LePUS3 and Class-Z Reference manual

This document formally defines the elements in the syntax and the semantics of LePUS3 and the Class-Z specification languages. It was designed to satisfy the rigid requirements of mathematical logic, and it is therefore unsuitable for learning LePUS3 and Class-Z. To learn LePUS3 and Class-Z please see the Tutorial. To learn about the background and motivation see the About page. A legend offering a key to the language's symbols is also available.

LePUS3 and Class-Z are the product of the collaborative effort of the authors, based on revisions to the LanguagE for Patterns Uniform Specification—LePUS [Eden 2001]. Class-Z and LePUS3 are equivalent: Every specification in LePUS3 is equivalent to one encoded in Class-Z and vice versa, the difference being that LePUS3 is a visual language (a specification in LePUS3 is called a Codechart) while Class-Z is a symbolic language which borrows the schema notation from the Z specification language [Spivey 1992].

The metalanguage

LePUS3 and Class-Z are defined using classical predicate calculus. It is also easy to show that the both LePUS3 and Class-Z are proper subsets of first-order predicate calculus (see proposition 1). We use the standard language of mathematical logic in defining the semantics of LePUS3 and Class-Z, including model theory, predicate calculus, and elementary set theory. Among others, we use the following symbols which carry their usual meanings:

Symbol	Meaning
iff	if and only if
	Is defined as
	Set membership
	Set union

The Axioms of Class-Based Programs have also been transcribed to formulas in FOPL, using the quantifiers (Forall), (Exists), and the connectives (And), (Or), (implies) with their usual meanings.

For example, the power set of the set is a set of four elements as follows:

For example, since class Vector does NOT inherit directly from (extends or implements) class Object, it would be false to require that

However, Vector does inherit INDIRECTLY from Object directly, so we require that

If you are unfamiliar with mathematical logic or with these symbols we recommend you consult any introductory book on elementary logic and set theory such as [Huth & Ryan 2000].

Semantics

The semantics of LePUS3 and Class-Z consist of an abstract representation of programs in class-based object-oriented programming languages such as Java, C++, and Smalltalk. The picture our semantics provides, a design model, is called the abstract semantics of the program. This simplified representation consists of atomic primitives ('entities of dimension 0') and sets thereof (entities of dimension 1), as well as relations between the primitive entities.

Entities

Entities represent elements of the abstract semantics of a program: classes, methods, method signatures, and sets of these entities.

Each entity has a dimension. We shall be primarily concerned with entities of dimension 0 or 1. An entity of dimension 0 is an atomic primitive (representing either a class, a method, or a method signature in the program), and an entity of dimension 1 is a non-empty, finite set of entities of dimension 0. More generally, a non-empty, finite set of entities of dimension is an entity of dimension . An entity of dimension is called a higher-dimensional entity.

Entity names are written in underlined fixed-size typeface, where lower case names (e.g., , ) are reserved for entities of dimension 0, and capitalized names (e.g., , ) are reserved for entities of dimension 1.

In the abstract semantics of Java, classes of dimension 0 represent classes, interfaces, and primitive types (e.g. int, char, etc.) in the program.

For example, is a class of dimension 0 which represents the class java.lang.Object in the abstract semantics of Java programs.

For example, is a class of dimension 0 which represents the primitive type int in the abstract semantics of Java and C++ programs.

For example, is a class of dimension 0 which represents the interface java.util.Collection in the abstract semantics of Java 1.4.

For example, the set is a class of dimension 1 in the abstract semantics of a Java 1.4 program.

Also, the unary relation is itself also a class of dimension 1.

See more classes of dimension 0 in Example 1 in [Nicholson et al. 2007, Part I]

A 'hierarchy' is therefore a set of classes which includes one 'root' class such that all other classes inherit (possibly indirectly) from it.

For example, any set of two or more classes in Java which includes java.lang.Object is a hierarchy.

See more hierarchies in Example 2 in [Nicholson et al. 2007, Part II].

For example, the abstract semantics of the java.util package shall contain one signature of dimension 0: "size()" which represents the signature of both methods ArrayList.size() and LinkedList.size().

For example, the abstract semantics of the java.util package shall contain one signature of dimension 0: "add(Object)" which represents the signature of both methods ArrayList.add(Object) and LinkedList.add(Object).

For example, if and are signatures of dimension 0 then is a signature of dimension 1.

