Popular software modelling notations visualize implementation minutiae but fail to scale, to capture design abstractions, and to deliver effective tool support.

The first version of the modelling language was named LePUS by its inventor, Dr Eden. The LePUS notation only modelled design patterns. LePUS3, the language of Codecharts, was developed by Dr Eden with his research students Dr Notis Gasparis and Dr Jonathan Nicholson.

The formal design description language of Codecharts was tailored to—

• Visualize the building–blocks of object–oriented design
• Create bird’s–eye roadmaps of large programs with minimal symbols and no clutter
• Model blueprints of patterns, frameworks, and other design decisions
• Be exactly sure what diagrams claim about programs and reason rigorously about them

LePUS3, the language of Codecharts, also satisfies the following requirements:

• 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

LePUS3 Website

Design patterns are not programs but blueprints of an implementation, templates which describe the correlations and collaborations between generic participants in a program. Modelling them therefore requires an appropriately generic language.

We define Codecharts, a visual language for modelling the static (decidable) aspects of design patterns, and demonstrate how to verify whether a given Java implementation satisfies the specification of the pattern.

Visualising object-oriented design (OOD) poses several challenges, for example:

• How can the constructs of OOD be best visualised?
• How much of the program should be visualised?

This line of work demonstrates the answers given to these questions.

What is the difference between architecture and design? This distinction is important since the choice of architecture has strategic and far-reaching implications over the implementation and therefore must be made early in the development process, whereas design decisions have localized effect and must be deferred to a latter stage in the process.

We distinguish between three abstraction strata in software design statements:

• Strategic statements include programming paradigms and architectural styles
• Tactical statements include design patterns
• Implementation statements include class diagrams

We define criteria of distinction in mathematical logic and present the Intension/Locality Hypothesis:

1. The class of non-local statements (NL) contains Strategic statements;
2. The class of local and intensional statements (LI) contains Tactical statements;
3. The class of local and extensional statements (LE) contains Implementation statements.

This distinction allows us to prove the Architectural Mismatch Theorem, which formalizes the notion of architectural mismatch (Garlan, Allen & Ockerbloom 1995).

Inconsistency between design and implem entation is a major problem for most programmers. Conflicts are common because there are no effective tools for detecting them. Original design documents are a hassle to update (and nobody bothers with that). Absence of current and accurate design documentation results in software that is unpredictable and poorly understood.
Round-trip engineering tools support an iterative process of detecting conflicts and resolving them by changing either the design or the implementation.

A Toolkit we developed, the Two-Tier Programming Toolkit, supports a round-trip engineering of native Java programs without interfering with any existing practices, tools or development environments, thereby posing a minimal barrier on adoption. The Toolkit includes a user-guided software visualization and design recovery tool, which generates Codecharts from source code. A ‘round-trip’ process is possible because Codecharts visualizing source code can be edited to reflect the intended design, and the Verifier can detect conflicts between the intended and as-implemented design.

Our work has demonstrated how the Toolkit effectively helps to close the gap between design and implementation, recreate design documentation, and maintaining consistency between design and implementation.

Computer science is a broad discipline. Theoretical computer science is very mathematical, whereas software development has all the hallmarks of an engineering activity. Further facets merge with psychology and cognitive science and applications are found throughout the physical sciences and engineering.

The philosophy of computer science is concerned with conceptual issues that arise by reflection upon the nature of computer science. The topics covered reflect the latter’s wide range: What kind of discipline is computer science? What are the roles of design and experimentation? What role is played by mathematics? What do correctness proofs establish? These are only a few of the questions that form the body of the philosophy of computer science.

Our entry on the philosophy of computer science in Stanford Encyclopedia of Philosophy attempts to cast these questions in the context of existing philosophical issues and shed light on the answers that the various branches of computing may offer.