Arquitectura del Software

Captulo 1
El Lenguaje Unificado de Modelado, UML

Introduccin a UML
Definicin de mtodo software Necesidad del modelado Presentacin de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado estructural Diagramas de Clases

Introduccin a UML
Modelado del comportamiento Diagramas de Interaccin Diagramas de actividades Mquinas de estado Modelado de la implementacin Diagramas de componentes Diagramas de despliegue Colaboraciones Modelado con roles en UML
3

Definiciones
Mtodo
Conjunto ordenado de pasos para obtener un resultado

Metodologa
Estudio de una familia de mtodos

Metodologa/Mtodo en Ingeniera del Software

Modo de abordar el desarrollo del software

Qu debemos esperar de un mtodo OO?

Cmo construir software?

Todo el mundo quiere guas que le ayuden a enfrentarse a los problemas

Cmo conseguir X de un modo prctico y sencillo?

En Ingeniera del Software,

Existe algn medio de asegurar el desarrollo de buen software?

6

Construir software es difcil

El desarrollo de software es una tarea difcil. Es difcil asegurar la calidad del software. Importante conocer las limitaciones y beneficios de los mtodos. Los mtodos pueden ayudar pero no aseguran el xito. Un mtodo ofrece guas mediante ejemplos de aplicacin. Un mtodo es fruto de la experiencia en proyectos. No sustituye a la necesidad creativa
7

Mtodo
Establece cmo abordar de un modo sistemtico la construccin de software. Centrados en el anlisis (modelado del sistema) y diseo. Se describe el problema y la solucin mediante un conjunto de modelos. Tres dimensiones: Tecnolgica, Proceso y Organizacin

Mtodo
Dimensin Tecnolgica
Conceptos, Notacin, Tcnicas y Herramientas usadas para el modelado

Dimensin Proceso
Conjunto de pasos a realizarse y resultados obtenidos en cada paso (entregables)

Dimensin Organizacin
Cmo organizar las personas para acomodar el proceso
9

Mtodo
TECNOLOGIA
(OO, UML, Rational Rose)

ORGANIZACION
(SIUM)

PROCESO
(RUP)
10

Dimensin Tecnolgica
CONCEPTOS
Cmo soporta los conceptos OO?

NOTACION
Modelos requeridos Representacin de los modelos
Expresividad de la notacin Legibilidad de la notacin
Grfica, Especificaciones formales,
Agregacin, Generalizacin, Roles

11

Dimensin Tecnolgica
NOTACION

Sintaxis y Semntica bien definidos?

Conexiones entre modelos. Capturan la semntica de las propiedades? Reglas para transformar y razonar sobre los modelos Crecimiento (Scaleability) Ofrece el conjunto de modelos una visin consistente y completa del sistema?. Existe un mecanismo para particionar en subsistemas? Es posible generacin de cdigo?
12

Dimensin Proceso
Pasos a realizar. Resultados que deben ser producidos en cada paso. Pueden tener diferentes escalas de tiempo: - Creacin de modelos
- Desarrollo de sistemas - Creacin de componentes reutilizables

13

Proceso
Para qu contexto de desarrollo es apropiado?
Nuevo software, Reingeniera, Prototipado, Reutilizacin

En qu grado cubre el ciclo de vida?

Anlisis vs. Diseo Implementacin Testing Anlisis de Dominios

14

Elementos del Proceso

Secuencia de etapas Entradas y Salidas de cada etapa Papeles implicados Interaccin entre las etapas Identificar etapas opcionales

Heursticas
Mecanismos para seguimiento, validacin y verificacin

15

Proceso
Los procesos son iterativos y los entregables evolucionan Conviene centrarse en los aspectos crticos en las primeras iteraciones para minimizar riesgos.

Creacin de software es un proceso CREATIVO y EXPLORATORIO: no puede encerrarse en una secuencia de pasos fija.

16

Proceso
No existe proceso que asegure soluciones satisfactorias NO HAY RECETA MAGICA

Un mtodo debera describir procesos por defecto y sugerir documentacin: UNO DEBE CREARSE SU PROPIO PROCESO.

17

Organizacin
Software de alta calidad no puede producirse en el general software job shop. Es necesario un enfoque industrial para la produccin de software:
CAPACIDAD DE PRODUCIR PRODUCTOS DE ALTA CALIDAD A BAJO COSTE

Diferentes productos software exigen diferentes organizaciones.

18

Organizacin
Mltiples facetas:
Management, Finanzas, Marketing, Ventas, Control y Planificacin de la produccin, Especificacin de productos, Diseo y produccin.

El xito de la produccin industrial del software implica:

Especializacin de la produccin Reutilizacin Trabajos y responsabilidades organizadas en una cadena de valor. Adecuar tareas a las capacidades del personal

19

Organizacin y Reutilizacin
La tecnologa de reutilizacin exige
i) invertir en componentes reusables ii) utilizacin de componentes reusables en el desarrollo de aplicaciones.

Formar una cadena de valor (value chain)

20

Mtodo completo
Adems de notacin, proceso y herramientas:
Guas de estimacin de costesTareas de manejo de proyecto Guas para elaboracin de los entregables Mtricas Polticas y Procesos para asegurar calidad del software Programas de entrenamiento Descripciones de roles Ejemplos elaborados de aplicacin y ejercicios para el aprendizaje. Tcnicas para adecuacin del mtodo

21

Pragmtica
Recursos disponibles Experiencia requerida Necesita herramientas CASE? Es orientado a un lenguaje de programacin? Para qu dominio es ms conveniente?

22

Soporte de la Ingeniera del Software

Reutilizacin Extensibilidad Proceso de test y evaluacin de los productos del mtodo Integridad conceptual: Puro, Combinativo, Adaptativo

23

Mtodos de Anlisis OO
Booch OMT Jacobson Shlaer-Mellor Wirfs-Broks Fusion Catalysis Coad/Yourdon Champeaux Martin/Odell OOram BON Open

Y muchos ms!
24

El lenguaje unificado de modelado, UML

A mediados de los noventa existan muchos mtodos de anlisis y diseo OO.
Mismos conceptos con distinta notacin. Mucha confusin. Guerra de los mtodos

En 1994, Booch, Rumbaugh (OMT) y Jacobson (Objectory) deciden unificar sus mtodos: Unified Modeling Language (UML) Proceso de estandarizacin promovido por el OMG
25

Evolucin UML
Grady Booch y Jim Rumbaugh comenzaron a unificar sus mtodos (Octubre, 1994). Borrador de UML (versin 0.8) (Octubre, 1995) Ivar Jacobson se une al proyecto (Noviembre, 1995). UML 0.9 y se crea un consorcio (Junio, 1996) OMG lanza una peticin para un lenguaje unificado (1996) UML 1.0 es ofrecido al OMG (Enero, 1997) Se extiende el consorcio (Enero-Julio, 1997) UML 1.1 es ofrecido al OMG (Julio, 1997) OMG adopta UML 1.1 (Noviembre, 1997) Se crea el UML RTF (1998) Aparece UML 1.3 (Mayo 1999)
26

Historia de UML
2001 ? UML 2.0

2000 ?
1999 1998 Nov 97
UML aprobado por el OMG

UML 1.4 UML 1.3

Revisiones menores

UML 1.2

(Tomada de www.dsic.upv.es/~uml)
27

UML aglutina otros enfoques

Rumbaugh Booch Odell Jacobson Meyer
Pre- and Post-conditions

Shlaer-Mellor
Object life cycles

UML
State Charts

Harel

Gamma et. al.

Frameworks, patterns, notes

Embly
Singleton classes

Wirfs-Brock Fusion
Operation descriptions, message numbering Responsabilities

(Tomada de www.dsic.upv.es/~uml)

28

Ventajas de la unificacin
Reunir los puntos fuertes de cada mtodo Idear nuevas mejoras Proporcionar estabilidad al mercado
Proyectos basados en un lenguaje maduro Aparicin de potentes herramientas

Eliminar confusin en los usuarios

29

Objetivos en el diseo de UML

Modelar sistemas, desde los requisitos hasta los artefactos ejecutables, utilizando tcnicas OO. Cubrir las cuestiones relacionadas con el tamao propias de los sistemas complejos y crticos. Lenguaje utilizable por las personas y las mquinas
Encontrar equilibrio entre expresividad y simplicidad.
30

