modeling and reasoning about software systems containing uncertainty and variability marsha chechik...

Modeling and Reasoning about Software Systems Containing Uncertainty and Variability

Marsha ChechikUniversity of TorontoSeptember 11, 2015

TASE’15, Nanjing, China

2

Acknowledgements

Many thanks for colleaguesin Toronto

• Michalis Famelis• Rick Salay• Julia Rubin• Alessio DiSandro• Yi Li• Benson Quach• Cynthia Disenfield

and elsewhere in the world

• Andrej Wazowski• Aws Albarghouthi• Michal Antkewitz• Krzysztof Czarnecki• Levi Lucio• Gehan Selim• Gabrielle Taenzer• Daniel Struber

3

Why Models?

• Traditional Engineering Approach

– Abstract & Precise

– Amenable to analysis

– Complexity: Model << System

• Pre-development and pre-deployment analysis

– Early detection -> cheaper fixes

• Cost < Benefit

4

Software Engineering Models

Requirements

ArchitectureBehaviour Static Design

Use CasesDeployment

Concepts

StructureAbstraction Purposeful Reasoning

5

Model-Based Software Engineering (MBSE) Toolbox (partial list!)

Support for:Development,

analysis,refinement,

transformation of models +

Communication,documentation

6

• Model-driven engineering under presence of uncertainty

• Model-driven engineering under presence of variability

• Uncertainty and variability combined?• Some current/future work

7

Uncertainty

• Sources• Modeling• Verification of models containing uncertainty

– Technology– Scalability / effectiveness– Dealing with analysis results

• Other parts of MDSE toolbox• Tool support

8

This is Natalie.

Natalie is a modeler.

Natalie faces uncertainty in her everyday work

9

Alternative Designs

Hmm, I don’t know which

one, yet.

10

Conflicting Stakeholder Opinions

What do I do until they decide?

11

Incomplete Information

I don’t know everything about

this, yet.

12

Uncertainty in Software Development

Uncertainty about the content of the model.

Many design alternatives Conflicting stakeholder opinions

Incomplete information

MBSE Toolbox for Natalie?

Existing tools do not applyOptions:

– Wait until uncertainty gets resolved (how long?)– Make a provisional decision and run with it (need backtracking!)

We propose:– Defer resolution of uncertainty but incorporate

uncertainty handling into the development processto allow progress

– Lift standard MDE tools to handle models with uncertainty– Add new tools:

• Help Natalie express her uncertainty• Help Natalie determine what she does not yet know• Help Natalie manage and reduce uncertainty

Mod

el

with

Unc

erta

inty

14

Modeling Uncertainty: Example

Solver

SolverException

+ effect : String

Unsure if it should be an inner class.

Unsure if we need this field.

Notation means “inner class” in UML

15

Some Decisions to Make

Options for assigning values to states of confidence

Quantitative

Examples: 0, 0.3, 0.75

Good for capturing likelihood of events

Hard to capture one’s own uncertainty

Qualitative

Examples: yes/no/don’t know strongly … strongly agree disagree

Good for capturing one’s own level of uncertainty

Less precise than quantitative

16

How to Represent Uncertainty?

Ask users

• Goals: model uncertainty explicitly, keep syntax familiar [MiSE’13]

17

Representing Uncertainty

Partial Models

• Points of uncertainty (“May elements”) explicated using syntactic annotations

Solver

SolverException

+ effect : String


Unsure if we need this field.

[ICSE12]

18


Partial Models


Propositional variables: “the element exists”

Solver

SolverException

+ effect : String

X

Y

[ICSE12]

19

Representing UncertaintySolver

SolverException

+ effect : String

X

Y

Solver

SolverException

Solver

SolverException

Solver

SolverException

+ effect : String

Solver

SolverException

+ effect : String

x=F, y=F x=T, y=F

x=F, y=T x=T, y=T

4 concretizations: 4 ways to resolve uncertainty.

20


Partial Models


• Restrictions to the set of concretizations can be captured in the “May formula”

Solver

SolverException

+ effect : String

