Ver modelo

Editar artículo

Para otros usos, consulte Ver modelo (desambiguación).

La matriz de puntos de vista y perspectivas de TEAF.

Un modelo de vista o marco de puntos de vista en ingeniería de sistemas, ingeniería de software e ingeniería empresarial es un marco que define un conjunto coherente de vistas que se utilizará en la construcción de una arquitectura de sistema, arquitectura de software o arquitectura empresarial. Una vista es una representación de un sistema completo desde la perspectiva de un conjunto relacionado de preocupaciones.

Desde principios de la década de 1990, se han realizado varios esfuerzos para prescribir enfoques para describir y analizar arquitecturas de sistemas. Estos esfuerzos recientes definen un conjunto de puntos de vista (o puntos de vista). A veces se les denomina marcos de arquitectura o marcos de arquitectura empresarial, pero normalmente se denominan "modelos de vista".

Por lo general, una vista es un producto de trabajo que presenta datos de arquitectura específicos para un sistema dado. Sin embargo, el mismo término se usa a veces para referirse a una definición de vista, incluido el punto de vista particular y la guía correspondiente que define cada vista concreta. El término modelo de vista está relacionado con las definiciones de vista.

Contenido

1 Resumen
2 Historia
3 Ver temas del modelo
- 3.1 Ver
- 3.2 Miradores
- 3.3 Modelado de perspectivas
- 3.4 Modelo de punto de vista
- 3.5 Descripción de la arquitectura
4 tipos de modelos de vista del sistema
- 4.1 Enfoque de tres esquemas
- 4.2 Modelo de arquitectura de 4 + 1 vistas
5 tipos de vistas de arquitectura empresarial
- 5.1 Marco de Zachman
- 5.2 Vistas RM-ODP
- 5.3 vistas DoDAF
- 5.4 Vistas de la arquitectura empresarial federal
- 5.5 Conjunto nominal de vistas
6 Véase también
7 referencias
8 Enlaces externos

Visión de conjunto

El propósito de las opiniones y los puntos de vista es permitir que los humanos comprendan sistemas muy complejos, organicen los elementos del problema y la solución en torno a dominios de experiencia y separen preocupaciones. En la ingeniería de sistemas físicamente intensivos, los puntos de vista a menudo corresponden a capacidades y responsabilidades dentro de la organización de ingeniería.

La mayoría de las especificaciones del sistema complejas son tan extensas que ninguna persona puede comprender completamente todos los aspectos de las especificaciones. Por otra parte, todos tenemos intereses diferentes en un sistema dado y diferentes razones para examinar el sistema de 's especificaciones. Un ejecutivo de negocios hará diferentes preguntas sobre la estructura de un sistema de las que haría un implementador de sistemas. El concepto de marco de puntos de vista, por lo tanto, es proporcionar puntos de vista separados en la especificación de un sistema complejo dado para facilitar la comunicación con las partes interesadas. Cada punto de vista satisface a una audiencia con interés en un conjunto particular de aspectos del sistema. Cada punto de vista puede utilizar un lenguaje de punto de vista específico que optimiza el vocabulario y la presentación para la audiencia de ese punto de vista. El modelado de puntos de vista se ha convertido en un enfoque eficaz para hacer frente a la complejidad inherente de los grandes sistemas distribuidos.

Las prácticas de descripción de la arquitectura, como se describe en IEEE Std 1471-2000, utilizan múltiples vistas para abordar varias áreas de inquietudes, cada una de las cuales se enfoca en un aspecto específico del sistema. Ejemplos de marcos de arquitectura que utilizan múltiples vistas incluyen el modelo de vista "4 + 1" de Kruchten, el marco de Zachman, TOGAF, DoDAF y RM-ODP.

Historia

En la década de 1970, comenzaron a aparecer métodos en la ingeniería de software para modelar con múltiples vistas. Douglas T. Ross y KE Schoman en 1977 introducen el contexto de las construcciones, el punto de vista y el punto de vista para organizar el proceso de modelado en la definición de requisitos de sistemas. Según Ross y Schoman, un punto de vista "aclara qué aspectos se consideran relevantes para lograr... el propósito general [del modelo]" y determina ¿Cómo miramos [un tema que se está modelando]?

