Design Models for Adaptive

(1)

REQUIREMENTS ENGINEERING LAB

Integrating Requirements and Design Models for Adaptive

Systems

Jaelson Castro, Universidade Federal de Pernambuco, Brazil

IFIP 2.9 meeting (2016), 22-02-16

Pernambuco, Brazil

(2)

Integrating Requirements and Design Models for Adaptive

Systems

IFIP 2.9 meeting (2016)

Pernambuco, Brazil

(3)

Integrating Requirements and Design Models for Adaptive

Systems

IFIP 2.9 meeting (2016)

Pernambuco, Brazil

(4)

Core idea

Define feedback loops considering requirements and design concerns

Specify adaptive behaviour with complementary models

4

(5)

Traditional example: fridge

5

if (door open)

^ increase power

if (gets hotter outside)

^ increase power

If (fridge is full)

^ increase power/

Condition or

context-based

(6)

Traditional example: fridge

6

Here’s what I want:

10ºC

Here’s what you can do:

+ Increase power - Decrease power

Feedback

loop

(7)

7

Real world, software example

(8)

8

LOAD

VARIATION

PROVISION

VARIATION

(9)

9

Resolution changes

according to bandwidth

(10)

Software Adaptation Frameworks

Requirements-based

 Goldsby et al. (2008)

 Morandini et al. (2008)

 Lapouchnian and Mylopoulos (2009)

 Dalpiaz et al. (2009)

 Qureshi et al. (2010)

 Bencomo et al. (2010)

 Baresi and Pasquale (2010)

 Souza et al. (2011)

 ...

Architecture-based

 Allen et al. (1998)

 Oreizy et al. (1998)

 Dowling and Cahill (2001)

 Garlan et al. (2004)

 Asadollahi et al. (2009)

 Cetina et al. (2009)

 ...

10

(11)

Twin Peaks

11 Source: [1]

PROBLEM SOLUTION

(12)

Early

Requirements

Late

Requirements

Architectural Design

Detailed Design This is where our framework fits in

12

(13)

Core idea

13

(14)

BASELINE

14

(15)

Goal Model

15

(16)

Goal Model

16

(17)

Goal Model

17

(18)

Goal Model

18

(19)

Goal Model

19

(20)

Goal Model

20

(21)

Goal Model

21

(22)

Goal Model

22

(23)

23

Goal Model

Feedback

Loops

Zanshin

(24)

Zanshin

 Extended Goal Model

 Feedback Loop

 Set of adaptation actions

 Control algorithm

 Reasoning engine

 Prototype implementation

24

(25)

Awareness Requirement

25

Awareness Requirements:

what you monitor

(26)

Awareness Requirement

 NeverFail

 NotTrendDecrease

 SuccessRate

 MaxFailure

 ComparableSuccess

 ComparableDelta

 StateDelta

26

(27)

Parameter

27

Parameter: what you can change to improve

the results FhM: From how Many

VPA: View Private Appointments MCA: Maximum # Conflicts Allowed

(28)

Adaptation Strategies

 Abort

 Delegate

 Relax

 Replace

 Retry



Reconfigure

 Strengthen

 Warning

28

(29)

Proposal:

MULAS

Framework

MUlti-Level Adaptation for Software Systems

(30)

MULAS Framework – what’s in it?

 Extended goal model ^[3]

 Design process ^[4]

 Model transformation

 Design Goal Model  Statechart _[5]

 Runtime engine (borrowed from Zanshin ^{[6] )}

 Supporting tool ^[7]

30

(31)

Design Goal

Model

(32)

Design Goal Model – New Elements

32

Flow expressions

New elements

(33)

What is the difference?

Requirements

 Stated by stakeholders (customers, users)

 Changes must be

negotiated and approved by stakeholders

 The rationale is mostly domain-related

Design

 Stated by designers

 Changes are negotiated by designers

 The rationale is mostly technology-related

33

(34)

Design constraints,

Design assumptions, (Design) tasks

34

(35)

It allows us to describe...

35

 Algorithms

 Additional tasks

 Particular implementation technologies

 Constraints arising from the choice of algorithms or technology

(36)

36

 How a quality constraint will be satisfied

 Alternative technologies that were considered

 Assumptions made by

designers and developers

It allows us to describe...

(37)

The use of different

views

allow to treat requirements independently from design

37

(38)

Behaviour and

behavioural variability

38

(39)

Behaviour described through flow expressions

39

(40)

Statechart derivation

40

(41)

Incremental design

41

(42)

Behavioural variability

42

(43)

Adaptation

43

(44)

Adaptation

 With...

 Awareness Requirements

 Parameters

 + Design Constraints, + Design Assumptions, + (Design) Tasks

 We can express...

 Monitoring

 Adaptation strategies

44

(45)

Adaptation - Monitoring

 Monitoring

 Monitor the achievement of a goal

 Monitor the validity of a domain assumption

 Monitor the execution of an algorithm

 Monitor the satisfaction of design constraints

 ...

45

(46)

Adaptation - strategies

 Adaptation strategies

 Retry the achievement of a goal

 Alert an stakeholder

 Abort the execution of an algorithm

 Execute a different algorithm instead

 Request a person to perform a task

 Change the value of a design parameter

 ...

