UML-RUP un caso prctico

Mg. Carlos Gerardo Neil

Facultad de Tecnologa Informtica UAI
noviembre de 2004

ndice
Introduccin al Modelo Orientado a Objetos Lenguaje de Modelado Unificado -UMLLenguaje de Restriccin de Objetos -OCLPatrones de diseo OO Proceso de desarrollo Persistencia de datos Un caso prctico

Introduccin Algunas Consideraciones Generales

Anlisis, Diseo, Implantacin

El anlisis OO pone nfasis en la investigacn del problema y los requisitos, en vez de ponerlo en la solucin El diseo pone nfasis en una solucin conceptual, que satisface los requisitos, en vez de ponerlo en la implantacin La implantacin es la traduccin de la solucin a un lenguaje de programacin determinado

Objetos
Un objeto es cualquier cosa real o abstracta, acerca de la cual almacenamos datos y las operaciones que controlan dichos datos Se opone al anlisis estructurado donde los datos y el comportamiento estn dbilmente relacionados Tenemos que olvidarnos del modelo estructurado...

Porqu la orientacin a objetos?

Estabilidad de modelalo respecto a las entidades del mundo real Simplicidad del modelo (objetos, mensajes, clases, herencia y polimorfismo) para analisis, diseo e implementacin Posibilidad de reutilizar elementos

Propiedades de los Objetos

El estado de un objeto abarca todas las propiedades (normalmente estticas) del mismo, ms los valores actuales (normalmente dinmicos) de cada una de esas propiedades El comportamiento es como acta y reacciona un objeto, en trminos de sus cambios de estado y paso de mensajes La identidad es aquella propiedad de un objeto que lo distingue de todos los dems objetos

Clases
Un objeto es una instancia de una clase Una clase especifica una estructura de datos y las operaciones permisibles que se aplican a cada uno de sus objetos. Los objetos se vinculan mediante enlaces Cada familia de enlaces entre objetos corresponde a una asociacin entre clases de esos objetos

Relaciones entre Clases

Se descompone (clases) para comprender, se une (asociaciones) para contruir Los enlaces entre objetos son instancias de la asociacin entre sus clases La asociacin representa un acoplamniento dbil, la Agregacin y la Composicin expresa un acoplamiento ms fuerte en clases

Jerarqua entre clases

La generalizacin consiste en factorizar los elementos comunes de un conjunto de clases en una clase ms general llamada superclase La herencia es una tcnica de los lenguajes de programacin para construir una clase a partir de una o varias clases, compartiendo atributos y operaciones

Polimorfismo
Permite la posibilidad de desencadenar operaciones diferentes en respuesta a un mismo mensaje
Figura Editor dibujar() mover()

Circulo dibujar() mover()

Triangulo dibujar() mover()

Rectangulo dibujar() mover()

La interacciones entre objetos se escriben segn los trminos de las especificaciones definidas en las superclases

Anlisis Estructurado vs. Anlisis Orientado a Objetos

El enfoque tradicional del anlisis y diseo estructurados, se descompone el problema en funciones o procesos y estructuras de datos En un enfoque OO se busca descomponer el problema, no en funciones, sino en unidades ms pequeas denominadas objetos,

Beneficios del Enfoque OO

Disminucin del bache semntico entre anlisis y diseo proveyendo una representacin consistente en todo el ciclo de vida Enfoque OO La transicin del anlisis al diseo es un refinamiento Enfoque Estructurado En la transicin del anlisis al diseo pasamos del DFD al DE mediante un proceso heurstico no trivial

Bibliografa Bsica (clsica)

Booch G. Anlisis y Diseo Orientado a Objetos, con Aplicaciones. 2 ed. USA: Addison-Wesley; 1996 Jacobson I, Christerson M, Jonsson P, vergaard G. ObjectOriented Software Engineering, a Use Case Driven Approach. 1 ed. England: Addison-Wesley; 1992 Rumbaugh J, Blaha M, Premerlani W, Eddy F, Lorensen W.. Modelado y Diseo Orientado a Objetos. Espaa: PrenticeHall; 1996

UML
Qu son los modelos? Para qu sirven los modelos? Cules son los modelos de UML? Se usan todos...?

Qu son los modelos?

Un modelo es una representacin que capta los aspectos ms importantes de lo que estamos modelando y simplifica u omiten el resto Un modelo de un sistema software est construido en un lenguaje de modelado. Tiene semntica y notacin. Incluye grficos y texto

Para qu sirven los modelos?

Para pensar el diseo de un sistema
La simplicidad de crear y de modificar modelos permite un pensamiento creativo e innovacin a bajo precio

Para explorar econmicamente mltiples soluciones Para trabajar con sistemas complejos

UML (lenguaje de modelado unificado) es un lenguaje para especificar, construir, visualizar y documentar los objetos de un sistema de software.

Diagrama UML
Use Case Use Case Diagramas Diagrams de Diagrams Casos de Uso State State Diagramas Diagrams de Diagrams Clases

Use Case Use Case Diagramas Diagrams de Diagrams Secuencia Scenario Scenario Diagrams de Diagramas Diagrams Colaboracin

State State Diagramas Diagrams de Diagrams Objetos State State Diagrams de Diagramas Diagrams Componentes

Modelo

Scenario Scenario Diagramas Diagrams de Diagrams Estados

Diagramas de Actividad

Component Component Diagrams Diagramas de Diagrams

Distribucin

Diagrama de Casos de Uso

Reintegro Cuenta Corriente

<<include>>

Cliente

Verificar Operacin <<include>>

Reintegro Cuenta de Crdito

Muestra las distintas operaciones que se esperan de un sistema y cmo se relacionan con su entorno

Diagramas de Secuencia
: Encargado :WInPrstamos :Socio :Video :Prstamo

prestar(video, socio) verificar situacin socio verificar situacin video

registrar prstamo entregar recibo

Muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo

Diagrama de Colaboracin
:Socio

:Video 2: verificar situacin socio

1: prestar(video, socio) :WInPrstamos 5: entregar recibo : Encargado

