Concepto: Arquitectura del sistema
Una arquitectura de sistema es una representación de un sistema en la que hay una correlación de funciones con componentes de hardware y software, una correlación de la arquitectura de software con la arquitectura de hardware, e interacción humana con estos componentes.
Relaciones
Descripción principal

Introducción

Actualmente, el término arquitectura se utiliza mucho sin su connotación tradicional de compilación y existen muchas definiciones de "arquitectura" (en el contexto de sistemas) y "arquitectura del sistema (o sistemas)", por ejemplo:

"Systems architecture: the fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviors." (Arquitectura de sistemas: la estructura del sistema fundamental y de unificación definida en términos de comportamientos, restricciones, procesos, interfaces y elementos del sistema). 
[definición de línea base aprobada por INCOSE Systems Architecture Working Group en INCOSE '96, en Boston (MA), el 8 de julio de 1996]

"System architecture comprises the major physical properties, style, structure, interactions, and purpose of a system." (La arquitectura del sistema comprende las principales propiedades físicas, el estilo, la estructura, las interacciones y el objetivo de un sistema).
[Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz Pirbhai, Dorset House Publishing 2000]

"Architecture: the concepts and rules that define the structure, semantic behavior, and relationships among the parts of a system; a plan of something to be constructed. It includes the elements that comprise the thing, the relationships among those elements, the constraints that affect those relationships, a focus on the parts of the thing, and a focus on the thing as a whole." (Arquitectura: los conceptos y reglas que definen la estructura, el comportamiento semántico y las relaciones entre los componentes de un sistema; un plan de construir algo. Incluye los elementos que forman ese algo, las relaciones entre dichos elementos, las restricciones que afectan a dichas relaciones, el foco de los componentes y el foco de todo el conjunto).
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001, que hace referencia a ISO/IEC 10746-2: Tecnología de la información - Proceso distribuido abierto - Modelo de referencia: Bases, igual que el origen]

"Architecture: the structure of components in a program/system, their interrelationships, and the principles and guidelines governing their design and evolution over time." (Arquitectura: la estructura de componentes en un programa/sistema, sus interrelaciones y los principios y directrices que rigen el diseño y la evolución en el tiempo).
[DoD 5000.59-P, "Modeling and Simulation Master Plan," Octubre 1995]

Una arquitectura es "the structure of components, their relationships, and the principles and guidelines governing their design and evolution over time." (la estructura de componentes, sus relaciones y los principios y directrices que rigen el diseño y la evolución en el tiempo).
[IEEE STD 610.12, ligeramente ampliada por Integrated Architectures Panel (IAP) de C4ISR Integration Task Force (ITF) en DoD Architecture Framework, Versión 1.0]

Se utilizan diferentes palabras y construcciones, y no todas las definiciones cubren exactamente los mismos aspectos, aunque hay superposiciones significativas. Estas definiciones revelan que la arquitectura de sistema consiste en lo siguiente:

  • la estructura del sistema en términos de elementos, componentes y partes
  • las relaciones entre estos elementos
  • las restricciones que afectan a los elementos y sus relaciones
  • el comportamiento que manifiesta el sistema y las interacciones que se originan entre los elementos para producir dicho comportamiento
  • los principios, reglas y fundamentos que hacen que el sistema sea como es (y rigen su evolución)
  • las características y propiedades lógicas y físicas del sistema
  • el objetivo del sistema

Por lo tanto, para reflejar completamente todos estos aspectos es necesario un conjunto de información rico y potencialmente complejo, pero hay que ser consciente de que no todos los interesados deben ver o comprender todos los aspectos de manera simultánea. La idea de puntos de vista permite la separación de los diferentes problemas y la presentación en una clase de interesados de únicamente lo necesario para una participación eficaz. Desde la perspectiva de un punto de vista particular, también puede ver el sistema en diferentes "resoluciones", desde baja resolución, que corresponde a un nivel de abstracción elevado, hasta alta resolución, que corresponde a una especificación concreta (de partes y demás) para la implementación.

Punto de vista

Un punto de vista (en un sistema) es "a form of abstraction achieved using a selected set of architectural concepts and structuring rules, in order to focus on particular concerns within a system." (una forma de abstracción que se consigue mediante un conjunto seleccionado de conceptos arquitectónicos y reglas de estructura, para centrarse en problemas particulares de un sistema). [ISO/IEC 10746-2: Tecnología de la información - Proceso distribuido abierto - Modelo de referencia: Bases]. La tabla lista algunos de los puntos de vista para detectar varios problemas. Estos puntos de vista se alinean con los que se encuentran en ISO/IEC 10746-1: Tecnología de la información - Proceso distribuido abierto - Modelo de referencia: Visión general.

Punto de vista Asunto Impacto
Trabajador Se ocupa de los roles y las responsabilidades de los trabajadores del sistema y la organización (y las políticas que les afectan). Actividades del trabajador, interacción humano/sistema. Especificación del rendimiento humano y factores humanos.
Información Las clases de información que maneja el sistema y las restricciones de utilización e interpretación de dicha información. Integridad de la información, limitaciones de capacidad.
Accesibilidad de la información, actualidad.
Lógico La descomposición del sistema en un conjunto de subsistemas que interactúan en interfaces, colaboran para proporcionar los servicios del sistema. El sistema muestra el comportamiento deseado.
El sistema es extensible, adaptable y se puede mantener.
Los activos son reutilizables.
Distribución/Físico La infraestructura necesaria para soportar la distribución y la funcionalidad del sistema. La adecuación de las características físicas del sistema para alojar las funciones y satisfacer los requisitos no funcionales.
Proceso Concurrencia, escalabilidad, rendimiento, producción, fiabilidad. La adecuación de la capacidad de respuesta, el rendimiento y la tolerancia a errores del sistema.

