Project Software Engineering. Brand New Auto

Project Software Engineering

Brand New Auto Bram Schrijvers Cedric Vanaken Karel Frederix Kristof Thys Maarten Cardinaels Panagiotis Korovessis Wesley Hendrikx 6 juni 2004

1

Inhoudsopgave 1 Glossary

6

2 Planning en Taakverdeling 2.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Taakverdeling . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 8 8

3 Requirements Analyse 10 3.1 Overzicht van de probleemstelling . . . . . . . . . . . . . . . . 10 3.2 Gebruikersgroepen . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Doelstellingen van het systeem . . . . . . . . . . . . . . . . . . 11 4 Systeemfuncties 4.1 Zaphod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Wereld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 A.I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12 12 13 16

5 High Level Use Cases 5.1 Use cases die te maken hebben met het systeem . . . . . . . . 5.2 Use cases die te maken hebben met de gebruiker . . . . . . . . 5.3 Use Cases die te maken hebben met het AI-gedeelte . . . . . .

17 17 19 24

6 Expanded Use Cases 6.1 Use cases die te maken hebben met het systeem . . . . . . . . 6.2 Use cases die te maken hebben met de gebruiker . . . . . . . . 6.3 Use Cases die te maken hebben met het AI-gedeelte . . . . . .

26 26 30 50

7 Conceptueel model

55

8 Systeem Sequentie Diagrammen

56

9 Contracten

70

10 Collaboratie Diagrammen

95

11 Real Use Cases

107

12 Design Patterns 138 12.1 Creational Patterns . . . . . . . . . . . . . . . . . . . . . . . . 138 12.2 Structional Patterns . . . . . . . . . . . . . . . . . . . . . . . 138 12.3 Behavioral Patterns . . . . . . . . . . . . . . . . . . . . . . . . 139

2

13 Individuele logs 13.1 Bram Schrijvers . . . 13.2 Cedric Vanaken . . . 13.3 Karel Frederix . . . . 13.4 Kristof Thys . . . . . 13.5 Maarten Cardinaels . 13.6 Panagiotis Korovessis 13.7 Wesley Hendrikx . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

3

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

141 141 144 147 149 152 155 158

Lijst van figuren 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

Conceptueel Model . . . . . . Spel opstarten . . . . . . . . . Spel afsluiten . . . . . . . . . New game . . . . . . . . . . . Save game . . . . . . . . . . . Load game . . . . . . . . . . . Rijden met voertuig . . . . . . Eten in restaurant . . . . . . Wapen kopen . . . . . . . . . Auto opspuiten . . . . . . . . Gokken in casino . . . . . . . Locatie zoeken . . . . . . . . Verzorging . . . . . . . . . . . Geld opslaan en weghalen . . Bank overvallen . . . . . . . . Auto zoeken . . . . . . . . . . Auto stelen . . . . . . . . . . Auto afleveren . . . . . . . . . Beboet worden . . . . . . . . Gearresteerd worden . . . . . Bank binnengaan . . . . . . . Politie omkopen . . . . . . . . Botsen met voertuig . . . . . Verkeersovertreding maken . . Patrouilleren door politie . . . Sterven . . . . . . . . . . . . . Vluchten van de politie . . . . A.I.wagens laten rondrijden . Collaboratiediagram bij UC1.3 Collaboratiediagram bij UC1.4 Collaboratiediagram bij UC1.5 Collaboratiediagram bij UC2.1 Collaboratiediagram bij UC2.2 Collaboratiediagram bij UC2.3 Collaboratiediagram bij UC2.4 Collaboratiediagram bij UC2.5 Collaboratiediagram bij UC2.6 Collaboratiediagram bij UC2.7

4

. . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : :

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . New Game . . . . . Save Game . . . . . Load Game . . . . . Rijden met voertuig Eten . . . . . . . . . Wapen kopen . . . . Auto opspuiten . . . Gokken in casino . . Locatie zoeken . . . Verzorging . . . . .

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

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

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

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

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

55 56 56 57 57 58 58 59 59 60 60 61 61 62 62 63 63 64 64 65 65 66 66 67 67 68 68 69 95 95 96 97 97 98 98 99 99 99

39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75

Collaboratiediagram bij UC2.8, UC2.9 en UC2.15 : acties in de bank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Collaboratiediagram bij UC2.10 : Auto zoeken . . . . . . . . . Collaboratiediagram bij UC2.11 : Auto stelen . . . . . . . . . Collaboratiediagram bij UC2.12 : Auto afleveren . . . . . . . . Collaboratiediagram bij UC2.13 : Beboet worden . . . . . . . Collaboratiediagram bij UC2.14 en UC2.16: Gearresteerd worden en politie omkopen . . . . . . . . . . . . . . . . . . . . . . Collaboratiediagram bij UC2.17 : Botsen met voertuig . . . . Collaboratiediagram bij UC2.18 : Verkeersovertreding maken . Collaboratiediagram bij UC3.1 : Patrouilleren . . . . . . . . . Collaboratiediagram bij UC3.2 : Sterven . . . . . . . . . . . . Collaboratiediagram bij UC3.3 : Vluchten van de politie . . . Collaboratiediagram bij UC3.4 : Zich in het verkeer bevinden Een nieuw spel starten. . . . . . . . . . . . . . . . . . . . . . . Moeilijkheidsgraad kiezen. . . . . . . . . . . . . . . . . . . . . Load game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rijden met voertuig . . . . . . . . . . . . . . . . . . . . . . . . Een gerecht kiezen in een restaurant. . . . . . . . . . . . . . . Gun shop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Garage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Casino : inzetten van geld . . . . . . . . . . . . . . . . . . . . Casino : Resultaat na het gokken . . . . . . . . . . . . . . . . Kaart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ziekenhuis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bank transactie . . . . . . . . . . . . . . . . . . . . . . . . . . Gelukte bankoverval . . . . . . . . . . . . . . . . . . . . . . . Mislukte bankoverval . . . . . . . . . . . . . . . . . . . . . . . Lijst van de objectives . . . . . . . . . . . . . . . . . . . . . . tijdbalkje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beboet worden . . . . . . . . . . . . . . . . . . . . . . . . . . Gearresteerd worden omdat men de boete niet kon betalen. . . Bribe option . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bribe offer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bribe accept . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bribe reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arrested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Klassediagram met enkel relaties en klassen . . . . . . . . . .

5

100 100 101 101 102 102 103 104 105 105 106 106 107 107 109 111 113 115 117 119 120 121 123 124 125 125 127 129 130 130 134 134 134 134 136 136 140

1

Glossary

Hieronder vindt u een lijst van termen die in dit document gebruikt worden: • A.I.: Artficiële intelligentie. • A.I. model: Een model dat gebruik maakt van A.I. • A.I. wagens: De wagens die zelfstandig in de stad rond rijden. Ze worden door het systeeem bestuurd en zijn geen politie. • bulldozer: Graafmachine. • casino: Plaats waar je kan met geld kan gokken. • hangar: Opslagplaats voor auto’s. • healt-meter: Geeft de gezondheid van de speler weer. • honger-meter: Geeft weer hoeveel honger de speler heeft. • inventory: Een lijst van objecten die de speler in zijn bezit heeft. • map: Kaart. • menu: Interface waarin men een keuze kan maken tussen verschillende opties. • objectieven: Doelen die men wil/moet bereiken. • random: Willekeurig. • renderen: Tekenen op het scherm. • resources: De middelen die de applicatie gebruikt. • scooter: Soort brommer. • smeergeld: Het geld dat gebruikt wordt bij omkooppraktijken. • status: Op elk moment bevindt het spel dat gespeeld wordt zich in een bepaalde staat. Dit is de status van het spel. • UI: User interface. • wanted level: De mate waarin de speler gezocht wordt door de politie. Hoe meer misdaden de gebruiker pleegt, hoe hoger het wanted level wordt. 6

• wereld: In dit document wordt met de wereld, de omgeving waarin de speler zich bevindt tijdens het spel, bedoeld. • Zaphod: De naam van de speler in het spel. • zoomlevel: De mate waarin er ingezoomd is.

7

2

Planning en Taakverdeling

2.1

Planning

• Week 1 : 12/4 - 16/4 : Kiezen van de extensie, praktische dingen in orde brengen: CVS, ... • Week 2 : 19/4 - 23/4 : Planning opstellen, opstellen requirements analyse, zoeken naar use cases. • Week 3 : 26/4 - 30/4 : High level en expanded use cases, verdelen systeem sequentie diagrammen en contracten • Week 4 : 3/5 - 7/5 : Systeem sequentie diagrammen en contracten, beginnen aan conceptueel model • Week 5 : 10/5 - 14/5 : Conceptueel model, nakijken use cases + contracten; beginnen aan collaboratiediagrammen en real use cases • Week 6 : 17/5 - 21/5 : Collaboratiediagrammen, real use cases en design patterns zoeken • Week 7 : 24/5 - 28/5 : nakijken collaboratiediagrammen en real use cases. Maken van Design patterns + Klassediagram • Week 8 : 31/5 - 4/6 : Afwerken, nakijken, inbinden • Week 9 : 7/6 : Afgeven

2.2

Taakverdeling

We hebben ervoor gekozen om bij elk groot thema één verantwoordelijke aan te stellen. Deze persoon onderzoekt de theorie over dit onderwerp en legt dit uit aan de rest. De uitwerking van elk thema wordt dan verdeeld onder alle groepsleden, zodat iedereen overal voeling mee heeft. • Requirements analyse : Cedric + Systeemfuncties : Karel • Use cases : Panagiotis • Systeem sequentie diagrammen : Maarten • Contracten : Bram - Cedric • Conceptueel model : Wesley 8

• Collaboratiediagrammen : Kristof • Real Use Cases : Karel • Design Patterns : Bram - Kristof • Klassediagram : Maarten - Panagiotis

9

3 3.1

Requirements Analyse Overzicht van de probleemstelling

We moeten een spel produceren waarbij de gebruiker binnen een bepaalde tijd een aantal wagens moet stelen en ze naar een verzamelplaats moet brengen. Dit alles speelt zich af in een stad waarin verschillende gebouwen te vinden zijn, sommigen hiervan hebben een functie en sommigen worden slechts als decoratie beschouwd. Naast deze gebouwen bevat de stad ook allerlei verschillende wegen, elk met hun eigen kenmerken. Verkeersregels zijn natuurlijk ook aanwezig, wanneer de speler zich niet aan deze regels houdt kan hij in aanvaring komen met de politie en hiervoor beboet of gearresteerd worden. De mate waarin de politie ageert is afhankelijk van het wanted level van de gebruiker. Dit wanted level kan naast het overtreden van verkeersregels ook stijgen wanneer de speler in het bezit van een wapen is, een auto steelt, of een bank overvalt. Wanneer de speler gearresteerd wordt door de politie en in het bezit van geld is, kan hij een poging doen om de politie om te kopen. Wanneer dit niet lukt komt hij uit aan de gevangenis, waardoor hij al zijn geld verliest en een leven kwijtspeelt. Om te voorkomen dat hij al zijn geld verliest, kan de gebruiker een deel van zijn geld bewaren (en eventueel afhalen) in een bank. Dit geld kan hij, naast voor het omkopen van politie, ook gebruiken om wapens of eten te kopen, inzetten in casino’s, gebruiken als betaalmiddel in garage’s (om zijn auto op te spuiten) en in ziekenhuizen. Indien de speler niet eet stijgt zijn honger-meter, en zolang deze op zijn hoogste niveau is zakt de speler zijn health-meter. Deze meter kan ook een stevige deuk krijgen wanneer de gebruiker aangereden wordt, maar in het ziekenhuis kan men de speler terug oplappen, voor een prijsje natuurlijk. Wanneer de speler deze operatie niet kan betalen, zal zijn health meter blijven zakken totdat hij uiteindelijk sterft. Hij is dan 1 leven kwijt, en kan het spel dan verzetten, beginnend zonder geld en wapens, totdat al zijn levens op zijn. De meest voor de handliggende manier om geld te verdienen, en ineens ook het doel van het spel, is het stelen en afleveren van bepaalde wagens. Wanneer zo een gestolen wagen in de hangar van de opdrachtgever wordt binnengebracht, krijgt de speler een geldbeloning die afhankelijk is van de staat en het type van de wagen en van de tijd die hij nodig gehad heeft.

10

3.2

Gebruikersgroepen

Het product dat we ontwikkelen wordt op de commerciële games-markt uitgebracht, en zal dus gericht zijn op jongeren en volwassen computergebruikers die een deel van hun tijd spenderen aan het spelen van computergames. Ons product wordt enkel uitgebracht voor de pc, het wordt niet omgezet naar consoles zoals bijvoorbeeld Playstation en X-Box.

3.3

Doelstellingen van het systeem

Het doel van ons project is het aanbieden van een product dat men kan gebruiken in de vrije tijd. Het ontspanningsgehalte van onze applicatie is bijgevolg vrij hoog. In ons spel is het de bedoeling dat de gebruiker auto’s steelt voor de kost, en deze wagens aflevert bij zijn opdrachtgever. De gebruiker dient zich wel aan de wet te houden in verband met verkeersregels en criminele activiteiten zoals banken overvallen en auto’s stelen. Wanneer hij dit niet doet zal hij in contact komen met de politie en bestaat de kans dat hij dan al zijn geld verliest. Bij het aanvangen van het spel krijgt de speler een lijst van wagens, en het is de bedoeling om deze wagens zo vlug mogelijk te stelen en af te leveren zonder al zijn levens te verliezen. Ondanks het feit dat dit spel rond het thema ‘auto’s stelen’ draait, ligt het absoluut niet in onze bedoeling om de gebruikers aan te sporen tot gelijkaardig gedrag in het echte leven, ons product bevat enkel een entertainend doel.

11

4

Systeemfuncties

4.1 Ref. SF1.1

SF1.2 SF1.3

SF1.4

SF1.5 SF1.6 SF1.7 SF1.8 SF1.9

Zaphod Functie

Klasse

Systeem attribuut Zaphod moet zich kunnen voortbewegen Evident Gebruiksgemak, doorheen de wereld uitvoeringstijd, response tijd Zaphod moet op elk moment een bepaalde Evident Interface metahoeveelheid health hebben foor Hij moet een wanted level hebben dat aan- Evident Interface metageeft hoezeer hij door de politie gezocht foor wordt Hij heeft een honger level dat aangeeft of hij Evident Interface metaal dan niet dringend moet eten. Wanneer de foor hongerlimiet bereikt wordt, daalt z’n health Hij heeft een bepaalde hoeveelheid geld Evident Interface metafoor Hij moet gebouwen kunnen betreden Evident Gebruiksgemak, response tijd Hij kan de politie omkopen Evident Gebruiksgemak Hij heeft een lijst van wagens die hij moet Evident Interface metastelen foor Hij heeft een beperkt aantal levens Evident Interface metafoor

12

4.2

Wereld

Ref. SF2.1 SF2.2 SF2.3 SF2.4 SF2.5

SF2.6 SF2.7 SF2.8 SF2.9 SF2.10 SF2.11

SF2.12 SF2.13

SF2.14

Functie Een wapenwinkel moet betreden kunnen worden In een wapenwinkel kunnen wapens gekocht worden Het bezit van een wapen moet het wanted level verhogen Wanneer men gearresteerd is geweest wordt Zaphod voor het politiebureau geplaatst Wanneer men gearresteerd is geweest, wordt het geld dat Zaphod op zak had in beslag genomen Garages moeten met een voertuig binnengereden kunnen worden In een garage wordt het voertuig herspoten in ruil voor geld Een casino moet betreden kunnen worden

Klasse Attribuut Evident Gebruiksgemak, response tijd Evident Gebruiksgemak Evident Interface metafoor Evident response tijd Hidden

Interface metafoor

Evident Gebruiksgemak, response tijd Hidden Gebruiksgemak

