Casos de Uso Diagramas de casos de uso: Casos de uso Actores Relaciones de dependencia, generalización y asociación Actores: Se representan mediante monigotes Se pueden definir categorías generales (Cliente) y especializarlas a través de relaciones de generalización Un Actor sólo se puede conectar a un caso de uso mediante una asociación
Diagramas de Clases Modelan la vista de diseño estática de un sistema La vista estática soporta los requisitos funcionales Son los más utilizados en el modelado de sistemas orientados a objeto Fowler: "Psst. ¿Quiere ver un diagrama de UML?" Muestra un conjunto de clases, interfaces y colaboraciones Son importantes para construir sistemas ejecutables, aplicando ingeniería directa e inversa
Diagramas de Clases Son un conjunto de nodos y arcos Contienen clases, interfaces, colaboraciones, relaciones de dependencia, generalización y asociación Pueden contener también paquetes o subsistemas para agrupar otros elementos del modelo El mayor peligro de los diagramas de clases es que uno se puede concentrar en la estructura y olvidar la conducta – Alternar clases de diagramas Recomendación 2 (Fowler): No diagramar todo, sino aspectos importantes
Diagramas de Objetos Modelan las instancias de los elementos contenidos en los diagramas de clases Muestran un conjunto de objetos y sus relaciones en un momento concreto (vista estática, como una instantánea) Consisten en los objetos que colaboran, pero sin especificar los mensajes Contienen objetos y enlaces Pueden contener paquetes o subsistemas
Diagramas de Objetos Se puede hacer ingeniería directa, pero en la práctica esto tiene un valor limitado Las instancias son creadas en tiempo de ejecución Hacer ingeniería inversa es más razonable y se hace continuamente p. ej. para localizar un enlace perdido, etc. Tener en cuenta: No es posible capturar todos los objetos potenciales de un sistema o sus relaciones Se usan para capturar algún aspecto específico del sistema en un momento dado
Diagramas de Componentes Modelan aspectos físicos del sistema Ejecutables, bibliotecas, tablas, archivos, documentos Representan el empaquetamiento físico de elementos lógicos tales como clases, interfaces y colaboraciones Definen abstracciones con interfaces bien definidas La notación canónica permite visualizar un componente con independencia de sistema operativo o lenguaje de programación Con los mecanismos de extensión (estereotipos) se puede particularizar la notación
Diagramas de Componentes Contienen componentes, interfaces y relaciones de dependencia, asociación y realización También pueden contener paquetes, subsistemas e instancias Es habitual hacer ingeniería directa e inversa Cada diagrama representa un aspecto; el conjunto de todos representa una vista estática completa del sistema
Diagrama de Secuencia (DSS) Muestra eventos de entrada y salida relacionados con el sistema UML incluye notación para representar los eventos que parten de los actores externos hacia el sistema Un DSS es un dibujo que muestra, para un escenario* de casos de uso, los eventos generados por los actores, el orden y los eventos entre sistemas El orden de los eventos debe seguir el orden en el caso de uso
Diagrama de Secuencia (DSS) Larman, p. 118
Diagrama de Secuencia (DSS) Forman parte del Modelo de los Casos de Uso No se mencionan en la especificación de UP Se suelen crear en la elaboración, no en la incepción No es necesario crear DSS para todos los escenarios de todos los casos de uso En UML 1, los elementos del DSS eran objetos; ahora es más complicado y abstracto
Diagramas de Secuencia Son buenos para comprender la conducta de varios objetos en un solo caso de uso Sirven para mostrar colaboración entre objetos; no lo son para modelar la conducta Si se quiere ver la conducta de un solo objeto a través de varios casos de uso, usar un diagrama de estados Muchos threads a través de muchos casos, un diagrama de actividad
Diagramas de Estados Statecharts: Muestran una máquina de estados Un diagrama de actividad es una clase especial de diagrama de estados que muestra el flujo de control entre actividades Un diagrama de estados muestra el flujo de control entre estados Especifica la secuencia de estados por la que pasa un objeto en respuesta a eventos, junto con sus respuestas a esos eventos Son útiles para modelar comportamiento regido por eventos
Diagramas de Estados Usualmente se modela la vida de un objeto, comenzando por su creación, sus estados estables y su destrucción Una máquina de estados cuyas acciones están asociadas a transiciones se llama máquina de Mealy Una máquina de estados cuyas acciones están asociadas a estados se llama máquina de Moore En la práctica se suelen mezclar ambos tipos de máquinas
Diagramas de Estado La ingeniería directa es usual La ingeniería inversa es teóricamente posible pero no es útil Las herramientas de ingeniería inversa no tienen capacidad de abstracción y no pueden producir diagramas de estado significativos Puede resultar más útil alguna herramienta de animación
Diagramas de Actividad Equivalente de un workflow, pero con soporte de paralelismo Describen lóigica de procedimiento, lógica de negocios y workflow Es uno de los que más cambió en UML 2 En UML 1 eran casos especiales de diagramas de estado; ya no más En UML 1 había reglas especiales para balancear forks y joins; ya no es más preciso
Diagramas de Comunicación Se llamaban Diagramas de Colaboración en UML 1. Enfatiza los vínculos de datos entre los participantes de una interacción Utilizan numeración para mostrar la secuencia de un mensaje Usualmente su usa numeración común, plana; pero la legal ("Kosher") debería ser decimal 1.1, etc .
Diagramas de Despliegue Modelan la vista de despliegue estática, equivalente a la topología del sistema Para modelar hardware, se recomiendan lenguajes específicos, como VHDL No sólo modelan el despliegue, sino que pueden gestionarlo a través de ingeniería directa o inversa Contienen nodos y relaciones de dependencia y asociación Pueden contener paquetes, subsistemas, componentes e instancias
Diagramas de Despliegue Se puede hacer alguna ingeniería directa, mayormente para visualizar La ingeniería inversa es de mayor valor
Vista de gestión: Paquetes Un paquete es una parte de un modelo Cada parte de un modelo debe pertenecer a un paquete Los paquetes contienen elementos en el más alto nivel Clases y relaciones, máquinas de estado, diagramas de casos de uso, interacciones y colaboraciones Cualquier elemento que no esté contenido en otro paquete Si se ilgen bien los paquetes, representan la arquitectura de alto nivel del sistema
Mecanismos de Extensión Las herramientas pueden almacenar y manipular las extensiones, pero sin entender su semántica Se espera que haya herramientas y módulos adicionales que puedan entenderlas Los mecanismos usuales de extensión son: Restricciones Valores etiquetados Estereotipos Las extensiones generan "dialectos" de UML
Extensiones: Restricción Es una condición semántica representada como expresión textual Puede ser notación matemática formal, un lenguaje como OCL, un lenguaje de programación o seudocódigo Aunque se represente en lenguaje formal, no es de cumplimiento automático Habitualmente se expresan entre llaves cantidad: Dinero {valor múltiplo de 20} {Persona.Empleado = Persona.Jefe.Empleado}
Extensiones: Valor etiquetado Los valores etiquetados se muestran como cadenas con el nombre de la etiqueta, un signo igual y un valor No se deben usar etiquetas reservadas Usualmente se ponen entre llaves {autor=Billy Reynoso,creación=7/12/04,estado=activado}
Extensiones: Estereotipos Pueden utilizar símbolos pre-existentes o iconos creados a ese efecto Usualmente se presentan como cadenas de texto encomilladas
Referencias Grady Booch, James Rumbaugh, Ivar Jacobson – El Lenguaje Unificado de Modelado. Madrid, Addison Wesley, 1999. Craig Larman – UML y Patrones. 2a ed., Madrid, Pearson/Prentice Hall, 2003.
| Página siguiente |