204

IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 4, JULY 2007

Una Aproximación Basada en Patrones para el Modelado Conceptual de Sistemas Cooperativos José Luis Isla Montes, Francisco Luis Gutiérrez Vela y Patricia Paderewski Rodríguez

 Resumen-- La sociedad actual demanda el desarrollo de sistemas que den soporte al trabajo colaborativo (CSCW). Sin embargo, su inherente complejidad dificulta la especificación de los requisitos reales, así como su producción rápida y barata. Para analizar, diseñar y desarrollar sistemáticamente este tipo de sistemas en el seno de nuestro grupo de investigación se ha creado la metodología AMENITIES. Sin embargo, durante el modelado conceptual del sistema nos encontramos con situaciones que deben ser modeladas una y otra vez. En este trabajo mostramos como pueden usarse patrones, a nivel conceptual, en varias de las fases de aplicación de la metodología AMENITIES. Para ello vamos a usar un profile UML que facilita la definición de estos patrones software. Usando una plantilla uniforme describimos y modelamos dos ejemplos de patrones aplicables en diferentes vistas del sistema de acuerdo con la metodología. Palabras clave -- Software engineering, Cooperative systems, Modeling, Software requirements and specifications, Software reusability.

I. INTRODUCCIÓN

L

os sistemas CSCW (Computer Supported Cooperative Work) son inherentemente complejos y su desarrollo requiere de métodos y técnicas específicas de modelado con capacidad para especificar fielmente sus requisitos reales. Adicionalmente, para atender las exigencias del mercado, hay que buscar mecanismos apropiados que ayuden en la producción de sistemas fiables de forma rápida y barata. Con el propósito de satisfacer la demanda que nuestra sociedad reclama entorno al desarrollo de sistemas CSCW, en el seno de nuestro grupo de investigación se ha creado una metodología para el análisis, diseño y desarrollo de sistemas cooperativos denominada AMENITIES (A MEthodology for aNalysis and desIgn of cooperaTIve systEmS) [7,8]. A pesar del potencial que nos brinda esta metodología, cada vez que modelamos un nuevo sistema hay que partir prácticamente de cero. Sin embargo, durante el modelado conceptual de estos sistemas suelen aparecer conceptos y Este trabajo está financiado por la Comisión Interministerial para la Ciencia y la Tecnología (CICYT) - Proyecto AMENITIES - TIN2004-08000C03-02. J. L. Isla pertenece al Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Cádiz, España (e-mail: [email protected]). F. L. Gutiérrez y P. Paderewski pertenecen al Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Granada, España (e-mail: {fgutierr, patricia}@ugr.es). Los tres autores forman parte del Grupo de Investigación en Especificación, Desarrollo y Evolución del Software (GEDES).

escenarios comunes que deben ser descritos reiteradamente. Capturar dichas situaciones, representarlas y documentarlas para facilitar su posterior reutilización en otros proyectos es de un gran valor, tanto desde el punto de vista del proceso como de la propia especificación. Desde la aparición de los primeros trabajos relacionados con la aplicación de patrones de software en el terreno de la ingeniería del software [1], éstos se han erigido como un valioso instrumento para la descripción y reutilización del conocimiento experto durante las distintas fases del ciclo de vida del software. Sin embargo, su explotación no ha sido la misma en todos los campos de aplicación y fases del desarrollo. Existen algunos trabajos [3,4,5] relacionados con el estudio de patrones aplicables al desarrollo de sistemas CSCW. Sin embargo, a pesar de la inherente complejidad de estos sistemas y de la relevancia que las decisiones tomadas en fases tempranas del desarrollo tienen sobre el producto final, salvo alguna excepción [6], no existen apenas propuestas relacionadas con la aplicación de patrones específicos, denominados patrones de análisis o conceptuales [2], durante estas fases iniciales. Tampoco se aborda la integración de esta clase de patrones dentro de una metodología concreta que permita su aplicación sistemática. El principal obstáculo reside en la inexistencia de una notación adecuada que facilite la representación y aplicación de este tipo de patrones en el marco de una metodología especializada. En este trabajo introducimos la metodología AMENITIES (sección II) y mostramos la aplicación de un profile UML para la representación de patrones de software que nos va a permitir modelar y aplicar patrones conceptuales dentro de dicha metodología (sección III). A continuación presentamos una plantilla uniforme de descripción que incluye todos los atributos necesarios para la correcta selección, uso y comparación de este tipo de patrones (sección IV). En base a esta plantilla, describimos dos ejemplos de patrones conceptuales aplicables durante el modelado de vistas diferentes en dicha metodología (sección V). Por último (sección VI), exponemos nuestras conclusiones y trabajo futuro. II. LA METODOLOGÍA AMENITIES AMENITIES [7,8] es una metodología, basada en modelos de comportamiento y tareas, para el análisis, diseño y desarrollo de sistemas cooperativos (Fig. 1). Esta metodología está centrada en el modelado inicial del

