Construccin de Software

Captulo 2

Un Proceso basado en UML

 Contenidos

Introduccin
Modelado del Negocio
Modelado de Requisitos
Modelado del Anlisis
Patrones GRASP
Modelado del Diseo
Casos Prcticos

2
 Contenidos

Introduccin
Modelado del Negocio
Modelado de Requisitos
Modelado del Anlisis
Patrones GRASP
Modelado del Diseo
Casos prcticos

3
 Un proceso simple

Descrito en UML y Patrones, C. Larman,

Prentice-Hall, 2002.
Fcil de aprender y usar.
No incluye modelado del negocio.
Conforma con el Proceso Unificado, UP
Dirigido por casos de usos.
Desarrollo iterativo e incremental
Conforma con modelado gil

4
 Etapas del Proceso
Inicio
Comprender procesos del negocio (opcional)
Obtener y especificar requisitos del sistema
Identificar y especificar clases y colaboraciones
para objetos del dominio (anlisis)
Resolver problemas de diseo (arquitectura,
base de datos, redes, patrones, nuevas clases y
colaboraciones)
Implementacin y pruebas
Validacin
5
 Etapas del Proceso

Modelado del Negocio (opcional)

Modelado de Requisitos
Modelado del Anlisis
Modelado del Diseo
Implementacin
Pruebas

6
M o d e lo d e C a s o s M o d e lo d e D ia g ra m a s
de Uso D o m in io d e P ro c e s o
M o d e lo d e
M o d e lo d e R e q u is it o s N e g o c io

D ia g ra m a d e
S e c u e n c ia d e l
S is t e m a ( D S S )
(u no po r caso d e uso)

C o n tra tos D ia g ra m a d e
( u n o p o r i n t e r a c c i n ) C la s e s

C o la b o r a c io n e s
( u n a p o r c o n tr a to )

M o d e lo d e A n lis is

A r q u ite c tu r a d e l
S is te m a

P a q u e te s D is e o G U I

P a t r o n e s d e D is e o P e r s is te n c ia

El Proceso
E s tru c tu ra s d e D i s t r ib u c i n
D a to s

M o d e lo d e l D is e o
 Inicio

Estudio de necesidades de la empresa, ver si es

viable, alternativas, anlisis de riesgos,
oportunidad.
Definicin de objetivos del proyecto
Estimacin aproximada del coste
Duracin una o dos semanas

Debemos abordar el proyecto?

8
 Inicio
Primeros talleres de requisitos
Plan para la primera iteracin
Casos de uso escritos en formato breve, excepto
unos pocos que se consideran claves.
Se identifican riesgos
Escribir borrador del documento Visin y
Especificacin Complementaria
Prototipado

9
 Contenidos

Introduccin
Modelado del Negocio
Modelado de Requisitos
Modelado del Anlisis
Patrones GRASP
Modelado del Diseo
Casos prcticos

10
 Modelado del Negocio

Objetivo:
Comprender el conjunto de procesos de
negocio que tienen lugar dentro de una
empresa, como paso previo a establecer los
requisitos del sistema a desarrollar.

Cmo consigue la empresa sus objetivos?

11
 Procesos de Negocio

Una organizacin tiene una serie de objetivos que

satisface a travs de Procesos de Negocio
Elementos de un proceso de negocio:
Flujo de Tareas, Agentes, Informacin y Reglas Negocio
Reglas de Negocio regulan el funcionamiento de
la empresa
Describen restricciones y comportamientos
NO son requisitos, pero influyen en ellos

12
 Procesos y Reglas del Negocio
Procesos del Negocio
RN1
datos
tarea2 RN3
tarea1 tarea4 tarea5
tarea3

Reglas del Negocio RN2

Determinan polticas y estructura de la informacin

13
 Ejemplo
Empresa que fabrica productos bajo demanda

Objetivos
Estratgicos
Satisfacer pedido Incrementar las Reducir tiempo de
...
de cliente ventas un 25% fabricacin un 15%

Subobjetivos Registrar Fabricar Gestionar Realizar

Procesos pedidos de productos almacn de pedidos a
del Negocio clientes pedidos materiales proveedores

Casos de Generar
Registrar Fabricar Gestionar pedidos a
Uso del
pedido productos almacn proveedor
Negocio
 Etapas del modelado del negocio

Identificar y definir los procesos de negocio segn

los objetivos de la organizacin.
Definir un caso de uso del negocio para cada
proceso del negocio (diagrama de casos de uso del
negocio muestra el contexto y los lmites de la
organizacin).
Identificar los roles implicados en los diferentes
procesos del negocio (diagrama de roles).

15
 Etapas del modelado del negocio
Modelar el flujo de tareas asociado a cada proceso de
negocio mediante escenarios (diagramas de
secuencia) y diagramas de procesos (diagramas de
actividades) que muestran la interaccin entre roles
para conseguir el objetivo.

Especificar las informaciones y actividades incluidas

en cada diagrama de actividades.

16
Diagrama Casos de Uso del Negocio

Cliente Registrar Pedido

Fabricar P roducto

Gestin Almacen

Pedidos Proveedores Proveedor

17
Diagrama Casos de Uso del Negocio

Operario Puesto Fabricar Producto Jefe Tcnico

Worker
Gestin Almacen Operario Almacen

18
 Casos de Uso del Negocio
Descripcin Textual
Plantillas
Diagramas
Diagrama de roles:
aspecto estructural de colaboracin entre roles
Escenario:
aspecto de comportamiento de la colaboracin
Diagrama de Proceso:
workflow que realiza el caso de uso del negocio
19
 Ejemplo de Caso de Uso del Negocio
Registrar Pedido
1. El cliente realiza un pedido que incluir la fecha del pedido, los datos del cliente y los productos
solicitados.

2. El comercial revisa el pedido (completndolo si es necesario) y le da curso, envindolo al jefe

tcnico para que realice el anlisis del mismo.

3. El jefe tcnico analiza la viabilidad de la fabricacin de cada producto del pedido por separado.
- si el producto pedido est en el catlogo, se acepta la fabricacin del mismo,
- en caso contrario, el producto es especial, y el jefe tcnico estudia su fabricacin
- si sta es viable, la fabricacin del producto especial es aceptada,
- si no es viable, el producto no ser fabricado.

4. Una vez estudiado el pedido completo, el jefe tcnico

- informa al departamento comercial de la aceptacin/rechazo de cada producto integrante del pedido.
- si todos los productos de un pedido han sido aceptados, genera una orden de trabajo para cada producto,
a partir de una plantilla de fabricacin (la estndar, si el producto estaba catalogado, o bien una nueva
generada para el producto, si ste estaba fuera del catlogo). Cada orden de trabajo es enviada al jefe de
produccin, y queda pendiente de su lanzamiento.

5. El comercial comunica al cliente el resultado del anlisis de su pedido.

20
 Plantilla Caso de Uso del Negocio
Proceso de
Registrar Pedido
Negocio
Objetivo Registrar pedido de un cliente
Descripcin 1. El cliente enva una orden de pedido, que debe incluir la fecha de solicitud, datos del
Rol Externo
cliente y productos solicitados. Es posible que sea un empleado del departamento comercial
quien introduzca el pedido, a peticin de un cliente que realiz su pedido por telfono o lo
envi por fax o correo ordinario al dpto. comercial de la empresa.
2. El empleado revisa el pedido (completndolo, si es necesario), y comienza su
procesamiento envindolo al jefe tcnico, encargado de su anlisis.
3. El jefe tcnico analiza la viabilidad de cada producto pedido por separado:
Si el producto pedido est en el catlogo, su fabricacin es aceptada.
Roles Internos
En caso contrario es considerado un producto especial y estudia su produccin:
- Si es viable, la fabricacin del producto especial es aceptada;
- Si no es viable, el producto especial no ser fabricado.
4. Una vez estudiado el pedido completo, el jefe tcnico...
Informa al depto comercial de la aceptacin o rechazo de cada producto pedido;
Si todos los productos de un pedido han sido aceptados, se crea una orden de trabajo
para cada producto, a partir de una plantilla de fabricacin (la estndar si el producto
estaba catalogado, o una nueva, especficamente diseada para el producto, si ste no
estaba en el catlogo). Cada orden de trabajo es enviada al jefe de produccin, y queda
pendiente de su lanzamiento.
5. El comercial comunica al cliente el resultado final del anlisis de su pedido.
Prioridad Bsico
Riesgos ...
Posibilidades ...
Tiempo Ejec. ...
Coste Ejec. ...
 Modelado del negocio

