Modelaje Con Uml

Anlisis y Diseo del Software Curso 2005/2006
Un proceso software basado en UML

Jess Garca Molina Departamento de Informtica y Sistemas Universidad de Murcia http://dis.um.es/~jmolina
Contenidos
Introduccin
Dimensiones de un mtodo Mtodos pesados vs. Desarrollo gil Un proceso simple
Modelado del Negocio Modelado de Requisitos Modelado del Anlisis Patrones GRASP Modelado del Diseo Casos Prcticos
2
Mtodo
Establece cmo abordar de un modo sistemtico la construccin de software. Se describe el problema y la solucin mediante un conjunto de modelos. Es difcil asegurar la calidad del software. No sustituye a la necesidad creativa. Lo ms importante son las personas.
3
Mtodo
Dimensin Tecnolgica
Conceptos, Notacin, Tcnicas y Herramientas
Dimensin Proceso
Conjunto de pasos a realizarse y resultados obtenidos en cada paso (entregables)
Dimensin Organizacin
Cmo organizar las personas para acomodar el proceso
Tecnologa
Conceptos
Qu conceptos soporta? Paradigma?
Notacin
Modelos soportados Representacin de los modelos Expresividad de la notacin Legibilidad de la notacin
Grfica, Especificaciones formales,
Agregacin, Generalizacin, Interfaces, Roles,
Tecnologa
Notacin
Sintaxis y Semntica bien definidas

Conexiones entre modelos Expresar la semntica de las propiedades de los elementos de un modelo Reglas para transformar y razonar sobre los modelos Crecimiento (Escalabilidad) El conjunto de modelos proporcionan una visin consistente y completa del sistema. Particionar en subsistemas Generacin de cdigo
6
Tecnologa
Conceptos
Orientacin a objetos Anlisis y Diseo estructurado
Notacin
Especificaciones formales Plantillas Diagramas
7
Proceso
Un proceso bien definido es necesario para desarrollar sistemas software de manera repetible y predecible Permite un negocio sostenible y que puede mejorar en cada nuevo proyecto, incrementando la eficiencia y productividad de la organizacin G. Booch
Proceso
Un proceso software debe indicar: la secuencia de actividades a realizar por el equipo de desarrollo: flujo de actividades los productos que deben crearse: qu y cundo una asignacin de tareas a cada miembro del equipo y al equipo como un todo heursticas los criterios para controlar el proceso
Proceso
Para qu contexto de desarrollo es apropiado?
Nuevo software, Reingeniera, Prototipado, Desarrollo de componentes, Lneas de producto,
En qu grado cubre el ciclo de vida?

Anlisis, Diseo, Implementacin, Pruebas,
10
Proceso
Basados en casos de uso Debe ser iterativo e incremental.
Conviene centrarse en los aspectos crticos en las primeras iteraciones para minimizar riesgos. Rpida retroalimentacin
Establecer un proceso marco: Cada empresa de desarrollo debe definir su propio proceso.
11
Organizacin
Software de alta calidad no puede producirse sin una organizacin adecuada. Reutilizacin Especializacin Trabajos y responsabilidades organizadas en una cadena de valor. Adecuar tareas a las capacidades del personal Mltiples facetas: Marketing, Ventas, Planificacin, Diseo, Produccin, etc.
12
Factora software Comprar antes que construir
Mtodo
TECNOLOGIA
(OO, UML, MagicDraw)
ORGANIZACION
(ATICA-UMU)
PROCESO
(XP)
13
Mtodo completo
Adems de tecnologa, proceso y organizacin: Guas para la gestin y planificacin del proyecto Guas de estimacin de costes Guas para elaboracin de los entregables Mtricas Polticas y procesos para asegurar calidad del software Descripciones de roles Ejemplos elaborados de aplicacin y ejercicios para el aprendizaje Tcnicas para adecuacin del mtodo a contextos
14
Mtodos Pesados y giles

Proceso Unificado, UP
Marco para definir procesos
Rational Unified Process, RUP

Intento de convertirse en un estndar de facto
Movimiento de la Extreme Programming, XP

Rechazo a procesos pesados como RUP
Movimiento del Desarrollo Agil

Mtodos giles y Modelado gil
15
Mtodos Pesados y Agiles

Proceso pesado
Muchos artefactos creados en un ambiente burocrtico Muchas actividades realizadas con rigidez y control Planificacin detallada a largo plazo Predictivos en vez de adaptativos
16
El Proceso Unificado (RUP)
Extreme Programming, XP
Valores
Comunicacin Simplicidad Realimentacin Valenta
Prcticas
El juego de la planificacin Versiones pequeas Metfora Diseo simple Pruebas Recodificacin (Refactoring) Programacin por parejas Cdigo colectivo Integraciones continuas Semanas de 40 horas Cliente en el equipo Estndares de codificacin
Principios
Aceptar cambios Asumir Simplicidad Rpida Realimentacin Cambio incremental Trabajo de calidad
Manifiesto para el Desarrollo de
Software gil
Nosotros estamos descubriendo mejores formas de desarrollar software hacindolo y ayudando a hacerlo. A travs de nuestro trabajo hemos llegado a apreciar:
- Personas e interacciones - Trabajar con el software
antes que procesos y herramientas antes que documentacin - Colaborar con el cliente antes que la negociacin de un contrato - Responder al cambio antes que seguir un plan
Esto es, aunque reconocemos que los tems de la derecha tienen valor, nosotros valoramos ms los tems de la izquierda.
19
Principios detrs del Manifiesto gil

