Modelado UML

Modelado del
Sistema
Juan Alvites Huamani
Tutorial UML y PU: 1/138

El Software
• La descripción de software en un libro de texto

podría tomar la siguiente forma: el software es (1)
instrucciones que cuando se ejecutan
proporcionan la función y el rendimiento deseados,
(2) estructuras de datos que permiten a los
programas manipular adecuadamente la
información, y (3) documentos que describen la
operación y el uso de programas.

Características del Software
• El software se desarrolla, no se fabrica en un sentido clásico.
• Aunque existen similitudes entre el desarrollo del software y la

construcción del hardware, ambas actividades son fundamentalmente
diferentes. En ambas actividades la buena calidad se adquiere mediante
un buen diseño, pero la fase de construcción del hardware puede
introducir problemas de calidad que no existen (o son fácilmente
corregibles) en el software. Ambas actividades dependen de las
personas, pero la relación entre las personas dedicadas y el trabajo
realizado es completamente diferente para el software. Ambas
actividades requieren de la construcción de un producto, pero los
métodos son diferentes.
• Los costes del software se encuentran en la ingeniería. Esto significa
que los proyectos de software no se pueden gestionar como si fueran
proyectos de fabricación

• El software no se estropea. El software no es susceptible a los males del entorno que
hacen que el hardware se estropee.
• Otro aspecto de ese deterioro ilustra la diferencia entre el hardware y el software.
Cuando un componente se estropea, se sustituye por una pieza de repuesto. No
hay pieza de repuesto para el software. Cada fallo en el software indica un error
en el diseño o en el proceso
• mediante el que se tradujo el diseño a código maquina ejecutable. Por tanto, el
mantenimiento del software tiene una complejidad considerablemente mayor que la
del mantenimiento del hardware.

• La mayoría del software se construye a medida, en vez de
ensamblar componentes existentes. No existen catálogos de
componentes de software. Se puede comprar software ya desarrollado,
pero solo como una unidad completa, no como componentes
que pueden re ensamblarse en nuevos programas.

UML y Proceso
Unificado

CONTENIDO
GENERAL
Parte I: Introducción a UML.

Parte II: Introducción al Proceso Unificado.

Parte I:
Introducción a UML

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.

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 cómo emplear UML en un proyecto
1.1. Objetivos Tutorial UML y PU: 11/138

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 Tutorial UML y PU: 12/138

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

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 Tutorial UML y PU: 15/138

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

4. El Lenguaje Unificado de Modelado
4.1. El UML Tutorial UML y PU: 26/138

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.

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.

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.

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

Agrupación de métodos u operaciones que especifican

un servicio de una clase o componente, describiendo su
comportamiento, completo o parcial, externamente visible.
UML permite emplear un círculo para representar las
interfaces, aunque lo más normal es emplear la clase con
el nombre en cursiva.
Define una interacción entre elementos que cooperan

para proporcionar un comportamiento mayor que la
suma de los comportamientos de sus elementos.

Describe un conjunto de secuencias de acciones que un

sistema ejecuta, para producir un resultado observable
de interés. Se emplea para estructurar los aspectos de
comportamiento de un modelo.
Parte física y por tanto reemplazable de un modelo, que

agrupa un conjunto de interfaces, archivos de código fuente,
clases, colaboraciones y proporciona la implementación de
dichos elementos.
Elemento físico que existe en tiempo de ejecución y

representa un recurso computacional con capacidad de
procesar.

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.

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.

Relaciones: Abstracciones que actúan de unión entre los
elementos.
Es una relación entre dos elementos, tal que un cambio en uno
Dependencia puede afectar al otro.
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

Generalización substituido por cualquiera de los elementos hijos, ya que
comparten su estructura y comportamiento.
Es una relación que implica que la parte realizante cumple con

una serie de especificaciones propuestas por la clase realizada
Realización
(interfaces).

Diagramas: Disponen un conjunto de elementos, que
representan el modelo desde distintas perspectivas.
UMLtiene nueve diagramas fundamentales, clasificados
en dos grupos, uno para modelar la estructura estática del
sistema y otro para modelar el comportamiento dinámico.
Diagramas estáticos: Clases, Objetos, componentes y

despliegue.
Diagramas dinámicos: Casos de Uso, secuencia,

