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”


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



comprar libro

Cliente

buscar libros

Consultar libro

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


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)


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)


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



Cliente

Gestor de Libros

Tarjeta de Credito

Consultar libro


<<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)


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


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 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)


: 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()


• 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

Ejemplo de Diagrama de Colaboración


• 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


Piramide


3DAdaptador

dibujar()mover()

3DFigura


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.


tiene

OrdenCompra

numerotarjetadireccionEntregaopcionEntrega


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


: 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


1..*

11

tiene

1..*

Items

cantidad

crear()subtotal()


Autornombreapellido

OrdenCompranumerotarjetadireccionEntregaopcionEntrega


0..*

1

0..*

1

tiene

Libroisbntituloeditorialsoportecategoria

1..*1..* 1..*1..*

esta escrito por

CarritoCompra


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


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.


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


Iter#n

------------Iter#2

Test

Iter#n-1

------Iter#1

Implementac.

Diseño

Análisis

Requisitos


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)


El producto resultante no es un prototipo desechable

El código y el diseño son de calidad y se integran al sistema final


• 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


Iter#n

------------Iter#2

Test

Iter#n-1

------Iter#1

Implementac.

Diseño

Análisis

Requisitos


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


Iter#n

------------Iter#2

Test

Iter#n-1

------Iter#1

Implementac.

Diseño

Análisis

Requisitos


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


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


Autornombreapellido

OrdenCompra

numerotarjetadireccionEntregaopcionEntrega


0..*

1

0..*

1

tiene

Libro

isbntituloeditorialsoportecategoria

1..*1..* 1..*1..*

esta escrito por

CarritoCompra


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



0..*


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



0..*


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



0..*


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()


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


• 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)

66827593 analisis de sistemas administrativos uml ocl rup

Documents