Diagrameditor met layoutoptimalisatie

Transcriptie

1 Academiejaar Departement Industriële Wetenschappen BME - CTL Schoonmeersstraat Gent Diagrameditor met layoutoptimalisatie Eindwerk voorgedragen tot het behalen van het diploma van INDUSTRIEEL INGENIEUR INFORMATICA Steven DE GROOTE Promotor: Wijnand SCHEPENS

2

3 Voorwoord Vooreerst wil ik Dhr. Wijnand Schepens bedanken voor het voorstel van dit onderwerp en de begeleiding tijdens de uitwerking ervan. Gedurende de hele loop van het project was er voldoende sturing en vrijheid om tot een goed eindresultaat te komen. Zijn positieve ingesteldheid en persoonlijke interesse heeft tot een beter resultaat geleid dan wat anders mogelijk was. Daarnaast moet ik ook mijn familie bedanken voor de steun en hulp die ze me gaven. Hoewel niet hun vakgebied waren ze er altijd om te luisteren naar mijn frustraties en vorderingen. Hun oprechte mening bij tests of uitleg waren een grote hulp. Verder zijn er nog talrijke medestudenten en vrienden die een voorlopige versie van het programma getest hebben en daarmee waardevolle informatie hebben gegeven over de pijnpunten in het project. Steven De Groote Gent, mei Steven De Groote

4 Abstract Een diagram bestaat uit elementen en relaties. Deze thesis bespreekt de ontwikkeling van een framework en een front end applicatie om dergelijk diagram op te slaan en te bewerken. Beide onderdelen worden geïmplementeerd in Java. In het framework wordt een diagram hiërarchisch opgeslagen in twee gescheiden boomstructuren. Een XML pluginsysteem zorgt hierin voor dynamische uitbreidingsmogelijkheden. De front end laat doorgedreven visueel ontwerp van een diagram toe. Het biedt een visuele boomstructuur en een property inspector voor elk diagramelement. De lay-out van een diagram kan bovendien geoptimaliseerd worden met simulated annealing. Het geïmplementeerde algoritme wisselt knoopposities tot een visueel aantrekkelijk diagram wordt bekomen. Overlappende knopen worden vermeden terwijl de totale taklengte wordt geminimaliseerd. De applicatie kan bovendien de iteraties van het algoritme op het scherm tonen en de gebruiker toelaten tussen te komen tijdens de werking ervan. A diagram consists of elements and relations. This thesis reviews on the development of a framework and a front end application to store and provide editing of such a diagram. Both modules have been developed in Java. The framework is built so that it stores a diagram in a hierarchical form, more precisely in two tree structures. An XML based plugin system provides for dynamic extensibility. The front end application allows for advanced visual design of a diagram. It can display each element in a visual tree structure and makes use of a property inspector to display each element. Moreover, the layout of a diagram can be optimised by simulated annealing. The implemented algorithm switches nodes from their position in order to generate a better formed diagram. Overlapping elements are avoided while the aim is to reduce the total length of the edges in the diagram to a minimum. The front end application can, during the running of the optimisation, visualise each step and allow the user to intervene. 3 Steven De Groote

5 Inhoudsopgave Voorwoord...2 Abstract... 3 Inhoudsopgave... 4 Figurenlijst... 7 Inleiding Project Situering Doelstellingen Technologie Gebruikersplatform Ontwikkelplatform Analyse Diagram als data Structurele eigenschappen Lay-out gebonden eigenschappen Grafisch bewerken Klassenstructuur Framework Boomstructuur Diagram als boom Implementatie Structuur Klassenstructuur Diagramelementen Knopen Takken Relatieve positionering Verbindingspunten bij knopen Principe Conversie Aanknopingspunten aan verbindingen Subdiagram en groepen Scheiden van berekenen en tekenen Positie caching Afhankelijkheden tussen verbindingen Tekenen Infinite layering Delegatie Bézier subdivision Selectie Wijzigingen Serialisatie Generatie Steven De Groote

6 4 Front end Functionaliteit Use-Case diagram Overzicht Invoer en uitvoer Configuratie Bewerken Lay-out Implementatie Klassenstructuur Koppeling met mediator Configuratie en plugin systeem Observable settings XML configuratiebestanden Plugins voor uitbreidbaarheid User interface Algemeen Acties Sneltoetsen en iconen Dynamische menu s Canvas Functie Grafische selectie Elementen verslepen Diagramboom Eigenschappenlijst Overzicht Editors voor eigenschappen Typeconversie Automatische lay-out Overzicht Visualisatie van het verloop Eenvoudige lay-outwijzigingen Knopenreeks uitlijnen Knopen geometrisch positioneren Simulated annealing Methode Vaste knoopposities Verloop Energiefunctie Startwaarden Stopvoorwaarden Tests Interne programmatesten Functionaliteit Automatische lay-out Performantie Externe acceptatietesten Algemeen besluit Referentielijst Steven De Groote

7 8.1 Boeken Electronische bronnen...66 Bijlage I Diagrammen uit de analyse Bijlage II Klassendiagrammen Bijlage III Inhoud cd-rom Bijlage IV Codestructuur Bijlage V Testinformatie van annealing Bijlage VI Lijst van bugs Steven De Groote

8 Figurenlijst Figuur 1 : Voorbeeldiagram Figuur 2 : Structuurboom Figuur 3 : Beknopte klassenstructuur van het framework Figuur 4 : Takvolgorde Figuur 5 : Circulaire afhankelijkheid Figuur 6 : Kubische Bézier (links), kwadratische Bézier (rechts) Figuur 7 : Use cases voor de GUI Figuur 8 : Kernklassen van de GUI Figuur 9 : Mediator pattern in de GUI Figuur 10 : Structuur van de GUI Figuur 11 : Aangepaste editors Figuur 12 : Wijzigen van takeinde Figuur 13 : Wijzigen van lettertype Figuur 14 : Layouter infobalk Figuur 15 : Opwaartse transitie Steven De Groote

