Software Architecture: Views and Viewpoints
One of the most used strategies nowadays in many problem-solving challenges is “divide and conquer”. This has not left Software Architecture out.
As you may know, the job of a software architect involves finding the needs and requirements of the stakeholders and addressing them in a reasonable manner, which is realistic and efficient. For this purpose, one of the main responsibilities is preparing an architecture design document. A more formal definition of software architect can be found here.
There can be a huge amount of stakeholder concerns, and addressing all of them in one stage is not considered a good practice. Here comes in handy the concept of “divide and conquer”.
In order to simplify the architecture design and make it more readable for the target user, the concept of views has been introduced.
Formally, a view, in software architecture, is a way to portray those aspects or elements of the architecture that are relevant to the concerns the view intends to address and, by implication, the stakeholders to whom those concerns are important.
What is implied by this, is the fact that we split the big problem into small subparts, each of which addresses some specific set of concerns of stakeholders. Each view is a different look at the problem and could be targeted to a specific audience. Some stakeholders may be interested in a specific view more than others, and vice versa.
Then a question arises. How do we define, which views to create? Should I invent them from scratch for every project? Or what should I do?
Luckily, we have viewpoints. These act as templates when creating the views. Viewpoint is like a blueprint to what can be created later as a view.
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 the guidelines, principles, and template models for constructing its views.
There are different accepted types of viewpoints, and a software architect can choose any of them to address in the specific project. The most common viewpoints are context, functional, information, concurrency, development, deployment, and operational.
- Context viewpoint addresses overall relationships and dependencies between the components of the project and the way the system interacts with its environment
- Functional viewpoint describes the system’s runtime functional elements, their responsibilities, interfaces, and interactions between them
- Information viewpoint is intended to address the ways data is collected, stored, and managed to make the system work
- Concurrency viewpoint includes aspects of how concurrent units of the program are handled and what parts specifically can execute concurrently
- Development viewpoint is made for use of technical staff, which build and test this software. It includes design specifications of software and is used as a guideline when preparing the product
- Deployment viewpoint describes where and how the system will be deployed and includes technical details for dependencies and other requirements
- Operational viewpoint handles the part that comes in a production environment, which includes how the software will be operated, administered, and supported
It is worth noting that not all projects require all of these viewpoints to be used. Some have more weight and some less depending on the type of software that you build.
These blueprints help to build a document that describes many aspects but does not overwhelm the reader. However, it is still the job of the software architects to decide on which viewpoints to use to construct views and the level of detail they require.
What distinguishes a good software architect from a bad one is the ability to satisfy the stakeholders, while also balancing the opportunity costs. It would be unrealistic to address all the concerns, as there are time and cost limits for all the projects. Software architect has to choose, which concerns are most important, and explain why.
References:
Nick Rozanski, Eoin Woods (2012). Software Systems Architecture. Second Edition. Published by Pearson Education, Inc.
