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?

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

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

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.

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

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

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.

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.