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)
• What this view shows?
• “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
• What this view shows?
• “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
• What this view shows?
• “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.
