Christian Guillén-Drija, Francisca Losavio

RESUMEN

Este trabajo presenta una primera versión de MUDA (Método Unificado de Diseño Arquitectónico) en el que se integran aspectos adoptados de otros métodos estudiados. MUDA se caracteriza por:

1. Sustentarse en un cuerpo de conceptos universalmente aceptados en el área de la arquitectura de software, a saber: componentes, conectores, interfaces, estilos arquitectónicos, restricciones arquitectónicas, comportamientos, componentes estructurados, entre otros.

2. Tratar explícitamente los requisitos no funcionales: aunque los requisitos funcionales son el punto de partida para la generación de una arquitectura inicial, son los requisitos no funcionales los que van a dar forma final a dicha arquitectura a través de la adopción de mecanismos arquitectónicos que aseguren que el sistema ofrezca sus funcionalidades dentro de un entorno de calidad, en un dominio específico.

3. Proporcionar mecanismos de derivación arquitectónica: a partir de un conjunto de requisitos iniciales, el arquitecto de software debe generar elementos de valor arquitectónico para la estructuración de una arquitectura preliminar o inicial. Este proceso se le conoce como derivación arquitectónica (Lamsweerde, 2003).

]]> 4. Aplicar UML como mecanismo de descripción arquitectónica: puesto que este lenguaje asume muchos de los conceptos arquitectónicos a los cuales los ADLs (Garlan, Monroe y Wile, 1997;Guillén, 2002) pretenden responder y el mismo es aplicado por muchas organizaciones. Sin embargo, este lenguaje no ha sido adoptado por muchos de los métodos de diseño arquitectónicos estudiados.

5. Proporcionar actividades de transformación arquitectónica: tales transformaciones son logradas aplicando patrones de diseño arquitectónico o algún estilo arquitectónico que favorezca el modelo de calidad asumido. MUDA contempla la posibilidad de realizar sucesivas transformaciones hasta el logro de las características de calidad necesarias.

6. Utilizar escenarios, casos de uso y modelos de calidad como mecanismos para el levantamiento de requisitos de calidad. Los casos de uso junto con los escenarios, son una excelente manera de registrar tanto requisitos funcionales como requisitos no funcionales, y al mismo tiempo, facilitan la determinación de las relaciones existentes entre los requisitos funcionales y los no funcionales.

El hecho de que MUDA integre las características antes mencionadas, facilita la identificación y refinamiento de la información arquitectónicamente relevante contenida en el conjunto de requisitos iniciales.

Como ya se ha mencionado, la generación de una arquitectura que satisfaga los requisitos iniciales, es aún una tarea ardua, principalmente basada en la intuición y experticia del arquitecto de software (Grünbacher, Egyed y Medvidovic, 2003). Tal dificultad es aún más notoria en el caso de los requisitos no funcionales, por lo que es un tema de investigación abierto, aún no resuelto completamente (Jani, Vanderveken y Perry, 2004). A este respecto, se han realizado esfuerzos dirigidos a la concepción de frameworks o marcos de referencia para la generación de una arquitectura inicial basada en requisitos (Chung, Cooper y Yi, 2003) (Lamsweerde, 2003) (Grünbacher, Egyed y Medvidovic, 2003), (Brito y Moreira, 2004).

Especial mención merece la propuesta realizada por Grünbacher y otros (2003), quienes proponen el enfoque CBSP (Component-Bus-System-Property), como un método sistemático dirigido a facilitar el refinamiento de un conjunto de requisitos y expresarlos a través de dimensiones arquitecturales. La idea que subyace es que cualquier requisito de software puede implícitamente o explícitamente contener información relevante para la arquitectura del sistema. Las dimensiones arquitecturales propuestas son 6, las cuales generan artefactos específicos que envuelven elementos arquitectónicos básicos; estos son: (1) artefactos que describen o involucran a un componente en una arquitectura, (2) artefactos que describen o involucran un BUS (conector), (3) artefactos que describen características generales del sistema o características pertinentes a un amplio subconjunto de componentes y conectores del sistema, (4) artefactos que describen o involucran a propiedades de componentes de procesamiento o componentes de datos, (5) artefactos que describen o involucran a propiedades de un BUS (conector), y (6) artefactos que describen o involucran propiedades de un sistema o subsistema. Estas dimensiones son aplicadas al cuerpo de requisitos, dando como resultado un conjunto de descripciones de relevancia arquitectónica. En el proceso, se generan dos tipos de entregables: (1) un conjunto artefactos (componentes) que describen decisiones arquitectónicas y (2) enlaces, que describen las dependencias entre esos artefactos. Los primeros proporcionan piezas que potencialmente pueden formar parte de la arquitectura, mientras que los segundos ayudan a clarificar las dependencias de control y datos existentes entre tales piezas. En la fase final del método, el conjunto de artefactos y enlaces son reordenados según un determinado estilo arquitectónico que responda a requisitos no funcionales.

