Viewpoints vs Perspectives

18 Jan 2010

Yarc, a Norwegian software engineer has recently posted on his blog to ask “Why can’t we use viewpoints for quality attributes?

He asked this question in the context of understanding the idea of an architectural perspective, created by Nick Rozanski and myself, as introduced in our book.

This is a great question and one Nick  and I get asked a lot.  In fact there are people who know a lot more about architectural viewpoints than I do, like Rich Hilliard, editor of the new ISO standard 42010, who have come to the conclusion that perspectives really are viewpoints (in the IEEE 1471 sense of the term).

In our approach to software architecture, a viewpoint tells you how to define an architectural structure. The Functional structure (i.e. components, interfaces, …) the Information structure (entities, data ownership and flow, …), the Deployment structure (nodes, system software mapping components to runtime environments, …) and so on. So an architectural view (in your architectural description) corresponds to a viewpoint and contains models that define one of the structures in the software architecture of the system.

We defined a perspective as being a collection of activities, checklists and so on that guides an architect to help them make sure that their architectural design will exhibit a particular quality (performance, security, scalability, availability, …)

The key difference is that a perspective doesn’t result in a view. Rather you apply a perspective (its process, activities, checklists etc) to your architecture, normally as described in a set of views. For example, applying the security perspective might mean that you end up changing the functional view to partition components differently to allow them to be secured (and maybe add a security manager component) you change the information view for similar partitioning reasons and you change the deployment view to add in security mechanisms to the system’s runtime structure.

Some perspectives (security and performance being good examples) often do result in architectural deliverables (threat models, performance models and so on) but these aren’t structural definitions of the architecture, they’re supporting definitions.  So while important, we don’t consider that they add a new view.

So using a viewpoint results in a new view (a model or maybe a set of models). Using a perspective (probably) results in changes to one or more views in your architectural description. It doesn’t result in a new architectural structure itself.

I hope this helps!

published under Software Architecture