Identificamos los agentes o roles participantes

(En el ejemplo: Cliente, Comercial, Jefe Tcnico y
Jefe Produccin )
Creamos escenarios para mostrar la
colaboracin entre los agentes, distinguimos
entre flujos bsicos y alternativos:
Escenarios: diagramas de secuencia (objetos
son roles)

22
Workers en Registrar Pedido

1..n 1 1..5 1
Cliente Comercial Jefe Tcnic o
1

1..3

Jefe P roducc in
 Escenario Registrar Pedido

: Cliente : Comercial : Jefe Tcnico : Jefe Produccin

cursar pedido
estudiar pedido

[ok] realizar Produccin

responder estudio

aceptar pedido
 Flujos de actividades

Mostrar flujo del proceso mediante

diagramas de proceso
diagramas de actividades con calles que
corresponden a roles
una actividad puede ser compleja para ser
descrita en otro diagrama.
Incluir slo informaciones relevantes

25
 Cliente Comercial Jefe Tcnico

Realizar
Pedido

Cursar Pedido

Actividad compleja:
otro diagrama
propio? Analizar
Viabilidad

Rechazar viable?
Pedido

Si
si

Diagrama de Crear Plantilla

Proceso
Confirmar
Pedido

Generar Ordenes de
Trabajo
 Cliente Comercial Jefe Tecnico Jefe Produccion

Inicio

Introducir
Pedido

Cursar Pedido Analizar Pedido

Viable

Denegar Pedido Viable

[no]
[si]

Aceptar Pedido

Diagrama de
Proceso Ordenar
Fabricacion

Planificar
Produccion
 Reglas de Negocio

Reglas de restriccin
Especifican polticas o condiciones que restringen la
estructura y comportamiento de las informaciones
Estmulo-Respuesta
Restriccin de operacin
Restriccin de estructura
Reglas de derivacin
Especifican polticas o condiciones para inferir nuevos
hechos a partir de otros.

28
 Glosario
... ...
Objeto de Informacin: Pedido Actividad: Ordenar fabricacion

Atributos Origen: Analizar viabilidad

Codigo de pedido Agente: Jefe Tecnico
Fecha de solicitud Precondiciones: La fabricacion de todos los productos
Fecha lmite de entrega pedidos es viable. Existe una plantilla de fabricacin para
Conjunto de {Producto} cada uno de dichos productos.
Cliente Postcondiciones: Ha sido creada una orden de trabajo
Importe total para cada producto, con estado pendiente, y ha sido enviada
Estado Actual al jefe de produccin para su planificacin.
Caso de Uso : - por especificar-
Restricciones
- El cdigo de pedido identificar unvocamente el
pedido, y ser asignado automticamente por el
sistema Actividad: Notificar aceptacion de pedido
- La fecha de solicitud ser anterior a la fecha lmite de
entrega.
Origen: Analizar viabilidad
- Un pedido contendr al menos un producto; no existe
Agente: Comercial
lmite mximo de productos.
Precondiciones: La fabricacin de todos los productos
- Un pedido siempre ser solicitado por uno y pedidos es viable.
solamente un cliente. Postcondiciones: Se ha comunicad al cliente la
- El importe total ser calculado a partir del precio de aceptacin de su pedido. El estado del pedido es aceptado.
cada producto pedido.
Caso de Uso : - por especificar-
Clase del Dominio : - por especificar -

Trazabilidad
 Especificacin de las actividades

Contrato: nombre de la actividad realizada por los actores

Origen: Actividad/es precedente/s
Agente: Actor que realiza la actividad
Precondicin: Estado previo a la realizacin de la actividad
Postcondicin: Estado posterior a la realizacin de la
actividad
Caso de uso: Nombre del caso de uso que se corresponde
con la actividad. Este campo no se rellenar hasta que no
se identifiquen los casos de uso.

30
 Especificacin de las informaciones

Nombre de la informacin
Atributos: Listado de los atributos de la informacin
Restricciones: Restricciones sobre los atributos de la
informacin, referidas tanto al significado como al
valor de los mismos.
Clase: Nombre de la clase que modelar esta
informacin. En principio no se indica nada, y slo se
rellena este campo cuando la clase es identificada en
el modelado conceptual.

31
 Contenidos

Introduccin
Modelado del Negocio
Modelado de Requisitos
Modelado del Anlisis
Patrones GRASP
Modelado del Diseo
Casos prcticos

32
 Modelado de Requisitos

Objetivo:
Se establecen los requisitos funcionales y
no funcionales del sistema.

A partir del modelo del negocio (si se hace)

se construye el modelo de casos de uso y
el modelo conceptual.

33
 Tipos de Requisitos

Funcionales
No Funcionales
Usabilidad
Fiabilidad
Rendimiento
Adaptabilidad, Mantenimiento, Configurable
Implementacin: lenguajes, herramientas,..
GUI
Legales

34
 Del modelo de negocio al modelo de
requisitos

Extraer los casos de uso del sistema a

partir de las actividades que aparecen en
los diagramas de actividades.
Establecer el modelo conceptual a
partir de las informaciones incluidas en los
diagramas de actividades.

35
 Del modelo de negocio al modelo de
requisitos
De los diagramas de proceso...

rol
actor
Caso de Uso
actividad

objeto Concepto del

Dominio

36
 Cursar Pedido

Comercial

Confirmar Pedido

Analizar Viabilidad

Jefe Tcnico

Crear Plantilla

Casos de Uso para Registrar Pedido

 Responsable Servicio PE Alumno Sistema

Registrar Curso

Aprobar Curso

Preinscripcin

Avisar
Admi ti dos

Matriculacin
Hay alumnos? Gestin
no
Cursos PE
Cambiar
admitidos Hay alumnos?

no

Cancelar Curso

Crear Proyecto

Cerrar Curso
 Gestin
Registrar curso Cursos PE

Aprobar curso
Rebajar Cupo Servicio CPE
Responsable

Cerrar curso

Crear proyecto
Servicio Contabilidad

Cerrar Preinscripcin

Realizar preinscripcin

Cerrar Mat riculacin

Sist ema
Alumno

Realizar Matriculacin
Cancelar curso
 Identificacin de casos de uso

Objetivos Estrtegicos casos de uso del negocio

Ejemplo: Evitar prdidas
Objetivos de Usuario casos de uso
Ejemplo: Realizar Venta
Subfunciones casos de uso?
Ejemplo: Iniciar sesin (Login)

40
 Identificacin de casos de uso

Establecer los lmites del sistema

Identificar los actores principales
Es el cliente un actor en el sistema TPV?
Identificar sus objetivos de usuario
Posible uso de los eventos externos
Definir un caso de uso por objetivo de usuario
Excepcin: casos de uso para manejar informacin
(crear, eliminar, modificar, consultar)
Formato expandido y esencial

41
 Plantilla usecases.org
Actor Principal
Personas involucradas e Intereses
Precondiciones
Postcondiciones
Escenario Principal (Flujo Bsico)
Extensiones (Flujos Alternativos)
Requisitos especiales
Tecnologa y Lista Variaciones de datos
Frecuencia
Cuestiones abiertas

42
Ejemplo: Terminal Punto de Venta

Realizar Venta

Cajero Cliente

Registrar Productos

Casos de Uso
Inicia
Gerente

Gestion Usuarios
Administrador
Sistema

43
 Caso de uso Realizar Venta
Resumen: Un cliente llega al TPV con un conjunto de artculos. El
Cajero registra los artculos y se genera un ticket. El cliente paga en
efectivo y recoge los artculos.
Actor Principal: Cajero
Personal Involucrado e Intereses:
Cajero: quiere entradas precisas, rpida y sin errores de pago
Compaa: quiere registrar transacciones y satisfacer clientes.
...
Precondicin: El cajero se identifica y autentica
Postcondiciones: Se registra la venta. Se calcula el
impuesto. Se actualiza contabilidad e inventario...

44
 Caso de uso Realizar Venta
