Ontwikkel Methode Elektrotechniek I

��

��

Inhoudsopgave Deel I: Inleiding 1. Inhoud van dit dictaat......................................................................................1 2. Systeem Ontwikkeling: wat en waarom?........................................................2 2.1. Wat is systeem ontwikkeling? ........................................................................2 2.2. Waarom systeem ontwikkeling? .....................................................................2 2.2.1. Systeem ontwikkeling als communicatie middel............................................2 2.2.2. Systeem ontwikkeling als ‘denk-tool’ ............................................................3 3. De methode: een combinatie van Yourdon en UML......................................4 3.1. Eigenschappen van de methode ......................................................................4 3.1.1. Gebruik van diagrammen................................................................................4 3.1.2. Uitgaan van ‘perfecte’ technologie.................................................................4 3.2. Stappen waaruit de methode bestaat ...............................................................5 3.3. Voorbeeld: thermostaat regeling.....................................................................6 3.3.1. Context diagram en dictionary........................................................................6 3.3.2. Event/Respons List .........................................................................................7 3.3.3. Statemachine ...................................................................................................8 3.3.4. Interactie met gebruiker ..................................................................................8 3.3.5. Globaal classe diagram ...................................................................................8 3.3.6. Sequentie Diagrammen...................................................................................9 3.3.7. PSD’s ..............................................................................................................9 Deel II: De Analysefase 4. Context Diagram & Scenario’s.....................................................................11 4.1. De symbolen van een context diagram .........................................................11 4.1.1. Het Hoofdproces ...........................................................................................11 4.1.2. De Terminators .............................................................................................12 4.1.3. Flows.............................................................................................................12 4.2. Opstellen context diagram ............................................................................13 4.2.1. Wanneer is iets een terminator?....................................................................13 4.2.2. Systemen hebben altijd output ......................................................................14 4.3. Opstellen van de dictionary ..........................................................................15 4.4. Opstellen van een scenario............................................................................16 4.5. De temperatuurregeling ................................................................................16 4.5.1. De opdrachtomschrijving..............................................................................16 4.5.2. Context diagram............................................................................................17 4.5.3. Scenario.........................................................................................................17 4.6. De parkeergarage ..........................................................................................18 4.6.1. De opdrachtomschrijving..............................................................................18 4.6.2. Scenario’s......................................................................................................18 4.6.3. Context diagram............................................................................................19

��

��

5. De Event/Respons List (ERL) ......................................................................23 5.1. Wat is de event list........................................................................................23 5.2. De onderdelen van de event list ....................................................................23 5.2.1. De event ........................................................................................................23 5.2.2. De respons.....................................................................................................24 5.2.3. De state-classificatie .....................................................................................24 5.3. Het bouwen van een ERL .............................................................................24 5.4. De controlematrix .........................................................................................25 5.5. De parkeergarage ..........................................................................................25 5.5.1. De ingang......................................................................................................26 5.5.2. De uitgang.....................................................................................................26 5.5.3. De betaalautomaat.........................................................................................27 5.5.4. Controlematrix ..............................................................................................27 6. State diagrammen..........................................................................................29 6.1. De elementen van een statemachine .............................................................29 6.1.1. De state..........................................................................................................29 6.1.2. De transitie ....................................................................................................30 6.1.3. De conditie ....................................................................................................30 6.1.4. De actie .........................................................................................................30 6.2. Omzetten event list naar een statemachine ...................................................31 6.3. De parkeergarage ..........................................................................................32 6.3.1. De ingang......................................................................................................32 6.3.2. De uitgang.....................................................................................................33 6.3.3. De betaalautomaat.........................................................................................34 Deel III: PSD’s 7. PSD’s ............................................................................................................36 7.1. Wat zijn PSD’s..............................................................................................36 7.2. De symbolen van het PSD ............................................................................36 7.2.1. De bewerking ................................................................................................37 7.2.2. De beslissing .................................................................................................37 7.2.3. De herhaling..................................................................................................38 7.2.4. Combineren van de PSD-elementen .............................................................40 8. Waarom liever PSD’s dan flowcharts? .........................................................42 9. Algoritmes ontwikkelen met PSD’s..............................................................46 9.1. Opsplitsen van problemen.............................................................................46 9.2. Een voorbeeld: de wasmachine.....................................................................46 10. Algoritmes met een herhaling.......................................................................49 10.1. Volgorde bij ontwikkelen van een lus ..........................................................49 10.2. Voorbeeld 1: Som van een rij getallen..........................................................50 10.3. Voorbeeld 2: Grootste verandering in reeks getallen ...................................53 10.4. Voorbeeld 3: Het één na grootste getal vinden.............................................57 10.5. Voorbeeld 4: Som van deelrijen zoeken .......................................................61

��

��

1. Inhoud van dit dictaat In dit dictaat wordt aandacht besteed aan een methode die gebruikt kan worden bij het ontwerpen en ontwikkelen van systemen. Hierbij wordt uitgelegd hoe je systematisch vanuit een probleemstelling kunt komen tot een oplossing. De methode die hierin wordt behandeld is een combinatie van Yourdon en UML. Er is hiervoor gekozen om te zorgen dat de technieken bij veel verschillende elektrotechnische disciplines kunnen worden toegepast. De hier gepresenteerde methodes worden vooral gebruikt bij het ontwikkelen van software, maar een subset van de technieken kan ook goed worden toegepast bij het ontwikkelen van hardware.

Dit dictaat is een inleiding, en om deze reden is de behandelde methode een subset van wat in Yourdon en UML gebruikt wordt. De subset is bruikbaar voor eenvoudige systemen, en zal in de volgende modules worden uitgebreid met nieuwe technieken.

Door het dictaat heen worden steeds twee voorbeelden gebruikt, aan de hand waarvan de methode nader wordt uitgelegd. Deze voorbeelden zijn:

• Een thermostaat regeling

• Een parkeergarage

Het eerste voorbeeld is een redelijk eenvoudig systeem. Hierdoor blijven de bijbehorende diagrammen ook eenvoudig en is goed te volgen hoe de methode wordt toegepast. Het tweede voorbeeld is wat complexer, waardoor beter zichtbaar wordt hoe de methode helpt om complexe(re) systemen te ontwerpen.

Dit dictaat is het eerste deel van een reeks van 2. In dit eerste deel worden de volgende onderdelen besproken:

1. Inleiding: wat is systeem ontwikkeling, waarom wordt het gebruikt, en welke methode wordt hier behandeld.

2. De analyse: in dit deel worden de verschillende stappen uitgebreid behandeld die behoren tot de analysefase. De verschillende diagrammen worden besproken en toegelicht aan de hand van de thermostaatregeling en de parkeergarage.

3. Opstellen van PSD’s. Deze techniek wordt gebruikt voor het verder ontwikkelen binnen een 3de generatie programmeertaal, zoals C, Java, Pascal, e.d.

In het tweede deel komen de volgende onderdelen aan bod.

4. Het ontwerp: in dit deel worden de verschillende stappen behandeld voor het ontwerpen van software.

5. Vertalen van statemachines in PSD’s.

��

��

2. Systeem Ontwikkeling: wat en waarom?

2.1. Wat is systeem ontwikkeling? Systeem ontwikkeling is in feite een verzameling van methodes en technieken die gebruikt worden tijdens het ontwikkelen van systemen. In dit dictaat ligt de nadruk op het ontwikkelen van technische systemen, waarbij met name gedacht wordt aan systemen binnen de industriële automatisering.

Bij het gebruik van een dergelijke methode wordt tijdens het ontwikkelen van een dergelijk systeem het gehele traject opgesplitst in twee belangrijke fases:

1. Analyse fase: hier wordt onderzocht en vastgelegd wat het systeem moet gaan doen, m.a.w. de gewenste functionaliteit wordt in deze fase vastgelegd.

2. Ontwerp fase: in deze fase wordt vastgelegd hoe deze functionaliteit wordt gerealiseerd.

Duidelijk moge zijn dat de analyse fase moet zijn afgerond voordat aan de ontwerpfase wordt begonnen. Het is namelijk erg vervelend als de functionaliteit verandert tijdens de ontwerpfase. Het kan n.l. blijken dat onderdelen zijn ontworpen die niet langer nodig zijn, of anders gerealiseerd dienen te worden. In praktijk lopen deze fases toch altijd wel wat in elkaar, maar het streven dient te zijn om ze zoveel mogelijk te scheiden.

Beide fases vinden voornamelijk op papier plaats. Dit betekent dat de echte realisatie (in hardware en software) pas in een laat stadium plaats vindt. Met name dit aspect blijkt in de praktijk heel moeilijk te zijn, omdat het aantrekkelijk is om met die realisatie te beginnen.

Het grote verschil tussen beide fases is dat het in fase 1 vooral gaat om het wat, en over hoe moet eigenlijk niet na worden gedacht. Ook dit is echter veel moeilijker dan het lijkt, omdat je als technicus snel geneigd bent om al meteen aan een oplossing te denken. In de eerste fase moet je dat echter expliciet niet doen. Pas in fase 2 wordt nagedacht over het hoe. Later zal in dit dictaat hier nog op terug gekomen worden, en aangegeven worden waarom dat zo belangrijk is.

2.2. Waarom systeem ontwikkeling? Het toepassen van dergelijke methodes en technieken tijdens het ontwikkelingstraject lijkt het traject te vertragen. Zeker omdat met de echte realisatie lang wordt gewacht, n.l. pas nadat de analyse en ontwerp op papier zijn afgerond. In de praktijk betekent dat ongeveer 50% tot 70% van het totale traject! Managers zullen dat zeker als een nadeel beschouwen, dus dat betekent dat er erg grote voordelen aan moeten zitten om die methodes te gebruiken.

2.2.1. Systeem ontwikkeling als communicatie middel Bij het gebruik van dergelijke methodes kan op papier eenduidig worden vastgelegd wat het systeem moet gaan doen en hoe. Vroeger werd dit vaak met tekst gedaan, maar het nadeel van tekst is dat deze juist niet eenduidig is. Verschillende mensen kunnen zo'n tekst verschillend interpreteren, met alle gevolgen van dien.

��

��

Met de opdrachtgever communiceren is erg belangrijk, want deze heeft in eerste instantie vaak slechts globaal aangegeven wat hij wil. Vaak weet hij het zelf ook nog niet precies. In de analyse fase wordt samen met de opdrachtgever precies vastgelegd wat het systeem gaat doen. Dit betekent overigens dus ook dat de opdrachtgever blijkbaar in staat moet zijn om de ontwikkelde diagrammen te lezen. Ook zal in deze fase duidelijk worden welke eisen er allemaal aan het te bouwen systeem gesteld worden. Een aantal van deze eisen zijn voor de opdrachtgever n.l. zo vanzelfsprekend dat ze vaak niet eens genoemd worden.

Ook met de mede ontwerpers communiceren is belangrijk en lang niet altijd eenvoudig. In een groot project zijn vaak ontwerpers actief met een verschillende achtergrond en daardoor ook een verschillend vakjargon. De gebruikte diagrammen zou je kunnen zien als een universele taal die alle ontwerpers spreken.

Het is ook eenvoudiger om veranderingen aan te brengen in een papieren ontwerp, dan in een gedeeltelijk gerealiseerd ontwerp. Gedurende het traject veranderen vaak de inzichten van zowel de opdrachtgever als de opdrachtnemer(s), waardoor veranderingen in de functionaliteit en/of de realisatie eerder regel dan uitzondering zijn. Zolang nog niet met de realisatie is begonnen zijn deze veranderingen vaak ook tegen beperkte kosten door te voeren. Wel dient te worden opgemerkt dat veranderingen in de functionaliteit zo vroeg mogelijk moet worden geconstateerd. Als de ontwerpfase al ver is gevorderd zijn dergelijke veranderingen toch vaak kostbaar.

Tenslotte heeft men na de realisatie van het systeem goede documentatie gegenereerd betreffende het opgeleverde systeem. Hierdoor zijn ook wijzigingen in de toekomst eenvoudiger. Zeker als de wijzigingen door een andere opdrachtnemer dienen te worden uitgevoerd.

Samenvattend kan worden geconcludeerd dat het een communicatie middel is in drie richtingen:

1. tussen opdrachtgever en opdrachtnemer

2. tussen de verschillende (deel)ontwerpers

3. naar de toekomst toe voor toekomstige wijzigingen

2.2.2. Systeem ontwikkeling als 'denk-tool' Het gebruik van dergelijke methodes heeft nog een ander voordeel. Complexe systemen ontwerpen wordt eenvoudiger door bepaalde technieken te gebruiken, n.l..:

1. Het totale systeem opdelen in blokken en de blokken apart ontwerpen

2. Details in eerste instantie weglaten en pas later invullen.

Beide technieken zijn verwerkt in de methode, waardoor de ontwerper geholpen wordt om zich eerst op de belangrijke hoofdzaken te concentreren, en pas later op de details.

��

��

3. De methode: een combinatie van Yourdon en UML Er zijn verschillende methodes en technieken om toe te passen tijdens een systeem ontwikkelingstraject. In dit dictaat is gekozen voor een combinatie van Yourdon en UML. Hiervoor zijn een aantal redenen:

1. De gekozen combinatie is redelijk eenvoudig en daarom geschikt om mee te beginnen.

2. Yourdon is een oudere methode die nog veel gebruikt wordt. Het enige nadeel is dat de methode niet objectgeorienteerd is. Er zijn echter een aantal diagrammen die in de eerste fase heel nuttig zijn.

3. UML wordt steeds meer de standaard ontwikkelset. UML tracht vooral eenduidigheid te scheppen in de gebruikte symbolen bij diagrammen. UML is ook sterk objectgeorienteerd.

4. Door de combinatie is het eerste stuk (analysefase) zowel geschikt voor hardware als software. Deze fase is vooral gebaseerd op Yourdon, alleen wordt voor de statemachine de notatiewijze van UML gehanteerd. In de ontwerpfase, die vooral bedoeld is voor software, worden de verschillende objecten bepaald en ontworpen.

3.1. Eigenschappen van de methode De methode heeft een aantal eigenschappen, die van belang zijn voor het ontwikkelen van systemen.