Evident Gebruiksgemak, response tijd In een casino kan de gebruiker een random Hidden Interface metahoeveelheid geld winnen of verliezen foor Ziekenhuizen moet betreden kunnen worden Evident Gebruiksgemak, response tijd In een ziekenhuis wordt de hoeveelheid Hidden Gebruiksgemak health terug hersteld in ruil voor geld. Des te hoger het wanted level, des te meer geld het zal kosten Een bank moet betreden kunnen worden Evident Gebruiksgemak, response tijd In een bank heeft men de keuze uit: geld- Evident transacties doen (geld opslaan of geld afhalen) of de bank overvallen Indien men een bank overvalt, gaat het wan- Evident Interface metated level omhoog foor

13

Ref. Functie SF2.15 Een restaurant moet betreden kunnen worden SF2.16 In een restaurant wordt er gegeten in ruil voor geld SF2.17 Indien men gegeten heeft, wordt het honger level terug op 0 gezet SF2.18 Een hangar kan betreden worden met een voertuig indien dat voertuig op de lijst van te stelen voertuigen stond. SF2.19 Indien men een voertuig in de hangar heeft afgeleverd, krijgt men een bepaalde hoeveelheid geld. Dit is afhankelijk van het type voertuig en de benodigde tijd voor het stelen en binnen brengen ervan SF2.20 Indien men een voertuig gestolen heeft, gaat het wanted level omhoog SF2.21 Voertuigen hebben een bepaalde hoeveelheid schade SF2.22 Voertuigen zijn beperkt met betrekking tot het type van wegen die ze kunnen berijden SF2.23 SF2.24 SF2.25 SF2.26 SF2.27 SF2.28 SF2.29

Klasse Attribuut Evident Gebruiksgemak, response tijd Hidden Gebruiksgemak Evident Interface metafoor Evident Gebruiksgemak, response tijd Hidden

Interface metafoor

Evident Interface metafoor Evident Interface metafoor Hidden Interface metafoor, response tijd Voertuigen hebben een maximumsnelheid Evident Interface metafoor Voertuigen hebben een kleur en een Evident Interface metamerk/type foor Voertuigen hebben 2 modi, namelijk gepar- Evident Interface meta” keerd” of rijdend” foor ” Gewone auto’s mogen elk type weg berijden Hidden Interface metafoor Gewone auto’s kunnen maximum 140 km/u Hidden Interface metarijden foor Scooter’s mogen niet op de autosnelweg Hidden Interface metafoor Scooter’s kunnen maximum 60 km/u rijden Hidden Interface metafoor

14

Ref. Functie SF2.30 Bestelauto’s mogen elk type weg berijden SF2.31 SF2.32 SF2.33 SF2.34 SF2.35 SF2.36 SF2.37 SF2.38 SF2.39 SF2.40 SF2.41 SF2.42 SF2.43

Attribuut Interface metafoor Bestelauto’s kunnen maximum 120 km/u rij- Hidden Interface metaden foor Race-auto’s kunnen niet op de zandwegen Hidden Interface metawant dan gaan ze stuk foor Race-auto’s kunnen maximum 200 km/u rij- Hidden Interface metaden foor Bulldozer’s mogen niet op de autosnelweg Hidden Interface metafoor Bulldozer’s kunnen maximum 40 km/u rij- Hidden Interface metaden foor Politie-auto’s mogen elk type weg berijden Hidden Interface metafoor Politie-auto’s kunnen maximum 180 km/u Hidden Interface metarijden foor Wegen hebben een type en een snelheidlimiet Evident Interface metadie afhankelijk is van het type foor De snelheidslimiet van zandwegen is onbe- Hidden Interface metaperkt foor De snelheidslimiet van autosnelwegen is 120 Hidden Interface metakm/u foor De snelheidslimiet van hoofdwegen is 90 Hidden Interface metakm/u foor De snelheidslimiet van wegen in een bebouw- Hidden Interface metade kom is 50 km/u foor De wereld bevat kruispunten met stoplichten Evident Interface metafoor

15

Klasse Hidden

4.3

A.I.

Ref. Functie SF3.1 Politie agents beschikken over een achtervolginsmechanisme dat toelaat om Zaphod te achtervolgen wanneer hij zich heeft misdragen en zich binnen een bepaalde straal van de agents bevindt SF3.2 Wanneer Zaphod slechts een laag wanted level heeft kan hij er vanaf komen met een boete. Wanneer hij echter probeert te vluchten, gaat het wanted-level omhoog SF3.3 De politiewagens rijden random rond in de wereld en houden zich aan de verkeersregels zolang Zaphod zich gedraagt SF3.4 De politiewagens rijden Zaphod niet omver

16

Klasse Attribuut Evident Interface metafoor, uitvoeringstijd

Evident Interface metafoor

Evident Uitvoeringstijd

Evident Uitvoeringstijd, foutbestendigheid/robuustheid

5 5.1

High Level Use Cases Use cases die te maken hebben met het systeem Reference Use Case Actors Type Description

UC1.1 SPEL OPSTARTEN gebruiker primary Het spel wordt gestart en de nodige initialisaties worden uitgevoerd. Wanneer het spel opgestart is, wordt het hoofdmenu getoond en kan de gebruiker kiezen om een nieuw spel te starten of om een spel te laden.

Reference Use Case Actors Type Description

UC1.2 SPEL AFSLUITEN gebruiker primary Het spel wordt afgesloten zodat de computer weer vrij is voor eventuele andere taken.


UC1.3 NEW GAME gebruiker primary Er wordt een nieuw spel gestart en de spelwereld wordt getoond aan de gebruiker.


UC1.4 SAVE GAME gebruiker primary De huidige status van het spel wordt opgeslaan zodat de speler achteraf het spel opnieuw kan starten en vanaf hier kan verdergaan.

17


UC1.5 LOAD GAME gebruiker primary De speler kan een opgeslagen spel hiermee terug opstarten om zo het spel niet volledig van het begin te moeten hervatten.

18

5.2

Use cases die te maken hebben met de gebruiker Reference Use Case Actors Type Description

UC2.1 RIJDEN MET VOERTUIG gebruiker primary De gebruiker kan rondrijden met een - al dan niet gestolen - voertuig. Niet alle wegen zijn toegankelijk voor bepaalde voertuigen. De gebruiker kan met zijn voertuig ook vluchten van de politie.


UC2.2 ETEN gebruiker primary In de stad bevinden zich een aantal restaurants waar de gebruiker kan gaan eten. De gebruiker moet eten om zijn honger-meter te doen dalen. Voedsel kan enkel gekocht worden dus de gebruiker moet over het nodige geld beschikken als hij wil eten.


UC2.3 WAPEN KOPEN gebruiker primary De gebruiker wil een wapen kopen om hiermee een bank te overvallen. Hierdoor zal zijn wanted-level echter stijgen.

19


UC2.4 AUTO OPSPUITEN gebruiker primary De gebruiker wil zijn auto laten herspuiten zodat de politie hem niet meer herkent, en dus ook niet meer achtervolgt.


UC2.5 GOKKEN IN CASINO gebruiker primary De gebruiker wil geld verdienen via het casino.


UC2.6 LOCATIE ZOEKEN gebruiker primary De gebruiker wil via een kaart van het gebied een locatie in de wereld zoeken.


UC2.7 VERZORGING gebruiker primary De gebruiker kan zich in het ziekenhuis laten verzorgen.


UC2.8 GELD OPSLAAN EN AFHALEN gebruiker primary De gebruiker kan zijn geld naar de bank brengen en het later weer ophalen.

20


UC2.9 BANK OVERVALLEN gebruiker primary De gebruiker kan de bank overvallen.


UC2.10 AUTO ZOEKEN gebruiker primary De gebruiker gaat op zoek naar het te stelen voertuig dat hij heeft gekozen uit zijn lijst van objectieven. Dit bevat de locatie van alle te stelen voertuigen. Zodra de gebruiker er een voertuig heeft uitgepikt, gaat zijn tijd lopen.


UC2.11 AUTO STELEN gebruiker primary De gebruiker komt aan bij een voertuig en probeert het vervolgens te stelen. De tijd die hij nodig heeft om een voertuig te stelen is afhankelijk van het type voertuig.


UC2.12 AUTO AFLEVEREN gebruiker primary De gebruiker arriveert aan een hangar met een gestolen voertuig om dit af te leveren en om geld te verdienen. De hoeveelheid geld dat de gebruiker ontvangt is afhankelijk van de snelheid waarmee de opdracht uitgevoerd is, van de hoeveelheid schade aan het voertuig en van welk merk het voertuig is.

21


UC2.13 BEBOET WORDEN gebruiker primary Als de gebruiker een verkeersovertreding heeft gemaakt, zal de politie hem beboeten (er gaat geld verloren).


UC2.14 GEARRESTEERD WORDEN gebruiker primary Als de gebruiker een voertuig gestolen heeft of als hij te veel verkeersregels overtreden heeft zonder gepakt te zijn, zal de politie hem arresteren (er gaat één leven verloren). Tenzij hij genoeg geld heeft om de politie te kunnen omkopen.


UC2.15 BANK BINNENGAAN gebruiker primary De gebruiker kan de bank binnengaan. Vervolgens krijgt hij de keuze of hij een geldtransactie wil doen (geld opslaan of afhalen) of dat hij de bank wil overvallen.

22


UC2.16 POLITIE OMKOPEN gebruiker optional Als de gebruiker gepakt is door de politie, kan hij de politie proberen om te kopen om zo te ontsnappen aan de wet.


UC2.17 BOTSEN MET VOERTUIG gebruiker optional Als de gebruiker met een voertuig aan het rijden is, kan hij hiermee tegen andere voertuigen of objecten in de wereld botsen.


UC2.18 EEN VERKEERSOVERTREDING MAKEN gebruiker secondary De gebruiker begaat een verkeersovertreding, waardoor zijn wanted-level zal stijgen.

23

5.3

Use Cases die te maken hebben met het AI-gedeelte Reference Use Case Actors Type Description

UC3.1 PATROUILLEREN DOOR POLITIE systeem primary In de stad rijden er politiewagens rond, die controleren of de andere voertuigen zich wel aan de wet houden.


UC3.2 STERVEN systeem primary Wanneer het health level van de gebruiker gelijk is aan nul, sterft hij. Hij heeft echter drie levens.


UC3.3 VLUCHTEN VAN DE POLITIE gebruiker secondary De gebruiker heeft een misdaad begaan en is gezien door de politie, hij moet vluchten.


UC3.4 ZICH IN HET VERKEER BEVINDEN gebruiker primary Auto’s rijden rond, houden zich aan de verkeersregels en proberen niet te botsen.

24


U3.5 HONGERMETER STIJGEN systeem primary De hongermeter van de gebruiker moet constant aan het stijgen zijn, wanneer hij iets eet, zal deze meter, afhankelijk van het verorberde voedsel, een beetje dalen.

25

6 6.1

Expanded Use Cases Use cases die te maken hebben met het systeem

Reference Use Case Actors Purpose

UC1.1 SPEL OPSTARTEN gebruiker Opstarten van het spel en de nodige initialisaties verrichten. Overview De gebruiker start het spel op. Hierdoor wordt het hoofdmenu van het spel geladen en getoond aan de gebruiker. De gebruiker kan dan kiezen om een nieuw spel te starten of om een spel te laden. Type primary and essential Cross References UC1.3 Actor Action 1. De gebruiker start het spel.

System Response 2. Het hoofdmenu wordt ge¨ınitialiseerd en getoond aan de gebruiker.

26

Reference Use Case Actors Purpose Overview

Type Cross References

UC1.2 SPEL AFSLUITEN gebruiker Het spel afsluiten en verlaten zodat de computer weer vrij is voor eventuele andere taken. De gebruiker kiest om het spel af te sluiten. Hierdoor worden alle gebruikte resources weer vrijgegeven en het spel wordt verlaten. primary and essential

Actor Action 1. De gebruiker kiest om het spel af te sluiten.

System Response

2. De gebruikte resources worden vrijgegeven. 3. Het spel wordt verlaten.


UC1.3 NEW GAME gebruiker Een nieuw spel starten. De gebruiker start een nieuw spel. Dit zorgt ervoor dat de spelwereld wordt geladen en getoond wordt aan de gebruiker. Type primary and essential Cross References UC1.1 Actor Action 1. De gebruiker start een nieuw spel via het hoofdmenu.

System Response

2. De spelwereld wordt geladen en getoond aan de gebruiker zodat hij kan beginnen met het spelen van het spel.

27


UC1.4 SAVE GAME gebruiker De huidige status van het spel opslaan. Om niet telkens helemaal opnieuw te moeten beginnen kan de gebruiker het spel opslaan, en het eventueel later hervatten vertrekkend van de opgeslagen status. Type primary Cross References UC1.5 Actor Action 1. De gebruiker slaat het spel op via het hoofdmenu.

System Response

2. De huidige status van de wereld wordt opgeslaan. 3. De gebruiker kan het spel stoppen of verderzetten.

28


UC1.5 LOAD GAME gebruiker De gebruiker laadt een opgeslagen spel in. Wanneer de gebruiker eerder een spel opgeslagen heeft, kan hij dit spel terug inladen om het te hervatten vanaf het opgeslagen status. Type primary Cross References UC1.4 Actor Action 1. De gebruiker kiest in het hoofdmenu de ’spel laden’ keuze.

System Response

2. Het systeem toont de lijst van eerder opgeslagen spellen. 3. De gebruiker maakt zijn keuze uit de lijst. 4. Het systeem laadt de bijhorende wereld in waarna de gebruiker dat spel kan hervatten. Alternative Course 2. De speler heeft nog geen enkel spel opgeslagen, het systeem meldt dit en de gebruiker komt terug in het hoofdmenu terecht.

29

6.2

Use cases die te maken hebben met de gebruiker

30


UC2.1 RIJDEN MET VOERTUIG gebruiker Zich verplaatsen doorheen de stad. De gebruiker kan met verschillende voertuigen rijden om zich door de stad te verplaatsen. Als hij een voertuig gestolen heeft, moet hij dit zo snel mogelijk naar de verzamelplaats brengen. Als Zaphod achtervolgd wordt, kan hij proberen te vluchten van de politie. De verschillende soorten voertuigen zijn: personenwagen, scooter, bulldozer, race-auto en bestelwagen. Type primary and essential Cross References SF1.1, SF2.18, SF2.20, SF2.22, SF2.23, SF2.24, SF2.25, SF2.26, SF2.27, SF2.28, SF2.29, SF2.30, SF2.31, SF2.32, SF2.33, SF2.34, SF2.35, SF2.38, SF2.39, SF2.40, SF2.41, SF2.42, UC2.12, UC2.17 Actor Action 1. De gebruiker stapt in een voertuig.

System Response

2. De snelheid en het schade-niveau wordt op het scherm getoond. 3. De gebruiker begint te rijden met het voertuig. Alternative Course 4. De gebruiker rijdt met een raceauto een zandweg op. 5. Er wordt een boodschap getoond en de schade aan het voertuig stijgt. Alternative Course 4. De gebruiker rijdt met een scooter of een bulldozer de snelweg op. 5. De politie zet de achtervolging in om de gebruiker te beboeten.

31


UC2.2 ETEN gebruiker Honger-meter doen dalen Als Zaphod’s honger-meter tot een maximum gestegen is, zal zijn health-meter langzaam aan dalen. De gebruiker kan daarom een restaurant binnengaan om voedsel te kopen en op te eten. Daardoor zal zijn honger-meter dalen. Type primary and essential Cross References SF1.4, SF1.5, SF2.15, SF2.16, SF2.17, UC3.5 Actor Action System Response 1. De gebruiker begeeft zich naar een restaurant (te voet of met een voertuig). 2. Hij gaat het restaurant binnen. 3. Er wordt een lijst getoond van mogelijke gerechten, afhankelijk van het budget van de gebruiker, en hun prijs. 4. De gebruiker kiest een gerecht. 5. Hij betaalt en verorbert zijn voedsel. 6. De gebruiker verliest geld en zijn honger-meter daalt. 7. Hij wordt nu buiten voor het restaurant geplaatst.

32