colaboración, estados y actividades.

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.

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).
Argumentos: nombre:tipo [=val] (, nombre:tipo[=val])*
Los atributos y métodos estáticos (de clase) se representan mediante un subrayado.

Los métodos pueden emplear el estereotipo <<static>>.

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

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.

Diagrama de Despliegue:
Los diagramas de despliegue sirven para modelar la configuración hardware del sistema,
mostrando qué nodos lo componen

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.

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.

frontera
estereotipo
generalización
Paralelo, orden irrelevante

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).
Los corchetes expresan condición [condición].

Si son precedidos por “*”  iteración mientras.

Diagrama de Secuencia:
Los rectángulos verticales son barras de activación. Representan la duración de la
ejecución del mensaje.
Mensaje asíncronos: El emisor puede enviar otros mientras éste está siendo procesado.
Es independiente a otros mensajes.
Mensaje síncronos: El emisor debe esperar que termine el tiempo de proceso de éste
para enviar nuevos mensajes.
Mensaje simple Mensaje simple Síncrono

puede ser síncrono de vuelta (opt) Asíncrono
o asíncrono

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.

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

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 Tutorial UML y PU: 52/138

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.

Centrado en la arquitectura: La arquitectura de un sistema es
el conjunto de decisiones significativas que se toma en torno
a su organización, la selección de elementos estructurales, la
definición de las interfaces entre estos elementos, su
comportamiento, su división en subsistemas, qué elementos
son estáticos y cuales dinámicos. La arquitectura también
incluye el uso que se le va a dar al sistema, la funcionalidad,
el rendimiento, la capacidad de adaptación, la reutilización, la
capacidad de ser comprendido, las restricciones económicas,
las temporales, los compromisos entre alternativas y los
aspectos estéticos.

Proceso incremental: aquél que consiste en sucesivas
ampliaciones y mejoras de la arquitectura, a partir de una
línea básica. Cada incremento resuelve los problemas
encontrados en la versión anterior minimizando
progresivamente los riesgos más significativos para el
éxito del proyecto.

Lo primero que se debe hacer para comenzar a desarrollar un proyecto con UML, es
seleccionar una metodología de desarrollo que defina la naturaleza concreta del proceso a
seguir.
El modelo a definir en base al

proceso elegido, se divide en
realidad en varios tipos de
modelo o vistas, cada una
centrada en un aspecto o punto
de vista del sistema. En general,
independientemente del proceso
que se emplee, se puede
encontrar las siguientes vistas

Vista de Casos de Uso: Engloba los Casos de Uso que describen el comportamiento del
sistema como lo verían los usuarios finales, los analistas y demás componentes del equipo
de desarrollo. No especifica la organización del sistema. Con UML los aspectos estáticos de
esta vista se pueden concretar con los diagramas de Casos de Uso; los aspectos dinámicos
con los diagramas de iteración (secuencia y colaboración), diagramas de estados y de
actividades.
Vista de Diseño: Engloba las clases e interfaces que conforman el vocabulario del problema
y su solución. Da soporte a los requisitos funcionales del sistema, es decir los servicios que
proporciona a los usuarios finales. Con UML los aspectos estáticos de esta vista se pueden
concretar con los diagramas de clases y de objetos; los aspectos dinámicos con los
diagramas de iteración (secuencia y colaboración), diagramas de estados y de actividades.

Vista de Procesos: Engloba los hilos y procesos que forman los mecanismos de
sincronización y concurrencia del sistema. Da soporte al funcionamiento, capacidad de
crecimiento y rendimiento del sistema. Con UML los aspectos estáticos de esta vista se
pueden concretar con los diagramas de clases, de clases activas y de objetos; los aspectos
dinámicos con los diagramas de iteración (secuencia y colaboración), diagramas de estados
y de actividades.
Vista de Despliegue: Engloba los nodos que forman la topología hardware sobre el que se
ejecuta el sistema. Da soporte a la distribución, entrega e instalación de las partes que
conforman el sistema físico. Con UML los aspectos estáticos de esta vista se pueden
concretar con los diagramas despliegue; los aspectos dinámicos con los diagramas de
iteración (secuencia y colaboración), diagramas de estados y de actividades.

