TECHNISCHE UNIVERSITEIT EINDHOVENFACULTEIT ELEKTROTECHNIEKVakgroep Meten en Regelen

Methodisch ontwerpenvan programmatuuf voor

real-time besturingssystemen

door J.P. Vermeil'

Rapport van het afstudeerwerkuitgevoerd van maart 1990 tot oktober 1990in opdracht van prof. ir. F.J. Kylstraonder leiding van ir. R. van Vliet.150kt 1990

De faculteit Elektrotechniek van de Technische Universiteit Eindhoven aanvaardt geen•

verantwoordelijkheid voor de inhoud van stageverslagen en/of afstudeerrapporten.

Samenvatting

De vakgroep ER van de TU-Eindhoven kampt met problemen op het gebied van softwareontwikkeling. De ontwikkeling van programmatuur duurt te lang, de geleverde resultatenvoldoen vaak niet aan de wensen en zijn moeilijk aan te passen aan nieuwe ontwikkelingen.Vooral de onderhoudbaarheid van software geeft problemen omdat de ontwikkeling vaakuitgevoerd wordt door studenten die door tijdgebrek meestal niet in staat zijn om eenprobleem volledig op te lossen. Daarom is het nodig dat anderen verdeI' gaan met deontwikkeling van een programma. Onvolledige of onduidelijke documentatie geeft in eendergelijke omgeving grote problemen, zelfs zodanig dat besloten moet worden dat de re­sultaten van maanden onbruikbaar zijn.Genoemde problemen zijn op te lossen met methoden voor management en voor analyse enontwerp. In het kader van dit afstudeerwerk is literatuuronderzoek naar dit soort methodengedaan. De uitkomst daarvan is dat SQS een geschikte managementmethode is, terwijl demethode van Yourdon en Ward/Mellor gebruikt kan worden voor analyse en ontwerp. Voordeze methoden is instructiemateriaal geschreven, dat een student in staat moet stellen omgenoemde methoden binnen een aantal weken te leren. Er is een inventarisatie gemaaktvan ondersteunende programmatuur (CASE-tools).

Summary The group of Measurement and Control of Eindhoven University of Techno­logy has to cope with software development problems. Software development takes toolong, often results are not according to the wishes and not easily adaptable to new circum­stances.Maintainability in particular is difficult because software development is often done bystudents, who, due to timing constraints, are often incapable of solving a problem in alldetails. In an environment like this, incomplete or inadequate documentation causes hugeproblems. It is sometimes necesary to abandon results that have been accomplished aftermonths of work.Software development problems can be solved using techniques for management and foranalysis and design. In the scope of this thesis a study of software development methodshas been done. The results are that SQS is a useful tool for managing a software project,while the Yourdon (or Ward/Mellor) method is useful for analysis and design. A course onthese methods has been written. This course should enable students to learn mentionedmethodes within a few weeks. An inventory of supporting software (CASE-tools) has beenmade. ..

1

Inhoud

1 Inleiding

2 Probleemstelling

3 Software management methoden3.1 Inleiding..............3.2 Het waterval model van Boehm3.3 De System Development Methodology3.4 Het Software Quality System.3.5 De gekozen methode . . . . . . . . . .

4 Software analyse- en ontwerpmethoden4.1 Het doel van analyse- en ontwerpmethoden .

4.1.1 Vijf belangrijke criteria.4.1.2 11odulariteit .

4.2 Twee filosofien .4.3 Taakgeorienteerde methoden .

4.3.1 Algemene technieken4.3.2 Gane en Sarson4.3.3 Ward en Mellor ..4.3.4 Yourdon .4.3.5 Hatley en Pirbhai .4.3.6 De Systems Engineering Methodology.

4.4 Datageorienteerde methoden . . . . .4.4.1 Objectgeorienteerd on.twerpen4.4.2 Jackson '"

4.5 De gekozen methode . . . . . . . . .

5 CASE-tools5.1 Inleiding.....5.2 Promod .....5.3 System Architect5.4 Analyst designer

2

4

5

101010111213

14141415161717202122222627272932

3434353637

5.5 CASE-tools voor workstations .....

6 Beschrijving van de gekozen methoden

7 Conclusies en aanbevelingen7.1 Conclusies .7.2 Aanhevelingen .

8 Appendix8.1 Inleiding

3

37

39

414141

4444

Hoofdstuk 1

Inleiding

Onder real-time besturingssystemen zullen we hardware- en softwaresystemen (ook com­binaties van hardware en software) verstaan die een proces besturen dat binnen een korttijdsbestek stuursignalen nodig heeft.

Vit cijfers over de software industrie komt duidelijk naar voren dat veel bedrijven en instel­lingeI;l kampen met grote problemen op het gebied van software ontwikkeling. De kostenvan programmatuur zijn te hoog, de ontwikkeling duurt te lang, de geleverde resultatenvoldoen vaak niet aan de wensen van de opdrachtgever en zijn moeilijk aan te passen aannieuwe ontwikkelingen.

Ook bij de vakgroep ER van de TV-Eindhoven zijn dergelijke problemen geconstateerd.Ret gaat hier vooral om het probleem van de onderhoudbaarheid van programma's. Deontwikkeling ervan wordt namelijk vaak uitgevoerd door studenten die meestal niet in staatzijn om een probleem volledig op te lossen. Daarom is het nodig dat anderen verder gaanmet de ontwikkeling van een gedeeltelijk voltooid programma. Onvolledige of onduidelijkedocumentatie geeft in een dergelijke omgeving grote problemen, zeUs zodanig dat somsbesloten moet worden dat de resultaten van maanden onbruikbaar zijn.

Er zijn methoden beschikbaar waarmee de meeste problemen op het gebied van softwareontwikkeling opgelost kunnen worden. Ret gaat hier om twee zaken:

• een management methode waarmee werkzaamheden ingedeeld worden en waarmeede documentatie gestandaardiseerd wordt en

• hulpmiddelen voor analyse en ontwerp van een programma.

Om bovenstaande methoden te ondersteunen is programmatuur te koop.

Ret probleem is nu goede methoden voor management en ontwikkeling te vinden metdaarbij passende programmatuur. Vervolgens moet het geheel zodanig beschreven worden

•dat anderen zich de methoden snel eigen kunnen maken.

4

Hoofdstuk 2

Probleemstelling

Dat er bij software ontwikkeling problemen optreden moge blijken uit onderstaande cijfers,ontleend aan [Wallace, 1987]. De cijfers komen uit een onderzoek van het Amerikaanseleger naar de uitgaven aan software. In figuur 2.1 is weergegeven welk percentage van hetbudget voor software uitgegeven is aan werkelijk bruikbare programrnatuur..

Onderzoek van Boehm (zie [Boehm, 1981]) heeft uitgewezen dat de kosten van foutencor­rigeren in software dramatisch toenemen naarmate de ontwikkeling verdeI' gevorderd is. Infiguur 2.2 is dit grafisch gei1lustreerd. De figuur geeft de relatieve kosten van het verbete­ren van fouten in de verschillende ontwerpfasen weer. De kosten van correcties tijdens deanalyse en het ontwerp van software zijn relatief laag vergeleken bij de kosten van correctieals het systeem operationeel is. Hieruit voIgt dat het van groot belang is om deze laatstevorm van correetie zoveel mogelijk te voorkomen. Dit kan aIleen als de onwikkelde pro­grarnmatuur aan de eisen voldoet, waarvoor dan weer een goede ontwerpmethode verreistIS.

We kunnen dus stellen dat een goede ontwerpmethode de ontwerper helpt aan de gesteldeeisen te voldoen.

Dit is echter nog niet alles. Omdat goede software een lange levensduur zal hebben, zullende eisen die eraan gesteld worden op den duur veranderen. De software zal uitgebreidworden, of aangepast aan nieuwe omstandigheden. Om de kosten van dergelijke wijzigingenbinnen de perken te houden moet de. software goed gestructureerd zijn. Dat wiI zeggendat we een onderdeel moeten kunnen wijzigen of toevoegen zonder dat dit grote gevolgenheeft voor de rest van het systeem.

Een tweede eis die uit onderhoudbaarheid voIgt, is dat het systeem goed gedocumenteerdmoet zijn: iemand (meestal niet de ontwerper) moet in staat zijn de programmatuur tedoorgronden.

Samenvattend moet een ontwikkelmethode hulp geven bij:

5

Gebruikt soa1a geleverd (2%)

Gebruikt na wijzigingen (3%)

Geatopt (19%)

Betaald maar met geleverd (29%)

Geleverd maar met gebruikt (47%)

Figuur 2.1: Geld besteed aan bruikbare en niet bruikbare software

6

75

25

9

5

1 2,5 II

A.nal7ae Ontwerp Codering Onwikltel Acceptatie Operationeelteat teat

Figuur 2.2: De kosten van het korrigeren van fouten in software

•

7

1. het correct implementeren van de wensen van de gebruikers,

2. het structureren van het systeem en

3. het documen teren van het systeem.

In de literatuur zijn vele methoden te vinden waarmee geprobeerd wordt aan bovenstaandeeisen te voldoen. Uit diverse boeken komt naar voren dat er onderscheid gemaakt moetworden tussen het management van een project en de analyse en het ontwerp van eenprogramma.

Life-cycle modellen

Voor het management van een project kan gebruik gemaakt worden van een life-cyclemodel. Dit is een beschrijving van de aktiviteiten die uitgevoerd moeten worden om debehoefte aan een systeem om te zetten in een werkende implementatie die de behoefte zogoed mogelijk bevredigt. Daartoe wordt het ontwerptraject ingedeeld in fasen (meestalzeven of acht) met min of meer gedefinieerde taken die tijdens elke fase uitgevoerd moe­ten worden. Doordat vastgelegd is welke taken uitgevoerd moeten worden en met welkehulpmiddelen dat moet gebeuren, is het vrij eenvoudig om de voortgang van een project tebewaken. De meeste methoden schrijven ook voor welke documentatie geproduceerd moetworden tijdens elke fase, zodat in ieder geval hulp gegeven wordt bij het documenteren vaneen systeem. Opgemerkt moet worden dat het documentatie-aspect niet in elke methodeeven sterk naar voren komt.

Analyse- en ontwerpmethoden

Analyse en ontwerp vormen een onderdeel van elk life-cycle model. In de literatuur wordtanalyse omschreven als het vastleggen van de eisen die aan het systeem gesteld worden.Meestal worden de eisen eerst in een informele vorm gegeven. Als op basis van op dezemanier gestelde eisen een programma geschreven wordt, is vrijwel gegarandeerd dat hetresultaat niet aan de wensen van de toekomstige gebruiker zal voldoen. Dit komt omdatinformele specificaties voor velerlei uitleg vatbaar zijn; de ontwerper heeft vaak iets andel'Sin gedachten dan de opdrachtgever. Om de eisen vast te leggen kunnen we een model vanhet systeem maken. Ret is daarbij handig als de notatie van het model eenvoudig te lerenis, zodat niet-ingewijde gebruikers kunnen begrijpen wat het model inhoudt. Ret modelwordt dan een manier om over het sys.teem te communiceren.Als de eisen eenmaal vastgelegd zijn in een model kan het systeem geimplementeerd worden.Dat wil zeggen dat gekozen kan worden met welke hardware- en software-middelen hetprobleem opgelost zal worden.

CASE-tools

Ret is de taak van de analyse- en ontwerpmethode om ervoor te zorgen dat het systeemaan de eisen voldoet en dat het goed gestructureerd is.

8

Om de ontwerper te ondersteunen bij het analyseren en ontwerpen van een systeem enhet maken van documentatie zijn verschillende hulpmiddelen beschikbaar: de zogenaamdeCASE-tools.

Bet probleem

Het probleem is nu in de eerste plaats het vinden van een life-cycle model en een methodevoor analyse en ontwerp. Ook moet gezocht worden naar een CASE-tool waarmee degekozen methoden ondersteund worden.

Er is een groot aantal methoden in de literatuur beschreven, helaas op zodanig uitvoerigeen ondoorzichtige wijze, dat het niet mogelijk is om de methoden binnen korte tijd (eenaantal dagen) aan de hand van een boek onder de knie te krijgen. Er zijn weI kursus­sen beschikbaar, maar die zijn over het algemeen erg duur of ze vragen veel begeleiding.Daarom moet de gekozen methode zodanig beschreven worden dat een student er binneneen aaotal dagen mee aan de slag kan.

Het doel van dit afstudeerwerk kan als voIgt samengevat worden:

1. Zoek een software management methode.

2. Zoek een methode voor analyse en ontwerp van programmatuur voor real-time be­sturingssystemen.

3. Zoek ondersteunende programmatuur voor bovenstaande twee methoden.

4. Beschrijf de methoden zodanig dat ze snel door anderen geleerd kunnen worden.

9

Hoofdstuk 3

Software management methoden

3.1 Inleiding

In de ontwikkeling van een systeem zijn een aantal fasen te onderscheiden. Daarbij moetgedacht worden aan een orienterende fase, een analyse- en ontwerpfase, enz. Iedereen dieeen systeem ontwikkelt doorloopt deze fasen, maar meestal gebeurt dat niet bewust. Retvoordeel van het expliciet gebruiken van een gefaseerde ontwikkeling is dat de voortgangvan een project eenvoudig in de gaten gehouden kan worden. Daarnaast kunnen bij elke faseeisen aan documentatie gesteld worden, waarmee ongedocumenteerde systemen voork6menkunnen worden.

Een methode waarmee expliciet een fasering in het ontwerptraject wordt aangebracht wordteen life-cycle model genoemd. Er zijn vele sterk overeen komende modellen. De redenhiervoor is dat ze allemaal vrij goed aansluiten bij wat iedereen eigenlijk uit zichzelf aldoet. Op die manier onststaan methoden die aIleen in de nuances verschillen.Grotere verschillen ontstaan in filosofien over het doorlopen van de verschillende fasenwaaruit een model bestaat.

We zullen nu drie van de bekendste modellen kort bespreken.

3.2 Het waterval model van Boehm

In het model van Boehm worden de volgende fasen onderscheiden:

1. Onderzoek de haalbaarheid van het project.

2. Stel een specificatie op.

3. Ontwerp het systeem.

4. Ontwikkel de code door eerst het ontwerp uit de vorige fase de detailler~n en daarnaom te zetten naar code.

10

Haalbaarbeid

Eilen

Ontwerp

Figuur 3.1: Het watervalmodel van Boehm

5. Test het systeem.

6. Voer het systeem in.

7. Onderhoud.

8. Vervang het systeem als het verouderd is.

De fasen van dit model worden doorlopen met de 'waterval'-strategie. Dat wi! zeggen datelke fase apart uitgevoerd wordt, waarna de resultaten ervan niet meer gewijzigd kunnenworden. In figuur 3.1 is dit verduidelijkt.Meer informatie is te vinden in [Boehm, 1981]

3.3 De System Development Methodology

De System Development Methodology (SDM) is ontwikkeld door het Nederlandse bedrijfPandata. SDM onderscheidt de volgeride fasen:

1. Tijdens de informatieplanning wordt een analyse van de omgeving van het systeemgemaakt en wordt be'paald welke delen van het systeem geautomatiseerd zullen wor­den.

2. Tijdens de definitiestudie worden de eisen die aan het systeem gesteld worden vast­gelegd.

11

3. Tijdens het basisontwerp wordt eerst een globaal en daarna een gedetailleerder funetio­neel model van het systeem gemaakt. Implementatiebeslissingen worden uitgesteldtot de volgende fase.

4. Ret detailontwerp omvat het opstellen van een gedetailleerd model van het systeem,waarbij implementatiebeslissingen aan het functionele model uit de basisontwerpfasetoegevoegd worden.

5. De realisatie omvat het coderen en testen van het systeem.

6. Voer het systeem in.

7. Gebruik en onderhoud van het systeem, waarbij te zijner tijd over vervanging beslistwordt.

Ben belangrijk verschil tussen SDj\l en het model van Boehm is de informatieplanning. Deinteraktie tussen het systeem en de omgeving ervan is erg belangrijk. Daarom is het goedom de omgeving te analyseren. Tijdens de informatieplanning kan een heel bedrijf bekekenworden, wat kan leiden tot een aantal automatiseringsprojeeten.Meer informatie is te vinden in [Turner, 1988], [Hice, 1988] en [Eilers, 1989].

3.4 Het Software Quality System

Ret Software Quality System (SQS) is ontwikkeld door de faculteit informatica van de TUEindhoven in samenwerking met het ITP. De fasen van het model zijn als voIgt:

1. Analyseer de omgeving van het systeem.

2. Definieer de eisen die aan het systeem gesteld worden.

3. Stel een conceptueel-model op. Een conceptueel-model is een formalisering van deeisen. Ret is een funetioneel model, dus een beschrijving van de taken van het systeemwaarbij geen implementatiebeslissingen genomen worden.

4. Maak een implementatiemodel. Ben implementatiemodel is een vertaling van hetconceptueel-model naar een implementatie. Rierbij worden implementatiedetails toe­gevoegd, zoals de gebruikte processoren en communicatieprotocollen.

5. Codering.

6. Test het systeem.

7. Voer het systeem in.

8. Onderhoud.•

12

Ben van de belangrijkste kenmerken van dit model is de strikte scheiding tussen analyse (hetmaken van een conceptueel-model) en ontwerp (het maken van een implementatiemodel).Deze scheiding is erg belangrijk omdat ermee voorkomen kan worden dat al vroeg in deontwikkeling van het systeem uitgegaan wordt van implementatiebeslissingen die mogelijkbetere oplossingen uit kunnen sluiten. Ben tweede voordeel is dat door het conceptueel­model iedereen die met de systeemontwikkeling te maken heeft een goed beeld krijgt vanwat er van het systeem verwacht wordt. Voor een opdrachtgever is het eenvoudiger omhet systeem te begrijpen aan de hand van een model dan aan de hand van code. Alswijzigingen in de eisen van het systeem aangebracht moeten worden is dat makkelijker terealiseren in een abstrakt model dan in een werkend systeem.

Ben tweede kenmerk van SQS is het onderscheid dat gemaakt wordt tussen projectdocu­menten en produktdocumenten.Projectdocumenten beschrijven hoe een systeem tot stand moet komen. Er staan zaken inzoals planningen en kostenschattingen.Produktdocumenten beschrijven hoe het systeem eruit ziet: de omgevingsanalyse, de eisen,het conceptueel-model, maar ook de code zijn produktdocumenten.In [Hammer, 1990] wordt een exacte beschrijving van de fasen en de bijbehorende docu­mentatie gegeven.

Tenslotte zijn er nog de ontwikkelstrategien voor het doorlopen van de fasen. SQS schrijftgeen strategie voor; het model kan sequentieel doorlopen worden zoals dat van Boehm,maar ook iteraties zijn toegestaan.

3.5 De gekozen methode

Uiteindelijk is gekozen voor SQS. De redenen hiervoor zijn de volgende:

1. SQS is een goedbeschreven methode. [Hammer, 1990] is een makkelijk te gebruiken(en vooral kort) artikel waarin toch een volledig beeld van de methode gegeven wordt.Het is dus niet nodig om dikke boeken door te werken.

2. De faculteit informatica is dichtbij zodat het eenvoudig is om ondersteuning te krij­gen. Bovendien is hier geen sprake van commerciele belangen, zodat geen kostengemaakt hoeven te worden om de methode toe te kunnen passen.

3. De analyse- en ontwerpfasen (fasen 3 en 4) van SQS zijn goed te combineren met be­staande methoden waarmee een conceptueel- en implementatiemodel opgesteld kun­nen worden. Voor SDM geldt dit in mindere mate, omdat de scheiding tussen func­tionele specificatie en implementatie niet zo strikt is.

4. De documentatie is bij SQS goed gedefinieerd.

13

Hoofdstuk 4

Software analyse- enontwerpmethoden

4.1 Het doel van analyse- en ontwerpmethoden

4.1.1 Vijf belangrijke criteria

Het doel van een analyse- en ontwerpmethode is garanderen dat de ontwikkeide softwarevoidoet aan bepaaide kwaliteitscriteria. We onderscheiden externe en interne criteria (zie[Meyer, 1988]). Externe criteria zijn zaken als snelheid, betrouwbaarheid en gebruikers­gemak; het zijn kenmerken die de gebruiker van de software kan waarnemen. Tot internecriteria behoren een modulaire opbouw en Ieesbaarheid van de code, waar te nemen doorde ontwerper of degene die de software moet onderhouden.Hieronder voIgt een definitie van de genoemde criteria, overgenomen uit [Meyer, 1988]. Decriteria en de opmerkingen over modulariteit in de volgende paragraaf kunnen gebruiktworden om een software ontwikkelmethode te beoordelen.

Correctheid is het vermogen van software-systemen om hun taak uit te voeren zoaisgedefinieerd in eisen en specificaties.

Robuustheid is het vermogen van software-systemen om ook in abnormale omstandig­heden te blijven functioneren. Dit wil zeggen dat in niet voorziene omstandighedenhet gedrag van het systeem geen rampen mag veroorzaken.

Uitbreidbaarheid Hieronder verstaan we het gemak waarmee een systeem aangepast kanworden aan veranderingen in specificaties.

Herbruikbaarheid is de mate waarin een software-systeem geheel of gedeeitelijk gebruiktkan worden in nieuwe toepassingen. .

Compatibiliteit is de mate waarin software-systemen gecombineerd kunnen worden metanderen.

14

Andere criteria Verder zijn er nog zaken als efficientie, overdraagbaarheid, controleer­baarheid, integriteit (bescherming tegen ongeoorloofd gebruik) en gebruikersgemak.

4.1.2 Modulariteit

Om te kunnen voldoen aan de criteria uitbreidbaarheid, herbruikbaarheid en compatibili­teit moet de ontwikkelde software modulair zijn. Een module is in ieder geval autonoom(voert een taak uit waarbij geen andere modules nodig zijn), samenhangend (voert nietmeer dan een taak uit) en georganiseerd in robuuste eenheden (de module vangt onver­wachte gebeurtenissen zoveel mogelijk zelf op). Eerst ontwerpen en daarna pas nagaan ofer goede modules gemaakt zijn, leidt tot veel overbodig werk omdat na het ontwikkelenvan een module veranderingen aangebracht moeten worden. Daarom is het belangrijk datde ontwerpmethode helpt bij het ontwerpen van goede modules.Om ontwerpmethoden te evalueren op het punt modulariteit noemt Meyer vijf criteria:

Decompositie Een methode moet hulp geven bij het verdelen van een probleem in deel­problemen die onafhankelijk van elkaar opgelost kunnen worden.Top-down ontwerp is een voorbeeld van een methode die aan dit criterium voldoet.Een methode waarbij een initialisatie-module (voor aIle andere modules van het sy­steem) gebruikt wordt voldoet niet aan h~t criterium omdat een deel van de taakdie elke module uit moet voeren overgenomen wordt door de initialisatie-module. Demodules kunnen dus niet onafhankelijk van elkaar ontwikkeld worden.

Compositie Dit criterium heeft betrekking op het opnieuw gebruiken van modules ineen andere omgeving dan die waarvoor ze oorspronkelijk ontworpen zijn. Top-downontwerp voldoet niet aan dit criterium omdat de geproduceerde modules ontworpenworden voor een specifiek probleem. Alleen modules onderaan in de hierarchie zijnin sornmige gevallen (bijvoorbeeld reken- of i/o-routines) opnieuw bruikbaar.

Duidelijkheid Om het onderhoud aan een systeem te vereenvoudigen is het belangrijkdat een module onafhankelijk van andere modules bekeken kan worden (samenhang).

Continuileit De modules moeten zo opgezet zijn dat een kleine verandering in de speci­ficaties alleen gevolgen heeft voor een beperkt aantal modules. Dit criterium heeftbetrekking op de bovengenoemde uitbreidbaarheid.

Bescherming De effecten van onvoorziene gebeurtenissen tijdens de uitvoering van hetprogramma moeten beperkt blijven tot een zo klein mogelijk aantal modules (ra­buustheid).

Uit de criteria volgen vijf principes:

1. Modules moeten overeen komen met syntactische eenheden van de taal waarin zebeschreven worden (prograrnmeertaal, specificatietaal). Een voorbeeld is een moduledie overeenkomt met een procedure. Als een module overeen zou komen"met een deel

15

van een procedure wordt hergebruik veel moeilijker. Bij een goede keuze van mo­dules blijft de structuur van het ontwerp duidelijk zodat onderhoud en beschermingeenvoudiger worden. Ret gaat hier om de criteria duidelijkheid en compositie.

2. Elke module moet met zo weinig mogelijk andere communiceren. Uit een groot aantalrelaties voIgt dat fouten sneller door zullen werken in andere modules. Veranderingenin specificaties zullen eerder effect hebben op meer dan een module. Criteria diehiermee worden gerealiseerd zijn robuustheid en continuiteit.

3. Modules moeten zo weinig mogelijk informatie uitwisselen. Zonder communicatietussen modules zou er sprake zijn van aparte systemen, dus het is niet zo dat elkevorm van communicatie vermeden moet worden.Ook hier spelen continuiteit en robuustheid een roI.

4. Ret feit dat twee modules met elkaar communiceren moet duidelijk blijken uit decode van de modules. Een gemeenschappelijk datablok is tegen dit principe. Alseen van de modules die een stuk data gebruiken gewijzigd wordt moet zorgvuldignagegaan worden welke invloed dat heeft op andere modules. Ret gaat hier om hetcriterium duidelijkheid.

5. Een module levert bepaalde diensten aan andere modules. AIleen deze dienstenmogen zichtbaar zijn voor de buitenwereld (in dit geval de andere modules van hetsysteem), de implementatie ervan is aIleen aan de module zelf bekend. Ook hierspeelt de duidelijkheid een rol

4.2 Twee filosofien

Er zijn twee belangrijke filosofien die ten grondslag liggen aan ontwerpmethoden: uitgaanvan de objecten die het systeem manipuleert of uitgaan van de functies die het vervult.

Ret laatste sluit het beste aan bij wat de meeste programmeurs gewend zijn: kijk naarde gewenste functionaliteit, maak een indeling in deelfuncties die op hun beurt ook weerverdeeld kunnen worden, enzovoort net zolang tot een werkend stuk code ontstaan is.Taakgeorienteerde methoden zijn in wezen een formalisatie van wat iedereen altijd al doetbij het maken van een groot systeem.

Datageorienteerde methoden vragen wat meer training van de gebruiker, die zich een anderedenkwijze aan zal moeten leren. Ret grote voordeel is de geringere gevoeligheid voorwijzigingen in het ontwerp. Dit komt omdat de data die een systeem gebruikt vaak veelminder aan wijzigingen onderhevig is dan de implementatie van de datastructuren dienodig zijn om de data te manipuleren. Daarnaast leiden datageorienteerde methoden totmodules die eenvoudiger te gebruiken zijn in nieuwe toepassingen.We zullen nu van beide filosofien een aantal methoden bespreken.

16

4.3 Taakgeorienteerde methoden

4.3.1 . Algemene technieken

Taakgeorienteerde methoden gaan uit van de functies die een systeem moet vervuIlen.Het probleem wordt opgelost door deelfuncties te definieren die onafhankelijk van elkaarsteeds verder gedetailleerd worden, net zo lang tot eenvoudig te coderen deelproblemenoverblijven. Veel taakgeorienteerde methoden maken gebruik van een aanta! techniekenvoor modelvorming die we hieronder kort zullen bespreken.

Dataflowdiagrammen

Het dataflowdiagram (DFD) geeft weer uit welke deelfuncties het systeem is opgebouwd enwelke data er door deze functies tijdens hun uitvoering uitgewisseld wordt. Het DFD is eenhierarchisch model; het systeem wordt gezien als een aanta! taken die op hun beurt weeropgebouwd kunnen zijn uit deeltaken. Ook deze deeltaken kunnen weer opgedeeld wor­den. Het diagram is opgebouwd uit processen (transformeren inputs in outputs), dataflows(geven bewegende data weer), stores (geven opgeslagen data weer) en terminators (repre­senteren objecten uit de omgeving van bet systeem). Verder zijn er nog besturingsprocessenen -flows. De processen worden gebruikt om dataverwerkende processen te aktiveren of tedeaktiveren. Ze geven het tijdsaspect van het systeem weer en worden gemodelleerd metbehulp van toestandsdiagrammen.In figuur 4.1 is een voorbeeld gegeven, waarin ook te zien is hoe een proces uitgewerkt kanworden in deelprocessen.

Datadietionary

In de datadictionary worden aIle flows en stores van het DFD gedefinieerd met behulp vaneen wiskundige ogende notatie.Een voorbeeld van een definitie in een datadictionary is

Naam = 1{letter}20* Dit betekent: Een naam bestaat uit minimaal 1 en maximaal20 karakters. *

Processpecificaties

Processpecificaties zijn bedoeld om processen op het onderste niveau van het hierarchischeDFD te specificeren. Het gaat hier dus om processen die niet meer in deelprocessen ver­deeld zijn. Er zijn diverse specificatietechnieken waaronder gestructureerde taal, pre- enpostcondities, beslissingstabellen, toestandsdiagrammen en wiskundige formalismen.

17

Terminalor 1

/I\\

\."-

...............

................ - ----._--- ---

Terminalor 2

\

Datafbf 1\

I/

//

/./

./

Figuur 4.1: Het uitwerken van een proces in deelprocessen

18

Figuur 4.2: Ben voorbeeld van een ERD

Ben voorbeeld van een processpecificatie in gestructureerde taal is het onderstaande:

voorbeeld.Het geven van eenInputl, Input2Output 1, Output2Lokale_variabele

Doel:Input:Ouput:Lokaal :Begin

IF Inputl=10 THENOutputl:=Output2-Lokale_variabele

ELSEIF Input2=20 THENOutputl:=Output2+Lokale_variabeleELSE

Geef foutmeldingENDIF

ENDIFEnd

Object-relatiediagrammen

Object-relatie diagrarrunen (ERD: Entity Relation Diagram) worden gebruikt om de op­bouw van opgeslagen data te modelleren. Een ERD bestaat uit objecttypen, relaties,associaties en super/subtype relaties. ERD's zijn vooral van belang voor applicaties diedata-georienteerd zijn, zoals database toepassingen.In figuur 4.2 is een voorbeeld van een ERD gegeven.

Structure charts

De structuur van een taak kan gemodelleerd worden met een structure chart. Ben struc­ture chart beschrijft de verdeling van een taak in modules, de hierarchische organisatievan deze modules en de interfaces ertussen. Structure charts bestaan uit modules, calls,parameterpijlen en datagebieden.In figuur 4.3 is een voorbeeld van een structure chart gegeven.

•

19

ModuleA

ModuleB

ModuleD

data 1

ModuleC

data 1

Figuur 4.3: Een voorbeeld van een structure chart

4.3.2 Gane en Sarson

De methode van Gane en Sarson dateert al van 1977. In [Gane, 1977] wordt een analyse­en ontwerpmethode beschreven die, uitgaande van oude probleemoplossingen een nieuwsysteem ontwerpt. Hierbij wordt gebruik gemaakt van datafiowdiagrammen, datadictiona­ries en structure charts.Gane en Sarson gebruiken een eigen life-cycle model, waarin de volgende stappen genomenmoeten worden:

1. Maak een voorlopige studie van het probleem. Hierbij worden vragen beantwoordals: 'Wat is er mis met de huidige situatie?', 'Welke verbeteringen zijn mogelijk?'en 'Wat is de invloed van een nieuw systeem op het personeel?'. Ook wordt eenvoorlopige kostenschatting gemaakt.

2. Maak een gedetailleerde studie van het probleem. De aktiviteiten van deze studiebestaan uit:

• Definieer wie de gebruikers van het nieuwe systeem zullen zijn.

• Maak een logisch model van.het huidige systeem. Hierbij wordt gebruik gemaaktvan dataflowdiagrammen, datadictionaries en processpecificaties.

• Stel de kostenschatting bij.

3. Ontwikkel een aantal alternatieven. De volgende aktiviteiten moeten ui.tgevoerdworden:

• Bepaal de doeleinden van het nieuwe systeem met behulp van het oude.

• Maak een logisch model van het nieuwe systeem.

20

• Maak voorlopige fysieke ontwerpen.

4. Maak een keuze uit de mogelijke oplossingen.

5. Verfijn het model van het nieuwe systeem. Hiervoor moeten de volgende taken uit­gevoerd worden:

• Verfijn het logische model.

• Maak een database voor het ontwerp en leg vast waar gegevens opgeslagen zullenworden.

• Maak een structure chart van het systeem.

• Definieer de taken die door mensen uitgevoerd moeten worden.

4.3.3 Ward en Mellor

In 1986 publiceerden Ward en Mellor een uitvoerig standaardwerk over het ontwikkelen vansoftware voor real-time systemen (zie rMellor, 1986]). Ze beschrijven hierin een methodedie uitgaat van twee modellen van een systeem: een conceptueel-model en een implemen­tatiemodel.Het conceptueel-model volgens \Vard en Mellor bestaat uit een omgevings- en een gedrags­model.

Het omgevingsmodel is opgebouwd uit:

• een doelbeschrijving: een kort stukje tekst waarin het doel van het systeem beschre­ven wordt,

• een contextmodel: een model van het systeem en zijn omgeving en

• een event-list: een lijst van gebeurtenissen in de omgeving waarop het systeem moetreageren.

Het gedragsmodel bestaat uit:

• een dataflowdiagram met processpecificaties,

• een datadictionary en

• een object-relatiediagram.

De vier laatstgenoemde technieken komen overeen met de beschrijving in de inleiding.Ret implementatiemodel bestaat uit:

• Een processormodel: een verdeling van het conceptueel-model over de processorenwaar het systeem gerealiseerd zal worden. •

21

• Een taakmodel: met een taakmodel wordt een model gemaakt van de software die opeen processor zal draaien. De processen die aan een processor toegekend zijn wordenin parallel uitvoerbare eenheden (taken) verdeeld.

• Een modulemodel: een implementatie van een taak in procedures en funeties.

Ward en Mellor maken een duidelijke scheiding tussen de analyse van het probleem (hetconceptueel-model) en het maken van een implementatie (het implementatiemodel).

4.3.4 Yourdon

De methode van Yourdon is een van de meest bekende software-engineering methoden.De verschillen met de methode van Ward en Mellor zijn te verwaarlozen (Ward en Mellorhoren bij een groep rond Yourdon), we zullen er dan ook niet verder op ingaan.Een groot voordeel van Yourdon is de populariteit die de methode geniet, wat zich uit ineen grote hoeveelheid literatuur en ondersteunende programmatuur (CASE-tools).Meer informatie over de analyse-fase (het conceptueel-model) is te vinden in [Yourdon,1989].

4.3.!} Hatley en Pirbhai

Hatley en Pirbhai (zie [Hatley, 1987]) gebruiken twee modellen, het eisenmodel (komt over­een met een conceptueel-model) en het architeetuurmodel (komt overeen met een imple­mentatiemodel). In figuur 4.4 is een schematisch overzicht van de twee modellen gegeven.In de volgende paragrafen zullen de modellen kort beschreven worden.

Het eisenmodel

Het doel van het eisenmodel is het geven van een implementatie-onafbankelijke specificatievan het systeem; het is dus een conceptueel-model. Zoals in figuur 4.4 weergegeven, bestaathet eisenmodel uit een procesmodel en een besturingsmodel. Het procesmodel omvat een'echt' dataflowdiagram (dus zonder besturingsflows en -processen) met processpecificatiesin gestructureerde taal en een datadietionary. Een ander onderdeel van het eisenmodelwordt gevormd door timingspecificaties. In de vorm van tabellen en timing-diagrammenwordt a.angegeven binnen welk tijdsbestek het systeem een antwoord moet geven op eenbepaalde gebeurtenis.Het besturingsmodel bestaat uit een besturingsflowdiagram. Het doel ervan is hetzelfdeaIs dat van besturingsprocessen en -flows in de dataflowdiagrammen van Ward/Melloren Yourdon, aIleen de opzet is wat anders. Het diagram bestaat uit aIle processen dieook op het dataflowdiagram voorkomen samen met aIle besturingsflows en symbolen dieovereenkomen met een besturingsproces (de zogenaamde 'bar', weergegeven door een kortevertikale streep). De akties van de bars worden gespecificeerd met een toestandsdiagram.De methode schrijft voor dat er voor elk dataflowdiagram een besturingsflowdiagram is.•

22

IIItI,IIL J

II Gebruikersinterrace------------1 I

EisenmodelII

I I

I __dd I I I

I P-,_.~ I, I

I I

I I Input OuputI I verwerkins verwerkins

IBn'_dd I

I II

I I Besturinpmodel

I I

I I

1 I

------_- ____ 1 II Onderhoud en zelf-testII

L

r

Figuur 4.4: Ret systeemmodel volgens Ratley en Pirbhai

In figuur 4.5 is een voorbeeld van een dataflowdiagram gegeven. Figuur 4.6 geeft eenbijbehorend besturingsflowdiagram.

Het architectuurmodel

Ret doel van het architectuurmodel is:

• aangeven uit welke fysieke onderdelen het systeem bestaat,

• de informatiestroom tussen de onderdelen definieren en

• de informatiekanalen vastleggen.

Ret belangrijkste onderdeel van het architectuurmodel is het architectuur flowdiagram.Dit diagram laat de onderdelen van het systeem zien, samen met de informatie die erdooruitgewisseld wordt. Bij 'onderdelen' kan hier ook gedacht worden aan softwaremodules. Deopbouw is hetzelfde als die van dataflowdiagrammen, dus hierarchisch met op het laagste ni­veau tekstuele specificaties. Groepen processen van het dataflow- en besturingsflowdiagramworden toegekend aan de onderdelen van het architeetuur flowdiagram. Het architeetuurflowdiagram vertoont een overeenkomst met het processormodel van Ward en Mellor: hetis een implementatiemodel waarin onderdelen van een implementatie-onafhankelijk modeltoegekend worden aan processoren. De twee concepten zijn echter niet helemaal vergelijk­baar, omdat het architectuur flowdiagram ook softwaremodules kan bevatten.

•Ret architectuur verbindingsdiagram laat zien hoe de informatie tussen onderdelen van het

23

t---8--Figuur 4.5: Een voorbeeld van een da­tafiowdiagram volgens Hatley en Pir­bhai

&-i~ _r-iI

01 6---Figuur 4.6: Het bijbehorende bestu­ringsflowdiagram

fiowdiagram getransporteerd wordt. Typische namen in een verbindingsdiagram zijn bus­sen en kabels. Bij een verbindingsdiagram hoort een verbindingsspecificatie waarin voorelke flow is opgenomen waaruit de informatie bestaat, waar de informatie vandaan komt,waar de informatie naar toegaat en over welk kanaal de informatie getransporteerd wordt.Dit is eigenlijk een tekstuele samenvatting van het flow- en het verbindingsdiagram.Een voorbeeld van de laatste twee diagrammen is gegeven in figuur 4.7. De bovenste figuurgeeft het architectuur fiowdiagram van een automaat (bijvoorbeeld een koffie-automaat)weer; het onderste diagram is het bijbehorende verbindingsdiagram. In tabel 4.1 is eenvoorbeeld van een verbindingsspecificatie gegeven. Het voorbeeld is ontleend aan [Hatley,1987] en hoort bij de diagrammen van figuur 4.7.

24

'fi fb' d'b IdTbl41 Eea e n voor ee van een vel' In mgsspeci ca IeFlow naam Samengesteld uit Bron Doel Kanaal

Objects [Coins I Slugs] External Coin receptacle ExternalCoins Quarters + Coin Product vending Coin

Nickels + Dimes receptacle controller receptacle

STAlUSDISPlAY

PRODUCT AVAILABIUTY

DESIREDSB.E~

tMNTENANCE~TA

SB..fC1lOI/REGIS"TER~TA

CON_--.... RECEPTAClE .-IL--A...&......--- INFO.

(~) (:r)DISPlAY

~I IDISPLAYREGISTER BUSBUS I AaU:T )CON

FE:EPTAClf rJ AaU:T, DISPENSER

( CON ) BUS rAaU:T OISPENSEAFE<:EPTAClfJ ~ BUS

II All CONDISPENSERBUS

CON

~)QfJTE

Figuur 4.7: Ret architectuur f1.owdiagram (hoven) en het architectuur verbindingsdiagram(onder)

25

Ret architectuur flow- en verbindingsdiagram vormen samen het proces- en besturingsmo­del van figuur 4.4. In deze figuur zijn ook nog blokjes 'Gebruikersinterface', 'Inputverwer­king', 'Outputverwerking' en 'Onderhoud en zelf-test' te zien. Ben sterk punt van dezemethode is dan ook dat dit soort zaken als een expliciet onderdeel opgenomen zijn. Dezemethode leent zieh vooral goed voor systemen met een belangrijke hardware component.

4.3.6 De Systems Engineering Methodology

De systems engineering methodology (SEM) is een samenvoeging van een drietal methodendie al een tijdje in gebruik zijn bij de Amerikaanse lucht- en zeemacht. Ret gaat hier omIntegrated Computer-Aided Manufacturing, het Software Cost-Reduction System en desimulatie taal Analysis of Integrated Networks of Tasks. De auteurs van [Wallace, 1987]hebben deze drie methode samengevoegd en uitgebreid tot een sterk hardware gerichteontwerpmethode.De methode is gebaseerd op het maken van modellen van een systeem vanuit een aantalverschillende gezichtspunten. Er worden drie hoofdgezichtspunten onderscheiden:

1. Ret functionele perspectief geeft een beeld van de taken die een systeem uit moetvoeren. Ret bijbehorende modellijkt sterk op een dataflowdiagram, met een aantalminder belangrijke toevoegingen.

2. Ret gedragsperspectief geeft een beeld van het gedrag van het systeem in de tijd.Aan het functionele model worden aktiverings- en deaktiveringsvoorwaarden voorprocessen toegevoegd met behulp van events.

3. Ret informatieperspectief behandelt de structuur en samenhang van de gegevens diehet systeem gebruikt. Ret model voor dit perspectief bestaat uit een soort object­relatie diagram.

Naast deze drie hoofdperspectieven zijn er nog een aantal andere invalshoeken, waaronder:

1. Ret fysieke perspectief (grootte, vorm, gewicht en dergelijke).

2. Zaken zoals betrouwbaarheid, onderhoudbaarheid, beschikbaarheid.

3. Het menselijke-factoren-perspectief (de verbanden tussen mensen, machines en pro-cedures die samen een systeem vormen).

Ben groot probleem bij het toepassen van deze methode is het feit dat er vrijwel geenverband is met een implementatie: er is geen echte ontwerpfase gedefinieerd. Waar weI inis voorzien is het gebruik van een simulatietaal (SAINT genaamd), waarmee een prototypevan het systeem gemaakt kan worden. Op zich is dit bijzonder interessant omdat het deontwerper in staat stelt om op een hoger niveau van abstractie het systeem te testen. Bennadeel is de geringe beschikbaarheid en ondersteuning van de techniek.Ben tweede nadeel is de nogal 'wazige' manier waarop de modellen in het boek beschrevenworden. De schrijvers zijn er niet in geslaagd om helemaal duidelijk te Ill.aken wat zebedoelen.

26

4.4 DatageorH~nteerdemethoden

4.4.1 . Objectgeorienteerd ontwerpen

De data (de objecten) die een systeem manipuleert verandert meestal weinig tijdens desysteemontwikkeling. Wat eventueel weI verandert is de representatie van data, een array­implementatie moet misschien veranderd worden in een implementatie met linked-lists.Als we een programma dat ontwikkeld is met een taakgeorienteerde ontwerpmethode aanmoeten passen aan een dergelijke verandering kan dit tot grote hoeveelheden werk leiden.Er is namelijk niet gegarandeerd dat de wijzigingen beperkt blijven tot een module, omdatde ontwerpmethode daar niet toe dwingt. Vaak is de informatie over de implementatie vaneen datastructuur verdeeld over een aantal modules. Datageorienteerde ontwerpmethodendwingen tot het concentreren van de implementatie van een datastructuur in een module,De continuileit van het ontwerp, dus het voorkomen van grote veranderingen, is het belang­rijkste argument voor data-georienteerde methoden. Bijkomende argumenten zijn compa­tibiliteit (het is makkelijker om stukken software te combineren als de datastructuur waarze mee werken hetzelfde of goed afgeschermd is) en herbruikbaarheid.Ben voorlopige definitie van objectgeorienteerd ontwerp is de volgende (zie [Meyer, 1988]):

Objeetgeorie'nteerd ontwerp is een methode die leidt tot software architeeturen gebaseerd opde objeeten die een systeem manipuleert.

Er zijn twee belangrijke vragen die beantwoord moeten worden: hoe ontwerp je een systeemin termen van objecten en hoe vindt je die objecten?De tweede vraag is eenvoudig te beantwoorden: een object is een computer-representatie

van iets wat door het systeem gemanipuleerd moet worden. Voorbeelden zijn een cameraof een robot in een naadvolgsysteem of een stuk tekst in een editor. Met het oog op

het opnieuw gebruiken van stukken software is het nuttig om niet alleen naar specifiekeobjecten te kijken, maar naar een klasse van objecten, Neem bijvoorbeeld een stack: debasisoperaties die op een stack uitgevoerd kunnen worden zijn hetzelfde voor een stack vanintegers en voor een stack van records. Ben stack in het algemeen zullen we een klasse(Eng: class) noemen, een stack van integers is dan een object van de klasse stack.

•

27

Voor het beschrijven van een klasse kan gebruik gemaakt worden van abstracte datatypen.Hiermee worden objecten beschreven als een verzameling functies.

Bij wijze van voorbeeld zal de stack als abstract datatype beschreven worden. De definitievan stack is als voIgt:

TYPEstack[X]

FUNCTIESempty: stack[X] --+ BOOLEANfull: stack[X] --+ BOOLEANnew: --+ stack[X]push: X x stack[X] ......-+ stack[X]pop: stack[X] ......-+ stack[X]top: stack[X] ......-+ X

PRECONDITIESpre pop (s:stack[X])=(not empty(s))pre top (s:stack[X])=(not empty(s))pre push (s:stack[X])=(not full(s))

AXIOMA'SVx:X,s:stack[X] :empty(newO)not empty(push(x,s))top(push(x,s) )=xpop(push(x,s) )=s

In de definitie zijn de volgende onderdelen gebruikt:

Type In de type-paragraaf worden de gedefinieerde klassen vermeld. In dit geval is ermaar een klasse, en weI stack. Stack heeft een dummy-parameter X die het type vande stack-elementen aangeeft. Met de defil1itie kunnen dus zowel stacks van integersals stacks van records of wat dan ook beschreven worden.

Functies In de functies-paragraaf worden aIle functies die op het type uitgevoerd kun­nen worden opgesomd. Een functie definitie ziet er in het algemeen als voIgt uit:A 1xA2 ••• xAn --+ B1xB2x··· xBm , waarbij de A's en B's typen zijn. Het aantal ar­gumenten links van de pijl kan nul zijn (zie bijvoorbeeld de functie new). Een partielefunctie, weergegeven door een ......-+ symbool in plaats van een pijl, geeft aan dat deoperatie niet voor elk element van het type links van de pijl (bijvoorbeeld 'stack' bijde definitie van pop en push) gedefinieerd is. Pop is gedefinieerd als partiele func­tie omdat een stack minstens een element moet bevatten anders is de operatie niettoegestaan. De operatie is dus, evenals top en push, niet altijd gedefinieerd.

Precondities worden gebruikt om aan te geven in welke gevallen partiele functies gede-•finieerd zijn. Bij elke partiele functie hoort dus een preconditie.

28

Axioma's Met behulp van axioma's wordt semantische informatie aan de syntax definitiesvan de functies-paragraaf toegevoegd. In dit geval wordt voor elke x van het type Xenelke s van het type stack[X] gedefinieerd wat de resultaten van de functies zijn.

Met behulp van de zojuist geintroduceerde terminologie kan een nieuwe definitie van ob­jectgeorienteerd ontwerp gegeven worden:

Objectgeorie'nteerd ontwerp is de constructie van software systemen in de vorm van imple­mentatie van een aantal abstracte datatypen.

4.4.2 Jackson

Jackson Structured Programming (JSP) werd ontwikkeld door Michael Jackson in 1972.Later werd deze programmeermethode uitgebreid tot een methode om grotere systemente ontwikkelen, de Jackson System Development (JSD) methode. De technieken die doorJSP gebruikt worden zijn een deelverzameling van JSD,Berst zal JSP behandeld worden en daarna de uitbreiding tot JSD. Meer informatie is tevinden in [Cameron, 1989].

Jackson Structured Programming

De JSP methode maakt gebruik van vier stappen om een programma te ontwikkelen:

1. Teken struktuurdiagrammen waarmee de opbouw van input- en outputstromen vanhet programma beschreven worden,

2. Voeg de input en output struktuurdiagrammen samen tot ren diagram, het pro­gramma structuurdiagram.

3, Maak een lijst van alle operaties van een gekozen programmeertaal die op de dia­grammen uitgevoerd moeten worden om het probleem op te lossen. Ken de operatiestoe aan eenheden van het diagram.

4. Vertaal het structuurdiagram in een tekstuele vorm, dus in een pseudo-code of meteenin een programmeertaal.

De genoemde structuurdiagrammen ~ijn erg belangrijk in JSP. Ze worden gebruikt omde datastromen van en naar een programma te modelleren. Hiermee wordt het data­georienteerde karakter van de methode duidelijk.

29

Een structuurdiagram kan opgebouwd worden met behulp van drie constructies:

Volgorde:A is opgebouwd uit een B, gevolgd door een C, gevolgd door een

"r--..... D. De volgorde van de elementen is van links naar rechts.

Iteratie:A is opgebouwd uit nul of meer keer B.

Selectie:A bestaat uit 1 B, 1 C of 1 D.

Na het opstellen van de diagrammen voor inputs en outputs, moeten deze samengevoegdworden tot een diagram door te letten op overeenkomende elementen in een input- eneen outputdiagram. In figuur 4.8 is een voorbeeld gegeven van twee samen te voegendiagrammen. De pijlen geven aan welke elementen met elkaar overeenkomen. In figuur 4.9is het resultaat te zien. De voorvoegsels 'C' en 'P' verwijzen naar consumer en producer,dus de output, respectievelijk de input-structuurdiagrammen.

De derde stap is het opstellen van een lijst van operaties die op de data uitgevoerd moetenworden om het probleem op te lossen. Ret gaat hier om zaken zoals bijvoorbeeld hetopenen van output- en inputfiles, het toekennen van waarden aan objecten en dergelijke.De operaties zijn afhankelijk van de g~kozen programmeertaal. Nadat de lijst is opgesteldmoeten de operaties toegewezen worden aan objecten in het structuurdiagram. Dit gebeurtdoor aan de rechthoek waarmee een object weergegeven wordt een nummer te koppelen,zoals in figuur 4.10 De grote rechthoeken met letters erin geven data weer. De kleinererechthoeken met nummers erin geven operaties weer. Elk nummer komt overeen met eenandere operatie.

Tenslotte wordt het diagram omgezet in een pseudo-code, die in een programma vertaaldkan worden. •

30

Producer Consumer

Figuur 4.8: Twee samen te voe­gen structuur-diagrammen

Figuur 4.9: Ret resultaat

A 1

D

4 3 2

Figuur 4.10: Ret toekennen van operaties a.an diagrammen

31

Jackson System Development

De JSD methode is eigenlijk meer een life-cycle model dan een analyse methode. Retmodel bestaat uit drie fasen:

1. maak een model

2. ontwikkel een netwerk van abstracte processen (een soort niet-hierarchisch dataflow­diagram)

3. implementeer het netwerk

In de eerste fase wordt een model van de omgeving van het systeem ontwikkeld, waarbij denadruk komt te liggen op timing-aspecten. De omgeving wordt gezien als een verzamelingprocessen.Gedurende de tweede fase worden de losse processen die tijdens de eerste fase ontstaanwaren verbonden en uitgebreid met extra processen om het probleem op te lossen. Rieruitontstaat een netwerk, de systeemspecificatie.Tijdens de implementatiefase wordt het netwerk omgezet in code die moet voldoen aan dein de eerste fase gestelde timing-eisen.Bij het uitvoeren van de drie fasen kan gebruik gemaakt worden van de technieken vanJSP.

4.5 De gekozen methode

De methode van Gane en Sarson kunnen we eigenlijk weI buiten beschouwing laten, omdatde andere taakgeorienteerde methoden een verbetering ervan zijn.

De methode van Ward/Mellor en Yourdon heeft een aantal voordelen waaronder de grotepopulariteit, de hoeveelheid ondersteunende programmatuur en literatuur en de eenvoudigetoepasbaarheid. Daarnaast sluit de methode goed aan bij de manier waarop veel mensente werk gaan bij het oplossen van een groot probleem. Nadelen zijn de geringe steun die demethode geeft bij het opstellen van een model en het feit dat de gebruiker niet gedwongenwordt om goede modules te maken. Daarom zullen veel systemen die met Ward/Mellorof Yourdon ontworpen zijn minder goed bestand zijn tegen wijzigingen in specificaties enimplementatiebeslissingen.

De methode van Hatley en Pirbhai is zeker bruikbaar, vooral als een groot deel van hetsysteem in hardware geimplementeerd moet worden. Ook voor deze methode is onder­steunende programmatuur beschikbaar. Een nadeel is de overbodige splitsing. van hetdataflowdiagram in een data- en een besturingsgedeelte.

De Systems Engineering Methodology is te slecht beschreven en ondersteund hoewel deuitgangspunten goed zijn. •

32

Objectgeorienteerd ontwerpen heeft voordelen die vooral gezocht moeten worden in decontinuiteit van het ontwerp (het is beter bestand tegen wijzigingen in specificaties) en demate waarin ermee ontworpen prograrnrnatuur opnieuw bruikbaar is. Ben van de nade­len van objectgeorienteerd ontwerpen is dat de gebruiker een nieuwe denkwijze aan moetleren. Dit verhoogt de weerstand tegen de methode, zeker in een rninder op wiskundigeformalismen ingestelde elektrotechnische omgeving.

De methode van Jackson is te sterk gericht op adrninistratieve toepassingen en komt danook niet in aanmerking voor gebruik in real-time omgevingen.

Gezien de goede ondersteuning en de eenvoud vormen de methoden van Ward/Mellor enYourdon goede kandidaten. Gezien de kwaliteit van het ontworpen systeem is objectge­orienteerd ontwerpen ook een uitstekende kandidaat voor toepassing in real-time omge­vingen. Op grond van zuiver technische overwegingen is objectegeorienteerd ontwerpende beste. Deze bewering wordt ook ondersteund door het grote aantal publicaties die delaatste tijd over de methode verschijnen. Een sterk tegenargument is echter dat de ge­bruiker gedwongen wordt om op een andere manier te gaan denken. Dit zal waarschijnlijkzoveel weerstand oproepen dat de invoering van de methode onmogelijk wordt. Daarom isgekozen voor de methode van Ward/Mellor en Yourdon.

Tenslotte moet nog opgemerkt worden dat het beschrijven van een ontwerp met data­fiowdiagrammen het gebruik van technieken van objectgeorienteerd ontwerpen niet uit­sluit. Deze technieken zouden gebruikt kunnen worden om een deel van het systeem tespecificeren, namelijk het deel dat gebruik maakt van datastructuren. Op deze manier ont­staat het onderste niveau van een datafiowdiagram. De ontwerper kan daarna de hogereniveau's ontwikkelen. Het resultaat van dit alles is een structuur die minder afhankelijk isvan wijzigingen in specificaties, maar die toch eenvoudig genoeg te ontwikkelen is.

33

Hoofdstuk 5

CASE-tools·

5.1 Inleiding

De afkorting CASE staat voor Computer Aided Software Engineering. Ben CASE-tool isdan een programma waarmee CASE bedreven kan worden. Er zijn programma's te koopvoor de meeste van de methoden die in hoofdstuk 4 aan de orde zijn geweest. Gezochtwordt.. een programma dat de methode van Yourdon of Ward/Mellor ondersteund.

Workstation-versies

Uit een kort marktonderzoek blijkt dat de meest volledige programmatuur alleen beschik­baar is voor workstations zoals bijvoorbeeld een Sun of een VAX-workstation. Deze pro­gramma's bieden niet aIleen ondersteuning bij het maken van plaatjes (dataflowdiagram­men, structure charts), maar ook bij het ontwerpproces zelf. Ze verzorgen de organisatievan de documentatie en de verschillende versies die er van een systeem zijn. Daarnaast isvaak ook codegeneratie mogelijk. Voorbeelden van dergelijke programma's zijn Teamworken een pakket van het Nederlandse bedrijf Westmount. Helaas is de prijs van een derge­lijk programma evenredig met de geleverde prestaties; een basisconfiguratie kost al snelveertig- tot vijftigduizend gulden. In sommige gevallen zijn onderwijskortingen mogelijk,maar meestal worden die niet zonder meer aan een onderwijsinstelling gegeven. Het istwijfelachtig of de vakgroep ER voor een dergelijke korting in aanmerking komt, gezien desamenwerkingsverbanden met de industrie.

PC-versies

Gelukkig zijn er ook goedkopere alternatieven die op een PC draaien. De mogelijkhe­den zijn wat beperkter (geen codegeneratie, geen configuratiemanagment), maar voor hettekenen van plaatjes en alles wat daarbij hoort voldoen ze uitstekend. Voorbeelden vanprogrammapakketten voor PC's zijn Promod, System Architect en Analyst Designer.In onderstaande hoofdstukken zullen een aantal geevalueerde pakketten besproken worden.Wegens tijdgebrek en onzekerheden over het beschikbare budget is het niet .tot aanschaf

34

van een pakket gekomen. De duurdere versies kunnen niet geevalueerd worden voordat erzekerheid is over het besehikbare budget.

5.2 Promod

Voordelen:

1. Tekenen van diagrammen gaat erg makkelijk.

2. Namen in proeesspeeifieaties kunnen gekoppeld worden aan dataflows in het diagram.Ais deze laatste naam wordt veranderd, wordt de naam in de speeifieatie automatisehegewijzigd.

Nadelen:

1. Promod gebruikt een menustructuur die bijzonder onoverziehtelijk is.

2. Bij het wegsehrijven van een diagram wordt automatisch een syntax eontrole uitge­voerd. Dit is ongewenst maar schijnt weI via een true te omzeilen te zijn.

3. Het tekenveld is klein (een deel van het seherm) waardoor manipulaties met stukkendiagram moeilijk worden.

4. Het splitsen van een flow kan aIleen in twee volledige kopieen, niet in samenstellendeonderdelen.

5. Datadictionary definities zijn erg omslaehtig (twee menustappen voor elke definitie).

6. Er is geen ondersteuning van proeessor- en taakmodellen.

7. Een ontwerp gebruikt zo'n 300 kbyte diskruimte, onafhankelijk van de grote ervan.

8. Het programma is gebruikersonvriendelijk beveiligd (met een teller die verlaagd wordtbij installatie en weer verhoogd bij de-installatie; als iemand het pakket van de hard­disk wist zonder de de-installatie van het programma zelf te gebruiken ben je dus eenkopie kwijt).

9. Het programma werkt traag, zowel bij het wisselen van diagrammen als bij het eon­troleren van de model-regels.

10. Er wordt een afwijkende notatie gebruikt voor besturingsproeessen (Hatley/Pirbhaiin plaats van Ward/Mellor).

11. Onduidelijke handleiding.

Opmerkingen:

1. Dit programma is niet tot in details getest.

2. Meer informatie verkrijgbaar bij ir. Van Weert en ir. Koisteren (vakgroep EB).

35

5.3 System Architect

Voordelen:

1. Makkelijk te bedienen en snel te leren.

2. Redelijk goede ondersteuning van een aantal ontwerpmethoden (Ward/Mellor, Your­don, Gane/Sarson), waarbij opgemerkt moet worden dat het processor- en het taak­modelontbreken.

3. Het opstellen van de datadictionary verloopt erg soepel.

4. Er is een netwerkversie beschikbaar die het mogelijk maakt om met meer personentegelijk aan een ontwerp te werken.

5. Redelijk overzichtelijke handleiding.

6. Dataflows kunnen aan namen in processpecificaties gekoppeld worden.

Nadelen:

1. Het programma draait onder MS-Windows. Dit is eigenlijk niet echt een nadeel(aIleen financieel). Een mogelijk probleem is incompatibiliteit tussen versies vanSystem Architect en versies van Windows.

2. In de geteste versie 1.9 is het printen niet helemaal goed verzorgdj de output wordtsoms weI en soms niet verkleind, underscores verdwijnen. In versie 2.0 zou dit pro­bleem opgelost zijn.

3. Er wordt onderscheid gemaakt tussen flows op het diagram en structures in dedatadictionary. Een flow kan als een structure gedefinieerd worden (bijvoorbeeld:A=B+C). Flow A kan in de datadietionary gedefinieerd worden, waarna het pro­gramma aangeeft dat B en C nog niet gedefinieerd zijn. De gebruiker kan B en Cnu uit een lijst van niet gedefinieerde objecten halen en ze specificeren als elementof als structure. Ais nu de flow A op een diagram van een lager niveau uitgesplitstwordt in flows B en C, en we laten het diagram controleren, dan blijken de flows Ben C als niet-gedefinieerd gerapporteerd te worden. Er zijn redenen voor deze opzet(structures kunnen vaker voorkomen, flows niet) maar het zou weI handig zijn als ereen manier was om structures aan flows te koppelen.

Opmerkingen:

1. Versie 2.0 is binnenkort beschikbaar en draait onder windows versie 3.0. Deze versievan windows zal dus ook aangeschaft moeten worden (prijs fl. 150,-).

2. De prijs bedraagt fl. 4130,- voor de eerste kopie. Bij afname van meer kopieen zakt deprijs per kopie (10% voor de tweede kopie, nog meer korting vanaf de tiende). Vooronderwijsinstellingen geldt een korting van 20%. De netwerkversie is ~O% duurderdan de gewone versie.

36

..

3. Versie 2.0 is uitgebreid met een SQL-achtige taal voor het genereren van rapporten.Dit maakt het mogelijk om zelf te bepalen welke informatie in een rapport vermeldmoet worden.

4. Inlichtingen: Real-Time Software B.V., Strijkviertel 37b, 3454 PJ de Meern, 03406­65530

5.4 Analyst designer

Analyst designer is een van de oudste CASE-tools, ontwikkeld door Yourdon Publishing,een bedrijf dat door Yourdon opgezet is om het publiceren van literatuur en het gevenvan cursussen over zijn methode te organiseren. Het bedrijf heeft een aantal jaren geledenook een CASE-tool voor PC's ontwikkeld, dat gedemonstreerd werd tijdens een inleidendecursus over de Yourdon methode. Helaas ontbrak de mogelijkheid om het programmauitgebreid te testen. Uit foldermateriaal en de demonstratie blijkt dat het programma demethode volledig ondersteund. Ook het gebruikersinterface zag er doordacht uit.Een belangrijk voordeel van Analyst designer is dat het bedrijf nog steeds bezig is metonderzoek naar ontwerpmethoden. Zo is voor de volgende versie een implementatie vanobjectgeorienteerd ontwerpen gepland. Dit geeft wat meer garanties voor ondersteuningen implementatie van nieuwe ontwikkelingen in de toekomst. Een bedrijf dat alleen pro­grammatuur voor bestaande methoden ontwikkeld zal meer achter de feiten aanlopen.Daarnaast is Yourdon Publishing onderdeel van het veel grotere Kodak, waardoor hetvoortbestaan ervan minder onzeker is geworden.Een nadeel van het pakket is de relatief hoge prijs (1900 Pond, dus ongeveer fl. 7000,-).Voor een dergelijke prijs zijn (met kortingen) ook veel krachtiger workstation-versies tekoop.

5.5 CASE-tools voor workstations

CASE-tools voor workstations hebben over het algemeen veel meer mogelijkheden dan PC­versies, waaronder configuratie management, codegeneratie en desktop publishing. Daar­naast is het gebruikersinterface vaak beter: er kan veel meer informatie op een schermweergegeven worden. Tenslotte neemt de snelheid van PC-versies snel af naarmate hetproject groter wordt. Workstations ziin hier wat minder gevoelig voor.Er is informatie beschikbaar over:

• 'Software through pictures' van HAS computer systems BV, Postbus 8362, 1005 AJAmsterdam. Contactpersoon is de heer M.J.M. Cox, 020-5866600.

• Een CASE-tool van het bedrijf Westmount. Contactpersonen zijn de heer Hansen enmevrouw Keuzenkamp, 015-610815.

37

• 'Unified CASE' wordt vertegenwoordigd door Koning en Hartman, Postbus 125, 2600AC Delft. Contactpersoon is de heer de Goede, 015-609889.

• 'Cradle' van Yourdon, Postbus 1000, 3970 BA Driebergen-Rijsenburg. Contactper­soon is de heer Baker, 03405-99976.

38

Hoofdstuk 6

Beschrijving van de gekozenmethoden

In bovenstaande hoofdstukken is de keuze voor SQS en Ward/Mellor beargumenteerd, restnog het geven van een beschrijving van de methoden, zodanig dat iemand er snel mee kanleren werken. Gezien de beperkte tijd die studenten ter beschikking hebben, moet snel hiergezien worden als een, hooguit twee weken.

Beschrijving van SQS

Voor SQS is een mooie, compacte beschrijving beschikbaar in [Hammer, 1990]. Dit artikelgeeft eerst een korte inleiding in life-cycle modellen, het onderscheid tussen project- enproduktdocumenten en een beschrijving van de doelen van elke fase. Tenslotte wordtheel beknopt weergegeven welke aktiviteiten in elke fase uitgevoerd moeten worden enwelke documentatie daarbij geproduceerd moet worden. Het is goed om deze structuuraan te houden, vooral bij afstudeerwerk, zodat een goede planning en voortgangsbewakingmogelijk zijn. De door SQS voorgeschreven documentatie geeft een goede houvast bij hetwerk, niet aIleen voor de begeleiding maar ook voor de student zelf.

Beschrijving van Yourdon

Over de methode van Yourdon zijn diverse boeken en cursussen geschreven. Een probleemmet de boeken is de omvang ervan: ze beslaan gerniddeld meer dan 400 bladzijden, zodatniet van studenten gevraagd kan worden ze door te lezen. Een bijkomend probleem isdat het passief lezen van een boek de lezer niet vertrouwd maakt met het gebruik vande methode; er zal ook nog geoefend moeten worden. Een cursus is wat oefening betreftvaak beter. Helaas zijn commerciele cursussen duur en niet op elk gewenst moment tevolgen. Een alternatief is het aankopen van cursusmateriaal dat door de student zelfdoorgewerkt kan worden. Een mogelijk probleem dat bij deze oplossing naar voren komtis weer langdradigheid, maar ook voorbeelden die weinig met de praktijk te maken hebben(zoals in veel boeken voorkomt) en de vereiste begeleiding kunnen een probleem worden.

39

Een alternatief voor een commerciele uitvoering is een eigen cursus, aangepast aan de wen­sen van de vakgroep. Een bijkomend voordeel hiervan is dat een scheiding aangebrachtkan worden tussen het leren lezen van de gebruikte modellen en het leren opstellen ervan.Vooral voor stagiairs die een stuk code moeten schrijven uitgaande van een implementa­tiemodel, zou een handleiding voor het lezen van modellen handig zijn. Op grond van dezeoverwegingen is een handleiding voor het lezen van grafische modellen en een handleidingvoor het opstellen ervan geschreven.De handleiding voor het lezen is geschreven aan de hand van de FALC-recepten editor, eeneenvoudige teksteditor beschreven in [Kloprogge, 1990]. De FALC-editor is een bestaandsysteem waarbij vrijwel iedereen zich iets voor kan stellen (je zou er zelfs mee kunnen wer­ken). Ret is daarom wat minder 'zwevend' dan de voorbeelden die in de literatuur vaakgebruikt worden.Als iemand eenmaal vertrouwd is met de gebruikte notatie, is het leren opstellen vaneen conceptueel- en een implementatiemodel wat eenvoudiger geworden. Er is een poginggedaan om met behulp van twee voorbeelden een zo volledig mogelijk beeld van de te ge­bruiken technieken te geven. In het eerste voorbeeld is de ontwikkeling van de FALC-editorbeschreven. Omdat de editor een vrij eenvoudig systeem is, waarbij niet aIle aspeeten vaneen conceptueel- en implementatiemodel aan de orde komen, is een tweede voorbeeld uit­gewe:r:kt. Ret gaat hier om een fictieve Japanse limonadefabriek, Limozuki genaamd. Delopende band van de fabriek wordt beschreven, waarna een deel van het systeem gemo­delleerd wordt. De verschillende machines aan de lopende band vragen om een parallelleverwerking in het systeem. Dit geeft goede mogelijkheden om processor- en taakmodellente beschrijven.Voor referentiedoeleinden is nog een alfabetische lijst van termen opgesteld, gevolgd dooreen aantal technieken die bij het opstellen van modellen gebruikt kunnen worden.Ret kursusmateriaal is in de appendix opgenomen.

40

Hoofdstuk 7

Conclusies en aanbevelingen

7.1 Conclusies

Uit het literatuuronderzoek blijkt dat er in het algemeen in de industrie een grote behoefteis aan methoden waarmee op gestructureerde wijze software ontwikkeld kan worden. Ookde vakgroep ER heeft behoefte aan gestructureerde software-ontwikkeling.Om de problemen die komen kijken bij het ontwikkelen van software op te lossen zijneen groot aantal methoden ontwikkeld, waaronder methoden voor management van de Ie­venscyclus van een systeem en methoden voor analyse en ontwerp. Uit al deze methodenis gekozen voor de managementmethode SQS en de analyse- en ontwerpmethode volgensYourdon en \Vard/Mellor.Voor SQS is een goede inleidende tekst gevonden die gebruikt kan worden als instruetie­materiaal.Voor Yourdon en \Vard/Mellor is geen geschikt (betaalbaar en praktisch bruikbaar) in­structiemateriaal gevonden. Dit materiaal is zelf geschreven in de vorm van een inleidendhoofdstuk over het lezen van grafische modellen gevolgd door een bespreking van tweevoorbeelden waarmee geillustreerd wordt hoe een model van een systeem opgezet kan wor­den. Hierbij wordt ook gebruik gemaakt van SQS, zodat een manier van documenterengedemonstreerd kan worden. Tenslotte is een referentielijst opgesteld waarin in alfabetischevolgorde aIle termen uit SQS en Yourdon verduidelijkt worden. Deze lijst wordt gevolgddoor een beschrijving van een aantal technieken voor het opstellen van modellen.Er is gekeken naar CASE-tools die de methode van Yourdon en Ward/Mellor ondersteunen.Er zijn goedkope PC-versies beschikbaar die waarschijnlijk bruikbaar zijn om de vakgroepvertrouwd te maken met het fenomeen. Later kan dan overschakeld worden op de veelkrachtiger (maar ook veel duurdere) versies voor workstations.

7.2 Aanbevelingen

Het geschreven cursusmateriaal moet uitgeprobeerd en eventueel bijgesteld worden. Omte voorkomen dat de resultaten van dit werk in de kast verdwijnen is het absoluut noodza-

41

kelijk dat een CASE-tool aangeschaft wordt. Zonder een dergelijk tool is het erg moeilijken tijdrovend om de methode van Yourdon toe te passen. Ret lijkt dan ook nauwelijksverantwoord om een dergelijke methode verplicht te stellen als er geen ondersteunendeprogrammatuur is.Er is alleen gekeken naar de ontwikkeling van software, hoewel SQS en de analyseme­thode van Yourdon ook bruikbaar zijn voor hardwaresystemen of combinaties van soft- enhardware. Vanaf het taakmodel wordt de beschreven ontwerpmethode weI specifiek voorsoftware. Er zou verder onderzoek gedaan kunnen worden naar een methode waarmeeook de hardware-implementatie gestructureerd uitgevoerd kan worden. De methode vanRatley/Pirbhai biedt interessante aanknopingspunten.Objectgeorienteerd ontwerpen is een techniek die sterk in opkomst is. Er was onvoldoendetijd om de mogelijkheden ervan voor real-time besturingssystemen te onderzoeken. Omdatde industrie, zoals bijvoorbeeld Yourdon Publishing, zich op deze methode aan het con­centreren is lijkt het zinvol om nader onderzoek te doen naar de toepassingsmogelijkhedenervan.Een ander aandachtspunt is het systematisch testen van programmatuur. Over dit on­derwerp is veel geschreven. Ret is waarschijnlijk zinvol om ook hier een inventarisatie temaken zodat het totale ontwikkelproces zo gestructureerd mogelijk kan verlopen.

42

Literatuur

[Boehm, 1981] Boehm, B.W., Software engineering economics, 1981 Prentice-Hall Inc

[Cameron, 1989] Cameron, J.R., JSP and JSD: the Jackson Approach to Software Deve­lopment (Second Edition)., 1989 IEEE Computer Society Press, bse: dfb 89 jsp

[Eilers, 1989] Eilers, H.B., Systeemontwikkeling op kleinere schaal met SDM., 1989 Acade­mic service, bsr: dfx 89 eil

[Gane, 1977] Gane, C, T. Sarson, Structured Systems Analysis: Tools & Techniques, 1977Improved System Technologies, bsk: dfx 77 gan

[Hatley, 1987] Hatley, D.J., LA. Pirbhai, Strategies for Real-Time System Specification,1987 Dorset House Publishing Co., bsa: ddt 87 hat

[Hammer, 1990] Hammer, D.K., K.M. van Hee, Fasering en documentatie in software eng­ineering, Informatie jaargang 32, TIr. 2, pag. 105 tim 232, 1990

[Hice, 1988] Hice, G.F., SDA! for technical information systems., 1988 Pandata BV, Rijs­wijk

[Kloprogge, 1990] Kloprogge, 1., Ontwerp van een besturingssysteem voor de FALC, 1990TV Eindhoven, vakgroep ER, afstudeerverslag

[Mellor, 1986] Mellor, S.J ., T. Ward, Structured Development for Real- Time Systems, ~TO_

lume 1, 2 and 3, 1986 Prentice Hall, bsa: ddt 85 war

[Meyer, 1988] Meyer B., Object-oriented Software Construction, 1988 Prentice Hall, bsr:dfx 88 mey

[Turner, 1988] Turner, W.S., R.P. Langerhorst, G.F. Hice, H.B. Eilers, A.A. Uijttenbroek,SDM, system development methodology., 1988 Pandata BV, Rijswijk, bsw: dfx 88 sys

[Wallace, 1987] Wallace, R.H., J.E. Stockenberg, R.N. Charette, A Unified Afethodologyfor Developing Systems, 1987 Intertext Publications, Inc, bsr: dfb 87 wal

[Yourdon] Yourdon, E., Modern Structured Analysis, 1989 Prentice Hall, Inc. bas: dfx 89you

43

Hoofdstuk 8

Appendix

8.1 Inleiding

Deze appendix bevat een handleiding voor het lezen van grafische systeemmodellen, tweecase-studies over het ontwerpen van een systeem waarbij gebruik gemaakt is van SQS ende methode van \Vard/Mellor en een referentielijst waarin alle begrippen die bij SQS enWard/Mellor aan de orde komen beschreven staan, samen met een beschrijving van eenaantal nuttige technieken bij het opstellen van grafische modellen.

44

Inhoud

1 Inleiding 5

2 Ret Software Quality System 7

3 Ret lezen van grafische systeemmodellen 93.1 Inleiding ........ 93.2 Ret voorbeeld ........ 113.3 Ret conceptueel-model ... 11

3.3.1 De doelbeschrijving . 133.3.2 Ret contextdiagram . 133.3.3 De event-list ..... 163.3.4 Ret dataflow diagram . 183.3.5 De datadictionary . . . 253.3.6 Processpecificaties 303.3.7 Object-relatie diagrammen 35

3.4 Ret implementatiemodel .. 363.4.1 Ret processormodel . 363.4.2 Ret taakmodel 373.4.3 Ret modulemodel 44

3.5 Antwoorden ....... 49

4 Het ontwerp van de FALC-recepten editor 534.1 Inleiding ....... 534.2 De omgevingsanalyse . 534.3 Eisendefinitie ..... 544.4 Ret conceptueel-model 55

4.4.1 De doelbeschrijving . 55

1

Inhoud

4.4.2 Ret contextdiagram. .4.4.3 De event-list .4.4.4 Ret dataflow diagram.4.4.5 De datadictionary . . .4.4.6 De processpecificaties .

4.5 Ret implementatiemodel ..4.5.1 Ret processormodel .4.5.2 Ret taakmodel .4.5.3 Ret modulemodel

4.6 Code .4.7 Randleidingen.4.8 Antwoorden

5 Een opdracht5.1 Inleiding.............5.2 Een automatische boormachine5.3 Een oplossing . . . . . . . .

5.3.1 De omgevingsanalyse .5.3.2 Eisendefinitie . . . . .5.3.3 Ret conceptueel-model5.3.4 Ret implementatiemodel

6 Limozuki6.1 Inleiding.......6.2 De omgevingsanalyse6.3 Eisendefinitie . . . .6.4 Ret conceptueel-model

6.4.1 De doelbeschrijving .6.4.2 Ret contextdiagram .6.4.3 De event-list .....6.4.4 Ret dataflowdiagram6.4.5 De datadictionary. .6.~.6 De processpecificaties .6.4.7 Ret Objeet-relatie diagram.

6.5 Ret implementatiemodel ..6.5.1 Ret processormodel .6.5.2 Ret taakmodel ...

565758666770707174828283

959596989898

100110

115115115120121121121125128142142145146146147

2

Inhoud

6.5.3 Het modulemodel 1596.5.4 De rest. 168

6.6 Code ......... 1696.7 Handleidingen . 1696.8 Antwoorden 169

7 Referentielijst 1957.1 Inleiding .. 1957.2 Lijst van termen 1957.3 Technieken. . . . 221

7.3.1 Het opstellen van een DFD . 2217.3.2 Interfacetechnologie. . . . . 2247.3.3 Naamgeving . .. I ............ 2257.3.4 Het toewijzen van processen aan pro-

cessoren .................................. 2277.3.5 Het toewijzen van processen aan taken 2377.3.6 Toewijzing van tijd-discrete processen . 2437.3.7 Het modelleren van interfaces .......... 2437.3.8 Het vertalen van een netwerk in een hie-

rarchie ............... 2467.3.9 Verfijning van de structure chart 252

8 Literatuur 257

3

Hoofdstuk 1

Inleiding

Er zijn een groot aantal technieken ontwikkeld voor het ge­structureerd ontwerpen van software systemen. Een aantaldaarvan zijn gericht op administratieve toepassingen, ande­ren zijn meer geschikt voor real-time systemen. \Ve zullenons hier op deze laatste klasse van systemen concentreren.Dit artikel beschrijft een aantal grafisch-georienteerde metho­den, ontleend aan Yourdon en Ward/Mellor (zie [Yourdon,1989] en [Mellor, 1986]). We zullen eerst de gebruikte no­tatie en terminologie van deze methoden uitleggen en daarnapas ingaan op het ontwikkelen van programmatuur. TenslottevoIgt een referentielijst waarin alle termen en technieken op­genomen ZlJn.

5

Hoofdstuk 2

Het Software QualitySystem

SQS is een zogenaamd lifecycle model, dat wi! zeggen een me­thode waarmee de ontwikkeling van het systeem beschrevenkan worden vanaf het moment waarop iemand de behoefte er­aan constateert tot op het moment waarop besloten wordt hetsysteem te vervangen. Het model schrijft voor welke aktivitei­ten uitgevoerd moeten worden en wat voor soort documenta­tie daarbij geproduceerd moet worden. Dit heeft als voordeeldat de ontwikkeling van programmatuur voor iedereen die demethode kent eenvoudig te volgen is. De voortgang van eenproject en de resultaten die het heeft opgeleverd zijn eenvou­dig terug te vinden.SQS is ontwikkeld door de faculteit informatica van de TUEin samenwerking met het ITP en is beschreven in [Hammer,1990]. Dit artikel is een goede en compacte introductie in debelangrijkste onderdelen van SQS.Opdracht 2.1: Lees [Hammer, 1990].

7

conceptueel­model

Hoofdstuk 3

Het lezen van grafischesysteemmodellen

3.1 Inleiding

SQS schrijft voor dat er een conceptueel-model en een imple­mentatiemodel gemaakt moeten worden. Dergelijke model­len kunnen op veel manieren gemaakt worden, waarvan eenkorte beschrijving er een is. Korte beschrijvingen geven helaasslechts weinig informatie, vooral als anderen verder moetengaan met de ontwikkeling van een project. Daarom is gezochtnaar methoden om een probleem te analyseren en vervolgenste implementeren. Er is gekozen voor de methode van Your­don en Ward/Mellor, omdat deze eenvoudig te leren is enbruikbare modelIen oplevert. De twee belangrijkste modelIendie gemaakt moeten worden volgens de methode van Yourdonsluiten goed aan bij het conceptueel- en implementatiemodelvan SQS.De bedoeling van dit hoofdstuk is de lezer vertrouwd te ma­ken met de terminologie en notatie die bij de modelIen vanYourdon en Ward/Mellor gebruikt worden. Dit gebeurt aande hand van een voorbeeld, de FALC-recepten editor.Zoals hierboven vermeld, zijn er twee 'hoofdmodelIen', hetconceptueel-model en het implementatiemodel. Ret eerste is

9 •

implementatiemodel

omgevingsmodel

gedragsmodel

bedoeld als hulpmiddel om inzicht te verkrijgen in de functio­naliteit van een systeem, het tweede legt de struetuur van degebruikte hardware (processoren waarop het systeem draait)en de structuur van de software in de vorm van taken en mo­dules vast.Ret conceptueel-model bestaat uit de volgende onderdelen(zie ook figuur 3.1):

• een model van de omgeving van het systeem opgebouwduit

- een beschrijving van het doel van het systeem

- een contextdiagram

- een event-list

• een model van het gedrag van het systeem opgebouwduit

een data flow diagram

een data dictionary

- processpecificaties

- een object-relatie diagram

Ret implementatiemodel bestaat uit:

• een processormodel

• een taakmodel

• een modulemodel

De interpretatie van deze modellen zal in onderstaande hoofd­stukken beschreven worden aan de hand van een voorbeeld,de FALC-recepten editor.

•Ret lezen van grafische systeemmodellen 10

data flow diagramdatadictionary

proceaapec:ificatieatoeatandadiagrammenobject.relatie diagram

doelbeschrijvingcontextdiagram

event.liatr-----------.,I ledrapmode1

IIIII

IIIII IL -l

,------------...,I omseviDpmode1IIII

Figuur 3.1: Het conceptueel-model volgens de Yourdon me­thode

3.2 Het voorbeeld

FALC-recepteneditor

Ais voorbeeld zal de FALC-recepten editor gebruikt worden.Dit is een eenvoudige tekst-editor die ontwikkeld is in hetkader van het FALC-project waaraan de vakgroep ER deel­neemt. De editor is bedoeld om op eenvoudig wijze recepten,korte stukken tekst waarmee een produktieproces beschrevenwordt, in te kunnen voeren. Ben recept bestaat uit letters,cijfers en de gebruikelijk scheidingssymbolen. De gebruikermoet de cursor met behulp van de gebruikelijke toetsen doorde tekst kunnen bewegen. Tenslotte moet een recept op diskopgeslagen en weer teruggelezen kunnen worden.

3.3 Het conceptueel-model

abstract systeem

Ben conceptueel-model is bedoeld om inzicht te verkrijgenin de functionaliteit van het systeem. Volgens de definitiein [Hammer, 1990] is het conceptueel-model een abstx:act sys-

Ret lezen van grafische systeemmodellen 11

omgevingsmodel

gedragsmodel

teem waarvoor geldt dat elke materialisering of implementatievoldoet aan de eisen. Ret dient:

• om de existentie aan te tonen van een systeem dat aande eisen voldoet en

• als formele specificatie voor bet implementatiemodel

Ret conceptueel-modellaat zien:

1. welke funeties bet systeem vervult,

2. welke inputs daarvoor nodig zijn en welke outputs ge­produceerd worden (de interaktie met de omgeving),

3. welke deelfuncties uitgevoerd moeten worden om de to­tale systeemfunctie te verwezenlijken,

4. welke data binnen het systeem getransporteerd en op­geslagen wordt.

De eerste twee taken worden gerealiseerd met bebulp van betomgevingsmodel. Dit model bestaat uit:

• een globale bescbrijving van bet doel van bet systeem,

• een contextdiagram waarin aangegeven worden met wel­ke zaken uit de omgeving bet systeem comrnuniceert,

• een event-list, een lijst van gebeurtenissen waarop betsysteem moet reageren.

Taken 3 en 4 worden verwezenlijkt met behulp van bet ge­dragsmodel. Dit model bestaat uit:

• bet dataflow diagram dat aangeeft welke deelfuncties betsysteem vervult en welke data er tussen deze funetiesuitgewisseld wordt,

• de datadictionary die een formele specificatie van de da­taflows binnen bet systeem geeft,

Ret lezen van grafische systeemmodellen 12

• processpecificaties die een tekstuele beschrijving van pro­cessen geven,

• object-relatie diagrarrnnen die de structuur van opgesla­gen data (in bijvoorbeeld databases) modelleren.

3.3.1 De doelbeschrijving

De beschrijving van het doel van het systeem is een globaleopsomming van functies waar het systeem verantwoordelijkvoor is. De beschrijving is opzettelijk vaag en kort (niet langerdan een alinea) om niet bij voorbaat oplossingen uit te sluitenen zoveel mogelijk het 'implementatie-denken' te voorkomen.

Het doel van de FALC-editor

Ret doel van de FALC-recepten editor is de gebruiker in staatstellen om op een eenvoudige manier recepten (korte stukkentekst) in te voeren.

3.3.2 Het contextdiagram

Ret contextdiagram diagram beschrijft:

• de grens tussen het systeem en zijn omgeving

• mensen, organisaties en systemen waarmee het systeemcorrnnuniceert

• data die het systeem van de buitenwereld krijgt of ernaartoe stuurt

• opgeslagen data die het systeem samen met de buiten­wereld gebruikt.

Ret lezen van grafische systeemmodellen 13

Tenninalor 1

Tenninator 2

~~

Terminator

Dataflow•

Tennin8lor 3

Figuur 3.2: Voorbeeld van een contextmodel

In figuur 3.2 is weergegeven uit welke komponenten een con­textdiagram opgebouwd kan zijn. Bovenstaande aspecten ko­men in de figuur voor, behalve de opgeslagen data die in pa­ragraaf 3.3.4 beschreven zal worden. Een proces wordt weer­gegeven door een cirkel met daarin de naam en het nummervan het proces. Ret proces in het contextdiagram is nooitgenummerd. De functie van een proces is het ornzetten vaninputs (pijlen naar het proces toe) in outputs (pijlen van hetproces af). Ret contextdiagram bevat altijd slechts een procesdat het te ontwerpen systeem voorstelt.De rechthoeken zijn terminators, objecten uit de omgevingwaarmee het systeem communiceert. Een terminator kan eenmin of meer intelligent apparaat zijn, maar ook een schake­laar, een thermometer, een computer of een mens.De pijlen zijn dataflows (data-objecten in beweging). Derichting van de pijl is belangrijk omdat daarmee aangegevenwordt of de data als input (naar een proces toe) of als out­put (van een proces af) gezien moet worden. Elke dataflowheeft een naam, behalve in de uitzonderinsgevallen die in pa­ragraaf 3.3.4 aan de orde zullen komen.

Ret lezen van grafische systeemmodellen 14

data-object

Tijd-continuedataflow

Toelsenbord

Figuur 3.3: Ret contextmodel van de FALC-editor

Als data-object zal meestal elektrische informatie gebruiktworden. Totaal andere dingen als rekeningen, betonblokkenen vrachtwagens zijn ook mogelijk, maar dan is meestal sprakevan een bedrijfskundig gebruik van de hier beschreven model­leringstechnieken.Er zijn tijd-discrete dataflows zoals die in figuur 3.2, die alleenop een bepaald tijdstip een waarde hebben en tijd-continuedataflows die altijd een waarde hebben. Een voorbeeld vandeze laatste soort flows is een spanning waarmee de tempe­ratuur of iets dergelijks aangegeven wordt. Tijd-continue da­taflows worden weergegeven door een dubbele pijl.

Het contextmodel van de FALC-editor

In figuur 3.3 is het contextdiagram van de editor te zien.We zien hier het proces 'FALC-recepten editor' en de ter­minators 'Toetsenbord', 'Beeldscherm' en 'Disk'. Ret procesheeft 'Toetsaanslagen' en 'Receptin' als input-dataflows en'SchermJrifo' en 'Recept-uit' als output-dataflows. Aile da­taflows zijn tijd-discreet.

Het lezen van grafische systeemmodellen 15

Opdracht 9.1

Opdracht 9.2

Opdracht 9.9

Opdrachten

Wat is er fout met het hiernaast getekende proces?

En wat is er fout met ditproces?

En wat is er zoal fout metdit proces?

-0-

-(0

oOpdracht 9.4 Wat is er zoal fout met ne­

venstaand contextdiagram?

3.3.3 De event-list

T1

T2

externe events

In het algemeen is een event 'een belangrijke gebeurtenis'waarop het systeem moet reageren. Voor het contextdiagramzijn alleen externe events van belang. Deze events voldoenaan drie eisen:

1. Ze treden op in de omgeving van het systeem.

Ret lezen van grafische systeemmodellen 16

2. Ze starten een van te voren gedefinieerde aktie van hetsysteem.

3. Ze treden op een bepaald tijdstip op.

Er zijn drie soorten events:

• events gekoppeld aan datafiows (de ontvangst van eenbepaalde boodschap bijvoorbeeld),

• events die met een bepaalde frequentie optreden (eentimer-interrupt),

• events die een wens van een gebruiker weergeven, waar­bij nog niet is vastgelegd hoe de gebruiker die wens ken­baar zal maken (de gebruiker wenst een regel uit hetrecept te verwijderen).

De event-list van de editor

De event-list van de editor ziet er als voIgt uit:

1. De gebruiker wil een karakter toevoegen.

2. De gebruiker wil de cursor verplaatsen (een karakternaar links of naar rechts, een regel omhoog of omlaag,naar het begin of einde van de regel, een bladzijde om­hoog of omlaag, naar het begin of einde van de tekst).

3. De gebruiker wil het karakter voor de cursor wissen.

4. De gebruiker wil het karakter onder de cusor wissen.

5. De gebruiker wil een regel wissen.

6. De gebruiker wil een recept opslaan.

7. De gebruiker wil een recept inlezen.

Ret lezen van grafische systeemmodellen 17

invoerapparaat

sensors

deelfuneties

data-uitwisseling

contextdiagram

'Figuur l'

Store

Rier treden eigenlijk alleen de derde soort events (de wens vande gebruiker) op. Dat komt omdat een algemeen invoerappa­raat (een toetsenbord) gebruikt wordt, waar sleehts een soortinformatie door geprodueeerd wordt. Als er meer flows uit deomgeving komen, bijvoorbeeld informatie van sensors, zullener meer events naar aanleiding van flows gevonden worden.

3.3.4 Het dataflow diagram

Ret dataflow diagram (DFD) geeft weer uit welke deelfunetieshet systeem is opgebouwd en welke data er door deze fune­ties uitgewisseld wordt. Ret DFD is een hierarehiseh model;het systeem wordt gezien als een aantal functies die op hunbeurt weer opgebouwd kunnen zijn uit deelfuneties. Ook dezedeelfuneties kunnen weer opgedeeld worden. De bovenste laagvan het DFD wordt gevormd door het eontextdiagram. Retene proees van dit diagram wordt uitgewerkt in 'Figuur 1',waarmee een eerste indeling van het systeem gegeven wordt.In figuur 3.4 is weergegeven hoe een proees in deelproeessengesplitst wordt.In deze figuur zijn een aantal nieuwe zaken te zien, zoalsde store, weergegeven door twee horizontale strepen met eennaam ertussen. Ben store is bedoeld om aan te geven dat in­formatie opgeslagen wordt, in tegenstelling tot flows die datain beweging voorstellen.De flows die met de store verbonden zijn hebben de volgendebetekenis:

• De flows naar een store toe geven aan dat het proeeswaar de flow vandaan komt de inhoud van de store wij­zigt.

• Flows van een store af geven aan dat het proees aan deandere kant van de flow data uit de store leest.

In beide gevallen geldt dat de hele inhoud van de store ofsleehts een gedeelte ervan gewijzigd of uitgelezen kan worden.Als de flow geen naam heeft (of dezelfde naam als d~ store)

Het lezen van grafische systeemmodellen 18

Tenninalor 1

/I\\

\"-

"­ , , ----- -----

TennlrBor2

/'

Figuur 3.4: Ret uitwerken van een proces in deelprocessen

Ret lezen van grafische systeemmodellen 19

Bericht•Bevestiging

stores en flows

fl9uur 0: een ...aelndeli1

Figuur 3.5: Figuur 0 van de FALC-recepten editor

wordt de hele inhoud van de store in een keer geschreven ofgelezen. Als de flow een naam heeft die verschilt van die vande store wordt een deel van de inhoud geschreven of gelezen.Behalve de stores zijn ook de dubbele pijlen nieuw. Een dub­bele pijl geeft twee sterk met elkaar verbonden flows weer.Ben voorbeeld is een bericht en een bevestiging. In figuur 3.4is gebruik gemaakt van dubbele pijlen om plaats te sparen ophet diagram.

Figuur 1 van de editor

In figuur 3.5 is 'Figuur l' van de editor gegeven. We zien indeze figuur de processen 'Beheer scherm' en 'Beheer recept',de stores 'Recept' en 'Cursor positie' en de flows 'SchermJnfo','Recept_uit', 'ReceptJn', 'Toets..a.anslag' en 'Rerstel'. De flowsdie met de twee stores verbonden zijn hebben geen naam, duslees- en sc~ijfaktieshebben betrekking op de hele inhoud vande stores.We zien in deze figuur ook hoe de processen genummerd wor­den. Ret proces in het contextdiagram heeft geen nummer.Ret wordt uitwerkt in figuur 0, waarin we processen 1 en 2 vin-

Ret lezen van grafische systeemmodellen 20

•

nummering

Figuur 3.6: Figuur 2 van de FALC-recepten editor

den. Proces 2 kunnen we weer verder uitwerken in figuur 2,met de processen 2.1, 2.2 en 2.3 (zie figuur 3.6). Op dezemanier ontstaat een hierarchie van processen die een steedsnauwkeuriger omschreven functie uitvoeren.

Het lezen van grafische systeemmodellen 21

Deell

F~Deel2

F~

Deell?WDeel2

Flow?WFlow

In figuur 3.6 komt nog een eigenschap van flows naar voren: zekunnen opgebouwd zijn uit deelflows. De flow 'Toetsaanslag'wordt gesplitst in 'Verplaats_opdracht', 'RecepLtekst', 'Ver­wijder_opdracht', 'Disk_opdracht' en 'Receptnaam'.Dat wilzeggen dat 'Toetsaanslag' niet een object was maar een verza­meling van de bovengenoemde objeeten. Op het contextdia­gram was deze informatie niet zo interressant en dus is daareen flow getekend in plaats van vijf. Omdat de informatienu naar verschillende processen moet wordt 'Toets-aanslag'verdeeld in zijn samenstellende komponenten. Je kunt eensamengestelde flow zien als een bos draadjes die samen in eenomhulsel zitten, bijvoorbeeld een printerkabel. AIle draadjesgeven onafhankelijk van elkaar informatie maar zijn voor hetgemak binnen hetzelfde omhulsel gebracht.Informatie kan ook naar meer dan een proces gaan, wat aan­gegeven wordt door de flow te splitsen in delen die dezelfdenaam hebben als de oorspronkelijke flow (of helemaal geennaam mag ook). Andersom kan ook: een flow kan samenge­steld worden uit verschillende deelflows.We kunnen ook OR-operaties uitvoeren op flows door tweeflows met dezelfde naam samen te stellen.

Ret lezen van grafische systeemmodellen 22

Opdrachten

Opdracht 3.5Welke informatie loopt over D~de twee naamloze pijlen?

Test

Opdracht 3.6Uit welke informatie is de D~flow 'data' samengesteld?

Data

Opdracht 3.7Wat is er fout met de hier ~naast getekende store?

store •

Opdracht 3.8Wat is er fout met de hiernaast getekende store?

store

Opdracht 3.9 Wat doet dit proces?

Opdracht 3.10 Zie figuur 3.7. Geef de namen van de flows met een vraagtekenerbij in de 6nderste figuur. Geef de nummers van de processen.Welk nummer zou de onderste figuur moeten hebben?

Ret lezen van grafische systeemmodellen 23

.......

? ,1

//

// ?

I \I I\

I\

/\\ /

'\ /

"/

'"/

........ ,/

....... ,/.,.,-

Figuur 3.7: Uitwerkins van proces 'P1.3'

Het lezen van grafische systeemmodellen 24

betekenis, typeen samenstelling

3.3.5 De datadictionary

De data dictionary is een geformaliseerde lijst van aIle ob­jecten in het systeem. Ret doel is het vastleggen van debetekenis, het type en de samenstelling van elk object. Elkedefinitie in de data dictionary beschrijft dan ook deze drieaspecten van het gedefinieerde object:

. 1. de betekenis: de rol die het object speelt in het systeem

2. het type: de waarden die het object aan kan nemen

3. de samenstelling: de verzameling objecten waaruit hetgedefinieerde object bestaat (deze verzameling kan leegzijn)

De gebruikte notatie is als voIgt:Een definitie wordt ingeleid door de naam van het te definierenobject gevolgd door een '='-teken. Daarna voIgt de definitiezelf die opgebouwd kan worden met de onderstaande construc­ties:

1. + : samenstelling

2. (tekst): het deelobject tekst is optioneel

3. ondergrens{ tekst}bovengrens : nul of meer keer deelob­ject tekst, ondergrens en bovengrens zijn optioneel

4. [keuzel} I keuze2 I ... I keuzfn]: kies ren van de alterna­tieven tussen de vierkante haken. I wordt gebruikt alsscheidingsteken voor de alternatieven.

5.• tekst .: tekst is commentaar

6. @ tekst: tekst is een sleutelveld in een store (aIleen vantoepassing in verband met object-relatie diagrammen,zie paragraaf 3.3.7)

7. 'tekst': tekst is een constante

Het lezen van grafische systeemmodellen 25

introductie

elementaireobjecten

iteratie

selectie

De definities voor objecten worden als voIgt opgesteld:

• Een object wordt geintroduceerd met het '=' symbool.De definitie bestaat uit de naam van het object gevolgddoor het '=' symbool en

de betekenis van het object (gegeven in de vormvan kommentaar)

- de samenstelling van het object (bijvoorbeeld "po­sitie=rij + kolom", dus "positie" is samengestelduit "rij" en "kolom")

- waarden die het object aan kan nemen, de eenheiden nauwkeurigheid van deze waarden (in de vormvan kommentaar).

• Elementaire objecten hebben geen decompositie, dushet tweede element van bovenstaande definitie is afwe­ZIg.

• Iteratie wordt weergegeven door een object tussen ac­colades te plaatsen. Er kan een onder- en bovengrensaangegeven worden: de ondergrens wordt voor de ope­ningsaccolade geplaatst, de bovengrens komt achter desluitingsaccolade. Beide grenzen zijn optioneel en zou­den voor de overzichtelijkheid eigenlijk net zo goed inde vorm van kommentaar opgenomen kunnen worden.Een voorbeeld is "naam=3{karakter}10", wat betekentdat "naam" uit minstens 3 en minimaal 10 "karakter's"kan bestaan.

• Selectie wordt weergegeven door een aantal mogelijkealternatieven, onderling gescheiden door het 'I' sym­bool, tussen vierkante haken te plaatsen. De definitie"keuze=aanluit" betekent dat "keuze" de waarde "aan"of de waarde "uit" kan hebben.

Ret lezen van grafische systeemmodellen 26

Toelsenbord

Figuur 3.8: Het contextmodel (herhaling)

De datadictionary van de editor De flows van figuur 3.8kunnen gedefinieerd worden met het onderstaande fragmentuit de datadictionary van de editor:

BeeldJ.nfo =X-pos + Y_pos + Tekst* Opdra.cht aan bee1dscherm hardware om cursor op eenbepa.alde plaats te zetten en daa.rna de tekst toe te voegen.

*Disk..opdracht = ['Lees_opdra.cht' I 'Schrijf..Dpdra.cht ']

* Opdra.cht om een recept in te lezen of weg te schrijven. *Herstel =['HersteLscherm' I 'Herstel.~egel']

* Geeft aan het proces 'Beheer scherm' de opdra.cht een stukvan het scherm of een stuk van de huidige regel opnieuw teschrijven. *

RecepLin =Recept* De recepttekst uit een diskfile. *

RecepLnaam =1{Naamsymbool}12* Na.a.m van een recept. *

RecepLkarakter = [ Letter I Cijfer I Scheidingssymbool)* Mogelijke karakters wa.a.ruit een recept ka.n bestaan. *

Ret lezen van grafische systeemmodellen 27

RecepCuit = Recept* De recepttekst voor een diskfile. *

Toetsenbord..input =[Receptnaam I Disk-Opdracht IVerplaats_opdracht I RecepLkarakter I Verwijder_opdracht]* Input van het toetsenbord. *

Verplaats-Opdracht = ['Binnen-regel' I 'Twee-regeLverplaats' I'Scherm_verplaats' I 'Boven_onder_verplaats']* Opdracht om de cursor te verplaatsen. *

Verwijder_opdracht = ['Delete_opdracht' I'Verwijder-regeLopdracht' I 'Backspace_opdracht ']* Opdracht om een karakter of een regel te verwijderen. *

Opmerking: de flow "Disk_opdracht" kan ook als voIgt gede­finieerd worden:

Disk-Opdracht = Lees_opdracht + Schrijf-Opdracht* Opdracht om een recept in te lezen of weg te schrijven. *

Dat wil zeggen als samenstelling van "Lees_opdracht" en"SchrijLopdracht". Syntactisch is dit weI correct, maar hetis verwarrend, omdat niet tegelijk gelezen en geschreven kanworden. De twee flows sluiten elkaar dus uit. Daarom is deeerste definitie beter.AIle flows die in het diagram voorkomen zijn gedefinieerd, demeeste in termen van andere, nog niet gedefinieerde objec­ten. In de volledige datadictionary moeten ook deze objec­ten gedefinieerd worden, net zo lang totdat het niveau vanconstanten bereikt wordt. Een voorbeeld hiervan is de flow"RecepLkarakter" , in eerste instantie gedefineerd als: "Re­cept..karakter = [Letter I Cijfer I Scheidingssymbool]". Dedrie objecten "Letter", "Cijfer" en "Scheidingssymbool" kun­nen als voIgt gedefinieerd worden:

Letter =I'Lettera' I ... I 'Letterz' I 'LetterA' I ... I 'LetterZ']

cijrer =['Een' I 'Twee' I 'Drie' I 'Vier' I 'Vijf' I 'Zes' I 'Zeven' I'Acht'l 'Negen' I 'Nul']

Ret lezen van grafische systeemmodellen 28

het '+ '-teken

Opdracht 9.11

Opdracht 9.12

Scheidingssymbool = ['Spatie'l 'Underscore'l 'Komma'i'Punt'l 'Puntkomma'i 'Dubbelepunt'l 'Haakjeopen'I 'Haakjedicht'l 'Accolade_open 'I 'Accolade_dicht' I'Min'l 'Plus'l 'Maal'l 'Nieuwe-l'egel']

Nu is het niveau van de constanten bereikt: aIle letters, cijfersen scheidingssymbolen worden weergegeven door een bepaaldecode in een karakterset. Ze kunnen gedefinieerd worden alsconstante met als waarde het codenummer in de gebruikteverzameling karakters. Dit is hier een beetje flauw omdatwaarschijnlijk toch de standaard ASCII-set van een PC ge­bruikt wordt, maar er zijn genoeg voorbeelden denkbaar vanniet-triviale gevallen.Opmerking: het '+'-teken is niet helemaal eenduidig gedefi­nieerd. Er zijn twee betekenissen:

1. Ben flow bestaat uit twee delen die tegelijk aanwezigmoeten zijn, bijvoorbeeld een achternaam en een straat­naam in een adres-flow.

2. Ben flow bestaat uit delen die voor de overzichtelijkheidsamengevoegd zijn, maar die verder niets met elkaar temaken hebben. Ben voorbeeld hiervan is een bundelingvan sensorsignaIen.

Opdrachten

Leg uit welke onderdelen in de definitie van adres voorkomen

adres = 1{voorletter}5 + achternaam+ straat + huisnummer + postcode + stad+ (telefoonnummer)

Geeft de betekenis van voorletter in onderstaande definitie.voorletter ~ [ 'A' I ... I 'Z' ]

Het lezen van grafische systeemmodellen 29

eenvoudigeprocessen

slechte methoden

IFlguur 2.2: BehMr cllkl

RecepUn

FifP;u'''' 3.~: Het prOcel 'Debeer disk'

3.3.6 Processpecificaties

In de paragraaf over het DFD werd gezegd dat processen uit­gewerkt worden met behulp van diagrammen op een lager rn­veau in het diagram. Tot op zekere hoogte is dit waar, maar erkomt een moment waarop processen zo eenvoudig worden dathet overbodig is om nog een extra laag aan het diagram toete voegen. 'Beheer scherm' (figuur 3.5), 'Recept van disk' en'Recept naar disk' (figuur 3.9) zijn voorbeelden van dergelijkeprocessen.Om vast te leggen wat elk proces doet kunnen we processpeci­ficaties gebruiken. Er zijn drie veelgebruikte specificatietech­nieken:

1. gestructureerde taal ('Structured English')

2. pre- en postcondities

3. beslissingstabellen

Daarnaast zijn er nog een aantal. slechte methoden zoal.s ge-

•Het lezen van grafische systeemmodellen 30

Inlezen van een recept uit een opgegevendiskfile.ReceptJn, Lees_recept, ReceptnaarnCursor_positie, Herstel..scherrn, Recept

woordenschat

wone taal (te veel redundantie, onoverzichtelijk, dubbelzin­nig), flow diagrammen en Nassi-Schneidermann diagrammen(beide soorten diagrammen beschrijven een algorithme, watniet de bedoeling van een functionele specificatie is). Gewonetaal zou eventueel gebruikt kunnen worden in heel eenvou­dige gevallen, maar dan voldoet gestructureerde taal natuur­lijk ook.Er is geen goede reden om een van de drie methoden te kie­zen en die voor elke specificatie te gebruiken. Elke methodeheeft zijn eigen voor- en nadelen, dus voor elke situatie kande meest geschikte methode uitgezocht worden.

Gestructureerde taal

Gestructureerde taal bestaat uit een deelverzameling van eennatuurlijke taal zoals Engels of Nederlands, met sterke beper­kingen van de woordenschat en voor het vormen van zinnen.Hieronder is een specificatie voor het proces 'Recept van disk'(zie figuur 3.9) gegeven: P1.2.1 Recept van disk

Doel:

Input:Output:Begin

IF Lees_recept ontvangen ANDReceptnaarn ontvangen THENOpen_file (Receptnaarn)IF Alles-kits THEN

Lees_recepLvanJileIF Fout-bijJezen THEN

Foutrnelding (Fout bij lezen recept)ELSE

Cursor_positie:=(Rij1,Kolorn1 ,Regel1)HersteLscherrn:=True

ENDIFELSE

Foutmelding (Fout bij openen file)ENDIF

Het lezen van grafische systeernmodellen 31

statementsconstantenvariabelenluncties

precondities

ENDIFEnd

De specificatie ziet er een beetje uit als een procedure ineen programmeertaal. Er wordt gebruik gemaakt van eenaantal standaard-termen ('BEGIN', 'END', 'IF'), variabelen('Lees..recept', 'Receptnaam',...), constanten ('RUl', 'KO­LOMl', 'REGELl', 'FOREVER') en dan nog wat niet na­der gespecificeerde zaken als 'OpenJile', 'Lees..recepLvanJile'.Voor deze laatste 'fundies' geldt dat ze vaak erg implementa­tie-afhankelijk zijn, zodat een specificatie ervan niet in eenconceptueel-model thuis hoort. Ze kunnen echter toch ge­bruikt worden omdat, eventueel met wat uitleg, weI duidelijkis wat ze doen.Naast de constructies in het bovenstaande voorbeeld kan noggebruik gemaakt worden van CASE-, WHILE- en REPEAT­statements.

Pre- en postcondities

Met behulp van pre- en postcondities kan de functie die dooreen proces uitgevoerd wordt beschreven worden zonder iets tehoeven zeggen over de manier waarop de uitvoering plaats­vindt.Precondities beschrijven de voorwaarden waaraan moet zijnvoldaan voordat het proces gestart wordt.Ze beschrijven over het algemeen

• de inputs die beschikbaar moeten zijn

• welke relaties tussen de inputs onderling moeten geldenof welke waarde een input moet hebben

• welke relaties tussen inputs en de inhoud van stores moe­ten bestaan

• welke relaties tussen de inhoud van stores of de gegevensbinnen een store moeten bestaan.

Ret Iezen van grafische systeemmodellen 32

postcondities Postcondities beschrijven aan welke voorwaarden moet ZlJnvoldaan nadat het proces afgelopen is.Ze beschrijven over het algemeen

• de gegenereerde outputs

• de relaties tussen outputs en de inputwaarden

• de relaties tussen outputs en de inhoud van stores

• de veranderingen in de inhoud van stores.

Een proces kan beschreven worden door een aantal pre- enpostconditie paren.Een voorbeeld voor het proces 'Recept van disk' is:

Preconditie Er is een Lees..recept opdracht ener is een receptnaam ende file 'Receptnaam' is beschikbaar ende file 'Receptnaam' is een recept.

Postconditie Recept is gelijk aan de inhoud van defile 'Receptnaam' enCursoLpositie=(Rijl, Koloml, Regell) enHersteLscherm=True.

Preconditie Er is een Lees_recept opdracht ener is een receptnaam ende file 'Receptnaam' is met beschikbaar.

Postconditie Foutmelding (Receptnaam bestaat niet)is gegeven.

Het lezen van grafische systeemmodellen 33

bld' ..Tbl31 B r' tbla e es lssm~s a e voor me lCIJnpro eemCombinatiemogelijkheden

Voor- Leeftijd>21 Ja Ja Ja Ja Nee Nee Nee Neewaarden Geslacht M M V V M M V V

Gewicht> 150 Ja Nee Ja Nee Ja Nee Ja Nee

Akties Medicijn1 X X XMedicijn2 X XMedicijn3 X X XGeen Medicijn X X

groot aantalcombinaties

voorwaarden enakties

B eslissingstabe11en

Een beslissingstabel is nuttig aIs er verschillende akties on­dernomen moeten worden afhankelijk van een groot aantalcombinaties van inputs. De tabellen zijn als voIgt opgebouwd(zie tabel 3.1):in de linkerkolom staan aIle voorwaarden (uitspraken over eeninput) die van toepassing zijn onder elkaar. Gescheiden dooreen dubbele lijn volgen daaronder aIle mogelijke akties. Voorelke mogelijke combinatie van voorwaarden is er een kolomin de tabel. In elke kolom staat een kruisje bij de akties dieuitgevoerd moeten worden als de combinatie van voorwaar­den die voor die kolom geldt waar is. Ret is dus zo dat devoorwaarde binair moet zijn. Een compacter alternatief is hetonder elkaar schrijven van aIle te ondernemen akties met ho­rizontaal aIle voorwaarden die van toepassing zijn. Op elkerij komt nu een aantaI kruisjes die weergeven aan welke voor­waarde voldaan moet zijn om de bijbehorende aktie uit temogen voeren. Als een aktie bij meer dan een combinatie vaninputs op kan treden zijn er voor die aktie ook meer regels inde tabel nodig.

Opdrachten

Opdracht 3.13 Wat is er mis met onderstaande processpecificatie?Proces 1.5:IF X=l THEN EXIT

Het Iezen van grafische systeemmodellen 34

d ht 3 15Tbl32 B r' tbla e es lssm,gs a e voor op, raeraam open open dieht openverwarmmg aan uit aan aantemperatuur warm warm koud warm

raam dieht Xverwarming uit X Xraam openverwarmmg aan

Opdracht 3.14 Wat is er mis met onderstaande proeesspeeifieatie?

Preconditie Ret raam is open ende verwarming is aan en bet is te koud

Postconditie Doe bet raam dieht

Opdracht 3.15 Wat is er mis met tabel 3.2?

opgeslagen data

3.3.7 Object-relatie diagrammen

Object-relatie diagrammen (ERD: Entity Relation Diagram)worden gebruikt om de opbouw van opgeslagen data te mo­delleren. Een ERD bestaat uit vier eomponenten

1. objecttypen

2. relaties

3. assoeiaties

4. super/subtype relaties

Een ERD is vooral van belang voor toepassingen waar inge­wikkelde databases gebruikt worden (niet voor editors dus).Daarom ztillen ze niet besproken worden.

Ret lezen van grafische systeemmodellen 35

identificatie vanprocessoren

hie:rarchischmodel

3.4 Het implementatiemodel

Het implementatiemodel vormt de verbinding tussen het con­ceptueel-model en een programma. Het bestaat uit drie on­derdelen:

1. een processormodel

2. een taakmodel

3. een modulemodel.

3.4.1 Het processormodel

Ben processor is iets dat in staat is een bepaalde taak uit tevoeren. Dit kan een mens of een programmeerbare compu­ter zijn, maar ook een elektrisch circuit of een mechanischeconstructie komen in aanmerking. In dit verband zal alleenprogrammeerbare digitale apparatuur beschouwd worden.De eerste stap in het samenstellen van een implementatiemo­del is het identificeren van processoren die de functies vanhet conceptueel-model uit zullen voeren en het toewijzen vandelen van het conceptueel-model aan deze processoren. Hetresultaat is een nieuw hierarchisch model van het systeem.De bovenste laag bestaat uit een aanta! processoren, de lagendaaronder zijn delen van het conceptueel-model.Meestal is het processormodel niet veel meer dan een verdelingvan processen en stores over processoren, hoewel het voor kankomen dat een proces in twee stukken gesplitst wordt. Ookkan het nodig zijn een store te verdubbelen.De FALC-recepten editor leent zich niet zo goed voor het op­stellen van een processormodel (het zou wat overdreven zijnom meer dan een processor te gebruiken). Ben voorbeeld iste vinden in hoofdstuk 6.

Ret lezen van grafische systeemmodellen 36

parallellisme

hie'rarchie

I

Taak1 Taak2

I I

Taak1.1 Taak1.2 Taak1.3

Figuur 3.10: Voorbeeld van een taakhierarchie

3.4.2 Het taakmodel

In principe kan niet meer dan een proces tegelijk uitgevoerdworden op een bepaalde processor. Om parallellisme mogelijkte maken, bijvoorbeeld op time-sharing basis onder een multi­tasking operating system, worden processen gegroepeerd intaken. Taken zijn onderling parallel uitvoerbaar, maar internniet.Er kunnen niet alleen processen, maar ook deeltaken in eentaak zitten. We kunnen een hierarchie van taken maken. In fi­guur 3.10 is een voorbeeld gegeven. 'Taak1' en 'Taak2' vormenhet bovenste niveau van de hierarchie, waarbij Taak1 onder­verdeeld is in de deeltaken 'Taak1.1" 'Taak1.2' en 'Taak1.3'.Dit betekent niet dat Taak1.2 en Taak1.3 tegelijk in uitvoe­ring kunnen zijn, maar dat Taak2 parallel aan een van de ta­ken Taak1.1, Taak1.2 en Taak1.3 loopt. Taak1 bepaalt welkevan de drie deeltaken uitgevoerd wordt; deze taak heeft eenorganisatorische functie.

Ret lezen van grafische systeemmodellen 37

IIL J

Figuur 3.11: Een voorbeeld van eentaakmodel

/P1-'\

,"IU~

\ J~).. -, _<. "Evel1lllow 2

Evel1lllow 1 / / ""

/ / " "d:\'-(~-oo

Figuur 3.12: Een voorbeeld van een be­sturingsproces

,-------, TaakI

II

I

I IL I

-- ...,. "I' ,

I PI \: Besturings- I\ proces I

, I'..... ,.---

Besturingsflow------,.

Eventflow------,.

In figuur 3.11 is een voorbeeld van een taakmodel gegeven.Een taak wordt weergegeven door een stippellijn die getekendis om de processen waaruit de taak bestaat.Omdat binnen een taak geen parallellisme toegestaan is, moe­ten we ervoor zorgen dat de processen van een dergelijke taaksequentieel uitgevoerd worden. Om dit te bereiken is een be­sturing nodig waarmee de processen om de beurt geaktiveerdworden. In figuur 3.12 is een besturingsproces met twee ge­wone processen getekend. Het besturingsproces wordt weer­gegeven door een gestippelde cirkel. De nummering van bestu­ringsprocessen is afhankelijk van die van dataprocessen. Bij­voorbeeld, dataproces 4 in 'Figuur 1.3' heeft nummer 1.3.4.Besturingsproces 1 in dezelfde figuur zal dan nummer 1.3.1hebben.Besturingsflows (ook weI prompts genaamd) worden gebruiktom processen te aktiveren of te deaktiveren. Ze worden weer­gegeven door gestippelde pijlen. In figuur 3.12 is te zien dat debesturingsflows naar de twee processen wijzen. In werkelijk­heid zijn de flows signalen aan een operatingsystem waarmeewaarmee aangegeven wordt dat een proces geaktiveerd of ge­deaktiveerd moet worden.Ook eventflows worden weergegeven door gestippelde pijlen.Met eventflows wordt het optreden van een bepaalde gebeur-

Ret lezen van grafische systeemmodellen • 38

Voorwavde 1Aktie 1

Voorwaarde 2Aktie 2

Voorwaarde 3Aktie 3

Voorwaarde ..Aktie ..

Toe.tand 3

Toestand

voorwaarde(n)aktie(s)

Figuur 3.13: Voorbeeld van een toestandsdiagram

tenis kenbaar gemaakt.Voor het model1eren van een besturingsproces wordt gebruikgemaakt van toestandsdiagrammen. In figuur 3.13 is een voor­beeld van een dergelijk diagram gegeven. Toestanden wordenweergegeven door rechthoeken met de naam van de toestanderin. Toestandsovergangen worden weergegeven door pijlenmet een aantal voorwaarden en akties. De voorwaarden ko­men naast de pijl te staan met daaronder een horizontalestreep en een aantal akties.

Ret lezen van grafische systeemmodellen 39

overzichtelijkeprogramma­structuur

Ret taakmodel van de editor

Ook hier geldt dat de recepteneditor niet erg geschikt is vooreen taakmodel (het is niet wenselijk dat bepaalde processenparallel aan anderen uitgevoerd worden). Ret is weI mogelijkom taken te definieren met als doel een overzichtelijke pro­grammastructuur te maken. Daarom is toch een taakmodelgemaakt (zie figuur 3.14).In deze figuur zijn vier taken te zien: 'Disktaak', 'Cursor­taak', 'Wijzigtaak' en 'Schermtaak'. Behalve de taken is ookhet proces 'Evalueer toetsaanslag' toegevoegd. Dit is noodza­kelijk omdat het toetsenbord aIleen toetscodes levert en nietweet welke code een opdracht voorstelt en welke een onder­deel van een recept is. Ret proces genereert dataflows als'Receptnaam' en 'Recept-karakter' maar ook de eventflows'Verplaats_opdracht', 'Disk_opdracht' en 'Wijzig..opdracht'.Merk op dat de nummering van de processen anders is ge­worden. Dit is nodig omdat het proces 'Beheer.xecept' uithet conceptueel-model vervangen is door de drie processenwaaruit het bestond. Deze drie processen zijn in een apartetaak ondergebracht op hetzelfde niveau als 'Beheer...scherm'.Daarom moet de nummering van de processen veranderd wor­den.

Ret lezen van grafische systeemmodellen 40

.....I

..... ..... VerpIaaIs_cpQ'ec:N.....I

.....- --. .....~---,

DiskI~.....

I ..... ....., II I ..... P2 I

I I I I

{ I I II I

IIII Helllel

II - --,I luk

lI II Helllel I

~ I I

I I------- -------'......

Figuur 3.14: Het taa.kmodel van de editor

Ret Jezen van grafische systeemmodellen 41

IFlguur 2.2: BehHr ciskl

RecepUn

Figuur 3.15: De processen van de disk­taak (herhaling)

RecepUn

Figuur 3.16: De di.kta.ak met besturing

ReoIpt.

geenpara/le/lismemeer

In figuur 3.15 zijn de processen van de disktaak weergegeven.De twee processen kunnen binnen een taak niet meer paralleldraaien, zodat een besturing toegevoegd moet worden. Infiguur 3.16 is dit gedaan, het proces 'Disk besturing' aktiveertafhankelijk van de waarde van de eventflow 'Disk_opdracht'een van de twee processen 'Recept van disk' en 'Recept naardisk'.Het toestandsdiagram voor 'Disk besturing' is gegeven in fi­guur 3.17.

Opdracht 3.16

Opdracht 9.17

Wat is er fout met dit be­sturingsproces?

En wat is er fout met dit be­sturingsproces?

,,-',--! Pl L_.

, Proce- I, .-... -

Het lezen van grafische systeemmodellen 42

Idle

ree:ept gelezen

diaable"recept

van diak"

achrijUec:ept

enable "recept naar diak"

leea-rec:ept

enable "recept van diak"

ree:ept geschreven

diaabk "recept naar diak"

Recept laen Recept ac:hrijven

Figuur 3.17: Ret toestandsdiagram van 'Disk besturing'

•

Het lezen van grafische systeemmodellen 43

procedures enfuncties

modules eninterfaces

Module

/Data

~

Besturing

.~

3.4.3 Het modulemodel

Binnen een taak op het laagste niveau van de hierarchie wor­den processen sequentieel afgehandeld. In een procedureleprogrammeertaal (C, Pascal, Modula) kan gebruik gemaaktworden van procedures en functies voor de implementatie vaneen taak. Om de structuur binnen een taak te verduidelijkenzjjn 'structure charts', module specificaties en data specifica­ties beschikbaar.

De structure chart

Een structure chart beschrijft de verdeling van een taak inmodules, de hierarchische organisatie van deze modules en deinterfaces ertussen. In figuur 3.18 is een voorbeeld van eenstructure chart gegeven.Een structure chart is opgebouwd uit modules, aanroepen,parameterpijlen en datagebieden.Een module wordt weergegeven door een rechthoek met daarinde naam van de module. Een module is een stukje sequentieeluit te voeren code (een procedure, functie of iets dergelijks,afhankelijk van de terminologie van de gebruikte program­meertaal).Een aanroep geeft weer dat een module gebruikt maakt vaneen andere module. Aanroepen (calls) worden weergegevendoor een pijl die van de aanroepende module naar de aange­roepen module wijst.Een dataparameter geeft weer dat bij een aanroep parametersuitgewisseld worden. De parameter wordt weergegeven dooreen pijItje met een open cirkel aan het eind. De pijl wijst vande module die de parameter moet leveren af. In figuur 3.18wordt dus de parameter 'Data' overgedragen van 'Module 2'naar 'Module 1'. Dat wil zeggen dat 'Module 2' door 'Modulel' aanger~penwordt, zijn taak uitvoert en daarna 'Data' te­ruggeeft aan 'Module 1'.Een besturingsparameter wordt gebruikt om besturingsinfor­matie tussen modules uit te wisselen. Besturingsinformatie

Ret lezen van grafische systeemmodellen 44

Module 1

Module 2

Dalllgebied

~BeslUring

\Module 3

r Datagebied I

Figuur J.18: Voorbeeld van eel} .t.ructure chart

komt overeen met de eventfiows van het datafiowdiagram. Deparameter wordt weergegeven door een kort pijltje met eengesloten cirkel aan het uiteinde.Een datagebied is een hoeveelheid data die door een aantalmodules gedeeld wordt. Datagebieden worden weergegevendoor een rechthoek onder elke module die er gebruik vanmaakt.

Ret lezen van grafische systeemmodellen 45

Ecilor besluring

CuI'lOl' tuncties

detaillering

Figuur 3.19: Structure chari van de editor

De structure chart van de editor

In figuur 3.19 is een structure chart van de editor gegeven.We zien de module 'Editor besturing' te zien, die de modules'Evalueer toetsaanslag', 'Beheer disk', 'Cursor functies', 'Wij­zig functies' en 'Beheer scherm' aanroept. Daarnaast zienwe de dataparameters 'Recept...naam' en 'ReceptJcarakter' enbesturingsparameters zoals 'Opdracht' en 'Herstel.,Dpdracht'.De stores 'Recept' en 'Cursorpositie' komen hier voor als eendatagebied dat door vier modules gedeeld wordt.Met deze ene structure chart is de kous natuurlijk nog niet af:een aantal modules is nog lang niet ver genoeg gespecificeerd.Om verdere detaillering toe te staan kan een module uitge­werkt worden met een structure chart op een lager niveau,net zoals dat bij het dataflow diagram gebeurde. De module'Beheer disk' is uitgewerkt in figuur 3.20.

Ret lezen van grafische systeemmodellen • 46

Recepl van dsk

Lees recepl-regel

ReceptCursor positie

Recept na.- dsk

SChrijl reoept­regel

ReceptCurIor poshie

Figuur 3.20: Structure chart van 'Beheer disk'

Ret lezen van grafische systeemmodellen 47

Opdrachten

Opdracht 3.18 Wat is er zoal fout met dezestructure chart?

elke modulespecificeren

Module A

Modulespecificaties

Elke module moet op dezelfde manier gespecificeerd wordenals de processen van het DFD. Een verschil is dat elke mo­dule gespeeificeerd moet worden, in tegenstelling tot proces­sen waarvoor een diagram op een lager niveau ook als speei­ficatie kan gelden. De mate van detaillering van deze specifi­catie hangt af van de taal waarin het programma geschrevenzal worden: een taal als C of Pascal vraagt een rninder gede­tailleerde specificatie dan een assemblertaal. De modulespe­cificaties zijn meestal zonder veel wijzigingen over te nemenvan de processpecificaties.

Dataspecificaties

De speeificatie van gegevens in het model kan in de meestegevallen rechtstreeks overgenomen worden uit de data dictio­nary. Er moeten nog een aantal zaken toegevoegd worden:

• De representatie van de data moet gekozen worden (bij­voor~eeld integer, boolean, real, ...).

• De initiele waarde van data die door een aantal modulesgedeeld wordt, moet gespeeificeerd worden.

Het lezen van grafische systeemmodellen 48

Opdracht 3.1

Opdracht 3.2

Opdracht 3.3

Opdracht 3.4

Opdracht 3.5

Opdracht 3.6

Voor de store 'Cursor positie' zou bijvoorbeeld de volgendespecificatie gekozen kunnen worden:

Cursor positie = Rij + Kolom + Bovenste..regel* Positie van de cursor tOY de linker bovenboek van hetscberm en tOY bet begin van de tekst. ** Initieel geldt: Rij = Rijl, Kolom = Koloml, Bovenste..regel

= 1 *

3.5 Antwoorden

Dit proces heeft geen naam.

Een proces transformeert inputs in outputs. Dit procesheeft geen output.

Dit proces heeft geen naam, geen inputs en ook geen out­puts.

De terminator rechtsboven heeft geen naam en communi­ceert met terminator T2. Communicatie tussen terminatorswordt niet op het contextdiagram weergegeven, omdat dezetoch niet door het systeem te beinvloeden is. Het doel van hetdiagram is het afbakenen van het werkgebied van het systeem,dus communicatie tussen terminators is overbodige informa­tie.De derde fout is dat het systeem geen outputs heeft (het doetdus niets!)

De twee onbenoemde pijlen zijn verbonden met de flow'Data'. Omdat ze geen naam hebben loopt er dezelfde in­formatie overheen, dus 'Data'.'Data' is verbonden met de flows 'DeelI' en 'Test', dus 'Data'bestaat uit de onderdelen 'Deell' en 'Test'.

Het lezen van grafische systeemmodellen 49

Opdracht 3.7

Opdracht 3.8

Opdracht 3.9

Opdracht 3.10

Opdracht 3.11

Opdracht 3.12

Opdracht 3.13

De store is alleen verbonden met inkomende pijlen, waar­mee aangegeven wordt dat iets aan de inhoud van de storegewijzigd wordt. Er zijn geen uitgaande flows dus er wordtniets met de opgeslagen informatie gedaan.

De store is verbonden met een continue flow. Dit betekentdat de inhoud ervan voortdurend veranderd, zodat het nietveel zin heeft om de informatie op te slaan.

Ret proces heeft een uitgaande flow 'Straatnaam' die aan deandere kant verbonden is met de store'Adres'. Rieruit kunnenwe afleiden dat het proces informatie over straatnamen in destore bijwerkt.

Ret proces 'P1.3' is uitgewerkt in drie deelprocessen. Denummers van die processen beginnnen dus in ieder geval met1.3. Mogelijke nummers zijn 1.3.1, 1.3.2 en 1.3.3.De flow linksboven is de enige binnenkomende flow en komtdus overeen met 'flow1' in de bovenste figuur. De ondersteflow is continu en komt daarom overeen met 'flow2'. De flowrechtsboven tenslotte komt overeen met 'flow3' in de bovenstefiguur.

Adres bestaat uit een aantal voorletters (minstens een enmaximaal vijf), een achternaam, een straat, een huisnummer,een postcode en een stad. Ret telefoonnummer is optionee!.

Een voorletter kan een 'A', een 'B', enz. zijn.

Omdat de onderste figuur een uitwerking is proces 3 in fi­guur 1, heet deze figuur 'Figuur 1.3'.

Deze processpecificatie in gestructureerde taal mist de on­derdelen naam, doel, input-, output- en lokale variabelen. Defunctie is ook niet helemaal duidelijk.

Ret lezen van grafische systeemmodellen 50

Opdracht 3.14

Opdracht 3.15

Opdracht 3.16

Opdracht 3.17

Opdracht 3.18

Deze processpecificatie met pre- en postcondities is fout,omdat de postconditie een aktie bevat. Een betere postcon­ditie is 'het raam is dicht'. Dit proces kan geimplementeerdworden met een statement 'Doe het raam dicht'. Er zijn tweedingen fout aan deze tabel. In de eerste plaats komen nietaIle mogelijke kombinaties van de drie voorwaarden 'raam','verwarrning' en 'temperatuur' voor. Daarnaast is de vierdekombinatie hetzelfde als de eerste.

Een besturingsproces wordt gemodelleerd met een toestands­diagram. Toestandsovergangen vinden plaats als gevolg vanevents (aangegeven met eventflows) en hebben andere eventsof prompts tot gevolg. Een dataflow kan dus nooit als inputvan een besturingsproces voorkomen.

Dit besturingsproces heeft aIleen inputs en geen outputs.

De aanroeppijl staat de verkeerde kant op, de bovenste mo­dule en de linkse parameterpijl hebben geen naam.

Ret lezen van grafische systeemmodellen 51

generiek

doelstellingenarchitectuurinjormatievoorzieninginjrastructuur

Hoofdstuk 4

Het ontwerp van deFALC-recepten editor

4.1 Inleiding

We zullen nu met behulp van de in de twee vorige hoofdstuk­ken beschreven methoden, SQS en de ontwerpmethoden vanWard/Mellor en Yourdon, een eenvoudig systeem ontwerpen,De bedoeling is het illustreren van de geintroduceerde concep­ten, De fasen van SQS zullen steeds kort toegelicht worden,voor een beschrijving van de andere modellen wordt verwe­zen naar hoofdstuk 3, waar ook de als voorbeeld gebruikteFALe-editor gei'ntroduceerd wordt.

4.2 De omgevingsanalyse

De omgevingsanalyse is een beschrijving van die facet ten vande omgeving van het te ontwikkelen systeem die ervoor vanbelang zijn. De editor is een zogenaamd generiek systeem,dat wi! zeggen een programma dat voor diverse doeleinden enin allerlei Qmgevingen ingezet kan worden. Bij de analyse ko­men de doelstellingen van het systeem, de architectuur van deomgeving, de huidige informatievoorziening (het te vervangensysteem) en de technische infrastructuur aan bod.

53

architectuur

functionele,kwaliteits- enonwikkeleisen

De omgevingsanalyse voor de FALC-editor

De doelstelling van de editor is om de gebruiker in staat testellen op eenvoudige wijze een kort stukje tekst in te tikken,zonder veel handleidingen te moeten lezenof commando's temoeten onthouden.Voor wat de architectuur van de omgeving betreft, gaan weuit van de aanwezigheid van hardware voor het aansturen vaneen toetsenbord, een diskdrive en een beeldscherm. De omge­ving moet funeties ter beschikking hebben waarmee genoemdehardware eenvoudig aan te spreken is.Op dit moment worden recepten ingevoerd met een standaardeditor.Bij de ontwikkeling van het programma dient gebruik gemaaktte worden van SQS en de methode van Yourdon. Er is eenPC en een CASE-tool beschikbaar om de ontwikkeling uit tevoeren.

4.3 Eisendefinitie

De eisendefinitie beschrijft de eisen die de omgeving (in ditgeval de gebruiker) aan het systeem stelt. We onderscheidenfunetionele, kwaliteits- en ontwikkeleisen.

De eisendefinitie van de FALC-editor

Voor de FALC-editor geldt het volgende:

1. De gebruiker moet tekst (letters, cijfers en de gebrui­kelijke scheidingssymbolen) in kunnen voeren via eentoetsenbord.

2. De gebruiker moet een cursor door de tekst kunnen be­wegen met behulp van de gebruikelijke toetsen.

3. De resultaten van het type-werk van de gebruiker moe­ten op een beeldscherm zichtbaar zijn. Daarbij moet

Ret ontwerp van de FALC-recepten editor 54

funetionele eisen

kwaliteitseisen

ontwikkeleisen

Opdracht .4-1

aangegeven worden in welke regel en kolom de cursorzich bevindt en wat de naam van het recept is.

4. Recepten moeten opgeslagen kunnen worden op disk enook weer teruggelezen en gewijzigd kunnen worden.

5. Ais bij het schrijven van een recept naar disk een foutgemaakt wordt, moet dit aan de gebruiker meegedeeldworden.

6. Een recept bestaat maximaal uit duizend regels die ma­ximaal tachtig karakters lang zijn.

7. De documentatie moet volgens de SQS methode gepro­duceerd worden.

8. Voor het analyseren en ontwikkelen van de editor moetgebruik gemaakt worden van de methode van Yourdonen het CASE-tool 'System Architect'.

De eerste vier eisen zijn functioneel, ze leggen de taken vande editor vast. De vijfde eis is een kwaliteitseis: de gebruikermoet er op kunnen vertrouwen dat zijn handelingen uitge­voerd worden. Ais er een fout optreedt moet die kenbaargemaakt worden zodat de gebruiker maatregelen kan nemen.Ook de zesde eis heeft betrekking op de kwaliteit, omdat decapaciteit van de editor vastgelegd wordt. De laatste tweeeisen hebben betrekking op de te gebruiken ontwikkelmetho­den.

Vergelijk de editor met commerciele varianten en bedenkeen aantal uitbreidingen.

4.4 Het conceptueel-model

4.4.1 De doelbeschrijving

Ret doel van de FALC-recepten editor is de gebruiker in staatstellen om op een eenvoudige manier recepten (korte ,stukken

Ret ontwerp van de FALC-recepten editor 55

Opdracht 4.2

terminators

data-uitwisseling

tekst) in te voeren.

4.4.2 Het contextdiagram

Ret contextdiagram geeft het systeem weer als een proces,in dit geval 'FALC-recepten editor' genaamd, met een aantalterminators en flows tussen de terminators en het proces. Omhet diagram op te kunnen stellen moeten we nagaan met welketerminators de editor te maken heeft en welke data ermeeuitgewisseld wordt.

Ga voor jezelf na wat terminators zouden kunnen zijn.

In het algemeen willen we met een editor teksten in kunnenvoeren via het toetsenbord van een computer, de ingevoerdetekst moet op een beeldscherm verschijnen en het moet moge­lijk zijn om tekst op te slaan zodat deze op een later tijdstipgewijzigd kan worden. Rieruit volgen drie apparaten waarmeeeen editor te maken krijgt: een toetsenbord, een beeldschermen een opslagmedium, waarvoor we een diskdrive hebben ge­kozen. Figuur 4.1 geeft het contextdiagram weer.De flows op dit diagram betekenen het volgende:

Toetsenbord.Jnvoer Toetsenbordjnvoer is een verzamel­naam voor gegevens die via het toetsenbord ingevoerdkunnen worden. Ret gaat hier om letters en cijfers waar­uit een recept kan bestaan, de naam van een recept oftoetsen waarmee opdrachten gegeven kunnen worden.

Scherrn_info Scherminformatie moet gezien worden als eensamenstel van commando's waarmee de cursor op eenbepaalde plaats gezet kan worden, en tekst die vanaf deplaats van de cursor op het scherm gezet moet worden.

Recept.Jn t RecepLuit Recepten zijn voor de editor een ver­zameling regels (maximaal duizend) van maximaal tach­tig karakters lang.

Ret ontwerp van de FALC-recepten editor 56

events gebaseerdop elsen

Toelsenbord

Figuur •.1: Het contextmodel

4.4.3 De event-list

De event-list voor de editor is de volgende:

1. De gebruiker wil een karakter toevoegen.

2. De gebruiker wil de cursor verplaatsen (een karakternaar links of naar rechts, een regel omhoog of omlaag,naar het begin of einde van de regel, een bladzijde om­hoog of omlaag, naar het begin of einde van de tekst).

3. De gebruiker wil het karakter voor de cursor wissen.

4. De gebruiker wil het karkater onder de cusor wissen.

5. De gebruiker wil een regel wissen.

6. De gebruiker wil een recept opslaan.

7. De gebruiker wil een recept inlezen.

We zien hier vooral events die gebaseerd zijn op eisen dieaan het systeem gesteld zijn. Flow-georienteerde events tre­den hier niet op omdat we als invoerapparaat iets algemeens

Het ontwerp van de FALC-recepten editor 57

Opdracht -4.:3

eventpartitioning

stores

als een toetsenbord gebruikt hebben. Ret toetsenbord produ­ceert maar een soort codes die door de editor gesplitst moetenworden in opdrachten en tekst. Temporele events zijn er ookniet; een voorbeeld zou zijn een timer-interrupt waarmee aan­gegeven wordt dat het tijd is om een backup van het receptte maken. Ook besturingsevents zijn hier niet van toepassing.

Bepaal welke events horen bij de uitbreidingen van opdracht4.1.

4.4.4 Het dataflow diagram

De eventpartitioning-techniek leent zich goed voor toepassingop de FALC-editor. Met behulp van de event-list kunnen wehet diagram dat in figuur 4.2 gegeven is opstellen. Voor elkevent is er een proces, waarbij de processen om de cursor teverplaatsen voor de overzichtelijkheid samengevoegd zijn. Deprocessen communiceren met een aantal stores die toegevoegdzijn om algemene informatie te bewaren. Ret gebruik van destore 'Recept' zal duidelijk zijn. 'Cursor positie' wordt ge­bruikt om aan te geven in welke rij en kolom de cursor zichop het beeld bevindt. Omdat niet de hele tekst op het schermhoeft te staan, moet ook opgeslagen worden welke regel bo­venaan staat, zodat de cursorpositie niet alleen de plaats vande cursor op het scherm, maar ook de positie binnen de tekstweergeeft. Aile processen behalve 'Recept naar disk' en 'Re­cept van disk' moeten deze informatie hebben om hun taak uitte kunnen voeren. Daarnaast veranderen sommige processende positie (niet aIleen het proces 'Cursor verplaatsen' maarook 'Karakter wissen (backspace)' omdat de cursor zich dannaar links verplaatst, 'Karakter toevoegen' omdat de cursorzich dan naar rechts verplaatst en 'Recept van disk' omdatvolgens de. conventie de cursor links op de eerste regel ver­schijnt als we een tekst ingelezen hebben).

Ret ontwerp van de FALC-recepten editor 58

Figuur 4.2: DFD D& eventpartitioning

Het antwerp van de FALC-recepten editor 59

alternatief

Figuur 4.3: Figuur 0 van de FALC-recepten editor

We missen op dit diagram nog een proces waarmee tekstop het scherm gezet kan worden. In figuur 4.3 is een derge­lijk proces toegevoegd ('Beheer scherm', procesnummer 1), enzijn de processen van figuur 4.2 samengevoegd in het proces'Beheer recept' (procesnummer 2).Figuur 4.4 laat een mogelijke detaillering van 'Beheer recept'zien. We zien hier drie processen 'Beheer disk', 'Wijzig func­ties' en 'Cursor funeties'.Een alternatief voor de diagrammen in de figuren 4.3 en 4.4 iseen diagram met daarop vier processen, namelijk de drie vanfiguur 4.4 en het proces 'Beheer scherm'. Een nadeel van dezeoplossing is de wirwar van flows die dan ontstaat. Daarom isgekozen voor de oplossing met twee niveau's.In figuur 4.4 zien we hoe de invoer van het toetsenbord opge­deeld wordt in karakters die tot de tekst behoren en toets­aanslagen die het verwijderen van regels en karakters, hetverplaatsen van de cursor of het opslaan/inlezen van recep­ten ten gevolge hebben. De flow 'Toetsenbordinvoer' wordtverdeeld in de flows 'Verwijder.opdracht', 'Recept_tekst', 'Re­ceptnaam', 'Disk..opdracht' en 'Verplaats.opdracht'. Als wedeze splitsing willen implementeren zal er een proces voor

Het ontwerp van de FALC-recepten editor 60

Figuur 4.4: Figuur 2 van de FALC-recepten editor

Ret ontwerp van de FALC-recepten editor 61

hie'rarchie

detaillering

recept lezen enwegschrijven

stores

geintroduceerd moeten worden. In het conceptueel-model isdit echter nog niet nodig.Riermee is dus het diagram dat ontstond door event-partitio­ning toe te passen omgezet in een diagram van de hierarchie.Omdat processen samengevoegd zijn tot grotere processen ishet noodzakelijk geworden om in ieder geval 'Beheer disk' en'Wijzig fundies' in een diagram op een lager niveau uit tewerken. Ret proces 'Cursor functies' was al een samenraapselvan een aantal processen en moet dus ook uitgewerkt wor­den. 'Beheer scherm' is eenvoudig genoeg om een tekstuelespecificatie mogelijk te maken. In het onderstaande zullen webovengenoemde akties beschrijven.

Het proces 'Beheer disk'

In het proces 'Beheer disk' zijn de processen 'Recept naar disk'en 'Recept van disk' samengevoegd. We kunnen deze proces­sen zonder meer naar het nieuwe diagram kopieren, waarbijwe aIleen flows voor interne communicatie toe moeten voegen.In figuur 4.5 is dit gedaan. Merk op dat de stores 'Recept' en'Cursor_positie' gekopieerd zijn, hoeweI ze niet specifiek bijeen van de twee processeD horen. Dit is gedaan om de lezerduidelijk te maken waar de informatie (recept en cursorposi­tie) vandaan komt.

Ret antwerp van de FALC-recepten editor 62

RecepUn

Ret antwerp van de FALC-recepten editor

IF1guur 22: .... clskl

Figuur 4.5: Bet procs 'Beheer disk'

63

Het proces 'Wijzig recept-functies'

In het proces 'Wijzig functies' zijn vier processen samenge­voegd: 'Karakter toevoegen', 'Karakter verwijderen (delete)','Karakter verwijderen (backspace)' en 'Regel verwijderen'.Deze processen maken gebruik van de cursorpositie en eendeel van de inhoud van het recept.Nadat een proces iets aan de inhoud van het recept gewijzigdheeft, moet een deel van het beeldscherm opnieuw opgebouwdworden. Dit wordt kenbaar gemaakt met de flow 'Herstel' diede waarden 'HersteLscherm' en 'HersteLregel' aan kan nemen.Voor aIle processen geldt dat ze eenvoudig genoeg zijn om meteen tekstuele specificatie beschreven te worden.In figuur 4.6 is het diagram van 'Wijzig functies' gegeven.

Het proces 'Cursor functies'

Akties waarmee de cursor verplaatst wordt kunnen we grofwegin vier groepen verdelen:

1. Verplaatsen binnen een regel (karakter naar links, ka­rakter naar rechts, naar het eind of het begin van deregel).

2. Verplaatsen naar de regel onder of boven de huidige re­gel.

3. Verplaatsen naar de volgende of vorige bladzijde.

4. Verplaatsen naar het begin of het einde van de tekst.

In figuur 4.7 is het proces 'Cursor funeties' uitgewerkt in vierdeelprocessen die de bovenstaande verplaatsingen realiseren.Het resultaat van het verplaatsen van de cursor is dat een deelvan het scherm opnieuw opgebouwd moet worden. Daaromproducereri de vier processen een herstel-flow. De vier deel­processen kunnen met een tekstuele specificatie beschrevenworden.

Ret ontwerp van de FALC-recepten editor 64

Fi.e:uur 4.6: Het proces 'Wijzi.~ functies'V.,..._apctKH

Figuur 4.7: Het proces 'Cursor functies'

Ret ontwerp van de FALC-recepten editor 65

voorbeeld

4.4.5 De datadictionary

Bij wijze van voorbeeld zullen we hier de definitie van 'Recept'uitwerken:

Recept = 1{Regel}1000 + Aantal.Iegels* Een recept is samengesteld uit minimaal 1 en maximaal1000 regels.Ret aantal regels wordt opgeslagen in 'Aantal.Iegels'. *

De store 'Recept' bestaat volgens deze definitie uit minimaaleen en maximaal duizend regels en een variabele waarin bijge­houden wordt hoeveel regels in gebruik zijn. 'Regel' en 'Aan­taLregels' zijn nu nog ongedefinieerd dus:

AantaLregels =* Ret aantal regels waaruit een recept bestaat. *

Regel = 1{RecepLkarakter}80* Een regel is samengesteld uit minimaal 1 (een lege regel)en maximaal 80 letters, cijfers of scheidingssymbolen. *

'AantaLregels hoeft verder niet gespecificeerd te worden (hetwordt later waarschijnlijk een integer, maar dat hoeft nu nogniet vastgelegd te worden). Een 'Regel' blijkt te bestaan uitminimaal een en maximaal tachtig 'RecepLkarakter's:

Recept-karakter = [Letter I Cijfer I Scheidingssymbool ]* Karakters waaruit een recept mag bestaan. *

Ook hier weer ongedefinieerde objecten (letters, cijfers en schei­dingssymbolen):

Letter =['Lettera' 1···1 'Letterz' I 'LetterA' I ···1 'LetterZ']* AIle mogelijke letters. *

Cijfer =['Een' I 'Twee' I 'Drie' I 'Vier' I 'Vijf' I 'Zes'I 'Zeven' I 'Acht' I 'Negen' I 'Nul']* Alle mogelijke cijfers. *

Scheidingssymbool = ['Spatie'l 'Underscore'l 'Komma'i'Punt'l 'Puntkomma'i 'Dubbelepunt'l 'Raakjeopen'I 'Raakjedicht'l 'Accolade_open 'I 'Accolade_dicht' I'Min'l 'Plus'l 'Maal'l 'Nieuwe.Iegel']* De toegestane scheidingssymbolen. *

Ret ontwerp van de FALC-recepten editor 66

Hier zijn we ook weer op het laagste niveau aangeland. Wekunnen aIleen nog een waarde geven aan de constanten, maarhet is beter om dit pas bij de implementatie te doen (er is noggeen reden om een waarde vast te leggen).

Opdracht 4.4 Definieer de andere flows die in de diagrammen voorkomen.

4.4.6 De processpecificaties

De FALC-editor is nu zover uitgewerkt in diagrammen zodatprocessen ontstaan zijn waarvoor een nieuw diagram triviaalzou zijn. Om dergelijke processen te beschrijven moeten weprocesspecificaties maken.Voor de processen van de FALC-editor kunnen we de volgendespecificaties opstellen:

Input:Output:Begin

IF RecepLkarakter~Nieuwe.IegelTHENIF CursoLop_einde-Iegel THEN

IF Lengte_regel< 'Max..karakters-per-Iegel' THENVoeg-IecepLkarakterInSchuiLcursor_op_naar-IechtsHerstel:= 'HersteLl'egel'

ELSEGeeLmelding(Regel te lang, helaas)

ENDIFELSE

IF Lengte_regel<'Max..karakters_per-Iegel' THENSchuif..aJle-karakters..op-Ilaar-IechtsVoeg-RecepLkarakterInSchuiLcursor_op_naar-IechtsHerstel:= 'Herstel-Iegel'

ELSEGeeLmelding(Regel te lang, helaas)

Pl.l.1 Karakter toevoegenDoel: Het invoegen van een karakter op de plaats van

de cursor.RecepLkarakter, Cursor_positieHerstel, Cursor_positie, Recept

Het ontwerp van de FALC-recepten editor • 67

pre- enpostconditieparen

ENDIFENDIF

ELSEIF AantaLregels<'Ma.x...aantaLregels' THEN

SplitSJegeLop_cursor_positieAantalJegels:=Aan talJegels+ 1Herstel:='HersteL.scherm'

ELSEGeeLmelding(Te veel regels, helaas)

ENDIFENDIF

End

AIle akties die hier ondernomen moeten worden zijn sterk af­hankelijk van de implementatie die voor het opslaan van re­cepten gekozen wordt. Daarom zijn ze hier niet verder uitge­werkt.Verder is de specificatie al aan de lange kant. Om dat te ver­mijden kunnen we gebruik maken van pre- en postconditieparen:

Preconditie Er is een RecepLkarakter enRecepLkarakter1'NieuweJegel' ener is genoeg plaats op de regel.

Postconditie RecepLkarakter is ingevoegd op de plaatsvan de cursor enHerstel='HersteLregel '.

Preconditie Er is een RecepLkarakter enRecepLkarakter1'NieuweJegel' ener is niet genoeg plaats op de regel.

Postconditie Foutmelding 'Regel te lang' is gegeven.

Preconditie Er is een RecepLkarakter enRecepLkarakter='Nieuwe-regel' ener zijn minder regels dan 'Max..aa.ntalJegels'.

Postconditie De regel is gesplitst op de plaats van de cursor (hetkarakter onder de cursor komt op de volgende regel) enHerstel='HersteLscherm'.

Het ontwerp van de FALC-recepten editor 68

Preconditie Er is een RecepLkarakter enRecepLkarakter='Nieuwe..regel' ener zijn 'Ma.x..aantal..regels'.

word-wrapping

Postconditie Foutmelding 'Te veel regels' is gegeven.

Deze manier van specificeren laat iets als word-wrapping opeenvoudige wijze toe. We zouden het tweede conditiepaarkunnen vervangen door het volgende:

Preconditie Er is een RecepLkarakter enRecepLkarakter;l'Nieuwe..regel' ener is niet genoeg plaats op de regel ener zijn minder dan 'Max_aantal-regels'.

Postconditie Huidige regel is in twee stukkengesplitst aan het begin van het laatste woord enRecepLkarakter is toegevoegd ende cursor staat aan het einde van de vorige regel enHerstel='HersteLscherm'.

Hiermee is natuurlijk niet gezegd dat we met gestructureerdetaal niet een zelfde functie zouden kunnen toevoegen. Hetprobleem is dan echter dat de specificatie nogal omvangrijkzal wor den.

Opdracht .r5 Werk een specificatie in gestructureerde taal uit waarmeeword-wrapping mogelijk wordt.

P1.3.1 Verplaats binnen regelDoel: Afhandelen van opdrachten om cursor binnen regel

te verplaatsen.Binnen_regel, Recept, Cursor_positieHerstel..regel, Cursor_positie

Input:Output:Begin

DOCASECASE Binnen..regel='CursorJinks ':

IF Cursor_positie[Kolom]>'Kolom1' THENCursor_positie[Kolom]:=Cursor..positie[Kolom]-1Herstel:='Herstel..regel'

ENDIF

Het ontwerp van de FALC-recepten editor 69

Opdracht 4.6

een processor

CASE BinneILregel='Cursor..rechts':IF Cursor_positie[Kolom]<'MaJLkarakters_per_regel'

THENCursor_positie[Kolom]:=

Cursor_positie[Kolom]+ 1Herstel:='Herstel..regel'

ENDIFCASE BinneILregel='Einde..regel':

Cursor_positie[Kolom]:='Koloml'+lengte..regelHerstel:= 'Herstel..regel'

CASE BinneILregel='Begin..regel':Cursor_positie[Kolom]:='Koloml'Herstel:= 'Herstel..regel'

ENDCASEEnd

Schrijf specificaties voor de andere processen.

4.5 Het implementatiemodel

4.5.1 Het processormodel

Voor iets eenvoudigs als een editor is een processormodel eenbeetje overdreven. Ret geheel is eenvoudig op ren processorte implementeren, behalve natuurlijk als geeist wordt dat weook een besturing voor het beeldscherm, de diskdrive en hettoetsenbord gemaakt wordt. We zullen er hier vanuit gaandat dergelijke faciliteiten gerealiseerd zijn, zodat we weI zon­der processormodel af kunnen. Merk op dat als we inderdaadeen besturing voor de terminators zouden moeten maken, wehiervoor waarschijnlijk insteekkaarten zouden moeten ontwik­kelen (denk aan de kaarten in een PC). Deze kaarten kunnenwe dan als processoren zien. Een processor is dus zeker nietaItijd een CPU.

Het ontwerp van de FALC-recepten editor 70

4.5.2 Het taakmodel

In principe geldt voor het taakmodel een zelfde opmerking alsvoor het processormodel gemaakt is: het is eigenlijk een beetjeoverdreven (het is niet wenselijk dat bepaalde processen pa­rallel aan anderen uitgevoerd worden). Het programma wachtop invoer en aktiveert dan de juiste functie om die invoer teverwerken, waarna eventueel nog het scherm aangepast moetworden.

Het ontwerp van de FALC-recepten editor • 71

......I

...... ...... VerpIaaIs_opa-acht......I ......-- ...... ......

~--...,DiIld~

......I ......

...... 1...... II 1 I P2 II I 1 I( I I I

I 1

III Hel'ltel

III

- -..,taak,

I1

I Hel'ltel IWi~ 1

I------ .......

Figuur 4.8: Het taakmodel van de editor

bunde/en vanfuncties

We kunnen echter toch een taakmodel maken door bij elkaarhorende functies te bundelen. Op deze manier ontstaat hettaakrnodel in figuur 4.8. Ret proces 'Evalueer toetsaanslag'is noodzakelijk geworden orndat het toetsenbord van een PCzo algerneen van opzet is dat het niet in staat is te bepalenwelke opdracht de gebruiker aan de recepten-editor wil geven.Ret proces bekijkt de toetsaanslagen en geeft aan de handdaarvan opdrachten aan de vier taken.

Het ontwerp van de FALC-recepten editor 72

Figuur 4:.9: Model van de disktaak

In figuur 4.9 is een nieuwe versie van het dataflow diagramvoor het proces 'Beheer disk' gegeven. Er is een besturingtoegevoegd om het juiste proces te aktiveren en weer te deak­tiveren zodra het zijn taak uitgevoerd heeft.We zouden voor elke taak zo'n model op kunnen stellen, maarerg interressant zijn ze eigenlijk niet. Daarom zullen we hetniet doen en volstaan met de opmerking dat eigenlijk bij elketaak een model hoort waarbij een besturingsproces is toege­voegd.

Ret ontwerp van de FALC-recepten editor .. 73

Ecllor besluring

bovenste laag

stores

globale data

Figuur 4.10: Structure chart van de editor

4.5.3 Het modulemodel

We zullen beginnen met een structure chart voor de bovenstelaag van het taakmodel (zie figuur 4.8). In figuur 4.10 is ditmodel gegeven.De module 'Editor besturing' is nieuw, dat wi! zeggen, staatniet als proces op een van de dataflow diagrammen. Dezemodule komt overeen met een besturing die we aan figuur 4.8toe zouden moeten voegen voor het coordineren van de werk­zaamheden van de vier taken. De enige functie van de moduleis het aanroepen van 'Evalueer toetscode' en aan de hand vande output van deze module een module voor een van de drietaken 'Beheer disk', 'Cursor funeties' en 'Wijzig functies' aante roepen. Daarna wordt 'Beheer scherm' aangeroepen omhet scherm te herstellen. 'Recept' en 'Cursor positie' zijn destores die door de vier taken gedeeld worden. Ze worden hier

•Ret ontwerp van de FALC-recepten editor 74

besturingsmodule

opgevoerd als globale data.'Evalueer toetsaanslag', 'Beheer disk' en 'Beheer scherm' zijnin aparte modellen verder uitgewerkt. De andere twee modu­les zijn met behulp van tekst gespecificeerd. We zullen nu despecificatie van de modules behandelen.

De module 'Editor besturing'

De taak van de module 'Editor besturing' is het aanroepenvan 'Evalueer toetscode', het aanroepen van een module voorhet uitvoeren van een opdracht en daama het aanroepen van'Beheer scherm' om het beeldscherm weer te herstellen. Wekunnen de module als voIgt specificeren:

Doel: Het verwerken van de invoer van de gebruiker doorhet aanroepen van de juiste module.

Input: HersteLopdrachtBegin-Module

DO ForeverCall Evalueer_toetsaanslag

(recept-naam, Recept-karakter, opdracht)DOCASE

CASE Disk_opdracht: Call Beheer_disk(receptnaam, hersteLopdracht)

CASE Verplaats-Opdracht: Call CursorJuncties(Verplaats-Opdracht, hersteLopdracht)

CASE Wijzig_opdracht: Call WijzigJuncties(Wijzig_opdracht, hersteLopdracht)

ENDCASECall Beheer_scherm (hersteLopdracht)

ENDDOEnd..module

Het ontwerp van de FALC-recepten editor 75

EvaJueerloelsaanslag

Lees receptnaam

Lees loell8lnlag

Figuur 4.11: Structure chart V&Il 'Evalueer toetsaanslag'

De module 'Evalueer toetsaanslag'

De module 'Evalueer toetsaanslag' is uitgewerkt in figuur 4.11.We zien behalve de hoofdmodule nog twee submodules. Nor­maal gezien zal de gebruiker tekst voor het recept invoeren.'Evalueer toetsaanslag' roept de module 'Lees toetsaanslag'aan die de code van een aangeslagen toets teruggeeft. Daarnabepaalt de module of de toets als recepttekst gezien moet wor­den, of dat het een opdracht is. Als de gebruiker vraagt omhet lezen of schrijven van een recept wordt de module 'Lees re­ceptnaam'.aangeroepen. Deze module leest toetscodes totdatde gebruiker op de 'Enter'-toets drukt en daarmee te kennengeeft dat het invoeren van de receptnaam beeindigd is.

Het ontwerp van de FALC-recepten editor 76

modulespecificatie

standaardfuneties

Hieronder voIgt een specificatie van 'Evalueer toetsaanslag':

Doel: Het inlezen van toetsaanslagen, uitgesplitst naarreceptnaam, recept-karakters en opdrachten.

Input: Toetscode, ReceptnaamOutput: Opdracht, Receptnaam, Recept..karakterBegin-Module

Call Lees_toetsaanslag (Toetscode)IF Toetscode='Lees_recepLtoets'

OR Toetscode='SchrijLrecepLtoets' THENOpdracht:=ToetscodeCall Lees_receptnaam (Receptnaam)

ELSEIF Toetscode is een receptkarakter THEN

Opdracht:=KarakterJnvoerenRecepLkarakter:=Toetscode

ELSEOpdracht:=Toetscode

ENDIFENDIF

End-.Module

Het inlezen van de receptnaam zuBen we niet uitwerken. Wezouden hierbij kunnen denken aan een standaardfunctie voorhet inlezen van een aantal karakters, bijvoorbeeld in een apartwindow op het scherm.Toetscodes zouden eventueel met standaard-functies als read(in Pascal) of getc (in C) ingelezen kunnen worden.

Het ontwerp van de FALC-recepten editor 77

Beheercisk

HersteLopdr

Recepl van lisk

RegeinUmm1 }egelLees recept-regel

ReoeptCursor pos~ie

Rec8pt naar lisk

SChrijf recepe­tegel

Figuur •.12: Structure chart van 'Beheer disk'

De module 'Beheer disk'

'Beheer disk' is een eenvoudige module, opgebouwd uit detwee deelmodules 'Recept van disk' en 'Recept naar disk'. Despecificaties van deze twee laatste modules kunnen we zo over­nemen uit de gelijknamige processpecificaties. 'Beheer disk'zelf is zo ~nvoudig dat we deze module niet zullen specifice­ren. In figuur 4.12 is de structure chart gegeven.Op de structure chart zijn de modules 'Lees-regel' en'Schrijf...regel' opgenomen. Deze modules verzorgen de com­municatie met de store 'Recept'. De aanroepende module

Ret ontwerp van de FALC-recepten editor 78

geeft een regelnummer op en krijgt de inhoud ervan als tekst­string terug (of moet de inhoud als tekststring geven in hetgeval van 'Schrijf..regel'). Deze modules zuBen nog meer voor­komen. Ze zijn bedoeld om het programma af te schermen vande implementatie van de stores.

De module 'Cursorfuncties'

In de module 'Cursor functies' zijn aIle opdrachten om decursor te verplaatsen verenigd. We kunnen de specificatie vande module overnemen van de specificatie van de vier proces­sen 'Verplaats binnen regel', 'Verplaats over regel', 'Verplaatsscherm' en 'Verplaats boven/onder'

De module 'Wijzig functies'

Ook de specificatie van 'Wijzig functies' kan rechtstreeks over­genomen worden uit de specificatie van het overeenkomstigeproces.

Ret ontwerp van de FALC-recepten editor•

79

Herstel regal Herslel sc:herm &aIUI r8geI

Lees regel u~recepl

Recept

Schrijl regel naarschenn

Lees l1Igel ulrecepl

Schri)l regal naarictMinn

implementatie­onafhankelijk

Figuur 4.13: Structure chart van 'Beheer scherm'

De module 'Beheer scherm'

In figuur 4.13 is een structure chart gegeven voor 'Beheerscherm'. De hoofdmodule roept een van de modules 'Her­steLregel' en 'Herstel..scherm', gevolgd door een aanroep van'Status-regel' om de cursor-informatie weer te geven.

Dataspecificaties

De datadictionary van het conceptueel-model was implemen­tatie-onafhankelijk (we hebben zelfs met opzet objecten als'Ben', 'Nieuwe-regel' en dergelijke ingevoerd). In de dataspe-

Ret antwerp van de FALC-recepten editor 80

constanten

stores

cificatie van het implementatiemodel krijgen al deze constan­ten een waarde. Er vanuit gaande dat het idee duidelijk is,zullen we dit hier niet meer opschrijven.Behalve de constanten uit de datadictionary moeten we ookeen waarde kiezen voor constanten die tijdens proces- en mo­dulespecificaties ingevoerd zijn.

Implementatie van de stores 'Recept' en 'Cursor po­sitie'

Tenslotte moeten we nog de implementatie van de twee storesvastleggen. Voor de cursorpositie kunnen we een globale va­riabele gebruiken, bijvoorbeeld een record in Pascal:

Cursor_positie: record Rij:intj{ Rij waarin cursor zich bevindt}

Kolom:intj{ Kolom positie van cursor}

BovensteJ'egel:int ;{ Regel van het recept diebovenaan op bet scherm staat }

end

£en recept bestaat uit maximaal duizend regels van tachtigkarakters. Het ligt daarom voor de hand om de store te de­finieren als een array. Helaas werkt dat op de meeste PC's(onder MS-DOS) niet; de maximale grootte van een data­structuur is 64k. £en oplossing is een array van duizend poin­ters te definieren en vervolgens voor elke pointer een string vantachtig karakters te alloceren. Behalve het array moeten weook weten uit hoeveel regels het recept bestaat. £en mogelijkedefinitie in Pascal is:

Recept:record AantalJ'egels:intj{ Aantal regels in recept }

Data:array[1..1000] of string[80]{ Pointers naar regels }

end

Bij deze declaraties horen functies om de informatie uit destores te lezen of er in te schrijven. Dit is vooral voor de

Het ontwerp van de FALC-recepten editor 81

annotatie

receptgegevens van belang, maar ook voor de cursorpositie.Door functies te maken die de rij, kolom en eerste regel ophet scherm teruggeven, kunnen we eenvoudiger overschakelenop een andere structuur of een andere programmeertaal.

4.6 Code

Het zou te ver voeren om hier de volledige code van de edi­tor te behandelen. We zullen ons beperken tot de opmerkingdat de modellen uit de vorige hoofdstukken niet voor nietsgemaakt zijn. Dit wi! zeggen dat de code overeen moet ko­men met het implementatiemodel. Hieruit voIgt dat als tij­dens het coderen problemen optreden die een wijziging in destructuur of de specificatie van het programma noodzakelijkmaken, deze wijziging ook in de modellen doorgevoerd moetworden. We moeten dus terug naar het model dat veranderdmoet worden, de wijzigingen moeten aangebracht en gedocu­menteerd worden, waarna het volgende model en tenslotte decode aangepast kunnen worden.Daarnaast moet de code geannoteerd worden. Dit kan doorgebruik te maken van de modulespecificaties, dus door ver­melding van het doel, de input, de output en eventuele lokaalgebruikte variabelen. Daarna komt de code waarbij ondoor­zichtige constructies zoveel mogelijk vermeden dienen te wor­den. Als een statement tot verwarring zou kunnen leiden moetnatuurlijk ook commentaar opgenomen worden.De codering van de editor is te vinden in [Kloprogge, 1990].

4.7 Handleidingen

De handleidingen voor gebruikers, systeembeheerders en on­derhoud zijn te vinden in [Kloprogge, 1990].

•Ret ontwerp van de FALC-recepten editor 82

Opdracht 4.1

Opdracht 4.2

Opdracht 4.3

Opdracht 4.4

4.8 Antwoorden

Commerciele editors kunnen natuurlijk veel meer dan deFALC-editor (EDLIN, de line-editor van dos, uitgezonderd).We zouden kunnen denken aan een functie als word-wrapping,of we zouden langere regels toe kunnen staan. Andere mo­gelijkheden zijn zoek- en vervangfuneties, blokfuncties, hetprinten van stukken tekst en makro's.

Zie de tekst die voIgt op de opdracht.

De word-wrap funetie heeft geen gevolgen voor de event-list,omdat het hier om externe events gaat. Als er teveel karaktersop een regel staan moet intern een signaal gegenereerd wordenwaarmee deze gebeurtenis aangegeven wordt. Word-wrappingheeft dus niets met de omgeving te maken.lets soortgelijks geldt voor langere regels. Als de cursor rechtsvan het tachtigste karakter geplaatst wordt is dit een interneen geen externe gebeurtenis.De andere genoemde funeties geven weI aanleiding tot events.De gebruiker geeft bijvoorbeeld door op een functietoets tedrukken aan dat een zoekaktie gestart moet worden, of dateen blok gedefinieerd wordt. Voor al dit soort funeties kunnenwe een event definieren.

In onderstaande lijst is een mogelijke definitie van de flowsgegeven. Variaties hierop zijn zeker mogelijk.

AantaLregels =* Bet aantal regels waaruit een recept bestaat. *

BeeldJ.nfo = Rij + Kolom + Tekst* Opdracht aan beeldscherm hardware om cursor op eenbep~lde plaats te zetten en daarna de tekst toe te voe­gen. *

Binnen_regel = ['Cursor-links' I 'Cursor-rechts' I'Einde-regel' I 'Begin-regel']

Het ontwerp van de FALC-recepten editor 83

* Opdracht op de cursor binnen een regel te verplaatsen.

*BovelLonder_verplaats = ['Begin_tekst' I 'Eind_tekst']

* Opdracht om de cursor naar het begin of het eindevan de tekst te verplaatsen. *

Bovenste-regel =* Regel van het recept die bovenaan op het scherm staat.

*Cijfer = ['Een' I 'Twee' I 'Drie' I 'Vier' I 'Vijf' I 'Zes' I 'Zeven'

I 'Acht' I 'Negen' I 'Nul']* AIle mogelijke cijfers. *

Cursor_positie = Rij + Kolom + Bovenste.Iegel* Positie van de cursor tov van de linkerbovenhoek vanhet scherm en de regel die bovenaan op het scherm staat.

*Disk_opdracht =['Lees_opdracht' I 'SchrijLopdracht']

* Opdracht om een recept in te lezen of weg te schrijven.

*Herstel = 'Herstel..scherm' I 'Herstel.Iegel']

* Geeft aan het proces 'Beheer scherm' de opdracht eenstuk van het scherm of een stuk van de huidige regelopnieuw te schrijven. *

Kolom = * Vertikale postitie van de cursor op het beel­scherm, bereik afhankelijk van soort scherm en imple­mentatie. *

Letter = ['Lettera' I ... I 'Letterz'I 'LetterA' I ... I 'LetterZ']* AIle mogelijke letters. *

Naamsymbool = [Letter I Cijfer I Underscore I Punt]* Karakters waaruit een receptnaam kan bestaan. *

Ret ontwerp van de FALC-recepten editor 84

Recept = 1{Regel}1000 + AantaLxegels* Een recept is samengesteld uit minimaal 1 en maxi­maallOOO regels. Het aantal regels wordt opgeslagen in,Aantal.xegels' *

Recept..in = Recept* De recepttekst uit een diskfile. *

Recept...karakter = [Letter I Cijfer I Scheidingssymbool]* Karakters waaruit een recept mag bestaan. *

RecepLnaam = 1{Naamsymbool}12* Naam van een recept. *

RecepLuit = Recept* De recepttekst voor een diskfile. *

Regel = 1{RecepLkarakter}80* Een regel is samengesteld uit minimaal 1 (een legeregel) en maximaal 80 letters, cijfers of scheidingssym­bolen. *

Rij = * Horizontale positie van de cursor op het beeldscherm,bereik afhankelijk van soort scherm en implementatie.

*Scheidingssymbool = ['Spatie'l 'Underscore'l 'Komma'i

'Punt'l 'Puntkomma'i 'Dubbelepunt'l 'Haakjeopen'I 'Haakjedicht'I 'Accolade_open'I 'Accolade_dicht' I'Min'l 'Plus'l 'Maal'l 'Nieuwe.xegel']* De toegestane scheidingssymbolen. *

ScherIl'l-verplaats = ['Schernumlhoog' I 'ScherIILOmlaag']* Opdracht om de cursor een scherm naar boven (naarhet begin van de tekst) of naar beneden (naar het eindevan de tekst) te verplaatsen. *

Tekst = 1{RecepLkarakter}* Stuk tekst dat vanaf de plaats van de cursor op hetscherm gezet moet worden. *

Ret ontwerp van de FALC-recepten editor 85

Toetsenbord-invoer = [Verplaats_opdracht IRecepLkarakter I Verwijder..opdracht IDisk_opdracht I Receptnaam]* Mogelijke toetsaanslagen. *

Twee-.regeLverplaats = ['Cursor_omhoog' I'Cursor_omlaag']* Opdracht om de cursor een regel omhoog of omlaagte verplaatsten. *

Verplaats_opdracht = [Binnen..regell Twee..regeLverplaatsI ScherIlLverplaats I Boven..onder_verplaats]* Opdracht om de cursor te verplaatsen. *

Verwijder_opdracht = ['Delete..opdracht' I 'Verwijder_regeL opdracht' I 'Backspace..opdracht']* Opdracht om een karakter of een regel te verwijderen.

*Opdracht 4.5 Onderstaande processpecificatie staat word-wrapping toe.

Pl.l.1 Karakter toevoegen

Het invoegen van een karakter op de plaats vande cursor met word-wrapping.RecepLkarakter, Cursor_positieHerstel, Cursor_positie, Recept

Doel:

Input:Output:Begin

IF RecepLkarakter~'NieuweJ'egel'THENIF Cursor_op_einde..regel THEN

IF Lengte_rege1<'Max..karakters_per-regel' THENVoeg-recepLkarakterInSchuiLcursor_op_naar-rechtsHerstel:= 'Herstel-regel'

ELSEZeLcursor_opJaatste-spatieIF Aantal-regels<'Max..aantal-rege1s' THEN

Spli ts-regeLop_cursor_positieAantal-regels:=Aantal-regels+1Cursor..naar_einde-regelVoeg-recepLkarakterIn

Het antwerp van de FALC-recepten editor 86

Herstel:='HersteL.seherm'ELSE

GeeLmelding (Te veel regels, helaas)ENDIF

ENDIFELSE

IF Lengte..regel<'Max..karakters_per-regel' THENSehuif..alle-karakters..op..naar-reehtsVoegJteeept-karakterinSehuiLeursor_op..naar-reehtsHerstel:='Herstel-regel'

ELSEGeeLmelding(Regel te lang, helaas)

ENDIFENDIF

ELSEIF Aantal..regels<'Max-aantal-regels' THEN

Splits-regeLop_eursor_positieAantal-regels:=Aantal-regels+ 1Herstel:='HersteLseherm'

ELSEGeeLroelding(Te veel regels, helaas)

ENDIFENDIF

End

Het zonder meer geven van de melding 'Regel te lang' is dusvervangen door het verdelen van een regel in twee stukken.Dit gebeurt door eerst naar de laatste spatie (dus het beginvan het woord dat niet meer op de regel paste) te zoeken. Ver­volgens wordt de regel op die plaats in twee stukken verdeeld.Tenslotte wordt het ingetikte karakter aan het einde van denieuwe regel toegevoegd. Omdat het aantal regels toeneemt,moet ook getest worden of er niet teveel regels zijn.Ais we een karakter invoegen midden in een regel en er daar­door te veel karakters op de regel staan, wordt toch een fout­melding gegeven. Een heel gebruikersvriendelijke editor zouhet laatste woord van de regel op de volgende regel neerzetten.

Het ontwerp van de FALC-reeepten editor 87

Opdracht 4.6 Rieronder volgen definities van de processen. Net als voorde datadictionary geldt ook hier dat variaties mogelijk zijn.Ret is goed om een aantal variaties op te schrijven, liefst inverschillende notaties.

Pl.1.2 Karakter verwijderen (delete)Doel: Het verwijderen van het karakter onder de cursor.Input: Verwijder_opdracht, Cursor_positieOutput: Recept, HerstelBegin

IF 'Delete_opdracht' ontvangen THENIF Lengte_regel>O THEN

SchuiLkarakters-rechts_van_cursor_op-naarJinksHerstel:='HersteLscherm'

ENDIFENDIF

End

Pl.1.3 Karakter verwijderen (backspace)Doel: Het verwijderen van het karakter links van de cursor.Input: Verwijder_opdracht, Cursor_positieOutput: Recept, Herstel, Cursor_positieBegin

IF 'Backspace_opdracht' ontvangen THENIF Cursor_positie>'Koloml' THEN

SchuiLcursor_op-naarJinksSchuiLkarakters-rechts_van_cursor_op-naarJinksHerstel:='HersteL.scherm'

ENDIFENDIF

End

Pl.1.4 Regel verwijderenDoel: Het verwijderen van de huidige regel.Input: Verwijder..opdracht, Cursor_positieOutput: . Cursor_positie, Recept, HerstelBegin

IF 'Verwijder-regeLopdracht' ontvangen THENIF Aantal-regels> 1 THEN

Haal-regeLweg

Het ontwerp van de FALC-recepten editor 88

AantaLregels:=Aantal.regels-lHerstel:= 'HersteLscherm'

ENDIFENDIF

End

P1.2.1 Recept van diskDoel: Inlezen van een recept uit een opgegeven diskfile.Input: ReceptJn, Disk_opdracht, ReceptnaamOutput: Cursor_positie, Herstel, Recept

Preconditie Er is een 'Lees_recept' opdracht ener is een receptnaam ende file 'Receptnaam' is beschikbaar ende file 'Receptnaam' is een recept.

Postconditie Recept is gelijk aa.n de inhoud van de file 'Recept­naam' enCursor_positie=('Rijl', 'Koloml', 'Regell') enHerstel='HersteLscherm'.

Preconditie Er is een 'Lees_recept' opdracht ener is een receptnaam en(de file 'Receptnaam' is niet beschikbaar ofde file 'Receptnaam' is geen recept).

Postconditie Foutmelding 'Receptnaam bestaat nietlis geen recept' is gegeven.

P1.2.2 Recept naar diskDoel: Schrijven van een recept naar een opgegeven diskfile.Input: Recept, Disk..opdracht, ReceptnaamOutput: Recept-uitBegin

IF 'SchrijLrecept' ontvangenAND Receptnaam ontvangen THEN

Open_file (Receptnaam)IF Alles_goed THEN

SchrijLrecepLnaar-fileIF FouLbij..schrijven THEN

Het ontwerp van de FALC-recepten editor 89

Foutmelding 'Fout bij schrijven recept'ENDIF

ELSEFoutmelding 'Fout bij openen file'

ENDIFENDIF

End

Bij deze laatste specificatie is bet niet mogelijk om gebruikte maken van pre- en postconditieparen, omdat fouten dietijdens de uitvoering optreden opgevangen moeten worden (erzouden bij dezelfde preconditie meer postcondities nodig zijn,wat natuurlijk onmogelijk is). Bij bet lezen van een file is ditopgevangen door de twee voorwaarden "de file 'Receptnaam'is bescbikbaar en de file 'Receptnaam' is een recept".

P1.3.2 Verplaats schermDoel: Verplaats de cursor een scherm naar onder of

naar boven.Scherm_verplaats, Recept, Cursor_positieCursoLpositie, Herstel...scherm

Input:Output:Begin

IF 'Scherm_omhoog' ontvangen THENCursor_positie[Bovenste..regel]:=

Cursor_positie[Bovenste.xegel]- 'Regels_per_scherm'IF Cursor_positie[Bovenste..regel] <'Regell ' THEN

Cursor_positie[Bovenste.xegel]:='Regell'ENDIFHerstel:= 'Herstel...scherm'

ELSEIF 'Scherm_omlaag' ontvangen THEN

Cursor_positie[Bovenste.xegel]:=Cursor_positie[Bovenste.xegel]+'Regels_per_scherm'

IF Cursor_positie[Bovenste.xegel]>Aantal.xegelsTHEN Cursor_positie[Bovenste..regel]:=

Aantal..regels- 'Regels_per..scherm'IF Cursor_positie[Bovenste..regel] < 'Regell'

THEN Cursor_positie[Bovenste..regel]:= 'Regel! 'ENDIF

ENDIF

Het ontwerp van de FALC-recepten editor 90

Herstel:= 'Herstel..scherm'ENDIF

ENDIFEnd

P1.3.3 Verplaats boven/onderDoel: Verplaats de cursor naar het begin of het einde

van de tekst.Boven_onder_verplaats, ReceptCursor_positie, Herstel

Input:Output:Begin

IF 'Begin_tekst' ontvangen THENCursor_positie[Bovenste..regel]:='Regel1 'Herstel:='Herstel..scherm'

ELSEIF 'Eind_tekst' ontvangen THEN

Cursor_positie[Bovenste..regel]:=Aantal..regels­'Regels_per_scherm'

IF Cursor_positie[Bovenste..regel] <'Regell ' THENCursor_positie[Bovenste..regel]:= 'Regel1'

ENDIFHerstel:= 'Herstel..scherm'

ENDIFENDIF

End

P1.3.4 Verplaats over regelDoel: Verplaats de cursor een regel naar onder

of naar boven.Twee..regeLverplaats, Recept, Cursor_positieCursor_positie, Herstel

Input:Output:Begin

IF 'Cursor-Omhoog' ontvangen THENIF Cursor_positie[Rij]>'Rij1' THEN

Cursor_positie[Rij]:=Cursor-positie[Rij]-lHerstel:= 'Herstel..scherm'

ELSEIF Cursor_positie[Bovenste..regel]>'Regell' THEN

Cursor_positie[Bovenste..regel]:=

Het ontwerp van de FALC-recepten editor 91

Cursor_positie[Bovenste..regel] - 1Herstel:= 'Herstel...scherm'

ENDIFENDIF

ELSEIF 'Cursor_omlaag' ontvangen THEN

IF Cursor_positie[Rij] <'Rijl'+'Max-aantal..regels' THEN

Cursor_positie[Rij] :=Cursor_positie[Rij]+1Herstel:= 'Herstel...scherm'

ELSEIF Cursor_positie[Bovenste..regel] +

'Max-aantal..regels'<Aantal..regels THENCursor_positie[Bovenste..regel]:=

Cursor_positie[Bovenste..regel]+1Herstel:='Herstel...scherm'

ENDIFENDIF

ENDIFENDIF

End

P1.4: Beheer schermDoel: Herstellen van de huidige regel of een deel van het

scherm na het uitvoeren van een operatie.Herstel, Recept, Cursor_positieSchermJnfo

Input:Output:Begin

IF 'HersteLregel' ontvangen THENLees_regeLuiLreceptSchrijLregeLnaar...schermSchrijf...status_regel

ELSEIF 'Herstel...scherm' ontvangen THEN

WHILE Laatste regel niet bereikt DOLees..regeLuit..receptSchrijLregeLnaar..schermVolgende regel

ENDWHILE

Het ontwerp van de FALC-recepten editor 92

IF Cursor_positie[Rij] >Aantal..regels ­Cursor_positie[Bovenste..regel] THENCursor_positie[Rij]:=Aantal..regels ­

Cursor_positie[Bovenste..regel]Schrijf...status..regel

ENDIFENDIF

End

Het ontwerp van de FALC-recepten editor 93

Hoofdstuk 5

Een opdracht

5.1 Inleiding

In het vorige hoofdstuk hebben we gezien hoe met behulp vanSQS en de methode van Yourdon een systeem ontwikkeld kanworden. Nu is het natuurlijk niet genoeg om alleen maar teIezen, er moet ook geoefend worden. Met dat doel voor ogenis dit hoofdstuk geschreven. Er wordt van de Iezer verwachtdat hijjzij aan het werk gaat om een eenvoudig systeem teontwerpen. Na de opdracht voIgt een korte uitwerking vanhet probleem die ter controle gelezen kan worden.

95

mogozijn

houten

blokken

boorcilinder

bO

b,

copocitievebenoderingsschokeloor

p ....1 _----'

>-----<

Istortkn~~

S; I

0,

ofvoercilinder

(90· gedrooid)

Figuur 5.1: De boormachine

Een opdracht

5.2 Een automatische boormachine

In figuur 4.1 is het te besturen systeem schematisch weergege­Yen. Het gaat om een boormachine waarmee gaten in houtenblokken geboord kunnen worden. De blokken worden opge­slagen in een magazijn. Een boorcyclus verloopt als voIgt:

1. De vulcilinder gaat naar rechts waardoor een blok onderde boormachine komt te liggen.

2. De boorcilinder duwt de boorkop naar beneden, het gatwordt geboord, waarna de cilinder weer omhoog getrok­ken wordt.

96

Een opdracht

3. De afvoercHinder duwt het blok rechts van het zojuistgeboorde blok uit de weg en wordt vervolgens weer te­ruggetrokken.

4. De vulcilinder wordt naar links getrokken, waardoor eennieuw blok uit het magazijn op de transportband valt.

Nu zijn we weer bij het begin van de cyclus aangeland. Desituatie is nu zoals in de figuur getekend. Ais de schakelaarp aangeeft dat er geen blokken meer zijn kunnen er nog drieblokken geboord worden. Ais de blokken niet bijgevuld wor­den voor het einde van de derde boorcyclus ontstaat de situa­tie met twee blokken op de horizontale transportband, waar­van de meest rechtse onder de boormachine zit en geboord is.De werking van de cilinders is als voIgt: in de uitgangspositiestaat er druk op de voorkant van de cHinder. De stang dieeraan bevestigd is, is dus ingetrokken. Ais nu het relais vaneen cHinder (A+, B+ of V+) bekrachtigd wordt, valt de drukaan de voorkant van de cHinder weg, en wordt de stang naarbuiten geduwd. Ais de spanning weggehaald wordt, komt erweer druk op de voorkant van de cilinder waardoor de stangweer teruggeduwd wordt. Elke cilinder heeft twee sensoren(ao en al, bo en bl , Vo en Vl) waarmee aangegeven wordt inwelke stand de cHinder zicht bevindt. Ais de sensor een po­sitieve spanning afgeeft, betekent dit dat de cilinder zich bijdie sensor bevindt.De capacitieve benaderingsschakelaar p geeft een positievespanning zolang er nog blokken in het magazijn zitten.Met behulp van de startknop st moet de boorcyclus gestarten gestopt kunnen worden.Op dit moment wordt het systeem bediend via schakelaarsdoor een menselijke operator.Gevraagd wordt nu om met behulp van SQS en Yourdon eenbesturing voor dit systeem te ontwerpen. Het systeem hoeftniet gecodeerd te worden.

97

specifieke omge­vmg

architectuur

doe!

informatievoorziening

infrastructuur

Ben opdracht

5.3 Een oplossing

Hieronder voIgt in het kort een mogelijke oplossing van hetgeschetste probleem. Dit is niet de enige juiste oplossing, erzijn zeker andere mogelijkheden.

5.3.1 De omgevingsanalyse

In tegenstelling tot de FALC-editor gaat het hier niet om eengeneriek systeem, maar om een systeem dat specifiek voor eenbepaalde omgeving ontwikkeld is, namelijk voor de boorma­chine. Daarom is het architectuur-aspect van de omgevings­analyse hier van groter belang dan voor de editor. EigenIijkis al een analyse gegeven, en weI in de probleemstelling. Wekunnen deze analyse dan ook overnemen.De doelstelling van het systeem is het automatiseren van deboormachine, dus het vervangen van de taken van een men­selijke operator, de huidige 'informatievoorziening' van hetsysteem, door een computersysteem.Wat de technische infrastructuur betreft: we zuBen gebruikmaken van SQS, de methode van Yourdon en een CASE-toolvoor een PC.

5.3.2 Eisendefinitie

De volgende eisen worden aan het systeem gesteld:

1. Het besturingssysteem moet in staat zijn om zondermenselijke tussenkomst te functioneren, dat wil zeggen,gaten te boren in blokken, die vervolgens afgevoerd wor­den.

2. Als er geen blokken meer zijn moet dit met een waar­schuwingslampje aangegeven worden, waarna het sys­teem na het aanvullen van de blokken zonder menselijketussenkomst weer verder moet gaan.

98

Een opdracht

3. De uitgangspositie is zoals in figuur 4.1 getekend, dusmet voldoende blokken in het magazijn, een blok onderde boormachine en alle cilinders in de ingetrokken stand.

4. De documentatie moet volgens de SQS-methode geschre­ven worden, het conceptueel- en implementatiemodelmoeten met de methode van Yourdon ontwikkeld wor­den.

5. Bij de ontwikkeling van een conceptueel- en implementa­tiemodel moet gebruik gemaakt worden van een CASE­tool.

99

automatiseren

contexteenvoudig model

terminator

Een opdracht

Boormachine

Figuur 5.2: Ben mogelijk contextmodel

5.3.3 Het conceptueel-model

De doelbeschrijving

Ret doel van het boorsysteem is het automatiseren van eenboormachine waarmee gaten in houten blokken geboord kun­nen worden.

Het contextmodel

Ret boorsysteem heeft de boormachine met bijbehorende ci­linders, schakelaars en het magazijn als context. In figuur 4.2is een heel eenvoudig contextmodel getekend, waarbij de helemachine met alles erop en eraan als een terminator gezienwordt. Een nadeel van deze oplossing is dat er weinig in­formatie door gegeven wordt. Daarom is het model van fi­guur 4.3 beter. Rier zijn de terminators de drie cHinders ende schakelaar p, samen met het lampje en de schakelaar st.De 'schakelaar en lampje'-terminator heeft een flow waarmeede stand van de schakelaar aangegeven wordt en een waarmeehet lampje aan- of uitgezet kan worden. Elke cilinder heefteen flow w·aarmee de stand van de cilinder aangegeven wordten een waarmee de cilinder gestuurd kan worden.

100

Vulcilinder Atvoercilinder

A8rWIllChakeIaar(II)

Figuur 5.3: Een beter contextmodel

gebeurtenissen

Een opdracht

De event-list

Ret boorsysteem moet reageren op de volgende gebeurtenissen(tussen haakjes staan de akties die gestart moeten worden):

1. Er zijn geen blokken meer (er mogen nog drie blokkengeboord worden).

2. Er zijn weer blokken (het waarschuwingslampje moetuitgeschakeid worden, waarna het boren weer hervat kanworden).

3. Stand ao is bereikt (dus er is een biok weggeduwd en deafvoercilinder bevindt zich weer in de uitgangspositie;de volgende boorcyclus kan gestart worden).

4. Stand at is bereikt (dus er is een biok weggeduwd; deafvoercilinder kan teruggetrokken worden).

5. Stand bo is bereikt (de boor bevindt zich weer in deuitgangspositie dus kan de volgende stap van de cyclusgestart worden).

101

besturing

besturingsprocessen

dataprocessen

1 proces voorelke terminator

Een opdracht

6. Stand bl is bereikt (het gat is geboord dus de boorma­chine kan teruggetrokken worden).

7. Stand Va is bereikt (de vulcilinder bevindt zich weer inde uitgangstoestand dus het volgende blok kan onder deboormachine geschoven worden).

8. Stand VI is bereikt (de vulcilinder heeft een blok onderde boormachine geduwd, dus het boren kan beginnen).

9. De schakelaar st wordt in de stand'Aan' gezet (de boor­cyclus moet gestart worden).

10. De schakelaar st wordt in de stand 'Uit' gezet (de boor­cyclus moet gestopt wordt, dus de spanning wordt vanaIle bekrachtigde relais gehaald). Als dit gebeurd ismoet de totale machine weer in de uitgangstoestand ge­zet worden.

Het dataflowdiagram

Met behulp van de beschrijving van de boorcyclus kunnenwe een besturing voor de machine opzetten. Alles wat hetsysteem moet dgen is de genoemde stappen een voor een uit­voeren. Om dat te verwezenlijken kunnen we gebruik makenvan een besturingsproces en een aantal processen waarmee decilinders gestuurd en de sensoren uitgelezen kunnen worden.In figuur 4.4 is een oplossing weergegeven. Voor elke cilin­der is er een proces dat de signalen van de sensor ornzet naareventflows, en de eventflows van het besturingsproces naarsignalen voor het aansturen van de cilinders.Voor de schakelaar p en het lampje is er een proces waar­mee een signaal 'Blokken..voorraad' gegenereerd wordt. Ditsignaal krijgt pas een waarde als er echt geen gaten meer ge­boord kunnen worden, dus als ook de laatste drie blokken opZIJn.Voor de schakelaar st is er een apart proces waarmee de standvan de schakelaar doorgegeven wordt.

102

IFlguurO:8ocn)'MlmI

AOA1Clf1M1nge.!l-

~ontvMgen I" ",-

VulJ"_ul /~1..i. '( "'-~_In_u11........ I BoormachIne

................ beJturing r-~~en• ) /. \ Boorapct8Cfll

BIOldI4IfUfClClI'raad.............. "-.l- "....... ." P3

....... \ Boot_In_Ut'-.

BOontY8ngen __ L _AIn_uI

P5

"WII BO

Figuur 5.4: Figuur 0 van het DFD

Een opdracht103

Een opdracht

flQuur 3: Besluur boon:iIinde~

I+BOB1onlvangen

/\BOontvangen / \

II ~

Figuur 5.5: Uitwerking van 'Bestuur boorcilinder'

Er zijn in figuur 4.4 vijf nog niet gedefinieerde processen ge­tekend.In figuur 4.5 is een mogelijke uitwerking van 'Bestuur boor­cilinder' gegeven. De besturing voor de andere cilinders zieter hetzelfde uit. We zien in de figuur twee processen 'Be­waak boorcilinder', waarmee 'Boorstand' omgezet wordt inde events 'BOontvangen' en 'Blontvangen' (gebundeid in'BOBlontvangen') en 'Geef booropdrachten', waarmee 'Boor_in_uit' opdrachten omgezet worden in spanningen waarmeehet relais voor de boorcilinder bekrachtigd wordt. Er is ooknog een eventflow 'BOontvangen' die noodzakelijk is voor hetproces 'Bewaak schakelaar en Iampje'. De andere cilinderskunnen op dezelfde manier uitgewerkt worden, alleen kan daarhet event 'BOontvangen' komen te vervallen.'Bewaak st' kan weI tekstueel gespecificeerd worden.

104

PSland

I

BOonlvangen

Een opdracht

Figuur 5.6: Uitwerking van 'Bewaak schakelaar en lampje'

'Bewaak schakelaar en lampje' is uitgewerkt in figuur 4.6.Ret proces 'Overgang detector' genereert de eventflow 'Blok­ken.op' als de spanning van de benaderingsschakelaar p over­gaat van positief naar negatief. 'Blokken..aa.ngevuld' wordtgegenereerd in het omgekeerde geval. Met behulp van dezetwee eventflows en 'BOontvangen' kan bepaald worden wan­neer het boren gestopt, en wanneer het weer hervat kan wor­den.

105

6

_Uaangevuld'

1~

, Er zijn genoeg ---bIokk8n

, Biokkerulp

BlokJlen_ungevulc

2E~~3.----

2 @Oonlvangen

BlokJlen ungevuld3E~~2

.-----

~5BIokJlen ungevulduur 'B=n voorr

3 BOontvangen ~ luur "Lampje:ul'

lokJlen aangevuld

" Er is nog , bloK

-

" BOontvangenSlwr 'BloIdIen_voorraad:=

Stuur 'L.ampfe_

5 Er zljn geenbIokk8n meer

I---

7

8B

Figuur 5.7: Toestandsdiagram voor 'Schakelaar besturing'

het centralebesturingsproces

Het besturingsproces is gespecificeerd in figuur 4.7.Tenslotte moeten we nog het centrale besturingsproces van'Figuur 0' specificeren. Dit is gedaan in figuur 4.8. Met dittoestandsdiagram wordt de boorcyclus bestuurd. Als de scha­kelaar st in de stand 'Uit' gezet wordt, keert de machine terugnaar de begintoestand. Dit kan vanuit elke toestand gebeu­ren, maar is niet getekend omdat de figuur dan niet meeroverzichtelijk zou zijn.

Een opdracht 106

openen

llIde

12 BlokkerUlp en SIll

Blokken ~8YUld en 11811VuurCl1:7i'

2 Wachl lot vullen

"Blokken aangeyul

10 vOonlvangen:: VULln_un:.""UI'

2v1onl~enBiokken_aangevu

9080'-~ ai' VuUn_uk:- Oil

3 Wachl op boren8 Wachllot bIokken

aangevuld

3 B1onlv~en 5 BiokkenBoor_rl_u:a In' VOonlvaiig

" Wachllol boor 7 Wacht op vullenleruggelrokken letUggelrokken

~

Ie .BQonlvan~en 17 AOonlll:lnnenI'tvoer_ln_u :- U~' !VuLln_un:-,n

5 Wachl op alvoeren 6 Wachl op alvoerteruggelrokken

llAOont~enAIvOii_lIuF. in'

Figuur 5.8: Toestandsdiagram voor 'Boormachine besturing'

Een opdracht 107

Ben opdracht

De datadictionary

De datadictionary ziet er als voIgt uit:

80 = ['Hoog' I 'Laag']* De output van de sensor ao kan de twee niveau's 'Hoog'en 'Laag' aannemen. ** De andere sensoren worden op dezeide manier gedefi­nieerd. *

AOAlontvangen = ['AOontvangen' I 'Alontvangen']* Vertaling van de afvoer-sensorstand. *

Aan_uit = ['Start' I 'Stop']* Starten of stoppen van de boorcyclus. *

Afvoer-in_uit = ['In' I 'Dit']* Opdracht voor het afvoer-relais. *

Afvoeropdracht = ['In' I 'Dit']* 'In': relais niet bekrachtigd, 'Dit': relais bekrachtigd.

*BOontvangen =

* Geeft aan dat een biok geboord is. *BOBlontvangen = ['BOontvangen' I 'Blontvangen']

* Vertaling van de boor-sensorstand. *boor-in_uit = ['In' I 'Dit']

* Opdracht voor het boor-relais. *Booropdracht = ['In' I 'Dit']

* 'In': relais niet bekrachtigd, 'Dit': relais bekrachtigd.

*Biokken_aangevuld =

* Geeft aan dat blokken weer aangevuld zijn. *Blokken-op =

* Geeft aan dat volgens de benaderingsschakelaar deblokken op zijn. *

108

tekstuelespecificatie

Blokken_voorraad = ['Blokken_op' I 'Blokken...a.angevuld']* Geeft aan of er nog geboord mag worden. *

Lampje_aan_uit = ['Aan' I 'Vit']* Opdracht om lampje aan of uit te schakelen.*

Lampopdracht = ['Aan' I 'Vit']* Lampje aan of uit. *

P -stand = ['Vol' I 'Leeg']* Signaal van de benaderingsschakelaar p. *

St-stand = ['Aan' I 'Vit']* Stand van schakelaar st. *

VOVlontvangen = ['VOontvangen' I 'V1ontvangen']* Vertaling van de vul-sensorstand. *

VuLin_uit = ['In' I 'Vit']* Opdracht voor het vul-relais. *

Vulopdracht = ['In' I 'Vit']* 'In': relais niet bekrachtigd, 'Vit': relais bekrachtigd.

*

De processpecificaties

De dataprocessen die niet in een diagram uitgewerkt zijn moe­ten nog tekstueel gespecificeerd worden.De cilinders zijn eigenlijk allemaal hetzelfde zodat we kun­nen volstaan met een specificatie voor 'Bestuur boorcilinder'.Ben mogelijke specificatie voor de twee processen hiervan isde volgende:

Input:Output:

Een opdracht

P3.1:Doel:

Bewaak boorcilinderRet vertalen van de elektrische signalen van desensoren in de hoorcilinder na.a.r events voor dehesturing.ho, hiBOB1ontvangen

109

Oude..stand

Geef booropdrachtenHet vertalen van booropdrachten naar het al danniet bekrachtigen van het boor-relais.Boor-in_uitBooropdracht

Input:Output:BEGIN

IF BoorJn_uit='Uit' THENREPEAT

Booropdracht:='Uit'UNTIL BoorJn_uit='In'

ENDIFEND

Lokaal:BEGIN

IF bo='Hoog' AND Oude..stand='b1 ' THENBOB lontvangen:= 'BOontvangen'Oude..stand:= 'bo'

ELSEIF b1 ='Hoog' AND Oude..stand='bo' THEN

BOB lontvangen:= 'Blontvangen'Oude_stand:='b1 '

ENDIFENDIF

ENDP3.2:Doel:

Ret proces 'Bewaak st' kan gespecificeerd worden zoals 'Be­waak boorcilinder'. Ook 'Overgang detektor' en 'Schakelaar'mogen geen problemen meer opleveren.

5.3.4 Het implementatiemodel

flip-flop

Het processormodel

Ret is mogelijk om aIle processen te implementeren op eendigitaIe computer, bijvoorbeeld een micro-controller. Er isechter een' nog eenvoudiger oplossing door een deel van deprocessen in hardware te implementeren.Om de relais te bekrachtigen kunnen we gebruik maken vaneen trigger flip-flop. Doordat bijvoorbeeld 'Booropdracht' van

Een opdracht 110

Een opdracht

Figuur 5.9: Het processormodel

waarde verandert wisselt oak de output van de flip-flop vanwaarde. Er is een initialisatie nodig om ervoor te zorgen datde stand van de cilinders overeen komt met de gewenste uit­gangspositie.De rest van de processen kunnen geimplementeerd worden opeen micro-processor.Ret processormodel ziet er nu uit zoals in figuur 4.9 getekend.

111

Een opdracht

Figuur 5.10: Ret taakmodel

Bet taakmodel

Ret taakmodel is eenvoudig op te stellen. De makkelijk­ste oplossing is het definieren van een taak voor elk data­proces in figuur 4.4 (behalve de processen die met flip-flopsgeimplementeerd zijn). We kunnen deze taken als interrupt­handlers zien, die geaktiveerd worden door een signaalover­gang op een interruptlijn (bijvoorbeeld een omhooggaandeflank op lijn 'bo').Ret besturingsproces kunnen we dan zien als de hoofdtaak,die de output (het bekrachtigen van de relais en het schakelenvan het lampje) verzorgt.Ret taakmodel is getekend in figuur 4.10.

112

interrupthandler

Ben opdracht

Het modulemodel

Voor elke taak moet een modulemodel gemaakt worden. Indit geval zijn deze modellen weI erg triviaal, omdat de meestetaken niet meer dan een proces bevatten.Voor de taken waarmee de cilinders en schakelaars bekekenworden moeten we een interrupthandler schrijven. Dit kanmet een module die door een interrupt geaktiveerd wordt. Inde code moeten we rekening houden met het 'denderen' vande schakelaars.De hoofdtaak kan gecodeerd worden met een standaardrou­tine voor het doorlopen van toestandsdiagrammen.De taak voor de schakelaar p en het lampje moet zowel dooreen hardware-interrupt (een niveauverandering in het signaalvan p) als door een software-interrupt (het signaal 'BOont­vangen' dat gegenereerd wordt door de boorcilinder-taak) ge­aktiveerd worden. Daarom is het beter om twee handlers teschrijven. De twee routines delen een semafoor waarmee hetaantal blokken bijgehouden wordt. Het besturingsproces kanweggelaten worden.

113

Hoofdstuk 6

Limozuki

6.1 Inleiding

Na de eerste eenvoudige voorbeelden wordt het nu tijd om eenwat ingewikkelder probleem met behulp van SQS en Ward/Mellor aan te pakken.We gaan ervan uit dat de lezer ondertussen vertrouwd is ge­raakt met de terminologie.Ret beschreven voorbeeld gaat over de fictieve Japanse limo­nadefabriek Limozuki, waarvan we een gedeelte zuBen model­leren.

6.2 De omgevingsanalyse

Ret management van de Japanse limonadefabriek Limozukiheeft besloten het bottelen van limonades te automatiserenom zo de moordende concurrentie het hoofd te kunnen bie­den. Ret doel is de huidige fabriek aan te passen zodat dezedoor niet meer dan een operator bediend kan worden. Debestaande apparatuur moet via een computersysteem aan el­kaar geknoopt worden. Dit houdt in dat het systeem een grootaantal aktiviteiten van menselijke operators uit moet voeren.Limozuki produceert drie soorten limonade, Coca-cola, Cas­sis en 7-Up. Coca-cola wordt geleverd in de bekende speciale

115

Limozuki

£lessen, de andere twee dranken zit ten in dezelfde standaard­£lessen. Alle soorten limonade zijn verkrijgbaar in literflessenen in kleine £lesjes van 33 centiliter.In figuur 6.1 is een schets van de fabriek gegeven. De routevan een £les door het systeem is globaal als voIgt:

1. De £les wordt door een robot uit een container met lege£lessen gehaald en op een van de twee transportbandengezet. Er zijn vier containers voor grote en kleine Cola£lessen en voor grote en kleine standaard £lessen (voor7-Up en Cassis).

2. Voor elke transportband is een schoonmaak-installatiebeschikbaar. Na het schoonmaken wordt met behulpvan een sensor bepaald of de £les schoon, vuil of kapot is.Kapotte £lessen worden afgevoerd naar een stortplaats,vuile £lessen gaan weer de container in.

3. Flessen die zowel heel als schoon zijn gaan door naarhet einde van de band waar ze samengevoegd wordenmet de stroom £lessen van de tweede band. Door eencomputer-gestuurd mechanisme worden de £lessen overtwee andere banden verdeeld.

4. De £lessen worden gevuld door een vul-installatie die aIlesoorten £lessen aankan. De installatie is in staat te be­palen wat voor soort £les voorhanden is en ook wanneerdeze deze vol is.

5. Na het vullen voIgt een installatie waarmee de £lessenafgesloten kunnen worden.

6. Ret vullen en afsluiten van £lessen gaat met nogal watgeweld gepaard, zodat het nodig is de £lessen op defectente co.ntroleren. Dit gebeurt zowal na het vullen als nahet afsluiten. Kapotte £lessen worden afgevoerd naar destortplaats.

116

Hn421

lege ~flessen IIoftclt

~

.1

14---~--I ofsluiten

schoonmook

schoonmook

Limozuki

Figuur 6.1: De transportband en machines van Limozuki

117

Limozuki

7. Na het vullen en afsluiten moeten de £lessen nog eenetiket krijgen. Riervoor is slechts een machine beschik­baar, die in principe snel genoeg is de stroom £lessente voorzien van een etiket. Ret is echter mogelijk datde etiketten voor een bepaalde drank op raken. Omte voorkomen dat dan de hele fabriek stilgelegd moetworden terwijl de operator de etiketten bijvult, is eenbufferband aangelegd. Flessen die tijdelijk niet van eenetiket voorzien kunnen worden, worden hierop gescho­ven en zo snel mogelijk aIsnog geetiketteerd.

8. Tenslotte worden de £lessen in een krat gezet dat doorgeautomatiseerde heftrucs op een klaar staande vracht­wagen geschoven wordt.

De operator kan via een terminal informatie krijgen over hetproces in de fabriek en kan aIle lijnen apart of tegelijk aan­en uitschakelen.Ret is de bedoeling dat een groothandelaar met zijn vracht­wagen de fabriek in kan rijden en zijn bestelling door kangeven aan het systeem. De £lessen worden dan zo snel moge­lijk gevuld en naar de vrachtwagen getransporteerd, waarnade handelaar een seintje krijgt dat hij kan vertrekken. Af­rekenen geschied via een creditcard bij een geautomatiseerdekassa.Ret doel van het geheel is het aantal £lessen dat de fabriekverlaat te maximaliseren. Er kunnen maximaal 50 vrachtwa­gens tegelijk bediend worden.Onderstaande apparatuur staat ter beschikking:

• Een sensor waarmee bepaald kan worden of er nog £les­sen in een van de vier containers zitten.

• Een robot waarmee £lessen op een van de twee trans­portbanden gezet kunnen worden.

• Per transportband een sensor die aangeeft of er een £lesbij kan.

118

Limozuki

• Schoonmaakmachines.

• Sensoren waarmee bepaald kan worden of een Hes vuilis.

• Sensoren waarmee bepaald kan worden of een Hes kapotIS•

. • Mechanismen in de transportband die £lessen van tweebanden samen kunnen voegen, waarbij wordt aangege­ven van welke band een fles gehaald wordt.

• Mechanismen om £lessen van een band te verdelen overtwee andere banden, afhankelijk van een stuursignaal.

• Vulmachines.

• Machines waarmee flessen afgesloten kunnen worden.

• Ben etiketteermachine.

• Ben systeem waarmee kratten getransporteerd kunnenworden.

• Een systeem dat rekeningen produceert en betalingenmet een creditcard accepteert.

• Ben systeem waarmee bestellingen opgenomen kunnenworden.

• Ben terminal waarmee de operator de fabriek kan be­sturen.

Bij de ontwikkeling van het programma dient gebruik gemaaktte worden van SQS en de methode van Yourdon. Er is eenPC en een CASE-tool beschikbaar om de ontwikkeling uit tevoeren.

119

Limozuki

6.3 Eisendefinitie

Uit de beschrijving in de vorige paragraaf kunnen we afieidenwelke eisen aan het systeem gesteld worden:

• Bestellingen moeten door het systeem opgenomen engeinterpreteerd worden zonder dat daar een operatoraan te pas mag komen. Uit de bestelling moet afgeleidworden welke :£lessen gevuld moeten worden.

• De klant moet op eenvoudige wijze via een terminal zijnbestelling aan het systeem kenbaar kunnen maken.

• Flessen moeten de juiste dop en het juiste label krijgen.

• In verband met de veiligheid moet het systeem in staatzijn zichzelf bij potentieel gevaarlijke situaties (overver­hitting bijvoorbeeld) geheel of gedeeltelijk uit te scha­kelen.

• Ret systeem moet de bestelling van een klant naar dejuiste vrachtwagen sturen en een rekening produceren.Zodra de vrachtwagen gevuld is moet de eigenaar ervaneen seintje krijgen. De klant kan dan bij het automati­sche kassasysteem betalen.

• De operator moet via een terminal het systeem kun­nen overzien. Dit houdt in dat informatie beschikbaarmoet zijn over de toestand van apparatuur en het aan­tal :£lessen van elke 500rt dat op bepaalde plaatsen inhet systeem passeert. De operator moet via de terminaldelen van het systeem apart en het hele systeem ineensuit kunnen zetten.

• De operator moet informatie over de prijs van de dran­ken in kunnen voeren via de terminal.

• Als het systeem na een calamiteit opnieuw opgestartmoet worden, moet de operator via de terminal infor­matie over de :£lessen die zich op de band bevinden aan

120

terminatorsdata-uitwisseling

Lirnozuki

de diverse eenheden van het systeem door kunnen geven,zodat de produktie met zo weinig mogelijk verliezen her­vat kan worden.

• Het management wi! graag periodieke rapporten over deprestaties van het systeem. Deze rapporten moeten au­tomatisch geproduceerd worden, maar ook op aanvraagbeschikbaar zijn.

• Tenslotte moet het systeem met behulp van de in devorige paragraaf vermelde apparatuur, aangevuld metcomputers en netwerken, gerealiseerd worden.

5.1 Het conceptueel-model

5.1.1 De doelbeschrijving

Het doe1 van het systeem is het automatiseren van de Limo­zawa limonadefabriek, zodat deze door ren operator bediendkan worden. De uitstroom van £lessen uit de fabriek moet zogroot mogelijk zijn.

5.1.2 Het contextdiagram

Het contextdiagram geeft het systeem weer als een proces, indit geval 'Limozuki' genaamd, met een aantal terminators en£lows tussen de terminators en het proces. Om het diagram opte kunnen stellen moeten we nagaan met welke terminatorshet systeem te maken heeft en welke data ermee uitgewisseldwordt. Voor Limozuki zijn de terminators de schoonmaak­machines, de robot, de transportbanden, de vulmachines, deafsluitmachines, de labelmachine, het transportsysteem tus­sen het ei~de van de lopende band en de vrachtwagens, determinals voor bestellingen en voor de operator en tenslottede automatische kassa. Het gedrag van al deze machines be­staat uit een aantal vaste mogelijkheden waarvan we er een

121

bundeling vansignalen

Limozuki

moeten kiezen. Daarnaast geven ze een aantal signalen (la­bels zijn op, fles is kapot) waarop een automatiseringssysteemzou kunnen reageren. Om de fabriek te kunnen automatiserenmoet het systeem de signalen van de machines opvangen, ver­werken en omzetten in stuursignalen voor andere machines.Wat het systeem dus aan het geheel toevoegt is een interpre­tatie die het mogelijk maakt om met de signalen van de enemachine de akties van een andere te sturen.In figuur 6.2 is het contextdiagram gegeven. Ten behoevevan de overzichtelijkheid van het diagram zijn niet aIle sig­nalen die tussen omgeving en systeem uitgewisseld wordengetekend. Ret was nodig om signalen te bundelen en weer tegeven door een enkele flow. Dit is niet helemaal volgens deregels van de kunst, maar helaas moest het vanwege het groteaantal signalen. Als terminators zijn gebruikt:

Robot en containers De robot haalt flessen uit een contai­ner en zet deze op een door het systeem te specificerentransportband.De Containers geven een signaal waarmee aangegevenwordt of ze leeg zijn of niet. Daarnaast kan via een aan­tal druktoetsen aangegeven worden welke soort flessenin welke containers zitten.

Schoonmaaksystemen De schoonmaakmachines detekterenwanneer een fles op een van de transportbanden beschik­baar is, gaan over tot het schoonmaken ervan en produ­ceren een signaal waarmee de afloop van het schoon­maakproces aangegeven wordt. Een tweede functie ishet controleren van de toestand van de fles na het schoon­maken (schoon of vuil, heel of kapot).

Vulsystemen De vulmachines detecteren wanneer een flesbesc4ikbaar is en wachten dan op een opdracht om de£les ergens mee te vullen. Na afloop van het vullen wordteen signaal gegenereerd, de fles op de volgende trans­portband gezet en de toestand van de £les gecontroleerd(heel of kapot).

122

Terminal(beIte/ling)

Kassa

RoboC encontainenl

Limozuki

Figuur 6.2: Het contextdiagam van Limozuki

123

Limozuki

Afsluitsystemen De afsluitmachines detecteren wanneer een£les beschikbaar is en wachten dan op een opdracht omeen bepaalde kroonkurk op de £les aan te brengen. Na­dat de kroonkurk aangebracht is wordt een signaal ge­genereerd, de fles op de volgende transportband gezeten de toestand van de £les gecontroleerd (heel of kapot).

Etiketteersysteem De etiketeermachine brengt een etiketaan als er een £les langskomt en het systeem een op­dracht gegeven heeft. Als er geen opdracht is wordt eensignaal gegenereerd dat aangeeft dat de transportbandstilgelegd moet worden. De machine geeft ook informa­tie over de voorraad etiketten.

Transport De transportbanden en schakelaars zijn samen­gevoegd in de terminator 'Transport'. Elke transport­band kan gestopt of gestart worden. Er is informatiebeschikbaar over de toestand waarin de band zich be­vindt en of het begin van de band vrij is. De stand vande schakelaars kan door het systeem bepaald worden.De schakelaars waarmee twee stromen £lessen samenge­voegd worden geven een signaal dat aangeeft van welkeband een fles gehaald is.

Terminal (operator) De terminal voor de operator is eenapparaat dat in staat is om voorgedefineerde menu'sop een beeldscherm te zetten. Ret staat de gebruikertoe om een keuze te maken waarmee een opdracht aanhet systeem gegenereerd wordt. Daarnaast is ruimtevoor het weergeven van alarmboodschappen. Aile bood­schappen worden naar een printer gestuurd. Deze prin­ter is ook in staat de rapporten voor het managementaf te drukken.

Kassa De kassa krijgt van het systeem rekeningen voor deklanten en handelt daarna de betaling verder af. Doorop een knop te duwen kan de klant om hulp vragen.

124

Limozuki

Terminal (bestelling) De terminal voor het opgeven vanbestellingen verzorgt de dialoog met de klant en geeftdiens bestelling door aan het systeem. De klant krijgtdaarna het nummer van de plaats waar hij zijn vracht­wagen moet parkeren. Door op een knop te duwen kande klant om hulp vragen.

Afvoer Bet afvoersysteem verzorgt het transport van ge­vulde £lessen naar kratten en het transport van krattennaar de juiste vrachtwagens.

Alle terminators geven met een signaal hun status weer (defectof OK) en kunnen met een relais uitgeschakeld worden.

6.4.3 De event-list

De eventlist van Limozuki ziet er als voIgt uit:

1. Robot raakt defect.Deze gebeurtenis vraagt om een aktie van het systeem,namelijk het geven van een alarmmelding aan de opera­tor. Er zou een event 'Robot is weer OK' gedefinieerdkunnen worden. Dit heeft echter alleen zin als van hetsysteem een aktie verlangd wordt. Dat is niet het geval,want als de robot defect is zal alleen de aanvoer van £les­sen naar de andere apparaten stoppen. Zodra de robotgerepareerd is komen er weer £lessen en kan het systeemweer doorgaan.

2. Container is leeg.

3. Container is weer vol.Bier is een event 'Container is weer vol' toegevoegd zo­dat het systeem na het optreden van een 'Container isleeg"event op kan houden met het sturen van opdrach­ten om een £les uit de lege container te halen. Zodrade container weer bijgevuld is kan het sturen van debetreffende opdrachten hervat worden.

125

Limozuki

4. Schoonmaakmachine 1 (of 2) heeft een fles schoonge­maakt.Nadat een fles schoongemaakt is moet deze door deschoonmaakmachine op de transportband gezet worden.Deze band moet dan natuurlijk weI vrij zijn. Daaromworden bovengenoemde events gedefinieerd: het sys­teem kan nu wachten tot de transportband vrij is endaarna de schoonmaakmachine opdragen de fles op deband te zetten.

5. Schoonmaakmachine 1 (of 2) is vastgelopen.

6. Fles op band 3 (of 4, 13, 14, 21, 22) is kapot.

7. Fles op band 3 (of 4, 13, 14, 21, 22) is heel.

8. Fles op band 3 (of 4) is vuil.

9. Fles op band 3 (of 4) is schoon.Al deze gebeurtenissen vragen om een schakelaarstand.

10. Vulmachine 1 (of 2) is vastgelopen.

11. Vulmachine 1 (of 2) heeft een fles gevuld.

12. Afsluitmachine 1 (of 2) is vastgelopen.

13. Afsluitmachine 1 (of 2) heeft een fles afgesloten.

14. Etiketteermachine is vastgelopen.

15. Cola etiketten (of Cassis, 7-Up) zijn op.

16. Cola etiketten (of Cassis, 7-Up) zijn aangevuld.

17. Band 1 vastgelopen.

18. Band 32 vastgelopen.

19. Schakelaar 1 is vastgelopen.

126

Limozuki

20. Schakelaar 13 is vastgelopen.We zouden nu kunnen kiezen voor events waarmee aan­gegeven wordt dat de banden of schakelaars het weerdoen. In dit geval zouden we Hessen om kunnen leidenals een van de banden van bijvoorbeeld een vulmachinevastloopt. Dit is niet gedaan om de zaak niet te inge­wikkeld te maken. Er is natuurlijk niets dat de lezertegenhoudt om het systeem met deze extra faciliteit uitte breiden.

21. Afvoer is overbelast.

22. Afvoer-opdracht uitgevoerd.

23. Kassa raakt defect.

24. Klant 1 heeft betaald.

25. Klant 50 heeft betaald.

26. Klant vraagt om assistentie bij betaling.

27. Bestelapparatuur raakt defect.

28. Klant vraagt om assistentie bij bestelling.

29. Bestelling ontvangen.

30. Operator terminal hangt.

31. Alarm ontvangen.

32. Melding ontvangen.

33. Opdracht ontvangen.

Deze lijst is niet volledig voor de onderdelen van het systeemdie niet verder uitgewerkt zullen worden.

127

eventpartitioning

interfacelaag

Limozuki

6.4.4 Het dataflowdiagram

Vaak is event partitioning een goede manier om een eersteversie van het data:fl.owdiagrarn te verkrijgen. Door voor elkevent een proces te definieren krijgen we een groot aantalprocessen op een diagram die we voor de overzichtelijkheidkunnen groeperen in processen van een hoger niveau. Dezeaanpak zou in dit geval al gauw uit de hand lopen gezien hetgrote aantal events.Daarom is het probleem anders aangepakt, en weI door het de­finieren van een interfacelaag. We kunnen het dataflowdiagramopgebouwd denken uit twee lagen (zie figuur 6.3). De bui­tenste interfacelaag schermt de rest van het systeem af vande eigenschappen van randapparatuur. Vooral in industrieleomgevingen kan dit van groot belang zijn, omdat bij de be­sturing van niet-digitale apparatuur veel zaken komen kijkendie voor het systeem als geheel niet belangrijk zijn. Wat weeigenlijk doen is een besturing voor elk randapparaat maken.De taak van deze besturingen is het omzetten van opdrach­ten van het systeem in opdrachten voor het randapparaat enhet interpreteren van de signalen die het randapparaat terbeschikking stelt.

128

Limozuki

r-------------------------~

I e ....-...,I twoo _ -.akJi~qJ _' b= L !!ttb'e.!J'L _ ...I 1 deaktiveer \.... rd' deaktiveer

------I--'---1. t 00 fI I ... - Igenereer antwoordI L - - - - - - - - - - - rB- ,c.. - - - - - - - - _ - .JI I IIII Ding I

I event herkenning t 'L I

I

'A

Figuur 6.3: DFD met event herkennigslaag

129

hulpmiddel

decompositie

events

Limozuki

Deze techniek toegepast op Limozuki levert het diagram infiguur 6.4 op. De processen in deze figuur vormen het inter­face tussen het systeem (dat niet getekend is) en de omgeving.Processen die we verder niet uit zullen werken zijn samenge­voegd in het proces 'De rest'.Het is belangrijk om in te zien dat dit diagram geen onder­deel van het uiteindelijke dataflow diagram zal vormen (tenniinste, niet zonder aanpassingen): het is een hulpmiddel omtot het uiteindelijke diagram te komen. Door het maken vaneen eerste indeling hebben we het probleem in overzichtelijkestukken gehakt, die nu vrijwel onafhankelijk van elkaar aan­gepakt kunnen worden. We kunnen nu gebruik maken van degedefinieerde events om elk onderdeel van het systeem verderuit te werken.

130

TermillllUnlo

Alslui,-beslurilg

Figuur 6.4: De eente venie van bet DFD

Limozuki 131

Opdracht 6.1

event-list

functiebeschrijving

internecommunicatietoevoegen

bemonstering

Limozuki

Breidt het diagram uit met processen voor de andere ter­minators.

Robot en container besturing

Ais eerste zul1en we de robot en de containers bekijken. Defuncties van het proces 'Robot en container besturing' zijn hetvertalen van opdrachten van het 8ysteem naar opdrachten diegeschikt zijn voor de robot, het genereren van een melding alser problemen met de robot zijn, als een van de containers leegis en als de container weer vol is. Nu blijkt dat we met detwee events uit de vorige paragraaf die betrekking hebben opde robot en de containers niet alle taken van het proces gehadhebben: het uitvoeren van een opdracht van het systeem komtniet tot uitdrukking in de event-list. Ret is dus niet zo datde event-list het enige hulpmiddel is dat we ter beschikkinghebben om het systeem te ontwerpen; een goede beschrijvingvan de uit te voeren functies is minstens even belangrijk.Ais we de lijst van gebeurtenissen uitbreiden met 'Opdrachtaan robot ontvangen' kunnen we drie processen tekenen: 'Be­waak containers', 'Bewaak robot' en 'Grijp fles' voor het uit­voeren van een opdracht van het systeem. Deze processenen hun inputs zijn getekend in figuur 6.5. De flow 'Contai­ner-status' is een onderdeel van 'Containerjnfo' en geeft aanof een container leeg of vol is. 'Robot-status' is een onderdeelvan 'Robot-info' en geeft aan of de robot defect is of niet.'Zet..fles_op_band' tenslotte is een opdracht van het systeemaan de robot om een bepaald soort fles op een transportbandte zetten.We hebben nu aIleen nog maar een begin, wat nog toege­voegd moet worden zijn flows voor de communicatie met het8ysteem en het doorgeven van opdrachten aan de robot. Daar­naast moeten we een mechanisme hebben om op te slaanwelke soort flessen in de containers zitten. Tenslotte is deflow 'Container-status' een continue flow. Dit 800rt flows iszonder bemonstering niet door een digitale computer te be­werken. De communicatie met de robot gaat via de flow 'Ro-

132

Limozuki

Figuur 6.5: Eerste uitwerking van 'Robot en container bestu­ring'

boLcommando'. Dit signaal kan de waarden 'Reset', (Contai­nernummer, Bandnummer) en 'Stop' aannemen. Container­nummer kan de waarden 'Container!', 'Container2', 'Contai­ner3' en 'Container4' aannemen. Bandnummer kan de waar­den 'Band!' en 'Band2' aannemen. Voordat een volgende op­dracht uitgevoerd kan worden moet de vorige afgerond zijn.Ret systeem mag dus pas een volgende opdracht geven alsde robot een aagegeven heeft dat de vorige afgerond is. Omdit aan te geven is de flow 'Rob_com..uitgevoerd' toegevoegd.Deze flow is een onderdeel van 'Robotjnfo'.Voor het doorgeven van meldingen kunnen we de flow 'Ro­bot..rnelding' invoeren. Deze melding is samengesteld uit een'RoboLdefect..melding' en een 'ContainerJeeg..melding', detwee situaties die het 'Robot en container besturing' aan hetsysteem door moet geven zodat de operator gewaarschuwdkan worden.Om te kunnen onthouden welke flessen in de vier containerszitten kunnen we de store 'Container inhoud' invoeren.Om de communicatie tussen het proces 'Bewaak containers'

133

synchronisatiestore

Limozuki

RabaUnlo

Figuur 6.6: Bet proces 'Robot en container besturing'

dat eigenlijk continu uitgevoerd zou moeten worden en hetproces 'Grijp Bes' dat aileen uitgevoerd wordt als daarom ge­vraagd wordt, te synchroniseren moeten we een store 'Fles_voorraad' invoeren. Zodra de voorraad £lessen van een be­paalde soort verandert, past 'Bewaak containers' de inhoudvan 'Fles_voorraad' aan. 'GrijpJies' kan de inhoud van destore uitlezen vlak voordat de uitvoer van een opdracht be­gint. Dit alles leidt tot een dataflowdiagram van figuur 6.6.

134

funetionerenvulmachine

architectuur­beschrijving

Limozuki

De vulmachines

Ret tweede proces dat we uit zullen werken is dat voor debesturing van de vulmachines.Om een goed ontwerp te kunnen maken moeten we iets meerweten van de manier waarop een vulmachine functioneert. Demachine werkt als voIgt: Ret systeem geeft de opdracht omeen fies te vullen met een bepaalde drank. De machine wachtdan tot een fies beschikbaar is, haah deze van de band en starthet vulproces. Als het vulproces afgesloten is wordt een sig­naal gegenereerd, waarop het systeem gaat wachten tot er eenband vrij is waar de gevulde fies opgezet kan worden. Zodradit het geval is krijgt de vulmachine de opdracht om de fiesop de band te plaatsen. Daarna wordt de fies gecontroleerddoor een sensor, die automatisch een signaal genereert zodraer een fies voorbij komt. Aan de hand van het sensorsignaalwordt bepaald wat de stand van de schakelaars 7 en 8 moetZIJn.Omdat de vulmachines niet helemaal betrouwbaar zijn voerenwe ook nog een timer in zodat het systeem in kan grijpen alshet vullen van een fies te lang duurt.Opmerking: deze beschrijving kan ook heel goed bij de be­schrijving van de terminators in het contextdiagram geplaatstworden. Ret probleem met die aanpak is dat de beschrijvingin het begin wat langdradig en overbodig lijkt; het doel ervanis nog niet helemaal duidelijk. Ben nadeel van het geven vande beschrijving op deze plaats, is dat informatie over de ar­chitectuur van de omgeving verspreid wordt over de tekst.Ook hier blijkt weer dat de event-list niet helemaal voldoendeis, maar uitgebreid moet worden om rekening te houden metde ontvangst van een opdracht van het systeem. Uit het bo­venstaande zou je de conclusie kunnen trekken dat ook hetbeschikbaar komen van een fies een event is. Dit is echtervoor het systeem niet zo, omdat de vulmachine zelf reageertop een dergelijke gebeurtenis door de fies van de band te ha­len. Als de fies arriveert voordat een opdracht beschikbaar iswacht de machine gewoon op de opdracht.

135

Limozuki

VuUnlo

Figuur 6.7: De processen van 'Vul besturing'

Ook hier hebben we dus drie events die dan ook drie pro­cessen opleveren: 'Fles vullen', 'Fles controleren' en 'Bewaakvulsysteem'. De processen met hun exteme signalen zijn infiguur 6.7 weergegeven. We moeten nu weer signalen toevoe­gen om de genoemde functies te realiseren. Voor het doorge­yen van opdrachten van het systeem naar het proces 'Vul be­sturing' voeren we de flow 'VuLopdracht' in. De flow 'Fles_vol'is een onderdeel van 'VuUnfo' en wordt true zodra een fles ge­vuld is. Om het systeem in staat te stellen te bepalen wanneereen gevulde ftes op een van de afvoerbanden gezet kan wor­den is de flow 'Band13_14_vrij' ingevoerd. Meldingen naarhet systeem worden gebundeld met de flow 'VuLmelding' diebestaat uit 'VuLtime_ouLmelding' en 'VuLdefect-Illelding'.'Schak7JLopdracht' tenslotte geeft opdrachten aan het trans­portsysteem om de stand van de schakelaars 7 en 8 te veran­deren. Het nieuwe diagram is in figuur 6.8 gegeven.

136

Limozuki

Figuur 6.8: Ret proces 'Vul besturing'

137

detaillering

Limozuki

Ret proces 'Fles_vullen' voert eigenlijk twee taken uit, hetvullen zelf en het afvoeren van de Bes. Daarnaast is het zodat er twee vulmachines zijn die allebei apart bestuurd moe­ten worden. Voor de overzichtelijkheid van het model is hetgoed om het proces 'Fles_vullen' nog een niveau dieper uit tewerken. Vole voeren nu voor elke vulmachine een proces in datopdrachten van het systeem vertaalt naar opdrachten aan demachine en een proces dat de vulmachines opdracht geeft omeen Bes op een band te zetten zodra de tijd daarvoor rijp is.Dit levert het diagram van figuur 6.9 op. We zien dat op ditdiagram een aantal Bows weer verder uitgesplitst is. 'Fles_vol'bijvoorbeeld is gesplitst in 'FlesLvol' en 'Fles2_vol' en wordtin zijn geheel gekopieerd naar 'Voer..af'. 'Vulbesturing' blijktuit vier verschillende opdrachten te bestaan.De stap die we nu uitgevoerd hebben is niets anders dan eendetaillering van een proces dat we niet in een keer kunnenoverzien. Ret controleren van een Bes en het bewaken vanhet vulsysteem zouden we ook nog uit kunnen werken, maarze zijn zo eenvoudig dat ze ook direkt in een specificatietaalbeschreven kunnen worden.De beslissing om een bepaald proces op een bepaalde manieruit te werken (met een diagram of een tekstuele specificatie)is nogal afhankelijk van omstandigheden en van de persoon­lijke voorkeur van de ontwerper. In het algemeen geldt dateen tekstuele specificatie niet te lang mag zijn (niet meer daneen A4-tje bijvoorbeeld), maar ook niet te ruim interpreteer­baar. \Ve moeten met het model weI aangeven wat de functievan een bepaald proces is. Daarmee wordt bedoeld dat hetinkorten van een tekstuele specificatie tot de A4-grens nietgeoorloofd is als daardoor ruim interpreteerbare statementsnoodzakelijk worden. Vaak is het dan beter om een extralaag in het diagram toe te voegen.

Het transportsysteem

Ret transportsysteem valt uiteen in twee onderdelen: een pro­res voor de schakelaars en een voor de transportbanden. Ret

138

Limozuki

Figuur 6.9: Het proces 'Fles vullen'

139

Opdracht 6.2

Opdracht 6.3

Limozuki

proces voor de schakelaars moet de besturing en de bewakingervan realiseren. We onderscheiden drie soorten schakelaars:

1. De verdeelschakelaars (nummers 1, 2, 3, 4, 6, 7, 8, 9,10 en 12) verdelen de stroom £lessen over twee banden,afhankelijk van een opdracht van het systeem.

2. Schakelaars 5 en 11 voegen twee stromen £lessen samen.Ze geven aan van welke band ze een £les gehaald hebben.

3. Schakelaar 13 voegt ook twee stromen £lessen samen,maar het systeem bepaalt van welke band een £les ge­haald wordt.

De banden moeten gestart en gestopt kunnen worden en destatus ervan moet bewaakt worden.In figuur 6.10 is de verdeling van het proces 'Transport bestu­ring' in de onderdelen 'Schakelaars' en 'Banden' weergegeven.De lezer kan zelf nagaan welke interne signalen zijn toege­voegd. Merk op dat 'Schak7_8_opdracht' en 'Band30_opdracht'eigenlijk twee keer voorkomen: een keer van het systeem eneen keer van de processen 'Vul besturing' respectievelijk 'Eti­ket besturing'. 'Band13_14_vrij' wordt afgesplitst van 'Band_vrij' omdat dit signaal nodig is in 'Vul besturing'.

Werk zelf de processen 'Schakelaars' en 'Banden' uit.

De etiketteermachine

Tenslotte zuBen we de etiketteermachine bekijken. Deze ma­chine brengt een etiket aan op een £les zodra deze voorbijkomt op de transportband. Als geen opdracht beschikbaar isals een £les voorbij komt wordt de transportband gestopt. Alsde voorraa:d etiketten voor een bepaalde drank op is genereerthet proces 'Etiket besturing' een melding zodat het systeem£lessen om kan leiden op de overloopband (band 32).

Werk het proces 'Etiket besturing' uit.

140

Limozuki

Figuur 6.10: Het proces 'Transport besturing'

141

Opdracht 6.4

voorbeeld

Opdracht 6.5

Limozuki

De tweede laag van het DFD

In het dataflowdiagram moeten we de boven beschreven pro­cessen nog aan elkaar knopen. Voer een proces in met alsnaam 'De centrale', dat verantwoordelijk is voor de logistiekekant van het probleem. Knoop dit proces aan de hierbovenbeschreven processen.

6.4.5 De datadictionary

Bij wijze van voorbeeld zullen we hier de definitie van 'VuUnfo'uitwerken:

VulJnfo = [Fles_voll Vul...status I V..fles...status]* Bundeling van de signalen van de vulmachines. *

'VulJnfo' is dus gedefinieerd in termen van 'Fles_vol', 'VuLstatus' en 'V_fles_status', die we vervolgens ook moeten de­finieren:

V _fles_status =['Fles_op_band13_kapot' I 'Fles_op_band13_0K' I'Fles_op_band14_kapot' I 'Fles_op_band14_0K']* Geeft de toestand van de flessen na het vul1en weer *

VuLstatus = ['VuLmachineLdefect' I 'Vul.machineLOK' I'Vul.machine2_defect' I 'Vul.machine2_0K']* Geeft de toestand van de vulmachines weer *

Fles_vol = ['Flesl_vol' I 'Fles2_vol']* Geeft aan dat een fles gevuld is. *

Definieer zelf de rest van de flows in de datadictionary.

6.4.6 De processpecificaties

Processen op het dataflow diagram die niet uitgewerkt wor­den in een diagram op een lager niveau, worden beschrevenmet behulp van processpecificaties. We zullen nu een aantalprocessen van het dataflow diagram specificeren.

142

Ret proces 'Robot en container besturing' heeft de nog nietgedefinieerde processen 'Bewaak containers', 'Bewaak robot'en 'Grijp £les'. Deze processen kunnen als voIgt gespecificeerdworden:

Grijp flesHet vertalen van ZetJles_op_band opdrachtennaar de juiste serie robot commando'sZeLfles_op_band [SoortJles, Bandnummer],Fles_voorraad, Rob_com_uitgevoerd,ContainerJnhoudRobot-commandoContainernummer

Bewaak containersVertaal bet leeg of vol zijn van de vierflessencontainers naar bet op zijn of niet vaneen 600rt fles.Container..status, ContainerJnhoudFles_voorraadContainernummer, SoortJles

P2.1:Doel:

Output:Lokaal:BEGIN

IF Fles_voorraad[SoortJies]='nieLop' THENRobot-commando:= 'Reset'Stuur (Robot-commando)Wacht op (Rob_com_uitgevoerd)Containernummer:=Zoek-eontainernummer(ContainerJnhoud,SoortJies)Robot-commando:=ContainernummerStuur (Robot-commando)Wacbt op (Rob_com_uitgevoerd)Robot-commando:=BandnummerStuur (Robot-commando)Wacht op (Rob_com_uitgevoerd)

Input:Output:Lokaal:BEGIN

DO voor elk ContainernummerSoorLfles:=ContainerJnhoud[Containernummer]Voorraad[SoortJles]:=

Container..status[Containernummer]ENDDO

ENDP2.2:Doel:

Input:

Limozuki 143

Bewaak robotGeeft foutmelding als er problemen met derobot zijnRobot-statusRobot-defect-meldingVorige-robotstatus

Robot-commando:= 'Stop'Stuur (Robot-commando)Wacht op (Rob_com_uitgevoerd)

ELSESoortJies_op-melding:= 'True'

ENDIFENDP2.3:Doel:

Input:Output:Lokaal:BEGIN

IF Vorige-robotstatus=Robot-OK ANDRobot-status= Robot-defect THENRobot-defect-rnelding:='True'

IF Vorige-robotstatus=Robot-defect ANDRobot-status=Robot-OK THENRobot-defect-rnelding:= 'False'

ENDIFVorige-robotstatus:=Robot..status

END

We zien hier weer programmeertaal-achtige constructies diegebruikt worden om de processen te specificeren. Er wordt ge­bruik gemaakt van IF-ELSE-ENDIF en DO-ENDDO. Anderemogelijkheden zijn CASE, WHILE en REPEAT statements.Daarnaast zijn er de logische operaties (AND, OR, NOT) eneen array-notatie voor stores en samengestelde flows. Ten­slotte zijn er nog wat ongedefinieerde zaken als 'Stuur' en'Wacht op'. De uitvoering van dit soort opdrachten is imple­mentatie afhankelijk, maar de betekenis zal duidelijk zijn.

Opdracht 6.6 Werk zelf de rest van de processen uit.

Limozuki 144

Limozuki

6.4.7 Het Object-relatie diagram

Ben object-relatie d~agram is bedoeld om opgeslagen data temodelleren. Ret gaat hier vooral om database toepassingen,voor Limozuki is een dergelijk diagram niet noodzakelijk.

145

se/eeteerprocessoren

seleetiecriteria

Limozuki

6.5 Het implementatiemodel

6.5.1 Het processormodel

Het opstellen van een processormodel bestaat uit het selecte­ren van ren of meer processoren waarmee de functies van hetsysteem uitgevoerd moeten worden, en het verdelen van diefuncties over de gekozen processoren.We zullen nu het vul-gedeelte verder uitwerken door een pro­cessor- een taak- en een modulemodel ervoor op te stellen.Voor het processormodel zijn er een aantal mogelijkheden:

1. Alle processen draaien op dezelfde processor.

2. Alle processen draaien op een aparte processor.

3. Vullen en controleren op dezelfde processor.

4. Vullen en bewaken op dezelfde processor.

5. Controleren en bewaken op dezelfde processor.

Het vulproces bestaat uit twee deelprocessen en dus kunnenwe dit proces nog een keer verdelen. Omdat dit wat te veelvan het goede lijkt zal deze mogelijkheid niet besproken wor­den.Ais we uitgaan van processoren met voldoende capaciteit omde eerste mogelijkheid aan te kunnen zijn alle genoemde op­lossingen realiseerbaar. We moeten nu een oplossing kiezenop grond van bepaalde criteria. Een mogelijk criterium isde onderlinge verbindingen tussen processen. Aangezien ditsoort verbindingen niet voorkomt is er geen technische redenom het gebruik van drie processoren uit te sluiten. Een an­der criterium is van economische aard: drie processoren zijnvaak duurder dan een processor. Een derde criterium is deveiligheid op grond waarvan we zouden kunnen besluiten debewakingsfunctie op een aparte processor te implementeren.Tenslotte kunnen we het aantal kasten of de oppervlakte vanprintplaten tot een minimum beperken door alle processen op

146

parallellisme

Limozuki

dezelfde processor te implementeren.Om de hoeveelheid hardware te beperken, kiezen we voor im­plementatie op een processor. Er hoeft nu niets veranderdte worden aan het conceptueel-model, het kan rechtstreeksgekopieerd worden naar het processormodel.

6.5.2 Ret taakmodel

In onderstaande paragrafen zullen we een aantal taakmodel­len voor het in het vorige hoofdstuk gekozen processormodelopstellen.Als we alle processen toekennen aan dezelfde processor zijner weer vijf mogelijkheden om een taakmodel te maken. Betblijkt dus dat we met de keuze van het processormodel hetprobleem voor ons uit geschoven hebben. Dit is echter niet zoerg; er zijn immers goede redenen op grond waarvan de keuzegemaakt is (goedkoper, minder ruimte).

AIle processen in dezelfde taak

Bet toekennen van aIle processen aan dezelfde taak lijkt ineerste instantie nogal triviaal; alles kopieren en dat was het.Belaas zit er een addertje onder het gras en weI het paral­lellisme. We hebben dan een taak op het laagste niveau vande taak-hierarchie met parallellopende processen erin en datmocht niet volgens de definitie. \Ve kunnen dit probleem op­lossen door een besturing toe te voegen waarmee de processenieder een deel van de tijd geaktiveerd worden.

147

besturingsproces

Limozuki

CJee, (de)aklMler_ /

, I Conlroler8n /

(de\·"'''- Vul. --' - /,-~- , / P1 '\ ,l(de)alcllv8er_Bewaken

,( BeIIuring )/

, /--Figuur 6.11: Taakmodel: alle processen in dezelfde taak

In figuur 6.11 is een oplossing gegeven waarbij een besturings­proces toegevoegd is. Dit proces aktiveert en deaktiveert dedrie dataverwerkende processen. We zouden de zaak nu zoop kunnen zetten dat de drie processen allemaal een deel vande tijd geaktiveerd worden. Dit maakt het toestandsdiagramerg eenvoudig (zie figuur 6.12). Merk op dat hiervoor een vrijgeavanceerd operating system noodzakelijk is. Een oplos­sing waarbij de drie processen achter elkaar uitgevoerd wor­den is echterniet aanvaardbaar, omdat dan niet gegarandeerdkan worden dat het bewakingsproces vaak genoeg uitgevoerdwordt (er is niet gedefinieerd hoe lang bijvoorbeeld het vullenen controleren van een £les zal gaan duren).

148

"Con1rOleren0

"Sew_n°

11 EIewakan

)eil~kSr °Bewak8n°~iveer "VuIlen°

2 Vullen 3I!i!tom

i'kINMr

2~~~ _ "Vullen°

NMr "Controillren°

3 ControIeren

Figuur 6.12: Toesta.ndadiagram voor 1 taak

Limozuki 149

tweede oplossing

Limozuki

Een andere mogelijkheid is gebruik maken van het feit dat hetniet nodig is om tijd toe te kennen aan het 'Fles vullen' en'Fles controleren' proces als er geen vulopdrachten zijn of alser geen fles is die gecontroleerd moet worden. Een gevolg hier­van is dat de besturing moet weten wanneer er een opdrachtis en wanneer deze uitgevoerd is. Dit wordt aangegeven doorde eventflows 'OpdrachLontvangen', 'Vullen..klaar' en 'Con­troleren klaar'. In figuur 6.13 is de oplossing getekend. Alstijdens de uitvoering van een opdracht een volgende binnen­komt zouden opdrachten verloren kunnen gaan. Om dit tevoorkomen is een zogenaamde eventstore toegevoegd. Dit iseen semafoor die gebruikt kan worden om events te onthou­den. Een alternatief is het toevoegen van toestanden in hettoestandsdiagram. Dit leidt tot toestanden met namen als'Vul een fles', 'Vul een fles (er is nog een opdracht)', 'Vul eenfles (er zijn nog twee opdrachten)', enz. Een eventstore kanin zo'n geval de situatie aanzienlijk eenvoudiger maken. Rettoestandsdiagram voor deze oplossing is in figuur 6.14 gege­Yen.

150

Figuur 6.13: Taakmodel, efficientere tijdsbesteding

7 ftel op en peen 0flChChIen

18ewaken

6 TTJdop EN.seen Controle ope!rachtDeakliYeer °Vullen°Akliwer °Bewaken°

2 Vullen 3 ConlroIeren

Limozuki

Figuur 6.14: Toestandsdiagram voor ef6cientere tijdsbeste­ding

151

Limozuki

Vullen en controleren in dezelfde taak

Een tweede mogelijke verdeling in taken is het toekennen van'Fles vullen' en 'Fles controleren' aan de ene taak en 'Bewaakvulsysteem' aan een tweede. Ret model is in figuur 6.15 ge­geven. Met behulp van het besturingsproces 'Vulbesturing'wordt de processortijd tussen de twee taken verdeeld. In dezesituatie kan de uitvoering van een proces in de 'Vullen en con­troleren' taak onderbroken worden door het controleren vande toestand van de vulmachine door de tweede taak. Rier isparallellisme dus weI toegestaan. Een voordeel van deze inde­ling is de grotere overeenkomst met wat je intuitief als functiesvan het vulsysteem ziet: het vullen van een fles met alles watdaarbij llOort en het in de gaten houden van de toestand vande vulmachine. In figuur 6.16 is een toestandsdiagram voorde besturing gegeven, waarbij de 'Vullen en controleren' taakgeen processortijd krijgt als er geen opdrachten zijn. De sta­tements 'Disable "x'" en 'Enable "x'" zijn opdrachten aan hetoperating system waarmee taak "x" verboden respectievelijktoegestaan kan worden.

152

101I Bewaken II II IL _

Figuur 6.15: Taakmodel: vullen en controleren in dezelfdetaak

11 Bewaking

t 2en·

2 Vullln en bew8k8n

1 VuLopdrachtEnable "Vullen~

Figuur 6.16: Toestandsdiagram voor 'Vul..besturing'

Limozuki 153

VuLbeSturing

" " --..-!'-_atgewerd y P1.1 ,~~

- - -y.I1J en control8}" _...Vul time FIes~ -....-. - - .., /

OUl_melciiig /' " ......(de)al<liveer_ /' /' ",,-.

controle /' /'/' /'

/' /'/' /'Controle_atgerond

V_IIes_ /'status /'

Figuur 6.17: Nieuw dataflow diA«f&Dl voor 'Vullen en contr<rleren'

We moeten nu nog wat veranderingen aanbrengen in het data­flowdiagram voor de 'Vullen en controleren' taak, omdat hierintwee processen parallel uitgevoerd worden ('Fles vullen' en'Fles controleren'). In 'Fles vullen' zijn oak weer twee paral­lelle processen getekend, waardoor er eigenlijk sprake is vandrie processen ('Fles controleren', 'Vul' en 'Voer af'). Omsequentiele uitvoering mogelijk te maken moeten we een be­sturingsproces toevoegen. In figuur 6.17 is dit gedaan, in fi­guur 6.18 is de aangepaste uitwerking van het proces 'Flesvullen' gegeven. In figuur 6.19 is het toestandsdiagram vanhet besturingsproces gegeven. Merk op dat de drie processen'Vul', 'Voer af' en 'Fles controleren' a.chter elkaar gea.ktiveerdworden. Een alternatief is om op timesharing basis de proces­sortijd te verdelen.

Limozuki 154

(de)aIcIiwer, Vul -

....... ....\ Fles_algewerd

\\,

(de)aIcIiwerV08I'_aI -

Figuur 6.18: Nieuw dataflow diagram voor 'Fles vul1en'

l1 FIR YUlen

1 Gevu~aIcliveer 'Vul'iveer 'V08I' ar

2 Fles aIYoeren

Fles atoeY08l'drveer 'V08I' ar='Filii controlenl. '

3 FIll llIlfIIroIeren

Limozuki

Figuur 6.19: Toestandsdiagram voor besturing 'Vul en con­trole'

155

Opdracht 6.7

Opdracht 6.8

randvoorwaarden

Limozuki

Drie aparte taken

Ben derde oplossing is het onderbrengen van de drie processenin aparte taken. Deze oplossing heeft als voordeel dat een fiesgecontroleerd kan worden terwijl de volgende gevuld wordt,zodat de doorstroomsnelheid van flessen wordt vergroot.

Geef een model voor de taak (dataflowdiagram) en een toe­standsdiagram voor het besturingsproces dat nodig is voorhet datafiowdiagram.

Twee hoofdtaken met een onderverdeling

De volgende oplossing kombineert de voordelen van intuitieveduidelijkheid (het geval van twee taken) met de efficientie vanhet drie-taken-geval. We definieren twee hoofdtaken, de enevoor het vullen en controleren, de tweede voor het bewaken.De 'Vullen en controleren' taak verdelen we in twee deeltaken('Vultaak' en 'Controleertaak'). Vullen en controleren hoevennu niet meer sequentieel uitgevoerd te worden terwijl ze tochoverzichtelijk opgeborgen zijn in een aparte taak. Het modelis in figuur 6.20 gegeven, het besturingsproces 'Vulsysteembesturing' is uitgewerkt in figuren 6.21

Geef een toestandsdiagram voor'VuLen_controle_besturing' .

De beste oplossing

Wat de beste oplossing is, is afhankelijk van allerlei rand­voorwaarden zoals het maximale aantal taken dat het opera­ting system aankan, het maximale aantal taken dat efficientuitgevoerd kan worden, de gewenste doorstroomsnelheid vanflessen, enz. In het algemeen zal het wenselijk zijn om deoverhead die gepaard gaat met het wisselen van taken zo kleinmogelijk te houden. Dit pleit voor een oplossing met een taak.Helaas is het ook in dit geval noodzakelijk om time-sharing

156

~kingSlaak - - ~

1 03 1

I Bewaken I1 I

I 1I______ J

1------------~Uil---l ~ _,1

1 P1 P2 I 11 I Vullen I I Controlenln I1 I 1 I 1 1

1 I 1 I I I

I L _ _ -I l_ - -' I1 Vuflen_~y ·P1- <fomrolenlnJdaarl

1 f Vul en 1control8} VulIen_

1 \ besturing contn:lleren_ 1_ klaar

J ,,/ - I --ul en controleel' taak _ ~ - _ / P2 '\L: - - - - - - - - - - - .::to- _ f Vulsysteem

" -...... besturing }" Opdrachten \" ,,/" -:.-

" --" ­--vuror-contrOle9rqldrachlen

-r-~-

Controleer / '\VuLqldrachl

/ \.

Figuur 6.20: Taa.kmodel: twee hoofdtaken

1 Bewaken

2 Vul conIroIeer Id8aroL6Ci 'Viii en &imrawr luke

Limozuki

2 BewakenenVuIIlIMlonlrolllren

Figuur 6.21: Toestandsdiagram voor 'Vulsysteem besturing'

157

Limozuki

in te voeren (vanwege de veiligheid), zodat de tijdwinst weerverloren gaat. We kunnen dus net zo goed meteen meer takeninvoeren. Omdat het vullen en het bewaken van het systeemniets met elkaar te maken hebben, lijkt het goed om de pro­cessen in ieder geval in minstens twee taken onder te brengen.Als we dan ook nog als doel hebben de doorstroomsnelheidvan £lessen te maximaliseren, moeten we de 'Vul en controleer'taak in twee deeltaken verdelen, of het hele systeem in drietaken realiseren. Ben argument tegen deze laatste oplossingis dat we dan de intui'tieve indeling kwijt zijn, een voordeel isdat de besturing minder komplex is (een proces minder).

158

specificatie

Limozuki

Bewaking

Figuur 6.22: Ben modulemodel van het bewakingsproces

6.5.3 Het modulemodel

Het laatste onderdeel van het implementatiemodel volgensWard en Mellor is het modulemodel. Elke taak heeft eenmodulemodel waarin aangegeven wordt hoe de processen vande taak in procedures en functies gerealiseerd worden. Hetmodel bestaat uit een structure chart met specificatie van degebruikte functies.We zuBen nu van een aantal van de in de vorige paragraaf ge­geven taakmodellen een modulemodel opstellen, waarbij wezul1en beginnen met de indeling in de twee taken 'Vullen encontroleren' en 'Bewaking', waarbij de eerste taak niet in deel­taken verdeeld is.

Modulemodel voor twee deeltaken

Bij de in figuur 6.15 gegeven taakindeling horen twee modu­lemodellen. Het model voor de bewakingstaak lijkt triviaalomdat daar sprake is van slechts een proces. We zouden kun­nen besluiten om dit proces over te nemen zodat het modelin figuur 6.22 ontstaat. Hierbij hoort nog een specificatie,bijvoorbeeld in gestructureerde taal, waarvoor we die van hetconceptueel-model kunnen gebruiken.

159

RoboC bewaking

l.ees nieuw8loestand

Sluur melding

detailleren

Limozuki

Figuur 6.23: Uitgebreider modulemodel voor het bewakings­proces

Nu is het zo dat we het proces 'Bewaak vulmachine' bestnog verder kunnen detailleren, bijvoorbeeld door het uit tebreiden met processen die de toestand van de machine inle­zen en een proces dat de melding op een output poort zet.Als we dit doen ontstaat figuur 6.23. We zien in deze figuurhoe de module 'Bewaking' twee ondergeschikte modules 'Leesnieuwe toestand' en 'Stuur melding' gekregen heeft. Voor devolledigheid is hieronder de specificatie van de drie modulesgegeven.

MODULE 'Bewaking'Doel: Genereren van de melding 'Vulsysteem defect' als de

het signa.al 'Vul-status' overgaat van 'OK'naar 'Defect'.

Input: Nieuwe_toestandOutput: Vulsysteem_defect-meldingLoka.al: Oude..toestand, MeldingBEGIN

CALL Lees..nieuwe..toestand (Nieuwe_toestand)IF Oude..toestand=Vul_OK AND

Nieuwe..toestand=Vul_defect THENCALL Stuur-IIlelding

ENDIFOude..toestand:=Nieuwe..toestand

END

160

Limozuki

ENDMODULEMODULE'Lees_nieuwe_toestand'

Doel: Inlezen van de toestand van de vulma.chine:start AD conversie, wacht op READY signaal oppoort A,en lees waarde in van poort B

Input: PoortB_waarde, READY..signaalOutput:ADC-startsignaal, Nieuwe_toestandBEGIN

Stuur (ADC-startsignaal, PoortA)WachLop (READY, PoortA)Lees (Nieuwe_toestand, PoortB)

ENDENDMODULEMODULE'Stuur_melding'

Doel: Over het netwerk de melding 'Vulma.chineis defect' versturen

BEGINStuur ('Vulmachine is defect', Netwerkpoort)Wacht op (Acknowledge, Netwerkpoort)

ENDENDMODULE

161

besturingsproces

Limozuki

De structuur van de tweede taak is wat ingewikkelder, maar eris weI meer hulp beschikbaar bij het opstellen van een struc­ture chart. Die hulp bestaat uit het besturingsproces datnoodzakelijk was om het parallellisme uit de taak te halen.We kunnen dit proces zien als de top van de hierarchie metdaaronder de twee processen 'Fles vullen' en 'Fles controle­ren'. 'Fles controleren' kunnen we nu verder detailleren zoalsook voor de bewakingstaak gedaan is. 'Fles vullen' heeft inhet taakmodel twee deelprocessen 'Vul' en 'Voer af', die we alsdeelmodules van 'Fles vullen' kunnen gebruiken. Deze tweemodules kunnen nu ook weer gedetailleerd worden door hettoevoegen van processen die communiceren met de omgeving('Geef opdrachten', 'Geef afvoer opdracht') of wachten op eengebeurtenis ('\Vacht op Fles_vol', 'Wacht op Band_vrij'). Infiguur 6.24 is de structure chart gegeven.

Modulemodel voor twee hoofdtaken

In figuur 6.25 is het modulemodel van de vultaak en de contro­leertaak weergegeven voor het geval van de twee hoofdtakenwaarvan er een onderverdeeld is (taakmodel in figuur 6.20).Dit model ontstaat door dat van figuur 6.24 in twee stukkente verdelen waarbij de top van de hierarchie weggelaten kanworden. Deze top-module wordt eigenlijk vervangen door hetbesturingsproces 'VuLen_controle_besturing' .

162

Vullen encontrolllren

FIes YUlen FIes controleren

Gee! opdrachten

Voeral

Wacht cp band vrij

Lees lies status

Geelalvoercpdracht

Zel schalutlaarstand

Limozuki

Figuur 6.24: Modulemodel voor de tweede taak

163

FIes vulen

Voerllf

Geet opdrachlen Wac:.tlt op FJes_voI Wacht op band Ylij Gee! aIYoeropdracnl

LAeI .._UI

FIls conIroler8ll

Limozuki

Figuur 6.25: Modulemodel voor twee hoofdtaken

164

modellerenbesturingsproces

Limozuki

In de taak 'Vullen en controleren' is nu aIleen een besturings­proces over, dat ook nog gemodelleerd moet worden. We kun­nen dit doen op twee standaardmanieren:

1. Zet het toestandsdiagram om in een tabel die gebruiktwordt door een speciale module voor het bepalen van deuit te voeren module en de volgende toestand.

2. Maak gebruik van een hoofdmodule die afhankelijk vande toestand een andere module aanroept. Deze mo­dule houdt de optredende events in de gaten en stopthet aktieve zodra er een toestandsverandering optreedt.Daarna wordt de controle terug gegeven aan de hoofd­module die de volgende toestand bepaald en de modulevoor die toestand aanroept.

Omdat de eerste manier bijzonder eenvoudig uit te voeren(misschien zelfs te automatiseren) is en ook wijzigingen inaantal toestanden eenvoudig maakt, zullen we er het bestu­ringsproces 'VuLen_controle_besturing' van figuur 6.24 meemodelleren. Ret toestandsdiagram is gegeven in figuur 6.26.We zetten dit diagram om in een tabel met horizontaal deuitgangstoestanden, vertikaal de events en op de kruispuntenin de tabel paren 'volgende toestand/aktie'. Rierbij is aktieeen module die uitgevoerd moet worden (in dit geval wordteen taak enabled of disabled, maar het principe is het zelfde).Tabel 6.1 geeft het resultaat weer.

165

8 Vulen ldaarDisaSie 'VLdi8f1'Sluur'Vul en

c:onlrole&r_Klaai'

2 Vullen

11c1e

Conlrole kIaar-C;;ntro"'f8ren'

Stuur 'Vuf enconlroIeer_KIaai'

3 Conlroleren

4 VuDenenClOI*oiIlen

Limozuki

Figuur 6.26: Toestandsdiagram voor 'VuLen_controle_ bestu­ring'

166

t 1 b t'V 1Tb161 T t dtbla e oes an s a evan u _en_con ro e_ es urm~'

Idle Vullen Controleren Vullen encontroleren

VuL Vullen Vullen Vullen en Vullen enopdracht controleren controleren

Enable "Vullen" Enable "Vullen"

Controle_ Controleren Vullen en Controleren Vullen enopdracht controleren controleren

Enable Enable"Controleren" "Controleren"

Vullen_ Idle Idle Controleren Controlerenklaar Disable "Vullen" Disable "Vullen"

Stuur "Vul_en_controleer klaar"

Controle_ Idle Vullen Idle Vullenklaar Disable Disable

"Controleren" "Controleren"Stuur "Vul_en_

controleer klaar"

Limozuki 167

Limozuki

Om de volgende toestand en de uit te voeren aktie te bepalenkunnen we gebruik maken van onderstaande standaardmo­dule:

MODULE'Doorloop_toestandsdiagram'Lokaal: begin_module, begin_toestand, module, voorwaarde,

toestandBEGIN

module:=begin_moduletoestand:=begin_toestanddo forever

voer-aktie_uit (module)lees_voorwaarde (voorwaarde)module:=volgende...module (voorwaarde, toestand)toestand:=volgende_toestand (voorwaarde, toestand)

enddoENDENDMODULE

In dit geval moeten we het statement 'module:=begin..module'vervangen door 'Disable "Vullen"; Disable "Controleren" '.Voor de begintoestand kunnen we hier 'Idle' invullen. 'Lees_voorwaarde' is een module die wacht op het optreden van eenevent, en dit doorgeeft aan de besturingsmodule via de varia­bele'voorwaarde'. 'Volgende..module' en 'Volgende_toestand'bepalen welke aktie uitgevoerd moet worden, respectievelijkwat de volgende toestand zal zijn met behulp van de tabel.

6.5.4 De rest

Het is een goede oefening om de rest van het systeem uit tewerken, waarbij het beste begonnen kan worden met model­len van de schoonmaak- en afsluitmachines omdat deze sterkeovereenkomsten vertonen met de vulmachines. Tenslotte zoude rest van de machines gemodelleerd kunnen worden. Daar­naast is er nog een centraal deel in het systeem dat zorg draagtvoor het aan elkaar koppelen van de onderdelen. Taken vandit gedeelte zijn onder andere het bijhouden van de plaats van

168

onderhouds­handleidingen

Opdracht 6.1

Opdracht 6.2

Opdracht 6.9

Opdracht 6.4

Limozuki

£lessen in het systeem en de mate waarin bestellingen uitge­voerd zijn.In dit systeem is er van uitgegaan dat de terminals voor deoperator en het opgeven van een bestelling beschikbaar zijn.De programmatuur voor deze terminals is tamelijk complexmaar wordt weI als gegeven beschouwd. In de praktijk zal ookdeze programmatuur geschreven moeten worden, wat ook eenmooi oefen-probleem is.

6.6 Code

Omdat Limozuki een volledig fictief systeem is, is er natuur­lijk ook geen programmacode. Ook hier geldt weer dat wede modellen niet voor niets gemaakt hebben en dat de codegeannoteerd moet worden.

6.7 Handleidingen

Handleidingen zijn er natuurlijk ook niet, maar in werkelijk­heid zijn ze weI van levensbelang. Vooral handleidingen voorhet onderhoud van programmatuur is belangrijk, gezien decomplexiteit van het systeem.

6.8 Antwoorden

De oplossing is getekend in figuur 6.27

De processen 'Schakelaars' en 'Banden' zijn uitgewerkt infiguren 6.28 en 6.29.

Ret proces 'Etiket besturing' is uitgewerkt in figuur 6.30.

Zie figuur 6.31.

169

e..Unto

belturlng -

Limozuki

Figuur 6.27: De uitsebreide eente versie van bet DFD

170

Limozuki

Schak Info

Figuur 6.28: Het pl"OCe8 'Schakelaars'

171

Limozuki

Band info

Figuur 6.29: Het proces 'Banden'

172

Limozuki

Figuur 6.30: Het proces 'Etiket besturing'

173

Limozuki

Elik8tleeUnlo

Elik8tleer_belturing

TenninllUnlo

lctlOClllmalllkJnlo

Figuur 6.31: Uiteindelijke versie van het tweede niveau vanhet DFD

174

Opdracht 6.5

Limozuki

Hieronder voIgt een mogelijke definitie voor de fl.ows vanhet datafl.owdiagram. De definities zijn per proces alfabetischgeordend.

Datadictionary voor 'Robot en container besturing'

Band_nummer = [1 I 2]* Nummer van een band waarop de robot fl.essen kanplaatsen. *

ContainerLinhoud = ['Grote-flessen' I 'Kleine..fl.essen' I'Grote_Cola-fl.essen' I 'KIeine_Cola_fl.essen']

Container2_inhoud = ['Grote-flessen' I 'KIeineJlessen' I'Grote_Cola-fl.essen' I 'KIeine_Cola_fl.essen ']

Container3_inhoud = ['Grote-flessen' I 'KIeineJlessen' I'Grote_Cola-fl.essen' I 'KIeine_Cola-fl.essen']

Container4_inhoud = ['Grote-flessen' I 'Kleine..fl.essen' I'Grote_Cola-fl.essen' I 'KIeine_Cola_fl.essen']

Container_inhoud = Container1jnhoud + Container2_inhoud + Container3jnhoud + Container4jnhoud* Geeft aan wat voor soort fl.essen er in de containerszitten. *

Container_info = Container-status + ContainerJnhoud* Bundeling van signalen van de containers. *

Container_meldingen = Grote_Cola_op-IIlelding + Kleine_Cola-op_melding + Grote.-fl.essen_op-IIlelding + Kleine_fl.essen_op_melding* Meldingen over de toestand van de containers. *

Container_nummer = [1 I 2 I 3 I 4]* Nummer van een van de containers. *

175

Limozuki

Container_status =['ContainerlJeeg' I 'Containerl_vol'] +['Container2Jeeg' I 'Container2_vol'] +['Container3Jeeg' I 'Container3_vol'] +['Container4Jeeg' I 'Container4_vol']'" Geeft aan of een container leeg is of niet. '"

Fles_voorraad = VoorraacLGrote_Cola + Voorraad_Kleine_Cola + VoorraacLGroot + VoorraacLKlein'" Store waarmee de voorraad van een bepaalde soortfles onthouden wordt. '"

Robot-commando = ['Reset' I Container..nummer IBand_nummer I 'Stop']'" De verzameling robot commando's '"

Robot-info = Rob_com..uitgevoerd + Robot..status'" Bundeling van signalen van de robot '"

Robot-melding = ContainerJIleldingen +Robot-defectJIlelding'" Melding van het robot besturingssysteem over de toe­stand van de containers en de robot. '"

Robot-status = ['Robot-OK' I 'Robot-defect']'" Geeft de toestand van de robot aan '"

Voorraad_Grote_Cola = [lOp' I 'Niet-op']'" Voorraad grote Cola-flessen. '"

Voorraad-Kleine_Cola = [lOp' I 'Niet..op']'" Voorraad kleine Cola-flessen. '"

Voorraad_Groot = ['Op' I 'Niet..op']'" Voorraad grote standaard-flessen. '"

Voorraad-Klein = [lOp' I 'Niet..op']'" Voorraad kleine standaard-flessen. '"

176

Limozuki

ZetJles_op_band = ['Grote_ColaJies' I 'GroteJies' I'Kleine_Cola..fies' I 'KleineJies'] + BandJlummer'" Opdracht aan Robot besturingssysteem om een soortfies op een bepaalde band te plaatsen. '"

Containers_vol, Grote...Cola..op_melding,GroteJiessen_op-lIlel­ding, Kleine_Cola..op_melding, KleineJiessen_op-lIleldingen Rob_coITLuitgevoerd zijn variabelen die de waarden trueen false aan kunnen nemen.

Datadictionary voor Vul besturing

Band_13_14_vrij = Bandl3_vrij + Bandl4_vrij'" Geeft aan of banden 13 en 14 vrij zijn. 'BandX_vrij'gedefinieerd bij transportsysteem.•

Fles_vol = ['Flesl_vol' I 'Fles2_vol']'" Geeft aan dat een fies gevuld is.•

Schak7_8_opdracht = Schak7_opdracht +Schak8_opdracht• Opdrachten aan het transportsysteem om de standvan schakelaars 7 en 8 te veranderen. 'SchakX_opdracht'gedefinieerd bij transportsysteem.•

V Jles_op_band = ['VJies_op_bandI3' I 'VJies_op_bandI4']• Signaal waarmee een vulmachine opdracht gegevenkan worden om een fl.es op een afvoerband te zetten.

•V _fles_status -

['Fles_op_bandI3_kapot' I 'Fles..op_bandI3_0K' I'Fles_op_bandI4_kapot' I 'Fles..op_bandI4_0K']• Geeft de toestand van de fl.essen na het vullen weer.

V _vulLcom = ['Cola' I 'Cassis' I '7_Up']• Soort drank waarmee vulmachine 1 een fies moet vul­len.•

177

Limozuki

V_vuI2_com = ['Cola' I 'Cassis' I '7_Up']* Soort drank waarmee vulmachine 2 een fles moet vul­len. *

VuLaan_uit = ['VulLaan' I 'VulLuit' I'VuI2-aan' I 'Vu12_uit']* Signalen waarmee de vulmachines aan- en uitgescha­keld kunnen worden. *

VuLbesturing = [VuLaaILuit I V_vulLcom I V_vuI2_com IV_fles_op_band]* Stuursignalen voor de vulmachines. *

VuLdefecLmelding = ['VulLdefecLmelding' I'VuI2_defect.-melding']* Defectmeldingen van de vulbesturing. *

VuUnfo = [Fles_voll Vul..status I V..fies..status]* Bundeling van de signalen van de vulmachines. *

VuLmelding = [VuLtime_ouLmelding IVuLdefecLmelding]* Meldingen van de vulbesturing naar het systeem. *

VuLopdracht = [VullJnet I Vul2Jnet I Vul-aan_uit]* Opdrachten van het systeem aan de vulbesturing. *

Vul....status = ['Vu1JnachineLdefect' I 'VulJnachineLOK' I'VuIJnachine2_defect' I 'VulJnachine2_0K']* Geeft de toestand van de vulmachines weer *

VuLtime_ouLmelding = 'Time_ouLLmelding' I'Time_ouL2_melding']* Time-out meldingen van de vulbesturing. *

VulLmet = ['Cola' I 'Cassis' I '7_Up']* Vulopdracht voor de eerste vulmachine. *

Vul2-lT1et = ['Cola' I 'Cassis' I '7_Up']* Vulopdracht voor de tweede vulmachine. *

178

Limozuki

Datadictionary voor Transport besturing

Band_best = BandLbest + ... + Band32_best* Stuursignaal van de transportbesturing aan het trans­portsysteem. *

Band_info = Band_status + Band_vrij* Informatie van het transportsysteem aan de transport­besturing over de toestand van de banden. *

BandJIlelding = BandLmelding + ... + Band32-Illelding* Melding van de transportbesturing aan het systeemover de toestand van de banden. *

Band_opdrachten = BandLopdracht + ... +Band32_opdracht* Opdrachten van het systeem aan de transportbestu­rmg. *

Band_status = BandLstatus + ... + Band32-status* Toestand van de transportbanden. *

Band_vrij = BandLvrij + ... + Band32_vrij* True als een band vrij is. *

BandLbest = ['Start' I 'Stop']* Stuursignaal voor band 1. *

Band32_best = ['Start' I 'Stop']* Stuursignaal voor band 32. *

BandLmelding = ['Band_vastgelopen' I 'Band_OK']* Melding over band 1.*

Band32_melding = ['Band_vastgelopen' I 'Band_OK']* Melding over band 32.*

179

Limozuki

BandLopdracht = ['Start-band' I 'Stop_band']* Opdracht voor band 1. *

Band32_opdracht = ['Start-band' I 'Stop_band']* Opdracht voor band 32. *

BandLstatus = ['BandJoopt' I 'Band..gestopt' I'Band_vastgelopen']* Informatie over band 1. *

Band32_status = ['BandJoopt' I 'Band_gestopt' I'Band_vastgelopen']* Informatie over band 32 *

Fles_gearriveerd =Fles_op_3 + ... + Fles_op_32* True als er een fles op een band bij een schakelaaraangekomen is. Gedefinieerd voor banden 3-6, 9, 10,13, 14, 21-24, 28, 29,31 en 32. *

Fles_van_band_gehaald = ['Band9' I 'Band10'] +['Band23' I 'Band28'] +['Band29' I 'Band32']* Geeft aan van welke band een schakelaar (nummers 5,11 en 13) een fles gehaald heeft. *

Overloop_uit = ['True' I 'False']* Store waarmee aangegeven wordt of band32 aan of uitis. *

Schak_best = SchakLbest + ... + Schak13_best* Besturingssignalen voor de schakelaars 1-4, 6-10, 12en 13. *

Schak-info = Schak..status + Fles..gearriveerd* Informatie van de schakelaars aan de transportbestu­rmg.*

180

Limozuki

Schak_melding = SchakLmelding + ... +Schak13JIlelding* Melding van de transportbesturing aan het systeemover de toestand van de schakelaars. *

Schak-opdrachten = SchakLopdracht + ... +Schakl3_opdracht* Opdrachten van het systeem aan de transportbestu­ring voor de schakelaars 1-4, 6-10, 12 en 13. *

Schak_status = SchakLstatus + ... + Schakl3-status* Toestand van de schakelaars. *

SchakLbest = ['SchakJinks' I 'Schak-rechts']* Besturing voor schakelaar 1. *

Schak13_best = ['SchakJinks' I 'Schak-rechts']* Besturing voor schakelaar 13. *

SchakLmelding = ['Schak_vastgelopen' I 'Schak_OK']* Melding over schakelaar 1. *

Schak13_melding = ['Schak_vastgelopen' I 'Schak_OK']* Melding over schakelaar 13. *

SchakLopdracht = ['SchakJinks' I 'Schak-rechts']* Opdracht aan besturing voor schakelaar 1. *

Schak13_opdracht = ['SchakJinks' I 'Schak-rechts']* Opdracht aan besturing voor schakelaar 13. *

SchakLstatus = ['Schak..vastgelopen' I 'Schak_OK']* Informatie over schakelaar 1. *

181

Limozuki

Schak13-status = ['Schak_vastgelopen' I 'Schak_OK']* Informatie over schakelaar 13. *

Transport_besturing = Schak_best + Band_best* Bundeling van stuursignalen voor de schakelaars entransportbanden. *

Transport-info = SchakJnfo + BandJnfo* Informatie van het transportsysteem over de toestandvan de schakelaars en banden. *

Transport-melding = Schak..rnelding + Band..rnelding* Melding van de transportbesturing aan het systeem.

*Transport-opdrachten = Schak..opdrachten +

Band_opdrachten* Opdrachten van het systeem aan de transportbestu­ring. *

BandJs_vrij, BandLvrij, ... Band32_vrij en Fles_op_1 ...Fles_op_32 kunnen de waarden True of False aannemen.

Datadictionary voor Etiket besturing

Cassis_etiketten_voorraad = [ lOp' I 'NieLop']

Cola_etiketten_Voorraad = [lOp' I 'Niet..op']

Etiket-info = Cola-etiketten_op + Cassis_etiketten..op +Up_etiketten..op* Geeft aan of er nog etiketten voor een bepaald drankZlJn. *

Etiket-melding = Etiketmachine..defect..rnelding + Etiket­ten_voorraad-melding* Meldingen over de toestand van de etiketteermachineen de voorraad etiketten. *

182

Limozuki

EtikeLopdracht = ['Cola_etiket' I'Cassis_etiket' I'Up_etiket' l'Etiket..a.an' l'EtikeLuit']* Verzameling opdrachten aan de etiketteer machine. *

EtikeLstatus = ['EtikeLOK' l'EtikeLdefect']* Geeft de toestand van de etiketteermachine aan. *

Etiketteer_besturing = ['Cola_etiket' I'Cassis_etiket' I'Up_etiket' l'Etiket..a.an' l'EtikeLuit']* Opdrachten aan etiketteermachine. *

Etiketteer-info = Etiket..a.angebracht + Etiket.status +Etiketjnfo + Stop_band* Bundeling van signalen van de etiketteermachine. *

Etiketten_aangevuld = Cola..etiketten...aangevuld + Cas­sis_etiketten..a.angevuld + Up_etiketten...aangevuld* Geeft aan dat bepaalde soort etiketten weer aangevuldIS. *

Etiketten_vo orraad.-melding ­['Cola..etiketten_op_melding' I'Cassis_etiketten_op_melding'I 'Up_etiketten_op_melding']* Bundeling van meldingen over de voorraad etiketten.

*Up_etiketten_voorraad = [lOp' I'NieLop']

Cassis_etiketten_aangevuld, Cassis_etiketten-Op, Cassis_etiket­ten_op_melding, Cola..etiketten..a.angevuld, Cola...etiketten_op,Cola...etiketten-Op_melding, Etiket...aangebracht, Etiketmachi­ne_defect.melding, Stop_band, Up_etiketten..a.angevuld, Up_e­tiketten-Op en Up_etiketten_op_melding zijn variabelen die dewaarden true en false aan kunnen nemen.

183

Opdracht 6.6

Limozuki

Hieronder volgen specificaties voor de processen van Limo­zuki.

184

Bewaak bandenGenereren van bandmeldingen als een band vastlooptBand_statusBand_meldingVorige..status, Bandnummer

Band besturingAls het systeem opdracht geeft en band te stoppen of te startenmoet een signaal aan de betreffende band gegeven worden. Als deoverloopband (band 32) gestart of gestopt moet worden moet ook de inhoudvan de store 'Overloop_uit' aangepast worden.Band_opdrachtBand_best, Overloop_uit

P4.2.2:Doel:

Input:Output:BEGIN

DO voor banden 1-31IF Band_opdracht[Bandnummer] ontvangen THEN

IF Band_opdracht[Bandnummer]='StarLband' THENBand_best[Bandnummer]:='Start'

ELSEBand_best[Bandnummer]:='Stop'

ENDIFENDIF

ENDDOIF Band_opdracht[32] ontvangen THEN

IF Band_opdracht[32]='StarLband' THENBand_best[32]:='Start'Overloop_uit:='False'

ELSEBand_best[32]:='Stop'Overloop_uit:= 'True'

ENDIFENDIF

ENDP4.2.1:Doel:Input:Output:Lokaal:BEGIN

DO Voor aile bandenIF Band_status[Bandnummer]='Band..vastgelopen'

ANDVorige..status[Bandnummer]:I:'Band_vastgelopen'

THENBand_melding[Bandnummer]:= 'Band_vastgelopen'

ELSEIF Band_status[Bandnummer]:I:'Band..vastgelopen' AND

Vorige..status[Bandnummer]='Band_vastgelopen' THENBand-IDelding[Bandnummer]:='Band_OK'

ENDIFENDIF

Limozuki 185

Bewaak etiket machineGeeft foutmelding als er problemen zijn met de etiketteermachine en stopt de aanvoerband als de machine daarom vraagtEtiket..status, Stop_bandEtiketmachine_defect-melding, Band30_bestVorige_etiketstatus

Input:Output:Lokaal:BEGIN

IF Vorige_etiketstatus=IEtiket-OK' AND Etiket..status=IEtiket-defect' THENEtiketmachine_defectJDelding:=ITrue'

ENDIFIF Stop_band THEN

Band30_best:=IStop'ENDIF

ENDP3.1: Bewaak etikettenvoorraadDoel: Bijhouden van de voorraad etiketten voor elke fles en

genereren van etiketten_aangevuld signaalEtiketJnfoEtiketteILvoorraad, Etiketten..aangevuld

Input:Output:BEGIN

IF Cola_etiketten-Op=ITrue' THENVoorraad[Cola-etiketten]:=IOp'

ELSEIF Voorraad[Cola..etiketten]=IOp' AND Cola_etiketteILOp='False' THEN

Cola_etiketten...aangevuld:='True'Voorraad[Cola..etiketten]:='Niet op'

ENDIFENDIFIF Cassis_etiketten_op='True' THEN

Voorraad[Cassis_etiketten]:= lOp'

Input:Output:Lokaal:BEGIN

DO voor elk ContainernummerSoortJies:=ContainerJnhoud[Containernummer]Voorraad[SoortJies]:=Container..status[Containernummer]

ENDDOENDP3.2:Doel:

Vorige..status[Bandnummer]:=Band..status[Bandnummer]ENDDO

ENDP2.1: Bewaak containersDoel: Vertaal het leeg of vol zijn van de vier flessencontainers naar

het op zijn of niet van een soort fles.Container..status, ContainerinhoudFles_voorraadContainernummer, SoortJies

Limozuki 186

Bewaak schakelaarsgenereren van foutmeldingen als er een schakelaar vastloopt.Schak...statusSchak-lIleldingOude-schak..status, Schak-nummer

ELSEIF Voorraad[Cassis..etiketten]:'Op' AND Cassis_etiketten.np:'False' THEN

Cassis_etiketten...a.angevuld:: 'True'Voorraad[Cassis..etiketten]::'Niet op'

ENDIFENDIFIF Up_etiketten_op:'True' THEN

Voorraad[Up_etiketten]::'Op'ELSE

IF Voorraad[Up_etiketten]:'Op' AND Up_etiketteILop:'False' THENUp_etiketten..aangevuld:: 'True'Voorraad[Up_etiketten]::'Niet op'

ENDIFENDIF

ENDP2.3: Bewaak robotDoel: Geeft foutmelding als er problemen met de robot zijnInput: Robot-statusOutput: RoboLdefect-meldingLokaa1: Vorige-robotstatusBEGIN

IF Vorige-robotstatus=Robot-OK AND Robot-status=Robot-defect THENRobot-defect-melding:= 'True'

IF Vorige-robotstatus=RoboLdefect AND Robot-status:Robot-OK THENRobot-defect-melding:= 'False'

ENDIFVorige-robotstatus:: Robot...status

ENDP4.1.6:Doel:Input:Output:Lokaa1:BEGIN

DO voor alle BchakelaarsIF Oude-schak..status[SchalulUmmer]:'Schak-OK' AND

Schak-status[Schak-nummer]:'Schak-vastgelopen'THENSchak-lIlelding[Schak-nummer]:: 'Schaksastgelopen'

ELSEIF Oude-schak..status[Schak-nummer]:'Schak_vastgelopen' ANDSchak-status[Schak-nummer]='Schak-OK' THEN

Schak-lIlelding[Schak-nummer]::'Schak_OK'ENDIF

ENDIFENDDO

Limozuki 187

Fles controlerenZet de stand van schakelaars 7 en 8 afhankelijk van de toestandvan de fiessen op band 13 en 14

Output:BEGIN

IF Etiket-opdracht({'Etiket..aan', 'Etiket_uit'} THENEtiketteer_besturing: =Etiket-opdracht

ELSEIF EtiketteILvoorraad[Etiket-opdracht]='Op' THEN

Etiketten-voorraad..melding:=Etiket..opdracht..op_meldingELSE

Etiketteer_besturing:=Etiket..opdrachtWacht op (Etiket..aangebracht)

ENDIFENDIF

ENDP1.2:Doel:

ENDP1.3: Bewaak vulsysteemDoel: genereren van de melding 'Vulsysteem defect' als

het signaal Vul..status overgaat van 'VuLOK' naar 'VuLdefect'Vul..statusVuLdefect-meldingOude..status_l, Oude_status-2

Input:Ouput:Lokaal:BEGIN

IF Oude..status_l='OK' AND Vul..status='Vul..machineLdefect' THENVul_defect_melding:= 'Vul_Ldefect-melding'Oude..status_l:='Defect'

ELSEIF Oude..status_l='Defect' AND Vul_status='Vul..machineLOK' THEN

Oude..status_l:='OK'ENDIF

ENDIFIF Oude..status_2='OK' AND Vul..status='Vul..macrune2_defect' THEN

VuLdefect-melding:= 'Vul-2_defect-melding'Oude..status_2:=Vul..status

ELSEIF Oude..status_2='Defect' AND Vul..status='Vul..machine2_0K' THEN

Oude_status_2:='OK'ENDIF

ENDIFENDP3.3: EtiketteerDoel: Het aanbrengen van een etiket op een fiesInput: Etiket-opdracht, Etiket-aangebracht,

EtiketteILvoorraadEtiketteILvoorraad..melding, Etiketteer_besturing

Limozuki 188

V-fies_statusSchak7_8_opdracht

Samenvoeg sehakelaars (autom.)Samenvoegen van twee fiesstromen, genereren van melding dieaangeeft van welke band een fies gehaald is.Fles_op_9, Fles..op_10, Fles_op_23, Fles_op_28SchaL5_1Lbest, Fles_van_gehaald

Grijp flesHet vertalen van Zet-fies_op_band opdrachten naarde juiste serie robot commando'sZet-fies_op_band [Soort..fles, Bandnummer],Fles_voorraad, Rob_com_uitgevoerd, ContainerJnhoudRobot-commandoContainernummer

Input:Output:

Output:Lokaal:BEGIN

IF Fles_voorra.acl[Soort..fles]='niet-op' THENRobot-commando:='Reset'Stuur (Robot-commando)Wacht op (Rob_com_uitgevoerd)Containernummer:=Zoek_containernummer( ContainerJnhoud ,Soort-fies)Robot-commando:=ContainernummerStuur (Robot-commando)Wacht op (Rob_com_uitgevoerd)Robot-commando:=BandnummerStuur (Robot-commando)Wacht op (Rob_com_uitgevoerd)Robot-commando:='Stop'Stuur (Robot-commando)Wacht op (Rob_com_uitgevoerd)

ELSESoort-fies_op_melding:='True'

ENDIFENDP4.1.4:Doel:

Input:

Input:Output:BEGIN

DOCASE V-fies_statusCASE 'Fles_op_13Jtapot':

Schak7_opdracht:='SchaUinks'CASE 'Fles_op_13Jieel':

Schak7_opdracht:='Schaluechts'CASE 'Fles_op_14Jtapot':

Schak8_opdracht:= 'SchaUinks'CASE 'Fles_op_14-heel':

Schak8_opdracht:= 'Schak..rechts'ENDCASE

ENDP2.2:Doel:

Limozuki 189

Verdeel schakelaarsAls er een fles bij een van de schakelaars aankomt,geeft dit proces afhankelijk van een systeemopdrachteen schakelaarstand door aan het transportsysteem.Schak_opdracht, Fles~earriveerdSchak_best, X

Samenvoeg schakelaars (gest.)Ais er een fies bij schakelaar 13 aankomt,geeft dit proces afhankelijk van het bandnummer en de waarde vanOverloop_uit een schakelaarstand door aan het transportsysteem.Het proces genereert een signaal dat aangeeft van welke band eenfies gehaald heeft.Overloop_uit, Fles_op_32, Fles_op_29Schak13_best, Fles_van_band_gehaald

Input:Output:

Input:Output:BEGIN

IF Overloop_uit='False' AND Fles_op_32 THENSchakI3_best:='SchakJinks'Fles_van_band_gehaald:='Band32'

ELSEIF Fles_op_29 THEN

SchakI3_best:='Schak-rechts'Fles_van_band~ehaald:='Band29'

ENDIFENDIF

ENDP4.1.3:Doel:

BEGINIF Fles_op_9 THEN

Schak5_best:='Schak..rechts'Fles_van_band_gehaald:='Band9'ELSEIF Fles_op_l0 THEN

Schak5_best:= 'SchakJinks'Fles_van_band~ehaald:='Bandl0'

ENDIFENDIFIF Fles_op_28 THEN

SchakILbest:='Schak..rechts'Fles_van_band_gehaald:='Band28'ELSEIF Fles_op_23 THEN

Schak1Lbest :='SchakJinks'Fles_van_band_gehaald:='Band23'

ENDIFENDIF

ENDP4.1.5:Doel:

Limozuki 190

Voer afWacht tot een band vrij en een ties vol is enzet dan de ties op de bandFles_vol, Band13_14_vrijV..fl.es_op_band

Input:Output:BEGIN

Wacht op Vul2-Illet ontvangenV_vul_com:=Vul2-IlletStart (VuLTimer)Wacht op (Vul_time_out...2 OR 'Fles2_vol')IF VuLtime_ouL2 THEN

Vul_time_out-Illelding:='Time-Out...2-Illelding'ENDIF

END

Input:Output:BEGIN

Wacht op Vul1-Il1et ontvangenV_vulLcom:=Vull-Il1etStart (Vul_Timer)Wacht op (VuLtime_ouL1 OR 'FlesLvol')IF Vul_time_ouL1 THEN

VuLtime_out-Il1elding:= 'Time_ouL1-Il1elding'ENDIF

END Pl.l.3: Vu12Doel: \Vacht op een Vu12-Il1et commando, vul de fies en genereer time-out

melding als het te lang duurt (machine 2)Vul2-Il1et, Fles2_volVul_time_ouLmelding, V_vul2_com

BEGINWacht op (Fles-gearriveerd[X] ontvangen AND SchalLopdracht[X] ontvangen)Schalcbest[X]:=Schak_opdracht[X]

ENDP1.1.2:Doel:

Input:Output:BEGIN

IF Fles_vol='FlesLvol' AND Band13_vrij THENV..fl.es_op_band:='V..fl.es_op_band_13'

ENDIFIF Fles_vol='Fles2_vol' AND Band14_vrij THEN

V..fl.es_op_band:='V..fl.es_op_band_14'ENDIF

ENDPl.l.!: VullDoel: Wacht op een Vull-Il1et commando, vul de fles en genereer time-out

melding als het te lang duurt (machine 1)Vul1-Il1et, FlesLvolVul_time_out-Il1elding, V_vuLLcom

Limozuki 191

Opdracht 6.7

Opdracht 6.8·

Limozuki

Figuur 6.32: Taakmodel: drie taken

In figuur 6.32 is een mogelijk dataflowdiagram getekend.Welke taak in uitvoering is wordt bepaald door bet besturings­proces waarvan in figuur 6.33 een toestandsdiagram getekendIS.

In figuur 6.34 is een toestandsdiagram voor'VuLen..controle_besturing' gegeven.

192

1 Bewaken

2 Bewaken en Vullen

Conlrole ldaar"Conlroleren"

3 BewakenenconIroIlIren

oConlrole ldaarblSaDi8

"Controleren"

.. Bewaken. wlen enoonlI'CMIrWI

Vulen ldaarIfliSlir"VUlI8n"

Limozuki

Figuur 6.33: Toestandadiagram voor 3 taken

193

111..

8 Vulen klaarDisable 'vJI8n'51uur 'Vul en

controleer_KIaaI'

2 VuHen

6 Conlrole klan

3 Conlroleren

" VullenenconIr'OIeren

Limozuki

Figuur 6.34: Toestandadiagam voor 'VuLen_controle_ bestu­ring'

194

Associatie

Hoofdstuk 7

Referentielijst

7.1 Inleiding

In dit hoofdstuk wordt een lijst gegeven van termen en tech­nieken die gebruikt worden in het software lifecycle modelSQS [Hammer, 1990] en in de analyse- en ontwerpmethodenvan Yourdon [Yourdon, 1989] en Ward/Mellor [Mellor, 1986].De lijst van termen is een alfabetische opsomming van ailetermen, met per definitie een korte uitleg en een aantal ver­wijzingen. Elke definitie ziet er als voIgt uit:

Definitie UitlegZie ook:···De lijst van technieken beschrijft een aantal hulpmiddelen diebruikbaar zijn bij de analyse- en ontwerpmethoden.

7.2 Lijst van termen

Associatie Associaties komen voor in het object-relatie dia­gram. Een associatie geeft een relatie weer waarover informa­tie bewaard moet worden. Een normale relatie geeft nietsanders weer dan dat er een verband is tussen twee of meerobjecttypen; er is geen mogelijkheid om extra informatie over

195

klant

artikel

klant

werkwoord wordt&eIf.t6ndis naamwoord •

aaDkoop

artikel

Beslissingstabe1

Referentielijst

Figuur 7.1: Een relatie wordt omgezet in een assoeiatie

de relatie op te slaan. Een assoeiatie biedt deze mogelijk­heid weI door van de relatie een objecttype te maken. Benvoorbeeld is de relatie 'koopt' links in figuur 7.1. Als we in­formatie over een aankoop willen bewaren (de datum en hetbedrag bijvoorbeeld), kunnen we 'koopt' ornzetten in een as­soeiatie 'aankoop', weergegeven reehts in dezelfde figuur. Derelatie-ruit is nu leeg en de relatie zelf is veranderd in een zelf­standig naamwoord ('aankoop') dat in een reehthoek onderde relatie-ruit gesehreven wordt. Merk op dat 'klant' en 'arti­kel' onafhankelijk van 'aankoop' kunnen bestaan; ook zonderaankopen kan er sprake zijn van klanten en artikelen. Zon­der klanten en artikelen is er eehter geen aankoop mogelijk.Een assoeiatie bestaat dus aIleen in eombinatie met andereobjeettypen. Zie ook: object-relatie diagram

Beslissingstabel Met behulp van beslissingstabellen kaneen proees van het DFD gespecifieeerd worden. Een beslis­singstabel is nuttig als er versehillende akties ondernomenmoeten worden afhankelijk van een groot aantal combinatiesvan inputs. De tabellen zijn als voIgt opgebouwd:In de linkerkolom staan alle voorwaarden (uitspraken over eeninput) die van toepassing zijn onder elkaar. Geseheiden door

196

Besturingsftow

Referentielijst

Tabel 7 1 Beslissm.e:stabel voor een medicijnprobleemLeeftijd>21 Ja Ja Ja Ja Nee Nee Nee NeeGeslacht M M V V M M V VGewicht>150 Ja Nee Ja Nee Ja Nee Ja Nee

Medicijn1 X X XMedicijn2 X XMedicijn3 X X XGeen Medicijn X X

een dubbele lijn volgen daaronder alle mogelijke akties. Voorelke mogelijke combinatie van voorwaarden is er een kolomin de tabel. In elke kolom staat een kruisje bij de akties dieuitgevoerd moeten worden als de combinatie van voorwaar­den die voor die kolom geldt 'waar' is. Ret is dus zo datde voorwaarde binair moet zijn. Een voorbeeld is gegevenin tabel 7.1. Een compacter alternatief is het onder elkaarschrijven van aIle te ondernemen akties met horizontaal aIlevoorwaarden die van toepassing zijn. Op elke rij komt nu eenaantal kruisjes die weergeven aan welke voorwaarde voldaanmoet zijn om de bijbehorende aktie uit te mogen voeren. Alseen aktie bij meer dan een combinatie van inputs op kan tre­den zijn er voor die aktie ook meer regels in de tabel nodig.Een nadeel is dat de gebruiker niet gedwongen wordt om overaIle mogelijke combinaties van inputs na te denken. Een na­deel van de Yourdon methode is dat de omvang van de tabelnogal snel uit de hand loopt, omdat het aantal mogelijke com­binaties exponentieel toeneemt met het aantal voorwaarden.Zie ook: dataflowdiagram, gestructureerde taal, pre­en postcondities, proces, processpecificatie

Besturingsflow Een besturingsflow is een speciale binairedataflow, die gebruikt wordt om dataprocessen te aktiverenof te deaktiveren. Besturingsflows komen vooral voor op hettaakniveau van het implementatiemodel en in mindere mateop het dataflowdiagram. Ze worden weergegeven door gestip­pelde pijlen. Een besturingsflow kan alleen door een bestu-

197

Besturingsproces

Call

Code

Referentielijst

ringsproces gegenereerd worden. Een synoniem voor bestu­ringsfl.ow is prompt. Ret verschil tussen een eventfl.ow en eenbesturingsfl.ow is dat de eerste niet gebruikt kan worden omeen proces te aktiveren of te deaktiveren.Zie ook: besturingsproces, dataflow, dataproces, im­plementatiemodel, taakmodel

Besturingsproces Een besturingsproces is een speciaalproces dat aIleen eventflows als inputs en outputs heeft. Retheeft als doel de akties van dataprocessen te coordineren.Ret wordt weergegeven door een gestippelde cirkel en komtmeestal voor in het implementatiemodel op het taakniveauals parallel werkende processen in een bepaalde volgorde uit­gevoerd moeten worden. Ook op het datafl.owdiagram uithet conceptueel-model kunnen besturingsprocessen voorko­men, maar dit zal minder vaak het geval zijn. Strikt genomenkunnen de taken van een besturingsproces ook overgenomenworden door een dataproces, een voordeel van het maken vanhet onderscheid is dat duidelijk gemaakt wordt waar de be­sturing van een onderdeel van het systeem zich bevindt. Ditgeeft voordelen bij het afl.eiden van het implementatiemodel(zie ook paragraaf 'Technieken'). Een besturingsproces wordtgemodelleerd met behulp van een toestandsdiagram.Zie ook: dataproces, eventflow, implementatiemodel,toestandsdiagram

Call Een call is een onderdeel van structure charts waarmeeaangegeven wordt dat een module gebruik maakt van een an­dere module. Calls worden weergegeven door pijlen die vande aanroepende module naar de aangeroepen module wijzen.Zie ook: module, structure chart

Code Het produceren van programmacode is een van defasen van het lifecycle model SQS. Er wordt een documentgeproduceerd waarin de code van alle modules te vinden ismet annotaties om het geheel te verduidelijken.

198

Conceptueel­model

Conceptueel­model(Yourdon)

Referentielijst

Zie ook: SQS

Conceptueel-model Ben conceptueel-model is bedoeld ominzicht te verkrijgen in de functionaliteit van het systeem. Vol­gens de definitie in [Hammer, 1990] is het conceptueel-modeleen abstract systeem waarvoor geldt dat elke materialiseringof implementatie voldoet aan de eisen. Het dient om:

• de existentie aan te tonen van een systeem dat aan deeisen voldoet en

• als formele specificatie voor het implementatiemodel

Het conceptueel-modellaat zien:

1. welke functies het systeem vervult,

2. welke inputs daarvoor nodig zijn en welke outputs ge­produceerd worden (de interaktie met de omgeving),

3. welke deeltaken uitgevoerd moeten worden om de totalesysteemfunctie te verwezenlijken,

4. welke data binnen het systeem getransporteerd en op-geslagen wordt.

Voor het opstellen van een conceptueel-model is een grootaantal methoden ontwikkeld. Er zijn zowel wiskundige alsgrafische of zuiver tekstuele methoden, en dan ook nog combi­naties van die drie. Een vrij eenvoudig te gebruiken methode,geschikt voor real-time systemen is die van Yourdon.Zie ook: conceptueel-model (Yourdon)

Conceptueel-model (Yourdon) Het conceptueel-modelvolgens Yourdon bestaat uit de volgende onderdelen

• een model van de omgeving van het systeem opgebouwduit

- een beschrijving van het doel van het systeem

199

Contextdiagram

Referentielijst

- een contextdiagram

- een event-list

• een model van het gedrag van het systeem opgebouwduit

- een dataflowdiagram

- een datadictionary

- processpecificaties

- een object-relatie diagram

Zie ook: conceptueel-model, contextdiagram, data­flowdiagram, datadictionary, doelbeschrijving, event­list, object-relatie diagram, processpecificatie

Contextdiagram Ret contextdiagram beschrijft:

• mensen, organisaties en systemen waarmee het systeemcommuniceert

• data die het systeem van de buitenwereld krijgt of ernaartoe stuurt

• opgeslagen data die het systeem samen met de buiten­wereld gebruikt

• de grens tussen het systeem en het heelal.

Ret diagram bestaat uit een proces met als naam de naamvan het te ontwerpen systeem, terminators die weergeven doorwelke objecten uit de omgeving het systeem communiceert enflows die aangegeven welke data het systeem met de omge­ving uitwisselt. Ret contextdiagram vormt het bovenste ni­veau van het dataflowdiagram. Ret is een onderdeel van hetconceptueel-model.Zie ook: conceptueel-model, dataflow, dataflowdia­gram, eventflow, proces, terminator

200

Datadietionary

Dataflow

Referentielijst

Datadictionary AIle flows en stores die op het dataflow­diagram voorkomen moeten in de datadictionary gedefinieerdworden. Een definitie in de datadictionary bestaat uit denaam van het gedefinieerde object gevolgd door een '='-tekenen de definitie zelf. Deze laaste kan bestaan uit:

1. +: en

2. (tekst): het deelobject tekst is optioneel

3. ondergrens{ tekst} bovengrens: nul of meer keer deelob­ject tekst, ondergrens en bovengrens zijn optioneel

4. [alternatieven]: kies ren van de alternatieven tussen devierkante haken

5. I: scheidingsteken voor alternatieven in bovenstaandeconstructie

6. * tekst *: tekst is commentaar

7. @ tekst: tekst is een sleutelveld in een store (aIleen vantoepassing in verband met object-relatie diagrammen)

8. 'tekst ': tekst is een constante

Zie ook: dataflowdiagram, flow, object-relatie dia­gram, store

Dataflow Dataflows geven het transport van objecten (ge­gevens, papier, electronen, ...) van de ene plaats in het sys­teem naar de andere weer; dataflows representeren dus datain beweging. Ze worden weergegeven door pijlen met de naamvan het object erbij, zie figuur 7.2. Vaak hoort een dataflowbij een object maar het is ook mogelijk om een verzamelingobjecten aan een flow toe te kennen. De flow 'adres' in fi­guur 7.2 zou bijvoorbeeld kunnen bestaan uit de onderdelen'straat', 'postcode' en 'plaats'.Flows kunnen zich vertakken, wat twee dingen kan betekenen:

201

Figuur 7.2: Voorbeeld van een dataflow

Figuur 7.3: Volledige data stroomt overde twee takken

Figuur 7.4: Data wordt verdeeldover twee takken

Referentielijst

1. Een kopie van de flow gaat naar versehillende plaatsen(de namen van de takken zijn hetzelfde als de naam voorde vertakking). Zie figuur 7.3.

2. De flow wordt in zijn samenstellende onderdelen ge­splitst (de namen van de takken versehillen van de naamvoor de vertakking). Zie figuur 7.4.

Bet is ook mogelijk om een flow samen te stellen uit een aantalandere flows. De flow 'adres' in figuur 7.5 wordt bijvoorbeeldsamengesteld uit 'straat', 'postcode' en 'plaats'.Tenslotte is het nog mogelijk om een flow in twee riehtingente gebruiken (zie figuur 7.5). In dit geval moet aan beide uit­einden van de pijl weergegeven worden welke objecten in dieriehting stromen.Een tijd-continue flow wordt weergegeven door een dubbelepijl ( _). Een dergelijke flow geeft een eontinu veran­derende variabele weer. Een voorbeeld is een spanning ofeen temperatuur. Een tijd-diserete flow ( _) daarentegen

202

Datafiowdia­gram

Referentielijst

Figuur 7.5: Flow samengesteld uit deelflows

geeft een signaal weer dat aIleen op bepaalde tijdstippen eenwaarde heeft.Dataflows komen voor op het contextdiagram en het data­flowdiagram.Zie ook: contextdiagram, dataflowdiagram

Dataflowdiagram Ret dataflowdiagram (DFD) geeft weeruit welke deeltaken het systeem is opgebouwd en welke data erdoor deze taken uitgewisseld wordt. Ret DFD is hierarchisch;het systeem wordt gezien als een aantal taken die op hun beurtweer opgebouwd kunnen zijn uit deeltaken. Ook deze deelta­ken kunnen weer opgedeeld worden. De bovenste laag vanhet DFD wordt gevormd door het contextdiagram. Ret eneproces van dit diagram wordt uitgewerkt in 'Figuur 1', waar­mee een eerste indeling van het systeem gegeven wordt. Deprocessen op dit diagram kunnen weer uitgewerkt worden inandere diagrammen. De nummering van de processen op eendiagram is als voIgt: het proces op het contextdiagram wordtniet genummerd. De processen op het diagram worden opvol­gend vanaf 1 genummerd. Als een proces uitgewerkt wordtin een ander diagram, krijgt dat diagram als naam 'Figuur x:naam van het proces', waarbij x het nummer van het procesis. De processen die op dit diagram voorkomen krijgen als

203

Datagebied

Dataproces

Dataspecificatie

Referentielijst

nummer x.I, x.2, enz.Ret DFD bestaat uit: besturingsprocessen, dataprocessen,dataflows, datastores, eventflows en eventstores. Ret diagramvormt een onderdeel van het conceptueel-model. Zie ook:besturingsproces, conceptueel-model, dataproces, da­taflow, datastore, eventflow en eventstore.

Datagebied Datagebieden komen voor op structure charts.Ze geven weer dat bepaalde gegevens gebruikt worden dooreen aantal modules. Datagebieden worden weergegeven doorrechthoeken die onder de modules die er gebruik van makengetekend worden. Over het algemeen komen datagebiedenovereen met stores op het DFD.Zie ook: dataflowdiagram, module, store, structurechart

Dataproces Ben dataproces is iets wat inputs in de vormvan dataflows omzet in outputs in de vorm van data- en event­flows. Dataprocessen komen voor op het contextdiagram enhet dataflowdiagram, waar ze weergegeven worden door eencirkel. Dataprocessen hebben altijd een specificatie in de vormvan een flowdiagram op een lager niveau, dan weI in de vormvan een stuk tekst.Zie ook: contextdiagram, dataflow, dataflowdiagram,eventflow, processpecificatie

Dataspecificatie Dataspecificaties worden gebruikt omaIle parameterpijltjes van de structure charts te specificeren.In de meeste gevallen kan deze specificatie rechtstreeks over­genomen worden uit de data dictionary. Er moeten nog eenaantal zaken toegevoegd worden:

• De representatie van de data moet gekozen worden (bij­voorbeeld integer, boolean, real, ...).

• De initiele waarde van data die door een aantal modulesgedeeld wordt, moet gespecificeerd worden.

204

Doelbeschrijving

Datastore

Referentielijst

Zie ook: data dictionary, parameterpijltje, structurechart

Doelbeschrijving De beschrijving van het doel van hetsysteem is een globale opsomming van taken waar het sys­teem verantwoordelijk voor is. De beschrijving is opzette­lijk vaag en kort (niet langer dan een aantal regels) om nietbij voorbaat oplossingen uit te sluiten en zoveel mogelijk het'implementatie-denken' te voorkomen. De doelbeschrijvingvormt een onderdeel van het conceptueel-model.Zie ook: conceptueel-model

Datastore Een datastore wordt gebruikt om opgeslagen da­ta weer te geven. Ze komen voor op het contextdiagram enhet dataflowdiagram. Stores bevinden zich tussen een of meeringaande en uitgaande flows (minstens 1 van beide soorten).Ze worden weergegeven door twee horizontale strepen met denaam van de store ertussen.Stores hebben de volgende twee belangrijke eigenschappen:

1. Ze zijn passief, dus leveren aIleen data of slaan aIleendata op als een proces erom vraagt.

2. Een leesactie is niet destructief, dus de gelezen datablijft onveranderd in de store aanwezig.

Een flow uit een store geeft een leesactie weer. Door mid­del van de naamgeving van de uitgaande flow kunnen tweesituaties weergegeven worden:

1. Als de flow uit de store geen label heeft wordt bij eenleesaktie de hele inhoud van de store in een keer uitge­lezen.

2. Als de naam van de flow verschilt van die van de storewordt bij een leesaetie een aantal gegevens of elementenvan gegevens uitgelezen.

205

Eisendefinitie

Event-list

Referentielijst

Een flow naar een store toe geeft een schrijfaetie weer. Eendergelijke aktie kan bestaan uit het toevoegen, verwijderen ofaanpassen van gegevens.Een store kan alleen verbonden worden met tijd-discrete flows.Een store fungeert als tijdsvertraging (een synchronisatie me­thode) voor de cornmunicatie tussen twee processen.Zie ook: contextdiagram, dataflow, dataflowdiagram

Eisendefinitie De eisendefinitie is een fase van het lifecyclemodel SQS, waarin de aan het systeem gestelde eisen vast­gelegd worden. We onderscheiden functionele eisen (takendie het systeem uit moet voeren), kwaliteitseisen (betrouw­baarheid, beschikbaarheid, capaciteit) en ontwikkeleisen (ge­bruikte technieken voor documentatie en ontwikkeling van hetsysteem).Zie ook: SQS

Event-list reageren. De events moeten voldoen aan drieeisen: Een event-list is een lijst van gebeurtenissen (events)waarop het systeem moet

1. Ze treden op in de omgeving van het systeem.

2. Ze starten een van te voren gedefinieerde aktie van hetsysteem.

3. Ze treden op een bepaald tijdstip op.

We onderscheiden vier soorten events:

1. Flow-georienteerde events geven de ontvangst van eendatapakket aan. Ze komen overeen met de flows in hetcontextdagram, maar het is niet zo dat bij elke floween event hoort. Flows waarover alleen data getrans­porteerd wordt als het systeem daarom vraagt (dus nietop 'initiatief' van de omgeving) komen niet overeen meteen event.

206

Eventflow

Eventstore

Referentielijst

2. Temporele events worden gestart op een bepaald tijd­stip en met en bepaalde frequentie herhaald. Dataflowskunnen indirect met een temporeel event geassocieerdzijn doordat een aktiviteit gestart wordt die bepaaldegegevens van de omgeving nodig heeft.

3. Besturings-events starten een bepaalde aktiviteit maarniet op een voorspelbaar tijdstip (zoals temporele e­vents). In het context diagram zijn ze weergegeven dooreventflows.

4. Ben extern event hoeft niet noodzakelijk overeen te ko­men met een flow uit de omgeving naar het systeem.Ben event kan bijvoorbeeld gei'nspireerd zijn op een be­paalde functie van het systeem. Zo zou 'gebruiker ver­wijdert karakter' in een editorprogramma een event kun­nen zijn. Ben editor zal als inputflow bijvoorbeeld 'aan­geslagen toets' hebben, waarvan de backspace en deletetoets een instantiatie zijn. Als ren van deze toetsenaangeslagen wordt, geeft dit aanleiding tot het event'gebruiker verwijdert karakter'.

Zie ook: dataflow, eventflow

Eventflow Een eventflow is een speciale binaire dataflowwaarmee het optreden van een bepaalde gebeurtenis aangege­ven wordt. Eventflows worden weergegeven door gestippeldepijlen. Ret verschil tussen een eventflow en een besturings­flow is dat de eerste niet gebruikt kan worden om een proceste aktiveren of te deaktiveren. Eventflows komen voor op hettaakniveau van het implementatiemodel en in mindere mateop het dataflowdiagram.Zie ook: besturingsflow, dataflow, dataflowdiagram,implementatiemodel,taakmodel

Eventstore Ben eventstore geeft een seinpaal weer, in devorm van twee gestippelde horizontale strepen met de naam

207

Flow

Flowdiagram

Gestructureerdetaal

Referentielijst

van de seinpaal ertussen. Eventstores kunnen aIleen verbon­den zijn met eventflows. Elke keer als het event dat met eenflow geassocieerd is optreedt wordt de waarde van de seinpaalmet 1 verhoogd. Als een besturingsproces de store uitleestwordt de waarde weer met 1 verlaagd. Eventstores komenvooral voor op het taakniveau van het implementatiemodel,maar ook op het dataflowdiagram.Zie ook: dataflowdiagram, eventflow, implementatie­model, taakmodel

Flow Flow is een verzamelnaam voor besturingsflow, data­flow en evenflow. Welke van de drie bedoeld wordt moet uitde context blijken.Zie ook: besturingsflow, dataflow, eventflow

Flowdiagram Flowdiagram is hier een synoniem voor da­taflowdiagram. In de literatuur wordt weI onderscheid ge­maakt tussen een dataflowdiagram waar geen besturingspro­cessen, besturingsflows of eventflows toegestaan zijn, en eenflowdiagram waar dat weI het geval is. Flowdiagram en da­taflow diagram zuBen door elkaar gebruikt worden, waarbijop beiden besturingsprocessen, besturingsflows en eventflowstoegestaan zijn.Zie ook: dataflowdiagram

Gestruetureerde taal Gestructureerde taal is een manierom de processen van het DFD te specificeren. Gestructu­reerde taal bestaat uit een deelverzameling van een natuur­lijke taal zoals Engels of Nederlands, met sterke beperkingvan de woordenschat en voor het vormen van zinnen. Benzin (statement) bestaat uit een vergelijking, een eenvoudigebeschrijving (gevormd met behulp van een werkwoord en denaam van een object) of een uit vier bijzondere constructies(IF, CASE, WHILE en REPEAT).Gestruetureerde taal lijkt op een programmeertaal, maar is

208

Referentielijst

minder formeel en meer omschrijvend. Ret formele beperktzicht tot de volgende constructies:

• Ret IF-ELSE-ENDIF statementMet behulp van deze uit programmeertalen bekendeconstructie kan een binaire keuze gemaakt worden. Desyntax is als voIgt:

IF conditiestatement-l

ELSEstatement-2

ENDIF

Ret ELSE-deel is optioneel, maar het is een goede ge­woonte om het toch op te nemen zodat het uiteindelijkeprogramma deterministisch is.

• Ret CASE statementMet behulp van een CASE statement kan een keuze uiteen aantal waarden gemaakt worden. De syntax is:

DOCASECASE conditie-l

statement-lCASE conditie-2

statement-2

CASE conditie-nstatement-n

OTHERWISEstatement-n+l

ENDCASE

Deze cODstructie biedt meer mogelijkheden dan soortge­Hjke cODstructies in programmeertalen, omdat de con­ditie niet beperkt is tot een gelijkheidstest (zoals een

209

Hand/eiding

Referentielijst

case-statement in bijvoorbeeld C of Pascal) maar ookiets kan zijn als '/eeftijd> 10 en /eeftijd< 20'. Voor het'ENDCASE'-geval geldt het zeflde als voor het 'ELSE'­deel van een 'IF'-statement.

• WHILE en REPEAT statementsMet behulp van WHILE en REPEAT statements kun­nen lussen gemaakt worden op dezelfde manier waaropdat in programmeertalen kan.De syntax is:

WHILE conditiestatement

ENDWHILEREPEAT

statementUNTIL conditie

Het nesten van statements is mogelijk, maar leidt al snel totonoverzichtelijke constructies. Drie geneste IF's kunnen waar­schijnlijk beter vervangen worden door een beslissingstabel.Als de specificatie langer wordt dan een A4-tje duidt dit opontwerpproblemen: het proces dat beschreven wordt is nietelementair en moet vervangen worden door een extra niveauin de hierarchie van het DFD.Zie ook: beslissingstabellen, dataflowdiagram, pre- enpostcondities, proces

Handleiding Het maken van handleidingen is een onder­deel van het lifecycle model SQS. Er zijn handleidingen voorgebruikers (de buitenkant van het systeem), systeembeheer­ders (systeemconfiguratie, installatie) en onderhoud van hetsysteem (toelichting op hardware, implementatiemodel en co­de in verband met wijzigingen).Zie ook: SQS

210

Implementatiemodel

Implementatiemodel(Ward/Mellor

Modulemodel

Referentielijst

Implementatiemodel Het implementatiemodel is een ver­taling van het conceptueel-model naar een concrete implemen­tatie. Er zijn veel methoden, waarvan die van Ward en Mellor([Mellor, 1986]) een veelgebruikte is.Zie ook: implementatiemodel (Ward/Mellor)

Implementatiemodel (Ward/Mellor) Het implementa­tiemodel volgens Ward en Mellor beschrijft hoe de processenvan het conceptueel-model verdeeld zullen worden over pro­cessoren, hoe de processen binnen processoren in parallel uit­voerbare eenheden (taken) verdeeld worden en tenslotte hoede processen van een taak in procedures en functies geimple­menteerd zullen worden.Het implementatiemodel bestaat uit de volgende onderdelen:

1. In het processormodel worden delen van hetconceptueel-model toegekend aan processoren.

2. In het taakmodel worden de aan een processor toege­kende processen verdeeld over parallel uitvoerbare een­heden.

3. Het modulemodel beschrijft de structuur van procedure­en functie-aanroepen binnen een taak.

Zie ook: implementatiemodel, modulemodel, proces­sormodel, taakmodel

Modulemodel Het laatste onderdeel van het implementa­tiemodel volgens \Vard en Mellor is het modulemodel. Elketaak heeft een modulemodel waarin aangegeven wordt hoe deprocessen van de taak in procedures en functies gerealiseerdworden. Het model bestaat uit een structure chart met spe­cificatie van de gebruikte functies en de gebruikte data.Zie ook: dataspecificatie, implementatiemodel, mo­dulespecificatie en structure chart

211

M odulespecificatieModulespecificatie Modulespecificaties zijn tekstuele be­schrijvingen van de functie van een module. Bij elke modulehoort een dergelijke specificatie ook bij modules die uit deel­modules bestaan (in tegenstelling tot processen van het DFD,die aIleen tekstueel gespecificeerd worden als ze niet uitge­werkt zijn in een diagram). Een specificatie ziet er als voIgtuit:

Input:Output:Lokaal:

BEGINDe body

ENDENDMODULE

MODULE ,Modulenaam,Doel: Korte beschrijving van de door de module

uitgevoerde taak.AIle inputvariabelen van de moduleAIle outputs van de moduleAIle lokale variabelen van de module

De doelbeschrijving en de variabelen declaraties kunnen vaakovergenomen worden uit een specificatie van een proces. Ookde body is vaak te kopieren, tenminste als de specificatie vaneen proces in gestructureerde taal opgesteld is.Zie ook: dataflowdiagram, processpecificatie, struc­ture chart

Objeet-relatiediagram

Object-relatie diagram Object-relatie diagrammen(ERD: Entity Relation Diagram) worden gebruikt om de op­bouw van opgeslagen data te modelleren. Een ERD bestaatuit vier componenten

1. objecttypen

2. relaties

3. associaties

4. super/subtype relaties

Referentielijst 212

Objecttype

Omgevingsanalyse

Referentielijst

ERD's zijn vooral van belang voor applicaties die data­georienteerd zijn, zoals database toepassingen.Zie ook: associatie, objecttype, relatie, su-per/subtype relatie

Objecttype Objecttypes komen voor op het ERD. Ze wor­den weergegeven door een rechthoek met daarin de naam vanhet objecttype. Het type representeert een verzameling ob­jecten met de volgende eigenschappen.

• Elk object in het objecttype is uniek identificeerbaar.Als we bijvoorbeeld het objecttype 'klant' beschouwenmoet er dus een kenmerk zijn waarmee de verschillendeklanten van elkaar te onderscheiden zijn (bijvoorbeeld'naam' of 'klantnummer').

• Het objecttype moet absoluut noodzakelijk zijn voor hetfunctioneren van het systeem.

• Elk object van een bepaald objecttype heeft dezelfdeverzameling kenmerken (bijvoorbeeld elke klant heefteen naam, adres en telefoonnummer).

Zie ook: associatie, object-relatie diagram, relatie, su­per/subtype relatie

Omgevingsanalyse De omgevingsanalyse is een beschrij­ving van die facet ten van de omgeving van het te ontwikkelensysteem die ervoor van belang zijn. Voor systemen die bedoeldzijn voor een specifieke omgeving (een fabriek bijvoorbeeld)bestaat de omgevingsanalyse uit een beschrijving van de ar­chitectuur van de omgeving. Generieke systemen (compilers,editors en dergelijke) zijn geschikt voor diverse omgevingenen vragen daarom een beschrijving van het type omgevingwaarin ze moeten functioneren.Zie ook: SQS

213

Parameterpijltje

Pre- enpostcpndities

Referentielijst

Parameterpijltje Parameterpijltjes geven weer welke datauitgewisseld wordt tussen de modules van een structure chart.De richting van het pijItje geeft aan in welke richting het da­tatransport plaatsvindt. Er zijn twee soorten:

1. Dataparameters worden aangegeven door een open cir­kel aan het eind van het pijItje. Ze geven aan dat deparameter als data gezien moet worden.

2. Besturingsparameters worden weergegeven door een ge­sloten cirkel aan het eind van het pijItje. Ze geven be­sturingsinformatie weer (vergelijk dataflow/ eventflow).

Zie ook: module, structure chart

Pre- en postcondities Pre- en postcondities zijn een mid­del om een proces van het DFD te specificeren. Met behulpvan pre- en postcondities kan de functie die een proces uit­voert beschreven worden zonder iets te hoeven zeggen over demanier waarop de uitvoering plaatsvindt.Precondities beschrijven de voorwaarden waaraan moet zijnvoldaan voordat het proces gestart wordt. Ze beschrijven overhet algemeen

• de inputs die beschikbaar moeten zijn

• welke relaties tussen de inputs onderling moeten geldenof welke waarde een input moet hebben

• welke relaties tussen inputs en de inhoud van stores moe­ten bestaan

• welke relaties tussen verschillende stores of de gegevensin een store moeten bestaan.

Postcondities beschrijven aan welke voorwaarden moet zijnvoldaan nadat het proces afgelopen is. Ze beschrijven overhet algemeen

• de gegenereerde outputs

214

Proces

Processormodel

Processpecificatie

Referentielijst

• de relaties tussen outputs en de inputwaarden

• de relaties tussen outputs en de inhoud van stores

• de veranderingen in de inhoud van stores.

Een proces kan beschreven worden door een aantal pre- enpostconditie paren.Zie ook: beslissingstabel, dataflowdiagram, gestruc­tureerde taal, proces, processpecificatie

Proces Proces is een synoniem voor dataproces en bestu­ringsproces, welke van de twee bedoeld wordt moet uit decontext afgeleid worden.Zie ook: besturingsproces, dataproces

Processormodel Een processor is in staat een bepaaldetaak uit te voeren. Dit kan een mens of een programmeerbarecomputer zijn, maar ook een elektrisch circuit of een mechani­sche constructie komen in aanmerking. We zullen ons verderalleen met programmeerbare digitale apparatuur bezig hou­den.De eerste stap in het samenstellen van een implementatiemo­del is het identificeren van processoren die de taken uit zullenvoeren en het toewijzen van delen van het conceptueel-modelaan deze processoren. Het resultaat is een nieuw hierarchischmodel van het systeem. De bovenste laag bestaat uit eenaantal processoren, de lagen daaronder zijn delen van hetconceptueel-model.Zie ook: conceptueel-model, implementatiemodel,proces

Processpecificatie Processpecificaties beschrijven de ac­ties die processen op het laagste niveau van het DFD uit­voeren om inputs om te zetten in outputs. Ze beschrijven dusprocessen die niet in een aparte figuur van het DFD uitge­werkt worden.Er zijn drie veelgebruikte specificatietechnieken:

215

Prompt

Relaties

Referentielijst

1. gestructureerde taal ('Structured English')

2. pre- en postcondities

3. beslissingstabellen

Daarnaast zijn er nog een aantal slechte methoden zoals ge­wone taal (te veel redundantie, onoverzichtelijk, dubbelzin­nig), flow diagrammen en Nassi-Schneidermann diagrammen(beide soorten diagrammen beschrijven een algorithme, watniet de bedoeling van een functionele specificatie is). Eenandere methode is die beschreven in [Hayes, 1987] waarbij ge­bruik gemaakt wordt van wiskundige technieken. Gewone taalzou eventueel gebruikt kunnen worden in heel eenvoudige ge­vallen, maar dan voldoet gestructureerde taal natuurlijk ook.Er is geen goede reden om ren van de drie methoden te kiezenen die voor elke specificatie te gebruiken. Elke methode heeftzijn eigen voor- en nadelen, je kunt dus de voor een bepaaldesituatie meest geschikte methode uitzoeken.Voor het specificeren van besturingsprocessen worden toe­standsdiagrammen gebruikt.Zie ook: beslissingstabellen, dataflowdiagram, ge­structureerde taal, pre- en postcondities, proces, toe­standsdiagrammen

Prompt Prompt is een synoniem voor besturingsflow.Zie ook: besturingsflow

Relaties Relaties komen voor op ERD's. Ze VOl'men deverbinding tussen objecttypen. Relaties worden weergegevendoor een ruit met daarin de naam van de relatie. De ruit isvia lijnen verbonden met de relevante objecttypen. Een voor­beeld van een relatie is in figuur 7.6 weergegeven. Merk opdat deze relatie niets zegt over welke klant welk artikel kooptof hoeveel klanten een bepaald artikel kopen. Er wordt aIleenaangegeven dat er een verband is tussen twee objecttypen. Erkan een aantal relaties bestaan tussen twee objecttypen. Deze

216

SQS

Store

Referentielijst

Figuur 7.6: Volledige data stroomt over de twee takken

relaties moeten dan onderling onafhankelijk zijn.Zie ook: object-relatie diagram, objecttype

SQS SQS (software quality system) is een lifecycle model,dat wil zeggen een methode om een software systeem te be­schrijven vanaf het moment waarop iemand de behoefte eraanonderkent tot het moment waarop het vervangen wordt.SQS definieert de levenscyclus van een systeem in de volgendefasen:

1. omgevingsanalyse

2. eisendefinitie

3. conceptueel-model

4. implementatiemodel

5. code

6. handleidingen

Zie ook: code, conceptueel-model, eisendefinitie,handleiding, implementatiemodel, omgevingsanalyse,testmodel

Store Store is een synoniem voor datastore en eventstore.Welke van de twee bedoeld wordt moet uit de context afgeleidworden.Zie ook: datastore, eventstore

217

ModuleA

ModuleB

ModuleD

data 1

ModuleC

data 1

Structure chart

Superjsubtyperelaties

Referentielijst

Figuur 7.7: Een voorbeeld van een structure chart

Structure chart Een structure chart beschrijft de verde­ling van een taak in modules, de hierarchische organisatie vandeze modules en de interfaces ertussen. Structure charts vor­men een onderdeel van het implementatiemodel.Structure charts bestaan uit modules, calls, parameterpijlenen datagebieden. In figuur 7.7 is een voorbeeld gegeven vaneen eenvoudige structure chart om de boven beschreven con­cepten te illustreren. 'U' is hier een besturingsparameter, 'X','V' en 'z' zijn parameters voor het doorgeven van data. Degegevens in 'datal' worden door 'module C' en 'module D'gedeeld.Zie ook: call, datagebied, implementatiemodel, mo­dule, parameterpijl

Super/subtype relaties Super/subtype relaties komenvoor als onderdeel van object-relatie diagrammen. Met behulpvan dit type relaties kan aangegeven worden dat een object­type bestaat uit een aantal deelcategorieen. Er worden voorhet hoofdtype (supertype) een aantal gegevens bijgehouden,

218

Taakmodel

Referentielijst

terwijl voor elk subtype een verschillende verzameling additi­onele gegevens bijgehouden wordt. Ben voorbeeld is een ver­zameling journalisten waarvan er een aantal vaste medewer­kers zijn en een aanta! op free-lance basis werkt. Over elkejournalist worden gegevens als naam, adres, telefoonnumeren dergelijke bijgehouden, terwijl over vaste medewerkers ooknog zaken bewaard worden als maandsalaris en afdeling. Overde free-lancers wordt daarentegen alleen bijgehouden wat hunsalaris per uur is. De relatie wordt als voIgt weergegeven (ziefiguur 7.8). Ret supertype wordt bovenaan getekend, daaron­der voIgt een lege relatie-ruit, verbonden met het supertypedoor een lijn met een korte dwarsstreep erin. Onder de relatie­ruit volgen de verschillende subtypen.In de datadictionary worden super/subtypen weergegeven

Figuur 7.8: Ben super/subtype

door in een commentaarregel de gemeenschappelijke data opte nemen. De compositie van het object is dan een lijst metsubtypes weergeven als alternatieven. Ret journalistenvoor­beeld kan als voIgt gedefinieerd worden:

journalisten & * naam. adres. telefoonnummer *& [vast I free-lance]

Zie ook: object-relatie diagram

Taakmodel Ret taakmodel beschrijft de interne organisatievan elke processor in de vorm van parallel uitvoerbare taken.Met een taak wordt een onafhankelijk uit te voeren stuk van

219

Terminator

Testmodel

Toestandsdiagram

Referentielijst

het processormodel bedoeld. Een taak kan onderverdeeld zijnin deeltaken die op hun beurt ook weer uit deeltaken kunnenbestaan. Binnen taken op het laagste niveau is er geen paral­lellisme meer. Op een hoger niveau kunnen taken weI paralleluitgevoerd worden.In het processormodel werden delen van het conceptueel-mo­del toegekend aan processoren. Ret modellegt geen beperkin­gen op aan parallellisme en de besturing binnen een proces­sor hoeft niet gecentraliseerd te zijn. Ret taakmodel verdeeltstukken van het processormodel over een aantal taken, waar­binnen parallellisme beperkt is (zeUs verboden in een taak ophet laagste niveau) en de besturing gecentraliseerd is. Ditheeft als consequentie dat het aantal processen kan toe- ofafnemen. Ret taakmodel is daarom meer dan een nieuwe dis­tributie van processen.Zie ook: implementatiemodel, proces, processormo­del

Terminator Terminators komen voor op het contextdia­gram. Ze representeren zaken (systemen, mensen, enz.) bui­ten de controle van het systeem. Ze worden weergegeven doorrechthoeken met een naam erin. Ret gedrag van terminatorsis een niet te veranderen gegeven. De connecties tussen hetsysteem en de terminators geven de interfaces tussen het sys­teem en de buitenwereld weer. Relaties tussen terminatorsonderling verschijnen niet op het diagram omdat ze geen on­derdeel uitmaken van het systeem.Zie ook: contextdiagram

Testmodel Ret testmodel beschrijft de uit te voeren test­procedures en de verwachte resultaten.Zie ook: SQS

Toestandsdiagram Voor het specificeren van besturings­processen wordt gebruik gemaakt van toestandsdiagrammen.Deze diagrammen zijn opgebouwd uit toestanden en overgan-

220

functioneledecompositie

Referentielijst

.1 toeltand II 3

voorwaarde voorwaarde voorwaardealdie aldie aldie

y toeltand I I toatand I1 2

Figuur 7.9: Het eerste niveau van een toestandsdiagram

gen daartussen. De overgangen worden weergegeven door eenpijl met daarnaast een voorwaarde waaraan voldaan moet zijnom de overgang mogelijk te maken. Onder de voorwaardevoIgt een horizontale streep met daar weer onder de aktiesdie uitgevoerd moeten worden tijdens de overgang. Ben voor­beeld is gegeven in figuur 7.9Zie ook: besturingsproces, processpecificatie

7.3 Technieken

Deze paragraaf beschrijft een aantal technieken die nuttigkunnen zijn bij het opstellen van een conceptueel- en een im­plementatiemodel.

7.3.1 Het opstellen van een DFD

Er zijn een aantal manieren om een eerste versie van het DFDop te stellen waaronder:

1. functionele decompositie

2. met event partitioning

Bij functionele decompositie wordt als eerste stap het systeem

221

event­partitioning

Referentielijst

als een functie gezien met bepaalde inputs en outputs. Dezefunctie wordt opgedeeld in een aantal deelfuncties die dezelfdeinput/output relatie realiseren als het origineel. Dit procesgaat door totdat de functies eenvoudig genoeg zijn om gespe­cificeerd te worden.De nadelen van deze methode zijn:

• Er ontstaat al snel een arbitraire verdeling in deelfunc­ties (meestal afhankelijk van het aantal mensen dat hetproject uitvoert). Een slechte indeling verhindert goedeimplementaties.

• De methode geeft geen aanwijzingen voor een goede in­deling; er is aIleen controle achteraf mogelijk. Dit houdtin dat veel werk verloren gaat bij het opstellen en con­troleren van onbruikbare alternatieven.

Door gebruik te maken van event-partitioning ontstaat eenmodel van het systeem op een niveau ergens midden in dehierarchie. Voor het verwerken van elk event wordt een pro­ces gedefinieerd, wat over het algemeen in een te groot aantalprocessen zal resulteren. Daarom zal het nodig zijn om pro­cessen te groeperen in processen van een hoger niveau.De werkwijze is als voIgt:

• Definieer een proces voor elk event uit de eventlist.

• Als naam krijgt het proces de responsie die het systeemop het event moet uitvoeren.

• Teken de voor de reaktie benodigde inputs en de gepro­duceerde outputs. Als twee processen met elkaar com­municeren moet er een store tussen getekend worden,omdat de events voor twee processen niet tegelijkertijdhoeven op te treden. Er is in dit geval een store nodigom tijdvertragingen op te vangen.

• Controleer het DFD met behulp van de event-list en hetcontextdiagram.

222

hierarchie naarboven

minimale inter­faces

stores verbergen

het getal 7

decompositie

Referentielijst

Nadat deze eerste versie van het DFD klaar is moeten pro­cessen op een hoger niveau gedefinieerd worden, waarvan deprocessen op het lagere niveau de specificatie vormen. Als ernu nog steeds te veel processen over zijn, moet nog een extraniveau aangebracht worden, net zo lang totdat een redelijkaantal processen over is.Een goede strategie om hogere niveaus te definieren is de mini­male interfaces strategie, waarbij er naar gestreefd wordt omde communicatie tussen processen tot een minimum te be­perken, zodat synchronisatieproblemen zoveel mogelijk wor­den vermeden. Hierbij hoeft geen rekening te worden gehou­den met opgeslagen data omdat die per definitie al gesyn­chroniseerd is. Het gaat aIleen om flows tussen de processen.Een bijkomend voordeel van deze strategie is dat processenbijna onafhankelijk van elkaar bestudeerd kunnen worden.Naast de hoofdstrategie kunnen nog de volgende bijkomenderichtlijnen gebruikt worden:

• Probeer zoveel mogelijk stores te verbergen. Eengroepje processen dat dezelfde store gebruikt is eengoede kandidaat voor een proces op een hoger niveau.

• Zorg ervoor dat op elke figuur niet meer dan 7 ± 2 pro­cessen overblijven (George Miller: 'The Magical NumberSeven, Plus or Afinus Two'). Dit houdt vaak in dat meerdan een extra niveau nodig is.

Naast het aanbrengen van een hierarchie naar boven is hetvaak ook nodig om een aantal van de processen uit het eerstediagram verder uit te werken, dus te splitsen in deelproces­sen. Dit kan gebeuren door deelfuncties te definieren of doorde inputs en outputs te laten verwerken, respectievelijk pro­duceren, door een apart proces.Merk op dat het eerste diagram geen deel uitmaakt van heteigenlijke DFD. Nadat een hierarchie naar boven is aange­bracht worden de processen van het eerste diagram verdeeldover die op het hogere niveau. Daarna worden deze processen

223

echte omgeving

interfacelaag

virtueleomgevmg

eventherkenning

Referentielijst

eigenlijke analooaenaor alcohol 0

virtuele sensor

Figuur 7.10: Een virtuele sensor

in aparte figuren uitgewerkt. Ret eerste diagram komt dusverspreid over een aantal figuren terug in het DFD.A

7.3.2 Interfacetechnologie

Ret model kan beschermd worden tegen veranderingen in degebruikte interfacetechnologie (bijvoorbeeld een andere sen­sor, een parallelle in plaats van een seriele data-overdracht)door gebruik te maken van virtuele terminators. Een voor­beeld is een sensor die het alcoholgehalte van de oplossingdoorgeeft aan het systeem. Deze sensor zou eruit kunnen zienals in figuur 7.10 gegeven. Ret invullen van de inhoud vanhet blok 'virtuele sensor' kan overgelaten worden aan de im­plementatiej het is dus mogelijk om technologiebeslissingenuit te stellen. Ret volledige contextmodel ziet er in het al­gemeen uit zoals in figuur 7.11 weergegeven, dus opgebouwduit een 'echte' omgeving, een interfacelaag en een virtuele om­geving. Voor het conceptueel-model is aIleen de virtuele om­geving van belang. Pas bij het implementeren moet ook deinterfacelaag bij de beschouwing betrokken worden. Er isnog een techniek beschikbaar waarmee de kern van het modelgewapend kan worden tegen veranderingen in omgeving of im­plementatie: het aanbrengen van een laag in het DFD waarinevents herkend worden. Een voorbeeld hiervan is een event'de gebruiker wi! een file van disk lezen' in een editor. Roe degebruiker dit kenbaar maakt is onafhankelijk van het inlezenvan de file zelf. Door nu een proces toe te voegen waarmee

224

8virtueletermina­

tor

echtetermina­

tor

r----------------,I

r-----, IIII

II

- - - - - - - - - - -j I

I II II II I

I1 II II

1 1 IL vlri~el! 0.!Dl.ev~ I I

I L~~~~J :L ..!~t!..o~g!V~ I

Figuur 7.11: Het gelaagde omgevingsmodel

het event herkend wordt, kan deze onafhankelijkheid explicietgemaakt worden. In figuur 7.12 is deze laag getekend.

7.3.3 Naamgeving

De naamgeving van dingen als processen, flows en terminatorsis erg belangrijk, omdat door een foute of onduidelijke naam­geving misverstanden kunnen ontstaan. Let op de volgendezaken:

uitgeoefendefunetie

• Gebruik in plaats van de namen van personen de naamvan de uitgeoefende funetie. Deze laatste soort namen isveel minder onderhevig aan veranderingen dan de eerste.

systeem­ondenJJerp

• Terminators en flows moeten vanuit bet standpunt vanbet systeem-onderwerp geidentificeerd worden. Dit wi!zeggen dat de naamgeving in termen van bet systeemon­derwerp en niet in computertermen moet zijn. Een voor­beeld is in de figuren 7.13 en 7.14 weergegeven, waarbijde eerste een slechte en de tweede de juiste naamgevingweergeeft.

Referentielijst 225

~-------------------------~

__~;",~J_''j,~\ !!<;"",L _+Q :I deakuveer \ woord I deakuveer ~ I.

---..+---L...1

_.ol\. \, _f <""'-''-,-+-,-SeDereer antwoord TL ~-;~----------J ,

I I I,I

, Ding I

, h k . ,L e~e~t _er_e~~ ,

I

IA

Figuur 7.12: DFD met event herkennigslaag

bufferinlaatklep

drankalcohol in tanksehalte

'------'

klepltand

drankItatus

bottel.eontroler I----:-_~\..,

DAC

ADCdigitaleinput '--__.....

digitaleoutput

displayt----~\

Figuur 7.13: Contextmodel met slechtenaamgevmg

Figuur 7.14: Contextmodel met goedenaamgeving

Referentielijst 226

diagram

processpecificatie

besturingsproces

7.3.4 Het toewijzen van processen aanprocessoren

Bij het toewijzen van processen aan processoren kunnen eenaantal gevallen onderscheiden worden:

1. Ret proces wordt beschreven door een diagram op eenlager niveau in de hierarchie van het DFD. In dit gevalkunnen delen van het diagram gekopieerd worden naarde modellen voor de betreffende processoren.

2. Een proces beschreven door een processpecificatie moetverdeeld worden over processoren. Dit maakt het nood­zakelijk dat de processoren hun werkzaamheden syn­chroniseren. De specificatie wordt in delen gesplitst envan synchronisatiestatements (bijvoorbeeld met behulpvan semaforen) voorzien.

3. Een besturingsproces moet gesplitst worden. In dit ge­val is er een procedure waarmee het toestandsdiagramvan het proces verdeeld kan worden:

(a) Kopieer het diagram voor elke processor waaroverhet verdeeld moet worden.

(b) Bestudeer de voorwaarde/aktie paren bij elke tran­sitie en voer een van de volgende akties uit:

• deze processor controleert de voorwaarde envoert de aktie uit: voeg een aktie toe waar­mee aan de andere processor kenbaar gemaaktwordt dat de voorwaarde gecontroleerd is

• de voorwaarde wordt door deze processor ge­controleerd, terwijl de andere de aktie uit­voert: vervang de aktie door een signaal dataangeeft dat de voorwaarde gecontroleerd is

• de aktie wordt door deze processor uitgevoerd,terwijl de andere de voorwaarde controleert:vervang de voorwaarde door de ontvangst van

Referentielijst 227

Referentielijst

een signaal dat de voorwaarde gecontroleerd is(dit signaal wordt gegenereerd door de andereprocessor waarvoor het voorgaande geval vantoepassing is)

• de andere processor controleert de voorwaardeen voert de aktie uit: vervang de voorwaardedoor de ontvangst van een signaal dat de voor­waarde gecontroleerd is en verwijder de aldie.

(c) Voor elke toestand waarvan

• aIle uitgaande transities als voorwaarden sig­nalen van andere processoren maar geen aktieshebben, en

• aIle uitgaande transities naar dezelfde toe­stand gaan

doe het volgende:

• verwijder de toestand en zijn uitgaande trans­ities

• leid aIle inkomende transities om naar de toe­stand die volgde op de zojuist verwijderde toe­stand.

Blijf deze stap uitvoeren tot geen toestanden meerverwijderd kunnen worden.

4. Verwijder aIle gegenereerde signalen die door het verwij­deren van toestanden overbodig geworden zijn en pas denaamgeving van toestanden en signalen aan.

Een voorbeeld

In figuur 7.15 is een stukje DFD van een systeem waarmee£lessen gevuld kunnen worden gegeven. Er zijn vijf processenwaarmee gecontroleerd kan worden of een £les aangekomenis ('Wacht op £les'), een £les gevuld kan worden ('Vul £les'),een £les gelabeled kan worden ('Label £les'), een £les afgeslotenkan worden ('Sluit £les af') en een £les afgevoerd kan worden

228

stap (a)

stap (b)

stap (c)

Referentielijst

0®I II I

Sea I I Seasevuld I I selabeled

I I

® ..-..., -@wacht Q. l Sea lI1uit

op - .t!.ea_ -.bnturingl.- -1- - ...... II er I I lea oten ueauea '"-f

I SeaI af'gevoerdI

®Figuur 7.15: Bet te splitsen stukje DFD

('Voer fles af'). We willen dit systeem verdelen over tweeprocessoren. De eerste processor verzorgt het transport van£lessen, de tweede zorgt ervoor dat de flessen gevuld, gelabeleden afgesloten worden.Figuur 7.16 geeft het te verdelen toestandsdiagram. Instap (a) van het algorithme wordt dit diagram gekopieerd,waarna op elke transitie een van de vier beschreven operatiesuitgevoerd wordt. In figuur 7.17 is het resultaat gegeven voorde transport processor. Bet paar '£les is er/aktiveer vul fles' isvervangen door 'fles is er/stuur £les is er ontvangen' op grondvan de tweede regel die in stap (b) vermeld is. Op grond vande vierde regel worden de overgangen '£les vol/aktiveer label£les' en '£les gelabeled/aktiveer sluit £les' vervangen door '£lesvol ontvangen/' en '£les gelabeled ontvangen/,. Na de eerstekeel' stap (c) uitgevoerd te hebben ziet het diagram eruit alsin figuur 7.18 getekend. De toestand '£les wordt gevuld' isverwijderd, omdat de uitgaande transitie van deze toestandalleen signalen van de tweede processor als voorwaarde en geen

229

Figuur 7.16: Ret oorspronkelijke toe­standsdiagrarn

Referentielijst

fiea afgevoerd

aktiveer 'wacht op fiea'.tuur 'fiea afgevoerd ontvaneen'

Figuur 7.17: 'Bestuur transport' na stap1

230

Ba afgevoerd

aktiveer 'wacht op Bes'.tuur 'Ba afgevoerd ontvangen'

Figuur 7.18: 'Bestuur transport' na eerstekeel' stap 3

Figuur 7.19: 'Bestuur transport' natweede keel' stap 3

stap (d)

Referentielijst

akties heeft Stap (c) kan nog een keel' uitgevoerd worden metals gevolg dat ook de toestand '£les wordt gelabeled' verwij­derd kan worden. Meer toestanden kunnen niet weggehaaldworden. Het resultaat van stap (d) is te zien in figuur 7.19.Het genereren van het signaal '£les afgevoerd ontvangen' isoverbodig geworden (dit signaal wordt door de tweede pro­cessor niet meer gebruikt) en de naam '£les wordt gesloten' isvervangen door '£les wordt verwerkt' om betel' weer te gevenwat er gebeurt.In figuur 7.20 is het resultaat gegeven van het toepassen vanhet algorithme op het tweede stuk van de besturing. Fi­guur 7.21 tenslotte geeft de twee DFD's weer.

231

Referentielijst

fies geslaten

.tuur 'fie. vuwerkt'

Figuur 7.20: Toestandsdiagram van 'Verwerk fles'

232

eventresponsie

Referentielijst

r-----------..,10I TU1

: Sa

I I Sa vol~----------- ..... Saiaer I J

®....-...,tanhallgenl ....... , ®

wacbt .. 'b. -1- - - - -1-.( beltuur~a labelop .,.1Ill! ea.uur I verweJ'oSa 1& er ~ranlPO~ - - - - L I kina II l)eIed Sa

" .... I Sa I" ....-r I verwerkt I "'rSa at'levoerd I I I I Sa Ics10ten

I I I I

G) I I@voer I ISea I I Iluitat' I I Sa

Transport procasor I I Verwerkings procalorL ~ L ~

Figuur 7.21: Ret DFD na splitsing

Voorkom synchronisatieproblemen Ret toewijzen vanprocessen aan een processor kan tot behoorlijke conflicten lei­den als het nodig is om de processen die samen de responsieop een event vormen te splitsen. Ret voorbeeld in figuur 7.22zou op de in figuren 7.23 en 7.24 gegeven manieren over tweeprocessoren verdeeld kunnen worden. Figuur 7.23 heeft devoorkeur omdat de synchronisatie beperkt blijft tot een pro­cessor (als we aannemen dat toegang tot de store onder mu­tual exclusion plaatsvindt). Daarnaast wordt in figuur 7.24de logica van het proces 'verander %' over twee processorenverdeeld wat wijzigingen in de implementatie van het procesmoeilijk maakt. Merk op dat de oplossing van figuur 7.24de struetuur van het conceptueel-model verstoort. Over hetalgemeen brengt dit de meeste problemen met zich mee, maarsorns is het niet te vermijden.

233

t

alcohol%;'" - ...... ,

aktiveerL' . Id-;.kti;e~ -,beatunng,, ;'

I

I aktiveer/,deaktiveerI

gewenat%....------I nieuw%

Figuur 7.22: Een DFD dat over 2 taken verdeeld moet worden

processor 2r-----', I, I

I '" - .... I,'aktiveerL" ., II - - - "' - bestunng ICieaktiveeI' I I

I "" II , I II, I

__ J , I aktive~/, I deaktivfer

I, I

I II ,

nieuw%gewCDllt%,....r-----+--II

I IL J

,,,L __

processor 1r--f--'I ,

I ' ,I ,f'out

alcohol%1,e.

Figuur 7.23: Een goede splitsing

Referentielijst 234

procell.or 1 proceaaor 2

r--f--' r-----'I I I I

II fout I I II 'I .... - ... , I

alcohol%' laktiveerL' I ., I~""'"'-rl-'·'1 'c!-;.£ti;ed -,bClturinIJ I

I I'.... I....---l I I I I

I I I II I aldivectl

gewenat% I deaktiI I I vferI I II I II I I

acce tee nieuw%,alcohol%,

, I I 1L J L J

Figuur 7.24: Een minder goede splitsing

Allocatie van stores

Data die opgeslagen is in stores kan op drie manieren doormeer dan ren processor gebruikt worden:

1. delen van de store

2. de store is eigendom van een bepaalde processor

3. de store wordt gekopieerd voor elke processor

mutualexclusion

Delen van de store AIle processoren hebben dezelfde toe­gangsrechten tot de store. De inhoud ervan kan onder mutualexclusion gemanipuleerd worden. Er zijn geen toevoegingenof wijzigingen van de dataflowdiagrammen voor de processo­ren nodig om deze situatie weer te geven. In figuur 7.25 iseen voorbeeld gegeven: het procesormodel, met daaronder deDFD's voor de twee processoren. Store 'V' wordt gedeeld.

processen voorcommunicatie

Exclusief eigendom Als slechts ren van de processoren di-

Referentielijst 235

~-A~data-u

r-:---------,IProc:aaor 1 I

1&11 --I1 proc:a A data 1

I IL I

r:---------.1Proc:aaor 2 11 811-- ,1 data - proc:a B I

I IL I

processen voorsynchronisatie

Referentielijst

Figuur 7.25: Een store wordt gedeeld door twee processorenmet gelijke toegangsrechten

recte toegang heeft tot bepaalde data, heeft een proces in eenandere processor de hulp van de eerste processor nodig om dedata uit te lezen of te wijzigen. Als processor I store X inbezit heeft en processor 2 wil data uit deze store lezen, moetaan de processen die op I draaien een proces toegevoegd wor­den om de data aan 2 over te dragen. In figuur 7.26 is eenvoorbeeld gegeven. 'Processor A' is hier eigenaar van de store.'Proces BI' wordt toegewezen aan 'Processor A' om de com­municatie met 'Processor 2' te verzorgen.

Verdubbeling Als verdubbeling wordt toegepast moet aanaIle processoren die de data nodig hebben een proces toege­voegd worden om ervoor te zorgen dat de inhoud van de storesgelijk blijft (erg gevaarlijk dus). AIle processoren hebben nuweI ongelimiteerde lees-toegang tot de data, wat voordelen opkan leveren als relatief veel gelezen en weinig gewijzigd wordt.In figuur 7.27 zijn 'Proces BI' en 'Proces AI' toegevoegd aanrespectievelijk 'Processor A' en 'Processor B' om de commu­nicatie tussen de processoren te verzorgen.

236

data

Figuur 7.26: Ben processor is eigenaar vande sto·re

L _

Figuur 7.27: De store wordt verdubbeld

beperktparallel/isme

gecentraliseerdebesturing

Referentielijst

7.3.5 Het toewijzen van processen aan ta­ken

In het processormodel werden delen van het conceptueel-mo­del toegekend aan processoren. Het modellegt geen beperkin­gen op aan parallellisme en de besturing binnen een proces­sor hoeft niet gecentraliseerd te zijn. Het taakmodel verdeeltstukken van het processormodel over een aantal taken, waar­binnen parallellisme beperkt is (zelfs verboden in een taak ophet laagste niveau) en de besturing gecentraliseerd is. Ditlaatste houdt in dat aIle besturingsprocessen binnen een taaksamengevoegd moeten worden, zodat het totale aantal pro­cessen dus af kan nemen. Het taakmodel is daarom meer daneen nieuwe distributie van processen.

237

algorithme

aktivering

begintoestand

transitie

Referentielijst

Het samenvoegen van toestandsdiagrammen

Voor het samenvoegen van twee toestandsdiagrammen kaneen standaard algorithme gebruikt worden, aangepast aan despecifieke eisen van het huidige probleem. Het algorithmewerkt als voIgt:

1. Teken de twee samen te voegen toestandsdiagrammenopnieuw. Als een diagram door een extern signaal geak­tiveerd of gedeaktiveerd kan worden, moet een nieuwebegintoestand toegevoegd worden. Vanuit deze nieuwebegintoestand wordt een transformatie naar de oudebegintoestand getekend, met als voorwaarde 'aktiveer'.Vanuit elke toestand wordt een overgang naar de nieuwebegintoestand getekend met als voorwaarde 'deaktiveer'en als akties het deaktiveren van alle processen die opdat moment aktief zijn.

2. De begintoestand van het samengestelde diagram is desamenstelling van de begintoestanden van de twee dia­grammen die in stap I zijn getekend.

3. Beschouw nu aIle transities in de diagrammen vanstap 1. Bepaal in welke toestand elk diagram terechtkomt als de voorwaarde voor de transitie optreedt. Voegop het nieuwe diagram een transitie toe met als voor­waarde de voorwaarde van de beschouwde transitie enals doel een (eventueel nieuwe) toestand die de combi­natie is van de toestanden waarin de oude diagrammenterecht zouden komen. Merk op dat een overgang inhet ene diagram een overgang in het andere kan ver­oorzaken. Zo kan bijvoorbeeld de overgang in diagramA van toestand Al naar A2 als aktie een overgang vantoestand BI naar B2 in diagram B veroorzaken. Denieuwe toestand zal dan A2/B2 zijn en niet A2/BI zo­als je in eerste instantie zou denken. In een dergelijkgeval moeten ook de akties die bij de twee overgangenhoren samen gevoegd worden in de nieuwe overgang.

238

parallellisme

slap 1

Referentielijst

Ij c:ruiae control uit

,- ..... , ' ..... ,.P1~or / be.aak L ~.Lve.!l'I - / beatuur L.- £.I"!i'~

wt~ motor / deakt.ive~ funct.ie / control &aD

'/ '/-fI motor &aD

I

Figuur 7.28: De samen te voegen processen

Rerhaal deze stap tot aIle combinaties van toestandenen overgangen behandeld zijn.

Tenslotte moet nog het paraIlellisme uit de diagrammen ge­haald worden. Een toestandsdiagram waarin twee processentegelijk aktief zijn moet veranderd worden zodat altijd slechtseen van de twee toestanden aktief is.

Een voorbeeld

Ais voorbeeld nemen we twee besturingsprocessen uit een sys­teem voor 'cruise control' van een auto (ontleend aan [Mel­lor, 86]). De twee samen te voegen processen zijn gegevenin figuur 7.28, de toestandsdiagrammen zijn te vinden in fi­guur 7.29.In stap 1 van het algorithme moeten we de twee toestands­diagrammen opnieuw tekenen en eventueel een nieuwe begin­toestand toevoegen. 'Bewaak motor' wordt niet extern geak­tiveerd en blijft dus ongewijzigd. 'Bestuur functie' wordt weIextern geaktiveerd en krijgt daarom een nieuwe begintoestanddie we 'Voor besturing' zul1en noemen. Vanuit deze toestandmoet een overgang met'Aktiveer' als voorwaarde naar de oor­spronkelijke begintoestand ('Besturing is uit') gaan. Verdermoet een overgang van elke toestand naar de nieuwe begin­toestand mogelijk zijn met de voorwaarde 'Deaktiveer'. Retresultaat is in figuur 7.30 getekend. In figuur 7.31 is het

239

motor i8 uit besturinJ ia aan

motor &an

aktiveer 'beatuur func:lie'motor uit

deakliveer 'beatuur func:lie'cruiae c:ontrol aan cruiae c:ontrol uit

motor i8 aan besturinJ i8 uit

Figuur 7.29: De toestandsdiagrammen van de samen te voegen processen

11I voor beaturing

I

aktiveer deaktiveer

Ibeaturing ia &an

I

cruiae c:ontrol &an cruiae c:ontrol uit

Ibeaturing ia uit

I

Ideaktiveer

Figuur 7.30: Ret resultaat van stap 1 vanhet algorithme

Referentielijst

motor i8 uit/voor beaturing

motor aan

motor ia aan/beaturing ia uit

Figuur 7.31: Het diagram na stap 3, eersteiteratie

240

stap 2

stap 9

bemonstering

Referentielijst

begin van het gecombineerde diagram gegeven (stap 2 en deeerste iteratie van stap 3). De nieuwe begintoestand is 'Mo­tor is uitfVoor besturing'. De enige mogelijke overgang is dienaar 'Motor is aanfBesturing is uit', en weI met voorwaarde'Motor aan' (de machine 'Bewaak motor' komt in toestand'Motor is aan', de machine 'Bestuur functie' komt in de toe­stand 'Besturing is uit' doordat bij de overgang in 'Bewaakmotor' de besturing geaktiveerd wordt).Vanuit de toestand 'Motor is aanfBesturing is uit' zijn tweeovergangen mogelijk:

1. Met het event 'Motor uit' komt de machine weer in debegintoestand terecht. Merk op dat deze overgang in'Bewaak motor' de aktie 'Deaktiveer "Bestuur functie'"ten gevolge heeft. In figuur 7.29 is te zien dat dit opzijn beurt weer de aktie 'Deaktiveer "Bestuur functie'"tot gevolg heeft, zodat het diagram weer in de toestand'Motor is uitfvoor besturing' terecht komt.

2. Met het event 'Cruise control aan' komt de machine 'Be­stuur functie' in de toestand 'Besturing is aan', 'Bewaakmotor' blijft in dezelfde toestand. Er is nu een nieuwetoestand 'Motor is aanfBesturing is aan'. Ret resultaatis in figuur 7.32 gegeven.

Door voor de derde keer stap 3 uit te voeren ontstaat fi­guur 7.33, het eindresultaat van het algorithme.

Toewijzing van tijd-continue processen

Met een digitale computer is het niet mogelijk om continueen bepaald proces uit te voeren. Tijd-continue flows moetendan ook bemonsterd worden door een proces dat periodiek ge­aktiveerd wordt. De minimale herhalingsfrequentie kan metbehulp van omgevingsrandvoorwaarden bepaald worden.In principe wordt elk periodiek proces aan een aparte taaktoegekend. Ais dit echter betekent dat teveel van taak ge­wisseld moet worden, kan een aantal periodieke processen sa­mengevoegd worden in een taak, die met de frequentie van het

241

1I motor wt/voor beaturing I

motor aan motor wt

I motor aan/be.turing i. wt Icrui.e control aan

I motor aan/be.turing i. aan I

Figuur 7.32: Ret diagram na stap 3,tweede iteratie

1I motor wt/voor beaturing I

motor aan motor wt

Imotor aan/beaturing ia wt I

crui.e control aan crui.e control wt

I motor aan/beaturing ia aan IImotor wtI

Figuur 7.33: Ret eindresultaat

synchronisatiestore

Referentielijst

proces met de kortste periodetijd herhaald moet worden. Om­dat binnen een taak processen sequentieel uitgevoerd worden,is een besturing noodzakelijk om de processen om de beurt teaktiveren.Als nu bepaalde processen binnen een taak gedeaktiveerd kun­nen worden onafhankelijk van de rest van de processen wordtde situatie iets ingewikkelder. Een mogelijke oplossing is hetgebruik van een store waarin per proces een boolean beschik­baar is om aan te geven of het betreffende proces geaktiveerdmag worden of niet.Merk op dat het belangrijk is om besturingsprocessen van da­taprocessen te scheiden. Neem als voorbeeld een proces dateen event herkent, een proces dat als gevolg van dat event ge­aktiveerd wordt en een besturingsproces dat aan een anderetaak toegekend is. Als het event optreedt, moet de event­herkenner dit aan de besturing melden die op zijn beurt deboolean van het dataproces van waarde moet veranderen. Retis beter om de eventherkenner in zo'n geval toe te kennen aande taak waaraan de besturing toegekend is. Rierdoor wordtde communicatie tussen taken verminderd.

242

lage aankomst­frequentie

wachtrijmechanisme

extra interfaces

Referentielijst

7.3.6 Toewijzing van tijd-discrete proces­sen

Taken waaraan tijd-discrete processen zijn toegekend moetengeaktiveerd worden zodra data voor een proces beschikbaarIS.

Er zijn twee situaties waarin we een geldige implementatiek:rijgen:

1. De aankomstfrequentie van data is laag genoeg zodatvoldoende tijd beschikbaar is om een responsie te geven.In dit geval zal het proces binnen een taak een lees­aktie uitvoeren om de data te verkrijgen en vervolgensgedeaktiveerd worden totdat de data beschikbaar is.

2. De gemiddelde aankomstfrequentie is laag genoeg en eris een wachtrijmechanisme beschikbaar om inputs opte vangen. In dit geval worden twee taken gedefini­eerd: een taak waarmee de eigenlijke transformatie uit­gevoerd wordt (de essentiele taak) en een taak waarmeede wachtrij beheerd wordt. Heide taken voeren nu eenlees-aktie uit. De wachtrij-taak wordt geaktiveerd alsdata arriveert, het data verwerkende deel als de wacht­rij niet leeg is.

7.3.7 Het modelleren van interfaces

Door het verdelen van het conceptueel-model over processorenen taken ontstaan extra interfaces die gemodelleerd moetenworden.Daarnaast moeten dataflows uitgewerkt worden:

• De vorm van data moet gemodelleerd worden.

• In twee communicerende taken moeten besturingspro­cessen opgenomen worden om ervoor te zorgen dat dedata in de goede volgorde wordt getransporteerd.

243

synchronisatie

data en prompt

Referentielijst

x~~-~~

Figuur 7.34: Twee communicerende taken

,..- ...... , /- ...... ,X __~ X:. _'beltuUl' L _ Y _ - y - _ 'beatuUl'L __

treeCft op _ _ _ laanbiedelt treedi" op _ _ _ ~0D.IlIm~

'1 ... _( '1 ... _'1

-~i'~""'"'- -.....~.....".--Xd"~_~Y:'~

Figuur 7.35: Synchronisatie van dataflows tussen twee taken

Synchronisatie van dataflows

Als twee taken via een dataflow communiceren is synchroni­satie nodig. De twee taken in figuur 7.34 communiceren viadataflow Y. Deze dataflow is tijd-discreet en bestaat daaromeigenlijk uit twee onderdelen: de data zelf en een prompt dieaangeeft dat er data beschikbaar is. Door gebruik te makenvan een store en de prompt kunnen we voor synchronisatiezorgen. De oplossing is in figuur 7.35 gegeven. Ret toestands­diagram voor de 'aanbieder' is in figuur 7.36 gegeven. De wait­en signal-operaties zijn de gebruikelijke semafoor-operaties.Bij dit alles moet opgemerkt worden dat dit soort synchroni­satie eigenlijk een taak van het operating system is. Als eenmultitasking operating system beschikbaar is hoeft de syn­chronisatie niet specifiek in het model opgenomen te worden.

Synchronisatie van toegang tot opgeslagen data

De store in de vorige paragraaf werd gebruikt als wachtrij. Detoegang ertoe werd via semafoor-operaties in de communice­rende taken gesynchroniseerd. Als twee taken gebruik maken

244

opgeslagen data

prioriteit

Referentielijst

X opgetreden

alttiveer aIlDbieder

klaardeaktiveer aIlDbiederulIlal(Y)wait(X)

Figuur 7.36: Ret toestandsdiagram van de 'aanbieder'

van opgeslagen data in een 'normale' store (dus geen wachtrijmaar een verzameling gegevens) kan de toegang tot de gege­vens ook met behulp van semaforen gesynchroniseerd worden.In dit geval zijn binaire semaforen al voldoende.

Synchronisatie van besturing

Twee besturingsprocessen die vanuit verschillende taken metelkaar communiceren geven grote synchronisatie problemen.Neem het volgende geval (zie figuur 7.37). Proces A gene­reert een event R als P optreedt. Proces B reageert op R engenereert afhankelijk van andere condities een event S. Als Aevent S ontvangt verandert de reaktie op Q. Het probleem is I'

nu dat het niet ontvangen van S niet altijd aangeeft dat Sniet verzonden is. Het kan ook zijn dat B onderbroken werdvoordat S gezonden kon worden. Er zijn drie mogelijke oplos­smgen:

1. B krijgt een hogere prioriteit dan A. Deze oplossingwerkt niet in aIle gevallen; het zou voor kunnen komendat A dan helemaal niet meer uitgevoerd wordt. Alseen derde proces bij de beschouwing betrokken wordt

245

eventstore

samenvoegen

scheidingdatafbesturing

Referentielijst

J: -" - ... ~ R ~ - ....... _

I It. I I B II I I I

- - ".. - - - - - - ~ ,,- ..Q ... - s ... _'

Figuur 7.37: Synchronisatieproblemen bij besturingsproces­sen

P -... R - ...--" ~------~ .... -I I S Ie.est I \\ It. r-----' B I

-- Q- - ".. - - - .- - - .\, ,,- ..- - ...... - S nJet ...... -le.est

Figuur 7.38: Synchronisatie met een eventstore

zou het zeUs zo kunnen zijn dat het onmogelijk wordtom prioriteiten toe te kennen.

2. Breid het diagram uit met een eventstore om Q op tekunnen slaan en een eventflow waarmee aangegeven kanworden dat S niet gegenereerd zal worden. Proces Amoet nu wachten tot een van de events'S is gegenereerd'of'S is niet gegenereerd' ontvangen wordt. De nieuwesituatie is in figuur 7.38 weergegeven.

3. Voeg de twee processen samen tot een enkel proces.Deze oplossing is nogal rigoreus maar werkt weI altijd.

7.3.8 Het vertalen van een netwerk in eenhierarchie

Bij de vertaling van een stukje DFD in een hierarchie is hetbelangrijk om de volgende zaken voor ogen te houden:

• Het besturingsdeel en het data-transformatiedeel zijn inhet conceptueel-model opzettelijk uit elkaar gehouden.

246

scheidingtransformatie/implementatie

snel flowssplitsen

besturingsproces

toestandstabel

Referentielijst

Ret is belangrijk om deze structuur bij het modellerenvan modules te bewaren.

• Ret transformeren van data op zich moet gescheidengehouden worden van implementatie handelingen als hetformateren van datastructuren, het transporteren vandata en dergelijke. Ret doel hiervan is de uit te voerentaak af te schermen van implementatie beslissingen.

• Objecten die om een of andere reden gebundeld op de­zelfde dataflow op het DFD voorkomen maar apart wor­den verwerkt moeten zo snel mogelijk uit elkaar gehaaldworden. Ais een van de objecten verandert heeft dat zoweinig mogelijk invloed op de rest.

Het bovenste niveau van de hierarchie

De top van de hierarchie verzorgt de besturing van de akti­viteiten van een taak. Ais binnen een taak een besturings­proces aanwezig is wordt dit het bovenste niveau. Processendie rechtstreeks door het besturingsproces geaktiveerd wordenvormen het volgende niveau van de hierarchie.Ais een taak geen besturingsproces heeft, moet er een gemaaktworden. Dit proces moet er voor zorgen dat de andere pro­cessen geaktiveerd worden met in acht neming van volgordebeperkingen die door het DFD opgelegd worden.

Het vertalen van toestandsdiagrammen

Er zijn twee gestructureerde manieren om een toestandsdia­gram om te zetten in een stukje module-hierarchie.

1. Ret toestandsdiagram kan omgezet worden in een tabelwaarin voor elke toestandsovergang opgenomen zijn: devoorwaarden die moeten gelden, de te ondernemen ak­ties en de volgende toestand. De uitgangstoestandenstaan horizontaal opgesomd, de gebeurtenissen die over­gangen veroorzaken staan vertikaal. Op elk kruispunt

247

hoofdmodule

Referentielijst

staat een 'volgende toestand/aktie' paar. De aktie iseen foutmelding als de toestandsovergang onmogelijk is.Merk op dat deze machine deterministisch is; voor elketoestand en event is een volgende toestand en een aktiegedefinieerd. Bij de tabel hoort een stukje programmaom hem te doorlopen. Dit programma zou er als voIgtuit kunnen zien:

MODULE fDoorloop_toestandsdiagram'Lokaal: begin~odule, begin_toestand, module,

voorwaarde, toestandBEGIN

module:=begin~odule

toestand:=begin_toestanddo forever

voer_aktie_uit (module)lees_voorwaarde (voorwaarde)module:= volgende~odule (voorwaarde,

toestand)toestand:= volgende_toestand (voorwaarde,

toestand)enddo

ENDENDMODULE

De termen in het bovenstaande betekenen:

module de module is de naam van het proces dat uit­gevoerd wordt.

voer_aktie_uit de module 'voer..aktie_uit' stopt het opdat moment aktive proces en aktiveert het proces'module'.

lees_voorwaarde de module 'lees_voorwaarde' bepaaltof een event opgetreden is en geeft de naam daar­van terug.

2. De tweede strategie gebruikt een hoofdmodule die af-

248

nadere detaille­rmg

transformatieanalyse

Referentielijst

hankelijk van de toestand een andere module aanroept.Voor elke toestand is een module beschikbaar die be­kijkt welk event optreedt. Deze module stopt dan hethuidige aktieve proces, bepaalt de volgende toestand engeeft die door aan het hoofdproces. Dit roept op zijnbeurt weer een ondergeschikte module aan om de vol­gende toestand uit te voeren.

Ais geen besturingsproces beschikbaar is, of als een proceste globaal gedefinieerd is om implementatie mogelijk te ma­ken, moeten we op een andere manier te werk gaan. Vaakmoet een proces verder gedetailleerd worden dan nodig wasvoor het conceptueel-model; er moeten implementatiedetailstoegevoegd worden. Het in figuur 7.39 gegeven proces bijvoor­beeld, bepaalt het gemiddelde van twee gemeten percentagesen schrijft dit naar een beeldscherm. Dit proces kan uitge­werkt worden zoals in figuur 7.40 gegeven. Merk op dat ditproces gedetailleerd is door processen toe te voegen die inputsvoorbewerken en een proces dat de output verzorgt. In hetalgemeen kan gezocht worden naar processen die:

1. data uit de omgeving inlezen

2. data transformeren naar een funetionele vorm

3. funetionele data transformeren naar een outputformaat

4. de echte transformatie (uit het conceptueel-model) uit­voeren

Vaak is het mogelijk om een flow te splitsen in samenstellendedelen, die dan apart verwerkt kunnen worden. Dit levert ookeen detaillering van het hoofdproces op.Nu moet nog van het nieuwe dataflowdiagram een hierarchiegemaakt worden. Om dit te bereiken zijn twee technieken be­schikbaar: transformatie- en transaktie analyse.Bij transformatie analyse is het nodig een 'centraal proces' tedefinieren. Dit is een proces dat input in de meest essentielevorm ornzet in output in de meest essentiele vorm. Dit houdt

249

Figuur 7.39: Ret DFD van het conceptueel-model

min.percentage

max.percentage

gcmiddeldpercentage

fout

Figuur 7.40: Ret DFD van het implementatiemodel

fout

Referentielijst

fout

gem. %

~.%

ormate .voor display

250

KhrijfnAar

diaplay

min. %

lee.min. %

t seachaaldb min."

lee.seachaaldmin. ,.

pchaaldmin. %

.chaalmin. ,.

formateer% yoordiaplay

1Semiddeld"

di.playsemiddeld,.

scf'orm.

/ ~%lcf'orm.~"'L.---...,

%

Figuur 7.41: Structure chart: proces le­vert data aan een hoger niveau

Figuur 7.42: Structure chart: proces ge­bruikt data van een hoger niveau

Referentielijst

in dat processen die inputs valideren of outputs formaterengeen centrale processen kunnen zijn. Uit de overige processenkunnen we een willekeurige kandidaat kiezen (bijvoorbeeld het'Middel alcoholpercentages' proces uit figuur 7.40). De eersteversie van de hierarchie bestaat nu uit twee niveaus: het bo­venste niveau wordt gevormd door een module met de naamvan het oorspronkelijke proces (bijvoorbeeld 'Display alcoholinformatie'). Ret tweede niveau bestaat uit het centrale pro­ces samen met aIle processen die er direct mee communiceren.Aile processen behalve het centrale hebben nog rninstens eenextra niveau nodig. Op dit niveau worden modules voor hettransporteren van data toegevoegd, samen met alle processendie:

• output leveren die door het proces op het hogere niveaugebruikt wordt, of

• data gebruiken die door het proces op het hogere niveaugeleverd wordt.

Een voorbeeld van beide gevallen is in figuur 7.41 en 7.42 gege­ven. Een voordeel van een structure chart die op deze manier

251

transaktieanalyse

Referentielijst

tot stand gekomen is, is dat bet centrale proces geisoleerdwordt van specifieke i/o-omgevingen.

Vaak is bet nodig om een aantal onafhankelijke processenaan dezelfde taak toe te kennen. Een voorbeeld biervan iseen verzameling periodieke processen die eigenlijk ieder in eenaparte taak zouden moeten zitten, maar die zijn samenge­voegd om bet aantal taken te beperken. In dit geval is betvoor het implementatiemodel voldoende om een proces toe tevoegen dat zorg kan dragen voor een tijdige aktivering van demodules in de taak.Een tweede geval treedt op als data, afhankelijk van een be­paald kenmerk of de waarde van een semafoor, bewerkt moetworden door verschillende processen. In dit geval wordt eenzogenaamd 'transaktie centrum' toegevoegd. Dit proces be­paalt welk proces de binnenkomende data moet verwerken.Het transaktie centrum vormt nu de bovenste laag van dehierarchie met de oorspronkelijke processen op bet tweede ni­veau. Transformatie en transaktie analyse sluiten elkaar nietuit en kunnen dan ook goed in kombinatie gebruikt worden.

7.3.9 Verfijning van de structure chart

Met de metboden uit bet vorige boofdstuk kan een eerste ver­sie van de structure cbart gemaakt worden. Over bet alge­meen zijn nog verfijningen en optimalisaties nodig die bereiktkunnen worden door te letten op de koppeling van modu­les onderling en de eenduidigheid, complexiteit en algemenebruikbaarheid van de individuele modules.

Koppeling

Twee modules kunnen gekoppeld zijn doordat de ene de an­dere aanroept, door een gemeenscbappelijk datagebied of zelfsdoor een 'goto'-statement. Over bet algemeen geldt: boe la­ger de koppelingsgraad boe overzicbtelijker en efficienter bet

252

groeperen

datagebied

besturingssignalen

Referentielijst

geheel zal zijn. Om de koppeling te reduceren kan gebruikgemaakt worden van de volgende technieken:

• Data-elementen groeperen in grotere structuren. Ditmoet gezien worden als het samenvoegen van losse vari­abelen in grotere structuren (het reduceren van het aan­tal parameterpijItjes). Het is niet zo dat alle variabelenzo maar gecombineerd kunnen worden en aan aIle mo­dules beschikbaar gesteld moeten worden. Het samen­voegen is alleen geoorloofd als de modules die de datater beschikking hebben ook van het grootste deel van deelementen ervan gebruik maken. Bijvoorbeeld: vijf va­riabelen samenvoegen in een structuur en die doorgevenaan modules die maar twee van die variabelen gebrui­ken, maakt de boel alleen maar onduidelijker. Daar­naast mogen alleen verwante variabelen samengevoegdworden (weer vanwege de duidelijkheid, die hier tot ui­ting zal komen in de naamgeving, hoe moet je bijvoor­beeld een structuur noemen waarin de cursorpositie ende achternaam van een systeemontwerper zijn samenge­voegd?).

• Als data in een bepaalde module gegenereerd wordt engebruikt wordt in een module die niet direct met deeerste verbonden is, moet data door een aantal tussen­liggende modules gestuurd worden. Dit kan erg onover­zichtelijk worden, vooral als de tussenliggende modulesniets met de data doen. Een oplossing is de data opslaanin een datagebied dat voor beide modules toegankelijkis.

• Besturingssignalen zijn vaak overbodig. In figuur 7.43geeft de waarde van 'functietype' (zie linkertekening)weer welke functie de module 'Display of verstuur toe­stand' uit moet voeren. Een betere oplossing is rechtsin de figuur gegeven. De logica van het nemen van debeslissing, welke functie uitgevoerd moet worden is in

253

Figuur 7.43: Links: overbodige besturingssignalen, rechts eenbetere oplossing

diaplayof Yeratuur

toeatand

een functie

een bladzijde

specifiekefunctie

Referentielijst

het eerste geval dubbel uitgevoerd, in het tweede gevalgeconcentreerd in een module.

Eenduidigheid

Voor de overzichtelijkheid van het model is het belangrijk dateen module niet meer dan ren functie uitvoert. Dit wil nietzeggen dat een module geen deelfuncties kan hebben, het be­tekent echter weI dat de functie met een naam beschrevenmoet kunnen worden. De rechter module in figuur 7.43 is dusook om deze reden niet goed: 'Display of verstuur toestand'geeft duidelijk twee functies weer.

Complexiteit

Ben module die meer dan een bladzijde code nodig heeft iswaarschijnlijk te complex (onoverzichtelijk doordat je niet al­les tegelijk kunt bekijken). Dit is natuurlijk geen absolutegrens maar een richtlijn. De complexiteit van een module kanverminderd worden door de logica te scheiden van het uitvoe­rende deel (binnenhalen en versturen van gegevens, rekenen).

Statiegeldflessen of kartonnen pakken

De mate waarin een module opnieuw beschikbaar is in an­dere toepassingen is een laatste criterium waarop een struc­ture chart beoordeeld kan worden. Om makkelijk opnieuw

254

Referentielijst

bruikbaar te zijn, moet de functie van een module zo specifiekmogelijk zijn, het gaat dus vaak om modules op het laagsteniveau van de hierarchie. Vaak wordt een extra parameteraan een module toegevoegd om bruikbaarheid in andere toe­passingen of plaatsen in het systeem mogelijk te maken. Ditgeeft al snel problemen: de functie van de module wordt metelke extra parameter weer onduidelijker.

255

Hoofdstuk 8

Literatuur

Meer literatuur over dit onderwerp is te vinden in:

[Hammer, 1990] Hammer, D.K., K.M. van Hee, Fasering endocumentatie in software engineering, Informatie jaar­gang 32, nr. 2, pag. 105 tim 232, 1990

[Kloprogge, 1990] Kloprogge, 1., Ontwerp van een besturings­systeem voor de FALe, 1990 TV Eindhoven, vakgroepER, afstudeerverslag

[Mellor, 1986] Mellor, S.J., T. Ward, Structured Developmentfor Real- Time Systems, Volume 1, 2 and 3, 1986 Pren­tice Hall, bsa: ddt 85 war

[Yourdon] Yourdone, E., Afodern Structured Analysis, 1989Prentice Hall, Inc. bas: dfx 89 you

257