El Lenguaje Unificado de Modelado, UML Análisis y Diseño del Software Curso 2004/2005 Capítulo 1 El Lenguaje Unificado de Modelado, UML Jesús García Molina Departamento de Informática y Sistemas Universidad de Murcia http://dis.um.es/~jmolina

Contenidos Modelado del software Presentación de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases

Contenidos Modelado del Comportamiento Diagramas de interacción Diagramas de actividades Máquinas de estado Modelado de la Implementación Diagramas de componentes Diagramas de despliegue Colaboraciones Formalización de UML: MOF y metamodelo

Contenidos Modelado del software Presentación de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases

Bibliografía G. Booch, J. Rumbaugh, I. Jacobson, “El lenguaje unificado de modelado”, Addison-Wesley, 1999. C. Larman, “UML y Patrones: Una introducción al análisis y diseño orientado a objetos y al proceso unificado”, Prentice-Hall, 2003. http://www.uml.org/

El lenguaje unificado de modelado, UML A mediados de los noventa existían muchos métodos A/DOO Mismos conceptos con distinta notación Mucha confusión. En 1994, Booch, Rumbaugh y Jacobson deciden unificar las notaciones de sus métodos: Unified Modeling Language (UML) Proceso de estandarización promovido por el OMG http://www.uml.org

Explosión de métodos OO en los noventa OMT Coad/Yourdon Booch Champeaux Jacobson Martin/Odell Shlaer-Mellor OOram Wirfs-Broks BON Fusion Open Catalysis ¡Y muchos más! ¡Guerra de Métodos!

Evolución UML Grady Booch y Jim Rumbaugh comenzaron a unificar sus métodos (Octubre, 1994). Borrador de UML (versión 0.8) (Octubre, 1995) Ivar Jacobson se une al proyecto (Noviembre, 1995). UML 0.9 y se crea un consorcio (Junio, 1996) OMG lanza una petición para un lenguaje unificado (1996) UML 1.0 es ofrecido al OMG (Enero, 1997) Se extiende el consorcio (Enero-Julio, 1997) UML 1.1 es ofrecido al OMG (Julio, 1997) OMG adopta UML 1.1 (Noviembre, 1997) Se crea el UML RTF (1998) UML 1.3 (Mayo 1999) UML 2.0 (principios de 2005)

Ventajas de la unificación Reunir los puntos fuertes de cada método Idear nuevas mejoras Proporcionar estabilidad al mercado Proyectos basados en un lenguaje maduro Aparición de potentes herramientas Eliminar confusión en los usuarios

Objetivos en el diseño de UML Modelar sistemas, desde los requisitos hasta los artefactos ejecutables, utilizando técnicas OO. Cubrir las cuestiones relacionadas con el tamaño propias de los sistemas complejos y críticos. Lenguaje utilizable por las personas y las máquinas Encontrar equilibrio entre expresividad y simplicidad.

Modelado del Software El modelado es el diseño de aplicaciones software antes de escribir el código. Se crean un conjunto de modelos (“planos del software”) que permiten especificar aspectos del sistema como los requisitos, la estructura y el comportamiento. Los modelos ayudan a razonar sobre el sistema permiten documentar las decisiones Permiten una generación automática de código

¿Qué es un modelo? “Un modelo es una simplificación de la realidad” “Un modelo es una descripción de un sistema, escrito en un lenguaje bien definido”

Tipos de modelo ¿En qué etapa del proceso se usa? ¿Análisis o Diseño? ¿Cuál es su grado de detalle? ¿Abstracto o detallado? ¿Qué sistema describe? ¿Modelo de negocio o modelo software? ¿Qué aspecto describe? ¿Estructural o de comportamiento? ¿Es específico o independiente de la plataforma? ¿A qué plataforma va dirigido? EJB, JDBC, .NET, CORBA, etc.

Modelos de Negocio y de Software Modelo del Negocio derivado de Modelo Software describe describe Sistema software Sistema de la empresa Empresa

Utilidad del modelado “Una empresa software con éxito es aquella que produce de manera consistente software de calidad que satisface las necesidades de los usuarios” “El modelado es la parte esencial de todas las actividades que conducen a la producción de software de calidad”

.... necesitamos escribir modelos Utilidad del modelado ¿Escribimos código directamente? Sería lo ideal pero .... .... necesitamos escribir modelos

Utilidad del modelado Hay estructuras que trascienden lo representable en un lenguaje de programación. Se facilita la comunicación entre el equipo al existir un lenguaje común. Se dispone de documentación que trasciende al proyecto.

Utilidad del modelado Visualizar cómo es o queremos que sea el sistema Especificar la estructura y comportamiento del sistema Proporciona plantillas que guían la construcción del sistema. Documentan las decisiones.

Propiedades del modelado La elección de los modelos tiene una profunda influencia sobre cómo se acomete el problema y se moldea la solución. Todo modelo debe estar ligado a la realidad. Un único modelo no es suficiente. Cualquier sistema trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes.

¿Por qué las empresas no hacen modelado? Hasta ahora, la mayor parte de las empresas software no realizan ningún modelado. El modelado requiere: aplicar un proceso de desarrollo formación del equipo en la técnicas concienciación de su importancia ¿Se obtienen beneficios con el modelado?

¿Construimos software de calidad? Retrasos en los plazos Proyectos cancelados Rápido deterioro del sistema instalado Tasa de defectos o fallos Requisitos mal comprendidos Cambios frecuentes en el dominio del problema Buenos programadores se cansan y dejan el equipo ¿Modelado es la solución?

Contenidos Presentación de UML Modelado del software Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases

UML y el modelado UML es una notación, no es un proceso UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos (modelos) de un sistema que involucra una gran cantidad de software, desde una perspectiva orientada a objetos. UML es una notación, no es un proceso Se han definido muchos procesos para UML. Rational ha ideado RUP, el“proceso unificado”. Utilizable para sistemas que no sean software

Marco Conceptual de UML Bloques básicos de construcción Elementos Estructurales, Comportamiento, Agrupación, Anotación Relaciones Diagramas Reglas para combinar bloques Establecen qué es un modelo bien formado Mecanismos comunes Especificaciones, Extensibilidad, Dicotomía clase-instancia, Dicotomía interfaz-realización

Elementos Estructurales Partes estáticas de un modelo Ventana <<Interface>> origen IAvisable tamaño IAvisable abrir() cerrar() Interface mover() dibujar() clase caso de uso ValidarTransaccion

Elementos Estructurales Gestor Eventos suspender() vaciarCola() clase activa Gestión Pedidos colaboración componente nodo

Elementos de Comportamiento Son las partes dinámicas de UML. Interacción Conjunto de mensajes intercambiados entre un conjunto de objetos con un propósito particular. dibujar mensaje

Elementos de Comportamiento Son las partes dinámicas de UML. Máquina de estados Secuencia de estados por las que pasa un objeto durante su vida en respuesta a eventos. estado activado

Elementos de Agrupación Son las partes de organización de los modelos UML Paquete Modelo del Negocio Un paquete incluye un conjunto de elementos de cualquier naturaleza. Tiene una naturaleza conceptual.

Elementos de Anotación Son las partes explicativas de los modelos UML Nota

Relaciones Dependencia Asociación patron empleado Generalización 0..1 * Asociación patron empleado Generalización Realización

Ejemplo

