Objectives

LePUS3 and Class-Z are formal Design Description Languages tailored for the following purposes:

• Scalability: To model industrial-scale programs using small Codecharts with only few symbols
• Automated design verifiability: To allow programmers to continuously keep the design in synch with the implementation
• Visualization (only LePUS3): To allow tools to reverse-engineer legible Codecharts from plain source code modelling their design
• Pattern verification: To allow tools to determine automatically whether your program implements a design pattern
• Abstraction in early design: To specify unimplemented programs without committing prematurely to implementation minutia
• Genericity: To model a design pattern not as a specific implementation but as a design motif
• Rigour: To be rigorous and allow software designers to be sure exactly what Codecharts mean and reason rigorously about them

What can be modelled with LePUS3

Object-oriented programs (Above: collections and iterators in java.util)	Object-oriented design patterns (Above: Iterator pattern)	Object-oriented application frameworks (Above: Java RMI)

Context

LePUS3 and Class-Z relate to languages of the following broad categories:

1. Object oriented modelling languages (e.g., UML) are (mostly visual) notations that represent the building-blocks in the design of object-oriented programs.
   • Unlike UML, LePUS3 and Class-Z a formal language that are unpacked in a subset of the (first-order) predicate logic
   • Unlike UML, Codecharts (specifications in LePUS3) and schemas (specifications in Class-Z) are automatically verifiable
2. Formal Specification Languages are mathematical languages (such as Z, B, and CSP) used to articulate properties of software systems in a language that lends itself to reasoning and verification.
   • Unlike these languages, LePUS3 is a visual language and charts therein are decidable formulas.
   • Unlike these languages, specifications in LePUS3 areautomatically verifiable
3. Logic Visual Languages use diagrams to articulate sentences in mathematical logic.
   • LePUS3 is a logic visual language geared towards specifications of object-oriented design.
4. Architecture Description Languages are non-functional, [semi-]formal specification languages used to represent [architectural-]design decisions, normally associated with tools which integrate specifications with their implementations.
   • LePUS3 and Class-Z are Design Description Languages, not Architecture Description Languages. This means, among others, that LePUS3 is suitable for modelling Java programs and design patterns, not architectural styles.
5. Program Visualization Notations offer a graphical representation of the program in a higher level of abstraction, normally generated by reverse-engineering the source code of the program (see how this is done by the Design Navigator).

The building-blocks of object-oriented design

Object-oriented programs written in languages such as Java, C++, C# and Smalltalk are encoded in text files ('source-code') which span across many files and directories. The size and complexity of these systems render code-level reasoning prohibitive; we cannot afford to design, understand, and use large systems by reading source code. Instead, we employ design abstractions: mental pictures of course-grained class hierarchies and sets of dynamically-bound methods and their interaction. These building-blocks can be coarse or refined, depending on the level of abstraction. A good specification language must allow us to represent these building-blocks at all levels of abstraction (example below).

We contend that a minimal set of conceptual building-blocks of object-oriented design can be observed [Eden 2002], that these building-blocks are amenable to formal analysis (using mathematical logic and finite set theory), and that they can be adequately expressed in a visual formalism (LePUS3). These building-blocks include the following:

1. Individual classes ("classes of dimension 0") and methods ("methods of dimension 0")
2. Properties of individual classes and methods ("unary relations") and relations amongst them ("binary relations")
3. Sets of classes ("classes of dimension 1") and methods ("methods of dimension 1"), in particular dynamically-bound methods
4. Correlations between sets of classes and methods ("predicates")

LePUS3 and Class-Z were tailored to model these building-blocks in a minimal vocabulary.

LePUS3 vocabulary (see also: LePUS3 and Class-Z Legend)

Principles

• Visuality: Specifications are articulated using a visual language.
  • LePUS3 was tailored to visualize the building-blocks of object-oriented design using a minimal vocabulary. LePUS3 is therefore a notation for software visualization, the language of Codecharts that the Design Navigator reverse-engineers from any Java 1.4 program.
• Verifiability: Design specifications can be verified fully automatically by a tool (see: the Two-Tier Programming Toolkit).
  • LePUS3 and Class-Z specifications are turing decidable, meaning that a design verification tool can determine fully automatically whether a given program satisfies the specification, calculating the result in polynomial time and space complexity. In contrast, the main difficulty with other languages has been in the task of proving correctness in practical applications. While formal verification of statements in the majority of formal specification/modelling languages, if possible at all (few specification languages are well-defined, fewer are turing-decidable) is generally a matter of laborious, error-prone manual process.
• Scalability: Specifications should model industrial-scale programs using small Codecharts with only few symbols.
  • One of the biggest impediments to existing modelling notations is the attempt to model the minute details of programs, yielding highly-cluttered diagrams which do not scale. In contrast, the potent abstraction mechanisms in LepUS3 and Class-Z scale well and specifications do not clutter with the size of the program. In particular, small and highly abstract specifications (‘architectural charts’) can be serve as architectural ‘road-maps’ to large-scale software.
• Rigour: A formal definition defines the semantics of specifications, the mathematical relation between specification and programs, and allows us to reason rigorously about specifications.
  • LePUS3 and Class-Z are formal specification languages. Each specification (in LePUS3: Chart, in Class-Z: Schema) stands for a sentence in an axiomatized, recursive (turing-decidable) subset of the 1st-order predicate logic. A semantics is defined using finite structures in mathematical logic, a representation of which (i.e. a relational database of entities and relations) can be generated mechanically from pure source code in programming languages such as Java, C++, and Smalltalk.
• Abstraction: A design description language should be abstract in the following senses: It should—
  1. Support early design: A design description language should offer means for modelling unimplemented programs without prematurely committing to implementation minutia.
  2. Support genericity: A design description language should distinguish between modelling a design pattern (a design motif) from modelling a specific implementation thereof. Unlike UML, LePUS3/Class-Z specifications distinguish between modelling design motifs (such as design patterns) and specific programs. Distinction is made using the standard mathematical distinction between variables and constants.
• Minimality. A Design Description Language should restrict itself to a minimal number of symbols. It need not attempt to model "everything" and avoid the Symbol Safari Syndrome.
  The visual vocabulary of LePUS3 consists only of 15 visual tokens.
• Object-orientation: A Design Description Language should offer expressive abstraction mechanisms that can capture and convey the design of programs and design motifs.
  •  LePUS3/Class-Z specifications can capture and convey object-oriented design decisions in a wide range, including:
    1. Generic design motifs, such as the 'Gang of Four' design patterns
    2. Concrete programs, including open-source and widely-used large-scale software at varying levels of abstraction in a range of object-oriented programming languages, such as Java Foundation Classes (java.awt, java.io.logging, java.util), JDom,  JUnit,  JGraph, Microsoft Foundation Classes (MFC), and Smalltalk-80.
    3. Application frameworks, such as Enterprise JavaBeans and Java Servlets

Examples

All examples

• Enterprise JavaBeans
• Abstract Factory pattern
• Composite pattern and its implementation in java.awt
• The Closable inheritance hierarchy in java.io
• Package java.util.logging
• JDom
• JUnit