Unidad 9 Patrones De DiseñO

13 de abr de 2023 Sergio Sánchez Rios

Metodologías de Análisis y DiseñoUnidad VII

Diseño O.O – Diagramas de Interacción

“Patrones de Diseño”

Sergio Sánchez Rios.

Ingeniero en Informática – Licenciado en Informática

Docente Jornada Parcial Universidad Viña del Mar


Diagramas de InteracciónGRASP – Patrones de asignación de Responsabilidades

Patrones

Los diseñadores expertos en orientación a objetos, van formando un amplio repertorio de principios generales que los guían al crear software. Estos principios son llamados Patrones.

Los patrones se codifican en un formato estructurado que describe el problema y su solución .

Cada patrón tiene un nombre. Los patrones no se proponen descubrir ni expresar principios nuevos en Ingeniería de Software. Todo lo contrario, intentan codificar el conocimiento y los principios ya existentes: cuanto más generalizados y usados mejor.


Patrones

En consecuencia, los patrones GRASP no establecen nuevas ideas: son una codificación de principios básicos ampliamente utilizados. Para un experto en objetos, los patrones GRASP – por su idea y por su nombre – parecerán muy elementales y familiares. ¡Eso es lo importante!.



GRASP

Resumiendo

La asignación habilidosa de responsabilidades es extremadamente importante en el diseño O.O..

La decisión acerca de la asignación de responsabilidades, a menudo, tiene lugar durante la creación de los diagramas de interacción y con seguridad durante la programación.

Los patrones son pares problema/solución con un nombre que codifican buenos consejos y principios relacionados con frecuencia con la asignación de responsabilidades.



GRASP

Es importante entender y ser capaz de aplicar estos principios durante la creación de los diagramas de interacción porque un desarrollador de software con poca experiencia en la tecnología de objetos necesita dominar estos principios tan rápido como sea posible; constituyen la base de cómo diseñara el sistema.

GRASP es un acrónimo de General Responsibility Assignment Software Patterns (patrones generales de software para asignar responsabilidades).



El patrón Experto [Larman 98]

Nombre Experto

Problema ¿Cuál es el principio fundamental en virtud del cual se asignan las responsabilidades en el diseño O.O?

Un modelo de clases puede definir n clases de software, y una aplicación tal vez requiera el cumplimiento de n responsabilidades.

Durante el Diseño O.O, cuando se definen las interacciones entre los objetos se toman decisiones sobre la asignación de responsabilidades a clases. Si se hacen en forma adecuada, los sistemas tienden a ser más fáciles de entender, mantener y ampliar, y nos presentan la oportunidad de reutilizar componentes en futuras aplicaciones.

Solución Asignar una responsabilidad al experto en información: la clase que cuenta con la información necesaria para cumplir la responsabilidad.

Diagramas de InteracciónPrincipales Patrones - GRASP


El patrón Experto [Larman 98]

Ejemplo En la aplicación del punto de venta, alguna clase necesita conocer el gran total de venta.

Beneficios -Se conserva el encapsulamiento, ya que los objetos se valen de su propia información para hacer lo que se les pide. Esto provee un bajo nivel acoplamiento, lo que favorece al hecho de tener sistemas mas robustos y fáciles de mantener.

-El comportamiento se distribuye entre las clases que cuentan con la información requerida, lo que ayuda a definir “clases sencillas” y más cohesivas, que son mas faciles de comprender y mantener.



El patrón Experto [Larman 98] (Ejemplo)

Para el ejemplo del Punto de Venta. ¿Quién es el responsable de conocer el gran total de la venta?.

Desde el punto de vista del patrón Experto, deberíamos buscar la clase de objetos que posee la información necesaria para calcular el total. Por ejemplo:




¿Qué información hace falta para calcular el gran total?. Hay que conocer todas las instancias VentaLineadeProducto de una venta, y la suma de sus subtotales, y esto lo conoce únicamente la instancia Venta. Por tanto, desde el punto de vista del Experto, Venta es la clase de objetos correcta para asumir esta responsabilidad. Venta es el experto de información.




Todavía no terminamos. ¿Qué información hace falta para determinar el subtotal de la línea de productos?. Se necesitan VentasLineasProducto.cantidad y EspecificacióndeProductos.precio. VentasLineaProducto conoce su cantidad y su correspondiente EspecificaciondeProducto. Por tanto, desde la perspectiva patrón experto, VentasLineaProducto debería calcular el subtotal




VentasLineaProducto no puede cumplir la responsabilidad de conocer y dar el subtotal, si no conoce el precio del producto. EspecificaciondeProducto es un Experto de información para contestar su precio. Por tanto, habrá que enviarle un mensaje preguntándole el precio.




