design and validation of a distributed computationenvironment for mobile devices


• Overview of ”SmartSpaces”

• Process

• Architecture

• Validation (Simulation)

• Examples of Validation (Simulation)

• Evaluation of Simulation Runs

• Other Techniques/Tools

• Conclusions


• Mobile device variation on ”Blackboard” architecture

• realised as a computation platform

• highly distributed & concurrent

• applications can be spread over devices

• information sharing

• not message passing cf:Linda

• logic of information

• implicit communication

• declarative

• no control flow (asynchronous)

• ”agent-oriented”

• Emergent Behaviour

• applications constructed from a collaboration of devices, nodes and spaces


• Light-weight formal methods

• short development time (6 months)

• small team (3 persons)

• but actually part of larger group

• Need to prototype quickly

• prototyping in Alloy

•still specification not implementation

•close to OO semantics/ideas

•dynamic and static modelling possible

•tool support

•”feels” like programming

• nature of concurrency in this system

• implementation language not set

•multiple choices

• certain implementation technologies not decided or potential to be open

•IP vs GSM/UMTS/ vs BT

•RDF vs SQL vs ...

• idea and concept crystallisation

• understanding basic behaviour of system

Requirements

”agile”

development

UML/OO

analysis

Alloy model

Implementation

Test cases

(informal)

Test cases

(”formal”...)

Test cases

(implemented)

• Iterations made to investigate specific parts of the specification as necessary.

... another story


• Models

• domain

• architecture/architectural

• Concepts

• Node

• SmartSpace

• Session

• Fact

• Behaviour

• join/leave, invite/remove

• policy mechanisms

• assert/retract/query/subscribe

• Properties

• System Consistency

• Space vs Information Distribution

• Synchronisation of Information

• Concurrency

• Mobility

Information Store

SIB

Ontological Convenience Functions

Client Services

Membership Info Access

SIB Distribution

Information Distribution

Architectural Mapping


• Alloy

• simple modelling language

• first-order predicate logic

• signatures + relations

• ”method”-free/agnostic

• model constructor/refutor • based on SAT

• Dynamic Modelling

• versus Static

• notion of Time

• Simulation

• executing the system

sig SmartSpace { aware_of : Node set -> Time, facts : Fact set -> Time } sig Node { discovered : SmartSpace set-> Time, memberOf : SmartSpace set-> Time, sessions : Session set->Time } sig Session { target : one SmartSpace, buffer: Fact set -> Time } sig SchedulerTakeFacts extends SchedulerSession_Event{} { #se.buffer.t > 0 ss.facts.t' = ss.facts.t + se.buffer.t no se.buffer.t' } /* A fact can not be shared amongst sessions */ fact FactsNotSharedAmonstSessions{ all f:Fact, t : Time | lone se:Session | f in se.buffer.t }


• Alloy





• model constructor/refutor

• based on SAT


• versus Static

• notion of Time

• Simulation


open util/ordering[Time] as TO sig Time {} fact Traces { -- init [first] all e:Event | e.t' = e.t.next all x: Time - last | one e:Event | e.t = x } pred init (t: Time) { no aware_of.t no discovered.t no memberOf.t no sessions.t no facts.t } abstract sig Event {t,t':Time}


• Alloy





• model constructor/refutor

• based on SAT


• versus Static

• notion of Time

• Simulation


run{} for 5 -- small scale hypothesis run{} for 50 -- lots of memory and patience required! run{} for 5 but 2 Node, exactly 2 SmartSpace, 0 Session run{ some e:InviteNode | e.t != last } for 3 but 2 Node, 2 SmartSpace, 0 Session run { some e:SendFact, f:SchedulerTakeFacts, s:Session | e.t' = f.t and e.se = f.se and #s.buffer.(e.t)>2 and s.buffer.(e.t) in s.buffer.(f.t) } for 5 but 3 Time, 2 Session assert FactsAreEitherInBuffersOrInSmartSpace { all t:Time, se:Session, ss:SmartSpace | no f:Fact | f in se.buffer.t and f in ss.facts.t } check FactsAreEitherInBuffersOrInSmartSpace for 5


run { some e:SendFact, f:SchedulerTakeFacts,

s:Session | e.t' = f.t and e.se = f.se

and #s.buffer.(e.t)>2

and s.buffer.(e.t) in s.buffer.(f.t)

} for 5 but 3 Time,2 Session

t t’

t’’

If a node sends a fact how does this affect the session’s buffer and the SmartSpace information store?

• NB: this is just one example run, Alloy can generate

other non-symmetrical examples if required


run { some e:SendFact, f:SchedulerTakeFacts,

s:Session | e.t' = f.t and e.se = f.se

and #s.buffer.(e.t)>2

and s.buffer.(e.t) in s.buffer.(f.t)

} for 5 but 3 Time,2 Session

t t’

t’’

If a node sends a fact how does this affect the session’s buffer and the SmartSpace information store?

Increase concurrency (trace predicate):

all x: Time - last |

some e:Event | e.t = x }


• Increasing the potential concurrency means that the period of time for a given event may include other events.

• At the points in time t and t’ for some event are guaranteed to be consistent with the invariants (facts) in the model


some e:Event | e.t = x }

