Algebraic Laws for Process Subtyping

Abstract

Abstract. This work presents a conservative extension of OhCircus, a concurrent specification language, which integrates CSP, Z, objectorientation and embeds a refinement calculus. This extension supports the definition of process inheritance, where control flow, operations and state components are eligible for reuse. We present the extended OhCircus grammar and, based on Hoare and He's Unifying Theories of Programming, we give the formal semantics of process inheritance and its supporting constructs. The main contribution of this work is a set of sound algebraic laws for process inheritance. The proposed laws are exercised in the development of a case study.

Specification is Law: Safe Creation and Upgrade of Ethereum Smart Contracts

“…A limitation of our current approach is the restrictive notion of evolution for smart contracts: only the implementation of public functions can be upgradedthe persistent state data structures are fixed. However, we are looking into new types of evolution where the data structure of the contract's persistent state can be changed -as well as the interface of the specification, provided the projected behaviour with respect to the original interface is preserved, based on notions of class [23] and process [12] inheritance, and interface evolution such as in [13].…”

A refinement checking based strategy for component-based systems evolution

“…Some works have proposed inheritance relations for behavioural specifications [11,17,13,15,16,18]. In [13,11] inheritance relations are defined in terms of invariants over state components and by pre and postconditions over defined methods.…”

“…To achieve this goal in a controlled manner, component inheritance must obey the substitutability principle [14,12]: an instance of the subcomponent should be usable wherever an instance of the supercomponent was expected, without a component, playing the role of a client, being able to observe any difference. Some works have proposed inheritance relations for behavioural specifications [11,13,15,16,17,18]. The first four define behaviour in terms of preand postconditions, and structure by method signatures (covariance and contravariance), but do not address reactive behaviour.…”

“…The first four define behaviour in terms of preand postconditions, and structure by method signatures (covariance and contravariance), but do not address reactive behaviour. Although the approaches in [17,18] consider active objects, they do not focus on structure. Furthermore, none of the mentioned works differentiate the nature of input and output events nor the context in which they are communicated.…”