soluciones con objetos y patrones. visibilidad

Ingeniería en Sistemas de Información

Diseño de Sistemas(3K1)

Contenidos de la Unidad 3Diseño Orientado a

Objetos I3. Diseño orientado a Objeto I Craig Larman , Cap 15.A. Casos de Uso Reales Cap. 16A. Diagrama de Interacción Cap. 17

a. Diagrama de Secuencia.

a. Diagramas de Comunicación (UML 2)/ Colaboración (UML 1.1)

A. Patrones de Diseño. Cap. 18

a. Patrones creacionales

a. Patrones Estructurales

a. Patrones de Comportamiento

a. GRAPS (Experto, Creador, Alta Cohesión, Bajo Acoplamiento, Controlador)

Soluciones con Objetos Soluciones con Objetos y Patronesy Patrones

Craig Larman, Cap. 19Craig Larman, Cap. 19

Ingeniería en Sistemas de Información

DISEÑO DE SISTEMASDISEÑO DE SISTEMAS

IINNTTRROODDUUCCCCIIÓÓNN La asignación de responsabilidades y la elaboración de los diagramas de interacción representan uno de los pasos más importantes en la fase del diseño.

Como elaborar Diagramas de Interacción Para elaborar diagramas de interacción:

1. Prepare un diagrama individual para cada operación del sistema.

Por cada evento del sistema construya un diagrama, que lo incluya como mensaje inicial.

2. Si el diagrama se vuelve complejo, divídalo en otros más pequeños.

3. Con las responsabilidades contractuales, las poscondiciones y la descripción del caso de uso, como punto de partida, diseñe un sistema de objetos interactuantes para que realicen las tareas. Aplique los patrones GRASP para elaborar un buen diseño.


Diagramas de Interacción y otros artefactos

EfectuarPago(monto)

Cajero Sistema

Introducir Producto

(cup, cantidad)

TerminarVenta()

Diagrama de Secuencia

Operación:

IntroducirProducto

Poscondiciones: 1. Si se trata de una nueva venta, se creo una nueva Venta...

Operación: EfectuarPago Poscondiciones: 1. ...

Contratos

:TPDV

:TPDV

Introducir Producto

EfectuarPago(monto)

Diagrama de Colaboración

(cup, cantidad)


Relación entre los artefactos:

Los Casos de Uso indican los eventos del sistema que se muestran explícitamente en los Diagramas de Secuencia.

Los efectos producidos por los eventos del sistema se describen en los contratos.

Los eventos del sistema pasan a ser los mensajes iniciadores de los Diagramas de Interacción; y describen visualmente cómo los objetos interactúan para realizar esa operación solicitada.

Los objetos que interactúan en los Diagramas de Interacción (o Colaboración) pueden ser los definidos en el Modelo Conceptual y otros más.


Los diagramas de interacción y los eventos del sistema:

Ejemplo: Para el Caso de Estudio del Video Club: tomaremos como referencia el Caso de Uso:

Alquilar Video: dentro del cual identificamos los 4 eventos siguientes:

o introducirSocio

o introducirVideo

o terminarAlquiler

o efectuarPago

Por cada evento del sistema construiremos un Diagrama de Colaboración cuyo mensaje inicial será, precisamente, el de su evento respectivo.


Habrá entonces 4 (cuatro) Diagramas de Interacción. Con el patrón Controlador, la clase CAJA puede escogerse como Controlador para que maneje los eventos.

1: ??? ()

1: ??? ()

1: ??? ()

: Caja introducirSocio()

: Caja introducirVideo()

: Caja terminarAlquiler()

: Caja efectuarPago() 1: ??? ()


Patrones (GRASP)Patrones (GRASP)

Los diagramas de interacción y los contratos: Con las responsabilidades y las poscondiciones del contrato, así como también los casos de uso como punto de partida, se diseña un sistema de objetos interactuantes (Diagramas de Colaboración) para que realicen las tareas para cumplir con cada operación.

Por cada operación del sistema existe un contrato que estipula lo que deben lograr las operaciones. Por ejemplo:


Patrones (GRASP)Patrones (GRASP)

Contrato

Nombre: introducirSocio(codigo : número)

Responsabilidades: Capturar el alquiler del socio.

Desplegar el nombre y dirección del socio.

Poscondiciones:

Se creó un Alquiler (creación de instancia). Se asoció el Alquiler a Socio (asociación formada).


Para elaborar un Diagrama de Colaboración efectivo necesitamos contar con las Responsabilidades y las Postcondiciones, que hemos estudiado en los Contratos.

En caso de omitir la preparación del contrato, de todos modos deberíamos elaborar los diagramas de interacción retornando a los casos de uso y reflexionando sobre los cambios que cada operación genera en el sistema, para poder elaborar los Diagramas de Colaboración.

