4+1 Architectural View Model

Illustration of the 4+1 Architectural View Model.

4+1 is a view model designed by Philippe Kruchten for "describing the architecture of software-
intensive systems, based on the use of multiple, concurrent views".[1] The views are used to
describe the system from the viewpoint of different stakeholders, such as end-users, developers
and project managers. The four views of the model are logical, development, process and
physical view. In addition selected use cases or scenarios are utilized to illustrate the architecture
serving as the 'plus one' view. Hence the model contains 4+1 views: [1]

Logical view : The logical view is concerned with the functionality that the system provides to
end-users. UML Diagrams used to represent the logical view include Class diagram,
Communication diagram, Sequence diagram [2].

Development view : The development view illustrates a system from a programmer's perspective
and is concerned with software management. This view is also known as the implementation
view. It uses the UML Component diagram to describe system components. UML Diagrams
used to represent the development view include the Package diagram [2].

Process view : The process view deals with the dynamic aspects of the system, explains the
system processes and how they communicate, and focuses on the runtime behavior of the system.
The process view addresses concurrency, distribution, integrators, performance, and scalability,
etc. UML Diagrams to represent process view include the Activity diagram[2].

Physical view : The physical view depicts the system from a system engineer's point-of-view. It
is concerned with the topology of software components on the physical layer, as well as
communication between these components. This view is also known as the deployment view.
UML Diagrams used to represent physical view include the Deployment diagram[2].

Scenarios : The description of an architecture is illustrated using a small set of use cases, or
scenarios which become a fifth view. The scenarios describe sequences of interactions between
objects, and between processes. They are used to identify architectural elements and to illustrate
and validate the architecture design. They also serve as a starting point for tests of an architecture
prototype. UML Diagram(s) used to represent the scenario view include the Use case diagram[2].
Overview

The Unified Process is not simply a process, but rather an extensible framework which should be
customized for specific organizations or projects. The Rational Unified Process is, similarly, a
customizable framework. As a result it is often impossible to say whether a refinement of the
process was derived from UP or from RUP, and so the names tend to be used interchangeably.

The name Unified Process as opposed to Rational Unified Process is generally used to describe
the generic process, including those elements which are common to most refinements. The
Unified Process name is also used to avoid potential issues of trademark infringement since
Rational Unified Process and RUP are trademarks of IBM. The first book to describe the process
was titled The Unified Software Development Process (ISBN 0-201-57169-2) and published in
1999 by Ivar Jacobson, Grady Booch and James Rumbaugh. Since then various authors
unaffiliated with Rational Software have published books and articles using the name Unified
Process, whereas authors affiliated with Rational Software have favored the name Rational
Unified Process.

[edit] Unified Process Characteristics

[edit] Iterative and Incremental

Diagram illustrating how the relative emphasis of different disciplines changes over the course of
the project

Software development process

Activities and steps

Requirements · Specification
 Architecture · Design
Implementation · Testing
Deployment · Maintenance

Methodologies

Agile · Cleanroom · Iterative

RAD · RUP · Spiral
Waterfall · XP · Lean
Scrum · V-Model · TDD

Supporting disciplines

Configuration management
Documentation
Quality assurance (SQA)
Project management
User experience design

Tools

Compiler · Debugger · Profiler

GUI designer · IDE

v·d·e

The Unified Process is an iterative and incremental development process. The Elaboration,
Construction and Transition phases are divided into a series of timeboxed iterations. (The
Inception phase may also be divided into iterations for a large project.) Each iteration results in
an increment, which is a release of the system that contains added or improved functionality
compared with the previous release.

Although most iterations will include work in most of the process disciplines (e.g. Requirements,
Design, Implementation, Testing) the relative effort and emphasis will change over the course of
the project.
[edit] Use Case Driven

In the Unified Process, use cases are used to capture the functional requirements and to define
the contents of the iterations. Each iteration takes a set of use cases or scenarios from
requirements all the way through implementation, test and deployment.

[edit] Architecture Centric

The Unified Process insists that architecture sit at the heart of the project team's efforts to shape
the system. Since no single model is sufficient to cover all aspects of a system, the Unified
Process supports multiple architectural models and views.

One of the most important deliverables of the process is the executable architecture baseline
which is created during the Elaboration phase. This partial implementation of the system serves
to validate the architecture and act as a foundation for remaining development.

[edit] Risk Focused

The Unified Process requires the project team to focus on addressing the most critical risks early
in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase,
must be selected in order to ensure that the greatest risks are addressed first.