UNIVERSIDAD AUTNOMA DE CHIHUAHUA

FACULTAD DE INGENIERA

TESIS DE LICENCIATURA

TECNICA DE DETECCIN DE PATRONES DE DISEO EN SISTEMAS DE

SOFTWARE ORIENTADOS A OBJETOS

QUE PARA OBTENER EL GRADO DE INGENIERO DE SOFTWARE

PRESENTA:
Emmanuel Acosta De Len
DIRECTOR DE TESIS:
M.I.Jess Roberto Lpez Santilln

Chihuahua Chih.
2012

Agosto del
NDICE

AGREDICIMIENTOS.

A mis padres y maestros.

RESUMEN

En cuestin de reingeniera, la industria del software es basta pues las tecnologas de

la informacin con su constante cambio obligan al desarrollador a adaptarse a ellas.
Tratando a la ingeniera inversa como tema principal de este papel tenemos que para la
ayuda del desarrollador, sea ingeniero o arquitecto de software incluso el programador
tener que adaptarse a un sistema desarrollada por alguien mas es todo un reto. Aqu se
presenta una solucin mediante una tcnica y su aplicacin en una herramienta que
proporciona datos de cmo est diseado un sistema de software mostrando los
patrones de diseo encontrados en dicho sistema. Los resultados de esta tcnica se
demuestran en su aplicacin y en la comparacin real con los datos procesados.

OBJETIVOS

Objetivos Generales.

Generar conocimiento a partir de un tema poco explorado como lo son las

herramientas CASE y los patrones de diseo en conjuncin.
Crear una estimulacin por el uso de los patrones de diseo para la creacin y
diseo de sistemas de software orientado a objetos.
Proporcionar los resultados y toda una herramienta para su uso pblico.
Dar entrega de un recurso acadmico para una futura aplicacin o para una
extensin del proyecto como base o parte parcial de otro.
Generar proyectos de software de la facultad de ingeniera la UACH.

Objetivos Especficos.

Encontrar una tcnica y aplicarla para la deteccin de patrones de diseo.

Comprender el uso y aplicacin de los patrones de diseo.
Entender que a partir de un proyecto de software se puede ayudar a la
comprensin de temas recurrentes en la ingeniera del software.
Aprender cmo funciona el paradigma orientado a objetos para desarrollar de
manera exitosa una tcnica de deteccin de patrones basada en las
caractersticas de la POO.

JUSTIFICACION.
En la actualidad se tiene una pobre motivacin por el uso de los patrones de diseo en
la fase de diseo del ciclo de desarrollo de software, si se tuviera una filosofa por
querer solventar los problemas con soluciones existentes tal vez los patrones de diseo
serian una de las prioridades en el software escrito en lenguajes orientados a objetos.
La motivacin por su uso es uno de los objetivos en este documento, pero tambin lo
es la creacin de una tcnica para comprender como es que se obtuvo el diseo de
algn software basado en los patrones de diseo.
Si se toma en cuenta que en la actualidad, aunque si existen herramientas con un
propsito as, no son de divulgacin ni de orden publico pues trabajos como el
desarrollado por Birkner Marcel (2007) que dicta que de manera esttica y dinmica se
puede hacer una deteccin de patrones de diseo nicamente en Java, aqu presenta
su tcnica de manera amena pero sin entrar en detalles pero no distribuye en forma de
herramienta sus resultados para su aplicacin, adems de tener como objeto querer
formar una competencia con quien realice este tipo de herramientas.
El principal objetivo ser realizar algo que en un futuro prximo o lejano a cualquier
persona que tenga relacin con el desarrollo y mantenimiento de software y la mejor
forma de hacerlo es entregando un documento que contenga las tcnicas y bases para
el desarrollo de una herramienta de ingeniera de software asistida por computadora,
cosa que en este pas es bastante necesaria puesto que se tiene una pobre inversin
en materia de tecnologas de la informacin.

METODOLOGA

Se opto por utilizar un mtodo hipottico-deductivo pues si bien el problema que es

basado en poder crear una tcnica para la deteccin de patrones de diseo se basa en
la primer hiptesis que sera si se puede llevar a cabo dicha tarea, todo el contexto es
totalmente analizable de manera deductiva y naturalmente se puede comprobar de
manera experimental evitando que la parte terica, que es basta, pierda su sentido de
manera que se pueda relacionar directamente con la realidad.
Para este tipo de investigacin la deduccin tiene a su favor el seguimiento de pasos
sencillos, lgicos que permiten asegurar el conocimiento de algo que de otra forma se
tendra que haber dado por alto o simplemente no pensar que fuera necesario, como
ejemplo se tomaron muchas tcnicas ya establecidas de deteccin de patrones (no de
diseo) tanto en la naturaleza como patrones en series numricas e imgenes entre
otras y se fueron descartando con forme, o no se adaptaban de manera adecuada o
resultaban muy costosas en cuestin de rendimiento.
En este tipo de experimentacin gran parte del conocimiento fue generado por la
experiencia, as que se obtiene una mayor seguridad de lo que se est realizando y
adems se permite un uso de variables de manera que da una oportunidad para la
correccin de errores y la mejora de la investigacin en general puesto que en la
creacin de un software y cualquiera de las tareas asociadas, la prueba y el error son
sumamente valiosas pues es de ah en donde se genera el conocimiento.

