ACM / Crossroads / Espanol / Xrds12-4 / 

Desarrollo Centrado en la Arquitectura: Un acercamiento diferente a la Ingeniería de Software

por John C. Georgas, Eric M. Dashofy, y Richard N. Taylor

Traducido por Nadia P. García Castellanos y Carlos A. Fernández Guillot

Introducción

Todo estudiante de ciencias computacionales ha practicado el desarrollo de software en cursos de introducción generalmente enfocados en programación y algoritmos. Estos cursos típicamente introducen sintaxis básicas de los lenguajes de computación como la decisiones y ciclos junto con principios básicos de diseño como la abstracción, modularidad y encapsulamiento. Para la mayoría de los problemas pequeños estos principios son suficientes. Sin embargo, conforme la complejidad crece, estas técnicas son insuficientes para asegurar un producto exitoso que permita que los requerimientos y las expectativas de calidad sean alcanzados. Los grandes proyectos de software tienen grandes posibilidades de falla: el reporte del grupo Standish [18] declara que cerca de un tercio de los proyectos son cancelados antes de completarse y más de la mitad sufren serios incrementos en su costo.

La ingeniería de software a gran escala es una actividad inherentemente compleja que involucra la creación y manipulación, por varias personas, de un gran número de artefactos frecuentemente intangibles y muy dinámicos. Éstos pueden incluir especificaciones de requerimientos, diseños de software de alto nivel, código fuente, información de pruebas, y mantenimiento y necesidades de evolución posteriores a la implementación. Debido a la complejidad de la actividad, muchos de los esfuerzos se han dedicado a mejorar el proceso de ingeniería de software, esto es, los pasos a seguir durante la construcción del software. Estándares ampliamente aceptados para alcanzar la calidad, como el conocido como Capability Maturity Model (CMM) [Modelo de Capacidad de Madurez] [6] se enfocan exclusivamente en el proceso. Aun a pesar de estas mejoras al proceso, no necesariamente veremos un mejoramiento significativo correspondiente en el software que construyamos. Un buen proceso no garantiza un buen producto.

Nosotros creemos que existe otro camino para mejorar la calidad del software y las probabilidades de éxito de los proyectos. La arquitectura de software es una disciplina capaz de conectar e integrar a personas, actividades y productos involucrados en la ingeniería de software. La arquitectura de software permite a los ingenieros mayor control e introspección en el sistema en el proceso de desarrollo desde sus inicios, y promueve la temprana identificación y prevención de problemas. Como resultado, la arquitectura puede guiar el proyecto al éxito en vez de librarlo al fracaso por falta de entendimiento.

Todo sistema de software, desde el más pequeño hasta los sistemas multi-organizacionales tienen una arquitectura que puede variar en calidad. La arquitectura captura el conjunto de decisiones principales de diseño que se hacen sobre un sistema. Las decisiones de diseño son elecciones hechas pensando en cómo el sistema se desarrollará y cómo funcionará, y estas elecciones pueden incluir estructura, organización, funcionalidad, comportamiento, o más propiedades no funcionales como la usabilidad y estética [de la interfaz de usuario]. La importancia de estas decisiones de diseño varía para cada sistema de software y está en función de los interesados en el sistema, sus preocupaciones, y sus necesidades específicas. Una cuestión clave es que, a pesar de que la arquitectura es fundamentalmente una actividad centrada en el diseño, afecta a todo el ciclo de vida. Las decisiones de la arquitectura se concentran en lo que es esencial en un sistema la influencia de los requerimientos y las actividades importantes con el diseño colaborativo, el desarrollo e implementación del sistema, la planeación de su evolución y su adaptación.

Adquirir todos los beneficios de la arquitectura de software requiere una aplicación apropiada de la disciplina. Los sistemas con buena arquitectura son propensos al éxito, mientras sistemas con arquitecturas pobres están condenados a fallar. Este artículo propone una "caja de herramientas" de conceptos, herramientas, notaciones, y métodos que, combinados con las tradicionales y buenas técnicas y procesos de ingeniería de software, comprenden un método nuevo de desarrollo de software centrado en la arquitectura. Toda la discusión entera se establece en el contexto de investigación prometedora en el campo de la arquitectura de software y provee consejos y una idea general de útiles métodos, y herramientas de investigación que pueden ser adoptadas en la práctica de la ingeniería de software.

Una introducción a la (buena) Arquitectura de Software

Esta sección introduce a los conceptos básicos de la arquitectura de software: los ingredientes de una buena arquitectura y actividades requeridas. Estos temas servirán como fundamentos para las discusiones posteriores.

Elementos básicos de arquitectura

