24) Condition-Action-Analysis and Event-Condition-Action-Based - - PowerPoint PPT Presentation

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

24) Condition-Action-Analysis and Event-Condition-Action-Based Design

• Prof. Dr. U. Aßmann

Technische Universität Dresden Institut für Software- und Multimediatechnik Gruppe Softwaretechnologie http://st.inf.tu- dresden.de/teaching/swt2 Version 16-1.1, 14.01.17 1. Structured decisions: decision diagrams and decision tables) 2. Binary decision diagrams (BDD) And Ordered DD 3. Model Checking 4. Variability of CA 5. Event-Condition Action Design 6. Extensibility of ECA

• Prof. U. Aßmann

1

Softwaretechnologie II

Obligatory Reading

►

Balzert, Kapitel über Entscheidungstabellen

►

Ghezzi 6.3 Decision-table based testing

►

Pfleeger 4.4, 5.6 Ø Stankovski, V., Trnkoczy, J. Application of decision trees to smart homes. In Designing Smart Homes - The Role of Artificial Intelligence, J. C. Augusto and C. D. Nugent, Eds., Lecture Notes in Artificial Intelligence, vol. 4008, Springer Verlag, 2006, 132–145. Ø Randal E. Bryant. Graph-based algorithms for Boolean function

• manipulation. IEEE Transactions on Computers, C-35:677-691, 1986.

Ø Red Hat. JBoss Enterprise BRMS Platform 5: JBoss Rules 5 Reference Guide. (lots of examples for ECA Drools)

• http://docs.redhat.com/docs/en-

US/JBoss_Enterprise_BRMS_Platform/5/pdf/JBoss_Rules_5_Reference_Guide/JBos s_Enterprise_BRMS_Platform-5-JBoss_Rules_5_Reference_Guide-en-US.pdf

• Prof. U. Aßmann

2

Softwaretechnologie II

References

►

Decision algebra:

►

Danylenko, Antonina, Lundberg, Jonas, Löwe, Welf. Decisions: Algebra and

• Implementation. In Machine Learning and Data Mining in Pattern Recognition.

Perner, Petra(ed.) Lecture Notes in Computer Science, 6871, Springer 2011. http://dx.doi.org/10.1007/978-3-642-23199-5_3

►

ECA state of the art

►

REWERSE-DEL-2004-I5-D1 José Júlio Alferes, James Bailey, Mikael Berndtsson, François Bry, Jens Dietrich, Alex Kozlenkov, Wolfgang May, Paula-Lavinia Pătrânjan, Alexandre Miguel Pinto, Michael Schroeder, and Gerd Wagner: Wolfgang May (editor): State-of-the-art on evolution and reactivity. http://rewerse.net/publications/rewerse-publications.html#REWERSE-DEL-2004- I5-D1

►

http://en.wikipedia.org/wiki/Complex_event_processing

►

ECA Engines

►

Websphere Jrules engine http://www-01.ibm.com/software/integration/business- rule-management/decision-server/

►

JBOSS Rules http://www.jboss.org/drools

►

http://docs.redhat.com/docs/de-DE/JBoss_Enterprise_BRMS_Platform/index.html

• Prof. U. Aßmann

3

Softwaretechnologie II

Goal

Ø Decision analysis (Condition analysis) is a very important method to

analyze complex decisions

Ø Understand that several views on a decision tree exist (tables, BDD,

OBDD)

Ø Condition-action analysis can also be employed for requirements

analysis

Ø Understand how to describe the control-flow of methods and

procedures and their actions on the state of a program

Ø Event-condition-action-based design (ECA-based design) relies on

condition-action analysis

Ø Understand that model checking is a technology with future

• Prof. U. Aßmann

4

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

24.1 DECISION ANALYSIS WITH DECISION TREES AND TABLES (CONDITION-ACTION ANALYSIS)

• Prof. U. Aßmann

5

Softwaretechnologie II

A House-Selling Expert System

Ø Ok, I do not like bungalows, but my wife does not like that the car stands in free space in winter. Hmm... I rather would like to have the half double house... But we need anyway 2 floors, because I need this space for my

• hobbies. My wife also would like a garden….

►

How does the system analyze the customers requirements and derive appropriate proposals?

• Prof. U. Aßmann

6

Softwaretechnologie II

Decision Analysis (Condition-Action Analysis)

Ø Decision analysis is necessary when complex, intertwined decisions

should be made

