UML.

Presentación del tema: "UML."— Transcripción de la presentación:

1 UML

2 I. Introducción: UML Situación de Partida Diversos métodos y técnicas OO, con muchos aspectos en común pero utilizando distintas notaciones Inconvenientes para el aprendizaje, aplicación, construcción y uso de herramientas, etc. Pugna entre distintos enfoques (y correspondientes gurús) Establecer una notación estándar

3 I. Introducción: UML Historia de UML Comenzó como el “Método Unificado”, con la participación de Grady Booch y Jim Rumbaugh. Se presentó en el OOPSLA’95 El mismo año se unió Ivar Jacobson. Los “Tres Amigos” son socios en la compañía Rational Software. Herramienta CASE Rational Rose

4 … Historia de UML UML 2.0 2001-2003 2000 UML 1.4 1999 UML 1.3 1998
I. Introducción: UML … Historia de UML UML 2.0 2000 UML 1.4 1999 UML 1.3 Revisiones menores 1998 UML 1.2 Nov ‘97 UML aprobado por el OMG

5 Participantes en UML 1.0 MCI Systemhouse Microsoft ObjecTime
I. Introducción: UML Participantes en UML 1.0 MCI Systemhouse Microsoft ObjecTime Oracle Corp. Platinium Technology Sterling Software Taskon Texas Instruments Unisys Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson) Digital Equipment Hewlett-Packard i-Logix (David Harel) IBM ICON Computing (Desmond D’Souza) Intellicorp and James Martin & co. (James Odell)

6 Que es UML El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de modelar cosas: procesos de negocio funciones de sistema escribir clases en un lenguaje determinado Concretas esquemas de base de datos componentes de software reusables. UML es una especificación de notación orientada a objetos. Se basa en las anteriores especificaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto Conceptuales

7 Ventajas UML es estándar.
UML introduce nuevos diagramas que representa una visión dinámica del sistema. Permite darse cuenta en la fase de diseño de problemas en la fase de estructura al propagar errores o de las partes que necesitan ser sincronizadas y el estado de cada una de las instancias en cada momento. Su utilización es independiente del lenguaje de programación y de las características de los proyectos. UML ha sido diseñado para modelar cualquier tipo de proyectos tanto informáticos como de arquitectura

8 I. Introducción: UML … Ventajas Un lenguaje de propósito general para el modelado orientado a objetos UML combina notaciones provenientes desde: Modelado Orientado a Objetos Modelado de Datos Modelado de Componentes Modelado de Flujos de Trabajo (Workflows) Documento “OMG Unified Language Specification”, (versión 1.3, 808 páginas, 8 de Julio de 1999 y versión 1.4, 582 páginas, 1 de Noviembre de 2000) Resumen Semántica (185 páginas) Guía de Notación (173 páginas) Profiles Estándares Definición de Interfaz CORBAfacility Especificación DTD de XMI Especificación del Object Constraint Language Elementos Estándar de UML Glosario de Modelado del OMG 9

9 UML “aglutina” enfoques OO
I. Introducción: UML UML “aglutina” enfoques OO Rumbaugh Booch Jacobson Odell Meyer Pre- and Post-conditions Shlaer-Mellor UML Object life cycles Harel State Charts Gamma et. al. Frameworks, patterns, notes Embly Wirfs-Brock Singleton classes Fusion Responsabilities Operation descriptions, message numbering

10 Aspectos Novedosos Definición semi-formal del Metamodelo de UML
I. Introducción: UML Aspectos Novedosos Definición semi-formal del Metamodelo de UML Mecanismos de Extensión en UML: Stereotypes Constraints Tagged Values Permiten adaptar los elementos de modelado, asignándoles una semántica particular Stereotype = Estereotipo Constraint = Restricción de Integridad Tagged Values = Valores Etiquetados, es un par (nombre propiedad, valor) Los mecanismos de extensión pueden usarse para: Añadir nuevos elementos de modelado sin crear nuevos símbolos. En este caso el símbolo existente estará etiquetado con el correspondiente estereotipo. Esto permite que el metamodelo de UML no se vea alterado. Definir extensiones necesarias en un proceso de desarrollo o lenguaje de implementación específico. Asignar una semántica particular o información no semántica a elementos de modelado. Las restricciones de integridad pueden escribirse usando un lenguaje específico para representar restricciones (tal como OCL, Object Constraint Language, que expresa restricciones mediante fórmulas bien formadas, desarrollado por IBM) u otros lenguajes (por ejemplo, un determinado lenguaje de programación) o incluso en lenguaje natural. Tipos de enfoques: no-formales, semi-formales y formales Las principales mejoras al utilizar métodos formales son: Mayor rigor en la especificación Mejores condiciones para realizar la verificación y validación Mejores condiciones para automatización de procesos para la generación automática de prototipos y/o código final

11 I. Introducción: UML Inconvenientes en UML Definición del proceso de desarrollo usando UML. UML no es una metodología Falta integración con respecto de otras técnicas tales como patrones de diseño, interfaces de usuario, documentación, etc. Ejemplos aislados “Monopolio de conceptos, técnicas y métodos en torno a UML”

12 I. Introducción: UML Perspectivas de UML UML será el lenguaje de modelado orientado a objetos estándar predominante los próximos años Razones: Participación de metodólogos influyentes Participación de importantes empresas Aceptación del OMG como notación estándar Evidencias: Herramientas que proveen la notación UML “Edición” de libros Congresos, cursos, “camisetas”, etc.

13 Breve recorrido por UML

14 II. Breve Tour por UML Modelos y Diagramas Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle. Diagrama: una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos OMG UML 1.4 Specification

15 II. Breve Tour por UML … Modelos y Diagramas Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos ... Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos

16 Diagramas de UML Diagrama de Casos de Uso Diagrama de Clases
II. Breve Tour por UML Diagramas de UML Diagrama de Casos de Uso Diagrama de Clases Diagrama de Objetos Diagramas de Comportamiento Diagrama de Estados Diagrama de Actividad Diagramas de Interacción Diagrama de Secuencia Diagrama de Colaboración Diagramas de implementación Diagrama de Componentes Diagrama de Despliegue El Diagrama de Objetos en realidad no se provee como un tipo de diagrama separado. En Diagramas de Secuencia, Diagramas de Colaboración y en Diagramas de Actividad se modelan objetos. He visto en algunos libros referirse a Diagramas de Paquetes, Diagramas de Subsistemas y Diagramas de Modelos. Sin embargo, éstos corresponden a casos particulares de los diagramas arriba mencionados, cuando en éstos sólo se incluye paquetes (o subsistemas, o modelos, respectivamente).

17 II. Breve Tour por UML ... Diagramas de UML Los diagramas expresan gráficamente partes de un modelo Use Case Diagrams Diagramas de Casos de Uso Scenario Colaboración State Componentes Component Distribución Objetos Estados Secuencia Clases Actividad Modelo

18 Diagramas Estáticos Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los más comunes y dan una vista estática del proyecto. Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visión de casos reales. Diagrama de componentes: Muestran la organización de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones.