Flujo Bsico:
1. A: El cliente llega al TPV con los artculos.
2. A: El cajero inicia una nueva venta
3. A: El cajero introduce el identificador de cada artculo.
4. S: El sistema registra la lnea de venta y presenta descripcin del
artculo, precio y suma parcial.
El Cajero repite los pasos 3 y 4 hasta que se indique.
5. S: El Sistema presenta el total
6. A: El Cajero le dice al Cliente el total a pagar
7. S: El Cliente paga y el sistema gestiona el pago.
8. S: El Sistema registra la venta completa y actualiza Inventario.
9. S: El Sistema presenta recibo

45
 Caso de uso Realizar Venta
Extensiones (Flujos Alternativos):
3a. Identificador no vlido
1. El Sistema seala el error y rechaza la entrada
3-6a. El Cliente pide eliminar un artculo de la compra
1. El Cajero introduce identificador a eliminar
2. El sistema actualiza la suma
...
7a. Pago en efectivo
1. El Cajero introduce cantidad entregada por el cliente
2. El Sistema muestra cantidad a devolver
...
....

46
 Caso de uso Realizar Venta
Requisitos especiales:
- Interfaz de usuario con pantalla tctil en un monitor de pantalla
plana. El texto debe ser visible a un metro de distancia.
- Tiempo de respuesta para autorizacin de crdito de 30 sg. el 90%
de las veces
...
Lista de Tecnologa y Variaciones de Datos:
- El identificador podra ser cualquier esquema de cdigo UPC, EAN,..
- La entrada de informacin de la tarjeta se realiza mediante un lector
de tarjetas.
...
Cuestiones Pendientes:
- Explorar cuestiones de recuperacin de accesos a servicios remotos
- Qu adaptaciones son necesarias para diferentes negocios?

47
Diagramas de estado de casos de uso
int roducirArt iculo

Esperando crearNuevaVenta Introduciendo

Venta Articulos

finaliz arVent a

EsperandoPago

realizarPagoEnEfect ivo

Autorizando
Pago
realizarPagoACredito
Procesar Venta

realizarPagoConCheque

48
 Elaboracin de casos de uso

Cundo?
Al principio de la iteracin en formato extendido y
esencial, se refinan a lo largo de las iteraciones
Dnde?
En talleres de captura de requisitos
Quin?
Usuarios finales, clientes, desarrolladores
Cmo? (Herramientas)
Herramientas de requisitos web-enabled integradas
con un procesador de texto (texto cdu) y
herramientas CASE UML (diagramas de cdu)

49
 Recomendaciones sobre casos de uso
Define bien los lmites del sistema.
Los actores interaccionan con el sistema.
Pregunta qu quieren los actores del sistema:
Objetivos.
Distingue el flujo normal de los flujos alternativos.
Lo importante es escribir la descripcin del caso
de uso, no dibujar diagramas de casos de uso.
Uso limitado de las relaciones include y extend

50
 Recomendaciones sobre casos de uso
Usa include para factorizar parte de un flujo que
aparece en varios casos de uso.
Las extensiones pueden incluirse dentro del caso
de uso base como flujos alternativos en vez de
incluir casos de uso aparte.
El propio sistema puede disparar casos de uso.
No incluir casos de uso CRUD; casos de uso Crear
y Consulta si son relevantes.
No especificar casos de uso que incluyan detalles
de diseo de interfaces de usuario.

51
 Modelo Conceptual (o Dominio)

Representa el vocabulario del dominio:

ideas, conceptos, objetos
No son modelos de elementos software
Clases conceptuales
Clases no incluyen operaciones, slo
atributos
Atributos: nmeros o texto
Asociaciones entre clases
52
 Identificar Clases Conceptuales

Si se hace modelado del negocio:

Los objetos informacin, entrada y salida de las
actividades de los diagrama de proceso, representan
entidades y conceptos del dominio.
Una clase conceptual para cada informacin
relevante.
De la especificacin del diccionario se extraen:
atributos, asociaciones, restricciones
Se refina a lo largo de las iteraciones
Ms vale que sobren clases que falten
53
 Del Modelo del Negocio al Modelo
Conceptual

Objeto informacin Pedido (modelo del negocio)

Atributos: codigo, importe, estado, fechaTopeEntrega,..

Asociaciones: Pedido-Cliente y Pedido-Producto,..
Restricciones: fechaTopeEntrega > fechaRecepcion, ..

Tambin es posible identificar objetos que pasan por

varios estados (diagrama de estados preliminar)

54
 Identificar Clases Conceptuales

Si no se hace modelado del negocio:

Usar una lista de categoras de clases
Identificar nombres de las frases
Categoras de clases
Objetos fsicos
Especificaciones o descripciones de cosas
Lugares
Transacciones
Lneas de una transaccin

55
 Identificar Clases Conceptuales
Categoras de clases (continua)
Contenedores de cosas
Cosas en un contenedor
Dispositivos externos al sistema
Conceptos abstractos
Eventos
Procesos
Reglas y Polticas
Catlogos
Contratos, documentos legales
Instrumentos y servicios financieros
Manuales, documentos, trabajos, libros
56
 Modelo
Conceptual
Registra venta de

TPV 1

Descrita por Contiene

Catalogo Productos Producto
1 1..n
1
Usado-por Describe
0..1
0..n
0..n
Tienda Almacena 1
Item
Lineas Venta direccion
cantidad nombre 1 0..n
0..n
1..n 1
Contenidas en
1 1..n
capturada en Iniciado por
Venta TPV Gerente
1 1 1 1
1 1
1
iniciada por Registra Ventas
pagado por
1
1
1
Cliente Cajero
Pago
CriteriosSeleccion
1.. n
Curso
1..n nombre responsable
Requisit os Prof-Univers idad Prof-Empresa
duracion
fecha
numAlumnos
costeMatricula
Presupuesto
ingresos
gastos
Edicion Curso
Catalogo impartido Profesor
Cursos fecha
nombre
ao
1..n 1..n depto
id
1..n
Mat ricula
Alumno
1..n
nombre
Alumno dni
Expediente nombre nota
dni
Preincripcion
nota

Modelo Conceptual
AlumnoExt AlumnoUniv Gestin Cursos PE
 EspecificacinTarea
Cliente Pedido
1 1..n 1
1

1
Modelo Plantilla 1..n Tarea Puesto Produccin
1 1 1..n 1
1 1

Propio EnCatalogo 1
OrdenTarea
0..n

LineaMaterial

Material

Modelo conceptual Fabricacin bajo demanda

 Identificar Asociaciones

Se incluyen aquellas:
para la que el conocimiento de la relacin deba
mantenerse algn tiempo
derivadas de la Lista de Asociaciones
Lista de Asociaciones
A es parte fsica de B
A es parte lgica de B
A est fsicamente contenida en B
A est lgicamente contenida en B
A es una descripcin de B

60
 Identificar Asociaciones

Lista de Asociaciones (continua)

A es una lnea de una transaccin o informe B
A es conocido/registrado/informado/capturado en B
A es miembro de B
A es una subunidad organizacional de B
A usa o maneja B
A comunica con B
A est relacionado a una transaccin B
A es el siguiente a B
A es propiedad de B
A es un evento relacionado con B

61
 Identificar Asociaciones

Encontrar clases conceptuales es ms importante que

encontrar asociaciones. Se debe dedicar ms tiempo a
encontrar clases conceptuales que asociaciones

Centrarse en las asociaciones necesita-conocer

Muchas asociaciones dificultan la comprensin de los
diagramas
Evitar asociaciones redundantes
En la implementacin se notar que falta o sobra alguna
asociacin

62
 Asociaciones en TPV

A es parte fsica de B
TPV-Caja
A es parte lgica de B
LineaVenta-Venta
A est fsicamente contenida en B
Item-Tienda, TPV-Tienda
A est lgicamente contenida en B
EspecificacionProducto-CatalogoProductos
A es una descripcin de B
EspecificacionProducto-Item

63
 Asociaciones en TPV
A es una lnea de una transaccin o informe B
LineaVenta-Venta
A es conocido/registrado/informado/capturado en B
Venta-TPV
A es miembro de B
Cajero-Tienda
A usa o maneja B
Cajero-TPV, Gerente-TPV
A comunica con B
Cliente-Cajero
A est relacionado con una transaccin B
Cliente-Pago, Cajero-Pago
A es el siguiente a B
LineaVenta-LineaVenta
A es propiedad de B
TPV-Tienda
64
 Atributos