Vista de Implementación: Engloba los componentes y archivos empleados para hacer
posible el sistema físico. Da soporte a la gestión de configuraciones de las distintas
versiones del sistema, a partir de componentes y archivos. Con UML los aspectos estáticos
de esta vista se pueden concretar con los diagramas de componentes; los aspectos dinámicos
con los diagramas de iteración (secuencia y colaboración), diagramas de estados y de
actividades.

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.

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

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

paquetes. Aparecen nuevos requisitos que deben ser integrados. Se define la vista
de despliegue, que define la arquitectura física del sistema, y la vista de
implementación.

5. Construir el sistema, repartiendo las tareas entre el equipo de programación.
6. Buscar errores de programación, o incluso de diseño, corregirlos e ir sacando

sucesivas versiones del programa hasta llegar a una versión que cumpla con
todos los requisitos especificados en el contrato con los usuarios.
7. Documentar y entregar el programa a los usuarios finales.

6. Bibliografía:
Grady Booch, James Rumbaugh, Ivar Jacobson, (1996)
El Lenguaje Unificado de Modelado¸Addison 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 Tutorial UML y PU: 64/138

Parte II:
Introducción al Proceso
Unificado

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 Análisis.
15. Modelado de Diseño.
16. Modelado de Implementación.
17. Resumen.
18. Bibliografía

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 Tutorial UML y PU: 67/138

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 Tutorial UML y PU: 68/138

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

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

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
Concepción Desarrollo Explotación
Tiempo

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

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

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 técnicas orientadas a objetos.
F. Impulsa un control de calidad y una gestión del
riesgo objetivos y continuos.
9.1. El Proceso Unificado Tutorial UML y PU: 74/138

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

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

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

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

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

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

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

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
Iteraciones Iter Iter Iter Iter Iter Iter Iter

preliminares #1 #2 #n #n+1 #n+2 #m #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 conjunción de tiempo (fases) y esfuerzos
(flujos de trabajo) da lugar a las iteraciones.
– La conjunción de resultados (modelos) y
esfuerzos (flujos de trabajo) da lugar a los tipos
de modelos.
– La conjunción de tiempo (fases) y resultados
(modelos) da lugar a las versiones.

• Se puede representar esta estructura
conceptual (metamodelo) mediante una
figura tridimensional donde:
– Eje X: Fases  tiempo
– Eje Y: Flujos de trabajo  esfuerzos
– Eje Z: Modelos  resultados

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

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 Tutorial UML y PU: 86/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.

Las iteraciones son distintas en el ciclo de vida
Flujos de trabajo
F1: Modelado del

negocio
F2: Requisitos
F3: Análisis y diseño

F4: Implementación
F5: Pruebas
F6: Despliegue
Flujos de trabajo
de soporte
F7: Gestión del cambio
y configuraciones
F8: Gestión del proyecto
F9: Entorno
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

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.

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 Tutorial UML y PU: 90/138

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.

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.

El ciclo de vida del desarrollo del software:
Flujos
Flujos de trabajo
Modelado del
negocio
Requisitos
Análisis y diseño
Implementación
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Entorno


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 Tutorial UML y PU: 94/138

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

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

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

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

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.

Relaciones lógicas entre los modelos :
Modelo de
Casos de Uso verificado por
especificado por realizado por

Modelo de
distribuido por Prueba
Modelo de
Análisis
Modelo de implementado por
Diseño
Modelo de
Despliegue
Modelo de
Implementación

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

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

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

Vistas de la arquitectura de un sistema
vocabulario, ensamblado del

funcionalidad sistema,
Vista de gestión de
Vista de diseño configuraciones
implementación
comportamiento Vista de
casos de uso
Vista de Vista de
procesos despliegue
Funcionamiento, topología del

capacidad de sistema,
crecimiento, distribución,
rendimiento entrega,
instalación

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

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.

VISTAS Y DIAGRAMAS EN UML
Diagra- Diagrama Diagrama Diagra- Diagra- Diagrama Diagrama Diagrama Diagrama

ma de de de ma de ma de de de de Compo- de Desplie-
Casos de Interac- Interacción- Clases Objetos Estados Activida- nentes gue
Uso ción- Colabora- des
Secuen- ción
cia
Vista de Casos Estática

de Uso
Dinámica
Vista de Estática
Diseño
Dinámica
Vista de Estática
Procesos
Dinámica
Vista de
Estática
Implemen-
tación
Dinámica
Vista de Estática
Despliegue
Dinámica

