Modified a little by Newweapon. | ![]() |
![]() |
Level: Introductory Mikko Kontio (mikko.kontio@softera.fi), Production Manager, Softera 02 Feb 2005 The designing software architectures series continues with a look at the 4+1 view model. The 4+1 view model lets you separate a system into four essential views: logical, process, physical, and development. Then, for good measure, it gives you one more: a use case view that describes the functional aspects of the system as a whole. This month you're being introduced to the 4+1 view model, an architect's tool for viewing and documenting application software. The 4+1 view model was originally introduced by Philippe Kruchten in 1995 (see Resources). Kruchten's new approach gave architects a way to examine different parts of an architecture separately, thus easing the complexity of the overall viewing. Each of the five views in the 4+1 view model highlights some elements of the system, while intentionally suppressing others. The 4+1 view model is an excellent way for both architects and other team members to learn about a system's architecture. Architects use it to understand and document the many layers of an application in a systematic, standardized way. Documents created using the 4+1 view process are easily used by all members of the development team. The first four views represent the logical, processing, physical, and developmental aspects of the architecture. The fifth view consists of use cases and scenarios that might further describe or consolidate the other views. Figure 1 shows the five views of the 4+1 view model.
System integrator System engineering Note that, like some of the other articles in this series, this article assumes you are familiar with UML diagramming. The 4+1's logical view supports behavioral requirements and shows how the system is decomposed into a set of abstractions. Classes and objects are the main elements studied in this view. You can use class diagrams, collaboration diagrams, and sequence diagrams, among others, to show the relationship of these elements from a logical view. Class diagrams show classes and their attributes, methods, and associations to other classes in the system. The class diagram in Figure 2 shows a simple use case of an ordering system (or part of one). The customer can have from zero to several orders, and an order can have from one to several items. Figure 2. A class diagram of an ordering system ![]() While useful, the class diagram hardly gives you a complete picture of the system. For one thing, class diagrams are static, so they tell you nothing about how the system will react to user input. For another, class diagrams are often too detailed to offer a useful overview of the system. You can only learn so much from studying a class diagram for a system comprised of thousands of classes. You can use collaboration diagrams (or communication diagrams) and sequence diagrams to see how objects in the system interact. A collaboration diagram is a simple way to show system objects and the messages and calls that pass between them. Figure 3 is a simple collaboration diagram. Note that each message is assigned a number that indicates its order in the sequence. Figure 3. A collaboration diagram of an ordering system ![]() Collaboration diagrams are very practical for showing a birds-eye view of collaborating objects in the system. If you want a more detailed window into the system's logic you might want to try drawing a sequence diagram. Sequence diagrams provide more detail than collaboration diagrams, but still let you study the system from a distance. Architects and designers often use sequence diagrams to fine-tune system design. For example, looking at the sequence diagram in Figure 4 might lead you to change a number of the system's method calls to reduce their number. Alternately, you might change the design by creating a vector (or similar collection) of all the Figure 4. A sequence diagram of an ordering system ![]()
The development view is used to describe the modules of the system. Modules are bigger building blocks than classes and objects and vary according to the development environment. Packages, subsystems, and class libraries are all considered modules. Figure 5 is a package diagram showing how packages are nested in the system. Figure 5. A package diagram shows how packages are nested in the system ![]() You can also use the development view to study the placement of actual files in the system and development environment. Alternately, it is a good way to view the layers of a system in a layered architecture. A typical layered architecture might contain a UI layer, a Presentation layer, an Application Logic layer, a Business Logic layer, and a Persistence layer.
The process view lets you describe and study the system's processes and how they communicate, if they communicate with each other at all. An overview of the processes and their communication can help you avert unintentional errors. This view is helpful when you have multiple, simultaneous processes or threads in your software. For example, Java servlets usually create threads of one servlet instance to serve requests. Without access to a process view, a developer might unintentionally store something in the servlet class's attributes, which could lead to complex errors if other threads did the same. The process view could reduce this type of problem by describing clearly how to communicate. The process view can be described from several levels of abstraction, starting from independently executing logical networks of communicating programs. The process view takes into account many of the nonfunctional requirements or quality requirements (which last month's column talked about) like performance, availability, etc. Activity diagrams are quite often used to describe this view.
The physical view describes how the application is installed and how it executes in a network of computers. This view takes into account nonfunctional requirements like availability, reliability, performance, and scalability. Figure 6 is a deployment diagram of the example ordering system. It has one node for users who run the Web browser on their own computers. The ordering system and database are on their own nodes. The nodes contain one or more components, which can be either larger entities or smaller actual components. Figure 6. A deployment diagram of an ordering system ![]()
The "plus-one" view of the 4+1 view model consists of use cases and scenarios that further describe or consolidate the other views. As discussed in previous columns in this series, use cases represent the functional side of the system. In the case of the 4+1 model they are used to explain the functionality and structures described by the other views. Some of the other views also utilize use cases, like the sequence diagram shown in Figure 4. The use case view consists of use case diagrams and specifications detailing the actions and conditions inside each use case. See Resources for more about use cases.
The 4+1 view model is a useful, standardized method for studying and documenting a software system from an architectural perspective. In this fifth article in the "Designing software architectures" series, I've introduced you to the five views of the 4+1 model. Each view offers a window into a different layer of the system. Taken together they ensure that all of the important aspects of the system are studied and documented. Let's review the views:
Resources offers more links where you can learn about the 4+1 view model, as well as other architectural views. In next month's Architectural manifesto I will discuss the evaluation of architecture prototypes.
|