Architectural Modeling – Choosing your Viewpoints

Ok, so we’ve identified stakeholders,  set principles and guidelines, and discovered our architectural requirements. We want to start modeling already – especially considering architectural modeling is great fun (for techno-geeks like myself, anyway). However, before we just start to create an endless flurry of blocks, boxes, arrows, and whatnot, it is probably worthwhile to take a few minutes to think about which Models we want to create and what views we want to use to communicate them otherwise we may end up doing a very good job thinking about and describing something that doesn’t interest anyone and gives no real value.

IEEE 1471 defines (an architectural) view as a representation of a whole system from the perspective of a set of concerns (where concerns are the key interests of the different stakeholders)

• A view is comprised of parts of one or more models to demonstrate how the concerns are covered.
• A view is (sort of) an instantiation of the pattern defined in a viewpoint (see more below)

So for example, if our concerns are concurrency and timing issues, looking from this viewpoint can be looking at the threads and process model of the solution, and we can use views like process diagrams and timing diagrams to visualize it.

One thing we can do (over time) is to create a viewpoint repository, and then when faced with a set of concerns, we can easily choose which views to create.

Rich Hilliard suggests that a viewpoint would hold the following information:

• Viewpoint name
• The stakeholders addressed by the viewpoint
• The stakeholder concerns to be addressed by the viewpoint
• The viewpoint language, modeling techniques, or analytical methods used
• The source, if any, of the viewpoint (e.g., author, literature citation)

A viewpoint may also include:

• Any consistency or completeness checks associated with the underlying method to be applied to models within the view
• Any evaluation or analysis techniques to be applied to models within the view
• Any heuristics, patterns, or other guidelines that aid in the synthesis of an associated view or its models

If you are just starting out, you can turn to various frameworks to see which views they have and use that as the basis of your repository, for example:

RUP suggests a 4+1 set of viewpoints:

Microsoft is currently moving from the MSF 3.0 model (4 spheres – contextual, conceptual, logical, and physical crossed with 4 “views” -business view, applications view, information view, and technology view, totaling 16 viewpoints) to the following set of viewpoints:

Other examples are DODAF (3 main viewpoints with 26 sub-viewpoints), RM-ODP (5 viewpoints), and Zachman Framework (with 36 viewpoints)

Lastly, the software architecture document template I’ve posted also contains a list of possible views

What about a minimal set of viewpoints? Well, I don’t know about a minimal set – there are, however, a few viewpoints that usually get used:

• Some sort of layer view (usually a block diagram)
• A logical view (main classes/packages)
• A deployment diagram (tiers, zones, etc.)
• A view to show concurrency and timing issues.
• For SOA projects there’s also a service view (services, policies)

To wrap-up –

• Choosing which views to create (viewpoints) is an important step before embarking on modeling.
• Viewpoints are chosen according to the stakeholder’s concerns (to help ensure the concerns are addressed and communicate the architecture better).
• Growing a viewpoint repository is a way to reuse your knowledge of concerns to view mapping.