Los contratos organizan y aíslan la información en un formato funcional, y estimulan la investigación en la fase de análisis y no en la de diseño, ahorrándonos trabajo y problemas.


Las postcondiciones son sólo una estimación:Las postcondiciones son sólo una estimación:

Los diagramas se deben preparar para cumplir con las postcondiciones del contrato. Por eso, las postcondiciones definidas de antemano son una excelente conjetura o estimación inicial de lo que se pretende alcanzar; aunque tal vez no sean muy exactas.

Lo mismo sucede con el modelo conceptual: es un punto de partida que contendrá errores y omisiones. Los contratos son un mero punto de partida para establecer lo que se hará, pero sin sentirnos obligados por ellos. Lo más probable es que algunas postcondiciones no sean necesarias y que haya algunas tareas por realizar aún no descubiertas.


Los Diagramas de Interacción y el Modelo Conceptual:

Algunos objetos que interactúan (a través de mensajes) en los Diagramas de Colaboración provienen del Modelo Conceptual. Utilizamos información del Modelo Conceptual para asignar responsabilidades con los patrones GRASP.

Ahora bien: ¿todos los objetos en interacción saldrán necesariamente del Modelo Conceptual?

De ninguna manera; durante la fase de diseño podemos descubrir otros objetos nuevos, que no figuran en los análisis anteriores.


DIAGRAMAS DE COLABORACION – VIDEO CLUB:DIAGRAMAS DE COLABORACION – VIDEO CLUB:

A continuación, desarrollaremos los Diagramas de Colaboración para el caso de uso Alquiler de video del caso de estudio del Video Club.

El diagrama de colaboración: introducirSocio:

La operación del sistema introducirSocio ocurre cuando el Cajero captura el Código del Socio.

Debemos contar con un Diagrama de Colaboración que cumpla con las Postcondiciones de introducirSocio.


Selección de la case Controlador: Primero, elegiremos el controlador que se encargue del mensaje de las operaciones del sistema introducirProducto. Aplicando el patrón Controlador, tenemos estas opciones: representar todo el sistema (controlador de fachada) Caja representar la empresa o la organización total Tienda (controlador de fachada) representar algo del mundo real que sea activo Cajero (controlador de papeles) representar un manejador artificial de todas las ManejadordeAlquiler operaciones del sistema en un caso de uso (controlador de casos de uso)


Caja no es una terminal real de punto de venta, sino una abstracción de software que representa al objeto “Sistema de CAJA”, dentro del “Territorio del Software”.

Aplicación del patrón Controlador de GRASP

introducirSocio(codigo) :Caja

Controlador


Realización de un alquiler:

Ahora, repasamos las Postcondiciones, expresadas en los contratos, (de introducirSocio); que establecen lo siguiente:

•Se creó un Alquiler (creación de instancia).

•Se asoció el Alquiler a Socio (asociación formada).


Primero, tenemos una responsabilidad de creación. Con lo cual, utilizamos el patrón Creador; el cual indica la asignación de la responsabilidad de generar una clase que agregue, contenga o registre la que va a ser creada.

Al analizar el Modelo Conceptual, descubrimos que Caja nos permite ver el registro de un Alquiler; con lo que Caja sería un buen candidato para crear un Alquiler.

Sin embargo, perderíamos la posibilidad de asociar Alquiler con Socio; por lo tanto, es mejor asignar a Socio la responsabilidad de crear el Alquiler.


Además, cuando se crea el Alquiler, hay que generar una colección vacía (un contenedor) para que registre todas las instancias futuras AlquilerLineadeVideo que vayamos agregando.

En conclusión, el objeto Socio crea un Alquiler y éste, a su vez, genera una colección vacía, representada por un multiobjeto en el Diagrama de Colaboración.


2.1: crear ()introducirSocio(codigo) 2: hacerAlquiler():Caja

:AlquilerLinea deVideo

soc:Socio

2.2: Crear ()

:Socio

1: soc:=encontrar(codigo)

:Alquiler

según Controlador según Creador

según Creador

Creación de Alquileres


Mensajes a multiobjetos:Mensajes a multiobjetos:

Un mensaje enviado a un multiobjeto se envía a todos los elementos de la colección / contenedor. Por ejemplo, en el Diagrama de Colaboración introducirSocio:

El mensaje crear (2.2) enviado al multiobjeto AlquilerLineadeVideo tiene por objeto generar la estructura de datos colección representada por el multiobjeto. Su finalidad no es crear una instancia de la clase AlquilerLineadeVideo.


El Diagrama de Colaboración: introducirVideo

La operación del sistema introducirVideo ocurre cuando el Cajero captura el código de Video. Con las Postcondiciones de introducirVideo se construirá un Diagrama de Colaboración. Cada vez que se emita un mensaje debemos asignar una responsabilidad.