UML y el modelado
UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software, desde una perspectiva OO.

UML es una notacin, no es un proceso Se estn definiendo muchos procesos para UML. Rational ha ideado RUP, proceso unificado.
31

Por qu modelamos?
Una empresa software con xito es aquella que produce de manera consistente software de calidad que satisface las necesidades de los usuarios

El modelado es la parte central de todas las actividades que conducen a la produccin de software de calidad
32

Por qu modelamos?
Un modelo es una simplificacin de la realidad Construimos modelos para comprender mejor el sistema que estamos modelando Cuatro utilidades de los modelos:
Visualizar cmo es o queremos que sea el sistema Especificar la estructura y comportamiento del sistema Proporcionan plantillas que guan la construccin del sistema Documentan las decisiones
33

Por qu las empresas no hacen modelado?

La mayor parte de las empresas software no realizan ningn modelado. El modelado requiere: aplicar un proceso de desarrollo formacin del equipo en la tcnicas tiempo?

Se obtienen beneficios con el modelado?

34

Problemas en el desarrollo de software?

Retrasos en los plazos Proyectos cancelados Rpido deterioro del sistema instalado Tasa de defectos o fallos Requisitos mal comprendidos Cambios frecuentes en el dominio del problema Muchas de las interesantes caractersticas del software no proporcionan beneficios al cliente Buenos programadores se cansan y dejan el equipo

35

Principios del modelado

La eleccin de los modelos tiene una profunda influencia sobre cmo se acomete el problema y se moldea la solucin. Todo modelo puede expresarse a diferentes niveles de detalle. Todo modelo debe estar ligado a la realidad. Un nico modelo no es suficiente. Cualquier sistema trivial se aborda mejor a travs de un pequeo conjunto de modelos casi independientes.

36

Utilidad del modelado

Escribimos cdigo directamente?
Se facilita la comunicacin entre el equipo al existir un lenguaje comn. Se dispone de documentacin que trasciende al proyecto. Hay estructuras que trascienden lo representable en un lenguaje de programacin.

37

Utilidad de UML
Permite especificar todas las decisiones de anlisis, diseo e implementacin, construyndose modelos precisos, no ambiguos y completos. UML puede conectarse a lenguajes de programacin:
Ingeniera directa e inversa

Permite documentar todos los artefactos de un proceso de desarrollo (requisitos, arquitectura, pruebas, versiones,..)

38

Metamodelo UML
Cmo se expresa la semntica del modelo? Informalmente Formalmente

El metamodelo UML define la notacin de un modo riguroso, a travs de diagramas de la propia notacin y con OCL.

39

Metamodelo UML: Ejemplo

Relacin

Generalizacin

Asociacion
1

ordered

2..*

Role de asociacin
40

Modelo Conceptual de UML

Bloques bsicos de construccin
Elementos
Estructurales, Comportamiento, Agrupacin, Anotacin

Relaciones Diagramas

Reglas para combinar bloques

Establecen qu es un modelo bien formado

Mecanismos comunes

41

Elementos Estructurales
Partes estticas de un modelo
Ventana origen tamao abrir() cerrar() mover() dibujar()
<<Interface>> IAvisable

IAvisable

Interface

clase

ValidarTransaccion

caso de uso

42

Elementos Estructurales
Gestor Eventos
suspender() vaciarCola()

clase activa

Hola Mundo.class

colaboracin

componente

Gestin Pedidos

Servidor

nodo

43

Elementos de Comportamiento
Son las partes dinmicas de UML.
Interaccin Conjunto de mensajes intercambiados entre un conjunto de objetos con un propsito particular.

dibujar

mensaje

44

Elementos de Comportamiento
Son las partes dinmicas de UML.
Mquina de estados Secuencia de estados por las que pasa un objeto durante su vida en respuesta a eventos.

activado

estado

45

Elementos de Agrupacin
Son las partes organizativas de los modelos UML Paquete

Modelo del Negocio

Un paquete incluye un conjunto de elementos de cualquier naturaleza.

Tiene una naturaleza conceptual.

46

Elementos de Anotacin
Son las partes explicativas de los modelos UML

Retorna 0 si no existe el valor

Nota

47

Relaciones
Dependencias
0..1 *

patron

empleado

Asociaciones

Generalizaciones Realizacin
48

Diagramas de UML
Diagramas de Casos de Uso Diagramas de Clases Diagramas de Objetos Diagramas de Interaccin
Diagrama Secuencia Diagrama Colaboracin

Diagramas de Estados Diagramas de Actividades Diagramas de Componentes Diagramas de Despliegue

49

Mecanismos comunes de UML

Especificaciones
Proporcionan una base semntica para cada elemento Los diagramas son proyecciones de esa base

Adornos
La notacin grfica bsica de cada elemento puede incluir adornos textuales o grficos para resaltar algunas propiedades de la especificacin.

50

Mecanismos comunes de UML

Divisiones Comunes
Dicotoma clasificador /instancia
Persona nombre direccion telefono

Elena

Elena : Persona

: Persona

51

Mecanismos comunes de UML

Divisiones Comunes
Dicotoma interfaz / implementacin

asistente Ortografico.dll

IOrtografia

52

Mecanismos comunes de UML

Mecanismos de extensibilidad
Estereotipos
Extienden el vocabulario de UML, permitiendo aadir nuevos tipos de bloques de construccin

Valores etiquetados
Extienden las propiedades de un bloque de construccin, aadiendo nueva informacin

Restricciones
Extiende la semntica de un bloque, aadiendo reglas o modificando las existentes.

53

Mecanismos de extensibilidad de UML

valor etiquetado estereotipo
ColaEventos {version 3.2; autor: jgm}

<<Exception>>

aadir()
quitar() vaciar()

Overflow

{ordenado}

restriccin

54

Hola, Mundo!
import Java.awt.Graphics; class HolaMundo extends java.applet.Applet { public void paint (Graphics g) { g.drawString (Hola, Mundo!,10,10); } }
HolaMundo g.drawString