• In requirements analysis and elicitation
• In complex business cases, described with business rules
• In testing, for specification of complex test cases

Ø Decision analysis can be made in a decision algebra

• Boolean functions and their representations (implementations):

§

Truth tables, decision trees, decision tables

§

Binary decision diagrams (BDD), ordered BDD (OBDD)

• Static single assigment form (SSA) (not treated here)
• Lattice theory, such as formal concept analysis (FCA) (not treated here)

Ø Decision trees and tables collect actions based on conditions Ø Condition action analysis is a decision analysis that results in actions

Ø A simple form of event-condition-action (ECA) rules Ø However, without events, only conditions

• Prof. U. Aßmann

7

Design Question: Which conditions provoke which actions?

Softwaretechnologie II

Decision Trees

Ø Decisions can be analyzed with a decision tree, a simple form of a decision

algebra

Ø A trie (Präfixbaum) is a tree which has an edge marking

Ø Every path in the trie assembles a word from a language of the marking

Ø A trie on lB = {0,1} is called decision tree

Ø Paths denote sequences of decisions (a set of vectors over lB). A path corresponds

to a vector over lB

Ø A set of actions, each for one sequence of decisions Ø Sequences of decisions can be represented in a path in the decision tree

• Prof. U. Aßmann

8

000 001 01 10 11 1 00 1 1 1 1 e A1 A2 A3 A4 A5

Softwaretechnologie II

Decision Trees with Code Actions

►

The action may be code

►

The inner nodes of same tree layer correspond to a condition E[i]

►

Then, a Trie is isomorphic to an If-then-else cascade

• Prof. U. Aßmann

9

000 001 01 10 11 1 00 1 1 1 1 e A1 A2 A3 A4 A5

E0 E1 E2 E3 if (E0) then // case E0 === true if (E1) then

if(E2) then A5 else A4

else // case E0 === false if (E1) then

if(E2) then A3 else

if (E3) then A2 else A1

Softwaretechnologie II

Extensibility of Decision Trees

Ø Decision Trees can be completed by new alternatives Ø Decision Trees can be extended by new decisions (variables)

• Prof. U. Aßmann

10

Extensibility Question: Which further conditions provoke which further actions?

000 001 01 10 11 1 00 1 1 1 1 e

E0 E1 E2 E3 (complete)

101 101 1 110 111 1 010 011 1

New E4 (incomplete)

0110 0111 1 1100 1101 1

A1 A1 A2 A2 A3 A32 A3 A33 A4 A41 A4 A42 A5 A51 A5 A52 A3 A31 A5 A53

Softwaretechnologie II

Decision Tables

►

An alternative representation of decision trees are decision tables

►

Conditions and actions can be entered in a table

• Prof. U. Aßmann

11

01 10 11 1 00 1 1 1 e A1 A2 A1 A2

E0 E1

Condition E0 yes yes no no Condition E1 yes no yes no Action A1 X X Action A2 X X

Multiple choice quadrant Boolean cross product

Softwaretechnologie II

Process: How to Construct A Decision Table

1) Elaborate decisions 2) Elaborate actions 3) Enter into table 4) Elaborate: Construct a cross boolean product as upper right quadrant (set

• f boolean vectors)

5) Elaborate: Construct a multiple choice quadrant (lower right) by associating actions to boolean vectors 6) Consolidate

■

Coalesce yes/no to “doesn’t matter”

■

Introduce Else rule

• Prof. U. Aßmann

12

Softwaretechnologie II

13

What Students Should Do to Professors After Exams

• Prof. U. Aßmann

13

Points <= 30 yes yes yes yes No No No no 50 < Points yes yes no no yes yes no no

• St. Francophil?

yes no yes no yes no yes No Student pays a Bordeaux X X Professor pays a Bordeaux X Professor pays a beer X Student pays a beer X Professor drinks a beer X X X >

Softwaretechnologie II

14

Common Columns Can Be Folded

• Prof. U. Aßmann

14

Points <= 30 yes

• yes

no no no 50 < Points yes no no yes yes no

• St. Francophil?
• yes

no yes no no Student pays a Bordeaux X Professor pays a Bordeaux X Professor pays a beer X Student pays a beer X Professor drinks a beer X X >

Softwaretechnologie II

15

Or Abbreviated to Else Action (Consolidated Decision Table)

• Prof. U. Aßmann

15

Points <= 30

• yes