Como ejemplos de puntos de vista, el trabajo ofrece: Puntos de vista técnico, operativo y económico. En 1992, Anthony Finkelstein y otros publicaron un artículo muy importante sobre puntos de vista. En ese trabajo: "Se puede pensar en un punto de vista como una combinación de la idea de un" actor "," fuente de conocimiento "," rol "o" agente "en el proceso de desarrollo y la idea de una" vista "o" perspectiva ”Que sostiene un actor”. Una idea importante en este artículo fue distinguir "un estilo de representación, el esquema y notación por los cuales el punto de vista expresa lo que puede ver" y "una especificación, las declaraciones expresadas en el estilo del punto de vista que describen dominios particulares". El trabajo posterior, como IEEE 1471, conservó esta distinción utilizando dos términos separados: punto de vista y vista, respectivamente.

Desde principios de la década de 1990, se han realizado varios esfuerzos para codificar enfoques para describir y analizar arquitecturas de sistemas. Suelen denominarse marcos de arquitectura o, a veces, conjuntos de puntos de vista. Muchos de estos han sido financiados por el Departamento de Defensa de los Estados Unidos, pero algunos han surgido de esfuerzos internacionales o nacionales en ISO o IEEE. Entre estos, la práctica recomendada de IEEE para la descripción arquitectónica de sistemas intensivos en software ( IEEE Std 1471-2000 ) estableció definiciones útiles de vista, punto de vista, partes interesadas y preocupaciones y pautas para documentar una arquitectura de sistema mediante el uso de múltiples vistas aplicando puntos de vista abordar las preocupaciones de las partes interesadas. La ventaja de las opiniones múltiples es que los requisitos ocultos y los desacuerdos de las partes interesadas se pueden descubrir más fácilmente. Sin embargo, los estudios muestran que, en la práctica, la complejidad adicional de conciliar múltiples vistas puede socavar esta ventaja.

IEEE 1471 (ahora ISO / IEC / IEEE 42010: 2011, Ingeniería de sistemas y software - Descripción de la arquitectura) prescribe el contenido de las descripciones de la arquitectura y describe su creación y uso en una serie de escenarios, incluido el diseño, el diseño evolutivo y la captura con y sin precedentes. de diseño de sistemas existentes. En todos estos escenarios, el proceso general es el mismo: identificar a las partes interesadas, suscitar preocupaciones, identificar un conjunto de puntos de vista que se utilizarán y luego aplicar estas especificaciones de puntos de vista para desarrollar el conjunto de puntos de vista relevantes para el sistema de interés. En lugar de definir un conjunto particular de puntos de vista, el estándar proporciona mecanismos y requisitos uniformes para que los arquitectos y las organizaciones definan sus propios puntos de vista. En 1996 se publicó el Modelo de referencia ISO para el procesamiento distribuido abierto ( RM-ODP ) para proporcionar un marco útil para describir la arquitectura y el diseño de sistemas distribuidos a gran escala.

Ver temas del modelo

Ver

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 con respecto al sistema, que suprime detalles para proporcionar un modelo simplificado que tiene solo aquellos elementos relacionados con las preocupaciones del punto de vista. Por ejemplo, un punto de vista de seguridad se enfoca en preocupaciones de seguridad y un modelo de punto de vista de seguridad contiene aquellos elementos que están relacionados con la seguridad de un modelo más general de un sistema.

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ía, etc. que utilizan una pieza de información en particular, mientras que la Vista de organización puede presentar todas las funciones, tecnología e información de interés 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 particular porque se centran en el "qué", "cómo", "quién", "dónde", "cuándo" o "por qué" de la empresa. Por ejemplo, los productos de trabajo de Functional View responden a la pregunta "¿cómo se lleva a cabo la misión?" Los expertos en descomposición funcional los desarrollan más fácilmente 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 lo que respecta a las funciones.

Miradores

En la ingeniería de sistemas, un punto de vista es una división o restricción de preocupaciones en un sistema. La adopción de un punto de vista es útil para que los problemas en esos aspectos se puedan abordar por separado. Una buena selección de puntos de vista también divide el diseño del sistema en áreas específicas de experiencia.

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 todo un sistema desde la perspectiva de un punto de vista. Una vista puede constar de uno o más modelos arquitectónicos. 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.

Modelado de perspectivas

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

