2004inforsaludtutorialuml Up 101025085108 Phpapp01

VII CONGRESO NACIONAL DE INFORMTICA DE LA SALUD Madrid, 24-26 de marzo de 2004
UML y Proceso Unificado en Informtica Biomdica

scar Coltell, y Miguel Arregui
Grupo de Integracin y Re-Ingeniera de Sistemas (IRIS)
Departamento de Lenguajes y Sistemas Informticos
Tutorial.
Universitat Jaume I
Tutorial UML y PU: 1/138
CONTENIDO GENERAL
Parte I: Introduccin a UML. Parte II: Introduccin al Proceso Unificado.
Introduccin a UML
Miguel Arregui
Parte I:
PARTE I. CONTENIDO
1. 2. 3. 4. Objetivos. Introduccin. La Orientacin a Objetos, OO. El Lenguaje Unificado de Modelado. (Elementos, Relaciones, Diagramas). 5. Cmo utilizar UML. 6. Bibliografa.
1. Objetivos:
1. Introducir los conceptos que maneja UML
2. Ser una til toma de contacto con UML para Conocer sus posibilidades Decidir si incluirlo en el arsenal de desarrollo
3. Ser breve, conciso y no entrar en excesivos detalles 4. Describir cmo emplear UML en un proyecto
1.1. Objetivos
2. Introduccin:
Problema: Actualmente, Software Grande y Complejo. Demanda de interfaces ms completas, funcionalidades ms elaboradas Impacto en complejidad del producto. Requisitos: Los programas deben poder ser mantenidos y ampliados con garantas de xito.
Solucin: Estructuracin, modelado.
2.1. Introduccin
2. Introduccin:
Ante problemas complejos Divide y vence Estructura
Modela
Modelar es disear y estructurar, antes de programar. Sirve para visualizar un diseo y especificar su estructura y comportamiento. Se abstraen los detalles del problema complejo simplificando su desarrollo.
2.2. Introduccin
2. Introduccin:
UML es un lenguaje grfico para: Modelar, disear, estructurar, visualizar, especificar y documentar Software.
Proporciona vocabulario comn a la cadena de produccin. Es un estndar para crear planos completos y no ambiguos. Creado por el OMG y usado por NASA, ESA, EBI, W3C...
2.3. Introduccin
3. La Orientacin a Objetos, OO:

UML est muy cerca de este paradigma.
Objeto: Intuitivamente todo lo que tiene masa, aunque tambin hay objetos no tangibles. En informtica, definen representaciones abstractas de entidades del mundo, tangibles o no, con la intencin de emularlas.
Objetos mudo real Objetos informticos
3.1. La Orientacin a Objetos

Los objetos se caracterizan por su estado y comportamiento.
Estado: Situacin en que se encuentra un objeto, tal que cumple alguna condicin/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.

Los objetos exhiben su comportamiento a travs de mtodos.
Mtodo: Trozos de funcionalidad asociados al objeto.
Objeto Conjunto de Atributos y Mtodos

Los objetos revelan su utilidad en un contexto de comunicacin con otros objetos, por medio del paso de mensajes, para componer un sistema con un comportamiento ms complejo que el suyo propio.

El envo de mensajes es la forma en que se invoca los comportamientos de un objeto (cada mtodo define un comportamiento).
La invocacin de mtodos permite a un objeto cambiar su estado o el de otro objeto.
Los detalles internos del objeto quedan ocultos para los Dems objetos Encapsulacin.

Clase: Son patrones que definen qu atributos y qu mtodos son comunes a un conjunto de objetos, que pertenecen a dicha clase. Es ms fcil de entenderlo si se toma tipo como equivalente. Todos los objetos del mismo tipo comparten el mismo juego de atributos y mtodos y, por tanto, pertenecen a la misma clase.

Cada objeto tiene sus atributos y sus mtodos, empleando una clase como patrn. Una vez creado el objeto pasa a ser una instancia 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 como variables de instancia.

Hay atributos que no varan de una instancia a otra. Todas las instancias de la clase tienen el mismo valor. Estos atributos que no varan de instancia a instancia se conocen como variables de clase.
De manera anloga hay mtodos de instancia y mtodos de clase.

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 definicin a partir de otras clases. Esto permite definir una jerarqua de especializacin. Una Clase definida a partir de otra, hereda todos los atributos y mtodos de su clase ancestro. Las clases herederas pueden sobrescribir los atributos y los mtodos heredados y pueden aadir nuevos.

La clase tomada como patrn se conoce como Superclase o clase padre, mientras que la heredera se llama clase hija.
La jerarqua de herencia puede ser todo lo profunda que sea necesario. Una clase puede tener varias clases como patrn.

Interfaces: Mecanismo que emplean dos objetos para interactuar. Definen un conjunto de mtodos para establecer el protocolo en base al que interactan dos objetos.
Interfaces Protocolos
Las interfaces capturan similitudes entre clases no relacionadas. Son clases a su vez.
4. El Lenguaje Unificado de Modelado
4.1. El UML
4. El Lenguaje Unificado de Modelado:

UML es un lenguaje para modelar. Su vocabulario y sintaxis estn ideados para la representacin conceptual y fsica de un sistema.
Sus modelos son precisos, no ambiguos y se pueden trasladar a una gran variedad de lenguajes de programacin, como Java, C++, visual basic, pero tambin a tablas de bases de datos relacionales y orientadas a objetos.
4.2. El UML

Ingeniera directa: Es posible generar cdigo a partir de un modelo UML. Ingeniera inversa: Es posible generar un modelo UML a partir de la implementacin.
En ambos casos se requiere mayor o menor supervisin, en funcin de lo buenas que sean las herramientas usadas.
4.3. El UML

UML tiene tres bloques bsicos de construccin, elementos, relaciones y diagramas.
Elementos: Unidades bsicas de construccin, cuatro tipos: Estructurales: Partes estticas de los modelos, representan aspectos conceptuales o materiales. De comportamiento: Partes dinmicas de los modelos, representan comportamientos en el tiempo y espacio. De agrupacin: Partes organizativas de los modelos. De Notacin: Partes explicativas de los modelos.
4.4. El UML

Elementos estructurales:
Describe un conjunto de objetos que comparten los mismos atributos, mtodos, relaciones y semntica. Las clases implementan una o ms interfaces.
Clase
Se trata de una clase, en la que existe procesos o hilos de ejecucin concurrentes con otros elementos. Las lneas del contorno son ms gruesas que en la clase normal.
Clase activa
4.5. El UML

