66827593 Analisis de Sistemas Administrativos Uml Ocl Rup
-
Upload
elvis-henry-guzman-aquije -
Category
Documents
-
view
48 -
download
2
Transcript of 66827593 Analisis de Sistemas Administrativos Uml Ocl Rup
UML-RUPun caso práctico
Mg. Carlos Gerardo NeilFacultad de Tecnología Informática UAI
noviembre de 2004
Índice
• Introducción al Modelo Orientado a Objetos• Lenguaje de Modelado Unificado -UML-• Lenguaje de Restricción de Objetos -OCL-• Patrones de diseño OO• Proceso de desarrollo • Persistencia de datos• Un caso práctico
Introducción
Algunas Consideraciones Generales
Análisis, Diseño, Implantación
• El análisis OO pone énfasis en la investigacíón del problema y los requisitos, en vez de ponerlo en la solución
• El diseño pone énfasis en una solución conceptual, que satisface los requisitos, en vez de ponerlo en la implantación
• La implantación es la traducción de la solución a un lenguaje de programación 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 análisis estructurado donde los datos y el comportamiento están débilmente relacionados
Tenemos que olvidarnos del modelo estructurado...
¿Porqué la orientación a objetos?
• Estabilidad de modelalo respecto a las entidades del mundo real
• Simplicidad del modelo (objetos, mensajes, clases, herencia y polimorfismo) para analisis, diseño e implementación
• Posibilidad de reutilizar elementos
Propiedades de los Objetos
“El estado de un objeto abarca todas las propiedades (normalmente estáticas) del mismo,
más los valores actuales (normalmente dinámicos) de cada una de esas propiedades”
“El comportamiento es como actúa y reacciona un objeto, en términos de sus cambios de estado y
paso de mensajes”
“La identidad es aquella propiedad de un objeto que lo distingue de todos los demás 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 asociación 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 asociación entre sus clases
• La asociación representa un acoplamniento débil, la Agregación y la Composición expresa un acoplamiento más fuerte en clases
Jerarquía entre clases
• La generalización consiste en factorizar los elementos comunes de un conjunto de clases en una clase más general llamada superclase
• La herencia es una técnica de los lenguajes de programación 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 mensaje
La interacciones entre objetos se escriben según los términos de las especificaciones definidas en las
superclases
Circulo
dibujar()mover()
Rectangulo
dibujar()mover()
Triangulo
dibujar()mover()
Figura
dibujar()mover()
Editor
Análisis Estructurado vs. Análisis Orientado a Objetos
El enfoque tradicional del análisis y diseño 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 más
pequeñas denominadas objetos,
Beneficios del Enfoque OO
Disminución del bache semántico entre análisis y diseño proveyendo una representación consistente en todo el
ciclo de vida
Enfoque OOLa transición del análisis al diseño es un refinamiento
Enfoque EstructuradoEn la transición del análisis al diseño
pasamos del DFD al DE mediante un proceso heurístico no trivial
Bibliografía Básica (clásica)
Booch G. Análisis y Diseño Orientado a Objetos, con Aplicaciones. 2ª ed. USA: Addison-Wesley; 1996
Jacobson I, Christerson M, Jonsson P, Övergaard G. Object-Oriented 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 Diseño Orientado a Objetos. España: Prentice-Hall; 1996
UML
¿Qué son los modelos?¿Para qué sirven los modelos?
¿Cuáles son los modelos de UML?¿Se usan todos...?
¿Qué son los modelos?
Un modelo es una representación que capta los aspectos más 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 semántica y notación.
Incluye gráficos y texto
¿Para qué sirven los modelos?
• Para pensar el diseño de un sistemaLa simplicidad de crear y de modificar modelos
permite un pensamiento creativo e innovación a bajo precio
• Para explorar económicamente múltiples 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 CaseDiagramsUse Case
DiagramsDiagramas de Casos de Uso
ScenarioDiagramsScenario
DiagramsDiagramas deColaboración
StateDiagramsState
DiagramsDiagramas deComponentes
ComponentDiagramsComponent
DiagramsDiagramas deDistribución
StateDiagramsState
DiagramsDiagramas de Objetos
ScenarioDiagramsScenario
DiagramsDiagramas deEstados
Use CaseDiagramsUse Case
DiagramsDiagramas deSecuencia
StateDiagramsState
DiagramsDiagramas deClases
Diagramas deActividad
Modelo
Diagrama de Casos de Uso
Verificar Operación
Reintegro Cuenta Corriente
Cliente
Reintegro Cuenta de Crédito
<<include>>
<<include>>
Muestra las distintas operaciones que se esperan de un sistema y cómo se relacionan con su entorno
Diagramas de Secuencia
: Encargado:WInPréstamos :Socio :Video :Préstamo
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo
Muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo
Diagrama de Colaboración
: Encargado
:WInPréstamos
:Socio
:Video
:Préstamo
1: prestar(video, socio)
2: verificar situación socio
3: verificar situación video
4: registrar préstamo5: entregar recibo
Muestra la forma de representar interacciones entre objetos,
Diagrama de Estados
con préstamos
sin préstamos
alta baja
prestar devolver[ número_préstamos = 1 ]
prestar
devolver[ número_préstamos > 1 ]
número_préstamos = 0
número_préstamos > 0
Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con los cambios que permiten pasar de un
estado a otro
Diagrama de Actividad
B u s c a r B e b i d a [ no hay ca fé ]
P o n e r c a f é en filtro
A ñ a d i r a g u a al depósito
C o g e r t a z a
Poner f i l t ro e n m á q u i n a
E n c e n d e r m á q u i n a
C a f é e n p r e p a r a c i ó n
/ c a f e t e r a . O n
Serv i r café B e b e r
C o g e r z u m o
[ hay ca fé ]
ind icador de f in
[ h a y z u m o ]
[ n o z u m o ]
Muestran transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos.
Diagrama de Componentes
Interfaz de Terminal
Gestión de Cuentas Rutinas de conexión Acceso a BD
Control y Análisis
Muestra las dependencias lógicas entre componentes software
Diagrama de Despliegue
Punto de Venta
Servidor Central
Terminal de Consulta
Gestión de Cuentas
Comment
Interfaz de TerminalRutinas de Coneccion
Comment
Rutinas de Coneccion
Comment
Interfaz de Terminal
Comment
Rutinas de Coneccion
Comment
Acceso a BD
Comment
Control y Análisis
Comment
Muestran la organización de los componentes del sistema
Modelo y Metamodelo
• Para la definición y formalización de UML, los diferentes conceptos se han modelado, a su vez, con UML.
• Esta definición recursiva de denomina Metamodelo
• El metamodelo describe de manera formal los elementos de modelado, la sintaxis y la semántica asociados a ellos
Extracto del Metamodelo
Relacion
Diagrama de Clases
*
Clase
*
Enlace
Diagrama de Objetos
*
Objeto
** *
* *
instancia de
instancia de
enlaza enlaza
Los modelos más utilizados...
Casos de Uso
Casos de Uso
Especifica el comportamiento de un sistema o una parte del mismo
Es una descripción de un conjunto de secuencias de acciones, donde cada secuencia representa la
interacción 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
actor 1
caso de uso 2
caso de uso 1
<<extend>>
caso de uso 3
caso de uso 4
<<include>>
Actores y EscenariosUn actor representa un conjunto coherente de roles
que juegan los usuarios de los casos de uso cuando interactúan con éstos
Un escenario es una secuencia específica de acciones entre los actores y el sistema
actor
persona sistemamaquinas
externo alsistema
Interactua con el sistema
Tipo de Actores
• Actores primarios: utilizan las funciones principales del sistema
• Actores secundarios: efectúan tareas administrativas o de
mantenimiento
CVLI
Cliente
Administrador Sistema
<< actor>>
TARJETA DECREDITO
<< actor>>
GESTORDE ENVIO
<< actor>>
GESTORDE LIBROS
0..*
0..1
0..1
0..1
0..1
secundario
secundario
secundario
Casos de Uso
Describe tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él
Están 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 sólo en algunas
oportunidades
La excepción consiste en interrumpir el caso de uso B y pasar a ejecutar otro caso de uso A
Caso de Uso ACaso de Uso B
<<extend>>
un ejemplo...
Consultar libros en general
Consultar novedades Consultar ofertas
Cliente
Consultar libro
<<extend>><<extend>>
<<extend>>
Casos de Uso
Relaciones include
Es común que la misma funcionalidad del sistema sea accedida a partir de varios casos de uso
Caso de Uso A Caso de Uso B
<<include>>
un ejemplo...
Consultar libros en general
Consultar novedades Consultar ofertas
comprar libro
Cliente
buscar libros
Consultar libro
<<extend>>
<<extend>><<extend>>
<<include>><<include>>
Comenzamos con el caso práctico...
Compañía de Ventas de Libros por Internet (CVLI)
• El cliente accede a la información sobre los libros a través de la Web
• El cliente elegirá un nombre de usuario y una clave como método de autentificación para efectuar las transacciones
• El cliente podrá realizar búsquedas por autor, título o ISBN• El cliente debe estar previamente registrado• El cliente puede establecer preferencias de envío• El cliente puede introducir opciones de empaquetado• La librería deberá recoger los datos de los pedidos• La librería deberá rearmar en uno único los pedidos
aislados que estén dentro del plazo de 90 minutos• La empresa puede realizar envíos parciales en función de
la disponibilidad de los ítems
Identificación de los actores
• Cliente (primario)• Administrador del sistema (primario)• Tarjeta de crédito (secundario)• Gestor de libros (secundario)• Gestor de envio (secundario)
Diagrama de Contexto
Permite determinar las fronteras del sistema
CVLI
Cliente
Administrador Sistema
<< actor>>
TARJETA DECREDITO
<< actor>>
GESTORDE ENVIO
<< actor>>
GESTORDE LIBROS
0..*
0..1
0..1
0..1
0..1
secundario
secundario
secundario
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
Identificación de los Casos de Uso
ClienteRegistrarse al sistemaConsultar libroComprar libroEstablecer preferencias de envío y empaquetado
Administrador del sistemaArmar pedidosRearmar pedidos
Diagrama de Casos de Uso
Armar pedidos
Rearmar pedidos Administrador del SistemaEstablecer preferencias
de envío y empaquetado
Consultar libro
Cliente
Gestor de Libros
Comprar libro
Registrarse al sistema
Tarjeta de Credito
Descripción de los Casos de Uso
Titulo: Registrarse al sistemaResumen: el cliente, antes de realizar una primera
transacción de compra o búsqueda de libros, debe introducir todos sus datos por única vez, los cuales serán guardados por el sistema y éste le ofrecerá la posibilidad de tener una clave y contraseña que utilizará para cada transacción que realice posteriormente, el cliente tendrá la posibilidad de hacer cambios en los datos introducidos, incluso en su clave y contraseña
Actores: cliente (primario), tarjeta de crédito (secundario)
Descripción de los Casos de Uso
Titulo: Consultar libro Resumen: el cliente, una vez ingresado al sistema, podrá
navegar por el mismo en búsqueda de libros, novedades, ofertas, etc.
Actores: cliente (primario), gestor de libros (secundario)
Descripción de los Casos de Uso
Titulo: Comprar libroResumen: el cliente, una vez ingresado al sistema, podrá
realizar compras de libros, eligiéndolo de una lista ofrecida por la empresa, cada libro elegido, se sumará a una carrito de compra, etc. El cliente informará el número y tipo de tarjeta de crédito para realizar el pago. Deberá especificar dirección de envió y forma de pago
Actores: cliente (primario), gestor de libros (secundario), tarjeta de crédito (secundario)
Refinamiento: include y extend
Establecer preferencias de envío y empaquetado
Consultar libros en general
Consultar novedades Consultar ofertas
Cliente
Gestor de Libros
Tarjeta de Credito
Consultar libro
<<extend>><<extend>>
<<extend>>
Comprar libro
<<include>>
<<extend>>
Desarrollo de un Caso de Uso
Titulo: Registrarse al sistemaActores: cliente (primario), tarjeta de crédito (secundario)Fecha de creación: Fecha de actualización:Versión
Precondición: el cliente ingresa al sistema por primera vez
Escenario principal
1. El cliente ingresa a la pagina web de CVLI2. El cliente ingresa a la opción “registración “3. El sistema solicita ingreso de los datos personales: nombre y apellidos,
dirección, localidad, código postal, país4. El cliente ingresa los datos personales5. El sistema evalúa el país de origen y solicita ingreso de los datos de la tarjeta
de crédito: tipo de tarjeta, número, fecha límite de validez6. El cliente ingresa datos de la tarjeta de crédito7. El sistema chequea el número de la tarjeta de crédito8. El sistema (teniendo en cuenta el país de origen) solicita la opción de
preferencia de envío por omisión, esta opción puede modificarse en cada envío9. El cliente ingresa preferencia de envío10. El sistema solicita, para finalizar, el ingreso de la clave de acceso y la
contraseña11. El cliente ingresa clave y contraseña12. El sistema solicita reingreso de contraseña13. El cliente reingresa contraseña14. El sistema informa que la transacción se realizo correctamente
Flujo alternativo
A1 Ingreso incorrecto de los números de los datosLa 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 números nuevamente
El escenario vuelve al punto 5
A2 Ingreso incorrecto de los números de la tarjeta de créditoLa secuencia comienza en el punto 7 del escenario principal
7. El sistema informa que los números ingresados son incorrectos8. El sistema evalúa si la cantidad de veces que ingreso el numero de tarjeta en forma incorrecta es menor a 39. El sistema pide ingreso de números nuevamente
El escenario vuelve al punto 8
Poscondición: el cliente está registrado en el sistema
Algunos puntos a tener en cuenta....
• Los casos de uso son texto, no gráfico• Comenzar identificando y nombrando los casos de
uso más importantes• Comenzar por una descripción no necesariamente
completa ni exacta y despues refinarla• En cada iteración del proceso de desarrollo se
amplia la funcionalidad del caso de uso
Diagrama de clases
Diagrama de Clases
Las clases representan los bloques de construcción más importantes de cualquier sistema orientado a
objetos.
Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semántica.
Diagramas de clases UML
(-) visibilidad privada(#) visibilidad protegida(+) visibilidad pública
atributoVisibilidad nombre : tipo = valor inicial
ejemplo - temperatura : numérico = 0
operaciónVisibilidad nombre (lista parámetros ) : tipo de expr retornada
ejemplo +BuscarValor (n:int) : int
Nombre de Clase
atributo 1atributo 2atributo n
operacion 1()operacion 2()operacion n()
AsociacionesSon relaciones entre clases que indica alguna conexión significativa que deseamos preservar
Tipo de asociaciones:Unarias, Binarias, n-ariasClases asociación
Cada instancia de una asociación (enlace) es una tupla de referencias a objetos
Asociación y Enlace
empleado empresa
11..*trabaja para
empleadorempleado
1..* 1
emp1 : empleado
emp2 : empleado
em : empresa
emp3 : empleado
asociación
enlace
(emp3, em)
(emp1, em)
(emp2, em)
Trabajo cargo : Literal fechaDeInicio : Fecha salario : Entero Matrimonio
lugar : Literal fecha : Fecha
cliente 0..*
Banco
gerente
compañíasGerenciadas
0..* Compañía nombre : Literal cantidadDeEmpleados : Entero
valorAcción() empleado empleador
0..* 0..*
Persona esCasado : Booleano esDesocupado : Booleano fechaDeNacimiento : Fecha edad : Entero nombre : Literal apellido : Literal sexo : enum{ masculino, femenino }
ingresos(Fecha) : Entero
0..1
0..*
0..* 0..*
0..1
0..1
esposa
esposo
0..1
0..1
Clase asociación
Nombre de rol
Multiplicidad
Asociación binaria
Asociación unaria
Agregación y Composición
Agregación
• Una clase forma parte de otra clase
• Es un tipo de asociación más fuerte
• Relación no simétrica entre clases donde uno de los extremos cumple un rol dominante
Composición
• 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 Asociación
Una asociación puede representarse por medio de una clase para añadir, por ejemplo, atributos y
operaciones
empresa empleado1..*
1..*
cargo
nombresueldo
empleador
empleado1..*
1..*
Asociación n-aria
Generalización
Herencia es el mecanismo mediante el cual los elementos más específicos incorporan la estructura y el comportamiento de
elementos mas generales
relación “es-un-tipo-de”
Rectangulo
dibujar()mover()
Circulo
dibujar()mover()
Triangulo
dibujar()mover()
Figura
color
dibujar()mover()
superclase
subclases
Lista de categorías de clases
La identificacion de clases del dominio del problema tiene “mucho de arte”
• Objetos tangibles o físicos (personas)• Lugares (escuela)• Roles de la gente (gerente)• Contenedores (tienda)• Cosas de un contenedor (artículos)• 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 más importantes– No preocuparse inicialmente por las
operaciones – No pensar en jerarquías (al principio...)
Seguimos con el caso practico...
Diagrama de clases
tiene
OrdenCompranumerotarjetadireccionEntregaopcionEntrega
Clientenombreapellidodireccionteprofesion
0..*
1
0..*
1
tiene
Autornombreapellido
Libroisbntituloeditorialsoportecategoria
1..*1..* 1..*1..*
esta escrito por
CarritoCompra
1
1
1
1es de
1
1
1
1
usa
EjemplarLibro
numeroprecio
1..*
1
1..*
1
tiene
Itemscantidad
1..*
1
1..*
1
1
0..*
1
0..* pertenecen
Refinamiento del Diagrama de Clases
Incluimos:Relaciones de jerarquíaPatrones de diseño (opcional)Agregaciones y composicionesRestricciones OCL (opcional)Algunas operaciones evidentes
Seguimos con el ejemplo...
Autor
nombreapellido
ClienteOcacional ClienteEspecializado
profesion
DireccionCompra
callenumero
OpcionEntrega
tipoTarjetanombrenumero
OrdenCompranumero
IngresarPreferencias()
1
1
1
1
1
1
1
1
1
1
1
1
Cliente
nombreapellidodireccionte
ingresarDatos()
0..*1 0..*1 tiene
CarritoCompra
agregarItem()venta()
1
1
1
1
es de
1
1
1
1
usa
Itemscantidad
crear()subtotal()
1..*
1
1..*
1
tiene
EjemplarLibro
numero
darPrecio()1
0..*
1
0..* pertenecen
Categoria
tipo
Libroisbntituloeditorial
ConsultarLibro()
1..* 1..*1..* 1..*escrito por
1..*
1
1..*
1
tiene
1
1..*
1
1..*
pertenece
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
Los diagramas de secuencia se utilizan en la etapa de análisis para documentar casos de uso
En la etapa de diseño se utilizan conjuntamente con los diagramas de colaboración para designar las
responsabilidades de las clases
Diagrama de Secuencia
Diagrama de Secuencia del Sistema
Muestra, para un escenario específico de un caso de uso, los eventos que generan los actores externos
Los sistemas se tratan como cajas negras
Muestran los mensajes que podrían ser traducidos a operaciones dentro del sistema
(y serán distribuidos, en la etapa de diseño, a los objetos del sistema)
Seguimos con el ejemplo...
: SISTEMA
: cliente ingresarSistema()
ingresarDatosPersonales()
ingresarTarjetaCredito()
ingresarPreferenciasEnvio()
ingresarClaveContraseña()
DSS "Registrarse al sistema"
Seguimos con el ejemploDebería quedar claro que el sistema (si estuviera compuesto
por una sóla clase) podría tener, por ahora, las siguientes operaciones ...
Esto nos brinda una primera aproximación de las posibles operaciones, no implica necasariamente que serán ellas las operaciones del sistema (estamos en una epata inicial...)
SISTEMA
ingresarSistema()ingresarDatosPersonales()ingresarTarjetaCredito()ingresarPreferenciasEnvio()ingresarClaveContraseña()
Algunos puntos a tener en cuenta....
• El diagrama de secuencia (DSS) lo utilizamos en la etapa de análisis, conjuntamente con los casos de uso para la identificación de los mensajes
• Los mensajes al sistema serán respondidos por él mediante operaciones que serán distribuidas a los diferentes objetos en la etapa de diseño
Diagramas de Colaboración
Diagramas de Colaboración
Muestra las interacciones organizadas en torno a los objetos y los enlaces entre ellos
Lo utilizamos en la fase de diseño para asignar responsabilidades a las clases (definir dónde ubicar las
operaciones)
Representación de los Mensajes
Representación de los Mensajes
Ejemplo de Diagrama de Colaboración
Algunos puntos a tener en cuenta....
• Los diagramas de colaboración lo utilizamos en la etapa de diseño, conjuntamente con los patronespara asignación de responsabilidades, para la distribución de operaciones en las clases en la etapa de diseño
Bibliografía básica
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, Addison-Wesley, 1999.
James Rumbaugh, Ivar Jacobson and Grady Booch: The Unified Modeling Language Reference Manual,Addison-Wesley, 1999.
http://www.uml.org/
Patrones de Diseño
Otra forma de reutilización...
Patrones de Diseño
Diseñar software orientado a objetos es difícil, más aún diseñar software orientado a objetos
reutilizables.
Se deben encontrar objetos apropiados, definir jerarquías de herencia y de interfaces y establecer
relaciones entre ellas.
El diseño debe satisfacer las necesidades actuales del usuario además de contemplar futuros
problemas o requerimientos.
Patrones de Diseño
El término patrón 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 diseño.
“Design Patterns: Elements of Reusable Object-Oriented Software” Gamma
Patrones de Diseño
Los patrones de diseño permiten la reutilización exitosa de diseños y arquitecturas más
rápidamente, además de ayudar a elegir alternativas de diseño que hace a los sistemas
reutilizables.
Aprovechar las experiencia de los desarrolladores
Patrones de Diseñoelementos esenciales
El nombre del patrón: se usa para describir un problema de diseño, su solución y las consecuencias, en una o dos palabras.
El problema: describe cuándo aplicar el patrón, explica el problema y su contexto
La solución: describe los elementos que hacen al diseño, sus relaciones, responsabilidades y colaboraciones
Las consecuencias: establecen los costos y beneficios de aplicar el patrón
Ejemplo: Patrón 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: Patrón Adaptador
Diagrama general del patrón
Ejemplo: editor de gráficos
Circulo
dibujar()mover()
Rectangulo
dibujar()mover()
Triangulo
dibujar()mover()
EditorFigura
dibujar()mover()
Esfera
3Ddibujar()3Dmover()
Paralelepipedo
3Ddibujar()3Dmover()
Piramide
3Ddibujar()3Dmover()
3DAdaptador
dibujar()mover()
3DFigura
3Ddibujar()3Dmover()
La interacciones entre objetos se escriben según los términos de las especificaciones definidas en las superclases
Asignación deResponsabilidades a las
Clases
Asignación de responsabilidades a las clases
“Despues de la identificación de los requisitos de los usuarios y de la creación del modelo del dominio,
añada operaciones en las clases de software y defina el paso de mensajes entre los objetos para satisfacer los
requisitos”
Decisiones poco acertadas sobre la asignación de responsabilidades de cada clase, dan origen a sistemas
y componentes frágiles y difíciles 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 categorías: conocer y hacer.
Responsabilidades
Entre las responsabilidades de un objeto relacionadas con el hacer se encuentran:
• Hacer algo uno mismo.
• Iniciar una acción 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...
tiene
OrdenCompra
numerotarjetadireccionEntregaopcionEntrega
Clientenombreapellidodireccionteprofesion
0..*
1
0..*
1
tiene
Autor
nombreapellido
Libro
isbntituloeditorialsoportecategoria
1..*1..* 1..*1..*
esta escrito por
CarritoCompra
1
1
1
1es de
1
1
1
1
usa
EjemplarLibro
numeroprecio
1..*
1
1..*
1
tiene
Itemscantidad
1..*
1
1..*
1
1
0..*
1
0..* pertenecen
El Patrón Experto [Larman]
Nombre: Experto.
Problema: ¿Cuál es el principio fundamental en virtud del cual se asignan las responsabilidades en el diseño
orientado a objetos?
Solución: Asignar una responsabilidad al experto en información: la clase que cuenta con la información
necesaria para cumplir la responsabilidad.
El Patrón Experto
Ejemplo: ¿quién es el responsable de saber la cantidad de ítems vendidos?.
Desde el punto de vista del patrón Experto, deberíamos buscar la clase de objetos que posee
información sobre los Items, el objeto que conoce esto es CarritoCompra
El Patrón Experto
¿Qué información 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
información necesaria para realizar la responsabilidad
Seguimos con el ejemplo...
: CarritoCompra : Items
2: s := subtotal()1: venta()
: EjemplarLibro
3: p := darPrecio()
CarritoCompra
venta()
1..*
11
tiene
1..*
Items
cantidad
subtotal()
0..* pertenecen
1
0..*
1
EjemplarLibro
numeroprecio
darPrecio()
El Patrón Creador [Larman]
El patrón Creador guía la asignación de responsabilidades relacionadas con la creación de objetos, tarea muy frecuente en los sistemas
orientados a objetos.
El objetivo de este patrón es encontrar un creador que debemos conectar con el objeto producido en
cualquier evento
El Patrón Creador
Nombre: Creador.Problema: ¿Quién debería ser responsable de crear
una nueva instancia de alguna clase?
La creación de objetos es una de las actividades más frecuentes en un sistema orientado a objetos. En consecuencia, conviene contar con un principio general para asignar las responsabilidades concernientes a ella.
El Patrón Creador
Solución: 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 inicialización que serán enviados a A cuando este objeto sea creado (B es un experto respecto a la creación de A).
El Patrón Creador
Ejemplo: En la aplicación ¿quién debería encargarse de crear una instancia de items?
Desde el punto de vista del patrón Creador, deberíamos 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 reutilización.
El Patrón Creador
Un CarritoCompra contiene (agrega) muchos objetos Items. Es por esto que el patrón Creador
sugiere que CarritoCompra es la clase idónea para asumir la responsabilidad de crear las
instancias de Items.
: CarritoCompra : Items
2: crear()1: agregarItem()
CarritoCompra
agregarItem()venta()
1..*
11
tiene
1..*
Items
cantidad
crear()subtotal()
Seguimos con el ejemplo...
Autornombreapellido
OrdenCompranumerotarjetadireccionEntregaopcionEntrega
Clientenombreapellidodireccionteprofesion
0..*
1
0..*
1
tiene
Libroisbntituloeditorialsoportecategoria
1..*1..* 1..*1..*
esta escrito por
CarritoCompra
agregarItem()venta()
1
1
1
1es de
1
1
1
1
usa
EjemplarLibro
numeroprecio
darPrecio()
1..*
1
1..*
1
tiene
Itemscantidad
crear()subtotal()
1..*
1
1..*
1
tiene
1
0..*
1
0..* pertenecen
Bibliografía básica
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 introducción al Análisis y Diseño 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 introducción al Análisis y Diseño 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 notación
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 guían el diseño, la implementación y la prueba
• Basándose en los casos de uso los desarrollares crean modelos de diseño e implementación que llevan a cabo los casos de uso
Centrado en la Arquitectura
• La arquitectura es una vista de diseño on las características más importantes, dejando los detalles de lado
• Constituyen la “forma del sistema”, incluye aspectos estáticos y dinámicos
• 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 duración fija, llamados iteraciones (2 a 6 semanas)
• El resultado de cada uno es un sistema que puede ser probado, integrado y ejecutado.
• Cada iteración incluye sus propias actividades de: análisis de requisitos, diseño, implementación y prueba
Iterativo e Incremental
• Desarrollo incremental: el sistema crece incrementalmente a lo largo del tiempo, iteración tras iteración.
• El resultado de cada iteración es un sistema ejecutable, pero incompleto
• En general, cada iteración aborda nuevos requisitos y amplia el sistema incrementalmente
• La salida de una iteración NO es un prototipo desechable, es un subconjunto de calidad del sistema final
Fases del Desarrollo Unificado
• Inicio: visión aproximada, análisis del negocio, alcance, estimaciones imprecisas
• Elaboración: visión refinada, implementación iterativa del núcleo central de la arquitectura, resolución de riesgos altos, identificación de más requisitos
• Construcción: implementación iterativa del resto de requisitos de menor riesgo
• Transición: pruebas beta
El Proceso UnificadoIterativo e incremental
Iter#n
------------Iter#2
Test
Iter#n-1
------Iter#1
Implementac.
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboraciónGestaciónFlujos de trabajo / Fases
Fase de inicio
Fase de inicio
• Actividades a realizar (una o algunas)
– Visión y análisis del negocio– Modelo de casos de uso– Especificaciones complementarias– Listas de riesgos– Prototipos– Plan de iteración
Fase de inicio
• No se entendio la fase de inicio si...– La duración es mayor a unas pocas semanas– Se intenta definir la mayoría de los requisitos– Se espera que los planes y la estimación es
fiable– Se define la arquitectura– No se identifican la mayoría de de los nombres
de los casos de uso y los actores– Se escribieron todos los casos de uso en detalle
El Proceso UnificadoIterativo e incremental
Iter#n
------------Iter#2
Test
Iter#n-1
------Iter#1
Implementac.
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboraciónGestaciónFlujos de trabajo / Fases
Fase de elaboración
Fase de elaboración
• Actividades a realizar– Se descubren y estabilizan la mayoría de los
casos de uso– Se reducen o eliminan los riesgos importantes– Se implementan y prueban los elementos
básicos de la arquitectura– Duración: 2 a 4 iteraciones con una duración
de 2 a 6 semanas (dependiendo de la duración del proyecto)
Fase de elaboración
El producto resultante no es un prototipo desechable
El código y el diseño son de calidad y se integran al sistema final
Fase de elaboración
• Artefactos de la fase de elaboración– Modelo del dominio (entidades del dominio)– Modelo de diseño (diagramas de clases, de
iteración. etc)– Modelo de datos– Modelo de pruebas– Modelos de implementación
Fase de Elaboración
• No se entendio la fase de elaboración si...– Sólo comprende una iteración– La mayoría de los requisitos se definieron antes
de la elaboración– NO hay programación de codigo ejecutable– Se intenta llevar a cabo un diseño completo
antes de la codificación– Los usuarios no se involucran en la evaluación
El Proceso UnificadoIterativo e incremental
Iter#n
------------Iter#2
Test
Iter#n-1
------Iter#1
Implementac.
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboraciónGestaciónFlujos de trabajo / Fases
Fase de construcción
Fase de construcción
• Objetivos– Terminar de construir la aplicación – Realizar pruebas alfa– Preparar pruebas beta (para la transición) – Preparación de guías de usuario – Preparación de materiales de aprendizaje
El Proceso UnificadoIterativo e incremental
Iter#n
------------Iter#2
Test
Iter#n-1
------Iter#1
Implementac.
Diseño
Análisis
Requisitos
TransiciónConstrucciónElaboraciónGestaciónFlujos de trabajo / Fases
Fase de transición
Fase de Transición
Objetivo: poner el sistema en producción
• 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 elaboración– Se refinan en las sucesivas iteraciones
• Casos de uso en la fase de construcción– Se escriben casos de uso menores
• Casos de uso en la fase de transición– En esta fase no se describen
Bibliografia básica
Larman C. UML y patrones. Una introducción al Análisis y Diseño 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
¿Cómo mantengo la persistencia de los objetos...?
...Mediante una base de datos
¿Cómo 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
Transformación
¿Todas las clases se corresponden con tablas?¿...y las asociaciones?¿...y las clases asociaciones?¿...y las generalizaciones?
Además ...¿Cuáles serán las entidades e interrelaciones ?¿Cuáles serán sus atributos?¿Cuáles serán los atributos identificadores?
Transformación
• 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 asociación se transforman en interrelaciones– La multiplicidad es de M:N– Los atributos de la clase asociación pasan a ser
atributos de la interrelación
Transformación
• Las asociaciones se transforman en interrelaciones– Se mantiene la misma multiplicidad de la
asociación en las interrelaciones
• Las relaciones de clasificación– Se transforman en relaciones de clases y
subclases en el modelo entidad interrelación, o – Se pasan los atributos de la superclases a las
subclases (desaparece la superclase)
ALUMNO
CURSO MATERIA
cod_alum
cod_cur
cod_mat
N
1
PROFESOR
NOTA
M
NN
M
nota
fecha
cod_prof
supeclase
superclase
NOTAnotafecha
PROFESOR
CURSO
ALUMNO
1
*
MATERIA*
*
*
**
*
*
*
*
1
Transformación del modelo de
clases al modelo de datos
La transformación al modelo relacional es la
conocida...
Seguimos con el ejemplo...
Autornombreapellido
OrdenCompra
numerotarjetadireccionEntregaopcionEntrega
Clientenombreapellidodireccionteprofesion
0..*
1
0..*
1
tiene
Libro
isbntituloeditorialsoportecategoria
1..*1..* 1..*1..*
esta escrito por
CarritoCompra
agregarItem()venta()
1
1
1
1es de
1
1
1
1
usa
EjemplarLibro
numeroprecio
darPrecio()
1..*
1
1..*
1
tiene
Itemscantidad
crear()subtotal()
1..*
1
1..*
1
tiene
1
0..*
1
0..* pertenecen
CLIENTE
EJEMPLARLIBRO
cod_cli
num_ejemp
1
1
ORDENCOMPRA
1
1
1
cod_carro
cod_ord
AUTOR LIBRO
cod_librocod_autor
ITEMS
num_item
CARRITOCOMPRA
1
N
N
N 1
1
N
N N
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))
Bibliografía Básica
• Rumbaugh J, Blaha M, Premerlani W, Eddy F, LorensenW.. Modelado y Diseño Orientado a Objetos. España: Prentice-Hall; 1996
• Mapping Objects to Tables. A Pattern Language. Wolfgang Keller
¿Cómo podemos hacer para especificar aquello que los
modelos no pueden?
OCL
Object Constraint Language
¿Por qué utilizar OCL?
• Un modelo gráfico como UML no es suficente para una especificación 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 solución: LENGUAJES FORMALES– Problemas: necesidad de usuarios con una
fuerte formación matemática
• Una alternativa: OCL– Lenguaje de características formales– Fácil de leer– Fácil de escribir
¿Qué no es OCL?
• NO es un lenguaje de programación• NO es posible escribir lógica de programación• NO es posible invocar operaciones que no sean
una consulta• NO considera aspectos de implementación
¿Dónde usar OCL?
• Para especificar invariantes sobre clases en un modelo de clases.
• Para especificar pre y post-condiciones sobre Operaciones.
• Como lenguaje de navegación.• Para especificar restricciones sobre operaciones
Invariante
• Una expresion OCL puede ser utilizada como un invariante que es una restricción que, cuando está asociada a una clase, debe ser verdadera para todos las instancias de esa clase, en todo momento
Context Alumno inv: self.edad > 0
Dentro de un diagrama Fuera de un diagrama
tipo contextualobjeto contextual
Alumnonombreapellidodireccionedad
darNombre()
<<invariant>> edad > 0
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 operación, escribimos:
context Alumno inv:self.darNombre()
Alumnonombreapellidodireccionedad
darNombre()
Combinación de Propiedades
Las propiedades se pueden combinar para obtener expresiones más complicadas
si quisiéramos decir que los casados son mayores de edad:
context Person inv: self.wife->notEmpty implies self.wife.age>=18 and self.husband->notEmpty impliesself.husband.age>=18
Extremo de Asociación y Navegación
Comenzando desde un objeto en particular, podemos navegar una asociación en un diagrama de clases para referirnos a otro objeto y a sus propiedades.
El valor de esta expresión es el conjunto de objetos que están del otro lado de la asociaciónnombreDeRol
Para hacerlo, navegamos la asociación usando su extremo opuesto:
objecto.nombreDeRol
Si la multiplicidad del extremo es *, es un conjunto
Context Person inv:
self.employer ... (un conjunto)
Si la multiplicidad del extremo es 0 ó 1, es un objetoContext Company inv:Self.manager... (Un objeto)
Colecciones
• El tipo Collection define un gran número de operaciones predefinidas que permiten al modelador de expresiones OCL manipular colecciones
• Colección es un supertipo abstracto para todos los tipos de colección en OCL
• OCL distingue tres tipos diferentes de colecciones: Set, Sequence y Bag
Colecciones
• Set es un conjunto matemático. 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 están ordenados
• { 1, 3, 3, 6 , 6, 7, 8}
Colecciones
• Las Colecciones son tipos predefinidos en OCL. • Tienen un gran número de operaciones
predefinidas. • Una propiedad de la colección en sí es accedida
utilizando la flecha ‘->’ seguida del nombre de la propiedad.
collection->select( ...
Operación Select
Especifica un subconjunto de una colección. El parámetro de la select debe ser una expresiónbooleana.
collection->select( boolean-expression )
context Company inv:self.employee -> select (age > 50)
Operación forAll
La operación forAll en OCL permite especificar expresiones Booleanas, que deben cumplirse para todos los elementos de la colección:
collection->forAll( boolean-expression )
context Company inv: self.employee -> forAll(age <= 65 )
Operación Exists
Muchas veces uno necesita saber si en una colección hay, al menos, un elemento que cumple cierta condición.
Collection -> exists( boolean-expression )
context Company inv:self.employee -> exists(name = 'Jack' )
Operaciones sobre Colecciones
collection->size : IntegerThe 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) : IntegerThe number of times that object occurs in the collection collection
v. gr.: set -> count(object : T) : IntegerThe number of occurrences of object in setpost: result <= 1
Operaciones sobre colecciones
collection -> isEmpty() : BooleanIs collection the empty collection?
collection -> notEmpty() : BooleanIs collection not the empty collection?
context Company inv:self.wife -> notEmpty implies self.wife.sex = female
EjerciciosLa compañía debe tener menos de 50 empleados y más de 5
PersonaesCasado : BooleanesDesocupado : Booleanedad : IntegeresFeliz : Boolean
Compañianombre : StringcantidadDeEmpleados : Integer
0..*
1compañiaGerenciada
gerente
0..*
0..*
0..*
1
empleador
0..*
0..*empleado
La compañía debe tener menos de 50 empleados y más de 5
Context Compañía inv:Self.cantidadDeEmpleados < 50 and Self.cantidadDeEmpleados > 5
EjerciciosLa compañía debe tener empleados mayores de 18 años
PersonaesCasado : BooleanesDesocupado : Booleanedad : IntegeresFeliz : Boolean
Compañianombre : StringcantidadDeEmpleados : Integer
0..*
1compañiaGerenciada
gerente
0..*
0..*
0..*
1
empleador
0..*
0..*empleado
La compañía debe tener empleados mayores de 18 años
Context Compañía inv:Self.empleado-> forAll(edad > 18)
EjerciciosLa compañía debe tener alguna persona soltera
PersonaesCasado : BooleanesDesocupado : Booleanedad : IntegeresFeliz : Boolean
Compañianombre : StringcantidadDeEmpleados : Integer
0..*
1compañiaGerenciada
gerente
0..*
0..*
0..*
1
empleador
0..*
0..*empleado
La compañía debe tener alguna persona soltera
Context Compañía inv:Self.empleado -> select( not esCasado)-> notEmpty()
EjerciciosLa compañía debe tener empleados mayores a 50 años y casados
PersonaesCasado : BooleanesDesocupado : Booleanedad : IntegeresFeliz : Boolean
Compañianombre : StringcantidadDeEmpleados : Integer
0..*
1compañiaGerenciada
gerente
0..*
0..*
0..*
1
empleador
0..*
0..*empleado
La compañía debe tener empleados mayores a 50 años y casados•
Context Compañía inv:Self.empleado->select(esCasado and edad > 50)->notEmpty()
Bibliografía básica
http://www.omg.org/technology/uml/index.htm
Algunos puntos a tener en cuenta....
• Un sistema de información se diseña en funcion de varias capas
– Interfaz (no la vimos)– Capa logica de la aplicación y objetos del
dominio– Capa de servicios (persistencia)
Fin