Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Asynchronous Software Evolution: Obtaining Type Safety by Combining Type Checking and Runtime Constraints

244 views

Published on

We discuss the problem of runtime software evolution in the distributed, asynchronous setting of, e.g., IoT devices.

Published in: Software
  • Be the first to comment

Asynchronous Software Evolution: Obtaining Type Safety by Combining Type Checking and Runtime Constraints

  1. 1. Asynchronous Software Evolution: Obtaining Type Safety by Combining Type Checking and Runtime Constraints Einar Broch Johnsen (joint work with Ingrid Chieh Yu and others) University of Oslo, Norway einarj@ifi.uio.no 1st workshop on Architectures, Languages and Paradigms for IoT (ALP4IoT) Torino, 18 September 2017 http://www.sirius-labs.no
  2. 2. What Do We Want To Talk About Today? [Wikipedia]The Internet of Things • Connected physical devices (also called “smart devices”) with embedded software, sensors, and actuators, which collect and exchange data • Applications: Environmental monitoring, infrastructure management, manufacturing, agriculture, energy management, medical and healthcare, building and home automation, … • Currently, IoT has a strong engineering focus: IoT gateways connect IoT devices and the cloud Talk Overview • Quick, informal intro to home automation • Software evolution for asynchronous, loosely coupled systems • Programming abstractions, typing, and behavioral reasoning E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 1 / 33
  3. 3. Connected, Smart Things Whirlpool’s $1,699 “smart” washing machine boasts Wi-Fi and a colored control screen, can be started from an iPhone app, and will text or email you when your clothes are ready to dry (hopefully you dry them in a “smart” dryer). But if you wonder who would want to buy an Internet-enabled washing machine, you’re not alone. Even Whirlpool’s not so sure. “We’re a little bit of a hammer looking for a nail right now,” said Chris Quatrochi, Whirlpool’s global director of user experi- ence and connectivity. The buyers of web- connected washers, more than a year after launch, are still “not at all widespread,” he said. “Trying to understand exactly the value proposition that you provide to the consumer has been a little bit of a challenge.” (Washington Post, October 28, 2014) Can we help Mr Quatrochi with some ideas? E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 2 / 33
  4. 4. Woolen Smart Things “Smart Socks translate proven science into a design that fits easily into your everyday life.” All you have to do is put on socks like you would every day. The temperature sensors are integrated into the fabric of the sock, and the data is sent to your phone app. Smart Socks are smart machine washable, smart machine dryable, and do not need to be charged. But how can the smart socks get to the washing machine? E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 3 / 33
  5. 5. Smart Implants “Let us connect the smart socks and the smart washing machine to a controllable host, which can act as our mule” (Image MIT) E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 4 / 33
  6. 6. Microprocessor Knees (Images Össur) Software upgrades propagatevia bluetooth to the MPKs! E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 5 / 33
  7. 7. Software Evolution in IoT Distributed system of loosely connected running software that needs to be maintained E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 6 / 33
  8. 8. Runtime Software Evolution Different devices need maintenance • Distributed system of loosely coupled devices • Overall functionality depends on how the devices interact Traditional solution to software upgrades • Halt overall system behavior, recompile, restart • Difficult to achieve in IoT setting Need automated, non-halting solution E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 7 / 33
  9. 9. DSU: Dynamic Software Updating DSU : Techniques to update a running program Existing approaches in practice • Barrier solutions All existing instances must have expired • Passive partitioning Multiple coexisting versions C++, AspectJ • Global update / hot-swapping dist. obj. databases, Java • Asynchronous global Erlang E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 8 / 33
  10. 10. DSU: Dynamic Software Updating DSU : Techniques to update a running program Related formal models • Imperative: C, barrier, single threaded, explicit primitive • Object-oriented: AspectJ, passive partitioning, multiple versions, explicit primitive • Module linking • Reclassification E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 9 / 33
  11. 11. What Could Possibly Go Wrong? In the asynchronous setting, DSU can introduce races between regular execution and code evolution Target CallerDSU Add method m() Call to m() Local upgrades can happen too late Example: Call to a new method, but it is not yet available E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 10 / 33
  12. 12. What Could Possibly Go Wrong? In the asynchronous setting, DSU can introduce races between regular execution and code evolution Target CallerDSU Remove method m() Call to m() Local upgrades can happen too early Example: Call to an old method, but it has been removed E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 11 / 33
  13. 13. What Could Possibly Go Wrong? In the asynchronous setting, DSU can introduce races between regular execution and code evolution Target CallerDSU Remove method m() Call to m() Local upgrades can happen too early Example: Call to an old method, but it has been removed Target DSU Add method m() DSU Call method m() Upgrades can depend on other (delayed) upgrades Example: An upgrade may call a method in another upgrade E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 12 / 33
  14. 14. Asynchronous DSU: The Allegory of the Cave Static vs. runtime view • We want to statically eliminate such runtime errors • …but we don’t know what has happened (so far) at runtime • Mismatch between static and runtime view of the code Technical part of talk coming up • Formal approach to async. runtime evolution • Dynamic class calculus for active objects • Ensure that method binding succeeds when programs asynchronously evolve E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 13 / 33
  15. 15. A Formal Model of Async. Communicating IoT Devices Asynchronously communicating objects: Natural model for IoT • OO model structures programs in terms of classes and methods • Active objects interact asynchronously w/o transfer of control • Internal data structures in objects are captured by ADTs • Active objects encapsulate a processor • Implicit scheduling between processes inside an object Object STATE E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 14 / 33
  16. 16. Asynchronous Method Calls Decouple Communication and Synchronization • Objects communicate through method calls only • Methods exported through interfaces (the types of objects) • Asynchronous invocation: f := o!m(e) • Polling for method result: await f? • Reading the result: x := f.get() • Guarded invocations: f := o!m(e); . . . ; await f?; x := f.get() • Self calls may also be asynchronous / guarded • In order to increase execution flexibility, polling may cause process suspension E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 15 / 33
  17. 17. Cooperative Concurrency • Process: code + local variable bindings (method activation) • Object: state + active process + suspended processes • Suspension by statement await guard • Guards are combinations of: - f? ∈ Guard, where f : Fut⟨T⟩ - e ∈ Guard, where e : Bool • If guard g evaluates to false the active process is suspended • If no process is active, any suspended process may be activated if its guard evaluates to true. • Inner guards enable interleaving of active and reactive code E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 16 / 33
  18. 18. Syntax for Active Object Calculus P ::= D L {T x; sr} D ::= interface I extends I {Ms} T ::= I | Bool | . . . | Fut⟨T⟩ L ::= class C extends C implements I {T f; M} M ::= Ms{T x; sr} Ms ::= T m (T x) sr ::= s; return e s ::= v := e | await g | skip | s; s | if e then s else s fi | release e ::= v | new C( ) | e.get | e!m(e) | . . . g ::= e | v? | g ∧ g v ::= f | x Note that interfaces are the types of objects, and that code is structured in a class hierarchy of method definitions (We here ignore ADTs…) E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 17 / 33
  19. 19. Example: A Bank Account class BankAccount implements Account { Int bal := 0, Fut⟨Bool⟩ f Bool deposit (Nat sum) { bal := bal+sum; return true } Bool transfer (Nat sum, Account acc) { await bal ≥ sum ; bal := bal−sum; f := acc!deposit(sum); return true } } E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 18 / 33
  20. 20. Typing • Classes and interfaces will not be statically given • Context Γ: interfaces ΓI, classes ΓC, variables Γv • Context overriding: Γ + ∆ is Γ overridden by ∆ • Judgments Γ ⊢ s (Var) Γ(v) = T Γ ⊢ v : T (Get) Γ ⊢ v : Fut⟨T⟩ Γ ⊢ v.get : T (New) ∃T′ ∈ interfaces(ΓC(C)) · T′ ⪯ T Γ ⊢ new C( ) : T (Class) ∀I ∈ I · implements(C, I, Γ) ∀M ∈ M · Γ + [this→vC] + [attr(C, Γ)] ⊢ M Γ ⊢ class C extends C implements I {T f; M} Semantics & Type Safety • SOS semantics for asynchronously communicating objects (e.g., ABS) • No “method not understood” errors at runtime [FMCO10] E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 19 / 33
  21. 21. Dynamic Classes • Balance flexibility, ease of use, robustness • A modular OO upgrade mechanism • Asynchronous upgrades propagate through the distributed system • Modify class definitions at runtime A class upgrade affects • All future instances of the class and its subclasses • All existing instances of the class and its subclasses D Network A B C E E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 20 / 33
  22. 22. Upgrade Operations on Dynamic Classes We consider the following class upgrade operations U ::= new-class C extends C implements I {T f; M} Add new class | new-interface I extends I {Ms} Add new interface | update C extends C implements I {T f; M} Add interfaces, add/redefine code | simplify C retract C {T f; M} Remove code Challenges • The timing of upgrade operations at runtime • Recall: Interleaved execution of different processes in an object • New processes must execute on the new state • Old processes must execute on the old state • Upgrade operations may depend on each other! E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 21 / 33
  23. 23. Example of a Class Upgrade: Bank Account class BankAccount implements Account { - - Version 1 Int bal := 0, Fut⟨Int⟩ f Bool deposit (Nat sum) { bal := bal+sum; return true } Bool transfer (Nat sum, Account acc) { await bal ≥ sum ; bal := bal−sum; f := acc!deposit(sum); return true } } update BankAccount extends ∅ implements BankerInt { Nat overdraft := 0 Bool transfer (Nat sum, Account acc) { await bal ≥ (sum−overdraft); bal := bal−sum; f := acc!deposit(sum); return true } Bool setOverdraft (Nat max) { overdraft := max; return true } } The BankerInt interface exports the setOverdraft method E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 22 / 33
  24. 24. Example of a Class Upgrade: Bank Account class BankAccount implements Account, BankerInt { - - Version 2 Int bal := 0, Fut⟨Int⟩ f, Nat overdraft := 0 Bool deposit (Nat sum) { bal := bal+sum; return true } Bool transfer (Nat sum, Account acc) { await bal ≥ (sum−overdraft); bal := bal−sum; f := acc!deposit(sum); return true } Bool setOverdraft (Nat max) { overdraft := max; return true } } E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 23 / 33
  25. 25. Typing w/ Dependency Effects • Context extended with dependencies Γd (class name + version) • Judgments Γ ⊢ s ⟨Σ⟩ where Σ is a set of dependencies • [[v]] represents the dependency information for a variable v (Var) Γ(v) = T Γ ⊢ v : T ⟨[[v]]⟩ (Get) Γ ⊢ v : Fut⟨T⟩ ⟨Σ⟩ Γ ⊢ v.get : T ⟨Σ⟩ (New) ∃T′ ∈ interfaces(ΓC(C)) · T′ ⪯ T Γ ⊢ new C( ) : T ⟨{⟨C, curr(C, Γ)}⟩ (Class) ∀I ∈ I · implements(C, I, Γ) ∀M ∈ M · Γ + [this→vC] + [attr(C, Γ)] ⊢ M ⟨ΣM ⟩ Γ + [⟨C, 0⟩→d ∪ M∈M ΣM {⟨C, 0⟩}] ⊢ class C extends C implements I {T f; M} The effect system identifies all internal dependencies in a piece of code E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 24 / 33
  26. 26. Typing of Dynamic Class Constructs • Sequence of typing contexts Γ0, Γ1, Γ2, . . . • Γ0: context for the original program • Syntax-driven construction of Γi+1 from Γi (New-Class) Γ′ = [C→C(C, I, T f, M)] ∀I ∈ I · implements(C, I, Γi + Γ′ ) C ̸∈ dom(Γi C) ∀M ∈ M · Γi + Γ′ + [this→vC] + [attr(C, Γi + Γ′ )] ⊢ M ⟨ΣM ⟩ Γi + Γ′ + [⟨C, 1⟩→d ∪ M∈M ΣM {⟨C, 0⟩}] ⊢ new-class C extends C implements I {T f; M} (Class-Update) vs = curr(C, Γi d) Γ′ = [C →C (C1; C2, I1; I2, (T1 f1; T2 f2), (M1 ⊕ M))] Γi C(C) = (C1, I1, T1 f1, M1)} refines(M, M1) ∀I ∈ I2 · implements(C, I, Γi + Γ′ ) ∀M ∈ M · Γi + Γ′ + [this→vC] + [attr(C, Γi + Γ′ )] ⊢ M ⟨ΣM ⟩ Γi + Γ′ + [(C, vs + 1)→d ∪ M∈M ΣM ∪ {(C, vs)}] ⊢ update C extends C2 implements I2 {T2 f2; M} E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 25 / 33
  27. 27. Semantics for Dynamic Classes The SOS semantics of the active object calculus consists of ∼20 rules Rough idea of the extension for dynamic classes • Upgrade messages are injected into the runtime configuration • Messages propagate asynchronously • Messages modify classes, then subclasses, then objects • When to apply changes to objects: processor release! • What about upgrades which depend on other upgrades? Upgrade dependencies • The static view of the system may differ from the runtime view • Exploit the dependency mapping! • Dependencies from the type analysis impose runtime constraints on the application of upgrades • Runtime constraints differ for the different upgrade operations E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 26 / 33
  28. 28. Type-Safe Upgrades General case: Modify a class in a class hierarchy Type correctness: Method binding should still succeed! • Add attributes, methods, interfaces, superclasses • Redefine methods (subtyping discipline) • Remove fields, methods • Remove interfaces: not supported • Formal class parameters may not be modified Theorem. Dynamic class upgrades are type-safe with the extended type system and semantics [FM09] E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 27 / 33
  29. 29. Can We Go Beyond Type Safety? Let us now assume that upgrades are well-typed, what can we say about their effect on program behavior? Behavioral Interfaces • Natural to check that classes satisfy constraints of their interfaces • Consider an assertion language to specify local constraints • Assume now that interfaces associate pre/post-conditions to methods • Let O ⊢ m : (p, q) express that O proves that (p, q) holds for method m Soundness Conditions for a Class C Implementing Interfaces I • For m in I, guarantees of m must entail associated interface constraints • For external calls {r}v.m(){s}, (r, s) must follow from constraints of m in I (where v : I) • For local calls {r}m(){s}, (r, s) must follow from guarantees of m [ISOLA12, JLAMP15] E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 28 / 33
  30. 30. Behavioral Reasoning About Adaptable Class Hierarchies Working With Contexts We will analyze a sequence of updates and associated analysis steps, and their effect on a proof context • P: current definitions of classes and interfaces • U: unresolved proof obligations • G(C, m): guarantees (with proof) for m in C Soundness Invariant • For each method m in I, guarantees of m must entail associated constraints in I or I ⇝ m : (p, q) ∈ U(C) • For external calls {r}v.m(){s} in proof of n, (r, s) must follow from constraints of m in I (where v : I) or n ⇝ I : m : (r, s) ∈ U(C) • For local calls {r}m(){s}, (r, s) must follow from guarantees of m or n ⇝ m : (r, s) ∈ U(C) Obviously, when U is empty, we are back to the standard setting E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 29 / 33
  31. 31. Invariant-Preserving Analysis Building Blocks of a Proof System Programs evolve by small changes to the class hierarchy, which can be characterized by their effect on the proof context • Add/remove class, add/remove field, add/remove/redefine method, add/remove inheritance • Add/remove interface, add/remove constraint, add/remove inheritance Each change must preserve the soundness invariant! Example For newMtd(C, M): empty G(C, m), remove M-triggered constraints from U, add new constraints to U for C and for its subclasses E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 30 / 33
  32. 32. Levels of Modularity Combining Steps The class upgrade abstractions discussed earlier can be defined in terms of these operations. Example modify C implements I {F;M} == newImpl(C, I) · newFld(C, F) · newMtd(C, M) How Modular are the Different Operations? Modularity level Adaptations 1. Class local newCls, newImpl 2. Class and subclasses newFld, remFld, newMtd, remMtd, setSup 3. Global – implements clause remInt, newConstr, newSup 4. Global – implementation remCls, remImpl, remConstr, remSup E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 31 / 33
  33. 33. Summary Formal model of asynchronously evolving systems • Active objects: natural model for IoT • Dynamic classes: Modular and asynchronous runtime evolution • Addresses mismatch between static and runtime views of system by combining type analysis with runtime constraints • Type safe asynchronous runtime evolution allows systems to evolve safely • Need contexts to capture change (both for type and proof system) IoT motivates interesting research problems in PL/FM • IoT can be “more than gateways” • Asynchronous software evolution and types • Behavioral reasoning and evolution • Behavioral reasoning and information hiding E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 32 / 33
  34. 34. References Here are references to our work discussed in this talk: [FMCO10] E. B. Johnsen, R. Hähnle, J. Schäfer, R. Schlatte, M. Steffen, ABS: A Core Language for Abstract Behavioral Specification. Proc. 9th Intl. Symp. on Formal Methods for Components and Objects (FMCO 2010), LNCS 6957, Springer 2011. http://einarj.at.ifi.uio.no/Papers/johnsen10fmco.pdf [FM09] E. B. Johnsen, M. Kyas, I. C. Yu, Dynamic Classes: Modular Asynchronous Evolution of Distributed Concurrent Objects. Proc. 16th Intl. Symp. on Formal Methods (FM’09), LNCS 5850, Springer 2009. http://einarj.at.ifi.uio.no/Papers/johnsen09fm.pdf [ISOLA12] J. Dovland, E. B. Johnsen, I. C. Yu, Tracking Behavioral Constraints during Object-Oriented Software Evolution. Proc. Intl. Symp. on Leveraging Applications (ISoLA’12), LNCS 7609, Springer 2012. http://einarj.at.ifi.uio.no/Papers/dovland12isola.pdf [JLAMP15] J. Dovland, E. B. Johnsen, O. Owe, I. C. Yu, A proof system for adaptable class hierarchies. J. Log. Algebr. Meth. Program. 84 (1): 37–53, 2015. https://doi.org/10.1016/j.jlamp.2014.09.001 See these papers for a thorough discussion of related work. E. B. Johnsen (U. of Oslo) Asynchronous Software Evolution ALP4IoT, 18.09.2017 33 / 33

×