Upload
pooyan-jamshidi
View
491
Download
3
Tags:
Embed Size (px)
DESCRIPTION
Lero Doctoral Symposium
Citation preview
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/
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.]