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.