JOSE GREGORIO SUAREZ P. C.I.

Nº 8724285

28/11/09
• Patrones de diseño, componentes, diseño de interfases del sistema, notación de diseño.
• Medición de los atributos del diseño.

MI COMENTARIO: (ANALISIS)
PATRON DE DISEÑO:
DE ACUERDO A LAS SIGUIENTES DEFINICIONES, ENTIENDO QUE UN
PATRON DE DISEÑO: es o son soluciones comunes a problemas de
diseño de software orientado a objetos y que además poseen ciertas
características de efectividad para resolver ese problema, reusabilidad:
que puede ser reutilizado o aplicado en otros diseños o problemas, si
se quiere.
http://es.wikipedia.org/wiki/Patrones_de_dise%C3%B1o

http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php

Según el libro "Design Patterns ", escrito por los que comúnmente se
conoce como GoF (gang of four, "pandilla de los cuatro"). Los patrones
de diseño se clasifican en:
• Patrones de creación: Inicialización y configuración de
objetos.
• Patrones estructurales: Separan la interfaz de la
implementación. Se ocupan de cómo las clases y objetos se
agrupan, para formar estructuras más grandes.
• Patrones de comportamiento: Más que describir objetos o
clases, describen la comunicación entre ellos.

1Un componente es una parte no trivial, casi independiente, y reemplazable de un sistema

que llena claramente una funcionalidad dentro de un contexto en una arquitectura bien
definida. Un componente se conforma y provee la realización física por medio de un
conjunto de interfaces.[5]
2• Un componente de software en tiempo de ejecución es un paquete dinámicamente
vinculado con uno o varios programas manejados como una unidad y que son accedidos
mediante interfaces bien documentadas que pueden ser descubiertos en tiempo de
ejecución.[6]
3• Un componente de software es una unidad de composición con interfaces
contractualmente especificadas y explícitas sólo con dependencias dentro de un
contexto. Un componente de software puede ser desplegado independientemente y es
sujeto a la composición de terceros.[7]
4• Un Componente de Negocio representa la implementación de software del concepto de
un negocio “autónomo” o un proceso de negocio. Que consiste de artefactos de
software necesarios para expresar, implementar y poner en marcha el concepto de
elemento reusable de un sistema mas grande de negocios.[8]

Estas definiciones no son mutuamente excluyentes, por el contrario, se complementan y

construyen el significado no sólo de componente, también el significado del desarrollo
basado en componentes. Sin embargo más allá de su definición existen algunas
características claves para que un elemento pueda ser catalogado como componente:
1– Identificable: Debe tener una identificación que permita acceder fácilmente a sus
servicios y que permita su clasificación.
2– Auto contenido: Un componente no debe requerir de la utilización de otros para
finiquitar la función para la cual fue diseñado.
3– Puede ser remplazado por otro componente: Se puede remplazar por nuevas
versiones u otro componente que lo remplace y mejore.
4– Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a
lo largo de su implementación.
5– Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar,
pero su implementación sí.
1– Bien Documentado: Un componente debe estar correctamente documentado para
facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
2– Es genérico: Sus servicios debe servir para varias aplicaciones.
3– Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una
aplicación.
4– Independiente de la plataforma: Hardware, Software, S.O.[9]

UN COMPONENTE DE SOFTWARE:
http://pegasus.javeriana.edu.co/~jcpymes/Docs/DSBC.pdf

•
• Un componente de software reutililizable (CSR) es un artefacto de software
auto-contenido y claramente identificable que:
 ejecuta funciones específicas,
 tiene una interface clara a través de la cual se integra a otros
sistemas,
 tiene una documentación apropiada y
 tiene un status de reuso definido
• Un componente de software reutilizable puede ser:
 un módulo,
 una clase,
 un procedimiento o función,
 un subsistema,
 una aplicación

Los patrones de diseño (design patterns) son la base para la búsqueda de

soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes
al diseño de interacción o interfaces.

Un patrón de diseño es una solución a un problema de diseño. Para que una

solución sea considerada un patrón debe poseer ciertas características. Una de ellas es
que debe haber comprobado su efectividad resolviendo problemas similares en
ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a
diferentes problemas de diseño en distintas circunstancias.