See more signatures in Java in Example 2 and Example 3 in [Nicholson et al. 2007, Part I].

Unlike methods, signature entities have a dedicated symbols in LePUS3 and Class-Z (e.g., 0-dimensional and 1-dimensional signature constants) whereas method entities have no dedicate symbols for representing them. Instead, we use superimpositions, the advantage is that of being able to represent a large set of methods indirectly using a single signature.

Method entities abstract the procedural units of execution in class-based programming languages: 'methods' in Java and Smalltalk, functions and function members in C++. However Method entities have no dedicated symbol in LePUS3 and Class-Z. Instead, method entities are represented using the superimposition of signature and class symbols, the advantage is that of being able to represent a large set of methods indirectly using a single signature.

See methods of dimension 0 in Java in Example 2 and Example 3 in [Nicholson et al. 2007, Part I].

Relations

For example, the unary relation contains all the classes of dimension 0 in the abstract semantics of a Java 1.4 program, each of which represents a class, interface, or primitive type. Most commonly, the relation will contain at least the entities and in the abstract semantics of any Java program.

See the unary relation in the abstract semantics of a Java program in Example 1 and Example 2 in [Nicholson et al. 2007, Part I].

For example, the unary relation contains all the methods of dimension 0 in the abstract semantics of a Java or a C++ program, each of which represents a method (in C++: a function or a function member).

See the unary relation in the abstract semantics of a Java program in Example 2 and Example 3 in [Nicholson et al. 2007, Part I].

For example, the unary relation contains all those classes of dimension 0 and methods of dimension 0 which represent the abstract methods, abstract classes, and the interfaces in the abstract semantics of a Java program.

See the unary relation in the abstract semantics of a Java program in Example 4 in [Nicholson et al. 2007, Part I].

For example, the binary relation represents the extends, implements, and the subtype relations between Java classes and/or interfaces. For instance, since the Java interface Collection is a subtype of class Object and the interface List implements the interface Collection.

See the binary relation in the abstract semantics of a Java program in Example 5 in [Nicholson et al. 2007, Part I].

For example, the binary relation represents the relation between a class containing a field and the class of the contained field in a Java program (in C++: between a class containing a data member and the class/type of the contained member.)

See the binary relation in the abstract semantics of a Java program in Example 7 in [Nicholson et al. 2007, Part I].

Superimpositions

In LePUS3 and Class-Z, methods have no dedicated symbol. Instead, of the form superimposition terms of the form represent methods by indicating their signature ( ) and and the class in which they are defined ( ). (C++ global functions are represented as methods that are not members of any class, and multiple-dispatch methods in languages such as CLOS can be members of more than one class.)

A 0-dimensional superimposition is an expression of the form , where is a signature of dimension 0 and is a class of dimension 0. The binary operator is a partial functional relation, defined as follows:

If there exists a method of dimension 0 such that and then
Otherwise, if there exists exactly one class of dimension 0 such that for which is defined and then
Otherwise the term is undefined.

Given a signature of dimension 1 and a class of dimension 1, we also define the following 1-dimensional superimposition expressions:

The method of dimension 1 is called a clan.

The method of dimension 1 is called a tribe.

In other words, the superimposition selects the unique method with signature that is either defined explicitly in class or inherited from exactly one other class.

For example, if represents the signature of the method ArrayList.size() and represents class ArrayList then the superimposition represents the method ArrayList.size().

For example, if represents the signature of the method AbstractSequentialList.iterator() and represents class LinkedList then the superimposition represents method AbstractSequentialList.iterator() which class LinkedList inherits from class AbstractSequentialList.

For more superimpositions see Example 4 in [Nicholson et al. 2007, Part II].

Structures

Our notion of semantics is based on finite structures in model theory. A finite structure is simply a pair such that (also called the universe of ) is a finite set of primitive entities (in our metalanguage: entities of dimension 0) and is a set of relations. We extend the traditional notion of a finite structure with the notion of a design model as follows:

A design model is a triple such that:

, called the universe of , is a finite set of entities such that where is a finite set of entities of dimension 0 and is a finite set of entities of dimension 1.
is a set of relations, including:
- The unary relations , , , , and
- The binary relations , , , , , , , , and

is an interpretation function which maps some constant terms to entities in depending on the type of the term:

is a constant term of type	If defined, is a
	class of dimension 0
	class of dimension 1
	signature of dimension 0
	signature of dimension 1
	method of dimension 0
	method of dimension 1
	hierarchy of dimension 1

For superimposition terms, we define:

If defined then is called the interpretation of .

satisfies the Axioms of Class-Based Programs.

Design models supply us with a greatly simplified picture of the program: They abstract the intricate details of the implementation, which are normally buried deep in the source code, and represent them using of primitive entities ('entities of dimension 0') and relations amongst them. In addition, design models supply us with sets of entities ('entities of dimension 1'), which cluster together related classes and related methods.

Our definition of design models extends naturally to include entities of any finite dimension.

See sample design models for Java programs see documents "Abstract Semantics for Java 1.4 Programs" [Nicholson et al. 2007, Part I] and "Sample Models" [Nicholson et al. 2007, Part II].

The following are the Axioms of Class-Based Programs:

Axiom 1: No two methods with same signature (method name and argument type) are members of same class:

Axiom 2: There are no cycles in the inheritance graph:

Axiom 3: Every method has exactly one signature:

Axiom 4: Some dependencies exist between relations as follows:

,
,

The Axioms of Class-Based Programs require that the design model—the abstract representation of a program—does not violate some inherent principles of object-oriented programming.

LePUS3 and Class-Z

This section is concerned with the actual specification languages. Specifications are spelled out using terms, which stand for entities, and formulas, which impose constraints on entities.

Terms

Terms stand for entities. Each term is either a constant or a variable term: Constant terms represent specific entities where, as a general rule, the constant class/signature/hierarchy is assigned to the class/signature/hierarchy entity , and variable terms range over entities. Each term has a type and (term) dimension as specified in the following is a list of symbols for the terms in LePUS3 and Class-Z:

The type is a subtype of ; in other words, every term of type is also a term of type . Note that superimpositions can also mix variables with constants, in which case they yield a method variable of the respective dimension and type.

For sample terms and their semantics see the examples in §1: Terms in [Nicholson et al. 2007, Part II].

Relation and predicate symbols

For each relation we assign the relation symbol . The symbol is assigned to the transitive closure of binary relation . The following relation and predicate symbols are admitted:

Formulas

Let be a unary relation symbol, a binary (possibly transitive) relation symbol, and terms of dimension 0. Then the following are ground formulas:

Ground formulas in Class-Z	Ground formulas in LePUS3
	A unary relation symbol placed over the term
	A binary relation symbol connecting the term to the term

Let and be terms, and terms of dimension 1. Then the following are called predicate formulas:

Predicate formulas in Class-Z	Predicate formulas in LePUS3
	An ALL predicate symbol marked with placed over
	A TOTAL predicate symbol marked with connecting to
	An ISOMORPHIC predicate symbol marked with connecting to

Note that in LePUS3 we do not distinguish between the ground formula and the predicate formula . Since both formulas are satisfied under the same conditions, there is no ambiguity here.

For sample Class-Z formulas and their semantics see the examples in §2: Ground Formulas and §3: Predicate Formulas in [Nicholson et al. 2007, Part II].

Specifications

A specification is either a Codechart, a statement in LePUS3, or a Schema, a statement in Class-Z.

You can find many sample Codecharts in lepus.org.uk/spec/ and in lepus.org.uk/ref/legend.

You can find many sample schemas in lepus.org.uk/spec and in lepus.org.uk/ref/legend.

We also distinguish between two kinds of specifications: those that contain variables and those that do not.

For example, a program is only modelled using closed specifications consisting of 1- and 0-dimensional class, hierarchy, and signature constants.

For example, the specifications of any design pattern, in particular the specifications of all the 'Gang of Four' design patterns are open. (See for example the "'Gang of Four' Companion" [Eden et al. 2007].)

Truth conditions

Truth conditions describe the circumstances in which a specification is satisfied by a design model (also ' models '). We follow the standard Tarski truth condition style, which if satisfied we write

The satisfaction of a specification is first defined for specifications that do not contain variables (closed specifications.) The satisfaction of specifications with variables (open specifications) is defined based on that.

The following notational conventions are used in the definitions below: is a unary relation symbol; is a binary relation (possibly transitive) symbol; , and are 0-dimensional constant terms; , and are 1-dimensional constant terms.

Satisfying closed specifications

