Tutorial. UML y Proceso Unificado en Inform

1
Tutorial. UML y Proceso Unificado en
Informática Biomédica
VII CONGRESO NACIONAL DE INFORMÁTICA DE LA
SALUD Madrid, 24-26 de marzo de 2004
Ò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
2
CONTENIDOGENERAL
Parte I Introducción a UML. Parte II
Introducción al Proceso Unificado.
3
Parte IIntroducción a UML
Miguel Arregui
4
PARTE I. CONTENIDO

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.

5
1. Objetivos

• Introducir los conceptos que maneja UML
• Ser una útil toma de contacto con UML para
• Conocer sus posibilidades
• Decidir si incluirlo en el arsenal de desarrollo
• Ser breve, conciso y no entrar en excesivos
  detalles
• Describir cómo emplear UML en un proyecto

1.1. Objetivos
6
2. Introducción
Problema Actualmente, Software Grande y
Complejo. Demanda de interfaces más completas,
funcionalidades más elaboradas ? Impacto en
complejidad del producto. Requisitos Los
programas deben poder ser mantenidos y ampliados
con garantías de éxito. Solución
Estructuración, modelado.
2.1. Introducción
7
2. Introducción
Ante problemas complejos ? Divide y vence ?
Estructura
Modela
Modelar es diseñar y estructurar, antes de
programar. Sirve para visualizar un diseño y
especificar su estructura y comportamiento. Se
abstraen los detalles del problema complejo
simplificando su desarrollo.
2.2. Introducción
8
2. Introducción
UML es un lenguaje gráfico para Modelar,
diseñar, estructurar, visualizar, especificar y
documentar Software. Proporciona vocabulario
común a la cadena de producción. Es un estándar
para crear planos completos y no
ambiguos. Creado por el OMG y usado por NASA,
ESA, EBI, W3C...
2.3. Introducción
9
3. La Orientación a Objetos, OO
UML está muy cerca de este paradigma.
Objeto Intuitivamente todo lo que tiene masa,
aunque también hay objetos no tangibles. En
informática, definen representaciones abstractas
de entidades del mundo, tangibles o no, con la
intención de emularlas.
Objetos mudo real ?? Objetos informáticos
3.1. La Orientación a Objetos
10
3. La Orientación a Objetos, OO
Los objetos se caracterizan por su estado y
comportamiento.
Estado Situación en que se encuentra un objeto,
tal que cumple alguna condición/es particulares,
realiza una actividad o espera que suceda un
acontecimiento.
Los objetos mantienen su estado en uno o mas
atributos. Atributo Dato identificado por un
nombre.
3.2. La Orientación a Objetos
11
3. La Orientación a Objetos, OO
Los objetos exhiben su comportamiento a través de
métodos. Método Trozos de funcionalidad
asociados al objeto.
Objeto ? Conjunto de Atributos y Métodos
3.3. La Orientación a Objetos
12
3. La Orientación a Objetos, OO
Los objetos revelan su utilidad en un contexto de
comunicación con otros objetos, por medio del
paso de mensajes, para componer un sistema con
un comportamiento más complejo que el suyo
propio.
3.4. La Orientación a Objetos
13
3. La Orientación a Objetos, OO
El envío de mensajes es la forma en que se invoca
los comportamientos de un objeto (cada método
define un comportamiento).
La invocación de métodos permite a un objeto
cambiar su estado o el de otro objeto.
Los detalles internos del objeto quedan ocultos
para los Demás objetos ? Encapsulación.
3.5. La Orientación a Objetos
14
3. La Orientación a Objetos, OO
Clase Son patrones que definen qué atributos y
qué métodos son comunes a un conjunto de objetos,
que pertenecen a dicha clase. Es más fácil de
entenderlo si se toma tipo como equivalente.
Todos los objetos del mismo tipo comparten el
mismo juego de atributos y métodos y, por tanto,
pertenecen a la misma clase.
3.6. La Orientación a Objetos
15
3. La Orientación a Objetos, OO
Cada objeto tiene sus atributos y sus métodos,
empleando una clase como patrón. 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.
3.7. La Orientación a Objetos
16
3. La Orientación a Objetos, OO
Hay atributos que no varían de una instancia a
otra. Todas las instancias de la clase tienen el
mismo valor. Estos atributos que no varían de
instancia a instancia se conocen como variables
de clase.
De manera análoga hay métodos de instancia y
métodos de clase.
3.8. La Orientación a Objetos
17
3. La Orientación a Objetos, OO
Herencia Los objetos se definen a partir de
clases. Se puede saber mucho de un objeto
sabiendo a qué clase pertenece. Las clases
permiten su definición a partir de otras clases.
Esto permite definir una jerarquía de
especialización. Una Clase definida a partir de
otra, hereda todos los atributos y métodos de su
clase ancestro. Las clases herederas pueden
sobrescribir los atributos y los métodos
heredados y pueden añadir nuevos.
3.9. La Orientación a Objetos
18
3. La Orientación a Objetos, OO
La clase tomada como patrón se conoce como
Superclase o clase padre, mientras que la
heredera se llama clase hija.
La jerarquía de herencia puede ser todo lo
profunda que sea necesario. Una clase puede tener
varias clases como patrón.
3.10. La Orientación a Objetos
19
3. La Orientación a Objetos, OO
Interfaces Mecanismo que emplean dos objetos
para interactuar. Definen un conjunto de métodos
para establecer el protocolo en base al que
interactúan dos objetos.
Interfaces ?? Protocolos
Las interfaces capturan similitudes entre clases
no relacionadas. Son clases a su vez.
3.11. La Orientación a Objetos
20
4. El Lenguaje Unificado de Modelado
4.1. El UML
21
4. El Lenguaje Unificado de Modelado
UML es un lenguaje para modelar. Su vocabulario y
sintaxis están ideados para la representación
conceptual y física de un sistema.
Sus modelos son precisos, no ambiguos y se pueden
trasladar a una gran variedad de lenguajes de
programación, como Java, C, visual basic, pero
también a tablas de bases de datos relacionales
y orientadas a objetos.
4.2. El UML
22
4. El Lenguaje Unificado de Modelado
Ingeniería directa Es posible generar código a
partir de un modelo UML.
Ingeniería inversa Es posible generar un modelo
UML a partir de la implementación.
En ambos casos se requiere mayor o menor
supervisión, en función de lo buenas que sean
las herramientas usadas.
4.3. El UML
23
4. El Lenguaje Unificado de Modelado
UML tiene tres bloques básicos de construcción,
elementos, relaciones y diagramas.