Son valores de tipos de datos: Identidad no tiene sentido
Tipos Primitivos: Boolean, Date, Numero, Time, String
Tipos no primitivos: Dinero, Direcciones, Colores, Nmero
Tlfno, Nmero Seguridad Social, DNI, Cdigo de Producto
Universal, Cdigo Postal,..
Tipos no primitivos se deben modelar como clases si:
Estn formados por varias partes
Son aplicables operaciones
Tiene otros atributos
Es una cantidad con una unidad
No utilizar atributos como claves ajenas

65
 Documentos de Anlisis Requisitos

Visin
Define visin del producto de las personas
involucradas, en trminos de sus necesidades y
caractersticas.
Casos de Uso
Especificacin Complementaria
Captura otros requisitos
Glosario
Captura trminos y definiciones

66
 Especificacin Complementaria
Funcionalidad
Abarca varios casos de uso
Ej. Almacenar informacin errores, Cualquier uso requiere
autenticacin de usuario
Requisitos No Funcionales (Atributos de calidad)
Usabilidad, Mantenimiento, Adaptacin, Fiabilidad, Rendimiento
Restricciones Implementacin (hardware, software, desarrollo)
Componentes comprados y free open source
Interfaces
Reglas de Negocio (Ej. Reglas de descuento, Clculo impuestos)
Cuestiones Legales
Cuestiones sobre el entorno fsico y operacionales
Informacin en dominios relacionados

67
 Visin
Oportunidad
Definicin del problema
Alternativas
Descripcin personal involucrado (stakeholder)
Objetivos usuario
Perspectiva del producto
Beneficios del producto
Lista de caractersticas del producto
Coste y precio
Otros requisitos y restricciones

68
 Lista de Caractersticas del Sistema

Alguna funcionalidad no puede ser asignada

a un caso de uso:
El sistema debe hacer transacciones con sistemas
externos de inventario, contabilidad y clculo de
impuestos
Para algunas aplicaciones conviene ms una
lista de caractersticas que casos de uso
Ej. Servidor de aplicacin

69
 Qu hacemos primero?

1. Escribir un borrador poco elaborado de la Visin

en la Etapa Inicial
2. Identificar objetivos del usuario y casos de uso
para ellos
3. Escribir algunos casos de uso y comenzar
Especificacin Complementaria
4. Refinar Visin

70
 Elaboracin de Requisitos y Visin
Cundo?
Etapa Inicial, un poco
Modelado de requisitos en cada iteracin
Dnde?
Inicio en talleres de requisitos, se completa despus
Quin?
Analista de sistemas, Arquitecto Software, Usuarios
Cmo?
Herramientas de requisitos web-enabled integradas
con un procesador de texto

71
 Casos de uso e iteraciones
Asignar prioridad a casos de uso
Escribir casos de uso en su forma expandida
Asignar casos de uso a iteraciones.
Varias versiones de un caso de uso complejo,
para aadir complejidad de modo incremental.
Necesidad de comunicacin con el usuario
Al final un caso de uso esencial se transforma
en su forma concreta.

72
 Iteraciones
Dirigidas por el riesgo
Asociar a cada caso de uso un nivel de riesgo
e importancia para el negocio
Comenzar pronto con la programacin
Realizar pruebas
Rpida retroalimentacin
Se obtiene la arquitectura en las primeras
iteraciones

73
 Prototipo Inicial

Prototipo desechable
Fcil de construir con herramientas visuales.
Sirve para validar los requisitos: analista y
usuarios llegan a un acuerdo sobre la
funcionalidad y vocabulario.
Utilizar los casos de uso.
Incluye las interfaces de usuario

74
 Contenidos

Introduccin
Modelado del Negocio
Modelado de Requisitos
Modelado del Anlisis
Patrones GRASP
Modelado del Diseo
Casos prcticos

75
 Modelo del anlisis
Objetivo:
A partir de los casos de uso obtener el diseo
preliminar del sistema que deber ser
refinado en el modelo del diseo.
Nivel de abstraccin ms alto que en el
diseo. Visin ideal del sistema.
Se define una arquitectura del sistema.

76
 Modelo del anlisis
Para cada caso de uso se define un
diagrama de secuencia del sistema que
muestra los eventos que un actor genera
durante la interaccin con el sistema (caja
negra)
Cada evento da origen a una operacin del
sistema
El efecto de las operaciones se describen
mediante contratos especificados mediante
una plantilla (opcional) .
77
 Modelo del anlisis
Para cada operacin del sistema se define
una colaboracin (diagrama de interaccin)
que muestra cmo deben colaborar los objetos
para satisfacer la postcondicin expresada en el
contrato de dicha operacin.
Disear las colaboraciones, asignando
responsabilidades a las clases. Utilizaremos
patrones GRASP (luego patrones de diseo).
Crear el modelo de clases a partir del modelo
conceptual, conforme se definen las
colaboraciones
78
 Cajero Realizar Venta Cliente

:Sistema

: Cajero
crearNuevaVenta
Operacin
* introducirItem(upc,cantidad)
Operacin
finalizarVenta()
Operacin
crearPago(cantidad)

CONTRATOS
 Diagrama de Secuencia del Sistema
(Caso de Uso Realizar Venta)

:Sistema
: Cajero
1. Cliente llega al TPV con crearNuevaVenta()
item
2. Cajero inicia venta
* introducirItem (CUP, cantidad)
3. Cajero introduce id item
4. Sistema registra lnea de
finalizarVenta ()
venta y presenta parcial Operaciones
del sistema

Cajero repite pasos 3 y 4 crearPago()

hasta que acaba

5. Sistema presenta total

6. Cajero requiere pago
7. ...
eventos del
sistema
 Contratos

Descripcin detallada del comportamiento del

sistema en trminos de cambios de estado a los
objetos en el Modelo Conceptual, tras la ejecucin
de una operacin del sistema.
Definicin basada en pre y postcondiciones
Las postcondiciones indican
Creacin y Eliminacin de objetos
Creacin y Eliminacin de asociaciones
Modificacin de atributos

81
 Contratos

Las postcondiciones sern incompletas y se

descubrirn detalles en el diseo.
Escribimos las postcondiciones a partir del
modelo conceptual.

Son redundantes los contratos con los

casos de uso?

82
 Contratos

tiles cuando hay mucha complejidad y la

precisin es un valor aadido
Normalmente no son necesarios, si un
equipo escribe un contrato para cada caso de uso
es una seal de unos casos de uso muy pobres o
falta de colaboracin con los expertos o que les
gusta escribir documentacin innecesaria
En la prctica la mayora de detalles se pueden
inferir de los casos de uso de modo obvio,
aunque obvio es un concepto muy escurridizo.

83
 Contratos
1. Identificar operaciones del sistema en DSS
2. Construir un contrato para operaciones
complejas y quiz sutiles en sus resultados, o
que no estn claras en el caso de uso.
3. Describir postcondiciones
Creacin/Eliminacin de instancias
Creacin/Eliminacin de asociaciones
Modificacin de atributos
No olvidar crear asociaciones!
Se puede usar OCL
84
 Plantilla de un Contrato

Nombre operacin Signatura de la operacin

Referencias Casos de uso en los que puede tener lugar
cruzadas esta operacin
(opcional)
Precondiciones Suposiciones relevantes sobre el estado del
sistema o de objetos del modelo conceptual,
antes de ejecutar la operacin. Suposiciones
no triviales
Postcondiciones Estado de objetos del dominio despus de que
se complete la operacin

85
 Contrato IntroducirItem
Nombre: introducirItem (itemID: itemID, cantidad: integer)
Referencias Cruzadas: Registrar Venta
Precondiciones: Hay una venta en curso
Postcondiciones:
- Se cre una instancia lv de LineaVenta
- Se asoci lv a la venta en curso v
- Se asign cantidad a lv.cantidad
- lv se asoci a una EspecificacinProducto segn itemID

86
 Colaboracin

Diagramas de secuencia o colaboracin

Crear estos diagramas es una actividad de
AOO/DOO muy creativa.
Diseo de colaboraciones es la parte ms difcil.
Punto de partida para la programacin.
Crear diagramas en parejas.
Crear modelo de clases de anlisis en paralelo.