En los sistemas de información, la forma tradicional de dividir las perspectivas de modelado es distinguir las perspectivas estructural, funcional y conductual / procesual. Esto, junto con las perspectivas de reglas, objetos, comunicación y actores y roles, es una forma de clasificar los enfoques de modelado.

Modelo de punto de vista

En cualquier punto de vista dado, es posible hacer un modelo del sistema que contiene solo los objetos que son visibles desde ese punto de vista, pero también captura todos los objetos, relaciones y restricciones que están presentes en el sistema y son relevantes para ese punto de vista. Se dice que tal modelo es un modelo de punto de vista, o una vista del sistema desde ese punto de vista.

Una vista dada es una especificación para el sistema en un nivel particular de abstracción desde un punto de vista dado. Los diferentes niveles de abstracción contienen diferentes niveles de detalle. Las vistas de nivel superior permiten al ingeniero diseñar y comprender todo el diseño e identificar y resolver problemas en general. Las vistas de nivel inferior permiten al ingeniero concentrarse en una parte del diseño y desarrollar las especificaciones detalladas.

Ilustración de las vistas, productos y datos en Architecture Framework.

En el propio sistema, sin embargo, todas las especificaciones que aparecen en los diversos modelos de puntos de vista deben abordarse en los componentes realizados del sistema. Y las especificaciones para cualquier componente dado pueden extraerse de muchos puntos de vista diferentes. Por otro lado, las especificaciones inducidas por la distribución de funciones sobre componentes específicos e interacciones entre componentes reflejarán típicamente una división de preocupaciones diferente a la reflejada en los puntos de vista originales. Por lo tanto, también pueden ser útiles puntos de vista adicionales que aborden las preocupaciones de los componentes individuales y la síntesis ascendente del sistema.

Descripción de la arquitectura

Una descripción de arquitectura es una representación de la arquitectura de un sistema, en cualquier momento, en términos de sus partes componentes, cómo funcionan esas partes, las reglas y restricciones bajo las cuales funcionan esas partes y cómo esas partes se relacionan entre sí y con el entorno. En una descripción de la 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 y sus atributos y relaciones que los definen. En la capa de presentación se encuentran los productos y las vistas que respaldan un medio visual para comunicar y comprender el propósito de la arquitectura, lo que describe y los diversos análisis arquitectónicos realizados. Los productos proporcionan una forma de visualizar datos de arquitectura como representaciones gráficas, tabulares o textuales. Las vistas brindan la capacidad de visualizar datos de arquitectura que se derivan de productos, organizando lógicamente los datos para una perspectiva específica u holística de la arquitectura.

Tipos de modelos de vista del sistema

Enfoque de tres esquemas

La noción de un modelo de tres esquemas fue introducida por primera vez en 1977 por la arquitectura de tres niveles ANSI / X3 / SPARC, que determinaba tres niveles para modelar los datos.

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 sistemas de gestión de la información, que promueve el modelo conceptual como clave para lograr la integración de datos. 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 piensan y hablan. 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 presentados a los programas de aplicación. El marco intentó permitir el uso de múltiples modelos de datos para esquemas externos.

A lo largo de los años, la habilidad y el interés en la construcción de sistemas de información ha crecido enormemente. Sin embargo, en su mayor parte, el enfoque tradicional de los sistemas de construcción solo se ha centrado en definir datos desde dos vistas distintas, la "vista del usuario" y la "vista por computadora". Desde la vista del usuario, que se denominará el "esquema externo", la definición de datos está en el contexto de informes y pantallas diseñadas para ayudar a las personas a realizar sus trabajos específicos. La estructura requerida de los datos de una vista de uso cambia con el entorno empresarial y las preferencias individuales del usuario. Desde la vista de la computadora, que se denominará "esquema interno", los datos se definen en términos de estructuras de archivos para el almacenamiento y la recuperación. La estructura de datos necesaria para el almacenamiento informático depende de la tecnología informática específica empleada y de la necesidad de un procesamiento eficaz de los datos.

Modelo de arquitectura 4 + 1 vistas

Ilustración del modelo o arquitectura de 4 + 1 vistas.

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. Las vistas se utilizan para describir el sistema desde el punto de vista de diferentes partes interesadas, como usuarios finales, desarrolladores y directores de proyectos. Las cuatro vistas del modelo son lógica, desarrollo, proceso y vista física:

Las cuatro vistas del modelo se refieren a:

Vista lógica: se ocupa de la funcionalidad que el sistema proporciona a los usuarios finales.
Vista de desarrollo: ilustra un sistema desde la perspectiva de un programador y se ocupa de la gestión de software.
Vista de procesos: se ocupa del aspecto dinámico del sistema, explica los procesos del sistema y cómo se comunican, y se centra en el comportamiento en tiempo de ejecución del sistema.
Vista física: describe el sistema desde el punto de vista de un ingeniero de sistemas. Se ocupa de la topología de los componentes de software en la capa física, así como de 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 vistas 4 + 1.

Tipos de vistas de arquitectura empresarial

El marco de la arquitectura empresarial define cómo organizar la estructura y las vistas asociadas con una arquitectura empresarial. Debido a que la disciplina de Arquitectura e Ingeniería Empresarial es tan amplia, y debido a que las empresas pueden ser grandes y complejas, los modelos asociados con la disciplina también tienden a ser grandes y complejos. Para administrar esta escala y complejidad, un marco de arquitectura proporciona herramientas y métodos que pueden enfocar la tarea y permitir que se produzcan artefactos valiosos cuando más se necesitan.

Los marcos de arquitectura se utilizan comúnmente en la tecnología de la información y el gobierno de los sistemas de información. Una organización puede querer exigir que se produzcan ciertos modelos antes de que se pueda aprobar el diseño de un sistema. De manera similar, es posible que deseen especificar que se utilicen ciertas vistas en la documentación de los sistemas adquiridos; el Departamento de Defensa de los EE. UU. Estipula que los proveedores de equipos proporcionarán vistas específicas de DoDAF para proyectos de capital por encima de cierto valor.

Marco de Zachman

Ilustración simplificada de Zachman Framework con una explicación de las filas. El marco original es más avanzado, vea un ejemplo aquí.

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

El marco se utiliza para organizar "artefactos" arquitectónicos de una manera que tiene en cuenta a quién se dirige el artefacto (por ejemplo, propietario y constructor de la empresa) y qué problema particular (por ejemplo, datos y funcionalidad) se está abordando. Estos artefactos pueden incluir documentos de diseño, especificaciones y modelos.

A menudo, se hace referencia a Zachman Framework como un enfoque estándar para expresar los elementos básicos de la arquitectura empresarial. El Zachman Framework ha sido reconocido por el gobierno federal de los EE. UU. Por haber "... recibido aceptación mundial como un marco integrado para gestionar el cambio en las empresas y los sistemas que las respaldan".

Vistas de RM-ODP

El modelo de vista RM-ODP, que proporciona cinco puntos de vista genéricos y complementarios sobre el sistema y su entorno.

El modelo de referencia de la Organización Internacional de Normalización (ISO) para el procesamiento distribuido abierto ( RM-ODP ) especifica un conjunto de puntos de vista para dividir el diseño de un sistema de software / hardware distribuido. Dado que la mayoría de los problemas de integración surgen en el diseño de tales sistemas o en situaciones muy análogas, estos puntos de vista pueden resultar útiles para separar los problemas de integración. Los puntos de vista de RMODP son:

el punto de vista de la empresa, que se ocupa del propósito y los comportamientos del sistema en lo que respecta al objetivo comercial y los procesos comerciales 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 restricciones sobre 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 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, que incluyen:

el uso de objetos y procesos empresariales en la definición de unidades de información
el uso de objetos y comportamientos empresariales al especificar los comportamientos de los componentes computacionales, y el uso de las unidades de información al definir interfaces computacionales
la asociación de opciones 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

Vistas DoDAF

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

Vínculos DoDAF entre vistas.

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

Vista general general (AV),
Vista operativa (OV),
Vista de sistemas (SV) y
Vista de estándares técnicos (TV).

Cada vista muestra ciertas perspectivas de una arquitectura como se describe a continuación. Por lo general, solo se crea un subconjunto del conjunto de vistas DoDAF completo 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 común - proporcionan la base para derivar medidas como la interoperabilidad o el desempeño, y para medir el impacto de los valores de estas métricas en la misión operativa y la efectividad de la tarea.

Vistas de la arquitectura empresarial federal