• Elementos Unidades básicas de construcción,
  cuatro tipos
• Estructurales Partes estáticas de los modelos,
• representan aspectos conceptuales o materiales.
• De comportamiento Partes dinámicas de los
  modelos,
• representan comportamientos en el tiempo y
  espacio.
• De agrupación Partes organizativas de los
  modelos.
• De Notación Partes explicativas de los modelos.

4.4. El UML
24
4. El Lenguaje Unificado de Modelado
Elementos estructurales
Describe un conjunto de objetos que comparten los
mismos atributos, métodos, relaciones y
semántica. Las clases implementan una o más
interfaces.
Clase
Se trata de una clase, en la que existe procesos
o hilos de ejecución concurrentes con otros
elementos. Las líneas del contorno son más
gruesas que en la clase normal.
Clase activa
4.5. El UML
25
4. El Lenguaje Unificado de Modelado
Elementos estructurales
Agrupación de métodos u operaciones que
especifican un servicio de una clase o
componente, describiendo su comportamiento,
completo o parcial, externamente visible. UML
permite emplear un círculo para representar las
interfaces, aunque lo más normal es emplear la
clase con el nombre en cursiva.
Define una interacción entre elementos que
cooperan para proporcionar un comportamiento
mayor que la suma de los comportamientos de sus
elementos.
4.6. El UML
26
4. El Lenguaje Unificado de Modelado
Elementos estructurales
Describe un conjunto de secuencias de acciones
que un sistema ejecuta, para producir un
resultado observable de interés. Se emplea para
estructurar los aspectos de comportamiento de un
modelo.
Parte física y por tanto reemplazable de un
modelo, que agrupa un conjunto de interfaces,
archivos de código fuente, clases,
colaboraciones y proporciona la implementación de
dichos elementos.
Elemento físico que existe en tiempo de ejecución
y representa un recurso computacional con
capacidad de procesar.
4.7. El UML
27
4. El Lenguaje Unificado de Modelado
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 interacción, en respuesta a
eventos.
4.8. El UML
28
4. El Lenguaje Unificado de Modelado
Elementos de agrupación
Se emplea para organizar otros elementos en
grupos.
Elementos de notación
Partes explicativa de UML, que puede describir
textualmente cualquier aspecto del modelo.
4.9. El UML
29
4. El Lenguaje Unificado de Modelado
Relaciones Abstracciones que actúan de unión
entre los elementos.
Es una relación entre dos elementos, tal que un
cambio en uno puede afectar al otro.
Dependencia
Es una relación estructural que resume un
conjunto de enlaces que son conexiones entre
objetos.
Asociación
Es una relación en la que el elemento
generalizado puede ser substituido por
cualquiera de los elementos hijos, ya que
comparten su estructura y comportamiento.
Generalización
Es una relación que implica que la parte
realizante cumple con una serie de
especificaciones propuestas por la clase
realizada (interfaces).
Realización
4.10. El UML
30
4. El Lenguaje Unificado de Modelado
Diagramas Disponen un conjunto de elementos, que
representan el modelo desde distintas
perspectivas. UMLtiene nueve diagramas
fundamentales, clasificados en dos grupos, uno
para modelar la estructura estática del sistema y
otro para modelar el comportamiento dinámico.
Diagramas estáticos Clases, Objetos, componentes
y despliegue.
Diagramas dinámicos Casos de Uso, secuencia,
colaboración, estados y actividades.
4.11. El UML
31
4. El Lenguaje Unificado de Modelado
Diagrama de Clases
Muestran un resumen del sistema en términos de
sus clases y las relaciones entre ellas.
Las clases abstractas tienen su nombre en
itálica.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
32
4. El Lenguaje Unificado de Modelado
   
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.
4.13. El UML
33
4. El Lenguaje Unificado de Modelado
   
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 ? métodos
Acceso de atributos y métodos ? público
- ? privado (sólo los métodos), ?
protegido (sólo clases hija).
Argumentos nombretipo val (,
nombretipoval)
Los atributos y métodos estáticos (de clase) se
representan mediante un subrayado. Los métodos
pueden emplear el estereotipo ltltstaticgtgt.
4.14. El UML
34
4. El Lenguaje Unificado de Modelado
   
