K: A Wide Spectrum Language for Modeling,

Programming and Analysis

∗

Klaus Havelund, Rahul Kumar, Chris Delp and Bradley Clement

Jet Propulsion Laboratory, California Institute of Technology, Pasadena, California, U.S.A.

Keywords:

Modeling, Programming, Constraints, Reﬁnement, Veriﬁcation, SMT, Analysis, SysML, Translation.

Abstract:

The formal methods community has over the years proposed various formally founded speciﬁcation languages

based on predicate logic and set theory, typically with textual notations. At the same time the model-based en-

gineering community has proposed often less formally founded languages such as UML and SysML, typically

with graphical notations. Although the graphical notations have become highly popular in industry, we argue

that textual notations can be attractive in many situations. We report on an effort to provide a textual notation

for SysML, realized in a language named K. K supports classes, multiple inheritance, predicate logic and set

theory. K contains programming constructs, and can thus be considered as a wide-spectrum modeling and

programming language. We further explain the translation of a subset of this language to the input language of

the SMT-LIB standard, and the application of Z3 for analysis of the generated SMT-LIB formulas. The entire

effort is part of a larger effort to develop a general purpose SysML development framework for designing

systems, in support of NASA’s proposed 2022 mission to Jupiter’s moon Europa.

1 INTRODUCTION

Modeling is the activity of formulating an abstract

description of a system, for example to understand

the system before it is implemented. Modeling in-

cludes activities such as requirements capture in the

initial phases and design of higher-level architectural

decisions in later stages. Modeling has been stud-

ied by various communities, of which at least two

can be identiﬁed: the model-based engineering com-

munity and the formal methods community. The

model-based engineering community has suggested

modeling languages such as UML (OMG, 2015) and

SysML (OMG, 2012), a variant of UML. These lan-

guages typically come equipped with graphical nota-

tions (concrete syntax). Both UML and SysML have

been designed by the OMG (Object Management

Group) technology standards consortium. SysML is

meant for systems development more broadly consid-

ered, including physical systems as well as software

systems, in contrast to UML, which is mainly meant

for software development. The graphical notations

have received a high degree of popularity in industry

due to their two dimensional format, also sometimes

∗

The research was carried out at the Jet Propulsion Labo-

ratory, California Institute of Technology, under a contract

with the National Aeronautics and Space Administration.

referred to popularly as boxology: boxes and arrows.

However, drawbacks of these languages include lack

of precise semantics, lack of analysis capabilities, te-

dious GUI operations in tools supporting the graphi-

cal notations, requiring lots of visual real estate even

for simple models, as well as large volumes of tech-

nologies. Learning UML and SysML is not just learn-

ing very large languages, it is also learning a large

set of additional tools needed to work with models.

We formulate the hypothesis that some of these draw-

backs in part are due to the lack of a simple textual

notation, at a size comparable to a programming lan-

guage notation. As evidence of this hypothesis, one

may observe, that software developers mostly prefer

to program in textual languages.

From an even earlier point in time, since the

1960s, the formal methods community, part of the

computer science community, and closely connected

to the programming language community, has pro-

posed numerous formally founded speciﬁcation lan-

guages with textual notations. Several of these are

based on predicate logic and set theory. These lan-

guages are, compared to UML and SysML, concise,

small, well deﬁned in the form of semantics, and in

recent time well supported with analysis capabilities.

The obvious observation is that it might be fruitful

to study the interaction between the two classes of

Havelund, K., Kumar, R., Delp, C. and Clement, B.

K: A Wide Spectrum Language for Modeling, Programming and Analysis.

DOI: 10.5220/0005741401110122

In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 111-122

ISBN: 978-989-758-168-7

111

languages. Consider furthermore that programming

languages are gaining in abstraction, such as for ex-

ample combining object-oriented and functional pro-

gramming. An example is Scala, which has many

commonalities with very early formal speciﬁcation

languages, such as for example VDM (Bjørner and

Jones, 1978), and speciﬁcally its object-oriented vari-

ant VDM

(Fitzgerald et al., 2005). The study

should therefore include the interaction between lan-

guages with graphical notations, and languages with

textual notations, such as formal methods modeling

languages, and programming languages

We report on an effort to develop a textual nota-

tion for SysML. For this purpose we have developed

a language named K (Kernel language) with a tex-

tual notation inspired by notations used in the formal

methods community. K corresponds to SysML’s class

diagrams plus constraints. It is our plan to map other

SysML language concepts into this kernel, rather than

extending the K language to incorporate the rest of

SysML. K supports object-oriented concepts such as

classes, multiple inheritance, and object instances.

The contents of classes can be typed values, includ-

ing functions, and constraints over these expressed

in higher-order predicate logic. K also contains pro-

gramming constructs such as variables/properties, as-

signment statements, and looping constructs, and can

as such be seen as a wide-spectrum modeling and pro-

gramming language. The K language provides an al-

ternative to modeling with the mouse in tools that typ-

ically support SysML: namely writing textual mod-

els in the K notation directly, just like one normally

writes programs. K can furthermore be seen as a vehi-

cle for giving semantics to SysML, providing analysis

capabilities. It is our hypothesis, that modeling can

be seen as programming in a language where some

parts of the model (program) at any point in time are

executable, and some maybe are not (yet). Support-

ing this hypothesis is the large number of language

constructs shared by modeling and programming lan-

guages.

The idea of merging modeling and programming

in one language has been suggested before, as will

be discussed in the related work section. Although K

is not much different from previously suggested for-

malisms, our contribution is the creation of K speciﬁ-

cally in support of a SysML model engineering tool

set under development, to be used by designers of

the proposed 2022 mission to Jupiter’s moon Europa,

also referred to as the Europa Clipper mission con-

cept (Europa Clipper Mission, 2015). The resulting

tool set will support graphical SysML modeling using

MagicDraw (MagicDraw, 2015), as well as browser-

based model viewing and editing, including of textual

K models. A ﬁrst-order subset of K is furthermore

translated to the input language of the SMT-LIB stan-

dard, and currently processed with the Z3 SMT solver

for proving satisﬁability of class deﬁnitions (are the

constraints consistent?), and model ﬁnding (ﬁnd vari-

able assignments satisfying constraints, for example

used in task scheduling). The contribution here is the

handling of (multiple) class inheritance, which is typ-

ically not supported by similar languages translated to

SMT-LIB, as well as the allowance of recursive class

deﬁnitions. Multiple inheritance is a crucial part of

SysML, and therefore of K.

The paper is organized as follows. Section 2 intro-

duces a subset of the K language through an example,

