Es un lenguaje Unificado de Modelado.
Tiene la característica de estar orientado a objetos.
Tiene gramática, sintaxis, elementos, reglas para nombrar estos elementos.
Estándar para el modelado de sistemas.
Es una notación, no es un proceso, ni es una metodología (como es RUP)
Creado en 1997. Se basa en metodologías antiguas: OMT, Booch, OOSE
Hubo cambios fuertes desde la versión 2.0 (en 2004)
Se espera que la versión 2.5 tenga grandes cambios también (aún no sale)
2. Estructura de UML
Elementos de UML
7 Elementos que intervienen en todos los diagramas: Clases, Interfaz, Colaboración, Casos de Uso, Clase Ativa, Componente y Nodo.
Curiosidad: Los actores son clases con un estereotipo
Los componentes son las librerías... los archivos físicos
Los componentes van en los nodos, son los equipos, servidores, discos duros... inclusive pueden ser hubs, routers... si es necesario
2 Elementos de Comportamiento:
Son la interacciones (flechas) y la Máquina de Estados (rectángulo redondeado)
Elemento de Agrupación: El Paquete
Elemento de Anotación: La Nota
Relaciones UML
Relación de Dependencia
Un elemento depende de otro
Relación de Asociación
Dos elementos necesitan trabajar en conjunto
Relación de Generalización
Apunta hacia el elemento general
Relación de realización
Un elemento de colaboración ayuda al caso de uso. Apunta hacia el caso de uso.
Diagramas UML
UML1.x
9 diagramas:
Diagrama de clases: de análisis, de diseño, de negocio. Varían por el estereotipo. Los únicos elementos son clases y relaciones (solo línea contínua)
Diagrama de casos de Uso: dos diagramas
Casos de Uso de Negocio: Expresa los procesos de la empresa, todos aquellos procesos que tienen relación con el sistema. El Actor (StickMan) y los casos de uso llevan un estereotipo de línea diagonal. La relación es una asociación simple sin flecha.
Casos de Uso del Sistema: Expresa las funciones de un sistema
Diagrama de Objetos: Modela las instancias de los elementos. Grafican un ejemplo, una instantánea.
Diagramas de Secuencia: Compuesto de Objetos, instanciados de una clase que ya exista. Es un modelo de análisis. Es una secuencia de mensajes y corresponde exactamente lo que debe ocurrir en un caso de uso. Es importante el orden en el que se envían los mensajes.
Diagrama de Colaboración: Corresponde al diagrama de secuencia, pero de distinta forma.
Diagrama de Estados: Muestra un valor de un atributo. Normalmente va pegado a una clase. Las líneas llevan los eventos y los mensajes. Tienen un solo inicio y pueden tener varios finales.
Diagrama de Actividades: Parecidos a los diagramas de flujo. Un solo inicio, las actividades son atómicas (no pueden ser subdividido). Corresponden a una operación o un caso de uso.
Diagrama de Componentes: Para los archivos físicos.
Diagrama de Despliegue: Va junto al de componentes. Muestra qué componentes van en qué nodo (servidor, pc de usuario y otros elementos de la red también).
UML2.x
Han cambiado algunas cosas:
d. de actividad tiene nuevos elementos
d. de Estados ahora se llama Máquina de Estado
d. Secuencia tmabién tiene nuevos elementos.
Diagrama de Visión de Interacción: Nuevo diagrama que muestra la secuencia entre diagramas, parecido al diagrama de actividad. Realmente puede expresar la secuencia de varias cosas, no solo casos de uso, como una caja negra.
Diagrama de tiempos: Para programar tiempos en dispositivos o piezas de software.
d. Comunicación es el de colaboración
Diagrama de Paquetes, aunque ya se usaba intuitivamente.
Diagrama de Estructura Compuesta: para software que pueden crear su propia estructura de clase o nuevos tipos de datos.
Hay una Estructura Taxonómica que categoriza los diagramas entre d. de Estructura (estáticos) y de Comportamiento (dinámicos)
También en la versión 2.0 aparecen los frames que tienen etiquetas: pkg, cmp (componentes), uc, act, stm (Máquina de Estado) y sd (d. de interacción)
Mecanismos Comunes
Elementos de Apoyo que ayudan a entender mejor el diagrama.
Especificación. un documento que ayuda a poner por escrito precondiciones, post condiciones, restricciones, errores, etc
3. Arquitectura UML
4+1
REGLAS EN UML
Hay consideraciones, las cosas no pueden combinarse de cualquier manera, existen reglas.
Hay reglas para nombres, alcance, visibilidad y 2 mas
Para nombres:
La dependencia entre casos de uso include y extend.
Nombes de caso de uso de sistema se escriben en infinitivo, los nombres de casos de uso de negocio no tienen reglas porque dependen de cada negocio.
Para alcance: Da el significado específico a un nombre. Me dice cuando mostrar o no mostrar cosas. Como el include que en los casos de uso nunca van de uno con uno.
Para visibilidad: los signos (+ u otros ). O la regla que dice que siempre debe haber estereotipo gráfica o textualmente.
Para integridad: relaciones apropiadas entre elementos.
Ejm: Un actor q no puede tener include con un caso de uso. include entre dos casos de uso.
Para Ejecución
Luego usamos el Enterprise Arquitect
- Herramienta poderosa... licenciada... pero no es fiel a UML para analisis de negocio
- Copy and Paste poderosos... al pegar en Word le pone automáticamente el frame
- Crear los elementos en sus paquetes y luego traerlos al diagrama como vínculo.
- Asegurarse de abrir el diagrama correcto con doble click... pasa seguido que ponemos actores en un sitio y no era...
- En Business Entities, para crear los objetos de negocio, debemos crear un diagrama de objetos, luego crear la clase (son clases creadas para apoyo nomás, no son las clases finales del sistema), luego instanciarla
- De Business Entity a Entity para al final poner tener las clases reales del software
- En entidades de negocio es necesario poner las clases y luego instanciarlas... en el modelo de Trabajadoers de Negocio, no es necesario crear las clases... solo se ponen objetos.
- Se puede subir los archivos de Enterprise Arquitect al subversion... leer esto
==
Precisiones:
El estereotipo es para los elementos, y es obligatorio en todos los diagramas y puede aparecer gráficamente o escrito.
El actor es una clase
Nunca poner BusinessWorker en un diagrama de Casos de Uso!
En las casos de uso no va la secuencia
==
Para el trabajo:
- Power Builder puede ser usado orientado a objetos? Sí... leer por qué
- Se puede subir los archivos de Enterprise Arquitect al subversion... leer esto
- Debo llegar a una nueva implementación del Gestor con un avance de los diagramas con Enterprise Arquitect.
No hay comentarios:
Publicar un comentario