Diagrama de Clases
Relación de auto agregación. Un departamento
puede estar compuesto por varios sub
departamentos, o ninguno, con la restricción de
que el mínimo número de personas en los sub
departamentos debe ser dos. En UML las
restricciones se expresan mediante llaves
condicion a cumplir siempre.
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
4.15. El UML
35
4. El Lenguaje Unificado de Modelado
   
Diagrama de Componentes
Un componente es un módulo de código, de modo que
los diagramas de componentes son los análogos
físicos a los diagramas de clases. Muestran la
organización y dependencias de un conjunto de
componentes. Cubren la vista de implementación
estática de un sistema.
4.16. El UML
36
4. El Lenguaje Unificado de Modelado
   
Diagrama de Despliegue
Los diagramas de despliegue sirven para modelar
la configuración hardware del sistema, mostrando
qué nodos lo componen
4.17. El UML
37
4. El Lenguaje Unificado de Modelado
   
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 cómo.
Plantean escenarios, lo que pasa cuando alguien
interactúa con el sistema. Proporcionan un
resumen para una objetivo.
Los Actores son papeles que determinadas personas
u objetos desempeñan.
Las líneas que unen los Actores con los Casos de
Uso (óvalos) representan una asociación de
comunicación.
4.18. El UML
38
4. El Lenguaje Unificado de Modelado
   
Diagrama de Casos de Uso
Los Casos de Uso pueden explosionarse para
describir en mayor profundidad.
Carlos tuesta el pan en la tostadora, después
lo unta con mantequilla y mermelada de fresa y
se lo come, posiblemente mojándolo en un café.
Carlos calienta leche, añade café y azúcar al
gusto y se lo bebe.
Los Casos de Uso pueden acompañarse de texto que
enriquezca el lenguaje gráfico.
4.19. El UML
39
4. El Lenguaje Unificado de Modelado
   
Diagrama de Casos de Uso
frontera
estereotipo
generalización
Paralelo, orden irrelevante
4.20. El UML
40
4. El Lenguaje Unificado de Modelado
   
Diagrama de Secuencia
Describen cómo los objetos del sistema colaboran.
Detalla cómo las operaciones se llevan a cabo en
términos de qué mensajes son enviados y cuando
(en torno al tiempo).
tiempo
Los corchetes expresan condición condición. Si
son precedidos por ? iteración mientras.
Línea de vida obj.
Su vida termina.
Orden participación
4.21. El UML
41
4. El Lenguaje Unificado de Modelado
   
Diagrama de Secuencia
Los rectángulos verticales son barras de
activación. Representan la duración de la
ejecución del mensaje.
Mensaje asíncronos El emisor puede enviar otros
mientras éste está siendo procesado. Es
independiente a otros mensajes.
Mensaje síncronos El emisor debe esperar que
termine el tiempo de proceso de éste para enviar
nuevos mensajes.
Mensaje simple puede ser síncrono o asíncrono
Mensaje simple de vuelta (opt)
Síncrono
Asíncrono
4.22. El UML
42
4. El Lenguaje Unificado de Modelado
   