An closed specification is satisfied by a design model , written , iff all the terms in have an interpretation in and all the formulas in are satisfied by . The specific conditions depend on the formulas as laid as follows. Detailed verification examples and counter-examples are given the document: "Sample Models" [Nicholson et al. 2007].

For example, the formula is satisfied not only when a member of class is defined inside class but also by a program which defines a member of class which inherits from class inside class .

For example, the ground formula is semantically equivalent to the ground formula .

For sample Class-Z ground formulas and their semantics see the examples in §2: Ground Formulas in [Nicholson et al. 2007, Part II].

For subtyping, see Example 7:B in [Nicholson et al. 2007, Part I].

Predicates offer us means for imposing constraints on the relations that may exist between entities. The conditions for satisfying each predicate formula are defined below using the conditions for satisfying ground formulas.

The truth conditions for predicate formulas are defined below for 1-dimensional term arguments. But 0-dimensional term arguments for predicate formulas are also allowed, where each 0-dimensional term argument is treated as representing the singleton set . For example: iff where .

For example, the predicate formula requires that all the methods in class Collection with a signature represented by the elements of are abstract.

See also Example 15, Example 16, and Example 17 in [Nicholson et al. 2007, Part II].

A TOTAL predicate indicates the existence of a total functional relation from the concrete elements of one set to another. More formally, a TOTAL predicate formula of the form is satisfied by design model iff does not consist solely of abstract methods, and for each entity in that is not an abstract method there exists some entity in such that .

The formula thus indicates that the relation is a total functional relation from the set of entities represented by the first term (with the exception of abstract methods) to the set of entities represented by the second term .

For example, the formula requires that class cls1 and class cls2 have each a member of type Object (or of some class that inherits from it.)

See also Example 18, Example 19, and Example 20 in [Nicholson et al. 2007, Part II].

An ISOMORPHIC predicate indicates the existence of a bijective (1:1 and onto) functional relation between the concrete elements of two sets. More formally, an ISOMORPHIC predicate formula of the form is satisfied by design model iff there exists a pair where and such that:

; and
unless both and are empty.

where and stands for the subset of set which consists of all and only non-abstract entities in .

The formula thus indicates that there exists a subset of the relation which is a bijective functional (one-to-one and onto) relation from the set of concrete entities represented by the term to the set of entities represented by the term .

For example, the formula , if all classes are non-abstract, requires that either that class A1 has a member of class B1 (or of its subtypes) and class A2 has a member of class B2 (or of its subtypes), or that class A1 has a member of class B2 (or of its subtypes) and class A2 has a member of class B1 (or of its subtypes).

See also Example 21, Example 22, Example 23, Example 24, and Example 25 in [Nicholson et al. 2007, Part II].

Satisfying open specifications

The truth conditions for open specifications require the notion of an assignment.

A well-formed assignment associates each variable with a constant of same type and dimension. Assignments are used so as to associate variables in generic specifications, such as design patterns, to constants representing specific elements of concrete programs.

For example, an assignment from the Iterator design pattern [Eden et al. 2007] to the abstract semantics of java.util may read:

We say that the open specification , where are all the (distinct) variables in , is satisfied by a design model under the assignment , written

where is that closed specification which results from the consistent replacement of variable with the constant , ... and the consistent replacement of variable with the constant in the open specification .

For example, let be the specification of the the Iterator design pattern [Eden et al. 2007], design model is the abstract semantics of the java.util package, and be the assignment from to the universe of . Then we write to indicate that java.util satisfies (also 'models' or 'implements') the Iterator design pattern.

Type	Symbol in LePUS3	Symbol in Class-Z	Symbol name
			0-dimensional class constant
			0-dimensional class variable
			1-dimensional class constant
			1-dimensional class variable
			0-dimensional signature constant
			0-dimensional signature variable
			1-dimensional signature constant
			1-dimensional signature variable
			1-dimensional hierarchy constant
			1-dimensional hierarchy variable
			0-dimensional method constant term
			0-dimensional method variable terms
			1-dimensional superimposition (method) constant terms


			1-dimensional superimposition (method) variable terms

Symbol in LePUS3	Symbol in Class-Z	symbol name
		Unary relation symbols
		Binary relation symbols
		Transitive binary relation symbol
		ALL predicate symbol
		TOTAL predicate symbol
		ISOMORPHIC predicate symbol

Abstract

Introduction