LUIS ISLA et al.: A PATTERN-BASED APPROACH FOR

sistema, usa el punto de vista de los usuarios y tiene muy en cuenta aspectos relacionados con el grupo (conciencia de grupo, relaciones entre usuarios, dinámica del grupo, representación de aspectos sociales, etc).

Fig. 1. Modelos contemplados en la metodología AMENITIES

Dentro del modelo de desarrollo propuesto se distinguen tres fases. Una primera fase de obtención y representación del modelo de requisitos, donde se describen los elementos más representativos del sistema, usando técnicas como la etnografía aplicada (traduce resultados empíricos en ideas para nuevos sistemas), los casos de uso (identifican procesos y tareas relevantes) o modelos teóricos (permiten el análisis de actividades de cooperación y propiedades abstractas relacionadas con aspectos de diseño). En una segunda fase se realiza el modelo cooperativo del sistema, modelo conceptual que constituye el núcleo central de la metodología. Su propósito es dar una descripción del sistema independientemente de su implementación, proporcionando así una mejor comprensión del dominio del problema, dada la complejidad que caracteriza a este tipo de sistemas. La descripción es realizada usando una notación basada en UML y que se denomina COMO-UML [8]. El modelo cooperativo representa el sistema mediante cuatro vistas realizadas bajo diferentes niveles de abstracción: - Vista organizacional. Por medio de los llamados diagramas de organización, los cuales están basados en los diagramas de estados de UML, se modela la estructura estática y dinámica de la organización del sistema. Los estados representan los diferentes roles que pueden desempeñar los miembros en la organización y las transiciones reflejan los posibles cambios de rol en virtud del cumplimiento de ciertas restricciones. Estas restricciones pueden ser capacidades (restricciones cognitivas impuestas a un actor para participar bajo un rol determinado) o leyes (restricciones impuestas por la propia organización que identifican las reglas sociales que deben ser preservadas en el grupo). - Vista cognitiva. Representa las tareas que puede llevar

205

a cabo cada miembro del grupo en el escenario colaborativo. Por un lado se define la “interfaz del rol”, el cual incluye las características más relevantes del conjunto de tareas a realizar (su naturaleza cooperativa, mecanismos de activación y modos de sincronización, interrupción de unas tareas por otras, etc.), y por otro lado se describen las tareas mediante diagramas de actividades que reflejan los participantes, secuencialidad, concurrencia, optatividad, etc. En esta vista pueden aparecer elementos de las vistas de información (documentos, datos, recursos, etc.) y de interacción (protocolos). - Vista de interacción. Se analiza la forma de comunicación entre participantes y los recursos usados mediante protocolos de interacción de alto nivel. - Vista de la información. Refleja la información que es compartida en el escenario o que se utiliza para la comunicación (documentos, eventos, recursos, etc.). Esta información se puede describir a través de los diagramas de clases y de interacción de UML. Estas cuatro vistas permiten reflejar todos los aspectos relevantes del sistema. A partir del modelo cooperativo se puede construir una máquina de estados en UML y traducirla a una red de Petri coloreada (CPN) que permitiría el análisis y verificación de determinadas propiedades (interbloqueos, alcanzabilidad, etc.). En una última fase, se pasaría del modelo cooperativo a un diseño inicial del sistema basándonos en una arquitectura [9] que permite integrar de manera sencilla el modelo previamente propuesto. III. LA INTEGRACIÓN DE PATRONES DE SOFTWARE CON AMENITIES