Diagramas no son modelos Diagramas de UML Diagramas de Casos de Uso Diagramas de Clases Diagramas de Objetos Diagramas de Interacción Diagrama Secuencia Diagrama Colaboración Diagramas de Estados Diagramas de Actividades Diagramas de Componentes Diagramas de Despliegue Diagramas no son modelos

Modelos en UML Modelado de Casos de Uso Modelado Estructural Diagrama de Casos de Uso Modelado Estructural Diagrama de Clases Modelado de Comportamiento Diagramas de Interacción Diagramas de Estados Modelado de flujos de actividades (p.e. Modelo del Negocio) Diagramas de actividades Modelado Implementación Diagrama de Componentes Modelado de Despliegue Diagramas de Despliegue

Diagrama de actividades Modelo del Negocio Diagrama de actividades

Diagrama de casos de uso Modelo Casos de Usos Diagrama de casos de uso

Diagrama de clases Modelo Estructural

Diagrama de colaboración Modelo de Comportamiento

Máquina de Estado Diagrama de estado

Mecanismos comunes de UML Especificaciones Proporcionan una semántica para cada elemento Los diagramas son proyecciones de esa base Adornos La notación gráfica básica de cada elemento puede incluir adornos textuales o gráficos para resaltar algunas propiedades de la especificación.

Mecanismos comunes de UML Dicotomía clasificador /instancia UML distingue un objeto utilizando el mismo símbolo de la clase y subrayando el nombre del objeto CLASE Objetos Objeto de la clase Persona que no se muestra en forma explícita Se indica en forma explícita que es un objeto Persona Objeto Persona anónimo Persona nombre direccion telefono Elena Elena : Persona Casi todos lo bloque de construcción UML presentan esta dicotomía Clase/Objeto: Ej. Caso uso e instancia de caso de uso Componente e instancias de componentes Nodos e instancias de nodos : Persona

Mecanismos comunes de UML Dicotomía interfaz / implementación Una Interfaz declara un contrato y una implementación representa una realización concreta de ese contrato, responsable de hacer ejecutar de forma fidedigna la semántica completa de la interfaz asistente Ortografico.dll IOrtografia Casi todos los bloques de construcción UML presentan esta dicotomía interfaz/implementación. Ej. Casos de uso y las colaboraciones que los realizan operaciones y los métodos que los implementan

Mecanismos de extensibilidad de UML Estereotipos Extienden el vocabulario de UML, permiten definir nuevos tipos elementos y relaciones a partir de los existentes. Algunos son predefinidos en UML Valores etiquetados Extienden las propiedades de un elemento, añadiendo nueva información. Par etiqueta/valor: { etiqueta = “valor” } Restricciones Restricciones semánticas a elementos o relaciones. Definidos por el modelador o incluidos en UML. Ejemplo: { emp.vacaciones < 28 }

Ejemplo Estereotipo predefinido Clase Clase estereotipada

Ejemplo Estereotipo Predefinido Clase estereotipada

Mecanismos de extensibilidad de UML valor etiquetado estereotipo ColaEventos {version 3.2; autor: jgm} <<Exception>> añadir() quitar() Overflow vaciar() {ordenado} restricción

¡Hola, Mundo! import java.awt.Graphics; Paquete Java en el cual se encuentra la Clase Graphics La clase Graphics esta disponible para el código que sigue Introduce la nueva clase Holamundo especificando que es una subclase de Applet que se encuentra en paquete java.applet import java.awt.Graphics; class HolaMundo extends java.applet.Applet { public void paint (Graphics g) { g.drawString (“¡Hola, Mundo!”,10,10); } parámetro Operación Operación invocada por paint HolaMundo g.drawString ("Hola, mundo”) paint() ABSTRACCIONES claves para HolaMundo ( captura los aspectos básicos de la aplicación “¡HolaMundo!” pero deja fuera varias cosas)

La Clase Applet se utiliza como padre de HolaMundo Diagrama de Clases La Clase Applet se utiliza como padre de HolaMundo Y la clase Graphics se utiliza en la signatura e implementación de una de sus operaciones, paint. generalización dependencia

Component implementa a ImageObserver Al revisar las bibliotecas de Java para Applet y Graphics se verá que son parte de una jerarquía mayor Jerarquía de Herencia de HolaMundo

Organización en Paquetes Organización de paquetes de HolaMundo

Organización en Paquetes java HolaMundo Applet awt lang

Diagrama de Secuencia Mecanismos para Dibujar ( se establece el orden de los eventos) activación Nombre del objeto Operaciones invocadas La figura muestra la colaboración de varios objetos , incluida una instancia de la clase HolaMundo. Los objetos son parte del entorno Java

Diagrama de Componentes Componente ejecutable hola.java HolaMundo.class Código fuente de la clase HolaMundo Página Web Cada uno de los íconos de esta figura representa un elemento UML en la vista de implementación del sistema hola.html hola.jpg

Contenidos Presentación de UML Modelado de Casos de Usos Modelado del software Presentación de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases

Modelado de Casos de Uso Un caso de uso especifica un comportamiento deseado del sistema. Representan los requisitos funcionales del sistema. “Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor” Describen qué hace el sistema, no cómo lo hace.

Emisor Centralita Receptor listo( ) tono marcar_numero tono_sonando timbre_sonando telefono_cogido para_tono para_timbre ESCENARIO Casos de uso son ideados por Jacobson a principios de los noventa Se inspira en los escenarios utilizados para describir procesos

Otras definiciones de caso de uso “Describe un conjunto de interacciones entre actores externos y el sistema en consideración orientadas a satisfacer un objetivo de un actor”. [D. Bredemeyer] “Es una colección de posibles secuencias de interacciones entre el sistema en discusión y sus actores externos, relacionado con un objetivo particular”. [A. Cockburn] “Es una colección de escenarios de éxito y fracaso relacionados que describe a los actores que usan un sistema para conseguir un objetivo” [C. Larman]

Ejemplo Caso de Uso actor caso de uso asociacion

Actores Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos de uso al interaccionar con el sistema. Roles jugados por personas, dispositivos, u otros sistemas. El tiempo puede ser un actor (“procesos iniciados por el sistema”) No forman parte del sistema

Actores Un usuario puede jugar diferentes roles. En la realización de un caso de uso pueden intervenir diferentes actores. Un actor puede intervenir en varios casos de uso. Identificar casos de uso mediante actores y eventos externos. Un actor necesita el caso de uso y/o participa en él.

Actores A. Cockburn distingue dos tipos de actores: Primarios: Requieren al sistema el cumplimiento de un objetivo Secundarios: El sistema necesita de ellos para satisfacer un objetivo

Propiedades de los casos de uso Son iniciados por un actor con un objetivo en mente y es completado con éxito cuando el sistema lo satisface. Puede incluir secuencias alternativas que llevan al éxito y fracaso en la consecución del objetivo. El sistema es considerado como una “caja negra” y las interacciones se perciben desde fuera. El conjunto completo de casos de uso especifica todas las posibles formas de usar el sistema, esto es el comportamiento requerido.

Escenarios y Casos de Uso Un caso de uso describe un conjunto de secuencias de interacciones o escenarios: flujo principal y flujos alternativos o excepcionales Un escenario es una instancia de un caso de uso Escenarios principales vs. Escenarios secundarios Especificación con diagramas de secuencia o textual.

Descripción de un caso de uso Describir el flujo de eventos Texto estructurado informal Texto estructurado formal (plantillas) Pseudocódigo Notaciones gráficas: diagramas de secuencia Debe ser legible y comprensible para un usuario no experto. Debe indicarse: inicio y final, actores, objetos que fluyen, flujo principal y flujos excepcionales.

Descripción de un caso de uso Comprar artículos (en un terminal de punto de venta) Flujo Principal: Un cliente llega al TPV con un conjunto de articulos. El Cajero registra los artículos y se genera un ticket. El cliente paga en efectivo y recoge los artículos. 1. El cliente llega al TPV con los artículos. 2. El cajero registra el identificador de cada artículo. 3. El sistema obtiene el precio de cada artículo y añade la información a la transacción de venta. 4. Al acabar el cajero indica la finalización de la introducción de artículos. 5. El sistema calcula el total de la compra y lo muestra.

Descripción de un caso de uso Comprar articulos (en un terminal de punto de venta) 6. El Cajero le dice al cliente el total. 7. El cliente realiza el pago. 8. El cajero registra la cantidad de dinero recibida. 9. El sistema muestra la cantidad a retornar al cliente y genera un recibo. 10. El cajero deposita el dinero recibido y saca la cantidad a devolver que entrega al cliente junto al ticket de compra. 11. El sistema almacena la compra completada. 12. El cliente recoge los artículos comprados.

introducirItem(upc,cantidad) Comprar Articulos Cajero Cliente :Sistema : Cajero introducirItem(upc,cantidad) finalizarVenta() hacerPago(cantidad)

Descripción de un caso de uso Validar Usuario (contexto de un cajero automático) Flujo Principal: El sistema pide el NIP. El cliente lo introduce a través del teclado y pulsa Enter. El sistema comprueba la validez del NIP. Si es válido el sistema acepta la entrada y finaliza el caso de uso. Flujo Excepcional: El cliente puede cancelar la transacción en cualquier momento, pulsando el botón Cancelar, reiniciando el caso de uso. Flujo Excepcional: Si el NIP introducido es inválido entonces se reinicia el caso de uso. Si esto ocurre tres veces, el sistema cancela la transacción completa y se queda con la tarjeta.

Ejemplo diagrama de casos de uso

Ejemplo diagrama de casos de uso Actores Secundario Actor Principal

Ejemplo diagrama de casos de uso Reservar Libro Prestamo revista Profesor Prestamo Libro Devolver revista Socio Devolver libro Actualizar catalogo Bibliotecario Extender Prestamo Consultar Socio

Casos de uso y Colaboraciones Con un caso de uso se describe un comportamiento esperado del sistema, pero no se especifica cómo se implementa. Una caso de uso se implementa a través de una colaboración: “Sociedad de clases y otros elementos que colaborarán para realizar el comportamiento expresado en un caso de uso” Una colaboración tiene una parte estática (diagramas de clases) y una parte dinámica (diagramas de secuencia).

Casos de uso y Colaboraciones caso de uso colaboración Hacer Pedido Gestión Pedidos realización

Casos de uso y Colaboraciones “El objetivo de la arquitectura del sistema es encontrar el conjunto mínimo de colaboraciones bien estructuradas, que satisfacen el comportamiento especificado en todos los casos de uso del sistema”

Organización de Casos de uso Tres tipos de relaciones: Generalización Un cdu hereda el comportamiento y significado de otro Inclusión Un cdu base incorpora explícitamente el comportamiento de otro en algún lugar de su secuencia. Extensión Un cdu base incorpora implícitamente el comportamiento de otro cdu en el lugar especificado indirectamente por este otro cdu

Ejemplo «extend» «include» Hacer Pedido Urgente Hacer Pedido (establecer prioridad) Hacer Pedido Urgente «extend» Relación de extensión Validar Usuario Hacer Pedido Seguir Pedido «include» Relación de inclusión Generalización Comprobar clave Examinar retina

Relación de inclusión Permite factorizar un comportamiento en un caso de uso aparte y evitar repetir un mismo flujo en diferentes casos de uso. Ejemplo caso de uso “Hacer Pedido”: “Obtener y verificar el número de pedido. Include (Validar usuario). Examinar el estado de cada parte del pedido y preparar un informe para el usuario”.

Relación de extensión El caso de uso base incluye una serie de puntos de extensión. Sirve para modelar la parte opcional del sistema un subflujo que sólo se ejecuta bajo ciertas condiciones varios flujos que se pueden insertar en un punto Ejemplo caso de uso “Hacer Pedido”: “ Include (Validar usuario). Recoger los ítems del pedido del usuario. (establecer prioridad). Enviar pedido para ser procesado.

Obtención de casos de uso 1) Identificar los usuarios del sistema. 2) Encontrar todos los roles que juegan los usuarios y que son relevantes al sistema. 3) Para cada rol identificar todas las formas (objetivos) de interactuar con el sistema. 4) Crea un caso de uso por cada objetivo. 5) Estructurar los casos de uso. (¡Cuidado!) 6) Revisar y validar con el usuario.

Plantilla para casos de uso (D. Coleman) Caso de Uso identificador / historia Descripción objetivo a conseguir Actores lista de actores Asunciones condiciones que deben cumplirse Pasos interacciones entre los actores y el sistema necesarias para obtener el objetivo Variaciones (opcional) cualquier variación en los pasos No-funcional (opcional) lista requisitos no funcionales Cuestiones lista de cuestiones que permanecen por resolver

Plantilla para casos de uso (D. Coleman) Ejemplo campo “pasos”: 1. Operador es notificado de problema en la red 2. Operador inicia una sesión de reparación 3. REPETIR 3.1. Operador ejecuta aplicación diagnósticos en la red. 3.2. Operador identifica elementos que deben cambiarse y sus nuevos valores para los parámetros. 3.3. EN PARALELO 3.3.1. Ingeniero mantenimiento comprueba elementos en la red || 3.3.2. Ingeniero mantenimiento envía informe fallo 4. Operador cierra sesión

Plantilla para casos de uso (D. Coleman) Relación de uso: PERFORM c.d.u. Relación de extensión: Caso de uso extensión c.d.u. extends c.d.u. Cambio objetivo que debe conseguirse Pasos ... Variaciones ... No funcional ... Cuestiones ...

Plantilla usecases.org (Larman) Actor Principal Personas involucradas e Intereses Precondiciones Postcondiciones Escenario Principal (Flujo Básico) Extensiones (Flujos Alternativos) Requisitos especiales Tecnología y Lista Variaciones de datos Frecuencia Cuestiones abiertas

¿Por qué casos de uso? “Ofrecen un medio sistemático e intuitivo para capturar los requisitos funcionales, centrándose en el valor añadido para el usuario” Dirigen todo el proceso de desarrollo puesto que la mayoría de actividades (planificación, análisis, diseño, validación, test,..) se realizan a partir de los casos de uso. Mecanismo importante para soportar “trazabilidad” entre modelos.

Críticas a los casos de uso (B.Meyer) Los casos de uso no son adecuados en el modelado orientado a objetos porque: i) Favorecen un enfoque funcional, basado en procesos ii) Se centran en secuencias de acciones iii) Se basan en los escenarios actuales del sistema “Solo deben ser usados por equipos expertos en desarrollo OO” Útiles para validación

