Context petri nets: Enabling consistent composition of context-dependent behavior

Université catholique de Louvain

Vrije Universiteit Brussel2

1

Context Petri Nets:Enabling consistent composition of context-dependent behavior

1

25-VI-2012

6th Workshop on Petri Nets and Software Engineering (PNSE) 2012

Nicolás Cardozo, Jorge Vallejos, Sebastián González, Kim Mens, Theo D’Hondt2

1,2

1 1

2

Monday 25 June 12

2

Agenda

Monday 25 June 12

2

AgendaContext-oriented

programming

context-oriented

programming

context-aware

systems

contexts definition

Monday 25 June 12

2


programmingBehavior

consistency

context-oriented

programming

consistency

requirements

context-aware

systems

contexts definition sources of

inconsistency

Monday 25 June 12

2


programmingBehavior

consistencyContext Petri Nets

context-oriented

programming

consistency

requirements

context Petri Nets

context-aware

systems

contexts definition

dependency relations

sources of

inconsistency

Monday 25 June 12

2


programmingBehavior

consistencyContext Petri Nets Wrap-up

context-oriented

programming

consistency

requirements

context Petri Nets

context-aware

systems

contexts definition


sources of

inconsistency

conclusion and future

work

Monday 25 June 12

2


programmingBehavior

consistencyContext Petri Nets Wrap-up

context-oriented

programming

consistency

requirements

context Petri Nets

context-aware

systems

contexts definition


sources of

inconsistency

conclusion and future

work

Monday 25 June 12

3

Monday 25 June 12

context-aware systems3

Monday 25 June 12

E


Monday 25 June 12

E


disallow multiple connections when battery is low

internal state

user configurationonly allow to call when connected to a WiFi network

phone-to-phone information exchangepeer service

use internet based location mechanismslocation semantics

E

Internet Video Calling

Monday 25 June 12

4

Monday 25 June 12

contexts definition4

computationally accessible information

Battery level = 220 mAh

Idle cycles = 11 MHz

Position = 50°51′0″N 4°21′0″E

Z axis = 0.03

Monday 25 June 12

http://toolserver.org/~geohack/geohack.php?pagename=Eindhoven_University_of_Technology&params=51_26_53_N_5_29_23_E_region:NL_type:edu




no semantics



Position = 50°51′0″N 4°21′0″E

Z axis = 0.03

Monday 25 June 12





no semantics



Position = 50°51′0″N 4°21′0″E

Z axis = 0.03

Low battery charge

High CPU load

actions can be taken

Brussels

Landscape orientation

Monday 25 June 12



5

Monday 25 June 12

context-oriented programming5

Monday 25 June 12


ContextsFirst-class entities of the program

Connectivity WiFi Edge VideoCall HighBattery LowBattery

Monday 25 June 12


Context-dependent behaviorSpecific behavior associated to a context

@contexts VideoCall-‐ (void) setupCall:(Call) c { [c enableVideo]; @resend();}

VideoCall



Monday 25 June 12


Context-dependent behaviorSpecific behavior associated to a context


VideoCall



Context activation/deactivation@activate(WiFi)@deactivate(WiFi)

Monday 25 June 12

6

Monday 25 June 12

sources of inconsistency6

context functionality

Epaying connection

Fast connection

Block network connection

Location based services

Monday 25 June 12



Epaying connection

Fast connection



Monday 25 June 12



Epaying connection

Fast connection



Monday 25 June 12



Epaying connection

Fast connection


Monday 25 June 12

7

Monday 25 June 12

7consistency requirements

activation module

behavior module

sensor networkmodule

Monday 25 June 12


activation module

behavior module

sensor networkmodule network

devices connection protocols

Monday 25 June 12


@activate(VideoCall)activation module

behavior module



networkdevices connection

protocols

Monday 25 June 12



behavior module


@deactivate(VideoCall)

networkdevices connection

protocols

Monday 25 June 12



behavior module


@deactivate(VideoCall)

network

