Your SlideShare is downloading. ×
  • Like
Design and Validation of a Distributed ComputationEnvironment for Mobile Devices
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Design and Validation of a Distributed Computation Environment for Mobile Devices

  • 55 views
Published

Development of complex software systems is known to be difficult. The use of formal methods in …

Development of complex software systems is known to be difficult. The use of formal methods in
such developments is advantageous but often suffers from difficulty in applying such methods and the visualisation of the results. We show here that the use of a light-weight formal speci cation language
- Alloy - and the use of simulation traces similar to that of object-diagrams in UML can be eff ective in understanding the behaviour of such systems at analysis and design-times.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
55
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 1 © 2007 Nokia ESM200/IJO
  • 2. 2 © 2007 Nokia ESM200/IJO • Overview of ”SmartSpaces” • Process • Architecture • Validation (Simulation) • Examples of Validation (Simulation) • Evaluation of Simulation Runs • Other Techniques/Tools • Conclusions
  • 3. 3 © 2007 Nokia ESM200/IJO • 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
  • 4. 4 © 2007 Nokia ESM200/IJO • 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
  • 5. 5 © 2007 Nokia ESM200/IJO • 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
  • 6. 6 © 2007 Nokia ESM200/IJO • 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 }
  • 7. 7 © 2007 Nokia ESM200/IJO • 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 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}
  • 8. 8 © 2007 Nokia ESM200/IJO • 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 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
  • 9. 9 © 2007 Nokia ESM200/IJO 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
  • 10. 10 © 2007 Nokia ESM200/IJO 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 }
  • 11. 11 © 2007 Nokia ESM200/IJO • 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 all x: Time - last | 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’’ all x: Time - last | 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”
  • 12. 12 © 2007 Nokia ESM200/IJO
  • 13. 13 © 2007 Nokia ESM200/IJO • 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
  • 14. 14 © 2007 Nokia ESM200/IJO • 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?
  • 15. 15 © 2007 Nokia ESM200/IJO • 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
  • 16. 16 © 2007 Nokia ESM200/IJO • 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