Una Propuesta Metodológica basada en Taxonomías para el Desarrollo de Sistemas Groupware Interactivos

Transcripción

1 Una Propuesta Metodológica basada en Taxonomías para el Desarrollo de Sistemas Groupware Interactivos William J. Giraldo 2, Ana I. Molina 1, Manuel Ortega 1, César A. Collazos 3 1 Departmento de Sistemas y Tecnologías de la Información. Universidad Castilla La Mancha. {AnaIsabel.Molina,Manuel.Ortega}@uclm.es 2 Ingeniería de Sistemas y Computación, Universidad del Quindío, Quindío, Colombia wjgiraldo@uniquindio.edu.co 3 Grupo de investigación IDIS, Universidad del Cauca, Popayán, Colombia. ccollazo@unicauca.edu.co Abstract. En este artículo se describe una taxonomía para el diseño de sistemas groupware interactivos. Dicha taxonomía define los objetivos, métodos y principios para la clasificación de modelos y facilita la integración de los mismos. En concreto, mostramos el proceso de integración de dos notaciones como son CIAN, que contempla aspectos de colaboración e interacción personacomputador, y UML, que permite especificar la funcionalidad de los sistemas groupware. Dicho proceso de integración se apoya en una herramienta software desarrollada a tal efecto denominada CIAT. Keywords: Desarrollo basado en modelos, groupware, Interacción Persona- Ordenador, taxonomía, propuesta metodológica. 1 Introducción El desarrollo de sistemas groupware de carácter interactivo integra disciplinas como la Ingeniería de Software, el CSCW (Computer Supported Cooperative Work), y la Ingeniería de la Usabilidad. Los implicados en el desarrollo de estos sistemas provienen de distintas disciplinas, abordan distintas perspectivas durante el diseño y requieren información específica, generando igualmente artefactos concretos [1, 2]. Dicho proceso multidisciplinar de desarrollo es, en sí mismo, un proceso colaborativo en el cual cada persona involucrada necesita un soporte para el diseño de artefactos desde múltiples perspectivas y distintas abstracciones. La información especificada por cada uno de ellos, en su espacio de trabajo, es un complemento para el modelado realizado en los espacios de trabajo del resto de integrantes del equipo de desarrollo. Aunque en la actualidad existe un número creciente de propuestas para el desarrollo de sistemas colaborativos, continúa existiendo una brecha entre los procesos de desarrollo de la funcionalidad de dichos sistemas y el desarrollo de la interfaz de usuario que le da soporte [3]. IX Congreso Internacional Interacción, Albacete 9-11 de Junio de 2008 Grupo LoUISE-Universidad de Castilla-La Mancha

