Introducción al modelado

1. Introducción al modelado Metodologías, UML y patrones de diseño Ricardo Borillo Doménech borillo@si.uji.es

2. Índice • Conceptos • Lenguajes de modelado: UML • Metologías: • Metologías clásicas: RUP, Métrica, MSF • Metologías ágiles: eXtreme Programming • Patrones de diseño de sofware • Arquitecturas dirigidas por modelos (MDA) • Herramientas de modelado

3. Introducción a las metodologías

4. Componentes básicos • RUP. Técnicas y su aplicación a la gestión de proyectos software orientados a objeto. • XP. Gestión ágil de proyectos y grupos de desarrollo. • UML. Diagramas, elementos notacionales y semántica de los modelos generados.

5. Modelado con UML

6. Qué es UML? • El UML modela sistema mediante el uso de objetos que forman parte de él así como, las relaciones estáticas o dinámicas que existen entre ellos. • UML puede ser utilizado por cualquier metodología de análisis y diseño orientada por objetos para expresar los diseños.

7. Qué es UML? • UML es un Lenguaje de Modelado Unificado basado en una notación gráfica la cual permite: especificar, construir, visualizar y documentar los objetos de un sistema programado. • Este lenguaje es el resultado de la unificación de los métodos de modelado orientados a objetos de Booch, Rumbaugh (OMT: Object Modeling Technique) y Jacobson (OOSE: Object-Oriented Sotfware Engineering).

8. UML • UML es un lenguaje de modelado que sirve para visualizar, especificar , construir y documentar un sistema software. Lenguaje de modelado: “Lenguaje cuyo vocabulario y reglas se centran en la representación conceptual y física de un sistema” (Booch, Jacobson y Rumbaugh).

9. UML para visualizar • Símbolos con semántica bien definida. • UML transciende al lenguaje de programación. • Modelo explícito, que facilita la comunicación.

10. UML para especificar • Especificar es equivalente a construir modelos que cumplan las condiciones de no ambigüedad y completitud. • UML cubre la especificación del análisis, diseño e implementación de un sistema software.

11. Es posible hacer corresponder con los lenguajes de programación (Java, C#, B.Datos, etc.). UML para construir IngenieríaDirecta ModeloUML CÓDIGO Ingeniería Inversa

12. UML para documentar • UML cubre la documentación de un sistema: • Requisitos • Arquitectura • Diseño • Código fuente • Planificación • Pruebas • Prototipos • Versiones

13. 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 Responsabilities Fusion Operation descriptions, message numbering

14. UML 2.0 2001 UML 1.4 2000 1999 UML 1.3 Revisiones menores 1998 UML 1.2 Nov ‘97 UML aprobado por el OMG Historia de UML

15. Actualizaciones de UML • UML 1.3 es una versión madura de UML a la que se le han añadido una serie de pequeñas revisiones, las cuales corrigen o mejoran la especificación base (UML 1.2). • UML 1.4 incorpora ciertas modificaciones sobre el estándar en base a los comentarios recogidos de los usuarios finales y de los fabricantes de software compatible con UML. • UML 2.0 promete la puesta a punto del estándar para poder integrarse con el desarrollo basado en componentes que demanda el mercado.

16. UML 2.0 • Arquitectura: refinamiento del núcleo del estándar para que esté en consonancia con el resto de estándares del mercado. • Personalización: mejora de los mecanismos de extensibilidad y personalización. • Componentes: mejor soporte para el desarrollo basado en componentes (CORBA, EJB, COM+). • Mecanismos generales: nuevos mecanimos para el control de las versiones dentro del modelo, así como el intercambio de los metadatos del mismo con XMI (XML Metadad Interchange).

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

18. Modelos y Diagramas • Modelo: capturauna vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. • Diagrama:representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos.

19. Vista de Implementación Vista de Diseño Vista de los Casos de Uso Vista de Despliegue Vista de Procesos Organización de Modelos

20. State Diagrams State Diagrams Diagramas de Clases Use Case Diagrams Use Case Diagrams State Diagrams Diagramas de Casos de Uso State Diagrams Use Case Diagrams Diagramas de Objetos Use Case Diagrams Diagramas de Secuencia Scenario Diagrams State Diagrams Scenario Diagrams State Diagrams Diagramas de Componentes Diagramas de Colaboración Modelo Component Diagrams Scenario Diagrams Component Diagrams Scenario Diagrams Diagramas de Distribución Diagramas de Estados Diagramas de Actividad Diagramas de UML

21. Mecanismos comunes en UML • Especificaciones. Es más que un lenguaje gráfico (semántica detrás de la notación). • Adornos. Detalles sobre un clase, nivel de acceso de sus métodos, notas. • Divisiones Comunes: Clase/Objecto o Interfaz/Implementación. • Extensibilidad. Estereotipos, valores etiquetados o restricciones.

22. Mecanismos comunes en UML

23. Casos de Uso

24. Casos de Usos • Un diagrama de Casos de Uso muestra la distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuario u otras aplicaciones). • Es una herramienta esencial para la captura de requerimientos y para la planificación y control de un proyecto interactivo.

25. Casos de Usos • Los casos de Uso Se representa en el diagrama por una elipse que denota un requerimiento solucionando por el sistema. • Cada caso de uso de uso es una operación completa desarrollada por los actores y por el sistema en un diálogo. • El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por el sistema.

