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

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@iﬁ.uio.no
1st workshop on Architectures, Languages and Paradigms for IoT (ALP4IoT)
Torino, 18 September 2017
http://www.sirius-labs.no

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

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?

Woolen Smart Things
“Smart Socks translate proven science into a design that
ﬁts 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?

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)

Microprocessor Knees
(Images Össur)
Software upgrades propagatevia bluetooth to the MPKs!

Software Evolution in IoT
Distributed system of loosely connected
running software that needs to be maintained

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
• Difﬁcult to achieve in IoT setting
Need automated,
non-halting solution

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

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
• Reclassiﬁcation

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

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
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

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

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

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 ﬂexibility,
polling may cause process suspension

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

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 ﬁ | 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 deﬁnitions
(We here ignore ADTs…)

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 }
}

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]

Dynamic Classes
• Balance ﬂexibility, ease of use, robustness
• A modular OO upgrade mechanism
• Asynchronous upgrades propagate
through the distributed system
• Modify class deﬁnitions 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

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/redeﬁne 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!

Example of a Class Upgrade: Bank Account
class BankAccount implements Account { - - Version 1
Int bal := 0, Fut⟨Int⟩ f
await bal ≥ sum ; bal := bal−sum; f := acc!deposit(sum); return true }
}
update BankAccount extends ∅ implements BankerInt {
Nat overdraft := 0
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

Example of a Class Upgrade: Bank Account
class BankAccount implements Account, BankerInt { - - Version 2
Int bal := 0, Fut⟨Int⟩ f, Nat overdraft := 0
await bal ≥ (sum−overdraft); bal := bal−sum; f := acc!deposit(sum); return true }
Bool setOverdraft (Nat max) { overdraft := max; return true }
}

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 identiﬁes all internal dependencies in a piece of code

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)} reﬁnes(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}

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 conﬁguration
• 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

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]

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]

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 deﬁnitions 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

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 ﬁeld, add/remove/redeﬁne 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

Levels of Modularity
Combining Steps
The class upgrade abstractions discussed earlier can be
deﬁned 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

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

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.

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

Recommandé

Recommandé

Contenu connexe

Dernier

Dernier (20)

En vedette

En vedette (20)

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