Las buenas arquitecturas, en el nivel más básico, capturan la estructura de un sistema de software en términos de elementos arquitectónicos de alto nivel. Estos elementos son componentes y conectores, ligados entre ellos en configuraciones específicas [15]. Los componentes son elementos arquitectónicos que son, primordialmente, responsables de la computación. Conforme los componentes involucran los aspectos funcionales del sistema, las estrategias tradicionales de diseño, como la descomposición funcional, pueden contribuir significantemente a la identificación y restricciones de componentes. Los conectores son elementos que solo son responsables de facilitar y administrar la comunicación entre los componentes. Los conectores permiten que los componentes independientes interactúen sin la necesidad de un conocimiento directo mutuo. Al ser la independencia de componentes la llave de la reutilización, los conectores pueden significar un ahorro significativo de costo. Finalmente, las configuraciones combinan componentes y conectores en una unidad, única y coherente. Las configuraciones dirigen el comportamiento del sistema de software.

Estos componentes y conectores arquitectónicos no son abstracciones lógicas únicamente útiles durante el diseño, sino que deben ser explícitamente modelados, conservados e implementados para que acompañen al sistema y sean utilizados durante su desarrollo y despliegue.

Modelado Arquitectónico

El modelado arquitectónico es el proceso de capturar y documentar decisiones del diseño arquitectónico y puede hacerse de diferentes maneras. Algunos arquitectos y desarrolladores capturan las decisiones de diseño arquitectónico usando documentos de lenguaje natural y diagramas abstractos de "cajas y flechas". Mientras estas formas informales de documentar son útiles en muchos aspectos, generalmente carecen del rigor y la precisión necesarias para la descripción comprensible de la arquitectura.

La clave para habilitar la arquitectura en otras áreas, además del diseño, es lograr un nivel apropiado de rigor y precisión en el modelado arquitectónico. Los modelos buenos proveen la base para el análisis arquitectónico, la comprensión y la comunicación del diseño del sistema, y guiar la evolución del mismo. Los Lenguajes de Descripción de Arquitectura (ADL por sus siglas en inglés) son notaciones diseñadas específicamente para lograr las especificaciones de rigor y precisión de las arquitecturas.

Muchos ADLs han sido desarrollados para documentar conceptos importantes para ciertos dominios o áreas de interés. El lenguaje Wright [2], por ejemplo, se enfoca en el análisis formal de interacciones de componentes basado en los conectores y por ello incluye el soporte de un lenguaje para capturar este aspecto de la arquitectura de software. Una nueva rama de la investigación del ADL se ha enfocado en la extensibilidad, esto es, crear ADLs que los interesados puedan adaptar fácilmente para soportar sus nuevas necesidades o combinaciones de las mismas. Ejemplos en este artículo usan el lenguaje basado en XML, xADL 2.0 [7], el cual es único porque se enfoca en una definición modular de ADLs a través de mecanismos extensibles que provee el esquema XML. El lenguaje xADL 2.0 está acompañado de un conjunto de herramientas que abarcan el ciclo de vida de la ingeniería de software desde el diseño hasta el mantenimiento, pasando a través de la implementación.

Retorno de la inversión: El Valor de la Arquitectura

En esta sección, discutimos técnicas y herramientas aplicables a varios momentos en el ciclo de vida de la ingeniería de software. Estas técnicas han demostrado agregar valor significativo a la ingeniería de software ya sea a través de mejoras de calidad, reduciendo el tiempo que toma el producto en llegar al mercado o reduciendo los costos.

Diseño y Análisis

El diseño y el desarrollo arquitectónico empieza con los intersados en el sistema. El desarrollo de una arquitectura es fundamentalmente una actividad dirigida por los problemas a solucionar. Maier y Rechtin, en su libro El Arte de la Arquitectura de Sistemas [13], usan un diagrama similar a la Figura 1 para describir la relación entre el problema a solucionar y la arquitectura.

Figura 1: Una ilustración de la relación entre los problemas a solucionar y la arquitectura

Cada barra en esta figura representa un problema a solucionar de uno o más interesados. Algunos problemas a solucionar, representados por las barras más profundas, son más importantes que otros: por ejemplo, en un sistema médico, la confianza ha de ser mucho más importante que la "reconfiguración". Arquitectónicamente, el nivel de detalle usado para capturar un problema debe de ser proporcional a la profundidad del mismo. Los problemas menos importantes serán señalados con un nivel más abstracto de detalle, mientras los más importantes serán señalados con mayor precisión arquitectónica.

Aunque este diagrama es definitivamente simple, conlleva un intenso mensaje: la arquitectura de un sistema es manejada y se basa en lo que los interesados consideran más importante. Claro que los problemas variarán de un sistema a otro. Mantener el enfoque en los problemas a solucionar asegura que la atención sea puesta en los aspectos correctos del sistema y previene que el dise se desviar hacia elementos no críticos.

