Capítulo 22. Herramientas UML y UML como un plano.

Capítulo 22. Herramientas UML y UML como un plano. Miguel RDZ. GUILLÉN CINVESTAV-Tamaulipas 22 de Oct del 2012 Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 1 / 65

1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 2 / 65

Capítulo 22. Herramientas UML y UML como un plano 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 3 / 65

Capítulo 22. Herramientas UML y UML como un plano No es conveniente especificar las herramientas UML a detalle. Este capítulo apunta a algunas características comunes y al uso de herramientas para UML como un plano. Existen 3 maneras en cómo las personas desearían aplicar UML: Como un boceto. (generación de diagramas) Como un plano. (aplica a ambos: generación de código y diagramas) Como un lenguaje de programación. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 4 / 65

Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 5 / 65

Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Ingeniería directa, inversa, y de ida y vuelta En la herramienta CASE (siglas en inglés para Computer Aided Software Engineering), la ingeniería directa se refiere a la generación de código a partir de diagramas; ingeniería inversa se refiere a la generación de diagramas desde código, y en la ingeniería de ida y vuelta existe una sincronización inmediata entre los diagramas UML y el código, cuando alguno de ellos es modificado. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 6 / 65

Capítulo 22. Herramientas UML y UML como un plano Qué buscar en una herramienta? 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 7 / 65

Capítulo 22. Herramientas UML y UML como un plano Qué buscar en una herramienta? Qué buscar en una herramienta? Primero, prueba herramientas gratuitas, sólo compra una herramienta después de haber probado muchas opciones libres. Una vez que hayas elegido, pruébala en un proyecto real con varios desarrolladores antes de tomar una decisión. Decide en base a los desarrolladores que la hayan usado por un largo periodo. Escoge la herramienta UML que se integre a tu IDE favorita. Escoge una herramienta UML que soporte ingeniería inversa. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 8 / 65

Capítulo 23. Actualización rápida de análisis 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 9 / 65

Capítulo 23. Actualización rápida de análisis En este capítulo se trata brevemente algunos de los cambios en los requerimientos y análisis de dominio. El modelado notable y algunos tips relacionados a los modelos de dominio Monopoly y NextGen. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 10 / 65

Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 11 / 65

Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: NextGen Casos de uso: No es necesario el refinamiento para los casos de uso en esta iteración. Sin embargo es recomendado un segundo taller breve (un día o dos) de requerimientos para esta iteración, cerca del final de la iteración 1 y nuevamente al final de la iteración 2. Diagramas de Secuencias del Sistema: Esta iteración agrega soporte para sistemas terceros con variedad de interfaces como el calculador de impuestos. El sistema se comunicará remotamente con sistemas externos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 12 / 65

Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: NextGen Ejemplo: Se muestra un SSD para un escenario de pago por crédito, que requiere la colaboración de varios sistemas externos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 13 / 65

Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: NextGen Modelo de dominio: el modelador puede estimar si un conjunto de nuevos requerimientos tendrán mayor o menor impacto en el modelo de dominio en términos de nuevos conceptos, asociaciones y atributos. En contraste con la iteración anterior, los requerimientos que se abordan en esta ocasión no implican muchos conceptos nuevos de dominio. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 14 / 65

Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: NextGen Contratos de operaciones del sistema: En esta iteración no son consideradas nuevas operaciones de sistema, y los contratos no son requeridos. En todo caso, los contratos son solo una opción a considerar cuando el detalle de precisión que ellos ofrecen representa una mejora sobre las descripciones de los casos de uso. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 15 / 65

Capítulo 23. Actualización rápida de análisis Caso de estudio: Monopoly 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 16 / 65

Capítulo 23. Actualización rápida de análisis Caso de estudio: Monopoly Caso de estudio: Monopoly Casos de uso: son omitidos, por las reglas del juego, No se requiere actualización del SSD y no son escritos los contratos de operaciones. Modelo de dominio: Los conceptos Square, GoSquare, IncomeTaxSquare, y GoToJailSquare son todos variaciones de Square, en esta situación, es posible (y frecuentemente útil) organizarlos en herencia de clases en donde la superclase Square representa un concepto más general y las sub clases más especificas. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 17 / 65

