Capítulo 22. Herramientas UML y UML como un plano.ertello/swe/sesion14.pdfEste capítulo apunta a...

Capítulo 22. Herramientas UML y UML como unplano.

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 planoIntroducciónIngeniería directa, inversa, y de ida y vuelta¿Qué buscar en una herramienta?

2 Capítulo 23. Actualización rápida de análisisIntroducciónCaso de estudio: NextGenCaso de estudio: Monopoly

3 Capítulo 24. Iteración 2 - Más patronesIntroducciónIteración 2

4 Capítulo 25. GRASP Más Objetos con responsabilidadesPatrones GRASP

5 Capítulo 26. Aplicando diseño de patrones GoFIntroducciónPatrones GoF


Capítulo 22. Herramientas UML y UML como un plano Introducción







Capítulo 22. Herramientas UML y UML como un plano Introducción

Introducción

No es conveniente especificar las herramientas UML a detalle.Este capítulo apunta a algunas características comunes y al usode 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 ydiagramas)Como un lenguaje de programación.


Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta







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 AidedSoftware Engineering), la ingeniería directa se refiere a lageneración de código a partir de diagramas; ingeniería inversa serefiere a la generación de diagramas desde código, y en laingeniería de ida y vuelta existe una sincronización inmediataentre los diagramas UML y el código, cuando alguno de ellos esmodificado.


Capítulo 22. Herramientas UML y UML como un plano ¿Qué buscar en una herramienta?







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 unaherramienta después de haber probado muchas opciones libres.

Una vez que hayas elegido, pruébala en un proyecto real convarios desarrolladores antes de tomar una decisión. Decide enbase a los desarrolladores que la hayan usado por un largoperiodo.

Escoge la herramienta UML que se integre a tu IDE favorita.

Escoge una herramienta UML que soporte ingeniería inversa.


Capítulo 23. Actualización rápida de análisis Introducción







Capítulo 23. Actualización rápida de análisis Introducción

Introducción

En este capítulo se trata brevemente algunos de los cambios enlos requerimientos y análisis de dominio. El modelado notable yalgunos tips relacionados a los modelos de dominio Monopoly yNextGen.


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 deuso en esta iteración. Sin embargo es recomendado un segundotaller 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 laiteración 2.

Diagramas de Secuencias del Sistema: Esta iteración agregasoporte para sistemas terceros con variedad de interfaces comoel calculador de impuestos. El sistema se comunicaráremotamente con sistemas externos.




Ejemplo: Se muestra un SSD para un escenario de pago porcrédito, que requiere la colaboración de varios sistemas externos.




Modelo de dominio: el modelador puede estimar si un conjunto denuevos requerimientos tendrán mayor o menor impacto en elmodelo de dominio en términos de nuevos conceptos,asociaciones y atributos. En contraste con la iteración anterior, losrequerimientos que se abordan en esta ocasión no implicanmuchos conceptos nuevos de dominio.




Contratos de operaciones del sistema: En esta iteración no sonconsideradas nuevas operaciones de sistema, y los contratos noson requeridos. En todo caso, los contratos son solo una opción aconsiderar cuando el detalle de precisión que ellos ofrecenrepresenta una mejora sobre las descripciones de los casos deuso.


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 serequiere actualización del SSD y no son escritos los contratos deoperaciones.

Modelo de dominio: Los conceptos Square, GoSquare,IncomeTaxSquare, y GoToJailSquare son todos variaciones deSquare, en esta situación, es posible (y frecuentemente útil)organizarlos en herencia de clases en donde la superclaseSquare representa un concepto más general y las sub clases másespecificas.




Herencia:

Generalización: es la actividad de identificar concordancia entreconceptos y definir relaciones superclases (conceptos generales)y subclases (conceptos especializados).




¿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 manipuladode manera diferente que la superclase de otras subclases, demaneras notables.


Capítulo 24. Iteración 2 - Más patrones Introducción







Capítulo 24. Iteración 2 - Más patrones Introducción

Introducción

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.


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

Todo el software ha sido rigorosamente probado.Los consumidores han evaluado el sistema parcial, para obtenerretroalimentación para adaptaciones y clarificación derequerimientos.El sistema, a través de sus subsistemas, ha sido completamenteintegrado y estabilizado como una liberación base interna.



Iteración 2

Para los casos de estudio en la iteración 2 en gran parte ignoralos análisis de requerimientos y dominio y se enfoca al diseño deobjetos con responsabilidades y GRASP.

La aplicación NextGen POS maneja muchos requerimientosinteresantes:

Soporte a variaciones en servicios externos, por ejemplo diferentescalculadores 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 totalcambia.



Iteración 2

Los requerimientos adicionales para la segunda iteración de laaplicación de Monopoly incluyen:

Cada jugador recibe $1500 al inicio del juego. Considerando que eljuego 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 alrecuadro Prisión.Cuando un jugador cae en el recuadro impuesto, el jugador pagaun mínimo de $200 o 10 % de su valor.


