Apposition

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.”

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 implementation analysis high-leveldesign low-leveldesign 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

5. CompositePattern DrawingElt leaf {draw,graphics} * Composite «pattern» Graphic children component Composite Component Leaf composite operation() operation() operation() Picture Example 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() } ...} ...}

6. high-leveldesign view low-leveldesign view code view Vision • Choose “enhanced” implementation as common underlying model • Focus onimplementation • 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 theimplementation model • Representation-independent • Filter relevant information only extra info implementation

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

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]