SASKIA P² Revamp GUI. Wim DUYSBURGH. Schoonmeersstraat Gent

Academiejaar 2008 – 2009

Departement Toegepaste Ingenieurswetenschappen Schoonmeersstraat 52 - 9000 Gent

SASKIA P² Revamp GUI

Eindwerk voorgedragen tot het behalen van het diploma van INDUSTRIEEL INGENIEUR INFORMATICA

Wim DUYSBURGH Promotoren: Christophe DE MULDER (ArcelorMittal, 9042 Gent) Jan CNOPS

Academiejaar 2008 – 2009

Departement Toegepaste Ingenieurswetenschappen Schoonmeersstraat 52 - 9000 Gent

Eindwerk voorgedragen tot het behalen van het diploma van INDUSTRIEEL INGENIEUR INFORMATICA

Wim DUYSBURGH Promotoren: Christophe De Mulder (ArcelorMittal, 9042 Gent) Jan Cnops

Woord vooraf

Er is mij de gelegenheid gegeven mijn thesis te maken in een bedrijf van de ArcelorMittal groep. ArcelorMittal Gent, of vroeger beter bekend als Sidmar, is een maritiem en geïntegreerd staalbedrijf dat meer dan 4,8 miljoen ton staal produceert op jaarbasis, dit is zo een 60.000 ton per dag. Deze tonnen produceren is één zaak, ze op een correcte en nauwkeurige manier plannen is een andere uitdaging. Sidmar is in feite een verzameling van kleinere fabrieken die elk een stap in het verwerkingsproces van staal verzorgen. Om een vlotte werking te garanderen moet er voor elk van deze fabrieken een goed werkschema bestaan. Elke dag moeten er negentien nieuwe planningen op een nauwkeurige manier gemaakt worden. Vroeger had elke fabriek zijn eigen specifieke systeem, met een unieke look and feel en vaak uitgesmeerd over verschillende computerplatformen. Dit is niet alleen lastig om te onderhouden maar er is tevens geen universele look and feel waardoor elke applicatie anders aanvoelt voor de gebruiker, hoewel de functionaliteiten elkaar voor een groot deel overlappen. Daarop heeft ArcelorMittal een applicatie ontworpen, SASKIA 1 genaamd. Deze applicatie leidt de planning van de materialen in goede banen, zorgt voor een universele look and feel en is door zijn generieke opbouw in staat alle verschillende productielijnen met dezelfde applicatie te visualiseren.

1

Alle vaktermen en afkortingen worden verklaard in een woordenlijst achteraan in deze thesis

Woord vooraf

Het is deze applicatie waaraan ik zal meewerken in mijn masterproef. Concreet is mijn taak de grafische component verzorgen.

I

Dankwoord

Toen ik het schrijven van mijn thesis aanvatte, heb ik een tijd nagedacht over al de mensen die mij geholpen hebben zo ver te komen. Daarom zou ik graag iedereen bedanken die mij aangemoedigd heeft om door te zetten in soms uitzichtloze situaties. In het bijzonder wil ik graag men moeder, Frieda Cattoir, bedanken voor haar jaren lange steun: zonder haar was ik hier nooit geraakt. Verder had ik graag mijn interne promotor, Jan Cnops, Doctor in de Wetenschappen en docent aan de hogeschool Gent, en mijn externe promotor, Christophe De Mulder, Burgerlijk Ingenieur en Projectcoördinator-architect applications bij ArcelorMital bedankt voor hun goede begeleiding van mijn thesis. Ook nog een woordje van dank aan alle mensen bij ArcelorMittal die dit eindwerk mogelijk maakten en in het bijzonder Bjorn Coussemaeker, 1e Programmeur Logistiek, en Kevin De Vos, IT Analist, van ArcelorMittal. Ik kon altijd bij jullie terecht met mijn soms vervelende vragen. Mijn dank gaat ook uit naar al de mensen die geholpen hebben bij het foutvrij maken van mijn thesis met in het bijzonder Pierre Wuyts.

Dankwoord

Tot slot wil ik mijn vrienden en familie bedanken voor hun goede zorgen en steun. Ik had echt veel aan jullie en ik had dit niet kunnen verwezenlijken zonder jullie.

II

Abstractie Deze thesis handelt over de ontwikkeling van een generieke GUI in opdracht van ArcelorMittal. Deze GUI vormt een deel van het SASKIA framework. Op het einde van de ontwikkeling werd het ook geïntegreerd in het systeem van ArcelorMittal. De unieke aspecten aan deze GUI zijn de genericiteit, de uitbreidbaarheid en de flexibiliteit. Het is de bedoeling een nieuwe GUI te kunnen maken zonder code te moeten aanpassen. Louter met XML configuraties wordt een nieuwe GUI opgebouwd.

Abstractie

In dit boek wordt veel aandacht besteed aan de analyse van dit project. Alles staat of valt bij een degelijke analyse. Verder wordt er ook wat toelichting gegeven over de werking van het project en de problemen die voorkwamen tijdens het ontwikkelingsproces. Tot slot worden de resultaten uit de doeken gedaan.

III

Abstraction This thesis treats the development of a generic GUI tool as requested by ArcelorMittal. This tool is a part of the SASKIA framework and was integrated into the ArcelorMittal systems at the end of the development cycle. It is unique in its generic, extendable and flexible features. The intention was to provide a tool with which a completely new GUI could be assembled without having to write or alter any code code. It is only necessary to provide a new configuration file in the XML format.

Abstraction

Much attention will go to the analysis, with which any project should start. Furthermore we take a closer look at the tool in action and at some of the errors we have encountered during its development. Finally we discuss the results we obtained.

IV

Inhoudsopgave Woord vooraf ........................................................................................................................................... I Dankwoord .............................................................................................................................................. II Abstractie ............................................................................................................................................... III Abstraction ............................................................................................................................................. IV Inhoudsopgave ........................................................................................................................................ 1 Hoofdstuk 1

Beschrijving project ......................................................................................................... 7

1.1

Inleiding ................................................................................................................................... 7

1.2

Situatieschets .......................................................................................................................... 7

1.2.1

Een korte omkadering ..................................................................................................... 7

1.2.2

Algemene werking SASKIA............................................................................................... 8

1.2.3

De generieke GUI............................................................................................................. 9

1.3

Doelstellingen .......................................................................................................................... 9

1.4

Uitdagingen ............................................................................................................................. 9

1.5

Bespreking GUI ...................................................................................................................... 10

1.5.1

Lay-out GUI .................................................................................................................... 10

1.5.2

Gebruik GUI ................................................................................................................... 11

Werkwijze .............................................................................................................................. 12

1.6.1

Kennismaking ................................................................................................................ 12

1.6.2

Analyse .......................................................................................................................... 13

1.6.3

Concepten ..................................................................................................................... 13

1.6.3.1 1.6.4 Hoofdstuk 2

De testprogramma’s .................................................................................................. 13 Uiteindelijke implementatie .......................................................................................... 16 Analyse .......................................................................................................................... 18

2.1

Inleiding ................................................................................................................................. 18

2.2

Opbouw layer-composite ...................................................................................................... 18

2.2.1 2.3

Tekenen van de layer-composite .......................................................................................... 19

2.3.1 2.4

Wijzigingen in de uiteindelijke implementatie .............................................................. 19


Tekenen van de cellen ........................................................................................................... 20

2.4.1

Het relatief/absoluut proces ......................................................................................... 21

2.4.2


Inhoudsopgave

1.6

1

Hoveren en selecteren .......................................................................................................... 22

2.5.1 2.6

Het selectie probleem ................................................................................................... 24

Requirements ........................................................................................................................ 25

2.6.1

Requirements (basis) ..................................................................................................... 26

2.6.1.1

GUI aspecten ............................................................................................................. 26

2.6.1.2

Dynamische aspecten ................................................................................................ 27

2.6.2

Requirements (optioneel) .............................................................................................. 27

2.6.2.1

GUI aspecten ............................................................................................................. 27

2.6.2.2

Dynamische aspecten ................................................................................................ 28

2.6.3

Bijkomende requirements ............................................................................................. 28

2.6.4

Status van implementatie ............................................................................................. 29

2.6.4.1

Eén of meerdere planpijpen visualiseren .................................................................. 29

2.6.4.2

Verkleinen of vergroten van de form ........................................................................ 29

2.6.4.3

Per planpijp – hiërarchische relaties ......................................................................... 29

2.6.4.4

Visualiseren properties van een object ..................................................................... 29

2.6.4.5

Speciale visualisaties ................................................................................................. 30

2.6.4.6

Draw/redraw ............................................................................................................. 30

2.6.4.7

Events ........................................................................................................................ 30

2.6.4.8

Bevoegdheden........................................................................................................... 30

2.6.4.9

Selectie van objecten ................................................................................................ 31

2.6.4.10

Context in acht nemen .......................................................................................... 31

2.6.4.11

Bakens ................................................................................................................... 31

2.6.4.12

Werkplan ............................................................................................................... 31

2.6.4.13

In- en uitzoomen ................................................................................................... 31

2.6.4.14

Voortgang van de planlijn...................................................................................... 31

2.6.4.15

Aanpassen lay-out ................................................................................................. 31

2.6.4.16

Andere GUI view .................................................................................................... 32

2.6.4.17

Planpijp verschuiven .............................................................................................. 32

2.6.4.18

Informatie in popup............................................................................................... 32

2.6.4.19

Visualisatie ruler object ......................................................................................... 32

2.6.4.20

Witruimte tussen materialen ................................................................................ 32

2.6.4.21

Veranderen van plaats .......................................................................................... 33

2.6.4.22

Bakens generiek opbouwen .................................................................................. 33

2.6.4.23

Objecten visualiseren zonder data ........................................................................ 33

Inhoudsopgave

2.5

2

2.6.4.24

Flexibiliteit van de code ......................................................................................... 33

2.6.4.25

Integratie en overdracht........................................................................................ 33

2.6.4.26

Syntax van ArcelorMittal ....................................................................................... 34

2.6.5

Documentatie code ....................................................................................................... 34

2.6.5.1

Meerdere planpijpen in verschillende frames .......................................................... 34

2.6.5.2

Start tijdstip ............................................................................................................... 34

2.6.5.3

XML opties ................................................................................................................. 35

Hoofdstuk 3

Werking project ............................................................................................................. 36

3.1

Inleiding ................................................................................................................................. 36

3.2

Bouwstenen........................................................................................................................... 36

3.2.1

Unit-convertors ............................................................................................................. 36

3.2.2

Het ruler object ............................................................................................................. 37

3.2.3

Composite structuren.................................................................................................... 37

3.2.3.1

Layer-composite ........................................................................................................ 37

3.2.3.2

Data-composite ......................................................................................................... 38

3.2.3.3

De structuur............................................................................................................... 38

3.2.3.4

Handlers..................................................................................................................... 38

3.2.4

Picturebox Extreme ....................................................................................................... 39

3.2.5

Controller....................................................................................................................... 39

3.2.6

ObjectBuilder ................................................................................................................. 39

3.2.7

Layer .............................................................................................................................. 40

Design patterns ..................................................................................................................... 41

3.3.1

Unieke container ........................................................................................................... 41

3.3.2

Plug-in visitors ............................................................................................................... 41

3.4

WorkFlow .............................................................................................................................. 42

3.4.1

Opbouw layer-composite .............................................................................................. 42

3.4.2

De Brush library's........................................................................................................... 43

3.4.3

Het tekenwerk ............................................................................................................... 44

3.4.3.1

De Layer naamplaat ................................................................................................... 44

3.4.3.2

De layer cellen ........................................................................................................... 45

Hoofdstuk 4

Problemen en oplossingen ............................................................................................ 46

4.1

Inleiding ................................................................................................................................. 46

4.2

Het layer probleem................................................................................................................ 46

4.3

Tekenen van layers ................................................................................................................ 49

Inhoudsopgave

3.3

3

Visualisatie dubbele takken................................................................................................... 50

4.4.1 4.5

Bijkomende problemen ................................................................................................. 52

Tekenprobleem van de ruler ................................................................................................. 53

Hoofdstuk 5

Gebruikte technologieën ............................................................................................... 54

5.1

Inleiding ................................................................................................................................. 54

5.2

VB.NET (VB 9.0) ..................................................................................................................... 54

5.2.1

Bespreking ..................................................................................................................... 54

5.2.2

Vernieuwende aspecten................................................................................................ 54

5.2.3

Richtprijs ........................................................................................................................ 55

5.3

WPF VS GDI+.......................................................................................................................... 55

5.3.1

Bespreking ..................................................................................................................... 55

5.3.2

Richtprijs ........................................................................................................................ 55

5.4

Visual SourceSafe 2005 ......................................................................................................... 56

5.4.1

Bespreking ..................................................................................................................... 56

5.4.2

Richtprijs ........................................................................................................................ 56

5.5

Javascript ............................................................................................................................... 56

5.5.1 5.6

Bespreking ..................................................................................................................... 56

Visio 2007 .............................................................................................................................. 56

5.6.1

Bespreking ..................................................................................................................... 56

5.6.2

Richtprijs ........................................................................................................................ 57

5.7

UModel (Altova) .................................................................................................................... 57

5.7.1 5.8

Check point VPN-1 SecureCient ............................................................................................ 57

5.8.1 5.9

Bespreking ..................................................................................................................... 57

Bespreking ..................................................................................................................... 57

Adobe Photoshop CS4 ........................................................................................................... 58

5.9.1

Bespreking ..................................................................................................................... 58

5.9.2

Richtprijs ........................................................................................................................ 58

5.10

Dreamweaver 8 ..................................................................................................................... 58

5.10.1

Bespreking ..................................................................................................................... 58

5.10.2

Richtprijs ........................................................................................................................ 58

5.11

Office 2007 ............................................................................................................................ 58

5.11.1

Bespreking ..................................................................................................................... 58

5.11.2

Richtprijs ........................................................................................................................ 59

5.12

Camtasia studio ..................................................................................................................... 59

Inhoudsopgave

4.4

4

5.12.1

Bespreking ..................................................................................................................... 59

5.12.2

Richtprijs ........................................................................................................................ 59

Hoofdstuk 6

Resultaten...................................................................................................................... 60

6.1

Inleiding ................................................................................................................................. 60

6.2

Testen .................................................................................................................................... 60

6.2.1

Dummy data .................................................................................................................. 60

6.2.2

Nieuw type layer............................................................................................................ 61

6.2.3

Flexibiliteit en uitbreidbaarheid .................................................................................... 61

6.2.3.1

Aanpassen XML ......................................................................................................... 61

6.2.3.2

Aanpassen LayerBacis................................................................................................ 62

6.2.3.3

Aanpassen Controler ................................................................................................. 62

6.3

Integratie Project ................................................................................................................... 63

6.4

Code overdracht .................................................................................................................... 63

6.5

De kracht van de generic art of programming (GARP) .......................................................... 63

6.6

De thesis leeft ........................................................................................................................ 64

Besluit .................................................................................................................................................... 65 Woordenlijst .......................................................................................................................................... 66 Figurenlijst ............................................................................................................................................. 70 Geraadpleegde literatuur ...................................................................................................................... 72 Appendix................................................................................................................................................ 73 Werkwijze .......................................................................................................................................... 73 Eerste analyse........................................................................................................................................ 76 Requirements .................................................................................................................................... 76 Requirements (basis)......................................................................................................................... 76 GUI aspecten ................................................................................................................................. 76 Dynamische aspecten .................................................................................................................... 77 Requirements (optioneel).................................................................................................................. 77 GUI aspecten ................................................................................................................................. 77 Dynamische aspecten .................................................................................................................... 78 Klassendiagram...................................................................................................................................... 79

Het initialisatieproces ........................................................................................................................ 80 Paintproces ........................................................................................................................................ 82 Paint van ruler ............................................................................................................................... 82

Inhoudsopgave

Proces beschrijving ................................................................................................................................ 80

5

Paint van linker paneel .................................................................................................................. 82 Paint van de composit structuur ................................................................................................... 83 Het zoomproces ................................................................................................................................ 84 Het verschuifproces........................................................................................................................... 85 Het relatief/absoluut proces ............................................................................................................. 86 Aan/uitschakelen/verslepen van layers ............................................................................................ 86 Het drag/drop proces ........................................................................................................................ 87 Het hoveren selectproces ............................................................................................................... 87 Hover sequentiediagram ............................................................................................................... 88 Select sequentiediagram ............................................................................................................... 89 Resize ................................................................................................................................................. 89 Andere ideeën/opmerkingen ................................................................................................................ 89 De if else trap .................................................................................................................................... 89 Wanneer repaint? ............................................................................................................................. 90 Paint en repaint van delen van de planpijp....................................................................................... 90 Probleemstelling............................................................................................................................ 90 Mogelijke oplossingen ................................................................................................................... 90 Oplossing 1 ................................................................................................................................ 90 Oplossing 2 ................................................................................................................................ 90 Klassendiagramma Layers ..................................................................................................................... 91

Inhoudsopgave

Syntax ArcelorMittal .............................................................................................................................. 92

6

Hoofdstuk 1

Beschrijving project Computer Science is no more about computers than astronomy is about telescopes. Edsger W. Dijkstra

1.1

Inleiding

Deze masterproef kadert binnen een groot programmeerproject van ArcelorMittal. Het is de bedoeling tijdens deze masterproef, een generieke GUI te ontwerpen die gebruikt kan worden op het SASKIA framework. Om dit tot een goed einde te brengen moest er nauw worden samengewerkt met de informatici van ArcelorMittal. Gezien het SAKIA project een grotere prioriteit gekregen heeft binnen het bedrijf, wegens de crisis, werd er meestal met meerdere informatici tegelijkertijd aan het project gewerkt. Het was dus een zeer actief project en er moest goed gecommuniceerd worden om niet in elkaars vaarwater terecht te komen. Ook werd er gebruik gemaakt van SourceSafe om de code met elkaar te delen. Hier wordt later op teruggekomen in het hoofdstuk over gebruikte technologieën. Elke programmeur stond weliswaar in voor zijn eigen deel, maar uiteindelijk moesten alle delen van het project vlot kunnen samenwerken. Om dit te verwezenlijken werd er meermaals vergaderd om samen gemeenschappelijke problemen op te lossen.

1.2

Situatieschets

1.2.1

Een korte omkadering

De Saskia Applicatie bestaat uit vier grote delen, vijf als de database wordt meegerekend. Explore: gebruiksvriendelijke exploreer toepassing op de database

GUI: visualiseerde de volgorde van de geplande orders en geeft specifieke informatie Scheduling application: brengt alles samen. Dit is het brein achter de hele operatie

Figuur 1: Componenten planningsysteem (ArcelorMittal, ISM/WPI Klantenondersteuning,2002)

Hoofdstuk : Beschrijving project

Wizard: staat in voor het ordenen van de bestellingen en beheer van de goederenvoorraad

7

1.2.2

Algemene werking SASKIA

In dit puntje wordt kort besproken hoe SASKIA werkt. Alles begint bij de stock populatie. Er zijn een aantal materialen aanwezig in de stok en er komen een aantal bestellingen binnen. Binnen SASKIA worden de bestellingen niet volgens de fifo 2 structuur behandeld. Er wordt gebruik gemaakt van een wizard die de orders zal plannen voor productie.

Figuur 2: Algemene werking planninsysteem (ArcelorMittal, ISM/WPI Klantenondersteuning,2002)

Nadat de wizard een planpijn opstelde met een mogelijke volgorde van te produceren bestellingen wordt deze nagekeken door de planners. Zij zullen de GUI gebruiken die in deze masterproef besproken wordt. De planners krijgen een visualisatie van de planpijp te zien. Mochten er dan toch nog orders zijn die niet goed staan of een hogere prioriteit hebben, kunnen ze een aantal plandelen selecteren en ze destilleren tot een werkschema. Hierop kunnen ze dan bewerkingen uitvoeren. Na de bewerkingen wordt een evaluatie wizard aangesproken. Deze zal controleren over er geen conflicten ontstaan met

2

fifo first in first out


Dit gebeurt aan de hand van een aantal meta heuristieken. Een voorbeeld van zo een heuristiek is het volgende: een staalplaat van 2 mm dik kan niet geproduceerd worden na een staalplaat van 15 mm dik. Het verschil is gewoon te groot om te overbruggen. Er zijn nog onnoemelijk veel andere heuristieken waaraan de planning moet voldoen zodat ze in productie geen problemen krijgen. In deze masterproef zal hier niet verder op worden ingegaan. Wat wel nuttig is om weten is dat de wizard, wegens de quasi oneindige zoekruimte, nooit de perfecte oplossing kan vinden. Daardoor moet er nog een manuele controle zijn. Dit op zijn beurt is dan de reden waarom er een visualisatie moet gemaakt worden van de planpijp.

8

de huidige wijzigingen. Als er conflicten ontstaan, zal hij dit rood laten kleuren door de GUI en de nodige fout waarden generen. 1.2.3

De generieke GUI

Wat er juist bedoeld wordt met een generieke GUI is het volgende. Er zouden een aantal algemene stukken code moeten geschreven worden die elke GUI kan gebruiken. Maar alle specifieke informatie zit uiteindelijk in een XML-bestand. De gemakkelijkste manier om er naar te kijken is als volgt: bekijk de bouw van een huis. Een huis bestaat uit bakstenen. Je kunt heel veel verschillende huizen bouwen met toch telkens dezelfde bakstenen, enkel met een verschillend bouwplan. Wel, de codeblokken die geschreven zijn kan je vergelijken met de bakstenen van een huis. De XMLfiles zijn het plan, in dit geval niet van een huis, maar van een GUI. De informatie in de XML-files zal zeer uitvoerig moeten zijn. De kleur, grote, visuele voorstelling, welk soort component, extra symbolen, … wordt allemaal in de XML-file gestoken. Dit zorgt voor een heel grote flexibiliteit van de GUI. Deze flexibiliteit is nodig omdat deze GUI niet één enkele planpijp moet visualiseren; hij moet negentien verschillende planpijpen visualiseren. Elke productielijn op het bedrijf heeft zijn eigen specifieke voorstelling. Door de GUI zo op te bouwen is het niet alleen eenvoudig om nieuwe visuele voorstellingen te maken. Tevens wordt het aanpassen van huidige views enorm vereenvoudigd. Stel, er komt een vraag van de planners binnen om een bepaalde eigenschap, die gevisualiseerd staat op hun planpijp, een andere kleur te geven. Er wordt iets in de XML-files aangepast en aan de planner gevraagd een refresh te doen, en de eigenschap heeft een nieuwe kleur. Dit banale voorbeeld toont de kracht aan van zo te werken. Als de kleur bijvoorbeeld in de code had gestaan dan had deze daar aangepast moeten worden, had het project opnieuw moeten compileren en had er dan een nieuwe versie moeten uitgegeven worden. Dit enkel om een kleur te veranderen. De XML-file bezit natuurlijk veel meer dan alleen maar kleuren. Hij bezit alle informatie om een volledige view op te bouwen. In de bijlage achteraan vindt u een voorbeeld van zo een configuratiefile terug.

