Francisca Losavio de Ordáz

  Universidad Central de Venezuela

Christian Guillén-Drija

  UPEL Instituto Pedagógico de Miranda José Manuel Siso Martínez

Los métodos actuales de diseño arquitectónico coinciden en la importancia de tomar en cuenta los aspectos de calidad para dirigir la selección de la solución arquitectónica, sin embargo aún no hay acuerdo sobre métodos precisos que puedan ser usados en la práctica común. Distintas propuestas de métodos de diseño arquitectónico se han presentado hasta el momento (Grünbacher, Egyed y Medvidovic, 2003) (Lamsweerde, 2003) (Losavio, Chirinos, Lévy, Ramdane-Cherif, 2003), (Chung, Cooper y Yi, 2003), (Losavio, Chirinos y Pérez, 2001), (Bosch, 2000) fundamentados en conceptos que o bien son equivalentes, complementarios o alternativos. El presente trabajo, inspirado en los métodos mencionados, tiene como objetivo la definición de un marco conceptual, de referencia o framework que contemple un proceso general de diseño arquitectónico centrado en las propiedades de calidad exigidas por requisitos funcionales y no funcionales. Este framework constituye una estructura unificadora que permite especificar los diferentes elementos del proceso del diseño arquitectónico, siendo este el principal aporte del trabajo.

Palabras clave: Arquitectura del software, Métodos de diseño arquitectónico, Calidad de software.

Conceptual Framework for Architectural Design Based on Quality Aspects.

Key words: Software, Architectural Design Methods, Software Quality.

* Recibido: marzo 2006.

Aceptado: junio 2006.

Es indiscutible la importancia que tiene la industria del software, por lo que es relevante caracterizar el proceso de desarrollo que se lleva a cabo en la mayoría de las organizaciones. En general, tales procesos de desarrollo se caracterizan por poner énfasis en la entrega, tomándose decisiones siempre en función de una fecha límite en detrimento de la calidad del producto final. Como una consecuencia de lo anterior, los sistemas de software son desarrollados sin considerar su posible evolución en el tiempo, su mantenimiento y extensibilidad; características que condicionaran el tiempo de vida de tales sistemas.

Aunque tales procesos de desarrollo se centran en fechas límites de entrega, son escasos los proyectos que logran cumplir con tal requerimiento. Por otra parte, muchos productos generados por las organizaciones en las que se aplican procesos de desarrollo con las características antes descritas, carecen de calidad, aspecto que se evidencia en los altos costos generados en la solución de problemas en sistemas ya entregados y en funcionamiento.

Los costos aumentan aun más cuando los sistemas necesitan mantenimiento para poder extender sus funciones y así poder responder a nuevas situaciones o procesos.

Como respuesta a la problemática descrita, surge la disciplina denominada Ingeniería de Software, la cual trata todos los aspectos relacionados con la producción de software, entre los que se encuentra la generación y estructuración de procesos de desarrollo así como la creación lenguajes que permitan expresar de manera clara los artefactos de diseño producidos durante tales procesos de desarrollo. Todo lo anterior con el fin de lograr que los requerimientos exigidos por clientes, usuarios y toda persona con algún interés en el futuro sistema, sean atendidos adecuadamente.

Los requerimientos están constituidos por todas aquellas exigencias que los distintos interesados hacen al futuro sistema; pero también se deben incluir las demandas que otros sistemas puedan realizar cuando interactúen con este. Tales exigencias se dividen en requerimientos funcionales y requerimientos no funcionales. Los primeros se refieren a las distintas funcionalidades que el sistema ofrece, que comúnmente son los más fáciles de registrar, puesto que son los más evidentes. Los segundos se conocen como atributos de calidad, entre los que se encuentran: seguridad, reutilización, facilidad de uso, facilidad de mantenimiento, robustez, extensibilidad, etc.

La experiencia lograda por la comunidad de ingenieros de software, ha evidenciado la necesidad de tratar de manera explícita a los atributos de calidad, surgiendo de esta forma una disciplina relativamente nueva dentro de la ingeniería de software denominada arquitectura de software.