Diagrama de Colaboración
Son otro tipo de diagramas de interacción.
Contienen la misma información que los diagramas
de secuencia, pero se centran en la
responsabilidad de cada objeto en lugar de en el
tiempo en que los mensajes son enviados
Cada mensaje tiene un número de secuencia. El
primer nivel comienza en 1, los mensajes que son
enviados durante la misma llamada a un método se
numeran 1.1, 1.2 ... 1.i, tantos niveles como
sea necesario.
4.23. El UML
43
4. El Lenguaje Unificado de Modelado
   
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.
Resultado de actividad
Circunstancia o condición que provoca la
transición
inicio
acción
fin
4.24. El UML
44
4. El Lenguaje Unificado de Modelado
   
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.
4.25. El UML
45
4. El Lenguaje Unificado de Modelado
   
Diagrama de Actividades
Son diagramas de flujo adornados, con mucha
similitud a los diagramas de estados.
Mientras los diagramas de estados centran su
atención en el proceso que lleva a cabo un
objeto, los diagramas de actividades muestran
como las actividades fluyen y las dependencias
entre ellas.
4.26. El UML
46
5. Cómo 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 típicamente como parte de un proceso
de desarrollo, con ayuda de una herramienta CASE.
UML es independiente de cualquier proceso
particular, no Está ligado a ningún ciclo de vida
de desarrollo de software concreto.
5.1. Cómo Utilizar UML
47
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.
Dirigido por Casos de Uso Los Casos de Uso son
básicos Para establecer el comportamiento deseado
del sistema, para verificarlo, para validar su
arquitectura y para comunicarse Con todas las
personas involucradas en el proyecto.
5.2. Cómo Utilizar UML
48
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.
5.3. Cómo Utilizar UML
49
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.
5.4. Cómo Utilizar UML
50
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.
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
5.5. Cómo Utilizar UML
51
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.
5.6. Cómo Utilizar UML
52
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.
5.7. Cómo Utilizar UML
53
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.
5.8. Cómo Utilizar UML
54
5. Cómo utilizar UML
   
Ejemplo para la construcción de un programa
Un ejemplo de proceso para la construcción de un
programa, podría ser similar al siguiente,
teniendo en cuenta que el proceso descrito deja
muchas cosas por ampliar. Se proporciona
meramente como un ejemplo de cómo se puede
encajar UML como soporte para el desarrollo de un
proyecto.

1. Iniciar y mantener reuniones con los usuarios
   finales del programa, para comprender sus
   necesidades, el contexto en que lo usarán y todos
   los detalles necesarios para comprender el ámbito
   del problema a resolver. Esta información será
   empleada para capturar las actividades y procesos
   involucrados y susceptibles de ser incorporados
   en el programa, a un nivel alto, y proporcionará
   la base para construir la vista de Casos de Uso.

5.9. Cómo Utilizar UML
55
5. Cómo utilizar UML
   
Ejemplo para la construcción de un programa

1. Construir la vista de Casos de Uso definiendo
   exactamente la funcionalidad que se va a
   incorporar en el programa, desde el punto de
   vista de sus usuarios. El modelo resultante es
   realmente un mapeo de la información obtenida en
   el paso anterior, en el que cada nuevo Caso de
   Uso realiza un aspecto de la funcionalidad
   planteada. Refinar, en conjunto con los usuarios
   finales, todos los diagramas de Casos de Uso,
   incluyendo requisitos y restricciones, para
   llegar a un acuerdo común en lo que el programa
   hará y no hará. En este punto puede ser
   conveniente diseñar escenarios de prueba que
   ayuden a verificar si el programa finalizado
   cumple con las expectativas del contrato.

5.10. Cómo Utilizar UML
56
5. Cómo utilizar UML
   
Ejemplo para la construcción de un programa

1. Partiendo del modelo de Casos de Uso se comienza
   a estructurar los requisitos en una arquitectura
   llamada línea base. Se definen clases y
   relaciones entre ellas, los primeros diagramas de
   secuencia y colaboración, definiendo los
   comportamientos de cada clase, también las
   interfaces entre los diferentes elementos de la
   arquitectura. Se construye aquí la vista de
   diseño y la vista de procesos. Construir
   diagramas de clases más elaborados y refinar los
   comportamientos del sistema.