87
 Diagrama de Colaboracin
2: [nuev venta] crear()

1: IntroducirProducto(cup, cant) 6: AddLineaVenta(esp, cant)

GUI : TPV : Vent a

4: esp:= especificacion(cup)
7: crear(esp,cant)
3: crear()
: Catalogo 8: add(lv)
Productos

lv : Lineas
5: esp:= find(cup) Venta

: Lineas
Venta

:
Product o
 Modelo de clases del anlisis
El modelo de clases del anlisis se crea a partir
del modelo conceptual.
Se aade una clase por cada tipo de objeto del
dominio que participa en la colaboracin.
Se aaden atributos segn los contratos.
Se aaden mtodos segn las colaboraciones.
Para aquellas clases con objetos con
comportamiento dependiente del estado, se
construye una mquina de estados:
Dispositivos, Controladores, Ventanas, etc.

89
 Modelo del anlisis
En la primera iteracin, en esta fase se definen
los subsistemas.
En el modelo del diseo se refinarn las
colaboraciones del anlisis para aadir aspectos
relacionados con la plataforma, patrones de
diseo, etc.

90
 Contenidos
Introduccin

Modelado del Negocio

Modelado de Requisitos
Modelado del Anlisis
Patrones GRASP
Modelado del Diseo
Casos prcticos

91
 Patrones GRASP
Describen los principios bsicos de asignacin
de responsabilidades a clases.
Distribuir responsabilidades en la parte ms
difcil del diseo OO. Consume la mayor parte
del tiempo.
Patrones GRASP:
Experto Creador
Bajo Acoplamiento Alta Cohesin
Controlador Polimorfismo
Indireccin Variaciones Protegidas
92
 Responsabilidades y Mtodos
Contrato u obligacin de una clase.
Dos categoras:
Conocer
datos encapsulados privados
existencia de objetos conectados
datos derivados o calculados
Hacer
Algo l mismo, como crear un objeto o realizar un clculo
Iniciar una accin en otros objetos
Controlar y coordinar actividades en otros objetos

93
 Responsabilidades y Mtodos
Responsabilidades conocer se pueden inferir de
las asociaciones y atributos del modelo
conceptual.
Puede asignarse a varias clases y mtodos
dependiendo de su granularidad.
Una responsabilidad se implementa mediante uno
o ms mtodos.
Diagramas de interaccin muestran elecciones en
la asignacin de responsabilidades.

94
 Experto
Cmo se asignan responsabilidades?
Asignar una responsabilidad a la clase que
tiene la informacin necesaria para
cumplimentarla
Heursticas relacionadas
Distribuir responsabilidades de forma homognea
No crear clases dios
Beneficios
Se conserva encapsulacin: Bajo acoplamiento
Alta Cohesin: clases ms ligeras
95
 Ejemplo 1
Quin es el responsable de conocer el total de
una venta?

Venta contiene LineaVenta

fecha
cantidad
nota
1..1 1..*
1
Descrita por

0..*
Producto
descripcion
precio
codigo

96
 Ejemplo 1
Quin es el responsable de conocer el total de
una venta?

: Venta : LineaVenta : Producto

t:=total()
* st:=subtotal()
p:=getPrecio()

97
 Ejemplo 2
Quin es el responsable de conocer todos los
mensajes recibidos entre dos fechas?

1: mensajesPeriodo(f1,f2) 2: * mensajesPeriodo(f1, f2)

:LectorCorreo :Buzon :Carpeta

3: * enFecha(f1,f2)

:Mensaje

98
 Participante

Ejemplo 3
nombre
apellidos
numID
domicilio
direccionEnv io
telef ono
reputacion

Subastas por internet

Pa goAnunc io +p

+pa +puja Adjudicacion

PujaOrdinaria
+pc datosTarjeta
estado +as
+art
PagoCuot a

+as

+pujas
+adjudicaciones
AnuncioSubasta
EdicionSubasta pv pRecomend
+articulos ArticuloConcreto
idEdici on pujaMinima
cuota codArticulo
f echaI ni cio +anuncios +es
f echaCi erre gastosEnv io
es tado plazo
f ormaPago
anticipo
 Ejemplo 3
Quin es el responsable de obtener la puja
ganadora?

1: cerrarEdicionSubasta(es)

:
ControladorAnuncios

: Sistema

2: ce rra r() 5: obtenerAdjudicacion()

7: adj:= crearAdjudicacion(this, pg,a)

4: * cerrar()
: Anun ci oSub asta : Edici on Su basta as : :
AnuncioSubasta Ca talogoAd judi cacio nes
3: * a s : = ge t()

6: pg := g et()
pujas :
Puj aOrdin aria
 Creador
Quin es responsable de crear una
nueva instancia de una cierta clase?

Asignar a la clase B la responsabilidad de

crear instancias de una clase A si:
B es una agregacin de objetos de A
B contiene objetos de A
B registra instancias de A
B hace un uso especfico de los objetos de A
B proporciona los datos de inicializacin necesarios
para crear un objeto de A

101
 Creador
Quin debera crear una instancia de la clase
LineaVenta?

Una instancia de la clase Venta es una agregacin de

instancias de la clase LineaVenta

Venta incluir crearLineaVenta(int cantidad)

Beneficios:
Bajo acoplamiento

102
Ejemplo Quin debera crear
: CatalogoSubastas
una instancia de puja?
2: as := getSubasta(numAnunci o)

1: pujarAnuncio(partID, numAnuncio, valorPuja, datosTarjeta)

4: p := getParticipante(partID)
: : CatalogoParticipantes
ControladorPujas

: Pujador

6: po := crearPuja(p, valorPuja, datosTarjeta)

7: numPujas := comprobarPujas(p) 9: numSerie := generarNumSerie()

8: [numPujas < 3] po := crear(as, p, valorPuja, datosTarjeta)

as : po :
AnuncioSubasta PujaOrdinaria

10: add(po)

puj as :
PujaOrdinaria
 Bajo Acoplamiento
Cmo reducir las dependencias entre
clases?

Asignar responsabilidad de modo que se

consiga un bajo acoplamiento

Es un patrn evaluativo
No considerarlo de forma independiente, sino
junto a los patrones Experto y Alta Cohesin.
Beneficios: Facilita i) reutilizacin, ii)
comprensin de las clases y iii) mantenimiento
104
 Tipos de dependencias
Existe acoplamiento entre una clase A y otra B
si:

i) A posee un atributo de tipo B

ii) A tiene un mtodo con un parmetro, una variable
local o devuelve un valor de tipo B
iii) A es subclase directa o indirecta de B
iv) A implementa la interfaz B (Java)

105
 Ejemplo

:GUI : TPV p: Pago :Venta

efectuarPago()
crear()

agregarPago(p)

106
 Ejemplo

:GUI : TPV : Venta :Pago

efectuarPago()
efectuarPago()
crear()

107
 Alta Cohesin
Canto estn de relacionadas las
responsabilidades de una clase?
Asignar una responsabilidad de modo que la
cohesin siga siendo alta

Baja Cohesin: Clases con responsabilidades

que deberan haber delegado. Son clases
dios. Difciles de comprender, reutilizar,
mantener.
Ejemplo anterior: En el primer caso TPV tendra
ms operaciones, mejor delegar. 108
 Alta Cohesin
Muy baja cohesin:
Clase AccesoBD-RPC
Mezcla de funcionalidad
Baja cohesin:
Clase AccesoBD
Muchos mtodos
Alta cohesin:
Clase AccesoBD + Familia de clases relacionada
Cohesin moderada:
Clase Empresa: conoce empleados e informacin
financiera
109
 Alta Cohesin
Una clase con alta cohesin no tiene muchos
mtodos, que estn muy relacionados
funcionalmente, y no realiza mucho trabajo.
Colabora con otras clases.

Beneficios
Mejora reutilizacin
Clases ms claras, se comprenden mejor
Mejora mantenimiento

110
 Controlador

Quin se encarga de atender los

eventos del sistema

Asignar responsabilidad de manejar eventos

externos a un controlador:
i) el sistema global, dispositivo o subsistema
ii) un manejador de los eventos de un caso
de uso
El mismo controlador para todos los eventos de
un mismo caso de uso.
111
 Controlador