La arquitectura de software concibe a los sistemas de software a un alto nivel de abstracción en el que tales sistemas están compuestos por componentes y conectores. Los componentes se refieren a elementos en los que se llevan a cabo cómputos, mientras que los conectores son concebidos como elementos que permiten la comunicación entre los componentes. Cuando los componentes y conectores se ensamblan, se constituyen en una arquitectura.

Una visión arquitectónica del software es útil porque permite el tratamiento explícito de los atributos de calidad y por lo tanto su presencia en el sistema a construir. Cuando se selecciona una determinada arquitectura, se imponen mecanismos que favorecen ciertos atributos de calidad.

Por otra parte, una visión arquitectónica, facilita la comunicación entre los distintos especialistas, puesto que obvia los detalles de implementación, centrándose en los mecanismos necesarios para el logro de los requerimientos de calidad que cada uno de ellos exige. Tal comunicación permite que se identifiquen riesgos y fortalezas en la arquitectura, pudiéndose entonces idear alternativas que equilibren fuerzas contrapuestas a través de la negociación.

Por último, facilita la creación de líneas de componentes de software. Cuando se logra la creación de una línea de componentes para un determinado dominio, se pueden entonces reutilizar en distintos productos, disminuyéndose considerablemente costos de producción.

Métodos como RUP (Krutchen, 2000) o el propuesto por Bosh (2000), incorporan en sus primeras etapas el diseño arquitectónico, en la que se debe hacer referencia a los requerimientos no funcionales; sin embargo, no explican detalladamente cuales son las actividades a desarrollar en dicha etapa. Tal imprecisión ha traído como consecuencia que, en general, los requerimientos de calidad sean tratados informalmente.

Para responder a tales imprecisiones, Lamsweerde (2003), Losavio, Chirinos y Pérez (2001), y Gross y Yu (2001), entre otros; han intentado describir con mayor detalle las actividades ha realizar para la generación y transformación de la arquitectura de un sistema de software. Como un producto de la comparación de varios métodos, este trabajo propone un método genérico de diseño arquitectónico que intenta integrar distintos enfoques estudiados en una primera aproximación.

Además de la introducción y conclusiones, el presente artículo está estructurado de la siguiente manera: en la sección 2 se presentan algunos métodos centrados en la visión arquitectónica del software; en la sección 3, se propone una lista de características deseables en un método de diseño arquitectónico; en la sección 4, se hace referencia a los conceptos arquitectónicos introducidos en UML 2.0, haciéndolo elegible para ser integrado a un método de diseño arquitectónico; para culminar presentando una propuesta de método de diseño arquitectónico en la sección 5.

En el caso de RUP, la arquitectura del sistema de software es concebida en la fase de Elaboración, dentro del Workflow de Levantamiento de requisitos (inception Workflow). En cada iteración, los modelos que se generan en el proceso sufren cambios, y en consecuencia, la arquitectura es también generada de forma incremental. Lo anterior se explica por el hecho de que la arquitectura es descrita por medio de las distintas vistas basadas en tales modelos. Inicialmente, los casos de uso son utilizados para definir los componentes principales a un alto nivel de abstracción, lo que constituye la arquitectura inicial, o también denominada arquitectura base; sin embargo, no se detalla la relación entre los casos de uso, los cuales representan las funcionalidades principales del sistema y los requerimientos no funcionales.

Por otra parte, Bosch (2000), presenta un enfoque basado en la transformación de una arquitectura inicial, por ejemplo generada a partir de los casos de uso. Cada transformación consiste en la generación de soluciones dirigidas a optimizar un atributo de calidad, lo que generalmente puede afectar negativamente a otras características de calidad. Tal hecho, genera sucesivas transformaciones hasta lograr que el sistema adquiera una arquitectura que permita un balance aceptable entre las distintas características de calidad consideradas.

Como puede observarse, los enfoques anteriores colocan especial énfasis en la relación existente entre los requisitos iniciales de un sistema y la arquitectura generada a partir de estos. No obstante, la generación de una arquitectura que satisfaga los requisitos iniciales, es aún una tarea ardua, principalmente se 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 (Jani, Vanderveken y Perry, 2004). A este respecto, se han realizado esfuerzos dirigidos a la concepción de frameworks que propongan mecanismos para la generación de arquitecturas tomando en cuenta tanto los requerimientos funcionales como los no funcionales. Entre tales propuestas, se encuentran las de Chung, Cooper y Yi (2003), Grünbacher, Egyed y Medvidovic (2003) y Lamsweerde (2003).

