This presentation explains a theoretical approach and associated tool support to evolve software architecture descriptions expressed in an architectural description language.

1. Using
Evolu,on
Pa/erns
to
Evolve
So4ware
Architectures
Joint
work
with
Dalila
Tamzalit,
Université
de
Nantes,
France
Published
in
IEEE
ECBS
2010,
Oxford
With
help
of
Aurélien
Lansmanne
for
the
implementaMon

2. Context
:
So4ware
Architectures
SoOware
development
process
–
Requirements
–
Architecture
–
Design
–
ImplementaMon
Architectural
descripMons
– Capture
strategic
decisions
and
raMonale
at
a
high-­‐level
of
abstracMon
– Provide
a
basis
for
detailed
design
– Are
essenMal
for
expressing
and
constraining
large-­‐scale
and
criMcal
systems
3

3. Context
:
So4ware
Architectures
IEEE/ISO/IEC
Standard
1471-­‐2000:
Recommended
Prac,ce
Component
&
connector
4
viewpoint
Université de Mons

4. Context
:
So4ware
Architectures
• C&C
viewpoint
• Expresses
the
system
structure
in
terms
of
components
(with
ports)
related
by
connectors
(with
roles)
• Architectural
DescripMon
Language
(ADL)
• Provides
the
syntax
and
semanMcs
for
the
C&C
viewpoint
• Example
• e-­‐shop
expressed
in
COSA
ADL
5

5. Context
:
Architectural
Styles
• An
architectural
style
captures
recurring
architectural
paZerns
• Examples
• Pipe&Filter,
Publish-­‐Subscribe,
Peer-­‐to-­‐peer,
n-­‐Mered,
…
6

6. Context
:
Architectural
Styles
• An
architectural
style
captures
recurring
architectural
paZerns
• Examples
• Client-­‐Server
7

7. Goal
:
Architectural
Evolu,on
• SoOware
evoluMon
– Is
inevitable:
Perpetual
challenge
for
large-­‐scale
systems
– Is
difficult
and
expensive
• Systems
tend
to
increase
in
complexity
• Several
stakeholders,
several
representaMons
• Difficult
to
manage,
lack
of
abstracMon
– Needs
to
be
liOed
• Support
for
evoluMon
at
architectural
level
– Needs
to
be
automated
• Needs
to
be
built
in
the
language
(ADL)
and
its
supporMng
tools
8

8. Goal
:
Architecture
restructuring
• Apply
ideas
of
“program
refactoring”
at
architectural
level
• Improve
architectural
structure
by
automated
transformaMons
• Examples
• Transform
legacy
systems
to
client-­‐server
systems,
to
N-­‐Mered
systems,
to
SOA,
…
• Introducing
an
architectural
style
to
an
exisMng
architecture
– Goal
• Impose
addiMonal
structural
constraints
• While
preserving
the
exisMng
funcMonality
9

9. Goal
:
Architecture
restructuring
Example:
from
monolithic
to
client-­‐server
• Original
C&C
architecture
e-­‐shop
expressed
using
COSA
ADL
10
Université de Mons

10. Goal
:
Architecture
restructuring
Example:
from
monolithic
to
client-­‐server
11
Université de Mons

11. Approach
Formal
valida,on
– Assess
feasibility
using
graph
transformaMon
theory
– Provide
proof-­‐of-­‐concept
using
AGG
tool
Prac,cal
valida,on
– Extend
exisMng
ADL
(COSA)
with
support
for
evoluMon
– Implement
the
formal
ideas
in
COSABuilder
tool
Case
study
– Convert
a
monolithic
architecture
(E-­‐shop)
in
a
client-­‐
server
architecture
by
introducing
architectural
style
12

12. Formal
valida,on
• Use
graph
transformaMon
theory
• Specify
proof-­‐of-­‐concept
in
AGG
tool
• Represent
ADL
metamodel
as
a
type
graph
• Represent
addiMonal
constraints
as
graph
invariants
• Represent
architecture
as
a
graph
conforming
to
this
type
graph
• Represent
architectural
style
• Represent
architectural
evoluMon
steps
as
graph
transforma1on
rules
• Use
formal
analysis
capabiliMes
of
AGG
13