SendFact(...) @ t

sendFact(...) @ t’,

SchedulerTakesFacts(...) @ t’

SchedulerTakesFacts(...) @ t’’

other events E1 occur here where:

all e:E1 | e.te > t & e.t’e <t’

other events E1 occur here where:

all e:E1 | e.te > t’ & e.t’e <t’’


one e:Event | e.t = x }

versus

• one and some could be changed to lone or all for different results (all might not be possible other

than the trivial case), but the number of events could be strictly controlled, eg: 2 events per ”tick”


• Specification of policy mechansisms for SmartSpace join events

• Specification of specific parts of the system:

• scheduler of ontology/reasoner engines inside the SmartSpace

• currently being worked upon

• Integration of models, rerunning the simulations and comparing the results

satisfies


• Primarily evaluation is subjective

• requires humans (at least initially) to check the validity of the results

• validation is necessarily an interactive process

• Small scale hypothesis • Simple examples

• Don’t need complex example to find most issues

• Easy to see overconstrainted specifications

• Frame Conditions and Concurrency • single step, atomic semantics not easy in a

distributed system – synchronisation and semaphore protocol overhead

• Can be automated over time • as constraints in the run clause

• eventually as facts (invariants) or pre/post conditions of actions

• cf: test case generation

• regression testing

• demonstration of refinement properties

Is this scenario allowed?

Is this state complex enough?

Is this state reachable or

possible?

Does this action need to be atomic? How storng a frame

condition?


• Testing

• To implementation oriented

• Formal Methods

• UML (!!)

• Z - Z/Eves

• VDM

• Petri-nets

• B/EventB & ProB tool

• verification

• etc

• Advantages of Alloy

• Simple language

• ”Visual” results

• Method-agnostic

• Ability to specify particular runs

• ability to model ”dynamically”

• Semantics

• sig – relationship structure close to OO/ER concepts; easier for the engineers and closer to ”more familiar” development ideas

• frame conditions are explicitly specified

•no underlying ”execution” semantics


• Simulation aids Undertanding and the overall validation of the system

• simulation is a more familiar technique than verification

• verification (static checking/theorem proving) only ensures that the system is correct

• actively involves the customer

• can get involved during specification stages

• early problem diagnosis = better!

• Usecases and Scenarios are meaningful in the context of the specification

• can be visualised

• many simulations for the same use-case

•NB: symmetry breaking

• More integration of formal spec with implementation required

• regression testing

• test cases driving the implementation

• Results wrt. ”SmartSpaces”

• comparison with ”agile methods”

• two groups developing the same system!

• greatly reduced development time

• major concepts and behaviour specified and decided upon early in development

• mapping to implementation much easier when compared to working with informal requirements defintions

• ability to see requirements conflicts

• reduced bugs

• currently no bugs found concerning the architecture or overall system behaviour

• bugs tend to be very localised and simple:

•typos: = vs ==

•logic bugs: off-by-one errors in loops

•Demo of System (Specification and

Implementation) if wanted

design and validation of a distributed computationenvironment for mobile devices

Technology