El enfoque anterior busca generar artefactos que posiblemente pueden componer una arquitectura, sin embargo el diseño arquitectónico consiste también en determinar las estrategias de organización de los componentes que conformarán el sistema a construir. Dichas estrategias están tipificadas en estilos y patrones arquitectónicos (Krutchen, 2000), y es tarea del arquitecto de software identificar los que mejor responden a los requisitos iniciales. De esta forma obtiene una arquitectura base, sobre la cual necesariamente se deben realizar sucesivas transformaciones con el fin de calibrar dicha arquitectura con respecto a los requisitos no funcionales y así obtener una versión definitiva. Tales transformaciones deben ser guiadas por una evaluación de la arquitectura. Esta se puede realizar a través de la asignación de prioridades tanto a los escenarios como a las características de calidad relacionadas con el estilo o patrón escogido. La justificación del estilo seleccionado es el enfoque propuesto en el método ATAM (Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord y Stafford, 2002). En este, se determinan los conflictos que pueden surgir entre los mecanismos arquitectónicos escogidos para responder a las características de calidad iniciales, pero en ningún momento se realizan transformaciones sobre la arquitectura evaluada. Otros trabajos extienden este método introduciendo modelos de calidad estándar y métricas arquitectónicas para la justificación de la selección del estilo, (Losavio, Chirinos y Pérez, 2001) (Losavio, Chirinos, Lévy y Ramdane-Cherif, 2002) lo que permite escoger una arquitectura inicial justificada sobre esas bases.

En la siguiente sección se describe el método propuesto en este trabajo. Dicho método adopta aspectos de los enfoques antes descritos y los integra con UML. Basado en aspectos de calidad considera la derivación de requisitos en elementos arquitecturales, la generación de una arquitectura base y su posterior transformación hasta obtener una arquitectura definitiva.

a. Generación del Modelo de Casos de Uso: lo que permite la apropiada descripción de las funcionalidades a través de la notación que para tal fin propone UML (Unified Modeling Language) (OMT, 2005). Este modelo de casos de uso estará compuesto por el diagrama de casos de uso y una especificación detallada de los mismos. A través de las relaciones extend, include o use (OMT, 2005) se debe lograr la división de casos de uso generales en casos de uso cada vez más específicos, puesto que nuestro objetivo es la determinación de los casos de uso que arquitectónicamente son significativos desde el punto de vista funcional. Esta actividad generaráuna jerarquía de casos de uso, desde los más generales hasta los más específicos a manera de árbol. Esta actividad permite a los especialistas involucrados en el desarrollo del sistema, analizar los requisitos iniciales y verificar la pertinencia de estos o la omisión de funcionalidades importantes. Por otra parte, este proceso es de naturaleza iterativa e incremental, por lo que se puede partir de un diagrama sencillo y muy general, intentando expresar de manera coherente la lista inicial de requisitos, enriqueciendo en cada iteración el modelo de casos de uso hasta llegar a la especificación detallada de los mismos. Cuando lo último ocurre, existe la posibilidad de que algunos requisitos no funcionales aparezcan.

a. Generación del Modelo de Componentes: esto se logra utilizando dos fuentes: el modelo de casos de uso y el modelo de calidad. En primer lugar, se toman los casos de uso ubicados como hojas del diagrama de casos de uso y se les asigna un componente, expresado gráficamente a través de la