Capítulo 23. Actualización rápida de análisis Caso de estudio: Monopoly Caso de estudio: Monopoly Herencia: Generalización: es la actividad de identificar concordancia entre conceptos y definir relaciones superclases (conceptos generales) y subclases (conceptos especializados). Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 18 / 65

Capítulo 23. Actualización rápida de análisis Caso de estudio: Monopoly Caso de estudio: Monopoly Cuándo mostrar subclases? Cree una subclase conceptual de una superclase cuando: La subclase tiene atributos adicionales de interés. La subclase tiene asociaciones adicionales de interés. La subclase está operando, manejado, reaccionó a, o manipulado de manera diferente que la superclase de otras subclases, de maneras notables. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 19 / 65

Capítulo 24. Iteración 2 - Más patrones 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 20 / 65

Capítulo 24. Iteración 2 - Más patrones En esta iteración, los casos de estudio enfatizan: Diseño esencial de objetos. El uso de patrones para crear diseño sólidos. Aplicar UML para visualizar modelos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 21 / 65

Capítulo 24. Iteración 2 - Más patrones Iteración 2 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 22 / 65

Capítulo 24. Iteración 2 - Más patrones Iteración 2 Iteración 2 Cuando la iteración 1 termina, lo siguiente tiene que haberse cumplido: Todo el software ha sido rigorosamente probado. Los consumidores han evaluado el sistema parcial, para obtener retroalimentación para adaptaciones y clarificación de requerimientos. El sistema, a través de sus subsistemas, ha sido completamente integrado y estabilizado como una liberación base interna. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 23 / 65

Capítulo 24. Iteración 2 - Más patrones Iteración 2 Iteración 2 Para los casos de estudio en la iteración 2 en gran parte ignora los análisis de requerimientos y dominio y se enfoca al diseño de objetos con responsabilidades y GRASP. La aplicación NextGen POS maneja muchos requerimientos interesantes: Soporte a variaciones en servicios externos, por ejemplo diferentes calculadores de impuestos pueden ser conectados al sistema. Diferentes reglas de fijación de precios. Diseño para refrescar la ventana de interfaz cuando la venta total cambia. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 24 / 65

