Directriz: Documento de arquitectura de software
Esta directriz proporciona una visión general de los contenidos del documento de arquitectura de software.
Relaciones
Descripción principal

Referencias

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:

  1. documentos externos
  2. documentos internos
  3. documentos de gobierno
  4. documentos no gubernamentales
  5. etc.

Objetivos y restricciones de la arquitectura

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

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:

  1. El nombre del guión de uso.
  2. Una descripción breve del guión de uso.
  3. 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.
  4. 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.
  5. Una enumeración de los diagramas de guión de uso relacionados con el guión de uso.
  6. 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.
  7. Imágenes de la interfaz de usuario significativas, que aclaren el guión de uso.
  8. Las realizaciones de estos guiones de uso deben encontrarse en la vista lógica.

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:

  1. 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.

  2. Paquete de diseños arquitectónicamente significativos

    Para cada paquete significativo, incluya una subsección con la información siguiente:

    1. Su nombre.
    2. Una descripción breve.
    3. 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.
    4. 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.
  3. 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:

    1. El nombre del guión de uso realizado.
    2. Una descripción breve del guión de uso realizado.
    3. 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.
    4. Una enumeración de la interacción significativa o diagramas de clase relacionados con la ejecución de guiones de uso.
    5. 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

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:

  1. Su nombre.
  2. Los procesos implicados.
  3. 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.

La vista de despliegue

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:

  1. Su nombre.
  2. Un diagrama de despliegue que ilustra la configuración, seguido de una correlación de procesos para cada procesador.
  3. 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.

La vista de implementación

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:

  1. 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.

  2. Capas

    Para cada capa, incluya una subsección con la información siguiente:

    1. Su nombre.
    2. Un diagrama de componentes que muestra los subsistemas de implementación y sus dependencias de importación.
    3. Si resulta apropiado, una esquematización de la relación de la capa con los elementos de la vista lógica o de proceso.
    4. 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.

La vista de datos

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.).

Tamaño y rendimiento

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.

Calidad

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.