Legend

Key to LePUS3 and Class-Z Symbols

Print this document

This document describes the visual vocabulary of LePUS3 and Class-Z that captures the abstract building-blocks in object-oriented design. It gives a brief and informal summary of each term, relation and predicate symbols used in LePUS3 and Class-Z formulas. It does not include formal definitions, which are given in the LePUS3 and Class-Z Reference Manual.

See also:

LePUS3 Vocabulary

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

LePUS3 Vocabulary

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:

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 Concrete collections modelled using 0-dimensional constants
1-dimensional hierarchy constant A set of classes which contains one class such that all other classes inherit (possibly indirectly) from it Collections hierarchy illustration
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. Ground formula with a transitive binary relation: Illustration
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. Total predicate in concrete collections Concrete Collections in 0-dimensional terms
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:

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.