1. Requirements vs. Design vs. Runtime UC San Diego CSE 294 Fall Quarter 2007 Barry Demchak

2. 2 Papers A Reconfiguration Mechanism for Statechart Based Components by Elkorobarrutia, Sagardui, et al (2007) Reconciling System Requirements and Runtime Behavior by Feather, Fickas, et al (1998)

3. 3 The Questions Can requirements and designs be leveraged to facilitate system adaption … yet avoid emergent, inappropriate, or unpredictable behavior? What types of requirements and designs facilitate this? What types of runtime support facilitate this?

4. 4 The Context – Autonomic Computing Autonomic Computing as defined by Kephart and Chess in IEEE Computer Society, January 2003 Systems and integration of systems is getting more complex (installation, tuning, configuration, maintainance) Design getting too complex  push some design decisions to runtime self-* Self-configuration – based on high level policies Self-optimization Self-healing – detect, diagnose, repair Self-protection – malicious attacks, cascading failures

5. 5 Two Approaches Statechart execution (Elkorobarrutia et al) Goal-oriented (Feather et al)

6. 6 Statechart Execution Basic Approach Given a collection of substitutable components, have an application-independent way of choosing one No designer involvement needed Operates at higher level (i.e., component) than Class/Operation/Type (as in Java methodology per Faud) Develop statechart-based components Assist developer in creating executable components Make model available at runtime (i.e., reflection) Based on message dispatcher/receptor model (i.e., perhaps a leadin to SOA)

7. 7 Sample Statechart r o o t=new XorSt a t e ( ) ; r o o t S t a t e=r o o t ; s1=new XorSt a t e ( ) ; r o o t. addSt a t e ( s1 ) ; s2=new AndState ( ) ; r o o t. a d d I n i t i a l S t a t e ( s2 ) ; r eg1=new Region ( ) ; s2. addRegion ( r eg1 ) ; s21=new XorSt a t e ( ) ;... Structure: j r=new J o i nRe a c t i o n ( s1, n u l l, ” e vA j o i n ” ) ; j r. addSource ( s22 ) ; j r. addSource ( s24 ) ; s2. addRe a c t ion (EvA. c l a s s, j r ) ; s1. s e t E x i tAc t i o n ( ” e x i t 1 ” ) ;....... Behavior:

8. 8 State Machine Execution 1. Incoming Message 2. Evaluate Guards 3. Execute action/transition State Machine Repository 2. Replace state machine, add states, remove states 1. Incoming Message

9. 9 Executor Model Well Tested Interceptor site Exception catching Replace executor Can throw exception

10. 10 Advantages Direct connection to UML model – requirements are inferred Execution chosen based on user stimulus or automatic reaction to execution fault Inversion of Control (IoC) allows flexible choice of execution alternatives

11. 11 Disadvantages Undefined semantics for changed statecharts No guarantees that statecharts are correct Independent execution framework was not achieved (interceptors and exception handlers oddly conceived)

12. 12 Goal-oriented Basic Approach Identify high level goals and the services, constraints, and agents that serve them … then figure out way to achieve the goal Allow multiple execution strategies, and provide the means to choose between them Monitor system behavior at runtime, and reconcile it with requirements (-- complete static analysis too costly, and may not even be possible)

13. 13 Closing the Gap (requirements vs runtime) At specification time, identify event sequences to be monitored – acceptable vs unacceptable changes At design time, identify alternative designs and explicitly represent them in trees At runtime, monitor system state to determine when goals are not met, then take remedial action – change parameters or choose alternate design

14. 14 The Players Object – entities, relationships, events characterized by attributes and invariants Actions – input/output relation over objects Agent – object that acts as action processor Goal – contains AND-refinement of subgoals and OR-refinement of alternative subgoals Constraint – ultimate decomposition of goals Assumption – auxiliary assertions KAOS – Specification Language FLEA – Monitoring System

15. 15 KAOS – Specification Language

16. 16 Temperal Logic Operators Cheat Sheet o (in the next state) · (in the previous state)  (eventually)  (some time in the past)  (always in the future) (always in the past) U (always in the future until) W (always in the future unless) Subscripts as realtime restrictions:   nu means “sometime in the future within n time units u”.