3.1.1. Gebruik van diagrammen De methode maakt intensief gebruik van diagrammen, waarin de functionaliteit van het te systeem grafisch wordt voorgesteld. De reden hiervoor is dat wij, mensen, veel beter in staat zijn om plaatjes te interpreteren, dan tekst (in tegenstelling tot computers!). Aangezien de methode ook vooral een communicatie-tool is, is dat natuurlijk erg belangrijk.

Ook dienen de schema's die opgesteld worden goed door 'leken' te kunnen worden gelezen. Zo moet ook de opdrachtgever in staat zijn te zien welke functionaliteit beschreven wordt, en ook de verschillende projectleden moeten het daarover met elkaar eens zijn.

3.1.2. Uitgaan van 'perfecte' technologie In de eerste fase (analyse fase) dient men uit te gaan van perfecte technologie bij het beschrijven van de functionaliteit. Dit betekent dat voorlopig de technologie de volgende eigenschappen heeft:

• oneindig snel

• oneindig betrouwbaar

• oneindig nauwkeurig

• etc.

��

�� !

De reden hiervoor is dat bij het beschrijven van de functionaliteit men niet gehinderd dient te worden door de gebrekkigheid / beperkingen van bestaande technieken. Eerst dient men zich te concentreren op wat echt gewenst is, vervolgens moet besloten worden hoe snel en betrouwbaar het systeem dient te zijn. Dan pas wordt techniek gekozen zodat duidelijk wordt hoe snel en betrouwbaar het gebouwde systeem zal zijn. Het is duidelijk dat dit oha. een kosten/baten verhaal is. Grotere snelheid en/of grotere betrouwbaarheid brengen meestal ook hogere kosten met zich mee en dit dient gerechtvaardigd te zijn.

Dit betekent ook dat storingsgedrag in eerste instantie niet meegenomen wordt. Pas als de functionaliteit bekend is wordt dit in de ontwerpfase meegenomen.

Uitgaan van perfecte technologie brengt een vereenvoudiging met zich mee. Details worden hierdoor in eerste instantie weggelaten en pas later ingevuld. Hierdoor zijn ook zeer complexe systemen goed te ontwerpen.

3.2. Stappen waaruit de methode bestaat De gehele methode bestaat uit een aantal stappen:

0. Opstellen globale opdracht/doelstelling. Dit wordt meestal gedaan door de opdrachtgever, en dit is de eerste input voor de opdrachtnemer om te starten met de analysefase.

1. Opstellen context diagram en scenario’s. Opdrachtgever stelt in overleg met de opdrachtgever het context diagram op. Dit diagram geeft de grens weer tussen het te bouwen systeem en zijn omgeving. Tevens worden een aantal scenario’s beschreven waarin globaal wordt beschreven hoe het systeem zich gedraagt.

2. Opstellen event/response list. Alle gebeurtenissen in de omgeving waarop het te bouwen systeem moet reageren worden opgesteld inclusief de gewenste respons (en binnen welke tijd!). Samen met het context diagram levert dit een eenduidige beschrijving van de gewenste functionaliteit.

3. Opstellen statemachine. De producten van stap 1 en 2 worden nader uitgewerkt in een statemachine(s). De elektrotechnicus houdt zich vooral bezig met besturen, en hierbij kunnen systemen goed beschreven worden met statemachines.

4. Opstellen interactie met gebruiker. In deze stap wordt de interface met de mens ontworpen. Dit is de eerste stap van de ontwerpfase. Mens-machine communicatie verlangt nou eenmaal extra aandacht.

5. Opstellen globaal classe diagram. Hierbij wordt op basis van het context diagram en de statemachines een eerste opzet van de verschillende classes (softwaremodules) opgesteld.

6. Opstellen sequentiediagrammen. De statemachine(s) van stap 3 worden vertaald in sequentiediagrammen, waarbij de samenwerking van de classes van stap 5 duidelijker wordt. Meestal resulteert dit ook in een verdere invulling van de verschillende classes.

7. Opstellen PSD’s. De verschillende functies die nu in de classes beschreven zijn, kunnen nu verder worden ingevuld met behulp van Programma Structuur

��

�� "

Diagrammen (PSD’s). Dit wordt (uiteraard) alleen gedaan voor de complexere functies.

Stap 1 t/m 3 is de analysefase en is geschikt voor zowel hardware als software. Stappen 4 t/m 7 zijn bedoeld om de softwarecomponent te ontwerpen. Voor andere systemen volgen hier andere stappen voor het ontwerpproces.

Zoals eerder vermeld worden in dit eerste deel de stappen 1 t/m 3 en stap 7 beschreven. De overige stappen komen in het 2de deel aan bod.

3.3. Voorbeeld: thermostaat regeling Het wordt tijd om eens een voorbeeld te bekijken. In dit voorbeeld wordt niet getoond hoe de diagrammen zijn opgesteld, alleen het resultaat. Ook worden de diagrammen en symbolen niet verder uitgelegd (dit gebeurt verderop in het dictaat). Hiermee wordt meteen getest in hoeverre de diagrammen inderdaad door leken te lezen zijn.

Bij dit voorbeeld, wat verderop in het dictaat regelmatig zal terugkeren, is sprake van een thermostaatregeling. Deze regeling dient een kamer op een ingestelde temperatuur te houden. Reeds beschikbaar is een ketel waarmee de kamer verwarmd kan worden en een thermometer waarmee de temperatuur kan worden gemeten. De ketel kan met twee niveaus worden aangestuurd, en de bedoeling is dat de ketel laag wordt aangestuurd als de gewenste temperatuur bijna bereikt is.

3.3.1. Context diagram en dictionary Als eerste diagram is er het context diagram (figuur 3.1). Dit diagram toont de grens tussen het te bouwen systeem en zijn omgeving.

Figuur 3.1: Context Diagram Temperatuur Regeling

Op deze figuur is te zien dat de operator een gewenste temperatuur aan het systeem kan opgeven, dat een thermometer de temperatuur levert aan het systeem, en dat deze tenslotte de ketel aanstuurt met een ketelsignaal.

Temp

Regeling

OPERATOR

THERMOMETER

KETEL

gewenste temperatuur

temperatuur ketelsignaal

��

�� #

Bij de vermelde signalen hoort de volgende dictionary:

signaal beschrijving bereik

gewenste temperatuur de door de operator ingestelde egeltemperatuur

5-30 graden Celsius

ketelsignaal hiermee wordt de ketel aan en uit gezet uit / laag / hoog

temperatuur de door de thermometer gemeten temperatuur 0 – 60 graden Celsius

Naast het context diagram wordt een scenario opgesteld. Zo’n scenario beschrijft globaal de functionaliteit van het systeem. In dit geval is een grafiek van de aansturing het duidelijkst (zie figuur 3.2).

Figuur 3.2: Aanstuurgrafiek temperatuurregeling

3.3.2. Event/Response List Vervolgens wordt een event/response list opgesteld: Nr Event Respons State 1 Operator stelt nieuwe temperatuur in Temperatuur wordt opgeslagen en

gebruikt Nee

2 Temperatuur stijgt tot ½ graad onder de gewenste temperatuur

Ketel wordt laag aangestuurd Ja

3 Temperatuur stijgt tot ½ graad boven gewenste temperatuur

Ketel wordt uitgezet Ja

4 Temperatuur daalt tot ½ graad onder gewenste temperatuur


5 Temperatuur daalt tot 1 graad onder de gewenste temperatuur

Ketel wordt hoog aangestuurd Ja

Tabel 3.1: Event/Respons List van temperatuurregeling

gewenst

H L U L H L

tijd

temp

gewenst – ½

gewenst – 1

gewenst + ½

��

�� $

3.3.3. Statemachine De ERL (Event/Respons List) wordt vervolgens vertaald in de statemachine van figuur 3.2.

Figuur 3.2: Statemachine temperatuurregeling

3.3.4. Interactie met gebruiker In deze case is de interactie met de mens minimaal. Het enige is de operator die een gewenste temperatuur dient in te stellen. Hiervoor kan bijvoorbeeld een potmeter met een schaalverdeling worden gebruikt. Via deze potmeter kan dan een variabele spanning aangeboden worden aan het besturende orgaan, bijvoorbeeld een microcontroller.

3.3.5. Globaal classe diagram Er worden 3 classes gedefinieerd die overeenkomen met de terminators (rechthoeken) van het context diagram (figuur 3.3). Tevens worden uit de voorliggende gegevens bruikbare functies afgeleid:

Figuur 3.3: Globaal classediagram temperatuurregeling

WACHTEN

VERWARMEN

LAAG

VERWARMEN

HOOG

temp < gewenst – ½ / ketel signaal = laag

temp < gewenst – 1 / ketel signaal = hoog

temp > gewenst – ½ / ketel signaal = laag

temp > gewenst + ½ / ketel signaal = uit

Operator +gewensteTemp(): double

Thermometer +temp(): double

Ketel +stuurHoog() +stuurLaag() +stuurUit()

��

�� %

3.3.6. Sequentie Diagrammen In deze stap wordt de statemachine omgezet in een sequentiediagram. Hierin wordt duidelijk hoe de verschillende classes samenwerken om de gewenste functionaliteit te bereiken.

Figuur 3.4: Sequentie Diagram Temperatuurregeling

3.3.7. PSD’s In deze stap kan van het hoofdprogramma en enkele belangrijke functies een PSD worden opgesteld. Bij deze temperatuurregeling is één PSD gemaakt: van het hoofdprogramma.

PROG :Operator :Thermometer :Ketel

gewensteTemp()

temp()

stuurHoog()

��

�� &

Figuur 3.5: PSD Hoofdprogramma Temperatuurregeling

state = WACHTEN

oneindige lus

gewenst = Operator.gewensteTemp()

temp = Thermometer:gewensteTemp()

state = WACHTEN en temp < gewenst – ½? Nee Ja

Ketel:stuurLaag()

state = LAAG

state = LAAG en temp > gewenst + ½? Nee Ja

Ketel:stuurUit()

state = WACHTEN

state = LAAG en temp < gewenst - 1½? Nee Ja

Ketel:stuurHoog()

state = HOOG

state = HOOG en temp > gewenst - ½? Nee Ja

Ketel:stuurLaag()

state = LAAG

��

��'��(��

4. Context Diagram & Scenario’s Wanneer de opdrachtgever een eerste globale beschrijving heeft gegeven, kan begonnen worden met het opstellen van een context diagram. Het context diagram plaatst het te bouwen systeem in zijn directe omgeving. Hiermee wordt duidelijk met welke andere systemen het nieuwe systeem communiceert, en welke informatie hiermee wordt uitgewisseld.

Tevens kunnen scenario’s worden geschreven waarin in ‘gewone mensentaal’ wordt beschreven wat het systeem doet. Zo’n scenario is meestal niet helemaal exact, maar wordt gebruikt om een idee te krijgen van gebeurtenissen in de loop der tijd.

Het is niet altijd zo dat er eerst een context diagram wordt opgesteld en vervolgens scenario’s. De volgorde hangt een beetje af van het te bouwen systeem, en ook van de voorkeur van de ontwerper. Als output van deze eerste stap dienen in ieder geval beide aanwezig te zijn.

4.1. De symbolen van een context diagram Op het context diagram wordt het volgende weergegeven (zie figuur 4.1):

• het te bouwen systeem: het hoofdproces

• de systemen waarmee gecommuniceerd wordt: de terminators

• de informatie en besturing die het te bouwen systeem in en uit gaat: de flows In de volgende paragraven wordt op deze onderdelen dieper ingegaan.

4.1.1. Het Hoofdproces Het te bouwen systeem wordt weergegeven als een cirkel, met daarin een naam die het systeem beschrijft. Het systeem vervult een bepaalde functionaliteit, en vaak is het nuttig om de naam ook op deze functionaliteit te baseren.

In figuur 4.1 zijn een aantal voorbeelden gegeven.

Figuur 4.1: Enkele voorbeelden van hoofdprocessen

Temp

Regeling

Robot

Besturing

Theezakjes

Vullen

��

��'��(��

4.1.2. De Terminators Terminators behoren niet tot het te bouwen systeem, maar geven elementen weer waarmee het systeem moet communiceren. Zo zal b.v. een operator die het systeem moet bedienen als terminator verschijnen. Maar ook andere onderdelen die door het systeem bediend dienen te worden, of die gegevens uit de omgeving doorgeven verschijnen als terminators in de diagrammen.

Terminators worden weergegeven als een rechthoek met een dikke omlijning.

Aangezien terminators elementen/objecten uit de omgeving weergeven bestaat de naam uit een zelfstandig naamwoord. Ook geldt voor de terminators dat de naam uniek dient te zijn. Komt een terminator tweemaal voor met dezelfde naam, dan dient deze te worden beschouwd als exact dezelfde terminator. Soms is dit laatste handig om een diagram overzichtelijk te houden. Er wordt dan een astrix gebruikt (*) om aan te geven dat de naam meerdere malen voor komt.

In figuur 4.2 worden een aantal voorbeelden van terminators gegeven.

Figuur 4.2: Enkele voorbeelden van Terminators

4.1.3. Flows Objecten en informatie worden getransporteerd over flows. Hierbij moet erg veel worden opgevat als een flow. Niet alleen data die in verband wordt gebracht met computersystemen, maar ook een muntstuk of een product kan worden getransporteerd over een flow.

Het getransporteerde element is een object of bepaalde informatie en heeft om deze reden een zelfstandig naamwoord als naam. Er kan geen werkwoord worden gekozen, omdat de flow zelf geen activiteit voorstelt. Het is een passief iets waar pas binnen een (data) proces iets mee gedaan kan worden.

Er moet ook worden opgelet dat de namen van flows uniek dienen te zijn. Als twee flows dezelfde naam hebben, dan stellen ze ook fysiek dezelfde flow voor. Dit kan soms handig zijn om kruisende lijnen te voorkomen. Wel wordt er dan bij zo’n flow een asterix (*) gezet om de lezer er op te attenderen dat deze flow meerdere malen getekend is.

Er zijn twee soorten flows:

• Data flows: over deze flows kunnen fysieke zaken worden getransporteerd, of data die door computers kan worden bewerkt en opgeslagen. Deze flows worden als een enkele doortrokken lijn getekend.

• Control flows: ook hier betreft het informatie die door computersystemen wordt bewerkt, alleen wordt op basis van deze informatie een besturingsbeslissing