("Hola, mundo)
paint()

55

Hola, Mundo!
Applet

HolaMundo paint ()

Graphics

56

Object ImageObserver Component Container

Panel
Applet HolaMundo

Hola, Mundo!
java
HolaMundo Applet

awt
lang

58

Hola, Mundo!
:Thread
run

:Toolkit
run

:ComponentPeer
callbackLoop

target:HolaMundo

handleExpose

paint

59

Hola, Mundo!
hello.java

HolaMundo.class

hello.html

60

Modelado de Casos de Uso

Un caso de uso especifica el comportamiento deseado del sistema. Representan los requisitos funcionales del sistema. Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor Describen qu hace el sistema, no cmo lo hace.
61

Casos de Uso
Emisor Centralita Receptor

Emisor_listo Tono

Efectuar_llamada
Timbre_sonando Telefono_cogido

Marca_nmero
Tono_sonando

Para_tono

Para_timbre

ESCENARIO

CASO DE USO

62

Otras definiciones de caso de uso

Describe un conjunto de interacciones entre actores externos y el sistema en consideracin orientadas a satisfacer un objetivo de un actor. [D. Bredemeyer] Es una coleccin de posibles secuencias de interacciones entre el sistema en discusin y sus actores externos, relacionado con un objetivo particular. [A. Cockburn] Es una descripcin de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor [UML]
63

Ejemplo Caso de Uso

actor caso de uso

Procesar Prstamo
ResponsablePrestamos

asociacion

64

Actores
Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos de uso al interaccionar con el sistema. Roles jugados por personas, dispositivos, u otros sistemas. No forman parte del sistema

65

Actores
Un usuario puede jugar diferentes roles. En la realizacin de un caso de uso pueden intervenir diferentes actores. Un actor puede intervenir en varios casos de uso. Identificar casos de uso mediante actores y eventos externos. Un actor necesita el caso de uso y/o participa en l.

66

Actores
A. Cockburn distingue dos tipos de actores:
Primarios: Requieren al sistema el cumplimiento de un objetivo Secundarios: El sistema necesita de ellos para satisfacer un objetivo

67

Propiedades de los casos de uso

Son iniciados por un actor con un objetivo en mente y es completado con xito cuando el sistema lo satisface. Puede incluir secuencias alternativas que llevan al xito y fracaso en la consecucin del objetivo. El sistema es considerado como una caja negra y las interacciones se perciben desde fuera. El conjunto completo de casos de uso especifica todas las posibles formas de usar el sistema, esto es el comportamiento requerido.
68

Escenarios y Casos de Uso

Un caso de uso describe un conjunto de secuencias de interacciones o escenarios: flujo principal y flujos alternativos o excepcionales. Un escenario es una instancia de un caso de uso. Escenarios principales vs. Escenarios secundarios. Especificacin con diagramas de secuencia.

69

Descripcin de un caso de uso

Describir el flujo de eventos
Texto estructurado informal Texto estructurado formal (pre y postcondiciones) Pseudocdigo Notaciones grficas: Diagramas de Secuencia

Debe ser legible y comprensible para un usuario no experto. Debe indicarse: inicio y final, actores, objetos que fluyen, flujo
principal y flujos excepcionales.
70

Descripcin de un caso de uso

Comprar articulos (en un terminal de punto de venta)
Flujo Principal: Un cliente llega al TPV con un conjunto de articulos. El Cajero
registra los artculos y se genera un ticket. El cliente paga en efectivo y recoge los artculos. 1. El cliente llega al TPV con los artculos. 2. El cajero registra el identificador de cada artculo. 3. El sistema obtiene el precio de cada artculo y aade la informacin a la transaccin de venta. 4. Al acabar el cajero indica la finalizacin de la introduccin de artculos. 5. El sistema calcula el total de la compra y lo muestra.
71

Descripcin de un caso de uso

Comprar articulos (en un terminal de punto de venta)
6. El Cajero le dice al cliente el total. 7. El cliente realiza el pago. 8. El cajero registra la cantidad de dinero recibida. 9. El sistema muestra la cantidad a retornar al cliente y genera un recibo. 10. El cajero deposita el dinero recibido y saca la cantidad a devolver que entrega al cliente junto al ticket de compra. 11. El sistema almacena la compra completada. 12. El cliente recoge los artculos comprados.
72

Cajero

Comprar Articulos

Cliente

:Sistema

: Cajero introducirItem(upc,cantidad) finalizarVenta() hacerPago(cantidad)

Descripcin de un caso de uso

Validar Usuario (contexto de un cajero automtico)
Flujo Principal: El sistema pide el NIP. El cliente lo introduce a travs del teclado
y pulsa Enter. El sistema comprueba la validez del NIP. Si es vlido el sistema acepta la entrada y finaliza el caso de uso.

Flujo Excepcional: El cliente puede cancelar la transaccin en cualquier

momento, pulsando el botn Cancelar, reiniciando el caso de uso.

Flujo Excepcional: Si el NIP introducido es invlido entonces se reinicia el caso

de uso. Si esto ocurre tres veces, el sistema cancela la transaccin completa y se queda con la tarjeta.
74

Diagrama de Casos de uso

Realizar transaccin con tarjeta Cliente

Comercio

Procesar factura cliente

Cliente Individual Cliente Corporativo Ajustar transacciones Entidad financiera

Gestionar cuentas clientes

75

Diagrama de Casos de uso

Reservar Libro

Prestamo revista

Profesor

Prestamo Libro

Devolver revista

Socio Devolver libro Actualizar catalogo

Bibliotecario

Extender Prestamo

Consultar

Socio

76

Diagrama de Casos de Uso

Rellenar Pedido

Analizar Viabilidad

Cliente Cursar Pedido

JefeTecnico

Ordenar Fabricacion

Notificar Aceptacion Pedido Comercial

Planificar Produccion

JefeProduccion

Notificar Rechazo Pedido

77

Casos de uso y Colaboraciones

Con un caso de uso se describe un comportamiento esperado del sistema, pero no se especifica cmo se implementa. Una caso de uso se implementa a travs de una colaboracin:
Sociedad de clases y otros elementos que colaborarn para realizar el comportamiento expresado en un caso de uso

Una colaboracin tiene una parte esttica (diagramas de clases) y una parte dinmica (diagramas de secuencia).
78

Casos de uso y Colaboraciones

caso de uso colaboracin

Hacer Pedido

Gestin Pedidos

realizacin

79

Escenario del caso de uso Realizar Compra

: Cliente : Interfaz Compra : CarroCompra : Producto

iniciarCompra()
nuevoCarroCompra(cliente)

seleccProducto(cantidad)

obtenerDescripcionDe(prod)
cargarProd(cliente,prod,cantidad)

confirmarCompra()
confirmarCompraDe(cliente)
decremStock(cantidad)

Realizar para cada producto incluido en el carro de compra

80

Casos de uso y Colaboraciones

El objetivo de la arquitectura del sistema es encontrar el conjunto mnimo de colaboraciones bien estructuradas, que satisfacen el comportamiento especificado en todos los casos de uso del sistema

81

Organizacin de Casos de uso

Tres tipos de relaciones: Generalizacin
Un c.d.u. hereda el comportamiento y significado de otro

Inclusin
Un c.d.u. base incorpora explcitamente el comportamiento de otro en algn lugar de su secuencia.

Extensin
Un c.d.u. base incorpora implcitamente el comportamiento de otro c.d.u. en el lugar especificado indirectamente por este otro c.d.u.
82

Ejemplo
Relacin de extensin

extend
Hacer Pedido
(establecer prioridad)

Hacer Pedido Urgente

include
Relacin de inclusin

Comprobar clave

Validar Usuario

Generalizacin

Seguir Pedido

include

Examinar retina
83

Relacin de inclusin
Permite factorizar un comportamiento en un caso de uso aparte y evitar repetir un mismo flujo en diferentes casos de uso. Ejemplo caso de uso Seguir Pedido:
Obtener y verificar el nmero de pedido. Include (Validar usuario). Examinar el estado de cada parte del pedido y preparar un informe para el usuario.

84

Relacin de extensin
El caso de uso base incluye una serie de puntos de extensin. Sirve para modelar
la parte opcional del sistema un subflujo que slo se ejecuta bajo ciertas condiciones varios flujos que se pueden insertar en un punto

Ejemplo caso de uso Hacer Pedido:

Include (Validar usuario). Recoger los items del pedido del usuario. (establecer prioridad). Enviar pedido para ser procesado.
85

Obtencin de casos de uso

1) Identificar los usuarios del sistema.

2) Encontrar todos los roles que juegan los usuarios y que son relevantes al sistema. 3) Para cada role identificar todas las formas (objetivos) de interactuar con el sistema. 4) Crea un caso de uso por cada objetivo. 5) Estructurar los casos de uso. 6) Revisar y validar con el usuario.
86

Plantilla para casos de uso (D. Coleman)

Caso de Uso
identificador / historia

Descripcin
Actores Asunciones Pasos

objetivo a conseguir
lista de actores Condiciones que deben cumplirse

interacciones entre los actores y el sistema necesarias para obtener el objetivo

Variaciones (opcional) cualquier variacin en los pasos No-funcional (opcional) lista requisitos no funcionales Cuestiones Lista de cuestiones que permanecen por
resolver
87

Plantilla para casos de uso (D. Coleman)

Ejemplo campo pasos:
1. Operador es notificado de problema en la red
2. Operador inicia una sesin de reparacin 3. REPETIR 3.1. Operador ejecuta aplicacin diagnsticos en la red. 3.2. Operador identifica elementos que deben cambiarse sus nuevos valores para los parmetros. 3.3. EN PARALELO 3.3.1. Ingeniero mantenimiento comprueba elementos en la red || 3.3.2. Ingeniero mantenimiento enva informe fallo 4. Operador cierra sesin

88

Plantilla para casos de uso (D. Coleman)

Relacin de uso: PERFORM c.d.u. Relacin de extensin:
Caso de uso extensin id. c.d.u. extends id. c.d.u. Cambio objetivo que debe conseguirse Pasos ... Variaciones ... No funcional ... Cuestiones ...
89