En la arquitectura empresarial federal de EE. UU., La arquitectura empresarial, de segmento y de solución proporciona diferentes perspectivas comerciales 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 ofrece cada tipo de arquitectura. La Federal Enterprise Architecture Practice Guidance (2006) ha definido tres tipos de arquitectura:

Niveles y atributos de la arquitectura empresarial federal

Arquitectura empresarial,
Arquitectura de segmentos y
Arquitectura de soluciones.

Por definición, la Arquitectura Empresarial (EA) se ocupa fundamentalmente de identificar activos comunes o compartidos, ya sean estrategias, procesos comerciales, inversiones, datos, sistemas o tecnologías. EA está impulsado por la estrategia; ayuda a una agencia a identificar si sus recursos están correctamente alineados con la misión de la agencia y las metas y objetivos estratégicos. Desde una perspectiva de inversión, EA se utiliza para impulsar decisiones sobre la cartera de inversiones de TI en su conjunto. En consecuencia, las principales partes interesadas de la EA 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.

Por el contrario, la arquitectura de segmento define una hoja de ruta simple para un área de misión central, un servicio comercial o un servicio empresarial. La arquitectura del segmento 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 segmento impulsa las decisiones para un caso de negocio o grupo de casos de negocio que respaldan un área de misión central o un servicio común o compartido. Los principales interesados en la arquitectura del segmento son los propietarios y gerentes de empresas. La arquitectura de segmentos está relacionada con la EA a través de tres principios: estructura, reutilización y alineación. En primer lugar, la arquitectura de segmento hereda el marco utilizado por el EA, aunque puede ampliarse y especializarse para satisfacer las necesidades específicas de un área de misión central o un servicio común o compartido. En segundo lugar, la arquitectura del segmento reutiliza activos importantes definidos a nivel empresarial, que incluyen: datos; inversiones y procesos comerciales comunes; y aplicaciones y tecnologías. En tercer lugar, la arquitectura del segmento se alinea con elementos definidos a nivel empresarial, como estrategias comerciales, mandatos, estándares y medidas de desempeño.

Conjunto nominal de vistas

En busca de un "Marco para modelar arquitecturas de sistemas espaciales", Peter Shames y Joseph Skipper (2006) definieron un "conjunto nominal de vistas", derivado de CCSDS RASDS, RM-ODP, ISO 10746 y compatible con IEEE 1471.

Ilustración del "Conjunto de vistas nominal".

Este "conjunto de vistas", como se describe a continuación, es una lista de posibles puntos de vista de modelado. No todas estas vistas se pueden utilizar para un proyecto y se pueden definir otras vistas según sea necesario. Tenga en cuenta que para algunos análisis, los elementos de múltiples puntos de vista se pueden combinar en una nueva vista, posiblemente usando una representación en capas.

En una última presentación, este conjunto nominal de puntos de vista se presentó como una derivación del modelo de información semántica RASDS extendido. Por la presente, RASDS significa Arquitectura de referencia para sistemas de datos espaciales. ver segunda imagen.

Punto de vista empresarial

Vista de organización: incluye elementos organizativos y 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. Dice lo que el sistema debe poder hacer.
Vista de escenario: describe la forma en que se pretende utilizar el sistema; consulte la planificación de escenarios. Incluye vistas del usuario y descripciones de cómo se espera que se comporte el sistema.

Mirador de información

Vista de metamodelo: una vista abstracta que define los elementos del modelo de información y sus estructuras y relaciones. Define las clases de datos que crea y administra el sistema y la arquitectura de datos.
Vista de información: describe los datos y la información reales a medida que se obtienen y manipulan dentro del sistema. Los elementos de datos están definidos por la vista del metamodelo y se refieren a ellos mediante objetos funcionales en otras vistas.

Arquitectura de referencia para sistemas de datos espaciales.

Mirador funcional

Vista de flujo de datos funcional: una vista abstracta que describe los elementos funcionales del sistema, sus interacciones, comportamiento, servicios prestados, restricciones y flujos de datos entre ellos. Define qué funciones es capaz de realizar el sistema, independientemente de cómo se implementen realmente estas funciones.
Vista de control funcional: describe los flujos de control y las interacciones entre los elementos funcionales dentro del sistema. Incluye interacciones generales de control del sistema, interacciones entre elementos de control y elementos de sensor / efector e interacciones de gestión.