X

Y

X v Y

21

Representing UncertaintySolver

SolverException

+ effect : String

X

Y

Solver

SolverException

Solver

SolverException

Solver

SolverException

+ effect : String

Solver

SolverException

+ effect : String

x=F, y=F x=T, y=F

x=F, y=T x=T, y=TX v Y

22

• Benefits– Partial model refinement = uncertainty reduction – Formal: allows analysis and automation– Semantics-independent – applies to models of different types– Use instead of concrete models …

… to allow deferral of decisions without delaying progress

Partial Models

A partial model represents the entire set of possible concrete models

23

Uncertainty




Model Checking

Model M Property P

Does M satisfy P?

counterexample

yes

the property

holds!

verifie

d

25

Properties to Verify

Example property:“Every inner class has at least one attribute”

Natalie’s favorite analysis

technique

How can you apply it to partial models?

Class.allInstances()->forAll( c | not c.nestedIn->isEmpty() implies not c.ownedAttributes->isEmpty() )

Model Checking for Models with Uncertainty

Partial Model M Property P

Does M satisfy P?

yes

the property holds in all

concretizations!

counterexample + concretizations where property

fails

27

Verification: the Naïve ApproachExample property:

“Every inner class has at least one attribute”

Enumerate:

28

Verification: LiftingExample property:

“Every inner class has at least one attribute”

Natalie’s favorite analysis technique,

LIFTED

• Applies directly to the partial model

• Does not enumerate concretizations

• Computes result using three-valued logic

…all concretizations

…some but not all

…none

Property holds for…

29

Verification: Lifting

• Checking syntactic properties [ICSE12]:– Language independent– SMT-based

30

SMT Encoding;Concretizations(define-sort NodeType () Int)(define-sort Node () Int)(declare-fun node (Node) Bool)(declare-fun nodeType (Node) NodeType)(define-sort EdgeType () Int)(define-sort Edge () Int)(declare-fun edge (Edge) Bool)(declare-fun edgeType (Edge) EdgeType)(declare-fun src (Edge) Node)(declare-fun tgt (Edge) Node)(declare-const CLASS NodeType)(assert (= CLASS 1))(declare-const ATTRIBUTE NodeType)(assert (= ATTRIBUTE 2))(declare-const OPERATION NodeType)(assert (= OPERATION 3))(declare-const DEPENDENCY EdgeType)(assert (= DEPENDENCY 4))(declare-const ASSOCIATION EdgeType)(assert (= ASSOCIATION 5))(declare-const NESTEDINREFERENCE EdgeType)(assert (= NESTEDINREFERENCE 6))(declare-const SUPERCLASSREFERENCE EdgeType)(assert (= SUPERCLASSREFERENCE 7))

;Model(declare-const Solver Node)(assert (= Solver 8))(declare-const SolverException Node)(assert (= SolverException 9))(declare-const Y Node)(assert (= Y 10))(declare-const X Edge)(assert (= X 11));End Model

(assert (= (nodeType Solver) CLASS))(assert (= (nodeType SolverException) CLASS))(assert (= (nodeType Y) ATTRIBUTE))(assert (= (edgeType X) NESTEDINREFERENCE))(assert (= (src X) SolverException))(assert (= (tgt X) Solver))(assert (=>

(edge X)(and (node SolverException) (node

Solver))))

;Model is Complete(assert (forall ((c Node)) (=>

(node c)(and

(>= c 8)(<= c 10)

))))(assert (forall ((c Edge)) (=>

(edge c)(and

(>= c 11)(<= c 11)

))));Solver Exists(assert (node Solver));SolverException Exists(assert (node SolverException))

;May Formula(assert (or X Y))

31

Verification: Lifting

• Checking syntactic properties [ICSE12]:

– Language independent– SMT-based

• Checking semantic properties:– Depends on language semantics– Requires custom adaptation of verification technique– Examples:

• Goal satisfaction in i* models [RE12, RE14]

• MTSA: Model checking and other analyses over MTSs [ASE08]

32

Scalability of Verification