Agrupacin de mtodos u operaciones que especifican un servicio de una clase o componente, describiendo su comportamiento, completo o parcial, externamente visible. UML permite emplear un crculo para representar las interfaces, aunque lo ms normal es emplear la clase con el nombre en cursiva.
Define una interaccin entre elementos que cooperan para proporcionar un comportamiento mayor que la suma de los comportamientos de sus elementos.
4.6. El UML

Describe un conjunto de secuencias de acciones que un sistema ejecuta, para producir un resultado observable de inters. Se emplea para estructurar los aspectos de comportamiento de un modelo. Parte fsica y por tanto reemplazable de un modelo, que agrupa un conjunto de interfaces, archivos de cdigo fuente, clases, colaboraciones y proporciona la implementacin de dichos elementos. Elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional con capacidad de procesar.
4.7. El UML

Elementos de comportamiento:
Comprende un conjunto de mensajes que se intercambian entre un conjunto de objetos, para cumplir un objetivo especifico.
Especifica la secuencia de estados por los que pasa un objeto o una interaccin, en respuesta a eventos.
4.8. El UML

Elementos de agrupacin:
Se emplea para organizar otros elementos en grupos.
Elementos de notacin:
Partes explicativa de UML, que puede describir textualmente cualquier aspecto del modelo.
4.9. El UML

Relaciones: Abstracciones que actan de unin entre los elementos.
Dependencia
Es una relacin entre dos elementos, tal que un cambio en uno puede afectar al otro. Es una relacin estructural que resume un conjunto de enlaces que son conexiones entre objetos. Es una relacin en la que el elemento generalizado puede ser substituido por cualquiera de los elementos hijos, ya que comparten su estructura y comportamiento. Es una relacin que implica que la parte realizante cumple con una serie de especificaciones propuestas por la clase realizada (interfaces).
Asociacin
Generalizacin
Realizacin
4.10. El UML

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 esttica del sistema y otro para modelar el comportamiento dinmico. Diagramas estticos: Clases, Objetos, componentes y despliegue. Diagramas dinmicos: Casos de Uso, secuencia, colaboracin, estados y actividades.
4.11. El UML

Diagrama de Clases:
Muestran un resumen del sistema en trminos de sus clases y las relaciones entre ellas. Las clases abstractas tienen su nombre en itlica.Son interfaces. Las flechas navegables son asociaciones navegables que expresan el sentido en que se consultan los datos. El Resto son asociaciones bidireccionales.
4.12. El UML

