Introducing the 4+1 view model

Document options
<noscript></noscript> <noscript>&amp;lt;tr valign=&amp;quot;top&amp;quot;&amp;gt;&amp;lt;td width=&amp;quot;8&amp;quot;&amp;gt;&amp;lt;img alt=&amp;quot;&amp;quot; height=&amp;quot;1&amp;quot; width=&amp;quot;8&amp;quot; src=&amp;quot;//;quot;/&amp;gt;&amp;lt;/td&amp;gt;&amp;lt;td width=&amp;quot;16&amp;quot;&amp;gt;&amp;lt;img alt=&amp;quot;&amp;quot; width=&amp;quot;16&amp;quot; height=&amp;quot;16&amp;quot; src=&amp;quot;//;quot;/&amp;gt;&amp;lt;/td&amp;gt;&amp;lt;td class=&amp;quot;small&amp;quot; width=&amp;quot;122&amp;quot;&amp;gt;&amp;lt;p&amp;gt;&amp;lt;span class=&amp;quot;ast&amp;quot;&amp;gt;Document options requiring JavaScript are not displayed&amp;lt;/span&amp;gt;&amp;lt;/p&amp;gt;&amp;lt;/td&amp;gt;&amp;lt;/tr&amp;gt;</noscript>
Set printer orientation to landscape mode

Print this page

Email this page

E-mail this page

<!-- START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- 11/28/07 refreshed by gem, per MOC --><!-- <br /> <table border="0" cellpadding="0" cellspacing="0" width="150"> <tr> <td class="v14-header-2-small">New forum features</td> </tr> </table> <table border="0" cellpadding="0" cellspacing="0" class="v14-gray-table-border"> <tr> <td width="150" class="no-padding"> <table border="0" cellpadding="0" cellspacing="0" width="143"> <tr valign="top"> <td width="8"><img src="//" mce_src="" width="8" height="1" alt="" /></td> <td><img src="//" mce_src="" height="16" width="16" border="0" vspace="3" alt="" /></td> <td width="125"> <p><a href=";S_CMP=LEAF" mce_href=";S_CMP=LEAF" class="smallplainlink">Try private messaging, read-tracking, and more </a> </p> </td> </tr> </table> </td> </tr> </table> --><!-- END RESERVED FOR FUTURE USE INCLUDE FILES-->
Rate this page

Help us improve this content

Level: Introductory

Mikko Kontio ( ), 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 type="text/javascript"><!-- capture_referrer(); // --></script>

<!-- START KRUGLE SEARCH HEADING PLAY <table width="580" cellspacing="0" cellpadding="0" border="0"> <tr> <td class="v14-header-5"> <b>Show more developerWorks content related to my search</b> </td> </tr> </table> --> <!-- START : HTML FOR ARTICLE SEARCH --> <!-- END : HTML FOR ARTICLE SEARCH --> <!-- START : HTML FOR CODE SEARCH --> <!-- END : HTML FOR CODE SEARCH -->

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 Image of the 4+1 views

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 A simple 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 A simple collaboration diagram of the ordering action

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 A sequence diagram shows in more detail how the objects interact

Back to top

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 The package diagram shows  the packages and how they are nested

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.

Back to top

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.

Back to top

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 A deployment diagram of the  ordering system

Back to top

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.

Back to top

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.


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 .

想对作者说点什么? 我来说一句