3: verificar situacin video

4: registrar prstamo

:Prstamo

Muestra la forma de representar interacciones entre objetos,

Diagrama de Estados
alta baja

sin prstamos

nmero_prstamos = 0

prestar

devolver[ nmero_prstamos = 1 ]

nmero_prstamos > 0 con prstamos prestar

devolver[ nmero_prstamos > 1 ]

Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicacin, junto con los cambios que permiten pasar de un estado a otro

Diagrama de Actividad
Buscar Bebida [ hay caf ] [ hay zumo ] Poner caf en filtro Aadir agua al depsito Coger taza Coger zumo [ no hay caf ] [ no zumo ]

Poner filtro en mquina

Encender mquina / cafetera.On Caf en preparacin indicador de fin Servir caf Beber

Muestran transiciones internas, sin hacer mucho nfasis en transiciones o eventos externos.

Diagrama de Componentes
Interfaz de Terminal Control y Anlisis

Gestin de Cuentas

Rutinas de conexin

Acceso a BD

Muestra las dependencias lgicas entre componentes software

Diagrama de Despliegue
Servidor Central Acceso a BD Comment Control y Anlisis Comment

Rutinas de Coneccion Comment

Terminal de Consulta Rutinas de Coneccion Comment

Interfaz de Terminal

Punto de Venta

Rutinas de Coneccion Comment

Gestin de Cuentas Comment

Interfaz de Terminal Comment

Muestran la organizacin de los componentes del sistema

Modelo y Metamodelo
Para la definicin y formalizacin de UML, los diferentes conceptos se han modelado, a su vez, con UML. Esta definicin recursiva de denomina Metamodelo El metamodelo describe de manera formal los elementos de modelado, la sintaxis y la semntica asociados a ellos

Extracto del Metamodelo

Clase *
enlaza enlaza instancia de

Objeto *

Relacion *

instancia de

Enlace *

Diagrama de Clases

Diagrama de Objetos

Los modelos ms utilizados...

Casos de Uso

Casos de Uso
Especifica el comportamiento de un sistema o una parte del mismo Es una descripcin de un conjunto de secuencias de acciones, donde cada secuencia representa la interaccin de los elementos externos del sistema (sus actores) con el propio sistema

Los casos de uso no son orientados a objetos

Diagrama de Casos de Uso

actor 2

<<extend>> caso de uso 2

caso de uso 1

<<include>> caso de uso 4

actor 1

caso de uso 3

Actores y Escenarios
Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos de uso cuando interactan con stos Un escenario es una secuencia especfica de acciones entre los actores y el sistema
externo al sistema persona sistema maquinas

Interactua con el sistema

actor

Tipo de Actores
Actores primarios: utilizan las funciones principales del sistema Actores secundarios: efectan tareas administrativas o de mantenimiento
<< actor>> TARJETA DE CREDITO

0..1 0..*

secundario

Cliente CVLI
secundario 0..1
<< actor>> GESTOR DE LIBROS

0..1 secundario
<< actor>> GESTOR DE ENVIO

Administrador Sistema

0..1

Casos de Uso
Describe tanto lo que hace el actor como lo que hace el sistema cuando interacta con l Estn acotados al uso de una determinada funcionalidad, claramente diferenciada, del sistema

Actor

caso de uso

Casos de Uso
Relaciones de extends La funcionalidad de un caso de uso incluye un conjunto de pasos que ocurren slo en algunas oportunidades La excepcin consiste en interrumpir el caso de uso B y pasar a ejecutar otro caso de uso A
<<extend>>

Caso de Uso B

Caso de Uso A

un ejemplo...

Consultar libros en general

Consultar novedades <<extend>> <<extend>> <<extend>>

Consultar ofertas

Consultar libro Cliente

Casos de Uso
Relaciones include Es comn que la misma funcionalidad del sistema sea accedida a partir de varios casos de uso
<<include>>

Caso de Uso A

Caso de Uso B

un ejemplo...

Consultar libros en general

Consultar novedades <<extend>>

Consultar ofertas

<<extend>>

<<extend>>

<<include>> Consultar libro

<<include>>

buscar libros

comprar libro

Cliente

Comenzamos con el caso prctico...

Compaa de Ventas de Libros por Internet (CVLI)

El cliente accede a la informacin sobre los libros a travs de la Web El cliente elegir un nombre de usuario y una clave como mtodo de autentificacin para efectuar las transacciones El cliente podr realizar bsquedas por autor, ttulo o ISBN El cliente debe estar previamente registrado El cliente puede establecer preferencias de envo El cliente puede introducir opciones de empaquetado La librera deber recoger los datos de los pedidos La librera deber rearmar en uno nico los pedidos aislados que estn dentro del plazo de 90 minutos La empresa puede realizar envos parciales en funcin de la disponibilidad de los tems

Identificacin de los actores

Cliente (primario) Administrador del sistema (primario) Tarjeta de crdito (secundario) Gestor de libros (secundario) Gestor de envio (secundario)

Diagrama de Contexto
Permite determinar las fronteras del sistema
<< actor>>

0..1 0..*

TARJETA DE CREDITO

secundario

Cliente CVLI
secundario 0..1
<< actor>> GESTOR DE LIBROS

0..1 secundario
<< actor>> GESTOR DE ENVIO

Administrador Sistema

0..1

Pre y Pos Condiciones

Precondiciones: establece lo que siempre debe cumplirse antes de comenzar un caso de uso Poscondiciones: establece qu debe cumplirse cuando el caso de uso se completa con exito

Identificacin de los Casos de Uso

Cliente Registrarse al sistema Consultar libro Comprar libro Establecer preferencias de envo y empaquetado Administrador del sistema Armar pedidos Rearmar pedidos

Diagrama de Casos de Uso

Registrarse al sistema Gestor de Libros

Consultar libro Tarjeta de Credito Cliente Comprar libro

Armar pedidos

Establecer preferencias de envo y empaquetado

Rearmar pedidos

Administrador del Sistema

