El documento presenta una introducción al Proceso Unificado de Desarrollo de Software (UP) y sus flujos de trabajo, incluyendo el flujo de requisitos y el flujo de análisis. Explica conceptos clave como roles, artefactos, diagramas y relaciones entre elementos del modelo de objetos como clases, paquetes y casos de uso.
7. Roles y ArtefactosFlujo de Requisitos – Dirigido por Casos de Uso Arquitecto Diseñador de Interfaces de Usuario Especificador de los Casos de Uso Analista del Sistema Responsable de Responsable de Responsable de Responsable de Descripción de la Arquitectura Prototipo de Interfaz de Usuario Glosario Actor Modelo de Casos de Uso Caso de Uso Material Preparado por MARTA SILVIA TABARES B. UdeM
8. Proceso UnificadoFlujo de Requisitos – Dirigido por Casos de Uso Encontrar Actores y Casos de Uso Analista del Sistema Estructurar el Modelo de Casos de Uso Priorizar Casos de Uso Arquitecto Especificador de los Casos de Uso Detallar Casos de Uso Diseñador de Interfaces de Usuario Prototipos de las Interfaces de Usuario Material Preparado por MARTA SILVIA TABARES B. UdeM
18. Modelo de Pruebas Material Preparado por MARTA SILVIA TABARES B. UdeM
19. Flujo de Análisis UP Ingeniero de Casos de Uso Analizar un Caso de Uso Material Preparado por MARTA SILVIA TABARES B. UdeM
20. Productos del Análisis y sus Responsables Responsable de Arquitecto Responsable de Ingeniero de Casos de Uso Clase de Análisis Responsable de Ingeniero de Componentes Material Preparado por MARTA SILVIA TABARES B. UdeM
21. Artefactos UP-Análisis Modelo de Análisis Clase de Análisis Realización de Caso de Uso Paquete de Análisis Material Preparado por MARTA SILVIA TABARES B. UdeM
22. Modelo de Análisis: Diagramas Diagrama de Objetos Modelo de Casos de Uso Diagrama de Secuencia Diagrama de Clases Diagrama de Colaboración Diagrama de Actividades Diagrama de Estados Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
23. Modelo de Casos de Usovs. Modelo de Análisis Flujo de Análisis UP Tomado de la Referencia [3] Material Preparado por MARTA SILVIA TABARES B. UdeM
24. Propiedades del Desarrollo de Software Orientado por Objetos (1) Abstracción Encapsulamiento Herencia Polimorfismo Reusabilidad Elementos de Modelo: Clases Objetos Material Preparado por MARTA SILVIA TABARES B. UdeM
25. Propiedades del Desarrollo de Software Orientado por Objetos (2):Conceptos de Abstracción y Herencia Tomado de Systems Analysis and Design with UML Version 2.0 - An Object Oriented Approach, Second Edition Material Preparado por MARTA SILVIA TABARES B. UdeM
26. Clases y Objetos (3) UML provee un conjunto de elementos de modelo que son definidos desde diferentes niveles de abstracción. Por ejemplo las CLASES y los OBJETOS son definidos desde el nivel de METAMODELO y sus instancias se especifican al nivel de MODELO, como se muestra en las Figuras. En el nivel del METAMODELO los elementos son abstractos, es decir sólo se definen sus propiedades y posibles operaciones. En el nivel de MODELO los elementos son instancias del meta elemento y toma un valor específico. Figura 1 Figura 2 Material Preparado por MARTA SILVIA TABARES B. UdeM Figuras tomadas del Unified Modeling Language: Infrastructure
27. Clases y Objetos (4) Una CLASE en la teoría OO es la representación abstracta de los OBJETOS del mundo real que tienen las mismas características y comportamiento. Clase Objetos (Instancia) Material Preparado por MARTA SILVIA TABARES B. UdeM
28. UML: Notación de la Clase (1) Valor etiquetado, o Restricción (constraint) Nombre de la clase estereotipo Compartimiento de identificación de la clase Compartimiento de definición de atributos Valor inicial Compartimiento de identificación de las operaciones Alcance de la operación (parámetros) visibilidad Material Preparado por MARTA SILVIA TABARES B. UdeM
29. UML: Notación de la Clase (2) Alcance de la Instancia Alcance de la Clase Alcance de la Clase: Se refiere a los atributos y operaciones que pertenecen a , o operan en, toda clase de objetos. Alcance de la Instancia: Se refiere a los atributos y operaciones que pertenecen a , o operan en, objetos específicos Material Preparado por MARTA SILVIA TABARES B. UdeM
30. UML: Notación de la Clase (3)Alcance que determina el acceso Material Preparado por MARTA SILVIA TABARES B. UdeM
31. UML: Notación de la Clase (4)Visibilidad de una Clase Material Preparado por MARTA SILVIA TABARES B. UdeM
32. Diagrama de Clases (1): Elementos de modelo Clases Relaciones de: Abstracción (Dependencia) Asociación Generalización Agregación Composición Interfaces InterfazRealización Realización Material Preparado por MARTA SILVIA TABARES B. UdeM
33. Diagrama de Clases (2): Relaciones entre clases ABSTRACCIÓN Una relación de abstracción es una relación que relaciona dos elementos o conjunto de elementos que representan el mismo concepto en diferente niveles de abstracción o desde puntos de vista diferentes. una Abstracción es una Dependencia en la cual hay a la correlación entre el proveedor y el cliente. Clase A Clase B <<nombre del estereotipo>> Clase Cliente (la que requiere de la clase proveedora) Clase Proveedora (la que provee a la clase cliente) Pueden ser otros tipos de elementos de modelo tales como paquetes, y casos de uso, entre otros, en diferentes niveles de abstracción. Asociación Una relación de asociación describe un conjunto de tuplas cuyos valores se refieren a tipos de instancias. Una relación de asociación entre instancias es llamada un link (vínculo) ASOCIACIÓN Estereotipo de la relación de Dependencia entre el objeto y la clase Link Material Preparado por MARTA SILVIA TABARES B. UdeM
34. Diagrama de Clases (3): Relaciones entre clases Formas básicas de usar la Relación de Asociación multiplicidad (1) Este tipo de asociaciones son usadas para reducir una asociación con multiplicidad n:m, (1) realizando una clase tipo asociación, o (2) especificando un objeto o un grupo de objetos del conjunto destino (2) qualifier Material Preparado por MARTA SILVIA TABARES B. UdeM
35. Diagrama de Clases (4): Relaciones entre clases Una generalización relaciona un clasificador específico con un clasificador más general, que a su vez es poseído por el clasificador específico (un clasificador es una clasificación de instancias de acuerdo a sus características). GENERALIZACIÓN Figura tomada del Unified Modeling Language: Superstructure Material Preparado por MARTA SILVIA TABARES B. UdeM
36. Diagrama de Clases (5): Relaciones entre clases Figuras tomadas del Unified Modeling Language: Superstructure Material Preparado por MARTA SILVIA TABARES B. UdeM
37. Diagrama de Clases (6): Relaciones entre clases Una agregación es un tipo especial de asociación en la cual los objetos son reunidos o configurados juntos para crear un objeto más complejo. Una agregación describe un grupo de objetos y como se relaciona con ellos. La agregación protege la integridad de un ensamble de objetos definiendo un punto solo del control, llamado el agregado, en el objeto que representa el ensamble. AGREGACIÓN La agregación compuesta (composición) es una forma fuerte de la agregación. Esta requiere que una parte de instancia sea incluida en al menos una composición a la vez. Si una composición es eliminada, todas sus partes son normalmente suprimidas con esta. COMPOSICIÓN Figura tomada del: Unified Modeling Language: Superstructure Material Preparado por MARTA SILVIA TABARES B. UdeM
38. Diagrama de Clases (7): Relaciones entre clases Asociación Los objetos son conscientes unos de los otros, entonces ellos pueden trabajar juntos Agregación Protege la integridad de la configuración Las Funciones son una sola unidad El control es a través de un objeto – la propagación es descendente Composición Una parte puede ser un miembro de una sola configuración. Es decir, la parte “no puede existir” fuera de la configuración de la composición. Material Preparado por MARTA SILVIA TABARES B. UdeM
39. Diagrama de Clases (8): Ejemplo: Diagrama de Clases – Sistema Bancario Rel. Asociación Rel. Agregación Multiplicidad* Rel. Generalización TIPS : Las especializaciones tienen sentido si tienen atributos u operaciones diferentes a los que heredan de la clase padre. Recuerden que la herencia es una relación excluyente y cada hijo tiene su especialidad. * También se conoce como CARDINALIDAD Material Preparado por MARTA SILVIA TABARES B. UdeM
40. Paquetes (1) Un paquete es un contenedor UML el cual es propietario de elementos de modelo. Es un mecanismo de propósito general para agrupar y organizar elementos de modelo (incluyendo otros paquetes) y diagramas en grupo. Se puede usar para: Proporcionar un espacio encapsulado y nombrado dentro del cual todos los nombres son únicos. Agrupar semánticamente elementos relacionados. Definir un “límite semántico” en el modelo. Proporcionar unidades para el trabajo en paralelo y administración de la configuración. Pueden contener: casos de uso, clases de análisis, etc. Material Preparado por MARTA SILVIA TABARES B. UdeM
41. Paquetes (2): Banking Account Package Elementos de Modelo del Paquete Paquete Material Preparado por MARTA SILVIA TABARES B. UdeM
42. Paquetes (3): Companies Package Multiplicidad Multiplicidad Roles Rel. Reflexiva Material Preparado por MARTA SILVIA TABARES B. UdeM
44. Relaciones entre Paquetes (1) Un elemento en el paquete Cliente usa un elemento público del paquete Proveedor de alguna forma. El cliente depende del proveedor. Elementos públicos del espacio nombrado del Proveedor son adicionados como elementos públicos al espacio nombrado del Cliente. Elementos públicos del espacio nombrado del Proveedor son adicionados como elementos privados al espacio nombrado del Cliente. Elementos públicos del paquete Proveedor son combinados con elementos paquete Cliente. <<trace>> normalmente representa el desarrollo histórico de un elemento en otro en una versión más desarrollada. Esto se da más en relaciones entre MODELOS que en relaciones entre elementos de modelo. Símbolo que identifica un MODELO Material Preparado por MARTA SILVIA TABARES B. UdeM
45. Relaciones entre Paquete (2): Ejemplos Ejemplo 1: Paquete Cliente Paquete Proveedor Ejemplo 2: Figura tomada del: Unified Modeling Language: Superstructure Material Preparado por MARTA SILVIA TABARES B. UdeM
46. Tareas Cuáles son los cinco (5) estereotipos que UML provee para trabajar con la relación de Dependencia de Uso (Usage Dependency). Cuáles son los cuatro (4) estereotipos que UML provee para trabajar con la relación de Dependencia de Abstracción (Abstraction Dependency). No olvide realizarla, toda tarea o ejercicio propuesto es EVALUABLE Material Preparado por MARTA SILVIA TABARES B. UdeM