Uml

Contenido Anlisis y Diseo Orientado a Objetos usando la notacin UML
Ing. Mario Alberto Prez Universidad Nacional de Colombia

1
Basada en material de la Universidad Politcnica de Valencia
Introduccin: Modelado de SI 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 Proceso de Desarrollo de SW con UML Conclusiones
2
Construccin de una casa para fido
Introduccin: Modelado de SI
Puede hacerlo una sola persona Requiere : Modelado mnimo Proceso simple Herramientas simples
Construccin de una casa
Construccin de un rascacielos
Construida eficientemente y en un tiempo razonable por un equipo Requiere : Modelado Proceso bien definido Herramientas ms sofisticadas
5 6
Claves en Desarrollo de SI
Notacin
Abstraccin - Modelado Visual (MV)

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

7 8
MV para manejar la complejidad
MV para definir la Arquitectura del Software

Interfaz de Usuario (Visual Basic, Java, ..) Lgica del Negocio (C++, Java, ..)
Servidor de BDs (C++ & SQL, ..)
Modelar el sistema independientemente del lenguaje de implementacin
10
MV promueve la reutilizacin
Mltiples Sistemas
Breve Tour por UML
Componentes Reutilizados
11
12
Qu es UML?
UML = Unified Modeling Language Un lenguaje de propsito general para el modelado orientado a objetos Documento OMG Unified Modeling Language Specification UML combina notaciones provenientes desde:
Modelado Orientado a Objetos Modelado de Datos Modelado de Componentes Modelado de Flujos de Trabajo (Workflows)
13
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 correspondientes gurs)
=> Necesidad de una notacin estndar
14
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
Historia de UML
2001 ? 2000 1999 1998 Nov 97
UML aprobado por el OMG
UML 2.0 UML 1.4 UML 1.3

Revisiones menores
UML 1.2
15
16
Participantes en UML 1.0

Rational Software
(Grady Booch, Jim Rumbaugh y Ivar Jacobson)
UML aglutina enfoques OO

Rumbaugh Booch Odell Shlaer-Mellor
Objectlife cycles
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 Corp. Platinium Technology Sterling Software Taskon Texas Instruments Unisys
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
17
18
Aspectos Novedosos
Definicin semi-formal del Metamodelo de UML Mecanismos de Extensin en UML: Stereotypes Constraints Tagged Values
Mtodos Formales en Modelado

Tipos de enfoques: no-formales, semi-formales y formales 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 para la generacin automtica de prototipos y/o cdigo final
20
Permiten adaptar los elementos de modelado, asignndoles una semntica particular Ver UML V1.3 pgina 2-67
19
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
21
Perspectivas de UML
UML ser el lenguaje de modelado orientado a 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.
22
Evidencias:
Diagramas de UML
Use Case Use Case de Diagrams Diagramas Use Case Diagrams Use Case de Casos de Uso Diagramas Diagrams Diagrams Secuencia Scenario Scenario Diagrams Diagramas Diagrams de Colaboracin Scenario Scenario de Diagramas Diagrams Diagrams Estados State State de Diagrams Diagramas Diagrams Clases State State de Diagrams Diagramas Diagrams Objetos State State Diagrams Diagramas de Diagrams Componentes
Component Component Diagramas Diagrams Diagrams
... Diagramas de 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
23 24
Modelo
Diagramas de Actividad
de Distribucin
Un modelo es una descripcin completa de un sistema desde una perspectiva concreta
Paquetes en UML
Los paquetes ofrecen un mecanismo general para la organizacin de los modelos agrupando elementos de modelado Se representan grficamente como:
Nombre de paquete
Paquetes en UML
Cada paquete corresponde a un subconjunto del modelo y contiene, segn el modelo, clases, objetos, relaciones, componentes y diagramas asociados Un paquete puede contener otros paquetes, sin lmite de anidamiento pero cada elemento pertenece a (est definido en) slo un paquete
25
26
Prctica 1
Paquetes en UML
Una clase de un paquete puede aparecer en otro paquete por la importacin a travs de una relacin de dependencia entre paquetes Todas las clases no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa
Paquetes en UML
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
27
28
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 estrictamente al enfoque orientado a objeto, es una tcnica para captura de requisitos
Ejemplos
Verificar Situacin Vendedor
Cliente Establecer Crdito Supervisor
Preparar Catlogo
Secretaria
Tipos de Venta
29
30
Ejemplos
En el paquete tipos de venta:
Ejemplos
Venta Normal
Realizar prstamo Socio Encargado
tarjeta caducada
<<extend>> <<extends>>
Venta en Rebajas Cliente Vendedor
Solicitar nueva tarjeta
Venta en Oferta
31
32
Prctica 2
Ejemplos
Diagramas de Secuencia
: Socio : Encargado Coger libro : Libro : Ficha socio : Ficha libro : Prstamo
Reintegro cuenta corriente
<<include>> <<uses>>
Solicitar prstamo Verificar situacin socio Situacin socio ok
Cliente
Validar operacin
Verificar situacin libro
<<uses>> <<include>>
Autorizar prstamo
Situacin libro ok Introducir prstamo
Reintegro cuenta crdito
33
34
Prctica 3
Diagramas de Colaboracin
1: Coger libro : Libro
Diagramas de Clases (y objetos)