Ejemplo
Caso de Uso Descripcin Actores Asunciones Pasos Ordenar Fabricacin Se crearn rdenes de trabajo para cada producto solicitado en el pedido, y sern enviadas al jefe de produccin para su planificacin. Jefe tcnico Es viable la fabricacin de cada producto solicitado en el pedido. Existe una plantilla de fabricacin para cada producto solicitado. 1. REPETIR 1.1 Obtener un producto del pedido. 1.2 Buscar la plantilla de fabricacin asociada al producto. 1.3 Crear la orden de trabajo. 1.4 Almacenar la orden de trabajo con el estado pendiente. -

Variaciones Req. No Funcionales Cuestiones

90

Plantilla Escenario (A. Cockburn)

Sistema Actor principal Objetivo Condiciones Resultado
Compaa Seguros Asegurado Cobrar seguro accidente Todo en regla Compaa seguros paga

1. Asegurado enva reclamacin 2. Compaa verifica que asegurado tiene una pliza vlida 3. Compaa asigna agente 4. Agente verifica todos los detalles son conformes el contrato 5. La compaa paga al asegurado
91

Plantilla Caso de Uso (A. Cockburn)

Sistema Actor principal Objetivo

Compaa Seguros Asegurado Cobrar seguro accidente

1. Asegurado enva reclamacin 2. Compaa verifica que asegurado tiene una pliza vlida 3. Compaa asigna agente 4. Agente verifica todos los detalles son conformes el contrato 5. La compaa paga al asegurado

92

Plantilla Caso de Uso (A. Cockburn)

Extensiones
1a. Datos del parte incompletos 1a1. Compaa requiere datos 1a2. Asegurado enva datos 2a. Asegurado no tiene una pliza vlida 2a1. Compaa rechaza reclamacin, avisa al asegurado. 3a. No hay agentes disponibles 3a1. qu hace la compaia?
.
93

Plantilla Caso de Uso (A. Cockburn)

Variaciones 1. Asegurado a) una persona b) otra compaa de seguros c) el gobierno
2. Pago a) transferencia b) dinero en efectivo c) cheque

94

Por qu casos de uso?

Ofrecen un medio sistemtico e intuitivo para capturar los requisitos funcionales, centrndose en el valor aadido para el usuario Dirigen todo el proceso de desarrollo puesto que la mayora de actividades (planificacin, anlisis, diseo, validacin, test,..) se realizan a partir de los casos de uso. Mecanismo importante para soportar trazabilidad entre modelos.
95

Crtica a los casos de uso

(B.Meyer, E. Berard)

Los casos de uso no son adecuados en el modelado orientado a objetos porque:

i) Favorecen un enfoque funcional, basado en procesos ii) Se centran en secuencias de acciones iii) Se basan en los escenarios actuales del sistema

Solo deben ser usados por equipos expertos en desarrollo OO Utiles para validacin
96

Utilidad de los casos de uso

Hay consenso en considerar casos de uso como esenciales para capturar requisitos y guiar el modelado. Pero existe mucha confusin sobre cmo usarlos. Diferentes opiniones sobre el nmero de casos de uso conveniente:
20 para un proyecto 10 personas/ao (Jacobson) depende de la granularidad

97

Granularidad

(M. Fowler)

Diferente granularidad Un caso de uso puede describir:

Un objetivo o propsito del usuario Una interaccin con el sistema

Un objetivo implica una o ms interacciones. Primero construir un caso de uso por cada objetivo del usuario. Despus escribir casos de uso para cada interaccin que corresponda a un objetivo.
98

Granularidad
Ambito
Sistema
Funcionalidad requerida del sistema

(A. Cockburn)

Organizacin
Objetivo estratgico para la empresa, de mucho valor

Especificidad
Objetivo del usuario Colecciones de objetivos de usuario Subfunciones

99

Granularidad
Especificidad
Objetivo del usuario

(A. Cockburn)

Tarea del usuario o proceso de negocio elemental

Colecciones de objetivos de usuario

Recoge casos de uso de usuario relacionados

Subfunciones
Un paso en la descripcin de un caso de uso (validar, buscar, log on)

Detalle de la interaccin
Interface de dialogo o Interface semntica

100

Tipos de casos de uso

Alto nivel vs. Expandido

(Larman)

Descripcin muy general o conversacin entre actor y sistema.

Primarios, Secundarios u Opcionales

Segn su importancia en el sistema

Esenciales vs. Reales

Segn su grado de abstraccin Un caso de uso real describe el proceso en trminos de su diseo actual, teniendo en cuenta tecnologa de E/S.
101

Recomendaciones (E. Berard)

Un caso de uso no debe considerar cuestiones de implementacin. Conveniencia de una herramienta para la gestin de los casos de uso. Encontrar contradicciones entre casos de uso. Preocupacin por mantener la validez y consistencia del conjunto de casos de uso. Cmo se comprueba que los casos de uso incluyen toda la funcionalidad del sistema?
102

Recomendaciones (E. Berard)

Cada compaa debe tener un manual sobre uso de los casos de uso. A qu nivel de detalle se describe un caso de uso? Qu granularidad es apropiada para un caso de uso?
Pinchar botn, Aadir Empleado,.. son casos de uso?

103

Recomendaciones

(M. Fowler)

Cuidado con el empleo de la relacin uses

NO HAGAS UNA DESCOMPOSICION FUNCIONAL!

No abusar de la estructuracin de casos de uso No es necesario aplicar la abstraccin

USA CASOS DE USO CONCRETOS!

Distinguir entre casos de uso del sistema y casos de uso del usuario.

104

Recomendaciones

A. Pols

Primero establecer los objetivos del proyecto. Despus identificar actores y sus responsabilidades, y las tareas que ejecutan son los casos de uso. Contrastar casos de uso frente a los objetivos. Cuidado con la ambigedad No profundizar en la descripcin de un caso de uso No te preocupes en exceso de la notacin

105

Recomendaciones

(A. Pols)

Evita redes complicadas de casos de uso: Cuidado con las relaciones included y extend. No considerar la interfaz del usuario Los casos de uso slo consideran los requisitos funcionales del proyecto, hay que aadir los nofuncionales.

106

Casos de Uso y Componentes

Pensar en componentes lo antes posible
Ahorrar esfuerzo Negociar los requisitos

Si se producen componentes
Asociarle su propio caso de uso

107

Modelado estructural
Se describen los tipos de objetos de un sistema y las relaciones estticas que existen entre ellos. Se expresa mediante los diagramas de clase. Normalmente contienen:
Clases Interfaces Relaciones de dependencia, realizacin, generalizacin y asociacin (agregacin, composicin)

Tambin pueden incluir paquetes y colaboraciones.

108

Diagramas de Clase
Forman parte de la vista de diseo esttica del sistema. Los diagramas de clase se usan para modelar:
vocabulario del sistema
identificar clases para abstracciones relevantes del dominio del problema

colaboraciones (parte esttica)

identificar clases e interfaces cuya interaccin produce el comportamiento deseado.

esquema lgico de base de datos

109

Vocabulario del sistema

Comercio nombre direccion direccionWeb avisarPedido() Responsabilidades CarroCompra almacenar productos aadir productos eliminar productos calcular precio compra Factura fecha importe nuevaFactura() Cliente nombre direccion email

Producto id nombre precio ubicacion

Transaccion commit() rollback() tuvoExito()

Internauta email numeroCuenta

110

Producto Especial

Producto Catalogado

Catalogo

Producto 1..*

tiene

Plantilla de Fabricacion

basada en 0..* Pedido 1..* genera 0..* 0..* Orden de Trabajo

Cliente

Colaboracin (Parte Esttica)

CarroCompra contiene 0..* 1..1 es propiedad de 1..* Producto

1..1

Cliente

113

Colaboracin (Parte dinmica)

: Cliente iniciarCompra() nuevoCarroCompra(cliente) : Interfaz Compra : CarroCompra : Producto

seleccProducto(cantidad) obtenerDescripcionDe(prod) cargarProd(cliente,prod,cantidad)

confirmarCompra() confirmarCompraDe(cliente) decremStock(cantidad)

Realizar para cada producto incluido en el carro de compra

114

Patrn de diseo (Parte Esttica)

Subject subjectState Attach() Detach() Notify() +observers 1..1 1..* Observer Update()

for all o in observers {o->update}

ConcreteSubject

subjectState
getState() setState()

+subject