• Q: Is verification of models with uncertainty feasible?– How does it compare with checking each model individually?– What about comparison with the classical verification?

• Q: How does the level of uncertainty affect this feasibility?

Experiments: with random inputs and real case studies

Random inputs:varying size of the model and level of uncertaintyspeedup = time for set of conventional models

time to check partial model

33

Results

36

Results of Evaluation

• Is there a speedup?- Yes, it is consistently faster than reasoning with the set.

• How is speedup affected by changing model size and levels of uncertainty?- Speedup decreases with model size- Speedup increases with level of uncertainty- No slowdowns!

Reasoning with Partial modelsvs

Reasoning with a set of conventional models

37

Uncertainty




Analysis Results

Solver

SolverException

+ effect : String


Show user an example:

-- A concretization where the property holds

Analysis Results

Solver

SolverException

+ effect : String


Show user a counterexample:

-- A concretization where the property does not hold

Using Analysis Results

Solver

SolverException

+ effect : String


Generate the diagnostic core:

-- Partial model of concretizations where property does/does not hold

X

Tool Support for Responding to Analysis

Greyed out: not part of the

diagnostic core

Part of the core


Offending May elements removed

44

Uncertainty




45

Uncertainty-Reducing Refinement• Systematically incorporate

new information…– … Manually

• Edit the uncertainty annotations

– … Using automated transformations

Verify that a transformation is always uncertainty reducing.


X v Y

Unsure if we need this

field.

I want to get rid of effect. [FASE12, JOT15]

46

Transformations

The transformations assumeinputs that don’t containuncertainty

Like everygood MBE practitioner,Natalie usesa variety of MTs

But Natalie’s models do!

[MODELS13]

47

Transforming Models with Uncertainty

Natalie should be able to use model transformations

[MODELS13]

48


We need to lift Natalie’s transformations so that they can apply to models with uncertainty

Existing transformation techniques do not support this!


[MODELS13]

49

Goal: “Lifting”

class1

+ attribute : type

class1

- attribute : type+ getAttribute():type

class1

class2

RHSLHSNAC

Solver

SolverException

+ effect : String

Solver

SolverException

+ effect : StringSolver

SolverException

Solver

SolverException

-effect : String+getEffect() : String

Solver

SolverException

+ effect : String

Solver

SolverException

50

Goal: “Lifting”

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Solver

SolverException

+ effect : String

Solver

SolverException


SolverException

( X ¬Y ¬a ¬b) v∧ ∧ ∧(¬X Y ¬a b) v∧ ∧ ∧( X Y a ¬b)∧ ∧ ∧

Solver

SolverException

+ - effect : String+getEffect() : String

X

Ya

b

51

Goal: “Lifting”

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Solver

SolverException

+ effect : String

X

Y

X v Y( X ¬Y ¬a ¬b) v∧ ∧ ∧(¬X Y ¬a b) v∧ ∧ ∧( X Y a ¬b)∧ ∧ ∧

Solver

SolverException


X

Ya

b

52

Lifting Technique Summary

Solver

SolverException

+ effect : String

X

Y

X v Y( X ¬Y ¬a ¬b) v∧ ∧ ∧(¬X Y ¬a b) v∧ ∧ ∧( X Y a ¬b)∧ ∧ ∧

Solver

SolverException


X

Ya

b

Step 1: Determine applicability (Henshin + Z3 SMT Solver)Step 2:Transform graph (Hanshin)Step 3:Transform formula (Java + Z3 input strings)

53

Making the Toolbox... MMINT: Model Management INTeractive [MODELS15]

– A platform for developing (typed) model management tools

– Model management environment:• Diff, refine, merge, etc.

Available at https://github.com/adisandro/MMINT

CSPSAT/SMTHenshinAlloy

54

Making the Toolbox... Uncertainty-aware

MMINT: Model Management INTeractive– A platform for developing (typed) model management tools– Model management environment:

• Diff, refine, merge, etc.

Available at https://github.com/adisandro/MMINTMU-MMINT [ICSE15] – lifting of model management operators + new ones