Estilos Arquitectónicos

Una vez que los problemas han sido identificados y priorizados, pueden ser utilizados para identificar y seleccionar apropiadamente los estilos arquitectónicos, que son la clave en la reducción del costo y previene que el sistema se desvie de su diseño original. Reutilizar soluciones efectivas es una de las prácticas fundamentales de éxito en la práctica de la ingeniería de software, y lo mismo pasa en el contexto de la arquitectura de software. La creación de componentes y conectores reutilizables es una forma usual de la reutilización arquitectónica. Un tipo más comprensible a nivel arquitectura de reutilización se consigue con la adopción de estilos arquitectónicos [17]. Un estilo arquitectónico es llamado "paquete" de decisiones arquitectónicas expresadas para que puedan ser aplicadas a una gran variedad de productos con el fin de mejorar o ayudar a asegurar ciertas cualidades deseadas en los mismos.

Probablemente el estilo arquitectónico más conocido es el pipe-and-filter (entuba yfiltra). En este estilo arquitectónico, los componentes (llamados filtros) interactúan con el mundo exterior sólo a través de una interface de entrada y salida. Los datos son transferidos a través de esta interface en forma de secuencias de caracteres, aunque el formato específico de esos conjuntos depende de la aplicación. Estos conjuntos están conectados a los componentes por medio de los conectores (llamados tuberías). Este estilo es lineal y no permite ramificaciones. Las reglas de pipe-and-filter han sido específicamente escogidas para mejorar ciertas cualidades del software. Por ejemplo, estandarizando los componentes de la interface, se mejora la interoperabilidad. Las aplicaciones pipe-and-filter también pueden tomar ventaja de multiprocesadores y trabajar más eficientemente manteniendo los componentes independientes y permitiéndoles trabajar en datos tan pronto como estén disponibles. Cuando uno teclea

ls -l | grep "foo" | more

en una línea de comandos de UNIX, uno está definiendo y ejecutando una arquitectura pipe-and-filter compuesta de tres componentes (ls, grep, and more) y dos conectores (tuberías). Debe notarse que mientras las reglas de pipe-and-filter rules puedan mejorar ciertas cualidades del software, el estilo en sí no puede garantizar que cualquier componente hará algo útil.

Mientras el estilo arquitectónico pipe-and-filter es trivialmente simple, más estilos complejos proveen más valor a dominios particulares. El estilo arquitectónico de Transferencia de Estados Representativos (Representational State Transfer) [10] es el fundador de la Web moderna y del protocolo HTTP/1.1 que encierra principios específicos compositores destinados a optimizar interacciones de red. Los requerimientos de interacciones cliente-servidor sin estados y depósitos de cliente, por ejemplo, promueve cualidades de escalabilidad del sistema e incrementa la funcionalidad percibida por el usuario. El estilo de arquitectura C2 [19] combina aspectos de estilos mucho más simples -como capas e invocación implícita- para crear una amalgama la cual se ajusta para el desarrollo altamente dinámico de aplicaciones heterogéneas.

Con la influencia de los estilos, los ingenieros claramente pueden obtener "gratuitamente" conocimiento, patrones, y herramientas de ingeniería que implican una reducción significativa de costos. Si la arquitectura se desarrolla basada en los intereses de los interesados, las características deseadas de la aplicación emergerán con la selección del estilo que incluya cualidades que se acerquen a los problemas a solucionar más importantes identificados por el sistema de los mismos.

Modelado y Visualización

La selección de la notación de modelo y las técnicas de visualización también deben de ser en función del problema. Desde el lenguaje natural pasando por UML hasta los ADL, los arquitectos tienen una gran variedad de notaciones y visualizaciones para escoger. La selección también debe ser en función de los problemas a solucionar previamente identificados. Los buenos arquitectos deben de estar bien informados de las armas disponibles en notación de modelado, y hacer uso de ellas libremente -un error común en la arquitectura de modelos es limitar el modelado a una simple notación por conveniencia, por adopción, o por minimizar esfuerzo.

Modelar o capturar las decisiones de diseño arquitectónico está estrechamente ligado con la visualización arquitectónica - la foma en que las decisiones de diseño son representadas y manipuladas por los interesados. De hecho, todas las notaciones de modelado tienen por lo menos una visualización canónica que es propia de la notación. Para xADL 2.0, la visualización canónica es textual porque la arquitectura es representada en XML. Sin embargo, muchas visualizaciones pueden ser aplicadas a diferentes modelos para desplegar la misma información en diferentes formas. Cada visualización tiene diferentes ventajas y desventajas que un arquitecto debe considerar.

<component type="Component" id="xArchTrans">


<description>xArchADT Transaction Manager</description>

<interface id="xArchTrans.IFACE_TOP">


