Embedded Systems Engineering
Informatica 2 studiehandleiding
Jos Onokiewicz Klassen: ES1, ES1V, ES1D 1 februari 2013 versie 1.3w
Hogeschool van Arnhem en Nijmegen Embedded Systems Engineering
2
Inhoud 1
Inleiding .................................................................................................................................... 5
2
Beschrijving en beoordeling ..................................................................................................... 6 2.1
Propedeuse voltijd ............................................................................................................. 6
2.2
Propedeuse voltijd versneld .............................................................................................. 7
2.3
Propedeuse deeltijd ........................................................................................................... 9
2.4
Beoordelingstabel Informatica 2 ..................................................................................... 11
3
Assessment............................................................................................................................. 12
4
Planning .................................................................................................................................. 13 4.1
Studieplanning normale traject (ES1) en deeltijdtraject (ES1D)...................................... 13
4.2
Studieplanning versneld traject (ES1V) ........................................................................... 14
5
Eisen aan het verslag .............................................................................................................. 15
6
Eindopdracht .......................................................................................................................... 18 6.1
Opzet tool chain en inrichten project directory .............................................................. 18
6.2
Opdracht 1: omzetting code van C naar C++ ................................................................... 21
zet de INF1 C code in de project directory .......................................................................... 21
gebruik IO streams .............................................................................................................. 21
gebruik het string type ........................................................................................................ 21
gebruik het bool type .......................................................................................................... 21
gebruik file streams ............................................................................................................. 21
gebruik call by reference ..................................................................................................... 22
gebruik de template class STL vector
............................................................................ 22
gebruik const correctness ................................................................................................... 22
gebruik relatieve padnamen van files ................................................................................. 22
6.3
Opdracht 2: class(es) maken op basis van de C struct..................................................... 22
6.4
Opdracht 3: unittesten .................................................................................................... 23
6.5
Opdracht 4: Qt GUI maken .............................................................................................. 24
Bijlage 1: Doxygen en Subversion richtlijnen ................................................................................. 27 Bijlage 2: Specificatie van het programma Cross ........................................................................... 28 Bijlage 3: Specificatie van het programma Roots .......................................................................... 30
3
Bijlage 4: Specificatie van het programma Triangle ....................................................................... 32 Bijlage 5: Voorbeeld van een testrapport ...................................................................................... 34
4
1
Inleiding
De onderwijseenheid Informatica 2 bouwt voort op Informatica 1, waar de taal C is behandeld. Nu gaat het om een kennismaking met de taal C++ en een introductie op het object georiënteerd ontwerpen van programma's als voorbereiding op de onderwijseenheid Project 4 in het tweede studiejaar. C++ reference manual: http://www.cplusplus.com/reference/ C++ is op het eerste gezicht een stevige uitbreiding van C. Er zijn echter subtiele verschillen in deze talen die kunnen leiden tot zowel run time als compile time errors. Er wordt gebruik gemaakt van de grafische ontwikkelomgeving QtCreator. Deze ontwikkelomgeving is multiplatform gericht, dit betekent dat we onder andere zowel voor Linux, Windows als MacOS X kunnen ontwikkelen. Bron voor downloaden QtCreator: http://qt.digia.com/Try-Qt-Now/ of http://www.hanese.nl/~pbijl/INF2/
Er wordt tevens uitgebreid aandacht besteed aan de diverse methoden van software testen. Binnen QtCreator wordt gebruik gemaakt van een unit test framework. Zodat testen door een programma worden uitgevoerd. Hoofdstuk 2 geeft uitgebreide informatie van deze onderwijseenheid. Je vindt er o.a. met welke indicatoren je wordt beoordeeld. In hoofdstuk 3 vind je informatie over de assessment. Hoofdstuk 4 geeft een planning voor het bestuderen van de gebruikte literatuur. Hoofdstuk 5 geeft de eisen die aan het verslag worden gesteld. Hoofdstuk 6 geeft een uitgebreide beschrijving van de eindopdracht. Bijlage 2, 3 en 4 geven voorbeelden van functionele specificaties van software. Bijlage 5 geeft het formaat van een testrapport.
5
2
Beschrijving en beoordeling
2.1
Propedeuse voltijd
Titel onderwijseenheid (OWE)
Informatica 2 (INF2)
1.
Opleiding
Embedded Systems Engineering
2.
Doelgroep
Eerstejaars ESE-studenten
3.
Beroepstaak/ beroepstaken
BT2: Software ontwerpen en testen
4.
Centrale beroepstaak
BT2: Software ontwerpen en testen
5.
(Beroeps) Producten
Windows programma in C++ met productrapport incl. testcases en testrapport
6.
Studiepunten/ Studielast
7,5 EC / 210 SBU
7.
Samenhang met andere OWE’s
Informatica 2 bouwt voort op de kennis van Informatica 1 en legt de basis voor Project 4.
8.
Ingangseisen
Informatica 1 gevolgd
9.
Algemene omschrijving
De student gebruikt een grafische ontwikkelomgeving en ontwikkelt in die omgeving individueel een van tevoren door hem of de docent aangedragen en met de docent afgesproken applicatie. Bovendien past hij een aantal testmethodieken toe op (een deel van) de ontwikkelde applicatie.
10.
Competenties
zie onderstaande beoordelingstabel
11.
Beoordelingscriteria
12.
Tentaminering
zie onderstaande beoordelingstabel Toetscode
Toetsnaam
Toetsvorm
Weging
Grens
INF2-A
Assessment
demonstratie en rapport
1.00
3.00
Compensatiemogelijkheden geen Frequentie (deel) tentamens 2 x per jaar
6
13.
Verplichte literatuur
De studiehandleiding 'Informatica 2' Jos Rouland, Hogeschool van Arnhem en Nijmegen Het dictaat 'C++ in het kort' Jos Rouland, Hogeschool van Arnhem en Nijmegen Het dictaat 'Software testen' Jos Rouland, Hogeschool van Arnhem en Nijmegen Het dictaat 'Aanbevelingen voor de lay-out van C-programma's' Frits Feldbrugge, Hogeschool van Arnhem en Nijmegen
14.
Aanbevolen literatuur
n.v.t.
15.
Software
Qt Creator
16.
Overig materiaal
n.v.t.
17.
Activiteiten
bijwonen van theorielessen deelnemen aan practica deelnemen aan de mondelinge assessment opleveren van bovengenoemde beroepsproducten
18.
Werkvormen
theorielessen practica
19.
Les-/Contacturen
0,75 uur per week theorie in blok 3 1,5 uur per week practicum
20.
Onderwijsperiode
Semester 2
21.
Maximum aantal deelnemers
n.v.t.
2.2
Propedeuse voltijd versneld
Titel onderwijseenheid (OWE)
Informatica 2 Versneld (INF2V)
1.
Opleiding
Embedded Systems Engineering
2.
Doelgroep
Eerstejaars ESE-studenten met vooropleiding vwo of mbo
3.
Beroepstaak/ beroepstaken
BT2: Software ontwerpen en testen
4.
Centrale beroepstaak
BT2: Software ontwerpen en testen
5.
(Beroeps) Producten
Windows programma in C++ met productrapport incl. testcases en testrapport
7
6.
Studiepunten/ Studielast
7,5 EC / 210 SBU
7.
Samenhang met andere OWE’s
Informatica 2V bouwt voort op de kennis van Informatica 1V en legt de basis voor Project 4.
8.
Ingangseisen
Informatica 1V gevolgd
9.
Algemene omschrijving
De student gebruikt een grafische ontwikkelomgeving en ontwikkelt in die omgeving individueel een van tevoren door hem of de docent aangedragen en met de docent afgesproken Windows applicatie. Bovendien past hij een aantal testmethodieken toe op (een deel van) de ontwikkelde applicatie.
10.
Competenties
zie beoordelingstabel Informatica 2 (voltijd nominaal)
11.
Beoordelingscriteria
12.
Tentaminering
zie beoordelingstabel Informatica 2 (voltijd nominaal) Toetscode
Toetsnaam
Toetsvorm
Weging
Grens
INF2V-A
Assessment
demonstratie en rapport
1.00
3.00
Compensatiemogelijkheden geen Frequentie (deel) tentamens 2 x per jaar 13.
Verplichte literatuur
8
De studiehandleiding 'Informatica 2' Jos Rouland, Hogeschool van Arnhem en Nijmegen Het dictaat 'C++ in het kort' Jos Rouland, Hogeschool van Arnhem en Nijmegen Het dictaat 'Software testen' Jos Rouland, Hogeschool van Arnhem en Nijmegen Het dictaat 'Aanbevelingen voor de lay-out van C-programma's' Frits Feldbrugge, Hogeschool van Arnhem en Nijmegen
14.
Aanbevolen literatuur
n.v.t.
15.
Software
Qt Creator
16.
Overig materiaal
n.v.t.
17.
Activiteiten
bijwonen van theorielessen deelnemen aan practica deelnemen aan de mondelinge assessment opleveren van bovengenoemde beroepsproducten
18.
Werkvormen
theorielessen practica
19.
Les-/Contacturen
0,75 uur per week theorie
2,25 uur per week practicum 20.
Onderwijsperiode
Blok 2
21.
Maximum aantal deelnemers
n.v.t.
2.3
Propedeuse deeltijd
Titel onderwijseenheid (OWE)
Informatica 2 Deeltijd (INF2D)
1.
Opleiding
Embedded Systems Engineering
2.
Doelgroep
Eerstejaars ESE-deeltijdstudenten met een werkkring op mbo-niveau
3.
Beroepstaak/ beroepstaken
BT2: Software ontwerpen en testen
4.
Centrale beroepstaak
BT2: Software ontwerpen en testen
5.
(Beroeps) Producten
Windows programma in C++ met productrapport incl. testcases en testrapport
6.
Studiepunten/ Studielast
7,5 EC / 210 SBU
7.
Samenhang met andere OWE’s
Informatica 2D bouwt voort op de kennis van Informatica 1D en legt de basis voor Project 4D.
8.
Ingangseisen
Informatica 1D gevolgd
9.
Algemene omschrijving
De student gebruikt een grafische ontwikkelomgeving en ontwikkelt in die omgeving individueel een van tevoren door hem of de docent aangedragen en met de docent afgesproken Windows applicatie. Bovendien past hij een aantal testmethodieken toe op (een deel van) de ontwikkelde applicatie.
10.
Competenties
zie beoordelingstabel Informatica 2 (voltijd nominaal)
11.
Beoordelingscriteria
12.
Tentaminering
zie beoordelingstabel Informatica 2 (voltijd nominaal) Toetscode
Toetsnaam
Toetsvorm
Weging
Grens
INF2D-A
Assessment
demonstratie en rapport
1.00
3.00
9
Compensatiemogelijkheden geen Frequentie (deel) tentamens 2 x per jaar 13.
Verplichte literatuur
10
De studiehandleiding 'Informatica 2' Jos Rouland, Hogeschool van Arnhem en Nijmegen Het dictaat 'C++ in het kort' Jos Rouland, Hogeschool van Arnhem en Nijmegen Het dictaat 'Software testen' Jos Rouland, Hogeschool van Arnhem en Nijmegen Het dictaat 'Aanbevelingen voor de lay-out van C-programma's' Frits Feldbrugge, Hogeschool van Arnhem en Nijmegen
14.
Aanbevolen literatuur
n.v.t.
15.
Software
Qt Creator
16.
Overig materiaal
n.v.t.
17.
Activiteiten
bijwonen van theorielessen deelnemen aan practica deelnemen aan de mondelinge assessment opleveren van bovengenoemde beroepsproducten
18.
Werkvormen
theorielessen practica
19.
Les-/Contacturen
1,5 uur per week theorie + practicum
20.
Onderwijsperiode
Semester 2
21.
Maximum aantal deelnemers
n.v.t.
2.4
Beoordelingstabel Informatica 2
Eindkwalificaties Indicatoren (Competenties) op niveau 2
Score (gewicht) 0=ontbreekt/slecht 1=onvoldoende 2=voldoende 3=goed
C1 Wensen van de klant vertalen in 1. R: Legt ondubbelzinnig vast wat de klant een SMART geformuleerd geboden wordt (functionele specificatie). programma van eisen voor een 2. A/R: Ontwerpt een overzichtelijke user te ontwikkelen embedded interface. system
1……….(2)
C2 De architectuur van het gewenste embedded system ontwerpen: opdelen in onderdelen en subfuncties van de benodigde hardware en software
1. R: Verdeelt zijn applicatie in subfuncties. 2. A/R: Maakt efficiënt gebruik van minstens vier verschillende typen componenten van de grafische ontwikkelomgeving.
1……….(2) 2……….(2)
C3 De benodigde hardware en software voor een embedded system ontwerpen en testen. Het gaat hierbij om: - digitale systemen - embedded software - interfaces met gebruiker, fysieke omgeving en netwerken en tussen hardware en software
1. R: Ontwerpt correcte pseudocode voor functies. 2. R: Programmacode komt overeen met pseudocode. 3. R: Leidt een correcte set test cases af m.b.v.: a. equivalence partitioning b. boundary value analysis c. cause effect graphing d. multiple condition coverage 4. R: Stelt uit bovenstaande een minimaal totaal testplan op. 5. R: Schrijft een correct testrapport. 6. R: Motiveert ontwerpkeuzes.
1……….(1) 2……….(1) 3 a…….(5) b…….(5) c…….(5) d…….(5) 4……….(5)
C5 Een bijdrage leveren aan het 1. A: Demonstreert de correcte werking van zijn acceptatietraject door het geven programma. van presentaties, demonstraties 2. R: Zorgt voor een goede programma lay-out. en het opleveren van de 3. R: Kiest suggestieve namen van variabelen, documentatie objecten en functies. 4. A: Kan zijn ontwerp overtuigend uitleggen. (knock-out)
1……….(3)
C7 Projectmatig werken: kan plan 1. R: Doorloopt bij de ontwikkeling van zijn van aanpak maken, plannen, product de werkzaamheden afstemmen en a. definitiefase rapporteren over de voortgang b. ontwerpfase c. implementatiefase
1
C9 Schriftelijk en mondeling, in- en 1. R: Titelpagina, samenvatting en voorwoord extern communiceren in Engels zijn correct. en Nederlands, zowel met 2. R: Inleiding en inhoudsopgave zijn correct. vakgenoten als niet-vakgenoten 3. R: Gebruikt correcte spelling en stijl. 4. R: Brengt een heldere structuur en lay-out aan. 5. R: Schrijft gebruiksvriendelijke Engelstalige user manual. R: Rapport A: Assessment
1……….(1) 2……….(1) 3……….(1) 4……….(1) 5……….(1)
2……….(2)
5……….(2) 6……….(2)
2……….(1) 3……….(1) 4……….(1)
a…….(1) b…….(1) c…….(1)
11
3
Assessment
De student levert individueel bewijsmateriaal aan om aan te tonen dat hij de gewenste competenties heeft bereikt:
Hiertoe moet hij (individueel) een programma in C++ ontwerpen en demonstreren in een grafische ontwikkelomgeving en een uitgebreid verslag inleveren.
Ook moet hij een aantal test cases ontwerpen voor (delen van) zijn programma: -
-
De student definieert een duidelijke casus en bespreekt de functionaliteit van de te ontwikkelen applicatie met de docent en ontwerpt een overzichtelijke user interface. Hij verdeelt zijn applicatie in subfuncties, gebruikt componenten van de grafische ontwikkelomgeving (Qt) en ontwikkelt de applicatie in C++. Hij leidt testcases af m.b.v. equivalence partitioning, boundary value analysis, cause effect graphing en multiple condition coverage. Hij laat zien dat hij bij de ontwikkeling van zijn product de definitiefase, ontwerpfase en implementatiefase op de juiste wijze doorloopt. Hij levert heldere en complete documentatie van zijn product en motiveert zijn ontwerpkeuzes. Zie hoofdstuk 5 van deze handleiding voor de eisen die aan het verslag zijn gesteld en raadpleeg bijlage 5 voor het uiterlijk van het testrapport.
De student moet zijn werkwijze en zijn producten op vragen van de docent adequaat kunnen toelichten om een voldoende eindcijfer te krijgen!
Als de onderwijseenheid met een voldoende wordt afgesloten (minimaal 5.5), krijgt de student hiervoor 7,5 EC aan studiepunten.
12
4
Planning
Het versnelde traject geldt voor de studenten die de propedeuse in een half jaar afsluiten (ES1V). Voor de overige studenten (ES1 en ES1D) is het normale traject van toepassing. Er wordt van je verwacht dat je de opdrachten zoveel mogelijk buiten de ingeroosterde contacturen voorbereidt (pseudo-code en testen ontwerpen, C++-code schrijven en testen uitvoeren) om de beschikbare practicumtijd zo efficiënt mogelijk te gebruiken. Zorg ervoor dat je na elke sessie je software als back-up op je USB-stick zet. C++ boek: Gertjan Laan, Aan de slag met C++, 5de druk, Academic Service.
4.1
Studieplanning normale traject (ES1) en deeltijdtraject (ES1D)
weeknr. Te bestuderen literatuur en uit te voeren opdrachten 06 C++: H1 t/m H6 ('C++ boek') Opdracht: inrichten QtCreator project directory, met (lokale) subversion repository, INF1 code kunnen compileren onder QtCreator 07 Voorjaarsvakantie 08 C++: H7 ('C++ boek'), het aandachtsveld ‘iteratoren’ niet. 09 Testen: H1 t/m H4 ('Software testen'); 10 Testen: §5.1.1 ('Software testen'); toepassen op cross, roots of triangle (zie bijlagen) 11 Testen: §5.1.2 ('Software testen'); toepassen op cross, roots of triangle (bijlagen) 12 Testen: §5.1.3 ('Software testen'); toepassen op cross, roots of triangle (zie bijlagen) 13 Testen: §5.2 t/m §5.5 en H6 ('Software testen'); multiple condition coverage toepassen op cross, roots of triangle (zie bijlagen) 14 Testen: afronden van oefeningen software testen. Definiëren van de casus 15 Toetsweek 16 Starten met de casus 17 Werken aan de casus 18 Meivakantie 19-23 Werken aan de casus 24 Afronden van de casus 25 Toetsweek
13
4.2
Studieplanning versneld traject (ES1V)
weeknr. Te bestuderen literatuur en uit te voeren opdrachten 46 C++: H1 t/m H6 ('C++ boek') Opdracht: inrichten QtCreator project directory, met (lokale) subversion repository, INF1 code kunnen compileren onder QtCreator 47 C++: H7 ('C++ boek'), het aandachtsveld ‘iteratoren’ niet. Testen: H1 t/m H4 ('Software testen') 48 C++ en OO: Introductie object oriëntatie (van C structs naar C++ classes) Voorbeeld C++ class: CD.h en CD.cpp, constructor, destructor, public, private, member data en member functies, STL vector 49 Testen: H4 en H5 (black box en white box testen) QtCreator: opzetten Unit testen in projectdirectory Casus: verder naar C++ omzetten (zonder GUI) 50 C++: verschillen tussen structs en classes, new en delete QtCreator: inrichten GUI directories in project directory, kennismaken event driven gebruik widgets (signals en slots), widgets programmeren, toepassing pointers, new en delete Casus: start met het ontwikkelen van de GUI Testen: afronden H5 functioneel testen 51 Testen: H6 (niet functioneel testen). Werken aan de casus (voortzetting testen en GUI ontwikkeling) 52-01 Kerstvakantie 02-03 Afronden van de casus (testen en GUI) 04 Toetsweek 05 Projectweek Engineering
14
5
Eisen aan het verslag
Het projectverslag dient de volgende onderdelen te bevatten (breng zelf, indien nodig, de indeling in paragrafen aan): Titelpagina Samenvatting Voorwoord Inhoudsopgave 1 Inleiding 2 Definitiefase 3 Ontwerpfase 4 Realisatiefase 5 Testplan 5.1 Equivalence partitioning 5.2 Boundary value analysis 5.3 Cause effect graphing 5.4 Multiple condition coverage 5.5 Resulterend testplan 6 Testrapport Bijlage 1 User manual Titelpagina bevat titel (naam van het ontwikkelde product) en ondertitel (naam van de betreffende onderwijseenheid), auteur(s), klas, datum en eventueel een toepasselijke illustratie. Samenvatting beslaat maximaal 1 pagina en moet los van het rapport gelezen kunnen worden. De lezer hoeft geen kennis te hebben van het project! De samenvatting moet het gehele rapport dekken. Er moet kort worden beschreven waarover het gaat, wat de bereikte resultaten en niet gehaalde doelstellingen zijn en wat met belangrijkste testen is aangetoond. Voorwoord is bedoeld voor persoonlijke opmerkingen met betrekking tot de projectuitvoering en het gerelateerde verslag. Hierin kan bijvoorbeeld iets verteld worden over de ervaringen die tijdens het project zijn opgedaan, wat heb je geleerd, wat zou je volgende projecten anders gaan doen, over de problemen die zijn opgetreden of over oorzaken van vertragingen en dergelijke. Inhoudsopgave noemt alle onderdelen van het rapport met het nummer van de pagina aan het einde van de regel. Inleiding (hoofdstuk 1) vertelt bondig waar het rapport over gaat en hoe het is opgebouwd. Door het lezen van de inleiding kan de lezer zich oriënteren op de inhoud van het rapport en kan hij bepalen of het lezen ervan voor hem voldoende interessant is. Eventueel kan hij besluiten alleen bepaalde hoofdstukken of delen daarvan door te nemen. Dit betekent dat kort wordt besproken welk onderwerp of probleem behandeld of opgelost gaat worden en wat er in de opeenvolgende
15
hoofdstukken aan de orde komt. Bij dit laatste moet iets meer worden weergegeven dan de titels van de hoofdstukken. Definitiefase beschrijft de achtergrond van het project, de hoofdfunctie en de eisen en wensen die aan het te ontwikkelen product worden gesteld. Hierbij gaat het om de buitenkant van het systeem, het wat. Definieer de user interface. Verder worden de grenzen afgebakend (wat wel en wat niet) en wordt de acceptatietest (eisen voor de klant op gebruikersniveau) beschreven. De definitiefase mondt uit in een functionele specificatie. Toon hier de gebruikte menu's en formulieren met buttons, labels, edit velden, enz. De functionele specificatie dient volledig en eenduidig te zijn. Hij vormt de basis voor de drie black box testmethoden en de klant moet weten wat voor product hij kan verwachten. Zorg er dus voor dat je de opdracht van de docent in detail verder uitwerkt. Omschrijf nauwkeurig aan welke voorwaarden de diverse invoergegevens moeten voldoen. Som ook alle foutmeldingen op en vermeld hierbij in welke gevallen deze optreden. Ontwerpfase beschrijft de binnenkant van het systeem (de verwerkingskant, het hoe). Hier wordt globaal aangegeven hoe de functionele specificatie wordt omgezet in een technische oplossing. Alternatieven worden hierbij tegen elkaar afgewogen en de structuur van de gekozen oplossing wordt getoond. Realisatiefase beschrijft het detailontwerp (pseudocode en programmacode) en levert een gebruikershandleiding (de user manual). Hierbij wordt gebruikgemaakt van bijlagen. In de realisatiefase worden ook uitgebreide testcases gegenereerd om het product diepgaand te testen. Het testplan wordt in een apart hoofdstuk besproken. De API documentatie moet met Doxygen in een aparte directory met duidelijke naam in de projectdirectory gegenereerd worden. Voeg alleen in dit projectverslag een screendump van de documentatie van de uit de C struct met functies gemaakte C++ class toe (dus geen afdrukken van de Qt GUI classes). Testplan laat zien hoe de testcases worden afgeleid volgens de vier gegeven methoden (§5.1 t/m §5.4) teneinde het product uitgebreid te testen. In §5.5 wordt het resulterende testplan gegeven, waarbij het aantal testcases zo klein mogelijk is gemaakt. Er wordt dus gezocht of naar een minimale set die alle testcases uit §5.1 t/m §5.4 afdekt. Testrapport (hoofdstuk 6) toont de resultaten van het uitvoeren van de testcases door de test engineer. Dit hoofdstuk bevat dus in feite de conclusie. Hieraan kunnen eventueel aanbevelingen voor verbeteringen of uitbreidingen worden toegevoegd. User manual (bijlage 2) geeft de gebruikershandleiding. Deze is in het Engels. Begin hierbij met te vermelden hoe de applicatie opgestart moet worden. Gebruik
16
passende screendumps van de GUI van de Qt applicatie om het gebruik duidelijk te illustreren. Geef ook duidelijk aan hoe de applicatie gestopt kan worden. Opmerkingen: Nummer de pagina's, hoofdstukken en paragrafen. Begin elk hoofdstuk op een nieuwe pagina. Gebruik een zakelijke stijl, dus niet de ik- of wij-vorm (behalve in het voorwoord). Let op de correcte spelling en zinsbouw. Gebruik altijd de spellings- en grammatica-check van de tekstverwerker. Gebruik Doxygen om de API documentatie in html-formaat te kunnen genereren.
17
6
Eindopdracht
6.1
Opzet tool chain en inrichten project directory
Uitgangspunt vormt de specificatie, ontwerp en de uitwerking van de eindopdracht van INF1. Deze is gemaakt met C en is ontwikkeld op basis van functionele decompositie. Dit betekent dat het bepalen van functies en subfuncties de manier van ontwikkelen is geweest. In de praktijk bestaat soms de behoefte om bestaande "oude" code die nog steeds waarde heeft voor een bedrijf te gaan moderniseren. Deze "oude" code wordt legacy code genoemd. In deze opdracht gaan we onze eigen legacy code moderniseren door over te stappen naar een meer object georiënteerde aanpak, in C++ te implementeren en de tekstgeoriënteerde user interface te vervangen door een grafische user interface (GUI). Inrichten van de vereiste tool chain in een Linux of windows omgeving:
QtCreator (geïntegreerde ontwikkelomgeving) Subversion (code versiebeheer in SVN repository) TortoiseSVN of RapidSVN (subversion client met grafische frontend, makkelijker in het gebruik dan de command line tool) Valgrind (checking memory leaks)
Voor de uitvoering van ontwikkelproject is het noodzakelijk om een goed georganiseerde projectdirectory op te zetten. Zowel de structuur als naamgeving van directories en files is zeer belangrijk om de tooling correct, begrijpelijk en volgens veel algemeen toegepaste richtlijnen te laten werken. Denk bijvoorbeeld aan het gebruik van de make tool om een applicatie te kunnen compileren. Een projectdirectory staat op één plaats zodat het mogelijk is deze directory in één keer te kunnen copieren. Met andere woorden een projectdirectory heeft één root directory. We streven er naar om verschillende subdirectories te gebruiken om de verschillende type files overzichtelijk te kunnen organiseren. Bijvoorbeeld: de executables en .o files staan niet in dezelfde directory als de source files. Onderstaand geeft de vereiste aanpak weer voor het maken van een dergelijke directory. Het doel is niet alleen om zelf georganiseerd te werken maar ook voor de begeleidende docent om snel en adequaat te kunnen helpen in een omgeving waar meerdere tools toegepast moeten worden.
In het volgende stappenplan gaan we uit van de volgende feiten: de ontwikkelaar heet Pietje Puk en de applicatie heet Bereken
18
Stappen: 1. kies een passende naam (1 woord) voor de gemaakte applicatie in INF1. Bijvoorbeeld: Bereken. Deze naam gebruiken we voor de executable en als onderdeel voor een aantal subdirectory namen in de project directory. 2. Maak de directory INF2-<je naam zonder spaties> Bijvoorbeeld: INF2-PietjePuk. 3. Maak de volgende directory structuur (let op de naamgeving van de directories): INF2-PietjePuk BerekenProject branches releases trunk Bereken BerekenDebug BerekenRelease
4. Open een terminal en ga naar de directory INF2-PietjePuk en creëer met svn in deze directory een SVN repository met de naam BerekenSVN >svnadmin create BerekenSVN 5. De SVN repository moet nu gekoppeld worden met de workspace BerekenProject met een checkout (co) commando: >svn co file:///home/....../INF2-PietjePuk/BerekenSVN BerekenProject 6. Ga naar INF2-PietjePuk/BerekenProject om de nieuwe directories aan de SVN repository administratie (in een .svn directory) toe te voegen en deze aan te bieden aan de repository met een checkin (ci) commando: >svn add * >svn ci –m “Initial commit” 7. Start QtCreator. Kies File, New File or Project, Other Project, Plain C++ project Name: Bereken Create in: ......BerekenProject/trunk Negeer de opmerking ‘The project already exists’
19
8. Zet in QtCreator Projects, Compile voor Release setting Shadow build, dir ..../trunk/BerekenRelease. Zet in QtCreator Projects, Compile voor Debug setting Shadow build, dir ..../trunk/BerekenDebug Zet in QtCreator Projects, Run Settings de optie 'Run in terminal' uit (in bepaalde Linux releases kunnen we een terminal niet opstarten). De uitvoer komt nu in het QtCreator uitvoerpanel. 9. Compile het programma door op groene pijl links links onder te drukken. Het resultaat is een release versie. Onder deze groene pijl staat een tweede groene pijl met een “bug” afgebeeld. Hiervan is het resultaat een debug versie. De directory structuur met de belangrijkste inhoud voor de Bereken applicatie moet er na compilatie voor Debug en Release vorm er nu als volgt uitzien: INF2-PietjePuk BerekenSVN BerekenProject branches releases trunk Bereken main.cpp Bereken.pro Bereken.pro.user BerekenDebug Bereken main.o Makefile BerekenRelease Bereken main.o Makefile De make files zijn op basis van de Bereken.pro en Bereken.pro.user door qmake gegenereerd. 10. We kunnen nu in QtCreator gebruikmakend van Subversion verder ontwikkelen: gebruik Tools, Subversion. NB.: deze aanpak voor de opbouw van de projectdirectory had in een linux bash script gezet kunnen worden. Als command line parameter hadden we de naam van de applicatie mee kunnen geven. In ons voorbeeld: Bereken.
20
De volgende opdrachten zijn soms omschreven in termen van het voorbeeldproject Bereken. Uiteraard moet je daarvoor je eigen applicatienaam gebruiken!
6.2
Opdracht 1: omzetting code van C naar C++
Zie voor C++ de reference manual: http://www.cplusplus.com/reference/ en het genoemde C++ boek. Zoek op internet informatieve voorbeelden die aanvullend zijn voor alle genoemde aanwijzingen in de opdrachten.
zet de INF1 C code in de project directory Zet de bestaande INF1 C code in de directory waar main.cpp staat. Verander alle .c file namen in .cpp. Er kan maar één file zijn met main() dus zal de door QtCreator gemaakt e main.cpp verwijderd moeten worden. De verschillende .cpp en .h moeten aan de administratie van QtCreator medegedeeld worden. Ga naar de Projects pane, rechter muisknop, Add Existing Files. Commit aangepaste compileerbare files in de subversion repository met Qt Creator: Tools, Subversion, Commit files. Commit alleen files die compileerbaar zijn.
gebruik IO streams Vervang de printf en scanf statements door IO streams (cin, cout, cerr en/of clog). Gebruik voor het layouten van de uitvoer van data stream manipulators.
gebruik het string type Vervang de char arrays voor strings door het C++ string type. Een string type variabele (object) is ook nog als C array te gebruiken: string s; s.c_str(); Dit is noodzakelijk om soms C++ te gebruiken in combinatie met “oude”C functies, zonder deze C functies te hoeven aanpassen.
gebruik het bool type Gebruik op de geschikte plekken het bool type dat false of true kan zijn. In C zal daar een int voor gebruikt zijn.
gebruik file streams Vervang de C file types FILE door file streams (ifstream, ofstream en/of fstream).
21
gebruik call by reference Vervang de pointer argumenten van functies door een C++ reference type. Voorbeeld: int functie(int* piData) verandert in int functie(int& iData). Dit betekent dat ook de code in de functies aangepast dient te worden. We hoeven niet meer gebruik te maken van pointers en pointer notaties. Als we bijvoorbeeld een C++ string object doorgeven aan een functie dan moet dit by reference gedaan worden omdat anders het gehele string object onnodig gekopieerd gaat worden. Dit geldt niet alleen voor strings maar voor alle object typen die we doorgeven aan functies.
gebruik de template class STL vector Vervang de 1 dimensionale arrays door de STL vector voor het bijbehorende type. Bijvoorbeeld: int aiBuffer[20] ==> vector buffer; Let op: voor low level gebruik van arrays (hardware gerelateerd) wordt de vervanging door de STL vector niet gedaan. Laat 2 dimensionale arrays in hun oude C vorm.
gebruik const correctness Gebruik zo veel als mogelijk de aanduiding const in je programma. Doe dit niet achteraf omdat dit kan leiden tot veel error meldingen van de compiler! Toepassing van const verhoogt de kwaliteit van je code.
gebruik relatieve padnamen van files Indien we files openen in de code moeten we weten wat de current directory van de applicatie is zodat we de juiste relatieve padnaam van de te openen files in ons programma kunnen gebruiken. Vermijd absolute paden!
6.3
Opdracht 2: class(es) maken op basis van de C struct
Uitgangspunt C-code: data die bij elkaar hoort moet in één struct staan. Vervang de toegepaste struct en de bijbehorende “losse” C functies door een C++ class.
22
één of meer constructor(s), onder andere een default constructor indien mogelijk/zinvol, initialisatie van alle data members met initializer list constructor destructor member data
member functies (dit zijn de oude "losse" C-functies, maar nu in de scope van de class) public en private (streef ernaar om de data members allemaal private te maken en het aantal getters en setters zo klein mogelijk te maken) eventueel de output stream operator overloaden gebruik const zo veel als mogelijk
Overweeg het maken van eventueel meer classes (overleg dit met de docent). Het is mogelijk in een class objecten op te nemen van andere gemaakte classes.
6.4
Opdracht 3: unittesten
Maak met QtCreator een unittestproject aan met de naam BerekenTests in de trunk directory. Omdat de unittestcode een eigen main() nodig heeft zijn twee andere directories ook noodzakelijk (optie: shadow build): BerekenTestsDebug en BerekenTestsRelease. Omdat de unittestsoftware gebruik moet maken van bestaande files uit de directory Bereken, moeten we in de .pro file aangeven waar deze directory staat en welke bestaande files uit de directory Bereken we gaan gebruiken. We gaan dus geen files kopiëren naar andere directories. In .pro file toevoegen met juiste verwijzing naar de reeds bestaande directories in de projectdirectory: DEPENDPATH += ..... INCLUDEPATH += ..... In de .pro file toevoegen van de namen van de bestaande files (de padnaam hoeft er niet bij omdat we deze met DEPENDPATH en INCLUDEPATH al hebben opgegeven): SOURCES += .... HEADERS += .... De volgende directory structuur (let op de naamgeving van directories) moet nu ontstaan, uiteraard moet je gebruikmaken van je eigen programmanaam in de namen van de directories: INF2-PietjePuk BerekenProject branches releases trunk Bereken BerekenDebug BerekenRelease BerekenTests
23
BerekenTestsDebug BerekenTestsRelease De nieuwe directories moeten toegevoegd worden aan de Subversion repository. De gegenereerde files zoals bijvoorbeeld de executables en .o files moeten door Subversion genegeerd worden. Deze toevoeging van directories is gemakkelijk te doen met bijvoorbeeld RapidSVN (kan buiten QtCreator om). Uiteraard kan deze handeling ook gebeuren met de command line (kan ook buiten QtCreator om). QtCreator heeft een file gegenereerd met een class die aangevuld kan worden met member functions die verschillende testen moeten gaan uitvoeren. Gebruik voor deze functies informatieve namen. In elke testfunctie kan een object geinstantieerd worden van de class die in de vorige opdracht gemaakt is. Nu kunnen we testen gaan maken om alle member functions van deze zelf gemaakte class te kunnen controleren op correcte werking. Aanpak: we maken alle testfuncties in deze class. In de praktijk zal bij grotere programma's per class die we maken een aparte testclass gemaakt moeten zijn. Gebruik onder andere de testmacro's QCOMPARE en QVERIFY. Maak verschillende testen (aantall >=1) voor elke categorie (Equivalence partitioning, Boundary value analysis, Cause effect graphing en Multiple condition coverage). Unit testen moeten uitgevoerd kunnen worden zonder dat er invoer via het toetsenbord van een gebruiker nodig is! Invoer data dus hard coderen (opnemen in je code).
6.5
Opdracht 4: Qt GUI maken
Maak met QtCreator een GUI project aan met de naam BerekenGUI inde trunk directory. Kies in QtCreator: Create Project, Qt Widget Project, Qt Gui Application. Omdat de GUI software gebruik moet maken van files uit de directory Bereken moeten we in de .pro file aangeven waar deze directory staat. We gaan dus geen files copieren naar een andere directory. De volgende directory structuur moet nu zijn ontstaan, uiteraard moet je weer gebruikmaken van je eigen programmanaam in de directory namen: INF2-PietjePuk BerekenProject branches releases trunk Bereken BerekenDebug
24
BerekenRelease BerekenTests BerekenTestsDebug BerekenTestsRelease BerekenGUI BerekenGUIDebug BerekenGUIRelease Voor de ontwikkeling van de GUI is grondige programmeeroefening vereist. Advies: maak Qt C++ kennismakingsvoorbeelden op basis van Qt Tutorials op YouTube. Let erop dat in het commentaar op video’s aanwijzingen gegeven kunnen zijn op mogelijk fouten in de getoonde voorbeelden. Bron Qt video tutorials: http://www.voidrealms.com. In QtCreator is voor elke widget op basis van de bijbehorende class naam uitgebreide hulp te vinden met de QtCreator Help documentatie. Het is zeer lastig om alleen uit de class documentatie een applicatie te bouwen. Het is dus noodzakelijk om bijna altijd naar uitgewerkte code voorbeelden te kijken. Qt gebruikt in zijn bibliotheek een groot aantal zelf gemaakte typen (classes) die geoptimaliseerd zijn voor Qt gebruik. Bijvoorbeeld C++ std::string heeft als Qt variant QString. Het is goed mogelijk (zelfs wenselijk) om in je eigen core code standaard C++ typen te gebruiken, maar op GUI niveau de Qt typen. Onderstaand volgen enkele eisen. Overleg altijd met de opdrachtgever/docent als je wilt/moet afwijken! Eisen voor de GUI: 1. Zorg voor een zakelijke en overzichtelijke lay-out van de GUI. Gebruik duidelijke labels en rustige/opvallende kleuren voor de verschillende widgets. Zie voor kleurenpaletten bijvoorbeeld: http://www.colorhunter.com 2. Een standaard menu keuzebalk heeft de voorkeur. In elk geval moeten volgende menu items aanwezig zijn: - Menu item File: New, Open, Save en Quit (of in het Nederlands) - Menu Item Help: Info en About (of in het Nederlands). - Gebruik eventueel naast het menu ook knoppen (QPushButton) voor de belangrijkste menukeuzen. 3. Pas bij de menukeuze Quit wordt de applicatie beëindigd (window verdwijnt). Het moet dus mogelijk zijn de applicatie te kunnen herstarten zonder hem te hebben afgesloten. 4. Gebruik Qt signals en slots om de applicatie door de GUI event driven te kunnen laten uitvoeren.
25
5. Zet de naam van de applicatie en een versienummer in de window titel, zie help QMainWindow: setWindowTitle(). De applicatienaam en het versienummer moeten in de header file AppInfo.h met #define’s (macro's) opgenomen worden. Voeg onderstaande file aan je project toe: #ifndef APPINFO_H #define APPINFO_H #define #define #define #define #define #define
APPNAME "Bereken" MAJOR_VERSION "0" MINOR_VERSION "1" REVISION_VERSION "0" VERSION MAJOR_VERSION "." MINOR_VERSION "." REVISION_VERSION APPNAME_VERSION APPNAME " v" VERSION
#endif
De minimale grootte van het window moet in de code worden ingesteld, zie help QMainWindow: setMinimumSize(). 6. Met verschillende widgets kan er invoer gevraagd worden aan de gebruiker, check altijd of de invoer aan het vereiste waardebereik voldoet en geef duidelijke foutmeldingen. Denk bij het testen aan Boundary Value Analysis. Foute waarden mogen niet gebruikt worden voor de uitvoering van berekeningen (zorg voor robuustheid van de applicatie, programmeer defensief). 7. Zet met doxygen de API documentatie in de header files. In elk geval moet bij boven elke class definitie een korte omschrijving staan van het doel van de class.
26
Bijlage 1: Doxygen en Subversion richtlijnen Onderstaande richtlijnen zijn nog belangrijker als in een team met één repository aan dezelfde applicatie wordt gewerkt! Richtlijnen Subversion gebruik. 1. Het is gebruikelijk om in het algemeen in de header files Doxygen API commentaar toe te voegen. 2. In elk geval moet boven elke class definitie in een .h file altijd een omschrijving/doel van de class (kort) toegelicht worden. 3. Genereer de API documentatie altijd in aparte directories in de projectdirectory. Kies voor het formaat: html (met de Doxygen wizard). 4. Maak de volgende startdirectories in de workspace: trunk, branches en releases. 5. Het toevoegen, verplaatsen, verwijderen en het hernoemen van files moet met subversion gebeuren. 6. Commit alleen code die compilabel is. De code kan nog best bugs (run time errors) bevatten. 7. Voeg altijd een informatieve passende logging boodschap aan een commit toe. 8. Als er meerder aspecten verbeterd of aangevuld zijn, probeer dan de files zoveel en zo snel als mogelijk per aspect in te checken. Het is dus niet noodzakelijk om alle veranderende files in één keer te moeten comitten.
27
Bijlage 2: Specificatie van het programma Cross Het programma CROSS leest een aantal viertallen in. De getallen zijn integers, evt. voorafgegaan door een + of - teken en hebben een waardebereik van -1000 t/m +1000. Per viertal (a, b, c, d) wordt berekend wat het snijpunt van de lijnen ax+b en cx+d is. Per viertal wordt het resultaat als volgt afgedrukt: of of
parallel overlapping lines cross in: (x,y)
De snijpunten worden in wetenschappelijke notatie (E-notatie) weergegeven. Het programma wordt aangeroepen als:
CROSS
[]
De viertallen worden gelezen uit de file met de gespecificeerde filenaam. Als de file niet gevonden wordt of niet geopend kan worden, wordt het programma gestopt na het geven van de foutmelding: FILE NOT ACCESSIBLE
Als er meer dan één filenaam meegegeven wordt, wordt het programma gestopt na het geven van de foutmelding: TOO MANY ARGUMENTS
Als er geen filenaam gegeven is, worden de getallen gelezen uit de standaard invoer. De invoer is als volgt geformatteerd:
Standaard invoer bestaat uit vier getallen (resp. a, b, c en d) op één regel, gescheiden door een of meer spaties en/of tabs. Per regel wordt als volgt uitvoer (naar standaard uitvoer) gegenereerd: Als het een geldig viertal getallen betreft, dan wordt het snijpunt berekend en afgedrukt, anders wordt een foutmelding gegeven (zie onder). De invoer wordt afgesloten door een aparte regel die slechts het codewoord END (case insensitive) bevat. Als een getal buiten het waardebereik valt, dan wordt deze regel verder genegeerd en wordt de volgende foutmelding naar standaard uitvoer geschreven: NUMBER NOT IN DOMAIN:
28
Als een regel een, twee of drie getallen (binnen het waardebereik) bevat, dan wordt deze regel verder genegeerd en wordt de volgende foutmelding naar standaard uitvoer geschreven: UNUSED DATA: Lege regels worden genegeerd (geen foutmelding). Als een regel anderszins foutieve invoer bevat (dus ook bij teveel getallen), dan wordt deze regel verder genegeerd en wordt de volgende foutmelding naar standaard uitvoer geschreven: INVALID DATA:
De file heeft dezelfde lay-out als de standaard invoer. Het codewoord END is toegestaan, maar niet nodig. Getallen worden ingelezen totdat het codewoord END ofwel het einde van de file bereikt is.
Het programma dient gebruik te maken van een functie CrossPoint, die als volgt is gespecificeerd: typedef enum {CROSS, PARALLEL, EQUAL} CrossResult; CrossResult CrossPoint (int iA, int iB, int iC, int iD, float *pfX, float *pfY); function CrossPoint calculates the coördinates of the point where line y = iA * x + iB and y = iC * x + iD cross. If CrossPoint = values of fX If CrossPoint = values of fX If CrossPoint = of the point pre: post:
PARALLEL, the lines are parallel and the and fY are undefined. EQUAL, the lines are the same and the and fY are undefined. CROSS, (fX,fY) indicates the coördinates where the lines cross.
-1000 <= iA, iB, iC, iD <= +1000 if iA = iC and iB = iD then CrossPoint = EQUAL else if iA = iC and iB <> iD then CrossPoint = PARALLEL else CrossPoint = CROSS fX = (iD – iB) / (iA – iC) fY = iA * fX + iB
29
Bijlage 3: Specificatie van het programma Roots Het programma ROOTS leest drietallen in. De getallen zijn integers, evt. voorafgegaan door een + of - teken en hebben een waardebereik van -1000 t/m +1000. Per drietal (a, b, c) wordt berekend wat de wortels van de vierkantsvergelijking ax2+bx+c zijn, met andere woorden voor welke waarden van x de vierkantsvergelijking nul is. Per drietal worden de wortels als volgt afgedrukt: of of of
0
0
0
no roots one root: <wortel> two roots: infinite number of roots
De wortels worden in wetenschappelijke notatie (E-notatie) weergegeven. Het programma wordt aangeroepen als:
ROOTS []
De getallen worden gelezen uit de file met de gespecificeerde filenaam. Als de file niet gevonden wordt of niet geopend kan worden, wordt het programma gestopt na het geven van de foutmelding: FILE NOT ACCESSIBLE
Als er meer dan één filenaam meegegeven wordt, wordt het programma gestopt na het geven van de foutmelding: TOO MANY ARGUMENTS
Als er geen filenaam gegeven is, worden de getallen gelezen uit de standaard invoer. De invoer is als volgt geformatteerd: Standaard invoer bestaat uit drie getallen (resp. a, b en c) op één regel, gescheiden door een of meer spaties en/of tabs. Per regel wordt als volgt uitvoer (naar standaard uitvoer) gegenereerd: Als het een geldig drietal getallen betreft, dan worden de wortels berekend en afgedrukt, anders wordt een foutmelding gegeven (zie onder). De invoer wordt afgesloten door een aparte regel die slechts het codewoord END (case insensitive) bevat. Als een getal buiten het waardebereik valt, dan wordt deze regel verder genegeerd en wordt de volgende foutmelding naar standaard uitvoer geschreven: NUMBER NOT IN DOMAIN:
30
Als een regel slechts één of twee getallen (binnen het waardebereik) bevat, dan wordt deze regel verder genegeerd en wordt de volgende foutmelding naar standaard uitvoer geschreven: UNUSED DATA: Lege regels worden genegeerd (geen foutmelding). Als een regel anderszins foutieve invoer bevat (dus ook bij teveel getallen), dan wordt deze regel verder genegeerd en wordt de volgende foutmelding naar standaard uitvoer geschreven: INVALID DATA:
De file heeft dezelfde lay-out als de standaard invoer. Het codewoord END is toegestaan, maar niet nodig. Getallen worden ingelezen totdat het codewoord END ofwel het einde van de file bereikt is.
Het programma dient gebruik te maken van een functie RootValues, die als volgt is gespecificeerd: void RootValues (int iA, int iB, int iC, int *piNrRoots, float *pfX1, float *pfX2); function RootValues calculates the number of roots (iNrRoots) of the polynomial iA * x^2 + iB * x + iC. If iNrRoots = 0 or -1 (stands for infinite), the values of fX1 and fX2 are undefined. If iNrRoots = 1, fX1 contains the root value and the value of fX2 is undefined. If iNrRoots = 2, fX1 contains the smallest root value and fX2 contains the largest root value. pre: -1000 <= iA, iB, iC <= +1000 post: if iA = 0 and iB = 0 and iC = 0 then iNrRoots = -1 else if iA <> 0 and iB * iB < 4 * iA * iC or iA = 0 and iB = 0 and iC <> 0 then iNrRoots = 0 else if iA <> 0 and iB * iB = 4 * iA * iC or iA = 0 and iB <> 0 then iNrRoots = 1 fX1 = -iB / (2 * iA) else if iA <> 0 and iB * iB > 4 * iA * iC then iNrRoots = 2 fX1 = (-ib - √(iB2-4*iA*iC/(2*iA) fX2 = (-ib + √(iB2-4*iA*iC)/(2*iA)
31
Bijlage 4: Specificatie van het programma Triangle Het programma TRIANGLE leest drietallen in. De getallen vormen de lengtes van de zijden van een driehoek. Elk getal is een integer met een kleinste waarde 1 en grootste waarde 1000. Per drietal (a, b, c) wordt berekend of het een gelijkzijdige driehoek, een gelijkbenige driehoek of een ongelijkbenige driehoek betreft. Als de drie zijden geldige waarden hebben, maar geen driehoek vormen, dan wordt dat gemeld. Per drietal worden de resultaten afgedrukt als volgt: of of of
gelijkzijdig gelijkbenig ongelijkbenig geen driehoek
Het programma wordt aangeroepen als:
TRIANGLE []
De getallen worden gelezen uit de file met de gespecificeerde filenaam. Als de file niet gevonden wordt of niet geopend kan worden, wordt het programma gestopt na het geven van de foutmelding: FILE NOT ACCESSIBLE
Als er meer dan één filenaam meegegeven wordt, wordt het programma gestopt na het geven van de foutmelding: TOO MANY ARGUMENTS
Als er geen filenaam gegeven is, worden de getallen gelezen uit de standaard invoer. De invoer is als volgt geformatteerd:
32
Standaard invoer bestaat uit drie getallen (resp. a, b en c) op één regel, gescheiden door een of meer spaties en/of tabs. Per regel wordt als volgt uitvoer (naar standaard uitvoer) gegenereerd: Als het een geldig drietal getallen betreft, dan wordt het soort driehoek en afgedrukt, anders wordt een foutmelding gegeven (zie onder). De invoer wordt afgesloten door een aparte regel die slechts het codewoord END (case insensitive) bevat. Als een getal buiten het waardebereik valt, dan wordt deze regel verder genegeerd en wordt de volgende foutmelding naar standaard uitvoer geschreven: NUMBER NOT IN DOMAIN: Als een regel slechts één of twee getallen (binnen het waardebereik) bevat, dan wordt deze regel verder genegeerd en wordt de volgende foutmelding naar standaard uitvoer geschreven: UNUSED DATA:
Lege regels worden genegeerd (geen foutmelding). Als een regel anderszins foutieve invoer bevat (dus ook bij teveel getallen), dan wordt deze regel verder genegeerd en wordt de volgende foutmelding naar standaard uitvoer geschreven: INVALID DATA: De file heeft dezelfde lay-out als de standaard invoer. Het codewoord END is toegestaan, maar niet nodig. Getallen worden ingelezen totdat het codewoord END ofwel het einde van de file bereikt is.
Het programma dient gebruik te maken van een functie TriangleCheck, die als volgt gespecificeerd is: typedef enum {EQUILATERAL, ISOSCELES, SCALENE, NO_TRIANGLE} TriangleValue; TriangleValue TriangleCheck (int iA, int iB, int iC); function TriangleCheck calculates the kind of triangle with the side lengths iA, iB and iC. pre: 0 < iA, iB, iC <= 1000 post: EQUILATERAL <==> all sides are equal and the sides form a valid triangle)
ISOSCELES
<==> two sides are equal and the sides form a valid triangle SCALENE <==> no sides are equal and the sides form a valid triangle NO_TRIANGLE <==> the sides do not form a valid triangle
33
Bijlage 5: Voorbeeld van een testrapport
Testgroep:
................................................... ...................................................
Getest programma:
Cross / Roots / Triangle
Programmeurs:
................................................... ...................................................
Tester:
Nr 1 2 3 4 5 …
..........
Invoer
Verwachte uitvoer
Testresultaat
Als de uitvoer overeenkomt met de verwachte uitvoer, wordt "OK" als Testresultaat in de tabel ingevuld. Bij een afwijkende uitvoer wordt deze afwijkende uitvoer ingevuld in de kolom Testresultaat.
34
In deze onderwijspublicatie is géén auteursrechtelijk beschermd werk opgenomen.
35