CSPSAT/SMTHenshinAlloy

Mod

el w

ith

Unc

erta

inty

MU-MMINT(pronounced “Moomin”)

https://github.com/adisandro/MMINT



55

Summary: Uncertainty Modeling and Analysis

• Our choice:– Qualitative, possibilistic

uncertainty modeling– Keeping concrete syntax

familiar– Encoding an exact set of

potential classical models– Refinement – reducing the

set of possibilities– Verification – lifting of

classical approaches

Explicit uncertainty modelingwith Partial Models + May formulas

ConcretizationsPartial model

56




57

Variability

• Context• Modeling• Verification of models containing variability


• Other operators for handling variability

58

Product Lines

+Dry+Dry/Delay+Delay

…

• Goal: Help develop, manage, reuse a large number of similar but different artifact variants (products)

• Example: Washing Machine Co.

+Heat

59

Software Product Line Engineering

a discipline that promotes planned and predictive software reuse

K. Pohl et al., Software Product Line Engineering: Foundations, Principles, and Techniques, 2005

P. C. Clements and L. Northrop, Software Product Lines: Practices and Patterns, 2001

60

Modeling: Product Line Structure + Terminology

• Product line (annotative) represented by – Domain Model – combined parts from all products, annotated by

features (presence conditions)– Feature Model – shows possible features and restrictions for product

combinations

• Example : Washing Machine Co.Feature Model

Wash

Heat

Dry

Delay

excludes

Domain Model

61

Product Derivation (or Configuration)

• The process of deriving a specific software product from:– … artifacts with variability– … feature to artifacts association– … a product definition

62

Product Configuration – Example 1

+Dry/Delay

• +Heat product– Feature configuration: {Wash, Heat}

Feature Model

Wash

Heat

Dry

Delay

excludes

+Heat

63

Product Configuration – Example 2

+Dry/Delay

• +Dry/Delay product – Feature configuration: {Wash, Dry, Delay}

Feature Model

Wash

Heat

Dry

Delay

excludes

+Dry/Delay

64

Domain Model

Washing Machine Product Line

Locking Waiting

Washing

entry/TempCheck()

Drying

Unlocking

[heatEnabled;delayEnabled]/ HeaterOn()

/ HeaterOff(); wash.Start();

/ QuickCool()

/ QuickCool()

[not heatEnabled;not delayEnabled]/ wash.Start();

Presence Conditions

Feature Model

Wash

Heat

Dry

Delay

excludes

Heat Delay

Heat

Heat Delay

Heat Delay

Heat DelayHeat

Heat

Heat Delay

Heat

DryDry

DryDry

Dry

Heat Delay

65

Domain Model

Feature ModelWashing Machine Product Line: Configuring a Product

Locking Waiting

Washing

entry/TempCheck()

Drying

Unlocking



/ QuickCool()

/ QuickCool()


Wash

Heat

Dry

Delay

excludes

Heat Delay

Heat

Heat Delay

Heat Delay

Heat DelayHeat

Heat

Heat Delay

Heat

DryDry

DryDry

Dry

Heat Delay

66

+Dry/Delay Variant

Result: +Dry/Delay State Machine

Locking Waiting

Washing

Drying

Unlocking

[ delayEnabled]

/ wash.Start();

/ QuickCool()

[ not delayEnabled]/ wash.Start();

67

+Dry/Delay Variant

Result: +Dry/Delay State Machine

Locking Waiting

Washing

Drying

Unlocking

[delayEnabled]

/wash.Start();

/ QuickCool()

[not delayEnabled]/ wash.Start();

68

Variability


– Technology and its scalability / effectiveness– Dealing with analysis results


Model Checking

Model M Property P

Does M satisfy P?

counterexample

yes

the property

holds!

verifie

d

Model Checking for Product LinesProduct Line

Model M Property P

Does M satisfy P?

yes

the property holds for

all products!

counterexample + a list of violating products

71

Methods for Checking Systems with Variability

• Input: typically featured transition systems and LTL properties– “Don’t crash into a wall.”

