200505 - Modelado de Software con UML

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    6 Favorites

    200505 - Modelado de Software con UML - Presentation Transcript

    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. javiergs@acm.org
    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. 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. 1.1. Introducción: Arquitectura del Software
    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. La casa del perro Recursos: • una sola persona Conocimientos: • modelado mínimo • proceso simple • herramientas simples javiergs@acm.org
    8. La casa de la familia Recursos: • Un equipo Considerar: • eficiencia • tiempo razonable Requiere: • Modelado • Proceso bien definido • Herramientas sofisticadas javiergs@acm.org
    9. Aclarando Ideas reglas lenguaje modelo(s) [ UML ] elementos reglas objeto (s) elementos Arquitectura reglas elementos producto real javiergs@acm.org
    10. Desarrollo de Software Necesidad Notación Proceso Herramientas Producto javiergs@acm.org
    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. 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. 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. 1.2. Introducción: Principios de Orientación a Objetos
    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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Práctica 1 name: javiergs@acm.org
    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. javiergs@acm.org
    34. 2.1. Modelado: UML
    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. 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. Historia Microsoft Oracle HP IBM Ivar Jacobson – Use Case - OOSE Rumbaugh – Análisis - OMT Booch – Arquitectura - Booch javiergs@acm.org
    38. Unificado javiergs@acm.org
    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. 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. 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. 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. 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. 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. 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. 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. 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. Práctica 2 name: javiergs@acm.org
    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. 2.2. Modelado: Objetos
    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. 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. 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. 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. 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. 2.3. Modelado de la Arquitectura: Clases
    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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Anexo Dependencia javiergs@acm.org
    76. Práctica 3 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org
    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. javiergs@acm.org
    79. 3.1. Modelado: Casos de Uso
    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. Diagrama de Casos de Uso Caso de Uso A Actor A Caso de Uso B Actor B javiergs@acm.org
    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. 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. 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. 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. 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. 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. Ejemplo Ide n i i caci ó tf n <<include>> Transferencia Cliente << exten d>> Transferencia en Internet javiergs@acm.org
    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. Ejemplo frontera estereotipo generalización orden irrelevante javiergs@acm.org
    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. 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. 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. 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. Práctica 4 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org
    96. Práctica 4 Casos de Uso javiergs@acm.org
    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. javiergs@acm.org
    99. 4.1. Modelado: Diagramas de Interacción Secuencia y Colaboración
    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. Sintaxis para Mensajes predecesor / guarda secuencia: retorno := mensaje( args ) javiergs@acm.org
    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. 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. 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. Diagrama de Secuencia javiergs@acm.org
    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. 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. 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. 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. 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. 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. Mensajes Un mensaje se envía de manera condicionada: [x>y] 1: Mensaje B A javiergs@acm.org
    113. Mensajes Un mensaje que devuelve un resultado: 1: distancia:= mover(x,y) B A javiergs@acm.org
    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. 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. 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. 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. 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. Práctica 5 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org
    120. javiergs@acm.org
    121. 5.1. Modelado: Estados
    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. 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. 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. 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. Ejemplo c ontratar en el paro en ac tivo desempleado perder em pleo jubilars e jubil ars e jub ilado javiergs@acm.org
    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. 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. 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. 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. Generalización de Estados e1 A B a e1 b A B e2 e2 e2 C C javiergs@acm.org
    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. 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. 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. 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. 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. Historia Enjuague Lavado Secado H cerrar puerta abir puerta Espera javiergs@acm.org
    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. 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. 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. Resumen Los Diagramas de Estados facilitan la comprensión de los objetos a analistas, diseñadores y desarrolladores javiergs@acm.org
    142. Práctica 6 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org
    143. 5.2. Modelado: Actividades
    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. 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. Ejemplo Customer Sales Stockroom Request service Take order Play Fill order Deliver order Collect order javiergs@acm.org
    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. 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. 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. Práctica 7 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org
    151. 6.1. Para recordar: programando objetos
    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. 6.2. Modelado: componentes
    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. ...Diagrama de Componentes Paquete::componente Listar clases logo.gif javiergs@acm.org
    156. Componentes y su distribución javiergs@acm.org
    157. Notación NewPackageSpec NewMainSubprog NewPackageBody NewSubprogSpec NewComponent javiergs@acm.org
    158. 6.3. Modelado: deployment
    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. BIOS javiergs@acm.org 4.17. El UML
    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. 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. Práctica 8 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org
    164. 6.4. Modelado: RUP
    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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
    178. Iteraciones Flujos de trabajo del proceso Iniciación Elaboración Construcción Transición F1: Modelado del negocio F2: Requisitos F3: Análisis y diseño F4: Implementación F5: Pruebas F6: Despliegue Flujos de trabajo de soporte F7: Gestión del cambio y configuraciones F8: Gestión del proyecto F9: Entorno Iteraciones Iter Iter Iter Iter Iter Iter Iter preliminares#1 #2 #n #n+1 #n+2 #m #m+1 F2 F2 F3 F2 F1 F1 F4 F3 F3 F1 F9 F9 F9 F4 F4 F8 F8 F5 F8 F5 F5 F7 F6 F7 F6 F6 F7 javiergs@acm.org
    179. Iteraciones Cada iteración pasa a través de varios flujos de trabajo del proceso, aunque con un énfasis diferente en cada uno de ellos, dependiendo de la fase en que se encuentre: Durante la iniciación, el interés se orienta hacia el análisis y el diseño. También durante la elaboración. Durante la construcción, la actividad central es la implementación. La transición se centra en el deployment de la aplicación javiergs@acm.org
    180. Flujos de Trabajo Los esfuerzos aplicados en el ciclo de vida de desarrollo son de dos tipos: Flujos de trabajo del proceso: Conjunto de actividades fundamentalmente técnicas. Flujos de trabajo de soporte: Conjunto de actividades fundamentalmente de gestión. javiergs@acm.org
    181. Flujos de Trabajo del Proceso 1. Modelado del negocio: describe la estructura y la dinámica de la organización. 2. Requisitos: describe el método basado en casos de uso para extraer los requisitos. 3. Análisis y diseño: describe las diferentes vistas arquitectónicas. 4. Implementación: tiene en cuenta el desarrollo de software, la prueba de unidades y la integración. 5. Pruebas: describe los casos de pruebas, los procedimientos y las métricas para evaluación de defectos. 6. Despliegue/Deploy: cubre la configuración del sistema entregable. javiergs@acm.org
    182. Flujos de Trabajo de Soporte 1. Gestión de configuraciones: controla los cambios y mantiene la integridad de los artefactos de un proyecto. 2. Gestión del Proyecto: describe varias estrategias de trabajo en un proceso iterativo. 3. Entorno: cubre la infraestructura necesaria para desarrollar un sistema. javiergs@acm.org
    183. Flujos de Trabajo Flujos de trabajo 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 javiergs@acm.org
    184. Resultados Cada actividad del Proceso Unificado lleva algunos artefactos asociados. Algunos artefactos: Se utilizan como entradas directas en las actividades siguientes. Se mantienen como recursos de referencia en el proyecto. Se generan en algún formato específico, en forma de entregas definidas en el contrato. Los modelos son el tipo de artefacto más importante en el Proceso Unificado. Hay nueve modelos que en conjunto cubren todas las decisiones importantes implicadas en la visualización, especificación, construcción y documentación de un sistema con gran cantidad de software. javiergs@acm.org
    185. Resultados • Modelo del negocio: establece una abstracción de la organización. • Modelo del dominio: establece el contexto del sistema. • Modelo de casos de uso: establece los requisitos funcionales del sistema. • Modelo de análisis (opcional): establece un diseño de las ideas. • Modelo de diseño: establece el vocabulario del problema y su solución. • Modelo del proceso (opcional): establece los mecanismos de concurrencia y sincronización del sistema. • Modelo de despliegue: establece la topología hardware sobre la cual se ejecutará el sistema. • Modelo de implementación: establece las partes que se utilizarán para ensamblar y hacer disponible el sistema físico. • Modelo de pruebas: establece las formas de validar y verificar el sistema. javiergs@acm.org
    186. 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 javiergs@acm.org
    187. Resultados por Flujo de Trabajo Modelado del Implementa- Requisitos Análisis Diseño Prueba Despliegue Negocio ción Modelo del Negocio X Modelo del Dominio X X Modelo de Casos de Uso X Modelo de Análisis X Modelo de Diseño X Modelo de Procesos X Modelo de Despliegue X X Modelo de Implementación X X Modelo de Prueba X X javiergs@acm.org
    188. 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
    189. Agrupación de modelos en vistas vocabulario, ensamblado del funcionalidad sistema, Vista de gestión de Vista de diseño configuraciones implementación comportamiento Vista de casos de uso Vista de Vista de procesos despliegue Funcionamiento, topología del capacidad de sistema, crecimiento, distribución, rendimiento entrega, instalación javiergs@acm.org
    190. Agrupación de modelos en vistas Cada una de las vistas presenta: • Aspectos estáticos: mediante los diagramas estructurales de UML. • Aspectos dinámicos: mediante diagramas dinámicos de UML. Ejemplo: se puede trabajar con la vista de casos de uso estática y la vista de casos de uso dinámica, la vista de diseño estática y la vista de diseño dinámica, y así sucesivamente. javiergs@acm.org
    191. Diagramas por Vista Nombre Descripción Aspectos Aspectos Estáticos Dinámicos Vista de casos Proyecta el comportamiento del sistema tal y como Diagramas de casos de Diagramas de interacción de uso es percibido por los: usuarios finales, analistas y en- uso Diagramas de estados cargados de las pruebas. Especifica las fuerzas que configuran la arquitectura del sistema. Vista de diseño Soporta los requisitos funcionales del sistema: servi- Diagramas de clases Diagramas de interacción cios proporcionados a los usuarios finales. Vocabula- Diagramas de objetos Diagramas de estados rio del problema y su solución: clases, interfaces y colaboraciones. Diagramas de actividades Vista de procesos Cubre el funcionamiento, capacidad de crecimiento y Diagramas de clases Diagramas de interacción rendimiento del sistema. Mecanismos de sincroniza- (activas) Diagramas de estados ción y concurrencia del sistema: hilos y procesos. Diagramas de objetos Diagramas de actividades Vista de implementa- Cubre la gestión de configuraciones de las distintas Diagramas de componen- Diagramas de interacción ción versiones de un sistema a partir de componentes y tes Diagramas de estados archivos quasi-independientes. Ensamblado y dispo- nibilidad del sistema: componentes y archivos. Diagramas de actividades Vista de despliegue Contiene los nodos que forman la arquitectura (topo- Diagramas de despliegue Diagramas de interacción logía) hardware sobre la que se ejecuta el sistema a Diagramas de estados través de sus componentes. Está destinada a repre- sentar la distribución, entrega e instalación de las Diagramas de actividades partes que forman el sistema informático físico. javiergs@acm.org
    192. Diagramas por Vista Diagra- Diagrama Diagrama Diagra- Diagra- Diagrama Diagrama Diagrama Diagrama ma de de de ma de ma de de de de Compo- de Desplie- Casos de Interac- Interacción- Clases Objetos Estados Activida- nentes gue Uso ción- Colabora- des Secuen- ción cia Vista de Casos Estática de Uso Dinámica Vista de Estática Diseño Dinámica Vista de Estática Procesos Dinámica Vista de Estática Implemen- tación Dinámica Vista de Estática Despliegue Dinámica javiergs@acm.org
    193. Resumen Fases Iteraciones Flujos de trabajo Artefactos Modelos Diagramas Vistas javiergs@acm.org
    194. Conclusiones:
    195. Conclusiones Notación UML Herramientas Proceso p.e. Rational Rose p.e. Rational Unified Process javiergs@acm.org
    196. Como usar RUP Un ejemplo de proceso para la construcción de un programa, podría ser similar al siguiente, teniendo en cuenta que el proceso descrito deja muchas cosas por ampliar. 1. mantener reuniones con los usuarios finales del programa, para comprender sus necesidades, el contexto en que lo usarán y todos los detalles necesarios para comprender el ámbito del problema a resolver. Esta información será empleada para capturar las actividades y procesos involucrados y susceptibles de ser incorporados en el programa, a un nivel alto, y proporcionará la base para construir la vista de Casos de Uso. javiergs@acm.org
    197. Como usar RUP 2. Construir la vista de Casos de Uso definiendo exactamente la funcionalidad que se va a incorporar en el programa, desde el punto de vista de sus usuarios. El modelo resultante es realmente un mapeo de la información obtenida en el paso anterior, en el que cada nuevo Caso de Uso realiza un aspecto de la funcionalidad planteada. Refinar, en conjunto con los usuarios finales, todos los diagramas de Casos de Uso, incluyendo requisitos y restricciones, para llegar a un acuerdo común en lo que el programa hará y no hará. En este punto puede ser conveniente diseñar escenarios de prueba que ayuden a verificar si el programa finalizado cumple con las expectativas del contrato. javiergs@acm.org
    198. Como usar RUP 3. Partiendo del modelo de Casos de Uso se comienza a estructurar los requisitos en una arquitectura llamada “línea base”. Se definen clases y relaciones entre ellas, los primeros diagramas de secuencia y colaboración, definiendo los comportamientos de cada clase, también las interfaces entre los diferentes elementos de la arquitectura. Se construye aquí la vista de diseño y la vista de procesos. Construir diagramas de clases más elaborados y refinar los comportamientos del sistema. 4. A medida que crece el modelo se puede fraccionar en componentes software y paquetes. Aparecen nuevos requisitos que deben ser integrados. Se define la vista de despliegue, que define la arquitectura física del sistema, y la vista de implementación. javiergs@acm.org
    199. Como usar RUP 5. Construir el sistema, repartiendo las tareas entre el equipo de programación. 6. Buscar errores de programación, o incluso de diseño, corregirlos e ir sacando sucesivas versiones del programa hasta llegar a una versión que cumpla con todos los requisitos especificados en el contrato con los usuarios. 7. Entregar el programa a los usuarios finales. javiergs@acm.org
    200. Bibliografía UML™ Resource Page [ www.omg.org/uml/ ] El Lenguaje Unificado de Modelado¸Addison Wesley, Grady Booch, James Rumbaugh, Ivar Jacobson, (1996) javiergs@acm.org
    201. Gracias ! Javier González Sánchez, MCs Javier González Sánchez, MCs javiergs@itesm.mx javiergs@itesm.mx javiergs@acm.org
    SlideShare Zeitgeist 2009

    + Javier Gonzalez SanchezJavier Gonzalez Sanchez Nominate

    custom

    807 views, 6 favs, 1 embeds more stats

    Contextualizacion del Lenguaje Unificado de Modelad more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 807
      • 802 on SlideShare
      • 5 from embeds
    • Comments 0
    • Favorites 6
    • Downloads 0
    Most viewed embeds
    • 5 views on http://javiergs.com

    more

    All embeds
    • 5 views on http://javiergs.com

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories