El Lenguaje Unificado de Modelado, UML

Presentación del tema: "El Lenguaje Unificado de Modelado, UML"— Transcripción de la presentación:

1 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

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

3 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

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

5 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.

6 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

7 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!

8 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 (principios de 2005)

9 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

10 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.

11 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

12 ¿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”

13 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.

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

15 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”

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

17 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.

18 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.

19 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.

20 ¿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?

21 ¿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?

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

23 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

24 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

25 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

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

27 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

28 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

29 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.

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

31 Relaciones Dependencia Asociación patron empleado Generalización
* Asociación patron empleado Generalización Realización

32 Ejemplo

33

34 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

35 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

36 Diagrama de actividades
Modelo del Negocio Diagrama de actividades

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

38 Diagrama de clases Modelo Estructural

39 Diagrama de colaboración
Modelo de Comportamiento

40 Máquina de Estado Diagrama de estado

41 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.

42 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

43 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

44 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 }

45 Ejemplo Estereotipo predefinido
Clase Clase estereotipada

46 Ejemplo Estereotipo Predefinido
Clase estereotipada

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

48 ¡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)

49 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

50 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

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

52 Organización en Paquetes
java HolaMundo Applet awt lang

53 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

54 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

55 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

56 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.

57 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

58 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]

59 Ejemplo Caso de Uso actor caso de uso asociacion

60 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

61 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.

62 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

63 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.

64 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.

65 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.

66 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.

67 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.

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

69 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.

70 Ejemplo diagrama de casos de uso

71 Ejemplo diagrama de casos de uso
Actores Secundario Actor Principal

72 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

73 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).

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

75 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”

76 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

77 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

78 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”.

79 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.

80 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.

81 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

82 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 Ingeniero mantenimiento comprueba elementos en la red || Ingeniero mantenimiento envía informe fallo 4. Operador cierra sesión

83 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 ...

84 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

85 ¿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.

86 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

87 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

88 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.

89 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

90 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

91 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)

92 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

93 ¿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”

94 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

95 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.

96 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.

97 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

98 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.

99 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

100 Modelo Conceptual

101 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)

102 Modelo de diseño

103 ¿Modelo Conceptual o de Análisis?

104 Modelo de Comportamiento

105 Colaboración (parte estática)

106 Colaboración (parte dinámica)

107 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()}

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

109 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.

110 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}

111 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”

112 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}

113 Operaciones Atributos Operaciones

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

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

116 Clases Estereotipadas
Clases y valores etiquetados

117 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>>

118 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

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

120 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

121 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..*

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

123 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

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

125 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

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

127 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”

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

129 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

130 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.

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

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

133 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.

134 Ejemplo de clase asociación

135 Ejemplo de clase asociación

136 Asociaciones derivadas
Asociación Derivada

137 Asociaciones derivadas
Asociación Derivada

138 Restricciones para Asociaciones
{or} {subconjunto}

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

140 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

141 Clases Abstractas e Interfaces
Interfaz Clase Abstracta

142 Clases Abstractas e Interfaces
Interfaz

143 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.

144 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.

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

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

147

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

149 Uso de los paquetes

150 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.

151 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”

152 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.

153 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.

154

155

156 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

157 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

158 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

159 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

160 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.

161 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

162 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

163 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.

164 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

165 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

166 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)

167 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

168 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

169 Diagramas de Colaboración

170 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

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

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

173 Diagrama de Colaboración

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

175 Numeración jerárquica

176 Numeración jerárquica

177 Numeración jerárquica

178 Numeración jerárquica

179 Numeración jerárquica

180 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

181

182

183 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

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

185 Caso de uso (Colaboración)

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

187 Caso de uso de negocio

188 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.

189 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.

190 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

191 Transiciones estado inicial transiciones estado final

192 Bifurcación

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

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

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

196 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

197 Mucha información

198

199 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.

200 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

201 Señales

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

203 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

204 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

205 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

206 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.

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

208 Diagrama de Estado (Caso de Uso)

209 Diagrama de Estado (Caso de Uso)

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

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

212 Subestados Concurrentes

213 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

214 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

215 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”

216 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

217 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

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

219 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.

220 Componentes

221 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.

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

223 Modelado de ejecutables

224 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)

225 Componentes (UML 2.0) Interfaces requeridas Interfaces proporcionadas

226 Interfaz proporcionada
Componentes (UML 2.0) Interfaz requerida Interfaz proporcionada

227 Componentes (UML 2.0)

228 Componentes (UML 2.0)

229 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.

230 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.

231 Diagrama de Despliegue

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

233

234 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

235 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).

236 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)

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

238 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.

239 Mecanismo trading (Parte estática)

240 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?

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

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

243 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()

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

245 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

246 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

247 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

248 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

249 Arquitectura de cuatro capas del OMG

250 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)

251 Arquitectura de cuatro capas del OMG

252 Metamodelo UML

253 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.

254 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

255 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”

256 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

257 PIM

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

259 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

260 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

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

262 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,...

263 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)

264 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

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

266 Ejemplo de definición de un Perfil UML

267 Ejemplo Perfil UML Estereotipos Valores etiquetados

268 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)

269 Uso de un Perfil UML