This document discusses views and viewpoints in software architecture. It defines a viewpoint as a way of looking at a system that defines conventions for constructing views. A view is the result of applying a viewpoint to a system. The document discusses how stakeholders have different concerns that shape the viewpoints and views. It provides examples of viewpoints like the Rational Unified Process 4+1 views. The document emphasizes that using multiple views aligned with stakeholder concerns has become a standard practice in architecture description.

1. Views and Viewpoints
Henry Muccini
henry.muccini@univaq.it
DISIM
Dep.nt of Information Engineering, Computer Science and Mathematics
University of L’Aquila, Italy

2. The material in these slides may be freely reproduced
and distributed, partially or totally, as far as an explicit
reference or acknowledge to the material author is
preserved.
SEA Group
Henry Muccini

3. Intro to SA
SA Case study
SA style
ADLs
Design Decisions
Views/Viewpoints
SEA Group
Non Functional S.E.
Performance modeling
Performance analysis
UML
UML Profiling
Lab

4. Software Architecture
The Software Architecture is the earliest model of the
whole software system created along the software
lifecycle
“Traditional” definition:
→A set of components and connectors communicating through
interfaces
“Recent/Future” understanding:
SEA Group
→Focus on set of Views and Viewpoints, looking at
stakeholders and their concern
→A set of architecture design decisions taken to generate the
architecture artifact

5. SEA Group
Architecture as a set of Viewpoints

6. Structure
Behavior
Hw/Sw
Real-time
…
SEA Group

7. SEA Group

8. Two important views
SEA Group
Structural Spec. Behavioral Spec.
User1
AlarmUR AlarmRS (c)
Router Server
Timer
Check1
Nofunc
Clock
AckSR (c)
AckRU1
User2
AlarmUR1
AlarmUR2
Check2
Check
AckRU2
3
2 0 1
4
5
-Formal ADLs
-UML notations
- Posets, pre-post conditions
- Process Algebras
- Labeled Transition Systems,
IO Automata, IOLTS
- Statechart, UML state machine

9. SEA Group

10. SEA Group

11. SEA Group

12. SEA Group

13. SEA Group

14. SEA Group ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural
Description, 2011

15. Architecture Description is the practice of expressing
architectures (ISO/IEC 42010)
“The practices of recording software, system and
enterprise architectures so that architectures can be
understood, documented, analysed and realized.”
“Architecture descriptions are created by architects
and used by architects and other stakeholders
throughout all stages of a system’s life cycle, from
development through operation and maintenance.”
SEA Group

16. SEA Group
1) Architecture Viewpoints:
define the contents of each architecture view;
2) Architecture Frameworks (AFs):
coordinated set of viewpoints for use within a
particular stakeholder community or domain of
application (e.g., GERAM, TOGAF, MODAF);
3) Architecture Description Languages (ADLs):
any mode of expression used in an architecture
description.
ADL provides model kinds selected to frame one
or more concerns.

17. SEA Group ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural
Description, 2011

18. Stakeholders concerns can vary tremendously (and change
over time), depending on:
• the nature of the system
• project-specific constraints
• organizational constraints
• the application domain
• …
SEA Group

19. Software Architect
Software Developer
Financial manager
Business manager
SEA Group
…
…

20. Example
SEA Group

21. SEA Group ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural
Description, 2011

22. […] “a viewpoint is a way of looking at a system; a view is what you see”
“A viewpoint defines the conventions (such as notations, languages and
types of models) for constructing a certain kind of view”
[…]”viewpoint refers to the conventions for representing an architecture
relative to one set of concerns.”
“A view is the result of applying a viewpoint to a particular system of
interest”
[…] “viewpoints as first-class entities of architecture descriptions.”
view : viewpoint :: program : programming language
SEA Group
From the ISO/IEC/IEEE 42010

23. SEA Group ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural
Description, 2011

24. 2) Architecture Frameworks (AFs):
coordinated set of viewpoints for use within a
particular stakeholder community or domain of
application (e.g., GERAM, TOGAF, MODAF);
SEA Group ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural
Description, 2011

25. RUP 4+1 views
SEA Group
Logical View
Object Model
of Design
End-user
Functionality
Implementation (Development) View
Static Organization
of the Software
Programmers
Software management
Process View
Use Case View
System integrators
Performance
Scalability
Throughput
Deployment View
Concurrency and
Synchronization
Software Mapping
System engineering To Hw
System topology
Delivery, installation
Communication
Conceptual Physical

26. SEA Group
Models
Views
Use Case
Model
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Analysis
Model

27. Architectural views: Applied SA [Applied] & UML Process [UMLProcess]
[Applied]
Still based on Architectural views…
SEA Group
→Conceptual
→Module
→Execution
→Code
… but more Diagrams for each view
[UMLProcess]
[Applied] C. Hofmeister, R. Nord
and D. Soni. Applied Software
Architecture. Addison-Wesley.
1998.
[UMLProcess] I. Jacobson, G.
Booch and J. Rumbaugh.
The Unified Software Development
Process. Addison Wesley,
Object Technology Series, 1999.

28. Using multiple views has become standard practice in
industry
SEA Group
• IEEE Std 1471 (2000) -> … -> ISO/IEC/IEEE 42010 (2011)
• Based on a survey we conducted with 48 practitioners
[Survey2012], and about the usage of ALs in industry
 85% uses multiple views
[Survey2012] “What Industry needs from Architectural Languages: A Survey”, I. Malavolta, P. Lago, H.
Muccini, P. Pelliccione, A. Tang (under review)

29. Views and Viewpoints
Based on the informal description of the SA, identify:
•Stakeholders
•Concerns
•Concern–Stakeholder Traceability (see example below)
SEA Group
Service
Provider
Client
WSN
Developer
Mobile App
Developer
System
Integrator
Dependability X X X X
Energy
Consumption
X
Networking &
Communication
X X X
Usability X X X
Performance X X X
Security X X X
Cost X X

30. System Architecture View
Small overview of the System view.
Design Decisions
In this section, you are required to document the three (3) most important design decisions
using the QOC Template. For “most important” we mean those that may have a bigger impact
on your architecture, those that you discussed more, or you think are the most relevant. The
QOC Template is available in SVN. You are required to provide both the tabular representation
and the graphical one inside this document.
Models
In this section, you are required to show a picture of the SID model (by using any graphical tool
such as Powerpoint, Visio, OmniGraffle, etc.), the FSP specification (only its textual
representation), and to describe all of them in details. The models must address all of the
concerns framed by the view’s governing viewpoint and cover the whole system from that
viewpoint.
Known Issues
Document any discrepancies between the view and its viewpoint conventions. Each architecture
view must adhere to the conventions of its governing architecture viewpoint. Known issues
could include: inconsistencies, items to be completed, open or unresolved issues, exceptions and
deviations from the conventions established by the viewpoint. Open issues can lead to decisions
to be made. Exceptions and deviations can be documented as decision outcomes and rationale.
SEA Group