Para agilizar el desarrollo del modelo cooperativo y hacerlo más comprensible y fácil de mantener integramos el uso de patrones de software dentro del marco metodológico de AMENITIES. En concreto capturamos, representamos y documentamos conceptos y escenarios comunes que aparecen a menudo durante el modelado conceptual de este tipo de sistemas, para después seleccionarlos y aplicarlos en distintos proyectos llevados a cabo a través de dicha metodología. Los patrones pueden aplicarse en las diferentes vistas del sistema que la metodología proporciona. Habitualmente, comenzamos aplicando patrones durante el modelado de la estructura organizativa del sistema (vista organizacional). Posteriormente, identificamos tareas de la vista cognitiva que siguen patrones de conducta determinados y en los que la utilización de recursos también puede ser generalizada. Por último, usamos patrones que especifican protocolos de comunicación o coordinación para describir procesos de comunicación usados en la vista de interacción. La notación utilizada por AMENITIES (COMO-UML) está basada en UML, sin embargo, el tratamiento que hace UML de los patrones no es suficiente para nuestro propósito. UML usa colaboraciones parametrizadas que permiten especificar estructuras formadas por clases/objetos reutilizables en una etapa de diseño orientado a objetos. No

206

IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 4, JULY 2007

obstante, durante el modelado de un sistema cooperativo, además de objetos y clases, usamos otros tipos de elementos (estados, actividades, paquetes, eventos, actores, roles, etc.) que nos permiten reflejar muchos otros aspectos relevantes para esta clase de sistemas (flujos de trabajo, estructura social de los usuarios, dinámica de la organización, protocolos sociales, cooperación entre actores, etc.), los cuales son recogidos en fases tempranas de modelado. Para solventar este problema hemos definido un profile [10] que extiende UML a través de un conjunto mínimo de elementos, permitiéndonos representar de manera simple, intuitiva y fácil de comprender tanto la vista interna como externa de un patrón de software, independientemente de los elementos de modelado que intervengan. Según este profile, los patrones se consideran modelos genéricos parametrizados (de cualquier tipo) que actúan como plantillas flexibles para la construcción y/o descripción de familias de modelos semejantes (instancias del patrón). Para conseguir tal flexibilidad, aplicamos restricciones de multiplicidad, optatividad, agrupamiento o incertidumbre sobre los elementos del patrón, limitando así las posibles variantes de sus instancias. Las instancias se crean/describen mediante la ligadura (uno a uno, uno a varios) de cada uno de sus parámetros con cada uno de los elementos de estas instancias (argumentos), siempre y cuando éstos cumplan las restricciones asociadas con sus parámetros, coincidan sus tipos y entre los argumentos se den las mismas relaciones que entre los parámetros. IV. UNA PLANTILLA PARA LA DESCRIPCIÓN UNIFORME DE PATRONES

De manera similar a otros autores [1], aunque adaptada a nuestro propósito con AMENITIES, proponemos la plantilla que aparece en Tabla 1 para reflejar uniformemente los aspectos que definen un patrón, así como facilitar su aprendizaje, comparación y uso. TABLA I PLANTILLA PARA LA DESCRIPCIÓN UNIFORME DE PATRONES EN AMENITIES

