Requirements vs design vs runtime

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
ate Machine
pository
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
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 FLEA
D5 Bind trace events to particular agent modules

25. 25
Requirements-Runtime Reconciliation
Runtime 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

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 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 Models@run.time.
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.