2 50 W. J. Giraldo, A. I. Molina, M. Ortega, C. A. Collazos Con el objetivo de soportar el modelado de sistemas de apoyo al trabajo en grupo se creó una propuesta metodológica, denominada CIAM [4]. CIAM (Collaborative Interactive Applications Methodology) adopta diferentes puntos de vista para crear modelos de sistemas groupware interactivos, y propone una notación específica denominada CIAN [1], la cual promueve el modelado de la colaboración, la comunicación y la coordinación. CIAN soporta adecuadamente el modelado de la colaboración, pero no permite modelar atributos o cualidades 1 del sistema como son la funcionalidad, del modo en que lo hace UML. Por otro lado, ni UML ni RUP están pensados para un diseño de interfaces de sistemas interactivos con características de usabilidad [5]. Cuando en el desarrollo de software se tienen en cuenta varios aspectos, tales como la interacción con el usuario, la colaboración y la funcionalidad, no es fácil identificar la relación existente entre clases u objetos contenidos en los modelos que especifican dichos aspectos, dado que los distintos implicados en el proceso de desarrollo las conceptualizan de manera diferente. Así, por ejemplo, mientras que para un etnógrafo un objeto corresponde a un atributo dentro de una actividad en un diagrama de Inter-Acción 2 en CIAN, para un analista de datos el mismo objeto corresponde a una entidad de negocio en un diagrama de objetos de negocio en UML. De cara a completar el desarrollo de los sistemas groupware, el modelado de la interacción y la colaboración, soportado por CIAN, debe complementarse adecuadamente con el modelado de la funcionalidad, que se basa en el uso de la notación estándar UML. Nuestro propósito es integrar la información especificada con CIAN con la información recogida en los modelos UML, y de esta manera, reducir la brecha existente entre el desarrollo de la interfaz y el proceso de desarrollo de software, así como el mapping entre ambos tipos de representación. Para alcanzar este propósito se propone una taxonomía que define métodos, reglas, principios y lenguajes para la clasificación y organización de toda la información necesaria para la especificación de los sistemas groupware. Este artículo está organizado de la siguiente forma: La sección 2 introduce brevemente el planteamiento del problema al que pretendemos dar solución. La sección 3 presenta algunos trabajos relacionados. La sección 4 muestra la taxonomía propuesta. Finalmente, se exponen las conclusiones extraídas del trabajo desarrollado así como el trabajo futuro que se desprende del mismo. 2 Trabajos relacionados El CSCW encuentra sus bases en los conceptos de colaboración, comunicación, cooperación y coordinación, entre otros. Estos conceptos han sido relacionados con los conceptos de espacio y tiempo, lo cual ha dado lugar a distintas clasificaciones de las herramientas CSCW. La primera clasificación es planteada por Johansen [6]. A partir de ésta se han presentado distintas variaciones en las cuales se definen nuevas 1 Las cualidades son cada una de las características, atributos o aspectos que hacen que la especificación de un sistema se enriquezca. 2 Los diagramas de Inter-Acción de CIAM modelan los procesos y actividades a desarrollar en el contexto del trabajo en grupo. La especificación de cada actividad incluye los roles y objetos implicados en su desarrollo, así como la secuenciación existente entre ellas.

3 Una Propuesta Metodológica Basada en Taxonomías para Groupware 51 categorías que relacionan los conceptos base del CSCW antes mencionados, en función del tiempo y el lugar. Sin embargo, no siempre es posible ubicar herramientas simples, y menos aún sistemas complejos, en dichas categorías. Penichet [7] presenta una taxonomía en la que es posible clasificar una función, una herramienta o un sistema 3 con respecto a las características espacio-temporales y a las características propias de los sistemas CSCW como colaboración, comunicación y coordinación, Fig. 1(a). Esta propuesta, en cierto modo, elimina algunas discrepancias presentadas en las clasificaciones anteriores, permitiendo así separar en categorías independientes tanto los aspectos de colaboración, comunicación y coordinación, como el tiempo y lugar en que dichos aspectos se desarrollan. Fig. 1. Clasificación de las cualidades de una sistema groupware interactivo. 3 Taxonomía para sistemas groupware interactivos Todas estas clasificaciones, o taxonomías, han sido utilizadas para clasificar las funciones o subsistemas que dan soporte al trabajo colaborativo, sin embargo no han sido utilizadas para clasificar la información expresada en los modelos que especifican dichos sistemas. Nos planteamos crear una taxonomía con este objetivo. Dicha taxonomía difiere del resto en el hecho de que proporciona un marco para la clasificación de los distintos aspectos o facetas a considerar durante el modelado de un sistema groupware interactivo, así como por favorecer la adecuada integración y mapeo entre la información expresada en los diferentes modelos. La siguiente sección describe la taxonomía que hemos diseñado. Nuestra propuesta parte de la hipótesis de que un sistema groupware interactivo puede ser clasificado y, por lo tanto, modelado mediante una o varias capas, conjuntos o familias de especificaciones, en cada una de las cuales se expresan una o varias cualidades del mismo. Dicha idea, expresada de forma gráfica en la Fig. 1(d) da lugar a la definición de nuestra taxonomía. Para sistemas con una capa, ésta necesariamente representaría todas las cualidades del mismo Fig. 1(b). Esta hipótesis sugiere que un sistema CSCW existente puede ser reemplazado por un conjunto de componentes 3 Esta distinción es necesaria porque algunos de los servicios necesarios en CSCW pueden presentarse como una funcionalidad, como un componente software incorporado o como un sistema o aplicativo software por si mismo. Un chat es un ejemplo.