En conclusión, para cumplir con la responsabilidad de conocer y dar el total de venta, se asignaron responsabilidades a tres clases de objetos:

Clase Responsabilidad

Venta Conocer Total de la Venta

VentasLineadeProducto Conoce subtotal de la línea de producto

EspecificacióndeProducto Conoce el precio del producto

El cumplimiento de una responsabilidad requiere a menudo información distribuida en varias clases de objetos. (“Expertos Parciales” que colaboran en la tarea).



El patrón Creador [Larman 98]

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.




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 diseño, bien asignado, puede apoyar un bajo acoplamiento, una mayor claridad, el encapsulamiento y la reutilización.

Solución Asignar a la clase B la responsabilidad de crear una instancia de la clase A en uno de los siguientes casos:




Solución -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)

B es un creador de los objetos A. Si existe más de una opción, prefiera la clase B que agregue o contenga la clase A.

Ejemplo ¿Quién debería encargarse una instancia de VentasLineadeProductos?

Beneficios Se brinda apoyo al bajo acoplamiento, lo cual supone menos dependencias respecto al mantenimiento y mejores oportunidades de reutilización



El patrón Creador [Larman 98] (Ejemplo)

En la aplicación del punto de venta ¿quién debería encargarse de crear una instancia de VentasLineadeProducto?. 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.

Una Venta (en realidad, agrega) muchos objetos VentasLIneadeProducto. Es por esto que Venta es la clase idónea para asumir la responsabilidad de crear las instancias de VentaLineadeProducto. Esta asignación de responsabilidad requiere definir en Venta un método para hacerLineadeProducto.



El patrón Creador [Larman 98] (Ejemplo)



El patrón Controlador

Nombre Controlador

Problema ¿Quién debería encargarse de atender un nuevo evento del sistema?

Un evento del sistema es un evento de alto nivel generado por un actor externo. Es un evento de entrada externa. Se asocia a operaciones del sistema: las que se emiten en respuesta a los eventos del sistema.

Por ejemplo: cuando un cajero que usa una terminal de punto de venta oprime el botón “terminar Venta”, está generando un evento sistematico que indica que la “venta a terminado”.

Un controlador es un objeto de interfaz que se encarga de manejar un evento del sistema. Define además el método de su operación.



El patrón Controlador

Solución Asignar la responsabilidad del manejo de mensajes de los eventos del sistema a una clase que represente alguna de las siguientes opciones:

-El “sistema” global (controlador de fachada)

-La empresa u organización global (controlador de fachada)

-Algo en el mundo real que es activo (por ejemplo el rol de una persona) y que puede participar en la tarea (controlador de tareas).

-Un manejador artificial de todos los eventos del sistema de un caso de uso (controlador de casos de uso).

Utilice la misma clase controlador con todos los eventos del sistema en el mismo caso de uso.

Ejemplo En la aplicación del punto de venta se dan varias operaciones del sistema, como terminarVenta(), pasarProducto(), efectuarPago().

Beneficios Garantiza que la empresa o los procesos de dominio sean manejados por la capa de los objetos del dominio y no por la interfaz.



El patrón Controlador (Ejemplo)

Durante el análisis del comportamiento del sistema, sus operaciones son asignada al tipo de Sistema, para indicar que son operaciones del Sistema.

Pero esto no significa que una clase llamada Sistema las ejecute durante el diseño. Durante el diseño, a la clase Controlador se le asigna la responsabilidad de las operaciones del sistema.




¿Quien debería ser el Controlador de eventos sistemáticos como pasarProducto y terminarVenta?

Según el patrón Controlador, disponemos de las siguientes opciones:

TPDV (Registro) Representa al “sistema” global

Tienda Representa la empresa u organización

Cajero Representa algo en el mundo real que está activo y que puede intervenir en la tarea

ManejadordeComprarProducto Representa un manejador artificial de todas las operaciones del sistema de un caso de uso.




:Cajero

Articulo ID

Cantidad

IntroducirArticulo

Etc...Presiona

Botón

:JFrameVenta

actionPerfomed(actionEvent)

Capa Interfaz

:???????Capa

Dominio

introducirArticulo(articuloID,cant)

Mensaje de evento del sistema




:ProcesarVentaManejadorIntroduccirArticulo(id,cantidad)

:RegistroIntroduccirArticulo(id,cantidad)

Durante el diseño, se asignan a una o más clases controlador las operaciones del sistema que se identificaron durante el análisis del comportamiento del sistema, como Registro




La primera categoría de controladores es un controlador de Fachada, que representa al “sistema” global. Es un clase, que para el diseñador, representa de alguna manera el diseño completo.

Si se recurre a la cuarta categoría de controlador (un “manejador artificial de casos de uso”), habrá entonces un controlador para cada caso. Este no es un objeto del dominio, es un concepto artificial.