Utilidad de los casos de uso Hay consenso en considerar casos de uso como esenciales para capturar requisitos y guiar el modelado. Pero existe (¿ha existido?) mucha confusión sobre cómo usarlos. Diferentes opiniones sobre el número de casos de uso conveniente: 20 para un proyecto 10 personas/año (Jacobson) depende de la granularidad

Granularidad Diferente granularidad Un caso de uso puede describir: Un objetivo o propósito del usuario Una interacción con el sistema Un objetivo implica una o más interacciones. Construir un caso de uso por cada objetivo del usuario.

Granularidad (A. Cockburn) Caso de uso Ambito Sistema Funcionalidad requerida del sistema Organización Objetivo estratégico para la empresa, de mucho valor Especificidad Objetivo del usuario cdu Colecciones de objetivos de usuario cdu negocio Subfunciones inclusión de cdu Caso de uso del negocio

Granularidad (A. Cockburn) Especificidad Objetivo del usuario Tarea del usuario o “proceso de negocio elemental” Colecciones de objetivos de usuario Recoge casos de uso de usuario relacionados Subfunciones Un paso en la descripción de un caso de uso (validar, buscar, log on) Detalle de la interacción Interfaz de dialogo o Interfaz semántica

Tipos de casos de uso Según el nivel de detalle Según la importancia Breve : Descripción en unas pocas líneas Informal : Varios párrafos que cubren varios escenarios Expandido : Descripción detallada con una plantilla Según la importancia Primario, secundario u opcional Según el nivel de abstracción Esencial : ¿Qué hace el sistema? Concreto : Se contemplan detalles de implementación (GUI y tecnología)

Recomendaciones Especificar casos de uso no es una actividad de dibujar diagramas sino de escribir con el detalle necesario el flujo principal y los flujos alternativos: “centrado en la escritura en vez del dibujo” No hay que preocuparse demasiado por las relaciones entre casos de uso ni entre actores. El objetivo inicial es identificar los actores y a partir de sus objetivos encontrar los casos de uso, el diagrama de casos de uso es una ayuda visual. Los actores deben interactuar con el sistema

¿Qué granularidad es apropiada para un caso de uso? Recomendaciones ¿Qué granularidad es apropiada para un caso de uso? En un sistema de venta por internet, “Añadir producto al carro de la compra” “Introducir datos facturación” ¿son casos de uso? Deben ser objetivos del usuario Error común: no identificar como casos de uso las tareas que inicia el propio sistema “Anular reservas pasados quince días”

Cuidado con el empleo de la relación “include” Recomendaciones No incluir como caso de uso las operaciones CRUD sobre un objeto de negocio (alta, consulta, borrado, actualización): función del sistema aparte, excepto si se trata de operaciones relevantes para el sistema, como “registrar cliente” en un sistema de venta por internet Cuidado con el empleo de la relación “include” ¡NO HACER UNA DESCOMPOSICION FUNCIONAL! Escribir casos de uso independientes de la interfaz o de detalles de implementación, escribirlos a nivel esencial. ¿A qué nivel de detalle se describe un caso de uso? Primero informal, luego expandido

Recomendaciones Hay que comprobar que los casos de uso incluyen toda la funcionalidad del sistema. Preocupación por mantener la validez y consistencia del conjunto de casos de uso. Cada compañía debe tener un manual sobre uso de los casos de uso. Los casos de uso sólo consideran los requisitos funcionales del proyecto, hay que añadir los no-funcionales.

Referencias http://alistair.cockburn.us/usecases/usecases.html “Writing effective uses case”, Alistair Cockburn, Addison-Wesley, 2000 C. Larman, “UML y Patrones: Una introducción al análisis y diseño orientado a objetos y al proceso unificado”, Prentice-Hall, 2003.

Contenidos Presentación de UML Modelado Estructural Modelado del software Presentación de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases

Modelado estructural Se describen los tipos de objetos de un sistema y las relaciones estáticas que existen entre ellos. Clases Interfaces Relaciones de dependencia, realización, generalización y asociación (agregación, composición) También pueden incluir paquetes y colaboraciones Un diagrama de clase es una representación gráfica de un modelo estructural.

Modelado estructural Diferentes perspectivas. Modelado Conceptual Conceptos del dominio del problema: atributos, restricciones y relaciones entre ellos. Modelo del Análisis Clases que corresponden a conceptos del dominio Atributos y métodos Modelo de Diseño Incluye clases que corresponden a decisiones del diseño Modelo de Implementación Clases que corresponden a un lenguaje de programación

Modelo Conceptual

Del Modelo Conceptual a las clases Los modelos de análisis se obtienen a partir del modelo conceptual: Conceptos a clases Atributos de un concepto a atributos de la clase Añadir comportamiento (métodos)

Modelo de diseño

¿Modelo Conceptual o de Análisis?

Modelo de Comportamiento

Colaboración (parte estática)

Colaboración (parte dinámica)

Patrón de diseño (Parte Estática) Observer Update() Subject subjectState Attach() Detach() Notify() 1..* 1..1 +observers ConcreteSubject getState() setState() ConcreteObserver observerState update() +subject observerState= subject.getState() for all o in observers {o.update()}

Patrón de diseño (Parte dinámica)

Ingeniería directa e Inversa Transformar modelos en código en un lenguaje de programación determinado Ingeniería inversa Obtener un modelo a partir de código. Más difícil ya que hay pérdida de información al pasar de los modelos al código.

Atributos [visibilidad] nombre [: tipo] [= valor_inicial ] [{propiedades}] + = pública visibilidad # = protegida - = privada nombre: nombre del atributo tipo: tipo del atributo valor_inicial: valor inicial o por defecto propiedades: {frozen} {addOnly}

Atributos Nivel Conceptual: “Los clientes tienen un nombre” Nivel de Especificación: “El cliente puede almacenar y consultar su nombre” Nivel de Implementación: “Una instancia de Cliente tiene un campo de tipo String que almacena su nombre y un método que lo devuelve”

Operaciones [visibilidad] nombre [(lista_parametros)] [: tipo_retorno] [{propiedades}] + = pública visibilidad # = protegida - = privada nombre: nombre de la operación lista_parámetros: lista de parámetros separados por comas tipo retorno: tipo de valor devuelto por la operación propiedades: {isQuery}, {sequential}, {concurrent}

Operaciones Atributos Operaciones

Clases Parametrizadas G Tabla Clase Parametrizada count capacity put(G) «bind» <Empleado> item() : G Empleados Tabla<Cliente> Instanciación

Otras propiedades Clases y métodos diferidos Multiplicidad Variables y métodos de clase Figura rotar() trasladar() visualizar() <<abstract>>

Clases Estereotipadas Clases y valores etiquetados

Relaciones Dependencia Un cambio en la especificación de un elemento afecta a otro PlanDelCurso Curso Window añadir(c : Curso) position eliminar(c : Curso) parent children size Clock open() close() Nodo Lista move() resize() <<friend>>

Estereotipos para dependencias bind: entre una clase genérica y una instanciación friend: dependencia de clase amiga refine: relación de refinamiento use: relación de uso import: un paquete importa los elementos de otro. extend: para casos de uso include: para casos de uso

Relaciones Generalización “Es-un-tipo-de” Window TextWindow BoxDialog Cuenta Window CuentaAhorro CuentaCorriente TextWindow BoxDialog

Generalización Nivel Conceptual Nivel Especificación “Todas las instancias de CuentaCorriente son instancias de Cuenta” Nivel Especificación “La interfaz de CuentaCorriente incluye la interfaz de Cuenta” Principio Sustitución Nivel Implementación Herencia

