Arquitectura del sistema

La arquitectura del sistema  es la organización fundamental del sistema , plasmada en sus elementos , sus relaciones entre sí y con el entorno, así como los principios que guían su diseño y evolución [1] :3 .

El concepto de arquitectura es en gran medida subjetivo y tiene muchas interpretaciones contradictorias; en el mejor de los casos, refleja la visión general del equipo de desarrollo sobre los resultados del diseño del sistema. [2] :27 Hay muchas definiciones de arquitectura. Una colección de definiciones, principalmente relacionadas con la arquitectura de software , está compilada en el sitio web del Instituto de Ingeniería de Software de la Universidad Carnegie Mellon [3] .

En la actualidad, existe una fuerte tendencia a considerar el diseño arquitectónico y no arquitectónico como actividades diferentes; se intenta definirlos como prácticas separadas, pero estos tipos de diseño están en gran parte "entrelazados". Las decisiones arquitectónicas se consideran más abstractas, conceptuales y globales que las decisiones de diseño convencionales; están dirigidos al éxito de toda la misión ya las estructuras de más alto nivel del sistema [4] :272 .

Otras definiciones de arquitectura del sistema

La historia del concepto

A medida que aumentaba la complejidad de las tareas a resolver, surgió la necesidad de estructurar sistemas. Sin embargo, los profesionales han encontrado que el término "estructura" es insuficiente para describir todos los aspectos del sistema [4] :272 .

El término "arquitectura" en ingeniería de sistemas fue introducido por el profesor de la Universidad del Sur de California, Eberhardt Rechtin , a principios de la década de 1990 .  Creía que a medida que los sistemas se volvían más complejos, su "diseño de alto nivel" (o "diseño conceptual"), como se entendía en esos años, no era suficiente para llevar a los ingenieros y diseñadores a crear diseños precisos y eficientes. Estudió los principios arquitectónicos de la construcción para comprender cómo se crean y diseñan los sistemas complejos (por ejemplo, los edificios) [6] :223 .

Rekhtin explica el término arquitectura del sistema de la siguiente manera:

La esencia de la arquitectura es estructurar. La estructuración puede significar convertir la forma en función , extraer orden del caos o transformar las ideas parcialmente formadas de un cliente en un modelo conceptual viable [6] :223-224 .

Los términos "arquitectura" y "diseño arquitectónico" han estado en uso durante unos 30 años, especialmente en ingeniería de software y áreas problemáticas como cohetes y espacio [4] :272 .

Conceptos relacionados

Para una descripción más detallada de los principios de la arquitectura, el estándar ISO/IEC/IEEE 42010-2011 introduce los siguientes conceptos [7] :2 .

Tipos de arquitectura

El Cuerpo de Conocimientos de Ingeniería de Sistemas (SEBoK) divide la arquitectura en lógica y física [4] :269 .

Arquitectura lógica

La arquitectura lógica soporta el funcionamiento del sistema a lo largo de todo su ciclo de vida a nivel lógico. Consiste en un conjunto de conceptos y principios técnicos relacionados. La arquitectura lógica está representada por métodos correspondientes a grupos temáticos de descripciones y, como mínimo, incluye una arquitectura funcional, una arquitectura de comportamiento y una arquitectura temporal.

Arquitectura funcional . La arquitectura funcional es un conjunto de funciones y sus subfunciones que determinan las transformaciones que realiza el sistema al cumplir su propósito.

Arquitectura conductual . La arquitectura conductual es un acuerdo sobre las funciones y sus subfunciones, así como las interfaces (entradas y salidas), que determinan la secuencia de ejecución, las condiciones de control o flujo de datos, el nivel de rendimiento necesario para satisfacer los requisitos del sistema. La arquitectura conductual se puede describir como una colección de escenarios, funciones y/o modos operativos interrelacionados.

Arquitectura temporal . La arquitectura temporal es una clasificación de las funciones del sistema, que se obtiene de acuerdo con el nivel de frecuencia de su ejecución. La arquitectura temporal incluye la definición de aspectos sincrónicos y asincrónicos de las funciones. El seguimiento de las decisiones que tiene lugar dentro del sistema sigue la misma clasificación temporal [4] :287 .

Arquitectura física

El objetivo del diseño de la arquitectura física es crear una solución física y concreta que sea coherente con la arquitectura lógica y satisfaga los requisitos del sistema especificados.

Una vez que se define la arquitectura lógica, se deben identificar los elementos físicos específicos que soportan las propiedades funcionales, de comportamiento y temporales, así como las propiedades esperadas del sistema derivadas de los requisitos no funcionales del sistema.