Nombre: Debe ser significativo y reflejar la esencia del patrón en pocas palabras. Alias: Otro nombre por el cual es conocido. Clasificación: Según una taxonomía previamente establecida. Vista: Vista/s del modelo cooperativo de AMENITIES en la que puede usarse el patrón. Problema: ¿Cuál es el escenario que pretendemos describir? Contexto: ¿En qué situaciones se puede aplicar?, ¿cómo reconocer dichos escenarios? Participantes: Descripción de los elementos participantes y sus responsabilidades. Solución: Modelo que define el patrón. Puede incluir variantes. Explicación: Descripción de la solución que se propone. Ejemplo: Aplicación del patrón a un caso concreto. Patrones relacionados: Otros patrones que forman parte del mismo catálogo y con los cuales se relaciona.

V. CASO DE ESTUDIO A continuación, como muestra de utilización de la plantilla y el profile, definimos un par de ejemplos de patrones aplicables en vistas diferentes de un sistema según AMENITIES. Éstos describen situaciones comunes durante el modelado conceptual de sistemas cooperativos. El patrón Joint Venture (apartado A), aplicable durante el modelado de la vista organizacional de un sistema con AMENITIES, describe una organización típica procedente del ámbito de las alianzas estratégicas entre empresas que puede ser trasladada a muchos otros ámbitos (véase la sección ejemplo del patrón). A nivel de organización los patrones ayudan a modelar sistemas en los que las estructuras organizativas son complejas. Además, facilitan el proceso de elicitación de requisitos al estructurar la obtención de información (qué usuario es responsable de las actividades, qué pasa cuando no está ese usuario, cómo se adquieren las responsabilidades, etc.). El patrón Meeting Process (apartado B) describe la secuencia típica de tareas asociadas a la realización de una reunión. Éste es aplicable en la vista cognitiva del modelo cooperativo de AMENITIES. El análisis y la generalización de estos procesos permite reducir tanto el tiempo de modelado como el de diseño y desarrollo de los elementos necesarios para implantarlos en el sistema software. A. Patrón JOINT VENTURE Nombre: Joint Venture. Alias: Desconocido. Clasificación: Organización. Vista: Organizacional. Problema: Describir la organización de un grupo de socios, cada uno especializado en la realización de una tarea concreta, que unen sus capacidades y recursos para alcanzar objetivos más ambiciosos, obteniendo así una serie de ventajas colectivamente (inversión parcial, costes de mantenimiento más bajos, mayores beneficios, recursos compartidos, etc.). Contexto: - El objetivo común se descompone en varios subobjetivos. - Cada socio está especializado y es responsable de llevar a cabo alguno de los subobjetivos. - Existe un actor que se ocupa de coordinar las actividades entre los distintos socios y otro encargado de dirigir y representar la asociación. Participantes: Rol Socio - Ejecuta las tareas necesarias para lograr alguno de los subobjetivos marcados (tarea ObtenerSubobjetivo). - Comparte sus recursos con los demás socios (tarea CompartirRecurso). Rol Administrador - Se encarga de las relaciones con el exterior (tarea RepresentarAlianza). Rol Administrador::Director

LUIS ISLA et al.: A PATTERN-BASED APPROACH FOR

Decide la estrategia de la alianza (tarea TomarDecisionesEstratégicas). Rol Administrador::Coordinador - Convoca reuniones con los socios de la alianza (tarea ConvocarSocios). - Realiza reuniones de coordinación con los socios (tarea ReuniónCoordinación). - Toma decisiones de coordinación (tarea CoordinarSocios). Rol Socio::Representante - Se reúne con el coordinador de la alianza cuando es convocado (tarea ReuniónCoordinación). Solución: -

JointVenture {Classification = Organización}

organization Joint Venture

organization Socio

role-pattern tasks Administrador: RepresentarAlianza Socio: CompartirRecurso, ObtenerSubobjetivo

role-pattern tasks Representante:ReuniónCordinación

role Socio 2..*

[Subobjetivo?]

[Elegido]

[Administración?]

role Representante 1