Asociación Asociación Relación estructural que especifica que los objetos de un tipo están conectados con los de otro. +empleado +patron Persona Empresa 1..* 1..* * * impartido Curso Profesor * * 1..* 1..*

Asociaciones Agregación Caso especial de asociación Relación estructural parte-de Empresa 1..1 1..1 * * Departamento

Asociaciones Nivel Conceptual Nivel de Especificación Muestran la relación conceptual entre dos clases. “Un cliente tiene varios pedidos” Nivel de Especificación Representan responsabilidades Detectamos los mensajes del protocolo de una clase con respecto a la otra Nivel de Implementación Establecer atributos: navegabilidad

Asociaciones Especificación: class Pedido { public Cliente getCliente(); public Set getLineaPedido();... } Implementación private Cliente _cliente; private HashSet _lineasPedido; …}

Navegación Posibilidad de limitar la navegación a una sola dirección Determina si una clase de la asociación tiene “conocimiento” de la otra. Nivel de especificación o implementación

Visibilidad Pública: +propietario Protegida: #propietario Privada: -propietario +propietario -clave GrupoUsuarios Usuario Clave * * * * 1..1 1..1 * *

Asociaciones calificadas Nivel Conceptual: “Dentro del mismo pedido no pueden existir dos líneas con el mismo producto” Nivel Especificación: “El acceso a ItemPedido es indexado por productos” Nivel Implementación: “Se usa una tabla para almacenar las líneas de pedido”

Asociaciones calificadas Class Pedido { private Hashtable _lineasPedido; public ItemPedido getItemPedido(Producto unProducto); public void addItemPedido (Integer cantidad, Producto elProducto); … }

Agregación Dos criterios: Cuatro posibles tipos de agregación Dependencia: ¿La existencia de una parte va ligada a la del agregado? Exclusividad: ¿Una parte puede pertenecer a más de un agregado? Cuatro posibles tipos de agregación

Composición Es un caso particular de agregación: exclusiva y dependiente Las partes pueden crearse después del agregado compuesta al que pertenecen, pero una vez creadas viven y mueren con ella. La parte sólo puede formar parte de un agregado. El agregado gestiona la creación y destrucción de las partes. Las partes se pueden eliminar antes de eliminar el agregado.

Composición agregado /todo composición parte Ventana 1..1 1..1 * * Marco

Composición POLIGONO 1 Relleno:Diseño 1 {ordered} {ordered} 3..* Punto

Clases Asociación Una asociación que también es una clase Una clase asociación añade una restricción: “Sólo puede existir una instancia de la asociación entre cualquiera par de objetos participantes” No podríamos modelar que una persona tiene diferentes contratos para una misma compañía a lo largo del tiempo.

Ejemplo de clase asociación

Ejemplo de clase asociación

Asociaciones derivadas Asociación Derivada

Asociaciones derivadas Asociación Derivada

Restricciones para Asociaciones {or} {subconjunto}

Restricciones para Asociaciones operario empleado patrón Compañia * Persona * 0..1 0..1 jefe {Persona.patrón= Persona.jefe.patrón }

Realización Relación entre clasificadores, un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. <<Interface>> IPila Pila push() pop() top() Pila IPila

Clases Abstractas e Interfaces Interfaz Clase Abstracta

Clases Abstractas e Interfaces Interfaz

Paquetes Elemento organizativo Puede agrupar elementos de cualquier tipo. Un elemento es exclusivo a un paquete. Establece un espacio de nombres Posibilidad de anidar paquetes.

Importación/Exportación en paquetes “Los paquetes permiten controlar la complejidad del manejo de un gran número de abstracciones, controlando los accesos mediante la importación”. Relaciones de importación, acceso y generalización La parte pública de un paquete son sus exportaciones. Las partes públicas son visibles en los paquetes que importan al paquete contenedor. La importación no es transitiva. Los paquetes anidados pueden ver todo lo que ven los paquetes que los contienen.

<<import>> Cliente + FormularioPedido Servidor + FormularioDeSeguimiento + BaseDeDatos - Pedido + ServicioDeRegistro <<import>> Politicas + ReglasPedidos + GUI:Ventana <<import>> GUI + Ventana + Formulario # GestorEventos

Generalización de Paquetes GUI + Ventana + Formulario # GestorEventos WindowsGUI + GUI:Ventana MacGUI + Formulario # GUI:GestorEventos + VBForm

Paquetes Un paquete bien estructurado debe: ser cohesivo estar poco acoplado pocos anidamientos conjunto equilibrado de elementos

Uso de los paquetes

Uso de los paquetes Agrupar elementos relacionados para manejarlo en conjunto. Paquete “Clases e interfaces del modelo” Paquete “Interfaces de usuario” Paquete “Servicios base de datos” Paquete “Modelo del análisis” Un modelo es un paquete incluyendo todos los elementos que constituyen una particular vista del sistema modelado.

Sistema, modelo, vista, diagrama Un sistema es aquello que se está desarrollando y para lo que se crean modelos. Un sistema debe ser modelado desde dos puntos de vista: Modelar el problema: comprender el problema Modelar el producto a crear: diseñar la solución Modelado OO ofrece una correspondencia directa entre los dos puntos de vista, a través del concepto de “objeto”

Sistema, modelo, vista, diagrama Un modelo captura una vista de un sistema físico. Es una abstracción de ese sistema con cierto propósito, por ejemplo modelar su comportamiento en relación a unas personas que tienen determinado interés. Un modelo contiene todos los elementos de modelado necesarios, organizados en una jerarquía de paquetes/ subsistemas. Un modelo y sus elementos tienen una especificación. Un modelo y sus elementos se representan mediante diagramas, que expresan una vista del modelo.

Subsistema Un subsistema es una “unidad de comportamiento” en el sistema. Permite descomponer el sistema Un subsistema ofrece interfaces, tiene operaciones, y distingue entre especificación e implementación.

Vistas UML vocabulario ensamblado funcionalidad gestion conf. Vista de Implementacion Vista de Diseño comportamiento Vista de casos de uso Arquitectura: La visualización , especificacion , construcción y documentación de un sistema con gran cantidad de software requiere que el sistema sea visto desde varias perspectivas . La arquitectura de un sistema es quizás el artefacto mas importante que puede emplearse para manejar estos diferentes puntos de vista y controlar el desarrollo iterartivo e incremental de un sistema a lo largo de su ciclo de vida: La arquitectura es el conjunto de decisiones significativas sobre: La organización de un sistema de software La selección de elementos estructurales y sus interfaces a través de los cuales se constituye el sistema. Su comportamiento , como se especifica en las colaboraciones entre esos elementos El estilo arquitectónico que guía esta organización: los elementos estáticos y dinámicos y sus interfaces, sus colaboraciones y su composición. La arquitectura software no tiene que ver solamente con la estructura y el comportamiento ,sino también con el uso, la funcionalidad, el rendimiento, la capacidad de adaptación, la reutilización, la capacidad de ser comprendido, las restricciones económicas y de tecnología y los compromisos entre alternativas, así como los aspectos estéticos. Vista de Despliegue Vista de Procesos topología entrega distribución instalación Funcionamiento escalabilidad rendimiento Modelo de la Arquitectura de un sistema