1. A medida que crece el modelo se puede fraccionar
   en componentes software y paquetes. Aparecen
   nuevos requisitos que deben ser integrados. Se
   define la vista de despliegue, que define la
   arquitectura física del sistema, y la vista de
   implementación.

5.11. Cómo Utilizar UML
57
5. Cómo utilizar UML
   
Ejemplo para la construcción de un programa

1. Construir el sistema, repartiendo las tareas
   entre el equipo de programación.

1. Buscar errores de programación, o incluso de
   diseño, corregirlos e ir sacando sucesivas
   versiones del programa hasta llegar a una versión
   que cumpla con todos los requisitos especificados
   en el contrato con los usuarios.

1. Documentar y entregar el programa a los usuarios
   finales.

5.12. Cómo Utilizar UML
58
6. Bibliografía
   
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. Bibliografía PARTE I
59
Parte IIIntroducción al Proceso Unificado
Òscar Coltell
60
PARTE II. CONTENIDO

1. Objetivos.
2. Conceptos fundamentales.
3. El Proceso Unificado.
4. Fases del ciclo.
5. Flujos de trabajo.
6. Tipos de resultados.
7. Captura y Modelado de Requisitos.
8. Modelado de Análisis.
9. Modelado de Diseño.
10. Modelado de Implementación.
11. Resumen.
12. Bibliografía

61
7. OBJETIVOS

• Introducir los aspectos generales del Proceso
  Unificado de Rational (RUP), también 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
62
8. Conceptos fundamentales

• Proceso
• Es un marco de trabajo común compuesto por
  actividades de trabajo (conjuntos de tareas,
  hitos, productos y puntos de garantía de calidad)
  y actividades de protección (garantía de calidad,
  gestión de configuración y medición) (Pressman
  2001).
• Producto
• Es el resultado previsto y consistente del
  proceso.

8.1. Conceptos fundamentales
63
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.

8.2. Conceptos fundamentales
64
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).

8.3. Conceptos fundamentales
65
8. Conceptos fundamentales

• Ciclo de vida del software completo

8.4. Conceptos fundamentales
66
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.

8.5. Conceptos fundamentales
67
8. Conceptos fundamentales

• Estructura formal de la Ingeniería del Software

RUP
8.6. Conceptos fundamentales
68
9. El Proceso Unificado

• 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.

9.1. El Proceso Unificado
69
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.

9.2. El Proceso Unificado
70
9. El Proceso Unificado

• 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 guía el desarrollo
  del sistema
• Se facilita el desarrollo en paralelo.
• Se minimiza la repetición de trabajos.
• Se incrementa la probabilidad de reutilización de
  componentes y el mantenimiento posterior del
  sistema.
• Este diseño arquitectónico sirve como una sólida
  base sobre la cual se puede planificar y manejar
  el desarrollo de software basado en componentes.

9.3. El Proceso Unificado
71
9. El Proceso Unificado

• C. Aspectos del RUP
• Las actividades de desarrollo bajo el Proceso
  Unificado están dirigidas por los casos de uso.
• El Proceso Unificado pone un gran énfasis en la
  construcción de sistemas basada en una amplia
  comprensión de cómo se utilizará el sistema que
  se entregue.
• Las nociones de los casos de uso y los escenarios
  se utilizan para guiar el flujo de procesos desde
  la captura de los requisitos hasta las pruebas, y
  para proporcionar caminos que se pueden
  reproducir durante el desarrollo del sistema.

9.4. El Proceso Unificado
72
9. El Proceso Unificado

• 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 pequeños equipos de
  desarrollo de software hasta grandes empresas de
  desarrollo.
• También se basa en una arquitectura de proceso
  simple y clara, que proporciona un marco común a
  toda una familia de procesos y que, además, puede
  variarse para acomodarse a distintas situaciones.

9.5. El Proceso Unificado
73
9. El Proceso Unificado

• E. Aspectos del RUP
• El Proceso Unificado soporta las técnicas
  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 notación
  común.

9.6. El Proceso Unificado
74
9. El Proceso Unificado

• F. Aspectos del RUP
• El Proceso Unificado es impulsa un control de
  calidad y una gestión del riesgo objetivos y
  continuos.
• La evaluación de la calidad va contenida en el
  proceso, en todas las actividades, e implicando a
  todos los participantes, mediante medidas y
  criterios objetivos. No se trata como algo a
  posteriori o una actividad separada.
• La gestión del riesgo va contenida en el proceso,
  de manera que los riesgos para el éxito del
  proyecto se identifican y se acometen al
  principio del proceso de desarrollo, cuando
  todavía hay tiempo de reaccionar.