17. 17 KAOS – Specification Language Effectively, goal requirements are in constraints

18. 18 FLEA – Runtime Monitor FLEA Language provides constructs for expressing temporal combinations of events Runtime code to monitor such events is automatically generated by FLEA. Consists of: Historical database of events Inference engine Communication system Gathers events Distributes notifications of event combinations

19. 19 FLEA Temporal Patterns

20. 20 More FLEA Events can be composed using boolean operators External events are allowed Definition: (defevent constraints-provided: external (string)) Instance: (constraints-provided 1365124 chp) Events are used for: Detecting violations of complex assertions Keeping track of frequency of violations Deciding when it’s time to react

21. 21 System Architecture

22. 22 KAOS Spec Refinement Graph

23. 23 Requirements-Runtime Reconciliation Development Level Goal-based specification is elaborated KAOS assertions that can be violated are identified – breakable assertions KAOS specification implemented as system of cooperating agents that generate traces of breakable assertions

24. 24 Requirements-Runtime Reconciliation Development Level D1Elaborate the goal refinement graph, identify breakable assertions, and formalize into temporal pattern D2Check for monitorability, identify monitored parameters D3Identify reconciliation tactics (i.e., change a control parameter or switch to alternative design) D4Translate breakable assertions into FLEA D5Bind trace events to particular agent modules

25. 25 Requirements-Runtime Reconciliation Runtime Level R1Establish communication between state information and runtime monitor R2Correlate FLEA event definitions with current design specification R3Start monitoring events and looking for broken assertions

26. 26 KAOS-FLEA Recap Preserves high level goals through Requirements-time reasoning Event-based runtime monitoring System self-adaption tactics Advantages Development artifacts intimately tied to runtime decisions End-to-end demonstration of efficient execution Disadvantages Difficult ADL Awkward integration between KAOS and FLEA layers

27. 27 Methodology Comparison Both Elevate runtime problem resolution to requirements/design level Employ IoC methods in choosing amongst alternatives Self-healing, but in different ways Statecharts Tied to UML Untried end-to-end, many basic questions remain KAOS-FLEA Tied to custom ADL and temporal logic Solid end-to-end demonstration

28. 28 The Questions (again) Can requirements and designs be leveraged to facilitate system adaption … yet avoid emergent, inappropriate, or unpredictable behavior? What types of requirements and designs facilitate this? What types of runtime support facilitate this?

29. 29 Bibliography 1. M. Feather, S. Fickas, A. van Lamsweerde, and C. Ponsard, Reconciling System Requirements and Runtime Behavior, Proc. IWSSD'98 - 9th International Workshop on Software Specification and Design, Isobe, IEEE CS Press, April 1998. 2. M. Rohr, M. Boskovic, S. Gieseck, and W. Hasselbring. Model-driven Development of Self- managing Software Systems. Proceedings of the Workshop ``Models@run.time'' at the 9th International Conference on Model Driven Engineering Languages and Systems (MoDELS/UML'06) 2006. Springer, 4. 3. X. Elkorobarrutia, G. Sagardui, and X Aretxandieta. A Reconfiguration Mechanism for Statechart Based Components. Proceedings of the 1 st Workshop on Model-driven Software Adaptation (M-ADAPT’07 at ECOOP 2007). Berlin, Germany, 2007. 4. F. Barbier. MDE-based Design and Implementation of Autonomic Software Components. Proceedings of the 5 th IEEE International Conference on Cognitive Informatics (ICCI’06). Beijing, China. July, 2006. 5. J. Kephart and D. Chess. The Vision of Autonomic Computing. IEEE Computer 36(2003). 6. G. Blair, N. Bencomo. Workshop Models@run.time. http://www.comp.lancs.ac.uk/~bencomo/MRT07. June, 2007.Models@run.time http://www.comp.lancs.ac.uk/~bencomo/MRT07 7. M. Faud, D. Deb, M. Oudshoorn. Adding Self-Healing Capabilities into Legacy Object Oriented Applications. Proceedings of the International Conference on Autonomic and Autonomous Systems (ICAS). P 15. July, 2006.