This article was originally published in The Rational Edge in November 2006.  Since it is no longer available there I have republished it here.  Apologies if the picture quality is not the best.  They have not survived various storages very well…

The four dimensions of system models

In many projects I have been involved in, discussions with my colleagues about system models and how to divide them into parts have been generally confused and not very fruitful.  I believe that one of the problems is that we lack a common way of organizing and navigating models as well as thinking about their structure.  Therefore, I will in this article give my view on the problem and also provide four dimensions that have been useful for me when navigating through models of systems and software.

A system model typically covers many aspects of the system.  To convey the information about all of these aspects we need to organize our model in some way, which means that the model must be divided into parts according to some standardized rules.  There are many standard sets of such rules available that typically go by the name “architectural frameworks.”  An architectural framework provides information on what parts a system model should be made up of, thus what interesting aspects of the system the model must describe.  An architectural framework may provide many other things as well, but for the purpose of this article, we will focus on the model division aspects.

The IEEE1471 standard

There is actually a standard for architectural descriptions of software systems: IEEE1471-2000.  The standard defines a number of terms, such as system, architecture, architectural description, model, view, viewpoint, etc.  It also specifies the relationships between these terms in what is called the “Conceptual model of architectural description,” shown in Figure 1[1].

Figure 1 IEEE1471 conceptual model

Figure 1: IEEE1471 conceptual model

Now, let’s consider some of the terms illustrated in Figure 1. I will discuss each of them below.

Model

As I noted earlier, models are abstractions of the system to be built.  They may be created using a number of techniques, including the Unified Modeling Language (UML).

The description of a system and its architecture may be created in one or more models.  There are many ways to break up the description into separate models, but, at least conceptually, we can usually treat all of the model information as one single model.

View

Views represent individual pieces of the description or the individual pictures that you would find in a model.  A specific piece of the information in a model may be viewed in zero, one or more views.  If we use UML for our models, most views would come in the form of UML diagrams of some type.

Viewpoint

If the model is the source of information and the views contain representations of that information, the viewpoints define how the view representations should be made.  The viewpoint can be viewed as a collection of rules regarding what type of information to present and how to present it in each view.  One might think of this as the model being what we look at, the view being what we see, and the viewpoint being the glasses that we look through.

As you see in Figure 1, the IEEE1471 standard states that each viewpoint should address the concerns of one or more stakeholders.  This means that the mapping between the viewpoints and stakeholders should be known.

Examples of architecture frameworks

As noted above, there are many architecture frameworks available.  I will describe aspects of some of them here and in the next section talk about how I see the division of models into parts.

RUP

The IBM Rational Unified Process®, or RUP®, contains an architecture framework that is called “The 4+1 views of software architecture.” [2]  This framework describes five necessary views (or rather viewpoints in the IEEE1471 sense) for software architecture.  These views (viewpoints) are illustrated in Figure 2.

4 dimensions - fig2

Figure 2: The 4+1 views of software architecture

In the 4+1 view architectural framework, the views include: [3]

  • Use-case view
    Deals with WHAT the system should do.  This is expressed in terms of actors and use-cases by following standard use-case modeling techniques.
  • Logical view
    Deals with the logical structures of the system — i.e. how the system is broken down into logical subsystems, their relationships, and their interactions.
  • Process view
    Deals with the threads of control that the system runs.  This is expressed in terms of processes and threads.
  • Implementation view
    Explains how the system is implemented in terms of file structures
  • Deployment view
    Deals with how the system is run on machines and the network connections between those machines.

The 4+1 views of software architecture work well for software-centric systems.  If the system is more complex — e.g., a distributed system made up of hardware, software, and perhaps also people — then a more complex architectural framework is needed, which brings us to the next architectural framework.

RUP SE

IBM Rational Unified Process for Systems Engineering (RUP SE) is an extension of RUP, which covers software engineering, in order to deal with the more complex problem of systems engineering.  Many of the concepts of RUP still apply, but some things are changed.  For example, in RUP SE, the architectural framework from RUP (4+1 views) is replaced by another architectural framework called the “RUP SE Model framework,” [4]  illustrated in Table 1.

Model Levels

Model Viewpoints

