LePUS3 Vocabulary

The basic set of symbols used in LePUS3 is illustrated below.

For the precise definitions of this vocabulary please refer to the LePUS3 and Class-Z Reference Manual.

Some basic terminology

Terms stand for entities, such as classes (as defined in Section 2) and methods (as defined in Section 3 below). Formulas specify constraints on the entities, where ground formulas specify properties and relations between individual entities (see Section 4 below) and predicate formulas specify relations between sets of entities (see Section 5 below.)

Each term has a dimension: 0-dimensional terms stand for individual entities (either a class, a method, or a signature) whereas 1-dimensional terms stand for sets of entities. Each term also has a type (see complete list of types in the reference manual), for example:

• Terms of type (0-dimensional class terms) stand for individual classes, whereas terms of type (1-dimensional class terms) stand for sets of classes
• Terms of type (0-dimensional signature terms) stand for individual (method) signatures, whereas terms of type (1-dimensional signature terms) stand for sets of signatures
• -dimensional superimposition terms are of type

The type is a subtype of ; in other words, a hierarchy is also a set of classes.

For the precise definitions of this vocabulary please refer to the LePUS3 and Class-Z Reference Manual.

Modelling specific (sets of-)classes and class hierarchies

Constants are terms that stand each for a specific class, a (method) signature, or a hierarchy, or a set of these entities.

Symbol name	Meaning in Java	Sample Class-Z schema	Sample LePUS3 chart	Illustration
0-dimensional class constant	A class, an interface, or a primitive type			public class LinkedList {...}
1-dimensional class constant	A set of classes, interfaces, or primitive types
1-dimensional hierarchy constant	A set of classes which contains one class such that all other classes inherit (possibly indirectly) from it
2-dimensional hierarchy constant	A set of hierarchies

For the precise definitions of this vocabulary please refer to the LePUS3 and Class-Z Reference Manual.

Modelling specific (sets of-)methods

A method or (a set thereof) is represented by superimposing a signature term over a class term, a combination called a superimposition term:

Term name	Meaning in Java	Sample Class-Z schema	Sample LePUS3 chart	Illustration
0-dimensional superimposition constant	A method with signature which is a member of (or inherited by) class			public interface LinkedList { void add(); }
1-dimensional superimposition constant	A tribe (a set of methods with signatures ) that are members of (or inherited by) class
	A clan (a set of methods with signature ) that are members of (or inherited by) classes in
	A clan (a set of methods with signature ) that are members of (or inherited by) classes in the hierarchy

For the precise definitions of this vocabulary please refer to the LePUS3 and Class-Z Reference Manual.

Modelling properties and simple relations

Properties of individual classes and methods are modelled using unary relation symbols, modelled in LePUS3 as inverted triangles. Relations between individual classes and methods are modelled using binary relation symbols, A formula consisting of a unary or a binary relation symbol and 0-dimensional arguments is called a ground formula.

For the precise meaning of each unary and binary relation symbol in Java see: Abstract Semantics for Java 1.4 Programs

Relation Symbol	Meaning in Java	Sample Class-Z schema	Sample LePUS3 chart	Illustration
	The class/method represented by the argument abstract.			public abstract class AbstractList ...
				interface Collection { ... int size(); ... }
	One static type extends, implements, or is a subtype-of another.			public class vector extends AbstractList implements List ...
	The class represented by the 'from' term inherits (possibly indirectly) from the class represented by 'to' term.			public interface Collection ... public interface List implements Collection ... public class LinkedList implements List ...
	The 'from' method may create instances of the 'to' class (or subtypes thereof).			public String toLowerCase(Locale locale) { … if (…) { … } else { … for (…) { … char[] result2 = new char[…]; …
	The 'from' class has a field of the type of the 'to' class (or subtypes thereof).			public class package {… private URL theURL;
	The 'from' class is (or has a field of)a subtype of Collection, or has an array of (possibly a subtype of) the 'to' class.			public class LinkedList implements List // which implements Collection …
	The 'from' method may cal the 'to' method.			public class Test { public static void main (…) { … if (…) { System.out.print(…); …
Any other relation symbol designating a decidable relation in code is also permitted and modelled in the same manner, including: , indicating a method contains a return statement with a given type (or subtypes thereof); , indicating a method returns new instances of a given type (or subtypes thereof); , indicating a method may throw instances of a given type (or subtypes thereof);

For the precise definitions of this vocabulary please refer to the LePUS3 and Class-Z Reference Manual.

Modelling correlations between sets

Relations between sets of entities are represented using predicates:

Predicate name	Meaning	Sample Class-Z schema	Sample LePUS3 chart	Illustration
ALL	All the entities represented by the 'to' term are in the relation .
TOTAL	Each one of the entities (except abstract methods) in the set represented by the 'from' term is in the relation with some entity represented by the 'to' term.
ISOMORPHIC	Each one of the non-abstract entities in the set represented by the 'from' term can be paired with a unique non-abstract entity in the set represented by the 'to' term so as to satisfy the ground formula with the relation .

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 the precise definitions of this vocabulary please refer to the LePUS3 and Class-Z Reference Manual.

Modelling generic design motifs

Design patterns and generic elements of application frameworks are not tied in to a particular implementation. Their specification therefore requires variables rather than constants. The difference between constants and variables is as follows:

• Constants represent specific entities. Constants are modelled in LePUS3 as filled shapes and in Class-Z using .
• Variables range over entities. Constants are modelled in LePUS3 as empty shapes and in Class-Z using .

In other words, variables are used to specify generic design constraints that are not tied in to any specific implementation. For example, specifications of design patterns use only variables, as demonstrated in the 'Gang of Four' Companion document.

For the precise definitions of this vocabulary please refer to the LePUS3 and Class-Z Reference Manual.