Cualquier arquitectura distingue entre capa
presentacin y capa del dominio.
Las clases de la interfaz (capa presentacin) no
deben encargarse de realizar las tareas
asociadas a un evento. Deben delegarlas a un
controlador.
Separar interfaz de la lgica de aplicacin.
Las operaciones del sistema en la capa del
dominio.

112
 Controlador
Un controlador es un objeto que no pertenece
a la capa de presentacin, se encarga de
recibir y manejar un evento del sistema
procedente normalmente de una interfaz
grfica.
Una clase controlador incluye un mtodo para
cada operacin del sistema que maneja.
Controlador fachada vs. Controlador caso de
uso

113
 Controlador
Cundo debemos escoger un controlador de
caso de uso ?
Cuando con las otras alternativas obtenemos
controladores saturados
Es posible llevar el estado de la sesin
En el Proceso Unificado se distingue entre:
objetos entidad (dominio)
objetos control (controladores)
objetos frontera (interfaces GUI)

114
 Controlador
Objeto Entidad
Alumno

Objeto Control
Matriculacion

Objeto Frontera
GUIMatricula

115
 Ejemplocontrolador

:AppletTPV :TPV :Venta

introItem introItem(cant,cod)
crearLineaVenta(cant,cod)

evento

Acoplamiento adecuado de la capa presentacin con

la capa del dominio
 Ejemplo

:AppletTPV :Venta

introProd crearLineaVenta(cant,cod)

evento

Acoplamiento inadecuado de la capa presentacin

con la capa del dominio
117
 Controlador

Dado el evento Introducir tem, tendramos

varios posibles controladores:

i) TPV, ii) Tienda, iii) Manejador Compra

Beneficios de un controlador:
Favorece la reutilizacin
Posibilidad de capturar informacin sobre el estado
de una sesin
118
 Polimorfismo

Cmo manejar las alternativas basadas en el

tipo? Cmo crear componentes software
conectables (pluggable)?

Cuando las alternativas o comportamiento

relacionado varan segn el tipo asigne la
responsabilidad para el comportamiento a los tipos
para los que vara el comportamiento.

119
 Polimorfismo
No realizar anlisis de casos de uso basado en
el tipo de los objetos.

if tipoPago = Cheque then autorizarPagoCheque

else if tipoPago = Efectivo then autorizarPagoEfectivo
else if tipoPago = Tarjeta then autorizarPagoTarjeta
else if

Sustituir anlisis de casos de uso por jerarqua

de herencia.

120
 Polimorfismo

Pago
(from Clases)
fechaPago
cantidad

PagoCheque PagoTarjeta PagoEfectivo

121
 Polimorfismo
<<Interfac e>>
IAdaptadorCalcDeImpuestos

getImpuestos(v : Venta) : List of LineaImpuesto

AdaptadorMasterImpuestos AdaptadorImpuestosPro

Se aaden fcilmente las extensiones necesarias por nuevas

variaciones.
Los clientes no son afectados por nuevas implementaciones.
Usar si realmente el punto de variacin est motivado
122
 Indireccin

Cmo evitar un acoplamiento directo

entre dos clases?

Asignar la responsabilidad a un intermediario

que crea una indireccin

Ejemplo: Los adaptadores de clculo de impuestos

123
 Variaciones Protegidas (VP)

Cmo disear objetos, subsistemas y

sistemas de manera que las variaciones o
inestabilidades en estos elementos no
tengan un impacto indeseable sobre otros
elementos?

Identificar los puntos de variacin previstos y

asignar responsabilidades para crear una
interface alrededor de ellos

124
 Variaciones Protegidas (VP)

Ejemplo: Adaptadores de clculo de impuestos,

se combina indireccin con polimorfismo
VP es un principio fundamental que motiva la
mayora de mecanismos y patrones en
programacin y diseo destinados a
proporcionar flexibilidad y proteccin frente al
cambio.

125
 Variaciones Protegidas (VP)
Diseos dirigidos por datos
Lectura de cdigos, valores, nombres de ficheros,.., de una
fuente externa
Bsqueda de servicios
Servicios de nombres (JNDI de Java) o traders para obtener un
servicio (UDDI para servicios web)
Diseos dirigidos por un intrprete
Diseos reflexivos o de nivel meta
Usar la instropeccin
Acceso Uniforme
Principio de Sustitucin de Liskov

126
 Variaciones Protegidas (VP)

Diseos de ocultacin de la estructura

Principio no hables con extraos
VP se aplica a puntos de variacin y puntos de
evolucin.
VP es esencialmente lo mismo que los principios
Ocultacin de Informacin y Abierto-Cerrado

127
 No hables con extraos

No enviar mensajes sobre objetos indirectos,

sino sobre la instancia actual (self),
parmetros de mtodos, atributos de la
instancia actual y elementos de colecciones de
la instancia actual.

class A { class B {
B at1; C at2;
void met1() { C getAt2() {return at2;}
C obj = at1.getAt2(); }
obj.met2();}
}
128
 No hables con extraos
class A { class B {
B at1; C at2;
void met1(..) { C getAt2() {return at2;}
at1.met3;} void met3() {at2.met2;}
} }

class C {
void met2() {..}
}

Evitar recorrer largos caminos en la estructura de

objetos y entonces enviar un mensaje: diseo frgil

129
 No hables con extraos

class Registro {
private Venta venta;
public void metodoFragil () {
Dinero cantidad =
venta.getPago().getCantidadEntregada()
...
}
Dinero cantidad =
} venta.getCantidadEntregadaEnPago()

130
 Contenidos

Introduccin
Modelado del Negocio
Modelado de Requisitos
Modelado del Anlisis
Patrones GRASP
Modelado del Diseo
Casos prcticos

131
 Modelo del diseo

Objetivo:
Refinar el diseo del sistema del modelo del
anlisis considerando los requisitos no
funcionales y restricciones del entorno de
implementacin.

De manera iterativa se refina el modelo de

clases y las colaboraciones del anlisis hasta
obtener un diseo del sistema adecuado para
pasar a la implementacin.
132
 Cuestiones del diseo

Identificar clases (atributos y mtodos) e

interfaces en el modelo de clases del diseo
Establecer asociaciones entre clases.
Establecer navegabilidad para todas las
asociaciones.
Determinar visibilidad entre clases.
Incluir relaciones de dependencia entre clases.

133
 Cuestiones del diseo

Definicin de la arquitectura del sistema

Subsistemas: Paquetes
Patrones de diseo
Estructuras de datos
Diseo del interfaz de usuario
Manejo de la persistencia
Distribucin

134
Ejemplo 1: PetStore
Autenticacin

Usuario AltaUsuario

Casos de Uso
RealizarPedido
Nombre: RealizarPedido

Objetivo: Realizar una compra seleccionando y aadiendo productos al carro de compras, pudiendo cambiar el nmero de
unidades de un producto del carro y generando un pedido en el momento que el usuario decida finalizar la compra.
Actores: Usuario

Precondiciones: El usuario debe estar autenticado.

Flujo Principal:
1. A: Inicia compra
2. S: Crea un carro de compras nuevo asociado a la sesin del usuario.
3. A: El Usuario selecciona y aade un producto al carro de compras.
4. S: El sistema genera un nuevo tem en el carro de compras correspondiente al nuevo producto.
5. S: Actualiza el importe total del carro de compras.
6. A: El Usuario selecciona un producto del carro de compras e introduce el nmero de unidades del producto que
desea.
7. S: Actualiza el carro de compras reflejando las nuevas unidades. Si el nmero de unidades era cero, elimina el
producto del carro de compras.
8. A: El Usuario finaliza la compra.
9. A: El Usuario introduce los datos personales del pedido: direccin, localidad, provincia, cdigo postal.
10. A: El Usuario introduce los datos de la tarjeta de crdito: tipo de tarjeta, numero de tarjeta, mes y ao de caducidad.
11. S: Genera pedido de compras con sus correspondientes lneas de pedido.
Alternativas:
3.1) El producto se encuentra en el carro de compras.
3.1.1) S: El sistema incrementa en uno el nmero de unidades del producto del carro de compras.
9.1) La forma de pago es contra reembolso. En este caso, el usuario no tiene que introducir los datos de la tarjeta de
crdito.
9.2) La forma de pago es mediante transferencia bancaria. En este caso, el usuario no tiene que introducir los datos de la
tarjeta de crdito.
Comentarios:
 Modelo Conceptual
