Haramaya

university
Members name Id
Endale Tilahun 1749/10
Kasahun Desalegn 1763/10
College of computing and Informatics Hanisa Nasir 1757/10
Department of Software Engineering Helen Negash 1758/10
Tesfaye Godeso 1784/10
The “4+1”
Architectural View
Model
The “4+1” architectural view model

OUTLINE

Introduction
The 4+1 views model
Types of 4+1 views
Logical view
Development view
 Introduction 

This article presents a model for describing the architecture of software-

intensive systems, based on the use of multiple, concurrent views.

This use of multiple views allows to address separately the concerns of

the various ‘stakeholders’ of the architecture:
◦ end-user,
◦ developers,
◦ systems engineers,
◦ project managers, etc.,
And to handle separately the functional and non-functional
requirements.
 Cont.…
Each of the five views is described, together with a notation to
capture it. The views are designed using an architecture-centered,
scenario-driven, iterative development process.
To describe a software architecture, we use a model composed of
multiple views or perspectives.
More on “4+1” View Model

4+1 is a view model used for "describing the architecture of software-intensive

systems, based on the use of multiple, concurrent views". 

The four views of the model are

◦ logical,
◦ development,
◦ process
◦ physical view.

In addition, selected use-cases or scenarios are used to illustrate the architecture

serving as the 'plus one' view.
Views – Logical View
The logical view, which is the object model of the design.
It primarily supports the functional requirements.
They exploit the principles of abstraction, encapsulation, and
inheritance.
We use the Rational/ Booch approach, UML (Unified Modeling
Language) for representing the logical architecture, by means
of class diagrams.
◦ Viewer: End-user
Views – Logical Cont.
◦ Focuses: Functional Requirements
◦ What the system should provide in terms of services to its
users.
◦ This view shows the components (objects) of the system as
well as their interaction/relationship.

UML diagrams: Class diagram, Object diagram, State Machine,

Composite Structure diagrams
 Views – Development View
The development view, which describes the static organization
of the software in its development environment.
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.
 Views – Development View
◦ Viewer: Programmers and Software Managers
◦ Focuses: Software module organization
◦ Hierarchy of layers, software management, reuse, constraints
of tools.
◦ This view shows the building blocks of the system.
UML diagrams: Component, Package diagrams
The development architecture focuses on the actual software
module organization on the software development
environment.
 Views – Development View
The development view serves as the basis for:-
- Requirement allocation,
- For allocation of work to teams (or even for team
organization),
-For cost evaluation and planning,
-For monitoring the progress of the project,
-For reasoning about software reuse,
-Portability and security.
-It is the basis for establishing a line-of-product.
 Examples
Logical View
1. Class diagram
Class diagram is a static diagram. It represents the static view of an
application. Class diagram is not only used for visualizing, describing, and
documenting different aspects of a system but also for constructing
executable code of the software application.
Class diagram shows a collection of classes, interfaces, associations,
collaborations, and constraints. It is also known as a structural diagram.
 Examples
Logical View

The purpose of the class diagram can be summarized as −

Analysis and design of the static view of an application.
Describe responsibilities of a system.
Base for component and deployment diagrams.
Forward and reverse engineering.
Class Diagram for Order system
 Examples
Logical View
2. Object diagrams
Object diagrams are derived from class diagrams so object diagrams are dependent
upon class diagrams.
Object diagrams represent an instance of a class diagram. The basic concepts are similar
for class diagrams and object diagrams. Object diagrams also represent the static view of
a system but this static view is a snapshot of the system at a particular moment.
Object diagrams are used to render a set of objects and their relationships as an
instance.
 Examples
Logical View
2. Object diagrams
The purpose of the object diagram can be summarized as −
■ Forward and reverse engineering.
■ Object relationships of a system
■ Static view of an interaction.
■ Understand object behavior and their relationship from practical perspective
Object Diagram for Order system
 Examples
Development View
Component diagrams
■ Component diagrams are used to model the physical aspects of a system. Now the
question is, what are these physical aspects? Physical aspects are the elements such as
executables, libraries, files, documents, etc. which reside in a node.
■ It does not describe the functionality of the system but it describes the components
used to make those functionalities.
■ Component diagrams are used to visualize the organization and relationships among
components in a system. These diagrams are also used to make executable systems.
 Examples
Development View
Component diagrams
The purpose of the component diagram can be summarized as −
■ Visualize the components of a system.
■ Construct executables
■ Describe the organization and relationships of the components.
Component Diagram for Translator system