El Diagrama de Clases es el diagrama principal para el anlisis y diseo
: Ficha s ocio
: Socio
2: Solicitar prstamo 3: Verificar situacin socio
8: Autorizar prstamo 4: Situacin socio ok
6: Situacin libro ok
: Encargado 7: Introducir prstamo : Prsta mo
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 operaciones 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 operaciones
35 36
5: Verificar situacin libro : Ficha li bro
Ejemplos (Clase y Visibilidad)
Ejemplos (Asociacin)
Alumno DNI : char[10] nmero_exp : int nombre : char[50] alta() poner_nota(asignatura : char *, ao : int, nota : float) matricular(cursos : asignatura, ao : int) listar_expediente()
Departamento
dirige 0..1
director 1
Profesor
37
38
Ejemplos (Clase Asociacin)

Empresa empleador * trabajador 1..* Empleado
Ejemplos (Generalizacin)
Empleado
Cargo nombre sueldo 1..* +subordinado
{disjunta, completa}
+superior 0..1
Directivo
Administrativo
Obrero
39
40
Prcticas 4 -8
Ejemplos
Motor 1..4 Piloto 1..2 Vendedor de billetes 1
Diagramas de Estados
alta baja
nmero_prstamos = 0 sin prstamos
1 Avin 1 *
* Vuelo * 1 *
* Reserva
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 ]
{ disjunta, completa }
nmero_prstamos > 0 con prstamos prestar
1 Avin militar Avin comercial Lnea area
{ disjunta, completa }
devolver[ nmero_prstamos > 1 ]
Avin de carga
Avin de pasajeros
41
42
Prctica 9
Diagramas de Actividad
Poner caf en filtro Buscar Bebida [no hay caf] [no zumo] [hay zumo] [hay caf Aadir agua al depsito Coger taza Coger zumo
Otro Ejemplo (con swim lines)

Pasajero Vendedor Airline
Solicitar pasaje Verificar existencia vuelo Dar detalles vuelo
Poner filtro en mquina
Informar alternativas y precios Seleccionar vuelo
Encender mquina ^cafetera.On Caf en preparacin indicador de fin Servir caf Beber
43
Solicitar pago Reservar plazas Pagar pasaje Emitir billete

44
Confirmar plaza reservada
Prctica 10
Diagramas Componentes
Control y Anlisis Interfaz de Terminal Comment Comment
Diagramas de Distribucin
Servidor Central Acceso a BD Comment Control y Anlisis Comment
Rutinas de Coneccion
Gestin de Cuentas Rutinas de Coneccion Comment Comment
Terminal de Consulta
Acceso a BD Comment
Punto de Venta Rutinas de Coneccion Comment Gestin de Cuentas Interfaz de Terminal
Interfaz de Terminal Comment
Rutinas de Coneccion
45
46
Resumen
Captura de Requisitos Anlisis y Diseo
Diagramas de Estados Diagramas de Secuencia Diagramas de Casos de Uso Diagramas de Colaboracin Diagramas de Actividad Diagramas De Clases Diagramas de Componentes Diagramas de Actividad Diagramas de Distribucin
Implementacin
El Paradigma Orientado a Objetos
"You can model 80 percent of most problems by using about 20 percent of the UML."-- Grady Booch
47
48
Por qu la Orientacin a Objetos?

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

Por qu la Orientacin a Objetos?

Conceptos comunes de modelado durante el anlisis, diseo e implementacin

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 la transicin entre distintas fases Favorece el desarrollo iterativo del sistema Disipa la barrera entre el qu y el cmo
Facilita construccin, mantenimiento y reutilizacin
Sin embargo, existen problemas ...
49
50
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
51
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
52
Reflexiones respecto de Situacin Actual de Desarrollo de SI

Anlisis
Enfoque Estructurado
Diseo DEs
Modelo Relacional
Implementacin
Entornos de Programacin Visual
DFDs E-R
Diagramas de Casos de Uso Diagramas de Actividad Diagramas de Secuencia Diagramas de Colaboracin Bosquejos de Interfaces
Fundamentos del Modelado Orientado a Objetos
Modelo Relacional !!
Enfoque OO
Diagrama de Clases Diagrama de Estados Diagramas de Actividad
Bases de Datos (Objeto-) Relacionales
53
54
Objetos
Objeto = unidad atmica que integra estado y comportamiento La encapsulacin en un objeto permite una alta cohesin y un bajo acoplamiento Un objeto puede caracterizar una entidad fsica (coche) o concepto (ecuacin matemtica)
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
Un Objeto Otro Objeto ms Otro Objeto
55 56
Objetos
Ejemplo de varios objetos relacionados:
Dos clientes del banco
Objetos
Cuenta corriente Libreta de ahorro a plazo Libreta de ahorro
Felipe
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 ...
57 58
Juan
Cuenta corriente
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
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)
59 60
10
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
61
Comportamiento
Ejemplo de interaccin:
Otro objeto
Un mensaje Operacion 2
Un objeto
Operacion 1
62
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
Persistencia
La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo Un objeto persistente conserva su estado en un sistema de almacenamiento permanente (usualmente memoria secundaria) Podremos despus reconstruirlo , es decir, cogerlo de memoria secundaria para utilizarlo en la ejecucin (materializacin del objeto) Los lenguajes OO no proponen soporte adecuado para la persistencia, pues sta debera ser transparente, un objeto existe desde su creacin hasta que se destruya
64
63
Comunicacin
Un sistema informtico puede verse como un conjunto de objetos autnomos y concurrentes que trabajan de manera coordinada en la consecucin de un fin especfico El comportamiento global se basa pues en la comunicacin entre los objetos que la componen
Comunicacin
Categoras de objetos:
Activos - Pasivos Cliente Servidores, Agentes
Objeto Activo: posee un hilo de ejecucin (thread) propio y puede iniciar una actividad Objeto Pasivo: no puede iniciar una actividad pero puede enviar estmulos una vez que se le solicita un servicio Cliente es el objeto que solicita un servicio. Servidor es el objeto que provee el servicio solicitado
65 66
11
Comunicacin
Los agentes renen las caractersticas de clientes y servidores Son la base del mecanismo de delegacin Introducen indireccin: un cliente puede comunicarse con un servidor que no conoce directamente
Comunicacin
Ejemplo en el que un agente hace de aislante:
Enrutamiento dinmico
Un agente
Sevidor 1
Servidor 2 Un cliente
Aislante
67 68
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 Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinmico
69
El Concepto de Mensaje
Objeto 1 : Mensaje A Objeto 2
: Mensaje C Objeto 3
: Mensaje E Objeto 4
: Mensaje D
70
Mensaje y Estmulo
Un estmulo causar la invocacin de una operacin, la creacin o destruccin de un objeto o la aparicin de una seal Un mensaje es la especificacin de un estmulo Tipos de flujo de control:
Llamada a procedimiento o flujo de control anidado Flujo de control plano Retorno de una llamada a procedimiento Otras variaciones
Esperado ( balking) Cronometrado ( time-out)
71 72
Captura de Requisitos
12
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 Comparacin con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado
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
73
74
Casos de Uso
Ejemplo:
Sistema
Casos de Uso
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 utilizados Otros sistemas: sistemas con los que el sistema interacta
Caso de uso X
Actor A Actor B
La misma persona fsica puede interpretar varios papeles como actores distintos El nombre del actor describe el papel desempeado
76
Caso de uso Y
75
Casos de Uso
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. El proceso de desarrollo estar dirigido por los casos de uso
Casos de Uso: Relaciones