INTRODUCCIN
Existen herramientas de ingeniera en reversa para sistemas orientados a objetos,
estas herramientas CASE en sus versiones comerciales como ArgoUML, StarUML o
Visual Paradigm con funciones que van desde la representacin grafica de una
jerarqua de clases hasta la decompilacin de el cdigo y desde luego diseo. Este tipo
de herramientas son muy tiles cuando personas ajenas a la construccin y/o
mantenimiento de dicho sistema de software son delegadas a realizar tales tareas, pero
cuando se trata del diseo de un sistema no basta con este tipo de herramientas pues
no se puede saber la intencin del diseo, es decir, no saben los problemas que se
resolvieron al aplicar lo que se les muestra, ya sean grficos o cdigo fuente, a travs
de su uso. La tcnica y herramientas que se muestran aqu planean resolver esa
cuestin pues su aplicacin mostrara al usuario como fue diseado a niveles de
estructura y comportamiento a travs de los patrones de diseo que se utilizaron al
crear ese sistema, de esta manera se puede pensar que problemas tuvo el diseador
original del sistema y comprender plenamente su funcionamiento para proceder a darle
correcto mantenimiento.
Si se entiende por patrn de diseo como una solucin a un problema comn de
programacin, o desarrollo de software entonces tendremos que en su forma ms
primitiva, un patrn de diseo mostrara caractersticas propias mismas que ayudaran a
su deteccin. Sern discutidas ms adelante. Debido a esto la programacin y diseo
del algoritmo para la deteccin de estos patrones de diseo se basa en tcnicas de
reconocimiento de patrones comunes que abarca la ingeniera, la computacin y las
matemticas que vistas como una caja negra se denotan en la figura 1.

Figura 1. Modelo de reconocimiento de patrones.

Donde el sensor es la parte de la aplicacin que se encargara de obtener los datos, el
extractor de caractersticas ser la parte donde se da lugar a adquirir la esencia del
patrn y el clasificador, que recibe las caractersticas y decide de qu patrn se est
tratando.
Patrones de diseo.

Se conocen como patrones de diseo a las soluciones abstractas a problemas

recurrentes de programacin, es decir que estas soluciones se aplican cuantas veces
sea necesario. Al hablar de patrones de diseo, los veintids (veintitrs contando al
patrn arquitectnico Facade) presentados en el libro Design Patterns: Elements of
Reusable Object-Oriented Software sern los que la herramienta aqu presentada ser
capaz de detectar dentro de un paquete o carpeta conteniendo el cdigo fuente Java.
Los patrones de diseo se clasifican en tres clases, creacionales, estructurales y de
comportamiento.
Patrones creacionales.
Los patrones de diseo creacionales abstraen el proceso de instanciacin. Ayudan a
que un sistema sea independiente de cmo sus objetos son creados, compuestos y
representados. Un patrn de diseo creacional utiliza herencia para variar que objeto
est siendo instanciado de esta manera delega la instancia de un objeto a otro objeto.
Aqu la lista de patrones revisados:

Abstract Factory
Builder
Factory Method
Protoype
Singleton

Patrones estructurales.
A los patrones estructurales se les concibe con el fin de componer objetos y clases en
grandes estructuras. Estos patrones utilizan herencia para crear interfaces o
implementaciones.

Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

Patrones de comportamiento.
Los patrones de comportamiento se ocupan de los algoritmos y responsabilidades
entre objetos. Estos patrones no solo describen objetos y clases, sino tambin la
comunicacin entre ellos. Se caracterizan por tener un complejo control de flujo en

tiempo de ejecucin, pero su intencin es mantener a uno concentrado en cmo se

comunican los objetos que en como ocurre el flujo de datos.

Chain of responsability
Command
Interpeter
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor

Justificando el libro Design Patterns: Elements of Reusable Object-Oriented

Software.
La herramienta y tcnica se probo y se realizo en Java, que es es un lenguaje de
programacin puramente orientado a objetos, cuando se tiene un lenguaje de
programacin que no es hibrido, la aplicacin de los patrones de diseo es ms natural,
pero entindase que los patrones de diseo no solo aplican en este lenguaje, si no en
cualquier lenguaje que maneje orientacin a objetos, ya sea pura o compartida con otro
paradigma, en el caso de Java existen muchos recursos y ejemplos aplicando patrones
de diseo, incluso se reescribi el libro Design Patterns: Elements of Reusable ObjectOriented Software utilizando como lenguaje para sus ejemplos a Java. Cuando el
programador est familiarizado con los patrones de diseo, muy probablemente
conozca el lenguaje Java.
Acerca del libro, si bien los autores del libro no son los creadores de los patrones de
diseo fueron los que los compilaron en una sola obra. Estos autores apodados los
Gang of Four (Banda de cuatro) hicieron este libro en dos partes, la primer parte
muestra las capacidades y obstculos de la programacin orientada a objetos, la
segunda parte describe los veintitrs patrones de diseo clsicos, el libro original
incluye ejemplos en lenguaje C++ y Smalltalk. En esta segunda parte se encuentran
especificados el uso, la motivacin, la aplicabilidad, la estructura y las consecuencias
de la aplicacin de cada patrn de diseo, estos datos son valiosos para la
construccin de la herramienta aqu presentada pues la especificacin de estos
patrones de diseo es la base para la implementacin de la tcnica que ser capaz de
detectarlos.

FUNDAMENTACIN TERICA.

Se encuentra que el tema de deteccin de patrones de diseo es un rea aun poco

explorada con un gran potencial, algunos de los ms claros exponentes son mostrados
en el desarrollo de documentos como los de Marcel Brikner

en su trabajo Object-