No No Else 50 < Points no no yes yes Francophil? yes no yes no Student pays a Bordeaux X Professor pays a Bordeaux X Professor pays a beer X Student pays a beer X Professor drinks a beer X

>

Softwaretechnologie II

Applications of Decision Tables and Trees

Ø Requirements analysis:

• Deciding (decision analysis, case analysis)
• Complex case distinctions (more than 2 decisions)

Ø Design:

• Describing the behavior of methods
• Describing business rules

Ø Before programming if-cascades, better make first a nice decision tree or

table

Ø Formal design methods Ø CASE tools can generate code automatically

Ø Configuration management of product families:

Ø Decisions correspond here to configuration variants Ø Processor=i486? Ø System=linux? Ø Same application as #ifdefs in C preprocessor

• Prof. U. Aßmann

16

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

24.2 NORMALIZING CONTROL FLOW WITH NORMALIZED BDD

• Prof. U. Aßmann

17

Softwaretechnologie II

Truth Tables are Decision Tables with Target Domain Bool

►

With action = {true, false}, boolean decision tables are truth tables

►

Truth table:

• Prof. U. Aßmann

18

E0 E1 F Yes Yes Yes No 1 No Yes No No 1 Condition E0 Yes Yes No No Condition E1 Yes No Yes No Value of F = 0 X X Value of F = 1 X X

Softwaretechnologie II

BDDs (Binary Decision Diagrams)

►

BDD are dags that result by merging the same subtrees of a decision tree into one (common subtree elimination)

• Prof. U. Aßmann

19

000 001 01 10 11 1 00 1 1 1 1 e A1 A2 A3

E0 E1 E2 E3

Softwaretechnologie II

BDDs (Binary Decision Diagrams)

►

If the action is just a boolean value boolean functions f: lBn --> lB can be represented

►

The decisions E[i] are regarded as boolean variables

• Prof. U. Aßmann

20

000 001 01 10 11 1 00 1 1 1 1 e 1

E0 E1 E2 E3

Softwaretechnologie II

OBDDs (Ordered Binary Decision Diagrams)

Ø Problem: for one boolean function there are many BDD, depending on the

• rder of the variables

Ø Idea: introduce a standardized order for the variables Ø Result: ordered binary decision diagrams (OBDD) Ø In all OBDD holds: Ø for all children u of parents v ord(u) > ord(v). Ø For one order of variables there is one normal form OBDD (canonical

OBDD)

Ø This canonical form leads to an efficient OBDD-based comparison

algorithm of boolean functions:

compareBooleanFunction() = { Fix variable order for two BDD Transform both BDD into OBDD Compare both OBDD syntactically }

• Prof. U. Aßmann

21

Softwaretechnologie II

Complex BDD

• Prof. U. Aßmann

22

Softwaretechnologie II

The Influence of Variable Ordering with BDD

• Prof. U. Aßmann

23

Softwaretechnologie II

If-cascades, BDD and OBDD

if A then if B then if C then true else false else if C then false else true else if B then if C then false else true else if C then true else false

• Prof. U. Aßmann

24

B C C C B C 1 1 1 1 A 1

A B C

1 1 1 1 B C C B 1 1 1 A 1

A B C

1 1

Variable order is [A,B,C]

Softwaretechnologie II

Normalizing Wild Procedures: Normalized If-Structures with OBDD

Ø There is only one canonical OBDD for one order Ø Develop normalized and factorized if-structures with the canonical OBDD:

• 1. Elaborate arbitrary decision tree
• 2. Choose a variable order
• 3. Transform to OBDD
• 4. Transform to If structure
• 5. Factor out common subtrees by subprograms
• Prof. U. Aßmann

25

Acycl cyclic co control fl flow

• w ca

can be be represe sented ca canonica cally by by an an OBD OBDD

Softwaretechnologie II

Applications

Ø Requirements analysis

• Complex case analyses from customer interviews

Ø Design

• Normalized control-flow structures
• Complex case analyses for many boolean variables (decisions)

Ø Reengineering

• Structuring of legacy procedures: read in control-flow; construct control-flow

graph

• Produce a canonical OBDD for all acyclic parts of control-flow graph
• Pretty-print again
• Or: produce a statechart

Ø Configuration management

• Configuration of a software system to a platform is often a case analysis over

many boolean or integer variables

• Development of canonical versions of C preprocessor nestings
• Help to master large systems
• Prof. U. Aßmann

26

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

24.2.2 MODEL CHECKING LARGE STATE SPACES

