Ver modelo

Una vista de un sistema es una representación del sistema desde la perspectiva de un punto de vista. Este punto de vista sobre un sistema implica una perspectiva que se centra en preocupaciones específicas relacionadas con el sistema, omitiendo detalles para proporcionar un modelo simplificado que contiene solo aquellos elementos relacionados con dichas preocupaciones. Por ejemplo, un punto de vista de seguridad se centra en las preocupaciones de seguridad, y un modelo de punto de vista de seguridad contiene aquellos elementos relacionados con la seguridad desde un modelo más general del sistema. ^{[ 8 ]}

Una vista permite al usuario examinar una parte de un área de interés particular. Por ejemplo, una Vista de Información puede presentar todas las funciones, organizaciones, tecnologías, etc., que utilizan una información específica, mientras que la Vista Organizacional puede presentar todas las funciones, tecnologías e información relevantes para una organización en particular. En el Marco de Zachman, las vistas comprenden un grupo de productos de trabajo cuyo desarrollo requiere una experiencia analítica y técnica específica, ya que se centran en el "qué", el "cómo", el "quién", el "dónde", el "cuándo" o el "por qué" de la empresa. Por ejemplo, los productos de trabajo de la Vista Funcional responden a la pregunta "¿cómo se lleva a cabo la misión?". Su desarrollo resulta más sencillo para expertos en descomposición funcional mediante el modelado de procesos y actividades. Muestran la empresa desde el punto de vista de las funciones. También pueden mostrar componentes organizativos y de información, pero solo en relación con las funciones. ^{[ 9 ]}

En ingeniería de sistemas, un punto de vista es una partición o restricción de las preocupaciones en un sistema. La adopción de un punto de vista es útil para que los problemas en esos aspectos puedan abordarse por separado. Una buena selección de puntos de vista también divide el diseño del sistema en áreas de especialización específicas. ^{[ 3 ]}

Los puntos de vista proporcionan las convenciones, reglas y lenguajes para construir, presentar y analizar vistas. En ISO/IEC 42010:2007 ( IEEE-Std-1471-2000 ), un punto de vista es una especificación para una vista individual. Una vista es una representación de un sistema completo desde la perspectiva de un punto de vista. Una vista puede constar de uno o más modelos arquitectónicos . ^{[ 10 ]} Cada uno de estos modelos arquitectónicos se desarrolla utilizando los métodos establecidos por su sistema arquitectónico asociado, así como para el sistema en su conjunto. ^{[ 6 ]}

Las perspectivas de modelado consisten en un conjunto de diferentes maneras de representar aspectos preseleccionados de un sistema. Cada perspectiva tiene un enfoque, una conceptualización, una dedicación y una visualización diferentes de lo que representa el modelo .

En los sistemas de información , la forma tradicional de dividir las perspectivas de modelado es distinguir entre las perspectivas estructurales, funcionales y conductuales/procesuales. Esto, junto con las perspectivas de reglas, objetos, comunicación y actores y roles, es una forma de clasificar los enfoques de modelado ^{[ 11 ].}

Desde cualquier punto de vista, es posible crear un modelo del sistema que contenga únicamente los objetos visibles desde ese punto de vista, pero que también capture todos los objetos, relaciones y restricciones presentes en el sistema y relevantes para dicho punto de vista. A este modelo se le denomina modelo de punto de vista, o una vista del sistema desde ese punto de vista. ^{[ 3 ]}

Una vista dada es una especificación del sistema en un nivel de abstracción particular desde un punto de vista determinado. Los diferentes niveles de abstracción contienen diferentes niveles de detalle. Las vistas de nivel superior permiten al ingeniero diseñar y comprender el diseño completo, así como identificar y resolver problemas a gran escala. Las vistas de nivel inferior permiten al ingeniero concentrarse en una parte del diseño y desarrollar las especificaciones detalladas. ^{[ 3 ]}

En el sistema en sí, sin embargo, todas las especificaciones que aparecen en los distintos modelos de perspectiva deben abordarse en los componentes implementados del sistema. Y las especificaciones de cualquier componente dado pueden derivarse de muchas perspectivas diferentes. Por otro lado, las especificaciones derivadas de la distribución de funciones sobre componentes específicos y las interacciones entre componentes generalmente reflejarán una partición de preocupaciones distinta a la reflejada en las perspectivas originales. Por lo tanto, las perspectivas adicionales, que aborden las preocupaciones de los componentes individuales y la síntesis ascendente del sistema, también pueden ser útiles. ^{[ 3 ]}

