STAGEVERSLAG. Simulatie Diepstekende Schepen. CTE NCTi::

CTE NCTi::

STAGEVERSLAG

Simulatie Diepstekende Schepen

Rijswijk, 31 januari 1995 Rijkswaterstaat, Directie Noordzee

Joep Vermaat Stagiair Sector Informatica Haagse Hogeschool

Staeeverslag


Referaat

REFERAAT Vermaat, J.T., Stageverslag, Simulatie Diepstekende Schepen, Directie Noordzee, DirectoraalGeneraal Rijkswaterstaat, Rijswijk, 1995 Dit verslag bevat een beschrijving van werkzaamheden die Joep Vermaat heeft uitgevoerd tijdens zijn Stageperiode. Deze stageperiode is een onderdeel van de opleiding aan de Sector Informatica, Haagse Hogeschool en werd uitgevoerd op de afdeling Hydro-Meteo Advisering (MTBA) van Directie Noordzee te Rijswijk. De opdracht die tijdens het laatste halfjaar van 1994 is uitgevoerd, had tot doel met behulp van een object-georiënteerde taal een Windows applicatie te ontwikkelen waarin de vaart van diepstekende schepen door de vaargeulen in de Noordzee kan worden gesimuleerd.

Descriptoren: Stageverslag Directie Noordzee Object-georiënteerde ontwikkelmethode Windows Vaargeulen Diepstekende Schepen S i m u latie

Rijkswaterstaat. Directie Noordzee

Rijswijk, 31 januari 1995

Stageverslag


Samenvatting

SAMENVATTING Dit verslag is bedoeld als overzicht op de activiteiten die ik heb uitgevoerd tijdens de stage gedurende de periode september '94 tot begin februari '95. Ik heb de stage vervuld bij de onderafdeling HydroMeteo Advisering (MTBA) van de Directie Noordzee, een onderdeel van het Directoraal-Generaal van Rijkswaterstaat. Hydro-Meteo advisering heeft tot taak het verstrekken van Maritieme informatie en adviezen met betrekking tot de waterstand, golven, stroming, weersverwachting en tijpoorten voor zogenaamde tijgebonden schepen, naar de Rotterdamse haven. De tijpoorten worden met behulp van een programma dat aan de hand van tabellen berekend, hoe groot de kans is dat de bodem beroerd wordt. Deze wordt gevoed met parameters, die afhangen van de diepgang van het schip en de weeren water omstandigheden. Deze methode is echter zo ondoorzichtig dat het hoofd van de onderafdeling, Frits Draisma, een visueel alternatief wil. Hiervoor moet een simulatiepakket ontwikkeld worden dat diepstekende schepen over de werkelijk gemeten bodem laat varen, rekening houdend met de waterstand en de golfslag. Het pakket moet minstens kunnen draaien op een 386, 25 MHz machine met Windows en wordt ontwikkeld in de object-georiënteerde taal Visual C++. Het project is in het eerste halfjaar van 1993 uitgevoerd door een afstudeerder van de Sector Informatica, Peter-Paul de Bruin. Hij is echter niet verder gekomen dan een uitgebreid ontwerp ontwikkeld met behulp van SDMII en Object Modeling Technique [RUMBAU91]. Ik had nu tot taak zijn documentatie te evalueren, bij te stellen en eventueel opnieuw te ontwerpen. Daarbij heb ik gebruik van dezelfde methoden en technieken als Peter-Paul. De eerste paar onderdelen van de documentatie van Peter-Paul zijn volledig en juist. Aan de definitiestudie/basisontwerp hoefde niets te worden aangepast. Het functioneel detailontwerp echter bevat een aantal inconsistenties en moest worden veranderd wat betreft de communicatie met het meetnet Noordzee. Deze is vervangen door een database waarin de waterstand gegevens staan opgeslagen. Alle veranderingen zijn gedocumenteerd in het 'Vernieuwd Functioneel Detailontwerp' Het prototype, met het gebruikersinterface, voldeed ook niet langer en moest een facelift ondergaan, de menukeuzes werden beperkt. Het technisch detailontwerp van Peter-Paul werd verworpen omdat hij de technieken van Object Modeling Technique niet juist heeft uitgevoerd. Bovendien waren de veranderingen in het Functionele Detailontwerp te uitgebreid. Het 'Vernieuwd Technisch Detailontwerp' kreeg ik niet af, want OMT bleek te gedetailleerd en daarom te tijdrovend te werken. Omdat de tijd begon te dringen heb ik besloten met implementatie te beginnen. De implementatie bracht problemen met zich mee, omdat Visual C++ en Windows beiden nieuw terrein voor mij waren. De planning was dus iets te optimistisch ingeschat. Ondanks dat het een nieuwe omgeving was, verliep het programmeren over het algemeen goed. Dit dankzij de voorbeeld programma's die bij Visual C++ worden geleverd. De simulatie werd voorzien van een vernuftige gebruikersinterface met knoppenbalk, gecontroleerde invoer en beperking voor de gebruiker waardoor het 'foolproof werd, maar toch gebruikersvriendelijk. De grootste problemen ontstonden bij het maken van de presentatie in de vensters. Een aantal fouten binnen Visual C++ en Windows waren hier verantwoordelijk voor, het oplossen van de problemen kostte in het totaal twee weken meer tijd. Het programma is niet volledig afgekomen, maar schepen kunnen nu bij 'windstil' weer zonder getijden over een door de computer gegenereerde bodem varen. Concluderend was de stage bijzonder leerzaam. Ik heb erg veel kennis opgedaan in het object georiënteerd ontwerpen en programmeren. De opgeleverde produkten zijn niet allemaal volledig, maar zo ver ze af zijn, kwalitatief juist. Het simulatiepakket werkt, maar nog niet volgens de gespecificeerde eisen. Het project kan echter door een opvolger tot een goed einde worden gebracht. Het project kostte meer tijd dan gepland, doordat veel documentatie en literatuur moest worden gelezen, bovendien had ik geen rekening gehouden met de verslaggeving. De theoretische kennis van de Sector Informatica kwam over het algemeen goed van pas. Alleen jammer dat de Sector Informatica zo weinig aandacht besteed aan Object Georiënteerd ontwerpen en programmeren.

Rijkswaterstaat, Directie Noordzee

.


Stageverslag


Voorwoord

VOORWOORD Dit stageverslag is het resultaat na een halfjaar werken bij een overheidsinstelling. Het is voor mij de eerste keer dat ik een functie heb vervuld binnen een groot bedrijf. En het is me reuze meegevallen. In het begin moest ik wennen aan de regelmaat van alledag, maar uiteindelijk begon ik die toch wel als prettig te ervaren. Wat me wel tegenviel was dat het werk zo eentonig is. De hele dag alleen op een kantoortje, achter een computer. Als dat mijn toekomst is, dan zal ik alles proberen dat te voorkomen. Ik heb volgens mij wel aanleg voor het ontwikkelen van software en ik vind het nog steeds een interessant vakgebied. Toch hoop ik dat mijn functie later iets meer afwisseling zal brengen. Ik kijk nu al uit naar de afstudeerfase, waarin ik meer in een teamverband hoop te gaan werken. Het resultaat van de stage is een simulatiepakket wat nog niet geheel aan alle eisen voldoet, maar werkt. Ik ben blij dat ik een opdracht van het kaliber afstudeerproject' tot zon goed einde heb weten te brengen. Het project wordt nu overgenomen en hopelijk voltooid door een andere student aan de Sector Informatica. Ik wil een aantal mensen hartelijk bedanken, omdat zonder hen deze stage waarschijnlijk minder goed zou zijn uitgevoerd. Allereerst mijn opdrachtgever Frits Draisma, omdat hij altijd tijd had voor mijn vragen, maar af en toe ook zo maar binnen kwam voor een praatje. Bovendien heeft hij me een aantal keer op excursie genomen: naar het lodingsschip Octans', het Rotterdams Havenbedrijf, het HydroMeteo centrum Rijnmond en baggerschip 'Geopotes 14'. Tevens wil ik Henry Witteveen bedanken voor het beschikbaar stellen van de compiler Visual C++ 1.0. En als laatste wil ik mijn mede-stagiairs Jessica Treurniet (student Civiele Techniek, Haagse Hogeschool) en Martijn Meere (student Sector Informatica, Haagse Hogeschool) bedanken voor de afleiding.

Rijswijk, 26januari 1995 Joep Vermaat



Stageverslag


Inhoudsopgave

INHOUDSOPGAVE

1 INLEIDING ........................................................................................................................................................ 1 .

1.1. INTRODUCTIE ..................................................................................................................................................... 1.2. OMGEVINGSSCHETS ........................................................................................................................................... 1.3. OPDRACHT ......................................................................................................................................................... 1.3.1. Probleemstelling ..................................................................... ................................................................... 1.3.2. Doelstelling ............................... ................................................................................................................. 1.3.3. Produkten...................................................................................................................................................

1

3 3 3 4 1.4. HULPMIDDELEN ............................................ ..................................................................................................... 4 1.4. 1. Hardware................................................................................................................................................... 4 1.4.2. Software ..................................................................................................................... . ............................... 5 2 AANPAK ............................................................................................................................................................7 .

2 .1. TAKEN ............................................................................................................................................................... 7 2.1.1. Documentatie ............................................................................. ................................................................ 7 2.1.2. Ontwerp ..................................................................................................................................................... 8 2.1.3. Programma................................................................................................................................................ 8 2.1.4. Overdracht................................................................................................................................................. 8 2.2. PLAN VAN AANPAK ................ ............................................................................................................................ 8 2.3. METHODEN ........................................................................................................................................................ 9 2.315DM........................................................................................................................................................... 9 2.3.2. Object georiënteerd ontwerpen................................................................................................................ 10 2.4. TECI-INIEKEN ............................................... .................................................................................. ................... 11 2.4.1. OMT......................................................................................................................................................... 11 2.4.2. Visual C++ .............................................................................................................................................. 14 2.4.2.1. C++ ..................................................................................................................................................................... 14 2.4.2.2. Microsoft Foundation Classes ............................................................................................................................. 17

2.4.3. Windows................................................................................................................................................... 18 3 ONTWERP . ...................................................................................................................................................... 20 .

3.1. FUNCTIONEEL DETAILONTWERP ...................................................................................................................... 20 3 1.1. Functionele Eisen .................................................................................................................................... 20 3.1.2. Systeembeschrjving ................................................................................................................................. 20 3.1.3. Gebruikersinterface ........................... ...................................................................................................... 2! .

3.1.4. Overige Externe Interfaces ...................................................................................................................... 22 3.1.5. Wiskundige Functionaliteiten .................................................................................................................. 22 3 1.6. Resultaat .............................................................. .................................................................................... 23 3.2. TEST SPECIFICATIES. ........................................................................................................................................ 23 3.3. TECHNISCH DETAILONTWERP .......................................................................................................................... 24 3.3.1. OMT......................................................................................................................................................... 24 3.3.2. Object model............................................................................................................................................ 24 3.3.3. Dynamic model........................................................................................................................................ 27 3.3.4. Functional model .............................................. ....................................................................................... 30 3.3.5. Resultaat.................................................................................................................................................. 30 .



Stageverslag


Inhoudsopgave

4 IMPLEMENTATIE ............................................. . ........................................................................................... 31 .

4 .1.AANPAK .......................................................................................................................................................... 31 4.2. ALGEMEEN ...................................................................................................................................................... 3 1 4.3. GEBRUIKERS INTERFACE ................................................................................................................................. 32 4.3.1. ivfenubalk ................................................................................................................................................. 33 4.3.2, Knoppenbalk ....................................................................................... ..................................................... 4.3.3. Invulvensters ................. .............. ............................................ ... .... ............... ... ...... .................................. 4.4. PRESENTA IIE ................................................................................................................................................... 4.4.1. Venstergrootte en positie .........................................................................................................................

33 34 34 34 4.4.2. Verhoudingen schip ................................................................................................................................. 35 4.4.3. Coördinaten ........... ................... .............. ...................... ........................................................................... 36 4.4.4. Geheugen lek ............................... ............................................. .................................................. ...... ........ 36 4.4.5. Flitsende bootjes ...................................................................... ............. ................................................... 36 4.4.6. Numeriek.................................................................................................................................................. 37 4.5. SIMULATIE ....................................................................................................................................................... 38 4.5.1. simulatie proces ...................................... .......................................................... ....................................... 38 4.5.2. Verplaatsende bodem ............................... ................................................................................................ 38 4.6. EVALUATIE ...................................................................................................................................................... 39 4.6.1. Planning ......................... .......................................................................................................................... 39 4.6.2. Ontvverp ................................................................................................................................................... 40 4.6.3. Produkt .................................................................................................................................................... 41 5 EVALUATIE .................................................................................................................................................... 42 .

5.1. OPDRACHT ....................................................................................................................................................... 5.1. 1. Produkten................................................................................................................................................. 5.1.2. Proces ...................................................................................................................................................... 5.1.3. Voltooiing ................................................................................................................................................ 5.2. LEEREFFECTEN ................................................................................................................................................ 5.3. THEORIE/PRAKTIJK ............................................ .............................................................................................. 5.4. OPLEIDING .............................................................. .........................................................................................

42 42 43 44 44 46 47

LITERATUURLIJST .......................................................................................................................................... 49


Rijswijk. 31 januari 1995

Stageverslag

1.


Inleiding

INLEIDING

Dit hoofdstuk is bedoeld ter inleiding op de beschrijving van activiteiten in mijn stage periode. Eerst wordt een introductie gegeven van de stageplaats en hoe ik die gevonden heb. Daarna een korte omschrijving van de werkplek en waar binnen de Organisatie ik mijn functie heb uitgevoerd. Vervolgens de opdracht omschrijving, die onderverdeeld is in de probleemstelling, de doelstelling en de produkten die het oplevert. Als laatste een overzicht van de hulpmiddelen die gebruikt zijn om de opdracht te realiseren.

1.1. INTRODUCTIE Sinds begin september loop ik stage bij een van de grootste overheidsinstellingen in Nederland, Rijkswaterstaat. Op de afdeling Hydro-Meteo Advisering (MTBA) van de Directie Noordzee om precies te zijn. Ik kwam op het laatste nippertje tot deze stageplaats. Na een lange tijd van corresponderen met verschillende bedrijven zat ik in augustus nog steeds zonder stageplek. Omdat de tijd echt begon te dringen, ben ik via de map met aangeboden stageplaatsen een aantal mogelijke instanties gaan bellen. Bij de Directie Noordzee, de tweede naam op mijn lijstje, was het gelijk raak. Na een introducerend gesprek met Frits Draisma, waarin hij op zijn gemak het probleem aan mij voorlegde. Een Software Ontwikkelings probleem met raakvlakken op het gebied van datacommunicatie en databases. Juist de drie uitstroom profielen waarop ik me wilde oriënteren. Bovendien ligt de werkplek op fietsafstarid van mijn kamer in Den Haag. In overleg met school en Dhr. Draisma besloot ik deze stage te vervullen.

1.2. OMGEVINGSSCHETS Het hoofdkantoor van Directie Noordzee bevindt zich te Rijswijk op het industrie terrein "Plaspoelpolder". De afdeling Hydro-Meteo Advisering zit temidden van de baggerdienst op de eerste verdieping van het gebouw aan de Koopmansstraat. Alle werknemers op de verdieping hebben beschikking over een eigen kamer. Heel af en toe wordt er een kamer gedeeld, maar alleen wanneer mensen ook nog een andere werkplek hebben, zoals bij het Hydro-Meteo centrum Rijnmond in Hoek van Holland. Over het algemeen krijgen stagiairs ook de beschikking over een eigen kamer, als daar ruimte voor is. Zo ook in mijn geval. De eerste drie maanden nam ik een kamer over van een tijdelijk overgeplaatste werknemer. Later kwam, doordat iemand ergens anders ging werken, een andere kamer vrij. Beide kamers hebben uitzicht op de binnenplaats en de blinde muur van het toenmalige kantoor van EDS-ICIM, die inmiddels zijn verhuisd. In beide kamers bevond zich een bureau met daarop een computer. Organisatie Zoals veel overheidsinstellingen is de Directie Noordzee van Rijkswaterstaat een complexe hiërarchische organisatie. De onderafdeling Hydro-Meteo Advisering is maar een klein onderdeeltje wat zich bijna onderaan bevindt. Om aan te geven waar, zal ik een beknopte beschrijving geven van de organisatie. De Hydro-Meteo Advisering (MTBA) maakt samen met Baggerwerken (MTBB) en Vaargeulen en Civiele Werken (MTBV) deel uit van de afdeling Baggerwerken en Vaargeulen (MTB). Deze afdeling is onderdeel van de hoofdafdeling Mariene Techniek (MT), deze bevat tevens de afdelingen Zeemetingen en Instrumentatie (MTZ). Het hoofd van de hoofdafdeling Mariene Techniek is op haar beurt samen met de hoofden van de hoofdafdelingen Waterbeheer (AM) en Bestuur en Facilitaire Zaken (RB) onderdeel van het directieteam, die weer onder de verantwoording valt van de Hoofdingenieur-Directeur (H.I.D.): Dhr. Dik Tromp. De Directie Noordzee zelf maakt deel uit van het Directoraat-Generaal van de Rijkswaterstaat, dit zijn een aantal verschillende afdelingen van Rijkswaterstaat die verantwoordelijk zijn voor taken in Nederland. Het Directoraat-Generaal van de Rijkswaterstaat staat weer onder verantwoording van de Secretaris-Generaal en de Minister van Verkeer en Waterstaat. Maar een plaatje zegt meer dan duizend woorden, voor meer duidelijkheid wat betreft de organisatiestructuur van directie Noordzee, zie figuur 1.


Rijswtjk, 31 januari 1995

Stageverslag


Inleiding

HID directieteam RB AM MT

RB bestuur en facilitaire zsken

AM

MT

waterbeheer

mariene techniek

emetingen en instrumentatie

baggeeen en vaargeulen

M1B

L__J

hyaoo

ncJ

Figuur 1 Organisatiestructuur directie Noordzee, gericht op MTBA

Hoewel ik alle taken van de complete Organisatie ZOU kunnen beschrijven zal ik me beperken tot de hoofdafdeling Mariene Techniek. Voor een gedetailleerde beschrijving van de Organisatie verwijs ik naar het bed rijfsonderzoek. De hoofdafdeling Mariene Techniek heeft als taken het zorgdragen voor de realisatie, beheer en onderhoud van zeewaterbouwkundige werken (vaargeulen, platforms) en meet- en informatiesystemen. Hiernaast verschaft deze hoofdafdeling meetinformatie en adviezen. Vooral met het laatste onderdeel houdt de Hydro-Meteo Advisering zich bezig. Samen met het KNMI werkt deze onderafdeting in het Hydro-Meteo centrum Rijnmond (HMR) in Hoek van Holland. Vanaf deze locatie vervult de afdeling de volgende hoofdtaken: Het verstrekken van Hydro-adviezen Dit houdt voornamelijk in, het genereren van verwachtingen en het registreren van meetwaarden. Met het verstrekken van deze gegevens vervult de afdeling MTBA een maatschappelijke behoefte aan hydro-adviezen voor het beheersgebied van directie Noordzee. In het algemeen is dit ten behoeve van de scheepvaart, waterhuishouding, veiligheid en werkbaarheid op zee. Het verstrekken van Maritieme informatie met betrekking tot scheepvaart Naast adviezen verstrekt de afdeling MTBA ook exacte meetgegevens, zoals die worden geregistreerd door het meetnet op de Noordzee. Daarbij houdt ze een database van schepen bij. Al deze gegevens worden verstrekt aan derden. Het uitvoeren van bewakingstaken, communicatietaak en subkustwachttaak Deze taken bestaan uit, het bewaken van het meetnet, communicatie met schepen op de Noordzee en het vervullen van een intermediair tussen de Kustwacht en directie Noordzee.