Mirador físico

Vista del sistema de datos: describe los instrumentos, computadoras y componentes de almacenamiento de datos, sus atributos del sistema de datos y los conectores de comunicaciones (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 (RF o enlaces ópticos).
Vista de navegación: describe el movimiento de los elementos principales dentro del sistema (trayectoria, trayectoria, órbita), incluida su interacción con elementos externos y fuerzas que están fuera del control del sistema, pero que deben modelarse con él para comprender el comportamiento del sistema. (planetas, asteroides, presión solar, gravedad)
Vista estructural: describe los componentes estructurales del sistema (barra s / c, puntales, paneles, articulación), sus atributos físicos y conectores, junto con los aspectos estructurales relevantes de otros componentes (masa, rigidez, unión).
Vista térmica: describe los componentes térmicos activos y pasivos del sistema (radiadores, refrigeradores, ventilaciones) y sus conectores (radiación física y del espacio libre) y atributos, junto con las propiedades térmicas de otros componentes (es decir, la antena como parasol).
Vista de energía: describe los componentes de energía activos y pasivos del sistema (paneles solares, baterías, RTG) dentro del sistema y sus conectores, junto con las propiedades de energía de otros componentes (sistema de datos y elementos de propulsión como sumideros de energía y paneles estructurales como conexión a tierra avión)
Vista de propulsión: describe los componentes de propulsión activos y pasivos del sistema (propulsores, giroscopios, motores, ruedas) dentro del sistema y sus conectores, junto con las propiedades de propulsión de otros componentes.

Ontología de nivel superior MBED basada en el conjunto nominal de vistas.

Mirador de ingeniería

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 la satisfacción de los requisitos.
Vista de software: describe los aspectos de ingeniería de software del sistema, el diseño de software y la implementación de la funcionalidad dentro de los componentes de software, selecciona los lenguajes y bibliotecas que se utilizarán, define las API, realiza la ingeniería 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: describe los aspectos de ingeniería de hardware del sistema, diseño de hardware, selección e implementación de todos los componentes físicos que se ensamblarán en el sistema. Puede haber muchos de estos puntos de vista, cada uno específico de una disciplina de ingeniería diferente.
Vista de protocolo de comunicaciones: describe el diseño de extremo a extremo de los protocolos de comunicaciones y los servicios de gestión y transporte de datos relacionados, muestra las pilas de protocolos a medida que se implementan en cada uno de los componentes físicos del sistema.
Vista de riesgos: describe los riesgos asociados con el diseño, los procesos y las tecnologías del sistema, asigna atributos de evaluación de riesgos adicionales a otros elementos descritos en la arquitectura.
Vista Ingeniería de control: analiza el sistema desde la perspectiva de su capacidad de control, asignación de elementos en el sistema bajo control y sistema de control.
Vista de integración y prueba: observa 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, impulsada por escenarios, en cumplimiento de los requisitos.
Vista IVamp;V: validación y verificación independientes de la funcionalidad y el funcionamiento adecuado del sistema en cumplimiento de los requisitos. ¿El sistema, tal como fue diseñado y desarrollado, cumple con las metas y los objetivos?

Punto de vista tecnológico

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). Se trata esencialmente de limitaciones en los procesos de diseño e implementación.
Vista de infraestructura: define los elementos de infraestructura que deben respaldar el proceso de ingeniería, diseño y fabricación. Puede incluir elementos del sistema de datos (repositorios de diseño, marcos, herramientas, redes) y elementos de hardware (fabricación de chips, instalación de vacío térmico, taller de máquinas, laboratorio de pruebas de RF)
Vista de evaluación y desarrollo de tecnología: incluye una descripción de los programas de desarrollo de tecnología diseñados para producir algoritmos o componentes que pueden incluirse en un proyecto de desarrollo de sistemas. Incluye la evaluación de las propiedades de componentes de hardware y software seleccionados para determinar si están en un estado de madurez suficiente para ser adoptados para la misión que se está diseñando.

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 intensivas en software.

Ver también

Referencias

Atribución

Este artículo incorpora material de dominio público del sitio web del Instituto Nacional de Estándares y Tecnología https://www.nist.gov.

enlaces externos

Medios relacionados con Ver modelos en Wikimedia Commons