Modelleren en testen met behulp van eindige automaten en simulaties

Deze module gaat over software ontwikkeling en dan specifiek over testen op grond van modellen zoals een eindige automaat en een simulatie.

Je maakt kennis met de robotstofzuiger Roomba die als verbindende context zal worden gebruikt in hoofdstuk 1 t/m 4.

Je kunt de module binnen It's Learning bekijken of via de link als losse website.

Je maakt gebruik van 2 gratis software omgevingen Greenfoot en de Automaton Simulator.

Bijlagen

Hieronder staan enkele bijlagen die je in de cursus nodig hebt (hoofdstulk 3), je kunt ze openen en opslaan, ze zijn ook te vinden op het schoolnetwerk.

Open bestand PlantenbakBovenaanzicht

Open bestand Stoel

Open bestand Werkbladen.pdf

Studiewijzer

Onderdelen

Deze module bestaat uit verschillende onderdelen

Introductie met de ‘Roomba’ waarin je kennismaakt met de overige onderdelen van de module.
Eindige toestands automaten en toestands diagrammen.
Simuleren met behulp van een programma in Greenfoot
Testen met behulp van de beide onderdelen uit hoofdstuk 2 en hoofdstuk 3.
* Deze 4 hoofdstukken vind je in de wikiwijs module
Zelf een eigen automaat maken.
Eindtoets.

* Tussen modelleren en testen is vooral ook de onderlinge relatie belangrijk!

Media en hulpmiddelen

De leermodule wordt aangeboden via wikiwijs (link vanuit IL)

De testen en toetsjes worden via It’s Learning gedaan

Voor de automaten gebruiken we Automaton simulator

Voor de simulaties gebruiken we Greenfoot (taal Java)

Leerdoelen

Per les vind je de precieze leerdoelen per les, globaal voor de gehele module geldt:

Je weet wat een eindige automaat is en kent daarbij de begrippen toestand, toestandsovergang en toestandsdiagram.
Je kunt (valide) paden bepalen in een eindige automaat en daarmee redeneren.
Je kunt met behulp van een automaat redeneren over het gedrag. van een systeem en begrijpt ook de beperkingen van de automaat.
Je kent de begrippen modelleren en testen (validatie en verificatie) vaak afgekort met mvvt en je weet wat deze begrippen inhouden bij systeemontwikkeling.
Je kunt zelf bij een eenvoudige situatie een automaat opstellen.
Je kunt een simulatie in Greenfoot (Java) begrijpen en aanpassen.
Je kunt de automaat en de simulatie samen gebruiken om het traject modelleren en testen uit te leggen.

Relatie met examenprogramma

Dit is een onderdeel uit het vernieuwde examenprogramma

domein B – Grondslagen

‘onderzoeken van en redeneren over digitale artefacten zonder dat deze daadwerkelijk zijn geïmplementeerd’

Subdomein B1 ‘correctheid en efficiëntie onderzoeken via algoritmen’
Subdoemin B3 ‘eindige automaten gebruiken ter karakterisering v.e. algoritme’

Periode planning

Studiewijzer [G5in], zie ook de uitgebreide studiewijzer op It's Learning

* g5.in1 wo(2) – vr(1) g5.in6 ma(1) – vr(2)

Totaal gebruiken we 15 lessen voor deze module, de totale studielast is ongeveer 20 klokuur

les	Leerstof	Activiteit
1.1	Introductie automaten met de Roomba + begrippen
1.2	Introductie context en Greenfoot
1.3	Introductie mvvt
2.1	Eindige automaat en toestandsdiagram	donderdagochtend herkansingen
2.2	Automaton Simulator
2.3	Automaat in een andere context
3.1	Roomba zelflopend	dinsdagavond PWS presentaties gym6
3.2	Automatisch vuil maken
3.3	Interieur toevoegen	Eindtoets automaten
4.1	Testen, validatie en verificatie
4.2	Testen, validatie en verificatie
5	Een eigen automaat
6	Toets	se-week (start op vrijdag)

Weging voor het cijfer periode 3

nr	onderdeel	inhoud	weging
1	test (4 maal)	weektaken en testje naar beheersingsniveau en leerdoelen	40%
2	toets	theoretische toets over de gehele leerstof	40%
3	toepassing	een eigen automaat (mag in duo)	20%

*Exacte data vind je in de studiewijzer op It's Learningolgen via It's Learning

Hoofdstuk 1 Introductie (les 1, 2 en 3)

Dit eerste hoofdstuk is een introductie van de gehele module:

In les 1 maak je via en video kennis met een robotstofzuiger en het begrip eindige toestand automaat (Finite State Machine). Ook denk je na over de relatie tussen de stofzuiger en het diagram,

In les 2 lees je wat concept - context onderwijs inhoud en maak je kennis met de context van deze lesmodule de Roomba@600 robotstofzuiger.

In les 3 worden de begrippen modelleren, valideren, verificeren en testen uitgelegd bij toepassing in softwareengineering.

De onderwerpen worden daarna in de hoofdstukken 2,3 en 4 verder besproken door middel van lezen en opdrachten.

Na een hoofdstuk is er steeds een afsluitende korte test (ong. 15 minuten) om te kijken of je de leerdoelen van de betreffende lessen hebt bereikt en op welk niveau.

Les 1 Introductie automaten

Veel appraten kun je beschouwen als een automaten die zich in een bepaalde toestand bevinden. De werking van zo een apparaat komt er dan op neer dat het van toestand kan veranderen, soms door een actie van een gebruiker, soms vanzelf na verloop van tijd of door een bepaalde omstandigheid.

Om voor dergelijke apparaten software te kunnen ontwikkelen en testen voordat het apparaat daadwerkelijk is gebouwd kunnen we gebruik van modellen.
In deze module ga je jezelf dan ook verdiepen in het modelleren van en testen met een eindige automaat en je bekijkt en bewekt een simulatie dioe met behulp van Greenfoot in Java is geprogrammeerd.

Roomba Als voorbeeld begin je met een eenvoudige robotstofzuiger waarvan een deel van het model al bestaat, je breidt dit dan verder zelf uit aan de hand van de opdrachten. Je leert dus steeds in 3 stappen:

Door het bestuderen van een voorbeeld leer je het probleem begrijpen en een oplossing.
Door zelf aan te passen en/of uitbreiden van het model zie je of het goed hebt begrepen (neem ook de goede gewoonten over in stijl, naamgeving …).
Door het geleerde in een nieuwe situatie koppel je de kennis van de onderdelen aan elkaar en krijg je overzicht in het geheel (wisselend perspectief).

Leerdoelen introductie

Je kent de grafische voorstelling van een eindige automaat (toestandsdiagram) globaal
Je kunt de toestanden en overgangen in het diagram koppelen aan het gedrag van de robotstofzuiger
Je weet wat een (non) valid cleaning is en kunt deze benoemen in het voorbeeld van de robotstofzuiger
Je kunt een relatie leggen tussen eisen aan een robotstofzuiger en het toestandsdiagram

Introductie video robotstofzuiger

Learn about finite state machines (FSM) using a room-cleaning robot as an example.

Toestandsdiagram

Toestandsdiagram (uit de video)

Valid cleanings

Voldoet de automaat aan de gestelde eisen?

In de video (bij 4:00 minuten) zie je dat dat niet alle 'cleanings' mogelijk zijn.

De auteur laat zien dat een 'cleaning' waarbij de batterij leeg raakt tijdens het opruimen van vuil (toestand S) niet mogelijk is in de automaat.

not a valid cleaning video 4:00

Les 2 Introductie van de context

In de examprogramma's van veel van de betavakken en inmiddels ook maatschappijvakken wordt gesproken over een concept-contextbenadering.

De theoretische concepten worden geleerd door deze in een bepaalde context toe te passen.
In deze module zijn de concepten modelleren, valideren en testen met behulp van eindige automaten.
We gebruiken een robotstofzuiger als context om deze concepten te demonstreren en aan te leren, in de eindopdracht zul je de concepten ook zelf in een andere context toepassen.

Leerdoelen Robotstofzuiger

Je kunt de begrippen concept en context uitleggen en deze aanwijzen in een concrete situatie
Je kent de context van deze module, de Roomba 600
Je kunt het programma Greenfoot opstarten en gebruiken om een simulatie uit te voeren
Je kunt eenvoudige toegepaste Java code binnen Greenfoot lezen en uitleggen
Je kunt eenvoudige wijzigingen in het scenario maken en uitleggen
Je kunt een relatie leggen tussen de toestand van de Roomba en het gedrag van de Roomba

iRobot Roomba@600

Als context kiezen we een concreet voorbeeld, de "Roomba 600" robotstofzuiger.

Bekijk hieronder de video als introductie.

Roomba 600 video

Simulatie van de Roomba 600

In de introductie heb je een model van de werking van de stofzuiger gezien met behulp een eindige automaat. Dit model is goed te gebruiken om de toestanden van de Roomba te beschrijven, we komen hier in hofdstuk 2 weer op terug.

Een wat realistischer model kun je maken door een simulatie te maken die de Roomba echt laat zien en bewegen.

In dit hoofdstuk zie je daarvan een eerste versie die je zelf met de cursortoetsen kunt besturen.

Roomba 600 in Greenfoot

Greenfoot scenario openen

Voorbereiding

Kopieer de map Gym5Per3Bestanden vanaf de Lesmateriaal schijf.

Werk deze periode steeds in deze map zodat je de bestanden eenvoudig kunt terugvinden.

Greenfoot

Greenfoot is een programmeeromgeving die gebruik maakt van de taal Java.

Greenfoot kent een aantal extra klassen om redelijk eenvoudig met bewegende objecten om te gaan.

Start het programma Greenfoot vanuit je startmenu.
* Thuis kun je het gratis downloaden vanaf de download pagina van www.greenfoot.org

Je ziet een leeg startscherm
* of het laatst geopende scenario.

Kies voor <Scenario> <Open> (of Ctrl+O),

Selecteer de map RoombaVersie1 en kies voor Map selecteren.

Als het goed is zie je nu de Roomba in een rechthoekige kamer.

Roomba zelf besturen met pijltjes

Het scherm bestaat uit 3 delen

Links zie je informatie over de Roomba
In de kamer (middendeel) kun je de Roomba bewegen door middel van de pijltjetoetsen
In het rechterscherm zie je het klassendiagram met alle beschikbare objecten

Even verkennen

Kies onderaan het scherm voor <Run> (groene pijl)
Het programma is nu gestart, je kunt de Roomba bewegen door de kamer
Test dit en kijk naar het informatiescherm of je de informatie begrijpt
Hierna volgen een aantal vragen om over deze simulatie

Klassendiagram en broncode

Zorg dat je het Greenfoot scenario RoombaVersie1 (nog) open hebt staan.

Klassendiagram

In het rechterdeel zie je het klassendiagram waarin de verschillende objecten te zien zijn.

Greenfoot kent 2 soorten obecten:

Kinderen van het World object, simpel gezegd stellen deze de achtergrond voor en van hieruit start het programma.

Kinderen van Actor deze kunnen in de wereld worden geplaatst en daar acties uitvoeren (of daarop reageren).

