a framework for model-driven evolution in families of software architectures

Lero© 2011

A Framework for Model-Driven Evolution in Families of Software Architectures

Pooyan JamshidiLero - The Irish Software Engineering Research Centre,

School of Computing, Dublin City University http://www.computing.dcu.ie/~pjamshidi/

pooyan.jamshidi@computing.dcu.ie

Supervisor: Claus PahlStart Date: Dec. 2010

Lero© 2011

Overview• Context: During software lifecycle the

models at different levels such as process and architecture may evolve independently.

• Problem: Considering the evolution in families of software architectures then the changes at different abstraction become intertwined. Unfortunately, architects have few tools to help plan and execute such complicated changes. Therefore, the architecture “stays behind” (drifts) and becomes eroded!

• Objective: How to specify such changes and how to enable the architecture evolution in an automated fashion

• Tangible Outcome: Framework that support the automated architecture evolution 2

Lero© 2011

Agenda Motivations Background and Context Research Problem Research Method Summary of research to date Plan for next 12 months

3

Lero© 2011

Motivation behind Architecture Evolution

• Capability — to support new features or changes to existing features

• Reusability — to cut and make artifacts for reuse in other software applications

• Extensibility — to accommodate the potential future extensions

• Maintainability — to reduce the cost of software maintenance through restructuring

4

Lero© 2011

Architecture Evolution Questions

• How should we execute the evolution to achieve our goals, given limited resources?

• How can we be certain that intermediate releases do not break existing architectural constraints?

• How can we make tradeoffs between time, cost, development effort, risk, etc.?

• How can we represent and communicate an architecture evolution plan?

5

Lero© 2011

A Model of Architecture Evolution

6

[David Garlan et al.]

Lero© 2011

Product Line Evolution in 2 Dimensions

7

P1V1

P2V1

P2V2

PmV1

PmV3

P2V3

P1V3

PmV2

PmVn

P2Vn

P1Vn

P1V2

New Releases

New

Pro

duct

s

Lero© 2011

What We Can Do: Capture and Reuse it!

• Architectural evolution is a costly yet unavoidable

• Architecture evolution appear to follow certain common patterns [Evolution Style by David Garlan et al.] [Tamzalit et al.], particularly for families of applications.

• By taking advantage of this, we can provide automated assistance for capturing and reusing knowledge about architectural evolution.

8

Lero© 2011

Tangible Example: Change Pattern

9

[David Garlan et al.]

Lero© 2011

Potential Benefits

• Raising the level of abstraction of evolution, reuse, decision automation, and formal guarantees of correctness. Moreover, in the context of SPL, this is necessary to reason about how the change could impact the commonality, variability, and their interdependence.

• The ultimate objective: to facilitate controlled architecture modifications through reusable change patterns

10

Lero© 2011

Agenda Motivations Background and Context Research Problem Research Method Summary of research to date Plan for next 12 months

11

Lero© 2011

State of the Art

12

• State-based PLAs: explicitly captures the versions of artifacts in terms of revisions and variants, which are stored in a repository (SCM system). Examples: Ménage, Mae

• Change-based PLAs: stores the deltas resulting from changes in the repository, Examples: EASEL, COVAMOF

• Hybrid Approach: At the PLA level, change sets represent collections of related changes across architectural elements, at the SCM level, the variation introduced at the architectural level is kept in a configuration model, Example: CHS

Lero© 2011

Addressed Challenges

• Mapping Architecture to Code: through a configuration model that is mapped onto source code

• Maintaining Architectural Consistency: through restricting the kinds of changes that the developer can make to code

• Evolving the Architecture: through reorganizing the code base to maintain consistency with the new PLA

• Deriving Products: through automated product derivation process based on SCM

13

Lero© 2011

Shortcomings and ChallengesI. State-based PLAs track the evolution of both individual

elements and the overall PLA instead of enabling it.II. Invalid products may be composed out of change sets that

contain conflicting or dependent changes.III. Planning evolution would be a pure technical activity since

the change-sets are at the technical architecture against problem space artifacts such as feature models.

IV. Those approaches that considers feature based evolution suppose a 1-to-1 relationship to PLA.

V. Both approaches have not considered the architectural constraints that should be preserved during evolution.

14

Lero© 2011

Primary Research Question

RQ0: “How to manage property preserving architectural changes in families of architectures modeled in different description languages effectively (change pattern) and efficiently (automated)?"

15

Lero© 2011

Property=Architectural Constraint

Concepts in architecture

Constraint

Architecture Model

Use

Satisfy

Conform

Meta-model (MM)

Use

Each architecture model satisfies specific sets of constraints which are described by some kind of formalism mostly as a logic language interweave with the architectural concepts.

16

Lero© 2011

Characteristics of architectural constraints

• Scope: Global or Local• Level of obligation: obligatory or tentative• Level of rigour: informal or semi-formal or

formal• Instances: primitive, pattern, micro-structure,

style, choice, design pattern, invariant, decision, crosscutting concern, coordination, temporal, pre-post- condition

17

Lero© 2011

Intertwined Changes in Families of Software Architectures

18

Architecture-centric evolution in SPL:• Impact of each variable

feature on the software architecture (derivation of the product’s architecture)