UC2.3 WAPEN KOPEN gebruiker De gebruiker wil een wapen kopen om een bank mee te overvallen. Overview De gebruiker gaat een wapenwinkel binnen waar hij kan kiezen tussen verschillende mogelijke wapens, aan verschillende prijzen. Als hij een wapen koopt, stijgt zijn wanted level. Type primary and essential Cross References SF1.3, SF1.6, SF2.1, SF2.2, SF2.3, UC2.9 Actor Action 1. De use case begint wanneer de gebruiker een wapenwinkel binnengaat.

System Response

2. Er wordt een lijst met te kopen wapens gegenereerd. 3. De gebruiker kiest een wapen om te kopen. 4. De gebruiker heeft genoeg geld, het gekozen wapen wordt toegevoegd aan de inventory en het bedrag wordt van het geld van de gebruiker afgetrokken. 5. De gebruiker kan nog een wapen kiezen of kiezen om de winkel te verlaten. 6. Als de gebruiker ervoor kiest om de winkel te verlaten, wordt hij voor de winkel geplaatst en wordt zijn wantedlevel verhoogd. (anders terug naar 2.) Alternative Course 4. De gebruiker heeft niet genoeg geld, de lijst met wapens wordt opnieuw getoond (zodat hij eventueel een ander wapen kan kiezen) en er wordt een boodschap gegenereerd. 33


UC2.4 AUTO OPSPUITEN gebruiker De gebruiker wil zijn auto laten opspuiten zodat de politie hem niet meer herkent. Overview De gebruiker rijdt zijn wagen binnen in een garage, betaalt en zijn wantedlevel daalt. Het bedrag dat betaald moet worden hangt van het wantedlevel Type primary and essential Cross References SF1.3, SF1.6, SF2.6, SF2.7, UC3.3 Actor Action 1. De use case begint wanneer de gebruiker met zijn wagen een garage binnenrijdt.

System Response

2. Het systeem toont het vereiste bedrag (afhankelijk van wantedlevel) dat nodig is om de wagen op te spuiten. Er wordt ook een lijst met mogelijke nieuwe kleuren getoond. 3. Als de gebruiker genoeg geld heeft, kan hij een kleur kiezen, anders wordt hij met een ongewijzigd voertuig en ongewijzigd wantedlevel voor de garage geplaatst. 4. De kleur van de auto wordt aangepast, de auto wordt voor de garage gezet en het wantedlevel is nul.

34


UC2.5 GOKKEN IN CASINO gebruiker De gebruiker wil geld verdienen door een bedrag in te zetten in het casino. Overview De gebruiker gaat het casino binnen en kan kiezen hoeveel geld hij inzet. Afhankelijk van de grootte van deze som, wordt er een random positief of negatief getal gegenereerd, wat bijgeteld wordt bij het budget van de gebruiker. Type primary and essential Cross References SF1.5, SF1.6, SF2.8, SF2.9 Actor Action 1. De use case begint wanneer de gebruiker een casino binnenstapt.

System Response

2. Het systeem toont een inputvenster waarin de gebruiker het bedrag kan ingeven dat hij wil inzetten. 3. De gebruiker kiest een bedrag. 4. Het systeem genereert een random getal tussen -1 en 2. Dit wordt vermenigvuldigd met het ingezette bedrag en bijgeteld bij het budget van de gebruiker. Er wordt een boodschap gegenereerd waarin dit bedrag staat, en de gebruiker wordt voor het casino gezet.

35


UC2.6 LOCATIE ZOEKEN gebruiker De gebruiker wil een locatie zoeken in de wereld, hij doet dit via een kaart. Overview De gebruiker kiest om in te zoomen op de kaart die linksboven constant getoond wordt. Het systeem toont de map afhankelijk van het gekozen zoomlevel. Type primary and essential Cross References UC2.10 Actor Action 1. De use case begint wanneer de gebruiker op de knoppen om in te zoomen op de map linksboven klikt.

System Response

2. Het systeem bouwt een nieuwe kaart op afhankelijk vand e keuze van de gebruiker en toont de gewijzigde versie linksboven.

36


UC2.7 VERZORGING gebruiker Health niveau laten stijgen De gebruiker kan naar het ziekenhuis gaan om zijn health level te laten stijgen. In ruil daarvoor moet hij een bepaalde som geld betalen. Bovendien moet hij meer betalen als zijn wanted level hoger is. Type primary and essential Cross References SF1.2, SF1.6, SF1.9, SF2.10, SF2.11, UC2.17, UC3.5 Actor Action System Response 1. De use case begint wanneer de gebruiker het ziekenhuis binnengaat en om verzorging vraagt. 2. Het systeem zegt met hoeveel zijn health level kan verhogen (afhankelijk van zijn budget en wanted level). 3. De gebruiker kiest een hoeveelheid health. 4. Het systeem verhoogt het health level en verlaagt het geldniveau. De gebruiker wordt terug op straat gezet. Alternative Course 4. De gebruiker heeft niet genoeg geld en wordt terug op straat gezet.

37


UC2.8 GELD OPSLAAN EN WEGHALEN gebruiker Geld veilig wegzetten De gebruiker kan zijn geld veilig wegzetten op de bank. Het nut van deze actie is dat Zaphod deze som geld niet verliest wanner hij opgepakt wordt en terug vrijkomt (geld op zak is immers = 0 dan). Het gevaar is echter dat hij zich moet verplaatsen en de politie hem op het spoor zou kunnen komen. Type primary and essential Cross References SF1.5, SF1.6, SF2.12, SF2.13, UC2.15, UC3.2 Actor Action System Response 1. De use case begint nadat de gebruiker ervoor gekozen heeft om geld af te halen/af te geven (in use case 2.15). Daarna vraagt of geeft hij een bepaalde som geld. 2. Bij afgeven/vragen van som: rekening = rekening +/- som; geld op zak = geld op zak -/+ som. Als er niet genoeg geld beschikbaar is op de rekening wordt som vervangen door het huidige bedrag op de rekening.

38


UC2.9 BANK OVERVALLEN gebruiker Geld verkrijgen De gebruiker kan een bank overvallen. Daarvoor heeft hij een wapen nodig (zonder wapen lukt het overvallen nooit). Mèt een wapen lukt het overvallen ook niet altijd (wel in random gevallen, kans groter bij beter wapen). De hoeveelheid geld die hij kan bemachtigen kan ook verschillen. Na de overval is zijn wanted level gestegen, afhankelijk van de hoeveelheid geld. Type primary and essential Cross References SF1.3, SF1.6, SF2.12, SF2.13, SF2.14, UC2.15, UC2.3 Actor Action 1. De use case begint nadat de gebruiker ervoor gekozen heeft om de bank te overvallen. Vervolgens bedreigt hij de bedienden.

System Response

2. De overval lukt (juist random geval en wapen was goed genoeg). Random som geld wordt door bediende gegeven die wordt bijgeteld bij zijn geld op zak. Bovendien stijgt het wanted level. Alternative Course 2. Het overvallen mislukt (fout random geval, wapen niet goed genoeg of geen wapen), de gebruiker krijgt geen geld en zijn wanted level stijgt.

39


UC2.10 AUTO ZOEKEN gebruiker Het selecteren en zoeken van het te stelen voertuig. De gebruiker gaat op zoek naar een voertuig die hij heeft gekozen uit zijn lijst met de locatie van alle wagens die hij moet stelen. Zodra de gebruiker er een voertuig heeft uitgepikt, gaat zijn tijd lopen. Type primary and essential Cross References SF1.8, UC2.11, UC2.6 Actor Action 1. De use case begint wanneer de gebruiker zijn lijst opvraagt.

System Response

2. Het systeem toont de lijst van de nog te stelen voertuigen. 3. De gebruiker selecteert een voertuig op de lijst. 4. Het systeem start de tijd waarbinnen de gebruiker het betreffend voertuig moet afleveren.

40


UC2.11 AUTO STELEN gebruiker Het stelen van voertuig om zich voort te bewegen in de wereld of om het af te leveren. Overview De gebruiker komt aan bij een voertuig en probeert het vervolgens te stelen. De tijd dat hij nodig heeft om een voertuig te stelen is afhankelijk van type voertuig. Type primary and essential Cross References SF2.20, UC2.10 Actor Action System Response 1. De use case begint wanneer de gebruiker bij een voertuig komt dat hij wenst te stelen. 2. Het systeem start de tijd die nodig is om dit specifiek voertuig te stelen. 3. Geleidelijk aan doet het systeem de wanted level van de gebruiker toenemen. 4. Als de tijd om is, dan wordt dit voertuig beschikbaar voor de gebruiker. 5. De gebruiker stapt in het voertuig.

41


UC2.12 AUTO AFLEVEREN gebruiker Geld verdienen en het spel winnen. De gebruiker arriveert aan een hangar met een gestolen voertuig om dit af te leveren en om geld te verdienen. De hoeveelheid geld die de gebruiker ontvangt, is afhankelijk van de snelheid waarmee de opdracht uitgevoerd is, van de hoeveelheid schade aan de auto en van welk merk de auto is. Type primary and essential Cross References SF2.18, SF2.19, UC2.11 Actor Action System Response 1. De use case begint wanneer de gebruiker met een gestolen voertuig dat op zijn lijst met objectieven staat, een hangar binnenrijdt. 2. Het systeem berekent de hoeveelheid geld dat de gebruiker verdiend heeft en kent dit toe aan de gebruiker. 3. Het systeem verwijdert het gestolen voertuig uit de lijst van de gebruiker. 4. De gebruiker wordt voor de hangar geplaatst.

42


UC2.13 BEBOET WORDEN gebruiker Geld verliezen en dus het bemoeilijken van het spel. Als de gebruiker een verkeersovertreding heeft gemaakt, zal de politie de gebruiker beboeten (er gaat geld verloren). Type primary and essential Cross References SF3.2, UC3.1, UC2.18 Actor Action 1. De use case begint wanneer de gebruiker gepakt is door de politie.

System Response

2. Het systeem bepaalt de boete die de gebruiker moet betalen. 3. De gebruiker heeft genoeg geld, de boete wordt afgetrokken van zijn hoeveelheid geld en zijn wanted level vermindert. Alternative Course 3. De gebruiker heeft niet genoeg geld, hij wordt gearresteerd en verliest een leven. 4. De gebruiker wordt zonder geld, totaal onberucht, zonder honger en met volle gezondheid voor het politiebureau geplaatst.

43


UC2.14 GEARRESTEERD WORDEN gebruiker Leven verliezen en dus bemoeilijken van het spel. Als de gebruiker een voertuig gestolen heeft of als hij teveel verkeersregels overtreden heeft zonder gepakt te zijn, zal de politie hem arresteren (er gaat één leven verloren). Tenzij hij genoeg geld heeft om de politie te kunnen omkopen. Type primary and essential Cross References SF3.2, UC2.11, UC2.16 Actor Action 1. De use case begint wanneer de gebruiker gepakt is door de politie.

System Response

2. Het systeem genereert een menu waaruit de gebruiker kan kiezen of hij de politie wil proberen om te kopen. 3. De gebruiker wil de politie omkopen en kan tot driemaal toe een bod maken. 4. Het systeem gaat met één van de bodden akkoord en trekt het smeergeld af van het budget van de gebruiker en laat zijn wanted level dalen. Alternative Course 4. Het systeem is niet akkoord met één van de 3 bodden, de gebruiker wordt gearresteerd en verliest een leven. 5. De gebruiker wordt zonder geld, totaal onberucht, zonder honger en met volle gezondheid voor het politiebureau geplaatst.

44

Alternative Course 3. De gebruiker waagt het niet om de politie om te kopen. 4. De gebruiker verliest een leven en wordt zonder geld, totaal onberucht, zonder honger en met volle gezondheid voor het politiebureau geplaatst.

45


UC2.15 BANK BINNENGAAN gebruiker Geldtransacties doen of de bank overvallen De gebruiker kan de bank binnengaan. Vanaf het moment dat hij binnen is, toont het systeem een menu. Daarin zijn 2 keuzes mogelijk: ofwel geldtransactie doen (geld opslaan of afhalen) ofwel de bank overvallen. Een keuze wordt gemaakt en vervolgens gaat het systeem over in de desbetreffende use case (respectievelijk 2.8 en 2.9). Type primary en essential Cross References SF2.12, UC2.8, UC2.9 Actor Action 1. De use case begint wanneer de gebruiker de bank binnengaat

System Response

2. Het systeem genereert een menu waaruit de gebruiker kan kiezen of hij geld wil afhalen/afgeven of de bank wil overvallen 3. De gebruiker geeft aan dat hij geld wil afhalen of afgeven 4. Het systeem gaat over in use case UC2.8. 5. De gebruiker voert deze actie uit. 6. De gebruiker wordt voor de bank geplaatst Alternative Course 3. De gebruiker geeft aan dat hij de bank wil overvallen. 4. Het systeem gaat over in use case UC2.9. 5. De gebruiker voert deze actie uit. 6. De gebruiker wordt voor de bank geplaatst.

46


UC2.16 POLITIE OMKOPEN gebruiker Ontsnappen aan de wet. Als de gebruiker gepakt is door de politie, kan hij de politie proberen om te kopen. Type primary and essential Cross References SF1.7, UC2.14 Actor Action 1. De use case begint wanneer de gebruiker gearresteerd is en via een menu ervoor gekozen heeft om de politie om te kopen.

System Response

2. Het systeem genereert een menu waaruit de gebruiker tot driemaal toe een bedrag kan kiezen om de politie om te kopen. 3. De gebruiker doet drie bodden. 4. Het systeem gaat met één van de bodden akkoord en trekt het smeergeld af van het budget van de gebruiker en laat zijn wanted level dalen. Alternative Course 4. Het systeem is niet akkoord met één van de drie bodden, de gebruiker wordt gearresteerd en verliest een leven. 5. De gebruiker wordt zonder geld, totaal onberucht, zonder honger en met volle gezondheid voor het politiebureau geplaatst.

47


UC2.17 BOTSEN MET VOERTUIG gebruiker Voorzichtiger rijden De gebruiker kan met zijn voertuig tegen andere voertuigen of objecten in de wereld botsen. Type primary and essential Cross References UC2.1, UC2.7, UC3.2, SF1.1, SF2.21 Actor Action 1. De gebruiker rijdt met zijn voertuig tegen een ander object (voertuig of gebouw) in de wereld

System Response

2. Er wordt een boodschap getoond en de schade aan het voertuig wordt verhoogd. De health meter van Zaphod wordt ook aangepast, afhankelijk van de impact. 3. Als de health meter van Zaphod tot 0 is gezakt, verliest hij een leven.

48


UC2.18 EEN VERKEERSOVERTREDING MAKEN gebruiker Ofwel wil de gebruiker sneller de opdrachten in het spel kunnen vervolledigen, ofwel was het helemaal niet de bedoeling. Overview De gebruiker begaat een verkeersovertreding. De mogelijke overtredingen zijn: een botsing, door het rood rijden, te hard rijden te traag rijden op de snelweg. Type secondary Cross References UC2.1, UC2.13, SF1.1, SF1.3, SF2.38-2.43 Actor Action 1. De use case begint wanneer de gebruiker een overtreding begaat.

System Response

2. Het wanted-level van Zaphod wordt verhoogd, naar gelang de aard van de overtreding.

49

6.3

Use Cases die te maken hebben met het AI-gedeelte


UC3.1 PATROUILLEREN DOOR POLITIE systeem Wet handhaven. In de stad rijden er politiewagens rond, die controleren of de andere voertuigen zich wel aan de wet houden. Type primary and essential Cross References UC2.13, UC2.14, SF1.3, SF3.3, SF3.4 Actor Action

System Response 1. De use case begint bij aanvang van het spel. De politiewagens patrouilleren via een A.I. model.

50


UC3.2 STERVEN systeem Spel interessant houden, uitdaging om acties te ondernemen Overview De gebruiker sterft als zijn health gelijk is aan nul. Daardoor verliest hij één van zijn drie levens. Hij komt daarna terug tevoorschijn op een random plaats in de wereld. Zijn geld op zak is dan opnieuw gelijk aan nul, maar het geld op de bank behoudt hij. Zijn health is terug maximaal en zijn hongerlevel en wantedlevel terug minimaal. Heeft hij geen levens meer dan is het spel afgelopen. Type primary en essential Cross References UC2.8, UC2.17, SF1.2, SF1.5, SF1.9 Actor Action