http://es.wikipedia.org/wiki/Patrones_de_dise%C3%B1o

Patrones de diseño o más comúnmente conocidos como "Design Patterns". ¿Qué

son los patrones de diseño? Son soluciones simples y elegantes a problemas específicos y
comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se
ha demostrado que funcionan.
 Es evidente que a lo largo de multitud de diseños de aplicaciones hay problemas que
se repiten o que son análogos, es decir, que responden a un cierto patrón. Sería deseable
tener una colección de dichos patrones con las soluciones más óptimas para cada caso. En
este artículo presentamos una lista con los más comunes y conocidos.

Los patrones de diseño no son fáciles de entender, pero una vez entendido su
funcionamiento, los diseños serán mucho más flexibles, modulares y reutilizables. Han
revolucionado el diseño orientado a objetos y todo buen arquitecto de software debería
conocerlos.

A continuación una lista con los patrones de diseño a objetos más habituales publicados
en el libro "Design Patterns ", escrito por los que comúnmente se conoce como GoF (gang of
four, "pandilla de los cuatro").

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.

http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php

Volver
Qué es un Patrón de Diseño?
Por Nicolás Tedeschi

Contenido
¿Qué es un Patrón de Diseño?
Patrones Creacionales
Patrones Estructurales
Patrones de Comportamiento
Conclusión

¿Qué es un Patrón de Diseño?

Esta fue la primer pregunta que me hice cuando comencé a investigar sobre este tema. Al
principio no tenía mucha idea de por dónde comenzar, por lo que mi primera reacción fue realizar una
búsqueda en Internet y obtener de esta manera alguna base sobre la cual apoyarme. La definición que
más me gustó fue la siguiente:

“Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo
de software.”

En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de

software que están sujetos a contextos similares. Debemos tener presente los siguientes elementos de
un patrón: su nombre, el problema (cuando aplicar un patrón), la solución (descripción abstracta del
problema) y las consecuencias (costos y beneficios).

Grande fue mi sorpresa al averiguar que existen varios patrones de diseño popularmente
conocidos, los cuales se clasifican como se muestra a continuación:

• Patrones Creacionales: Inicialización y configuración de objetos.

 • Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases

y objetos se agrupan, para formar estructuras más grandes.

• Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación

entre ellos.

Veamos un poco en qué consisten los distintos tipos de patrones, cuáles son sus fines y qué
beneficios nos aportan.

Patrones de diseño software

Ramiro Lago (Abril 2007)

Introducción
El diseño es un modelo del sistema, realizado con una serie de principios y técnicas, que
permite describir el sistema con el suficiente detalle como para ser implementado. Pero los
principios y reglas no son suficientes, en el contexto de diseño podemos observar que los
buenos ingenieros tienen esquemas y estructuras de solución que usan numerosas veces en
función del contexto del problema. Este es el sentido cabal de la expresión "tener un mente
bien amueblada", y no el significado de tener una notable inteligencia. Estos esquemas y
estructuras son conceptos reusables y nos permiten no reinventar la rueda. Un buen ingeniero
reutiliza un esquema de solución ante problemas similares.

Algo de historia
El concepto de "patrón de diseño" que tenemos en Ingeniería del Software se ha tomado
prestado de la arquitectura. En 1977 se publica el libro "A Pattern Language:
Towns/Building/Construction", de Christopher Alexander, Sara Ishikawa, Murray Silverstein,
Max Jacobson, Ingrid Fiksdahl-King y Shlomo Angel, Oxford University Press. Contiene
numerosos patrones con una notación específica de Alexander.

Alexander comenta que “Cada patrón describe un problema que ocurre una y otra vez
en nuestro entorno, para describir después el núcleo de la solución a ese problema, de tal
manera que esa solución pueda ser usada más de un millón de veces sin hacerlo siquiera dos
veces de la misma forma”. El patrón es un esquema de solución que se aplica a un tipo de
problema, esta aplicación del patrón no es mecánica, sino que requiere de adaptación y
matices. Por ello, dice Alexander que los numerosos usos de un patrón no se repiten dos
veces de la misma forma.

La idea de patrones de diseño estaba "en el aire", la prueba es que numerosos