Satisfacer al cliente es lo principal Aceptar los cambios Versiones pequeas Integrar a la gente del negocio Motivacin del equipo La conversacin cara a cara es el medio ms eficiente de comunicacin Software funcionando es la mejor medida de progreso. Mantener velocidad constante por parte de todos Atencin continua a la excelencia tcnica y buenos diseos mejorar la agilidad. Simplicidad es esencial Las mejores arquitecturas, requisitos y diseos surgen de equipos que se auto-organizan. A intervalos regulares, el equipo refleja cmo llegar a ser ms efectivo.
http://www.agilealliance.com
20
10
Mtodos giles
Iteraciones corta de duracin fijada. Refinamiento evolutivo de planificacin, requisitos y diseo. Simplicidad, ligereza, comunicacin. Ejemplos: Scrum, XP, DSDM,..
21
Modelado gil (http://www.agilemodeling.com)

El propsito de modelar es principalmente comprender y comunicar no documentar. No hay que modelar todo el diseo software Se define y muestra cmo poner en prctica un conjunto de valores, principios y prcticas para un modelado efectivo y ligero. Se explora como aplicar las tcnicas de modelado en proyectos con enfoque gil (XP) Explorar cmo mejorar el modelado en procesos predictivos como el RUP
22
11
Modelado gil (http://www.agilemodeling.com)

Utilizar herramientas simples: pizarras y fotografas Herramientas CASE de modelado son complementarias
Integrada con un IDE y con ingeniera inversa
Programar por pares Modelo estructural y de comportamiento en paralelo No complicarse la vida con UML Los modelos sern imprecisos e incompletos Lo importante es el diseo OO Dedicar al modelado unas pocas horas (un da a lo sumo) al inicio de la iteracin.
23
Tendencia
Enfoque industrial para la produccin de software: Capacidad de producir software de alta calidad a bajo coste Automatizacin Estndares Reutilizacin: Componentes, Patrones, Frameworks Configurar soluciones Nuevo paradigma de desarrollo dirigido por modelos (por ejemplo MDA)
24
12
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 UP
Dirigido por casos de usos. Desarrollo iterativo e incremental
Conforma con modelado gil

25
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
26
13
Etapas del Proceso

Modelado del Negocio Modelado de Requisitos Modelado del Anlisis Modelado del Diseo Implementacin Pruebas
27
M o d e lo d e C a s o s de Uso
M o d e lo d e D o m in io
D ia g ra m a s d e P ro ce s o
M o d e l o d e R e q u is i t o s
M o d e lo d e 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 ) (un o po r caso d e u so)
C o n tra tos ( u n o p o r i n t e r a c c i n )
D ia g ra m a d e 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 l o d e A n l is is
A r q u ite c tu ra d e l S is te m a P a q u e te s P a tro n e s d e D is e o E s tru c tu ra s d e D a to s D is e o G U I P e r s is te n c ia D is t r ib u c i n M o d e lo d e l D is e o
El Proceso
14
Etapa Inicial
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?
29
Etapa Inicial
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
30
15
Contenidos
Introduccin Modelado del Negocio Modelado de Requisitos Modelado del Anlisis Patrones GRASP Modelado del Diseo Casos Prcticos
31
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?
32
16
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
33
Procesos y Reglas del Negocio

Procesos del Negocio
RN1
tarea2 tarea1 tarea3 tarea4
datos
RN3
tarea5
Reglas del Negocio
RN2
Determinan polticas y estructura de la informacin
34
17
Ejemplo
Empresa que fabrica productos bajo demanda
Objetivos Estratgicos Satisfacer pedido de cliente Incrementar las ventas Reducir tiempo de fabricacin ...
Subobjetivos Procesos del Negocio
Atender pedidos
Fabricar productos
Gestionar almacn
Realizar pedidos a proveedores
Casos de Uso del Negocio
Atender pedidos
Fabricar productos
Gestionar almacn
Generar pedidos a proveedor
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 Identificar los roles implicados en los diferentes procesos del negocio
36
18
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.
37
Diagrama Casos de Uso del Negocio

Cliente Registrar Pedido
Fabricar P roducto
Gestin Almacen
Pedidos Proveedores
Proveedor
38
19
Diagrama Casos de Uso del Negocio
Operario Puesto
Fabricar Producto
Jefe Tcnico
Worker
Gestin Almacen Operario Almacen
39
Casos de Uso del Negocio

Descripcin Textual Plantillas Diagramas Diagrama de casos de uso del negocio Diagramas de roles
Diagrama de clases (clases son roles) Diagrama de secuencia (objetos son instancias de roles)
Diagramas de Proceso
Diagrama de actividad
40
20
Ejemplo de Caso de Uso del Negocio

Registrar Pedido
1. 2. El cliente realiza un pedido que incluir la fecha del pedido, los datos del cliente y los productos solicitados. 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.
41
Plantilla Caso de Uso del Negocio

Proceso de Negocio Objetivo Descripcin
Registrar Pedido Registrar pedido de un cliente 1. El cliente enva una orden de pedido, que debe incluir la fecha de solicitud, datos del 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. 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.
Rol Externo
Roles Internos
Prioridad Riesgos Posibilidades Tiempo Ejec. Coste Ejec.
Bsico ... ... ... ...
21
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)
43
Workers en Registrar Pedido
1..n Cliente
1 Comercial
1..5
1 Jefe Tcnic o 1
1..3
Jefe P roducc in
22
Escenario Registrar Pedido
: Comercial cursar pedido
: Cliente
: Jefe Tcnico
: Jefe Produccin
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
46
23
Cliente
Comercial
Jefe Tcnico
Puesto Produccion
Operarario Alm acen
Realizar Pedido
Cursar Pedido
Actividad compleja: otro diagrama

Analizar Viabilidad
es propio?
es viable? Rechazar Pedido no Crear P lantilla
si
Diagrama de Proceso
Confirmar Pedido Realizar tarea
Pedir Material Ent regar Contenedor
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.
48
24
Diccionario
... Objeto de Informacin: Pedido
Atributos Codigo de pedido Fecha de solicitud Fecha lmite de entrega Conjunto de {Producto} Cliente Importe total Estado Actual Restricciones - El cdigo de pedido identificar unvocamente el pedido, y ser asignado automticamente por el sistema - La fecha de solicitud ser anterior a la fecha lmite de entrega. - Un pedido contendr al menos un producto; no existe lmite mximo de productos. - Un pedido siempre ser solicitado por uno y solamente un cliente. - El importe total ser calculado a partir del precio de cada producto pedido. Clase del Dominio : - por especificar -
...
Actividad: Ordenar fabricacion
Origen: Analizar viabilidad Agente: Jefe Tecnico Precondiciones: La fabricacion de todos los productos
pedidos es viable. Existe una plantilla de fabricacin para cada uno de dichos productos. Postcondiciones: Ha sido creada una orden de trabajo para cada producto, con estado pendiente, y ha sido enviada al jefe de produccin para su planificacin.
Caso de Uso : - por especificar-
Actividad: Notificar aceptacion de pedido

Origen: Analizar viabilidad Agente: Comercial Precondiciones: La fabricacin de todos los productos
pedidos es viable.
Postcondiciones: Se ha comunicad al cliente la aceptacin de su pedido. El estado del pedido es aceptado. Caso de Uso : - por especificar-
Trazabilidad
Especificacin de las actividades

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.
50
25
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.
51
BPMN
Business Process Modeling Notation
Notacin estndar de OMG (www.bpmn.org)
Notacin grfica. Legible y posibilidad de generacin de cdigo ejecutable BPEL. Define un Diagrama de Proceso de Negocio (BPD) basado en la tcnica de diagramas de flujo adaptada al modelado de procesos de negocio. Herramientas de gestin de procesos de negocio: Intalio, BizTalk, BizAgi, ...
52
26
Ejemplo BPMN
53
Contenidos
54
27
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.
55
Tipos de Requisitos
Funcionales No Funcionales
Usabilidad Fiabilidad Rendimiento Adaptabilidad, Mantenimiento, Configurable Implementacin: lenguajes, herramientas,.. GUI Legales
56
28
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.
57
Del modelo de negocio al modelo de requisitos

De los diagramas de proceso...
rol
actor actividad
Caso de Uso
objeto
Concepto del Dominio
58
29
Realiz ar Pedido
Realizar Tarea
Comercial
Confirmar Pedido
Pedir Material
Puesto Produccion
Analizar Viabilidad
Retirar Cont enedor
Jefe Tcnico Entregar Contenedor Crear Plantilla
Diagrama de Casos de Uso Registrar Pedido

Recoger Contenedor
Operario Almac en
Granularidad
Casos de uso del negocio
Procesos de Negocio: Objetivo estratgico de la empresa Ej. Vender productos
Casos de uso del sistema

Objetivo de un usuario Ej. Realizar una compra
Casos de uso de inclusin