El framework propuesto por Chung y otros (2003), se caracteriza por el énfasis en el tratamiento de los requerimientos como punto de partida de un proceso de análisis orientado a la identificación de mecanismos arquitectónicos que ofrezcan respuesta a los requerimientos no funcionales del sistema como antesala al diseño arquitectónico. Es importante acotar que en muchos casos, dichos mecanismos u operacionalizaciones, entendidas estas como posibles soluciones a los requerimientos no funcionales planteados, pueden derivar en la aplicación de un patrón de diseño arquitectónico. Sin embargo, su objetivo no es la generación de una arquitectura, sino más bien la identificación de piezas arquitecturales que subsecuentemente pudiesen formar parte de una arquitectura. Como se puede observar, este framework busca responder a la problemática planteada alrededor de la transformación consistente de los requerimientos en una arquitectura idónea.

Grünbacher y otros (2003) proponen el enfoque CBSP (Component-Bus-System-Property), como un método sistemático dirigido a facilitar el refinamiento de un conjunto de requerimientos y expresarlos en una arquitectura aplicando para ello una taxonomía de dimensiones arquitecturales. La idea que subyace es que cualquier requerimiento 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, y (6) artefactos que describen o involucran propiedades de un sistema o subsistema. Esta taxonomía es aplicada al conjunto de requerimientos, dando como resultado un conjunto de descripciones de la relevancia arquitectónica a partir de los requerimientos significativos. En el proceso, producen dos tipos de información: (1) un conjunto artefactos (componentes) que describen decisiones arquitectónicas y (2) enlaces, que describen las dependencias entre esos artefactos. Los artefactos proporcionan piezas potenciales que pueden formar parte de la arquitectura, mientras que los enlaces ayudan a clarificar las dependencias de control y datos entre dichos bloques. 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 requerimientos no funcionales.

Lamsweerde (2003), presenta un proceso de derivación, que tomando un conjunto de requerimientos, genera una especificación funcional del sistema. A continuación, tales especificaciones son tratadas para generar una primera versión de la arquitectura, que luego es refinada para que responda a las restricciones impuestas por el dominio del problema. En la última fase del problema, la arquitectura es refinada en forma recursiva para ir logrando los objetivos no funcionales modelados durante el proceso de ingeniería de procesos. El proceso descrito se caracteriza por partir de objetivos funcionales, de los cuales se derivan agentes de software que respondan a dichos objetivos. Tales agentes son relacionados con objetivos no funcionales, generándose un modelo que es sometido a un análisis que permita determinar las relaciones entre ellos y de esta forma, lograr un primer bosquejo de la arquitectura, compuesta por componentes y conectores.

Como puede observarse, los tres últimos enfoques se centran en la realización de la transición desde los requerimientos hacia la arquitectura del sistema a través de un proceso de derivación sistemática. Intentan de esta forma responder a las imprecisiones o generalidades presentes en las etapas de diseño arquitectónico dentro de procesos de desarrollo de software como RUP (Krutchen, 2000) y Bosch (Bosch, 2000).

El diseño arquitectónico consiste 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 determinar cuales son los más convenientes en función de los requerimientos iniciales. Cuando se logra tal objetivo, se 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. Dichas 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 escogido y con los patrones que constituyan dicho estilo. Este 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, (Losavio, Chirinos y Pérez, 2001) (Losavio, Chirinos, Lévy y Ramdane-Cherif, 2003) lo que permite escoger una arquitectura inicial.

En síntesis, una comparación preliminar de las distintas propuestas referenciadas, sugiere la posibilidad de definir un marco conceptual para un diseño arquitectónico basado en aspectos de calidad que podría considerar la derivación de requisitos en elementos arquitecturales, la generación de una arquitectura base y transformaciones sucesivas guiadas por evaluaciones respecto a las prioridades de los objetivos de calidad fijados inicialmente en la especificación de requisitos, hasta obtener una arquitectura definitiva.