diseñadores se dirigieron a aplicar las ideas de Alexander a su contexto. El catálogo más
famoso de patrones se encuentra en “Design Patterns: Elements of Reusable Object-
Oriented Software”, de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, 1995,
Addison-Wesley, también conocido como el libro GOF (Gang-Of-Four).

Siguiendo el libro de GOF los patrones se clasifican según el proposito para el que han
sido definidos:

• Creacionales: solucionan problemas de creación de instancias. Nos ayudan a

encapsular y abstraer dicha creación.
• Estructurales: solucionan problemas de composición (agregación) de clases y objetos.
• De Comportamiento: soluciones respecto a la interacción y responsabilidades entre
clases y objetos, así como los algoritmos que encapsulan.

Según el ámbito se clasifican en patrones de clase y de objeto:

 Creación Estructural De Conducta
Método de Adaptador Interprete
Clase
Fabricación (clases) Plantilla
Cadena de
Adaptador Responsabilidad,
Fábrica, (objetos), Puente, Comando (orden),
Constructor, Composición, Iterador,
Objeto
Prototipo, Decorador, Intermediario,
Singleton Fachada, Observador, Estado,
Flyweight Estrategia, Visitante,
Memoria

Concepto de patrón de diseño

"Una arquitectura orientada a objetos bien estructurada está llena de patrones. La calidad
de un sistema orientado a objetos se mide por la atención que los diseñadores han prestado a
las colaboraciones entre sus objetos. Los patrones conducen a arquitecturas más pequeñas,
más simples y más comprensibles". (Grady Booch)

Los patrones de diseño son descripciones de clases cuyas instancias colaboran entre
sí. Cada patrón es adecuado para ser adaptado a un cierto tipo de problema. Para describir un
caso debemos especificar:

• Nombre
• Propósito o finalidad
• Sinónimos (otros nombres por los que puede ser conocido)
• Problema al que es aplicable
• Estructura (diagrama de clases)
• Participantes (responsabilidad de cada clase)
• Colaboraciones (diagrama de interacciones)
• Implementación (consejos, notas y ejemplos)
• Otros patrones con los que está relacionado

Ventajas de los patrones:

 La clave para la reutilización es anticiparse a los nuevos requisitos y cambios, de modo
que los sistemas evolucionen de forma adecuada. Cada patrón permite que algunos aspectos
de la estructura del sistema puedan cambiar independientemente de otros aspectos. Facilitan la
reusabilidad, extensibilidad y mantenimiento.

Un patrón es un esquema o microarquitectura que supone una solución a problemas

(dominios de aplicación) semejantes (aunque los dominios de problema pueden ser muy
diferentes e ir desde una aplicación CAD a un cuadro de mando empresarial). Interesa
constatar una vez más la vieja distinción entre dominio del problema (donde aparecen las
clases propias del dominio, como cuenta, empleado, coche o beneficiario) y el dominio de la
solución o aplicación (donde además aparecen clases como ventana, menú, contenedor o
listener). Los patrones son patrones del dominio de la solución.

También conviene distinguir entre un patrón y una arquitectura global del sistema. Por
decirlo en breve, es la misma distancia que hay entre el diseño de un componente (o módulo) y
el análisis del sistema. Es la diferencia que hay entre el aspecto micro y el macro, por ello, en
ocasiones se denomina a los patrones como "microarquitecturas".

En resumen, un patrón es el denominador común, una estructura común que tienen

aplicaciones semejantes. Esto también ocurre en otros ordenes de la vida. Por ejemplo, en
nuestra vida cotidiana aplicamos a menudo el esquema saludo-presentación-mensaje-
despedida en ocasiones diversas, que van desde un intento de ligar hasta dar una conferencia
(si todavía no cree que existan patrones o que no son útiles intente ligar con el esquema
despedida-mensaje-presentación-saludo, a ver que ocurre).

Algunos patrones de diseño

Delegado (Delegate)

Compuesto (Composite)

Decorador (Decorator)

Mediador (Mediator)

Iterador (Iterator)

Observador (Observer)

Modelo-vista-controlador (Model-View-Controller)

Factoria

Data Access Object (DAO)

Proxy

Volver al índice