9 Inleiding Een afbeelding zegt vaak veel meer dan een stukje tekst. Omdat veel mensen eenvoudiger een afbeelding kunnen onthouden dan een alinea die een aantal verbanden uiteen zet, zijn de meeste technische boeken voorzien van tal van gestructureerde illustraties, ook wel diagrammen genoemd. Als we even denken aan toepassingen als een organigram, stamboom, een elektronisch schema, databankschema, projectplanning, is het duidelijk dat diagrammen bijzonder veel gebruikt worden. In deze thesis verstaan we onder een diagram een soort verzameling van elementen die kunnen verbonden worden met elkaar. Een diagram wordt in deze vorm vooral gebruikt als illustratie en is meestal voorzien van tekst, kleur en allerhande visuele extra s. Omwille van deze esthetische waarde ligt het niet voor de hand om een diagram te ontwerpen. Deze tekst bespreekt hoe een Javaprogramma werd ontwikkeld waarmee grafisch diagrammen kunnen worden getekend. Er werd een uitbreidbare structuur gebouwd waarmee diagrammen kunnen worden opgeslagen. Op basis hiervan kunnen ook andere programma s ontwikkeld worden. Om de functionaliteit van het programma te demonstreren en meteen ook te testen werden zo goed als alle diagrammen in deze scriptie daarmee getekend. De UML schema s en klassendiagrammen werden echter wel aangemaakt met gespecialiseerde applicaties. De codefragmenten in deze scriptie zijn bovendien louter ter illustratie en niet volledig. Vaak is enkel de essentie opgenomen of werd de code vereenvoudigd. Elk fragment werd daarbij voorzien van Nederlandstalige commentaar. De volledige programmacode die tijdens dit project ontwikkeld werd is te vinden op bijgevoegde CD-ROM. Bovendien is daarop ook een volledige API geplaatst die uitgebreide uitleg geeft over de klassen en functies. 8 Steven De Groote

10 1 Project 1.1 Situering Diagrammen kunnen visueel het verband aantonen tussen verschillende objecten. Het is daarbij onbelangrijk of die objecten van dezelfde soort zijn. Elk diagram bestaat uit een aantal elementen die verbonden kunnen zijn met relaties. Het is echter niet alleen de structuur die van belang is, maar ook de grafische vormgeving. Omdat punten en lijnen op zich zelden een betekenis hebben, worden elementen in een diagram vaak voorzien van een vorm, een kleur, tekst of zelfs afbeeldingen. Hoewel het principe vrij eenvoudig is mag het ontwerpen van een gestructureerd diagram niet onderschat worden. Om een diagram duidelijk te maken voor de lezer is de plaats van de elementen van zeer groot belang. Een organigram waarin een bediende boven de directeur-generaal wordt weergegeven leidt al snel tot overbodige verwarring. Wanneer men een diagram ziet, lijkt de structuur vaak vanzelfsprekend, maar de manier waarop men daartoe komt is dat niet altijd. 1.2 Doelstellingen Het is duidelijk dat diagrammen zeer veel gebruikt worden, zowel om een eenvoudig verband duidelijk te maken als om een ingewikkelde illustratie voor te stellen. Om dat ontwerp eenvoudig te maken, werd in dit thesisproject een programma ontwikkeld om diagrammen te ontwerpen. Omdat ook de lay-out bepalend is voor de kwaliteit van het diagram, bespreken we ook een aantal mogelijkheden hoe de lay-out van een diagram kan aangepast worden zodat het eenvoudig wordt om dit snel te begrijpen. Daaronder verstaan we zowel eenvoudige wijzigingen zoals uitlijnen van knopen, als geavanceerde optimalisaties zoals met simulated annealing 1. We stellen als doel het diagram zo te verbeteren dat het zo duidelijk mogelijk wordt voor elke lezer. Voorgaande wordt gerealiseerd door een applicatie in twee lagen. Afgeschermd van de gebruiker bevat de datalaag het eigenlijke diagram met alle informatie nodig zodat het eenduidig is bepaald. Omdat diagrammen echter grafische elementen zijn bevat deze structuur ook informatie over de plaats van de elementen. Deze laag wordt in de rest van deze scriptie besproken als framework 2. 1 Simulated annealing: Techniek die toepasbaar is om combinatorische problemen op te lossen. Wordt hier toegepast om de lay-out van diagrammen te verbeteren (zie 5. Automatische layout). 2 Framework: Een collectie van klassen die functies voorzien om door een cliënt gebruikt te worden. Het is een uitbreidbare beschrijving van een model dat enkel nut heeft wanneer het als component gebruikt wordt in een cliënt applicatie. 9 Steven De Groote

11 Daarbovenop is een grafische schil voorzien waardoor een diagram visueel kan gewijzigd worden. Het is belangrijk in te zien dat deze implementatie slechts een mogelijke gebruikersinterface (GUI) is. Het bepaalt de manier waarop een diagram bewerkt kan worden. Omdat de structuur van het diagram onafhankelijk is van deze van de GUI kan een alternatieve GUI ontwikkeld worden die zich anders gedraagt naar de gebruiker toe. 1.3 Technologie Gebruikersplatform De applicatie werd ontwikkeld voor Java 5 en vereist daarom voor iedereen die het wil uitvoeren een Java 5 virtual machine of recenter. Bovendien is ook nog jdom.jar nodig, een API die eenvoudig schrijven en lezen van XML bestanden vanuit java toelaat. Het wordt in de GUI implementatie gebruikt om de configuratiebestanden te laden en terug op te slaan in een leesbaar formaat. Dit pakket is te vinden op Ontwikkelplatform De volledige ontwikkeling van de applicatie gebeurde in Java. Er werd voor deze technologie gekozen omdat bij eerdere projecten en tijdens een stage al gebruik gemaakt werd van het.net-platform. Sun Java is daarom een nieuwe uitdaging. De ontwikkeling van Java is de laatste jaren sterk versneld en heeft al belangrijke snelheidsverbeteringen opgeleverd in de laatste versie. Java 6 beta is bovendien ook al klaar en belooft opnieuw een grote stap voorwaarts. De technologie zal aan dit ontwikkeltempo zeker niet moeten onderdoen voor.net. Uiteraard dankzij Java is de ontwikkelde applicatie dan ook op elk besturingssysteem uit te voeren. Met de stijgende populariteit van Linux is dit een belangrijk aspect. Alle code, zowel voor het testprogramma als voor de uiteindelijke diagramapplicatie werd voorzien van uitgebreide commentaar. Ook voor ieder package en elke klasse is commentaar voorzien in Javadoc stijl. Dit betekent dat in de API van beide applicaties te vinden op bijgevoegde CD-ROM er voldoende documentatie aanwezig is om de werking van de functies te begrijpen. In die API zijn bovendien alle externe packages, zoals de standaard Java package en de jdom.jar gelinkt zodat de API zeer volledig en bruikbaar is. Bij de ontwikkeling werden onder andere volgende applicaties gebruikt: Java 5 J2SE Development Kit (JDK) en Runtime Environment (JRE) update 6 (gratis): Binnen het programma zelf werd, vooral voor de opbouw van de diagram datastructuur, intensief gebruik gemaakt van de Java Beans 1 specificatie. Uiteindelijk biedt dit niets dan voordelen, gezien de code meer verstaanbaar is 1 Java Bean: Herbruikbare Java component met precies gedefinieerde naamgeving van functies. 10 Steven De Groote

