Najaar
2009 VRIJE UNIVERSITEIT AMSTERDAM
Faculteit der Exacte Wetenschappen - Informatica
Probleemoplossen Aniel Bhulai
FACULTEIT DER EXACTE WETENSCHAPPEN AFDELING INFORMATICA
Probleemoplossen Aniel Bhulai Met dank aan Eline van Mantgem en Frank Evers
2008-2009
Inhoudsopgave 1.
Studiehandleiding............................................................. 1 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7. 1.8. 1.9. 1.10. 1.11. 1.12.
2.
UML ................................................................................. 4 2.1. 2.2. 2.3. 2.4. 2.5.
3.
Inleiding.................................................................................. 1 Doelstelling ............................................................................ 1 Profiel van de studenten ........................................................ 1 Plaats in de opleiding............................................................. 2 Tijdsbesteding ........................................................................ 2 Boek ....................................................................................... 2 Syllabus ................................................................................. 2 Blackboard ............................................................................. 2 Docent en student-assistenten .............................................. 3 Colleges ................................................................................ 3 Practica.................................................................................. 3 Beoordeling ........................................................................... 3 Inleiding.................................................................................. 4 Wat is UML? .......................................................................... 4 UML diagrammen .................................................................. 5 Waarom UML? ....................................................................... 5 Use-case-diagram ................................................................. 6
Practicum ......................................................................... 8 3.1. Inleiding.................................................................................. 8 3.2. Het storyboard ....................................................................... 9 3.2.1. Een storyboard maken ......................................................... 9 3.2.2. Het weergeven van loops in een storyboard ....................... 9 3.2.3. Het weergeven van methodes in een storyboard .............. 10 3.2.4. Het weergeven van parameters in een storyboard ............ 11 3.2.5. Het weergeven van events in een storyboard ................... 11 3.2.6. Het inleveren van de bestanden ........................................ 12 3.3. Van UML naar storyboard.................................................... 12
S T U D I E H A N D L E I D I N G
1
Hoofdstuk
1. Studiehandleiding 1.1. Inleiding Het vak ‘Probleemoplossen’ wordt sinds september 2007 gegeven. In deze studiehandleiding geven we de uitgangspunten van het vak. Tevens geven we aan wat er van de studenten verwacht wordt en hoe zij dit kunnen bereiken.
1.2. Doelstelling In deze cursus leer je de fundamentele programmeerconcepten om problemen op te lossen m.b.v. het programma ‘Alice’. Tijdens het college en practicum maak je kennis met o.a. het vertalen van scenario’s naar storyboards met behulp van UML om problemen op te lossen. Je leert problemen op te lossen door logisch te redeneren en door gebruik te maken van kennis uit andere vakgebieden. Het probleemoplossend denken wordt bij dit vak gestimuleerd, evenals je creatieve en innovatieve vaardigheden. Na het volgen van dit vak: heb je kennis om scenario’s te vertalen naar een storyboard met behulp van UML om problemen op te lossen of een planning te maken om taken uit te voeren die gespecificeerd staan in de scenario’s, heb je kennis om problemen in kleine stappen op delen en op te lossen, heb je kennis om door logisch te redeneren problemen aan te pakken, en heb je kennis om problemen op te lossen door integratie van kennis uit andere vakgebieden.
1.3. Profiel van de studenten Er wordt geen specifieke voorkennis geëist om aan ‘Probleemoplossen’ deel te nemen. Zowel studenten die nog nooit een game, animatie of applicatie hebben gemaakt, als studenten die thuis zijn in programmeren, moeten in staat zijn om de colleges en de practica met succes te doorlopen.
Probleemoplossen
1
S T U D I E H A N D L E I D I N G
1.4. Plaats in de opleiding ‘Probleemoplossen’ is één van de eerste vakken waarmee je in het eerste jaar van je studie in aanraking komt. De kennis en vaardigheden die in je dit vak opdoet, zal je direct kunnen gebruiken bij andere (vervolg)vakken, zoals bij inleiding programmeren of project programmeren.
1.5. Tijdsbesteding Voor ‘Probleemoplossen’ staat een studiebelasting van 84 uur oftewel 3 ECTS punten. Voor de hoorcolleges zijn 14 uren (7 x 2 uren per week) gereserveerd en voor de practica 28 uren (7 x 4 uren per week). Voor zelfstudie, voorbereiding, eindopdracht en uitloop van het practicum blijven 42 uren over.
1.6. Boek Het boek dat bij de colleges en practica gebruikt wordt, is “Learning to Program with Alice” van de auteurs Wanda P. Dann, Stephen Cooper en Randy Pausch (ISBN: 0-13-187289-3). Zorg er voor dat je dit boek elk college en practicum bij je hebt anders heeft het weinig zin om bij het college en practicum te komen.
1.7. Syllabus Naast het boek heb je ook deze syllabus nodig. Hierin staan deze studiehandleiding en praktische informatie opgenomen. Deze syllabus is te downloaden vanaf de website van het vak in Blackboard (http://bb.vu.nl).
1.8. Blackboard Ter ondersteuning van de informatie in de syllabus is in Blackboard een website ontwikkeld voor dit vak. Blackboard is te vinden op http://bb.vu.nl. De website van dit vak bevat verschillende onderdelen, t.w.:
(rooster)wijzingen, fouten, aankondigingen, nieuwsberichten voor dit vak, e.d., worden op de announcement pagina vermeld. Wij raden je aan om ten minste 1x per week deze pagina te raadplegen voor het laatste nieuws.
Course Information:
Staff Information:
contactgegevens van de docent en practicumassistenten zijn opgenomen op de staff information pagina. Vanaf deze pagina kun je ze direct mailen.
Course Documents: onder course documents vind je o.a. deze syllabus in
Announcements:
onder course information vind je een korte beschrijving van het vak en een rooster voor de colleges en practica.
pdf formaat en de college
sheets.
Assignments:
om te toetsen of je de bestudeerde stof begrepen hebt, staan er onder assignments een aantal vragen per onderwerp of hoofdstuk. Per onderwerp of hoofdstuk worden er 10 vragen gesteld, waarvoor je 10 min. tijd hebt om ze te maken. Je krijgt een cijfer wanneer je alle vragen van een onderwerp of hoofdstuk hebt gemaakt. Hiermee kun je een halve punt extra verdienen op je eindcijfer wanneer het gemiddelde van alle toetsvragen een 8 of hoger is.
Probleemoplossen
2
S T U D I E H A N D L E I D I N G
Wij raden je aan om de studentenhandleiding onder de support tab van Blackboard door te nemen voor meer informatie over hoe je met Blackboard moet werken. De handleiding is zowel in het Nederlands als in het Engels beschikbaar.
1.9. Docent en student-assistenten De colleges worden verzorgd door de heer Aniel Bhulai, docent bij de afdeling Informatica en tevens de eindverantwoordelijke van het vak “Probleemoplossen”. Aniel Bhulai is te bereiken onder telefoonnummer 020 – 59 87803 of per email
[email protected]. De practica worden begeleid door student-assistenten. Hun contactgegevens vind je in Blackboard onder staff information.
1.10. Colleges De colleges zijn gekoppeld aan het practicum. Tijdens de colleges zullen de belangrijke punten uit een hoofdstuk toegelicht worden. Daarnaast zal aan de hand van o.a. voorbeelden verbanden gelegd worden met andere vakken en het bedrijfsleven. Wij verwachten van jou dat je alle colleges bijwoont. Je haalt het meeste rendement uit een college door de bijbehorende hoofdstukken van te voren door te lezen. Wij raden je daarom aan om dit ook te doen. Tijdens het college kun je dan aantekeningen maken die de inhoud aanvullen. Je mag tijdens de colleges vragen stellen aan de docent over de studiestof. Na afloop van het college kun je het hoofdstuk en je aantekeningen nog eens bestuderen ter voorbereiding op het practicum.
1.11. Practica Zie hiervoor hoofdstuk 3 over het practicum.
1.12. Beoordeling Bij elk practicum is een opdracht opgenomen die beoordeeld zal worden. Deze opdrachten kun je herkennen aan ‘*’ achter de opdrachttitel. Bij de eerste twee practica zullen die opdrachten beoordeeld worden met een onvoldoende of voldoende. Vanaf practicum 3 zal je voor de opdrachten een cijfer krijgen. De eerste twee practica moeten voldoende zijn om verder te kunnen. Van de laatste vier practica mag je maar één onvoldoende hebben. Deze mag niet lager zijn dan een 4, anders mag je niet deelnemen aan de eindopdracht. Er zal een punt van je cijfer afgetrokken worden wanneer je de opdracht niet op tijd inlevert. Bij het helemaal niet inleveren van de opdracht, zal er een 1 genoteerd worden voor de desbetreffende opdracht. Het gemiddelde cijfer van deze opdrachten telt voor 60% mee voor je eindcijfer. Naast de practicumopdrachten zal je aan het eind van de practicumreeks een grote opdracht krijgen waarover je een presentatie zal moeten geven. Deze opdracht zal je samen met 3 à 4 studenten in een groep maken. Voor deze eindopdracht en de presentatie zal je een cijfer krijgen die voor 40% zal meetellen bij je eindbeoordeling. Je eindcijfer is dus als volgt opgebouwd: 0,6 Probleemoplossen
0,4
. 0,5 3
U N I F I E D
M O D E L I N G
L A N G U A G E
2
Hoofdstuk
2. UML 2.1. Inleiding Het hart van object-georiënteerde probleemoplossing is het maken van een model (het modelleren). Het model geeft een overzicht van de belangrijke details van het onderliggende probleem. Bij dit vak gaan we UML gebruiken om het probleem/de situatie in kaart te brengen om vervolgens een oplossing voor het probleem te bedenken.
2.2. Wat is UML? UML staat voor Unified Modeling Language. UML is geen methode maar een standaard visuele modelleertaal, die uit een geïntegreerde set diagrammen bestaat1. Het is ontwikkeld om systeem- en softwareontwikkelaars te helpen bij het vervullen van de volgende taken2: Specificatie, Visualisatie, Architectuur design, Constructie, Simulatie en testen, Documentatie. Oorspronkelijk was UML bedoeld om de communicatie en de productiviteit tussen de ontwikkelaars van object-georiënteerde systemen te bevorderen. Echter, de kracht van UML is de oorzaak dat het tegenwoordig bij elk type systeem- en softwareontwikkeling gebruikt wordt.
1
Praktisch UML, 3e editie, J. Warmer & A. Kleppe
2
UML 2 for Dummies, M.J. Chonoles en J.A. Schardt
Probleemoplossen
4
U N I F I E D
M O D E L I N G
L A N G U A G E
2.3. UML diagrammen UML biedt een aantal diagrammen die gezamenlijk een beschrijving geven van het softwaresysteem. Het is belangrijk je te realiseren dat de hieronder genoemde verschillende diagrammen een beschrijving geven vanuit verschillende perspectieven. Het use-case-diagram beschrijft wat een system doet vanuit een oogpunt van een ‘buitenstander’, iemand die buiten het systeem staat. De nadruk bij use-case-diagrams ligt op wat een systeem doet, niet op hoe een systeem het doet. Het class diagram toont de statische structuur van het softwaresysteem weergegeven als klassen en hun relaties. Het object diagram toont de statische structuur van het softwaresysteem weergegeven als objecten en hun relaties. Ze zijn nuttig om kleine stukken met gecompliceerde relaties (m.n. recursieve relaties) uit te leggen. Het sequence diagram toont de volgorde in tijd van de boodschappen die in het systeem verstuurd en ontvangen worden. Het collaboration diagram toont hoe de objecten samenwerken om een doel te bereiken. Het statechart diagram toont de toestanden waarin een object zich kan bevinden gedurende zijn levensloop. Het activity diagram toont de activiteiten die door een deel van het systeem worden uitgevoerd, inclusief eventueel parallellisme. Activity diagrammen kunnen ook gebruikt worden voor het beschrijven van bedrijfsprocessen en de workflow. Het component diagram toont de verdeling van het gehele systeem in componenten en de relaties tussen die componenten. Het deployment diagram toont hoe de softwarecomponenten in een bepaalde systeemconfiguratie worden gebruikt. Bij dit vak zullen wij alleen het use-case-diagram gebruiken.
2.4. Waarom UML? Waarom is UML zo belangrijk? Deze vraag is beter te beantwoorden wanneer we de vraag bekijken vanuit het oogpunt van een bouwbedrijf. Voordat een gebouw gebouwd kan worden, moet er eerst een bouwtekening komen. De architect maakt hiervoor een ontwerp (zgn. blauwdruk of blueprint) van het gebouw. Het gebouw wordt op basis van dit ontwerp gebouwd door de bouwers. Hoe complexer een gebouw, hoe kritischer de communicatie is tussen de architect en het bouwbedrijf. De blauwdrukken zijn de standaard grafische taal voor zowel de architect en de bouwers, die zij in hun beroep moeten beheersen. Probleemoplossen
5
U N I F I E D
M O D E L I N G
L A N G U A G E
Het schrijven van software (lees: programmeren) is niet veel anders dan het bouwen van een gebouw. Hoe gecompliceerder het onderliggende systeem, hoe kritischer de communicatie wordt tussen al de mensen die betrokken zijn bij het ontwikkelen en het inzetten van de software. In het afgelopen decennium is UML veelvuldig gebruikt als de software blauwdruktaal voor o.a. softwareanalisten, softwareontwikkelaars en programmeurs dat het nu een deel vormt van het traject van softwareontwikkeling. UML is toepasbaar bij object-georiënteerde probleemoplossingen. Om UML te kunnen gebruiken moet je bekend zijn met de onderliggende basisprincipes van object-georiënteerde probleemoplossingen. Het begint met het construeren van een model. Een model is een abstractie van het onderliggende probleem. Het domein is de werkelijke wereld van waar het probleem komt. Modellen bestaan uit objecten die met elkaar interacteren d.m.v. berichten (messages). Beschouw een object als iets “levends”. Objecten hebben dingen die ze kennen (attributes) en dingen die ze kunnen doen (behaviors of operations). De waarde van een object’s attribute bepaald zijn toestand (state). Classes zijn de blauwdrukken voor objecten. Classes bestaan uit attributes (data) en behaviors (methods of functions) in een afzonderlijk entiteit. Objecten zijn instances van classes.
2.5. Use-case-diagram Zoals eerder aangegeven beschrijft een use-case-diagram wat een systeem doet vanuit een oogpunt van een ‘buitenstander’. Hierbij ligt de nadruk op wat een systeem doet, niet op hoe een systeem het doet. Use-casediagrams zijn nauw gerelateerd aan scenario’s. Een scenario is een voorbeeld van wat er gebeurt wanneer iemand interacteert met het systeem. Het volgende voorbeeld is een scenario van een medische kliniek: “Een patiënt belt de medische kliniek op voor een jaarlijkse controle. De receptioniste zoekt het eerst volgende vrije tijdstip op in de agenda en maakt een afspraak voor dat tijdstip.” Een use case is een samenvatting van scenario’s voor een taak of doel. Een actor is iemand (bv. een user) of iets (bv. een extern systeem), die de gebeurtenissen voor die taak initieert. Het use-case-diagram voor het maken van een afspraak bij de medische kliniek scenario ziet er als volgt uit: Medische kliniek Communicatie
Communicatie Afspraak maken Receptioniste
Patient
Figuur 1: Use-case-diagram voor het maken van een afspraak.
Probleemoplossen
6
U N I F I E D
M O D E L I N G
L A N G U A G E
De user is in het bovenstaande scenario de patiënt en wordt aangegeven met
.
Use cases worden aangeduid met een ovaal teken met daarin de actie of handeling van de user. In het bovenstaande scenario is dat
. Het scenario, in het onderhavige geval afspraak
maken bij de medische kliniek,wordt aangegeven met een rechthoek met daarin de naam van het scenario. De verbinding tussen de user en de use case is een 1 op 1 communicatie associatie of kortweg communicatie. Communicaties worden met lijnen weergegeven, die de users verbinden met de use cases. Use-case diagrammen zijn handig bij
het bepalen van requirements. Nieuwe use cases genereren nieuwe requirements wanneer het systeem geanalyseerd wordt en wanneer het ontwerp vormen begint aan te nemen.
de communicatie met klanten. De simpele notatie maakt het mogelijk om use case diagrammen te gebruiken bij de communicatie tussen ontwikkelaars en klanten.
het genereren van test cases. Een verzameling scenario’s voor een use case kan een verzameling test cases suggereren voor die scenario’s.
Probleemoplossen
7
P R A C T I C U M
3
Hoofdstuk
3. Practicum 3.1. Inleiding Het bijwonen van de practica is verplicht. Je aanwezigheid tijdens de practica wordt geregistreerd. Indien je door omstandigheden een practicum niet kunt bijwonen dien je dit te melden aan de vakdocent of je student-assistent. Wij raden je aan om de frauderegeling in Blackboard onder external links te lezen, zodat je op de hoogte bent van wat je wel en niet mag, en wat er gebeurt in geval van fraude constatering. Tijdens het practicum ga je werken aan de opgaven, die kort voor het practicum op Blackboard geplaatst zullen worden. Van tevoren zullen de opgaven, die uit het boek gemaakt moeten worden, aan het eind van elke college worden aangegeven. De opgaven gaan over de onderwerpen die in het voorafgaande colleges zijn besproken. Er wordt van jou verwacht dat je het practicum voorbereidt door de onderwerpen, die in de voorgaande colleges besproken zijn, thuis te bestuderen. Al de gevraagde opgaven dien je te maken. Voor elk van de opgaven geldt: 1. Maak een UML Use Case Diagram. 2. Maak een storyboard. 3. Laat het UML Use Case Diagram en het storyboard goedkeuren door je student-assistent. 4. Maak de opgave. 5. Laat je opgave aan de student-assistent zien wanneer je de opgave af hebt. Deze bekijkt of de opgave goed is gemaakt, zodat je verder kunt gaan met de volgende opgave. Alle opgaven dien je wekelijks, echter voor vrijdag 23.59u, in Blackboard in te leveren. Alle bestanden van de in te leveren opgave dienen tot één bestand gezipped te zijn. Houd daarbij de volgende naamgeving aan voor je zip-bestand: voorletters_achternaam_pracX.zip. Voorbeeld: L_Janssen_prac4.zip
Probleemoplossen
8
P R A C T I C U M
3.2. Het storyboard 3.2.1.Een storyboard maken Voor het maken van een storyboard geven wij twee werkwijzen die hieronder beschreven zijn. We geven hier twee werkwijzen, omdat het ook een beetje van je persoonlijke voorkeur afhangt welke je gaat gebruiken. Je mag zelf bepalen met welke van de twee je prettig vindt om te werken. Anders dan in het boek maken deze werkwijzen gebruik van accolades. Deze werkwijzen gelden voor meeste de programmeertalen. Ze maken een storyboard tevens overzichtelijker, beter interpreteer- en leesbaar. Hieronder maken we d.m.v. een voorbeeld de twee werkwijzen duidelijk. Werkwijze 1: do together { do in order { alien moves up alien says “Hello” } } Werkwijze 2 do together { do in order { alien moves up alien says “Hello” } } Zoals je kunt zien verschillen alleen de begin accolades '{' van plaats. Let bij het maken van een storyboard op het inspringen van nieuwe ‘blokken’ (ook wel indentation genoemd). Elk nieuwe stuk code die tussen de '{' en '}' staat moet worden ingesprongen.
3.2.2.Het weergeven van loops in een storyboard Stel dat een object 3 keer vooruit moet bewegen. Je kunt deze loop in het storyboard dan als volgt weergegeven: Loop (3 times) { object moves forward } Iets dergelijks geldt ook voor een while-statement. Stel dat we een statement net zo lang willen herhalen totdat object1 op 1 meter afstand van object2 is. Het storyboard van dit voorbeeld ziet er dan als volgt uit:
Probleemoplossen
9
P R A C T I C U M
While (afstand object1 tot object2 kleiner dan 1 meter) { statement } Je mag het bovenstaande ook als volgt noteren: While (afstand object1 tot object2 < 1 meter) { statement }
3.2.3.Het weergeven van methodes in een storyboard In hoofdstuk 4 zul je met methodes gaan werken. Deze methodes dien je apart in je storyboard op te nemen. Vanaf hoofdstuk 4 dien je in je storyboard aan te geven welke code bij het hoofdprogramma hoort en welke bij de diverse gebruikte methodes in je programma. Hieronder volgt een voorbeeld. Stel we hebben een programma waarin een object ‘persoon’ voorkomt. Daarnaast hebben we een wereld waarin het regent. De persoon in de wereld doet een dans terwijl het regent. Er is dan een world-level methode ‘regen’ en een class level methode ‘dans’ in de class persoon. Het storyboard, dat in delen bestaat, ziet er dan als volgt uit: Het hoofdprogramma gedeelte world.myfirstmethod { do together { regen persoon danst } } De methode ‘regen’ regen { loop (oneindig) { druppels vallen naar beneden } } De methode ‘dans’ in de class persoon dans { persoon beweegt benen persoon beweegt armen … }
Probleemoplossen
10
P R A C T I C U M
Wanneer de wereld start (lees: applicatie) wordt, de methode world.myfirstmethod (of kortweg: myfirstmethod) als eerst aangeroepen (dit is te zien in het events windows (het venster rechtsboven) van het Alice programma).
3.2.4.Het weergeven van parameters in een storyboard Vanaf hoofdstuk 4 ga je met parameters werken. Een voorbeeld is de solo methode uit het boek op bladzijde 87. De solo methode verwacht 2 parameters, namelijk een bandMember en een instrument. Het aanroepen van de methode solo vanuit world.myfirstmethod gaat dan op de onderstaande manier. Het hoofdprogramma gedeelte world.myfirstmethod { solo (george, bass) solo (lennon, guitar) solo (paul, saxophone) solo (ringo, drum) } De methode ‘solo’ solo (bandMember, instrument) { do together { bandMember springt instrument maakt geluid } }
3.2.5.Het weergeven van events in een storyboard In hoofdstuk 5 ga je met events werken. Laten we in het voorbeeld van §3.2.3 twee events toevoegen. In dat voorbeeld willen we dat het pas gaat regenen als de gebruiker op de ‘r’ toets drukt. Daarnaast willen we dat de methode ‘danst’ van de class persoon aangeroepen wordt als de gebruiker op de spatiebalk drukt. Het storyboard voor de aangepaste versie ziet er dan als volgt uit. Events: als de wereld start: als ‘r’ ingedrukt wordt: als ‘spatiebalk’ ingedrukt wordt:
world.myfirstmethod regen persoon.danst
Het hoofdprogramma gedeelte world.myfirstmethod { do together { regen persoon danst
Probleemoplossen
11
P R A C T I C U M
} } De methode ‘regen’ regen { loop (oneindig) { druppels vallen naar beneden } } De methode ‘danst’ in de class persoon danst { persoon beweegt benen persoon beweegt armen … } N.B.: Je noteert persoon.dans in het events gedeelte, omdat je door het indrukken van de spatiebalk de methode dans aanroept uit de class persoon. Het zelfde geldt voor world.myfirstmethod; in dit geval wordt myfirstmethod aan geroepen uit world.
3.2.6.Het inleveren van de bestanden Zoals eerder vermeld dien je alle bestanden tot één bestand te zippen. Sla storyboards op als plain text (dus als .txt bestand). Je kunt je storyboards maken in een willekeurige text editor, zoals write, notepad onder windows of vi(m), jEdit, emacs onder UNIX/LINUX. Voor het maken van je UML diagrammen kun je gebruik maken van dia, argouml, Visio of eclipse. Wij raden je aan om argouml (http://argouml.tigris.org/) of dia (http://dia-installer.de/index_en.html) te gebruiken. Beide programma’s zijn gratis te downloaden. Argouml kun je zonder installeren vanaf je home directory draaien. Exporteer de UML diagrammen naar png of een pdf formaat.
3.3. Van UML naar storyboard Het volgende voorbeeld laat de relatie tussen UML Use Case diagram en storyboard zien. De beschrijving van de opgave is als volgt: Maak een applicatie waarbij je net zoals op een luchthaven een bagageband met koffers hebt. De bagageband draait voordurend rond, waarbij de koffers op willekeurige tijdstippen langs een passagier komen. De passagier dien zoveel mogelijk koffers van de bagageband af te halen. Het programma moet aan de volgende eisen voldoen:
Zorg dat de koffers willekeurig verschijnen.
Probleemoplossen
12
P R A C T I C U M
Zorg ervoor dat het zichtbaar (bv. m.b.v. een meter) is hoeveel koffers van het totale aantal de passagier van de bagageband heeft afgehaald.
Zorg er voor dat het programma opnieuw start wanneer de passagier 6 koffers van de bagageband heeft afgehaald.
Het UML Use Case diagram ziet er dan als volgt uit: Bagageband
Change speed
Koffers pakken
Pause User Resume
Restart
Stop
User: User sleept het balkje van ‘Change speed’. Progamma: De bagageband draait sneller/langzamer. De koffers verschijnen/verdwijnen sneller. De meter reageert sneller/langzamer. User: User klikt op een koffer. Programma: De aangeklikte koffer verdwijnt. Meter neemt met 1 eenheid toe. Bagageband draait intussen door. User: User klikt op de ‘Pauze’ knop. Programma: De bagageband, koffers en meter staan stil. De ‘Resume’ knop wordt klikbaar. De ‘Pauze’ knop wordt onklikbaar. User: User klikt op de ‘Resume’ knop. Programma: De bagageband draait weer. De koffers verschijnen/verdwijnen weer. De meter wordt weer actief. De ‘Resume’ knop wordt onklikbaar. De ‘Pauze’ knop wordt klikbaar. User: User klikt op de ‘Restart’ knop. Programma: De bagageband start opnieuw. Het aantal gepakte koffers wordt gereset. De meter wordt gereset. User: User klikt op de ‘Stop’ knop. Programma: Het programma stopt en sluit af.
In het bovenstaande Use Case Diagram is de user de gebruiker van het programma in Alice (in het wereld window). De handelingen die de user kan doen staan naast de use cases beschreven. De reacties van het programma op de handelingen van de user staan onder de handelingen van de user beschreven. Dit is het vertrekpunt om het storyboard van de bovenstaande opdracht te maken. Voor de duidelijkheid vermelden we hier dat een aantal methoden in Alice al ingebouwd is zoals ‘Stop’, ‘Restart’, e.d. De methoden die niet in Alice ingebouwd zijn, moet je dus zelf implementeren, zoals ‘Koffers pakken’ in het voorbeeld. In het algemeen kun je dus zeggen dat er 3 typen use cases zijn: 1. Type A: dit type is ge-embedded in het systeem en is dus standaard aanwezig, zoals de “Stop” en “Restart” buttons.
Probleemoplossen
13
P R A C T I C U M
2. Type B: dit type is niet aanwezig en moet dus geïmplementeerd worden, zoals “koffers pakken” in het voorbeeld. 3. Type C is óf een type A die niet interactief is óf een type B die niet interactief is. Main Logic in de main
- Type A of B, maar niet interactief. - Type A is embedded. - Type B wordt geïmplementeerd.
Figuur 2: Drie typen use cases.
Hieronder volgt een mogelijke (globale) storyboard. Events: als de wereld start (actie user): world.myfirstmethod als er geklikt wordt op een koffer (actie user): showRandomKoffers Het hoofdprogramma gedeelte
(actie van het systeem; logic in de main)
world.myfirstmethod { do together { bagageband showRandomKoffers meter } }
De methode ‘bagageband
(type C)
bagageband { loop (oneindig) { bagageband draait } }
Probleemoplossen
14
P R A C T I C U M
De methode ‘showRandomKoffers’
(type B)
showRandomKoffers { koffers verschijnen koffers verdwijnen } De methode ‘meter’ (type C) meter { meter wordt opgehoogd }
De acties onder de knoppen “Change speed”, “Pause”, “Resume”, “Restart” en “Stop” zijn al in Alice voorgeprogrammeerd in het wereld window. Deze zijn dus allemaal van het type A.
Probleemoplossen
15