Capítulo 25. GRASP Más Objetos con responsabilidades







Capítulo 25. GRASP Más Objetos con responsabilidades Patrones GRASP








Patrones GRASP

En capítulos anteriores, aplicamos 5 patrones GRASP;Información de experto, creador, alta cohesión, bajo acoplamientoy controlador. Los cuatro restantes se cubrirán en este capítulo yson:

PolimorfismoIndirecciónFabricación puraVariaciones protegidas



Patrones GRASP

Polimorfismo:Problema: ¿Cómo controlar alternativas basadas en tipo? ¿Cómocrear componentes de software conectables? Viendo componentesen relaciones cliente servidor, ¿cómo puede reemplazar uncomponente servidor con otro, sin afectar al cliente?Solución: Polimorfismo: dar el mismo nombre a servicios endiferentes objetos.



Patrones GRASP

Ejemplo:

¿Cómo soportar Calculadores de impuestos terceros? En laaplicación NextGen hay múltiples calculadores de impuestosexternos que deben de ser soportados.

¿Qué objeto debería ser responsable de manejar las variacionesen las interfaces externas? Ya que el comportamiento de lacalculadora varía según el tipo de calculador, por polimorfismopodemos asignar responsabilidades para adaptación a diferentescalculadores (o adaptadores calculadores).



Patrones GRASP

Cada método getTaxes toma un objeto Venta como parámetro,por lo que el calculador puede analizar la venta, laimplementación de cada método getTaxex será diferente.



Patrones GRASP

Problema Monopoly: ¿Cómo diseñar acciones de Squarediferentes?

El principio nos aconseja crear una operación polimórfica paracada tipo en el que el comportamiento varíe. Esto varía en lostipos (clases) RegularSquare, GoSquare, etc. ¿Cual es laoperación que varía? Es la que sucede cuando un jugador cae enuna casilla. Por polimorfismo, vamos a crear una clase separadapara cada tipo de Square, e implementa al método landedOn encada uno.



Patrones GRASP



Patrones GRASP

El polimorfismo es un principio fundamental en el diseño de cómoun sistema está organizado para manejar variaciones similares.Un diseño basado en la asignación de responsabilidades porpolimorfismo puede ser fácilmente ampliado para incluir lasnuevas variaciones. Por ejemplo, la adición de una nueva claseadaptadora de calculador con su propio método polimórficogetTaxes tendrá un impacto menor sobre el diseño existente.



Patrones GRASP

Fabricación pura

Problema: ¿Qué objeto debe tener la responsabilidad, cuando nose quiere violar la alta cohesión y el bajo acoplamiento, pero lassoluciones ofrecidas por experto (por ejemplo) no sonapropiadas?

Solución: Asignar un conjunto altamente cohesivo deresponsabilidades a una clase artificial que no represente unproblema de dominio, para soportar alta cohesión, bajoacoplamiento y reutilización.



Patrones GRASP

Problema NextGen: Guardar un objeto venta en la Base de Datos.

Suponga que se necesita guardar instancias de venta en unabase de datos relacional. Por información de experto, hayjustificación para asignar la responsabilidad a la clase Venta, peroconsidere:



Patrones GRASP

La tarea requiere de un número relativamente grande deoperaciones de base de datos, Lo que provoca que la clase Ventapierda cohesión.

La clase venta tiene que estar acoplada a una interfaz de base dedatos (como JDBC en java), por lo que su acoplamiento aumenta.

Guardar objetos es una tarea general a la que muchas clasespudieran necesitar. Por lo que habrá poco reúso o muchaduplicidad en otras clases.



Patrones GRASP

Una solución razonable es crear una nueva clase que searesponsable de guardar objetos en una base de datos; esta clasees Fabricación Pura.



Patrones GRASP

La fabricación pura resuelve los problemas de diseño:La venta se mantiene bien diseñado, con alta cohesión y bajoacoplamiento.La clase PersistentStorage en sí es relativamente cohesiva, ya quetiene el único fin de almacenar o la inserción de objetos en unmedio de almacenamiento persistente.La clase PersistentStorage es un objeto muy genérico y reutilizable.



Patrones GRASP

Problema Monopoly: Manejo de los dados

En el diseño actual, el jugador tira todos los dados y suma lostotales. Dados son objetos muy generales, que puedan utilizarseen muchos juegos. Al poner esta responsabilidad de rodando ysumando en un jugador de Monopoly, el servicio de sumar no esgeneralizado para su uso en otros juegos.



Patrones GRASP

Pero, la elección de cualquier otro objeto inspirado en el modelode dominio de juego de Monopoly nos lleva a los mismosproblemas. Y eso nos lleva a hacer fabricación pura paraproporcionar convenientemente los servicios relacionados.

