Curso OOcon UML

Formacin de Postgrado, Departamento de Sistemas Informticos y Computacin Universidad Politcnica de Valencia Junio 2000
Anlisis y Diseo Orientado a Objetos usando la notacin UML

Patricio Letelier Torres Pedro Snchez Palma
{letelier, ppalma}@dsic.upv.es
Departamento Sistemas Informticos y Computacin Universidad Politcnica de Valencia (Espaa)

Formacin de Postgrado, Valencia, Junio de 2000
1
" www.dsic.upv.es/~uml
Contenido
Introduccin a Modelado de SI Un Breve Tour por UML El Paradigma Orientado a Objetos Fundamentos del Modelado OO Captura de Requisitos Modelado de Interacciones Modelado de la Estructura del Sistema Diagramas de Estados Modelado de Componentes Modelado de Distribucin Hacia un proceso de Desarrollo usando UML Conclusiones
xito en Desarrollo de SI
Notacin
Herramientas
Proceso
3
Abstraccin - Modelado Visual

El modelado captura las partes esenciales del sistema
Orden Item
envo
Proceso de Negocios Sistema Computacional

4
MV para manejar la complejidad
5
MV para definir la Arquitectura del Software

Interface de Usuario (Visual Basic, Java, ..) Lgica del Negocio (C++, Java, ..)
Servidor de BDs (C++ & SQL, ..)
Modelar el sistema independientemente del lenguaje de implementacin

MV promueve la reutilizacin
Multiples Sistemas
Componentes Reutilizados
7
Un Breve Tour por UML
8
Qu es UML?
UML = Unified Modeling Language Un lenguaje de propsito general para el modelado orientado a objetos UML combina notaciones provenientes desde:
Modelado Orientado a Objetos Modelado de Datos Modelado de Componentes Modelado de Flujos de Trabajo (Workflows)
9
Situacin de Partida
Diversos mtodos y tcnicas OO, con muchos aspectos en comn pero utilizando distintas notaciones Inconvenientes para el aprendizaje, aplicacin, construccin y uso de herramientas, etc. Pugna entre distintos enfoques (y correspon-dientes gurs)
=> Necesidad de una notacin estndar
10
Historia de UML
Comenz como el Mtodo Unificado, con la participacin de Grady Booch y Jim Rumbaugh. Se present en el OOPSLA95. El mismo ao se uni Ivar Jacobson. Los Tres Amigos son socios en la compaa Rational Software. Herramienta CASE Rational Rose.
11
Historia de UML
2001 ? 2000 ? 1999 1998 Nov 97
UML aprobado por el OMG
UML 2.0 UML 1.4 UML 1.3 UML 1.2

Revisiones menores
12
Participantes en UML 1.0

Rational Software
(Grady Booch, Jim Rumbaugh y Ivar Jacobson)
Digital Equipment Hewlett-Packard i-Logix (David Harel) IBM ICON Computing

(Desmond DSouza)
Intellicorp and James Martin & co. (James Odell)
MCI Systemhouse Microsoft ObjecTime Oracle Platinium Technology Sterling Software Taskon Texas Instruments Unisys
13
UML aglutina enfoques OO

Rumbaugh Booch Odell Shlaer-Mellor
Object life cycles
Jacobson Meyer
Pre- and Post-conditions
UML
State Charts
Harel
Gamma et. al.

Frameworks, patterns, notes
Embly
Singleton classes
Wirfs-Brock Fusion
Responsabilities Operation descriptions, message numbering
14
Aspectos Novedosos
Definicin semi-formal del Meta-Modelo semntico asociado Incluye stereotypes como mecanismo de extensibilidad. Mediante stereotypes los elementos de modelado pueden diferenciarse de acuerdo a un uso particular Incluye un lenguaje para expresar restricciones mediante frmulas bien formadas. OCL (Object Constraint Language) desarrollado por IBM
15
Mtodos Formales en Modelado

Tipos de enfoques:
no-formales, usando lenguaje natural semi-formales, notaciones (en parte graficas) con ciertas reglas y cuyas construcciones tienen una semntica ms o menos precisa formales, usando una notacin grfica o textual basada en un sistema formal (soporte matemtico)
Los mtodos formales permiten determinar y expresar con mayor rigor las propiedades del software. Sin embargo, an no son ampliamente utilizados.
16
Mtodos Formales en Modelado

Las principales mejoras al utilizar mtodos formales son:
Mayor rigor en la especificacin Mejores condiciones para realizar la verificacin y validacin en forma ms exhaustiva Mejores condiciones para automatizacin de procesos de generacin automtica de prototipos y/o cdigo final
17
Inconvenientes en UML
Definicin del proceso de desarrollo usando UML. UML no es una metodologa Falta integracin con respecto de otras tcnicas tales como patrones de diseo, interfaces de usuario, documentacin, etc. Ejemplos aislados Monopolio de conceptos, tcnicas y mtodos en torno a UML
18
Perspectivas de UML
UML ser el lenguaje de modelizacin de objetos estndar predominante los prximos aos Razones:
Participacin de metodlogos influyentes Participacin de importantes empresas Aceptacin del OMG como notacin estndar Herramientas que proveen la notacin UML Edicin de libros Congresos, cursos, camisetas, etc.
Evidencias:
19
Uso de UML
El objetivo de UML es describir cualquier tipo de sistema en trminos de diagramas orientados a objetos Algunas categoras de Sistemas
Sistemas de Informacin Sistemas de Tiempo Real Sistemas Embebidos Sistemas Distribuidos Software de Sistemas Sistemas de Negocios
20
10
Modelado con UML

Use Case Use Case Diagrams Diagramas de Use Case Diagrams Use Case Casos de Uso Diagramas de Diagrams Diagrams Secuencia Scenario Scenario Diagrams Diagramas de Diagrams Colaboracin Scenario Scenario de Diagramas Diagrams Diagrams Estados State State Diagrams Diagramas de Diagrams Clases State State Diagrams Diagramas de Diagrams Objetos State State Diagrams Diagramas de Diagrams Componentes
Component Component Diagrams Diagramas Diagrams de
Modelo
Diagramas de Actividad
Distribucin
Un modelo es una descripcin completa de un sistema desde una perspectiva concreta

21
Tipos de Diagramas UML

Diagrama de Casos de Uso Diagrama de Clase (incluyendo Diagrama de Objetos) Diagramas de Comportamiento Diagrama de Estados Diagrama de Actividad Diagramas de Interaccin Diagrama de Secuencia Diagrama de Colaboracin Diagramas de implementacin Diagrama de Componentes Diagrama de Despliegue
22
11
Paquetes en UML
Los paquetes ofrecen un mecanismo general para la particin de los modelos y la agrupacin de los elementos de modelado Se representan grficamente como:
Nombre de paquete
23
Paquetes en UML
Cada paquete corresponde a un subconjunto del modelo y contiene, segn el modelo, clases, objetos, relaciones, componentes y diagramas asociados La arquitectura del sistema viene dada en forma de paquetes y por las relaciones de dependencia entre ellos Los estereotipos <<Categora>> y <<Subsistema>> permiten distinguir los paquetes de la vista lgica y los de realizacin, respectivamente
24
12
Paquetes en UML
Un paquete puede contener a otros, sin lmite de anidamiento Un nivel dado puede contener paquetes y adems otros elementos de modelado (por ejemplo Diagramas de Clases y de Interaccin) Cada elemento pertenece a slo un paquete Una clase de un paquete puede aparecer en otro paquete por la importacin a travs de una relacin de dependencia entre paquetes
25
Paquetes en UML
Las importaciones entre paquetes se representan por medio de una relacin de dependencia estereotipada y orientada del cliente al proveedor Esto implica que al menos una clase del paquete cliente usa los servicios ofrecidos por al menos una clase del paquete proveedor (alguna clase en el paquete cliente hereda de, usa o depende de clases del proveedor) Una clase depende de otra si accede a un valor del proveedor, invoca a una operacin o referencia al proveedor como argumento en alguna operacin
26
13
Paquetes en UML
Todas las clases no son necesariamente visibles desde el exterior del paquete El operador :: permite designar una clase definida en un contexto distinto del actual Por ejemplo, la expresin Ventas::Producto designa la clase Producto definida en el paquete Ventas Un paquete encapsula a la vez que agrupa
27
Paquetes en UML
Los paquetes tambin poseen una interfaz y una implementacin Cada elemento de un paquete se incluye como visible o no desde el exterior del paquete Slo las clases pblicas aparecen en la interfaz del paquete No debe haber relaciones cclicas entre paquetes
28
14
Prctica 1
Paquetes en UML
Ejemplo:
Personal
Ventas
Representante de Ventas
Cliente
29
Diagramas de Casos de Uso