which is similar to examples typically used to illus-

trate such formal speciﬁcation languages. Section 3

outlines the translation from K to the SMT-LIB in-

put language for the purpose of analysis of K models.

This section is based on a different example illustrat-

ing how K is actually currently used at JPL. Section

4 explains the integration of K within the SysML de-

velopment framework, as well as the usage of this.

Section 5 discusses related work, and ﬁnally Section

6 concludes the paper.

2 INTRODUCTION TO K

In this section we introduce the K language. We use

the K model in Figure 1 as our running example for

discussing core concepts in K. The example shows a

model of a ﬁle system modeled using K. It is intended

to be a basis for discussing language features, and not

a complete model of a ﬁle system.

K is a high level textual language which supports

multiple paradigms. It allows one to create packages,

which are collections of classes. Packages can be im-

ported by other K ﬁles. Line 1 in Figure 1 shows

an example of a package declaration. Classes, as in

other object-oriented languages, provide a means for

abstracting and grouping properties (variables). In K,

classes may contain properties, functions (there is no

distinction between functions and methods), and con-

straints (requirements). Scoping rules in K are similar

to languages such as Java and C++. Lines 9 – 12 in

Figure 1 declare an Entry class, which contains two

members: property name of type String, and function

size that takes no arguments and returns an Int. The

function implementation is not speciﬁed for function

size. String is one of the six primitive types provided

by K: Int, Real, String, Char, Unit, and Boolean. K

also provides the following collections:

Bag: collection of items not subject to any order or

uniqueness constraints.

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

112

1 package e xa m p l es . f s

3 BLOCK_SIZE : I n t

5 t y p e B yt e =

6 { | b : I n t :− 0 <= b &&

7 b < 256 | }

9 c l a s s E n t r y {

10 name : St r i n g

11 fun s i z e : I n t

12 }

14 c l a s s Di r e x t e n d s E n t r y {

15 var c o n t e n t s : S e t [ E n t r y ]

16 fun s i z e : I n t {

17 c o n t e n t s . c o l l e c t ( e →

18 e . s i z e ( ) ) . sum ( )

19 }

20 }

22 c l a s s F i l e e x t e n d s E n t r y {

23 c o n t e n t s : Seq [ Blo ck ]

24 req s i z e ( ) <=

25 c o n t e n t s . s i z e ( ) ∗

26 BLOCK_SIZE

27 }

29 c l a s s B loc k {

30 b y t e s : Seq [ Byt e ]

31 fun s i z e : I n t { b y t e s . s i z e ( ) }

32 req s i z e ( ) <= BLOCK_SIZE

33 }

35 c l a s s FS {

36 d i r : D i r

38 fun mkDir ( n : S t r i n g ) : FS

39 pre ! e x i s t s

40 e : d i r . c o n t e n t s :−

41 e . name = n

42 p o s t $ r e s u l t . d i r . s i z e ( )

43 = d i r . s i z e ( )

44 {

45 newDir : D i r = D i r ( name : : n )

46 nc : S e t [ E n t r y ] =

47 d i r . c o n t e n t s + newDir

48 FS ( d i r : :

49 Di r ( name : : d i r . name ,

50 c o n t e n t s : : nc ) )

51 }

53 fun rmDir ( n : S t r i n g ) : FS

54 pre e x i s t s e : d i r . c o n t e n t s :−

55 e . name = n

56 p o s t $ r e s u l t . d i r . s i z e ( )

57 <= d i r . s i z e ( )

58 }

Figure 1: A simple model of a ﬁle system using K.

Seq: collection of items subject to an ordering, but

no uniqueness constraints.

Set: collection of items subject to uniqueness, but no

ordering constraints.

OSet: collection of items subject to uniqueness, as

well as ordering constraints.

K provides predicate subtypes. Line 5 speciﬁes a sub-

type named Byte, which is derived from the Int type

but restricted to values between 0 and 256. K allows

classes to inherit from one or more classes. For ex-

ample, class Dir, speciﬁed on lines 14 – 20 extends

the Entry class. As with other languages, inheritance

causes the child classes to inherit the instance vari-

ables and functions of the parent classes, but in ad-

dition, in K, the child classes also inherit the con-

straints from the parent classes. In the case of multi-

ple inheritance, K requires that the property names be

unique across all classes. Functions on the other hand

may be overloaded by changing the function signa-

ture. Both class File and Dir inherit from class Entry.

Line 15 declares the variable contents using the key-

word var, indicating that this variable is mutable (can

change value). Variables introduced without this key-

word (or with the keyword val) are constants. Lines

16 – 19 in Figure 1 show the implementation for the

size function in the Dir class. It makes use of the sum

function, that is provided by K for all numerical col-

lections. The size function is the same as declared

in class Entry. Currently, function bodies cannot be

declared more than once along an inheritance path.

Functions may take an arbitrary number of arguments

and return a single value. K also provides tuples to

group objects together. On line 32, we see a constraint

being speciﬁed for class Block using the req (require)

keyword. The constraint speciﬁes that the size func-

tion of Block should always return a value that is less

than or equal to the value speciﬁed in the global prop-

erty SIZE_OF_BLOCK (left unspeciﬁed). Any num-

ber of constraints can be speciﬁed at the global scope

or within classes. Constraints are Boolean expres-

sions, that restrict the values variables can take. Con-

straints in a class can be considered class invariants.

Class FS (for FileSystem) contains two functions:

mkDir and rmDir. The mkDir function takes a sin-

gle argument (n of type String) and returns a FS ob-

ject which contains one additional directory entry that

has name n. The rmDir function has no body spec-

iﬁed. Both functions are deﬁned along with a func-

tion speciﬁcation. Function speciﬁcations are a list

of pre and post conditions that describe the precondi-

tion and postcondition of the function. Any number

of speciﬁcations may be provided. Line 39 speciﬁes

the precondition for function mkDir with the use of an

existential quantiﬁer. It speciﬁes that when creating a

K: A Wide Spectrum Language for Modeling, Programming and Analysis

113

directory in the ﬁle system, the given name n should

not exist in the current set of entries in the ﬁle system.

K provides both existential and universal quantiﬁca-

tion in its expression language. For the same func-

tion, line 42 speciﬁes the postcondition. $result is a

reserved word that refers to the return value of the

function. It can only be used when specifying post-

conditions. The postcondition for mkDir speciﬁes that

function mkDir returns a FS object that has the same

size as the current FS object, which was used to create

the new directory. Lines 44 – 51, the body of function

mkDir, form a block consisting of the declaration of

two constants: newDir and nc, followed, in line 48, by

