Date post: | 04-Dec-2023 |
Category: |
Documents |
Upload: | independent |
View: | 0 times |
Download: | 0 times |
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
AgendaContext-oriented
programming
context-oriented
programming
context-aware
systems
contexts definition
Monday 25 June 12
2
AgendaContext-oriented
programmingBehavior
consistency
context-oriented
programming
consistency
requirements
context-aware
systems
contexts definition sources of
inconsistency
Monday 25 June 12
2
AgendaContext-oriented
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
AgendaContext-oriented
programmingBehavior
consistencyContext Petri Nets Wrap-up
context-oriented
programming
consistency
requirements
context Petri Nets
context-aware
systems
contexts definition
dependency relations
sources of
inconsistency
conclusion and future
work
Monday 25 June 12
2
AgendaContext-oriented
programmingBehavior
consistencyContext Petri Nets Wrap-up
context-oriented
programming
consistency
requirements
context Petri Nets
context-aware
systems
contexts definition
dependency relations
sources of
inconsistency
conclusion and future
work
Monday 25 June 12
E
context-aware systems3
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
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
contexts definition4
computationally accessible information
no semantics
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
contexts definition4
computationally accessible information
no semantics
Battery level = 220 mAh
Idle cycles = 11 MHz
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
context-oriented programming5
ContextsFirst-class entities of the program
Connectivity WiFi Edge VideoCall HighBattery LowBattery
Monday 25 June 12
context-oriented programming5
Context-dependent behaviorSpecific behavior associated to a context
@contexts VideoCall-‐ (void) setupCall:(Call) c { [c enableVideo]; @resend();}
VideoCall
ContextsFirst-class entities of the program
Connectivity WiFi Edge VideoCall HighBattery LowBattery
Monday 25 June 12
context-oriented programming5
Context-dependent behaviorSpecific behavior associated to a context
@contexts VideoCall-‐ (void) setupCall:(Call) c { [c enableVideo]; @resend();}
VideoCall
ContextsFirst-class entities of the program
Connectivity WiFi Edge VideoCall HighBattery LowBattery
Context activation/deactivation@activate(WiFi)@deactivate(WiFi)
Monday 25 June 12
sources of inconsistency6
context functionality
Epaying connection
Fast connection
Block network connection
Location based services
Monday 25 June 12
sources of inconsistency6
context functionality
Epaying connection
Fast connection
Block network connection
Location based services
Monday 25 June 12
sources of inconsistency6
context functionality
Epaying connection
Fast connection
Block network connection
Location based services
Monday 25 June 12
sources of inconsistency6
context functionality
Epaying connection
Fast connection
Block network connection
Monday 25 June 12
7consistency requirements
activation module
behavior module
sensor networkmodule network
devices connection protocols
Monday 25 June 12
7consistency requirements
@activate(VideoCall)activation module
behavior module
sensor networkmodule
@contexts VideoCall-‐ (void) setupCall:(Call) c { [c enableVideo]; @resend();}
networkdevices connection
protocols
Monday 25 June 12
7consistency requirements
@activate(VideoCall)activation module
behavior module
sensor networkmodule
@deactivate(VideoCall)
networkdevices connection
protocols
Monday 25 June 12
7consistency requirements
@activate(VideoCall)activation module
behavior module
sensor networkmodule
@deactivate(VideoCall)
network
1. Multiplicity of context-dependent behavior II. Dynamicity of context information
devices connection protocols
Monday 25 June 12
8context Petri nets (CoPN)
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
Monday 25 June 12
8context Petri nets (CoPN)
@context(WiFi)
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
Monday 25 June 12
8context Petri nets (CoPN)
@context(WiFi)
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
(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
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
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
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
- 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
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
Monday 25 June 12
10CoPN
@context(WiFi, 3)
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W3
Monday 25 June 12
10CoPN
@context(WiFi, 3)
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
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
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
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
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
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
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
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
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
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
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
Inconsistency
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
context definition runtime verificationconsistency management
Runtime model for context-oriented systems
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
Consistent
Monday 25 June 12
[SLE‘2010]
dependency relations - exclusion12
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: ]
dependency relations - exclusion12
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: ]
dependency relations - exclusion12
LowBatteryHighBattery
HPr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
@activate(HighBattery)
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]
{req.A, act.A}
[ContextManager andExclusionBetween: and: ]
dependency relations - exclusion12
LowBatteryHighBattery
HPr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
@activate(HighBattery)
Log:
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]
{req.A, act.A}
[ContextManager andExclusionBetween: and: ]
dependency relations - exclusion12
LowBatteryHighBattery
HPr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
@activate(HighBattery) | @activate(LowBattery)
Log:
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]
{req.A, act.A}
[ContextManager andExclusionBetween: and: ]
dependency relations - exclusion12
LowBatteryHighBattery
HPr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
@activate(HighBattery) | @activate(LowBattery)
Log:
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]
{req.A, act.A}
[ContextManager andExclusionBetween: and: ]
dependency relations - exclusion12
LowBatteryHighBattery
HPr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
@activate(HighBattery) | @activate(LowBattery)
Log:
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]
{req.A, act.A}
[ContextManager andExclusionBetween: and: ]
dependency relations - exclusion12
LowBatteryHighBattery
HPr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
@activate(HighBattery) | @activate(LowBattery)
Log:
Lreq.L act.L
Pr.¬L ¬L
deac.L cl.¬Lreq.¬L
Pr.L
Monday 25 June 12
dependency relations - weak inclusion13
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
dependency relations - weak inclusion13
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
deac.C
[ContextManager addWeakInclusionFrom: to: ]VideoCallConnectivity
[SLE‘2010]
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
Monday 25 June 12
dependency relations - weak inclusion13
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
deac.C
[ContextManager addWeakInclusionFrom: to: ]VideoCallConnectivity
@activate(Connectivity)
Log:
[SLE‘2010]
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
Monday 25 June 12
dependency relations - weak inclusion13
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
deac.C
[ContextManager addWeakInclusionFrom: to: ]VideoCallConnectivity
@activate(Connectivity)
Log:
[SLE‘2010]
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
Monday 25 June 12
dependency relations - weak inclusion13
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
deac.C
[ContextManager addWeakInclusionFrom: to: ]VideoCallConnectivity
@activate(Connectivity)
{req.C, act.C, act.V}Log:
[SLE‘2010]
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
Monday 25 June 12
dependency relations - weak inclusion13
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
deac.C
[ContextManager addWeakInclusionFrom: to: ]VideoCallConnectivity
@activate(Connectivity) | @deactivate(Connectivity)
{req.C, act.C, act.V}Log:
[SLE‘2010]
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
Monday 25 June 12
dependency relations - weak inclusion13
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
deac.C
[ContextManager addWeakInclusionFrom: to: ]VideoCallConnectivity
@activate(Connectivity) | @deactivate(Connectivity)
{req.C, act.C, act.V}Log:
[SLE‘2010]
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
Monday 25 June 12
dependency relations - weak inclusion13
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
deac.C
[ContextManager addWeakInclusionFrom: to: ]VideoCallConnectivity
@activate(Connectivity) | @deactivate(Connectivity)
{req.C, act.C, act.V}Log:
[SLE‘2010]
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
Monday 25 June 12
dependency relations - weak inclusion13
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
deac.C
[ContextManager addWeakInclusionFrom: to: ]VideoCallConnectivity
@activate(Connectivity) | @deactivate(Connectivity)
{req.C, act.C, act.V}Log:{req.¬C, deac.C, deac.V, cl.¬C, cl.¬V}
[SLE‘2010]
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
Monday 25 June 12
dependency relations - strong inclusion14
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
Creq.C act.C
Pr.¬C ¬C
deac.C cl.¬Creq.¬C
Pr.C
ConnectivityWiFi
[SLE‘2010]
Monday 25 June 12
dependency relations - strong inclusion14
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
Creq.C act.C
Pr.¬C ¬C
deac.C cl.¬Creq.¬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
dependency relations - strong inclusion14
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
Creq.C act.C
Pr.¬C ¬C
deac.C cl.¬Creq.¬C
Pr.C
deac.C
[ContextManager addStrongInclusionFrom: to: ]ConnectivityWiFi
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
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
dependency relations - strong inclusion14
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
Creq.C act.C
Pr.¬C ¬C
deac.C cl.¬Creq.¬C
Pr.C
deac.C
[ContextManager addStrongInclusionFrom: to: ]ConnectivityWiFi
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
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
dependency relations - strong inclusion14
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
Creq.C act.C
Pr.¬C ¬C
deac.C cl.¬Creq.¬C
Pr.C
deac.C
[ContextManager addStrongInclusionFrom: to: ]ConnectivityWiFi
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
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
dependency relations - strong inclusion14
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
Creq.C act.C
Pr.¬C ¬C
deac.C cl.¬Creq.¬C
Pr.C
deac.C
[ContextManager addStrongInclusionFrom: to: ]ConnectivityWiFi
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
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
dependency relations - strong inclusion14
WPr.W Pr.¬W ¬W
req.W act.W deac.W cl.¬Wreq.¬W
Creq.C act.C
Pr.¬C ¬C
deac.C cl.¬Creq.¬C
Pr.C
deac.C
[ContextManager addStrongInclusionFrom: to: ]ConnectivityWiFi
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
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
[SLE‘2010]
15dependency relations - requirement
Log:
H
V
Pr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
req.V act.V
Pr.¬V ¬V
deac.V cl.¬Vreq.¬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
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
[SLE‘2010]
15dependency relations - requirement
Log:
H
V
Pr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
req.V act.V
Pr.¬V ¬V
deac.V cl.¬Vreq.¬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
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
[SLE‘2010]
15dependency relations - requirement
@activate(V)
Log:
H
V
Pr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
req.V act.V
Pr.¬V ¬V
deac.V cl.¬Vreq.¬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
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
[SLE‘2010]
15dependency relations - requirement
@activate(V) |@activate(H)
Log: {req.H, act.H}
H
V
Pr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
req.V act.V
Pr.¬V ¬V
deac.V cl.¬Vreq.¬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
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
[SLE‘2010]
15dependency relations - requirement
@activate(V) |@activate(H)
Log: {req.H, act.H}
| @activate(V)
{req.V, act.V}
H
V
Pr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
req.V act.V
Pr.¬V ¬V
deac.V cl.¬Vreq.¬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
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
[SLE‘2010]
15dependency relations - requirement
@activate(V) |@activate(H)
Log: {req.H, act.H}
| @activate(V) | @deactivate(H)
{req.V, act.V}
H
V
Pr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
req.V act.V
Pr.¬V ¬V
deac.V cl.¬Vreq.¬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
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
[SLE‘2010]
15dependency relations - requirement
@activate(V) |@activate(H)
Log: {req.H, act.H}
| @activate(V) | @deactivate(H)
{req.V, act.V}
H
V
Pr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
req.V act.V
Pr.¬V ¬V
deac.V cl.¬Vreq.¬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
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
[SLE‘2010]
15dependency relations - requirement
@activate(V) |@activate(H)
Log: {req.H, act.H}
| @activate(V) | @deactivate(H)
{req.V, act.V}
H
V
Pr.H Pr.¬H ¬H
req.H act.H deac.H cl.¬Hreq.¬H
req.V act.V
Pr.¬V ¬V
deac.V cl.¬Vreq.¬V
Pr.V
deac.Hdeac.V
{req.¬H, deac.H, deac.V, cl.¬H}
[ContextManager addRequirementOf: from: ]VideoCallHighBattery
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