Forman parte de otro, son como subfunciones Ej. Buscar, Validar, Login
60
30
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

61
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
62
31
Ejemplo: Terminal Punto de Venta
Realizar Venta
Cajero
Cliente
Registrar Productos
Casos de Uso
Gerente Inicia
Gestion Usuarios
Administrador Sistema
63
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...
64
32

Flujo Bsico:
1. El cliente llega al TPV con los artculos. 2. El cajero inicia una nueva venta 3. El cajero introduce el identificador de cada artculo. 4. 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. El Sistema presenta el total 6. El Cajero le dice al Cliente el total a pagar 7. El Cliente paga y el sistema gestiona el pago. 8. El Sistema registra la venta completa y actualiza Inventario. 9. El Sistema presenta recibo
65

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

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:

3a. El identificador podra ser cualquier esquema de cdigo UPC, EAN,.. 7a. 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?
67
Diagramas de estado de casos de uso

int roducirArt iculo
Esperando Venta
crearNuevaVenta
Introduciendo Articulos
finaliz arVent a
EsperandoPago realizarPagoEnEfectivo
Autorizando Pago
realizarPagoACredito
Procesar Venta
realizarPagoConCheque
68
34
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)
69
Recomendaciones sobre casos de uso

Define bien los lmites del 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
70
35
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.
71
Modelo Conceptual (o de 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
72
36
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
73
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)
74
37

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
75

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
76
38
Modelo Conceptual
Descrita por
Registra venta de
1 CatalogoProductos 1 1 0..1 Usado-por 0..n LineaVenta cantidad 1..n Contenidas en 1 Venta 1 1 1 pagado por 1 Pago iniciada por 1 Cliente capturada en 1 1 Registra Ventas 1 Cajero 1..n TPV 1 Iniciado por 1 Gerente 0..n Tienda direccion nombre 1 1 Almacena 0..n Contiene 1..n Describe 0..n 1 Item Producto
EspecificacinTarea Cliente 1 1..n 1 1 Modelo 1 1 Plantilla 1..n Tarea 1 1..n 1 1 Puesto Produccin Pedido 1
Propio
EnCatalogo
1 OrdenTarea 0..n LineaMaterial
Material
Modelo conceptual inicial
39
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
79
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 a B A comunica con B A est relacionado a una transaccin B A es el siguiente a B A es apropiado por B A es un evento relacionado con B
80
40
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
81
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
82
41
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 a B
Cajero-TPV, Gerente-TPV
A comunica con B
Cliente-Cajero
A est relacionado a una transaccin B

Cliente-Pago, Cajero-Pago
A es el siguiente a B
LineaVenta-LineaVenta
A es apropiado por B
TPV-Tienda
83
Atributos
Son valores de tipos de datos: Identidad no tiene sentido Tipos Primitivos: Boolean, Date, Numero, Time, String Tipos no primitivos: 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

84
42
Documentos de Anlisis Requisitos

Casos de Uso Especificacin Complementaria
Captura otros requisitos
Glosario
Captura trminos y definiciones
Visin
Define visin del producto de las personas involucradas, en trminos de sus necesidades y caractersticas.
85
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
86
43
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
87
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
88
44
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.
89
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
90
45
Prototipo inicial
Utilizar los casos de uso. Incluye las interfaces de usuario Sirve para validar los requisitos: analista y usuarios llegan a un acuerdo sobre la funcionalidad y vocabulario. Prototipo desechable Fcil de construir con herramientas visuales.
91
Contenidos
92
46
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.
93
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).
94
47
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.
95
Diagrama de Secuencia del Sistema (Caso de Uso Realizar Venta)
: Cajero
:Sistema crearNuevaVenta()
1. Cliente llega al TPV con item 2. Cajero inicia venta 3. Cajero introduce id item 4. Sistema registra lnea de venta y presenta parcial Cajero repite pasos 3 y 4 hasta que acaba 5. Sistema presenta total 6. Cajero requiere pago 7. ...
* introducirItem (CUP, cantidad) finalizarVenta () crearPago()
Operaciones del sistema
eventos del sistema
48
Cajero
Realizar Venta
Cliente
:Sistema
: Cajero crearNuevaVenta() * introducirItem(upc,cantidad) finalizarVenta() crearPago(cantidad)
Operacin Operacin Operacin Operacin CONTRATOS
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 o Eliminacin de asociaciones Modificacin de atributos
98
49
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?
99
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.
100
50
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
101
Plantilla de un Contrato
Nombre operacin Precondiciones
Signatura de la operacin Suposiciones relevantes sobre el estado del sistema o de objetos del modelo conceptual, antes de ejecutar la operacin. Suposiciones no triviales Estado de objetos del dominio despus de que se complete la operacin
Postcondiciones
102
51
Contrato IntroducirItem
Nombre: introducirItem (itemID: itemID, cantidad: integer) Precondiciones: Hay una venta en curso Postcondiciones: - Se cre una instancia lv de LineaVenta - Se asoci ldv a la venta en curso v - Se asign cantidad a lv.cantidad - lv se asoci a una EspecificacinProducto segn itemID
103
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.
104
52
Diagrama de Colaboracin
1. introducirItem(cant, id) : TPV 1.2. crearLV( ) : Venta 1.2.1. lv:=crear( ) lv : LineaVenta
: Cajero 1.1. p:= getProducto(id ) 1.2.2. add(lv)
: CatalogoProducto : LineaVenta
1.1.1. p:=get(id)
: Producto
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.
106
53
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.
107
Contenidos
108
54
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 Bajo Acoplamiento Controlador Indireccin Creador Alta Cohesin Polimorfismo Variaciones Protegidas
109
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
110
55
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.
111
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
112
56
Ejemplo 1
Quin es el responsable de conocer el total de una venta?
Venta fecha nota contiene 1..1 1..* 1 Descrita por LineaVenta cantidad
0..* Producto descripcion precio codigo 113
Ejemplo 1
Quin es el responsable de conocer el total de una venta?
: Venta lv : LineaVenta : Producto
getTotal()
* st:= getSubtotal() pr := getPrecio()
return getProducto().getPrecio * getCantidad
public void getTotal() { int tot = 0; para cada LineaVenta, lv total = total + lv.getSubtotal() return total }
114
57
Violacin del Experto

