Development of dynamically evolving and self-adaptive software. 2. Understanding and managing change

Transcription

1 Development of dynamically evolving and self-adaptive software 2. Understanding and managing change LASER 203 Isola d Elba, September 203 Carlo Ghezzi Politecnico di Milano Deep-SE DEIB Tuesday, September 0, 3

2 The global picture: the machine and the world (Jackson/Zave) P, Zave, M. Jackson, Four dark corners of requirements engineering, TOSEM 9972 Tuesday, September 0, 3

3 The global picture: the machine and the world (Jackson/Zave) World (the environment) Machine P, Zave, M. Jackson, Four dark corners of requirements engineering, TOSEM Tuesday, September 0, 3

4 The global picture: the machine and the world (Jackson/Zave) World (the environment) Machine P, Zave, M. Jackson, Four dark corners of requirements engineering, TOSEM Tuesday, September 0, 3

5 The global picture: the machine and the world (Jackson/Zave) World (the environment) Machine Goals Requirements P, Zave, M. Jackson, Four dark corners of requirements engineering, TOSEM Tuesday, September 0, 3

6 The global picture: the machine and the world (Jackson/Zave) World (the environment) Machine Shared phenomena Goals Requirements P, Zave, M. Jackson, Four dark corners of requirements engineering, TOSEM Tuesday, September 0, 3

7 The global picture: the machine and the world (Jackson/Zave) World (the environment) Machine Shared phenomena Goals Requirements Specification P, Zave, M. Jackson, Four dark corners of requirements engineering, TOSEM Tuesday, September 0, 3

8 The global picture: the machine and the world (Jackson/Zave) World (the environment) Machine Domain properties, assumptions Shared phenomena Goals Requirements Specification P, Zave, M. Jackson, Four dark corners of requirements engineering, TOSEM Tuesday, September 0, 3

9 Domain properties and assumptions Domain property - statement about problem world phenomena - often it holds regardless of any software-to-be; e.g. physics laws avgtrainacceleration (t, t2) > 0 implies trainspeed (t2) > trainspeed (t) Assumption - statement about problem world phenomena, constraints - may be violated humans behave as instructed by the machine temperature is in the range Celsius device generates a measure every 2 ms. Tuesday, September 0, 3 3

10 Domain assumptions May concern usage profiles users responsiveness remote servers response time network latency sensors/actuators behaviors... Domain assumptions bridge the gap between requirements and specifications (M. Jackson & P. Zave) 4 Tuesday, September 0, 3

11 Dependability arguments Assume you have a formal representation for R = requirements S = specification D = Dp + Da domain properties and assumptions if S and D are both satisfied and consistent, it is necessary to prove S, D = R 5 Tuesday, September 0, 3

12 Change Requirements change Environment changes Change is often a manifestation of uncertainty Change asks for evolution (of the machine) Tuesday, September 0, 3 6

13 Changes may cause evolution Changes are exogenous phenomena that may concern - R S, D = R - D (actually, Da) Changes likely break the dependability argument Evolution (of the machine) is a consequence of change we need to change S (and hence the implementation) to continue to satisfy the dependability argument 7 Tuesday, September 0, 3

14 Evolution (970s) = software maintenance Traditionally, changes to software (the machine, S) in response to changes in D, R are performed manually (by software engineers) and applied off-line, after delivery Maintenance (Lientz and Swanson) classified as - Corrective maintenance Modification to correct discovered problems. - Adaptive maintenance Modification to keep it usable in a changed or changing environment. - Perfective maintenance Modification to improve it functionally/non-functionally. - Preventive maintenance. Anticipate any of the above. Tuesday, September 0, 3 Lientz B., Swanson E., Software Maintenance Management. Addison Wesley, 980 8

15 Early studies on software evolution Software evolution recognized as a crucial problem since the 970 s (work by M. Lehman and L. Belady) Three categories of software - S-programs - written according to an exact specification of what the program can do - P-programs - written to implement certain procedures that completely determine what the program can do (e.g., a program to play chess) - E-programs - written to perform some real-world activity - how they should behave is linked to the environment in which they run - need to adapt to varying requirements and circumstances in that environment Tuesday, September 0, 3 Lehman, M., Programs, Life Cycles, and Laws of Software Evolution, Proc. IEEE, 980 9