19 … Diagramas Estáticos Diagrama de despliegue: Muestra los nodos y sus relaciones. Un nodo es un conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas de clases y componentes de un gran sistema. Sirve como resumen e índice. Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen entre acciones (casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.

20 Diagramas Dinámicos Diagrama de secuencia, Diagrama de colaboración: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin perdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción. Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos.

21 … Diagramas Dinámicos Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.

22 Diagramas Recomendados
Los diagramas a representar dependerán del sistema a desarrollar, para ello se efectúan las siguientes recomendaciones dependiendo del sistema. Aplicación monopuesto Diagrama de casos de uso. Diagrama de clases. Diagrama de interacción. Aplicación monopuesto, con entrada de eventos: Añadir: Diagrama de estados. Aplicación cliente servidor: Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad. Aplicación compleja distribuida: Todos.

23 Organización de Modelos
II. Breve Tour por UML Organización de Modelos 4+1 vistas de Kruchten (1995) Vista de Diseño Vista de Implementación Vista de los Casos de Uso Vista de Procesos Vista de Despliegue

24 … Organización de Modelos
Las vistas existentes en UML son: Vista de casos de uso: Se forma con los diagramas de casos de uso, colaboración, estados y actividades. Vista de diseño: Se forma con los diagramas de clases, objetos, colaboración, estados y actividades. Vista de Procesos: Se forma con los diagramas de la vista de diseños, recalcando las clases y objetos referentes a procesos. Vista de Implementación: Se forma con los diagramas de componentes, colaboración, estados y actividades. Vista de despliegue: Se forma con los diagramas de despliegue, interacción, estados y actividades

25 … Organización de Modelos
II. Breve Tour por UML … Organización de Modelos Propuesta de Rational Unified Process (RUP) M. de Casos de Uso del Negocio (Business Use-Case Model) M. de Objetos del Negocio (Business Object Model) M. de Casos de Uso (Use-Case Model) M. de Análisis (Analysis Model) M. de Diseño (Design Model) M. de Despliegue (Deployment Model) M. de Datos (Data Model) M. de Implementación (Implementation Model) M. de Pruebas (Test Model)

26 Casos de uso Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje Se trata de la descripción de escenarios o situaciones posibles donde se pone de relieve el comportamiento del sistema ante su uso por parte del usuario. Así pues, los objetivos principales de la realización de casos de uso son: Definir el límite entre el sistema a desarrollar y los elementos externos a ese sistema (actores usuarios del sistema). Capturar el conjunto de funcionalidades y comportamientos del sistema a desarrollar.

27 Conceptos Básicos En el modelado de casos de uso debemos tener en
cuenta dos conceptos básicos: Actores . Casos de Uso. Actores. Los actores pueden ser personas, software o hardware; el término actor Representa el rol genérico de usuario del sistema. El nombre que se le dé a un actor deberá reflejar el papel que tendrá para el sistema. Actor Caso de Uso

28 … Conceptos Básicos Identificar los actores nos permite:
Definir los límites del sistema (qué forma parte del sistema y qué no). Desarrollar un sistema orientado al usuario que contemple todas las funcionalidades esperadas por los diferentes actores.

29 … Conceptos Básicos Casos de uso.
Reflejan el uso que harán los actores del sistema; se muestran a través de ellos tanto las funcionalidades que ofrecerá el sistema, como los diferentes comportamientos posibles inherentes a las situaciones contempladas para cada una de estas. Los casos de uso pueden estar relacionados con actores o con otros casos de uso; gráficamente una relación vendrá dada por una línea entre los casos de uso y/o actores relacionados, siendo que el extremo de dicha línea dependerá del tipo de relación.

30 Diagramas de casos de uso.
RELACIONES. Asociación.- Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple. Dependencia o Instanciación.- Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada. Generalización.- Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

31 Relaciones Relación <<include>>.
Es una simple relación de inclusión, es decir, los escenarios o situaciones posibles detalladas en un caso de uso están incluidas en otro caso de uso (aquel del que, gráficamente, parte la flecha). Relación <<extend>>. Este tipo de relación refleja situaciones particulares en un caso de uso que pueden ser tratadas (extendidas) por otro. En la descripción del caso de uso que es extendido debe haber una forma de indicar en que punto entra en juego el caso de uso que lo extiende (punto de extensión); esto se representa mediante una "etiqueta" (un texto significativo entre paréntesis) como referencia del lugar donde entraría a formar parte del caso de uso extendido.

32 … Relaciones

33 Flujos de Eventos Hasta aquí hemos tenido encuenta principalmente la representación gráfica, sin embargo, aparte de esta, un diagrama de casos de uso llevará asociada una descripción textual, en forma de flujos de eventos, de cada caso de uso representado. Surgen aquí dos tipos de apartado a tener en consideración: Flujo de eventos principal Se trata de una descripción de los eventos que van aconteciendo en el uso habitual, es decir, cuando no se presenta ningún tipo de problema (es el denominado happy path). Flujo de eventos excepcional Podemos encontrar tantos apartados de este tipo como situaciones excepcionales se puedan plantear, siendo que para cada uno de estos escenarios atípicos se definirá el flujo de eventos correspondiente.

34 Ejemplos

35 En el paquete tipos de venta:
… Ejemplos En el paquete tipos de venta:

36 … Ejemplos

37 … Ejemplos