12 voor Javaontwikkelaars en de toegang tot de objecten eenvoudig wordt met introspectie 1. Op deze manier was het mogelijk alle eigenschappen van diagramelementen flexibel op het scherm in de GUI te passen. Eclipse SDK (gratis in Eclipse foundation user agreement ): Ontwikkelomgeving voor Java die het coderen vele malen versnelt. Werkt bovendien een stuk efficiënter en eenvoudiger dan NetBeans. Borland Together Architect 2006 for Eclipse (marktwaarde $5000): Hiermee werden eenvoudig klassendiagrammen aangemaakt uit het codeproject van eclipse. GNU Image Manipulation Program (GIMP) (gratis onder de GNU public licence, GPL ): Bewerken van afbeeldingen en iconen gebruikt in de grafische user interface. PDFcreator (gratis onder GPL licentie): Aanmaken van de pdf s voor scriptie en dergelijke. 1 Introspectie: Dynamische detectie van de methodes en eigenschappen van een Javaobject. 11 Steven De Groote

13 2 Analyse 2.1 Diagram als data Diagrammen kunnen een zeer uiteenlopende structuur hebben. Ze zijn verwant met grafen, zij het dan dat er veel minder beperkingen bestaan voor de elementen. Zo is een graaf beperkt tot knopen die onderling verbonden kunnen worden met takken. Elk van deze knopen heeft hierbij een gelijkaardige inhoud. Een graaf is een soort abstracte gegevensstructuur die ontwikkeld werd om tal van problemen oplosbaar te maken. Gezien het zelf een structuur voor gegevens is kan een graaf op velerlei manieren voorgesteld worden. Op de duidelijkheid na voor de presentatie ervan is de positionering van knopen en takken bij een graaf namelijk onbelangrijk. In diagrammen zijn er echter meer mogelijkheden die niet allemaal voor de hand liggen. Waar een graaf op zichzelf kan bestaan zonder grafische voorstelling, is dit zinloos voor een diagram. Hoewel diagrammen ook kunnen gebruikt worden om gegevens op te slaan (gezien hun verwantschap met grafen), zijn ze in de eerste plaats een voorstelling van die gegevens. Een diagram bevat bijgevolg wel informatie over de lay-out. Posities van knopen, de vorm van verbindingen en andere presentatiegegevens zijn eigen aan het diagram en essentieel om het voor te stellen. Zo is het bijvoorbeeld belangrijk dat een hiërarchische structuur in een diagram ook hiërarchisch voorgesteld wordt. De plaats van de elementen is daarom niet willekeurig. Bovendien zijn diagramknopen geen zelfstandige entiteiten, maar containers: elke knoop is meestal een samenstelling van elementen. Algemeen kunnen we stellen dat een diagram er duidelijk en goed ontworpen moet uitzien. Het heeft met andere woorden zelden zin elke knoop identiek voor te stellen, gezien een lezer niet zal begrijpen wat het diagram voorstelt. Om een inzicht te krijgen in de structuur van een diagram, bijzondere eigenschappen en veel gebruikte manieren om iets voor te stellen, werden bestaande diagrammen verzameld en geanalyseerd. Een deel van die diagrammen is terug te vinden in Bijlage I. De belangrijkste aspecten zijn onder te verdelen in de structurele (2.1.1) en de lay-out gebonden eigenschappen (2.1.2). Gezien een diagram echter een grafische voorstelling is, zijn beide zeer nauw met elkaar verwant Structurele eigenschappen Onder deze groep beschouwen we alle eigenschappen van een diagram die hetzelfde blijven als we de lay-out van het diagram wijzigen. Door knopen te verplaatsen, kleuren te wijzigen en vormen aan te passen, zal geen van deze eigenschappen veranderen. Volgende elementen kunnen voorkomen in een diagram: In knopen komen takken toe en/of vertrekken er takken naar andere knopen. Er kunnen tussen twee knopen bovendien meerdere gelijkaardige verbindingen voorkomen, al dan niet in dezelfde richting. 12 Steven De Groote

14 Een tak is een lijn die een relatie aanduidt. Belangrijk hierbij is dat er niet noodzakelijk twee knopen verbonden worden. Een tak kan immers ook verbonden zijn aan een andere verbinding, of ook een uiteinde hebben waar geen zichtbare knoop aan gekoppeld is. Verbindingen hebben steeds twee of meerdere uiteinden. Ze kunnen meerdere elementen met elkaar verbinden. In sommige uitzonderlijke gevallen komt een diagram voor als subdiagram in een ander. Het wordt dan beschouwd als een soort groep van elementen (knopen en takken) dat binnen het grotere diagram opgenomen wordt en kan verbonden zijn met andere knopen. Deze eigenschappen zijn bijzonder eenvoudig, maar tonen meteen ook de mogelijkheden van een diagram aan. In de ontwikkeling van de editor 1 werd dan ook vooropgesteld dat alle voorgenoemde elementen mogelijk moesten zijn Lay-out gebonden eigenschappen Deze eigenschappen bepalen de manier waarop de structuur voorgesteld wordt. Voor een diagram is dit bijzonder belangrijk gezien een goede voorstelling helpt bij een snel begrip van de voorstelling. De lay-out van diagrammen is sterk uiteenlopend, maar zowel knopen als verbindingen worden meestal gelijkaardig voorgesteld binnen eenzelfde diagram: Het uiteinde van een verbinding wordt dikwijls aangeduid door een pijlvorm, een label of een andere indicatie. Deze kunnen zowel identiek als verschillend zijn bij het einde en het begin van de verbinding. Aan de knoop worden takken dikwijls verbonden aan hoekpunten of aan het midden van een zijde. Bij knopen en takken wordt meestal een label voorzien. De positie ervan is sterk uiteenlopend. In sommige gevallen worden meerdere labels op een knoop voorzien, specifiek aan de hoekpunten of uiteinden. De richting van die tekst hangt in sommige gevallen zelfs af van de richting van de tak. Verbindingen worden aangeduid door een lijntype, kleur, dikte en vooral een vorm. We kunnen een onderscheid maken tussen rechte, rechthoekige (orthogonale), kromme (Bézier, bspline, ) en gebroken verbindingen (polyline). Knopen worden vaak gerangschikt op horizontale of verticale lijnen. Meestal omdat ze verbonden zijn met elkaar door een aantal verbindingen. Algemeen stellen we vast dat verbonden knopen dicht bij elkaar te vinden zijn. Deze eigenschap is bijna altijd van toepassing op alle knopen van een diagram en wordt onder andere gebruikt bij hiërarchische structuren. 1 Editor: front end gedeelte van de applicatie dat gebruik maakt van het framework om grafisch diagrammen aan te maken en te bewerken. 13 Steven De Groote

