This seminar lecture, provided at the Gran Sasso Science Institute, provides an overview on software architecture styles, product lines, and my research

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. 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

3. Prescriptive vs descriptive use of an architectural
language

4. The Classical Style
The Californian Style

5. “A set of design rules that identify the kinds of components
and connectors that may be used to compose a system
or subsystem, together with local or global constraints on
the way the composition is done” (Shaw & Clements, 1996)
IMP
A set of constraints you put on your development to elicit desirable
properties from your software architecture.
Topological
Behavioral
Communication-oriented
etc. etc.

6. Architectural styles typically determine four kinds of
properties [AAG93]:
IMP

7. Many similarities between patterns and styles
But they have come from different communities
Differences
Architectural Styles
Design Patterns
Few
Many
Large-scale system
organization
Localized, small-scale
design solutions

8. ElevatorSynchronizer
ElevatorADT1
ElevatorPanel1
ElevatorSynchronizer
ElevatorADT2
ElevatorADT2
ElevatorADT1
ElevatorPanel2
ElevatorPanel1
ElevatorPanel2
Scheduler
Scheduler
C2 connector
C2 component
BuildingPanel
comm. channel
request
notification
BuildingPanel

9. 1. The top of a component may be connected to the
bottom of a single connector.
2. The bottom of a component may be connected to
the top of a single connector.
3. There is no bound on the number of components
or connectors that may be attached to a single
connector.
4. When two connectors are attached to each other,
it must be from the bottom of one to the top of
the other.
5. Components can communicate only through
connectors

10. 10

11. Application
Application
Presentation
Presentation
Session
Session
Transport
Transport
Network
Network
Network
Network
Data Link
Data Link
Data Link
Data Link
Physical
Physical
Physical
Physical

12. Advantages
Disadvantages

13. GLOBAL
XCONN
XCONN
SHELF
PERIPHE
RAL
XCONN1
XCONN1
1..1
1..1
1..2
1..1
1..2
XCONN2
1..1
XCONN2
1..1
1..1
XCONN3
1..1
1..1
1..1
…
1..1
1..1
1..1
…
1..1
XCONN3
1..1

14. Blackboad style
1..*
Controller
KS
1..*
Blackboard

15. The Blackboard Style
This style is characterized by a central data structure and a collection of
components operating on the central data store
The Blackboard is characterized by three main types of
components (Corkill, 1991):
Connector
Property

16. Advantages
Disadvantages

18. Distributed Peer-to-Peer Systems
Components
Connectors
Configurations
Computational model

19. 3-Tier Client/Server Systems (example)

20. WHAT IS P2P?
3rd: SKYPE

21. Advantages
Disadvantages
Distributed state
Potential for deadlock, starvation, race conditions, service outages
Data marshalling and unmarshalling
Proxies and stubs for RPC
Legacy wrappers

22. 22
[Garlan94] Exploiting Style in Architectural Design
Environments, David Garlan, Robert Allen and John Ockerbloom.
Proceedings of SIGSOFT '94 Symposium on the Foundations of
Software Engineering, December 1994.
[SC97] A Field Guide to Boxology: Preliminary Classification of
Architectural Styles for Software Systems, M. Shaw and P.
Clements, In Proc. COMPSAC97, 21st Int'l Computer Software
and Applications Conference, August 1997, pp. 6-13.
[Shaw96] Some Patterns for Software Architectures, M. Shaw,
In John Viissides, James O. Coplien, and Norman L. Kerth,
editors, Pattern Languages of Program Design 2. AddisonWesley, 1996.

23. The Software Architecture is the
earliest model of the whole software
system created along the software
lifecycle
 A brief Introduction to Product Lines
(i.e., families of products)

24. Product Lines and Product Families
Product Line:
→ This
term was introduced by the US community
Product Family:
→ This
term originated within a series of European
industrial-cooperation projects

25. Product Line
Definition:
A software product line is a set of software intensive
systems sharing a common, managed set of features that
satisfy the specific needs of a particular market segment
or mission and that are developed from a common set of
core assets in a prescribed way.
[P. Clements - L. M. Northrop, 2001]
(Software Engineering Institute, CMU)

