Refactoring 1: het aanpassen van het generieke model.

Transcriptie

1 Refactoring 1: het aanpassen van het generieke model. Nog even voor de duidelijkheid een globaal overzicht van de oude opbouw van de RevJava applicatie: User Interface Parser Critcs en properties files Parser model Reader Meta-Model Figuur 1: de opbouw van de RevJava applicatie. De reader krijgt een classpath binnen waarin.class of.jar files staan. Deze worden door de parser omgezet in Java entiteit objecten. Deze vormen het model. Hiermee wordt dus het oude Java specifieke model gevuld. In figuur 1 staat het oude RevJava model. Dit model is gebaseerd op gecompileerde Java code. We hebben een model ontwikkeld dat zoveel mogelijk programmeer talen kan representeren. Dit generieke model is gebaseerd op gecompileerde dotnet code (Msil) en gecompileerde Java code. In figuur 2 staat globaal de nieuwe situatie. User Interface Critcs en properties Java files Java Parser MSIL files MSIL Parser Meta-Model MSI Java Reader Figuur 2: Het model is nu in 3 delen gesplitst: Java specifiek, Msil specifiek en het generieke model. De Msil parser zullen we later pas gaan implementeren, dus het msil specifieke model wordt na de eerste refactoring nog niet gebruikt.

2 Aan het critics gedeelte zal ook nog o weinig mogelijk veranderd worden. Wel is alles zoveel mogelijk gebaseerd op het generieke model. Dus wanneer het model gevuld is vanuit de reader zullen de operaties op het model op het generieke model werken.

3 1. Het nieuwe meta-model Het nieuwe meta-model bestaat uit de volgende classes en packages: Package: nl.serc.revs.core.model Dit package bevat de generieke elementen (voornamelijk interfaces) van het meta-model. Elementen waarvan de naam met Gen begint worden gespecialiseerd naar MSIL en Java elementen in het model. Hierop zijn twee uitzonderingen: ModelFactory en DeploymentUnit. Dit soort elementen bepalen ook het generieke gedrag van de elementen. Op dit niveau moeten de meeste critics gaan werken. Specifieke MSIL of Java eigenschappen van elementen zitten in de J/Il specifieke elementen van het meta-model. - Argument.java: Een argument (parameter) van een methode. Dit een subclass van Variable.java. - CodeBlock.java: CodeBlock is toegevoegd. Het codeblock van een methode. Bevat lokale variabelen en operaties. Een codeblock is precies wat de naam aangeeft: een block code van die methode. Een CodeBlock wordt geimplementeerd door CodeBlockImpl. Een CodeBlock heeft de volgende fields en methoden: o een GenMethod holder: de methode die dit codeblock bevat. Een get/set methode hiervoor is aanwezig. Aangezien een codeblock geen specialisatie heeft naar MSIL en Java maakt deze gebruik van GenMethod. o een Vector locals: de lokale variabelen van de methode. Een get methode is hiervoor aanwezig welke de vector returnt. o een Vector typeoperations: de typeoperaties van de methode. Een get methode is hiervoor aanwezig welke de vector returnt. o Verschillende methoden om in de type operaties en lokale variabelen te zetten wat hun containing codeblock is. Deze heten allen grabholdof() met als mogelijke parameters: een vector van LocalVars od TypeOperations of een enkele LocalVar of TypeOperation. - CodeBlockTags.java: De modifiers (static,synchronized) die op een block code gedefinieerd kunnen zijn. - CritiquedElement.java: Een element in het meta-model waar critics op te definieren zijn. In het originele model was dit JcritiquedElement. - GenDeploymentUnit.java: GenDeploymentUnit is toegevoegd. (nl.serc.revs.core.model. GenDeploymentUnit). Het geeft het fysieke element weer van de programmeertalen. In MSIL de IlAssembly, in Java de JJar. Het neemt in wezen voor een gedeelte de functie van het oude JSystem over. - ElementTags.java: In het oude model Jtags. Deze class draagt zorg voor het beheer van de tags zoals public, static, protected e.d.. Het is de super van TypeTags, FieldTags, MethodTags, PropOrEventTags, VariableTags en CodeBlockTags. Het voordeel van deze opdeling is dat duidelijk is welk element welke tags kan hebben, en tijdens het draaien van het programma kan er geheugen bespaard worden. Tags zijn generiek en worden zowel voor Java als MSIL gebruikt. - Feature.java: JTypeElement heet nu Feature, aangezien methoden en fields eigenlijk de features van een class zijn. Feature is ook de superclass van GenEvent en GenProperty. Een type bevat Features zoals methodes, fields, events en properties. - FieldTags.java: Modifiers die op een GenField van toepassing kunnen zijn. - GenClass.java: De superclass van IlClass en Jclass, bevat de generieke methodes voor die twee. - GenElement.java: Het basis element voor alle model elementen. Zijn toegevoegde functionaliteit is vooral gebaseerd op het beheren van de properties. van de elementen in het meta-model. Deze class heette in het originele model Jelement. - GenEvent.java: Een event binnen een Type. Is een subclass van Feature. - GenField.java: Een field van een Type. Is een subclass van Feature. - GenInterface.java: een Interface, is de superclass van JInterface en IlInterface en bevat de generieke methodes hiervoor. - GenMethod.java: Een methode van een Type, is de superclass voor IlMethod en JMethod en bevat de generieke methodes hiervoor.