Una descripción de arquitectura es una representación de la arquitectura de un sistema en cualquier momento, en términos de sus componentes, cómo funcionan dichos componentes, las reglas y restricciones bajo las cuales funcionan, y cómo se relacionan entre sí y con el entorno. En una descripción de arquitectura, los datos de la arquitectura se comparten entre varias vistas y productos.

En la capa de datos se encuentran los elementos de datos de la arquitectura, junto con sus atributos y relaciones definitorias. En la capa de presentación se ubican los productos y las vistas, que proporcionan una representación visual para comunicar y comprender el propósito de la arquitectura, su descripción y los diversos análisis arquitectónicos realizados. Los productos permiten visualizar los datos de la arquitectura mediante representaciones gráficas, tabulares o textuales. Las vistas permiten visualizar datos de arquitectura provenientes de diferentes productos, organizándolos lógicamente para obtener una perspectiva específica u holística de la arquitectura.

El enfoque de tres esquemas para el modelado de datos, introducido en 1977, puede considerarse uno de los primeros modelos de vista. Es un enfoque para la construcción de sistemas de información y la gestión de la información de sistemas, que promueve el modelo conceptual como la clave para lograr la integración de datos . ^{[ 13 ]} El enfoque de tres esquemas define tres esquemas y vistas:

• Esquema externo para vistas de usuario
• El esquema conceptual integra esquemas externos
• Esquema interno que define las estructuras de almacenamiento físico.

En el centro, el esquema conceptual define la ontología de los conceptos tal como los usuarios los conciben y hablan de ellos. El esquema físico describe los formatos internos de los datos almacenados en la base de datos , y el esquema externo define la vista de los datos que se presentan a los programas de aplicación . ^{[ 14 ]} El marco intentó permitir el uso de múltiples modelos de datos para los esquemas externos. ^{[ 15 ]}

Con el paso de los años, la habilidad y el interés en la creación de sistemas de información han crecido enormemente. Sin embargo, en general, el enfoque tradicional para la creación de sistemas se ha centrado únicamente en la definición de datos desde dos perspectivas distintas: la del usuario y la del ordenador. Desde la perspectiva del usuario, que denominaremos «esquema externo», la definición de datos se da en el contexto de informes y pantallas diseñados para ayudar a las personas a realizar sus tareas específicas. La estructura de datos requerida desde la perspectiva del usuario cambia según el entorno empresarial y las preferencias individuales del usuario. Desde la perspectiva del ordenador, que denominaremos «esquema interno», los datos se definen en términos de estructuras de archivos para su almacenamiento y recuperación. La estructura de datos requerida para el almacenamiento informático depende de la tecnología informática específica empleada y de la necesidad de un procesamiento eficiente de los datos. ^{[ 16 ]}

4+1 es un modelo de vista diseñado por Philippe Kruchten en 1995 para describir la arquitectura de sistemas intensivos en software, basado en el uso de múltiples vistas concurrentes. ^{[ 17 ]} Las vistas se utilizan para describir el sistema desde el punto de vista de diferentes partes interesadas, como usuarios finales, desarrolladores y gerentes de proyecto. Las cuatro vistas del modelo son la vista lógica, la de desarrollo, la de proceso y la física:

Las cuatro vistas del modelo se refieren a  :

• Vista lógica : se centra en la funcionalidad que el sistema proporciona a los usuarios finales.
• Vista de desarrollo : ilustra un sistema desde la perspectiva de un programador y se centra en la gestión del software.
• Vista de procesos : aborda el aspecto dinámico del sistema, explica los procesos del sistema y cómo se comunican entre sí, y se centra en el comportamiento del sistema durante su ejecución.
• Vista física : describe el sistema desde el punto de vista de un ingeniero de sistemas. Se centra en la topología de los componentes de software en la capa física, así como en la comunicación entre estos componentes.

Además, se utilizan casos de uso o escenarios seleccionados para ilustrar la arquitectura. Por lo tanto, el modelo contiene 4+1 vistas. ^{[ 17 ]}

El marco de trabajo Zachman , concebido originalmente por John Zachman en IBM en 1987, es un marco para la arquitectura empresarial que proporciona una forma formal y altamente estructurada de visualizar y definir una empresa.

El marco se utiliza para organizar los "artefactos" arquitectónicos de manera que se tenga en cuenta tanto a quién va dirigido el artefacto (por ejemplo, el propietario del negocio y el constructor) como qué problema específico (por ejemplo, datos y funcionalidad) se está abordando. Estos artefactos pueden incluir documentos de diseño, especificaciones y modelos. ^{[ 19 ]}

