====== Model Refactoring in UML ======

**Begeleider(s):** [[mailto:rvdstrae@vub.ac.be|Ragnhild Van Der Straeten]] en [[mailto:tom.mens@umh.ac.be|Tom Mens]]

**Promotor:** Prof. Dr. Viviane Jonckers

===== Onderwerp =====

Objectgeoriënteerde analyse en ontwerp heeft de laatste jaren een enorme evolutie gekend. Dit resulteerde in een uniforme taal voor het ontwerpen van objectgeoriënteerde applicaties, nl. de Unified Modeling Language (UML). De visuele representatie van deze taal bestaat uit een aantal diagrammen. De verschillende soorten diagrammen laten ons toe om een softwaresysteem vanuit verschillende oogpunten te bekijken. Verschillende abstractieniveaus worden gebruikt binnen de Software Development Life Cycle (SDLC). Zo een abstractielaag noemen we een model van de applicatie. Binnen een model worden verschillende UML diagrammen gebruikt. De meeste gebruikte in een industriële context en dus de belangrijkste zijn: klassediagrammen, toestandsdiagrammen en interactiediagrammen.

Het ontwerpen van een softwaresysteem is meestal een groepsactiviteit. Verschillende mensen ontwerpen verschillende delen van het systeem. De compositie van deze verschillende delen moet uiteindelijk een consistent geheel opleveren. Naarmate het ontwerp van het softwaresysteem vordert, worden de modellen verder verfijnd, informatie wordt toegevoegd, weggelaten of impliciet gemaakt. Vanzelfsprekend is het noodzakelijk dat de verschillende modellen en de diagrammen binnen deze modellen consistent blijven. Het semantisch verbinden van de verschillende diagrammen, het bijhouden van de verschillende veranderingen en het controleren en garanderen van consistentie tussen de modellen en diagrammen dringt zich dan ook op. State-of-the-art UML CASE-tools [TogetherJ, RationalRose, Poseidon] ondersteunen geen semantische consistentie. Dit resulteert in minder onderhoudbare, minder herbruikbare en minder verstaanbare modellen en diagrammen. Als gevolg hiervan worden de verschillende diagrammen, die het ontwerp van een softwareapplicatie vormen, slechts éénmalig gebruikt bij de eerste implementatie van de software maar worden verder niet meer aangepast en dus in het extreme geval helemaal niet meer gebruikt.

Om de consistentie tussen de verschillende modellen en binnen modellen te behouden gebruiken we een logisch raamwerk dat ondersteund wordt door een reasoning engine Racer [Racer]. De verschillende queries die de verschillende soorten consistentie controleren bestaan reeds op papier.

Refactoring betekent het verbeteren van de structuur van object-georiënteerde software zonder het extern zichtbare gedrag te wijzigen. Deze techniek heeft zijn bruikbaarheid bewezen voor object-georienteerde software ontwikkeling. Ontwikkelingstools ondersteunen echter enkel refactoring van een programma op source code niveau. Er is echter een nood voor het toepassen van refactoring op ontwerpmodellen (model refactoring). [Astels 2002, Boger et al. 2002, Sunye et al. 2001]

===== Stage =====

De stage bestaat uit het implementeren van de logische queries en aldus de bestaande, in zijn kinderschoenen staande versie van ons prototype tool RacCOon te verbeteren en uit te breiden. Eveneens moeten de mogelijkheden tot integratie van deze tool in een bestaande UML case-tool (bvb. Poseidon) onderzocht worden. Op deze manier willen we de student ervaring laten opdoen met het onderzoek dat we reeds rond dit thema gevoerd hebben. Verder wordt er eveneens gevraagd van de student om een literatuurstudie uit te voeren rond model refactorings.

Het uiteindelijk doel is een mooi stuk software af te leveren en een literatuurstudie rond model refactorings.

===== Thesis =====

Het objectief van deze thesis is om ondersteuning te bieden voor de refactoring van object-georienteerde ontwerpen uitgedrukt in UML en dit aan de hand van ons prototype tool RacCOoN. De focus zal gericht zijn op klassediagrammen, interactiediagrammen en toestandsdiagrammen. Meer specifiek zouden de volgende objectieven moeten gehaald worden:

    * een lijst van praktisch bruikbare model refactorings definieren, gebaseerd op 1 of meerder case studies van evoluerende UML ontwerpen,
    * de model refactorings moeten geïmplementeerd worden en gevalideerd in RacCOoN geïntegreerd in een UML tool (bvb. Poseidon)
    * ook de verschillende gedragsbewarende eigenschappen van model refactorings zouden duidelijk beschreven moeten worden... 

===== Vereiste Voorkennis =====

    * Een goede voorkennis van Java is wel nuttig.
    * Basis kennis OO.
    * Basis kennis UML.
    * Kennis van bvb. Poseidon zou ook nuttig zijn maar niet noodzakelijk. 

===== Referenties =====

[TogetherJ] http://www.togethersoft.com\\
[RationalRose] http://www.rational.com/\\
[Poseidon] http://gentleware.com/\\
[Astels 2002] Dave Astels. Refactoring with UML. Proc. 3rd Int'l Conf. eXtreme Programming and Flexible Processes in Software Engineering, pp. 67-70, 2002\\
[Boger&al 2002] Marko Boger, Thorsten Sturm, Per Fragemann. Refactoring Browser for UML. Proc. 3rd Int'l Conf. on eXtreme Programming and Flexible Processes in Software Engineering, pp. 77-81, 2002\\
[Sunye et al. 2001] G. Sunyé, D. Pollet, Y. LeTraon, J.-M. Jézéquel. Refactoring UML models. Proc. UML 2001, LNCS 2185, Springer Verlag 2001\\
[Racer] http://www.sts.tu-harburg.de/~r.f.moeller/racer/