1 0..n 1 1..n
Usuario Pedido LineaItem

nombre numero unidades

nif nifCliente total
correo direccion
usuario localidad
1
clave provincia
codigoPostal
1 tipoTarjetaCredito
numeroTarjetaCredito
caducidadMes
caducidadYear
tipoPago
LineaItems
total
estado

1
1

1 0..n 1 1
CarroCompras ItemCarro Producto

precioTotal unidades nombre

items total numero
tamao descripcion
precio
categoria
origenFoto
Diagrama de Secuencia del Sistema para
Realizar Pedido

: Sistema
: Usuario

aadirItem(codigo)

cambiarUnidades(codigo,unidades)

cerrarPedido(nif,direcc,localidad,provincia,CP,tTarjeta,nTarjeta,cMes,cAo,tPago)
 Colaboracin AadirItem

: Usuario
1: aadirItem(codigo)
2: aadirItem(codigo)
11: recalcularTotal()
4: aadirItem(codigo)
3: [primer producto] crear()

: MostrarProductos : Aadir : CarroCompras 6: [!nuevoItem]incrementarUnidades()

10: [nuevoItem]put(codigo,i)

5: i:=getItemCarro(codigo) 7: [nuevoItem]p:=get(codigo) 9: [nuevoItem]i:=creaItem(p)

: ItemCarro : CatalagoProductos
i : ItemCarro
8: [nuevoItem]p:=buscar(codigo)

: Producto
 Diagrama de Clases (Struts y JDBC)
HttpServlet Action

EditarRegistroAction SalvarRegistroAction Most rarAnimalesAct ion AadirCarroAction ModificarCarroA ct ion EditarPedidoAc tion SalvarPedidoAction
ActionServlet LoginAction

Ext endedActionServlet ServiceImpl FachadaCarroCompras

IServicios

0..n 1 1..n 1 1 0..n 1

1
1 1
ActionForm
Usuario Pedido LineaItem Producto ItemCarro CarroCompras

nombre numero unidades nombre unidades precioTotal

nif nifCliente total numero t ot al items
correo direccion descripcion tam ao
usuario localidad precio
LoginForm ModificarCarroForm PedidoForm RegistroForm clave provincia categoria
codigoPostal origenFot o
tipoTarjetaCredito
numeroTarjetaCredito
caducidadMes
caducidadYear
t ipoPago
LineaItems DAOFactory
total
estado

JDBCDAOFactory
UsuarioDAO LineaItem DAO
ItemDAO PedidoDAO

JDBCUsuarioDAO JDBCLineaItemDAO
JDBCItemDAO JDBCPedidoDAO
 Colaboracin Aadir Item (Struts y JDBC)

1 : a a d i r It e m ( c o d i g o ) O b t ie n e O b t ie n e e l O t ie n e u n
A a d i r C a r r o A c ti o n A c t io n F o rw a rd C a rro C o m p ra s V O
a c c e d id o d e s d e J S P

: U s u a rio : M o s t ra rP ro d u c t o s
3 : a c a : = g e t A c t io n () 1 6 : a f: = fi n d F o r w a r d ( " s u c e s s " )

2 : p ro c e s s ()
1 5 : c c V O : = lis t a rC a rro C o m p ra s ()
4 : a f: = p e r fo r m ( ) 5 : a a d i r It e m ( c o d i g o )
1 7 : m o s t ra r()

: M o s t ra rC a rro : E x t e n d e d A c t i o n S e r vl e t a c a : A a d irC a rro A c t io n : S e r vi c e Im p l

1 4 : re c a lc u la r T o t a l( ) 6 : a a d i r It e m ( c o d i g o )

1 2 : [ n u e vo It e m ] i : = c r e a It e m ( p ) 8 : a a d i r It e m C a r r o ( c o d i g o )

1 0 : [ !n u e vo It e m ] i n c r e m e n t a r U n i d a d e s ( ) 7 : [ p rim e r p ro d u c t o ] c re a r()

H a c e u s o d e l p a t r n D A O
i : It e m C a r r o : C a rr o C o m p ra s p a ra re c u p e ra r e l p ro d u c t o : F a c h a d a C a rro C o m p ra s

1 3 : [n u e v o It e m ]p u t ( c o d ig o ,i )

9 : i : = g e t It e m C a r r o ( c o d i g o ) 1 1 : [ n u e vo It e m ] p : = r e c u p e r a r P r o d u c t o ( c o d i g o )

: It e m C a r r o
: P ro d u c t o
 Ejemplo 2: Caso de uso Realizar Venta
en sistema TPV

Resumen: Un cliente llega al TPV con un conjunto de artculos. El

Cajero registra los artculos y se genera un ticket. El cliente paga en
efectivo y recoge los artculos.
Actor Principal: Cajero
Personal Involucrado e Intereses:
Cajero: quiere entradas precisas, rpida y sin errores de pago
Compaa: quiere registrar transacciones y satisfacer clientes.
...
Precondicin: El cajero se ha identificado y autenticado
Postcondiciones: Se ha registrado la venta. Se ha
calculado el impuesto. Se ha actualizado contabilidad e
inventario...
 Caso de uso Realizar Venta
Flujo Bsico:
1. A: El cliente llega al TPV con los artculos.
2. A: El cajero inicia una nueva venta
3. A: El cajero introduce el identificador de cada artculo.
4. S: El sistema registra la lnea de venta y presenta descripcin del
artculo, precio y suma parcial.
El Cajero repite los pasos 3 y 4 hasta que se indique.
5. S: El Sistema presenta el total
6. A: El Cajero le dice al Cliente el total a pagar
7. S: El Cliente paga y el sistema gestiona el pago.
8. S: El Sistema registra la venta completa y actualiza Inventario.
9. S: El Sistema presenta recibo

143
 Caso de uso Realizar Venta
Extensiones (Flujos Alternativos):
3a. Identificador no vlido
1. El Sistema seala el error y rechaza la entrada
3-6a. El Cliente pide eliminar un artculo de la compra
1. El Cajero introduce identificador a eliminar
2. El sistema actualiza la suma
...
7a. Pago en efectivo
1. El Cajero introduce cantidad entregada por el cliente
2. El Sistema muestra cantidad a devolver
...
....

144
 Caso de uso Realizar Venta
Requisitos especiales:
- Interfaz de usuario con pantalla tctil en un monitor de pantalla
plana. El texto debe ser visible a un metro de distancia.
- Tiempo de respuesta para autorizacin de crdito de 30 sg. el 90%
de las veces
...
Lista de Tecnologa y Variaciones de Datos:
- El identificador podra ser cualquier esquema de cdigo UPC, EAN,..
- La entrada de informacin de la tarjeta se realiza mediante un lector
de tarjetas.
...
Cuestiones Pendientes:
- Explorar cuestiones de recuperacin de accesos a servicios remotos
- Qu adaptaciones son necesarias para diferentes negocios?

145
 Modelo
Conceptual
Registra venta de

Descrita por Contiene

Catalogo Productos Producto
1 1..n
1
Usado-por Describe
0..1
0..n
0..n
Tienda Almacena 1
Item
Lineas Venta direccion
cantidad nombre 1 0..n
0..n
1..n 1
Contenidas en
1 1..n
capturada en Iniciado por
Venta TPV Gerente
1 1 1 1
1 1
1
iniciada por Registra Ventas
pagado por
1
1
1
Cliente Cajero
Pago
 Cajero Realizar Venta Cliente

:Sistema

: Cajero
crearNuevaVenta
Operacin
* introducirItem(upc,cantidad)
Operacin
finalizarVenta()
Operacin
realizarPago(cantidad)

CONTRATOS
Operacin: crearVenta()
Caso de Uso: Realizar venta
Precondicin:
Postcondicin:
una instancia de Venta v fue creada
v se asoci con TPV
atributos de v fueron inicializados

1. crearVenta
: TPV

: Cajero

1.1. crear

1.1.1. crear
: Venta : LineaVenta
Operacin: introducirItem(itemID: itemID, cantidad: Dinero)
Caso de Uso: Realizar venta
Precondicin: se est procesando una venta
Postcondicin:
una instancia de LineaVenta lv fue creada
lv se asoci con la Venta actual
lv.cantidad = cantidad
lv se asoci con el Producto cuyo cdigo es itemID

