This seminar lecture, provided at the Gran Sasso Science Institute, provides an overview on the role of abstraction in software architectures.

1. Università degli Studi dell’Aquila
Henry Muccini
DISIM, University of L’Aquila
henry.muccini@univaq.it, @muccinihenry, henrymuccini.com
@Gran Sasso Science Instutitue (GSSI) – Nov. 2013

2. 2
W
E
E
L
O
C
M

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

4. 4
Myself:

Main expertise: Software Architecture
Description, verification and validation
 Software Architecture:
 Guest member of the IFIP WG on Software Architecture
 Research on Architecture Description (with MDE)
 SA-based Testing:
 special Issue on “Software Architecture For Code Testing And
Analysis”
 PC co-chair of AST 2013 @ ICSE 2013
 Director of the TAROT 2013 software testing school
 Cooperation with some partner Universities in Spaign and China
 Resilience:
 SC chair of the SERENE workshop (http://serene.uni.lu/Workshops/)
 Co-founder of the ERCIM WG on Resilience

New interests:
 Architecting Wireless Sensor Networks
 Architecting Mobile-Enabled Systems

5. Research interests
on developing methods and tools for the
analysis and design of software architectures
→Architecture-driven Model-based Testing
→Model-checking Architectures
→Architecting Fault Tolerant Systems
→Interoperable and Multi-view Software Architecture
Descriptions
Other
→Global Software Engineering Education
→Architecting Wireless Sensor Network
→Model Driven Engineering

7. Software Engineering
Software System
Engineered Software System

8. Process: Architecture as an artefact
Requirements
Drives
Software
Architecture
Low Level Design
Implementation

9. Process: Architecture towards the process
Use Case
Model
Analysis
Model
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Models
Views
• The architecture includes a collection of views
• The architecture is NOT a single fase in the software
development process

11. The Software Architecture is the
earliest model of the whole software
system created along the software
lifecycle
 A set of components and connectors
communicating through interfaces
A set of architecture design decisions
Focus on set of views and viewpoints
Written according to architectural styles

12. 13
Let us reason about the
Gaudi’s Sagrada Familia

13. Software Architecture definitions
Perry and Wolf, ’92 (aspects):
→“Architecture
is concerned with the selection of architectural
elements, their interactions, and the constraints on those elements and
their interactions necessary to provide a framework in which to satisfy the
requirements and serve as a basis for the design.”
→Elements are divided into processing elements, data elements and
connection elements
Garlan and Shaw, ’93 (elements):
Architecture for a specific system may be captured as “a collection of
computational components - or simply components - together with a
description of the interactions between these components - the connectors
–”
→

14. 15
The power of abstraction…

15. TELECOM ITALIA NETWORK ARCHITECTURE
WDM
ADM
ADM
ADM
ADM
ADM
ADM
STM-16 Ring
ADM
ADM
ADM
WL
WL
STM-16 Ring
ADM
ADM
ADM
ADM
ADM
ADM
National Level
ADM
STM-4/16
SXA
ADM
Regional level
ADM
ADM
ADM
ADM
SXC
SXA
4/1
ADM
STM-4/16
SXA
ADM
STM-4/16
STM-1/4
ADM
ADM
ADM STM-1/4 ADM
ADM
ADM STM-1/4 ADM
ADM
Urban Level
ADM
ADM
ADM
ADM

16. Plugin
Development
Environment
Core
Runtime
Workspace
User Interface
Workbench
Java
Development
Tools
SWT
JFace

17. standard
standard
standard
standard
laws
standard
p
r
o
c
e
s
s

18. Privacy e confidentiality
Autenticity
Need of Standards
Shared Process Management
Scalability
Docs digitalization

19. C2
Ideas
Software
Architecture
synthesis
Architectural constraints
and requirements
Constraints
Req1:..
Req2:..
Req3:..
………
Architectural
requirements
Evaluation and
Decisions making
C3
C1
C4
Software
Architecture

20. But which Architecture?
Implications on
privacy, confidentiality, performance, scalability, maintaina

21. But which Architecture?
Implications on
privacy, confidentiality, performance, scalability, maintaina

22. The Software Architecture is the
earliest model of the whole software
system created along the software
lifecycle
 A set of components and connectors communicating
through interfaces
A set of architecture design decisions
Focus on set of views and viewpoints
Written according to architectural styles

23. Architecture Design Decisions
Decisions about:
Selected components/interfaces/connectors
Distribution/Configuration of
components/connectors
Expected behavior
SA Styles, Patterns and Tactics
HW/SW/Deployment and other views
Components’ Nesting and sub-systems
NF attributes

24. 25
Architecture as a set of design decisions
A set of architecture design decisions taken to generate
the architecture artifact
Design
problem
subproblem
(or issue)
sub-
problem
(or issue)
Decision =
best option
Design
option
Design
option
Alternative
solutions
Problem space
Design
option
Alternative
solutions
Design
option
Solution
space
Decision =
best option
Best, with respect
to some criterion
Jansen, A.; Bosch, J., "Software Architecture as a Set of Architectural Design
Decisions," Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP
Conference on , vol., no., pp.109,120, 2005. doi: 10.1109/WICSA.2005.61

25. 26
But, which is the right abstraction!?!

26. 27
the right abstraction…

27. “The practices of recording
software, system and
enterprise architectures so
that architectures can be
understood, documented, an
alysed and realized.”
ISO/IEC/IEEE 42010 - International Standard for Systems and Software Engineering – Architectural
Description, 2011

28. 29
and, which is the right architecture!?!

29. 30
the right architecture…
The one that satisfies at best the
requirements and constraints
The “less” risky one
C2
Ideas
Software
Architecture
synthesis
Architectural constraints
and requirements
Constraints
Req1:..
Req2:..
Req3:..
………
Architectural
requirements
Evaluation and
Decisions making
C3
C1
C4
Software
Architecture

30. The Software Architecture is the
earliest model of the whole software
system created along the software
lifecycle
 A set of components and connectors communicating
through interfaces
A set of architecture design decisions
Focus on set of views and viewpoints
Written according to architectural styles

32. 33
Architectural Views
AckRU1
AlarmUR1
User1
Check1
AlarmRS (c)
AlarmUR
Check
Router
Nofunc
3
Server
AlarmUR2
User2
Check2
AckSR (c)
2
0
Clock
AckRU2
Timer
5
1
4

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

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

35. Using multiple views has become standard
practice in industry
•
•
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)

