"4+1" View of Model Software Architecture

If you recall, in my first blog post on software architecture, I mentioned architecture description languages (ADL) as ways to – obviously – describe some software architecture. However, using ADLs is not the only way. In the paper Architectural Blueprints—The “4+1” View Model of Software Architecture by Phillipe Kruchten¹, he examines how developers can use multiple views to capture the software architecture and how these views are more desirable than a single viewport that tries to capture everything. Each view, should ideally, address one specific set of concerns.

For Kruchten, software architecture is the deliberate assembling of various architectural elements to fulfill the requirements of the system. As such, it is possible to describe the architecture using these four views:

• The logical view, which is the object model of the design (when an object-oriented design method is used),
• The process view, which captures the concurrency and synchronization aspects of the design,
• The development view, which describes the static organization of the software in its development environment,
• The physical view, which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect.

Each view uses its own specialized set of notations that can convey the main point more succinctly. For the logical view, the class and object diagrams in UML would be an appropriate choice whereas the sequence diagrams in UML might be suitable for the process view.

The fifth view (the +1 view) would be some use cases for the system. And this fifth view ties the other four views and gives a more concrete description of the system. It is this concrete description that would be most important in a system since the fifth view explicitly states the scenario that needs to be addressed by the system. Most of the details of the “main” problem might be hidden away in the other views since they present a more abstract view of the system.

Furthermore, this fifth view serves an important role in a iterative approach to refine the architecture. The paper presents a sample iterative cycle that uses a specific scenario as the fifth view to help identify the components in the other four views. As each use case is addressed, the other views are also adapted to accommodate that use case.

Finally, these views can also serve as the basis for other forms of written documentation such as the Software Architecture Document and the Software Design Guidelines.

Kruchten himself states the generic nature of these 4+1 views and how other notation systems might be used alternatively. In fact, he is not against dropping certain views if there is no need for them in the system. For instance, he argues that if the logical view and development view are so similar, then there is no need for separate descriptions.

Why does this separation of concerns work? There are various requirements that each stakeholder might be interested in but not every stakeholder cares for what the other stakeholders are interested in. For example, the project manager might be interested in the development view but the systems engineer will be more interested in the physical and process views. By separating the concerns, each stakeholder would be able to quickly find out what they need to know about the architecture and, if necessary, provide feedback.

Documenting Software Architecture (another book to read for this class) does mention a brief note about the “4+1” view at page 380 but the book associates it more with the Rational Unified Process (RUP). So, it would be interesting to see whether this “4+1” is used by developers who are not in favor of RUP.

¹ I did not link to the version on UIUC’s CS server because the paper might still be under copyright.