200505 - Modelado de Software con UML

4,233
-1

Published on

Contextualizacion del Lenguaje Unificado de Modelado (UML) dentro del proceso de
desarrollo de software.

Published in: Technology
1 Comment
24 Likes
Statistics
Notes
No Downloads
Views
Total Views
4,233
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
0
Comments
1
Likes
24
Embeds 0
No embeds

No notes for slide

200505 - Modelado de Software con UML

  1. 1. UML Y el proceso unificado de desarrollo trabajando con objetos Javier González Sánchez, MCs javiergs@acm.org Departamento de Tecnologías de Información ITESM, campus Guadalajara
  2. 2. javiergs@acm.org
  3. 3. Expectativas del Curso Expectativas Antecedentes de UML Experiencia en Modelado de Software Experiencia en A&D Orientado a Objetos Experiencia con Lenguajes de Programación javiergs@acm.org
  4. 4. Contenido 1. Introducción: Arquitectura del Software Principios de Orientación a Objetos 2. Modelado Estructural UML Objetos y Clases (modelado de la arquitectura) 3. Modelado de Comportamiento Casos de Uso (modelado del comportamiento) 4. Modelado de Comportamiento Secuencias y Colaboración javiergs@acm.org 5. Modelado de Comportamiento
  5. 5. 1.1. Introducción: Arquitectura del Software
  6. 6. Objetivo Contextualizar al Lenguaje Unificado de Modelado dentro del proceso de desarrollo de software Definir el concepto de modelo y la importancia del modelado en el proceso de desarrollo de software Comprender los conceptos de objeto, relación, componente y capa como parte de cualquier arquitectura de software javiergs@acm.org
  7. 7. La casa del perro Recursos: • una sola persona Conocimientos: • modelado mínimo • proceso simple • herramientas simples javiergs@acm.org
  8. 8. La casa de la familia Recursos: • Un equipo Considerar: • eficiencia • tiempo razonable Requiere: • Modelado • Proceso bien definido • Herramientas sofisticadas javiergs@acm.org
  9. 9. Aclarando Ideas reglas lenguaje modelo(s) [ UML ] elementos reglas objeto (s) elementos Arquitectura reglas elementos producto real javiergs@acm.org
  10. 10. Desarrollo de Software Necesidad Notación Proceso Herramientas Producto javiergs@acm.org
  11. 11. Proceso = abstracción, modelo, objeto El modelado captura las partes esenciales del sistema Orden Objetos Item Metodologías de A&D envío Proceso de Negocios Sistema de cómputo javiergs@acm.org
  12. 12. Notación: arquitectura La mente humana puede trabajar con 7 más/menos 2 cosas a la vez … Divide y vencerás Interfase de Usuario Múltiples Sistemas (Visual Basic, Java, ..) Lógica del Negocio (C++, Java, ..) Servidor de BDs (C++ & SQL, ..) capas componentes Modelar el sistema independientemente del lenguaje de implementación Reuso de alto nivel javiergs@acm.org
  13. 13. Resumen Objeto A&D Clase Orientado a Objetos Capa Componente A&D Arquitectura Estructurado Modelo Metodología A&D Distribuido Análisis Diseño Implementación Test Deploy javiergs@acm.org
  14. 14. 1.2. Introducción: Principios de Orientación a Objetos
  15. 15. Objetivo Explicar los conceptos básicos detrás de la orientación a objetos clase, objeto, interfase atributo, estado, operación, mensaje, comunicación relación, asociación, herencia Identificar los elementos que conforman a las clases y objetos Describir las relaciones entre objetos y entre clases javiergs@acm.org
  16. 16. Contexto Problema: Actualmente, Software Grande y Complejo. Demanda de interfaces más completas, funcionalidades más elaboradas Impacto en complejidad del producto. Requisitos: Los programas deben poder ser mantenidos y ampliados con garantías de éxito. Solución: Estructuración, modelado. javiergs@acm.org
  17. 17. Objeto “cosa” del mundo real : una entidad física o abstracta representaciones abstractas de entidades del mundo, tangibles o no, con la intención de emularlas. Elemento que interviene en el proceso del negocio Estructura de datos con sus operaciones asociadas Unidad atómica que encapsula estado y comportamiento La encapsulación en un objeto permite una alta cohesión y un bajo acoplamiento Posee un OID identificador único y global dentro del sistema que es determinado en el momento de su creación. javiergs@acm.org
  18. 18. Estado y Comportamiento individual Estado: situación en que se encuentra un objeto, tal que cumple alguna condición/es particulares, realiza una actividad o espera que suceda un acontecimiento. Los objetos mantienen su estado en uno o más atributos. El estado evoluciona con el tiempo Algunos atributos pueden ser constantes El comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto. Exhibido a través de métodos Las operaciones de un objeto son consecuencia de un estímulo externo representado como mensaje enviado desde otro objeto javiergs@acm.org
  19. 19. Comunicación Un sistema informático puede verse como un conjunto de objetos autónomos y concurrentes que trabajan de manera coordinada en la consecución de un fin específico El comportamiento global se basa pues en la comunicación entre los objetos que la componen El envío de mensajes es la forma en que se invoca los comportamientos de un objeto (cada método define un comportamiento). La invocación de métodos permite a un objeto cambiar su estado o el de otro objeto. javiergs@acm.org
  20. 20. Comportamiento global Categorías de objetos: Objeto Activo: posee un hilo de ejecución (thread) propio y puede iniciar una actividad Objeto Pasivo: no puede iniciar una actividad pero puede enviar estímulos una vez que se le solicita un servicio Cliente: es el objeto que solicita un servicio. Servidor: es el objeto que provee el servicio solicitado Agente: javiergs@acm.org
  21. 21. Mensaje La unidad de comunicación entre objetos se llama mensaje El mensaje es el soporte de una comunicación que vincula dinámicamente los objetos que fueron separados previamente en el proceso de descomposición Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinámico javiergs@acm.org
  22. 22. Persistencia La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo Se dice que un objeto es reconstruido o reanimado si es trasladado de memoria secundaria a memoria primaria, para utilizarlo (materialización del objeto) javiergs@acm.org
  23. 23. Relaciones entre objetos Usar: invocar un objeto a un método de otro objeto ( asociación ) Tener: un objeto puede estar dentro de otro objeto ( composición ) Cardinalidad en las relaciones de objetos javiergs@acm.org
  24. 24. Clase Son patrones que definen qué atributos y qué métodos son comunes a un conjunto de objetos, que pertenecen a dicha clase. Es más fácil de entenderlo si se toma tipo como equivalente. Todos los objetos del mismo tipo comparten el mismo juego de atributos y métodos y, por tanto, pertenecen a la misma clase. javiergs@acm.org
  25. 25. Atributos y métodos de Clase Hay atributos que no varían de una instancia a otra. Todas las instancias de la clase tienen el mismo valor. Estos atributos que no varían de instancia a instancia se conocen como variables de clase. De manera análoga hay métodos de instancia y métodos de clase. javiergs@acm.org
  26. 26. Relación entre clases Las clases permiten su definición a partir de otras clases. Esto permite definir una jerarquía de especialización o bien generalizar a entidades existentes Una Clase definida a partir de otra, hereda todos los atributos y métodos de su clase ancestro. Las clases herederas pueden sobrescribir los atributos y los métodos heredados y pueden añadir nuevos. Las clases herederas pueden además sobrecargar los métodos heredados javiergs@acm.org
  27. 27. Herencia La clase tomada como patrón se conoce como superclase o clase padre, mientras que la heredera se llama clase hija o subclase La jerarquía de herencia puede ser todo lo profunda que sea necesario. Una clase puede tener varias clases como patrón. javiergs@acm.org
  28. 28. Interfaces Mecanismo que emplean dos objetos para interactuar. Definen un conjunto de métodos para establecer el protocolo en base al que interactúan dos objetos. Las interfaces capturan similitudes entre clases no relacionadas. Son a su vez clases, en particular clases totalmente abstractas ¿ clases abstractas ? ¿ entonces existirán métodos y/o atributos abstractos ? javiergs@acm.org
  29. 29. Polimorfismo Es la capacidad de diferentes objetos para responder al mismo mensaje, cada uno a su manera. Mensaje: hablar Objetos: gato, perro, niño Cada uno reacciona de acuerdo a su implementación Beneficios: simplicidad y flexibilidad. javiergs@acm.org
  30. 30. Resumen Objeto Composición Estado Comportamiento Agregación Encapsular Generalización Cohesión Especialización Acoplamiento IOD Sobreescribir Clase Sobrecargar Atributo Método Atributo de clase Método de clase Mensaje Herencia Polimorfismo Interfase javiergs@acm.org
  31. 31. Práctica 1 name: javiergs@acm.org
  32. 32. Práctica 1 Objetos Clases Relaciones ¿Cómo representarlas ? • Un grafo • Texto • Quizás instrucciones en un lenguaje especifico, un lenguaje de programación javiergs@acm.org
  33. 33. javiergs@acm.org
  34. 34. 2.1. Modelado: UML
  35. 35. Unified Modeling Language Un lenguaje de propósito general para el modelado orientado a objetos Grafico y textual No es una metodología, i.e. no define un ciclo de vida Documento “OMG Unified Modeling Language Specification” http://www.uml.org/ UML combina notaciones provenientes desde: Modelado Orientado a Objetos Modelado de Datos Modelado de Componentes Modelado de Flujos de Trabajo (workflow) javiergs@acm.org
  36. 36. Historia 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 javiergs@acm.org
  37. 37. Historia Microsoft Oracle HP IBM Ivar Jacobson – Use Case - OOSE Rumbaugh – Análisis - OMT Booch – Arquitectura - Booch javiergs@acm.org
  38. 38. Unificado javiergs@acm.org
  39. 39. Bloques básicos UML tiene tres bloques básicos de construcción: 1. Elementos: • estructurales: partes estáticas de los modelos, representan aspectos conceptuales o materiales. • de comportamiento: partes dinámicas de los modelos, representan comportamientos en el tiempo y espacio. • de agrupación: partes organizativas de los modelos. • de Notación: partes explicativas de los modelos. 2. Relaciones 3. Diagramas javiergs@acm.org
  40. 40. Generando modelos UML es simplemente un lenguaje. Define un conjunto de elementos y las relaciones entre ellos y esto se emplea para definir modelos. Los modelos representan : las propiedades estáticas (estructura) y las propiedades dinámicas (comportamiento) UML se usa típicamente como parte de un proceso de desarrollo, con ayuda de una herramienta CASE. UML es independiente de cualquier proceso particular, no está ligado a ningún ciclo de vida de desarrollo de software concreto. javiergs@acm.org
  41. 41. 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 javiergs@acm.org
  42. 42. 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 Existen relaciones de trazabilidad entre los diferentes modelos javiergs@acm.org
  43. 43. Diagramas de UML Los diagramas expresan gráficamente partes de un modelo desde cierta perspectiva State State Diagrams de Use Case Diagramas Diagrams Use Case Diagrams de Clases State Use Case Diagramas Diagrams State Use Case Diagrams de Diagramas Diagrams de Diagramas Casos de Uso Diagrams Diagrams Objetos Secuencia Scenario State Scenario Diagrams de State Diagrams de Diagramas Diagrams Diagramas Diagrams Colaboración Componentes Modelo(s) Scenario Component Scenario Diagrams de Component Diagrams Diagramas de Diagramas Diagrams Diagrams Estados Distribución Diagramas de Actividad Estáticos Dinámicos De Estructura De funcionalidad De arquitectura De Comportamiento javiergs@acm.org
  44. 44. Propuesta para Modelos 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) javiergs@acm.org
  45. 45. Propuesta para Diagramas 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 javiergs@acm.org
  46. 46. Ciclo de vida en RUP Flujos de trabajo fases del proceso Iniciación Elaboración Construcción Transición Modelado del negocio Requisitos Análisis y diseño Implementación Pruebas Despliegue Flujos de trabajo de soporte Gestión del cambio y configuraciones Gestión del proyecto Entorno Iteraciones Iter Iter Iter Iter Iter Iter Iter preliminares #1 #2 #n #n+1 #n+2 #m #m+1 Fuente: Jacobson et al., 2000 javiergs@acm.org
  47. 47. Resumen UML define una notación que se expresa como diagramas sirven para representar modelos/subsistemas o partes de ellos El 80 por ciento de la mayoría de los problemas pueden modelarse usando alrededor del 20 por ciento de UML– Grady Booch javiergs@acm.org
  48. 48. Práctica 2 name: javiergs@acm.org
  49. 49. Práctica 2 Diagrama Estático [ deployment ] ¿ donde se requiere el sistema ? ¿ para qué se requiere ? ¿ cómo se requiere ? Diagrama Dinámico [ actividades ] ¿ que actores están presentes en el escenario del problema ? ¿ que acciones importantes realizan? ¿ interactúan ? javiergs@acm.org
  50. 50. 2.2. Modelado: Objetos
  51. 51. Objetos y Vínculos (asociaciones) El Modelado de Objetos permite representar el ciclo de vida de los objetos a través de sus interacciones (asociación ó vinculo) En UML, un objeto se representa por un rectángulo con un nombre subrayado y estos se pueden relacionar CuentaCorriente 101 O o tro bjeto Juan Unobjeto Bancode Valencia Banco O objetom tro ás Felipe CuentaCorriente 114 javiergs@acm.org
  52. 52. Objetos y Clases Objeto = Identidad + Estado + Comportamiento El estado está representado por los valores de los atributos Un atributo toma un valor en un dominio concreto Un coche Azul 979 Kg 70 CV ... Atributo:Tipo = valor javiergs@acm.org
  53. 53. Preguntas Ejemplo de interacción ¿identificas nuevos elementos y/o relaciones? ¿esto será un diagrama? Un Objeto Operación 1 1: Un mensaje Operación 2 Se puede Otro Objeto Emplear --- javiergs@acm.org
  54. 54. Mensaje – Comportamiento - Estado Los mensajes navegan por los enlaces, a priori en ambas direcciones Estado y comportamiento están relacionados Ejemplo: no es posible aterrizar un avión si no está volando. Está volando como consecuencia de haber despegado del suelo javiergs@acm.org
  55. 55. Mensaje – Comportamiento - Estado Objeto 1 1: Mensaje A Objeto 2 2: Mensaje C 4: Mensaje E Objeto 3 Objeto 4 3: Mensaje D javiergs@acm.org
  56. 56. 2.3. Modelado de la Arquitectura: Clases
  57. 57. Clases firmaOperacion (n:tipo) visibilidad Atributo:tipo = valorinicial << estereotipos>> Paquete::clase { restricciones } Reglas de visibilidad Motocicleta Atributo público : Integer color lista Atributo protegido : Integer cilindrada Atributo privado : Integer velocidad máxima primero() ultimo() "Operación pública"() arrancar() añadir() "Operación protegida"() acelerar() quitar() "Operación privada"() frenar() cardinalidad() javiergs@acm.org
  58. 58. Paquete Todas las clases no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa El operador “::” permite designar una clase definida en un contexto distinto del actual javiergs@acm.org
  59. 59. Visibilidad Los niveles de encapsulación están heredados de los niveles de C++: (-) Privado : es el más fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminología C++) (#) Los atributos/operaciones protegidos están visibles para las clases friends y para las clases derivadas de la original (+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación) javiergs@acm.org
  60. 60. Relaciones entre Clases Los enlaces entre de objetos pueden representarse entre las respectivas clases. Formas de relación entre clases: Asociación Agregación (vista como un caso particular de asociación) Generalización/Especialización Las relaciones de Agregación y Generalización forman jerarquías de clases javiergs@acm.org
  61. 61. Asociación La asociación expresa una conexión bidireccional entre objetos Una asociación es una abstracción de la relación existente en los enlaces entre los objetos ITESM Univ. de Murcia : Universidad Un enlace Antonio : Estudiante ó vinculo U n iv e rs id a d E s tu d ia n te U n a a s o cia ció n Rol – nombre – dirección – cardinalidad - { restricciones} – asociación calificada javiergs@acm.org
  62. 62. Asociación ¿identificas nuevos elementos y/o relaciones? ¿esto será un diagrama? marido casado-con 0..1 mujer 0..1 Persona Compañía nombre * trabaja-para nombre s.s. dirección emplea-a * jefe 0..1 * Administra empleado javiergs@acm.org
  63. 63. Cardinalidad Especificación de multiplicidad (mínima...máxima) 1 Uno y sólo uno 0..1 Cero o uno M..N Desde M hasta N (enteros naturales) * Cero o muchos 0..* Cero o muchos 1..* Uno o muchos (al menos uno) La multiplicidad mínima >= 1 establece una restricción deexistencia javiergs@acm.org
  64. 64. Asociación Member-of * Committee Person * { subset } 1 Chair-of * Represents an incorporated entity. worker Person employee employer Company * * 0..1 0..1 boss {Person.employer = Person.boss.employer} javiergs@acm.org
  65. 65. Asociación Persona * Cuenta * or Asociación excluyente * Empresa 1 Usuario está-autorizado-en Estación * * Autorización Clase de asociación prioridad privilegios camb_privil() javiergs@acm.org
  66. 66. Agregación La agregación representa una relación parte_de entre objetos ¿Puede el objeto parte comunicarse directamente con objetos externos al objeto agregado? No => inclusiva Si => no inclusiva ¿Puede cambiar La composición del objeto agregado? Si => dinámica No => estática javiergs@acm.org
  67. 67. Agregación Polígono contiene Punto Agregación 1 3..* {ordenado} W in d o w s c r o llb a r [2 ] : S lid e r title : H e a d e r body : Panel Y podría colocar aquí un -- OR – ¿? W in d o w 1 1 1 s c r o llb a r 2 title 1 b o dy 1 S lid e r H e a de r Panel composición javiergs@acm.org
  68. 68. Diagramas de Clases y Diagrama de Objetos Diagrama de Clases y Diagramas de Objetos pertenecen a dos vistas complementarias del modelo Un Diagrama de Clases muestra la abstracción de una parte del dominio Un Diagrama de Objetos representa una situación concreta del dominio Las clases abstractas no son instanciadas ClaseAbstract <<interface>> Clase nombre Interface javiergs@acm.org
  69. 69. Generalización y Especialización Generalización y Especialización no son operaciones reflexivas ni simétricas pero sí transitivas Vehículo Particionamiento del espacio de objetos Clasificación Estática Particionamiento Veihículo Terrestre Vehículo Aéreo del espacio de estados de los objetos Clasificación Dinámica Coche Camión Avión Helicóptero javiergs@acm.org
  70. 70. Generalización y Especialización Ve hícu lo Aéreo Coche { estática } { dinámica } Avión Helicóptero Funcionando Estropeado javiergs@acm.org
  71. 71. Generalización y Especialización Ejemplo: varias especializaciones a partir de la misma clase padre, usando discriminadores: Comercial Militar uso Vehículo Aéreo estructura Avión Helicóptero javiergs@acm.org
  72. 72. Herencia Múltiple Uso disciplinado de la herencia múltiple: clasificaciones disjuntas con clases padre en hojas de jerarquías alternativas Bípedo Cuadrúpedo nro patas nro patas Con Pelos Herbívoro cubertura comida Animal Con Plumas cobertura comida cobertura Carnívoro Con Escamas Conejo javiergs@acm.org
  73. 73. Principio de Sustitución El Principio de Sustitución de Liskow (1987) afirma que: “Debe ser posible utilizar cualquier objeto instancia de una subclase en el lugar de cualquier objeto instancia de su superclase sin que la semántica del programa escrito en los términos de la superclase se vea afectado.” i.e. Polimorfismo El polimorfismo representa en nuestro caso la posibilidad de desencadenar operaciones distintas en respuesta a un mismo mensaje La búsqueda automática del código que en cada momento se va a ejecutar es fruto del enlace dinámico javiergs@acm.org
  74. 74. Polimorfismo Ejemplo: todo animal duerme, pero cada clase lo hace de forma distinta Animal Dormir() { dormir() } León Oso Tigre dormir() dormir() dormir() Dormir() Dormir() Dormir() { { { sobre el vientre sobrela espalda en un árbol } } } javiergs@acm.org
  75. 75. Anexo Dependencia javiergs@acm.org
  76. 76. Práctica 3 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org
  77. 77. Resumen Diagrama de Clases Es el el diagrama principal de diseño y análisis para un sistema. Durante el análisis del sistema, el diagrama se desarrolla buscando una solución ideal. Durante el diseño, se usa el mismo diagrama, y se modifica para satisfacer los detalles de las implementaciones Diagrama de Objetos Especialmente útiles para modelar estructuras de datos complejas. Evidentemente puede existir una multitud de posibles instancias de una clase particular, y para un conjunto de clases con N relaciones entre ellas, pueden existir muchas más configuraciones posibles de objetos. Diagramas de Colaboración y de Secuencia javiergs@acm.org
  78. 78. javiergs@acm.org
  79. 79. 3.1. Modelado: Casos de Uso
  80. 80. Casos de Uso Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista de un observador externo y/o el propio usuario. Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación. Describe el QUE más que el COMO Los Casos de Uso cubren la carencia existente en métodos previos (OMT, Booch) en cuanto a la determinación de requisitos Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo Están basados en el lenguaje natural, es decir, son accesibles para los usuarios (hasta cierto punto) javiergs@acm.org
  81. 81. Diagrama de Casos de Uso Caso de Uso A Actor A Caso de Uso B Actor B javiergs@acm.org
  82. 82. Relación entre los resultados Modelo de Casos de Uso verificado por especificado por realizado por Modelo de distribuido por Prueba Modelo de Análisis Modelo de implementado por Diseño Modelo de Despliegue Modelo de Implementación Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso javiergs@acm.org
  83. 83. Actores Tipos de Actores: Principales: personas que usan el sistema. Secundarios: personas que mantienen o administran el sistema. Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados. Otros sistemas: sistemas con los que el sistema interactúa La misma persona física puede interpretar varios papeles ( actores distintos ) El nombre del actor describe el papel desempeñado javiergs@acm.org
  84. 84. Relaciones: comunicación UML define cuatro tipos de relación en los Diagramas de Casos de Uso: 1. Comunicación C aso de U so Actor javiergs@acm.org
  85. 85. Relaciones: inclusión 2. Inclusión una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino <<include>> Caso de Uso Origen Caso deUso Destino <<include>> reemplaza a <<uses>> javiergs@acm.org
  86. 86. Relaciones: extensión 3. Extensión el Caso de Uso origen extiende el comportamiento del Caso de Uso destino <<extend>> Caso de Uso Origen Caso deUso Desti no javiergs@acm.org
  87. 87. Relaciones: herencia 4. Herencia el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía Caso de UsoHijo Caso de Uso Padre javiergs@acm.org
  88. 88. Ejemplo Ide n i i caci ó tf n <<include>> Transferencia Cliente << exten d>> Transferencia en Internet javiergs@acm.org
  89. 89. Ejemplo Supply Customer Data Order Product Arrange Payment <<include>> <<include>> <<include>> the salesperson asks for the catalog 1 * <<extend>> Salesperson Request Catalog Place Order javiergs@acm.org
  90. 90. Ejemplo frontera estereotipo generalización orden irrelevante javiergs@acm.org
  91. 91. Escenario Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción, los escenarios, desde el punto de vista del usuario Un escenario es una instancia de un caso de uso javiergs@acm.org
  92. 92. Construcción de Casos de Uso Un caso de uso debe ser simple, inteligible, claro y conciso Generalmente hay pocos actores asociados a cada Caso de Uso Preguntas clave: ¿cuáles son las tareas del actor? ¿qué información crea, guarda, modifica, destruye o lee el actor? ¿debe el actor notificar al sistema los cambios externos? ¿debe el sistema informar al actor de los cambios internos? javiergs@acm.org
  93. 93. Descripción La descripción del Caso de Uso comprende: objetivo del caso de uso: ¿qué lleva a cabo o intenta? el inicio: cuándo y qué actor lo produce? el fin: cuándo se produce y qué valor devuelve? la interacción actor-caso de uso: qué mensajes intercambian ambos? cronología y origen de las interacciones repeticiones de comportamiento: ¿qué operaciones son iteradas? situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el caso de uso? javiergs@acm.org
  94. 94. Documento R F - < id d e l r e q u is ito > < n o m b r e d e l r e q u is ito fu n c io n a l> V e r s ió n < n u m e r o d e v e r s ió n y f e c h a > A u to re s < a u to r> F u e n te s < f u e n t e d e la v e r s ió n a c t u a l> O b je tiv o s a s o c ia d o s < n o m b r e d e l o b je t iv o > D e s c r ip c ió n E l s is t e m a d e b e r á c o m p o r t a r s e t a l c o m o s e d e s c r ib e e n e l s ig u ie n t e c a s o d e u s o { c o n c r e t o c u a n d o < e v e n t o d e a c t iv a c ió n > , a b s t r a c t o d u r a n t e la r e a liz a c ió n d e lo s c a s o s d e u s o < lis t a d e c a s o s d e u s o > } P r e c o n d ic ió n < p r e c o n d ic ió n d e l c a s o d e u s o > S e c u e n c ia Paso A c c ió n N o rm a l 1 { E l < a c t o r > , E l s is t e m a } < a c c ió n r e a liz a d a p o r e l a c t o r o s is t e m a > , s e r e a liz a e l c a s o d e u s o < c a s o d e u s o R F -x > 2 S i < c o n d ic ió n > , { e l < a c t o r > , e l s is t e m a } < a c c ió n r e a liz a d a p o r e l a c t o r o s is t e m a > > , s e r e a liz a e l c a s o d e u s o < c a s o d e u s o R F -x > 3 4 5 6 n P o s tc o n d ic ió n < p o s t c o n d ic ió n d e l c a s o d e u s o > E x c e p c io n e s Paso A c c ió n 1 S i < c o n d ic ió n d e e x c e p c ió n > , { e l < a c t o r > , e l s is t e m a } } < a c c ió n r e a liz a d a p o r e l a c t o r o s is t e m a > > , s e r e a liz a e l c a s o d e u s o < c a s o d e u s o R F - x > , a c o n t in u a c ió n e s t e c a s o d e u s o { c o n t in u a , a b o r t a } 2 3 R e n d im ie n to Paso C o ta d e tie m p o 1 n segundos 2 n segundos F r e c u e n c ia e s p e r a d a < n º d e v e c e s > v e c e s / < u n id a d d e t ie m p o > Im p o r ta n c ia { s in im p o r t a n c ia , im p o r t a n t e , v it a l} U r g e n c ia { p u e d e e s p e r a r , h a y p r e s ió n , in m e d ia t a m e n t e } C o m e n ta r io s < c o m e n t a r io s a d ic io n a le s > javiergs@acm.org
  95. 95. Práctica 4 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org
  96. 96. Práctica 4 Casos de Uso javiergs@acm.org
  97. 97. Resumen La especificación de cada caso de uso y los correspondientes diagramas de Interacción asociados establecen el vínculo con el modelo conceptual En las metodologías Orientadas a Objeto que carecían de una técnica de captura de requisitos se comienza inmediatamente con la construcción del modelo conceptual (análisis). javiergs@acm.org
  98. 98. javiergs@acm.org
  99. 99. 4.1. Modelado: Diagramas de Interacción Secuencia y Colaboración
  100. 100. Interacción Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interacción muestran cómo se comunican los objetos en una interacción Existen dos tipos de diagramas de interacción: El Diagrama de Secuencia adecuados para observar la perspectiva cronológica de las interacciones. El Diagrama de Colaboración ofrece una mejor visión espacial mostrando los enlaces de comunicación entre objetos El Diagrama de Colaboración puede obtenerse automáticamente a partir del correspondiente Diagrama de Secuencia (o viceversa) javiergs@acm.org
  101. 101. Sintaxis para Mensajes predecesor / guarda secuencia: retorno := mensaje( args ) javiergs@acm.org
  102. 102. Diagrama de Secuencia Muestra la secuencia de mensajes entre objetos durante un escenario concreto Cada objeto viene dado por una barra vertical El tiempo transcurre de arriba abajo Cuando existe demora entre el envío y la atención se puede indicar usando una línea en diagonal javiergs@acm.org
  103. 103. Diagrama de Secuencia Describen cómo los objetos del sistema colaboran. Detalla cómo las operaciones se llevan a cabo en términos de qué mensajes son enviados y cuando (en torno al tiempo). tiempo Los corchetes expresan condición [condición]. Si son precedidos por “*” iteración mientras. Línea de vida obj. Su vida termina. Orden participación javiergs@acm.org
  104. 104. Diagrama de Secuencia Diagrama de Secuencia: Los rectángulos verticales son barras de activación. Representan la duración de la ejecución del mensaje. Mensaje asíncronos: El emisor puede enviar otros mientras éste está siendo procesado. Es independiente a otros mensajes. Mensaje síncronos: El emisor debe esperar que termine el tiempo de proceso de éste para enviar nuevos mensajes. Mensaje simple Mensaje simple Síncrono puede ser síncrono de vuelta (opt) Asíncrono o asíncrono javiergs@acm.org
  105. 105. Diagrama de Secuencia javiergs@acm.org
  106. 106. Diagrama de Secuencia Caller Exchange Receiver a: lift receiver {b.receiveTime b: dial tone - a.sendTime < 1 sec.} {c.receiveTime c: dial digit -b.sendTime < 10 sec.} ... The call is routed d: route through the network {d.receiveTime ringing tone phone rings -d.sendTime < 5 sec.} answer phone ----- < 1 sec At this point the stop tone stop ringing ----- parties can talk javiergs@acm.org
  107. 107. Diagrama de Secuencia ob 3 : C3 ob4 : C 4 Condiciones op( ) ob 1 : C1 [x > 0 ] f o o l( x ) ob2 : C2 [x < 0 ] b a r (x ) d o it ( z ) Recursion d o it ( w ) Creación y Destrucción m o re ( ) De Objetos javiergs@acm.org
  108. 108. Diagrama de Secuencia Diagram 1 ob1 : C1 [x<0] bar(x) Diagram 2 ob3 : C3 ob4 : C4 Sequence Diagram: Diagrams / Diagram 2 bar(x) doit(w) Sequence Diagram: Diagrams / Diagram 1 javiergs@acm.org
  109. 109. Diagrama de Colaboración Son útiles en la fase exploratoria para identificar objetos La distribución de los objetos en el diagrama permite observar adecuadamente la interacción de un objeto con respecto de los demás La estructura estática viene dada por los enlaces; la dinámica por el envío de mensajes por los enlaces javiergs@acm.org
  110. 110. Diagrama de Colaboración Son otro tipo de diagramas de interacción. Contienen la misma información que los diagramas de secuencia, pero se centran en la responsabilidad de cada objeto en lugar de en el tiempo en que los mensajes son enviados Cada mensaje tiene un número de secuencia. El primer nivel comienza en 1, los mensajes que son enviados durante la misma llamada a un método se numeran 1.1, 1.2 ... 1.i, tantos niveles como sea necesario. javiergs@acm.org
  111. 111. Mensajes Un mensaje desencadena una acción en el objeto destinatario Un mensaje se envía si han sido enviados los mensajes de una lista (sincronización): 1, 3 / 10:Mensaje B A javiergs@acm.org
  112. 112. Mensajes Un mensaje se envía de manera condicionada: [x>y] 1: Mensaje B A javiergs@acm.org
  113. 113. Mensajes Un mensaje que devuelve un resultado: 1: distancia:= mover(x,y) B A javiergs@acm.org
  114. 114. Secuencia vs Colaboración : WInP réstamos :Socio :Video : Préstamo : Encargado prestar(video, socio) verificar situación socio verificar situación video registrar préstamo entregar recibo javiergs@acm.org
  115. 115. Secuencia vs Colaboración :Socio :Video 2: verificar situación socio 1: prestar(video, socio) 3: verificar situación video :WInPréstamos 5: entregar recibo : Encargado 4: registrar préstamo :Préstamo javiergs@acm.org
  116. 116. Anexos Crear objeto en diagrama de colaboración amerita el uso de un estereotipo Manejar estados en el diagrama de secuencia se representa con un rectángulo redondeado en la línea de tiempo Manejar estados en el diagrama de colaboración implica colocar entre [ ] al lado derecho el nombre del estado (repitiendo al objeto en el diagrama) javiergs@acm.org
  117. 117. Resumen D. Clases Escenarios D. Casos de Uso D. Secuencia D. Colaboración D. Objetos Diagramas de Comportamiento Diagramas de Componentes Deployment javiergs@acm.org
  118. 118. Diagramas por Modelo (estático y dinámico) M ode lo de l M ode lo de l M ode lo de M ode lo de M ode lo de M ode lo de M ode lo de M ode lo M ode lo de Ne gocio Dom inio Cas os de Anális is Dis e ño Proce s os De s plie gue Im ple m e n- Prue ba Us o tación Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Diagram a de Cas os de Us o X X X Diagram a de Inte racción- X X X X X X X X Se cue ncia Diagram a de Inte racción- X X X X X X X X Colaboración Diagram a de Clas e s de X Anális is Diagram a de Obje tos de X Anális is Diagram a de Clas e s de X X Dis e ño Diagram a de Obje tos de X X Dis e ño Diagram a de Es tados X X X X X X Diagram a de Actividade s X X X X X Diagram a de Com pone nte s X Diagram a de De s plie gue X javiergs@acm.org
  119. 119. Práctica 5 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org
  120. 120. javiergs@acm.org
  121. 121. 5.1. Modelado: Estados
  122. 122. Diagrama de Estados Los Diagramas de Estados representan autómatas de estados finitos, desde el punto de vista de los estados y las transiciones Son útiles sólo para los objetos con un comportamiento significativo El formalismo utilizado proviene de los Statecharts ( Harel ) Muestra las condiciones de UN solo objeto javiergs@acm.org
  123. 123. Diagrama de Estados Cada objeto está en un estado en cierto instante El estado está caracterizado parcialmente por los valores de algunos atributos del objeto El estado en el que se encuentra un objeto determina su comportamiento Cada objeto sigue el comportamiento descrito en el Diagrama de Estados asociado a su clase Los Diagramas de Estados y escenarios son complementarios javiergs@acm.org
  124. 124. Diagrama de Estados Los Diagramas de Estados son autómatas jerárquicos que permiten expresar concurrencia, sincronización y jerarquías de objetos Los Diagramas de Estados son grafos dirigidos Los Diagramas de Estados de UML son deterministas Los estados inicial y final están diferenciados del resto La transición entre estados es instantánea y se debe a la ocurrencia de un evento javiergs@acm.org
  125. 125. Diagrama de Estados alta baja núm ero_prés tam os = 0 sin préstam os Socio número : int nombre : char[50] número_prestamos : int = 0 prestar devol ver[ núm ero_p rést amo s = 1 ] alta() baja() prestar(código_libro : int, fecha : date) devolver(código_libro : int, fecha : date) núm ero_prés tam os > 0 c on prés tam os pres tar devolver[ núm ero_prés tam os > 1 ] javiergs@acm.org
  126. 126. Ejemplo c ontratar en el paro en ac tivo desempleado perder em pleo jubilars e jubil ars e jub ilado javiergs@acm.org
  127. 127. Estados y Transiciones Evento [condición] / Acción A B Tanto el evento como la acción se consideran instantáneos javiergs@acm.org
  128. 128. Acciones Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transición: A Evento [condición] / OtroObjeto.Operación B javiergs@acm.org
  129. 129. Acciones Se puede especificar el ejecutar una acción como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento: estado A entry: acción por entrar exit: acción por salir do: acción mientras en estado on evento: acción javiergs@acm.org
  130. 130. Generalización de Estados Podemos reducir la complejidad de estos diagramas usando la generalización de estados Distinguimos así entre superestado y subestados Un estado puede contener varios subestados disjuntos Los subestados heredan las variables de estado y las transiciones externas javiergs@acm.org
  131. 131. Generalización de Estados e1 A B a e1 b A B e2 e2 e2 C C javiergs@acm.org
  132. 132. Generalización de Estados Sin embargo. Las transiciones de entrada deben ir hacia subestados específicos: e1 a A b B e2 e0 C javiergs@acm.org
  133. 133. Generalización de Estados O bien tener estados iniciales de entrada en el nivel e1 Aa b B e2 C e0 javiergs@acm.org
  134. 134. Generalización de Estados lif t r e c e iv e r / g e t d ia l to n e A c t iv e T im e o u t d o / p la y m e s s a g e a f t e r ( 1 5 s e c .) d ia l d ig it ( n ) [ in c o m p le t e ] a f t e r ( 1 5 s e c .) D ia lT o n e d ia l d ig it ( n ) D ia lin g d o / p l a y d i a l to n e Id le di a l d ig it ( n )[ inv a l id ] d ia l d ig it ( n ) [ v a lid ] c a lle r h a n g s u p P in n e d In v a li d / connect / d i sc o n n ec t d o / p la y m e s s a g e c a l le e C o n n e c t in g c a lle e hang h an g s s up up busy Busy c o n n e c te d d o / p la y b u s y t o n e T a lk in g R in g in g c a lle e a n s w e r s d o / p l a y r i n g i n g to n e / e n a b le speech javiergs@acm.org
  135. 135. Composición de Estados La composición es concurrente por lo que el objeto estará en alguno de los estados de cada uno de los subestados concurrentes e1 e1 javiergs@acm.org
  136. 136. Historia Por defecto, los autómatas no tienen memoria A Es posible memorizar el último subestado visitado d2 B para recuperarlo en una transición entrante en el in superestado que lo engloba D x y out d1 C También es posible la memorización para cualquiera de los subestados anidados (aparece un * junto a la H) H* javiergs@acm.org
  137. 137. Historia Enjuague Lavado Secado H cerrar puerta abir puerta Espera javiergs@acm.org
  138. 138. Destrucción del Objeto La destrucción de un objeto es efectiva cuando el flujo de control del autómata alcanza un estado final no anidado La llegada a un estado final anidado implica la “subida” al superestado asociado, no el fin del objeto c ras h E n vuelo des pegar aterriz ar Crear(m atric ula) E n t ierra javiergs@acm.org
  139. 139. Transiciones temporizadas Las esperas son actividades que tienen asociada cierta A duración / Abrir ranura La actividad de espera se interrumpe cuando el evento después de esperado tiene lugar esperar dinero 30 segundos entry: Mostrar mensaje anular transacción Este evento desencadena una exit: cerrar ranura transición que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro Depósito efectuado estado B javiergs@acm.org
  140. 140. Estados Sincronizados Los estados pueden anidarse, agrupando estados relacionados en un estado compuesto. Puede ser necesario cuando una actividad involucra actividades concurrentes o asíncronas. javiergs@acm.org
  141. 141. Resumen Los Diagramas de Estados facilitan la comprensión de los objetos a analistas, diseñadores y desarrolladores javiergs@acm.org
  142. 142. Práctica 6 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org
  143. 143. 5.2. Modelado: Actividades
  144. 144. Diagrama de Actividad El Diagrama de Actividad es una especialización del Diagrama de Estado, organizado respecto de las acciones y usado para especificar: • Un método • Un caso de uso Las actividades se enlazan por transiciones automáticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad javiergs@acm.org
  145. 145. Diagrama Dinámico: Actividades Son diagramas de flujo adornados, con mucha similitud a los diagramas de estados. Mientras los diagramas de estados centran su atención en el proceso que lleva a cabo un objeto, los diagramas de actividades muestran como las actividades fluyen y las dependencias entre ellas. javiergs@acm.org
  146. 146. Ejemplo Customer Sales Stockroom Request service Take order Play Fill order Deliver order Collect order javiergs@acm.org
  147. 147. Ejemplo C u st o m er S ales S t o ckro o m Re q ue st se rv i c e O rd e r [p la c e d ] T a k e o rd e r O rd e r [e n te r e d ] P la y F i l l o rd e r O rd e r D e l i v e r o rd e r O rd e r [d e live r ed ] [fille d ] C o l l e c t o rd e r javiergs@acm.org
  148. 148. Ejemplo B u s c a r B e b id a [ n o h a y c a fé ] [ no zumo ] [ h a y c a fé ] [ hay z um o ] P o n e r c a fé A ñ ad i r a g u a C o g e r ta z a e n filtro a l d e p ós ito C oger zumo P o n e r filtro e n m á q u in a Encender m áq u in a / c a fe t e ra .O n C afé e n p re p a ra c ió n i n di c a do r d e fi n S e rv ir c a fé B eber javiergs@acm.org
  149. 149. Ejemplo P a s a j e ro V ende do r A i r l i ne S o lic it a r p a s a je V e r if ic a r e x is t e n c ia v u e lo D a r d e t a lle s v u e lo I n fo r m a r a lt e r n a ti v a s y p r e c io s S e le c c io n a r v u e lo S o lic it a r R e s e rv a r pago pla z as C o n fir m a r p la z a Pagar re s e rv a d a p a s a je E m itir b i ll e t e javiergs@acm.org
  150. 150. Práctica 7 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org
  151. 151. 6.1. Para recordar: programando objetos
  152. 152. Herencia, Interfase, Polimorfismo, static, et al. Libro Revista Imagen precio año path isbn volumen mimet ype Documento imprimir() imprimir() pint ar() imprimir() 1 Configuracion BackgroundColor FontColor 0.. 1 leerArchivoCfg() Acervo t itulo resumen 0.. n keywords imprimir() Bibliot eca GUI 1 llenar() main() inventario() javiergs@acm.org
  153. 153. 6.2. Modelado: componentes
  154. 154. Diagrama de Componentes Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones Muestran las opciones de realización incluyendo código fuente, binario y ejecutable Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente Tipos de Componentes: De distribución: DLL, EXE, Java Beans o controles ActiveX De trabajo: archivos de base de datos y de codigo fuente De ejecución: creados por/para la ejecución del sistema (archivos) javiergs@acm.org
  155. 155. ...Diagrama de Componentes Paquete::componente Listar clases logo.gif javiergs@acm.org
  156. 156. Componentes y su distribución javiergs@acm.org
  157. 157. Notación NewPackageSpec NewMainSubprog NewPackageBody NewSubprogSpec NewComponent javiergs@acm.org
  158. 158. 6.3. Modelado: deployment
  159. 159. Diagrama de despliegue/deployment Muestra la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos Los estereotipos permiten precisar la naturaleza del equipo: Dispositivos Procesadores Memoria Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse NewP rocessor NewDevice N od o javiergs@acm.org
  160. 160. BIOS javiergs@acm.org 4.17. El UML
  161. 161. Diagrama de despliegue/deployment Podemos distinguir tipos de nodos y conexiones por estereotipado <<Cliente>> <<Servidor>> Terminal Punto <<TCP/IP>> Base de de Venta Datos <<RDSI>> <<RDSI>> Control javiergs@acm.org
  162. 162. Combinación Servidor Central Control y Análisis Acceso a BD C C Rutinas de Coneccion C Terminal de Consulta Interfaz de Terminal Rutinas de Coneccion C C Punto de Venta Rutinas de Coneccion C Gestión de Cuentas Interfaz de Terminal C C javiergs@acm.org
  163. 163. Práctica 8 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org
  164. 164. 6.4. Modelado: RUP
  165. 165. Proceso de Desarrollo de Software Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo PRINCIPIOS DE PRINCIPIOS DE LA INGENIERÍA DEL SOFTWARE LA INGENIERÍA DEL SOFTWARE NORMAS TÉCNICAS NORMAS DE NORMAS DE OTRAS LA INGENIERÍA DEL SOFTWARE NORMAS LA INGENIERÍA DEL SOFTWARE ESTÁNDARES MODELOS DE METODOLOGÍAS METODOLOGÍAS MODELOS DE PROCESO / /PARADIGMAS PARADIGMAS PROCESO PROCESO RUP TÉCNICAS TÉCNICAS HERRAMIENTAS HERRAMIENTAS PRODUCTO No existe un proceso de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable javiergs@acm.org
  166. 166. Rational Unified Process Rational Unified Process • Pruebas funcionales 1998 • Pruebas de desempeño • Gestión de requisitos Rational Objectory Process • Gestión de cambios y 1996-1997 configuración • Ingeniería de Negocio Objectory Process • Ingeniería de datos 1987-1995 • Diseño de interfaces javiergs@acm.org
  167. 167. RUP es iterativo Un enfoque iterativo propone una comprensión incremental del problema a través de refinamientos sucesivos y un crecimiento incremental de una solución efectiva a través de varias versiones. Como parte del enfoque iterativo se encuentra la flexibilidad para acomodarse a nuevos requisitos o a cambios tácticos en los objetivos del negocio. Permite que el proyecto identifique y resuelva los riesgos más bien pronto que tarde. javiergs@acm.org
  168. 168. RUP es centrado en la arquitectura El proceso se centra en establecer al principio una arquitectura de software que guía el desarrollo del sistema: La arquitectura de un sistema es el conjunto de decisiones significativas que se toma en torno a su organización, la selección de elementos estructurales, la definición de las interfaces entre estos elementos, su comportamiento, su división en subsistemas, qué elementos son estáticos y cuales dinámicos. Este diseño arquitectónico sirve como una sólida base sobre la cual se puede planificar y manejar el desarrollo de software basado en componentes. javiergs@acm.org
  169. 169. RUP esta dirigido por casos de uso El Proceso Unificado pone un gran énfasis en la construcción de sistemas basada en una amplia comprensión de cómo se utilizará el sistema que se entregue. Las nociones de los casos de uso y los escenarios se utilizan para guiar el flujo de procesos desde la captura de los requisitos hasta las pruebas, y para proporcionar caminos que se pueden reproducir durante el desarrollo del sistema. javiergs@acm.org
  170. 170. RUP es un proceso configurable Aunque un único proceso no es adecuado para todas las organizaciones de desarrollo de software, el Proceso Unificado es adaptable y puede configurarse para cubrir las necesidades de proyectos que van desde pequeños equipos de desarrollo de software hasta grandes empresas de desarrollo. También se basa en una arquitectura de proceso simple y clara, que proporciona un marco común a toda una familia de procesos y que, además, puede variarse para acomodarse a distintas situaciones. javiergs@acm.org
  171. 171. RUP es orientado a objetos Los modelos del Proceso Unificado se basan en los conceptos de objeto y clase y las relaciones entre ellos. javiergs@acm.org
  172. 172. RUP impulsa control de calidad La evaluación de la calidad va contenida en el proceso, en todas las actividades, e implicando a todos los participantes, mediante medidas y criterios objetivos. No se trata como algo a posteriori o una actividad separada. La gestión del riesgo va contenida en el proceso, de manera que los riesgos para el éxito del proyecto se identifican y se acometen al principio del proceso de desarrollo, cuando todavía hay tiempo de reaccionar. javiergs@acm.org
  173. 173. RUP es matricial RUP tiene una estructura matricial donde se relacionan esfuerzos y tiempos Los tiempos están definidos por las fases y las iteraciones. Los esfuerzos están definidos por los flujos de trabajo del proceso y de soporte. La representación gráfica se denomina en la jerga el Diagrama de Montañas. javiergs@acm.org
  174. 174. Ciclo de vida en RUP Flujos de trabajo fases del proceso Iniciación Elaboración Construcción Transición Modelado del negocio Requisitos Análisis y diseño Implementación Pruebas Despliegue Flujos de trabajo de soporte Gestión del cambio y configuraciones Gestión del proyecto Entorno Iteraciones Iter Iter Iter Iter Iter Iter Iter preliminares #1 #2 #n #n+1 #n+2 #m #m+1 Fuente: Jacobson et al., 2000 javiergs@acm.org
  175. 175. Elementos Los resultados de los flujos de trabajo de proceso son los MODELOS. La conjunción de tiempo (fases) y esfuerzos (flujos de trabajo) da lugar a las iteraciones. La conjunción de resultados (modelos) y esfuerzos (flujos de trabajo) da lugar a los tipos de modelos. La conjunción de tiempo (fases) y resultados (modelos) da lugar a las versiones. Se puede representar esta estructura conceptual (metamodelo) mediante una figura tridimensional donde: Eje X: Fases tiempo Eje Y: Flujos de trabajo esfuerzos Eje Z: Modelos resultados javiergs@acm.org
  176. 176. Metamodelo resultados Z: Modelos (x,z): versiones X,Y,Z: (y,z): tipos de Configuraciones modelos del sistema tiempo X: Fases esfuerzo Y: Flujos (x,y): iteraciones de trabajo javiergs@acm.org
  177. 177. Fases Iniciación. Se establece la planificación del proyecto y se delimita su alcance. Elaboración. Se analiza el dominio del problema, se establece una base arquitectónica sólida, se desarrolla el plan del proyecto y se eliminan los elementos de más alto riesgo del proyecto. Construcción. Se desarrolla de forma iterativa e incremental un producto completo que está preparado para la transición hacia la comunidad de usuarios. Transición. El software se despliega en la comunidad de usuarios. javiergs@acm.org

×