SWE411 Principles of Software Architecture Dr.

Nissreen El-Saber
WEEK 3 LECTURE 1

VIEWS AND VIEWPOINTS

3
 VIEWS AND VIEWPOINTS
Views are used to structure the architectural description into a number of pieces,
each describing one aspect of the system (the functional structure, the deployment
environment, the development constraints and so on). The architectural description
is made up of a set of views.

Viewpoints provide templates for the views and as such a particular viewpoint is
used to develop each view. A viewpoint provides the architect with guidance by
defining what the corresponding view should or may contain, how to represent it,
how to go about developing it, potential problems to be aware of and their solution,
and so on.

4
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
 … VIEWS AND VIEWPOINT

The use of Viewpoints and Views is an existing approach, that we have used
successfully, for dealing with complex architectural structures. Both ideas are simple
but have proved to be effective:

The relationship between view and viewpoint is similar to that of object and class. Using
viewpoints and views helps to organize both the process being followed (the viewpoints
providing implicit structure and explicit guidance) and the artefacts produced (the views being
an organization of the architectural description).
ARCHITECTURE VIEW MODEL
A model is a complete, basic, and simplified description of software architecture
which is composed of multiple views from a particular perspective or viewpoint.
A view is a representation of an entire system from the perspective of a related set
of concerns. It is used to describe the system from the viewpoint of different
stakeholders such as end-users, developers, project managers, and testers.

6
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
META-MODEL
FOR SOFTWARE
ARCHITECTURE

7
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
MORE ON VIEWS AND VIEWPOINTS
 Each view is constructed as a self-contained artifact, semi-independent of the others,
although interrelated.
 Views are then composed or integrated to yield the overall architectural description;
each distinct because their purposes differ– after all that was the whole point of
separation of concerns– but overlapping because they share a common subject, the
system.
 A viewpoint can be thought of as a domain-specific language. The purpose of a
viewpoint is to codify a specific set of concepts and relations for talking about a
particular set of concerns.

8
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
CONCEPTUAL
MODEL OF AN
ARCHITECTURE
DESCRIPTION

9
 10
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
4+1 VIEW MODEL
 The 4+1 View Model was designed by Philippe Kruchten.
 It describes the architecture of a software–intensive system based on the use of
multiple and concurrent views. It is a multiple view model that addresses different
features and concerns of the system. It standardizes the software design documents
and makes the design easy to understand by all stakeholders.
 It is an architecture verification method for studying and documenting software
architecture design and covers all the aspects of software architecture for all
stakeholders. It provides four essential views −

11
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
… 4+1 VIEW MODEL

12
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
… 4+1 VIEW MODEL
 The logical view or conceptual view − It describes the object model of the design.
 The process view − It describes the activities of the system, captures the concurrency and
synchronization aspects of the design.
 The physical view − It describes the mapping of software onto hardware and reflects its distributed
aspect.
 The development view − It describes the static organization or structure of the software in its
development of environment.

This view model can be extended by adding one more view called scenario view or use case view for
end-users or customers of software systems. It is coherent with other four views and are utilized to
illustrate the architecture serving as “plus one” view, (4+1) view model.

13
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
… 4+1 VIEW MODEL
Logical Process Development Physical Scenario
Shows the processes /
Workflow rules of Gives building block
Shows the component Shows the installation, Shows the design is
system and how those views of system and
(Object) of system as configuration and complete by
Description processes describe static
well as their deployment of performing validation
communicate, focuses organization of the
interaction software application and illustration
on dynamic view of system modules
system
System engineer,
Programmer and
End-User, Analysts Integrators & operators, system All the views of their
Viewer / Stake holder software project
and Designer developers administrators and views and evaluators
managers
system installers
Software Module
Nonfunctional
organization
Functional Non Functional requirement regarding System Consistency
Consider (Software
requirements Requirements to underlying and validity
management reuse,
hardware
constraint of tools)
Class, State, Object,
sequence, Component, Package
UML – Diagram Activity Diagram Deployment diagram Use case diagram
Communication diagram
Diagram
14
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
STANDARDS, SPECIFICATIONS AND
GUIDELINES
Relationship to Other Standards, Specifications, and Guidance Documents
- the TOGAF framework,
- the BIZBOK® Guide,
- UML,
- BPMN, and
- BMM.
https://pubs.opengroup.org/architecture/archimate31-
doc/apdxd.html#_Toc10045525
REFERENCES AND READING LIST
https://sparxsystems.com/enterprise_architect_user_guide/16.0/modeling_languag
es/archimate-viewpoints.html
https://pubs.opengroup.org/architecture/archimate31-doc/toc.html
https://www.computer.org/csdl/magazine/so/2010/06/mso2010060020/13rRUy0
8MDi

16
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.