Casos de Uso es una tcnica para capturar informacin de cmo un sistema o negocio trabaja actualmente, o de cmo se desea que trabaje No pertenece realmente al enfoque orientado a objeto, ms bien es una tcnica para el modelado de escenarios en los cuales el sistema debe operar
30
15
Diagramas de Casos de Uso

Cada Caso de Uso puede estar definido por:
texto que lo describe secuencia de pasos ejecutados dentro del escenario condiciones pre-post para que el escenario comience o termine mezclando las anteriores
Un Caso de Uso es representado por una elipse y describe una situacin de uso del sistema interactuando con actores Un actor es un agente, alguien o algo que solicita un servicio al sistema o acta como catalizador para que ocurra algo
31
Ejemplos
Verificar Situacin Vendedor
Realizar Venta
Secretaria Cliente
Preparar Catlogo
Supervisor Establecer Crdito
32
16
Ejemplos
Venta Normal
Venta en Rebajas Cliente Vendedor
Venta en Oferta
33
Ejemplos
Realizar prstamo Socio Encargado
tarjeta caducada <<extends>>
Solicitar nueva tarjeta
34
17
Prctica 2
Ejemplos
Reintegro cuenta corriente
<<uses>>
Cliente
Validar operacin <<uses>>
Reintegro cuenta crdito
35
Diagramas de Secuencia
Los Diagramas de Secuencia y de Colaboracin son usados para establecer un escenario del sistema, determinando los objetos y mensajes involucrados Un Diagrama de Secuencia muestra los objetos de un escenario mediante lneas verticales y los mensajes entre objetos como flechas conectando objetos Los mensajes son dibujados cronolgicamente desde arriba hacia abajo
36
18
Ejemplo
: Socio : Encargado Coger libro : Libro : Ficha socio : Ficha libro : Prstamo
Solicitar prstamo Verificar situacin socio Situacin socio ok Verificar situacin libro Situacin libro ok Introducir prstamo Autorizar prstamo
37
Diagramas de Colaboracin
El Diagrama de Colaboracin modela la interaccin entre los objetos de un Caso de Uso Los objetos estn conectados por enlaces (links) en los cuales se representan los mensajes enviados acompaados de una flecha que indica su direccin El Diagrama de Colaboracin ofrece una mejor visin del escenario cuando el analista est intentando comprender la participacin de un objeto en el sistema
38
19
Prctica 3
Ejemplo
1: Coger libro : Libro
: Socio
2: Solicitar prstamo 3: Verificar situacin socio
: Ficha s ocio
8: Autorizar prstamo 4: Situacin socio ok
6: Situacin libro ok
: Encargado : Prsta mo
7: Introducir prstamo
5: Verificar situacin libro : Ficha li bro
39
Diagramas de Clases (y objetos)

El Diagrama de Clases es el diagrama principal para el anlisis y diseo Un diagrama de clases presenta las clases y objetos del sistema con sus relaciones estructurales y de herencia La definicin de clase u objeto incluye definiciones para atributos y mtodos El trabajo realizado en los D. de Casos de Uso, D. de Secuencia y D. de Colaboracin aporta informacin para establecer las clases, objetos, atributos y mtodos
40
20
Ejemplos (Clase y Visibilidad)
Alumno DNI : char[10] NroExpediente : int Nombre : char[50] Alta(argname) PonerNota(asignatura : char *, ao : int, nota : float) Matricular(cursos : asignatura *, ao : int) ListarExpediente()
41
Ejemplos (Asociacin)
Departamento
depto profesor 1..* Profesor
Nro. despacho 0..1 dirige director 1
42
21
Ejemplos (Clase Asociacin)

empleador Empresa * 1..* trabajador Empleado
Cargo nombre sueldo +superior 0..1
1..* +subordinado
43
Ejemplos (Generalizacin)
Empleado
{disjunta, completa}
Directivo
Administrativo
Obrero
44
22
Prcticas 4-8
Ejemplos
Motor 1..4 Piloto 1..2 Vendedor de billetes 1
1 Avin 1 *
* Vuelo * 1 *
* Reserva
{ disjunta, completa }
1 Avin militar Avin comercial Lnea area
{ disjunta, completa }
Avin de carga
Avin de pasajeros 45
Diagramas de Estados
El Diagrama de Estados modela el comporta-miento de una parte del sistema a travs del tiempo Tpicamente se elabora un diagrama de Estados para cada clase que tenga un comportamiento significativo El comportamiento es modelado en trminos del estado en el cual se encuentra el objeto, qu acciones se ejecutan en cada estado y cul es el estado al que transita despus de un determinado evento
46
23
Ejemplo
Prestar Devolver[ Nmero prstamos = 1 ] Con prstamos Nmero prstamos > 1 Socio Biblioteca Nmero : int Nombre : char[50] Nmero prstamos : int = 0 Alta() Baja() Prestar(CdigoLibro : int, Fecha : date) Devolver(CdigoLibro : int, Fecha : date)
Prestar Devolver[ Nmero prstamos = 1 ]
Sin prstamos Alta Baja
Nmero prstamos = 0
47
Caso especial de Diagrama de Estados donde:
Todos (o la mayora de) los estados son estados de accin Todas (la mayora de) las transiciones son disparadas como consecuencia de la finalizacin de la la accin.
El Diagrama puede estar asociado a:

Una clase La implementacin de una operacin Un Caso de uso
48
24
Ejemplos
Buscar Bebida [no hay caf] [no zumo] [hay zumo] [hay caf Poner caf en filtro Aadir agua al depsito Coger taza Coger zumo
Poner filtro en mquina
Encender mquina ^cafetera.On Caf en preparacin indicador de fin Servir caf Beber
49
Prctica 9
Ejemplos (Swim lines)

Pasajero Vendedor Airline
Solicitar pasaje Verificar existencia vuelo Dar detalles vuelo Informar alternativas y precios Seleccionar vuelo
Solicitar pago
Reservar plazas Confirmar plaza reservada
Pagar pasaje Emitir billete
50
25
Diagramas Componentes
Un diagrama de Componentes permite modelar la estructura del software y la dependencia entre componentes Un componente es un grupo de clases que trabajan estrechamente. Los componentes pueden corresponder cdigo fuente, binario o ejecutable Una relacin de dependencia indica que un componente utiliza otro, por lo cual depende de l
51
Ejemplo
Control y Anlisis Interfaz de Terminal Comment Comment
Gestin de Cuentas Comment
Rutinas de Coneccion Comment
Acceso a BD Comment
52
26
Diagramas de Distribucin
El Diagrama de Distribucin modela la distribucin en tiempo de ejecucin de los elementos de procesamiento y componentes de software, junto a los procesos y objetos asociados En el Diagrama de Distribucin se modelan los nodos y la comunicacin entre ellos Cada nodo puede contener instancias de componentes
53
Prctica 10
Ejemplo
Servidor Central Acceso a BD Comment Control y Anlisis Comment
Rutinas de Coneccion
Terminal de Consulta Rutinas de Coneccion
Interfaz de Terminal Comment
Punto de Venta
Rutinas de Coneccion Comment
Gestin de Cuentas Comment
Interfaz de Terminal Comment
54
27
Relacin entre Diagramas

Diagramas de Distribucin Diagramas de Clases Diagramas de Componentes
Casos de Uso
C D I G O
55
El Paradigma Orientado a Objetos
56
28
Por qu la Orientacin a Objetos?

Proximidad de los conceptos de modelado respecto de las entidades del mundo real

Mejora captura y validacin de requisitos Acerca el espacio del problema y el espacio de la solucin
Modelado integrado de propiedades estticas y dinmicas del mbito del problema
Facilita construccin, mantenimiento y reutilizacin
57
Por qu la Orientacin a Objetos?

Conceptos comunes de modelado durante el anlisis, diseo e implementacin

Facilita la transicin entre distintas fases Favorece el desarrollo iterativo del sistema Disipa la barrera entre el qu y el cmo
Sin embargo, existen problemas ...
58
29
Problemas en OO
...Los conceptos bsicos de la OO se conocen desde hace dos dcadas, pero su aceptacin todava no est tan extendida como los beneficios que esta tecnologa puede sugerir ...La mayora de los usuarios de la OO no utilizan los conceptos de la OO de forma purista, como inicialmente se pretenda. Esta prctica ha sido promovida por muchas herramientas y lenguajes que intentan utilizar los conceptos en diversos grados
--Wolfgang Strigel
59
Problemas en OO
Un objeto contiene datos y operaciones que operan sobre los datos, pero ... Podemos distinguir dos tipos de objetos degenerados:
Un objeto sin datos (que sera lo mismo que una biblioteca de funciones) Un objeto sin operaciones, con slo operaciones del tipo crear, recuperar, actualizar y borrar (que se correspondera con las estructuras de datos tradicionales)
Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetos Las aplicaciones de gestin estn constituidas mayoritariamente por objetos degenerados
60
30
OO y Aplicaciones de Gestin
Las expectativas depositadas en la OO no se cumplen cuando se usa en las aplicaciones de gestin, pero Por qu invierten las compaas en el desarrollo OO? Esperan que las ventajas que se supone va a ofrecer se hagan realidad Necesitan IGU y tecnologa Cliente/Servidor Estan satisfechas con las tcnicas de modelado de datos que ofrece la OO, si no han tenido experiencias previas con otras tcnicas de modelado
61
Resumen Situacin Actual Notacin Herramientas - Proceso

Anlisis
Enfoque Estructurado
Diseo DEs
Modelo Relacional Modelo Relacional !!
Implementacin
Entornos de Programacin Visual
DFDs E-R
Diagramas de Casos de Uso Diagramas de Actividad Diagramas de Secuencia Diagramas de Colaboracin Diseo de Interfaces
Enfoque OO
Diagrama de Clases Diagrama de Estados Diagramas de Actividad
Bases de Datos (Objeto-) Relacionales
62
31
Fundamentos del Modelado Orientado a Objetos
63
Objetos
Objeto = unidad atmica que integra estado y comportamiento. El encapsulamiento de un objeto asegura una alta cohesin y un bajo acoplamiento. Un objeto puede caracterizar una entidad fsica (coche) o concepto (ecuacin matemtica).
64
32
Objetos
El Modelado de Objetos permite representar el ciclo de vida de los objetos a travs de sus interacciones En UML, un objeto se representa por un rectngulo con un nombre subrayado
Otro Objeto ms Otro Objeto
65
Un Objeto
Objetos
Ejemplo de varios objetos relacionados:
Dos clientes del banco
Felipe
Cuenta corriente Libreta de ahorro a plazo
Juan Libreta de ahorro Cuenta corriente
66
33
Objetos
Objeto = Identidad + Estado + Comportamiento El estado est representado por los valores de los atributos Un atributo toma un valor en un dominio concreto
Un coche Azul 979 Kg 70 CV ...
67
Identidad
Oid (Object Identifier) Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las siguientes caractersticas:
Constituye un identificador nico y global para cada objeto dentro del sistema. Es determinado en el momento de la creacin del objeto. Es independiente de la localizacin fsica del objeto, es decir, provee completa independencia de localizacin.
68
34
Identidad
Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de estructura No cambia durante toda la vida del objeto. Adems, un oid no se reutiliza aunque el objeto deje de existir No se tiene ningn control sobre los oids y su manipulacin resulta transparente
Sin embargo, es preciso contar con algn medio para hacer referencia a un objeto utilizando referencias del dominio (valores de atributos)
69
Estado
El estado evoluciona con el tiempo Algunos atributos pueden ser constantes El comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto Las operaciones de un objeto son consecuencia de un estmulo externo representado como mensaje enviado desde otro objeto
70
35
Comportamiento
Ejemplo de interaccin:
Otro objeto
Un mensaje Operacion 2
Un objeto
Operacion 1
71
Comportamiento
Los mensajes navegan por los enlaces, a priori en ambas direcciones Estado y comportamiento estn relacionados Ejemplo: no es posible aterrizar un avin si no est volando. Est volando como consecuencia de haber despegado del suelo
72
36
Persistencia
La persistencia de los objetos designa la capacidad de un objeto transcender en el espacio/tiempo. Un objeto persistente conserva su estado en un sistema de almacenamiento permanente Podremos despus reconstruirlo (materializacin del objeto). Por defecto no los consideramos persistentes
73
Persistencia
Los lenguajes OO no proponen soporte adecuado para la persistencia Esto obliga a recurrir a artificios externos para asegurar la persistencia
74
37
Comunicacin
Un sistema informtico puede verse como un conjunto de objetos autnomos y concurrentes que trabajan de manera corrdinada en la consecucin de un fin especfico El comportamiento global se basa pues en la comunicacin entre los objetos que la componen
75
Comunicacin
El estudio de las formas de comunicacin entre objetos es primordial en el modelo de objetos Los objetos interactan para realizar las funciones de la aplicacin Segn la naturaleza de las interacciones es posible describir el comportamiento de los objetos
76
38
Comunicacin
Categoras de comportamiento:
Actores o clientes Servidores Agentes
Actores: objetos en el origen de una interaccin. Poseen un hilo de ejecucin (thread) y pasan el testigo a otros objetos Servidores: No son nunca el origen de una interaccin. Son los receptores de los mensajes
77
Comunicacin
Ejemplo: Un actor pasa el testigo a un servidor y espera el fin del servicio antes de continuar su ejecucin
Un actor Un servidor
78
39
Comunicacin
Los agentes renen las caractersticas de actores y servidores. Pueden interactuar por iniciativa propia o por una solicitud externa Son la base del mecanismo de delegacin Introducen indireccin: un cliente puede comunicarse con un servidor que no conoce directamente
79
Comunicacin
Ejemplo en el que un agente hace de aislante:
Enrutamiento dinmico
Un agente
Sevidor 1
Servidor 2 Un cliente
Aislante
80
40
El Concepto de Mensaje
La unidad de comunicacin entre objetos se llama mensaje El mensaje es el soporte de una comunicacin que vincula dinmicamente los objetos que fueron separados previamente en el proceso de descomposicin Permite la interaccin de manera flexible Asegura la delegacin de tareas
81
Es un integrador dinmico que permite reconstruir una funcin de la aplicacin por la puesta en marcha de la colaboracin entre un grupo de objetos Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinmico
82
41
Objeto 1 : Mensaje A Objeto 2
: Mensaje C Objeto 3
: Mensaje E Objeto 4
: Mensaje D
83
Sincronizacin
Las formas de sincronizacin describen la naturaleza de los mecanismos de comunicacin entre objetos Consideraremos 5 categoras de mensajes:
Envo Envo Envo Envo Envo de mensaje simple de mensaje sncrono de mensaje esperado de mensaje cronometrado de mensaje asncrono
84
42
Sincronizacin
Envo de mensaje simple:
Un solo hilo de ejecucin El objeto activo pasa el control al objeto pasivo
Un cliente
: Envo simple Otro objeto
85
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
86
43
Sincronizacin
Envo de mensaje esperado:
Se desencadena la operacin slo si el servidor est previamente esperando el mensaje
Un cliente
: Envo esperado
Otro objeto
87
Sincronizacin
Envo de mensaje cronometrado:
El cliente estar bloqueado durante un tiempo dado esperando la atencin del mensaje por el destinatario Tras el tiempo fijado el cliente se libera
: Envo cronometrado Un cliente Otro objeto

88
44
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
Un cliente
: Envo asncrono
Otro objeto
89
Captura de Requisitos
90
45
Casos de Uso
Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario Permiten definir los lmites del sistema y las relaciones entre el sistema y el entorno Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementacin Contexto similar al de los tradicionales DFDs
91
Casos de Uso
Los Casos de Uso cubren la carencia existente en mtodos previos (OMT, Booch) en cuanto a la determinacin de requisitos Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categora de usuarios que participan en el mismo Estn basado en el lenguaje natural, es decir, es accesible por los usuarios
92
46
Casos de Uso
El modelo de los Casos de Uso comprende los actores, el sistema y los propios casos de uso El conjunto de funcionalidades de un sistema se determina examinando las necesidades funcionales de cada actor, expresadas en forma de interacciones
93
Casos de Uso
Ejemplo:
Sistema
Caso de uso X
Actor A Actor B
Caso de uso Y
94
47
Casos de Uso
Los actores se deteminan observando:
Usuarios directos del sistema Responsables del uso o mantenimiento del sistema Otros sistemas que interactan con el sistema en cuestin
La misma persona fsica puede interpretar varios papeles como actores distintos El nombre del actor describe el papel desempeado
95
Casos de Uso
La determinacin de los actores permite delimitar el alcance del sistema de manera progresiva Categoras de actores:
Principales: personas que usan el sistema Secundarios: personas que mantienen o administran el sistema Material externo: dispositivos materiales imprescindibles que forman parte del mbito de la aplicacin y deben ser utilziados Otros sistemas: sistemas con los que el sistema interacta
96
48
Casos de Uso
Tras localizar los actores, procede el describirlos Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interaccin, los escenarios, desde el punto de vista del usuario Un escenario es una instancia de un caso de uso Los casos de uso intervienen durante todo el ciclo de vida
97
Casos de Uso: Relaciones

UML define cuatro tipos de relacin en los Casos de Uso:
De Comunicacin:
Actor Caso de Uso
98
49

De Uso: una instancia del Caso de Uso origen comprende tambin el comportamiento descrito por el Caso de Uso destino
<<uses>> Caso de uso destino Caso de uso origen
En UML 1.3 se estereotipa como <<includes>>

99

De Extensin: el Caso de Uso origen el comportamiento del Caso de Uso destino
<<extends>> Caso de uso destino Caso de uso origen
100
50

De Herencia: el Caso de Uso fuente hereda la especificacin del Caso de Uso destino
Caso de uso destino Caso de uso origen
101

Ejemplo:
<<extends>> Giro por Internet Cliente <<includes>> Giro
Identificacin
102
51
Casos de Uso: Construccin

Un caso de uso debe ser simple, inteligible, claro y conciso Generalmente hay pocos actores asociados a cada Caso de Uso Preguntas clave:
cules son las tareas del actor? qu informacin crea, guarda, modifica, destruye o lee el actor? debe el actor notificar al sistema los cambios externos? debe el sistema informar al actor de los cambios internos?
103

Los Casos de Uso pueden presentarse en distintas vistas (un actor con todos sus casos de uso, un caso de uso con todos sus actores, etc.) La descripcin del Caso de Uso comprende:
el inicio: cundo y qu actor lo produce? el fin: cundo se produce y qu valor devuelve? la interaccin actor-caso de uso: qu mensajes intercambian ambos?
104
52

objetivo del caso de uso: qu lleva a cabo o intenta? cronologa y origen de las informaciones repeticiones de comportamiento: qu operaciones son iteradas? situaciones opcionales: qu ejecuciones alternativas se presentan en el caso de uso?
Un caso de uso puede tambin ser descrito mediante un diagrama de actividades

105
Casos de Uso: Test

Los casos de uso permiten realizar dos tipos de test: verificacin y validacin Verificar significa confirmar que el sistema se desarrolla correctamente Validar asegura que el sistema bajo desarrollo es el que el usuario realmente quiere
106
53
Casos de Uso: Test

Cuando un modelo de casos de uso se completa entonces dicho modelo es presentado y discutido con usuarios y clientes Los usuarios deben validar que el modelo encaja perfectamente en sus necesidades y que les ofrece la funcionalidad deseada
107
Casos de Uso: Realizacin

La realizacin de los Casos de Uso es la transformacin de los distintos pasos y acciones que lo describen en clases, operaciones y relaciones entre clases Esto se consigue localizando las distintas responsabilidades de cada paso del Caso de Uso en las clases que lo realizan
108
54

La responsabilidad total de una clase es la integracin de todos los roles que desempea en los distintos Casos de Uso Por otro lado, los escenarios se representarn como Diagramas de Interaccin o de Actividad. Jacobson propone distinguir tres tipos de objetos:
de frontera (boundary objects) de control (control objets) de entidad (entity objects)
109

Bounday Objects:
Estos objetos estn cerca de los lmites del sistema. Interacta con los actores que estn fuera del sistema y pasan mensajes desde y hacia el interior del sistema.
Control Objects:
Estos objetos controlan las interacciones entre un grupo de objetos. A veces slo existen durante la ejecucin del Caso de Uso.
Entity Objects:
Representan entidades del dominio. Son normalmente pasivos. Suelen ser persistentes y participar en diversos Casos de Uso.
110
55
Prctica 11

El proceso de construccin es iterativo, esto es, la realizacin del Caso de Uso puede implicar su modificacin Los Casos de Uso permiten centrarse en la funcionalidad del sistema En mtodos OO que carecen de una tcnica de captura de requisitos el anlisis comienza particionando el sistema en clases
111
Modelado de Interacciones
112
56
Interaccin
Los objetos interactan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interaccin muestran cmo se comunican los objetos en una interaccin Existen dos tipos de diagramas de interaccin: los diagramas de colaboracin y los diagramas de secuencia
113
Diagramas de interaccin
Los Diagramas de Secuencia estn bien adaptados para representar interacciones Los Diagramas de Colaboracin se prestn ms al descubrimiento de abstracciones pues permite representar los objetos en una disposicin prxima a la realidad Es frecuente empezar por uno de Colaboracin y pasar despus a Secuencia
114
57
Muestra la secuencia cronolgica de mensajes entre objetos durante un escenario concreto Cada objeto viene dado por una barra vertical El tiempo transcurre de arriba abajo Cuando existe demora entre el envo y la atencin se puede indicar usando una lnea oblcua
115
Un ejemplo:
A B C
m1
m2 m3
m4 m5
116
58
Utilidad del Diagrama de Secuencia:
Para la documentacin de un Caso de Uso: en trminos prximos al usuario y sin detallar la sincronizacin existente Para la representacin precisa de las interacciones entre objetos
117
Ejemplo
Quien llama Lnea telefnica Llamado descuelga
tono
marcar
Las bandas rectangulares representan los periodos de actividad de los objetos
indicacin de llamada
timbre
descuelga
diga?
118
59
Un objeto puede enviarse a s mismo un mensaje:
a
Puede representar tambin la entrada por parte del objeto en cierta actividad de ms bajo nivel
mensaje reflexivo
119
p
Grficamente tambin se puede indicar cundo el mensaje es para crear el objeto (va dirigido al rectngulo del objeto o etiquetado con new) o para destruirlo (va dirigido a la lnea del objeto pero el final de la flecha es una cruz)
120
60
Normalmente no es necesario indicar el retorno del control:
a b
El retorno se considera implcito cuando el envo es sncrono
121
Diagrama de Secuencia
En el caso asncrono el retorno, si existe, se debe representar:
a : aa b : aa
122
61
Tipos de Control
El Diagrama de Secuencia refleja de manera indirecta las opciones de control Un control centralizado tiene una forma como esta:
123
Tipos de control
Un control descentralizado tiene una forma como esta:
124
62
Estructuras de control
Podemos representar iteraciones en el envo de mensajes mientras, p.e., se cumpla una condicin:
While X Loop end Loop
125
La iteracin puede expresarse tambin como parte del mensaje:
*[condicin] Mensaje
126
63
Las bifurcaciones condicionales pueden representarse de esta forma:
If condicin else end if
127
Son tiles en la fase exploratoria para identificar objetos La distribucin de los objetos en el diagrama permite representar una disposicin espacial La estructura esttica viene dada por los enlaces; la dinmica por el envo de mensajes por los enlaces
128
64
El contexto de una interaccin comprende los argumentos, las variables locales creadas en ejecucin y los enlaces entre los objetos que participan en la interaccin La colaboracin es mediante el intercambio de mensajes
129
Mensajes
Un mensaje desencadena una accin en el objeto destinatario. Un mensaje se enva si han sido enviados los mensajes de una lista (sincronizacin):
1: A.1, B.3 / Mensaje
130
65
Mensajes
Un mensaje se enva iterada y secuencialente a un conjunto de instancias:
1: *[i:=1..n] : Mensaje B A
131
Mensajes
Un mensaje se enva iterada y concurrentemente a un conjunto de instancias:
1: *| | [i:=1..n] : Mensaje B A
132
66
Mensajes
Un mensaje se enva de manera condicionada:
1: [x>y]: Mensaje B A
133
Mensajes
Un mensaje que devuelve un resultado:
1: p:= cuestin B A
134
67
Prctica 12
Mensajes
Los argumentos de un mensaje pueden ser valores obtenidos como consecuencia de las llamadas anteriores Los argumentos pueden ser tambin expresiones de navegacin construidas a partir del objeto cliente Los argumentos pueden omitirse en el diagrama
135
Modelado de la Estructura del Sistema
136
68
Clases
Modelado Conceptual:
Organizacin del conocimiento del dominio del problema en un conjunto de abstracciones ordenadas de forma que se obtiene un conocimiento ms en profundidad del problema
137
Clases
El mundo real puede ser visto desde abstracciones diferentes (subjetividad) Mecanismos de abstraccin:
Clasificacin / Instanciacin Composicin / Descomposicin Agrupacin / Individualizacin Especializacin / Generalizacin
La clasificacin es uno de los mecanismos de abstraccin ms utilizados

138
69
Clases
La clase define el mbito de definicin de un conjunto de objetos Cada objeto pertenece a una clase Los objetos se crean por instanciacin de las clases
139
Clases: Definicin
Un lenguajes OO permite describir y manipular las clases y sus instancias Un lenguaje OO reduce la distancia entre nuestra forma de entender un dominio (abstracciones) y el sistema de informacin asociado
140
70
Clases: Notacin Grfica

Cada clase se representa en un rectngulo con tres partes:
nombre de la clase atributos de la clase operaciones de la clase
motocicleta color cilindrada velocidad maxima arrancar acelerar frenar
141
Clases: Notacin Grfica

Otros ejemplos:
lista pila primero ultimo aadir quitar cardinalidad
apilar desapilar cardinalidad
142
71
Clases: Encapsulacin
La encapsulacin presenta dos ventajas bsicas:
Se protegen los datos de accesos indebidos El acoplamiento entre las clases se disminuye por no saber cmo estn implementadas Favorece la modularidad y el mantenimiento
Tericamente los atributos de una clase no son manipulables directamente por el resto de objetos. El grado de encapsulacin es flexible
143
Los niveles de encapsulacin estn heredados de los niveles de C++:
(-) Privado: es el ms fuerte. Esta parte es totalmente invisible (excepto para los friends en terminologa C++) (#) Los atributos de la parte protegida estn visibles para los friends y para las clases derivadas de la original (+) Los atributos de la parte pblica son visibles a todas las clases (se pierde la encapsulacin)
144
72
Ejemplo:
Reglas de visibilidad + Atributo pblico : int # Atributo protegido : int - Atributo privado : int + "Operacin pblica" # "Operacin protegida" - "Operacin privada"
145
Relaciones entre clases

Los enlaces a nivel de objetos pueden verse en el mundo de las clases Distinguimos entre:
Asociacin Agregacin (caso particular de asociacin)
Las jerarquas de herencia son tambin un modo particular de relaciones entre clases
146
73
Asociacin
La asociacin expresa una conexin semntica bidireccional entre clases Una asociacin es una abstraccin de la relacin existente en los enlaces entre los objetos
Univ. de Murcia:Universidad Un enlace Antonio:Estudiante
Universidad Una asociacin
Estudiante
147
Asociacin
Ejemplo:
Universidad
+Patron 0..1
+Docente *
Persona
148
74
Asociacin
Especificacin de multiplicidad
1 0..1 M..N * 0..* 1..* Uno y slo uno Cero o uno De M a N (enteros naturales) De cero a varios De cero a varios De uno a varios
La multiplicidad puede establecer restricciones de existencia para los objetos de las clases asociadas
149
Asociacin Cualificada
Aerolnea nro_viajero *
0..1
Viajero
Tablero Ajedrez
fila columna
Cuadro
Un objeto y un cualificador identifican a un nico objeto en la asociacin (forma una clave compuesta) Reduce la multiplicidad del rol opuesto. La nueva multiplicidad es 0 1 (si hay mapeo para todos los valores del dominio del cualificador)
150
75
Agregacin
Histricamente, la agregacin representa un objeto compuesto por otros objetos Conocida tambin como relacin parte_de Puede ser caracterizada con precisin determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes
151
Agregacin: Caracterizacin
1. Puede el objeto componente ser compartido por ms de un objeto agregado?
No => componente disjunto (m. inclusin fuerte) Si => componente no disjunto (m. inclusin dbil)
2. La composicin de un objeto agregado vara por la ocurrencia de acciones?

Si => componente dinmico No => componente esttico
3. Puede un objeto de la clase componente existir sin ser componente de un objeto agregado?
Si => componente flexible No => componente estricto
152
76
4. Cuntos objetos de una clase componente puede tener asociados un objeto agregado?
Ms de uno => componente multivaluado Mximo uno => componente univaluado
5. Puede el objeto agregado no tener objetos de una clase componente en algn instante?
Si => componente con nulos permitidos No => componente con nulos no permitidos
153
Las caracterizaciones 1, 3, 4 y 5 estn incluidas en el concepto ms amplio de multiplicidad Objeto Agregado
Multiplicidad Mnima 0 nulos permitidos > 0 nulos no permitidos Multiplicidad Mxima 1 univaluado > 1 multivaluado Multiplicidad Mnima 0 flexible > 0 estricta Multiplicidad Mxima 1 disjunto > 1 no disjunto
Objeto Componente
154
77
Ejemplos
coche 1 0..2 +Padre 1 motor +Hijos *
Persona
155
Ejemplos
marido casado-con 0.. 1 0.. 1 mujer Persona jefe nombre 0.. 1 s. s. Administra trabaja-para emplea-a
* Compaa
nombre direccin
empleado
Agregacin
Polgono
1 contiene
3.. *
{ordenado}
Punto
156
78
Ejemplos
* *
Persona Empresa
Cuenta
*
or
1
Asociacin excluyente
Usuario
est-autorizado-en
Estacin
Clase de asociacin
Autorizacin prioridad privilegios camb_privil

157
Clases vs. Objetos

Los Diagramas de Clases y los Diagramas de Objetos pertenecen a dos vistas complementarias del modelo Un Diagrama de Clases muestra la abstraccin de una parte del dominio Un Diagrama de Objetos representa una situacin concreta del dominio Cada objeto es instancia de una clase. Ciertas clases (clases abstractas o diferidas) no pueden ser instanciadas
158
79
Clases Diferidas
Baricentro* Extensin* *
Figura
* rotar* visualizar*
Fig. Abierta Polilnea Polgono
Fig. Cerrada
permetro+
permetro* permetro+
Segmento
Elipse
permetro++
Tringulo
diagonal
Cuadriltero
Crculo
permetro++ lado2 lado1 permetro++
159
Rectngulo
Cuadrado
Clases vs. Objetos

Cada enlace es instancia de una relacin Los enlaces vinculan objetos, las asociaciones vinculan clases Los Diagramas de objetos que contienen objetos y enlaces son instancias de los Diagramas de Clases que contienen clases y asociaciones Debe existir coherencia entre ambos
160
80
Jerarquas de Clases
Las jerarquas de clases permiten gestionar la complejidad mediante un ordenamiento taxonmico Una jerarqua se obtiene usando los mecanismos de abstraccin de Generalizacin o Especializacin La Generalizacin consiste en factorizar los elementos comunes de un conjunto de clases en una clase ms general
161
Jerarquas de Clases
Nombres usados: clase padre - clase hija, superclase - subclase, clase base - clase derivada Una superclase es una abstraccin de sus subclases Las subclases heredan caractersticas de sus superclases, es decir, atributos y operaciones de la superclase estn disponibles en sus subclases
162
81
Jerarquas de Clases
La Generalizacin y Especializacin son equivalentes en cuanto al resultado: la jerarqua y herencia establecidas Generalizacin y Especializacin no son operaciones reflexivas ni simtricas pero s transitivas Dos formas de Generalizar segn Meyer:
Abstraccin: Se reconoce de manera tarda un nivel superior. Factorizacin: Se detecta que dos clases son variaciones de un concepto general.
163
Jerarquas de Clases
Abstracciones ms generales. vehiculo
vehiculo terrestre
vehiculo areo
camion
coche
avion
helicoptero
164
82
Jerarquas de Clases
La especializacin es una tcnica muy eficaz para la extensin y reutilizacin
coche
funcionando
estropeado
Tipos de especializacin:
disjunta - no disjunta total (completa) - parcial (incompleta)
165
Jerarquas de Clases
La nocin de clase est prxima a la de conjunto Dada una clase, podemos ver el conjunto relativo a las instancias que posee o bien relativo a las propiedades de la clase Generalizacin y especializacin expresan relaciones de inclusin entre conjuntos
166
83
Jerarquas de Clases
Particionamiento del espacio de objetos Especializacin Esttica Particionamiento del espacio de estados de los objetos Especializacin Dinmica
167
Jerarquas de Clases
Un ejemplo de Especializacin Esttica:
vehiculo areo
avion
helicoptero
168
84
Jerarquas de Clases
Un ejemplo de Especializacin Dinmica:
coche
funcionando
estropeado
169
Jerarquas de Clases
Extensin: Posibles instancias de una clase Intensin: Propiedades definidas en una clase
A int(A) int(B) ext(B) ext(A) B
170
85
Jerarquas de Clases
Estticas:
C0
ext(C 0) = ext(C i) ext(C i) ext(C j) = extt(C 0) = extt(Ci)
C1
Cn
extt(C i) extt(C j) =
171
Jerarquas de Clases
Dinmicas:
C0
extt(C 0) = extt(C i) extt(C i) extt(C j) =
C1
Cn
extt1(C i) extt2(C j) ext(C i) = ext(C j)

i,j=0,...,n
172
86
Jerarquas de Clases
En la Especializacin Esttica, el objeto es instancia desde su creacin de la subclase y la superclase en las que fue creado. Esta pertenencia es inmutable Un objeto slo puede ser instancia de una subclase en una Especializacin Esttica Puede haber ms de una especializacin esttica o dinmica a partir de la misma superclase
173
Jerarquas de Clases
Ejemplo: especializaciones a partir de la misma superclase:
comercial vehiculo areo
militar avion helicoptero

174
87
Jerarquas de Clases
En la Especializacin Dinmica un objeto puede migrar durante su vida entre las distintas subclases de la especializacin La migracin puede definirse en funcin de su estado o de los eventos que le acontezcan
175
Jerarquas de Clases
Ejemplo: especializaciones dinmicas de la misma superclase:
de menos de 1000kms coche
de ms de 1000 kms funcionando estropeado
176
88
Jerarquas de Clases
Un ejemplo combinado:
vehiculo
comercial vehiculo terrestre vehiculo areo esttica
esttica
esttica avion helicoptero
militar
camion
de menos de 1000kms dinmica de ms de 1000 kms
coche
dinmica
funcionando
estropeado
177
Jerarquas de Clases
El siguiente es un ejemplo de clasificacin no equilibrada:
vehiculo terrestre
camion
coche
Harley Davidson
178
89
Jerarquas de Clases
Por regla general, es mejor limitar el nmero de subclases a cada nivel a costa de aumentar el nmero de objetos por clase y reservar los atributos para cualificar afinadamente los objetos A veces, una especializacin dinmica tiene un equivalente a travs de una especializacin esttica y una asociacin ...
179
Jerarquas de Clases
Ejemplo:
mariposa
oruga
crislida
Lepidptero
Aspecto mariposa 1 estadio
oruga
crislida
Lepidptero
180
90
Herencia Mltiple
Se presenta cuando una subclase tiene ms de una superclase La herencia mltiple debe manejarse con precaucin. Algunos problemas son el conflicto de nombre y el conflicto de precedencia Se recomienda un uso restringido y disciplinado de la herencia. Java y Ada 95 simplemente no ofrecen herencia mltiple
181
Herencia Mltiple
La multiplicidad de la clasificacin mltiple se puede representar tambin mediante asociaciones:
Realiza > Clase * Tipo
Tipo A
Tipo B
Tipo C
182
91
Herencia Mltiple
Uso disciplinado de la herencia mltiple
conejo
con pelo Herbvoro con plumas omnvoro Animal con escamas carnvoro
Bipedo
Cuadrpedo
183
Delegacin
La herencia no es una necesidad absoluta y siempre puede sustituirse por delegacin Disminuye el acoplamiento: el cliente no conoce directamente al proveedor y el proveedor puede ser modificado sobre la marcha Permite implementar herencia mltiple en lenguajes con herencia simple
184
92
...Delegacin
Herencia con vistas (Meyer)
* Empleado
Fijo
Temporal
Supervisor
Ingeniero
Administr.
185
...Delegacin
Alternativa con vistas:
Empleado * contrato Contrato * contratar * despedir *
Supervisor
Ingeniero
Administr.
Fijo
Temporal
186
93
...Delegacin
Otras soluciones son ms oscuras:
Vista de empleado desde la perspectiva especialidad
Empleado *
Especialista
Contrato
Supervisor
Ingeniero
Administr.
Fijo
Temporal
187
Delegacin
Ejemplo de delegacin:
Delegado 1 Cliente 1: Cuestin 2: Propagacin
Interfaz
3: Propagacin
Delegado 2
188
94
Delegacin
Ejemplo de delegacin que evita la herencia mltiple: Animal
x Locomocin
x Alimento
Bpedo
Cuadrpedo
Herbvoro
Carnvoro
189
Principio de Sustitucin
El Principio de Sustitucin de Liskow (1987) afirma que: debe ser posible sustituir cualquier objeto instancia de una subclase por cualquier objeto instancia de una superclase sin que la semntica del programa escrito en los trminos de la superclase se vea afectado.
190
95
La herencia es respecto del estado, el comportamiento y las restricciones Todas las propiedades son vlidas en las clases hijas La necesidad de heredar parcialmente es sntoma de no existir realmente una relacin de clasificacin entre las clases
191
Dado que los programadores pueden introducir cdigo en las subclases redefiniendo las operaciones, es posible introducir involuntariamente incoherencias que violen el principio de sustitucin El polimorfismo que veremos a continuacin no puede implementarse sin este principio
192
96
Polimorfismo
El trmino polimorfismo se refiere a que una caracterstica de una clase puede tomar varias formas El polimorfismo representa en nuestro caso la posibilidad de desencadenar operaciones distintas en respuesta a un mismo mensaje Cada subclase hereda las operaciones pero tiene la posibilidad de modificar localmente el comportamiento de estas operaciones
193
Polimorfismo
Los beneficios del polimorfismo se recogen principalmente durante el mantenimiento No debemos pensar el anlisis en trminos del polimorfismo sino en trminos de abstraccin y como efecto secundario beneficioso aprovechar el polimorfismo
194
97
Polimorfismo
Ejemplo: todo animal duerme, pero cada clase lo hace de forma distinta
Zoo 1 * Animal
?
dormir
?
Len Oso Tigre
195
Polimorfismo
Zoo 1 * Animal Dormir() { }
Len
Oso
Tigre
Dormir() { sobre el vientre }

Dormir() { sobrela espalda }
Dormir() { en un rbol }
196
98
Polimorfismo
Los mecanismos generales escritos segn la especificacin del zoo no necesitan conocer los gustos particulares de cada especie para invocar la operacin dormir(). As al caer la noche el guarda se pasea e informa a cada animal de que debe dormir:
El guarda:Guardas : dormir Zoo Madrid
197
Polimorfismo
La bsqueda automtica del cdigo que en cada momento se va a ejecutar es fruto del enlace dinmico El cumplimiento del Principio de Sustitucin permite obtener un comportamiento y diseo coherente
198
99
...Polimorfismo
El siguiente es un ejemplo de violacin del principio de sustitucin:
Pjaro
Paloma
Gorrin
Avestruz
Volar() { Esconder la cabeza bajo tierra }

199
200
100
Los Diagramas de Estados representan autmatas de estados finitos, desde el p.d.v. de los estados y las transiciones Esta descripcin es til slo para los objetos con un comportamiento significativo El resto de objetos se puede considerar tienen un nico estado El formalismo es el de los Statecharts (Harel)
201
Los Statecharts son autmatas jerrquicos que permiten expresar concurrencia, sincronizacin y jerarquas de objetos Los Diagramas de Estados son grafos cclicos dirigidos Cada objeto sigue el comportamiento descrito en el Statechart asociado a su clase El estado en el que se encuentra caracteriza sus condiciones dinmicas Statecharts y escenarios son complementarios
202
101
Cada objeto est en un estado en cierto instante El estado est caracterizado parcialmente por los valores de los atributos del objeto Los Statecharts de UML son deterministas Los estados inicial y final estn diferenciados del resto La transicin entre estados es instantnea y se debe a la ocurrencia de eventos
203
Ejemplo de un Diagrama de Estados para la clase persona:
contratar en el paro perder empleo jubilarse jubilarse en activo
jubilado
204
102
La comunicacin bidireccional puede representarse mediante comunicacin asncrona. Por ejemplo en un Diagrama de Colaboracin:
1: una pregunta un objeto 2: la respuesta otro objeto
205
En este caso, el cliente debe esperar la respuesta. Con lo cual en tendramos:
a
plantear pregunta
espera respuesta
recibir respuesta
206
103
Las guardas permiten condicionar la transicin:
a Evento[ condicin ] b
207
Acciones
Podemos especificar la ejecucin de una accin como consecuencia de la transicin:
Evento[ condicin ] / accin
Dicha accin tambin se considera instantnea

208
104
Acciones
Podemos especificar el envo de un evento a otro objeto como consecuencia de la transicin:
a
Evento( arg1, arg2 )[ condicin ] / ^otro_objeto.evento(arg2)
b
209
Acciones
Se puede especificar el hacer una accin como consecuencia de entrar, salir o estar en un estado:
estado A entry: accin por entrar exit: accin por salir do: accin mientras en estado
210
105
.. Acciones
Se puede especificar el hacer una accin cuando ocurre en dicho estado un evento que no conlleva salir del estado:
estado A on evento_activador( arg1 )[ condicin ]: accin por evento
211
Actividades
Las actividades son similares a las acciones pero tienen duracin y se ejecutan dentro de un estado del objeto Las actividades pueden interrumpirse en todo momento, cuando se desencadena la operacin de salida del estado
212
106
Actividades
Cuando una actividad finaliza se puede produce una transicin automtica de salida del estado
a do: actividad [ condicin ] [ not condicin ] b
b
213
Generalizacin de Estados
Podemos reducir la complejidad de estos diagramas usando la generalizacin de estados Distinguimos as entre superestado y subestados Un estado puede contener varios subestados disjuntos Los subestados heredan las variables de estado y las transiciones externas
214
107
Ejemplo:
a e1 b
e2 e2 c
215
Quedara como:
e1
e2
216
108
Las transiciones de entrada deben ir hacia subestados especficos:
e1 a e2 e0 b
217
Es preferible tener estados iniciales de entrada a un nivel de manera que desde los niveles superiores no se sepa a qu subestado se entra:
e1 a b c e2 e0
218
109
Es posible ocultar los detalles de los subestados:
c e0
219
La agregacin de estados es la composicin de un estado a partir de varios estados independientes La composicin es concurrente por lo que el objeto estar en alguno de los estados de cada uno de los subestados concurrentes
220
110
Ejemplo:
e1 e1
221
Historial
Por defecto, los autmatas no tienen memoria Es posible memorizar el ltimo subestado visitado para recuperarlo en una transicin entrante en el superestado que lo engloba
222
111
Historial
Ejemplo:
a
d2 in h out d1 x y
223
Historial
Tambin es posible la memorizacin para cualquiera de los subestados anidados (aparece un * junto a la H)
a d2
in h x out d1 y
H*
224
112
Historial
Ejemplo:
Enjuague Lavado Secado
Cerrar Abrir Puerta
CAbrir errar Puerta
Espera
225
Destruccin del Objeto

La destruccin de un objeto es efectiva cuando el flujo de control del autmata alcanza un estado final no anidado La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto
226
113
Destruccin de Objeto
Ejemplo:
En vuelo crash
despegar Crear(matricula)
aterrizar
En tierra
227
Transiciones temporizadas
Las esperas son actividades que tienen asociada cierta duracin La actividad de espera se interrumpe cuando el evento esperado tiene lugar Este evento desencadena una transicin que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estado
228
114
Ejemplo:
Si en 30 segundos no se introduce el dinero se termina la actividad pasando a anular la transaccin. En cualquier caso se cierra la ranura.
/ Abrir ranura esperar dinero entry: Mostrar mensaje do: Esperar 30 segundos exit: cerrar ranura anular transaccin a
Depsito efectuado
b
229
Ejemplo v.2:
a
/ Abrir ranura esperar dinero entry: Mostrar mensaje exit: cerrar ranura Temporizador (30 segundos) anular transaccin
Depsito efectuado
b
230
115
Diagrama de Actividades
El Diagrama de Actividades es una variante de los Diagramas de Estados, organizado respecto de las acciones y principalmente destinado a representar el comportamiento interno de un mtodo (la realizacin de una operacin) o de un caso de uso Una actividad es un estereotipo de estado
231
...Diagrama de Actividades
Las actividades se enlazan por transiciones automticas Cuando una actividad termina se desencadena el paso a la siguiente actividad Las actividades no poseen transiciones internas ni transiciones desencadenadas por eventos
232
116
Ejemplos
Buscar Bebida [no hay caf] [no zumo] [hay zumo] [hay caf Poner caf en filtro Aadir agua al depsito Coger taza Coger zumo
Poner filtro en mquina
Encender mquina ^cafetera.On Caf en preparacin indicador de fin Servir caf Beber
233
...Ejemplos (bandas)
Pasajero Vendedor Airline
Solicitar pasaje Verificar existencia vuelo Dar detalles vuelo Informar alternativas y precios Seleccionar vuelo
Solicitar pago
Reservar plazas Confirmar plaza reservada
Pagar pasaje Emitir billete
234
117
Modelado de Componentes
235
Diagrama de Componentes
Los diagramas de componentes describen los elementos fsicos y sus realizaciones en el entorno de realizacin Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutable
236
118
...Diagramas de Componentes
Los componentes representan todos los tipos de elementos software que entran en la fabricacin de aplicaciones informticas Pueden ser simples archivos, paquetes de Ada, bibliotecas cargadas dinmicamente, etc. Cada clase del modelo lgico se realiza en dos componentes: la especificacin y el cuerpo
237
Diagramas de Componentes
La especificacin contiene el interfaz de la clase mientras que el cuerpo contiene la realizacin de la clase La especificacin puede ser genrica en el caso de las clases parametrizables
238
119
La representacin grfica es la siguiente:
Especificacin Cuerpo Genrico
Package specification
Package body
Generic package
239
En C++ una especificacin corresponde a un archivo con un sufijo .h y un cuerpo a un archivo con un sufijo .cpp En Ada la nocin de mdulo existe directamente en el lenguaje con el nombre del paquete
240
120
Dependencias entre Componentes

Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios ofrecidos por otro componente
NewPackageSpec NewPackageSpec2
Dependencia entre dos componentes

241
Subsistemas
Los distintos componentes pueden agruparse en paquetes segn un criterio lgico y con vistas a simplificar la implementacin Son paquetes estereotipados en <<subsistemas>> para incorporar la nocin de biblioteca de compilacin y de gestin de configuracin
<<subsistema>> NewPackage4
242
121
Subsistemas
Los subsistemas organizan la vista de realizacin de un sistema Cada subsistema puede contener componentes y otros subsistemas La descomposicin en subsistemas no es una descomposicin funcional La relacin entre paquetes y clases en el nivel lgico es el que existe entre subsistemas y componentes en el nivel fsico
243
Modelado de Distribucin
244
122
Los Diagramas de Distribucin muestran la disposicin fsica de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos
Nodo
245
Los estereotipos permiten precisar la naturaleza del equipo:
Dispositivos Procesadores Memoria
Los nodos se interconectan mediante soportes bidireccionales (en principio) que pueden a su vez estereotiparse
246
123
Ejemplo de conexin entre nodos:
<<Procesador> Nodo <<<<TCP/IP>>>> conexin1 <<dispositivo>> nodo2
conexin7 <<RDSI>>
En Rational Rose podemos distinguir entre el dispositivo por estereotipado y el dispositivo con su propio smbolo
dispositiv o
247
Hacia un Mtodo OO
248
124
Hacia un Mtodo OO
Un proceso de desarrrollo de programas tiene como objetivo la formalizacin de las actividades relacionadas con la elaboracin de sistemas informticos Debe ser:
Reproducible Definido Medible en cuanto a rendimiento Optimizable ...
249
Hacia un Mtodo OO
UML no incorpora por s misma el modelo de proceso Los autores destacan las siguientes caractersticas de UML como esenciales para determinar el proceso de desarrollo:
Est controlado por los casos de uso: desde la especificacin hasta el mantenimiento Se centra en la arquitectura: reutilizable y como gua hasta la solucin Iterativo e incremental: el trabajo se divide en iteraciones pequeas en funcin de la importancia de los casos de uso y el estudio de riesgos
250
125
Hacia un Mtodo OO
Requisitos Anlisis Diseo Implement. Prueba
Los Casos de Uso forman la unin
Capturar, clarificar y validar los casos de uso

Realizar los casos de uso
Verificar se satisfacen los casos de uso

251
Hacia un Mtodo OO
En anlisis las necesidades se segmentan respecto de los distintos actores. Sevicios del sistema de la forma interaccin actor -sistema En anlisis tambin se distinguen objetos y clases. Cada caso de uso se realiza por la colaboracin entre objetos La descomposicin no es estrictamente funcional: la colaboracin de un caso de uso es una situacin particular de clases potenciales
252
126
Hacia un Mtodo OO
Las 4+1 vistas de Kruchten (1995):
Vista Lgica Vista de los Casos de Uso Vista de Procesos
Vista de Realizacin
Vista de Distribucin
253
Vista Lgica
La vista lgica describe los aspectos estticos y dinmicos de un sistema en trminos de clases y objetos Se usan:
Objetos Clases Colaboraciones Interacciones Categoras (paquetes estereotipados)
254
127
Vista de Realizacin
Se preocupa de la organizacin de los componentes en el entorno de desarrollo Muestra el reparto de clases en componentes y estos en subsistemas Se usan:
Mdulos Subprogramas Tareas Subsistemas (paquetes estereotipados)
255
Vista de Procesos
Representa la descomposicin en flujos de ejecucin (threads), la sincronizacin entre flujos y la asignacin de objetos y clases en dichos flujos. Fiabilidad, rendimiento, etc. Importante en entornos multitarea. Se usan:
Tareas, threads, procesos. Interacciones.
256
128
Vista de Distribucin
Describe los diferentes recursos de hardware y la implementacin del programa en dichos recursos Se consideran:
Tiempos de respuesta y rendimiento restricciones geogrficas potencia de clculo distribuido sobrecargas tolerancia a fallos y a averas nodos, mdulos y programas principales
257
Se usan:
Vista de los Casos de Uso

Los casos de uso unifican las cuatro vistas precedentes Se usan:
Actores, Casos de suo Clases Colaboraciones
258
129
Realizacin
El cdigo que realiza las clases, los objetos y las interacciones entre los objetos se almacena en componentes que constituyen los mdulos de la estructura fsica de los sistemas Un programa principal es una especie de componente con cdigo ejecutable correspondiente a una o varias interacciones Un programa principal se distribuye sobre nodos en procesos que lo ejecutan
259
Organizacin de los modelos y las vistas

En la Vista Lgica los paquetes contienen objetos, clases, a otros paquetes y los diagramas contenidos (los paquetes se especializan en categoras) En la Vista de Realizacin los paquetes contienen componentes y los diagramas correspondientes (los paquetes se especializan en subsistemas)
260
130
...Organizacin de los modelos y las vistas

Hay relacin directa entre una categora y un subsistema. Puede haber diferencias para:
Agrupar objetos con fuerte interaccin. Realizar funcionalidades de bajo nivel no presentes en anlisis Repartir el trabajo del equipo de desarrollo
261
Ciclo de Vida Iterativo e Incremental

El ciclo de vida iterativo se basa en la evolucin de prototipos ejecutables que se muestran a los usuarios y clientes En el ciclo de vida iterativo a cada iteracin se reproduce el ciclo de vida en cascada a menor escala Los objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes
262
131
...Ciclo de Vida Iterativo e Incremental

Las actividades se encadenan en una minicascada con un alcance limitado por los objetivos de la iteracin
Anlisis Diseo Codific. n veces Pruebas e Integracin
263
...Ciclo de Vida Iterativo e Incremental

Cada iteracin comprende:
Planificar la iteracin (estudio de riesgos) Anlisis de los Casos de Uso y escenarios Diseo de opciones arquitectnicas Codificacin y pruebas. La integracin del nuevo cdigo con el existente de iteraciones anteriores se hace gradualmente durante la construccin Evaluacin de la entrega ejecutable (evaluacin del prototipo en funcin de las pruebas y de los criterios definidos) Preparacin de la entrega (documentacin e instalacin del prototipo)
264
132
Gestin del Riesgo

El anlisis de riegos consiste en evaluar el proyecto, la tecnologa y los recursos con el fin determinar y comprender la naturaleza y el origen de los riesgos Riesgos:
Comerciales (competencia, etc.) Financieros (econmicos, etc.) Tcnicos (base tecnolgica slida y probada?) De desarrollo (equipo experimentado?)
El mayor riesgo consiste en no saber dnde estn los riesgos

265
...Gestin del Riesgo

Cada iteracin se basa en la construccin de un nmero reducido de escenarios que se centran primero en los riesgos ms importantes y determinan las clases y las categoras a construir en la iteracin Se distinguen prototipos orientados a la interfaz del usuario, a cuestiones Hw, de reuso de programas o a la validacin funcional Cada prototipo corresponde a 1 ms casos de uso
266
133
Reparto de Actividades
Actividades
Inception E la bora tion
Fases
Construction Transition
Requisitos Una iteracin en la fase de elaboracin Anlisis
Diseo
Implementacin
Prueba
P re lim ina ry Iter atio n (s)
iter. #1
iter. #2
iter. #n
iter. # n +1
ite r. # n +2
iter. #m
ite r. # m +1
267
Fases del Ciclo de Vida

El ciclo de vida para UML consiste en una serie de ciclos cada uno de los cuales produce una nueva versin del producto Cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de iteraciones Las fases son:
Estudio de oportunidad Elaboracin Construccin Transicin
268
134
...Fases del Ciclo de Vida

Estudio de oportunidad (inception)
Define el mbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura bsica Se planifica el proyecto considerando recursos disponibles
Elaboracin

269

Construccin
El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de anlisis, diseo e implementacin Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu refinada de manera incremental conforme se construye (se permiten cambios en la estructura) Gran parte del trabajo es programacin y pruebas Se documenta tanto el sistema construido como el manejo del mismo Esta fase proporciona un producto construido junto con
la documentacin
270
135

Transicin
Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracn, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la informacin anterior Estas tareas se realizan tambin en iteraciones
271
Esfuerzo Respecto de las Actividades

Inception E la bora tion C onstruction Transition
15%
Requisitos Una iteracin en la fase de elaboracin Anlisis
10% 15% 30% 15%
Diseo
Implementacin
Prueba
P re lim in ar y Iter atio n (s) ite r. #1 iter. #2 iter. #n iter. #n + 1 ite r. # n +2 iter. #m ite r. #m +1
5% mantenimiento 10% gestin cambios

272
136
...Esfuerzo Respecto de las Fases

Inception E la bora tion C onstruction Transition Requisitos Una iteracin en la fase de elaboracin Anlisis
Diseo
Implementacin
Prueba
P re lim in ar y Iter atio n (s) ite r. #1 iter. #2 iter. #n iter. #n + 1 ite r. # n +2 iter. #m ite r. #m +1
Esfuerzo: Duracin:
5% 10%
20% 30%
65% 50%
10% 10%
273
Conclusiones
Apostar por enfoque Orientado a Objetos usando notacin UML Problemas actuales en implementacin, al usar programacin visual y/o bases de datos relacionales Posibles mejoras a medio plazo
Evolucin: Uso de BDOO y/o mejoras en los LPOO Revolucin: Generacin Automtica de Cdigo a partir de Modelos OO
274
137
Bibliografa Recomendada
UML
www.rational.com Martin Fowler, UML Destilled (UML Gota a Gota) Terry Quatrani, Visual Modeling ..., un ejemplo completo International Council in SE (INCOSE) Tools Database Working Group. www.incose.org/tools/ Desmond DSouza, componentes www.enteract.com/ bradapp/docs/patterns-intro.html, patrones Revista IEEE Software, Conferencias: OOPSLA, ECOOP
Herramientas CASE
Otras

275
138

Curso OOcon UML

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Curso OOcon UML

Hochgeladen von

Copyright:

Verfügbare Formate

Formacin de Postgrado, Departamento de Sistemas Informticos y Computacin Universidad Politcnica de Valencia Junio 2000

Anlisis y Diseo Orientado a Objetos usando la notacin UML

Departamento Sistemas Informticos y Computacin Universidad Politcnica de Valencia (Espaa)

Abstraccin - Modelado Visual

Proceso de Negocios Sistema Computacional

MV para manejar la complejidad

MV para definir la Arquitectura del Software

Servidor de BDs (C++ & SQL, ..)

Modelar el sistema independientemente del lenguaje de implementacin

Un Breve Tour por UML

=> Necesidad de una notacin estndar

UML 2.0 UML 1.4 UML 1.3 UML 1.2

Participantes en UML 1.0

Digital Equipment Hewlett-Packard i-Logix (David Harel) IBM ICON Computing

Intellicorp and James Martin & co. (James Odell)

UML aglutina enfoques OO

Gamma et. al.

Mtodos Formales en Modelado

Mtodos Formales en Modelado

Modelado con UML

Un modelo es una descripcin completa de un sistema desde una perspectiva concreta

Tipos de Diagramas UML

Diagramas de Casos de Uso

Diagramas de Casos de Uso

Supervisor Establecer Crdito

Venta en Rebajas Cliente Vendedor

Realizar prstamo Socio Encargado

tarjeta caducada <<extends>>

Solicitar nueva tarjeta

Reintegro cuenta corriente

Validar operacin <<uses>>

Reintegro cuenta crdito

2: Solicitar prstamo 3: Verificar situacin socio

8: Autorizar prstamo 4: Situacin socio ok

5: Verificar situacin libro : Ficha li bro

Diagramas de Clases (y objetos)

Ejemplos (Clase y Visibilidad)

depto profesor 1..* Profesor

Nro. despacho 0..1 dirige director 1

Ejemplos (Clase Asociacin)

Cargo nombre sueldo +superior 0..1

1 Avin militar Avin comercial Lnea area

Prestar Devolver[ Nmero prstamos = 1 ]

Sin prstamos Alta Baja

El Diagrama puede estar asociado a:

Poner filtro en mquina

Ejemplos (Swim lines)

Reservar plazas Confirmar plaza reservada

Pagar pasaje Emitir billete

Gestin de Cuentas Comment

Rutinas de Coneccion Comment

Terminal de Consulta Rutinas de Coneccion

Interfaz de Terminal Comment

Rutinas de Coneccion Comment

Gestin de Cuentas Comment

Interfaz de Terminal Comment

Relacin entre Diagramas

El Paradigma Orientado a Objetos

Por qu la Orientacin a Objetos?

Modelado integrado de propiedades estticas y dinmicas del mbito del problema

Facilita construccin, mantenimiento y reutilizacin

Por qu la Orientacin a Objetos?

Sin embargo, existen problemas ...