26. Casos de Usos

27. Casos de Usos • Actor: Es un usuario del sistema, que necesita o usa alguno de los casos de uso. Un usuario puede jugar más de un rol. Un solo actor puede actuar en muchos casos de uso; recíprocamente, un caso de uso puede tener varios actores. Los actores no necesitan ser humanos pueden ser sistemas externos que necesitan alguna información del sistema actual.

28. Casos de Usos • También se puede encontrar tres tipos de relaciones, como son: • Comunica (comunicates) Entre un actor y un caso de uso, denota la participación del actor en el caso de uso determinado.

29. Casos de Usos • Usa (uses): Relación entre dos casos de uso, denota la inclusión del comportamiento de un escenario en otro. Se utiliza cuando se repite un caso de uso en dos o más casos de uso separados. Frecuentemente no hay actor asociado con el caso de uso común.

30. Casos de Usos • Extiende (extends): Relación entre dos casos, denota cuando un caso de uso es una especialización de otro. Se usa cuando se describe una variación sobre el normal comportamiento.

31. Casos de Usos • Técnicas comunes de modelado: • Modelado del contexto del sistema (utilidad similar a los DFD). • Modelado de los requisitos de un sistema. • Modelado del proceso de test y estrés del sistema.

32. Diagrama de Clases

33. Conceptos básicos orientación a objetos • Clase • Objeto • Herencia • Interfaz • Polimorfismo de clases • Clases y atributos estáticos • Clases y atributos finales • Clases y métodos abstractos

34. Diagrama de clases • Un diagrama de clases o estructura estática muestra el conjunto de clases y objeto importantes que forman parte de un sistema, junto con las relaciones existentes entre clases y objetos. Muestra de una manera estática la estructura de información del sistema y la visibilidad que tiene cada una de las clases, dada por sus relaciones con los demás en el modelo.

35. Diagrama de clases • Usos comunes del diagrama: • Modelado del vocabulario del sistema. • Modelado de colaboraciones simples. • Modelado de un esquema lógico de base de datos. • Modelado de un conjunto de clases de test.

36. Diagrama de clases • Clase: representa un conjunto de entidades que tienen en común propiedades, operaciones, relaciones y semántica. • Una clase es un constructor que define la estructura y comportamiento de una colección de objeto denominados instancia de la clase. • En UML la clase está representada por un rectángulo con tres divisiones internas, son los elementos fundamentales del diagrama.

37. Diagrama de clases • Atributo: Representa una propiedad de una entidad. Cada atributo de un objeto tiene un valor que pertenece a un dominio de valores determinado. • Las sintaxis de una atributo es: • Visibilidad <nombre>: tipo = valor { propiedades} • Donde visibilidad es uno de los siguientes: • + público. • # protegido. • - privado.

38. Diagrama de clases • Operación: El conjunto de operaciones que describen el comportamiento de los objetos de una clase. La sintaxis de una operación en UML es: • Visibilidad nombre (lista de parámetros): tipo que retorna { propiedades}

39. Nombre de la clase Atributos Métodos Diagrama de clases

40. Diagrama de clases • Responsabilidades: Contrato u obligación de una clase, asignada en el momento del diseño. • Clase Producto: • Registrar el código de la publicación. • Mantener estructura del producto plantilla.

41. Diagrama de clases • Técnicas de modelado: • Modelado del vocabulario de un sistema a partir de las descripciones funcionales. • Modelado de la distribución de responsabilidades en un sistema. • Modelado de cosas que no son software (hardware, personas, etc). • Modelado de tipos primitivos.

42. Diagrama de clases • Objeto: es una instancia de una clase. Se caracteriza por tener una identidad única, un estado definido por un conjunto de valores de atributos y un comportamiento representado por sus operaciones y métodos. • Asociación (rol, multiplicidad, calificador): representan las relaciones entre instancias de clase. Una asociación es una línea que une dos o más clases.

43. Diagrama de clases • Nombre: Identifica la asociación entre los objetos, caracterizándola. • Rol: Identificado como un nombre a los finales de la línea, describe la semántica de la relación en el sentido indicado. Cada asociación tiene dos roles; cada rol es una dirección en la asociación. El rol puede estar representado en el nombre de la clase.

44. Diagrama de clases • Multiplicidad: Describe la cardinalidad de la relación, es decir, cuanto objetos de esa clase pueden participar en la relación dada. Tipos:

45. Diagrama de clases • Dependencia: Es una relación donde existen entidades independientes y otras dependientes, lo que implica que cambiar el elemento independiente puede requerir cambios en los dependientes. Se representa con una línea punteada direccional, indicando el sentido de la dependencia.

46. Diagrama de clases

47. Diagrama de clases • Los tipos de asociaciones entre clases presentes en un diagrama estático son: • Asociación binaria. • Asociación n-aria. • Composición. • Generalización. • Refinamiento.

48. Diagrama de clases • Asociación Binaria: Representa una relación sencilla entre dos clases, no muy fuerte (es decir, no se exige dependencia existencial ni encapsulamiento). Se indica como una línea sólida que une dos clases. • Asociación n-aria: Es una asociación entre tres o más clases. Se representa como un diamante del cual salen líneas de asociación a las clases.

49. Diagrama de clases

50. Diagrama de clases • Composición: Es una asociación fuerte que implica: • Dependencia existencial. El elemento dependiente desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo. • Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene.