 From: http://www-128.ibm.com/developerworks/wireless/library/wi-arch11/ Modified a little by Newweapon. |  |
| |
|
Level: Introductory
Mikko Kontio ([email protected]), 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.
<script language="JavaScript" type="text/javascript"> </script>
| | More dW content related to: 4+1 views | |
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.
Figure 1. The 4+1 view model End User Programmer
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 logical view
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
Item
s. You could then pass the vector and a
Customer
id to the
Order
constructor. (Note that doing this would change the roles of the
Customer
and
Order
classes completely.)
Figure 4. A sequence diagram of an ordering system
| |
|
The development view
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
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
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
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.
| |
|
In conclusion
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:
- The logical view describes the (object-oriented system) system in terms of abstractions, such as classes and objects. The logical view typically contains class diagrams, sequence diagrams, and collaboration diagrams. Other types of diagrams can be used where applicable.
- The development view describe the structure of modules, files, and/or packages in the system. The package diagram can be used to describe this view.
- The process view describes the processes of the system and how they communicate with each other.
- The physical view describes how the system is installed and how it executes in a network of computers. Deployment diagrams are often used to describe this view.
- The use case view describes the functionality of the system. This view can be described using case diagrams and use case specifications.
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.
Resources
- Mikko talked about use case diagramming in his column on "How to write a requirements specification" (developerWorks, December 2004).
- You can learn more about the 4+1 view model by reading Phillipe Krutchen's "The "4+1" View Model of Software Architecture" (in PDF format).
- Phillipe Krutchen's "The Tao of the Software Architect" is one of the Software Engineering Institute's published essays on software architecture.
- "Documenting Software Architectures," a comprehensive handbook about software documentation, includes an excellent section on views.
- Visit the OMG's UML homepage to learn more about the Unified Modeling Language
- Granville Miller's UML modeling workbook (developerWorks, May 2001 through June 2002) is a hands-on introduction to use case development and the Unified Modeling Language.
- "Documenting software architectures" (The Rational Edge, January 2004) is one architect's account of the importance of good documentation in large-scale development projects -- as well as a review of a book worth reading.
- See the Architectural Manifesto column page for a complete listing of Mikko's columns, as well as all the articles in the Designing software architectures series.
About the author
| | |
| | Mikko Kontio works as a Production Manager for the leading-edge Finnish software company, Softera. He holds a Masters degree in Computer Science and is the author and co-author of several books, the latest being Professional Mobile Java with J2ME, published by IT Press. Mikko can be reached at [email protected]. |