16 Lehman s laws of software evolution () Continuing Change E-type systems must be continually adapted or they become progressively less satisfactory. Increasing Complexity As an E-type system evolves its complexity increases unless work is done to maintain or reduce it. Self Regulation E-type system evolution process is selfregulating with distribution of product and process measures close to normal. Conservation of Organizational Stability (invariant work rate) The average effective global activity rate in an evolving E- type system is invariant over product lifetime. Tuesday, September 0, 3 0

17 Lehman s laws of software evolution (2) Conservation of Familiarity Over the lifetime of a system, the incremental change in each release is approximately constant. Continuing Growth The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime. Declining Quality The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes. Feedback System E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base. Tuesday, September 0, 3

18 Software evolution (2000): agility Common to all variants: - Incorporate feedback in an iterative development that supports progressive calibration of objectives and adjustment of requirements Tuesday, September 0, 3 2

19 Software evolution (late 200s) Run-time evolution Self-managing evolution Tuesday, September 0, 3 3

20 Evolution and adaptation Adaptation is a special case of evolution due to changes in domain assumptions, Da an increasingly relevant phenomenon, often due to uncertainty cyber-physical systems - interaction with the physical environment user-intensive systems - changes in usage profile cloud/service infrastructure - platform/software volatility 4 Tuesday, September 0, 3

21 On-line evolution and self-adaptive systems More and more often systems are required to be continuously running This asks for on-line evolution, i.e. applying changes to the machine as the system is running and providing service The special case of self-adaptive systems - on-line adaptation is self-managed 5 Tuesday, September 0, 3

22 Self-adaptive system (SaS) D decomposed into D f and D c D f is the fixed/stable part D c is the changeable part S, D = R A SaS should - detect changes to D c - modify itself (the machine --- S, and the implementation) to keep satisfying the dependability argument, if necessary 6 Tuesday, September 0, 3

23 Paradigm shift SaSs ask for a paradigm shift, which involves both development time (DT) and run time (RT) The boundary between DT and RT fades Reasoning and reacting capabilities must enrich the RT environment - detect change - reason about the consequences of change - react to change 7 Tuesday, September 0, 3

24 To detect change, we need to monitor the environment The changes must be retrofitted to models of the machine+environment that support reasoning about the dependability argument (a learning step) The updated models must be verified to check for violations to the dependability argument In case of a violation, a self-adaptation must be triggered 8 Tuesday, September 0, 3

25 Lifecycle of self-adaptive systems 9 Tuesday, September 0, 3

26 Lifecycle of self-adaptive systems Reqs 9 Tuesday, September 0, 3

27 Lifecycle of self-adaptive systems Reqs Env 9 Tuesday, September 0, 3

28 Lifecycle of self-adaptive systems Reqs 0 Specification E Specification Env 9 Tuesday, September 0, 3

29 Lifecycle of self-adaptive systems Reqs 0 Specification E Implementation Specification Env 9 Tuesday, September 0, 3

30 Lifecycle of self-adaptive systems Reqs 0 Specification E Implementation Development time Specification Env 9 Tuesday, September 0, 3

31 Lifecycle of self-adaptive systems Reqs 0 Specification E Implementation Development time Specification Run time Env 9 Tuesday, September 0, 3

32 Lifecycle of self-adaptive systems Reqs 0 Specification E Implementation Development time Run time Specification Execution Env 9 Tuesday, September 0, 3

33 Lifecycle of self-adaptive systems Reqs 0 Specification E Implementation Monitoring Development time Run time Specification Execution Env 9 Tuesday, September 0, 3

34 Lifecycle of self-adaptive systems Reqs 0 Specification E Reasoning Implementation Monitoring Development time Specification Run time Execution Env 9 Tuesday, September 0, 3