notación de UML. Inicialmente estos componentes tienen un nombre y nada más; pero tal descripción puede ser refinada a través de iteraciones. Por otra parte, se hace algo similar a partir del modelo de calidad expresado en el árbol de calidad; a cada escenario hoja, clasificado como un artefacto C, se le asigna un componente y a los escenarios de tipo CP, se les intenta ubicar como propiedades de los componentes.

4. Estudio de un caso: sistema de software educativo en el dominio de la enseñanza de la física

El software educativo que se analizó como caso de estudio, presenta el concepto de energía en diferentes contextos representados a través de nueve opciones didácticas. Cada opción consiste en un conjunto de planteamientos relacionados con analogías que permiten explorar el concepto de energía. La disponibilidad de una variedad de opciones brinda al usuario (estudiante) la oportunidad de planificar su sesión de estudio, explorando y seleccionando la estrategia que más se adapte a sus necesidades de aprendizaje, considerándose la individualización, la retroalimentación y el manejo de los errores como elementos básicos a tomar en cuenta en el proceso enseñanza-aprendizaje (Esteves, 2001). Las características anteriores ubican a este software dentro del marco de la teoría cognitiva, específicamente la presentada por: (a) Bransford (2000) quien en su teoría de la instrucción contextualizada (anchored instruction) basa las secuencias de aprendizaje en la presentación de macro-contextos que le permitan a los estudiantes la posibilidad de explorar hasta lograr el aprendizaje; y (b) Spiro, Feltovich y Coulson (2000), quienes en su teoría de la flexibilidad cognitiva sostienen que en el proceso enseñanza-aprendizaje, se debe considerar la representación múltiple del contenido y la dependencia contextual de los conceptos.

Por otra parte, este software implementa una adaptación del modelo propuesto por McCalla y Greer (1987) quienes desarrollaron un sistema CAI (computer assisted instruction: instrucción asistida por el computador) utilizando tecnología y técnicas de inteligencia artificial. Este modelo identifica los siguientes componentes (ver Figura 1):

Subsistema de comunicación: es la interfaz con todas sus características: colores, movimiento, rapidez de presentación; en general, determina la "calidad de la interacción" entre el usuario y el objeto de conocimiento.

1. Debe permitir la personalización de la sesión de trabajo.

2. Pueda ser utilizado tanto para fines de evaluación como para actividades de reforzamiento y exploración.

3. Le permita al usuario culminar la sesión de trabajo de manera sencilla.

4. Le permita al usuario conocer los resultados de las sesiones desarrolladas.

5. En el caso de ser utilizado dentro de actividades de evaluación, ofrezca un resumen de aciertos y desaciertos.

6. Registre las rutas seguidas por los usuarios durante la escogencia y revisión de las fichas didácticas. Esta información puede ser utilizada por el docente o el investigador para fines diversos.

]]> 7. Realice el reconocimiento de planes (sistema experto).

En primer lugar, se generó un conjunto de componentes candidatos a los cuales se les asignan responsabilidades según el modelo de casos de uso de manera que no exista al final de este paso casos de uso que no tenga un posible componente responsable. En la Figura 6 se puede observar una primera versión del modelo de componentes derivado exclusivamente del modelo de casos de uso.

Un segundo conjunto de componentes fue generado a partir del árbol de utilidad. Para lograr esto, primero se realizó un inventario de las posibles estrategias de solución arquitectónica que pueden ser aplicadas con el fin de responder a los escenarios planteados. Tales estrategias plantean

Por otra parte, es necesario identificar las dependencias entre los componentes con el fin de derivar posibles conectores y de esta manera obtener un modelo arquitectónico más detallado. Todo lo anteriormente mencionado puede observarse en la Figura 8, en la que se puede observar el resultado de la fusión de los dos modelos de componentes previamente obtenidos.

En el modelo resultante de la fusión de los dos tipos de componentes (funcionales y no funcionales) se pueden observar las relaciones de dependencia que se identificaron entre los componentes, las cuales pueden ser consideradas como indicadores de posibles conectores. Al mismo tiempo, una observación más detallada de la proto-arquitectura, permite identificar el nivel de acoplamiento entre algunos componentes, lo que se puede considerar como un signo inequívoco de la criticidad de estos.