Worker

Logical

Information

Physical

Process

Geometric

Context

Role definitionActivity modeling UML Context DiagramUML Use case diagram specification UML Enterprise data view containing extended Product data Domain-dependent Views (E.g. S-space for electromecanical) Domain-dependent (Such as highway modeling for vehicles

Analysis

UML partitioning of system in to human, machineActivity modeling and simulation UML logical decomposition Product data conceptual Schema (UML in RoseRT/ReqPro) UML locality view UML process view (static diagrams) Parameterized Geometric ModelLayouts

Design

Operator instructionsHelp filesWorkflow and transaction management Software component design Product data schema ECM Design Detailed process viewTiming diagrams MCAD Design

Implementation

Hardware, Software configuration

Table 1: RUP SE Model framework

The RUP SE Model framework specifies a set of views, as shown in the cells of Table 1.  For example we see the views “Role definition” and “UML locality view.”  Each of these views shows a specific aspect of the system.

The views are organized into two dimensions.  In the horizontal dimension of Table 1  we see the Model Viewpoints, and in the vertical dimension we see the Model Levels (i.e., each view belongs to a specific Model Level and a specific Model Viewpoint).

The first dimension, Model Viewpoints, corresponds to the viewpoint concept of IEEE1471 as described above.  In the RUP SE Model framework, the Model Viewpoints represent different areas of concern for the system model, typically the concerns of different stakeholder groups.

The Model Viewpoints of the RUP SE Model framework fill much of the same roles as the views do in the 4+1 views architectural framework from RUP.  They are not exactly the same set of Model Viewpoints, but they each deal with a specific area of concern for the system.  Why have a different set of viewpoints in the RUP SE Model framework? Because in systems engineering, you have to deal with, for example, the people inside the system, which is not necessary for software development covered by RUP.  Therefore, the RUP SE Model framework contains a worker viewpoint, something not covered in the 4+1 views.

The second dimension of the RUP SE Model framework is the Model Levels, which deals with levels of specification.  This means that in the higher model levels the system is not highly specified, and the information covers abstract issues of the system.  The farther down you go, the more detail is added and therefore you get a higher level of specification.  Furthermore, as you move down the model levels you realize the upper level through new model elements from the lower level.  This means that the usual workflow in the design of a system means that you work your way from the top Model Level and downwards to a higher level of detail.

Other architectural frameworks

There are many other examples of architectural frameworks besides the two described above.  The Department of Defense Architectural Framework (DoDAF) stipulates a number of views[5] that should be present in a system model of systems used by the US military.  In DoDAF, the views are divided into four groups: AV (All View), OV (Operational View), SV (Systems View), and TV (Techcnical Standards View).  In these groups we find examples of views such as AV-1 (Overview and Summary Information), OV-5 (Operational Activity Model), SV-1 (System Interface Description) and TV-2 (Technical Standards Forecast).[6]

Another example is the Zachman Framework.[7] The Zachman Framework takes a two-dimensional approach, dividing a model into stakeholders (rows) and aspects of the architecture (columns), as illustrated in Table 2.

What
(Data)

How
(Function)

Where
(Locations)

Who
(People)

When
(Time)

Why
(Motivation)

Scope
{contextual}

Planner

List of things important to the business

List of processes that the business performs

List of locations in which the business operates

List of organizations important to the business

List of events/cycles important for the business

List of business goals/strategies

Enterprise Model
{conceptual}

Business Owner

e.g.
Semantic Model

e.g.
Business Process Model

e.g.
Business Logistics System

e.g.
Workflow Model

e.g.
Master Schedule

e.g.
Business Plan

System Model
{logical}

Designer

e.g.
Logical Data Model

e.g.
Application Architecture

e.g.
Distributed System Architecture

e.g.
Human Interface Architecture

e.g.
Process Structure

e.g.
Business Rule Model

Technology Model
{physical}

Implementer

e.g.
Physical Data Model

e.g.
System Design

e.g.
Technology Architecture

e.g.
Presentation Architecture

e.g.
Control Structure

e.g.
Rule Design

Detailed Representation
{out of context}

Subcontractor

e.g.
Data Definition

e.g.
Program

e.g.
Network Architecture

e.g.
Security Architecture

e.g.
Timing Definition

e.g.
Rule Definition

Functioning System

e.g.
Data

e.g.
Function

e.g.
Network

e.g. Organization

e.g.
Schedule

e.g.
Strategy

Table 2: The Zachman Framework

Note that the Zachman Framework is not meant to be an architectural framework for system models.  Instead, it governs enterprise architecture, which is usually a larger problem than system modeling.  But we can see that this framework has a lot in common with the other examples shown.  The Zachman Framework divides the model in more than one dimension, and at the intersections of these dimensions (the cells in the table) we find views that describe the system we are modeling.

Introducing four system model dimensions

So far I have discussed known architectural frameworks that are described in the literature on system modeling.  But, as noted in the introduction, I have found that despite having these architectural frameworks to rely on, people have a hard time navigating through a system model.  This leads to confusion and bad communication, which in turn may lead to lower quality systems and delays of development projects.

If used in system modeling, the 4+1 view model is one-dimensional.  It divides the system model into parts according to one rule.  The RUP SE Model framework introduces another dimension which gives us more precision in our system model navigation, but I think this is still not enough.  I have come to the conclusion that we should add two more dimensions so that we actually have four interesting dimensions to work with in navigating a system model.

1st dimension – Viewpoint

My first dimension is the viewpoint dimension, which corresponds to how the RUP SE Model framework looks at things.  I feel that the viewpoint dimension is important because it gives us a good separation of concerns in our models.  Furthermore, we may divide the work in the separate viewpoints so that each viewpoint is handled by a specific engineering discipline at the lower model levels.  The logical viewpoint may, for example, be handled by software engineering whereas the physical viewpoint may be handled by hardware engineering.

The RUP SE model framework gives us a good starting point for understanding which viewpoints to use in system engineering.  These are the viewpoints shown earlier in Table 1, described below in Table 3.

Viewpoint Expresses Concern
Worker[8] Roles and responsibilities of system workers
  • Worker activities
  • Human/System Interaction
  • Human performance specification
Logical Logical decomposition of the system as a coherent set of UML subsystems that collaborate to provide the desired behaviour
  • System functionality is adequate to realize use cases.
  • System is extendible and maintainable.
  • Internal reuse
  • Good cohesion and connectivity
Physical Physical decomposition of the system and the specification of the physical components
  • System physical characteristics are adequate to host functionality and meet supplementary requirements.
Information Information stored and processed by the system
  • System has sufficient capacity to store data.
  • System has sufficient throughput to provide timely access to the data.
Geometric Spatial relationship between physical components
  • Manufacturability
  • Accessibility
Process Threads of control, which carry out the computation elements
  • System has sufficient partitioning of processing to support concurrency and reliability needs.

Table 3: RUP SE Model viewpoints serve as the first dimension in system modeling.

Of course, we do not need to use all of these viewpoints for all system models; instead we should only use the ones that make sense.  We may also add new viewpoints for specific system models.  A security viewpoint may, for example, be useful for the system models with specific security requirements.

2nd dimension – Model level

The second dimension I use is the Model level dimension from RUP SE.  This is necessary because we need to be able to express ourselves at varying levels of precision and varying levels of specification.  Early on in a development effort we do not have all the details, but we’ll need to be able to express what we know.  As development moves on, more details are added and we thus move down the model levels.

In modeling somewhat complex systems, it is probably a good idea to retain model information created at higher levels, even though we have moved on and filled in more details at the lower levels.  This is because a system description not covered in detail is helpful for people who need an overview or are learning about the system.  If we provide all of the details at once (the lower levels) they might have a hard time seeing the big picture.  In addition a single abstract design (higher level) may be implemented in a number of different ways, with varying performance and price points.

On the question on which model levels to use, I suggest that we use the ones from RUP SE unless there is a specific reason to add or remove any model levels.  The model levels from the RUP SE Model framework are described in Table 4.

Model Level Expresses
Context The system and its actors
Analysis Initial system partitioning in each of the viewpoints to establish the conceptual approach
Design Realization of the analysis level to hardware, software, and people
Implementation Realization of the design model into specific configurations

Table 4: RUP SE Model levels serve as the second dimension in system modeling. 

3rd dimension – System level

The 3rd dimension deals with system hierarchies and the current view’s position in that hierarchy.  I will explain this by first describing system hierarchies, then showing why we must treat these hierarchy levels as a dimension. The concept is comparable to the notion of “level of abstraction,” a phrase used frequently, but which I think is confusing to many people; I’ll explain more about this later.

System hierarchies

If we use a bit of system theory reasoning we can say that every system has a border which separates its inside from its outside.  The inside of the system contains a number of “parts” that collaborate to fulfill the purpose of the system — i.e., that produce the services the system delivers to its surroundings.  In a system-of-systems, approach we would view the “parts” inside the system in focus as also being systems themselves, which means that the larger system in focus is made up of a number of sub-systems.  Similarly, these sub-systems are made up of sub-sub-systems, and we can follow this hierarchical structure as deep into the system as we’d like.  Or, returning again to the larger system under discussion, we could move higher in this hierarchy, noting that the system in focus plays a role as a sub-system within its own surrounding system.

This means that a typical system model will contain a somewhat complex hierarchy of systems.  Each of these systems may be modelled in the same way (they are all systems) but it is important to always keep track of which system we are modeling.  For this reason I have introduced a 3rd dimension: system level, which locates the system in the overall system hierarchy.

Let’s look at an example of a system hierarchy to make things clearer.  Imagine that the system we are modeling is a warship, and let’s use the term “system in focus” to denote the warship.  This system is made up of a number of sub-systems — e.g., a Command and Control system, a Communications system, a Propulsion system, a Sensor system, and some Weapons systems.  In the hierarchy, these systems live at a system level one level below the warship.  If we go in the other direction we may say that our warship is working inside a larger system which is a Fleet.  The fleet contains the warship as a sub-system and it may also have other sub-systems, such as supply ships.  This example is illustrated[9] in Figure 3.

4 dimensions - fig3

Figure 3:  A UML Class diagram illustrating a system hierarchy

In Figure 3 we can clearly see three system levels, the level of the system in focus, the level of the surrounding system, and the level of the subsystems.  Of course, there may be many more levels in a real example, but this is enough to get the point across.  Also note that in a real example, a subsystem could support more than one higher level system.

Why “system level” is a dimension

Obviously, it is important to know the level of the system in focus for any view of our system model. When we for example look at our Warship and see a view which illustrates how the Command and Control, Sensors, and Weapons collaborate to combat a target, we do this at the level of the warship.  The reasoning on this level will then provide requirements to the systems one level down — i.e., the Command and Control, Sensors, and Weapons systems.  If we move down one level and change the focus to be, for example, the Sensors system, we now can see how the Sensors collaborate with the other systems at this level, which are the Command and Control and the Weapons.

In the example explained above, the Sensors system appears both on the Warship level as well as the Sensors level.  There is, however, a difference between how it is presented and why it is part of that level.  At the Warship level, the Sensors are part of the inside of the Warship and they show up because they are needed to make the Warship fulfill its task.  We are thus looking at the inside of the Warship and seeing how the Sensors are part of that inside.  On the Sensors level, however, the Sensors are the system in focus and therefore we are looking at the outside of the Sensors system.  Sometimes this distinction is referred to as black-box (outside) vs. white-box (inside).  In many cases the black-box is used to understand the requirements on the system in focus (in this case the Sensors system) but the white-box is used to understand the implementation of the system in focus (in that case the Warship).  Therefore the distinction between the two ways of looking at the Sensors is important and therefore it is important to understand the specific system level for each view we are looking at.

Relationship to level of abstraction

Many times I have heard people use the term “level of abstraction” to mean the system level as explained above.  I feel, however, that this is an unfortunate term since “level of abstraction” means many things to different people; for example, some people use “level of abstraction” to mean not the system level but the model level, which in my analysis is a different dimension altogether.  I have been part of many discussions where these two different meanings for the term were at the root of a misunderstanding.

Because of this, I choose not to use the term “level of abstraction” at all, but instead clarify by using “system level” and “model level.”

4th dimension – Description type

In addition to the three dimensions discussed above, a 4th dimension deals with the type of description that each view contains.  This involves the selection of model elements that are included in the view, and also the purpose of the view.

City bus example

Let me explain this by an example.  Let’s consider a city bus as our system in focus.  One way of looking at the bus (and thus one description type) is to look at the whole bus and to consider what parts it is made up of.[10]  This would give us a view such as Figure 4, which shows that the bus is made up of six subsystems that have dependencies on each other.

4 dimensions - fig4

Figure 4:City bus contents

Another way of looking at the bus (and thus another description type) is to consider a specific task that the bus performs.  When we look at one specific task, for example the transportation of people, perhaps fewer parts are involved.  This could give us a picture such as Figure 5.

4 dimensions - fig5

Figure 5: Bus parts involved in transportation of people

In Figure 5 we see that a subset of the total set of subsystems is used when this specific task is performed by the bus.

Generalizing the example

The examples provided in Figures 4 and 5 show the difference between two description types.  The two examples show model entities (in this case classes) selected from the same set of model entities.  But the selection is different, since we want to convey different messages with the example views (in Figure 4 we want to see the complete list of subsystems for some part of the bus, and in Figure 5 we want to see the subsystems participating in a specific task).

These different selection criteria do not correspond to any of the other three dimensions I’ve described so far.  They are not related to viewpoints, since both examples (Figures 4 and 5) show model entities from the logical viewpoint.  They are also unrelated to model level, since both examples live at the same level of detail.  Finally, the selection criteria are not related to system level, since both examples deal with how the bus may be broken down into parts.

These differences from the other three dimensions argue for a fourth dimension in our system model, which deals with the specific purpose of the view.  This purpose can be to show all entities in a specific part of the system or to show how the system works to fulfill a specific task[11].  I have chosen to call this dimension “Description type.”

The purposes explained above gives us three description types, noted here in boldface.  Showing all entities in a specific part of the system is covered by what I call contents diagrams.  Explaining how the system fulfills a specific task is handled by realizations, which are divided into static realizations and dynamic realizations.  All three description types are explained below.

Contents

Figure 4 is an example of a content diagram.  It shows the contents of the bus in the sense that it shows all parts (in this case subsystem parts) of the bus.

The important aspect for this description type is that it looks across one area of the system and for that area it shows all parts and their relationships.  The area in question may be the whole system, one layer of the system, or some similar area.  This description type looks at the internal structure of the chosen area, but I do not want to call this description type “structure” since structure diagrams is something else in UML2.

If we were to look at all content views of the system we would see all parts that the system is made of and how they relate to each other. They would thus define all contents of the system.

Realizations: Static and Dynamic

In addition to the structure views, we also need to show how the system works to fulfil its purpose.  Somewhere in our model we have a description of the tasks that the system should do.  This may be expressed in terms of use-cases or services.  For each of these tasks we would create a realization that describes how the system performs that task.  We could also create realizations that describe how the system solves specific problems.

Whatever the realization is about, it is typically made up of two parts: static realization and dynamic realization.

A static realization is shown in Figure 5.  The static realization shows the parts of the structure that are involved in the realization.  In most cases, the parts that show up in a static realization may belong to different areas of the content, which means that they do not show up in the same content view.  The static realization will thus be one way of tying the areas of the content together.

The dynamic realization describes how the parts shown in the static realization collaborate to make things happen.  This may be expressed in terms of a UML sequence diagram, but it can also be expressed in other ways.  The important thing is that it describes who does what, in what order it is done and what messages are being exchanged.  Figure 6 shows a dynamic realization from the bus example.

4 dimensions - fig6

Figure 6: Dynamic realization

Putting it together

So, why do we really need to think about all of these four dimensions?  I have found that they are very helpful for two reasons: to understand a specific view, and to act as a map for the model to be developed.

Understanding a specific view

When we consider at a specific view (which in most cases is one or more UML diagrams) in terms of these four dimensions, we understand more about what the view is intended to show. For example, if we say that the view is static realization from the physical perspective on the bus system and on the analysis model level, we understand a good deal about what the view is trying to convey.  Describing the view in this way helps us understand the message that the view provides and also helps us understand how the view fits into the larger picture.

Also, if people have conflicting ideas on where the view fits into the four dimensions, that will inevitably lead to misunderstandings.  I have found this to be quite common while discussing system models in places where the four dimensions are not known.  Therefore the understanding of four dimensions themselves and the understanding where a specific view fits into those four dimensions help clarify misunderstandings.

Mapping the model

The second reason to understand the four dimensions is that they can help us make a map of our model.  Before and during a development effort, the map can help us understand what parts of the model we need to develop.  After the development effort the map may help us understand what parts the model consists of so that we can more easily navigate through it.

Such a map of the model may be expressed in terms of what combinations of values from the four dimensions the model should consist of.  For example we may say that we will develop the logical, physical and worker viewpoints and that we will develop structure views as well as realization views on those viewpoints and that we will do this on the topmost system level as well as subsystems etc.

A note on practicalities

I don’t want to suggest that you have to use all viewpoints, all model levels, and all description types for every system level.  You should, as always, use only the parts that are relevant to your project. This could mean that specific viewpoints, model levels, system levels or description types are skipped.  Or it could mean that specific combinations (for example the dynamic realization in the information viewpoint) are skipped.  It could also mean that not all dimensions are interesting.  I have, for example, been in a project where the model level dimension was not interesting since the project was about creating an overview about the system and not sort out all the details.

Acknowledgements

First I would like to thank the people who helped me develop the ideas described in this article.  This was done when I was working in an engagement together with (among others) Håkan Beckman and Lars Schylberg.  Furthermore I would like to thank Dave Brown & Jim Densmore who helped me review the article.  I also want to thank Michael Perrow for his great edits and suggestions.

 


[1] I have simplified the conceptual model of architectural description somewhat so that concepts not interesting for this article have been excluded.

[2] This was originally described in an article by Philippe Kruchten, ”The 4+1 view model of architecture,” IEEE Software. 12(6), November 1995.

[3] This description is somewhat simplified.  The purpose of this article is not to explain the 4+1 views in detail.  Instead it is to show this as an example of an architectural framework.

[4] Please note that this is not meant to be a complete description of the RUP SE Model framework, but simply an example of an architectural framework. There are many sources of information on RUP SE, including a set of three articles by Murray Cantor. The description of the RUP SE Model framework is in the second article: Murray Cantor, ”Rational Unified Process for Systems Engineering, Part II: System architecture”, The Rational Edge, September 2003.

[5] The DoDAF framework uses the word “view”, but they are really viewpoints in the IEEE1471 sense.  I will use the word view to conform with the framework.

[6] For a complete description of IBM’s approach to DoDAF, see Chris Widney, “An IBM Rational approach to the Department of Defense Architecture Framework (DoDAF) Part 1: Operational view,” The Rational Edge, March 2006, at http://www-128.ibm.com/developerworks/rational/library/mar06/widney/index.html; and Chris Widney, “An IBM Rational approach to the Department of Defense Architecture Framework (DoDAF) Part 2: System views,” The Rational Edge, March 2006, at http://www-128.ibm.com/developerworks/rational/library/apr06/widney/index.html

[7] A new description of the Zachman Framework and its relationship to RUP and UML can be found elsewhere in this issue of The Rational Edge. See Vitalie Temnenco, “UML, RUP, and the Zachman Framework: Better together,” <URL REMOVED, since it is no longer available Fredrik Ferm, april 2014>

[8] Please note the distinction between workers and actors.  Workers are people who work inside the system in focus.  Actors are parties (for example persons) outside the system in focus.  The reason that the 4+1 view framework does not deal with workers is that, according to the system definition used in RUP, people may not be part of the system.  In system engineering, they certainly can be.

[9] I have chosen to illustrate the hierarchy through a UML model, where stereotyped classes represent the systems.  The relationships between a system and its sub-systems are shown with the owned element relationship from UML.

This does not mean that this is the only way to model a system hierarchy.  You may model this in many different ways.  I have just chosen this way of modeling to illustrate my example of systems sub-systems and surrounding systems.

[10] This is not necessarily the best way to divide a bus into parts.  I just want to show an example of a total view of parts.

[11] There could possibly be other purposes as well, but these seem to be enough for most system models