System Response 1. De use case begint wanneer de health gelijk is aan nul. De gebruiker verliest een leven en komt terug tevoorschijn op een random plaats. Geld op zak = 0, geld op bank = bewaard, health = maximaal, hongerlevel = 0, wanted level = 0 Alternative Course 1. De health is gelijk aan nul maar de gebruiker heeft geen levens meer. Het spel is dan gedaan.

51


UC3.3 VLUCHTEN VAN DE POLITIE gebruiker Proberen de politie kwijt te spelen, als de gebruiker achtervolgt wordt. Overview De gebruiker heeft een misdaad begaan. Hij moet vluchten van de politie. Type secondary Cross References UC2.4, UC2.13, UC2.14, SF1.1, SF1.3, SF1.7, SF3.1 Actor Action 1. De use case begint wanneer de gebruiker één of meerdere misdaden heeft begaan en hij wordt gezien door de politie.

System Response

2. Zolang de politie zich binnen een straal, afhankelijk van het wantedlevel, van de gebruiker bevindt, wordt de gebruiker achtervolgd. 3. De gebruiker probeert te vluchten en kan zorgen dat de politie zich niet meer binnen de straal bevindt. 4. De politie geeft het op. Alternative Course 3. De gebruiker slaagt er niet in de politie te ontlopen. 4. De politie tikt de gebruiker en de arrestatie of beboeting wordt in gang gezet.

52


UC3.4 ZICH IN HET VERKEER BEVINDEN. gebruiker Generatie van verkeer in de stad. De A.I. wagens rijden rond, houden zich aan het verkeer en proberen niet te botsen. Type primary Cross References UC2.17, SF1.1, SF2.22, SF2.23, SF2.25-2.37 Actor Action 1. De use case begint als de gebruiker zich in de stad bevindt

System Response

2. Het systeem laat A.I. wagens constant naar willekeurige bestemmingen rijden.

53


UC3.5 HONGERMETER LATEN STIJGEN. systeem Het laten stijgen van de hongermeter van de gebruiker Overview Door niet te eten stijgt de hongermeter van de gebruiker, wanneer deze op zijn hoogste punt is vermindert de health geleidelijk aan. Type primary Cross References UC2.2,UC3.2, SF1.2, SF1.4, SF2.17 Actor Action

System Response 1. De use case begint als een nieuw spel begonnen is of een opgeslagen spel geladen is. Het systeem laat de meter constant stijgen. 2. Wanneer de hongermeter vol is stopt het systeem met de meter te laten stijgen en zal hij de healthmeter laten zakken.

54

7

Conceptueel model

Figuur 1: Conceptueel Model

55

8

Systeem Sequentie Diagrammen

Figuur 2: Spel opstarten

Figuur 3: Spel afsluiten

56

Figuur 4: New game

Figuur 5: Save game

57

Figuur 6: Load game

Figuur 7: Rijden met voertuig

58

Figuur 8: Eten in restaurant

Figuur 9: Wapen kopen

59

Figuur 10: Auto opspuiten

Figuur 11: Gokken in casino

60

Figuur 12: Locatie zoeken

Figuur 13: Verzorging

61

Figuur 14: Geld opslaan en weghalen

Figuur 15: Bank overvallen

62

Figuur 16: Auto zoeken

Figuur 17: Auto stelen

63

Figuur 18: Auto afleveren

Figuur 19: Beboet worden

64

Figuur 20: Gearresteerd worden

Figuur 21: Bank binnengaan

65

Figuur 22: Politie omkopen

Figuur 23: Botsen met voertuig

66

Figuur 24: Verkeersovertreding maken

Figuur 25: Patrouilleren door politie

67

Figuur 26: Sterven

Figuur 27: Vluchten van de politie

68

Figuur 28: A.I.wagens laten rondrijden

69

9

Contracten

Name Responsibilities Cross References Notes Exceptions Output Pre-conditions Post-conditions

startupGame() het spel opstarten en initialisatiefuncties aanroepen UC1.1


initializeMenu() initializeren van het hoofdmenu. UC1.1


het spel is opgestart en het hoofdmenu is zichtbaar voor de gebruiker.

het systeem moet gestart zijn alle nodige initialisaties zijn uitgevoerd. Het hoofdmenu is nu klaar om getoond te worden.

showMenuToUser() hoofdmenu tonen aan de gebruiker. UC1.1

initializeMenu moet succesvol uitgevoerd zijn. het hoofdmenu is zichtbaar voor de gebruiker.

70




shutdownGame() het spel afsluiten. UC1.2

het systeem moet opgestart zijn. het spel is volledig afgesloten en alle resources zijn vrijgegeven.

freeResources() vrijgeven van de gebruikte resources. UC1.2

de gebruiker heeft gekozen om het spel af te sluiten alle resources zijn vrijgegeven. We zijn klaar om het systeem te verlaten.

exit() het spel verlaten. UC1.2

alle resources zijn vrijgegeven. we hebben het spel verlaten.

71




startNewGame() een nieuw spel beginnen. UC1.3

het systeem moet opgestart en ge¨ınitialiseerd zijn. de spelwereld is ge¨ınitialiseerd en het spel is klaar om gespeeld te worden.

loadGameWorld() de spelwereld inladen en initialiseren. UC1.3

het systeem moet opgestart zijn en de gebruiker heeft gekozen om een nieuw spel te beginnen. de spelwereld is ingeladen en klaar om gerenderd te worden.

showGameWorld() tonen van de spelwereld. UC1.3

de spelwereld moet met succes ingeladen zijn. de spelwereld wordt getoond aan de gebruiker.

72

Name Responsibilities Cross References Notes Exceptions Output Pre-conditions

Post-conditions

Name Responsibilities Cross References Notes

Exceptions Output Pre-conditions

Post-conditions

saveGame() de huidige status van de spelwereld opslaan. UC1.4

de gebruiker moet een spel aan het spelen zijn voordat hij het kan opslaan. de spelwereld is opgeslaan en de gebruiker kan het spel verderzetten.

saveGameWorld() de huidige status van de spelwereld opslaan. UC1.4 de gebruiker moet geen naam kiezen voor het opgeslagen spel, het systeem zal een naam genereren gebaseerd op de huidige datum en tijdstip.

de gebruiker moet een spel aan het spelen zijn voordat hij het kan opslaan. de spelwereld is opgeslaan en de gebruiker kan het spel verderzetten.

73

Name Responsibilities Cross References Notes Exceptions

Output Pre-conditions

Post-conditions



loadGame() een reeds opgeslagen spel inladen. UC1.5 de gebruiker kan geen spel laden wanneer er nog geen spellen opgeslagen zijn het systeem moet opgestart zijn en de gebruiker moet gekozen hebben om een spel te laden. de gebruiker krijgt een lijst te zijn van opgeslagen spellen waaruit hij kan kiezen.

showSavedGames() de lijst van opgeslagen spellen tonen. UC1.4, UC1.5

er zijn reeds spellen opgeslagen en de gebruiker heeft de loadGame functie aangeroepen. het systeem wacht op een keuze van de gebruiker.

selectSavedGame() een opgeslagen spel kiezen om te laden. UC1.4, UC1.5

het systeem heeft de lijst van opgeslagen spellen getoond. het geselecteerde spel is ingeladen.

74



updateStatus(game) Het inladen van de status van een opgeslagen spel. UC1.5 Dit gebeurt enkel wanneer er reeds spellen opgeslagen zijn.

De gebruiker heeft een opgeslagen spel geselecteerd om in te laden. Het geselecteerde spel is ingeladen en de speler kan dat spel verderzetten.

showVehicleInfo() Toon info over een voertuig aan de gebruiker. UC2.1

De gebruiker heeft plaatsgenomen in een voertuig. De user interface is aangepast aan de info over het voertuig.

Name Responsibilities

enterRestaurant() Geef de gebruiker de kans om zijn honger-level te verhogen door eten te kopen. Cross References UC2.2 Notes Exceptions Output Pre-conditions De gebruiker staat voor het restaurant. Post-conditions De gebruiker bevindt zich in het restaurant.

75


showFoodMenu(money) Toon de gebruiker een lijst van gerechten, afhankelijk van zijn budget. Cross References UC2.2 Notes Exceptions De gebruiker heeft geen geld en kan dus geen eten kopen. Output Pre-conditions De gebruiker is een restaurant binnengegaan. Post-conditions De user interface is aangepast aan de lijst van gerechten.



Exceptions Output Pre-conditions Post-conditions

makeFoodSelection(menuItem) Kies een gerecht. UC2.2

Het menu van gerechten werd getoond. De gebruiker kan het gekozen gerecht betalen.

changeHungerLevel(meal) Hongerlevel verlagen, afhankelijk van het gerecht. UC2.2, UC3.2, UC3.5 Wanneer men een level verloren en heeft en daarna verder speelt met een leven minder is het hongerlevel terug minimaal

De gebruiker laat Zaphod eten. Ook nadat leven verloren is en gespeeld wordt. Het hongerlevel is aangepast

76


enteredGunShop() Gebruiker de wapenwinkel laten binnengaan. UC2.3

De gebruiker moet zich net voor de wapenwinkel bevinden. De binnenkant van de wapenwinkel wordt getoond.


showGuns(money) Tonen van de wapens die de gebruiker kan kopen (afhankelijk van het budget van de gebruiker). Cross References UC2.3 Notes Exceptions Output Pre-conditions De gebruiker moet de wapenwinkel binnengegaan zijn. Post-conditions De wapens die de gebruiker kan kopen worden getoond.


chooseGun() Gebruiker kiest een wapen om te kopen. UC2.3

Het systeem moet de wapens die de gebruiker kan kopen tonen. De gebruiker heeft een wapen geselecteerd.

77


addGunToInventory() Gekozen wapen wordt toegevoegd aan de inventory. UC2.3

De gebruiker heeft een wapen geselecteerd in de wapenwinkel. Het systeem heeft het gekozen wapen toegevoegd aan de inventory van de gebruiker.


changeBudget(money) Het verhogen of verlagen van het geld van de gebruiker. Cross References UC2.3, UC2.4, UC2.5, UC2.7, UC2.8, UC2.9, UC2.12, UC3.2 Notes Exceptions Output Pre-conditions De gebruiker heeft een interactie gedaan waarmee geld gemoeid is en staat op het punt om geld te ontvangen of te verliezen. Post-conditions Het systeem verhoogt of verlaagt de hoeveelheid geld van de gebruiker en toont dit via de UI.


changeWantedLevel(x) Verhoog het wanted-level van Zaphod met een hoeveelheid x. Cross References UC2.3, UC2.4, UC2.9, UC2.18, UC3.2, UC3.5 Notes x kan ook negatief zijn. Exceptions Output Pre-conditions De gebruiker heeft een wapen gekocht, zijn auto laten opspuiten, de bank overvallen, een verkeersovertreding gemaakt of is gestorven. Post-conditions Het wanted-level van Zaphod is verhoogd met x.

78


enteredGarage() Binnengaan van een garage. UC2.4

De gebruiker moet zich met zijn wagen net voor de ingang van een garage bevinden. Het systeem toont de binnenkant van de garage.


calculateRepaintCost() Berekenen van de kost om het voertuig opnieuw op te spuiten. Cross References UC2.4 Notes Exceptions Output Pre-conditions De gebruiker moet zich met zijn wagen in een garage bevinden. Post-conditions Het systeem toont de prijs om de auto opnieuw op te spuiten en de mogelijke kleuren.


RepaintCar(color) Herspuiten van de auto. UC2.4

Het systeem heeft de kost om de wagen te herspuiten berekend. De auto krijgt de gewenste kleur.

79




enteredCasino() Binnengaan van een casino. UC2.5

De gebruiker moet zich vlak voor de ingang van het casino bevinden. Het systeem toont de binnenkant van het casino.

gamble(money) Inzetten van geld in het casino. UC2.5

De gebruiker moet zich in het casino bevinden. Het systeem heeft aan de hand van het ingezette geld een gewonnen of verloren som geld berekend.

zoomMap(level) Inzoomen op de map met een bepaalde factor. UC2.6

De gebruiker bevindt zich in de wereld. De gebruiker heeft een bepaald zoomlevel geselecteerd.

80




Exceptions Output Pre-conditions

Post-conditions

showMap() tonen van de map. UC2.6

De gebruiker heeft ervoor gekozen om de map te tonen met een bepaald zoomlevel. De map wordt ingezoomd getoond.

enteredHospital() Gebruiker het ziekenhuis laten binnengaan. UC2.7

De gebruiker moet zich voor het ziekenhuis bevinden. Het systeem toont de binnenkant van het ziekenhuis.

chooseNewHealthLevel(newhealthlevel) Een nieuw healthlevel kiezen UC2.7 De gebruiker heeft altijd genoeg geld voor de verhoging omdat eerst de mogelijke verhoging berekend wordt in functie van het geld.

De gebruiker heeft in het ziekenhuis gevraagd om hem te verzorgen en weet het maximale healthlevel dat hij kan bereiken in functie van zijn geld en wantedlevel. Nieuw level is ingegeven via de UI.

81


Post-conditions



changeHealthLevel(health) Healthlevel van de gebruiker verhogen of verlagen UC2.7, UC3.2, UC3.5 Kan positief of negatief zijn Gebruiker heeft zich in het ziekenhuis laten verzorgen (health = positief) of het hongerlevel is maximaal (health = negatief) Het healthlevel is aangepast met health.

positionZaphod(position) Plaats Zaphod op een bepaalde positie. UC2.7, UC2.13, UC2.15, UC2.16, UC3.2

Zaphod is gearresteerd of bevindt zich in een gebouw. Zaphod vertoeft op de aangegeven plaats.

changeBankAccount(money) Geld op de bank verhogen of verlagen UC 2.8

De gebruiker geeft geld af of vraagt geld van zijn rekening Het geld op de bank is aangepast

82


enteredBank() Gebruiker de bank laten binnengaan. UC2.8, UC2.9 en UC2.15 Niet te verwarren met de use case bank binnengaan die de algemene actie is.

De gebruiker moet zich voor de bank bevinden. Het systeem toont de binnenkant van de bank.


chooseBankOption(choice) Een keuze maken of men een geldtransactie wil doen of de bank wil overvallen Cross References UC2.8, UC2.9 en UC2.15 Notes Exceptions Output Pre-conditions Systeem toont menu met de twee keuzes Post-conditions Gebruiker heeft zijn keuze gemaakt en gemeld aan het systeem via het menu.


threatBankStaff() Bankbediende bedreigen UC2.9 Overval mislukt Gebruiker is in de bank en had de keuze gemaakt om de bank te overvallen Bij gelukte overval geeft bediende geld dat bij geld op zak wordt bijgeteld.

83


getObjectives() Opvragen van de lijst met de locaties van alle voertuigen die er gestolen moeten worden. Cross References UC2.10 Notes Een Objective bestaat uit een voertuig met zijn locatie en de maximale tijd waarin het voertuig moet afgeleverd worden. Exceptions Output Pre-conditions Er moet een toets of muisknop door de gebruiker gedefinieerd zijn voor het oproepen van de lijst. Post-conditions Het systeem wordt aangespoord om de lijst aan de hand van een point and click menu te tonen.


showObjectives() Tonen van de lijst met de locaties van alle voertuigen die er gestolen moeten worden. Cross References UC2.10 Notes Een Objective bestaat uit een voertuig met zijn locatie en de maximale tijd waarin het voertuig moet afgeleverd worden. Exceptions Output Pre-conditions De gebruiker heeft de gedefinieerde toets of muisknop ingedrukt. Post-conditions Het systeem toont de lijst aan de hand van een point and click menu.

84