UML define cuatro tipos de relacin en los Diagramas de Casos de Uso:
Comunicacin:
Actor Caso de Uso
77
78
13

Inclusin : una instancia del Caso de Uso origen incluye tambin el comportamiento descrito por el Caso de Uso destino
<<include> > Caso de uso destino Caso de uso origen

Extensin : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino
<<extend >> Caso de uso destino Caso de uso origen
En UML 1.3 se estereotipa como <<include>> lo que antes llevaba el estereotipo <<uses>>
79
80

Herencia : el Caso de Uso origen hereda la especificacin del Caso de Uso destino y posiblemente la modifica y/o ampla

Ejemplo:
<<extend>> <<extends>>
Cliente <<includes>> <<include>>
Giro por Transferencia porInternet Internet
Transferencia Giro
Caso de uso destino Caso de uso origen

Identificacin
81
82
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?
83
Casos de Uso: Construccin

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? objetivo del caso de uso: qu lleva a cabo o intenta? cronologa y origen de las interacciones repeticiones de comportamiento: qu operaciones son iteradas? situaciones opcionales: qu ejecuciones alternativas se presentan en el caso de uso?
84
14
RF - <id del requisito> Versin Autores Fuentes Objetivos asociados Descripcin
Precondicin Secuencia Normal
Postcondicin Excepciones
Rendimiento
Frecuencia esperada Importancia Urgencia Come n t a r i o s
< nombre del requisito funcional> <numero de versin y fecha> <autor> <fuente de la versin actual> <nombre del objetivo> El sistema deber comportarse tal como se describe en el siguiente caso de uso { concreto cuando <evento de activacin> , abstracto durante la realizacin de los casos de uso <lista de casos de uso>} <precondicin del caso de uso> Paso Accin 1 {El <actor> , El sistema} <accin realizada por el actor o sistema>, se realiza el caso de uso < caso de uso RF -x > 2 Si <condicin>, {el <actor> , el sistema} <accin realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x> 3 4 5 6 n <postcondicin del caso de uso> Paso Accin 1 Si <condicin de excepcin>,{el <actor> , el sistema} }<accin realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF -x>, a continuacin este caso de uso {continu a, aborta} 2 3 Paso Cota de tiempo 1 n segundos 2 n segundos <n de veces> veces / <unidad de tiempo> {sin importancia, importante, vital} {puede esperar, hay presin, inmediatamente} <comentarios adicionales>
Casos de Uso: Pruebas

