UML-RUP un caso prcticoMg. Carlos Gerardo NeilFacultad de Tecnologa Informtica UAInoviembre 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
ObjetosUn 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 ObjetosEl 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
ClasesUn 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 ClasesSe 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
PolimorfismoPermite la posibilidad de desencadenar operaciones diferentes en respuesta a un mismo mensajeFigura 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 ObjetosEl 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 OODisminucin 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
UMLQu 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 sistemaLa 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 UMLUse 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
Cliente
Verificar Operacin
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 Estadosalta 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 ActividadBuscar 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 ComponentesInterfaz de Terminal Control y Anlisis
Gestin de Cuentas
Rutinas de conexin
Acceso a BD
Muestra las dependencias lgicas entre componentes software
Diagrama de DespliegueServidor 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 MetamodeloClase *enlaza enlaza instancia de
Objeto *
Relacion *
instancia de
Enlace *
Diagrama de Clases
Diagrama de Objetos
Los modelos ms utilizados...
Casos de Uso
Casos de UsoEspecifica 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
caso de uso 2
caso de uso 1
caso de uso 4
actor 1
caso de uso 3
Actores y EscenariosUn 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 sistemaexterno 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> TARJETA DE CREDITO
0..1 0..*
secundario
Cliente CVLIsecundario 0..1> GESTOR DE LIBROS
0..1 secundario> GESTOR DE ENVIO
Administrador Sistema
0..1
Casos de UsoDescribe 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 UsoRelaciones 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
Caso de Uso B
Caso de Uso A
un ejemplo...
Consultar libros en general
Consultar novedades
Consultar ofertas
Consultar libro Cliente
Casos de UsoRelaciones include Es comn que la misma funcionalidad del sistema sea accedida a partir de varios casos de uso
Caso de Uso A
Caso de Uso B
un ejemplo...
Consultar libros en general
Consultar novedades
Consultar ofertas
Consultar libro
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 ContextoPermite determinar las fronteras del sistema>
0..1 0..*
TARJETA DE CREDITO
secundario
Cliente CVLIsecundario 0..1> GESTOR DE LIBROS
0..1 secundario> 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 UsoCliente 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
Consultar ofertas
Gestor de Libros
Consultar libro Cliente
Tarjeta de Credito
Comprar libro
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 principal1. 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 alternativoA1 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 = 0Nombre 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
AsociacionesSon 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 Enlaceasociacinempleado empleadotrabaja para
empleador 1
empresa
1..*
(emp1, em)
enlaceem : empresa
emp1 : empleado
emp2 : empleado
(emp3, em)emp3 : empleado
(emp2, em)
Banco
Nombre de rol0..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 binariagerente 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 AsociacinUna asociacin puede representarse por medio de una clase para aadir, por ejemplo, atributos y operacionesempresa empleador 1..* 1..* empleado empleado
cargo nombre sueldo
Asociacin n-aria
Generalizacinrelacin es-un-tipo-desuperclase 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 clasesLa 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 clasesClientenombre apellido direccion te profesion
1usa
1tiene
1CarritoCompra es de
0..* OrdenCompra 1numero tarjeta direccionEntrega opcionEntrega
1tiene 1..*
1
Itemscantidad
EjemplarLibro
0..*
pertenecen
1
numero precio1..*
tiene
1 Libroisbn titulo editorial soporte categoria
Autoresta 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 Clientenombre apellido direccion te ingresarDatos() tiene
1
0..* 1 1
OrdenCompranumero IngresarPreferencias()
1usa es de
1
1
1CarritoCompra
1agregarItem() venta()
1 Tarjetanombre numero
1DireccionCompra
1OpcionEntrega
calle numero
tipo
1tiene 1..* Categoria
tipoEjemplarLibro
Itemscantidad crear() subtotal()
0..* pertenecen 1
numero darPrecio()
1 1..*tiene pertenece 1..*
1 Autornombre apellido
Libroisbn titulo editorial ConsultarLibro()
1..*
escrito por
1..*
Diagrama de Secuencia
Diagrama de SecuenciaMuestra 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 SecuenciaLos 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 SistemaMuestra, 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 ejemploDebera 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...)SISTEMAingresarSistema() 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 ColaboracinMuestra 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 bsicaMartin 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 DiseoDisear 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 DiseoEl 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 Diseoelementos 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 AdaptadorConvierte 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 AdaptadorDiagrama general del patrn
Ejemplo: editor de grficosFigura Editor dibujar() mover() Rectangulo dibujar() mover()
3DFigura3Ddibujar() 3Dmover()
3DAdaptador dibujar() mover()
Circulo dibujar() mover()
Triangulo dibujar() mover()
Esfera3Ddibujar() 3Dmover()
Paralelepipedo 3Ddibujar() 3Dmover()
Piramide3Ddibujar() 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 clasesDespues 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
ResponsabilidadesLas responsabilidades se relacionan con las obligaciones de un objeto respecto de su comportamiento. Estas responsabilidades pertenecen, esencialmente, a dos categoras: conocer y hacer.
ResponsabilidadesEntre 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.
ResponsabilidadesEntre 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...Clientenombre apellido direccion te profesion
1usa
1tiene
1CarritoCompra es de
0..* OrdenCompranumero tarjeta direccionEntrega opcionEntrega
1 1tiene 1..*
1
Itemscantidad
EjemplarLibro
0..*
pertenecen
1
numero precio1..*
tiene
1 Libroisbn titulo editorial soporte categoria
Autoresta 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 ExpertoEjemplo: 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 ExpertoQu 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() 1tiene 1..*
Itemscantidad 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 CreadorNombre: 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 CreadorEjemplo: 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 CreadorUn 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()
1tiene
: CarritoCompra
: Items1..*
Itemscantidad crear() subtotal()
Seguimos con el ejemplo...Clientenombre apellido direccion te profesion
1usa
1tiene
1CarritoCompra agregarItem() venta() es de
0..* OrdenCompranumero tarjeta direccionEntrega opcionEntrega
1 1
1tiene 1..*
Itemscantidad crear() subtotal()
EjemplarLibro
0..*
pertenecen
numero precio
1darPrecio() 1..* tiene
1 Libroisbn titulo editorial soporte categoria
Autoresta escrito por
1..*
1..*
nombre apellido
Bibliografa bsicaGamma, 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 incrementalFlujos 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 incrementalFlujos de trabajo / Fases Gestacin Elaboracin
Fase de elaboracinConstruccin 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 incrementalFlujos 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 incrementalFlujos 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 TransicinObjetivo: 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
TransformacinTodas 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 datossupeclase
1 CURSO
* MATERIA
cod_alum
ALUMNO
PROFESORN N nota
La transformacin al modelo relacional es la conocida...
cod_prof
N
NOTAfecha M
1
M
CURSOcod_cur
MATERIA
cod_mat
Seguimos con el ejemplo...Clientenombre apellido direccion te profesion
cod_cli
cod_ord
1usa
1tiene
CLIENTE 1 10..* OrdenCompranumero tarjeta direccionEntrega opcionEntrega
ORDENCOMPRA N 1
1CarritoCompra
cod_carro 1 CARRITOCOMPRA 1 1
agregarItem() venta()
es de
1 1
1tiene 1..*
Itemscantidad crear() subtotal()
EjemplarLibro
num_ejemp N N 1 EJEMPLARLIBRO N num_itemAutoresta escrito por
0..*
pertenecen
numero precio
1darPrecio() 1..* tiene
ITEMS
1 Libroisbn 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?
OCLObject 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 momentoDentro de un diagramaAlumno edad > 0nombre apellido direccion edad darNombre()
Fuera de un diagramaContext 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 OperacionesAtributos 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()Alumnonombre apellido direccion edad darNombre()
Combinacin de PropiedadesLas propiedades se pueden combinar para obtener expresiones ms complicadassi 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 NavegacinComenzando 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 conjuntoContext Person inv: (un conjunto) self.employer ...
Si la multiplicidad del extremo es 0 1, es un objetoContext 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 exists( boolean-expression ) context Company inv: self.employee -> exists(name = 'Jack' )
Operaciones sobre Coleccionescollection->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 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 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
EjerciciosLa compaa debe tener menos de 50 empleados y ms de 5gerente 1compaiaGerenciada
PersonaesCasado : 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
EjerciciosLa compaa debe tener empleados mayores de 18 aos
PersonaesCasado : Boolean esDesocupado : Boolean edad : Integer esFeliz : Boolean
gerente 1compaiaGerenciada
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)
EjerciciosLa compaa debe tener alguna persona soltera
PersonaesCasado : Boolean esDesocupado : Boolean edad : Integer esFeliz : Boolean
gerente 1compaiaGerenciada
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()
EjerciciosLa compaa debe tener empleados mayores a 50 aos y casadosgerente 1compaiaGerenciada
PersonaesCasado : 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 bsicahttp://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
Top Related