¬ overlap(vehicle, wall)– “Each request is answered.”

(request ⇒ response)• Methods:

– Special-purpose model-checker [Classen – ICSE10]

– Transformation to ..• … Spin [Classen – STTT12]

• … NuSMV [Classen – ICSE11]

• … IC3 [Ben-David – ICSE15]

72

Dealing with Analysis Results

• Model-checking returns a list of violating products

• Methods:– Remove the offending products

(easy to automate)– Debug and reverify to ensure

that property holds for all products (no specific support)

…

73

Variability




Lifting Transformations74

[ICSE14]

75

Other PL Operations

[SPLC13, STTT15]

76

Feature Location and Migration Across Products

Given a history (sequence of commits) and a functionality exercised by tests, find a “semantic slice” that is

well-formedand can pass the same tests

Locating features in cloned variants [ASE12, FASE14, ongoing]

[ASE15]

77

Detecting and Resolving Feature Interaction

• Goal: compositional detection and resolution (using priorities) of behavioral interference properties between features

• Given a selection of features, understanding of the spec of the resulting system

[In progress]

78

Summary: Variability Modeling and Analysis

• Product lines – an industrially-relevant method for compactly encoding sets of similar but different products– Difference is explicated using features

• Verification of product lines:– Determine in which products a property fails– Resolution – reduction of variability or ad-hoc fixing of

products• Other PL operations:

– “lifted” versions of classical – … or special-purpose ProductsProduct Line

79




80

Two common kinds of choices in SE

Uncertainty Variability

Reason Incomplete information, design alternatives, stakeholder conflicts, etc.

Market demands for product variants

Granularity Decisions Features

Expression Partial models Product line (PL) models

Semantics Set of artifacts produced by combinations of decisions

Set of artifacts produced by combinations of features

81

GoalEnable modeling and analysis for design-space exploration of different product lines

i.e., given a space of product lines, which one should be selected (and why)?

Decision combinations produce possible PLs

𝑃 𝑟𝑜𝑑1 𝑃𝑟𝑜 𝑑2 …

Feature combinations produce possible products

𝑃 𝐿1𝑃 𝐿2𝑃 𝐿𝑚⋱

82

Uncertainty + Variability


– What are relevant properties?– How to check these properties?– Dealing with property violations

• Current Status

83

Uncertainty in a Washing Machine Product Line

Domain Model

83

Locking Waiting

Washing

entry/TempCheck()

Drying

Unlocking



/ QuickCool()

/ QuickCool()


Feature Model

Wash

Heat

Dry

Delay

excludes

Heat Delay

Heat

Heat Delay

Heat Delay

Heat DelayHeat

Heat

Heat Delay

Heat

DryDry

DryDry

Dry

Heat Delay

Decision point Mutex Not sure whether Heat and Delay

are mutually exclusive.

Decision point HasSpin Not sure whether to put a guard

NoSpin on transition.

84

A Design Space of Product Lines

Decision combinations produce possible PLse.g., {Mutex, HasSpin}

𝑃 𝑟𝑜𝑑1 𝑃𝑟𝑜 𝑑2 …

Feature combinations produce possible productse.g., {Delay, Heat, Dry}

𝑃 𝐿1𝑃 𝐿2𝑃 𝐿𝑚⋱

Goal: Use properties to explore the design space of PL’s

85

Constraining the Design Space using Properties

• For a product property P – Use All for critical properties and Some for

desirable properties– Use Necessary when you are sure it is needed and

Possible when unsure but don’t want to exclude the possibility

Necessary for product line

Possiblefor product line

Allproducts have P

All products inAll product lines

All products inSome product line

Someproducts have P

Some product inAll product lines

Some product inSome product line

86

Necessary-Some

…

Allproduct lines

Someproduct

87

Possible-Some

…

Some product line

Someproduct

88

Possible-All

…

Some product line

Allproducts

89

Necessary-All

…

Example Prop: State Unlocking must always be reached - a washing machine that violates this is unacceptable

All product lines

Allproduct