<description>xArchADT Transaction Manager Top
Interface</description>


<direction>inout</direction>

<type type="simple" href="#C2TopType"/>

<signature type="simple" href="#xArchTrans_type_topSig"/>


</interface>


<interface id="xArchTrans.IFACE_BOTTOM">



<description>xArchADT Transaction Manager Bottom
Interface</description>



<direction>inout</direction>


<type type="simple" href="#C2BottomType"/>


<signature type="simple"
href="#xArchTrans_type_bottomSig"/>


</interface>


<type type="simple" href="#xArchTrans_type"/>


</component>


<link id="xarchtrans_to_xarchadtbus">


<description>xArchTrans to xArchADT Bus
Connector</description>


<point>


<anchorOnInterface href="#xArchTrans.IFACE_BOTTOM"/>


</point>


<point>


<anchorOnInterface href="#xArchADTBus.IFACE_TOP"/>



</point>


</link>

 
     

Figura 2: Diferentes visualizaciones arquitectónicas: la parte de arriba muestra una pequeña parte de la arquitectura de ArchStudio gráficamente, mientras la parte de abajo muestra la definición textual de un componente y liga especificado en xADL 2.0.

La Figura 2 muestra dos visualizaciones que refieren al mismo modelo en xADL 2.0: un modelo de una parte de una arquitectura del ambiente ArchStudio[12]. Una visualización es gráfica e ilustra la estructura de un sistema en una forma convencional de "cajas y flechas". Es inmediatamente obvio a un humano cómo es la arquitectura del sistema y como se organizan los componentes y conectores. Aunque omite unos detalles: la descripción de diferentes interfaces y ligas, por ejemplo. La otra visualización consiste en un texto en niveles, un conjunto menos esmerado de xADL 2.0. Esta visualización no esconde nada, pero es mucho más complejo para un humano entender todo lo que tenga que ver con la configuración de la arquitectura a través de una especificación en texto. Justo como los arquitectos deberían de considerar usar diferentes notaciones para capturar las decisiones arquitectónicas, también deberían usar diferentes visualizaciones para representar esas decisiones.

Análisis Arquitectónico

Al análisis arquitectónico le interesa contestar preguntas que no puedan ser respondidas con el simple conocimiento de la arquitectura de un sistema. Por ejemplo, "¿El sistema será confiable?". Existen muchos métodos de análisis arquitectónico que pueden ser aplicados en la arquitectura cubriendo los que se hacen de forma manual hasta los que son hechos totalmente automáticos. Por ejemplo, un método de análisis arquitectónico es una inspección en la que los interesados se reúnen y generalmente, ayudados por una lista de tareas u otra agenda, revisan la arquitectura usando diferentes visualizaciones para ver el problema. En este sentido, el análisis puede ser más sobre el proceso que sobre las notaciones y las herramientas.

El objetivo final del análisis arquitectónico es, obviamente, el análisis totalmente automático: la arquitectura es definida, y una herramienta determina si la arquitectura alcanza cierta calidad o tiene cierta propiedad. Esto será posible en el grado de que dependa directamente de cómo la arquitectura será especificada. Muchas notaciones, especialmente las que se basan en modelos formales matemáticos, como el Wright, son desarrollados especialmente para facilitar ciertos análisis automatizados. Usualmente, estas notaciones están acompañadas de herramientas que apoyan este análisis. Se han dedicado otros esfuerzos en desarrollar nuevos métodos de análisis para notaciones frecuentemente usadas, particularmente UML; muchos de estos están recopilados en [8]. Por ejemplo, Engels, et al. [9] ha desarrollado una aproximación que determina si la especificación del comportamiento de una tabla de estados para las clases base y derivadas son compatibles.

La habilidad de un análisis en particular para revisar la arquitectura de software contra diferentes problemas a resolver deben ser tomados en cuenta cuando se escoge la notación de modelado y profundidad de detalle. Por ejemplo, si la confianza y concurrencia son los problemas a resolver más importantes, una notación que pueda revisar automáticamente si hay bloqueo mutuo debe de ser seleccionado.

Implementación

Un diseño arquitectónico bueno, y bien analizado es inútil hasta que hay un mapeo entre ésta arquitectura y su implementación. Entre menos completo o automatizado esté dicho mapeo, hay más posibilidad de una desviación arquitectónica: el fenómeno en el que la implementación de un sistema gradualmente diverge de su diseño previsto.

