viernes, 29 de mayo de 2009

Notas de Unified Modeling Language (UML)


Hace ya casi un mes que terminé un curso de UML y hace un par de semanas que me llego el número de serie para activar Enterprise Architect, la cual es una herramienta muy útil para realizar los diagramas UML que sean requeridos por el proyecto, aunque siempre es bueno capacitarse, lo mejor es practicar.

Las notas que elaboré del curso son las siguientes:

Hay que tener en cuenta que para todo proyecto, sobre todo de sistemas existen un ¿qué hacer? (análisis o modelo conceptual) y un ¿cómo hacer? (diseño o modelo de clases), donde hay actores o agentes externos al sistema.
De todas las metodologías hay metodologías que cubren la parte de administración y la parte de ingeniería dentro de la misma metodología, dos ejemplos de metodologías que cubren estos dos aspectos de los proyectos son: Microsoft Solution Framework (MSF) y Rational Unified Process (RUP), las características principales de este último son:


  1. Esta dirigido por casos de uso.
  2. Centrado en la arquitectura (tecnología, hardware, aplicación) y un ciclo de vida
  3. Es iterativo (cada dos o dos meses y medio entregar algo al cliente funcionando).

Este proceso toma una parte de la lógica del ciclo de vida en cascada, que tiene dos principios:

  1. No se puede programar algo que no está diseñado.
  2. No se puede probar algo que no está programado.


Buenas prácticas



  1. solicitar una recomendación para nomenclatura de proceso.
  2. solicitar procedimiento y reglamento.
  3. objetivo del proceso.
  4. usar verbos pasivos más el complemento para el nombre de las actividades.


Notas sobre los diagramas.


En los diagramas de actividades solo puede haber un estado inicial y un estado final.
Los diagramas de secuencia son uno a uno con los diagramas de casos de uso, es decir por cada diagrama de caso de uso debe de existir un diagrama de secuencia.
Cada diagrama no debe de tener más de nueve elementos en promedio de cinco a siete elementos.
Los actores primarios en el diagrama del caso de uso van del lado derecho y los actores secundarios van del lado izquierdo.
El término realización se refiere a que cada caso de uso realiza un requerimiento.
Nunca al redactarse un caso de uso se debe poner la palabra etc.
Siempre es bueno acompañar los diagramas con un glosario de términos.
Una forma de estimación de los casos de uso es la clasificación de actores, un ejemplo:
+-------------------------+
| Simple | 1 | Sistema |
+-------------------------+
| Mediana | 2 | Máquina |
+-------------------------+
| Dificíl | 3 | Humano |
+-------------------------+

En el modelo conceptual se muestran tanto las reglas físicas como las reglas de negocio.
El orden del ciclo hasta el diseño deberá ser:

Modelado del negocio: diagrama de Stakeholder y diagrama de proceso de negocio.


Requerimientos: matriz de requerimientos, matriz de trazabilidad y diagrama de casos de uso.


Análisis: descripción de alto nivel y especificación detallada de casos de uso.


Diseño: modelo conceptual, diseño detallado y prototipo.


Para aseguramiento de la calidad usar las revisiones de software y "poner puntos de control" es decir revisar los artefactos creados y regresar con el usuario.

El diagrama de comunicación solo muestra cuales son los mensajes.
El diagrama de secuencia muestra el orden en que deben de invocarse los mensajes.
Un escenario va de un estado inicial al estado final.
Siempre debemos de fijarnos entre la correspondencia entre el diagrama de secuencia y el diagrama de clases en cuanto a la multiplicidad, recordando que una multiplicidad se refiere a una colección.
En la nomenclatura de un diagrama de clases si se tiene dos puntos (:) se refiere a una instancia y si se tiene cuatro puntos (::) se refiere al namespace más la instancia.
Para hacer un diagrama de secuencia se debe de pensar en operaciones, en tiempo y en la responsabilidad.
Por buenas prácticas en el constructor solo se debe de poner los métodos que se inicialicen y se debe de separar de la invocación de los métodos.
Por estandarización no se ponen los retornos en el diagrama de secuencia, pero solamente si es necesario, la respuesta siempre regresa al actor que invoco el método.
Un caso de uso abstracto es un caso de uso que se utiliza para representar soluciones genéricas y se coloca dentro del paquete de casos de uso, este caso de uso se utiliza para ocurrencias que es una nota dentro del diagrama de secuencia que va hacia un diagrama de secuencia que está dentro del caso de uso abstracto.
La diferencia entre un diagrama de clases y un diagrama conceptual son los métodos, en el diagrama conceptual únicamente se muestran los atributos y la relación de los objetos además en el modelo conceptual se puede omitir el tipo de dato en cambio en el diagrama de clases es obligatorio poner el tipo de dato.
Una funcionalidad como los hilos (threads) solamente puede diagramarse en el diagrama de secuencia.
De un diagrama de secuencia puede sacarse el diagrama de colaboración o viceversa.
En un diagrama de actividades el estado inicial no es obligatorio.
En el diagrama de componentes existe el manifest: que indica una relación lógica entre el componente y un archivo físico.
En el diagrama de máquinas de estados, se ponen los objetos que más relaciones tienen además los diagramas de máquinas de estados son útiles en la etapa de análisis, aunque también pueden usarse en la etapa de diseño.