Oriented Design Pattern Detection Using Static and Dynamic Analysis que presenta
varios mtodos para la deteccin de patrones, de manera esttica hace el anlisis de
los archivos de cdigo, y de manera dinmica se refiere al anlisis de los objetos y el
trabajo de Jing Dong, Yongtao Sun y Yajing Shao 2 del departamento de informtica de
la Universidad de Texas en Dallas que redactaron un artculo titulado Design Pattern
detection by template matching en el que describen con ayuda de la teora de grafos y
anlisis de matrices a determinar patrones en un diseo UML.
En el ao 2003 Dirk Heuzeroth y Stefan Mandel de la Universitat Karlsruhe y Welf Lowe
de la Vaxjo universitet

presentan en su escrito Generating Design Pattern Detectors

from Pattern Specifications una aproximacin para desarrollar detectores de patrones

de diseo por medio de la definicin de predicados utilizando el lenguaje PROLOG
para ser usado en cdigo fuente escrito en Java.
La ventaja en todos estos trabajos es que se puede fomentar el uso y motivacin de los
patrones de diseo para poder generar software de manera correcta, teniendo as una
herramienta para aplicar ingeniera inversa, pero tambin tiene una gran desventaja;
Quienes hicieron estos trabajos solo presentan que hicieron pero no como lo hicieron.
En sus trabajos se ve la explicacin pero nunca la implementacin ni los detalles, no
brindan cdigo fuente ni software de uso pblico, entonces Cul es la solucin? Pues
es sencillo, si se tiene una tcnica de deteccin de patrones de diseo y una
herramienta generada aplicando esa tcnica para su uso futuro, as como su cdigo
fuente entonces se puede generar una herramienta para cualquier tipo de lenguaje. Si
bien la tcnica aqu mostrada es para sistemas Orientados a objetos en general

tambin ser dependiendo del lenguaje algunas de las caractersticas que se presenten
en cada patrn de diseo, o su forma de implementacin.
Bases que llevan a la deteccin de patrones de diseo.
Cuando se habla de deteccin de patrones siempre se encuentra su base en teoras
matemticas, en cuanto a comportamiento computacional se muestra fcilmente con el
uso de matemticas discretas en la teora de grafos, asi que en ese nivel se encuentran
algunas bases como presenta N. Tsantalis, A. Chatzigeorgiou, G. Stephanides, S. T.
Halkidis

pues proponen un mtodo de deteccin de patrones con sus variantes por

medio de la ayuda de grafos dirigidos, la aplicacin que este equipo produjo muestra
una alta tasa de precisin en la deteccin de patrones (Ntese que son patrones, no
patrones de diseo), previamente el grupo se dedico a la redaccin de un primer
trabajo titulado Application of Graph Theory to OO Software 5, base para el desarrollo
de su ltimo trabajo. Entonces por lo general las formas ms sencillas de deteccin de
patrones vienen desde un nivel ms bajo de abstraccin.

Herramientas para trabajo con patrones de diseo.

Existen varias herramientas en el mercado que trabajan con patrones de diseo, ya sea
en forma de plug in como lo es MARPLE desarrollado por Chistian Tosi, Marco Zanoni y
Stefano Maggioni

de la Univesit degli Studi di Milano-Bicocca soporta deteccin de

patrones de diseo basndose en algunos elementos bsicos que son extrados de

manera mecnica del cdigo fuente, una vez mas esta herramienta funciona solamente
con el lenguaje Java. Tambin en 2007, Federico Bergenti and Agostino Poggi

del

Dipartimento di Ingegneria dellInformazione, Universit degli Studi di Parma presentan

en su trabajo Improving UML Designs Using Automatic Design Pattern Detection un
sistema llamado IDEA (Interactive Desing Assistan) que es capaz de encontrar y
realizar mejoras en los patrones de diseo, basicamente el producto es capaz de
manera automtica encontrar patrones en un diagrama UML y producir crticas acerca
de esos patrones, en el centro de IDEA es el mdulo que realiza esta accin.

Otra herramienta bastante interesante es la llamada PMF o Pattern Modeling

Framework, en la cual sus autores Magen Elaasar, L. Briand e Yvan Labiche

lograron

disear un marco de trabajo para deteccin de patrones de diseo, en el cual los

patrones debern estar especificados en el lenguaje Epattern, otro producto de estos
autores. Para la alimentacin de esta herramienta los modelos que se especifiquen en
Epattern debern llevar un formato MOF, un lenguaje de metamodelado. Si bien este
trabajo es muy bueno su principal desventaja radica en la entrada al sistema, pues hay
que especificar primero el modelo de un sistema en un formato especifico con un
lenguaje nico para la herramienta y es una gran limitante, pues para crear alguna
herramienta universal a partir de esta se necesita un intermediario que pueda conocer
varios lenguajes a Epattern.
Uno de las herramientas ms conocidas en el mundo de la informtica para el manejo
de patrones de diseo es llamado Design Pattern Framework en su versin actual 4. Es
una aplicacin para .NET para diseo y desarrollo de aplicaciones utilizando patrones
de diseo y todas las siguientes caractersticas:

Gang of Four Patterns

Silverlight Patterns

ASP.NET MVC Patterns

Enterprise Patterns

WPF & WCF Practices

MVP Patterns

Head First Patterns

LINQ-to-SQL Practices

MVVM Patterns

SOA Patterns

Membership Practices

Entity Framework

3-Tier & N-Tier Patterns

Repository Patterns

RIA Services & MEF

App Facade Pattern

Dependency Injection

Testing, Mocking, and more...

Este software es de paga, cuesta alrededor de 70 dlares y es capaz de funcionar en