35 Lifecycle of self-adaptive systems Reqs 0 Specification E Reasoning Implementation Development time Self-adaptation Specification Monitoring Run time Execution Env 9 Tuesday, September 0, 3

36 Autonomic computing Tuesday, September 0, 3 20

37 Autonomic computing mic computing Tuesday, September 0, 3 20

38 Zooming in I. Epifani, C. Ghezzi, R. Mirandola, G. Tamburrelli, "Model Evolution by Run-Time Parameter Adaptation, ICSE 2009 C. Ghezzi, G. Tamburrelli, "Reasoning on Non Functional Requirements for Integrated Services, RE 2009 I. Epifani, C. Ghezzi, G. Tamburrelli, "Change-Point Detection for Black-Box Services, FSE 200 A. Filieri, C. Ghezzi, G. Tamburrelli, " A formal approach to adaptive software: continuous assurance of non-functional requirements", Formal Aspects of Computing, 24, 2, March Tuesday, September 0, 3

39 Problem setting Focus on non-functional requirements reliability, performance, energy consumption, cost, Quantitatively stated in probabilistic terms D c decomposed into D u, D s D u = usage profile D s = S... S n S i assumption on i-th service User?? Service S Integrated Service Workflow W <uses> <uses> Service S 2? <uses>...? Service S n 22 Tuesday, September 0, 3

40 An example NrmShipping Login [normal] Search [proceed] [express] CheckOut Buy ExpShipping Logout [buy more] 23 Tuesday, September 0, 3

41 An example NrmShipping Login [normal] Returning customers Search [proceed] [express] CheckOut vs new customers Buy ExpShipping Logout [buy more] 23 Tuesday, September 0, 3

42 An example NrmShipping Login [normal] Returning customers Search [proceed] [express] CheckOut vs new customers Buy ExpShipping Logout [buy more] 3 probabilistic requirements: R: Probability of success is > 0.8 R2: Probability of a ExpShipping failure for a user recognized as ReturningCustomer < R3: Probability of an authentication failure is less then < Tuesday, September 0, 3

43 Assumptions User profile domain knowledge RC NC RC NC RC External service assumptions (reliability) 24 Tuesday, September 0, 3

44 DTMC model Returning Search Buy ExpShipping FailedExpSh Login 0.35 Logged FailedLg 0.3 FailedChk 0.95 CheckOut Logout Success NewCustomer Search Buy NrmShipping FailedNrmSh 25 Tuesday, September 0, 3

45 DTMC model Returning Search Buy ExpShipping FailedExpSh Login 0.35 Logged FailedLg 0.3 FailedChk 0.95 CheckOut Logout Success NewCustomer Search Property check via model checking R: Probability of success is > 0.8 R2: Probability of a ExpShipping failure for a user recognized as ReturningCustomer < R3: Probability of an authentication failure is less then < 0.06 Buy NrmShipping FailedNrmSh 25 Tuesday, September 0, 3

46 DTMC model Returning Search Buy ExpShipping FailedExpSh Login 0.35 Logged FailedLg 0.3 FailedChk 0.95 CheckOut Logout Success NewCustomer Search Property check via model checking R: Probability of success is > R2: Probability of a ExpShipping failure for a user recognized as ReturningCustomer < R3: Probability of an authentication failure is less then < 0.06 Buy NrmShipping FailedNrmSh 25 Tuesday, September 0, 3

47 DTMC model Returning Search Buy ExpShipping FailedExpSh Login 0.35 Logged FailedLg 0.3 FailedChk 0.95 CheckOut Logout Success NewCustomer Search Property check via model checking R: Probability of success is > R2: Probability of a ExpShipping failure for a user recognized as ReturningCustomer < R3: Probability of an authentication failure is less then < 0.06 Buy NrmShipping FailedNrmSh 25 Tuesday, September 0, 3

48 DTMC model Returning Search Buy ExpShipping FailedExpSh Login 0.35 Logged FailedLg 0.3 FailedChk 0.95 CheckOut Logout Success NewCustomer Search Property check via model checking R: Probability of success is > R2: Probability of a ExpShipping failure for a user recognized as ReturningCustomer < R3: Probability of an authentication failure is less then < 0.06 Buy NrmShipping FailedNrmSh Tuesday, September 0, 3