.


Stageverslag


Inleiding

4) Het opstellen van tijpoorten voor geulen tijdgebonden scheepvaart Dit is de taak die het meest te maken heeft met mijn stageopdracht. Aan de hand van gemeten gegevens en voorspelde waarden, geeft de afdeling voor ieder tij-gebonden schip een advies uit. Dii zijn de zogenaamde tijpoort adviezen Het schip moet zich hieraan te houden, zodat de kans dat een schip de bodem raakt zeer klein wordt gehouden. Op dit onderdeel wordt nader ingegaan in de komende paragraaf.

1.3. OPDRACHT In deze paragraaf ga ik nader in op de opdracht. Ik begin met het opstellen van de probleemstelling. Waarin ik een beschrijving geef van de huidige situatie en wat de opdrachtgever hieraan wil veranderen. Daarna vervolg ik met de doelstellingen die met behulp van het resultaat moeten worden vervuld. En als laatste geef ik aan welke produkten het vervullen van de opdracht uiteindelijk oplevert.

1.3.1. Probleemstelling Op de aanlooproute naar Rotterdam en Amsterdam zijn geulen aangelegd in de ondiepe Noordzee bodem. Dankzij die geulen zijn diepstekende schepen (van 56 tot 74 voet, oftewel 17 tot 22,55 meter) in staat de havens zonder vast te lopen te bereiken. Omdat het veel te duur is om de geulen heel diep te maken, zijn ze precies diep genoeg om de diepst stekende schepen bij de juiste omstandigheden veilige doorgang te garanderen. Een van de taken van de afdeling Hydro-Meteo Advisering (MTBA), is het uitbrengen van een advies voor deze tij-gebonden schepen. Aan de hand van tabellen, die rekening houden met: het getij; de energie van laag frequente golven; de op- of afwaaiing van water; de diepgang van het schip en de lading, wordt een tijpoort advies vervaardigd waaraan de schepen zich moeten houden. Richtlijn voor het opstellen van deze adviezen is dat het schip tijdens de vaart maar 1% kans heeft om de bodem te beroeren en dat het over alle vaarten genomen slechts eens in de 2500 keer gebeurt (0,04%). Deze methode waarbij gerekend wordt aan de hand van tabellen werkt feilloos, maar is voor de medewerkers van Hydro-Meteo Advisering nogal ondoorzichtig. Ze willen eigenlijk met eigen ogen zien wat er onderweg met een schip gebeurt en waar zich de grootste risico's afspelen. Om dit zichtbaar te maken moet een simulatiemodel worden ontwikkeld. Afstudeer project Gedurende het eerste halfjaar van 1993, heeft een student van de Haagse Hogeschool, Sector Informatica, zich op dit probleem gestort in de vorm van een afstudeer project. De student, Peter-Paul de Bruin kreeg door een te optimistische inschatting van bepaalde onderdelen in het ontwikkelingstraject, het project niet op tijd rond. De produkten die hij wel heeft gerealiseerd zijn: • • • • •

Functioneel detailontwerp Prototype van het simulatiemodel Rapport Testspecificaties Technisch detailontwerp Begin implementatie simulatiemodel

Het werd mijn taak om dit project over te nemen en af te ronden. Dit moest gebeuren door eerst alle produkten van Peter-Paul te controleren op consistentie, volledigheid en kwaliteit. En vervolgens een eigen ontwerp samen te stellen.

1.3.2. Doelstelling Het programma is ontstaan uit een idee van Frits Draisma, die wilde een visueel alternatief tegenover de zeer wiskundige kansberekeningen, die gebruikt worden om de tijpoorten te bepalen. Per vaart wil hij kunnen zien, wat er onderweg met een schip gebeurt onder invloed van verschillende omstandigheden:


Rijswijk. 3! januari 1995

Stageverslag

Simulatie Diepstekende Schepen -

Inleiding

• astronomisch getij • de opwaaiing of afwaaiing van water • goifslag • stroming • de bodem die onder het schip doorgaat • scheepsbewegingen • de diepgang van het schip De maximale diepgang van de huidige toegelaten diepstekende schepen overschrijdt de 74 voet niet. Maar voor 1995 bestaat er het plan een 75 voeter toe te laten tot de Rotterdamse haven. Onderzoek door de directie Noordzee heeft aangetoond dat dit bij gunstige omstandigheden in principe mogelijk moet zijn. Het simulatie model kan hierbij een hulpmiddel zijn, voor het inzichtelijk maken van de geulvaart. De belangrijkste doelstelling van het simulatie model is het visueel maken van een geulvaart. Schepen van allerlei soorten en maten varen bij ingestelde (of gemeten) omstandigheden over de werkelijk gemeten bodem. Zo wordt het zichtbaar, waar het fout en waar het goed gaat. Daarbij levert het programma een log bestand per kilometer en over de gehele afstand, zodat iedere vaart ook later nog kan worden besproken, aan de hand van deze registratie. Het simulatiemodel kan een hulpmiddel zijn bij het bepalen van beleid rond de geulvaart. Bovendien kunnen risicovolle vaarten van te voren of na afloop worden geëvalueerd, waarbij het niet onmogelijk moet worden geacht dat een en ander het tijpoortadvies zo mogelijk kan beïnvloeden.

1.3.3. Produkten De opdracht levert slechts één produkt op. Een programma dat geulvaarten simuleert. Het draait op een MS-DOS compatible computer met Windows. De computer moet minimaal een 386 van 25 MHz zijn, maar een snellere machine zal betere resultaten leveren. Het programma moet kunnen beschikken over de lodingsbestanden van de geulen. Bovendien moet contact mogelijk zijn met DBHMR, waarin voorspellingen en gemeten waarden van waterstanden en golfslag in opgeslagen staan. Vervolgens kan de gebruiker door het invoeren van scheepsgegevens, het invoeren van tijd en datum van de vaart en eventueel de watergegevens, een simulatie specificeren. Het programma zal vervolgens, in normale, of versnelde tijd de simulatie uitvoeren. Op het beeldscherm is zichtbaar: • • • • •

Vooraanzicht van het schip met de bodem Zijaanzicht van het schip met de bodem Numerieke waarden tijdens de vaart Topografie van de geul en de positie van het schip De waterstand over het hele traject en de positie van het schip

Naast deze visuele weergave, wordt op de harde schijf ook nog een logbestand weggeschreven, waarin gemiddelde en minimale waarden geregistreerd staan. De enige interactie tussen gebruiker en programma gebeurt via de invoer vensters. Als de simulatie eenmaal gestart is, kan de gebruiker de simulatie alleen nog maar pauzeren of beëindigen.

1.4. HULPMIDDELEN In deze paragraaf beschrijf ik de hulpmiddelen die ik gebruikt heb bij het voltooien van de opdracht. Sommige van deze hulpmiddelen zullen voor zichzelf spreken, maar ik vind dat ze toch genoemd moeten worden, omdat ze een belangrijke rol spelen bij de realisatie van de opdracht. En zonder zou het een stuk moeilijker zijn geweest om de opdracht tot een goed einde te brengen.

1.4.1. Hardware Tulip 386, 25 MHz. De computer waarmee ik in eerste instantie aan de slag ben gegaan. Deze heb ik vooral gebruikt voor de rapportage rond het ontwerp van het simulatie model. Een snellere computer was de eerste paar maanden nog niet nodig, omdat ik geen compiler hoefde te gebruiken.


Rijswijk, 31 Januari 1995

Stageverslag


Inleiding

Planhold 486, 66 MHz. Het ontwerp bereikte uiteindelijk het stadium, waarin ik een compiler nodig had. Ik heb de Tulip toen verruilt voor de snelle computer van de collega van Frits Draisma, Rob van Houten. De minimum eisen voor Microsoft's Visual C++, vragen om een computer met meer dan 4 Megabyte geheugen en een minimale kloksnelheid van 50 MHz. De Planhold voldeed ruim aan deze eisen.

HP LaserJet 4. Vanzelfsprekend, maar toch essentieel. Dit type printer staat door heel het gebouw op vele plaatsen in het gebouw. Dankzij dit hulpmiddel was het realiseren van goed ogende rapportage en ontwerpen in een mum van tijd gebeurt.

1.4.2. Software Visio 1.0. Dit hulpmiddel kwam goed van pas bij het maken van Data Flow Diagrammen en de diagrammen van het Object-oriented Modeling Technique (zie verder). Het heeft niet de vierde generatie mogelijkheden als een pakket als SDW. Maar het stelt de gebruiker wel in staat nieuwe schematechnieken zelf toe te voegen. Het voordeel is ook dat dit stukje software prima samenwerkt met de Windows omgeving, zodat ontwerpen gelijk via Object Link Embedding in andere programma's kunnen worden opgenomen.

Word 6.0. Samen met WP een van de beste tekstverwerkers van dit moment. Waarbij Word het voordeel heeft dat het ook zo goed samenwerkt met de Windows omgeving. Zonder dit hulpmiddel hadden de ontwerpen en deze verslagen er niet zo goed uit gezien. Visual C++ versie 1.0 Dit is het hulpmiddel wat ik in het laatste stadium van de opdracht het meeste heb gebruikt. Het is meer dan een compiler alleen, dit is een volledig geïntegreerde programmeer omgeving. Met de nodige hulpmiddelen om het de software ontwikkelaar wat makkelijker te maken.

- Visual Workbench Dit is de omgeving waarin alle onderstaande hulpmiddelen zich in bevinden. Hierin wordt tijdens het programmeren het meest gewerkt. Hier zit de editor in, de debugger, de compiler, classwizard, application studio, de helpdatabase en de browser. Dit onderdeel brengt alle losse delen samen tot een geheel.

- Classwizard Het hulpmiddel dat de programmeur helpt tijd te besparen. Programmeren in C++ voor Windows brengt voor iedere applicatie dezelfde soort basis routines met zich mee. De Classwizard neemt het programmeren van deze routines van de programmeur over.

- Microsoft Foundation Classes (MFC2.0) Een vergevorderde vorm van het oude principe van bibliotheek routines. Alleen deze maken gebruik van de voordelen van C++. Dit is een van de onderdelen die ook wordt gebruikt door de classwizard. Meer hierover in het volgende hoofdstuk.

- Application Studio Het onderdeel dat het grafische en dialoog onderdeel van het programmeren makkelijker maakt. Hierin kunnen invoervensters, menubalken, bitmaps, iconen en nog veel meer worden ontworpen. Die kunnen vervolgens eenvoudig in je programma worden gehangen, met behulp van de resource. Ook hierover meer in het volgende hoofdstuk.


Rijswijk, 3 1 januari 1995

Stageverslag

Simu!atie Diepstekende Schepen

Inleiding

- Compi/er Het hart van het geheel. Deze zet alle C++ code om naar programma's.

- Debugger Een van de meest behulpzame middelen van het pakket. Fouten opsporen kan hiermee stap voor stap, meekij ken en veranderen van variabelen is ook mogelijk.

- Browser In samenwerking met de debugger een handig hulpmiddel. Als een functie of variabele onbekend voorkomt, kan hiermee zo de definitie, of de referenties naar, worden opgespoord.

Rijkswaterstaat, Directie Noordzee -


Stageverslag

--


Aanpak

Dit hoofdstuk handelt over de werkzaamheden en de handelwijze waarop deze werkzaamheden zijn uitgevoerd. Er wordt in gegaan op de methoden en waarom voor deze methoden is gekozen. Tevens worden een aantal technieken en technische beschrijvingen gegeven. Deze zijn van belang bij het begrijpen van de onderwerpen in het volgende hoofdstuk.

2.1. TAKEN In deze paragraaf geef ik een overzicht van de verschillende werkzaamheden die kwamen kijken bij het uitvoeren van de opdracht.

2.1.1. Documentatie De opdracht was, zoals in de probleemstelling te lezen valt, is eerder uitgevoerd door afstudeerder Peter-Paul de Bruin. Hij heeft zich indertijd bezig gehouden met het ontwerpen van het Simulatie Model. Daarbij heeft hij de volgende documentatie achter gelaten: • Afstudeerverslag, Simulatieprogramma voor diepstekende schepen [BRUIN93a]

Een overzicht op de uitvoering van de afstudeerperiode van Peter-Paul. Met daarin een beschrijving van de aanpak, methoden en technieken die hij gebruikt heeft. • Rapport definitiestudie/basisontwerp [BRUIN93b]

De voorstudie aan de hand van SDM. Waarin een definitie van eisen wordt gegeven. • Rapport functioneel detailontwerp [BRUI N93c]

De definitie van eisen verwerkt tot een functioneel ontwerp. • Rapport technisch ontwerp [BRUIN93d]

Het technische ontwerp waarbij gebruik is gemaakt van de object georiënteerde techniek 'OMT'. • Rapport testspecificaties [BRU] N93e]

Dit is een verzameling testsets waaraan het ontwikkelde simulatiepakket kan worden blootgesteld om de werking te testen. Omdat Peter-Paul aan de hand van interviews en gesprekken met de opdrachtgevers alle eisen al heeft vastgesteld, was het zaak deze rapporten door te nemen, te evalueren en uit te breiden om tot een eigen ontwerp te komen. In deze rapporten wordt gebruik gemaakt van een aantal methoden, die tijdens mijn opleiding niet behandeld zijn. Dit zijn, Object-oriented Modeling Technique (OMT) en C++. Hierbij heeft hij gebruik gemaakt van de volgende twee boeken: • "Object-Oriented Modeling and Design" van James Rumbaugh [RUMBAU91] • "Windows programming with Microsoft C++" van Michael J. Young [YOUNG93] Daarbij heeft Peter-Paul informatie gehaald uit een aantal uitgaven van de directie Noordzee zelf. Belangrijkste daarvan zijn: • "Varen in de 72' geul" [KIELSP84] • "Informatie voor de vaart met diepstekende schepen naar Rotterdam" [MARIEN90] • "Evaluatie geulvaart 1991 Euro-Maasgeul" [GEUL92] Als laatste was er ook nieuwe documentatie: • "PC-HMR: PC-programmatuur HMR Functionele specificatie" [INGEN94] Om een goed beeld te krijgen van de opdracht en om ontwerpmethoden als OMT te kunnen begrijpen was het nodig om deze documentatie van te voren grondig door te nemen.



Stageverslag

Simuatie Diepstekende Schepen

Aanpak

2.1.2. Ontwerp Door middel van evaluatie van de verschillende verslagen van Peter-Paul, door het zelf vergaren van nieuwe informatie en door het opstellen van nieuwe eisen. Moest tot een eigen ontwerp worden gekomen. Aan de hand daarvan werd de implementatie opnieuw uitgevoerd.

2.1.3. Programma Dit is het onderdeel waar alle op papier vastgestelde eisen tot een werkend programma samen moeten komen. De implementatie gebeurt met behulp van de programmeer omgeving Visual C++. Voordat hiermee aan de slag gegaan kan worden, moet eerst een deel van de documentatie bij dat pakket worden doorgenomen. De belangrijkste boeken die hierbij aan bod komen zijn: Visual Workbench User's Guide [MICROS93c]

Een onderdeel van de User's Guides, waarin wordt uitgelegd hoe het hart van de pro grammeer omgeving in elkaar steekt en hoe onderdelen, als de editor, debugger, browser en helpdatabase werken. • App Studio User's Guide [MICROS93c]

Dit is de gebruikershandleiding die van pas komt bij het leren kennen van het ontwerp programma voor de grafische user interface. • C++ Tutorial [MICRO93a]

Een stoomcursus voor mensen die al wel met C gewerkt hebben, maar nog niet eerder kennis hebben gemaakt met C++. Hierin wordt onder andere uit de doeken gedaan wat objecten en classes zijn en hoe je ermee om moet gaan. • Class library User's Guide [MICROS93b]

Als je C++ onder de knie hebt, dan kanje samen met de Microsoft Foundation Classes heel veel tijd en moeite uitsparen. De Class Librari User's guide legt aan de hand van een voorbeeld uit hoe je de Classwizard moet gebruiken en hoe Windows om gaat met C++ programma's. • C/C++ Language reference [MICROS93d]

Essentieel naslagwerk voor tijdens het programmeren.

2.1.4. Overdracht Wanneer het programma op tijd af komt. Zal het programma worden afgeleverd aan de opdrachtgever. Dit moet gebeuren aan de hand van een korte cursus. Echter, als de stage ten einde loopt en het programma is nog niet af, dan moet er tijd worden besteed aan het zo goed mogelijk overdragen op de volgende programmeur.

2.2. PLAN VAN AANPAK Aan de hand van de bovenstaande taken zijn de volgende activiteiten vastgesteld • voorbereiden • evalueren en bijwerken functioneel detailontwerp • evalueren en bijwerken testspecificaties • evalueren technisch ontwerp • programmeren en implementeren • invoering of overdracht De activiteiten 'evalueren technisch ontwerp' en 'programmeren en implementeren' bestaan naast ontwerpen en programmeren voor een groot gedeelte uit het lezen en bestuderen van de documentatie en literatuur. De periode waarin de werkzaamheden worden uitgevoerd is het tweede halfjaar van 1994. Om precies te zijn in de honderd werkdagen na de startdatum (5 september). Rekening houdend met de eventuele kerstvakantie werd de volgende planning aangehouden:


Rijswijk, 31januari 1995

Stageversiag

- Simulatie Diepstekende Schepen

Aanpak

In week 36 tot en met 51 (5 september -23 september) vallen de eerste 16 weken. Vervolgens een week vrij, week 52 (27 december - 30 december). De laatste 4 weken verlopen van 2 januari tot 27 januari met eventuele uitloop week 5 (30 januari - 3 februari). Als we uitgaan van die planning zijn de deadlines van de bovenstaande produkten als volgt: • woensdag 14 september: • woensdag 28 september: • woensdag 5 oktober: • vrijdag 21 oktober: • vrijdag 23 december: • donderdag 19 januari:

Plan van aanpak Rapport functioneel ontwerp (bijlage 1) Rapport test specificaties Rapport technisch ontwerp (bijlage II) Werkend programma simulatiemodel (bijlage IV) Invoering of overdracht simulatiemodel (bijlage III)

Deze planning is grafisch gepresenteerd in figuur 2.

plan van aanpak evalueren fuctioneel ontwerp evalueren test specificaties evalueren technisch ontwerp impiementeren overdracht

week

1 2 3 4 5 6 7 8

9 10 11 12 13 14 15 16 17 18 19 20

Figuur 2 Ganit-chart tijdsindeling

2.3. METHODEN In deze paragraaf wordt nader ingegaan op de methoden die gebruikt zijn voor het ontwerpen en realiseren van de opdracht. Van die methoden die uitvoerig gebruikt zijn wordt een beknopte uitleg gegeven. Deze paragraaf en de volgende zijn essentiële stof voor lezers die zich willen verdiepen in het volgende hoofdstuk. Waar mogelijk wordt ook uitgelegd waarom juist voor die methode gekozen is.