1.3

Doelstellingen

1.4

Uitdagingen

De uitdagingen rond deze masterproef zijn velerlei. Aan de ene kant is er de enorme universaliteit van de GUI. Er ligt weinig tot niets vast omtrent de structuren die er zullen moeten verwerkt worden. Verder moet de code ook zeer duidelijk geschreven zijn en goed gedocumenteerd. Er moet veel aandacht besteed worden aan de uitbreidbaarheid van de code en het onderhoud ervan.


Het doel van deze masterproef is een generieke GUI te schrijven die visueel weergeeft wat de produceer- volgorde is van de bestellingen. Hierbij moet at runtime visuele elementen kunnen veranderd worden.

9

Aan de andere kant is er het werken in team. Er moet rekening gehouden worden met structuren die door andere personen geschreven worden. Hierdoor is een goede communicatie van het uiterste belang voor het slagen van deze masterproef. Tot slot werd deze masterproef geprogrammeerd ter plaatse. De vertrouwde schoolbank werd ingeruild voor een bureau en een stapje in het bedrijfsleven.

1.5

Bespreking GUI

1.5.1

Lay-out GUI

In dit puntje wordt wat dieper ingegaan op het uitzicht van de GUI en de naamgeving die ook verder in deze thesis zal gebruikt worden. Hieronder vindt u een afbeelding van de GUI. De grijze strook aan de linker kant in de naam plaat van de layer en bevat de naam van de layer. Het rechterdeel van een layer bevat de layer cellen. Deze symboliseren het te produceren materiaal. Als men over een bepaalde layer cel hovert met de muis, wordt er een zwarte kader rond deze cel getekend. Onderaan verschijnen dan de specifieke gegevens van de cel. In deze bèta versie worden enkel het ID en de productietijd gegeven. Als er uiteindelijk met echte data gewerkt zal worden, zullen er meer gegevens weergegeven worden in deze status balk. Voorlopig wordt hier gewoon met het ID aangetoond dat de bepaalde cel weldegelijk gevonden wordt in de composite structuur. Er zijn meerdere types layer. Op de figuur zijn er drie types aangeduid. De ouder-layer, bevat een groep van kind-layers. Dan hebben we ook een baken. Dit is een speciaal type omdat dit wat meer informatie geeft over de materialen. Een baken stelt zelf geen te produceren materiaal voor maar symboliseert een eigenschap van het materiaal of het order dat tussen twee bakens staat van hetzelfde type. Het baken heeft daarom ook geen eigen starten stop tijd; dit wordt afgeleid van het onderstaande materiaal.


Tot slot zijn er nog twee andere types van layers, die niet werden aangeduid op de GUI, namelijk de ghost-layer en de overlay-layer. De ghost-layer is een layer die geen te produceren materiaal vertegenwoordigd. Het heeft geen starten stoptijd. Het is slechts een container van andere layers. Deze layer kan u evenwel zien op de figuur. Dit zijn de grote lichtgele vlakken. De overlay-Layer is een layer die even groot is als zijn ouder-layer. Deze heeft geen naamplaat en wordt gebruikt om stilstanden aan te geven. Deze vindt u niet terug op de onderstaande tekening.

10

Figuur 3: SASKIA GUI

1.5.2

Gebruik GUI

Verder behoudt de gebruiker de mogelijkheid om de GUI volledig te personaliseren. Dit gebeurd onder andere met behulp van het form dat u hiernaast vindt. Dit form geeft de gebruiker de mogelijkheid om layers zichtbaar of onzichtbaar te maken. De inhoud van dit venster kan door de programmeur geconfigureerd worden vanuit XML. Een ander voordeel is dat de gebruiker ook zijn gepersonaliseerde GUI configuratie kan opslaan en als hij later nogmaals de GUI opent zal hij direct zijn

Figuur 4: Property window SASKIA GUI


Deze GUI is gebouwd op het model van de oude GUI. Dit om de gebruiker een zeker gevoel van vertrouwen te geven. Er werden echter wel heel wat verbeteringen aangebracht, niet alleen onder de motorkap, maar visuele verbeteringen. Zo is het nu mogelijk in real-time door de planpijp te scrollen. Waar de planpijp vroeger enkel hertekend werd nadat het scrollen gedaan is, wordt nu direct feedback gegeven naar de gebruiker wanneer hij scrolt door de planpijp. Zo kan de gebruiker zich direct oriënteren binnen een planpijp.

11

vertrouwde GUI configuratie terugvinden. Dit zal gebeuren door een nieuw XML bestand te generen die de persoonlijke voorkeur bevat van de gebruiker. Met gepersonaliseerde GUI wordt er natuurlijk meer bedoeld dan enkel het zichtbaar en onzichtbaar maken van layers. Zo kan de gebruiker ook in staat gesteld worden de volgorde van layers te wijzigen. Als bijvoorbeeld de gebruiker liever zijn bakens onderaan of in het midden van zijn GUI ziet, dan is dat geen probleem. Ook zou de gebruiker eigen kleuren kunnen kiezen mocht dit nodig geacht worden. Dit zijn maar enkele van de vele mogelijkheden die deze GUI rijk is. Er bestaat echter nog geen consensus over hoe configureerbaar ze de GUI willen maken. Want als je elke gebruiker zijn eigen GUI laat configureren en dan een andere gebruiker achter die GUI zet, zal deze zijn vertrouwde view missen. Dus dit argument pleit eerder voor een gestandaardiseerde view. Een andere optie aan deze GUI is de zoom. Het bereik van deze zoom is eveneens configureerbaar zonder een letter code te schrijven. Verder is het voor de gebruiker mogelijk om enerzijds te zoemen door middel van een dropdown menu en anderzijds door de toetsencombinatie van control en de muisscroll. Er werd gekozen voor deze toetsencombinatie omdat de gebruiker zijn muisscroll, zonder extra toetsen, kan gebruiker om door de planpijp te lopen. Dit is overigens ook een nieuwe optie die geïntroduceerd wordt met deze GUI. Een laatste verandering is de scrollbar onderaan de GUI. Deze geeft accuraat weer hoe ver de gebruiker nog kan scrollen, en door een aanpasbare grote krijgt de gebruiker ook visuele feedback van hoe groot de planpijp is. De scrollbar zal verdwijnen als de volledige planpijp zichtbaar is.

1.6

Werkwijze

De ontwikkeling van deze masterproef kan opgedeeld worden in vier grote delen. Het eerste deel is de kennismaking met het oude systeem en de nieuwe opties daarna volgt de analyse. Daarna werden een aantal concepten uitgetest en vergeleken. Tot slot werd de GUI zelf geïmplementeerd. In deze paragraaf zal kort ingegaan worden op deze verschillende delen. 1.6.1

Kennismaking

Het idee was dus een volledig nieuwe motor te schrijven achter de applicatie, met een paar visuele upgrades, maar toch de vertrouwde omgeving van de gebruiker te behouden. Er werd met veel mensen gesproken over hoe de nieuwe GUI er moest uitzien, wat de vernieuwende aspecten zouden worden en welke visuele upgrades er zouden uitgevoerd worden. Aan de hand hiervan werden de requirements opgesteld. Deze requirements zullen in de loop van de masterproef nog wat bij geschaafd worden.


Eerst werd het project en de doelstelling grondig doornomen. Dan werd er gekeken hoe het oude systeem bepaalde dingen deed. Het was uiteindelijk de bedoeling deze functionaliteiten zeker ook in de nieuwe GUI te steken, dat en meer. Tevens moest er gestreefd worden naar een gebruiksvriendelijke en vertrouwde omgeving voor de gebruiker.

12

1.6.2

Analyse

Nadat de requirements zijn opgesteld kan er met de rest van de analyse begonnen worden. Een eerste analyse werd reeds opgesteld in augustus. Deze analyse werd in diezelfde maand ook voorgesteld aan het team dat met dit project bezig is. De integrale analyse kan u terugvinden in de Appendix. Deze analyse werd nog bijgestuurd maar gaf al een goede indicatie van wat er moest gebeuren en wat de gedachtegang was. In februari werd er dan aan de hand van deze analyse een tweede, meer concretere analyse opgesteld. Tevens waren reeds enkele requirements aangepast waardoor een deel van de analyse van augustus moest over gedaan worden. Het resultaat was een tweede analyse die heel nauw aansluit bij de uiteindelijke versie van het project. Op deze analyse wordt in Hoofdstuk 2 Analyse dieper op ingegaan. Daar worden ook de inconsistenties met de uiteindelijke implementatie uit de doeken gedaan en worden ook alle requirements overlopen. 1.6.3

Concepten

Dit deel loopt eigenlijk parallel met de tweede analyse. Tijdens de analyse werden er theoretische oplossingen bedacht voor praktische problemen. Om deze uit te testen werden een aantal testprogramma’s gerealiseerd. Deze waren enerzijds nuttig om nieuwe dingen uit te proberen en gaven anderzijds de programmeurs op ArcelorMittal de mogelijkheid om feedback te geven op iets tastbaars. Deze werkwijze werd niet opgedragen vanuit ArcelorMittal, maar is wel een heel belangrijke techniek geweest om uiteindelijk alles vlot te kunnen realiseren. Geen van deze testprogramma’s of code die geschreven werd voor deze testprogramma’s werden gebruikt in het uiteindelijke project. Het was echter veel eenvoudiger om deze geteste technieken opnieuw toe te passen in het uiteindelijke project. Tevens gaf het de mogelijkheid de programmeurs bij ArcelorMittal te overtuigen van deze werkwijze. Buiten de soms nogal helse kleuren werd dit altijd met veel enthousiasme onthaald. 1.6.3.1 De testprogramma’s

1.6.3.1.1 Eerste testprogramma

In dit eerste testproject werd het ruler object uitgetest. Deze component wordt nog verder toegelicht in 3.2 Bouwstenen. Het belangrijkste doel van deze testapplicatie was de visualisatie van deze component. Een normale visualisatie is geen probleem, maar dankzij deze test applicatie werden een heel aantal problemen blootgelegd.


Hier volgt een kort overzicht van de verschillende testprogramma’s en met welk doel ze geschreven zijn. Hier ziet u ook hoe de technieken die gebruikt zijn evolueerden.

13

Figuur 5: Eerste testprogramma

Zo wordt in-, uitzoemen en herschalen een groot probleem, zoals u kan zien in onderstaande figuur. Nu had de indicatie van de 30 min automatisch weg moeten gelaten worden om een duidelijker beeld te krijgen van de tijd. Echter, als je zomaar deze indicaties weg gaat laten, kan dit verwarrend worden voor de gebruiker. Daarbij komt nog dat het helemaal niet zo vanzelfsprekend is om deze aanduidingen weg te laten, want wanneer laat je ze precies weg? De testapplicatie was in staat dit te doen, maar de code werd veel te complex, mede omdat de ruler niet enkel instaat voor de tijd maar ook omdat hij algemener moest zijn en ook andere maateenheden moest kunnen weergeven. Dit programma gaf het probleem mooi weer en mede Figuur 6: Eerste testprogramma gecomprimeerd

dankzij dit programma werd er beslist de visualisatie van de ruler niet meer te implementeren. De code werd te complex en de baten wogen niet op tegen de grillen.

1.6.3.1.2 Tweede testprogramma

De locatie van de blokken wordt bepaald door de ruler. Hoewel deze hier niet meer gevisualiseerd is, doet hij achterliggend nog steeds alle convergeer werk tussen pixels en meeteenheid. Vernieuwende ideeën die werden uitgetest bij deze nieuwe GUI was het zoemen en het scrollen door de planpijp. In deze GUI werd ook voor het

Figuur 7: Tweede testprogramma


Een tweede testprogramma werd daarna geschreven. Dit programma zou de ruler niet meer visualiseren en zou de tijd aangeven met een label en een popup. De blokken die u op deze form ziet worden erop gezet door middel van een bepaalde tijd. Zo zal de eerste blok een starttijd hebben die overeenkomt met het tijdstip waarop de applicatie gestart werd. Dit blok zal 1 uur duren. Elk volgende blok duurt 1 uur langer en wordt in de tijd ook steeds groter.

14

eerst de nieuwe picturebox geïntroduceerd welke de eerder vermelde functies zou ondersteunen. Een probleem dat werd ontdekt bij de ontwikkeling van dit testprogramma, was het volgende: op dit moment werd er gezoemd door de image uit te rekken om zodoende herberekeningen te voorkomen. Echter als er op een zeer grote schaal wordt ingezoomd, dan wordt er een neveneffect waargenomen. De anti-allising kan niet voldoende goed overweg met deze factor van uitrekking, waardoor de wanden beginnen te vervagen.

Figuur 8: Anti-allising probleem

Aanvankelijk werd aangenomen dat zo een ingrijpende vorm van inzoomen niet zou plaatsvinden en dat alles nog steeds scherp zou zijn. Uiteindelijk bleek dit niet het geval te zijn en werd er geopteerd om toch alles terug te hertekenen. Gelukkig was deze redraw actie veel performanter dan eerst gevreesd.

Dit is het laatste testprogramma dat werd geschreven voor aan het echte programma werd begonnen. Dit testprogramma introduceerde de verschillende stijlen die een blok kan bevatten en de eerste versie van een XML parser, die uiteindelijk de xmlconfiguratiefile zou inlezen. Deze parser was op dat moment al in staat de stijlen xml in te lezen en at runtime nieuwe objecten aan te maken. De nieuwe objecten werden op dit moment aangemaakt door de stijl zelf en dat Figuur 9: Derde testprogramma


1.6.3.1.3 Derde testprogramma

15

gebeurde als volgt: ''' <summary> ''' can generates any brush in system.drawing.dll ''' m_typeBrush is set in a property ''' ''' ''' Public Function BrushNotSelected() As System.Drawing.Brush Implements_ IBaseStyle.BrushNotSelected Dim clsAssembly As System.Reflection.Assembly =_ System.Reflection.Assembly.LoadFrom("system.drawing.dll") If Not clsAssembly Is Nothing Then Return TryCast(clsAssembly.CreateInstance(m_typeBrush, True, Nothing,_ Nothing, m_args, Nothing, Nothing), Brush) Else Return Nothing End If

End Function

Later zal een heel deel van deze creatie gebeuren door de ObjectBuilder. Voorlopig wordt hier gewoon de assembly geladen en via reflection wordt de juiste brush aangemaakt. Het brush type wordt gegeven door m_typeBrush. Dit is een string die wordt ingelezen vanuit XML. In dit testprogramma wordt ook nog steeds gebruik gemaakt van de ruler die het blok op de juiste plaats zet. Onderaan het form maakt de statusbalk zijn introductie. Deze zal op dit moment gewoon de tijd weergeven waar de muiscursor zich op dat moment bevindt. Zo wordt er getest of de ruler ten allen tijden kan zeggen op welk tijdstip de muis staat. Dit zal belangrijk worden in de latere ontwikkeling, om te ontdekken op welk materiaal de muis staat. Verder werd het zoomen en scrollen ook verbeterd in deze nieuwe versie. Tijdens de ontwikkeling van deze GUI is er sterk overwogen om hier geen decorater pattern te gebruiken om de verschillende tekenstijlen te implementeren. Uiteindelijk werd dit niet zo geïmplementeerd omdat het eigenlijk telkens maar twee toestanden zijn. Je hebt de geselecteerde en niet- geselecteerde toestand. Deze wisselen elkaar af en komen nooit tegelijkertijd voor. Uiteindelijke implementatie

Nadat de analyse en de concepten zijn uitgewerkt en goedgekeurd door het team, wordt aan de implementatie van het echte project begonnen. Dankzij de testprojecten en de grondige analyse loopt de uitwerking van het project als een trein. Er werden bijna twee maanden voorbereid met analyses en testscenario’s maar dit loont de moeite. Het uiteindelijk project werd in minder dan een maand geschreven. Het debug werk was minimaal en het resultaat optimaal. Tijdens de ontwikkeling van het uiteindelijk project werd gewerkt met dummy data. Dit programma kan niet afzonderlijk werken. Het heeft invoer nodig van andere delen van het framework, waar het later deel van zal uitmaken. Gezien dit framework nog volop ontwikkeld wordt, konden nog niet alle invoergegevens voorzien worden om de GUI te testen. Daarom werd er teruggegrepen op dummy data. Deze stelde een fictieve planpijp voor die dan moest voorgesteld worden door de GUI.


1.6.4

16

Toen de GUI in zijn laatste face zat, werden er ook andere fictieve planpijpen gegenereerd met een meer complexere structuur. Deze moesten zonder aanpassingen in de code dan ook worden voorgesteld.


Tot slot werd de GUI geïntegreerd in het echte framework en werd de code overgedragen aan de programmeurs op ArcelorMittal.

17

Hoofdstuk 2

Analyse Divide et impera Gaius Julius Caesar

2.1

Inleiding

Dit hoofdstuk zal de volledige analyse uit de doeken doen. Tijdens het maken van de masterproef werd er veel belang gehecht aan een grondige analyse. Deze analyse werd tevens voorgelegd aan het team van analisten en programmeurs, die instaan voor de ontwikkeling van het SASKIA platform. Deze beoordeelden de analyse en gaven uiteindelijk groen licht voor de implementatie ervan. Er werden dus eigenlijk twee analyses gemaakt. De eerste analyse vindt u achteraan terug in de appendix. De analyse die in dit hoofdstuk besproken zal worden, is de herziene versie, naar aanleiding van de bewerkingen van de informatici op ArcelorMittal. Deze analyse is deze waarmee gestart is voor de implementatie. Tijdens de ontwikkeling zijn er echter nog een aantal zaken gewijzigd, enerzijds door veranderingen binnen de architectuur van het framework, anderzijds door dingen die nog niet voorzien waren tijdens de analyse. Deze verschillen zullen worden toegelicht in het laatste puntje van elk deel.

2.2

Opbouw layer-composite

Het opbouwen van de layer-composite gebeurt in de BuildLayerComposite klasse. Deze zal een Layerfactory gebruiken om de layers aan te maken. De factory zal de verschillende eigenschappen van een layer uit een xml-configuratiebestand halen. Aan de hand van deze gegevens zal de layer factory dan een nieuw Layer-Composite object maken. Nadat de layer geconstrueerd is, kan deze zijn ouder laten weten hoe zwaar hij weegt relatief ten opzichte van de andere kind-layers van deze ouder. Hierdoor zal de ouder-layer, nadat hij al zijn kinderen kent, weten van elk kind hoe groot het moet getekend worden. De ouder gaat als volgt te werk: eerst vraagt hij aan alle zichtbare layers hoe zwaar ze zijn. Daarna zal de ouder-layer al deze gewichten optellen. Vervolgens kan hij de verhoudingen van de gewichten van een kind-layer ten opzichte van het totale gewicht van alle kind-layers berekenen. Hieruit wordt dan afgeleid hoe groot een layer moet getekend worden.

Er wordt niet met percentages gewerkt, hoewel dit het meest voor de hand liggende systeem was geweest. Mocht er met percentages gewerkt worden, had een kind niet eens zijn ouder nodig om te weten hoe groot hij was. Helaas is dit geen optie omdat er layers in het kind bij kunnen komen of weg kunnen gelaten worden. De hoogte van de kind-layers wordt berekend enkel met het aantal zichtbare layers.

Hoofdstuk : Analyse

Voorbeeld: Er moeten 5 layers afgebeeld worden: L1, L2, L3, L4, L5 met respectievelijke gewichten 50, 50, 25, 10, 65. Dit geeft de totaalsom van 200 wat gelijk staat aan 100% of x pixels. Met andere woorden L1 en L2 zullen beide over ¼ van het scherm afgebeeld worden terwijl L3 1/8ste krijgt, L4 1/20ste en L5 13/40ste.

18

Figuur 10: Het sequentiediagram voor de opbouw van de layercomposite

2.2.1

Wijzigingen in de uiteindelijke implementatie

Na de creatie van de layer door de LayerFactory wordt de XML node doorgegeven aan de layer zelf. Deze is dan verantwoordelijk voor zijn properties verder in te vullen. Dit was een deel specifieke code die beter afgehandeld wordt door de layer in plaats van door een factory. Dit komt eveneens de uitbreidbaarheid ten goede. Mocht er een nieuwe property bijkomen in de layer, dan moeten er enkel aanpassingen gebeuren binnen de layer en niet in de factory.

Tekenen van de layer-composite

Eerst is er een canvas nodig waarop er kan getekend worden. Dit wordt meegegeven bij de creatie van de layer-composite. Vervolgens moet bepaald worden wat de hoogte is van bepaalde layers. Niet alle layers hebben namelijk een vaste hoogte. Er wordt een onderscheid gemaakt tussen dynamische en statische layers. De statische layers hebben een vaste hoogte die wordt gelezen uit het configuratie bestand. De hoogte zit vast gecodeerd. Dan zijn er de dynamische layers. Hierin zijn nog twee soorten, deze met

Hoofdstuk : Analyse

2.3

19

een vaste hoogte, berekend aan de hand van gewichten in de xml-file, en deze met een variabele hoogte, afhankelijk van de hoogste value van de eigenschap die ze weergeven. Voor deze laatste soort moet over de data-composite structuur gelopen worden om te bepalen welke de minimum en maximum waarde is van een bepaalde eigenschap. Hieruit zal dan de hoogte van de laatste soort layer bepaald worden. Eens alle hoogtes, gekend zijn, kunnen alle layers getekend worden. De breedte van alle layers is gelijk en af te lezen uit de xml-file. Tot slot moeten nog brush en de pen aangemaakt worden waarmee de layer getekend zal worden. Het aanmaken van deze brush en pen gebeuren via reflectie. Na het tekenen worden de brush en pen vernietigd. Dan wordt alles nog eens overgedaan voor de kinderen van de layer.

Figuur 11: Het sequentiediagram voor het tekenen van de layercomposite

2.3.1


In de uiteindelijke versie worden de brush-types bijgehouden in een dictionary, maar buiten een aantal namen die wat veranderd zijn, is dit geïmplementeerd op de manier waarop het hierboven beschreven staat.

Tekenen van de cellen

Eén cell is één shape die een eigenschap van de data-composite representeert. Elke layer bevat zelf de tekenlogica van de cellen. Deze tekenlogica wordt voor het grootste deel afgeleid uit het configuratie bestand. Er is een onderscheid te maken tussen het tekenen van de bakens en andere eigenschappen van het materiaal.

Hoofdstuk : Analyse

2.4

20