El modelo de casos de uso permite realizar pruebas orientadas a la verificacin y validacin del sistema Verificar significa confirmar que el sistema se desarrolla correctamente Validar asegura que el sistema bajo desarrollo es el que el usuario realmente quiere
85
86
Modelo de Casos de Uso y Modelo Conceptual
Prctica 11
La especificacin de cada caso de uso y los correspondientes D. de Interaccin establecen el vnculo con el modelo conceptual En mtodos OO que carecen de una tcnica de captura de requisitos se comienza inmediatamente con la construccin del modelo conceptual
Modelado de Interacciones
87
88
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
89
Diagramas de interaccin
Los Diagramas de Secuencia son ms adecuados estn para observar la perspectiva cronolgica de las interacciones Los Diagramas de Colaboracin ofrecen una mejor visin espacial mostrando los enlaces de comunicacin entre objetos Normalmente el D. de Colaboracin se obtiene a partir del correspondiente D. de Secuencia
90
15
Muestra la secuencia 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 oblicua
91
Un ejemplo:
A B C
m1
m2 m3
m4 m5
92
Ejemplo
Quien llama Lnea telefnica Llamado descuelga
Un objeto puede enviarse a s mismo un mensaje:
a
tono
marcar
Las bandas rectangulares representan los periodos de actividad de los objetos
indicacin de llamada
timbre
mensaje reflexivo
descuelga
diga?
93
94
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) Ver UML V1.3 pgina 3-100
Normalmente no es necesario indicar el retorno del control:
a b
El retorno se considera implcito cuando el envo es sncrono
95
96
16
Diagrama de Secuencia
En el caso asncrono el retorno, si existe, se debe representar:
a : aa b : aa
Tipos de Control
El Diagrama de Secuencia refleja de manera indirecta las opciones de control Un control centralizado tiene una forma como esta:
97
98
Tipos de control
Un control descentralizado tiene una forma como esta:
Estructuras de control
Podemos representar iteraciones en el envo de mensajes, p.e., mientras se cumpla una condicin:
While X Loop end Loop
99
100
La iteracin puede expresarse tambin como parte del mensaje:
Las bifurcaciones condicionales pueden representarse de esta forma:
*[condicin] Mensaje
If condicin else end if
101
102
17
Diagramas de Colaboracin
Son tiles en la fase exploratoria para identificar objetos La distribucin de los objetos en el diagrama permite observar adecuadamente la interaccin de un objeto con respecto de los dems La estructura esttica viene dada por los enlaces; la dinmica por el envo de mensajes por los enlaces
Mensajes
Un mensaje desencadena una accin en el objeto destinatario Un mensaje se enva si han sido enviados los mensajes de una lista (sincronizacin):
A.1, B.3 / 1:Mensaje
A
103 104
Mensajes
Un mensaje se enva iterada y secuencialmente a un conjunto de instancias:
Mensajes
Un mensaje se enva iterada y concurrentemente a un conjunto de instancias:
1 *[i:=1..n] : Mensaje B A A
1 *| | [i:=1..n] : Mensaje B
105
106
Mensajes
Un mensaje se enva de manera condicionada:
Mensajes
Un mensaje que devuelve un resultado:
[x>y] 1: Mensaje
1: distancia:= mover(x,y) B B A
107
108
18
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
109 110
Modelado Conceptual
Clases
Modelado Conceptual:
Organizacin del conocimiento del dominio del problema en un conjunto de abstracciones ordenadas de forma que se obtiene un conocimiento ms profundo del problema
Clases
El mundo real puede ser visto desde abstracciones diferentes (subjetividad) Mecanismos de abstraccin:
111
Clasificacin / Instanciacin Composicin / Descomposicin Agrupacin / Individualizacin Especializacin / Generalizacin
La clasificacin es uno de los mecanismos de abstraccin ms utilizados

112
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
Clases: Notacin Grfica

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

