La sección de referencias presenta documentos externos que proporcionan información de fondo importante para la
comprensión de la arquitectura del sistema. Si existe un gran número de referencias, estructure la sección en
subsecciones:
-
documentos externos
-
documentos internos
-
documentos de gobierno
-
documentos no gubernamentales
-
etc.
La arquitectura se formará teniendo en cuenta:
-
requisitos funcionales, capturados en el modelo de guión de uso
-
requisitos no funcionales, capturados en las especificaciones suplementarias
No obstante, estas no son las únicas influencias que formarán la arquitectura: existirán restricciones impuestas por el
entorno en que el software debe operar; por la necesidad de reutilizar los activos existentes; por la imposición de
diferentes estándares; por la necesidad de compatibilidad con los sistemas existentes, etc. También puede haber
un conjunto preexistente de principios y políticas arquitectónicas que orientarán el desarrollo, y que deben ser
elaboradas y verificadas para el proyecto. Esta sección del documento de arquitectura de software es el
lugar para describir estos objetivos y restricciones, y cualquier decisión arquitectónica que fluya de ellos que
no encuentre un inicio preparado (como requisitos) en otra parte.
Cuando se crea este documento, una entrada importante es una especificación del entorno de implementación. Ejemplos de
cosas que se deben especificar son plataformas de destino (hardware, sistema operativo), sistema de ventanas,
herramientas de desarrollo (lenguaje, constructor de GUI), sistema de gestión de base de datos y bibliotecas de
componentes. También es valorable especificar qué tecnologías de interfaz de usuario se permiten y cuáles
no. Muchos sistemas escogen no utilizar ciertas tecnologías de presentación (JavaScript, Applets, Frames, XML,
etc.) para que más sistemas cliente puedan utilizar la aplicación, o para que la aplicación sea más sencilla de
desarrollar. Las decisiones se capturan aquí en el documento de arquitectura de software, mientras que los
detalles sobre cómo utilizar y aplicar las tecnologías escogidas se documenta en Producto de trabajo: Directrices específicas de proyecto.
La aplicación de estas decisiones se alcanza formando un conjunto de criterios de evaluación de arquitectura que
se utilizará como parte de la valoración de iteración.
Los criterios de evaluación también se derivan de los Guiones de cambio que documentan los posibles cambios
futuros a:
-
las capacidades y las propiedades del sistema
-
el modo en que se utiliza el sistema
-
los entornos operativo y de soporte del sistema
Los guiones de cambio aclaran estas propiedades del sistema descrito por frases subjetivas como "fácil de ampliar",
"fácil de conectar al puerto", "fácil de mantener", "robusto ante los cambios" y "rápido de desarrollar". Los guiones
de cambio se centran en lo que es importante y probable en lugar de centrarse sólo en lo que es posible.
Los guiones de cambio intentan predecir los cambios: estas predicciones raramente acaban siendo exactamente ciertas.
Las propiedades de un sistema las determinan los usuarios, patrocinadores, proveedores, desarrolladores y otros
interesados. Los cambios pueden surgir de muchos orígenes, por ejemplo:
-
Controladores empresariales: procesos empresariales nuevos y modificados y objetivos
-
Controladores de tecnología: adaptación del sistema a nuevas plataformas, integración con nuevos componentes
-
Cambios en los perfiles del usuario medio
-
Cambios en las necesidades de integración con otros sistemas
-
Cambios de ámbito que surgen de la migración de la funcionalidad de sistemas externos
La vista de guión de uso presenta un subconjunto de Producto de trabajo: Modelo de guión de uso, que presenta los guiones
de uso arquitectónicamente significativos del sistema. Describe el conjunto de casos de ejemplo y/o guiones de uso que
representan alguna funcionalidad significativa o central. También describe el conjunto de casos de ejemplo y/o guiones
de uso que tienen una cobertura arquitectónica sustancial (que ejercen muchos elementos arquitectónicos)o que presionan
o ilustran un punto específico, delicado, de la arquitectura.
Si el modelo es mayor, habitualmente se organizará en paquetes; para facilitar la comprensión, la vista de guión de
uso, debe organizarse similarmente por paquete, si están empaquetados. Para cada guión de uso significativo, incluya
una subsección con la información siguiente:
-
El nombre del guión de uso.
-
Una descripción breve del guión de uso.
-
Descripciones significativas de los Sucesos de flujo del guión de uso. Puede ser la descripción completa del
Flujo de sucesos, o subsecciones de este que describen flujos significativos o casos de ejemplo del guión de
uso.
-
Las descripciones significativas de relaciones que implican el guión de uso, como las relaciones de inclusión y
ampliación, o las asociaciones de comunicación.
-
Una enumeración de los diagramas de guión de uso relacionados con el guión de uso.
-
Descripciones significativas de Requisitos especiales del guión de uso. Puede ser la descripción completa de
los Requisitos especiales, o subsecciones de este que describen requisitos significativos.
-
Imágenes de la interfaz de usuario significativas, que aclaren el guión de uso.
-
Las realizaciones de estos guiones de uso deben encontrarse en la vista lógica.
La vista lógica es un subconjunto del Producto de trabajo: Modelo de diseño que presenta los elementos de
diseño arquitectónicamente significativos. Describe las clases más importantes, su organización en paquetes y
subsistemas, y la organización de estos paquetes y subsistemas en capas. También describe las ejecuciones de guión de
uso más importantes, por ejemplo, los aspectos dinámicos de la arquitectura.
Un sistema complejo puede requerir una serie de secciones que descubran la vista lógica:
-
Visión general
Esta subsección describe el desglose global del modelo de diseño en términos de la jerarquía y las capas de su
paquete. Si el sistema tiene varios niveles de paquetes, primero debe describir los que son significativos en
el nivel superior. Incluya los diagramas que muestran los paquetes significativos de nivel superior, así como
sus interdependencias y capas. Los siguientes presentan todos los paquetes significativos dentro de estos, y
así sucesivamente hasta los paquetes significativos de la parte inferior de la jerarquía.
-
Paquete de diseños arquitectónicamente significativos
Para cada paquete significativo, incluya una subsección con la información siguiente:
-
Su nombre.
-
Una descripción breve.
-
Un diagrama con todas las clases significativas y paquetes contenidos dentro del paquete. Para mejorar la
comprensión, este diagrama puede mostrar algunas clases de otros paquetes si fuera necesario.
-
Para cada clase significativa del paquete, incluya nombre, descripción breve y, opcionalmente, una
descripción de alguna de sus principales responsabilidades, operaciones y atributos. Describa también las
relaciones importantes si fuera necesario para comprender los diagramas incluidos.
-
Ejecuciones de guión de uso
Esta sección ilustra cómo funciona el software dando unas cuantas ejecuciones de guión de uso (o casos de
ejemplo) seleccionadas, y explica cómo los diferentes elementos de modelo de diseño contribuyen en su
funcionalidad. Las ejecuciones que se muestran se han elegido porque representan funcionalidades significativas
y centrales del sistema final; o por su cobertura arquitectónica - ejercen muchos elementos arquitectónicos - o
destacan o ilustran un punto específico o delicado de la arquitectura. Los guiones de uso y casos de ejemplo
correspondientes a estas ejecuciones deben encontrarse en la vista de guión de uso.
Para cada ejecución de guiones de uso significativa, incluya una subsección con la información siguiente:
-
El nombre del guión de uso realizado.
-
Una descripción breve del guión de uso realizado.
-
Descripciones significativas del Flujo de sucesos - Diseño de la ejecución de guiones de uso. Puede
ser la descripción completa del Flujo de sucesos - Diseño, o subsecciones de este que describen la
ejecución de flujos significativos o casos de ejemplo del guión de uso.
-
Una enumeración de la interacción significativa o diagramas de clase relacionados con la ejecución de
guiones de uso.
-
Descripciones significativas de Requisitos derivados de la ejecución de guiones de uso. Puede ser la
descripción completa de los Requisitos derivados, o subsecciones de este que describen requisitos
significativos.
Elementos de diseño arquitectónicamente significativos
Para ayudar en la decisión de qué es arquitectónicamente significativo, se presentan algunos ejemplos de elementos
calificativos y sus características:
-
Un elemento de modelo que encapsula una abstracción principal del dominio del problema, como por ejemplo:
-
Un plan de vuelo en un sistema de control de vuelos.
-
Un empleado en un sistema de nóminas.
-
Un suscriptor en un sistema telefónico.
Subtipos de estos no deben incluirse necesariamente, por ej., Distinguir un Plan de vuelo estándar ICAO de
un Plan de vuelo doméstico en EE.UU. no es importante; son planes de vuelos y comparten una cantidad
sustancial de atributos y operaciones.
Distinguir un suscriptor con una línea de datos, o con una línea de voz, no importa siempre que el manejo de la
llamada entre de un modo similar.
-
Un elemento de modelo que se utiliza en muchos otros elementos de modelo.
-
Un elemento de modelo que encapsula un mecanismo principal (servicio) del sistema
-
Mecanismos de diseño
-
Mecanismo de permanencia (gestión del depósito, base de datos, memoria).
-
Mecanismo de comunicación (RPC, difusión, servicio intermediario).
-
Manejo de errores o mecanismo de recuperación.
-
Mecanismo de visualización, y otras interfaces comunes (ventanas, captura de datos, condicionamiento de
señal, etc.).
-
Mecanismos de parametrización.
En general, cualquier mecanismo que se pueda utilizar en muchos paquetes diferentes (en oposición a completamente
interno en un paquete), y para el cual es positivo tener una única implementación común en el sistema, o como mínimo
una única interfaz que oculta varias implementaciones alternativas.
-
Un elemento de modelo que participa en una interfaz principal del sistema con, por ejemplo:
-
Un sistema operativo.
-
Un producto asequible (sistema de ventanas, RDBMS, sistema de información geográfica).
-
Una clase que implementa o proporciona soporte a un patrón de arquitectura (como patrones para desacoplar
elementos de modelo, que incluyen el patrón modelo-vista-controlador, o el patrón intermediario).
-
Un elemento de modelo que tiene visibilidad localizada, pero puede tener un gran impacto en el rendimiento global
del sistema, por ejemplo:
-
Un mecanismo de sondeo para explorar los sensores a una velocidad muy alta.
-
Un mecanismo de rastreo para solucionar problemas.
-
Un mecanismo de sincronización por puntos de comprobación para sistemas de alta disponibilidad (punto de
comprobación y reinicio).
-
Una secuencia de inicio.
-
Una actualización en línea del código.
-
Una clase que encapsula un algoritmo nuevo y técnicamente arriesgado, o algún algoritmo que es crítico para
la seguridad, como por ejemplo: la computación del nivel de irradiación; criterios para evitar la colisión
de aviones en un espacio aéreo congestionado; cifrado de contraseñas.
Los criterios de lo que es arquitectónicamente significativo evolucionará en las iteraciones tempranas del proyecto, a
medida que descubra las dificultades técnicas y empiece a comprender mejor el sistema. Como norma, sin embargo, debe
etiquetar como máximo un 10% de los elementos de modelo como "arquitectónicamente significativo." Si no, se
arriesga a diluir el concepto de arquitectura y que "todo sea arquitectura".
Cuando define e incluye los elementos de modelo arquitectónicamente significativos en la vista lógica, también debe
considerar los aspectos siguientes:
-
Identifique el potencial de similitudes y reutilizaciones. ¿Qué clases podrían ser subclases de una clase común, o
instancias de la misma clase parametrizada?
-
Identifique el potencial de parametrización. ¿Qué componente del diseño puede ser más reutilizable o flexible
utilizando parámetros estáticos y de tiempo de ejecución (como un comportamiento regido por una tabla, o datos de
recurso cargados en el inicio)?
-
Identifique el potencial de utilización de productos asequibles.
La vista de proceso describe la estructura de proceso del sistema. Como la estructura de proceso tiene un mayor impacto
en la arquitectura, todos los procesos deben presentarse. Dentro de los procesos, sólo deben presentarse las hebras
ligeras arquitectónicamente significativas. La vista de proceso describe las tareas (procesos y hebras) implicadas en
la ejecución del sistema, sus interacciones y configuraciones y la asignación de objetos y clases a las tareas.
Para cada red de procesos, incluya una subsección con la información siguiente:
-
Su nombre.
-
Los procesos implicados.
-
Las interacciones entre procesos en forma de diagramas de comunicación, en que los objetos son procesos reales que
engloban sus propias hebras de control. Para cada proceso, describa brevemente su comportamiento, tiempo de vida y
características de comunicación.
En esta sección se describen una o más configuraciones de redes físicas (hardware) donde el software está desplegado y
ejecutándose. También describe la asignación de tareas (de la Vista de proceso) a los nodos físicos. Para cada
configuración de red física, incluya una subsección con la información siguiente:
-
Su nombre.
-
Un diagrama de despliegue que ilustra la configuración, seguido de una correlación de procesos para cada
procesador.
-
Si existen muchas posibles configuraciones físicas, describa sólo una típica y explique las reglas de correlación
generales para seguir definiendo otras. También debe incluir, en la mayoría de casos, descripciones de
configuraciones de red para efectuar pruebas y simulaciones de software.
Esta vista se genera a partir del Producto de trabajo: Modelo de despliegue.
En esta sección se describe la descomposición del software en capas y subsistemas de implementación en el modelo de
implementación. También proporciona una visión general de la asignación de elementos de diseño (desde la vista lógica)
hasta la implementación. Contiene dos subsecciones:
-
Visión general
Esta subsección nombre y define las diferentes capas y sus contenidos, las reglas que gobiernan la inclusión de
una capa determinada, y los límites entre capas. Incluye un diagrama de componentes que muestra las relaciones
entre capas.
-
Capas
Para cada capa, incluya una subsección con la información siguiente:
-
Su nombre.
-
Un diagrama de componentes que muestra los subsistemas de implementación y sus dependencias de importación.
-
Si resulta apropiado, una esquematización de la relación de la capa con los elementos de la vista lógica o
de proceso.
-
Una enumeración de los subsistemas de implementación que se encuentran en la capa. Para cada subsistema de
implementación:
-
-
Facilite el nombre, abreviación o apodo, una descripción breve y un motivo de su existencia;
-
Si resulta apropiado, indique una relación del subsistema de implementación con los elementos de la
vista lógica o de proceso. En muchos casos, un subsistema de implementación implementará uno o más
subsistemas de diseño de la vista lógica.
-
Si un subsistema de implementación contiene subsistemas de implementación arquitectónicamente
significativos y/o
directorios, considere reflejar esto en la jerarquía de subsección.
-
Si un subsistema de implementación no correlaciona de uno a uno con un directorio de
implementación, incluya una explicación sobre cómo se ha definido el subsistema de implementación
en términos de directorios de implementación y/o archivos.
Esta vista sólo es relevante para sistemas que impliquen la permanencia soportada de la base de datos. Describe los
elementos permanentes arquitectónicamente significativos en el modelo de datos. Describe una visión general del modelo
de datos y su organización en términos de tablas, vistas, índices, desencadenantes y procedimientos almacenados
utilizados para proporcionar permanencia al sistema. También describe la correlación de clases permanentes (desde la
vista lógica) a la estructura de datos de la base de datos
Habitualmente incluye:
-
La correlación de clases de diseño permanentes clave, especialmente donde la correlación no es trivial.
-
Los componentes arquitectónicamente significativos del sistema que se han implementado en la base de datos, en
forma de procedimientos almacenados y desencadenantes.
-
Decisiones importantes en otras vistas que tienen implicaciones de datos, como elecciones de estrategias de
transacción, distribución, concurrencia y tolerancia a errores. Por ejemplo, la opción de utilizar la gestión de
transacción basada en base de datos (basada en la base de datos para confirmar o cancelar las transacciones)
requiere que el mecanismo de manejo de errores utilizado en la arquitectura incluya una estrategia para recuperar
de una transacción anómala renovando el estado de permanencia de los objetos de la memoria caché de la aplicación.
Debe presentar los elementos de modelo de datos significativos arquitectónicamente, describir sus responsabilidades,
así como unas pocas relaciones y comportamientos muy importantes (desencadenante, procedimientos almacenados, etc.).
En esta sección se describen las características volumétricas de definición arquitectónica y de respuesta del sistema.
La información presentada puede incluir:
-
El número de elementos clave que el sistema tendrá que manejar (como el número de vuelos simultáneos de un sistema
de control de tráfico aéreo, el número de llamadas telefónicas simultáneas de un conmutador de telecomunicaciones,
el número de usuarios simultáneos en línea de un sistema de reserva de líneas aéreas, etc.) .
-
Las medidas de rendimiento clave del sistema, como el tiempo de respuesta medio para sucesos clave; índices de
rendimiento medio, máximo y mínimo, etc.
-
La impresión (en el disco y la memoria) de los programas ejecutables - esencial si el sistema es un sistema
incorporado que debe vivir dentro de restricciones extremadamente limitadas.
La mayoría de estas cualidades se capturan como requisitos; se presentan aquí porque forman la arquitectura en modos
significativos y garantizan enfoques especiales. Para cada requisito, discuta como la arquitectura da soporte a este
requisito.
En esta sección, liste las dimensiones de calidad clave del sistema que forma la arquitectura. La información
presentada puede incluir:
-
Requisitos de rendimiento operativo, como tiempo medio entre anomalías (MTBF).
-
Destinos de calidad, como "tiempo de inactividad no planificado"
-
Destinos ampliables, como "el software se podrá actualizar mientras en sistema se esté ejecutando".
-
Destinos con portabilidad, como plataformas de hardware, sistemas operativos, lenguajes.
Para cada dimensión, discuta como la arquitectura da soporte a este requisito. Puede organizar la sección por las
diferentes vistas (lógica, implementación, y etc.), o por calidad. Cuando unas características concretas son
importantes en el sistema, por ejemplo, seguridad o privacidad, el soporte arquitectónico para estas características
debe delinearse cuidadosamente en esta sección.
|