Een baken heeft eveneens een rechthoek als shape maar hier wordt nog een extra driehoek bij getekend. Dus hiervoor zal een specifieke layer-composite voor gemaakt moeten worden die de layer -composite implementeert. Bij de start van het tekenen wordt de data-composite element per element overlopen. Naargelang het type van het element wordt de juiste layer-composite aangesproken. Als het een element is met meerdere properties waarin de GUI in geïnteresseerd is, worden alle properties overlopen en doorgegeven aan de respectievelijke layers samen met de begin- en eindtijd. Dit wordt in de layer dan omgezet naar coördinaten van de shape en tot slot wordt de juiste brush en pen aangemaakt om de shape ook daadwerkelijk te tekenen. Het teken van cellen in de dynamische layer kan op twee manieren gebeuren naargelang de voorkeur van de klant. Er is een relatieve of absolute weergave. Dit wordt uitvoeriger besproken in 2.4.1Het relatief/absoluut proces.

2.4.1 Het relatief/absoluut proces In dit proces wordt de berekening voor de relatieve of absolute weergaven nader besproken. Hiervoor hebben we 2 grenzen nodig: een onder- en een bovengrens. Hiertussen worden de verschillende materialen getekend met een bepaalde hoogte. Vb: • Absoluut: Dit houdt in dat de benedengrens 0 is en de bovengrens het grootste materiaal. Dus als het grootste materiaal 1000 mm is, dan zijn de grenzen tussen 0-1000 en wordt daarbinnen alles afgebeeld. • Relatief: Dit is een scope die kan vastgelegd worden door de gebruiker. Hij kan bijvoorbeeld vragen alles af te beelden tussen 100 en 300 mm. Dit geeft een veel duidelijker verschil

Hoofdstuk : Analyse

Figuur 12: Het sequentiediagram voor het tekenen van de cellen

21

tussen twee materialen die niet zo veel van elkaar scheelden. Aan de andere kant, als er een materiaal is dat groter is als 300 mm, dan moet dit ook aangegeven worden door middel van een afgebroken balk. In de layer-composite zelf wordt bijgehouden wat de laagste en wat de hoogste waarde is van de eigenschap. 2.4.2


De layer maakt niet zelf de brush aan om de shape te tekenen, maar vraagt deze aan de brush library. Er werd tevens extra functionaliteit toegevoegd aan het tekengedrag. Het is nu ook mogelijk dat de kind-layer en de ouder-layer onderhandelen over de grote van het kind. Zo is het bijvoorbeeld mogelijk dat het kind maar op 80% van de grote van de door de ouder voorziene ruimte getekend wordt. En kan een kind zowel gecentreerd worden in dit deel, als verplaatst worden naar boven of beneden. Zoals duidelijk gemaakt wordt in volgende figuur.

Figuur 13: Positie kind-layers

Deze positionering wordt volledig configureerbaar gemaakt in het XML-bestand. Dit komt de flexibiliteit ten goede.

2.5

Hoveren en selecteren

Bij het hover proces moet er rond bepaalde rechthoeken een dikkere rand getekend worden, maar enkel die rechthoeken die relevante informatie bezitten voor het deel waar de muis nu opstaat. Selectie doet hetzelfde maar in plaats van een boord te tekenen zal dit proces de verschillende rechthoeken selecteren (in een blauwe kleur zetten). Bij selectie is het ook mogelijk om meerdere delen tegelijk te selecteren door control ingedrukt te houden of door met shift te werken. (control voor enkele delen over de pijp te selecteren, shift voor alle tussenliggende delen te selecteren). Tot hier de verschillen. Zowel bij de hover als bij de selectie moet de x en y coördinaat bepaald worden van de muis. Uit de Y coördinaat kan er afgeleid worden in welke layer de muis staat en kan er ook gekeken worden welke andere layers, geïnteresseerd zijn in het zelfde type data. Er wordt met een visitor over de layer-composite structuur gelopen op zoek naar de layer die de y coördinaat

Hoofdstuk : Analyse

Het hoveren het select proces hebben een grote basis gemeenschappelijk. Het enige verschil tussen de twee is dat het hover proces geactiveerd wordt doordat de muis erover beweegt en het select proces geactiveerd wordt door erop te klikken.

22

bevat. Vervolgens wordt er gekeken welk datatype deze layer voorstelt. Dit wordt samen met de x coördinaat gebruikt als gegevens voor de visitor op de data-composite structuur. Hieruit volgt het data object dat onder de muis zit. Hierop wordt dan ofwel de selectie of hover boolean aangepast. Daarna worden alle layers die geïnteresseerd zijn in dit datatype verwittigd en wordt dit object voor een deel hertekend. Het hertekenen kan ofwel de rand zijn, als het om een hover actie gaat ofwel het inkleuren van de figuur, als het een selectie- actie is. Als er een muisklik geregistreerd wordt, dan gaat het om een selectie en dan moet het ID van de data-composite bijgehouden worden. Enerzijds voor eventuele shift of control combinaties later te kunnen verwerken en anderzijds om een lijst van geselecteerde data-composites door te kunnen geven aan rest van de applicatie. Deze lijst van ID’s wordt tevens gebruikt om te deselecteren. Als er een deselectie plaatsvindt moeten alle geselecteerde composites, degene wiens ID in de lijst zit, hertekend worden.

Hoofdstuk : Analyse

Figuur 14: Statendiagram selectie

23

2.5.1

Het selectie probleem

Dit probleem situeert zich rond de y coördinaat, zoals onderstaand voorbeeld demonstreert. Mocht er enkel op de y coördinaat worden voortgegaan dan zou zowel positie 2 als 3 overeenkomen met de kind-layer, terwijl positie twee eigenlijk de ouder-layer zou moeten selecteren. Dit omdat de kindlayer een variable hoogte heeft. Dit probleem wordt als volgt aangepakt. In plaats van tot op het laatste niveau te zoeken naar de y

Figuur 15: Positie bepaling (rechthoeken)

coördinaat, wordt er gestopt op de layer juist boven de kind-layers. Dit enkel wanneer de kind-layers variabele hoogte hebben zoals in het geïllustreerde voorbeeld. Vervolgens wordt de data-composite gezocht die overeen komt met de ouder-layer. Daarna wordt er over de kinderen van deze data-composite gelopen. Aan de hand van de x coördinaat, omgezet door de ruler naar een juiste tijd, wordt het mogelijke kind object uit de data-composite gehaald. Dan wordt de hoogte van dit object berekend aan de hand van de bepaalde property en geschaald naar de juiste schaal. Dan kan er bepaald worden of de y coördinaat in de ouder- of in de kind-layer geplaatst is. Dit lijkt een omslachtige methode, maar in de praktijk werkt dit zeer snel. Er wordt geen dubbel werk gedaan door deze methode. De afhandeling gebeurt op het einde echter iets anders dan bij de traditionele selectie.

Op dit moment zijn er al twee verschillende vormen in omloop, namelijk de rechthoek zoals deze hierboven en het trapezium. De linker en rechter zijde van het trapezium zijn recht en lopen in parallel; de boven en onderzijde zijn schuin. Het is op deze schuine kant dat er moet gekeken worden of de muiscursor nu in het trapezium zit of in de ouder. Voor de oplossing van dit probleem wordt er gebruik gemaakt van 3 vectoren; de eerste [A-P1], de twee [A-P2] en als laatste vector [A-B]. Als het uitwendige product genomen wordt van [A-B] en [A-P1]

Hoofdstuk : Analyse

Een bijkomend probleem, waarmee eveneens moest rekening gehouden worden tijdens het ontwerpen van deze oplossing, was dat de kind-objecten niet altijd zullen gesymboliseerd worden door rechthoeken. Het kan om het even welke vorm hebben. Vandaar dat deze logica zoveel mogelijk gescheiden moest worden van de rest van de code. Zodoende kan, als er een nieuwe vorm ontwikkeld wordt, dit gepaard gaan met een nieuwe berekening in verband met de y-coördinaat.

24

dan wordt er een nieuwe vector bekomen die weg wijst van het blad. Als het uitwendige product genomen wordt van [A-P2] met [A-B] resulteert dit in vector die in het blad ingaat. Eender welk punt boven de lijn AB zal een resultaat opleveren van een vector die van het blad weg wijst. Dus, als het uitwendige product resulteert in een vector die in het blad wijst dan bestaat er zekerheid dat het punt waarover het gaat onder de lijn AB ligt. Er kan echter op dat moment nog geen uitsluitsel gegeven worden over het feit dat het nu weldegelijk in het kind-object ligt. Daarvoor zal dit principe nogmaals moeten herhaald worden aan de onderkant van het trapezium. Ditmaal moet de resulterende vector weg wijzen van het blad.

Figuur 16: Positie bepaling (trapeziums)

Er kan dus besloten worden dat er twee testen moeten gebeuren. Een gunstig resultaat voor de eerste is een vector die in het blad wijst. Mocht dit al niet het geval zijn, kan er met zekerheid gesteld worden dat het punt niet in het kind-object ligt. Echter als dit wel een gunstig resultaat oplevert moet een tweede test worden uitgevoerd. Als deze test resulteert in een vector die van het blad wegwijst, dan kan er uitsluitsel gegeven worden over het punt. Dit punt zal dan binnen het kind liggen. Mocht hier eveneens de resulterende vector inwaards wijzen dan bevindt het punt zich onder het kind-object en dus in het ouder-object. Als een cirkel ooit een interessante vorm zou worden om te gebruiken, dan moet hier voortgegaan worden op de straal van de cirkel van het kind. Als de straal groter is dan de afstand van het middelpunt tot het punt waar de muiscursor staat, dan ligt het punt in de cirkel; anders ligt het erbuiten.

2.6

Requirements

Wat hier volgt is de requirements van het project bij aanvang van de masterproef. Tijdens de ontwikkeling zijn enkele van deze behoeften weggevallen of aangepast. Tevens zijn er enkele behoeften bijgekomen.

Hoofdstuk : Analyse

Andere, minder courante figuren zullen op het moment van implementatie op hun manier moeten vergeleken worden. In het programma is voorzien dat deze veranderingen een minimale impact zullen hebben op de rest van de code.

25

In dit puntje wordt de confrontatie aangegaan met de vooropgestelde planning en wordt verduidelijkt in hoeverre alles werkelijk werd geïmplementeerd. 2.6.1

Requirements (basis)

2.6.1.1 GUI aspecten •

Één of meerdere planpijpen visualiseren (waarbij men een planpijp kan afschakelen)

•

Verkleinen of vergroten van de form moet een trigger sturen om de ‘drawing’ te schalen: o

(PRI1) Gebruiker kiest steeds voor een bereik (bv. 4uur – 8 uur – 18 uur – alles) Het is de bedoeling dan ook steeds de bedoeling om het bereik volledig te tonen



(PRI2) In principe moet elk object de mogelijkheid hebben om te zeggen dat indien men kleiner wordt dan x dan het object dan niet meer hoeft getekend te worden.

Per planpijp – hiërarchische relaties: o

•



Kinderen van een planpart worden steeds binnen zijn parend getekend. Het moet mogelijk zijn om elk object te kunnen aanklikken (tenzij speciale stilstanden?)

Visualiseren property van een object (configureerbaar): o

Een waarde kan relatief of absoluut worden afgebeeld. bv. RELATIEF hoogte max. hoogte in planpijp 1800mm = 1 en min hoogte 1000 mm = 0,1 of bv. ABSOLUUT 1500mm wordt steeds geschaald aan 0,5

o

Een waarde of een char kan ook voorgesteld worden als een layer. Elke waarde krijgt een kleur waarbij het mogelijk moet zijn om bijvoorbeeld te zeggen A* -> alles wat begint met een A moet kleur ROOD krijgen of waarde tussen 1 en 10 GEEL

o

Bakens zijn speciale objecten die een gebied afbakenen die geldt voor alle daar tussenliggende objecten (tot aan het volgende baken van hetzelfde type). Dit moet ook mogelijk zijn. Elk baken wordt visueel getoond en de balk wordt gekleurd in de bijhorende kleur.

o

Properties kunnen aan of afgeschakeld worden (at run time).

o

sommige properties staan volledig los van de planpijp en hebben enkel een tijdsapect. Bv. de stilstanden in VELOCAP worden niet getoond in de planpijp doch het zou mooi zijn om deze te zien op een tijdsas samen met de planpijp. vb. stilstanden worden gepland onafhankelijk van de planpijp.

o

Afhankelijk waar de muis staat moet/kan de gegevens in statusbalk wijzigen

o

Gelieve ook deze informatie zichtbaar te maken in een vast staand property scherm en/of via een contextmenu (afschakelbaar door gebruiker)

Hoofdstuk : Analyse

•

Regels schalen:

26

•

Naast de standaard kleuren hebben sommige objecten speciale eigenschappen die een andere kleuring, arcering of ‘flikkering’ kunnen veroorzaken (moet niet at run time wijzigbaar zijn – doch indien regels wijzigen moet dit eenvoudig in de code aanpasbaar zijn): Opgelet: arcering/kleuring mag enkel zichtbaar zijn op object en properties van dat object! o

Bv. indien materiaal een ernstige planningsfout heeft dan wordt het object dat de planningsfout heeft in het rood/oranje gekleurd

o

Bv. arcering indien object in de lijn zit etc…

•

Applicatielaag moet mogelijkheid hebben om draw/redraw te triggeren. Ook de gebruiker moet een knop hebben om de redraw te triggeren

•

Gebruiker moet bereik (in- en uitzoomen) kunnen aanpassen

•

Events op objecten (klik-event, drag-drop event, dubbel klik event, etc… moeten opvangbaar zijn)

•

Indien gebruiker geen bevoegdheid in een bepaald gebied moet dit aangeduid worden.

2.6.1.2 Dynamische aspecten

•

Selectie van objecten (bij selectie verandert de kleur!) o

Klik -> selectie van dit enkele object

o

Klik object 1 – shift+klik op object 1 -> aaneengesloten selectie van objecten op zelfde hiërarchisch niveau

o

Ctrl+klik -> bestaande selectie + geselecteerd object

Context in acht nemen: o

Niet alle acties zijn toegelaten indien men zich in één of andere context bevindt Concreet: op werkplanning of op planpijp

•

Op elkaar gelegen bakens -> indien klik opent een klein context menu met alle bakens. Hieruit kan de gebruiker dan het gewenste baken aanklikken.

•

Verslepen bakens (bevoegdheidbakens): mogelijkheid om via drag and drop een baken te slepen over een aantal objecten (een bevoegdheidsbaken mag nooit over een ander bevoegdheidsbaken gesleept worden)

•

Op werkplan:

2.6.2

o

Verwijderen objecten

o

Verslepen object (enkel toegelaten niveaus)

Requirements (optioneel)

2.6.2.1 GUI aspecten •

Bij opstart standaard keuze welke properties aanstaan (ev. user afhankelijk ook voorzien – moet mogelijkheid zijn om ook af te zetten).

Hoofdstuk : Analyse

•

27

•

In- en uitzoomen moet met de scroll

•

Voortgang van de planlijn als muis zich gedurende enkele seconden aan de rand van de planpijp bevindt.

•


Voorzien dat er eventueel andere voorstellingen kunnen gehanteerd worden (buiten relatief of absolute weergave)

•

Aanpassen van de lay-out ook met drag en drop functies (in property window)

•

Maak met dezelfde GUI componenten een andere GUI view

•

Als planpijp verschuift automatisch mee hertekenen

•

Informatie over rolgroep weergeven met popup

•

Visualisatie ruler object

2.6.2.2 Dynamische aspecten • • •

2.6.3

Tot nu toe kan je enkel een opeenvolging van materialen achter elkaar op de lijn zetten. We zouden hier nu ook witruimte tussen willen. Het veranderen van plaats binnen een planpijp ondersteunen (als in proces plan een wijziging wordt doorgevoerd, moet dit zichtbaar worden binnen de planpijp) Bakens generiek opbouwen, niet meer hard coderen. Bijkomende requirements

•

Er moeten ook objecten kunnen gevisualiseerd worden die geen data object hebben

•

Flexibiliteit van de code

•

Het project moet geïntegreerd worden in het grote framework en overdracht van de code

•

De code moet voldoen aan de syntax van ArcelorMittal.

•

De code moet goed gedocumenteerd worden zodat latere programmeurs eenvoudig hun weg terugvinden in de code

•

Meerdere planpijpen visualiseren in een proces in verschillende frames

•

Planpijp moet op eender welk tijdstip kunnen starten (in het verleden en toekomst)

•

WPF of GDI+

•

XML opties: o

Er moet commentaar voorzien worden in XML

o

Case insensitive maken van XML

Hoofdstuk : Analyse

Deze requirements werden niet opgesteld bij de aanvang van de thesis, maar werden tijdens de ontwikkeling noodzakelijk.

28

2.6.4

Status van implementatie

2.6.4.1 Eén of meerdere planpijpen visualiseren De applicatie is niet alleen in staat meerdere planpijpen te visualiseren; het is tevens mogelijk van deze planpijpen ofwel in een ander form te zetten als op hetzelfde form weer te geven. 2.6.4.2

Verkleinen of vergroten van de form

Bij het vergroten of verkleinen van het venster wordt alles hertekend. De ruler wordt geherkalibreerd en er wordt rekening gehouden met het zoembereik dat de gebruiker instelde. Het is zelfs zo dat het zoembereik eenvoudig kan aangepast worden door een dropdown menu of met het gebruik van het muiswiel. De 4 uur, 8 uur, 18 uur, totale zoem waarvan gesproken wordt, is eenvoudig uitbreidbaar en gaat van 1 minuut tot dagen en elke eenheid ertussen. Op dit moment is het echter wel nog zo, dat het tekenen van te kleine objecten nog steeds wordt toegelaten. Dit resulteert in een dunne lijn per object. Het idee achter te kleine objecten niet tekenen is in principe wel goed, gezien je toch niets kan doen met bijna onzichtbare componenten. Maar om verwarring bij de planners te voorkomen, werd er besloten niet automatisch plandelen niet te tekenen. Het is echter zeer eenvoudig om dit in een later stadium toch nog toe te voegen. De draw behaviors, waar later nog op terug gekomen wordt, zijn van deze aard dat ze zeer gemakkelijk die extra functionaliteit kunnen adopteren. 2.6.4.3

Per planpijp – hiërarchische relaties

Dit werd succesvol geïmplementeerd. De precieze werking kan worden nagelezen in puntje 5 Hoveren en selecteren van dit hoofdstuk. 2.6.4.4 Visualiseren properties van een object Op dit moment is enkel de absolute weergave geïmplementeerd. Er werd echter wel rekening gehouden met een andere mogelijke vorm van afbeelden. Het is dus mogelijk eenvoudig nieuwe draw behaviors te maken en eender welke nieuwe vorm van afbeelden te implementeren.

Speciale objecten zoals baken worden op een identieke manier behandeld als andere layers. Ze zijn dus geen uitzondering meer, maar generiek opgebouwd, wat een enorm pluspunt is naar uitbreidbaarheid toe. Een baken bestaat, evenals een gewone layer, uit een naamplaat en cellen. Hij heeft een ander draw behavior als een gewone layer, maar die draw behavior wordt eveneens afgeleid van dezelfde klasse als het draw behavior van een gewone layer en kan dus op dezelfde manier aangesproken worden.

Hoofdstuk : Analyse

Voor het inkleuren van de cellen werd een brush bibliotheek voorzien. Deze is in staat niet alleen verschillende kleuren te gebruiken, maar kan ook zorgen voor speciale gevallen zoals arceringen en dergelijke. De kleur en de brush-stijl zijn beide configureerbaar vanuit XML.

29

Het feit dat properties kunnen aan- en afgeschakeld worden is geen nieuws meer. In punt 5.2 Gebruik GUI van het vorige hoofdstuk wordt dit al verduidelijkt. Om stilstanden te kunnen visualiseren werd een nieuw soort layer voorzien. Dit is de overlay-layer. Deze layer wordt even groot getekend als zijn ouder en heeft enkel een tijdsaanduiding nodig. Deze layer werd geïmplementeerd met als doel stilstanden te kunnen visualiseren. De gegevens in de statusbalk worden aangepast naargelang de muis beweegt. Dit gaat gepaard met een hover-actie. Als een nieuw materiaal geselecteerd wordt, dan wordt naast het tekenen van een rand rond het juiste materiaal ook extra gegevens geplaatst in de status balk. Op dit moment wordt enkel maar het ID van het geselecteerde plandeel weergegeven. Gezien er met dummy data gewerkt wordt, zijn andere properties nog niet ingevuld. 2.6.4.5 Speciale visualisaties Speciale visualisaties zoals planningsfouten, gereserveerde materialen worden afgehandeld in de brush bibliotheek. Een totaal nieuwe vorm van arcering of eender welke andere aanduiding, die in de toekomst eventueel zou kunnen gebruikt worden, kan gebruikt worden via het configuratiebestand aan te passen. Dit wordt mogelijk gemaakt dankzij een techniek reflection genaamd. Deze techniek laat je toe at runtime nieuwe objecten aan te maken vanuit plain tekst, zonder dat er voorkennis aanwezig moet zijn. De kleuren kunnen eveneens via xml geconfigureerd worden. 2.6.4.6 Draw/redraw Het tekenen en hertekenen van het form kan eenvoudig getriggerd worden door de applicatielaag. Er werd tevens een knop voorzien waar de gebruiker zelf de planpijp kan hertekenen. 2.6.4.7 Events De events worden ondersteund door het form en de picturebox. GDI+ objecten ondersteunen echter geen events. Daarvoor zouden WPF componenten moeten gebruikt worden. In deze implementatie werd toch geopteerd om GDI+ te gebruiken: hierop wordt uitgebreid ingegaan in 5.3WPF VS GDI+. De events worden wel gesimuleerd door de muis bewegingen op te vangen en zo de nodige informatie te voorzien. Bevoegdheden

Gezien er nog geen gebruikers waren toegevoegd in de databank, noch gebruikers ondersteund werden in het framework zelf, werd deze requirement achteruit geschoven.

Hoofdstuk : Analyse

2.6.4.8

30

2.6.4.9 Selectie van objecten Het selecteren van objecten is uitgewerkt zoals in de requirements beschreven staat. Wat niet helemaal duidelijk is, is het volgende. Als een bepaald type object geselecteerd wordt en er zijn meerdere properties die gevisualiseerd worden van dat object, moeten alle properties van dat object visueel geselecteerd worden. 2.6.4.10 Context in acht nemen Deze requirement werd geschrapt. Er werd tijdens de ontwikkeling van deze thesis meer nadruk gelegd op een efficiënte visualisatie van de planpijp en een vlotte uitbreidbaarheid. 2.6.4.11 Bakens Gezien bevoegdheden als dusdanig nog niet bestaan kon het verslepen van bevoegdheidsbakens nog niet geïmplementeerd worden. De visualisatie werd, zoals eerder vermeld, wel al gerealiseerd. 2.6.4.12 Werkplan Verwijderen en verslepen van objecten wordt ondersteund door de GUI. Dit moet echter ook door de data-composite toegelaten worden. 2.6.4.13 In- en uitzoomen Het in- en uitzoomen kan zowal met een dropdown menu als met de toetsencombinatie scroll+shift. 2.6.4.14 Voortgang van de planlijn De voortgang van de planlijn wordt op dit moment gerealiseerd door het verschuiven van de scrollbar, onderaan. Het idee was dat als je de muis aan de linker of rechter kant van het form plaatste en even liet staan, dat de planpijp automatisch zou verder gaan. Hoewel dit een nice to have was, is het in praktijk niet zo handig. Hoe gevoelig moet dit ingesteld worden? Want als het te gevoelig is, dan kan het zijn, dat het helemaal niet de bedoeling is van de gebruiker om te beginnen scrollen. Echter als je te lang moet wachten vooraleer het scrollen wordt ingezet, is het sneller om de scrollbar te gebruiken.

