Servicios Personalizados
Revista
Articulo
Indicadores
-
Citado por SciELO
-
Accesos
Links relacionados
-
Similares en SciELO
Compartir
SAPIENS
versión impresa ISSN 1317-5815
SAPIENS vol.10 no.2 Caracas dic. 2009
MUDA: método unificado de diseño arquitectónico*
Christian Guillén-Drija, Francisca Losavio
UPEL-Instituto Pedagógico de Miranda José Manuel Siso Martínez. Caracas, Venezuela. cguillen@ipmjmsm.upel.edu.ve
Centro ISYS. Escuela de Computación, Facultad de Ciencias-UCV Caracas, Venezuela. flosav@cantv.net
* Este trabajo fue parcialmente financiado por el Consejo de Desarrollo Científico y Humanístico de la Universidad Central de Venezuela, proyecto MODABAC No. 03-005821-2008.
RESUMEN
El consenso que existe sobre la importancia del diseño arquitectónico en la construcción de sistemas de software que respondan adecuadamente a los requisitos iniciales, evidencia la necesidad de disponer de métodos que guíen la actividad del arquitecto de software durante la etapa inicial del proceso de desarrollo. Aunque existen diversas propuestas de métodos arquitectónicos, resulta necesario seguir profundizando la investigación en esta área. En tal sentido, proponemos a MUDA (Método Unificado de Diseño Arquitectónico), un método de diseño arquitectónico de carácter integrador como un intento orientado hacia el aprovechamiento de las mejores prácticas en el contexto de la visión arquitectónica del software. MUDA es aplicado a un caso de estudio en el dominio de los STI (Sistemas Tutoriales Inteligentes), evidenciándose la construcción progresiva de la arquitectura del sistema a través de un mecanismo de derivación de elementos arquitectónicos a partir de requisitos funcionales y no funcionales.
Palabras Clave: Arquitectura de Software, métodos de diseño arquitectónico, calidad de software.
MUDA: unified architectural design method
ABSTRACT
The general consensus about the importance ofthe architectural design in constructing software systems that suitably meet initial requirements proves the need for methods to guide software architects during the initial phase ofthe development process. There are several proposals ofarchitectural methods, though it is essential to keep researching on the topic. We introduce MUDA (Método Unificado de Diseño Arquitectónico) which is an integrated method designed with the aim of using the optimum practices within the scope ofthe architectural perspective. The application ofMUDA to a case ofstudy in the area ofthe Tutorial Intelligent Systems (TISs) has shown the gradual construction ofthe system architecture through the derivation ofarchitectural elements defined from functional and nonfunctional requirements.
Key words: Software Architecture, architectural design methods, software quality.
MUDA: Méthode unifiée de dessin architectonique
RESUME
Le consensus existant au sujet de limportance du dessin architectonique, dans la construction de systèmes de logiciel qui remplissent les requêtes initiales, met en évidence le besoin de créer des méthodes pour guider lactivité de larchitecte de logiciel pendant la période initiale du processus de développement. Bien quil y ait de différentes propositions de méthodes architectoniques, on doit continuer la recherche dans ce champ. Avec ce travail, lon propose MUDA (Méthode Unifiée de Dessin Architectonique) ; cest une méthode intégrale de dessin architectonique. Grâce à MUDA on pourrait profiter des meilleures pratiques dans le contexte de la vision architectonique du logiciel. La méthode proposée a été appliquée à un cas détude dans le domaine des STI (Systèmes Tutélaires Intelligents), et lon a pu constater la construction progressive de larchitecture du système grâce à un mécanisme de dérivation déléments architectoniques à partir de requêtes fonctionnelles et non-fonctionnelles.
Mots-clés: architecture de logiciel, méthodes de dessin architectonique, qualité de logiciel.
Muda: método unificado desenho arquitetônico
RESUMO
O consenso que existe sobre a importância do projeto arquitetônico para a construção de sistemas de software para responder adequadamente às exigências iniciais, destaca a necessidade de métodos para guiar a atividade do arquiteto de software durante a fase inicial de desenvolvimento. Apesar de existirem várias propostas de métodos de arquitectura, é necessário aprofundar a investigação nesta área. Neste sentido, propomos a MUDA (Método Unificado Desenho Arquitetônico), um método de inclusão de projeto arquitetônico como uma tentativa que visa tornar a utilização das melhores práticas no contexto da visão arquitetônica de software. MUDA é aplicado a um estudo de caso no domínio dos STI (Sistemas Tutoriais Inteligentes), mostrando a construção progressiva da arquitetura do sistema através de um mecanismo de referência elementos arquitectónicos dos requisitos funcionais e não funcionais.
Palavras-chave: arquitetura de software, os métodos de concepção arquitectónica, a qualidade do software.
Recibido: febrero 2009 Aceptado: mayo 2009
Introducción
El desarrollo de un proceso de diseño arquitectónico explícito se ha propuesto como un medio eficaz en el logro de sistemas de software confiables (Shaw y Garlan, 1996; Bosch 2000). Aunado a lo anterior, la creciente demanda de sistemas que permitan la realización de transacciones a través de la Internet, ha evidenciado la necesidad de tomar en cuenta aspectos de calidad tales como la portabilidad, eficiencia, facilidad de uso, la reutilización de soluciones, entre otros; que requieren el análisis de posibles soluciones y consiguiente toma de decisiones arquitectónicas que son registradas en un diseño arquitectónico. En otras palabras, es el diseño arquitectónico la herramienta que permite asegurar la apropiada calidad de un sistema, siendo esta la principal razón que ha impulsado el creciente auge de las investigaciones en esta área (Losavio, Chirinos, Lévy, Ramdane-Cherif, 2002).
Si bien la primera meta que debe ser alcanzada al producir un sistema de software es que ofrezca las funcionalidades para las cuales fue concebido, es también cierto que debido a la complejidad de tales sistemas, su funcionamiento depende cada vez más del logro de características de calidad.
En la actualidad, es comúnmente aceptado el hecho de que la arquitectura debe implementar un conjunto de mecanismos que permitan el logro de las características de calidad, lo que significa que las decisiones arquitectónicas subyacentes serán fuertemente influenciadas por la necesidad de lograr tales objetivos de calidad. La relación entre arquitectura y calidad evidencia la problemática centrada en la comprensión y sustentación de la interacción que surge entre los requisitos iniciales de un sistema y el diseño arquitectónico resultante, siendo todavía un tema abierto lo relativo a los procedimientos y técnicas que permitan determinar, a partir de un conjunto de requisitos iniciales, el diseño arquitectónico más idóneo. Tal tarea sigue siendo muy compleja y básicamente sustentada en la intuición del arquitecto de software.
Este trabajo presenta una primera versión de MUDA (Método Unifi
cado 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 arquitec
tó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, f
acilita la identificación y refinamiento de la información arquitectónicamente relevante contenida en el conjunto de requisitos iniciales.Este artículo está organizado de la siguiente manera: en la sección 2 se presentan algunos antecedentes del trabajo. En la sección 3 se describe el método MUDA. En la sección 4 se expone brevemente el caso de estudio para luego en la sección 5 explica la aplicación de MUDA a dicho caso. Por último, la sección 6 contiene las conclusiones obtenidas.
Antecedentes
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.MUDA (Método Unificado de Diseño Arquitectónico)
Este método está estructurado por tres fases. La primera es la fase de preparación, cuyo objetivo es extraer los requisitos arquitectónicamente significativos y expresarlos de manera que se facilite la posterior identificación de elementos arquitectónicos. En la segunda etapa se busca generar una arquitectura base sobre la cual realizar las transformaciones necesarias para la consecución de las características de calidad registradas en el modelo de calidad del sistema. En la tercera etapa se aplican los mecanismos arquitectónicos que mejor respondan a los requisitos de calidad iniciales. A continuación se describen tales etapas, así como las actividades y entregables generados en cada una de ellas.
1. Etapa de Preparación: en la que se deben organizar los requisitos obtenidos del análisis del dominio. Se supone que como etapa previa al diseño arquitectónico, un proceso de levantamiento de requisitos se ha llevado a cabo, generando como mínimo una lista de requisitos funcionales y las principales restricciones sobre el sistema. Esta etapa se divide en dos actividades:
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.b. Generación del Árbol de Utilidad: cuyo objetivo es capturar las características de calidad (requisitos no funcionales) iniciales que se esperan del sistema. Para esto, se puede partir de los requisitos que fueron identificados y asignados a los casos de uso durante su especificación. También se debe considerar la información referente a las restricciones propias del dominio de la aplicación. El artefacto final debe ser un Árbol de Calidad (Kazman y otros, 1998), expresado según el modelo de calidad estándar de ISO/IEC 9126-1. Dicho árbol debe ser refinado hasta lograr que en las hojas se encuentren escenarios en los que, según el criterio de los especialistas que intervienen en la ejecución del método, se manifiesten todas las características identificadas. Una vez generado el árbol de calidad, se deben clasificar los escenarios ubicados en las hojas según la taxonomía de artefactos propuesta por Grünbacher, Egyed y Medvidovic (2003). Esta taxonomía está compuesta por las siguientes categorías de artefactos:
i. C: artefactos que describen o involucren componentes individuales en una arquitectura.
ii. CP: artefactos relacionados con propiedades de componentes.
iii. B: artefactos que describen o involucran a un conector (Bus).
iv. S: artefactos que describen características que involucran a una amplia sección de componentes del sistema
v. BP: artefactos relacionados con propiedades de un conector.
vi. SP: artefactos relacionados con propiedades del sistema.
La taxonomía anterior permite jerarquizar el conjunto inicial de escenarios generado en el árbol de calidad, convirtiéndose en un producto intermedio entre la lista de requisitos y la arquitectura.
2. Etapa de Derivación Arquitectónica: esta etapa persigue generar una arquitectura base o inicial sobre la cual poder realizar transformaciones que respondan a los requisitos tanto funcionales como no funcionales. Se compone de dos actividades:
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 lanotació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.b. Generación del Modelo CC (modelo de componentes y conectores): lo que se logra inicialmente asignando relaciones entre los componentes del modelo anterior (modelo de componentes). Tales relaciones deben ser analizadas para discernir cuáles se derivarán en conectores o en relaciones de composición que generarán componentes estructurados. A partir de las relaciones de dependencia y de los escenarios de tipo B, se producen conectores. Asimismo, los escenarios de tipo BP se ubican como propiedades de los conectores.
3. Etapa de Refinamiento Arquitectónico: en la que se refina la estructura hasta el momento obtenida. Se compone de dos actividades:
a. Identificación de Subsistemas, Estilos y Patrones: a partir de los escenarios identificados como artefactos S o SP. Como los artefactos S y SP se refieren al sistema o a subsistemas, permitirán:
i. Identificar subsistemas y su estructura interna a partir de los componentes identificados en el modelo CC.
ii. Identificar los estilos y/o patrones arquitectónicos que respondan a los artefactos SP.
b. Aplicación de Estilos y Patrones Arquitectónicos: una vez identificados se aplican al modelo CC, lo que transformará la arquitectura para conseguir responder a los requisitos de calidad. El resultado es la arquitectura base.
4. Estudio de un caso:
sistema de software educativo en el dominio de la enseñanza de la físicaEl 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 computa
dor) utilizando tecnología y técnicas de inteligencia artificial. Este modelo identifica los siguientes componentes (ver Figura 1):Base de conocimiento: referido al qué enseñar. Lo elabora un ingeniero de conocimiento (investigador).
Modelo del estudiante: comprende: (a) un modelo externo: elaborado por el diseñador, y (b) un modelo interno que se construye a partir de lo que el estudiante ejecuta en cada sesión de trabajo. Este modelo puede ser obtenido a partir del análisis de los reportes que generare el sistema. El modelo del estudiante que se presenta está basado en las rutas de aprendizaje (secuencia en la selección de opciones didácticas) y en los errores conceptuales y operacionales que cometen los estudiantes (Esteves, 2001).
Educador experto (docente): decide cómo enseñar. Selecciona las opciones didácticas en concordancia con la actividad del estudiante.
Subsistema de comunicación: es la interfaz con todas sus característi
cas: colores, movimiento, rapidez de presentación; en general, determina la "calidad de la interacción" entre el usuario y el objeto de conocimiento.Subsistema de aprendizaje: surge por la presencia del ser humano. Este componente debe incorporar toda la nueva información que pueda surgir de la interacción sistema-usuario para ampliar el conocimiento que se tiene de los estudiantes y adaptar el sistema a sus características.
Los elementos teóricos fundamentales a los que debe responder este sistema instruccional se muestran en la Figura 2 (Esteves, Rodríguez y Guillén, 2003) de la cual se desprende que el software:
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).
5. Aplicación de MUDA
En esta sección se describe el proceso mediante el cual se obtiene la arquitectura para el sistema descrito en la sección anterior.
5. 1. Etapa de Preparación
Generación del Modelo de Casos de Uso
Durante la identificación de los requisitos funcionales, se realizó una especificación de un conjunto de casos de uso. Partiendo de este entregable se procedió a generar varios diagramas de casos de uso con el fin de identificar las relaciones existentes entre estos. Al mismo tiempo, el diagrama de casos de uso permitió el refinamiento de las funcionalidades, identificándose en consecuencia un conjunto de casos de uso específicos.
Es importante resaltar que el objetivo de la etapa es precisamente la presentación de los requisitos capturados desde un punto de vista arquitectónico, con lo cual se quiere significar que tales requisitos deben ser expresados de manera que expongan información significativa para la configuración de la arquitectura. De esta forma, se refinan los requisitos iniciales y se les describe en un lenguaje centrado en la visión arquitectónica del software (ver Figura 3).
Por otra parte, tomando en cuenta la semántica de los casos de uso, estos se pueden agrupar en dos grandes grupos: los que se refieren a las ejecuciones de las rutas didácticas por parte del estudiante y los que se refieren a la administración del conocimiento, donde se incluyen aspectos relacionados al registro y consulta de los resultados, así como la adición de nuevas opciones didácticas.
Generación del Árbol de Utilidad
Si bien son los casos de uso los medios para la captura y descripción de los requisitos funcionales, en el caso de los requisitos no funcionales también denominados características de calidad, son los escenarios los medios por los cuales se logra su descripción. En este sentido, se procedió a elaborar un árbol de utilidad (Kazman y otros, 1998), colocando en las hojas los escenarios en los que se considera que se manifiestan tales características. Cada uno de los escenarios identificados debe ser atendido a través de la adopción de distintos mecanismos que deben ser integrados en la arquitectura resultante. Al mismo tiempo, se clasificaron cada uno de los escenarios según la taxonomía propuesta por Grünbacher, Egyed y Medvidovic (2003). Tal clasificación tiene como objetivo facilitar la derivación de los componentes y conectores que constituirán la arquitectura del sistema. Cada uno de los escenarios se consideran entonces como artefactos que afectarán a componentes, conectores o al sistema en general, por lo que podrían ser llamados proto-elementos arquitectónicos. En las Figuras 4 y 5 se muestran algunos escenarios ubicados en las hojas del árbol de utilidad generado.
5.2. Etapa de Derivación Arquitectónica
Generación del Modelo de Componentes
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
transformaciones en la arquitectura en lo relativo su topología, número de componentes, asignaciones de responsabilidades y relaciones entre los componentes. En el Cuadro 1 se muestra la relación que se ha establecido entre los escenarios de calidad y las estrategias de solución arquitectónica.
La Figura 7 muestra el conjunto de componentes generados a partir
del Árbol de Utilidad. Tales componentes se consideran necesarios para la aplicación de las estrategias arquitectónicas adoptadas para responder a los requisitos de calidad planteados.Generación del Modelo Componentes-Conectores
Para la generación de este modelo, es necesario realizar la unificación de los modelos de componentes obtenidos en el paso anterior, lo cual puede conducir a la fusión de componentes o a la sustitución de un componente por otro. En principio, estos componentes lucen monolíticos, sin embargo, un refinamiento posterior de tales componentes conduciráa la generación de una estructura interna en muchos de ellos.
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 depen
dencia 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.Este modelo también evidencia la necesidad de simplificar los canales de comunicación entre los componentes, lo cual se puede lograr a través de la aplicación de estilos y patrones arquitectónicos. Lo anterior conduce necesariamente a otro esfuerzo de refinamiento en el que se simplifican las conexiones entre los componentes. En la Figura 9 se muestran los cambios realizados en la arquitectura con el fin de simplificar la comunicación entre los componentes. Obsérvese que la aplicación de los patrones Mediador (Gamma, Helm, Johnson y Vlissides, 1998) y Publicador-Subscritor (Clements y otros, 2002) permitió simplificar las conexiones entre los componentes otorgando a la estructura de la arquitectura mayor claridad. Al unísono, por ser los patrones antes mencionados mecanismos de indirección de datos, favorecen el desacoplamiento entre los componentes de una arquitectura lo que se traduce en un aumento en la facilidad de modificación de la arquitectura en función de los posibles escenarios de mutabilidad que se pueden suscitar en el futuro.
Es importante mencionar que los elementos identificados en el modelo presentado en la Figura 9 como Mediador_personalización y Mediador_datos, han sido definidos como conectores. En el primer caso, el conector permite la comunicación entre varios componentes relacionados con la funcionalidad de personalización del subsistema Tutor. De esta forma, se prevee que si se produce la actualización de alguno de los componentes involucrados, se minimicen los efectos entre los restantes. En el caso del Mediador_datos, su objetivo es aislar los aspectos de conectividad propios de la aplicación con respecto al componente encargado del almacenamiento y administración de los datos. De esta forma, se favorece tanto la facilidad de modificación como la portabilidad del sistema.
Etapa de Refinamiento Arquitectónico
Identificación de Subsistemas y Aplicación de Estilos y Patrones Arquitectónicos
En la Figura 9 se muestran los subsistemas identificados y los componentes incluidos en cada uno. Adicionalmente, se refina la arquitectura por medio de la aplicación del estilo de capas, lográndose por una parte, cohesionar los componentes que presenten similitudes entre si en cuanto a las áreas funcionales en las que actúan; y por otra, disminuir el acoplamiento entre los componentes dedicados a la presentación del sistema, los componentes dedicados a la lógica del sistema y los componentes que facilitan la persistencia.
Los subsistemas identificados son el Subsistema Tutor y el Subsistema de Análisis, ubicados en la capa lógica. Cada uno de los subsistemas posee su propia interfaz gráfica, localizada en la capa de presentación. Al mismo tiempo, la capa lógica (Subsistema de Tutor y Subsistema de Análisis) puede acceder a la capa de persistencia a través de la capa de acceso, la cual actúa como un conector que encapsula los aspectos relativos al establecimiento de la comunicación entre el sistema y los mecanismos de almacenamiento (capa de persistencia).
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.Conclusiones
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.Referencias
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 CASCON97. [ 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 auto
mated 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 ]