About LePUS3 and Class-Z
LePUS3 and Class-Z are formal object-oriented Design Description Languages.
They are formal specification lanaguges for modelling non-functional specifications
representing the design of object-oriented class libraries, design patterns, and object-oriented application frameworks
(What can be modelled with LePUS3).
LePUS3 diagrams ('Codecharts', or simply charts) are axiomatized
as decidable statements in the first-order predicate logic.
LePUS3 is tailored for tool support in fully automated design verification (ie, checking conformance to Codecharts)
and program visualization (ie design recovery from source code),
as demonstrated by the the Two-Tier Programming Toolkit.
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
LePUS3 and Class-Z relate to languages of the following broad categories:
- Object oriented modelling languages (e.g., UML) are (mostly visual)
notations that represent the building-blocks in the design of object-oriented
- 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
- 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
- Logic Visual Languages use diagrams to articulate sentences in mathematical logic.
- LePUS3 is a logic visual language geared towards specifications of object-oriented design.
- 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
- 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
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:
- Individual classes ("classes
of dimension 0") and methods ("methods
of dimension 0")
- Properties of individual classes and methods ("unary
relations") and relations amongst them ("binary
- Sets of classes ("classes
of dimension 1") and methods ("methods
of dimension 1"), in particular dynamically-bound methods
Correlations between sets of classes and methods ("predicates")
LePUS3 and Class-Z were tailored to model these building-blocks in a minimal vocabulary.
- Visuality: Specifications are articulated using a visual language.
- 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
- LePUS3 and Class-Z are
formal specification languages. Each specification (in LePUS3:
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—
- Support early design: A design description language
should offer means for modelling
unimplemented programs without prematurely committing to implementation
- 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
- 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,
- Generic design motifs, such as the
'Gang of Four' design patterns
- 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
JGraph, Microsoft Foundation
Classes (MFC), and Smalltalk-80.
- Application frameworks, such as Enterprise JavaBeans and Java