: Venta lv : LineaV enta p : Producto
getTotal()
p:=getProducto( ) public int getTotal() { precio:=getPrecio( ) int total = 0; para cada LineaVenta, lv: int precio = lv.getProducto().getPrecio int cant = lv.getCantidad(); total = cant * precio; return total
c ant: =getCantidad( )
return precio*cant
115
Ejemplo 2
Quin es el responsable de conocer todos los mensajes recibidos entre dos fechas?
: Lect orCorreo : Buzon : Carpeta : Mensaje
getMensajes(f1,f2)
m :=getMensajes(f1,f2) * m := getMensajes(f1,f2) * entreFechas(f1,f2)
116
58
Violacin del Experto

: LectorCorreo b : Buzon c : Carpeta m : Mensaje s : Set
getMensajes(f1,f2)
c:=getCarpetas( )
m:=getMensajes( ) f: =getFecha( ) [f en rango] add( )
para cada mensaje m en cada carpeta c si f en rango [f1,f2] aadir al conjunto s return s
117
Participante nombre apellidos numID domicilio direccionEnv io telef ono reputacion
Ejemplo 3
Subastas por internet
Pa goAnunc io +pa +pc PagoCuot a
+p PujaOrdinaria datosTarjeta estado +puja Adjudicacion
+as
+art
+as
+pujas +adjudicaciones AnuncioSubasta EdicionSubasta idEdici on f echaI ni cio f echaCi erre es tado +anuncios +es pv pRecomend pujaMinima cuota gastosEnv io plazo f ormaPago anticipo +articulos ArticuloConcreto codArticulo
59
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 3: * a s : = ge t() : Edici on Su basta as : AnuncioSubasta : Ca talogoAd judi cacio nes
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
120
60
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
121
Ejemplo
: CatalogoSubastas 2: as := getSubasta(numAnunci o)
Quin debera crear una instancia de puja?
1: pujarAnuncio(partID, numAnuncio, valorPuja, datosTarjeta) 4: p := getParticipante(partID) : ControladorPujas : Pujador : CatalogoParticipantes
6: po := crearPuja(p, valorPuja, datosTarjeta)
7: numPujas := comprobarPujas(p)
9: numSerie := generarNumSerie()
8: [numPujas < 3] po := crear(as, p, valorPuja, datosTarjeta) as : AnuncioSubasta po : PujaOrdinaria
10: add(po)
puj as : PujaOrdinaria
61
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
123
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)
124
62
Ejemplo
:GUI realizarPago() : TPV crear() agregarPago(p) p: Pago :Venta
125
Ejemplo
:GUI realizarPago() : TPV : Venta :Pago
realizarPago() crear()
126
63
Alta Cohesin
Cunto 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.
127
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
128
64
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
129
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.
130
65
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.
131
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
132
66
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)
Alumno
objetos control (controladores)

Matriculacion
objetos frontera (interfaces GUI)

GUIMatricula
133
Ejemplo
:AppletTPV :TPV
controlador
:Venta
introItem
introItem(cant,cod)
crearLineaVenta(cant,cod)
evento Acoplamiento adecuado de la capa presentacin con la capa del dominio
67
Ejemplo
:AppletTPV :Venta
introProd
crearLineaVenta(cant,cod)
evento Acoplamiento inadecuado de la capa presentacin con la capa del dominio

135
Controlador
Dado el evento Introducir tem, tendramos varios posibles controladores: i) TPV, ii) Tienda, iv) Manejador Compra Beneficios de un controlador:
Favorece la reutilizacin Posibilidad de capturar informacin sobre el estado de una sesin
136
68
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.
137
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.
138
69
Polimorfismo
Pago
(from Clases)
fechaPago cantidad
PagoCheque
PagoTarjeta
PagoEfectivo
139
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
140
70
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
141
Variaciones Protegidas (VP)

Cmo disear objetos, subsistemas y sistemas de manera que las variaciones o inestabilidades en estos elementos no tenga un impacto indeseable sobre otros elementos? Identificar los puntos de variacin previstos y asignar responsabilidades para crear una interface alrededor de ellos
142
71

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

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

144
72

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
145
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 { B at1; void met1() { C obj = at1.getAt2(); obj.met2(); } } class B { C at2; C getAt2() {return at2;} }
146
73

class A { B at1; void met1(..) { at1.met3; } } class C { void met2() {..} } class B { C at2; C getAt2() {return at2;} void met3() { at2.met2; } }
Evitar recorrer largos caminos en la estructura de objetos y entonces enviar un mensaje: diseo frgil
147

class Registro { private Venta venta; public void metodoFragil () { Dinero cantidad = venta.getPago().getCantidadEntregada() ... } Dinero cantidad = } venta.getCantidadEntregadaEnPago()
148
74
Contenidos
Introduccin
Dimensiones de un mtodo Mtodos pesados vs. Desarrollo gil
Modelado del Negocio Modelado de Requisitos Modelado del Anlisis Patrones GRASP Modelado del Diseo Casos Prcticos
149
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.
150
75
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.
151
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
152
76
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.
153
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!
154
77

Antes de escribir el mtodo getTotal() en la clase Venta, escribimos un mtodo de prueba de unidad en una clase TestVenta 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).
155

class TestVenta 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); } }
156
78
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
157
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.
158
79
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.
159
Iteracin 2: Ejemplo TPV

Se considera nueva funcionalidad del caso de uso Registrar Venta: desarrollo incremental
Uso de servicios externos (impuestos, autorizaciones,..) Reglas para establecer precios Reglas de negocio conectables Diseo para actualizar ventana cuando cambia el total de la venta
No se refina el caso de uso. Talleres de requisitos para escribir en detalle otros casos de uso
160
80
: Cajero crearNuevaVenta * introducirItem(id,cant)
: Sistema
: Calculo Impuestos
: Servicio Autorizacion
: Servicio Contabilidad
finalizarVenta li : = get Impuestos(venta) realizarPago (numTarj, fecha) ok:=solicitarAutorizacion putAdmisible(admisible) addVenta(venta)
Contenidos
Introduccin Modelado del Negocio Modelado de Requisitos Modelado del Anlisis Patrones GRASP Modelado del Diseo Casos prcticos
162
81
Ejemplo 1: PetStore
Autenticacin
Usuario
AltaUsuario
Casos de Uso
RealizarPedido
Nombre: RealizarPedido Objetivo: Realizar un pedido seleccionando y aadiendo productos a un carro de compras. Es posible cambiar el nmero de unidades de un producto del carro. 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. Se repiten los pasos 3-5 hasta que se indique 6. A: El Usuario finaliza la compra. 7. A: El Usuario introduce los datos personales del pedido: direccin, localidad, provincia, cdigo postal. 8. A: El Usuario introduce los datos para el pago Flujos alternativos: 3a. El producto se encuentra en el carro de compras. 1. S: El sistema incrementa en uno el nmero de unidades del producto del carro de compras. 3b. El Usuario selecciona un producto del carro de compras e introduce el nmero de unidades del producto que desea. 1. S: Actualiza el carro de compras reflejando las nuevas unidades. Si el nmero de unidades era cero, elimina el producto del carro de compras. 8a. La forma de pago es contra reembolso. 8b. La forma de pago es mediante transferencia bancaria. 8c. La forma de pago es mediante tarjeta de crdito. Comentarios:
82
Modelo Conceptual
Usuario nombre 1 nif 1 0.. n Pedido id tot al 1 1..n
LineaPedido unidade s 0..n
1 CarroCompra total ItemCarro unidades
1 Product o nombre preci o desc ripcion
0..n
0..n
Diagrama de Secuencia del Sistema para Realizar Pedido
: Usuario aadirItem(codigo) cambiarUnidades(codigo,unidades)
: Sistema
cerrarPedido(nif,direcc,localidad,provincia,CP,tTarjeta,nTarjeta,cMes,cAo,tPago)
83
Colaboracin AadirItem
: Usuario 11: recalcularTotal() 1: aadirItem(codigo) 4: aadirItem(codigo) 2: 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 ActionServlet LoginAction
Most rarAnimalesAct ion
AadirCarroAction
ModificarCarroA ct ion
EditarPedidoAc tion
SalvarPedidoAction
Ext endedActionServlet
ServiceImpl IServicios 0..n 1 1 1 Pedido numero nifCliente direccion localidad provincia codigoPostal tipoTarjetaCredito numeroTarjetaCredito caducidadMes caducidadYear t ipoPago LineaItems total estado LineaItem unidades total 1 Producto nombre numero descripcion precio categoria origenFot o ItemCarro unidades t ot al 1
FachadaCarroCompras
1..n
0..n
ActionForm Usuario nombre nif correo usuario clave
CarroCompras precioTotal items tam ao
LoginForm
ModificarCarroForm
PedidoForm
RegistroForm
DAOFactory
JDBCDAOFactory UsuarioDAO ItemDAO PedidoDAO LineaItem DAO
JDBCUsuarioDAO JDBCItemDAO JDBCPedidoDAO
JDBCLineaItemDAO
84
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 A a d i r C a r r o A c ti o n O b t ie n e e l A c t io n F o rw a rd O t ie n e u n 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 2 : p ro c e s 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 " ) 1 5 : c c V O : = lis t a rC a rro C o m p ra s ()
1 7 : m o s t ra r()
4 : a f: = p e r fo r m ( )
5 : a a d i r It e m ( c o d i g o )
: 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( ) 1 2 : [ n u e vo It e m ] i : = c r e a It e m ( p ) 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 ( )
6 : a a d i r It e m ( c o d i g o ) 8 : a a d i r It e m C a r r o ( c o d i g o ) 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 p a ra re c u p e ra r e l p ro d u c t o
i : It e m C a r r o
: C a rr o 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 )
: F a c h a d a C a rro C o m p ra s
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 identifica y autentica Postcondiciones: Se registra la venta. Se calcula el impuesto. Se actualiza contabilidad e inventario...
85

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
171

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

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:

3a. El identificador podra ser cualquier esquema de cdigo UPC, EAN,.. 7a. 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?
173
Modelo Conceptual
Descrita por
Registra venta de
1 Catalogo Productos 1 1 0..1 Usado-por 0..n Lineas Venta cantidad 1..n Contenidas en 1 Venta 1 1 1 pagado por 1 Pago iniciada por 1 Cliente capturada en 1 1 Registra Ventas 1 Cajero 1..n TPV 1 Iniciado por 1 Gerente 0..n Tienda direccion nombre 1 1 Almacena 0..n Contiene 1..n Describe 0..n 1 Item Producto
87
Cajero
Realizar Venta
Cliente
:Sistema
: Cajero crearNuevaVenta * introducirItem(upc,cantidad) finalizarVenta() realizarPago(cantidad)
Operacin Operacin Operacin
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
88
Operacin: Caso de Uso: Precondicin: Postcondicin:
introducirItem(itemID: itemID, cantidad: Dinero) Realizar venta se est procesando una venta 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) : TPV
1.2. crearLV( ) : Venta
1.2.1. lv:=crear( ) 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
: Cajero
: TPV
: Venta
1. finalizarVenta( ) 1.1. completar( )
89
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.1. pr:= getPrecio( ) : LineaVenta : Producto
1.1. * st:= getSubtotal( ) : Venta
{st = lv.cantidad + lv.producto.precio }
Operacin: Caso de Uso: Precondicin: Postcondicin:
crearPago(cantidad:Dinero) Realizar venta se est procesando una venta 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 ) : TPV 1.1. crearPago(cant ) v : Venta
: Cajero 1.1.1. crear( cant) 1.2. aadirVenta(v )
: Pago : Tienda
1.2.1. add(v)
: Venta
90
el sistema imprime el recibo con la cantidad a devolver
1.2. getTotal( )
1. getDevolucion( ) :Cliente v : Venta
1.1. getCantidad( ) p : Pago
dev = p.cantidad - v.getTotal
Operacin: Postcondicin:
Inicio Una instancia de Tienda, TPV y CatalogoProductos es creada. 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( ) Raiz : Tienda 1.1. crear( ) : CatalogoProducto
1.1.1. crear( ) 1.1.2.2. add(p)
p: Producto
1.1.2.1. crear( ) : Producto
91
Producto precio descripcion id getPrecio() 1 describe 1..n LineaVenta
CatalogoProducto 1..n 1 cargarProd() getProducto() 1 Usa 1 Tienda 1 aadirVenta() 1 posee 1 TPV Captura 1 crearVenta() finalizarVenta() introducirItem() realizarPago()
1..n 1 Venta
registra 0..n
completar() crearLV() 1 crearPago() getDevolucion() getTotal() 1 pagada 1 Pago cantidad getCantidad()
Modelo de 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); } }
92
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); } }
93
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; } }
Ejemplo 3. La Megasubasta
Realizar puja ordinaria Cerrar edicin de subasta
Pujador
Cancelar puja ordinaria Realizar pago de subasta ordinaria
Rechazar adjudicacin Sistema Notif icar adjudicatario Teleoperador Participante
Env iar artculo
Crear edicin de subasta
Anular anuncio de subasta Login Administrador Anular edicin de subasta Participante Conf irmar compra Incrementar of erta
Dev olv er artculo
94
Participante n Tarjeta de crdito Niv el de crdito es titular 1 nombre apellidos numID domicilio direccionEnv io telef ono reputacion 1 PagoAdjudicacion importe f echaPago medioPago datosTarjeta 1
realiza
0..n PagoCuota importe f echaPago 1 1 PujaOrdinaria numSerie v alorPuja datosTarjeta f echa 0..n Un pujador slo puede hacer hasta 3 pujas por anuncio de subasta. 1 0..1 0..n 0..1 1 Adjudicacion
Representa la especif icacin de un tipo de artculo.
1 AnuncioSubasta EdicionSubasta idEdicion f echaInicio f echaCierre numAnuncio pv pRecomend pujaMinima cuota gastosEnv io plazo f ormaPago anticipo 1 1 ArticuloConcreto 0..n 1..n codArticulo n 1 Articulo idEspec caracteristicas pv pRecomend
1..n
Caso de Uso: Crear edicin

Caso de Uso: Crear edicin de subasta Personal Involucrado: Administrador: Desea que la lectura de datos sea correcta. Proveedor: Desea que el anuncio refleje fielmente la informacin proporcionada por l. Participante: Desea que la descripcin del artculo se ajuste a la realidad, as como la fotografa. Que los datos mostrados en el anuncio sean correctos. Actor: Administrador Precondiciones: El Administrador est identificado y autenticado en el sistema. Postcondiciones: Se cre una nueva edicin de subasta con un conjunto de anuncios de subasta.
190
95
Caso de Uso: Crear edicin

Escenario Principal (o Flujo Bsico): 1. El Administrador quiere crear una edicin de subasta. 2. El Administrador introduce la fecha de inicio y cierre de la edicin. 3. El Sistema registra la nueva edicin, le asigna un nmero de edicin y solicita la introduccin de nuevos anuncios de subasta en la misma. Para cada subasta que el Administrador desea crear se realizan los pasos 4-11 4. El Administrador crea una nueva subasta ordinaria. 5. El Administrador elige el artculo a subastar y el nmero de artculos. 6. El Administrador introduce (en cualquier orden) el valor de la puja mnima, la cuota de participacin, los gastos de envo y el plazo de entrega. 7. El Sistema valida los datos. 8. El Sistema presenta al Administrador los datos introducidos con el IVA calculado al valor de puja mnima, a la cuota de participacin y a los gastos de envo. 9. El Administrador guarda los cambios. 10. El Sistema registra la nueva subasta y asigna un nmero a la subasta. 11. El Sistema establece el estado de los artculos subastados a En subasta.
191
: Administrador
: Sistema
crearEdicion(fechaInicio, fechaFin)
* introducirSubasta(idEspec, cantidad, puja, cuota, gastos, plazo)
Con idEspec se indica la especificacin de un artculo.
96
Operacin: crearEdicion (fechaInicio: Fecha, fechaFin: Fecha) Caso de Uso: Crear edicin de subasta Precondiciones: El Administrador est identificado y autenticado. Postcondiciones: - Se cre una instancia edicionActual de EdicionSubasta. - Se inicializ edicionActual.idEdicion - edicionActual.fechaInicio = fechaInicio - edicionActual.fechaCierre = fechaFin - Se cre una coleccin de tipo AnuncioSubasta y se asoci con edicionActual. - Se insert edicionActual con el CatalogoEdiciones
3. generarIdEdicion()
1. crearEdicion(fechaInicio, fechaFin)
2. edicionActual := crear(fechaInicio, fechaFin) edicionActual : EdicionSubasta
: ControladorAnuncios : Administrador 5. addEdicion(edicionActual)
4. anuncios := crear()
: CatalogoEdiciones
: AnuncioSubasta
6. add(edicionActual)
: EdicionSubasta
Se crea la coleccin de anuncios de subasta.
Operacin: introducirSubasta(idEspec: idEspec, cantidad: integer, puja: tipoDinero, cuota: tipoDinero, gastos: tipoDinero, plazo: intervalo) Caso de Uso: Crear edicin de subasta Precondiciones: Se est creando una edicin de subasta (ControladorAnuncios tiene asociada una edicionActual) Postcondiciones: - Se cre una instancia as de AnuncioSubasta. - Se inicializ as.numSubasta - Se asoci as con edicionActual. - Se asoci as con cantidad instancias de ArticuloConcreto basndose en idEspec. - Los atributos as.nombreArticulo, as.descArticulo y as.pvpRecomend se inicializaron de acuerdo con los atributos del Articulo a cuyo a.idEspec es idEspec. - as.pujaMinima = puja - as.cuota = cuota - as.gastosEnvio = gastos - as.plazo = plazo - as.formaPago y as.anticipo tomaron valores por defecto. - Se cre una coleccin pujas para objetos de tipo PujaOrdinaria y se asoci con as. - Se cre una coleccin adjudicaciones para objetos de tipo Adjudicacion y se asoci con as. - Se asoci as con la coleccin de AnuncioSubasta de edicionActual (se insert en la coleccin). - Se insert as en el CatalogoSubastas
97
15: add(as) : CatalogoSubastas : Subasta
14: addSubasta(as) 1: introducirSubasta(idEspec, cantidad, puja, cuota, gastos, plazo) 4: as := crearSubasta(a, cantidad, puja, cuota, gastos, plazo) 13: add(as) : ControladorAnuncios : Administrador edicionActual : EdicionSubasta : AnuncioSubasta
2: a := getArticulo(idEspec) 5: as := crear(edicionActual, a, cantidad, puja, cuota, gastos, plazo)
: Articulo
: CatalogoArticulos 3: a: = get(idEspec) as : AnuncioSubasta
6: pujas := crear()
: PujaOrdinaria
7: adjudicaciones := crear() 8: articulos := crear() : Adjudicacion
as tambin obtiene de a los atributos nombre, descripcin y pv p (se obv ia).
12: add(ac) 9: num := getNumArticulos() : Articulo 10: [num >= cantidad] *ac := getArticuloConcreto()
: ArticuloConcreto 11: [1..cantidad]* get()
a : Articulo
Itera sobre la coleccin buscando un artculo disponible.
if (num >= cantidad) { while (cantidad > 0) { ArticuloConcreto ac = a.getArticuloConcreto(); ac.setEstado("En subasta"); articulos.add(ac); cantidad--; } }
Caso de uso: Realizar puja ordinaria Personal Involucrado: La Mega Subasta, Pujador Actor: Pujador Precondiciones: Pujador es autenticado Postcondiciones: Una puja ordinaria es creada. Escenario Principal (o Flujo Bsico):
1. El Pujador decide pujar en un anuncio de subasta. 2. El Sistema comprueba que el Pujador no ha pujado tres veces en el anuncio. 3. El Pujador introduce el valor de la puja y los datos de su tarjeta de crdito (la primera vez). 4. El Sistema pide confirmacin para crear la puja. 5. El Pujador acepta. 6. El Sistema se comunica con la Entidad de Crdito y carga el valor de la cuota de participacin del anuncio de subasta en la tarjeta especificada por el Pujador. 7. El Sistema registra el pago de la cuota realizado (importe y fecha de pago). 8. El Sistema registra la nueva puja (le asigna un nmero de serie y almacena el valor de la puja, los datos de la tarjeta y la fecha de realizacin). 9. El Sistema notifica al usuario.
98
: Pujador
: Sistema
: GestorPagos
pujarAnuncio(partID, numAnuncio, valorPuja, datosTarjeta)
pagoCuota()
pagar(pago)
Se considera el escenario en el que el Pujador es un Participante que ha entrado en el sistema y est pujando por Internet.
Operacin:
pujarAnuncio (partID: NumID, numAnuncio: NumSubasta, valorPuja: real, datosTarjeta: DatosTarjeta) Casos de Uso: Realizar puja ordinaria Controlador: ControladorPujas Precondiciones: Postcondiciones: - Se cre una instancia po de PujaOrdinaria. - po.numSerie se inicializ. - po.valorPuja = valorPuja; - po.datosTarjeta = datosTarjeta; - po.fecha = fechaActual - po se asoci con el AnuncioSubasta as cuyo numAnuncio es numAnuncio. - po se asoci con el Participante cuyo numID es partID. - po se inserto en la coleccin de pujas de AnuncioSubasta
99
3: as := get(numAnuncio) : CatalogoSubastas : Subasta : Participante
2: as := getSubasta(numAnuncio) La puja se introduce en CatalogoPujas.
5: p := get(partID)
1: pujarAnuncio(partID, numAnuncio, valorPuja, datosT arjeta) 4: p := getParticipante(partID) : ControladorPujas : Pujador : CatalogoParticipantes
6: po := crearPuja(p, valorPuja, datosTarjeta)
7: numPujas := comprobarPujas(p)
9: numSerie := generarNumSerie()
8: [numPujas < 3] po := crear(as, p, valorPuja, datosT arjeta) as : AnuncioSubasta private int comprobarPujas(Participante p) { int numPujas = 0; Iterator it = pujas.iterator(); while (it.hasNext()) { PujaOrdinaria puja = (PujaOrdinaria)it.next(); if (puja.getParticipante().equals(p)) { numPujas++; } } return numPujas; } po : PujaOrdinaria
10: add(po)
pujas : PujaOrdinaria
Insercin ordenada: consideramos que la coleccin est ordenada de mayor a menor valor de puja.
Operacin: pagoCuota() Casos de Uso: Realizar puja ordinaria Controlador: ControladorPujas Precondiciones: Se est creando una puja ordinaria po. Postcondiciones: - Se cre una instancia pc de PagoCuota. - tarjetaOrigen = datosTarjeta de po e importe = el valor de la cuota (en el AnuncioSubasta as asociado con la PujaOrdinaria po). - Se asoci la instancia po de PujaOrdinaria con la instancia pc de PagoCuota. - Se realiz el pago especificado en pc a travs del GestorPagos. - Se asoci el PagoCuota pc con el CatalogoPagos del ControladorPujas (se insert en el catlogo).
100
7: add(pc) : CatalogoPagos : Pago
6: addPago(pc) 5: pagar(pc) : ControladorPujas : Pujador 2: pc := anotarPagoCuota() : GestorPagos
1: pagoCuota()
4: pc := crear(cuota, datosTarjeta) PujaOrdinaria en curso. po : PujaOrdinaria pc : PagoCuota
3: cuota := getCuota()
: AnuncioSubasta
Cso de uso: Cerrar edicin de subasta Personal Involucrado: La Mega Subasta, los Pujadores. Actor: Sistema Precondiciones: La fecha de cierre de una edicin de subasta ha vencido. Postcondiciones: Se cierran los anuncios de subasta de la edicin. Se emite la lista de resultados. Escenario Principal (o Flujo Bsico): 1. El Sistema comprueba que la fecha de cierre de una edicin de subasta ha vencido y procede a cerrarla. 2. El Sistema obtiene los anuncios de subasta de la edicin de subasta. Para cada anuncio de subasta el Sistema realiza los pasos 3-6: 3. El Sistema establece el estado de la subasta a Cerrado. 4. El Sistema obtiene una lista de las Pujas ganadoras (las de mayor valor y tantas como artculos subastados). 5. El Sistema registra las adjudicaciones asociando para cada una la Puja ganadora, el anuncio de subasta y uno de los artculos subastados. 6. El Sistema establece el estado de los artculos subastados a Adjudicado. 7. El Sistema emite la lista de resultados de la edicin de subasta.
101
Operacin: cerrarEdicionSubasta(es: EdicionSubasta) Caso de Uso: Cerrar edicin de subasta Precondiciones: La fecha de cierre de la edicin de subasta ha vencido. Postcondiciones: Para cada AnuncioSubasta as de la EdicionSubasta es: Se crearon n instancias adj de Adjudicacion (n = nmero de pujas adjudicatarias de as). Para cada Adjudicacion adj: adj se asoci con as, la PujaOrdinaria adjudicataria y un ArticuloConcreto. adj se asoci a la coleccin de objetos de tipo Adjudicacion de as.
1: cerrarEdicionSubasta(es) : ControladorAnuncios : Sistema 2: cerrar()
int numAjudicaciones = Minimo(pujas.length(), articulos.length());
5: numAdjs = calcularAdjudicaciones()
9: [1..num Adjs]* add(adj) 4: * cerrar() : AnuncioSubasta 3: * as := get() : EdicionSubasta as : AnuncioSubasta adjudicaciones : Adjudicacion
8: [1..numAdjs]* adj := crear(as, pg, a) 6: [1..numAdjs]* pg := get() pujas : PujaOrdinaria 7: [1..numAdjs]* a:= get()
Se recorre la coleccin de pujas obteniendo las pujas ganadoras (consideramos que la coleccin est ordenada de mayor a menor valor de puja).
adj : Adjudicacion : ArticuloConcreto Se crean tantas adjudicaciones como pujas ganadoras haya. Cada adjudicacin se asocia con un ArticuloConcreto, una puja adjudicataria y con la subasta.
102
Profesor 1..n nombre dni
Ejercicio 4. Gestin Cursos de Promocin Educativa

