Viewtypes

Book section 9.6

Looking back on all the views, you can see patterns in how they are organized. Some views are easy to reconcile with each other, while others are not. For example, it is easy to reconcile the Yinzer functionality scenario with its component assembly, and you could imagine merging these views together into a single view without much difficulty.

But other views are hard to reconcile with the source code view, such as a view of the instantiated objects or components. You would have to scour the source code and mentally animate it to imagine which component instances will appear at runtime, and in which configurations. Put another way, if you have the source code in one hand and a component assembly in the other, it will take you a while to determine if that code could possibly create that configuration of component instances at runtime. While it was easy to reconcile the functionality scenario and component assembly views, there is no obvious way to reconcile module and runtime views. What you would like to do is group together the views that are easy to reconcile.

9.6.1 Viewtype definition

This grouping is accomplished through the idea of viewtypes. A viewtype is a set, or category, of views that can be easily reconciled with each other (Clements et al., 2010). The views that cannot be reconciled belong to different viewtypes. In software architecture, viewtypes4 apply to any design or code model, including the top-level boundary model and any nested internals or boundary models. It is an unfortunate fact that you cannot easily reconcile every view of a software system. Clearly, in some sense all of the views must be reconcilable, if only in your head, because you build systems that conform to all of the views. A good way of thinking about reconciling views it is to consider someone else’s design, not your own, and how hard it is to find flaws and inconsistencies between their views.

9.6.2 Standard architectural viewtypes

The three standard viewtypes in software architecture are the module viewtype, the runtime viewtype, and the allocation viewtype.

The module viewtype contains views of the elements you can see at compile-time. It includes artifacts like source code and configuration files. Definitions of component types, connector types, and port types are also in the module viewtype, along with definitions of classes and interfaces.

The runtime viewtype, also called the component and connector (C&C) viewtype, contains views of elements that you can see at runtime. It includes artifacts like functionality scenarios, responsibility lists, and the component assemblies. Instances of components, connectors, and ports are in the runtime viewtype, as are objects (class instances).

The allocation viewtype contains views of elements related to the deployment of the software onto hardware. It includes deployment diagrams, descriptions of environmental elements like servers, and descriptions of communication channels like ethernet links. It may also include geographical elements, so that you can describe two servers in different cities.

Figure 9.10 shows a graphical summary of the three viewtypes with a non-exhaustive list of the contents of each viewtype. It shows one additional viewtype,
the spanning viewtype, which contains views that cross over between two or more viewtypes, because not everything will fit neatly into the categories. Here is an example of a tradeoff that spans viewtypes. You decide to denormalize a database schema (described in the module viewtype) in order to achieve greater transaction throughput (described in the runtime viewtype) so you describe that tradeoff in the spanning viewtype.

Definitions:

Viewtype. A viewtype is a set or category of views that can be easily reconciled with each other (Clements et al., 2010). See module viewtype, runtime viewtype, and allocation viewtype.

Allocation viewtype. The viewtype that contains views of elements related to the deployment of the software onto hardware. It includes deployment diagrams, descriptions of environmental elements like servers, and descriptions of communication channels like ethernet links. It may also include geographical elements, so that you can describe two servers in different cities.

Module viewtype. The viewtype that contains views of the elements you can see at compile-time. It includes artifacts like source code and configuration files. Definitions of component types, connector types, and port types are also in the module viewtype, as are definitions of classes and interfaces.

Runtime viewtype (i.e., component & connector viewtype) The viewtype that contains views of elements that you can see at runtime. It includes artifacts like functionality scenarios, responsibility lists, and the component assemblies. Instances of components, connectors, and ports are in the runtime viewtype, as are objects (class instances).

This section is extracted from the book.