Una arquitectura física es una sistematización de los elementos físicos (elementos del sistema e interfaces físicas) que implementan las soluciones diseñadas para un producto, servicio o empresa. Está diseñado para cumplir con los requisitos del sistema y los elementos de la arquitectura lógica y se implementa a través de los elementos tecnológicos del sistema. Los requisitos del sistema se distribuyen entre arquitecturas lógicas y físicas. La arquitectura global del sistema se evalúa a través del análisis del sistema y, una vez cumplidos todos los requisitos, se convierte en la base para la implementación del sistema [4] :296 .

Descripción arquitectónica

Una arquitectura se puede capturar utilizando una descripción arquitectónica completa (AO) (ver figura). El estándar ISO/IEC/IEEE 42010-2011 prescribe una distinción entre la arquitectura conceptual de un sistema y una de las descripciones de esa arquitectura, que es un producto o artefacto en particular.

En sistemas complejos, AO se puede desarrollar no solo para el sistema como un todo, sino también para los componentes del sistema. Dos AO conceptuales diferentes pueden incluir grupos de descripciones que corresponderán al mismo método de descripción. Aunque los sistemas descritos por estos dos grupos de descripción estarán relacionados en su totalidad y en parte, este no es un ejemplo de múltiples grupos de descripción correspondientes a un método. Estos AO se consideran separados a pesar de que están vinculados a través de los sistemas que describen [7] :3 .

Enfoque conceptual

El enfoque conceptual define términos y conceptos relacionados con el contenido y la aplicación de AO. La figura muestra los conceptos principales y sus relaciones. Todos los conceptos se definen en el contexto de una arquitectura de sistema específica y una descripción arquitectónica asociada. No se debe suponer que solo hay una arquitectura para un sistema, o que esta arquitectura está representada por una sola descripción arquitectónica.

En la figura, los cuadros representan las clases de entidad.

Las líneas que conectan los rectángulos representan las relaciones entre entidades. La comunicación incluye dos roles (uno en cada dirección). Cada función se puede nombrar opcionalmente con una etiqueta. Un rol dirigido de A a B está [etiquetado] más cerca de B, y viceversa. Por ejemplo, los roles entre "sistema" y "entorno" podrían ser "el 'sistema' vive en el 'entorno'" y "el 'entorno' influye en el 'sistema'". En la figura, los roles tienen una aridad de 1:1 a menos que se indique lo contrario. Un rol puede tener aridad múltiple, por ejemplo, un rol denotado como "1..*" se usa para denotar muchos, como en las relaciones de uno a muchos o de muchos a uno. El rombo (al final de la línea de comunicación) denota la relación de una parte del todo. Por ejemplo, los "grupos de descripción" forman parte de la "descripción arquitectónica". Esta notación se toma prestada de UML.

Consideremos cada componente del esquema conceptual con más detalle. En el contexto del esquema considerado, el sistema se extiende a aplicaciones de software individuales, sistemas en el sentido tradicional, subsistemas, sistemas de sistemas, productos, familias de productos, organizaciones como un todo y otras poblaciones de interés.

El sistema vive en algún entorno. El entorno de un determinado sistema puede influir en este sistema. Su ambiente, o contexto, define el ambiente y las circunstancias de desarrollo, operación, política y otras influencias en un sistema dado. Dicho entorno puede incluir otros sistemas que interactúan con el sistema de destino, ya sea directamente a través de interfaces o indirectamente de otras formas. Dicho entorno define los límites que definen el tema del sistema de destino en relación con otros sistemas.

Cada sistema tiene una o más partes interesadas . Cada parte interesada por lo general participa en el sistema, o tiene un interés en el sistema. Los intereses implican tener en cuenta aspectos del sistema como el rendimiento, la fiabilidad, la seguridad, la distribución y la capacidad de evolución.

Cualquier sistema existe para implementar una o más misiones en su entorno.

En el enfoque conceptual, una descripción arquitectónica se organiza como uno o más grupos de descripción arquitectónica.

La descripción arquitectónica selecciona uno o más métodos de descripción apropiados para aplicar. La elección de los métodos de descripción generalmente se basa en las consideraciones e intereses de las partes interesadas a quienes se dirige el AO. La definición del método de descripción puede ocurrir junto con el AO, o puede definirse por separado. Un método de descripción definido por separado del AO se denomina método de descripción de biblioteca.

Un grupo de descripción puede constar de una o más descripciones arquitectónicas. Cada una de estas descripciones arquitectónicas se desarrolla utilizando los métodos establecidos de descripción arquitectónica apropiados para ella. Una descripción arquitectónica puede estar incluida en más de un grupo de descripciones [7] :4-6 .

Tipos de grupos de descripción de arquitectura

Hay tres tipos de grupo de descripción: funcional, lógico y físico. Cada uno de los grupos pretende describir sus propios puntos de vista y su correspondiente nivel de complejidad [6] :224 .

Descripción grupo funcional