9.7. El Proceso Unificado
75
9. El Proceso Unificado

• El Proceso Unificado tiene una estructura
  matricial donde se relacionan esfuerzos y
  tiempos
• Los tiempos están definidos por las fases y las
  iteraciones.
• Los esfuerzos están definidos por los flujos de
  trabajo del proceso y de soporte.
• La representación gráfica se denomina en la jerga
  el Diagrama de Montañas.

9.8. El Proceso Unificado
76
El ciclo de vida del desarrollo del software
Fuente Jacobson et al., 2000
9.9. El Proceso Unificado
77
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.

9.10. El Proceso Unificado
78
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

9.11. El Proceso Unificado
79
Z Modelos
resultados
(x,z) versiones
X,Y,Z Configuracionesdel sistema
(y,z) tipos de modelos
tiempo
X Fases
Y Flujosde trabajo
esfuerzo
(x,y) iteraciones
9.12. El Proceso Unificado
80
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.

10.1. Fases del ciclo
81
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.

10.2. Fases del ciclo
82
Las iteraciones son distintas en el ciclo de vida
10.3. Fases del ciclo
83
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.

10.4. Fases del ciclo
84
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
  técnicas.
• Flujos de trabajo de soporte
• Conjunto de actividades fundamentalmente de
  gestión.

11.1. Flujos de trabajo
85
11. Flujos de trabajo
Flujos de trabajo del proceso

1. Modelado del negocio describe la estructura y la
   dinámica de la organización.
2. Requisitos describe el método basado en casos de
   uso para extraer los requisitos.
3. Análisis y diseño describe las diferentes vistas
   arquitectónicas.
4. Implementación tiene en cuenta el desarrollo de
   software, la prueba de unidades y la integración.
5. Pruebas describe los casos de pruebas, los
   procedimientos y las métricas para evaluación de
   defectos.
6. Despliegue cubre la configuración del sistema
   entregable.

11.2. Flujos de trabajo
86
11. Flujos de trabajo
Flujos de trabajo de soporte

1. Gestión de configuraciones controla los cambios
   y mantiene la integridad de los artefactos de un
   proyecto.
2. Gestión del Proyecto describe varias estrategias
   de trabajo en un proceso iterativo.
3. Entorno cubre la infraestructura necesaria para
   desarrollar un sistema.

11.3. Flujos de trabajo
87
El ciclo de vida del desarrollo del
software Flujos
11.4. Flujos de trabajo
88
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

12.1. Tipos de resultados
89
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.

12.2. Tipos de resultados
90
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.

12.3. Tipos de resultados
91
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.

12.4. Tipos de resultados
92
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.

12.5. Tipos de resultados
93
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.

12.6. Tipos de resultados
94
Relaciones lógicas entre los modelos
Modelo deCasos de Uso
verificado por
especificado por
Modelo dePrueba
realizado por
distribuido por
Modelo deAnálisis
Modelo deDiseño
implementado por
Modelo deDespliegue
Modelo deImplementación
12.7. Tipos de resultados
95
Modelos y flujos de trabajodel Proceso Unificado
12.8. Tipos de resultados
96
MODELOS Y DIAGRAMAS EN EL RUP
12.9. Tipos de resultados
97
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.

12.10. Tipos de resultados
98
Vistas de la arquitectura de un sistema
12.11. Tipos de resultados
99
6. Tipos de resultados

• Cada una de las vistas presenta
• Aspectos estáticos mediante los diagramas
  estructurales de UML.
• Aspectos dinámicos mediante diagramas dinámicos
  de UML.
• Ejemplo se puede trabajar con la vista de casos
  de uso estática y la vista de casos de uso
  dinámica, la vista de diseño estática y la vista
  de diseño dinámica, y así sucesivamente.
• En el RUP se da más importancia a los modelos que
  a las vistas. Aunque se siguen manteniendo para
  determinados propósitos de modelado.

12.12. Tipos de resultados
100
6. Tipos de resultados
12.13. Tipos de resultados
101
VISTAS Y DIAGRAMAS EN UML
12.14. Tipos de resultados
102
6. Tipos de resultados

• Los artefactos conjunto del RUP son los
  siguientes
• Conjunto de requisitos.
• Conjunto de diseño.
• Conjunto de implementación.
• Conjunto de despliegue.

12.15. Tipos de resultados
103
6. Tipos de resultados

• Conjunto de requisitos
• Agrupa toda la información que describe lo que
  debe hacer el sistema.