13. Formal
Valida,on
• Represent
(part
of
)
COSA
ADL
metamodel
as
a
type
graph
• Architectural
concepts:
component,
configuraMon,
(provided
or
required)
port
or
role,
connector,
binding,
aZachment
14

14. Formal
Valida,on
• Represent
architecture
as
a
graph
conform
to
this
type
graph
15

15. Formal
Valida,on
• Represent
(part
of
)
COSA
ADL
metamodel
as
a
type
graph
• Derived
edge
types:
connectsTo
and
connector
16

16. Formal
Valida,on
• Represent
(part
of
)
COSA
ADL
metamodel
as
a
type
graph
• Graph
invariants
• A
component
cannot
be
connected
to,
or
contained
in,
itself.
• A
uses
dependency
is
only
allowed
between
different
ports
belonging
to
the
same
component.
• Two
components
cannot
be
at
the
same
Mme
connected
to,
and
contained,
in
one
another.
• A
binding
is
only
allowed
between
ports
of
the
same
type
belonging
to
a
component
and
one
of
its
subcomponents.
17

17. Formal
Valida,on
• Express
the
architectural
style
as
extension
of
type
graph
• with
addiMonal
graph
constraints
– Only
Client
and
Server
are
allowed
as
top-­‐level
components
– A
Client
component
must
always
be
connected
to
Server
via
a
connectsTo-­‐link
18

18. Formal
Valida,on
• Represent
evoluMon
operaMons
as
graph
transformaMon
rules
19

19. Formal
Valida,on
• Represent
evoluMon
operaMons
as
graph
transformaMon
rules
20

20. Formal
Valida,on
• Ensure
preservaMon
of
internal
structural
dependencies
21

21. Evolu,on
pa/ern
mandatory
phase
Université de Mons

22. Evolu,on
pa/ern
manual
phase
Université de Mons

23. Formal
Valida,on
• Use
transformaMon
analysis
to
detect
potenMal
problems
• Based
on
criMcal
pair
analysis
of
parallel
conflicts
and
sequenMal
dependencies
24

24. Prac,cal
Valida,on
•
COSABuilder
• Eclipse
plug-­‐in
supporMng
the
COSA
ADL
• Developed
@
Modal
team
-­‐
University
of
Nantes
• Object-­‐oriented
framework,
extensible
with
new
concepts
• Extend
COSABuilder
with
automated
support
for
evoluMon
• Masters
thesis
of
Aurélien
Lansmanne

25. Prac,cal
Valida,on
• Extend
COSABuilder
with
evoluMon
support
• All
architectural
evoluMon
operaMons
are
reified
in
the
ADL
• EvoluMon
paZerns
expressed
in
terms
of
primiMve
operaMons
• GUI
support
for
selecMng
and
applying
evoluMon
paZerns
and
operaMons
• Support
for
verifying
• the
contraints
imposed
by
an
architectural
style
• that
internal
dependencies
are
preserved
by
evoluMon

26. Prac,cal
Valida,on
• Applying
an
evoluMon
operaMon
(part
1)

27. Prac,cal
Valida,on
• Applying
an
evoluMon
operaMon
(part
2)

28. Prac,cal
Valida,on
• Applying
an
evoluMon
paZern
to
introduce
the
Client-­‐Server
architectural
style

29. Prac,cal
Valida,on
• Verifiying
conformance
of
an
architecture
to
the
Client-­‐Server
architectural
style
(1)
(2)

30. Prac,cal
Valida,on
• Verifiying
conformance
of
an
architecture
to
the
Client-­‐Server
architectural
style
(1)
(2)

31. Future
Work
• SupporMng
mutlipe
ADLs,
mulMple
viewpoints,
mulMple
styles
• Carrying
out
more
case
studies
• Expressing
non-­‐structural
aspects
of
an
architectural
descripMon
• Considering
other
evoluMon
scenarios
• E.g.
changing
a
style
to
another
one
• Extending
ADLs
with
first-­‐class
support
for
evoluMon
32

32. Future
Work
con,nued
• Dealing
with
co-­‐evoluMon
http://
ComputingNow.computer.org.
• But
also
with
requirements,
run-­‐Mme,
language
evoluMon
33