VII CONGRESO NACIONAL DE INFORMÁTICA DE LA SALUD Madrid, 24-26 de marzo de 2004. Tutorial. UML y Proceso Unificado en Informática Biomédica. Òscar Coltell , y Miguel Arregui. Grupo de Integración y Re-Ingeniería de Sistemas (IRIS) Departamento de Lenguajes y Sistemas Informáticos - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Problema: Actualmente, Software Grande y Complejo.Demanda de interfaces más completas, funcionalidadesmás elaboradas Impacto en complejidad del producto.
Requisitos: Los programas deben poder ser mantenidos yampliados con garantías de éxito.
Ante problemas complejos Divide y vence Estructura
Modela
Modelar es diseñar y estructurar, antes de programar.Sirve para visualizar un diseño y especificar su estructura y comportamiento. Se abstraen los detalles del problema complejo simplificando su desarrollo.
Objeto: Intuitivamente todo lo que tiene masa, aunquetambién hay objetos no tangibles. En informática, definenrepresentaciones abstractas de entidades del mundo, tangibles o no, con la intención de emularlas.
Objetos mudo real Objetos informáticos
3.1. La Orientación a Objetos3.1. La Orientación a Objetos
Los objetos se caracterizan por su estado y comportamiento.
Estado: Situación en que se encuentra un objeto, tal quecumple alguna condición/es particulares, realiza una actividad o espera que suceda un acontecimiento.
Los objetos mantienen su estado en uno o mas atributos.
Atributo: Dato identificado por un nombre.
3.2. La Orientación a Objetos3.2. La Orientación a Objetos
Los objetos revelan su utilidad en un contexto de comunicación con otros objetos, por medio del paso de mensajes, para componer un sistema con un comportamiento más complejo que el suyo propio.
3.4. La Orientación a Objetos3.4. La Orientación a Objetos
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 juegode atributos y métodos y, por tanto, pertenecen a la misma clase.
3.6. La Orientación a Objetos3.6. La Orientación a Objetos
Cada objeto tiene sus atributos y sus métodos, empleando unaclase como patrón. Una vez creado el objeto pasa a ser unainstancia particular de la clase a la que pertenece.
Dos objetos distintos de la misma clase pueden tener el mismo valor en todos sus atributos. Estos atributos que pueden variar de instancia a instancia se conocen comovariables de instancia.
3.7. La Orientación a Objetos3.7. La Orientación a Objetos
Hay atributos que no varían de una instancia a otra. Todas lasinstancias de la clase tienen el mismo valor. Estos atributos que no varían de instancia a instancia se conocen comovariables de clase.
De manera análoga hay métodos de instancia y métodos de clase.
3.8. La Orientación a Objetos3.8. La Orientación a Objetos
Herencia: Los objetos se definen a partir de clases. Se puede saber mucho de un objeto sabiendo a qué clase pertenece.Las clases permiten su definición a partir de otras clases. Esto permite definir una jerarquía de especialización. UnaClase 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 puedenañadir nuevos.
3.9. La Orientación a Objetos3.9. La Orientación a Objetos
Interfaces: Mecanismo que emplean dos objetos para interactuar. Definen un conjunto de métodos para establecerel protocolo en base al que interactúan dos objetos.
Interfaces Protocolos
Las interfaces capturan similitudes entre clases no relacionadas. Son clases a su vez.
3.11. La Orientación a Objetos3.11. La Orientación a Objetos
UML es un lenguaje para modelar. Su vocabulario y sintaxis están ideados para la representación conceptual y física de unsistema.
Sus modelos son precisos, no ambiguos y se pueden trasladara una gran variedad de lenguajes de programación, como Java, C++, visual basic, pero también a tablas de bases de datos relacionales y orientadas a objetos.
UML tiene tres bloques básicos de construcción, elementos,relaciones y diagramas.
Elementos: Unidades básicas de construcción, cuatro tipos:• 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.
Describe un conjunto de objetos que comparten los mismos atributos, métodos, relaciones y semántica. Las clases implementan una o más interfaces.
Se trata de una clase, en la que existe procesos o hilos de ejecución concurrentes con otros elementos. Las líneas del contorno son más gruesas que en la clase “normal”.
Agrupación de métodos u operaciones que especifican un servicio de una clase o componente, describiendo su comportamiento, completo o parcial, externamente visible. UML permite emplear un círculo para representar las interfaces, aunque lo más normal es emplear la clase con el nombre en cursiva.
Define una interacción entre elementos que cooperan para proporcionar un comportamiento mayor que la suma de los comportamientos de sus elementos.
Describe un conjunto de secuencias de acciones que un sistema ejecuta, para producir un resultado observable de interés. Se emplea para estructurar los aspectos de comportamiento de un modelo.
Parte física y por tanto reemplazable de un modelo, que agrupa un conjunto de interfaces, archivos de código fuente, clases, colaboraciones y proporciona la implementación de dichos elementos.
Elemento físico que existe en tiempo de ejecución y representa un recurso computacional con capacidad de procesar.
Relaciones: Abstracciones que actúan de unión entre los elementos.
Dependencia
Asociación
Generalización
Realización
Es una relación entre dos elementos, tal que un cambio en uno puede afectar al otro.
Es una relación estructural que resume un conjunto de enlaces que son conexiones entre objetos.
Es una relación en la que el elemento generalizado puede ser substituido por cualquiera de los elementos hijos, ya que comparten su estructura y comportamiento.
Es una relación que implica que la parte realizante cumple con una serie de especificaciones propuestas por la clase realizada (interfaces).
Diagramas: Disponen un conjunto de elementos, que representan el modelo desde distintas perspectivas. UMLtiene nueve diagramas fundamentales, clasificados en dos grupos, uno para modelar la estructura estática del sistema y otro para modelar el comportamiento dinámico.
4. El Lenguaje Unificado de Modelado:
Diagramas estáticos: Clases, Objetos, componentes y despliegue.
Diagramas dinámicos: Casos de Uso, secuencia, colaboración, estados y actividades.
Las relaciones pueden traer asociada una multiplicidad, expresada “en el lado opuesto” dela relación. Resume el número de posibles instancias de una clase asociadas a una únicainstancia de la clase en el otro extremo.
Relación de auto agregación. Un departamento puede estarcompuesto por varios sub departamentos, o ninguno, con larestricción de que el mínimo número de personas en los sub departamentos debe ser dos. En UML las restricciones se expresan mediante llaves “{condicion a cumplir siempre}”.
Los diagramas de objetos son análogos a los de clases, con la particularidad de que en lugar de encontrar clases, encontramos instancias de éstas. Son útiles para explicar partes pequeñas del modelo en las que hay relaciones complejas
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.
Muestran los posibles estados en que puede encontrarse un objeto y las transiciones que pueden causar un cambio de estado. El estado de un objeto depende de la actividad que esté llevando a cabo o de alguna condición.
Circunstancia o condición que provoca la transición
Los estados pueden anidarse, agrupando estados relacionados en un estado compuesto.Puede ser necesario cuando una actividad involucra actividades concurrentes o asíncronas.
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.
UML proporciona mayores beneficios si se selecciona un proceso dirigido por Casos de Uso, centrado en la arquitectura y sea incremental.
Dirigido por Casos de Uso: Los Casos de Uso son básicosPara establecer el comportamiento deseado del sistema, para verificarlo, para validar su arquitectura y para comunicarse Con todas las personas involucradas en el proyecto.
Centrado en la arquitectura: 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. La arquitectura también incluye el uso que se le va a dar al sistema, la funcionalidad, el rendimiento, la capacidad de adaptación, la reutilización, la capacidad de ser comprendido, las restricciones económicas, las temporales, los compromisos entre alternativas y los aspectos estéticos.
Proceso incremental: aquél que consiste en sucesivas ampliaciones y mejoras de la arquitectura, a partir de una línea básica. Cada incremento resuelve los problemas encontrados en la versión anterior minimizando progresivamente los riesgos más significativos para el éxito del proyecto.
Lo primero que se debe hacer para comenzar a desarrollar un proyecto con UML, es seleccionar una metodología de desarrollo que defina la naturaleza concreta del proceso a seguir.
El modelo a definir en base al proceso elegido, se divide en realidad en varios tipos de modelo o vistas, cada una centrada en un aspecto o punto de vista del sistema. En general, independientemente del proceso que se emplee, se puede encontrar las siguientes vistas
Vista de Casos de Uso: Engloba los Casos de Uso que describen el comportamiento del sistema como lo verían los usuarios finales, los analistas y demás componentes del equipo de desarrollo. No especifica la organización del sistema. Con UML los aspectos estáticos de esta vista se pueden concretar con los diagramas de Casos de Uso; los aspectos dinámicos con los diagramas de iteración (secuencia y colaboración), diagramas de estados y de actividades.
Vista de Diseño: Engloba las clases e interfaces que conforman el vocabulario del problema y su solución. Da soporte a los requisitos funcionales del sistema, es decir los servicios que proporciona a los usuarios finales. Con UML los aspectos estáticos de esta vista se pueden concretar con los diagramas de clases y de objetos; los aspectos dinámicos con los diagramas de iteración (secuencia y colaboración), diagramas de estados y de actividades.
Vista de Procesos: Engloba los hilos y procesos que forman los mecanismos de sincronización y concurrencia del sistema. Da soporte al funcionamiento, capacidad de crecimiento y rendimiento del sistema. Con UML los aspectos estáticos de esta vista se pueden concretar con los diagramas de clases, de clases activas y de objetos; los aspectos dinámicos con los diagramas de iteración (secuencia y colaboración), diagramas de estados y de actividades.
Vista de Despliegue: Engloba los nodos que forman la topología hardware sobre el que se ejecuta el sistema. Da soporte a la distribución, entrega e instalación de las partes que conforman el sistema físico. Con UML los aspectos estáticos de esta vista se pueden concretar con los diagramas despliegue; los aspectos dinámicos con los diagramas de iteración (secuencia y colaboración), diagramas de estados y de actividades.
Vista de Implementación: Engloba los componentes y archivos empleados para hacer posible el sistema físico. Da soporte a la gestión de configuraciones de las distintas versiones del sistema, a partir de componentes y archivos. Con UML los aspectos estáticos de esta vista se pueden concretar con los diagramas de componentes; los aspectos dinámicos con los diagramas de iteración (secuencia y colaboración), diagramas de estados y de actividades.
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. Se proporciona meramente como un ejemplo de cómo se puede encajar UML como soporte para el desarrollo de un proyecto.
1. Iniciar y 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.
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.
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.
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. Documentar y entregar el programa a los usuarios finales.
PARTE II. CONTENIDO7. Objetivos.8. Conceptos fundamentales. 9. El Proceso Unificado.10.Fases del ciclo.11.Flujos de trabajo.12.Tipos de resultados. 13.Captura y Modelado de Requisitos.14.Modelado de Análisis.15.Modelado de Diseño.16.Modelado de Implementación.17.Resumen.18.Bibliografía
– Es un marco de trabajo común compuesto por actividades de trabajo (conjuntos de tareas, hitos, productos y puntos de garantía de calidad) y actividades de protección (garantía de calidad, gestión de configuración y medición) (Pressman 2001).
• Producto:– Es el resultado previsto y consistente del proceso.
• Fase:– Es el intervalo de tiempo entre dos hitos
importantes del proceso durante el que se cumple un conjunto bien definido de objetivos, se completan partes del sistema y se toman decisiones sobre si pasar o no a la siguiente fase.
• Iteración:– Representa un ciclo de desarrollo completo,
desde la captura de requisitos en el análisis hasta la implementación y pruebas, que produce como resultado la entrega al cliente o la salida al mercado de un proyecto ejecutable.
– Son asertos de ingeniería que prescriben restricciones sobre soluciones de problemas o sobre el proceso de desarrollo de soluciones, se evalúan rigurosamente en la práctica, y se juzgan sobre la base de la utilidad, la relevancia y la significación (Bourque et al., 2002).
• Normas:– Son el desarrollo de los principios fundamentales
para ámbitos particulares de tipo técnico, económico y organizativo.
– 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.
9.2. El Proceso Unificado9.2. El Proceso Unificado
– Las actividades de desarrollo bajo el Proceso Unificado están dirigidas por los 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.
9.4. El Proceso Unificado9.4. El Proceso Unificado
– El Proceso Unificado 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.
9.5. El Proceso Unificado9.5. El Proceso Unificado
– El Proceso Unificado es impulsa un control de calidad y una gestión del riesgo objetivos y continuos.
– 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.
9.7. El Proceso Unificado9.7. El Proceso Unificado
• El Proceso Unificado 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.
9.8. El Proceso Unificado9.8. El Proceso Unificado
• 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
9.11. El Proceso Unificado9.11. El Proceso Unificado
• Fase: es el intervalo de tiempo entre dos hitos importantes del proceso durante el que se cumple un conjunto bien definido de objetivos, se completan artefactos y se toman decisiones sobre si pasar o no a la siguiente fase.
• Dentro de cada fase hay varias iteraciones– Iteración: representa un ciclo de desarrollo completo, desde
la captura de requisitos en el análisis hasta la implementación y pruebas, que produce como resultado la entrega al cliente o la salida al mercado de un proyecto ejecutable.
• 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 despliegue.
• Un modelo de objetosmodelo de objetos o modelo orientado a objetosmodelo orientado a objetos es una abstracción de un sistema informático orientado a objetos real que tiene un propósito determinado.
• Según el propósito final, el mismo sistema puede tener distintos modelos.
• Sin embargo, cualquiera de los modelos se construye con el mismo conjunto de elementos para representar las propiedades estáticas (estructura) y dinámicas (comportamiento) tanto del sistema como de las entidades que lo componen.
12.3. 12.3. Tipos de resultadosTipos de resultados
• Los modelosmodelos son el tipo de artefacto más importante en el Proceso Unificado.
• Constituyen el tercer eje del metamodelo 3-D:– Los tipos de resultados obtenidos con los distintos
esfuerzos a lo largo de las fases del ciclo.
• 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.
12.5. 12.5. Tipos de resultadosTipos de resultados
12.13. 12.13. Tipos de resultadosTipos de resultados
Nombre Descripción Aspectos Estáticos
Aspectos Dinámicos
Vista de casos de uso
Proyecta el comportamiento del sistema tal y como es percibido por los: usuarios finales, analistas y en-cargados de las pruebas. Especifica las fuerzas que configuran la arquitectura del sistema.
Diagramas de casos de uso
Diagramas de interacción
Diagramas de estados
Vista de diseño Soporta los requisitos funcionales del sistema: servi-cios proporcionados a los usuarios finales. Vocabula-rio del problema y su solución: clases, interfaces y colaboraciones.
Diagramas de clases
Diagramas de objetos
Diagramas de interacción
Diagramas de estados
Diagramas de actividades
Vista de procesos Cubre el funcionamiento, capacidad de crecimiento y rendimiento del sistema. Mecanismos de sincroniza-ción y concurrencia del sistema: hilos y procesos.
Diagramas de clases (activas)
Diagramas de objetos
Diagramas de interacción
Diagramas de estados
Diagramas de actividades
Vista de implementa-ción
Cubre la gestión de configuraciones de las distintas versiones de un sistema a partir de componentes y archivos quasi-independientes. Ensamblado y dispo-nibilidad del sistema: componentes y archivos.
Diagramas de componen-tes
Diagramas de interacción
Diagramas de estados
Diagramas de actividades
Vista de despliegue Contiene los nodos que forman la arquitectura (topo-logía) hardware sobre la que se ejecuta el sistema a través de sus componentes. Está destinada a repre-sentar la distribución, entrega e instalación de las partes que forman el sistema informático físico.
1. Conjunto de requisitos:• Agrupa toda la información que describe lo que
debe hacer el sistema.• Puede comprender un modelo de casos de uso,
un modelo de requisitos no funcionales, un modelo del dominio, un modelo de análisis y otras formas de expresión de las necesidades del usuario, incluyendo pero no limitándose a maquetas, prototipos de la interfaz, restricciones legales, etc.
12.16. 12.16. Tipos de resultadosTipos de resultados
2. Conjunto de diseño:• Agrupa información que describe cómo se va a
construir el sistema y captura las decisiones acerca de cómo se va realizar, teniendo en cuenta las restricciones de tiempo, presupuesto, aplicaciones existentes, reutilización, objetivos de calidad y demás consideraciones.
• Puede implicar un modelo de diseño, un modelo de pruebas y otras formas de expresión de la naturaleza del sistema, incluyendo, pero no limitándose, a prototipos y arquitecturas ejecutables.
12.17. 12.17. Tipos de resultadosTipos de resultados
3. Conjunto de implementación:• Agrupa toda la información acerca de los
elementos software que comprende el sistema, incluyendo, pero no limitándose, a código fuente en varios lenguajes de programación, archivos de configuración, archivos de datos, componentes software, etc., junto con la información que describe cómo ensamblar el sistema.
12.18. 12.18. Tipos de resultadosTipos de resultados
• El Análisis de Requisitos tiene por misión convertir el problema, expresado en términos del dominio del negocio, a soluciones descritas en en lenguaje del dominio de la Tecnología de Información.
• El problema y su planteamiento pertenecen al Espacio del Espacio del ProblemaProblema:
– Descripción concreta del negocio.– Dominio de los Objetos de Negocio (DON).
• Las soluciones pertenecen al Espacio de la SoluciónEspacio de la Solución:– Descripción concreta del sistema de información.– Dominio de los Objetos de Negocio.– Dominio de los Objetos de Infraestructura (DOI):
• Subdominio de Objetos de Bases de Datos (SDOBD).• Subdominio de Objetos de Interfaz (SDOIZ).
13.1. 13.1. Captura y Modelado de Requisitos Captura y Modelado de Requisitos
• El Análisis de Requisitos en el RUP se realiza por medio de los flujos de trabajo:
– Modelado del negocio.– Requisitos.
• El resultado del Análisis de Requisitos es el siguiente:– Modelo del Negocio.– Modelo del Dominio.– Modelo de Casos de Uso.– Documento de Especificaciones Técnicas del Sistema
(según norma IEEE-830/1999).
13.3. 13.3. Captura y Modelado de Requisitos Captura y Modelado de Requisitos
13.6. 13.6. Captura y Modelado de Requisitos Captura y Modelado de Requisitos
SubModelo de Casosde Uso de Negocio
SubModelo de Casosde Uso (Técnico)
Diagrama Principaldel Modelo de Casosde Uso
Use-Case Model
The Use-Case Model is traceable to (and derives from) the Business Model. The system (as described in the Use Case Model) provides behavior that supports the bus iness.
• Una vez completado el modelo de casos de uso (CU) se ha llegado a obtener diagramas de casos de uso en determinados niveles que ya no se pueden explotar más.
• Si se intentara explotar los CU, se pasaría a describir el comportamiento interno de las funciones con artefactos inadecuados.
• Los casos de uso contenidos en estos diagramas se denominan casos de uso elementales.
• Esta situación límite indica que se debe pasar a trabajar con otros artefactos, que son los del modelo de análisis:
– Clases de análisis.– Asociaciones.– Diagramas de clases.– Diagramas de colaboración asociados a los diagramas de
clases.
14.1. 14.1. Modelado de AnálisisModelado de Análisis
• En el flujo de requisitos se construye un modelo que representa el comportamiento observable o externo del sistema que se quiere obtener.
• En los flujos de análisisanálisis, diseñodiseño e implementaciónimplementación, se representa la estructura y el comportamiento internos del sistema a realizar.
• Característica común de los tres flujos frente al flujo de requisitos:
– En los tres flujos se trabaja a diferentes niveles de abstracción, desde el más elevado en el análisis, hasta el más bajo en la implementación.
• El modelado de implementación se realiza para obtener:– La implementación del sistema en términos de lenguajes y
elementos de programación.– La distribución de los módulo software en los elementos
hardware del sistema.
• En el flujo de implementaciónimplementación se construye un modelo que representa la estructura y el comportamiento internos del sistema en cuanto a:
– Componentes y módulos.– Arquitectura software del sistema.
• En el flujo de desplieguedespliegue se construye un modelo que representa la estructura y el comportamiento internos del sistema en cuanto a:
– Arquitectura hardware del sistema.
16.1. 16.1. Modelado de ImplementaciónModelado de Implementación
• El Proceso Unificado es una metodología creada principalmente para el desarrollo de software orientado a objetos.
• Utiliza el soporte de modelado de UML, pero es independiente de UML.
• El Proceso Unificado:– Es un Proceso iterativo.– Está centrado en la arquitectura.– Está dirigido por los casos de uso.– Es un proceso configurable.– Soporta las técnicas orientadas a objetos.– Impulsa un control de calidad y una gestión del riesgo
• El Proceso Unificado es flexible y se puede adaptar al grado de complejidad del modelo de proceso de desarrollo (descarte de algunos modelos o flujos).
• El Proceso Unificado es abierto y permite la incorporación de enfoques y artefactos complementarios:
– Patrones de diseño.– Patrones de implementación.– Marcos de diseño.– Combinación de varios modelos de proceso.– Arquitecturas Dirigidas por Modelos (Model Driven
Architectures).– Ejecutabilidad de modelos: UML 2, validación y