36. The Software Architecture is the
earliest model of the whole software
system created along the software
lifecycle
 A set of components and connectors communicating
through interfaces
A set of architecture design decisions
Focus on set of views and viewpoints
Written according to architectural styles

37. The Classical Style
The Californian Style

38. 39
but... why to care?

39. Why to care?
All the software systems have an architecture

All the critical/complex systems must have it carefully and
explicitly specified
Architecture-level decisions impact the
scalability, performance, testability, functioning of the
produced system
Even if the code is perfectly written, a wrong
architecture produces a wrong system

40. Why to care?
A wrong architecture produces a wrong system


Electronic Voting Systems
Bad architecting of FT software:
 Tens of thousands of people around the large cities weren’t able to travel by
train Thursday morning. No trains from and to Amsterdam and Airport
Schiphol from early morning until after the morning rush hour. A failure in
the back-up system was the cause. The system therefore didn’t start. And
then the signals and switches could not be operated. Both primary and
backup failed, hence no operations. (april 2012)
 the Interim Report on Causes of the August 14th 2003 Blackout in the US
and Canada clearly shows that the problem was mostly caused by badly
designed fault tolerance, including various architectural issues: poor
diagnostics of component failures, longer-than-estimated time for
component recovery, failure to involve all necessary components in
recovery, inconsistent system state after recovery, failures of alarm
systems. (2003)

Denver Airport

41. Why to care?

42. A bad architecture can imply a spaghetti code
system

43. 44
Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software
architecture". ACM SIGSOFT Software Engineering Notes 17 (4):
40.doi:10.1145/141874.141884.
Garlan & Shaw (1994). "An Introduction to Software Architecture".
Retrieved 2012-09-13.
ISO/IEC/IEEE (2011). "ISO/IEC/IEEE 42010:2011 Systems and software
engineering -- Architecture description". Retrieved 2012-09-12.
Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1”
View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.
Len Bass, Paul Clements, Rick Kazman: Software Architecture in
Practice, Third Edition. Addison Wesley, 2012, ISBN 0-321-81573-4 (This
book, now in third edition, eloquently covers the fundamental concepts of
the discipline. The theme is centered around achieving quality attributes of a
system.)