the creation (and return) of a new FS object by calling

the constructor for class FS. Note that the entries of a

block are not separated by semicolon (‘;’). In fact,

K does not have a semicolon (nor newline) as state-

ment separator, as for example seen in the program-

ming language Scala. The only argument provided to

the FS constructor is a Dir object which contains one

additional Dir entry whose name is n. K provides con-

structors automatically for all classes where the argu-

ments are named arguments. Each named argument is

of the form ‘member :: value’ where the ‘::’ notation

is used as a form of assignment. Multiple named ar-

guments can be provided as a comma delimited list. It

is not necessary to specify a value for all members of a

class. Any members that are speciﬁed in a constructor

call are assigned the speciﬁed value, and the rest are

left underspeciﬁed. Function rmDir is speciﬁed with

no body, but only function speciﬁcations. The func-

tion speciﬁcations require that function rmDir only ex-

ecute if the provided directory n exists in the current

object’s contents. The postcondition speciﬁes that the

resulting FS object should be either the same size or

smaller relative to the current object.

Expressions in K are the core of the language. Ex-

pressions in K allow one to write assignment state-

ments (side-effects), binary expressions (such as and,

or, implication, iff etc.), logical negation, arithmetic

negation, quantiﬁcation, ‘is’ for checking type, and

‘as’ for type casting. Any expression can make use

of other deﬁned constructs such as variables, function

application, lambda functions, and dot expressions.

K also supports control expressions such as if-then-

else, while, match, for, continue, break, and return.

These expressions are similar to control expressions

provided in programming languages such as Scala or

Java. A detailed description of the expression lan-

guage is beyond the scope of this paper.

K also provides multiplicities as part of the lan-

guage. Multiplicities in K are inﬂuenced by similar

concepts in languages such as UML/SysML. In K,

multiplicities can be used as a short hand for speci-

fying collections and also restricting the size of col-

lections. Figure 2 shows a K model of a Person that

has various member properties, and the correspond-

ing inferred type for each member property. We will

analyze each of these individually.

Each Person can have exactly one mother. This is

speciﬁed by line 4. No explicit multiplicity is speci-

ﬁed, which makes it a singleton. A Person can also

have many unique children, which is speciﬁed by line

5 using the Set collection. Line 6 speciﬁes that a

Person may have many cars. It is written using a

modiﬁer and a multiplicity, which semantically trans-

lates to a Set (K default for a multiplicity is Bag) of

Car. Finally, a person may own one or more portfo-

lios (prtﬂios, speciﬁed to have a multiplicity of 1 or

more), where each entry itself is a Set of Stock. This

translates to prtﬂios being a Bag of Set[Stock] with at

least 1 entry and no upper limit.

SysML models can also carry meta data informa-

tion in them (sometimes introduced by tools). To ac-

commodate for this, K also provides the annotation

construct. New annotations can be created and ap-

plied to classes, expressions, functions etc. Currently,

each annotation has a name and a type.

K also provides single line comments using ‘--’ at

the beginning of the line, and block comments using

‘===(=*)’ as the token for the beginning and the end

of the comment.

2.1 K Type Checking

The K type checker performs basic checks on the pro-

vided input to ensure naming and type consistency.

It is used to ensure that all declarations, expressions,

annotations etc. are logically sound and reference

names (functions, members, variables) that exist and

are type consistent in the given context. Type infor-

mation for all expressions and any other inferences

made by the type checker are saved and made avail-

able to all other analyses/modules in the K tool chain.

Further, the type checker imposes a stricter set of rules

on the provided input to ensure that it can be com-

pletely and correctly translated to SMT. More details

are provided in Section 3. The type checker is im-

plemented as a stand alone module, which is invoked

after the AST has been constructed by a visitor (in-

terfacing with ANTLR). The implementation is done

using Scala.

3 TRANSLATING K TO SMT-LIB

In this section we illustrate the translation from K to

the SMT- LIB input language. SMT-LIB (SMT-LIB,

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

114

1 c l a s s St o c k

2 c l a s s Car

3 c l a s s P e r s o n {

4 moth e r : P e r s o n

5 c h i l d r e n : S e t [ P e r s o n ]

6 unique c a r s : Car [ ∗ ]

7 p r t f l i o s : S e t [ S to c k ] [ 1 , ∗ ]

8 }

4 Pe r s o n

5 Se t [ P e r s o n ]

6 Se t [ Car ]

7 Bag [ S e t [ S to c k ] ]

8 req p r t f l i o s . s i z e ( ) >= 1

Figure 2: Example model (left) and inferred types (right) for members of class Person.

2015) is the standard “satisﬁability modulo theories

library” for SMT solvers. The standard is used by nu-

merous SMT solvers, allowing comparison between

systems (for example in competitions). In addition,

it allows systems generating SMT-LIB formulas to

target any SMT solver processing this standard. In

our case we use the Z3 SMT solver (De Moura and

Bjørner, 2008) to process the generated formulas, but

anticipate targeting other solvers in the near term.

3.1 The Source K Model

The translator currently covers a ﬁrst-order logic sub-

set of the K language, corresponding to the model of

a SpaceCraft shown in Figure 3. The translated sub-

set includes classes, multiple inheritance, properties

of primitive types (Bool, Int, and Real), user-deﬁned

class types, tuple types (cartesian product), functions,

pre/postconditions, and constraints. Functions, pre/-

postconditions, and constraints can be speciﬁed in

a rich expression language supporting conditionals,

class constructors, dot notation for accessing proper-

ties in objects, and universal and existential quantiﬁ-

cation. Sets are under development but not covered

here. Currently not translated constructs include type

parameterized classes, statements with side-effects

(assignment) and their corresponding looping con-

structs, functions as ﬁrst class citizens, type abbrevia-

tions and predicate subtypes, as well as multiplicities,

which will be treated as collection types. Recursive

functions can currently not be deﬁned using function

deﬁnitions, but can be speciﬁed by providing function

signatures plus separate constraints.

The example illustrates the features of K that have

been used by engineers at JPL until the time of writ-

ing. The emphasis of these models is on structure of

artifacts and scheduling of events. The class Thing is

meant to represent entities that have weight. Instru-

ments, its radio sub-classes, and the SpaceCraft class

itself, inherit from class Thing. Class Instr deﬁnes a

power level. Requirements in the form of Boolean

constraints are imposed on power and weight. The

SpaceCraft class makes instances of instruments, de-

ﬁnes a combined sum instrWeight, and a constraint

on it with additional requirements. Such elements of

a model are so-called structural elements, what one

would normally see in a SysML class diagram.

The spacecraft in addition contains a system man-