Capítulo 24. Iteración 2 - Más patrones Iteración 2 Iteración 2 Los requerimientos adicionales para la segunda iteración de la aplicación de Monopoly incluyen: Cada jugador recibe $1500 al inicio del juego. Considerando que el juego tiene una cantidad ilimitada de dinero. Cuando un jugador cae en el recuadro avanzar, Recibe $200. Cuando un jugador cae en el recuadro ir a prisión, se mueve al recuadro Prisión. Cuando un jugador cae en el recuadro impuesto, el jugador paga un mínimo de $200 o 10 % de su valor. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 25 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 26 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 27 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades En capítulos anteriores, aplicamos 5 patrones GRASP; Información de experto, creador, alta cohesión, bajo acoplamiento y controlador. Los cuatro restantes se cubrirán en este capítulo y son: Polimorfismo Indirección Fabricación pura Variaciones protegidas Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 28 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Polimorfismo: Problema: Cómo controlar alternativas basadas en tipo? Cómo crear componentes de software conectables? Viendo componentes en relaciones cliente servidor, cómo puede reemplazar un componente servidor con otro, sin afectar al cliente? Solución: Polimorfismo: dar el mismo nombre a servicios en diferentes objetos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 29 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Ejemplo: Cómo soportar Calculadores de impuestos terceros? En la aplicación NextGen hay múltiples calculadores de impuestos externos que deben de ser soportados. Qué objeto debería ser responsable de manejar las variaciones en las interfaces externas? Ya que el comportamiento de la calculadora varía según el tipo de calculador, por polimorfismo podemos asignar responsabilidades para adaptación a diferentes calculadores (o adaptadores calculadores). Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 30 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Cada método gettaxes toma un objeto Venta como parámetro, por lo que el calculador puede analizar la venta, la implementación de cada método gettaxex será diferente. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 31 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Problema Monopoly: Cómo diseñar acciones de Square diferentes? El principio nos aconseja crear una operación polimórfica para cada tipo en el que el comportamiento varíe. Esto varía en los tipos (clases) RegularSquare, GoSquare, etc. Cual es la operación que varía? Es la que sucede cuando un jugador cae en una casilla. Por polimorfismo, vamos a crear una clase separada para cada tipo de Square, e implementa al método landedon en cada uno. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 32 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 33 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades El polimorfismo es un principio fundamental en el diseño de cómo un sistema está organizado para manejar variaciones similares. Un diseño basado en la asignación de responsabilidades por polimorfismo puede ser fácilmente ampliado para incluir las nuevas variaciones. Por ejemplo, la adición de una nueva clase adaptadora de calculador con su propio método polimórfico gettaxes tendrá un impacto menor sobre el diseño existente. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 34 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Fabricación pura Problema: Qué objeto debe tener la responsabilidad, cuando no se quiere violar la alta cohesión y el bajo acoplamiento, pero las soluciones ofrecidas por experto (por ejemplo) no son apropiadas? Solución: Asignar un conjunto altamente cohesivo de responsabilidades a una clase artificial que no represente un problema de dominio, para soportar alta cohesión, bajo acoplamiento y reutilización. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 35 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Problema NextGen: Guardar un objeto venta en la Base de Datos. Suponga que se necesita guardar instancias de venta en una base de datos relacional. Por información de experto, hay justificación para asignar la responsabilidad a la clase Venta, pero considere: Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 36 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades La tarea requiere de un número relativamente grande de operaciones de base de datos, Lo que provoca que la clase Venta pierda cohesión. La clase venta tiene que estar acoplada a una interfaz de base de datos (como JDBC en java), por lo que su acoplamiento aumenta. Guardar objetos es una tarea general a la que muchas clases pudieran necesitar. Por lo que habrá poco reúso o mucha duplicidad en otras clases. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 37 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Una solución razonable es crear una nueva clase que sea responsable de guardar objetos en una base de datos; esta clase es Fabricación Pura. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 38 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades La fabricación pura resuelve los problemas de diseño: La venta se mantiene bien diseñado, con alta cohesión y bajo acoplamiento. La clase PersistentStorage en sí es relativamente cohesiva, ya que tiene el único fin de almacenar o la inserción de objetos en un medio de almacenamiento persistente. La clase PersistentStorage es un objeto muy genérico y reutilizable. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 39 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Problema Monopoly: Manejo de los dados En el diseño actual, el jugador tira todos los dados y suma los totales. Dados son objetos muy generales, que puedan utilizarse en muchos juegos. Al poner esta responsabilidad de rodando y sumando en un jugador de Monopoly, el servicio de sumar no es generalizado para su uso en otros juegos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 40 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Pero, la elección de cualquier otro objeto inspirado en el modelo de dominio de juego de Monopoly nos lleva a los mismos problemas. Y eso nos lleva a hacer fabricación pura para proporcionar convenientemente los servicios relacionados. Aunque no existe un vaso para dados de Monopoly, muchos juegos hacen uso de uno. Por lo tanto, se propone una fabricación pura denominada Cup. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 41 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 42 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Alta cohesión porque las responsabilidades se incluyen en una clase de grano fino que sólo se centra en un conjunto muy específico de tareas relacionadas. Potencial de reutilización puede aumentar debido a la presencia de clases de grano fino de fabricación pura cuyas responsabilidades tienen usos en otras aplicaciones. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 43 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Indirección Problema: Dónde asignar responsabilidad, para evitar acoplamiento directo entre dos o más cosas? Cómo desacoplar objetos de tal manera que exista un acoplamiento bajo y un alto potencial de reúso? Solución: Asignar la responsabilidad a un objeto intermediario para mediar entre otros componentes o servicios y no estén directamente acoplados. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 44 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Ejemplo: Adaptador- Calculador de impuestos, estos objetos actúan como intermediarios a clases externas de cálculo de impuestos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 45 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades En el ejemplo de fabricación pura para el desacoplamiento de la venta y los servicios de bases de datos mediante la introducción de una clase PersistentStorage es también un ejemplo de asignación de responsabilidades que apoya la indirección. La clase PersistentStorage actua como un intermediario entre la Venta y base de datos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 46 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Variaciones Protegidas Problema: Cómo diseñar objetos, subsistemas y sistemas de tal manera que las variaciones en estos elementos no tengan un impacto indeseable en otros? Solución: Identificar los puntos de variación o inestabilidad; asignar responsabilidades para crear una interfaz estable alrededor de ellos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 47 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Por ejemplo, el anterior problema de calculador de impuestos externo y su solución con polimorfismo ilustra las Variaciones Protegidas. El punto de inestabilidad o variación son las diferentes interfaces de calculadoras externas. El sistema de POS tiene que ser capaz de integrarse con muchos sistemas calculadores de impuestos existentes, y también con los futuros calculadores que no están aún en existencia. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 48 / 65