Diagrama de Clases:
Las relaciones pueden traer asociada una multiplicidad, expresada en el lado opuesto de la relacin. Resume el nmero de posibles instancias de una clase asociadas a una nica instancia de la clase en el otro extremo.
Multiplicidad 1 N/* 0..N / 0..* 1..N / 1..* 0..1 N..M
Significado Una nica instancia N instancias Entre ninguna y N instancias Entre una y N instancias Ninguna o una instancia Entre N y M instancias
4.13. El UML

Diagrama de Clases:
En las relaciones de dependencia un cambio en la clase dependida afectar la clase dependiente. Compartimentos de la clase: primero nombre segundo atributos tercero mtodos Acceso de atributos y mtodos: + pblico - privado (slo los mtodos), # protegido (slo clases hija).
Argumentos: nombre:tipo [=val] (, nombre:tipo[=val])* Los atributos y mtodos estticos (de clase) se representan mediante un subrayado. Los mtodos pueden emplear el estereotipo <<static>>.
4.14. El UML Tutorial UML y PU: 33/138

Diagrama de Clases:
Relacin de auto agregacin. Un departamento puede estar compuesto por varios sub departamentos, o ninguno, con la restriccin de que el mnimo nmero de personas en los sub departamentos debe ser dos. En UML las restricciones se expresan mediante llaves {condicion a cumplir siempre}.
Diagrama de Objetos:
Los diagramas de objetos son anlogos a los de clases, con la particularidad de que en lugar de encontrar clases, encontramos instancias de stas. Son tiles para explicar partes pequeas del modelo en las que hay relaciones complejas
4.15. El UML

Diagrama de Componentes:
Un componente es un mdulo de cdigo, de modo que los diagramas de componentes son los anlogos fsicos a los diagramas de clases. Muestran la organizacin y dependencias de un conjunto de componentes. Cubren la vista de implementacin esttica de un sistema.
4.16. El UML

Diagrama de Despliegue:
Los diagramas de despliegue sirven para modelar la configuracin hardware del sistema, mostrando qu nodos lo componen
4.17. El UML

Diagrama de Casos de Uso:
Describen lo que hace el sistema desde el punto de vista de un observador externo.
Enfatizan el qu en lugar del cmo.

Plantean escenarios, lo que pasa cuando alguien interacta con el sistema. Proporcionan un resumen para una objetivo. Los Actores son papeles que determinadas personas u objetos desempean. Las lneas que unen los Actores con los Casos de Uso (valos) representan una asociacin de comunicacin.
4.18. El UML

Los Casos de Uso pueden explosionarse para describir en mayor profundidad.
Carlos tuesta el pan en la tostadora, despus lo unta con mantequilla y mermelada de fresa y se lo come, posiblemente mojndolo en un caf.
Carlos calienta leche, aade caf y azcar al gusto y se lo bebe.
Los Casos de Uso pueden acompaarse de texto que enriquezca el lenguaje grfico.
4.19. El UML

frontera
estereotipo
generalizacin
Paralelo, orden irrelevante 4.20. El UML Tutorial UML y PU: 39/138

Diagrama de Secuencia:
Describen cmo los objetos del sistema colaboran. Detalla cmo las operaciones se llevan a cabo en trminos de qu mensajes son enviados y cuando (en torno al tiempo).
Los corchetes expresan condicin [condicin]. Si son precedidos por * iteracin mientras.
4.21. El UML

Diagrama de Secuencia:
Los rectngulos verticales son barras de activacin. Representan la duracin de la ejecucin del mensaje. Mensaje asncronos: El emisor puede enviar otros mientras ste est siendo procesado. Es independiente a otros mensajes. Mensaje sncronos: El emisor debe esperar que termine el tiempo de proceso de ste para enviar nuevos mensajes.
Mensaje simple puede ser sncrono o asncrono
Mensaje simple de vuelta (opt)
Sncrono Asncrono
4.22. El UML

Diagrama de Colaboracin:
Son otro tipo de diagramas de interaccin. Contienen la misma informacin 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 nmero de secuencia. El primer nivel comienza en 1, los mensajes que son enviados durante la misma llamada a un mtodo se numeran 1.1, 1.2 ... 1.i, tantos niveles como sea necesario.
4.23. El UML

Diagrama de Estados:
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 condicin.
Circunstancia o condicin que provoca la transicin accin inicio Resultado de actividad
fin 4.24. El UML Tutorial UML y PU: 43/138

Diagrama de Estados:
Los estados pueden anidarse, agrupando estados relacionados en un estado compuesto. Puede ser necesario cuando una actividad involucra actividades concurrentes o asncronas.
4.25. El UML

Diagrama de Actividades:
Son diagramas de flujo adornados, con mucha similitud a los diagramas de estados. Mientras los diagramas de estados centran su atencin en el proceso que lleva a cabo un objeto, los diagramas de actividades muestran como las actividades fluyen y las dependencias entre ellas.
4.26. El UML
5. Cmo utilizar UML:

UML es simplemente un lenguaje. Define un conjunto de elementos y las relaciones entre ellos y esto se emplea para definir modelos.
UML se usa tpicamente como parte de un proceso de desarrollo, con ayuda de una herramienta CASE.
UML es independiente de cualquier proceso particular, no Est ligado a ningn ciclo de vida de desarrollo de software concreto.
5.1. Cmo Utilizar UML

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 bsicos Para 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 organizacin, la seleccin de elementos estructurales, la definicin de las interfaces entre estos elementos, su comportamiento, su divisin en subsistemas, qu elementos son estticos y cuales dinmicos. La arquitectura tambin incluye el uso que se le va a dar al sistema, la funcionalidad, el rendimiento, la capacidad de adaptacin, la reutilizacin, la capacidad de ser comprendido, las restricciones econmicas, las temporales, los compromisos entre alternativas y los aspectos estticos.

Proceso incremental: aqul que consiste en sucesivas ampliaciones y mejoras de la arquitectura, a partir de una lnea bsica. Cada incremento resuelve los problemas encontrados en la versin anterior minimizando progresivamente los riesgos ms significativos para el xito del proyecto.

Lo primero que se debe hacer para comenzar a desarrollar un proyecto con UML, es seleccionar una metodologa 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 veran los usuarios finales, los analistas y dems componentes del equipo de desarrollo. No especifica la organizacin del sistema. Con UML los aspectos estticos de esta vista se pueden concretar con los diagramas de Casos de Uso; los aspectos dinmicos con los diagramas de iteracin (secuencia y colaboracin), diagramas de estados y de actividades.
Vista de Diseo: Engloba las clases e interfaces que conforman el vocabulario del problema y su solucin. Da soporte a los requisitos funcionales del sistema, es decir los servicios que proporciona a los usuarios finales. Con UML los aspectos estticos de esta vista se pueden concretar con los diagramas de clases y de objetos; los aspectos dinmicos con los diagramas de iteracin (secuencia y colaboracin), diagramas de estados y de actividades.

Vista de Procesos: Engloba los hilos y procesos que forman los mecanismos de sincronizacin y concurrencia del sistema. Da soporte al funcionamiento, capacidad de crecimiento y rendimiento del sistema. Con UML los aspectos estticos de esta vista se pueden concretar con los diagramas de clases, de clases activas y de objetos; los aspectos dinmicos con los diagramas de iteracin (secuencia y colaboracin), diagramas de estados y de actividades.
Vista de Despliegue: Engloba los nodos que forman la topologa hardware sobre el que se ejecuta el sistema. Da soporte a la distribucin, entrega e instalacin de las partes que conforman el sistema fsico. Con UML los aspectos estticos de esta vista se pueden concretar con los diagramas despliegue; los aspectos dinmicos con los diagramas de iteracin (secuencia y colaboracin), diagramas de estados y de actividades.

Vista de Implementacin: Engloba los componentes y archivos empleados para hacer posible el sistema fsico. Da soporte a la gestin de configuraciones de las distintas versiones del sistema, a partir de componentes y archivos. Con UML los aspectos estticos de esta vista se pueden concretar con los diagramas de componentes; los aspectos dinmicos con los diagramas de iteracin (secuencia y colaboracin), diagramas de estados y de actividades.

Ejemplo para la construccin de un programa:
Un ejemplo de proceso para la construccin de un programa, podra ser similar al siguiente, teniendo en cuenta que el proceso descrito deja muchas cosas por ampliar. Se proporciona meramente como un ejemplo de cmo 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 usarn y todos los detalles necesarios para comprender el mbito del problema a resolver. Esta informacin 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 informacin 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 comn en lo que el programa har y no har. En este punto puede ser conveniente disear 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 lnea base. Se definen clases y relaciones entre ellas, los primeros diagramas de secuencia y colaboracin, definiendo los comportamientos de cada clase, tambin las interfaces entre los diferentes elementos de la arquitectura. Se construye aqu la vista de diseo y la vista de procesos. Construir diagramas de clases ms elaborados y refinar los comportamientos del sistema. 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 fsica del sistema, y la vista de implementacin.
4.

5. 6. Construir el sistema, repartiendo las tareas entre el equipo de programacin. Buscar errores de programacin, o incluso de diseo, corregirlos e ir sacando sucesivas versiones del programa hasta llegar a una versin que cumpla con todos los requisitos especificados en el contrato con los usuarios.
7.
Documentar y entregar el programa a los usuarios finales.
6. Bibliografa:
Grady Booch, James Rumbaugh, Ivar Jacobson, (1996) El Lenguaje Unificado de ModeladoAddison Wesley. Schneider G., Winters J.P., (2001) Applying Use Cases: A Practical Guide, Addison Wesley.
OMG en Internet: http://www.omg.org
6.1. Bibliografa PARTE I
Introduccin al Proceso Unificado

scar Coltell
Parte II:
PARTE II. CONTENIDO

7. 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 Anlisis. 15. Modelado de Diseo. 16. Modelado de Implementacin. 17. Resumen. 18. Bibliografa
7. OBJETIVOS
Introducir los aspectos generales del Proceso Unificado de Rational (RUP), tambin denominado Proceso Unificado de Desarrollo de Software (SDUP). Asociar las fases de un proyecto de software con las fases del RUP y el ciclo de vida del desarrollo del software. Presentar los artefactos fundamentales del Proceso Unificado.
7.1. OBJETIVOS Tutorial UML y PU: 61/138
8. Conceptos fundamentales
Proceso:
Es un marco de trabajo comn compuesto por actividades de trabajo (conjuntos de tareas, hitos, productos y puntos de garanta de calidad) y actividades de proteccin (garanta de calidad, gestin de configuracin y medicin) (Pressman 2001).
Producto:
Es el resultado previsto y consistente del proceso.
8.1. Conceptos fundamentales
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.
Iteracin:
Representa un ciclo de desarrollo completo, desde la captura de requisitos en el anlisis hasta la implementacin y pruebas, que produce como resultado la entrega al cliente o la salida al mercado de un proyecto ejecutable.
Ciclo de vida del software:
Es el conjunto de fases por las que pasa el software, que abarcan desde su creacin u origen, hasta su eliminacin o liquidacin formal.
Modelo de desarrollo:
Tambin denominado Modelo de Proceso. Estrategia de desarrollo basada en el ciclo de vida, naturaleza del proyecto y metodologa, que determina las caractersticas especficas del proceso (Pressman 2001).
Ciclo de vida del software completo
Preparacin del proble ma Modelado del negocio Anlisis de requisitos Anlisis Diseo Construccin Pruebas Entrega Explotacin / Manten imiento Liquidacin
Conocimiento Implementacin
Concepcin
Desarrollo
Explotacin
Tiempo
% Implementacin
% Conocimiento
Principios fundamentales:
Son asertos de ingeniera que prescriben restricciones sobre soluciones de problemas o sobre el proceso de desarrollo de soluciones, se evalan rigurosamente en la prctica, y se juzgan sobre la base de la utilidad, la relevancia y la significacin (Bourque et al., 2002).
Normas:
Son el desarrollo de los principios fundamentales para mbitos particulares de tipo tcnico, econmico y organizativo.
8.5. Conceptos fundamentales Tutorial UML y PU: 66/138
Estructura formal de la Ingeniera del Software
PRINCIPIOS PRINCIPIOSDE DE LA INGENIERA LA INGENIERADEL DELSOFTWARE SOFTWARE
NORMAS TCNICAS
NORMAS NORMASDE DE LA INGENIERA LA INGENIERADEL DELSOFTWARE SOFTWARE
OTRAS NORMAS
ESTNDARES
MODELOS MODELOSDE DE PROCESO PROCESO
PROCESO
METODOLOGAS METODOLOGAS / /PARADIGMAS PARADIGMAS
RUP
TCNICAS TCNICAS
HERRAMIENTAS HERRAMIENTAS
PRODUCTO
9. El Proceso Unificado
El Proceso Unificado: A. Es un Proceso iterativo. B. Est centrado en la arquitectura. C. Est dirigido por los casos de uso. D. Es un proceso configurable. E. Soporta las tcnicas orientadas a objetos. F. Impulsa un control de calidad y una gestin del riesgo objetivos y continuos.
9.1. El Proceso Unificado
A. El RUP es un proceso iterativo:
Un enfoque iterativo propone una comprensin incremental del problema a travs de refinamientos sucesivos y un crecimiento incremental de una solucin efectiva a travs de varias versiones. Como parte del enfoque iterativo se encuentra la flexibilidad para acomodarse a nuevos requisitos o a cambios tcticos en los objetivos del negocio. Permite que el proyecto identifique y resuelva los riesgos ms bien pronto que tarde.
9.2. El Proceso Unificado Tutorial UML y PU: 69/138
B. Aspectos del RUP:
El desarrollo bajo el Proceso Unificado est centrado en la arquitectura. El proceso se centra en establecer al principio una arquitectura software que gua el desarrollo del sistema:
Se facilita el desarrollo en paralelo. Se minimiza la repeticin de trabajos. Se incrementa la probabilidad de reutilizacin de componentes y el mantenimiento posterior del sistema.
Este diseo arquitectnico sirve como una slida base sobre la cual se puede planificar y manejar el desarrollo de software basado en componentes.
C. Aspectos del RUP:
Las actividades de desarrollo bajo el Proceso Unificado estn dirigidas por los casos de uso. El Proceso Unificado pone un gran nfasis en la construccin de sistemas basada en una amplia comprensin de cmo 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.
D. Aspectos del RUP:
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 pequeos equipos de desarrollo de software hasta grandes empresas de desarrollo. Tambin se basa en una arquitectura de proceso simple y clara, que proporciona un marco comn a toda una familia de procesos y que, adems, puede variarse para acomodarse a distintas situaciones.
E. Aspectos del RUP:
El Proceso Unificado soporta las tcnicas orientadas a objetos. Los modelos del Proceso Unificado se basan en los conceptos de objeto y clase y las relaciones entre ellos, y utilizan UML como la notacin comn.
F. Aspectos del RUP:
El Proceso Unificado es impulsa un control de calidad y una gestin del riesgo objetivos y continuos. La evaluacin 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 gestin 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 todava hay tiempo de reaccionar.
El Proceso Unificado tiene una estructura matricial donde se relacionan esfuerzos y tiempos:
Los tiempos estn definidos por las fases y las iteraciones. Los esfuerzos estn definidos por los flujos de trabajo del proceso y de soporte. La representacin grfica se denomina en la jerga el Diagrama de Montaas.
El ciclo de vida del desarrollo del software

Flujos de trabajo del proceso
Modelado del negocio Requisitos Anlisis y diseo Implementacin Pruebas Despliegue
Iniciacin
Elaboracin
Construccin
Transicin
Flujos de trabajo de soporte

Gestin del cambio y configuraciones Gestin del proyecto Entorno
Iteraciones preliminares
Iter #1
Iter #2
Iter #n
Iter #n+1
Iter #n+2
Iter #m
Iter #m+1
Fuente: Jacobson et al., 2000
En esta estructura matricial se puede deducir que:
Los resultados de los flujos de trabajo de proceso son los MODELOS. La conjuncin de tiempo (fases) y esfuerzos (flujos de trabajo) da lugar a las iteraciones. La conjuncin de resultados (modelos) y esfuerzos (flujos de trabajo) da lugar a los tipos de modelos. La conjuncin de tiempo (fases) y resultados (modelos) da lugar a las versiones.
9.10. El Proceso Unificado Tutorial UML y PU: 77/138
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
resultados
Z: Modelos (x,z): versiones
(y,z): tipos de modelos
X,Y,Z: Configuraciones del sistema
tiempo
X: Fases
Y: Flujos de trabajo
esfuerzo
(x,y): iteraciones
10. Fases del ciclo

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
Iteracin: representa un ciclo de desarrollo completo, desde la captura de requisitos en el anlisis hasta la implementacin y pruebas, que produce como resultado la entrega al cliente o la salida al mercado de un proyecto ejecutable.
10.1. Fases del ciclo
10. Fases del ciclo

Iniciacin.
Se establece la planificacin del proyecto y se delimita su alcance.
Elaboracin.
Se analiza el dominio del problema, se establece una base arquitectnica slida, se desarrolla el plan del proyecto y se eliminan los elementos de ms alto riesgo del proyecto.
Construccin.
Se desarrolla de forma iterativa e incremental un producto completo que est preparado para la transicin hacia la comunidad de usuarios.
Transicin.
El software se despliega en la comunidad de usuarios.
Las iteraciones son distintas en el ciclo de vida

F1: Modelado del negocio F2: Requisitos F3: Anlisis y diseo F4: Implementacin F5: Pruebas F6: Despliegue
Iniciacin
Elaboracin
Construccin
Transicin

F7: Gestin del cambio y configuraciones F8: Gestin del proyecto F9: Entorno
Iteraciones Iter preliminares#1

F2 F2
Iter #2
Iter #n
Iter Iter #n+1 #n+2
Iter #m
Iter #m+1
F3
F1
F1
F4
F2
F3 F9 F4 F5 F8 F6 F7
F3 F9 F4 F8 F5 F6 F7 F5 F6 F7
F1 F9 F8
10. Fases del ciclo

Cada iteracin pasa a travs 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 iniciacin, el inters se orienta hacia el anlisis y el diseo. Tambin durante la elaboracin. Durante la construccin, la actividad central es la implementacin. La transicin se centra en despliegue.
11. 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 tcnicas.
Flujos de trabajo de soporte:

Conjunto de actividades fundamentalmente de gestin.
11.1. Flujos de trabajo

Flujos de trabajo del proceso:
1. 2. 3. 4. 5. 6. Modelado del negocio: describe la estructura y la dinmica de la organizacin. Requisitos: describe el mtodo basado en casos de uso para extraer los requisitos. Anlisis y diseo: describe las diferentes vistas arquitectnicas. Implementacin: tiene en cuenta el desarrollo de software, la prueba de unidades y la integracin. Pruebas: describe los casos de pruebas, los procedimientos y las mtricas para evaluacin de defectos. Despliegue: cubre la configuracin del sistema entregable.

Flujos de trabajo de soporte:
1.
2. 3.
Gestin de configuraciones: controla los cambios y mantiene la integridad de los artefactos de un proyecto. Gestin del Proyecto: describe varias estrategias de trabajo en un proceso iterativo. Entorno: cubre la infraestructura necesaria para desarrollar un sistema.
El ciclo de vida del desarrollo del software: Flujos

Iniciacin
Elaboracin
Construccin
Transicin

Iter #1
Iter #2
Iter #n
Iter #n+1
Iter #n+2
Iter #m
Iter #m+1
12. Tipos de resultados

Un modelo es una abstraccin de la realidad o de un sistema real tomando los elementos ms representativos con un propsito determinado. De un mismo sistema puede haber ms de un modelo, porque, segn el propsito del mismo, los elementos representativos pueden ser distintos. Los elementos a considerar en la construccin de modelos son: supuestos, simplificaciones, limitaciones o restricciones y preferencias
12.1. Tipos de resultados

Los supuestos:
Son elementos para la construccin de modelos que reducen el nmero de permutaciones y variaciones posibles, permitiendo al modelo reflejar el problema de manera razonable.
Las simplificaciones:
Son elementos para la construccin de modelos que permiten crear el modelo a tiempo.
Las limitaciones o restricciones:

Son elementos para la construccin de modelos que ayudan a delimitar el problema.
Las preferencias:
Son elementos para la construccin de modelos que indican la arquitectura preferida para toda la informacin, funciones y tecnologa. Pueden tener conflictos con otros factores restrictivos. Es recomendable tenerlas en cuenta para obtener un resultado aceptado, adems de correcto.
12.2. Tipos de resultados Tutorial UML y PU: 89/138

Un modelo de objetos o modelo orientado a objetos es una abstraccin de un sistema informtico orientado a objetos real que tiene un propsito determinado. Segn el propsito 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 estticas (estructura) y dinmicas (comportamiento) tanto del sistema como de las entidades que lo componen.

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 algn formato especfico, en forma de entregas definidas en el contrato.
Estos artefactos son adicionales a los que proporciona el propio UML:

Los modelos y los conjuntos.

Los modelos son el tipo de artefacto ms 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 visualizacin, especificacin, construccin y documentacin de un sistema con gran cantidad de software.

Modelos del Proceso Unificado:
1. 2. 3. 4. 5. 6. 7. 8. 9. Modelo del negocio: establece una abstraccin de la organizacin. Modelo del dominio: establece el contexto del sistema. Modelo de casos de uso: establece los requisitos funcionales del sistema. Modelo de anlisis (opcional): establece un diseo de las ideas. Modelo de diseo: establece el vocabulario del problema y su solucin. Modelo del proceso (opcional): establece los mecanismos de concurrencia y sincronizacin del sistema. Modelo de despliegue: establece la topologa hardware sobre la cual se ejecutar el sistema. Modelo de implementacin: establece las partes que se utilizarn para ensamblar y hacer disponible el sistema fsico. Modelo de pruebas: establece las formas de validar y verificar el sistema.
12.6. Tipos de resultados Tutorial UML y PU: 93/138
Relaciones lgicas entre los modelos :
Modelo de Casos de Uso
verificado por
especificado por
realizado por distribuido por
Modelo de Anlisis Modelo de Diseo
Modelo de Prueba
implementado por
Modelo de Despliegue
Modelo de Implementacin
Modelos y flujos de trabajo del Proceso Unificado

Modelado del Negocio Modelo del Negocio Modelo del Dominio Modelo de Casos de Uso Modelo de Anlisis Modelo de Diseo Modelo de Procesos Modelo de Despliegue Modelo de Implementacin Modelo de Prueba Requisitos Anlisis Diseo Implementacin Prueba Despliegue
X X X X X
X X X X X X X X
MODELOS Y DIAGRAMAS EN EL RUP

Modelo del Negocio Modelo del Dom inio Modelo de Casos de Uso Est. Din. Modelo de Anlisis Modelo de Diseo Modelo de Procesos Modelo de Despliegue Modelo Im plem entacin Est. Din. Modelo de Prueba
Est. Diagram a de Casos de Uso Diagram a de InteraccinSecuencia Diagram a de InteraccinColaboracin Diagram a de Clases de Anlisis Diagram a de Objetos de Anlisis Diagram a de Clases de Diseo Diagram a de Objetos de Diseo Diagram a de Estados
Din.
Est.
Din.
Est.
Din.
Est.
Din.
Est.
Din.
Est.
Din.
Est.
Din.
X X X X X
X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X X
X X
Diagram a de Actividades
Diagram a de Com ponentes
Diagram a de Despliegue
El Proceso Unificado recupera el concepto de vista de UML. Para el Proceso Unificado una vista es:
Una proyeccin de un modelo. Una proyeccin de la organizacin y la estructura del sistema que se centra en un aspecto particular del sistema.
La arquitectura de un sistema se captura en forma de cinco vistas que interactan entre s:

La vista de casos de uso. La vista de diseo. La vista de procesos. La vista de despliegue. La vista de implementacin.
Vistas de la arquitectura de un sistema
vocabulario, funcionalidad
Vista de diseo
comportamiento
Vista de implementacin
ensamblado del sistema, gestin de configuraciones
Vista de casos de uso Vista de procesos Vista de despliegue

topologa del sistema, distribucin, entrega, instalacin
Funcionamiento, capacidad de crecimiento, rendimiento
Cada una de las vistas presenta: Aspectos estticos: mediante los diagramas estructurales de UML. Aspectos dinmicos: mediante diagramas dinmicos de UML. Ejemplo: se puede trabajar con la vista de casos de uso esttica y la vista de casos de uso dinmica, la vista de diseo esttica y la vista de diseo dinmica, y as sucesivamente. En el RUP se da ms importancia a los modelos que a las vistas. Aunque se siguen manteniendo para determinados propsitos de modelado.
Nombre
Vista de casos de uso
Descripcin
Aspectos Estticos
Aspectos Dinmicos
Diagramas de interaccin Diagramas de estados
Proyecta el comportamiento del sistema tal y como Diagramas de casos de es percibido por los: usuarios finales, analistas y en- uso cargados de las pruebas. Especifica las fuerzas que configuran la arquitectura del sistema.
Vista de diseo
Soporta los requisitos funcionales del sistema: servi- Diagramas de clases cios proporcionados a los usuarios finales. Vocabula- Diagramas de objetos rio del problema y su solucin: clases, interfaces y colaboraciones. Cubre el funcionamiento, capacidad de crecimiento y Diagramas de clases rendimiento del sistema. Mecanismos de sincroniza- (activas) cin y concurrencia del sistema: hilos y procesos. Diagramas de objetos
Diagramas de interaccin Diagramas de estados Diagramas de actividades Diagramas de interaccin Diagramas de estados Diagramas de actividades
Vista de procesos
Vista de implementa- Cubre la gestin de configuraciones de las distintas Diagramas de componencin versiones de un sistema a partir de componentes y tes archivos quasi-independientes. Ensamblado y disponibilidad del sistema: componentes y archivos.
Diagramas de interaccin Diagramas de estados Diagramas de actividades
Vista de despliegue
Contiene los nodos que forman la arquitectura (topo- Diagramas de despliegue loga) hardware sobre la que se ejecuta el sistema a travs de sus componentes. Est destinada a representar la distribucin, entrega e instalacin de las partes que forman el sistema informtico fsico.
Diagramas de interaccin Diagramas de estados Diagramas de actividades
VISTAS Y DIAGRAMAS EN UML

Diagrama de Casos de Uso Diagrama de InteraccinSecuencia Diagrama Diagrade ma de Interaccin- Clases Colaboracin Diagrama de Objetos Diagrama Diagrama Diagrama de de de CompoEstados Activida- nentes des Diagrama de Despliegue
Vista de Casos Esttica de Uso Dinmica Vista de Diseo Esttica Dinmica Vista de Procesos Vista de Implementacin Vista de Despliegue Esttica Dinmica Esttica Dinmica Esttica Dinmica
Los artefactos conjunto del RUP son los siguientes: 1. Conjunto de requisitos. 2. Conjunto de diseo. 3. Conjunto de implementacin. 4. Conjunto de despliegue.
1. Conjunto de requisitos:
Agrupa toda la informacin 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 anlisis y otras formas de expresin de las necesidades del usuario, incluyendo pero no limitndose a maquetas, prototipos de la interfaz, restricciones legales, etc.
2. Conjunto de diseo:
Agrupa informacin que describe cmo se va a construir el sistema y captura las decisiones acerca de cmo se va realizar, teniendo en cuenta las restricciones de tiempo, presupuesto, aplicaciones existentes, reutilizacin, objetivos de calidad y dems consideraciones. Puede implicar un modelo de diseo, un modelo de pruebas y otras formas de expresin de la naturaleza del sistema, incluyendo, pero no limitndose, a prototipos y arquitecturas ejecutables.
3. Conjunto de implementacin:
Agrupa toda la informacin acerca de los elementos software que comprende el sistema, incluyendo, pero no limitndose, a cdigo fuente en varios lenguajes de programacin, archivos de configuracin, archivos de datos, componentes software, etc., junto con la informacin que describe cmo ensamblar el sistema.
4. Conjunto de despliegue:
Agrupa toda la informacin acerca de la forma en que se empaqueta actualmente el software, se distribuye, se instala y se ejecuta en el entorno destino.
13. Captura y Modelado de Requisitos

El Anlisis de Requisitos tiene por misin convertir el problema, expresado en trminos del dominio del negocio, a soluciones descritas en en lenguaje del dominio de la Tecnologa de Informacin. El problema y su planteamiento pertenecen al Espacio del Problema:
Descripcin concreta del negocio. Dominio de los Objetos de Negocio (DON). Descripcin concreta del sistema de informacin. 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).
Las soluciones pertenecen al Espacio de la Solucin:
13.1. Captura y Modelado de Requisitos

Espacio del Problema Espacio de la Solucin de Usuario Anlisis de Requisitos
Anlisis OO Espacio de la Solucin de Implementacin
Diseo OO
Espacio de la Solucin Tcnica
Diseo

El Anlisis de Requisitos en el RUP se realiza por medio de los flujos de trabajo:
Modelado del negocio. Requisitos. Modelo del Negocio. Modelo del Dominio. Modelo de Casos de Uso. Documento de Especificaciones Tcnicas del Sistema (segn norma IEEE-830/1999).
El resultado del Anlisis de Requisitos es el siguiente:

Iniciacin
Elaboracin
Construccin
Transicin
Requisitos

Iter #1
Iter #2
Iter #n
Iter #n+1
Iter #n+2
Iter #m
Iter #m+1

El Modelo de Casos de Uso (MCU) establece los requisitos funcionales del sistema de informacin. En el MCU se recoge la descripcin externa y observable de cmo se utiliza el sistema de informacin:
Descripcin de CMO se utiliza el sistema:
Funciones, Servicios y Procesos. Se identifican y describen funciones/servicios/procesos del negocio que un usuario puede hacer con el soporte del sistema de informacin.
Descripcin EXTERNA del uso del sistema:
Descripcin OBSERVABLE del uso del sistema:

Es como si hubiera un observador externo que va anotando lo que hace el usuario con el sistema y lo que el sistema responde al usuario.

Diagrama de Contexto del SMCU de Negocio
SubModelo de Casos de Uso de Negocio
Diagrama de Contexto del SMCU Tcnico
SubModelo de Casos de Uso (Tcnico)
Diagrama Principal del Modelo de Casos de Uso
Business 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 business. Use-Case Model

Diagrama de Contexto del MCU
14. Modelado de Anlisis

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 ms. Si se intentara explotar los CU, se pasara 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 situacin lmite indica que se debe pasar a trabajar con otros artefactos, que son los del modelo de anlisis:
Clases de anlisis. Asociaciones. Diagramas de clases. Diagramas de colaboracin asociados a los diagramas de clases.
14.1. Modelado de Anlisis

verificado por
especificado por
realizado por distribuido por
Modelo de Anlisis Modelo de Diseo
Modelo de Prueba
implementado por
Transicin del MCU hacia el MA
14.2. Modelado de Anlisis Tutorial UML y PU: 115/138

El Anlisis en el RUP se realiza por medio de los flujos de trabajo:
Anlisis y diseo.
El resultado del Anlisis es el siguiente:
Modelo de Anlisis.
La Vista de Diseo de UML. La Vista de Procesos de UML.
El Modelo de Anlisis contiene:

Iniciacin
Elaboracin
Construccin
Transicin
Anlisis

Iter #1
Iter #2
Iter #n
Iter #n+1
Iter #n+2
Iter #m
Iter #m+1
Modelo de casos de uso con estructura de desglose de diagramas

NIVEL 0 Cada caso de uso se desglosa en un diagrama en el nivel inferior
Proceso de Conversin: Casos de Uso Anlisis
NIVEL1
NIVEL 2
Cada caso de uso se desglosa en un diagrama en el nivel inferior
MODELO DE CASOS DE USO

trace
MODELO DE ANLISIS
caso de uso (MCU)
Realizacin (MA)
Interfaz
Gestor/Control
Entidad
Artefactos del modelo de anlisis

trace
MODELO DE ANLISIS
caso de uso (MCU)
Realizacin (MA)
Proceso de Conversin: Casos de Uso Anlisis

Entidad
Interfaz
Gestor/Control
F01.01 Consulta saldo
Cliente
I_Cajero
C_Gestor_Interfaz
Cta_Cliente
Diagrama de Clases de Anlisis Atmico

I_Autenticacion C_Verificador_Autenticacio n
Modelo de Anlisis
Servicio(CU)-Subsistema(DA)
Top-Down
MCU Nivel 0
Subsistema 1
MA Nivel 0
Bottom-Up
MCU Nivel 1
Subsistema 3
Subsistema 2
MA Nivel 1
MCU Nivel 2
MA Nivel 2
MCU Nivel i
trace
MA Nivel j
MODELO DE ANLISIS
Cliente
I_Cajero
C_Gestor_Interfaz
Cta_Cliente
caso de uso (MCU)
Realizacin (MA)
I_Autenticacion C_Verificador_Autenticacio n
Interfaz
Gestor/Control
Entidad
La estructura del modelo en Rose:
D. Clases Anlisis Atmico para el Caso de Uso F01.01 <Nombre funcin> Diagrama de Colaboracin para DCAA F01.01
Carpeta de trabajo en la conversin
Diagrama de Clases de Anlisis de Contexto
15. Modelado de Diseo

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 anlisis, diseo e implementacin, se representa la estructura y el comportamiento internos del sistema a realizar. Caracterstica comn de los tres flujos frente al flujo de requisitos:
En los tres flujos se trabaja a diferentes niveles de abstraccin, desde el ms elevado en el anlisis, hasta el ms bajo en la implementacin.
15.1. Modelado de Diseo
Flujo de Anlisis de Requisitos
verificado por
especificado por realizado por distribuido por
Modelo de Anlisis
Flujo de Anlisis y Diseo
Modelo de Prueba
Modelo de Diseo Modelo de Despliegue

Transicin del MCA hacia el MD
implementado por

La tcnica de modelado consiste en identificar, a travs de las especificaciones de las clases de anlisis las clases de diseo correspondientes. Para cada clase de anlisis se puede derivar una o ms clases de diseo:
Clase de control clase activa (>= 1) Clase de entidad clase de entidad (>= 1) Clase de interfaz clase de interfaz (>= 1)
<<trace>>
<<process>> Gestor de cuenta
Factura
<<trace>>
Gestor de cuentas
<<trace>>
<<process>> Gestor de cliente
Facturas
Albarn
<<trace>>
Gestor de clientes
<<Interface_design>> Teclado
<<trace>>
<<Interface_design>> Pantalla
<<trace>>
<<trace>> <<trace>> Interfaz de terminal celular

<<Interface_design>> Altavoz
<<Interface_design>> Puerto MSVL
<<trace>>
<<Interface_design>> Mi crfono

En el proceso de conversin del Modelo de Anlisis (MA) al Modelo de Diseo (MD), la estrategia adoptada es mixta:
Top-Down + Level-to-Level
Modelo de Anlisis
Subsistema(DA)-Subsistema(DD)
Modelo de Diseo
Bottom-Up
MA Nivel 0
Subsistema 1
MD Nivel 0
Subsistema 1
MA Nivel 1
Subsistema 3
Subsistema 2
MD Nivel 1
Subsistema 3
Subsistema 2
MA Nivel 2
MD Nivel 2
Top-Down
MA Nivel j
MD Nivel i

15.7. Modelado de Diseo Tutorial UML y PU: 127/138
Modelo de Anlisis Bottom-Up

MA Nivel 0
Subsistema(DA)-Subsistema(DD)
Modelo de Diseo Top-Down

MD Nivel 0
MA Nivel 1
MD Nivel 1
Cta_Cliente
Cliente
I_Cajero
MA Nivel 2
C_Gestor_Interfaz
MD Nivel 2
I_Autenticacion
C_Verificador_Autenticacio n
MA Nivel j
Level-to-Level
MD Nivel i

15.8. Modelado de Diseo Tutorial UML y PU: 128/138
La estructura del modelo en Rose:
Diagrama de Clases de Diseo de Contexto
16. Modelado de Implementacin

El modelado de implementacin se realiza para obtener:
La implementacin del sistema en trminos de lenguajes y elementos de programacin. La distribucin de los mdulo software en los elementos hardware del sistema.
En el flujo de implementacin se construye un modelo que representa la estructura y el comportamiento internos del sistema en cuanto a:
Componentes y mdulos. Arquitectura software del sistema.
En el flujo de despliegue se construye un modelo que representa la estructura y el comportamiento internos del sistema en cuanto a:
Arquitectura hardware del sistema.
16.1. Modelado de Implementacin

Flujo de Anlisis de Requisitos
verificado por
especificado por realizado por distribuido por
Modelo de Anlisis
Flujo de Anlisis y Diseo
Modelo de Prueba
Modelo de Diseo
Flujo de Despliegue
implementado por
Flujo de Implementa cin
Transicin del MD hacia el MDP 16.2. Modelado de Implementacin

Gestin Proyectos Gestin Poblacin
Modelo de Implementacin (Vista parcial)

Gestin individuos Gestor Base de Datos Program a Principal
Gestin Interfaces Gestin Agentes
Gestin Clculo
componentes
(Vista parcial)
nodos / procesadores
17. Resumen
El Proceso Unificado es una metodologa 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 tcnicas orientadas a objetos. Impulsa un control de calidad y una gestin del riesgo objetivos y continuos.
17.1. Resumen
17. Resumen
La aplicacin formal del Proceso Unificado supone:
Desventajas:
Grandes esfuerzos en la construccin de modelos. Necesidad del soporte de herramientas informticas.
Ventajas:
Disminuye el riesgo del error de anlisis / diseo acumulado. Aligera el esfuerzo en implementacin. Proporciona la documentacin del ciclo de vida en el mismo proceso.
17.2. Resumen
17. Resumen
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 incorporacin de enfoques y artefactos complementarios:
Patrones de diseo. Patrones de implementacin. Marcos de diseo. Combinacin de varios modelos de proceso. Arquitecturas Dirigidas por Modelos (Model Driven Architectures). Ejecutabilidad de modelos: UML 2, validacin y verificacin formales.
17.3. Resumen
18. Bibliografa
1. 2. 3. 4. 5. 6. 7. 8. 9. Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de Modelado, Addison-Wesley, Madrid, 1999. Bruegge B., Dutoit A.H. Ingeniera de Software Orientado a Objetos, Prentice Hall Pearson educacin, Mxico, 2002. Jacobson I., Booch G., Rumbaugh J. El Proceso Unificado de Desarrollo de Software, Addison-Wesley, Madrid, 2000. Pressman R.S. Ingeniera del Software. Un enfoque prctico (5 ed.) Mc Graw-Hill; New York , 2001. Rumbaugh J., Jacobson I., Booch G. El Lenguaje Unificado de Modelado. Manual de Referencia, Addison-Wesley, Madrid, 2000. Sommerville I. Ingeniera de software, 6 edicin, Prentice Hall Pearson educacin, Mxico, 2002. Stevens P., Pooley R. Utilizacin de UML en Ingeniera del Software con Objetos y Componentes, Addison-Wesley, Madrid, 2002. http://www.omg.org http://www.uml.org
18. Bibliografa Parte II

2004inforsaludtutorialuml Up 101025085108 Phpapp01

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

2004inforsaludtutorialuml Up 101025085108 Phpapp01

Cargado por

Copyright:

Formatos disponibles

VII CONGRESO NACIONAL DE INFORMTICA DE LA SALUD Madrid, 24-26 de marzo de 2004

UML y Proceso Unificado en Informtica Biomdica

Tutorial UML y PU: 2/138

Tutorial UML y PU: 3/138

Tutorial UML y PU: 4/138

Tutorial UML y PU: 5/138

Tutorial UML y PU: 6/138

Tutorial UML y PU: 7/138

Tutorial UML y PU: 8/138

3. La Orientacin a Objetos, OO:

Objetos mudo real Objetos informticos

3.1. La Orientacin a Objetos

Tutorial UML y PU: 9/138

3. La Orientacin a Objetos, OO:

Atributo: Dato identificado por un nombre.

3.2. La Orientacin a Objetos

Tutorial UML y PU: 10/138

3. La Orientacin a Objetos, OO:

Objeto Conjunto de Atributos y Mtodos

3.3. La Orientacin a Objetos

Tutorial UML y PU: 11/138

3. La Orientacin a Objetos, OO:

3.4. La Orientacin a Objetos

Tutorial UML y PU: 12/138

3. La Orientacin a Objetos, OO:

3.5. La Orientacin a Objetos

Tutorial UML y PU: 13/138

3. La Orientacin a Objetos, OO:

3.6. La Orientacin a Objetos

Tutorial UML y PU: 14/138

3. La Orientacin a Objetos, OO:

3.7. La Orientacin a Objetos

Tutorial UML y PU: 15/138

3. La Orientacin a Objetos, OO:

3.8. La Orientacin a Objetos

Tutorial UML y PU: 16/138

3. La Orientacin a Objetos, OO:

3.9. La Orientacin a Objetos

Tutorial UML y PU: 17/138

3. La Orientacin a Objetos, OO:

3.10. La Orientacin a Objetos

Tutorial UML y PU: 18/138

3. La Orientacin a Objetos, OO:

3.11. La Orientacin a Objetos

Tutorial UML y PU: 19/138

4. El Lenguaje Unificado de Modelado

Tutorial UML y PU: 20/138

4. El Lenguaje Unificado de Modelado:

Tutorial UML y PU: 21/138

4. El Lenguaje Unificado de Modelado:

Tutorial UML y PU: 22/138

4. El Lenguaje Unificado de Modelado:

Tutorial UML y PU: 23/138

4. El Lenguaje Unificado de Modelado:

Tutorial UML y PU: 24/138

4. El Lenguaje Unificado de Modelado:

Tutorial UML y PU: 25/138

4. El Lenguaje Unificado de Modelado:

Tutorial UML y PU: 26/138

4. El Lenguaje Unificado de Modelado:

Tutorial UML y PU: 27/138

4. El Lenguaje Unificado de Modelado:

Tutorial UML y PU: 28/138

4. El Lenguaje Unificado de Modelado: