Você está na página 1de 106

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
Introduccin Modelado del Negocio Modelado de Requisitos Modelado del Anlisis Patrones GRASP Modelado del Diseo Casos Prcticos
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

Caso de uso Realizar Venta


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

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

33

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:


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

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
75

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

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

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

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
Introduccin Modelado del Negocio Modelado de Requisitos Modelado del Anlisis Patrones GRASP Modelado del Diseo Casos Prcticos
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
Introduccin Modelado del Negocio Modelado de Requisitos Modelado del Anlisis Patrones GRASP Modelado del Diseo Casos Prcticos
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

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.

143

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


144

72

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

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

No hables con extraos


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

No hables con extraos


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

Programacin Prueba primero


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

Programacin Prueba primero


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

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
171

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

86

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:


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