Using Evolution Patterns to Evolve Software Architectures
Sep. 17, 2010•0 likes
1 likes
Be the first to like this
Show More
•3,908 views
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
This presentation explains a theoretical approach and associated tool support to evolve software architecture descriptions expressed in an architectural description language.
Using Evolution Patterns to Evolve Software Architectures
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
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
Context
:
So4ware
Architectures
IEEE/ISO/IEC
Standard
1471-‐2000:
Recommended
Prac,ce
Component
&
connector
4
viewpoint
Université de Mons
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
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
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
Goal
:
Architecture
restructuring
Example:
from
monolithic
to
client-‐server
• Original
C&C
architecture
e-‐shop
expressed
using
COSA
ADL
10
Université de Mons
Goal
:
Architecture
restructuring
Example:
from
monolithic
to
client-‐server
11
Université de Mons
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
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
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
Formal
Valida,on
• Represent
architecture
as
a
graph
conform
to
this
type
graph
15
Formal
Valida,on
• Represent
(part
of
)
COSA
ADL
metamodel
as
a
type
graph
• Derived
edge
types:
connectsTo
and
connector
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
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
Formal
Valida,on
• Use
transformaMon
analysis
to
detect
potenMal
problems
• Based
on
criMcal
pair
analysis
of
parallel
conflicts
and
sequenMal
dependencies
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
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
Prac,cal
Valida,on
• Applying
an
evoluMon
paZern
to
introduce
the
Client-‐Server
architectural
style
Prac,cal
Valida,on
• Verifiying
conformance
of
an
architecture
to
the
Client-‐Server
architectural
style
(1)
(2)
Prac,cal
Valida,on
• Verifiying
conformance
of
an
architecture
to
the
Client-‐Server
architectural
style
(1)
(2)
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
Future
Work
con,nued
• Dealing
with
co-‐evoluMon
http://
ComputingNow.computer.org.
• But
also
with
requirements,
run-‐Mme,
language
evoluMon
33