Introducción al Análisis y

Diseño Orientado a Objetos

Tema 3

TACC II
Curso 2007/08
1
 Motivación
z Un proyecto software no consiste sólo en programar.

z Necesitamos saber cuáles son las necesidades del cliente.

{ Identificar los requisitos, anotarlos, analizarlos, validarlos.

z Necesitamos diseñar una solución, y hacer “los planos” del

software:
{ Diseño de la arquitectura, detallado, de datos, …

z Hay que asegurarse de que el software funciona:

{ Pruebas de unidad (a nivel de método y clase), de integración, del
sistema, de aceptación, etc.

z Hay que mantener el software.

{ Documentación (de cada una de las fases), coherencia entre los
productos de las distintas fases (ej. código vs. diseños). 2
Indice

zModelos de Ciclo de Vida.

zAnálisis y Diseño Orientado a Objetos.
zNotaciones.
zMetodologías.

3
Modelos de ciclo de vida
z ¿Qué estrategia seguimos para organizar las fases de
un proyecto?.

z Un modelo de ciclo de vida nos guia en las fases que

hay que realizar, sus entradas y salidas, y los criterios
de transición.

z La elección de uno u otro depende de las características

del proyecto.

z Con tecnologías orientadas a objetos se tiende a ciclos

de vida iterativos e incrementales.
4
 Modelos de Ciclo de Vida
/ Estudio de Viabilidad.

Qué
Planificación y Estimación.

Qué
Desventajas:
Análisis
•No permite iteraciones.

Cómo
Cómo
Diseño • Los requisitos se
congelan al principio del
proyecto.
Codificación
• No existe un proyecto
“enseñable” hasta el final
del proyecto.
Pruebas
e integración
MCV en
Cascada Operación y [retiro]
Mantenimiento 5
 Modelos de Ciclo de Vida

Iteraciónde
Iteración deAA&&DD [más iteraciones]

Planificación
Planificación Análisis
Análisis Diseño
Diseño

Incremento
Incremento
Extraer
Extraer Eval.
Eval.
Planificación
Planificación Análisis
Análisis Diseño
Diseño clases
clases Prototipo
Prototipo Pruebas
Pruebas cliente
cliente
reutilizables
reutilizables

[más iteraciones]

MCV iterativo e
incremental (RUP) 6
Indice

zModelos de Ciclo de Vida.

zAnálisis y Diseño Orientado a
Objetos.
{Ventajas e inconvenientes.
{Análisis.
{Diseño.
zNotaciones.
zMetodologías.
7
Análisis y Diseño
Problema vs. Solución
Análisis (qué) Diseño (cómo)

Dominio del problema Dominio de la Solución

Modelo del Dominio del Problema Modelo del Dominio de la Solución

ControTrafico
VentanaResumen VentanaMapas
Avión Controlador
Trafico BDPlanVuelo

Aeropuerto ControlTrafico
PlanVuelo
8
 Paradigma de Orientación a Objetos
Características

z Diseños modulares.

z Efectos laterales mínimos(encapsulamiento)

z Extensibilidad.

z Fácil de modificar.

z Orientado a datos.

z Explota la herencia (jerárquico).

z Reutilización de clases.
9
Ventajas
z Módulos con fuerte cohesión interna y escaso
acoplamiento externo (sin variables globales, …)
z Facilita el funcionamiento en entorno
multiprocesador (objetos distribuidos)
z Correspondencia directa con el mundo real
z Prototipos rápidos
z Herramientas y bibliotecas muy amplias
z Aplicaciones construidas enganchando objetos
z Mejor comprensión y mantenimiento
z Apropiado para aplicaciones dirigidas por eventos.
10
Inconvenientes
z Impactos desfavorables sobre espacio y tiempo de
ejecución.

z Forma de pensar diferente: curva de aprendizaje lenta.

z Herencia y ligadura dinámica dificultan las pruebas.

z Difícil seguir el flujo de ejecución (e.j. llamadas implícitas

a constructores, conversiones implícitas, etc.)

z Frameworks grandes y complicados (e.j. MFCs).

11
 Análisis Orientado a Objetos
z Centrarse en el “qué”.

z Identificar los requisitos: documentos de análisis.

{ Entrevistas.
{ Identificar requisitos funcionales y no funcionales (ej.: rendimiento,
fiabilidad)

z Especificar los requisitos: documento de especificación de

requisitos.
{ Documento técnico. Organización y clasificación de los requisitos.

z Analizar: Modelos de análisis.

{ Estudio de posibles escenarios: casos de uso.
{ Otras técnicas: fichas CRC, orientados al flujo, etc.

z Validar. 12
Análisis Orientado a Objetos
z La especificación de
requisitos describe el
Obtención
sistema, en lenguaje
de requisitos natural.
Especificación
de requisitos:
Documento
z Sirve de comunicación
entre desarrolladores y
Análisis
clientes, “contrato”.
Modelo de
Análisis:
Modelo z El modelo de análisis
Diseño del usa notación formal (ej.:
Sistema Z, Alloy) o semi-formal
Modelo del
Sistema: (ej.: UML).
Modelo

z Sirve de comunicación
entre desarrolladores. 13
Análisis Orientado a Objetos
Modelos de Análisis
Modelosbasados
Modelos basadosen en Modelosorientados
orientadosalalFlujo
Flujo
Modelos
Escenarios
Escenarios
Casosde
Casos deuso,
uso,texto.
texto. Diagramasde
Diagramas deFlujo
Flujode
deDatos
Datos
Casosde
Casos deuso,
uso,diagramas.
diagramas. Diagramasde
Diagramas deFlujo
Flujode
deControl
Control
Diagramasde
Diagramas deactividad.
actividad. Diagramasde
Diagramas deTransición
Transiciónde
deEstados
Estados
Diagramasde
Diagramas desecuencia.
secuencia. ……
……

Modelo de Análisis

Modelosbasados
Modelos basadosenen
Modelosbasados
Modelos basadosen
en
Clases
Clases Comportamiento
Comportamiento
Diagramasde
Diagramas deClases.
Clases.
Diagramasde
dePaquete.
Paquete. Diagramasde
Diagramas deEstado.
Estado.
Diagramas
ModelosCRC.
CRC. Diagramasde
Diagramas deSecuencia.
Secuencia.
Modelos
Diagramasde
deInteracción.
Interacción. ……
Diagramas
… 14
…
Análisis Orientado a Objetos
Modelos de Análisis. Basado en Escenarios.

Modelo de
Análisis: Modelo

Modelo Funcional: Modelo de Modelo

Modelo Objetos: Modelo Dinámico: Modelo

z Modelo funcional: casos de uso y escenarios.

z Modelo de Objetos: diagramas de clases y
objetos.
z Modelo dinámico: diagramas de secuencia,…
15
Casos de uso
z Describen qué hace el sistema desde el punto de vista
de un observador externo.

z Actores: ¿quién interactúa con el sistema?. También

pueden ser otros sistemas.

z Un escenario es un ejemplo de lo que ocurre cuando

uno o varios actores interactúan con el sistema.

z Caso de uso: conjunto de escenarios (secuencias de

interacción de los actores y el sistema)

16
Casos de uso

z Pasos:

{ Identificar los límites (alcance) del sistema.

{ Identificar los actores principales.

{ Para cada uno, identificar sus objetivos.

{ Definir casos de uso que satisfagan sus objetivos.

17
Ejemplo
Caso de uso: comprar una obra maestra
Actores primarios:
Agente Galería, vendedor
Interesados y Objetivos:
• Agente: quiere obtener una recomendación lo más acertada posible del
precio máximo recomendado de manera rápida.
• Vendedor: quiere vender el cuadro a un precio razonable de manera rápida.
Precondiciones:
El agente ha entrado en la aplicación.
Garantía de éxito (post-condiciones):
Se registra la venta.
Escenario Principal de Éxito:
1. El agente introduce la descripción del cuadro.
2. El sistema busca el cuadro más parecido del mismo autor.
3. El sistema presenta el precio recomendado.
4. El agente hace una propuesta por debajo del precio recomendado, y el
vendedor acepta la oferta.
5. El agente introduce información de la venta.
Extensiones:
2a. No hay ningún cuadro parecido del mismo autor, así que el sistema
no presenta una recomendación. 18

4a. El vendedor no acepta la oferta y la venta no se produce.

Modelos de Análisis Basados en Clases
Identificar las clases

z Analizar los documentos de análisis, o casos de uso.

z Clases que pertenecen al espacio de la solución vs.
espacio del problema.
z Aislar los sustantivos:
{ Entidades externas: producen o consumen información que usa
el sistema.
{ Cosas (informes, señales, etc.): información que necesita el
sistema.
{ Sucesos o eventos que ocurren durante la operación del
sistema.
{ Papeles que desempeñan los usuarios.
{ Unidades organizacionales.
{ Sitios que establecen el contexto y la función global del sistema.
{ Estructuras que definen una clase de objetos o clases
relacionadas.
19
 Cuadro
Ejemplo nombreDelArtista
apellidosDelArtista
Identificar las clases Titulo
AñoCreacion
Sistema Gestion Alto
Galeria Ancho
Tecnica
Tema

Cuadro Galeria Cuadro Subastado

Clasificacion fechaSubasta
fechaCompra precioSubasta
Fechaventa
nombreVendedor
direccionVendedor
precioCompraMaximo
precioCompraReal
precioVentaDeseado
precioVenta
nombreComprador
direccionComprador

Obra Maestra Cuadro de Otro Tipo Moda

usa nombreArtista
apellidosArtista
coeficiente 20
Obra Representativa
Clasificación de clases

z Tipos de clases:
{De entidad (a.k.a. de modelo o de negocio). Son clases
que persisten durante la aplicación. Representan
información relevante para la aplicación.

{De frontera (a.k.a. de contorno). Clases que crean la

interfaz que el usuario ve y con la que interacciona.

{De control. Realizan una “unidad de trabajo”: crean o

actualizan objetos de entidad, validan datos, etc.

21
Ejemplo
Clasificación de las clases

Proporciona los datos introducidos

por el agente
Vendedor

Obra maestra

GUI Calcular Precio

Agente
Obra Maestra
Galería
Cuadro
Subastado
22
 Técnicas Basadas en Escenarios
Diagrama de Secuencia Detallado

: GUI : Calcular Precio

:Vendedor :Agente : Cuadro
Obra Maestra
Galería Subastado
1: proporcionar
datos obra 2: transferir detalles
maestra : Obra maestra
3: crear objeto
nuevo
4: devolver objeto
Datos
proporcionados
nuevo
por el vendedor 5: buscar cuadros
subastados
6: devolver cuadro
7: proporcionar
8: mostrar subastado
precio
precio

9: proporcionar
detalles del 10: transferir detalles
vendedor 11: solicitar
vendedor
actualización

13: confirmación 12: confirmación

14: mostrar 23
confirmación
Método de Clase-Responsabilidad-
Colaborador (CRC)
z Clases/Responsabilidades/Colaboradores.

z Facilitan la colaboración entre desarrolladores.

z Una ficha por cada clase relevante.

z Se identifican sus responsabilidades.

z División de responsabilidades, relaciones de

colaboración.

z Jerarquías de generalización/especialización.
24
Método de Clase-Responsabilidad-
Colaborador (CRC)

Clase: PlanoDePlanta
Descripción:

Responsabilidad Colaborador
Define el nombre/tipo de plano de planta

Maneja la posición del plano de planta

Escala el plano de planta

Incorpora paredes, puertas y ventanas Pared

Muestra la posición de las cámaras de vídeo Camara

25
Del Análisis al Diseño
z El modelo de análisis describe el sistema desde
el punto de vista de los actores.
z No contiene información de la estructura interna
del sistema, esto es del cómo.
z Diseño del sistema:
{Objetivos de diseño que se deben optimizar (derivados
de los requisitos no funcionales).
{Una arquitectura software: descomposición en
subsistemas, dependencias entre ellos, etc.
z Diseño detallado (de objetos).
{Refinamiento del diseño del sistema.
{Diseño de las clases de la solución, interfaces. 26
Diseño Orientado a Objetos

zConceptos básicos de DOO:

{ Encapsulamiento.
{ Ocultación de información.
{ Herencia.
{ Interfaces.
{ Polimorfismo.

27
Diseño Orientado a Objetos
Encapsulamiento

zDesarrollador
{Objetivo: crear clase con interfaz clara y
comprensible
{Manera: ocultar detalles de implementación
{Beneficios: cambio de estructuras/algoritmos
sin afectar
{Coste: clases reutilizables más caras a corto
plazo

28
Diseño Orientado a Objetos
Encapsulamiento

zUsuario de las clases

{Objetivo: usar la clase con el mínimo esfuerzo
{Manera: usar sólo las operaciones provistas
{Beneficios: interfaz comprensible, bajo coste de
programación
{Coste: pérdida de eficiencia de ejecución

29
Descomposición Funcional

zMódulos construidos alrededor de las

operaciones
zDatos globales o distribuidos entre
módulos
zEntrada/Proceso/Salida
zOrganigramas de trabajo y flujo de datos

30
OOD

zMódulos construidos alrededor de las

clases
zClases escasamente acopladas, sin datos
globales
zEncapsulamiento y mensajes
zDiagramas jerárquicos de clases

31
Definción de una clase

z Identificar y nombrar la clase

z Identificar sus componentes
z Identificar sus atributos
z Identificar los errores
z Identificar las conexiones funcionales (qué
clases sirve/exige)
z Definir conexiones con superclase y subclases
z Identificar propiedades especiales (persistencia,
concurrencia)
z Probar la clase en un prototipo 32
Identificar atributos

zEl conjunto de atributos de una clase debe

ser:
{Completo (contienen toda la información
pertinente)
{General (se aplican a todos los objetos de la
clase)
{Diferenciado (cada atributo representa un
aspecto diferente de la clase)

33
Definir atributos

zTipos de atributos
{Atómicos predefinidos (entero, real, carácter,
pixel...)
{Atómico enumerativo (color, día de la
semana...)
{Colección
{Composición (referencias objetos)
zValor del atributo
{Común a muchos objetos (variable de clase)
{Propio de un objeto (variable de objeto)
34
Identificar Métodos

z Método: algoritmo que utiliza y modifica los

atributos de una clase
z Un método es desencadenado por un mensaje
z Funcionalidad de la clase: conjunto de sus
métodos
z El conjunto de métodos debe ser:
{Completo (realizan toda la funcionalidad de la clase)
{General (se aplican a todos los objetos de la clase)
{Diferenciado (cada método debe ser simple y realizar
una sola función)
35
Definir Métodos

zTipos de métodos
{Modificador (asigna valor a un atributo)
{Selector (devuelve el valor de un atributo)
{Aplicable a la clase (constructor)
{Aplicable al objeto
zParámetros del método
{¿Qué información necesita? (argumentos de
entrada)
{¿Qué debe devolver? (resultado y argumentos
de salida)
36
Identificar Errores

z¿Qué puede salir mal durante la ejecución

de un método?
z¿Qué comprobaciones debe hacer cada
método?
z¿Cómo interceptar y corregir las
condiciones de error?

37
Patrones de Diseño
z Catálogo de soluciones que han probado ser buenas
para ciertos problemas comunes de diseño.

z Evita “reinventar la rueda” continuamente.

z Reutilización de buenas prácticas, común en otras

ingenierías.

z Un patrón es una descripción del problema y la esencia

de su solución, que se puede reutilizar en casos
distintos.

z Los estudiaremos en el Tema 8.

38
Indice

zModelos de Ciclo de Vida.

zAnálisis.
zDiseño.
zNotaciones.
{UML
zMetodologías.

39
UML
http://uml.org

z Unified Modeling Language.

z Combinar y estandarizar una notación para la descripción

de sistemas orientados a objetos a partir de los lenguajes
de modelado más conocidos:
{ Booch - OOD.
{ Rumbaugh - OMT.
{ Jacobson - OOSE y Objectory.

z Combina las mejores propiedades de:

{ Conceptos de modelos de datos (ERD)
{ Modelos de negocios (workflow)
{ Modelos de Objetos
{ Modelos de Componentes
40
UML
z Es un lenguaje gráfico para visualizar, especificar,
construir y documentar las partes de un sistema de
software desde distintos puntos de vista.

z Ofrece una forma estándar de modelar sistemas

software, pudiendo utilizarse:
{ Con cualquier proceso de desarrollo.
{ A lo largo de todo el ciclo de vida.
{ Con distintas tecnologías de implementación

z Puede usarse también en otras áreas, como la

ingeniería de negocio, modelado de procesos, etc.

41
UML
z No es un método, ni un proceso ni una metodología.

z No establece qué modelos construir.

z Para un óptimo aprovechamiento, debe ser usado en un

proceso:

{ guiado por casos de uso,

{ centrado en la arquitectura,

{ iterativo e

{ incremental.
42
UML

zUML es una familia de notaciones, útiles

para describir distintos aspectos de un
sistema:
{Estático. Describe los elementos del sistema y
sus relaciones.
{Dinámico. Describe el comportamiento del
sistema a lo largo del tiempo.
zCasos de Uso. Desde el punto de vista del usuario.

43
UML

Tipos de
Diagramas

UML

Modelos 44
Vistas
z Vista de Casos de Uso
{Funcionalidad externa del sistema
z Vista Lógica
{Estructura estática y conducta dinámica del sistema
z Vista de Componentes
{Organización de las componentes
z Vista de Concurrencia
{Comunicaciones y sincronización
z Vista de Despliegue
{Arquitectura física
45
Vista de Casos de Uso
z Dirigida al Análisis de Requisitos (lo que quiere hacer el
usuario)
z Describe la funcionalidad del sistema, como la perciben
los actores externos
z Dirige el desarrollo de las otras vistas
z Define los objetivos finales del sistema
z Permite validar el sistema
z Actor externo:
{ Usuario
{ Otro sistema
z Se plasma en diagramas
{ de Casos de Uso
{ de Actividad
{ de Secuencia
46
Vista de Casos de Uso
TPV
TPV
Procesar
Procesar
Venta
Venta
Servicio
cajero de Autorización
Procesar
Procesar de Pagos
Devoluciones
Devoluciones
«actor»
«actor»
«actor»
«actor»
Analizar
Analizar
Analizadorde
Analizador de Actividad
Actividad Calculadorde
de
Actividadde
de Calculador
Actividad Impuestos
Impuestos
Ventas
Ventas
...
...
«actor»
«actor»
Gestionar
Gestionar Sistemade de
Sistema
Seguridad
Seguridad contabilidad
contabilidad

Gestionar
Gestionar
Administrador Usuarios
Usuarios
del sistema 47
Vista Lógica

zDescribe la funcionalidad interna

zDirigida a diseñadores y desarrolladores
zDefine la estructura estática
{Clases, objetos y relaciones
zDefine las colaboraciones dinámicas
{Mensajes y funciones
zPropiedades adicionales
{Persistencia y concurrencia
{Interfaces y estructura interna de las clases 48
Vista Lógica

zSe plasma en diagramas

{Estáticos
zde Clases
zde Objetos
{Dinámicos
zde Estado
zde Secuencia
zde Colaboración
zde Actividad

49
 Vista Lógica
Diagramas estáticos

Elemento

Diagrama de
clases
Carbono Hidrógeno

:Hidrógeno :Hidrógeno

Diagrama de
objetos :Hidrógeno :Carbono :Carbono :Hidrógeno

50
:Hidrógeno :Hidrógeno
 Vista Lógica
Diagrama de Estados
[(info=driver.detectarDisco())!=NULL]/
[not driver. disco=buscaDisco(info)
detectarAbierto()] NumActual = 1;
C actual = disco.obtenerCancion(ordenActual)
[driver.detectarAbierto()]

Cerrado endOfSong()/
NumActual+=1
driver.cerrar ()
driver.abrir ()

Play()/ C
Stop driver.play(actual, 0) Play
eject ()/
eject ()/

driver.play(actual, Tpausa)
[NumActual<=
disco.numCanciones()]/

Tpausa = driver.stop()
actual=
eject ()/
Abierto disco.obtenerCancion
driver.stop(); stop()/
(NumActual)
driver.abrir() driver.stop();
driver.play(actual,0)
NumActual=1

Pause()/
actual=

Play()/
disco.obtenerCancion(NumActual)

Pause

apagar ()/
driver.stop(); 51
driver.apagar()
Vista Lógica
Diagrama de Secuencia

52
Vista Lógica
Diagrama de Colaboración (comunicación)

realizarPago(cantidad) 1: realizarPago(cantidad)
:Registro
:Registro :Venta
:Venta

1.1: crear(cantidad)

:Pago
:Pago

53
 Vista Lógica
Diagrama de Actividad

Put Coffee Put Filter

in Filter in Machine
Turn on
Machine
[found
coffee] Add Water / coffeePot.turnOn
to Reservoir
Find Brew
Beverage coffee

[no coffee] Get light goes out

Cups
Pour
Coffee
[found cola] Get cans
of cola

Drink

[no cola]

54
Vista de Componentes

zDescribe los módulos del sistema y sus

dependencias.
zModelar la arquitectura software.
zDirigida a desarrolladores.
zSe plasma en diagramas.
{de Componentes

55
Vista de Componentes
Ejemplo

56

http://www.agilemodeling.com/artifacts/componentDiagram.htm
Vista de Concurrencia

z Describe la división del sistema en procesos y

procesadores
z Dirigida a desarrolladores e integradores
z Resuelve problemas de
{uso eficiente de los recursos
{ejecución en paralelo (hilos)
{comunicación y sincronización de hilos
z Se plasma en diagramas
{dinámicos
{de Componentes
{de Despliegue 57
Vista de Concurrencia
Ejemplo

:FactoryManager
:FactoryScheduler
job
1:start(job)
A2,B2/2:completed(job)
currentJob:TransferJob
<<local>> job :FactoryJobMgr

B2:completed A2:completed
1/B1:start(job) 1/A1:start(job)

:Robot :Oven

58
Vista de Despliegue

zMuestra la distribución física del sistema

(ordenadores, dispositivos) y sus
conexiones
zDirigida a desarrolladores, integradores y
probadores
zSe plasma en
{el diagrama de Despliegue
{el mapa de asignación de componentes a la
arquitectura física

59
Vista de Despliegue
Diagrama de Despliegue

60
Tipos de Diagramas

61
Tipos de Diagramas

Análisis
Análisis Diseño
Diseño

„ D. Casos de Uso. „ D. Clases y Objetos.

„ D. Secuencia del Sistema. „ D. Colaboración.

„ D. Clases Conceptuales. „ D. Secuencia.

„ D. Clases Análisis. „ D. Estados.

62
Indice

zModelos de Ciclo de Vida.

zAnálisis.
zDiseño.
zNotaciones.
zMetodologías.

63
Metodologías

zUna notación no es suficiente.

z¿Cómo se organiza el proyecto? (MCV)
z¿Qué documentación se genera?
z¿Qué técnicas se utilizan en cada fase?
z¿Quién las realiza?
z¿Herramientas de soporte?

64
Metodologías
ÎBooch (OOAD) ÎJacobson (OOSE)
ÊCASEIode (CCM) ÊOlivetti (OGROUP)

ÊCoad-Yourdon- ÎMartin-Odell
Nicola (OOA,OOD) (OOIE)
ÊNE University ÊTASKON
(Demeter) (OORAM)
ÊObject Engin. ÊWinter (OSMOSYS)
(Fresco) ÎRumbaugh (OMT)
ÊHewlett-Packard ÊLBMS (SE/OT)
(Fusion) ÎShlaer/Mellor
ÊGraham (SOMA) (OOSA)
ÊTexas Instruments ÊCCTA (SSADM)
(IE\O) ÎWirfs-Brock (RDD)
ÊICL (MTD) ÊLloyds Register 65

ÊParcPlace (OBA) (Z++)

Rational Unified Process (RUP)
z Es un proceso iterativo e incremental.
z Dirigido por los casos de uso.
z Centrado en la arquitectura.
z Fases:
{ Comienzo. Definir el alcance del proyecto.
{ Elaboración. Plan de proyecto, especificar características,
esbozar la arquitectura.
{ Construcción. Construir el producto.
{ Transición. Entrega a los usuarios.

Comienzo Elaboración Construcción Transición

66
tiempo
Rational Unified Process (RUP)
Hitos e Iteraciones

Comienzo Elaboración Construcción Transición

Visión Esbozo funcionalidad Release

de arqu. inicial del producto

Comienzo Elaboración Construcción Transición

… … … …

Iteraciones Iteraciones de Iteraciones de Iteraciones de

preliminares arquitectura desarrollo transición

Release Release Release Release Rel. Release ReleaseRel. Release Release 67

Rational Unified Process (RUP)
Fases, workflows e iteraciones

68
Rational Unified Process (RUP)
workflows y modelos

Modelo de Uso de diagramas UML

Requisitos Casos de
Uso

Modelo de
Análisis Análisis

Modelo
Modelo de
Diseño de
Despliegue
Diseño

Modelo de
Implementación Implementación

Modelo de
Prueba Pruebas
69
Modelo de Casos de Uso
Diagramas de
Casos de Uso

Modelo de Diagramas de Diagramas de

Casos de Uso Clases Objetos

Modelo de Diagramas de
Análisis Componentes

Modelo Diagramas de
De Diseño Despliegue

Modelo de Diagramas de
Despliegue Secuencia

Modelo de Diagramas de
Implementación Colaboración

Modelo de Diagramas de
Pruebas Estado

Diagramas de 70
Actividad
Modelo de Análisis
Diagramas de
Casos de Uso

Modelo de Diagramas de Diagramas de Diagramas de

Casos de Uso Clases Objetos Paquetes

Modelo de Diagramas de
Análisis Componentes

Modelo Diagramas de
De Diseño Despliegue

Modelo de Diagramas de
Despliegue Secuencia

Modelo de Diagramas de
Implementación Colaboración

Modelo de Diagramas de
Pruebas Estado

Diagramas de 71
Actividad
Modelo de Diseño
Diagramas de
Casos de Uso

Modelo de Diagramas de Diagramas de Diagramas de

Casos de Uso Clases Objetos Paquetes

Modelo de Diagramas de
Análisis Componentes

Modelo Diagramas de
De Diseño Despliegue

Modelo de Diagramas de
Despliegue Secuencia

Modelo de Diagramas de
Implementación Colaboración

Modelo de Diagramas de
Pruebas Estado

Diagramas de 72
Actividad
Modelo de Despliegue
Diagramas de
Casos de Uso

Modelo de Diagramas de Diagramas de Diagramas de

Casos de Uso Clases Objetos Paquetes

Modelo de Diagramas de
Análisis Componentes

Modelo Diagramas de
De Diseño Despliegue

Modelo de Diagramas de
Despliegue Secuencia

Modelo de Diagramas de
Implementación Colaboración

Modelo de Diagramas de
Pruebas Estado

Diagramas de 73
Actividad
Modelo de Implementación
Diagramas de
Casos de Uso

Modelo de Diagramas de Diagramas de Diagramas de

Casos de Uso Clases Objetos Paquetes

Modelo de Diagramas de
Análisis Componentes

Modelo Diagramas de
De Diseño Despliegue

Modelo de Diagramas de
Despliegue Secuencia

Modelo de Diagramas de
Implementación Colaboración

Modelo de Diagramas de
Pruebas Estado

Diagramas de 74
Actividad
Proceso dirigido por casos de uso
workflows

Requisitos Análisis Diseño Implementación Prueba

Los casos de uso dirigen y relacionan estos workflows

z Los casos de uso dirigen las iteraciones:

{ Creación y validación de la arquitectura.
{ Definición de los casos y procedimientos de prueba.
{ Planificación de las iteraciones.
{ Creación de la documentación de usuario.
{ Entrega del sistema
z Sincronización del contenido de los distintos modelos
75
Proceso centrado en la arquitectura
z Los modelos son el medio para visualizar,
especificar, construir, generar y documentar la
arquitectura del sistema.

z RUP prescribe el refinamiento sucesivo de la

arquitectura.

Comienzo Elaboración Construcción Transición

tiempo

Arquitectura

76
Bibliografía
z “Applying UML and Patterns. 2nd Edition ”. Craig
Larman, Prentice Hall, 2002.
z “Applying UML in the Unified Process”. Ivar
Jacobson, Rational Software.
z “Ingeniería del Software. Un enfoque práctico 6ª
Edición”. R.S. Pressman, McGraw Hill. 2005.
z “Ingeniería del Software Orientado a Objetos”,
Bruegge, Dutoit, Prentice Hall. 2002.
z “Análisis y Diseño Orientado a Objetos con UML
y el Proceso Unificado”. Schach. McGraw Hill.
2005.
77