• Puede comprender un modelo de casos de uso, un
  modelo de requisitos no funcionales, un modelo
  del dominio, un modelo de análisis y otras formas
  de expresión de las necesidades del usuario,
  incluyendo pero no limitándose a maquetas,
  prototipos de la interfaz, restricciones legales,
  etc.

12.16. Tipos de resultados
104
6. Tipos de resultados

• Conjunto de diseño
• Agrupa información que describe cómo se va a
  construir el sistema y captura las decisiones
  acerca de cómo se va realizar, teniendo en cuenta
  las restricciones de tiempo, presupuesto,
  aplicaciones existentes, reutilización, objetivos
  de calidad y demás consideraciones.
• Puede implicar un modelo de diseño, un modelo de
  pruebas y otras formas de expresión de la
  naturaleza del sistema, incluyendo, pero no
  limitándose, a prototipos y arquitecturas
  ejecutables.

12.17. Tipos de resultados
105
6. Tipos de resultados

• Conjunto de implementación
• Agrupa toda la información acerca de los
  elementos software que comprende el sistema,
  incluyendo, pero no limitándose, a código fuente
  en varios lenguajes de programación, archivos de
  configuración, archivos de datos, componentes
  software, etc., junto con la información que
  describe cómo ensamblar el sistema.

12.18. Tipos de resultados
106
6. Tipos de resultados

• 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.

12.19. Tipos de resultados
107
13. Captura y Modeladode 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
• Descripción concreta del negocio.
• Dominio de los Objetos de Negocio (DON).
• Las soluciones pertenecen al Espacio de la
  Solución
• Descripción concreta del sistema de información.
• Dominio de los Objetos de Negocio.
• Dominio de los Objetos de Infraestructura (DOI)
• Subdominio de Objetos de Bases de Datos (SDOBD).
• Subdominio de Objetos de Interfaz (SDOIZ).

13.1. Captura y Modelado de Requisitos
108
13. Captura y Modeladode Requisitos
Diseño
13.2. Captura y Modelado de Requisitos
109
13. Captura y Modeladode Requisitos

• El Análisis de Requisitos en el RUP se realiza
  por medio de los flujos de trabajo
• Modelado del negocio.
• Requisitos.
• El resultado del Análisis de Requisitos es el
  siguiente
• Modelo del Negocio.
• Modelo del Dominio.
• Modelo de Casos de Uso.
• Documento de Especificaciones Técnicas del
  Sistema (según norma IEEE-830/1999).

13.3. Captura y Modelado de Requisitos
110
13. Captura y Modeladode Requisitos
Requisitos
13.4. Captura y Modelado de Requisitos
111
13. Captura y Modeladode 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/pro
  cesos 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.

13.5. Captura y Modelado de Requisitos
112
13. Captura y Modeladode Requisitos
Diagrama de Contextodel SMCU de Negocio
SubModelo de Casosde Uso de Negocio
SubModelo de Casosde Uso (Técnico)
Diagrama de Contextodel SMCU Técnico
Diagrama Principaldel Modelo de Casosde Uso
13.6. Captura y Modelado de Requisitos
113
13. Captura y Modeladode Requisitos
Diagrama de Contextodel MCU
13.7. Captura y Modelado de Requisitos
114
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.

14.1. Modelado de Análisis
115
14. Modelado de Análisis
Modelo deCasos de Uso
verificado por
especificado por
Modelo dePrueba
realizado por
distribuido por
Modelo deAnálisis
Modelo deDiseño
implementado por
Modelo deDespliegue
Transición del MCU hacia el MA
Modelo deImplementación
14.2. Modelado de Análisis
116
14. Modelado de Análisis

• El Análisis en el RUP se realiza por medio de los
  flujos de trabajo
• Análisis y diseño.
• El resultado del Análisis es el siguiente
• Modelo de Análisis.
• El Modelo de Análisis contiene
• La Vista de Diseño de UML.
• La Vista de Procesos de UML.

14.3. Modelado de Análisis
117
14. Modelado de Análisis
Análisis
14.4. Modelado de Análisis
118
Proceso de Conversión Casos de Uso ? Análisis
14.5. Modelado de Análisis
119
Proceso de Conversión Casos de Uso ? Análisis
Diagrama deClases de AnálisisAtómico
14.6. Modelado de Análisis
120
Modelo de Casos de Uso
Modelo de Análisis
Servicio(CU)-Subsistema(DA)
MCU Nivel 0
MA Nivel 0
Bottom-Up
Top-Down
MA Nivel 1
MCU Nivel 1
MA Nivel 2
MCU Nivel 2
MCU Nivel i
MA Nivel j
14.7. Modelado de Análisis
121