los lenguajes de .NET como C# y Visual Basic .NET, esta herramienta basa toda su
funcionalidad en ingeniera hacia adelante pero el inters mostrado se basa en el
manejo de una gran cantidad de patrones, tanto de diseo como los patrones
arquitectnicos en sus variantes de construccin de software o de aplicaciones
orientadas a servicios. Su desventaja se basa en tanto el precio como en el limitado
nmero de lenguajes soportados adems de que no presenta forma de realizar
ingeniera inversa.
Mas recientemente se encuentran mas plugins para eclipse como el llamado Reclipse
9

, que es una herramienta para la deteccin de patrones de diseo en el cdigo fuente.

Reclipse tiene las siguientes caractersticas:

Especificacin

grfica

de

los

patrones

estructurales

patrones

de

comportamiento

Descripcin de los diagramas de objeto basados en estructura.

Descripcin de los diagramas de comportamiento basados en diagramas de

secuencia de UML.

Soporte para elementos adicionales.

Deteccin de patrones de diseo en cdigo fuente.

Marca los posibles candidatos.

Rating de porcentaje de los candidatos.

Anlisis dinmico para comprobar el comportamiento de los candidatos.

Reclipse analiza de manera esttica y dinmica.

Otros trabajos antecedentes.

1999, Una Arquitectura para una Herramienta de Patrones de Diseo

10

, Resumen: Los

patrones de diseo constituyen una importante tcnica para facilitar la construccin de

software orientado a objetos. Los entornos de programacin deberan incluir
herramientas que facilitarn el uso de los patrones de diseo. Para poder integrar los
patrones de diseo en tales herramientas es necesario disponer de una arquitectura
flexible que permita manipularlos eficientemente. Este trabajo presenta una
arquitectura, basada a su vez en patrones, diseada con este fin y describe una
herramienta desarrollada para evaluarla.
2008, Antipattern-based Detection of Deficiencies in Java Multithreaded Software

11

. En

este trabajo se investiga un enfoque basado en anti patrones para analizar programas
con subprocesamiento mltiple. Se presenta una librera de 38 anti patrones que
describen a partir de las fuentes de cdigo predefinidas los errores relacionados con el
mismo. Los anti patrones son archivados de manera prctica, plantillas fcil de usar y
estn clasificados de acuerdo a su potencial efecto en el comportamiento

del

programa, tambin en el documento se habla de la experiencia propia de los autores en

cuanto a el uso de los anti patrones en el anlisis de aplicaciones reales con
subprocesamiento mltiple.
Qu es un anti patrn?
Pues la respuesta ms sencilla, un anti patrn de diseo es la anttesis de un patrn de
diseo, es decir que un anti patrn es una mala solucin para un problema 12.
Presentacin.
Para la aplicacin de la tcnica que se presentara en este documento que ser para el
lenguaje Java, escrito en lenguaje Java se utilizara, para el anlisis estatico,
ClassFileAnalyzer (CAN) que es un software que analiza y desensambla un archivo
class de java y est basado en la especificacin de la mquina virtual de java JVM. La
aplicacin fue lanzada como un producto del software libre con la licencia GPL 2.0

Y su uso y funcionamiento es simple, pues convierte una clase a Bytecode legible, es

decir muestra las instrucciones en texto plano.
Para anlisis dinmico se utilizaran las funciones que Java ya brinda al desarrollador.
Marco Terico
Definicin de patrn
Un patrn es un conjunto de elementos que forman una unidad diferenciada y que se
repiten a lo largo del tiempo, por lo que pueden tomarse como modelo o punto de
referencia. Ejemplo: un patrn de comportamiento; el compositor usa un patrn rtmico
que va repitiendo durante la pieza, pero cambiando la meloda.
Patrones de diseo
Los patrones de diseo son la base para la bsqueda de soluciones a problemas
comunes en el desarrollo de software y otros mbitos referentes al diseo de
interaccin o interfaces.
Un patrn de diseo es una solucin a un problema de diseo. Para que una solucin
sea considerada un patrn debe poseer ciertas caractersticas. Una de ellas es que
debe haber comprobado su efectividad resolviendo problemas similares en ocasiones
anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a
diferentes problemas de diseo en distintas circunstancias.
En la terminologa de objetos, el patrn de diseo es una descripcin de un problema y
su solucin que recibe un nombre y que puede emplearse en otros contextos; en teora,
indica la manera de utilizarlo en circunstancias diversas. Muchos patrones ofrecen
orientacin sobre cmo asignar las responsabilidades a los objetos ante determinada
categora de problemas.

Objetivos que tienen los patrones de diseo

Los patrones de diseo pretenden:

Proporcionar catlogos de elementos reusables en el diseo de sistemas

software.

Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y

solucionados anteriormente.

Formalizar un vocabulario comn entre diseadores.

Estandarizar el modo en que se realiza el diseo.

Facilitar

el

aprendizaje

de

las

nuevas

generaciones

de

diseadores

condensando conocimiento ya existente.

De igual forma, no pretenden:

Imponer ciertas alternativas de diseo frente a otras.

Eliminar la creatividad inherente al proceso de diseo.

No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo

problema o similar que soluciona el patrn, siempre teniendo en cuenta que en un caso
particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un
error".
Categoras de los patrones de diseo
Los patrones de diseo son 23 y se dividen en 3 categoras:
Patrones creacionales:

Abstract Factory (Fbrica abstracta): Permite trabajar con objetos de distintas

familias de manera que las familias no se mezclen entre s y haciendo
transparente el tipo de familia concreta que se est usando.

Builder (Constructor virtual): Abstrae el proceso de creacin de un objeto

complejo, centralizando dicho proceso en un nico punto.

Factory Method (Mtodo de fabricacin): Centraliza en una clase constructora la

creacin de objetos de un subtipo de un tipo determinado, ocultando al usuario
la casustica para elegir el subtipo que crear.