ConcreteObserver observerState update() observerState= subject->getState()

115

Patrn de diseo (Parte dinmica)

: Subject SetState( ) Notify( ) Update( ) GetState( ) Update( ) GetState( )
one : Observer

another : Observer

116

Diagramas de Clase
Diferentes perspectivas: Conceptual
Se representan los conceptos del dominio estudiado.

Especificacin
Se representan los tipos que representan una interface cual puede tener cualquier implementacin la

Implementacin
Se representan las clases tal y como sern implementadas

117

Clases y asertos
Posibilidad de incluir en la especificacin:
Precondiciones Postcondiciones Invariante

Recomendacin: Usar Diseo por Contrato

118

Ingeniera directa e Inversa

Ingeniera directa
Transformar modelos en cdigo en un lenguaje de programacin determinado

Ingeniera inversa
Obtener un modelo a partir de cdigo. Ms difcil ya que hay prdida de informacin al pasar de los modelos al cdigo.
119

Atributos
[visibilidad] nombre [: tipo] [= valor_inicial ] [{propiedades}]
+ = pblica # = protegida - = privada

visibilidad nombre: tipo:

nombre del atributo

tipo del atributo valor inicial o por defecto

valor_inicial:

propiedades: {frozen} {addOnly}

120

Diagramas de Clase: Atributos

Nivel Conceptual: Los clientes tienen un nombre Nivel de Especificacin: El cliente puede almacenar y consultar su nombre Nivel de Implementacin: Cliente tiene un campo de tipo string que almacena su nombre y un mtodo que lo devuelve
121

Operaciones
[visibilidad] nombre [(lista_parametros)] [: tipo_retorno] [{propiedades}] visibilidad
+ = pblica # = protegida - = privada

nombre: nombre de la operacin lista_parmetros: tipo retorno: propiedades: lista de parmetros separados por comas

tipo de valor devuelto por la operacin {isQuery}, {sequential}, {concurrent}

122

Diagramas de clase: Operaciones

123

Diagramas de Clase: Operaciones

Nivel Conceptual
Responsabilidades de la clase Tarjetas CRC: Descripcin de alto nivel del propsito de la clase

Nivel Especificacin
Protocolo de la clase (operaciones pblicas)

Nivel Implementacin
Conjunto de mtodos de la clase

124

Clases Parametrizadas

T Clase Parametrizada Set

insert(T) remove(T)

Instanciaciones

Set<Empleado>

bind <Empleado>

SetEmpleados
125

Clases Parametrizadas
G Tabla count capacity put(G) item() : G

bind <Empleado>

Empleados Tabla<Cliente>

126

Otras propiedades
Clases diferidas Multiplicidad Variables y mtodos de clase
Cuenta codigo titular saldo $ UltimoCodigo reintegro() ingreso() nuevoCodigo()

<<abstract>> Figura rotar() trasladar() visualizar()

127

Clases Estereotipadas
<<metaclass>> MetaclaseCuenta

<<exception>> FueraRango

Clases y valores etiquetados

Cuenta {Autor:jgm: version: 1}

codigo titular saldo $ UltimoCodigo

reintegro() ingreso() nuevoCodigo() 128

Diagramas de Clases: Relaciones

Dependencia
Un cambio en la especificacin de un elemento afecta a otro
PlanDelCurso

Window position parent children size open() close() move() resize()

Curso aadir(c : Curso) eliminar(c : Curso)

Clock

Nodo

Lista

<<friend>>
129

Estereotipos para dependencias

bind: entre una clase genrica y una instanciacin friend: dependencia de clase amiga refine: relacin de refinamiento use: relacin de uso

import: un paquete importa los elementos de otro.

extend: para casos de uso include: para casos de uso
130

Diagramas de Clases: Relaciones

Generalizacin
Es-un-tipo-de

Cuenta

Window

CuentaAhorro

CuentaCorriente

TextWindow

BoxDialog

131

Diagramas de Clase: Generalizacin

Nivel Conceptual
Todas las instancias de CuentaCorriente son instancias de Cuenta

Nivel Especificacin
La interface de CuentaCorriente incluye la interface de Cuenta Principio Sustitucin

Nivel Implementacin
Herencia

132

Adornos para la generalizacin

implementation (estereotipo): herencia privada C++ complete/incomplete (restriccin):
se han especificado todos los descendientes?

Disjoint/overlapping (restriccin):
clasificacin esttica vs. clasificacin dinmica

133

Restricciones semnticas entre las subclases

OVERLAPPING Una nueva clase puede ser subclase de ms de una subclase Una instancia puede ser instancia directa o indirecta de dos ms subclases DISJOINT Una nueva clase no puede ser subclase de ms de una subclase. Instancias de una nica clase.
134

Generalizacin: overlapping
Vehculo
fuerza overlapping} fuerza Impulsado por motor medio { overlapping} medio Vehculo terrestre

Impulsado por viento

Vehculo marino

Camin

Velero

135

Generalizacin: disjoint

rbol

{disjoint, incomplete}

Nogal

Pino

Olmo

136

Clasificacin Mltiple
Un objeto puede ser instancia de ms de una clase, no necesariamente conectadas por la herencia
Discriminador

Hombre Persona
sexo

role

Doctor
Enfermera

Mujer

{completo}

paciente

Paciente

Masajista
137

Clasificacin Dinmica
Un objeto puede cambiar de clase dentro de la jerarqua de subclases. Hombre Persona
sexo trabajo dynamic

Manager
Ingeniero

Mujer

{completo}

Vendedor
138

Diagramas de Clase: Asociacin

Asociacin
Relacin estructural que especifica que los objetos de un tipo estn conectados con los de otro.

Persona

+empleado 1..*

+patron *

Empresa

Curso
*

impartido
1..*

Profesor

139

Asociaciones
Agregacin
Caso especial de asociacin Relacin estructural parte-de
Empresa

1..1

Departamento

140

Asociaciones
Nivel Conceptual
Muestran la relacin conceptual entre dos clases. Un cliente tiene varios pedidos

Nivel de Especificacin
Representan responsabilidades Detectamos los mensajes del protocolo de una clase con respecto a la otra

Nivel de Implementacin
Establecer atributos: navegabilidad
141

Asociaciones
Especificacin: class Pedido { public Cliente getCliente; public Set getLineaPedido;... } Implementacin class Pedido { private Cliente private Set _cliente; _lineasPedido; }
142

Navegacin
Posibilidad de limitar la navegacin a una sola direccin Determina si una clase de la asociacin tiene conocimiento de la otra. Nivel de especificacin o implementacin

Curso *

impartido 1..*

Profesor

143

Visibilidad
Pblica: +propietario Protegida: #propietario Privada: -propietario

GrupoUsuarios * *

Usuario

+propietario
1..1

-clave
*

Clave

144

Asociaciones calificadas
LneaPedido Producto 0..1 lineaPedido

Pedido

Unidades: Integer PrecioTotal: Integer

N. Conceptual: Dentro del mismo pedido no pueden existir dos lneas con el mismo producto
N. Especificacin: El acceso a lineaPedido es indexado por productos

N. Implementacin: Se usa una tabla para almacenar las lneas de pedido

145

Asociaciones calificadas
Class Pedido { private Tabla _lineasPedido;

public LineaPedido getLineaPedido(Producto unProducto); public void addLineaPedido (Integer cantidad, Producto elProducto); }

146

Ejemplo

Departamento

depto 1 Nro. despacho 0..1 dirige

profesor 1..* director

Profesor

147

Agregacin
Dos criterios:
Dependencia:
La existencia de una parte va ligada a la del agregado?

Exclusividad:
Una parte puede pertenecer a ms de un agregado?

Cuatro posibles tipos de agregacin

148

Composicin
Es un caso particular de agregacin:
exclusiva y dependiente

Las partes pueden crearse despus del agregado compuesta al que pertenecen, pero una vez creadas viven y mueren con ella. La parte slo puede formar parte de un agregado. El agregado gestiona la creacin y destruccin de las partes. Las partes se pueden eliminar antes de eliminar el agregado.
149

Composicin
Ventana

agregado /todo

1..1

composicin
* Marco

parte

150

Composicin

Agregacin

POLGONO 1 3..* 1

Composicin

