200505 - Modelado de Software con UML

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

javiergs@acm.org

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

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

1.1. Introducción: Arquitectura del Software

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

La casa del perro Recursos: • una sola persona Conocimientos: • modelado mínimo • proceso simple • herramientas simples javiergs@acm.org

La casa de la familia Recursos: • Un equipo Considerar: • eficiencia • tiempo razonable Requiere: • Modelado • Proceso bien definido • Herramientas sofisticadas javiergs@acm.org

Aclarando Ideas reglas lenguaje modelo(s) [ UML ] elementos reglas objeto (s) elementos Arquitectura reglas elementos producto real javiergs@acm.org

Desarrollo de Software Necesidad Notación Proceso Herramientas Producto javiergs@acm.org

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

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

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

1.2. Introducción: Principios de Orientación a Objetos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Práctica 1 name: javiergs@acm.org

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

javiergs@acm.org

2.1. Modelado: UML

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

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

Historia Microsoft Oracle HP IBM Ivar Jacobson – Use Case - OOSE Rumbaugh – Análisis - OMT Booch – Arquitectura - Booch javiergs@acm.org

Unificado javiergs@acm.org

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

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

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

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

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

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

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

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

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

Práctica 2 name: javiergs@acm.org

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

2.2. Modelado: Objetos

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

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

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

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

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

2.3. Modelado de la Arquitectura: Clases

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Anexo Dependencia javiergs@acm.org

Práctica 3 Titulo Resumen Contenido Foto archivos anexos reportero admin usuario javiergs@acm.org

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

javiergs@acm.org

3.1. Modelado: Casos de Uso

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

Diagrama de Casos de Uso Caso de Uso A Actor A Caso de Uso B Actor B javiergs@acm.org

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

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

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

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

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

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

Ejemplo Ide n i i caci ó tf n <<include>> Transferencia Cliente << exten d>> Transferencia en Internet javiergs@acm.org

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

Ejemplo frontera estereotipo generalización orden irrelevante javiergs@acm.org

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

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

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

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

Práctica 4 Casos de Uso javiergs@acm.org

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

javiergs@acm.org

4.1. Modelado: Diagramas de Interacción Secuencia y Colaboración

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

Sintaxis para Mensajes predecesor / guarda secuencia: retorno := mensaje( args ) javiergs@acm.org

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

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

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

Diagrama de Secuencia javiergs@acm.org

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

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

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

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

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

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

Mensajes Un mensaje se envía de manera condicionada: [x>y] 1: Mensaje B A javiergs@acm.org

Mensajes Un mensaje que devuelve un resultado: 1: distancia:= mover(x,y) B A javiergs@acm.org

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

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

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

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

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

javiergs@acm.org

5.1. Modelado: Estados

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

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

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

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

Ejemplo c ontratar en el paro en ac tivo desempleado perder em pleo jubilars e jubil ars e jub ilado javiergs@acm.org

Estados y Transiciones Evento [condición] / Acción A B Tanto el evento como la acción se consideran instantáneos javiergs@acm.org

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

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

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

Generalización de Estados e1 A B a e1 b A B e2 e2 e2 C C javiergs@acm.org

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

Generalización de Estados O bien tener estados iniciales de entrada en el nivel e1 Aa b B e2 C e0 javiergs@acm.org

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

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

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

Historia Enjuague Lavado Secado H cerrar puerta abir puerta Espera javiergs@acm.org

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

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

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

Resumen Los Diagramas de Estados facilitan la comprensión de los objetos a analistas, diseñadores y desarrolladores javiergs@acm.org

5.2. Modelado: Actividades

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

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

Ejemplo Customer Sales Stockroom Request service Take order Play Fill order Deliver order Collect order javiergs@acm.org

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

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

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

6.1. Para recordar: programando objetos

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

6.2. Modelado: componentes

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

...Diagrama de Componentes Paquete::componente Listar clases logo.gif javiergs@acm.org

Componentes y su distribución javiergs@acm.org

Notación NewPackageSpec NewMainSubprog NewPackageBody NewSubprogSpec NewComponent javiergs@acm.org

6.3. Modelado: deployment

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

BIOS javiergs@acm.org 4.17. El UML

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

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

6.4. Modelado: RUP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 representar la distribución, entrega e instalación de las Diagramas de actividades partes que forman el sistema informático físico. javiergs@acm.org

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

Resumen Fases Iteraciones Flujos de trabajo Artefactos Modelos Diagramas Vistas javiergs@acm.org

Conclusiones:

Conclusiones Notación UML Herramientas Proceso p.e. Rational Rose p.e. Rational Unified Process javiergs@acm.org

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

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

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

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

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

Gracias ! Javier González Sánchez, MCs Javier González Sánchez, MCs javiergs@itesm.mx javiergs@itesm.mx javiergs@acm.org

200505 - Modelado de Software con UML

0 comments

Notes on slide 1

6 Favorites