Descripcin de los Casos de Uso

Titulo: Registrarse al sistema Resumen: el cliente, antes de realizar una primera transaccin de compra o bsqueda de libros, debe introducir todos sus datos por nica vez, los cuales sern guardados por el sistema y ste le ofrecer la posibilidad de tener una clave y contrasea que utilizar para cada transaccin que realice posteriormente, el cliente tendr la posibilidad de hacer cambios en los datos introducidos, incluso en su clave y contrasea Actores: cliente (primario), tarjeta de crdito (secundario)

Descripcin de los Casos de Uso

Titulo: Consultar libro Resumen: el cliente, una vez ingresado al sistema, podr navegar por el mismo en bsqueda de libros, novedades, ofertas, etc. Actores: cliente (primario), gestor de libros (secundario)

Descripcin de los Casos de Uso

Titulo: Comprar libro Resumen: el cliente, una vez ingresado al sistema, podr realizar compras de libros, eligindolo de una lista ofrecida por la empresa, cada libro elegido, se sumar a una carrito de compra, etc. El cliente informar el nmero y tipo de tarjeta de crdito para realizar el pago. Deber especificar direccin de envi y forma de pago Actores: cliente (primario), gestor de libros (secundario), tarjeta de crdito (secundario)

Refinamiento: include y extend

Consultar libros en general

Consultar novedades <<extend>> <<extend>> <<extend>>

Consultar ofertas

Gestor de Libros

Consultar libro Cliente <<include>>

Tarjeta de Credito

Comprar libro <<extend>>

Establecer preferencias de envo y empaquetado

Desarrollo de un Caso de Uso

Titulo: Registrarse al sistema Actores: cliente (primario), tarjeta de crdito (secundario) Fecha de creacin: Fecha de actualizacin: Versin Precondicin: el cliente ingresa al sistema por primera vez

Escenario principal
1. El cliente ingresa a la pagina web de CVLI 2. El cliente ingresa a la opcin registracin 3. El sistema solicita ingreso de los datos personales: nombre y apellidos, direccin, localidad, cdigo postal, pas 4. El cliente ingresa los datos personales 5. El sistema evala el pas de origen y solicita ingreso de los datos de la tarjeta de crdito: tipo de tarjeta, nmero, fecha lmite de validez 6. El cliente ingresa datos de la tarjeta de crdito 7. El sistema chequea el nmero de la tarjeta de crdito 8. El sistema (teniendo en cuenta el pas de origen) solicita la opcin de preferencia de envo por omisin, esta opcin puede modificarse en cada envo 9. El cliente ingresa preferencia de envo 10. El sistema solicita, para finalizar, el ingreso de la clave de acceso y la contrasea 11. El cliente ingresa clave y contrasea 12. El sistema solicita reingreso de contrasea 13. El cliente reingresa contrasea 14. El sistema informa que la transaccin se realizo correctamente

Flujo alternativo
A1 Ingreso incorrecto de los nmeros de los datos La secuencia comienza en el punto 4 del escenario principal 5. El sistema informa que los datos ingresados son incorrectos 6. El sistema pide ingreso de nmeros nuevamente El escenario vuelve al punto 5 A2 Ingreso incorrecto de los nmeros de la tarjeta de crdito La secuencia comienza en el punto 7 del escenario principal 7. El sistema informa que los nmeros ingresados son incorrectos 8. El sistema evala si la cantidad de veces que ingreso el numero de tarjeta en forma incorrecta es menor a 3 9. El sistema pide ingreso de nmeros nuevamente El escenario vuelve al punto 8 Poscondicin: el cliente est registrado en el sistema

Algunos puntos a tener en cuenta....

Los casos de uso son texto, no grfico Comenzar identificando y nombrando los casos de uso ms importantes Comenzar por una descripcin no necesariamente completa ni exacta y despues refinarla En cada iteracin del proceso de desarrollo se amplia la funcionalidad del caso de uso

Diagrama de clases

Diagrama de Clases

Las clases representan los bloques de construccin ms importantes de cualquier sistema orientado a objetos. Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica.

Diagramas de clases UML

