ビュー・モデル
エンタープライズアーキテクチャビュー・モデルのタイプ > ビューの名目セット

In search of "Framework for Modeling Space Systems Architectures" Peter Shames and Joseph Skipper (2006) defined a "nominal set of views", Derived from CCSDS RASDS, RM-ODP, ISO 10746 and compliant with IEEE 1471.
This "set of views", as described below, is a listing of possible modeling viewpoints. Not all of these views may be used for any one project and other views may be defined as necessary. Note that for some analyses elements from multiple viewpoints may be combined into a new view, possibly using a layered representation.
In a latter presentation this nominal set of views was presented as an Extended RASDS Semantic Information Model Derivation. Hereby RASDS stands for Reference Architecture for Space Data Systems. see second image.
Organization view – Includes organizational elements and their structures and relationships. May include agreements, contracts, policies and organizational interactions.
Requirements view – Describes the requirements, goals, and objectives that drive the system. Says what the system must be able to do.
Scenario view – Describes the way that the system is intended to be used, see scenario planning. Includes user views and descriptions of how the system is expected to behave.
Metamodel view – An abstract view that defines information model elements and their structures and relationships. Defines the classes of data that are created and managed by the system and the data architecture.
Information view – Describes the actual data and information as it is realized and manipulated within the system. Data elements are defined by the metamodel view and they are referred to by functional objects in other views.
Functional Dataflow view – An abstract view that describes the functional elements in the system, their interactions, behavior, provided services, constraints and data flows among them. Defines which functions the system is capable of performing, regardless of how these functions are actually implemented.
Functional Control view – Describes the control flows and interactions among functional elements within the system. Includes overall system control interactions, interactions between control elements and sensor / effector elements and management interactions.
Data System view – Describes instruments, computers, and data storage components, their data system attributes and the communications connectors (busses, networks, point to point links) that are used in the system.
Telecomm view – Describes the telecomm components (antenna, transceiver), their attributes and their connectors (RF or optical links).
Navigation view – Describes the motion of the major elements within the system (trajectory, path, orbit), including their interaction with external elements and forces that are outside of the control of the system, but that must be modeled with it to understand system behavior (planets, asteroids, solar pressure, gravity)
Structural view – Describes the structural components in the system (s/c bus, struts, panels, articulation), their physical attributes and connectors, along with the relevant structural aspects of other components (mass, stiffness, attachment)
Thermal view – Describes the active and passive thermal components in the system (radiators, coolers, vents) and their connectors (physical and free space radiation) and attributes, along with the thermal properties of other components (i.e. antenna as sun shade)
Power view – Describes the active and passive power components in the system (solar panels, batteries, RTGs) within the system and their connectors, along with the power properties of other components (data system and propulsion elements as power sinks and structural panels as grounding plane)
Propulsion view – Describes the active and passive propulsion components in the system (thrusters, gyros, motors, wheels) within the system and their connectors, along with the propulsive properties of other components
Allocation view – Describes the allocation of functional objects to engineered physical and computational components within the system, permits analysis of performance and used to verify satisfaction of requirements
Software view - Describes the software engineering aspects of the system, software design and implementation of functionality within software components, select languages and libraries to be used, define APIs, do the engineering of abstract functional objects into tangible software elements. Some functional elements, described using a software language, may actually be implemented as hardware (FPGA, ASIC)
Hardware views – Describes the hardware engineering aspects of the system, hardware design, selection and implementation of all of the physical components to be assembled into the system. There may be many of these views, each specific to a different engineering discipline.
Communications Protocol view – Describes the end to end design of the communications protocols and related data transport and data management services, shows the protocol stacks as they are implemented on each of the physical components of the system.
Risk view – Describes the risks associated with the system design, processes, and technologies, assigns additional risk assessment attributes to other elements described in the architecture
Control Engineering view - Analyzes system from the perspective of its controllability, allocation of elements into system under control and control system
Integration and Test view – Looks at the system from the perspective of what must be done to assemble, integrate and test system and sub-systems, and assemblies. Includes verification of proper functionality, driven by scenarios, in satisfaction of requirements.
IV&V view – independent validation and verification of functionality and proper operation of the system in satisfaction of requirements. Does system as designed and developed meet goals and objectives.
Standards view – Defines the standards to be adopted during design of the system (e.g. communication protocols, radiation tolerance, soldering). These are essentially constraints on the design and implementation processes.
Infrastructure view – Defines the infrastructure elements that are to support the engineering, design, and fabrication process. May include data system elements (design repositories, frameworks, tools, networks) and hardware elements (chip fabrication, thermal vacuum facility, machine shop, RF testing lab)
Technology Development & Assessment view – Includes description of technology development programs designed to produce algorithms or components that may be included in a system development project. Includes evaluation of properties of selected hardware and software components to determine if they are at a sufficient state of maturity to be adopted for the mission being designed.
In contrast to the previous listed view models, this "nominal set of views" lists a whole range of  views, possible to develop powerful and extensible approaches for describing a general class of software intensive system architectures.
3層スキーマ・モデルの表記は、1977年にデータをモデル化するための3つのレベルを決めたANSI/X3/SPARC three level architectureによって最初に紹介された。
4+1アーキテクチャビュー・モデル（英語版）
横行の解説を持つZachmanフレームワークの単純化された描画 オリジナルなフレームワークは、
より高度である、 ここの例を見よ。
システムとその環境への5つの一般的かつ補完的視点を提供する、RM-ODPビュー・モデル 。
DoDAFのビュー間の連携。
連邦エンタープライズアーキテクチャのレベルと特質
Illustration of the "Nominal set of views".
Reference Architecture for Space Data Systems.
MBED Top Level Ontology based on the Nominal set of views.