2.3.1. SOM Dit is een methode die uitgebreid behandeld is in de zogenaamde Kern Informatica (K15) vakken aan de Sector Informatica, Haagse Hogeschool. In deze subparagraaf wordt de methode slechts oppervlakkig beschreven. Voor meer informatie over deze ontwerpmethode verwijs ik naar de boeken "SDM: Samenvatting van de System Development Methodology" [SDM89] en "SDM: System Development Methodology (Nederlandse versie)" [TU RN ER9O]. SDM staat voor System Development Methodology, vrij vertaald in het Nederlands 'Systeem Ontwikkeling Methode'. Het is een ontwikkelmethode bedacht door de firma CAP GEMINI in 1974 en het heeft sinds die tijd een grote naam gemaakt in de wereld van de Software Ontwikkeling. Het is een methode die zich voornamelijk bezig houdt met de planning en organisatie van de systeemontwikkeling. Ze helpt de ontwikkelaar anticiperen op bepaalde gebeurtenissen bij de ontwikkeling van een informatiesysteem. En zorgt er voor dat de ontwikkelaar een methode consequent zal toepassen. De methode wordt gebruikt voor het ontwikkelen van geautomatiseerde systemen, maar juist de typisch menselijke aspecten ervan worden benadrukt. SDM legt bijzonder de nadruk op de ontwikkeling van passende mens/machine-interfaces.

Rijkswaterstaat, Directie Noordzee -


Stageverslag


Aanpak

SOM beschrijft de vele processen die bij systeemontwikkeling een rol spelen en ordent die in een aantal vaste ontwikkelingsstadia, zodat de systeemontwikkelaar gerichter te werk gaat. De ontwikkelmethode is opgedeeld in zeven stadia: 0. Informatieplanning

Dit is de fase die handelt over ontwikkelingsplannen voor het te maken informatiesysteem. Definitiestudie

Stelt vast welke eisen er worden gesteld aan het systeem. Basisontwerp

Hierin worden de eisen verfijnd en het ontwerp van subsystemen ontwikkeld. Detailontwerp

De systeemeisen en het ontwerp van subsystemen worden nog verder verfijnd, zodat specifieke onderdelen kunnen worden ingevoerd. Realisatie

De fase waarin de programmatuur wordt veîvaardigd en uitgetest. Invoering

Fase die betrekking heeft voor het operationeel maken van het nieuwe systeem. Gebruik en beheer

Dit is het proces wat ook wel de 'nazorg' wordt genoemd. Waarin het werkend systeem wordt bijgehouden en in zodanige staat wordt gehouden dat het tegemoet komt aan bestaande en nieuwe eisen. SDM geeft voor al deze fasen richtlijnen wat betreft de documentatie, kwaliteitsbeoordeling, standaards, tools, technieken, management en planning. Deze methode komt vooral goed van pas bij het ontwikkelen van grote informatiesystemen. Maar is voor ieder software ontwikkelingsprobleem geschikt, omdat het orde brengt in de activiteiten. Motivatie Peter-Paul heeft gebruik gemaakt van de ontwikkelmethode SDM II, deze is meer gericht op kleine projecten. Maar zover ik het bestudeerd heb, wijkt deze methode heel weinig af van de oorspronkelijke SOM. Mijn keuze om met 5DM te werken was vooral gemaakt omdat Peter-Paul zoveel onderzocht heeft met deze methode. Het is daarom eenvoudiger om aan de hand van dezelfde methode te werk te gaan en zijn werk te controleren.

2.3.2. Object georiënteerd ontwerpen Dit is niet zozeer een methode als wel een totaal andere denkwijze op het gebied van modelleren en programmeren. De principes achter object oriëntatie zijn voor het eerst naar voren gekomen in 1966 bij het ontstaan van de taal Simula. Simula is een op Algol gebaseerde programmeertaal die geschikt is gemaakt voor het uitvoeren van simulaties. In de jaren 70 en 80 werden object-georiënteerde concepten van Simula verder uitgewerkt in één van de invloedrijkste object georiënteerde talen: Smalltalk. Object Georiënteerd modelleren is een andere manier van het beschrijven van problemen, gebruik makende van concepten uit de echte wereld om ons heen. Objecten in de werkelijkheid hebben eigenschappen. Neem bijvoorbeeld een bal, een bal kan een bepaalde kleur hebben, van een bepaald materiaal gemaakt zijn, een bepaalde temperatuur hebben en vertoond bepaalde gedragingen als we hem in beweging brengen. Over het algemeen gesproken kunnen we deze eigenschappen opdelen in vier aspecten: identiteit, soort, meervormigheid en erfelijkheid. Met identiteit wordt bedoeld dat gegevens op te delen zijn in duidelijk verschillende dingen onder de naam objecten'. Zo spreek je over verschillende objecten als je het hebt over de witte koning in het schaakspel of een venster op het scherm.



Stageverslag


Aanpak

Soort is de wijze waarop je objecten met gelijke eigenschappen, zoals bijvoorbeeld de (data) structuur of het gedrag kan classificeren. Binnen object georiënteerde ontwerp-methoden en talen wordt in dit geval meestal gesproken van een 'class'. Classes worden gebruikt om objecten abstract te maken tot enkel de essentie over blijft. Zo zou je bijvoorbeeld kunnen spreken van een fiets class, waarmee je alle objecten die tot de soort fietsen horen kunt definiëren. Meervormigheid geeft aan dat bepaalde gedraging of eigenschappen verschillende consequenties hebben voor verschillende soorten objecten. Zo is bijvoorbeeld verplaatsen voor een venster op het scherm iets heel anders dan voor een schaakstuk in het schaakspel. Erfelijkheid wil zeggen dat sommige classes elkaars eigenschappen en gedraging delen als ze een hiërarchische relatie tot elkaar hebben. Een class kan in het hoogste niveau slechts heel algemeen worden gedefinieerd, waarna je de subclasses die gebaseerd zijn op deze class steeds specifieker gaat definiëren. Daardoor kunnen objecten die behoren tot de subclassen gebruik maken van eigenschappen die gedefinieerd zijn in de hoogste class. Deze mogelijkheid van het delen van overeenkomsten zorgt ervoor dat modellen en programma's aanzienlijk minder herhalingen bevatten en dus minder ruimte in beslag nemen. Het bovenstaande is een wat abstracte omschrijving van de basisprincipes van object oriëntatie. Hoe deze methode in de modellering en programmering gebruikt wordt, komt verder naar voren in de paragrafen over technieken. Motivatie Opnieuw is de belangrijkste motivatie achter het kiezen voor deze methode het feit dat Peter-Paul hiervoor gekozen heeft. Toch ben ik het zeer zeker eens met zijn beweegredenen achter deze denkwijze. Vooral wat betreft simulaties kan deze methode zeer veer voordelen hebben. Aangezien je concepten uit de werkelijkheid herkenbaar kan modelleren. Dit maakt modellen begrijpelijker voor de opdrachtgevers en eindgebruikers. Bovendien heeft de programmeur er ook gemak van, omdat objecten alleen met zichzelf en hun eigen gegevens bezig houden. Dit heeft tot gevolg dat er overzichtelijk en veilig geprogrammeerd kan worden. Er kleeft echter een nadeel aan deze ontwerp methode. Ze is nog betrekkelijk nieuw en daarom nog sterk in ontwikkeling. Waarschijnlijk daarom is het een methode die nog niet behandeld is tijdens mijn opleiding. Toch is het mijns inziens een denkwijze die in de toekomst gaandeweg meer terrein zal winnen. Het is dus bijzonder leerzaam er in de praktijk kennis mee te maken.

2.4. TECHNIEKEN Deze paragraaf kan gezien worden als een korte stoomcursus object georiënteerd modelleren en programmeren in de Windows omgeving. Er wordt slechts een globaal overzicht gegeven van de technieken, zodat de lezer in staat is de onderwerpen uit de volgende hoofdstukken te begrijpen. Voor gedetailleerdere beschrijvingen wordt verwezen naar de literatuur.

2.4.1. OMT OMT staat voor Object-oriented Modeling Technique. Het is een techniek die uitvoerig staat beschreven in "Object Modeling and Design" [RUMBAU91]. De techniek legt in tegenstelling tot vele andere technieken en methoden erg de nadruk op analyse en ontwerp. De gedachte hierachter is dat fouten in de ontwerpfase goedkoper zijn aan te passen, dan fouten die pas ontdekt worden in de implementatie fase. Object-georiënteerd ontwerpen is een conceptueel proces dat compleet onafhankelijk is van de taal. Tot aan de laatste stadia, waarbij de taal weer essentieel is. Het grootste voordeel van deze techniek is dat de abstractie van het ontwerp helder blijft voor zowel de ontwerper als de opdrachtgever en toekomstige gebruiker. Voor het gebruik van OMT wordt een object-georiënteerde methode geadviseerd die bestaat uit vier stadia: de analyse; het systeemontwerp; object ontwerp en de implementatie. In wezen verschilt deze methode niet zoveel met die van SDM. Daarom is de techniek ook te gebruiken binnen het technisch detailontwerp stadium van SDM.



Stageverslag


Aanpak

OMT maakt gebruik van drie soorten modellen om een systeem te beschrijven: • Object Model

Hierin wordt de statische structuur beschreven van de objecten die in het systeem zijn opgenomen. Daarbij wordt beschreven wat hun relatie tot elkaar is. De schema techniek die hiervoor gebruikt wordt heet het 'object diagram', dit is een soort graaf waarin de noden de objecten zijn en de verbindingen de relaties. • Dynamisch Model

Beschrijft de aspecten van een systeem dat verandert in de tijd. Het dynamisch model wordt gebruikt om de con trole aspecten van een systeem te beschrijven. Dit model maakt gebruik van zogenaamde 'state dia grams'. Opnieuw is dit een soort graaf waarvan de noden de stadia zijn en de verbindingen de transities tussen de stadia. • Functioneel Model