La diversidad de propuestas de métodos centrados en el diseño arquitectónico, sugiere la necesidad de establecer criterios de comparación que conduzcan a la definición de los aspectos deseables que tales métodos deben poseer. Trabajos realizados en este sentido facilitarían la escogencia de un método en particular, según los requerimientos de un proyecto; al mismo tiempo que se convierten en puntos de partida para trabajos tendientes a lograr un método general de diseño arquitectónico que intente unificar las distintas propuestas y así cubrir de forma efectiva los distintos aspectos involucrados en el diseño arquitectónico.

En este sentido, los trabajos realizados por Losavio y otros (2001) y Ali Babar, Zhu, y Jeffery (2004), presentan marcos de referencia para la comparación y evaluación de métodos de diseño arquitectónico, ofreciendo un punto de partida para la definición de un cuerpo de características concebidas como deseables en un método de diseño arquitectónico. Se considera entonces que un método de diseño arquitectónico debe:

1. Poseer una infraestructura arquitectónico-conceptual clara: el cuerpo de conceptos sobre los que se fundamenta el método debe contemplar todas las definiciones que como consecuencia de la investigación en el área de la arquitectura de software, son universalmente aceptadas. En otras palabras, debe utilizar los conceptos de componentes, conectores, interfaces (roles en el caso de conectores y puertos en el caso de los componentes), estilos arquitectónicos, restricciones arquitectónicas, comportamientos, componentes estructurados, entre otros.

2. Tratar explícitamente los requerimientos no funcionales: ya que la arquitectura de software surge como una respuesta a la creciente importancia que los investigadores han otorgado al tratamiento temprano de los atributos de calidad, esta característica es vital para que un método de diseño arquitectónico pueda ser considerado como tal. Ciertamente, son los requerimientos funcionales el punto de partida para la generación de una arquitectura inicial, pero son los requerimientos 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: cualquier método de diseño arquitectónico se iniciará a partir de un conjunto de requerimientos funcionales y no funcionales, generado como producto final de la actividad desplegada por un ingeniero de requerimientos. Una vez definido tal conjunto, el arquitecto de software debe convertir tales requerimientos en 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 mecanismos de descripción arquitectónica: para que se puedan obtener beneficios ciertos de una visión arquitectónica de los sistemas de software, se debe contar con formas de especificación que, además de describir expresamente aspectos arquitectónicos, posibiliten la aplicación de técnicas de análisis sobre tales descripciones (Guillén, 2002). Tales formas de descripción, deben proveer medios de abstracción adecuados que permitan expresar aspectos arquitectónicos de un sistema de software, evitando hacer referencia a los detalles de especificación. Como respuesta a lo anterior, surgen los ADLs (Arquitecture Description Languages) o Lenguajes de Descripción Arquitectónica. Un ADL proporciona una sintaxis concreta y un marco conceptual dentro del cual se produce un modelo arquitectónico de un sistema (Garlan, Monroe y Wile, 1997). Diversas han sido las propuestas que en esta área se han realizado (Guillén, 2002) sin conseguirse, no obstante, que su uso sea generalizado entre los arquitectos de software. En este sentido, la aparición de UML 2.0 (Unified Modeling Language), quizás sea el comienzo del fin de los ADLs, tal y como hoy se conocen; puesto que este lenguaje asume muchos de los conceptos arquitectónicos a los cuales los ADLs pretenden responder y el mismo es aplicado de forma generalizada dentro de muchas organizaciones. Sin embargo, este lenguaje no ha sido adoptado por los métodos de diseño arquitectónicos estudiados.

5. Tener como objetivo el logro de cualquier combinación atributos de calidad en general: algunos de los métodos de diseño arquitectónicos estudiados, están dirigidos al logro de atributos de calidad en particular. Lo deseable es que un método de diseño arquitectónico proporcione actividades que permitan el tratamiento de cualquier modelo de calidad, constituido por distintas combinaciones de atributos de calidad según el dominio de la aplicación.

