I’m somewhat confused, I guess. I thought my understanding of a software architectural viewpoint was fairly sound. I read about work on architectural perspectives, in particular the work by Nick Rozanski and Eoin Woods (here is an accessible presentation).
Now, let’s have a look at the original view and viewpoint definition (all from the aforementioned presentation);
“A viewpoint is a collection of patterns, templates and conventions
for constructing one type of view. It defines the stakeholders
whose concerns are reflected in the viewpoint, and guidelines and
principles and template models for constructing its views.
A view is a representation of all or part of an architecture, from
the perspective of one or more concerns which are held by one or
more of its stakeholders.”
Typical views may be the 4+1 by Kruchten (RUP) – Logical, Development, Physical, Process. Other blueprints have been suggested.
Now, let’s turn to perspectives. Defined, by the same source;
“Architectural perspective is a collection of activities, checklists,
tactics and guidelines to guide the process of ensuring that a
system exhibits a particular set of closely related quality properties
that require consideration across a number of the system’s
architectural views.”
Fair enough. Blueprint-type examples they come up with are essentially quality attributes as viewpoints, e.g. “Performance and Scalability, Security, Availability and Resilience, Evolution etc.
Now, what I don’t get is why this has to be a new type of concept in IEEE 1471-2000’s taxonomy. Why can’t we use viewpoints for quality attributes? A viewpoint is governed by a stakeholder’s concern. If the stakeholder is concerned with a particular quality attribute – fine, then a view may be constructed to reflect this. I cannot see why I need a perspective to cater for this.
Clearly, there is something I’m missing.
Anybody?
That’s a very fair question and one that lots of people have asked. In fact, a number of people who are very well known in the development of viewpoints (like Rich Hilliard editor of the new ISO standard 42010 that supercedes IEEE 1471) have discussed this and concluded that a perspective is just a kind of viewpoint.
We don’t really get too steamed up about this one way or the other. It’s people doing good architectural design that matters and if they find the content useful and want to call them “viewpoints” that’s OK. However, we did separate the two for a reason ….
For us, 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.
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.
Now this *is* an extension to IEEE 1471, but it’s one we’ve found useful.
I’ll try to put something on my blog about this in the next day or two.
Best wishes,
Eoin.
I’m chewing upon this.
> The key difference is that a perspective doesn’t result in a view.
Ok. That was clarifying. Thanks.
So you kind of apply a perspective to your architectural work to ensure that a particular quality attribute has been met. And that application might entail changes to one or more views. Hm. Fair enough, if I understand it rightly.
I’m trying to reconcile this with the way we’re working. We would define viewpoints that correspond to stakeholders concerns. Often the concerns would essentially be questions that pertain to some quality attribute. We could have a a scalability viewpoint for example. Then, we’d go about creating views upon our models (and possibly refine or extend the models (and codebase) themselves) which would reveal to what extent we cover the stated stakeholder concern.
Or to put it another way, we don’t use standard 4+1 viewpoints (or similar) as such, because they’re (often) not tightly enough connected to an expressed concern. And that makes the architectural work less cost-effective. In a sense, we cannot afford it.
Does this make sense? Does this reveal there is something we haven’t understood? Is what we do related to perspectives?
Yes, I completely see the problem – you want views aimed at one particular concern which is often a quality property, so you’ll have a scalability or security view.
That’s fine and is certainly the way that the IEEE 1471 standard views the world.
The problem with this is that you tend to get a lot of duplicated information between views – that’s what lead us to the idea of perspectives. We suggest that you need one definitive set of views to define the structures and you don’t want duplication between them.
That said, in our real work both of us often create other architectural representations for specific groups of people. For example, you might have a formal UML model for your system components forming the core of your functional view and that’s the “real” description. But to explain the system’s main functions to (say) your IT auditors, you create a simplified picture in PowerPoint. As long as you’re clear about which is the “master” definition then this is no problem at all. The Powerpoint is discardable once you’re done with it, the functional view is maintained over time.
I certainly don’t think you’ve missed anything – you’re doing exactly the right thing and thinking carefully about the way you use these ideas and tailoring them for your environment.
What you’re doing is certainly using perspectives, you’re just extending them to have their own views associated with them. As long as you manage that redundancy and consistency between them, I’m sure this will work well.