Introducción al Análisis y Diseño Orientado a Objetos - U

Introducción al Análisis y
Diseño Orientado a Objetos
Tema 3
TACC II
Curso 2008/09
1
Motivación
z Un p
proyecto
y
software no consiste sólo en p
programar.
g
z Necesitamos saber cuáles son las necesidades del cliente.
{ Identificar
Id tifi
llos requisitos,
i it
anotarlos,
t l
analizarlos,
li l
validarlos.
lid l
z Necesitamos diseñar una solución,, y hacer “los planos”
p
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
sistema,
aceptación, etc.
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
Objetos.
zNotaciones.
zMetodologías.
3
Modelos de ciclo de vida
z ¿Qué
Q é estrategia
t t i seguimos
i
para organizar
i
l
las
f
fases
d
de
un proyecto?.
z Un modelo de ciclo de vida nos guia en las fases que
hayy q
que realizar, sus entradas y salidas, y los criterios
de transición.
zL
La elección
l
ió de
d uno u otro depende
d
d de
d las
l características
í i
del proyecto.
z Con teconologías orientadas a objetos se tiende a ciclos
de vida iterativos e incrementales.
4
Modelos de Ciclo de Vida
Qué
/ Estudio de Viabilidad.
Planificación y Estimación.
Análisis
Desventajas:
•No
N permite
it iteraciones.
it
i
Cómo
Diseño
Codificación
MCV en
Cascada
Pruebas
e integración
Operación
O
ó y
Mantenimiento
• Los
requisitos
se
congelan al principio del
proyecto.
• No existe un proyecto
“enseñable” hasta el final
del proyecto.
[ ti ]
[retiro]
5
Modelos de Ciclo de Vida
[más iteraciones]
Iteración de A & D
Planificación
Análisis
Diseño
Incremento
Planificación
Análisis
Diseño
Extraer
clases
reutilizables
Prototipo
Pruebas
Eval.
Eval
cliente
[más iteraciones]
MCV iterativo e
incremental (RUP)
6
Indice
zModelos
M d l d
de Ci
Ciclo
l d
de Vid
Vida.
zAnálisis
Análisis y Diseño Orientado a
Objetos.
{Ventajas e inconvenientes
inconvenientes.
{Análisis.
{Diseño.
zNotaciones.
zNotaciones
zMetodologías.
7
Análisis y Diseño
Problema vs
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
ControlTrafico
VentanaResumen
Avión
PlanVuelo
Controlador
Trafico
Aeropuerto
VentanaMapas
p
BDPlanVuelo
C t lT fi
ControlTrafico
8
Paradigma
g
de Orientación a Objetos
j
Características
z Diseños modulares
modulares.
z Efectos laterales mínimos(encapsulamiento)
(
p
)
z Extensibilidad.
z Fácil de modificar.
z Orientado a datos.
z Explota la herencia (jerárquico).
z Reutilización
R ili
ió d
de clases.
l
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 IImpactos
t
d f
desfavorables
bl
sobre
b
espacio
i y tiempo
ti
d
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. llamádas implicitas
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
D
t técnico.
té i
O
Organización
i
ió y clasificación
l ifi
ió d
de llos requisitos.
i it
z Analizar: Modelos de análisis
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
i it
d
describe
ib
ell
sistema, en lenguaje
natural.
Obtención
de requisitos
Especificación
de requisitos:
Documento
Análisis
Modelo de
Análisis:
Modelo
Diseño del
Sistema
Modelo del
Sistema:
Modelo
z Sirve de comunicación
entre desarrolladores y
clientes, “contrato”.
z El modelo de análisis
usa notación formal (ej.:
Z,, Alloy)
y) o semi-formal
(ej.: UML).
z Sirve de comunicación
entre desarrolladores. 13
Análisis Orientado a Objetos
Modelos de Análisis
Modelos basados en
Escenarios
Casos de uso, texto.
Casos de uso, diagramas.
Diagramas de actividad.
Diagramas de secuencia.
…
Modelos orientados al Flujo
Diagramas de Flujo de Datos
Diagramas de Flujo de Control
Diagramas de Transición de Estados
…
Modelo de Análisis
Modelos basados en
Clases
Diagramas de Clases.
Diagramas de Paquete.
Modelos CRC.
CRC
Diagramas de Interacción.
…
Modelos basados en
Comportamiento
Diagramas de Estado.
Diagramas de Secuencia.
Secuencia
…
14
Análisis Orientado a Objetos
Modelos de Análisis. Basado en Escenarios.
Modelo de
Análisis: Modelo
Modelo Funcional:
Modelo
Modelo de
Objetos: Modelo
Modelo
Dinámico: Modelo
z Modelo funcional: casos de uso y escenarios.
z Modelo de Objetos: diagramas de clases y
objetos.
z Modelo
M d l dinámico:
di á i
di
diagramas d
de secuencia,…
i
15
Casos de uso
zD
Describen
ib qué
é hace
h
ell sistema
i t
d d ell punto
desde
t de
d vista
i t
de un observador externo.
z Actores: ¿quién interactúa con el sistema?. También
pueden ser otros sistemas.
p
z Un escenario es un ejemplo de lo que ocurre cuando
uno o varios
i actores interactúan
i
ú con ell sistema.
i
zC
Caso de
d uso: conjunto
j t de
d escenarios
i
(
(secuencias
i
d
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
Casos de Uso: Ejemplo
CASO DE USO 1: Procesar venta
Actor Primario:
{ Cajero.
C j
Interesados y objetivos:
{ Cajero: Quiere anotaciones precisas y rápidas de precios, sin errores.
{ Cliente:
Cli t Q
Quiere
i
que ell pago sea rápido
á id con ell mínimo
í i
esfuerzo.
f
Q i
Quiere
una prueba de compra para justificar devoluciones.
{ Compañía: Quieren almacenar las transacciones y satisfacer los
intereses de los clientes.
{ Comercial: Quiere que se le actualicen sus comisiones por venta.
{ Agencias de impuestos gubernamentales: Quieren recolectar impuestos
de cada venta. Puede que haya varias agencias (nacionales, regionales,
etc.)
t )
{ Servicios de Autorización de Pagos (por tarjetas de crédito): Quiere
recibir peticiones digitales de autorizaciones en el formato y protocolo
correcto.
Precondiciones:
{ El cajero se ha identificado y autentificado.
18
Casos de Uso: Ejemplo
Garantía de éxito (Postcondiciones):
Se registra la compra en el sistema. Se calcula el impuesto aplicable. Se actualizan los sistemas de
inventario y de contabilidad. Se registran las comisiones. Se genera un recibo. Se registran las
aprobaciones de pago por tarjeta.
Escenario principal de Exito:
1. Llega un clienta al TPV con bienes o servicios que comprar.
2. El cajero comienza una nueva compra.
3. El cajero introduce un identificador de producto.
4 El sistema
4.
i t
registra
i t ell elemento
l
t y presenta
t una descripción
d
i ió del
d l mismo,
i
su precio
i y
total actual. Se calcula el precio de una lista de reglas.
El cajero
j
repite
p los p
pasos 3-4 hasta q
que no hayy más elementos.
5. El sistema presenta el total con los impuestos calculados.
6. El cajero le dice el total al cliente, y le pide que pague.
7 El cliente paga y el sistema procesa el pago.
7.
pago
8. El sistema registra la venta completada y manda la información a los sistemas
externos de inventario y contabilidad.
9. El sistema genera el recibo.
10. El cliente se va.
19
Casos de Uso: Ejemplo
Extensiones (Flujos alternativos):
a*. En cualquier momento, el sistema falla.
3a. Identificador inválido.
1. El sistema señala un error y rechaza la entrada.
7a. Pago en efectivo.
...
7b Pago con tarjeta
7b.
tarjeta.
...
Requisitos especiales:
z Pantalla táctil en panel grande y plano. El texto debe ser visible desde un metro.
z Respuesta de autorización de crédito en menos de 30 secs, el 90% de las veces.
z Recuperación robusta cuando el acceso a sistemas externos (tales como el inventario,
impuestos, etc.) falla.
z Posibilidades de internazionalización de texto.
z Reglas de negocio insertables en los pasos 3 y 7.
...
20
Casos de Uso: Ejemplo
Lista de variaciones de tecnología y datos:
3a. Se introduce el identificador del elemento mediante escáner de código de barras o
mediante el teclado.
3b. Distintos esquemas de identificadores: UPC, EAN, JAN o SKU.
7a. La información sobre el pago con tarjeta se puede introducir mediante el teclado o
lector.
7b. Se pide firma en papel. En dos años, creemos que muchos clientes van a querer
captura de firma digital.
Frecuencia de ocurrencia:
Puede ser casi continua.
Temas abiertos:
¿Cuáles son las posibles variaciones en las leyes sobre impuestos?
Explorar el tema de recuperación en caso de fallo de sistemas externos.
¿Qué modificaciones se necesitan para negocios distintos?
¿Debe el cajero extraer el cajón con la recaudación al terminar?
¿Puede el cliente usar directamente el lector de tarjetas o es el cajero el que lo hace?
21
Diagrama de Casos de Uso (UML)
TPV
Procesar
Venta
caje o
cajero
Procesar
Devoluciones
«actor»
Analizador de
Actividad de
Ventas
Administrador
del sistema
«actor»
Analizar
Actividad
Calculador de
Impuestos
p
...
Gestionar
Seguridad
Gestionar
Usuarios
Servicio
de Autorización
de Pagos
«actor»
Sistema de
contabilidad
22
Modelos de Análisis Basados en Clases
Identificar las clases
z Analizar los documentos de análisis,
análisis o casos de uso.
uso
z Clases que pertenecen al espacio de la solución vs.
espacio
p
del p
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.
23
Diagrama de clases
Conceptuales
ElementoVenta
cantidad
*
0..1
Concepto
C
t u
Objeto del
dominio
d
descrito-por
it
1
registra-ventas-de
1..*
1..
Descripcion
Precio
ID
1..*
1..
Producto
contenido-en
1 *
1..*
fecha
hora
pagada-p
por
1
*
capturada-en
cantidad
Catálogo
3 Usado-por
*
3 almacena
1
1
Tienda
dirección
nombre
Iniciada-por
1
1
3contiene
1
1..*
3 describe
Atributos
1
Cliente
contiene
1..*
1
P
Pago
1..*
1
1
Venta
Especific.Producto
1
Cajero
registra-ventas-en
1
Asociación
R i t
Registro
24
1
Clasificación de clases
z Tipos de clases:
{De entidad (a.k.a. de modelo o de negocio). Son clases
que persisten
i
d
durante
l
la
aplicación.
li
ió
R
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.
interacciona
{De control. Realizan una “unidad
unidad de trabajo
trabajo”:: crean o
actualizan objetos de entidad, validan datos, etc.
25
Diagrama de clases de análisis
Caso de uso Procesar Venta
Cajero
TPV GUI
«actor»
«actor»
«actor»
Sistema
Contabilidad
Servicio
Autorización
Pagos
Calculador
Impuestos
Calculo
Precio
Registro
Venta
Busqueda
Elemento
1..*
Venta
Elemento26
Venta
Método de Clase-ResponsabilidadColaborador (CRC)
z Clases/Responsabilidades/Colaboradores.
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.
27
Método de Clase-ResponsabilidadColaborador (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
M
Muestra
t la
l posición
i ió d
de llas cámaras
á
d
de vídeo
íd
C
Camara
28
Del Análisis al Diseño
z El modelo
d l de
d análisis
áli i d
describe
ib ell sistema
i t
d
desde
d
el punto de vista de los actores.
z No
N contiene
ti
iinformación
f
ió d
de lla estructura
t t
iinterna
t
del sistema, esto es del cómo.
z Diseño
Di ñ d
dell sistema:
i t
{Objetivos de diseño que se deben optimizar (derivados
de los requisitos no funcionales)
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.
29
Diseño Orientado a Objetos
zConceptos básicos de DOO:
{ Encapsulamiento.
p
{ Ocultación de información.
{ Herencia.
Herencia
{ Interfaces.
{ Polimorfismo.
P li
fi
30
Diseño Orientado a Objetos
j
Encapsulamiento
zDesarrollador
{Objetivo:
j
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
31
Diseño Orientado a Objetos
j
Encapsulamiento
zUsuario de las clases
{Objetivo:
j
usar la clase con el mínimo esfuerzo
{Manera: usar sólo las operaciones provistas
{Beneficios: interfaz comprensible
comprensible, bajo coste de
programación
{Coste: pérdida de eficiencia de ejecución
32
Descomposición Funcional
zMódulos construidos alrededor de las
p
operaciones
zDatos globales o distribuidos entre
módulos
zEntrada/Proceso/Salida
zOrganigramas de trabajo y flujo de datos
33
OOD
zMódulos construidos alrededor de las
clases
zClases escasamente acopladas, sin datos
globales
zEncapsulamiento y mensajes
zDiagramas jerárquicos de clases
34
Definición de una clase
z Identificar y nombrar la clase
p
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
35
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)
36
Definir atributos
zTipos
Ti
d
de atributos
t ib t
{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
op o de u
un objeto ((variable
a ab e de objeto)
37
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)
38
Definir Métodos
zTipos
Ti
de
d métodos
ét d
{Modificador (asigna valor a un atributo)
{Selector (devuelve el valor de un atributo)
{Aplicable
p
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 sa
salida)
da)
39
Ejemplo
ElementoVenta
C tid d Entero
Cantidad:
E t
descrito-por
*
1
getSubTotal()
1..*
contenido-en
1
Venta
Fecha: Date
hora: Time
completa: Logico
captura
1
Completar()
*
crearElementoVenta(..)
crearPago()
getTotal()
g
()
1
pagada-por
1
1
1
Busca-en
catalogo
Registro
...
Cantidad: Dinero
Catalogo
g
...
1
finalizarVenta()
introducirElemento(...)
hacerNuevaCompra(...)
realizarPago(...)
5usa
1
Tienda
1
tiene
Descripcion: Text
Precio: Dinero
ID: IDElemento
...
1 *
1..*
5contiene
1
getEspecificacion(...)
Dirección: Direccion
nombre: Texto
1
P
Pago
EspecificacionProducto
1
anyadirVenta(...)
40
3Registra-completadas
1
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?
41
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.
zR
Reutilización
tili
ió de
d buenas
b
prácticas,
á ti
común
ú en otras
t
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.
distintos
z Los estudiaremos en el Tema 8.
42
Indice
zModelos de Ciclo de Vida.
zAnálisis.
zAnálisis
zDiseño.
zNotaciones.
{UML
zMetodologías.
zMetodologías
43
UML
http://uml.org
z Unified Modeling Language
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.
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
44
UML
z Es un lenguaje gráfico para visualizar
visualizar, especificar
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:
software,
{ Con cualquier proceso de desarrollo.
{ A lo largo de todo el ciclo de vida.
{ Con
C di
distintas
ti t ttecnologías
l í d
de iimplementación
l
t ió
z Puede usarse también en otras áreas,, como la
ingeniería de negocio, modelado de procesos, etc.
45
UML
z No es un método,
método ni un proceso ni una metodología
metodología.
z No establece qué modelos construir.
z Para un óptimo aprovechamiento, debe ser usado en un
proceso:
{ guiado por casos de uso
uso,
{ centrado en la arquitectura,
{ iterativo e
{ incremental.
46
UML
zUML es una familia de notaciones, útiles
para describir distintos aspectos
p
p
de un
sistema:
{Estático. Describe los elementos del sistema y
{Estático
sus relaciones.
{Dinámico Describe el comportamiento del
{Dinámico.
sistema a lo largo del tiempo.
zCasos de Uso
Uso. Desde el punto de vista del usuario
usuario.
47
UML
Tipos de
Diagramas
UML
Modelos
48
Vistas
z Vista
Vi t de
d C
Casos d
de U
Uso
{Funcionalidad externa del sistema
z Vista
Vi t Lógica
Ló i
{Estructura estática y conducta dinámica del sistema
z Vista
Vi t de
d C
Componentes
t
{Organización de las componentes
z Vista
Vi t de
d C
Concurrencia
i
{Comunicaciones y sincronización
z Vista
Vi t de
d D
Despliegue
li
{Arquitectura física
49
Vista de Casos de Uso
z Dirigida
g
al Análisis de Requisitos
q
((lo q
que q
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 p
plasma en diagramas
g
{ de Casos de Uso
{ de Actividad
{ de Secuencia
50
Vista de Casos de Uso
TPV
Procesar
Venta
caje o
cajero
Procesar
Devoluciones
«actor»
Analizador de
Actividad de
Ventas
Administrador
del sistema
«actor»
Analizar
Actividad
Calculador de
Impuestos
p
...
Gestionar
Seguridad
Gestionar
Usuarios
Servicio
de Autorización
de Pagos
«actor»
Sistema de
contabilidad
51
Vista Lógica
zDescribe la funcionalidad interna
zDirigida a diseñadores y desarrolladores
zDefine la estructura estática
{Clases, objetos y relaciones
zDefine
Define las colaboraciones dinámicas
{Mensajes y funciones
zP i d d adicionales
zPropiedades
di i
l
{Persistencia y concurrencia
{Interfaces y estructura interna de las clases
52
Vista Lógica
zSe plasma en diagramas
{Estáticos
zde Clases
j
zde Objetos
{Dinámicos
zde Estado
zde Secuencia
de Colaboración
zde
zde Actividad
53
Vista Lógica
g
Diagramas estáticos
Elemento
Diagrama
ag a a de
clases
Carbono
Diagrama de
Di
d
objetos
:Hidrógeno
Hidrógeno
:Hidrógeno
:Hidrógeno
:Carbono
:Carbono
:Hidrógeno
:Hidrógeno
:Hidrógeno
54
Vista Lógica
Diagrama
g
de Estados
endOfSong()/
NumActual+=1
Play()/
Pl
()/
driver.play(actual, 0)
eject ()/
driver.stop(); stop()/
driver.abrir() driver.stop();
NumActual=1
actual=
disco.obtenerCancion(NumActual)
C
Play
Pause()//
Tpausa = driver.stop
p()
Abierto
Stop
Play()/
driver.plaay(actual, Tp
pausa)
e
eject
()/
driver.cerrar ()
d
Cerrado
ejject ()/
driver.abrir ())
d
[driiver.detectarA
Abierto()]
[(info=driver.detectarDisco())!=NULL]/
disco=buscaDisco(info)
[not driver.
detectarAbierto()] NumActual = 1;
C
actual = disco.obtenerCancion(ordenActual)
disco obtenerCancion(ordenActual)
[NumActual<=
disco.numCanciones()]/
actual=
disco.obtenerCancion
(NumActual)
driver.play(actual,0)
P
Pause
apagar ()/
driver.stop();
driver.apagar()
55
Vista Lógica
g
Diagrama de Secuencia
56
Vista Lógica
g
Diagrama de Colaboración (comunicación)
realizarPago(cantidad)
:Registro
1: realizarPago(cantidad)
:Venta
1.1: crear(cantidad)
:Pago
57
Vista Lógica
g
Diagrama de Actividad
Put Coffee
in Filter
[found
coffee]
Find
Beverage
[no coffee]
Put Filter
in Machine
Turn on
Machine
Add Water
to Reservoir
Get
Cups
/ coffeePot.turnOn
Brew
coffee
light goes out
Pour
Coffee
[found cola]
Get cans
of cola
Drink
[no cola]
58
Vista de Componentes
zDescribe los módulos del sistema y sus
p
dependencias.
zModelar la arquitectura software.
zDirigida
Di i id a d
desarrolladores.
ll d
zSe
Se p
plasma
as a e
en d
diagramas.
ag a as
{de Componentes
59
Vista de Componentes
p
Ejemplo
60
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
61
Vista de Concurrencia
Ejemplo
:FactoryManager
:FactoryScheduler
job
currentJob:TransferJob
A2,B2/2:completed(job)
1:start(job)
:FactoryJobMgr
<<local>> job
A2:completed
B2:completed
1/B1:start(job)
:Robot
1/A1:start(job)
:Oven
62
Vista de Despliegue
zMuestra
M
t la
l di
distribución
t ib ió fí
física
i d
dell sistema
i t
(ordenadores, dispositivos) y sus
conexiones
zDirigida
g
a desarrolladores,, integradores
g
y
probadores
zSe plasma en
{el diagrama de Despliegue
{el mapa de asignación de componentes a la
arquitectura física
63
Vista de Despliegue
p g
Diagrama de Despliegue
64
Tipos de Diagramas
65
Tipos de Diagramas
Análisis
Diseño
„
D. Casos de Uso.
„
D. Clases y Objetos.
„
D. Secuencia del Sistema.
„
D. Colaboración.
„
D Clases Conceptuales
D.
Conceptuales.
„
D Secuencia
D.
Secuencia.
„
D. Clases Análisis.
„
D. Estados.
66
Indice
zModelos de Ciclo de Vida.
zAnálisis.
zAnálisis
zDiseño.
zNotaciones.
zMetodologías.
zMetodologías
67
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?
68
Metodologías
ÎBooch
(
(OOAD)
)
ÊCASEIode (CCM)
ÊCoad-YourdonNi l (OOA,OOD)
Nicola
(OOA OOD)
ÊNE University
(Demeter)
ÊObject Engin.
(Fresco)
ÊHewlett-Packard
(Fusion)
ÊGraham (SOMA)
ÊTexas Instruments
(IE\O)
ÊICL (MTD)
ÊParcPlace (OBA)
ÎJacobson
(OOSE)
ÊOlivetti (OGROUP)
ÎMartin-Odell
(OOIE)
ÊTASKON
((OORAM))
ÊWinter (OSMOSYS)
ÎRumbaugh (OMT)
ÊLBMS (SE/OT)
ÎShlaer/Mellor
(OOSA)
ÊCCTA (SSADM)
ÎW
Wirfs-Brock
s oc (RDD)
(
)
ÊLloyds Register
(Z++)
69
Rational Unified Process (RUP)
z Es un p
proceso iterativo e incremental.
z Dirigido por los casos de uso.
z Centrado en la arquitectura.
arquitectura
z Fases:
{ Comienzo
Comienzo. Definir el alcance del proyecto.
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
tiempo
Construcción
Transición
70
Rational Unified Process (RUP)
(
)
Hitos e Iteraciones
Comienzo
Elaboración
Visión
Comienzo
Esbozo
de arqu.
Elaboración
…
Iteraciones
preliminares
Release
Construcción
funcionalidad
inicial
Construcción
Release
del producto
Transición
…
…
Iteraciones de
arquitectura
Transición
Iteraciones de
desarrollo
Release Release Release Rel.
…
Iteraciones de
transición
Release ReleaseRel.
Release Release
71
Rational Unified Process (RUP)
Fases workflows e iteraciones
Fases,
72
Rational Unified Process (RUP)
workflows y modelos
Requisitos
Análisis
Diseño
Implementación
Prueba
Uso de diagramas UML
Modelo de
Casos de
Uso
Modelo de
Análisis
Modelo
de
Diseño
Modelo de
Despliegue
g
Modelo de
I l
Implementación
t ió
Modelo de
Pruebas
73
Modelo de Casos de Uso
Diagramas de
Casos de Uso
Modelo de
Casos de Uso
Diagramas de
Clases
Modelo de
Análisis
Diagramas de
Componentes
Modelo
De Diseño
Diagramas d
Di
de
Despliegue
Modelo de
D
Despliegue
li
Diagramas
g
de
Secuencia
Modelo de
Implementación
Diagramas de
Colaboración
Modelo de
Pruebas
Diagramas de
Estado
Diagramas de
Actividad
Diagramas de
Objetos
Diagramas de
Paquetes
74
Modelo de Análisis
Diagramas de
Casos de Uso
Modelo de
Casos de Uso
Diagramas de
Clases
Modelo de
Análisis
Diagramas de
Componentes
Modelo
De Diseño
Diagramas d
Di
de
Despliegue
Modelo de
D
Despliegue
li
Diagramas
g
de
Secuencia
Modelo de
Implementación
Diagramas de
Colaboración
Modelo de
Pruebas
Diagramas de
Estado
Diagramas de
Actividad
Diagramas de
Objetos
Diagramas de
Paquetes
75
Modelo de Diseño
Diagramas de
Casos de Uso
Modelo de
Casos de Uso
Diagramas de
Clases
Modelo de
Análisis
Diagramas de
Componentes
Modelo
De Diseño
Diagramas d
Di
de
Despliegue
Modelo de
D
Despliegue
li
Diagramas
g
de
Secuencia
Modelo de
Implementación
Diagramas de
Colaboración
Modelo de
Pruebas
Diagramas de
Estado
Diagramas de
Actividad
Diagramas de
Objetos
Diagramas de
Paquetes
76
Modelo de Despliegue
Diagramas de
Casos de Uso
Modelo de
Casos de Uso
Diagramas de
Clases
Modelo de
Análisis
Diagramas de
Componentes
Modelo
De Diseño
Diagramas d
Di
de
Despliegue
Modelo de
D
Despliegue
li
Diagramas
g
de
Secuencia
Modelo de
Implementación
Diagramas de
Colaboración
Modelo de
Pruebas
Diagramas de
Estado
Diagramas de
Actividad
Diagramas de
Objetos
Diagramas de
Paquetes
77
Modelo de Implementación
Diagramas de
Casos de Uso
Modelo de
Casos de Uso
Diagramas de
Clases
Modelo de
Análisis
Diagramas de
Componentes
Modelo
De Diseño
Diagramas d
Di
de
Despliegue
Modelo de
D
Despliegue
li
Diagramas
g
de
Secuencia
Modelo de
Implementación
Diagramas de
Colaboración
Modelo de
Pruebas
Diagramas de
Estado
Diagramas de
Actividad
Diagramas de
Objetos
Diagramas de
Paquetes
78
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
79
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.
arquitectura
C i
Comienzo
El b
Elaboración
ió
C
Construcción
t
ió
T
Transición
i ió
tiempo
Arquitectura
80
Bibliografía
z “Applying
“A l i UML and
d Patterns.
P tt
2 d Edition
2nd
Editi ”.
” Craig
C i
Larman, Prentice Hall, 2002.
z “Applying
“A l i
UML in
i the
th Unified
U ifi d Process”.
P
” Ivar
I
Jacobson, Rational Software.
z “Ingeniería
“I
i í del
d l Software.
S ft
U enfoque
Un
f
práctico
á ti 6ª
Edición”. R.S. Pressman, McGraw Hill. 2005.
z “Ingeniería
“I
i í del
d l Software
S ft
O i t d a Objetos”,
Orientado
Obj t ”
Bruegge, Dutoit, Prentice Hall. 2002.
z “Análisis
“A áli i y Diseño
Di ñ Orientado
O i t d a Objetos
Obj t con UML
y el Proceso Unificado”. Schach. McGraw Hill.
2005
2005.
81