• Los artefactos conjunto del RUP son los siguientes:

1. Conjunto de requisitos.
2. Conjunto de diseño.
3. Conjunto de implementación.
4. Conjunto de despliegue.

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.

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.

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.

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.

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:
– 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 Tutorial UML y PU: 113/138

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

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

de Requisitos
Flujos de trabajo
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
Entorno


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.

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
Business Use-Case
del Modelo de Casos Model
de Uso 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

de Requisitos
Diagrama de Contexto
del MCU

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 Tutorial UML y PU: 120/138

Modelo de
especificado por realizado por

Modelo de
Modelo de
Análisis
Diseño
Modelo de
Despliegue
Transición del MCU hacia el MA
Modelo de
Implementación

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

Flujos de trabajo
Modelado del
negocio
Requisitos
Análisis y diseño Análisis

Implementación
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Entorno


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
Cada caso de uso se

desglosa en un diagrama
en el nivel inferior
NIVEL 2
MODELO DE CASOS DE USO MODELO DE ANÁLISIS
«trace»
caso de uso (MCU) Realización (MA)
Interfaz Gestor/Control Entidad
Artefactos del modelo de análisis

MODELO DE CASOS DE USO MODELO DE ANÁLISIS
«trace»
Proceso de Conversión:
Realización (MA)
Casos de Uso 
caso de uso (MCU)
Análisis
F01.01 Consulta saldo
Cliente I_Cajero C_Gestor_Interfaz Cta_Cliente
Diagrama de
Clases de Análisis
Atómico
I_Autenticacion C_Verificador_Autenticacio
n

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
MCU MA F01.01 Consulta saldo
Nivel i Nivel j
MODELO DE CASOS DE USO MODELO DE ANÁLISIS Cliente I_Cajero C_Gestor_Interfaz Cta_Cliente
«trace»
caso de uso (MCU) Realización (MA)

n

La estructura del modelo en Rose:
D. Clases Análisis Atómico

para el Caso de Uso
F01.01 <Nombre función> Carpeta de trabajo
en la conversión
Diagrama de Colaboración
para DCAA F01.01
Diagrama de Clases
de Análisis de Contexto

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 Tutorial UML y PU: 128/138

Flujo de
Análisis de
Requisitos
Modelo de
especificado por
Modelo de
realizado por
Modelo de
Análisis
Diseño
Flujo de
Análisis y Modelo de
Diseño Despliegue
Modelo de
Transición del MCA hacia el MD
Implementación

• 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 (>= 1)
– Clase de entidad  clase de entidad (>= 1)
– Clase de interfaz  clase de interfaz (>= 1)

<<trace>>
<<process>> Factura
Gestor de cuenta <<trace>>
Gestor de cuentas
<<trace>> <<process>>
Gestor de cliente Facturas Albarán
<<trace>>
Gestor de clientes
<<Interface_design>>
Teclado
<<trace>>
<<trace>> Pantalla
<<trace>> Puerto MSVL
<<trace>>
Interfaz de terminal celular Altavoz
<<trace>> Mi crófono

• 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

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

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
Cliente I_Cajero
MA C_Gestor_Interfaz Cta_Cliente
MD
Nivel 2 Nivel 2
n
MA MD
Nivel j Level-to-Level Nivel i
Modelo de
Casos de Uso

La estructura del modelo en Rose:
Diagrama de Clases
de Diseño de Contexto

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 Tutorial UML y PU: 137/138

Flujo de
Análisis de
Requisitos
Modelo de
especificado por
Modelo de
realizado por
Modelo de
Análisis
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

Gestión Proyectos
Gestión Población
Modelo de
Implementación
(Vista parcial)
Gestión individuos
Gestor Base de Datos
Program a Principal
Gestión Interfaces
Gestión Agentes
Gestión Cálculo
componentes

Modelo de Despliegue
(Vista parcial)
nodos /
procesadores

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 Tutorial UML y PU: 141/138

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.
– Ventajas:
• Disminuye el riesgo del error de análisis / diseño
acumulado.
• Aligera el esfuerzo en implementación.
• Proporciona la documentación del ciclo de vida en el
mismo proceso.

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
incorporación de enfoques y artefactos
complementarios:
– Patrones de diseño.
– Patrones de implementación.
– Marcos de diseño.
– Combinación de varios modelos de proceso.
– Arquitecturas Dirigidas por Modelos (Model Driven
Architectures).
– Ejecutabilidad de modelos: UML 2, validación y
verificación formales.