ager, representing the software on board. For the pur-

pose of illustration, the system manager is deﬁned as

a small scheduler of three events: a bootUp event,

re-booting the ﬂight software computer, an initMem

event, initializing the computer memory, and a tkPic

event, taking a picture. An event is an instance of the

Event class, which deﬁnes an event as having a start

time and an end time appearing after the start time.

In addition, the Event class deﬁnes a function after,

which as argument takes another event ‘e’, and re-

turns true if the event (this) occurs after ‘e’. The def-

inition of the after function is inspired by Allen logic

(Allen, 1984). Finally, the model contains an instance

ShRaan of type SpaceCraft.

Given the spacecraft model, the general proof-

theoretic problem we want an answer to is whether

our classes are logically consistent. That is, whether

the constraints of each class are consistent (do not

evaluate to false such as for example is the case with:

‘x < 0 ∧ x > 0’). From a semantics point of view,

it means that for each class there exists at least one

instance (object) of that class that satisﬁes the con-

straints. An SMT solver demonstrates satisﬁability

by ﬁnding a model satisfying the constraints (model

ﬁnding). This model furthermore represents a sched-

ule of the events in the system manager.

3.2 The Translation to SMT-LIB

The SMT-LIB language (from here on referred to as

SMT-LIB) is equipped with a textual notation, and

supports typed ﬁrst order predicate logic plus vari-

ous theories, including for example arithmetic, unin-

terpreted functions, and arrays. The syntax is LISP-

like, meaning for example that function calls such as

f (42, f alse) have the form ( f 42 f alse). For the

51 line K model in Figure 3, the translator generates

333 lines of uncommented SMT-LIB code (additional

comments are generated to make the output easier for

humans to read). We shall below show formulas from

each category of formulas generated, covering all the

categories. Our main challenge in translating K to

K: A Wide Spectrum Language for Modeling, Programming and Analysis

115

1 c l a s s T h ing { w e i g h t : I n t }

3 c l a s s Ev e nt {

4 s t a r t : R e al

5 end : R e a l

6 req s t a r t >= 0 . 0 &&

7 end > s t a r t

8 fun a f t e r ( e : E v e nt )

9 : Bool {

10 s t a r t >= e . end

11 }

12 }

14 c l a s s I n s t r

15 e x t e n d s Thi n g {

16 power : R e a l

17 req power >= 0 . 0

18 req w e i g h t > 0 &&

19 w e i g h t <= 1000

20 }

22 c l a s s SmplRadio

23 e x t e n d s I n s t r

24 c l a s s S m r t R ad i o

25 e x t e n d s SmplRadio

27 c l a s s SysMngr {

28 bootUp : Ev e n t

29 initMem : E v e n t

30 t k P i c : E vent

31 req t k P i c . a f t e r ( initMe m )

32 &&

33 t k P i c . a f t e r ( bootUp )

34 }

36 c l a s s S p a c e C r a f t

37 e x t e n d s Thi n g {

38 i n s t r W e i g h t : R eal

39 r a d i o : I n s t r

40 ca mera : I n s t r

41 s o f t w a r e : SysMngr

43 req i n s t r W e i g h t =

44 r a d i o . w e i g h t +

45 ca m era . w e i g h t

47 req n ot To oH ea vy :

48 i n s t r W e i g h t <= 999

49 }

51 ShRaan : S p a c e C r a f t

Figure 3: A simple K model of a spacecraft.

SMT-LIB is how to translate classes supporting (mul-

tiple) inheritance and recursive references between

classes. This will be illustrated in the following.

Classes, Objects, and the Heap. Let’s ﬁrst trans-

late a simple class, such as class Thing. We have

chosen to translate classes to the SMT-LIB concept

of datatypes. A datatype in SMT-LIB corresponds

to the classical notion of an algebraic datatype: a

named record, with a constructor function that when

applied to a sequence of values generates a value of

the datatype, while the values can be retrieved using

selector functions. The class Thing can be represented

in SMT-LIB as follows.

( d e c l a r e −d a t a t y p e s ( ) ( ( Thing

(mk−Thing ( w e i g h t I n t ) ) ) ) )

This declaration declares the datatype Thing, the con-

structor mk-Thing, which can be called on a value w

of type Int as follows: (mk-Thing w), to produce a

value in type Thing. Reversely, given a value o in type

Thing, we can retrieve the weight by applying the se-

lector function weight to o as follows: (weight o).

Consider now the following schematic example of

two mutually recursive classes, a situation often oc-

curring in SysML modeling (relationships between

two classes) as well as in programming (i.e. linked

lists). Note that due to the declarative nature of K,

it is possible to initialize objects of such classes in

a recursive manner even without programming with

side-effects. If no constructors are applied, the solver

will assign objects.

c l a s s A { c l a s s B {

b : B a : A

} }

The following translation of this model to the SMT-

LIB datatypes A and B is not well-founded since it

contains recursion between A and B (it is illegal SMT-

LIB).

( d e c l a r e −d a t a t y p e s ( ) (

(A (mk−A ( b B ) ) )

(B ( mk−B ( a A ) ) ) ) )

The solution is to operate with references to objects

rather than objects directly, exactly as done in any

runtime system for an object-oriented programming

language. In other words, we need a heap mapping

references to objects. For this purpose we deﬁne the

type of references as integers.

( d e f i n e −s o r t Ref ( ) I n t )

We can now in SMT-LIB use Ref as the type of prop-

erties whose type in K is a class, they will now denote

references to objects of the class. This is illustrated by

the following deﬁnition of the SpaceCraft datatype.

( d e c l a r e −d a t a t y p e s ( ) ( ( S p a c e C r a f t

(mk−S p a c e C r a f t

( w e i g h t I n t )

( i n s t r W e i g h t Real )

( r a d i o Ref ) ( ca m era Ref )

( s o f t w a r e Ref ) ) ) ) )

Observe how the fact that SpaceCraft inherits from

Thing is modeled by the inclusion of the weight ﬁeld

from Thing. Inheritance is simply modeled by prop-

erty inclusion in this manner. In order to deﬁne a

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

116

heap, we need a datatype that represents all the ob-

jects that can possibly be stored in the heap. The fol-

lowing datatype Any represents all the datatypes for

the individual classes, by lifting them to this single

type (null is a zero argument constructor). The type

Any corresponds to Java’s type Object.

( d e c l a r e −d a t a t y p e s ( ) ( ( Any

( l i f t −Th i ng

( s e l −Th i ng T h i ng ) )

( l i f t − I n s t r

( s e l − I n s t r I n s t r ) )

( l i f t −S p a c e C r a f t

( s e l −S p a c e C r a f t S p a c e C r a f t ) )

. . .

n u l l ) ) )