Aunque no existe un vaso para dados de Monopoly, muchosjuegos hacen uso de uno. Por lo tanto, se propone una fabricaciónpura denominada Cup.



Patrones GRASP



Patrones GRASP

Alta cohesión porque las responsabilidades se incluyen en unaclase de grano fino que sólo se centra en un conjunto muyespecífico de tareas relacionadas.

Potencial de reutilización puede aumentar debido a la presenciade clases de grano fino de fabricación pura cuyasresponsabilidades tienen usos en otras aplicaciones.



Patrones GRASP

Indirección

Problema: ¿Dónde asignar responsabilidad, para evitaracoplamiento directo entre dos o más cosas? ¿Cómo desacoplarobjetos de tal manera que exista un acoplamiento bajo y un altopotencial de reúso?

Solución: Asignar la responsabilidad a un objeto intermediariopara mediar entre otros componentes o servicios y no esténdirectamente acoplados.



Patrones GRASP

Ejemplo: Adaptador- Calculador de impuestos, estos objetosactúan como intermediarios a clases externas de cálculo deimpuestos.



Patrones GRASP

En el ejemplo de fabricación pura para el desacoplamiento de laventa y los servicios de bases de datos mediante la introducciónde una clase PersistentStorage es también un ejemplo deasignación de responsabilidades que apoya la indirección. Laclase PersistentStorage actua como un intermediario entre laVenta y base de datos.



Patrones GRASP

Variaciones Protegidas

Problema: ¿Cómo diseñar objetos, subsistemas y sistemas de talmanera que las variaciones en estos elementos no tengan unimpacto indeseable en otros?

Solución: Identificar los puntos de variación o inestabilidad;asignar responsabilidades para crear una interfaz establealrededor de ellos.



Patrones GRASP

Por ejemplo, el anterior problema de calculador de impuestosexterno y su solución con polimorfismo ilustra las VariacionesProtegidas. El punto de inestabilidad o variación son lasdiferentes interfaces de calculadoras externas. El sistema de POStiene que ser capaz de integrarse con muchos sistemascalculadores de impuestos existentes, y también con los futuroscalculadores que no están aún en existencia.



Patrones GRASP

Extensiones requeridas para las nuevas variaciones son fácilesde agregar.

Nuevas implementaciones pueden ser introducidos sin afectar alos clientes.

El acoplamiento se reduce.

El impacto o el costo de los cambios se puede bajar.


Capítulo 26. Aplicando diseño de patrones GoF Introducción







Capítulo 26. Aplicando diseño de patrones GoF Introducción

Introducción

Este capítulo explora diseño orientado a objetos para larealización de casos de uso para el caso de estudio NextGen,proporcionando soporte para servicios externos de terceros cuyasinterfaces pueden variar, las reglas de fijación de precios deproductos más complejos, y las reglas de negocio adaptables. Elénfasis es mostrar cómo aplicar el Gang-de-Four (GoF), y lospatrones GRASP más básicos.


Capítulo 26. Aplicando diseño de patrones GoF Patrones GoF








Patrones GoF

Adaptador:

El problema NextGen explorado en motivar al patrón depolimorfismo y su solución es más específicamente un ejemplodel modelo de adaptador GoF.



Patrones GoF



Patrones GoF

Fábrica:

El adaptador plantea un nuevo problema en el diseño: En lasolución anterior del patrón adaptador para los servicios externoscon interfaces diferentes, ¿Quién crea los adaptadores? Y ¿cómodeterminar qué clase de adaptador crear, comoTaxMaster-Adapter o GoodAsGoldTaxProAdapter?



Patrones GoF

Una alternativa común es aplicar el patrón de la fábrica, en la quese 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 deayuda cohesivos.Ocultar lógica de creación potencialmente compleja.Permitir la introducción de estrategias para mejorar el rendimientode gestión de memoria, como cacheo de objetos o reciclaje.



Patrones GoF



Patrones GoF

Singleton:

El Factory plantea otro problema nuevo en el diseño: ¿Quién creala propia fábrica, y cómo se accede?



Patrones GoF

El patrón Singleton se utiliza a menudo para los objetos y losobjetos fábrica y facade (otro patrón GoF que será discutido).



Patrones GoF



Patrones GoF

Estrategia:



Patrones GoF



Patrones GoF

Facade:

Una fachada es un objeto "front-end"que es el único punto deentrada para los servicios de un subsistema, la aplicación y otroscomponentes del subsistema son privados y no puede ser vistopor los componentes externos. Fachada ofrece Variacionesprotegidas de los cambios en la implementación de unsubsistema.



Patrones GoF



Patrones GoF

Gracias!


Capítulo 22. Herramientas UML y UML como un plano.ertello/swe/sesion14.pdfEste capítulo apunta a...

Documents

Transcript of Capítulo 22. Herramientas UML y UML como un plano.ertello/swe/sesion14.pdfEste capítulo apunta a...