role Administrador 1..2

role Administrador role-pattern tasks Coordinador: ConvocarSocios, ReuniónCoordinación, CoordinarSocios Director: TomarDecisionesEstratégicas

[CoordinaciónSocios?]

role Coordinador 1

[Dirección?] [Dirección? and DirectorNoDisponible]

role Director 1

Fig. 2. Modelo que define el patrón Joint Venture

Explicación: Según Fig. 2, cuando un actor posee la capacidad para poder realizar uno de los subobjetivos del objetivo común ([Subobjetivo?]), por ejemplo fabricar una de las piezas de un avión cuando el objetivo es construir un avión, éste puede desempeñar el papel Socio. Obsérvese que el cardinal de este rol indica que debería haber al menos un par de socios. Dentro de la organización correspondiente a cada socio pueden existir otros roles realizando tareas determinadas. En el diagrama se destaca el rol Representante para indicar que este rol es imprescindible dentro del patrón, ya que una tarea clave dentro de la organización va a consistir en la realización de reuniones (tarea ReuniónCoordinación) entre los actores que desempeñan el rol de Representante y el que actúa como Coordinador de los socios. La sección role-pattern tasks del patrón especifica las tareas esenciales que cada uno de los roles debería

207

desempeñar bajo el contexto del patrón. Por supuesto, un rol podrá desarrollar además otros tipos de actividades, pero como mínimo debería realizar esas. Tal y como se puede observar, el rol Socio tiene que realizar al menos las tareas CompartirRecurso y ObtenerSubobjetivo. Por otro lado, tal y como se puede advertir en el diagrama de organización del rol Socio, debe haber un actor que desempeñe el rol de Representante si éste resulta elegido por el resto de socios. El Representante tiene la obligación de reunirse con el Coordinador cuando sea preciso (tarea ReuniónCoordinación). Esta actividad será colaborativa y, por tanto, es común para el Coordinador y el Representante. Cuando un actor tenga la capacidad necesaria para poder administrar el Joint Venture, podrá participar como Administrador (obsérvese que solamente puede haber uno o dos actores que actúen como tales). En ese estado, un actor debería desempeñar al menos la tarea RepresentarAlianza, encargándose de las relaciones externas de la alianza. Si además tiene capacidad para coordinar los socios, podrá desempeñar el rol de Coordinador (éste podrá desempeñarlo un único actor) y, por consiguiente, tendrá que reunirse con los representantes de los socios cuando sea necesario (tareas ConvocarSocios y ReuniónCoordinación) además de realizar labores de coordinación de éstos (tarea CoordinarSocios). Si tiene capacidad para dirigir la estrategia de la alianza podrá desempeñar el rol de Director (obsérvese que podrá ser desempeñado también por un único actor), cuya principal misión es la de tomar decisiones estratégicas para la alianza (tarea TomarDecisionesEstratégicas). En este mismo diagrama se describe, mediante una transición aditiva, bajo qué ley un actor que desempeña el rol de coordinador podrá asumir además el rol de director. Tal y como se puede observar, esto podrá suceder siempre y cuando el Coordinador tenga capacidad de dirección y el Director no esté disponible (el Coordinador actúa en sustitución del Director). Ejemplo: En Fig. 3 se utiliza el patrón Joint Venture para guiar el modelado de la estructura organizativa de un proyecto de investigación. Cuando un proyecto es lo suficientemente amplio éste se divide en subproyectos asignados a diferentes grupos de investigación. Las labores de coordinación de todos los grupos suelen estar realizadas por alguien que mantiene contactos con representantes de los distintos subproyectos. Además, debe existir una cabeza visible con capacidad para dirigir todo el proyecto. Patrones relacionados: Production Line Pattern.- Los socios pueden estar organizados como una cadena de trabajo si existe secuencialidad entre los subobjetivos. B. Patrón MEETING PROCESS Nombre: Meeting Process. Alias: Desconocido. Clasificación: Proceso.