1. introducirItem(cant, id) 1.2. crearLV( ) 1.2.1. lv:=crear( )

: TPV : Venta lv :
LineaVenta

: Cajero
1.1. p:= getProducto(id )
1.2.2. add(lv)

: CatalogoProducto
: LineaVenta

1.1.1. p:=get(id)

:
Producto
Operacin: finalizarVenta()
Caso de Uso: Realizar venta
Precondicin: se est procesando una venta
Postcondicin:
v.esCompleta = true, siendo v la venta actual

: TPV : Venta
: Cajero

1. finalizarVenta( )
1.1. completar( )
El sistema presenta el total de la venta ms impuestos

public getTotal() {
int total = 0;
for each lv:LineaVenta
total = total + lv.getSubtotal;
return total;}

1. getTotal( )

1.1. * st:= getSubtotal( ) 1.1.1. pr:= getPrecio( )

: Venta : LineaVenta : Producto

{st = lv.cantidad + lv.producto.precio }

Operacin: crearPago(cantidad:Dinero)
Caso de Uso: Realizar venta
Precondicin: se est procesando una venta
Postcondicin:
una instancia de Pago p fue creada
p.cantidadEntregada = cantidad
p se asoci con la venta actual
se asoci la venta actual con Tienda (para registrarla)

1. realizarPago(cant ) 1.1. crearPago(cant )

: TPV v : Venta

: Cajero

1.1.1. crear( cant)

1.2. aadirVenta(v )

: Pago

: Tienda

1.2.1. add(v)

: Venta
 el sistema imprime el recibo con la cantidad a devolver

1.2. getTotal( )

1. getDevolucion( ) 1.1. getCantidad( )

:Cliente v : Venta p : Pago

dev = p.cantidad - v.getTotal

Operacin: Inicio
Postcondicin:
Una instancia de Tienda, TPV y CatalogoProductos fueron creadas.
Instancias de Producto son creadas y asociadas a
CatalogoProductos
Tienda se asocia a CatalogoProductos
Tienda se asocia a TPV
TPV se asocia a CatalogoProductos

: TPV

1.1.2. cargarProd( )

1.2. crear( )

1. crear( ) 1.1. crear( )

Raiz : Tienda : CatalogoProducto

1.1.1. crear( )
1.1.2.2. add(p)

1.1.2.1. crear( )
p:
Producto :
Producto
 Producto
precio CatalogoProducto
descripcion
id cargarProd()
1..n 1
getProducto()
getPrecio() 1
1 Usa
describe 1
1..n Tienda
LineaVenta
1 aadirVenta()
1..n 1
registra posee

1
0..n 1
Venta
TPV

completar() Captura
crearVenta()
crearLV()
finalizarVenta()
crearPago() 1 1
introducirItem()
getDevolucion()
realizarPago()
getTotal()
1
pagada
1
Pago
cantidad
Modelo de
getCantidad() Clases
public class Producto {
private itemID id;
private Dinero precio;
private String descripcion;

public Producto(ItemID id, Dinero precio, String desc) {

this.id = id;
this.precio = precio;
this.descripcion = desc;}
public ItemId getId() { return id; }
public Dinero getPrecio() { return precio; }
public String getDescripcion() { return descripcion; }
}
public class CatalogoProducto {
private Map productos = new HashMap ();

public CatalogoProductos () {
ItemId id1 = new ItemID(100);
ItemId id2 = new ItemID(200);
Dinero precio1 = new Dinero (3);
Dinero precio2 = new Dinero (5);
Producto p;
p:= new Producto (id1, precio1, producto 1);
productos.put(id1, p);) }
p = new Producto (id2, precio2, producto 2);
productos.put(id2, p);)
}

public Producto getProducto (ItemId id) { return (Producto) productos.get(id); }

}
public class TPV {
private CatalogoProducto catalogo;
private Venta venta;

public TPV(CatalogoProducto cp) { catalogo = cp; }

public void crearNuevaVenta () { venta = new Venta(); }
public void finalizarVenta () { venta.completar(); }
public void introducirItem (ItemId id, int cant) {
Producto p = catalogo.getProducto (id);
Venta.crearLineaVenta(p, cant); }
public void realizarPago() { venta.crearPago(cant) }
}

public class Pago {

private Dinero cantEntregada;

public Pago (Dinero cantidad) { cantEntregada = cantidad; }

public Dinero getCantEntregada () { return cantEntregada; }
}
public class Venta {
private List lineaVentas = new ArrayList();
private Date fecha = new Date();
private boolean esCompleta;
private Pago pago;

public Dinero getDevolucion() { return pago.getCantEntregada(). minus(getTotal() ); }

public void completar() { esCompleta = true; }
public void crearLineaVenta(Producto p, int cant) {
lineaVentas.add(new LineaVenta(p,cant)); }
public Dinero getTotal() {
Dinero total = new Dinero();
Iterator i = lineaVentas.iterator();
while (i.hasNext()) {
LineaVenta lv = (LineaVenta) i.next();
total.add(lv.getSubtotal()); }
return total;
}
public void crearPago (Dinero cantEntregada) { pago = new Pago(cantEntregada); }

}
public class LineaVenta {
private int cantidad;
private Producto producto;

public LineaVenta(Producto p, int cant) {

this.producto = p;
this.cantidad = cant; }
public Dinero getSubtotal () { return producto.getPrecio().times(cantidad); }
}

public class Tienda {

private CatalogoProducto catalogo;
private TPV tpv;

public TPV getTPV { return TPV; }

}
 Validacin del sistema

Utilizar los casos de uso.

Para cada caso de uso comprobar que el
sistema muestra el comportamiento esperado,
considerando el escenario principal y los
excepcionales o alternativos.
Considerar requisitos no funcionales.

160
 Programacin Prueba primero
Prctica promovida por XP
Ciclo escribo cdigo de prueba, escribo cdigo de
produccin, pruebo
Ventajas
Se escriben las pruebas!
Satisfaccin del programador: He superado la prueba!
Ayudan a comprender mejor las interfaces y
comportamiento
Verificacin de la correccin
No hay miedo a los cambios: existen cientos de pruebas
de unidad!
161
 Programacin Prueba primero
Antes de escribir el mtodo getTotal() en la clase
Venta, escribimos un mtodo de prueba de unidad en
una clase PruebaVenta que
Crea una venta
Le aade varias lneas de venta
Obtiene el total y comprueba si tiene el valor esperado
Luego escribimos el mtodo getTotal() y realizamos la
prueba.
Junit es un framework open source para pruebas de
unidad para cdigo Java (www.junit.org).

162
 Programacin Prueba primero
class PruebaVenta extends TestCase {
public void pruebaTotal() {
Dinero total = new Dinero (7.5);
Dinero precio = new Dinero (2.5);
ItemID id = new ItemId (1);
Producto p = new Producto (id, precio, producto 1);
Venta venta = new Venta ();
venta. crearLineaVenta(p,1);
venta. crearLineaVenta(p,2);

assertEquals(venta.getTotal(), total);
}
}

163
 Arquitectura de tres capas
Presentacin
Lgica de la Aplicacin
Almacenamiento

Principio de Separacin Modelo-Vista

Los objetos del modelo o dominio no conocen
directamente a los objetos de la vista o presentacin

164
 Separacin Modelo-Vista
Los objetos del modelo (dominio) no deben
conocer directamente a los objetos de la vista
(presentacin).
Las clases del dominio encapsulan la
informacin y el comportamiento relacionado
con la lgica de la aplicacin.
Las clases de la interfaz (ventanas) son
responsables de la entrada y salida,
capturando los eventos, pero no encapsulan
funcionalidad de la aplicacin.

165
 Separacin Modelo-Vista
Justificacin
Clases cohesivas
Permitir separar el desarrollo de las clases de la
vista y del dominio
Minimizar el impacto de los cambios en la interfaz
sobre las clases del modelo.
Facilitar conectar otras vistas a una capa del
dominio existente.
Permitir varias vistas simultneas sobre un mismo
modelo.
Permitir que la capa del modelo se ejecute de
manera independiente a la capa de presentacin.

166