Lenguaje Unificado de Modelado

1. Lenguaje Unificado de Modelado

2. AGENDA • Introducción • Diagramas UML • Clasificación • Diagramas de Estructura • Diagramas de Comportamiento • Vista y Diagramas • Elementos Generales • Vista de Usuario • Diagramas de casos de Uso • Escenarios de los Casos de Uso • Vista Estructural • Representación de clases y Objetos • Notación • Asociaciones y Enlaces • Asociaciones y Multiplicidad • Asociaciones Complejas • Relaciones Lógicas • Herencia • Polimorfismo • Agregación • Propagación y Delegación • Clases Abstractas e interfaces

3. AGENDA • Vista de Comportamiento (Modelo dinámico) • Diagramas de Secuencia • Diagramas de Colaboración • Diagramas de Estado • Diagramas de Actividad • Vista de Implementación • Diagramas de Componentes • Cohesion y Coupling • Vista de Ambiente • Diagramas de Despliegue

4. Introducción a UMLLenguaje Unificado de Modelado

5. Modelado • En la gestión del proceso de software: • Construimos modelos para comunicar la arquitectura y el comportamiento deseado del sistema. • Construimos modelos para visualizar y controlar la arquitectura del sistema. • Construimos modelos para comprender mejor el sistema que estamos construyendo, muchas veces descubriendo posibilidades de simplificación y reutilización. • En general se puede decir que construimos modelos para minimizar el riesgo: • Los modelos nos ayudan a visualizar como es que queremos que sea un sistema • Los modelos nos permiten especificar la estructura o el comportamiento de un sistema. • Los modelos nos proporcionan plantillas que nos guían en la construcción de un sistema • Los modelos documentan la decisiones que hemos adoptado

6. Modelado • Un modelo es básicamente una abstracción que incluye lo esencial de un problema complejo o estructura, filtrando los detalles no esenciales, de forma que el problema se hace más compresible. • Los modelos nos ayudan a organizar, visualizar, comprender y crear sistemas complejos • La importancia de la realización de un modelado formal es que las bases del modelado son comunes lo que conlleva a una comunicación no ambigua entre los individuos que forman parte del proyecto e incluso con los usuarios. • Siendo un modelo una abstracción de la realidad, dicha simplificación no es única, muy al contrario todo sistema debería ser visto desde diferente perspectivas utilizando diferentes modelos. • UML nos permite la construcción de diferentes modelos del mismo sistema de software .

7. Triangulo de éxito de la ejecución de un proyecto de software ALCANCE NOTACION C TIEMPO COSTO EXITO PROCESO HERRAMIENTA

8. Lenguaje Unificado de Modelado • UML Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad • Es un lenguaje gráfico para visualizar, especificar, construir y documentar los artefactos un sistema de software. • UML ofrece un estándar para describir un "plano" del sistema (modelo). • UML incluye: • Aspectos conceptuales tales como procesos de negocio y funciones del sistema • Aspectos concretos como expresiones de lenguajes de programación • Esquemas de bases de datos • Componentes reutilizables.

9. Para comprender qué es el UML, basta con analizar cada una de las palabras que lo componen, por separado • Lenguaje: El UML es, precisamente, un lenguaje. Lo que implica que éste cuenta con una sintaxis y una semántica. Por lo tanto, al modelar un concepto en UML, existen reglas sobre cómo deben agruparse los elementos del lenguaje y el significado de esta agrupación. • Modelado: El UML es visual, mediante su sintaxis se modelan distintos aspectos del mundo real, que permiten una mejor interpretación y entendimiento de éste. • Unificado: Unifica varias técnicas de modelado en una única. Ya que el UML proviene de técnicas orientadas a objetos, se crea con la fuerte intención de que este permita un correcto modelado orientado a objetos.

