Ingeniería de software II - Parte 3.1

3,986
-1

Published on

Material de Clase de Ingeniería de Software II - Universidad de Medellín - Colombia

Published in: Technology
1 Comment
4 Likes
Statistics
Notes
  • es un muy buen material, muy completo, sencillo y comprensible
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
3,986
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

Ingeniería de software II - Parte 3.1

  1. 1. Parte 1.2.1Proceso de Desarrollo UnificadoFLUJOS DE TRABAJO – UP<br /><ul><li>Flujo de Requisitos
  2. 2. Flujo de Análisis</li></ul>Material académico preparado por:<br />Ph.D, Marta Silvia Tabares B.<br />Fecha última actualización 4-Sep-2011<br />
  3. 3. Ingeniería de Software II(mapa conceptual de tópicos de conocimiento)<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  4. 4. Bibliografía<br />Roger Pressman. Ingeniería del Software (6ª ED.). Mcgraw-hill / Interamericana.<br />Alan Dennis, BarbaraHaleyWixom and David Tegarden. SystemsAnalysis and Designwith UML Version 2.0 - AnObjectOrientedApproach, SecondEdition. John Wiley & Sons © 2005.<br />Ivar Jacobson, Grady Booch, James Rumbaugh. El Proceso Unificado de Desarrollo de Software. Adisson Wesley. 2001.<br />Arlow, J., and Neustad, I. UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (2nd Edition). Addison-Wesley Object Technology Series. 2005.<br />OMG-UML. Unified Modeling Language: Superstructure. version 2.0, formal/05-07-04. 2005.<br />Simon Bennett, SteeMcRobb, y Ray Farmer. Análisis y DiseñoOrientado a Objetos del Sistema, Usando UML. McGraw-Hill, 2006.<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  5. 5. Proceso UnificadoFlujo de Requisitos<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  6. 6. Proceso UnificadoFlujo de Requisitos<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  7. 7. Roles y ArtefactosFlujo de Requisitos – Dirigido por Casos de Uso<br />Arquitecto<br />Diseñador de Interfaces de Usuario<br />Especificador de los Casos de Uso<br />Analista del Sistema<br />Responsable<br />de<br />Responsable<br />de<br />Responsable<br />de<br />Responsable<br />de<br />Descripción <br />de la <br />Arquitectura<br />Prototipo de<br />Interfaz de <br />Usuario<br />Glosario<br />Actor<br />Modelo <br />de Casos <br />de Uso<br />Caso de Uso<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  8. 8. Proceso UnificadoFlujo de Requisitos – Dirigido por Casos de Uso<br />Encontrar Actores y Casos de Uso<br />Analista del Sistema<br />Estructurar el Modelo de Casos de Uso<br />Priorizar Casos de Uso<br />Arquitecto<br />Especificador de los Casos de Uso<br />Detallar Casos de Uso<br />Diseñador de Interfaces de Usuario<br />Prototipos de las Interfaces de Usuario<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  9. 9. Proceso UnificadoFlujo de Análisis<br />PRODUCTOS<br /><ul><li> Dcto. de visión refinado
  10. 10. Dcto. de evaluación del riesgo refinado
  11. 11. Modelo de requisitos No-funcionales
  12. 12. Modelo de casos de uso arquitectónicamente significativos (Diagramas de Actividades, Diagramas de Comunicación)
  13. 13. Modelo de Clases
  14. 14. Modelo de componentes
  15. 15. Esquema de la base de datos
  16. 16. Prototipos definitivos
  17. 17. Arquitectura ejecutable
  18. 18. Modelo de Pruebas </li></ul>Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  19. 19. Flujo de Análisis UP<br />Ingeniero de <br />Casos de Uso<br />Analizar un <br />Caso de Uso<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  20. 20. Productos del Análisis y sus Responsables<br />Responsable de<br />Arquitecto<br />Responsable de<br />Ingeniero de <br />Casos de Uso<br />Clase de <br />Análisis<br />Responsable de<br />Ingeniero de <br />Componentes<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  21. 21. Artefactos UP-Análisis<br />Modelo de Análisis<br />Clase de Análisis<br />Realización de Caso de Uso<br />Paquete de Análisis<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  22. 22. Modelo de Análisis: Diagramas<br />Diagrama de <br />Objetos<br />Modelo de <br />Casos de Uso<br />Diagrama de <br />Secuencia<br />Diagrama <br />de<br />Clases<br />Diagrama de <br />Colaboración<br />Diagrama de<br />Actividades<br />Diagrama de <br />Estados<br />Flujo de Análisis UP<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  23. 23. Modelo de Casos de Usovs. Modelo de Análisis<br />Flujo de Análisis UP<br />Tomado de la Referencia [3]<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  24. 24. Propiedades del Desarrollo de Software Orientado por Objetos (1)<br />Abstracción<br />Encapsulamiento<br />Herencia<br />Polimorfismo<br />Reusabilidad<br />Elementos de Modelo:<br />Clases<br />Objetos<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  25. 25. Propiedades del Desarrollo de Software Orientado por Objetos (2):Conceptos de Abstracción y Herencia<br />Tomado de Systems Analysis and Design with UML Version 2.0 - An Object Oriented Approach, Second Edition<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  26. 26. Clases y Objetos (3)<br />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.<br />En el nivel del METAMODELO los elementos son abstractos, es decir sólo se definen sus propiedades y posibles operaciones.<br />En el nivel de MODELO los elementos son instancias del meta elemento y toma un valor específico.<br />Figura 1<br />Figura 2<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />Figuras tomadas del Unified Modeling Language: Infrastructure<br />
  27. 27. Clases y Objetos (4)<br />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.<br />Clase<br />Objetos<br />(Instancia)<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  28. 28. UML: Notación de la Clase (1)<br />Valor etiquetado, o<br />Restricción (constraint)<br />Nombre de la<br />clase<br />estereotipo<br />Compartimiento de identificación de la clase<br />Compartimiento de definición de atributos<br />Valor inicial<br />Compartimiento de identificación de las operaciones<br />Alcance de la <br />operación (parámetros)<br />visibilidad<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  29. 29. UML: Notación de la Clase (2)<br />Alcance de la Instancia<br />Alcance de la Clase<br />Alcance de la Clase:<br />Se refiere a los atributos y operaciones que pertenecen a , o operan en, toda clase de objetos.<br />Alcance de la Instancia:<br />Se refiere a los atributos y operaciones que pertenecen a , o operan en, objetos específicos <br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  30. 30. UML: Notación de la Clase (3)Alcance que determina el acceso<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  31. 31. UML: Notación de la Clase (4)Visibilidad de una Clase<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  32. 32. Diagrama de Clases (1): Elementos de modelo<br />Clases<br />Relaciones de:<br />Abstracción (Dependencia)<br />Asociación<br />Generalización<br />Agregación<br />Composición<br />Interfaces<br />InterfazRealización<br />Realización<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  33. 33. Diagrama de Clases (2): Relaciones entre clases<br />ABSTRACCIÓN<br />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.<br />Clase<br />A<br />Clase <br />B<br /><<nombre del estereotipo>><br />Clase Cliente<br />(la que requiere de la<br />clase proveedora)<br />Clase Proveedora<br />(la que provee a la<br />clase cliente)<br />Pueden ser otros tipos de elementos de modelo tales como paquetes, y casos de uso, entre otros, en diferentes niveles de abstracción.<br />Asociación<br />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)<br />ASOCIACIÓN<br />Estereotipo de la relación de Dependencia entre el objeto y la clase<br />Link<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  34. 34. Diagrama de Clases (3): Relaciones entre clases<br />Formas básicas de <br />usar la Relación de<br />Asociación<br />multiplicidad<br />(1)<br />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<br />(2)<br />qualifier<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  35. 35. Diagrama de Clases (4): Relaciones entre clases<br />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).<br />GENERALIZACIÓN<br />Figura tomada del Unified Modeling Language: Superstructure<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  36. 36. Diagrama de Clases (5): Relaciones entre clases<br />Figuras tomadas del Unified Modeling Language: Superstructure<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  37. 37. Diagrama de Clases (6): Relaciones entre clases<br />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. <br />AGREGACIÓN<br />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.<br />COMPOSICIÓN<br />Figura tomada del: Unified Modeling Language: Superstructure<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  38. 38. Diagrama de Clases (7): Relaciones entre clases<br />Asociación<br />Los objetos son conscientes unos de los otros, entonces ellos pueden trabajar juntos<br />Agregación<br />Protege la integridad de la configuración<br />Las Funciones son una sola unidad <br />El control es a través de un objeto – la propagación es descendente<br />Composición<br />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.<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  39. 39. Diagrama de Clases (8): Ejemplo: Diagrama de Clases – Sistema Bancario<br />Rel. Asociación<br />Rel. Agregación<br />Multiplicidad*<br />Rel. Generalización<br />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.<br />* También se conoce como CARDINALIDAD<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  40. 40. Paquetes (1)<br />Un paquete es un contenedor UML el cual es propietario de elementos de modelo.<br />Es un mecanismo de propósito general para agrupar y organizar elementos de modelo (incluyendo otros paquetes) y diagramas en grupo.<br />Se puede usar para:<br />Proporcionar un espacio encapsulado y nombrado dentro del cual todos los nombres son únicos.<br />Agrupar semánticamente elementos relacionados.<br />Definir un “límite semántico” en el modelo.<br />Proporcionar unidades para el trabajo en paralelo y administración de la configuración.<br />Pueden contener: casos de uso, clases de análisis, etc.<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  41. 41. Paquetes (2): Banking Account Package <br />Elementos de Modelo del Paquete<br />Paquete<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  42. 42. Paquetes (3): Companies Package <br />Multiplicidad<br />Multiplicidad<br />Roles<br />Rel. Reflexiva<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  43. 43. Paquetes (4): Visibilidad<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  44. 44. Relaciones entre Paquetes (1)<br />Un elemento en el paquete Cliente usa un elemento público del paquete Proveedor de alguna forma. El cliente depende del proveedor.<br />Elementos públicos del espacio nombrado del Proveedor son adicionados como elementos públicos al espacio nombrado del Cliente.<br />Elementos públicos del espacio nombrado del Proveedor son adicionados como elementos privados al espacio nombrado del Cliente.<br />Elementos públicos del paquete Proveedor son combinados con elementos paquete Cliente.<br /><<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.<br />Símbolo que identifica un MODELO<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  45. 45. Relaciones entre Paquete (2): Ejemplos<br />Ejemplo 1:<br />Paquete Cliente<br />Paquete Proveedor<br />Ejemplo 2:<br />Figura tomada del: Unified Modeling Language: Superstructure<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />
  46. 46. Tareas<br />Cuáles son los cinco (5) estereotipos que UML provee para trabajar con la relación de Dependencia de Uso (Usage Dependency).<br />Cuáles son los cuatro (4) estereotipos que UML provee para trabajar con la relación de Dependencia de Abstracción (Abstraction Dependency).<br />No olvide realizarla, toda tarea o ejercicio propuesto es EVALUABLE<br />Material Preparado por MARTA SILVIA TABARES B. UdeM<br />

×