chooseObjective(objective) Kiezen van een wagen die de gebruiker wenst te stelen en binnen te leveren en starten van de tijd waarbinnen deze opdracht moet gebeuren. Cross References UC2.10 Notes Een Objective bestaat uit een voertuig met zijn locatie en de maximale tijd waarin het voertuig moet afgeleverd worden. Exceptions Indien de voorgaande opdracht nog niet voltooid is, waarschuw dan de gebruiker. Output Pre-conditions De gebruiker heeft de gedefinieerde toets of muisknop ingedrukt en het systeem heeft de lijst getoond. De gebruiker heeft de voorgaande opdracht voltooid. Post-conditions Het systeem start de tijd waarbinnen opdracht voltooid moet zijn. Het systeem doet het menu verdwijnen.


startObjectiveTime() Het starten van de tijd waarbinnen de gekozen opdracht moet gebeuren. Cross References UC2.10 Notes Een Objective bestaat uit een voertuig met zijn locatie en de maximale tijd waarin het voertuig moet afgeleverd worden. Exceptions Output Pre-conditions De gebruiker heeft een opdracht gekozen. Post-conditions Het systeem start de tijd waarbinnen opdracht voltooid moet zijn. Het systeem toont de lopende tijd in de UI.

85


stealVehicle(vehicle) Het stelen van een voertuig. UC2.11

De gebruiker is te voet en komt aan bij een stilstaand voertuig om deze te stelen. Het systeem start de tijd waarbinnen het voertuig gestolen kan worden en verhoogt afhankelijk van de tijd de wanted level van de gebruiker.


startStealTime(vehicle) Het starten van de tijd waarbinnen het voertuig kan gestolen worden. Cross References UC2.11 Notes Exceptions Output Pre-conditions De gebruiker is een voertuig aan het stelen. Post-conditions Het systeem heeft de tijd gestart waarbinnen het voertuig gestolen kan worden. Het systeem toont de lopende tijd in de UI.


enterVehicle(vehicle) Het binnenstappen van een voertuig. UC2.11

De gebruiker heeft een voertuig gestolen. Het voertuig wordt geassocieerd met de gebruiker.

86


enteredHangar(vehicle) Het binnenstappen van een hangar. UC2.12

De gebruiker heeft een voertuig gestolen dat op de lijst staat. Het systeem is klaar om de gebruiker al dan niet te belonen.


calculateReward(time,damage,vehicletype) Het berekenen van de beloning aan de hand van de snelheid waarmee opdracht uitgevoerd is, de schade aan het voertuig en type voertuig. Cross References UC2.12 Notes Exceptions Output Pre-conditions De gebruiker heeft een voertuig gestolen dat op de lijst staat en is daarmee en hangar binnen gereden. Post-conditions Het systeem verhoogt het aantal geld van de gebruiker en plaatst de gebruiker voor de hangar.


Post-conditions

removeObjective(completedObjective) Het verwijderen van een voltooide opdracht. UC2.12

De gebruiker heeft een voertuig gestolen dat op de lijst staat, is daarmee en hangar binnen gereden en heeft zijn geld ontvangen. De voltooide opdracht wordt van de lijst verwijderd.

87


isbusted() Aangeven of de gebruiker al dan niet gepakt is door de politie en beboet zal worden. Cross References UC2.13 Notes Exceptions Output Pre-conditions De gebruiker is gepakt door de politie en zijn wanted level is niet te hoog. Post-conditions Het systeem maakt zich klaar om de gebruiker te beboeten.


calculateFine(wantedlevel) Het berekenen van de boete afhankelijk van de gebruiker zijn wanted level. Cross References UC2.13 Notes Exceptions Output Pre-conditions De gebruiker is gepakt door de politie, zijn wanted level is niet te hoog. Post-conditions Het systeem trekt de boete af van de gebruiker zijn geld en verlaagt zijn wanted level.


isArrested() Aangeven of de gebruiker al dan niet gepakt is door de politie en gearresteerd zal worden. Cross References UC2.13 Notes Exceptions Output Pre-conditions De gebruiker is gepakt door de politie en zijn wanted level is hoog. Post-conditions Het systeem maakt zich klaar om de gebruiker te arresteren.

88


arrest() Arresteren van de gebruiker waardoor hij een leven verliest. Cross References UC2.13, UC2.14 Notes Exceptions Output Pre-conditions De gebruiker heeft niet genoeg geld om boete te betalen. De gebruiker heeft de politie niet willen of kunnen omkopen. Post-conditions De gebruiker is een leven kwijt. De gebruiker heeft geen geld meer op zak. De gebruiker heeft geen honger en is onberucht.


showArrestedMenu() tonen van arrestedmenu UC2.14

De gebruiker is gepakt door de politie met de bedoeling hem te arresteren. Het systeem toont het betreffende menu.


chooseArrestedOption(choice) Kiezen of de gebruiker de politie al dan niet wilt omkopen. Cross References UC2.14 Notes Exceptions Output Pre-conditions Het systeem heeft het arrested menu getoond. Post-conditions Het systeem maakt zich klaar om de politie om te kopen. Anders verliest de gebruiker een leven en al zijn geld en zijn andere eigenschappen worden gereset

89




showBankMenu() Bankmenu aan gebruiker tonen UC 2.15

De gebruiker is de bank binnengegaan Het systeem toont het menu

askMoneyTransaction(money,type) Geld op bankrekening zetten of afhalen UC2.15 money staat voor het bedrag en type staat voor opslaan (= 0) of afhalen (= 1)

Gebruiker is in de bank en had de keuze gemaakt om een geldtransactie te doen Bankbediende neemt geld aan of geeft geld.

showBriberyMenu() Tonen van het menu met betrekking tot omkopen. UC2.16

De gebruiker is gearresteerd door de politie en heeft ervoor gekozen om de politie. Het systeem toont het betreffend menu.

90


makeBid(money) Aanbieden van een poging om de politie om te kopen. Cross References UC2.16 Notes Exceptions Output Pre-conditions De gebruiker heeft gekozen om de politie om te kopen en doet een bod om de politie om te kopen. Post-conditions Het systeem aanvaardt het bod en het smeergeld wordt afgetrokken van zijn geld.


collide(vehicle,object) Afhandelen van een botsing tussen een voertuig en een ander object in de wereld. Cross References UC2.17 Notes Een object kan een voertuig zijn of een ”statisch” object in de wereld (gebouw, verlichtingspaal, etc.). Exceptions Output Pre-conditions Het voertuig van de gebruiker moet in beweging zijn. Post-conditions De schade aan het voertuig (de voertuigen) kan berekend worden.


showCollisionMessage() Laat de gebruiker weten dat hij ergens tegen gebotst is. Cross References UC2.17 Notes Exceptions Output Pre-conditions De gebruiker is gebotst met zijn voertuig. Post-conditions De gebruiker weet dat hij gebotst heeft.

91


changeDamage(damage) Verhoog de schade aan een voertuig. UC2.17

Het voertuig moet betrokken geweest zijn in een botsing. De schade aan het voertuig is toegenomen.


trafficCrimeCommitted(Type) Verhoog het wanted-level van Zaphod als hij een verkeersovertreding begaan heeft. Cross References UC2.18, UC3.5 Notes Een botsing wordt met een andere systeemfunctie afgehandeld. Exceptions Output Pre-conditions De gebruiker is met een voertuig aan het rijden. Post-conditions Het wanted-level van Zaphod is verhoogd, naargelang de soort overtreding die gemaakt is.


patrol() Laten patrouilleren van de politie doorheen de wereld op zoek naar overtreders. Cross References UC3.1 Notes Exceptions Output Pre-conditions De wereld is ingeladen en er zijn AI politiewagens aangemaakt. Post-conditions Het al dan niet detecteren van overtreders.

92


changeLives() Aantal levens met 1 verlagen UC3.2 Als de gebruiker geen levens meer heeft is het spel gedaan.

Healthlevel van de gebruiker stond op 0 De gebruiker heeft 1 leven minder


catchZaphod() De positie berekenen waar Zaphod zich de volgende tijdstap waarschijnlijk gaat bevinden. Een snelste route naar deze positie berekenen en deze route volgen. Cross References UC3.3 Notes Exceptions Output Pre-conditions De politie heeft gedetecteerd dat Zaphod één of meerdere misdaden heeft begaan. De politie weet waar Zaphod zich bevindt. Post-conditions De posititie, waar Zaphod zich waarschijnlijk zal bevinden, op het volgende tijdstip is gecreëerd en berekend. Een snelste route naar deze positie is gecreëerd en berekend. De positie van de politie is gewijzigd, ze bevindt zich ergens op de snelste route, afhankelijk van de snelheid van de politie.

93


spotZaphod() Detecteren dat zaphod één of meerdere misdaden begaan heeft. Cross References UC3.3 Exceptions Output Pre-conditions De politie komt binnen een straal van Zaphod. De grootte van de straal rond Zaphod hangt af van zijn wanted-level. Post-conditions De status van de politie is op achtervolgen gezet.

Name Responsibilities Cross References Exceptions Output Pre-conditions Post-conditions

Name Responsibilities Cross References Exceptions Output Pre-conditions Post-conditions

initializeAICars(number) A.I. wagens in de stad plaatsen. UC3.4

De stad bevat nog geen verkeer. Een aantal (number) A.I.wagens zijn aangemaakt. De wagens hebben een willekeurig positie en een type gekregen. De wagens kregen een bestemming. De bestemming is ge¨ınitialiseerd op de huidige positie.

generateTraffic() Zorgen voor verkeer met behulp van de A.I.wagens UC3.4

Er bevinden zich A.I.wagens in de stad. De wagens hebben een bestemming. De wagens die zich op hun bestemming bevonden, hebben een nieuwe bestemming gekregen. Een snelste route naar deze positie is gecreëerd en berekend. De positie van alle wagens is gewijzigd. Ze bevinden op hun snelste route en zijn iets dichter bij hun bestemming.

94

10

Collaboratie Diagrammen

We hebben ervoor gekozen om bij de belangrijkste use cases een collaboratiediagram te maken. Dit leek ons het meest intuitieve en de meest logische keuze.

Figuur 29: Collaboratiediagram bij UC1.3 : New Game

Figuur 30: Collaboratiediagram bij UC1.4 : Save Game

95

Figuur 31: Collaboratiediagram bij UC1.5 : Load Game

96

Figuur 32: Collaboratiediagram bij UC2.1 : Rijden met voertuig

Figuur 33: Collaboratiediagram bij UC2.2 : Eten

97

Figuur 34: Collaboratiediagram bij UC2.3 : Wapen kopen

Figuur 35: Collaboratiediagram bij UC2.4 : Auto opspuiten

98

Figuur 36: Collaboratiediagram bij UC2.5 : Gokken in casino

Figuur 37: Collaboratiediagram bij UC2.6 : Locatie zoeken

Figuur 38: Collaboratiediagram bij UC2.7 : Verzorging

99

Figuur 39: Collaboratiediagram bij UC2.8, UC2.9 en UC2.15 : acties in de bank

Figuur 40: Collaboratiediagram bij UC2.10 : Auto zoeken

100

Figuur 41: Collaboratiediagram bij UC2.11 : Auto stelen

Figuur 42: Collaboratiediagram bij UC2.12 : Auto afleveren

101

Figuur 43: Collaboratiediagram bij UC2.13 : Beboet worden

Figuur 44: Collaboratiediagram bij UC2.14 en UC2.16: Gearresteerd worden en politie omkopen

102

Figuur 45: Collaboratiediagram bij UC2.17 : Botsen met voertuig

103

Figuur 46: Collaboratiediagram bij UC2.18 : Verkeersovertreding maken

104

Figuur 47: Collaboratiediagram bij UC3.1 : Patrouilleren

Figuur 48: Collaboratiediagram bij UC3.2 : Sterven

105

Figuur 49: Collaboratiediagram bij UC3.3 : Vluchten van de politie

Figuur 50: Collaboratiediagram bij UC3.4 : Zich in het verkeer bevinden

106

11

Real Use Cases


UC1.3 NEW GAME gebruiker Een nieuw spel starten. De gebruiker start een nieuw spel. Dit zorgt ervoor dat de spelwereld wordt geladen en getoond wordt aan de gebruiker. Type primary and essential Cross References UC1.1

Figuur 51: Een nieuw spel starten.

Figuur 52: Moeilijkheidsgraad kiezen.

107

Actor Action 1. De gebruiker start een nieuw spel door in het hoofdmenu te klikken op New Game”. (figuur 51) ”

System Response

2. Er wordt een dialoog getoond met drie moeilijkheidsgraden waaruit de gebruiker een keuze moet gaan maken. (figuur 52)

3. De gebruiker kiest de moeilijkheidsgraad van het spel door één van de drie keuzes aan te duiden en op OK te klikken. 4. De spelwereld wordt geladen en getoond aan de gebruiker zodat hij kan beginnen met het spelen van het spel.

108

Load Gam Use Case Actors Overview

UC1.5 LOAD GAME gebruiker Wanneer de gebruiker eerder een spel opgeslagen heeft, kan hij dit spel terug inladen om het te hervatten met het opgeslagen status. Type primary Cross Reference UC1.4

Figuur 53: Load game

109

Actor Action 1. De use case begint wanneer de gebruiker in de menu de Load Game optie kiest.

System Response

2. Het systeem genereert een menu waarin de reeds opgeslagen spellen getoond worden. Zie figuur 53 3. De gebruiker kiest een spel uit de lijst. 4. Het systeem laadt het spel in en de speler kan het gekozen spel verderzetten. Alternative Course 2. Er zijn nog geen spellen opgeslagen, het systeem meldt dit en de gebruiker komt terug in de hoofdmenu terecht.

110

Reference Use Case Actors Overview

UC2.1 RIJDEN MET VOERTUIG gebruiker De gebruiker kan met verschillende voertuigen rijden om zich door de stad te verplaatsen. Als hij een voertuig gestolen heeft, moet hij dit zo snel mogelijk naar de verzamelplaats brengen. Als Zaphod achtervolgd wordt, kan hij proberen te vluchten van de politie. De verschillende soorten voertuigen zijn: personenwagen, scooter, bulldozer, race-auto en bestelwagen. Type primary Cross Reference UC2.12

Figuur 54: Rijden met voertuig

111

Actor Action 1. De gebruiker wandelt naar een voertuig en geeft aan dat hij wil instappen

System Response

2. De gebruiker wordt in het voertuig geplaatst en het systeem toont de snelheid en het schade-niveau van het voertuig. 3. Het voertuig kan door de gebruiker bestuurd worden met behulp van het toetsenbord. Alternative Course 4. De gebruiker rijdt met een raceauto een zandweg op. 5. Er wordt een boodschap getoond en de schade aan het voertuig stijgt, zolang de gebruiker over de zandweg rijdt. Alternative Course 4. De gebruiker rijdt met een scooter of een bulldozer de snelweg op. 5. Het wanted-level van Zaphod stijgt. 6. De politie zet de achtervolging in om de gebruiker te beboeten of eventueel te arresteren.

112


UC2.2 ETEN gebruiker Als Zaphod’s honger-meter tot een maximum gestegen is, zal zijn health-meter langzaam aan dalen. De gebruiker kan daarom een restaurant binnengaan om voedsel te kopen en op te eten. Type primary Cross Reference UC3.5

Figuur 55: Een gerecht kiezen in een restaurant.

113

Actor Action System Response 1. De gebruiker begeeft zich naar een restaurant (te voet of met een voertuig). 2. Hij gaat het restaurant binnen. 3. Er wordt een lijst getoond van mogelijke gerechten, afhankelijk van het budget van de gebruiker, en hun prijs. 4. De gebruiker kiest een gerecht (zie figuur 55). 5. Hij betaalt en verorbert zijn voedsel. 6. De gebruiker verliest geld en zijn honger-meter daalt. 7. Hij wordt nu buiten voor het restaurant geplaatst.

114


UC2.3 WAPEN KOPEN gebruiker De gebruiker gaat een wapenwinkel binnen, waar hij kan kiezen tussen verschillende wapens aan verschillende prijzen. Als hij een wapen koopt stijgt zijn wanted level. Type primary Cross Reference UC2.9

Figuur 56: Gun shop

115

Actor Action 1. De use case begint wanneer de gebruiker aan de ingang van een wapenwinkel halt houdt, en zo aangeeft dat hij de winkel wil binnengaan.