10. Lenguaje Unificado de Modelado • Se puede aplicar en el desarrollo de software • Ofrece gran variedad de formas para dar soporte a una metodología de desarrollo de software (como el Proceso Unificado Racional o RUP) • UML no es un lenguaje de programación • Es un conjunto de diagramas que pueden ser usados para especificar, construir, visualizar y documentar diseños de software. • UML no es un proceso de cómo hacer análisis y diseño, UML solo es un conjunto de herramientas que se usan en el proceso. • Fue creado con el objetivo de crear un nuevo estándar para el modelamiento de software.

11. Breve Reseña Histórica • Las raíces del UML provienen de tres metodologías de análisis y diseño OO distintas: • El metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones. • La Técnica de Modelado Orientada a Objetos de James Rumbaugh (OTM Object-Modeling-Tecnique) • Aproximación “Objetory”, de Ivar Jacobson.(OOSE: Object Oriented Software Engineering) mediante la metodología de Casos de Uso. • Booch, Rumbaugh y Jacobson dieron forma a la primera versión del UML y en 1997 fue aceptado por la OMG, fecha en la que fue lanzada la versión v1.1 del UML. • Desde entonces, UML atravesó varias revisiones y refinamientos hasta llegar a la versión actual: UML 2.0. • La especificación de UML se puede encontrar en el web site de Object Management Group (OMG) http://www.omg.org/uml/.

12. Breve Reseña Histórica • ¿Qué es la OMG? • La OMG (Object Management Group) • Es una asociación sin fines de lucro formada por grandes corporaciones, muchas de ellas de la industria del software, como por ejemplo: • IBM, • Apple Computer, • Sun Microsystems Inc. • Hewlett-Packard. • Esta asociación se encarga de la definición y mantenimiento de estándares para aplicaciones de la industria de la computación. • Otro de los estándares definidos por la OMG, además del UML, es CORBA, el cual permite interoperabilidad multiplataforma a nivel de objetos de negocio.

13. DIAGRAMAS UML

14. Diagramas UML Diagramas de Estructura Diagramas de Comportamiento • Los diagramas de estructura construyen y documentan el modelo estáticodel sistema • Los diagramas de comportamiento muestran la parte dinámica de un sistema, construyen y documentan el modelo dinámico del sistema

15. Diagramas de Estructura • Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado • Dentro de los Diagrama de Estructura tenemos: • Diagrama de Clases • Diagrama de Componentes • Diagrama de Objetos • Diagrama de Estructura Compuesta (UML 2.0) • Diagrama de Despliegue • Diagrama de Paquetes

16. Diagramas de Comportamiento • Enfatizan en lo que debe suceder en el sistema modelado. • Diagramas de Actividades • Diagramas de Casos de Uso • Diagramas de Transición de Estados • Diagramas de Interacción • Son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado. • Diagramas de Secuencia • Diagramas de comunicación (versión simplificada Diagrama de colaboración) • Diagramas de Tiempos • Diagrama Global de Interacciones o Diagrama de Vista de Interacción

17. Categorización Jerárquica de los diagramas UML

18. Diagramas Básicos de UML • UML define nueve tipos de diagramas básicos: • Diagramas de casos de Uso • Diagramas Clases • Diagramas Objetos • Diagramas Actividad • Diagramas Colaboración • Diagramas Secuencia • Diagramas Estados • Diagramas Componentes • Diagramas Deployment

19. UML Vistas y Diagramas Vista Estructural Vista de la Implementación • Diagramas de clases • Diagramas de Objetos • Diagramas de Componentes Vista de Usuario • Diagramas Casos de Uso Vista de Comportamiento Vista Ambiente • Diagramas de Secuencia • Diagramas de Colaboración • Diagramas de Estado • Diagramas de Actividad • Diagramas de Despliegue F.E.R.D.

20. Elementos Generales • En general los diagramas UML representan conceptos como símbolos (nodos) y relaciones (links) que conectan estos símbolos. • Otros elementos UML importantes: • Notación de paquetes • Estereotipos • Comentarios (notas) • Constraints (o restricciones) • Valores etiqueta (tagged values)

21. Paquetes (packages) En UML, los paquetes permiten organizar el modelado los elementos del sistema en grupos, permiten una organización jerárquica del modelo de elementos del sistema. Package: Sistema de Reservaciones, contiene los packages de Agencia y Banco Package: Sistema de Reservaciones Agencia Package: Agencia muestra el contenido de sus clases Agente y Aerolínea Agente Aerolínea Banco Package: No se muestra su contenido en el diagrama F.E.R.D.

22. Paquetes (packages) Packagecontainer Compras Package name dominio pantallas << import >> Propietario 0 ..* compañía vehículo << import >> Subpackage reportes camión camioneta Package dependency Elementos del modelo

23. Estereotipos Tag estereotipo Los estereotipos aplican tanto a relaciones como a nodos << interface>> Set Antación (Annotation) Nota o comentario Vehiculo3 - carga : double peso en newtons - maximaCarga : double + getCarga() : double peso en kilogramos + getMaximaCarga() : double + addCaja(peso: double) : double

24. Restricciones (Constraints) { persistente } Jugador Las restricciones proporcionan al modelo ciertas condiciones que aplican a un nodo o link. * 0..1 Constraint { miembro} registro co-capitán capitán * * * Equipo { Mínimo 3 Jugadores mujeres y mínimo 4 jugadores hombres}

25. Valores etiqueta (tagged values) Valores etiqueta Sever Los valores etiqueta permiten agregar nuevas propiedades a los nodos en un diagrama. documento.java { version= 1.3 } {procesadores= 4 } ______________________________________________________________

26. UML Vistas y Diagramas Vista Estructural Vista de la Implementación • Diagramas de clases • Diagramas de Objetos • Diagramas de Componentes Vista de Usuario • Diagramas Casos de Uso Vista de Comportamiento Vista Ambiente • Diagramas de Secuencia • Diagramas de Colaboración • Diagramas de Estado • Diagramas de Actividad • Diagramas de Despliegue

27. UML Vistas y Diagramas Vista Estructural Vista de la Implementación • Diagramas de clases • Diagramas de Objetos • Diagramas de Componentes Vista de Usuario • Diagramas Casos de Uso Vista de Comportamiento Vista Ambiente • Diagramas de Secuencia • Diagramas de Colaboración • Diagramas de Estado • Diagramas de Actividad • Diagramas de Despliegue

28. Diagrama de Casos de Uso • Muestra quién hace uso del sistema y que procesos ejecutara. • Los usuarios en un Diagrama de Casos uso son llamados “Actores” • Un Caso de Uso se muestra como una elipse. • Utilidad: • Los Diagramas de Casos de Uso son de importanciapara la de obtención de requerimientos y modelado del negocio. • Durante todo el desarrollo del sistema para hacer seguimiento del trabajo relisado. • Relaciones de Casos de Uso: • Inclusión: Depencia de obiligatoriedad, esteriotipo <<include>> o <<use>> • Extensión: Opconal, esteriotipo <<extend>> • Generalización

29. Creando un modelo de Casos de Uso • Un Diagrama de Casos de Uso comprende de varios casos de uso • Sus componentes son: • Actores • Casos de uso • El sistema • Relaciones de generalización y asociación • Un modelo de casos de uso usa “Actores” para definir que existe fuera del sistema y “Casos de uso” para definir que debe ejecutarse por el sistema F.E.R.D.

30. Digrama de Casos de Uso Los casos de uso representan la funcionalidad dada por el sistema a los usuarios externos. Diagramas de Casos de Uso el cliente pregunta por el balance F.E.R.D.

31. Diagramas de Casos de Uso • El estándar de UML define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. • El valor verdadero de un caso de uso reposa en dos áreas: • La descripción escrita del comportamiento del sistemaal afrontar una tarea de negocio o un requisito de negocio. • La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes, consistentes promueve una imagen fácil del comportamientodel sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo. F.E.R.D.

32. SISTEMA HOTELERO Nueva Reservación Modificar Reservación Registrador Borrar Reservación Recepcionista Check in Huésped Check out Huésped Telefonista Buscar Huésped por nombre F.E.R.D.

