Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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
Universitat Jaume I
© O. Coltell, M. Arregui, 2004 Tutorial UML y PU: 1/138
CONTENIDO
GENERAL
Miguel Arregui
1. Objetivos.
2. Introducción.
3. La Orientación a Objetos, OO.
4. El Lenguaje Unificado de Modelado.
(Elementos, Relaciones, Diagramas).
5. Cómo utilizar UML.
6. Bibliografía.
Modela
© O. Coltell, M. Arregui, 2004 3.1. La Orientación a Objetos Tutorial UML y PU: 9/138
3. La Orientación a Objetos, OO:
© O. Coltell, M. Arregui, 2004 3.2. La Orientación a Objetos Tutorial UML y PU: 10/138
3. La Orientación a Objetos, OO:
© O. Coltell, M. Arregui, 2004 3.3. La Orientación a Objetos Tutorial UML y PU: 11/138
3. La Orientación a Objetos, OO:
© O. Coltell, M. Arregui, 2004 3.4. La Orientación a Objetos Tutorial UML y PU: 12/138
3. La Orientación a Objetos, OO:
© O. Coltell, M. Arregui, 2004 3.5. La Orientación a Objetos Tutorial UML y PU: 13/138
3. La Orientación a Objetos, OO:
© O. Coltell, M. Arregui, 2004 3.6. La Orientación a Objetos Tutorial UML y PU: 14/138
3. La Orientación a Objetos, OO:
© O. Coltell, M. Arregui, 2004 3.7. La Orientación a Objetos Tutorial UML y PU: 15/138
3. La Orientación a Objetos, OO:
© O. Coltell, M. Arregui, 2004 3.8. La Orientación a Objetos Tutorial UML y PU: 16/138
3. La Orientación a Objetos, OO:
© O. Coltell, M. Arregui, 2004 3.9. La Orientación a Objetos Tutorial UML y PU: 17/138
3. La Orientación a Objetos, OO:
© O. Coltell, M. Arregui, 2004 3.10. La Orientación a Objetos Tutorial UML y PU: 18/138
3. La Orientación a Objetos, OO:
Interfaces Protocolos
© O. Coltell, M. Arregui, 2004 3.11. La Orientación a Objetos Tutorial UML y PU: 19/138
4. El Lenguaje Unificado de Modelado
Clase activa
Elementos de notación:
Diagrama de Clases:
Las relaciones pueden traer asociada una multiplicidad, expresada “en el lado opuesto” de
la relación. Resume el número de posibles instancias de una clase asociadas a una única
instancia de la clase en el otro extremo.
Multiplicidad Significado
1 Una única instancia
N/* N instancias
0..N / 0..* Entre ninguna y N instancias
1..N / 1..* Entre una y N instancias
0..1 Ninguna o una instancia
N..M Entre N y M instancias
Diagrama de Clases:
En las relaciones de
dependencia un
cambio en la clase
dependida afectará la
clase dependiente.
Compartimentos de la clase: Acceso de atributos y métodos:
primero nombre “+” público
segundo atributos “-” privado (sólo los métodos),
tercero métodos “#” protegido (sólo clases hija).
Diagrama de Clases:
Diagrama de Objetos:
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
Diagrama de Componentes:
Diagrama de Despliegue:
Los diagramas de despliegue sirven para modelar la configuración hardware del sistema,
mostrando qué nodos lo componen
Las líneas que unen los Actores con los Casos de Uso
(óvalos) representan una asociación de comunicación.
Los Casos de Uso pueden acompañarse de texto que enriquezca el lenguaje gráfico.
estereotipo
generalización
Diagrama de Secuencia:
Describen cómo los objetos del sistema colaboran.
Orden participación
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.
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
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 condición.
Circunstancia o condición inicio Resultado de
que provoca la transición actividad
acción
fin
Diagrama de Estados:
Los estados pueden anidarse, agrupando estados relacionados en un estado compuesto.
Puede ser necesario cuando una actividad involucra actividades concurrentes o asíncronas.
Diagrama de Actividades:
Son diagramas de flujo
adornados, con mucha
similitud a los diagramas
de estados.
© O. Coltell, M. Arregui, 2004 5.1. Cómo Utilizar UML Tutorial UML y PU: 46/138
5. Cómo utilizar UML:
UML proporciona mayores beneficios si se selecciona un
proceso dirigido por Casos de Uso, centrado en la
arquitectura y sea incremental.
© O. Coltell, M. Arregui, 2004 5.2. Cómo Utilizar UML Tutorial UML y PU: 47/138
5. Cómo utilizar UML:
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.
© O. Coltell, M. Arregui, 2004 5.3. Cómo Utilizar UML Tutorial UML y PU: 48/138
5. Cómo utilizar UML:
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.
© O. Coltell, M. Arregui, 2004 5.4. Cómo Utilizar UML Tutorial UML y PU: 49/138
5. Cómo utilizar UML:
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.
© O. Coltell, M. Arregui, 2004 5.5. Cómo Utilizar UML Tutorial UML y PU: 50/138
5. Cómo utilizar UML:
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.
© O. Coltell, M. Arregui, 2004 5.6. Cómo Utilizar UML Tutorial UML y PU: 51/138
5. Cómo utilizar UML:
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.
© O. Coltell, M. Arregui, 2004 5.7. Cómo Utilizar UML Tutorial UML y PU: 52/138
5. Cómo utilizar UML:
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.
© O. Coltell, M. Arregui, 2004 5.8. Cómo Utilizar UML Tutorial UML y PU: 53/138
5. Cómo utilizar UML:
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.
© O. Coltell, M. Arregui, 2004 5.9. Cómo Utilizar UML Tutorial UML y PU: 54/138
5. Cómo utilizar UML:
© O. Coltell, M. Arregui, 2004 5.10. Cómo Utilizar UML Tutorial UML y PU: 55/138
5. Cómo utilizar UML:
© O. Coltell, M. Arregui, 2004 5.11. Cómo Utilizar UML Tutorial UML y PU: 56/138
5. Cómo utilizar UML:
© O. Coltell, M. Arregui, 2004 5.12. Cómo Utilizar UML Tutorial UML y PU: 57/138
6. Bibliografía:
© O. Coltell, M. Arregui, 2004 6.1. Bibliografía PARTE I Tutorial UML y PU: 58/138
Parte II:
Introducción al Proceso
Unificado
Òscar Coltell
© O. Coltell, M. Arregui, 2004 8.1. Conceptos fundamentales Tutorial UML y PU: 62/138
8. 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.
• 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.
© O. Coltell, M. Arregui, 2004 8.2. Conceptos fundamentales Tutorial UML y PU: 63/138
8. Conceptos fundamentales
• Ciclo de vida del software:
– Es el conjunto de fases por las que pasa el
software, que abarcan desde su creación u origen,
hasta su eliminación o liquidación formal.
• Modelo de desarrollo:
– También denominado Modelo de Proceso.
– Estrategia de desarrollo basada en el ciclo de
vida, naturaleza del proyecto y metodología, que
determina las características específicas del
proceso (Pressman 2001).
© O. Coltell, M. Arregui, 2004 8.3. Conceptos fundamentales Tutorial UML y PU: 64/138
8. Conceptos fundamentales
Ciclo de vida del software completo
Prepa- Mode- Análi- Análi- Dise- Cons- Prue- Entre- Explo- Liqui-
ración lado sis de sis ño truc- bas ga tación / dación
del del requi- ción Manten
proble nego- sitos imiento
ma cio
% Implementación
% Conocimiento
Conocimiento
Implementación
Tiempo
© O. Coltell, M. Arregui, 2004 8.4. Conceptos fundamentales Tutorial UML y PU: 65/138
8. Conceptos fundamentales
• Principios fundamentales:
– 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.
© O. Coltell, M. Arregui, 2004 8.5. Conceptos fundamentales Tutorial UML y PU: 66/138
8. Conceptos fundamentales
Estructura formal de la Ingeniería del Software
PRINCIPIOS
PRINCIPIOSDE
DE
LA
LA INGENIERÍADEL
INGENIERÍA DELSOFTWARE
SOFTWARE
NORMAS
TÉCNICAS
NORMAS
NORMASDE DE OTRAS
LA NORMAS
LA INGENIERÍADEL
INGENIERÍA DELSOFTWARE
SOFTWARE
ESTÁNDARES
MODELOS METODOLOGÍAS
MODELOSDE
DE METODOLOGÍAS
RUP
PROCESO / /PARADIGMAS
PARADIGMAS
PROCESO
PROCESO
TÉCNICAS
TÉCNICAS HERRAMIENTAS
HERRAMIENTAS
PRODUCTO
© O. Coltell, M. Arregui, 2004 8.6. Conceptos fundamentales Tutorial UML y PU: 67/138
9. El Proceso Unificado
El Proceso Unificado:
A. Es un Proceso iterativo.
iterativo
B. Está centrado en la arquitectura.
C. Está dirigido por los casos de uso.
D. Es un proceso configurable.
E. Soporta las técnicas orientadas a objetos.
F. Impulsa un control de calidad y una gestión del
riesgo objetivos y continuos.
© O. Coltell, M. Arregui, 2004 9.1. El Proceso Unificado Tutorial UML y PU: 68/138
9. El Proceso Unificado
• A. El RUP es un proceso 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.
© O. Coltell, M. Arregui, 2004 9.2. El Proceso Unificado Tutorial UML y PU: 69/138
9. El Proceso Unificado
© O. Coltell, M. Arregui, 2004 9.3. El Proceso Unificado Tutorial UML y PU: 70/138
9. El Proceso Unificado
© O. Coltell, M. Arregui, 2004 9.4. El Proceso Unificado Tutorial UML y PU: 71/138
9. El Proceso Unificado
© O. Coltell, M. Arregui, 2004 9.5. El Proceso Unificado Tutorial UML y PU: 72/138
9. El Proceso Unificado
© O. Coltell, M. Arregui, 2004 9.6. El Proceso Unificado Tutorial UML y PU: 73/138
9. El Proceso Unificado
© O. Coltell, M. Arregui, 2004 9.7. El Proceso Unificado Tutorial UML y PU: 74/138
9. El Proceso Unificado
© O. Coltell, M. Arregui, 2004 9.8. El Proceso Unificado Tutorial UML y PU: 75/138
El ciclo de vida del desarrollo del software
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
© O. Coltell, M. Arregui, 2004 9.9. El Proceso Unificado Tutorial UML y PU: 76/138
9. El Proceso Unificado
• En esta estructura matricial se puede deducir
que:
– 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.
© O. Coltell, M. Arregui, 2004 9.10. El Proceso Unificado Tutorial UML y PU: 77/138
9. 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
© O. Coltell, M. Arregui, 2004 9.11. El Proceso Unificado Tutorial UML y PU: 78/138
resultados Z: Modelos
(x,z): versiones
X,Y,Z:
(y,z): tipos de Configuraciones
modelos del sistema
tiempo
X: Fases
Y: Flujos
de trabajo esfuerzo (x,y): iteraciones
© O. Coltell, M. Arregui, 2004 9.12. El Proceso Unificado Tutorial UML y PU: 79/138
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
– 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.
© O. Coltell, M. Arregui, 2004 10.1. Fases del ciclo Tutorial UML y PU: 80/138
10. Fases del ciclo
• 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.
© O. Coltell, M. Arregui, 2004 10.2. Fases del ciclo Tutorial UML y PU: 81/138
Las iteraciones son distintas en el ciclo de vida
Flujos de trabajo
del proceso Iniciación Elaboración Construcción Transición
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
© O. Coltell, M. Arregui, 2004 10.3. Fases del ciclo Tutorial UML y PU: 82/138
10. Fases del ciclo
• 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.
© O. Coltell, M. Arregui, 2004 10.4. Fases del ciclo Tutorial UML y PU: 83/138
11. Flujos de trabajo
© O. Coltell, M. Arregui, 2004 11.1. Flujos de trabajo Tutorial UML y PU: 84/138
11. Flujos de trabajo
Flujos de trabajo del proceso:
© O. Coltell, M. Arregui, 2004 11.2. Flujos de trabajo Tutorial UML y PU: 85/138
11. Flujos de trabajo
Flujos de trabajo de soporte:
© O. Coltell, M. Arregui, 2004 11.3. Flujos de trabajo Tutorial UML y PU: 86/138
El ciclo de vida del desarrollo del software:
Flujos
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
© O. Coltell, M. Arregui, 2004 11.4. Flujos de trabajo Tutorial UML y PU: 87/138
12. Tipos de resultados
• Un modelo es una abstracción de la realidad o de un
sistema real tomando los elementos más
representativos con un propósito determinado.
• De un mismo sistema puede haber más de un
modelo, porque, según el propósito del mismo, los
elementos representativos pueden ser distintos.
• Los elementos a considerar en la construcción de
modelos son: supuestos, simplificaciones,
limitaciones o restricciones y preferencias
© O. Coltell, M. Arregui, 2004 12.1. Tipos de resultados Tutorial UML y PU: 88/138
12. Tipos de resultados
• Los supuestos:
– Son elementos para la construcción de modelos que reducen el
número de permutaciones y variaciones posibles, permitiendo al
modelo reflejar el problema de manera razonable.
• Las simplificaciones:
– Son elementos para la construcción de modelos que permiten crear
el modelo a tiempo.
• Las limitaciones o restricciones:
– Son elementos para la construcción de modelos que ayudan a
delimitar el problema.
• Las preferencias:
– Son elementos para la construcción de modelos que indican la
arquitectura preferida para toda la información, funciones y
tecnología.
– Pueden tener conflictos con otros factores restrictivos.
– Es recomendable tenerlas en cuenta para obtener un resultado
aceptado, además de correcto.
© O. Coltell, M. Arregui, 2004 12.2. Tipos de resultados Tutorial UML y PU: 89/138
12. Tipos de resultados
• Un modelo de objetos o modelo 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.
© O. Coltell, M. Arregui, 2004 12.3. Tipos de resultados Tutorial UML y PU: 90/138
12. Tipos de 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.
• Estos artefactos son adicionales a los que
proporciona el propio UML:
– Los modelos y los conjuntos.
© O. Coltell, M. Arregui, 2004 12.4. Tipos de resultados Tutorial UML y PU: 91/138
12. Tipos de resultados
• Los modelos 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.
© O. Coltell, M. Arregui, 2004 12.5. Tipos de resultados Tutorial UML y PU: 92/138
12. Tipos de resultados
Modelos del Proceso Unificado:
1. Modelo del negocio: establece una abstracción de la organización.
2. Modelo del dominio: establece el contexto del sistema.
3. Modelo de casos de uso: establece los requisitos funcionales del
sistema.
4. Modelo de análisis (opcional): establece un diseño de las ideas.
5. Modelo de diseño: establece el vocabulario del problema y su
solución.
6. Modelo del proceso (opcional): establece los mecanismos de
concurrencia y sincronización del sistema.
7. Modelo de despliegue: establece la topología hardware sobre la
cual se ejecutará el sistema.
8. Modelo de implementación: establece las partes que se utilizarán
para ensamblar y hacer disponible el sistema físico.
9. Modelo de pruebas: establece las formas de validar y verificar el
sistema.
© O. Coltell, M. Arregui, 2004 12.6. Tipos de resultados Tutorial UML y PU: 93/138
Relaciones lógicas entre los modelos :
Modelo de
Casos de Uso verificado por
© O. Coltell, M. Arregui, 2004 12.7. Tipos de resultados Tutorial UML y PU: 94/138
Modelos y flujos de trabajo
del Proceso Unificado
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
© O. Coltell, M. Arregui, 2004 12.8. Tipos de resultados Tutorial UML y PU: 95/138
MODELOS Y DIAGRAMAS EN EL RUP
Modelo del Modelo del Modelo de Modelo de Modelo de Modelo de Modelo de Modelo Modelo de
Negocio Dom inio Casos de Análisis Diseño Procesos Despliegue Im plem en- Prueba
Uso tación
Est. Din. Est. Din. Est. Din. Est. Din. Est. Din. Est. Din. Est. Din. Est. Din. Est. Din.
Diagram a de
Casos de Uso X X X
Diagram a de
Interacción- X X X X X X X X
Secuencia
Diagram a de
Interacción- X X X X X X X X
Colaboración
Diagram a de
Clases de X
Análisis
Diagram a de
Objetos de X
Análisis
Diagram a de
Clases de X X
Diseño
Diagram a de
Objetos de X X
Diseño
Diagram a de
Estados X X X X X X
Diagram a de
Actividades X X X X X
Diagram a de
Com ponentes X
Diagram a de
Despliegue X
© O. Coltell, M. Arregui, 2004 12.9. Tipos de resultados Tutorial UML y PU: 96/138
6. Tipos de resultados
• El Proceso Unificado recupera el concepto de vista
de UML.
• Para el Proceso Unificado una vista es:
– Una proyección de un modelo.
– Una proyección de la organización 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 interactúan entre sí:
– La vista de casos de uso.
– La vista de diseño.
– La vista de procesos.
– La vista de despliegue.
– La vista de implementación.
© O. Coltell, M. Arregui, 2004 12.10. Tipos de resultados Tutorial UML y PU: 97/138
Vistas de la arquitectura de un sistema
© O. Coltell, M. Arregui, 2004 12.11. Tipos de resultados Tutorial UML y PU: 98/138
6. Tipos de resultados
© O. Coltell, M. Arregui, 2004 12.12. Tipos de resultados Tutorial UML y PU: 99/138
6. Tipos de resultados
Nombre Descripción Aspectos Aspectos
Estáticos Dinámicos
Vista de casos Proyecta el comportamiento del sistema tal y como Diagramas de casos de Diagramas de interacción
de uso es percibido por los: usuarios finales, analistas y en- uso Diagramas de estados
cargados de las pruebas. Especifica las fuerzas que
configuran la arquitectura del sistema.
Vista de diseño Soporta los requisitos funcionales del sistema: servi- Diagramas de clases Diagramas de interacción
cios proporcionados a los usuarios finales. Vocabula- Diagramas de objetos Diagramas de estados
rio del problema y su solución: clases, interfaces y
colaboraciones. Diagramas de actividades
Vista de procesos Cubre el funcionamiento, capacidad de crecimiento y Diagramas de clases Diagramas de interacción
rendimiento del sistema. Mecanismos de sincroniza- (activas) Diagramas de estados
ción y concurrencia del sistema: hilos y procesos. Diagramas de objetos Diagramas de actividades
Vista de implementa- Cubre la gestión de configuraciones de las distintas Diagramas de componen- Diagramas de interacción
ción versiones de un sistema a partir de componentes y tes Diagramas de estados
archivos quasi-independientes. Ensamblado y dispo-
nibilidad del sistema: componentes y archivos. Diagramas de actividades
Vista de despliegue Contiene los nodos que forman la arquitectura (topo- Diagramas de despliegue Diagramas de interacción
logía) hardware sobre la que se ejecuta el sistema a Diagramas de estados
través de sus componentes. Está destinada a repre-
sentar la distribución, entrega e instalación de las Diagramas de actividades
partes que forman el sistema informático físico.
© O. Coltell, M. Arregui, 2004 12.13. Tipos de resultados Tutorial UML y PU: 100/138
VISTAS Y DIAGRAMAS EN UML
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
© O. Coltell, M. Arregui, 2004 12.14. Tipos de resultados Tutorial UML y PU: 101/138
6. Tipos de resultados
© O. Coltell, M. Arregui, 2004 12.15. Tipos de resultados Tutorial UML y PU: 102/138
6. Tipos de resultados
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.
© O. Coltell, M. Arregui, 2004 12.16. Tipos de resultados Tutorial UML y PU: 103/138
6. Tipos 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.
© O. Coltell, M. Arregui, 2004 12.17. Tipos de resultados Tutorial UML y PU: 104/138
6. Tipos 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.
© O. Coltell, M. Arregui, 2004 12.18. Tipos de resultados Tutorial UML y PU: 105/138
6. Tipos de resultados
4. Conjunto de despliegue:
• Agrupa toda la información acerca de la forma
en que se empaqueta actualmente el software,
se distribuye, se instala y se ejecuta en el
entorno destino.
© O. Coltell, M. Arregui, 2004 12.19. Tipos de resultados Tutorial UML y PU: 106/138
13. Captura y Modelado
de Requisitos
• 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
Problema:
Problema
– Descripción concreta del negocio.
– Dominio de los Objetos de Negocio (DON).
• Las soluciones pertenecen al Espacio de la Solución:
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).
© O. Coltell, M. Arregui, 2004 13.1. Captura y Modelado de Requisitos Tutorial UML y PU: 107/138
13. Captura y Modelado
de Requisitos
Espacio de la
Espacio del Solución de Usuario
Problema Análisis de
Requisitos
Análisis OO
Espacio de la
Solución de
Implementación
Diseño OO
Espacio de la
Diseño
Solución Técnica
© O. Coltell, M. Arregui, 2004 13.2. Captura y Modelado de Requisitos Tutorial UML y PU: 108/138
13. 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).
© O. Coltell, M. Arregui, 2004 13.3. Captura y Modelado de Requisitos Tutorial UML y PU: 109/138
13. Captura y Modelado
de Requisitos
Flujos de trabajo
del proceso Iniciación Elaboración Construcción Transición
Modelado del
negocio
Requisitos
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
© O. Coltell, M. Arregui, 2004 13.4. Captura y Modelado de Requisitos Tutorial UML y PU: 110/138
13. Captura y Modelado
de Requisitos
• El Modelo de Casos de Uso (MCU) establece los
requisitos funcionales del sistema de información.
• En el MCU se recoge la descripción externa y
observable de cómo se utiliza el sistema de
información:
– Descripción de CÓMO se utiliza el sistema:
• Funciones, Servicios y Procesos.
– Descripción EXTERNA del uso del sistema:
• Se identifican y describen funciones/servicios/procesos
del negocio que un usuario puede hacer con el soporte
del sistema de información.
– Descripción 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.
© O. Coltell, M. Arregui, 2004 13.5. Captura y Modelado de Requisitos Tutorial UML y PU: 111/138
13. Captura y Modelado
de Requisitos Diagrama de Contexto
del SMCU de Negocio
SubModelo de Casos
de Uso de Negocio
SubModelo de Casos
Diagrama de Contexto de Uso (Técnico)
del SMCU Técnico
Diagrama Principal
Busi ness Use-Case
del Modelo de Casos M odel
Us e-Cas e Model
© O. Coltell, M. Arregui, 2004 13.6. Captura y Modelado de Requisitos Tutorial UML y PU: 112/138
13. Captura y Modelado
de Requisitos
Diagrama de Contexto
del MCU
© O. Coltell, M. Arregui, 2004 13.7. Captura y Modelado de Requisitos Tutorial UML y PU: 113/138
14. Modelado de Análisis
• 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.
© O. Coltell, M. Arregui, 2004 14.1. Modelado de Análisis Tutorial UML y PU: 114/138
14. Modelado de Análisis
Modelo de
Casos de Uso verificado por
© O. Coltell, M. Arregui, 2004 14.2. Modelado de Análisis Tutorial UML y PU: 115/138
14. Modelado de Análisis
© O. Coltell, M. Arregui, 2004 14.3. Modelado de Análisis Tutorial UML y PU: 116/138
14. Modelado de Análisis
Flujos de trabajo
del proceso Iniciación Elaboración Construcción Transición
Modelado del
negocio
Requisitos
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Gestión del proyecto
Entorno
© O. Coltell, M. Arregui, 2004 14.4. Modelado de Análisis Tutorial UML y PU: 117/138
Modelo de casos de uso
con estructura de
desglose de diagramas
NIVEL 0 Proceso de Conversión:
Cada caso de uso se
desglosa en un diagrama
Casos de Uso
en el nivel inferior
Análisis
NIVEL1
«trace»
© O. Coltell, M. Arregui, 2004 14.5. Modelado de Análisis Tutorial UML y PU: 118/138
MODELO DE CASOS DE USO MODELO DE ANÁLISIS
«trace»
Realización (MA)
Proceso de Conversión:
caso de uso (MCU)
Casos de Uso
Análisis
Interfaz Gestor/Control Entidad
Diagrama de
Clases de Análisis
Atómico
I_Autenticacion C_Verificador_Autenticacio
n
© O. Coltell, M. Arregui, 2004 14.6. Modelado de Análisis Tutorial UML y PU: 119/138
Modelo de Casos de Uso Modelo de Análisis
Servicio(CU)-Subsistema(DA)
MCU MA
Top-Down Nivel 0 Subsistema 1 Nivel 0 Bottom-Up
MA
MCU Subsistema 2
Nivel 1
Nivel 1
Subsistema 3
MCU MA
Nivel 2 Nivel 2
Nivel i Nivel j
MODELO DE CASOS DE USO MODELO DE ANÁLISIS Cliente I_Cajero C_Ges tor_Interfaz Cta_Cliente
«trace»
© O. Coltell, M. Arregui, 2004 14.7. Modelado de Análisis Tutorial UML y PU: 120/138
La estructura del modelo en Rose:
Diagrama de Clases
de Análisis de Contexto
© O. Coltell, M. Arregui, 2004 14.8. Modelado de Análisis Tutorial UML y PU: 121/138
15. Modelado de Diseño
© O. Coltell, M. Arregui, 2004 15.1. Modelado de Diseño Tutorial UML y PU: 122/138
Flujo de
15. Modelado de Diseño
Análisis de
Requisitos
Modelo de
Casos de Uso verificado por
especificado por
Modelo de
distribuido por Prueba
realizado por
Modelo de
Análisis
Modelo de implementado por
Diseño
Flujo de
Análisis y Modelo de
Diseño Despliegue
Modelo de
Transición del MCA hacia el MD
Implementación
© O. Coltell, M. Arregui, 2004 15.2. Modelado de Diseño Tutorial UML y PU: 123/138
15. Modelado de Diseño
© O. Coltell, M. Arregui, 2004 15.3. Modelado de Diseño Tutorial UML y PU: 124/138
<<trace>> < <p ro ce s s >> Factura
Ge s to r d e cu e n ta <<trace>>
G estor de cuentas
© O. Coltell, M. Arregui, 2004 15.4. Modelado de Diseño Tutorial UML y PU: 125/138
15. Modelado de Diseño
Top-Down
+
Level-to-Level
© O. Coltell, M. Arregui, 2004 15.6. Modelado de Diseño Tutorial UML y PU: 126/138
Modelo de Análisis Modelo de Diseño
Subsistema(DA)-Subsistema(DD)
Bottom-Up MA MD
Nivel 0 Subsistema 1
Nivel 0
Subsistema 1
MA
Nivel 1 Subsistema 2 MD
Nivel 1 Subsistema 2
Subsistema 3
MA Subsistema 3 Top-Down
MD
Nivel 2 Nivel 2
MA MD
Nivel j Nivel i
Modelo de
Casos de Uso
© O. Coltell, M. Arregui, 2004 15.7. Modelado de Diseño Tutorial UML y PU: 127/138
Modelo de Análisis Modelo de Diseño
Top-Down
Subsistema(DA)-Subsistema(DD)
Bottom-Up
MA MD
Nivel 0 Nivel 0
MA
Nivel 1 MD
F01.01 Consulta saldo
Nivel 1
asociación
Punto Figura_2D
de fi ne
Coord_X : Double Centro : Punto
Coord_Y : Double Superficie : Doubl e
Instancias de Instancia de
la c lase Punto la clase
Cliente I_Cajero
MA C_Ges tor_Interfaz Cta_Cliente
MD
abstracción
Figura_2D
Nivel 2 <<object>>
Punto: Pto_1
Coord_X = 5 Nivel 2
define Figura_2D: Triángulo_T1
Coord_Y = 6
define
<<object>> define
MA MD
<<object>>
Punto: Pto_2
Modelo de
Casos de Uso
© O. Coltell, M. Arregui, 2004 15.8. Modelado de Diseño Tutorial UML y PU: 128/138
© O. Coltell, M. Arregui, 2004 15.9. Modelado de Diseño Tutorial UML y PU: 129/138
La estructura del modelo en Rose:
Diagrama de Clases
de Diseño de Contexto
© O. Coltell, M. Arregui, 2004 15.10. Modelado de Diseño Tutorial UML y PU: 130/138
16. Modelado de Implementación
© O. Coltell, M. Arregui, 2004 16.1. Modelado de Implementación Tutorial UML y PU: 131/138
16. Modelado de Implementación
Flujo de
Análisis de
Requisitos
Modelo de
Casos de Uso verificado por
especificado por
Modelo de
distribuido por Prueba
realizado por
Modelo de
Análisis
Modelo de implementado por
Diseño
Flujo de Flujo de
Análisis y Modelo de Implementa
Diseño Flujo de Despliegue ción
Despliegue
Modelo de
Transición del MD hacia el MDP
Implementación
© O. Coltell, M. Arregui, 2004 16.2. Modelado de Implementación Tutorial UML y PU: 132/138
16. Modelado de Implementación
Ges tión Proyectos
Gestión Población
Modelo de
Implementación
(Vista parcial)
Gestión individuos
Gestor Base de Datos
Programa Principal
Gestión Interfaces
Gestión Agentes
Gestión Cálculo
componentes
© O. Coltell, M. Arregui, 2004 16.3. Modelado de Implementación Tutorial UML y PU: 133/138
16. Modelado de Implementación
Modelo de Despliegue
(Vista parcial)
nodos /
procesadores
© O. Coltell, M. Arregui, 2004 16.4. Modelado de Implementación Tutorial UML y PU: 134/138
17. Resumen
• 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
objetivos y continuos.
© O. Coltell, M. Arregui, 2004 18. Bibliografía Parte II Tutorial UML y PU: 138/138