15 Een knoop wordt voorgesteld door een punt, een afbeelding, een geometrische figuur of een samenstelling van deze elementen. Meestal is daarbij ook een label voorzien. 2.2 Grafisch bewerken Uiteraard bestaan er al een aantal andere programma s die ook toelaten diagrammen aan te maken en te bewerken. De meeste hiervan bestaan bovendien al geruime tijd, waardoor ze al zeer uitgebreide mogelijkheden bieden. Om de best mogelijke gebruikersinterface te kunnen ontwikkelen werden Dia 0.95, Microsoft Visio 2003 en SmartDraw Suite 7.01 uitgeprobeerd. Bij elk van deze programma s zijn een aantal belangrijke tekortkomingen aan het licht gekomen waarvoor deze thesis een betere oplossing biedt: Bij de selectie van een element zijn de eigenschappen van een element niet onmiddellijk duidelijk. Deze moeten eerst opgevraagd worden alvorens de gebruiker ze kan bekijken of bewerken. Dit wordt opgelost met de in besproken eigenschappenlijst. In Dia kan geen enkel element geroteerd worden. Dit is een belangrijk gebrek dat in de thesisapplicatie zelfs nog wordt aangevuld door rotaties afhankelijk te maken van de ouderknoop (zie Relatieve positionering). In Dia is het niet mogelijk om op meerdere plaatsen langs een verbinding een label te voorzien. Voor dat label is het dan zelfs niet mogelijk om die tekst schuin afgebeeld te krijgen. In het ontwikkelde framework zijn met aanknopingspunten aan een verbinding (3.2.5) beide wel mogelijk. Microsoft Visio laat niet toe om zelf, door middel van eigen ontwikkelingen of extra s van derden functionaliteit toe te voegen aan het programma. Het pluginsysteem uit laat dit wel toe. Verder zijn de GUI en een aantal functies voor het bewerken van een diagram in de ontwikkelde applicatie geïnspireerd op deze geteste programma s. Alle functies die voorzien zijn in deze beschikbare applicaties kunnen bovendien geïmplementeerd worden in deze thesisapplicatie door verbeteringen aan te brengen in de GUI en/of het framework uit te breiden met extra klassen. 2.3 Klassenstructuur De structuur van het klassendiagram is bijzonder belangrijk voor een framework. Het moet de mogelijkheid bieden tot uitbreiding zonder dat bestaande klassen moeten aangepast worden. Bovendien mag de aard van de uitbreidingen niet beperkt worden en moet eender welk soort diagram kunnen voorgesteld worden, al dan niet gebruik makend van een dergelijke uitbreiding. Voordat met een implementatie werd gestart werd het klassenschema opgebouwd. Er werden enkel schema s uitgetekend en onderzocht op de mogelijkheden en beperkingen daarvan. Bijna dagelijks werden wijzigingen doorgevoerd. In de eerste versie van de klassenstructuur was er zelfs nog geen sprake van een hiërarchische structuur om een 14 Steven De Groote

16 diagram in op te slaan. Problemen die ontdekt werden in vroegere schema s leidden echter tot deze structuur die heel wat nieuwe mogelijkheden opende. Tijdens deze analyse werd ook een testprogramma ontwikkeld om een aantal mogelijkheden voor grafisch bewerken in Java te verkennen. Ook hiermee werden al snel problemen ontdekt die opgelost konden worden door wijzigingen in het klassendiagram. Het programma, dat ook op bijgevoegde CD-ROM te vinden is, heeft een canvas dat een eenvoudige graaf kan tekenen. Alle knopen zijn cirkels en alle takken rechte lijnen. Grafisch selecteren van elementen werd ook uitgetest doordat de gebruiker knopen kan verplaatsen. Deze ontwikkeling van de klassenstructuur duurde ongeveer twee maanden alvorens met de implementatie van de applicatie te beginnen. Het klassendiagram was op dat moment in grote lijnen definitief, zij het dat er nadien nog enkele benamingen veranderd zijn. De structuur liet in die vorm al toe om een diagram te bevatten met alle structurele en lay-outgebonden eigenschappen die uit de analyse (zie hoger) bleken. De wijzigingen tijdens de implementatie zijn er slechts gekomen vanwege het Java platform of om de mogelijkheden in verband met de hiërarchische opslagstructuur van een diagram (zie 3.1 Boomstructuur) te vergroten. 15 Steven De Groote

17 3 Framework 3.1 Boomstructuur Diagram als boom Zoals eerder al vermeld, is een diagram een vrij complexe, grafische voorstelling met weinig beperkingen voor de knopen. Uit de analyse bleek al dat knopen zo goed als altijd samengestelde elementen zijn. Als we veronderstellen dat blijkt ook uit de analyse dat er altijd één element het belangrijkste is dan is een samengestelde knoop een combinatie van een ouderknoop 1 met een aantal kindknopen 2. Dit aantal kinderen is in theorie zelfs onbeperkt. Belangrijk hierbij is de manier waarop de afzonderlijk elementen samengesteld zijn tot de hele knoop: de ouderknoop en zijn kinderen bepalen samen het uitzicht van de hele node (knoop). De positie van de kinderen is bijgevolg afhankelijk van de ouderknoop en meestal gelijksoortig aan andere knopen in hetzelfde diagram. Figuur 1 : Voorbeeldiagram Toegepast op het eenvoudige diagram in Figuur 1 zijn A, B en C ouderknopen omdat ze onmiddellijk aan het diagram gekoppeld zijn. A en B zijn met elkaar in hun middelpunt verbonden met tak1 waarop een punt X is aangebracht in het midden van de verbindingslijn. Tak 2 toont dan weer een relatie tussen knoop C een eenvoudig punt en het punt X op tak 1. Omdat de positie van het label Uitleg bij de knoop A hoort en tekstlabel bij X hoort, kunnen we die elementen beschouwen als kindknopen van hun ouders. Een diagram bestaat dus uit een aantal samengestelde knopen met daartussen enkele verbindingen. Hoewel dit wel het geval is in dit voorbeeld, vertrekken die verbindingen niet altijd vanuit het middelpunt van een knoop. Het is mogelijk dat een tak met een knoop verbonden is aan een hoekpunt. Sterker nog, een tak kan eigenlijk eender welk 1 Ouderknoop: Knoop die direct kind is van het diagram. Ze zijn dus nooit kind van een andere knoop maar kunnen wel ouder zijn van een aantal andere knopen. 2 Kindknoop: Een knoop die als ouder een andere knoop of een diagramtak heeft. Deze ouderkind relatie komt enkel tot uiting in de boomstructuur van het diagram en is niet zichtbaar in een grafische afdruk ervan. 16 Steven De Groote