33. SISTEMA HOTELERO <<extend>> Nueva Reservación Adicinar detalles Huésped Registrador Modificar Reservación <<include>> <<include>> Borrar Reservación Buscar Reservación <<include>> Recepcionista Check in Huésped <<include>> Habilitar Teléfono << actor>> Monitor Teléfonos <<include>> Check out Huésped Deshabilitar Teléfono Buscar Huésped por nombre Telefonista F.E.R.D.

34. Escenarios de los Casos de Uso • Un Caso de Uso muestra una función desde la perspectiva de los usuasrios. • Un escenario se refiere a una instancia de un Caso de Uso. • Un escenrio es un camino lógico desde el comienso hasta el final. • Los escenarios no contienen condicionales porque describen uno o varios caminos posibles de un caso de uso. • Se deben documentar escenerios tanto existosos como no existosos. • Se deben documentar los principales escenarios. F.E.R.D.

35. Nombre Nueva Reservación Actor Recepsionista, Resgistrador Estado Esperando por revisión del PM Adicionar detalles Huésped Puntos de Extensión Ninguna Extends El usuario esta logeado y la pantalla de reservaciones ha sido seleccionada Precondiciones/ Asunpciones La lista de reservaciones es actualizada si la reservación es aceptada Post-condiciones 1. Se muestra al usuario lista de tipos de cuarto 2. El usuario selecciona el tipo cuarto requerido 3. El usuario entra fechas inicial y final o duración 4. El usuario inicia búsqueda cuarto disponible 5. Si las fecha están mal especificadas [A1] 6. Si no encontró cuarto disponible [A2] 7. Si el cuarto esta disponible, se muestra precio 8. Si el cliente rechaza la oferta [A3] 9. (Adionar detalles Huésped) punto de extensión 10. ………………… Flujo de Eventos F.E.R.D.

36. Nombre Nueva Reservación Escenarios (Caminos Alternativos) • Este caso de uso se puede cancelar en cualquier momento • A1. La pantalla muestra mensaje “fechas invalidas” entonces vuelve al punto 1 • A2. La pantalla muestra mensaje “Por favor intente seleccionar otro tipo de cuarto” entonces vuelve al punto 1 • A3. El caso de uso es terminado, cambios no efectuados. Requerimientos no funcionales Performance Respuesta interactiva es requerida Baja Frecuencia Notas F.E.R.D.

37. UML Vistas y Diagramas Vista Estructural Vista de la Implementación • Diagramas de clases • Diagramas de Objetos • Diagramas de Componentes Vista de Usuario • Diagramas Casos de Uso Vista de Comportamiento Vista Ambiente • Diagramas de Secuencia • Diagramas de Colaboración • Diagramas de Estado • Diagramas de Actividad • Diagramas de Despliegue F.E.R.D.

38. UML Vistas y Diagramas Vista Estructural Vista de la Implementación • Diagramas de clases • Diagramas de Objetos • Diagramas de Componentes Vista de Usuario • Diagramas Casos de Uso Vista de Comportamiento Vista Ambiente • Diagramas de Secuencia • Diagramas de Colaboración • Diagramas de Estado • Diagramas de Actividad • Diagramas de Despliegue F.E.R.D.

39. Vista Estructural • Representación de Objetos y Clases en UML • Los aspectos lógico y físico de la vista estática se muestra en el Modelo de Objetos (Model Object) • El Model Object esta compuesto de dos diagramas: • Diagrama de Clases • Diagrama de Objetos F.E.R.D.

40. Notación UML de las clases • Estructura básica de una clase en un Diagrama de Clases NombreClase nombreClase atributos metodos Un Diagrama de clases es dinámico en su naturaleza, este puede ser revisado y actualizado durante la fase de análisis. Se le asigna el nombre cuando se crea pero la lista de atributos y métodos variará en cada iteración a otras F.E.R.D.