Como puede observarse, el resultado obtenido se resume en una estructura arquitectónica en la que se adopta un conjunto de estrategias consideradas apropiadas frente a las exigencias planteadas por el conjunto de requisitos funcionales y no funcionales identificados. Por ejemplo, para el caso de la característica de facilidad de mantenimiento, se aplicaron varias estrategias arquitectónicas como la de separación y la indirección de datos. La primera busca desacoplar la data con respecto a las funciones del sistema. Tal separación facilita la modificación de los componentes encargados de ejecutar las funciones sin que ello signifique necesariamente que los componentes de datos deban ser ajustados (Bachmann, Bass y Klein, 2002). En el caso de la arquitectura propuesta, se aplica en primer lugar el estilo Cliente-Servidor, el cual a su vez se implementa a través del estilo de capas (Clements y otros, 2002) (Figura 10).

La estrategia de indirección de datos consiste básicamente en desacoplar consumidores y productores de datos. De esta forma se facilita la modificación de los distintos componentes, al mismo tiempo que se minimizan los efectos colaterales que tales cambios pueden generar sobre el resto del sistema (Bachmann, Bass y Klein, 2002). En la arquitectura propuesta, la indirección de datos le logra a través de la aplicación de los patrones Publicador-Subscriptor, Mediador y Modelo-Vista-Control. El patrón Publicador-Subscriptor permite la sincronización del estado de los componentes productores y consumidores, donde los productores son denominados Publicadores y los consumidores son denominados Subscriptores (Clements y otros, 2002). Cuando un Publicador "publica" nueva información, todos los Subscriptores son notificados y automáticamente reciben la data. Lo anterior evidencia que el repositorio de información no es pasivo, sino más bien, tiene un rol activo, pues debe decidir a cuales Subscriptores debe enviar la información, ya que cada uno de ellos tiene interés sobre un tipo determinado de información. Es recomendable utilizar este patrón para responder a escenarios en los que pueden cambiar las estructuras de los datos generados por los Productores. También es recomendable cuando varios subscriptores comparten interés por un mismo tipo de datos, permitiendo la comunicación de estos de manera selectiva. Por otra parte, cambios eventuales realizados en componentes Consumidores de datos, no deberían reflejarse sobre las estructuras de datos o sobre los Productores de datos. En el caso de la arquitectura que se propone en este trabajo, el patrón Publicador-Subscriptor se aplica a través de los componentes Admnistrador de subscripciones del sistema análisis y Administrador de subscripciones del sistema tutor. En ambos casos, los componentes son básicamente repositorios de datos, pero con la responsabilidad de dirigir la información apropiada a los demás componentes que interactúan. Es importante explicar que los distintos componentes dentro de los subsistemas pueden asumir en un momento dado el rol de productor de información y en otro comportarse como consumidores de datos.

El patrón Mediador encapsula el comportamiento de componentes que interactúan, promoviendo el bajo acoplamiento en un contexto en el cual es necesaria la comunicación (Gamma, Helm, Johnson y Vlissides, 1998). Se diferencia del patrón anterior en que el Mediador no es un repositorio de información, sino más bien se comporta como un conector que en muchos casos debe realizar modificaciones sobre la información antes de transmitirla a otro componente. En la arquitectura propuesta, los componentes Mediador de Personalización, Mediador de datos y Conector_repositorio asumen el rol de Mediadores. En el caso de los dos últimos, estos conforman la capa de acceso, encapsulando los mecanismos de conexión necesarios para comunicar la capa lógica con la capa de persistencia. De esta manera, se favorece la portabilidad del sistema debido a que el mismo puede interactuar con varios sistemas de bases de datos con tan sólo realizar cambios en la capa de acceso.

El patrón Modelo-Vista-Control es recomendable cuando la misma información es presentada de distintas maneras, por ejemplo a través de un gráfico de barras o a través de un gráfico de torta. Los elementos que conforman este patrón son:

a. Modelo: componente que encapsula los datos básicos y la funcionalidad. En la arquitectura propuesta, el componente Administrador_Consultas asume el rol del Modelo (Figura 11).

b. Vista: componente que despliega la información al usuario. La vista obtiene la información del modelo, existiendo múltiples vistas por modelo. A cada vista se le asocia un componente control. En el caso de la arquitectura propuesta, el componente Interfaz Gráfica del Administrador de Consultas asume el rol del componente vista.