4 52 W. J. Giraldo, A. I. Molina, M. Ortega, C. A. Collazos software que por separado soportan una o varias de estas cualidades y que sean integrables entre sí para completarlo. Por lo tanto, una capa por sí sola podría llegar a modelar un componente software completamente funcional. Nuestra propuesta no solamente está orientada al modelado e integración de componentes de este tipo, sino también, a definir un método mediante el cual se pueda tener diversas abstracciones de un sistema que modelen, por separado, diversas cualidades a potenciar en el mismo. Las capas de un sistema CSCW pueden compartir elementos de modelado, puesto que cada una es simplemente una realización 4 (delimitación, o abstracción) de una o varias cualidades. En la Fig. 1(c) se observa una capa que tiene como propósito integrar todos los modelos que están relacionados con la usabilidad del sistema. Otra hipótesis que se plantea es que la taxonomía podría servir de base común y punto de conexión entre distintos procesos de desarrollo y propuestas de modelado para resolver, en gran medida, el problema de integración existente entre ellas. 3.1 Integración entre capas Aunque nuestra propuesta de integración, basada en el uso de la taxonomía propuesta, puede aplicarse a un amplio número de notaciones, cada una de ellas adecuada para especificar distintos aspectos del sistema, nuestro interés inicialmente se centra en la integración de las notaciones CIAN y UML, tal y como se ha apuntado anteriormente. Fig. 2. Posibles escenarios de integración de las propuestas CIAN y UML. La integración o separación se lleva a cabo mediante una capa de integración, cuyo propósito es almacenar la información útil y relevante proveniente de ambas notaciones. Dicha capa clasifica la información de los elementos de modelado comunes en ambas notaciones y los organiza en diversas perspectivas y vistas. Este proceso de integración podría realizarse de distintas formas. Algunos de los posibles escenarios de integración se describen a continuación: (1) Se inicia el modelado con diagramas en CIAN con el objetivo de especificar la interfaz colaborativa. Este modelo especifica la colaboración, las tareas de los usuarios, los objetos, el paso de información, la coordinación de las actividades, la relación entre interfaces y tareas, etc. 4 La realización es un mecanismo utilizado en el RUP para delimitar o demarcar el conjunto de elementos de modelado que implementan una especificación. Este mecanismo se usa principalmente en los casos de uso. Una realización por tanto es una vista de todas las clases que implementan una funcionalidad. Una clase puede participar en varias realizaciones.

5 Una Propuesta Metodológica Basada en Taxonomías para Groupware 53 Posteriormente, se continúa el diseño en UML con el objetivo de especificar la funcionalidad. En la Fig. 2 (a) se ilustra este proceso. (2) Se inicia el diseño en UML con el objetivo de especificar la funcionalidad. Posteriormente, continúa el diseño en CIAN con el objetivo de especificar la interfaz colaborativa. En la Fig. 2 (b) se ilustra este proceso. (3) Se combinan los dos escenarios anteriores. En este caso son necesarias transformaciones adicionales dentro de la capa de integración para sincronizar los modelos que se elaboran en paralelo, Fig. 2 (c). 3.2 Definición de la capa de integración La capa de integración que proponemos tiene su base en el Framework de Zachman [8]. Dicho Framework propone una taxonomía sistemática que permite asociar conceptos que describen el mundo real con los que describen su respectivo sistema de información y su posterior implementación [9]. Esta taxonomía está definida en dos dimensiones organizadas en perspectivas y vistas. De cara a facilitar la explicación se consideran únicamente las perspectivas de modelo de negocio, modelo de sistema y modelo de tecnología y las vistas de datos, procesos, red y personas. La intersección de vistas y perspectivas da lugar a 12 celdas de modelado, (Fig. 3). Cada celda provee un contenedor para los modelos que abordan una determinada perspectiva y vista. Se provee una representación desde distintos puntos de vista, en diferentes niveles de granularidad, generalidad y abstracción. Una perspectiva es una representación arquitectónica en un nivel de abstracción específico y representa un conjunto de restricciones físicas o lógicas que puedan afectar el desarrollo de un sistema en ese nivel. Esta clasificación por perspectivas permite una independencia entre los distintos niveles de abstracción, sin embargo, es necesario contar con una arquitectura sólida que permita su posterior integración. MDA (Model Driven Architecture) [10] es una arquitectura que promueve el diseño guiado por modelos y, tal y como puede observarse en la Fig. 3, existe una relación entre las perspectivas y los niveles de MDA. Frankel et al [11] describen como se puede mapear el Framework de Zachman con MDA. Fig. 3. Estructura de la capa de integración El concepto de vista, o abstracción, es un mecanismo utilizado por los diseñadores para entender un aspecto de un sistema. Un punto clave en las arquitecturas de software