Este grupo proporciona una vista de usuario u operador que incluye productos relacionados con las fases, escenarios y flujos de tareas del sistema operativo. El flujo de información se puede ver desde la perspectiva del usuario y también se describen las interfaces de usuario. Ejemplos de productos que pueden incluirse en esta descripción serían datos o gráficos funcionales, descripciones de escenarios (incluido el uso de estudios de casos), diagramas de flujo de tareas, organigramas y diagramas de flujo de información [6] :224 .

Grupo lógico de descripciones

Este grupo proporciona una visión desde el punto de vista del gerente o del cliente. La vista lógica incluye productos que definen los límites del sistema con su entorno e interfaces funcionales con sistemas externos, así como las principales funciones y el comportamiento del sistema, flujos de información, conjuntos de datos internos y externos, usuarios internos y externos e interfaces funcionales internas. . Los ejemplos de productos incluyen diagramas de bloques de flujo funcional (FFBD), diagramas de contexto, diagramas , diagramas IDEF0 , datos de diagramas de flujo y varias partes interesadas: productos característicos (incluidos los productos dependientes del negocio) [6] :224 .

Descripciones de grupos físicos

Este grupo ofrece una visión desde el punto de vista de los diseñadores. Incluye:

  • productos que definen los límites físicos del sistema;
  • los componentes físicos del sistema y cómo interactúan e influyen entre sí;
  • bases de datos internas y estructuras de datos;
  • sistemas de infraestructura de tecnología de la información (TI);
  • infraestructura de TI externa con la que interactúa el sistema;
  • requisitos necesarios para el desarrollo del sistema.

El producto puede incluir diagramas de bloques físicos con un nivel de detalle bastante alto, topologías de bases de datos , interfaces de gestión de documentos y estándares. Los tres tipos de grupos deben estar presentes en cada descripción de arquitectura [6] :224 .

Aplicación de descripciones arquitectónicas

Las descripciones arquitectónicas durante el ciclo de vida pueden ser aplicadas de manera diferente por todas las partes interesadas. Dichas aplicaciones incluyen, entre otras, las siguientes:

  • análisis de arquitecturas alternativas
  • planificación comercial para la transición del legado a la nueva arquitectura;
  • comunicación de organizaciones involucradas en el desarrollo, producción, instalación, operación y mantenimiento de sistemas;
  • comunicación entre clientes y desarrolladores como parte de la preparación del acuerdo;
  • criterios para certificar que una implementación se ajusta a una arquitectura dada;
  • documentación de desarrollo y mantenimiento, incluida la preparación de materiales para depósitos para su reutilización y materiales de formación;
  • entrada para las actividades subsiguientes de diseño y desarrollo del sistema;
  • materiales fuente para herramientas para crear y analizar el sistema;
  • apoyo operativo y de infraestructura; gestión y reparación de configuraciones ; rediseño y mantenimiento de sistemas, subsistemas y componentes;
  • apoyo a la planificación y financiación [7] :9 .

Notas

  1. GOST R ISO/IEC 15288, 2008 .
  2. 1 2 Fowler M., 2006 .
  3. Definiciones de arquitectura de software de la comunidad Archivado el 22 de mayo de 2014 en Wayback Machine // Instituto de ingeniería de software, Universidad Carnegie Mellon
  4. 1 2 3 4 5 6 SEBoK, 2012 .
  5. Danilin, Slyusarenko, 2005 .
  6. 1 2 3 4 5 6 Principios y práctica de ingeniería de sistemas, 2011 .
  7. 1 2 3 4 ISO/IEC 42010, 2011 .

Literatura

  • GOST R ISO/IEC 15288-2008. Ingeniería de Sistemas - Procesos del ciclo de vida de los sistemas. — 2008.
  • Danilin A., Slyusarenko A. Arquitectura y estrategia. "Yin" y "Yang" de las empresas de tecnología de la información. - M. : Universidad de Internet de las Tecnologías de la Información, 2005. - 504 p. — ISBN 5-9556-0045-0 .
  • Fowler M. Arquitectura de aplicaciones de software corporativo.: Per. De inglés. — M.: Williams Publishing House, 2006. — 544 p. ISBN 5-8459-0579-6
  • Pyster, A., D. Olwell, N. Hutchison, S. Enck, J. Anthony, D. Henry y A. Squires (eds). Guía del Cuerpo de Conocimientos de Ingeniería de Sistemas (SEBoK) versión 1.0 . — Los fideicomisarios del Instituto de Tecnología Stevens, 2012.
  • Kossiakoff A., Sweet WN, Seymour SJ, Biemer SM Principios y prácticas de ingeniería de sistemas. - 2ª ed. - Hoboken, Nueva Jersey: A John Wiley & Sons, 2011. - 599 p. — ISBN 978-0-470-40548-2 .
  • ISO/CEI 42010:2011. Ingeniería de sistemas y software - Descripción de la arquitectura. — 2011.

Enlaces