POLGONO 1 Relleno:Diseo

{ordered} Punto

Diseo Color Textura

POLGONO
{ordered} 3..* Punto 1

Puntos[3..*]: coord Color: Integer Textura: Integer

151

Clases Asociacin

152

Clases Asociacin
Una clase asociacin aade una restriccin: Slo puede existir una instancia de la asociacin entre cualquiera par de objetos participantes No podramos modelar que una persona tiene diferentes contratos para una misma compaa a lo largo del tiempo.

153

Ejemplo

154

Asociaciones n-arias
Asociacin entre tres o ms clases.
Cada instancia de la asociacin es una n-tupla de valores de cada una de las respectivas clases .
Ao temporada * Equipo * equipo * portero Jugador

Registro goles_a_favor goles_en-contra triunfos

155

Asociaciones derivadas
recibe Estudiante Asignatura

/ensea

imparte

Profesor

156

Asociaciones derivadas
+componentes * Cuenta /operaciones * Operacion

CuentaSet 0..1

CuentaCorriente 1..1

role operaciones derivado de componentes.operaciones

157

Restricciones para Asociaciones

Empresa
Departamento * *

Cuenta

{or}
Persona

{subconjunto}
+miembro 1..* Persona +Director 1..1

158

Restricciones para Asociaciones

Miembro-de

Persona
1

{subconjunto}
Presidente-de *

Comit

159

Restricciones para Asociaciones

operario * 0..1 jefe Persona

empleado *

patrn 0..1 Compaia

{Persona.patrn= Persona.jefe.patrn }

160

Diagramas de Clase: Realizacin

Relacin entre clasificadores, un clasificador especifica un contrato que otro clasificador garantiza que cumplir.
<<Interface>> IPila Pila push() pop() top()
Pila

IPila

161

Clases Abstractas e Interfaces

OrderReader

Dependencia
DataInput InputStream {abstract} Generalizacin DataInputStream Realizacin InputStream interface DataInput DataInputStream OrderReader

Dependencia

162

Paquetes
Elemento organizativo Puede contener elementos de cualquier tipo. Un elemento es exclusivo a un paquete. Posibilidad de anidar paquetes.
Modelo

Modelo

+ Producto + CarroCompra + Comercio

164

Paquetes
Un paquete bien estructurado debe:
ser cohesivo estar poco acoplado poco anidamientos conjunto equilibrado de elementos

165

Importacin/Exportacin en paquetes
Los paquetes permiten controlar la complejidad del manejo de un gran nmero de abstracciones, controlando los accesos mediante la importacin.

La parte pblica de un paquete son sus exportaciones. Las partes pblicas son visibles en los paquetes que importan al paquete contenedor. La importacin no es transitiva. Los paquetes anidados pueden ver todo lo que ven los paquetes que los contienen.
166

Cliente Servidor + BaseDeDatos + ServicioDeRegistro

+ FormularioPedido + FormularioDeSeguimiento - Pedido

import
Politicas + ReglasPedidos + GUI:Ventana

GUI + Ventana + Formulario # GestorEventos

import

Generalizacin de Paquetes
GUI + Ventana + Formulario # GestorEventos

WindowsGUI + GUI:Ventana + Formulario # GUI:GestorEventos + VBForm

MacGUI

168

Uso de los paquetes

Agrupar elementos, normalmente del mismo tipo, para manejarlo en conjunto.
Paquete Clases e interfaces del modelo Paquete Interfaces de usuario Paquete Servicios base de datos

Un modelo es un paquete incluyendo todos los elementos que constituyen una particular vista del sistema modelado.
169

Sistema, modelo, vista, diagrama

Un sistema es aquello que se est desarrollando y para lo que se crean modelos. Un subsistema es una parte de un sistema. Un modelo es una abstraccin de un sistema que ayuda a comprenderlo. Una vista es una proyeccin de la estructura y organizacin de un modelo del sistema, centrada en algn aspecto. Un diagrama es una representacin de un conjunto de elementos.
170

Vistas UML
vocabulario funcionalidad ensamblado gestion conf.
Vista de Implementacion

Vista de Diseo

comportamiento

Vista de casos de uso

Vista de Procesos

Vista de Despliegue

Funcionamiento escalabilidad rendimiento

topologa entrega distribucin instalacin

171

Vistas UML
clases interfaces colaboraciones
Vista de Implementacion

componentes

Vista de Diseo

casos de uso

Vista de casos de uso

Vista de Procesos

Vista de Despliegue

clases activas

nodos

172

Vistas UML
Diagramas de clase Diagramas de interaccin Diagramas de estado Diagramas de componentes Diagrama de interaccin Diagramas de estado
Vista de Implementacin

Vista de Diseo

Diagramas de casos de uso

Vista de casos de uso

Vista de Procesos

Vista de Despliegue

Diagramas de clase Diagramas de interaccin Diagramas de estado

Diagramas de despliegue Diagrama de interaccin Diagramas de estado

173

Diagrama de Objetos

d:DiagramaClases

:Relacion :Clase

:Metodo

:Clase

:Clase

:Atributo

174

Diagrama de Objetos
:Universidad

d2:Departamento

d2:Departamento

director:Profesor

:Profesor

:Asignatur a

175

Enlaces y Asociaciones
Un enlace es :
una conexin semntica entre objetos. una instancia de una asociacin. un camino por el cual enviar un mensaje

enlace
p:Persona 1: asignar(desarrollo) :Empresa

mensaje

176

Interacciones y Mensajes
Interaccin: Comportamiento que comprende un
conjunto de mensajes intercambiados entre un conjunto de objetos dentro de un contexto para lograr un propsito.

Mensaje: especificacin de una comunicacin entre

objetos que transmite informacin, con la expectativa de desencadenar una actividad.

177

Modelado del comportamiento

Se describe cmo los objetos colaboran entre s para realizar cierta actividad. Se expresan mediante los diagramas de interaccin:
Diagramas de Secuencia y Diagramas de Colaboracin.

Tambin se describe las mquinas de estado que caracterizan a los objetos

Diagramas de estado Diagramas de actividades

178

Diagramas de Interaccin
Describen una interaccin. Dos tipos: Diagramas de Secuencia y Colaboracin Diagramas de Secuencia:
Destacan la ordenacin temporal de los mensajes

Diagramas de Colaboracin:
Destacan la organizacin estructural de los objetos participantes.

Equivalencia semntica

179

Diagramas de Secuencia
Representan escenarios. Incluye:
Objetos y su lnea de tiempo Mensajes : argumentos y self-delegation Informacin de control: condiciones y marcas de iteracin Indicar el objeto devuelto por el mensaje: return
(aadirlos slo cuando ayuden a clarificar la interaccin)

Especificar procesos concurrentes: focos de control

180

Sincronizacin
Envo de mensaje simple: Un solo hilo de ejecucin El objeto activo pasa el control al objeto pasivo
: Envo simple

Un cliente

Otro objeto

181

Sincronizacin
Envo de mensaje sncrono: Slo se desencadena la operacin cuando el servidor acepta el mensaje El cliente se bloquea hasta que el servidor lo acepta o rechaza

Un cliente

: Envo sncrono

Otro objeto

182

Sincronizacin
Envo de mensaje asncrono: Un mensaje asncrono no interrumpe la ejecucin del cliente El cliente enva el mensaje sin saber cundo ni si se llevar a cabo
: Envo asncrono

Un cliente

Otro objeto

183

Diagramas de Secuencia
:Interface Entrada Pedido preparar *preparar hayStock:=comprobar [hayStock] eliminar pedir?:=necesarioPedir [pedir?]<<create>> :Pedido :LineaDe Pedido :Item

PedidoItem ItemEntregado

[hayStock] <<create>>

184

Diagramas de Colaboracin
1: preparar :Interface Entrada Pedido :Pedido 2: *preparar :LineaDe Pedido

7: 5: pedir?:=necesarioPedir 3: hayStock:=comprobar 4: [hayStock] eliminar 8: [hayStock] <<create>>

:Item

Item Entregado Pedido Item

6: [pedir?]<<create>>

185

Diagrama de Secuencia
c:Cliente <<create>> establecerAcciones establecerValores :Transaccion p:ProxyODBC

tiempo
exito

establecerValores