49 What happens at run time? Actual environment behavior is monitored Model updated e.g., by using a Bayesian approach to estimate DTMC matrix (posterior) given run time traces and prior transitions Boils down to the following updating rule 26 Tuesday, September 0, 3

50 What happens at run time? Actual environment behavior is monitored Model updated e.g., by using a Bayesian approach to estimate DTMC matrix (posterior) given run time traces and prior transitions Boils down to the following updating rule 26 Tuesday, September 0, 3

51 What happens at run time? Actual environment behavior is monitored Model updated e.g., by using a Bayesian approach to estimate DTMC matrix (posterior) given run time traces and prior transitions Boils down to the following updating rule A-priori Knowledge 26 Tuesday, September 0, 3

52 What happens at run time? Actual environment behavior is monitored Model updated e.g., by using a Bayesian approach to estimate DTMC matrix (posterior) given run time traces and prior transitions Boils down to the following updating rule A-priori Knowledge A-posteriori Knowledge 26 Tuesday, September 0, 3

53 In our example 27 Tuesday, September 0, 3

54 In our example R2: Probability of an ExpShipping failure for a user recognized as BigSpender < Tuesday, September 0, 3

55 In our example R2: Probability of an ExpShipping failure for a user recognized as BigSpender < Tuesday, September 0, 3

56 In our example Requirement violated! R2: Probability of an ExpShipping failure for a user recognized as BigSpender < Tuesday, September 0, 3

57 Model update and failure prediction Model checking applied to after each update Model checking may predict requirements violations... and trigger self-adaptations before violations manifest themselves 28 Tuesday, September 0, 3

58 In our example Returning Search Buy ExpShipping FailedExpSh Login 0.35 Logged FailedLg 0.3 FailedChk 0.95 CheckOut Logout Success NewCustomer Search Buy NrmShipping FailedNrmSh 29 Tuesday, September 0, 3

59 In our example Returning Search Buy ExpShipping FailedExpSh Login 0.35 Logged FailedLg 0.3 FailedChk 0.95 CheckOut Logout Success NewCustomer Search Buy NrmShipping FailedNrmSh R2: Probability of an ExpShipping failure for a user recognized as ReturningCustomer < Tuesday, September 0, 3

60 In our example Returning Search Buy ExpShipping FailedExpSh Login 0.35 Logged FailedLg 0.3 FailedChk 0.95 CheckOut Logout Success NewCustomer Search Buy NrmShipping FailedNrmSh R2: Probability of an ExpShipping failure for a user recognized as ReturningCustomer < Tuesday, September 0, 3

61 In our example Returning Search Buy ExpShipping FailedExpSh Login Logged FailedLg 5 FailedChk CheckOut Logout Requirement violated! Success NewCustomer Search Buy NrmShipping FailedNrmSh R2: Probability of an ExpShipping failure for a user recognized as ReturningCustomer < Tuesday, September 0, 3

62 In our example Returning Search Buy ExpShipping FailedExpSh Login Logged NewCustomer FailedLg 5 FailedChk CheckOut customers 0.5 have been Search Buy NrmShipping FailedNrmSh Logout Requirement violated! Even if no returning Success 6 observed R2: Probability of an ExpShipping failure for a user recognized as ReturningCustomer < Tuesday, September 0, 3

63 Another example Discrete Time Markov Reward Model (D-MRM) NrmShipping 20 Login Search Buy 0.56 Logout End CheckOut ExpShipping Units: $ Tuesday, September 0, 3

64 Another example Discrete Time Markov Reward Model (D-MRM) NrmShipping 20 Login Search Buy 0.56 Logout End CheckOut ExpShipping Units: $ What s the average cost Tuesday, September 0, 3 of a session?

65 Another example Discrete Time Markov Reward Model (D-MRM) NrmShipping 20 Login Search Buy 0.56 Logout End CheckOut ExpShipping Units: $ What s the average cost Tuesday, September 0, 3 of a session? =