2.6.4.15 Aanpassen lay-out De lay-out kan aangepast worden door het aanpassen van de XML. Er werd nog geen GUI voorzien om dit door de gebruiker zelf te laten doen. Hier steekt het vraag, hoever moeten de mogelijkheden reiken tot personalisatie van deze GUI, de kop terug op.

Hoofdstuk : Analyse

Dit programma is echter zo geschreven dat de implementatie van deze optie niet heel veel werk meer vergt. Er werd een scrollfunctie voorzien; door deze aan te spreken kan je gemakkelijk nieuwe manieren van scrollen voorzien.

31

Om dit te realiseren zal er een nieuwe XML file moeten gegenereerd worden die de nieuwe structuur bevat. Deze zal de oude XML moeten vervangen. 2.6.4.16 Andere GUI view Er werden ondertussen al meerdere views gerealiseerd. Zowel voor planpijp van een ander fabriekje op de ArcelorMittal site weer te geven, als iets totaal anders zoals een agenda. Dit wordt gerealiseerd enkel door aanpassingen te doen in de XML file. Er moet niets in de code zelf herschreven worden. 2.6.4.17 Planpijp verschuiven Dit komt erop neer dat de planpijp automatisch en direct mee wordt hertekend als de scrollbar wordt verschoven. Nu het is eigenlijk niet zo dat er iets wordt hertekend, maar de huidige image wordt verschoven, op het moment dat er gescrold wordt. Vroeger werd de planpijp enkel hertekend op het moment dat de scroll afgelopen was. Deze nieuwe optie zorgt ervoor dat de gebruiker zich veel gemakkelijker kan oriënteren in de planning. Vroeger was het een gok om op de juiste plaats terecht te komen. 2.6.4.18 Informatie in popup Dit is zeker een mogelijkheid die ondersteund kan worden. In een Bèta versie van deze applicatie werd dit reeds gerealiseerd. In de uiteindelijke versie zit dit er echter nog niet in. De dummy data waarmee gewerkt werd, heeft eigenlijk nog geen interessante informatie. 2.6.4.19 Visualisatie ruler object De ruler is een soort meter die tijd aanduidt. Deze component wordt nog uitvoerig besproken in 3.2 Bouwstenen. Het idee achter de visualisatie was een aanduiding te geven van tijd op de planpijp. Er komen vele problemen bij kijken die later in 4.5 Tekenprobleem van de ruler behandeld worden. Om deze even kort te schetsen: soms moeten er aanduidingen komen per minuut, soms per uur. Dit moet bepaald worden door de computer en telkens moet de volledige ruler hertekend worden. Uiteindelijk, na een uitvoerige analyse, werd dit niet geïmplementeerd. Dit omdat het voordeel voor de gebruiker niet opweegt ten opzichte van de kost van de implementatie en performantie.

Er wordt tijdens het visualiseren van de verschillende materialen met twee tijden gewerkt: hierdoor hoeven de materialen niet meer aaneengesloten te zijn. Er is nu geweten wanneer een materiaal start en wanneer het stopt. Als de tijden niet aaneensluitend zijn, dan ontstaat er automatisch een witruimte.

Hoofdstuk : Analyse

2.6.4.20 Witruimte tussen materialen

32

Er kan voor gekozen worden deze witruimte extra te benadrukken door een layer te voorzien in een andere kleur. 2.6.4.21 Veranderen van plaats Het veranderen van plaats binnen een planpijp wordt gerealiseerd door in de data-composite de tijden te veranderen van het materiaal. Hierdoor zal ook in de GUI deze verandering gevisualiseerd worden. 2.6.4.22 Bakens generiek opbouwen Een algemene layer is op die manier uitgedacht dat het mogelijk is een baken ook te bekijken als een layer. Hierdoor wordt een layer en een baken op dezelfde manier behandeld. De generieke opbouw van een baken is een feit. Er is geen specifieke code meer nodig om een baken te behandelen. 2.6.4.23 Objecten visualiseren zonder data Deze optie werd pas zeer laat ontdekt. De implementatie was al een heel eind op weg, toen de datacomposite structuur werd gewijzigd. Deze data-composite structuur was een externe inbreng bij de ontwikkeling van de GUI. Uiteindelijk werd het inderdaad mogelijk gemaakt om een structuur te tekenen zonder daadwerkelijke data. Hier wordt verder op ingegaan in 4.4 Visualisatie dubbele takken. 2.6.4.24 Flexibiliteit van de code Ten allen tijden moest de uitbreidbaarheid en flexibiliteit van de code bewaard worden. Dit werd één van de belangrijkste requirements gedurende de ontwikkeling van deze thesis en was ook doorslaggevend voor het uiteindelijke gebruik van de GUI in het uiteindelijke framework. Dit werd vooral gegarandeerd doordat er een grondige studie gemaakt werd van wat de veranderlijke delen waren en deze te scheiden van de vaste delen code. Ook werd er zeer algemeen gewerkt, zodat alles basisobjecten heeft die de basis functionaliteiten bezitten. Als er dan een nieuw object bij komt, kan dit geschreven worden als uitbreiding van het basis object. Dit heeft als voordeel dat alle objecten algemeen kunnen aangesproken worden als basis objecten en dat je niet telkens alle functionaliteit zelf moet schrijven maar je kan beperken tot de specifieke delen.

Op het einde van de implementatie werd de code goedgekeurd en werd ze geïmplementeerd in het framework waarvoor het in de eerste plaats ontwikkeld was. Daarna werd de code ook overgedragen 3 aan de programmeurs op ArcelorMittal.

3

Met code overdracht wordt bedoeld dat de code wordt uitgelegd zodat andere programmeurs eenvoudig wijzigingen kunnen aanbrengen.

Hoofdstuk : Analyse

2.6.4.25 Integratie en overdracht

33

Ook wordt de huidige stand van de implementatie verduidelijkt. Wat werd er nog niet verwezenlijkt, etc. 2.6.4.26 Syntax van ArcelorMittal Bij de aanvang van deze masterproef werd de te gebruiken syntax vastgelegd, en die vindt u tevens terug in de appendix. Deze syntax werd uiteraard gevolgd tijdens het coderen van deze masterproef. 2.6.5

Documentatie code