Lnea de vida

<<destroy>>

Foco de control
186

Diagrama de Colaboracin
1: <<create>> 2: establecerAcciones 6: <<destroy>>
c:Cliente 5: exito :Transac cion

3: establecerValores 4: establecerValores

p:Proxy ODBC

187

Diagrama de Secuencia
c:Cliente
<<create>> :AgenteBilletes

a:Ayuda Planificacion

establecerItinerario(i)
calcularRuta ruta

<<destroy>>

notificar

188

Diagrama de Colaboracin
3: calcularRuta

1: <<create>> 2: establecerItinerario(i) 5: <<destroy>> c:Cliente 4: ruta 6: notificar :Agente Billetes

a:Ayuda Planificacion

189

Uso de los diagramas de interaccin

Modelado del aspecto dinmico. Modelado del flujo de control que caracteriza el comportamiento de un sistema:
casos de uso colaboraciones patrones frameworks operaciones

190

Diagrama de Secuencia (Caso de uso)

: Cliente
iniciarCompra() nuevoCarroCompra(cliente)

: Interfaz Compra

: CarroCompra

: Producto

seleccProducto(cantidad) obtenerDescripcionDe(prod)

cargarProd(cliente,prod,cantidad)

confirmarCompra() confirmarCompraDe(cliente) decremStock(cantidad)

Realizar para cada producto incluido en el carro de compra

191

Diagrama de Colaboracin Caso de Uso)

1: iniciarCompra() 2: nuevoCarroCompra(cliente) 3: seleccProducto(cantidad) 5: cargarProd(cliente,prod,cantidad) 6: confirmarCompra() 7: confirmarCompraDe(cliente) : Interfaz : Carro : Cliente Compra Compra

4: obtenerDescripcionDe(prod) 8: decremStock(cantidad) : Producto

192

Diagrama de Secuencia

: Technical Responsible selectOrder()

: Launch Manufacturing GUI

:OrderManager

:EvaluatedOrders

o : Order

: OrderLine

: Product

: WorkOrder

selectOrder(cod) o:=find(cod)
launchManufacturing()

launchManufacturing(cod)

launch manufacturing() *generateWO() tpl:=getTemplate()

createWO(tpl)

193

Escenario de un proceso de negocio

traveler : Employee authorizer : Employee bookkeeper : Employee paymaster : Employee

travelPermissionRequest() travelPermission()

sendExpenseReport(anExpRep) expenseReportOk(anExpRep) payRequest(aTraveler)

194

Escenario de un proceso de negocio

: Cliente : Comercial : JefeTecnico : JefeProduccion

darCursoPedido()

estudiarPedido() * analizarFabricacionProducto()

planificarFabricacion() informarAnalisisPedido() acceptarPedido()

195

Patrn Observer
Subject subjectState Attach() Detach() Notify()

+observers 1..1 1..*

Observer

Update()

for all o in observers {o->update}

ConcreteSubject subjectState getState() setState()

+subject

ConcreteObserver observerState update() observerState= subject->getState()

196

Patrn Observer
: Subject SetState( ) Notify( ) one : Observer another : Observer

Update( )
GetState( ) Update( ) GetState( )

197

Patrn Observer
2: Notify( )

3: Update( ) : Subject 1: SetState( ) 4: GetState( ) one : Observer

6: GetState( )

5: Update( )

another : Observer

198

Colaboracin
ClienteDeGestor 1..* 1..1 Gestor 1..1 1..* 1..1 especifica necesita editar 1..1 editado con 1..* 1..* Editor FabricaDeEditor

0..*

ObjetoInformacion
1..*

199

Colaboracin
: ClienteDeGestor : Gestor : FabricaDeEditor : ObjetoInformacion : Editor

obtenerEditorPara(objInfo) obtenerInterfazSoportada() soportaInterfaz(nombreInterfaz)

crearEditorCon(objInfo) Crear&IniciarCon(objInfo)

200

Caso de Uso (Nivel alto de abstraccin)

: Cliente

:ReceptorPedido

:RealizacionPedido

enviarPedido

tramitarPedido

confirmarPedido

201

Caso de Uso (Nivel ms bajo de abstraccin)

: Cliente

:ReceptorPedidos enviarPedido

:AgenteTarjeta Credito

:RealizacionPedido

:AgenteFacturacion

procesarTarjeta

tramitarPedido

emitirFactura

confirmarPedido

202

Casos de Uso y Escenarios

Caso de Uso Buscar Pedido
1. Se inicia al seleccionar el usuario la opcin Buscar Pedido. 2. El sistema presenta la ventana Buscar Pedido. 3. El usuario introduce un ID de un pedido 4. El usuario arranca la bsqueda 5. El sistema realiza una bsqueda en la BD de pedidos. 6. El sistema visualiza datos pedido.

203

: Usuario

:Interfaz Cancelar Pedido visualizar ()

:Interfaz Buscar Pedido

: Base Datos

Encontrar Pedido ()

setIDPedido (IDPedido) buscarPedido () p:=getPedido (IDPedido)

visualizarPedido (p)

Diagramas de Secuencia: Procesos concurrentes y activaciones

new
unaTransaccin Mensaje Asncrono unCoordinadorde Transaccin

new

new
Activacin

unaPrimera Comprobacin unaSegunda Comprobacin

new

ok

Todo comprobado?

x
ok

validacin

Todo comprobado?
Objeto Autoeliminado

x
205

Diagramas de Secuencia vs. Diagramas de Colaboracin

Equivalencia semntica Simples para comportamientos simples. Si hay mucho comportamiento condicional, usar diferentes escenarios. Diagramas de secuencia muestran mejor el orden en que se ejecutan los mensajes Diagramas de colaboracin muestran claramente los objetos con que interacta un determinado objeto.

206

Diagramas de Actividades
Muestran un flujo de actividades. Es un caso especial de mquina de estados. Incluye:
estados actividad y estados accin transiciones objetos

Una actividad produce alguna accin que produce algn cambio en el sistema o retorna un valor.

207

Estados Accin y Estados Actividad

Un estado accin no se puede descomponer, representa una computacin atmica. Un estado actividad no es atmico, se compone de otros estados accin y actividad. Al entrar se ejecuta la accin o actividad, al terminar el flujo de control pasa a la siguiente accin o actividad. Misma notacin
Procesar Pedido
208

Transiciones
estado inicial transiciones
Planificar proceso

Asignar tareas

estado final

209

Bifurcacin

Planificar proceso
[materiales no disponibles]

Volver a planificar
[materiales disponibles]

Asignar tareas

210

Divisin y Unin
Preparar conversacin

divisin

Descomprimir

Gesticular Mover boca Emitir audio

unin
Limpieza
211

Solicitar Producto

Procesar Pedido
Extraer Articulos

Enviar Pedido

Recibir Producto

Facturar al cliente

Pagar Factura

Cerrar Pedido

Cliente

Ventas

Almacen

Solicitar Producto

Procesar Pedido
Extraer Articulos

Enviar Pedido

Recibir Producto

Facturar al cliente

Calles
Pagar Factura Cerrar Pedido

Cliente

Ventas

Almacen

Solicitar Producto

Procesar Pedido
Extraer Articulos

o: Pedido [en progreso]

Enviar Pedido

Recibir Producto

Facturar al cliente
b: Factura [impagada]

o: Pedido [completado]

Pagar Factura

Cerrar Pedido

Ejemplo
Pasajero Vendedor Airline

Solicitar pasaje

Verificar existencia vuelo Dar detalles vuelo Informar alternativas y precios

Seleccionar vuelo

Solicitar pago Pagar pasaje

Reservar plazas Confirmar plaza reservada

Emitir billete 215

: Cliente

: Comercial :Catalogo

: JefeTecnico

: JefeProduccion

Rellenar Pedido

p:Pedido [propuesto] :Plantilla de Produccion Cursar pedido p:Pedido [en_evaluacion]

Analizar viabilidad

p:Pedido [evaluado] Notificar rechazo de pedido Fin KO p:Pedido [rechazado] [ NO ] Viable ? [ SI ]

:Producto Especial

:Plantilla de Produccion

Notificar aceptacion de pedido

Ordenar fabricacion

:Orden de Trabajo [pendiente]

