- Definiciones
- Características
- Descripción de un
Patrón - Tipos de
patrones - Catálogo de
patrones - Antipatrones
- Evolución
- Orientaciones de
aplicación - Investigaciones actuales
(estado del arte) - Conclusiones
- Referencias
En un proceso de
desarrollo
de sistemas de
información, los profesionales del software se
enfrentan cada día a multitud de problemas
de distinta magnitud. Los profesionales con experiencia
resuelven, de forma mayormente intuitiva, muchos de los
problemas de modelado de sistemas
reales. El mejor profesional es el que reutiliza la misma
solución retocada para resolver problemas similares en
situaciones distintas. Estas experiencias, que engloban
técnicas y criterios experimentales
efectivos y probados, pueden ser difícilmente
transmitidas formalmente a ingenieros noveles.En la actualidad la idea de reutilización
cobra gran relevancia, especialmente en la orientación
a objetos. Esto se vuelve insuficiente, si sólo lo
aplicamos a nivel de componentes de software en el proceso
global de desarrollo. Se necesita una forma de transmitir el
conocimiento de estás experiencias
efectivas de solución.Christopher Alexander, desde el ámbito
de la arquitectura,
propone la idea de los Patrones, la cual luego es trasladada
a la ingeniería
de software. Los Patrones pretenden ser la
solución al problema de la
comunicación de experiencias que se plantea. Cada
patrón describe un problema concurrente en nuestro
entorno, para describir después el camino a la
solución a ese problema, de tal forma que pueda ser
reutilizado en proyectos
distintos.Esta idea de patrones, por su misma naturaleza
genérica de
Problema-Solución-Reutilización, se ha
popularizado a nivel mundial. En la actualidad existen muchas
investigaciones al respecto, las cuales se
orientan a muy distintos ámbitos de la actividad
humana. Asimismo dentro de la ingeniería de software se ha extendido,
tal así que se han creado y siguen creando
catálogos de patrones para problemas en distintos
niveles de abstracción. Por ejemplo, estamos hablando
ya, no solo de patrones de diseño, sino también tenemos
patrones de programación, de arquitectura, de
análisis, de requisitos,
etc.El presente trabajo
tiene el objetivo
de describir la evolución y las diferentes
orientaciones que ha tomado la idea de los
patrones.Para el logro del presente objetivo planteamos
primero la idea general de los patrones: Definición,
características, tipos. Asimismo se muestra una
reseña histórica de la evolución de los
patrones. Por último describiremos alguna de las
investigaciones que se realizan en la actualidad en los
diferentes ámbitos del desarrollo de
software.- Introducción
- Definiciones
En la práctica del desarrollo de software, los
ingenieros, analistas, diseñadores, etc. con un grado de
experiencia medio o alto, aplican normalmente técnicas
intuitivas para dar solución a problemas determinados.
Estas técnicas efectivamente aplicadas a problemas
específicos, son fruto de situaciones problemáticas
similares que estos profesionales atravesaron anteriormente
saliendo triunfantes.
Esta experiencia se plasma de cierta manera en métodos,
estructuras,
etc. y que se convierte, a su vez, en el núcleo de la
solución a un problema determinado. Estas prácticas
propias de profesionales experimentados no las
encontrábamos en los libros de
texto de
ingeniería de software y a su vez son difíciles de
transmitir a los profesionales con poca experiencia.
A continuación presentamos algunas definiciones
que describen la idea de patrones. Esta idea, surgida en el
ámbito de la arquitectura y posteriormente trasladada a la
ingeniería de software, intenta resolver el problema de la
reutilización efectiva de las experiencias de
solución a problemas específicos de profesionales
experimentados.
"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"
Christopher Alexander
Definición obtenida de: A Pattern Language:
Towns/Building/Construction, de Christopher Alexander, Sara
Ishikawa, Murray Silverstein, Max Jacobson, Ingrid
Fiksdahl-King y Shlomo Angel, 1977, Oxford University
Press. 253 patrones, con el formato específico
pro-puesto por Alexander, se dan cita en este texto, en el que
además se propugna una integración del mejor-vivir con el medio
físico circundante:
gente-gente-patrones-gente.
Esta definición propuesta por Alexander, intenta
identificar y resolver, en un marco descriptivo formal aunque
no-exacto, problemas esenciales que se presentan en el dominio de la
arquitectura.
Los profesionales del software han utilizado esta
definición como catalizador de tendencias de desarrollo en
el diseño orientado a objetos de sistemas de información. La definición expuesta
por Alexander, se refiere a patrones de ciudades y edificios,
pero son ciertamente válidas en el ámbito del
diseño orientado a objetos, por ejemplo nuestras soluciones se
expresan en términos de objetos e interfaces en vez de
paredes y puertas, pero en esencia ambas se orientan a la
solución de un problema dentro de un contexto
específico.
Las definiciones descritas a continuación
están basadas en la definición de Alexander y
están referidas ya al ámbito del
software.
Un Patrón de diseño nomina, abstrae e
identifica los aspectos claves de una estructura
de diseño común, lo que los hace útiles
para crear un diseño orientado a objetos reutilizable.
El patrón de diseño identifica las clases e
instancias participantes, sus roles y colaboraciones, y la
distribución de responsabilidades. Cada
patrón de diseño se centra en un problema
concreto,
describiendo cuando aplicarlo y si tiene sentido hacerlo
teniendo otras restricciones de diseño, así como
las consecuencias y las ventajas e inconvenientes de su uso.
Por otro lado, como normalmente tendremos que implementar
nuestros diseños, un patrón también
proporciona código de ejemplo en C++, y a veces en
Smalltalk, para ilustrar una
implementación.
Erich Gamma, Richard Helm, Ralph Jonson
y John Vlissides. [GA95]
"Un patrón describe un problema
de diseño recurrente, que surge en contextos
específicos de diseño, y presenta un esquema
genérico probado para la solución de este. El
esquema de la solución describe un conjunto de
componentes, responsabilidades y relaciones entre de
éstos, y formas en que dichos componentes colaboran
entre sí."
Frank Buschmann, Regine Meunier, Hans
Rohnert, Peter Sommerlad, Michael Stal. [BU96]
Los patrones de diseño son la
representación escrita de las técnicas que
proporcionan la visión de alto nivel de un sistema de
software. Un patrón es un conjunto de información
que aporta la solución a un problema que se presenta en
un contexto determinado. Para elaborarlo se aíslan sus
aspectos esenciales y se añaden cuantos comentarios y
ejemplos sean necesarios.
Alejandro Ramirez.
[RA04]
Estas últimas definiciones están referidas
principalmente al dominio del software. De éstas podemos
rescatar muchos puntos esenciales que a continuación
especificamos de la siguiente manera:
- Un Patrón de Diseño, es un
conjunto de información que describe una
solución recurrente a un problema de diseño no
trivial. - La efectividad de esta solución ha debido
ser probada muchas veces por profesionales expertos dentro de
un contexto determinado en situaciones
anteriores. - Esta solución debe ser reutilizable, para
problemas de diseño similares en distintas
circunstancias. - Esta descripción de un patrón debe
ser lo suficientemente explícita para que pueda ser
transmitida a profesionales no expertos".
Describimos algunos puntos importantes expuestos en las
especificaciones anteriores y que se piensa que se deben
resaltar:
- Contexto.- Conformado por el entorno,
situación, o condiciones interrelacionadas dentro de las
cuales existe el patrón. - Problema.- Esta dado por un asunto insatisfecho, algo
que se necesita investigar y resolver. Normalmente un problema
se puede especificar mediante un conjunto de causas y
efectos. - Solución.- Esta referida a la respuesta al
problema dentro de un contexto y muestra el camino para
resolver las dificultades. - Reutilizable.- La descripción bebe ser clara,
expresada de manera formal, aunque se encuentre en un
ámbito general, para que pueda ser transmitida y
reutilizada por profesionales no expertos.
El concepto de
patrón, aunque tiene un carácter general, se piensa que debe contar
con las siguientes propiedades para que sea eficientemente
reutilizado.
- Ser una solución de sentido común que
forma parte del conocimiento de un diseñador
experto. - Debe facilitar la comunicación entre diseñadores,
promulgan un vocabulario común. - Debe facilitar el aprendizaje
de diseñadores no expertos. - La solución que describe ha debido ser probada
más de una vez en distintos casos. - Debe proveer una plantilla conceptual que muestra el
núcleo de una solución a un problema de
diseño específico. - Debe describir participantes y relaciones entre
ellos: describen módulos, estructuras del sistema y
mecanismos complejos.
Para describir un patrón las notaciones gráficas no son suficientes. Para que el
patrón pueda ser reutilizado se necesita representar las
decisiones, alternativas, ventajas e inconvenientes que son su
razón de ser. Normalmente, un patrón está
documentado en forma de una plantilla. Es una práctica
común documentar los patrones en un formato de plantilla,
pero no significa que sea la única forma de hacerlo.
Además, existen muchos formatos de plantillas propuestos
por muchos autores, lo cual permite la creatividad en
la documentación de patrones. A
continuación presentamos como referencia los elementos de
descripción de patrones propuesto por Gamma
[GA95].
- Nombre del patrón. Debe ser un nombre corto y
significativo, generalmente una o dos palabras. El nombre
pasará a formar parte de nuestro vocabulario de
diseño. - Clasificación. Para el tipo del patrón
no hay una clasificación formal pero suelen agruparse en
patrones de creación, estructura, comportamiento, concurrencia, etc. - Propósito. Representado por una frese breve
que describe el problema concreto de diseño y que hace
el patrón para resolverlo. - También conocido como. Especificación
de otros nombres con los cuales se le conoce al
patrón. - Motivación. Describe el escenario que ilustra
el problema de diseño y como las estructuras de clases y
objetos del patrón resuelven el problema. - Aplicabilidad. Describe en que situaciones se puede
aplicar el patrón, ejemplos y formas de reconocer tales
situaciones. - Estructura. Se hace mediante una
representación gráfica del patrón que
muestren sus elementos y relaciones constitutivas. - Participantes. Especificación de las clases y
objetos que consta el patrón incluyendo las respectivas
responsabilidades. - Colaboraciones. Representación de cómo
colaboran los participantes para cumplir con sus
responsabilidades. - Consecuencias. Se especifican las ventajas e
inconvenientes a los que conlleva usar el
patrón. - Implementación. Descripción de las
dificultades, trucos o técnicas que deberíamos
tener presentes al momento de aplicar el
patrón. - Código de ejemplo. Especificación de
código que ejemplifique la forma como debemos
implementar el patrón. - Usos conocidos. Descripción de ejemplos donde
haya sido utilizado el patrón. - Patrones relacionados. Especificaciones de otros
patrones con los cuales este relacionado, las principales
diferencias y los patrones con los que se debería
usar.
La clasificación de los patrones no está
estandarizada, pero la mayoría de autores suele referirse
a los siguientes tipos:
- Fundamentales: Los patrones de esta
categoría son los más fundamentales e importantes
patrones de diseño conocidos. Estos patrones son
utilizados extensivamente en otros patrones de
diseño. - De Creación (Creational): Los patrones
de creación muestran la guía de cómo crear
objetos cuando sus creaciones requieren tomar decisiones. Estas
decisiones normalmente serán resueltas
dinámicamente decidiendo que clases instanciar o sobre
que objetos un objeto delegará
responsabilidades. - De partición: En la etapa de
análisis, se examina el problema para identificar los
actores, casos de uso, requerimientos y las relaciones que
constituyen el problema. Los patrones de esta categoría
proveen la guía sobre como dividir actores complejos y
casos de uso en múltiples clases. - Estructura (Structural): Describen la forma
como se pueden relacionar, diferentes tipos de objetos, para
trabajar unos con otros y formar estructuras de mayor
tamaño. - Conducta (Behavioral): Describen la forma como
organizar, administrar, y combinar, conductas y
responsabilidades de objetos. - Concurrencia (Concurrency patterns): Describen
como coordinar operaciones
concurrentes para compartir recursos o
secuenciar dichas operaciones.
Teniendo en cuanta que los patrones son creados para ser
reutilizados y pueden resultar útiles en el desarrollo de
software, es lógico pensar en la forma de hacerlos
accesibles para el momento en que se requieran. En consecuencia
debemos reunirlos en catálogos que permitan acceder a
ellos mediante distintos criterios, de tal forma que no solo nos
muestren una completa descripción de cada uno de los
patrones sino, esencialmente, la correspondencia entre un
problema real y un patrón (o conjunto de patrones)
determinado. El catálogo de patrones más famoso es
el contenido en el libro
"Design Patterns: Elements of Reusable Object-Oriented
Software"[GA95], también
conocido como el LIBRO GoF (Gang-Of-Four Book). La
descripción general de este catálogo y otros, la
mostramos a continuación en el Anexo I.
En la mayor parte de las disciplinas también
existen malos usos que están más o menos
extendidos, y que por lo tanto no aportan soluciones efectivas a
la resolución de problemas. Si un patrón es una
buena práctica, entonces un antipatrón es una mala
práctica. El estudio de los antipatrones propugna la
prevención de errores que pudieran incurrir profesionales
inexpertos. Hay dos nociones de antipatrones:
- Aquellos que describen una mala solución a un
problema que da como resultado una mala
situación. - Aquellos que describen como salir de una mala
situación y convertirla en una buena
solución.
Los antipatrones deben ser valorados porque a menudo es
tan importante ver y entender malas soluciones como ver y
entender las buenas. Brown, Malveau, MacCormick y Mowbray [BR98]
han escrito un libro sobre los antipatrones que intenta
identificar y diagnosticar varias anti-soluciones para
corregirlas y prevenirlas. Los antipatrones más
útiles serán aquellos que permiten rehacer un buen
diseño a partir de uno malo.
Se puede definir entonces un antipatrón de la
siguiente forma:
"Forma literaria que describe una
solución comúnmente dada a un problema que genera
consecuencias negativas decididamente".
Estos antipatrones se pueden encontrar en muchas
disciplinas. Ateniéndonos a la ingeniería del
software se pueden clasificar los diferentes tipos de
antipatrones de la siguiente forma:
Antipatrones de desarrollo de
software:
1. The Blob ("clases gigantes").
2. Lava Flow ("código muerto").
3. Funcional Decomposition ("diseño no orientado
a objetos").
4. Poltergeists ("no se sabe bien lo que hacen algunas
clases").
5. Golden hammer ("para un martillo todo son
clavos").
6. Spaghetti code ("muchos if o switch").
7. Cut-and-paste programming ("cortar y pegar
código").
Antipatrones de arquitectura de
software:
1. Stovepipe enterprise ("aislamiento en la
empresa").
2. Stovepipe system ("aislamiento entre
sistemas").
3. Vendor Lock-In ("arquitectura dependiente de producto").
4. Arquitecture by implication.
5. Design by committee ("navaja suiza").
6. Reinvent the Wheel ("reinventar la
rueda").
Antipatrones de gestión
de proyectos software:
1. Analysis paralysis.
2. Death by planning.
3. Corncob ("personas problemáticas").
4. Irrational management.
5. Project mismanegement.
De todos estos antipatrones los más relacionados
con los patrones de diseño son los de desarrollo de
software por lo que habrá que evitarlos en la medida de lo
posible. Todos los antipatrones tienen al lado una
aclaración que permite intuir a lo que se
refieren.
La idea de patrones de diseño de software, como
ya lo mencionamos anteriormente, hizo su aparición en el
dominio de la arquitectura con Alexander a mediados de los
70´s, y luego fue asimilada por los profesionales de
software.
La orientación a objetos propugna la
reutilización de componentes de código de software,
es aquí donde la idea de patrones es utilizada, pero no
para la reutilización de código, si no para abarcar
el ámbito del análisis y diseño orientado a
objetos.
A continuación mostraremos una reseña
histórica de esta idea y como ha ido evolucionando. En la
actualidad existen muchos estudios y proyectos al respecto y ya
no solo en el ámbito del diseño sino se ha
extendido a otras fases del ciclo de vida
del desarrollo de sistemas de información.
- Desde 1964 hasta 1979, Christopher Alexander escribe
varios libros acerca del planeamiento
urbano y la construcción de edificios. Entre ellos
destaca "A pattern Language: Towns/Building/Construction". Este
libro contiene 253 patrones, con un formato específico
propuesto por Alexander, en los que se describe la planificación de ciudades y la
construcción de edificios. Su método
de capturar el
conocimiento fue innovador, y reflejaba un conocimiento
práctico hasta entonces solo adquirible mediante
años de experiencia. Alexander propone que existe un
invariante común, que define los principios
generales del diseño y construcción. El
descubrimiento de las invariantes aplicables al diseño
de software es hoy el objetivo de los desarrolladores de
software, pues proporcionan un marco común de
conocimiento y soluciones. - A principios de los 80 se hizo evidente la escasez de
arquitectos de diseño orientado a objetos. La comunidad
académica no proporcionaba el conocimiento necesario
para lidiar con los requerimientos cambiantes de los proyectos.
Este conocimiento requería años de experiencia,
pero las demandas de la industria no
favorecían la demora necesaria para que los arquitectos
instruyesen a sus colegas. Era necesario un modo de difundir
este conocimiento. - En 1987, Ward Cunningham y Kent Beck diseñaban
interfaces de usuario con Smaltalk. Decidieron, para ello,
utilizar alguna de las ideas de Alexander para desarrollar un
lenguaje de
patrones que sirviese de guía a los programadores de
Smaltalk. El resultado fue el libro "Using Pattern Languages
for Object-Oriented Programs". - Poco después en 1991, Jim Coplien
comenzó a realizar un catálogo de patrones de
bajo niveñ (idioms) en C++ y publicó su libro
"Advanced C++ Programming Styles and Idioms". - Desde 1990 a 1994, Erich Gamma, Richard Helm, Ralph
Johnson y John Vlissides (Gang of Four (GoF), el llamado
grupo de los
cuatro) realizaron un primer catálogo de patrones de
diseño. - En 1994 se realizo la primera conferencia
sobre patrones de diseño: Pattern Languages
of Program Design (PLoP), centrada en patrones
para desarrollar aplicaciones de software. En la
PLoP
94 también se presento el ensayo "A
Development Process Generative Pattern Language" que fue el
primer ejemplo de patrones aplicados a otro campo distinto del
software. - Poco después de Abril de 1994 es publicado el
libro "Design Patterns: Elements of Reusable Object-Oriented
Software". A este libro se le suele llamar GoF, por el
sobrenombre de sus autores. La reacción a este libro fue
universalmente positiva y se convirtió en una obra
fundamental en la materia.
Muchos arquitectos reconocieron en las soluciones propuestas
descripciones a las que ellos mismos habían llegado
independientemente. Se organizaron grupos de
estudio sobre patrones y aparecieron consultoras que
proporcionaban aprendizaje
sobre el tema. - En 1996 Michael Akroyd formaliza el concepto de
anti-patrón en su presentación "Antipatterns:
Vaccinations against Object Misuse". Dicha presentación
se centro en identificar errores comunes cometidos en proyectos
de software. - En 1997 Brad Appleton publica "Patterns and Software:
Essential Concepts and Terminology". - Mark Grand publica en 1998 la primera edición de "Patterns in Java (volume
1)" que es un catálogo de patrones de diseño
ilustrados con UML. En 2001 el
mismo autor publica "Java Enterprise Design Patterns" en donde
se añaden 41 patrones de diseño relativos a Java
Enterprise. - En 1998, Brown, Malveau, MacCormick y Mowbray
públican un libro sobre antipatrones que intenta
identificar y diagnosticar varias anti-soluciones para
corregirlas y prevenirlas. - El 2002, van Duyne, D. Landay, J. Hong, J., en su
libro The Design of Sites: Patterns, Principles, and
Processes for Crafting a Customer-Centered Web
Experience [DU02], ofrecen principios, procesos, y
patrones para desarrollar sitios web centrados en el cliente. Con el
enfoque centrado en el cliente, el Web site puede ser
relevante, se explica por sí mismo, y fácil de
utilizar.
Por la naturaleza de la idea de los patrones,
éstos solucionan problemas que existen en muchos niveles
de abstracción. Los Patrones inicialmente fueron aplicados
en la fase de diseño de los sistemas de
información, por la necesidad respectiva que se
tenía en este ámbito. Sin embargo existen otros
ámbitos de la ingeniería del software donde se
puede aplicar el concepto genérico de
patrón.
Hay patrones que describen soluciones para todo, desde
el análisis hasta el diseño y desde la arquitectura
hasta la implementación. Además, los patrones
existen en diversas áreas de interés y
tecnologías. Por ejemplo mostramos algunos:
- Patrones organizativos: Describen la
estructura y prácticas de las organizaciones
humanas, especialmente las productoras de software. - Patrones de análisis: Describen un
conjunto de prácticas destinadas a elaborar modelos de
los conceptos principales de la aplicación que se va a
construir. La intención principal de estos patrones es
ayudar a las personas que realizan el trabajo
de modelado, pues no siempre tienen experiencia al respecto y,
en la mayoría de los casos, construyen sus modelos sin
referencia alguna. - Patrones de arquitectura: Expresan un paradigma
fundamental para estructurar u organizar un sistema
software. Proporcionan un conjunto de subsistemas
o módulos predefinidos, con reglas y guías para
organizar las relaciones entre ellos. Ejemplo: - Capas (Layers)
- Aplicaciones: JVM, API, Windows
NI - Pipes and Filters
- Aplicaciones: UNIX
- Pizarrón (Blackboard)
- Aplicaciones: Hearsay, Inteligencia Artificial
- Patrones de diseño: Proporciona un
esquema para refinar los subsistemas o componentes de un
sistema software y las relaciones entre ellos. Describe
estructuras recurrentes de comunicar componentes que resuelven
un problema de diseño en un contexto particular. Son
patrones de un nivel de abstracción menor que los
patrones de arquitectura. Están por lo tanto más
próximos a lo que sería el código fuente
final. Su uso no se refleja en la estructura global del
sistema. - Patrones de programación (Idioms
patterns): Un idiom es un patrón de bajo nivel,
específico a un lenguaje de
programación determinado. Describe como implementar
aspectos particulares de los componentes de un patrón de
diseño usando las características y
potencialidades de un lenguaje de programación
concreto.
Los patrones han adquirido una gran popularidad que ha
hecho que la comunidad de software los utilice comúnmente.
A continuación mostraremos algunas investigaciones que se
están haciendo al respecto.
Investigadores de la Universidad Autónoma de Tlaxcala
(UAT), el Instituto Nacional de Astrofísica
Óptica y Electrónica (INAOE) y la
Benemérita Universidad Autónoma de Puebla
(BUAP) de México, presentan en su
artículo los estudios que se exponen a
continuación.La civilización se apoya en la
utilización masiva, para el conjunto de las
actividades económicas, sociales y culturales, de
una ciencia,
la informática, de una tecnología, la de redes de
comunicación, y de un instrumento específico,
la
computadora. Gracias a las posibilidades que ofrecen
las redes, se puede generar un medio alternativo de
difusión. Para el sector cultural, los por-tales son
una vía importante para publicitar local, regional y
mundialmente, la
organización, servicios o procesos culturales de una
región. Esta investigación propone la
construcción de un portal cultural basado en
patrones de diseño para el Web. El objetivo es
detectar la problemática que existe actualmente en
el diseño de sitios web utilizando de manera
adecuada los patrones de diseño, con el fin de
satisfacer las necesidades de los usuarios.Los portales son sitios de gran movilidad de
información en donde se aprovecha al máximo
las bondades del Internet.
La mecánica de los portales es diferente
según sea el tipo de información que se
ofrece, pero la meta
final siempre es la publicidad o servicios.Otro de los aspectos importantes de los portales
es referente a la gran cantidad de contenidos y
aplicaciones que le dan funcionalidad a los usuarios y los
invitan a regresar con frecuencia. Podemos decir que para
el sector cultura,
los portales son una vía importante para publicitar
local, regional y mundialmente la organización, servicios o procesos
culturales, además no solamente mejoran la calidad
y eficiencia en la difusión de la
oferta
cultural, sino que se reducen costos
de impresión, reproducción y distribución de
una gran cantidad de información, se permite
mantener actualizada e integrada la información para
la toma de
decisiones y finalmente tienen un gran poder de
gestión.Actualmente en el web nos encontramos con algunos
sistemas carentes de un esquema y una estructura de
organización, lo que provoca: una navegación
inconsistente, uso indebido de la rotulación,
vínculos inválidos, uso indebido del
hipertexto, etc.Con base en lo anterior actualmente existe una
serie de patrones de diseño para el web, con los
cuales si se aplican de manera adecuada, se logrará
satisfacer las necesidades cada vez más exigentes
del usuario. Tomando en cuenta que un patrón es una
forma de describir una solución a un problema
recurrente bajo un determinado contexto, en el presente
trabajo se propone hacer una categorización de
patrones principalmente en los aspectos referentes a
navegación, elementos de página, mecanismos
de búsqueda y rotulación.- Uso de patrones para el diseño de sitios
web [GL03]Investigadores del Departamento de Lenguajes y
Sistemas Informáticos, Facultad de
Informática y Estadística, de la Universidad de
Sevilla, lleva a cabo esta investigación, que se
expone a continuación.El número de propuestas de
reutilización en ingeniería de requisitos es
aún escaso, sobre todo a nivel de requisitos de
cliente o requisitos–C, normalmente expresados en
lenguaje natural. En este caso, la utilización en
más de 80 prácticas académicas y en
tres proyectos reales, de las plantillas y patrones
lingüísticos para requisitos–C, ha puesto
de manifiesto la posibilidad de aplicar técnicas de
reutilización durante la fase de ingeniería
de requisitos. Como resultado de esta experiencia se han
identificado requisitos que, con pequeñas
variaciones, aparecen en un elevado número de
desarrollos. A dichos requisitos, una vez generalizados al
eliminar los detalles específicos, los hemos
denominado patrones de reutilización de requisitos,
o abreviadamente, patrones–R.Entre otros, los resultados más
interesantes de la normalización del formato de los
requisitos desarrollada, ha sido la posibilidad de
compararlos e identificar patrones de reutilización,
tanto a nivel de requisitos de cliente (requisitos–C,
normalmente expresados en lenguaje natural) como a nivel de
requisitos de desarrollador (requisitos–D,
habitualmente modelos conceptuales), que facilitan el
desarrollo y mejoran la calidad de las especificaciones de
requisitos.Las relaciones de rastreabilidad realizadas entre
requisitos–C, requisitos–D, e incluso elementos
de menor nivel de abstracción como componentes
software, ha permitido también plantear la
posibilidad de reutilizar estructuras complejas, desde
requisitos–C hasta código, obteniendo
así una reutilización vertical que abarque
distintos niveles de abstracción del desarrollo de
software.En un futuro esperamos identificar nuevos
patrones–R, sobre todo a partir de la disponibilidad
del prototipo de herramienta CASE para ingeniería de
requisitos (figuras 9, 10) que se ha desarrollado como
parte del proyecto
CICYT MENHIR, lo que permitirá el tratamiento
automatizado de las especificaciones de requisitos
así como el desarrollo de asistentes automatizados
que ayuden a aplicar las ideas presentadas en este
artículo o la aplicación automática de
métricas. - Identificación de Patrones de
Reutilización de Requisitos de Sistemas de
Información [DU00]Hohpe y Woolf, en su libro: Enterprise
Integration Patterns [HW03], proponen el uso de los
patrones para una tarea intrínsecamente compleja,
como es la integración de la empresa. Se centra el
estudio, principalmente, en las estructuras de
mensajería usadas para construir soluciones de
integración.El libro aborda los distintos aspectos de la
integración de una organización, desde
la perspectiva de un arquitecto, mostrando los patrones de
arquitectura y de diseño involucrados en el proceso,
como también desde la perspectiva del desarrollador,
con implementaciones de los mismos conceptos que se
explican durante el estudio.Plantean la justificación de la existencia
de la mensajería en cualquier proyecto y como
obtener el mejor provecho de ésta. Explica
detalladamente como debe funcionar un sistema de
mensajería y describen también como utilizar
los patrones involucrados en los componentes de este
sistema. - Patrones de Integración de la Empresa
Investigadores de las universidades de
Cádiz y de Granada [IG03] proponen la
elaboración de un modelo
sencillo e intuitivo para la especificación
estructural de patrones de diseño y su
integración en UML, con la finalidad de conseguir
verdaderas plantillas reutilizables.En su estudio plantean que los lenguajes de
modelado deben contemplar los patrones de diseño
como elementos de modelado de primer orden, estableciendo
para éstos una notación, semántica y tratamiento adecuado.
Asimismo también proponen que las herramientas de diseño de software
basadas en estos lenguajes deberían facilitar su
definición, aplicación y validación en
contextos específicos.En su artículo exponen los inconvenientes
que presenta UML para representar adecuadamente la esencia
de un patrón, resumen la filosofía de su
modelo (conceptos principales que intervienen y como se
relacionan) y por último especifican el
Patrón Abstract Factory aplicando la nueva
aproximación que proponen en su estudio. - Modelado Estructural de Patrones de
Diseño - Patrones de Interacción: Una Solución para
el Diseño de la Retroalimentación Visual de Sistemas
Interactivos
Investigadores del Instituto Nacional de
Astrofísica Óptica y Electrónica (INAOE) de
México [MR02], proponen en su
investigación a patrones de interacción como
mecanismo de integración entre la Ingeniería de
Software y la Interacción Hombre
Máquina (IHM) con el objeto de diseñar
la retroalimentación visual en función
del contexto de la tarea del usuario, y permitir a la vez la
comunicación entre los especialista involucrados en su
desarrollo.
El presente trabajo propone como solución una
categorización de patrones de interacción que
permitan capturar la experiencia en el diseño de la
retroalimentación visual de un sistema de
información en término de los requerimientos
del usuario.
La retroalimentación visual es forma de
comunicación visual que va del sistema en dirección al usuario. La
retroalimentación visual es un factor que corresponde
tanto a la ingeniería de software como a la IHC pues
contribuye respectivamente en la utilidad y la
usabilidad de un sistema interactivo. La utilidad concierne a la
funcionalidad del software del sistema caracterizándolo
para lo que fue hecho. La usabilidad concierne a guiar
pertinentemente al usuario en su tarea y hacer que el sistema se
fácil de usar.
De lado de la IHC, se han propuesto un gran
número de recomendaciones ergonómicas para la
retroalimentación visual, pero sin especificar "el como"
diseñar y concretizar la retroalimentación visual
en un SI. Ahora bien, del lado de la Ingeniera de Software
numerosas técnicas de programación visual y
herramientas
CASE se han propuesto para desarrollar componente de software
para la retroalimentación visual.
La investigación desarrollada preconiza el uso de
patrones de interacción (o de interfaz) como un mecanismo
integrador entre los factores de Ingeniera de Software y la IHC,
para así diseñar la retroalimentación visual
con un alto nivel de usabilidad y permitir a la vez la
comunicación entre los especialista involucrados en su
desarrollo. Bajo este objetivo, primero definen la necesidad de
los patrones de interacción en el diseño de la
retroalimentación visual. Luego proponen una
categorización de patrones de interacción en
función de la naturaleza lingüística de la
retroalimentación visual. Al final, la
investigación presenta a detalle el diseño de
diversos patrones de interacción derivados de la
categorización propuesta.
La idea de los patrones ha adquirido gran
popularidad. En el ámbito de la ingeniería de
software se están desarrollando muchos proyectos de
investigación al respecto. Como hemos visto en el
presente trabajo, no sólo se esta aplicando en los
llamados patrones de diseño, sino que la idea esta
transportándose a otras actividades del desarrollo de
software.El concepto de patrón tiene carácter
general y por consiguiente es aplicable a un sin
número de situación de diferente tipo, estilo,
entorno, etc. En lo referente al software, la
aplicación de los patrones esta siendo utilizada con
éxito en muchos ámbitos de la
ingeniería de software. En definitiva esta mejorando
las prácticas en el desarrollo de sistemas de
información.Donde exista la posibilidad aplicación del
criterio profesional experimentado, a un problema recurrente,
la idea de patrones de Alexander podrá usarse para
reutilizar y transmitir dichas experiencias a profesionales
menos experimentados.- Conclusiones
- Referencias
[GA95] Gamma, E. Helm, R. Jonson, R. & Vlissides,
J.. Design Patterns: Elements of Reusable Object-Oriented
Software. Addison Wesley, (1995).
[BU96] Buschmann, F. Meunier, R. Rohnert, H. Sommerlad,
P. Stal, M. Pattern-Oriented Software Architecture. A System
of Patterns. Wiley, (1996).
[BR98] Brown, W. Malveau, R. "Skip" McCormick III, H.
Mowbray, T. Anti Patterns. Refactoring software, Architectures
and Proyects in Crisis.
Wiley, (1998).
[DU02] van Duyne, D. Landay, J. Hong, J. The Design
of Sites: Patterns, Principles, and Processes for Crafting a
Customer-Centered Web Experience. Addison-Wesley,
(2002).
[HW03] Hohpe, G. Woolf, B. Enterprise Integration
Patterns. Addison-Wesley. (2003)
[ARR] Patrones, Ricardo Davis, 1996. http://www.arrakis.es/~devis/patrones.ppt
[última visita 03-02-2005]
[CPD] Catálogo de Patrones de Diseño J2EE.
I, Juan Antonio
Palos, 1999 – 2005. http://www.programacion.com/java/tutorial/patrones/
[última visita 03-02-2005]
[ERP] El
Rincón del Programador, 2002. http://www.elrincondelprogramador.com/
[última visita 04-02-2005]
[OKT] Hanna Oktaba, 2005.
http://www.mcc.unam.mx/~cursos/Algoritmos/javaDC99-2/patrones.htm
[última visita 04-02-2005]
[RA04] Ramirez, A. "Introducción a los Patrones de
Diseño." Creative Commons. Agosto 2004.
[DU00] Durán Toro, A. Ruiz Cortés, A.
Corchuelo Gil, R. Toro Bonilla, M. "Identificación de
Patrones de Reutilización de Requisitos de Sistemas de
Información".
WER. 2000.
[GL03] Galavíz, P. Muñoz, J. Santiago, C.
"Diseño de un Portal Cultural Basado en Patrones de
Diseño para el Web". CORE. 2003.
[IG03] Isla, J. y Gutierrez, F. "Modelado Estructural de
Patrones de Diseño: Diagramas REP".
SugarLoafPLoP. 2003.
[MR02] Muñoz, J. y Rodríguez, G. "Patrones
de Interacción: Una Solución para el Diseño
de la Retroalimentación Visual de Sistemas Interactivos".
CIC. 2002.
Omar Hurtado Jara
Doctorado en Ingeniería
Informática
Universidad Carlos III
Madrid, España