4 - GenNamespace.java: De superclass van JPackage en IlNamespace - GenProperty.java: geeft een property binnen een Type aan. Is een subclass van Feature. - GenRepository.java: Bevat referenties naar de geladen systemen, is de superclass van JRepository en IlRepository. - GenSystem.java: Bevat referenties naar de geladen DeploymentUnits. Superclass van JSystem en IlSystem. - GenType.java: Superclass van GenClass,GenInterface,JType en IlType. - IdElement.java: Een element met een unieke id, gegenereerd door de GenRepository. De id wordt door de repository geproduceerd. In het oude model JidElement. - JESet.java: Beheert sets van GenElements - LocalVar.java: Een lokale variabele in de codeblock van een methode. Dit is een subclass van Variable. - MethodTags.java: de modifiers welke op een methode gedefinieerd kunnen zijn - ModelFactory.java: Een factory voor het aanmaken van Geneireke elementen zoals de operaties en de variabelen. ModelFactory is de super van JmodelFactory en IlModelFactory. ModelFactory maakt de generieke elementen aan, JModelFactory de Java specifieke elementen en IlModelFactory de MSIL specifieke elementen. - NamedElement.java: Een element met een naam, bevat de getname() methode. In het oude model JNamedElement. - NullElement.java: Geeft een null element aan tijdens het afleiden van de properties als er geen element kan worden gevonden. - OpCall.java: Een TypeOperation: methode aanroep - OpCheck.java: Een TypeOperation: checks als instanceof of casts - OpCreate.java: Een TypeOperation: instantie creaties - Operation.java: Superclass van TypeOperation. - OpFieldRef.java: Een TypeOperation: field manipulaties - PropOrEventTags.java: De modifiers die op een property of event gedefinieerd kunnen zijn. - Props.java: Ieder element heeft een JProps waarin de properties voor dat element bijgehouden worden. - TaggedElement.java: JTaggedElement heet nu TaggedElement. Tevens heeft TaggedElement een implementatie TaggedElementImpl gekregen, met o.a. de methode hastag(string key) die standaard false retourneert en geherdefinieerd kan worden in de subclasses. - TypeOperation.java: JTypeElementPart heet nu TypeOperation. Het is het supertype van alle type-operaties in een methode body. Er is een nieuwe interface Operation als super class toegevoegd, welke zelf een subclass van GenElement is. OperationImpl implementeert deze interface Operation. Operation is toegevoegd omdat er naast TypeOperations ook ander soort Operations zijn zoals b.v. returnstatements e.d. In de toekomst zouden dit soort operaties wel eens nodig kunnen zijn en nu kan men deze makkelijk toevoegen.typeref.java: een holder van een referentie naar een type. - TypeTags.java: Modifiers die op een GenType gedefinieerd kunnen worden. - UndefinedValue.java: Als een object null is: niet gedefinieerd - Variable.java: De superclass van LocalVar en Argument. - VariableTags.java: JVariable heet nu Variable. Modifiers die op een Variable gedefinieerd kunnen zijn (vooral voor msil toegevoegd). Tevens is het nu een subclass van TaggedElement, en is het de superclass van LocalVar en Argument. Hierin kunnen respectievelijk de lokale variabelen en de methode-argumenten in opgeslagen worden. Het zijn TaggedElements, maar deze eigenschap wordt momenteel met het inlezen van Java bytecode niet ondersteund. Package nl.serc.revs.core.model.impl Dit package bevat de implementaties van de generieke elementen van het meta-model. De volgende implementaties zijn aanwezig: - ArgumentImpl.java - CodeBlockImpl.java - DeploymentUnitImpl.java

