Requirements vs design vs runtime
Transcript of Requirements vs design vs runtime
![Page 1: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/1.jpg)
Requirements vs. Design vs. Runtime
UC San DiegoCSE 294
Fall Quarter 2007Barry Demchak
![Page 2: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/2.jpg)
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)
![Page 3: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/3.jpg)
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?
![Page 4: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/4.jpg)
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
![Page 5: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/5.jpg)
5
Two Approaches
Statechart execution (Elkorobarrutia et al)
Goal-oriented (Feather et al)
![Page 6: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/6.jpg)
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)
![Page 7: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/7.jpg)
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:
![Page 8: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/8.jpg)
8
State Machine Execution1. Incoming Message
2. Evaluate Guards 3. Execute action/transition
State MachineRepository
2. Replacestatemachine,add states,removestates
1. Incoming Message
![Page 9: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/9.jpg)
9
Executor Model
Well Tested Interceptor site Exception catching Replace executor
Can throw exception
![Page 10: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/10.jpg)
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
![Page 11: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/11.jpg)
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)
![Page 12: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/12.jpg)
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)
![Page 13: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/13.jpg)
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
![Page 14: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/14.jpg)
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
![Page 15: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/15.jpg)
15
KAOS – Specification Language
![Page 16: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/16.jpg)
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”.
![Page 17: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/17.jpg)
17
KAOS – Specification Language
Effectively, goal requirements are in constraints
![Page 18: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/18.jpg)
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
![Page 19: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/19.jpg)
19
FLEA Temporal Patterns
![Page 20: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/20.jpg)
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
![Page 21: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/21.jpg)
21
System Architecture
![Page 22: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/22.jpg)
22
KAOS Spec Refinement Graph
![Page 23: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/23.jpg)
23
Requirements-Runtime ReconciliationDevelopment 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
![Page 24: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/24.jpg)
24
Requirements-Runtime ReconciliationDevelopment Level
D1 Elaborate the goal refinement graph, identify breakable assertions, and formalize into temporal pattern
D2 Check for monitorability, identify monitored parameters
D3 Identify reconciliation tactics (i.e., change a control parameter or switch to alternative design)
D4 Translate breakable assertions into FLEAD5 Bind trace events to particular agent modules
![Page 25: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/25.jpg)
25
Requirements-Runtime ReconciliationRuntime Level
R1 Establish communication between state information and runtime monitor
R2 Correlate FLEA event definitions with current design specification
R3 Start monitoring events and looking for broken assertions
![Page 26: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/26.jpg)
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
![Page 27: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/27.jpg)
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
![Page 28: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/28.jpg)
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?
![Page 29: Requirements vs design vs runtime](https://reader035.fdocuments.net/reader035/viewer/2022062503/58ee19f41a28ab125d8b458b/html5/thumbnails/29.jpg)
29
Bibliography1. 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 ``[email protected]'' 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 1st 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 5th 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 [email protected].
http://www.comp.lancs.ac.uk/~bencomo/MRT07. June, 2007.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.