View model

[1][2] Since the early 1990s there have been a number of efforts to prescribe approaches for describing and analyzing system architectures.

The purpose of views and viewpoints is to enable humans to comprehend very complex systems, to organize the elements of the problem and the solution around domains of expertise and to separate concerns.

Viewpoint modeling has become an effective approach for dealing with the inherent complexity of large distributed systems.

Architecture description practices, as described in IEEE Std 1471-2000, utilize multiple views to address several areas of concerns, each one focusing on a specific aspect of the system.

Schoman in 1977 introduce the constructs context, viewpoint, and vantage point to organize the modeling process in systems requirements definition.

Subsequent work, such as IEEE 1471, preserved this distinction by utilizing two separate terms: viewpoint and view, respectively.

Since the early 1990s there have been a number of efforts to codify approaches for describing and analyzing system architectures.

Many of these have been funded by the United States Department of Defense, but some have sprung from international or national efforts in ISO or the IEEE.

Among these, the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE Std 1471-2000) established useful definitions of view, viewpoint, stakeholder and concern and guidelines for documenting a system architecture through the use of multiple views by applying viewpoints to address stakeholder concerns.

However, studies show that in practice, the added complexity of reconciling multiple views can undermine this advantage.

In the Zachman Framework views comprise a group of work products whose development requires a particular analytical and technical expertise because they focus on either the “what,” “how,” “who,” “where,” “when,” or “why” of the enterprise.

Higher-level views allow the engineer to fashion and comprehend the whole design and identify and resolve problems in the large.

Products provide a way for visualizing architecture data as graphical, tabular, or textual representations.

From the user view, which will be referred to as the “external schema,” the definition of data is in the context of reports and screens designed to aid individuals in doing their specific jobs.

The required structure of data from a usage view changes with the business environment and the individual preferences of the user.

From the computer view, which will be referred to as the “internal schema,” data is defined in terms of file structures for storage and retrieval.

To manage this scale and complexity, an Architecture Framework provides tools and methods that can bring the task into focus and allow valuable artifacts to be produced when they are most needed.

[19] The Zachman Framework is often referenced as a standard approach for expressing the basic elements of enterprise architecture.

The DoDAF defines a set of products that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through graphic, tabular, or textual means.

Consequently, the primary stakeholders of the EA are the senior managers and executives tasked with ensuring the agency fulfills its mission as effectively and efficiently as possible.

Segment architecture is driven by business management and delivers products that improve the delivery of services to citizens and agency staff.

First, segment architecture inherits the framework used by the EA, although it may be extended and specialized to meet the specific needs of a core mission area or common or shared service.

Second, segment architecture reuses important assets defined at the enterprise level including: data; common business processes and investments; and applications and technologies.

Third, segment architecture aligns with elements defined at the enterprise level, such as business strategies, mandates, standards, and performance measures.

[23] In search of "Framework for Modeling Space Systems Architectures" Peter Shames and Joseph Skipper (2006) defined a "nominal set of views",[6] Derived from CCSDS RASDS, RM-ODP, ISO 10746 and compliant with IEEE 1471.

Note that for some analyses elements from multiple viewpoints may be combined into a new view, possibly using a layered representation.

The TEAF Matrix of Views and Perspectives.
Illustration of the views, products and data in Architecture Framework.
The notion of a three-schema model was first introduced in 1977 by the ANSI/X3/SPARC three-level architecture , which determined three levels to model data. [ 12 ]
Illustration of the 4+1 view model or architecture.
Simplified illustration of the Zachman Framework with an explanation of the rows. [ 18 ] The original framework is more advanced, see for an example here .
The RM-ODP view model, which provides five generic and complementary viewpoints on the system and its environment.
DoDAF linkages among views. [ 22 ]
Federal Enterprise Architecture levels and attributes [ 23 ]
Illustration of the "Nominal set of views". [ 24 ]
Reference Architecture for Space Data Systems. [ 24 ]
MBED Top Level Ontology based on the Nominal set of views. [ 6 ]