El marco de Zachman se cita a menudo como un enfoque estándar para expresar los elementos básicos de la arquitectura empresarial . El gobierno federal de EE. UU. ha reconocido el marco de Zachman por haber  recibido «…aceptación mundial como un marco integrado para gestionar el cambio en las empresas y los sistemas que las respaldan». ^{[ 20 ]}

El Modelo de Referencia para Procesamiento Distribuido Abierto ( RM-ODP ) de la Organización Internacional de Normalización (ISO) ^{[ 21 ]} especifica un conjunto de puntos de vista para particionar el diseño de un sistema distribuido de software/hardware. Dado que la mayoría de los problemas de integración surgen en el diseño de dichos sistemas o en situaciones muy análogas, estos puntos de vista pueden resultar útiles para separar las preocupaciones de integración. Los puntos de vista del RM-ODP son: ^{[ 3 ]}

• La perspectiva empresarial , que se ocupa del propósito y los comportamientos del sistema en relación con el objetivo empresarial y los procesos de negocio de la organización.
• el punto de vista de la información , que se ocupa de la naturaleza de la información manejada por el sistema y las limitaciones en el uso e interpretación de esa información.
• el punto de vista computacional , que se ocupa de la descomposición funcional del sistema en un conjunto de componentes que exhiben comportamientos específicos e interactúan en las interfaces.
• el punto de vista de la ingeniería , que se ocupa de los mecanismos y funciones necesarios para soportar las interacciones de los componentes computacionales.
• el punto de vista tecnológico , que se ocupa de la elección explícita de tecnologías para la implementación del sistema, y ​​en particular para las comunicaciones entre los componentes.

RMODP define además un requisito para que un diseño contenga especificaciones de coherencia entre puntos de vista, incluyendo: ^{[ 3 ]}

• el uso de objetos y procesos empresariales en la definición de unidades de información
• el uso de objetos y comportamientos empresariales para especificar los comportamientos de los componentes computacionales, y el uso de las unidades de información para definir las interfaces computacionales.
• la asociación de decisiones de ingeniería con interfaces computacionales y requisitos de comportamiento
• la satisfacción de los requisitos de información, computación e ingeniería en las tecnologías elegidas.

El Marco de Arquitectura del Departamento de Defensa (DoDAF) define una forma estándar de organizar una arquitectura empresarial (EA) o una arquitectura de sistemas en vistas complementarias y coherentes. Es especialmente adecuado para sistemas grandes con complejos desafíos de integración e interoperabilidad, y aparentemente es único por su uso de " vistas operativas " que detallan el dominio operativo del cliente externo en el que operará el sistema en desarrollo.

El DoDAF define un conjunto de productos que actúan como mecanismos para visualizar, comprender y asimilar el amplio alcance y las complejidades de una descripción arquitectónica a través de medios gráficos, tabulares o textuales. Estos productos se organizan en cuatro vistas:

• Vista general (AV),
• Vista Operativa (VO),
• Vista de sistemas (VS) y la
• Vista de estándares técnicos (TV).

Cada vista representa ciertas perspectivas de una arquitectura, como se describe a continuación. Generalmente, solo se crea un subconjunto del conjunto completo de vistas de DoDAF para cada desarrollo de sistema. La figura representa la información que vincula la vista operativa , la vista de sistemas y servicios, y la vista de estándares técnicos. Las tres vistas y sus interrelaciones, impulsadas por elementos de datos de arquitectura comunes, proporcionan la base para derivar medidas como la interoperabilidad o el rendimiento, y para medir el impacto de los valores de estas métricas en la eficacia de la misión y la tarea operativas. ^{[ 22 ]}

En la arquitectura empresarial federal de EE. UU. , la arquitectura empresarial, de segmento y de solución proporciona diferentes perspectivas de negocio al variar el nivel de detalle y abordar preocupaciones relacionadas pero distintas. Así como las empresas están organizadas jerárquicamente, también lo están las diferentes vistas que proporciona cada tipo de arquitectura. La Guía de Prácticas de Arquitectura Empresarial Federal (2006) ha definido tres tipos de arquitectura: ^{[ 23 ]}

• Arquitectura empresarial,
• Arquitectura de segmentos y
• Arquitectura de la solución.

Por definición, la Arquitectura Empresarial (AE) se centra fundamentalmente en la identificación de activos comunes o compartidos, ya sean estrategias, procesos de negocio, inversiones, datos, sistemas o tecnologías. La AE se guía por la estrategia; ayuda a una agencia a determinar si sus recursos están debidamente alineados con su misión y sus objetivos estratégicos. Desde una perspectiva de inversión, la AE se utiliza para orientar las decisiones sobre la cartera de inversiones en TI en su conjunto. En consecuencia, los principales interesados ​​en la AE son los altos directivos y ejecutivos encargados de garantizar que la agencia cumpla su misión de la manera más eficaz y eficiente posible. ^{[ 23 ]}