Otros ejemplos:
lista pila primero ultimo aadir quitar cardinalidad
Clases: Encapsulacin
La encapsulacin presenta dos ventajas bsicas: Se protegen los datos de accesos indebidos El acoplamiento entre las clases se disminuye Favorece la modularidad y el mantenimiento Los atributos de una clase no deberan ser manipulables directamente por el resto de objetos
apilar desapilar cardinalidad
115
116
Los niveles de encapsulacin estn heredados de los niveles de C++:
(-) Privado : es el ms fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminologa C++) (#) Los atributos/operaciones protegidos estn visibles para las clases friends y para las clases derivadas de la original (+) Los atributos/operaciones pblic os son visibles a otras clases ( cuando se trata de atributos se est transgrediendo el principio de encapsulacin)
Ejemplo:
Reglas de visibilidad + Atributo pblico : int # Atributo protegido : int - Atributo privado : int + "Operacin pblica" # "Operacin protegida" - "Operacin privada"
117 118
Relaciones entre Clases

Los enlaces entre de objetos pueden representarse entre las respectivas clases Formas de relacin entre clases: Asociacin y Agregacin (vista como un caso particular de asociacin) Generalizacin/Especializacin Las relaciones de Agregacin y Generalizacin forman jerarquas de clases
119
Asociacin
La asociacin expresa una conexin bidireccional entre objetos 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
120
20
Asociacin
Ejemplo:
marido casado -con 0.. 1 0.. 1 mujer Persona jefe nombre 0.. 1 s. s. Administra trabaja-para emplea -a
Asociacin
Especificacin de multiplicidad (mnima...mxima)
1 0..1 M..N * 0..* 1..* Uno y slo uno Cero o uno Desde M hasta N (enteros naturales) Cero o muchos Cero o muchos Uno o muchos (al menos uno)
* Compaa
nombre direccin
empleado
La multiplicidad mnima >= 1 establece una restriccin de existencia

121 122
Asociacin Cualificada
Aerolnea nro_billete *
0..1
Agregacin
La agregacin representa una relacin parte_de entre objetos En UML se proporciona una escasa caracterizacin de la agregacin 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
123 124
Viajero
Tablero Ajedrez
fila columna
Cuadro
Reduce la multiplicidad del rol opuesto al considerar el valor del cualificador
Agregacin: Caracterizacin
1. Puede el objeto parte comunicarse directamente con objetos externos al objeto agregado?
No => inclusiva Si => no inclusiva
4. Puede existir un objeto parte sin ser componente de un objeto
agregado?
Si => flexible No => estricta 5. Cuntos objetos de una clase componente puede tener asociados un objeto agregado? Ms de uno => multivaluada Mximo uno => univaluada 6. Puede el objeto agregado no tener objetos de una clase componente en algn instante? Si => co n nulos permitidos No => con nulos no permitidos
p
125
2. Puede cambiar La composicin del objeto agregado?

Si => dinmica No => esttica
3. Puede el objeto parte ser compartido por ms de un objeto agregado?

No => disjunta Si => no disjunta
En UML slo se distingue entre agregacin y composicin (aggregate composition), siendo esta ltima disjunta y estricta.
126
21
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
Ejemplos
coche 1 0..2 +Padre 1 motor +Hijos *
Persona
Objeto Componente
127 128
Ejemplos
Agregacin
Polgono
1 contiene 3.. * {ordenado}
Clases vs. Objetos

Punto
Persona Empresa
*
Cuenta
*
or
1
Asociacin excluyente
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
130
est-autorizado -en *
Usuario
Estacin

129
Clase de asociacin
Autorizacin prioridad privilegios camb_privil
Jerarquas de Generalizacin/Especializacin
Permiten gestionar la complejidad mediante un ordenamiento taxonmico Se obtiene usando los mecanismos de abstraccin de Generalizacin y/o Especializacin La Generalizacin consiste en factorizar las propiedades comunes de un conjunto de clases en una clase ms general
... Jerarquas de Generalizacin/Especializacin

Nombres usados: clase padre - clase hija, superclase - subclase, clase base - clase derivada Las subclases heredan caractersticas de sus superclases, es decir, atributos y operaciones (y asociaciones) de la superclase estn disponibles en sus subclases
131
132
22

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

Abstracciones ms generales. vehiculo
vehiculo terrestre
vehiculo areo
camion
133
coche
avion
helicoptero
134

La especializacin es una tcnica muy eficaz para la extensin y reutilizacin
coche

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
135 136
funcionando
estropeado
Caracterizacin de la generalizacin en UML:

disjunta - no disjunta total (completa) - parcial (incompleta)

Particionamiento del espacio de objetos => Especializacin Esttica Particionamiento del espacio de estados de los objetos => Especializacin Dinmica En ambos casos consideraremos generalizaciones/especializaciones disjuntas

Un ejemplo de Especializacin Esttica:
vehiculo areo
avion
helicoptero
137
138
23

Un ejemplo de Especializacin Dinmica:

Extensin: Posibles instancias de una clase Intensin: Propiedades definidas en una clase
A
coche
funcionando
estropeado
int(A) int(B) ext(B) ext(A) B

139 140

Estticas:

Dinmicas:
C0
ext(C 0) = ext(C i) ext(C i) ext(Cj ) = Cn C1
C0
ext(C 0) = ext(C i) extt(C i) extt(Cj ) = extt1(C i) extt2(Cj ) Cn
C1
141
142

En la Especializacin Esttica, el objeto es instancia de la subclase desde su creacin y la superclase en las que fue creado. Esta pertenencia es inmutable Puede haber ms de una especializacin esttica o dinmica a partir de la misma superclase

Ejemplo: varias especializaciones a partir de la misma superclase:
comercial vehiculo areo
militar avion
143
helicoptero
144
24

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

Ejemplo: especializaciones dinmicas de la misma superclase:
de menos de 1000kms coche
de ms de 1000 kms funcionando estropeado
145
146

Un ejemplo combinado:
vehiculo

El siguiente es un ejemplo de clasificacin no equilibrada:
comercial vehiculo terrestre vehiculo areo esttica
vehiculo terrestre
esttica esttica camion avion helicoptero militar
de menos de 1000kms dinmica de ms de 1000 kms
coche
camion
coche
Harley Davidson
dinmica
funcionando
estropeado
147
148

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

Ejemplo:
mariposa
oruga
crislida
Lepidptero
Aspecto mariposa 1 estadio
oruga
crislida
Lepidptero
150
25
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
151
Herencia Mltiple
La multiplicidad de la clasificacin mltiple se puede representar tambin mediante asociaciones:
Realiza > Clase * Tipo
Tipo A
Tipo B
Tipo C
152
Herencia Mltiple
Uso disciplinado de la herencia mltiple
conejo
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
153 154
con pelo Herbvoro con plumas omnvoro Animal con escamas carnvoro
Bipedo
Cuadrpedo
Delegacin
Ejemplo: delegacin en lugar de herencia mltiple Animal
Principio de Sustitucin
El Principio de Sustitucin de Liskow (1987) afirma que: Debe ser posible utilizar cualquier objeto instancia de una subclase en el lugar de cualquier objeto instancia de su superclase sin que la semntica del programa escrito en los trminos de la superclase se vea afectado.
Carnvoro
155 156
x Locomocin
x Alimento
Bpedo
Cuadrpedo
Herbvoro
26
Principio de Sustitucin
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 debera implementarse sin este principio
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
157 158
Polimorfismo
Ejemplo: todo animal duerme, pero cada clase lo hace de forma distinta
Zoo 1 * Animal
Polimorfismo
Zoo 1 * Animal Dormir() { }
?
dormir
Len Oso Tigre
?
Len Oso Tigre
Dormir() { sobre el vientre }
159
Dormir() { sobrela espalda }
Dormir() { en un rbol }
160
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
Comentarios
Los Diagramas de Clases v/s los modelos de datos (Diagramas Entidad -Relacin)
161
162
27
Diagramas de Estados Diagramas de Estados

Los Diagramas de Estados representan autmatas de estados finitos, desde el p.d.v. de los estados y las transiciones Son tiles slo para los objetos con un comportamiento significativo El resto de objetos se puede considerar que tienen un nico estado El formalismo utilizado proviene de los Statecharts (Harel)
163
164
Cada objeto est en un estado en cierto instante El estado est caracterizado parcialmente por los valores de los atributos del objeto
Los D. de Estados son autmatas jerrquicos que permiten expresar concurrencia, sincronizacin y jerarquas de objetos Los Diagramas de Estados son grafos dirigidos
Los D. De Estados 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 un evento
El estado en el que se encuentra un objeto determina su comportamiento Cada objeto sigue el comportamiento descrito en el D. de Estados asociado a su clase
Los D. De Estados y escenarios son complementarios
165
166
Ejemplo de un Diagrama de Estados para la clase persona:
contratar en el paro perder empleo jubilarse jubilarse en activo
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
jubilado
167
168
28
Si la comunicacin es sncrona el cliente debe esperar la respuesta. Con lo cual en el cliente tendramos:
a
Las guardas permiten condicionar la transicin:
a Evento[ condicin ] b
plantear pregunta recibir respuesta
espera respuesta
169
170
Acciones
Podemos especificar la ejecucin de una accin como consecuencia de la transicin:
Acciones
Podemos especificar el envo de un evento a otro objeto como consecuencia de la transicin:
a
b
Evento[ condicin ] / accin
Evento( arg1, arg2 )[ condicin ] / ^otro_objeto.evento(arg2)
Dicha accin tambin se considera instantnea

171
b
172
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
.. 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
173
174
29
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
Actividades
Cuando una actividad finaliza se produce una transicin automtica de salida del estado
a do: actividad [ not condicin ] b
[ condicin ]
175
176
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
Ejemplo:
a e2 e2 c e1 b
177
178
Quedara como:
e1
Las transiciones de entrada deben ir hacia subestados especficos:
e1 a e2 e0 b
e2
c
c
179 180
30
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 e2 e0 b c
Es posible ocultar los detalles de los subestados:
c e0
181
182
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
Ejemplo:
e1 e1
183
184
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
Historial
Ejemplo:
a
d2 in h out d1 x y
H
185 186
31
Historial
Tambin es posible la memorizacin para cualquiera de los subestados anidados (aparece un * junto a la H)
a d2 in h out d1
H*
Historial
Ejemplo:
Enjuague Lavado Secado
Cerrar Abrir Puerta
Cerrar Abrir Puerta
Espera
187 188
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
Destruccin de Objeto
Ejemplo:
En vuelo crash
despegar Crear(matricula) En tierra
aterrizar
189
190
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
191
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
192
32
Ejemplo v.2:
a
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), de un caso de uso o de un proceso de negocio (Workflow) Una actividad puede considerarse un estereotipo de estado
193 194
/ Abrir ranura esperar dinero entry: Mostrar mensaje exit: cerrar ranura Temporizador (30 segundos) anular transaccin
Depsito efectuado
...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
Ejemplos
Buscar Bebida [no hay caf] [no zumo] [hay zumo] [hay caf Poner caf en filtro Aadir agua al depsito Coger taza Poner filtro en mquina Coger zumo
Encender mquina ^cafetera.On Caf en preparacin indicador de fin Servir caf Beber
196
195
...Ejemplos (con bandas)

Pasajero Vendedor Airline
Solicitar pasaje Verificar existencia vuelo Dar detalles vuelo Informar alternativas y precios Seleccionar vuelo
Modelado de Componentes
Solicitar pago Reservar plazas Pagar pasaje Emitir billete

197 198
Confirmar plaza reservada
33
Diagrama de Componentes
Los diagramas de componentes describen los elementos fsicos del sistema y sus relaciones Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutable
...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
199 200
Diagramas de Componentes
La representacin grfica es la siguiente:
Especificacin Cuerpo Genrico
Diagramas de Componentes
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
Package specification
Package body
Generic package
201 202
Dependencias entre Componentes

Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente
Subsistemas
Los distintos componentes pueden agruparse en paquetes segn un criterio lgico y con vistas a simplificar la implementacin Son paquetes estereotipados en <<subsistemas>>
<<subsistema>> NewPackage4
203
204
34
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 necesariamente una descomposicin funcional Paquetes (Categorias) y clases en el nivel lgico. Paquetes (Subsistemas) y componentes en el nivel fsico
Modelado de Distribucin
205
206
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
Los estereotipos permiten precisar la naturaleza del equipo:
Dispositivos Procesadores Memoria
Nodo
Los nodos se interconectan mediante soportes bidireccionales (en principio) que pueden a su vez estereotiparse
207 208
Ejemplo de conexin entre nodos:
<<Procesador> Nodo <<dispositivo>> nodo2
<<<<TCP/IP>>>> conexin1
Proceso de Desarrollo de SW con UML
conexin7 <<RDSI>>
En Rational Rose podemos distinguir entre el dispositivo por estereotipado y el dispositivo con su propio smbolo
dispositiv o
209
210
35
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 ...
Hacia un Mtodo OO
UML no incorpora por s mismo el modelo de proceso Los autores destacan las siguientes caractersticas de UML como esenciales para determinar el proceso de desarrollo:
Est dirigido 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
211
212
Hacia un Mtodo OO
Requisitos Anlisis Diseo Implement. Pruebas
Hacia un Mtodo OO
Las 4+1 vistas de Kruchten (1995):
Vista de Realizacin Vista de los Casos de Uso Vista de Procesos Vista de Distribucin
Vista Lgica
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

213 214
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
215
...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
216
36
...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)
217
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

218
...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 reutilizacin de programas o a la validacin funcional Cada prototipo corresponde a 1 ms casos de uso
219
Reparto de Actividades
Actividades
Ince ption Requisitos Una iteracin en la fase de elaboracin Anlisis Elabora tion
Fases
Construc tion Tr ansition
Diseo
Implementacin
Pruebas
P r eli m in ary I te ratio n (s) iter. #1 iter. #2 iter. #n iter. #n +1 ite r. #n + 2 i te r. #m iter. #m + 1
220
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
221
...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

222
37

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
223

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

Inception Requisitos Una iteracin en la fase de elaboracin Anlisis Ela boration C onstr uction Tra nsition
...Esfuerzo Respecto de las Fases

Inception Ela boration C onstr uction Tra nsition Requisitos Una iteracin en la fase de elaboracin Anlisis
15% 10% 15% 30% 15%

P re lim i na ry Iter atio n(s) i ter. #1 i te r. #2 i te r. #n i te r. # n+ 1 iter. #n +2 iter. #m ite r. # m +1 225
Diseo
Diseo
Implementacin
Implementacin
Pruebas
Pruebas
P re lim i na ry Iter atio n(s) i ter. #1 i te r. #2 i te r. #n i te r. # n+ 1 iter. #n +2 iter. #m ite r. # m +1
5% mantenimiento 10% gestin cambios
Esfuerzo: Duracin:
5% 10%
20% 30%
65% 50%
10% 10%
226
Claves en el Desarrollo de SI
Notacin UML
Conclusiones
Herramientas p.e. Rational Rose