1. Multiplicity of context-dependent behavior II. Dynamicity of context information

devices connection protocols

Monday 25 June 12

8

Monday 25 June 12

8context Petri nets (CoPN)

context definition runtime verificationconsistency management

Runtime model for context-oriented systems

Monday 25 June 12


@context(WiFi)



Monday 25 June 12


@context(WiFi)



(1) P =< P, T, f, f�, ⇢,m0 > (5) f : (P ⇥ T ) [ (T ⇥ P ) �! Z+

(2) P \ T = � (6) f� : P ⇥ T �! {0, 1}(3) P = Pc [ Pt (7) ⇢ : T �! Z+

(4) T = Te [ Ti [ Tc (8) m0 : P �! Z+

Table 1: Context Petri nets components definition.

of transitions is divided into three disjoints sets: Te

of external transitions, Ti

ofinternal transitions and T

c

of internal cleaning transitions (4). There cannot bearcs between two places or two transitions. Each arc defines how many tokensflow from, or to places (5). There can be maximum one inhibitor arc between aplace and a transition (6). Transitions are given a firing order priority. Higherpriority transitions fire before lower priority ones (7). Enabled transitions of thesame priority fire randomly. Finally, tokens are assigned to places by means ofthe (initial) marking function (8).

An explanation of the mapping between Petri nets and COP concepts follows.As illustration, Fig. 1 shows how the VideoCall context from the example inSection 2 can be defined as a CoPN.

Pr.V

req(V)

0

act(V)

2V

req(¬V)

0Pr.¬V

deac(V)

2¬V

cl(¬V)

1

Fig. 1: CoPN representation of the VideoCall (V) context.

Places in CoPNs are used to capture the state of contexts. A context is definedin terms of four places defining the context’s life cycle. A context place, P

c

, (solid-line circle labeled VideoCall in Fig. 1) is used to represent the actual contextand its activation state. The other three temporary places, P

t

, (dashed circlesin Fig. 1) are used to represent intermediate states of the context: preparingfor activation (Pr.VideoCall), preparing for deactivation (Pr.¬VideoCall), andflagged as already deactivated (¬VideoCall).Temporary places help to maintain consistency constraints when manipulatingthe activation state of contexts. Activation and deactivation of a context doesnot occur immediately, but needs to be requested first and processed carefully,since the request may be denied if it violates constraints imposed by other con-texts. The flag temporary place (¬VideoCall in Fig. 1) is used to ensure that acontext is effectively deactivated once for every deactivation request (otherwise,the context would be emptied of all its tokens after just a single deactivation).Transitions in CoPNs represent changes in the activation state of contexts.Transitions are divided in two categories: external and internal. External transi-

tions (white squares in Fig. 1) are used to request a context activation or deac-tivation in response to a change detected in the execution environment. Internal

transitions (black squares in Fig. 1) forward the requests to other dependentcontexts, and trigger the actual activation or deactivation of contexts. Finally, aparticular kind of internal transition internal cleaning transitions (gray squarein Fig. 1) is used to clean the deactivation flag place.Transition priorities are shown as small numbers under each transition in Fig. 1.External transitions are white transitions of priority 0. Internal transitions are

WPr.W Pr.¬W ¬W

req.W act.W deac.W cl.Wreq.¬W

0 02 2 1

Monday 25 June 12

9CoPN

WPr.W Pr.¬W ¬W

req.W act.W deac.W cl.¬Wreq.¬W

temporary place

context place

activationstate

externaltransition

cleaningtransition

internaltransition

arcs

inhibitorarcs



Monday 25 June 12

9CoPN

WPr.W Pr.¬W ¬W


temporary place

context place

activationstate

externaltransition

cleaningtransition

internaltransition

arcs

inhibitorarcs



- Context-dependent behavior is available from context places- Inhibitor arcs test the activation state of contexts- External transitions fire in response to external events- Internal transitions fire automatically - Cleaning transitions fire automatically after internal transitions

[Reactive Petri nets,2003]

[On the analysis of Petri nets with static priorities,1996]

[Petri net semantics of priority systems,2003]

Monday 25 June 12

10CoPN



WPr.W Pr.¬W ¬W


Monday 25 June 12

10CoPN

@context(WiFi, 3)



WPr.W Pr.¬W ¬W

req.W act.W deac.W cl.¬Wreq.¬W3

Monday 25 June 12

10CoPN

@context(WiFi, 3)



WPr.W Pr.¬W ¬W

req.W act.W deac.W cl.¬Wreq.¬W3

@activate(WiFi)

Monday 25 June 12

Definition A context Petri net is said to be in a consistent state if none of the temporary places are marked after all internal transitions have fired

11CoPN



Monday 25 June 12


11CoPN



WPr.W Pr.¬W ¬W


Monday 25 June 12


11CoPN



WPr.W Pr.¬W ¬W


Monday 25 June 12


11CoPN



WPr.W Pr.¬W ¬W


Monday 25 June 12


11CoPN



WPr.W Pr.¬W ¬W


Inconsistency

Monday 25 June 12


11CoPN



WPr.W Pr.¬W ¬W


Consistent

Monday 25 June 12

[SLE‘2010]

12

Monday 25 June 12

[SLE‘2010]

dependency relations - exclusion12

Monday 25 June 12

[SLE‘2010]


LowBatteryHighBattery

HPr.H Pr.¬H ¬H

req.H act.H deac.H cl.¬Hreq.¬H

Lreq.L act.L

Pr.¬L ¬L

deac.L cl.¬Lreq.¬L

Pr.L

Monday 25 June 12

4.2 CoPN Dependency RelationsIn a COP system, contexts can depend on each other. That

is, a context (de)activation can take place, or be forbidden, asa consequence of the (de)activation of other contexts. Suchinteractions are called context dependency relations.

Taking advantage of the fine grained definition of contextpreviously given, dependency relations can be defined interms of CoPNs. Dependency relations are defined as a setof constraints between two contexts. Such constraints areexpressed as clauses that must be satisfied by the CoPN.

Definition 3 (Relation constraints). A constraint on aCoPN P =< P,T, f , f�,⇢,m0 > is defined as a clause of the form:

Q t 2 T such that B1(t) : B2(t)

where Q is a quantifier over the transitions T, B1 is a condition oversuch transitions and B2 is a condition over the flow functions f orf� that must follow whenever condition B1 holds.

Take as example the following clauses used to describepart of the CoPN in Figure 5: 8t 2 T then • t , � _ t• , �(all transitions have predecessors or successors) and 9t 2T such that t• = � (There is a transition that has no succes-sors).

Definition 4 (Dependency relation). Given two contextsC1,C2 2 S, a dependency relation R(C1,C2) between the two con-texts, is defined as a CoPN P where C1,C2 2 P and P satisfies allconstraints in the set CR of constraints for the relation. The set ofdependency relations is denoted as R.

Definition 5 (Satisfiability). We say that a CoPNP satis-fies a set of constraints C , denoted as P |= C , if and only if 8c 2 Cthe transitions t in P validate the constraint.

Satisfiability in CoPN is verified programmatically by go-ing over all c 2 C and verifying if the constraint is valid forthe transitions in the Petri net. As it will be seen in Section 4.4,this process takes place every time contexts are added to thesystem by means of composition.

Currently, CoPN supports 4 dependency relations: exclu-sion, weak inclusion, strong inclusion and requirement [14], how-ever, other relations could be defined in a similar fashion. Inthe following definitions the constraints can be visually iden-tified by the arcs going from one context to another, and thetransitions that lie in between them. The definition for eachof the dependency relations in CoPN is presented by givingthe intuition of the interaction between the contexts, the setC of constraints that must be fulfilled and the correspondingCoPN visual representation.

The visual representation given in the following definitionscontains double arcs. These are not a new kind of Petri netelement, they are just a visual synthesis to make the modelless cluttered. A double arc between a place p and a transitiont is the synthesis of the arcs (p, t) and (t, p) in f .

Each dependency relation is presented with an intuitiveexample showing when such dependency relation could beused, and the way the contexts interact when they are acti-vated. Dependency relations between two contexts are usu-ally defined based on the domain information of the appli-cation. Their interaction whenever a context is activated ordeactivated in CoPN (i.e. the flow of tokens), is explainedin Section 4.3.

For the following definitions we assume two contextsCA =< PA,TA, fA, f�A,⇢A,m0A >,CB =< PB,TB, fB, f�B,⇢B,m0B >.The CoPN defined by each of the dependency relations is ofthe form P =< P,T, f , f�,⇢,m0 >.

Definition 6 (Exclusion A ⇤–⇤ B). An exclusion depen-dency represents a restriction where two contexts cannot be activeat the same time. However, both contexts may be simultaneouslyinactive. The conditions that must be satisfied by an exclusion are:

CE : 8t 2 T such that A 2 t • then (B, t) 2 f�8t 2 T such that B 2 t • then (A, t) 2 f�

Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb

req(¬Hb)Pr.¬Hb deac(Hb) ¬Hb cl(¬Hb)

Figure 6: Exclusion dependency between the HighBattery(Hb) and LowBattery (Lb) contexts, Lb⇤–⇤ Hb

Exclusion dependency relations are used, for example, forsituations that cannot occur at the same time in the real world.An application running on a mobile device can present dif-ferent behavior according to the battery level of the device.Clearly, the battery level of the device cannot be high and lowat the same time, so an exclusion dependency relation couldbe defined between the contextsLowBatteryandHighBatteryas in Figure 6. The consequence of such relation, is that thechange between the LowBattery and HighBattery contextsmust occur by first deactivating the currently active contextand then activating the other one.

Definition 7 (Weak inclusion A–⇤B). A weak inclusionrepresents a situation in which the activation (deactivation) of thesource context A automatically triggers the activation (deactivation)of the target context B. However, the dependency is weak in thesense that the target context B can still be activated or deactivatedindependently of the source context A. The conditions that must besatisfied by a weak inclusion are:

CW : 9t 2 T such that A,Pr.¬A 2 •t and (B, t) 2 f�8t 2 T such that A 2 t • and A < •t then (t,Pr.B) 2 f8t 2 T such that A 2 •t and (B, t) < f� then (t,Pr.¬B) 2 f8t 2 T such that A 2 •t and (B, t) < f�

then (B, t), (t,B) 2 f

Weak inclusion dependency relations are commonly used,for example, in situations in which there is an implication be-tween the contexts, however the transposition of the implica-tion is not necessarily true. In a noise sensing application, forexample, the microphone reception can be adapted according

[SLE‘2010]

[ContextManager andExclusionBetween: and: ]



HPr.H Pr.¬H ¬H


Lreq.L act.L

Pr.¬L ¬L


Pr.L

Monday 25 June 12

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








[SLE‘2010]




HPr.H Pr.¬H ¬H


@activate(HighBattery)

Lreq.L act.L

Pr.¬L ¬L


Pr.L

Monday 25 June 12

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








[SLE‘2010]

{req.A, act.A}




HPr.H Pr.¬H ¬H


@activate(HighBattery)

Log:

Lreq.L act.L

Pr.¬L ¬L


Pr.L

Monday 25 June 12

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








[SLE‘2010]

{req.A, act.A}




HPr.H Pr.¬H ¬H


@activate(HighBattery) | @activate(LowBattery)

Log:

Lreq.L act.L

Pr.¬L ¬L


Pr.L

Monday 25 June 12

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








[SLE‘2010]

{req.A, act.A}




HPr.H Pr.¬H ¬H



Log:

Lreq.L act.L

Pr.¬L ¬L


Pr.L

Monday 25 June 12

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








[SLE‘2010]

{req.A, act.A}




HPr.H Pr.¬H ¬H



Log:

Lreq.L act.L

Pr.¬L ¬L


Pr.L

Monday 25 June 12

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








[SLE‘2010]

{req.A, act.A}




HPr.H Pr.¬H ¬H



Log:

Lreq.L act.L

Pr.¬L ¬L


Pr.L

Monday 25 June 12

dependency relations - weak inclusion13

[SLE‘2010]

Monday 25 June 12


CPr.C Pr.¬C ¬C

req.C act.C deac.C cl.¬Creq.¬C

Vreq.V act.V

Pr.¬V ¬V

deac.V cl.¬Vreq.¬V

Pr.V

VideoCallConnectivity

[SLE‘2010]

Monday 25 June 12


CPr.C Pr.¬C ¬C


Vreq.V act.V

Pr.¬V ¬V


Pr.V

deac.C

[ContextManager addWeakInclusionFrom: to: ]VideoCallConnectivity

[SLE‘2010]

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








Monday 25 June 12


CPr.C Pr.¬C ¬C


Vreq.V act.V

Pr.¬V ¬V


Pr.V

deac.C


@activate(Connectivity)

Log:

[SLE‘2010]

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








Monday 25 June 12


CPr.C Pr.¬C ¬C


Vreq.V act.V

Pr.¬V ¬V


Pr.V

deac.C



Log:

[SLE‘2010]

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








Monday 25 June 12


CPr.C Pr.¬C ¬C


Vreq.V act.V

Pr.¬V ¬V


Pr.V

deac.C



{req.C, act.C, act.V}Log:

[SLE‘2010]

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








Monday 25 June 12


CPr.C Pr.¬C ¬C


Vreq.V act.V

Pr.¬V ¬V


Pr.V

deac.C


@activate(Connectivity) | @deactivate(Connectivity)


[SLE‘2010]

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








Monday 25 June 12


CPr.C Pr.¬C ¬C


Vreq.V act.V

Pr.¬V ¬V


Pr.V

deac.C




[SLE‘2010]

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








Monday 25 June 12


CPr.C Pr.¬C ¬C


Vreq.V act.V

Pr.¬V ¬V


Pr.V

deac.C




[SLE‘2010]

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








Monday 25 June 12


CPr.C Pr.¬C ¬C


Vreq.V act.V

Pr.¬V ¬V


Pr.V

deac.C



{req.C, act.C, act.V}Log:{req.¬C, deac.C, deac.V, cl.¬C, cl.¬V}

[SLE‘2010]

















Pr.Lb

req(Lb)act(Lb)

act(Hb)

Lb

req(¬Lb)

Pr.¬Lb

deac(Lb)

¬Lb cl(¬Lb)

Pr.Hb

req(Hb) Hb








Monday 25 June 12

dependency relations - strong inclusion14

[SLE‘2010]

Monday 25 June 12


WPr.W Pr.¬W ¬W


Creq.C act.C

Pr.¬C ¬C

deac.C cl.¬Creq.¬C

Pr.C

ConnectivityWiFi

[SLE‘2010]

Monday 25 June 12


WPr.W Pr.¬W ¬W


Creq.C act.C

Pr.¬C ¬C


Pr.C

deac.C

[ContextManager addStrongInclusionFrom: to: ]ConnectivityWiFi

deac.W

deac.C

[SLE‘2010]

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N

req(¬N)Pr.¬N deac(N) ¬N

cl(¬N)

Figure 7: Weak inclusion dependency relation between the

Cafeteria (C) and Noisy (N) contexts, C –⇤N

to the place in which a measurement is being taken. Figure 7shows the assumption that whenever the Cafeteria contextis active, the Noisy context filter should be used. Note that ifthe Noisy context is no longer used, this does not mean thatthe location is no longer the Cafeteria.

Definition 8 (Strong inclusion A–I B). A strong inclu-sion represents that the activation (deactivation) of the source con-text A automatically triggers the activation (deactivation) of thetarget context B. The deactivation of B automatically triggers thedeactivation of A. However, B can still be activated (deactivated) in-dependently of A. The conditions that must be satisfied by a stronginclusion are:CS : 9t 2 T such that (Pr.¬A, t), (t,¬A), (¬A, t) 2 f9t 2 T such that (Pr.B, t), (t,¬B), (¬B, t) 2 f9t 2 T such that B,Pr.¬B 2 •t and (A, t) 2 f�8t 2 T such that ¬A 2 t • and ¬A < •t then (¬A, t) 2 f�8t 2 T such that ¬B 2 t • and ¬B < •t then (¬B, t) 2 f�8t 2 T such that A 2 t • and A < •t then (t,Pr.B) 2 f8t 2 T such that A 2 •t and A < t • then (t,Pr.¬B) 2 f8t 2 T such that B 2 •t and (A, t) < f� then (t,Pr.¬A) 2 f8t 2 T such that B 2 •t and (A, t) < f�

then (A, t), (t,A) 2 f

Strong inclusion dependency relations are commonly used,for example, in situations in which there is a containmentrelation between the contexts in the real world. A localizationapplication can adapt its content based on the region in whichit is being executed. Clearly country regions can reuse thecontent specified for their country. As shown in Figure 8 itis possible to define the Brussels and Belgium contexts. AsBrussels is contained in Belgium, every time we are in theformer context, it can be ensured that the later context is alsovalid. Note that if we are not longer in the later context, wecan assert that we are no longer in the former one.

Definition 9 (Requirement A–⇣B). A requirement repre-sents the situation in which activation of the source context A ispossible only if the target context B is already active. This restric-tion implies that when the target context is deactivated, the sourcecontext must be deactivated too. Even more, if the target context B

Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)

Figure 8: Strong inclusion dependency between the

Brussels (Br) and Belgium (Be) contexts, Br–IBe

is not active, it must be ensured that the source context A is not acti-vated either. The conditions that must be satisfied by a requirementare:CR : 9t 2 T such that B,Pr.¬B 2 •t and (A, t) 2 f�

9t 2 T such that A 2 •t, (B, t) 2 f�8t 2 T such that B 2 •t and (A, t) < f� then (A, t), (t,A) 2 f8t 2 T such that A 2 t • and A < •t then (B, t), (t,B) 2 f

Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V

req(¬V)Pr.¬V deac(V) ¬V

cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)

Figure 9: Requirement dependency relation between the

HDVideo (V) and HighBattery (Hb) contexts, V –⇣Hb

Requirement dependency relations are commonly used, forexample in situations in which one context needs the adap-tations introduced by another context. For example, a videodecoder provider, has codecs to display videos in a high def-inition (HDVideo context). However, the processing of highdefinition videos is power consuming, and so to display such

Monday 25 June 12


WPr.W Pr.¬W ¬W


Creq.C act.C

Pr.¬C ¬C


Pr.C

deac.C


deac.W

deac.C

@activate(WiFi)

[SLE‘2010]

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N


cl(¬N)








Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)





Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V


cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)