6 54 W. J. Giraldo, A. I. Molina, M. Ortega, C. A. Collazos (perspectivas) es el soporte para el manejo de distintos niveles de abstracción. La abstracción es la herramienta que permite a los desarrolladores de software manejar la complejidad de sus desarrollos. Es por ello que nos enfocamos, en primer lugar, en las abstracciones y, posteriormente, en las implementaciones que se derivan de dichas abstracciones [12]. Así, por ejemplo, la vista de datos provee modelos con información acerca del dominio del sistema a desarrollar. Por otro lado, la vista de procesos incluye modelos que representan los procesos y funcionalidades del sistema. Para capturar todos los requisitos de un sistema software es necesario contemplar múltiples vistas. Las cualidades son cada una de las características, atributos o aspectos que hacen que la especificación de un sistema se enriquezca, y por ende, permite diferenciar un atributos de calidad considerarse como cualidades. Para controlar la integridad, la unicidad, la consistencia y la recursividad de la información especificada, la taxonomía define una serie de reglas. En este sentido se han adoptado y refinado las siete reglas del Framework de Zachman [9]. Algunos ejemplos de estas reglas son: (R 2 ) El conjunto de las celdas en cada vista columna- se guía por un metamodelo único. (R 5 ) La composición o integración de todos los modelos de las celdas en una fila constituye un modelo completo desde esa perspectiva. (R 7 ) La lógica es recursiva. Fig. 4. Niveles del MOF y su relación con la taxonomía 3.3 Estructura de las notaciones en la capa de integración MDA provee la estructura conceptual mediante la cual se especifican las notaciones o lenguajes de dominio específico, DSL (Domain-Specific Language)) utilizados en cada una de las celdas de la capa de integración. Adicionalmente, permite implementar dichas notaciones por medio de herramientas software para aplicaciones específicas, dentro de un enfoque arquitectónico [13], Fig. 4 (a). Por tanto, cada uno de los modelos de las celdas está relacionado con su respectivo metamodelo (DSL). Todos los modelos en MDA están relacionados gracias a que se basan en un metamodelo más abstracto denominado MOF (Meta Object Facility) [10]. El uso de MOF facilita la definición de las transformaciones necesarias en la integración de modelos. Las transformaciones que se llevan a cabo son del tipo Modelo a Modelo