Planificar produccion p:Pedido [aceptado]

Fin OK

Utilidad de los diagramas de actividades

Modelado de flujos de trabajo (workflow) como son los procesos de negocio (business process). Se puede asociar a cualquier elemento de modelado, pero lo ms normal es asociarlo a una operacin: diagrama de flujo de las acciones.

217

Eventos
Un evento es un acontecimiento que ocupa un lugar en el tiempo y espacio. Un evento es un estmulo que dispara una transicin en una mquina de estados. Eventos externos vs. Eventos internos. Tipos de eventos:
Seales (excepciones) Llamadas Paso de tiempo Cambio de estado
218

Modelado Excepciones
<<exception>> Excepcion establecerManejador() primerManejador() ultimoManejador()

<<exception>> Duplicado

<<exception>> Overflow

<<exception>> Underflow

Conjunto aadir() eliminar()

<<send>>

<<send>>

<<send>>

Estados
Un estado es una situacin en la vida de un objeto en la que satisface cierta condicin, realiza alguna actividad o espera algn evento. Elementos de un estado
Nombre Acciones entrada/salida Transiciones internas Subestados Eventos diferidos
220

Estados

accin entrada transicin interna evento diferido

Rastreando entry/ activarModo(enRastreo) exit / activarModo(noRastreo) nuevoObjetivo/rastreador.adquirir do / seguirObjetivo autotest / defer

accin salida actividad

221

Transiciones
Una transicin de un estado A a un estado B, se produce cuando se origina el evento asociado y se satisface la condicin especificada, en cuyo caso se ejecuta la accin de salida de A, la accin de entrada a B y la accin asociada a la transicin. Elementos de una transicin:
Estados origen y destino Evento de disparo Condicin de guarda Accin
222

Mquina de estados
Especifica la secuencia de estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos, junto con sus respuestas a esos eventos.
til si las instancias de una clase tienen un comportamiento que depende de su historia o que deben responder a eventos externos: objetos reactivos. Se representa mediante un diagrama de estados.

223

After (2 sec) send c.estaActivo

ruido Inactivo

Buscando

Configuracin

objetivoEn(p) [representaAmenaza] / t.aadirObjetivo(p)

Rastreando

Acoplamiento

contactar

224

Modificar hoja

Finaliza S.A.D.

Pendiente de aceptacin

Modificacin por pedido urgente

Administrador acepta hoja Administrador rechaza hoja

No aceptada

Pendiente de envo a factora

Envo a factora

En realizacin

Hojar rutas realizada

Realizada

Inicio

Pendiente de envo a Bualgas

Envo a Bualgas

Pendiente de anlisis

Factible[ Analizado ]

Viable

No factible[ Analizado ]

Envo a jefe

Rechazado
Comunicacion de Rechazo a Central

No aprobado[ Estudiado ] Modificar hoja Administrador rechaza hoja Asignado a Hoja de Rutas Modificar hoja
Envo a factora

Pendiente de aprobacin

Aprobado[ Estudiado ]

Aprobado

Finaliza S.A.D
No realizado[ Hoja Rutas realizada ]

Aprobado

Pendiente de realizacin

No realizado

Realizado[ Hoja Rutas realizada ]

Realizado

Subestados secuenciales
introducirTarjeta Activo entry/leerTarjeta exit/expulsarTarjeta [continuar]
Procesando

Inactivo
Validacin

cancelar mantener
Seleccin

Mantenimiento

[no continuar]
Impresin

227

Subestados secuenciales
Siguiente_item [No todo items chequeado]

Activo
Chequeando Do/chequeo
[Todo item chequeado y disponible]

Enviando
Do/Iniciar_ entrega

[Todo item chequeado y alguno no disponible]

Esperando
Item Recibido [algn item no disponible] cancelado

Item Recibido [todo item disponible]

Cancelado

Entregado

228

Subestados concurrentes
Mantenimiento mantener Pruebas
Probar perifericos AutoDiagnosis

Inactivo

Manejo Ordenes
Espera

[continuar] Orden Pulsar tecla

[no continuar]

229

Componentes

Un componente es una parte fsica y reemplazable de un sistema, que conforma con un conjunto de interfaces y proporciona su implementacin. Modela artefactos tales como: ejecutables, bibliotecas, tablas, ficheros, documentos,.. Representa el empaquetamiento fsico de elementos lgicos tales como clases, interfaces,.. Residirn en los nodos del sistema
230

Componentes
explorador.java

agenteFraudes.dll

Realiza agenteFraudes politicaFraudes busquedaPatrones

231

Componentes

explorador.java

JerarquaElementos

arbol.java

El componente arbol.java puede ser reemplazado por otro que proporcione la interfaz JerarquaElementos.

Estereotipos: executable, library, file, table, document

232

Tipos de componentes
Despliegue
Necesarios y suficientes para formar un sistema ejecutable: libreras dinmicas(dll), ejecutables (exe),..

Productos del trabajo

Permanecen al final del proceso de desarrollo: archivos cdigo fuentes, ficheros de datos,.. Con ellos se crean los componentes de despliegue

De ejecucin
Se crean durante la ejecucin: objeto COM, instanciado a partir de una dll.
233

Diagrama de Componentes
Modelado de ejecutables y bibliotecas Modelado de cdigo fuente Modelado de una API

234

Modelado de ejecutables

v.exe

Vwbas20.dll

vwdev20.dll

vwsrc20.dll

235

Ejemplo
Control y Anlisis Interf az de Terminal Comment Comment

Gestin de Cuentas Comment

Rutinas de Coneccion Comment

Acceso a BD Comment

236

Nodos
Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional que puede tener memoria y capacidad de procesamiento. Los componentes se ejecutan en nodos Los nodos representan el despliegue fsico de los componentes.

237

Diagramas de Despliegue
Muestra la configuracin de los nodos que participan en la ejecucin y de los componentes que residen en los nodos. Incluye nodos y arcos que representan conexiones fsicas entre nodos. Modelado de sistemas empotrados, sistemas clienteservidor, sistemas distribuidos.

238

Diagrama de Despliegue

terminal

<<10-T-Ethernet>>

servidor

Unidad RAID

<<RS-232>> Consola

239

Modem

<<procesador> servidor cache

<<procesador>> servidor cache

internet

<<red>> red local

<<procesador> servidor principal

<<procesador> servidor

<<procesador>> servidor

<<procesador>> servidor

240

Colaboraciones
Sociedad de clases, interfaces y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de los elementos.
Parte estructural (diagrama de clases) y parte de comportamiento (diagrama de secuencia).

241

Colaboraciones
El ncleo de la arquitectura de un sistema est formado por un conjunto de colaboraciones que representan las decisiones de diseo ms importantes. Un sistema orientado a objetos bien estructurado se compone de un conjunto relativamente pequeo de colaboraciones. Modelado de un caso de uso, operacin o mecanismo (patrn o framework)
242

Casos de uso y Colaboraciones

caso de uso colaboracin

Hacer Pedido

Gestin Pedidos

realizacin

243

Gestor Documentos (Parte esttica)

ClienteDeGestor 1..* 0..* necesita editar 1..1

Gestor 1..1 1..*

FabricaDeEditor

1..1 especifica 1..1 editado con 1..* 1..* Editor

ObjetoInformacion 1..*

244

Gestor Documentos (Comportamiento)

: ClienteDeGestor : Gestor : FabricaDeEditor : ObjetoInformacion : Editor

obtenerEditorPara(objInfo)

obtenerInterfazSoportada() soportaInterfaz(nombreInterfaz)

crearEditorCon(objInfo)

Crear&IniciarCon(objInfo)

245

Colaboraciones Parametrizadas
Modelado de patrones de diseo
Subject Observer
Observer Subject Observer

Alarma

Ventana
246

Patrn de diseo (Parte Esttica)

Subject subjectState Attach() Detach() Notify()

+observers 1..1 1..*

Observer

Update()

for all o in observers {o->update}

ConcreteSubject subjectState getState() setState()

+subject

ConcreteObserver observerState update() observerState= subject->getState()

247

Patrn de diseo (Parte dinmica)

: Subject SetState( ) Notify( ) one : Observer another : Observer

Update( ) GetState( ) Update( ) GetState( )

248