Monday 25 June 12


WPr.W Pr.¬W ¬W


Creq.C act.C

Pr.¬C ¬C


Pr.C

deac.C


deac.W

deac.C

@activate(WiFi)

[SLE‘2010]

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N


cl(¬N)








Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)





Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V


cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)




Monday 25 June 12


WPr.W Pr.¬W ¬W


Creq.C act.C

Pr.¬C ¬C


Pr.C

deac.C


deac.W

deac.C

@activate(WiFi) | @deactivate(Connectivity)

[SLE‘2010]

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N


cl(¬N)








Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)





Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V


cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)




Monday 25 June 12


WPr.W Pr.¬W ¬W


Creq.C act.C

Pr.¬C ¬C


Pr.C

deac.C


deac.W

deac.C


[SLE‘2010]

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N


cl(¬N)








Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)





Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V


cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)




Monday 25 June 12


WPr.W Pr.¬W ¬W


Creq.C act.C

Pr.¬C ¬C


Pr.C

deac.C


deac.W

deac.C


[SLE‘2010]

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N


cl(¬N)








Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)





Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V


cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)




Monday 25 June 12

[SLE‘2010]

15dependency relations - requirement

Log:

H

V

Pr.H Pr.¬H ¬H


req.V act.V

Pr.¬V ¬V


Pr.V