41. Notación UML de las clases Nodos clase: a) b) c) <<interface>> InputStream Compañia Set Es una clase concreta, en donde sus miembros no están modelados. Es una clase abstracta (nombre en itálicas) Es una interface d) Vehículo Es una clase concreta, en donde sus miembros están modelados. - carga : double = 0.0 - cargaMaxima : double + getCarga() : double + getCargaMaxima() : double + addionarCaja(peso : double) : boolean F.E.R.D.

42. Notación UML de las clases tipo atributo multiplicidad atributo valor inicial atributo nombre atributo Vehículo nombre clase - carga : double = 0.0 atributos - cargaMaxima : double - Destinos [1 . . *] : String <<constuctor>> + Vehiculo(cargaMaxima : double ) <<accesor>> modos de acceso + getcarga() : double + getCargaMaxima() : double métodos <<mutator>> + setCargaMaxima(maximo : double) <<bussiness logic>> + adicionarCaja(peso : double) : boolean # calcularEficiencia() :double + calcularDistanciaRecorrida() : double tipo retorno nombre método tipo parámetro nombre parámetro F.E.R.D.

43. Notación UML de los objetos UML define modos de acceso y sus símbolos: símbolo modo de acceso private - protected # Public + Count - counter : int = 0 - instanciaNumbre : int Elementos estáticos - getTotalCount() : int + getMyNumber : int Ejemplo de una clase con elementos estáticos, counter es un atributo estático y getTotalCounter() un método estático. F.E.R.D.

44. Notación UML de los objetos La notación de un objeto es diferente a la de una clase ya que un objeto es una instancia de una clase objectName:NombreClase atributo1 = valor1 atributo2 = valor2 Sintaxis: objectName:NombreClase :NombreClase Si se conoce que el objeto es requerido pero no se le a identificado un nombre F.E.R.D.

45. Asociaciones y Enlaces (links) Asociacción: La relación representada por una línea sobre un Diagrama de Clases es una Asociación, la Asociación debe tener un nombre indicando una descripción lógica del propósito de la relación. Propietario Persona Carro Una Asociación entre dos Clases Enlace (link): Una relación entre dos objetos es llamada un Enlace (Link). Propietario :Persona :Carro Un Link entre dos Objetos F.E.R.D.

46. Asociaciones y Multiplicidad La Multiplicidad muestra cada posible combinación de cómo varios objetos de una clase pueden ser asociados con objetos de otra clase. 1 1 movido por Carro Motor * 1 Propietario Persona Carro * 1 1 1 Propietario movido por :Persona :Carro :Motor Diagrama de Clases Carro, Motor, Persona F.E.R.D.

47. Asociaciones y Multiplicidad Instructor 1 0 ..* 1 .. * 1 ..* 1 3..12 Clase Plan Estudiante 0 ..* Ejemplo de Diagrama de Clases 1 Salón 1 1 1 3..12 Cubierta computador F.E.R.D.

48. Asociaciones Complejas Una asociación Compleja es cuando la Multiplicidad marcada con “*” se encuentra en ambos lados de la asociación. * * presta Persona Libro • Una Asociación Compleja no es fácil modelar por las reglas que aplican a cada clase y tampoco lo es su implementación en un lenguaje de programación. • Dos técnicas para resolver asociaciones complejas son: • Clase Asociada • Asociaciones Cualificadas F.E.R.D.

49. Asociaciones Complejas Clase Asociada (o derivada): Una Clase asociación es codificada con atributos para resolver el conflicto. * * presta Persona Libro Esta técnica es usada en la fase de análisis para resolver relaciones muchos a muchos Presta fechaDesde * * Persona Presta Libro fechaDesde fechaHasta • El nombre de la clase asociada debe ser el mismo de la asociación origen F.E.R.D.

50. Asociaciones Complejas Clase Cualificada: Cuando dos clases tienen una asociación lógica “muchos-a-muchos”, Se asigna un valor de atributo único que actúa como índice. * * Bancos con Banco Cliente Asociación “muchos-a-muchos” * Bancos con Banco Cliente ideCliente Asociación Cualificada para Banco referenciado a un Cliente * Bancos con Banco Cliente codBanco Asociación Cualificada para Cliente referenciado un Banco F.E.R.D.