jueves, 28 de mayo de 2009

UML

El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.

  • Diagramas de Casos de Uso para modelar los procesos ’business’.
  • Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
  • Diagramas de Colaboración para modelar interacciones entre objetos.
  • Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
  • Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
  • Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
  • Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
  • Diagramas de Componentes para modelar componentes.
  • Diagramas de Implementación para modelar la distribución del sistema.

Visitor

Nombre del patrón
Visitor

Clasificación del patrón
De comportamiento

Intención
Permite incluir nuevos métodos a una clase sin tener que modificarla.

Aplicabilidad
Recomendado para:

  • Estructuras jerárquicas (arboles).
  • Muchas clases poco relacionadas entre sí.
  • Estructura de objetos con diferentes interfaces y posibilidad de ampliación.
  • Estructura con altas probabilidades de incluir de nuevos métodos.
  • Compiladores, intérpretes.

No recomendado para:

  • Sistemas con cambios constantes en estructura global.
  • Estructuras poco jerárquicas.

Estructura

Participantes
Visitor. Declara una operación visitar para cada clase de operación ConcreteElement de la estructura de objetos.
ConcreteVisitor. Implementa cada operación declarada por Visitor.
Element. Define una operación que le permite aceptar la visita de un Visitor.
ConcreteElement. Implementa la operación Aceptar que se limita a invocar su correspondiente método del Visitor.
ObjectStructure. Puede enumerar sus elementos y puede proporcionar una interfaz de alto nivel para permitir al Visitor visitar sus elementos.

Colaboraciones

Implementación

Al implementar el patron Visitor debemos tenr en cuenta:

  • El cliente crea una instancia de un ConcreteVisitor y lo utiliza para recorrer su estructura.
  • Las clases visitadas por un mismo Visitor pueden no estar relacionadas entre sí a través de la herencia.
  • El Visitor facilita añadir nuevas operaciones.
  • Agrupa operaciones relacionas y separa las que no lo están.
  • Añadir nuevas clases a la estructura resulta muy costoso.

Patrones relacionados
Composite.
Interpreter.


Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://kybele.escet.urjc.es/documentos/SI/Patrones/23_Visitor.ppt
http://dmi.uib.es/~yuhua/APOO07-08/Presentation/visitor.pdf

Template Method

Nombre del patrón
Template Method (Metodo Plantilla)

Clasificación del patrón
De comportamiento

Intención
Define en una clase abstracta el esqueleto o los pasos de un algoritmo y cada subclase implementa la estructura concreta de cada uno de los pasos.

Motivación
Supongamos que tenemos una aplicación definida por dos clases, la clase “Application” y la clase “Document”. La clase “Application” se ocupa de abrir documentos almacenados en un formato externo (un fichero). Un objeto de la clase “Document”, representa la información en un documento, una vez que se ha leído del fichero.
La operación OpenDocument() permite abrir y leer un documento.
Se trata de un template method. Define su estructura mediante operaciones abstractas, las cuales serán implementadas por las clases hijas para determinar el comportamiento específico de cada una de ellas.

Aplicabilidad
Se usa para implementar partes invariantes de un algoritmo, y dejar a las subclases implementar el comportamiento que puede variar.
Cuando tenemos un comportamiento común en diferentes clases, puede ser refactorizado para evitar la duplicación de código. Para ello se identifican las partes diferentes del código, se separan mediante nuevas operaciones y se reemplazan con un método que hace uso de ellas.
Para controlar la redefinición de operaciones en las subclases, es posible definir un método Template que llama a una operación “Hook” dentro de la operación que queremos evitar su redefinición, permitiendo únicamente la extensión de la operación “Hook”.
Una subclase puede heredar el comportamiento de una clase padre redefiniendo la operación y llamando a la operación del padre explícitamente:

Estructura

Participantes
AbstractClass.
Implementa un método plantilla que define el esqueleto de un algoritmo y define métodos abstractos que implementan las subclases concretas.
ConcreteClass. Implementa los métodos abstractos para realizar los pasos del algoritmo que son específicos de la subclase.

Colaboraciones
Las clases concretas confían en que la clase abstracta implemente la parte fija del algoritmo

Consecuencias
Ventajas y desventajas:

  • Favorece la reutilización del código. Muy útiles para construir bibliotecas, pues ayuda a factorizar el comportamiento común de las clases.
  • Lleva a una estructura de control invertido (Principio de Hollywood): la superclase base invoca los métodos de las subclases.

Implementación

  • En C++. Las operaciones primitivas pueden definirse como protegidas, permitiendo a las clases hijas su implementación. Tendrán que usarse únicamente dentro del método Template, el cual no debería ser redefinido, por lo que nunca se declarará como virtual. Las operaciones primitivas que obligatoriamente hay que definir, se declaran como virtuales puras.
  • Minimizar las operaciones primitivas. Es importante que el número de operaciones primitivas sea pequeño, cuantas más operaciones haya que definir, mas tedioso será el trabajo que conlleva crear nuevas clases.
  • Convenios de nombres. Se debe poder diferenciar las operaciones que podrían ser redefinidas con las que tienen que ser definidas, por ejemplo añadiendo un prefijo a sus nombres.

Usos Conocidos
Se suelen encontrar en casi todas las clases abstractas

Patrones relacionados
Strategy. El Strategy usa la composición para cambiar todo el algoritmo, los métodos plantilla usan la herencia para cambiar parte de un algoritmo.
Factory Method. Los métodos fábrica suelen llamarse desde métodos plantilla

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://www.lsi.us.es/docencia/get.php?id=1310
http://dmi.uib.es/~yuhua/APOO07-08/Presentation/IteratorTemM.pdf
http://kybele.escet.urjc.es/docencia/SI/2006-2007/Material/Patrones/22_TemplateMethod.ppt