Before you start reading about open distributed processing approach, you may need to understand the view model.

Reference:

The main content and all the images used in this page are from the wikipedia, "View model".


Let's start with the definition: "A view is a representation of a whole system from the perspective of a related set of concern".

Imagine we have very complex systems (e.g. distributed and interconnected systems). Naturally, management of such complex systems needs to comprehensively understand how these systems work individually and together. we need to organise the elements of the problem and solutions and separate the different concerns. We cannot simply look at the system from one perspective or domains. Exactly, here is the place that "view model" steps in. The purpose of views and viewpoints is to enable humans to comprehend very complex systems and to manage it in an efficient and productive approach.

Digging more into this, we see that this is not only technical difficulties or complexity that we have, but the complexity originated from the fact that we all have different interests in a give system. For example a business executive will ask different questions of a system make-up than would a system implementer. The concept of viewpoints framework, therefore, is to provide separate viewpoints into the specification of a given complex system in order to facilitate communication with the stakeholders. Each viewpoint satisfies an audience with interest in a particular set of aspects of the system. Each viewpoint may use a specific viewpoint language that optimizes the vocabulary and presentation for the audience of that viewpoint.

A view of a system is a representation of the system from the perspective of a viewpoint.This viewpoint on a system involves a perspective focusing on specific concerns regarding the system, which suppresses details to provide a simplified model having only those elements related to the concerns of the viewpoint. For example, a security viewpoint focuses on security concerns and a security viewpoint model contains those elements that are related to security from a more general model of a system. The advantage of multiple views is that hidden requirements and stakeholder disagreements can be discovered more readily, which itself turn to be an additional complexity for the management of the system.

Viewpoint modeling has become an effective approach for dealing with the inherent complexity of large distributed systems. The examples framework which uses the different viewpoints Kruchten's "4+1" view model, the Zachman Framework, TOGAF, DoDAF, RM-ODP, and Hamdaqa's "5+1" view model. Here we only focues on three of these examples.

Read more:

If you are interested to know more about view model and its examples check the wikipeda on "View model".

The Department of Defense Architecture Framework (DoDAF) defines a standard way to organize an enterprise architecture (EA) or systems architecture into complementary and consistent views. It is especially suited to large systems with complex integration and interoperability challenges, and is apparently unique in its use of "operational views" detailing the external customer's operating domain in which the developing system will operate.

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. These products are organized under four views:

  • Overarching All View (AV),
  • Operational View (OV),
  • Systems View (SV), and the
  • Technical Standards View (TV).

Each view depicts certain perspectives of an architecture as described below. Only a subset of the full DoDAF viewset is usually created for each system development. The figure represents the information that links the operational view, systems and services view, and technical standards view. The three views and their interrelationships driven – by common architecture data elements – provide the basis for deriving measures such as interoperability or performance, and for measuring the impact of the values of these metrics on operational mission and task effectiveness.

In the US Federal Enterprise Architecture enterprise, segment, and solution architecture provide different business perspectives by varying the level of detail and addressing related but distinct concerns. Just as enterprises are themselves hierarchically organized, so are the different views provided by each type of architecture. The Federal Enterprise Architecture Practice Guidance (2006) has defined three types of architecture:

  • Enterprise architecture,
  • Segment architecture, and
  • Solution architecture.

By definition, Enterprise Architecture (EA) is fundamentally concerned with identifying common or shared assets – whether they are strategies, business processes, investments, data, systems, or technologies. EA is driven by strategy; it helps an agency identify whether its resources are properly aligned to the agency mission and strategic goals and objectives. From an investment perspective, EA is used to drive decisions about the IT investment portfolio as a whole. 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.

By contrast, segment architecture defines a simple roadmap for a core mission area, business service, or enterprise service. Segment architecture is driven by business management and delivers products that improve the delivery of services to citizens and agency staff. From an investment perspective, segment architecture drives decisions for a business case or group of business cases supporting a core mission area or common or shared service. The primary stakeholders for segment architecture are business owners and managers. Segment architecture is related to EA through three principles: structure, reuse, and alignment. 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.

Rather than define a particular set of viewpoints, the standard provides uniform mechanisms and requirements for architects and organizations to define their own viewpoints. In 1996 the ISO Reference Model for Open Distributed Processing (RM-ODP) was published to provide a useful framework for describing the architecture and design of large-scale distributed systems.

The RM-ODP view model, which provides five generic and complementary viewpoints on the system and its environment. This set of viewpoints is in order to partition the design of a distributed software/hardware system. Since most integration problems arise in the design of such systems or in very analogous situations, these viewpoints may prove useful in separating integration concerns. The RMODP viewpoints are:

  • the enterprise viewpoint, which is concerned with the purpose and behaviors of the system as it relates to the business objective and the business processes of the organization
  • the information viewpoint, which is concerned with the nature of the information handled by the system and constraints on the use and interpretation of that information
  • the computational viewpoint, which is concerned with the functional decomposition of the system into a set of components that exhibit specific behaviors and interact at interfaces
  • the engineering viewpoint, which is concerned with the mechanisms and functions required to support the interactions of the computational components
  • the technology viewpoint, which is concerned with the explicit choice of technologies for the implementation of the system, and particularly for the communications among the components

RMODP further defines a requirement for a design to contain specifications of consistency between viewpoints, including:

  • the use of enterprise objects and processes in defining information units
  • the use of enterprise objects and behaviors in specifying the behaviors of computational components, and use of the information units in defining computational interfaces
  • the association of engineering choices with computational interfaces and behavior requirements
  • the satisfaction of information, computational and engineering requirements in the chosen technologies




  • Keine Stichwörter