Puntos de vista comunes del sistema.

Estos puntos de vista son algunos de los más comunes para sistemas de software intensivos. Muchas arquitecturas de sistema también requieren puntos de vista adicionales específicos del dominio. Algunos ejemplos son los puntos de vista mecánicos y de seguridad. Los puntos de vista representan diferentes áreas de preocupación que deben tratarse en el diseño y la arquitectura del sistema. Si hay expertos o interesados en el sistema que tienen preocupaciones importantes para la arquitectura general, puede que sea necesario un conjunto de productos de trabajo de puntos de vista para capturar las decisiones de diseño. 

Es importante crear un equipo de arquitectura del sistema con personal competente para buscar los diferentes puntos de vista. El equipo puede estar formado por analistas empresariales y usuarios que asumen la responsabilidad principal del punto de vista del trabajador, los arquitectos de software que adoptan el punto de vista lógico y los ingenieros que se encargan del punto de vista físico, así como los expertos en puntos de vista específicos del dominio.

Niveles de abstracción

Además de los puntos de vista, una arquitectura del sistema requiere niveles de especificación. A medida que se desarrolla la arquitectura, evoluciona desde una especificación abstracta y general a una especificación más detallada y específica. RUP identifica cuatro niveles de arquitectura, como se muestra en la siguiente tabla.

Nivel de modelo Expresa
Contexto El sistema y sus actores.
Análisis Partición inicial del sistema para establecer la propuesta conceptual.
Diseño Realización del modelo de análisis de hardware, software y personas.
Implementación Realización del modelo de diseño en configuraciones específicas.

Niveles de arquitectura de RUP

En estos niveles, el diseño pasa de lo abstracto a lo físico. El modelo de contexto captura todas las entidades (actores) externos que interactúan con el sistema. Estos actores pueden ser externos a la empresa que despliega el sistema o internos. En ambos casos, los actores pueden ser trabajadores humanos u otros sistemas. En el nivel de análisis, las particiones no reflejan las elecciones de hardware, software y personas. En su lugar, reflejan las propuestas de diseño para dividir lo que debe hacer el sistema y cómo se debe distribuir el esfuerzo. En el nivel de diseño, las decisiones se toman en función de las clasificaciones de componentes de hardware y software y los roles de trabajador necesarios. En el nivel de implementación, se hacen elecciones específicas de tecnología de software y hardware para implementar el diseño. Por ejemplo, en el nivel de diseño, se puede especificar un servidor de datos. En el nivel de implementación, se toma la decisión de utilizar una plataforma específica que ejecute una aplicación de bases de datos específica.

Modelos y diagramas

Un modelo es una representación de un sistema, que normalmente trata un área de preocupación en particular. Un sistema, por lo tanto, suele representarse mediante un conjunto de modelos, ya que el desarrollo o la utilización del sistema tienen varios asuntos que tratar. Cada modelo se puede construir con varios niveles de abstracción, desde el más general, que oculta o encapsula detalles, al más específico, que presenta decisiones de diseño más explícitas y detalladas.

Un punto de vista, tal como implica su nombre, es una "posición" nocional desde la que se pueden ver algunos aspectos o asuntos del sistema, lo que supone la aplicación de un conjunto de conceptos y reglas para formar un filtro conceptual. Normalmente, no es suficiente (para obtener conocimiento) limitarse a examinar el sistema real; los modelos se han construido (o deberían haberse construido) para representar y describir las preocupaciones.

Las vistas son proyecciones de modelos que muestran entidades importantes desde un punto de vista particular. Estas proyecciones suelen ilustrarse mediante diagramas de algún tipo.

La intersección del nivel de abstracción o especificación del modelo y el punto de vista contiene (o, por lo menos, identifica) vistas de uno o varios modelos relevantes para ese punto de vista o asunto, en ese nivel de abstracción.

Entonces, la arquitectura del sistema se captura en un conjunto de modelos (y diagramas que los visualizan) que expresan la arquitectura desde varios puntos de vista y niveles. Como se muestra en la tabla de infraestructura del modelo que aparece abajo, no hay un modelo/diagrama para cada combinación de nivel y punto de vista. En el nivel de implementación, un solo modelo captura la realización de componentes de hardware y software para cada configuración del sistema.

Nivel de modelo Puntos de vista
Trabajador Lógico Información Distribución/Físico Proceso
Contexto Vista Organización UML Diagrama de contexto del sistema Vista Datos empresariales Vista Localidad empresarial Vista Proceso empresarial
Análisis Vista Trabajador del sistema generalizado Vista Subsistema Vista Datos del sistema Vista Localidad del sistema Vista Proceso del sistema
Diseño Vista Trabajador del sistema Vistas Clase de subsistema

Vistas Componente de software

Esquema de datos del sistema Vista Nodo de descriptor Vista Proceso detallado
Implementación Instrucciones y especificaciones del rol de trabajador Configuraciones: diagramas de despliegue con componentes del sistema de hardware y software.

Muchas de las vistas especificadas en la tabla se derivan de modelos UML estándar. Por ejemplo, en el nivel de análisis del punto de vista lógico, el sistema se descompone en subsistemas que colaboran para satisfacer los requisitos del usuario. Los subsistemas se utilizan con la misma semántica que el estándar UML. Estos subsistemas, a su vez, se descomponen en subsistemas o (en última instancia) clases. El nivel de diseño del punto de vista lógico es la vista del modelo de clase detallado. El modelo de proceso también es un modelo de clase UML estándar, que se centra en clases activas del sistema. Los puntos de vista específicos del dominio también necesitan tener vistas de productos de trabajo para uno o varios niveles. El conjunto de productos de trabajo del proyecto, en esta infraestructura, debe formar parte del guión de desarrollo del proyecto.