THERMOMETER KLANT SORTEER SYSTEEM

��

��'��(��

genomen. Deze flows hebben ook altijd maar een beperkt aantal waarden, b.v.: “waar / niet waar” of “laag / midden / hoog”. Deze flows worden getekend als een stippellijn.

Er kunnen dus ook flows getekend worden waarover fysieke zaken worden getransporteerd. Dit gebeurt vooral als het te bouwen systeem ook werktuigbouwkundige zaken bevat, zoals transportbanden e.d.

In figuur 4.3 zijn enkele voorbeelden van flows gegeven.

Figuur 4.3: Enkele voorbeelden van flows

4.2. Opstellen context diagram Zoals eerder gezegd, het context diagram beschrijft het systeem in relatie tot zijn omgeving.

4.2.1. Wanneer is iets een terminator? De terminators die verschijnen op het context diagram zijn geen onderdeel van het systeem, maar zijn objecten in de omgeving van het systeem waar het systeem mee communiceert. Deze objecten kunnen personen zijn of apparaten.

Er zijn uiteraard veel objecten in de omgeving van het systeem, maar als het systeem er niets mee te maken heeft, verschijnt het ook niet op het context diagram! Ook communicatie tussen terminators waar het systeem geen kennis van heeft, dient ook weggelaten te worden. Er worden dus alleen maar pijlen getekend tussen de procesbol en de terminators.

Een voorbeeld hiervan is gegeven in figuur 4.4. In deze figuur levert een systeem frisdranken aan een klant. De frisdrankautomaat wordt bijgevuld door een operator, maar het systeem heeft hier verder niets mee te maken. Het systeem weet alleen dat de frisdrank op is (m.b.v. de aangegeven controlflow).

temperatuur

munt

produkt op

start/stop

��

��'��(��

Figuur 4.4: Context diagram frisdrank automaat

Om deze reden is het tekenen van zowel de operator als de flow 'Blikjes' voor het te bouwen systeem niet van belang. Ook het feit dat de blikuitwerper een blikje levert aan de klant is niet van belang (tenminste: niet voor de ontwerper van het Frisdrank Systeem!). Dus ook deze pijl kan worden weggelaten. Op deze wijze ontstaat dan het contextdiagram van figuur 4.5.

Figuur 4.5: Correct context diagram frisdrank automaat

4.2.2. Systemen hebben altijd output Geen enkel systeem opereert volledig onafhankelijk van zijn omgeving. Als er uit een systeem niets komt ten behoeve van deze omgeving, dan heeft zo'n systeem geen nut en dus geen bestaansrecht.

Als voorbeeld is in figuur 4.6 een eerste versie gemaakt van een Jukeboxsysteem. De opdrachtgever wil een systeem kopen, waarbij de klant munten kan inwerpen en een aantal nummers kan kiezen. De Jukebox speelt vervolgens deze nummers achtereenvolgens af.

Frisdrank Systeem

KLANT munt

buiten werking

BLIKUITWERPER

blik-trigger

blikjes op

Frisdrank Systeem

KLANT munt

buiten werking

BLIKUITWERPER

blik-trigger

OPERATOR

blikjes op

blikjes

blikje

��

��'��(�� !

Figuur 4.6: Vreemd context diagram Jukebox

Omdat er geen uitgaande pijlen zijn, is dit systeem zeer goedkoop te maken:

• Pak een schoenendoos en maak er een gleuf in waar de klant zijn munten in kan stoppen.

• Plak een toetsenbordje erop voor de selectie

Klaar! Verder hoeft het systeem volgens het context diagram namelijk niets te doen!

Wat ontbreekt is de weergave van wat de klant terugkrijgt in ruil voor zijn geld. Wat dat dan is? Muziek! Het juiste context diagram is weergegeven in figuur 4.7.

Figuur 4.7: Juist context diagram Jukebox

Nou lijkt dit onnozel, omdat iedereen begrijpt dat een Jukebox muziek moet produceren. Maar in praktijk is het juist dat zaken die voor de ene partij vanzelfsprekend zijn, soms voor de andere partij dat juist niet zijn. Zo kan een belangrijke communicatiestoornis optreden, die vervelende gevolgen kan hebben.

4.3. Opstellen van de dictionary Bij een context diagram wordt ook een dictionary opgesteld. Deze geeft extra informatie over de flows die op het context diagram worden weergegeven. Ondanks het feit dat de

Juke Box

KLANT *

munt

selektie

KLANT *

muziek

Juke Box

KLANT

munt

selektie

��

��'��(�� "

namen van de flows zo duidelijk mogen (dienen te) zijn, is het goed om eenduidig te vertellen wat de flows precies bevatten. Deze dictionary komt in een tabel te staan met drie gegevens:

• De naam van de flow • Een nadere beschrijving • Het bereik: welke waardes kan de flow aannemen

In tabel 4.1 is als voorbeeld de dictionary van bovenstaande Jukebox gegeven. signaal beschrijving bereik

munt muntstukken die door de klant worden ingeworpen

5 cent / 10 cent / 20 cent / 50 cent / 1 euro / 2 euro

muziek de muziek uit de luidsprekers van de Jukebox n.v.t.

selectie het nummer dat de klant wil horen CD disk (1 t/m 10) en nummer van de CD (1 t/m 20)

Tabel 4.1: dictionary van de Jukebox

4.4. Opstellen van een scenario Bij het opstellen van scenario(‘s), wordt getracht gedrag van het systeem te beschrijven aan de hand van één of meer stappenplannen. Puntsgewijs wordt beschreven in welke volgorde, tengevolge van wat voor gebeurtenissen, het systeem acties onderneemt. Verschillende situaties kunnen in eerste instantie in verschillende scenario’s worden beschreven. Vervolgens kan er gekeken worden of twee of meer scenario’s te combineren zijn door bijvoorbeeld een beslissing/keuze te maken.

Deze scenario’s zijn eigenlijk een eerste versie van de event/respons list en de statemachine van stappen hierna. Het is dan ook niet noodzakelijk om de volle 100% van de functionaliteit in deze stap te vangen. Het gaat er om dat de verschillende partijen (opdrachtgever en ontwerper(s)) het eens zijn over de globale functionaliteit.

4.5. De temperatuurregeling

4.5.1. De opdrachtomschrijving De opdrachtgever wil een temperatuurregeling ontworpen hebben, die een ruimte op een ingestelde temperatuur houdt. De hardware voor een dergelijke regeling heeft hij reeds aangeschaft, het gaat bij de opdracht vooral om de besturing.

Reeds beschikbaar is een ketel waarmee de kamer verwarmd kan worden en een thermometer waarmee de temperatuur kan worden gemeten. De ketel kan met twee niveaus worden aangestuurd (laag en hoog), en de bedoeling is dat de ketel laag wordt aangestuurd als de gewenste temperatuur op een graad na bereikt is. Is de afwijking groter, dan dient de ketel hoog te worden aangestuurd. Uiteraard gaat de ketel uit als de gewenste temperatuur bereikt is. Om ‘flipperen’ van de regeling te voorkomen moet er gebruik gemaakt worden van drempelwaarden.

��

��'��(�� #

4.5.2. Context diagram Uit de opdrachtomschrijving blijkt dat er drie elementen zijn waarmee het systeem dient te communiceren. Deze zijn:

• de operator die de gewenste temperatuur instelt.

• de thermometer waarmee de temperatuur gemeten wordt.

• de ketel voor het verwarmen van de ruimte.

Als deze zaken in een context diagram worden geplaatst, dan ontstaat figuur 4.8.

Figuur 4.8: Context diagram van temperatuurregeling

Bij dit context diagram hoort de dictionary van tabel 4.2. signaal beschrijving bereik

gewenste temperatuur de door de operator ingestelde regeltemperatuur

5-30 graden Celsius

ketelsignaal hiermee wordt de ketel aan en uit gezet uit / laag / hoog

temperatuur de door de thermometer gemeten temperatuur 0 – 60 graden Celsius

Tabel 4.2: Dictionary van de temperatuurregeling

4.5.3. Scenario De ketel dient op twee niveaus te worden aangestuurd. Tevens dient ‘flipperen’ voorkomen te worden, dus worden drempelwaardes gehanteerd. In onderstaande figuur is aangegeven hoe de temperatuur in de loop der tijd reageert. Met de vakken is daarin aangegeven hoe dan de aansturing van de ketel dient te zijn (Hoog, Laag, Uit).

Temp

Regeling

OPERATOR

THERMOMETER

KETEL

gewenste temperatuur

temperatuur ketelsignaal

��

��'��(�� $

Figuur 4.9: Temperatuurverloop en aansturing ketel

In plaats van een tekstueel scenario is ook een dergelijke figuur een bruikbare vorm te beschrijven hoe het systeem zich dient te gedragen.

4.6. De parkeergarage

4.6.1. De opdrachtomschrijving Dit voorbeeld is aanzienlijk complexer dan de thermostaat regeling. De opdrachtgever heeft de volgende beschrijving opgesteld:

Ik wil een systeem kopen voor het automatiseren van een parkeergarage. De parkeergarage heeft een capaciteit van 500 auto's en er is sprake van één ingang en één uitgang. Beide zijn beveiligd met een slagboom. De bestuurders kunnen aan de ingang een ticket krijgen, waarna ze de parkeergarage binnen kunnen. Voordat ze de garage verlaten dienen ze te betalen bij de betaalautomaat (1 euro voor elk kwartier). De slagbomen voor de in- en uitgang zijn reeds aanwezig, inclusief sensoren in het wekdek voor en achter de slagboom. De betaalautomaat en kaartlezers dienen mee geleverd te worden.

4.6.2. Scenario’s Er is binnen dit systeem sprake van drie verschillende klanten, namelijk:

1. een klant bij de ingang

2. een klant bij de betaalautomaat

3. een klant bij de uitgang

Voor alle drie de klanten kan een scenario worden opgesteld:

gewenst

H L U L H L

tijd

temp

gewenst – ½

gewenst – 1

gewenst + ½

��

��'��(�� %

Klant bij de ingang:

• klant komt aanrijden bij de parkeergarage

• hij drukt op de knop ‘ticket’

• hij krijgt een kaartje en de slagboom v/d ingang gaat open

• hij rijdt naar binnen

• de slagboom gaat weer dicht

Klant bij de betaalautomaat:

• klant stop zijn kaartje in de betaalautomaat

• het te betalen bedrag verschijnt op het display

• de klant werpt het verschuldigde bedrag in, totdat het te betalen bedrag 0 is

• de klant krijgt zijn kaartje terug

Klant bij de uitgang:

• klant komt aanrijden bij de uitgang

• hij stopt zijn kaartje in de kaartlezer die daar staat

• als hij voldoende betaald heeft gaat de slagboom open, anders krijgt hij het kaartje terug

• de klant rijdt naar buiten

• de slagboom gaat weer dicht

4.6.3. Context diagram Er is sprake van een aantal terminators. Allereerst hebben we de ingang en de uitgang. Deze twee terminators krijgen allebei een signaal (controlflow) om de slagboom aan te sturen en geven twee control flows terug voor de sensoren voor en achter de slagboom. Om het aantal flows te beperken nemen we deze twee control flows samen.

Vervolgens hebben we de klant als terminator. De klant komt echter op drie plaatsen voor:

1. aan de ingang

2. aan de uitgang

3. bij de betaalautomaat

Om verwarring te voorkomen gebruiken we hiervoor ook drie terminators.

Op basis hiervan komen we tot het contextdiagram zoals weergegeven in figuur 4.10.

��

��'��(�� &

Figuur 4.10: Eerste context diagram parkeergarage

De bijbehorende dictionary is te vinden in tabel 4.3.

signaal beschrijving bereik

bedrag het nog te betalen bedrag 0 – 100 euro

euro fysieke euromunt -

knop ‘ticket’ klant vraagt ticket bij de ingang aan / uit

sensor achter ingang detectie auto achter ingangsslagboom aan / uit

sensor achter uitgang detectie auto achter uitgangsslagboom aan / uit

sensor voor ingang detectie auto voor ingangsslagboom aan / uit

sensor voor uitgang detectie auto voor uitgangsslagboom aan / uit

sensoren ingang sensor voor ingang + sensor achter ingang -

sensoren uitgang sensor voor uitgang + sensor achter uitgang -

slagboom ingang signaal om slagboom open/dicht te doen open / dicht

slagboom uitgang signaal om slagboom open/dicht te doen open / dicht

ticket betaald fysiek magneetkaartje uit betaalautomaat -

ticket ingang nieuw fysiek magneetkaartje -

ticket onbetaald fysiek magneetkaartje in betaalautomaat -

ticket uitgang fysiek magneetkaartje bij uitgang -

Tabel 4.3: Dictionary parkeergarage

Parkeer-

Garage

INGANG

KLANT INGANG

KLANT BETALEN

KLANT UITGANG

UITGANG

knop ‘ticket’

ticket ingang

sensoren ingang

slagboom ingang

slagboom uitgang

sensoren uitgang

ticket uitgang

ticket betaald

euro

bedrag

ticket onbetaald

��

��'��(��

In dit context diagram zijn nog een aantal materiaal-flows aanwezig. In deze case is het nu zo dat al in een vroeg stadium besloten wordt om standaard hardware te kopen om hierin te kunnen voorzien. Er ontstaat dan een aangepast context diagram met nieuwe terminators, die zich concentreert op de besturing.

Er dient hardware gekozen te worden die met tickets kan omgaan, en een geldinwerper die op zijn minst euro’s accepteert. De volgende hardware wordt na overleg met de opdrachtgever gekozen:

1. Een ticketdrukker die uit een voorraad tickets een nieuw ticket naar buiten geeft, voorzien van een magneetstrip met daarop een uniek nummer. Deze ticketdrukker krijgt als ingang een data flow met ticket nummer.

2. Een ticketlezer die de tickets kan lezen en het nummer teruglevert aan het systeem. Tevens kan met een controlflow het ticket worden teruggeven of juist worden vernietigd. Deze ticketlezer komt op twee plaatsen voor, n.l. bij de betaalautomaat en bij de uitgang.

3. Een muntlezer die euro’s accepteert en andere munten direct teruggeeft. Deze geeft alleen een control flow af dat een euro is gedetecteerd.