227
Proceso p.e. Proceso Unificado

228
38
Contexto de Desarrollo : Grado de Complejidad
Modelado de SI: Algunas Reflexiones
Modelar para la concebir el sistema y/o para la documentarlo Pragmatismo, los modelos deben ser tiles Sencillez y Elegancia Distintos nivel de abstraccin, diferentes modelos Seguimiento de transformaciones durante el proceso (Traceability ) Sincronizacin de modelos Dificultades para la introduccin de tcnicas y herramientas de modelado
230

229
... Finalmente
Apostar por enfoque Orientado a Objetos usando notacin UML Problemas actuales en implementacin, al usar entornos de programacin visual y/o bases de datos relacionales Posibles mejoras a mediano plazo
Evolucin: Uso de BDOO y/o mejoras en los LPOO Revolucin: Generacin Automtica de Cdigo a partir de Modelos OO (Compilacin de Modelos)
231
Bibliografa Recomendada
UML
www.omg.org / uml/ Martin Fowler , UML Destilled (UML Gota a Gota) Terry Quatrani , Visual Modeling ..., un caso de estudio
Herramientas CASE
International Council in SE (INCOSE) Tools Database Working Group . www.incose.org/tools/
Otras
Desmond DSouza, componentes www.enteract.com / bradapp/docs/patterns -intro.html, patrones Revista IEEE Software, Conferencias: OOPSLA, ECOOP
232
39