6. Proporcionar actividades para la evaluación cualitativa y cuantitativa de la arquitectura: la evaluación permitirá determinar aquellos aspectos de una arquitectura que deben ser transformados para responder de forma apropiada a los atributos de calidad que se considera, debe tener el sistema de software. ATAM (Architecture Tradeoff Analysis Method), es un método de evaluación arquitectónica cuyo objetivo es determinar los efectos que un determinado atributo de calidad tiene sobre otros atributos dentro de una arquitectura (Kazman y otros, 1998). De esta forma se pueden identificar los riesgos que implica la adopción de una determina solución arquitectónica que busca favorecer ciertos atributos y así poder tomar las precauciones durante las etapas posteriores de desarrollo. Cuando se aplica a varias arquitecturas, se puede determinar cual de ellas responde de forma más adecuada al modelo de calidad planteado. Un método de diseño arquitectónico debe contemplar evaluaciones que permitan validar la arquitectura generada durante el diseño arquitectónico y determinar la necesidad o no de realizar transformaciones en dicha arquitectura.

]]> 7. Proporcionar actividades para la negociación entre los especialistas involucrados (Stakeholders): la negociación se hace necesaria cuando requerimientos de calidad realizados por distintos especialistas sobre un sistema, entran en conflicto. Cuando esto ocurre, se deben tomar decisiones que implican la sujeción de determinados atributos de calidad a otros que por medio de un proceso de votación son considerados como más importantes. En general, tales mecanismos de negociación implican la aplicación de métodos de negociación de grupos.

8. Proporcionar actividades de transformación arquitectónica: una vez determinados los riesgos que pueden ser entendidos como aspectos dentro de la arquitectura propensos a fallar frente a la demanda que sobre el sistema se realice de ciertos atributos de calidad considerados como centrales, el método de diseño debe proporcionar mecanismos que permitan la transformación de la arquitectura existente. Dichas transformaciones podrían ser logradas aplicando patrones de diseño arquitectónico o algún estilo arquitectónico que favorezca el modelo de calidad perseguido. Un método de diseño arquitectónico debe contemplar la posibilidad de realizar sucesivas transformaciones hasta el logro de los atributos de calidad necesarios.

9. Estar apoyado por herramientas de software: el diseño arquitectónico implica un esfuerzo intensivo de generación de información a través de diversas tareas como la recolección de datos, documentación y organización de la información arquitectónicamente relevante. La exigencia de tales tareas es una de las razones por las cuales muchas organizaciones no adoptan de manera amplia el diseño arquitectónico como una etapa en su proceso de desarrollo. Por consiguiente, se pone de manifiesto la necesidad de contar con herramientas automatizadas que auxilien a los especialistas en la ejecución de tales tareas.

10. Haber sido validado: lo cual se logra como resultado de la aplicación de un método a varios casos, probando su utilidad en repetidas ocasiones. El estudio de casos es la forma por medio de la cual una propuesta pasa a ser un método extensivamente adoptado. Un repositorio extenso de tales casos es una medida de la madurez del método.

11. Ser fácil de usar: lo que implica que el método sea fácil de aprender. Lo anterior dependerá de la complejidad tanto de la infraestructura conceptual como de la superestructura metodológica. Si estas son enrevesadas, evidentemente, la curva de aprendizaje será mayor. Un método en general debe poseer una infraestructura muy sencilla, en otras palabras, debe estar constituida por un cuerpo conceptual minimalista, que proporcione soporte a una superestructura ligera, eficiente y lo suficientemente general como para que el método pueda ser implementado por cualquier organización, según sus requerimientos particulares y proceso de desarrollo adoptado.

Como se mencionó en la sección anterior, un método de diseño debe proporcionar mecanismos para la descripción de la arquitectura a medida que esta se va generando durante el diseño. Métodos como los propuestos por Bosh (2000), Krutchen (2000) y Losavio, Chirinos, Matteo, Lévy, y Ramdane-Cherif (2003), no ofrecen explicación detallada de tales mecanismos; mientras que otros, centrados en la derivación arquitectónica (Grünbacher, Egyed, Medvidovic, 2003) (Gross y Yu, 2001) (Lamsweerde, 2003), proponen su propia semántica y notación para traducir requerimientos en elementos arquitectónicamente valiosos. La adopción de una notación con semántica arquitectónica clara y proclive a ser utilizada por una amplia variedad de especialistas, facilitaría el aprendizaje del mismo puesto que simplificaría en alguna medida la aplicación del método. Este trabajo sostiene que UML 2.0 puede ser incluido dentro de un marco conceptual para el diseño arquitectónico basado en aspectos de calidad.