Profesor Contratado empresa cuentaBancaria
Profesor Universitario
registra
Especificacin Curso nombre horario duracin num creditos corte matrcula 0..n num max alum num min alum programa crite rio seleccin presupuesto reqPreinscripcion 1 Preinscripcin matriculable posee realiza 0..n tiene 0..n 0..1 Curso 1 1 Calificacin 0..n pagado p or 1..n Grupo 1 pertenece tiene 1 Alumno expediente 1 dni 1 nombre realiza 0..n 0..n Matricula 1 1 Catlogo Curso 0..n Aula
participa
Laboratorio 0..n
0..n
asig nado
rese rvada 0..n
0..n 1 0..n se_abre 1 Proyecto Presupuestario
posee 0..n 1
Curso
1..n
Curso Especialista Universitario
Curso Master
Curso P.E.
A lumno Universitario
Alumno Titulado
1 Pago
Registrar curso
Responsable
Rebajar Mnimo
Aprobar curso
Servicio CPE
Cerrar curso Crear proyecto Servicio Contabilidad
Fin matriculacion
Realizar preinscripcin
Sist ema
Avisar admitidos Alumno
Matriculacin Cancelar curso
103
Caso de uso: Registrar
Curso
Actor Principal: Responsable Precondiciones: - El responsable se identifica y se autentica Se est en el periodo de registro de cursos de PE. Postcondiciones: Se registra el curso Flujo Bsico: 1. El responsable comienza un nuevo registro. 2. El responsable introduce los siguientes datos del curso: nombre, duracin, fecha realizacin, fecha preinscripcin, horario, n crditos equivalencia, si est abierto o cerrado a titulados, n max alumno, n min. alumnos, programa y criterio de seleccin. 3. El responsable introduce el presupuesto global del curso, coste de la matricula, ayudas externas, pago del profesorado, costes de publicidad, costes en material fungible. 4. El responsable introduce las aulas y laboratorios que requiere para la ejecucin del curso, as como sus horarios respectivos. 5. El sistema accede al sistema de organizacin docente y comprueba que los requisitos de aulas y laboratorios son factibles. 6. El responsable introduce para cada profesor su nombre, dni, la empresa a la que pertenece ( en caso de pertenecer a alguna ), si pertenece o no a la universidad, su carga respecto al curso en crditos y su cuenta bancaria si procede. 7. El sistema recoge los datos del profesorado, accede al sistema de organizacin docente y comprueba que las cargas asignadas a los profesores universitarios son correctas. 8. El sistema registra el curso.
: Responsable
: SistemaGCPE
:SistemaOrganizacionDocente
1: crearCurso(especificacion) 2: *addReqAulaLab(reqAulaLab)
3: *addProfesorado(nombre,dni,tipo,empresa,cuentaBancaria, cargaDocente) 4: datosProfesor:= *getDatosProfesor(dni)
5: finalizarRegistro()
Si es una nueva edicin del curso y no ha habido cambio alguno en la especificacin, presupuesto, ni en los requerimientos de aulas, entonces se aprueba el curso 'aprobarCurso()'.
104
3: e s p ec := ge t(d a tos Es pe ci fica cio n) : C ata log oEs p ecificac io ne s : Es pe cificaci n C urs o : Matricu la Si es pe c s e c re en 4, s e a ad e al ca tlo go . Si la e dici n del curs o no e s la prim e ra pa s a r a es tad o a prob ad o.
2 : es pe c := g etEs pe cifica cio n(d atos Es pe cifica cio n)
11 : a dd Es pe cifica cio n(es pe c) 1 : cre arC urs o (da to s Es p ecificacion ,re s p ) : Con tro lad or Re gis tra rC urs o 7: cre ate(e s p ec)
10 : crea te()
8: cre ate () c : C u rs o : Pre in s crip cio n
: R es po ns ab le
9: cre ate () 4: [es pe c = n ull] crea te(d atosEs pe cifica cio n,res p)
: C rite rio Pre in s cr ip cio n 6 : ad dC riterio(criterio)
es p ec : Es p ecificacion C u rs o
El e s ta do de l curs o e s a prob ad o s i s e g en era e l m en s a je 7 y reg is trad o s i n o s e g en era.
: Partic ipa cio nC urs o
5 : crite rio := cre ate C rite rio ()
Se crea r n los cirte rio s e leg id os en da to s Es p ecificacin .
:Fa ctoriaC rite rio s
: Profesor
4. create(datosProfesor) : CatalogoProfesor
3. datosProfesor:= getDatosProfesor(dni) :SistemaOrganizacionDocente
Si la carga en cursos de PE del profesor no excede la cantidad estipulada se realizarn los pasos del 4 al 9. 2. p := getProfesor(dni)
Si el profesor no est en el catlogo se piden sus datos, se crea y se aade al catlogo.
part : ParticipacionCurso
Trata el caso de aadir un profesor universitario, sino lo fuera necesitara el resto de datos empresa y cuentaBancaria.
Est e me nsaj e y los sig ui en te s se ge ne ra rn si e l p ro fesor c ump le la s c ondi cion es est ab lecid as en c uant o a su c arga d oc en te.
6. cre at e(ca rga Doc en te,p)
1. ad dP ro fe sorad o(no mbre,d ni ,ti po ,emp re sa,cu en ta Ba ncaria ,ca rg aDocente ) : ControladorRegistrarCurso : Responsable
5. addParticipacion(p,cargaDocente) c : Cu rso
7. addParticipacion(part) p : Profesor Un iversita ri o
9. ad d(pa rt) Esta col aborac in ser a pa ra el caso de qu e el profesor f ue ra de tipo uni ve rsitario. S i fue se de tipo c ontrata do ser a el mi smo proceso obvia nd o los p asos de a cceso al sistema de o rgan izaci on docen te.
8. add(part)
: ParticipacionCurso
: ParticipacionCurso
105
Caso de uso: Realizar
Preinscripcin
Actor Principal: Alumno Precondiciones: El alumno se identifica y autentica El curso ha sido aprobado por el Consejo de Gobierno. Se est en el periodo de preinscripcin del curso. Postcondiciones: El alumno se preinscribe en el curso. Se envi un e-mail al alumno indicando si fue aceptada o rechaza su preinscripcin. Flujo Bsico: 1. El alumno comienza una nueva preinscripcin. 2. El alumno elige un curso sobre el que se desea preinscribirse. 3. El sistema comprueba que el alumno no realiz con anterioridad el curso y que no estaba preinscrito con anterioridad. 4. El sistema accede al sistema de gestin acadmica y comprueba que los datos acadmicos del alumno cumplen los requisitos para preinscribirse en el curso. 5. El sistema crea y enva un e-mail al alumno confirmando la preinscripcin. 6. El sistema aade el alumno a la lista de preinscritos.
3: c := get(idCurso) : Catlogo Curso : Curso
: Preinscripcin
9: *get() 2: c := getCurso(idCurso)
15: add(preins)
8: preinscrito:= isAlumnoPreinscrito(a.dni) 1: realizarPreinscripcion(idCurso,dniAlumno) : ControladorPreisncripcionCurso 12: [expValido= true] create(a,c) : Alumno 13: addPreinscripcion(preins) 10: [preins crito= false] expValido:= is Exp edVal ido(a) La preinscripcin se crea en estado no admitido. : EspecificacionCurso 5: datosAlumno:= getDatosAlumno(dniAlumno) Si preinscrito = true, los mensajes del 10 al 14 no son generados. 14: add(preins) 11: *aplicar() :SistemaGestinAcadmica Si el alumno no es t en el catlogo se piden sus datos, se crea y se aade al cat logo. : Preinscripcin 7: addPreisncripcion(a) c : Curso preins : Preinscripcin
4: a := getAlumno(dniAlumno)
: Alumno 6: create(datosAlumno)
: (CatalogoAlumno)
a : Alumno
:Criterio
106

