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

 

 

Terug naar SRe2Lic.

Project 2004

Herstructureer een bestaand software systeem zodat nieuwe behoeften gemakkelijker geimplementeerd kunnen worden. Merk op dat extra functionaliteit als zodanig niet geimplementeerd moet worden; wel moet het bestaande ontwerp zodanig aangepast worden dat het toevoegen van de nieuwe functionaliteit een spreekwoordelijk fluitje van een cent wordt.

Bestaand software systeem

Wij stellen het volgende project voor

  • Extraheer een standalone Abstract Syntax Tree (AST) component uit de IDE Eclipse. Deze component moet instaan voor code-manipulatie en code-analyse van Java 1.4 broncode op basis van een AST, en als een apart product (los van Eclipse) uitgebouwd worden.

De vereisten voor het te extraheren AST component zijn:

  1. De AST component moet een abstractie bieden van de broncode. Dit betekent dat de component instaat voor het lezen van en schrijven naar .java-bestanden en manipulatie en analyse van Java-broncode ondersteunt.

    Onder manipulatie verstaan we het creëren en wijzigen van model-elementen van de AST (packages, klassen, methoden, attributen,...).

    Onder analyse verstaan we het opvragen van informatie over model-elementen van de AST, alsook van informatie over cross-references tussen model-elementen.

  2. De AST component moet de implementatie van volgende functionaliteiten triviaal maken:
    1. Constructie van een refactoringtool. Deze implementatie zal zowel beroep doen op de manipulatie- als op de analyse-functionaliteit van de AST component. Een voorbeeld van de implementatie van zo'n refactoringtool vind je uiteraard in Eclipse zelf.
    2. Constructie van een XMI beschrijving van broncode. De implementatie zal sterk beroep doen op de analyse-functionaliteit van de AST component.Een voorbeeld van zo'n XMI beschrijving vind je in Generic XMI Support for the MOOSE Reengineering Environment, A. Schlapbach, Universität Bern [PDF| HTML].
    3. Constructie van een metrics tool. Deze implementatie zal enkel beroep doen op de analyse-functionaliteit. Als voorbeeld van het wijde bereik van mogelijke bevragingen geven we volgende lijst metrieken:
      • Package metrics
        • Number of Classes
        • Number of Base Classes (at top of inheritance hierarchy)
        • Number of Interfaces
        • Number of sub-packages
        • Number of other packages referenced
        • Lines of Code
      • Class metrics
        • Lines of Code
        • Number of Attributes (public/protected/private)
        • Number of Methods (public/protected/private)
        • Number of Accessors
        • Depth of Inheritance Tree
        • Maximum Depth of Containment Tree for an object of this class
        • Number of other classes from same/other package(s) referenced
        • Weighted Methods per Class (sum of Cycl. Complexity of methods)
        • Number of other packages referenced
        • Number of disjoint pairs of methods (methods not referring to same attribute)
      • Method metrics
        • Lines of Code
        • Cyclomatic Complexity
        • Number of parameters
        • Number of Local Variables
        • Number of exit points from method (return, exception, System.exit,...)
        • Number of attributes referenced
        • Number of methods from same class referenced
        • Number of methods from other classes from same/different package referenced
        • Number of other classes from same/different package referenced

    Merk op dat we niet van jullie verwachten dat je deze functionaliteit ook daadwerkelijk implementeert. Jouw taak is enkel te verantwoorden dat de implementatie van deze functionaliteit op basis van jouw standalone AST component zeer eenvoudig is.

  3. De code voor de AST component moet zo klein mogelijk zijn, om het onderhoud van de component te minimaliseren. De minimale component bevat dus enkel code die direct of indirect helpt in het invullen van de hierboven beschreven vereisten.

Maar het staat jullie vrij om zelf een project te kiezen. Dit projectvoorstel moet door ons wel goedgekeurd worden, op basis van een gemotiveerde aanvraag.

Groepswerk

