[原]Software Architecture: 4+1 view

It's not the rule, but the PRINCIPLE.

Software architecture work is never trivial. In general, software is a set of well-defined behaviours on a set of data. To construct a software system, we need to identify the behaviours and data, which may be mapped to real world entities, procedures, and then organise them in a rationale way. After observing all these information, we must abstract the most useful information from real world problem. Efforts must be paid on the mapping, decomposition and abstraction, then comes the architecture of the system, which is the blueprint of the system.

However, many architects try putting too much information into one diagram, or a set of diagrams. Software architecture itself deals with design and implementation of high level structure of software, so it's good idea to seperate these diagrams at many levels.

Before we start, keep this in mind:

Software Architecture = Elements + Forms + Rationale/Constraints.

To describe the blueprint, 4+1 view model is used. The "4" views:

• The logical view, which is the object model of the design using an OOD model.

• The process view, which captures the concurrency and synchronization aspects of the design.

• The physical(deployment) view, whic describes the mapping of software onto hardware, and distributed aspect.

• The development(implementation) view, which describes the static organization of the s/w in its development.

The "1" view:

• The scenarios(use cases) view, which selects a few use cases to illustrated the architecutre.

Not all of these views are needed for all software architecture. It depends on the scale of system, platform, etc.

The Logical View

It's object-oriented decomposition of the s/w system, used to support the functional requirements. The s/w is decomposed to a set of key abstractions of the problem domain, in the form of objects or classes. Class diagram and lass templates is used in this view.

The Process View

It's process decomposition, takes into account some non-functional requirements, including performance, and availability.

So it adresses issues of:

• concurrency,

• distribution,

• integrity,

• fault-tolerance,

• how the abstraction from logical view fit with the process architecture.

Serval levels can be used to describe the process architecture. From top level down:

1. logical networks of communicating programs(processes), distributed across a set of h/w through LAN/WAN, or on a single h/w platform.

2. A group of tasks that form a executable unit(process). this level controls the process architecture, such as started, recovered, reconfigured, shut down.

3. Communications between tasks: synchronization, messages.

The Development(Implementation) View

This is the subsystem decomposition, and focouses on actual s/w module organization on the dev env. Subsystems are organized in a hierarchy of layers, and each layer provides a narrow and well-defined interface to layers above it. This view can be represented by module and sybsystem diagrams. All internal requirements go here. This view serves as basis for requirement allocation, allocation of work to teams, cost evaluation and planning, monitering the progress, reasoning of reuse, portability and security.

The Physical(Deployment) View

This view maps the s/w to the h/w. S/w executes on a network of computers (or processing nodes). It will take into account the non-functional requirements such as availability, reliability(fault-tolerance), performance(throughput) and scalability. In this view, several deployment configurations will used: testing, different h/w, different customers. So this view needs to be flexible so that different configurations will have a minimal impact on the source code.

The 4+1 view is shown as below:

(cited from ref 2)

Correspondence Between the Views

"The various views are not fully orthogonal or independent. Elements of one view are connected to elements in other views, following certain design rules and heuristics.

... several important characteristics of the classes of the logical architecture:

• Autonomy: are the objects active, passive, protected?

  • an active object takes the initiative of invoking other objects’ operations or its own operations, and has full control over the invocation of its own operations by other objects

  • a passive object never invokes spontaneously any operations and has no control over the invocation of its own operations by other objects

  • a protected object never invokes spontaneously any operations but performs some arbitration on the invocation of its operations.

• Persistence: are the objects transient , permanent? Do they the failure of a process or processor?

• Subordination: are the existence or persistence of an object depending on another object?

• Distribution: are the state or the operations of an object accessible from many nodes in the physical architecture, from several processes in the process architecture?" (cited from ref 1).

From logical to process

"In the logical view of the architecture we consider each object as active, and potentially “concurrent,” i.e., behaving “in parallel” with other objects, and we pay no more attention to the exact degree of concurrency."(cited from ref 1) Therefore the logical architecture takes into account only functional requirements.

However, this will cause huge overhead. We know process architecture is about performance, throughput, scalability, availability, etc, so process and logical architecture interfere each other.

To achieve the process architecture goal, classes and objects in logical architecture are catagorized per the characteristics listed above. The deployment architecture has impacts on process architecture as well - in other words, process architecture should make multiple deployment configuration possible.

Then finally comes the result: a mapping of classes of logical architecture onto a set of tasks and processes of process architecture. Typically to achieve this result several iterations are needed and decisions should be make on acceptable compromise (trade-offs).

Logical and Implementation architecture

Classes of logical architecture can be catagorized by functionality. Packages, subsystems can be used to group the classes. Additional constraints on the decomposition to packages and sybsystems is that they must be managable, and, sometimes reusable.

These 2 views are closely related but address different concerns. A functional requirement may be represented as a family of classes in logical view but several different layers in implementation view.

Applying with UML

(cited from ref 2)

Summary

Logical view: OOD diagrams used. Representing the classes and their relationships concerning functionality.

Process view: representing group of classes to form executable units.

Implementation view: representing layered subsystems.

Deployment view: representing possible system configurations.

(cited from ref 1)

References

1. "Architectural Blueprints - The "4+1" view Model of Software Architecture", by Philippe Kruchten.

2. "Applying 4+1 view Architecture with UML 2".

Copyleft (C) 2007-2009 raof01.

本文可以用于除商业外的所有用途。此处“用途”包括（但不限于）拷贝/翻译（部分或全部），不包括根据本文描述来产生代码及思想。若用于非商业，请保留此权利声明，并标明文章原始地址和作者信息；若要用于商业，请与作者联系（[e-mail]），否则作者将使用法律来保证权利。