Now we can deﬁne the heap as an array from refer-

ences of type Ref to Any.

( d e c l a r e −c o n s t he ap ( Array Ref Any ) )

Accessing the Heap. We ﬁrst deﬁne a function

deref, which when applied to a reference returns the

Any object at that entry.

( d e f i n e −fu n d e r e f ( ( r e f Ref ) ) Any

( s e l e c t heap r e f ) )

With this function we are now ready to deﬁne func-

tions, which can test what kind of object is at a certain

location in the heap, as well as retrieve that object.

The following functions perform these two tasks for

the case of the Instr objects (for each datatype con-

structor C, SMT-LIB generates an is-C function that

can determine whether an object is constructed with

the constructor).

( d e f i n e −fu n d e r e f −i s − I n s t r

( ( t h i s Ref ) ) Bool

( i s − l i f t − I n s t r ( d e r e f t h i s ) ) )

( d e f i n e −fu n d e r e f − I n s t r

( ( t h i s Ref ) ) I n s t r

( s e l − I n s t r ( d e r e f t h i s ) ) )

As we have seen, K classes can contain properties of

types that are classes. For example the SpaceCraft

class contains a property radio of type Instr. In an

object-oriented language like K with inheritance, such

a property can denote any object that is of type that

either is equal to, or sub-classes Instr. In order to for-

mulate invariants on objects of class SpaceCraft, we

therefore need to be able to determine whether a ra-

dio object is equal to, or sub-classes Instr. This task

is performed by the following function, the body of

which is a disjunction between the three alternatives.

( d e f i n e −fu n d e r e f −i s a − I n s t r

( ( t h i s Ref ) ) Bool

( or

( d e r e f −i s − I n s t r t h i s )

( d e r e f −i s −SmplRadio t h i s )

( d e r e f −i s −Sm r tR a d i o t h i s ) ) )

Getters of Properties in Classes. Functions and

requirements access properties. An example is the ex-

pression weight > 0 in class Instr. These accesses are

wrapped into getter functions. As an example, the

weight property of the class Instr can be accessed with

a call of the following function, named Instr!weight

(SMT-LIB allows symbols such as ‘!’ in names, to

be discussed further below), on a reference that is as-

sumed to refer to an Instr object.

( d e f i n e −fu n I n s t r ! w e i g h t

( ( t h i s Ref ) ) I n t

( w e i g h t ( d e r e f − I n s t r t h i s ) ) )

The above deﬁnition assumes that the this reference

denotes an Instr object, and not an object of any sub-

class on Instr, hence the ‘!’ symbol (for exact! class)

in the name. This is sufﬁcient when checking satisﬁ-

ability of the class Instr class itself. However, when

checking the satisﬁability of, for example, the Space-

Craft class, which contains a property of type Instr,

as for example radio : Instr, we have to assume that

radio in addition potentially can refer to any object

of a class that sub-classes Instr, which in this case

is either SmplRadio or SmrtRadio. This is achieved

with the following alternative getter function, named

Instr.weight, for the weight property of the class Instr.

( d e f i n e −fu n I n s t r . w e i g h t

( ( t h i s Ref ) ) I n t

; i f

( i t e ( d e r e f −i s − I n s t r t h i s )

; t h e n

( w e i g h t ( d e r e f − I n s t r t h i s ) )

; e l s e i f

( i t e ( d e r e f −i s −SmplRadio t h i s )

; t h e n

( w e i g h t ( d e r e f −SmplRadio t h i s ) )

; e l s e

( w e i g h t ( d e r e f −SmrtRa d i o t h i s ) )

) ) )

Each line in the body is preceded with a comment us-

ing the comment symbol ‘;’, explaining the structure

of the LISP version of ‘if e

then e

else e

’, which is

‘(ite e

)’. The reason for not just using the lat-

ter more general function Instrument.weight for all ac-

cesses to the weight property is that conditionals make

it harder for an SMT solver. Even moderately sized

expressions with several accesses to variables become

unsolvable in reasonable time in the presence of such

conditional expressions.

Functions. Functions are translated directly to

SMT-LIB functions. Each function is translated in

two versions, corresponding to the two versions of the

getter functions, and named using respectively class-

Name!functionName and className.functionName,

to suggest which getter functions are called inside

K: A Wide Spectrum Language for Modeling, Programming and Analysis

117

the function, again depending on the calling context

(whether this refers to the exact class or potentially a

sub-class). As an example, the following is the trans-

lation of the after function in the class Event, only

showing one of the two versions, which are the same

in this case.

( d e f i n e −fun E v e nt . a f t e r

( ( t h i s Ref ) ( e Ref ) ) Bo ol

( >= ( Ev e n t . s t a r t t h i s )

( Even t . end e ) ) )

The ﬁrst parameter is a reference (named this) of type

Ref. The this reference is meant to refer to the ob-

ject upon which the function is called. Consider for

example a call like: tkPic.after(initMem) in line 31 of

Figure 3. Here tkPic denotes a reference to which the

parameter this is bound. The second parameter is the

user-provided parameter.

Invariants and Assertions. We are ﬁnally able

to present how class invariants are generated and as-

serted. These validate the satisﬁability of our classes.

The invariant for a class is generated as a function that

as argument takes a this reference to an object of that

class. Let’s take the example of the SysMngr class.

The generated invariant is the following.

( d e f i n e −fu n SysMngr . i n v

( ( t h i s Ref ) ) Bool

( and

( d e r e f −i s a −E v e n t

( SysMngr ! bootUp t h i s ) )

( d e r e f −i s a −E v e n t

( SysMngr ! initMe m t h i s ) )

( d e r e f −i s a −E v e n t

( SysMngr ! t k P i c t h i s ) )

( and

( Even t . a f t e r

( SysMngr ! t k P i c t h i s )

( SysMngr ! initMe m t h i s ) )

( Even t . a f t e r

( SysMngr ! t k P i c t h i s )

( SysMngr ! bootUp t h i s ) ) ) ) )

The body of this function is a conjunction of the con-

ditions that have to hold on the SysMngr object re-

ferred to by this. There are four such: three for the

property deﬁnitions in lines 28 – 30 in Figure 3, and

one for the requirement on line 31. Each of the prop-

erty deﬁnitions results in a condition that veriﬁes that

the property is of the right type, in these three cases:

that each of the properties bootUp, initMem, and tkPic,

are objects of any sub-class of class Event (the use of

‘isa’), although in this case there are no sub-classes

