This chapter is from the book
This chapter is from the book
This chapter is from the book
Viewpoints
It would be hard work if every time you were creating a view of your architecture you had to go back to first principles to define what should go into it. Fortunately, you don’t quite have to do that.
In his introductory paper, Philippe Kruchten defined four standard views, namely, Logical, Process, Physical, and Development. The IEEE standard made this idea generic (and did not specify one set of views or another) by proposing the concept of a viewpoint.
The objective of the viewpoint concept is an ambitious one—no less than making available a library of templates and patterns that can be used off the shelf to guide the creation of an architectural view that can be inserted into an AD. We define a viewpoint (again after IEEE Standard 1471) as follows.
Definition
A viewpoint is a collection of patterns, templates, and conventions for constructing one type of view. It defines the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template models for constructing its views.
Architectural viewpoints provide a framework for capturing reusable architectural knowledge that can be used to guide the creation of a particular type of (partial) AD. You may find it helpful to compare the relationship between viewpoints and views to the relationship between classes and objects in object-oriented development.
- A class definition provides a template for the construction of an object. An object-oriented system will include at runtime a number of objects, each of a specified class.
- A viewpoint provides a template for the construction of a view. A viewpoints-and-views-based architecture definition will include a number of views, each conforming to a specific viewpoint.
Viewpoints are an important way of bringing much-needed structure and consistency to what was in the past a fairly unstructured activity. By defining a standard approach, a standard language, and even a standard metamodel for describing different aspects of a system, stakeholders can understand any AD that conforms to these standards once familiar with them.
In practice, of course, we haven’t fully achieved this goal yet. There are no universally accepted ways to model software architectures, and many ADs use their own homegrown conventions (or even worse, no particular conventions at all). However, the widespread acceptance of techniques such as entity-relationship models and of modeling languages such as UML takes us some way toward this goal.
In any case, it is extremely useful to be able to categorize views according to the types of concerns and architectural elements they present.
Strategy
When developing a view, whether or not you use a formally defined viewpoint, be clear in your own mind what sorts of concerns the view is addressing, what types of architectural elements it presents, and who the viewpoint is aimed at. Make sure that your stakeholders understand these as well.