Example AnalysisCheck: does prop hold?

90

Uncertainty in a Washing Machine Product Line

Domain Model

90

Locking Waiting

Washing

entry/TempCheck()

Drying

Unlocking



/ QuickCool()

/ QuickCool()


Feature Model

Wash

Heat

Dry

Delay

excludes

Heat Delay

Heat

Heat Delay

Heat Delay

Heat DelayHeat

Heat

Heat Delay

Heat

DryDry

DryDry

Dry

Heat Delay

Decision point Mutex Not sure Heat and Delay are

mutually exclusive.

Decision point HasSpin Not sure whether to put guard

NoSpin on transition.

NO!If and then the guard may prevent state

Unlocking from being reached.

92

Responses to Property Violation

…

Necessary-All?

93

Response 1: Relax Constraint

…

Possible-All? Necessary-All?

94

Response 2: Reduce Uncertainty

…

ReduceUncertainty

Necessary-All?

e.g., decide

95

Response: Reduce Uncertainty

…

Necessary-All?

96

Response: Reduce Variability

…

Reduce Variability

Necessary-All?

e.g., remove feature

97

Response 3: Reduce Variability

…

Necessary-All?

98

Implementation and Status

• Implementation– Proof of concept implementation in Clafer for property

checking and feedback generation– Exploring Higher-Order Alloy*

• Current Work– Evaluating scalability of the tools and effectiveness of the

methodology– Better automation of response strategies– Case studies

• Power Window• “Real” Washing Machine

99

Summary: Uncertainty + Variability• Uncertainty and Variability are similar but different• They can be used effectively together to explore SPL

design space• We defined:

– Four natural classes of properties that can be checked– Responses to property violations

ConcretizationsPartial model ProductsProduct Line

Uncertainty Variability

100




101

Understanding Sources of Uncertainty: Mining Developer Conversations

Mine conversations

Gather Analytics

Generate Action Recommendations

[RSSE14]

102

Understanding Sources of Uncertainty: Mining Developer Conversations

• Identify unique Points of Uncertainty from question utterances

• Associate them with Proposed Alternatives

• Track the stakeholders’ arguments

• Recognize the Resolution of Uncertainty

[RSSE14]

Variability-Aware Transformations

Problem:Graph-based transformationLots of similar yet somewhat different rulesHow to represent these rules so that the transformation

can be done efficiently (e.g., save time on matching to determine applicability) How to produce variability-aware rule sets from lots of rules

[FASE15, additional work in progress]

75

Lifting Code Analyses