• Prof. U. Aßmann

27

Softwaretechnologie II

Representation of Mathematical Structures in Decision Algebras (BDD and OBDD)

Many mathematical data types can be represented with decision algebras and boolean functions (most efficiently with BDD/OBDD):

►

Functions over finite domains of size n [Bryant86]

■

Associate to every element a vector from lBk, where k = ld n

■

Code sets with sets of such vectors

■

Map again to boolean algebra

►

Sets, partial orders and lattices (e.g., in Z, VDM, SETL)

■

Represent subsets of a set in the powerset lattice of the set

■

Map the powerset lattice to a boolean algebra (theorem of Stone)

■

Use a BDD to encode the sets

■

Uniform efficient representation in space and time

►

Relations and graphs

►

Interprete the elements of the relation (the edges) as sets of ordered k-tuples

►

Represent as in the case of sets

►

Thus, it is possible to encode databases into BDD

►

Specific graphs:

►

State machines

►

Data-flow graphs

►

Propositional logic formulas

• Prof. U. Aßmann

28

Softwaretechnologie II

Model Checking on BDD

►

BDD and OBDD are very compact representation for state machines, boolean functions, predicate logic, and modal logic

►

Build a basis for checking state transition systems with modal logic (model checking)

■

System is modeled as a state transition system and encoded as OBDD

■

Features of the system (predicates, logic formulas) are encoded as OBDD, too

■

Important: System and predicates to be checked are both encoded as OBDD

■

Model checking:

■

Then, a model checker compares the OBDDs and checks whether a feature holds in a state

■

Effectively, the model checker only compares normalized representations of boolean functions, the OBDD

• Prof. U. Aßmann

29

Softwaretechnologie II

The Use of Model Checking

►

State spaces up to 2**120 can be handled

►

Model checking checks whether features hold in states of large state spaces

■

Used in hardware verification ♦ Proving circuits correct

■

Software verification ♦ Safety-critical systems ♦ Minimization of boolean circuits

►

Very important technique for verification of safety-critical hard- and software

• Prof. U. Aßmann

30

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

24.3 VARIABILITY OF CONDITION- ACTION RULES

• Prof. U. Aßmann

31

Softwaretechnologie II

Variability

Ø Variability means that actions are exchanged for boolean combinations

• Prof. U. Aßmann

32

Variability is simple in Condition-Action-Systems

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

24.4 EVENT-CONDITION-ACTION BASED DESIGN (ECA)

• Prof. U. Aßmann

33

Softwaretechnologie II

Event-Condition-Action Design

Ø Decision analysis is invoked when events occur Ø Event-condition-action (ECA) based design uses

• ECA rules with condition-action analysis
• Complex event processing (CEP) for recognition of complex events
• Prof. U. Aßmann

34

Design Question: Given some (complex) events, which conditions provoke which actions? Extensibility Question: Which further events, which further conditions provoke which further actions?

Softwaretechnologie II

ECA with State-Based Specifications

►

An event-condition-action (ECA) system listens on channel(s) for events, analyses a condition, and executes an action

■

Statecharts (see course ST)

■

Petri Nets (see corr. Chapter)

■

ECA rules (Drools)

■

Condition analysis can be done by BDD

■

Verification by model checking

■

Process:

■

Collect all ECA rules

■

Collect all states

■

Link states with ECA rules as transitions

• Prof. U. Aßmann

35

Tür abgesperrt verriegeln/ amp.rotesLicht An() entriegeln/ amp.grünesLi chtAn() geschlossen schließen/ amp.gelbesLic htAn() öffnen()/

• öffnen(),

verriegeln() , entriegeln() /

• öffnen,

schließen , verriegeln /

• entriegeln(),

schließen()/ beep()

• ffen

öffnen() schließen() verriegeln() entriegeln()

<<Steuerungsmachine>>

Softwaretechnologie II

ECA with Petri Nets

►

In a Petri Net, an event-generating channel is a transition with fan-in=0

►

Listening to the events, the Petri Net can do condition-action analysis

• Prof. U. Aßmann

36

Tür

öffnen() schließen() verriegeln() entriegeln()

<<Steuerungsmachine>> Sc Schließknopf dr drüc ücken en

• ffe

n

Öf Öffne-Kn Knopf dr drüc ücken en öffnen(), verriegeln(), entriegeln()

geschl

• ssen

öffnen() schließen entriegeln(), schließen()

Schließknopf drücken Öffne-Knopf drücken

