1. Apposition
“In order to fill the observed gap between the various phases of the object-oriented software development life-cycle, they should be regarded as different views on a common underlying software model.”
Opmerking: Het onderliggend model hoeft niet per se OO te zijn. Wat zijn de voordelen/nadelen van een OO aanpak?

2. Bijstelling
“Om de waargenomen kloof tussen de verschillende fasen van de objectgerichte software-ontwikkelingslevenscyclus te dichten, moeten deze fasen beschouwd worden als verschillende gezichtspunten op een gemeenschappelijk onderliggend softwaremodel.”

3. The OO Development Life-Cycle
Layered approach to software development
analysis
high-level design
low-level design
implementation
more abstract
more concrete

4. Observed Problem Problem with different underlying models
Need to implement similar tools repeatedly
Need to maintain compatibility between tools
Poor support for reverse and synchronous engineering
Difficult to maintain consistency between layers
architectural drift, software aging, erosion, ...
problems with impact assessment
Reasons
no explicit link from more concrete to more abstract layer
some of the more abstract information is absent in the more concrete layer
architectural decisions & implementation strategies based on non-functional requirements
programming conventions & design patterns
Problems with different underlying models:
Need to implement similar tools. Sometimes, artifacts in different phases require similar tools (e.g. impact analysis, version management, …). If these phases use a different underlying model, these tools need to be implemented several times, for each of the different phases. This unnecessarily leads to increased effort and code duplication.
Incompatibilities in tool chain. When each of the phases uses a different underlying representation, there is an additional complexity of needing to maintain each of these different representations. An example of this problem is that tools used in each of the phases need to work together with tools in other phases. Therefore, their input and output should be compatible. Changes to the output format of the one requires changes to the input format of the other.
Poor support for reverse and synchronous engineering
Difficult to maintain consistency between layers. Cf. problems cited in research literature: impact analysis, architectural drift, software aging, erosion, ... When a change is made to a software artifact in a particular layer, we want to know the impact on software artifacts in more abstract and more concrete layers. For example, which abstract decisions will be invalidated by making a change in a more concrete layer.
Reasons:
No explicit link from more concrete to more abstract layer. Such a link is necessary to know on which more abstract software artifacts the concrete artifacts depend, so that we can know the impact when changes are made to the more concrete elements.
Some of the more abstract information is absent in the more concrete layer. E.g. The reason for choosing a particular implementation strategy, as well as an explanation about the alternatives and why these were not choosen (depending on certain nonfunctional requirements). Similarly for the choice of a particular software architecture. Another example are programming conventions and design patterns, which are used in the implementation model, although they are not explicitly codified there. As a result, it is hard to know when a programming convention or design pattern becomes breached when the implementation code changes.

5. Example Composite «pattern» Graphic DrawingElt Picture Component Leaf
{draw,graphics}
abstract class Graphic() {
abstract void draw() {...};
...}
class DrawingElt():Graphic() {
void draw() {...};
class Picture():Graphic() {
List<Graphic> graphics;
void draw() {
Iterator<Graphic> g(graphics);
for(g.first(),!g.empty(),g.next())
{ g.current()->draw() }
Component
operation()
Leaf
Composite
children *
CompositePattern

6. high-level design view
Vision
Choose “enhanced” implementation as common underlying model
Focus on implementation
most essential part of software dev.
more difficult, time-consuming, error-prone to write
more complex
Enhanced with
more abstract information
bidirectional link between code and abstract info
Define each layer as abstract view on the implementation model
Representation-independent
Filter relevant information only
high-level design view
code view
low-level design view
extra info
implementation
To solve all the above problems, we envision a common underlying software model, where the main focus lies on the implementation layer.
The implementation is the most essential part of the software development, because it is precisely this information that gets compiled into an executable form.
The process of writing and maintaining code is substantially more difficult, error-prone and time-consuming then maintaining more abstract layers.
The information contained in the code is more detailed and more complex than in any of the other layers.
The implementation model needs to be enhanced with
more abstract information that cannot or is not expressed directly in the code
an explicit bidirectional link between the code and this more abstract information
Each layer can be defined as an abstract view on the enhanced implementation model
Each of the views filters the information that is relevant for the specific layer that is being viewed. These filters can be arbitrarily complex.
Views are displayed in a specific way, e.g. a textual or graphical view, even with a view-specific syntax

7. Logic Meta Programming
Enhance implementation code with meta layer
To avoid cluttering code
To enable reasoning about and manipulating the code
Tight symbiosis between code and metalevel
when editing software, meta-information is used to
give feedback on impact of changes
warn about breaches in more abstract layers
metalevel is integrated with software development environment
Use logic meta programming
declarative approach
evidence: promising experiments at our lab
The question that remains is how the implementation model should be enhanced.
The enhancement should be made at metalevel for the following reasons:
it avoids unnecessarily cluttering the code
it allows us to reason about and manipulate the code, either directly or indirectly. (This can also be done without a metalevel, but only if the language is reflective, which can also be seen as a kind of metalevel.)
Nevertheless, there should be a tight symbiosis between the code and the metalevel information. When editing the software (either at code level directly, or in a specific view), the metainformation should enable us to give feedback about the impact of the changes that have been made, e.g. by warning us about certain more abstract (or more concrete) software artifacts that are invalidated. Therefore, the metalevel should be tightly integrated with the software development environment, because the software developer does not have to be aware about the internal representation of the metainformation.
Logic meta programming seems to be a very suitable medium for expressing information at metalevel. Evidence for this can be found in the many promising experiments that have been carried out at our lab recently.

8. Evidence SOUL: declarative reasoning framework for Smalltalk
Automatic detection of design patterns in Smalltalk [Wuyts98]
Detecting breaches of programming conventions when evolving Smalltalk code [Wuyts98]
e.g. “each instance variable should have a corresponding accessor method with the same name”
Checking conformance of Smalltalk code to software architecture [Mens&Wuyts99]
Extracting interaction diagrams from Smalltalk [Richner&al99]
Aspect-oriented programming [DeVolder98]
Code optimisation [Tourwe&DeMeuter99]
As a first set of experiments concerning logic meta programming, Roel Wuyts has implemented a declarative reasoning framework, called SOUL, that allows us to reason about Smalltalk code. The following promising experiments have been carried out with this framework:
As another experiment, Kris De Volder has shown how Logic Meta Programming can be used to deal with issues like Aspect Oriented Programming, by specifying each of the different aspects of a program as separate code fragments in the underlying implementation model, and viewing the resulting weaved code as a view on this implementation.
A similar approach is taken by Tom Tourwe, who uses a declarative approach for code transformation. More specifically, the intention is to automatically transform well-structured, but relatively inefficient code into efficient but much less readable code.Again, the efficient code can be seen as a view on the well-structured one.