Vistas UML clases interfaces colaboraciones componentes casos de uso Vista de Implementacion Vista de Diseño casos de uso Vista de casos de uso Vista de Despliegue Vista de Procesos clases activas nodos

Vistas UML Diagramas de componentes Diagramas de clase Diagrama de interacción Diagramas de estado Diagramas de clase Diagramas de interacción Diagramas de estado Vista de Implementación Vista de Diseño Diagramas de casos de uso Vista de casos de uso Vista de Despliegue Vista de Procesos Diagramas de despliegue Diagrama de interacción Diagramas de estado Diagramas de clase Diagramas de interacción Diagramas de estado

Diagrama de Objetos Modelan las instancias de los elementos contenidos en los diagramas de clases Muestra un conjunto de objetos y sus relaciones en un momento concreto Multiobjeto (colección de objetos anónimos) Enlace Objeto Se utilizan para modelar la vista de diseño estática o la vista de procesos estática de un sistema

Diagrama de Objetos Con UML, los diagramas de clases se utilizan para visualizar los aspectos estáticos de los bloques de construcción del sistema. Los diagramas de interacción se utilizan para ver los aspectos dinámicos del sistema , y constan de instancias de estos bloques y mensajes enviados entre ellos. Un diagrama de objetos contiene un conjunto de instancias de los elementos encontrados para en un diagrama de clases.Por tanto , un diagrama de objetos, expresa la parte estática de una interacción, consistiendo en los objetos que colaboran , pero sin ninguno de los mensajes enviados entre ellos. En ambos casos , un diagrama de objetos congela un instante el tiempo.

Contenidos Modelado del Comportamiento Diagramas de interacción Diagramas de actividades Máquinas de estado Modelado de la Implementación Diagramas de componentes Diagramas de despliegue Colaboraciones Formalización de UML: MOF y metamodelo

Enlaces y Asociaciones Un enlace es : una conexión semántica entre objetos. una instancia de una asociación. un camino por el cual enviar un mensaje enlace mensaje

Interacciones y Mensajes Interacción: Comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos dentro de un contexto para lograr un propósito. Mensaje: especificación de una comunicación entre objetos que transmite información, con la expectativa de desencadenar una actividad.

Modelado del comportamiento Se describe cómo los objetos colaboran entre sí para realizar cierta actividad. Se expresan mediante los diagramas de interacción: Diagramas de Secuencia y Diagramas de Colaboración. También se describe las máquinas de estado que caracterizan a los objetos Diagramas de estado Diagramas de actividades

Diagramas de Interacción Describen una interacción. Dos tipos: Diagramas de Secuencia y Colaboración Diagramas de Secuencia: Destacan la ordenación temporal de los mensajes Diagramas de Colaboración: Destacan la organización estructural de los objetos participantes. Equivalencia semántica

Diagramas de Secuencia Incluye: Objetos y su línea de tiempo Focos de control o activación Mensajes: a instancias o de creación Mensaje self ( especifica que el objeto correspondiente es visible porque es el emisor del mensaje) Información de control: condiciones ( entre corchetes)y marcas de iteración ( asterisco) Indicar el objeto devuelto por el mensaje: return (añadirlos sólo cuando ayuden a clarificar la interacción)

Mensajes Simple: metodo(arg) Creación de objetos: <<create>> Condición: [cond] metodo() Iteración: * metodo() Asignación: v:= getObjeto() Numeración jerárquica o secuencial o ninguna

Diagramas de Secuencia : : : Pedido : LineaPedido : Item InterfacePedido ControladorPedido 1: preparar() 2: preparar() 3: * preparar() 4: hayStock:=check() 5: [hayStock] eliminar() 6: pedir?:= necesarioPedir() 7: [pedir?] <<create>> : ItemPedido 8: 9: [hayStock] <<create>> : ItemEntregado

Diagramas de Colaboración

Diagrama de Secuencia Línea de vida tiempo Foco de control c:Cliente p:ProxyODBC <<create>> :Transaccion establecerAcciones establecerValores Línea de vida tiempo establecerValores exito <<destroy>> Foco de control

Diagrama de Colaboración 1: <<create>> 2: establecerAcciones 6: <<destroy>> c:Cliente :Transac cion 5: exito 3: establecerValores 4: establecerValores p:Proxy ODBC

Diagrama de Secuencia c:Cliente a:Ayuda Planificacion <<create>> :AgenteBilletes establecerItinerario(i) calcularRuta ruta <<destroy>> notificar

Diagrama de Colaboración

Numeración secuencial Confusión en el flujo de ejecución

Numeración jerárquica

Numeración jerárquica

Numeración jerárquica

Numeración jerárquica

Numeración jerárquica

Tipos de mensajes Simple Síncrono (llamada) Asíncrono Retorno Llamada de operación o flujo anidado de control Síncrono (llamada) El emisor espera hasta recibir el resultado Asíncrono El emisor no espera a recibir el resultado Retorno Indica el retorno de una llamada

Uso de los diagramas de interacción Modelado del aspecto dinámico. Modelado del flujo de control que caracteriza el comportamiento de un sistema: casos de uso colaboraciones patrones frameworks operaciones

Caso de Uso (Escenario) :ReceptorPedidos :AgenteTarjeta :GestionPedido :AgenteFacturacion : Cliente Credito enviarPedido procesarTarjeta tramitarPedido emitirFactura confirmarPedido

Caso de uso (Colaboración)

Caso de uso de negocio viajero: Empleado encargado: Empleado contable : Empleado pagador : Empleado solicitudPermisoViaje() PermisoViaje() informeGastos(unInforme) OKgastos(unInforme) solicitudPago(viajero)

Caso de uso de negocio

Diagramas de Secuencia vs. Diagramas de Colaboración Equivalencia semántica Simples para comportamientos simples. Si hay mucho comportamiento condicional, usar diferentes escenarios. Diagramas de secuencia muestran mejor el orden en que se ejecutan los mensajes Diagramas de colaboración muestran claramente los objetos con que interactúa un determinado objeto.

Diagramas de Actividades Muestran un flujo de actividades. Es un caso especial de máquina de estados. Incluye: estados actividad y estados acción transiciones objetos Una actividad produce alguna acción que produce algún cambio en el sistema o retorna un valor.

Estados Acción y Estados Actividad Un estado acción no se puede descomponer, representa una computación atómica. Un estado actividad no es atómico, se compone de otros estados acción y actividad. Al entrar se ejecuta la acción o actividad, al terminar el flujo de control pasa a la siguiente acción o actividad. Misma notación

Transiciones estado inicial transiciones estado final

Bifurcación

División y Unión división unión Preparar conversación Descomprimir Gesticular Mover boca Emitir audio unión Limpieza

Solicitar Producto Procesar Pedido Extraer Articulos Enviar Pedido Recibir Producto Facturar al cliente Pagar Factura Cerrar Pedido

Calles Almacen Ventas Cliente Solicitar Producto Procesar Pedido Extraer Articulos Enviar Pedido Recibir Producto Facturar al cliente Calles Pagar Factura Cerrar Pedido

Almacen Ventas Cliente Solicitar Producto Procesar Pedido Extraer Articulos o: Pedido [en progreso] Enviar Pedido Recibir Producto Facturar al cliente o: Pedido [completado] b: Factura [impagada] Pagar Factura Cerrar Pedido

Mucha información