Als we dit doorvoeren ontstaat het contextdiagram van figuur 4.11. Hier zijn voor de duidelijkheid de oude terminators nog weergegeven en ook de materiaal flows tussen de terminators. Op deze wijze is de relatie met de vorige versie goed te zien.

Figuur 4.11: Context diagram met extra terminators Zoals je kunt zien is dit diagram nogal groot en daardoor al redelijk complex. In figuur 4.12 is het uiteindelijke contextdiagram te zien, waarbij alleen nog de terminators getoond worden die direct communiceren met ons systeem. Ook zijn nu alle materiaal flows weggelaten.

Parkeer-

Garage

INGANG

KLANT INGANG

LEZER BETALING

KLANT UITGANG

UITGANG

knop ‘ticket’ nieuw

nummer

sensoren ingang

slagboom ingang

slagboom uitgang

sensoren uitgang

nummer uitgang

bedrag ticket

onbetaald

TICKET DRUKKER

ticket ingang

LEZER UITGANG ticket uitgang

ticket retour

aktie uitgang

KLANT BETALEN

nummer betaling aktie betaling

MUNTLEZER

munt

euro

ticket betaald

��

��'��(��

Figuur 4.12: Definitieve versie context diagram In tabel 4.4 is tenslotte de uiteindelijke dictionary gegeven. signaal beschrijving bereik

bedrag het nog te betalen bedrag 0 – 100 euro

euro fysieke euromunt -

knop ‘ticket’ klant vraagt ticket bij de ingang aan / uit

sensor achter ingang detectie auto achter ingangsslagboom aan / uit

sensor achter uitgang detectie auto achter uitgangsslagboom aan / uit

sensor voor ingang detectie auto voor ingangsslagboom aan / uit

sensor voor uitgang detectie auto voor uitgangsslagboom aan / uit

sensoren ingang sensor voor ingang + sensor achter ingang -

sensoren uitgang sensor voor uitgang + sensor achter uitgang -

slagboom ingang signaal om slagboom open/dicht te doen open / dicht

slagboom uitgang signaal om slagboom open/dicht te doen open / dicht

ticket betaald fysiek magneetkaartje uit betaalautomaat -

ticket ingang nieuw fysiek magneetkaartje -

ticket onbetaald fysiek magneetkaartje in betaalautomaat -

ticket uitgang fysiek magneetkaartje bij uitgang -

Tabel 4.4: Dictionary van de parkeergarage

Parkeer-

Garage

INGANG

KLANT INGANG

LEZER BETALING

UITGANG

knop ‘ticket’

nieuw nummer

sensoren ingang

slagboom ingang

slagboom uitgang

sensoren uitgang

nummer uitgang

bedrag

TICKET DRUKKER

LEZER UITGANG

aktie uitgang

KLANT BETALEN

nummer betaling aktie betaling

MUNTLEZER

munt

��

��'��(��

5. De Event/Respons List (ERL)

5.1. Wat is de event list? Na het opstellen van het contextdiagram volgt het maken van de event list. De event list kan gezien worden als een nadere en precieze uitwerking van de scenario’s.

In deze event list wordt beschreven op welke gebeurtenissen in de omgeving van het systeem het systeem reageert. Ook wordt hierin aangegeven wat deze reactie is. Een gebeurtenis wordt een event genoemd, en een reactie een respons. De opsomming van al deze reacties op gebeurtenissen beschrijft eigenlijk de totale functionaliteit van het te bouwen systeem!

Een event list bestaat uit 3 onderdelen:

1. de event: de gebeurtenis waarop het systeem reageert

2. de respons: de reactie van het systeem op deze gebeurtenis

3. de classificatie: is deze event/respons een besturingsactiviteit of niet

Deze drie onderdelen worden in paragraaf 5.2 nader uitgespit. In tabel 5.1 is als voorbeeld de event list van de thermostaat regeling gegeven.

Nr Event Respons State 1 Operator stelt nieuwe temperatuur in Temperatuur wordt opgeslagen en

gebruikt Nee









Tabel 5.1: Event/Respons List van temperatuurregeling

5.2. De onderdelen van de event list

5.2.1. De event De event geeft de gebeurtenis aan waarop het systeem dient te reageren. Essentieel is dat deze gebeurtenis in de omgeving plaats vindt, en niet in het systeem zelf! Uiteraard vinden binnenin het systeem ook allerlei gebeurtenissen plaats, maar alleen reacties op de omgeving is van belang voor de functionaliteit.

Het systeem dient in staat te zijn om de gebeurtenis te detecteren, anders kan hij er immers ook niet op reageren. Een event heeft dus bijna altijd een relatie met één van de terminators. Is er echter toch een event waarop het systeem zou moeten reageren, maar kan hij deze nu niet detecteren, dan is dit een signaal dat het contextdiagram nog niet volledig is. Er zal in zo'n situatie iets extra's opgenomen (meestal een extra terminator) moeten worden waardoor de betreffende event wel kan worden gedetecteerd.

Sommige events hebben te maken met het verstrijken van tijd. Ook deze events worden gezien als events die in de omgeving plaats vinden. Het systeem zal natuurlijk straks

��

��'��(��

intern een timer o.e.d. gebruiken om dit te detecteren, maar het wordt niet gezien als een interne event. Bij zo'n event is de relatie met een terminator vaak wat moeilijker te zien, of soms zelfs helemaal niet aanwezig. Een voorbeeld van zo'n laatste event is deze:

Nr Event Respons State 1 Het is 12:00 Dagrapport printen Nee

Tabel 5.2: Event gebaseerd op tijd

5.2.2. De respons Met de respons wordt de reactie gegeven van het systeem. Ook deze reactie heeft iets te maken met de omgeving van het systeem. De opname van een event/respons in een event list heeft alleen maar betekenis als de respons ook een zogenaamde positieve respons is. Hiermee wordt bedoeld dat er inderdaad iets verandert aan de situatie. De volgende event/respons is bijvoorbeeld niet zinvol:

Nr Event Respons State 4 Temperatuur tussen ondergrens en

bovengrens Aansturing van ketel hetzelfde houden Nee

Tabel 5.3: Vreemde respons

Ook bij de respons geldt weer dat deze reactie ook door het systeem gegeven moet kunnen worden. Hij heeft dus iets te maken met een uitgaande pijl op het contextdiagram.

5.2.3. De state-classificatie Dit is de moeilijkste kolom. Deze kolom geeft aan of de betreffende event/respons de besturing van toestand (state) laat veranderen. Deze informatie is nodig als de ERL (event/respons list) wordt omgezet in een statemachine.

De kolom dient een ‘Ja’ te bevatten wanneer geldt dat deze event/repons sommige andere event/responses onmogelijk maakt of juist mogelijk maakt. M.a.w.: de verzameling event/responses die kunnen optreden is na deze event/respons anders dan ervoor.

Als voorbeeld wordt de event list van tabel 5.1 genomen. Event 3 kan pas optreden nadat event 2 is opgetreden. Event 2 kan vervolgens pas weer optreden nadat event 4 is opgetreden, etc. Oftewel: event 2 t/m 5 zorgen allemaal voor een verandering van state. Event 1 heeft geen invloed op de andere events, omdat men nu eenmaal altijd een nieuwe gewenste temperatuur moet kunnen instellen.

5.3. Het bouwen van een ERL Uit paragraaf 5.2 zijn drie eisen te halen waaraan een event/respons dient te voldoen. Ze worden hier voor alle volledigheid nog een keer genoemd:

1. De event dient in de omgeving van het systeem plaats te vinden, en niet binnen het systeem zelf.

2. De respons dient een positieve respons te zijn, er dient dus een verandering plaats te vinden.

3. De event moet gedetecteerd kunnen worden, en de respons moet gerealiseerd kunnen worden.

��

��'��(�� !

Bij het bouwen van een event list is het goed om een visuele voorstelling van het systeem te maken. Je moet als het ware in gedachte het systeem simuleren en proberen te bepalen op welke gebeurtenissen in de omgeving van het systeem gereageerd wordt, en wat deze reactie is. Hiervoor zijn ook de scenario’s nuttig die samen met het context diagram zijn opgesteld.

5.4. De controlematrix Na het bouwen van de ERL is het nuttig om een matrix te maken waarin de relatie tussen event/repons en flow van het context diagram wordt weergegeven. Voor de temperatuurregeling is deze in tabel 5.4 weergegeven.

Tabel 5.4: Controlematrix ERL

In deze tabel worden horizontaal de events getoond, en verticaal de verschillende flows van het contextdiagram: boven de dikke streep de ingangen, onder de dikke streep de uitgangen.

In de cellen wordt nu een kruisje gezet als de desbetreffende flow gebruikt wordt bij de desbetreffende event/respons. Het volgende moet dan gelden:

• elke flow wordt bij minimaal één event gebruikt, d.w.z.: er is op elke horizontale rij minimaal één kruisje.

• elke event maakt gebruik van minimaal één ingangsflow en elke respons van minimaal één uitgangsflow.

Als dit niet zo is, dan is er waarschijnlijk iets vergeten, of in het context diagram of in de event/respons list. Een uitzondering hierop is de event die alleen gebaseerd is op het verstrijken van de tijd: die heeft geen bijbehorende binnenkomende flow.

5.5. De parkeergarage Bij de parkeergarage zijn er drie plaatsen waar iets gebeurt. Dit zijn:

• de ingang, waar auto's aan komen rijen en naar binnen gaan

• de uitgang, waar auto's weer de parkeergarage verlaten

• de betaalautomaat, waar de klanten betalen

Van alle drie de deelsystemen worden de event/responses bepaald.

Event/ Flow

1 2 3 4 5

gewenste temp x temp x x x x ketelsignaal x x x x x

��

��'��(�� "

5.5.1. De ingang Bij de ingang gebeurt het volgende:

Een auto komt aanrijden en stopt voor de slagboom. De klant (automobilist) drukt op de knop 'Ticket' en krijgt een kaartje. De slagboom gaat open, waarna de auto de parkeergarage binnen rijdt. Hierna sluit de slagboom weer.

In deze beschrijving worden een aantal events genoemd en een aantal responses. De kunst is nu om deze hieruit te destilleren. De volgende events en responses kunnen hieruit gehaald worden:

• Event: auto voor ingang slagboom en knop 'Ticket' wordt ingedrukt. Respons: klant krijgt kaartje en slagboom gaat open.

• Event: auto passeert slagboom (sensor achter slagboom wordt actief). Respons: slagboom sluit weer.

Dit is de normale gang van zaken. Maar wat als de automobilist niet doorrijdt? De slagboom moet dan natuurlijk niet onbeperkt open blijven staan. We spreken af dat de automobilist b.v. 15 seconden de tijd krijgt om naar binnen te rijden. Dit levert het volgende op:

• Event: 15 seconden na openen slagboom en geen auto binnen gereden. Respons: slagboom gaat weer dicht.

En wat als een voorbijganger voor de grap op de knop 'Ticket' drukt? Het systeem moet dan eigenlijk niets doen. Omdat de respons leeg is levert dit geen event/respons op!

In tabel 5.5 zijn de hier genoemde event/responses te vinden als 1 t/m 3.

5.5.2. De uitgang Eerst bekijken we weer de normale gang van zaken:

De auto komt naar de slagboom van de uitgang gereden. Hij stopt zijn (betaalde) ticket in de automaat bij de uitgang en de slagboom gaat open. Vervolgens rijdt de auto naar buiten waarna de slagboom weer sluit.

Welke event/responses levert dit op? De volgende:

• Event: auto bij uitgang en ticket in automaat en ticket betaald. Respons: slagboom gaat open.

• Event: auto passeert slagboom van uitgang. Respons: slagboom gaat dicht.

Maar ook hier zijn weer een aantal uitzonderingen. Zo kan b.v. de klant niet betaald hebben. Uiteraard moet dan de slagboom niet open gaan. Het is dan goed om het kaartje weer terug te geven:

• Event: auto bij uitgang en ticket in automaat en ticket NIET betaald. Respons: kaartje terug geven.

Het kan ook zijn dat het ticket wel betaald is, maar dat geen auto bij de uitgang staat. Kaartje gewoon terug geven is dan een goede respons:

• Event: ticket in automaat bij uitgang maar geen auto bij uitgang. Respons: kaartje terug geven.

��

��'��(�� #

Merk op dat bij deze event eigenlijk niet belangrijk is of het kaartje betaald is of niet. Tenslotte hebben we nog de situatie dat de klant niet doorrijdt. Ook hier geven we de automobilist 15 seconden de tijd om naar buiten te rijden:

• Event: 15 seconden na openen slagboom en geen auto voorbij slagboom. Respons: slagboom sluiten en kaartje terug geven.

Ook hier is het dus handig om het kaartje dan maar terug te geven.

In tabel 5.5 zijn deze event/responses terug te vinden als 4 t/m 8.

5.5.3. De betaalautomaat Bij de betaalautomaat treedt het volgende op:

Een klant stopt zijn ticket in de betaalautomaat. Op de betaalautomaat wordt het verschuldigde bedrag zichtbaar (in guldens). De klant werpt nu voldoende guldens in, waarbij het bedrag steeds lager wordt. Als de klant voldoende betaald heeft wordt het bedrag 0 en krijgt de klant zijn betaalde ticket terug.

Ook hier moeten weer de event/responses van het systeem uit dit scenario gehaald worden. Dit levert het volgende op:

• Event: klant stopt ticket in automaat. Respons: te betalen bedrag wordt getoond.

• Event: klant werpt euro in (nog niet genoeg betaald). Respons: bedrag wordt lager.

• Event: klant werpt laatste euro in. Respons: bedrag wordt 0 en kaartje terug geven.

Hier zijn geen bijzondere situaties te ontdekken. De klant kan alleen maar het volledige bedrag betalen en niet eerder stoppen. In tabel 5.5 zijn ze terug te vinden als 9 t/m 11.

5.5.4. Controlematrix Nr Event Respons State 1 Sensor voor ingang actief en knop 'Ticket'

ingedrukt Geef kaartje en slagboom ingang gaat open

Ja

2 Sensor achter ingang actief (na event 1!) Slagboom dicht en kaartje opslaan in database

Ja

3 15 seconden na event 1 en sensor achter ingang niet actief

Slagboom ingang dicht en kaartje negeren Ja

4 Klant stop kaartje in automaat uitgang en sensor voor uitgang actief en klant heeft voldoende betaald