of Event. The last condition, corresponding to the re-

quirement, illustrates how functions are called, in the

case the function after.

We are now ﬁnally ready to assert the well-

formedness of the model. For each class two asser-

tions are generated, one that asserts the existence of

an object of the class in the heap, and one asserting

that every object of that class in the heap satisﬁes the

invariant of that class. Below are these two assertions

for the SysMngr class.

( a s s e r t ( e x i s t s ( ( t h i s Ref ) )

( d e r e f −i s −SysMngr t h i s ) ) )

( a s s e r t ( f o r a l l ( ( t h i s Ref ) )

(= >

( d e r e f −i s −SysMngr t h i s )

( SysMngr . i n v t h i s ) ) ) )

Solving the Model. Given the generated SMT-

LIB model outlined above, an SMT solver follow-

ing the SMT-LIB standard can determine whether the

model is satisﬁable. Our currently used SMT solver is

Z3. If the model is not satisﬁable, the solver will just

return ‘not satisﬁed’. One can in this case analyze

subsets of the model, eliminating assertions to dis-

cover which assertions caused the model to become

unsatisﬁable, in the best case the minimal set of such

assertions. We are working on such a violation expla-

nation capability.

If the model on the other hand is satisﬁable, an

assignment to variables in the model will be returned

by the solver. In our case the model outlined above

is satisﬁable and solves in 2 seconds. The returned

assignment is shown in Figure 4. This view has been

produced by processing the output from Z3, which is

less comprehensible. The assignment shows the fol-

lowing. The outermost ShRaan property in the heap

denotes a SpaceCraft object. This object contains var-

ious ﬁelds, for example the weight property with the

value 18, and the software property, which denotes

the reference (of type Ref) 21. This reference in turn

denotes a SysMngr object containing three references

bootUp (25), initMem (26), and tkPic (27), each of

which are events. Due to the constraint in line 31 of

Figure 3 these events have been scheduled such that

the taking of the picture occurs after the boot as well

as after the memory initialization. This can be seen

from the fact that the end times of the boot and mem-

ory initialization events at references 25 and 26 are

less than the start time of the take picture event at ref-

erence 27. Note that the values suggested by the SMT

solver are not necessarily realistic, although they sat-

isfy the provided constraints.

4 K IN PRACTICE

Currently, K is used to analyze models created for the

NASA Europa Clipper Mission Concept. Figure 5

gives an overview of the usage scenarios for the K

language and tool chain.

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

118

+−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+

| V a r i a b l e | V alu e |

| ShRaan | S p a c e C r a f t ( w e i g h t : : 1 8 , i n s t r W e i g h t : : 9 6 6 . 0 , |

| | r a d i o : : Ref 1 9 , cam er a : : Ref 20 , s o f t w a r e : : Ref 2 1 ) |

| Ref 19 | SmplRadio ( w e i g h t : : 3 6 0 , power : : 2 3 3 1 . 0 ) |

| Ref 20 | I n s t r ( w e i g h t : : 6 0 6 , power : : 4 7 7 0 . 0 ) |

| Ref 21 | SysMngr ( bootUp : : Ref 25 , i nit Mem : : Ref 26 , t k P i c : : Ref 27 ) |

| Ref 25 | E v e n t ( s t a r t : : 9 6 5 9 . 9 0 8 8 , end : : 9 6 6 0 . 9 0 8 8 ) |

| Ref 26 | E v e n t ( s t a r t : : 7 8 5 4 . 0 , end : : 7 8 5 5 . 0 ) |

| Ref 27 | E v e n t ( s t a r t : : 1 7 2 5 7 . 0 , end : : 2 1 5 9 3 . 0 ) |

Figure 4: Output of the K tool chain for the spacecraft example.

The typical scenario involves modelers (of the Eu-

ropa Clipper mission concept) creating SysML dia-

grams in a tool such as MagicDraw and saving them

to a central model repository. This database of mod-

els is accessible via a REST API. The input to the

REST API is a unique identiﬁer for a node (typically

a SysML package) in the model, and the result is a

list of all the nodes that are part of the package spec-

iﬁed in the input. The result is provided as an array

of JSON objects, where each object contains infor-

mation such as name, type, owner, etc. Typically, the

types of objects are classes, constraints, expressions,

and member properties. The K tool chain takes this

input and converts each node in the list of nodes to a

corresponding K AST object. Since the list of nodes

received from the REST API is unordered and un-

structured, we perform multiple passes on the list of

nodes. The ﬁrst pass is performed to create the list of

classes in the model, followed by passes to populate

properties and constraints in each class. Once the K

model has been constructed, the K tool chain proceeds

normally with type checking and SMT analysis. Cur-

rently this scenario is based on a pull methodology

where a modeler has to initiate the K based transla-

tion and analysis. In the future, we plan on automat-

ing this effort and have it be executed on a regular ca-

dence with results made available through the model

database to a web application.

A second common scenario for using K is via the

web browser (K, 2015). We have created a simple

HTML based K code editor along with the function-

ality to invoke the K tool chain from the web browser.

This page is used for purposes of teaching, learning,

exploring, and prototyping with K. The web page also

provides a tutorial, documentation, and examples.

Finally, the K tool chain is also available as a bi-

nary download for all major operating systems. Users

may download the binaries and invoke the tool chain

from the command line. We expect that certain mod-

els of Europa Clipper mission concept are created and

analyzed directly as K models. Currently, there are

two such salient examples where K was used to cre-

ate and analyze requirements. The ﬁrst model is a

series of scheduling constraints, which after model-

ing in K, were successfully analyzed in less than 20

seconds. The results of the analysis also discovered a

scheduling problem, that was later successfully con-

ﬁrmed by a signiﬁcantly more cumbersome manual

analysis. The second model contains a series of high

level constraints that are analyzed using K for satisﬁ-

ability. This model solves in around 30 seconds. Due

to JPL’s information release restrictions, such details

cannot be shared at this time.

5 RELATED WORK

K is a wide spectrum language with a textual nota-

tion, containing concepts such as classes, inheritance,

properties, functions, and expressions. Expressions

in K are very rich and provide a basis for express-

ing any higher order logic formula succinctly. The

language also contains constructs such as lists, sets,

loops etc. for performing general sequential pro-

gramming, functional programming, and object ori-

ented programming. The main goal is to automati-

cally translate SysML diagrams and models to K and

perform various types of analysis such as type check-

ing, satisﬁability checking, and potentially execution.

The formal methods community has studied and

investigated wide spectrum speciﬁcation languages in

