La arquitectura de software es un concepto fácil de entender y que la mayoría de los ingenieros aprecian
intuitivamente, sobre todo los que tienen un poco de experiencia, pero resulta difícil definirlo con precisión. En
concreto, es difícil dibujar una línea precisa entre el diseño y la arquitectura, la arquitectura es un aspecto de
diseño que se concentra en algunas características específicas.
En An Introduction to Software Architecture, David Garlan y Mary Shaw sugieren que la arquitectura es un nivel
de diseño que se centra en aspectos: "Beyond the algorithms and data structures of the computation; designing and
specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization
and global control structure; protocols for communication, synchronization, and data access; assignment of
functionality to design elements; physical distribution; composition of design elements; scaling and performance; and
selection among design alternatives." (Más allá de los algoritmos y estructuras de datos de la computación; el diseño y
la especificación de la estructura general del sistema emergen como una clase nueva de problema. Los aspectos
estructurales incluyen la estructura global de control y la organización general; protocolos de comunicación,
sincronización y acceso de datos; asignación de funciones para diseñar elementos; distribución física, composición de
elementos de diseño; ajuste y rendimiento; y selección entre otras alternativas de diseño). [GAR93]
Pero la arquitectura es algo más que una estructura; el IEEE Working Group on Architecture la define como "the
highest-level concept of a system in its environment" (el concepto de más alto nivel de un sistema en su
entorno) [IEP1471]. También incluye el "ajuste" con la integridad del sistema, con las
restricciones económicas, con las preocupaciones estéticas y con el estilo. No se limita a un enfoque interior, si no
que tiene en cuenta el sistema en su totalidad dentro del entorno de usuario y el entorno de desarrollo, un enfoque
exterior.
En RUP, la arquitectura de un sistema de software (en un punto determinado) es la organización o la estructura de los
componentes importantes del sistema que interactúan mediante interfaces, con componentes compuestos de interfaces y
componentes cada vez más pequeños.
Para poder hablar y razonar sobre la arquitectura de software, antes debe definir una representación arquitectónica,
una manera de describir aspectos importantes de una arquitectura. En RUP, esta descripción se captura en el Documento de arquitectura de software.
Hemos decidido representar la arquitectura de software en varias vistas de la arquitectura. Cada vista de la
arquitectura trata un conjunto concreto de problemas, específico de interesados en el proceso de desarrollo: usuarios,
diseñadores, gestores, ingenieros de sistemas, mantenedores, etc.
Las vistas capturan las principales decisiones de diseño estructural y muestran cómo se descompone la estructura de
software en componentes y cómo se conectan los componentes mediante conectores para producir formas
útiles [PW92]. Estas elecciones de diseño deben estar unidas a los Requisitos, funcionales y suplementarios y otras restricciones. Aunque, a su vez,
añaden más restricciones a los requisitos y a las próximas decisiones de diseño en un nivel inferior.
La arquitectura se representa mediante un número diferente de vistas de la arquitectura, que, esencialmente, son
extractos que ilustran los elementos "significativos arquitectónicamente" de los modelos. En RUP, se empieza en un
conjunto típico de vistas, llamado el "modelo de vista 4+1" [KRU95]. Consta
de:
Las vistas de la arquitectura se muestran en el Documento de arquitectura de software. Puede visualizar vistas
adicionales para expresar diferentes preocupaciones especiales: vista de interfaz de usuario, vista de seguridad, vista
de datos, etc. En sistemas simples, puede omitir algunas de las vistas contenidas en el modelo de vista 4+1.
Aunque las vistas de arriba pueden representar el diseño completo de un sistema, la arquitectura trata únicamente
algunos aspectos específicos:
-
La estructura del modelo: los patrones organizativos, por ejemplo, la Creación de
capas.
-
Los elementos esenciales: guiones
de uso críticos, clases principales, mecanismos comunes, etc., en oposición a
todos los elementos presentes en el modelo.
-
Unos cuantos casos de ejemplo clave que muestran los flujos de control principales en el sistema.
-
Los servicios, para capturar aspectos de la línea de productos, modularidad y características opcionales.
Las vistas de la arquitectura son, esencialmente, abstracciones o simplificaciones de todo el diseño, en las que
las características importantes pasan a ser más visibles y se dejan de lado los detalles. Estas características son
importantes cuando se razona sobre:
-
La evolución del sistema, el paso al siguiente ciclo de desarrollo.
-
La reutilización de la arquitectura, o partes de ella, en el contexto de una línea de productos.
-
La evaluación de calidades suplementarias, como rendimiento, disponibilidad, portabilidad y seguridad.
-
La asignación de trabajo de desarrollo a equipos y subcontratistas.
-
Las decisiones sobre la inclusión de componentes asequibles.
-
La inserción en un sistema más amplio.
Los patrones de arquitectura son formatos preparados que resuelven problemas
arquitectónicos recurrentes. Una infraestructura de la arquitectura (middleware) es un conjunto de componentes
sobre los que puede construir una cierta clase de arquitectura. Muchas de las principales dificultades arquitectónicas
deberían resolverse en la infraestructura, normalmente destinada a un dominio específico: mandato y control, MIS,
sistema de control, etc.
Ejemplos de patrones de arquitectura
[BUS96] agrupa patrones de arquitectura en función de las características de los
sistemas en los que son más aplicables; una de las categorías trata temas de estructura más generales. La tabla muestra
las categorías que se presentan en [BUS96] y los
patrones que contienen.
Categoría
|
Patrón
|
Estructura
|
Capas
|
Conductos y filtros
|
Pizarra
|
Sistemas distribuidos
|
Intermediario
|
Sistemas interactivos
|
Modelo-Vista-Controlador
|
Presentación-Abstracción-Control
|
Sistemas adaptables
|
Reflejo
|
Microkernel
|
Dos de ellas se presentan aquí más detalladamente, para clarificar estas ideas; si desea obtener un tratamiento
completo, consulte [BUS96]. Los
patrones se presentan con el siguiente formato, muy utilizado:
-
Nombre del patrón
-
Contexto
-
Problema
-
Fuerza la descripción de diferentes aspectos del problema que se deberían tener en cuenta
-
Solución
-
Fundamentos
-
Contexto resultante
-
Ejemplos
Nombre del patrón
Capas
Contexto
Un sistema grande que requiere descomposición.
Problema
Un sistema que debe manejar asuntos en diferentes niveles de abstracción.
Por ejemplo: asuntos de control de hardware, asuntos de servicios comunes y asuntos específicos del dominio. No sería
nada deseable escribir componentes verticales que manejen asuntos en todos los niveles. Habría que manejar el mismo
asunto (posiblemente de manera incoherente) varias veces en componentes distintos.
Fuerzas
-
Las partes del sistema deberían ser sustituibles.
-
Los cambios de los componentes no deberían extenderse.
-
Las responsabilidades similares deberían agruparse juntas.
-
El tamaño de los componentes: puede que sea necesario descomponer los componentes complejos.
Solución
Estructure los sistemas en grupos de componentes que formen capas unos encima de otros. Haga que las capas superiores
utilicen únicamente los servicios de las capas de abajo (nunca los de las capas de arriba). Intente utilizar únicamente
los servicios de la capa inmediatamente inferior (no se salte capas, a no ser que las capas intermedias sólo sean de
paso por los componentes).
Ejemplos:
1. Capas genéricas
Una arquitectura de capas estricta indica que los elementos de diseño (clases, paquetes, subsistemas) sólo utilizan
los servicios de la capa inmediatamente inferior. Los servicios pueden incluir manejo de sucesos, manejo de
errores, acceso a bases de datos, etc. Contiene mecanismos más palpables, en oposición a las llamadas de nivel de
sistema operativo bruto documentadas en la capa inferior.
2. Capas del sistema empresarial
El diagrama anterior muestra otro ejemplo de creación de capas, donde hay capas específicas de la aplicación
vertical, capas horizontales y capas de infraestructura. Tenga en cuenta que el objetivo es tener "tubos de estufa"
empresariales muy cortos y promover la similitud entre las aplicaciones. Sino, puede tener a varias personas resolviendo el mismo problema,
potencialmente diferente.
Consulte el apartado Directriz: Creación
de capas para obtener más información sobre este patrón.
Nombre del patrón
Pizarra
Contexto
Un dominio en el que no hay ningún enfoque cerrado (algorítmico) conocido o viable para resolver un problema. Por
ejemplo, sistemas de vigilancia, reconocimiento de voz y sistemas AI.
Problema
Para solucionar un problema que no puede solucionar ninguno de los agentes individuales, deben cooperar varios agentes
de resolución de problemas (agentes de conocimiento). El resultado del trabajo de los agentes individuales debe ser
accesible para todos los demás agentes, de manera que puedan evaluar si pueden contribuir a encontrar una solución y
enviar el resultado de su trabajo.
Fuerzas
-
La secuencia en la que los agentes de conocimiento pueden contribuir a resolver el problema no es
determinante y puede variar en función de las estrategias de resolución de problemas.
-
La entrada de agentes diferentes (el resultado o soluciones parciales) puede tener diferentes
representaciones.
-
Los agentes no se conocen directamente, pero pueden evaluar las contribuciones enviadas por los demás.
Solución
Una serie de agentes de conocimiento tienen acceso a un almacén de datos compartidos llamado Pizarra. La Pizarra
proporciona una interfaz para inspeccionar y actualizar su contenido. El objeto / módulo de Control activa a los
agentes siguiendo una estrategia. Tras ser activado, un agente inspecciona la pizarra para ver si puede contribuir a
resolver el problema. Si el agente decide que puede contribuir, el objeto de control permite a los agentes poner la
solución parcial (o final) en la pizarra.
Ejemplo:
Este diagrama muestra la vista estructural o estática modelada con UML; formaría parte de una colaboración con
parámetros, que después se vincula a parámetros reales para crear instancias del patrón.
Una arquitectura de software, o simplemente una vista de la arquitectura, puede tener un atributo llamado estilo de
la arquitectura, que reduce el conjunto de formatos posibles para escoger e impone un cierto grado de uniformidad
con la arquitectura. El estilo puede definirse mediante un conjunto de patrones, o mediante la elección de componentes
o conectores específicos como bloques de compilación básicos. Para un sistema dado, el estilo se puede capturar como
parte de la descripción de la arquitectura en una guía de estilo de la arquitectura, que se proporciona a través
del producto de trabajo Directrices específicas del proyecto en RUP. El estilo desempeña un
papel principal en la comprensibilidad y la integridad de la arquitectura.
La representación gráfica de una vista de la arquitectura se llama anteproyecto de arquitectura. Para las
diferentes vistas que se describen arriba, los anteproyectos constan de los siguientes diagramas de lenguaje unificado
de modelado [UML01]:
-
Vista lógica. Diagramas de clase, máquinas de estado y diagramas de objeto
-
Vista de proceso. Diagramas de clase y diagramas de objeto (tareas contenedoras,
procesos y hebras)
-
Vista de implementación. Diagramas de componentes
-
Vista de despliegue. Diagramas de despliegue
-
Vista de guión de uso. Diagramas de guión de uso que representan guiones de uso,
actores y clases de diseño ordinarias; diagramas de secuencia que representan objetos de diseño y su colaboración
En RUP, la arquitectura es principalmente un resultado del análisis y el flujo de trabajo de diseño. A medida que el proyecto
reactiva este flujo de trabajo, de iteración e iteración, la arquitectura evoluciona hasta que está perfeccionada y
pulida. Dado que todas las iteraciones incluyen integración y pruebas, la arquitectura es bastante robusta cuando se
entrega el producto. Esta arquitectura es uno de los focos principales de las iteraciones de la fase de Elaboración, al final de cual la arquitectura suele tener su línea base.
|