Prototype (Prototipo): Crea nuevos objetos clonndolos de una instancia ya

existente.

Singleton (Instancia nica): Garantiza la existencia de una nica instancia para

una clase y la creacin de un mecanismo de acceso global a dicha instancia.

Patrones estructurales:

Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una
clase que de otro modo no podra utilizarla.

Bridge (Puente): Desacopla una abstraccin de su implementacin.

Composite (Objeto compuesto): Permite tratar objetos compuestos como si de

uno simple se tratara.

Decorator (Envoltorio): Aade funcionalidad a una clase dinmicamente.

Patrones de comportamiento:

Chain of Responsibility (Cadena de responsabilidad): Permite establecer la lnea

que deben llevar los mensajes para que los objetos realicen la tarea indicada.

Command (Orden): Encapsula una operacin en un objeto, permitiendo ejecutar

dicha operacin sin necesidad de conocer el contenido de la misma.

Interpreter (Intrprete): Dado un lenguaje, define una gramtica para dicho

lenguaje, as como las herramientas necesarias para interpretarlo.

Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos

independientemente de la implementacin de estos.

Facade (Fachada): Provee de una interfaz unificada simple para acceder a una
interfaz o grupo de interfaces de un subsistema.

Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos

poseen idntica informacin.

Proxy: Mantiene un representante de un objeto.

Mediator (Mediador): Define un objeto que coordine la comunicacin entre

objetos de distintas clases, pero que funcionan como un conjunto.

Memento (Recuerdo): Permite volver a estados anteriores del sistema.

Observer (Observador): Define una dependencia de uno-a-muchos entre

objetos, de forma que cuando un objeto cambie de estado se notifique y
actualicen automticamente todos los objetos que dependen de l.

State (Estado): Permite que un objeto modifique su comportamiento cada vez

que cambie su estado interno.

Strategy (Estrategia): Permite disponer de varios mtodos para resolver un

problema y elegir cul utilizar en tiempo de ejecucin.

Template Method (Mtodo plantilla): Define en una operacin el esqueleto de un

algoritmo, delegando en las subclases algunos de sus pasos, esto permite que
las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.

Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarqua de

clases sin modificar las clases sobre las que opera.

Estructura de los patrones de diseo

Para describir un patrn se usan plantillas ms o menos estandarizadas, de forma que
se expresen uniformemente y puedan constituir efectivamente un medio de
comunicacin uniforme entre diseadores. Varios autores eminentes en esta rea han
propuesto plantillas ligeramente distintas, si bien la mayora definen los mismos
conceptos bsicos.
La plantilla ms comn es la utilizada precisamente por el GoF y consta de los
siguientes apartados:

Nombre del patrn: nombre estndar del patrn por el cual ser reconocido en
la comunidad (normalmente se expresan en ingls).

Clasificacin del patrn: creacional, estructural o de comportamiento.

Intencin: Qu problema pretende resolver el patrn?

Tambin conocido como: Otros nombres de uso comn para el patrn.

Motivacin: Escenario de ejemplo para la aplicacin del patrn.

Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrn.

Estructura: Diagramas de clases oportunos para describir las clases que

intervienen en el patrn.

Participantes: Enumeracin y descripcin de las entidades abstractas (y sus

roles) que participan en el patrn.

Colaboraciones: Explicacin de las interrelaciones que se dan entre los

participantes.

Consecuencias: Consecuencias positivas y negativas en el diseo derivadas de

la aplicacin del patrn.

Implementacin:

Tcnicas

comentarios

oportunos

de

cara

la

implementacin del patrn.

Cdigo de ejemplo: Cdigo fuente ejemplo de implementacin del patrn.

Usos conocidos: Ejemplos de sistemas reales que usan el patrn.

Patrones relacionados: Referencias cruzadas con otros patrones.

Gang of Four es el nombre con el que se conoce comnmente a los autores del libro
Design Patterns (ISBN 0-201-63361-2), referencia en el campo del diseo orientado a
objetos.
La 'Banda de los cuatro', se compone de los siguientes autores:

Erich Gamma

Richard Helm

Ralph Johnson

John Vlissides

Ventajas de los patrones de diseo

Son soluciones concretas:

Un catlogo de patrones es un conjunto de recetas de diseo.

Aunque se pueden clasificar, cada patrn es independiente del resto.

Son soluciones tcnicas:

Dada una determinada situacin, los patrones indican cmo resolverla mediante
un D.O.O.

Existen patrones especficos para un lenguaje determinado, y otros de carcter

ms general.

Se aplican en situaciones muy comunes:

Preden de la experiencia.

Han

demostrado

su

utilidad

frecuentemente en el D.O.O.

Son soluciones simples:

para

resolver

problemas

que

aparecen

Indican cmo resolver un problema particular utilizando un pequeo nmero de

clases relacionadas de forma determinada.

No indican cmo disear un sistema completo, sino slo aspectos puntuales del
mismo.

Facilitan la reutilizacin de las clases y del propio diseo:

Los patrones favorecen la reutilizacin de clases ya existentes y la
programacin de clases reutilizables.

La propia estructura del patrn es reutilizada cada vez que se aplica.

Desventajas de los patrones de diseo

El uso de un patrn no se refleja claramente en el cdigo:

A partir de la implementacin es difcil determinar qu patrn de diseo se ha
utilizado.

No es posible hacer ingeniera inversa.

Referencias a self:

Muchos patrones utilizan la delegacin de operaciones y esto provoca el

conocido problema del mbito local de los objetos (self).

Es difcil reutilizar la implementacin de un patrn:

Las clases del patrn son roles genricos, pero en la implementacin aparecen
clases concretas.