■

Process:

■

Collect all ECA rules

■

Collect all states

■

Link states with ECA rules as subnets reacting

• n event-

generating channels

Softwaretechnologie II

ECA-based Blackboard Style

Ø The ECA-blackboard has two repositories: a fact/object base and a rule base Ø The rule base is an active repository (i.e., an active component) that

coordinates all other components Ø It investigates the state of the repository. If an event has occured by entering

something in the repository (modify), components are fired/triggered to work on

• r modify the repository
• Prof. U. Aßmann

37

C1 C3 C2 C4 Fire/trigger

Rule base Repository (fact base,

• bject base)

modify

Softwaretechnologie II

JBOSS ECA Rule Engine for ECA Blackboard Style

Ø Drools (.drl-files) is an active repository with ECA rule processing Ø

• Ex. Fire Alarm Rules [JRules]:
• Prof. U. Aßmann

38

rule "Status output when things are ok" when not Alarm() not Sprinkler( on == true ) then System.out.println( "Everything is ok" ); end rule "Raise the alarm when we have one or more fires" when exists Fire() // tests whether a Fire object exists then insert( new Alarm() ); System.out.println( "Raise the alarm" ); end

Softwaretechnologie II

• Ex. Fire Alarm

Ø Create a blackboard and fill the object base

• Prof. U. Aßmann

39

// make a new blackboard KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder(); // add a .drl-file to the rule base kbuilder.add( ResourceFactory.newClassPathResource( "fireAlarm.drl", getClass() ), ResourceType.DRL ); if ( kbuilder.hasErrors() ) System.err.println( kbuilder.getErrors().toString() ); // open a session with the blackboard StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession(); // allocate objects in the object/fact base String[] names = new String[]{"kitchen","bedroom","office","livingroom"}; Map<String,Room> name2room = new HashMap<String,Room>(); for( String name: names ) { Room room = new Room( name ); name2room.put( name, room ); ksession.insert( room ); Sprinkler sprinkler = new Sprinkler( room ); ksession.insert( sprinkler ); } ksession.fireAllRules(); // output>> ”Everything is ok”

Softwaretechnologie II

• Ex. Fire Alarm (ctd.)

Ø Raise fire by inserting a Fire object into the object base

• Prof. U. Aßmann

40

Fire kitchenFire = new Fire( name2room.get( "kitchen" ) ); Fire officeFire = new Fire( name2room.get( "office" ) ); // insert into the session FactHandle kitchenFireHandle = ksession.insert( kitchenFire ); FactHandle officeFireHandle = ksession.insert( officeFire ); // investigate: ksession.fireAllRules(); // output>> “Raise the alarm"

Softwaretechnologie II

Other Application Areas

Ø Event-based Web systems (AJAX systems)

• Scripts in Javascript react on user-triggered events on the client side
• Server actions are called

Ø Interactive Systems

• Event-reaction tables record event-condition-action rules

Ø Complex event processing in clouds and embedded systems

• Prof. U. Aßmann

41

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

24.5 EXTENSIBILITY OF ECA RULES

• Prof. U. Aßmann

42

Softwaretechnologie II

Extensibility of ECA Rule Systems

Ø Extensibility means to add more ECA rules Ø Rules are open constructs Ø Problem: new rules should be conflict-free with the old rules Ø Harmless extension is usually not provable Ø In general, contracts of the old system cannot be retained

• Prof. U. Aßmann

43

ECA-Systems are extensible, but harmlessness of extensions are hard to prove

Softwaretechnologie II

What Have We Learned

►

Decision analysis (Condition-Action analysis) is an important analysis

■

to describe requirements,

■

to describe complex behavior of a procedure

■

Decision analysis must be encoded in a decision algebra

►

Boolean functions, decision trees, relations, graphs, automata can be encoded in OBDD

►

The control-flow of a procedure can be normalized with a BDD and OBDD

►

Conditions in large state spaces can be encoded in OBDD and efficiently checked

►

ECA-based design reacts on events and conditions with actions

• Prof. U. Aßmann

44

Softwaretechnologie II

The End

Ø Explain the difference of decision trees, tables, BDD and OBDD. Ø Why is a BDD an „optimized“ decision tree? Ø Explain how to ecnode a subset of a finite set with a BDD Ø Explain how to encode a relation over two finite sets with a BDD Ø How would you reengineer a program with a wild, spaghetti-like control flow structure?

• Prof. U. Aßmann

45