detail. (Bjørner and Jones, 1978; Bjørner and Jones,

1982; Jones, 1990; Jones and Shaw, 1990) present

the VDM language, which provides a combination of

procedural and functional programming along with

sets, lists, maps, and higher order predicate logic in

proper mathematical notation. A natural evolution of

VDM was to introduce object orientation, as shown

in VDM

(Fitzgerald et al., 2005). The RAISE

speciﬁcation language (George et al., 1992) is another

wide spectrum language that takes inspiration from

VDM, Z (Spivey, 1988) and algebraic speciﬁcation

languages. More recently, Asml presented in (Gure-

vich et al., 2005) presents a language where all oper-

ations operate on algebras. Alloy (Jackson, 2012) is

K: A Wide Spectrum Language for Modeling, Programming and Analysis

119

Figure 5: K in practice.

a language intended for describing structure and ex-

ploring the design of the structure through the speciﬁ-

cation of constraints. Alloy also provides seamless

integration with a SAT solver. FORMULA (Jack-

son et al., 2009) also presents a language for logic

programming where the model is then analyzed by

SMT solvers. FORMULA focuses on requirements

for incremental reﬁnement purposes and design ex-

ploration.

In contrast to speciﬁcation languages, high level

programming languages have also been developed

over time. SML (Standard ML) (Milner et al., 1997),

Ocaml (OCaml, 2015), and Haskell (Jones, 2003) be-

long to the same family of functional programming

languages with some support for classes and object

orientation. Python (Python, 2015) also provides a

unique perspective on combining object oriented and

functional programming. In our view, Scala (Scala,

2015) does so to the fullest extent. The close re-

lationship between Scala and VDM is discussed in

(Havelund, 2011). Fortress (Fortress, 2015) intro-

duced built-in notation for sets, lists, and maps, very

much resembling the notation in VDM.

Yet another class of recent languages has investi-

gated introducing speciﬁcation constructs in program-

ming languages in the form of design-by-contract

(pre/postconditions and class invariants). Examples

of such languages include Eiffel (Meyer, 1988) and

SpeC

(Barnett et al., 2011). Scala also attempts

at providing such constructs, but through the use of

library functions on functional programs (Odersky,

2010). Finally, The JML language (Leavens et al.,

1998) allows to write design-by-contract speciﬁca-

tions for Java as comments. These speciﬁcations and

constructs are ignored by the standard Java compiler.

Rather, they are processed with special tools; thus,

in some cases making them less valuable to the lan-

guage.

With the great improvements being made to SAT

and SMT solvers (SMT-LIB, 2015; De Moura and

Bjørner, 2008), programming languages now are also

built with veriﬁcation as a primary goal. Dafny

(Leino, 2010) provides explicit support for speciﬁca-

tions in the program that can be used to specify func-

tional correctness constraints for programs. These

constraints and speciﬁcations are veriﬁed using the

Boogie (Barnett et al., 2006) veriﬁer that uses Z3 as

the underlying SMT solver. Dafny is an excellent lan-

guage for performing veriﬁcation, but lacks support

for inheritance and class invariants, which are a ne-

cessity for the kind of models we deal with. Similarly,

SpeC

also provides support for verifying the user

provided speciﬁcations. Why3 (Bobot et al., 2011)

provides a rich language for speciﬁcation and pro-

gramming, called WhyML. Why3 relies on external

theorem provers (automatic and interactive) to then

verify the speciﬁcation. Additionally, using WhyML,

one can also generate Ocaml programs using a correct

by construction automatic extraction procedure. In

contrast to using automated provers, interactive the-

orem provers such as PVS (Owre et al., 1992; PVS,

2015), Coq (Barras et al., 1997), and Isabelle (Nip-

kow et al., 2002), also provide languages to create

speciﬁcations and provide constraints, which can then

be discharged via a user guided process. Such tools

allow for proving much more complex properties, but

tend to be laborious and non-trivial to use.

Past research in formal modeling has also resulted

in various attempts at combining formal and semi-

formal languages. Work in (Lausdahl et al., 2009)

presents an approach to translate between UML and

VDM

, and (Kim et al., 2005) presents work on

integrating a formal language such as Object-Z with

UML in a single combined framework. To the best of

our knowledge, these approaches have not focused on

translating constraints and integrating with an SMT

solver, and have been primarily focused on UML (not

SysML).

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

120

K is very close in spirit and ideology to many

of the aforementioned languages, but differs in many

respects as well. For example, due to the appli-

cation environment of K being targeted to SysML

models, proving class satisﬁability and model ﬁnd-

ing are of prime importance, something for which K

is optimized. K also provides support for specify-

ing and proving speciﬁcations with multiple inheri-

tance, something SysML models depend on greatly.

Integration with SMT solvers has proven to be useful

not only for proving class satisﬁability, but also for

model ﬁnding (including scheduling) and model ex-

ploration. In model exploration, users manually ex-

plore the range of satisﬁable solutions for the given

model using iterative reﬁnement techniques (chang-

ing constraints manually).

6 CONCLUSIONS

We have presented an overview of the K language

in this paper. K is intended to be used in a model-

ing environment for proving satisﬁability of SysML

models and exploring solutions to various types of

models, such as structure, planning/scheduling, etc.

We have also presented in detail, our methodology

for performing automatic translation of K models to

SMT-LIB, and using an SMT solver such as Z3 to

perform semantic model ﬁnding. Using manual meth-

ods of creating K models from SysML models and

reference materials, we have already observed K pro-

vide value in the modeling environment by discov-

ering unsatisﬁability of scheduling problems in the

proposed Europa Clipper mission concept, which was

conﬁrmed by external manual analysis. In our cur-

rent experience, K seems to be sufﬁcient for creating

small to medium sized SysML models and proving

properties about them. Concerning problems faced,

a main challenge of course is the higher-order nature

of K, requested by mission engineers (expressiveness

prioritized over guaranteed analyzability). SMT-LIB

is generally ﬁrst-order. Some problems are a con-

sequence of using SMT-LIB solvers, which struggle

with the combination of arrays (used for the heap and

for sets) and universal quantiﬁcation. Additionally,

the use of Real numbers and arithmetic on them is

also a known SMT challenge, especially in the con-

text of arrays. We are now in the process of creating

tools to automatically translate SysML models to K

models (and back) and perform analysis on them us-

ing the K infrastructure. This will make it possible to

view a model as graphics as well as in text. The trans-

lation of K needs to be extended to cover more con-

structs, including statements with side-effects. Other

challenges include making K executable, for example

by translation to Scala, including executing OCL-like

expressions; providing support for reﬂection such that

models can query themselves; and making the K lan-

