martes, 4 de febrero de 2014



Patrones y Anti patrones 

de Diseño y Gestión de Proyectos.

PATRONES.
 Los patrones de diseño son soluciones a los problemas recurrentes de diseño de software que encontramos una y otra vez en el desarrollo de aplicaciones.
 • Se clasifican en tres grupos:
 – De creación (Creational), 
– De estructura (Structural) 
– De comportamiento. (Behavioral).
http://arqsoftunellez2012.wikispaces.com/Patrones+de+Dise%C3%B1o




Las características de un patrón son tres:


  • Contexto: situación en la que se presenta el problema de diseño.
  • Problema: descripción del problema a resolver, y enumeración de las fuerzas a equilibrar (requisitos no funcionales como eficiencia, portabilidad, cambiabilidad, …).
  • Solución: conjunto de medidas que se han de tomar, como crear alguna clase, atributo o método, nuevos comportamientos entre clases, …


Otros tipos de patrones...

Los patrones pueden encontrarse en todas las áreas de la ingeniería informática. A continuación, enumeraremos una serie de áreas donde existen patrones aceptados y conocidos en la industria:
  • Idiomas: Son específicos del lenguaje de programación. Describen cómo implementar ciertos aspectos de un problema utilizando las características de un lenguaje de programación.
  • Patrones de Análisis: Los patrones enumerados en el libro Analysis Patterns: Reusable Object Models[Fowler97] provienen de diversos dominios, incluyendo las áreas de la salud, servicios financieros y contabilidad. Cada uno de los patrones se describen en forma textual y con una simple notación pre-UML.
  • Patrones de Integración de Aplicaciones: Patrones para integración de aplicaciones. La obra más popular al respecto es Enterprise Integration Patterns [Hophe03], de Gregor Hophe y Bobby Woolf.
  • Patrones de UI: Patrones referentes a interfaces de usuarios. Existen distintas categorías bien diferenciadas: algunas se encargan de detalles relacionados con la cognición, memoria a corto plazo y mejoras en la experiencia del usuario, mientras que otros describen técnicas de ingeniería para crear interfaces de usuario.
  • Patrones de Pruebas: Patrones para diseñar y realizar pruebas.
ANTI PATRONES.

Un anti patrón de diseño es un patrón de diseño que invariablemente conduce a una mala solución para un problema por algun u otro motivo. Al documentarse los anti patrones, además de los patrones de diseño, se dan argumentos a los diseñadores de sistemas para no escoger malos caminos, partiendo de documentación disponible en lugar de simplemente la intuición.
Los tipos de anti patrones que hay son tres:
  1. Anti patrones de desarrollo de software
  2. Anti patrones de arquitectura de software
  3. Antipatrones de gestión de proyectos de software.



         PATRONES               
   IMAGENES             
Patrones de creación
  • Abstract Factory. Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas.
  • Builder. Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones.
  • Factory Method. Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos.
  • Prototype. Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo.
  • Singleton. Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.










































Patrones estructurales
  • Adapter. Convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.
  • Bridge. Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente.
  • Composite. Combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.
  • Decorator. Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.
  • Facade. Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar.
  • Flyweight. Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.
  • Proxy. Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.






























Patrones de comportamiento
  • Chain of Responsibility. Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto.
  • Command. Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones.
  • Interpreter. Dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje.
  • Iterator. Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.
  • Mediator. Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente.
  • Memento. Representa y externaliza el estado interno de un objeto sin violar la encapsulación, de forma que éste puede volver a dicho estado más tarde.
  • Observer. Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.
  • State. Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto.
  • Strategy. Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan.
  • Template Method. Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura.
  • Visitor. Representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.







ANTI PATRONES                                            
                     IMÁGENES                                        

Humo y espejos (smoke and mirrors):
 Mostrar cómo será una funcionalidad antes de 
que esté implementada.
Mala gestión  (bad management):
 Gestionar un proyecto sin tener suficientes
 conocimientos sobre la materia

Software inflado (software bloat):
 Permitir que las sucesivasversiones de un
sistema exijan cada vez más recursos