Hay una variedad de sistemas disponibles que conecta explícitamente las arquitecturas de software con las implementaciones. El ambiente de ArchStudio y el lenguaje xADL 2.0 proveen marcos para ligar elementos arquitectónicos con sus implementaciones a través de marcos arquitectónicos. Los marcos están compuestos por librerías de software que conectan el espacio entre conceptos arquitectónicos -como componentes, conectores y ligas- y los conceptos de lenguajes de programación como objetos y llamadas a función. Algunos marcos, como los que tiene ArchStudio, soportan la capacidad de reflejar automáticamente los cambios arquitectónicos a su correspondiente implementación en tiempo de ejecución. Otros esfuerzos de investigación están más enfocados en los artefactos del código fuente. Por ejemplo, ArchJava [1] embebe información arquitectónica en el código Java para proveer ligas entre los artefactos arquitectónicos y de implementación.

Con los métodos de análisis, la existencia de técnicas y herramientas de mapeo de implementación pueden y deben afectar la profundidad en la decisión de la notación y modelado del arquitecto. Mientras unas tecnologías de mapeo son aplicables a todo tipo de artefactos de implementación, otras son limitadas a determinados lenguajes de programación, sistemas operativos o middleware. Si un proyecto tiene necesidades especiales en términos de ambientes en que se espera correr, entonces la selección de notaciones compatibles con la tecnología de implementación es necesaria. Las técnicas y herramientas que permiten a la ingeniería un "viaje redondo", que propagan automáticamente cambios arquitectónicos en la implementación, son los preferibles.

Evolución y Mantenimiento

Las actividades de evolución y mantenimiento están principalmente ligadas con el interés de operación del software después de que éste es puesto en funcionamiento. El objetivo de estas actividades es asegurar que el producto de software puesto en funcionamiento continúa operando de forma satisfactoria, adaptándose a las nuevas situaciones y necesidades. En la práctica real, las actividades de evolución y mantenimiento son los más costosos durante el desarrollo del software [16].

La arquitectura provee la alternativa de usar modelos arquitectónicos como base para las operaciones de mantenimiento. La actualización de componentes de software para usar una nueva librería disponible, por ejemplo, puede hacerse cambiando sus conexiones arquitectónicas para que esté ligado a la nueva librería. Enfocarse en este nivel de abstracción evita a los desarrolladores tener que modificar componentes de bajo nivel en el código fuente, que es más difícil de entender y modificar.

Figura 3: Una ilustración la administración de procesos de evolución y adaptación. Un explícito modelo arquitectónico es la llave para la unificación de estos procesos y la influencia de la arquitectura para la evolución dinámica y adaptación en tiempo de ejecución del sistema.

Los procesos generales para usar la arquitectura de software para la evolución y el mantenimiento, mostrado en la mitad inferior de la Figura 3, empieza con la especificación explícita de la arquitectura de un sistema de software usando el lenguaje ADL que pueda leer una máquina. Una vez que las conexiones entre la arquitectura y su implementación están hechas, el modelo arquitectónico del sistema se convierte en una representación confiable del estado actual. Este modelo arquitectónico puede ser usado como la base de evolución del sistema. Aunque cambios muy finos al comportamiento de un componente deben ser hechos a nivel de código, los cambios a alto nivel pueden ser expresados como cambios en el modelo arquitectónico. Por ejemplo, añadiendo la funcionalidad de corrección de ortografía distribuida en un sistema de procesador de palabras, puede ser efectivo cambiando un conector arquitectónico para usar facilidades de corrección ortográficas remotas que usar una local. Los cambios arquitectónicos son entonces detectados y decretados en el sistema en ejecución a través de un administrador de evolución arquitectónica, que asegura que los cambios en la arquitectura sean reflejados en la implementación en ejecución.

Este acercamiento, adoptado por una variedad de investigadores [5, 7], tiene ciertos beneficios en técnicas de evolución basadas en código fuente: evita que sistemas implementados se desvíen de sus arquitecturas previstas conforme evolucionan, fuerza a desarrolladores a mantener y actualizar la arquitectura que a dejar y desentenderse pues fue un documento usado durante el diseño, y forma parte de la base de una evolución de un software pensado en dos formas, fuera de ejecución y mientras está en ejecución.

Adaptación

Mientras a la evolución del software le interesa modificar sistemas en tiempo de ejecución, la adaptación del software se involucra en decidir qué y cuándo las modificaciones son apropiadas. Durante la adaptación del software, los sistemas evolucionan dinámicamente para enfrentarse a nuevas metas funcionales o no funcionales. La meta evidente es crear sistemas que se adapten por sí solos, esto es, sistemas que puedan modificarse a sí mismos. La arquitectura del software puede proveer formalismos fundamentales y plantear una plataforma que soporte la auto-adaptación de comportamiento en modelos arquitectónicos. Esto simplifica los tipos y números de artefactos que deben de ser considerados durante la adaptación, y de ahí que tiene el potencial y gran sencillez para desarrollar y administrar los sistemas auto-adaptables.

