Architectural Modeling – Choosing your Viewpoints

Ok, so we’ve identifies stakeholders, set principles and guidelines, found out what are our architectural requirements and 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 which Models we want to create and what views do 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 the how the concerns are covered
• A view is (sort of) an instantiation of the pattern defined in a viewpoint (see more below)

So for an 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 suggest 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 which 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 suggest a 4+1 set of viewpoints:

Microsoft is currently moving from the MSF 3.0 model (4 spheres – contextual, conceptual, logical, physical crossed with 4 “views” -business view, applications view information view and technology view totaling in 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 few viewpoints that usually get used:

• Some sort layer view (usually block diagram)
• A logical view (main classes/packages)
• A deployment diagram (tiers, zones etc.)
• A view to show concurrency and timing issues.
• On SOAs 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 make sure the concerns are addressed and to communicate the architecture better).
• Growing a viewpoint repository is a way to reuse your knowledge of concerns to views mapping.