5 - FeatureImpl.java - GenClassImpl.java - GenElementImpl.java - GenEventImpl.java - GenFieldImpl.java - GenInterfaceImpl.java - GenMethodImpl.java - GenNamespaceImpl.java - GenPropertyImpl.java - GenRepositoryImpl.java - GenSystemImpl.java - GenTypeImpl.java - IdElementImpl.java - LocalVarImpl.java - OpCallImpl.java - OpCheckImpl.java - OpCreateImpl.java - OperationImpl.java - OpFieldRefImpl.java - Storable.java - TaggedElementImpl.java - TypeOperationImpl.java - VariableImpl.java Van de ElementTags, ModelFactory, UndefinedValue en NullElement zijn geen interfaces maar zijn al een class, daarom is er daarvan geen Impl class in dit package. Package nl.serc.revs.core.model.java Dit package bevat de J-elementen: - JClass.java - JField.java - JInterface.java - JJar.java - JMethod.java - JModelFactory.java: Maakt J-elementen aan. - JPackage.java - JRepository.java - JSystem.java - JType.java: Superclass van JClass of JInterface. Behalve JModelFactory hebben al deze classes een implementatie in package: nl.serc.revs.core.model.java.impl - JClassImpl.java - JFieldImpl.java - JInterfaceImpl.java - JJarImpl.java - JMethodImpl.java - JPackageImpl.java - JRepositoryImpl.java - JSystemImpl.java - JTypeImpl.java Package nl.serc.revs.core.model.msil Dit package bevat de IL-elementen: - IlClass.java - IlModule.java: Een module in de MSIL - IlEvent.java

6 - IlProperty.java - IlField.java - IlInterface.java - IlAssembly.java - IlMethod.java - IlModelFactory.java: Maakt IL-elementen aan. - IlPackage.java - IlRepository.java - IlSystem.java - IlType.java: Superclass van ILClass of IlInterface. Behalve IlModelFactory hebben al deze classes een implementatie in package: nl.serc.revs.core.model.msil.impl - ILClassImpl.java - IlModuleImpl.java - IlEventImpl.java - IlPropertyImpl.java - IlFieldImpl.java - IlInterfaceImpl.java - IlAssemblyImpl.java - IlMethodImpl.java - IlPackageImpl.java - IlRepositoryImpl.java - IlSystemImpl.java - IlTypeImpl.java - Het gehele package.core.model zoals het geimplementeerd is:

7 GenElement Operation ElementTags NamedElement GenRepostitory TypeOperation MethodTags TypeTags PropOrEventTags CritiquedElement JRepostitory IlRepostitory OpCheck OpCall OpCreate VariableTags FieldTags CodeBlockTags IdElement IlModule GenNamespace GenSystem IlSystem JSystem OpFieldRef TaggedElement JPackage IlNamespace GenDeploymentUnit Feature CodeBlock GenType JJar IlAssembly GenClass GenInterface Variable GenField GenMethod JClass IlClass JInterface IlInterface JField IlField JMethod GenProperty IlMethod GenEvent JType IlType LocalVar Argument IlProperty IlEvent Figuur 3: Een overzicht van de implementatie van het meta-model. Generiek, Java-specifiek en Msil-specifiek.

