Post on 04-Mar-2018
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 resultaten 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 Technology 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 circumstances.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 combinaties 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 instellingeI;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 foutencorrigeren 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 verbeteren 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 prograrnmatuur 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 moeten 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 kursussen 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 besturingssystemen.
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 worden.
2. Tijdens de definitiestudie worden de eisen die aan het systeem gesteld worden vastgelegd.
11
3. Tijdens het basisontwerp wordt eerst een globaal en daarna een gedetailleerder funetioneel 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 toegevoegd, 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 conceptueelmodel 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 projectdocumenten 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 documentatie 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 krijgen. 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 bestaande methoden waarmee een conceptueel- en implementatiemodel opgesteld kunnen worden. Voor SDM geldt dit in mindere mate, omdat de scheiding tussen functionele 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 gebruikersgemak; 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 omstandigheden 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, controleerbaarheid, integriteit (bescherming tegen ongeoorloofd gebruik) en gebruikersgemak.
4.1.2 Modulariteit
Om te kunnen voldoen aan de criteria uitbreidbaarheid, herbruikbaarheid en compatibiliteit 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 onverwachte 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 deelproblemen 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 systeem) 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 specificaties 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 (rabuustheid).
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 modules 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 worden. Het diagram is opgebouwd uit processen (transformeren inputs in outputs), dataflows(geven bewegende data weer), stores (geven opgeslagen data weer) en terminators (representeren 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 verdeeld 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 opbouw 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 structure 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 analyseen ontwerpmethode beschreven die, uitgaande van oude probleemoplossingen een nieuwsysteem ontwerpt. Hierbij wordt gebruik gemaakt van datafiowdiagrammen, datadictionaries 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 uitgevoerd 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 implementatiemodel.Het conceptueel-model volgens \Vard en Mellor bestaat uit een omgevings- en een gedragsmodel.
Het omgevingsmodel is opgebouwd uit:
• een doelbeschrijving: een kort stukje tekst waarin het doel van het systeem beschreven 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 overeen met een conceptueel-model) en het architeetuurmodel (komt overeen met een implementatiemodel). 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 niveau 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 vergelijkbaar, 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 datafiowdiagram volgens Hatley en Pirbhai
&-i~ _r-iI
01 6---Figuur 4.6: Het bijbehorende besturingsflowdiagram
fiowdiagram getransporteerd wordt. Typische namen in een verbindingsdiagram zijn bussen 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 besturingsmodel van figuur 4.4. In deze figuur zijn ook nog blokjes 'Gebruikersinterface', 'Inputverwerking', '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 objectrelatie 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 arrayimplementatie 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 belangrijkste argument voor data-georienteerde methoden. Bijkomende argumenten zijn compatibiliteit (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 kunnen 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 argumenten 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 functie 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 objectgeorienteerd ontwerp gegeven worden:
Objectgeorie'nteerd ontwerp is de constructie van software systemen in de vorm van implementatie 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 programma structuurdiagram.
3, Maak een lijst van alle operaties van een gekozen programmeertaal die op de diagrammen 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 datageorienteerde 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 voegen 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 dataflowdiagram)
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 ondersteunende 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 nadelen 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 objectgeorienteerd ontwerpen ook een uitstekende kandidaat voor toepassing in real-time omgevingen. 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 gebruiker 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 datafiowdiagrammen het gebruik van technieken van objectgeorienteerd ontwerpen niet uitsluit. Deze technieken zouden gebruikt kunnen worden om een deel van het systeem tespecificeren, namelijk het deel dat gebruik maakt van datastructuren. Op deze manier ontstaat 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 beschikbaar is voor workstations zoals bijvoorbeeld een Sun of een VAX-workstation. Deze programma's bieden niet aIleen ondersteuning bij het maken van plaatjes (dataflowdiagrammen, 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 dergelijk 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 mogelijkheden 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 uitgevoerd. 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 harddisk 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 eontroleren 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, Yourdon, Gane/Sarson), waarbij opgemerkt moet worden dat het processor- en het taakmodelontbreken.
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 probleem 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 programma 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, 0340665530
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 programmatuur 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 PCversies, waaronder configuratie management, codegeneratie en desktop publishing. Daarnaast 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. Contactpersoon 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 wensen 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 implementatiemodel, 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 werken). 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 gebruiken 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 uitgewe: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 gemodelleerd 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 Ievenscyclus 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 instruetiemateriaal.Voor Yourdon en \Vard/Mellor is geen geschikt (betaalbaar en praktisch bruikbaar) instructiemateriaal 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 worden. 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 analysemethode 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 concentreren is lijkt het zinvol om nader onderzoek te doen naar de toepassingsmogelijkhedenervan.Een ander aandachtspunt is het systematisch testen van programmatuur. Over dit onderwerp 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 Development (Second Edition)., 1989 IEEE Computer Society Press, bse: dfb 89 jsp
[Eilers, 1989] Eilers, H.B., Systeemontwikkeling op kleinere schaal met SDM., 1989 Academic 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 engineering, Informatie jaargang 32, TIr. 2, pag. 105 tim 232, 1990
[Hice, 1988] Hice, G.F., SDA! for technical information systems., 1988 Pandata BV, Rijswijk
[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 gestructureerd ontwerpen van software systemen. Een aantaldaarvan zijn gericht op administratieve toepassingen, anderen zijn meer geschikt voor real-time systemen. \Ve zullenons hier op deze laatste klasse van systemen concentreren.Dit artikel beschrijft een aantal grafisch-georienteerde methoden, ontleend aan Yourdon en Ward/Mellor (zie [Yourdon,1989] en [Mellor, 1986]). We zullen eerst de gebruikte notatie en terminologie van deze methoden uitleggen en daarnapas ingaan op het ontwikkelen van programmatuur. TenslottevoIgt een referentielijst waarin alle termen en technieken opgenomen ZlJn.
5
Hoofdstuk 2
Het Software QualitySystem
SQS is een zogenaamd lifecycle model, dat wi! zeggen een methode waarmee de ontwikkeling van het systeem beschrevenkan worden vanaf het moment waarop iemand de behoefte eraan constateert tot op het moment waarop besloten wordt hetsysteem te vervangen. Het model schrijft voor welke aktiviteiten uitgevoerd moeten worden en wat voor soort documentatie 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 eenvoudig 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
conceptueelmodel
Hoofdstuk 3
Het lezen van grafischesysteemmodellen
3.1 Inleiding
SQS schrijft voor dat er een conceptueel-model en een implementatiemodel gemaakt moeten worden. Dergelijke modellen 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 Yourdon 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 maken 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 functionaliteit 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 modules 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 hoofdstukken 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 methode
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 deelneemt. 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 geproduceerd worden (de interaktie met de omgeving),
3. welke deelfuncties uitgevoerd moeten worden om de totale systeemfunctie te verwezenlijken,
4. welke data binnen het systeem getransporteerd en opgeslagen 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 welke 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 gedragsmodel. 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 dataflows binnen bet systeem geeft,
Ret lezen van grafische systeemmodellen 12
• processpecificaties die een tekstuele beschrijving van processen geven,
• object-relatie diagrarrnnen die de structuur van opgeslagen 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 buitenwereld 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 contextdiagram opgebouwd kan zijn. Bovenstaande aspecten komen in de figuur voor, behalve de opgeslagen data die in paragraaf 3.3.4 beschreven zal worden. Een proces wordt weergegeven 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 schakelaar, 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 output (van een proces af) gezien moet worden. Elke dataflowheeft een naam, behalve in de uitzonderinsgevallen die in paragraaf 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 modelleringstechnieken.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 temperatuur of iets dergelijks aangegeven wordt. Tijd-continue dataflows 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 terminators 'Toetsenbord', 'Beeldscherm' en 'Disk'. Ret procesheeft 'Toetsaanslagen' en 'Receptin' als input-dataflows en'SchermJrifo' en 'Recept-uit' als output-dataflows. Aile dataflows 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, waarbij nog niet is vastgelegd hoe de gebruiker die wens kenbaar 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 omhoog 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 invoerapparaat (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 funeties 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 informatie 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 wijzigt.
• 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 dubbele 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 worden. 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', 'Verwijder_opdracht', 'Disk_opdracht' en 'Receptnaam'.Dat wilzeggen dat 'Toetsaanslag' niet een object was maar een verzameling van de bovengenoemde objeeten. Op het contextdiagram 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 aangegeven 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 samengesteld 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 objecten 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 constructies:
1. + : samenstelling
2. (tekst): het deelobject tekst is optioneel
3. ondergrens{ tekst}bovengrens : nul of meer keer deelobject tekst, ondergrens en bovengrens zijn optioneel
4. [keuzel} I keuze2 I ... I keuzfn]: kies ren van de alternatieven 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 "positie=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 afweZIg.
• Iteratie wordt weergegeven door een object tussen accolades te plaatsen. Er kan een onder- en bovengrensaangegeven worden: de ondergrens wordt voor de openingsaccolade geplaatst, de bovengrens komt achter desluitingsaccolade. Beide grenzen zijn optioneel en zouden 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' symbool, 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 gedefinieerd 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 objecten. In de volledige datadictionary moeten ook deze objecten gedefinieerd worden, net zo lang totdat het niveau vanconstanten bereikt wordt. Een voorbeeld hiervan is de flow"RecepLkarakter" , in eerste instantie gedefineerd als: "Recept..karakter = [Letter I Cijfer I Scheidingssymbool]". Dedrie objecten "Letter", "Cijfer" en "Scheidingssymbool" kunnen 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 gebruikt wordt, maar er zijn genoeg voorbeelden denkbaar vanniet-triviale gevallen.Opmerking: het '+'-teken is niet helemaal eenduidig gedefinieerd. Er zijn twee betekenissen:
1. Ben flow bestaat uit twee delen die tegelijk aanwezigmoeten zijn, bijvoorbeeld een achternaam en een straatnaam 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 uitgewerkt worden met behulp van diagrammen op een lager rnveau 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 processpecificaties gebruiken. Er zijn drie veelgebruikte specificatietechnieken:
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, dubbelzinnig), 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 eenvoudige gevallen, maar dan voldoet gestructureerde taal natuurlijk ook.Er is geen goede reden om een van de drie methoden te kiezen 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 beperkingen 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', 'KOLOMl', 'REGELl', 'FOREVER') en dan nog wat niet nader gespecificeerde zaken als 'OpenJile', 'Lees..recepLvanJile'.Voor deze laatste 'fundies' geldt dat ze vaak erg implementatie-afhankelijk zijn, zodat een specificatie ervan niet in eenconceptueel-model thuis hoort. Ze kunnen echter toch gebruikt 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 REPEATstatements.
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 plaatsvindt.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 moeten 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 ondernomen 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 voorwaarden 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 horizontaal aIle voorwaarden die van toepassing zijn. Op elkerij komt nu een aantaI kruisjes die weergeven aan welke voorwaarde 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 modelleren. 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 ingewikkelde 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 conceptueel-model en een programma. Het bestaat uit drie onderdelen:
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 computer 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 implementatiemodel 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 opstellen 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 multitasking 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 figuur 3.10 is een voorbeeld gegeven. 'Taak1' en 'Taak2' vormenhet bovenste niveau van de hierarchie, waarbij Taak1 onderverdeeld is in de deeltaken 'Taak1.1" 'Taak1.2' en 'Taak1.3'.Dit betekent niet dat Taak1.2 en Taak1.3 tegelijk in uitvoering kunnen zijn, maar dat Taak2 parallel aan een van de taken 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 besturingsproces
,-------, 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, moeten we ervoor zorgen dat de processen van een dergelijke taaksequentieel uitgevoerd worden. Om dit te bereiken is een besturing nodig waarmee de processen om de beurt geaktiveerdworden. In figuur 3.12 is een besturingsproces met twee gewone processen getekend. Het besturingsproces wordt weergegeven door een gestippelde cirkel. De nummering van besturingsprocessen is afhankelijk van die van dataprocessen. Bijvoorbeeld, 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 weergegeven door gestippelde pijlen. In figuur 3.12 is te zien dat debesturingsflows naar de twee processen wijzen. In werkelijkheid zijn de flows signalen aan een operatingsystem waarmeewaarmee aangegeven wordt dat een proces geaktiveerd of gedeaktiveerd 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 voorbeeld 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 komen naast de pijl te staan met daaronder een horizontalestreep en een aantal akties.
Ret lezen van grafische systeemmodellen 39
overzichtelijkeprogrammastructuur
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 programmastructuur te maken. Daarom is toch een taakmodelgemaakt (zie figuur 3.14).In deze figuur zijn vier taken te zien: 'Disktaak', 'Cursortaak', 'Wijzigtaak' en 'Schermtaak'. Behalve de taken is ookhet proces 'Evalueer toetsaanslag' toegevoegd. Dit is noodzakelijk omdat het toetsenbord aIleen toetscodes levert en nietweet welke code een opdracht voorstelt en welke een onderdeel 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 geworden. 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 worden.
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 disktaak (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 figuur 3.17.
Opdracht 3.16
Opdracht 9.17
Wat is er fout met dit besturingsproces?
En wat is er fout met dit besturingsproces?
,,-',--! 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 worden 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 specificaties 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 programmeertaal).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 aangeroepen 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' teruggeeft aan 'Module 1'.Een besturingsparameter wordt gebruikt om besturingsinformatie 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', 'Wijzig 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 uitgewerkt 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 reoeptregel
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 module gespeeificeerd moet worden, in tegenstelling tot processen waarvoor een diagram op een lager niveau ook als speeificatie kan gelden. De mate van detaillering van deze specificatie hangt af van de taal waarin het programma geschrevenzal worden: een taal als C of Pascal vraagt een rninder gedetailleerde specificatie dan een assemblertaal. De modulespecificaties 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 dictionary. Er moeten nog een aantal zaken toegevoegd worden:
• De representatie van de data moet gekozen worden (bijvoor~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 outputs.
De terminator rechtsboven heeft geen naam en communiceert 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 informatie.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 informatie 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, waarmee 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 figuur 1, heet deze figuur 'Figuur 1.3'.
Deze processpecificatie in gestructureerde taal mist de onderdelen 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 postconditie 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 toestandsdiagram. 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 module 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 hoofdstukken beschreven methoden, SQS en de ontwerpmethoden vanWard/Mellor en Yourdon, een eenvoudig systeem ontwerpen,De bedoeling is het illustreren van de geintroduceerde concepten, De fasen van SQS zullen steeds kort toegelicht worden,voor een beschrijving van de andere modellen wordt verwezen 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 komen 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 omgeving 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 gebruikelijke scheidingssymbolen) in kunnen voeren via eentoetsenbord.
2. De gebruiker moet een cursor door de tekst kunnen bewegen met behulp van de gebruikelijke toetsen.
3. De resultaten van het type-werk van de gebruiker moeten 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 maximaal tachtig karakters lang zijn.
7. De documentatie moet volgens de SQS methode geproduceerd 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 uitgevoerd 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 ontwikkelmethoden.
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 mogelijk 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 gekozen. Figuur 4.1 geeft het contextdiagram weer.De flows op dit diagram betekenen het volgende:
Toetsenbord.Jnvoer Toetsenbordjnvoer is een verzamelnaam voor gegevens die via het toetsenbord ingevoerdkunnen worden. Ret gaat hier om letters en cijfers waaruit 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 verzameling regels (maximaal duizend) van maximaal tachtig 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 omhoog 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 treden 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 produceert 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 aangegeven 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 gebruikt 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 bovenaan 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 'Recept 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 verschijnt 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 dergelijk 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 functies' 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 opgedeeld wordt in karakters die tot de tekst behoren en toetsaanslagen die het verwijderen van regels en karakters, hetverplaatsen van de cursor of het opslaan/inlezen van recepten ten gevolge hebben. De flow 'Toetsenbordinvoer' wordtverdeeld in de flows 'Verwijder.opdracht', 'Recept_tekst', 'Receptnaam', '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-partitioning 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 worden. '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 processen 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 cursorpositie) 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 samengevoegd: '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, karakter naar rechts, naar het eind of het begin van deregel).
2. Verplaatsen naar de regel onder of boven de huidige regel.
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 deelprocessen 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 bijgehouden wordt hoeveel regels in gebruik zijn. 'Regel' en 'AantaLregels' 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 scheidingssymbolen):
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 afhankelijk van de implementatie die voor het opslaan van recepten gekozen wordt. Daarom zijn ze hier niet verder uitgewerkt.Verder is de specificatie al aan de lange kant. Om dat te vermijden 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 zonder processormodel af kunnen. Merk op dat als we inderdaadeen besturing voor de terminators zouden moeten maken, wehiervoor waarschijnlijk insteekkaarten zouden moeten ontwikkelen (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 parallel 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 deaktiveren 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 toegevoegd.
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 werkzaamheden 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 modules 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. Normaal 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 worden, of dat het een opdracht is. Als de gebruiker vraagt omhet lezen of schrijven van een recept wordt de module 'Lees receptnaam'.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 recepetegel
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 overnemen uit de gelijknamige processpecificaties. 'Beheer disk'zelf is zo ~nvoudig dat we deze module niet zullen specificeren. 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 communicatie 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 tekststring terug (of moet de inhoud als tekststring geven in hetgeval van 'Schrijf..regel'). Deze modules zuBen nog meer voorkomen. 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 processen 'Verplaats binnen regel', 'Verplaats over regel', 'Verplaatsscherm' en 'Verplaats boven/onder'
De module 'Wijzig functies'
Ook de specificatie van 'Wijzig functies' kan rechtstreeks overgenomen 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
implementatieonafhankelijk
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 'HersteLregel' 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 implementatie-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 constanten 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 modulespecificaties ingevoerd zijn.
Implementatie van de stores 'Recept' en 'Cursor positie'
Tenslotte moeten we nog de implementatie van de twee storesvastleggen. Voor de cursorpositie kunnen we een globale variabele 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 definieren als een array. Helaas werkt dat op de meeste PC's(onder MS-DOS) niet; de maximale grootte van een datastructuur is 64k. £en oplossing is een array van duizend pointers 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 editor 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 komen met het implementatiemodel. Hieruit voIgt dat als tijdens 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 gedocumenteerd 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 vermelding van het doel, de input, de output en eventuele lokaalgebruikte variabelen. Daarna komt de code waarbij ondoorzichtige constructies zoveel mogelijk vermeden dienen te worden. 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 onderhoud 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 mogelijkheden 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 voegen. *
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 beelscherm, bereik afhankelijk van soort scherm en implementatie. *
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 maximaallOOO 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 scheidingssymbolen. *
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. Vervolgens 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 daardoor te veel karakters op de regel staan, wordt toch een foutmelding 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 'Receptnaam' 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 weergegeYen. Het gaat om een boormachine waarmee gaten in houtenblokken geboord kunnen worden. De blokken worden opgeslagen 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 getrokken wordt.
96
Een opdracht
3. De afvoercHinder duwt het blok rechts van het zojuistgeboorde blok uit de weg en wordt vervolgens weer teruggetrokken.
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 worden voor het einde van de derde boorcyclus ontstaat de situatie met twee blokken op de horizontale transportband, waarvan 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 positieve 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 omgevmg
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 boormachine. Daarom is het architectuur-aspect van de omgevingsanalyse 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 menselijke 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 worden.
2. Als er geen blokken meer zijn moet dit met een waarschuwingslampje aangegeven worden, waarna het systeem 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 geschreven worden, het conceptueel- en implementatiemodelmoeten met de methode van Yourdon ontwikkeld worden.
5. Bij de ontwikkeling van een conceptueel- en implementatiemodel moet gebruik gemaakt worden van een CASEtool.
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 kunnen worden.
Het contextmodel
Ret boorsysteem heeft de boormachine met bijbehorende cilinders, 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 informatie door gegeven wordt. Daarom is het model van figuur 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 boormachine 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 boorcyclus moet gestart worden).
10. De schakelaar st wordt in de stand 'Uit' gezet (de boorcyclus moet gestopt wordt, dus de spanning wordt vanaIle bekrachtigde relais gehaald). Als dit gebeurd ismoet de totale machine weer in de uitgangstoestand gezet 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 uitvoeren. 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 cilinder 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 waarmee een signaal 'Blokken..voorraad' gegenereerd wordt. Ditsignaal krijgt pas een waarde als er echt geen gaten meer geboord 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 getekend.In figuur 4.5 is een mogelijke uitwerking van 'Bestuur boorcilinder' gegeven. De besturing voor de andere cilinders zieter hetzelfde uit. We zien in de figuur twee processen 'Bewaak 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 'Blokken.op' als de spanning van de benaderingsschakelaar p overgaat van positief naar negatief. 'Blokken..aa.ngevuld' wordtgegenereerd in het omgekeerde geval. Met behulp van dezetwee eventflows en 'BOontvangen' kan bepaald worden wanneer het boren gestopt, en wanneer het weer hervat kan worden.
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 schakelaar st in de stand 'Uit' gezet wordt, keert de machine terugnaar de begintoestand. Dit kan vanuit elke toestand gebeuren, 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 gedefinieerd. *
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 moeten nog tekstueel gespecificeerd worden.De cilinders zijn eigenlijk allemaal hetzelfde zodat we kunnen 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 'Bewaak 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 uitgangspositie.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 makkelijkste oplossing is het definieren van een taak voor elk dataproces in figuur 4.4 (behalve de processen die met flip-flopsgeimplementeerd zijn). We kunnen deze taken als interrupthandlers zien, die geaktiveerd worden door een signaalovergang 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 standaardroutine 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 'BOontvangen' dat gegenereerd wordt door de boorcilinder-taak) geaktiveerd 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 geraakt met de terminologie.Ret beschreven voorbeeld gaat over de fictieve Japanse limonadefabriek Limozuki, waarvan we een gedeelte zuBen modelleren.
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 bieden. 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 elkaar geknoopt worden. Dit houdt in dat het systeem een grootaantal aktiviteiten van menselijke operators uit moet voeren.Limozuki produceert drie soorten limonade, Coca-cola, Cassis 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 bepalen 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 beschikbaar, 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 geschoven en zo snel mogelijk aIsnog geetiketteerd.
8. Tenslotte worden de £lessen in een krat gezet dat doorgeautomatiseerde heftrucs op een klaar staande vrachtwagen geschoven wordt.
De operator kan via een terminal informatie krijgen over hetproces in de fabriek en kan aIle lijnen apart of tegelijk aanen uitschakelen.Ret is de bedoeling dat een groothandelaar met zijn vrachtwagen de fabriek in kan rijden en zijn bestelling door kangeven aan het systeem. De £lessen worden dan zo snel mogelijk gevuld en naar de vrachtwagen getransporteerd, waarnade handelaar een seintje krijgt dat hij kan vertrekken. Afrekenen 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 vrachtwagens tegelijk bediend worden.Onderstaande apparatuur staat ter beschikking:
• Een sensor waarmee bepaald kan worden of er nog £lessen in een van de vier containers zitten.
• Een robot waarmee £lessen op een van de twee transportbanden 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 aangegeven 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 besturen.
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 (oververhitting bijvoorbeeld) geheel of gedeeltelijk uit te schakelen.
• 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 automatische kassasysteem betalen.
• De operator moet via een terminal het systeem kunnen overzien. Dit houdt in dat informatie beschikbaarmoet zijn over de toestand van apparatuur en het aantal :£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 dranken in kunnen voeren via de terminal.
• Als het systeem na een calamiteit opnieuw opgestartmoet worden, moet de operator via de terminal informatie 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 hervat kan worden.
• Het management wi! graag periodieke rapporten over deprestaties van het systeem. Deze rapporten moeten automatisch 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 Limozawa 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 schoonmaakmachines, de robot, de transportbanden, de vulmachines, deafsluitmachines, de labelmachine, het transportsysteem tussen 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 bestaat uit een aantal vaste mogelijkheden waarvan we er een
121
bundeling vansignalen
Limozuki
moeten kiezen. Daarnaast geven ze een aantal signalen (labels zijn op, fles is kapot) waarop een automatiseringssysteemzou kunnen reageren. Om de fabriek te kunnen automatiserenmoet het systeem de signalen van de machines opvangen, verwerken en omzetten in stuursignalen voor andere machines.Wat het systeem dus aan het geheel toevoegt is een interpretatie 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 signalen 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 container 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 aantal druktoetsen aangegeven worden welke soort flessenin welke containers zitten.
Schoonmaaksystemen De schoonmaakmachines detekterenwanneer een fles op een van de transportbanden beschikbaar is, gaan over tot het schoonmaken ervan en produceren een signaal waarmee de afloop van het schoonmaakproces aangegeven wordt. Een tweede functie ishet controleren van de toestand van de fles na het schoonmaken (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 transportband 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. Nadat de kroonkurk aangebracht is wordt een signaal gegenereerd, 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 opdracht gegeven heeft. Als er geen opdracht is wordt eensignaal gegenereerd dat aangeeft dat de transportbandstilgelegd moet worden. De machine geeft ook informatie over de voorraad etiketten.
Transport De transportbanden en schakelaars zijn samengevoegd in de terminator 'Transport'. Elke transportband kan gestopt of gestart worden. Er is informatiebeschikbaar over de toestand waarin de band zich bevindt 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 samengevoegd 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 boodschappen worden naar een printer gestuurd. Deze printer 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 vrachtwagen moet parkeren. Door op een knop te duwen kande klant om hulp vragen.
Afvoer Bet afvoersysteem verzorgt het transport van gevulde £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 operator. 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 £lessen 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 zodat het systeem na het optreden van een 'Container isleeg"event op kan houden met het sturen van opdrachten 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 schoongemaakt.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 systeem 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 aangegeven 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 ingewikkeld 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 definieren van een interfacelaag. We kunnen het dataflowdiagramopgebouwd denken uit twee lagen (zie figuur 6.3). De buitenste interfacelaag schermt de rest van het systeem af vande eigenschappen van randapparatuur. Vooral in industrieleomgevingen kan dit van groot belang zijn, omdat bij de besturing 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 opdrachten 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 interface tussen het systeem (dat niet getekend is) en de omgeving.Processen die we verder niet uit zullen werken zijn samengevoegd in het proces 'De rest'.Het is belangrijk om in te zien dat dit diagram geen onderdeel 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 aangepakt 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 terminators.
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: 'Bewaak containers', 'Bewaak robot' en 'Grijp fles' voor het uitvoeren van een opdracht van het systeem. Deze processenen hun inputs zijn getekend in figuur 6.5. De flow 'Container-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 toegevoegd moet worden zijn flows voor de communicatie met het8ysteem en het doorgeven van opdrachten aan de robot. Daarnaast 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 bewerken. De communicatie met de robot gaat via de flow 'Ro-
132
Limozuki
Figuur 6.5: Eerste uitwerking van 'Robot en container besturing'
boLcommando'. Dit signaal kan de waarden 'Reset', (Containernummer, Bandnummer) en 'Stop' aannemen. Containernummer kan de waarden 'Container!', 'Container2', 'Container3' en 'Container4' aannemen. Bandnummer kan de waarden 'Band!' en 'Band2' aannemen. Voordat een volgende opdracht 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 'Robot..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 gevraagd wordt, te synchroniseren moeten we een store 'Fles_voorraad' invoeren. Zodra de voorraad £lessen van een bepaalde soort verandert, past 'Bewaak containers' de inhoudvan 'Fles_voorraad' aan. 'GrijpJies' kan de inhoud van destore uitlezen vlak voordat de uitvoer van een opdracht begint. Dit alles leidt tot een dataflowdiagram van figuur 6.6.
134
funetionerenvulmachine
architectuurbeschrijving
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 signaal 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 beschrijving 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 architectuur 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 bovenstaande 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 halen. 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 processen opleveren: 'Fles vullen', 'Fles controleren' en 'Bewaakvulsysteem'. De processen met hun exteme signalen zijn infiguur 6.7 weergegeven. We moeten nu weer signalen toevoegen om de genoemde functies te realiseren. Voor het doorgeyen van opdrachten van het systeem naar het proces 'Vul besturing' voeren we de flow 'VuLopdracht' in. De flow 'Fles_vol'is een onderdeel van 'VuUnfo' en wordt true zodra een fles gevuld is. Om het systeem in staat te stellen te bepalen wanneereen gevulde ftes op een van de afvoerbanden gezet kan worden 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 transportsysteem om de stand van de schakelaars 7 en 8 te veranderen. 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 moeten 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 persoonlijke 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 interpreteerbaar. \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 prores 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 gehaald 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 besturing' in de onderdelen 'Schakelaars' en 'Banden' weergegeven.De lezer kan zelf nagaan welke interne signalen zijn toegevoegd. 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 'Etiket 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 machine 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 processen 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 definieren:
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 worden 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 gebruik 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. Tenslotte zijn er nog wat ongedefinieerde zaken als 'Stuur' en'Wacht op'. De uitvoering van dit soort opdrachten is implementatie 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 selecteren 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 processor- 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 worden.Ais we uitgaan van processoren met voldoende capaciteit omde eerste mogelijkheid aan te kunnen zijn alle genoemde oplossingen 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 ander 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 implementatie 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 taakmodellen 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 parallellisme. 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 oplossen 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 besturingsproces 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 oplossing waarbij de drie processen achter elkaar uitgevoerd worden 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 hiervan is dat de besturing moet weten wanneer er een opdrachtis en wanneer deze uitgevoerd is. Dit wordt aangegeven doorde eventflows 'OpdrachLontvangen', 'Vullen..klaar' en 'Controleren klaar'. In figuur 6.13 is de oplossing getekend. Alstijdens de uitvoering van een opdracht een volgende binnenkomt zouden opdrachten verloren kunnen gaan. Om dit tevoorkomen is een zogenaamde eventstore toegevoegd. Dit iseen semafoor die gebruikt kan worden om events te onthouden. 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 gegeYen.
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 tijdsbesteding
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 gegeven. 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 controleren' taak onderbroken worden door het controleren vande toestand van de vulmachine door de tweede taak. Rier isparallellisme dus weI toegestaan. Een voordeel van deze indeling 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 statements '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 dataflowdiagram voor de 'Vullen en controleren' taak, omdat hierintwee processen parallel uitgevoerd worden ('Fles vullen' en'Fles controleren'). In 'Fles vullen' zijn oak weer twee parallelle processen getekend, waardoor er eigenlijk sprake is vandrie processen ('Fles controleren', 'Vul' en 'Voer af'). Omsequentiele uitvoering mogelijk te maken moeten we een besturingsproces toevoegen. In figuur 6.17 is dit gedaan, in figuur 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 processortijd 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 controle'
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 toestandsdiagram 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 randvoorwaarden zoals het maximale aantal taken dat het operating 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 processen 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 gegeven taakmodellen een modulemodel opstellen, waarbij wezul1en beginnen met de indeling in de twee taken 'Vullen encontroleren' en 'Bewaking', waarbij de eerste taak niet in deeltaken verdeeld is.
Modulemodel voor twee deeltaken
Bij de in figuur 6.15 gegeven taakindeling horen twee modulemodellen. Het model voor de bewakingstaak lijkt triviaalomdat daar sprake is van slechts een proces. We zouden kunnen 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 bewakingsproces
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 inlezen 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 structure 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 controleren'. '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 controleertaak 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 besturingsproces over, dat ook nog gemodelleerd moet worden. We kunnen 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 module houdt de optredende events in de gaten en stopthet aktieve zodra er een toestandsverandering optreedt.Daarna wordt de controle terug gegeven aan de hoofdmodule 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 besturingsproces '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_ besturing'
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 standaardmodule:
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 variabele'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 modellen van de schoonmaak- en afsluitmachines omdat deze sterkeovereenkomsten vertonen met de vulmachines. Tenslotte zoude rest van de machines gemodelleerd kunnen worden. Daarnaast 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
onderhoudshandleidingen
Opdracht 6.1
Opdracht 6.2
Opdracht 6.9
Opdracht 6.4
Limozuki
£lessen in het systeem en de mate waarin bestellingen uitgevoerd 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 natuurlijk 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 werkelijkheid 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 toestand 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-lIlelding, 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 vullen.•
177
Limozuki
V_vuI2_com = ['Cola' I 'Cassis' I '7_Up']* Soort drank waarmee vulmachine 2 een fles moet vullen. *
VuLaan_uit = ['VulLaan' I 'VulLuit' I'VuI2-aan' I 'Vu12_uit']* Signalen waarmee de vulmachines aan- en uitgeschakeld 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 transportsysteem. *
Band_info = Band_status + Band_vrij* Informatie van het transportsysteem aan de transportbesturing 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 transportbesturmg. *
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 transportbesturmg.*
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 transportbesturing 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 transportbesturing. *
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 + Etiketten_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 + Cassis_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_etiketten_op_melding, Cola..etiketten..a.angevuld, Cola...etiketten_op,Cola...etiketten-Op_melding, Etiket...aangebracht, Etiketmachine_defect.melding, Stop_band, Up_etiketten..a.angevuld, Up_etiketten-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 Limozuki.
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 besturingsproces 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_ besturing'
194
Associatie
Hoofdstuk 7
Referentielijst
7.1 Inleiding
In dit hoofdstuk wordt een lijst gegeven van termen en technieken 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 verwijzingen. 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 diagram. Een associatie geeft een relatie weer waarover informatie 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 mogelijkheid weI door van de relatie een objecttype te maken. Benvoorbeeld is de relatie 'koopt' links in figuur 7.1. Als we informatie over een aankoop willen bewaren (de datum en hetbedrag bijvoorbeeld), kunnen we 'koopt' ornzetten in een assoeiatie 'aankoop', weergegeven reehts in dezelfde figuur. Derelatie-ruit is nu leeg en de relatie zelf is veranderd in een zelfstandig naamwoord ('aankoop') dat in een reehthoek onderde relatie-ruit gesehreven wordt. Merk op dat 'klant' en 'artikel' onafhankelijk van 'aankoop' kunnen bestaan; ook zonderaankopen kan er sprake zijn van klanten en artikelen. Zonder 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 beslissingstabel 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 voorwaarden 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 treden 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 nadeel van de Yourdon methode is dat de omvang van de tabelnogal snel uit de hand loopt, omdat het aantal mogelijke combinaties exponentieel toeneemt met het aantal voorwaarden.Zie ook: dataflowdiagram, gestructureerde taal, preen 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 gestippelde pijlen. Een besturingsflow kan alleen door een bestu-
197
Besturingsproces
Call
Code
Referentielijst
ringsproces gegenereerd worden. Een synoniem voor besturingsfl.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, implementatiemodel, 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 uitgevoerd moeten worden. Ook op het datafl.owdiagram uithet conceptueel-model kunnen besturingsprocessen voorkomen, 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 besturing 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 andere 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
Conceptueelmodel
Conceptueelmodel(Yourdon)
Referentielijst
Zie ook: SQS
Conceptueel-model Ben conceptueel-model is bedoeld ominzicht te verkrijgen in de functionaliteit van het systeem. Volgens 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 geproduceerd 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 combinaties 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, dataflowdiagram, datadictionary, doelbeschrijving, eventlist, 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 buitenwereld 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 omgeving uitwisselt. Ret contextdiagram vormt het bovenste niveau van het dataflowdiagram. Ret is een onderdeel van hetconceptueel-model.Zie ook: conceptueel-model, dataflow, dataflowdiagram, eventflow, proces, terminator
200
Datadietionary
Dataflow
Referentielijst
Datadictionary AIle flows en stores die op het dataflowdiagram 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 deelobject 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 diagram, store
Dataflow Dataflows geven het transport van objecten (gegevens, papier, electronen, ...) van de ene plaats in het systeem 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 figuur 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 gesplitst (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 uiteinden 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 veranderende variabele weer. Een voorbeeld is een spanning ofeen temperatuur. Een tijd-diserete flow ( _) daarentegen
202
Datafiowdiagram
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 dataflowdiagram.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 deeltaken kunnen weer opgedeeld worden. De bovenste laag vanhet DFD wordt gevormd door het contextdiagram. Ret eneproces van dit diagram wordt uitgewerkt in 'Figuur 1', waarmee 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 opvolgend 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, dataflow, 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 eventflows. 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 overgenomen worden uit de data dictionary. Er moeten nog eenaantal zaken toegevoegd worden:
• De representatie van de data moet gekozen worden (bijvoorbeeld 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 systeem verantwoordelijk voor is. De beschrijving is opzettelijk 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 data 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 middel 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 uitgelezen.
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 methode) 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 vastgelegd worden. We onderscheiden functionele eisen (takendie het systeem uit moet voeren), kwaliteitseisen (betrouwbaarheid, beschikbaarheid, capaciteit) en ontwikkeleisen (gebruikte 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 getransporteerd 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 tijdstip 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 events). In het context diagram zijn ze weergegeven dooreventflows.
4. Ben extern event hoeft niet noodzakelijk overeen te komen met een flow uit de omgeving naar het systeem.Ben event kan bijvoorbeeld gei'nspireerd zijn op een bepaalde functie van het systeem. Zo zou 'gebruiker verwijdert karakter' in een editorprogramma een event kunnen zijn. Ben editor zal als inputflow bijvoorbeeld 'aangeslagen 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 aangegeven wordt. Eventflows worden weergegeven door gestippeldepijlen. Ret verschil tussen een eventflow en een besturingsflow 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 verbonden 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, implementatiemodel, taakmodel
Flow Flow is een verzamelnaam voor besturingsflow, dataflow en evenflow. Welke van de drie bedoeld wordt moet uitde context blijken.Zie ook: besturingsflow, dataflow, eventflow
Flowdiagram Flowdiagram is hier een synoniem voor dataflowdiagram. In de literatuur wordt weI onderscheid gemaakt tussen een dataflowdiagram waar geen besturingsprocessen, besturingsflows of eventflows toegestaan zijn, en eenflowdiagram waar dat weI het geval is. Flowdiagram en dataflow 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. Gestructureerde taal bestaat uit een deelverzameling van een natuurlijke 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 gewoonte 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 soortgeHjke cODstructies in programmeertalen, omdat de conditie 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 kunnen 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 waarschijnlijk 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 onderdeel van het lifecycle model SQS. Er zijn handleidingen voorgebruikers (de buitenkant van het systeem), systeembeheerders (systeemconfiguratie, installatie) en onderhoud van hetsysteem (toelichting op hardware, implementatiemodel en code in verband met wijzigingen).Zie ook: SQS
210
Implementatiemodel
Implementatiemodel(Ward/Mellor
Modulemodel
Referentielijst
Implementatiemodel Het implementatiemodel is een vertaling van het conceptueel-model naar een concrete implementatie. Er zijn veel methoden, waarvan die van Ward en Mellor([Mellor, 1986]) een veelgebruikte is.Zie ook: implementatiemodel (Ward/Mellor)
Implementatiemodel (Ward/Mellor) Het implementatiemodel volgens Ward en Mellor beschrijft hoe de processenvan het conceptueel-model verdeeld zullen worden over processoren, hoe de processen binnen processoren in parallel uitvoerbare eenheden (taken) verdeeld worden en tenslotte hoede processen van een taak in procedures en functies geimplementeerd 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 toegekende processen verdeeld over parallel uitvoerbare eenheden.
3. Het modulemodel beschrijft de structuur van procedureen functie-aanroepen binnen een taak.
Zie ook: implementatiemodel, modulemodel, processormodel, taakmodel
Modulemodel Het laatste onderdeel van het implementatiemodel 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 specificatie van de gebruikte functies en de gebruikte data.Zie ook: dataspecificatie, implementatiemodel, modulespecificatie en structure chart
211
M odulespecificatieModulespecificatie Modulespecificaties zijn tekstuele beschrijvingen van de functie van een module. Bij elke modulehoort een dergelijke specificatie ook bij modules die uit deelmodules bestaan (in tegenstelling tot processen van het DFD,die aIleen tekstueel gespecificeerd worden als ze niet uitgewerkt 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, structure chart
Objeet-relatiediagram
Object-relatie diagram Object-relatie diagrammen(ERD: Entity Relation Diagram) worden gebruikt om de opbouw 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 datageorienteerd zijn, zoals database toepassingen.Zie ook: associatie, objecttype, relatie, su-per/subtype relatie
Objecttype Objecttypes komen voor op het ERD. Ze worden weergegeven door een rechthoek met daarin de naam vanhet objecttype. Het type representeert een verzameling objecten 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, super/subtype relatie
Omgevingsanalyse De omgevingsanalyse is een beschrijving 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 architectuur 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 datatransport plaatsvindt. Er zijn twee soorten:
1. Dataparameters worden aangegeven door een open cirkel aan het eind van het pijItje. Ze geven aan dat deparameter als data gezien moet worden.
2. Besturingsparameters worden weergegeven door een gesloten cirkel aan het eind van het pijItje. Ze geven besturingsinformatie weer (vergelijk dataflow/ eventflow).
Zie ook: module, structure chart
Pre- en postcondities Pre- en postcondities zijn een middel om een proces van het DFD te specificeren. Met behulpvan pre- en postcondities kan de functie die een proces uitvoert 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 moeten 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, gestructureerde taal, proces, processpecificatie
Proces Proces is een synoniem voor dataproces en besturingsproces, 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 mechanische constructie komen in aanmerking. We zullen ons verderalleen met programmeerbare digitale apparatuur bezig houden.De eerste stap in het samenstellen van een implementatiemodel 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 acties die processen op het laagste niveau van het DFD uitvoeren om inputs om te zetten in outputs. Ze beschrijven dusprocessen die niet in een aparte figuur van het DFD uitgewerkt 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 gewone taal (te veel redundantie, onoverzichtelijk, dubbelzinnig), 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 gebruik gemaakt wordt van wiskundige technieken. Gewone taalzou eventueel gebruikt kunnen worden in heel eenvoudige gevallen, 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 toestandsdiagrammen gebruikt.Zie ook: beslissingstabellen, dataflowdiagram, gestructureerde taal, pre- en postcondities, proces, toestandsdiagrammen
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 voorbeeld 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 beschrijven 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 verdeling van een taak in modules, de hierarchische organisatie vandeze modules en de interfaces ertussen. Structure charts vormen 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 concepten 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, module, parameterpijl
Super/subtype relaties Super/subtype relaties komenvoor als onderdeel van object-relatie diagrammen. Met behulpvan dit type relaties kan aangegeven worden dat een objecttype bestaat uit een aantal deelcategorieen. Er worden voorhet hoofdtype (supertype) een aantal gegevens bijgehouden,
218
Taakmodel
Referentielijst
terwijl voor elk subtype een verschillende verzameling additionele gegevens bijgehouden wordt. Ben voorbeeld is een verzameling journalisten waarvan er een aantal vaste medewerkers 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, daaronder voIgt een lege relatie-ruit, verbonden met het supertypedoor een lijn met een korte dwarsstreep erin. Onder de relatieruit 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 journalistenvoorbeeld 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 parallellisme meer. Op een hoger niveau kunnen taken weI paralleluitgevoerd worden.In het processormodel werden delen van het conceptueel-model toegekend aan processoren. Ret modellegt geen beperkingen op aan parallellisme en de besturing binnen een processor hoeft niet gecentraliseerd te zijn. Ret taakmodel verdeeltstukken van het processormodel over een aantal taken, waarbinnen 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 distributie van processen.Zie ook: implementatiemodel, proces, processormodel
Terminator Terminators komen voor op het contextdiagram. Ze representeren zaken (systemen, mensen, enz.) buiten 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 systeem en de buitenwereld weer. Relaties tussen terminatorsonderling verschijnen niet op het diagram omdat ze geen onderdeel uitmaken van het systeem.Zie ook: contextdiagram
Testmodel Ret testmodel beschrijft de uit te voeren testprocedures en de verwachte resultaten.Zie ook: SQS
Toestandsdiagram Voor het specificeren van besturingsprocessen 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 voorbeeld 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 implementatiemodel.
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
eventpartitioning
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 gespecificeerd te worden.De nadelen van deze methode zijn:
• Er ontstaat al snel een arbitraire verdeling in deelfuncties (meestal afhankelijk van het aantal mensen dat hetproject uitvoert). Een slechte indeling verhindert goedeimplementaties.
• De methode geeft geen aanwijzingen voor een goede indeling; er is aIleen controle achteraf mogelijk. Dit houdtin dat veel werk verloren gaat bij het opstellen en controleren 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 proces gedefinieerd, wat over het algemeen in een te groot aantalprocessen zal resulteren. Daarom zal het nodig zijn om processen 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 geproduceerde outputs. Als twee processen met elkaar communiceren 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 interfaces
stores verbergen
het getal 7
decompositie
Referentielijst
Nadat deze eerste versie van het DFD klaar is moeten processen 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 minimale interfaces strategie, waarbij er naar gestreefd wordt omde communicatie tussen processen tot een minimum te beperken, zodat synchronisatieproblemen zoveel mogelijk worden vermeden. Hierbij hoeft geen rekening te worden gehouden met opgeslagen data omdat die per definitie al gesynchroniseerd 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 processen 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 deelprocessen. Dit kan gebeuren door deelfuncties te definieren of doorde inputs en outputs te laten verwerken, respectievelijk produceren, door een apart proces.Merk op dat het eerste diagram geen deel uitmaakt van heteigenlijke DFD. Nadat een hierarchie naar boven is aangebracht 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 sensor, een parallelle in plaats van een seriele data-overdracht)door gebruik te maken van virtuele terminators. Een voorbeeld 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 implementatiej het is dus mogelijk om technologiebeslissingenuit te stellen. Ret volledige contextmodel ziet er in het algemeen uit zoals in figuur 7.11 weergegeven, dus opgebouwduit een 'echte' omgeving, een interfacelaag en een virtuele omgeving. Voor het conceptueel-model is aIleen de virtuele omgeving 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 implementatie: 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 naamgeving 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.
systeemondenJJerp
• Terminators en flows moeten vanuit bet standpunt vanbet systeem-onderwerp geidentificeerd worden. Dit wi!zeggen dat de naamgeving in termen van bet systeemonderwerp en niet in computertermen moet zijn. Een voorbeeld 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 noodzakelijk dat de processoren hun werkzaamheden synchroniseren. De specificatie wordt in delen gesplitst envan synchronisatiestatements (bijvoorbeeld met behulpvan semaforen) voorzien.
3. Een besturingsproces moet gesplitst worden. In dit geval 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 transitie en voer een van de volgende akties uit:
• deze processor controleert de voorwaarde envoert de aktie uit: voeg een aktie toe waarmee aan de andere processor kenbaar gemaaktwordt dat de voorwaarde gecontroleerd is
• de voorwaarde wordt door deze processor gecontroleerd, terwijl de andere de aktie uitvoert: 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 voorwaarde gecontroleerd is en verwijder de aldie.
(c) Voor elke toestand waarvan
• aIle uitgaande transities als voorwaarden signalen van andere processoren maar geen aktieshebben, en
• aIle uitgaande transities naar dezelfde toestand gaan
doe het volgende:
• verwijder de toestand en zijn uitgaande transities
• leid aIle inkomende transities om naar de toestand die volgde op de zojuist verwijderde toestand.
Blijf deze stap uitvoeren tot geen toestanden meerverwijderd kunnen worden.
4. Verwijder aIle gegenereerde signalen die door het verwijderen 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 toestandsdiagrarn
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' verwijderd 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 processor 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. Figuur 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 leiden 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 processor (als we aannemen dat toegang tot de store onder mutual 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 toegangsrechten tot de store. De inhoud ervan kan onder mutualexclusion gemanipuleerd worden. Er zijn geen toevoegingenof wijzigingen van de dataflowdiagrammen voor de processoren 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 worden 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 communicatie met 'Processor 2' te verzorgen.
Verdubbeling Als verdubbeling wordt toegepast moet aanaIle processoren die de data nodig hebben een proces toegevoegd 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 communicatie 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 taken
In het processormodel werden delen van het conceptueel-model toegekend aan processoren. Het modellegt geen beperkingen op aan parallellisme en de besturing binnen een processor hoeft niet gecentraliseerd te zijn. Het taakmodel verdeeltstukken van het processormodel over een aantal taken, waarbinnen 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 processen 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 geaktiveerd 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 diagrammen 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 voorwaarde de voorwaarde van de beschouwde transitie enals doel een (eventueel nieuwe) toestand die de combinatie is van de toestanden waarin de oude diagrammenterecht zouden komen. Merk op dat een overgang inhet ene diagram een overgang in het andere kan veroorzaken. 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 zoals 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 gehaald 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 systeem voor 'cruise control' van een auto (ontleend aan [Mellor, 86]). De twee samen te voegen processen zijn gegevenin figuur 7.28, de toestandsdiagrammen zijn te vinden in figuur 7.29.In stap 1 van het algorithme moeten we de twee toestandsdiagrammen opnieuw tekenen en eventueel een nieuwe begintoestand toevoegen. 'Bewaak motor' wordt niet extern geaktiveerd 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 oorspronkelijke begintoestand ('Besturing is uit') gaan. Verdermoet een overgang van elke toestand naar de nieuwe begintoestand 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 'Motor 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 toestand '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 'Bestuur 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 figuur 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 geaktiveerd 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 gewisseld moet worden, kan een aantal periodieke processen samengevoegd 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. Omdat 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 kunnen 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 beschikbaar is om aan te geven of het betreffende proces geaktiveerdmag worden of niet.Merk op dat het belangrijk is om besturingsprocessen van dataprocessen te scheiden. Neem als voorbeeld een proces dateen event herkent, een proces dat als gevolg van dat event geaktiveerd wordt en een besturingsproces dat aan een anderetaak toegekend is. Als het event optreedt, moet de eventherkenner 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 aankomstfrequentie
wachtrijmechanisme
extra interfaces
Referentielijst
7.3.6 Toewijzing van tijd-discrete processen
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 leesaktie 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 gedefinieerd: een taak waarmee de eigenlijke transformatie uitgevoerd 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 wachtrij 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 besturingsprocessen 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 synchronisatie 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 toestandsdiagram voor de 'aanbieder' is in figuur 7.36 gegeven. De waiten signal-operaties zijn de gebruikelijke semafoor-operaties.Bij dit alles moet opgemerkt worden dat dit soort synchronisatie eigenlijk een taak van het operating system is. Als eenmultitasking operating system beschikbaar is hoeft de synchronisatie 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 communicerende 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 gegevens 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 genereert 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 oplossmgen:
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 besturingsprocessen
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 dezelfde dataflow op het DFD voorkomen maar apart worden 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 aktiviteiten van een taak. Ais binnen een taak een besturingsproces 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 processen 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 toestandsdiagram 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 akties en de volgende toestand. De uitgangstoestandenstaan horizontaal opgesomd, de gebeurtenissen die overgangen 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 uitgevoerd 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 daarvan terug.
2. De tweede strategie gebruikt een hoofdmodule die af-
248
nadere detaillermg
transformatieanalyse
Referentielijst
hankelijk van de toestand een andere module aanroept.Voor elke toestand is een module beschikbaar die bekijkt 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 volgende toestand uit te voeren.
Ais geen besturingsproces beschikbaar is, of als een proceste globaal gedefinieerd is om implementatie mogelijk te maken, 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 bijvoorbeeld, bepaalt het gemiddelde van twee gemeten percentagesen schrijft dit naar een beeldscherm. Dit proces kan uitgewerkt 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) uitvoeren
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 beschikbaar: 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 levert data aan een hoger niveau
Figuur 7.42: Structure chart: proces gebruikt 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 bovenste niveau wordt gevormd door een module met de naamvan het oorspronkelijke proces (bijvoorbeeld 'Display alcoholinformatie'). Ret tweede niveau bestaat uit het centrale proces 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 gegeven. 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 samengevoegd 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 bepaald kenmerk of de waarde van een semafoor, bewerkt moetworden door verschillende processen. In dit geval wordt eenzogenaamd 'transaktie centrum' toegevoegd. Dit proces bepaalt welk proces de binnenkomende data moet verwerken.Het transaktie centrum vormt nu de bovenste laag van dehierarchie met de oorspronkelijke processen op bet tweede niveau. 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 versie van de structure cbart gemaakt worden. Over bet algemeen zijn nog verfijningen en optimalisaties nodig die bereiktkunnen worden door te letten op de koppeling van modules onderling en de eenduidigheid, complexiteit en algemenebruikbaarheid van de individuele modules.
Koppeling
Twee modules kunnen gekoppeld zijn doordat de ene de andere aanroept, door een gemeenscbappelijk datagebied of zelfsdoor een 'goto'-statement. Over bet algemeen geldt: boe lager 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 variabelen in grotere structuren (het reduceren van het aantal parameterpijItjes). Het is niet zo dat alle variabelenzo maar gecombineerd kunnen worden en aan aIle modules beschikbaar gesteld moeten worden. Het samenvoegen is alleen geoorloofd als de modules die de datater beschikking hebben ook van het grootste deel van deelementen ervan gebruik maken. Bijvoorbeeld: vijf variabelen samenvoegen in een structuur en die doorgevenaan modules die maar twee van die variabelen gebruiken, maakt de boel alleen maar onduidelijker. Daarnaast mogen alleen verwante variabelen samengevoegdworden (weer vanwege de duidelijkheid, die hier tot uiting zal komen in de naamgeving, hoe moet je bijvoorbeeld een structuur noemen waarin de cursorpositie ende achternaam van een systeemontwerper zijn samengevoegd?).
• 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 tussenliggende modules gestuurd worden. Dit kan erg onoverzichtelijk 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 toestand' 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 betekent 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 alles 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 uitvoerende deel (binnenhalen en versturen van gegevens, rekenen).
Statiegeldflessen of kartonnen pakken
De mate waarin een module opnieuw beschikbaar is in andere toepassingen is een laatste criterium waarop een structure 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 toepassingen 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 jaargang 32, nr. 2, pag. 105 tim 232, 1990
[Kloprogge, 1990] Kloprogge, 1., Ontwerp van een besturingssysteem 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 Prentice Hall, bsa: ddt 85 war
[Yourdon] Yourdone, E., Afodern Structured Analysis, 1989Prentice Hall, Inc. bas: dfx 89 you
257