Esta herramienta también puede auxiliarnos en la etapa de desarrollo creando código desde el diagrama clases, aquí dependerá del lenguaje o los lenguajes que decidimos para el proyecto y por supuesto no olvidar que la notación de UML ayuda con un factor importante en los proyectos: la comunicación.

martes, 26 de mayo de 2009

Ingeniería de software

Hace un par de semanas me solicitaron la elaboración de dos propuestas, una para la migración y otra para un nuevo desarrollo por lo me solicitaron hacer un resumen general sobre Metodologías RUP, MSF y XP, el mismo para ambas propuestas, el resultado fue el siguiente:


Microsoft Solution Framework (MSF) proporciona un conjunto de modelos, principios, y guías para diseñar y desarrollar soluciones empresariales de una manera que asegura que todos los elementos del proyecto tal como gente, procesos y herramientas, puedan ser exitosamente conducidos. No solamente es aplicable a los proyectos de desarrollo sino igualmente a los de infraestructura o redes. MSF actualmente tiene dos instancias: MSF for Agile Software Development y MSF for CMMI (Capability Maturity Model Integration) Process Improvement.MSF contiene un meta-modelo que estaba basado en la filosofía de que un proceso esta creado para ayudar y no para estorba, este modelo es compartido para procesos agiles y maduros que ocupen MSF.MSF consta de cinco fases: Previsión, Planificación, Desarrollo, Estabilización e Implementación y es continuamente refinado por clientes, consultores, grupos de producto y partners de Microsoft.



Rational United Process (RUP) Es un refinamiento del proceso unificado, sus características principales son combinar las prácticas comúnmente aceptadas de los procesos incremental e iterativo. Su objetivo principal es entregar artefactos verificables por el cliente. El énfasis en el desarrollo iterativo e incremental previene muchos de los riesgos comunes en los proyectos al animar al equipo a desarrollar en principio lo más riesgoso del proyecto, además de que los artefactos y los roles de los participantes están bien definidos y que el proceso esta soportado por muchas herramientas de desarrollo, el proceso toma en cuenta que cada proyecto es diferente, con necesidades diferentes y habilita para que cada fase del proyecto sea personalizada para lo requerido por el proyecto. Este proceso comienza con la toma de requerimientos, el análisis y el diseño para todo el proyecto incluyendo el modelado de datos y de objetos antes de la construcción. En este sentido toma un enfoque de proceso en cascada para el análisis y el diseño y un enfoque iterativo para la construcción y la liberación.



Extreme Programming (XP) Los procesos ágiles mueven el enfoque de desarrollo de software hacia lo que se considera la importancia del desarrollo de software: ejecutar software. Esto es posible si se acepta que el desarrollo de software es un trabajo creativo hecho por seres humanos individuales, por eso este proceso anima a la comunicación, interacción y diversión. XP se distingue de otras metodologías en: es inmediato, concreto y se retroalimenta en ciclos muy cortos, tiene flexibilidad para programar las funcionalidades en acuerdo con los cambios en los requerimientos, se confía de pruebas automatizadas escritas por los programadores y clientes para monitorear el progreso del desarrollo que permite una detección de pruebas tempranas, se confía de la comunicación oral y el código fuente para mostrar la estructura del programa, tiene confianza en la cercana colaboración de los programadores con habilidades ordinarias. XP es diseñado para trabajar con proyectos que pueden ser construidos por equipos de dos a diez programadores.



En la revisión de las propuestas por parte del cliente, se selecciono la metodología MSF para el nuevo desarrollo y RUP para la migración, lo interesante de esta elección es que la tecnología empleada por el cliente en ambos proyectos es .NET, por lo que la elección natural hubiera sido MSF sin miramientos.

Pero bueno el cliente es el cliente y sus razones tendrá, aunque esta decisión no es tan dispar como pudiera parecerse, ya que MSF y RUP comparten una gran cantidad de artefactos, por lo que solo deberé que usar lo común a las dos metodologías.