26. The general idea…
The idea behind a system-family approach is to:
→ build
a new system or application from a common
set of assets…
─ A software asset might be a component, known
requirements or design elements, models, artifacts that
an engineer uses to build or modify a software
product…
→ in
the same line (i.e., domain)…
─ pertaining to a general production line of a company

27. 27
An example

28. An example
• Car product line

29. Keywords > 1/3
Variability:
→
Variability is the ability to change or customize a software
system [Jan Bosch, 2002]
Variation point:
A variation point refers to a delayed design decision, i.e., it
indicates a specific point in the development or deployment
phase of a software system
→ The intention of designing a variation point into a system is
to insert a variant (alternative) at a later phase in the
lifecycle
→

30. Keywords > 2/3
Features:
Underlying def: a feature groups related requirements
→ Features are an abstraction mechanism to express variability
→ Cross-cutting features
→ FODA: Feature Oriented Domain Analysis
→

31. Keywords > 3/3
Levels:
→
→
Domain
Application

32. Why Product Lines?

33. 33
Feature Model

34. Product Lines and Reuse

35. 35
SPLC Conference

36. The Software Architecture is the
earliest model of the whole software
system created along the software
lifecycle
 Our current research on Architecture Description
Languages and Frameworks

37. 37

38. 38
ADL = Architecture Description Language = any mode
of expression used in an architecture description
Informal
UML-based
Formal

39. 39
Pro:
 of immediate use
 perfect for sketching
 communicative
Cons:
 ambiguous
 non automated
Pro:
 not too difficult
 same notation for SA
and design modeling
Cons:
 not a 100% fit
 tool investment
Pro:
 formal semantics
 computable
Cons:
 difficult to learn
 general lack of tools
 prolifetarion
But.. What Industry needs from Architectural Languages?
I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, A. Tang. IEEE TSE 2012 (pre-print)
Main Finding: Introvert versus extrovert nature of architects role
ADLs should combine features supporting both communication
and disciplined development.

40. 41

41. 42
Medvidovic et al. [12]
Woods and Hilliard [17]
Woods [18]
Pandey [19]
Hilliard and Rice [20]
Clements [21]

42. The study population
Participants = 48
─ 25 interviews
─ 23 on-line questionnaires
Localization: 15 countries
→
USA (9), Sweden (6), Germany (5), Netherlands (5), Canada (4), Australia
(4), France (4), Argentina (2), UK (2), Austria (1), Belgium (1), Chile (1),
Croatia (1), India (1), Switzerland (1), unknown (1)
Number of employees
A(0-99)
25%
23%
18%
34%
B(100-999)
C(1000-4999)
D(5000-above)

44. usefulness of ADL features in past and future
projects

45. 47
C1: need of models interoperability

multiple languages are used to describe the architecture of a
software system
C2: need of extending existing ALs
C3: need of creating, storing, re-using, views and
Architecture Frameworks
C4: need of communicative and analytic AL

46. S1. DUALLY (dually.di.univaq.it)
→An
MDE interoperability framework for existing ADLs
[TSE2010,SOSYM2012]
S2.ByADL (byadl.di.univaq.it)
48
DUALLY supports interoperability among
MDE framework for customizing existing ADLs ADLs. One
model written in an ADL, can be then automatically
[ICSE2010, ECSA2010]
transformed into another model conforming to a
S3.MEGAF (megaf.di.univaq.it) a change is applied to
different ADL. Moreover, if
one model in the transformation network, it is
→A repository and a framework for creating your architecture
descriptionpropagated to all the models.
based on different viewpoints/views/concerns
→An
[ASE2010, WICSA/ECSA2012]
S4.WIKI & AL

47. 49
•Use of different ALs to model or analyze different
architectural aspects of a system
Bridging the different descriptions to be kept
consistent and coherent is of paramount relevance

48. DUALLY Motivating Example
Performance
Performance analysis
Model PM
System
?
Security
Model
Security
analysis
?

49. 53
Tech Foundation: Model Transformations and
Weaving
Model 2 Model