• La estructura del modelo en Rose

D. Clases Análisis Atómicopara el Caso de
UsoF01.01 ltNombre funcióngt
Carpeta de trabajoen la conversión
Diagrama de Colaboraciónpara DCAA F01.01
Diagrama de Clasesde Análisis de Contexto
14.8. Modelado de Análisis
122
15. Modelado de Diseño

• En el flujo de requisitos se construye un modelo
  que representa el comportamiento observable o
  externo del sistema que se quiere obtener.
• En los flujos de análisis, diseño e
  implementación, se representa la estructura y el
  comportamiento internos del sistema a realizar.
• Característica común de los tres flujos frente al
  flujo de requisitos
• En los tres flujos se trabaja a diferentes
  niveles de abstracción, desde el más elevado en
  el análisis, hasta el más bajo en la
  implementación.

15.1. Modelado de Diseño
123
15. Modelado de Diseño
Flujo de Análisis de Requisitos
Modelo deCasos de Uso
verificado por
especificado por
Modelo dePrueba
distribuido por
Modelo deAnálisis
realizado por
Modelo deDiseño
implementado por
Flujo de Análisis y Diseño
Modelo deDespliegue
Modelo deImplementación
Transición del MCA hacia el MD
15.2. Modelado de Diseño
124
15. Modelado de Diseño

• La técnica de modelado consiste en identificar, a
  través de las especificaciones de las clases de
  análisis las clases de diseño correspondientes.
• Para cada clase de análisis se puede derivar una
  o más clases de diseño
• Clase de control ? clase activa (gt 1)
• Clase de entidad ? clase de entidad (gt 1)
• Clase de interfaz ? clase de interfaz (gt 1)

15.3. Modelado de Diseño
125
15.4. Modelado de Diseño
126
15. Modelado de Diseño

• En el proceso de conversión del Modelo de
  Análisis (MA) al Modelo de Diseño (MD), la
  estrategia adoptada es mixta
• Top-Down
• Level-to-Level

15.6. Modelado de Diseño
127
Modelo de Diseño
Modelo de Análisis
Subsistema(DA)-Subsistema(DD)
MA Nivel 0
Bottom-Up
MD Nivel 0
MA Nivel 1
MD Nivel 1
Top-Down
MA Nivel 2
MD Nivel 2
MA Nivel j
MD Nivel i
Modelo deCasos de Uso
15.7. Modelado de Diseño
128
Modelo de Diseño
Modelo de Análisis
Top-Down
Subsistema(DA)-Subsistema(DD)
Bottom-Up
MA Nivel 0
MD Nivel 0
MA Nivel 1
MD Nivel 1
MA Nivel 2
MD Nivel 2
MA Nivel j
MD Nivel i
Level-to-Level
Modelo deCasos de Uso
15.8. Modelado de Diseño
129
15.9. Modelado de Diseño
130

• La estructura del modelo en Rose

Diagrama de Clasesde Diseño de Contexto
15.10. Modelado de Diseño
131
16. Modelado de Implementación

• El modelado de implementación se realiza para
  obtener
• La implementación del sistema en términos de
  lenguajes y elementos de programación.
• La distribución de los módulo software en los
  elementos hardware del sistema.
• En el flujo de implementación se construye un
  modelo que representa la estructura y el
  comportamiento internos del sistema en cuanto a
• Componentes y módulos.
• Arquitectura software del sistema.
• En el flujo de 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 Implementación
132
16. Modelado de Implementación
Flujo de Análisis de Requisitos
Modelo deCasos de Uso
verificado por
especificado por
Modelo dePrueba
distribuido por
Modelo deAnálisis
realizado por
Modelo deDiseño
implementado por
Flujo de Implementación
Flujo de Análisis y Diseño
Modelo deDespliegue
Flujo de Despliegue
Modelo deImplementación
Transición del MD hacia el MDP
16.2. Modelado de Implementación
133
16. Modelado de Implementación
Modelo de Implementación
(Vista parcial)
componentes
16.3. Modelado de Implementación
134
16. Modelado de Implementación
Modelo de Despliegue
(Vista parcial)
nodos / procesadores
16.4. Modelado de Implementación
135
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.

17.1. Resumen
136
17. Resumen

• La aplicación formal del Proceso Unificado
  supone
• Desventajas
• Grandes esfuerzos en la construcción de modelos.
• Necesidad del soporte de herramientas
  informáticas.