Conceptos básicos sobre Arquitectura de SoftwareGrupo de Trabajo Académico

GNU/Linux - GLUDUniversidad Distrital F.J.CCarrera 8 N. 40-78 Piso 2

Bogotá – Colombiaglud@udistrital.edu.co

ABSTRACT1

In this paper, the author describes the basic concepts about software architectures.

Keywordssoftware, architecture, design.

1. INTRODUCCIÓN

2. Arquitectura de SoftwareEn la actualidad no se ha llegado a un acuerdo en cuanto a la definición formal de lo que es arquitectura de software2. De acuerdo con la IEEE, una arquitectura de software es: la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente; y los principios que orientan su diseño y evolución[1]. En esta definición se mezclan conceptos multivalentes que es necesario aclarar. Para la presente propuesta se entiende por:

• organización fundamental: la estructura esencial de un sistema en términos de que contiene los elementos importantes, necesarios y suficientes para brindar una descripción clara del sistema, guiar su desarrollo y soportar el conjunto de requerimientos capturados.

• Ambiente: Contexto en el cual se desenvuelve el sistema en todo su ciclo de vida. Está compuesto por el ambiente de desarrollo, operacional, de despliegue, de pruebas, producción y otros sistemas con los que se interaccione.

1 Este artículo pertenece a la serie GLUD – Académico, el cual tiene como objetivo la elaboración de materiales académicos de consulta para estudiantes que participan en los proyectos del Grupo Linux de la Universidad Distrital Francisco José de Caldas. Se concede permiso para copiar, distribuir o modificar este documento bajo los términos de la Licencia de Documentación Libre de GNU, Versión 1.3 o cualquier otra versión posterior publicada por la Free Software Foundation; sin Secciones Invariantes.

2 Aunque existe un conjunto de definiciones parcialmente aceptadas, no se puede llegar a una definición única del concepto. Esto convierte a la arquitectura de software en un área imprecisa de investigación y todos los involucrados deben, como paso previo, llegar a un acuerdo en la concepción de lo que significa el término. Tal es la pluralidad de opiniones que el Instituto de Ingeniería de Software de la Carnegie Mellon, uno de los más influyentes a nivel mundial, en la página de definición del término da no solo una, sino un conjunto de definiciones y además ofrece un formulario en el cual los visitantes pueden colocar su propia definición.

Para [2], la arquitectura de software de un programa, o de un sistema de cómputo, es la estructura, o estructuras, del sistema; la cual comprende elementos de software, las propiedades visibles externamente de dichos elementos y las relaciones que existen entre ellos.

En [3], se presenta a la arquitectura de software como un conjunto de decisiones importantes acerca de: (a) la organización de un sistema software, (b) los elementos estructurales (con sus interfaces) que componen el sistema, (c) el comportamiento del sistema especificado por las colaboraciones existentes entre los elementos estructurales, (d) la agrupación (o separación) de elementos estructurales y del comportamiento en subsistemas progresivamente más grandes (o más pequeños) y (e) el estilo arquitectónico que guía la organización de tales elementos, sus interfaces, sus colaboraciones y su composición.

El estilo de la arquitectura define la forma del sistema y da lugar a conjuntos de configuraciones concretas que son más o menos efectivas dentro del contexto de la solución planteada. Ejemplos de estilo puede ser el de Frontera – Control -Entidad, la organización por capas, la orientación a objetos, la organización por componentes, la organización modular, la arquitectura de máquina virtual, basados en eventos, orientado a servicios, basada en recursos, etc. La elección de un (o varios estilos ya que muchos de ellos son complementarios entre sí) estilo depende de los requerimientos funcionales y los requisitos no funcionales del sistema.

Es claro que una arquitectura de software es mucho más que la mera disposición de componentes y engloba aspectos conceptuales que tienen que ver con decisiones de alto nivel que se toman y que tienen impacto en la forma en que organiza el sistema. En [4], se hace especial énfasis en la descomposición de la arquitectura en partes especializadas que permiten un mejor control y una mayor abstracción. La descomposición divide a un sistema complejo en subsistemas, paquetes y componentes especializados que fomentan la facilidad de crecimiento, la arquitectura de software debe mostrar la forma en que tales piezas de descomposición interaccionan entre si y como se utilizan los servicios que prestan cada una de ellas sin especificar los detalles de como cada elemento implementa el servicio o su comportamiento.

3. Vistas de la ArquitecturaUna arquitectura compleja debe ser modelada a partir de diferentes perspectivas que permitan enfocar los elementos claves con un alto nivel de abstracción. En este sentido [5] presenta un modelo para la descripción de la arquitectura de sistemas el cual está compuesto por cinco vistas básicas: escenarios (ahora conocida como casos de uso), lógica, de procesos, física y de despliegue.

1

• Vista de Casos de Uso (escenarios): Necesidades de los interesados. Requerimientos funcionales del sistema complementados con la definición de requerimientos no funcionales que pueden afectar la arquitectura.