Utilidad de los diagramas de actividades Modelado de flujos de trabajo (workflow) como son los procesos de negocio (business process). Se puede asociar a cualquier elemento de modelado, pero lo más normal es asociarlo a una operación: diagrama de flujo de las acciones.

Eventos Un evento es un acontecimiento que ocupa un lugar en el tiempo y espacio. Un evento es un estímulo que dispara una transición en una máquina de estados. Eventos externos vs. Eventos internos. Tipos de eventos: Señales (excepciones) Llamadas Paso de tiempo Cambio de estado

Señales

Modelado Excepciones Conjunto añadir() eliminar() Excepcion establecerManejador() primerManejador() ultimoManejador() <<exception>> Duplicado Overflow Underflow <<send>>

Estados Un estado es una situación en la vida de un objeto en la que satisface cierta condición, realiza alguna actividad o espera algún evento. Elementos de un estado Nombre Acciones entrada/salida Transiciones internas Subestados Eventos diferidos

Estados acción entrada acción entrada acción salida transición interna Rastreando acción entrada acción entrada entry/ activarModo(enRastreo) exit / activarModo(noRastreo) nuevoObjetivo/rastreador.adquirir do / seguirObjetivo autotest / defer acción salida transición interna actividad evento diferido

Transiciones Una transición de un estado A a un estado B, se produce cuando se origina el evento asociado y se satisface la condición especificada, en cuyo caso se ejecuta la acción de salida de A, la acción de entrada a B y la acción asociada a la transición. Elementos de una transición: Estados origen y destino Evento de disparo Condición de guarda Acción

Máquina de estados Especifica la secuencia de estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos, junto con sus respuestas a esos eventos. Útil si las instancias de una clase tienen un comportamiento que depende de su historia o que deben responder a eventos externos: objetos reactivos. Se representa mediante un diagrama de estados.

After (2 sec) send c.estaActivo ruido Inactivo Buscando Configuración objetivoEn(p) [representaAmenaza] / t.añadirObjetivo(p) Rastreando Acoplamiento contactar

Diagrama de Estado (Caso de Uso)

Diagrama de Estado (Caso de Uso)

Subestados secuenciales introducirTarjeta entry/leerTarjeta exit/expulsarTarjeta Activo Inactivo Validación [continuar] cancelar mantener Selección Procesando Mantenimiento [no continuar] Impresión

Subestados concurrentes Mantenimiento Pruebas mantener Probar perifericos AutoDiagnosis Inactivo Manejo Ordenes [continuar] Espera Orden Pulsar tecla [no continuar]

Subestados Concurrentes

Contenidos Modelado del Comportamiento Diagramas de interacción Diagramas de actividades Máquinas de estado Modelado de la Implementación Diagramas de componentes Diagramas de despliegue Colaboraciones Formalización de UML: MOF y metamodelo

Componentes Un componente es una parte física y reemplazable de un sistema, que conforma con un conjunto de interfaces y proporciona su implementación. Modela artefactos tales como: ejecutables, bibliotecas, tablas, ficheros, documentos,.. Representa el empaquetamiento físico de elementos lógicos tales como clases, interfaces,.. Residirán en los nodos del sistema Estereotipos: executable, library, file, table, document

Componentes (UML 1.5) “Es una parte de un sistema reemplazable, modular y desplegable que encapsula una implementación y expone un conjunto de interfaces. Normalmente especificado por uno o más clasificadores (clases, interfaces, tipo de dato,..) que residen en el componente, y un conjunto de ellos define su interfaz externa. Conforma a las interfaces que expone al exterior, y puede ser implementado por un fichero binario, ejecutable o script. Puede ser desplegado sobre un nodo”

Propiedades de un componente Es una unidad de despliegue independiente. Puede ser conectado con otros componentes En una aplicación dada existirá una única copia Es una parte sustituible de un sistema (conforma con una interfaz) Realiza una función bien definida (cohesión física y lógica) Abarca más de una colaboración de clases Existe en el contexto de una arquitectura bien definida. Presupone una infraestructura tecnológica en la que se piensa utilizar

Propiedades de un componente Interfaz Componente Interfaz soportada Especificación Componente 1..* * 1 realización * Implementación Componente 1 instalación * Instancia Componente instancia Instalación Componente * 1

Componentes Realiza agenteFraudes politicaFraudes busquedaPatrones agenteFraudes.dll Realiza agenteFraudes politicaFraudes busquedaPatrones

Componentes El componente arbol.java puede ser reemplazado por otro explorador.java arbol.java JerarquíaElementos El componente arbol.java puede ser reemplazado por otro que proporcione la interfaz JerarquíaElementos.

Componentes

Tipos de componentes Despliegue Productos del trabajo De ejecución Necesarios y suficientes para formar un sistema ejecutable: librerías dinámicas (dll), ejecutables (exe),.. Productos del trabajo Permanecen al final del proceso de desarrollo: archivos código fuentes, ficheros de datos,.. Con ellos se crean los componentes de despliegue De ejecución Se crean durante la ejecución: objeto COM, instanciado a partir de una dll.

Diagrama de Componentes Modelado de ejecutables y bibliotecas Modelado de código fuente Modelado de una API

Modelado de ejecutables

Componentes (UML 2.0) “Es una parte modular de un sistema que encapsula su contenido y cuya manifestación se puede reemplazar en su entorno” Define su comportamiento en términos de las interfaces que requiere y proporciona. Puede actuar como un tipo. Es una unidad auto-contenida que encapsula el estado y comportamiento de clasificadores (cdu, clases, interfaces)

Componentes (UML 2.0) Interfaces requeridas Interfaces proporcionadas

Interfaz proporcionada Componentes (UML 2.0) Interfaz requerida Interfaz proporcionada

Componentes (UML 2.0)

Componentes (UML 2.0)

Nodos Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional que puede tener memoria y capacidad de procesamiento. Los componentes se ejecutan en nodos Los nodos representan el despliegue físico de los componentes.

Diagramas de Despliegue Muestra la configuración de los nodos que participan en la ejecución y de los componentes que residen en los nodos. Incluye nodos y arcos que representan conexiones físicas entre nodos. Modelado de sistemas empotrados, sistemas cliente-servidor, sistemas distribuidos.

Diagrama de Despliegue

internet <<red>> red local Modem <<procesador>> <<procesador> servidor cache servidor cache <<red>> red local <<procesador> <<procesador> <<procesador>> <<procesador>> servidor servidor servidor servidor principal

Contenidos Modelado del Comportamiento Diagramas de interacción Diagramas de actividades Máquinas de estado Modelado de la Implementación Diagramas de componentes Diagramas de despliegue Colaboraciones Formalización de UML: MOF y metamodelo

Colaboraciones Sociedad de clases, interfaces y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de los elementos. Parte estructural (diagrama de clases) y parte de comportamiento (diagrama de secuencia).

Colaboraciones El núcleo de la arquitectura de un sistema está formado por un conjunto de colaboraciones que representan las decisiones de diseño más importantes. Un sistema orientado a objetos bien estructurado se compone de un conjunto relativamente pequeño de colaboraciones. Modelado de un caso de uso, operación o mecanismo (patrón o framework)

Casos de uso y Colaboraciones caso de uso colaboración Hacer Pedido Gestión Pedidos realización