A terrific body of work by Christen Kaestner on reinterpreting various code analyses – one at a time- on 150% code models (with #ifdefs)Problem:

Given an analysis method on programs, reinterpret it on 150% representations, together with proofs of correctness (that the method gives correct analysis on each variant)

Specifically, trying to lift analysis behind UFO [CAV12]

a combination between over- and under-approximation

[in progress] 76

105

Representation of Sets

Uncertainty

Product Lines

Metamodels

Megamodels

ConcretizationsPartial model

ProductsProduct Line

InstancesMetamodel

MembersMegamodel

106

Support for Megamodeling

[MODELS15]

• Model management for collection of models

• Additional operations:– Map– Reduce– Filter

107

To Summarize

108

References, part 1108

[MiSE13] Michalis Famelis, Stephanie Santosa: MAV-Vis: Notation for Model Uncertaint. MiSE13 @ ICSE13.

[ICSE12] Michalis Famelis, Rick Salay, Marsha Chechik: Partial models: Towards modeling and reasoning with uncertainty. ICSE 2012: 573-583

[RE12] Rick Salay, Marsha Chechik, Jennifer Horkoff: Managing requirements uncertainty with partial models. RE 2012: 1-10

[RE14] Jennifer Horkoff, Rick Salay, Marsha Chechik, Alessio Di Sandro: Supporting early decision-making in the presence of uncertainty. RE 2014: 33-42

[ASE08] Nicholas D’Ippolito, Dario Fishbein, Marsha Chechik, Sebastian Uchitel: MTSA: The Modal Transition System Analyzer. ASE 2008: 475-476

[FASE12] Rick Salay, Michalis Famelis, Marsha Chechik: Language Independent Refinement Using Partial Modeling. FASE 2012: 224-239

[JOT15] Rick Salay, Marsha Chechik, Michalis Famelis: A Methodology for Verifying Refinements of Partial Models. Journal of Object Technology 2015.

[MODELS13] Michalis Famelis, Rick Salay, Alessio Di Sandro, Marsha Chechik: Transformation of Models Containing Uncertainty. MoDELS 2013: 673-689

[ASE12] Julia Rubin, Marsha Chechik: Locating distinguishing features using diff sets. ASE 2012: 242-245

[FASE14] Daniel Strüber, Julia Rubin, Gabriele Taentzer, Marsha Chechik: Splitting Models Using Information Retrieval and Model Crawling Techniques. FASE 2014: 47-62

[ASE15] Yi Li, Julia Rubin, Marsha Chechik: Semantic Slicing of Software Version Histories: ASE 2015. to appear.

[MODELS15] Rick Salay, Sahar Kokaly, Alessio Di Sandro, Marsha Chechik: Enriching Megamodel Management with Collection-Based Operators. MODELS 2015 to appear

109

References, Part 2109

[CAV12] Aws Albarghouthi, Yi Li, Arie Gurfinkel, Marsha Chechik: Ufo: A Framework for Abstraction- and Interpolation-Based Software Verification. CAV 2012: 672-678

[FASE15] Daniel Strüber, Julia Rubin, Marsha Chechik, Gabriele Taentzer: A Variability-Based Approach to Reusable and Efficient Model Transformations. FASE 2015: 283-298

[ICSE15] Michalis Famelis, Naama Ben-David, Alessio Di Sandro, Rick Salay, Marsha Chechik: MU-MMINT: An IDE for Model Uncertainty. ICSE (2) 2015: 697-700

[MODELS15Tool] A. Di Sandro, M. Famelis, R. Salay, S. Kokaly, M. Chechik. MMINT: A Graphical Tool for Interactive Model Management: MODELS 2015 Demos, to appear

[SPLC13] Julia Rubin, Krzysztof Czarnecki, Marsha Chechik: Managing cloned variants: a framework and experience. SPLC 2013: 101-110

[STTT15] Julia Rubin, Krzysztof Czarnecki. Cloned Product Variants: From Ad-Hoc to Managed Software Product Lines. STTT 2015.

[ICSE14] Rick Salay, Michalis Famelis, Julia Rubin, Alessio Di Sandro, Marsha Chechik: Lifting model transformations to product lines. ICSE 2014: 117-128

[RSSE14] Ahmed Shah Mashiyat, Michalis Famelis, Rick Salay, Marsha Chechik: Using developer conversations to resolve uncertainty in software development: a position paper. RSSE@ICSE 2014: 1-5

[Classen-ICSE10] Andreas Classen, Patrick Heymans, Pierre-Yves Schobbens, Axel Legay, Jean-François Raskin: Model checking lots of systems: efficient verification of temporal properties in software product lines. ICSE (1) 2010: 335-344

[Classen-ICSE11] Andreas Classen, Patrick Heymans, Pierre-Yves Schobbens, Axel Legay: Symbolic model checking of software product lines. ICSE 2011: 321-330

[Classen-STTT12] Andreas Classen, Maxime Cordy, Patrick Heymans, Axel Legay, Pierre-Yves Schobbens: Model checking software product lines with SNIP. STTT 14(5): 589-612 (2012)

[Ben-David-ICSE15] Shoham Ben-David, Baruch Sterin, Joanne M. Atlee, Sandy Beidu: Symbolic Model Checking of Product-Line Requirements Using SAT-Based Methods. ICSE (1) 2015: 189-199

111

Uncertainty-Reducing Refinement• Systematically incorporate

new information

Two options:• Manual

– Edit the uncertainty annotations [FASE’12]

• Using automated transformations– How do you verify that a

transformation is always uncertainty reducing? [VOLT’12]


X v Y

Unsure if we need this

field.

You know what? I want to get rid of

effect.

Analysis Example

• P1: State Unlocking must always be reached– Mandatory, Certain

• Check P1 on washing machine product line WM– Is query ) true? – No! If U2 = True and Dry feature is selected then the guard