Slagboom uitgang gaat open Ja

5 Sensor achter uitgang actief (na event 4) Slagboom uitgang dicht en kaartje uit database verwijderen

Ja

6 Klant stop kaartje in automaat uitgang en sensor voor uitgang actief en klant heeft NIET voldoende betaald

Kaartje terug geven Nee

7 Klant stop kaartje in automaat uitgang en sensor voor uitgang NIET actief


8 15 seconden na event 6 en sensor achter uitgang niet actief

Slagboom uitgang dicht en kaartje terug geven

Ja

9 Klant stopt kaartje in betaalautomaat Bedrag tonen Ja 10 Munt inworp en nog niet genoeg betaald Nieuw bedrag tonen Nee 11 Munt inworp en nu wel genoeg betaald Bedrag op 0 zetten en kaartje terug geven Ja

Tabel 5.5: ERL van parkeergarage

��

��'��(�� $

In tabel 5.5 zijn de events opgenomen die gevonden zijn. In de laatste kolom is steeds aangegeven of sprake is van een verandering van state. Dit geeft, zoals eerder gezegd, aan dat de desbetreffende event/repons invloed heeft op andere event/responses.

Hieronder is een korte toelichting op deze kolom voor de parkeergarage:

1. Na [1] wordt [2] mogelijk, dus er is sprake van een state verandering.

2. Na [2] wordt [1] mogelijk.

3. Na [3] wordt weer [1] mogelijk.

4. Na [4] wordt [5] mogelijk.

5. Na [5] wordt [4] weer mogelijk.

6. Deze event/respons kan optreden als ook [4] kan optreden. Na deze event/respons is de situatie precies gelijk, dus geen state verandering.

7. Hiervoor geldt hetzelfde als voor [6].

8. Na [8] wordt weer [4] mogelijk.

9. Na [9] wordt [10] en [11] mogelijk.

10. Deze event/respons is na [9] mogelijk. Na deze event/respons is de situatie gelijk, dus geen state verandering.

11. Na [11] is [9] weer mogelijk.

Event/

Flow

1 2 3 4 5 6 7 8 9 10 11

knop ‘ticket’ x

sensoren ingang x x x

munt x x

nummer betaling x

nummer uitgang x x x

sensoren uitgang x x x x

slagboom ingang x x x

bedrag x x x

actie betaling x

actie uitgang x x x x

slagboom uitgang x x x

nieuw nummer x

Tabel 5.6: Controlematrix ERL parkeergarage De controletabel geeft aan dat er voor elke flow minimaal één event/respons is, en dat elke event/respons minimaal één ingaande flow heeft en minimaal één uitgaande flow. Alles lijkt dus in orde.

��

��'��(�� %

6. State diagrammen In dit hoofdstuk wordt beschreven hoe de besturing binnen wordt gemodelleerd. De meeste besturingen zijn te beschouwen als een statemachine, waarvan de functionaliteit goed te beschrijven is d.m.v. State diagrammen.

6.1. De elementen van een statemachine Een statemachine is opgebouwd uit een aantal elementen, weergegeven in figuur 6.1. In de volgende paragraven worden deze elementen behandeld.

Figuur 6.1: De elementen van een state machine

6.1.1. De state Als eerste is er de state. Een state is een toestand waar de besturing / systeem zich langere tijd in zal bevinden. De state wordt afgebeeld als een afgeronde rechthoek met daarin de naam van de state. Deze naam dient aan te geven wat het systeem op dat moment aan het doen is. Zo is b.v. in figuur 6.2 nogmaals de statemachine van de thermostaatregeling gegeven. Deze statemachine heeft drie states, n.l. 'WACHTEN' waarin hij wacht totdat het te koud is, en 'VERWARMEN HOOG' als het systeem de kamer aan het verwarmen is met een hoge aansturing van de ketel, en tenslotte ‘VERWARMEN LAAG’ als de ketel laag wordt aangestuurd.

Een statemachine kan zich altijd slechts in één state tegelijkertijd bevinden!

State

State

Conditie / Aktie

Transitie

��

��'��(�� &

Figuur 6.2: De statemachine van de temperatuurregeling

6.1.2. De transitie Een statemachine wisselt tussen twee states m.b.v. een transitie. Een transisitie wordt afgebeeld als een rechthoekige pijl tussen de twee states. De pijl loopt altijd één richting op.

Er is één aparte transitie, en dat is de initiële transisitie. Deze transisitie wordt afgebeeld met een pijl afkomstig van een zwarte bol, en deze geeft de state aan waarin de statemachine begint. In figuur 6.2 is dat dus de state 'WACHTEN'.

Uit een state kunnen meerdere transisities lopen naar andere states, maar wel moet steeds gelden dat ze elkaar uitsluiten. Er mag dus geen twijfel zijn welke transisitie in een bepaalde situatie gekozen wordt.

6.1.3. De conditie Naast een transitie wordt de conditie genoteerd. Deze conditie is een logische expressie die resulteert in ‘waar’ of ‘niet waar’. Als de expressie waar is dan springt de statemachine via deze transitie naar de aangegeven state.

Als er uit een state meerdere uitgaande transities zijn, dan dienen de condities zo zijn te geformuleerd dat er altijd maar één conditie waar is. Anders is niet duidelijk welke transisitie genomen wordt.

De logische expressie moet door de statemachine geëvalueerd kunnen worden. Dit betekent dat de logische expressie opgebouwd is uit de inkomende flows van het systeem. Het moet duidelijk zijn dat het systeem de aangegeven conditie kan detecteren.

6.1.4. De actie Naast de conditie van een transitie staan de eventuele acties die worden uitgevoerd tijdens deze transitie. Om de conditie te scheiden van de actie(s) wordt een schuine streep (/) geplaatst. Deze acties zijn klaar tegen de tijd dat de statemachine in de nieuwe state terecht komt. We praten tenslotte nog steeds over oneindig snelle technologie.

WACHTEN

VERWARMEN

LAAG

VERWARMEN

HOOG


temp < gewenst – 1 / ketel signaal = hoog

temp > gewenst – ½ / ketel signaal = laag


��

��'��(��

6.2. Omzetten event list naar een statemachine Bij het opstellen van de statemachine wordt alleen gekeken naar de event/responses waarbij de State-kolom een ‘Ja’ bevat. Hierbij levert elk van deze event/responses een transitie op van de statemachine. De states zelf moeten hieruit worden afgeleid, maar meestal is dat niet zo moeilijk omdat de respons hiervoor vaak al een aanwijzing geeft.

Nr Event Respons State 1 Operator stelt nieuwe temperatuur in Temperatuur wordt opgeslagen en

gebruikt Nee









Figuur 6.3: De ERL van de temperatuurregeling

Kijken we in figuur 6.3 naar regel 2 dan zien we dat deze transitie ervoor zorgt dat het systeem begint met verwarmen op de lage stand. De state waar naartoe wordt gesprongen zou dus 'VERWARMEN LAAG' kunnen heten. Voordat deze event/respons plaats vindt deed het systeem eigenlijk niets, dus deze state noemen we 'WACHTEN'. De actie in deze transitie is dan de ketel laag aansturen.

Voor regel 3 geldt precies het tegenovergestelde: het systeem dient te stoppen met verwarmen. Als de gewenste temperatuur bijna bereikt is, wordt de ketel laag aangestuurd, dus de transitie loopt van de state 'VERWARMEN LAAG' terug naar 'WACHTEN'. De actie in deze transitie is de ketel uit zetten.

Deze twee transities leveren dan het gedeeltelijke statemachine op van figuur 6.4.

Figuur 6.4: Gedeeltelijke statemachine temperatuurregeling

Op dezelfde wijze worden de andere 2 event/responses (4 en 5) toegevoegd, waarbij deze transities de overgangen weergeven tussen ‘VERWARMEN LAAG’ en ‘VERWARMEN HOOG’. Ook is duidelijk dat het systeem dient te starten in de state ‘WACHTEN’. Hiermee komen we dan tot de statemachine van figuur 6.2.

WACHTEN

VERWARMEN

LAAG



��

��'��(��

6.3. De Parkeergarage In deze paragraaf wordt de besproken techniek toegepast op de parkeergarage. Allereerst beginnen we met de event list van tabel 6.1. Nr Event Respons State 1 Sensor voor ingang actief en knop 'Ticket'

ingedrukt Geef kaartje en slagboom ingang gaat open

Ja

2 Sensor achter ingang actief (na event 1!) Slagboom dicht en kaartje opslaan in database

Ja

3 15 seconden na event 1 en sensor achter ingang niet actief

Slagboom ingang dicht en kaartje negeren Ja

4 Klant stop kaartje in automaat uitgang en sensor voor uitgang actief en klant heeft voldoende betaald

Slagboom uitgang gaat open Ja

5 Sensor achter uitgang actief (na event 4) Slagboom uitgang dicht en kaartje uit database verwijderen

Ja

6 Klant stop kaartje in automaat uitgang en sensor voor uitgang actief en klant heeft NIET voldoende betaald


7 Klant stop kaartje in automaat uitgang en sensor voor uitgang NIET actief


8 15 seconden na event 6 en sensor achter uitgang niet actief

Slagboom uitgang dicht en kaartje terug geven

Ja

9 Klant stopt kaartje in betaalautomaat Bedrag tonen Ja 10 Munt inworp en nog niet genoeg betaald Nieuw bedrag tonen Nee 11 Munt inworp en nu wel genoeg betaald Bedrag op 0 zetten en kaartje terug geven Ja

Tabel 6.1: De ERL van de parkeergarage

Bij het opstellen van deze event list waren we al uitgegaan van drie deelsystemen:

• de ingang, waar auto's aan komen rijen en naar binnen gaan (event/responses 1 t/m 3)

• de uitgang, waar auto's weer de parkeergarage verlaten (event/responses 4 t/m 8)

• de betaalautomaat, waar de klanten betalen (event/responses 9 t/m 11)

Sommige systemen laten zich niet (of moeilijk) beschrijven door een enkele statemachine. De parkeergarage is hier een goed voorbeeld van: eigenlijk zijn het 3 redelijk onafhankelijke deelsystemen. Vandaar dat we kiezen voor het beschrijven van het gedrag door een statemachine op te stellen per deelsysteem.

6.3.1. De ingang Voor dit deelsysteem zijn event/responses 1 t/m 3 van belang. Alle 3 de regels hebben een ‘Ja’ in de state-kolom, dus er zijn 3 transities.

Uit de drie transities is af te leiden dat er twee states zijn, n.l.: 'WACHTEN AUTO' en 'AUTO BINNENLATEN'. Alleen gedurende deze tweede state is de slagboom open. Als we tussen deze twee states de drie transities tekenen ontstaat figuur 6.5. De state om te starten is ‘WACHTEN AUTO’.

��

��'��(��

Figuur 6.5: De statemachine van de ingang

6.3.2. De uitgang Voor dit systeem zijn de event/responses 4 t/m 8 van belang. Hierbij hebben alleen de event/responses 4, 5, en 8 een ‘Ja’ in de state-kolom. Ook hier hebben we net als bij de ingang het wachten op een auto, en de slagboom die open is. Met de 3 transities komen we zo tot figuur 6.6.

Figuur 6.6: De statemachine van de uitgang – eerste versie

Wat moet er nu gebeuren met event/responses 6 en 7? Deze veroorzaken geen state verandering. Het is echter wel zo dat deze event/responses alleen kunnen optreden als de state machine in de state ‘WACHTEN’ staat. In zo’n situatie kan dan zo’n transitie naar dezelfde state worden getekend. Ook is te zien dat de respons bij beide hetzelfde is, en dus kunnen ze worden gecombineerd door de event als volgt te formuleren:

klant stopt kaartje in automaat uitgang EN (sensor uitgang niet actief OF klant niet betaald).

Als deze transitie wordt toegevoegd, dan ontstaat de statemachine van figuur 6.7.

WACHTEN AUTO

AUTO

BUITENLATEN

kaartje uitgang EN sensor voor uitgang

aktief EN klant betaald / slagboom uitgang

openen

sensor achter uitgang aktief / slagboom uitgang sluiten

15 seconden verstreken /

slagboom uitgang sluiten; kaartje

teruggeven

WACHTEN AUTO

AUTO

BINNENLATEN

knop ‘Ticket’ EN sensor voor ingang aktief / slagboom ingang

openen; kaartje geven

sensor achter ingang aktief / slagboom

ingang sluiten; kaartje opslaan

15 seconden verstreken / slagboom

ingang sluiten

��

��'��(��

Figuur 6.7: De statemachine van de uitgang – volledige versie

6.3.3. De betaalautomaat Bij de betaalautomaat zijn event/responses 9 t/m 11 van belang. Hierbij hebben alleen event/respons 9 en 11 een ‘Ja’ in de state-kolom. Bij 2 transities zijn niet meer dan 2 states mogelijk, dus ook hier is weer sprake van een statemachine met 2 states.

Uit de beschrijving van event/respons 9 en 11 is af te leiden dat de statemachine òf staat te wachten op een klant, òf bezig is met betalen. We komen dan tot de statemachine van figuur 6.8.

Figuur 6.8: De statemachine van de betaalautomaat – eerste versie Ook hier is weer de vraag wat we met event/respons 10 aanmoeten. Hij veroorzaakt geen state verandering, maar het is wel duidelijk dat deze alleen kan optreden in de state ‘BETALEN’. Ook hier wordt dus gebruik gemaakt van een transitie naar dezelfde state, en zo ontstaat figuur 6.9.

WACHTEN KLANT

BETALEN

kaartje in betaalautomaat /

bedrag tonen munt inworp EN

voldoende betaald / kaartje teruggeven

WACHTEN AUTO

AUTO

BUITENLATEN

kaartje uitgang EN sensor voor uitgang

aktief EN klant betaald / slagboom uitgang

openen

sensor achter uitgang aktief / slagboom uitgang sluiten

15 seconden verstreken /

slagboom uitgang sluiten; kaartje

teruggeven

kaartje uitgang EN (sensor voor uitgang NIET aktief OF klant niet betaald) / kaartje

teruggeven

��

��'��(�� !

Figuur 6.9: Statemachine van de betaalautomaat – volledige versie