De belangrijkste objecten in de Roomba simulatie:

Room [World] deze stelt de achtergrond voor en van hier uit worden de andere objecten in de Room geplaatst.

Roomba [Actor] deze stelt de robotstofzuiger voor, Roomba reageert op de cursortoetsen en kan acties uitvoeren als vuil opruimen, verder vult Roomba het informatiescherm (object Info).

Vuil [Aarde, Pluis en Spin] deze objecten kunnen zelf niets, ze hebben alleen een waarde voor 'vulling' en een afbeelding zodat ze zichtbaar zijn.

Broncode

Je kunt de broncode van elk object zien door rechts te klikken op het object in het klassendiagram
en dan <Open editor> (dubbelklikken werkt ook).

Open de broncode van de klasse Room, je zou dan onderstaande code moeten zien.

De methode (public) Room() is de constructor als het programma opent of na een 'Reset' wordt deze gebruikt om de wereld opnieuw te creëren (instantiëren).

Kijk goed naar de 3 opdrachten (methode aanroepen) die de kamer (Room) verder vormgeven:

setBackground("vloer.jpg");
maakMuren();
plaatsRoomba();

Scrol in de code editor naar beneden en kijk of je de methoden maakMuren en plaatsRoomba kunt vinden.

De code zelf hoef je niet precies te begrijpen.
maakMuren plaatst via twee herhalingsopdrachten de muur blokjes.
plaatsRoomba maakt en plaats een basisstation, het infoscherm en de Roomba zelf in de Room()

In de opgaven bij 'broncode aanpassen' doe je zelf wat aanpassingen aan de simulatie om het prgramma Greenfoot te verkennen en weer even aan Java te wennen.

Greenfoot, broncode aanpassen

Vuil plaatsen

Omdat het steeds met de hand plaatsen van vuil in de kamer veel tijd kost (en niet echt leuk is...) kunnen we dit ook bij het maken van de kamer al laten doen.

Dit is al voorbereid door twee methoden te maken in klasse Room:

- plaatsVuiltje()

- maakKamerVuil()

Naast onze zelfgeschreven methoden maken we regelmatig gebruik van methoden die Greenfoot (of Java) al kent, bijvoorbeeld addObject(...) en getRandomNumber(...).
Deze laatse is handig om willekeurig gedrag mee te beschrijven en wordt gebruikt in de methoden om vuil mee te plaatsen.

De preciese werking van deze methoden kun je vindne in de Greenfoot Class Documentation (Greenfoot API).

Opdracht altijd vuil in de kamer

Net zoals de stofzuiger vanzelf in de kamer komt kun je ook het vuil vanzelf aan het begin in de kamer plaatsen.

Dit vraagt een kleine aanpassing in de constructor van Room.

Kijk goed naar bijvoorbeeld de aanroep van maakMuren en voert deze aanpassing uit.

Les 3 Introductie mvvt

MVVT staat voor modelleren, valideren, verifiëren en testen.

Je kunt een systeem zoals een robotstofzuiger gewoon maken en dan testen of deze werkt (wat dat dan ook precies inhoud).
Helaas kan het herstelllen van fouten dan betekenen dat een deel of het gehele systeem opnieuw gemaakt moet worden.

Er zijn verschilllende manieren om dit te vermijden, één van die manieren is het modelleren van het systeem voor het daadwerkelijk te bouwen en aan de hand van dat model al een aantal testt uit te voeren.

Zowel de automaat als de simulatie uit de inrtroductie zijn voorbeelden van een model dat ons in staat stelt om zonder het systeem zelf te hoeven bouwen toch een aantal aspecten van dat systeem te bekijken. Hiermee kan tijd en geld worden bespaard en de kwaliteit worden vergroot.

Leerdoelen MVVT

Je kunt de begrippen modelleren, valideren, verifiëren en testen uitleggen en deze aanwijzen in een concrete situatie
Je kunt voordelen noemen van testen met behulp van een model
Je kunt het begrip specificatie uitleggen in relatie tot validatie en verificatie
Je kent het V model en de bijbehorende fasen

V-model

Bij onder andere systeemontwikkeling vind je vaak het zogenaamde V-shape model terug.

Het V-shape model geeft de stappen aan waarin je ontwerpt, vervolgens het systeem bouwt en hoe je kunt testen in de verschillende fases.

Er zijn heel veel varianten, in de afbeelding hieronder vind je een beknopte variant.

V-shape model systeemontwikkeling

-----------------------------------------------------------------------------------------------------------------------------------------------------

V-shape model uitleg

Je ziet dat de systeemontwikkeling de vorm van de V volgt in het model.

Vanaf linksboven eerst het ontwerp van idee tot aan het programmeren (coderen) van de software.

Vanaf onder naar rechtsboven volgt dan het testen van de code tot aan de werking van het gehele systeem.

Testen bij het V-shape model:

De horizontale lijnen geven aan welk soort test in verband staat met welke fase van het ontwerp.

Bijvoorbeeld is de "gebruikservaring" de test of het product overenkomt met het oorspronkelijke idee.

Nadeel V-shape model

Het belangrijkste nadeel van ontwikkeling volgens het V-shape model is dat pas getest kan worden als het syteem grotendeels of helemaal klaar is en iet in de ontwerpfase.

Indien bijvoorbeeld bij de systeemvalidatie eenfout wordt gevonden dan moeten de eisen worden aangepast en het gehele proces vanaf daar opnieuw worden doorlopen.

Testen met behulp van modellen

Een oplossing voor dit problem is om niet te testen met het uiteindelije product maar met een model van het product. Omdat een model maar een deel van de werkelijkheid bevat en vaak uitsluitend als software bestaat is aanpassen hiervan veel voordeliger.

In deze module gaan we uitvoeriger in op dit proces met behulp van twee soorten modellen, een eindige automaat en een simulatie met behulp van Java / Greenfoot.

Validatie en verificatie

Wikipedia geeft als uitleg bij validatie en verificatie onderstaande tekst:

In systeem- (en software-)ontwikkeling houdt validatie in dat gecontroleerd wordt of het gebouwde systeem voldoet aan de verwachtingen van de gebruiker ( de door de gebruiker gewenste functionaliteit ook wel User Requirement Specifications genoemd), terwijl bij de verificatie wordt gecontroleerd of het gebouwde systeem voldoet aan de gestelde eisen ('Software Quality Control').

Een eenvoudig ezelsbruggetje om validatie en verificatie uit elkaar te houden, is:

Validatie: men controleert of het juiste systeem is gemaakt (doet het wat de klant wil?)
Verificatie: men controleert of het systeem juist is gemaakt (zijn alle eisen verwerkt?)

Verificatie en validatie zijn afzonderlijke activiteiten die een verschillend doel dienen en horen ook beide uitgevoerd te worden.

Validatie en Verificatie

Validatie

In de vorige paragraaf stond voor validatie:

Men controleert of het juiste systeem is gemaakt (doet het wat de klant wil?).

Omdat het systeem zelf nog niet bestaat is het doel van de validatie om te kijken of de eisen van de gebruikers (specificatie) kloppen met de wensen van de gebruiker.

Kijk in het schema van de vorige paragraaf of je dit ziet bij de pijl van validatie!

Specificatie

Het is mooi om vast te stellen dat een systeem helemaal is gebouwd volgens de specificaties, maar als de specificaties niet weergeven wat de gebruker nodig heeft voldoet het systeem toch niet!

Bij de specificatie gaat het er om zo precies mogelijk aan te geven wat een product moet kunnen (functionaliteit), er worden meerdere termen voor gebruikt, zoals onder andere User Requirements Specifications, Pakket van Eisen).

Een voorbeeld bij de robotstofzuiger kan zijn:

De stofzuiger kan vuil in de hele kamer bereiken
Op een volle batterij kan de stofzuiger minimaal 4 uur werken
De stofzuier zal nooit met een lege batterij in de kamer blijven
....

Om aan te geven hoe lastig dit formuleren is:

Wat als een doorgang smaller is dan de stofzuiger, hoe groot (of zwaar) mag het vuil maximaal zijn, na hoeveel jaar moet de batterij nog steeds 4 uur 'werken'

Bij de validatie is de vraag:

Kloppen de specificaties en de user requirements bij elkaar

Voorbeeld
In de requirements wordt opgeschereven dat de Roomba bij botsen van richting veranderd
In de specificaties wordt hiervan gemaakt dat de Roomba bij botsen omkeert
Dit kan in werkelijkheid betekenen dat de Roomba tuissen twee muren heen en weer blijft gaan

Een manier om te valideren is het bouwen van een model dat aan de specificaties voldoet en dan met de gebruiker en requirements te kijken of dit ook voldoet.

Verificatie

Over verificatie staat in de paragraaf 'Validatie en verificatie:

men controleert of het systeem juist is gemaakt (zijn alle eisen verwerkt?)

Omdat het systeem nog niet bestaat gebruiken we een model om te testen of het model voldoet aan de specificaties (eisen).

Hierbij kunnen meerdere modellen worden gebruikt om verschillende aspecten van het (te bouwen) systeem te testen. In ons geval gebruiken we 2 modellen:

- Een eindige automaat

- Een simulatie

Met de eindige automaat heb je in hoofdstuk 1 al kennisgemaakt en zul je in week twee verder werken.

De eindige automaat kwam je in hoofdstuk 2 tegen en hier zul je in de derde week verder mee aan de slag gaan.

Het proces van validatie, verificatie en testen komt dan in week 4 weer uitgebreid terug.

Afronden week 1

Je hebt de introductie nu afgerond.

Kijk nog eens goed terug naar de leerdoelen van hoofdstuk1, hoofdstuk2 en hoofdstuk 3

De eerste les van week 2 begin je met een korte test op It's Learning van 15 minuten om te testen of je de leerdoelen hebt behaald en in hoeverre je ze kunt toepassen.

- Zie de studiewijzer voor de weging hiervan in het periodecijfer

Hoofdstuk 1 terugblik

Dit eerste hoofdstuk was een introductie van de gehele module:

Je hebt kennisgemaakt met eindige automaten (les 1) en met de context van deze module de Roomba robotstofzuiger. Over eindige automaten gaat hoofdstuk 2 en de eindopdracht.

In de tweede les heb je naast context - content onderwijs ook kennisgemaakt met het Java model gemakt in Greenfoot van de Roomba en gezien dat dit model meer aspecten kan testen. Hoofdstuk 3 gaat dieper in op deze vorm van modelleren met behulp van Grenfoot.

De derde les ging over de begrippen modelleren, valideren, verificeren en testen en de toepassing daarvan binnen softwareengineering. In hoofdstuk 4 gebruik je de automaat en de simulatie in relatie met valideren, verificeren en testen.

Lees nog eens goed de leerdoelen van de drie lessen en kijk of je deze beheerst.

Aan het begin van les 4 doe je een afsluitende test (15 minuten) op It's Learning om te toetsen of je de leerdoelen van de betreffende lessen hebt bereikt en op welk niveau.

Daarna ga je in hoofdstuk 2 je meer verdiepen in 'eindige toestandsautomaten'.

Hoofdstuk 2 Eindige automaten

