View model

A View model, or viewpoint model or view diagram in software engineering is framework which provides the viewpoints on the system and its environment. It is a graphical representation of the underlying semantics of a view.

Overview

The purpose of viewpoints and views is to enable human engineers to comprehend very complex systems, and to organize the elements of the problem and the solution around domains of expertise. In the engineering of physically-intensive systems, viewpoints often correspond to capabilities and responsibilities within the engineering organization.

Most complex system specifications are so extensive that no single individual can fully comprehend all aspects of the specifications. Furthermore, we all have different interests in a given system and different reasons for examining the system's specifications. 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. These viewpoints each satisfy an audience with interest in a particular set of aspects of the system. Associated with each viewpoint is a viewpoint language that optimizes the vocabulary and presentation for the audience of that viewpoint.

Viewpoint modeling has become an effective approach for dealing with the inherent complexity of large distributed systems. Current software architectural practices, as described in IEEE Std. 1471, divide the design activity into several areas of concerns, each one focusing on a specific aspect of the system. Examples include the "4+1" view model, the Zachman framework, TOGAF, DoDAF and, RM-ODP.

View model topics

Viewpoints

Viewpoint is a systems engineering concept that describes a partitioning of concerns in the characterization of a system. A viewpoint is an abstraction that yields a specification of the whole system restricted to a particular set of concerns. Adoption of a viewpoint is useful in separating and resolving a set of engineering concerns involved in integrating a set of components into a system. Adopting a viewpoint makes certain aspects of the system "visible" and focuses attention on them, while making other aspects "invisible," so that issues in those aspects can be addressed separately. A good selection of viewpoints also partitions the design of the system into specific areas of expertise.

Viewpoint model

In any given viewpoint, it is possible to make a model of the system that contains only the objects that are visible from that viewpoint, but also captures all of the objects, relationships and constraints that are present in the system and relevant to that viewpoint. Such a model is said to be a viewpoint model, or a view of the system from that viewpoint.

A given view is a specification for the system at a particular level of abstraction from a given viewpoint. Different levels of abstraction contain different levels of detail. Higher-level views allow the engineer to fashion and comprehend the whole design and identify and resolve problems in the large. Lower-level views allow the engineer to concentrate on a part of the design and develop the detailed specifications.

In the system itself, however, all of the specifications appearing in the various viewpoint models must be addressed in the realized components of the system. And the specifications for any given component may be drawn from many different viewpoints. On the other hand, the specifications induced by the distribution of functions over specific components and component interactions will typically reflect a different partitioning of concerns than that reflected in the original viewpoints. Thus additional viewpoints, addressing the concerns of the individual components and the bottom-up synthesis of the system, may also be useful.

Types of view models

4+1

4+1 is a view model designed by Philippe Kruchten in 1995 for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. The views are used to describe the system in the viewpoint of different stakeholders, such as end-users, developers and project managers. The four views of the model are logical, development, process and physical view. In addition selected use cases or scenarios are utilized to illustrate the architecture. Hence the model contains 4+1 views.

RM-ODP

The International Organization for Standardization (ISO) Reference Model for Open Distributed Processing (RM-ODP) specifies a set of viewpoints for partitioning 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

See also

• DoDAF
• Zachman framework,
• TOGAF

References

 This article incorporates public domain material from the National Institute of Standards and Technology