Nog een laatste opmerking: Bij de temperatuurregeling is in de statemachine de eerste event/respons niet opgenomen. Deze heeft net als event/respons 10 van de parkeergarage een ‘Nee’ in de state-kolom. Bij deze event/respons 1 is echter wat anders aan de hand: Hij kan in elke state optreden. We kunnen natuurlijk vanaf elke state een transitie naar dezelfde state tekenen voor deze event/respons 1, maar dat maakt het niet duidelijker. In de regel wordt dat dus niet gedaan. In de ontwerpfase wordt deze event/respons wel meegenomen.

WACHTEN KLANT

BETALEN

kaartje in betaalautomaat /

bedrag tonen munt inworp EN

voldoende betaald / kaartje teruggeven

munt inworp EN nog niet voldoende betaald

/ bedrag verlagen

��

��)�*� ��"

7. PSD’s

7.1. Wat zijn PSD’s? In dit dictaat wordt ook ingegaan op de techniek van het PSD: het Programma Structuur Diagram. Deze techniek wordt gebruikt om te helpen bij het ontwikkelen van algoritmes voor bepaalde programmeerproblemen. Het PSD is hierbij toegesneden op de 3de generatie programmeertalen, zoals C, Pascal en Ada. Hij is ook nog steeds bruikbaar bij objectgeoriënteerde talen, zoals C++ en Java. Bij het gebruiken van een PSD wordt het programma ontwikkelen gesplitst in twee fases:

1. het bedenken van de structuur van het programma zodat het programmeerprobleem correct wordt opgelost

2. het vertalen van de structuur naar de juiste statements e.d. van de gekozen

programmeertaal Juist door deze 2 fases goed te splitsen is het mogelijk om complexere problemen op te lossen. Als je goed in staat bent om details uit te stellen, kun je je concentreren op de grotere structuur. Het coderen in een bepaalde programmeertaal is tenslotte een detail. Vooral als de programmeertaal nog redelijk nieuw voor je is, loop je vast als je tegelijkertijd moet nadenken over de structuur (het wat v/h programma), en de codering (het hoe v/h programma). In feite gebeurt er op een lager niveau weer hetzelfde als in het vorige deel van dit dictaat is besproken: eerst wat, daarna pas hoe! Ondanks het feit dat iedereen het daar wel mee eens zal zijn, blijkt het in de praktijk moeilijk deze volgorde aan te houden. Vooral in het onderwijs blijkt vaak dat ten behoeve van de docent het PSD na realisatie van het programma alsnog wordt opgesteld. Studenten geven vaak aan dat ze het erg moeilijk vinden om een PSD op te stellen, moeilijker dan het programma zelf schrijven. Eigenlijk is dat vreemd, omdat het PSD in principe eenvoudiger is dan het programma zelf. Het probleem is dat bij de eerste oefeningen de programmacode zo eenvoudig is, dat een PSD opstellen wel ingewikkelder lijkt. Dit dictaat probeert door een betere uitleg en voorbeelden aan te geven dat PSD’s opstellen niet ingewikkeld is, en inderdaad helpt bij het ontwikkelen van algoritmes.

7.2. De symbolen van het PSD PSD’s geven de structuur van een programma weer met behulp van een beperkt aantal symbolen. Juist omdat het aantal zeer beperkt is, is de schematechniek eenvoudig aan te leren. In totaal zijn er 3 verschillende structuren die kunnen worden afgebeeld:

1. de bewerking 2. de beslissing 3. de herhaling

��

��)�*� ��#

7.2.1. De bewerking Programma’s bestaan grotendeels uit een volgorde van bewerkingen. Een bewerking kan van alles zijn: een berekening, iets weergeven op het scherm, een getal inlezen van het toetsenbord, etc. De bewerking wordt afgebeeld als een rechthoek met daarin de bewerking weergegeven. Hieronder is een voorbeeld weergegeven, waarbij een teller met één wordt opgehoogd.

Het blok dient vooral aan te geven wat de bewerking is die hierin plaats vindt. Het hoe van de straks gekozen programmeertaal is niet belangrijk. Er dienen dus zo weinig mogelijk codeerdetails in aanwezig te zijn. Een goed voorbeeld hiervan is onderstaande bewerking in:

Hiermee wordt aangegeven dat een getal wordt ingelezen. Of dat getal via het toetsenbord wordt ingelezen, of via een mooi invoerscherm is (nog) niet van belang en blijft hier dus weg.

7.2.2. De beslissing Naast bewerkingen bevat een programma ook vaak beslissingen. Een beslissing bestaat uit een bewering/expressie die ‘waar’ of ‘niet waar’ is. Vervolgens wordt op basis hiervan de programma-flow gesplitst in 2 paden. Deze paden worden weergegeven door de blokken onder de bewering. Later kunnen de paden weer bij elkaar komen. Het symbool van de beslissing ziet er als volgt uit (alleen het bovenste blok):

Ook hier geldt weer dat de bewering moet aangeven wat de test inhoudt, niet zozeer hoe dat straks gecodeerd wordt. Uiteraard moet wel duidelijk zijn dat codering later mogelijk is. Een goed voorbeeld hiervan is hieronder weergegeven:

teller := teller + 1

a > b ? Ja Nee

programma flow voor ‘Ja’

programma flow voor ‘Nee’

hier komen de verschillende flows weer samen

lees getal in

a deelbaar door 2 ? Ja Nee

��

��)�*� ��$

In de meeste programmeertalen, en ook in Java, is het niet rechtstreeks mogelijk om te testen of een getal deelbaar is door 2. Het is echter wel mogelijk met de modulo-operator: deze bepaald de restwaarde van een gehele deling. Als deze restwaarde 0 is, dan is het getal dus deelbaar door het opgegeven getal. In Java code zou bovenstaande bewering als volgt gecodeerd worden (het %-teken is in Java de modulo-operator): if ((a % 2) == 0) { . . .

Deze Java-code is voor een leek nogal cryptisch, vandaar dat het belangrijk is om in het PSD weer te geven wat je eigenlijk wilt doen: testen of a deelbaar is door 2. Met dat in je achterhoofd is de Java-code ook duidelijk.

7.2.3. De herhaling Het meest krachtige element van programmeren is de herhaling. Juist doordat een computer heel snel een eenvoudige reeks van opdrachten kan herhalen, is deze in staat complexe problemen op te lossen. Bij een herhaling is net als bij een beslissing sprake van een bewering die ‘waar’ of ‘niet waar’ is. In dit geval geeft deze bewering aan of de herhaling moet worden uitgevoerd of niet. De bewering geeft m.a.w. de conditie aan waaronder de herhaling moet worden gestopt of juist moet worden doorgegaan. Herhaling met controle vooraf De meest gebruikte herhaling is met controle vooraf. Het symbool is hieronder weergegeven:

In bovenstaand voorbeeld wordt de structuur in het binnenste vierkant herhaald zolang de teller groter is dan 0. Hier wordt dus de bewering vermeld om de herhaling voort te zetten. Het is ook mogelijk om de bewering te vermelden om te stoppen met de herhaling. Bovenstaand voorbeeld is dus ook als volgt weer te geven:

zolang teller > 0

programma gedeelte dat herhaald wordt

totdat teller = 0


��

��)�*� ��%

Beide geven hetzelfde weer, alleen is het soms duidelijk om het stopcriterium te vermelden, en soms is het duidelijk om te specificeren wanneer moet worden doorgegaan. Juist omdat er gekozen kan worden dien je altijd erbij te vermelden waarvoor gekozen is (m.b.v. zolang of totdat). In onderstaande figuur is het bijvoorbeeld onduidelijk wat de situatie is:

Wordt er nu doorgegaan of gestopt als a groter dan b? Als iemand die het PSD leest moet gaan gokken, dan is het fout. Het PSD dient eenduidig te zijn, dus altijd erbij vermelden of wordt doorgegaan of gestopt. Nog een laatste opmerking: In sommige programmeertalen, zoals C en Java, is het criterium dat in een herhaling vermeld wordt altijd het doorgaan-criterium. Als in het PSD een stop-criterium is vermeld, moet deze bij codering worden omgezet. Herhaling met controle achteraf Het is ook mogelijk om de controle achter het blok te plaatsen dat herhaald wordt. Dit wordt weergegeven door de herhalingssymbool ‘om te klappen’ zoals hieronder is weergegeven:

Ook bij deze herhalingsstructuur is het mogelijk om zowel een doorgaan-criterium als een stop-criterium te vermelden. Wat is nu het verschil tussen een controle vooraf en achteraf? Het verschil is subtiel, en in veel situaties maakt het niet uit. Het grootste verschil is dat de lus met controle achteraf altijd minimaal één maal wordt doorlopen. Aangezien de controle achteraf plaats vindt is het blok minstens één maal uitgevoerd. Bij de controle vooraf kan het criterium de eerste keer al aangeven dat het blok niet moet worden uitgevoerd, en dan wordt de herhaling dus nul maal doorlopen!

a > b



��

��)�*� �� &

De voorkeur dient uit te gaan naar controle vooraf. Het is namelijk voor de lezer prettig om eerst het criterium te lezen, en dan pas het blok dat herhaald moet worden. In feite is het verschil tussen beide structuren zo klein dat de éne altijd om te zetten is naar de andere. Je dient echter steeds duidelijkheid en transparantie voorop te stellen: kies dus de structuur die voor het gegeven probleem het duidelijkst is voor de lezer van het PSD!

7.2.4. Combineren van de PSD-elementen Een totale PSD bestaat uit een samenstelling van de hiervoor besproken elementen. Het totale PSD heeft de vorm van een rechthoek. Deze rechthoek wordt verdeeld in opeenvolgende bewerkingen, beslissingen en herhalingen. Bij een beslissing komt onder de “Ja”-tak en “Nee”-tak een rechthoek met daarin de bijbehorende structuur die onder die conditie moet worden uitgevoerd. Zo’n rechthoek dien je te zien als een sub-PSD: ook deze kan worden verdeeld in bewerkingen, beslissingen en herhalingen. Ook het blok in de herhaling is zo’n sub-PSD. Op deze wijze kunnen de elementen onbeperkt gecombineerd worden tot complexe PSD’s. Als voorbeeld wordt hieronder een PSD gegeven, die van een rij van 10 getallen het maximum moet vinden. Van de getallen is gegeven dat ze allemaal groter zijn dan 0. Hieronder is het PSD gegeven. Verderop in dit dictaat wordt besproken hoe zo’n PSD kan worden opgesteld.

Hieronder is ook de Java-code gegeven die bovenstaand PSD implementeert. Er wordt hierbij gebruik gemaakt van 2 functies: LeesGetal() om een getal aan de gebruiker te vragen, en PrintGetal() om een getal op het scherm weer te geven.

teller := 0

maximum := 0

zolang teller < 10

lees getal in

getal > maximum? Ja Nee

maximum := getal

teller := teller + 1

druk maximum af op scherm

��

��)�*� ��

int teller; int maximum; int getal; teller = 0; maximum = 0; while (teller < 10) { getal = LeesGetal(); if (getal > maximum) { maximum = getal; } teller = teller – 1; } PrintGetal(maximum);

Een opmerking is hier nog op zijn plaats: In het PSD is de “Nee”-tak leeg: het programma hoeft dan namelijk niets te doen. Het blok in het PSD wordt dan gewoon leeg gelaten. In de code betekent dit dan dat er geen ‘else’-tak nodig is.

��

��)�*� ��

8. Waarom liever PSD’s dan flowcharts? Bij allerlei programmeerdisciplines wordt ook vaak gebruik gemaakt van flowcharts. In zo’n flowchart is slechts sprake van 2 symbolen: de rechthoek voor een bewerking en de ruit voor een beslissing. Soms ontstaat de discussie waarom PSD’s gebruikt moeten worden in plaats van flowcharts. Natuurlijk kan de flow van een programma ook worden weergegeven met een flowchart. Een flowchart is echter veel algemener dan een PSD. Vertaling van een flowchart naar een 3de generatie programmeertaal is daarom niet altijd eenvoudig. Er ontstaat met name een probleem als lijnen in een flowchart elkaar gaan kruisen. Als voorbeeld wordt weer gezocht naar het maximum van een rij getallen. Nu is echter van tevoren niet bekend hoeveel getallen er zijn. Wel is gegeven dat de rij getallen wordt afgesloten met een 0. Een flowchart zou dan er als volgt uit kunnen zien:

Deze flowchart geeft duidelijk aan wat het programma moet doen. Echter, hij is niet eenvoudig te vertalen in programmacode van een 3de generatie programmeertaal. De

lees getal in

start

getal = 0?

maximum := 0

getal > maximum?

maximum := getal

geef maximum op scherm

stop

Ja

Nee

Nee

Ja

��

��)�*� ��

verschillende pijlen in de flowchart zijn natuurlijk te vertalen als goto-statements, maar die mogen alleen bij hoge uitzondering worden gebruikt. Bij de vertaling in programmacode, dient de pijl terug omhoog beschouwd te worden als een herhalingsconstructie. Er is geen conditie om te stoppen of door te gaan, dus blijkbaar is het een oneindige lus. Er is echter in het midden wel een conditie om uit de lus te breken. De vertaling in Java-code zou er dan als volgt uit kunnen zien: int getal; int maximum; maximum = 0; while (true) { getal = LeesGetal(); if (getal == 0) break; if (getal > maximum) { maximum = getal; } } PrintGetal(maximum);

Er zijn twee nadelen aan deze code: 1. De structuur is niet erg duidelijk. Midden in een lus eruit springen is niet verboden,

maar ook hier geldt weer: liever niet. 2. Je moet goed kijken om te zien dat de flowchart en het programma inderdaad

hetzelfde zijn. De flowchart dwingt je niet om bij de oplossing van het probleem te denken in bewerkingen, beslissingen en herhalingen. Hierdoor is de vertaling niet altijd eenvoudig en de structuur ook niet de meest duidelijke. Hoe zou de structuur dan worden als er uitgegaan wordt van een PSD? In een PSD wordt een lus middenin verlaten niet aangemoedigd, dus wordt een structuur gezocht waarbij dat niet hoeft. De oplossing ligt er in, dat het eerste getal buiten de lus wordt ingelezen. Hierna kan dan de test plaats vinden, waardoor de lus herhaald wordt zolang het (nieuw) ingelezen getal ongelijk is aan 0. Hieronder is het PSD gegeven:

��

��)�*� ��

De code die hieruit volgt ziet er zo uit: int getal; int maximum; maximum = 0; getal = LeesGetal(); while (getal > 0) { if (getal > maximum) { maximum = getal; } getal = LeesGetal(); } PrintGetal(maximum);

De meeste programmeurs zullen van menig zijn dat deze versie beter leesbaar is dan de eerdere versie. Natuurlijk kan bovenstaande structuur ook als flowchart worden opgesteld. Een dergelijke flowchart zo er als volgt uit zien:

maximum := 0

lees getal in

zolang getal > 0

getal > maximum? Ja Nee

maximum := getal lees getal in

druk maximum af op scherm

��

��)�*� �� !

Hopelijk is voor iedereen te zien, dat deze structuur voor de flowchart niet de meest voor de hand liggende is. Ook is vertaling in getoonde Java-code niet zo vanzelfsprekend. De conclusie dient dan ook te zijn dat flowcharts weliswaar een goede tool zijn om algoritmes te modelleren, echter niet als ze moeten worden vertaald in een 3de generatie programmeertaal. Dan kan beter gekozen worden voor PSD’s, omdat men daarmee al in een bepaald keurslijf wordt geperst. Flowcharts zijn wel uitermate geschikt om bedrijfsprocessen e.d. weer te geven.

lees getal in

start

getal = 0?

maximum := 0

getal > maximum?

maximum := getal

geef maximum op scherm

stop

Ja

Nee

Nee

Ja

lees getal in

��

��)�*� �� "

9. Algoritmes ontwikkelen met PSD’s Duidelijk is nu welke symbolen in PSD’s gebruikt worden en hoe ze gecombineerd kunnen worden. Onduidelijk is nog hoe men hiermee een bepaald probleem kan oplossen.

9.1. Opsplitsen van problemen In het algemeen wordt bij het oplossen van problemen gebruik gemaakt van een standaard techniek: deel het grote probleem op in kleinere deelproblemen. Ga hiermee door totdat de deelproblemen zo klein zijn dat ze eenvoudig zijn op te lossen. Deze techniek van opsplitsen (decompositie) is een algemene HBO-vaardigheid. Juist op deze wijze kunnen complexe problemen hanteerbaar worden gemaakt. Uiteindelijk geldt hetzelfde principe voor programmeerproblemen. Het totale programma wordt opgedeeld in subprogramma’s, en hiermee wordt doorgegaan totdat eenvoudige bouwstenen overblijven die ook eenvoudig te realiseren zijn. PSD’s ondersteunen hierin, door als bewerking te kunnen refereren aan een sub-PSD. Men krijgt hierdoor een hoofd-PSD die een aantal kleinere PSD’s gebruikt. Elke PSD op zichzelf blijft hierdoor eenvoudig en overzichtelijk. Zo’n blok dat refereert aan een andere PSD wordt als volgt weergegeven:

De dubbele kantlijn geeft aan dat er sprake is van een sub-PSD die TrommelVullen heet. Opmerking: in de omzetting naar programmacode kan ervoor gekozen worden om op dezelfde wijze functies en/of procedures te maken. Het is echter niet verplicht dat dat op identieke wijze gebeurt.

9.2. Een voorbeeld: de wasmachine Als voorbeeld wordt een eenvoudige besturing voor een wasmachine genomen. De besturing (programma) dient het volgende te doen:

• de gebruiker doet de vuile was in de trommel, sluit de trommeldeur en start het (enige mogelijke) wasprogramma

• de trommel wordt gevuld met water dat reeds de juiste temperatuur heeft en zeep bevat (een beetje magie...)

• de trommel draait gedurende een bepaalde tijd (b.v. 30 minuten) afwisselend linksom en rechtsom. Na elke minuut wordt er gewisseld.

• de trommel wordt weer leeg gemaakt • hierna wordt de trommel 5 minuten snel linksom geroteerd • de deur wordt ontgrendeld, het programma is klaar

TrommelVullen

��

��)�*� �� #

In bovenstaande beschrijving is al een bepaalde volgorde weergegeven. Het is al bijna een stappenplan. Als de gebruiker de startknop bedient wordt automatisch het programma gestart. Als eerste slag wordt nu dit stappenplan vertaald in een PSD die het totale programma opdeelt in subprogramma’s. Deze subprogramma’s worden na elkaar uitgevoerd.

De laatste stap (deur ontgrendelen) is al zo elementair dat deze als bewerking wordt weergegeven en niet als sub-PSD. Het totale probleem van het wasprogramma doorlopen is nu teruggebracht tot 5 kleinere eenvoudigere deelproblemen. Deze resulteren in 5 sub-PSD’s. Niet alle PSD’s worden hier getoond, er worden er hier 2 uitgelicht. Allereerst het blok WachtDeurDicht. Dit blok doet precies wat de naam aangeeft: wachten met starten totdat de deur dicht is. Het blok zorgt tevens voor vergrendeling van de deur. In programmeren betekent de term ‘wachten op...’ in het algemeen een lus die pas stopt als datgene waarop gewacht wordt waar is. Soms moet tijdens de lus nog wat gebeuren, maar vaak is de lus zelf leeg! Sommige beginnende programmeurs vinden het verleidelijk om de volgende structuur op te stellen:

Echter, de beslissing in de lus niet nodig, want de controle vindt ook al plaats binnen de lus. Tevens kun je niet een los stoppen met ‘lus stoppen’. De lus stop je in het algemeen óf door een controle vooraf óf door een controle achteraf. Tenslotte wordt de actie ‘deur ontgrendelen’ als laatste éénmaal uitgevoerd. Om deze reden dient hij onder de lus geplaatst te worden. De resulterende PSD ziet er aanzienlijk eenvoudiger uit:

WachtDeurDicht

TrommelVullen

Wassen

TrommelLegen

deur ontgrendelen

zolang deur open

deur open ? Ja Nee

deur vergrendelen

lus stoppen

WachtDeurDicht:

��

��)�*� �� $

Zoals eerder vermeld, ook in deze situatie is de wachtlus uiteindelijk leeg. Het tweede deelprogramma wat hier wordt getoond is TrommelVullen. Bij de invulling hiervan is van belang hoe de wasmachine wordt aangestuurd. In ons voorbeeld gaan we er van uit dat er een kraan open en dicht kan worden gezet. Tevens is er een hoogtesensor in de trommel die actief wordt als de trommel vol is. Om nu te bepalen wat de besturing dient te doen, is het goed om te bedenken wat je zou doen als je het zelf zou moeten doen. Je zou dan (waarschijnlijk) het volgende doen:

• je zet de kraan open • je wacht totdat de hoogtesensor actief wordt • je draait de kraan weer dicht

De besturing dient dus precies hetzelfde te doen. De eerste en laatste stap is een eenvoudige actie, de middelste stap is een wachtlus. Hierdoor ontstaat het volgende PSD:

Stel nu dat er in Java 2 functies beschikbaar zijn:

• De functie ZetKraan() die met een boolean de kraan open (true) of dicht (false) kan zetten.

• De functie HoogteSensor() die met een teruggegeven boolean aangeeft of de hoogtesensor actief is.

Bovenstaande PSD ziet er dan in Java-code als volgt uit:

ZetKraan(true); while (HoogteSensor() == false) {} // lege lus! ZetKraan(false);

zolang deur open

deur vergrendelen

WachtDeurDicht:

kraan openen

TrommelVullen:

totdat hoogtesensor aktief

kraan sluiten

��

��)�*� �� %

10. Algoritmes met een herhaling Veel (deel-)algoritmes komen neer op het ontwikkelen van een lus. Dit wil eigenlijk zeggen dat computers ingewikkelde problemen kunnen oplossen door heel vaak een zelfde soort eenvoudige bewerking te doen. Het is echter wel de programmeur die moet verzinnen hoe het probleem vertaalt kan worden in een herhaling van een eenvoudige bewerking! Het opstellen van algoritmes is moeilijk aan te leren. Er is geen vast recept om tot een goede oplossing te komen. Er komt creativiteit bij kijken en uiteraard speelt ook ervaring een grote rol. Het is dus vooral een combinatie van aanleg en oefenen (oefenen, oefenen,...). Echter, er zijn wel bepaalde technieken die helpen bij het opstellen van herhalingsalgoritmes. Deze technieken helpen om in de juiste volgorde over het probleem na te denken. Aan de hand van 4 voorbeelden wordt deze techniek uitgelegd:

1. som van een reeks getallen 2. grootste delta bepalen in een reeks getallen 3. op één na grootste getal bepalen in een reeks getallen 4. alle deelrijen bepalen waarvoor de som een opgegeven waarde heeft

10.1. Volgorde bij ontwikkelen van een lus Bij de meeste programmeerproblemen is wel duidelijk of ze wel of niet met een herhaling kunnen worden opgelost. Als er inderdaad sprake zal zijn van een herhaling, dan kun je het beste als volgt te werk gaan: Stap 1: Zet eerst een voorbeeld op papier Dit is erg belangrijk, omdat je vaak met je eigen hersens wel degelijk het gegeven probleem kunt oplossen. Wij doen het niet altijd met een herhaling, maar uiteindelijk vaak ook wel. Alleen zijn we er ons niet altijd van bewust. De kunst is nu om je wel van je eigen denkproces bewust te worden! Bepaal op basis van het voorbeeld op papier wat elke herhaling globaal behandeld wordt. Als er bijvoorbeeld sprake is van een reeks getallen, hoeveel getallen worden dan in elke slag van de lus behandeld? Meestal is dit één, maar niet altijd. Stap 2: Bepaal start van de body van de lus Voor deze stap pak je ergens in het midden een geval, en je bekijkt wat de lus voor dit geval dient te doen. Hieruit kun je ook afleiden wat het programma uit het ‘verleden’ dient te onthouden. Het lijkt wellicht vreemd om in het midden te beginnen, maar dat is het niet. Vaak is een eerste en/of laatste geval van een herhaling wat anders dan de rest. Deze gevallen los je dus later op, en je concentreert je eerst op de meest voorkomende gevallen: de middelste daar tussen! Ook is het makkelijker om je voorstellen wat het programma moet onthouden als je bedenkt dat het programma al een tijdje bezig is.

��

��)�*� ��!&

Stap 3: Bepaal einde van de body van de lus Vervolgens ga je bekijken wat de lus voor het volgende geval dient te doen. Meestal komt dit neer op het aanpassen van de gegevens uit het ‘verleden’ die je in stap 2 hebt vastgelegd. Stap 4: Bepaal stopcriterium Nu ga je nadenken wanneer de lus gestopt moet worden. Stap 5: De initie van de lus Vervolgens ga je naar het eerste geval kijken. Wat doet de lus de eerste keer, en welke gegevens dienen hiervoor te worden voorbereid. Stap 6: Na de lus Tenslotte dient er nog gekeken te worden of het laatste geval anders is, of dat er na de lus nog iets anders gedaan moet worden (iets op het scherm zetten bijvoorbeeld). Soms is deze stap ook gewoon leeg! Dit stappenplan is zonder voorbeeld nog steeds behoorlijk abstract. In de volgende paragraven zullen de voorbeelden (in oplopende moeilijkheid) de techniek nader verduidelijken.

10.2. Voorbeeld 1: Som van een rij getallen In het eerste voorbeeld dient de som van een rij getallen te worden bepaald. Gegeven is dat alle getallen in de rij groter zijn dan 0, en dat de rij afgesloten wordt met een 0. Stap 1: Zet eerst een voorbeeld op papier We maken zelf een voorbeeld van een rij getallen: 2 5 10 6 8 4 2 7 0 Het ligt voor de hand om te stellen dat de body van de lus steeds één getal behandeld. Stap 2: Bepaal start van de body van de lus We pakken in het midden een bepaald geval, bijvoorbeeld het 4de getal: de 6. 2 5 10 6 8 4 2 7 0 We gaan er van uit dat het programma de eerste 3 getallen reeds correct heeft behandeld. Vervolgens maken we het volgende globale PSD:

��

��)�*� ��!�

In het midden staat de herhalingsstructuur met ruimte erboven voor eventuele initie, en ruimte eronder om nog wat laatste bewerkingen te doen (indien nodig). De pijl geeft aan over welk gedeelte we gaan nadenken. Allereerst maken we afspraken welke variabelen er zijn en wat daar in staat als het programma is aangeland bij de pijl. Pas later zullen we zorgen dat deze afspraken worden nagekomen! Welke gegevens heeft het programma nu nodig als het in aangeland bij de pijl en het de 6 dient te behandelen? Allereerst dient het getal 6 ergens opgeslagen te zijn. We spreken dus af: afspraak 1: getal := huidige te behandelen getal Verder dient het programma te weten wat de som is van de getallen tot dan toe: afspraak 2: som := som van de getallen tot dan toe Voor het geval wat we aan het bekijken zijn geldt dan: getal := 6 som := 17 Boven aan de lus is nu slechts één bewerking nodig:

Het getal 6 is nu correct behandeld, dus we zijn met stap 2 klaar. Stap 3: Bepaal einde van de body van de lus We gaan nu kijken wat de lus moet doen met het getal volgend op de 6: de 8.

som := som + getal

��

��)�*� ��!�

2 5 10 6 8 4 2 7 0 Wat moet dan voor de afspraken gelden? Het volgende: getal := 8 som := 23 De som is al correct bepaald. Wel moet we zorgen dat de variabele getal de volgende uit de reeks bevat. Dit doen we door het volgende getal in te lezen.

Nu is alles klaar voor het volgende geval. We gaan naar de volgende stap. Stap 4: Bepaal stopcriterium De reeks getallen wordt afgesloten met een 0, dus dan dient het programma te stoppen. Het volgende getal wordt steeds onder aan de lus gelezen, dus we kunnen boven aan de lus controleren op 0.

Stap 5: De initie van de lus Eerst dien je te bepalen wat het eerste geval is. In dit geval is dat gewoon het eerste getal, de 2. Voor dit eerste geval dienen ook weer de afspraken te gelden, dus: getal := 2 som := 0 Hieruit volgt ook de initie van het PSD.

zolang getal � 0

som := som + getal

lees getal in

som := som + getal

lees getal in

��

��)�*� ��!�

Stap 6: Na de lus In deze stap hoeft voor de som niets meer te gebeuren. Het algoritme werkt ook met het laatste getal. Wel dient nog de som te worden weergegeven. Hieruit volgt dan het uiteindelijke PSD.

Nou is duidelijk dat bij dit eenvoudige probleem de weg langer lijkt dan noodzakelijk. Dit voorbeeld is vooral bedoeld om de techniek te illustreren. In de volgende voorbeelden ligt het algoritme wat minder voor de hand.

10.3. Voorbeeld 2: Grootste verandering in reeks getallen Het volgende voorbeeld is iets moeilijker, en beschrijft een situatie die regelmatig voorkomt. Van een reeks getallen dient de grootste verandering te worden bepaald, m.a.w.: het grootste verschil tussen 2 opvolgende getallen. Ook hier wordt de reeks weer afgesloten met een 0. Stap 1: Zet eerst een voorbeeld op papier We maken zelf weer een voorbeeld van een rij getallen: 2 5 10 6 8 4 2 7 0 Hoeveel getallen behandeld de lus nu per slag? Het lijkt verleidelijk om uit te gaan van 2 getallen per keer, omdat het verschil tussen 2 getallen moet worden bepaald. Echter, elk nieuw getal van de rij veroorzaakt ook éénmaal een nieuw verschil. Het is dus wel degelijk één getal per slag van de lus.

lees getal in

zolang getal � 0

druk som af op scherm

som := som + getal

lees getal in

som := 0

lees getal in

zolang getal � 0

som := som + getal

lees getal in

som := 0

��

��)�*� ��!

Stap 2: Bepaal start van de body van de lus We pakken in het midden weer een bepaald geval, bijvoorbeeld het 4de getal: de 6. 2 5 10 6 8 4 2 7 0 We gaan er weer van uit dat het programma de eerste 3 getallen reeds correct heeft behandeld. Vervolgens maken we het volgende globale PSD:

Welke afspraken dienen we nu te maken? Ook nu dient weer het huidige getal bekend te zijn, dus: afspraak 1: getal := huidige te behandelen getal Ook moet het grootste verschil tot nu toe zijn opgeslagen. We nemen hiervoor de variabele delta: afspraak 2: delta := grootste gevonden verschil tot nu toe Voor ons voorbeeld geldt dan: getal := 6 delta := 5 Met het getal 6 ontstaat een nieuw verschil met het vorige getal, de 10. Hieruit blijkt dat we het vorige getal ook onthouden moeten hebben. We komen hiermee tot afspraak 3: afspraak 3: vorige := het vorige getal uit de reeks En in ons voorbeeld geldt dan: vorige := 10 Nu is het niet moeilijk meer wat boven aan de lus dient te gebeuren. Eerst wordt het nieuwe verschil bepaalt, en vervolgens wordt gekeken of het nieuwe verschil groter is. Merk op dat bij het bepalen van het verschil de absolute waarde moet worden genomen!

��

��)�*� ��!!

Hiermee is stap 2 klaar. Stap 3: Bepaal einde van de body van de lus We gaan nu kijken wat de lus moet doen met het getal volgend op de 6: de 8. 2 5 10 6 8 4 2 7 0 Wat moet dan voor de afspraken gelden? Het volgende: getal := 8 delta := 5 vorige := 6 De variabele delta is reeds bepaald in de start van de body. De variabelen getal en vorige moeten nog worden aangepast. Voor de variabele getal geldt weer dat deze als nieuw getal moet worden ingelezen. Echter, de huidige waarde moet naar de variabele vorige, dus dat doen we eerst. Hierdoor ontstaat het volgende PSD:

verschil := | getal – vorige |

verschil > delta ? Ja Nee

delta := verschil

vorige := getal

lees getal in



delta := verschil

��

��)�*� ��!"

Stap 4: Bepaal stopcriterium De reeks getallen wordt weer afgesloten met een 0. Hier is kan dezelfde constructie gebruikt worden als bij het vorige voorbeeld.

Stap 5: De initie van de lus Eerst dien je te bepalen wat het eerste geval is. In dit geval is dat niet zo voor de hand liggend. Het eerste geval is als er sprake is van het eerste verschil. Dus de eerste keer dat de lus loopt wordt niet het 1ste getal (de 2) behandeld, maar het 2de getal (de 5)! Voor dit eerste geval geldt dan: getal := 5 delta := 0 vorige := 2 Hieruit volgt de volgende initie voor het PSD:

lees getal in

zolang getal � 0



delta := verschil

vorige := getal

lees getal in

lees vorige in

delta := 0

zolang getal � 0



delta := verschil

vorige := getal

lees getal in

��

��)�*� ��!#

Wat we doen is 2x een lees getal actie, waarbij de eerste keer het resultaat in vorige wordt opgeslagen, en de 2de keer in getal. Nog een laatste opmerking is hier op zijn plaats. Dit algoritme gaat fout wanneer de getallenrij leeg is, d.w.z. als het eerste getal al een 0 is! Met dit soort randgevallen dien je normaal gesproken rekening mee te houden, tenzij zeker is dat zo’n randgeval niet kan optreden. Stap 6: Na de lus Ook in dit voorbeeld is het voldoende om na de lus het gevonden verschil af te drukken. Hieruit volgt dan het uiteindelijke PSD.

10.4. Voorbeeld 3: Het één na grootste getal vinden In het volgende voorbeeld moet uit een getallenrij, weer afgesloten met een 0, het één na grootste getal gevonden worden. Stap 1: Zet eerst een voorbeeld op papier We maken zelf weer een voorbeeld van een rij getallen: 2 5 10 6 8 4 2 7 0 Hoeveel getallen behandeld de lus nu per slag? Hopelijk is iedereen met mij eens dat 1 getal per slag van de lus het meest voor de hand ligt. Stap 2: Bepaal start van de body van de lus We pakken in het midden weer een bepaald geval, bijvoorbeeld het 4de getal: de 6. 2 5 10 6 8 4 2 7 0

lees getal in

zolang getal � 0

druk delta af op scherm



delta := verschil

vorige := getal

lees getal in

lees vorige in

delta := 0

��

��)�*� ��!$

We gaan er weer van uit dat het programma de eerste 3 getallen reeds correct heeft behandeld. Vervolgens maken we het volgende globale PSD:

Welke afspraken dienen we nu te maken? Ook nu dient weer het huidige getal bekend te zijn, dus: afspraak 1: getal := huidige te behandelen getal Ook moet het één na grootste tot nu toe zijn opgeslagen. We nemen hiervoor de variabele zoek: afspraak 2: zoek := één na grootste getal tot nu toe Voor ons voorbeeld geldt dan: getal := 6 zoek := 5 Wat moeten we nu doen? Het huidige getal is het nieuwe één na grootste, als hij groter is dan zoek maar kleiner dan het grootste getal. Hieruit blijkt dat we ook het grootste getal dienen te onthouden! Afspraak 3: afspraak 3: grootste := grootste getal tot nu toe En in ons voorbeeld geldt dan: grootste := 10 Zoals eerder vermeld, als getal tussen zoek en grootste inzit, dan is dit het nieuwe één na grootste getal. In PSD:

zoek < getal < grootste ? Ja Nee

zoek := getal

��

��)�*� ��!%

Er zijn nog andere mogelijkheden. Als getal kleiner is dan zoek, dan hoeft er niets te gebeuren, maar wat als getal groter dan grootste? Dan wordt getal de nieuwe waarde van grootste, en de oude waarde van grootste is dan dus de één na grootste, dus de nieuwe waarde van zoek! Nu kunnen we de PSD eenvoudiger maken als we eerst op dit geval testen. We komen dan tot de volgende PSD:

Merk op dat deze oplossing dubbele waardes negeert, dus als de maximale waarde 2x voor komt, dan wordt niet de andere maximale waarde als één na grootste genoemd. Stap 3: Bepaal einde van de body van de lus We gaan nu kijken wat de lus moet doen met het getal volgend op de 6: de 8. 2 5 10 6 8 4 2 7 0 Wat moet dan voor de afspraken gelden? Het volgende: getal := 8 zoek := 6 grootste := 10 Alleen de waarde van getal moet worden aangepast, wederom door een nieuw getal in te lezen.

getal > grootste ? Ja Nee

zoek := grootste

grootste := getal

getal > zoek ? Ja Nee

zoek := getal

lees getal


zoek := grootste

grootste := getal


zoek := getal

��

��)�*� ��"&

Stap 4: Bepaal stopcriterium De reeks getallen wordt weer afgesloten met een 0. Hier is kan dezelfde constructie gebruikt worden als bij het vorige voorbeeld.

Stap 5: De initie van de lus Eerst dien je te bepalen wat het eerste geval is. In dit geval is dat eenvoudig, we pakken gewoon de eerste 2. Omdat we weten dat alle getallen groter zullen zijn dan 0, kunnen we zoek en grootste laten starten met een 0. getal := 2 zoek := 0 grootste := 0 Hieruit volgt de volgende initie voor het PSD:

Stap 6: Na de lus Ook in dit voorbeeld is het voldoende om na de lus het gevonden getal af te drukken. Hieruit volgt dan het uiteindelijke PSD.

lees getal

zolang getal � 0


zoek := grootste

grootste := getal


zoek := getal

lees getal

grootste := 0

zoek := 0

zolang getal � 0


zoek := grootste

grootste := getal


zoek := getal

lees getal

��

��)�*� ��"�

10.5: Voorbeeld 4: Som dan deelrijen zoeken Het laatste voorbeeld is wat ingewikkelder. Als je de eindoplossing ziet, is het eigenlijk niet zo moeilijk, maar in het begin lijkt het bijna oplosbaar. Het programma moet voor een bepaalde waarde x alle opeenvolgende reeksen vinden, waarvoor de som gelijk is aan x. Voor x = 15 zijn dit de volgende rijen: 1 + 2 + 3 + 4 + 5 = 15 4 + 5 + 6 = 15 7 + 8 = 15 Stap 1: Zet eerst een voorbeeld op papier Oef! Het belangrijkste is nu dit probleem zo herformuleren dat er sprake is van een herhaling. Hier komt ook een belangrijk stukje creativiteit om de hoek kijken! Van een bepaalde reeks hoeven we slechts 2 waardes te onthouden, n.l.: de start-waarde en de eind-waarde. We maken zelf weer een voorbeeld. We pakken inderdaad als x de waarde 15, en we pakken een willekeurige reeks die we aan het testen zijn: 1 2 3 4 5 6 7 8 9 10 11 start eind

Elke slag van de lus gaan we nu precies één reeks testen, of deze goed is. Na een reeks getest te hebben, testen we de volgende slag van de lus de volgende reeks. Stap 2: Bepaal start van de body van de lus Van twee variabelen weten we al dat we ze nodig hebben:

lees getal

zolang getal � 0

druk zoek af op scherm


zoek := grootste

grootste := getal


zoek := getal

lees getal

grootste := 0

zoek := 0

��

��)�*� ��"�

afspraak 1: start := startwaarde van de te testen reeks afspraak 2: eind := eindwaarde van de te testen reeks Nu dienen we eerst de som van de reeks te bepalen en vervolgens te kijken of deze juist is. Als hij juist is drukken we de huidige reeks af op het scherm. Maar nu gaan we een truukje uithalen. In plaats van de som te bepalen spreken we af dat er al een variabele som is met de som van de huidige reeks! Het ligt namelijk voor de hand dat de som van een nieuwe reeks eenvoudig te berekenen is op basis van de som van de vorige reeks. Dus: afspraak 3: som := som van de te testen reeks In ons voorbeeld geld dan bovenaan de lus: start := 3 eind := 6 som := 18 Onze eerste PSD ziet er dan als volgt uit:

Voorlopig stellen we het afdrukken van de reeks uit, door hier een Sub-PSD aan te roepen. Stap 3: Bepaal einde van de body van de lus Nu moet gekeken worden naar de volgende slag van de lus. Allereerst komt de vraag: welke volgende reeks moeten we testen. We testen een nieuwe reeks door óf de start-waarde óf de eindwaarde te veranderen. Het is tevens logisch deze steeds naar rechts om te schuiven. Maar wanneer veranderen we welke? Dit laten we afhangen van de waarde van som t.o.v. x. Als som namelijk hoger is dan x, dan is het zinvol om de eind-waarde op te hogen: de som wordt dan immers nog hoger! In deze situatie hogen we dus de start-waarde op. Als de som te laag is, dan hogen we de eind-waarde op. Op deze manier worden toch uiteindelijk alle mogelijke reeksen getest! Als overigens een reeks gevonden is kunnen we beide ophogen. Ook kan nu de nieuwe som eenvoudig berekend worden. We komen dan tot de volgende PSD:

som = x ? Ja Nee

druk reeks af

��

��)�*� ��"�

Stap 4: Bepaal stopcriterium Wanneer zijn we klaar? Een reeks bestaat uit minimaal 2 waarden. Als de start-waarde dus groter is dan x/2, dan kunnen we geen goede reeks meer vinden. We gaan dus door zolang start kleiner dan x/2.

Stap 5: De initie van de lus Eerst dien je te bepalen wat het eerste geval is. In dit geval is dat eenvoudig, we pakken gewoon de eerste reeks met lengte 2:

zolang start < x/2

som = x ? Ja Nee

druk reeks af

start := start + 1

eind := eind + 1

som := som + eind

som := som - start

som < x ? Ja Nee

eind := eind + 1

som := som + eind

som := som - start

start := start + 1

som = x ? Ja Nee

druk reeks af

start := start + 1

eind := eind + 1

som := som + eind

som := som - start

som < x ? Ja Nee

eind := eind + 1

som := som + eind

som := som - start

start := start + 1

��

��)�*� ��"

Aan het einde hoeft niets te gebeuren, dus stap 6 is leeg. Dit voorbeeld geeft ook aan dat je bij sommige problemen nog steeds je creativiteit nodig hebt, en dat is maar goed ook!

som := 3

zolang start < x/2

som = x ? Ja Nee

druk reeks af

start := start + 1

eind := eind + 1

som := som + eind

som := som - start

som < x ? Ja Nee

eind := eind + 1

som := som + eind

som := som - start

start := start + 1

eind := 2

start := 1

Ontwikkel Methode Elektrotechniek I

Documents

Transcript of Ontwikkel Methode Elektrotechniek I