Goed gedocumenteerde code is de beste gids die een programmeur kan bedenken om door de code te lopen. Deze documentatie wordt zeker belangrijk als andere programmeurs verder moeten werken aan een project dat ze zelf niet gestart zijn. Het was dus van het uiterste belang dat de code goed gedocumenteerd werd. Er werd gebruik gemaakt van de ‘’’ notatie om documenten te genereren, zoals het voorbeeld hieronder aangeeft: ''' <summary> ''' this function will check if a sertain y coord is in the layer ''' ''' <param name="a_ObjPropValue">the value of the property ''' <param name="a_intYCoord">the y coordinate ''' returns default true ''' true because a full layer is the standaard layer and that ''' meens it will alway be in that layer this function has do be ''' overwirtten by special layers! Public Overridable Function IsInLayer(ByVal a_ObjPropValue As Object,_ ByVal a_intYCoord As Integer) As Boolean Implements ILayer.IsInLayer

De code evenals de rest van de code werd allemaal in het Engels geschreven. Gezien ArcelorMittal een internationaal bedrijf is, is de bedrijfstaal Engels. 2.6.5.1 Meerdere planpijpen in verschillende frames

2.6.5.2 Start tijdstip Het start tijdstip van de planpijp moet kunnen ingesteld worden. Dit is inderdaad mogelijk. Op dit moment wordt er wel nog steeds op de nu gestart, maar dit wordt gedaan via een functie die eender welke tijd kan binnenkrijgen. Het is reeds getest en het werkt prima.

Hoofdstuk : Analyse

Dit is in principe een aanpassing van een bestaande requirement. Er werd al eerder gezegd dat er meerdere planpijpen moesten gevisualiseerd worden binnen hetzelfde frame. Later werd hier aan toegevoegd dat het ook in meerdere frames gevisualiseerd moest worden. Dit lijkt op het eerste zicht banaal, maar had wel gevolgen voor de architectuur. Sommige klassen, waar voorheen hoogstens één instantie van bestond, moesten nu meerdere instanties van gemaakt worden.

34

2.6.5.3 XML opties Enerzijds moest de XML file commentaar kunnen bevatten. Blijkbaar wordt dit niet automatisch overgeslagen tijdens het inlezen van het xml-document, maar wordt dit ook bekeken als een node. Daarom moet er een extra test voorzien worden om de commentaar uit het document te halen, anders zou het programma crashen.

Hoofdstuk : Analyse

Verder moet de XML hoofdletterongevoelig zijn voor het gemak van de programmeur. Dit wordt ook ondersteund, door alles in het programma om te zetten naar kleine letters.

35

Hoofdstuk 3

Werking project Good code is its own best documentation. As you're about to add a comment, ask yourself, "How can I improve the code so that this comment isn't needed?" Improve the code and then document it to make it even clearer. Steve McConnell

3.1

Inleiding

In dit hoofdstuk zullen de belangrijkste componenten van het project uitvoerig besproken worden. Tevens zal het verband tussen alle componenten verduidelijkt worden, om uiteindelijk een algemene schets te kunnen geven van de werking van het project.

3.2

Bouwstenen

3.2.1

Unit-convertors

De Unit-convertors liggen mee aan de basiswerking van dit project. Zij staan samen met de ruler, die in het volgende puntje besproken wordt, in voor een juiste plaatsing van de plaatsen van materialen op de planpijp. Dit wordt verwezenlijkt door pixelwaarde om te zetten naar een basiseenheid. De basiseenheid wordt vervolgens geconverteerd naar een specifieke eenheid, zoals tijd, lengte of eender welke andere maateenheid. Het omgekeerde is natuurlijk ook mogelijk, de unit-convertor is eveneens in staat een basiseenheid om te zetten naar een pixelwaarde.

specifieke eenheid krijgen.

Figuur 17: Klassendiagramma unitconvertors

In deze specifieke omgeving wordt de basiseenheid steeds omgezet naar een tijdstip. Er had dus geopteerd kunnen worden alles in één enkele klasse te schrijven. Dit werd echter niet gedaan voor eventueel herbruik van deze code mogelijk te maken. Tevens wordt het statische deel van de berekeningen zo gescheiden van het veranderlijke deel. Voor elke andere unit-convertor moet er nu afgeleid worden van de abstracte klasse en moet er enkel maar het basisgetal geïnterpreteerd worden.

Hoofdstuk : Werking project

Er werd een abstracte basisklasse gemaakt met als doel duplicaten code te vermijden. In de basisklasse zal de conversie van pixels naar een getalwaarde gebeuren. In de afgeleide klassen zal deze getalwaarde een

36

3.2.2

Het ruler object

Het ruler object is één van de andere hoekstenen van dit eindwerk. In dit puntje wordt er wat dieper ingegaan over hoe pixels en tijden een belangrijke rol spelen in het juist plaatsen van de materialen. De ruler is het object waar andere klasse aan vragen om een pixelwaarde om te zetten in een tijdstip. In de ruler wordt deze aanvraag doorgestuurd naar de juiste unit-convertor. De ruler lijkt in de eerste plaats enkel een doorgeefluik van informatie, van de unit-convertor naar de rest van de applicatie. Deze klasse werd in leven geroepen voor latere uitbreidingen aan de ruler te voorzien. Zo was één van de optionele eisen de ruler ook visueel voor te stellen. Daarom werd er gekozen om hiervoor een aparte klasse te maken. Figuur 18: Klassendiagramma Ruler

3.2.3

Composite structuren

Er worden ook twee composite structuren gebruikt. Beide zullen hier even toegelicht worden. 3.2.3.1 Layer-composite

De uitdaging was groot om in de eerste plaats een begrijpbaar xml-structuur op te stellen die voldeed aan al deze eisen. Uiteindelijk werd er besloten drie grote blokken xml te voorzien. Het eerste blok zou instaan voor de structuur van de boom. Gezien er op voorhand niet geweten was hoeveel layers, er waar in de GUI zouden staan, was dit noodzakelijk. Het tweede blok beschreef de functie van een bepaalde layer. Dankzij een unieke identificatie key kon er achterhaald worden waar de layer zich in de structuur bevond. Het derde en laatste blok beschreef de verschillende soorten brushes en pennen die nodig waren voor het tekenen van de cellen in de layers. De vorm van de cellen wordt hier nog even buiten beschouwing gelaten. Deze composite structuur moet opgesteld worden met één eis voor ogen. Er moet snel kunnen bepaald worden wanneer de muiscursor op een layer staat.


De Layer-composite wordt, aan de hand van een xml-bestand, opgebouwd door de GUI zelf. Zoals eerder al vermeld, is dit een zeer generiek systeem dat in alle omstandigheden zeer flexibel moet kunnen omspringen met verandering. Dit zorgde ervoor dat er virtueel niets hard gecodeerd kon worden in verband met deze structuur. Alles wordt ingelezen vanuit het configuratiebestand. Welke brushes er moeten gebruikt worden, welke kleuren en vormen de cellen in de layers kunnen aannemen, etc.

37

3.2.3.2 Data-composite De data-composite is een structuur die niet werd gemaakt binnen het kader van deze masterproef. Deze structuur werd geïmplementeerd door de mensen van ArcelorMittal. In deze masterproef werd de data-composite overlopen om het te visualiseren. Zo komt bijna elke layer-composite overeen met een data-composite en zal een layer een eigenschap van de data weergeven. 3.2.3.3 De structuur De structuur van een data-composite en een layer-composite ziet er als volgt uit:

Figuur 19: Composite structuur

MotherComposite: verwijst naar de moeder van de huidige composite NextComposite: verwijst naar de volgende composite onder dezelfde moeder NextCompositeInLine: verwijst naar de volgende composite ongeacht of dit onder dezelfde moeder zit of niet FirstChild: verwijst naar het eerste kind onder de composite. Deze pointers zijn nodig om eenvoudig over de composite structuur te lopen. Het overlopen van de composite wordt gedaan door visitors.

Deze twee composite structuren worden niet rechtstreeks gemanipuleerd door alle klassen. Er werden respectievelijk twee handlers geschreven een data-composite handler en een layercomposite handler. Deze waren verantwoordelijk voor de verschillende handelingen die konden uitgevoerd worden op de composite structuren. Deze werden in de eerste plaats bestuurd door de controler, maar kunnen ook aangesproken worden door andere klasse indien nodig. Deze handlers zijn ook de klasse die de visitors gingen aanmaken om over de composite te lopen en de uiteindelijke acties op de structuur uit te voeren.


3.2.3.4 Handlers

38

3.2.4

Picturebox Extreme

Dit project bevat een nieuwe component. Deze component is een soort picturebox, maar met de mogelijkheid om te zoemen zonder dat er hertekend moet worden. Deze pixturebox werd ontwikkeld om de GUI een performantie boost te geven. In plaats van een volledige planpijp te hertekenen, werd het mogelijk de image te stretchen. Tevens wordt de scroll balk onderaan automatisch aangepast naargelang de zoom. Dit werd verwezenlijkt door een picturebox in een paneel te steken. Als dan de picture groter wordt, wordt er in het paneel een scrollbar gezet die je toelaat om de picturebox te verplaatsen. Het zoemen wordt gedaan door enerzijds een drop down menu of door shift en de muis scrollwheel te gebruiken. Helaas werd er op het laatste moment toch nog beslist om de picturebox toch niet op deze manier te gebruiken. Dit door onder andere het allising probleem. Het bleek ook dat het hertekenen van alle cellen veel sneller ging dan aanvankelijk was aangenomen. Deze component heeft veel van zijn belang verloren tijdens de evolutie van het project, maar hij wordt toch nog gebruikt. Hij staat nog steeds in voor het verplaatsen van de image en het aanpassen van de grootte van image als blijkt dat de planpijp groter is dan de image op dat moment kan weergeven. Tevens heeft hij de mogelijkheid de image ook terug kleiner te maken als dit nodig blijkt. Hierdoor wordt toch weer een klein beetje aan performantie gewonnen. 3.2.5

Controller

De controller is het kloppende hart van deze applicatie. Het is de delegeerder van alle taken. Er kan maximum één controller bestaan per form. Deze controller bevat alle unieke objecten zoals de ruler, de layer-composite en de data-composite. De interactie tussen de data- en de layer-composite gebeuren dan ook via deze weg. Alles wat nodig is voor een tekenopdracht vindt een layer-object terug in de controller. Elke layer bezit een referentie naar deze controller. Waardoor ze gemakkelijk aan de nodige objecten kan. Mocht er ooit later iets nieuws worden geïntroduceerd of iets worden veranderd, zoals de picturebox, waar een nieuwe of oude layer nood aan zou hebben, dan kan dit gemakkelijk toegevoegd of veranderd worden aan de controller. ObjectBuilder

Deze klasse stelt je in staat om at runtime nieuwe objecten aan te maken. Er werd een systeem in visual studio voorzien om dit te doen. Dit heet reflection en werd reeds kort aangehaald bij de uitleg van het derde testprogramma. De ObjectBuilder die hier gebruikt werd, is een eigen versie hiervan. Zo is deze ObjectBuilder niet alleen in staat om microsoft componenten aan te maken vanuit een string, maar ook eigen gedefinieerde objecten zoals de verschillende layers die worden ingelezen vanuit het XML bestand.


3.2.6

39

De ObjectBuilder heeft hiervoor enerzijds eigen XML file nodig waarin hij de juiste assembly kan vinden en de key die gebruikt zal worden om het object aan te maken. Tot slot heeft de ObjectBuilder ook de exacte locatie nodig in de vorm van een namespace waar het object geacht wordt te staan als er een bepaalde key wordt meegegeven. De ObjectBuilderFile ziet er als volgt uit voor de layers van deze masterproef:

In de code zelf wordt dan volgende code geschreven om het object aan te maken: layer = TryCast(m_ObjectBuilder.BuildObjectFromKey(strType), LayerBasic)

Het strType is het eigenlijke layer type dat u hierboven als ObjectKey zou terugvinden. Deze wordt gecast naar een LayerBasic omdat dit de alles overkoepelende klasse is. In dit geval is het niet van toepassing, maar het is eveneens mogelijk om argumenten mee te geven aan de object builder. In principe werkt de ObjectBuilder eveneens door het laden van de assembly en met reflection dan het juiste object te genereren. Gezien dit zo veel moet gebeuren en op een aantal verschillende plaatsen is ervoor geopteerd om dit door een aparte klasse te laten afhandelen. Layer

De layer, bestaande uit de naamplaat en de cellen, is de belangrijkste visuele component van de GUI. Er wordt een algemene layer interface opgesteld, waar elke layer zich aan moet houden. Verder wordt er een basis klasse gemaakt waar alle layers van afleiden. De basisklasse implementeert de interface en bezit alle basis functies van de layers. Hiertoe kunnen afgeleide layers zich volledig concentreren op hun specifiek deel. Ook naar uitbreidbaarheid toe is dit een goede zaak. Als er een nieuwe layer moet voorzien worden, kan deze gewoon overerven van de basis layer en de layer interface implementeren. De nieuwe layer kan enkele functies van de basis layer overschrijven om zijn eigen node te kunnen bevredigen.


3.2.7

40

Hieronder ziet u de gebruikte structuur. De uitgeklapte versie vindt u in de Appendix onder de paragraaf Klassendiagramma Layers.

Figuur 20: Klassendiagram layers

3.3

Design patterns

Design patterns speelde een belangrijke rol in deze thesis. Dit komt de uitbreidbaarheid ten goede. In deze thesis werden een aantal nieuwe concepten gebruikt, geïnspireerd op oude design patterns. 3.3.1

Unieke container

Dit is geïnspireerd op het singleton pattern. Bij de initiële implementatie was de controler klasse een singleton. Dit werd ongedaan gemaakt gezien er geen unieke controler kon gebruikt worden als er meerdere forms opgestart werden binnen één proces. Andere klasse zoals de layer composite handler en de data composite handler waren ook singleton. Dit moest aangepast worden tijdens de integratie van het stand alone project in het logistiek framework van ArcelorMittal. Er werd geopteerd voor een controler klasse die wordt aangemaakt door het form zelf. Deze klasse zal alle andere unieke objecten bevatten. De controler klasse wordt aan alle objecten meegegeven waardoor deze dan de andere unieke objecten kunnen aanspreken. Er werd dus 1 klasse aangemaakt die alle andere unieke objecten bevat. Deze ene klasse wordt meegegeven aan alle andere objecten, om zodoende een container van unieke objecten mee te geven. Plug-in visitors

Dit is een ander soort pattern dat geïnspireerd is op het visitor pattern. In essentie doet deze visitor het hetzelfde als een normale visitor, maar de plug-in visitor kan veel meer. Bij het normale visitor pattern bestaat er een traversor, die loopt over de composite structuur, en een visitor die een actie uitvoert op de composite. Bij deze versie van visitors hebben we eveneens een traversor, hier rechts preorder visitor genaamd. Deze loopt in preorder over de composite structuur. Naast het overlopen van de composite structuur implementeert hij tevens een interface pluginvisitor. Dit stelt de visitor in staat een nieuwe visitor op


3.3.2

41

te roepen op een bepaalde composite structuur. Deze visitor, in het voorbeeld hiernaast de visible visitor, voert een actie uit op de composite of in dit geval kijkt hij of de composite getekend wordt door de GUI. Als de composite voldoet, zal ook deze visitor de actie van de op zich ingeplugde visitor oproepen. Zo wordt er een toren van acties opgebouwd tot het hoogste niveau wordt bereikt. De laatste visitor zal geen plug-in visitor interface implementeren. Deze zal gewoon zijn actie uitvoeren. De voordelen van deze werkwijze zijn talrijk. Het eerste belangrijke voordeel is naar herbruikbaarheid toe. Zo moet er niet in een visitor telkens geschreven worden of de composite zichtbaar is of niet. Er wordt gewoon een visible visitor tussengestoken, en dan is er geweten of de composite zichtbaar is of niet. Dit komt eveneens de snelheid ten goede; als de composite niet zichtbaar is moeten ook alle bovenliggende visitors niet worden uitgevoerd.

Figuur 21: Plug-in visitors

Tot slot wordt de code ook heel flexibel en eenvoudig uitbreidbaar. Als er een nieuwe test of als er een nieuwe functionaliteit moet worden toegevoegd volstaat het dus een nieuwe visitor te schrijven. De visitor moet ook niet volledige van nul opgebouwd worden omdat al een heel deel van de testen in andere visitors zit en reeds klaar zijn voor gebruik.

3.4

WorkFlow

Dit hoofdstuk werd geschreven op aanvraag van ArcelorMittal en geeft een overzicht van hoe het project juist in elkaar zit. Na de initialisatie van het planpijpform wordt de controler geïnitialiseeerd. Deze initialisatie houdt onder andere in dat de controller op de hoogte wordt gebracht van verschillende pictureboxen waarop later de planpijp gevisualiseerd zal worden. De controler is het hart van de applicatie en zorgt ervoor dat alle handelingen in een goede baan worden geleid. Tijdens de ontwikkeling werd er geopteerd om te werken volgens het MVC, waardoor het ontbreken van een controler klasse ondenkbaar was.

3.4.1

Opbouw layer-composite

Door middel van een eigen XMLParser klasse wordt er een XMLnodeList opgebouwd die als routemap zal dienen om de layer-composite op te bouwen. In volgende functie van de LayerCompositeHandler wordt de layer-composite opgebouwd:

4

Deze werden in het begin van dit hoofdstuk reeds toegelicht


De controler initialiseert en houdt alle belangrijkste bouwstenen 4 bij. Na de initialisatie van de DateConvertor en de Ruler, wordt de layer-composite aangemaakt en ingelezen vanuit xml.

42

Sub toComposite(ByVal a_lstnode As XmlNodeList, ByVal a_intNiveau _ As Integer, ByVal a_compParent As LayerBasic)

In de functie wordt de XmlNodeList node per node overlopen. Dankzij de unieke opbouw van de XML structuur kan de layer-composite structuur zonder problemen afgeleid worden. Elke node bevat tevens een key die verwijst naar een specifiek stuk XML. Dit stuk XML bevat specifieke parameters voor elke layer. Dit stukje XML wordt, nadat de layer werd aangemaakt door de ObjectBuilder in de LayerFactory, door de layer zelf ingelezen. Het meeste inleeswerk wordt gedaan door een basis layer waar alle andere layers van overerven zodat de properties die iedere layer nodig heeft geen meerdere malen moet geschreven worden. Nadat de algemene properties werden ingelezen, wordt de node doorgegeven aan de specifieke layer door middel van een hook functie. (SpecificXMLHook(a_node)). Deze leest dan nog enkele specifieke properties in. Mocht de layer een boolean MinMax op true hebben staan, dan wordt er een extra bewerking uitgevoerd alvorens de layer wordt teruggegeven aan LayerCompositeHandler. Deze MinMax boolean wordt enkel op true gezet als de layer een verschillende hoogte moet weergeven. Deze extra bewerking zal door de data-composite lopen op zoek naar het type en de property waarin de layer geïnteresseerd is. Deze bewerking zal de minimum waarde en de maximum waarde bijhouden en later aan de layer bekend maken. Deze zal de minimum en maximum waarde dan later gebruiken om het hoogteverschil te bepalen. Daarna worden ook de eventuele PlanPartTests 5 van de ouder toegevoegd aan de kind-layer. Tevens wordt er nog een speciale test voorzien om te kijken of de layer van een speciaal type is. Voorlopig bestaat er één speciaal type en dat is de ghost-layer 6. Dan is de layer volledig klaar om zijn rechtmatige plaats op te eisen binnen de composite structuur. Tot slot wordt de functie recursief opgeroepen op alle kinderen van de node die juist werd afgehandeld. Er werd in dit puntje niet dieper ingegaan op de precieze structuur van de XML node. Hierop wordt later teruggekomen in het hoofdstuk over problemen en oplossingen. 3.4.2

De Brush library's

Hier zal er wel even dieper op de XML structuur worden ingegaan, omdat deze later niet meer aan bod zal komen. <painterDef> <status> 40 23 <error> 5 6

Deze testen staan in voor de goede afhandeling van meerdere planpijpen in één form Dit is een layer die gevisualiseerd wordt maar geen data-composite symboliseert.


Nadat de layer-composite is opgebouwd, moeten de brush library’s worden aangemaakt. Dit gebeurt op een soortgelijke manier als de layer-composite. Alleen wordt er hier geen gebruik gemaakt van een boomstructuur om de brushes in op te slaan, maar wel een dictionary waar snel een bepaald type brush kan uit opgezocht worden.

43

40 23

In de painterDef tags vind je als eerste de naam van een specifieke library (bijvoorbeeld: status), welke overeenstemt met de naam van de dictionary waarin de brushes zullen worden toegevoegd. In deze tags vind je de naam van de brush zelf (bijvoorbeeld: reserved). Wat daarin staat, is een nummer dat samenhangt met een type van HatchStyle. De brush library, zoals aangegeven in de LibBurshes klasse, houdt eigenlijk HatchStyles bij en niet de brush zelf. Dit omdat een HatchBrush na creatie niet meer van kleur kan veranderen. De kleur wordt bepaald door de layer waardoor de brush uiteindelijk op het moment van gebruik zal moeten aangemaakt worden. Er zijn verschillende libraries met HatchStyles in omdat er een onderscheid moet kunnen gemaakt worden tussen de verschillende soorten planpijpen. Elke soort planpijp zal een eigen library gebruiken om zijn brushes aan te maken. Als een brushnaam niet wordt teruggevonden in de gespecificeerde library, dan wordt er een solid brush aangemaakt van de gewenste kleur. Als er ook geen kleur wordt weergegeven, dan wordt er standaard gebruik gemaakt van “de kleur” zwart. 3.4.3

Het tekenwerk

Nadat de brushes en de layer-composite in orde zijn, kan er begonnen worden aan het echte tekenwerk. Eerst wordt de linkerkant van de form getekend. Dit is de Layer naamplaat. Vervolgens worden de cellen van de layer getekend. 3.4.3.1 De Layer naamplaat

Daarna wordt er over de layer-composite gelopen en wordt aan elke layer gevraagd zijn naamplaat te tekenen. Dit tekengedrag wordt niet door de layer zelf gedaan. De layer bezit een draw behavior. Op deze problematiek wordt ook verder in gegaan in het 4.3Tekenen van layers.

7

Een canvaslayer is een container waarin één planpijn wordt getekend. Als er meerdere planpijpen op één form komen dan zijn er meerdere canvaslayers nodig.


Voor het tekenen van de layer naamplaat moet de hoogte van de picturebox bepaald worden waarin de naamplaat zal moeten getekend worden. De respectievelijke y coördinaten worden op de rootlayer gezet. Daarna berekent de root layer hoe groot de canvas-layers 7 binnen hem zullen zijn. De layer verdeelt de hoogstens evenredig over de verschillende canvas-layers. Nadat de canvas-layers hun hoogte kennen, worden zij aan het rekenen gezet. Een canvas-layer kan een statische layer, een dynamische en nog een statische layer bevatten. Nadat ook deze hun respectievelijke hoogtes gekregen hebben doen zij weer hetzelfde voor hun kinderen. Dit domino-effect gaat door tot alle layers hun hoogte kennen.

44

3.4.3.2 De layer cellen


Vervolgens worden de cellen getekend. Dit gebeurt in de eerste plaats niet door over de layercomposite te lopen, wat wel het geval was bij het tekenen van de naamplaat. Hier wordt er over de data-composite gelopen. Bij elke data-composite wordt halt gehouden en gevraagd welke layers er geïnteresseerd zijn in dat type data-composite. Hiervoor wordt dan wel over de layer-composite gelopen. Hierdoor wordt er een lijst geproduceerd van layers die geïnteresseerd zijn in dat type composite. Daarna wordt de lijst overlopen en wordt de data-composite, of de property waarin de layer geïnteresseerd is, getekend. Afhankelijk van welke layer het is, wordt dit op een bepaalde manier getekend. Hier spelen de draw behaviors weer een rol.

45

Hoofdstuk 4

Problemen en oplossingen The question of whether computers can think is just like the question of whether submarines can swim. Edsger W. Dijkstra

4.1

Inleiding

In dit hoofdstuk zullen de grootste obstakels besproken worden, die tijdens de masterproef de kop kwamen bovensteken.

4.2

Het layer probleem

Probleemstelling: Er moet een layer lay-out gedefinieerd worden in een XML structuur. Deze staat in voor de juiste plaatsing van de layer binnen het geheel en geeft ook aan met welk soort layer het was. Layers kunnen andere layers bevatten: dit wordt optimaal weergegeven in een XML structuur: <static_layer layerType="…"> <static_child layerType="…"/> <static_child layerType=”…”/> <static_child layerType=”…”/>

Een bijkomend probleem is dat er een relatie moet kunnen teruggevonden worden tussen een kind en zijn ouder. Vragen die moeten beantwoord worden: - hoe wordt er optimaal gebruik gemaakt van de XML structuur? - hoe geven we de ouder- kind relaties aan? - Hoe wordt dit verwezenlijkt zonder duplicatie van XML? Oplossingen: Oplossing 1: Er wordt aan elke layer een layerType attribuut meegegeven. Dit verwijst naar een specifiek XML

Hoofdstuk : Problemen en oplossingen

Het probleem situeert zich rond het feit dat een XML structuur een vrij statische structuur is. Het ligt op voorhand niet vast hoeveel sub layers er moeten zijn. Het verschilt trouwens ook van planlijn tot planlijn. Dus in het programma kan je niet rekenen op vaste naamgeving, noch op het aantal kinderen een layer kan hebben noch over hoe diep die kinderen liggen.

46

blok. In dit blok worden de specifieke eigenschappen van het layerobject ingevuld. Naast dit layerType wordt ook nog een parent attribuut meegegeven; hierin zit het type van de ouder. Zo kan er gevonden worden welke ouder bij welk kind hoort. De types van de verschillende layers ligt wel vast met als gevolg dat er zo wel uitsluitsel kan gegeven worden over wie de ouder is. <static_layer layerType="…" ParentType=”…”> <static_child layerType=”…” ParentType=”…”/>

Deze oplossing biedt een goede oplossing voor het niet dupliceren van XML code, door een layertype te definiëren. Echter het parentType dat eveneens moet worden meegegeven, is geen goede oplossing. Er kan een eigenlijk ook uit de structuur worden afgeleid wie de ouder is van welk kind. Oplossing 2: Als er door de XML structuur gelopen wordt kan er een string path bijgehouden worden; zo kan er achteraf gezocht worden naar de kinderen van de dynamic-layer zonder dat er door de volledige XML structuur moet gelopen worden. Dit gebeurt als volgt: er wordt één maal door de volledige XML structuur gelopen. Tijdens het doorlopen wordt het doorlopen path bijgehouden. Als er dus gezocht moet worden naar de kinderen van de dynamic-layer weten we dat deze zich situeren onder: root/dynamic-layer. Dus hierdoor wordt het ParentType overbodig. Het nadeel van deze oplossing is echter dat er telkens opnieuw moet gezocht worden in de XML structuur en dit is onaanvaardbaar. Oplossing 3: Een andere mogelijkheid is de XML structuur overlopen en ook direct alles omzetten in objecten en deze vervolgens in een boomstructuur steken zodat er een ouder-kind relatie ontstaat. Zo kan er gemakkelijk uitgezocht worden welke layer welke ouder-layer heeft. Deze structuur kan vervolgens overlopen worden met een visitor op zoek naar een specifiek type.

De structuur wordt optimaal gebruikt. De ouder- kind relaties worden afgeleid uit de XML structuur zelf. Dit lost ook de tweede vraag op, eens de structuur van de XML is nagebouwd in de boom. Hoe dit juist gebeurt werd reeds in een eerder puntje besproken. Tot slot wordt er dankzij het type Layer ook duplicatie van XML vermeden. De uiteindelijke structuur ziet er als volgt uit:


Uiteindelijk is dit de beste oplossing. Zo moet je niet telkens opnieuw naar de XML kijken. Wat echter wel moet gebeuren is dat vanaf het moment er iets wijzigt in de XML structuur, deze ook moet doorgevoerd worden in de boomstructuur. Gezien deze actie zeldzamer is dan een opzoeking in de structuur wordt aanvaard. Op dat moment zal de XML opnieuw overlopen worden.

47

Caster Ghost 80 1 True <Style type="status"> <Style type="error"> 255 250 205 <SpecPlanpartTest> Castertester <parameters>


Een stukje specifieke XML:

48

4.3

Tekenen van layers

Oorspronkelijk was het idee alles door de controller zelf te laten tekenen, maar dit bleek als snel rijkelijk onvoldoende. Probleemstelling: Op één of andere manier moeten de layers getekend worden. Zoals al eerder werd aangehaald, bestaat een layer uit een naamplaat en een reeks cellen. De naamplaat tekenen geeft niet veel problemen, gezien deze uniform zijn voor alle layers. De cellen is een andere zaak. Vele cellen worden op dezelfde manier getekend, maar er kan toch een onderscheid gemaakt worden tussen de verschillende cellen. Zo heeft u de cellen met een vaste en een variabele hoogte, om over de bakens maar te zwijgen. Dus, hoewel er voor cellen van hetzelfde type de zelfde visualisatie moet gebruikt worden, varieert de visualisatie van type tot type. Tevens moet er naar de toekomst toe rekening gehouden worden met eventuele uitbreidingen en nieuwe stijlen van tekenen. Vragen die moeten beantwoord worden: - hoe wordt duplicate code vermeden? - hoe wordt de veiligheid van de code gegarandeerd? - hoe wordt een flexibele, snel uitbreidbare structuur gegarandeerd? - Alle verschillende types moeten op één zelfde manier aangesproken kunnen worden vanuit andere klassen, zonder dat zij moeten weten van welk type de layer is. Hoe wordt dit best gerealiseerd?

Oplossingen: Er werden twee prominente oplossingen naar voor geschoven, bovenstaande oplossing niet meegerekend uiteraard.

Gezien alles binnen één klasse zit en de gespecialiseerde layers weten welke tekenstijl zij nodig hebben, eventueel ingefluisterd door het xml-bestand, is het eenvoudig om in andere klasse gewoon de layer aan te spreken zonder het specifieke type te kennen. Het schoentje wringt echter bij de veiligheid van de code. Is het wenselijk dat elke layer kennis heeft van alle andere tekenstijlen? Een aanpassing aan deze oplossing kan dit verhelpen. De verschillende tekenstijlen worden uit de basis klasse gehaald en in een aparte klasse ondergebracht. Deze heeft verschillende interfaces geïmplementeerd die telkens delen van de code afschermen naar de buitenwereld toe. Elke layer heeft een object van deze klasse in zijn bezit, maar telkens met een andere interface. Zodoende hebben ze maar een beperkte kennis van wat het object eigenlijk kan doen. U kan het zich het best voorstellen als een doos waarin het object zit en elke kant heeft een kijkgaatje, maar iedereen kan


Oplossing 1: In deze oplossing wordt alle functionaliteit in één klasse gestoken: dit is de LayerBasic klasse waar alle andere layers van afgeleid worden. Dus in principe bevat nu elke layer de kennis om eerder welke type layer te tekenen. Dit voorkomt in ieder geval duplicate code. Elke tekenstijl wordt slechts één maal gedefinieerd. Naar uitbreiding toe, moeten nieuwe tekenstijlen toegevoegd worden aan de basis klasse, waardoor elke andere afgeleide klasse ook kennis heeft van deze nieuwe stijl en dus eventueel kan gebruikt worden.

49

maar slechts langs één kijkgaatje kijken en dus maar één aspect van het object bekijken. Dit principe wordt dit hier verwezenlijkt met gebruik van interfaces. Oplossing 2: Deze oplossing gaat veel verder met het uiteentrekken van de functionaliteit. Er worden tekenstijl behaviors aangemaakt. Deze gedragingen worden aan de respectievelijke layers toegekend. Als de layer dan moet getekend worden, wordt dit door het tekengedrag gedaan dat die layer bezit. Gezien deze gedragscodes eveneens maar één maal moeten gedefinieerd worden, kan ook deze oplossing het argument van mogelijke duplicate code de kop indrukken. Elke layer van hetzelfde type maakt gewoon eenzelfde tekenstijl gedrag object aan, waardoor ze dus eveneens allemaal hetzelfde getekend worden. Er is ook geen reden meer om zich zorgen te maken over interfaces en afschermen van code gezien elke tekenstijl maar één stijl bevat. Naar uitbreiding toe is deze oplossing ook goed. Er moet gewoon een nieuwe tekenstijl gedefinieerd worden in een nieuwe klasse. Deze tekenstijl erft over van een basis tekenstijl of implementeert de interface en je kan elke interface op dezelfde manier aanspreken. Een extra voordeel ten opzichte van de eerste oplossing is dat je niets in een bestaande klasse moet toevoegen, noch nieuwe interfaces moet voorzien. Het enige is de nieuwe klasse die de tekenstijl beschrijft. Elke layer heeft zijn tekenstijl die hij alleen kent en op een universele manier kan aangesproken worden binnen de layer. Naar de buitenwereld toe heeft de layer enkel een draw functie om de layer te tekenen. In die layer wordt dit dan doorgepropageerd naar de tekenstijl van de layer. Dus de buitenwereld spreekt elke soort layer op dezelfde manier aan.

4.4

Visualisatie dubbele takken

Probleemstelling: Tot hier toe is er nog niet gesproken over layers die geïnteresseerd zijn in hetzelfde type en dezelfde property, maar deel uitmaken van een andere tak. Helaas is het ook mogelijk om twee takken te hebben in de composite structuur die elk starten op hetzelfde tijdstip en parallel geproduceerd worden. Dit ondermijnt echter het principe van zoeken naar geïnteresseerde layers op basis van het composite type alleen.

Merk op dat dit een voorbeeldstructuur is om het probleem te illustreren. Andere visualisaties hebben uiteraard andere structuren. Er mag dus bij de oplossing niet vanuit gegaan worden dat de dubbele tak juist onder de root zit. In dit geval zit er onder de composite MDPRoot een aantal dubbele takken met een zelfde structuur, hier caster genoemd. Het zijn dus (Roman & Petrusha, VB.NET Language in a nutshell, 2001) de casters materialen die onder de casters zitten die parallel moeten geproduceerd worden.


Schetsen voorbeeldprobleem: De huidige Data structuur ziet er als volgt uit:

50

Figuur 22: Voorbeeld composite

Zowel de ene als de andere caster start om 9 uur en eindigt om 10 uur. De charges onder de caster worden in volgorde geproduceerd: de eerste charge wordt geproduceerd van 9:00 tot 9:05, de tweede van 9:05 tot 9:10,… . De eerste charge van de tweede caster start eveneens om 9:00 en eindigt om 9:05,… De overeenkomstige XML voor deze structuur is:

Vragen die moeten beantwoord worden: - Hoe wordt er onderscheid gemaakt tussen de twee takken? - Hoe koppel je de layer-composite aan de data-composite? - Dit is specifiek voor verschillende views. Hoe zorg je ervoor dat die specifieke deel toch flexibel genoeg om veranderingen te kunnen opvangen? Oplossingen: Oplossing 1: De eerste oplossing die werd geopperd was een welbepaalde Interface te implementeren op de Caster van de data-composite. Van deze oplossing werd echter snel afgezien aangezien dit niet conform was met de business logica.


51

Oplossing 2: Een andere oplossing is de ID van de Caster van de data-composite bij te houden, in de geïnteresseerde layer-composite. Dit lijkt op het eerste zicht een goede oplossing te zijn, maar wat dan, als er dan een charge data composite type zit? Dan moet er eerst gekeken worden naar wat de caster is van deze charge. Deze oplossing klinkt al vrij aannemelijk. Hoe goed beantwoordt ze aan de vragen? - Er wordt een onderscheid gemaakt tussen takken door middel van ID’s - de koppeling tussen de layer-composite en de data-composite gebeurt eveneens aan de hand van die zelfde ID’s - Er wordt steeds gezocht een een ID dat een onderscheid maakt, maar waar van is dat ID? Er mag niet van uit gegaan worden dat het om een caster gaat. Dus er kan niet zomaar algemeen gezocht worden. Mits wat bijsturen kan deze oplossing wel gebruikt worden. Echter, toen er over deze oplossing werd nagedacht, is er een ander probleem naar boven gekomen. Dit heeft niet rechtstreeks te maken met deze masterproef en ik zal hier ook niet verder op ingaan. Het gevolg evenwel was het schrappen van de casters. Oplossing 3: Door het schrappen van de caster composite moet er een nieuwe manier gevonden worden om te bepalen welke composite nu deel uitmaakt van welke caster. Gezien de vorige oplossing al vrij goed was, zal hier op worden verder gebouwd. Er wordt nu een fictief ID bijgehouden in de tundishgroups. Alle tundishgroups van de eerste caster hebben uiteraard hetzelfde ID. De eerste twee vragen kunnen op dezelfde manier beantwoord worden als in oplossing twee. Voor het derde antwoord moet er nog wat meer informatie verschaft worden. Er zal een specifiek stuk code geschreven moeten worden om te bepalen tot welk ID een kind composite behoort. Dit is voor elke data-composite structuur anders. Er wordt dus verlangd dat dit stuk code uitwisselbaar is naargelang de structuur. Hiervoor moet er wat extra voorzien worden in de XML structuur die de layer-composite beschrijft.

De bedoeling van dit stukje xml is het volgende: er wordt een nieuwe class CasterTester gemaakt welke een specifieke check functie heeft met twee parameters. Enerzijds de composite waarvan je wilt weten in welke virtuele caster het zit en anderzijds de id van de caster waarin de layer in geïnteresseerd is. Deze check functie zal uiteindelijk een boolean teruggeven. True als de composite in de juiste virtuele caster zit en false als die er niet in zit. 4.4.1

Bijkomende problemen

Gezien nu de data-composite structuur niet meer overeenkomt met de layer-composite structuur, betekent dit dat een deel van het project herwerkt moest worden. Er moet extra logica voorzien worden om sommige bijzondere gevallen op te vangen. Zo werd er voorheen gerekend op de


<SpecPlanpartTest> Castertester <parameters> 1

52

corresponderende data-composite om de cellen van de layer te kunnen tekenen. Hierop kan nu echter niet meer gesteund worden. Hierop werd het volgende bedacht: layers die niet in relatie staan met data-composites, worden getekend door zijn ouder-layer, in de layer-composite. Zij zullen dus naast zichzelf ook kijken of er eventuele ghost layers onder hen zitten. Als dit het geval is dan zullen ze ook deze hertekenen op het moment dat ze zichzelf hertekenen.

4.5

Tekenprobleem van de ruler

Eén van de bijkomende requirements was het visualiseren van het ruler object. Hier stellen zich echter een aantal vervelende problemen. Zoals: hoe teken je iets waarvan je de eenheid niet zeker weet? Er zou dus een functie moeten voorzien worden in de unit convertors om de plaatsen te bepalen van de verschillende dagen, uren en minuten. Nu deze functionaliteit daar implementeren is niet de grootste moeilijkheid: het is hoogstens wat onoverzichtelijk. Een groter probleem hebben we als de streepjes van de verschillende minuten zo dicht op elkaar liggen dat het niet meer uit te maken is wel streepje welke minuut voorstelt. Het gevolg van zoveel minuten op elkaar, is een dikke zwarte lijn in plaats van allemaal fijne lijntjes. Er zullen dus minuut aanduidingen moeten weggelaten worden om het overzicht te kunnen behouden. Als er dan wordt ingezoomd op een bepaald deel, kan er dan voor geopteerd worden om de minuut streepjes wel terug te zetten. Hoe weet de ruler nu wanneer er wel minuut streepjes moet gezet worden?


Dit probleem werd niet verder bekeken. Het nut van de visualisatie van de ruler woog niet op tegen de tijd die moest gespendeerd worden om de implementatie en het resultaat vlekkeloos te doen verlopen.

53

Hoofdstuk 5

Gebruikte technologieën Computers are good at following instructions, but not at reading your mind. Donald Knuth

5.1

Inleiding

In dit hoofdstuk wordt een overzicht gegeven van de gebruikte technologie, een bespreking van de technologieën en waarom er voor dit soort technologie gekozen werd. Tevens wordt de richtprijs van het product gegeven.

5.2

VB.NET (VB 9.0)

5.2.1

Bespreking

Visual basic.NET of vb.net is een onderdeel van het Visual studio softwarepakket. Het programma werd geschreven in vb.net. De keuze van deze software werd bepaald door Figuur 23: .Net logo (http://blogs.msdn.com) ArcelorMittal. De ontwikkeling van het nieuwe framework, waar deze applicatie ook deel van uitmaakte, was reeds gestart. Bij de aanvang van deze ontwikkeling is de keuze gevallen op vb.net omdat de know how van vb.net in het bedrijf rijkelijk vertegenwoordigd is. Verder is het ook een zeer aangename taal om in te programmeren, met alle voordelen van een Object georiënteerde taal en moderne debug mogelijkheden zoals quick watches. Vernieuwende aspecten Het belangrijkste vernieuwende aspect waarmee werd gewerkt in deze thesis is het XDocument. Dit maakt het mogelijk om op een zeer eenvoudige manier xml te manipuleren. Ook XElement en XAttribuut zijn zeer belangrijke vernieuwingen waarmee wordt gewerkt in deze thesis. Dankzij deze vernieuwingen is het mogelijk om nieuwe XML-elementen te maken zonder dat je een xml document nodig hebt waarin alles instaat. Dit zorgt ervoor dat er tussen de applicaties onderling ook gecommuniceerd kan worden met XML. Dit werd onder andere gebruikt om configuraties door te sturen van de GUI naar andere Figuur 24: Visual Studio 2008 (http://www.techhunt.org)

Hoofdstuk : Gebruikte technologieën

5.2.2

54

applicaties binnen het framework. 8 5.2.3

Richtprijs

Het volledige Visual studio 2008 pakket komt op een 1 282 euro. Het is ook mogelijk om enkel VB.Net aan te schaffen. Microsoft heeft zelfs een gratis trail versie uitgebracht waar je, je mee vertrouwd kan maken.

5.3

WPF VS GDI+

5.3.1

Bespreking

Shapes, daar draait het allemaal rond. WPF en GDI+ zijn beide manieren om shapes te tekenen in een form. WPF is een relatief jong systeem, maar heeft een aantal goede troeven. Zo kan WPF gemakkelijk overweg met events terwijl GDI+ event niet zelf ondersteunt. Bij GDI+ zal alles custom moeten getekend en zelf geschreven worden. Ook om events op te vangen zal er een custom control moeten gemaakt worden die de events opvangt voor de GDI+ shape. Dit is geen onoverkomelijke zaak, maar het blijft handiger met WPF. Dit eerste punt is ook meteen één van de belangrijkste punten in dit project. Er worden namelijk enorm veel shapes, meestal rechthoeken, getekend die een bepaald object representeren. Als er gehoverd wordt over één van deze shapes, moet er een event geraised worden. Hierdoor kan dan de corresponderende informatie op het scherm weergegeven worden. Verder kan WPF gerenderd worden op hardware of op software als het niet mogelijk is om op hardware te renderen. Dit zorgt ervoor dat een betere video kaart sneller een goed resultaat genereert. GDI+ is geheel software gebaseerd. Een nadeel van WPF is dat het nog vrij jong is en enkel ondersteund wordt door de latere.NET frameworks (.NET 2.0 en hoger).

Het feit dat GDI+ geen events ondersteunt, wordt opgevangen door de mouse position te converteren naar een datetime. Deze kan op zijn beurt dan gebruikt worden om te bepalen welk object achter het blok schuil gaat. Een ander voordeel van deze werkwijze is dat de GUI laag totaal geen kennis moet bijhouden van de getekende objecten. 5.3.2

Richtprijs

Dit is een onderdeel van het .NET framework, en gezien dit ook nog voor andere doelen gebruikt wordt brengt dit geen extra kost met zich mee.

8

Meer informatie over vernieuwende aspecten vindt u in Beijer, M. d. (2009). Visual Basic 9.0 belooft veel goeds. advertentie Microsoft Press , 1-4.


Uiteindelijk is er ondanks de bruikbare events, die WPF genereren, toch gekozen om GDI+ te gebruiken. GDI+ werkt met pixel based drawing actions, wat enorm handig is voor het precies tekenen van een shape op een bepaald tijdstip.

55

5.4

Visual SourceSafe 2005

5.4.1

Bespreking

Visual SourceSafe heeft twee belangrijke waarden gehad voor deze thesis. Enerzijds werd het, dankzij SourceSafe mogelijk om op een eenvoudige manier van geschreven code een backup te nemen. Deze software stond ook toe om lables te leggen om eenvoudig terug te keren naar vorige versies, mocht er op de huidige versie iets mis gelopen zijn. Dit was zeer handig als je eens iets wilde uitproberen, maar niet zeker was dat het wel zou werken. Anderzijds was SourceSafe heel handig om geschreven code uit te wisselen met andere mensen. Deze software Figuur 25: Visual SourceSave 2005 (http://content.etilize.com/Large/10951676.jpg) beheerde de code pool als het ware. Zo was het zeer gemakkelijk om feedback te krijgen van andere programmeurs over de geschreven code en kon eenvoudig updates uitgewisseld worden van het framework. Het is zo mogelijk om binnen een zelfde applicatie met meerdere programmeurs tegelijkertijd bezig te zijn. Je houd enkel de files vast waar jij op dat moment mee bezig bent. Deze staan op checked out. Dit wil zeggen dat niemand buiten jij de files kan aanpassen. Daarna check je de files terug in en kan iedereen aan de nieuwe versie van de files. 5.4.2

Richtprijs

5.5

Javascript

5.5.1

Bespreking

Deze taal werd gebruikt om een Excel bestand automatisch in te lezen op de website: zodoende kon de website eenvoudig up to date gehouden worden.

5.6

Visio 2007

5.6.1

Bespreking

Is een schema tool die je toelaat om UML diagrammen te maken. Deze tool werd gebruikt in de eerste analyse, in augustus. Voor de tweede, uitgebreidere analyse werd

Figuur 26: Office Visio Logo (www.visioprojecttoolkit.com)


De richtprijs van deze software is 512,90 euro. Deze software werd voorzien op ArcelorMittal.

56

overgeschakeld op UModel. Deze module wordt later nog besproken. Om kort even de voordelen te schetsen. UModel laat toe software te generen vanuit schema’s en omgekeerd. Dit is niet mogelijk met Visio. 5.6.2

Richtprijs

Het grootste voordeel van dit pakket is dat het gratis te downloaden is van de microsoft website.

5.7

UModel (Altova)

5.7.1

Bespreking

Umodel is een programma dat je toelaat om eenvoudig UML diagrammen te maken. Alle diagrammen die u in deze masterproef terugvindt zijn gemaakt met behulp van deze software. Dit product laat je eenvoudig toe om verschillende diagrammen te genereren en aan de hand van deze schema’s kan ook al een deel van de code geschreven worden, of toch zeker de interfases gegenereerd worden. Richtprijs

Figuur 27: UModel Altova (http://i42.tinypic.com/103ec00.jpg)

De richtprijs van dit product is 149 euro.

5.8

Check point VPN-1 SecureCient

5.8.1

Bespreking

Dit programma laat de gebruiker toe om een remote connectie te maken naar een computer op ArcelorMittal. Hiervoor heeft u eveneens een pincode en een digipass nodig. De pincode wordt ingegeven in de digipass en deze genereert een paswoord dat u dan kan gebruiken om een connectie op te zetten naar ArcelorMittal.


Dit in combinatie met Remote Desktop Connection, een standaard tool van microsoft, is het mogelijk een pc over te nemen. Zo kan u ook van thuis verder werken.

57

5.9

Adobe Photoshop CS4 5.9.1 Bespreking Adobe photoshop is een grafisch pakket dat onder andere fotobewerking en ontwikkeling van grafische interfases toelaat. Dit pakket werd gebruikt voor het ontwikkelen van de template van de masterproef website. Tevens werd dit gebruikt om de poster in te ontwikkelen. De kennis over dit softwarepakket is vergaard door zelfstudie.

Figuur 28: Adobe Photoshop CS4 (http://www.letsgodigital.org)

5.9.2

Richtprijs

De richtprijs voor dit software pakket is 699,99 euro.

5.10

Dreamweaver 8

5.10.1

Bespreking

Dreamweaver werd gebruikt om de masterproef site eenvoudig op te bouwen aan de hand van de template die met photoshop werd gemaakt. Dit programma liet ook doe de site snel up to date te brengen. Verder bood het een uitstekend platform voor debugging en

ontwikkeling van de site. 5.10.2

Figuur 29: Dreamweaver 8 (http://i37.tinypic.com/e193yc.jpg)

Richtprijs

5.11

Office 2007

5.11.1

Bespreking

Word 2007 werd gebruikt om de thesis in te schrijven. Deze vernieuwde versie van office biedt heel wat voordelen ten opzichte van zijn voorgangers en concurrenten. Zo worden bibliografieën en figurenlijsten nu automatisch gegenereerd. Ook zijn de opmaakprofielen in een nieuw modern jasje gestoken waardoor het geheel mooi en overzichtelijk overkomt.


De richtprijs voor dit software pakket is 399,99 euro.

58

PowerPoint onderging dezelfde transformatie. De keuze om dit programma te gebruiken voor de verdediging van mijn thesis was dan ook snel genomen. 5.11.2

Richtprijs

De richtprijs voor dit software pakket is 125 euro voor studenten en 260 euro voor particulieren.

5.12

Camtasia studio

5.12.1

Bespreking

Figuur 30: Office 2007 (http://kvproit.nl/osCommerce/index.php?c Path=21)

Dit is een softwarepakket dat de gebruiker in staat stelt zijn computerscherm op te nemen. In die hoedanigheid kan de gebruiker dan video tutorials maken om iets duidelijk en in een visuele context uit te leggen. Deze software werd gebruikt om een demo op te nemen van deze masterproef. Deze demo kan bekeken worden op de website van deze masterproef. 5.12.2

Richtprijs

Er is een 60 dagen trail versie van deze software beschikbaar, welke volledig gratis is. Echter als u het softwarepakket wilt aankopen, betaalt u al snel een kleine 300 euro.


Figuur 31: Camtasia Studio (www.softwarecasa.com/camtasia-studio.htm)

59

Hoofdstuk 6

Resultaten We need above all to know about changes; no one wants or needs to be reminded 16 hours a day that his shoes are on. David Hubel

6.1

Inleiding

Het project startte als een stand alone project. Dit was zeer eenvoudig en veilig voor de ontwikkeling. Eenvoudig omdat er binnen dit project niemand anders werkte. Dus er moest geen rekening gehouden worden met andere programmeurs. Veilig, omdat de code afgeschermd zat van de rest van het project. Zodoende kon deze code geen schade berokkenen aan de rest van het framework. Wat niet wil zeggen dat er geen rekening gehouden moest worden met andere code. Het was van het begin af de bedoeling dit project te integreren in het framework. Dus naast de code afspraken moesten ook een aantal interfaces gerespecteerd worden. Dit project verwerkt ook data die het krijgt van externe bronnen. Deze interactie moest ook volgens bepaalde regels verlopen. Hierdoor zou later bij de integratie grote problemen kunnen vermeden worden. De resultaten die bekomen werden zouden niet gerealiseerd kunnen geworden zijn als er niet zo een goede communicatie was tussen de verschillende leden van het team. Er werd veel besproken tijdens en ook buiten de vergaderingen. Vaak werd er gewoon samen gezeten om gemeenschappelijke problemen aan te pakken.

6.2

Testen

Het testen en debuggen van de applicatie was een van de belangrijkste en meest cruciale zaken, zeker omdat het de bedoeling was om mijn thesisproject ook later te gebruiken in de bedrijfsomgeving. 6.2.1

Dummy data

Het testen gebeurde in de eerste plaats met dummy data. Deze werd gegenereerd door een klein project en gaf een datastructuur terug die een planning voorstelde. Met deze dummy data kon de GUI grondig getest worden.

Meestal ging de overgang tot volgende datastructuren gepaard met een uitvoerige bespreking van de tot dan toe gerealiseerde resultaten. Ook werd de GUI telkens getest door mijzelf en andere. Er werden menige vergaderingen belegd over de vooruitgang van dit project.

Hoofdstuk : Resultaten

Er werd gestart met een basis datastructuur. Eens deze zonder problemen werd gevisualiseerd door de GUI, werd er overgegaan tot een ingewikkeldere structuur. Dit proces ging voort tot de GUI uiteindelijk in staat was de meest complexe datastructuren te visualiseren.

60

6.2.2

Nieuw type layer

Nadat de GUI inderdaad in staat bleek te zijn om telkens opnieuw verschillende planpijpen te visualiseren, werd er een volgende test uitgevoerd. Hierbij werd de uitbreidbaarheid van de GUI getest. Het was de bedoeling een nieuw type layer te voorzien, met een nieuwe tekenstijl. De GUI zette een sterk resultaat neer. In minder dan een uur was het mogelijk een totaal nieuw type layer, niet alleen te visualiseren maar ook volledig werkend te hebben binnen het project. Er was een volledige dag voorzien om deze code te schrijven en te testen, maar na één uur slechts bleek alles al prima te werken. Het nieuwe type layer dat geschreven werd was het baken, dat u ook kon zien op de screenshot in het begin van deze thesis. Naast het feit dat het baken op een andere manier geselecteerd kan worden, is het zo dat een baken niet aan een materiaal gebonden is, en dus niet per definitie eigenschappen weergeeft van het materiaal. Het is een onafhankelijke data-composite en dus verschillende van de data-composite die een normale layer weergeeft. Dit om aan te tonen dat een baken inderdaad heel anders is als een gewone layer. 6.2.3

Flexibiliteit en uitbreidbaarheid

In dit stukje zal het proces beschreven worden van een aanpassing die moet gebeuren aan de GUI. De opdracht is niet eenvoudig. Er wordt gevraagd de statusbalk, die voorheen statisch was, configureerbaar te maken via XML. Hier moet enerzijds de configuratiefile worden aangepast en anderzijds moet deze ook verwerkt worden in de achterliggende code. In deze paragraaf zal deze omzetting stap voor stap beschreven worden, enerzijds om latere mogelijke uitbreidingen te spiegelen aan dit voorbeeld en anderzijds om aan te tonen hoe eenvoudig dit verloopt. 6.2.3.1 Aanpassen XML

Total Weight: TotalWeight Start Time: TimeLineStart Stop Time: TimeLineStop


De eerste stap is het aanpassen van de XML. Er moet een goede structuur bedacht worden die de juiste informatie goed weergeeft. In dit geval moet er informatie weergegeven worden in de statusbalk. De informatie bestaat uit een naam en een waarde van een bepaalde property. De XML structuur die deze informatie zal bevatten, ziet er als volgt uit:

61

6.2.3.2 Aanpassen LayerBacis Gezien dit een eigenschap is die alle layers moet bezitten, wordt deze toegevoegd in de LayerBasic klasse bij het inlezen van de XML file. Mocht de nieuwe mogelijkheid enkel betrekking hebben tot een beperkt aantal layers, kan deze ingelezen worden via de hook functie. Deze functie speelt de XML door naar de verschillende specifieke layers zodat zij specifieke info kunnen inlezen in hun porperties. In dit geval is het dus nodig van deze inlezing voor alle layers te voorzien. Hiertoe wordt volgende functie geschreven om bovenstaande XML in te lezen: If (.ContainsItem(a_node, "DisplayInfo")) Then Dim nodeDisplayInfo As XmlNode = a_node.SelectSingleNode("DisplayInfo") Dim nodelist As XmlNodeList = nodeDisplayInfo.SelectNodes("item") For Each nodeInfo As XmlNode In nodelist Dim caption As String = nodeInfo.Item("Caption").InnerText Dim propertyName As String = nodeInfo.Item("Property").InnerText m_dicDisplayInfo.Add(caption, propertyName) Next End If

De m_dicDisplayInfo die gebruikt wordt in deze functie werd speciaal aangemaakt om deze informatie in op te slaan. Later zal deze dictionery gebruikt worden om de properties te overlopen. Tevens wordt er in de LayerBasic een property voorzien om eenvoudig de dictionery te kunnen bemachtigen vanuit een andere klasse. 6.2.3.3 Aanpassen Controler De controller is het hart van de applicatie en regelt alle interacties met de GUI. Hier zal dus de aanpassing ook moeten gebeuren. Tijdens het hoveren over de GUI moet de nodige informatie zichtbaar worden gemaakt. Hiervoor werd een extra functie geschreven:

For Each key As String In a_layer.DisplayInfo.Keys Dim label As New ToolStripStatusLabel Dim propertyName = a_layer.DisplayInfo.Item(key) label.Text = key + a_planpart.DynamicPropertyGet(propertyName).ToString label.BorderSides = CType((ToolStripStatusLabelBorderSides.Left Or_ ToolStripStatusLabelBorderSides.Right),_ ToolStripStatusLabelBorderSides) label.BorderStyle = Border3DStyle.Sunken label.Visible = True m_frm.CellStatusBar.Items.Add(label) Next End Sub


''' <summary> ''' changes the display info on the status bar of the Form ''' ''' <param name="a_layer"> ''' <param name="a_planpart"> ''' Private Sub changeDisplayInfo(ByVal a_layer As ILayer, ByVal a_planpart As_ SGS_PlanPart) m_frm.CellStatusBar.Items.Clear()

62

Deze functie moet dan nog opgeroepen worden in de hover functie. De nieuwe functionaliteit is in geen tijd toegevoerd.

6.3

Integratie Project

Nadat bleek dat de GUI inderdaad in staat was om de testen te doorstaan, werd het project geïntegreerd in het grote framework. Dit werd verwezenlijkt u door pare programming. Door deze aanpak werd de kennis van beide projecten gedeeld en verliep de integratie relatief vlot. Tijdens het integreren dook er nog één probleem op. Tijdens het schrijven van dit programma was er vanuit gegaan dat er binnen één proces maar één GUI zou draaien. Hierdoor werden een aantal singletons in het leven geroepen die geen singletons mochten zijn. Nadat deze aangepast waren, kon de integratie verder gaan. Zonder verdere problemen werd de rest van het project geïntegreerd. Ondertussen is de GUI ook in staat om planningen die gegenereerd worden door de wizards te visualiseren.

6.4

Code overdracht

Nadat deze masterproef werd geïntegreerd in het framework van ArelocMittal zelf, vond de code overdracht plaats. Dit is een tijd waar de programmeurs die het project verder zetten en de programmeurs die het oorspronkelijk geschreven hebben, samen aan de code werken. Zo kunnen de nieuwe programmeurs zich wat inwerken in de code en kunnen ze vragen stellen aan de oorspronkelijke ontwikkelaar. Deze is uiteraard goed op de hoogte van de geschreven code en weet ook prima wat voor effect een bepaalde wijziging kan hebben in de code. Dit was eveneens een belangrijk deel van deze masterproef omdat het juist zo belangrijk is dat deze code inderdaad nu wordt gebruikt op ArcelorMittal en het is even belangrijk naar code onderhoud en uitbreidbaarheid dat ze precies weten hoe de code eruit ziet.

6.5

De kracht van de generic art of programming (GARP)

In deze thesis wordt meermaals aangehaald hoe eenvoudig aanpasbaar de verschillende stukken code zijn. Dit, in samenwerking met het configuratiebestand, maakt een geheel dat flexibeler is dan ooit te voren. Het is mogelijk in geen tijd een volledig nieuwe GUI te ontwerpen zonder ook maar één letter code te moeten schrijven. De ultieme test was de implementatie van een nieuw type layer, waar hierboven ook al werd over gesproken. Het resultaat was verbluffend. In minder dan een half uur werden de nieuwe type layers geïmplementeerd. De kracht van een generiek Framework werd direct duidelijk. Dankzij een goede


Ondertussen zou u de kracht van generiek programmeren wel duidelijk moeten zijn. Ondanks de hoge ontwikkelingskost en de hoeveelheid tijd die je steekt in de ontwikkeling van een generiek programma, blijkt dat een generiek programma naar aanpasbaarheid toe, enorm flexibel is. Hierdoor verdient zo een programma zich heel snel terug als het in een hoog adaptieve omgeving wordt ingezet.

63

programmeerstructuur en een prima uitgedacht generiek systeem werd dit zonder noemenswaardige problemen geïmplementeerd. Dit staat in schril contrast met de vorige versie van dit framework. Hierin zou een dergelijke operatie meer dan een mandag werk zijn. Hierin zit wel ook het in productie plaatsen van de nieuwe type layers. Toch blijft de tijdswinst enorm. Hier wordt duidelijk hoe krachtig het nieuwe framework is. Er wordt veel meer werk gestoken in het uitdenken en implementeren van een nieuw systeem, maar later worden hier wel de vruchten van geplukt. Dit wordt ook zeer duidelijk in deze masterproef.

6.6

De thesis leeft

Na de vlotte codeoverdracht en de enkele dagen pairprogramming werd de code volledig overgedragen aan Bjorn Cousemaeker en Kevin De Vos. Zij zullen de verdere ontwikkeling van het systeem doen en worden ook verantwoordelijk voor de code die werd geschreven tijdens deze masterproef. Zij worden belast met het updaten en uitbreiden van dit project in het kader van het nieuwe SASKIA framework. Deze thesis werd tot een goed einde gebracht en het resultaat werd goedgekeurd om daadwerkelijk te gebruiken. Deze masterproef zal dus niet het lot van zoveel andere ondergaan en onder het stof verdwijnen. Deze thesis leeft!


Figuur 32: Eindresultaat geïntegreerde GUI

64

Besluit Na maanden van zware analyse, uitgebreide beraadslagingen en intensief codeerwerk, mag ik met enige trots zeggen dat deze thesis een succes was. Alle vooropgestelde doelen werden bereikt. De GUI die ik uit zette te maken werd gerealiseerd en meer. Het systeem was veel generieker dan iets dat ik daarvoor ooit geschreven had. De XML configuratie geeft een ongeziene flexibiliteit zonder enige letter code te moeten schrijven. Voer aan deze mix disign patterns toe en je krijgt een zeer flexibel, eenvoudig uitbreidbaar en onderhoudbaar systeem. Tijdens deze masterproef werd het nut van een grondige analyse overduidelijk bewezen. Zonder een goede analyse was deze thesis absoluut niet zo vlot gegaan. Tevens is een grondige kennis van design patterns een enorm voordeel geweest. Hierdoor konden problemen snel en op een efficiënte manier de kop worden ingedrukt.

Besluit

Maar wat mij bovenal zal bijblijven is een geweldige ervaring van samenwerking in een professionele omgeving en de kennis die deze samenwerking mij opbracht. Ik zou dit alle toekomstige thesis studenten kunnen aanraden. “Get out there and do it!”. Vergewis je er echter wel van dat je een aan een interessant project kan meewerken, bij voorkeur iets dat het bedrijf echt nodig heeft en waarmee je nauw kan samenwerken met de programmeurs van het bedrijf.

65

A

Verklaring

B

Verklaring

Baken

Een speciaal type layer ongebonden door tijd

Basic-Layer

Ook wel LayerBasic genaamd bevat alle basis eigenschappen van een layer

C

Verklaring

Caster

Een bepaalde ghost-layer bevat een tundishgroup

Cellen

Blokken die een onderdeel zijn van een layer en geplande materialen symboliseren

Charge

Een bepaalde halfsize-layer eveneens een kind-layer bevat geen andere layers meer

Chargegroup

Een bepaalde fullsize-layer eveneens een ouder-layer bevat de casters en is de kind-layer van de tundishgroup

Composite

Een structuur of een onderdeel van een structuur waarin verschillende objecten opgeslagen zijn

Controler

Verzorgt alle acties die worden geïnitialiseerd op het form

D

Verklaring

Data-Composite

Bevat de gevisualiseerde data

Data-Composite Handler

Voert alle acties uit op de data-composite

draw behaviors

Ook wel teken gedragingen genoemd bevatten een bepaalde tekenstijl om layers voor te stellen

DrawBasic

bevat de basis van een draw gedrag

dummy data

test data

Dynamic-layer

Een niet gevisualiseerde layer die kinderen bevat welke een dynamische hoogte hebben

E

Verklaring

Woordenlijst

Woordenlijst

66

Verklaring

FiFo

First in first out

Fullsize-Layer

Een layer die over de volledige toegelaten hoogte getekend wordt

G

Verklaring

GARP

Generic Art of Programming

GDI+

Graphics Device Interface en is een vorm van visualisatie

Ghost-layer

Een layer die geen data symboliseert

GUI

Grafische User Interface

H

Verklaring

Halfsize-layer

Een layer die niet over de volledige toegelaten hoogte getekend wordt

I

Verklaring

J

Verklaring

K

Verklaring

Kind-layer

Een onderdeel een andere layer symboliseert ofwel een eigenschap van de bovenliggende layer

L

Verklaring

Layer

Een onderdeel van een planpijp en is opgebouwd uit een naam en cellen

Layer-Composite

Bevat de structuur van de layers

Layer-Composite Handler

Voert alle acties uit op de layer-composite

LayerDynamic

Een niet gevisualiseerde layer die kinderen bevat welke een dynamische hoogte hebben

LayerFullsize

Een layer die over de volledige toegelaten hoogte getekend wordt

LayerGhost

Een layer die geen data symboliseert. (naam van de klasse)

LayerHalfsize

Een layer die niet over de volledige toegelaten hoogte getekend wordt. (naam van

Woordenlijst

F

67

LayerOverlay

Een kind-layer die even groot getekend wordt als zijn ouder. (naam van de klasse)

LayerRoot

Een niet gevisualiseerde layer waaronder alle andere layer hangen. (naam van de klasse)

LayerStatic

Een niet gevisualiseerde layer die kinderen bevat welke een statische hoogte hebben. (naam van de klasse)

Lijn

Ook wel productielijn genoemd zijn de verschillende stappen van een verwerkingsproces serieel achter elkaar geschakeld

M

Verklaring

N

Verklaring

O

Verklaring

ObjectBuilder

Een object dat in staat is andere objecten, door middel van een string, at runtime aan te maken

Ouder-layer

Een ouder-layer bevat één of meerdere kind-layers

Overlay-layer

Een kind-layer die even groot getekend wordt als zijn ouder

P

Verklaring

Planpijp

Een planning van geplande materialen op een lijn

Plug-in visitor

een nieuw soort visitor waarop andere visitors kunnen geplaatst worden welke eventueel worden uitgevoerd

Productielijn

De verschillende stappen van een verwerkingsproces serieel achter elkaar geschakeld

Property

Een eigenschap meestal gebruikt in deze masterproef om te verwijzen naar een eigenschap van een materiaal

Q

Verklaring

R

Verklaring

Root-layer

Een niet gevisualiseerde layer waaronder alle andere layer hangen

Ruler

Een object dat in deze context pixels omzet naar een tijdsaanduiding en omgekeerd

Woordenlijst

de klasse)

68

Verklaring

SASKIA

Scheduling And Stock Inventory Application is een planningsapplicatie welke weergeeft wat de te produceren materialen zijn

SourceSafe

Een programma dat gebruikt werd om de codepool te beheren

Static-layer

Een niet gevisualiseerde layer die kinderen bevat welke een statische hoogte hebben

T

Verklaring

Teken gedragingen

Ook wel teken gedragingen genoemd bevatten een bepaalde tekenstijl om layers voor te stellen

U

Verklaring

Unit-convertor

stelt de ruler in staat om een conversie te kunnen maken van pixel naar een unit

V

Verklaring

VB.Net

visualbasic. Net

W

Verklaring

WPF

Windows Presentation Foundation en is een vorm van visualisatie

X

Verklaring

XML

Extensible Markup Language

Y

Verklaring

Z

Verklaring

Woordenlijst

S

69

Figuur 1: Componenten planningsysteem (ArcelorMittal, ISM/WPI Klantenondersteuning,2002) ...... 7 Figuur 2: Algemene werking planninsysteem (ArcelorMittal, ISM/WPI Klantenondersteuning,2002) . 8 Figuur 3: SASKIA GUI ............................................................................................................................. 11 Figuur 4: Property window SASKIA GUI................................................................................................. 11 Figuur 5: Eerste testprogramma ........................................................................................................... 14 Figuur 6: Eerste testprogramma gecomprimeerd................................................................................. 14 Figuur 7: Tweede testprogramma ......................................................................................................... 14 Figuur 8: Anti-allising probleem ............................................................................................................ 15 Figuur 9: Derde testprogramma ............................................................................................................ 15 Figuur 10: Het sequentiediagram voor de opbouw van de layercomposite ......................................... 19 Figuur 11: Het sequentiediagram voor het tekenen van de layercomposite ....................................... 20 Figuur 12: Het sequentiediagram voor het tekenen van de cellen ....................................................... 21 Figuur 13: Positie kind-layers ................................................................................................................ 22 Figuur 14: Statendiagram selectie ......................................................................................................... 23 Figuur 15: Positie bepaling (rechthoeken) ............................................................................................ 24 Figuur 16: Positie bepaling (trapeziums) ............................................................................................... 25 Figuur 17: Klassendiagramma unitconvertors....................................................................................... 36 Figuur 18: Klassendiagramma Ruler ...................................................................................................... 37 Figuur 19: Composite structuur ............................................................................................................ 38 Figuur 20: Klassendiagram layers .......................................................................................................... 41 Figuur 21: Plug-in visitors ...................................................................................................................... 42 Figuur 22: Voorbeeld composite ........................................................................................................... 51 Figuur 23: .Net logo (http://blogs.msdn.com) ...................................................................................... 54 Figuur 24: Visual Studio 2008 (http://www.techhunt.org) ................................................................... 54 Figuur 25: Visual SourceSave 2005 (http://content.etilize.com/Large/10951676.jpg) ........................ 56 Figuur 26: Office Visio Logo (www.visioprojecttoolkit.com)................................................................. 56 Figuur 27: UModel Altova (http://i42.tinypic.com/103ec00.jpg) ......................................................... 57 Figuur 28: Adobe Photoshop CS4 (http://www.letsgodigital.org) ........................................................ 58 Figuur 29: Dreamweaver 8 (http://i37.tinypic.com/e193yc.jpg) .......................................................... 58 Figuur 30: Office 2007 (http://kvproit.nl/osCommerce/index.php?cPath=21) .................................... 59 Figuur 31: Camtasia Studio (www.softwarecasa.com/camtasia-studio.htm) ...................................... 59 Figuur 32: Eindresultaat geïntegreerde GUI.......................................................................................... 64 Figuur 33: Download planpijp ............................................................................................................... 73 Figuur 34: Selecteer planpijp ................................................................................................................. 73 Figuur 35: Laden is geslaagd.................................................................................................................. 74 Figuur 36: Resultaat............................................................................................................................... 74 Figuur 37: Werkplanning openen .......................................................................................................... 74 Figuur 38: Werkplanning maken ........................................................................................................... 75 Figuur 39: Geladen werkplanning ......................................................................................................... 75 Figuur 40: Klassendiagram .................................................................................................................... 79 Figuur 41: Sequentiediagramma initialisatie (eerste analyse) .............................................................. 81 Figuur 42: Sequentiediagramma paint ruler ......................................................................................... 82 Figuur 43: Sequentiediagramma paint layers ....................................................................................... 83

Figurenlijst

Figurenlijst

70

Figurenlijst

Figuur 44: Sequentiediagramma paint composite ................................................................................ 84 Figuur 45: Sequentiediagramma verschuifproces................................................................................. 86 Figuur 46: Sequentiediagramma hover ................................................................................................. 88 Figuur 47: Sequentiediagramma selectie .............................................................................................. 89 Figuur 48: Klassendiagramma layers (uitgeklapt) ................................................................................. 91

71

Geraadpleegde literatuur Altova. (2009). UModel tutorial. Retrieved Februari/Maart 2009, from altova: http://www.altova.com/manual/UModel/umodelprofessional/index.html?umtutorial.htm Beijer, M. d. (2009). Visual Basic 9.0 belooft veel goeds. advertentie Microsoft Press , 1-4. Boyd, C. A. (2007). Shared Morality, A: A Narrative Defense of Natural Law Ethics. United States of America: Brazos Press. Campbell, S., Swigart, S., Horrocks, K., Hatchard, D., & Bernhardt, P. (2005). Introducing Microsoft Visual Basic 2005 for Developers (Pro - Developer). Redmond, Washington: Microsoft Press. Cnops, J. (2005). Programmaontwerp en -realisatie. Gent: Lannoo Campus. Creating a professional looking GDI+ drawn custom control. (2004, Mei 2). Retrieved Februari 14, 2009, from codeproject: http://www.codeproject.com/KB/miscctrl/ScrollingTextControlArtic.aspx Fowles, M. (2003, derde druk). UML Distilled: A Brief Guide to the Standard Object Modeling Languange. Amsterdam: Addison-Wesley. Freeman, E., Freeman, E., Sierra, K., & Bates, B. (2004). Head First Design Patterns. Verenigde Staten: O'Reilly Media, Inc. Gamma, E., Helm, R., Johnson, R., Vlissides, J., & GangOfFour), (. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Verenigde Staten en Canada: AddisonWesley Professional. Halvorson, M. (2008). Microsoft® Visual Basic® 2008 Step by Step. Redmond, Washington: Microsoft Press. Karkanti, M. S. (2006, maart 39). A Beginner's Guide to Delegates. Retrieved Februari 14, 2009, from codeproject: http://www.codeproject.com/KB/vb/Delegate.aspx Kloep, A. (n.d.). PictureBox. Retrieved 2 14, 2009, from codeproject: http://www.codeproject.com/KB/miscctrl/PictureBox.aspx Kloep, A. (2005, April 11). PictureBox. Retrieved Februari 14, 2009, from codeproject: http://www.codeproject.com/KB/miscctrl/PictureBox.aspx Ray, E. T. (2001). Learning XML. Verenigde Staten: O'Reilly Media, Inc.

Roman, S., Petrusha, R., & Lomax, P. (2003). VB.NET Language in a nutshell. O'Reilly Media. Scott, J. (n.d.). Point in triangle test. Retrieved mei 12, 2009, from blackpawn texts: http://www.blackpawn.com/texts/pointinpoly/default.html

Geraadpleegde literatuur

Roman, S., & Petrusha, R. (2001). VB.NET Language in a nutshell. Verenigde Staten: O'Reilly Media, Inc.

72

Appendix Werkwijze 1) Downloaden van de planpijp

Figuur 33: Download planpijp

2) Selecteer de juiste planpijp

Appendix

Figuur 34: Selecteer planpijp

73

3) Geeft aan wanneer de planpijp goed afgehaald is van de server

Figuur 35: Laden is geslaagd

4) Resultaat

Figuur 36: Resultaat

Figuur 37: Werkplanning openen

Appendix

5) Als u rechts klikt op de planpijp kan u een werkplanning openen

74

6) Werkplanning maken door rechts te klikken op de werkplanning

Figuur 38: Werkplanning maken

Figuur 39: Geladen werkplanning

Appendix

7) resultaat

75

Eerste analyse Requirements Requirements (basis) GUI aspecten •

Één of meerdere planpijpen visualiseren (waarbij men een planpijp kan afschakelen)

•

Verkleinen of vergroten van de form moet een trigger sturen om de ‘drawing’ te schalen: o

(PRI1) Gebruiker kiest steeds voor een bereik (bv. 4uur – 8 uur – 18 uur – alles) Het is de bedoeling dan ook steeds de bedoeling om het bereik volledig te tonen



(PRI2) In principe moet elk object de mogelijkheid hebben om te zeggen dat indien men kleiner wordt dan x dan het object dan niet meer hoeft getekend te worden.

Per planpijp – hiërarchische relaties: o

•



Kinderen van een planpart worden steeds binnen zijn parend getekend. Het moet mogelijk zijn om elk object te kunnen aanklikken (tenzij speciale stilstanden?)


Een waarde kan relatief of absoluut worden afgebeeld. bv. RELATIEF hoogte max. hoogte in planpijp 1800mm = 1 en min hoogte 1000 mm = 0,1 of bv. ABSOLUUT 1500mm wordt steeds geschaald aan 0,5

o

Een waarde of een char kan ook voorgesteld worden als een layer. Elke waarde krijgt een kleur waarbij het mogelijk moet zijn om bijvoorbeeld te zeggen A* -> alles wat begint met een A moet kleur ROOD krijgen of waarde tussen 1 en 10 GEEL

o

Bakens zijn speciale objecten die een gebied afbakenen die geldt voor alle daar tussenliggende objecten (tot aan het volgende baken van hetzelfde type). Dit moet ook mogelijk zijn. Elk baken wordt visueel getoond en de balk wordt gekleurd in de bijhorende kleur.

o

Properties kunnen aan of afgeschakeld worden (at run time).

o

sommige properties staan volledig los van de planpijp en hebben enkel een tijdsapect. Bv. de stilstanden in VELOCAP worden niet getoond in de planpijp doch het zou mooi zijn om deze te zien op een tijdsas samen met de planpijp. vb. stilstanden worden gepland onafhankelijk van de planpijp.

o

Afhankelijk waar de muis staat moet/kan de gegevens in statusbalk wijzigen

o

Gelieve ook deze informatie zichtbaar te maken in een vast staand property scherm en/of via een contextmenu (afschakelbaar door gebruiker)

Appendix

•

Regels schalen:

76

•

Naast de standaard kleuren hebben sommige objecten speciale eigenschappen die een andere kleuring, arcering of ‘flikkering’ kunnen veroorzaken (moet niet at run time wijzigbaar zijn – doch indien regels wijzigen moet dit eenvoudig in de code aanpasbaar zijn): Opgelet: arcering/kleuring mag enkel zichtbaar zijn op object en properties van dat object! o

Bv. indien materiaal een ernstige planningsfout heeft dan wordt het object dat de planningsfout heeft in het rood/oranje gekleurd

o

Bv. arcering indien object in de lijn zit etc…

•

Applicatielaag moet mogelijkheid hebben om draw/redraw te triggeren. Ook de gebruiker moet een knop hebben om de redraw te triggeren

•

Gebruiker moet bereik (in- en uitzoomen) kunnen aanpassen

•

Events op objecten (klik-event, drag-drop event, dubbel klik event, etc… moeten opvangbaar zijn)

•

Indien gebruiker geen bevoegheid in een bepaald gebied moet dit aangeduid worden.

Dynamische aspecten •

•

Selectie van objecten (bij selectie verandert de kleur!) o

Klik -> selectie van dit enkele object

o

Klik object 1 – shift+klik op object 1 -> aaneengesloten selectie van objecten op zelfde hiërarchisch niveau

o

Ctrl+klik -> bestaande selectie + geselecteerd object

Context in acht nemen: o

Niet alle acties zijn toegelaten indien men zich in één of andere context bevindt Concreet: op werkplanning of op planpijp

•

Op elkaar gelegen bakens -> indien klik opent een klein context menu met alle bakens. Hieruit kan de gebruiker dan het gewenste baken aanklikken.

•

Verslepen bakens (bevoegdheidbakens): mogelijkheid om via drag and drop een baken te slepen over een aantal objecten (een bevoegdheidsbaken mag nooit over een ander bevoegdheidsbaken gesleept worden

•

Op werkplan: o

Verwijderen objecten

o

Verslepen object (enkel toegelaten niveaus)

Requirements (optioneel)

•

Bij opstart standaard keuze welke properties aanstaan (ev. user afhankelijk ook voorzien – moet mogelijkheid zijn om ook af te zetten).

•

In- en uitzoomen moet scroll

Appendix

GUI aspecten

77

•

Voortgang van de planlijn als muis zich gedurende enkele seconde aan de rand van de planpijp bevind.

•


Voorzien dat er eventueel andere voorstellingen kunnen gehanteerd worden (buiten relatief of absolute weergave)

•

Aanpassen van de lay-out ook met drag en drop functies (in property window)

•

Maak met dezelfde GUI componenten een andere GUI view

•

Als planpijp verschuift automatisch mee hertekenen

•

Informatie over rolgroep weergeven met popup

Dynamische aspecten

• •

Tot nu toe kan je enkel een opeenvolging van materialen achter elkaar op de lijn zetten. We zouden hier nu ook witruimte tussen willen. Het veranderen van plaats binnen een planpijp ondersteunen (als in proces plan een wijziging wordt doorgevoerd moet dit zichtbaar worden binnen de planpijp Bakens generiek opbouwen, niet meer hard coderen.

Appendix

•

78

Klassendiagram

Appendix

Figuur 40: Klassendiagram

79

Proces beschrijving Het initialisatieproces Van het moment dat er een planpijp moet getekend worden, moet er eerst een composit structuur met alle layer informatie doorgestuurd worden vanuit de applicatielaag naar de GUI. Een tweede aspect dat moet afgehandeld worden is de XML file die moet ingelezen worden. Hierin vind je een beschrijving terug hoe welke layertypes voorgesteld moeten worden. Anderzijds vind je hier ook terug hoe de gebruiker zijn view heeft gecostumiseerd en welke layers er al dan niet visible staan. De composit structuur (bestaande uit de verschillende planparts) wordt opgeslaan in de class CompositContainer. Deze CompositContainer bezit eveneens een Hashtable met stijltypes voor elke layer. Een stijltype bestaat uit een kleur, dag/drop mogelijkheden en gewicht (dat bepalend is voor de grote van de visualisatie). Deze hashtable is verkregen door de object creator los te laten op een XML file waar stijlen in beschreven staan. Later zal dan de composit structuur doorlopen worden met een Visitor die zal nagaan van welk type elke layer is en het juiste stijltype toe te kennen aan elke layer. Dan gaan we de ruler initialiseren. Dit object zet plaatsen om naar Integers en viseversa. Of dat het ruler object ook daadwerkelijk getekend wordt moet nog gezien worden in de gebruikers configuratie file. Wat wel zeker moet bepaald worden is de scoop voor de ruler. Een eis is dat bij opstarten alle geplande materialen zichtbaar zijn (dit is configureerbaar in de XML file van de ruler). Dus het eindpunt van de scoop is wanneer het laatste geplande materiaal theoretisch van de band zou moeten rollen. (Dit kunnen we halen uit de composit structuur die doorgegeven is door de applicatielaag). Als beginpunt nemen we de huidige system time. Nu dat de scoop gekend is wordt er bepaald hoeveel units er in één pixel zitten. (één unit bij ons is één seconde). Eerste tekenopdracht: Hier kan de ruler eventueel al getekend worden. (nader besproken in 0 Paint van ruler) We kennen nu reeds al alle mogelijke stijlen van de layers. Nu is het tijd om te gaan kijken welke layers we daadwerkelijk moeten tekenen. Hiervoor bestaat een andere XML file die beschrijft welke layers er zichtbaar zijn en wat de volgorde is waarin de layers staan. Deze XML file moet aanpasbaar zijn door de gebruiker. Hiertoe zal een options form voorzien worden waarbij de gebruiker gemakkelijk zijn voorkeur lay-out kan samenstellen. Tweede tekenopdracht: Hier kan het linker paneel getekend worden waarop de namen van de layers staan. Dit hoeft in latere paint opdrachten niet terug getekend worden. (tenzij we een resize/minimize doen). Verdere info 0 Paint van linker paneel

Het is misschien best dat we deze berekeningen opslaan in variabelen. Zo zou elke layer kunnen bijhouden hoeveel pixels bij toegewezen krijgt en of hij relatief of absoluut afgebeeld moet worden. Deze berekeningen moeten herdaan worden als de gebruiker beslist een layer

Appendix

In een tweede fase zal dan de relatieve of absolute berekeningen moeten gebeuren. Dit wordt nader uitgelegd in Het relatief/absoluut proceshierboven

80

te verbergen of een extra layer zichtbar te maken. Of als de gebruiker over wil gaan naar een andere relatieven of absolute weergave. Derde tekenopdracht: Dit is de laatste en weliswaar meest complexe tekenopdracht. En zal nader beschreven worden in 0 Paint

_form

_compositContainer

_parser

_ObjectBuilder

_style

_ruler

aplicatielaag

new(_composit) new(_composit)

new() new()

for all styles

readStyle() convertStyle(style) new() return style

return style return styles

setStyles(_allStyles) _veindtijd calculateEnd(-einddatum) execute()

return einddatum

dateUnit

return einddatum

convertToInt:=convertToInt() return int

new(_start, _stop) readUserConf(_layerconfs, _rulerconf) convertLayerConfig(_layerConf) return config ConvertRulerConfig(_rulerConf) return config return config setConfig(_layerconfs) setConfig(_rulerconf) refresh(_start, _stop) PaintMe

Het tekenen zelf wordt op een nieuw sequentiediagram voorgesteld

Figuur 41: Sequentiediagramma initialisatie (eerste analyse)

Appendix

voor eindtijd voor begintijd

81

Paintproces Paint van ruler De ruler heeft een begin en eindpunt. Het begin en het einde zijn integers representatieve van een bepaalde tijd. Als deze 2 integers heel veel van elkaar verschillen gaan we als kleinste tekeneenheid uren nemen. Als ze niet zo veel van elkaar verschillen gaan we elke minuut tekenen. (De exacte rasio’s zullen met trail en error bepaald moeten worden. We steken ze dus ook best in constante zodat ze gemakkelijk aangepast kunnen worden). Dan gaan we kijken vanaf de start wanneer de volgende eenheid begint (bvb wanneer start de volgende minuut? Is dit in 10 sec of in 30. Het is in ieder geval kleiner als 60 seconde). Eens we deze eerste minuut gevonden hebben gaan we een vast aantal pixels gebruiken om de volgende minuut voor te stellen. Enkel de eerste minuut zal kleiner moeten voorgesteld worden (omdat die al bezig is). De andere minuten hebben een vast aantal pixels. Dit vind je terug in unitsPerPixel. Als de kleinste eenheid getekend is dan kan het zijn dat we ook nog een aantal uur willen voorstellen. Weer zullen we eerst het eerste uur moeten zoeken en daarna kunnen we een vaste afstand gebruiken om de volgende uren te bepalen. Beide processen kunnen samen lopen denk ik. Zodat we tegelijk minuten en uren tekenen.

_dateUnit

_ruler

_form

tot er een int wordt teruggegeven die niet meer binnen de scoop zit

paintMe() getNextPlace(_startPlace, _nextPlace, _nextText) return next place

drawLine()

Paint van linker paneel Als we het linker paneel willen gaat tekenen moeten we eerst en vooral al weten welke layers er getekend moeten worden en in welke volgorde. Dit wordt afgeleid uit een XML file die de gebruiker kan aanpassen in een option form. Deze XML file werd reeds ingelezen tijdens de initialisatie. Er werden ook door de parser objecten aangemaakt die beschrijven of de layer zichtbaar is en welke volgorde er gehanteerd moet worden. Als we dit allemaal weten rest er ons nog te berekenen hoe hoog elke box moet getekend worden. De hoogte wordt afgeleid uit een gewicht dat je terugvindt in de stijl van de layer. Dit wordt met een regel van 3 uitgerekend als volgt: Voorbeeld: ik wil 5 layers afbeelden: L1, L2, L3, L4, L5 met respectievelijke gewichten 50, 50, 25, 10, 65. Dit geeft mij een totaalsom van 200 wat gelijk staat aan 100% of x pixels. Met andere woorden L1 en L2 zullen beide over ¼ van het scherm afgebeeld worden terwijl L3 1/8ste krijgt, L4 1/20ste en L5 13/40ste.

Appendix

Figuur 42: Sequentiediagramma paint ruler

82

Aangezien we veel zulk type berekeningen moeten doen heb ik besloten dit in een aparte klasse te steken. Deze klasse zal uitsluiten zulk type berekeningen maken.

_form

_compositContainer

_shared

paintLeftPanel() voor elke zichtbare layer

CalTotalWeightLayer()

regelVanDrie(_startvalue, _endvaule, _startweight, _endweight, _askweight, _askedvalue)

return hoogte blok (!=y coörd)

calYfromHeight()

X coörd is een vaste constante De start Y waardeis 0. De eindwaarde van heteerste blok is de hoogte dit is tevens de start van het 2de blok enz. => we hebben een x en y

DrawRec()

Figuur 43: Sequentiediagramma paint layers

Voor de paint gebeurtenis zijn er een aantal dingen die moeten afgehandeld worden. Het eerste is de berekening van de juiste plaats op het form (tekening houdend met het feit dat het relatief of absoluut kan zijn). De plaats op het form is af te leiden uit de ruler. Elk object heeft een begintijd (DateTime) en een duur. Daarmee weten we dus de begin en eindtijden van een bepaald materiaal. Deze tijden kunnen dankzij een unit convertor omgezet worden naar integers. De ruler doet geen omzettingen van DateTime naar integers omdat we onze ruler zo algemeen mogelijk willen houden. Daartoe wordt dus een unit convertor geschreven die de DateTime omzet naar seconde (in integers). Onze ruler kan enkel overweg met Integers. Dit convert proces hadden we ook al nodig bij de initialisatie van de ruler. Toen is hier echter niet verder op ingegaan. Dus nu gaan we de composit structuur overlopen maar we zijn dit keer enkel geïnteresseerd in de planparts. De layers hebben we reeds klaarstaan op het linker paneel en we kennen dus de grote van elke layer. Nu hebben we dus een begin en eindtijd van een planpart in integers. Hierdoor kan dan de ruler zeggen waar op het form het planpart moet getekend worden. Dan volgt de berekening van de relatieve of absolute weergave. Deze wordt nader beschreven in Het relatief/absoluut proces. Dit levert ons de coördinaten op van de hoogte, dikte binnen een rolgroep. De X en Y coördinaten van de rolgroep zelf en de andere planpart zoals olie, etc. kan afgeleid worden uit enerzijds de x coördinaten gegeven door de ruler en anderzijds de y coördinaten kunnen afgeleid worden uit het linker paneel. Het laatste wat ons dan nog rest is te kijken welke stijl we moeten gebruiken om het object te teken.

Appendix

Paint van de composit structuur

83

OPM: Om de berekeningen vlot te doen verlopen is het misschien best het coördinatenstelsel te verleggen. Van het rode assenstelsel naar het groene. Zo begint is de ruler op de nu=0 op de x-as. Dit zou de berekeningen volgens mij aanzienlijk vergemakkelijken. Nadeel: je kan waarschijnlijk niet meer zo gemakkelijk werken met de breedte van het form zelf. Dit zal nog moeten afgewogen worden. Je kan ook niet zomaar meer met een muispositie werken. Dus dit lijkt me misschien toch niet het beste idee te zijn.

_form

_compositContainer

_shared

_getCSVisitor

_dataUnit

_ruler

de structuru zal in met breedte eerst afgetast worden. Zo kan je van groot naar klein werken Telkens een volledig niveau afgelopen is worden de gewichten verdeeld

PaintComposit() execute Dit is voor de relatief of absoluut berekeningen voor de dikte/breedte/hardheidsindex. En dus NIET voor de hoogte van de layer

layers with style/duration

CalTotalWeightLayerpart() regelVanDrie(_startvalue, _endvaule, _startweight, _endweight, _askweight, _askedvalue) returns value of weight (=y coörd)

enkel voor de kleinse planonderdelen is dit nodig

voor beide tijden

convertToInt return int

convertUnitToPosition returns x-coord

DrawRec()

Figuur 44: Sequentiediagramma paint composite

Het zoomproces is een aanpassing van de scoop hierdoor zal de ruler een bericht binnenkrijgen dat zijn scoop is aangepast. Er zal een nieuwe scoop meegegeven worden aan de

Appendix

Het zoomproces

84

ruler na de herberekening van units per pixel kan de paint gebeurtenis kan terug opgeroepen worden. De truck in het zoomproces ligt echter bij het bepalen van een nieuwe scoop. Je wilt zoomen maar je wilt op die manier kunnen zoemen dat als je met je muis scrollt het materiaal dat onder je muis staat voor en na de zoom hetzelfde is. Dus het centrum van de zoom moet dat materiaal zijn. Als er gezoemd wordt met de knoppen bovenaan dan wordt er verwacht dat het centrum het centrum van je zoom zal zijn. De zoomfunctie die ik zal moeten schrijven krijgt dus een centrum mee adhv coördinaten en zal daarrond bepalen hoeveel er van het eerste tijdstip zal moeten afgehaald worden en hoeveel van het laatste. Ik denk dat het best is dat we ook hier een 100% gradatie toepassen hoe meer de muis naar links staat hoe meer er van het laatste tijdstip af zal moeten. Ik zou het zoembereik aanpassen uur per uur. Dus als de muis in het centrum zou staan dan gaat er van de begin en eindtijd respectievelijk 30 min bij of af. Als de muis op 1/3de van de rechter uithoek verwijderd staat dan zal dit bekenten dat er bij het begintijdstip 40 min wordt bijgeteld en dat er bij het eindtijdstip 20 min af gaan. OPM: De ruler werkt helaas niet met minuten dus we zullen waarschijnlijk met een integer waarde moeten werken die een uur zal voorstellen. Je kan ook niet kleiner inzoomen als 1 uur.

Het verschuifproces Dit proces zal beschrijven hoe we het form zullen hertekenen eens het verschoven is. Hier wordt. Eigenlijk is het ongeveer hetzelfde principe als het zoomproces alleen wordt er vooraan een uur bijgeteld/afgetrokken en achteraan een uur afgetrokken/bijgeteld. De scoop blijft hierbij wel contant alleen hebben we een nieuw begin en einduur. We hertekenen het form naar de nieuwe begin en eindtijd OPM: Je kan hier ook weer geen uur meegeven maar wel een integer die overeenstemt met een uur. Dit omdat de ruler dus niet in uren werkt maat in integers

Appendix

IDEE: Het is nog misschien een leuk idee om de muisscroll te gebruiken om de planpijp te verschuiven. We zouden dan ctrl+scroll kunnen gebruiken voor in en uitzoeken. Zoals ook de standaard is voor te zoomen op documenten, internet pagina’s,…

85

_statubar

_compositContainer

_ruler

_form

Scrolled(_IntPixels) firstValueChanged(_intAdded) refresh(_start, _stop)

PaintComposit()

Figuur 45: Sequentiediagramma verschuifproces

Het relatief/absoluut proces In dit proces gaan we de berekening voor de relatieve of absolute weergaven nader bespreken. Hiervoor hebben we 2 grenzen nodig. Een onder en een bovengrens. Hiertussen gaan we de verschillende materialen tekenen met een bepaalde hoogte. Vb: - Absoluut: Dit houdt in dat de benedengrens 0 is en de bovengrens het grootste materiaal dus als je grootste materiaal 1000 mm is dan zijn de grenzen tussen 0-1000 en wordt daarbinnen alles afgebeeld - Relatief: Dit is een scoop die kan vastgelegd worden door de gebruiker. Hij kan je bijvoorbeeld vragen alles af te beelden tussen 100 en 300 mm. Dit geeft een veel duidelijker verschil tussen twee materialen die niet zo veel van elkaar scheelden. Aan de andere kant als er een materiaal is dat groter is als 300 mm dan moet dit ook aangegeven worden door middel van een afgebroken balk. Concreet zullen we hier onze composit structuur moeten overlopen om te kijken hoe groot het materiaal zal moeten getekend worden. Dit levert ons dan 2 y coördinaten op als het materiaal binnen de grenzen ligt. De eerste coördinaat kan afgeleid worden uit de compositconainer. De 2de coördinaat zal berekend worden dankzij de relatieven of absolute berekening. Als het materiaal echter groter is als de bovengrens denk ik eraan maar de coördinaat op -1 te zetten dit geeft dan aan dat de rechthoek afgebroken moet worden.

Aan/uitschakelen/verslepen van layers

Appendix

Het aan en uitschakelen of het verslepen van layers in opmaak dat de gebruiker zou moeten kunnen aanpassen. Hiertoe zal een configuratie form worden gemaakt waar een gebruiker zijn persoonlijke voorkeur kan opbouwen. Die aanpassingen zullen naar een XML bestand worden geschreven en telkens terug worden ingelezen bij het heropstarten van de applicatie. Zo verliest de gebruiker zijn persoonlijke view niet. Het gebruik van deze XML file zag u al in het initialisatieproces.

86

Het drag/drop proces Een bevoegde gebruiker kan rolgroepen veranderen van volgorden. Dit door middel van drag drop. Je moet er wel rekening mee houden dat je niet zomaar een rolgroep dropt een een rolonderdeel. Of op een baken.

Het hoveren selectproces Het hoveren het select proces hebben een grote basis gemeenschappelijk. Het enige verschil tussen de twee is dat het hover proces geactiveerd wordt doordat de muis erover beweegt en het select proces geactiveerd wordt door erop te klikken. Bij het hover proces moet er rond bepaalde rechthoeken een dikkere rand getekend worden, maar enkel die rechthoeken die relevante informatie bezitten voor het deel waar de muis nu opstaat. Selectie doet hetzelfde maar ipv een boord te tekenen zal dit proces de verschillende rechthoeken selecteren (in een blauwe kleur zetten). Bij selectie is het ook mogelijk om meerdere delen tegelijk te selecteren door ctrl ingedrukt te houden of door met shift te werken. (ctrl voor enkele delen over de pijp te selecteren shift voor alle tussenliggende delen te selecteren).

Appendix

Tot hier de verschillen zowel bij de hover als bij de selectie moet de x en y coördinaat bepaald worden van de muis. Uit de Y coördinaat kunnen we afleiden in welke layer we staan en kunnen we dus ook kijken welke andere layers er interessant kunnen zijn. Ik zou de rechthoeken in het linker paneel wel bijhouden om een snelle y bepaling te kunnen doen. De x coördinaat kan je dan gebruiken om de andere layers te bepalen die geselecteerd moeten worden. Dit is echter niet zo eenvoudig eerst moet de ruler de x coördinaat omzetten naar een integer deze moet dan omgezet worden naar een DateTime. Die datetime komt overeen met een materiaal in de composit structuur. Aan de hand van de y coördinaat weten we al waar ongeveer we in de composit structuur moeten zoeken. Als we dan ook nog eens het eerste afgebeelde materiaal bijhouden kunnen we de zoekactie al een heel pak beperken. We moeten natuurlijk niet enkel het materiaal rechthoek hertekenen waar we op dit moment op staan, maar ook alle rechtoeken die ermee te maken hebben en waar we geinteresseerd in zijn. Dit kan je afleiden uit de y coordinaat die je kan vertellen waar je staat en welke andere layers je interesseren. Dit vind je terug in de layerconfig.

87

Hover sequentiediagram _form

_compositContainer

_dataUnit

_ruler

_statusbar

Object1 mouseMove() findPlanpartAndRedraw(_planpart)

ConvertPositionToLayer:=ConvertPositionToLayer() return name layer

convertPositionToUnit:=convertPositionToUnit() return Unit

convertToUnit:=convertToUnit() return Unit

FindplanpartAndBorder(_units, _layer, _info) return string with info

setInfo

Appendix

Figuur 46: Sequentiediagramma hover

88

Select sequentiediagram check of er ctrl of shits ingedrukt werdindien ctrl: enkel het geselecteerde gebruiken.Als Shift wachten op 2de klik en dan alles tussen beide selecteren.Een vorige selectie wordt bij shit ook ongedaan gemaakt!

_compositContainer

_form

_dataUnit

_ruler

Object2 mouseClick() ConvertPositionToLayer return name layer

convertPositionToUnit return Unit

convertToUnit return Unit

findPlanpartAndFill

et planpart wordt hier toegevoegd aan een array van geselecteerde planparts

Figuur 47: Sequentiediagramma selectie

Resize Het resize event heeft als gevolg dat alles herberekend moet worden. Dit komt vrij goed overeen met een herinitialisatie zonder de eigenlijke initialisatie. Bij het resize event worden nu eerst de onderste delen verkleind. Je kunt het vergelijken met de Java met de bakens in het noorden en rolgroep in het centrum.

Andere ideeën/opmerkingen

Bij de parser zal je een if else structuur moeten hanteren om de sart/stop tag van XML te kunnen overlopen… of toch niet! Je steekt de verschillende tags in een hashtable (de tags als key en de value van de hashtable is een operatie die moet uitgevoerd worden wanneer je die tag tegenkomt in XML. Het gevolg van deze werkwijze is geen grote if else structuur meer maar wel 1 functie die in de hashtable gaat kijken of de tag al dan niet bestaat. Als de tag bestaat wordt de operatie bij die tag uitgevoerd ander zal er een exeption opgegooid worden. Als je een tag wil toevoegen moet je ook niet meer werken met een if else maar steek je de nieuwe tag gewoon bij in je hashtable en hoef je enkel nog de verwerkinsfunctie te schrijven van deze hashtabel.

Appendix

De if else trap

89

Wanneer repaint? Er wordt niet bij elke vensteractie een repaint opgeroepen. Zo zal na een minimalisatie geen nieuwe paint functie opgeroepen worden. Er wordt gewoon een image terug opgezet. Dit heeft als resultaat dat er geen nieuwe berekeningen moeten gebeuren bij het minimaliseren. ENKEL bij zoom, resize en verplaatsen over de planpijp zal een paint event opgeroepen worden!

Paint en repaint van delen van de planpijp Probleemstelling De muis staat op een bepaald materiaal daardoor moet een rand rond dit materiaal getekend worden En rond alle property’s die met die layer te maken hebben. Daarvoor moeten we natuurlijk weten in welke property’s we geïnteresseerd zijn. Mogelijke oplossingen Oplossing 1 Deze oplossing zal aan mij composit structuur gaan aanhangen in welke layers ik geintereseerd ben. Als ik dan op een material ga staan dan worden mij direct de layers van interesees aangegeven.

Appendix

Oplossing 2 Je kan bij de layers bijhouden van welk andere layers ge intereseeren

90

Figuur 48: Klassendiagramma layers (uitgeklapt)

Appendix

Klassendiagramma Layers

91

Syntax ArcelorMittal Checklist Code Review VB.Net ITSWE Application ID: Application Name: Version: Reference: Description: Auditor: Audit Date:

Blocking(Y/N)

Y Y Y

Y Y

Description Before Review Has the developer tested the code?

test report available

Does the code build correctly Does the code execute as expected? Coding Principles General Use option strict on to enforce strict typing (set in code) Use option explicit on to enforce explicitly declared variables (set in code) Load text to be translated (captions, tooltips, error messages, …) from resource files, database when available, or use messages as defined in analyse

Y Naming Conventions

Comments / Default values Check Remarks

Recomme nded use of resource files

Does the code use a clear naming convention? Making the purpose of each variable clear

Y

Projects / Solutions /Folders

Appendix

Y Y

Reduce chance of programming errors Use descriptive names Never use default name (for example Text1) English is standard language for coding (except when MSP standards are used for variables)

92

Checklist Code Review VB.Net ITSWE

Y

Y

Y

Y

Y

Y

Y

Y

Y

Avoid long folder names. Folder must not repeat application root name Namespaces use for namespaces. Country, location and department are optional if not applicable (transversal projects) Class default PascalCas e default PascalCas e If a class belongs to a certain group or type, the Making groupname is added as a prefix (for example the for Forms, Service Classes, Data Managers, purpose Datasets, …) of each variable clear Interfaces default Interfaces are named with descriptive nouns or PascalCas e noun phrases and start with the prefix 'I' Methods Use descriptive verbs or verb phrases to name default methods PascalCas e Properties Use prefix "_" + same name as property, to Default name the corresponding private variable camelCas e Variables Default Use descriptive name for parameters camelCas describing a parameters meaning rather than e the type, do not repeat the type in the name

Every public class is in a separate file and filename is the same as the classname Use a descriptive noun or noun phrase to name a class

Appendix

Y Y

Names of projects, solutions and service classes See Naming must reflect architecture & layers Conventio ns document for defaults Use Standard folder structure

93

Checklist Code Review VB.Net ITSWE Y

Variables which represent an attribute in a table or are business related: MSP

Y

Private variables that are global for an instance of a class, start with '_'

Y

Default Use descriptive name for local variables describing the variable meaning rather than the camelCas e type, do not repeat the type in the name

Y Y Y

Database Table names start with acronym of application Columnames use MSP (local Gent applications) or Pascal Case (transversal) Stored procedures start with usp__

Commenting Techniques code comments: are all functions, methods and classes documented? The comments clearly indicate the thinking and logic behind the code

N N

N N Y

Proper grammer, punctuation and spelling used Use VBCommenter or VS2005 IDE comment XML block, containing at least description, parameter and return value Use webservice description attribute Fill in description of tables and columns

Coding Style & Organization

consistent code formatting

Standard structure architecture/layering Standard structure of projects , programs and modules (Body Standards,...) Appendix

N

Reducing the need for readers to run a simulation of code execution in their heads Every public type, method, event, delegate, stored procedure must have a corresponding comment if it has added value to explain the business logic The length of a comment should not exceed the length of the code

94

Checklist Code Review VB.Net ITSWE Readability, understandable, freeing the reader of your code from having to make assumptions. organisation of modules into a set of procedures that are tightly related Making the structure of your code as self-documenting as possible Does each routine perform one will-defined task? Is each routine's contract obvious and clear?

Y N N Y

N

N

Y

N N

Y

Y

default tabsize 4

Code should be self describing Reuse of code instead of code copy Namespaces Use namespacing to indicate layering Regions Use Regions for members, properties, events, delegated, constructors and destructors and methods in case of a complex and large class Function/Procedure Limited scope of a function (information hiding) Config Files All application settings should be located in config files / database

VSU standards

Variables Scope of variables should be as small as possible Always use scope declaration Constants Use Constants instead of hard coded values and numbers Proxy Use a seperate project containing a Proxy to a webservice or a comproxy

Defensive programming: preconditions, post conditions, assertions, exception handling, resource constraints clean up

Appendix

N

Minimized nesting Do not place multiple statements on a single lign Use indentation

95

Checklist Code Review VB.Net ITSWE Y N

Use dispose when appropriate Use of asserts

Y

Error Handling Error message contain key, parameters and description Consistent use of ADF exception manager to publish exceptions

Y

Y Y

Publish on BS layer Rethrow on WS layer as SOAP Publish exception to client/user translated to business exception with an understandable message Security Avoid using impersonation and do not impersonate a power user Use the default application security when applicable GUI Standards - to be replaced with specific GUIdeline color blindness visual consistency consistency with user expectations default handling Use tooltips for buttons and toolbar Messagebox: use a corresponding icon (warning, exclamation, …) and a title Use of Menu is mandatory based on standard windows menu structure In case of shorcut/accelerator keys, use standard shortcut key when available Use of infobox containing info application, version Use of standard microsoft icons when available Use of statusbar at the bottom of the window Use of consistent formatting, font and style Use of drop-down box in case of permitted values

Appendix

Y Y Y

96

Checklist Code Review VB.Net ITSWE Position buttons on the right bottom of the screen, horizontal aligned Use of sandbox for indicating busy state and reset to previous mouse pointer state after execution Navigation Design for Operations

Y Y Y

Error Handling Do they not publish to much exceptions? Do not publish exceptions in webservice method (just catch and rethrow)

Y

Do they catch and retrow without any action Do not use unless specific action is needed, because loss of stacktrace

Y

Tracing Use configurable tracing (ADF standard)

Y

Technical Architecture Is the architecture, components, technology valid for ITSWE

Appendix

Y

Monitoring Usage of performance counters

97

SASKIA P² Revamp GUI. Wim DUYSBURGH. Schoonmeersstraat Gent

Recommend Documents