46

(47)

Core idea

47

(48)

Complementing the specification

Ok, we will monitor this goal, but

 How?

 When?

48

Collect from Google Calendar (dt49)

exit informResultAR2()

Collect Automatically (t14)

Check Calendar Update Date (dt86) entry informStartAR4()

exit informResultAR4() if (DelegateAR4) then

delegate(“dt86”, “CompanyManager”)

(49)

Complementing the specification

49

Ok, we can change this parameter, but

 How does this change affect the system’s behaviour?

(50)

Complementing the specification

50

Adaptation Strategies

 Abort

 Delegate

 Replace

 Retry

 Reconfigure

 Warning

Idle (i1)

Process

Characterization (dt58) entry informStartAR9() exit informResultAR9() if (DelegateAR9) then

delegate(“ResponseTime<2s”, “SoftwareArchitect”)

After 5000ms (RetryAR7)

(51)

Evaluation

(52)

Evaluation

 Case studies with simulation

 Meeting Scheduler

 Automatic Telling Machine

 Case study with execution

 Line-tracking robot

 Experiments

 Following the process and creating the models

 Statechart derivation performance

52

(53)

Can we expect people to write flow expressions? Yes

53

(54)

Minor mistakes

54

(55)

55

Can we expect people to

include adaptation actions on

statecharts? Yes

(56)

56

Can we expect people to create statecharts from flow

expressions? Yes

(57)

Tool Support

(video)

https://www.youtube.com/watch?v=vl4MdkGkzdQ

(58)

Conclusion

(59)

Main Contributions

 Modeling Notation

 Design Goal Model

 Behavioural variability

 Architectural Design Process

 Prototype tool support

 Modeling/views

 Statechart derivation

59

(60)

Benefits

 Adaptation with requirements and design concerns

 Enactment of requirements adaptation

 Derivation of statecharts

 Twin Peaks process

60

(61)

Core idea

61

(62)

Call for Collaboration

 Interesting applications

 Additional adaptation mechanisms/extensions

 Better reasoning engine

62

(63)

Thanks!

Jaelson Castro jbc@cin.ufpe.br

(64)

References

1. Nuseibeh, B.: Weaving together requirements and architectures (Computer 34, 2001).

2. Souza, V.E.S., Lapouchnian, A., Mylopoulos, J.: System Identification for Adaptive Software Systems: A Requirements Engineering Perspective (ER 2011).

3. Pimentel, J.: Systematic Design Of Adaptive Systems — Control-based Framework (Ph. D thesis)

4. Pimentel, J., Castro, J.: Designing adaptive systems (ISTAR 2015).

5. Pimentel, J., Castro, J.: Mylopoulos, J., Angelopoulos, K., Souza, V. E. S. From Requirements to Statecharts via Design Refinement (SAC 2014).

6. Souza, V. E. S.: Requirements-based software system adaptation (Ph. D thesis)

7. Pimentel, J., Vilela, J., Castro, J.: Web Tool for Goal Modelling and Statechart Derivation (RE 2015).

(65)

DGM – Allowed Refinements

65

(66)

Adaptation Strategies – Meeting Scheduler

66

(67)

Flow Expressions

( A B ( C | D ) E F* G ) ^ʘ ( H* )

67

 A B ^ B after A

 A | B ^ A or B

 A* ^ A zero or more times

 A+ ^ what we wish for in our courses

and A one or more times

 A? ^ A is optional

 A ^ʘ B ^ A and B concurrently

(68)

Derivation Patterns

68

(69)

DGM  Statechart

69 Cancel Meeting

(t17)

Manage Meeting (g5)

Idle (i4)

Confirm Occurrence (t18)

Change Room (t22)

Change Date (t21)

Change Details (g20)

Change Participants (t23)

Notify Participants

(t19)

(70)

Simulation

70

(71)

Statechart derivation performance

71

(72)

Guidelines – adaptation on statecharts

 Abort —include a transition from the last state(s) related to the monitored element onto a target state. Transition label: always [AbortARx].

 Abort With Action — in the case of atomic actions, include these actions as exit actions of the last state(s) related to the monitored element, and also apply Guideline 1. In the case of non-atomic actions, they can be

included in a sequence of new states that represent their behaviour, also with a transition from the last of these new states onto the target state.

Action: if [AbortARx] then action1; action2; etc.

 Delegate —include a delegation action as exit action of the last state(s) related to the monitored element, conditional to the need of executing the adaptation. Action: if [DelegateARx] then delegate(element, actor to be delegated to).

72

(73)

 Retry — Include a transition from the state(s) that are subsequent to the target state back onto the target state, using the delay interval as the trigger for this transition. Transition label: after x ms [RetryARx].

 Step Back — include a transition from the end state(s) related to the monitored element back onto itself. Transition label: [StepBackARx].

 Notify —Include a ‘notify’ action as exit action of the last state(s) related to the monitored element, conditional to the need of executing the

adaptation. Transition label if [NotifyARx] then notify(element, actor to be notified).

73