Uml

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Uml

Cargado por

Copyright:

Formatos disponibles

Contenido Anlisis y Diseo Orientado a Objetos usando la notacin UML

Ing. Mario Alberto Prez Universidad Nacional de Colombia

Basada en material de la Universidad Politcnica de Valencia

Construccin de una casa para fido

Construccin de una casa

Abstraccin - Modelado Visual (MV)

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

Breve Tour por UML

=> Necesidad de una notacin estndar

UML 2.0 UML 1.4 UML 1.3

Participantes en UML 1.0

UML aglutina enfoques OO

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

Intellicorp and James Martin & co. (James Odell)

Gamma et. al.

Mtodos Formales en Modelado

... Diagramas de UML

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

Diagramas de Casos de Uso

Cliente Establecer Crdito Supervisor

Realizar prstamo Socio Encargado

Solicitar nueva tarjeta

Reintegro cuenta corriente

Situacin libro ok Introducir prstamo

Reintegro cuenta crdito

Diagramas de Clases (y objetos)

2: Solicitar prstamo 3: Verificar situacin socio

8: Autorizar prstamo 4: Situacin socio ok

: Encargado 7: Introducir prstamo : Prsta mo

5: Verificar situacin libro : Ficha li bro

Ejemplos (Clase y Visibilidad)

Ejemplos (Clase Asociacin)

Cargo nombre sueldo 1..* +subordinado

nmero_prstamos = 0 sin prstamos

nmero_prstamos > 0 con prstamos prestar

1 Avin militar Avin comercial Lnea area

Otro Ejemplo (con swim lines)

Poner filtro en mquina

Informar alternativas y precios Seleccionar vuelo

Solicitar pago Reservar plazas Pagar pasaje Emitir billete

Confirmar plaza reservada

Gestin de Cuentas Rutinas de Coneccion Comment Comment

Interfaz de Terminal Comment

El Paradigma Orientado a Objetos

Por qu la Orientacin a Objetos?

Por qu la Orientacin a Objetos?

Modelado integrado de propiedades estticas y dinmicas del mbito del problema

Facilita construccin, mantenimiento y reutilizacin

Sin embargo, existen problemas ...

Reflexiones respecto de Situacin Actual de Desarrollo de SI

Fundamentos del Modelado Orientado a Objetos

Diagrama de Clases Diagrama de Estados Diagramas de Actividad

Bases de Datos (Objeto-) Relacionales

Casos de Uso: Relaciones

Actor Caso de Uso

Casos de Uso: Relaciones

Casos de Uso: Relaciones

<<extend >> Caso de uso destino Caso de uso origen

Casos de Uso: Relaciones

Casos de Uso: Relaciones