18 knopenpaar met elkaar verbinden, onafhankelijk of dat ouderknopen, kindknopen of knopen zijn die aan een verbinding vastgekoppeld zijn. Dit principe met ouderknopen en kindknopen en de eigenschappen die blijken uit de analyse maken het mogelijk een diagram te beschouwen als een soort boomstructuur. Die boomstructuur bevat dan alle kinderen, samen met een lijst van alle takken die in dat diagram voorkomen. Waar de meeste programma s gebruik maken van lineaire structuren met kruisverwijzingen hebben bomen, als opslagstructuur voor een diagram, een aantal niet te onderschatten voordelen: Knopen kunnen samengesteld worden door een object met kinderen aan te maken. Een kindknoop kan eigenschappen overerven van zijn ouder. Een knoop verwijderen kan snel omdat alle kinderen onmiddellijk gevonden kunnen worden. De positie van een kindknoop kan afhankelijk zijn van de positie van zijn ouderknoop Implementatie Door de elementen van het diagram in een boom op te slaan, kunnen we van al deze voordelen gebruik maken. Gezien die elementen vaak slechts een aantal directe kinderen hebben en dus geen kleinkinderen is in bijna alle gevallen de boom slechts enkele lagen diep. Het diagram kan dan beschouwd worden als de wortel van de boom. De elementen van dat diagram zitten opgeslagen in de diepere lagen in de boomstructuur. Diagramverbindingen kunnen echter van elkaar afhankelijk zijn. Het is met andere woorden belangrijk om een volgorde voor de takken bij te houden die zal bepalen welke verbinding het eerst verwerkt of getekend moet worden ( Afhankelijkheden tussen verbindingen). Om dat te vereenvoudigen, kunnen we de diagramboom opdelen in twee kleinere deelbomen: een knopenboom en een takkenboom. In de knopenboom zitten dan alle ouderknopen en hun kinderen, terwijl in de takkenboom alle diagramverbindingen samen met hun kinderen worden opgeslagen. Abstract bestaat een diagram dus uit een boom die gesplitst kan worden in een knopenboom en een takkenboom. Deze grote elementenboom is echter alleen een algemene opvatting, maar wordt niet als dusdanig geïmplementeerd. In plaats daarvan worden de ouderknopen van het diagram opgeslagen in een HashSet daar hun volgorde onbelangrijk is (de toegangtijd tot de knopen is hierdoor trouwens O(1)). De takken zitten verzameld in een zelf ontwikkelde SortedEdgeCollection. Ze worden daarin gesorteerd, rekening houdend met hun onderlinge afhankelijkheden: // Set van alle ouderknopen. private HashSet<OffsetNode> points; // Verzameling van alle diagramtakken, opgeslagen als een DAG. private SortedEdgeCollection edges; 17 Steven De Groote

19 Figuur 2 : Structuurboom De structuurboom van het voorbeelddiagram in Figuur 1 is voorgesteld in Figuur 2. De scheiding van beide deelbomen is in deze figuur duidelijk zichtbaar en biedt belangrijke mogelijkheden. Ten eerste is er de analogie met grafen, die met deze diagramstructuur eenvoudig kunnen opgeslagen worden. Belangrijker is echter dat een verbinding in het diagram eender welk paar knopen met elkaar kan verbinden. De knoop aan het ene einde van de verbinding mag dus op een andere diepte in de knopenboom liggen dan de knoop aan het andere einde van de verbinding. In Figuur 2 zijn de puntknopen voorgesteld door rode elementen, de vormknopen door blauwe elementen en de diagramverbindingen door groene rechthoeken. Volle verbindinglijnen stellen een ouder-kindrelatie voor en vormen de structuurboom. Zo is Ellips A de ouderknoop van het label uitleg en heeft het bovendien een viertal waarvan er slechts twee afgebeeld in de figuur verbindingspunten (zie Verbindingspunten bij knopen). Het label met tekst uitleg heeft op zijn beurt ook verbindingspunten om de gebruiker de kans te geven een verbinding te koppelen aan de rand van een vormknoop. Een stippellijn in de figuur wijst op een referentie. Er zijn voor elke diagramverbinding twee referenties naar andere knopen. Ze stellen de begin- en eindknoop voor van die verbinding. Voor tak 1 zijn die referenties gericht op Ellips A en Ellips B. Bij tak 2 is het beginpunt ook een ouderknoop in het diagram: punt C. Het eindpunt is echter een aanknopingspunt van tak 1. Het wijst erop dat tak 2 afhankelijk is van tak 1 en steeds na tak 1 verwerkt of getekend moet worden. De knopenboom bevat op de eerste laag de directe kinderen van het diagram alle knopen die geen kind zijn van een andere knoop of tak (de ouderknopen). De takkenboom bevat op de eerste laag alle verbindingen van het diagram. Op diepere lagen kunnen zich, in beide bomen, knopen bevinden. In de knopenboom zijn dit allemaal OffsetNode objecten met als ouderknoop een element uit de eerste laag. In de takkenboom zitten er op de tweede laag enkel EdgePoint objecten (knopen die enkel aan een diagramverbinding kunnen vastgekoppeld worden, 3.2.5). Dieper in de hiërarchie kunnen in beide deelbomen enkel nog OffsetNode-objecten (zowel puntknopen als vormknopen) voorkomen. Elke positie en in feite de hele transformatie, inclusief rotatie en vergroten van een OffsetNode wordt gedefinieerd als een offset relatief ten opzichte van zijn ouder. De 18 Steven De Groote

20 wortel kan dan beschouwd worden als een knoop in de oorsprong van het tekenvlak. De absolute positie van een knoop kan dan bepaald worden door in de boom naar dat element af te dalen en alle transformaties van de gepasseerde elementen samen te voegen. Op die manier worden de kinderen steeds bij de ouderknoop gehouden wanneer die bewerkt wordt. De precieze implementatie en werkingen van deze aspecten komen verder in dit hoofdstuk aan bod. 3.2 Structuur Klassenstructuur Figuur 3 : Beknopte klassenstructuur van het framework 19 Steven De Groote