Los patrones suponen cierta sobrecarga de trabajo a la hora de implementar:

Se usan ms clases de las estrictamente necesarias.

A menudo un mensaje se resuelve mediante delegacin de varios mensajes a

otros objetos.

DESARROLLO DE LA TECNICA DE DETECCION DE PATRONES DE DISEO EN

SISTEMAS DE SOFTWARE ORIENTADO A OBJETOS

Cuando se trata de cdigo fuente, es necesario no ser dependiente de las

convenciones que utiliza el programador para poder realizar acciones de deteccin de
patrones, por lo tanto convenciones de nomenclatura de clases, mtodos, atributos no
sern tomados en cuenta. El algoritmo generalizado para la deteccin de patrones aqu
mostrada es el siguiente:
1. Compilar todo el cdigo fuente para descartar clases con errores.
2. Guardar el bytecode en memoria en objetos Class.
3. Formar estructuras jerrquicas de clases donde una, dos o ms clases
extiendan/implementen a otra.
4. Segn las caractersticas propias del patrn de diseo, buscar que relaciones
entre las estructuras jerrquicas concuerden.
5. Mostrar los resultados.

Caractersticas de un patrn de diseo.

Cada patrn de diseo tiene caractersticas propias que los hacen diferir de otros, la
caracterstica ms esencial es su estructura, siendo esta el nmero de clases
involucradas y sus jerarquas. Veintiuno de los veintids patrones aqu mostrados
muestran jerarquas de clases en sus estructuras, otra de sus caractersticas son las
firmas de los mtodos, los tipos devueltos, campos y constructores, as como sus
modificadores de acceso. Vase la figura 1 para denotar un ejemplo.

Figura 2.
En la figura 2 vemos el patrn de diseo estructural Decorator, este patrn soluciona el
problema de poder agregar funcionalidad de manera dinmica a un objeto. La
estructura bsica se muestra en la que las clases involucradas son cinco como mnimo
y si se separa en sus participantes tenemos que son los siguientes:

Componente
Componente Concreto
Decorador
Decorador Concreto

Y separados por estructuras tendremos la estructura Componente(Component,

ConcreteComponent,
Decorator)
y
la
estructura
Decorador(Decorator,
ConcreteDecoratorA, ConcreteDecoratorB). Al analizar la estructura Decorador, se
puede notar que la necesidad de tener dos Decoradores Concretos no son necesarias
para cumplir el patrn, pero analizando la a fondo se nota que es totalmente necesaria
para darle el sentido propio de este diseo debido a que si solo se tiene una sola clase
Decorador Concreto entonces no tiene caso alguno aplicar el patrn pues solo se le
aadir funcionalidad de un solo tipo, mismo que se podra reemplazar con escribir
todos los mtodos en la clase Decorator.

El problema del rendimiento.

El usuario de la aplicacin ser capaz de alimentarla con una carpeta con todo el
cdigo fuente, cuando se trate de un nmero muy grande de archivos de cdigo fuente
ser necesario agruparlos en estructuras para generar menos carga y manipular todo el
cdigo como objetos de estructuras y no individualmente.
Vease la figura 3, de esta forma la entrada pasa por la primer pasada de procesamiento
que es generar las estructuras e1,e2,e3eN que sern almacenadas en una lista
variable identificada de aqu en adelante como la letra E.

Figura 3 Delimitacin de estructuras de un paquete

Buscando caractersticas del patrn de diseo.

Vase el ejemplo de la figura 4 del patrn creacional Abstract Factory.

Figura 4.

Dado que la caracterstica ms importante es su estructura, se aprecia que el mnimo

numero de estructuras para este patrn de diseo son tres, siendo los roles de Abstract
Factory, familia de productos A y familia de productos B. Pueden existir mas familias de
productos pero para poder justificar el uso del patrn son dos familias de producto. Por
lo tanto, para Abstract Factory el algoritmo para identificar su estructura ser el
siguiente:
1.para cada e1 en E
2. para cada e2 en E
3. si e1 es diferente de e2
4. si e1 tiene asociacin con cualquier clase de e2
5. si mtodos de e1 devuelven tipos e2
6. almacenar(e1,e2)

Obteniendo que haya relacin como debe en la primer parte del algoritmo, de procede
a encontrar la otra familia, pues en la estructura nuclear del patrn. Luego el mismo
algoritmo se repite para encontrar a la otra familia de productos.
1.para cada e3en E
3. si e1 es diferente de e3
4. si e1 tiene asociacin con cualquier clase de e3
5. si mtodos de e1 devuelven tipos e3
6. almacenar(e1,e3)

A partir del almacenamiento se le da formato de manera adecuada

En este caso se encontrara que e1,e2 y e3 son los siguientes.

Figura 5
Relaciones entre clases.
Es muy importante remarcar que en una estructura en la mayora de sus casos en los
patrones de diseo se relacionan entre ellas, las relaciones que aparecen son las de:

Asociacin

Agregacin
Composicin
Realizacin
Dependencia
Multiplicidad

Si se analizan estas relaciones se tiene que la diferencia entre ellas es meramente

conceptual pues al tratar si una clase A tiene relacin de asociacin con una clase B la
manera de encontrarla es buscar que A tenga un miembro B en alguna parte de su
cdigo. Sin embargo si un miembro de la clase B se encuentra dentro del cuerpo de un
mtodo el anlisis tendr que ser ms profundo y ser discutido ms adelante.
Herramientas en Java.
Para la bsqueda de las caractersticas de un patrn de diseo es necesario contar con
una coleccin de mtodos para conocer las siguientes preguntas:
Pongamos de ejemplo a la clase A con respecto a la clase B.