La visión que evocamos para una arquitectura hecha para la auto-adaptación -inicialmente señalada en [ 14] -- se centra en un modelo arquitectónico que puede ser usado para la evolución del software dinámico. Además, la lógica para guiar el comportamiento de adaptación también está basada en la descripción arquitectónica del sistema. La primera mitad de la Figura 3 presenta gráficamente esta idea. La información de un sistema de software se consigue examinando su modelo arquitectónico y su correspondiente implementación. Un Administrador de Adaptación Arquitectónica (AAM por sus siglas en inglés) es el responsable de pensar y decidir qué cambios se deben de hacer a la arquitectura. Los cambios necesarios seleccionados son entonces planteados como cambios al modelo arquitectónico. Entonces, estos cambios se reflejan en tiempo de ejecución a través del proceso administrador de evolución discutido en la sección anterior. El proceso es el mismo independientemente si el sistema es auto-adaptable o no. En un sistema guiado por el humano, el AAM actúa como punto de coordinación donde las adaptaciones manuales son inyectadas al sistema en lugar de programar un proceso de toma decisión automático.

Esta idea necesita la adopción de una notación arquitectónicas que soporte (o pueda ser extendida para soportar) las especificaciones de qué y cuándo las adaptaciones son necesarias. Una variedad de técnicas han sido desarrolladas para soportar las especificaciones de propiedades de adaptación a nivel de arquitectura: contratos para la interacción de sistemas orientados a objetos [3] y políticas de sistemas expertos basados en reglas [11] son dos ejemplos. A pesar de la idea de representación adoptada, la clave oculta es el uso de modelos arquitectónicos dinámicos que actúan como los fundamentos de la razón de comportamientos de auto-adaptación. Tanto como la evolución de sistemas es manejada mejor a nivel arquitectura, dicho nivel es también el nivel más apropiado para la abstracción cuando se trata de requerimientos funcionales o no funcionales que los sistemas adaptables deben tener.

Direcciones futuras

Algunas de las direcciones para las próximas investigaciones de arquitectura de software son evidentes: el primer problema es cómo la arquitectura será usada en la etapa de diseño, un segundo problemas sería el tipo de analisis de calidad que deben adquirirse para una fuerte adopción de arquitectura de software, y el tercer problema es dónde aplicar la arquitectura en términos del dominio de la aplicación.

Diseño de apoyo a la arquitectura

Una dirección de la investigación aborda la averiguación de las mejorías que la arquitectura de software puede mejorar para soportar los procesos de diseño. Un aspecto de esta mejora es mayor soporte arquitectónico para la coordinación de las actividades diarias y en colaboración de la ingeniería de software a gran escala. Otro aspecto de esta investigación involucrará nuevas formas de visualizar y manipular los modelos arquitectónicos de software que van más allá de la representación en dos dimensiones de los diagramas de "cajas y flechas". Dos posibles mejoras para la visualización arquitectónicas es incluir múltiples capas en una sola descripción arquitectónica, y la manipulación de diseños a través de diferentes significados como las interfaces en tercera dimensión o de realidad virtual.

Finalmente, la comunidad de investigación necesitará precisar diferentes criterios para evaluar diseños. Fundamentalmente los principios de la ingeniería de software dictan un conjunto de criterios técnicamente orientados que son actualmente usados para la evaluación de diseños, como evitar los cuellos de botella en la comunicación. Aún hay potencial, sin embargo, para determinar un sentido de estética arquitectónica: criterios humanos intuitivos que establecen un sentido para decir si una solución arquitectónica es adecuada o está progresando de forma adecuada. Esta estética puede facilitar el discurso y comunicación entre los arquitectos, similar, al fin y al cabo, al criterio usado para determinar el valor artístico del arte a través del uso del color, forma, simetría, o composiciones específicas.

Análisis de Calidad Arquitectónica

Para mayor satisfacción de las habilidades de la arquitectura para asegurar el éxito y calidad del software, la comunidad de investigación también debe de proveer mejor soporte para modelar y analizar cualidades del software al nivel del diseño arquitectónico. Por ejemplo, Banerjee, et al. [4] ha empezado una investigación comprometedora para aplicar la arquitectura a aspectos medibles de la calidad. Esta aproximación redefine las métricas en diferentes aspectos, identifica estrategias generales para mejorar las métricas de calidad, y finalmente identifica cómo cada estrategia puede ser implementada a nivel arquitectónico. Investigaciones como esta deben de ser extendidas para explorar y modelar otras cualidades del software a nivel arquitectura, como seguridad, amigabilidad, y el comportamiento esperado del sistema.

Arquitectura Aplicada

