4+1. describing the architecture of software-intensive systems, based on the use of multiple, concurrent views.
The views are used to describe the system from the viewpoint of different stakeholders,
2. 4+1 Architectural view model
By Philippe Kruchten - Canadian software engineer,
Professor of Software Engineering at University of
British Columbia in Vancouver, Canada,
2
3. Introduction 4+1 architectural M. V.
4+1. describing the architecture of software-intensive
systems, based on the use of multiple, concurrent views.
The views are used to describe the system from the
viewpoint of different stakeholders,
such as
o End-users,
o Developers,
o project managers and
o System Engineers.
3
4. Introduction 4+1 architectural M. V.
The four views of the model are_
Logical view,
Development view,
Process view and
Physical view.
In addition selected use cases or scenarios
as the 'plus one' view.
4
7. Logical View and the Process View are at a Conceptual
level
Used from analysis to design.
The Implementation View and the Deployment View are at
the Physical level
Used represent the actual application components built and
deployed.
7
8. Logical view
(Object-oriented Decomposition)
Logical Architects use this view for functional analysis
UML diagrams used to represent the logical view include,
class diagrams, and state diagrams.
Viewer:End-user
considers: Functional requirements-What the system
should provide in terms of services to its users.
8
9. Logical view
The system is decomposed into a set of key abstractions,
taken (mostly) from the problem domain, in the form of
objects or object classes.
They exploit the principles of abstraction, encapsulation,
and inheritance.
9
18. Process View
(The process decomposition)
Viewer:Integrators
Considers: Non -functional requirements
This view considers non-functional aspects such as
performance,
Concurrency,
scalability and
throughput.
To understand the organization processes, the process architectural view is used
in the Analysis and Design.
18
19. Process View
The process view allows you to show
what the system does at a high level, and
how the smaller steps within the process fit together.
It clears the processes steps, order and flow of information.
the major flows of information through the system well understood and
documented.
19
22. Implementation View
(Subsystem decomposition)
Viewer: Programmers and Software Managers
Considers: software module organization
(Hierarchy of layers, software management,
reuse, constraints of tools)
Focuses on configuration management and actual software module organization.
Component Diagrams are used to represent the Implementation View
These diagrams show different components, the ports available and the
dependencies on the environment in terms of provided and required interfaces.
22
23. The implementation view is useful for:
assigning implementation work to individuals and
teams, or subcontractors
assessing the amount of code to be developed,
modified, or deleted
reasoning large-scale reuse
considering release strategies
23
Implementation View
26. Physical View
(Mapping the software to the Hardware)
Viewer: System Engineers
Considers: Non-functional req. regarding to underlying hardware
(Topology, Communication)
Understanding the physical distribution of the system across a set of processing
nodes.
The distribution of processing across a set of nodes in the system, including the
physical distribution of processes and threads.
26
29. Scenario View
(Putting it all together)
Viewer: All users of other views and Evaluators.
Considers: System consistency, validity
Notation: almost similar to logical view
The scenarios describe sequences of interactions between objects
and between processes.
a use case is a list of actions or event steps typically defining the
interactions between a role (known in the UML as an actor) and a
system to achieve a goal.
The actor can be a human or other external system.
In systems engineering use cases are used at a higher level than
within software engineering often representing missions or
stakeholder goals.
29