18. Bibliografía
1. Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de
Modelado, Addison-Wesley, Madrid, 1999.
2. Bruegge B., Dutoit A.H. Ingeniería de Software Orientado a Objetos,
Prentice Hall– Pearson educación, México, 2002.
3. Jacobson I., Booch G., Rumbaugh J. El Proceso Unificado de
Desarrollo de Software, Addison-Wesley, Madrid, 2000.
4. Pressman R.S. Ingeniería del Software. Un enfoque práctico (5ª ed.)
Mc Graw-Hill; New York , 2001.
5. Rumbaugh J., Jacobson I., Booch G. El Lenguaje Unificado de
Modelado. Manual de Referencia, Addison-Wesley, Madrid, 2000.
6. Sommerville I. Ingeniería de software, 6ª edición, Prentice Hall –
Pearson educación, México, 2002.
7. Stevens P., Pooley R. Utilización de UML en Ingeniería del Software
con Objetos y Componentes, Addison-Wesley, Madrid, 2002.
8. http://www.omg.org
9. http://www.uml.org
18. Bibliografía Parte II Tutorial UML y PU: 144/138

Modelado UML

Cargado por

Copyright:

Formatos disponibles

Modelado UML

Cargado por

Información del documento

Descripción original:

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

Modelado UML

Cargado por

Copyright:

Formatos disponibles

Modelado del

Tutorial UML y PU: 1/138

• La descripción de software en un libro de texto

Tutorial UML y PU: 3/138

• Aunque existen similitudes entre el desarrollo del software y la

Tutorial UML y PU: 4/138

Tutorial UML y PU: 5/138

Tutorial UML y PU: 6/138

Tutorial UML y PU: 7/138

Parte I: Introducción a UML.

Tutorial UML y PU: 8/138

Tutorial UML y PU: 9/138

Tutorial UML y PU: 10/138

1. Introducir los conceptos que maneja UML

2. Ser una útil toma de contacto con UML para

• Conocer sus posibilidades

3. Ser breve, conciso y no entrar en excesivos detalles

4. Describir cómo emplear UML en un proyecto

1.1. Objetivos Tutorial UML y PU: 11/138

Problema: Actualmente, Software Grande y Complejo.

Requisitos: Los programas deben poder ser mantenidos y

Solución: Estructuración, modelado.

2.1. Introducción Tutorial UML y PU: 12/138

Ante problemas complejos  Divide y vence  Estructura

Modelar es diseñar y estructurar, antes de programar.

2.2. Introducción Tutorial UML y PU: 13/138

UML es un lenguaje gráfico para: Modelar, diseñar,

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 Tutorial UML y PU: 14/138

UML está muy cerca de este paradigma.

Objeto: Intuitivamente todo lo que tiene masa, aunque

Objetos mudo real  Objetos informáticos

3.1. La Orientación a Objetos Tutorial UML y PU: 15/138

Los objetos se caracterizan por su estado y comportamiento.

Estado: Situación en que se encuentra un objeto, tal que

Los objetos mantienen su estado en uno o mas atributos.

Atributo: Dato identificado por un nombre.

3.2. La Orientación a Objetos Tutorial UML y PU: 16/138

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 Tutorial UML y PU: 17/138

Los objetos revelan su utilidad en un contexto de

3.4. La Orientación a Objetos Tutorial UML y PU: 18/138

El envío de mensajes es la forma en que se invoca los

La invocación de métodos permite a un objeto cambiar

Los detalles internos del objeto quedan ocultos para los

3.5. La Orientación a Objetos Tutorial UML y PU: 19/138

Clase: Son patrones que definen qué atributos y qué métodos

Es más fácil de entenderlo si se toma tipo como equivalente.

3.6. La Orientación a Objetos Tutorial UML y PU: 20/138

Cada objeto tiene sus atributos y sus métodos, empleando una

Dos objetos distintos de la misma clase pueden tener el

3.7. La Orientación a Objetos Tutorial UML y PU: 21/138

Hay atributos que no varían de una instancia a otra. Todas las

De manera análoga hay métodos de instancia y métodos de

3.8. La Orientación a Objetos Tutorial UML y PU: 22/138