Finalmente, creemos que es extremadamente valioso extender la aplicación de la arquitectura del software a diferentes campos en estrecha colaboración con expertos de los diferentes campos. Recientes investigaciones en arquitecturas de software de campos especializados revelaron que un valor agregado puede surgir de explorar puntos comunes que ocurren en los campos especializados. Los dos, tanto teoría como práctica de la arquitectura de software, han mejorado sustancialmente gracias a los esfuerzos de estas investigaciones, creemos que valdría la pena más esfuerzos directos al extraer estilos y patrones de campos como la exploración del espacio autónomo y control aéreo.

Sin embargo, esto no es un simple problema de transición tecnológica: la comunidad de investigación no puede usar únicamente el campo del mundo real como materia de prueba. Examinar realmente la efectividad de una práctica de arquitectura requerirá de una buena relación y compromisos en ambos sentidos de los investigadores y de los expertos en el campo. Los practicantes actuales deben de tener disposición de extender la adopción de sus técnicas arquitectónicas y apoyar su desarrollo incondicionalmente, mientras los investigadores deben de tener la voluntad de estudiar los resultados de sus esfuerzos en circunstancias concretas y prepararse para conocer los límites de la disciplina.

Conclusiones

La ingeniería de software es una actividad compleja que involucra una gran variedad de artefactos de desarrollo con interdependencias complejas en diferentes niveles de abstracción. Este artículo apoya la posición de que la disciplina de la arquitectura de software debe de jugar un rol central en proveer una vista coherente de una arquitectura de un sistema de software y su acompañamiento de los procesos de desarrollo. Los modelos arquitectónicos representan un conjunto de decisiones de diseño involucrados en la ingeniería de software y por ende deben servir como primer punto de integración entre las actividades de desarrollo y los problemas a resolver.

Las buenas prácticas de la arquitectura de software aplicadas durante el ciclo de vida, tienen el potencial de incrementar la facilidad para entender un sistema de software y de desarrollar procesos para crearlo, asegurando que cualidades particulares y revelantes sean alcanzadas, y que se reduzca el costo. Como una herramienta para mejorar la práctica de diseño, la arquitectura ofrece una forma efectiva de modelar sistemas de software mientras ayuda en el razonamiento y análisis del comportamiento antes de que el desarrollo sea terminado. Como las disciplinas y artefactos relativas al diseño, la arquitectura también tiene el potencial de garantizar beneficios importantes al proceso de desarrollo de todo el software incluyendo la evolución en tiempo de ejecución y adaptación.

En este artículo, hemos identificado algunas aproximaciones, herramientas y técnicas específicas que demuestran cómo la arquitectura pude ser usada para mejorar un amplio espectro de actividades de desarrollo. Claro, esto no significa que la arquitectura puede o debe reemplazar prácticas actuales pensadas para ser efectivas; significa, sin embargo, que la arquitectura de software debe ser usada como el artefacto núcleo que provee una visión coherente y conecta a todos las personas, las actividades, y artefactos involucrados en la ingeniería de software.

Agradecimientos

Los autores quisieran agradecer a Anita Sarma y André van der Hoek por su ayuda en formular y clarificar algunas de las ideas presentadas en este artículo. Este trabajo fue apoyado en parte por NSF Grant CCF-0420066 y por The Boeing Company.

Referencias

1

Aldrich, J., Chambers, C., and Notkin, D. ArchJava: Connecting Software Architecture to Implementation. In Proceedings of the 24th International Conference on Software Engineering (ICSE), pp.187-197, May 19-25, 2002.

2

Allen, R., and Garlan, D. A Formal Basis for Architectural Connection. In ACM Transactions on Software Engineering and Methodology. 6(3), pp.213-249, July, 1997.

3

Andrade, L. and Fiadeiro, J.L. An architectural approach to auto-adaptive systems. In Proceedings of the 22nd International Conference on Distributed Computing Systems Workshops, pp.439-444, 2002.

4

Banerjee, S., Mattmann, C., Medvidovic, N., and Golubchik, L. Leveraging Architectural Models to Inject Trust into Software Systems. In Proceedings of the ICSE 2005 Workshop on Software Engineering for Secure Systems--Building Trustworthy Applications (SESS05), St. Louis, Missouri, May, 2005.

5

Cheng, S., Huang, A., Garlan, D., Schmerl, B., and Steenkiste, P. Rainbow: Architecture-Based Self Adaptation with Reusable Infrastructure. IEEE Computer, 37(10), October, 2004.

6

CORPORATE Carnegie Mellon University, Paulk, M.C., Webber, C.V., Curtis, B., and Chrissis, M. The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley Longman Publishing Co., Inc., 1995.

7

Dashofy, E.M., Van der Hoek, A., and Taylor, R.N. A Comprehensive Approach for the Development of Modular Software Architecture Description Languages. In ACM Transactions on Software Engineering and Methodology (TOSEM). 14(2), pp.199-245, April, 2005.