UML 2.0 introduce nuevos conceptos y redefine otros presentes en sus versiones anteriores que desde el punto de vista arquitectónico son relevantes, a saber (Iver, Clements, Garlan, Nord, Schmerl y oviedo, 2004):

Interfaces: UML 2.0, extiende este concepto para definir explícitamente los términos de interfaces requeridas e interfaces proporcionadas. Una interfaz requerida describe las demandas que un componente realiza a su entorno para poder llevar a cabo sus funcionalidades; mientras que una interfaz proporcionada describe los servicios que un componente ofrece a su entorno. El hecho de que en UML 2.0 las interfaces son tratadas de forma explícita permite que estas sea descritas de manera más completa, incluyéndose atributos y aumentando la descripción de sus comportamientos por medio de máquinas de estado de protocolos, las cuales definen las restricciones en cuanto al uso de las características de las interfaces asociadas.

Existen tres formas de representar interfaces en UML 2.0. El gráfico 1, muestra la representación de una interfaz como un clasificador estereotipado con compartimientos contentivos de atributos. En este caso se diferencia la interfaz proporcionada de la requerida por medio de las relaciones que se establecen entre estas y el otro clasificador denominado server (servidor). Así la relación (de dependencia) entre el componente servidor y la interfaz de la base de datos, indica que el primero requiere de la segunda para poderse comunicar con la base de datos. Por otra parte, la relación (de realización) que se establece entre el servidor y la interfaz HTTPRequest indica que la interfaz es realizada por el servidor; en otras palabras, el entorno recibirá respuestas del servidor a través de la interfaz.

El gráfico 2, muestra otra forma de indicar las interfaces de un clasificador. En este caso, las interfaces se encuentran en los compartimientos del clasificador servidor. Cada interfaz es identificada como proporcionada o requerida por medio de la utilización de los estereotipos provided interfaces y required interfaces.

Una tercera alternativa se muestra en el gráfico 3, en la que las interfaces se representan gráficamente a través de clasificadores de conexión de tipo ball-and-socket (conocidos como "lollipops"). Las esferas (balls) representan las interfaces proporcionadas y los enchufes (sockets) representan interfaces requeridas. Este tipo de representación no incluye la descripción de las interfaces.

Puertos: un puerto es un nuevo concepto introducido en UML 2.0, que al igual que la interfaz, describe la manera en la que el clasificador interactúa con su ambiente. Sin embargo, la diferencia entre los dos conceptos estriba en que cada puerto es un punto de interacción distinto de su clasificador. Un clasificador puede especificar múltiples puertos, los cuales son creados¹ cuando el clasificador es creado. Cada puerto se puede relacionar con un número de interfaces. Los gráficos 4 y 5 muestran representaciones de puertos. La primera sin interfaces asociadas y la segunda con interfaces; la notación [1..*] indica que por cada instancia del clasificador se generarán una o varios puertos.

Clasificadores estructurados: Este nuevo concepto en UML, permite representar clasificadores estructurados por otros, dando mayor riqueza a las descripciones arquitectónicas en las que un sistema puede estar compuesto por subsistemas que se pueden relacionar entre si por medio de interfaces.

Componentes: Concepto que extiende al clasificador Clase, lo cual implica que un componente puede ser especializado, poseer descripciones de su comportamiento, tener una estructura interna, poseer puertos e interfaces, así como la posibilidad de ser creados (ver gráficos 6 y 7). A las características anteriores, se le agregan las siguientes:

• La habilidad de apropiarse de más tipos de elementos que las clases; como por ejemplo: paquetes, restricciones, casos de uso y artefactos.

• Poseer especificaciones de despliegue que definen sus parámetros de ejecución en un nodo.

De esta forma, UML 2.0 propone una notación que logra expresar la significación del término componente, vital en el diseño arquitectónico del software.

Conectores: aunque el concepto de conector es introducido en UML 2.0, su alcance no es suficiente para expresar las características que desde el punto de vista arquitectónico debe poseer un conector. Específicamente UML 2.0 falla al expresar la semántica que debe estar asociada a la descripción de un conector, o en la documentación de los roles que puede este asumir. Sin embargo, se puede establecer una estrategia que solucione tal dificultad, la cual puede consistir en concebir a un conector como un tipo especial de componente. Así como un componente es una especialización del clasificador Clase, puede generarse un estereotipo para representar a un conector también como una extensión del mismo clasificador. De esta forma, los conectores pueden ser tratados como elementos arquitectónicos de primer orden y formar parte de una descripción arquitectónica.