In de introductievideo laat de auteur zien hoe hij een eindige toestandsauomaat (Finite State Machine) maakt bij de Roomba en daarna gebruikt hij een programma om de automaat te kunnen doorlopen.

In les 1 heb je hier al naar gekeken in dit tweede hoofdstuk (les 4, 5 en 6) ga je dieper in op het onderwerp eindige automaten.

Door de Engelse begrippen naar het Nederlands te vertalen maak je kennis met de belangrijkste begrippen en door zelf een automaat te maken, vervolgens te bouwen in de software en daarna te gebruiken ga je steeds dieper op het onderwerp in.

Na hoofdstuk 2 krijg je ook hier weer een korte test over om te kijken in hoeverre je de leerdoelen beheerst.

Les 4 Eindige automaten

Deze les gaat over een eindige toestandsautomaat kort ook wel eindige automaat genoemd. Het woord eindig betekend in dit geval dat er een beperkt aantal toestanden mogelijk is.

Eindige automaten worden onder andere gebruikt om systemen mee te beschrijven die zich altijd in één bepaalde toestand bevinden. Een dergelijk systeem kan een robotstofzuiger zijn, zoals in deze leereenheid, maar ook een dvd speler, een game, een lift enzovoort.

Voordat je de eindige automaat gaat gebruiken leer je in deze les een aantal begrippen rond eindige automaten.

Leerdoelen eindige toestandsautomaten

Je kunt in een toestandsdiagram een toestand en een toestandsovergang aanwijzen.
Je kunt in een toestandsdiagram de begintoestand en mogelijke eindtoestanden aanwijzen.
Je kunt een eindige toestandsautomaat doorlopen bij gegeven overgangen.
Je kunt de automaat koppelen aan het gedrag in de bijbehorende context.
Je begrijpt dat de automaat los staat van de gebruikte context.
Je kunt een valide serie overgangen noemen en niet valide overgangen herkennen.

Toestandsdiagram

Bekijk nog eens het deel van de introductievideo over eindige automaten (vanaf tijdstip 0:40 tot 3:00).

De auteur heeft het onder andere over Finite State Machine, state (starting en final acceptance) en transition.