Por el contrario, la arquitectura de segmentos define una hoja de ruta simple para un área de misión principal, un servicio empresarial o un servicio corporativo. La arquitectura de segmentos está impulsada por la gestión empresarial y ofrece productos que mejoran la prestación de servicios a los ciudadanos y al personal de la agencia. Desde una perspectiva de inversión, la arquitectura de segmentos impulsa las decisiones para un caso de negocio o un grupo de casos de negocio que respaldan un área de misión principal o un servicio común o compartido. Los principales interesados ​​en la arquitectura de segmentos son los propietarios y gerentes de negocios. La arquitectura de segmentos se relaciona con la arquitectura empresarial a través de tres principios: estructura, reutilización y alineación. Primero, la arquitectura de segmentos hereda el marco utilizado por la arquitectura empresarial, aunque puede extenderse y especializarse para satisfacer las necesidades específicas de un área de misión principal o un servicio común o compartido. Segundo, la arquitectura de segmentos reutiliza activos importantes definidos a nivel corporativo, incluidos: datos; procesos e inversiones comerciales comunes; y aplicaciones y tecnologías. Tercero, la arquitectura de segmentos se alinea con elementos definidos a nivel corporativo, como estrategias comerciales, mandatos, estándares y medidas de desempeño. ^{[ 23 ]}

En busca de un "Marco para modelar arquitecturas de sistemas espaciales", Peter Shames y Joseph Skipper (2006) definieron un "conjunto nominal de vistas", ^{[ 6 ]} Derivado de CCSDS RASDS, RM-ODP, ISO 10746 y conforme con IEEE 1471 .

Este conjunto de vistas, descrito a continuación, es una lista de posibles puntos de vista para el modelado. No todas estas vistas se utilizarán en un mismo proyecto, y se pueden definir otras según sea necesario. Cabe destacar que, para algunos análisis, se pueden combinar elementos de múltiples puntos de vista en una nueva vista, posiblemente mediante una representación por capas.

En una presentación posterior, este conjunto nominal de vistas se presentó como una Derivación Extendida del Modelo de Información Semántica RASDS. ^{[ 24 ]} Aquí, RASDS significa Arquitectura de Referencia para Sistemas de Datos Espaciales. Véase la segunda imagen.

Punto de vista empresarial ^{[ 6 ]}

• Vista organizacional: Incluye los elementos organizacionales , sus estructuras y relaciones. Puede incluir acuerdos, contratos, políticas e interacciones organizacionales.
• Vista de requisitos: describe los requisitos , metas y objetivos que impulsan el sistema. Indica lo que el sistema debe ser capaz de hacer.
• Vista de escenario: describe la forma en que se pretende utilizar el sistema (véase planificación de escenarios ). Incluye vistas de usuario y descripciones del comportamiento esperado del sistema.

Punto de vista de la información ^{[ 6 ]}

• Vista de metamodelo: una vista abstracta que define los elementos del modelo de información , sus estructuras y relaciones. Define las clases de datos que crea y gestiona el sistema y la arquitectura de datos.
• Vista de la información: describe los datos y la información tal como se obtienen y manipulan dentro del sistema. Los elementos de datos se definen mediante la vista del metamodelo y los objetos funcionales de otras vistas hacen referencia a ellos.

Punto de vista funcional ^{[ 6 ]}

• Vista de flujo de datos funcional: una vista abstracta que describe los elementos funcionales del sistema, sus interacciones, comportamiento, servicios proporcionados, restricciones y flujos de datos entre ellos. Define qué funciones puede realizar el sistema, independientemente de cómo se implementen realmente.
• Vista de control funcional: describe los flujos de control y las interacciones entre los elementos funcionales del sistema. Incluye las interacciones de control generales del sistema, las interacciones entre los elementos de control y los sensores/efectores, y las interacciones de gestión.

Punto de vista físico ^{[ 6 ]}