c. Control: cuya función es recibir las entradas realizadas por el usuario y posiblemente los eventos relativos al control del ratón o entradas del teclado. El componente Interfaz Gráfica del Administrador de Consultas tiene asociado el componente Control _Interfaz_Administrador_Consultas, encargado de controlar la interacción entre este y los componentes Vistas Gráficas. Al mismo tiempo, el componente Control_Interfaz_Administrador_Consultas controla la comunicación con el componente Administrador_Consultas.

El arquitecto de software tiene como tarea esencial, la generación de la arquitectura más idónea para un sistema de software. Tal objetivo es alcanzado tras un esfuerzo sostenido por comprender tanto el espacio del problema como el espacio de la solución. En el espacio del problema, el arquitecto de software debe distinguir e identificar aquellos requisitos que realmente tengan repercusión en la arquitectura del sistema, lo cual implica en muchos casos un ejercicio de reinterpretación de los mismos, o al menos de adecuación. Con esto último, se quiere significar que en muchos casos, los requisitos deben ser expresados de manera tal que faciliten la identificación de los elementos que conformarán la arquitectura. Por otra parte, en el espacio de la solución, el arquitecto debe aplicar aquellos mecanismos que mejor respondan a los requisitos planteados, los cuales en muchos casos generan efectos entre sí, difíciles de resolver. En este contexto, MUDA es propuesto como un método en el que se intentan unificar elementos extraídos de otros métodos centrados en la visión arquitectónica del software con el fin de responder a la dificultad inherente al proceso de generación de una arquitectura a partir de un conjunto de requisitos. Su fortaleza, creemos, está en que este permite al arquitecto de software ir construyendo de manera progresiva una arquitectura a través de un mecanismo de derivación que facilita la generación de elementos arquitectónicos a partir de requisitos tanto funcionales como no funcionales. Por otra parte, se ha puesto especial énfasis en utilizar conceptos arquitectónicos de aceptación generalizada, proponiéndose además utilizar UML como medio de especificación de los constituyentes arquitectónicos.

Consideramos que MUDA responde a los siguientes aspectos críticos en el diseño de una arquitectura: la adecuación de requisitos, la derivación de elementos arquitectónicos potenciales y la transformación arquitectónica. La adecuación arquitectónica se lleva acabo a través de la identificación de los casos de uso y la construcción del árbol de calidad, junto con los escenarios correspondientes. La derivación arquitectónica se realiza a través de la aplicación de la taxonomía CBSP y la posterior generación de los modelos de componentes y conectores, considerando tanto los requisitos funcionales como los no funcionales. Por último, la transformación arquitectónica se realiza a través de la aplicación de mecanismos tales como los estilos y patrones arquitectónicos.

1. Bass, L., Clements, P., Kazman, R. (2003). Software Architecture in Practice. Massachussets, Addison-Wesley. Segunda edición.        [ Links ]

2. Brito, I. y Moreira, A. (2004). Integrating the NFR framework in a RE model. (Documento en línea). Disponible: http://trese.cs.utwente.nl/workshops/early-aspects-2004/Papers/BritoMoreira.pdf (Consulta: 2008, Abril 27).         [ Links ]

3. Bosch, J. (2000). Design & Use of Software Architecture. Addison-Wesley.        [ Links ]

4. Bransford, J. (2000). Anchored Instruction. (Documento en línea). Disponible: http://www.gwu.edu (Consulta: 2008, Marzo 22).        [ Links ]

5. Chung, L., Cooper, K., y Yi, A. (2002). Developing Adaptable Software Architectures Using Design Patterns: a NFR Approach. Departament of Computer Science, University of Texas at Dallas.         [ Links ]

6. Chung, L., Cooper, K. y Yi, A. (2003). Developing adaptable software architecture using design pattern: an NFR approach. Computer Standards & Interfaces, v.25 n.3, p.253.        [ Links ]

7. Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R. y Stafford, J. (2002). Documenting Software Architectures: Views and Beyond. Addison Wesley.        [ Links ]

8. Esteves, Y. (2001). Diseño instruccional en energía para primer año de ciencias de Educación Media Diversificada y Profesional. Trabajo de grado de Maestría. Caracas, Universidad Pedagógica Experimental Libertador, Instituto Pedagógico de Caracas.        [ Links ]