Modelaje Con Uml

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Modelaje Con Uml

Încărcat de

Drepturi de autor:

Formate disponibile

Anlisis y Diseo del Software Curso 2005/2006

Un proceso software basado en UML

Sintaxis y Semntica bien definidas

En qu grado cubre el ciclo de vida?

Factora software Comprar antes que construir

Mtodos Pesados y giles

Rational Unified Process, RUP

Movimiento de la Extreme Programming, XP

Movimiento del Desarrollo Agil

Mtodos Pesados y Agiles

El Proceso Unificado (RUP)

Manifiesto para el Desarrollo de

Principios detrs del Manifiesto gil

Modelado gil (http://www.agilemodeling.com)

Modelado gil (http://www.agilemodeling.com)

Conforma con modelado gil

Etapas del Proceso

Etapas del Proceso

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 ) (un o po r caso d e u so)

A r q u ite c tu ra d e l S is te m a P a q u e te s P a tro n e s d e D is e o E s tru c tu ra s d e D a to s D is e o G U I P e r s is te n c ia D is t r ib u c i n M o d e lo d e l D is e o

Modelado del Negocio

Reglas de Negocio regulan el funcionamiento de la empresa

Procesos y Reglas del Negocio

Reglas del Negocio

Determinan polticas y estructura de la informacin

Subobjetivos Procesos del Negocio

Realizar pedidos a proveedores

Casos de Uso del Negocio

Generar pedidos a proveedor

Etapas del modelado del negocio

Etapas del modelado del negocio

Diagrama Casos de Uso del Negocio

Diagrama Casos de Uso del Negocio

Casos de Uso del Negocio

Ejemplo de Caso de Uso del Negocio

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

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

Plantilla Caso de Uso del Negocio

Prioridad Riesgos Posibilidades Tiempo Ejec. Coste Ejec.

Bsico ... ... ... ...

Modelado del negocio

Workers en Registrar Pedido

Escenario Registrar Pedido

: Comercial cursar pedido

estudiar pedido [ ok] realizar Produccin

Operarario Alm acen

Actividad compleja: otro diagrama

es viable? Rechazar Pedido no Crear P lantilla

Confirmar Pedido Realizar tarea

Pedir Material Ent regar Contenedor

Caso de Uso : - por especificar-

Actividad: Notificar aceptacion de pedido

Especificacin de las actividades

Especificacin de las informaciones

Del modelo de negocio al modelo de requisitos

Del modelo de negocio al modelo de requisitos

Concepto del Dominio

Retirar Cont enedor

Jefe Tcnico Entregar Contenedor Crear Plantilla

Diagrama de Casos de Uso Registrar Pedido

Casos de uso del sistema

Casos de uso de inclusin

Identificacin de casos de uso