UML con Enterprise Architect

Información tomada de  http://www.sparxsystems.com.ar/resources/ 

El Modelo Dinámico El modelo dinámico se usa para expresar y modelar el comportamiento del sistema a lo largo del tiempo. Incluye soporte para diagramas de actividades, diagramas de estados, diagramas de secuencia y extensiones incluyendo modelado de proceso de negocio. Diagramas de secuencia  Los diagramas de secuencia se usan para mostrar la interacción entre los usuarios, las pantallas y las instancias de los objetos en el sistema. Proveen un mapa secuencial del paso de los mensajes entre los objetos a lo largo del tiempo. Frecuentemente, estos diagramas se ubican bajo los casos de uso o los componentes en el modelo para ilustrar un escenario -cómo interactúa un usuario con el sistema y qué sucede internamente para que el trabajo se lleve a cabo-. Muchas veces, los objetos se representan utilizando íconos especialmente estereotipados, como en el ejemplo de abajo. El objeto etiquetado "PantallaDeIngreso" (Login Screen) se muestra empleando el ícono de interfaz. El objeto etiquetado "AdministradorDeSeguridad" (SecurityManager) se muestra usando el ícono controlador. El objeto etiquetado "Usuarios" (Users) se muestra usando el ícono entidad. Diagramas de actividad Los diagramas de actividad se usan para mostrar cómo se construyen los diferentes flujos de trabajo o los procesos dentro de un sistema, cómo se inician, los variados caminos alternativos que se pueden tomar desde el inicio hasta el fin. También pueden ilustrar dónde puede ocurrir procesamiento en paralelo durante la ejecución de algunas actividades. Modelo de Procesos Un modelo de procesos es una extensión del UML de un diagrama de actividades usado para un modelo de procesos de negocios - este diagrama muestra que metas tiene el modelo, las entradas, salidas, eventos e información que se encuentran involucradas en el proceso. El Modelo Lógico Un modelo lógico es una vista estática de los objetos y las clases que cubren el espacio de análisis y diseño. Típicamente, un modelo de dominio es una vista más pobre, de alto nivel de los objetos de negocio y de las entidades, mientras que el modelo de clases es un modelo más riguroso y enfocado al diseño. Esta discusión describe principalmente el modelo de clases. El Modelo de Clases  Una clase es un elemento estándar del UML, que se usa para especificar el patrón del que se producirán los objetos en tiempo de ejecución. Una clase es una especificación; un objeto es una instancia de una clase. Las clases se pueden heredar de otras clases (es decir, heredan todo el comportamiento y el estado de sus padres y agregan nueva funcionalidad propia), pueden tener otras clases como atributos, pueden delegar sus responsabilidades a otras clases e implementar interfaces abstractas. El modelo de clases está en el núcleo del desarrollo y del diseño orientados a objetos; expresa el estado persistente y el comportamiento del sistema. Una clase encapsula el estado (los atributos) y ofrece los servicios para manipularlo (el comportamiento). Un buen diseño orientado a objetos limita el acceso directo a los atributos de la clase y ofrece los servicios que manipulan a solicitud del solicitante. Este ocultamiento de los datos y exposición de los servicios asegura que las modificaciones de los datos se realizan sólo en un lugar y de acuerdo con reglas específicas; para grandes sistemas la cantidad de código que tiene acceso directo a los elementos de datos en muchos sitios es extremadamente alto. Las clases se representan usando la siguiente notación: Observe que la clase tiene tres áreas diferentes: 1. El nombre de la clase (y el estereotipo, si corresponde) 2. El área de los atributos (es decir los elementos de datos internos) 3. El comportamiento; privado y público Los atributos y los métodos pueden ser marcados como: - Privados (private), indicando que no son visibles para los solicitantes fuera de la clase - Protegidos (protected), son visibles sólo para las clases hijas - Públicos (public), son visibles para todos. La herencia mostrada a continuación consiste en: una clase abstracta en este caso, es el padre de dos clases hijos, las cuales heredan las características y extienden sus comportamientos. Las clases se pueden agrupar en unidades lógicas o paquetes. Ellos juntan elementos relacionados entre sí. El diagrama siguiente ilustra esto. El Modelo Físico El Modelo Físico/de Despliegue provee un modelo detallado de la forma en la que los componentes se desplegarán a lo largo de la infraestructura del sistema. Detalla las capacidades de red, las especificaciones del servidor, los requisitos de hardware y otra información relacionada al despliegue del sistema propuesto. Vista de Despliegue MF01: Modelo Físico  El modelo físico muestra dónde y cómo se desplegarán los componentes. Es un mapa específico de la instalación física del sistema. Un diagrama de despliegue ilustra el despliegue físico del sistema en un ambiente de producción (o prueba). Muestra dónde se ubicarán los componentes, en qué servidores, máquinas o hardware. Puede ilustrar vínculos de red, ancho de banda de LAN, etc. Se utiliza un nodo para identificar cualquier servidor, terminal de trabajo u otro hardware host que se utiliza para desplegar componentes en el ambiente de producción. Usted también puede especificar los vínculos entre los nodos y asignarles estereotipos (tales como TCP/IP) y requisitos. Los nodos también pueden tener documentados características de performance, estándares mínimos de hardware, niveles de sistema operativo, etc. La pantalla de abajo ilustra las propiedades comunes que puede establecer para un nodo. El Modelo de Caso de Uso El modelo de casos de uso describe la funcionalidad propuesta del nuevo sistema. Un caso de uso representa una unidad discreta de interacción entre un usuario (humano o máquina) y el sistema. Un Caso de Uso es una unidad simple de trabajo significativo; por ejemplo, "Validarse en el sistema", "Registrarse en el sistema" y "Crear un pedido" son todos casos de uso. Cada caso de uso tiene una descripción que describe la funcionalidad que se construirá en el sistema propuesto. Un caso de uso puede "incluir" la funcionalidad de otro caso de uso o "extender" a otro caso de uso con su propio comportamiento. Una descripción de caso de uso generalmente incluirá: Comentarios generales y notas describiendo el caso de uso Requisitos -cosas que el caso de uso debe permitir hacer al usuario, tales como <capacidad para actualizar pedido>, <capacidad para modificar pedido>, etc. Restricciones -reglas acerca de qué se puede y qué no se puede hacer-. Incluye: Pre-condiciones que deben ser verdaderas antes de que el caso de uso se ejecute, por ejemplo <crear pedido> debe preceder a <modificar pedido> Post-condiciones que deben ser verdaderas una vez que el caso de uso se ejecutó, por ejemplo <el pedido está modificado y es consistente> invariantes: éstas son siempre verdaderas -por ejemplo, un pedido debe tener siempre un número de cliente. Escenarios -descripciones secuenciales de los pasos que se toman para llevar a cabo el caso de uso. Pueden incluir escenarios múltiples, para satisfacer circunstancias excepcionales y caminos de proceso alternativos Diagramas de escenarios -diagramas de secuencia para describir el flujo de trabajo- similar al punto 4 pero descrito gráficamente. Atributos adicionales como fase de implementación, número de versión, rango de complejidad, estereotipo y estado Actores Un actor es un usuario del sistema. Incluye usuarios humanos y otros sistemas computarizados. Un actor usa un caso de uso para desempeñar alguna porción de trabajo que es de valor para el negocio. El conjunto de casos de uso al que un actor tiene acceso define su rol global en el sistema y el alcance de su acción. Relaciones de Inclusión y Extensión entre Casos de Uso Un Caso de Uso puede incluir la funcionalidad de otro como parte de su procesamiento normal. Generalmente se asume que los casos de uso incluidos se llamarán cada vez que se ejecute el camino base. Un ejemplo puede ser listar un conjunto de órdenes de clientes de las cuáles poder elegir antes de modificar una orden seleccionada; en este caso, el Caso de Uso <listar órdenes> se puede incluir en el Caso de Uso <modificar orden> cada vez que éste se ejecute. Un Caso de Uso puede ser incluido por uno o más casos de uso, ayudando así a reducir la duplicación de funcionalidad al factorizar el comportamiento común en los casos de uso que se reutilizan muchas veces. Un Caso de Uso puede extender el comportamiento de otro Caso de Uso; típicamente cuando ocurren situaciones excepcionales. Por ejemplo, si antes de modificar un tipo particular de orden de cliente, un usuario debe obtener la aprobación de alguna autoridad superior, entonces el Caso de Uso <obtener aprobación> puede extender opcionalmente el Caso de Uso normal <modificar orden>. Diagrama de Secuencia El UML provee un medio gráfico para representar la interacción entre los objetos a lo largo del tiempo en los diagramas de secuencia. Éstos muestran típicamente a un usuario o a un actor y los objetos y componentes con los que interactúen durante la ejecución de un Caso de Uso. Un diagrama de secuencia representa típicamente un único escenario de Caso de Uso o flujo de eventos. Los diagramas son una vía excelente para documentar los escenarios de uso, para capturar los objetos necesarios de manera temprana en el análisis y para verificar el uso de los objetos más tarde en el diseño. Los diagramas de secuencia muestran el flujo de mensajes de un objeto a otro y, como tales, representan los métodos y los eventos soportados por un/a objeto/clase. El diagrama ilustrado abajo muestra un ejemplo de un diagrama de secuencia, con el usuario o actor a la izquierda iniciando un flujo de eventos y mensajes que corresponden al escenario del caso de uso. Los mensajes que pasan entre objetos se convertirán en operaciones de clases en el modelo final. Diagrama de Implementación Un Caso de Uso es una descripción formal de la funcionalidad que el sistema tendrá cuando se construya. Un diagrama de implementación se asocia típicamente con un caso de uso para documentar qué elementos de diseño (por ejemplo, componentes y clases) implementará la funcionalidad del Caso de Uso en el nuevo sistema. Esto provee un alto grado de trazabilidad al diseñador, al cliente y al equipo que construirá el sistema. La lista de casos de uso a los que se asocia un componente o una clase documenta la funcionalidad mínima que debe ser implementada por el componente. El ejemplo de arriba muestra que el caso de uso "Acceso" implementa el requisito formal "1.01 Acceder al sitio web". También establece que el componente de lógica de negocios y el componente de páginas ASP implementan alguna parte o toda la funcionalidad de "Acceso". Un refinamiento adicional es mostrar la pantalla de "Acceso" (una página web) como una implementación de su interfaz. Estos enlaces de implementación o realización definen la trazabilidad desde los requisitos formales, a través de casos de uso, a componentes y pantallas.