System Response

2. Het systeem genereert afhankelijk van het budget van de gebruiker een lijst met wapens waaruit de gebruiker kan kiezen. Zie figuur 56. 3. De gebruiker kiest uit het menu een wapen of kiest om de winkel te verlaten. 4. Als de gebruiker een wapen gekozen heeft dan wordt dit wapen door het systeem toegevoegd aan de inventory van de gebruiker, het budget van de gebruiker wordt verminderd met de prijs van het wapen. Daarna wordt de gebruiker terug voor de wapenwinkel geplaatst.

116


UC2.4 AUTO OPSPUITEN gebruiker De gebruiker rijdt zijn auto binnen in een garage, kiest een kleur en betaalt. Hierdoor daalt zijn wantedlevel. Type primary Cross Reference UC3.3

Figuur 57: Garage

117

Actor Action 1. De use case begint wanneer de gebruiker met zijn wagen een garage binnenrijdt.

System Response

2. Het systeem genereert een menu waarin de gebruiker de kost voor het herspuiten van de wagen kan zien, en waar hij een nieuwe kleur kan kiezen. Zie figuur 57. 3. De gebruiker kiest een nieuwe kleur of kiest om de garage te verlaten. 4. Als de gebruiker een nieuwe kleur gekozen heeft dan krijgt de wagen een andere kleur, het wantedlevel van de gebruiker daalt en zijn budget wordt aangepast.

118


Type

UC2.5 GOKKEN IN CASINO gebruiker De gebruiker gaat het casino binnen en kan kiezen hoeveel geld hij inzet. Afhankelijk van de grootte van deze som, wordt er een random positief of negatief getal gegenereerd, wat bijgeteld wordt bij het budget van de gebruiker. primary

Figuur 58: Casino : inzetten van geld

119

Figuur 59: Casino : Resultaat na het gokken Actor Action System Response 1. De use case begint wanneer de gebruiker aan de ingang van een casino halt houdt, en zo aangeeft dat hij het casino wil binnengaan. 2. Het systeem genereert een menu waar de gebruiker geld kan inzetten. Zie figuur 58 3. De gebruiker geeft een hoeveelheid geld in. 4. Het systeem trekt eerst de ingezette som geld af van het budget van de gebruiker. Daarna wordt er een random som geld gegenereerd afhankelijk van de hoeveelheid ingezet geld. Het resultaat wordt aan de gebruiker getoond zoals in figuur 59 en het resulterende bedrag wordt opgeteld bij het budget van de gebruiker.

120


UC2.6 LOCATIE ZOEKEN gebruiker De gebruiker kiest om in te zoomen op de kaart die linksboven constant getoond wordt. Het systeem toont de map steeds rechtsboven afhankelijk van het gekozen zoomlevel. Type primary Cross Reference UC2.10

Figuur 60: Kaart

121

Actor Action 1. De use case begint wanneer de gebruiker op de mini-kaart klikt, linksboven op het gewone scherm.

System Response

2. Het systeem genereert een kaart waarop de gebruiker kan in- en uitzoomen en navigeren. Zie figuur 60 3. De gebruiker kan navigeren met de knoppen en de kaart wegsteken wanneer hij wil. 4. Het systeem reageert op de acties van de gebruiker.

122


UC2.7 VERZORGING gebruiker De gebruiker gaat naar het ziekenhuis om zijn healthlevel te laten verhogen. Hij krijgt de mogelijke verhoging te zien in functie van zijn geld en maakt dan een keuze. Type primary and essential Cross References UC2.17, UC3.5

Figuur 61: Ziekenhuis

Actor Action 1. De use case begint wanneer de gebruiker bij het ziekenhuis aankomt.

System Response

2. Het systeem genereert een menu (figuur 61). Daarin is te zien met hoeveel het healthlevel verhoogd kan worden. Dit is in functie van het geld en het wanted level. 3. De gebruiker kiest hoeveelheid health en klikt op change. 4. Het systeem verhoogt het health level en verlaagt het geldniveau.

123


UC2.8 GELD OPSLAAN EN WEGHALEN gebruiker De gebruiker kan een bepaalde som geld afgeven op de bank of ophalen Type primary and essential Cross References UC2.15, UC3.2

Figuur 62: Bank transactie

Actor Action 1. De use case begint nadat de gebruiker ervoor gekozen heeft om geld af te halen/af te geven

System Response

2. Het systeem genereert een menu waarin kan aageduid worden of geld afgegeven of geld opgevraagd wordt en welke som (figuur 62). 3. De gebruiker maakt zijn keuze en geeft een bepaalde geldsom in. Daarna drukt hij op OK. 4. Het systeem verhoogt/verlaagt het geld op de bank en het geld op zak.

124


UC2.9 BANK OVERVALLEN gebruiker Afhankelijk van het wapen en van het random geval lukt het overvallen en krijgt de gebruiker geld bij. Type primary and essential Cross References UC2.15, UC2.3

Figuur 63: Gelukte bankoverval

Figuur 64: Mislukte bankoverval

125

Actor Action 1. De use case begint nadat de gebruiker ervoor gekozen heeft om de bank te overvallen.

System Response

2. Het systeem geneert een boodschap dat het overvallen gelukt is en welk bedrag de gebruiker erbij krijgt (figuur 63). Alternative Course 2. Het overvallen mislukt en het systeem genereert hier een boodschap voor (figuur 64)

126


UC2.10 AUTO ZOEKEN gebruiker Het selecteren en zoeken van het te stelen voertuig. De gebruiker gaat op zoek naar een voertuig die hij heeft gekozen uit zijn lijst met de locatie van alle wagens die hij moet stelen. Zodra de gebruiker er een voertuig heeft uitgepikt, gaat zijn tijd lopen. Type primary and real Cross References UC2.6, UC2.11

Figuur 65: Lijst van de objectives

127

Actor Action 1. De use case begint wanneer de gebruiker zijn lijst opvraagt door op de ’O’ toets te drukken.

System Response

2. Het systeem toont de lijst van de nog te stelen voertuigen. 3. De gebruiker selecteert een voertuig op de lijst door één van de selectievakjes te selecteren. Daarna duwt hij op de ’Exit’ knop waardoor de lijst terug verdwijnt. 4. Het systeem start de tijd die zich rechtsboven van het gewone scherm bevindt, waarbinnen de gebruiker het betreffend voertuig moet afleveren.

128


UC2.11 AUTO STELEN gebruiker Het stelen van voertuig om zich voort te bewegen in de wereld of om die af te leveren. Overview De gebruiker komt aan bij een voertuig en probeert het vervolgens te stelen. De tijd dat hij nodig heeft om een voertuig te stelen is afhankelijk van type voertuig. Type primary and real Cross References UC2.10

Figuur 66: tijdbalkje

Actor Action System Response 1. De use case begint wanneer de gebruiker bij een voertuig komt die hij wenst te stelen en dit aangeeft door op de spatiebalk te drukken. 2. Het systeem start de tijd die nodig is om dit specifiek voertuig te stelen en toont dit in de vorm van een tijdbalkje. 3. Geleidelijk aan doet het systeem de wanted level van de gebruiker toenemen. 4. Als de tijd om is, dan wordt dit voertuig beschikbaar voor de gebruiker. 5. De gebruiker stapt in het voertuig door op de enter toets te drukken.

129


UC2.13 BEBOET WORDEN gebruiker Geld verliezen en dus het bemoeilijken van het spel. Als de gebruiker een verkeersovertreding heeft gemaakt, zal de politie de gebruiker beboeten (er gaat geld verloren). Type primary and essential Cross References UC3.1, UC2.18

Figuur 67: Beboet worden

Figuur 68: Gearresteerd worden omdat men de boete niet kon betalen.

130

Actor Action 1. De use case begint wanneer de gebruiker gepakt is door de politie.

System Response

2. Het systeem bepaalt de boete die de gebruiker moet betalen en toont dit aan de hand van een dialoog. 3. De gebruiker heeft genoeg geld, de boete wordt afgetrokken van zijn hoeveelheid geld en zijn wanted level vermindert. 4. De gebruiker verlaat de dialoog door op de ’Exit’ knop te drukken. Alternative Course 3. De gebruiker heeft niet genoeg geld, hij wordt gearresteerd en verliest een leven. 4. De gebruiker wordt zonder geld, totaal onberucht, zonder honger en met volle gezondheid voor het politiebureau geplaatst. 5. De gebruiker verlaat de dialoog door op de ’Exit’ knop te drukken.

131

References UC2.14, UC2.16 Use Case GEARRESTEERD WORDEN, POLITIE OMKOPEN Actors gebruiker Purpose Leven verliezen en dus bemoeilijken van het spel. Overview Als de gebruiker een voertuig gestolen heeft of als hij te veel verkeersregels overtreden heeft zonder gepakt te zijn, zal de politie hem arresteren (er gaat één leven verloren). Tenzij hij genoeg geld heeft om de politie te kunnen omkopen. Type primary and essential Actor Action 1. De use case begint wanneer de gebruiker gepakt is door de politie.

System Response

2. Het systeem genereert een menu waaruit de gebruiker kan kiezen of hij de politie wilt proberen om te kopen. 3. De gebruiker wilt de politie omkopen en kan tot driemaal toe een bod maken. In een dialoog kan de gebruiker ingeven hoeveel geld hij wil aanbieden 4. Het systeem gaat met één van de bodden akkoord en toont dit in een messagebox. Het systeem trekt het smeergeld af van de gebruiker zijn hoeveelheid geld en laat zijn wanted level dalen.

132

Alternative Course 4. Het systeem is niet akkoord met één van de 3 bodden. Het systeem toont dit in een messagebox en zegt hoeveel kansen de gebruiker nog heeft. Als de kansen op zijn dan wordt de gebruiker gearresteerd en verliest een leven. Dit wordt ook getoond in een messagebox 5. De gebruiker wordt zonder geld, totaal onberucht, zonder honger en met volle gezondheid voor het politiebureau geplaatst.

Alternative Course 3. De gebruiker waagt het niet om de politie om te kopen. 4. Een messagebox geeft aan dat de gebruiker gearresteerd is. De gebruiker verliest een leven en wordt zonder geld, totaal onberucht, zonder honger en met volle gezondheid voor het politiebureau geplaatst.

133

Figuur 69: Bribe option

Figuur 70: Bribe offer

Figuur 71: Bribe accept

Figuur 72: Bribe reject

134


UC2.15 BANK BINNENGAAN gebruiker De gebruiker kan de bank binnengaan. Vanaf het moment dat hij binnen is toont het systeem een menu. Daarin zijn 2 keuzes mogelijk: ofwel een geldtransactie (geld opslaan of afhalen) ofwel de bank overvallen. Type primary en essential Cross References UC2.8, UC2.9

Actor Action 1. De use case begint wanneer de gebruiker de bank binnengaat

System Response

2. Het systeem genereert een menu waaruit de gebruiker kan kiezen of hij een geldtransactie wil doen of de bank wil overvallen (figuur 74) 3. De gebruiker geeft aan of hij een geldtransactie wil doen of de bank wil overvallen en drukt op OK

135

Figuur 73: Arrested

Figuur 74: Bank

136


UC2.17 BOTSEN MET VOERTUIG gebruiker Voorzichtiger rijden De gebruiker kan met zijn voertuig tegen andere objecten (voertuigen of gebouwen) in de wereld botsen. Type primary and essential Cross References UC2.1, UC3.2 Actor Action 1. De gebruiker rijdt met zijn voertuig tegen een ander object (voertuig of gebouw) in de wereld

System Response

2. Er wordt een boodschap getoond en/of een geluidsfragment afgespeeld. De schade aan het voertuig wordt verhoogd. 3. Zaphod’s health meter wordt verlaagd, afhankelijk van de snelheid waarmee het voertuig gebotst is. 4. Als de schade aan het voertuig niet te ernstig is, kan de gebruiker verder rijden. 5. Als de health meter van Zaphod tot 0 gezakt is, verliest hij een leven.

137

12 12.1

Design Patterns Creational Patterns

Design Pat- Participants Motivation tern Singleton Zaphod, Game, Om voor de hand liggende redenen, wordt ervoor World, Application gezorgd dat er slechts één instantie van elk van deze klassen aangemaakt kan worden. Builder WorldBuilder, The- We hebben voor dit patroon gekozen om de look van WorldBuilder, Ga- de wereld makkelijk aanpasbaar te maken door het me, World, Vehicle, uitzicht ervan te scheiden van de constructie. Zo Road, Building kunnen bijvoorbeeld verschillende types van werelden zeer eenvoudig op dezelfde manier aangemaakt worden door gewoon een nieuwe klasse af te leiden van WorldBuilder. We denken hier bijvoorbeeld aan een wereld zoals Chicago ten tijde van de drooglegging en Al Capone of iets futuristisch of misschien wel gewoon het Brusselse van vandaag...

12.2

Structional Patterns

Design Pat- Participants tern Fa¸cade World

Motivation Het voorziet een higher-level interface dat het subsysteem, namelijk de onderdelen van de wereld, makkelijker te gebruiken maakt.

138

12.3

Behavioral Patterns

Design Pat- Participants tern Template Me- ActiveBuilding, Gathod rage, Restaurant, Casino, Hangar, Bank, Hospital en GunShop

Mediator

World

Strategy

AIAgent, PoliceOfficer en DriveStrategy

139

Motivation Het definieert het skelet van het entered algoritme, waarbij sommige stappen uitgesteld worden tot de subklassen. Template Method laat subklassen toe om bepaalde stappen van een algoritme te herdefinieren zonder de structuur van het algoritme te veranderen. Hier is het van toepassing op de gebouwen die men kan binnenstappen. Afhankelijk van soort gebouw moet er een onderscheid gemaakt worden tussen de mogelijkheden die de speler krijgt bij het binnenwippen. De wereld is een overkoepelend object dat een lijst met autonome voertuigen bijhoudt. De wereld werkt als een mediator tussen deze voertuigen. Er wordt met andere woorden niet in elk voertuig een referentie bijgehouden naar alle andere voertuigen, maar wel naar de wereld. Via de wereld wordt interactie tussen verschillende voertuigen afgehandeld. AI agenten (politie en gewoon verkeer) kunnen zich door de wereld verplaatsen door middel van een eigen strategie. Drivestrategy is de abstracte klasse hiervoor die door de diverse agenten verder ingevuld kan worden. De politie kan meerdere soorten strategieën uitvoeren (patrouilleren en achtervolgen) waartussen geswitched kan worden, PoliceStrategy is hier de abstracte klasse voor.

140 Figuur 75: Klassediagram met enkel relaties en klassen

13 13.1

Individuele logs Bram Schrijvers

Datum Duur Type Inhoud 15.04.2004 1,5 uur groepsvergadering We hebben de opgave overlopen, gekeken wat er het meest dringend moest gebeuren. We hebben een extensie gekozen en extra requirements bedacht. Er is een CVS module opgezet om de communicatie te vergemakkelijken. We hebben besloten om van elke vergadering een verslag te maken, dat ook op CVS gezet wordt, zodat iedereen weet wat er moet gebeuren, en wat de volgende vergadering inhoudt en wanneer die plaatsvindt. 20.04.2004 1 uur groepsvergadering We hebben een ruwe planning opgesteld. 22.04.2004 1,5 uur groepsvergadering We hebben de nodige aandacht besteed aan requirements analyse en we hebben gezocht naar high level en expanded use cases. 24.04.2004 1 uur persoonlijk Opstellen high-level en expanded use cases 2.1 (rijden) en 2.2 (eten). 28.04.2004 1,5 uur persoonlijk Opzoekingen gedaan over contracten. 29.04.2004 2,5 uur groepsvergadering We hebben de high level en expanded use cases overlopen en we hebben er nieuwe ontdekt. Verder hebben we gezamenlijk een voorlopig conceptueel model uitgedacht. Daarna hebben we de systeem sequentie diagrammen en de contracten onder ons verdeeld. 03.05.2004 1,5 uur persoonlijk Expanded use case 2.1 uitgebreid, use case 2.17 toegevoegd (botsen) SSD 2.1, 2.2 en 2.17 gemaakt. 04.05.2004 1 uur groepsvergadering We hebben de gemaakte systeem sequentie diagrammen overlopen en als het nodig was verbeteringen aangeduid. 05.05.2004 1 uur persoonlijk SSD’s verbeterd.