7 Una Propuesta Metodológica Basada en Taxonomías para Groupware 55 (M2M) o Modelo a Texto (M2T) (Fig. 4 (c)), las cuales pueden realizarse entre celdas de dos diferentes capas, en una misma capa, en sentido horizontal -misma perspectivao vertical -misma vista-. La integración entre capas que utilicen las notaciones UML y CIAN es posible gracias a que estos son coherentes con los niveles de MDA, ver figura 4(b). Fig.5. Modelos de la Celdas de la capa de integración. La capa de integración posee un conjunto de celdas con información que debe estar relacionada tanto a nivel de vistas como de perspectivas. Por lo tanto, se especifica un metamodelo base (Fig. 5 (c)) para conservar la consistencia de los modelos en celdas de una misma vista regla2- y para la integración o composición de los modelos en las celdas de una misma fila regla 5-, desempeñando una función de integración a nivel de perspectiva. Puede especificarse un metamodelo base distinto para cada capa de integración, eso depende de la naturaleza de la familia de lenguajes (DSL) que esté especificando dicho metamodelo base. Por ejemplo, al integrar UML y CIAN se podría crear una sola capa de integración para almacenar la información común útil en la integración. Sin embargo, se podría tener una capa de integración por cada notación, proporcionando un beneficio adicional porque se puede exponer la información que una notación brinda a las demás y no solo a una en especial. Múltiples capas de integración pueden coexistir en un sistema. Una capa de integración puede estar asociada directamente a una capa -ver Fig. 1-, a una notación o a una cualidad. Esto supone una nueva dimensión en la taxonomía. Esta dimensión se establece para agrupar el conjunto de capas de integración que conforman un sistema groupware interactivo. Cada nivel en esta dimensión representa un conjunto o familia de lenguajes de dominio específico que intenta modelar una o varias cualidades del sistema. Fig. 5(b). La integración entre capas se realiza mediante transformaciones definidas para cada notación. MDA propone la transformación de modelos para reducir la complejidad del diseño de software [13, 14]. En la Fig. 6 (a) se ilustra un ejemplo de transformación en el cual se extrae información de un diagrama en CIAN y se rellena la capa de integración. La estructura de las notaciones se representa mediante unas cajas que

8 56 W. J. Giraldo, A. I. Molina, M. Ortega, C. A. Collazos contienen metamodelos a nivel M3 y M2. La celda con el diagrama en CIAN sociograma- está en el nivel M1 (Modelo), el cual está definido por la notación CIAN, la cual a su vez, está definida como un UML-Profile en el nivel M2 (metamodelo). La transformación tiene como metamodelo de entrada a CIAN y como metamodelo de salida el DSL definido para dichas celdas. En la Fig. 6 (b) se ilustra el proceso contrario que consiste en transformar modelos desde la capa de integración para generar diagramas UML. Hay que aclarar que no siempre se podrán obtener diagramas completos en UML, generalmente se genera información parcial de elementos de modelado, la cual sirve como punto de partida para el posterior modelado en UML. Fig. 6. integración entre CIAM y UML 3.4 Ejemplo de Integración entre capas. La Fig. 7 ilustra la integración de modelos de CIAN y UML usando CIAT (Collaborative Interactive Applications Tool). CIAT es una herramienta basada en Eclipse que ayuda a los desarrolladores a especificar modelos en CIAN. En particular se muestra el proceso de integración del diagrama denominado Sociograma de CIAN y su correspondiente representación en notación UML. La información relativa a los roles y relaciones entre los miembros de la organización mostrados en el Sociograma se procesa por medio de las transformaciones para generar información parcial del modelo de negocio y del modelo de sistema. Esta información se clasifica en estas dos perspectivas para la vista personas principalmente. Cada actor en CIAN puede representar tanto un Business Actor como un System Actor en UML. Las relaciones de dependencia y asociación no tienen una representación directa en UML, sin embargo, su información debe ser almacenada para generar otros artefactos. La perspectiva del modelo de negocio se presenta en la Fig. 7 (b), en la cual se ha rellenado información para las vistas de datos, procesos, red y personas. Esta información es generada a partir de varios diagramas en CIAN. En primer lugar, la columna de personas (people) de la capa de integración se ha rellenado con información del sociograma, ver Fig. 7 (a), posteriormente, a partir de la información de la capa de integración en la columna personas (people), para este caso, se ha generado el diagrama de actores de negocio en UML, ver Fig. 7 (c). Los nombres de los elementos de modelado que se almacenan en esta capa son numerados tanto de forma automática como manual.