Existe asociacin de A con B?

Algn mtodo de A devuelve a B?
Es A un B?
A tiene a un B?
Cuntos mtodos tiene A o B?
Es abstracto/interfaz A o B?

Java en un API nos permite tratar a una clase como un objeto Class, este objeto cuenta
con mtodos que resultan muy tiles en la bsqueda de la respuesta a estas
cuestiones presentadas pues en su sumario de mtodos se encuentran entre todos los
siguientes:
1.
2.
3.
4.
5.
6.

getConstructors()
getDeclaredFields()
getDeclaredMethods()
getInterfaces()
getSuperclass()
isInterface()

A partir del refinamiento de estos mtodos y de su abstraccin para moldearlo a las

necesidades de la aplicacin construida y presentada aqu tenemos el siguiente
sumario de mtodos en la figura 6.

Figura 6 Sumario de mtodos.

Falsos positivos.
Otro problema recurrente al utilizar esta tcnica son los falsos positivos, una forma de
evitarlos seria aplicando reglas ms duras para verificar las caractersticas de los
patrones de diseo, pero sera bastante rigoroso que probablemente alguna variante de
algn patrn de diseo pase desapercibida por no encontrar estrictamente lo que se
pretende, si vemos en el ejemplo anterior del patrn Abstract Factory, en el algoritmo
nicamente se busco que las estructuras e1 y e2 hubiera asociacin entre cualquier
clase de ellas, no entre alguna en especifico o entre algn numero, tambin se busco
que mtodos de e1 regresaran tipos e2 pues es una caracterstica esencial, aun as
nmeros de falsos positivos existirn pero no tanto como para quitar practicidad a la

tcnica pues aun as esos falsos positivos mostraran una estructura que corresponde a
la del patrn que pudiera ser potencialmente una variante.
Pruebas.
Las siguientes pruebas se hicieron utilizando el paquete del API de Java java.util como
entrada a la aplicacin, se muestra en la tabla los resultados para los patrones Visitor,
Composite, Bridge, Factory Method, Builder y Chain of Responsability.
Patrn
Visitor
Bridge
Composite
Builder
Factory Method
Chain
Responsability

Total
1
10
3
3
3
of 2

Reales
1
3
3
3
3
2

Falsos positivos
0
7
0
0
0
0

Como parte de los falsos positivos, no se toman en cuenta los que cumplen algunas de
las caractersticas de los patrones, al no cumplirlas todas algunos patrones aun asi las
muestran con un porcentaje de parecido en ciertos casos, en otros casos las
propiedades del patrn son esenciales que se manejan como un valor absoluto.

Anlisis dinmico.
La parte de anlisis dinmico es la que se realiza en tiempo de ejecucin sobre los
objetos actuales en memoria y sus relaciones, como parte del anlisis dinmico se
obtienen lo siguiente:

Tipos devueltos.
Tipo de clase; abstracta, interfaz.
Relaciones es un
Relaciones tiene un
Relaciones generales de asociacin.

En anlisis dinmico es de suma importancia en la presentacin de esta tcnica, con la

ayuda de las funciones de Java es fcil tratar estas tareas, pero no siempre es
suficiente pues hay ciertos mtodos que no encuentran la informacin necesaria, por lo
tanto se opta tambin por un anlisis esttico.
Anlisis esttico.
El anlisis esttico ayudo a realizar funciones de:

Relaciones generales de asociacin.

Compilacin
Bsqueda dinmica en cdigo fuente.

Buscar de manera esttica ayuda a encontrar relaciones entre clases que de otra
manera seria imposibles, veamos el siguiente caso para denotar una relacin de
agregacin/composicion.

Claramente A tiene una relaciones con B, pero de manera dinmica no podemos ver la
implementacin del mtodo de la clase A para conocer si de verdad tiene una
relaciones con B, puesto que podemos saber si devuelve un B o si tiene un B, o si
recibe en alguno de sus mtodos un tipo B como argumento pero no hay forma de
saber si dentro de la implementacin o de un constructor esta una llamaba o
construccin de un B, por lo tanto para evitar eso se utiliza el anlisis esttico del
Bytecode.

CONCLUSIONES.

Crear una tcnica para deteccin de patrones de diseo en sistemas orientados a

objetos es totalmente plausible, se obtuvieron resultados favorables en la deteccin con
un margen aceptable de falsos positivos, si se toma en cuenta una de las limitantes;
Esta basado en las especificaciones de los patrones de diseo del libro del GoF que
solo muestra la implementacin de un tipo, Cmo se puede mejorar? Pues aadiendo
para el mismo patrn varias de sus especificaciones en la programacin de las reglas
para su deteccin. Lo que se obtuvo al aplicar esta tcnica fue una herramienta que
ayudara a quien sea capaz de utilizarla y sepa el contexto de los patrones de diseo,
se tiene en cuenta que una herramienta as deber solo caer en manos de personas
que puedan usarla de forma adecuada y familiarizadas con la reingeniera del software,
pues solo a esas personas les resultara til.
En cuestiones tcnicas se obtiene que para, al menos el lenguaje Java, es fcil
implementar una tcnica como estas pues no hay necesidad de desarrollar muchas
funciones extras ya que su API facilita muchas de estas cuestiones, adems que trae
soporte para patrones de diseo como lo son Iterator, Singleton entre otros. Para otros
lenguajes de programacin la principal limitante ser crear toda esta coleccin de
funciones que sean capaces de conocer las relaciones entre clases, tipos devueltos,
tipos parmetros, tipos de clases, modificadores de acceso y todo lo necesario para
poder llegar a una aplicacin correcta de esta tcnica. Los resultados nos revelan
informacin importante y nos permiten ver la aproximacin a la creacin de una
herramienta verdaderamente til, al igual que cualquier herramienta es necesario que
se sepa utilizar y conocer el contexto que el uso de algo como esto, se necesita para
darle, asi, como un correcto funcionamiento, ayudar a la deteccin de problemas
futuros o de formas de corregir, mejorar y mantener una herramienta de esta
naturaleza, y ms que hoy en da el uso de asistencia por computadora es totalmente
necesaria en busca del aseguramiento de calidad en software y en cualquier etapa del
ciclo de vida.
La herramienta resultante bien puede ser como parte de alguna otra herramienta que
maneje ingeniera inversa como las presentadas en la introduccin de este documento,
pues sera ms til como parte de algo ms grande que sola como es ya que el uso de
algo as, que es relativamente nuevo podr atraer la atencin necesaria, adems de su
uso que es limitado nicamente a la deteccin de patrones de diseo, adems tomando
en cuenta el estado del arte del tema tratado se conoce que este tema poco estudiado