Capítulo 25. GRASP Más Objetos con responsabilidades Extensiones requeridas para las nuevas variaciones son fáciles de agregar. Nuevas implementaciones pueden ser introducidos sin afectar a los clientes. El acoplamiento se reduce. El impacto o el costo de los cambios se puede bajar. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 49 / 65

Capítulo 26. Aplicando diseño de patrones GoF 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 50 / 65

Capítulo 26. Aplicando diseño de patrones GoF Este capítulo explora diseño orientado a objetos para la realización de casos de uso para el caso de estudio NextGen, proporcionando soporte para servicios externos de terceros cuyas interfaces pueden variar, las reglas de fijación de precios de productos más complejos, y las reglas de negocio adaptables. El énfasis es mostrar cómo aplicar el Gang-de-Four (GoF), y los patrones GRASP más básicos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 51 / 65

Capítulo 26. Aplicando diseño de patrones GoF 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 52 / 65

Capítulo 26. Aplicando diseño de patrones GoF Adaptador: El problema NextGen explorado en motivar al patrón de polimorfismo y su solución es más específicamente un ejemplo del modelo de adaptador GoF. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 53 / 65

Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 54 / 65

Capítulo 26. Aplicando diseño de patrones GoF Fábrica: El adaptador plantea un nuevo problema en el diseño: En la solución anterior del patrón adaptador para los servicios externos con interfaces diferentes, Quién crea los adaptadores? Y cómo determinar qué clase de adaptador crear, como TaxMaster-Adapter o GoodAsGoldTaxProAdapter? Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 55 / 65

Capítulo 26. Aplicando diseño de patrones GoF Una alternativa común es aplicar el patrón de la fábrica, en la que se define un objeto de fabricación pura para crear objetos. Los objetos de fábrica tienen varias ventajas: Separar la responsabilidad de creaciones complejas en objetos de ayuda cohesivos. Ocultar lógica de creación potencialmente compleja. Permitir la introducción de estrategias para mejorar el rendimiento de gestión de memoria, como cacheo de objetos o reciclaje. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 56 / 65

Capítulo 26. Aplicando diseño de patrones GoF Singleton: El Factory plantea otro problema nuevo en el diseño: Quién crea la propia fábrica, y cómo se accede? Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 58 / 65

Capítulo 26. Aplicando diseño de patrones GoF El patrón Singleton se utiliza a menudo para los objetos y los objetos fábrica y facade (otro patrón GoF que será discutido). Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 59 / 65

Capítulo 26. Aplicando diseño de patrones GoF Estrategia: Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 61 / 65

Capítulo 26. Aplicando diseño de patrones GoF Facade: Una fachada es un objeto "front-end"que es el único punto de entrada para los servicios de un subsistema, la aplicación y otros componentes del subsistema son privados y no puede ser visto por los componentes externos. Fachada ofrece Variaciones protegidas de los cambios en la implementación de un subsistema. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 63 / 65

Capítulo 26. Aplicando diseño de patrones GoF Gracias! Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del 2012 65 / 65