• Vista del sistema de datos: describe los instrumentos, las computadoras y los componentes de almacenamiento de datos, sus atributos del sistema de datos y los conectores de comunicación (buses, redes, enlaces punto a punto) que se utilizan en el sistema.
• Vista de telecomunicaciones: describe los componentes de telecomunicaciones (antena, transceptor), sus atributos y sus conectores (enlaces de radiofrecuencia u ópticos).
• Vista de navegación: describe el movimiento de los elementos principales del sistema (trayectoria, camino, órbita), incluyendo su interacción con elementos y fuerzas externas que están fuera del control del sistema, pero que deben modelarse junto con él para comprender su comportamiento (planetas, asteroides, presión solar, gravedad).
• Vista estructural: describe los componentes estructurales del sistema (bus del sistema de propulsión, puntales, paneles, articulación), sus atributos físicos y conectores, junto con los aspectos estructurales relevantes de otros componentes (masa, rigidez, fijación).
• Vista térmica: describe los componentes térmicos activos y pasivos del sistema (radiadores, enfriadores, rejillas de ventilación) y sus conectores (radiación física y en el espacio libre) y atributos, junto con las propiedades térmicas de otros componentes (por ejemplo, la antena como parasol).
• Vista de potencia: describe los componentes de potencia activos y pasivos del sistema (paneles solares, baterías, generadores termoeléctricos de radioisótopos) y sus conectores, junto con las propiedades de potencia de otros componentes (sistema de datos y elementos de propulsión como sumideros de potencia y paneles estructurales como plano de puesta a tierra).
• Vista de propulsión: describe los componentes de propulsión activos y pasivos del sistema (propulsores, giroscopios, motores, ruedas) y sus conectores, junto con las propiedades propulsoras de otros componentes.

Punto de vista de la ingeniería ^{[ 6 ]}

• Vista de asignación: describe la asignación de objetos funcionales a componentes físicos y computacionales diseñados dentro del sistema, permite el análisis del rendimiento y se utiliza para verificar el cumplimiento de los requisitos.
• Vista de software: Describe los aspectos de ingeniería de software del sistema, el diseño e implementación de la funcionalidad dentro de los componentes de software, la selección de lenguajes y bibliotecas, la definición de API y la transformación de objetos funcionales abstractos en elementos de software tangibles. Algunos elementos funcionales, descritos mediante un lenguaje de software, pueden implementarse como hardware (FPGA, ASIC).
• Vistas de hardware: Describen los aspectos de ingeniería de hardware del sistema, el diseño, la selección y la implementación de todos los componentes físicos que se ensamblarán en el sistema. Puede haber varias de estas vistas, cada una específica para una disciplina de ingeniería diferente.
• Vista del protocolo de comunicaciones: describe el diseño integral de los protocolos de comunicaciones y los servicios relacionados de transporte y gestión de datos, y muestra las pilas de protocolos tal como se implementan en cada uno de los componentes físicos del sistema.
• Vista de riesgos: describe los riesgos asociados con el diseño del sistema, los procesos y las tecnologías, y asigna atributos adicionales de evaluación de riesgos a otros elementos descritos en la arquitectura.
• Perspectiva de la ingeniería de control: analiza el sistema desde la perspectiva de su controlabilidad, la asignación de elementos en el sistema bajo control y el sistema de control.
• Vista de integración y pruebas: Analiza el sistema desde la perspectiva de lo que se debe hacer para ensamblar, integrar y probar el sistema, los subsistemas y los ensamblajes. Incluye la verificación de la funcionalidad adecuada, basada en escenarios, para el cumplimiento de los requisitos.
• Análisis IV&V: validación y verificación independientes de la funcionalidad y el correcto funcionamiento del sistema para satisfacer los requisitos. ¿El sistema, tal como fue diseñado y desarrollado, cumple con las metas y los objetivos?

Punto de vista tecnológico ^{[ 6 ]}

• Vista de estándares: define los estándares que se adoptarán durante el diseño del sistema (por ejemplo, protocolos de comunicación, tolerancia a la radiación, soldadura). Estos son, esencialmente, restricciones para los procesos de diseño e implementación.
• Vista de infraestructura: define los elementos de infraestructura que deben dar soporte al proceso de ingeniería, diseño y fabricación. Puede incluir elementos del sistema de datos (repositorios de diseño, marcos de trabajo, herramientas, redes) y elementos de hardware (fabricación de chips, instalación de vacío térmico, taller de mecanizado, laboratorio de pruebas de RF).
• Vista de Desarrollo y Evaluación Tecnológica: Incluye la descripción de programas de desarrollo tecnológico diseñados para producir algoritmos o componentes que puedan integrarse en un proyecto de desarrollo de sistemas. Incluye la evaluación de las propiedades de los componentes de hardware y software seleccionados para determinar si han alcanzado un nivel de madurez suficiente para su adopción en la misión prevista.

A diferencia de los modelos de vista enumerados anteriormente, este "conjunto nominal de vistas" enumera una amplia gama de vistas, posibles para desarrollar enfoques potentes y extensibles para describir una clase general de arquitecturas de sistemas intensivos en software. ^{[ 6 ]}