y entra de manera completa en las areas de la ingeniera del software ms

importantes, sobre todo la de mantenimiento.
En cuanto a los patrones de diseo, es totalmente necesario extender su uso,
promoverlo y estimularlos, la filosofa del uso de los patrones de diseo se basa en la
programacin para una interfaz, no para una implementacin lo que nos dice que
siempre tendremos formas de mantener, extender y modificar de una manera sencilla y
limpia el software orientado a objetos que escribamos adems que si no es el mismo
ingeniero/arquitecto de software el que le tiene que dar mantenimiento le ser mas fcil
su comprensin si conoce cmo funcionan los patrones. La verdad es que si se
pregunta acerca de quien usa estos patrones muy pocas respuestas afirmativas sern
obtenidas.
Como parte para un trabajo futuro, se propone la incorporacin de un elemento grafico
que permita la visualizacin de estos patrones en todo el conjunto de clases analizadas
seria una caracterstica que permitiera hacer de la aplicacin resultante una
herramienta completa o stand-alone para uso completo, adems de que sera mucho
ms amigable identificarlos de una manera visual que estarlos leyendo en texto plano y
buscarlos para identificarlos consecutivamente.
En cuanto a los lenguajes de programacin de paradigma orientado a objetos, para
este trabajo se utilizo java nicamente, java al ser puramente orientado a objetos y al
tener, afortunadamente, forma de tratarse a sus mismas clases como objetos facilito
mucho la escritura de aplicacin de la tcnica aqu mostrada, cosa que el lenguaje C#
no tiene (al menos al momento de la redaccin de este documento), pero igualmente la
tcnica es para el paradigma orientado a objetos y funciona tericamente igual para
cada lenguaje, lo laborioso ser tener que buscar la forma de hacer el anlisis esttico
y dinmico para las clases, si es que se deseara utilizar estas tcnicas puesto que
hacen fcilmente las funciones mas importantes como la bsqueda de relaciones entre
dos clases.

Referencias bibliogrficas.
1. Birkner, M. (s.f.). mb-pde. Recuperado el 9 de Septiembre de 2011, de Java Software
Design Pattern Detection Engine: http://mb-pde.googlecode.com/files/MasterThesis.pdf
2. Dong, J., Sun, Y., & Zhao, Y. (s.f.). UT Dallas. Recuperado el 10 de Septiembre de
2011, de http://www.utdallas.edu/~jdong/papers/sac08.pdf
3. Heuzeroth, D., & Mandel, S. (s.f.). ARiSA - Applied Research in System Analysis.
Recuperado el 10 de Septiembre de 2011, de http://www.arisa.se/files/HLM-03.pdf
4. N. Tsantalis, A. Chatzigeorgiou, G. Stephanides, S. T. Halkidis, "Design Pattern
Detection Using Similarity Scoring", IEEE Transactions on Software Engineering, vol.
32, no. 11, pp. 896-909, November, 2006.
5. A. Chatzigeorgiou, N. Tsantalis, G. Stephanides, "Application of Graph Theory to OO
Software Engineering", 2nd International Workshop on Interdisciplinary Software
Engineering Research (WISER'2006), Shanghai, China, May 20, 2006
6. Tosi, C., Zanoni, M., & Maggioni, S. (s.f.). Eclipse-IT 2009. Recuperado el 9 de
Septiembre de 2011, de http://eit09.unibg.it/pdfs/99990089.pdf
7. Wang, W., & Tzerpos, V. (s.f.). York University. Recuperado el 10 de Septiembre de
2011,
de
Department
of
Computer
Science
and
Engineering:
www.cse.yorku.ca/~bil/publications/dpd.pdf
8. Elaasar, M., Briand, L., & Labiche, Y. (s.f.). Mendeley. Recuperado el 9 de
Septiembre de 2011, de http://www.mendeley.com/research/metamodeling-approachpattern-specification/
9. FUJABA Tool Suite. (s.f.). Recuperado el 15 de Septiembre de 2011, de
http://www.fujaba.de/index.php?id=11731
10. Sez Martnez, J., Garca Molina, J., & Jimnez Garca, P. (s.f.). Departamento de
Informtica y Sistemas Universidad de Murcia. Recuperado el 12 de Septiembre de
2011, de http://dis.um.es/~jmolina/arquipatronesjis99.pdf
11. IEEE Xplore Digital Library. (s.f.). Recuperado el 14 de Septiembre de 2011, de
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1357968

12. Anti patterns. Recuperado 21 Agosto 2012, de http://c2.com/cgi/wiki?AntiPattern