208

IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 4, JULY 2007

organization ProyectoInvestigación

[TareaSubproyecto?]

role AdministraciónProyecto

Role CoordinadorSubproyectos 1

[Coordina?]

role GrupoSubproyecto 2..*

[AdministraciónProyecto?]

[Dirección? and representación?]

[Dirección? and DirectorNoDisponible]

role DirectorProyecto 1

role AdministradorProyecto 1..2





organization GrupoSubproyecto

Coordinador Director

Socio

Socio Administrador Coordinador Director Representante

Administrador

Role PersonalApoyo 0..*

[ApoyoGrupo?]

[Investiga?]

role Investigador 1..*

JointVenture

[EscribeArtículos?] [Coordinación?] Representante

Role AutorArtículo 1..*

[EscribeArtículos?]

role CoordinadorGrupo 1



Fig. 3. Modelo de la estructura organizativa de un proyecto de investigación a partir del patrón Joint Venture

Vista: Cognitiva. Problema: Describir las tareas necesarias para llevar a cabo una reunión. Contexto: Existe un grupo de personas que necesitan reunirse para tratar uno o varios temas y llegar a algún acuerdo. Participantes: Actividad FijarReunión - Los participantes se ponen de acuerdo en la realización de una reunión para tratar una serie de temas. - En esta actividad participan al menos la persona que lidera la reunión (Líder) y el que la convoca (Convocante). Actividad ConvocarReunión - Se envía a todos los participantes información sobre el lugar, fecha, hora y asuntos a tratar. - El actor que desempeña el rol de convocante es el encargado de ejecutar la actividad. Actividad AsistirReunión - Se reúnen las personas que han sido convocadas (MiembroReunión) en el lugar, fecha y hora indicados y se discuten los asuntos objeto de la convocatoria. Actividad LevantarActa - El actor que actúa como Secretario redacta el acta de la reunión. Actividad EnviarActa (Convocados) - El secretario envía el acta a todas las personas que fueron convocadas a la reunión, es decir, a los miembros de la reunión. Objeto Acta - Documento que contiene lo sucedido, tratado o

acordado en la reunión. Solución: Meeting Process {Classification = Process}

cooperative-task ProcesoReunión

Convocante + Líder: FijarReunión

Convocante: ConvocarReunión [FechaHoraReunión and MiembroReuniónDisponible]

MiembroReunión: AsistirReunión

{0..1} Secretario: LevantarActa Acta: Documento Secretario: EnviarActa (Convocados)

Fig. 4. Modelo que define el patrón Meeting Process

LUIS ISLA et al.: A PATTERN-BASED APPROACH FOR

209

Explicación: En Fig. 4 se muestra que la tarea ProcesoReunión es una tarea colaborativa en la que,

embargo, aunque muchas veces modelamos escenarios similares, dichos modelos no son documentados y reutilizados

cooperative-task ReuniónComitéProgramaConferencia

SecretarioCP + PresidenteCP: PlanificarReunión

SecretarioCP: AnunciarReunión



FijarReunión ConvocarReunión AsistirReunión LevantarActa EnviarActa Acta

FijarReunión [MomentoReunión] ConvocarReunión

MiembroCP: AsistirReunión

AsistirReunión LevantarActa

SecretarioCP: EscribirListaArtículosAceptados

Meeting Process

Acta

ListaArtículosAceptados: Documento

EnviarActa

SecretarioCP: PublicarListaArtículosAceptados

Fig. 5. Modelado del proceso seguido para llevar a cabo la reunión de un comité de programa de una conferencia a partir del patrón Meeting Process