Dit model beschnjft de verandering van gegevens binnen een systeem. Het functioneel model wordt beschreven met behulp van 'data flow diagrammen' (DFD's). In een DFD zijn de noden de processen en de verbindingen de gegevensstromen. Deze, modellen samen zijn nodig om alle aspecten van een systeem te beschrijven. Het object model is het meest fundamenteel, omdat het belangrijker is eerst te beschrijven wat er verandert, voordat er nagedacht wordt over hoe en wanneer het verandert. Object Model

Het doel van een Object Model is die aspecten van de buitenwereld te beschrijven die voor het toekomstig systeem van belang zijn. Deze aspecten worden in het Object Model beschreven in de termen waarin ze in de omgeving van het probleem bekend zijn. Problemen uit de Horeca maken gebruik van terminologie van de Horeca. Problemen uit de autoindustrie worden weer beschreven met termen uit de Autoindustrie. Het Object Model staat los van de implementatie in de computer. Het Object model wordt grafisch gepresenteerd met behulp van Object Diagrammen. In de Object diagrammen wordt de class-hiërarchie en de relaties tussen objecten zichtbaar. Tevens zijn de attributen uit het diagram af te lezen. In het onderstaande figuur wordt een beknopt overzicht gegeven van deze tekentechniek. Generalisatie (erfelijkheid):

Relatie Verhoudingen:

Ciass: Class Name

Class

Precies één

Class

Veel (nul of meer)

Class

Optioneel (nul of een) Subclass 1 Subciass 2

Superciass

/[\

Relatie:

Classi

rela Se

Ciass2

Een of meer

Object:

Gespeciticeerd

Figuur 3 Belangrijkste symbolen van de tekentechniek voor object diagrammen

Rijswijk,


12

31 januari 1995

Stageverslag


Aanpak

Om van een probleem tot een Object Model te komen worden de volgende stappen doorlopen: Identificeer objecten en classes Maak hiervan een data-dictionary Identificeer associaties tussen objecten Identificeer de attributen van objecten Reorganiseer en vereenvoudig de objecten door gebruik te maken van erfelijkheid Toets het verkregen model aan de buitenwereld Herhaal stap 1 tot en met 7 om het model te verfijnen Groepeer de classes in modules ten behoeve van de overzichtelijkheid van de grafische presentatie Dynamisch Model Het dynamisch model legt het tijdafhankelijke gedrag van objecten vast. Hierin worden de volgorde van operaties die voorkomen beschreven, zonder dat er hierbij in wordt gegaan op wat de operatie doet, waar een operatie invloed op heeft of hoe de operatie wordt geïmplementeerd. Dit model wordt grafisch gepresenteerd aan de hand van state-diagrammen. Elk state-diagram geeft van een object de toegestane stadia en gebeurtenis-volgorde binnen het systeem weer. Acties in het state-diagram corresponderen met functies in het functioneel model. Gebeurtenissen in een statediagram worden later operaties in het Object Model. Om state-diagrammen te kunnen tekenen wordt in OMT twee tussenstappen geboden. Eerst moet een eventtrace worden gemaakt, die geeft aan in welke volgorde de gebeurtenissen tussen de objecten plaatsvinden. Daarna maak je een eventflow, waaruit is af te leiden tussen welke objecten er een gebeurtenis plaats vindt. Het onderstaand figuur geeft een beknopt overzicht van de tekentechniek.

Initial state:

Final state:

t: I l_

State

j

Gebeurtenis tussen twee states:

State -1

State

D

gebeurtenis Ste.2

D

Gebeurtenis met attribuut: gebeurtenis (attrrbuut)

State generalisatie (nesting):

State. 1

State . 2

Superstate Gebeurtenis onder voorwaarde: gebeurtenis State - 1

gebeurtenis 2

gebeurtenis

D

gebeurtenis [condttie]

KII

State . 2

3

Figuur 4 Overzicht tekentechniek state-diagrammen

De volgende stappen worden ondernomen om tot een dynamisch model te komen: Beschrijf scenario's van typische interacties tussen objecten Identificeer events en gebeurtenissen tussen objecten Maak een eventtrace voor elk scenario Maak de state-diagrammen Controleer op consistentie



13


Stageverslag

Aanpak

Functioneel Model Het functioneel model legt de transformaties van waarden, beperkingen, domeinen en functionele afhankelijkheden van het systeem vast. In het functioneel model wordt vastgelegd wat het systeem doet, zonder aandacht te besteden aan de manier waarop dit gedaan wordt. Dit model wordt gepresenteerd aan de hand van dataflow-diagrammen. Hieronder wordt een kort overzicht gegeven van de tekentechniek. Proces:

G

Buitenwereld: Buffer:

Extern

Data store

ss

Gegevensstroom:

(:E)gegevensQ

Figuur 5 Tekentechniek Data Flow Diagrammen (DFD)

Voor het opstellen van het functioneel model schrijft OMT de volgende stappen voor: Specificeer de in- en outputwaarden Teken de functionele afhankelijkheden met behulp van dataflow-diagrammen Beschrijf de functies Identificeer de domeinen van de waarden Specificeer optimaliseringscriteria

2.4.2. Vis ual C++ Voor het begrijpen van deze paragraaf is enige kennis van de programmeertaal C' nodig. Hoewel alleen de elementaire onderdelen van Visual C++ worden beschreven, zal voor een leek sommige terminologie onduidelijk blijven. Wie zich toch wil verdiepen in deze paragraaf en de technische onderdelen van het volgende hoofdstuk, raad ik aan een inleidend boek over programmeertalen door te nemen en C' of C++' in het bijzonder.

2.42.1. C++ C++ is een programmeertaal die ontwikkeld is uit de taal C. Op een paar uitzonderingen na is C++ een groter omvattende verzameling waar C ook in zit. Dit betekent dat alles wat mogelijk is in C in principe ook mogelijk is in C++. In C++ zijn een aantal dingen bijgewerkt die in C ook al mogelijk waren, maar er zijn ook een hoop nieuwe dingen aan toegevoegd. Dit zijn de simpelste vernieuwingen: • Functie argumenten met standaard waarden • Flexibele variabele declaraties • Een scope resolution' operator voor het gebruik bij locale en globale variabelen en functies • Het 'inline' keyword voor het verminderen van de cail stack • De 'const' qualifier, voor het declareren van constante variabelen • Enumeraties • Overloading. Het dubbel declareren van functies, om de leesbaarheid te vergroten • Link specificaties voor het gebruik van meerdere talen in een source



14

Stageversiag


Aanpak

Maar al deze extra's zijn slechts kleine wijzigingen in vergelijking met de werkelijk belangrijke verandering. Het gebruik van classes', dit maakt het mogelijk om in de taal C object georiënteerd te programmeren.

Classes Een 'class' is de C++ benaming voor de term 'soort' (zie paragraaf 2.3.2.). Een class is een door de gebruiker gedefinieerd type, waarmee objecten kunnen worden gedeclareerd. Het is gebaseerd op C typen zoals de 'struct', waarmee abstracte data types mee vast te leggen zijn. Een class is een veel machtiger typedefinitie dan de door de gebruiker gedefinieerde types uit de taal C. In een class kan je namelijk niet alleen de data definiëren, maar tevens de operaties die gebruik maken van deze data. De definitie van een 'datum' class ziet er bijvoorbeeld zo uit: // Datum class // functie library voor in- en uitvoer #include class Datum public: Datum(int dg, int md, int jr) void drukaf () -Datum() private: int dag, maand jaar;

Constructor

7/ Functie voor het afdrukken van de datum /7 Destructor // prive data

De regels beginnend met 'II' gevolgd door tekst zijn de commentaar regels, deze worden door de compiler overgeslagen. Het bovenstaande geeft weer dat een datum object geconstrueerd wordt door het invoeren van de dag, de maand en het jaar. De datum kan dan vervolgens op het scherm worden afgedrukt met behulp van de 'drukaf functie. De data is 'private' opgeslagen in het object zelf. Hier volgen de gedeclareerde 'member' functies van de class: 7/ Constructor Datum: :Datum(int dg, int md, int jr) dag = dg; maand = md; jaar = jr;

/7 Member voor het afdrukken van de datum void Datum: : drukaf () cout « dag « '-' « maand « '-' « jaar;

7/ Afdrukken in de vorm 1 99-99-1999'

7/ Destructor Datum: :-Datum() 7/ doe niets

De opzet van de 'drukaf functie is vergelijkbaar met hoe dat in C gebeurde. De constructor en destructor zijn echter nieuw. Dit zijn de functies die zorgen voor het creëren en opruimen van het object. Met de constructor worden over het algemeen de belangrijke interne variabelen van het object ingesteld. De destructor zorgt voor het netjes opruimen van het object.



15

Stageverslag


Aanpak

En nu volgt de laatste stap. Het gebruik van het data type. Dit gaat als volgt: II Programma dat het gebruik van de Datum class demonstreert void main() Datum rnijnDatum(12,9,1971) Datum jouwDatum(5,5,1945);

declareren van een datum declareren van nog een datum

mijnDatum.drukaf () cout « jouwDatum.drukaf () cout «

Het resultaat na compileren en executie is dan: 12 9 1971 5-5-1945

Het voordeel van deze manier van programmeren is dat je niet langer gegevens die ergens staan opgeslagen naar een speciale functie moet sturen die het afdrukken verzorgd. In 0 zou een zelfde operatie er als volgt uit gezien hebben: II datum afdrukken in C display date (&myDate) display date (&yourDate)

Het belangrijkste voordeel van een object georiënteerde taal is dat dit soort operaties op de eigen data door de objecten zelf worden afgehandeld. Dit zorgt ervoor dat er veilig en overzichtelijk kan worden geprogrammeerd. Class Onderdelen

Zoals uit het bovenstaande duidelijk is geworden bestaat een classdefinitie uit het definiëren van twee dingen, de operaties en de data. De zichtbaarheid' (scope) van deze onderdelen is afhankelijk van het gebruik van de keywords private en public. Onderdelen die public gedeclareerd zijn, zijn zichtbaar voor de wereld buiten het object. De private onderdelen kunnen slechts gebruikt worden binnen het object zelf. Het raadplegen van de dag, maand en jaar variabelen mag dus alleen binnen een Datum object. Statements als hieronder zijn dus niet toegestaan. i = minDatum.rnaand; /1 Fout: kan prive onderdeel niet lezen mijnDatum.dag = 1; 1/ Fout: kan prive onderdeel niet veranderen

Het gebruik van private stelt de programmeur in staat information hiding' toe te passen. Hierbij wordt belangrijke data en operaties aan de blik van de argeloze gebruiker onttrokken, zodat die niet afgeleid wordt door zaken die niet van belang zijn. De communicatie met de privé operaties en data moet nu verlopen via die operaties die public zijn. Dit worden ook wel het interface' genoemd. Met deze operaties kan je de data uitlezen of aanpassen. In het volgende voorbeeld zijn dit de functies Haaldag en SchrijfDag:



16

Stageverslag


// Datum class #include

Aanpak

// functie library voor in- en uitvoer

class Datum public: Datum(int dg, int md, int jr) void drukafO;

Constructor Functie voor het afdrukken van de datum

Functie voor het raadplegen van de dag Functie voor het veranderen van de dag

int HaalDag() void SchrijfDag(int dg)

Destructor

-Datum() private: int dag, maand, jaar;

prive data

2.4.2.2. Microsoft Foundation Classes De Microsoft Foundation Class Library (MFC) helpt de C++ programmeur bij het maken van applicaties voor Microsoft Windows. De class library geeft een compleet applicatie raamwerk, waaruit alle onderdelen die in Windows gebruikelijk zijn, kan raadplegen. Het gebruik van de MFC stoelt op het principe van erfelijkheid. In object-georiënteerde talen kan je gebruik maken van de mogelijkheid classes te maken die eigenschappen hebben van een opperclass. Dit heet in C++, derived'. Bij het ontwikkelen van een eigen applicatie met behulp van MFC doe je dit voor ieder onderdeel in je applicatie, dat iets te maken heeft met Windows. Dit is bijvoorbeeld een venster, gedeclareerd met behulp van MFC: class Venster : public CFrameWnd public: Venster ()

// Venster derived van CFrameWnd class

Create(MULL, "Groetjes!")

// constructor

// Maakt een venster met de naam 'Groetjes!'

Het CFrameWnd class heeft de beschikking over een aantal operaties die zich bezighouden met het beheren van een venster. In het voorbeeld is er slechts een van gebruikt, de 'Create' functie maakt een venster aan van een bepaalde standaard grootte met de naam "Groetjes!" in de titelbalk. Andere operaties reageren bijvoorbeeld op het verkleinen of het sluiten van het venster. Zo heeft iedere class uit de MFC haar eigen operaties en gegevens, die soms ook uit weer hogere classes worden geraadpleegd. De Microsoft Foundation Classes zijn verdeeld in de volgende categorieën: • Basis

Dit is de basis class 'CObject' waaruit alle andere classen binnen MFC zijn ontwikkeld. Dit type class heeft een aantal veel voorkomende operaties die in iedere lagere class van pas kunnen komen. • Applicatie architectuur

Deze zijn handig bij het aanmaken van de applicatie zelf, of onderdelen als document en views. • Visual object

Belangrijkste onderdelen hiervan zijn de vensters, dialogen, menu's, device contexts en teken objecten. • Algemene handelingen

Objecten die ervoor zorgen dat, bestanden, diagnose, uitzonderingen en data verzamelingen worden afgehandeld.



17

Stageverslag


Aanpak

• Object Linking and Embedding (OLE) Classes waarmee applicaties OLE compatible kunnen worden gemaakt, zodat ze objecten uit andere Window applicaties kunnen gebruiken. • Macros en globaal Data types, messagebox vensters, applicatie in formatie. Al deze soorten classes kunnen worden gebruikt om eigen onderdelen optimaal samen te laten werken met de Windows omgeving. Een onderdeel uit de programmeer omgeving van Visual C++ dat nauw samenwerkt met MFC is de ClassWizard. Dit programma maakt in een mum van tijd het skelet voor een applicatie aan de hand van de onderdelen die programmeur definieert in de Application Studio. Classes die door dit programma automatisch worden geprogrammeerd baseert hij op classes uit de MFC. Het enige wat de programmeur nog hoeft te doen is zijn eigen operaties en gegevens aan het geheel toe te voegen. Motivatie Hoewel het bovenstaande klinkt als een enorme tijdbesparing, zit er nog een klein addertje onder het gras. MFC is toegespitst op het maken van applicaties die werken met documenten. Niet onterecht, want het leeuwendeel van applicaties voor Windows heeft wel een bepaalde document-vorm in zich. Helaas geldt dit niet voor deze opdracht. De ClassWizard en vele handige mogelijkheden uit MFC gingen dus aan de realisatie van deze opdracht voorbij. Toch zijn de MFC een handige aanvulling op de standaard C++ omgeving en libraries die zich directer op Windows richten. Meer over de opzet van Windows in de volgende subparagraaf.

2.4.3. Windows Windows is een werkomIing speciaal toegespitst op de interactie met gebruikers. Als een gebruiker iets doet met zijn muis, op een knop drukt dan reageert Windows hierop. Hoe gebeurt dat? Windows kent een principe dat heet message handling'. Voor iedere handeling die de gebruiker verricht wordt door Windows aan de desbetreffende applicaties een bericht gestuurd waarop ze kunnen reageren. Door Windows wordt voortdurend een routine doorlopen, die controleert of er een verandering is in de situatie. Deze routine heet de message-loop'. Wat deze routine ook bij houdt is of de gebruiker een bepaald commando uitkiest in een applicatie. Dit kan de gebruiker door middel van het indrukken van een 'button', het kiezen van een item' uit een menu of door het invoeren van een toetsencombinatie. Een applicatie die berichten wil kunnen afhandelen moet dit doen aan de hand van een message map'. Dit is een macro die de compiler de sourcecode laat invoegen voor het afhandelen van bepaalde soorten berichten. Dit moet door zowel in de definitie als de declaratie van een object in de applicatie een message map aan te maken. Hier volgt een voorbeeld van een venster die reageert op de 'ON_CLOSE' message.



18

Simuatie Diepstekende Schepen

Stageverslag

Aanpak

// De definitie class CPresentatie public CMDIChildWnd //{{AFXMSG(CPresentatie) 7/ Definitie van de message map afxmsg void OnClose() 7/ Definitie van de afhandelende functie /7} }AFXMSG DECLAREMESSAGEMAP() 7/ Macro voor declareren van message map

7/ De declaratie

BEGIN MESSAGE MAP(CPresentatie, CMDIChildWnd)// Declaratie message handlers in Windows /7 { { AFX MSG MAP (CPresentatie) DNWMCLDSE() // Roept DnClose() aan. }AFX MSG MAP END MESSAGE MAP () void CPresentatie: :DnClose()

this- >ShowWindow (SWMINIMIZE);

/7 Declaratie van de afhandelende functie

7/ Zorgt ervoor dat het huidige window /7 een icoon op het beeld wordt

Deze constructie zorgt ervoor dat het window dat wordt dichtgeklikt door de gebruiker niet verdwijnt zoals normaal, maar wordt verkleind tot icoon in de hoek van het scherm. Naast deze berichten die directe handelingen van de gebruiker omzet in acties. Is het ook mogelijk de User Interface bij te werken na een verandering in het programma. Dit gebeurt met behulp van de 'ON_UPDATECOMMAND_UI' macro. Als een bepaalde verandering heeft plaatsgevonden, dan wordt een functie aangeroepen die bijvoorbeeld een knopje actief of inactief maakt. Voor bijna iedere class in de MFC zijn er verschillende message afhandelingsfuncties die door de programmeur naar eigen inzicht kunnen worden gebruikt. Dit maakt het makkelijk om een applicatie te maken die reageert op bepaalde gedragingen van de gebruiker.



19

Stageversiag

Si mulatie Diepstekende Schepen

Implementatie

3. ONTWERP In dit hoofdstuk wordt ingegaan op de activiteiten, problemen en keuzes die kwamen kijken bij het ontwerpen van het simulatie model. Van ieder onderdeel geef ik weer wat er fout was in het origineel en hoe dit veranderd is. Van problemen die hierbij zijn ontstaan geef ik aan wat en hoe ik die heb opgelost. Als laatste probeer mijn werk te evalueren en te vergelijken met produkten die later zijn gerealiseerd. Het is verstandig om bij het doornemen van dit hoofdstuk het origineel van Peter-Paul en het vernieuwde ontwerp erbij te nemen. Maar om het zonder deze twee stukken leesbaar te maken, zullen wijzigingen waar mogelijk aan de hand van illustraties en voorbeelden worden verheldert.

3.1. FUNCTIONEEL DETAILONTWERP Van dit onderdeel is het de bedoeling dat functionaliteiten uit de systeemeisen zoals die zijn vastgelegd, verder worden uitgediept. Het functioneel detailontwerp van Peter-Paul is gebaseerd op zijn 'rapport definitiestudie/basisontwerp'. Dat onderdeel heb ik zonder wijzigingen overgenomen, omdat het een goed overzicht is van de eisen. Het verslag was in z'n geheel consistent met de eisen die ik voor mezelf heb vastgesteld na gesprekken met Frits Draisma. Aan het functioneel detailontwerp schortte echter nog het een en ander. Hier en daar werd een wijziging gedaan op verzoek van Frits Draisma.

3.1.1. Functionele Eisen In de paragraaf Te simuleren bewegingen wilde Peter-Paul ook rekening houden met de verandering van de zeebodem als gevolg van de verplaatsing van het schip. Dit is een zeer complex en moeilijk nabootsbaar onderdeel. Besloten werd hiervan af te zien. Bovendien werd met nadruk gesteld dat ook stroming een factor is die bij het probleem komt kijken, maar te complex is om op te nemen. Het getij werd in het originele verslag maar zeer beperkt beschreven. Na een gesprek met Frits Draisma begon ik me pas te realiseren hoe ingewikkeld dit onderdeel eigenlijk is. Het getij is immers veranderlijk en beweegt met een verschillende snelheid dan de verplaatsing van het schip. Ter illustratie: Een schip dat vlak voor vloed bij het Europlatform vandaan vaart, zal onderweg het hoogtepunt van de vloed onder zich door krijgen. De waterstand op het punt van het schip is dus afhankelijk van de snelheid van het getij, de snelheid van het schip, de positie en de richting waarin het schip vaart. Aangezien we van maar twee punten (Hoek van Holland en het Europlatform) ten alle tijde de waarden weten, moet er worden geïnterpoleerd. Nagegaan moet worden hierbij een waterstandsmodel te implementeren. In de Te presenteren aspecten zijn een aantal eisen aangepast die ik niet zinvol achtte. Peter-Paul wilde in zowel de topografische als traject presentatie een 'zoom' mogelijkheid opnemen. Omdat in beide presentaties goed is te zien waar het schip zich bevindt en hoe de situatie daar is, heb ik in overleg met Frits besloten deze functionaliteit te schrappen. Hiernaast heb ik de numerieke presentatie uitgebreid met gegevens omtrent de vaartijd, de afstand en de richting. Gegevens die Peter-Paul over het hoofd heeft gezien. Het aantal Simulatieparameters is ingekort. Dit komt door de wijzigingen in de gebruikersinterface. Om het programma zo simpel en gebruikersvriendelijk mogelijk te maken heb ik besloten om keuze opties als het uit en aan zetten van de afzonderlijke scheepsbewegingen te verwijderen. Bovendien is de externe interface met het meetnet vervangen door communicatie met de database DB-HMR, waardoor een aanzienlijke hoeveelheid communicatie parameters wegvalt.

3.1.2. Systeembeschrijving Hierin wordt beschreven welke functionaliteiten het systeem bevat. Dit gebeurt met behulp van de Data Flow Diagram (DFD) teken techniek. Een belangrijke verandering in de eisen van het pakket was dat de communicatie met het meetnet via MKS (Meetnet Koppel Systeem) vervangen werd door de nieuwe database. Hierin staan alle



20

Stageverslag


Implementatie

geregistreerde en voorspelde watergegevens opgeslagen. De communicatie met deze database kan gewoon via een device over het netwerk. Het ingewikkelde protocol (SMP) zoals dat gebruikt werd voor MKS, is niet meer nodig. Dit heeft ervoor gezorgt dat de buitenwereld MKS in het contextdiagram nu vervangen is door DB-HMR. Dit is te zien in het onderstaande figuur.

DB-HMR water

diepte -tabellen

raag simulatie water data model aR / presentatie

t aanvraag gegevens invoer

( gebruiker

Figuur 6 Contextdiagram simulatie model

Ondanks deze verandering is er in de functiestructuur van het simulatiepakket op zich weinig veranderd. Het was daarom niet zinvol om dit onderdeel nog eens uit te diepen. De enige wijzigingen is wederom de communicatie met DB-HMR.

3.1.3. Gebruikersinterface Dit onderdeel is aanzienlijk aangepast. Maar dit kon pas gerealiseerd worden nadat ik me verdiept had in Visual C++ en met behulp daarvan een nieuw prototype kon bouwen. Het originele prototype van Peter-Paul ziet er als volgt uit.

venster

Bestand Schip Simulatie Opties Start

Ucip

L!J

Lengteproticl vaargeul Bovenaanzicht vaargeul Vooraanzicht schip Zijaanzicht schip

Numerieke presentatie

Figuur 7 Prototype van Peter-Paul



21

Stageverslag

Si mulatie Diepstekende Schepen

Implementatie

Mijn prototype is daarop gebaseerd, maar heeft op een flink aantal onderdelen een facelift gekregen. Zoals bijvoorbeeld de knoppenbalk en de statusregel. Het onderstaande figuur is mijn versie van het prototype.

Figuur 8 Mijn Prototype

Op de facelift na is de belangrijkste verandering het pull-down menu geweest. Peter-Paul had de gebruiker een hoop keuze opties gegeven. Ik heb de opties geschrapt of naar de invoervensters verplaatst. Hierdoor werd het programma overzichtelijker en makkelijker te gebruiken. Hoewel het niet altijd wijs is de gebruiker te beperken, is het in dit geval essentieel. De enige iriteractie die de gebruiker met het systeem heeft gebeurt via de invoervensters en de actiekeuzes. Wat rest zijn de vensters, die de gebruiker kan openen, sluiten, verplaatsen of van grootte veranderen. Ik heb besloten me niet teveel vast te leggen wat betreft de gebruikersinterface. Hoewel het prototype een goede richtlijn is om de toekomstige gebruiker na te laten denken over het systeem. Peter-Paul heeft de interface en de windowsomgeving gedetailleerd beschreven. Als ik dit opnieuw zou hebben gedaan, zou dit veel tijd hebben gekost, maar niet meer resultaat hebben opgeleverd.

3.1.4. Overige Externe Interfaces Zoals in de bovenstaande subparagrafen al duidelijk is geworden, de externe interface MKS is vervangen door communicatie met de DB-HMR. Dit gebeurt aan de hand van een in FORTRAN geprogrammeerde functie, geti'. Deze geeft over een bepaalde tijdreeks de gemeten waarden zoals die zijn opgeslagen in de database. Het uitlezen van de lodingsbestanden is onveranderd gebleven. Deze worden door de afdeling verantwoordelijk voor de bodemmetingen beschikbaar gesteld en door het programma uitgelezen tijdens de simulatie.

3.1.5. Wiskundige Functionaliteiten Dit is een onderdeel dat in de verslaggeving door Peter-Paul maar heel summier aan de orde is gekomen. Dat is jammer, want dit is nu juist een belangrijk punt voor het bepalen van de risico's. Het schip verplaatst zich door de vaargeul en wordt door de laag frequente golven (golven met een frequentie groter dan 10 seconden) in beweging gezet. Dit zorgt ervoor dat delen van het schip lager komen te liggen in het water, waardoor de kans op bodem beroering toe neemt. De lang frequente golven zorgen ervoor dat het schip drie soorten beweging maakt: 1. Slingeren

Dit is de beweging van het schip om zijn lengte as. Dit zorgt ervoor dat de zijkanten lager komen te



22

Stageverslag


Implementatic

liggen. Stampen

Dit is een beweging om de breedte as van de schip. Hierdoor komen de voorkant of de achterkant lager te liggen Dompen

Hierdoor komt het schip in een verticale beweging, waardoor het in zijn geheel dieper (of ondieper) komt te liggen. Deze bewegingen zijn afhankelijk van een aantal factoren: • • • •

Energie van de langfrequente golven Richting van de golven Snelheid van het schip Lading van het schip

Al deze bewegingen zijn in het model na te bootsen als we gebruik maken van zogenaamde 'overdrachtsfuncties'. Dit zijn de wiskundige representaties van het golvenspectrum die het schip in beweging zetten. Binnen de Rijkswaterstaat, maar vooral via de heer Henk Keyser zijn onderzoekresultaten beschikbaar waaruit deze functies zijn op te stellen. Dit moet echter gebeuren met een grondig functie-onderzoek. Henk Keyser heeft mij in een middag de principes achter deze overdrachtsfuncties duidelijk gemaakt.

De bedoeling was dat ik me later misschien nog een week in de stof zou verdiepen. Dat is er echter niet meer van gekomen en zodoende zijn geen van deze functionaliteiten vastgelegd.

Ik heb echter wel al vroeg een besluit genomen. De wiskundige stof achter dit probleem is dusdanig ingewikkeld dat je het risico loopt het doel voorbij te schieten. Het doel van het model is een vereenvoudigde weergave te geven van een vaart van een tijgebonden schip. Met als oogpunt het verschil tussen kiel en bodem. Daarbij moet wel rekening worden gehouden met de factor beweging. Maar aangezien beweging in een simulatie toch zal verschillen van de werkelijkheid, is het misschien zinvol om te denken over een eenvoudigde beweging op basis van een aantal sinuscurves. Het belangrijkste is dat de gebruiker een mooie weergave op het scherm gepresenteerd krijgt. Dit kan ook wanneer slechts eenvoudige bewegingsformules worden gebruikt. Op basis van dit besluit ben ik me verder gaan concentreren op de simulatie zonder beweging. Deze functionaliteit heeft wel prioriteit, maar is makkelijker in te bouwen nadat het schip een simulatie bij 'stil weer' kan doorstaan.

3.1.6. Resultaat Het 'vernieuwd rapport functioneel detailontwerp' (bijlage 1) was bedoeld als addendum en erratum bij het origineel van Peter-Paul. Deze twee verslagen vormen de basis voor het technisch detailontwerp en de implementatie. De consistentie van deze verslagen is over de hele linie gelijk gebleven. De enige verschillen zitten in de gebruikersinterface. Omdat ik me op dat gebied niet vanaf het begin heb vastgepint heb ik de gebruikersinterface tot aan het einde van de implementatie steeds aangepast. Af en toe op verzoek van Frits Draisma, maar meestal op eigen initiatief. Dit met het doel het programma zo goed mogelijk te laten ogen, zodat de gebruiker er plezierig mee kan werken. Ook heb ik hier en daar consessies moeten doen wat betreft de interface, maar meer daarover in het hoofdstuk 'Implementatie'.

3.2. TEST SPECIFICATIES Door SDM wordt voorgeschreven dit onderdeel op te stellen tijdens de ontwerpfase. De bedoeling is dat voor iedere mogelijke invoer wordt vastgelegd wat de verwachte uitvoer is, zodat na voltooiing van het project het geheel aan de hand van deze tests kan worden getoetst. Doordat de menustructuur en een aantal variabelen compleet veranderd zijn, klopt er van de oorspronkelijke Test specificaties niet veel meer.



23

Stageverslag


hpIernentatie

Mijn bedoeling was in eerste instantie een nieuwe test specificatie op te stellen. Maar naar mate ik verder vorderde met het ontwerp begon ik me te realiseren dat het opstellen van een testspecificatie voor een eenmansproject niet effectief is. Een testspecificatie komt vooral van pas in projecten met meerdere personen, hierdoor kunnen de verschillende onderdelen van het programma, tijdens de ontwikkeling worden getoetst of ze voldoen aan de voorafgestelde eisen. Zonder dat degene die de onderdelen bij elkaar brengt zich druk hoeft te maken over de wijze waarop het onderdeel is geprogrammeerd. Bij een eenmansproject heb ik echter gemerkt dat de programmeur voldoende overzicht heeft over het project om tijdens de implementatie zijn programma af te stellen tot aan de specificatie is voldaan. Bovendien is een van de voordelen van een object georiënteerde programmeeromgeving dat de programmeur gedwongen wordt netjes te programmeren. Onverwachte uitkomsten zijn daardoor tot een minimum beperkt. Daarom heb ik besloten om van het opstellen van de testspecificaties af te zien en juist meer tijd te steken in het technisch detailontwerp en de implementatie.

33. TECHNISCH DETAILONTWERP In dit onderdeel is het de bedoeling dat de technische kant van de functionaliteiten verder wordt uitgediept. Wat moet worden beschreven is wat het programma doet, maar niet hoe dit wordt uitgevoerd in de programmeertaal. Dit technisch detailontwerp is gebaseerd op het functioneel detailontwerp. Aangezien een paar dingen in het functioneel detailontwerp zijn veranderd, klopt veel in het technisch detailontwerp ook niet meer. Daarnaast was ik het niet altijd eens met de wijze waarop Peter-Paul de onderdelen heeft ontworpen.

3.3.1. OMT Dit was de eerste keer dat ik in aanraking ben gekomen met een object georiënteerde ontwerptechniek. Het was dus zaak eerst het boek Object-Oriented Modeling and Design" grondig door te nemen, voordat ik kon beginnen met de evaluatie van het originele verslag. Het onder de knie krijgen van de object georiënteerde ontwerp-techniek kostte nogal wat tijd. Dit kwam niet zozeer omdat OMT zo'n moeilijke ontwerp-methode is, maar vooral omdat niemand anders bij de directie Noordzee ervaring heeft met OMT. Dit had tot gevolg dat ik alleen mijn eigen interpretatie kon gebruiken voor de toetsing en wijziging van het origineel. En hoewel ik vermoed dat mijn interpretatie juist is, ben ik over het hele verslag gezien niet altijd zeker van mijn zaak. In ieder geval blijkt uit het resultaat van de implementatie dat ik met mijn ideeën er niet ver naast zat. Maar laat ik niet op de zaken vooruit lopen.

3.3.2. Object model In dit model wordt een beschrijving gegeven van de statische data structuur bestaande uit de objecten en de relaties daartussen. Dit gebeurt door aan de hand van de eisen de objecten te definiëren en vervolgens deze tot elkaar te relateren. Origineel Ik ben begonnen met het doornemen van Peter-Paul's origineel. Hij kwam tot de volgende objecten (en attributen): • Golf (energie, richting en spectrum) • Water (meteo-afwijking) • Vaargeul (gebied te gaan, mode waterstand, mode MKS, sensor MKS) • MKS-Server (username, password, communicatie, poort, baudrate) • MKS-Buffer (lijst data, vroegste tijdstip, laatste tijdstip) • Bodem (matrix, bodemligging)



24

Stageverslag

Simu!atie Diepstekende Schepen

Implementatie

• XYZ-interface • Simulatie klok (simulatie snelheid, simulatie tijdstip) • Model • Polygoon (coördinaten, rotatie, kleur, vulpatroon, vulkleur) • Bitmap (matrix waterstand, kleuren diepten) • Schip (scheepsnaam, lengte/diepte, breedte, draagvermogen, lading) • Simulatie schip (vaarsnelheid, plaats, mode slinger, stampen, dompen, squat) • Presentatie • Zoompresentatie • Scheepsdatabase • Overdrachtsfunctie (functieparameters) • Overdrachts server (overdrachtsfuncties van schepen) • Logfile Al deze objecten waren samengebracht tot een warrig netwerk van een op een, en een op meer relaties. Ik zal dit netwerk niet proberen te reproduceren, maar het valt te bekijken in Peter-Paul's eigen verslag. Er schort nogal wat aan deze representatie van het model. Op de eerste plaats zijn een aantal onderdelen compleet vervallen, zoals de objecten voor MKS en de 'zoom' optie. Bovendien lijken mij de objecten scheepsdatabase', 'XYZ-interface', 'overdrachtsfuncties' en 'logfile' niet juist, omdat deze allemaal op te nemen zijn als operaties voor beter gedefinieerde objecten. Daarbij heeft Peter-Paul niet goed weergegeven hoe de verschillende presentaties worden verzorgd. Toen ik me realiseerde dat er zoveel mis was heb ik Peter-Paul's technisch detailontwerp grotendeels verworpen. Nieuw Op basis van de opnieuw opgestelde eisen kwam ik tot de volgende objecten: • Beweging

Verantwoordelijk voor het bijhouden van de stand van het schip met behulp van de bewegingscomponenten stampen, dompen en slingeren. • Bodem

Hierin wordt de bodem van de omgeving bepaald door het uitlezen van de lodingsbestanden. • Dompen

Beweging verantwoordelijk voor de verticale verplaatsing. • Grafisch geul

Verantwoordelijk voor de grafische presentatie van de geul, zowel de trajectpresentatie als de topografie. • Grafisch schip

Neemt de grafische presentatie van het schip voor z'n rekening, zowel het vooraanzicht als het zijaanzicht. • Model

Het programma, hierin worden alle objecten bij elkaar gehouden, zodat ze met elkaar kunnen communiceren. • Omgeving

Houdt bij hoe de omgeving rond het schip eruit ziet. Zo wordt op de positie van het schip, de waterstand en het pro fiel van de bodem bepaald. • Presentatie

Object verantwoordelijk voor de presentatievensters.



25

Stageverslag


Implementatie

• Schip

Het object waar het in de simulatie om draait. • Simulatie

Bevat de startwaarden van de simulatie. Simulatieklok

Verzorgt het verstrijken van de tijd in de simulatie. • Slingeren

De bewegingscomponent om de lengteas. • Stampen

Bewegingscomponent om de breedte-as. • Statistiek

Vergaart alle gegevens omtrent de vaart en presenteert deze. • Vaargeul

Bevat de streefdiepten en topografie van de twee vaarge uien en kan deze presenteren. • Water

Haalt de tijdreeksen met waterniveaus en berekent de waterstand rond het schip. Dit geeft na de relaties uitgewerkt te hebben, het volgende diagram:

Figuur 9 Object model diagram van het model

Een belangrijk probleem dat kwam bij het opstellen van dit Object Model was het opnemen van de invulvensters. Dat zijn onderdelen die pas goed naar voren kwamen bij het maken van het prototype. De invulvensters horen eigenlijk teveel bij de implementatie en de techniek zegt uitdrukkelijk dat tijdens het ontwerp geen rekening mag worden gehouden met de implementatie. Daarom heb ik deze objecten in het achterhoofd gehouden, maar ik wil ze in dit verslag toch even op een rijtje zetten. • Invulvenster scheepsgegevens

Verzorgt de interactie met de gebruiker wat betreft de scheepsgegevens. Dit venster fungeert tevens als het beheer van de database.



Kei

Stageverstag


Implementatie

Invulvenster watergegevens

Hierin kan de gebruiker water gegevens over de go/ven en opwaaiing invullen of ophalen uit DBHMR. • Invulvenster simulatiegegevens

Hierin wordt vastgesteld op welk tijdstip het schip in de geul binnenkomt. Met welke snelheid er wordt gesimuleerd. En in welke geul er gevaren wordt. Als deze vensters in het diagram opgenomen zouden worden dan zouden ze vlak onder het model object staan. Daarbij zouden de scheepsgegevens een relatie hebben met schip, watergegevens met water en simulatiegegevens met simulatie. Het bovenstaande is het resultaat van een herhalend proces van steeds opnieuw en opnieuw ontwerpen, relaties en objecten bijstellen. In hoeverre dit model juist is, is niet helemaal duidelijk, omdat er in mijn werkomgeving niemand is die verstand heeft van OMT. De enige toetsing is de implementatie, maar meer daarover in het volgende hoofdstuk.

3.3.3. Dynamic model Hierin wordt het gedrag van het systeem en de objecten daarin beschreven ten opzichte van de tijd. Het model is in twee onderdelen verdeelt het 'Global Event Flow Diagram' en het 'State diagram'. Global Event Flow Diagram Het boek geeft aan dat voor het opstellen van dit model er eerst een event-trace gemaakt moet worden. Toen ik de event-traces van Peter-Paul bekeek, zag ik pas hoe onduidelijk deze methode eigenlijk is. Bovendien kost deze methode onwaarschijnlijk veel tekenwerk, omdat er voor iedere actie een pijl moet worden getekend tussen het object dat de actie uitvoert en het object dat de actie ontvangt. Ik heb toen besloten om volgens een andere aanpak te werk te gaan. Wat je met een event-trace doet is het toekomstige programma in gedachten laten werken en precies nagaan wat het programma in de tijd doet. Kortom, dit kan ook door voor ieder object uit het model in gedachten alle acties en stadia door te nemen. Wat je dan krijgt is het volgende: simulatieklok: zet simulatie begin tijd zet simulatiesnelheid bereken nieuwe tijd vraag simulatietijd start beweging: zet golfgegevens haal goifgegegevens bereken nieuwe stand presentatie: cyclus update venster open venster statistiek: bepaal bepaal bepaal bepaal

vaartijd gevaren afstand vaartijd te gaan minimale kielspeling

Van ieder object tientallen mogelijke acties. Een Global Event Flow Diagram is op te stellen door deze acties onder te verdelen. Er zijn namelijk teveel acties en objecten om samen te brengen in een groot diagram. Het model kan zich eigenlijk maar in vier verschillende stadia bevinden: 1. Opstarten

Waarin de belangnjkste objecten worden aangemaakt en gevuld met beginwaarden.



27

Stageverslag


Implementatie

Invullen

Waarbij de gebruiker de waarden in vult. Waarna vervolgens de respectievelijke objecten - water, schip, simulatie - worden gevuld. Simuleren

Het belangrijkste stadium waarbij het schip door de geul wordt gevaren gebruik makende van bijna alle objecten. Presenteren

Dit is niet zozeer een ander stadium, want dit gebeurt tijdens het 'simuleren', maar er gebeuren hier andere activiteiten. En het was overzichtelijker om ze apart te plaatsen. Hieronder het Global Event Flow Diagram van 'Opstarten'.

- vraagt of gebruiker zeker is - kiest 'schip' uit het menu - scherm en windows worden gesloten - kiest 'simulatie' uit het menu - kiest 'water' uit het menu a2: - klok wordt geinitialiseerd en op de computertijd gezet - start de simulatie - pauzeert de sirnulatie a3: - simulatie object wordt - stopt de simulatie - sluit, opent of verandert de gedeclareerd windows a4: - presentatiewindows worden geopend - sluit programma af

+al: - start het model

-al: - programma opent scherm met knopjes a5: - schip object wordt gedeclareerd en

gevuld met het eerste schip uit de - een dialoogwindow voor scheepsgegevens wordt geopend lijst - een dialoogwindow voor simulatiegegevens wordt geopend a6: - beweging object wordt gedeclareerd - een dialoogwindow voor watergegevens wordt geopend a7: - omgeving object wordt gedeclareerd - programma presenteert de simulatie in de geopende windows a8: - statistiek object wordt gedeclareerd - veranderde windows worden bij gewerkt Figuur 10 Global Event Flow Diagram

Zoals te zien is het 'opstarten' stadium al een wirwar van activiteit. Het diagram verdient wat toelichting. Gebruiker is vanzelfsprekend geen object, maar het is wel die persoon die het model aanstuurt en feedback ontvangt van het model. Ik heb toen maar besloten om de gebruiker als een



28

Stageverslag

--


--

Implementatie

soort object op te nemen. Een ander probleem is dat activiteiten binnen objecten niet in dit schema worden opgenomen, maar meer hierover later. State Diagram Dit is het diagram waarin de meest dynamische onderdelen uit het systeem worden gemodelleerd. Er zijn veel stadia binnen een systeem die zo elementair zijn dat ze niet behoeven gemodelleerd te worden, maar een aantal zijn zo complex dat het beter is ze te visualiseren. Een probleem waar ik bij dit onderdeel tegenaan liep was dat in OMT niet duidelijk beschreven staat welke activiteiten je hiermee wel moet modelleren. En hoe ver je moet gaan. Bovendien had ik een tekort aan goede voorbeelden waarin duidelijk te zien is hoe de tekentechniek toe te passen. Het enige waar ik enigszins van overtuigd was dat Peter-Paul's State Diagrammen onjuist waren, omdat hij alleen een aantal acties op het allerlaagste niveau heeft beschreven, zoals het lezen van namen uit een bestand. Hieronder staan drie State Diagrammen van een van de meest dynamische onderdelen in het systeem, de activiteiten binnen het Model Object: initializeer p,og,eoma

open sche,m

nO smoIa0ekIok

toeo,ng

h,p

specificatie simulatie

00 oecoet

'°

00

(00 n,t

dg

00

.

'\nSm0Iate

Figuur 11 State Diagram van Model'

Conclusie Toen ik de vier Global Event Flow Diagrammen en de State Diagrammen tekende ontdekte ik dat een soort activiteit niet altijd zichtbaar wordt in het model. En dat zijn de activiteiten die in objecten zelf worden uitgevoerd. Een deel zou naar voren moeten komen in het Functional Model, maar daar wordt ieder object weer onderverdeelt in hele elementaire onderdeeltjes. Dat kost veel tijd. Vanaf dat moment ben ik gaan twijfelen over de effectiviteit van deze ontwerp techniek. Net als voor SDM lijkt me dit een methode die buiten gewoon goed van pas kan komen bij het maken van een groot informatie systeem met een team van programmeurs. In een eenmansproject is het volledig uitvoeren van deze methode zeer tijdrovend. Aangeland in week negen van de stageperiode besloot ik zo snel mogelijk over te gaan op de implementatie, om zeker te zijn dat in ieder geval een deel van de opdracht voltooid zou worden.


Rijswijk, 31 januari 1995 29

Stageverslag


Implernentatie

3.3.4. Functional model Het functioneel model is ervoor de datastromen binnen het systeem zichtbaar te maken. Dit gebeurt met behulp van de Data Flow Diagram (DFD) tekentechniek. Voordat ik aan dit onderdeel begon had ik al het besluit genomen om me te gaan concentreren op de implementatie. Maar om een beter beeld te krijgen heb ik eerst een twintigtal schetsen gemaakt van de belangrijkste stromen binnen het systeem. Deze zijn echter niet opgenomen in het verslag. Ik overweeg dit hoofdstuk toch op te nemen, om mijn programma makkelijk overdraagbaar te maken.

3.3.5. Resultaat Het vernieuw technische detailontwerp' (bijlage II) is niet helemaal af. Het verslag van Peter-Paul was onjuist en mijn verslag is niet compleet. Ik ben aan het programmeren geslagen zonder het Technisch Detailontwerp af te maken. Dit is een belangrijke keuze geweest die ik halverwege de stage heb gemaakt. Het bestuderen van Peter-Paul's werk, het doornemen van de literatuur en het aanleren van een programmeertaal heeft zoveel tijd gekost dat het voltooien van het project, net als bij Peter-Paul, in het gedrang dreigde te komen. Ik had in mijn hoofd een goed beeld van hoe het programma eruit moest gaan zien en ik merkte dat OMT mij over het algemeen meer in de weg zat dan hielp. Door OMT wordt je verplicht niet over de implementatie na te denken tot aan het allerlaatste moment. Dit geeft alleen niet het juiste effect bij een programmeertaal als Visual C++ in een omgeving als Windows. Want OMT houdt er geen rekening mee dat Windows werkt volgens het 'message-handling' principe, Ieder State-diagram zoals ik dat getekend heb, ziet er dus helemaal niet zo uit in het uiteindelijke programma. Het leek mij daarom wijzer om te concentreren op hoe het wel moet binnen Windows, dan de OMT ontwerpen met veel moeite proberen in te passen.



Stageverslag


Implementatje

4. IMPLEMENTATIE In dit hoofdstuk wordt een overzicht gegeven van produkten en activiteiten in de implementatie fase. Daarbij wordt van ieder globaal onderdeel behandeld hoe ze zijn geprogrammeerd, wat voor problemen er kwamen kijken en hoe deze problemen zijn opgelost. Er zal niet in teveel ingewikkelde details worden getreden. Maar een aantal problemen waren zo technisch het toch met een C++ voorbeeld moet worden geïllustreerd. Om deze voorbeelden goed te kunnen begrijpen wordt enige kennis van de programmeertaal C en object georiënteerd programmeren vereist. Maar met de introductie hierop in paragraaf 2.4. kan men ook een heel eind komen.

4.1. AANPAK Omdat het technisch detailontwerp niet is afgemaakt was er eigenlijk maar een aanpak mogelijk voor de implementatie. Top down, incrementeel, dat wil zeggen dat van het programma eerst de globale structuren worden geprogrammeerd, voordat er aan details wordt gewerkt. Dit heeft het voordeel dat alle latere onderdelen getest kunnen worden zonder dat daar aparte drivers' (programma's die het onderdeel aansturen voor een test) voor gemaakt hoeven worden. Hoewel het technisch detailontwerp niet is voltooid, is wel tot enig detail vastgelegd hoe de structuur van het toekomstige programma in elkaar steekt. Vooral het 'Object Model' kwam hierbij goed van pas. Aan de hand daarvan kwam ik tot de volgende planning.

in • • • • • •

in • • • • • • • in

november 11 dagen bouwen van een skelet van classes 1 declareren functies en interfaces 2 vastieggen interfaces 1 implementeren resources 3 vastleggen dialogen 2 scheepsdatabase afhandeling 2

december 17 dagen communicatie DB-HMR 1 inlezen lodingsgegevens 2 traject presentatie 4 schip presentatie 4 omgevingsbepaling 2 2 beweging samenbrengen en testen geheel 3

januari 10

dagen

overloop

Bij deze planning ben ik er niet van uit gegaan dat ik op ernstige problemen zou stuiten tijdens het programmeren. Het testen en debuggen gebeurde per onderdeel. En er werd alleen naar een volgend punt in de planning gegaan als het onderdeel juist functioneerde binnen het geheel.

4.2. ALGEMEEN In deze paragraaf ga ik in op de algemene activiteiten en problemen die daarbij zijn ontstaan. De compiler van Visual C++ wordt geleverd met een enorme stapel boeken, waarvan de referentie gidsen en programmeurs handleidingen het meest omvattend zijn. Dit zijn prima overzichten van alle



31

Stageverslag


Implementatie

objecten en classes binnen de programmeer taal en wat ze doen. Maar geen enkel boek geeft aan, hoe je ze moet toepassen. Hoe is een algemene applicatie opgebouwd? Hoe krijg je een venster op het beeld? Hoe zet je grafiek of tekst in de vensters? Gelukkig wordt deze compiler geleverd met een groot aantal voorbeeld applicaties. Deze waren zeer belangrijk bij de ontwikkeling van het programma. Ik heb veel ideeën uit die programma's overgenomen of doodgewoon gecopieerd. Om aan te geven welke routines in het programma die schijnbaar uit de lucht zijn komen vallen, geef ik een lijstje waarvan ik de meeste inspiratie heb opgedaan: Algemene applicatie structuur Dit was het eerste probleem waarop ik stuitte. Hoe zit een applicatie normaal in elkaar? Hoewel het mij al gelukt was om een werkend prototype te schrijven, was ik niet helemaal tevreden over de wijze waarop ik dat gedaan had. Ik heb toen besloten om met dezelfde resource bestanden (waarde grafische en tekstonderdelen in op geslagen staan) opnieuw te beginnen. 'Scribble', is het enige praktische voorbeeld dat in de boeken van Visual C++ staat. Het is een soort grafische tekstverwerker. Deze wordt als introductie op C++ in een mum van tijd gemaakt met behulp van de Application- en Class-Wizard, maar geeft ook goed aan hoe applicaties er over het algemeen uit zien. Vanuit dit programma heb ik de ruggegraat, de class die gebaseerd is op CWinApp en het basis venster, overgenomen en omgebouwd naar mijn eigen programma. Iconen in het venster Toen de basis er eenmaal lag wilde ik eerst de presentatievensters inbouwen in het geheel. In het boek 'Class Library Reference' staat beschreven waarmee je deze vensters in het basisvenster kan opnemen. En in eerste instantie lukte dat ook prima. Maar op een ding na, de verkleinde vensters hadden geen eigen iconen. Van alle voorbeeld applicaties bracht 'MDI' de meeste uitkomst. Dit is een wat uitgebreide variant op het 'Hello World' programma (over het algemeen het eerste programma dat iedere programmeur in een nieuwe taal maakt), waarin meerdere vensters worden geopend met ieder hun eigen icoon. Grafische presentatie Dit is een ander onderdeel waar 'MDI' uitkomst bood. Hoe zet je grafiek in een venster. Meer hierover in de paragraaf over presentatie. Gecontroleerde invoer In de dialogen met de gebruiker moest de invoer op juistheid gecontroleerd worden. In het programma 'CTRLTEST', ontdekte ik een onderdeel waarbij de gebruiker door het programma verplicht werd de juiste dingen in te voeren. Bijvoorbeeld in een invoerveld voor cijfers kunnen alléén numerieke tekens worden ingevoerd. Omdat C++ object georiënteerd werkt, was het een eenvoudige zaak het object verantwoordelijk voor deze controle over te zetten naar mijn eigen programma. Meer hierover in de volgende paragraaf. Splash en aboutbox Om de gebruiker te informeren over het programma, wilde ik een zogenaamd informatie venster aanbrengen waarin staat door wie en wanneer het programma is gemaakt. In het programma 'Superpad' zat zoiets, maar bovendien een zogenaamd 'splashwindow'. Dit is een venstertje dat tijdens het opstarten op het scherm verschijnt en na enige tijd, of na invoer van de gebruiker, verdwijnt. Dit soort venstertjes zie je in de meeste grote professionele programma's. Kortom, het simulatiemodel moest er ook een. Ook hierbij was het een kwestie van het object overzetten en een eigen nformatievenster maken.

4.3. GEBRUIKERS INTERFACE Het gebruikers interface kan in Visual C++ met behulp van de Application Studio worden ontworpen. Dit is een soort teken pakket, waarbij je van ieder dingetje dat je tekent vastlegt hoe je het aan kan



32

Stageverslag


Implementatie

roepen of raadplegen. Zo is het dus mogelijk om een aan/uit knopje te maken in een dialoogvenstertje en het object die dat dialoogvenster beheert kan dan zien of het knopje aan of uitgeschakeld is. De gebruikersinterface is een van de belangrijkste, maar vaak onderschatte onderdelen van het programma. Dit is namelijk het enige onderdeel waar de gebruiker ten alle tijden mee te maken heeft. Een programma kan dan nog zo goed werken, als het interface niet deugt, dan kan het zijn dat de gebruiker het programma liever niet gebruikt, of verkeerd gaat gebruiken. Ik heb daarom veel tijd gestoken in een zo logisch en vriendelijk mogelijke gebruikersinterface waarin weinig fout kan gaan. Ir de subparagrafen komen de verschillende onderdelen aan de orde, de afwegingen die erbij gemaakt zijn en hier en daar wat uitleg over de programma code achter de interface.

4.3.1. Menubalk De menubalk heb ik vrij minimaal gehouden. De hoofdopties zijn project, in vullen, actie, venster en ? (help). Op het moment dat je project uit kiest krijg je de mogelijkheid om het programma af te sluiten. Dit kan ook door het uitklikken van het basis venster. Invullen is het submenu waarin je kan kiezen welke van de drie invulvensters je wil raadplegen. Het Actie menu spreekt haast voor zich, als de simulatie nog niet gestart is dan kan men voor start kiezen, hierna is het niet meer mogelijk om invul vensters te kiezen. In het Actie menu kan na de start wel worden gekozen voor pauze of stop. Met het venster menu kun je na opstarten de geopende venster opvragen of rangschikken. Het laatste menu ? is voor de hulp en de programma informatie.

4.3.2. Knoppenbalk De menubalk is een veel gebruikt hulpmiddel in Windows applicaties. Maar de afgelopen jaren zijn er meer en meer programma's verschenen met knoppenbalken. Een knoppenbalk is niet meer dan een grafische representatie van de menubalk, maar gebruikers kunnen er over het algemeen beter mee overweg. Voor dit programma ziet hij er als volgt uit:

Figuur 12 Knoppenbalk in het 'invul' stadium

Zo ziet de knoppenbalk eruit wanneer het programma zich in het invul' stadium bevindt. De keuzes zijn dan beperkt tot de knoppen voor de invulvensters, achtereenvolgend Schip, Simulatie en Water. De Start knop en de SDS informatie knop. Als de gebruiker nu op Start drukt of kiest uit het actie menu, veranderd de balk als volgt: 12345 --, S4U611 U

WMI î1ijjjI Figuur 13 Atwppenbulk in liet 'simulatie gestart' stadium

Het programma bevindt zich nu in het simulatie gestart' stadium. De knoppen voor de invulvensters zijn inactief geworden. De keuzes zijn nu veranderd in de knoppen pauze, stop, vooraanzicht schip, zijaanzicht schip, topografie, traject, numeriek, rangschikken en opnieuw SDS informatie. Zoals te zien is blijft de start knop ingedrukt. Wanneer de gebruiker nu voor pauze kiest, zal die ingedrukt blijven en er kan nu weer voor start gekozen worden. Het programma is dan in het 'simulatie gepauzeerd' stadium. Voor ieder van de vijf 'presentatie venster' knopjes geldt dat ze ook ingedrukt blijven als het venstertje geopend is. Het venstertje kan weer worden gesloten door opnieuw op het knopje te drukken. De 'truuk' achter het inactief en ingedrukt maken van de knopjes zit hem in het Windows principe van de 'UI_COMMAND .UPDATE' macro. Hiermee kan steeds worden gekeken in welk stadium het programma zich verkeerd, de desbetreffende onderdelen uit het gebruikers interface passen zich daaraan aan. Het tekenen van de plaatjes voor de knopjes ging eigenlijk vrij gemakkelijk, de meeste woorden en acties zijn wel om te vertalen naar een plaatje. Van de invulvensters 'Schip' en 'Simulatie' heb ik nog andere versies, maar deze leken mij het meest duidelijk. Het wijzende vingertje van Rangschikken is



33


Stageverslag

Implementatie

als laatste gekomen. Rangschikken is moeilijk naar iets visueels te vertalen. De motivatie achter het vingertje is het terug wijzen van vensters naar hun plek.

4.3.3. Invulvensters Deze zijn voor de dialoog die de gebruiker aan gaat met het programma. Hierin worden alle gegevens ingevoerd of veranderd. Deze dialoog vensters werden ook in z'n geheel worden in de Application Studio. Er zijn tientallen keuzes voor items die aan het venster kunnen worden toegevoegd. De gegevens uitwisseling tussen het invulvenster en de andere objecten kan op verschillende manieren verlopen. Een manier die door Visual C++ wordt geadviseerd is het doorsluizen van data met behulp van een data-map, vergelijkbaar met de message-map, maar dan voor gegevens. Een nadeel hierbij is dat de data invoer niet fout gevoelig kan worden gecontroleerd. En ik wilde juist een programma dat zogenaamd 'fool proof is, dus dat zelfs de meest onervaren gebruiker zonder al te veel moeite een simulatie op het scherm kan toveren. Een van de eisen daarvoor was dat de invoer velden gevoelig moesten zijn voor de invoer. Dit principe had ik bij alle invoervensters nodig, waaronder ook het scheepsgegevens venster:

Invulscherm scheepsgegevens

Scheepsnaam Esso Honolulu

- Lading _____

Dimensies Lengte 1200-5001 Breedte 140-801

[

i meter

[._J

meter

1

Draagvermogen 340 [204i9 Soort

Diepgang [1 9-241 201) meter

OlIe Q Bulk

J D] L1 d Figuur 14 Invulvenster voor scheepsgegevens

In het invoerveld voor lengte mogen bijvoorbeeld alleen getallen worden ingevoerd. Als de gebruiker andere toetsen gebruikt dan wordt er gepiept. Bij te hoge of te lage invoer zal een 'OK' keuze niet worden toegestaan. De oplossing voor invoer gevoeligheid vond ik in het programma 'CTRLTEST' tussen de voorbeeld programma's. De class CParsedEdit checkt tijdens de invoer wat er wordt ingevoerd en als het niet aan de eisen voldoet wordt er gepiept. Na invoer worden alle gegevens weggezet in de desbetreffende objecten, zodat ze gebruikt kunnen worden in de simulatie.

4.4. PRESENTATIE De presentatie van de simulatie heeft het meeste tijd gekost. Dit komt vooral omdat er vijf vensters worden gebruikt om de simulatie te presenteren. En ieder venster is anders. Bovendien is het gebruik van grafiek in vensters niet erg goed beschreven door de literatuur bij Visual C++. Daardoor kwam ik in allerlei problemen die soms zeer moeilijk op te lossen waren. In de komende subparagrafen staan ze allemaal op een rijtje.

4.4.1. Venstergrootte en positie De vijf vensters moesten zo over het scherm verdeeld worden dat ze alle vijf zichtbaar waren voor de gebruiker en dat de grafiek in de vensters van de juiste verhoudingen zou zijn. Als de simulatie wordt gestart dan 'kijkt' het object verantwoordelijk voor de presentaties naar het formaat van het basisvenster en berekend vervolgens de positie en grootte van de vensters. Het indrukken of kiezen van rangschikken heeft het zelfde effect, wanneer de gebruiker de vensters heeft verplaatst of het



34


Stageverslag

Implementatie

basisvenster van formaat heeft veranderd. Na enig gepuzzel kwam ik voor de schermen tot de volgende verhoudingen. Voor het vooraanzicht en de numerieke presentatie, 1/3 tegen 7/16. Voor de andere vensters, 2/3 tegen 7/24. Hierdoor hield ik aan de onderzijde nog een strook over voor de iconen. De verhoudingen van het vooraanzicht en zijaanzicht wijkt iets af van de werkelijkheid, maar de presentatie lijkt heel goed op de werkelijkheid. Op het figuur hier onder is goed te zien hoe de schermen zich ten opzicht van elkaar verhouden.

Figuur 15 Simulatie met alle vensters geopend

4.4.2. Verhoudingen schip Een ander presentatie probleem waarbij verhoudingen een belangrijke rol spelen is de presentatie van het vooraanzicht en zijaanzicht. Wat ik moest weten wat de verhoudingen van een gemiddeld diepstekende schip is. Hoe veel van een schip boven het water uitsteekt wanneer het een bepaalde diepgang heeft. Deze verhoudingen waren binnen Rijkswaterstaat nergens beschikbaar. Er zijn veel overzichten van schepen, maar nergens met de verhoudingen die ik nodig had. De oplossing vond ik in de bibliotheek van de directie Noordzee, op een andere afdeling van Rijkswaterstaat was een boek beschikbaar met een overzicht van alle grote schepen die in 1992 zijn gemaakt. In het boek "Significant Ships of 1992" [LINGWO93] waren drie prachtige voorbeelden van diepstekende schepen te vinden, waarvan de Bergeland', een bulk carrier, gelijk een van de grootste ter wereld is. Na wat gereken kwam ik tot het volgende rijtje verhoudingen: breedte dekhoogte diepte cabine hoogte cabine breedte

: lengte

=

: breedte

=

:

=

:

=

: 6 5 : 9 3 : 4 1 : 2

=

1

dekhoogte dekhoogte : cabine hoogte

1

: 1

Deze verhoudingen zijn natuurlijk niet voor alle schepen gelijk, maar leveren op het beeldscherm een juist plaatje op.



35

Stageverslag


Implernentatie

4.4.3. Coördinaten Wat ik nu had waren de juiste verhoudingen voor het schip met de werkelijke afmetingen in het geheugen. Hoe vertaal je zoiets om naar het scherm? Hier heeft Microsoft wat op gevonden. Van ieder object verantwoordelijk voor de vensters, is in te stellen welk coördinatenstelsel er gebruikt wordt. Zo werd het mogelijk om gewoon gebruik te maken van de werkelijk afmetingen in decimeters en het polygoon in het venster te tekenen. Van het vooraanzicht bijvoorbeeld ligt de oorsprong (0,0) in het midden van het scherm. De linker bovenhoek heeft de coördinaat (-450, 290), de rechter onderhoek ligt op (450-280). Het voordeel was hierbij dat de waterspiegel gewoon een horizontale lijn door de oorsprong is en voor de bodem kan gewoon het zelfde coördinaten systeem gebruikt worden. Een ander voordeel is, dat het coördinaten systeem relatief is, daardoor veranderd de grafiek van grootte wanneer het venster wordt aangepast.

4.4.4. Geheugen lek Toen ik een bootje in de beide venstertjes had weten te tekenen, ontdekte ik een van de minst eenvoudige programmeer problemen die ik ben tegenkomen in het ontwikkelingstraject. De computer liep vast als je de venstertjes erg vaak van grootte veranderde. Na uren achter elkaar gezocht te hebben met de debugger, ontdekte ik de oorzaak. Het geheugen raakte te vol. Het bootje wordt getekend in een zogenaamd 'Client' gebied van het venster. Dit is een object dat iedere keer als het venstertje opnieuw wordt getekend, wordt gedeclareerd. Het Client object is het object waarin het bootje getekend wordt, deze zet het in het geheugen getekende bootje op het scherm. Objecten hebben net als lokaal gedeclareerde variabelen de eigenschap, dat nadat je een functie verlaat het geheugen weer netjes wordt opgeruimd. Een object heeft hiervoor zelfs een speciale functie, de destructor. Over het algemeen werkt deze feilloos en wordt het geheugen netjes schoongemaakt. Dit wordt ook onderschreven door de boeken bij Visual C++. In dit geval was het helaas anders, iedere keer als het bootje werd getekend bleef het oude bootje in het geheugen staan. Na vele keren tekenen was het gehele werkgeheugen gevuld met bootjes en kon het programma niets meer. Het oplossen van het probleem was minstens zo moeilijk als het ontdekken ervan, bijna twee dagen heb ik allerlei mogelijkheden geprobeerd. Uiteindelijk deed ik het als volgt: void CvoorkantSchip::OnPaint() II zorgt voor het tekenen van het venster CPaintDC *dc; 1/ een pointer naar de 'Client' dc = new CPaintDC(this) 1/ maakt de pointer naar het object de rest van de functie tekent het bootje this->ReleaseDC(dc) /1 de 'Client' vrijlaten delete dc; II de 'Client' uit het geheugen verwijderen

Wat hier gebeurd is dat het object dat verantwoordelijk is voor het tekenen wordt aangemaakt. Vervolgens wordt na het tekenen het geheugen weer vrijgemaakt door het object weg te gooien. Dit is het resultaat na veel geëxperimenteer, want deze constructie kan op vele manieren, maar dit is de enige die goed functioneerde.

4.4.5. Flitsende bootjes Nadat de bootjes zonder problemen werden getekend, begon ik te werken aan de simulatiecyclus. Toen ontdekte iets wat ik me niet gerealiseerd had. De wijze waarop ik de bootjes nu tekende had het effect dat de presentatie gaat flitsen. Wat gebeurde er namelijk: Eerst werd de lichtblauwe lucht getekend; het water; stuurboord, bakboord en kajuit van de boot; het wateroppervlak.



36

Stageverslag

Sirnulatte Diepstekende Schepen

Implementatie

Dus iedere keer als de presentatie ververste, werd de oude tekening overtekend door de lichtblauwe lucht en het water, waarna vervolgens het bootje er weer overheen getekend werd. Het gevolg is een flitsend bootje. De oplossing vond ik tussen de voorbeeld programma's. Het programmaatje MDI' heeft een venstertje waarin een balletje heen en weer stuitert. Dat balletje wordt niet iedere keer direct op het scherm getekend, zoals ik dat deed met het schip. MDI maakt eerst een aparte ruimte aan het in het geheugen waar het balletje wordt getekend, vervolgens wordt het geheugen iedere keer naar het scherm gecopieerd. Daardoor flitst het balletje niet wanneer het verplaatst wordt. Dit deed ik dus ook met de bootjes. Dat geeft in C++ de volgende constructie: void CVoorkantSchip: OnPaint () CBrush Brush; CPen Pen; CRect rect; CBrush *PtrûldBrush; CPen *PtrOldPen; CPaintDC *dc; Cgitmap *bm. CBitmap *PtroldBitmap; CDC *dcMem.

bm = new Cbitmap; dc = new CPaintDC(this) ; dcMem = new CDC() ; GetClientRect (rect) ;

de Kwast die vlakken in kleurt

/1 de Pen die omlijning verzorgt /1 rechthoek voor coördinaten pointer naar pointer naar pointer naar pointer naar /1 pointer naar /1 pointer naar geheugen

de oude kwast de oude pen 'Client' gebied de bitmap in het geheugen oude bitmap 'Client' gebied in

// bitmap geheugen // 'Client' gebied /1 'Client' gebied // coördinaten van

toewijzen aanmaken in geheugen aanmaken het venster opvragen

/1 aanpassen aan het venster bm->CreateCompatibleBitmap(dc, rect.Width() , rect.Height() het instellen van de coördinaten en het tekenen dc->BitBlt(-(t'tXBREED/2), -MXDIEP, MXBREED, // zet de tekening (MXHOOG+MXDIEp), dcMem, - // vanuit het geheugen (MXBREED/2), -MXDIEP, SRCCOPY); II op het scherm dcMem->SelectObject(PtrOldBitmap) ; // this->ReleaseDC(dc) ; // delete dcMem; II delete dc; II delete bm; 1/

Bitmap vrijgeven Gebied vrijgeven geheugen vrijgeven geheugen vrijgeven geheugen vrijgeven

Een behoorlijk ingewikkelde constructie zoals je ziet. Deze is opnieuw ontstaan door veel experimenteren.

4.4.6. Numeriek Toen ik de simulatie cyclus rond had ging ik me concentreren op andere presentaties. Het numerieke venster. De grafische vensters hebben de mogelijkheid dat grafiek in de vensters mee veranderd als de vensters van grootte worden veranderd. Met het numerieke venster wilde ik het zelfde. Maar dat werkt weer heel anders. Tekst is in Windows namelijk niet grafisch, dus van een relatief coördinaten stelsel trekt windows zich in dit geval niets aan. Als je de tekst van grootte wil veranderen moet je iedere keer een ander lettertype inladen. Dit probleem heb ik niet meer kunnen oplossen. Het inladen van nieuwe Iettertypes had te veel voeten in de aarde om een snelle oplossing te verzinnen. Ik heb besloten om het voorlopig maar in de standaard lettertype te doen.



37

Stageverslag


Implementatie

4.5. SIMULATIE De simulatie is het hart van het programma en wordt centraal in gang gehouden in het Model object. In deze paragraaf behandel ik de verschillende processen die komen kijken bij het berekenen van de veranderingen. En hoe die verandering vervolgens weer op het scherm gezet worden.

4.5.1. simulatie proces Nadat de gebruiker gekozen heeft voor het starten van de simulatie worden alle objecten die nodig zijn bij de simulatie aangemaakt. En vervolgens komt er een proces op gang. In een normaal' 0programma gebeurt dit gewoon met een lus die iedere keer doorlopen wordt, totdat een of andere actie hem onderbreekt. In een Windows applicatie gaat dit net even anders. Hier wordt alleen met behulp van messages een actie worden ondernomen. Omdat het regelmatig moet, heeft Windows hier een oplossing voor. Een timer, dit is een klokje dat eens in de zoveel tijd een timer-bericht stuurt. De message-handler 'OnTimer' vangt dit bericht af. Dus zo gauw de simulatie gestart wordt, wordt er een timer aangemaakt. En die zet het simulatieproces in gang. Dit is een vaste volgorde van handelingen: void CModel::OnTimer)tJINT /*id*/) if (simustate == START) Klok- >Bereken)) Omgeving- >Bepaal)) Statis->Verzamel () UpdateVensters 1)

7/ Alleen doen als START is ingedrukt /7 Bereken de simulatietijden Bepaal de bodem en de rest

/7 Verzamel gegevens over kielspeling e.d. /7 Verversen presentatie

De simulatie kan onderbroken worden door op pauze te drukken. Hierdoor wordt de timer en de simulatieklok gestopt. Als dan de start knop wordt ingedrukt, wordt er weer een timer aangemaakt en de klok wordt weer gestart.

4.5.2. Verplaatsende bodem De bodem wordt ingelezen als een raster van punten, die over de gehele (relatieve) lengte van het venster wordt getekend. Dit is een raster van 550 meter bij 125 meter, met vakken van 25 bij 25. Dat zijn dus 6 punten in de breedte en 23 punten in de lengte. Steeds als de boot een stuk verplaatst worden de volgende paar punten ingelezen. Dit brengt een probleem met zich mee, je kan namelijk niet steeds weer het hele raster overnieuw inlezen. Wat je moet doen is steeds de positie van de nieuwste ingelezen waarde opschuiven over het raster. Waardoor je steeds een andere 'eerste' positie krijgt. Op het onderstaande figuur is te zien hoe dit in z'n werk gaat.

Simulatie gestart, raster gelezen, laatste nieuwe = 22, eerste = 0

r

i1

1 1

2 3 4 5 l l

l 6 1 7 1 8 1 9 1 101111 ... 191201211221

Boot verplaatst zich 50 meter, laatste nieuwe = 1, eerste = 2

10112

3

t

1

1

4 5

l 6 1 7 1 8 1 9 1 101111 ... 191201211221

Figuur 16 Verplaatsing bodem onder het schip

Terwijl de bodem 'circulair' wordt ingelezen, worden ook de polygonen voor de bodem presentaties uitgerekend. Dit zijn twee lijsten van diepte getallen. Een voor het vooraanzicht, dit zijn de hoogste



38

Stageverslag


Implementatie

punten in de lengterichting van het raster. En een voor het zijaanzicht, dit zijn de ondiepste punten in de breedte richting van het raster. Deze schuiven op dezelfde wijze als hierboven op. Dit zorgt ervoor dat op de presentatie de bodem onder de boot door verplaatst.

4.6. EVALUATIE In deze paragraaf wordt het resultaat van de implementatie geëvalueerd. In hoeverre het programma af is. Waar en waarom de problemen in de planning zijn ontstaan. Bovendien wordt het produkt vergeleken met het ontwerp.

4.6.1. Planning De planning van het programmeren had ik iets te optimistisch ingeschat. Visual C++, was voor mij een compleet nieuwe taal in een onbekende programmeer omgeving. Daardoor is het moeilijk in te schatten hoeveel tijd iets kost. Je weet niet van te voren wat voor problemen er kunnen ontstaan. Dit is ook de belangrijkste reden dat een groot aantal onderdelen in het programma niet zijn afgekomen. De planning verschilde als volgt met de werkelijkheid:

1 2 1 3 2 2 1 2 4 4 2 2 3

Bouwen van het skelet Declareren functies en interfaces Vastleggen interfaces Implementeren resources Vastleggen dialogen Scheepsdatabase afhandeling Communicatie DB-HMR Inlezen lodingsgegevens Traject Presentatie Schip Presentatie Omgevingsbepaling Beweging Samenbrenaen en testen Qeheel

2 2 1 3 3 0 0 0 1 10 3 1 2

Zoals te zien is ging de meeste tijd steken in het bouwen van de presentatie en de gebruikersinterface. Dit waren de onderdelen waar de grootste problemen naar voren kwamen. Ondanks de optimistische inschatting en de problemen zijn de volgende onderdelen af gekomen: • Schip class • Invulvenster Schip, zonder database • Invulvenster Water, zonder DB-HMR communicatie • Invulvenster Simulatie • Presentatie voor-/zijaanzicht schip en bodem • Numerieke presentatie • Bodem, computer gegenereerd • Omgeving • Simulatie cyclus • Gebruikersinterface Onderdelen die nog niet zijn gebouwd: • • • • • • •

Database scheepsgegevens DB-HMR communicatie Waterstandsmodel Beweging Topografische presentatie Traject presentatie lnlezen lodingsgegevens



39

Stageverslag


Implementatje

Het ontbreken van deze onderdelen brengt met zich mee dat het programma nog niet doet waarvoor het ontworpen is. En dat is een vaart simuleren van een diepstekend schip door de vaargeul, gebruik makende van de echte meetgegevens. Toch doet het programma al iets en dat is het laten varen van een diepstekend schip over een door de computer gegenereerde bodem. Het programma wordt niet langer door mij uitgebreid. Ik laat het echter zo achter dat een volgende programmeur zonder al te veel problemen andere functionaliteiten aan het programma kan toevoegen. Hiervoor gebruik ik de overloop' periode, die ik heb opgenomen in de planning.

4.6.2. Ontwerp De staat waarin het programma zich nu bevindt verschilt niet veel met het ontwerp. Alle basis ideeën zo goed als gelijk gebleven. De structuur zoals dat is vastgelegd in het Technisch Detailontwerp is alleen wat veranderd. Het eindresultaat is opgebouwd uit een wijd vertakte boom van objecten. Deze ziet er als volgt uit:

SDS applicatie

Model Splash/Info basis venster

Klok

Water

dialoog

Omgeving Statistiek

Bodem

VoorZijaanzicht Topografie 1 aanzicht kind venster , kind venster 1

1 Numeriek 1 Traject 11 1

nvul Schip simulatie dialoog d ialoog

kind venster

kInd venster

LSch"

1

Invul water dialoog

Parsed edit invoer

Figuur 17 Opbouw van objecten in SDS

De bouw van SDS is zo wijd vertakt, omdat Model de communicatie tussen objecten verzorgt en in stand houdt. De objecten kunnen elkaar aanroepen doordat de pointers worden doorgegeven aan die objecten die contact met elkaar moeten hebben. Zo worden Schip en Omgeving aangeroepen door Vooraanzicht voor de grafische presentatie. In het originele ontwerp waren voor deze grafische presentatie twee objecten aangemaakt, Grafische geul en Grafisch schip, de taken van deze objecten zijn echter onder gebracht bij het schip en de omgeving zelf. Een aspect komt in het bovenstaande figuur niet naar voren. De objecten Vooraanzicht, Zijaanzicht, Topografie, Traject en Numeriek, zijn allemaal gebaseerd op een object, het Presentatie object. Hierdoor bevatten ze allemaal gelijksoortige informatie, maar ieder object kan totaal verschillende dingen presenteren. De wijze waarop dit is geïmplementeerd is te zien in het onderstaande figuur.



40

Stageverslag


Implementatie

Presenatie kind venster

/ \.toorZijaanzicht T aanzicht

___

Traject Numeriek

Figuur 18 Hiërarchische structuur van de presentatie objecten

De basis ideeën uit het dynamische ontwerp zijn zo goed als allemaal overgenomen in het programma. Dit ontwerp was dus ook een goed houvast bij het programmeren van het simulatie pakket.

4.6.3. Produkt Over het eindprodukt (bijlage IV), zover dat nu af is. Ben ik behoorlijk tevreden. Er kan nu iets worden gesimuleerd. Een schip vaart over een door de computer gegenereerde bodem. Daarbij is het mogelijk de simulatie sneller te laten verlopen, de vaarsnelheid in te stellen. En de invoer van specificaties heeft duidelijk effect op het gepresenteerde bootje. Daarbij worden de numerieke gegevens van iedere vaart bij gehouden. Dit alles gebeurt zonder fouten of vastlopers. Het programma voldoet nog niet aan de eindeisen, maar het is duidelijk te zien hoe het na implementatie van de andere functionaliteiten eruit gaat zien.


Rijswijk, 31 januari 1995 41


Stageverslag

Evaluatie

5. EVALUATIE In dit hoofdstuk wordt de gehele stage nog eens bekeken. Hierbij behandel ik de stageopdracht zelf. De leereffecten die bij de stage tot uiting kwamen. De praktisch opgedane kennis en ervaringen worden getoetst aan de theorie. En als laatste wordt beschreven hoe ik na deze stage aan kijk tegen de opleiding.

5.1. OPDRACHT In deze paragraaf worden alle aspecten binnen de opdracht geëvalueerd. Achtereenvolgens komen aan de orde, de produkten die opgeleverd zijn, het verloop van het proces en de aanbevelingen en toekomst van het eindprodukt.

5.1.1. Produkten In deze subparagraaf wordt de bruikbaarheid van de produkten besproken. Deze waardering is de ontwikkelaar zelf opgesteld. Het waarderen van eigen produkten is niet eenvoudig, maar omdat ieder later produkt afhankelijk was van het vorige, kwamen fouten op die manier wel naar voren. Aan de orde komen het functioneel detailontwerp, prototype, technisch detailontwerp en het simulatiepakket. Alle produkten zijn gebaseerd op het werk van Peter-Paul de Bruin. Vooral op basis van zijn 'Definitiestudie/Basisontwerp', welke zeer volledig was en niet bijgesteld hoefde worden. Functioneel Detailontwerp Het originele rapport bevatte een aantal onvolledigheden. Bovendien was het verouderd, omdat de communicatie met het meetnet Noordzee inmiddels is vervangen door de database DB-HMR waarin alle meetgegevens worden opgeslagen. Door sommige details aan te passen en sommige onderdelen beter te beschrijven, kwam ik tot een 'Vernieuwd Functioneel Detailontwerp'. Dit is samen met het originele functioneel detailontwerp een goede gedetailleerde basis voor het verdere proces geweest. Het vernieuwde verslag is echter ook leesbaar zonder het origineel, maar is dan hier en daar niet volledig. Prototype Dit was mijn eerste poging in het object georiënteerd programmeren. Deze wist ik uiteindelijk op te stellen door eerst een aantal programmeer voorbeelden door te nemen. Het prototype bleek een goede richtlijn te zijn voor zowel de opdrachtgever als de ontwikkelaar bij het ontwikkelen van het pakket. In latere versies van het programma is nog veel herkenbaar uit het prototype. Toch IS de opbouw van het programma totaal verschillend. Technisch detailontwerp Dit onderdeel is niet volledig. Net als bij Peter-Paul kwam ik in aanraking met hetzelfde probleem. OMT is nog geen gangbare ontwerpmethode. En binnen Rijkswaterstaat, maar ook in mijn directe omgeving is er niemand die deze methode kent en gebruikt. Dit houdt niet in dat de methode ongeschikt is, maar alles wat je hiermee maakt is niet te toetsen behalve dan met eigen ervaring. Het 'Gewijzigd Technisch Detailontwerp' is niet af. Tijdens het opstellen van het Dynamisch Model bemerkte ik dat het een zeer tijdrovende ontwerpmethode is. Bovendien ontdekte ik dat bepaalde activiteiten binnen de objecten niet altijd tot uitdrukking komen in de diagrammen. Het voltooien van het Technisch Detailontwerp leek mij niet zinvol. Toen ik tot deze conclusie was ik in week negen van de stage aangeland en volgens mijn opgestelde planning had ik allang aan de implementatie moeten beginnen. Simulatiepakket Het eindprodukt waar het allemaal om draaide. Peter-Paul was niet verder gekomen dan een aantal basisonderdelen. Ik zelf ben totaal overnieuw begonnen, gebruik makende van de grafische gebruikersinterface die ik had ontworpen voor het prototype. Het pakket kan op dit moment een vaart met een willekeurig schip simuleren. Hierbij beweegt het schip echter niet, omdat er geen golfslag is.



42

Simulatic Diepstekende Schepen

Stageverslag

Evaluade

Bovendien is er nog geen sprake van getijden. En de bodem wordt nog gegenereerd door de computer. Het pakket is verre van af, maar het is al goed zichtbaar van wat het gaat worden in de nabije toekomst. In middels is een afstudeerder van de Sector Informatica geïnteresseerd in het voltooien van het simulatiepakket. Wat hem allemaal nog te doen staat is te vinden in subparagraaf 5.1.3.

5.1.2. Proces In deze subparagraaf wordt de planning vergeleken met de werkelijke tijdsbesteding. Daarna wordt in gegaan op de werkzaamheden. Planning Het plannen van een grote opdracht is niet zo eenvoudig wanneer je nog nooit eerder in een dergelijke situatie geweest bent. Dit is de voornaamste reden waarom originele planning niet helemaal overeen komt met de werkelijke situatie. Ik heb wel mijn best gedaan om me zoveel mogelijk aan deadlines en mijlpalen te houden. Anders kan je net zo goed geen planning opstellen. De bovenste grafiek is de oorspronkelijke, de onderste de werkelijke tijdsbesteding. plan van aanpak evalueren fuctioneel ontwerp evalueren test specificaties evalueren technisch ontwerp implementeren

9 .4jj

overdracht

week 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

plan van aanpak evalueren fuctioneel ontwerp prototype doornemen OMT en Visual C++ technisch ontwerp implementeren verslagen

week 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Figuur 19 Planning versus werkelijke tijds besteding

De duidelijkste verschillen tussen de twee liggen bij de verslaggeving en het doorlezen van literatuur. Dit waren twee activiteiten die ik bij het opstellen behoorlijk over het hoofd heb gezien. Het doornemen van de literatuur ging vanzelfsprekend hand in hand met de activiteiten waarbij de literatuur van pas kwam. Maar voor de verslaggeving, moest flink worden gekort op de tijd gereserveerd voor de implementatie. Werkzaamheden Omdat dit project gestoeld is op de uitvoering van een voorganger, heb ik gekozen gebruik te maken van dezelfde methoden. Peter-Paul maakte gebruik van SDMII, een ontwerpmethode die



43

Stageverslag


Evaluatie

Rijkswaterstaat gebruikt bij de systeemontwikkeling. Dit is een typische top-down methode, die niet echt geschikt is bij het object-georiënteerd ontwerpen, omdat dat immers om een bottom-up benadering vraagt. Peter-Paul's keuze viel toen op de Object Georiënteerde methode OMT als meest geschikte methode voor deze klus. Het nadeel bleek later echter dat SOM II en OMT elkaar af en toe in de weg zitten. Ik heb de meeste dubbelzinnigheden weten te voorkomen, omdat Peter-Paul in zijn verslaggeving van de eerste poging er meestal wel voor waarschuwde. OMT is nieuw voor mij en voor Rijkswaterstaat. Voorschriften, ideeën en goede voorbeelden in het gebruik van deze methode zijn dus ook helaas niet te vinden. Peter-Paul's ontwerp was echter een voorbeeld van hoe het naar mijn mening niet moest. Systeemontwikkeling met OMT zag ik in eerste instantie als een goede aanpak, maar later zag ik het vooral als omslachtig en te uitgebreid. De technieken helpen echter wel de gedachten van de ontwerper te ordenen en daardoor heeft deze methode zeer geholpen bij de ontwikkeling van het pakket. Het programmeren in een object-georiënteerde taal was voor mij nieuw. Hoewel ik ervaring heb met 0, vereist de taal C++ toch weer een hele andere manier van denken. Ook de Windows omgeving was nieuw terrein voor mij. Het werken bij Rijkswaterstaat op zich was een prettige ervaring. In het begin moest ik nogal wennen aan de regelmaat, die bij een studentenleven altijd een beetje ontbreekt, maar nu juist opgelegd wordt. Maar eenmaal in het ritme, gaf het houvast en helpt het je dag in te delen. Het gebouw van de Directie Noordzee is een rustige werkomgeving, waarbij iedere werknemer zo'n beetje z'n eigen kantoor heeft. Ook aan dit aspect moest ik even wennen, maar de rust werkte meestal stimulerend.

5.1.3. Voltooiing Het project is dus niet af gekomen. Deze subparagraaf zet nog eens op een rijtje welke functionaliteiten nog aan het pakket moeten worden toegevoegd, wil het aan de eisen voldoen. Tevens wordt een aantal extra aanbevelingen toegevoegd om het pakket nog optimaler te laten functioneren. Deze onderdelen moeten nog worden toegevoegd of afgemaakt, om te kunnen spreken van een goed functionerend Simulatie Pakket: • niezen van lodingsgegevens • Communicatie met DB-HMR • Berekenen van het waterstandsmodel • Presentatie topografie, met positie • Presentatie traject met waterstanden en positie • Beweging van het schip als gevolg van golfslag m.b.v. overdrachtsfuncties • Database voor scheepsgegevens • Simulatie voor de lJ-geul • Logfile numerieke presentatie • Volledige, overzichtelijke numerieke presentatie Andere eisen en verzoeken die niet in dit ontwerp zijn opgenomen, maar wel te overwegen zijn: • Rekening houden met stroming • Vaarten vanuit de haven de zee op simuleren • Vaart tot aan het begin van de Rotterdamse haven (lage licht) Al met al bieden deze nog te implementeren functionaliteiten genoeg werk op voor een nieuw stage- of afstudeerproject. Ik hoop dat mijn opvolger gebruik maakt van al het werk dat Peter-Paul en ik hebben verricht, zodat een werkend pakket nu eindelijk het daglicht zal zien.

5.2. LEEREFFECTEN De stage was bijzonder leerzaam. In deze paragraaf zet ik op een rijtje welke kennis ik heb opgedaan en welk nut ik hiervan hoop te hebben in de nabije toekomst.



44

Stageverslag

Simuiatie Diepstekende Schepen

Esaluat!e

Werkervaring Dit is het voornaamste doel van de stage. Het opdoen van werkervaring in een informatiserings omgeving. Voor mij hield dit in, het zelfstandig werken aan een software ontwikkelingsproject, op een afdeling van Rijkswaterstaat die weinig te maken heeft met informatica. Doordat het een individueel project was, heb ik geleerd hoe zoiets aan te pakken. Ook heb ik geleerd op school opgedane kennis in de praktijk toe te passen. Dit was een belangrijk houvast waardoor ik in staat was het project in te schatten en zelfstandig uit te voeren. Naast de technische werkervaring, heb ik ook geleerd te functioneren op een afdeling. Dit was niet zo moeilijk, omdat mijn werk niet van belang was voor andere mensen binnen Directie Noordzee behalve mijn opdrachtgever en de onderafdeling MTBA. Bovendien had ik de beschikking over een eigen kamer, waardoor ik volkomen onafhankelijk mijn gang kon gaan. Noordzee Voordat ik bij Directie Noordzee ging werken, wist ik niet precies wat deze afdeling van Rijkswaterstaat nu precies deed. Na een halfjaar stage lopen heb ik vele taken van dicht bij meegemaakt. Voor de afwisseling heeft opdrachtgever Frits Draisma me af en toe op excursie genomen naar verschillende werkgebieden van de directie. Zo ben ik wezen kijken op een schip verantwoordelijk voor het loden van de vaargeul. Ik heb het Hydro-Meteo centrum Rijnmond in Hoek van Holland bezocht. Ik ben bij het Rotterdams Havenbedrijf wezen kijken naar een tijpoorten systeem voor de Rotterdamse haven. En ik ben een middagje op een baggerschip - de sleephopperzuiger Geopotes 14 - mee geweest, die bezig was de Europoort uit te baggeren. Ik zou nog een keer mee gaan met het meetvliegtuig van de kustwacht, maar dat ging tot drie maal toe op het laatste moment niet door. Plannen Een belangrijke activiteit waarbij het werk voor het project moet worden ingeschat en geordend. Op school heb ik geleerd voor betrekkelijk kleine projecten een tijdsindeling te maken. Het plannen van een groter zelfstandig project heeft meer voeten in de aarde. De moeilijkheid zat hem vooral in het voorzien van problemen, dat is waar een planning de mist in kan gaan. Toch denk ik dat ik bij een volgend project beter kan inschatten hoeveel tijd het me gaat kosten. Communicatie met opdrachtgever Essentieel bij het uitvoeren van ieder informatiseringsproject. En iets dat ik op school aan de hand van rollenspel wel heb leren kennen. Toch is de werkelijkheid altijd weer anders. Ik heb geleerd gedurende de ontwikkelingsfase, de opdrachtgever op de hoogte te houden van de voortgang. En oplossingen voor het probleem op een minder technische manier uitleggen, zodat het voor iemand zonder programmeer ervaring duidelijk is. Aanleren nieuwe methoden Doordat mijn voorganger, Peter-Paul de Bruin, gekozen heeft voor een object-georiënteerde oplossing van het probleem was ik verplicht om mezelf een nieuwe methode aan te leren. Dit deed ik door het doornemen van de beschikbare literatuur en het evalueren van het ontwerp van Peter-Paul. Hierdoor heb ik niet alleen object-georiënteerd leren ontwerpen en programmeren. Ik heb bovendien geleerd hoe je zelfstandig een methode of techniek kan leren. Object-georiënteerd Een denkwijze die in de voorstage periode helemaal niet aan bod is gekomen. Dit was dus ook de eerste keer dat ik hiermee in aanraking kwam. En ik ben er een beetje door gegrepen. Het is een compleet andere manier van tegen de dingen aankijken. De denkwijze heeft binnen de software ontwikkeling inmiddels een enorme vlucht genomen. Ik ben blij dat ik deze denkwijze op zo'n praktische manier heb kunnen aanleren. En ik weet zeker dat deze kennis mij in mijn verdere loopbaan goed van pas zal komen. De eerste vruchten van deze opgedane kennis zijn al afgeworpen. Omdat ik gedurende deze stage me intensief bezig heb gehouden met Object-georiënteerd ontwerpen en programmeren heb ik vrijstelling gekregen voor het vak K1206, waarin dit onderwerp behandeld wordt.

Rijssijk, 31 Januari 1995


45

Stageverslag

Sirnuatie Diepstekende Schepen

Evaluatie

OMT Een zeer grondige gedetailleerde ontwerptechniek, die helpt bij het ordenen van objecten en operaties uit het probleem. Het is helaas geen techniek die erg gangbaar is in de software ontwikkeling. Toch geeft het een goede beschrijving van mogelijke aanpakken bij het oplossen van object oriënterende problemen. En het lijkt mij dat andere methoden elementen bevatten die ook in OMT gangbaar zijn. C++ Hoewel ik de nodige ervaring heb met 0, is C++ toch weer iets totaal anders. Hoewel ik geen andere object oriënterende talen ken, vind ik C++ een zeer krachtig hulpmiddel in vergelijking met C. Ontwerpen zijn zonder al te veel problemen over te nemen in de taal. Bovendien worden alle voordelen van object oriëntatie uitgebreid door de principes van functie overloading en de implementatie van erfelijkheid. Windows Het was bijzonder leerzaam te zien wat er zich allemaal afspeelt onder de schil van vensters en iconen. Tijdens de stage heb ik geleerd hoe je onder Windows een applicatie maakt, die gebruik kan maken van alle voordelen die Windows te bieden heeft. Gebruikers interface Dankzij Windows en Visual C++ was het ook mogelijk om een zeer gebruikersvriendelijke interface te creëren. Ik heb geleerd hoe dat je dit doet binnen Windows. Bovendien heb ik geleerd afwegingen te maken om het voor de gebruiker zo makkelijk mogelijk te maken.

5.3. THEORIE/PRAKTIJK In deze paragraaf geef ik aan welke theoretische kennis ik op school heb opgedaan en van pas kwam tijdens de stage. Ook beschrijf ik in hoeverre de praktijk verschilde met de theorie. SOM Deze ontwikkelingsmethode is ons bij een aantal software ontwikkelings vakken aangeleerd. Het is enorme houvast bij het plannen en documenteren van alle software ontwikkelingsstappen. Maar de methode is zo algemeen en uitgebreid, dat het bij veel projecten erg veel tijd vergt. Van de ontwerpers, wordt verlangd dat hij iedere activiteit motiveert en documenteert. Dit is zeer zeker noodzakelijk bij grote en onoverzichtelijke projecten, waarbij contact met gebruikers, opdrachtgevers en project medewerkers optimaal moet verlopen. Tijdens de vakken op school was al te merken, dat de meeste projecten te kleinschalig zijn om deze methode uitgebreid te gebruiken. Veel stappen kunnen heel summier worden behandeld en af en toe gewoon worden overgeslagen. Zo heb ik de methode tijdens dit project ook toegepast. Alleen die onderdelen waarbij het van belang was dat er iets vastgelegd moest worden heb ik uitgevoerd. Als ik alles precies volgens de regels van de methode had aangepakt, zou ik waarschijnlijk nu nog in de ontwerpfase verkeren. En hoewel het goed is een lange tijd aan het ontwerp te werken, blijft het zaak dat het einddoel uiteindelijk toch in niet al te lange tijd bereikt wordt. Kortom 5DM biedt houvast in de meeste projecten, maar pas het niet te streng toe, omdat dat te tijdrovend is. Software Engineering Dankzij de Software Ontwikkelings vakken heb ik niet alleen een aantal ontwikkelingsmethoden aangeleerd. De vakken hebben me ook geleerd een project in te schatten en te plannen. Bovendien kon ik dankzij de oefeningen in veel gevallen heel intuïtief te werk gaan. Tijdens deze vakken is de communicatie tussen ontwikkelaar en opdrachtgever uitgebreid behandeld aan de hand van rollenspel. Hoewel het in de praktijk er altijd anders aan toe gaat, heeft het me wel laten realiseren de opdrachtgever niet te bestoken met allerlei technische termen. En door het regelmatige contact krijgt



46

Stageverslag

Simulatie Depstekende Schepen

Evaluatie

de opdrachtgever bovendien de kans om het project bij te sturen en bepaalde verzoeken tijdens het ontwerp nog toe te laten voegen. Wiskunde Hoewel ik niet altijd even zeker was van het nut van zoveel wiskunde bij de Sector Informatica, kwam het in deze stage toch nog even van pas. In een middagje heeft Henk Keyser, een specialist op het gebied van waterbewegingen, uitgelegd hoe golven in elkaar steken en wat voor effect ze hebben op de bewegingen van het schip. Zonder de wiskundige kennis, was het waarschijnlijk niet zo goed te volgen geweest. Helaas ben ik wat betreft de overdrachtfuncties niet verder gekomen dan dit gesprek. Dus de theorie kwam eigenlijk maar een korte middag goed van pas. Communicatieve vaardigheden Ook hierbij is de communicatie tussen opdrachtgever, gebruiker en ontwikkelaar uitgebreid behandeld. Maar de voornaamste vaardigheden die ik hiervan gebruikt heb, zijn de technieken voor documentatie. Deze kwamen goed van pas bij onder andere het maken van dit verslag, alsmede de tussenverslagen voor het ontwerp. Programmeertalen Vanaf de propedeuse zijn een aantal programmeertalen aangeleerd. Eerst Pascal en toen 0, deze programmeertalen zijn een voorname basis voor de meeste andere talen. Dus als je die kent dan is het mogelijk om iedere andere taal te Ieren, omdat ze nou eenmaal allemaal op elkaar lijken. De kennis van 0 kwam dus goed van pas bij het onder de knie krijgen van C++. De meeste programma constructies zijn precies hetzelfde, het belangrijkste verschil zit hem in de object-georiënteerdheid. En dat is het enige wat we nog niet op school gekregen hebben. Unix vs Dos vs Windows Dit is het enige punt waarop ik kritiek heb tegenover het onderwijs. De Sector Informatica concentreert zich bij de software ontwikkeling voornamelijk op het gebruik van Unix. Dit is een veel gebruikt systeem voor grote bedrijven en het aantal bedrijven wat er op over gaat neemt nog steeds toe. Toch zie je in de praktijk, dat kleine bedrijven en bedrijven die zich niet zo bezig houden met de professionele informatie technologie, kiezen voor MS-DOS computers. Op deze machines draait tegenwoordig steeds vaker Windows. Het is jammer dat er bij de Software Ontwikkelingsvakken niet wat vaker wordt gekeken naar ontwikkeling in MS-DOS of Windows omgeving. De kennis van een programmeertaal alleen is niet genoeg in de praktijk. Ik heb daarom veel tijd moeten steken in het doorgronden van de programmeeromgeving. Zinloos? Tijdens de stage bemerkte ik dat veel theorie helemaal niet aan de orde kwam. Van het meeste had ik dat wel verwacht en tijdens de opleiding vroeg ik me ook vaak af wat het praktische voordeel van bepaalde vakken was. Zoals een groot deel van de Bedrijfskundige kennis die ik heb moeten op doen. Hoewel een deel goed van pas kwam bij het herkennen van Organisatiekundige aspecten van de Rijkswaterstaat, heb ik bijzonder weinig gehad aan bijvoorbeeld Bedrijfseconomie. Andere vakgebieden die niet aan de orde kwamen waren Databases en Netwerken. Dit lag meer aan de aard van de opdracht, dan aan die theoretische kennis. Als de opdracht in een verder stadium was gevorderd, was ik uiteindelijk wel in aanraking gekomen met deze twee vakgebieden.

5.4. OPLEIDING In deze laatste paragraaf vel ik een oordeel over de kwaliteit van de opleiding, wat ik graag veranderd zou willen zien aan het onderwijs en hoe ik aan kijk tegen de veranderingen die op dit moment binnen de opleiding spelen. Kwaliteit Uit de vorige paragraaf blijkt dat ik nog niet eens zo ontevreden ben met het onderwijs zoals ik dat tot nu toe op de opleiding kreeg. De Sector Informatica gaf mij een brede basis kennis, variërend van een

.

Rijkswaterstaat, Directie Noordzee 47


Stageversiag


Evaluatie

redelijk hoog niveau Wiskunde en programmeer technieken, tot kennis van database systemen en netwerken. Door die brede basis denk ik dat studenten een hoog inlevingsvermogen hebben gekregen en inzetbaar zijn op vele plaatsen. Deze kennis brengt bovendien met zich mee dat studenten problemen zelfstandig kunnen aanpakken en nieuwe technieken zichzelf kunnen aanleren. Tijdens de opleiding heb ik me wel eens geërgerd aan het feit dat de kennis misschien wel iets te breed gespreid was, kennis van Bedrijfseconomie leek mij niet handig voor iemand die zijn talenten voor Software Ontwikkeling wil ontplooien. En de organisatie van het onderwijs was uiteindelijk toch niet zo ideaal als ik had gehoopt. Het modulaire onderwijs vraagt van de student een enorme zelf discipline, bovendien zorgt dit zelfstandige onderwijs voor een bijzonder eenzaam bestaan binnen de school. Veranderingen Dit is een van de weinige positieve punten die ik zie in het nieuwe onderwijs. Door het vergroten van de modulen, wordt meer gedaan aan de contacten tussen studenten onderling. Bovendien brengt de terugkeer van een Havo-achtig' met zich mee dat de student meer verplicht wordt te werken. Hoewel ik geen groot voorstander ben van presteren onder dwang, zal dit uiteindelijk wel betere resultaten opleveren. Ik vind het wel jammer, dat ieder nieuw vak zoveel verschillende onderwijsvormen in zich heeft. Alles is onderverdeeld in hoorcolleges, werkcolleges en practica. Studenten die liever wel zelfstandig willen werken en op die manier goed functioneren, worden onnodig vastgelegd. Tijdens de stage heb ik hier en daar wel geruchten opgevangen van medestudenten en ik ben bang dat de kwaliteit van het onderwijs aanzienlijk naar beneden zal zijn gegaan als ik terugkeer op school. Het massale ontslag van leraren en de overgangsfase van het nieuwe onderwijs, heeft ervoor gezorgd dat de student moet vechten voor zijn studiepunten. Sommige vakken schijnen door de studenten helemaal zelfstandig moeten worden gemaakt, omdat er geen docenten beschikbaar zijn. Steeds meer studenten worden uitgeschreven, omdat lokalen overvol raken. En die onderwijzers die wel les staan te geven weten niet waar de stof over gaat. Het aantal verschillende vakken wat wordt aangeboden neemt af, waardoor niet altijd meer mogelijk is het volle aantal studiepunten per halfjaar te halen. Ik hoop dat dit slechts kinderziektes zijn van het nieuwe systeem. Maar als deze symptomen tekenend zijn voor het nieuwe onderwijs, zie ik de laatste anderhalf jaar van mijn opleiding met een lichte angst tegemoet. Object-georiënteerd Dit is het belangrijkste principe dat ik tijdens de stage pas heb leren kennen. En nu ik redelijk objectgeoriënteerd kan ontwerpen, programmeren, maar vooral denken, ben ik verbaasd dat de Sector Informatica nog steeds weinig aandacht aan deze denkwijze schenkt. Op dit moment is object oriëntatie een van de belangrijkste denkwijzen bij de meer technisch gerichte software ontwikkeling. Het herbergt allerlei aspecten waar in veel vakken van de Sector Informatica op gehamerd werd. Het verplicht de programmeur information hiding toe te passen, de ontwerpfase maakt gebruik van technieken uit de database ontwikkeling, de programmeur wordt verplicht netjes te programmeren, fouten zijn sneller op te sporen, programmacode is makkelijker her te gebruiken. Ik weet niet of men met de onderwijs herziening op dit gebied iets van plan is, maar het lijkt mij zeer verstandig om deze techniek in de toekomst uitgebreider te behandelen. Aanbeveling Ik denk dat deze object-georiënteerde ontwerpmethode slechts een van de vele voorbeelden is van technieken die binnen de Sector Informatica te weinig aandacht krijgen. Het onderwijs loopt achter de feiten aan. Sommige methoden die de studenten nu krijgen aangeleerd, zullen in een aantal jaren tijd sterk zijn verouderd. Daarom is het denk ik wijs ieder jaar de inhoud van sommige vakken te herzien, te toetsen aan de praktijk en bij te stellen. Als de Sector Informatica zich wat meer zou richten op de informatiseringsmarkt om zich heen. Meer zou samenwerken of sponsoring zou regelen met grote firma's, dan zou het wel eens een van de beste informatica opleidingen van Nederland kunnen worden. Dat is het op dit moment niet.



48

Stageverslag


IiteratuurIijst

LITERATUURLIJST BRUIN93a

Bruin, P.A. de, Afstudeerverslag. Simulatieprogramma voor diepstekende schepen, Directie Noordzee, Directoraat-Generaal Rijkswaterstaat, Rijswijk, 1993

BRUIN93b

Bruin, P.A. de, Rapport definitiestudie/basisontwerp. Simulatie Diepstekende Schepen Euro- en Maasgeul en IJ-geul, Rijkswaterstaat Directie Noordzee, Rijswijk, 1993

BRUIN93c

Bruin, P.A. de, Rapport functioneel detailontwerp. Simulatie Diepstekende Schepen Euro- en Maasgeul en IJ-geul, Rijkswaterstaat Directie Noordzee, Rijswijk, 1993

BRUIN93d

Bruin, P.A. de, Rapport technisch detailontwerp. Simulatie Diepstekende Schepen Euro- en Maasgeul en IJ-geul, Rijkswaterstaat Directie Noordzee, Rijswijk, 1993

BRUIN93e

Bruin, P.A. de, Rapport testspecificaties. Simulatie Diepstekende Schepen Euroen Maasgeul en IJ-geul, Rijkswaterstaat Directie Noordzee, Rijswijk, 1993

GEUL92

Evaluatie Geulvaart 1991 Euro-Maasgeul, Gemeentelijk Havenbedrijf Rotterdam/Rijkswaterstaat Directie Noordzee, Rotterdam/Hoek van Holland, 1992

INGEN94

Ingen, A. van, PC-HMR: PC-programmatuur HMR, Functionele Specificatie, Simtech, Hoek van Holland,1994

KIELSP84

Varen in de 72' geul, werkgroep Kielspeling, Rotterdam, 1984

LINGWO93

Lingwood, J., Significant ships of 1992, Royal Institution of Naval Architects, 1993

MARIEN90

Mariene Techniek, Informatie voor de vaart met diepstekende schepen naar de haven van Rotterdam, RWS Directie Noordzee, Rijswijk, 1990

MICROS93a

Microsoft Visual C++, Programmer's Guides, Microsoft Corporation, Redmond, Washington, 1993

MICROS93b

Microsoft Visual C++, Reference Volumes, Microsoft Corporation, Redmond, Washington, 1993

MICROS93c

Microsoft Visual C++. User's guides, Microsoft Corporation, Redmond, Washington, 1993

MICROS93d

Microsoft Visual C++, Programmer's Reference, Microsoft Corporation, Redmond, Washington, 1993

MICROS93e

Microsoft Visual C++. Professional Tools User's Guides, Microsoft Corporation, Redmond, Washington, 1993

RUMBAU91

Rumbaugh, James, M. Blaha, e.a., OBJECT-ORIENTED MODELING AND DESIGN, Prentice Hall, Englewood Cliffs, New Jersey, 1992

SDM89

SDM, Samenvatting van de System Development Methodology, Pandata, Rijswijk, 1989

TURNER90

Turner, W.S., R.P. Langerhorst, e.a., SDM. System Development Methodology. Nederlandstalige versie, Cap Gemini Publishing, Rijswijk, 1990

YOUNG93 Young, Michael J., Windows Programming with Microsoft C++, Sybex, Alameda, California, 1993



49

STAGEVERSLAG. Simulatie Diepstekende Schepen. CTE NCTi::

Recommend Documents