From design to analysis models
From one view to another
ADLb
ADLa
Model 2 Code:


Executable code
Simulation code
Transformation

50. 2) Star topology:
1) Full-mesh topology:
Other
ADLs
Darwin/
LTSA
ACME
AADL
SA UML
profiles
n notations  n (n-1)/2 weaving models
Other
ADLs
A0
Profile
SA UML
profiles
Darwin/
LTSA
ACME
AADL
n notations  n weav. models
Consistency of models may be
verified in A0

51. S1. DUALLY (dually.di.univaq.it)
→An
MDE interoperability framework for existing ADLs
[TSE2010,SOSYM2012]
S2. ByADL (byadl.di.univaq.it)
→An
MDE framework for customizing existing ADLs
[ICSE2010, ECSA2010]
MEGAF (megaf.di.univaq.it)
ByADL framework for creating your for
repository and a is Eclipse-based solution architecture
descriptionextending and customizing architecture
based on different viewpoints/views/concerns
→A
[ASE2010, WICSA/ECSA2012]
description
languages (or, more in
→S4.WIKI &general, domain specific modeling
AL
languages) to adapt an ADL to better fit
stakeholders’ concerns.

52. ByADL (byadl.di.univaq.it)
→An
MDE framework for customizing existing ADLs
[ICSE2010, ECSA2010]
PROBLEM
SOLUTION
current ADLs mostly fail to capture multiple
(and varying) stakeholders concerns
extending and customizing existing ADLs w.r.t.
to domain- & organization- specific concerns

53. 59
Tech Foundation: Metamodel Composition
Metamodels (and models) can be “composed” so to
generate a new metamodel (model)
MM
MMext
composition
model
transformation
s
MMcomp

54. S1.DUALLY (dually.di.univaq.it)
→An
MDE interoperability allows software architects
MEGAF framework for existing ADLs
to
[TSE2010,SOSYM2012]
create new and re-usable architecture
S2.ByADL (byadl.di.univaq.it)
frameworks
→An
MDE framework for customizing existing ADLs
[ICSE2010, ECSA2010]
S3.MEGAF (megaf.di.univaq.it)
→A
repository and a framework for creating your architecture
description based on different viewpoints/views/concerns
[ASE2010, WICSA/ECSA2012]
S4.WIKI & AL

55. To provide an infrastructure that enables to
build reusable architecture frameworks
by treating
views, viewpoints, concerns as
first-class entities.
MEGAF is an MDE approach to create new architecture
frameworks by means of mechanisms:
i.
ii.
iii.
to store, retrieve, and combine existing viewpoints, by properly
selecting and reusing models previously defined and resident in
MEGAF;
to define correspondences among
views, viewpoints, stakeholders, system concerns and their
elements;
to enforce consistency and completeness checks based on
defined architectural relationships and rules among elements.

56. Tech. Foundation: Megamodeling
A megamodel can be seen as a map to find and
link together all the involved models
A megamodel is a kind of model in which elements could
represent and/or refer to models or metamodels [Bézivin et
al., OOPSLA/GPCE 2004]
A megamodel specifies properties and rules governing model
construction, including multiple models and metamodels
→Models
and metamodels are first-class entities
→It offers also the possibility to specify relationships between
them and to navigate them.

57. Composed AF
Extended/customized ADL
generated in byADL
generated in MEGAF
St1
VP
1
BPMN
VP
2
Darwin/FSP
FT
MK1
SA UML profiles
other ADLs
ACME
pivot
metamodel
(A0)
AADL
xADL
DUALLy: an automated approach for ADLs interoperability
byADL: an approach to adapt and customize existing ADLs
MEGAF: a model-driven infrastructure for building reusable
and extensible architecture frameworks

58. DUALLy
byADL
MEGAF
other
engines
MEGAF
AMMA
AM3
AMW
EMF
ATL

59. megaf.di.univaq.it
• Preliminary prototype in Eclipse, using
megamodeling techniques
dually.di.univaq.it
• Prototype in Eclipse, using model-driven
engineering techniques
byadl.di.univaq.it
• Prototype in Eclipse, using model-driven
engineering techniques