Ejercicio Diseña una colaboración de un mecanismo Object Trading que separa la representación de una información de su presentación y edición; las clases que representan a los objetos información no conocen a las clases que representan editores y viceversa. Un mismo editor puede editar diferentes tipos de información y una misma información puede ser editada por diferentes editores. El propósito del mecanismo es seleccionar un editor que colaborará adecuadamente con el objeto información, creará un objeto editor y lo ligará con el objeto información. Un objeto cliente solicitará a un objeto Trader editar cierta información.

Mecanismo trading (Parte estática)

Mecanismo trading (Comportamiento) : ClienteDeGestor : Trader : FactoriaEditor info : ObjetoInformacion : Editor editar(info) * i:= getInterfaz() p:= soportaInterfaz(i) [p] crearEditor(info) <<create>> ¿Clases Cliente, Editor y ObjetoInformacion?

Mecanismo trading (Comportamiento) ¿Clases Cliente, Editor y ObjetoInformacion?

Colaboraciones Parametrizadas Modelado de patrones de diseño Observer Subject Alarma Ventana

Patrón de diseño (Parte Estática) Subject subjectState +observers Observer Attach() 1..1 1..1 1..* 1..* Update() Detach() Notify() for all o in observers {o->update} ConcreteSubject ConcreteObserver subjectState +subject observerState observerState= getState() update() subject->getState() setState()

Patrón de diseño (Parte dinámica)

Contenidos Modelado del Comportamiento Diagramas de interacción Diagramas de actividades Máquinas de estado Modelado de la Implementación Diagramas de componentes Diagramas de despliegue Colaboraciones Formalización de UML: MOF y metamodelo

Lenguajes OMG MOF (Meta Object Facility) UML OCL AS (Action Semantics) Definir semántica de modelos de comportamiento Muy bajo nivel No define una sintaxis concreta

Lenguajes OMG Perfiles UML (Profiles) Subconjunto de UML con extensiones para un dominio concreto Perfiles estándar OMG: EDOC, Corba, EAI,.. QVT (Query, Views,Transformations) Lenguaje estándar para definir transformaciones

Metamodelo UML ¿Cómo se define formalmente un lenguaje de modelado? UML es definido con un metamodelo escrito es un metalenguaje, MOF. Los cuatro niveles de modelado del OMG Nivel MO: el sistema Nivel M1: el modelo del sistema Nivel M2: el modelo del modelo Nivel M3. el modelo de M2

Arquitectura de cuatro capas del OMG

Metamodelo UML Nivel M0 Nivel M1 Nivel M2 Nivel M3 Sistema de pedidos por internet Nivel M1 Un modelo estructural que incluye un diagrama de clases UML Clase Pedido con atributos fecha y producto Nivel M2 Metamodelo Especificación de clase o atributo UML Nivel M3 Metametamodelo (Lenguaje estándar MOF)

Arquitectura de cuatro capas del OMG

Metamodelo UML

MOF Proporciona conceptos y herramientas para razonar sobre lenguajes de modelado y transformaciones. Repositorio MOF Define un formato de intercambio para modelos de M1 llamado XMI (XML Metadata Interchange), basado en XML.

MDA (Model Driven Architecture) Nuevo paradigma de desarrollo de software (noviembre, 2000): Desarrollo dirigido por el modelado Ingeniería de modelos Artefactos del proceso de desarrollo Modelo Independiente de la Plataforma, PIM Modelo Específico de la Plataforma, PSM Código

MDA “MDA separa la especificación de la funcionalidad del sistema de la especificación de la implementación de esa funcionalidad sobre una plataforma específica, y proporciona un conjunto de guías para estructurar especificaciones expresadas como modelos” “ El paradigma MDA y los estándares que lo soportan permiten especificar en un modelo la funcionalidad del sistema que debe ser realizada sobre diferentes plataformas mediante mappings estándar para cada plataforma, y permite que diferentes aplicaciones puedan ser integradas relacionando explícitamente sus modelos, permitiendo integración e interoperabilidad y soportar la evolución del sistema conforme las tecnologías van cambiando”

PIM y PSM PIM describe la funcionalidad de un sistema software (nivel de captura de requisitos y análisis). PSM incorpora al PIM los aspectos relacionados con la plataforma (nivel de diseño). Un PIM puede transformarse en uno o más PSM para una misma aplicación

PIM

Transformaciones de modelos TMM TMC PIM PSM Código L2 L3 L1 Definición Transformación Definición Transformación

OCL (Object Constraint Language ) Lenguaje de especificación para escribir expresiones sobre modelos, p.e. queries, reglas de derivación de atributos, el cuerpo de operaciones de consulta, pre y postcondiciones o el invariante, guardas. Extiende la potencia expresiva de UML y permite crear modelos más precisos y más completos. Es tipado, cada expresión OCL tiene un tipo. Utilizado para escribir las restricciones

Expresiones OCL context c : Company inv enoughEmployees: c.numberOfEmployees > 50 context Company inv: self.employee.select(p : Person | p.age > 50)->notEmpty() context Person::getCurrentSpouse() : Person pre: self.isMarried = true body: self.mariages->select( m | m.ended = false ).spouse

Expresiones OCL context Job inv: self.employer.numberOfEmployees >= 1 inv: self.employee.age > 21 context Person::birthdayHappens() post: age = age@pre + 1 context Company::hireEmployee(p : Person) post: employees = employees@pre->including(p) and stockprice() = stockprice@pre() + 10

Profiles UML (Perfiles) Mecanismo de especialización. Un profile (perfil) define una forma específica de usar UML. Agrupación de un conjunto de estereotipos, valores etiquetados y restricciones, con su correspondiente notación para adaptar UML a un dominio concreto: EJB, aplicaciones web, CORBA, modelado del negocio,...

Perfiles UML Un perfil define un metamodelo mediante la especialización de un subconjunto del metamodelo de UML. Usados como lenguajes de un PSM Dos alternativas para extender UML Definir un perfil Un nuevo lenguaje definido con MOF (por ejemplo CWM)

Perfiles UML Profile = Packages • Estereotipos definir nuevas meta-clases • Valores etiquetados definir nuevos meta-atributos y nuevas asociaciones • Definir restricciones • Modelar gráficamente los perfiles

Ejemplo de definición de Perfil UML “Modelar conexiones entre elementos de un sistema de información conectados según la topología estrella”

Ejemplo de definición de un Perfil UML

Ejemplo Perfil UML Estereotipos Valores etiquetados

Ejemplo de definición de un Perfil UML context MyTopology::MainNode inv : self.localnodes ->forAll (n : Node | n.location = self.location) inv: self.target ->forAll(n : MainNode | n.location <> self.location ) context UML::InfrastructureLibrary::Core::Constructs::Class inv : self.isStereotyped(“Node”) implies self.connection->select(isStereotyped(“LocalEdge”))->size = 1 and self.connection->select(isStereotyped(“Edge”))->isEmpty context UML::InfrastructureLibrary::Core::Constructs::Association inv : self.isStereotyped(“LocalEdge”) implies self.connection->select(participant.isStereotyped(“Node”) or participant.isStereotyped(“MainNode”) ) -> forAll(n1, n2 | n1.location = n2.location) self.connection-> exists(participant.isStereotyped(“MainNode”) and multiplicity.min=1 and multiplicity.max=1) inv : self.isStereotyped(“Edge”) implies self.connection->select(participant.isStereotyped(“Node”))->isEmpty and self.connection->select(participant.isStereotyped(“MainNode”) ) -> forAll(n1, n2 | n1.location <> n2.location)

Uso de un Perfil UML