21 Bovenstaande figuur is een verkleinde klassenstructuur van het framework. Dit diagram toont enkel de relaties tussen de klassen met hun naam, en verbergt functies, klasseveriabelen en bean properties 1 van de gewone klassen. Een uitgebreidere klassenstructuur van het framework is te vinden in Bijlage II. Het is niet onbelangrijk te weten dat elk van deze klassen zo ontworpen is, zodat alle eigenschappen toegankelijk zijn met functies zoals die voorgeschreven zijn in de Java beans specificatie. Zoals blijkt uit voorgaand schema, kan op een diagram elk soort DiagramElement getoond worden. De twee belangrijkste groepen daarin zijn Node die elementen voorstellen (knopen, tekst, een afbeelding, ) en Edge die de verbinding vormen tussen precies twee Node objecten Diagramelementen Knopen Een knoop, ook wel node genoemd, betekent voor de structuur van het diagram niets meer dan een plaats waar takken kunnen vertrekken en aankomen. Voor de lay-out van het diagram is ook de vormgeving en positie van belang. Op deze twee grafische criteria kunnen we vier grote groepen onderscheiden: De eenvoudigste van alle knopen is een OffsetPoint. Dit is een punt dat zijn positie bepaald ziet door een x- en y-coördinaat. Net zoals voor elk ander knooptype dat gepositioneerd wordt met een offset is die positie echter afhankelijk van de plaats van zijn ouder in het diagram. Deze relatieve positionering wordt besproken in Als tweede type is er de OffsetArea (of vormknoop) dat zonder twijfel het meest gebruikt wordt in diagrammen. Hoewel ook gepositioneerd met coördinaten, bevat dit type knoop een vorm en meteen ook een oppervlakte. Die oppervlakte kan zowel opgevuld zijn met een afbeelding uit een bestand, tekst of een kleur eventueel zelfs transparant. Door dit type knoop van het framework uit te breiden, is het zelfs mogelijk eender welke figuur te tonen. Verder zijn in het framework klassen geïmplementeerd voor rechthoeken, afgeronde rechthoeken en ellipsen. Een derde type knoop is voorzien om meedere verbindingspunten te hebben bij een OffsetArea. Het ConnectionPoint is een punt dat niet kan aangemaakt worden door een gebruiker, maar voorzien wordt door een vormknoop. Wanneer die gewijzigd wordt, zal die er meteen ook voor zorgen dat de positie van de verbindingspunten correct blijft. Verbindingspunten worden meestal voorzien aan de rand van een vormknoop. Ze geven de gebruiker meer vrijheid om te kiezen waar precies een verbinding aan een vormknoop moet gekoppeld worden. Het middelpunt van die vormknoop is namelijk niet altijd de beste of duidelijkste oplossing. Er wordt dieper ingegaan op deze verbindingspunten in Bean property: Eigenschappen van een Javabean object die gelezen en/of gewijzigd worden. 20 Steven De Groote

22 Tenslotte is er het EdgePoint, een punt dat als enige zijn positie niet bepaald ziet door een offset ten opzichte van de positie van zijn ouderknoop. Een EdgePoint is daarentegen altijd vastgekoppeld aan een verbinding tussen 2 andere knopen. Zijn positie is bepaald door één getal: een fractie die aanduidt waar langs de verbindingslijn deze knoop moet worden getekend. Meer over deze aanknopingspunten is te vinden in Takken Takken zijn de verbindingen die een relatie aanduiden tussen twee elementen in het diagram. Hoewel er verschillende types zijn, werd hier gekozen om geen enkele klasse te laten overerven van Edge. In plaats daarvan is de klasse universeel en slaat die zijn eigenschappen op als klassenvariabelen. Het maakt de toegang tot een tak daarom eenvormig, onafhankelijk van welke vorm de verbinding precies is. Deze vorm, in het bijzonder de manier hoe beide eindpunten met elkaar worden verbonden, wordt bepaald door een EdgePath object. Het zijn precies de verschillende klassen die overerven van deze interface die voor verschillende types van takken zorgen. Zo zijn er in de huidige versie rechte en gebroken verbindingen, maar kan de functionaliteit eenvoudig uitgebreid worden met Bézier 1 of BSpline 2 krommes. Het werk hiertoe beperkt zich tot het implementeren van de juiste interfaces en de klasse te registreren in het plugin systeem van de applicatie. Voor het overige kan het uitzicht van een tak gewijzigd worden door het lijntype, de kleur en het toewijzen van pijlen aan de uiteinden van de verbinding. Ook pijltypes (klassen die de klasse Arrow uitbreiden) kunnen toegevoegd worden met het plugin systeem zoals besproken in Relatieve positionering Samenhangend met de boomstructuur voor een diagram zijn ook de posities van alle knopen opgeslagen als relatieve coördinaten ten opzichte van hun ouder. Het blijft echter niet bij positionering. Knopen kunnen onafhankelijk van elkaar gedraaid en vergroot of verkleind worden. Deze transformaties voor de positie worden voor elk element bijgehouden als een Transformation object. Dit bevat informatie over de rotatie, de vergroting en de verschuiving ten opzichte van zijn ouder. Voor elementen die geen ouder hebben (ouderknopen en takken) is deze offset meteen absoluut. Een kind daarvan kent zijn absolute positie dan door een samenstelling te maken van de positie van zijn ouder met zijn eigen offset. Analoog is voor elk element de absolute positie eenduidig bepaald. 1 Bézier curve: Kromme bepaald door 3 of 4 controlepunten. Werd ontwikkeld door Pierre Bézier voor Renault. 2 BSpline: Kromme samengesteld uit opeenvolgende Bézier-curves zodat de tweede afgeleide van de lijnstukken gelijk zijn in de controlepunten. 21 Steven De Groote

