Ontwerp, bouw en test van een web-gebaseerd, object-georiënteerd Supply Chain simulatiegame Jeroen Dhollander
Promotor: prof. dr. ir. Hendrik Van Landeghem Begeleider: ir. Veronique Limère Scriptie ingediend tot het behalen van de academische graad van Burgerlijk ingenieur in de computerwetenschappen
Vakgroep Technische bedrijfsvoering Voorzitter: prof. dr. ir. Hendrik Van Landeghem Faculteit Ingenieurswetenschappen Academiejaar 2007-2008
Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopi¨eren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”
Jeroen Dhollander, april 2008
Dankwoord Graag wil ik iedereen bedanken die heeft bijgedragen tot de verwezenlijking van dit eindwerk, en in het bijzonder: • Mijn promotor Prof. dr. ir. Hendrik Van Landeghem voor zijn inzichten in de materie van supply chain management en om mij de kans te geven dit onderzoek te verrichten. • Ir. Joris April, ir. Sofie Van Volsem en ir. Veronique Lim`ere voor hun hulp en feedback tijdens de testfase. • Kurt De Cock voor zijn technische hulp bij het opzetten van de werk- en testomgeving. • Sven Berckmoes voor zijn uitgebreide creatieve bijdrage en vele tassen koffie. • Mijn vriendin voor de vele steun en bemoedigende woorden op de ogenblikken dat ik het niet meer zag zitten. • Mijn klasgenoten om te luisteren naar mijn gesakker en om mij op tijd en stond van mijn computer weg te halen. • Mijn ouders en andere familieleden voor de vele steun, niet alleen tijdens mijn thesis maar tijdens de gehele studie.
Dank u!
Jeroen Dhollander, april 2008
Design of a dynamic supply chain simulation Jeroen Dhollander Supervisor(s): prof. dr. ir. Hendrik Van Landeghem Abstract— This article shows the different technics used to create a dynamic and flexible supply chain simulation. Keywords—Supply Chain Management, Dynamic software framework
Administrator Upper class 1
I. I NTRODUCTION Supply chain management is not an easy subject to master. It requires a thorough understanding of the inner workings of the market, the suppliers, and many more aspects. That’s why a simulation is required to be used for the practicums of the course ‘supply chain management’ (taught at the university of Ghent by prof. dr. ir. H Van Landeghem). This simulation offers the students a chance to compete in a virtual market and in this way experience the effects and aspects of supply chain management first handed. Due to the complexity of supply chain management it is of utmost importance that the administrator is able to change, monitor and finetune as much of the supply chain as possible. This article describes how these requirements are met. In section II we will run by the different technics used to provide the required flexibility. Section III will cover how these technics are used to model the different parts of the supply chain.
User Lower class 1.1
1 The documentation can be found at http://java.sun.com/j2se/1. 5.0/docs/api/
Lower class 1.2
Lower class 2.1
Fig. 1. Illustration by the layered model.
ActorType
Actor
Fig. 2. The layered model used to model the buildings.
II. T ECHNICS USED TO PROVIDE DYNAMICS Flexibility is acquired by using abstraction, as abstraction allows a greater differentation of in and output. A commonly used way to achieve this abstraction is by using abstract classes and interfaces. These are programming technics where a parent class defines the signature of the methods, but the child classes all provide a different implementation. When you write the user interface against this common parent, you support all the children. However, we want to allow the administrator to perform all necessary changes from within the user interface. As these methods require programming for each change, we need another method. The idea behind the other method was found within a little known package of the Java language, namely the java.util.prefs package1 . This package allows the programmer to create a hierarchic tree, where each node holds a key-value pair. By allowing the administrator to edit the configuration of this tree we can allow him to create different children. However, this technic still holds 2 problems: First of all, these key-value pairs are able to contain any type of value (be it an integer or a string), but they provide no way to deduce the value type at runtime. Secondly, the administrator can define different children, but there is no way for the user to actually create multiple instances of each of these children.
Upper class 2
The first problem is addressed by not using a key-value pair but rather a key-type-value tuplet. This allows the program to iterate an unknown tree and take appropriate actions for each node, depending on the node type. The second problem is solved by using a layered model. In this model, the administrator defines the configuration of an ‘upper class’. The users can create instances of the ‘lower class’, which are linked to a specific upper class. This way, multiple users can have multiple instances of the lower class, all using the same upper class. This concept is illustrated in figure 1. III. F LEXIBILITY IN THE SUPPLY CHAIN SIMULATION The simulation provides this flexibility in 3 parts of the supply chain. Buildings The buildings are modeled by the architecture in figure 2. The administrator defines instances of ActorType by completing the configuration seen in figure 3. Examples are ‘Factory’ and ‘DC’. The user can create buildings (‘Actor’) of each of these types. This architecture uses the layered model in combination with the hierarchical tree described in the previous section. Note that the fields under “Items for sale” are the names of all the existing product types. Creating a new product type will create a new field in this tree. This is also made possible by the dynamic
C ONCLUSION In this document I demonstrated how a highly dynamic supply chain simulation can be obtained by using these two simple abstractions. This architecture is off course not limited to supply chain simulations, and can be used in many situations where a huge flexibility is required from within the user interface.
Fig. 3. The configuration that defines the different actortypes.
ProductType
ProductModel
OptionsPackage
Product
Fig. 4. The architecture of the products.
nature of this tree. Products The architecture of the products is slightly more complex (figure 4). Each producttype contains two trees, called ‘ProductModel’ and ‘OptionsPackage’. By adding and removing fields of these trees the administrator can create completely different producttypes, as illustrated in figure 5. Mapping the supply chain Finally the administrator has to finish the supply chain by creating trade routes, telling which actor types can buy from who. This can simply be achieved by using a list of buyer-seller pairs.
Fig. 5. Example of 2 different producttypes.
INHOUDSOPGAVE
i
Inhoudsopgave 1 Situering
1
1.1
Supply chain management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Doel van dit business game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Opbouw van dit document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Requirements & Technische keuzes
4
2.1
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Technische keuzes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3 Architectuur 3.1
6
Kern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.1.1
Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.2
Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.3
ClientGenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.4
WorldMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.5
Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1.6
Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.7
Varia
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.3
Webbrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4 Het concept & de leveringsketen
14
4.1
Het concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
4.2
Mobilhome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
INHOUDSOPGAVE
ii
4.3
Bedrijven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.4
Gebouwen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.4.1
Fabriek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.4.2
DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.4.3
Dealer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.4.4
Optie leverancier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
Productielijnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.5.1
Dedicated productielijn . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.5.2
Mixed productielijn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.5.3
Batch productielijn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.6
Modificatielijnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.7
Beurtovergangen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.5
5 Administrator console
21
5.1
Eerste keer inloggen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.2
Simulaties aanmaken & selecteren
. . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.3
De productsoorten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.3.1
Alle productsoorten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.3.2
Een productsoort aanpassen . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Gebouwtypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5.4.1
Alle gebouwtypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5.4.2
Een gebouwtype aanpassen . . . . . . . . . . . . . . . . . . . . . . . . . .
27
Wereldmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.5.1
Klant generatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.5.2
Wereldmap aanpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.5.3
Klant simulatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Bedrijven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.6.1
Alle bedrijven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.6.2
E´en enkel bedrijf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
Beurtovergangen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.7.1
40
5.4
5.5
5.6
5.7
Manuele beurtovergangen . . . . . . . . . . . . . . . . . . . . . . . . . . .
INHOUDSOPGAVE 5.7.2 5.8
iii
Automatische beurtovergangen . . . . . . . . . . . . . . . . . . . . . . . .
40
Supply Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6 Gebruikersinterface
44
6.1
Productmodellen & optiepakketten . . . . . . . . . . . . . . . . . . . . . . . . . .
44
6.2
Leveringsketen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
6.2.1
Leveringsketen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
6.2.2
Gebouwtypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
6.2.3
Productiekosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.3
Wereldmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.4
Gebouwen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.4.1
Lijst van alle gebouwen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.4.2
Individueel gebouw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
6.4.3
Productie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
6.4.4
Plaatsen van optiepakketten . . . . . . . . . . . . . . . . . . . . . . . . . .
54
6.4.5
De stock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
6.4.6
De leveranciers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.4.7
De prijzenstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.4.8
De log van een gebouw . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.5
De globale log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
6.6
Statistieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
6.6.1
Marktvraag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
6.6.2
Stock statistieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
Financi¨en . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.7.1
Een enkele beurt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.7.2
Alle beurten
59
6.7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Testen
67
7.1
Unit testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
7.2
Individuele testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
7.3
Tryout gehele game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
INHOUDSOPGAVE
iv
A Installatie & configuratie A.1 Benodigde downloads
69 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
A.2 Configuratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
A.3 Gebruik van jspf files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
Bibliografie
81
SITUERING
1
Hoofdstuk 1
Situering 1.1
Supply chain management
Voor een gewone consument is het hedendaags zeer gemakkelijk om een product te kopen. Hij moet meestal gewoon naar de winkel stappen, het product selecteren en betalen. Al deze producten in de juiste hoeveelheid op het juiste moment in de juiste winkels krijgen, is niet zo’n triviaal probleem. Eerst moeten de grondstoffen ontgonnen worden. Deze grondstoffen worden dan getransporteerd en omgevormd naar tussentijdse producten die dan, weeral op een andere locatie, omgevormd kunnen worden tot eindproducten, of tot andere tussentijdse producten. Deze eindproducten worden dan naar de winkels getransporteerd waar de klant ze dan kan kopen. Het probleem wordt nog complexer als je rekening wilt houden met de veranderende marktvraag; De klant wilt morgen namelijk niet hetzelfde kopen als vandaag, er zijn modetrends, nieuwe ontwikkelingen of zelfs gewoon de drang naar “iets nieuws”. Dit probleem kent vele aspecten.
E´en eerste aspect is het beheer van de voorraden. Een te kleine voorraad kan tekorten opleveren (stockbreuk genaamd) en zo resulteren in langere leveringstijden, een te grote voorraad verbruikt onnodig veel plaats en kost dus geld. Het vinden van de juiste balans is hier onontbeerlijk. Een ander aspect is de variatie in het aanbod. Men kan kiezen voor ´e´en populair basismodel, of men kan het aanbod uitbreiden om een grotere doelgroep te bereiken. Er moet dan wel over
1.2 Doel van dit business game
2
gewaakt worden dat het uitbreiden van het gamma de prijs van het basismodel niet (teveel) verhoogt. Bovendien levert dit ook het risico op “onverkoopbare stock”. Ook de opslag van eindproducten is belangrijk. Soms is het beter om in de winkel zelf maar een kleine stock te hebben, en deze voortdurend bij te vullen. Dit vereist dan meestal de aanwezigheid van een groothandelaar, die bij de fabriek bestelt en aan de winkels verkoopt. Slechte communicatie kan tot lange wachttijden leiden. Voor het transport wordt meestal beroep gedaa op een extern bedrijf. Tenslotte is het ook belangrijk dat er geluisterd wordt naar de vraag van de klant. Echter, dit kan ook tot problemen leiden. De winkels staan het dichtst bij de klant, en zullen dus hun producten bestellen op basis van de vraag van de klanten. De fabrieken zullen dan, onder impuls van de bestellingen van de winkels, hun productieproces en voorraad aanpassen. De leveranciers van de fabriek zullen op hun beurt hun voorraad afstellen op de vraag van de fabriek enzovoortr. Kleine schommelingen aan het begin van de keten kunnen aldus leiden tot grote schommelingen op het einde van de keten. Dit wordt het ‘bullwhip effect’ genoemd. Supply chain management heeft als doe deze aspecten te beheren en zo de leveringsketen optimaal te kunnen aansturen, beheren, onderhouden en optimaliseren[1].
1.2
Doel van dit business game
Het doel van dit business game is om studenten, vooral binnen een economische opleiding, de kans te bieden om aan de levende lijve te ervaren wat het inhoudt om een, welliswaar vereenvoudigde, volledige leveringsketen op te zetten en te onderhouden. Dit geeft hen dan de mogelijkheid om de geleerde technieken toe te passen en de resultaten hiervan waar te nemen. Gezien de beperkte tijd binnen een opleiding mag de game niet te complex zijn. In dit game leren de studenten samenwerken in groepsverband. Elk bedrijf wordt namelijk geleid door een groep van studenten. Ze dienen gezamenlijk te beslissen welke richting het bedrijf uitgaat. Dit verplicht hen om te discussi¨eren en zo dieper in te gaan op de geziene theorie. Dit helpt hen dan bij het begrijpen en verwerken van de leerstof. Door de complexiteit van een leveringsketen levert dit enorm veel informatie en resultaten
1.3 Opbouw van dit document
3
op. Het spel biedt deze aan in ordentelijke tabellen en excell-documenten. Toch zal het een inspanning vereisen van de studenten om al deze informatie te bekijken en verwerken. Dankzij de inzichten die ze hierdoor kunnen verwerven, zullen ze in staat zijn om hun strategie nog wat bij te schaven of, indien nodig, volledig te veranderen. Ook dit is een belangrijke vaardigheid dat ze moeten leren ´en door dit spel kunnen oefenen. Dit business game geeft de studenten dezelfde verantwoordelijkheden als de bedrijfswereld. Communicatie en analyse van de beschikbare (onvolledige) informatie zal hen in staat stellen om deze verantwoordelijkheden tot een goed einde te brengen.
1.3
Opbouw van dit document
Na deze inleiding zullen we ons in hoofdstuk 2 richten op de gestelde eisen en de gemaakte technische keuzes. Daarna zullen we in hoofdstuk 3 de gekozen softwarearchitectuur van dit game overlopen. Hoofdstuk 4 beschrijft het doel van het spel en zal dieper ingaan op de aanwezige leveringsketen, gebouwtypes en producten. Dit hoofdstuk is zo geschreven dat het in combinatie met hoofdstuk 6 gebruikt kan worden als een handleiding voor de studenten. Gecombineerd met hoofdstuk 5 is dit de handleiding voor de beheerder van het spel. Vervolgens zullen we in hoofdstuk 7 de uitgevoerde testen overlopen. De installatieinstructies voor dit game kunnen tenslotte gevonden worden in de appendices.
REQUIREMENTS & TECHNISCHE KEUZES
4
Hoofdstuk 2
Requirements & Technische keuzes 2.1
Requirements
Bij het opzetten van een project, dus ook het implementeren van dit business game, zijn er een aantal requirements die gehaald moeten worden. Een requirement is een eigenschap van het resultaat dat gewenst is. Het probleem hierbij is dat verschillende requirements vaak tegenstrijdige eisen stellen. Er zal dus altijd een afweging moeten gebeuren wat ´echt belangrijk is. In dit geval waren de belangrijkste requirements dynamiek, gebruiksvriendelijkheid en onderhoudbaarheid. Deze gaan we dieper toelichten. De vereiste dynamiek situeert zich vooral aan de kant van de administrator console. Hier wordt verwacht dat het mogelijk is om het spel zo diepgaand mogelijk te beheren, configureren en veranderen zonder dat enige codering vereist is. In de uiteindelijke implementatie is het mogelijk om nieuwe producten te introduceren, nieuwe gebouwtypes aan te maken ´en de interactie tussen deze gebouwtypes onderling en tussen de gebouwen en de markt te bepalen. Je kan dus wel stellen dat dit zeer dynamisch is. Merk op dat deze dynamiek niet opgelegd kan worden in de interface alleen, maar vanuit de kern van de implementatie ondersteund moet worden. Gebruiksvriendelijkheid is belangrijk voor zowel de administrator als de studenten. Dit wordt bereikt door een duidelijke, simpele maar toch intu¨ıtieve interface te gebruiken. Bovendien worden er meerdere ‘samenvattende’ pagina’s voorzien waarop de studenten in ´e´en oogopslag kunnen zien wat er allemaal gaande is.
2.2 Technische keuzes
5
Onderhoudbaarheid tenslotte is belangrijker voor de programmeur. Dit kan bekomen worden door in de implementatie duidelijk afgelijnde modules te gebruiken met een duidelijke taak. Ook het duidelijk documenteren van de code is hiervoor belangrijk. Naast deze hoofdrequirements is er ook gelet op de veiligheid. Daarover volgt meer in sectie 3.2.
2.2
Technische keuzes
Er was gevraagd om de implementatie in Java te doen. Er is dus gekozen voor Java EE 5, aangezien deze de benodigde server- en persistentie-technologie¨en bezit. Voor de persistentie is gekozen voor de EJB3 technologie [3] omdat deze op een natuurlijke en elegante manier ge¨ıntegreerd is in Java ´en het afhandelen van de persistentie daardoor ook zeer intu¨ıtief en vlot gaat. Aangezien dit een relatief nieuwe technologie is, zijn er maar twee servers die deze technologie ondersteunen, namelijk GlassFish en JBoss. De implementatie van JBoss is echter nog in een experimentele fase [4], dus is er gekozen voor de GlassFish webserver [5]. De authenticatie van de server wordt, zoals hierboven reeds vermeld, volledig automatisch afgehandeld door de server. In appendix A wordt uitgelegd hoe de server geconfigureerd moet worden om dit te ondersteunen. Bij het kiezen van de browsertechnologie was er keuze tussen het gebruik van een Java Applet enerzijds en de combinatie van HTML en JavaScript anderzijds. Aangezien de voordelen van applets (geen browser problemen, gemakkelijke integratie in het gehele systeem) vooral voor de programmeur zijn maar de nadelen (traag, log, onnatuurlijk in gebruik, laag gebruiksgemak) vooral voor rekening van de eindgebruiker zijn, is er gekozen om dit niet te gebruiken. Het combineren van HTML en JavaScript levert een gebruikservaring op zoals de eindgebruiker deze verwacht van een webbrowser. Om de verschillen tussen de browsers te overkomen is er gebruik gemaakt van het Prototype framework [6]. Een uitstekend referentiewerk hierover is het boek van C. Porteneuve [7].
ARCHITECTUUR
6
Hoofdstuk 3
Architectuur Het gehele systeem kan opgedeeld worden in drie delen (zie figuur 3.1). Eerst heb je de webbrowser die verantwoordelijk is voor de visualisatie en het doorsturen van de input. De server zal deze input opvangen en valideren. Indien deze input geldig is ´en de gebruiker geldig geauthenticeerd is wordt het verzoek doorgestuurd naar de kern. Deze zal tenslotte de input verwerken en de persistente opslag verzekeren. Merk op dat de server een “guard”-functie heeft: hij moet verzekeren dat de gevraagde actie geldig en toegelaten is. Noch de webbrowser noch de kern moeten zich druk maken over de beveiliging.
3.1
Kern
De kern bevat alle logica, en bepaalt dus alles wat wel/niet kan gebeuren. Daarom is het belangrijk dat deze kern een zeer flexibele, modulaire en weldoordachte architectuur heeft. Deze architectuur kan je zien in figuur 3.2. In de volgende subsecties gaan we dieper in op elk van de
Browser (firefox,...) Visualisatie Input
Server Authenticatie Validatie
Student
Figuur 3.1: Globale structuur met belangrijkste functies
Kern Verwerking Persistentie
3.1 Kern
7
onderdelen van de architectuur. De persistentie wordt afgehandeld door gebruik te maken van EJB’s. Zie hoofdstuk 2 voor meer uitleg over de persistentie.
3.1.1
Simulator
Elke instantie van deze klasse stelt een simulatie voor. Het game is zo geschreven dat het perfect mogelijk is dat meerdere simulaties simultaan op dezelfde server lopen. Deze simulaties zullen geen invloed op elkaar hebben. Deze klasse kan gezien worden als het aanspreekpunt van de simulatie, en bevat dus referenties naar alle componenten. Naast de componenten die gezien kunnen worden in figuur 3.2 bevat de simulatie nog enkele kleinere componenten zoals het “supply chain model” en de “TurnManager”. Deze worden verder uitgelegd in de varia sectie verderop.
3.1.2
Company
De studenten werken samen in groepen. Elk van deze groepen zal een bedrijf beheren. Deze klasse stelt deze bedrijven voor. Naast de componenten te zien in figuur 3.2 bevat deze klasse ook een prijslijst waarin de studenten globale verkoopsprijzen kunnen ingeven.
3.1.3
ClientGenerator
Deze klasse is verantwoordelijk voor het genereren van klanten tijdens de beurtovergang. Verder zal deze klasse ook de instellingen bijhouden die het gedrag van deze klanten sturen, zoals hun aantal, hoeveel dealers ze bezoeken, hun budget en wat ze willen kopen.
3.1.4
WorldMap
Deze klasse stelt de wereldmap voor waarop het gehele spel zich afspeelt. Deze wereldmap is een rechthoekig gebied waarvan de grootte in te stellen is door de administrator. Verder kunnen er rechthoekige gebieden met een hogere bevolkingsdichtheid geplaatst worden op deze wereldmap. Deze gebieden stellen dan bijvoorbeeld steden voor, en worden inwendig voorgesteld als instanties van de klasse MapArea.
3.1 Kern
8
Simulator *
1 WorldMap
1
* ProductType
1
1
*
* Company 1
1
1
ClientGenerator
* ActorType
1
*
*
1 MapArea
OptionsPackage
Actor 1
* Stock
*
*
1
ProductModel 1
* Production
* Modification
Figuur 3.2: Simpel UML diagram van de kernstructuur
3.1.5
Product
Voor het voorstellen van de producten en hun productsoorten wordt een gelaagd model gebruikt. Dit model wordt weergegeven in figuur 3.3, waar iedere pijl van A naar B kan gelezen worden als ‘Iedere A heeft een B’. Op het hoogste niveau bepaalt de administrator welke productsoorten (“ProductType”) er gebruikt kunnen worden. Deze klasse is volledig generiek. Dit betekent dat het mogelijk is om, via de gebruikersinterface, een nieuwe productsoort te defini¨eren. Een productsoort wordt oa gedefinieerd door aan te geven welke mogelijke opties en varianten er kunnen bestaan. In het hoofdstuk over de administrator console (hoofdstuk 5) gaan we dieper in over alle andere parameters dat ingesteld kunnen worden. Indien meerdere simulaties dezelfde productsoort gebruiken worden kopie¨en gemaakt, dit om ongewenste afhankelijkheden te vermijden.
3.1 Kern
9
ProductType
ProductModel
OptionsPackage
Product
Figuur 3.3: Modelering van de producten.
Een niveau dieper heb je de productmodellen (“ProductModel”). Deze worden aangemaakt door de studenten, en zijn invullingen van een deel van de opties en varianten gedefinieerd bij de productsoorten. De studenten zullen deze productmodellen ook een naam kunnen geven, en deze naam zal overal doorheen de gebruikersinterface gebruikt worden. Dit voorkomt dat de studenten overal bij elke stap steeds alle opties en varianten zullen moeten ingeven. Op hetzelfde niveau van de productmodellen heb je ook de opties (“OptionsPackage”). Dit is een invulling van alle andere opties en varianten. Het bepalen van welke opties en varianten bij de productmodellen horen, en welke bij de opties is de taak van de administrator, en zal gebeuren bij het defini¨eren van een productsoort. Het onderscheid tussen productmodellen en optie pakketten zit hem in het gebruik hiervan. De productmodellen zijn de opties en varianten die vaststaan bij de productie van het product. Bijvoorbeeld, bij een mobilhome zal er op het moment van productie gekozen worden hoeveel bedden en extra zetels er aanwezig zijn. Dit is achteraf niet meer aanpasbaar. De opties daarentegen kunnen later geplaatst worden op een bestaand product, bijvoorbeeld een airco of een fietsenrek. Tenslotte is er de product klasse (“Product”). Elke instantie van deze klasse stelt een bestaand product voor. Deze klasse heeft dus een productmodel en productopties.
3.1 Kern
10
ActorType
Actor 1 * Stock
1 * Production
1 * Modification
Figuur 3.4: Modelering van de actoren.
3.1.6
Actor
Ook voor de actoren (‘gebouwen’) wordt een gelaagd model gebruikt, zei het nu met een totaal andere opbouw (figuur 3.4). Op het hoogste niveau bepaalt de administrator welke gebouwtypes (“ActorType”) er meespelen in deze simulatie. Hij kan zo bijvoorbeeld kiezen om geen DC te gebruiken, of om een nieuw gebouwtype te introduceren. Deze keuzes kunnen natuurlijk gemaakt worden via de webgebaseerde interface. Bij het defini¨eren van een nieuw gebouwtype moet er oa gekozen worden of het gebouw kan produceren dan wel opties plaatsen. Verder zal er gezegd worden wat het gebouw mag verkopen en hoe groot de stock is. Meer informatie hieromtrent is te vinden in het hoofdstuk over de administrator console (hoofdstuk 5). Net zoals bij de productsoorten zullen er hier ook kopie¨en gemaakt worden als meerdere simulaties dezelfde gebouwtypes gebruiken. Op het volgende niveau heb je de individuele gebouwen (“Actor”) die de studenten gezet hebben. Elk van deze gebouwen heeft logischerwijs een geassocieerd gebouwtype, wat bepaalt wat dit gebouw kan en mag produceren, verkopen, enzovoort. Omdat een gebouw veel verantwoordelijkheden heeft, zijn er drie hulpklassen die elk een deel van deze verantwoordelijkheden op zich nemen. Dit laat toe om de code mooi gescheiden en dus ook onderhoudbaar te houden. Deze hulpklassen zijn de klassen Stock, Production en Modification die respectievelijk verantwoordelijk zijn voor alles in verband met de stock (en bestellingen), de productie en het plaatsen van de opties. Hoe dit juist in zijn werk gaat, wordt uitgelegd in hoofdstuk 5. Een verantwoordelijkheid die wel nog bij de klasse Actor hoort is het bijhouden
3.2 Server
11
van verkoopprijzen, zowel procentueel als absoluut. In sectie 6.12 wordt uitgelegd hoe de prijzen vastgelegd kunnen worden.
3.1.7
Varia
Tenslotte zijn er nog een aantal kleinere hulpklassen die ook hun nut hebben. Het Supply Chain Model bijvoorbeeld, houdt per simulatie bij welke gebouwtypes met welke gebouwtypes handel mogen drijven via welke transportroutes. Dit laat toe om, in combinatie met de instellingen in de ClientGenerator, de volledige leveringsketen vast te leggen.
3.2
Server
De server is verantwoordelijk voor de authenticatie, de validatie van de input en het aanspreken van de kern. Iedere interactie met de kern gebeurt dus eerst via de server. Daarom is het genoeg om de server te beveiligen en niet de kern. Het beveiligen van de webbrowser zou niet genoeg zijn, omdat het zeer simpel is om deze te omzeilen en rechtstreeks met de server te communiceren. Iedere validatie dat in de webbrowser gebeurt, is dus enkel en alleen om de student directe feedback te kunnen geven, en moet overgedaan worden in de server. Figuur 3.5 toont de verschillende stappen die doorlopen worden bij iedere pagina aanvraag. Eerst zal gekeken worden of de gebruiker ingelogd is ´en toestemming heeft om de betreffende pagina op te vragen. Deze controle gebeurt niet door het programma maar door de GlassFish server. Dit verkleint de kans op beveiligingsfouten. Appendix A legt uit hoe de server geconfigureerd kan worden om automatische authenticatie te doen, en hoe deze permissies aangepast kunnen worden. Indien de gebruiker geen toestemming heeft om de pagina op te vragen, wordt hij naar het inlogscherm doorgestuurd. Indien de gebruiker wel toestemming heeft om een pagina op te vragen, wordt er eerst gekeken of er acties uitgevoerd moeten worden. Dit gebeurt door een paginaspecifieke servlet. Indien er acties moeten gebeuren (bv het zetten van een nieuw gebouw) zal dit servlet de input controleren en, indien deze geldig is, de acties doorsturen naar de kern. Zodra deze acties afgerond zijn wordt de verzoek doorgestuurd naar een algemeen template. Dit template is verantwoordelijk voor de algemene opbouw van de webpagina, zoals de kleuren,
3.2 Server
12
Aanvraag webpagina
Toegangscontrole Ingelogd & toegestaan? JA
NEE Toon inlog scherm
Servlet Controle van input Verwerken van input Verzoek doorsturen Template Algemene pagina layout
1 2
Includeer pagina specifieke deel
3 Terugsturen pagina
Figuur 3.5: Werking van de server.
de css, het menu,. . . . Dit template zal ook een pagina specifiek jsp-fragement oproepen en toevoegen. Dit pagina specifieke fragment is verantwoordelijk voor het centrale gedeelte van de webpagina, dat anders is op elke pagina. Tenslotte zal dit template het resultaat terugsturen naar de gebruiker. Door dit systeem consistent te gebruiken zorgen we ervoor dat de interface gemakkelijk aanpasbaar is aangezien deze interface slechts op een plaats gedefinieerd wordt, namelijk in de template pagina. Als deze pagina aangepast wordt, verandert de interface op elke pagina. Dit systeem verzekert met andere woorden dat alle pagina’s consistent zijn. Er zijn twee verschillende template pagina’s, namelijk ´e´en voor de administrator console en ´e´en voor het studenten gedeelte.
3.3 Webbrowser
3.3
13
Webbrowser
Dit is de enigste component waar we geen controle over hebben. Iedere student is immers vrij te kiezen welke webbrowser hij gebruikt. Omdat we gebruik maken van het prototype framework [6] levert dit weinig problemen op. Het spel is getest op Firefox, Safari ´en Internet Explorer. Alhoewel het spel overal werkt , wordt toch Firefox aangeraden om een optimale spelervaring te hebben.
HET CONCEPT & DE LEVERINGSKETEN
14
Hoofdstuk 4
Het concept & de leveringsketen 4.1
Het concept
Het spel draait rond mobilhomes. Elke beurt gaan er klanten op zoek naar de mobilhome van hun dromen. Hiervoor bezoeken ze de dealers, die geleid worden door de studenten. Dankzij deze klantbezoeken krijgen de dealers een steeds beter beeld van wat de klant wilt. Dit beeld kunnen de studenten dan gebruiken om hun productie en stock bij te schaven. De student is dus verantwoordelijk voor de leveringsketen vanaf de fabriek tot de dealer. De leveranciers van de opties worden beheerd door de administrator. De gehele leveringsketen is weergegeven in figuur 4.1.
Airco Leverancier Airbag Leverancier
. . .
Mobilhome Fabriek
DC
GPS Leverancier
Figuur 4.1: De supply chain van dit spel
Dealer
4.2 Mobilhome
4.2
15
Mobilhome
Het eindproduct in dit spel is een mobilhome. Een mobilhome is een motorvoertuig uitgerust om in te wonen. Er bestaan vele modellen van een mobilhome; Deze verschillen van elkaar in hun afwerking en hun opties. Elke klant zal een zeer duidelijk beeld hebben van welke mobilhome hij wilt. De punten waarop de mobilhomes van elkaar kunnen verschillen zijn: • Comfortniveau: Het afwerkingsniveau van de gehele mobilhome. Er zijn drie niveau’s: Basis, normaal en hoog. • Aantal slaapplaatsen: Dit kan vari¨eren van twee tot zes. • Aantal extra zitplaatsen: Een mobilhome heeft standaard evenveel zitplaatsen als slaapplaatsen. De klant kan tot twee extra zitplaatsen vragen. • Kleur: De mobilhome kan geleverd worden in wit, zwart, blauw of grijs. • Airbag: of men al dan niet een airbag wenst. • Airco: of men al dan niet een airco wenst. • Automatic: of men al dan niet een automatic wenst. • Cruise Control: of men al dan niet cruise control wenst. • Fietsrek: of men al dan niet een fietsenrek wenst. • GPS: of men al dan niet een GPS wenst. De eerste drie instellingen maken deel uit van het model. Dit zijn de instellingen die gekozen worden bij de productie van een mobilhome. De andere instellingen (alles vanaf ‘kleur’) kunnen later door de DC aangepast worden. Deze worden de opties genoemd.
4.3
Bedrijven
Een student staat er niet alleen voor, maar zal samen met een aantal medestudenten een bedrijf vormen. Het is de bedoeling dat de studenten overleggen en gezamenlijk de bedrijfsstrategie ontwikkelen.
4.4 Gebouwen
4.4 4.4.1
16
Gebouwen Fabriek
De fabriek is het gebouw waar mobilhomes geproduceerd worden. Bij de productie wordt het model vastgelegd. Dit bepaald het comfortniveau, het aantal slaapplaatsen en het aantal extra zitplaatsen. De opties en de kleur zullen later door de DC geplaatst worden. Deze productie gebeurt aan de hand van productielijnen. Er zijn drie soorten productielijnen die geplaatst kunnen worden. Meer hierover in sectie 4.5. Er zijn geen grondstoffen nodig om een mobilhome te produceren, dit om de complexiteit van het spel binnen de perken te houden. Tenslotte zal de fabriek ook de opties inkopen bij de leveranciers, en deze verdelen aan de DC’s.
4.4.2
DC
De DC zal de opties plaatsen op de mobilhomes. De mogelijke opties zijn de kleur, airco, airbag, automatic, cruise control, fietsenrek en GPS. Het plaatsen van elk van deze opties (behalve de kleur) vereist de aankoop van deze optie. De opties worden verkocht door de optie leveranciers aan de fabriek. De DC zal deze opties dus geleverd krijgen vanuit zijn fabriek. Verder dient de DC als opslagplaats voor de mobilhomes. De dealers zullen hun mobilhomes hier aankopen.
4.4.3
Dealer
De dealer zal de mobilhomes proberen te verkopen aan de klanten. Hoe groter de stock en hoe meer zijn aanbod afgestemd is op de marktvraag, hoe meer hij er zal verkopen. Bovendien is ook zijn ligging belangrijk, aangezien de klant niet graag ver rijdt om een mobilhome te kopen. Er zijn drie soorten dealers, namelijk kleine, normale en grote. Het verschil tussen deze zit hem in het aantal mobilhomes dat ze in stock kunnen hebben. Natuurlijk zijn de grotere dealers ook duurder in bouw- en onderhoudskosten.
4.5 Productielijnen
4.4.4
17
Optie leverancier
Elk van deze gebouwen zal ´e´en soort opties kunnen produceren en verkopen aan de fabrieken. Deze gebouwen worden beheerd door de administrator. Bovendien kan de administrator de verkoopsstrategie van deze gebouwen aanpassen. Hiervoor heeft hij de keuze tussen First Come First Serve of Equal Share. Bij First Come First Serve zullen de oudste bestellingen het eerst afgehandeld worden, terwijl bij Equal Share de opties zo eerlijk mogelijk verdeeld zullen worden tussen de verschillende gegadigden. De verschillende bedrijven zijn dus steeds in competitie voor de aankoop van de opties.
4.5
Productielijnen
Een basismodel wordt geproduceerd door productielijnen. Het model bepaalt het comfortniveau, het aantal slaapplaatsen en het aantal extra zitplaatsen. Dit levert een totaal van 45 verschillende modellen. De student zal dus duidelijke keuzes moeten maken welke van deze mogelijke modellen hij zal produceren.
4.5.1
Dedicated productielijn
Elke dedicated productielijn zal slechts ´e´en model kunnen produceren. Dit is dus een zeer beperkte lijn. Daarentegen staat wel dat deze lijnen goedkoop en snel zijn en een hoge capaciteit hebben. Deze lijn is dus ideaal om het populairste model te produceren.
4.5.2
Mixed productielijn
Deze productielijnen kunnen elk model produceren. Dit is een duidelijk voordeel van deze productielijn. Echter, aangezien de modellen sterk van elkaar verschillen, vereist dit een zeer gesofisticeerde machinerie en lange steltijden. Deze lijn zal dus een lage capaciteit en hoge kostprijs hebben. Bovendien zal de machinerie zeer generiek zijn en zal de productie dus vele beurten duren.
4.6 Modificatielijnen
4.5.3
18
Batch productielijn
Deze lijn biedt een mooie tussenweg tussen de mixed en dedicated productielijnen. Net zoals de mixed productielijn kan de batch productielijn elk model produceren. Om de stelkosten en steltijden te drukken zal men echter wachten tot men X orders voor hetzelfde model heeft. Deze X orders zullen dan na elkaar afgewerkt worden. Een voorbeeld van de wachtrij van een productielijn van dit type (met batchgrootte = 3): AAAEEECCCGGG . . .
4.6
Modificatielijnen
Het plaatsen van de verschillende opties op de modellen gebeurt door de DC’s. De mogelijke opties zijn kleur, airco, airbag, automatic, cruise control, fietsenrek en GPS. Dit levert een totaal op van 256 verschillende optiepakketten. Elke optie kan geplaatst worden op elk model, wat betekent dat er 11520 verschillende mobilhomes mogelijk zijn. Het plaatsen van de opties gebeurt door de modificatielijnen. Er zijn, naar analogie van de productielijnen, 3 verschillende soorten modificatielijnen. Deze worden verderop in deze sectie uitgelegd. Het plaatsen van een optie gebeurt direct. Dit betekent echter niet dat het plaatsen van opties op een mobilhome altijd in eenzelfde beurt klaar is. Bijvoorbeeld, stel u voor dat een mobilhome zwart gespoten moet worden ´en een airco moet krijgen. Het is dan mogelijk (bijvoorbeeld als er geen airco’s in stock zijn) dat in de ene beurt de mobilhome zwart gespoten wordt en pas in de volgende beurt de airco geplaatst wordt. Deze mobilhome verdwijnt uit stock zodra hij zwart gespoten wordt, maar zal pas terug in stock verschijnen als de airco geplaatst is. Dit om te voorkomen dat de zwarte mobilhome zonder airco ongewenst verkocht zou worden.
4.7
Beurtovergangen
Deze game is ‘turn based’. Dat betekent dat het spel opgesplitst wordt in vele ronden. Tijdens de rondes krijgt de gebruiker de kans om de huidige situatie te bekijken, analyseren en eventueel acties te plannen. Na deze ronde zal er een ‘beurtovergang’ gebeuren. Tijdens deze beurtovergang zullen de geplande acties van de gebruikers uitgevoerd worden (indien toegestaan, zie verder), de
4.7 Beurtovergangen
19
klanten gegenereerd worden en de productie en modificatie gebeuren. Eens deze beurtovergang afgerond is zal de volgende ronde beginnen waarin de gebruiker weerom de kans krijgt om de (nieuwe) situatie te bekijken, te analyseren en bij te sturen. Dit systeem zal zich blijven herhalen tot het spel afgelopen is. Bij elke beurtovergang kan de administrator kiezen welke acties de studenten wel dan niet mogen uitvoeren. De acties waarover dit gaat zijn het bouwen van gebouwen, het bouwen van productie- en modificatielijnen en het plaatsen van stock-, modificatie- en productieorders. De administrator kan bijvoorbeeld beslissen om 10 beurten uit te voeren waarin de studenten alleen het resultaat van hun acties zien. Dit zorgt dan dat ze niet voortdurend bij kunnen sturen, maar verplicht worden om hun acties voorop te plannen. Een beurtovergang doorloopt de volgende stappen: 1. Bouw nieuwe gebouwen (indien toegestaan). 2. Bouw nieuwe productie- en modificatielijnen (indien toegestaan). 3. Genereer klanten en laat ze hun aankopen doen. 4. Plaats nieuwe productie-, modificatie- en stockorders en verwijder oude (indien toegestaan). 5. Betaal onderhoudskosten voor alle gebouwen en modificatie- en productielijnen. 6. Overloop alle stockorders en plaats de bestellingen indien nodig. 7. Overloop alle bestellingen die binnengekomen zijn en lever alle producten die in stock zijn. Indien een bestelling niet afgehandeld kan worden, blijft deze gewoon wachten tot de volgende beurtovergang. 8. Handel de productie af. Dit houdt in dat eerst de productieorders overlopen worden. Deze zullen dan nieuwe productiebestellingen plaatsen. Vervolgens zullen alle productielijnen (eerst de dedicated lijnen, dan batch en mixed) de productiebestellingen overlopen en zoveel mogelijk afhandelen. De productiebestellingen die niet afgehandeld kunnen worden blijven gewoon wachten tot de volgende beurtovergang.
4.7 Beurtovergangen
20
9. Handel het plaatsen van opties af. Dit houdt in dat eerst de modificatieorders overlopen worden. Deze zullen dan nieuwe modificatiebestellingen plaatsen. Vervolgens zullen alle modificatielijnen (eerst de dedicated lijnen, dan batch en mixed) de modificatiebestellingen overlopen en zoveel mogelijk afhandelen. De modificatiebestellingen die niet afgehandeld kunnen worden, wachten gewoon tot de volgende beurtovergang. Deze volgorde is natuurlijk niet willekeurig gekozen, maar is gekozen opdat de beurtovergang zo effici¨ent mogelijk verloopt. Eerst worden de gebouwen geplaatst (fase 1). Dit heeft tot gevolg dat een nieuwe verkoper direct marktinformatie kan inwinnen (in fase 3) en dat een nieuwe fabriek direct kan beginnen produceren (in fase 8). Ook zullen de bestellingen aan de leveranciers (fase 6) in de eerste beurtovergang doorgegeven kunnen worden. Het plaatsen van nieuwe productie-, modificatie- en stockorders (en het verwijderen van oude) gebeurt in fase 4. Aangezien dit voor de fase ligt waarin deze orders nodig zijn (namelijk fase 6), kunnen deze orders vanaf de eerste beurt gebruikt worden. Nieuw geleverde goederen (fase 7) kunnen tenslotte ook direct gebruikt worden voor productie (fase 8) en het plaatsen van opties (fase 9). Nieuw geproduceerde producten zullen echter een beurt in de stock moeten blijven voordat ze geleverd kunnen worden. Dit zorgt echter voor een grotere transparantie voor de eindgebruiker, omdat hij zo dit product duidelijker kan volgen (anders zou het geproduceerde product direct doorverkocht kunnen worden en zodoende nooit in de stock komen en zou het kunnen lijken dat deze gewoon ‘verdwijnt’).
ADMINISTRATOR CONSOLE
21
Hoofdstuk 5
Administrator console Deze handleiding zal de creatie van een nieuwe simulatie overlopen. Bovendien zal bij elke stap uitgelegd worden wat de bedoeling is ´en hoe het achterliggende systeem werkt. Na het doorlopen van deze handleiding zou de lezer in staat moeten zijn om zelf een simulatie op te zetten en te beheren.
5.1
Eerste keer inloggen
De eerste keer dat het systeem opgestart wordt, wordt automatisch een administrator account aangemaakt. De gebruikersnaam is admin, het paswoord is l@titude. Geef deze gegevens in op het inlog-scherm en druk op ‘login’.
5.2
Simulaties aanmaken & selecteren
Na het inloggen kom je op de simulators pagina (figuur 5.1). Op deze pagina kan je simulaties aanmaken, selecteren en verwijderen. Om een simulatie aan te maken, geef je in het linkse tekstveld een naam in en druk je op ‘create’. In de screenshot zie je de situatie nadat een simulatie genaamd ‘simulatie’ aangemaakt is. Merk op dat de naam van deze simulatie ook in de dropbox linksboven verschenen is. Deze dropbox kan je vanop elke pagina gebruiken om te kiezen welke simulatie je wilt beheren. Met andere woorden, alle pagina’s tonen de instellingen van de simulatie waarvan de naam linksboven
5.2 Simulaties aanmaken & selecteren
22
Figuur 5.1: De simulators pagina
te zien is. Je kan ook verwisselen van simulatie door op deze pagina in de centrale tabel op deze simulatie te klikken. De simulatie die momenteel geselecteerd is heeft een lichtblauwe achtergrond. Een nieuw aangemaakte simulatie heeft reeds alle standaardinstellingen zoals beschreven in hoofdstuk 4. Deze standaardinstellingen worden geladen uit een xml-file die gevonden kan worden in een map genaamd ‘scm’1 . Deze xml-files worden aangemaakt de eerste keer dat een simulatie aangemaakt wordt. 1
Deze map wordt gemaakt in de ‘current directory’ van het project.
/Applications/NetBeans/glassfish-v2ur1/domains/domain1/config/scm.
Op een Macintosh is deze
5.3 De productsoorten
5.3
De productsoorten
5.3.1
Alle productsoorten
23
De productsoorten kunnen gevonden worden door op het icoontje van een mobilhome (met als ondertekst ‘Products’) te klikken (figuur 5.2). Links zie je een tekstveld waar je een nieuwe productsoort kunt aanmaken. Dit is momenteel wegens tijdsgebrek niet ge¨ımplementeerd in de interface. Centraal zie je een lijst met alle productsoorten die in deze simulatie gebruikt worden. Van elke productsoort zie je: • De naam: Door hierop te klikken navigeer je naar een pagina waarop je de instellingen van deze productsoort kan veranderen. Meer hierover in subsectie 5.3.2. • Consumergood: Indien een product aangeduid is als zijnde een ‘consumergood’ zal het gekocht worden door de gegenereerde klanten. Indien een product geen consumergood is, zal het niet verkocht kunnen worden aan de klanten en zal het dus als een grondstof gebruikt moeten worden bij de productie van andere productsoorten. • Product size: Dit bepaalt hoeveel ruimte een product inneemt in de stock. • Production cost: De basiskost die betaald moet worden bij de productie van een instantie van dit product. Meer hierover volgt in sectie 6.4.7.
5.3.2
Een productsoort aanpassen
Laten we de instellingen van de mobilhome een beetje aanpassen. Hiervoor klik je op het woord ‘mobilhome’ in de centrale lijst. Dit brengt ons naar de productpagina voor mobilhomes (figuur 5.3). Bekijken we eerst het centrale gedeelte. Onder ‘varia’ kan je kiezen hoeveel plaats dit product zal innemen in de stock, en of het product verkocht kan worden aan de gegenereerde klanten of niet. Bij de aanmaak van een product is het mogelijk dat er grondstoffen nodig zijn. Welke grondstoffen nodig zijn wordt als volgt bepaald:
5.3 De productsoorten
24
Figuur 5.2: De productsoorten pagina, met alle initi¨ele productsoorten
• Elk product dat aangevinkt staat op deze pagina onder ‘raw materials’ zal nodig zijn voor de productie van elke instantie van deze productsoort. Bijvoorbeeld, om een cd te maken is een cd-doosje nodig. • Verder wordt gekeken naar de opties die geplaatst kunnen worden voor deze productsoort. Als er een productsoort bestaat met dezelfde naam als een optie die gekozen is voor deze instantie, wordt dit als grondstof vereist. Bijvoorbeeld, bij een mobilhome waarop de optie ‘airco’ geplaatst moet worden, wordt een airco als grondstof vereist. Indien de optie ‘airco’ niet geplaatst wordt, is er natuurlijk geen airco nodig als grondstof. Tenslotte kunnen hier de kosten voor de productie ingesteld worden. De productie heeft altijd een vaste kost die betaald moet worden voor elke instantie van deze productsoort. Deze kan ingesteld worden in het veld ‘basic price’. Verder kan er een kost ingesteld worden voor elke optie. Deze moet alleen betaald worden als de bijhorende optie effectief geplaatst wordt.
5.3 De productsoorten
25
Figuur 5.3: Een deel van de pagina waarop je een productsoort kan aanpassen.
Nadat je hier alle instellingen ingesteld hebt, dien je links op de knop ‘store changes’ te drukken. Indien je dit niet doet gaan alle veranderingen verloren!. Ook kan je door op de knop ‘store as model’ te drukken, zorgen dat deze productsoort met deze instellingen standaard in elke nieuwe simulatie aanwezig zal zijn. Om terug te keren naar de lijst met alle productsoorten kan je op ‘products’ drukken in de kleine rechthoek boven het centrale deel. Indien deze rechthoek aanwezig is, kan deze gebruikt worden als navigatiemenu.
5.4 Gebouwtypes
5.4
26
Gebouwtypes
5.4.1
Alle gebouwtypes
Vervolgens gaan we door naar de pagina van de gebouwtypes. Deze kan je bereiken door op het icoontje van de fabriek te klikken (met ondertitel ‘Buildings’). Deze kan je zien in figuur 5.4 In het linkermenu kan je eerst en vooral een lijst zien met ongebruikte gebouwtypes. In het voorbeeld kan je zien dat een gebouwtype genaamd ‘test’ niet gebruikt wordt. Door op de knop ‘use building’ te drukken zouden we ervoor kunnen zorgen dat dit gebouwtype wel gebruikt wordt in deze simulatie. Verder zie je in het linkermenu een mogelijkheid om een nieuw gebouwtype te defini¨eren. Indien je dit wil, geef je gewoon de gewenste naam in en druk je op ‘create building’. Je zal dan verder gebracht worden naar een pagina waarin je dit gebouwtype kan gebruiken. In het centrale gedeelte zie je een lijst met alle gebouwtypes die in deze simulatie gebruikt mogen worden. Voor elk gebouwtype zie je de volgende velden: • Icon: Het icoontje waarmee gebouwen van dit type op de wereldmap aangeduid worden. • Name: De naam van het gebouwtype. Hierop kan je klikken om naar de pagina te gaan waar je dit gebouwtype kan aanpassen. Meer hierover in subsectie 5.4.2 • Can Produce: Of dit gebouwtype mag produceren en zoja, welke productsoort geproduceerd mag worden. • Can Place options: Of dit gebouwtype opties mag plaatsen op bestaande producten zoja, op welke productsoort. • Can sell: De productsoorten dat instanties van dit gebouwtype te koop zullen aanbieden. • Multiple suppliers allowed: Of een instantie van dit gebouwtype ´e´en dan wel meerdere leveranciers mag hebben. • Priority Algorithm: Hoe de binnengekomen bestellingen afgehandeld worden. Indien dit ‘First Come First Serve’ (FCFS) is zullen de oudste bestellingen voorrang krijgen. Indien dit ‘Equal Share’ is zullen de producten eerlijk verdeeld worden onder iedereen die deze wil kopen.
5.4 Gebouwtypes
27
Figuur 5.4: De gebouwtypes pagina, met alle initi¨ele gebouwtypes
Net zoals bij de productsoorten is er een standaardset van gebouwtypes dat bij een nieuwe simulatie aanwezig is. Initieel zijn dit alle gebouwtypes die je in de screenshot (figuur 5.4) kan zien.
5.4.2
Een gebouwtype aanpassen
Klik op de naam van de DC om door te gaan naar de pagina waarop je een gebouwtype kan aanpassen (figuur 5.5). Kosten & stock Het eerste dat je kan aanpassen zijn de kosten verbonden aan dit gebouw. De ‘build cost’ is de (eenmalige) kost nodig om een instantie van dit gebouw te zetten. De ‘upkeep cost’ is de kost die elke beurt betaald moet worden om dit gebouw te onderhouden. Hier komt ook nog een kost per productielijn of modificatielijn bij. Vervolgens kan je de grootte van de stock kiezen. Een
5.4 Gebouwtypes
28
Figuur 5.5: Een deel van de pagina waarop je een gebouwtype kan aanpassen
stock van 100 betekent dat je 100 producten met grootte 1 kunt bijhouden ofwel 1 product met grootte 100 ofwel 10 producten met grootte 5 samen met 1 met grootte 50, enzovoort. Het veld ‘multiple suppliers allowed’ is zelfverklarend. Indien je het veld voor ‘production allowed’ selecteert, geef je aan dat dit gebouwtype zal kunnen produceren. Er komen dan extra velden bij die je moet invullen (figuur 5.6). Zie sectie 4.5 voor meer uitleg over deze velden. Indien je het veld voor ‘modification allowed’ selecteert, geef je aan dat dit gebouwtype opties zal kunnen plaatsen. Er komen dan extra velden bij die je moet invullen (figuur 5.5). Zie sectie 4.6 voor meer uitleg over deze velden.
5.5 Wereldmap
29
Figuur 5.6: De instellingen die de productie aansturen
Tenslotte moet er nog aangegeven worden welke productsoorten dit gebouwtype kan verkopen en (niet zichtbaar op de screenshot) moet een icoontje gekozen worden. Nieuwe icoontjes kunnen simpelweg toegevoegd worden door ze in de map ‘img/icons’ op de server te plaatsen. In het linkermenu vind je, net zoals bij de productsoorten, opnieuw de knop om de veranderingen op te slaan ´en een knop om deze instellingen bij een volgende simulatie als standaard te gebruiken. Merk bovendien op dat er weerom een klein navigatiemenuutje bovenaan verschenen is dat u toelaat om terug te keren naar de pagina met alle gebouwtypes.
5.5 5.5.1
Wereldmap Klant generatie
Klik nu op het icoontje van een wereldbol. De pagina die je nu ziet (figuren 5.7, 5.8 en 5.9) laat toe om te bepalen hoeveel klanten er elke beurt gegenereerd worden, wie ze zullen bezoeken en wat ze willen kopen.
5.5 Wereldmap
30
Figuur 5.7: Een deel van de pagina waarop je de marktvraag aanpast (1/3)
Het eerste dat je ziet in het centrale deel is het selecteren van een wereldmap. Hierover meer in sectie 5.10.
5.5 Wereldmap
31
Figuur 5.8: Een deel van de pagina waarop je de marktvraag aanpast (2/3)
Generated clients Onder ‘generated clients’ kan je kiezen hoeveel klanten er elke beurt gesimuleerd zullen worden. Deze gesimuleerde klanten zullen dan de verkopers bezoeken. Dit aantal wordt willekeurig gekozen volgens een gaussiaanse verdeling, waarvan je het gemiddelde en de standaardafwijking kan ingeven. Dealers selection Hier kan je instellen welke dealers de klanten zullen bezoeken. Om dit te bepalen wordt het volgende algoritme toegepast bij elke klant: 1. Elke verkoper krijgt een score. Deze score is afhankelijk van de afstand tussen de klant
5.5 Wereldmap
32
Figuur 5.9: Een deel van de pagina waarop je de marktvraag aanpast (3/3)
en de verkoper en van de stockgrootte van deze verkoper. Verder spelen er nog een aantal
5.5 Wereldmap
33
klant-specifieke parameters mee. De gebruikte formule is:
stockgrootte afstandsfactor afstand afstandsdeler
2. Sorteer deze verkopers op score, waarbij de hoogste score eerst staat. 3. Selecteer de beste verkopers totdat je aan het minimale aantal verkopers zit. 4. Kijk naar de volgende verkoper; indien zijn score boven de PLOW zit wordt deze verkoper ook geselecteerd. 5. Herhaal de vorige stap totdat je aan het maximale aantal verkopers zit, of totdat de score te laag wordt. De klant zal dan elk van de geselecteerde verkopers bezoeken. Aan elk product van deze bezochte verkopers wordt een waarde toegekend. De formule die gebruikt wordt om deze waarde te berekenen wordt in sectie 5.5.1 verder toegelicht. De klant zal dan de voorkeur geven aan het product met de hoogste score. Als deze score hoog genoeg is wordt het product gekocht. Zoniet verlaat de klant de markt zonder aankoop uit te voeren. Verder wordt in dit gedeelte ook ingegeven welke gebouwtypes producten mogen verkopen aan de klanten. Product Demand In dit gedeelte (figuur 5.8) geef je in wat de klanten willen kopen. Zowel voor de varianten als de opties moet je ingeven hoeveel procent van de klanten dit wilt. Bij de varianten wordt er automatisch voor gezorgd dat de som steeds 100 vormt. Product matching Dit gedeelte (figuur 5.9) bevat alle parameters nodig om de producten een score te geven. Deze score wordt dan gebruikt om te bepalen of een klant een bepaald product zal aankopen of niet. De berekening gaat als volgt: 1. Eerst wordt voor de klant een persoonlijk budget en minimale score berekend.
5.5 Wereldmap
34
2. Dan wordt er gekeken naar de kostprijs. Dit levert een aantal plus- of minpunten op. Deze plus- of minpunten worden als initi¨ele score beschouwd. 3. Daarna wordt elke instelling van het product bekeken. Deze instellingen kunnen in drie types ingedeeld worden: (a) Een ‘range’ is een situatie waarin de klant een hoeveelheid moet kiezen. Een voorbeeld is het aantal bedden. Hier wordt een score gegeven voor een ‘match’, een bonus voor elk teveel of een penalty voor elk tekort. (b) Een ‘variant’ is een situatie waarin de klant kiest uit een beperkt aantal opties, bijvoorbeeld de kleur. Indien dit overeenkomt geeft dit pluspunten, zoniet kost dit punten. (c) Een ‘optie’ tenslotte is iets dat wel of niet aanwezig kan zijn, zoals een airco. Aangezien de klant dit ook wel of niet kan vragen, zijn er vier mogelijke situaties; voor elk van deze situaties kan ingesteld worden hoeveel score dit kost of oplevert. 4. Nadat alle instellingen bekeken zijn en alle scores opgeteld (of afgetrokken, komen we aan de totaalscore. Indien deze totaalscore boven de persoonlijke minimale score zit, zal dit product gekocht worden indien dit het product is met de hoogste score. Indien deze totaalscore echter te laag is zal het product nooit gekocht worden.
5.5.2
Wereldmap aanpassen
In het linkermenu kan je in het gedeelte ‘maps’ een wereldmap selecteren. Indien je daarna op ’edit’ drukt, kom je in het scherm zoals in figuur 5.10. Deze wereldmap is een rechthoekig gebied waarvan de grootte ingesteld kan worden in het linkermenu. De achtergrond heeft een bevolkingsdichtheid van 100. Er kunnen rechthoekige gebieden met een andere (hogere) bevolkingsdichtheid toegevoegd worden door ergens op de map te klikken en dan, in het linkermenu, de grootte en bevolkingsdichtheid in te geven voor dit nieuwe gebied. Gebieden met een hogere bevolkingsdichtheid zullen een donkerdere kleur krijgen. De mogelijke kleuren zie je in figuur 5.11; het gebied met de laagste bevolkingsdichtheid krijgt de meest linkse kleur, het gebied met de hoogste de meest rechtse kleur. De kleur van alle andere gebieden wordt bepaald door een simpele lineaire interpolatie tussen deze twee uitersten.
5.5 Wereldmap
35
Figuur 5.10: De wereldmap
Figuur 5.11: De kleurengradi¨ent van de kleuren gebruikt om de bevolkingsdichtheden aan te geven
Deze bevolkingsdichtheid wordt gebruikt om de kans te bepalen dat klanten in het gegeven gebied gegenereerd worden. Als je twee evengrote gebieden hebt waarbij gebied A een bevolkingsdichtheid heeft die dubbel zo groot is als die van gebied B zullen er gemiddeld dubbel zoveel klanten gegenereerd worden in gebied A als in gebied B. Bestaande gebieden kunnen ook aangepast of verwijderd worden door in het centrale gedeelte op deze gebieden te klikken. Vergeet tenslotte niet op ‘store changes’ te drukken of alle veranderingen gaan verloren bij het verlaten van de pagina!
5.6 Bedrijven
5.5.3
36
Klant simulatie
Het is ook mogelijk om al deze instellingen te testen en te finetunen. Hiervoor druk je op ‘simulate turn’ in het linker menu. Dit zal klanten genereren die de verkopers zullen opzoeken en kijken of ze iets naar hun zin vinden of niet, net zoals tijdens een beurtovergang. De enigste verschillen met een echte beurtovergang is dat de verkopers hier niets van merken, dat de producten niet effectief gekocht worden en dat u meer gedetailleerde informatie krijgt over wat er allemaal gebeurt. Het resultaat is dan te zien in figuur 5.12. Deze pagina toont drie verschillende soorten statistieken: Globale statistieken Hier ziet u de algemene samenvattende resultaten, zoals het aantal klanten, hoeveel klanten besloten hebben tot aankoop over te gaan, enzovoort. Statistieken per verkoper Hier krijg je per verkoper te zien welke score ze krijgen, hoe vaak ze bezocht geweest zijn en hoeveel ze verkocht hebben. Verder wordt ook hun stockgrootte getoond. Indien deze 0 is (en ze dus niets in stock hebben) zal hun score natuurlijk op 0 staan (aangezien de formule rekening houdt met het aantal producten in de stock). Statistieken per klant Hier krijg je de meest gedetailleerde informatie. Per gegenereerde klant wordt er getoond waar hij woont, wat hij wilt, welke dealers hij bezocht heeft, welk product zijn voorkeur heeft, of hij dit product gekocht heeft, enzovoort.
5.6 5.6.1
Bedrijven Alle bedrijven
Om het game te kunnen spelen moeten er natuurlijk bedrijven aanwezig zijn. Deze kunnen beheerd worden door op het icoontje met als tekst ‘companies’ te drukken (figuur 5.13). Er zijn twee soorten bedrijven. Enerzijds heb je de bedrijven ‘beheerd door de studenten’. Deze kan je
5.6 Bedrijven
37
Figuur 5.12: De resultaten van het simuleren van de klanten.
zien in het centrale deel van de pagina. Anderzijds heb je het ‘globale bedrijf ’. Dit bedrijf wordt beheerd door de administrator en is verantwoordelijk voor de leveranciers van de opties. Door in het linkermenu op ‘manage global company’ te drukken kan je inloggen in dit globale bedrijf. Vervolgens kan je de gebouwen en productie van dit globale bedrijf aansturen. Voor meer uitleg hieromtrent verwijzen we je naar het hoofdstuk over het gebruikersgedeelte (hoofdstuk 6). Het globale bedrijf heeft een onbeperkt budget. De bedrijven van de studenten kunnen aangemaakt worden door in het linkermenu een naam en budget in te geven. Vervolgens vink je de gebouwsoorten aan dat dit bedrijf zal mogen bouwen, en druk je op ‘create company’. Dit zal het bedrijf aanmaken en toevoegen aan de
5.6 Bedrijven
38
Figuur 5.13: De pagina waarop je de bedrijven beheert.
centrale lijst. In deze lijst zie je de naam van het bedrijf. Verder zie je het aantal studenten van dit bedrijf, het budget (zowel het initi¨ele startbudget als wat er van rest) en welke gebouwsoorten dit bedrijf mag aanpassen. Door op de link ‘manage company’ te drukken zal je inloggen als een gebruiker van dit bedrijf. Dit laat toe om al hun instellingen te zien en, indien nodig, aan te passen. Terugkeren doe je dan via de ‘admin’-link die bovenaan elke pagina staat.
5.6.2
E´ en enkel bedrijf
Door in het centrale gedeelte op de naam van het bedrijf te drukken kom je op de beheerspagina van dit bedrijf (figuur 5.14).
5.6 Bedrijven
39
Figuur 5.14: De pagina waarop je ´e´en enkel bedrijf beheert.
In het centrale gedeelte kan je hier het initi¨ele budget aanpassen. Dit zal dan het effectieve budget ook aanpassen. Bijvoorbeeld, stel dat het bedrijf oorspronkelijk e 1000 budget had en er nu nog e 900 van rest. Als het initi¨ele budget dan verhoogd wordt naar e 2000 zal het budget van dit bedrijf verhogen tot e 1900. Dit laat toe om het budget van alle bedrijven achteraf op een eerlijke manier te verhogen. Ook kan je hier de bouwpermissies aanpassen. Dit is handig als je bij een bedrijf een bepaalde gebouwsoort teveel of teweinig gezet had. Via het linkermenu kan je nieuwe gebruikers toevoegen aan dit bedrijf. Dit doe je simpelweg door een gebruikersnaam en paswoord in te geven. Deze combinatie kan dan door de student gebruikt worden om in te loggen. Ook hier kan je via de link ‘manage company’ inloggen als een student in dit bedrijf. Terugkeren doe je dan via de ‘admin’-link die bovenaan elke pagina staat.
5.7 Beurtovergangen
5.7
40
Beurtovergangen
Een beurtovergang start je op de pagina genaamd ‘turns’. Afhankelijk van het feit dat de beurtovergangen van de huidige simulatie manueel gebeuren of niet , verschijnt figuur 5.15 of 5.16 op het scherm. Je wisselt tussen automatische en manuele beurtovergangen via het eerste veld in het linkermenu. De stappen die tijdens een beurtovergang doorlopen worden, werden reeds beschreven in sectie 4.7. Hier gaan we ons dus richten op de verschillen tussen manuele en automatische beurtovergangen.
5.7.1
Manuele beurtovergangen
Indien de beurtovergangen handmatig gebeuren (figuur 5.15) moet de administrator naar deze pagina navigeren, de acties aanvinken die hij wil toelaten en vervolgens op ‘simulate turn’ klikken. Dit zal dan de beurtovergang starten en afwerken.
5.7.2
Automatische beurtovergangen
De administrator kan er echter ook voor opteren om de beurtovergangen automatisch te laten verlopen (figuur 5.16). Hiervoor moet hij in het linkermenu eerst en vooral aangeven hoeveel tijd er tussen twee beurtovergangen zal zitten. Vervolgens moet hij ‘turn controls’ aanmaken. Dit zijn objecten die bepaalde acties aan bepaalde beurten toekennen. Om deze te gebruiken vink je onder ‘turn controls’ simpelweg de acties aan die je wilt toewijzen, kies je de periode waarmee deze acties toegekend worden (een periode van 1 betekent elke beurt, een periode van 2 elke even beurt, enzovoort) en kies je de eerste beurtovergang waarin je deze actie wilt laten toekennen. Indien in eenzelfde beurtovergang meerdere turn controls ‘actief’ zijn zal een actie toegestaan worden zodra deze toegestaan wordt in ´e´en van de turn controls. Je krijgt steeds een ‘live preview’ te zien van de acties die in de volgende 20 beurten toegestaan worden. Indien je tevreden bent moet je op ‘store changes’ drukken om de turn controls op te slaan. Een voorbeeld zal dit verduidelijken. In de screenshot (figuur 5.16) zijn er twee turn controls; De ene geeft elke 5 beurten toestemming om productie-, modificatie- en stockorders te plaatsen. Aangezien er aangegeven staat dat deze voor de eerste keer voorkwam in beurt 7 zal de student
5.8 Supply Chain
41
Figuur 5.15: De pagina waarop je de beurtovergangen manueel beheert.
dus in beurt 12,17,22,27,. . . orders mogen plaatsen. De andere turncontrol geeft de student toestemming om alle acties uit te voeren. Deze turncontrol is echter slechts om de 15 beurten actief.
5.8
Supply Chain
De laatste pagina (figuur 5.17) laat tenslotte toe om te bepalen wie met wie handel mag drijven. In het eerste gedeelte kan je aanvinken welke gebouwtypes rechtstreeks aan de gesimuleerde klanten mogen verkopen. In het tweede gedeelte zie je de handelsroutes staan. Deze geven aan welk gebouwtype aan welk gebouwtype mag verkopen via welke transportmethode. Er zal alleen handel gedreven kunnen worden tussen twee gebouwen indien er hier een handelsroute staat die aangeeft dat ze handel mogen drijven. Een nieuwe handelsroute aanmaken kan via het linkermenu.
5.8 Supply Chain
Figuur 5.16: De pagina waarop je de automatische beurtovergangen beheert.
42
5.8 Supply Chain
Figuur 5.17: De pagina waarop je de leveringsketen kan aanpassen.
43
GEBRUIKERSINTERFACE
44
Hoofdstuk 6
Gebruikersinterface Voor je dit hoofdstuk leest wordt je verondersteld om eerst hoofdstuk 4 te lezen, zodat je een goed inzicht hebt in de concepten en leveringsketen, gebruikt in dit spel. In dit hoofdstuk gaan we alle stappen overlopen nodig om een bedrijf op te richten en te beheren. Daarvoor zullen we in de eerstvolgende secties eerst en vooral uitleggen hoe je mobilhomes kan defini¨eren (sectie 6.1) en gebouwen kan bouwen (sectie 6.3). Daarna gaan we deze gebouwen configureren zodat de leveringsketen opgebouwd wordt (sectie 6.4). In sectie 6.14 en 6.17 zullen we tenslotte alle statistieken overlopen die tijdens de duur van het spel gegenereerd worden en gebruikt kunnen worden om deze leveringsketen te optimaliseren.
6.1
Productmodellen & optiepakketten
Deze pagina (figuur 6.1) kan je bereiken door op het meest rechtse icoontje (met als tekst ‘products’) te drukken. Hier kan je de modellen en optie pakketten defini¨eren die je wil gebruiken. Dit doe je door in het linkermenu een naam in te geven, de gewenste configuratie aan te passen en op ‘create’ te drukken. Het model en de optiepakketten verschijnen dan in het centrale gedeelte. In de screenshot kan je de optiepakketten bekijken die in de vorige sectie beschreven staan.
6.2 Leveringsketen
45
Figuur 6.1: De productmodellen en optiepakketten pagina
6.2
Leveringsketen
De pagina genaamd ‘Supply Chain’ is een zeer interessante pagina, aangezien deze kan dienen als naslagwerk. Op deze pagina kan je namelijk controleren hoe de leveringsketen eruit ziet, hoeveel de verschillende gebouwtypes kosten (en wat ze exact kunnen) en wat de productie (en het plaatsen van opties) kost.
6.2 Leveringsketen
6.2.1
46
Leveringsketen
De leveringsketen wordt reeds beschreven in sectie 4.1. Toch kan je deze altijd nakijken op deze webpagina indien gewenst. De leveringsketen wordt weergegeven in twee onderdelen (figuur 6.2). Eerst krijg je een lijst van alle gebouwtypes die rechtstreeks aan de klanten mogen verkopen. Dit zijn dus de drie soorten dealers (klein, normaal en groot). Vervolgens wordt er aangegeven welke gebouwtypes aan welke gebouwtypes kunnen verkopen. Bijvoorbeeld, er is een item dat zegt dat een fabriek aan de DC mag verkopen. Als je deze twee zaken combineert, heb je de volledige leveringsketen zoals weergegeven in figuur 4.1.
6.2.2
Gebouwtypes
Op deze pagina zie je verder een lijst van alle gebouwtypes die je mag bouwen. Dit zijn de factory, DC, small dealer, normal dealer en large dealer. De functie van deze gebouwen wordt reeds uitgelegd in hoofdstuk 4. Toch kan je dit altijd nakijken op deze webpagina. Verder biedt deze pagina ook de mogelijkheid om op te zoeken wat een gebouw (en zijn productie-/modificatielijnen) kost en wat de stockgrootte van dit gebouw is. In figuren 6.3 en 6.4 wordt dit ook weergegeven.
Figuur 6.2: De leveringsketen zoals deze op de webpagina ‘supply chain’ te zien is.
6.2 Leveringsketen
47
Figuur 6.3: De informatie van de verschillende verkopers
Figuur 6.4: De informatie van de DC en fabriek
6.2 Leveringsketen
6.2.3
48
Productiekosten
Tenslotte kan je op deze pagina de kosten van de opties ´en de productiekosten van de mobilhomes bekijken. De kosten van de opties zijn: • Airbag: 250 e • Airco: 200 e • Automatic: 1100 e • Cruise control: 150 e • GPS: 1300 e • Fietsenrek: 100 e Het plaatsen van elk van deze opties bij de DC kost nog 100 e per geplaatste optie (of voor het spuiten van de kleur). Voor het produceren van een mobilhome moet je 10000 e betalen, ongeacht het model. Verder komen er nog extra kosten bij afhankelijk van het gekozen model. Deze extra kosten zijn: • Comfortniveau: – Basis: 0 e – Medium: 1200 e – Luxueus: 3300 e • Aantal bedden: – 2: 0 e – 3: 1800 e – 4: 2000 e – 5: 4700 e – 6: 5000 e • Extra zitplaatsen:
6.3 Wereldmap
49
– 0: 0 e – 1: 200 e – 2: 500 e
6.3
Wereldmap
Het aanmaken van nieuwe gebouwen gebeurt op de wereldmap, dit is het eerste icoontje linksboven (rechts van het logo van de universiteit). Zoals je in figuur 6.5 kan zien is deze wereldmap een rechthoekig gebied waarop allemaal andere rechthoekige gebieden te zien zijn. Elk gebied heeft een andere bevolkingsdichtheid. Deze bevolkingsdichtheid bepaalt de kans dat een klant in dat gebied zal wonen. Gebieden met een hogere bevolkingsdichtheid hebben een donkerdere kleur. De mogelijke kleuren kun je zien in
Figuur 6.5: De wereldmap waarop je nieuwe gebouwen kan aanmaken
6.4 Gebouwen
50
Figuur 6.6: De kleurengradi¨ent gebruikt om de bevolkingsdichtheden aan te geven
figuur 6.5; het gebied met de laagste bevolkingsdichtheid krijgt de meest linkse kleur, het gebied met de hoogste de meest rechtse kleur. De kleur van alle andere gebieden ligt tussen deze twee uitersten. Via icoontjes wordt aangegeven waar de gebouwen zich bevinden. Elke gebouwsoort heeft een eigen icoontje. Via de filter in het linkermenu kan je aanpassen welke gebouwsoorten er weergegeven worden en welke niet. Door hier bijvoorbeeld het vinkje voor ‘factory’ weg te halen, zal de fabriek niet meer weergegeven worden op de wereldkaart. Om een nieuw gebouw aan te maken klik je eerst op de wereldmap op de plaats waar je dit gebouw wilt bouwen. Vervolgens kan je in het linkermenu het gebouwtype en een naam voor dit gebouw kiezen. Door op ‘build’ te drukken wordt de constructie van dit gebouw gepland. Aangezien de gehele game turn-based is (zie sectie 4.7 voor meer uitleg) wordt dit gebouw nog niet direct geplaatst. Toch zal het al op de wereldmap te zien zijn. Door op dit nieuwe gebouw te klikken zal je de mogelijkheid krijgen om de constructie van dit gebouw te annuleren. De bouwkosten van dit gebouw zullen slechts betaald moeten worden in de beurtovergang waarin dit gebouw effectief geplaatst wordt.
6.4 6.4.1
Gebouwen Lijst van alle gebouwen
Klik nu op de link genaamd ‘buildings’. Je krijgt dan figuur 6.7 te zien. Hier heb je een overzicht van alle gebouwen die jouw bedrijf bezit. Ook krijg je kort de mogelijkheden van deze gebouwen te zien (of ze kunnen produceren en/of opties plaatsen en wat ze kunnen verkopen). Tenslotte krijg je ook de ‘gebouwstatus’ te zien. Indien deze ‘planned’ is, is het gebouw nog niet gebouwd, en kan je nog steeds de constructie annuleren. Door op de naam van een van de gebouwen te klikken kom je op de ‘gebouwspecifieke pagina’
6.4 Gebouwen
51
Figuur 6.7: Een overzicht van alle gebouwen die je bezit.
(figuur 6.8). Deze pagina zal meer of minder opties weergeven naargelang de mogelijkheden van het geselecteerde gebouw. Selecteer om te beginnen de fabriek.
6.4.2
Individueel gebouw
Deze pagina heeft een dubbel doel: enerzijds toont ze een kort overzicht van wat dit gebouw allemaal doet en anderzijds dient ze om te navigeren naar de pagina’s waarop je kunt instellen wat dit gebouw doet. Het terugkeren naar het overzicht van alle gebouwen doe je door in het linkermenu op ‘view all buildings’ te drukken. Ook kan je het submenu gebruiken. Dit kleine menu, te vinden tussen de hoofding en de inhoud van de pagina, biedt steeds een handig middel om terug te keren, zowel van deze pagina naar de lijst met alle gebouwen als van elke volgende pagina naar deze pagina.
6.4 Gebouwen
52
Figuur 6.8: Het overzicht van de mogelijkheden en instellingen van een individueel gebouw
Deze pagina kan de volgende velden bieden: • View Production: Indien dit gebouw kan produceren, kan je via deze link de productie beheren. • View Modifications: Indien dit gebouw opties kan plaatsen, kan je dit via deze link beheren. • View Stock: Kijk wat dit gebouw in stock heeft en plaats nieuwe bestellingen. • View Log: Zie wat dit gebouw in de vorige beurten gedaan heeft. • View market demand: Indien dit gebouw een dealer is kan je hier zien wat de klanten
6.4 Gebouwen
53
gevraagd hebben tijdens de vorige beurten. • View stock statistics: Zie wat dit gebouw in welke beurt in stock had, produceerde, enzovoort. • View sales prices: Zie wat de prijzenstrategie van dit gebouw is. We gaan nu in de volgende subsecties dieper in op elk van deze pagina’s, behalve de ‘market demand’ en de ‘stock statistics’. Deze worden besproken in sectie 6.14.
Figuur 6.9: De productiepagina van een fabriek
6.4 Gebouwen
6.4.3
54
Productie
Om te kunnen produceren heb je zowel productielijnen als productieorders nodig. De verschillende soorten productielijnen worden in sectie 4.5 toegelicht. Productieorders zullen de productie aansturen. Dit gaat als volgt in zijn werk: 1. Elke productieorder heeft een bijhorend model en een gewenst aantal. 2. Tijdens de beurtovergang wordt gekeken hoeveel mobilhomes van het gegeven model in stock en/of in productie zijn. Indien dit aantal lager is dan het gewenste aantal wordt de productie van dit verschil aangevraagd. 3. Nadat alle productieorders overlopen zijn, komen de productielijnen aan beurt. Zij krijgen dus een lijst met mobilhomes waarvan de productie gewenst is. Uit deze lijst kunnen ze dan kiezen welke ze deze beurt gaan produceren. Alle mobilhomes die deze beurt niet geselecteerd worden krijgen de volgende beurt een nieuwe kans. Onder ‘Items in production’ (figuur 6.9) zie je alle mobilhomes die momenteel door een of andere productielijn geproduceerd worden. Je kan dan voor elk van deze mobilhomes zien welke productielijn ze aan het produceren is, wat deze productie zal kosten en wanneer deze productie klaar zal zijn. Onder ‘Products waiting for production’ zie je alle mobilhomes die we willen produceren, maar die in stap 3 hierboven (nog) niet geselecteerd werden. Verder toont deze pagina natuurlijk alle productielijnen en productieorders. Via het linkermenu kan je nieuwe productielijnen en -orders plannen en via het submenu tussen de hoofding en de inhoud van de pagina kan je tenslotte terugkeren naar de overzichtspagina voor de fabriek.
6.4.4
Plaatsen van optiepakketten
Het plaatsen van de optiepakketten kan gebeuren door de DC. Het principe is soortgelijk aan de productie, alleen worden nu modificatielijnen en modificatieorders gebruikt. Het resultaat kan je zien in figuur 6.10.
6.4.5
De stock
De volgende pagina (figuur 6.11) is verantwoordelijk voor de gehele stock. Dit bevat vele aspecten die we hier ´e´en voor ´e´en gaan toelichten.
6.4 Gebouwen
55
Figuur 6.10: De modificatiepagina van een DC
Stockorders De stockorders zijn verantwoordelijk voor het op tijd bijbestellen van de gewensten producten. Er zijn drie types stockorders, met elk een eigen gedrag:
6.4 Gebouwen
56
• De ‘one for one’ stockorder zal tijdens elke beurtovergang de producten bijbestellen die in de vorige beurt verkocht of gebruikt geweest zijn. • De ‘batch’ stockorder zal wachten tot het aantal producten in de stock gedaald is onder een zeker orderpunt. Zodra dit gebeurd is wordt er een gehele batch van producten bijbesteld. • De ‘periodic’ stockorder zal om de X beurten (de ‘periode’ genaamd) alle producten bijbestellen die gedurende deze periode verkocht of gebruikt geweest zijn. Bij het bestellen is het verder nog belangrijk om te herinneren dat een nieuw geproduceerde mobilhome opties op ‘default’ staan heeft. Verkoopstock In dit deel zie je alle producten die je momenteel in stock hebt en die je mag verkopen. Verder wordt hier ook de totale stockgrootte, de gebruikte stock en de vrije stock getoond. Grondstoffen stock Alle producten die je niet mag verkopen worden in de ‘grondstoffen stock’ gezet. Dit zijn bijvoorbeeld de opties bij een DC, die hij niet mag verkopen maar wel kan gebruiken om te plaatsen op de mobilhomes. Uitstaande en binnengekomen orders De uitstaande bestellingen toont alle producten die dit gebouw aan zijn leveranciers gevraagd heeft, maar die nog niet geleverd zijn. De binnengekomen orders daarentegen zijn alle producten die een ander gebouw bij dit gebouw wilt kopen, maar die dit gebouw nog niet geleverd heeft.
6.4.6
De leveranciers
Op deze pagina kan je de leverancier of leveranciers van het geselecteerde gebouw kiezen. Sommige gebouwen (de fabriek bijvoorbeeld) mogen meer dan ´e´en leverancier hebben, andere gebouwen mogen er slechts ´e´en hebben.
6.4 Gebouwen
6.4.7
57
De prijzenstrategie
De verkoopsprijs van een mobilhome wordt bepaald door een watervalsysteem bestaande uit 4 delen. Dit valt duidelijk af te leiden uit de prijzen pagina (figuur 6.12). Eerst wordt er gekeken of bij deze verkoper een vaste prijs ingesteld is voor deze mobilhome. Deze laat toe om eenzelfde mobilhome bij iedere verkoper een andere prijs te geven. Indien er geen vaste prijs is, wordt gekeken of er bij dit gebouw een vast winstpercentage ingesteld is. Indien dit het geval is, verkoopt deze dealers alle mobilhomes met de gegeven winstmarge. Deze winstmarge wordt genomen bovenop de totale kost die we reeds betaald hebben voor deze mobilhome, inclusief de productiekost, de geplaatste opties en de transportkosten. Bijvoorbeeld, stel dat de productie van een mobilhome 10000 e kost, en dat op deze mobilhome een airco geplaatst is. De aankoopsprijs van een airco is 250 e en de plaatsingskost voor een airco is 100 e. Dit betekent dat we reeds 10350 e betaald hebben voor deze mobilhome. Een winstmarge van 100% zal dus resulteren in een verkoopsprijs van 20700 e. Indien er bij deze verkoper geen winstpercentage ingesteld is, wordt er gekeken of er een globale vaste prijs ingesteld is voor deze mobilhome. Dit laat toe om eenzelfde mobilhome bij iedere verkoper dezelfde prijs te geven. Tenslotte zal er een globaal winstpercentage gebruikt worden. Standaard staat dit op 50%. In het voorbeeld (figuur 6.12) zal dealer2 de ‘basic blue’ mobilhome verkopen aan 15000 e, zal elke dealer de ‘black’ mobilhome verkopen aan 17000 e en zullen alle andere mobilhomes verkocht worden met een winstpercentage van 50%.
6.4.8
De log van een gebouw
De log toont kort de belangrijkste zaken die bij dit gebouw gebeurd zijn (figuur 6.13), bijvoorbeeld welke producten gekocht, verkocht of geproduceerd zijn. In het linkermenu kan je filteren wat je te zien krijgt. Je kan kiezen welke beurten weergegeven worden (standaard is dit de laatste 2), welke soorten boodschappen je ziet en welke labels vereist
6.5 De globale log
58
zijn. Dit laat toe om deze log zeer nauwkeurig te filteren indien je iets wilt opzoeken.
6.5
De globale log
Deze log bevat alle loginformatie van alle gebouwen, en nog wat globale informatie. Voor meer informatie verwijzen we naar sectie 6.4.8.
6.6
Statistieken
Een van de belangrijkste onderdelen van dit game zijn de statistieken. Deze geven de studenten de mogelijkheid om alles op te volgen, te analyseren en uiteindelijk de strategie te optimaliseren. Er zijn drie soorten statistieken, namelijk de marktvraag, de stock statistieken en de financi¨ ele statistieken. In deze sectie gaan we de marktvraag en de stock statistieken bespreken. De financi¨ele statistieken komen in sectie 6.7 aan de beurt. Deze twee statistieken zijn beschikbaar door op ‘statistics’ te drukken in het menu. Dit brengt je naar de pagina die je kan zien in figuur 6.14. Op deze pagina kan je elk van deze statistieken op drie manieren opvragen, namelijk de statistieken van een enkel gebouw, de statistieken van alle gebouwen (in een beurt naar keuze) of de globale statistieken (per beurt). Ook kan je al deze statistieken in een excel document downloaden indien gewenst.
6.6.1
Marktvraag
De marktvraag (figuur 6.15) toont je hoeveel klanten er in een bepaalde beurt langsgekomen zijn, en welke mobilhome deze klanten wensten. Bovendien wordt ook aangegeven hoeveel procent van alle klanten (van de gehele markt) in dit gebouw langsgekomen zijn (onder ‘clients (%)’) en hoeveel procent hiervan besloten heeft om een mobilhome bij jou te kopen (onder ‘sales (%)’). Deze statistieken laten dus toe om zowel te evalueren wat de klant wilt als wat je marktaandeel is.
6.7 Financi¨en
6.6.2
59
Stock statistieken
De stock statistieken (figuur 6.16) tonen je welke producten er tijdens een welbepaalde beurtovergang in stock zijn, in productie zijn, waarop opties geplaatst worden, gekocht of verkocht worden, enzovoort. Samenvattend tonen deze statistieken je alles wat er met de producten gebeurt. Deze statistieken laten dus toe om te controleren of de leveringsketen goed werkt en zoniet om de problemen te identifici¨eren.
6.7 6.7.1
Financi¨ en Een enkele beurt
Door op ‘finances’ te drukken krijg je de inkomsten en uitgaven van de laatste beurtovergang te zien (figuur 6.17). Door op het driehoekje voor de gebouwnamen te drukken kan je meer details te zien krijgen of deze juist verbergen. In de screenshot (figuur 6.17) zie je bijvoorbeeld de details van de verkoop van dealer2, terwijl de details van de productie en onderhoudskosten verborgen zijn. Op deze pagina zie je natuurlijk ook nog het resterende budget van het bedrijf. In het linkermenu kan je bovendien de inkomsten en uitgaven van een andere beurt opvragen indien dit gewenst is.
6.7.2
Alle beurten
Indien je eerder de samenvattende inkomsten en uitgaven van alle beurten wil kan dit door op ‘summary of all turns’ te drukken op de financi¨en pagina. Dit brengt je naar de pagina die je kan zien in figuur 6.18. Hier zie je dan in tabelvorm de inkomsten en uitgaven van alle beurten tot nu toe opgesomd staan. Deze tabel kan weerom gedownload worden als een excel document via de link in het linkermenu.
6.7 Financi¨en
60
Figuur 6.11: De stock pagina
6.7 Financi¨en
61
Figuur 6.12: De pagina waarop je de prijzenstrategie kunt aanpassen
6.7 Financi¨en
62
Figuur 6.13: Het logboek van een enkel gebouw
6.7 Financi¨en
63
Figuur 6.14: De statistieken pagina
6.7 Financi¨en
64
Figuur 6.15: De marktvraag van een enkele leverancier.
Figuur 6.16: De stock statistieken van een enkel gebouw.
6.7 Financi¨en
65
Figuur 6.17: De financi¨en van een enkele beurt
6.7 Financi¨en
66
Figuur 6.18: De financi¨en van alle beurten
TESTEN
67
Hoofdstuk 7
Testen Gedurende de ontwikkeling van dit game zijn drie soorten testen gebruikt, elk op hun eigen tijdstip en met hun eigen doel. In de volgende secties ga ik deze verschillende soorten testen overlopen.
7.1
Unit testen
In het begin van de implementatie was er nog geen interface beschikbaar langs waar de code getest kon worden. Daarom werd de code toen getest via ‘unit testen’[8]. Dit zijn testen om te valideren dat individuele delen van de code hun werk doen ´en blijven doen. Deze testen worden dan binnen een testframework verzameld dat toelaat om deze testen in een batch uit te voeren. Deze batch kan dan gebruikt worden om aan ‘recursie testen’ te doen. Dit zijn testen bedoeld om te controleren dat de nieuwe veranderingen niet als zijeffect een ander deel van de code ‘breekt’. Als testframework werd ‘JUnit’[9] gebruikt. Dit framework is speciaal voor java ontwikkeld en integreert in alle belangrijke IDE’s, zoals NetBeans en Eclipse. Deze unit testen zijn uitvoerig gebruikt geweest om de functionaliteiten van de kern te valideren.
7.2
Individuele testen
Zodra de kern klaar was (zie hoofdstuk 3 voor uitleg over de architectuur) werd er overgegaan op de implementatie van de gebruikersinterface. Dit liet dan toe om meer ‘high level’ testen
7.3 Tryout gehele game
68
uit te voeren. Deze testen werden door de programmeur gebruikt om te zien of ‘high level functionaliteiten’ zoals het aanmaken van een nieuwe simulatie, een nieuwe gebouwsoort, het bouwen van een nieuw gebouw, het uitvoeren van productie, enzovoort werkten. Deze testen zijn eerder ‘ad hoc’ gebeurd telkens de interface een nieuwe actie toeliet.
7.3
Tryout gehele game
Als laatste test werd een tryout van de gehele game door de assistanten van Prof. dr. ir. Hendrik Van Landeghem uitgevoerd. Deze testrun diende om de laatste bugs te vinden, om feedback te krijgen ´en als demonstratie. Deze tryout ging door op 7 en 8 mei, waarbij op 7 mei de game ge¨ınstalleerd en opgezet werd en de gebruikers een briefing kregen in het gebruik van deze game. Tenslotte konden de gebruikers hun strategie bepalen en de gebouwen bouwen. Op 8 mei werd eerst de strategie van de gebruikers gecontroleerd. Hierna werden de parameters voor de klantengeneratie verfijnd. Tenslotte werden een aantal ronden gesimuleerd. Deze testrun leverde een aantal interessante opmerkingen en mogelijke verbeteringen op, die echter wegens tijdsgebrek niet uitgevoerd konden worden. De belangrijkste opmerkingen zijn: • Een mogelijkheid om de instellingen van productie en bestellingen te kopi¨eren, zodat de gebruiker deze slechts eenmaal hoeft in te geven en dan kan gebruiken voor elke verkoper (indien gewenst is dat alle dealers dezelfde producten aanbieden). • Een betere feedback voor de klantengeneratie. Deze veranderingen zijn wel doorgevoerd en hebben geresulteerd in de pagina die je kan zien in sectie 5.5.3. • Een overzicht van de geplande kosten, zodat de gebruiker tijdens het plannen van de strategie kan zien hoeveel de reeds geplande constructiekosten bedragen. • Het weergeven van een waarschuwing indien de productie groter wordt dan de stock toelaat. Deze veranderingen (tesamen met het implementeren van de interface voor het maken van nieuwe producten (zie sectie 5.3.1)) zouden bijvoorbeeld door een volgende student ge¨ımplementeerd kunnen worden.
INSTALLATIE & CONFIGURATIE
69
Bijlage A
Installatie & configuratie A.1
Benodigde downloads
Java Voor deze thesis is intensief gebruik gemaakt van enkele technologie¨en ge¨ıntroduceerd in java 5. Dit is dus ook de minimale vereiste java versie. De editie die gekozen moet worden is de EE (‘Enterprise Edition’). Deze kan gevonden worden op de dvd of op http://java.sun.com/ javaee/downloads/index.jsp. Hier is het ook nuttig om te kijken naar de edities die reeds Netbeans en GlassFish v2 bevatten, zodat je deze niet apart hoeft te downloaden.
Netbeans en GlassFish v2 Als ontwikkelaarsomgeving (IDE) is gekozen voor Netbeans omdat dit als enigste een volledige ondersteuning van de EJB3 technologie bood. Omdat de thesis server technologie¨en gebruikt is de ‘Web & Java EE’ editie van Netbeans 6.x nodig. Deze kan gevonden worden op de dvd of op http://www.netbeans.org. Dit pakket bevat meteen ook de benodigde GlassFish server. Indien je alleen de server wilt installeren kan je deze vinden op https://glassfish.dev.java. net/downloads/v2ur2-b04.html.
A.2 Configuratie
A.2
70
Configuratie
De broncode op de dvd bestaat uit drie Netbeans projecten, genaamd simulator, simulator-war en simulator-ejb. Hierbij zitten de twee laatsten in de map van de eerste. Om deze projecten in Netbeans te openen volstaat het om simulator te openen en ‘open afhankelijke projecten’ aan te vinken. Om de projecten correct te kunnen deployen op de server zijn er nog een aantal stappen nodig. Deze stappen zijn voornamelijk nodig omdat de authenticatie automatisch door de server gebeurt en we dus moeten zorgen dat deze server de gebruikersnamen uit de juiste databank haalt. De standaardwaarden van de in te vullen velden zullen steeds tussen haakjes gezet worden.
Server installeren in Netbeans Open Netbeans, en kies Tools > Servers. Indien de GlassFish v2 server hier niet staat druk je op Add Server, selecteer je GlassFish v2 en navigeer je in het volgende scherm naar de installatiefolder van de GlassFish v2 server.
Maak connection pool & databank • Start de server. Dit kan je doen door in Netbeans naar Tools > Servers te gaan en daar met de rechtermuisknop op de GlassFish server te klikken en Start server te kiezen. Kies View Admin Console eens de server gestart is (figuurA.1). • Geef nu je gebruikersnaam (admin) en paswoord (adminadmin). • Navigeer naar Resources > JDBC > Connection Pool en druk op New.... Dit geeft je figuur A.2. • Kies een naam voor de connectiepool (userauth), het resource type (javax.sql.DataSource) en de database vendor (JavaDB) (figuur A.3). Selecteer vervolgens (Next). • Scroll naar beneden totdat je bij (Additional Properties komt. Vul hier de databanknaam, gebruikersnaam & paswoord in die je voor de databank wilt gebruiken (scmgame, scmgui & latitude in figuur A.4). Zet ook ;create=true bij de ConnectionAttributes. Klik Finish eens je hier klaar bent.
A.2 Configuratie
71
Figuur A.1: Open de admin console
• Nu kom je op een lijstje waarin je alle connection pools ziet. Druk op de connection pool die je juist gemaakt hebt (userauth), en druk dan op de knop Ping. Omdat je bij de Additional Properties gekozen hebt voor ‘‘;create=true’’ zal de databank nu automatisch aangemaakt worden. • Ga nu naar Resources > JDBC > JDBC Resources en druk op New.... • Geef het kind een naam (jdbc/userauth), selecteer de juiste pool (userauth) en kies OK.1
Maak gebruikersdatabank • Nog steeds in de “Server administrator console”, navigeer naar Configuration > Security > Realms en druk op New.... • Kies een naam (userauth) en kies de klasnaam die eindigt op ‘.JDBCRealm’. Vul verder alle gegevens in zoals in figuur A.5. Druk tenslotte op OK om alles op te slaan. • Klik nu op Configuration > Security. Stel daar userauth in als Default Realm en druk op Save (figuur A.6). 1
Deze instructies komen van http://blogs.sun.com/foo/entry/mort_learns_jdbc_for_glassfish
A.2 Configuratie
72
Figuur A.2: De lijst met bestaande connectionpools.
Figuur A.3: De nieuwe connectionpool.
A.2 Configuratie
73
Figuur A.4: De instellingen van de connectionpool.
• Herstart de server en Netbeans. Dit is zeer belangrijk aangezien anders deze veranderingen nog niet aanvaard worden.2
Maak databankconnectie Nu gaan we terug naar Netbeans. • Opden de Services tab, klik met de rechtermuisknop op Databases en kies “New Connection” (figuur A.7).
• Vul in deze popup (figuur A.8) de locatie van de databank (jdbc:derby://localhost:1527/scmg de gebruikersnaam (scmgui) en het paswoord (latitude) in. Druk nu tweemaal op OK.
Configureer EJB-Project Normaalgezien zijn de projecten correct geconfigureerd, en kan je dus deze stap (en alle volgende) overschieten. Deze uitleg is dus louter voor als het nu nog niet werkt. • Open de file Configuration Files > persistence.xml in het EJB-project. Kies daar bij Data Source voor “new data source” (figuur A.9). 2
Deze instructies komen grotendeels van http://blogs.sun.com/foo/entry/mort_learns_jdbc_realm_
authentication
A.2 Configuratie
74
Figuur A.5: De instellingen van de securityrealm.
• Kies een naam en selecteer de databank connectie die je gemaakt hebt in de vorige stap (stap A.2). Dit zie je in figuur A.10.
Configureer war-project • Navigeer naar Web Pages > WEB-INF > web.xml in het WAR-project. • Klik daar op Security en maak daar de security roles genaamd administrator en user aan (figuur A.11). • Vervolgens maak je de 4 security constraint voor de administrator en de eindgebruiker aan die je in figuur A.12 en A.13 ziet.
A.3 Gebruik van jspf files
75
Figuur A.6: Het instellen van de default securityrealm
Figuur A.7: Het aanmaken van een nieuwe databankconnectie
• Open nu sun-web.xml en klik opnieuw op Security. Daar voeg je groep administrator toe aan administrator, en user aan user (figuur A.14).
A.3
Gebruik van jspf files
Het probleem bij het gebruik van .jspf files is dat deze (hoe raar het ook mag klinken) niet gecompileerd worden als jsp files maar letterlijk ge¨ıncludeerd worden (zoals html pagina’s). Gelukkig kan dit gemakkelijk verholpen worden.
A.3 Gebruik van jspf files
Figuur A.8: Het aanmaken van een nieuwe databankconnectie (vervolg)
Figuur A.9: Het aanmaken van een nieuwe datasource in persistence.xml
• Open project simulator-war. • Navigeer daar naar Web Pages > WEB-INF > web.xml. • Open deze in XML-view zodat je de pure xml ziet. • Voeg daar boven session-config het volgende toe: <servlet-mapping>
76
A.3 Gebruik van jspf files
Figuur A.10: Het aanmaken van een nieuwe datasource in persistence.xml (vervolg)
Figuur A.11: De gebruikte securityroles in web.xml
<servlet-name>jsp
*.jspf
77
A.3 Gebruik van jspf files
Figuur A.12: De gebruikte securityconstraints in web.xml (1/2)
78
A.3 Gebruik van jspf files
Figuur A.13: De gebruikte securityconstraints in web.xml (2/2)
79
A.3 Gebruik van jspf files
Figuur A.14: Instelling van de groepen in sun-web.xml
80
BIBLIOGRAFIE
81
Bibliografie [1] D. Simchi-Levi, “Designing and Managing the Supply Chain, McGraw-Hill Education (ISE Editions); 3Rev Ed edition (November 1, 2007) [2] K. Nichols, V. Jacobson, L. Zhang, “A two-bit differentiated services architecture for the Internet”, IETF RFC 2638, July 1999. [3] http://java.sun.com/products/ejb/ [4] http://www.jboss.org/jbossejb3/ [5] https://glassfish.dev.java.net/ [6] http://www.prototypejs.org/ [7] C. Porteneuve, “Prototype and script.aculo.us”, December 2007, ISBN: 978-1-9343560-1-2 [8] IEEE Standard for software unit testing, December 1986, http://ieeexplore.ieee.org/servlet/opac?punumber=2599 [9] JUnit test framework, http://www.junit.org/