Selección de la case Controlador:

Igual que en el diagrama anterior, utilizaremos Caja como Controlador.


Análisis de las Postcondiciones de introducirVideo:

Las Postcondiciones Contractuales de introducirVideo establecen lo siguiente:

1) Se creó una instancia AlquilerLineadeVideo (creación de instancia).

2) Se asoció AlquilerLineadeVideo al Alquiler (asociación formada).

3) Se asoció la instancia AlquilerLineadeVideo con Video a partir de la correspondencia en el código (asociación formada).

4) Se asignó el valor verdadero a Video.estado (modificación de atributo).


Lo anterior indica la responsabilidad de crear una instancia AlquilerLineadeVideo.

El análisis del Modelo Conceptual revela que el Alquiler contiene los objetos AlquilerLineadeVideo; por lo tanto, aplicando el patrón Creador; Alquiler es un buen candidato para generar la línea de video.

Al hacer esto, asociamos automáticamente el Alquiler con la línea a lo largo del tiempo, al guardar esta nueva colección.


Obtención de una instancia Video:Obtención de una instancia Video:

Debemos ahora asociar la instancia AlquilerLineadeVideo a Video, por concordancia del código que se recibe. Esto significa que se requiere recuperar un Video basado en la correspondencia del código.

En este caso, no estamos ante un problema de creación ni de escoger un controlador. Entonces, aplicamos el patrón Experto GRASP en primer lugar.

¿Quién está enterado de todo lo concerniente a Video?:

El análisis del Modelo Conceptual revela que VideoClub contiene a todos los Videos y así, siguiendo al patrón Experto, VideoClub es idóneo para asumir esa responsabilidad de consulta.


Establecimiento del atributo Video.estado:Establecimiento del atributo Video.estado:

¿Quién debería encargarse de asignar el valor verdadero al atributo estado del Video?

Basándonos en el patrón Experto, debería ser el mismo Video, porque posee el atributo estado.

Así VideoClub enviará a la instancia Video el mensaje seAlquila para asignarle el valor verdadero, el Video quede registrado como «alquilado», y por ende, no disponible para una nueva transacción de Alquiler.


introducirVideo(codigo) 2: hacerAlquilerLineadeVideo(vid):Caja

:AlquilerLinea deVideo

2.2:agregar (da)

:Video

1: vid:=extraer(codigo)

:Alquiler

según Controlador según Creador

:VideoClub

1.1: vid:=encontrar(codigo)

vid:Video

3: alquilado()

2.1: crear(vid)

da:AlquilerLineadeVideo

según Experto

Diagrama de colaboración introducirVideo


Mensajes a multiobjetos:

En este diagrama de colaboración, los mensajes a multiobjetos son los siguientes:

1) El mensaje encontrar (1.1) enviado al multiobjeto Video.

2) El mensaje agregar (2.2) enviado al multiobjeto AlquilerLineadeVideo, tiene por objeto incorporar un elemento a la estructura de datos colección.


El diagrama de colaboración: El diagrama de colaboración: terminarAlquilerterminarAlquiler

La operación terminarAlquiler ocurre cuando un Cajero oprime un botón para indicar la conclusión de un alquiler.

Se elaborará un Diagrama de Colaboración para cumplir las Postcondiciones de terminarAlquiler.

Cada decisión sobre mensajes implica asignar Responsabilidades, y los patrones GRASP se emplearán para escogerlos y justificarlos.

Selección de la clase Controlador:Selección de la clase Controlador:

Basándonos en el patrón Controlador de GRASP, seguiremos utilizando Caja.


Establecimiento de los atributos de Alquiler:

Las Postcondiciones contractuales establecen lo siguiente:1) Se asignó el valor FechaActual a Alquiler.fecha (modificación de

atributo).

1) Se asignó el valor HoraActual a Alquiler.hora (modificación de atributo).

Como siempre, el Patrón Experto debe ser el primero a considerar, salvo para problemas de controlador o de creación.

En este caso, el Experto debería ser el propio Alquiler, puesto que éste tiene los atributos fecha y hora. De esta manera, Caja enviará a Alquiler el mensaje seTermina, para modificar los atributos anteriores.


terminarAlquiler() 2: seTermina()

:Caja :Alquiler

según Controlador según Experto

seTermina(){ fecha := FechaActual hora:= HoraActual}

Terminación de la captura de videos


La presentación visual de información:

En las responsabilidades del contrato terminarAlquiler se estipula que debe mostrarse el total del alquiler.

Se trata de una cuestión de quién debe encargarse de presentar visualmente la información, en una ventana gráfica.

Se sugiere que la capa de los objetos del dominio (Alquiler, VideoClub, Caja, etc.) no debieran conocer las ventanas o la capa de presentación o tener comunicación con ellas.