(-) visibilidad privada (#) visibilidad protegida (+) visibilidad pblica atributo Visibilidad nombre : tipo = valor inicial ejemplo - temperatura : numrico = 0
Nombre de Clase atributo 1 atributo 2 atributo n operacion 1() operacion 2() operacion n()

operacin Visibilidad nombre (lista parmetros ) : tipo de expr retornada ejemplo +BuscarValor (n:int) : int

Asociaciones
Son relaciones entre clases que indica alguna conexin significativa que deseamos preservar Tipo de asociaciones: Unarias, Binarias, n-arias Clases asociacin Cada instancia de una asociacin (enlace) es una tupla de referencias a objetos

Asociacin y Enlace
asociacin
empleado empleado
trabaja para

empleador 1

empresa

1..*

(emp1, em)

enlace
em : empresa

emp1 : empleado

emp2 : empleado

(emp3, em)
emp3 : empleado

(emp2, em)

Banco

Nombre de rol
0..1 0..* cliente Persona esCasado : Booleano esDesocupado : Booleano fechaDeNacimiento : Fecha edad : Entero nombre : Literal apellido : Literal sexo : enum{ masculino, femenino } ingresos(Fecha) : Entero esposo 0..1 Trabajo cargo : Literal fechaDeInicio : Fecha salario : Entero

Asociacin binaria
gerente Compaa compaasGerenciadas nombre : Literal cantidadDeEmpleados : Entero empleador 0..* valorAccin() 0..*

empleado 0..* esposa 0..1

Multiplicidad

Asociacin unaria

Matrimonio lugar : Literal fecha : Fecha

Clase asociacin

Agregacin y Composicin

Agregacin
Una clase forma parte de otra clase Es un tipo de asociacin ms fuerte Relacin no simtrica entre clases donde uno de los extremos cumple un rol dominante

Composicin
Dependencia existencial. El elemento dependiente desaparece al destruirse el que lo contiene Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene Los objetos contenidos no son compartidos

Clase Asociacin
Una asociacin puede representarse por medio de una clase para aadir, por ejemplo, atributos y operaciones
empresa empleador 1..* 1..* empleado empleado

cargo nombre sueldo

Asociacin n-aria

Generalizacin
relacin es-un-tipo-de
superclase Figura color dibujar() mover()

subclases

Circulo dibujar() mover()

Triangulo dibujar() mover()

Rectangulo dibujar() mover()

Herencia es el mecanismo mediante el cual los elementos ms especficos incorporan la estructura y el comportamiento de elementos mas generales

Lista de categoras de clases

La identificacion de clases del dominio del problema tiene mucho de arte Objetos tangibles o fsicos (personas) Lugares (escuela) Roles de la gente (gerente) Contenedores (tienda) Cosas de un contenedor (artculos) Organizaciones (departametno de ventas) Hechos (venta, pago)

Algunos puntos a tener en cuenta....

Comenzar con el modelo del dominio

Identificar las clases y sus asociaciones Incluir los atributos ms importantes No preocuparse inicialmente por las operaciones No pensar en jerarquas (al principio...)

Seguimos con el caso practico...

Diagrama de clases
Cliente
nombre apellido direccion te profesion

1
usa

1
tiene

1
CarritoCompra es de

0..* OrdenCompra 1
numero tarjeta direccionEntrega opcionEntrega

1
tiene 1..*

Items
cantidad

EjemplarLibro

0..*

pertenecen

numero precio
1..*

tiene

1 Libro
isbn titulo editorial soporte categoria

Autor
esta escrito por

1..*

1..*

nombre apellido

Refinamiento del Diagrama de Clases

Incluimos: Relaciones de jerarqua Patrones de diseo (opcional) Agregaciones y composiciones Restricciones OCL (opcional) Algunas operaciones evidentes

Seguimos con el ejemplo...

ClienteOcacional ClienteEspecializado

profesion Cliente
nombre apellido direccion te ingresarDatos() tiene

0..* 1 1

OrdenCompra
numero IngresarPreferencias()

1
usa es de

1
CarritoCompra

1
agregarItem() venta()

1 Tarjeta
nombre numero

1
DireccionCompra

1
OpcionEntrega

calle numero

tipo

1
tiene 1..* Categoria

tipo
EjemplarLibro

Items
cantidad crear() subtotal()

0..* pertenecen 1

numero darPrecio()

1 1..*
tiene pertenece 1..*

1 Autor
nombre apellido

Libro
isbn titulo editorial ConsultarLibro()

1..*

escrito por

1..*

Diagrama de Secuencia

Diagrama de Secuencia
Muestra los objetos que se encuentran en el escenario y la secuencia de mensajes intercambiados entre ellos para llevar a cabo la funcionalidad descrita por el escenario.

Ejemplo de diagrama de secuencia

Diagrama de Secuencia
Los diagramas de secuencia se utilizan en la etapa de anlisis para documentar casos de uso En la etapa de diseo se utilizan conjuntamente con los diagramas de colaboracin para designar las responsabilidades de las clases

Diagrama de Secuencia del Sistema

Muestra, para un escenario especfico de un caso de uso, los eventos que generan los actores externos Los sistemas se tratan como cajas negras Muestran los mensajes que podran ser traducidos a operaciones dentro del sistema (y sern distribuidos, en la etapa de diseo, a los objetos del sistema)

Seguimos con el ejemplo...

: SISTEMA

: cliente

ingresarSistema()

ingresarDatosPersonales()

ingresarTarjetaCredito()

ingresarPreferenciasEnvio()

ingresarClaveContrasea()

DSS "Registrarse al sistema"

Seguimos con el ejemplo

Debera quedar claro que el sistema (si estuviera compuesto por una sla clase) podra tener, por ahora, las siguientes operaciones ... Esto nos brinda una primera aproximacin de las posibles operaciones, no implica necasariamente que sern ellas las operaciones del sistema (estamos en una epata inicial...)
SISTEMA
ingresarSistema() ingresarDatosPersonales() ingresarTarjetaCredito() ingresarPreferenciasEnvio() ingresarClaveContrasea()

Algunos puntos a tener en cuenta....

El diagrama de secuencia (DSS) lo utilizamos en la etapa de anlisis, conjuntamente con los casos de uso para la identificacin de los mensajes Los mensajes al sistema sern respondidos por l mediante operaciones que sern distribuidas a los diferentes objetos en la etapa de diseo

Diagramas de Colaboracin

Diagramas de Colaboracin
Muestra las interacciones organizadas en torno a los objetos y los enlaces entre ellos Lo utilizamos en la fase de diseo para asignar responsabilidades a las clases (definir dnde ubicar las operaciones)

Representacin de los Mensajes

Representacin de los Mensajes

Ejemplo de Diagrama de Colaboracin

Algunos puntos a tener en cuenta....

Los diagramas de colaboracin lo utilizamos en la etapa de diseo, conjuntamente con los patrones para asignacin de responsabilidades, para la distribucin de operaciones en las clases en la etapa de diseo

Bibliografa bsica
Martin Fowler with Kendall Scott UML Distilled second edition- A Brief Guide to the Standard Object Modeling LanguageAddison Wesley Reading, Massachusetts 2000 Grady Booch, James Rumbaugh and Ivar Jacobson : The Unified Modeling Language User Guide, AddisonWesley, 1999. James Rumbaugh, Ivar Jacobson and Grady Booch: The Unified Modeling Language Reference Manual, Addison-Wesley, 1999. http://www.uml.org/

Patrones de Diseo

Otra forma de reutilizacin...

Patrones de Diseo
Disear software orientado a objetos es difcil, ms an disear software orientado a objetos reutilizables. Se deben encontrar objetos apropiados, definir jerarquas de herencia y de interfaces y establecer relaciones entre ellas. El diseo debe satisfacer las necesidades actuales del usuario adems de contemplar futuros problemas o requerimientos.

Patrones de Diseo
El trmino patrn se utiliz inicialmente en el campo de la arquitectura, por Christopher Alexander, a finales de los 70s. Este conocimiento es transportado al mbito del desarrollo de software orientado por objetos y aplicado al diseo.
Design Patterns: Elements of Reusable Object-Oriented Software Gamma

Patrones de Diseo

Los patrones de diseo permiten la reutilizacin exitosa de diseos y arquitecturas ms rpidamente, adems de ayudar a elegir alternativas de diseo que hace a los sistemas reutilizables.

Aprovechar las experiencia de los desarrolladores

Patrones de Diseo
elementos esenciales El nombre del patrn: se usa para describir un problema de diseo, su solucin y las consecuencias, en una o dos palabras. El problema: describe cundo aplicar el patrn, explica el problema y su contexto La solucin: describe los elementos que hacen al diseo, sus relaciones, responsabilidades y colaboraciones Las consecuencias: establecen los costos y beneficios de aplicar el patrn

Ejemplo: Patrn Adaptador

Convierte la interfaz de una clase en la interfaz que el cliente espera. Un objeto Adaptador provee la funcionalidad prometida por una interfaz, sin tener que asumir qu clase es usada para implementar la interfaz. Permite trabajar juntas a dos clases con interfaces incompatibles.

Ejemplo: Patrn Adaptador

Diagrama general del patrn

Ejemplo: editor de grficos

Figura Editor dibujar() mover() Rectangulo dibujar() mover()

3DFigura
3Ddibujar() 3Dmover()

3DAdaptador dibujar() mover()

Circulo dibujar() mover()

Triangulo dibujar() mover()

Esfera
3Ddibujar() 3Dmover()

Paralelepipedo 3Ddibujar() 3Dmover()

Piramide
3Ddibujar() 3Dmover()

La interacciones entre objetos se escriben segn los trminos de las especificaciones definidas en las superclases

Asignacin de Responsabilidades a las Clases

Asignacin de responsabilidades a las clases

Despues de la identificacin de los requisitos de los usuarios y de la creacin del modelo del dominio, aada operaciones en las clases de software y defina el paso de mensajes entre los objetos para satisfacer los requisitos Decisiones poco acertadas sobre la asignacin de responsabilidades de cada clase, dan origen a sistemas y componentes frgiles y difciles de mantener, entender, reutilizar o extender

Responsabilidades
Las responsabilidades se relacionan con las obligaciones de un objeto respecto de su comportamiento. Estas responsabilidades pertenecen, esencialmente, a dos categoras: conocer y hacer.

Responsabilidades
Entre las responsabilidades de un objeto relacionadas con el hacer se encuentran: Hacer algo uno mismo. Iniciar una accin en otros objetos. Controlar y coordinar actividades en otros objetos.

Responsabilidades
Entre las responsabilidades de un objeto relacionadas con el conocer se encuentran: Estar enterado de los datos privados encapsulados. Estar enterado de la existencia de objetos conexos. Estar enterado de cosas que se pueden derivar o calcular.

Seguimos con el ejemplo...

Cliente
nombre apellido direccion te profesion

1
usa

1
tiene

1
CarritoCompra es de

0..* OrdenCompra
numero tarjeta direccionEntrega opcionEntrega

1 1
tiene 1..*

Items
cantidad

EjemplarLibro

0..*

pertenecen

numero precio
1..*

tiene

1 Libro
isbn titulo editorial soporte categoria

Autor
esta escrito por

1..*

1..*

nombre apellido

El Patrn Experto [Larman]

Nombre: Experto. Problema: Cul es el principio fundamental en virtud del cual se asignan las responsabilidades en el diseo orientado a objetos? Solucin: Asignar una responsabilidad al experto en informacin: la clase que cuenta con la informacin necesaria para cumplir la responsabilidad.

El Patrn Experto
Ejemplo: quin es el responsable de saber la cantidad de tems vendidos?. Desde el punto de vista del patrn Experto, deberamos buscar la clase de objetos que posee informacin sobre los Items, el objeto que conoce esto es CarritoCompra

El Patrn Experto
Qu informacin hace falta saber para determinar la cantidad de items pedidos y el precio para saber la venta total? La cantidad de items pedido est en la clase Items y el precio, en EjemplarLibro, ambos tienen la informacin necesaria para realizar la responsabilidad

Seguimos con el ejemplo...

1: venta() 2: s := subtotal() 3: p := darPrecio()

: CarritoCompra

: Items

: EjemplarLibro

CarritoCompra

venta() 1
tiene 1..*

Items
cantidad subtotal()

EjemplarLibro

0..* pertenecen 1

numero precio darPrecio()

El Patrn Creador [Larman]

El patrn Creador gua la asignacin de responsabilidades relacionadas con la creacin de objetos, tarea muy frecuente en los sistemas orientados a objetos. El objetivo de este patrn es encontrar un creador que debemos conectar con el objeto producido en cualquier evento

El Patrn Creador
Nombre: Creador. Problema: Quin debera ser responsable de crear una nueva instancia de alguna clase? La creacin de objetos es una de las actividades ms frecuentes en un sistema orientado a objetos. En consecuencia, conviene contar con un principio general para asignar las responsabilidades concernientes a ella.

El Patrn Creador

Solucin: Asignarle a la clase B la responsabilidad de crear una instancia de la clase A en uno de los siguientes casos: B agrega los objetos de A. B contiene los objetos de A. B registra las instancias de los objetos de A. B tiene los datos de inicializacin que sern enviados a A cuando este objeto sea creado (B es un experto respecto a la creacin de A).

El Patrn Creador
Ejemplo: En la aplicacin quin debera encargarse de crear una instancia de items?

Desde el punto de vista del patrn Creador, deberamos buscar una clase que agregue, contenga, y realice otras operaciones sobre este tipo de instancias.

Beneficios: Se brinda apoyo a un bajo acoplamiento, lo cual supone menos dependencias respecto al mantenimiento y mejores oportunidades de reutilizacin.

El Patrn Creador
Un CarritoCompra contiene (agrega) muchos objetos Items. Es por esto que el patrn Creador sugiere que CarritoCompra es la clase idnea para asumir la responsabilidad de crear las instancias de Items.
CarritoCompra agregarItem() venta()

1: agregarItem()

2: crear()

1
tiene

: CarritoCompra

: Items
1..*

Items
cantidad crear() subtotal()

Seguimos con el ejemplo...

Cliente
nombre apellido direccion te profesion

1
usa

1
tiene

1
CarritoCompra agregarItem() venta() es de

0..* OrdenCompra
numero tarjeta direccionEntrega opcionEntrega

1 1

1
tiene 1..*

Items
cantidad crear() subtotal()

EjemplarLibro

0..*

pertenecen

numero precio

1
darPrecio() 1..* tiene

1 Libro
isbn titulo editorial soporte categoria

Autor
esta escrito por

1..*

1..*

nombre apellido

Bibliografa bsica
Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. 1 ed, USA: Addison-Wesley Pub Co; 1995. Larman C. UML y patrones. Una introduccin al Anlisis y Diseo Orientado a Objetos y al Proceso Unificado. 2 ed. Madrid: Prentice-Hall; 2003.

Algunos puntos a tener en cuenta....

El libro de Larman UML y patrones. Una introduccin al Anlisis y Diseo Orientado a Objetos y al Proceso Es altamente recomendable para ampliar el tema de patrones

El Proceso de Desarrollo de Software

Proceso de desarrollo

UML no es un proceso... ...UML es una notacin

Modelos Tradicionales

Ciclo de Vida en Cascada Ciclo de Vida de Prototipos Ciclo de Vida en Espiral

....

Proceso Unificado (PU)

Proceso de Desarrollo de Software Conjunto de actividades para transformar los requisitos del usuario en un sistema software Proceso Unificado Rational (RUP) Dirigido por Casos de Uso Centrado en la Arquitectura Iterativo e Incremental

Dirigido por Casos de Uso

Los casos de uso representan los requisitos funcionales Los casos de uso guan el diseo, la implementacin y la prueba Basndose en los casos de uso los desarrollares crean modelos de diseo e implementacin que llevan a cabo los casos de uso

Centrado en la Arquitectura
La arquitectura es una vista de diseo on las caractersticas ms importantes, dejando los detalles de lado Constituyen la forma del sistema, incluye aspectos estticos y dinmicos Describe diferentes vistas del sistema La arquitectura y los casos de uso evolucionan en paralelo

Iterativo e Incremental
Desarrollo iterativo: el desarrollo se organiza en una serie de mini proyectos de duracin fija, llamados iteraciones (2 a 6 semanas) El resultado de cada uno es un sistema que puede ser probado, integrado y ejecutado. Cada iteracin incluye sus propias actividades de: anlisis de requisitos, diseo, implementacin y prueba

Iterativo e Incremental
Desarrollo incremental: el sistema crece incrementalmente a lo largo del tiempo, iteracin tras iteracin. El resultado de cada iteracin es un sistema ejecutable, pero incompleto En general, cada iteracin aborda nuevos requisitos y amplia el sistema incrementalmente La salida de una iteracin NO es un prototipo desechable, es un subconjunto de calidad del sistema final

Fases del Desarrollo Unificado

Inicio: visin aproximada, anlisis del negocio, alcance, estimaciones imprecisas Elaboracin: visin refinada, implementacin iterativa del ncleo central de la arquitectura, resolucin de riesgos altos, identificacin de ms requisitos Construccin: implementacin iterativa del resto de requisitos de menor riesgo Transicin: pruebas beta

El Proceso Unificado Iterativo e incremental

Flujos de trabajo / Fases Gestacin Elaboracin

Fase de inicio

Construccin

Transicin

Requisitos Anlisis Diseo Implementac. Test Iter #1 Iter #2 ------------Iter #n-1 Iter #n

Fase de inicio
Actividades a realizar (una o algunas) Visin y anlisis del negocio Modelo de casos de uso Especificaciones complementarias Listas de riesgos Prototipos Plan de iteracin

Fase de inicio
No se entendio la fase de inicio si... La duracin es mayor a unas pocas semanas Se intenta definir la mayora de los requisitos Se espera que los planes y la estimacin es fiable Se define la arquitectura No se identifican la mayora de de los nombres de los casos de uso y los actores Se escribieron todos los casos de uso en detalle

El Proceso Unificado Iterativo e incremental

Flujos de trabajo / Fases Gestacin Elaboracin

Fase de elaboracin
Construccin Transicin

Requisitos Anlisis Diseo Implementac. Test Iter #1 Iter #2 ------------Iter #n-1 Iter #n

Fase de elaboracin
Actividades a realizar Se descubren y estabilizan la mayora de los casos de uso Se reducen o eliminan los riesgos importantes Se implementan y prueban los elementos bsicos de la arquitectura Duracin: 2 a 4 iteraciones con una duracin de 2 a 6 semanas (dependiendo de la duracin del proyecto)

Fase de elaboracin

El producto resultante no es un prototipo desechable El cdigo y el diseo son de calidad y se integran al sistema final

Fase de elaboracin

Artefactos de la fase de elaboracin Modelo del dominio (entidades del dominio) Modelo de diseo (diagramas de clases, de iteracin. etc) Modelo de datos Modelo de pruebas Modelos de implementacin

Fase de Elaboracin
No se entendio la fase de elaboracin si... Slo comprende una iteracin La mayora de los requisitos se definieron antes de la elaboracin NO hay programacin de codigo ejecutable Se intenta llevar a cabo un diseo completo antes de la codificacin Los usuarios no se involucran en la evaluacin

El Proceso Unificado Iterativo e incremental

Flujos de trabajo / Fases Gestacin Elaboracin

Fase de construccin

Construccin

Transicin

Requisitos Anlisis Diseo Implementac. Test Iter #1 Iter #2 ------------Iter #n-1 Iter #n

Fase de construccin
Objetivos Terminar de construir la aplicacin Realizar pruebas alfa Preparar pruebas beta (para la transicin) Preparacin de guas de usuario Preparacin de materiales de aprendizaje

El Proceso Unificado Iterativo e incremental

Flujos de trabajo / Fases Gestacin Elaboracin

Fase de transicin

Construccin

Transicin

Requisitos Anlisis Diseo Implementac. Test Iter #1 Iter #2 ------------Iter #n-1 Iter #n

Fase de Transicin
Objetivo: poner el sistema en produccin Actividades Realizacion de pruebas beta Reaccionar a la retroalimentacion a partir de las pruebas beta Conversion de datos Cursos de entrenamiento

Casos de uso y las fases

Casos de uso en la fase de inicio No se describen completamente en esta fase Casos de uso en la fase de elaboracin Se refinan en las sucesivas iteraciones

Casos de uso en la fase de construccin Se escriben casos de uso menores Casos de uso en la fase de transicin
En esta fase no se describen

Bibliografia bsica

Larman C. UML y patrones. Una introduccin al Anlisis y Diseo Orientado a Objetos y al Proceso Unificado. 2 ed. Madrid: Prentice-Hall; 2003. Jacobson I. Booch G. Rumbaugh J. El Proceso de Desarrollo Unificado. Addison-Wesley. 2000

Algunos puntos a tener en cuenta....

Comenzar con algunos casos de uso Crear un modelo del dominio (diagrama de clases) Armar diagramas de secuencia de sistema Asignar responsabilidades a las clases (patrones) Codificar Testear Iterar nuevamente....

Persistencia de los Objetos

Persistencia de los Objetos

Cmo mantengo la persistencia de los objetos...? ...Mediante una base de datos Cmo se puede hacer corresponder un modelo de objetos con un modelo de base de datos?

Modelo de clases vs Modelo de datos

Modelo de clases
Clases Asociaciones Clases Asociaciones Generalizaciones Atributos

Modelo de datos
Entidades Interrelaciones Atributos

Transformacin
Todas las clases se corresponden con tablas? ...y las asociaciones? ...y las clases asociaciones? ...y las generalizaciones? Adems ... Cules sern las entidades e interrelaciones ? Cules sern sus atributos? Cules sern los atributos identificadores?

Transformacin
Todas las clases se transforman en entidades Los atributos de la clase pasan a ser atributos de la entidad Se crean atributos identificadores para cada entidad Las clases asociacin se transforman en interrelaciones La multiplicidad es de M:N Los atributos de la clase asociacin pasan a ser atributos de la interrelacin

Transformacin
Las asociaciones se transforman en interrelaciones Se mantiene la misma multiplicidad de la asociacin en las interrelaciones Las relaciones de clasificacin Se transforman en relaciones de clases y subclases en el modelo entidad interrelacin, o Se pasan los atributos de la superclases a las subclases (desaparece la superclase)

superclase

ALUMNO * * * NOTA nota fecha

PROFESOR *

Transformacin del modelo de clases al modelo de datos

supeclase

1 CURSO

* MATERIA

cod_alum

ALUMNO

PROFESOR
N N nota

La transformacin al modelo relacional es la conocida...

cod_prof

NOTA
fecha M

CURSO
cod_cur

MATERIA

cod_mat

Seguimos con el ejemplo...

Cliente
nombre apellido direccion te profesion

cod_cli

cod_ord

1
usa

1
tiene

CLIENTE 1 1
0..* OrdenCompra
numero tarjeta direccionEntrega opcionEntrega

ORDENCOMPRA N 1

1
CarritoCompra

cod_carro 1 CARRITOCOMPRA 1 1

agregarItem() venta()

es de

1 1

1
tiene 1..*

Items
cantidad crear() subtotal()

EjemplarLibro

num_ejemp N N 1 EJEMPLARLIBRO N num_item

Autor
esta escrito por

0..*

pertenecen

numero precio

1
darPrecio() 1..* tiene

ITEMS

1 Libro
isbn titulo editorial soporte categoria

1..*

1..*

nombre apellido

cod_autor N AUTOR

cod_libro 1 N LIBRO

El modelo Relacional Asociado

Cliente(cod_cli, ...) OrdenCompra(cod_ord, ..., cod_cli(Cliente)) CarritoCompra(cod_carro, ..., cod_cli(Cliente), cod_ord(OrdenCompra)) Items(num_item, ..., cod_carro(CarritoCompra), num_ejem(EjemplarLibro)) EjemplarLibro(num_ejem, ..., cod_libro(Libro)) Libro(cod_libro, ...) Autor(cod_autor, ...) LibroAutor(cod_libro(Libro), cod_autor(Autor))

Bibliografa Bsica
Rumbaugh J, Blaha M, Premerlani W, Eddy F, Lorensen W.. Modelado y Diseo Orientado a Objetos. Espaa: Prentice-Hall; 1996 Mapping Objects to Tables. A Pattern Language. Wolfgang Keller

Cmo podemos hacer para especificar aquello que los modelos no pueden?

OCL
Object Constraint Language

Por qu utilizar OCL?

Un modelo grfico como UML no es suficente para una especificacin no ambigua Necesidad de establecer restricciones adicionales sobre el modelo Muchas veces las restricciones se escriben en lenguaje natural Qu problemas surgen con este tipo de especificaciones?

Por qu utilizar OCL?

Una solucin: LENGUAJES FORMALES Problemas: necesidad de usuarios con una fuerte formacin matemtica Una alternativa: OCL Lenguaje de caractersticas formales Fcil de leer Fcil de escribir

Qu no es OCL?

NO es un lenguaje de programacin NO es posible escribir lgica de programacin NO es posible invocar operaciones que no sean una consulta NO considera aspectos de implementacin

Dnde usar OCL?

Para especificar invariantes sobre clases en un modelo de clases. Para especificar pre y post-condiciones sobre Operaciones. Como lenguaje de navegacin. Para especificar restricciones sobre operaciones

Invariante
Una expresion OCL puede ser utilizada como un invariante que es una restriccin que, cuando est asociada a una clase, debe ser verdadera para todos las instancias de esa clase, en todo momento
Dentro de un diagrama
Alumno <<invariant>> edad > 0
nombre apellido direccion edad darNombre()

Fuera de un diagrama
Context Alumno inv: self.edad > 0

objeto contextual

tipo contextual

Propiedades
Atributos Nombres de rol Operaciones El valor de una propiedad para un objeto que est definido en un diagrama de clases se especifica con un punto seguido del nombre de la propiedad:
context Alumno inv: self.nombre

Atributos y Operaciones
Atributos El apellido de un alumno se escribe como: context Alumno inv: self.apellido Operaciones Para referirnos a una operacin, escribimos: context Alumno inv: self.darNombre()
Alumno
nombre apellido direccion edad darNombre()

Combinacin de Propiedades
Las propiedades se pueden combinar para obtener expresiones ms complicadas
si quisiramos decir que los casados son mayores de edad:

context Person inv: self.wife->notEmpty implies self.wife.age>=18 and self.husband->notEmpty implies self.husband.age>=18

Extremo de Asociacin y Navegacin

Comenzando desde un objeto en particular, podemos navegar una asociacin en un diagrama de clases para referirnos a otro objeto y a sus propiedades. El valor de esta expresin es el conjunto de objetos que estn del otro lado de la asociacin nombreDeRol Para hacerlo, navegamos la asociacin usando su extremo opuesto:
objecto.nombreDeRol

Si la multiplicidad del extremo es *, es un conjunto

Context Person inv: (un conjunto) self.employer ...

Si la multiplicidad del extremo es 0 1, es un objeto

Context Company inv: Self.manager... (Un objeto)

Colecciones
El tipo Collection define un gran nmero de operaciones predefinidas que permiten al modelador de expresiones OCL manipular colecciones Coleccin es un supertipo abstracto para todos los tipos de coleccin en OCL OCL distingue tres tipos diferentes de colecciones: Set, Sequence y Bag

Colecciones
Set es un conjunto matemtico. No contiene elementos duplicados. { 1, 6, 7, 3, 8} Bag es como un conjunto, que puede contener duplicados. { 1, 6, 7, 3, 8, 3, 6} Sequence es como un Bag en el que los elementos estn ordenados { 1, 3, 3, 6 , 6, 7, 8}

Colecciones
Las Colecciones son tipos predefinidos en OCL. Tienen un gran nmero de operaciones predefinidas. Una propiedad de la coleccin en s es accedida utilizando la flecha -> seguida del nombre de la propiedad.
collection->select( ...

Operacin Select

Especifica un subconjunto de una coleccin. El parmetro de la select debe ser una expresin booleana.
collection->select( boolean-expression ) context Company inv: self.employee -> select (age > 50)

Operacin forAll

La operacin forAll en OCL permite especificar expresiones Booleanas, que deben cumplirse para todos los elementos de la coleccin:
collection->forAll( boolean-expression ) context Company inv: self.employee -> forAll(age <= 65 )

Operacin Exists
Muchas veces uno necesita saber si en una coleccin hay, al menos, un elemento que cumple cierta condicin.
Collection -> exists( boolean-expression ) context Company inv: self.employee -> exists(name = 'Jack' )

Operaciones sobre Colecciones

collection->size : Integer The number of elements in the collection collection v. gr.: a company has at most 50 employees context Company inv: self.employee -> size <= 50 Collection -> count(object : OclAny) : Integer The number of times that object occurs in the collection collection v. gr.: set -> count(object : T) : Integer The number of occurrences of object in set post: result <= 1

Operaciones sobre colecciones

collection -> isEmpty() : Boolean Is collection the empty collection? collection -> notEmpty() : Boolean Is collection not the empty collection? context Company inv: self.wife -> notEmpty implies self.wife.sex = female

Ejercicios
La compaa debe tener menos de 50 empleados y ms de 5
gerente 1
compaiaGerenciada

Persona
esCasado : Boolean esDesocupado : Boolean edad : Integer esFeliz : Boolean

0..* Compaia

empleado

0..* empleador 0..*

nombre : String cantidadDeEmpleados : Integer

La compaa debe tener menos de 50 empleados y ms de 5 Context Compaa inv: Self.cantidadDeEmpleados < 50 and Self.cantidadDeEmpleados > 5

Ejercicios
La compaa debe tener empleados mayores de 18 aos

Persona
esCasado : Boolean esDesocupado : Boolean edad : Integer esFeliz : Boolean

gerente 1
compaiaGerenciada

0..* Compaia

empleado

0..* empleador 0..*

nombre : String cantidadDeEmpleados : Integer

La compaa debe tener empleados mayores de 18 aos Context Compaa inv: Self.empleado-> forAll(edad > 18)

Ejercicios
La compaa debe tener alguna persona soltera

Persona
esCasado : Boolean esDesocupado : Boolean edad : Integer esFeliz : Boolean

gerente 1
compaiaGerenciada

0..* Compaia

empleado

0..* empleador 0..*

nombre : String cantidadDeEmpleados : Integer

La compaa debe tener alguna persona soltera Context Compaa inv: Self.empleado -> select( not esCasado)-> notEmpty()

Ejercicios
La compaa debe tener empleados mayores a 50 aos y casados
gerente 1
compaiaGerenciada

Persona
esCasado : Boolean esDesocupado : Boolean edad : Integer esFeliz : Boolean

0..* Compaia

empleado

0..* empleador 0..*

nombre : String cantidadDeEmpleados : Integer

La compaa debe tener empleados mayores a 50 aos y casados Context Compaa inv: Self.empleado->select(esCasado and edad > notEmpty()

50)->

Bibliografa bsica
http://www.omg.org/technology/uml/index.htm

Algunos puntos a tener en cuenta....

Un sistema de informacin se disea en funcion de varias capas Interfaz (no la vimos) Capa logica de la aplicacin y objetos del dominio Capa de servicios (persistencia)

Fin