Background for the header
To the home page of the University of Antwerp

 

 

LORE / Teaching / SRe2LIC / Opdracht 2006

Terug naar SRe2Lic.

Context | Opdracht | Resultaat

Context

PMD is een code smell detector. Deze tool heeft extensies voor integratie in Integrated Development Environments (IDE's) zoals Eclipse, IntelliJ IDEA, JBuilder, en vele anderen. PMD gaat na of regels inzake de structuur van een software systeem geschonden worden. Deze regels kunnen op twee verschillende manieren opgesteld worden:

  • Een regel kan geïmplementeerd worden als Visitor van een Abstract Syntax Tree die PMD opbouwt. Hierbij schrijf je eerst navigatie-code om bij de juiste AST-knoop te komen. Vanaf dan kan je een voorwaarde implementeren waaraan die knoop moet voldoen. Uiteraard is het ook mogelijk om meerdere knopen en meerdere voorwaarden te betrekken.
  • Een regel kan gedeclareerd worden als XPath regel. In plaats van de navigatie naar de gewenste AST-knoop te moeten implementeren als een Visitor, kan je deze als een XPath query beschrijven (bv. //FieldDeclaration[@Private='false'] om attributen op te zoeken die niet als private gedeclareerd zijn). Het verschil is hierbij dus dat de navigatie declaratief is.

Meer informatie vind je op de PMD site zelf.

In deze opdracht leggen we de aandacht op de structuur van de geïmplementeerde regels. Aangezien deze regels eigenschappen van AST elementen nagaan (bv. cardinaliteit, visibiliteit, aanwezigheid van structuur-patronen, etc.) is het wenselijk dat er een abstractielaag is tussen de AST zelf en de regels. Je kan een regel namelijk beschouwen als een formule. Hierbij is het normaal dat er meerdere formule's bestaan die erg gelijkaardig zijn. Om deze gelijkaardigheid expliciet te maken, kan je abstracties introduceren die in twee gelijkaardige formule's hergebruikt kunnen worden.

Het principe van hergebruik tussen verschillende regels is reeds uitgeoefend op enkele regels. Zo bevat PMD een aantal Visitors ( ExcessiveNodeCountRule en ExcessiveLengthRule ) die hergebruikt worden in andere Visitors die een bijzonder geval vormen van deze abstracties (bv. respectievelijk ExcessiveImports en LongClassRule ).

Inheritance is echter niet de enige manier om hergebruik te maken. Zo kan je ook bv. compositie gebruiken om functionaliteit te hergebruiken. Wanneer je echter de structuur van de code inzake regels bestudeerd, merk je dat er (buiten de genoemde voorbeelden) haast geen hergebruik is tussen regels. Dit houdt in dat, wanneer je een nieuwe regel wil introduceren die erg gelijkaardig is aan een bestaande regel, je niet anders kan dan via copy-and-paste code over te nemen van een andere regel. Daardoor stimuleer je een impliciet ontwerp, waarin de semantische gelijkaardigheid niet gereflecteerd wordt in de expliciete structuur (bv. via inheritance, compositie, etc.).

Opdracht

Als reengineering-team wordt jullie gevraagd om het regel-deel van PMD te herstructureren teneinde hergebruik tussen regels te optimalizeren.

Daarvoor zullen jullie een aantal technieken moeten toepassen die in de lessenreeks zijn aangeboden. Deze zijn:

  • Analyse:
    • Analyze van duplicate code
    • Dynamische analyze
    • Metrics
    • Visualisatie
  • Herstructurering:
    • Testing
    • Refactoring

Aangezien de schaal van het te herstructuren deel van PMD een pak kleiner is dan die van vorige jaren (ArgoUML en Eclipse), leggen we dit jaar meer de nadruk op een uitgebreide analyse. Daarom vragen we jullie om minstens drie verschillende analyse-technieken te gebruiken teneinde op te sporen hoe hergebruik tussen regels geoptimaliseerd kan worden. Als resultaat van deze analyse komen  jullie dan tot een voorstel tot herstructurering van de code om dit hergebruik te realiseren.

Als tweede deel wordt jullie gevraagd om enkele van deze typische herstructureringen uit te voeren. We verwachten niet dat jullie alle voorgestelde herstructureringen uitvoeren, omdat we willen vermijden dat jullie veel tijd moeten investeren in gelijkaardige en routineuze activiteiten. Daarom is het in het herstructurerings-deel de bedoeling dat jullie aantonen dat de voorgestelde herstructurerings-scenario's realistisch zijn en ook wel degelijk uitgevoerd kunnen worden zonder het gedrag van het software systeem te wijzigen.

Resultaat

Om aan te tonen dat je in deze opdracht geslaagd bent, zal je volgende zaken moeten kunnen aantonen:

  • Je hebt een selectie gemaakt van drie analyse-technieken (analyze van duplicate code, dynamische analyse, metrics of visualitie), en deze drie technieken uitgebreid toegepast om opportuniteiten voor hergebruik te identificeren. Je hebt in je verslag duidelijk aangegeven (bv. via screenshots, resultaten van analyse van de output van technieken) hoe je de resultaten van de analyse-technieken gebruikt hebt om tot voorstellen voor herstructurering te komen.
  • Je hebt de voornaamste voorgestelde herstructureringen uitgevoerd. We verwachten niet dat je alle voorgestelde herstructureringen uitvoert, maar wel dat je, indien er sterke verschillen zijn in deze voorstellen (bv. door de wijze van hergebruik, via inheritance, compositie, etc.) deze verschillende herstructurerings-scenario's hebt uitgevoerd. M.a.w.: je zal slechts een beperkt aantal mogelijke principe's vinden om hergebruik te realiseren. Het herstrureren naar deze stijl van realisatie van hergebruik zal vrij typerend zijn. Daarom heeft het weinig zin om een zelfde stijl van realisatie van hergebruik meerdere malen toe te passen (tenzij er essentiele verschillen zijn).
  • De toegepaste herstructureringen zijn gedragsbehoudend.
    • Je kan de mapping aantonen tussen elk van de klassen uit de oorspronkelijke structuur en de nieuwe structuur.
    • Het compilatie-proces verloopt foutloos.
    • De testen draaien foutloos.
    • PMD werkt foutloos.
  • De toegepaste herstructureringen zijn kwaliteitsverbeterend.
    • Je hebt gelijkaardige structuren of functionaliteiten tussen regels herkent, of hebt geïdentificeerd dat een regel eigenlijk een bijzonder geval is van een meer algemene regel.
    • Je hebt deze gelijkaardigheid, of deze meer algemene regel expliciet gemaakt in het ontwerp.
    • Je kan duidelijk aantonen dat er (a) meer hergebruik is tussen regels; en/of (b) de introductie van gelijkaardige regels aan een bestaande regels vergemakkelijkt werd door de introductie van een te hergebruiken regel (een meer algemene regel).

Vooral het kwaliteitsverbeterende aspect kan je in je projectverslag en verdediging toelichten, door aan te geven dat de resulterende PMD versie wel degelijk de (hierboven beschreven) voordelen van hergebruik vertoont.

Nota: uiteraard is het ook dit jaar mogelijk om eigen project-voorstellen in te sturen. Deze voorstellen zullen door ons worden goedgekeurd indien ze een goede oefening vormen op de reengineering-technieken die we in de lessenreeks gezien hebben. Zo is het steeds mogelijk om bv. een software-systeem dat je voor je thesis, of voor een ander vak hebt geschreven of gebruikt, te reengineeren.

 

Valid HTML 4.01! Valid CSS!

 Lab On REengineering - Antwerpen, last modified 16:22:33 11 June 2007