Week 10 Kruchten-4+1 View

4+1 View Model
Software Design &

Architecture
Outline
• Problem
• Solution
• 4+1 view model
• Logical view
• Process view
• Development view
• Physical view
• Use-case view
• The Notations
The Problem
• Arch. documents over-emphasize an aspect of development (i.e.

team organization) or do not address the concerns of all stakeholders.
• The stakeholders of software system:

• end-user,
• developers,
• system
• engineers,
projectengineers
• Software managers struggled to represent more on one blueprint,
and so architecture documents contains complex diagrams
Different stakeholders – different prospective
• Architecture also means different things to different stakeholders.

• For example,
• a Network Engineer would only be interested in the hardware and network
configuration of the system;
• a Project Manager in the key components to be developed and their
timelines;
• a Developer in classes that make up a component; and
• a Tester in testable scenarios.
Solution
Solution came from “4+1” view model
• The views are used to describe the system from the viewpoint of
different stakeholders, such as end-users, developers and project
managers.
• Suitable for large and challenging architectures
• Describe different aspects of the system into different views.

• (Why?) Because different stakeholders have different aspects
• DEVELOPERS – Aspects of Systems like classes
• SYSTEM ADMINISTRATOR – Deployment, hardware and network configuration
• TESTER , PM, CUSTOMER -- ???
• “4+1” view model provides a “better organization with better separation of
concern”.
4+1 View Model of Architecture
End user Programmers

& software
managers
Integrator System Engineer

4+1 view model architecture
(for distributed systems)
1. Logic a l w (or Structural View) - an object model of the
Design
2. Process View (or Behavioral View) - concurrency and
synchronization aspects
3. Development View (or Implementation View) - static
organization (subset) of the software
4. Physical View (or Deployment View) - mapping of the
software to the hardware
+1. U se-cases View ( or Scenarios) - various usage scenarios
Software architecture involves the high level structure of software system abstraction, by using decomposition and
composition, with architectural style and quality attributes. A software architecture design must conform to the major
functionality and performance requirements of the system, as well as satisfy the non-functional requirements such as
reliability, scalability, portability, and availability.
A software architecture must describe its group of components, their connections, interactions among them and
deployment configuration of all components.
1. Logical View = (The Object-oriented Decomposition)
• Viewer: End-user
• Considers: Functional Requirements- What the system should
provide in terms of services to its users.
• What this view shows?

• “This view shows the components (objects) of the system as well as
their interaction/relationship”.
• Notation: Object and dynamic models
• UML diagrams: Class, Object, State Machine, Composite Structure
diagrams
2. Process View = (The Process Decomposition)
• Viewer: Integrator(s)
• Considers: Non-Functional Requirements - (concurrency, performance,
scalability, usability, resilience, re-use, comprehensibility, economic
and
technology constraints, trade-offs, and cross-cutting concerns - like
security and transaction management)
• “This view shows the processes (workflow rules) of the system and how
those processes communicate with each other”.
• UML diagrams: Sequence, Communication, Activity, Timing,
Interaction
Overview diagrams
3. Development/Implementation View
= (The Subsystem
Decomposition)
• Viewer: Programmers and Software Managers
• Considers: Software module organization of layers,
software management, reuse, constraints of tools)
(Hierarchy
• “This view shows the building blocks of the system”.
• UML diagrams: Component, Package diagrams
• Package Details, Execution Environments, Class Libraries, Layers, Sub-system
design
4. Physical/Deployment View
= (Software to Hardware
Mapping)
• Viewer: System Engineers
• Considers: Non-functional Requirements for
(Topology, Communication)
hardware
• What this view shows? Non-functional
• “This view shows the system execution environment”.

• UML diagrams: Deployment diagrams
• Non-UML diagrams: Network Topology (not in UML)
5. Use-case View/Scenarios = (putting it altogether)
• Viewer: All users of other views and Evaluators

• Considers: System consistency, validity
• “This view shows the Validation and Illustration system
completeness.
of This view is redundant with other views.”.
• UML diagrams: Use-case diagram, User stories
Why is it called the 4 + 1 instead of just 5?
• The Use-case View: The use case view has a special significance.
Views are effectively redundant (i.e. Views are interconnected).
However, all other views would not be possible without use
case view.
It details the high levels requirements of the system.
The other views detail how those requirements are realized.
Correspondence between views
• Views are interconnected.
• They are very close, but the larger the project, the greater the
• Start with Logical view (Req. Doc) and Move to Development
distance. or Process
view and then finally go to Physical view.
1. From logical to Process view
 Two strategies to analyze level of concurrency:
 Inside-out: starting from Logical structure
 Outside-in: starting from physical structure
2. From Logical to development view
 Grouping to subsystems is based on:
 Classes
 Class packages
 Line of codes
 Team organization
Software Architecture Definition by IEEE
“Software Architecture is the fundamental organization

of a system, embodied in its components, their
relationships to each other and the environment, and
the principles governing its design and evolution.”
— The definition of Software Architecture as per IEEE Recommended

Practice for Architectural Description of Software Intensive Systems
(IEEE 1471-2000)
IEEE 1471's contributions can be summarized as follows
 provides definitions and description of architecture
 It states that an architecture should address a system's stakeholders concerns
 It asserts that architecture descriptions are inherently multi-view, no

single view adequately captures all stakeholder concerns
 It specifies the notions of view and viewpoint, where a viewpoint identifies the set
of concerns and the representations/modeling techniques, etc. used to describe
the architecture to address those concerns and a view is the result of applying a
viewpoint to a particular system.
 It establishes content requirements for architecture descriptions and the idea that
a conforming architecture description has a 1-to-1 correspondence between
its viewpoints and its views.

Week 10 Kruchten-4+1 View

Uploaded by

Copyright:

Available Formats

Week 10 Kruchten-4+1 View

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Week 10 Kruchten-4+1 View

Uploaded by

Copyright:

Available Formats

4+1 View Model

Software Design &

• Arch. documents over-emphasize an aspect of development (i.e.

• The stakeholders of software system:

• Architecture also means different things to different stakeholders.

• Describe different aspects of the system into different views.

End user Programmers

Integrator System Engineer

• What this view shows?

• “This view shows the system execution environment”.

• Viewer: All users of other views and Evaluators

“Software Architecture is the fundamental organization

— The definition of Software Architecture as per IEEE Recommended

 It states that an architecture should address a system's stakeholders concerns

 It asserts that architecture descriptions are inherently multi-view, no

You might also like