guage and textual notation user-extensible.

REFERENCES

Allen, J. F. (1984). Towards a general theory of action and

time. Artiﬁcial Intelligence, 23:123–154.

Barnett, M., Chang, B.-Y. E., DeLine, R., Jacobs, B., and

Leino, K. R. M. (2006). Boogie: A modular reusable

veriﬁer for object-oriented programs. In Formal meth-

ods for Components and Objects, pages 364–387.

Springer.

Barnett, M., Fähndrich, M., Leino, K. R. M., Müller, P.,

Schulte, W., and Venter, H. (2011). Speciﬁcation and

veriﬁcation: the Spec# experience. Communications

of the ACM, 54(6):81–91.

Barras, B., Boutin, S., Cornes, C., Courant, J., Filliatre, J.-

C., Gimenez, E., Herbelin, H., Huet, G., Munoz, C.,

Murthy, C., et al. (1997). The coq proof assistant ref-

erence manual: Version 6.1.

Bjørner, D. and Jones, C. B., editors (1978). The Vienna De-

velopment Method: The Meta-Language, volume 61

of LNCS. Springer.

Bjørner, D. and Jones, C. B. (1982). Formal Speciﬁca-

tion and Software Development. Prentice Hall Inter-

national. ISBN 0-13-880733-7.

Bobot, F., Filliâtre, J.-C., Marché, C., and Paskevich, A.

(2011). Why3: Shepherd your herd of provers.

In Boogie 2011: First International Workshop on

Intermediate Veriﬁcation Languages, pages 53–64,

Wrocław, Poland.

De Moura, L. and Bjørner, N. (2008). Z3: An efﬁcient smt

solver. In Tools and Algorithms for the Construction

and Analysis of Systems, pages 337–340. Springer.

Europa Clipper Mission (2015). http://www.jpl.nasa.gov/

missions/europa-mission.

Fitzgerald, J., Larsen, P. G., Mukherjee, P., Plat, N., and

Verhoef, M. (2005). Validated Designs For Object-

oriented Systems. Springer-Verlag TELOS, Santa

Clara, CA, USA.

Fortress (2015). https://projectfortress.java.net/.

George, C., Haff, P., Havelund, K., Haxthausen, A., Milne,

R., Nielsen, C. B., Prehn, S., and Wagner, K. R.

(1992). The RAISE Speciﬁcation Language. The BCS

Practitioner Series, Prentice-Hall, Hemel Hampstead,

England.

Gurevich, Y., Rossman, B., and Schulte, W. (2005). Seman-

tic essence of AsmL. Theoretical Computer Science,

343(3):370–412.

Havelund, K. (2011). Closing the gap between speciﬁcation

and programming: VDM

and Scala. In Korovina,

M. and Voronkov, A., editors, HOWARD-60: Higher-

Order Workshop on Automated Runtime Veriﬁcation

and Debugging, volume 1 of EasyChair Proceedings.

Manchester, UK.

K: A Wide Spectrum Language for Modeling, Programming and Analysis

121

Jackson, D. (2012). Software Abstractions: Logic, Lan-

guage, and Analysis. The MIT Press.

Jackson, E. K., Seifert, D., Dahlweid, M., Santen, T.,

Bjørner, N., and Schulte, W. (2009). Specifying and

composing non-functional requirements in model-

based development. In Software Composition, pages

72–89. Springer.

Jones, C. B. (1990). Systematic Software Development us-

ing VDM. Prentice Hall. ISBN 0-13-880733-7.

Jones, C. B. and Shaw, R. C., editors (1990). Case Studies

in Systematic Software Development. Prentice Hall

International. ISBN 0-13-880733-7.

Jones, S. L. P. (2003). Haskell 98 language and libraries:

the revised report. Cambridge University Press.

K (2015). http://www.theklanguage.com.

Kim, S.-K., Burger, D., and Carrington, D. (2005). An

mda approach towards integrating formal and infor-

mal modeling languages. In FM 2005: Formal Meth-

ods, pages 448–464. Springer.

Lausdahl, K., Lintrup, H. K. A., and Larsen, P. G. (2009).

Connecting uml and vdm++ with open tool support. In

FM 2009: Formal Methods, pages 563–578. Springer.

Leavens, G. T., Baker, A. L., and Ruby, C. (1998). Jml:

a java modeling language. In Formal Underpinnings

of Java Workshop (at OOPSLA’98), pages 404–420.

Citeseer.

Leino, R. (2010). Dafny: An automatic program veriﬁer. In

Clarke, E. M. and Voronkov, A., editors, 16th Interna-

tional Conference on Logic for Programming, Artiﬁ-

cial Intelligence, and Reasoning, LPAR 2010, Dakar,

Senegal, April 25–May 1, volume 6355 of LNCS.

Springer.

MagicDraw (2015). https://www.magicdraw.com/.

Meyer, B. (1988). Eiffel: A language and environment for

software engineering. Journal of Systems and Soft-

ware, 8(3):199–246.

Milner, R., Tofte, M., and Harper, R., editors (1997). The

Deﬁnition of Standard ML. MIT Press. ISBN 0-262-

63181-4.

Nipkow, T., Paulson, L. C., and Wenzel, M. (2002). Is-

abelle/HOL: a proof assistant for higher-order logic,

volume 2283. Springer Science & Business Media.

OCaml (2015). http://caml.inria.fr/ocaml/index.en.html.

Odersky, M. (2010). Contracts for Scala. In Runtime

Veriﬁcation - First Int. Conference, RV’10, St. Ju-

lians, Malta, November 1-4, 2010. Proceedings, vol-

ume 6418 of LNCS, pages 51–57. Springer.

OMG (2012). Systems Modeling Language (SysML).

http://www.omg.org/spec/SysML/1.3/.

OMG (2015). UML. http://www.omg.org/spec/UML/2.5/.

Owre, S., Rushby, J. M., , and Shankar, N. (1992). PVS:

A prototype veriﬁcation system. In Kapur, D., edi-

tor, 11th International Conference on Automated De-

duction (CADE), volume 607 of Lecture Notes in Ar-

tiﬁcial Intelligence, pages 748–752, Saratoga, NY.

Springer-Verlag.

PVS (2015). http://pvs.csl.sri.com.

Python (2015). http://www.python.org.

Scala (2015). http://www.scala-lang.org.

SMT-LIB (2015). http://smtlib.cs.uiowa.edu.

Spivey, J. M. (1988). Understanding Z: A Speciﬁcation

Language and Its Formal Semantics. Cambridge Uni-

versity Press, New York, NY, USA.

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

122