Mapping Context-Dependent Requirements to Event-Based Context-Oriented Programs for Modularity Tetsuo Kamina (UTokyo) Tomoyuki Aotani (Tokyo Tech) Hidehiko Masuhara (Tokyo Tech)
Purpose Methodology for context-aware systems from requirements to implementation Context-dependent behavior well-studied in implementation identification of contexts and behavioral variations is not trivial Requirements model and systematic implementation using event-based COP language EventCJ
Context-awareness Capability of a system to behave w.r.t. surrounding contexts (outdoors, indoors) Multiple parts of behavior simultaneously change at runtime Map:City map,Floor plan Positioning:GPS, RFID
Context-awareness Capability of a system to behave w.r.t. surrounding contexts (outdoors, indoors) Multiple parts of behavior simultaneously change at runtime Map:City map,Floor plan Positioning:GPS, RFID Outdoors
Context-awareness Capability of a system to behave w.r.t. surrounding contexts (outdoors, indoors) Multiple parts of behavior simultaneously change at runtime Map:City map,Floor plan Positioning:GPS, RFID Indoors
modularization of context dep. behavior: layer Display Positioning Display Positioning Display disciplined activation of layers Positioning (COP) [Hirschfeld08] Context-Oriented Programming Layer display() getPos() Outdoors call display() display() getPos() call getPos() Indoors display() getPos()
modularization of context dep. behavior: layer Positioning override Positioning Display Positioning Display disciplined activation of layers Layer Display (COP) [Hirschfeld08] Context-Oriented Programming with(Outdoors) { ... display() getPos() } Outdoors call display() display() getPos() call getPos() Indoors display() getPos()
modularization of context dep. behavior: layer Positioning override Positioning Display Positioning Display disciplined activation of layers Layer Display (COP) [Hirschfeld08] Context-Oriented Programming with(Indoors) { ... display() getPos() } Outdoors call display() display() getPos() call getPos() Indoors display() getPos()
We need to identify: Variations of behavior that should be implemented using a layer Context that changes behavior A layer assumes a context Timing when contexts/layers change Outdoors is active when the situation is outdoors Layer Context
We need to identify: Variations of behavior that should be implemented using a layer Context that changes behavior A layer assumes a context Timing when contexts/layers change Outdoors is active when the situation is outdoors Layer Context Do we really know them?
Questions When to use layers? modularity What are contexts? Can a layer always assume only one single context? How relations b/w contexts and layers are defined? How can precisely specify when context changes? the ways (layers, design patterns, if ) affect
Questions When to use layers? modularity What are contexts? Can a layer always assume only one single context? How relations b/w contexts and layers are defined? How can precisely specify when context changes? the ways (layers, design patterns, if ) affect Methodology is required
Overview of methodology city map when GPS value outdoors indoors Layer outdoors ... outdoors ... outdoors indoors Identifying contexts and context- outdoors use cases context-dependent contexts behavior description of changes Identifying events that trigger context Identifying layers by grouping use cases dependent use cases becomes ...
Pedestrian Navigation System: Example use cases • If the user is outdoors, it displays a city map using GPS based positioning • If the user is indoors, it displays a floor plan using Wi-Fi based positioning • If the floor plan is not available, it displays a city map • If no positioning is available, it displays a static map and showing an alert message
Identifying contexts We identify contexts from behavior Documents describing system-to-be (e.g. use cases) Prototypes Conditions are candidates for contexts • If the use is outdoors, the system displays a city map • If the use is indoors, the system displays a floor plan • If the floor plan is not available, the system displays a city map • If no positioning is available, the system displays a static map ※conditions affecting a number of parts (e.g., external environmental conditions)
Identifying contexts We identify contexts from behavior Documents describing system-to-be (e.g. use cases) Prototypes Conditions are candidates for contexts • If the use is outdoors, the system displays a city map • If the use is indoors, the system displays a floor plan • If the floor plan is not available, the system displays a city map • If no positioning is available, the system displays a static map candidates ※conditions affecting a number of parts (e.g., external environmental conditions)
Defining contexts We define a context in terms of variables outdoors/indoors situations are merged A context is a specific setting of value to a variable (a Boolean term) name value situation outdoors, indoors floorPlan available, unavailable positioning available, unavailable e.g. situation=outdoors
Context-dependent use cases static map positioning=unavailable alert showing positioning=unavailable floorPlan=available situation=indoors ∨ floorPlan=unavailable situation=outdoors ∨ using a Defining context-dependent use cases floor plan using a map using a city using a map Annotated with proposition of contexts specific contexts a specialization of use case applicable in <<include>>
Identifying layers static map positioning=unavailable alert showing positioning=unavailable floorPlan=available situation=indoors ∨ floorPlan=unavailable situation=outdoors ∨ using a Layer: a set of use cases with the same floor plan using a map using a city using a map (cf. Jacobson, 2005) objects may also be identified as a layer * a use case scattering over multiple proposition <<include>>
Identifying layers using a positioning=unavailable alert showing positioning=unavailable floorPlan=available situation=indoors ∨ floorPlan=unavailable situation=outdoors ∨ static map floor plan Layer: a set of use cases with the same using a map using a city using a map layer (cf. Jacobson, 2005) objects may also be identified as a layer * a use case scattering over multiple proposition <<include>>
To identify events... We need to decompose context into more specific states of the machine (sensors) State changes are identified as events Contexts are abstract in use cases
Decomposing contexts GPS=under the criterion value GPS=on or Wi-Fi=connected positioning=available The floor plan service does not exist floorPlan=unavailable The floor plan service exists floorPlan=available situation=indoors Detailed specification consists of sensors GPS=over the criterion value situation=outdoors detailed context specification context Some contexts depend on multiple sensors (GPS, Wi-Fi) and external entities (floor plan) positioning=unavailable GPS=off and Wi-Fi=disconnected
Identifying events GPSEvent → Wi-Fi=connected the Wi-Fi device is Wi-Fi=disconnected WifiEvent becoming on the GPS device is GPS=off → GPS=on becomes over XXX Specifying how/when the status of detailed → GPS=over the criterion the GPS signal value StrongGPS GPS=under the criterion when how event context specification changes connected ...
We have obtained so far..
We have obtained so far.. using a city map layers/context-dep. use cases representing context-dep. behavior
We have obtained so far.. situation=outdoors floorPlan=unavailable using a city map OR layers/context-dep. use cases representing context-dep. behavior context changing layer activation
We have obtained so far.. situation=outdoors floorPlan=unavailable GPS=over criterion event: StrongGPS using a city map GPS=under criterion OR layers/context-dep. use cases representing context-dep. behavior context changing layer activation events changing contexts
Translating to implementation situation=outdoors floorPlan=unavailable GPS=over criterion event: StrongGPS using a city map GPS=under criterion OR Translating specifications to corresponding constructs in EventCJ [Kamina11]
Translating to implementation situation=outdoors contexts are encoded layers are directly mapped constructs in EventCJ [Kamina11] Translating specifications to corresponding OR GPS=under criterion map using a city event: StrongGPS GPS=over criterion floorPlan=unavailable in composite layers layer CityMap when Outdoors || !FPExists { .. }
Translating to implementation Translating specifications to corresponding events are encoded in in composite layers contexts are encoded layers are directly mapped situation=outdoors constructs in EventCJ [Kamina11] layer transition rules OR GPS=under criterion map using a city event: StrongGPS GPS=over criterion floorPlan=unavailable layer CityMap when Outdoors || !FPExists { .. } event GPSEvent ... transition StrongGPS: !Outdoors ? -> Outdoors;
Recommend
More recommend