Het is toegelaten (het wordt zelfs aangemoedigd) om de opdracht in groep uit te werken, maar groepjes worden bij voorkeur niet groter dan drie personen. Het is wel zo dat de verwachtingen voor het eindresultaat in verhouding staan met de groepsgrootte. Bovendien krijgen alle leden van dezelfde groep in principe hetzelfde eindcijfer.

Eindresultaat

Het eindresultaat van dit project bestaat uit een schriftelijk projectverslag dat toegelicht moet worden tijdens een mondelinge projectverdediging. De mondelinge verdediging grijpt plaats tijdens de normale zittijd. Jij moet zelf initiatief nemen om een afspraak te maken. Het verslag moet een week op voorhand afgegeven worden (mag elektronisch).

Schriftelijk verslag

Volgende onderwerpen moeten aan bod komen in het schriftelijk verslag: (zie ook http://www.lore.ua.ac.be/Teaching/PP1LIC/Project1LIC.pdf)

  • Korte samenvatting (Wie, Wat, Hoe): Voor wie doen we het? Wat was het probleem? Hoe hebben we het aangepakt?
  • Status: Wat heb je gedaan, wat gaat (kan) er nu gebeuren?
  • Wat voor technieken heb je gebruikt op niveau van behoeften analyse, ontwerp, implementatie en testen. T.t.z. hoe heb je de verschillen geidentificeerd tussen de oude en nieuwe behoeftes, tussen het oude en het nieuwe ontwerp ? Hoe heb je de bestaande code omgevormd tot de nieuwe ? Hoe heb je ervoor gezorgd dat deze aanpassingen geen fouten hebben geintroduceerd ?
  • Projectverloop: Overzicht van planning, tijdschema, en tussentijdse problemen.

Mondelinge verdediging

De mondelinge verdediging bestaat vooral uit het bespreken van de oplossingen voor de problemen die jullie tegen gekomen zijn en wat je eruit geleerd hebt. Alles wat je in je projectverslag beweert moet je tijdens de projectverdediging kunnen staven aan de hand van code en electronische documentatie.

Uiteraard drukken jullie je daarbij uit gebruik makende van de juiste terminologie. (cfr . Object-Oriented Reengineering Patterns, Serge Demeyer, Stephane Ducasse, en Oscar Nierstrasz, Morgan Kaufmann, 2002)

Beoordelingscriteria

  1. SELECTIE Om te slagen moet je aantonen dat je minstens in staat bent een bestaand software systeem te herstructureren. (MINIMUMNORM)
    • Je kunt het bestaande ontwerp uit de beschikbare gegevens distilleren (i.e. reverse engineering)
    • Je kunt de bestaande broncode transformeren zodat ze beter geschikt is om de nieuwe behoeftes te implementeren (i.e. refactoring)
    • Je kunt aantonen dat de code transformaties de bestaande functionaliteit niet hebben aangetast (i.e. regression tests)
  2. DIVERSIFICATIE Om goede punten te behalen moet je aantonen dat je het herstructureringsproces zelf onder controle hebt:
    • Welke technieken (reengineering patterns) heb je voor de verschillende fases gebruikt. In hoeverre kun je je keuze argumenteren ?
    • Hoe heb je de nieuwe behoeftes geanalyseerd ? In hoeverre zul je in de toekomst greep kunnen houden op veranderende behoeftes ?
    • Hoe heb je het ontwerp (architectuur) dat je uit de brondcode hebt gedistilleerd gevalideerd ? Hoe heb je dat gebruikt om probleemidentificatie te doen ?
    • Hoe heb je de code transformatie zelf aangepakt ? Waarom zijn die transformaties nuttig in functie van de nieuwe toe te voegen functionaliteit ?
    • Hoe ben je de kwaliteit van je testprocedure nagegaan ? In hoeverre kun je de tijd die je gestopt hebt in het testen verantwoorden ten opzichte van de bestaande functionaliteit en de gemaakte verbeteringen ?
    • Hoe heb je het herstructureringsproces aangepakt ? In hoeverre was je planning en schatting accuraat ? En hoe heb je gereageerd op onvoorziene omstandigheden ?

 

Valid HTML 4.01! Valid CSS!

 Lab On REengineering - Antwerpen, last modified 17:42:52 06 April 2009