• Vista lógica: Representa la estructura funcional del sistema (clasificación estructural y comportamiento dinámico). Describe como esta organizado el sistema con base en unidades funcionales y las relaciones existentes entre ellas. En el paradigma orientado a objetos las unidades pueden ser clases, interfaces, componentes y paquetes. Entre las relaciones se encuentran las dependencias, las realizaciones de interfaz, las relaciones todo-parte, asociaciones, generalizaciones, etc. Para modelar esta vista, usando el lenguaje UML, se emplean los diagramas de clases, de colaboración y de secuencia

• Vista de procesos: Entendidos desde el punto de vista de desempeño tiene que ver con la forma en que los diferentes procesos (de procesamiento) se comunican entre sí parta soportar la funcionalidad. Modela aspecto tales como concurrencia y distribución: un diagrama adecuado, en UML, para capturar la vista de procesos es el de actividades.

• Vista física: describe la relación entre el software y el hardware reflejando el aspecto distribuido de las soluciones. Representan como se despliegan los artefactos de software en tiempo de ejecución. Los diagramas de despliegue son adecuados para modelar esta vista.

• Vista de desarrollo: organización estática del software en el entorno de desarrollo (librerías, componentes). Para su modelado,en UML, se utilizan los diagramas de componentes.

Las diferentes vistas están relacionadas y no debe pretenderse que sean modelos únicos e independientes del sistema. La arquitectura se describe utilizando gran cantidad de modelos y cada uno de ellos es una representación incompleta del sistema. Así, la arquitectura de software se concreta cuando se agrupan todos los modelos y vistas que describen el sistema en términos de los elementos que lo constituyen, sus características, comportamiento y las relaciones que existen entre ellos.

En el presente proyecto se considera una sexta vista denominada Vista de Datos que aunque está incluida dentro de la vista lógica, es deseable gestionarla aparte teniendo en cuenta que la persistencia es un aspecto importante dentro de la arquitectura a proponer.

3.1.1 Elaboración de la Arquitectura

La arquitectura siempre debe tener en cuenta el modelo de requerimientos y los requisitos no funcionales determinados para la solución. En el proceso de elaboración de la arquitectura se recomienda realizar las tareas propuestas en el OpenUP [6]:

• Identificar los objetivos de la arquitectura respondiendo a preguntas como: ¿Cual es la vida útil esperada para

el sistema?, ¿el sistema debe responder a los cambios tecnológicos que ocurran? ¿cual es la tasa esperada de cambio, mantenimiento o adaptación?, etc.

• Identificar los requerimientos significativos que tienen impacto en la arquitectura.

• Identificar los conceptos y abstracciones claves del sistema y las relaciones que existen entre ellos (modelo conceptual del sistema).

• Identificar oportunidades para la re-utilización de partes de arquitecturas conocidas. Haciendo énfasis en estilos arquitectónicos de reconocida validez.

• Definir un enfoque para la descomposición del sistema tanto en la parte física como en la lógica.

• Definir un enfoque para el despliegue del sistema sobre los nodos de la plataforma de Hardware.

• Identificar los mecanismos aplicables a la arquitectura (soluciones comunes a problemas comunes).

• Verificar la consistencia de la arquitectura involucrando intensivamente a la comunidad de práctica para evaluar si la arquitectura es consistente con los requerimientos, está descrita de forma clara y se entiende (los interesados comprenden que es lo que representa la arquitectura).

Los modelos de las diferentes vistas se deben publicar en formato texto o a través de diagramas utilizando el lenguaje UML, para que la comunidad implicada pueda proponer cambios y contribuir a su depuración.

A medida que se refinan los requerimientos y la arquitectura se van construyendo, adaptando y probando las piezas de software que sirven para evaluar la efectividad de la solución propuesta. Se espera involucrar a estudiantes de pregrado y postgrado en el desarrollo de bloques específicos regulados por un entorno cuyo eje es el modelo de requerimientos, los requisitos no funcionales, la gestión del riesgo y la arquitectura. Con esta propuesta se puede des-estructurar el sistema en partes cuasi-independientes que puedan ser asignados a diferentes equipos siendo los avances integrados en tiempos específicos con base en un sistema orquestado de manejo de versiones.

4. REFERENCIAS[1] IEEE, ISO/IEC 42010/IEEE 1471: Architectural Description, 2000

[2] Bass,L., Clements, P. y Kazman, R., Software Architecture in Practice, 2003

[3] Kruchten,P., The Rational Unified Process, 1998

[4] Rumbaugh,J., Jacobson, I. y Booch, G., The Unified Modeling Language Reference Manual, 2005

[5] Kruchten,P., Architectural Blueprints—The “4+1” View Model of Software Architecture, 1995

[6] Fundación Eclipse., OpenUP, 2007.

2