Evolución y Orientaciones de Patrones

Enviado por omarh

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.

Características

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.

Descripción de un Patrón

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.

Tipos de patrones

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.

Catálogo de patrones

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.

Antipatrones

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.

Evolución

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.

Orientaciones de aplicación

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.

Investigaciones actuales (estado del arte)

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