Todo lo expuesto en esta sección, permite concluir parcialmente que, aunque UML 2.0 debe seguir extendiéndose para responder de manera más clara a los requerimientos notacionales derivados de la visión arquitectónica del software, se vislumbra en el futuro como un mecanismo sencillo para descripción y la captura de información arquitectónicamente significativa.

Como resultado del estudio y comparación de los distintos métodos arquitecto-céntricos, se propone una primera versión de un marco conceptual para un método de diseño arquitectónico. Las etapas de este se describen a continuación:

1. Etapa de Preparación: en la que se deben organizar los requerimientos ya levantados. Se supone que como etapa previa al diseño arquitectónico, un proceso de levantamiento de requerimientos se ha llevado a cabo, generando como mínimo una lista de requerimientos funcionales. 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. 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, incluye o use (OMT, 2005a) 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. 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 requerimientos 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 requerimientos, 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 requerimientos no funcionales aparezcan.

b. Generación del Modelo de Calidad: cuyo objetivo es capturar los atributos de calidad (requerimientos no funcionales) iniciales que se esperan del sistema. Para esto, se puede partir de los atributos que fueron identificados y asignados a los casos de uso durante su especificación. El artefacto final debe ser un árbol de calidad a la manera del árbol de utilidad de atributos de calidad de ATAM (Attribute Tradeoff Análisis Method) (Kazman et al., 1998). Dicho árbol debe ser refinado hasta lograr que en las hojas de este se encuentren escenarios en los que, según el criterio de los especialistas que intervienen en la ejecución del método, se pongan de manifiesto todos los atributos identificados. Una vez generado el árbol de calidad, se deben clasificar los escenarios ubicados en las hojas según la taxonomía de artefactos CBSP 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 todo 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 requerimientos y la arquitectura.

2. Etapa de Derivación Arquitectónica: en esta etapa persigue generar una arquitectura base o inicial sobre la cual poder realizar transformaciones para así lograr una arquitectura que responda a los requerimientos tanto funcionales como no funcionales. Al igual que la etapa anterior, se compone de dos actividades:

a. Generación del modelo de componentes: lo que 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, que según la taxonomía CBSP, se le ha clasificado como un artefacto C, se le asigna componente, mientras que a los que se les ha clasificado como artefactos CP, se les intenta ubicar como propiedades de los componentes.

b. Generación del modelo CC: o el modelo de componentes y conectores; lo que se logra inicialmente asignando relaciones entre los componentes generados a partir del modelo de componentes de la actividad anterior. Tales relaciones deben ser analizadas para discernir cuales se derivarán en conectores o en relaciones de composición que generarán componentes estructurados. Las relaciones de dependencia generarán nuevos conectores. Por otra parte, a los escenarios que en el árbol de calidad fueron clasificados como artefactos B se les asignan conectores y estos se intentan asignar a los componentes ya existentes. A los escenarios que se identificaron como artefactos BP, se les intenta ubicar como propiedades de los conectores.

3. Etapa de Refinamiento Arquitectónico:

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 a el sistema o a subsistemas, nos 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 requerimientos de calidad. El resultado es la arquitectura base.

4. Etapa de Resolución de Resonancia Arquitectónica: compuesta por las siguientes actividades:

a. Evaluación de la arquitectura: Que consiste en validar la arquitectura lograda en la etapa anterior según ATAM (Kazman et al., 1998). Como resultado, se generan los siguientes entregables:

]]> i. Un conjunto de riesgos.

ii. Un conjunto de fortalezas.

iii. Un conjunto de aspectos sensibles y efectos colaterales.

iv. Una lista de enfoques y mecanismos arquitectónicos.

b. Transformación de la arquitectónica: Si el conjunto de riesgos es notable, entonces se deben aplicar los enfoques y mecanismos arquitectónicos que permitan solucionar o al menos minimizarlos, lo que conduciría a una nueva transformación de la arquitectura.