8

Elaasar, M. and Briand, L. An Overview of UML Consistency Management. Carleton University, Technical Report, pp.2-51, August 24, 2004.

9

Engels, G., Heckel, R., and Kuster, J. Rule-Based Specification of Behavioral Consistency Based on the UML Meta-model. In Proceedings of the 4th International Conference on The Unified Modeling Language, Modeling Languages, Concepts, and Tools (UML'2001). pp.272-286, Toronto, Ontario, Canada, 2001.

10

Fielding, R.T., and Taylor, R.N. Principled Design of the Modern Web Architecture. In ACM Transactions on Internet Technology (TOIT). 2(2), pp. 115-150, May, 2002.

11

Georgas, J.C. and Taylor, R.N. Towards a Knowledge-Based Approach to Architectural Adaptation Management. In Proceedings of ACM SIGSOFT Workshop on Self-Managed Systems (WOSS 2004), October, 2004.

12

Institute for Software Research. ArchStudio 3 Homepage. <http://www.isr.uci.edu/projects/archstudio/>, 2005 (19 January 2006).

13

Maier, M. and Rechtin, E. The Art of Systems Architecting. 2nd ed. 344 pgs., CRC Press: Boca Raton, FL, 2000.

14

Oreizy, P., Gorlick, M., Taylor, R.N., Heimbigner, D., Johnson, G., Medvidovic, N., Quilici, A., Rosenblum, D., and Wolf, A. An Architecture-Based Approach to Self-Adaptive Software. In IEEE Intelligent Systems, 14(3), pp.54-62, May/June, 1999.

15

Perry, D.E., and Wolf, A.L. Foundations for the Study of Software Architecture. In ACM SIGSOFT Software Engineering Notes. 17(4), pp.40-52, October, 1992.

16

Schach, S.R. Classical and Object-Oriented Software Engineering. McGraw-Hill Professional, 1995.

17

Shaw, M., and Clements, P. A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems. In Proceedings of the Computer Software and Applications Conference. pp.6-13, August, 1997.

18

Standish Group, The. The CHAOS Report (1994). http://www.standishgroup.com/sample_research/chaos_1994_1.php, 1994 (19 January 2006).

19

Taylor, R.N., Medvidovic, N., Anderson, K.M., Whitehead, E.J., Robbins, J.E., Nies, K.A., Oreizy, P., and Dubrow, D.L. A Component- and Message-Based Architectural Style for GUI Software. IEEE Transactions on Software Engineering. 22(6), p. 390-406, June, 1996.

Biografías

John C. Georgas (jgeorgas@ics.uci.edu) es un candidato a doctor en la escuela Donald Bren de Ciencias de la Información y Computacionales del Departamento de Informática de la Universidad de California, Irvine, y es asesorado por el Profesor Richard N. Taylor. Su principal interés en la investigación reside en el área de la ingeniería de software basada en la arquitectura, sistemas dinámicos auto-adaptables, modelado de sistemas, y procesos de diseño.

Eric M. Dashofy (edashofy@ics.uci.edu) es un candidato a doctor en el Departamento de Informática de la Universidad de California, Irvine, y es asesorado por el Profesor Richard N. Taylor. Sus intereses de investigación están en el área de la arquitectura de software y modelado. Él es co-desarrollador de la descripción de la arquitectura del lenguaje xADL 2.0 y el principal sostén del ambiente de desarrollo ArchStudio 3 - software basado en arquitectura.

Richard N. Taylor (taylor@ics.uci.edu) es Profesor de Ciencias de la Información y Computacionales en la Universidad de California en Irvine y es el Director del Instituto de Investigación del Software. Recibió el grado de Doctor en Ciencias Computacionales de la Universidad de Colorado en Boulder en 1980. Sus intereses en la investigación están centrados en arquitecturas de software, especialmente los basados en eventos y sistemas peer-to-peer y de cómo cruzan las barreras organizacionales.

Traductores

Nadia P. García Castellanos (is67081@iteso.mx) es una estudiante de Ingeniería de Sistemas Computacionales en el Instituto Tecnológico y de Estudios Superiores de Occidente en Guadalajara; Vicepresidente del Capítulo Estudiantil ACM-ITESO 2006-2007. Sus intereses a desarrollar después de graduarse son las pruebas de software, y realizar una maestría.

Carlos A. Fernández Guillot (carlosf@iteso.mx) es Profesor en el Instituto Tecnológico y de Estudios Superiores de Occidente en Guadalajara donde coordina las materias de programación e imparte la materia de Ingeniería de Software. Maestro por la Universidad de Guadalajara, Ingeniero por el Instituto Superior Politecnico "José Antonio Echeverria" de La Habana, Cuba.