141

06.05.2004 1 uur

groepsvergadering We hebben afspraken gemaakt omtrent de contracten en we hebben voorbereidingen gemaakt voor het afgeven van ons tussentijds rapport. 10.05.2004 1,5 uur persoonlijk Opstellen contracten. 11.05.2004 2 uur groepsvergadering We hebben het conceptueel model met ons allen nagekeken, aangepast, uitgebreid, ... . We hebben een oplossing gevonden voor alternative courses aan te duiden binnen één systeem sequentie diagram. Tenslotte hebben we de cross references bij de use cases en de contracten nagezien. 12.05.2004 2 uur persoonlijk Aanpassen SSD’s aan alternative courses, 1 nieuw contract toegevoegd, SSD’s geexporteerd en in .tex gezet. Voorlopig resultaat in orde gemaakt en doorgestuurd naar begeleiders. 13.05.2004 0,5 uur groepsvergadering We hebben overlopen wat er nog gedaan moet worden, namelijk de real use cases en de collaboratiediagrammen. We hebben besloten om tegen de volgende vergadering hier meer over te weten te komen. 18.05.2004 2 uur groepsvergadering We hebben gezamenlijk een voorbeeld van een collaboratiediagram gemaakt voor het contract showGuns(money). Hieruit hebben we besloten dat één collaboratiediagram per use case beter is dan eentje per contract. Als laatste hebben we de collaboratiediagrammen en real use cases onder ons verdeeld. 22.05.2004 3 uur persoonlijk Opzoeken over design patterns. Richtlijnen collaboratiediagrammen + voorbeelden bekeken. Collaboratiediagrammen Rijden, Eten en Botsen + real use cases 2.1, 2.2 gemaakt. Dialoog-venster bij ‘Eten’ in Qt Designer 24.05.2004 1,5 uur groepsvergadering We hebben gezamenlijk de collaboratiediagrammen en real use cases overlopen en als het nodig was verbeteringen aangeduid. 25.05.2004 1 uur persoonlijk Verbeteren van collaboratie diagrammen. Richtlijnen klassediagram lezen.

142

27.05.2004 1,5 uur groepsvergadering We hebben de design patterns uit de slides bekeken en zijn begonnen met het klassediagram. 28.05.2004 1 uur persoonlijk Opzoeken extra design patterns + GRASP 01.06.2004 2 uur groepsvergadering We hebben extra design patterns overlopen en toegepast in het klassediagram. 03.06.2004 1,5 uur groepsvergadering We hebben het volledige document verdeeld in thema’s (wereld, zaphod, politie, voertuigen, gebouwen, ...). Iedereen kijkt een thema na doorheen het volledige document. 03.06.2004 1,5 uur persoonlijk Volledige bestand overlopen, alles wat met vehicles te maken heeft gecheckt. 04.06.2004 2,5 uur groepsvergadering We hebben het volledige bestand nog eens overlopen en de opmerkingen van iedereen aangepast.

143

13.2

Cedric Vanaken

Datum Duur Type Inhoud 15.04.2004 1,5 uur groepsvergadering We hebben de opgave overlopen, gekeken wat er het meest dringend moest gebeuren. We hebben een extensie gekozen en extra requirements bedacht. Er is een CVS module opgezet om de communicatie te vergemakkelijken. We hebben besloten om van elke vergadering een verslag te maken, dat ook op CVS gezet wordt, zodat iedereen weet wat er moet gebeuren, en wat de volgende vergadering inhoudt en wanneer die plaatsvindt. 20.04.2004 1 uur groepsvergadering We hebben een ruwe planning opgesteld. 22.04.2004 1,5 uur groepsvergadering We hebben de nodige aandacht besteed aan requirements analyse en we hebben gezocht naar high level en expanded use cases. 24.04.2004 1,5 uur persoonlijk Lezen over requirements analyse en nadenken over probleemstelling, doelgroepen en doelstellingen. 25.04.2004 2,5 uur persoonlijk Afwerken van requirements analyse door de tekst van gisteren te vervolledigen en door systeemfuncties te zoeken. Opzoekingen gedaan over contracten. 29.04.2004 2,5 uur groepsvergadering We hebben de high level en expanded use cases overlopen en we hebben er nieuwe ontdekt. Verder hebben we gezamenlijk een voorlopig conceptueel model uitgedacht. Daarna hebben we de systeem sequentie diagrammen en de contracten onder ons verdeeld. 29.04.2004 1 uur persoonlijk Na de groepsvergadering enkele van de pas ontdekte use cases uitgewerkt (high en expanded) en systeem sequentie diagrammen gemaakt. 04.05.2004 1 uur groepsvergadering We hebben de gemaakte systeem sequentie diagrammen overlopen en als het nodig was verbeteringen aangeduid.

144

04.05.2004 1 uur

persoonlijk

05.05.2004 1 uur

persoonlijk

06.05.2004 1 uur

groepsvergadering

08.05.2004 2 uur

persoonlijk

11.05.2004 2 uur

groepsvergadering

11.05.2004 0.5 uur persoonlijk 13.05.2004 0,5 uur groepsvergadering

14.05.2004 0.5 uur persoonlijk 15.05.2004 0.5 uur persoonlijk 18.05.2004 2 uur

groepsvergadering

18.05.2004 2 uur

persoonlijk

145

De nodige verbeteringen in mijn systeem sequentie diagrammen doorgevoerd en gewerkt aan contracten. De contracten afwerken en het conceptueel model uitbreiden. We hebben afspraken gemaakt omtrent de contracten en we hebben voorbereidingen gemaakt voor het afgeven van ons tussentijds rapport. Contracten aangepast volgens de gemaakte afspraken, leerstof lezen en conceptueel model vervolledigen. We hebben het conceptueel model met ons allen nagekeken, aangepast, uitgebreid, ... . We hebben een oplossing gevonden voor alternative courses aan te duiden binnen één systeem sequentie diagram. Tenslotte hebben we de cross references bij de use cases en de contracten nagezien. Systeem sequentie diagrammen aanpassen en cross references verbeteren. We hebben overlopen wat er nog gedaan moet worden, namelijk de real use cases en de collaboratiediagrammen. We hebben besloten om tegen de volgende vergadering hier meer over te weten te komen. Lezen en nadenken over real use cases. Lezen en nadenken over collaboratiediagrammen. We hebben gezamenlijk een voorbeeld van een collaboratiediagram gemaakt voor het contract showGuns(money). Hieruit hebben we besloten dat één collaboratiediagram per use case beter is dan eentje per contract. Als laatste hebben we de collaboratiediagrammen en real use cases onder ons verdeeld. Real use cases en collaboratiediagrammen maken zoals besproken tijdens vergadering.

24.05.2004 1,5 uur groepsvergadering We hebben gezamenlijk de collaboratiediagrammen en real use cases overlopen en als het nodig was verbeteringen aangeduid. 25.05.2004 1.0 uur persoonlijk Opzoeken over design patterns. 27.05.2004 1,5 uur groepsvergadering We hebben de design patterns uit de slides bekeken en zijn begonnen met het klassediagram. 27.05.2004 1 uur persoonlijk Klassediagram overlopen en leerstof lezen. 01.06.2004 2 uur groepsvergadering We hebben extra design patterns overlopen en toegepast in het klassediagram. 03.06.2004 1,5 uur groepsvergadering We hebben het volledige document verdeeld in thema’s (wereld, zaphod, politie, voertuigen, gebouwen, ...). Iedereen kijkt een thema na doorheen het volledige document. 03.06.2004 1,5 uur persoonlijk Volledige bestand overlopen, alles wat met het systeem te maken heeft gecheckt. 04.06.2004 2,5 uur groepsvergadering We hebben het volledige bestand nog eens overlopen en de opmerkingen van iedereen aangepast.

146

13.3

Karel Frederix

Datum Duur Type Inhoud 15.04.2004 1,5 uur groepsvergadering We hebben de opgave overlopen, gekeken wat er het meest dringend moest gebeuren. We hebben een extensie gekozen en extra requirements bedacht. Er is een CVS module opgezet om de communicatie te vergemakkelijken. We hebben besloten om van elke vergadering een verslag te maken, dat ook op CVS gezet wordt, zodat iedereen weet wat er moet gebeuren, en wat de volgende vergadering inhoudt en wanneer die plaatsvindt. 20.04.2004 1 uur groepsvergadering We hebben een ruwe planning opgesteld. 21.04.2004 0,5 uur persoonlijk Lezen over requirements analyse en opzoeken van theorie over systeemfuncties. 22.04.2004 1,5 uur groepsvergadering We hebben de nodige aandacht besteed aan requirements analyse en we hebben gezocht naar high level en expanded use cases. 24.04.2004 1 uur persoonlijk Requirements analyse: opstellen van tabel met systeemfuncties. 29.04.2004 2,5 uur groepsvergadering We hebben de high level en expanded use cases overlopen en we hebben er nieuwe ontdekt. Verder hebben we gezamenlijk een voorlopig conceptueel model uitgedacht. Daarna hebben we de systeem sequentie diagrammen en de contracten onder ons verdeeld. 02.05.2004 2 uur persoonlijk Uitwerking van high-level en expanded use cases + Systeem Sequentie Diagrammen. 04.05.2004 1 uur groepsvergadering We hebben de gemaakte systeem sequentie diagrammen overlopen en als het nodig was verbeteringen aangeduid. 05.05.2004 1,5 uur persoonlijk Uitwerking van contracten, vervolledigen van conceptueel model. 06.05.2004 1 uur groepsvergadering We hebben afspraken gemaakt omtrent de contracten en we hebben voorbereidingen gemaakt voor het afgeven van ons tussentijds rapport.

147

08.05.2004 0,5 uur persoonlijk Conceptueel model vervolledigen. 11.05.2004 2 uur groepsvergadering We hebben het conceptueel model met ons allen nagekeken, aangepast, uitgebreid, ... . We hebben een oplossing gevonden voor alternative courses aan te duiden binnen één systeem sequentie diagram. Tenslotte hebben we de cross references bij de use cases en de contracten nagezien. 13.05.2004 0,5 uur groepsvergadering We hebben overlopen wat er nog gedaan moet worden, namelijk de real use cases en de collaboratiediagrammen. We hebben besloten om tegen de volgende vergadering hier meer over te weten te komen. 14.05.2004 0,5 uur persoonlijk Lezen over real use cases en collaboratiediagrammen. 18.05.2004 2 uur groepsvergadering We hebben gezamenlijk een voorbeeld van een collaboratiediagram gemaakt voor het contract showGuns(money). Hieruit hebben we besloten dat één collaboratiediagram per use case beter is dan eentje per contract. Als laatste hebben we de collaboratiediagrammen en real use cases onder ons verdeeld. 22.05.2004 1 uur persoonlijk Uitwerking van collaboratiediagrammen. 23.05.2004 1,5 uur persoonlijk Uitwerking van real use cases. 24.05.2004 1,5 uur groepsvergadering We hebben gezamenlijk de collaboratiediagrammen en real use cases overlopen en als het nodig was verbeteringen aangeduid. 26.05.2004 1 uur persoonlijk Nadenken over design patterns. 27.05.2004 1,5 uur groepsvergadering We hebben de design patterns uit de slides bekeken en zijn begonnen met het klassediagram. 01.06.2004 2 uur groepsvergadering We hebben extra design patterns overlopen en toegepast in het klassediagram. 02.06.2004 1 uur persoonlijk Nakijken van design patterns en vervolledigen klassediagram. 03.06.2004 1,5 uur groepsvergadering We hebben het volledige document verdeeld in thema’s (wereld, zaphod, politie, voertuigen, gebouwen, ...). Iedereen kijkt een thema na doorheen het volledige document. 03.06.2004 2 uur persoonlijk Het geheel nalezen en verbeteringen aanbrengen. 04.06.2004 2,5 uur groepsvergadering We hebben het volledige bestand nog eens 148 overlopen en de opmerkingen van iedereen aangepast.

13.4

Kristof Thys

Datum Duur Type Inhoud 15.04.2004 1,5 uur groepsvergadering We hebben de opgave overlopen, gekeken wat er het meest dringend moest gebeuren. We hebben een extensie gekozen en extra requirements bedacht. Er is een CVS module opgezet om de communicatie te vergemakkelijken. We hebben besloten om van elke vergadering een verslag te maken, dat ook op CVS gezet wordt, zodat iedereen weet wat er moet gebeuren, en wat de volgende vergadering inhoudt en wanneer die plaatsvindt. 17.04.2004 1 uur persoonlijk Opnieuw doornemen van de opgave en opzoeken theorie. Wat moet er allemaal gebeuren, in welke volgorde, wat zijn de deadlines, wat moet er wanneer afgegeven worden,... 20.04.2004 1 uur groepsvergadering We hebben een ruwe planning opgesteld. 22.04.2004 1,5 uur groepsvergadering We hebben de nodige aandacht besteed aan requirements analyse en we hebben gezocht naar high level en expanded use cases. 24.04.2004 1,5u persoonlijk Opstellen van high level en expanded use cases : wapen kopen, auto opspuiten, gokken in casino. 29.04.2004 2,5 uur groepsvergadering We hebben de high level en expanded use cases overlopen en we hebben er nieuwe ontdekt. Verder hebben we gezamenlijk een voorlopig conceptueel model uitgedacht. Daarna hebben we de systeem sequentie diagrammen en de contracten onder ons verdeeld. 29.04.2004 1 uur persoonlijk De dingen die afgesproken zijn op de vergadering maken. 01.05.2004 2 uur persoonlijk Ik heb de use cases samengevoegd in 1 texbestand en consistent gemaakt. Ook UC.2.6 gemaakt. Daarna systeem sequentie diagrammen gemaakt bij use cases 2.3,2.4,2.5 en 2.6.

149

04.05.2004 1 uur

groepsvergadering We hebben de gemaakte systeem sequentie diagrammen overlopen en als het nodig was verbeteringen aangeduid. 05.05.2004 1 uur persoonlijk De dingen die we hebben afgesproken op de vergadering toevoegen. 06.05.2004 1 uur groepsvergadering We hebben afspraken gemaakt omtrent de contracten en we hebben voorbereidingen gemaakt voor het afgeven van ons tussentijds rapport. 08.05.2004 2 uur persoonlijk Opstellen van contracten van de functies uit use cases 2.3,2.4,2.5 en 2.6. 11.05.2004 2 uur groepsvergadering We hebben het conceptueel model met ons allen nagekeken, aangepast, uitgebreid, ... . We hebben een oplossing gevonden voor alternative courses aan te duiden binnen één systeem sequentie diagram. Tenslotte hebben we de cross references bij de use cases en de contracten nagezien. 11.05.2004 1,5 uur persoonlijk De dingen die afgesproken zijn op de vergadering aanpassen, een SSD.tex aangemaakt en alles samengevoegd in 1 groot tex-bestand, zodat we dit donderdag kunnen afgeven. 13.05.2004 0,5 uur groepsvergadering We hebben overlopen wat er nog gedaan moet worden, namelijk de real use cases en de collaboratiediagrammen. We hebben besloten om tegen de volgende vergadering hier meer over te weten te komen. 15.05.2004 1 uur persoonlijk Theorie bekeken over collaboratiediagrammen. 18.05.2004 2 uur groepsvergadering We hebben gezamenlijk een voorbeeld van een collaboratiediagram gemaakt voor het contract showGuns(money). Hieruit hebben we besloten dat één collaboratiediagram per use case beter is dan eentje per contract. Als laatste hebben we de collaboratiediagrammen en real use cases onder ons verdeeld. 18.05.2004 3 uur persoonlijk Maken van de real use cases bij UC2.3,2.4,2.5 en 2.6. Het maken van de collaboratiediagrammen bij deze use cases.

150