9 4 Conclusiones Una Propuesta Metodológica Basada en Taxonomías para Groupware 57 El desarrollo de sistemas de soporte al trabajo en grupo resulta una tarea compleja, entre otros motivos, dada la naturaleza de los grupos involucrados en dicho proceso, cuyos integrantes suelen provenir de distintas áreas de conocimiento. Las necesidades de los distintos miembros del equipo de desarrollo, así como los artefactos manipulados, es decir, la perspectiva adoptada durante el desarrollo, varía para cada uno de ellos. De igual forma, a la hora de desarrollar el sistema software existen distintos aspectos o cualidades a potenciar (usabilidad, soporte a la colaboración, funcionalidad, etc). Por otro lado, la posibilidad de trabajar con distintas abstracciones (vistas) facilita el manejo de la complejidad en el desarrollo de los sistemas. Contemplar todas estas posibilidades ha dado lugar a una propuesta basada en la definición de una taxonomía tridimensional (perspectivas-vistas-cualidades) que facilita la integración de las notaciones empleadas por distintos miembros del equipo de desarrollo, que soportan el modelado de distintos aspectos y que trabajan a distintos niveles de abstracción, así como la definición de transformaciones entre ellas. Desde otro punto de vista, dicha taxonomía puede ser igualmente empleada como una adecuada herramienta de clasificación de notaciones. Sería, en este caso, posible definir métricas, indicadores o índices de cobertura para cada una de las cualidades, perspectivas y/o niveles de abstracción soportados por un artefacto de especificación concreto. En particular, en este artículo se ha mostrado la aplicación de dicho marco de integración a dos notaciones como son UML, que da un soporte adecuado al modelado de la funcionalidad del sistema y CIAN, que se centra en el modelado de la colaboración y la interacción con el usuario. Extrapolando los resultados de integración de ambas propuestas a otras notaciones existentes en la bibliografía se podría concluir que la taxonomía propuesta hace posible la conexión entre propuestas provenientes del campo de la Ingeniería del Software y de la Interacción Persona-Ordenador. Se ha desarrollado una herramienta software denominada CIAT, que implementa las ideas aquí presentadas. Dicha herramienta no solo permite la edición de modelos en notación CIAN, sino que realiza la integración y transformación de los modelos al estándar UML, empleando como artefacto intermediario la taxonomía propuesta.

10 58 W. J. Giraldo, A. I. Molina, M. Ortega, C. A. Collazos Fig. 7. Ejemplo de integración entre CIAN y UML usando la herramienta CIAT. Agradecimientos Este trabajo ha sido financiado por la Universidad Castilla-La Mancha y la Junta de Comunidades de Castilla-La Mancha en los proyectos mguide (PBC ) y M-CUIDE (TC ) y por la Universidad del Quindío (Colombia). Referencias 1. Molina, A.I., M.A. Redondo, and M. Ortega. A conceptual and methodological framework for modeling interactive groupware applications. In 12th International Workshop on Groupware (CRIWG 2006) Valladolid. Spain: Springer-Verlag (LNCS). 2. Gutwin, C. and S. Greenberg. Design for Individuals, Design for Groups: Tradeoffs between power and workspace awareness. in Seattle: ACM Press. 3. Molina, A.I., et al. A proposal of integration of the GUI development of groupware applications into the Software Development Process. in 13th International Workshop on Groupware (CRIWG'2007) Bariloche (Argentina): Lecture Notes in Computer Science. Springer-Verlag. 4. Molina, A.I., M.A. Redondo, and M. Ortega, CIAM: A methodology for the development of groupware user interfaces. Journal of Universal Computer Science(JUCS), IBM_Rational, Too Navigator (Rational Unified Process) Johansen, R., Groupware: Computer support for business teams. 1988: New York: The Free Press. 7. Penichet, V.M.R., et al., A Classification Method for CSCW Systems. Electronic Notes in Theoretical Computer Science, 2007.

11 Una Propuesta Metodológica Basada en Taxonomías para Groupware Zachman, J.A., A Framework For Information Systems Architecture. IBM Ssystems Journal, (3). 9. Sowa, J.F. and J.A. Zachman, Extending and formalizing the framework for information systems architecture. IBM Syst. J, 1992: p Miller, J. and J. Mukerji. MDA Guide Version [cited ; Available from: Frankel, D.S., et al. (2003) The Zachman Framework and the OMG's Model Driven Architecture. MDA Journal 12. Kaisler, S.H., Software Paradigms. 2005: John Wiley & Sons, Inc. 13. Frankel, D.S. (2004) An MDA Manifesto. MDA Journal 14. Jouault, F. and I. Kurtev. On the architectural alignment of ATL and QVT. in Proceedings of the 2006 ACM symposium on Applied computing Dijon, France: ACM.