23 Voor EdgePoint elementen is de positionering enigszins anders: de positie voor deze punten wordt berekend aan de hand van de positie van de tak waarvan hij kind is. Deze punten bezitten echter wel instelbare rotatie- en vergrotingseigenschappen. Wanneer dus een knoop wordt verplaatst, wordt enkel de positie-informatie van die knoop gewijzigd. Vermits de kinderen relatief gepositioneerd zijn, zullen deze automatisch mee volgen. Ook hier geldt hetzelfde voor rotatie, vergroting en verkleining. Dit heeft echter tot gevolg dat wanneer een knoop met daarop een kindelement, zoals bijvoorbeeld een label gedraaid wordt, die tekst ook zal meedraaien. Omdat dit meestal niet gewenst is, kan door de relatieve eigenschap van dat kind uit te schakelen, vermeden worden dat de rotatie en vergroting van de ouder invloed hebben op die van het kind. Dit kan grafisch in de eigenschappenlijst (zie 4.3.7) van dat element Verbindingspunten bij knopen Principe Hoewel het voor een punt duidelijk is waar takken vertrekken of aankomen, is dit veel minder vanzelfsprekend bij een Node die een oppervlakte omvat. Beide hebben echter een positiepunt, dat voor een vormknoop of OffsetArea het centrum van dat gebied is. Uit de analyse blijkt dat een verbinding niet alleen naar het midden van de vormknoop wijst, maar in sommige gevallen eindigt in een speciaal punt zoals een hoekpunt of buigpunt langs de rand van die vorm. In alle gevallen wordt de verbinding uiteraard niet over de knoop getekend, maar eindigt ze aan de rand ervan (zie Tekenen). Verbindingen tekenen van middelpunt tot middelpunt is wel sluitend om een graaf voor te stellen, maar geheel ontoereikend voor diagrammen. Om meer vrijheid te laten aan de gebruiker worden vormknopen voorzien van een aantal verbindingspunten. Die zijn in het framework ingebouwd met de klasse ConnectionPoint. Deze punten liggen op de rand van een vormknoop en zijn in feite niets anders dan OffsetPoints met een paar bijzondere eigenschappen. Wanneer zo n verbindingspunt namelijk verschoven wordt dan enkel de knoop waar dat punt bij hoort zijn ouderknoop verschuiven. Op die manier blijft het verbindingspunt altijd op dezelfde relatieve positie ten opzichte van zijn ouder. Verder zijn verbindingspunten standaard niet zichtbaar en worden ze alleen gemarkeerd wanneer een tak getekend wordt. Gewone punten in het diagram worden standaard voorgesteld door een zwart punt. Precies omdat deze verbindingspunten ook Nodes zijn, kan een diagramverbinding eraan vasthaken. Gezien ook deze punten een relatieve positionering hebben, schuiven, draaien en herschalen ze mee met hun ouder, zodat ze steeds, zonder extra werk, precies op de rand van de figuur blijven staan Conversie De verschillende types van OffsetArea hebben allemaal een verschillende vorm maar kunnen onderling geconverteerd worden. Een knoop in het diagram die bijvoorbeeld 22 Steven De Groote

24 een ellipsvorm heeft, kan bijgevolg omgezet worden naar een rechthoek zonder dat die knoop verwijderd moet worden. Bij dit converteren blijven alle gemeenschappelijke eigenschappen (zoals randdikte en vulkleur) bovendien ongewijzigd. Met verschillende figuren komen echter ook andere verbindingspunten overeen. Het aantal en de plaats van die punten kan namelijk verschillen. Zo heeft een rechthoek 9 verbindingspunten, en een cirkel of afgeronde rechthoek slechts 4. Om dit op te vangen werd in OffsetArea een functie voorzien die opgeroepen wordt telkens als een vorm naar een andere omgezet wordt. De functie zorgt ervoor dat de eindpunten van de verbindingen zo weinig mogelijk van plaats veranderen, of ook, dat ter vervanging van het oude verbindingspunt de tak wordt gekoppeld aan het dichtst mogelijke nieuwe verbindingspunt langs die knoopomtrek. De invloed die de conversie van een vormknoop heeft op de rest van het diagram wordt tot een minimum beperkt Aanknopingspunten aan verbindingen In tegenstelling tot grafen, waar verbindingen niets anders doen dan twee knopen verbinden, kunnen in een diagram verbindingen gemaakt worden met meer dan twee uiteinden. Bovendien is het vaak nuttig om een label of een figuur langs die verbinding te voorzien. Om dit te realiseren kan een EdgePoint aan een verbinding gekoppeld worden. Dit is een punt dat zich altijd langs een diagramverbinding bevindt. Zijn positie is bepaald door een getal variërend van 0 tot 100, zodanig dat 0 gelijk is aan de plaats waar de verbinding vertrekt, 100 het verbindingseinde is en 50 precies halfweg de verbinding ligt. Gezien dit een punt is, kunnen er andere takken aan gekoppeld worden zodat het lijkt alsof er één tak is met meerdere uiteinden. Het aanknopingspunt is net zoals elke andere knoop in staat om kindknopen te hebben. Door een tekstknoop als kind toe te voegen, krijgen we een label langs de tak dat zal meeschuiven wanneer die tak verdraaid of verschoven wordt. Het is bovendien mogelijk gelijkaardig aan de relatieve rotatie te bepalen of de elementen aan het aanknopingspunt moeten meedraaien met een tak. Wanneer dit ingeschakeld is, wordt de draaihoek van de tak op de plaats van het aanknopingspunt gekoppeld en toegevoegd aan de rotatie die voor dat aanknopingspunt werd ingesteld. Een tekst langs een tak kan bijgevolg zo ingesteld worden dat het steeds eenzelfde hoek met de tak of de horizontale insluit Subdiagram en groepen Van bij het begin van de analyse werd voorop gesteld dat groepen of subdiagrammen mogelijk moesten zijn. Het is handig en soms hard nodig dat elementen samen genomen kunnen worden. Er werd dan ook meteen in de klassenstructuur gezorgd dat het mogelijk was om een diagram in een diagram op te nemen. Na verloop van tijd werd echter duidelijk dat met een boomstructuur, subdiagrammen op zich een overbodige luxe waren. Een subdiagram kan immers eenvoudig gemaakt worden door alle elementen van dat diagram aan een gemeenschappelijk ouderpunt te hangen. Als we in plaats van een ouderpunt een vormknoop als ouder nemen, is het zelfs mogelijk een rand of 23 Steven De Groote

25 achtergrondkleur voor het hele subdiagram te voorzien. Alle elementen in dit subdiagram zullen samen de transformaties van hun ouder ondergaan en zich gedragen als een groep. Het verdraaien of verschuiven van het ouderelement heeft dan tot gevolg dat alle kinderen ook verdraaien of verschuiven. Bovendien is het voor echte subdiagrammen een probleem om verbindingen te maken. Alle verbindingen van een diagram worden immers in het diagramobject opgeslagen. Een paar knopen van verschillende diagrammen met elkaar verbinden was daarom onmogelijk. De klasse Diagram werd vervolgens herwerkt zodat deze niet meer erfde van een diagrampunt, maar enkel een implementatie is van DiagramElementContainer, een interface die trouwens door elk diagramobject geïmplementeerd wordt. Het resultaat is dat, hoewel de elementen gegroepeerd zijn, ze zich niet in een afzonderlijk genest diagram bevinden. Een diagramverbinding kan vervolgens transparant een paar knopen met elkaar verbinden die niet in dezelfde groep en dus niet dezelfde ouderknoop hebben zitten Scheiden van berekenen en tekenen Omdat een diagram een grafisch object is, zijn er een aantal berekeningen nodig voor de elementen die ervoor zorgen dat knopen en takken geselecteerd, gewijzigd en getekend kunnen worden. Dit voorafgaand werk zorgt voor een juiste positionering van de elementen in het diagram en wordt in de programmacode aangeduid als rendering. Tijdens het verschuiven van een programmavenster, selecteren van een element en scrollen in het canvas is het telkens nodig om het scherm te vernieuwen en dus te tekenen. Gezien het diagram in deze gevallen zelf niet wijzigt, zijn er ook geen berekeningen nodig die de posities bepalen van de knopen. Het renderen kan hier met andere woorden overgeslagen worden. Vanwege de voordelen voor de performantie werden deze rendering fase en tekenfase gescheiden van elkaar. Let wel dat het tekenen enkel mag gebeuren als het diagram correct werd gerenderd de elementen op de juiste plaats werden gezet en er nadien geen andere wijzigingen gebeurden. Mede door het cachen van de posities (zie onder) zou tekenen na diagramwijzigingen en zonder renderen vooraf tot onverwachtse resultaten leiden Positie caching Een element grafisch selecteren uit een diagram gebeurt per niveau in de boom, waarbij de kinderen van de wortel worden onderzocht wanneer er nog niets werd geselecteerd. Is dit wel het geval, dan wordt gezocht in de kinderen van het geselecteerde element. Wordt er een geldig element gevonden, dan wordt het geselecteerd. Zoniet wordt de huidige selectie teniet gedaan. Bij dat onderzoek wordt een klikpositie vergeleken met het gebied die een knoop met zijn kinderen samen inneemt. De vraag is nu, hoe kennen we deze oppervlakte? Het spreekt voor zich dat deze controle zo efficiënt mogelijk moet gebeuren, gezien selecteren door klikken een bijzonder frequente operatie is. Om dit te realiseren wordt voor elk element afzonderlijk het gebied op het canvas bepaald. Dit gebied wordt 24 Steven De Groote