9. Esteves, Y., Guillén-Drija, C. (2007). Arquitectura para un Software Educativo en el Dominio de la Enseñanza de la Física. Caso de Estudio: Software Educativo en Petróleo y Energía. Trabajo de ascenso no publicado. Universidad Pedagógica Experimental Libertador, Instituto Pedagógico de Miranda J.M. Siso Martínez, Caracas.         [ Links ]

10. Esteves, Y., Rodríguez, J., y Guillén, C. (2003). Línea de Investigación en Enseñanza de la Física. Ponencia presentada en la Jornada anual de Investigación Educativa. Maracay: UPEL.        [ Links ]

11. Gamma, E., Helm, R., Johnson, R. y Vlissides, J. (1998) [DC]. Design Patterns. Addison Wesley.        [ Links ]

12. Garlan, D., Monroe, R., Wile, D. (1997). Acme: An Architectural Description Interchange language. Proceedings of CASCON’97.         [ Links ]

13. Grünbacher, P., Egyed, A., Medvidovic, N. (2003). Reconciling Software Requirements and Architectures: the CBSP Approach. Journal of Software and Systems Modeling (SOSYM).        [ Links ]

14. Guillén, C. (2002). Especificación de Patrones Arquitectónicos para Sistemas Distribuidos. Trabajo de Grado de Maestría no publicado. Universidad Central de Venezuela, Caracas.        [ Links ]

15. Jani, D., Vanderveken, D. y Perry, D. (2004). Deriving Architecture Specifications from KAOS Specifications: a Reseach Case Study. Empirical Software Engineering Lab. Austin, University of Texas.         [ Links ]

16. Kazman, R., Klein, M., Barbacci, T., Longstaff, H., Lipson, H. y Carriere, J. (1998). The Architecture Tradeoff Analyisis Method. IEEE, ICECCS.        [ Links ]

17. Klein, M. y Kazman, R. (1999). Attribute-Based Architectural Styles. Carnigie Mellon University. Software Engineering Institute. CMU/SEI-99-TR-022. (Documento en línea]. Disponible: http://www.sei.cmu.edu/publications/documents/99.reports/99tr022/99tr022abstract.html (Consulta: 2008, Abril 12]        [ Links ]

18. Krutchen, P. (2000). The Rational Unified Process. An Introduction. Second Edition. Addison-Wesley. Massachusetts, Readings.         [ Links ]

19. Lamsweerde, A. (2003). From System Goals to Software Architecture. Bélgica, Université Catholique de Louvain.        [ Links ]

20. Losavio, F., Chirinos, L., Lévy, N., Ramdane-Cherif, A. (2002). Quality Characteristics For Software Architectur INCO SQUADProject EP 962019 y CDCH-ARCAS Project 03.13.4584.00.        [ Links ]

21. Losavio, F., Chirinos, L., Pérez, M. (2001). Feature Analysis for quality-based architectural design methods.        [ Links ]

22. McCalla, G. y Greer, J. (1987). The practical use ofartificial intelligence in automated tutoring: current status and impediments to progress. Laboratory for advanced research in intelligent educational system. Canadá: Department of computational science. University of Saskatchewan.        [ Links ]

23. OMT (Object Management Group). (2005). Unified Modeling Language: Superstructure. Version 2.0.formal/05-07-04.        [ Links ]

24. Shaw, M., Garlan, D. (1996). Software Architecture: Perspectives on an Emerging Discipline. Printice – Hall.         [ Links ]

25. Spiro, R., Feltovitch, P. y Coulson, R. (2000). Cognitive flexibility theory. (Documento en línea). Disponible: http://www.gwu.edu (Consulta: 2007, Enero 22).        [ Links ] ]]> 1 2003 Segunda 2 2004 3 2000 4 2000 5 2002 6 2003 25 3 3 253 7 2002 8 2001 9 2007 10 2003 Maracay 11 1998 12 1997 13 2003 14 2002 15 2004 16 1998 17 1999 18 2000 Second 19 2003 20 2002 21 2001 22 1987 23 OMT (Object Management Group) 2005 24 1996 25 2000