Pattern-driven Reuse in Architecture-centric Evolution
for Service Software
Aakash Ahmad, Pooyan Jamshidi and Claus Pahl
School of Computing, Dublin City University, Dublin, Ireland
Lero - The Irish Software Engineering Research Centre, Limerick, Ireland
Keywords:
Software Evolution, Change Patterns, Architecture Model Evolution.
Abstract:
Service-based architectures implement business processes as technical software services to develop enterprise
software. As a consequence of frequent business and technical change cycles, the architect requires a reuse-
centered approach to systematically accommodate recurring changes in existing software. Our ‘Pat-Evol’
project aims at supporting pattern-driven reuse in architecture-centric evolution for service software. We
propose architecture change mining as a complementary phase to a systematic architecture change execution.
Therefore, we investigate the ‘history’ of sequential changes - exploiting change logs - to discover patterns of
change that occur during evolution. To foster reuse, a pattern catalogue maintains an updated collection with
once-off specification for identified pattern instances. This allows us to exploit change pattern as a generic,
first class abstractions (that can be operationalised and parameterised) to support reuse in architecture-centric
software evolution. The notion of ‘build-once, use-often’ empowers the role of an architect to model and
execute generic and potentially reusable solution to recurring architecture evolution problems.
1 INTRODUCTION
Software architecture represents the global sys-
tem structure for designing, evolving and reason-
ing about configurations of computational compo-
nents and their interconnection at higher abstraction
levels. Service Oriented Architecture (SOA) rep-
resents a business-centric, architectural approach to
model business process as technical software services
in enterprise software. Once deployed, a continu-
ous change in business and technical requirements
lead towards frequent maintenance and evolution in
service-driven software (Lewis and Smith, 2008). Al-
though architecture-centric maintenance and evolu-
tion proved successful in adjusting software struc-
ture and behavior at higher abstractions, a systematic
investigation (Breivold et al., 2012) suggests a lack
of concrete efforts in supporting a reuse-centered ap-
proach to architecture evolution. From an architect’s
perspective (Garlan et al., 2009), this is particularly
limiting as the existing solutions fall short of capital-
ising on the ‘build-once, use-often philosophy’.
The potential for change reuse is also evident in
the research taxonomy for SOA maintenance and evo-
lution (Lewis and Smith, 2008), urging development
of processes, frameworks and patterns to foster reusa-
ble evolution in service-driven software. Within the
‘Pat-Evol’ project (Ahmad and Pahl, 2012a) we aim
at supporting pattern-driven reuse in architecture-
centric evolution for service software. We rely
on architecture change mining (analysing implicit
evolution-centric knowledge) as a complementary
phase to guide architectural change execution.
In (Ahmad et al., 2012) we investigated the history of
sequential architectural changes - exploiting change
logs - to empirically identify patterns of change that
occur over-time during evolution. This allows us to
hypothesise that the application of change patterns to
architectural transformation supports potential reuse
in architecture-centric software evolution. Change
patterns as a generic solution can be i) identified as
recurrent, ii) specified once and iii) instantiated mul-
tiple times to support reuse in architectural change.
Although a recent emergence of evolution
styles (Garlan et al., 2009) and more specifically
the ‘Evolution Shelf’ (Goaer et al., 2008) promote
reuse in (more conventional) component-based ar-
chitecture evolution. However, these solutions fall
short of addressing frequent demand-driven process-
centric changes (Weber et al., 2007) that are central to
maintenance and evolution of SOAs. This motivates
the needs to systematically investigate architecture
279
Ahmad A., Jamshidi P. and Pahl C..
Pattern-driven Reuse in Architecture-centric Evolution for Service Software.
DOI: 10.5220/0004128602790284
In Proceedings of the 7th International Conference on Software Paradigm Trends (ICSOFT-2012), pages 279-284
ISBN: 978-989-8565-19-8
Copyright
c
2012 SCITEPRESS (Science and Technology Publications, Lda.)
change representation that goes beyond frequent ad-
dition or removal of individual components and con-
nectors to operationalise recurrent process-based ar-
chitectural changes. This is significant in relieving an
architect of routine evolution tasks by fostering their
reuse to support a systematic change execution when-
ever needs for architectural evolution arises.
In the ‘Pat-Evol’ project, the overall research con-
tribution in terms of an evolution application frame-
work is depicted in Figure 1. In this paper, we specif-
ically focus on evolution specification that is guided
by architecture change patterns as summarised below.
Change Mining
Operationalisation
Change Patterns
Architecture
Evolution
Change Execution
Constraints
Catalogue Framework
Change Specification
Change Instance Capturing
Change
Log
A
C
B
Figure 1: An overview of solution framework.
A. We analysed the history of sequential architec-
tural changesas ‘post-mortem’ analysis to contin-
uously identify recurring operationalisation and
patterns from change logs (Ahmad et al., 2012).
B. We support pattern specification and retrieval
with a repository infrastructure comprising of a
continuously validated and updated collection of
change patterns (Ahmad and Pahl, 2012b).
C. In this paper, we focus on evolution application in
terms of pattern-driven reuse during change exe-
cution to support the notion of ‘evolution off-the-
shelf’ in service-based architectures.
This paper is organised as follows. A formal spec-
ification of change patterns and its properties are pre-
sented in Section 2. We discuss pattern-driven ar-
chitecture evolution in Section 3. Section 4 outlines
related research to justify overall contribution that is
followed by conclusions and outlook in Section 5.
2 CHANGE PATTERN
In (Ahmad et al., 2012), we focused on exploiting ar-
chitecture change logs - analysing sequential archi-
tectural changes - to empirically identify patterns of
change that occur over time. This allows us to de-
fine change pattern as a generic, first class abstrac-
tion (that can be operationalised and parameterised)
to support potential reuse in architectural change exe-
cution. In this section, we i) formalise change pattern
in terms of a meta-model of its constituent elements in
Figure 2 and ii) outline pattern properties formulating
the foundation for pattern-driven change execution.
2.1 Modeling Pattern-based Evolution
We model pattern-based evolution as 4-tuple
PatEvol =< SArch, OPR,CNS, PAT > with element
inter-relationships in Figure 2 as explained below.
- Service Architecture (SArch): refers to architec-
ture elements to which a change pattern can be ap-
plied. We use attributed typed graphs (ATG) (Ehrig
et al., 2004) that provide formal syntax and seman-
tics with node and edge attribution to model typed in-
stances of architectural elements. The architectural
model is consistent with the Service Component Ar-
chitecture with configurations (CFG) of a set service
components (CMP) as computational entities linked
through connectors (CON). Following SOA princi-
ples (Lewis and Smith, 2008), modeling is restricted
to graph-based representation of service architectures,
only supporting composition or association type de-
pendencies in service composites (Pahl, 2002; Pahl
and Zhu, 2006). Thus, the consistency of pattern-
based change and structural integrity of architecture
elements beyond this architecture model is undefined.
- name : String
- intent : String
1..*
1..*
1..*
1..1
- precondition : CNS
- postcondition : CNS
- invariant : CNS
-oprExp : String
ADD(ae :SrvArch)
REM(ae :SrvArch)
MOD(ae :SrvArch)
in(ChangePattern: PAT)
out():ChangePattern
isContainedBy
1..*
isAppliedTo
constrains
isEvolvedBy
1..1
1..*
isComposedOf
isConstrainedBy
- id : Integer
PatternCatalogue
ChangePattern
ChangeOperator
Constraints
Configuration
Component Connector
Port
Endpoint
src
trg
ServiceArchitecture
Figure 2: Structural model for pattern-based evolution.
- Change Operators (OPR): represents change oper-
ationalisation that is fundamental to architectural evo-
lution. Our analysis of the log goes beyond basic
change types in (Buckley et al., 2005) to specify a set
of atomic and composite operations enabling struc-
tural evolution by adding (ADD), removing (REM)
and modifying (MOD) architecture elements. The
benefit with graph-based modeling lies in abstracting
change operationalisation as declarative graph trans-
formation rules (Corradini et al., 1996) specified as:
Atomic Change Operations: enable fundamental
architectural changes in terms of adding, removing or
modifying the component operation (OPT), compo-
nent port (POR), connector binding (BIN), connector
ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends
280
endpoint (EPT) and configuration interface (INF).
Composite Change Operations: are a set of
atomic change operations, combined to enable com-
posite architectural changes. These enable adding,
removing or modifying the components (CMP), con-
nectors (CON) and configurations (CFG) with a se-
quential composition of architectural changes.
- Constraints (CNS): refer to a set of pattern-specific
constraints in terms of pre-conditions (PRE) and post-
conditions (POST) to ensure consistency of pattern-
based changes. In addition, the invariants (INV) en-
sure structural integrity of individual architecture ele-
ments during change execution.
- Change Patterns (PAT): represents a recurring,
constrained composition of change operationalisation
on architecture elements. It defines a first class ab-
straction that can be operationalised and parame-
terised to support potentially reusable architectural
change execution as: PAT
<id, name>
: PRE(ae
m
∈
AE)
INV(OPR
n
(ae
m
∈AE))
−−−−−−−−−−−−→ POST(ae
′
m
∈ AE).
A pattern catalogue (CAT) refers to a template-
based repository infrastructure that facilitates an au-
tomated storage (in: once-off specification) and re-
trieval (out: multiple instantiation) of change patterns.
2.2 Properties of Change Pattern
Based on the meta-model, Pattern Identification is
an empirical investigation of the history of archi-
tectural changes to identify recurring sequences of
change. In (Ahmad et al., 2012), we use graphs
to analyse change representation along with an au-
tomated identification of patterns from architecture
change logs. PatternSpecification providesa consis-
tent (once-off) specification for the collection of iden-
tified pattern instances. In (Ahmad and Pahl, 2012b),
we use an XML-based pattern template to document
generic change patterns that can be retrieved when-
ever needs for pattern usage arises. Finally, Pattern
Instantiation allows instantiation of appropriate pat-
tern instances from abstract specifications to promote
the ‘build-once, use-often’ approach. Now, we focus
on utilising graph transformation guided by architec-
tural change patterns to support reusable evolution.
3 PATTERN-BASED EVOLUTION
IN SERVICE ARCHITECTURE
Based on the operationalisation of architectural
changes in the log, we observed recurring sequences
of change that corresponded to evolution needs and
their underlying tasks that occur frequently over time.
Furthermore, if design or architectural patterns can
prove to be successful in supporting reuse for ar-
chitectural construction, we believe change patterns
have the potential to facilitate reuse during its evolu-
tion. In particular, fostering the reuse of routine evo-
lution tasks is an attempt towards facilitating archi-
tects to follow a systematic, reuse-centered approach
to architecture-based change execution as highlighted
in (Garlan et al., 2009). It is vital to mention that ar-
chitectural evolution in the context of services-driven
software is particularly inclined towards accommo-
dating process-centric changes (Weber et al., 2007)
(i.e., integration, replacement, decomposition of ele-
ments), unlike frequent addition or removal of indi-
vidual components and connectors.
3.1 Evolution Use Case Scenario
We use a partial architectural view of an Electronic
Bill Presentment and Payment (EBPP) as a case study.
For architectural modeling, we use ATGs (Ehrig et al.,
2004) to model typed instances of architectural ele-
ments. We use the Graph Modeling Language (.GML)
as an XML-based representation of architectural in-
stances. A benefit of graph-based modeling is support
for architectural evolution by means of graph transfor-
mations (Corradini et al., 1996), (Graaf, 2007). More
specifically, during execution change operationalisa-
tion is abstracted as declarative graph transformation
rules (in our case XML transformations using XSLT).
For space reasons we abstract the underlying graph-
based formalism with an overview of pattern-driven
transformation to evolve architectural model.
accManager
BillerApp custBill
billingData
getInvoice
adjustAccount
Payment
Component
Ports
Connector
out
in
out
in
in
out
consInvoicing
Configuration
Figure 3: Partial architectural view for EBPP.
In the existing scope of case study (Figure 3), the
company charges customer with full payment of cus-
tomer bills in advance to deliver requested services.
Now, the company plans to facilitate existing cus-
tomers with either weekly or monthly bill payment.
Therefore, in the given architectural (Figure 3) con-
text, a new component billType must be included and
Pattern-drivenReuseinArchitecture-centricEvolutionforServiceSoftware
281
integrated as a mediator among the existing compo-
nents BillerApp and custBill. It facilitates billing type
options (monthly or weekly billing) to the customers.
3.2 Pattern-based Change Execution
In order to achievepattern-drivenarchitectural change
execution, we follow a three step process as presented
in Table 1 and explained below.
Table 1: Declarative specification for change intent.
Integrate(G
S
, [CNS], < billType, BillerApp, custBill >)
PRE (preConditions)
∃(BillerApp, custBill ∈ CMP) ⊆ G
S
∃billingData(BillerApp, custBill) ∈ CON ⊆ G
S
POST (postConditions)
∃(BillerApp, custBill, billType ∈ CMP) ⊆ G
S
∃billTypeData(BillerApp, billType) ∈ CON ⊆ G
S
∃getType(billType,custBill) ∈ CON ⊆ G
S
< PAT > retrievePattern(PRE, POST)
∀pat
i
∈ PAT∃pat
i
.PRE ∧ pat
i
.DEF ∧ pat
i
.POST
(pat
i
.PRE ≡ PRE ∧ pat
i
.POST ≡ POST) ∈ CAT
return(pat
i
.DEF)
1. Change Specification: A declarative specification
allows architect to represent syntactical context of
architectural change that contains the i) source ar-
chitecture graph (G
S
), ii) pre- and post-conditions
([CNS]) and iii) architecture elements (AE) that
need to be added, removed or modified such that
AE ∈ G
S
. For example, in Table 1 the declara-
tion Integrate() specifies that the new component
billType is added in G
S
and integrated as a media-
tor among the existing components BillerApp and
custBill using the predefined constraints.
2. Change Conditions: consists of preconditions
(PRE) and postconditions (POST) that must be
satisfied to preserve the structural integrity of the
overall architecture and individual elements dur-
ing change execution. In addition, the catalogue
(CAT) is queried based on these conditions to re-
trieve a list of patterns (PAT) in a given context.
The preconditions represent the context of archi-
tectural elements before change execution. For ex-
ample in Figure 4a, the sub-graph S specifies the
exact sub-architecture billingData(BillerApp, cust-
Bill) that is subject to change in the original ar-
chitecture G
S
, PRE in Table 1. In order to apply
changes, we must find an exact structural match
m
1
of S in G
S
, such that m
S
: S → G
S
as Figure 4a.
The postconditions specify the context of evolved
architectural elements as a result of the change ex-
ecution. After applying changes on specified el-
ements the overall architectural structure must be
preserved. In order to include the modified archi-
tecture elements T in the target architecture G
T
an
exact structural match m
T
of T in G
T
must exist
such that m
T
: T → G
T
as Figure 4c.
The invariants represent architectural structure
that is never changed during evolution. This is rep-
resented as Figure 4b, the invariant graph G
I
as
m
I
: I → G
I
with Double-Push-Out (DPO) graph
transformations (Corradini et al., 1996).
3. Pattern Retrieval: Once an exact instance of S
in G
S
is identified, the pattern catalogue is queried
with pre-conditions and post-conditions to retrieve
the appropriate pattern that provides the potential
reuse of change operationalisation to enable archi-
tectural evolution. Table 1 outlines the generic
syntax for querying the catalogue based on Xpath
query to retrieve pattern specification. The query
matches the specified change pre-conditions and
post-conditions to retrieve the pattern definition
from catalogue. Figure 4 illustrates the retrieved
instance of Linear Inclusion pattern that aims at
‘integration of a mediator among two or more di-
rectly connected service components’. In addition,
pattern instantiation involves labeling of generic
elements in specification with labels of concrete
architecture elements presented in change specifi-
cation. For example, in Figure 4a the connector
instance billingData that is missing in the change
post-conditions is removed from the G
S
. The
newly added instances of component billType and
connector billTypeData, getType are the candidates
for addition into G
S
to obtain G
T
in Figure 4c.
In example above, we support the fundamental hy-
pothesis that: if an architectural evolution problem
can be specified declaratively, its solution is executed
in an automated way in terms of instantiating change
operationalisation that exist in the catalogue. Keep-
ing in view some technical clarifications we provide
a brief overview of the change execution that is fa-
cilitated using the DPO construction (Corradini et al.,
1996). In Figure 4 the order of change operations is
insignificant and the sequence is presented as it ap-
peared in the given pattern instance.
- Deletion: In Figure 4b, S \ I describes the archi-
tecture elements which are to be deleted from G
S
,
For example, the connector billingData is removed
from the BillerApp and custBill. The invariant graph
G
I
is obtained from the source graph G
S
for ele-
ments which are a pre-image in S but not in I - the
deletion operation - as Rem
<billingData ∈ CON>
.
- Addition: In Figure 4c, R \ I described the
part which needs to be added in G
S
to obtain G
T
during change execution. For example, in Fig-
ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends
282
adjustAccount
BillerApp
custBill
billingData
adjustAccount
billType
BillerApp
custBill
BillerApp
custBill
consInvoice
accMgmt
generateInvoice
adjustAccount
billType
billiTypeData
getType
billiTypeData
getType
BillerApp
custBill
billingData
2
4
1
3
weekBill
monthBill
billType
pType
(o
ut
)
pData(in)
G
I
G
S
G
T
S
T
I
BillerApp
custBill
consInvoice
accMgmt
billingData
generateInvoice
BillerApp custBill
consInvoice
accMgmt
generateInvoice
Pattern
Catalogue
Pattern Instance
ADD Connector
ADD Component
ADD(weekBill:CMP)
ADD(weekBill:CMP)
ADD(weekBill:CMP)ADD(MONTHBill:CMP)
isComposite = true
PRE
POST
c1
A
B
c1
A
B
M
c2
c3
REM(c1:CON)
ADD(M:CMP)
ADD(c2:CON)
ADD(c3:CON)
Operationalisation
m
I
: S G
I
m
S
: S G
S
m
T
: S G
T
t = (G
S
G
I
G
T
)
m
1
: I S
m
2
: G
I
G
S
m
3
: I T
m
4
: G
I
G
T
2a - ADD(billType :CMP)
2b - ADD(pData :POR)
2c - ADD(pType :POR)
4a - ADD(getType : CON)
4b - ADD(eSource :EPT)
4c - ADD(eTarget :EPT)
Pattern
Catalogue
preconditions
invariants
postconditions
a)
c)
b)
Figure 4: Pattern-driven architecture change execution.
ure 4c the component PaymentType is added with
connector selectType and custPay in the architec-
ture. Add
<billType ∈ CMP>
; Add
<billTypeData ∈ CON>
;
Add
<getType ∈ CON>
.
3.3 Evaluation Plan
A performant solution still requires a rigorous evalu-
ation in terms of different architecture evolution sce-
narios. This is particularly beneficial to analyse the
adequacy of the proposed solution in facilitating a
reuse-centered approach to architecture evolution.
Scenario-based Evaluation: In order to avoid
scalability issues, preliminary evaluation of our work
is based on experimenting with evolutionary scenar-
ios in two service-based architectures. These in-
clude an Electronic Bill Presentment and Payment
and an On-line Tour Reservation System. The ob-
jectives of initial evaluation are to determine the ad-
equacy of proposed solution in terms of utilising re-
curring operationlisations that exist in the catalogue.
Possible Limitations - An interesting identifica-
tion is the emergence of change anti-patterns result-
ing from counter-productive pattern-based evolution.
This leads us to believe that change patterns do not
necessarily support an optimal solution; instead they
promote an alternative and potentially reusable op-
erationalisation for architecture evolution. However,
identification of possible anti-patterns and their res-
olution (architectural refinement) is vital to achieve
evolved architecture with desired specifications
Prototype-based Validation: Currently, we are in
the process of developing a prototypical framework
to fully automate and validate pattern-drivenarchitec-
ture evolution. The tool and the generated data shall
form the basis for the practitioners (software archi-
tects) for a survey and usability based analysis to eval-
uate the adequacy and applicability of the proposed
solution in a practical context.
4 RELATED WORK
During software design and evolution phase, an inher-
ent limitation with the architectural description lan-
guages (ADLs) or meta-models lies with their inabil-
ity to capitalise on an explicit change support within
existing architecture. Although xADL (Dashofy
et al., 2002) utilises the configuration management
concepts - utilising version graphs - to capture the
evolution of individual elements in architectural de-
scription, it lacks the granularity of change repre-
sentation from one version to another. This is par-
ticularly limiting to i) model and analyse the opera-
tional representation of changes and ii) fostering their
(potential) reuse to guide architectural change exe-
cution whenever needs for evolution arises. In con-
trast to the “evolution shelf” (Goaer et al., 2008),
we are specifically concerned about frequent demand-
driven, process-centric changes that are central to
maintenance and evolution in service-driven architec-
tures (Weber et al., 2007), (Lewis and Smith, 2008).
In the context of model driven engineering, the
research in (Graaf, 2007) specifically focuses on ar-
chitectural abstractions by exploiting model transfor-
mations to enable architecture model evolution. Our
research is fundamentally different and supports a
reuse-centered approach to achieve evolution in (plat-
form independent) architectural model. However,
the proposed solution is closely aligned to the work
in (Kim and Carrington, 2006) and (Lara and Guerra,
2008) that allows users to define patterns using a pat-
Pattern-drivenReuseinArchitecture-centricEvolutionforServiceSoftware
283
tern modeling notations. These support pattern-based
model evolution where patterns are used as transfor-
mation rules to support model evolution. We primar-
ily focused on utilising experimentally identified pat-
terns that facilitate a first class abstraction to reusable
change execution. This enables fine granular change
operationalisation that can be parameterised to guide
potentially reusable evolution in architecture-centric
models. It is vital to mention about a catalog of pro-
cess change patterns (Weber et al., 2007) that guides
changes in process-aware information systems. In
contrast to the process aspects of a software, we ex-
clusively focus on change operationalisation at archi-
tectural abstraction levels accommodating patterns to
guide structural evolution.
5 CONCLUSIONS AND
OUTLOOK
We propose to leverage architectural change mining
- identifying patterns from change logs - to support
potential reuse during architecture evolution. We
demonstrate that if an architectural evolution prob-
lem can be specified declaratively, pattern-driven evo-
lution could relieve an architect from the underlying
operational concerns for executing routine evolution
tasks that exist in catalogue.
In future, we are primarily concerned about ex-
plicitly addressing the granularity of change execu-
tion that goes beyond generic specifications of iden-
tified patterns. We focus on structural modifications
to the internal architecture of composite components
guided by change patterns that is currently lacking in
our solution. Additional case studies in (Gruhn et al.,
1996) and (Javed et al., 2009) shall allow a more rig-
orous evaluation in terms of a solution that facilitates
the notion of ‘build-once, use-often philosophy’ to
evolve architectural models.
REFERENCES
Ahmad, A., Jamshidi, P., and Pahl, C. (2012). Graph-based
Pattern Identification from Architecture Change Logs.
In Intl Workshop On System/Software Architectures.
Ahmad, A. and Pahl, C. (2012a). Pat-Evol: Pattern-Driven
Reuse in Architecture-Based Evolution for Service
Software. In ERCIM News 88.
Ahmad, A. and Pahl, C. (Retrieved April 1,
2012b). Pattern Catalogue: Towards an
Automated Storage and Retrieval of Archi-
tecture Change Patterns (Technical Report).
http://www.computing.dcu.ie/ aaakash/PatternCatalogue.pdf.
Breivold, H. P., Crnkovic, I., and Larsson, M. (2012). A
Systematic Review of Software Architecture Evolu-
tion Research. Inf and Softw Techn, 54(1):16–40.
Buckley, J., Mens, T., Zenger, M., Rashid, A., and
Kniesel, G. (2005). Towards a Taxonomy of Software
Change. Journal of Software Maintenance and Evolu-
tion, 17:309–332.
Corradini, A., Montanari, U., Rossi, F., Ehrig, H., Heckel,
R., and L¨owe, M. (1996). Algebraic Approaches
to Graph Transformation, Part I: Basic Concepts and
Double Pushout Approach. In Handbook of Graph
Grammars and Computing Graph Transformation,
Volume 1: Foundations, pages 163–245.
Dashofy, E., v.d. Hoek, A., and Taylor, R. N. (2002). An
Infrastructure for the Rapid Development of XML-
based Architecture Description Languages. In 24th
International Conference on Software Engineering.
Ehrig, H., Prange, U., and Taentzer, G. (2004). Fundamen-
tal Theory for Typed Attributed Graph Transforma-
tion. In Graph Transformations, pages 161–177.
Garlan, D., Barnes, J., Schmerl, B., and Celiku, O. (2009).
Evolution Styles: Foundations and Tool Support for
Software Architecture Evolution. In Proc. Joint Work-
ing IEEE/IFIP Conference on Software Architecture.
Goaer, O. L., Tamzalit, D., Oussalah, M., and Seriai, A. D.
(2008). Evolution Shelf: Reusing Evolution Expertise
within Component-Based Software Architectures. In
IEEE Intl Computer Software and Applications Conf.
Graaf, B. (2007). Model-Driven Evolution of Software Ar-
chitectures. Ph.D Dissertation: T.U. Delft.
Gruhn, V., Pahl, C., and Wever, M. (1996). Data Model
Evolution as Basis of Business Process Manage-
ment. In 14th International Conference on Object-
Oriented and Entity Relationship Modelling O-O
ER95. Springer-Verlag (LNCS Series).
Javed, M., Abgaz, Y.M., Pahl, C. (2009). A pattern-based
framework of change operators for ontology evolu-
tion. In: On the Move to Meaningful Internet Systems:
OTM Workshops, LNCS 5872, pp. 544–553. Springer.
Kim, S. K. and Carrington, D. (2006). A Pattern based
Model Evolution Approach. In 13th Asia Pacific Soft-
ware Engineering Conference.
Lara, J. and Guerra, E. (2008). Pattern-Based Model-to-
Model Transformation. In 4th International Confer-
ence on Graph Transformations.
Lewis, G. and Smith, D. (2008). Service-Oriented Archi-
tecture and its Implications for Software Maintenance
and Evolution. In Frontiers of Software Maintenance.
Pahl, C. (2002). A Formal Composition and Interaction
Model for a Web Component Platform. ICALP’2002
Workshop on Formal Methods and Component Inter-
action. Elsevier ENTCS.
Pahl, C. and Zhu, Y. (2006). A Semantical Framework for
the Orchestration and Choreography of Web Services.
International Workshop on Web Languages and For-
mal Methods WLFM’05. Elsevier ENTCS.
Weber, B., Rinderle, S., and Reichert, M. (2007). Change
Patterns and Change Support Features in Process-
Aware Information Systems. In 19th Intl. Conference
on Advanced Information Systems Engineering.
ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends
284
