Unidad 9 Patrones De DiseñO
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Unidad 9 Patrones De DiseñO

on

  • 5,110 views

 

Statistics

Views

Total Views
5,110
Views on SlideShare
5,108
Embed Views
2

Actions

Likes
0
Downloads
196
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Unidad 9 Patrones De DiseñO Presentation Transcript

  • 1. Metodologías de Análisis y Diseño Unidad 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
  • 2. Diagramas de Interacción GRASP – 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.
  • 3. Diagramas de Interacción 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 – Patrones de asignación de Responsabilidades
  • 4. Diagramas de Interacción
    • 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 – Patrones de asignación de Responsabilidades
  • 5. Diagramas de Interacción 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 G eneral R esponsibility A ssignment S oftware P atterns (patrones generales de software para asignar responsabilidades). GRASP – Patrones de asignación de Responsabilidades
  • 6. Diagramas de Interacción El patrón Experto [Larman 98] Principales Patrones - GRASP Experto Nombre Asignar una responsabilidad al experto en información: la clase que cuenta con la información necesaria para cumplir la responsabilidad. Solución ¿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. Problema
  • 7. Diagramas de Interacción El patrón Experto [Larman 98] Principales Patrones - GRASP En la aplicación del punto de venta, alguna clase necesita conocer el gran total de venta. Ejemplo -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. Beneficios
  • 8. Diagramas de Interacción 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: Principales Patrones - GRASP
  • 9. Diagramas de Interacción El patrón Experto [Larman 98] (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. Principales Patrones - GRASP
  • 10. Diagramas de Interacción El patrón Experto [Larman 98] (Ejemplo) 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 Principales Patrones - GRASP
  • 11. Diagramas de Interacción El patrón Experto [Larman 98] (Ejemplo) 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. Principales Patrones - GRASP
  • 12. Diagramas de Interacción El patrón Experto [Larman 98] (Ejemplo) En conclusión, para cumplir con la responsabilidad de conocer y dar el total de venta, se asignaron responsabilidades a tres clases de objetos: El cumplimiento de una responsabilidad requiere a menudo información distribuida en varias clases de objetos. (“Expertos Parciales” que colaboran en la tarea). Principales Patrones - GRASP Conoce el precio del producto EspecificacióndeProducto Conoce subtotal de la línea de producto VentasLineadeProducto Conocer Total de la Venta Venta Responsabilidad Clase
  • 13. Diagramas de Interacción 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. Principales Patrones - GRASP
  • 14. Diagramas de Interacción El patrón Creador [Larman 98] Principales Patrones - GRASP Creador Nombre Asignar a la clase B la responsabilidad de crear una instancia de la clase A en uno de los siguientes casos: Solución ¿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. Problema
  • 15. Diagramas de Interacción El patrón Creador [Larman 98] Principales Patrones - GRASP ¿Quién debería encargarse una instancia de VentasLineadeProductos? Ejemplo
    • 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.
    Solución Se brinda apoyo al bajo acoplamiento, lo cual supone menos dependencias respecto al mantenimiento y mejores oportunidades de reutilización Beneficios
  • 16. Diagramas de Interacció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. Principales Patrones - GRASP
  • 17. Diagramas de Interacción El patrón Creador [Larman 98] (Ejemplo) Principales Patrones - GRASP
  • 18. Diagramas de Interacción El patrón Controlador Principales Patrones - GRASP Controlador Nombre ¿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. Problema
  • 19. Diagramas de Interacción El patrón Controlador Principales Patrones - GRASP En la aplicación del punto de venta se dan varias operaciones del sistema, como terminarVenta(), pasarProducto(), efectuarPago(). Ejemplo 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. Solución Garantiza que la empresa o los procesos de dominio sean manejados por la capa de los objetos del dominio y no por la interfaz. Beneficios
  • 20. 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. Diagramas de Interacción Principales Patrones - GRASP
  • 21. Diagramas de Interacción El patrón Controlador (Ejemplo) ¿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: Principales Patrones - GRASP Representa un manejador artificial de todas las operaciones del sistema de un caso de uso. ManejadordeComprarProducto Representa algo en el mundo real que está activo y que puede intervenir en la tarea Cajero Representa la empresa u organización Tienda Representa al “sistema” global TPDV (Registro)
  • 22. Diagramas de Interacción El patrón Controlador (Ejemplo) Mensaje de evento del sistema Principales Patrones - GRASP :Cajero Articulo ID Cantidad Introducir Articulo Etc... Presiona Botón : JFrameVenta actionPerfomed(actionEvent) Capa Interfaz :??????? Capa Dominio introducirArticulo(articuloID,cant)
  • 23. Diagramas de Interacción El patrón Controlador (Ejemplo) 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 Principales Patrones - GRASP :ProcesarVentaManejador IntroduccirArticulo(id,cantidad) : Registro IntroduccirArticulo(id,cantidad)
  • 24. Diagramas de Interacción El patrón Controlador (Ejemplo) 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. Principales Patrones - GRASP
  • 25. Diagramas de Interacción El patrón Controlador (Ejemplo) 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. Principales Patrones - GRASP
  • 26. Diagramas de Interacción El patrón Bajo Acoplamiento [Larman 98] Principales Patrones - GRASP ¿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. Problema Bajo Acoplamiento Nombre Asignar una responsabilidad para mantener bajo acoplamiento. Solución
  • 27. Diagramas de Interacción El patrón Bajo Acoplamiento [Larman 98] Principales Patrones - GRASP -No afecta los cambios en otros componentes. -Fácil de entender de manera aislada. -Conveniente para reutilizar. Beneficios
  • 28. Diagramas de Interacción 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. Principales Patrones - GRASP
  • 29. Diagramas de Interacción El patrón Bajo Acoplamiento [Larman 98] (Ejemplo) 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. Principales Patrones - GRASP
  • 30. Diagramas de Interacción
    • El patrón Bajo Acoplamiento [Larman 98] (Ejemplo)
    • 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.
    Principales Patrones - GRASP
  • 31. Diagramas de Interacción El patrón Bajo Acoplamiento [Larman 98] (Ejemplo) 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. Principales Patrones - GRASP
  • 32. Diagramas de Interacción El patrón Alta Cohesión Principales Patrones - GRASP ¿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. Problema Alta Cohesión Nombre Asignar una responsabilidad de manera que la cohesión permanezca alta. Solución
  • 33. Diagramas de Interacción El patrón Alta Cohesión 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. Principales Patrones - GRASP -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. Beneficios
  • 34. Diagramas de Interacción
    • 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.
    Elaboración
  • 35.
    • 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