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