El método descrito intenta integrar distintas propuestas que se han realizado alrededor del diseño arquitectónico, al mismo tiempo que busca cumplir con las condiciones que se cree, son deseables en un método de este tipo. No obstante, se sigue trabajando en su refinamiento con el fin de describir de manera mucho más detallada las actividades, pasos, artefactos o entregables de cada etapa, así como en la identificación de los especialistas que deben intervenir en la ejecución de este método. Estamos concientes de que la presente propuesta necesita ser revisada con el fin de identificar posibles vacíos y contradicciones conceptuales, pero confiamos que en posteriores refinamientos se logre afianzar el marco conceptual aquí presentado. No obstante, sostenemos que este trabajo dirige en la dirección correcta para lograr responder a aspectos vitales como lo son los relacionados con la coherencia entre los distintos entregables generados en cada etapa, el tratamiento de los atributos de calidad, y la apropiada selección de mecanismos de descripción que aseguren la correcta comunicación entre los distintos especialistas que intervienen en el proceso de diseño arquitectónico.

Por otra parte, se considera de vital importancia la adecuada descripción del método así como la validación del método. Lo primero se espera lograr a través de la aplicación de SPEM (Software Process Engineering Metamodel Specification) (OMT, 2005b); mientras que lo segundo se obtendrá como resultado de estudios de casos en los que se aplique este método y así evaluar la pertinencia de las actividades incluidas en el mismo.

1. Ali Babar, M., Zhu, L., Jeffery, R. (2004). A Framework for Classifying and Comparing Software Architecture Evaluation Methods. Australia.        [ Links ]

2. Booch, J. (1994). Object-Oriented Análisis and Design with Applications. Benjamin/Cummings Publishing Co.        [ Links ]

3. Bosh, J. (2000). Design & Use of Software Architectures: Adopting and evolving a product-line approach. Great Britain: Pearson Education Limited.        [ Links ]

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

5. 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 ]

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

7. Gross, D. y Eric, Yu. (2001). From Non-Funtional Requeriments to Design through Patterns. Faculty of Information Studies. University of Toronto. Canada.        [ Links ]

8. Grünbacher P., Egyed A., Medvidovic, N. (2003). Reconciling Software Requirements and Architecture: The CBSP Approach, 2nd. International Workshop on Traceability In Emerging Forms of Software Engineering (TEFSE) with ASE 2003, Montreal, Canada.        [ Links ]

9. 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 ]

10. Iver, J., Clements, P., Garlan, D., Nord, R., Schmerl B., y oviedo, J. (2004).Documenting Component and Connector Views with UML 2.0. (Reporte No. CMU/SEI-2004-TR-008). Pittsburg, Carnegie Mellon University, Software Architecture Technology Initiative.        [ Links ]

11. Jacobson, I., Christerson, M., Jonsson, P., y Övergaard, G.(1992). Object-Oriented Software Engineering. A use case approach. Addison-Wesley.        [ Links ]

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

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

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

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

16. Losavio F., Chirinos L., Lévy N., Ramdane-Cherif A. (2003). Quality Characteristics for Software Architecture. Journal of object Technology, Vol 2, No. 2. pp. 133-150.        [ Links ]

17. Losavio, F., Chirinos, L., Matteo, A., Lévy, N. y Ramdane-Cherif, A. (2003). Putting ISO Standards into Practice for Architecture Evaluatión with the Unified Process. CDCH ARCAS project 03.13.45584.00. Universidad Central de Venezuela. Caracas, Venezuela.        [ Links ]

18. Losavio, F., Chirinos, L., Pérez, M. (2001). Feature Analysis for Quality-Based Architectural Design Methods. Caracas. CDCH.        [ Links ]

19. oMT (object Management Group). (2005a). Unified Modeling Language: Superstructure. version 2.0.formal/05-07-04.        [ Links ]

20. oMT (Management Group). (2005b). Software Process Engineering Metamodel Specification. Version 1.1.formal/05-01-06.        [ Links ]

21. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. y Lorensen, W. (1991). Object-oriented Modeling and Design. Prentice Hall.        [ Links ]

Notas:

¹ En este caso el término crear se utiliza como traducción del término técnico inglés instantiation, que se aplica al diseño orientado a objetos para denotar la acción de generar objetos de una clase.