may prevent Unlocking from being reached.• Possible corrective actions:

– Resolve uncertainty U2 to False– Modify state machine to have alternate path to Unlocking

74


Offending May elements removed


Greyed out: not part of the

diagnostic core

May elements part of the core

115

Reminder: Model Transformations With Graph Rewriting (“Classical”)

class1

+ attribute : type

class1

- attribute : type+ getAttribute() :type

class1

class2

NegativeApplicationCondition

LeftHandSide

RightHandSide

EncapsulateVariable refactoring:Make fields private and add getter methodsunless they belong to some inner class

Example rule:

116

Graph Rewriting: Example Input Model

SolverSolverException

+ effect : String

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Match

117

Graph Rewriting: Example Input Model

SolverSolverException

+ effect : String

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

NAC also matches! ABORT !

118

Graph Rewriting: Example Input Model 2

SolverException

+ effect : String

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Match

119


SolverException

+ effect : String

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Delete

120


SolverException

- effect : String

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Add

121


SolverException - effect : String + getEffect() : String

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Add

122


SolverException - effect : String + getEffect() : String

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

No more LHS matches.

Stop.

123

And Now: Transforming Models With Uncertainty

Natalie wants to apply the rule to an input with uncertainty

124

Why Transforming Models with Uncertainty is Hard?

Solver SolverException

+ effect : String

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Match???

X

YX v Y

125



+ effect : String

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Match???

X

YX v Y

126



+ effect : String

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Should we delete?Should we add?

X

YX v Y

127



+ effect : String

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Existing transformation techniques cannot be used.

X

YX v Y

128

Goal: “Lifting”

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Solver

SolverException

+ effect : String

X

Y

X v Y

?

129

Goal: “Lifting”

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Solver

SolverException

+ effect : String

Solver

SolverException


SolverException

?

130

Lifting Technique

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Solver

SolverException

+ effect : String

X

Y

X v Y

(a) Find Match

Step 1: Determine applicability

131

Lifting Technique

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Solver

SolverException

+ effect : String

X

Y

X v Y

(a) Find Match

(b) Make sure the rule applies to at least one concretization

(requires solvinga SAT problem)

Step 1: Determine applicability

132

Lifting Technique

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Solver

SolverException

+ effect : String

X

Y

X v Y

Solver

X

Step 1: Determine applicabilityStep 2:Transform graph

SolverException

+ effect : StringY

(a) Copy over unchangedparts

133

Lifting Technique

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Solver

SolverException

+ effect : String

X

Y

X v Y

Solver

SolverException


X

Ya

b

Step 1: Determine applicabilityStep 2:Transform graph

(a) Copy over unchangedparts

(b) Perform additions and deletions

Added and deleted elements become Maybe

134

Lifting Technique

class1

+ attribute : type

class1


class1

class2

RHSLHSNAC

Solver

SolverException

+ effect : String

X

Y

X v Y

Step 1: Determine applicabilityStep 2:Transform graphStep 3:Transform formula

( X ¬Y ¬a ¬b) v∧ ∧ ∧(¬X Y ¬a b) v∧ ∧ ∧( X Y a ¬b)∧ ∧ ∧

Solver

SolverException


X

Ya

b

Constrain Maybe elementsto ensure each thatconcretizationis correctly affected.

135


We need to lift Natalie’s transformations so that they can apply to models with uncertainty

Existing transformation techniques do not support this!


[MODELS13]

modeling and reasoning about software systems containing uncertainty and variability marsha chechik...

Documents

model uncertainty

this13modeling uncertainty

level of uncertainty

resolution of uncertainty

modeldriven engineering

uncertaintyhelp natalie

knowhelp natalie

uncertainty13 model