Introductie video (kijk van 0:40

Begin-, eindtoestand en overgang

In de toestandsdiagrammen zoals hier worden gebruikt is er altijd precies één begintoestand.

Een eindtoestand is niet verplicht en er mogen ook meerdere eindtoestanden bestaan.

Een overgang wordt ook wel toestandsovergang genoemd.

Vertaalde automaat bij de Roomba

Zoals je al zag in de video is het gebruikelijk om het toestandsdiagram om te zetten naar een versie waarbij toestanden en overgangen met één letter worden weergegeven.

In deze module doe je dit in twee stappen:

- Vertaal de toestanden en overgangen naar het Nederlands

- Kort alle toestanden en overgangen af met één letter

Bekijk eerst nog eens het toestandsdiagram uit de video hieronder:

Toestandsdiagram uit de video

In principe kun je de namen en afkortingen zelf kiezen maar omdat we deze bij volgende opdrachten nodig hebben is het belangrijk dat we allemaal dezelfde gebruiken.

Bekijk het toestandsdiagram hieronder en neem de namen en afkortingen zorgvuldig over op werkblad 1 die je van je docent hebt gekregen (je vind de werkbladen ook bovenin deze cursus onder bijlagen).

Toestandsdiagram gebruiken

Nu je toestandsdiagram klaar is kun je dit gebruiken om te kijken welk gedrag van de Roomba mogelijk of juist niet mogelijk is.

In hoofdstuk 4 (mvvt) ga je hier verder op in.

Les 5 Automaton simulator

Het toestandsdiagram uit les 4 is een goede beschrijving van een automaat maar geeft alleen een statische (stilstaande) situatie weer.

Om eenvoudiger te kunnen zien welk gedrag een automaat kan vertonen geeft een simulatie meer inzicht. Je kunt in dat geval ook spreken van een dynamische (in de tijd veranderende) beschrijving.

In deze les maak je kennis met een zeer eenvoudige simulatie voor automaten, de 'automaton simulator'.

Automaton simulator uit de video

Leerdoelen automaton simulator

Je kunt in de automaton simulator een toestandsdiagram invoeren.
Je weet wat een scenario is en wanneer dit geldig en ongeldig is.
Je kunt met behulp van de simulator onderzoeken of een scenario 'geldig' is.
Je kunt onderzoeken of toestanden bereikbaar zijn en snapt wat dit betekent in de werkelijkheid.
Je kunt onderzoeken of er 'deadlock' kan optreden en begrijpt wat dit in de werkelijkheid betekent.
Je weet dat er ook 'timed automata' bestaan en wat het verschil is met de automaat in deze module.

Automaton Simulator

De simulator die je zult gebruiken is een heel eenvoudige gratis simulator, die ook de auteur van het introductiefilmpje demonstreerde.

Op school kun je de simulator starten vanuit je gekopieerde bestanden uit de lesmateriaal schijf. Dubbelklik op RoombaAutomaat.jar.

Thuis kun je via It's Learning het bestand downloaden.
Het programma gebruikt Java, mocht je dit niet op je computer hebben dan kun je dit gratis downloaden.

In de paragraaf hierna vind je een korte handleiding over het gebruik van de automaton simulator, bekijk deze even vooraf en gebruik deze als je er niet uitkomt (op de website http://www.cburch.com/proj/autosim/ staat ook nog een Engelstalige handleiding).

Pak je toestandsdiagram uit les 4 erbij (je hebt dat op papier gemaakt).

Bouw dit Nederlandse toestandsdiagram in de automaat na.

In de afbeelding hieronder zie je hoe het resultaat moet worden.

Het toestandsdiagram van de Roomba in de Automaton simulator

Uitleg gebruik Automaton Simulator

Uitleg Automaton simulator

In de afbeelding hieronder zie je via tekstballonetjes een korte uitleg.

LET OP:

- De naam van een toestand voer je in via 'tekst toevoegen'.

- Een lus kies je door twee keer op dezezelfde toestand te klikken.

- Met 'overgang' actief kun je de pijlen en bijbehorende namen verplaatsen op het scherm.

- Met 'toestand' actief kun je toestanden verplaasten.

- Teksten kun je niet verplaatsen alleen maar vewijderen en opnieuw maken
(dit geldt ook voor namen van toestanden).

- Als de simulatie is gestart kun je door de juiste letter een overgang simuleren (zie ook volgende opdracht).

- Via het <File> menu kun je een automaat bewaren en weer openen.

Valid of non-valid in de siumulator

Bekijk nu nog eens het deel van de introductievideo over de simulator (vanaf tijdstip 3:00 tot 5:00).

De auteur heeft het over 'valid cleanings' en laat zien hoe deze met de automaton simulator kunnen worden getest en hoe zonodig de automaat kan worden aangepast.

In de opdrachten hierna ga je daar zelf mee aan de slag, kijk indien nodig terug naar de video.

Introductie video (kijk vanaf 3:00 tot 5:00)

Hoe kun je nu met de simulator een gegeven rij overgangen simuleren?

En hoe zie je aan de simulator of een bepaald rijtje overgangen (in dit geval een cleaning) 'valid' is of niet?

In de volgende opdracht probeer je dit zelf uit.

- Start de simulator en open je bestand dat je hebt bewaard (als het niet lukt bekijk dan Les5.asim).

- Klik op de groene pijl om een simulatie te starten.

- De begintoestand wordt als het goed is groen.

- Beantwoord nu door uit te proberen de twee meerkeuzevragen hieronder.

In de video laat de auteur zien hoe je met behulp van de simulator kunt zien of een bepaalde 'cleaning' valid of non-valid is.

Hoe zie je dit precies in de automaton simulator?

Probeer nog enkele rijtjes uit en ga wat heen en terug met backspace en de juiste letters.

- Kun je ook andere letters ingeven dan de namen van overgangen?

Scenario's

Scenario's vertalen

De auteur gebruikt voor een aantal opeenvolgende toestanden het woord cleaning (schoonmaak).

In het algemeen wordt een aantal opeenvolgende toestanden die in een bepaalde volgorde optreden ook wel een scenario genoemd.

Als een scenario door de automaat kan worden uitgevoerd dan is het een geldig scenario, de auteur gebruikt hier de term valid cleaning.

Bereikbaarheid en deadlock

Automaten worden vaak gebruikt om te onderzoeken of specifieke gewenste of ongewenste scenario's kunnen voorkomen.

In het geval van de Roomba is een gewenste situatie bijvoorbeeld dat de Roomba altijd bij het basisstation terugkeert (eindtoestand).
Anders gezegd 'Is de toestand Uit bereikbaar vanuit elke toestand of in elke situatie'.

Een ongewenste situatie bij de Roomba zou zijn als deze bijvoorbeeld blijft draaien.
Anders gezegd 'Kan het voorkomen dat de automaat in toestand Draai blijft steken'. Een dergelijke situatie wordt meestal aangeduidt met het Engelse woord deadlock.

Bereikbaarheid

Open je automaat in de simulator en probeer of het scenario oovrah mogelijk is?

Waar staat dit scenario voor?

De batterij/accu raakt leeg tijdens stof opzuigen, wat zou kunnen betekenen dat de Roomba uitvalt en niet terugkeert. Met andere woorden toestand U is niet bereikbaar vanuit toestand V.

De auteur lost dit op door een extra overgang te maken.

Deadlock

De situatie deadlock kun je waarschijnlijk zelf wel bedenken nu.

De automaat (Roomba) bevindt zich in een toestand waar deze niet uit komt in een bepaalde situatie / scenario.

Bijvoorbeeld als na het draaien steeds een obstakel in de weg staat zal de Roomba eeuwig in toestand draaien blijven, kan dat ook voorkomen?

Tijd in model

Een probleem als in de vraag hiervoor kun je in deze automaat niet goed oplossen.

Een mogelijkheid is om de tijd in de automaat te laten tellen.

Je kunt dan een overgang maken met iets als:

'Als de plek na 10 seconden niet schoon is ga dan terug naar toestand Loop' of zelfs een toestand 'geef waarschuwing'erbij kunnen maken ...

Automaten waarmee je ook de tijd kunt modeleren worden veel gebruikt en worden 'Timed automata' genoemd.

Wij zullen hier in deze module niet verder op in gaan.

Les 6 Een automaat in een andere situatie

Wendbaar toepassen

In les 2 heb je al even kennisgemaakt met het begrip concept (o.a. modelleren, testen) en context (roobotstofzuiger). Eén van de belangrijke kenmerken daarbij is dat je het concept ook in een andere context kunt toepassen. In de theorie heet dat wendbaar toepassen.

Leren wordt dan gedefinieerd als een stabiele verandering in kennis die ook, in zekere mate, wendbaar kan worden ingezet (Reintz & Willekers in SLO toolkit).

- Stabiel betekent dat leren voor een toets en dan weer vergeten hierbij niet onder leren valt

- Wendbaar betekent dus ook in een andere context / situatie kunnen gebruiken

Daarom maak en gebruik je in deze les een automaat als model voor het aansturen van verkeerslichten op en kruising en ontwikkel je in de eindopdracht ook zelf nog en model.

Leerdoelen wendbaar toepassen automaat

Je kunt bedenken wat voor en nadelen zijn van het kiezen van een bepaald model.
Je begrijpt dat het aantal toestanden snel te groot wordt.
Je kunt zelf een automaat maken bij een situatie.
Je kunt de automaat in de simulator bouwen en gebruiken.
Je kunt met behulp van het model en de automaat redeneren over de werkelijke situatie.
Je begrijpt dat voor een goede werking tijd vaak belangrijk is.

Een kruising met verkeerslichten

Diegenen van jullie die al met hun theorieexamen bezig zijn zullen onderstaande afbeelding wel herkennen.

Een eenvoudige kruising met verkeerslichten die worden aangestuurd door een eenvoudig programma.

In de wegen zijn 'detectielussen' aanwezig zodat het programma kan zien of er verkeer bij het verkeerslicht wacht.

Je kunt een aantal eisen direct al bedenken ...

Niet alle verkeerslichten mogen tegelijk groen zijn (veiligheid).
Een verkeersdeelnemer wil niet eeuwig voor een rood licht staan te wachten.

kruising met verkeerslichten

Je ziet dat zelfs zonder links- of rechtsaflichten het aantal toestanden snel heel groot wordt.

Een verschijnsel dat het gebruik van automaten niet in elke situatie geschikt maakt en ook wel wordt aangeduidt met state explosion (explosie van toestanden).

In de praktijk kun je door wat slimmer nadenken ook vaak het aantal toestanden in het model wel beperken, dat doe je in de volgende paragraaf.

Model (automaat) van de situatie

Model en doel

Zoals je bij informatica al eerder bent tegengekomen helpt het om de werkelijkheid eenvoudiger te maken door dit in een model weer te geven. Een model bevat alleen die aspecten die belangrijk zijn voor het doel van het model.

In ons geval kiezen we als model een eindige toestands automaat (kort noemen we deze gewoon automaat) en het doel van ons model is om de verkeerslichten aan te sturen.

Aannames

Om het model eenvoudiger te maken doen we enkele aannames:

Verkeerslichten tegen over elkaar hebben altijd dezelfde kleur.
Als één kant op rood 'springt' wordt de andere kant gelijktijdig groen.

De afbeelding hieronder staat ook op het werkblad:

Vul de tabel op het werkblad 2 verder in, de toestanden die niet zijn toegestaan hoef je niet op te nemen.
De werkbladen heb je van je docent ontvangen en vind je ook bovenin deze cursus onder bijlagen.

Nu je de toestanden weet kun je ook de overgangen bepalen en het toestandsdiagram invullen op werkblad 3.
De werkbladen heb je van je docent ontvangen en vind je ook bovenin deze cursus onder bijlagen.

Bijbehorende automaat

In de volgende opdrachten bouw je een bijbehorende automaat in de Automaton Simulator.

Open SimulatorVerkeerslicht.jar (dit is een iets andere versie dan voor de Roomba).

- Maak de 4 toestanden RG RO GR en OR en zet de naam in de juiste toestand.

- Maak toestand RG de begintoestand, er is geen eindtoestand in dit model.

- Maak ook de overgangen, de letter w betekent de overgang als het licht van kleur moet wisselen.

- Overgang b betekent dat de situatie hetzelfde blijft, een lus (er is geen wachtend verkeer).

In de volgende paragraaf staat een schermafbeeldingvan een mogelijke oplosing kijk of jouw model hetzelfde gedrag vertoont!

Voorbeeld model om te testen

voorbeeld automaat verkeerslichten

Het model lijkt redelijk in orde maar in de volgende twee vragen zie je in elk geval 2 problemen.

Eén van de lastige situaties bij modelleren is om ook te testen voor onverwacht of onlogisch gedrag van de gebruiker. Vaak gebeurd dat per ongeluk, soms ook express om het systeem te hacken of te saboteren.

Zoals ook bij de Roomba al even genoemd werd is de tijd vaak een belangrijk aspect bij het toepassen van automaten om software te beschrijven.

Voor deze situatie zou je twee eenvoudige oplossingen kunnen bedenken:

- Controleer maar één keer per minuut of er wachtend verkeer is.
je moet dan wel een tweede overgag 'w' kort daarna geven anders blijft het licht ook een minuut oranje!

- Vijf wacht toestanden maken zodat pas na zes keer weer een overgang van GR naar OR mogelijk is

PS: Een 'timed automata' kan een voorwaarde stellen dat de toestand pas an een minuut verlaten mag worden of juist na 10 seconden verlaten moet worden enzovoort.

Afhankelijk van de tijd

Om te voorkomen dat het verkeerslicht te vaak wisselt moet je model (of in elk geval de echte software) dus ook rekening met de tijd houden.

Bijvoorbeeld 1 maal per minuut kijken of er verkeer staat te wachten en dan een overgang w starten gevolgd door een tweede w na bijvoorbeld 10 seconden.

Staat er geen verkeer dan volgt de overgang b (de lus).

Hierna gaat de overgang opnieuw in.

Hoofdstuk 2 terugblik

In grote lijnen zijn er 3 functies bij het gebruik van modellen zoals automaten tijdens systeemontwikkeling.

1. Inzicht in een probleem
Een eindige automaat bedenken helpt de ontwikkelaar (jou dus) om een complex probleem helder en overzichtelijk te maken.
Bij de Roomba en de verkerslichten kun je vooraf bepalen welke toestanden nodig zijn, wat de software moet doen en welke sensoren en actuatoren daarbij nodig zijn. Bij de verkeerslichten zag je ook dat het model eenvoudiger kon dan op het eerste gezicht leek.

2. Compleet en veilig ontwerpen
Eindige automaten zijn ook een handig hulpmiddel te kijken of een apparaat doet wat het moet doen en of het veilig is. Er wordt daarbij onderscheidt gemaakt in liveness (wat moet wel voorkomen) en safety (wat mag juist niet voorkomen) eigenschappen.

Bij de Roomba kwam je vragen tegen als "Kan alle vuil worden opgezogen (anders gezegd is de hele kamer op één of andere manier bereikbaar en gebeurd dat ook?) en ook bivoorbeeld "zal de Roomba nooit blijven staan zonder stroom?".

3. Theoretische informatica
Ten slotte spelen eindige automaten ook een belangrijke rol in de theoretische informatica. Bijvoorbeeld het bepalen of een bepaald algoritme correct, effectief en efficiënt is.

Bij de Roomba zou je kunnen denken of de route van de Roomba wel slim wordt gekozen zodat alle plaatsen ongeveer even vaak worden bereikt.
Of zelfs dat vuile plaatsen vaker dan minder vuile plaatsen wordn bezocht. In dit laatse geval kom je al op het grensvlak van kunstmatige intelligentie.

Inmiddels heb je weer 3 lessen (een weektaak) afgerond. Aan het begin van de volgende les maak je eerst weer een testje over de leerdoelen van les 4 les 5 en les 6, bekijk deze nog eens!

In de test gaan we er vanuit dat je zelf een eenvoudige automaat kunt satrten en aanvullen met behulp van de Automaton Simulator.

Hoofdstuk 3 simulatie

In les 2 van de introductie (hoofdstuk 1) heb je al even kennis gemaakt met de Java in Greenfoot, in dit hofdstuk ga je hier dieper op in en verder mee aan de slag.

Als eerste ga je van de besturing via de cursortoetsen over naar een zelflopende Roomba (versie 2)

Vervolgens maak je zelfstandig een aantal aanpassingen om het prgramma te begrijpen en daarna ga je de simulatie gebruiken om het gedrag van de Roomba te bestuder en verbeteren .

Roomba simulatie versie 1

Les 7 Roomba zelflopend

In de introductie van hoofdstuk 1 heb je kennisgemaakt met de simulatie van een robotstofzuiger, de Roomba 600. Deze eerste versie kon je zelf besturen met behulp van de pijltjestoetsen.

In dit hoofdstuk ga je verder met versie 2 die als zelfrijdende robotstofzuiger functioneert. Net als de automaat betekent dit dat de Roomba obsatkels moet detecteren, vuil moet kunnen opzuigen en naar huisa moet gaan als de accu bijna leeg is.

Door aanpassingen te doen aan het Java model gemaakt in de Greenfoot omgeving leer je het model kennen en breidt je je Java programmeerkennis uit in deze lessen.

Hieronder nogmaals het toestandsdiagram waar de Roomba zich naar moet gedragen.

Toestandsdiagram Nederlands

Leerdoelen Java simulatie in Greenfoot

Je kunt zelfstandig een scenario openen, starten en bewaren zonder verdere aanwijzingen.
Je kunt instanties (= objecten) maken van vuil.
Je begrijpt de werking van extends achter de naam van de klasse in Java/Greenfoot.
Je begrijpt de specificatie static en final voor het gebruiken van constanten.
Je kunt eenvoudige aanpassingen in het model maken en testen om het gedrag te veranderen.
Je kunt in een nieuwe situatie beslissen welke klasse het best als ouder kan worden gekozen.

Roomba zelf lopend

Zoals je in de inleiding (hoofdstuk 1 les 2) hebt gezien kan een simulatie van de werkelijkheid meer inzicht geven in de werking van de robotstofzuiger dan een automaat. Ook kunnen andere zaken worden getest en andere problemen worden opgespoord voordat de software daadwerkelijk wordt geschreven en ingebouwd.

Daar staat als nadeel tegenover dat een simulatie ook lastiger te bouwen is en meer tijd kost.

Starten Greenfoot en Roomba versie 2

In les2 staat hoe je Grenfoot opent en een scenario opent, via de link les 2 kun je dat nog eens bekijken. Kies in dit geval echter voor RoombaVersie2 ipv RoombaVersie1. In de volgende opdrachten en in de test na hoofdstuk 2 gaan we er van uit dat je zelfstandig een scenario kunt openen en uitvoeren.

Laten we eerst eens kijken hoe de Roomba zich in deze versie gedraagt.

Met <run> kun je starten en met <reset> en dan weer <run> opnieuw beginnen.

Omdat het effect bij een lage accuspanning snel te kunnen zien staat het batterijverbuik vrij hoog, het is realistischer als de Roomba een tijdje kan rondlopen.

Open de broncode van klasse Roomba, dit kan op twee manieren. Je kunt dubbelklikken op de klasse Roomba of rechts klikken en dan <open editor> kiezen.

Je ziet dan onderstaand scherm.

Broncode klasse Roomba

We kijken eerst naar regel 9 van de boncode.

public class Roomba extends Actor

De naam van de klasse is Roomba, deze staat altijd achter het java woord class

extends Actor geeft aan dat niet alleen de methoden in de klasse Roomba kunne worden gebruikt maar ook alle methoden die door Greenfoot in de klasse Actor zijn geschereven. We komen hier nog op terug.

Variabelen

Onder de naam van de klasse staan alle namen van variabelen die in de klasse Roomba worden gebruikt, sommigen daarvan hebben al een beginwaarde zoals batterijPercentage en vulling.

batterijPercentage = 100, geeft aan dat de batterij vol is, je ziet dit percentage afnemen in het infoscherm aan de linkerkant als de Roomba loopt.
vulling = 0 betekent dat de Roomba leeg is, dit getal neemt toe als de Roomba vuil op gaat zuigen.

Constanten

De laatste twee variabelen onder de commentaarregel // standaardwaarden zijn zogenaamde contanten. Waarden die tijdens het uitvoeren niet veranderen, je herkent ze aan static final.

static betekent dat ze voor elke instantie van de Roomba dezelfde waarde hebben.

final geeft aan dat de waarde niet mag worden gewijzigd tijdens de uitvoering van het programma.

Looppatroon

Nu het stroomverbruik wat realistischer is kunn we eens naar het looppatroon van de Roomba kijken.

Als het goed is zijn je al twee zaken opgevallen:
- De Rooba loopt zonder van richting te veranderen over het oplaad station
Dit laten we zo door te stellen dat dit in de grond is weggewerkt waardoor dit mogelijk is.

- De Roomba loopt alleen maar langs de muren en zuigt alleen langs de randen
Dit moet worden aangepast

Voordat je dit veranderd is het belangrijk dat je nadenkt over de oorzaak en over een strategie (een plan) om dit aan te passen.

De oorzaak is vrij eenvoudig, zodra de Roomba iets ziet zal deze 90 graden draaien (toestand D), in een rechthoekige kamer betekent de 90 graden dat de Roomba langs de muren blijft lopen.

Looppatroon aanpassen

We willen dus dat de draai van de Roomba (deels) door toeval wordt bepaald.

Daarvoor moet je in elk geval twee dingen weten:

Hoe in Greenfoot / Java een Random getal te maken?
Waar in de broncode moet de draaihoek worden aangepast?

1-Hoe in Greenfoot / Java een Random getal te maken?

Om code te zoeken die je nog niet kent heb je de 'gebruiksaanwijzing' van de programmeertaal nodig, in vaktaal API (Application Programming Interface) genoemd.

Greenfoot API

In het hoofdscherm van Greenfoot vind je bij Help zowel de Greenfoot Class Documentation (Greenfoot API) als de Java Library Documentation (Java API). Een programmeur met enige ervaring kan hier alle beschikbare standaard code van Java en Greenfoot vinden.

Open de Greenfoot Class Documentation (je hebt dat in les 2 ook al gedaan).

Kies voor de klasse <Greenfoot> en scroll naar beneden tot je de methode getRandomNumber(....) ziet, zie de afbeelding hieronder.

methoden van klasse Greenfoot

Als je de methode getRandomNumber(int limit) wilt gebruiken moet je aangeven dat deze in de klasse Greenfoot is te vinden door dit voor de methode te zetten gescheiden door een punt.

Greenfoot.getRandomNumber(...) geeft dus een toevals getal van 0 tot het ingegeven getal, ga dat na.

2- Waar in de broncode moet de draaihoek worden aangepast?

Open weer de broncode van klasse Roomba en zoek naar de methode

public void act()

Toelichting:
void betekent dat deze methode geen 'antwoord' geeft maar alleen iets doet.
De methode act() wordt zodra je op <Run> drukt in het programma steeds herhaald uitgevoerd.

Het onderstaande stukje code zogt dat als er geen obstakel is de Roomba een stap loopt en als de weg niet vrij is (else) 90 graden draait door de methode draai(90).

if ( wegVrij() ) { // Kijk of er iets voor de Roomba staat
move(5);
Greenfoot.delay(4);
batterij = batterij - stroomVerbruik;
schrijfToestand();
}
else {

draai(90);
toestand = "L";
schrijfToestand();
}

Nu zou de aanpassing niet moeilijk meer moeten zijn, vervang de 90 door de juiste code voor het random getal van 45 t/m 135 (je antwoord op de vorige vraag en test je code!

Vuil plaatsen

Tot nu toe heb je alleen gekeken naar het gedrag van de Roomba en de bijbehorende broncode van de klasse Roomba. Zodra je het scenario RoombaVersie2 (en ook al bij versie1) opent werd er automatisch een instantie (= object) van de Roomba klasse gemaakt. Dit gebeurd vanuit de klasse Room, we kijken daar in les 8 verder naar.

De kamer is echter nog helemaal schoon zodat de Roomba nutteloos rondjes loopt.

Aan de rechterkant van het scherm zie je een klase Vuil met darbij 3 soorten 'vuil' namelijk Aarde, Pluis en Spin.

Plaats van Aarde 1 instantie, van Pluis 2 instanties en van Spin 3 instanties in de kamer, dit doe je door:

<rechts klikken> op de klasse (bv Aarde).
kies voor new Aarde() je gebruikt de constructor van klasse Aarde om een instantie te maken.
plaats deze door <links klikken> in de kamer (Room).

Laat de Roomba stofzuigen en kijk of deze al het vuil opruimt (verhoog eventueel de speed rechtsonder).

Zelfs dan kan het wel even duren! Kijk ondertussen naar wat er met de vulling gebeurd in het info scherm (links van het scherm) en beantwoord de vraag hieronder.

Subklassen van Vuil

Hiernaast zie je het zogenaamde klassendiagram van RoombaVersie2. Je ziet dat de 3 klassen Aarde, Pluis en Spin via een witte pijl schuin onder Vuil staan. Dit geeft aan dat zij als het ware tot de familie Vuil behoren.

Zij hebben veel overeenkomsten maar ook enkele verschillen.

Hun afbeelding is verschillend maar ook de waarde waarmee ze de stofzuiger vullen is verschillend.

Klassendiagram

Als je nog tijd over hebt zou je op deze manier eenvoudig zelf een soort vuil kunnen toevoegen.

Een afbeelding toevoegen kan via de keuzemenu's (rechts klikken).

Je moet de afbeelding dan eerst in de submap images van RoombaVersie2 plaatsen.

Les 8 De kamer vullen met vuil

Je ziet dat het plaatsen van instanties van Vuil op deze manier wel werkt maar bewerkelijk is en steeds weer opnieuw moet gebeuren.

Het automatisch plaatsen van vuil vanuit de wereldklasse Room wordt in deze les gebruikt om te kijken hoe insatnties worden gemaakt en willekeurig geplaatst.

Leerdoelen de kamer vullen

Je kunt automatisch instanties laten maken en plaatsen van bestaande klassen.
Je kunt de Greenfoot API zelfstandig gebruiken.
Je kunt nieuwe subklassen maken en gebruiken.
Je begrijpt de toegevoegde waarde van Greenfoot bij Java.

Wereldklasse Room

Zoals gezegd zie je als je het scenario opent al direct de kamer met de Roomba en het thuisstation. Ook de muren hebben al een plaats op het scherm.

Hoe komt dit en wat kun je er zelf mee.

In simpele vorm heeft Greenfoot 2 soorten klassen, kijk in het klassendiagram of je dit ziet!

Subklassen (ook wel kinderen genoemd) van klasse World, in dit geval is dat Room.

Subklassen van klasse Actor, in dit geval Info, Kamer, Roomba, Thuis, Vuil en ook de Subklassen daarvan.

Greenfoot

De Greenfoot omgeving is zo ontwikkeld dat er aan het begin altijd een instantie van de subklasse van World wordt gemaakt.
In java taal: de constructor van Room wordt aangeroepen, de constructor is de methode met dezelfde naam als de klasse.

Open de broncode van Room en zoek de costructor op, deze heet dus Room().

De methode aanroep super(1280, 768, 1,true); is een bijzondere.

Omdat deze in klasse Room staat (een subklasse van World) betekent dit dat de constructor van de superklasse (de ouder) wordt aangereoepen.

In dit geval kun je hiervoor ook lezen World(1280, 768, 1, true), zoek deze constructor op in de greenfoot API en vul in wat de waarden betekenen.

Zoals je zag waren er nog twee methoden die niet in de API stonden.

maakMuren() en plaatsRoomba()

Aan de Nederlandse naam die specifiek voor dit scenario is (Roomba) kon je ook al afleiden dat dit geen standaard methode van Greenfoot of van Java is.

Als je kijkt in de broncode van klasse Room zie je dat de beide methodes daar netjes in staan.

Alle code die in maakMuren() staat hadden we ook in de constructor kunnen plakken maar door dit in een aparte methode te zetten wordt de broncode overzichtelijker.
Bovendien kun je eenvoudig de methode maakMuren() aanpassen zonder met de overige code rekening te hoeven houden.

Je ziet hier het toepassen van twee belangrijke programmeerprincipes:

- Geef een methode één verantwoordelijkheid.
- Zorg dat je code overzichtelijk en begrijpelijk is.

De kamer automatisch vuil maken

Net zoals de muren automatisch worden geplaatst kun je ook vuil automatisch in de kamer plaatsen.

Een derde belangrijk principe bij programmeren is (gescheiden verantwoordelijkheid en begrijpelijkheid waren de eerste twee) is om stap voor stap te werken en tussendoor te testen.

De eerste stap is om een methode te maken in de broncode van de klasse Room die als taak krijgt om het vuil te plaatsen. Noem de methode plaatsVuil() schrijf het commentaar (Javadoc) erbij en laat de methode in eerste instantie nog niets doen.

/**
* Plaats vuil (Aarde, Pluis en Spin instanties) in de kamer op verschillende plaatsen
*/
public void plaatsVuil()
{
// hier komt de code

}

* De methode maakMuren begint met de toegagsspecificatie private je ziet dat hier is gekozen voor public dit is gedaan om eenvoudiger te kunnen testen binnen Greenfoot, als je helemaal klaar bent maak je de methode weer private zodat deze niet va buiten de klasse Room kan worden uitgevoerd.

Testen

Vertaal je code <Compile> en los eventuele fouten (syntax error(s) op.

Ga naar je hoofdscherm en klik rechts ergens in de kamer als het goed is zie je je methode void plaatsVuil() in de keuzelijst net onder inhereted from World.

* De methoden maakMuren() en plaatsRoomba() zie je niet omdat deze toegangsspecificatie private hebben.

Test je methode in Greenfoot net zaols je hiervoor hebt gedaan en kjk of je de aarde instantie ziet (<compileren> en rechts klikken in de Room).

* Wacht nog even met stofzuigen dat is tijdrovend ;-)

De plaats door toeval laten bepalen

Om te testen is het niet goed om steeds vuil op dezelfde plaatsen te zetten, je test dan maar één situatie tenslotte.

Je kunt hier op twee manieren mee omgaan:

- Maak een aantal testen en kijk speciaal naar moeijke situaties, vuil in de hoeken vlak bij de muur enzovoort
- Het vuil willekeurig laten plaatsen en een aantal test uitvoeren

In deze les kies je voor de laatste methode.

Het eerste wat je moet weten is hoe groot de kamer precies is zodat het vuil niet buiten de kamer komt.

Omdat je dit nog vaker nodig hebt is het slim dit op schrijven, doe dat op werkblad 4.
De werkbladen heb je van je docent ontvangen en vind je ook bovenin deze cursus onder bijlagen.!

Als je rechts klikt in de Room dan kun je met de optie inspect zien dat de width en height de waarden hebben van respectievelijk 1280 en 768.
Helaas is dat niet voldoende omdat de muren en het infoscherm ook binnen de Room vallen.
Je moet het dus iets slimmer aanpakken bijvoorbeeld door de x en y coördinaten van de muurblokken te bekijken. Ook dat kan gelukkig in Greenfoot.

Inspect scherm van een Actor instantie, in dit geval Muur

Via rechts klikken op een muurblok kun je via <inspect> de plaats en de maat van dat object / instantie bekijken.

LET OP: De waarde voor x en y zijn het midden van de instantie, bij imageWidth en imageHeight kun je de groote van het muurblok vinden.

Nu je de maten van de kamer weet is het niet moeilijk te bepalen waar het vuil moet komen.

Bedenk dat de vuil instantie sook een maat van 32x32 hebben je moet dus minimaal 16 optellen of aftrekken van de grenzen.

Misschien herinner je je dat we in hoofdstuk 1 les 3 deze methode in RoombaVersie1 ook al hebben gebruikt.

Als het goed is begrijp je nu precies hoe de methode werkt en kun je deze in de broncode invoegen.

Test je methode een aantal keer en kijk of er steeds aarde wordt geplaatst op een willekeurige plaats.

* Ga niet verder voor dit goed werkt!

Flink vuil maken

In principe heb je nu alle ingrediënten om de kamer flink vuil te maken, er moeten nog drie dingen gebeuren.

Een herhalingslus waarin een behoorlijk aantal vuiltjes worden geplaatst.
Zorgen dat niet alleen aarde maar ook pluisjes en spinnetjes worden geplaatst.
De methode vanzelf laten starten als de Room wordt gemaakt aan het begin.

Hiervoor stond de code al grotendeels in de Roomba versie 1 en zullen we toevoegen in de volgende vragen. Je gebruikt later nog eenzelfde soort code voor het plaatsen van obstakels.

1 - herhalingsopdracht

Het idee is om tusen de 20 en 50 stuks vuil te plaatsen, je doet dat in een herhalingsopdracht waarbij weer een random getal wordt gebruikt voor het antal herhalingen.

2 - keuze uit aarde, pluis of spin

Het kiezen tussen aarde, pluis of spin doen we ook weer met een toevalsgetal.

Je ziet nu het voordeel dat alle 3 de soorten vuil subklassen zijn van klasse Vuil, hierdoor kunnen we ze op dezelfde manier toevoegen.

Omdat er 3 keuzen zijn beginnen we met een random getal 0, 1 of 2:

Let op dit gebeurd binnen de for loop (lus) want we willen steeds een nieuwe keuze in elke herhaling.

int vuilKeuze = Greenfoot.getRandomNumber(3); // toevalsgetal 0,1 of 2

Vuil vuil; // declareer en instantie van vuil, nog niet bekend is welk soort

if (vuilKeuze == 0) { vuil = (Vuil) new Aarde(); }
else if (keus == 1) { vuil = (Vuil) new Pluis(); }
else {... } zie de vraag hieronder voor de code tussen de accolades

Er is nog één begrip dat niet is uitgelegd maar wel gebruikt, de zogenaamde casting.

Om bij het opzuigen verschil te kunnen maken tussen obstakels (muren en dergelijke) en vuil (een muur mag niet worden opgezogen) is het handig om niet te hoeven controleren of iets Aarde, Pluis of Spin is (of welk vuil je nog wilt maken) maar alleen maar of het van het soort Vuil is.

De casting (Vuil) zorgt dat het Aarde, Pluis of Spin object gezien wordt als een Vuil object, dat mag omdat zij allen een subklasse van Vuil zijn. Het begrip casting behoort niet tot de leerdoelen in deze lesmodule.

3 - Zelf starten van de methode

De laatse stap is heel eenvoudig, voeg gewoon de methode plaatsVuil() toe in de constructor (net als dal gedaan is met maakMuren).

Maak tenslotte de methode plaatsVuil() private, je kunt deze nu niet meer gebruiken door rechtsklikken in de Room, controleer dat! In dit geval niet zo heel belangrijk maar het voorkomet dat per ongeluk of zelfs express (hackers) code kan worden gebruikt of misbruikt.

Les 9 Interieur toevoegen

In deze laatste les van hoofdstuk 3 ga je de kamer verder voorzien van enkele obstakels (planten, meubels ...).

Waar tot nu toe de klassen aanwezig waren moeten deze nu eerst worden ontworpen en van een afbeelding voorzien.

Je leert in deze les zelfstandig klassen maken, deze voorzien van een constructor, attributen en methoden en vervolgens de klasse gebruiken in het Roomba scenario.

Leerdoelen subklassen maken

Je kunt zelfstandig nieuwe subklassen maken.
Je kunt je eigen klasse voorzien van een constructor, atributen en methoden.
Je kunt de nieuwe subklassen gebruiken in het scenario.

Een klasse ontwerpen

We beginnen met het ontwerpen en plaatsen van een plant, in tegenstelling tot vuil komt deze niet vanzelf in de kamer en willen we deze de gebruiken laten plaatsen of verplaatsen.

Later ga je dan zelf nog één of meer meubels toevoegen op een vergelijkbare manier.

Klasse ontwerpen:

Als je een klasse ontwerpt moet je over een aantal zaken nadenken:

- Welke taken (verantwoordelijkhden) moet de klasse krijgen.
- Zijn of komen er andere klassen die (bijna) hetzelfde moeten doen.
- Van daaruit een logische naam voor de klasse.
- Welke methoden moet de klasse krijgen.

Twee belangrijke verantwoordelijkheden zijn dus het tonen van een afbeelding en zorgen dat de Roomba tegen de plant botst (en deze niet opzuigt) zijn eenvoudig te realiseren door de klasse Plant op de juiste manier te maken.

Botsen:

Laten we eerst naar het botsen kijken.

In de klasse Roonba kijkt de Roomba via de methode wegVrij() of er obstakels zijn, je hoeft deze methode niet helemaal te begrijpen er komt wat goniometrie met radialen (uit de wiskunde) in voor. Het idee is dat de Roomba in een halve cirkel rond kijkt of er bbjecten te zien zijn.

Afbeelding koppelen

Als je kijkt naar het klassendiagram in Greenfoot dan zie je dat bij de meeste Actor Greenfoot al een voorbeeld van de gekoppelde afbeelding weergeeft.

Deze afbeelding kan worden gekoppeld via de methode setImage(bestandsnaam) die de klassen erven van ouderklasse / superklasse Actor maar kan ook direct bij het maken van de klasse worden gekoppeld. Wij zullen hier de laatste methode kiezen.

Belangrijk:

Voor je de afbeelding kunt koppelen dient deze op de juiste plaats en liefst in de juite maat aanwezig te zijn.

Download uit het menu bij 'bijlagen' het PlantenbakBovenaanzicht, het bestand Plant.png opent dan. Het formaat is 100 x 100 pixels, als je zelf afbeeldingen zoekt dan moet je ook het formaat zelf geschikt maken in bijvoorbeeld paint.

Sla je afbeelding op in je Greenfoot project <RoombaVersie2> in de submab <images>.

Nu ben je klaar om je eerste klasse te maken in de volgende paragraaf.

Planten maken en plaatsen

Nu je hebt gezien dat een meubel. plant (obstakel) een subklasse van kamer moet worden en je een afbeelding hebt gevonden en op de juiste plaats gezet kun je de klasse gaan maken.

Kies in het keuzemenu van klasse Kamer (rechts klikken) voor <New subclass...>. Er opent een scherm waarin je een naam kunt geven en de afbeelding kunt koppelen (gewoon aanklikken).

Kies als naam Plant en kopel de afbeelding Plant, je moet nu de klasse Plant in het klassendiagram zien als subklasse van Kamer (net onder Muur).

Testen

Test met enkele planten of de Roomba netjes botst en zuigt.

Stoel maken en plaatsen

Plaats op dezelfde manier een toel, het bestand staat ook bij de bijlagen en op het schoolnetwerk.

Test steeds zorgvuldig of alles naar behoren werkt.

Het is nu niet meer zo logisch dat het vuil is wordt geplaatst en de meubels daarna.

Maak zelf een methode in de klasse Room met de naam vulKamer().

Zorg dat deze minimaal één plant en één stoel plaatst en daarna het vuil.

Vergeet niet de methode plaatsVuil() uit de constructor van de Room te veranderen in vulKamer().

Bewaren en terugvinden

Zorg dat je je project goed hebt opgeslagen en snel terug kunt vindne je hebt dit nodig bij de test van week 3!

Hoofdstuk 3 terugblik

Inmiddels heb je weer 3 lessen (een weektaak) afgerond. Aan het begin van de volgende les maak je dus eerst weer de test over de leerdoelen van les 7 les 8 en les 9, bekijk deze nog eens!

In de test gaan we er vanuit dat je zelf het Greenfoot project RoombaVersie2 met je aanpasingen kunt openen en aanpassen, je moet dit ook inleveren bij na de aanpassingen in test 3.

In deze lessen heb je de programmeertaal Java en de omgeving Greenfoot gebruikt om een uitgebreidere simulatie te bouwen, de code zoals gemaakt zou grotendeels ook de code voor de software van de Roomba kunnen worden.

In hoofdstuk 4 gaan we de simulatie en de automaat gebruiken om wat test te doen met de werking van deze versie.

Hoofdstuk 4 Modelleren en testen

In dit laatste hoofdstuk komen we nogmaals terug op modelgebaseerd testen (model based testing). In les 3 van het introductiehoofdstuk is dit onderwerp al even aan de orde geweest.

In twee lessen kijk je naar het het begrip testen in relatie met software.

In les 10 gaat het over de noodzaak, de weerstand en een aantal begrippen.

In les 11 komen testen vanuit de opgegeven specificatie (verificatie) en testen vanuit de verwachting van de gebruiker (validatie) weer aan de orde.

De derde les is bestemd voor de afrondende test van hoofdstuk 4 en eventueel nog vragen stellen.

Les 10 Testen

Iedereen kent het wel dat je iets hebt gemaakt, ontdekt dat je iets fout hebt gedaan of bent vergeten en daarom helemaal opnieuw moet beginnen.

Mijn ouders kwamen dan altijd met het gezegde "bezint eer ge begint" aanzetten (waar ik niet blijer van werd overigens).

Toch raakt het de kern van de zaak.
Hoe verleidelijk het ook is om snel te beginnen en als je lekker in de flow zit vooral door te gaan. Het is van enorm belang eerst na te denken en ook tussentijds steeds te evalueren en testen en ook bij te stellen.

Een voorbeeld uit de praktijk van de roostermaker:

Nadat alle docenten hun vrije dagen hebben opgegeven is de invoer daarvan niet goed getest.

Pas nadat het rooster is gepubliceerd (acceptatietest) geeft de docent aan dat dit niet kan omdat deze dan op en andere school werkt ....

Het gevolg is dat bijna alles over moet, waardoor alles te laat is, ook anderen weer een ander rooster krijgen . . . . . . .

Leerdoelen les 10 Testen

Je kent en begrijpt de wet van Boehm.
Je begrijpt de noodzaak van testen en de weerstand tegen testen.
Je kent een aantal rollen bij software ontwikkeling en hun belangen.
Je kent een aantal vormen van testen en in welke situatie (fase) deze worden gebruikt.
Je weet wat modelgebaseerd testen is en hoe en wanneer dit in te zetten is.

Testen, waarom???

Als je even op internet zoekt op testen vind je vele verhalen en quotes met voorbeelden waar testen niet of niet goed genoeg is gedaan.

Cartoon tester

In grote lijnen komen de quotes omtrent testen op hezelfde neer:

- Testen wordt vaak geschrapt om tijd te besparen.

- Een fout / gebrek aantonen kan met één voorbeeld, juistheid aantonen is vrijwel onmogelijk.

- KIjk niet alleen naar wat logisch en te verwachten is maar juist naar het onverwachte (out o the box).

Wet van Boehm

Hoewel Barry Boehm niet zulke mooie oneliners heeft gebruikt wordt zijn wet (1979) wel als het begin van de bewustwording omtrent software testen gezien.

Nu 40 jaar later is er welliswaar veel veranderd en is men bewuster gaan testen maar komen nog ook nog steeds dezelfde fouten voor:

- Testen (deels) schrappen door gebrek aan tijd.

- Te laat in het proces testen.

- Alleen de logische situaties testen.

- De gebruikers vergeten in de test, we voldoen aan alle specificaties).

Wet van Boehm

Letterlijk zegt de wet van Boehm dat de herstelkosten van een fout exponentieel toenemen naarmate deze later in het ontwikkelproces worden ontdekt.

In de praktijk betekent het dat het bezuinigen op testen uiteindelijk geen besparing op zal leveren maar alleen maar meer kosten en meer vertraging (en vaak ook nog frustratie van over moeten doen).

Rollen bij softwareontwikkeling

Bij het ontwikkelen van een softwareproduct (een project) zijn veel mensen betrokken met verschillende belangen.

Vanuit hun 'rol' vervullen ze een 'taak' en omdat het mesnen zijn zullen ze daarbij ook fouten maken.

Het opsporen van dei fouten (testen) is een taak van de persoon zelf maar ook een gezamenlijke taak.

Onderstaande opsomming is overgenoemen uit het handboek projectmanagement versie 1.2 van Wouter Baars

bijlage 2, de tekst heb ik aangepast aan het doel van deze cursus:
https://www.projectmanagement-training.nl/boek/bijlagen/rollen-binnen-project/

projectteam of ontwikkelteam
De projectleden zijn de teamleden in het project. De mensen die het project daadwerkelijk uitvoeren en die taken hebben binnen het project. Vaak hebben teamleden verschillende expertisegebieden. Teamleden kunnen intern zijn (eigen personeel) en/of extern (van projectpartners, klanten, gebruikers of ingehuurd personeel).
Voor alle leden geldt dus ook een individuele verantwoordelijkheid hun taken te testen. Een speciale tester kan en zal ook vaak, lid van het team zijn.
projectleider, soms nog aangestuurd door een projectmanager (die meerdere projcten aanstuurt)
De projectleider is diegene die het projectteam aanstuurt en de eindverantwoordelijkheid heeft over het projectresultaat. Afhankelijk van hoe het wordt afgesproken, kan het natuurlijk zo zijn dat de projectleider verantwoordelijkheden delegeert aan teamleden en/of dat externe managers de verantwoordelijkheid hebben over een onderdeel van het project.
De projectleider zogt minimaal dat alle test worden gepland en uitgevoerd en dat er bijvoorbeeld testers binnen het team worden aangenomen.
Klant / opdrachtgever
De klant is de partij die het projectresultaat besteld heeft. Hij of zij kan actief in het project deelnemen of meer afstand houden. Stel dat de school een website voor de medewerkers en leerlingen laat maken, dan is de directie / het schoolbestuur de klant en de leerlingen en medewerkers zijn gebruikers.
De klant is degene die betaald en uiteindelijk ook degene die besluit of het resultaat goed genoeg is om het te accepteren (acceptatietest).
Gebruikers
De gebruikers zijn diegenen die het projectresultaat gaan gebruiken.
Het is belangrijk om deze personen te betrekken vanaf het begin bij het opstellen van de eisen en zo mogelijk ook tussentijds bij het testen.
Projectpartner
De projectpartner is een derde partij (organisatie) waarmee het project wordt uitgevoerd. Wanneer er meerdere partijen deelnemen aan het project is het uiteraard belangrijk om de verantwoordelijkheden en taken goed af te bakenen.
Bij een website voor de school kan bijvoorbeeld een externe partij de roosters voor de leelringen leveren.
Het testen van dat product maar vooral ook van de samenwerking met het zelf te ontwikkelen deel moet weer zorgvuldig worden getest.

Casus Roomba 2000

Als voorbeeld in deze les gebruiken we de te ontwikkelen software voor een nieuwe Roomba stofzuiger, zeg maar de Roomba 2K.

Deze Roomba 2K moet in elk geval 2 nieuwe functionaliteiten krijgen:

De vorm van de kamer en obstakels worden bewaard in een soort inwendige kaart waardoor de Roomba zelf een slimme route kan plannen met zo min mogelijk botsingen.
De Roomba 2K communiceert met de telefoon van de gebruiker, bijvoorbeeld een waarschuwing als de accu leeg is of er een storing is en op afstand aan en uit zetten.

Het bedrijf dat de Roomba verkoopt en ontwikkelt heet "iRoomba" en bestaat uit 3 totaal gescheiden bedrijfjes.

RoombaMarketing, zij verkopen de Roomba's en betalen aan de zusterbedrijven.

RoombaSoftware, hier werken de programmeurs, zij bouwen in opdracht de software.

RoombaTechniek, hier worden de diverse ondedelen gekocht of gemaakt en samengesteld tot Roomba.

Ontwikkeltaken, testen en fouten

Als voorbeeld van een aantal belangrijke ontwikkeltaken en het testen hiervan gebruiken we weer de casus over de ontwikkeling van de Roomba2K.

De eerste taak die moet gebeuren is het zo goed mogelijk in beeld krijgen van de eisen aan de software en deze opschrijven als specificatie of "pakket van eisen".

Meestal wordt hiervoor de Engelse term requirements gebruikt.

Requirements

Opstellen requirements

Het goed opstellen van requirements is van groot belang omdat anders het verkeerde zal worden gebouwd (en getest), zie ook validatie.

Belangrijk bij het opstellen van de requirements is in elk geval:

- Het betrekken van gebruikers hierbij en zorgvuldig en eenduidig formuleren.
- Zodanig opschrijven dat deze eisen testbaar / meetbaar zijn.
- Ook opschrijven wat vanzelfsprekend lijkt voor gebruikers.

Testen van requirements

In principe kun je pas testen of het prodcut aan de rquirements voldoet als het helemaal klaar is (zie ook het V-model uit les 3). Dat maakt ook direct het belang duidelijk omdat herstellen van een fout dan heel duur is.

Een fout in de requirements zal vaak pas worden ontdekt tijdens het gebruik en moet dan worden hersteld met een update of software - release. Je kunt immmers niet testen wat niet staat opgeschreven.

Volgens IT consultant James Martin komt meer dan 50% van de fouten vanuit 'slechte' requirements en zelfs meer dan 80% van de totale kosten om fouten op te lossen komt vanuit verkeerde of missende requirements.

Voorbeeld bij de Roomba2K:

Een eenvoudig voorbeeld bij de Roomba.

Stel dat in de specificaties is opgenomen dat de Roomba informatie kan uitwisselen met een smartphone.

Dit wordt keurig uitgevoerd en getest met diverse typen smartphones.

Bij gebruik blijkt dat het niet mogelijk is om twee telefoons te koppelen zodat gekozen moet worden welke huisgenoot de app kan gebruiken, wat naturlijk een ontevreden klant oplevert.

Overige stappen en testen

Programmeren (coding) gaat meestal in kleine (units) die dan later worden samengevoegd.

De eerste controle is de controle op syntax errors (taalfouten) deze controle / test wordt gedaan op het moment van compileren (compile - vertalen) van het code deel. In principe zou een syntax error dus niet in een stukje opgeleverde code mogen zitten.

Een tweede controle is een zogenaamde unit test er wordt getest of het geschreven stukje code aan de specificaties voldoet.
Bijvoorbeeld stukje codeblok dat plaats van een obsatkel moet opslaan kan worden getest voor rechthoekige voorwerpen en voor voorwerpen met een vreemde vorm ...

Als daarna meerdere units worden samengevoegd of een nieuw unit wordt ingepast moet worden getest of de blokken ook samen goed functioneren, dit noemen we een integratietest.
Bij de Roomba2K moet na het maken van de code die de route berekend ook wordne getest of dit goed samenwerkt met het al bestaande systeem van botsen en draaien.

Uiteindelijk zal het geheel moeten worden samengevoegd tot één systeem en dan weer getest, Niet verbazend spreken we dan over de systeemtest.

Tot slot wordt het gehele product opgeleverd aan de klant en volgt de test of het geheel aan de specificaties / requirement voldoet. Dit heet de acceptatietest. De klant / opdrachtgever zal na het slagen van deze test het geleverde accepteren en betalen.

* Merk op dat een verkeerde of vergeten requirement op dit moment nog steeds niet kan worden gevonden.

Test aanpak

Zeker weten dat er geen fouten in de software (of het systeem) zit kan alleen door elke situatie te testen, wat in de praktijk meestal niet mogelik is of teveel tijd kost (testing can show the presence of bugs never their absence was één van de uitspraken).

Daarom is het van belang een slimme anpak te kiezen:

Maak een (test)plan en documenteer dit.
Test de 'moeilijkste' situaties.
Test onverwachte / onlogische situaties (out of the box).

Bij de Roomba bijvoorbeeld:

Test op vuil dat in de hoeken en tegen meubels aanligt.
Test het zwaarsre vuil dat moet worden opgezogen bij en bijna volle Roomba.
Test wat er gebeurd als iemand meubels verschuift naar onverwachte plaatsen...

Modelgebaseerd en automatisch testen

Tot slot van deze les nog een toevoeging omtrent de mogelijke oplossing van twee van de genoemde problemen:

Automatisch (computergestuurd) testen:

Zoals gezegd lijkt het testen van alle mogelijkheden in de meeste gevallen niet paktisch haalbaar.

Als we echter de snelheid van de computer kunnne gebruiken dan is dit bij redelijk eenvoudige systemen soms wel mogelijk.

We spreken dan van geautomatiseerd testen. Bij systemen die met een automaat kunnen worden gemodelleerd is dit een aanpak die steeds vaker wordt toegepast.

Het gaat dan vaak om systemen met een ingebouwde (embedded) computer zoals ook de Roomba.

Modelgestuurd testen:

Om geautomatiseerd te kunnen testen is het nodig dat de computer een model bevat van van het systeem dat voldoende precies is om de test uit te voeren. Om nog maar eens een quote te gebruiken in dat verband "All models are wrong, but some are useful" George E. P. Box

Les 11 Verificatie en validatie

In deze laatse les van de module bekijken we nog een aantal voorbeelden van modelgebaseerd testen met onze context de Roomba.

We zullen weer onderscheidt maken tussen validatie en verificatie.

Leerdoelen les 11 Validatie

Je kunt de begrippen verificatie en validatie uitleggen.
Je kunt verificatie en validatie processen met behulp van een model uitvoeren en de beperkingen daarvan inzien.
Je snapt dat goede validatie afhankelijk is van goede verificatie.
Je kunt het begrip specificatie uitleggen in relatie tot verificatie en validatie.
Je kent het onderscheidt tussen 'mag niet voorkomen' en 'moet kunnen voorkomen'.
Je kent de begrippen bereikbaarheid en deadlock.

Verificatie voor validatie

In systeem- (en software-)ontwikkeling houdt validatie in dat gecontroleerd wordt of het gebouwde systeem voldoet aan de eisen / wensen van de gebruiker ( de door de gebruiker gewenste functionaliteit ook wel User Requirement Specifications genoemd), terwijl bij de verificatie wordt gecontroleerd of het gebouwde systeem voldoet aan de opgestelde specificaties / requirements ('Software Quality Control').

Validatie en verificatie

We kijken weer naar de Roomba als context / casus.

De gebruiker verwacht natuurlijk dat de Roomba in alle omstandigheden goed functioneert.

In de praktijk zal pas blijken of dit ook echt zo is.

Verificatie altijd voor validatie

De antwoorden op de vragen hierboven laten zien dat het altijd nodig is eerst de verificatie uit te voeren, daarna de validatie.

Als je weet dat aan de opgestelde specificaties is voldaan (verificatie) dan kun je bij een fout in de vallidatie de conclusie trekken dat de fout gemaakt is bij het opstellen van de specificaties (validatie).

Verificatie met automaat

Les 10 sloten we af met de term modelgebaseerd testen waarbij het grote voordeel is dat je niet eerst de software in het product hoeft in te bouwen en zodende fouten pas aan het eind van het traject ontdekt.

Nu je ook weet dat de verificatie altijd eerst dient te gebeuren kun je hier nog enkele voorbeelden van uitvoeren in onderstaande opdrachten.

Begin met het openen van de automaat.

automaat uit hoofdstuk 2 (les5)

Verificatie Greenfoot

Ook de simulatie kunnen we gebruiken om te testen voordat de Roomba werkelij is gemaakt en vaak op hogere snelheid.

In de specificatie (vanuit de requirements) staat bijvoorbeeld dat vuil dat niet onder een obstakel ligt in de gehele kamer moet kunnen worden opgezogen. Wat is nu een "slimme"manier om dit te testen?

"Trial en error"

Je kunt gewoon een aantal keer vuil plaatsen en de Roomba bijvoorbeeld 15 minuten laten lopen, in Greenfoot kan de snelhieid nog wat omhoog met de schuifregelaar maar het blijft een tijdrovend proces.

Vul de kamer met vuil en laat de Roomba op de hoogste snelheid (schuifregelaar) de kamer zuigen, word de kamer schoon?

Het lastige met testen blijft dat je wel aan kunt tonen dat iets werkt maar erg lastig dat iets niet werkt!

Worst case handmatig testen

Worst case

Iets slimmer dan gewoon uitproberen kan het zijn om bepaalde situaties eerst goed uit te zoeken.

Je zag al (en kon ook wel bedenken) dat vuil in een hoek een lastige situatie is, we noemen een dergelijke lastige situatie ook wel "worst case scenario".

Je kunt handmatig vuil (spin / pluisje ...) precies in een hoek plaatsen en dan kijken wat er gebeurd.

Voer dit even uit in Greenfoot, wacht niet te lang als het niet schoon wordt..

Rekening houden met wijzigingen

Een laatse onderwerp dat je als "komend" ontwerper / programmeur goe dvoor ogen moet hebben is dat veel problemen te voorkomen zijn door niet va één specifieke situatie uit te gaan maar van een meer algemene.

De code waarmee we meubels, vuil en muren plaatsen is niet zo goed geschreven, bijvoorbeeld voor de muren staat het onderstaande fragment in de broncode:

private void maakMuren()
{
// plaatst boven en ondermuur
for (int i=16; i < 1280; i= i+32) {
addObject (new Muur(), i, 16); // bovenmuur
addObject (new Muur(), i, 752); //ondermuur
}

....

Validatie

Na een goede verificatie kunnen we stellen dat het systeem juist is gemaakt, het voldoet aan alle opgestelde specificaties.

De vraag hierna is of ook juite systeem is gemaakt, oftewel doet het systeem wat het zou moeten doen en wat de gebruiker er van verwacht. Het testen hiervan noemen we de validatie (om het woord nog maar eens te gebruiken).

Ook bij validatie geld de regel dat een tekortkoming die pas wordt ontdekt als het systeem klaar is, veel geld en tijd kost om nog te verhelpen. Een tekortkoming die door een gebrekkige validatie niet wordt opgemerkt zal naast tijd en geld ook nog voor slechte reviews zorgen en is daardoor nog erger.

Ook hier is het dus zinvol om al vroeg in het ontwikkelproces te kijken naar validatie. De gebruiker laten testen met behulp van een model is een mogelijkheid hiervoor.

Model gebaseerde validatie

Tot slot nog een voorbeeld van een validatie test bij de Roomba context.

Open in Greenfoot weer de RoombaVersie2 simulatie die je hebt aangepast in hoofdstuk 3.

Simulatie met Greenfoot uit hoofdstuk 3

Als je er vanuit gaat dat het toestandsdiagram in de specificatie stond had deze fout al bij de verificatie moeten zijn ontdekt. Dit benadrukt nogmaals het belang van een goede verificatie voor de validatie!

In het model is de fout vrij eenvoudig te verhelpen door in de methode ruimOp() de volgende regels toe te voegen:
toestand = "V";
schrijfToestand();
Greenfoot.delay(300); // zonder vertraging duurt de teostnd zo kort dat we deze niet opmerken

Validatie model

Sommige situaties komen niet vaak voor of duren erg lang, daarom worden deze bij het testen vaak niet opgemerkt.

Een voorbeeld bij de Roomba is de situatie als de batterij leeg is, dit duurt erg lang met de huidige instellingen.

Op welke manier kun je dit sneller testen?
- Je kunt of het stroomverbruk vrij hoog zetten zodat de accu snel leeg is.
- Een tweede optie is om de voorwaarde an te passen zodat de Roomba bij 98 of 99 procent al nar huis gaat.

Kies voor de eerste optie en zet het stroomverbruik in de broncode van de Roomba op 0.4.

Hoofdstuk 4 terugblik

Kijk ook bij hoofdstuk 4 nog eens terug naar de leerdoelen van les 10 en les 11.

Les 10 ging over de noodzaak en het belang van testen in het algemeen en het soort testen dat wordt uitgevoerd.
Het is belangrijk de weerstand tegen testen goed te begrijpen en in te zien dat uiteindelijk meestal tijd, geld en kwaliteit wordt gewonnen door wel goed en zorgvuldig te testen.

In les 11 heb je met behulp van de automaat en de simulatie nog enkele model gebaseerde tests uitgevoerd als afsluiting.

Na de test over hoofdstuk 4 (les 10 en les 11) volgt nog:

de eindtoets, de vragen uit de tests en de leedoelen zijn daar en goede voorbereiding voor.
een eindopdracht met automaten.

Afronding

Eindopdracht

De eindopdracht (zie studiewijzer op It's Learnig gaat voornamelijk over automaten / toestandsdiagrammen, kijk daarvoor nog eens goed naar hoofdstuk 2.

Het testen met behulp van de automaat/ toestandsdiagram (in delen van hoofdstuk 1 en hoofdstuk 4) zal ook een onderdeel vormen van de eindopdracht.

Toets

De toetsa in de SE week gaat over hoofdstuk 1 t/m hoofdsuk 4.

- Kijk nog eens goed naar de leerdoelen en de vragen in de 4 weektesten.

zxc\

Het arrangement Reggesteyn_Automaten is gemaakt met Wikiwijs van Kennisnet. Wikiwijs is hét onderwijsplatform waar je leermiddelen zoekt, maakt en deelt.

Auteur: Tom van der Wal Je moet eerst inloggen om feedback aan de auteur te kunnen geven.
Laatst gewijzigd
Licentie: Dit lesmateriaal is gepubliceerd onder de Creative Commons Naamsvermelding 4.0 Internationale licentie. Dit houdt in dat je onder de voorwaarde van naamsvermelding vrij bent om:

het werk te delen - te kopiëren, te verspreiden en door te geven via elk medium of bestandsformaat

het werk te bewerken - te remixen, te veranderen en afgeleide werken te maken

voor alle doeleinden, inclusief commerciële doeleinden.

Meer informatie over de CC Naamsvermelding 4.0 Internationale licentie.

Aanvullende informatie over dit lesmateriaal

Van dit lesmateriaal is de volgende aanvullende informatie beschikbaar:

Toelichting: In ontwikkeling, 1e versie zal rond me 2019 klaar zijn Lessenserie rond het onderwerp automaten uit kernprogramma 'grondslagen'. Door een programma of systeem te modelleren als een automaat met een (eindig) aantal toestanden kun je dit systeem bestuderen en testen.
Leerniveau: VWO 4; VWO 5;
Leerinhoud en doelen: Informatica;
Eindgebruiker: leerling/student
Moeilijkheidsgraad: gemiddeld
Studiebelasting: 20 uur en 0 minuten
Trefwoorden: automaten, grondslagen

Bronnen

Bron	Type
Learn about finite state machines (FSM) using a room-cleaning robot as an example. https://youtu.be/4XEK7OU2gIw	Video
Roomba 600 video https://youtu.be/Yf8MuJUGLlI	Video
Introductie video (kijk van 0:40 https://youtu.be/4XEK7OU2gIw	Video
Introductie video (kijk vanaf 3:00 tot 5:00) https://youtu.be/4XEK7OU2gIw	Video

Gebruikte Wikiwijs Arrangementen

Trauschke, Chris. (2019).

Automaten

https://maken.wikiwijs.nl/125778/Automaten

Download
Downloaden

Het volledige arrangement is in de onderstaande formaten te downloaden.

pdf

json

IMSCP package

Metadata

Metadata overzicht (Excel)

LTI

Leeromgevingen die gebruik maken van LTI kunnen Wikiwijs arrangementen en toetsen afspelen en resultaten terugkoppelen. Hiervoor moet de leeromgeving wel bij Wikiwijs aangemeld zijn. Wil je gebruik maken van de LTI koppeling? Meld je aan via info@wikiwijs.nl met het verzoek om een LTI koppeling aan te gaan.

Maak je al gebruik van LTI? Gebruik dan de onderstaande Launch URL’s.

Arrangement

IMSCC package

Wil je de Launch URL’s niet los kopiëren, maar in één keer downloaden? Download dan de IMSCC package.

IMSCC package

Meer informatie voor ontwikkelaars

Wikiwijs lesmateriaal kan worden gebruikt in een externe leeromgeving. Er kunnen koppelingen worden gemaakt en het lesmateriaal kan op verschillende manieren worden geëxporteerd. Meer informatie hierover kun je vinden op onze Developers Wiki.
sluiten
Opties
Gebruik
Weergave
Wikiwijs is een dienst van