inicialmente, al menos la persona que lidera la reunión (Líder) y el que la convoca (Convocante) se ponen de acuerdo para fijar una reunión (FijarReunión). Después, el actor que desempeña el rol de convocante manda una convocatoria de reunión (ConvocarReunión) a todas las personas que necesitan tratar en común una serie de temas. A continuación, cuando llega el día y hora indicado en la convocatoria, se realiza la reunión (AsistirReunión) de los miembros convocados (MiembroReunión). Más tarde, si es necesario (la restricción {0..1} indica opcionalidad), el Secretario elabora un acta (LevantarActa) de la reunión y la envía (véase objeto Acta) a todos las personas convocadas (EnviarActa (Convocados)). Ejemplo: En Fig. 5 describimos el proceso que sigue un comité de programa de una conferencia para llevar a cabo una reunión de selección de artículos. Patrones relacionados: Meeting Convocation Pattern.- Describe las acciones necesarias para la elaboración y emisión de una convocatoria. VI. CONCLUSIONES Y TRABAJO FUTURO La demanda de sistemas para el soporte del trabajo colaborativo es cada día mayor. Sin embargo estos sistemas son inherentemente complejos, lo que dificulta la especificación de sus requisitos reales y su producción rápida y barata. A este respecto, nuestro grupo de investigación ha creado una metodología para el análisis, diseño y desarrollo de sistemas cooperativos denominada AMENITIES. Sin

en distintos proyectos. En este trabajo mostramos un par de ejemplos de aplicación y definición de patrones, a nivel conceptual, con objeto de facilitar la descripción y reutilización de conceptos y escenarios comunes que podemos encontrar durante la aplicación de esta metodología. Los patrones los empleamos como piezas de conocimiento reutilizable para agilizar la construcción y especificación de unos modelos a partir de otros (modelo del patrón), dando lugar a modelos más comprensibles y fáciles de mantener. Al mismo tiempo, éstos nos proveen de un vocabulario común, ayudando en la detección, comunicación y discusión de los problemas típicos de modelado. Partimos de un trabajo previo [10] que define un profile UML para el modelado de patrones de software independientemente del tipo de modelo, y usamos dicho profile para extender COMO-UML (notación basada en UML propia de la metodología AMENITIES) con el propósito de poder representar y aplicar patrones durante el modelado conceptual de sistemas cooperativos. Hemos propuesto una plantilla de descripción uniforme de patrones que nos va a permitir estudiarlos, catalogarlos, compararlos, relacionarlos y aplicarlos, conectándolos convenientemente con el proceso de construcción del modelo cooperativo (nivel conceptual) utilizado en AMENITIES. Por medio de esta plantilla, hemos descrito dos ejemplos típicos de patrones conceptuales, uno de organización (Joint Venture Pattern) y otro de proceso (Meeting Process Pattern). En estos momentos estamos construyendo un catálogo de patrones que facilite la especificación completa del modelo

210

IEEE LATIN AMERICA TRANSACTIONS, VOL. 5, NO. 4, JULY 2007

cooperativo [11]. En el futuro nuestra intención es establecer las posibles relaciones que pueden existir entre estos patrones (patrones conceptuales) con aquellos que pueden ser aplicados en una fase de diseño posterior (patrones de diseño). VII. AGRADECIMIENTOS Este trabajo ha sido financiado por el AMENITIES (CICYT TIN2004-08000-C03-02).

proyecto

