Introducing the 4+1 view model

本文介绍4+1视图模型,一种用于从不同角度理解软件架构的方法。包括逻辑视图、开发视图、过程视图、物理视图及用例视图,帮助架构师全面了解系统。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

From: http://www-128.ibm.com/developerworks/wireless/library/wi-arch11/ 

Modified a little by Newweapon.

developerWorks
Document options
Set printer orientation to landscape mode

Print this page

Email this page

E-mail this page


Rate this page

Help us improve this content


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.


Figure 1. The 4+1 view model  End User                Programmer
Image of the 4+1 views 

   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
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 Items. 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.



Resources



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 mikko.kontio@softera.fi.

 
Chapter 4: Processor Architecture. This chapter covers basic combinational and sequential logic elements, and then shows how these elements can be combined in a datapath that executes a simplified subset of the x86-64 instruction set called “Y86-64.” We begin with the design of a single-cycle datapath. This design is conceptually very simple, but it would not be very fast. We then introduce pipelining, where the different steps required to process an instruction are implemented as separate stages. At any given time, each stage can work on a different instruction. Our five-stage processor pipeline is much more realistic. The control logic for the processor designs is described using a simple hardware description language called HCL. Hardware designs written in HCL can be compiled and linked into simulators provided with the textbook, and they can be used to generate Verilog descriptions suitable for synthesis into working hardware. Chapter 5: Optimizing Program Performance. This chapter introduces a number of techniques for improving code performance, with the idea being that programmers learn to write their C code in such a way that a compiler can then generate efficient machine code. We start with transformations that reduce the work to be done by a program and hence should be standard practice when writing any program for any machine. We then progress to transformations that enhance the degree of instruction-level parallelism in the generated machine code, thereby improving their performance on modern “superscalar” processors. To motivate these transformations, we introduce a simple operational model of how modern out-of-order processors work, and show how to measure the potential performance of a program in terms of the critical paths through a graphical representation of a program. You will be surprised how much you can speed up a program by simple transformations of the C code. Bryant & O’Hallaron fourth pages 2015/1/28 12:22 p. xxiii (front) Windfall Software, PCA ZzTEX 16.2 xxiv Preface Chapter 6: The Memory Hierarchy. The memory system is one of the most visible parts of a computer system to application programmers. To this point, you have relied on a conceptual model of the memory system as a linear array with uniform access times. In practice, a memory system is a hierarchy of storage devices with different capacities, costs, and access times. We cover the different types of RAM and ROM memories and the geometry and organization of magnetic-disk and solid state drives. We describe how these storage devices are arranged in a hierarchy. We show how this hierarchy is made possible by locality of reference. We make these ideas concrete by introducing a unique view of a memory system as a “memory mountain” with ridges of temporal locality and slopes of spatial locality. Finally, we show you how to improve the performance of application programs by improving their temporal and spatial locality. Chapter 7: Linking. This chapter covers both static and dynamic linking, including the ideas of relocatable and executable object files, symbol resolution, relocation, static libraries, shared object libraries, position-independent code, and library interpositioning. Linking is not covered in most systems texts, but we cover it for two reasons. First, some of the most confusing errors that programmers can encounter are related to glitches during linking, especially for large software packages. Second, the object files produced by linkers are tied to concepts such as loading, virtual memory, and memory mapping. Chapter 8: Exceptional Control Flow. In this part of the presentation, we step beyond the single-program model by introducing the general concept of exceptional control flow (i.e., changes in control flow that are outside the normal branches and procedure calls). We cover examples of exceptional control flow that exist at all levels of the system, from low-level hardware exceptions and interrupts, to context switches between concurrent processes, to abrupt changes in control flow caused by the receipt of Linux signals, to the nonlocal jumps in C that break the stack discipline. This is the part of the book where we introduce the fundamental idea of a process, an abstraction of an executing program. You will learn how processes work and how they can be created and manipulated from application programs. We show how application programmers can make use of multiple processes via Linux system calls. When you finish this chapter, you will be able to write a simple Linux shell with job control. It is also your first introduction to the nondeterministic behavior that arises with concurrent program execution. Chapter 9: Virtual Memory. Our presentation of the virtual memory system seeks to give some understanding of how it works and its characteristics. We want you to know how it is that the different simultaneous processes can each use an identical range of addresses, sharing some pages but having individual copies of others. We also cover issues involved in managing and manipulating virtual memory. In particular, we cover the operation of storage allocators such as the standard-library malloc and free operations. CovBryant & O’Hallaron fourth pages 2015/1/28 12:22 p. xxiv (front) Windfall Software, PCA ZzTEX 16.2 Preface xxv ering this material serves several purposes. It reinforces the concept that the virtual memory space is just an array of bytes that the program can subdivide into different storage units. It helps you understand the effects of programs containing memory referencing errors such as storage leaks and invalid pointer references. Finally, many application programmers write their own storage allocators optimized toward the needs and characteristics of the application. This chapter, more than any other, demonstrates the benefit of covering both the hardware and the software aspects of computer systems in a unified way. Traditional computer architecture and operating systems texts present only part of the virtual memory story. Chapter 10: System-Level I/O. We cover the basic concepts of Unix I/O such as files and descriptors. We describe how files are shared, how I/O redirection works, and how to access file metadata. We also develop a robust buffered I/O package that deals correctly with a curious behavior known as short counts, where the library function reads only part of the input data. We cover the C standard I/O library and its relationship to Linux I/O, focusing on limitations of standard I/O that make it unsuitable for network programming. In general, the topics covered in this chapter are building blocks for the next two chapters on network and concurrent programming. Chapter 11: Network Programming. Networks are interesting I/O devices to program, tying together many of the ideas that we study earlier in the text, such as processes, signals, byte ordering, memory mapping, and dynamic storage allocation. Network programs also provide a compelling context for concurrency, which is the topic of the next chapter. This chapter is a thin slice through network programming that gets you to the point where you can write a simple Web server. We cover the client-server model that underlies all network applications. We present a programmer’s view of the Internet and show how to write Internet clients and servers using the sockets interface. Finally, we introduce HTTP and develop a simple iterative Web server. Chapter 12: Concurrent Programming. This chapter introduces concurrent programming using Internet server design as the running motivational example. We compare and contrast the three basic mechanisms for writing concurrent programs—processes, I/O multiplexing, and threads—and show how to use them to build concurrent Internet servers. We cover basic principles of synchronization using P and V semaphore operations, thread safety and reentrancy, race conditions, and deadlocks. Writing concurrent code is essential for most server applications. We also describe the use of thread-level programming to express parallelism in an application program, enabling faster execution on multi-core processors. Getting all of the cores working on a single computational problem requires a careful coordination of the concurrent threads, both for correctness and to achieve high performance翻译以上英文为中文
最新发布
08-05
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值