26 onmiddellijk daarna tijdelijk opgeslagen gecachet met absolute coördinaten. Wanneer er geklikt wordt om te selecteren kan dan het klikpunt vergeleken worden met de opgeslagen oppervlakte. Een knoop kan dan zelf het gebied bepalen dat hij omvat samen met zijn kinderen door zijn gebied samen te voegen met dat van al zijn kinderen. De berekening van deze gebieden en het tijdelijk opslaan ervan gebeurt tijdens het renderen van de diagramelementen. Het zou immers nutteloos zijn deze operaties telkens te moeten uitvoeren wanneer er getekend moet worden zonder voorafgaande diagramwijzigingen Afhankelijkheden tussen verbindingen In een klassieke voorstelling van een graaf is een verbinding een relatie tussen twee onafhankelijke knopen. Diagrammen leggen echter minder beperkingen op voor de verbindingen, waardoor deze niet altijd onafhankelijke elementen zijn. Figuur 4 : Takvolgorde In Figuur 4 is een voorbeelddiagram getekend waaruit blijkt dat de volgorde van berekening wel van belang is. We moeten er immers op letten dat het renderen van tak 1 afgerond is voordat met tak 2 gestart kan worden. Zolang tak 1 niet volledig bepaald is, is de positie van X immers onbepaald en kunnen we onmogelijk beginnen met het berekenen van tak 2. Figuur 5 : Circulaire afhankelijkheid Het gaat zelfs nog verder: Figuur 5 toont hoe de gebruiker het diagram zo kan wijzigen dat er circulaire afhankelijkheden kunnen ontstaan binnen het diagram. Het uiteindelijk resultaat zou ertoe leiden dat tak 1 moet getekend worden na tak 3 en tak 3 na tak 2. Maar tak 2 kan zelf nog niet getekend worden gezien eerst tak 1 moet afgewerkt zijn. Het is op deze manier dus niet mogelijk een dergelijk diagram te realiseren. 25 Steven De Groote

27 Om deze afhankelijkheden en circulaire problemen in goede banen te leiden, worden de takken van een diagram opgeslagen in een directed acyclic graph (DAG) 1. In deze SortedEdgeCollection zijn de knopen in de DAG de takken uit het diagram. De DAG verbindingen zijn dan weer de afhankelijkheden tussen de diagramtakken. Op die manier bepaalt de topologische volgorde meteen ook de volgorde waarin de takken kunnen afgehandeld worden. De implementatie van de DAG is als volgt: private HashMap<Edge, LinkedList<Edge>> dag; Dit houdt een lijst bij van alle diagramtakken objecten van het type Edge met daarbij een lijst van de diagramtakken die ervan afhankelijk zijn. Daar intern bij het wijzigen van een tak vaak de tak en zijn afhankelijkheden snel moeten gevonden worden, is een HashMap met O(1) toegangstijd een goede oplossing. Hoewel de iteratiesnelheid door alle takken hierdoor afneemt (evenredig met de capaciteit i.p.v. het aantal elementen) is dit geen bezwaar voor de map. Bij het tekenen (wat frequenter gebeurt dan renderen) wordt immers niet deze structuur gebruikt om alle takken te doorlopen (zie Infinite layering). Wanneer nu een tak aan een andere wordt gekoppeld, controleert de applicatie of er dichtbij een aanknopingspunt op die bestaande tak ligt. Is dit het geval dan wordt de verbinding die gewijzigd wordt daaraan gekoppeld. Zoniet dan wordt op die plaats een aanknopingspunt (EdgePoint) aangemaakt en wordt de gewijzigde tak eraan vastgekoppeld. Na de aanpassingen worden de afhankelijkheden in de DAG gewijzigd. Meteen wordt gecontroleerd op lussen en zal de wijziging niet doorgevoerd worden indien daardoor een lus en dus ook circulaire afhankelijkheid van diagramtakken ontstaat. De wijziging in het diagram wordt dan ongedaan gemaakt en de tak zo geplaatst zodat het visueel hetzelfde resultaat weergeeft. Meestal indien geen ander punt in aanmerking komt wordt hiervoor in het diagram een nieuw punt aangemaakt op de plaats waar in eerste instantie het aanknopingspunt geplaatst werd. Hoewel hiermee de onderlinge volgorde voor het renderen van de takken volledig bepaald is, kan het renderen van de takken pas gebeuren als alle knopen van het diagram al gepositioneerd zijn. Zowel het beginpunt als het eindpunt van een diagramverbinding moet immers correct gepositioneerd zijn voordat de oppervlakte van de verbinding berekend kan worden. Renderen gebeurt dus eerst voor alle knopen in volgorde zoals ze in de knopenboom gevonden worden voordat de takken in topologische DAG-volgorde worden gepositioneerd Tekenen Infinite layering Gezien het grote aantal objecten dat kan voorkomen in een diagram zijn overlappingen tussen enkele elementen niet ondenkbaar. Net zoals in veel andere applicaties wordt 1 Directed acyclic graph : Bijzonder type gerichte graaf waarin geen lussen voorkomen. Deze familie wordt veel gebruikt voor projectplanning. De topologische volgorde geeft in dat geval de volgorde van uitvoering van de taken aan. 26 Steven De Groote