VideoCallHighBattery

Monday 25 June 12

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N


cl(¬N)








Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)





Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V


cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)




[SLE‘2010]


Log:

H

V

Pr.H Pr.¬H ¬H


req.V act.V

Pr.¬V ¬V


Pr.V

deac.Hdeac.V

[ContextManager addRequirementOf: from: ]VideoCallHighBattery

Monday 25 June 12

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N


cl(¬N)








Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)





Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V


cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)




[SLE‘2010]


@activate(V)

Log:

H

V

Pr.H Pr.¬H ¬H


req.V act.V

Pr.¬V ¬V


Pr.V

deac.Hdeac.V


Monday 25 June 12

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N


cl(¬N)








Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)





Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V


cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)




[SLE‘2010]


@activate(V) |@activate(H)

Log: {req.H, act.H}

H

V

Pr.H Pr.¬H ¬H


req.V act.V

Pr.¬V ¬V


Pr.V

deac.Hdeac.V


Monday 25 June 12

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N


cl(¬N)








Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)





Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V


cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)




[SLE‘2010]



Log: {req.H, act.H}

| @activate(V)

{req.V, act.V}

H

V

Pr.H Pr.¬H ¬H


req.V act.V

Pr.¬V ¬V


Pr.V

deac.Hdeac.V


Monday 25 June 12

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N