Cálculo del total del Cálculo del total del AlquilerAlquiler::

El Patrón Experto debe ser el primero en considerarse.

a) ¿Quién debe asumir la responsabilidad de realizar el alquiler? Según el patrón Experto, el propio alquiler, porque conoce todo lo concerniente a AlquilerLineadeVideo. Por consiguiente Alquiler es el responsable de calcularlo, y se implementa como una operación total.

b) Para que Alquiler calcule el total, necesita conocer el precio de cada video en la línea de video. ¿Quién debería asumir la responsabilidad de ofrecer el precio?.

Según el patrón Experto, debería ser: AlquilerLineadeVideo, que esta asociado a Video. Por lo tanto AlquilerLineadeVideo tendrá esta responsabilidad, que se implementa con la operación subtotal.


El diagrama de colaboración total del alquiler:

Conviene construir un diagrama de colaboración que indique lo que sucede cuando a un Alquiler se le envía un mensaje de total. El primer mensaje del diagrama es total, pero observe que no es un evento del sistema. De ello extraemos la siguiente observación:

No todo diagrama de colaboración comienza con un mensaje de eventos del sistema; puede empezar con cualquier mensaje cuyas interacciones desee mostrar el diseñador.

El mensaje total se envía a la instancia Alquiler. Esta envía entonces un mensaje subtotal a las instancias relacionadas de AlquilerLineadeVideo. Y a su vez esta instancia enviara un mensaje precio al Video correspondiente.


2.1 : p := precio ()

2 : st := subtotal()

t:= total() :Alquiler

alv:=:ALV

vid:Video

:AlquilerLineadeVideo

1*:[p/c] alv:= siguiente()

según Experto

según Experto

Calculo del Total de la Venta


El diagrama de colaboración: El diagrama de colaboración: efectuarPagoefectuarPago

La operación sistémica efectuarPago ocurre cuando un cajero captura el efectivo ofrecido como pago.

Se construirá un diagrama de colaboración para cumplir con las Postcondiciones de efectuarPago.

Elección del Controlador:Elección del Controlador:

Nuestra primera decisión se refiere a la responsabilidad del manejo de los mensajes.

Con base en el patrón Controlador seguiremos empleando a la Con base en el patrón Controlador seguiremos empleando a la CajaCaja como controlador como controlador.


Creación del Pago:Creación del Pago:

Postcondiciones contractuales:

• “se creó un Pago” (creación de instancia).

¿Quién registra, agrega o contiene un Pago?:

Como resulta atractivo afirmar que la Caja registra lógicamente un Pago, se pensará que Caja es idónea para crearlo. Sin embargo, Alquiler está estrechamente ligado a su Pago; de ahí la posibilidad de que sea un buen candidato también para crearlo.

En conclusión, tenemos dos candidatos:

1º) Caja2º) Alquiler


En estos casos, en que tenemos varios buenos candidatos, conviene hacer jugar a los restantes patrones de: Bajo acoplamiento y Alta cohesión.

Si escogemos el objeto “Alquiler” para crear un Pago, las responsabilidades de Caja serán mas ligeras, y dará origen a una definición mas simple de Caja.

Además no necesita saber que existe una instancia Pago, porque podemos registrarla indirectamente mediante el Alquiler. Con lo cual, el diagrama de colaboración sería así:


1: efectuarPago (efecOfrecido):Caja :Alquiler

:Pago

efectuarPago (efecOfrecido)

1.1: crear (efecOfrecido)

según Controlador

según Creador y Bajo Acoplamiento

Diagrama de colaboración efectuarPago


Calcular el vuelto:Calcular el vuelto:

Como es habitual el patrón Experto será el primero en considerarse, y habrá que formular la responsabilidad en los siguientes términos:

¿Quién asume la responsabilidad de conocer el vuelto?

Para calcular el vuelto, necesitamos el total del alquiler y el pago en efectivo ofrecido. Por lo tanto: Alquiler y Pago son expertos parciales para la solución de este problema.

Si Pago es el principal responsable de conocer el saldo, necesitará ser visible al Alquiler para pedirle su total.

Como por ahora no lo conoce, con este método aumentará el acoplamiento global del diseño: y por lo tanto, no soportará el patrón de Bajo Acoplamiento.


En cambio si el Alquiler es el principal responsable de conocer el saldo, necesitara ser visible al Pago para pedirle el monto ofrecido.

Dado que Alquiler ya es visible al Pago (por ser su Creador), con este enfoque no aumenta el acoplamiento global, de ahí que es preferible elegir a Alquiler, para asignarle la responsabilidad e .

El diagrama de colaboración será el siguiente:

:Pago1: mon:= monto()sal:= saldo()

2:t := total()

:Alquiler

El diagrama de colaboración alquiler-saldo

soluciones con objetos y patrones. visibilidad

Travel