8 2. Aanpak: We hebben ervoor gekozen in eerste instantie de code vanuit de J-classes te kopieren in de generieke classes, en het programma op deze elementen te laten compileren. Hierna zijn waar nodig casts ingevoerd, of types terug gespecificeerd om het programma weer werkend te maken en de java-specifieke gedeelten ook J-elementen te laten gebruiken. Hierna hebben we de classes in het ingelezen model toegevoegd, zoals GenDeploymentUnit en CodeBlock, welke een ingrijpende verandering aan de structuur inhielden. We hebben zo weinig mogelijk veranderingen aan het reader gedeelte en het kritieken gedeelte gemaakt: 1. De Java reader maakt nu een JJar (GenDeploymentUnit) aan die de jar file voor Java class file representeert. Dit gaat nog niet naar wens want er moet per class verzameling een JJar aangemaakt worden, en dat gebeurt (nog) niet. 2. In de namespaces worden de ouder-kind relaties gelegd. Dus package nl.serc.revs heeft als parent (als deze bestaat) nl.serc. 3. De tags zijn opgesplitst naar entiteit. De methode maketags is nu opgesplitst voor de verschillende ElementTags. Bij niet-typetags vervalt de boolean forclass. Misschien moet er een ElementTagsFactory komen die de creatie van de ElementTags op zich gaat nemen. Aan LocalVar en Argument (voorheen JVariable) worden nu ook elementtags meegegeven, dit is in het model weergegeven door ze onder TaggedElement te hangen. In Java zijn deze leeg aangezien de BCEL java bytecode parser geen tags hiervoor inleest. 4. Er zijn metrics aangepast/toegevoegd om de deployment unit toe te kunnen voegen. Er zullen voor het toevoegen van MSIL zeer waarschijnlijk aanpassingen moeten plaatsvinden in de model structuur van de visitors en aan de properties en critics. We zijn nog niet in staat dit precies te overzien, dit moet beter onderzocht worden en zal dus binnen de vervolgopdracht vallen die met de critics aan de slag gaat. We hebben zoveel mogelijk als we konden overzien met betrekking tot de invoer van MSIL code geimplementeerd. Dit houdt in principe in dat de specifieke Il-elementen binnen het model een (her)implementatie hebben zover die ten opzichte van de J-elementen verschilt. Sommige Il-specifieke elementen waarvan we nog niet precies weten hoe die in het metamodel moeten worden toegevoegd, b.v. pointer => ispointer(), hebben we slechts in de Genclasses geimplementeerd en ze daar voor Java een default waarde gegeven. Toen het model in het programma geimplementeerd was hebben we ons programma naast de nieuwste RevJava release (0.8.5) gedraaid op dezelfde Jar file en de uitkomsten naast elkaar gelegd. Als ontwikkelomgeving gebruikten we Eclipse, voor versie beheer een CVS tool voor DOS.

9 Dubbele code: Duplicaat code hebben we zo veel mogelijk vermeden, echter in enkele gevallen was het onvermijdelijk het te gebruiken. Methode hastag() in de GenMethod GenType GenField GenEvent GenProperty GenVariable CodeBlockImpl vanwege de verschillende soorten elementtags die ze meekregen. Default returnt de methode false in TaggedElement. De access-modifier methoden staan zowel in Feature en Gentype i.v.m. de beschikbaarheid van de hastag() methoden. De ontworpen overervings-structuur van de ElementTags was niet geheel mogelijk omdat er veel statische elementen in de class ElementTags zaten. Dit bracht dubbele code met zich mee. Problemen/Todo: De BCEL bytecode parser die gebruikt wordt voor Java leest geen modifiers in voor methode argumenten en lokale variabelen. Dit houdt in dat voor het Java specifieke gedeelte dit niet beschikbaar is. De elementen krijgen een lege set ElementTags bij de creatie vanuit Java invoer. De java parser moet uitgebreid worden voor de naam van de class file verzamelingen (zoals de jar files). Dit nodig om de DeploymentUnits te kunnen scheiden. Op dit moment is er maar één DeploymentUnit per system. Wanneer er in verschillende DeploymentUnits dezelfde namespace voorkomt moet deze gemerged worden in GenSystem.

10 3. Aanpassingen aan het meta model Gedurende de implementatie waren we vanwege praktische redenen gedwongen enkele kleine veranderingen aan het door ons ontworpen model te maken. GenDeploymentUnit is een subclass van CritiquedElement geworden. Eerst had GenDeploymentUnit geen super gekregen. JType en IlType zijn subclasses van GenType. IlEvent en IlProperty zijn toegevoegd onder GenEvent en GenProperty. We hadden eerst gedacht dat we wel af konden met generieke events en properties, maar om het geheel overzichtelijk en consistent te houden, hebben we ervoor gekozen om deze classes en interfaces toch toe te voegen. Omdat we ervan uit moeten gaan dat ook interfaces andere interfaces kunnen implementeren, hebben we de JESet interfaces van GenClass omhoog gerefactored naar GenType. Voorheen waren we ervan uitgegaan dat interfaces geen andere interfaces implementeren maar Gert was het hiermee niet eens. LocalVars en TypeOperations hebben ook weet van hun methode holder. Deze wordt in GenMethod gezet door het opvragen via de get-methode en dan via grabholdof (in GenMethod) wordt setcontainingmethod() aangeroepen. Dit houdt in dat CodeBlock eigenlijk vooral als doorgeefluik fungeert. Een CodeBlock zou handig kunnen zijn wanneer in de toekomst de code (gedecompileerd) van een methode erbij opgeslagen zou gaan worden. Nu we een codeblock hebben geintroduceerd kan dit in de toekomst ook gebruikt worden om b.v. statische blokken code in types aan te geven. Om o.a. deze reden is CodeBlock een subclass van TaggedElement. Geheel kloppen doet dit niet aangezien een codeblock dan subclass van NamedElement is, maar een codeblock eigenlijk geen naam heeft. LocalVar heeft de volgende extra methoden t.o.v. Variable: public void setcontainingcodeblock(codeblock container): zet het codeblock waartoe de LocalVar behoort. public CodeBlock getcontainingcodeblock():get het codeblock waartoe de LocalVar behoort. public boolean ispointer(): in MSIL kan een LocalVar een pointer zijn. Operation wordt geimplementeerd door OperationImpl en deze bevat de volgende methoden en fields: GenMethod holder: met get/set methoden CodeBlock container: met get/set methoden