Por ejemplo, si la aplicación de punto de venta contiene casos como “Comprar Productos” y “Devolver Productos”, habrá un ManejadordeComprarProductos y una clase ManejadordeDevolverProductos.




Un controlador de casos de uso es una buena alternativa cuando hay muchos eventos de sistema entre varios procesos: asigna su manejo a clases individuales controlables.



El patrón Bajo Acoplamiento [Larman 98]

Nombre Bajo Acoplamiento

Problema ¿Cómo dar soporte a una mínima dependencia y aún aumento en la reutilización?

El acoplamiento mide qué tan fuerte está una clase conectada con otras (es decir, cuántas clases conoce y necesita). Una clase con bajo o débil acoplamiento no depende de muchas otras clases. Una clase con alto (o fuerte) acoplamiento recurre a muchas otras clases. Este tipo de clase no es conveniente, pues: cambios en las clases relacionadas ocasionan cambios en la clase local; son más difíciles de entender; son más difíciles de reutilizar.

Solución Asignar una responsabilidad para mantener bajo acoplamiento.



El patrón Bajo Acoplamiento [Larman 98]

Beneficios -No afecta los cambios en otros componentes.

-Fácil de entender de manera aislada.

-Conveniente para reutilizar.



El patrón Bajo Acoplamiento [Larman 98] (Ejemplo)

Tres de las clases de aplicación de punto de venta era: Pago, TPV y Venta. Supongamos que necesitamos crear una instancia de Pago y asociarla a Venta. Como TPV “registra” un pago en el mundo real, es un buen candidato para crearlo.

Está asignación de responsabilidades acopla la clase TPV al conocimiento de la clase Pago.




Una solución alterna sería crear Pago y asociarlo a la Venta.

Este último diseño es mejor porque conserva un menor acoplamiento global. El ejemplo es una situación donde patrones distintos (Bajo Acoplamiento y Creador) pueden surgir decisiones distintas.




Las formas más comunes de acoplamiento son las siguientes:

Una clase X posee un atributo o variable de instancia que se refiere a otra instancia de clase Y.

X tiene un método que referencia una instancia de clase Y.

X tiene un parámetro o una variable local del tipo Y.

El objeto devuelto en un mensaje invocado por X es una instancia de clase Y.

X es una subclase de Y.

Y es una interfaz y X la implementa.




El bajo acoplamiento apoya al diseño de clases mas independientes, que reduce el impacto de los cambios, así como clases más reutilizables.

El acoplamiento no es importante sino se busca la reutilización.



El patrón Alta Cohesión

Nombre Alta Cohesión

Problema ¿Cómo mantener la complejidad manejable?

En cuanto al diseño de objetos, la cohesión (o de manera más especifica la cohesión funcional) es una medida de fuerza con la que se relacionan y del grado de focalización de las responsabilidades de un elemento. Un elemento con responsabilidad altamente relacionada, y que no hace una gran cantidad de trabajo, tiene alta cohesión.

A menudo, las clases con baja cohesión representan un “grano grande” de abstracción, o se les ha asignado responsabilidades que debería haberse delegado en otros objetos.

Solución Asignar una responsabilidad de manera que la cohesión permanezca alta.



El patrón Alta Cohesión

Beneficios -Se incrementa la claridad y facilita la comprensión del diseño.

-Se simplifica el mantenimiento y las mejoras.

-Se soporta a menudo bajo acoplamiento.

-El grano fino de funcionalidad altamente relacionada incrementa la reutilización porque una clase cohesiva se puede utilizar para un propósito muy especifico.

Como regla empírica, una clase con alta cohesión tiene un número relativamente pequeño de métodos, con funcionalidades altamente relacionada, y no realiza mucho trabajo. Colabora con otros objetos para compartir el esfuerzo si la tarea es extensa.



Elabore un diagrama por cada operación del sistema durante el ciclo actual de desarrollo.

Diseñe un sistema de objetos interactivos que realicen las tareas, usando un punto de partida:

Las responsabilidades y las poscondiciones del contrato.

Las descripciones de casos de uso reales.

Aplique el GRASP y otros patrones para desarrollar un buen diseño.

Diagramas de InteracciónElaboración


Guía del Tópico:

Software Engineering 6a. ed.– Ian Sommerville – Pearson Education – 2000. (Cap. 6)Ingeniería de Software Teoría y Práctica – Shari Lawrence Pfleeger – Pearson Education – 2002.Utilización de UML en ingeniería del software con objetos y componentes – Perdita Stevens & Rob Pooley – Addison Wesley – 2002. UML y Patrones una introducción al análisis y diseño orientados a objeto y al proceso unificado – Craig Larman – Prentice Hall - 2002.

Bibliografía

Documents

Unidad 9 Patrones De DiseñO