VIII. REFERENCIAS E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Reading, MA: Addison Wesley Professional Computing Series, 1995. [2] M. Fowler, Analysis Patterns: Reusable Object Models. Booch, G., Jacobson, I. and Rumbaugh, J. (eds.), Object Technology Series, Reading, MA: Addison-Wesley Publishing Company, 1997. [3] D. Martin, I. Sommerville, T. Rodden and S. Viller, “Finding Patterns in the Fieldwork”, in Proceedings of ECSCW 2001, Bonn, Germany, Kluwer Academic Publishers, pp. 39-58, 2001. [4] T. Schümmer, “Constructing a Groupware Pattern Language”, CSCW Workshop on Socio-Technical Pattern Languages, New Orleans, November 16-20, 2002. [5] J. Schümmer, C. Schuckmann, L. M. Bibbó and J. J. Zapico, “Collaborative Hypermedia Design Patterns in OOHDM”, 2nd Workshop in Hypermedia Development: Design Patterns in Hypermedia, 1999. [6] A. Geyer-Schulz and M. Hahsler, “Software reuse with analysis patterns”, in Proceedings of AMCIS 2002, Dallas, TX, 2002. [7] J. L. Garrido, M. Gea , F. L. Gutierrez and N. Padilla, “Designing Cooperative Systems for Human Collaboration”, In Dieng, R.; Giboin, A. (Eds), Designing Cooperative Systems: The Use Of Theories and Models, IOS press, Netherlands, 2000. [8] J. L. Garrido, AMENITIES: Una metodología para el desarrollo de sistemas cooperativos basada en modelos de comportamiento y tareas, PhD Thesis University of Granada, 2003. [9] J. L. Garrido P. Paderewski, M. L Rodríguez., M. Hornos and M. Noguera, “A Software Architecture Intended to Design High Quality Groupware Applications”, in Proc. of The 2005 International Conference on Software Engineering Research and Practice, CSREA Press, pp. 59-65, 2005. [10] J. L. Isla, F. L. Gutiérrez and P. Paderewski, “Un Profile para el Modelado de Patrones de Software”, en Actas de las X Jornadas en Ingeniería del Software y Bases de Datos, Thomson Paraninfo, pp. 265270, 2005. [11] J. L., Isla, F. L. Gutiérrez and M. Gea, “Supporting Social Organization Modelling in Cooperative Work Using Patterns”, In Shen, W. et al. (eds.), Computer Supported Cooperative Work in Design II, LNCS 3865, Springer, pp. 112-121, 2006.

[1]

IX. BIOGRAFIAS José Luis Isla Montes es Licenciado en Informática por la Universidad de Granada (España). Actualmente realiza una tesis doctoral sobre modelado conceptual de sistemas cooperativos en base a patrones. Es profesor del Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Cádiz (España). Su interés investigador se centra principalmente en: especificación de software en base a patrones, sistemas cooperativos y empresariales, ingeniería de requisitos e ingeniería web. Es autor de diversas publicaciones de ámbito nacional e internacional y ha participado en varios proyectos I+D. Es miembro del Grupo de Investigación en Especificación, Desarrollo y Evolución del Software (GEDES) y de la Asociación Interacción PersonaOrdenador (AIPO).

Dr. Francisco Luís Gutiérrez Vela es licenciado y Doctor en Informática por la Universidad de Granada. Sus áreas de investigación son los métodos formales aplicados al desarrollo de sistemas interactivos, los sistemas colaborativos y la aplicación de técnicas hipermedia al aprendizaje colaborativo. En la actualidad es profesor del departamento de Lenguajes y Sistemas Informáticos de la Universidad de Granada (España) y esta involucrado en diversos proyectos de investigación y desarrollo a nivel local y nacional. Desarrolla su labor investigadora dentro del grupo GEDES (Grupo de investigación en Especificación, Desarrollo y Evolución de Software). Es miembro de la Asociación Interacción Persona-Ordenador (AIPO). Dra. Patricia Paderewski Rodríguez es licenciada en informática por la Universidad de Granada en 1990. En la actualidad es profesora del Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Granada desde 1990. Realizó los cursos de doctorado y obtuvo el título de Doctor en 2003 con la tesis titulada “Un Modelo Arquitectónico Evolutivo para Sistemas Software basados en Agentes”. Es miembro del Grupo de Investigación GEDES (Grupo de investigación en Especificación, Desarrollo y Evolución de Software) desde su creación en 1997 hasta la fecha. Actualmente está involucrada en varios proyectos de investigación, desarrollo e innovación (I+D+i), unos de ámbito local, y otros a escala regional y nacional. Sus principales líneas de investigación son la Evolución de Software, Arquitecturas Software Dinámicas y Desarrollo de Sistemas Colaborativos.