11 4. Relaties in het model Onderstaande figuren geven een beeld van de bevat relaties in het meta-model, met als extra verduidelijking een paar inheritance relaties. Deze diagrammen zijn niet heel gedetailleerd, maar geven een beeld van hoe het meta-model in elkaar steekt. Figuur 4: de bevat relaties op het generieke deel van het model (en stukje inheritance). GenTypes hebben geen GenEvents en GenProperties, maar slechts GenFields en GenMethods. Wanneer dit wel het geval zou zijn zou men deze aan een JType kunnen opvragen, terwijl een JType geen events en properties kan hebben. Figuur 5: de bevat relaties op het Java deel van het model (en stukje inheritance). Java heeft geen events en properties.

12 Figuur 6: de bevat relaties op het MSIL deel van het model (en stukje inheritance). Hier is te zien dat in MSIL de namespaces in een module bevat zijn. Aangezien de module weinig behaviour heeft (is gewoon een holder-object) is deze gestippeld weergegeven. Verder bevat een IlType ook IlEvents en IlProperties.

13 5. Gevolgen voor reader en critics Om het inlezen en het verwerken van de properties en critics iets beter te begrijpen zullen we beschrijven hoe door de sofware een project gestart, ingelezen en bekritiseerd wordt. 5.1 Reader In JEProject wordt een project geïnitieerd. Daar wordt de repository aangemaakt en geconfigureerd. Deze Repository bevat feitelijk de gehele boomstructuur van de ingelezen class files. Tevens wordt er een JFilteringLoader aangemaakt. Deze JFilteringLoader leest met behulp van de FastAnajaReader alle geselecteerde classes in. De JFilteringLoader bekijkt welke classes er wel en niet geladen kunnen/moeten worden. In de methode loadall(pset names) wordt aan de reader gevraagd een verzameling namen van classes in te lezen. Daar wordt tevens het main JSystem (de geselecteerde files) en het import JSystem (de classes waarnaar de ingelezen classes verwijzen) aangemaakt. Na het inlezen van de classes draagt de JFilteringLoader zorg voor het cross referencen. Het echte parsen gebeurt met behulp van de Byte Code Engineering Library, geïnitieerd door Markus Dahm. (Zie: Het cross referencen gebeurt in 2 stappen. Bij de eerste stap wordt een JXRefDeriver aangemaakt. Het main JSystem accepteert via het visitor pattern een JPostTraverser die een instantie van de JXRefDeriver beheert. De JPostTraverser vertelt de JXRefDeriver welke elementen hij moet bezoeken. Die weet bij het bezoeken van een entiteit precies wat er gedaan moet worden. Zie ook figuur 7. Wanneer een entiteit bezocht wordt, beslist deze over welke entiteiten erna bezocht gaan worden. Hij bezoekt respectievelijk: 1. Systems: in visitsystem(jsystem s) wordt niets gedaan. 2. DeploymentUnits: in visitdeploymentunit(jjar j) wordt (nog) niets gedaan, maar omdat de visit methoden de visitor doorsturen naar de sub-entiteiten (in dit geval de namespaces), moet deze functie wel toegevoegd worden. 3. Namespaces: in visitnamespace(jpackage p) wordt de parent (en dus ook de child) namespace gezet. 4. Classes en Interfaces: visitinterface(jinterface i) en visitclass(jclass c) doen precies hetzelfde. Eerst worden de supers en geïmplementeerde interfaces als bekende types geregistreerd. Daarna wordt aan het super type verteld dat dit een subclass van hem is. Tevens wordt de impementer van al de geïmplementeerde interfaces geset. Vervolgens wordt deze methode recursief aangeroepen voor de superclass en de interfaces. De Fields en Methoden zijn als laatste aan de beurt. 5. Fields: visitfield(jfield f) registreert het type van het field. Vervolgens wordt ook dit type nog een keer bezocht. 6. Mehoden: visitmethod(jmethod m) registreert de bekende typerefs van een methode, zoals het return type, exceptions, argumenten en lokale variabelen. Vervolgens worden achtereenvolgens de TypeRef die bij het return type hoort, de argumenten, de lokale variabelen en de operaties van de methode, bezocht. In de tweede cross referencing stap wordt door de entiteiten een JPostfixTraverser aangemaakt die een JAdditionalRelationDeriver beheert. De laatste voert de volgende opdrachten uit: 1. Voor alle types worden de inner en outer types berekend. 2. Er wordt voor gezorgd dat alle methoden in de super types ook in de sub types bekend zijn. 3. De field referenties van de super classes worden gezet. 4. Er wordt geprobeerd om nog zoveel mogelijk in OpCall de aangeroepen methode te vinden.

14 Figuur 7: Het visitor pattern zoals dit gebruikt wordt bij het cross referencen. Elke entiteit bekijkt in de methode do[entiteit]() welke referenties geset moeten worden voor dit element. Tot nu toe is er zo weinig mogelijk aangepast aan het inlees gedeelte. De methode maketags(int access_flags, boolean forclass) had als return een JTags. Nu JTags veranderd is in ElementTags en ieder TaggedElement een aparte ElementTags heeft is de methode gespecialiseerd naar de tags welke er gegenereerd moeten worden: maketypetags(int access_flags, boolean forclass) makemethodtags(int access_flags) makefieldtags(int access_flags) Wanneer er ook PropOrEventTags, VariableTags en CodeBlockTags aangemaakt gaan worden is het misschien het beste deze elementen in een TagsFactory aan te maken. Omdat de methode maketags() veranderde werd ook het aanmaken van de elementen veranderd en er werd de methode makecodeblock() toegevoegd: CodeBlock makecodeblock(localvar[] vars, TypeOperation[] ops) We hebben zoveel mogelijk geprobeerd de reader implementatie met rust te laten, echter op een paar plaatsen moesten er wat aanpassingen gedaan worden. De Java reader maakt nu een JJar (GenDeploymentUnit) aan die de jar file voor Java class file representeert. Dit gaat nog niet naar wens want er moet per class verzameling een JJar aangemaakt worden, en dat gebeurt (nog) niet. In de namespaces worden tijdens het cross ereferencen de ouder-kind relaties gelegd. Dus package nl.serc.revs heeft als parent (als deze bestaat) nl.serc.

15 5.2 Critics Na het initialiseren van de repository wordt er een PropertyManger, een PluginManager en een MetricManager geïnitieerd: JMetricManger zorgt ervoor dat alle metrics voor alle entiteiten gevonden worden. JPropertyManager zorgt ervoor dat alle properties die in JBaseProperties, AllProperties en MetricProperties staan gevonden worden. JPluginManager zorgt ervoor dat alle critics-plugins die in de configuratie file van RevJava gedefinieerd staan, gevonden worden. In een later stadium zal deze file gesplitst worden; er komt een config file voor de generieke kritieken en voor elke taal een afzonderlijke file met taal specifieke kritieken. Nadat alle types ingelezen zijn wordt vanuit het project gezorgd dat de metrieken berekend worden (dit gebeurt in de methode collectcritics()). Hier wordt een JCriticCollector aangemaakt. Deze haalt uit de JCriticsManger alle critics per entiteit. Daarna wordt met behulp van het visitor pattern deze JCriticCollector door de hele boom toegepast op de gewenste entiteiten. Hieronder een globaal schema van hoe dit werkt: Figuur 8: Het visitor pattern zoals dit gebruikt wordt bij het toepassen van de critics. Elke subclass van critiquedelement bekijkt in de methode calculatecriticismsforcritics(vector critics) welke critics overtreden worden. Deze violations worden in een Vector terug gegeven.

16 Omdat nu alleen nog maar Java files ingelezen worden is er nog niet heel erg veel veranderd aan de properties en critics. We hebben zoveel mogelijk geprobeerd alles generiek te maken. Dat betekent dat alle visitor classes alleen de generieke entiteiten bevatten.