cl(¬N)








Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)





Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V


cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)




[SLE‘2010]



Log: {req.H, act.H}

| @activate(V) | @deactivate(H)

{req.V, act.V}

H

V

Pr.H Pr.¬H ¬H


req.V act.V

Pr.¬V ¬V


Pr.V

deac.Hdeac.V


Monday 25 June 12

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N


cl(¬N)








Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)





Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V


cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)




[SLE‘2010]



Log: {req.H, act.H}


{req.V, act.V}

H

V

Pr.H Pr.¬H ¬H


req.V act.V

Pr.¬V ¬V


Pr.V

deac.Hdeac.V


Monday 25 June 12

Pr.C

req(C)act(C)

deac(C)

C

req(¬C)Pr.¬C

deac(C) ¬Ccl(¬C)

Pr.Nreq(N)

act(N)N


cl(¬N)








Pr.Br

req(Br)act(Br)

deac(Be)

Br

req(¬Br)Pr.¬Br

deac(Br)

¬Brcl(¬Br)

deac(Br)

Pr.Bereq(Be)

act(Be)Be

req(¬Be)Pr.¬Be

deac(Be)

¬Becl(¬Be)

deac(Be)





Pr.V

req(V)act(V)

deac(V)

deac(Hb)

V


cl(¬V)

Pr.Hb

req(Hb)act(Hb)

Hb

req(¬Hb)

Pr.¬Hb deac(Hb)

¬Hb

cl(¬Hb)




[SLE‘2010]



Log: {req.H, act.H}


{req.V, act.V}

H

V

Pr.H Pr.¬H ¬H


req.V act.V

Pr.¬V ¬V


Pr.V

deac.Hdeac.V

{req.¬H, deac.H, deac.V, cl.¬H}


Monday 25 June 12

Wrap-up16

Monday 25 June 12

Wrap-up16

✓ Runtime model to manage context-aware systems✓ Consistent behavior composition assurance ✓ Automatic composition of contexts✓ Semantics definition of context-aware systems✓sound definition of dependency relations

➡ Conflicts between internal transitions➡ Inconsistencies identification➡ Petri Nets analyses (liveness and reachability) ➡ Static analysis

Monday 25 June 12

Questions?

http://released.info.ucl.ac.be/Tools/Context-‐PetriNets

17

Monday 25 June 12

Documents

Context petri nets: Enabling consistent composition of context-dependent behavior