24.05.2004 1,5 uur groepsvergadering We hebben gezamenlijk de collaboratiediagrammen en real use cases overlopen en als het nodig was verbeteringen aangeduid. 24.05.2004 2 uur persoonlijk Bijvoegen van systeemattributen bij de requirements analyse. Het aanpassen van de collaboratiediagrammen zoals besproken tijdens de vergadering. Aanpassen van de screenshots bij real use case : gokken in casino. 25.05.2004 2 uur persoonlijk Bundel van klassediagrammen doorgenomen en een richtlijn op CVS gezet. Opgezocht over design patterns. 27.05.2004 1,5 uur groepsvergadering We hebben de design patterns uit de slides bekeken en zijn begonnen met het klassediagram. 01.06.2004 2 uur groepsvergadering We hebben extra design patterns overlopen en toegepast in het klassediagram. 03.06.2004 1,5 uur groepsvergadering We hebben het volledige document verdeeld in thema’s (wereld, zaphod, politie, voertuigen, gebouwen, ...). Iedereen kijkt een thema na doorheen het volledige document. 03.06.2004 2,5 uur persoonlijk Volledige bestand doorgenomen, extra aandacht besteed aan de dingen die te maken hebben met Zaphod. 04.06.2004 1,5 uur persoonlijk Collaboratiediagrammen omgezet naar image-formaat en toegevoegd in het document. Persoonlijke log toegevoegd. 04.06.2004 2,5 uur groepsvergadering We hebben het volledige bestand nog eens overlopen en de opmerkingen van iedereen aangepast.

151

13.5

Maarten Cardinaels

Datum Duur Type Inhoud 15.04.2004 1,5 uur groepsvergadering We hebben de opgave overlopen, gekeken wat er het meest dringend moest gebeuren. We hebben een extensie gekozen en extra requirements bedacht. Er is een CVS module opgezet om de communicatie te vergemakkelijken. We hebben besloten om van elke vergadering een verslag te maken, dat ook op CVS gezet wordt, zodat iedereen weet wat er moet gebeuren, en wat de volgende vergadering inhoudt en wanneer die plaatsvindt. 18.04.2004 1 uur persoonlijk Opgave opnieuw nalezen, bedoeling en verschillende onderdelen vatten. 20.04.2004 1 uur groepsvergadering We hebben een ruwe planning opgesteld. 22.04.2004 1,5 uur groepsvergadering We hebben de nodige aandacht besteed aan requirements analyse en we hebben gezocht naar high level en expanded use cases. 25.04.2004 2 uur persoonlijk Opstellen high level en expanded use cases ivm met (o.a. voor bank ziekenhuis). Opgezocht over systeem sequentie diagrammen 29.04.2004 2,5 uur groepsvergadering We hebben de high level en expanded use cases overlopen en we hebben er nieuwe ontdekt. Verder hebben we gezamenlijk een voorlopig conceptueel model uitgedacht. Daarna hebben we de systeem sequentie diagrammen en de contracten onder ons verdeeld. 01.05.2004 1.5 uur persoonlijk Zaken tijdens vorige vergadering besproken bijwerken en opstellen Systeem Sequentie Diagrammen. 04.05.2004 1 uur groepsvergadering We hebben de gemaakte systeem sequentie diagrammen overlopen en als het nodig was verbeteringen aangeduid. 05.05.2004 1 uur persoonlijk Aanpassen van SSD’s na vorige vergadering. 06.05.2004 1 uur groepsvergadering We hebben afspraken gemaakt omtrent de contracten en we hebben voorbereidingen gemaakt voor het afgeven van ons tussentijds rapport.

152

Datum Duur 09.05.2004 2 uur 11.05.2004 2 uur

12.05.2004 1.5 uur 13.05.2004 0,5 uur

14.05.2004 1 uur 18.05.2004 2 uur

22.05.2004 2,5 uur

24.05.2004 1,5 uur

25.05.2004 1,5 uur

27.05.2004 1,5 uur

01.06.2004 2 uur

Type Inhoud persoonlijk Aanmaken van contracten voor mijn functies. groepsvergadering We hebben het conceptueel model met ons allen nagekeken, aangepast, uitgebreid, ... . We hebben een oplossing gevonden voor alternative courses aan te duiden binnen één systeem sequentie diagram. Tenslotte hebben we de cross references bij de use cases en de contracten nagezien. persoonlijk Aanpassingen na vorige vergadering, SSD in latex + aanmaken van checklist. groepsvergadering We hebben overlopen wat er nog gedaan moet worden, namelijk de real use cases en de collaboratiediagrammen. We hebben besloten om tegen de volgende vergadering hier meer over te weten te komen. persoonlijk Informatie lezen ivm real use cases en collaboratiediagrammen. groepsvergadering We hebben gezamenlijk een voorbeeld van een collaboratiediagram gemaakt voor het contract showGuns(money). Hieruit hebben we besloten dat één collaboratiediagram per use case beter is dan eentje per contract. Als laatste hebben we de collaboratiediagrammen en real use cases onder ons verdeeld. persoonlijk Bundel lezen ivm collaboratiediagrammen. Opstellen van collaboratiediagrammen en real use cases (2.7,2.8,2.9 en 2.15), samen met UI elementen hiervoor. groepsvergadering We hebben gezamenlijk de collaboratiediagrammen en real use cases overlopen en als het nodig was verbeteringen aangeduid. persoonlijk Verbetering aangebracht aan de collaboratiediagrammen en real use cases, zoals in afgesproken in de vergadering. groepsvergadering We hebben de design patterns uit de slides bekeken en zijn begonnen met het klassediagram. groepsvergadering We hebben extra design patterns overlopen en toegepast in het klassediagram. 153

Datum Duur Type Inhoud 02.06.2004 1 uur persoonlijk Design patterns + klassediagram overlopen. 03.06.2004 1,5 uur groepsvergadering We hebben het volledige document verdeeld in thema’s (wereld, zaphod, politie, voertuigen, gebouwen, ...). Iedereen kijkt een thema na doorheen het volledige document. 03.06.2004 2,5 uur persoonlijk Aanpassingen volgens vergadering en volledig project overlopen en eventuele aanpassingen aanbrengen. 04.06.2004 2,5 uur groepsvergadering We hebben het volledige bestand nog eens overlopen en de opmerkingen van iedereen aangepast.

154

13.6

Panagiotis Korovessis

Datum Duur Type Inhoud 15.04.2004 1,5 uur groepsvergadering We hebben de opgave overlopen, gekeken wat er het meest dringend moest gebeuren. We hebben een extensie gekozen en extra requirements bedacht. Er is een CVS module opgezet om de communicatie te vergemakkelijken. We hebben besloten om van elke vergadering een verslag te maken, dat ook op CVS gezet wordt, zodat iedereen weet wat er moet gebeuren, en wat de volgende vergadering inhoudt en wanneer die plaatsvindt. 20.04.2004 1 uur groepsvergadering We hebben een ruwe planning opgesteld. 21.04.2004 1 uur persoonlijk Requirement analyse, opgezocht over high level use cases en expanded use cases. 22.04.2004 1,5 uur groepsvergadering We hebben de nodige aandacht besteed aan requirements analyse en we hebben gezocht naar high level en expanded use cases. 23.04.2004 1 uur persoonlijk Opstellen van de volgende high level use cases: auto afleveren, beboet worden, gearresteerd worden (en dan kan men proberen om te kopen) en patrouilleren door politie. 26.04.2004 1 uur persoonlijk Opstellen van de volgende expanded use cases: auto afleveren, beboet worden, gearresteerd worden (en dan kan men proberen om te kopen) en patrouilleren door politie. 29.04.2004 2,5 uur groepsvergadering We hebben de high level en expanded use cases overlopen en we hebben er nieuwe ontdekt. Verder hebben we gezamenlijk een voorlopig conceptueel model uitgedacht. Daarna hebben we de systeem sequentie diagrammen en de contracten onder ons verdeeld. 03.05.2004 2,5 uur persoonlijk De aan mij toegewezen use cases verbeteren en opstellen van de volgende nieuwe use cases: auto zoeken, auto stelen en politie omkopen. Vervolgens heb ik de systeem sequentie diagrammen horende bij de aan mij toegewezen use cases opgesteld.

155

Datum Duur 04.05.2004 1 uur

Type Inhoud groepsvergadering We hebben de gemaakte systeem sequentie diagrammen overlopen en als het nodig was verbeteringen aangeduid. 04.05.2004 1 uur persoonlijk Verbeteren van de aan mij toegewezen systeem sequentie diagrammen. 06.05.2004 1 uur groepsvergadering We hebben afspraken gemaakt omtrent de contracten en we hebben voorbereidingen gemaakt voor het afgeven van ons tussentijds rapport. 06.05.2004 2 uur persoonlijk Het opstellen van de contracten horende bij de systeem sequentie diagrammen die ik opgesteld had. Verder eens nagedacht over conceptueel model. 11.05.2004 2 uur groepsvergadering We hebben het conceptueel model met ons allen nagekeken, aangepast, uitgebreid, ... . We hebben een oplossing gevonden voor alternative courses aan te duiden binnen één systeem sequentie diagram. Tenslotte hebben we de cross references bij de use cases en de contracten nagezien. 12.05.2004 1,5 uur persoonlijk De aan mij toegewezen systeem sequentie diagrammen uitbreiden met alternative courses en in latex zetten. Toevoegen van nieuwe contracten. 13.05.2004 0,5 uur groepsvergadering We hebben overlopen wat er nog gedaan moet worden, namelijk de real use cases en de collaboratiediagrammen. We hebben besloten om tegen de volgende vergadering hier meer over te weten te komen. 14.05.2004 1,5 uur persoonlijk Onderzoek gedaan naar real use cases en collaboratiediagrammen. 18.05.2004 2 uur groepsvergadering We hebben gezamenlijk een voorbeeld van een collaboratiediagram gemaakt voor het contract showGuns(money). Hieruit hebben we besloten dat één collaboratiediagram per use case beter is dan eentje per contract. Als laatste hebben we de collaboratiediagrammen en real use cases onder ons verdeeld.

156

Datum Duur Type 18.05.2004 1,5 uur persoonlijk 19.05.2004 3 uur

persoonlijk

24.05.2004 1,5 uur groepsvergadering

24.05.2004 1 uur

persoonlijk


28.05.2004 1 uur 01.06.2004 2 uur

persoonlijk groepsvergadering

01.06.2004 1 uur

persoonlijk


03.06.2004 3 uur

persoonlijk


157

Inhoud Het maken van real use cases voor UC2.10, 2.11 en 2.13 met bijhorende GUI elementen. Het maken van de volgende collaboratiediagrammen: autoAfleveren, autoStelen, autoZoeken, beboetWorden, gearresteerdWorden, patrouilleren en politieOmkopen. We hebben gezamenlijk de collaboratiediagrammen en real use cases overlopen en als het nodig was verbeteringen aangeduid. Opgemerkte verbeteringen toepassen op de collaboratiediagrammen en real use cases. We hebben de design patterns uit de slides bekeken en zijn begonnen met het klassediagram. Lezen over design patterns en GRASP. We hebben extra design patterns overlopen en toegepast in het klassediagram. Uitwerken van de aan mij toegewezen design patterns. We hebben het volledige document verdeeld in thema’s (wereld, zaphod, politie, voertuigen, gebouwen, ...). Iedereen kijkt een thema na doorheen het volledige document. Volledig project overlopen en eventuele aanpassingen aanbrengen overeenkomstig met de vergadering. Skelet van de logfiles gemaakt in Latex, inclusief de groepsvergaderingen. Vervolgens mijn persoonlijke activiteiten toegevoegd. We hebben het volledige bestand nog eens overlopen en de opmerkingen van iedereen aangepast.

13.7

Wesley Hendrikx

Datum Duur Type Inhoud 15.04.2004 1,5 uur groepsvergadering We hebben de opgave overlopen, gekeken wat er het meest dringend moest gebeuren. We hebben een extensie gekozen en extra requirements bedacht. Er is een CVS module opgezet om de communicatie te vergemakkelijken. We hebben besloten om van elke vergadering een verslag te maken, dat ook op CVS gezet wordt, zodat iedereen weet wat er moet gebeuren, en wat de volgende vergadering inhoudt en wanneer die plaatsvindt. 20.04.2004 1 uur groepsvergadering We hebben een ruwe planning opgesteld. 22.04.2004 1,5 uur groepsvergadering We hebben de nodige aandacht besteed aan requirements analyse en we hebben gezocht naar high level en expanded use cases. 26.04.2004 1,5 uur persoonlijk Opstellen van de volgende high level en extended use cases: Vluchten van de politie en zich in het verkeer bevinden. 29.04.2004 2,5 uur groepsvergadering We hebben de high level en expanded use cases overlopen en we hebben er nieuwe ontdekt. Verder hebben we gezamenlijk een voorlopig conceptueel model uitgedacht. Daarna hebben we de systeem sequentie diagrammen en de contracten onder ons verdeeld. 03.05.2004 3,5 uur persoonlijk Toegewezen use cases verbeteren. Een use case voor een verkeersovertreding toevoegen. Systeemdiagrammen opstellen voor elke toegewezen use case. Contracten maken voor elk systeemdiagram. Theorie bekeken over conceptueel model. 04.05.2004 1 uur groepsvergadering We hebben de gemaakte systeem sequentie diagrammen overlopen en als het nodig was verbeteringen aangeduid. 05.05.2004 1 uur persoonlijk Verbeteringen aanbrengen aan het conceptueel model.

158


11.05.2004 2 uur

11.05.2004 1,5 uur 13.05.2004 0,5 uur

13.05.2004 1,5 uur 18.05.2004 2 uur

19.05.2004 4 uur

22.05.2004 2 uur 24.05.2004 1,5 uur

Type Inhoud groepsvergadering We hebben afspraken gemaakt omtrent de contracten en we hebben voorbereidingen gemaakt voor het afgeven van ons tussentijds rapport. groepsvergadering We hebben het conceptueel model met ons allen nagekeken, aangepast, uitgebreid, ... . We hebben een oplossing gevonden voor alternative courses aan te duiden binnen één systeem sequentie diagram. Tenslotte hebben we de cross references bij de use cases en de contracten nagezien. persoonlijk Kleine foutjes uit use cases en SSD, die ik gemaakt heb, halen groepsvergadering We hebben overlopen wat er nog gedaan moet worden, namelijk de real use cases en de collaboratiediagrammen. We hebben besloten om tegen de volgende vergadering hier meer over te weten te komen. persoonlijk Studie over real use cases en collaboratiediagrammen. groepsvergadering We hebben gezamenlijk een voorbeeld van een collaboratiediagram gemaakt voor het contract showGuns(money). Hieruit hebben we besloten dat één collaboratiediagram per use case beter is dan eentje per contract. Als laatste hebben we de collaboratiediagrammen en real use cases onder ons verdeeld. persoonlijk Studie over design patterns. Maken van collaboratiediagrammen voor de zelfgemaakte usecases. persoonlijk Maken van real usecases voor ’gearresteerd worden’ en ’politie omkopen’. groepsvergadering We hebben gezamenlijk de collaboratiediagrammen en real use cases overlopen en als het nodig was verbeteringen aangeduid.

159


Type persoonlijk


01.06.2004 2 uur

groepsvergadering

02.06.2004 1,5 uur persoonlijk 03.06.2004 1,5 uur groepsvergadering

04.06.2004 4 uur

persoonlijk


160

Inhoud Werken aan mijn collaboratiediagrammen, veranderingen uit de vergadering aanbrengen. We hebben de design patterns uit de slides bekeken en zijn begonnen met het klassediagram. We hebben extra design patterns overlopen en toegepast in het klassediagram. Werken aan klassediagram en design patterns. We hebben het volledige document verdeeld in thema’s (wereld, zaphod, politie, voertuigen, gebouwen, ...). Iedereen kijkt een thema na doorheen het volledige document. Overlopen van het hele document. Verbeteringen aanbrengen.Alles (mijn deel) volledig in orde brengen in latex. We hebben het volledige bestand nog eens overlopen en de opmerkingen van iedereen aangepast.

Project Software Engineering. Brand New Auto

Recommend Documents