• Evolving the architecture to address the feature (after original deployment)

Lero© 2011

Motivating Example: Core Platform (V1)

19

Lero© 2011

Product 1 (V1)

20

Changed models: BPM, FM

A violation of a well-formed-ness constraint in the BPM

Lero© 2011

Core Platform (V1)

21

Lero© 2011

Product 2 (V1)

22

Changed models: FM, ADM

Lero© 2011

Core Platform (V1)

23

Lero© 2011

Core Platform (V1.1)

24

Lero© 2011

Agenda Motivations Background and Context Research Problem Research Method Summary of research to date Plan for next 12 months

25

Lero© 2011

Hypothesis

H1: Capturing the change description and store them into an integrated meta-model regarding these diverse models consisting of elements with heterogeneous types could enable the property-preserving architectural change management in families of architectures.

26

Lero© 2011

Hypothesis

H2: The implementation of the integrated meta-model and application of a formal approach to architecture evolution process could ensure verification of evolved architectural properties.

27

Lero© 2011

Example: change pattern, architectural constraints, preservation, formal foundation

[Costa-Soria and Heckel 2009] 28

Lero© 2011

Detailed Research Questions

• RQ1: How to preserve the architectural constraints during the PLA evolution?

• RQ2: How to support identification and application of reusable changes during the PLA evolution?

• RQ3: How to determine proper consequential changes during the PLA evolution?

29

Lero© 2011

Architectural Constraint Preservation

30

Lero© 2011

Solution Components

• SC1: Integrated meta-model that facilitates capturing the evolution

• SC2: Integrated environment (prototype) that supports managing the evolution

• SC3: Formal foundations based on typed graph transformation systems to describe the semantics of the evolution

31

Lero© 2011

Project Objectives

• Productivity: the automation of consequential changes and also analysis of them with appropriate architect’s intervention

• Changeability: To provide mechanisms to change the several aspects of families of related products seamlessly

• Reusability: specifying change patterns that allows for possible reuse of architectural change operations over families of related architectures

32

Lero© 2011

Agenda Motivations Background and Context Research Problem Research Method Summary of research to date Plan for next 12 months

33

Lero© 2011

Research Method

Unfreezing : Diagnosis, Action Planning(Problem Identification, Project Scope)

Changing: Intervention (Deliverables)

Refreezing: Evaluation, Reflection (Validation)

Planning Action ResultState of the Art

Motivation Example

Research Problem:Research questions, Hypothesis, Solution componentsTheoretical foundations

Initial structure of the solution

Evaluation:Case studyFormal Proofs

Write-up

Integrated meta-model

Integrated environment (proof of concept)

Formal foundations (Theory)

Cyclical Process Model (CPM): • Attempts at solving a real world problem • Simultaneously investigating the experience and improving the solution

34

Lero© 2011

Agenda Motivations Background and Context Research Problem Research Method Summary of research to date Plan for next 12 months

35

Lero© 2011

Summary of research to date

• Literature has been reviewed with a systematic approach.

• Research problem has been identified: main research question, hypothesis, subsequent research questions, and solution component have been stabilized.

• Theoretical foundations have been investigated.• Initial structure of the framework has been

designed.

36

Lero© 2011

Agenda Motivations Background and Context Research Problem Research Method Summary of research to date Plan for next 12 months

37

Lero© 2011

Plan for next 12 months

• Finalizing the elements in the constituting models

• Devising mechanisms for formal architectural constraint representation and constraint preserving evolution according to the framework

• Identifying catalogue of patterns for changes • Discovering the relationships of the change

patterns

38

Lero© 2011

Plan for next 12 months

• To utilize consistency and validation rules to verify the evolved models and to handle inconsistencies

• Investigation of the tools that are existed in the domain of SPL

• Investigation of the repositories storing the SPL development data

• Deep investigation of the formalism that we are going to adopt

39

Lero© 2011

Any Questions

?!

40

Lero© 2011

Backup Materials

41

Definitions: Change, Software Architecture

• Micro-Level– Code: =, ==– Implementation level decisions: bug-fixing• Macro-Level– Design elements: class, relationships…– API design, References problems, Exception-Handling• Architecture-Level: (Shaw, Garlan, and Taylor)– Components, Connectors, configuration– Adding, removing, updating architecturally significant elements

42

EShop monolithic architecture

43

[Tamzalit et al. ]

Evolved client-server EShop architecture

44

Tangible Example

45

[David Garlan et al.]

levels of modeling and constraints

M1 M2

MM1 MM2

PM1 PM2

PM1’ PM2’

C1

C1’’

C1’

C1

C2

C2’’

C2’

C2

DefinesDefines

AugmentsAugmentsAugments

Augments

Validates

Validates

Validates Validates

Validates

Validates

MM/ML1 MM/ML 2CL1 CL2

46

Research questions, hypothesis, solution components

RQ0

H1 H2

RQ1 RQ2 RQ3

SC1 SC2-3

47

48

The Constituting Models and Their Associated Meta-models

49

Software Architecture Evolution Environment (Black Box)

50

Software Architecture Evolution Environment (structure viewpoint)

51

Change-Sets Example

[Scott A. Hendrickson and André van der Hoek]

52

State-based Example

[ROSHANAK ROSHANDEL, et al.]