02312 Indledende programmering og Udviklingsmetoder til IT- Systemer

Størrelse: px
Starte visningen fra side:

Download "02312 Indledende programmering og 02313 Udviklingsmetoder til IT- Systemer"

Transkript

1 Projektopgave efterår 2009 jan Indledende programmering og Udviklingsmetoder til IT- Systemer Projekt navn: CDIO tre ugers projekt Gruppe nr.: 52 Afleveringsfrist: Mandag d Studie nr. Efternavn Fornavn Underskrift s Ehrari Humira Kontakt person (Projektleder) s093468, Yildirim Ahmet s080529, Søby Michael s093479, Petersen Paw 1/33

2 Timeregnskab Dato Navn design impl. test dok Paw Humira Ahmet Michael Paw Humira Ahmet Michael Paw Humira Ahmet Michael Paw Humira Ahmet Michael Paw Humira Ahmet Michael Paw Humira Ahmet Michael Paw Humira Ahmet Michael Paw Humira Ahmet Michael Paw Humira Ahmet Michael Paw Humira /33

3 Ahmet Michael Paw Humira Ahmet Michael Paw Humira Ahmet Michael Paw Humira Ahmet Michael Paw Humira Ahmet Michael 3/33

4 Indledning (Humira) Dette projekt er lavet i forbindelse med tre ugers perioden i faget indledende programmering (02312). I dette projektet har vi udviklet et program til simulering af et Matador spil, hvor vi bygger videre og samler sammen på alt det vi har beskæftiget os med i de stillede opgaver i 13 ugers. Opgaven går ud på at lave en et matadorspil som består af en spilleplade forskellige type felter, et sæt af terninger samt 2-6 antal spillere. Opgaven løses ved benyttelse af forskellige metoder såsom: setnavn() der sætter navn på pågældende spiller, SetFarve() der Sætter navn på pågældende spiller, getsaldo(), der returnerer saldoen på kontoobjektet til den pågældende spiller, withdraw(), der trækker beløb penge fra konto, deposite() Indsætter beløb på konto osv. For at kunne løse opgaven har vi udarbejdet en række diagrammer over de overordnede datastrukturer og klasser, der repræsenterer matador spillet. På baggrund af denne opgave har udarbejdet en rapport der indeholder en beskrivelse af vores diagrammer og programkoder. 4/33

5 Indhold Indledning (Humira)... 4 Kravspecificering... 7 Matador... 7 Udviklingsstrategi (Humira og Paw)... 8 Design (Humira)... 8 Diagrammer (før programmering) (Humira)... 8 Sekvensdiagram (Humira) Klasse diagram (Humira) Implementering MatadorRaflebaeger (Paw) Player (Paw) Konto (Paw) PlayerController (Paw) PlayerBoundary (Ahmet) Field (Paw) Refuge (Paw) Taxes (Paw) Ownable (Paw) Street (Paw) Shipping (Paw) Brewery (Paw) Prison (Paw) LuckyCards (Ahmet) GameBoard (Paw) GameBoardController (Paw) GameBoardBoundary (Ahmet) BCE (Paw) Design efter programmering (Humira) Use case Designklassediagram (Humira) /33

6 Sekvens for at købe grunde (Humira) Konstruktion og test (Humira) Test (Michael) Om testene Test-klassen Manuel test Konklusion (Ahmet) Bilag /33

7 Kravspecificering Matador Der ønskes udarbejdet et program til simulering af et Matador spil. Delopgave 1: Datastruktur Et matadorspil består af en spilleplade, et sæt af terninger samt 2-6 antal spillere. Endvidere består en spilleplade af en sekvens af felter af forskellig type. Design de overordnede datastrukturer og klasser, der repræsenterer en spilleplade, et felt, en spiller og et sæt terninger. Det et krav, at I tegner i et UML diagram (det er meget ofte at det er dette vi tager udgangspunkt ved start af eksamen), som beskriver de forskellige klassers interaktion, og at I benytter jer af nedarving. Alt dette har vi beskæftiget os med i de stillede opgaver i 13 ugers. I skal nu samle det til et projekt. Delopgave 2: Valg af funktionalitet Det er tanken at så mange af spillets funktioner som muligt skal implementeres. Dog kan det være hensigtsmæssigt (evt. pga. kompleksitet) at fjerne nogle af spillets funktionaliteter eller sætte begrænsninger på dem, f.eks. bytning af grunde på kryds og tværs. Delopgave 3: Design tilstandsmaskine Når det bliver en spillers tur, står han/hende overfor en række valg, muligheder og begrænsninger - f.eks. kan en spiller der lander på en grund, som ikke ejes af andre spillere, købe grunden, pantsætte egne grunde og så købe grunden, eller lade være. Design den tilstandsmaskine, som håndterer disse valg, muligheder og begrænsninger. Overvej om denne tilstandsmaskine skal placeres indeni spiller klassen eller udenfor i en separat klasse. Delopgave 4: Test Det forventes at I laver en grundig og dybdegående test at programmet. Gennemtænk hvordan alle dele af programmet, alle dele af koden, testes med relevante testdata. Overvej hvordan I kan automatisere testen og hvordan I kan gemme resultaterne af Jeres test som dokumentation. 7/33

8 Udviklingsstrategi (Humira og Paw) Vi vil først finde ud af hvilke funktionaliteter der er de vigtigste, herefter vil vi få programmeret dem. Vi vil så inkludere dem i vores tilstandsmaskine og teste den. Hver gang vi har lavet en ny funktion i vores tilstandsmaskine vil vi dokumentere den. Hvis vi har mere tid, vil vi prøve at implementere mindre vigtige funktioner. Vi starter altså først med at få lavet de vigtigste og mest risikofyldte funktionaliteter, og går herefter videre til de mindre vigtige, hvis der er tid. Ved at gøre det på denne måde, sikrer vi os at vi ikke ender op med en masse funktionaliteter, som ikke fungerer og dermed følger vi UP-metoden. Vi arbejder altså ud fra princippet i UP som siger at processen skal være risk-driven. Desuden følger vi spiralmodellen og får hver funktionalitet op at køre, en ad gangen, i stedet for at følge vandfaldsmodellen og ende op med en hel masse ufuldstændige funktioner, der eksempelvis ikke er testet eller dokumenteret ordentligt. Spiralmodellen, har flere fordele idet de forskellige iterationer sikre at risikoen for fejl bliver tjekket i hver iteration, derved mindskes hele projektets risici, jo længere inde i projektet man er. Vi mener dette er det model der passer bedst til projektet. Efter at vi et færdig med at implementer vores system, så vil vi dele det således op, så den overholder kravet om BCE- modellen. Design (Humira) Det kan være en god måde at beskrive udviklingen i et system vha. diagrammer. På den måde får man overblik over, hvad systemet gør i forskellige situationer, og dette er med til at skabe overblik således, at koden bliver pæn. På baggrund af dette har vi i designfasen udviklet nogle diagrammer både før programmering og efter programmering der giver overblik over hvordan systemet skal stykkes sammen (før programmering) og hvordan ser system ud (efter programmering). Vi har valgt at benytte klassediagram, use case model og sekvens- og BCE-diagram til at diagrammere udvalgte scenarier af vores system. Diagrammer (før programmering) (Humira) For at kunne danne sig et overblik over funktionelle krav i systemet, har vi lavet neden stående Use-case diagram da det er en beskrivelse af brugeren af et system. Dette er en metode til at holde problemstillingerne simple og forståelige på. Vi valgte at lokaliserer de vigtige processer i spillet. Hvor systemet bliver nedbrudt i små dele (cases), og spilleren i aktør, der anvender forskellige del af system. 8/33

9 Som de ses til højre i diagrammet har vi en ekstern aktør der i dette tilfælde er et spiller, der benytter forskellige del af systemet. Blandt dele af systemet er der landet eller passeret, når der bliver kastet med terninger så skal spillerne kunne rykke antal felter frem eller tilbage. På de felter som de lander, skal man kunne købe eller sælge grunde, eller skal der betales leje, dvs. systemet skal kunne håndtere at der er spiller der lejer eller udlejer, køber og sælger grunde dermed skal de kunne bygge huse og hoteller. Systemet skal kunne håndtere passere eller landet start feltet, prøve lykken, pantsætte, parkere og gå i fængsel. 9/33

10 Sekvensdiagram (Humira) For at kunne danne sig overblik over matador spillets centrale dele og de centrale funktioner der indgår i spillet, har vi udarbejdet neden stående sekvensdiagram, der viser kommunikation mellem de forskellige klasser. Som det ses i sekvensdiagrammet klassen spiller bruger klassen raflebæger, for at få information om terningerne, dernæst bruger den klassen bræt for at rykke, dette er fordi terningernes sum påvirker spillerne position på brættet. Så er der en pil fra bræt til felt der bruger metoden landet på felt, til sidst sker der transaktioner. 10/33

11 Klasse diagram (Humira) Eftersom vi i dette projektet skulle bygge videre og samle sammen på alt det vi har beskæftiget os med i de tidligere stillede opgaver i 13 ugers perioden, har vi udarbejdet neden stående klassediagram for at danne sig overblik over de dele der mangler i spillet og det krav der er blevet stillet til opgaven. Klassediagrammet er ikke særlig detaljeret da vi bruger det til at få inspirationer til at bygge videre. Klassen Field er den klasse, hvor de øvrige felter nedarver fra. Vi har valgt at tilføje klasserne Spiller, Raflebæger, Konto og GameBoard i klassediagrammet. Dette fordi en spiller skal kunne lande på et felt, hvorefter han 11/33

12 skal betale eller modtage penge. Raflebægeret er med til at bestemme lejen i Brewery-felterne. Klassen Gameboard indeholder array med felterne. Klassen Taxes overfører et beløb til spilleren, der lander på feltet. Dette gøres ved at lade spilleren bruge feltets landonfield(). Street, Shipping og Brewery er de tre felter der kan ejes af spillere, alle klasserne nedarver fra Ownable, og har dermed en pris og en leje for at lande på grunden. Når en spiller lander på et rederi, skal der overføres penge fra spilleren til ejeren af grunden. Dette gøres ved at tilsidesætte den nedarvede landonfield()-metode med en, der overfører beløbet. 12/33

13 Implementering MatadorRaflebaeger (Paw) Vi har først oprettet konstanterne T1SIDER og T2SIDER, som er antallet af sider på henholdsvis terning 1 og 2. Konstanterne er sat til public, da vi gerne vil kunne hente antallet af sider til vores test-klasse. Desuden har vi variablerne terning1, terning2, sum som alle er int. Derudover har vi boolean-variablen ens. kast(): Vores kastefunktion genererer tilfældige tal for terning1 og terning2 ved hjælp af nextint()- kommandoen fra java.util.random, som vi har importeret i starten af klassen. Ved at bruge T1SIDER og T2SIDER som argument i nextint()-kommandoerne bliver der genereret et tal mellem 0 og 5, dette tal lægger vi så 1 til, for at få et tal mellem 1 og 6. Vores kaste-funktion ligger desuden i konstruktøren, således at terningerne i forvejen er kastet, når objektet oprettes i test-klassen. getøjne1() og getøjne2() returnerer variablerne terning1 og terning2, som indeholder antallet af øjne på hver terning. printøjne(): Denne ekstra-funktion returnerer en 2-linjet streng, der fortæller værdierne af terning1 og terning2. Funktionen er strengt taget ikke nødvendig, alligevel har vi valgt at beholde den. getsum() lægger terning1 og terning2 sammen, hvorefter den returnerer summen, sum. getens(): Hvis terning1 er lig med terning2 ændres boolean-variablen ens til true, ellers ændres den til false. Til sidst returnerer den ens. Player (Paw) Vores Player-klasse har variablerne navn og farve som henholdsvis String og int. Klassen har desuden et konto-objekt kaldet k. Da alle disse er sat til private, har vi nogle funktioner som bruger dem: Funktionerne setnavn(), setfarve(), getnavn() og getfarve() bruges til at sætte eller få returneret navn og farve. Desuden har vi en printfarve()-funktion der udskriver navn og farve. Vi har desuden en tostring()-funktion, som returnerer en streng med navn og k (her køres Konto-klassens tostring()-funktion). For at forbinde klassen til vores GameBoard, har vi oprettet en variabel kaldet position, som er af typen int. Desuden har vi en boolesk variabel, jail, som angiver om spilleren er i fængsel eller ej. Til disse værdier har vi både get- og set-funktioner. Funktionen move(int antalfelter) ændrer spillerens position til at være summen af hans nuværende position og antalfelter. Desuden bliver der trukket 40 fra position, hvis værdien for position overstiger dette tal, hvorefter der bliver kørt funktionen passeretstart() på hans konto. Desuden har vi oprettet henvisninger til de funktioner som vi har i Konto-klassen, så vi eksempelvis kan indsætte penge på en spillers konto ved at bruge player.deposite(double amount). 13/33

14 Konto (Paw) Klassen har en double-variabel, saldo, som er playerens saldo. Desuden har vi to arrays, transtid[] og beløb[], som håndterer punkt 9 i opgavebeskrivelsen (transaktioner skal gemmes med oplysninger om transaktionstid og beløb). Længden af de to arrays bliver sat til maxtrans (maksimum transaktioner), som er sat til Dette er en lille svaghed ved vores program da vi gemmer transaktionerne i arrays, bliver vi nødt til på forhånd at definere det maksimale antal mulige transaktioner. Hvis alle pladserne i de to arrays bliver udfyldt, opstår der altså et problem. Dog regner vi ikke med at der bliver lavet 1000 transaktioner så vi regner ikke med at der opstår problemer med mindre man med vilje fremprovokerer unaturligt mange transaktioner i et spil. Alternativt kunne vi have brugt arraylists. Vi har så en række funktioner. Funktionen getdatetime() returnerer tidspunktet som en streng på formen timer:minutter:sekunder og bruges kun internt i klassen til at gemme tidspunkter i arrayet transtid[]. getsaldo() returnerer spillerens saldo. withdraw(double amount) og deposite(double amount) bruges til at hæve og indsætte penge i spillerens saldo. withdraw(double amount) tjekker desuden om spilleren prøver at hæve flere penge end han har på sin saldo, på den måde undgår vi at hans saldo kan gå i minus. Hver gang withdraw(double amount) eller deposite(double amount) bliver kørt, gemmes tidspunkt og beløb på de næste tomme pladser i transtid[] (ved hjælp af getdatetime()-funktionen) og beløb[] (beløbenes fortegn afgør om pengene er blevet indsat eller hævet). Funktionen printoversigt() kan så bruges til at udskrive en oversigt over transaktionernes tidspunkt og beløb - lige som de oversigter man får fra banken i virkeligheden. Funktionen passeretstart() laver en deposite(double amount) med værdien for variablen passerstart på 4000, som argument. beløbtjek(double amount) returnerer sandt eller falsk, afhængig af om spilleren har det beløbet amount, fra funktionens argument, på sin saldo. Konto-klassens tostring()-funktion returnerer saldoen. PlayerController (Paw) Vi har først oprettet nogle variable: antalspillere og spillernummer. Herefter har vi oprettet 3 arrays: spillere[], farvearray[] og color[]. spillere[] er af typen Player, dens længde bliver defineret senere. farvearray[] er af typen String, og indeholder alle de farver som spillerne kan vælge imellem. På første plads i arrayet har vi ingen farve, som hver spiller starter med at have, når han bliver oprettet. color[] er af typen int, og har samme længde som farvearray[]. Arrayet color[] bliver brugt til at sikre at hver farve kun kan vælges én gang hvis en farve er i brug, sættes pladsen til 1. Er farven ikke i brug, har den værdien 0. Vi har så en række funktioner som returnerer og sætter de forskellige variabler. Derudover har vi getactiveplayers(), som gennemgår arrayet spillere[] og tjekker hvor mange af pladserne i arrayet, som ikke er tomme (dvs. der er en aktiv spiller), ved hjælp af en løkke. Antallet af aktive spillere returneres så. 14/33

15 getwinner()-funktionen tjekker først om der kun er én spiller tilbage i spillet, hvorefter spiller-arrayet bliver gennemgået og sætter variablen winner til at være lige spilleren. Variablen winner returneres så. navnoptaget(string navn) tjekker ved hjælp af en while-løkke om et navn allerede er taget, der skelnes ikke mellem store og små bogstaver, idet vi bruger equalsignorecase(string anotherstring). Funktionerne setnavn(player spiller, String navn) og setfarve(player spiller, int farvevalg) opretter navn og farve i henholdsvis spillere[] og farve i Player-klassen. Desuden bliver color[] i setfarve(player spiller, int farvevalg) opdateret, således at der er styr på hvilke farver er taget. PlayerBoundary (Ahmet) Starter med at lave en public static void, hvor spilleren skal indtaste sit navn og får tildelt et spillernummer. Derefter starter en while løkke som tjekker om navnet er optaget eller ej. Hvis navnet er optaget så gentages løkken. Hvis navnet ikke er optaget så tildeles spilleren et navn og et spillernummer. Derefter køres en public static void, hvor spiller skal vælge farve, som vælges ved at indtaste et tal mellem 1 og 6. Og hvis farven allerede er i brug skal spilleren vælge en ny farve som ikke er optager. Når man uoptaget farve vælges bliver man tildelt denne farve og så kan andre spillere ikke vælge denne farve. Derefter køres en public static void opret() metode som opretter spillere. Som starter med at spørge om hvor mange spillere der skal spille. En while løkke startes og betingelsen for denne er at antallet af spillere skal være mellem 2-6. Hvis ikke dette opfyldes så skal man indtaste antallet af spillere forfra. Hvis betingelsen opfyldes så kaldes playercontrolleren som sætter spillerne ind i spillet. Derefter kører en for løkke som scanner navnene og farverne på spillerne. Field (Paw) Klassen har variablerne number og name, som henholdsvis int og String. Disse er feltets nummer og navn, som er sat til protected, således at klasserne som nedarver fra klassen kan tilgå disse. Klassens konstruktør tager disse variable som argumenter. Vi har så defineret metoden landonfield(player player) som abstract, da alle de nedarvende klasser skal have denne metode. Metoden tager, som det ses, en spiller som argument. Denne metode har vi sat til at returnere en String med information om hvad der er sket med spilleren efter han er landet på feltet. Klassens tostring()-metode returnerer en streng med oplysninger om feltnavn og feltnummer. Refuge (Paw) Denne klasse nedarver direkte fra Field-klassen, og har udover argumenterne i Field-klassens konstruktør en bonus som int. Klassens tostring()-metode er den samme som Field-klassens. Synlighedsniveauet for variablen bonus er sat til private. Metoden landonfield(player player) tjekker først om bonus er større end nul, hvis den er det, indsættes bonus på spillerens konto, samt at den streng, som sendes tilbage, ændres. Ved at kunne sætte bonus til fx nul, når objektet oprettes, kan vi også bruge denne klasse til start-feltet og fængsels-besøgs-feltet. 15/33

16 Taxes (Paw) Også denne klasse arver fra Field. Da der i opgavebeskrivelsen står at der er to af disse skattefelter, har vi valgt at lade denne klasses konstruktør definere variablen tax, som er den skat man skal betale (int), når man lander på feltet. Klassens konstruktør tager både number, name og tax som argumenter, her har vi brugt super()-funktionen til at tilgå variablerne fra Field-klassen. Når en spiller lander på feltet, funktionen landonfield(player player), har vi først en løkke, som kører funktionen menu(player player) i GameBoardControlleren så længe han ikke har penge nok til at betale skatten. I menu(player player)-funktionen har spilleren mulighed for at sælge huse for at kunne komme videre i spillet. Kan han ikke skaffe nok penge, må han bruge Giv op -funktionen i menuen. Hvis spilleren har penge nok til at betale skatten (beløbtjek()-funktionen returnerer sandt), køres withdraw()-fuktionen på player-objektet, hvorpå skatten, tax, trækkes fra spillerens konto. Herefter returneres en streng der fortæller hvor meget han har betalt i skat. tostring()-metoden returnerer det samme som Field-klassen, inklusiv information om skatten, tax. Ownable (Paw) Denne klasse arver fra Field og har samme konstruktør som denne, dog med et ekstra argument, pris (int). Som klassens navn indikerer, nedarver alle de felter, der kan ejes af spillere, fra denne klasse. Vi har så lavet funktionen rent(player Lejer, Player Udlejer), der klarer overførslen af lejen. Vi har også en ejer-variabel, owner, som er af typen Player. Funktionen owned() returnerer en boolean der angiver om feltet er ejet eller ej. Vi har også metoderne getowner() og setowner(player player), som henholdsvis returnerer ejerens navn og sætter ejeren. Funktionen buylot(player Køber) køber grunden ved at trække penge fra kontoen og sætte ejeren, hvis køberen har penge nok. tostring()-metoden for denne klasse kører Field-klassens tostring()-metode ved hjælp af super() og tilføjer oplysninger om ejeren inden den returnerer strengen. Her bruger vi desuden vores owned()-funktion til at tjekke om grunden er ejet. Street (Paw) Street-klassen nedarver fra Ownable og har desuden leje, hus1, huse2, huse3, huse4, hotel og huspris, som tages som ekstraargumenter i konstruktøren. Funktionen getaktuelleje() returnerer den aktuelle leje ved at lave en switch på antalhuse, som er en tæller der holder styr på antallet af huse på grunden. Lejen returneres ved at matche antalhuse med de forskellige leje-værdier som er defineret i konstruktøren. buyhouse(player player)-funktionen kører først en løkke der kalder GameBoardControllerens menu(player player) så længe han ikke har penge nok til at købe huset. Herefter bliver husprisen trukket fra spillerens konto samt at antalhuse sættes én op, hvis antalhuse er mindre end 5. Ellers køres menu(player player). 16/33

17 sellhouse(player player) tjekker først om der overhovedet er nogle huse på grunden som kan sælges, hvorefter halvdelen af husets pris sættes ind på hans konto og antalhuse sættes én ned. Funktionen getantalhuse() returnerer antalhuse. Vi har så defineret rent(player Lejer, Player Udlejer)-funktionen til først at tjekke om grunden er ejet (super.owned() er sand eller falsk), hvorefter vi kører en løkke der kalder menu(player player) så længe spilleren ikke har penge nok til at betale den aktuelle leje. Herefter køres funktionen transfer(udlejer, leje) på Lejer-objektet hvis feltet altså er ejet. Ejer man selv feltet vil pengene først blive trukket fra ens konto, og derefter indsat igen - dette er en mindre fejl. landonfield(player player)-funktionen opretter først strengen result, som skal returneres til sidst. Herefter tjekkes om grunden er ejet, hvorefter rent(player Lejer, Player Udlejer)-funktionen køres med player og owner som henholdsvis første og andet argument, result opdateres med information om dette. Har grunden derimod ingen ejer (super.owned() evalueres til falsk), tjekkes der først om spilleren har råd til at købe grunden. Hvis han har pengene, spørges han om han ønsker at købe grunden (buyoption() på GameBoardBoundary køres). Svarer spilleren ja (buyoption() er sand), køres Ownable-klassens buylot(player Køber)-metode med player som argument, desuden opdateres result. Hvis grunden derimod ikke er ejet, køres der først et beløbtjek på spilleren med prisen som argument. Er beløb-tjekket sandt, bliver grunden købt og result opdateres. Hvis beløb-tjekket ikke evalueres til sandt, opdateres result med oplysninger om at han ikke har penge til at købe grunden. result bliver til sidst returneret. tostring()-metoden returnerer resultatet fra Ownable-klassens tostring(). Shipping (Paw) Klassen nedarver fra Ownable-klassen og har en leje som private int. Konstruktøren sætter feltets nummer, navn og pris. rent(player Lejer, Player Udlejer)-funktionen kører en switch på antallet af ejerens rederier, som den henter ved at kalde getantalrederier(udlejer) på GameBoard. Lejen bliver så bestemt af antallet af rederier. Nu bliver menu(player player) på Lejer kørt så længe spilleren ikke har penge nok. Herefter bliver lejen overført fra Lejer til Udlejer ved hjælp af Player-klassens transfer(player p, double amount)-funktion. landonfield(player player)-funktionen opretter først strengen result, som skal returneres til sidst. Herefter tjekkes om grunden er ejet, hvorefter rent(player Lejer, Player Udlejer)-funktionen køres med player og owner som henholdsvis første og andet argument, result opdateres med information om dette. Har grunden derimod ingen ejer (super.owned() evalueres til falsk), tjekkes der først om spilleren har råd til at købe grunden. Hvis han har pengene, spørges han om han ønsker at købe grunden (buyoption() på GameBoardBoundary køres). Svarer spilleren ja (buyoption() er sand), køres Ownable-klassens buylot(player Køber)-metode med player som argument, desuden opdateres result. Hvis grunden derimod ikke er ejet, køres der først et beløbtjek på spilleren med prisen som argument. Er beløb-tjekket sandt, bliver grunden købt og result opdateres. Hvis beløb-tjekket ikke evalueres til sandt, opdateres result med oplysninger om at han ikke har penge til at købe grunden. result bliver til sidst returneret. 17/33

18 tostring()-metoden henviser til tostring()-metoden fra Ownable. Brewery (Paw) Denne klasse nedarver fra Ownable og har desuden leje, som er en private int. Konstruktøren er den samme som konstruktøren fra Ownable-klassen. Da lejen i dette felt også bestemmes af et terninge-kast, opretter vi i denne klasse et MatadorRafleBaegerobjekt, som vi vil bruge til at kaste terningerne. rent(player Lejer, Player Udlejer) kaster først terningerne, ved hjælp af kast(), hvorefter lejen bliver sat til summen, getsum(), gange 100 gange antallet af ejerens bryggerier (funktionen getantalbryggerier(udlejer) fra GameBoard). Til sidst overføres lejen fra Lejer til Udlejer. landonfield(player player)-funktionen opretter først strengen result, som skal returneres til sidst. Herefter tjekkes om grunden er ejet, hvorefter rent(player Lejer, Player Udlejer)-funktionen køres med player og owner som henholdsvis første og andet argument, result opdateres med information om dette. Har grunden derimod ingen ejer (super.owned() evalueres til falsk), tjekkes der først om spilleren har råd til at købe grunden. Hvis han har pengene, spørges han om han ønsker at købe grunden (buyoption() på GameBoardBoundary køres). Svarer spilleren ja (buyoption() er sand), køres Ownable-klassens buylot(player Køber)-metode med player som argument, desuden opdateres result. Hvis grunden derimod ikke er ejet, køres der først et beløbtjek på spilleren med prisen som argument. Er beløb-tjekket sandt, bliver grunden købt og result opdateres. Hvis beløb-tjekket ikke evalueres til sandt, opdateres result med oplysninger om at han ikke har penge til at købe grunden. result bliver til sidst returneret. tostring()-metoden henviser igen til tostring()-metoden fra Ownable. Prison (Paw) Klassen nedarver fra Field og har samme konstruktør som denne klasse. landonfield(player player): Først fængsles spilleren ved at bruge spillerens setjail(boolean værdi) til at sætte jail til at være sand. Herefter køres menuen escapeprison() på GameBoardBoundary, hvor brugeren vælger hvordan han vil prøve at komme ud af fængslet (1: betal 1000, 2: slå to ens med max 3 kast). Der bliver oprettet en streng, status, som angiver at spilleren er i fængsel. Vi opretter herefter en boolesk variabel, bingo, som er falsk til at starte med, denne variabel angiver om spilleren har slået to ens med terningerne. Vi laver så en switch på brugerens valg. I case 1 kører vi først menu(player player), indtil han har penge nok, hvorefter der bliver trukket de 1000, som det koster at købe sig ud. Herefter sættes hans position til fængsels-besøgs-feltet, felt nummer 11, hvorefter der køres en landonfield(player player) på det nye felt. Til sidst opdateres status og spillerens jail-variabel sættes til false. I case 2 køres der en løkke så længe i, som starter på nul, er mindre end 3 og så længe bingo er falsk. I løkken kastes terningerne (funktionen kast() i MatadorRafleBaeger), hvorefter de udskrives. Hvis terningerne er ens, sættes bingo til at være sand, status ændres, hvorefter spillerens position ændres til det felt som spilleren skal rykke hen på (fængsels-besøg plus summen af terningerne). Herefter køres en landonfield på det nye felt, og spillerens jail-variabel sættes til false. Til sidst i landonfield(player player) returneres status. 18/33

19 LuckyCards (Ahmet) Klassen LuckyCards nedarver fra Field, som nedarver samme konstruktør som Field klassen. Vi har valgt at oprette en række af arrays. Det første array cardcategory har vi brugt til at kategorisere kortene fra 1-9. Det andet array cardmoney er et array over kategori 1, som omhandler transaktioner, mellem spilleren og banken, selvom der ikke findes en bank i programmet. Det 3. array cardtext er et array hvor alle kortenes tekst er nedskrevet som strings. Det 4. array cardmovenm er et array hvor spilleren rykker frem til et felt uden at modtage penge når spilleren passerer start. Det 5. array cardmovewm er et array hvor spilleren rykker frem til et felt og spilleren modtager kun penge hvis start feltet passeres. Det 6. array cardmovet er et array hvor spilleren skal rykke 3 felter tilbage. Det 7. array cardmoves er et array hvor spilleren skal rykke frem til nærmeste redderi. Det 8. array cardmoneys er et array hvor spilleren modtager 200 kr. fra hver medspiller. Det 9. array cardprison er ikke implementeret, men det var meningen at det skulle bruges til som et kort spilleren kunne benytte sig af for at komme ud af fængslet. Det 10. array cardhouse er et array hvor spilleren skal betale 800 kr. pr hus spilleren ejer. Det 11. array cardhotel er et array hvor spilleren skal betale 2300 kr. pr hotel spilleren ejer. Det starter med at vi definerer et tilfældig int nr. mellem 1-33 og en int cardcat som afgør hvilket kort som skal vælges. Dette gøres ved at det tilfældige tal udvælges fra arrayet cardcategory. Derefter har vi oprettet en switch på cardcat. Case1 beskriver transaktioner mellem spilleren og banken. Dette Case køres kun hvis cardmoney[nr] er større end nul og derefter udføres en deposite funktionen som vælger beløbet som skal indbetales til spilleren udfra pladsen i arrayet. Ellers hvis cardmoney[nr] er mindre end nul så udføres en withdraw funktion som vælger det beløb som skal trækkes fra spilleren udfra pladsen i arrayet. Case 2 beskriver den måde vi flytter spilleren til et andet felt. Her bruger vi setposition(cardmovenm[nr]) igen bestemmes feltet spilleren skal flyttes over på udfra plasen i arrayet. Herefter køres en funktion landonfield som gør at spilleren lander på feltet og kan købe grunden. Case 3 beskriver hvor man skal betale 800 kr. pr. hus og 2300 kr. pr. hotel. Dette gør vi ved at definere en int totalskat som er pladsen i arrayet cardhouse gange antal huse adderet med pladsen i arrayet cardhotel gange antal hoteller. Og til sidst udføres en withdraw funktion som trækker beløbet fra spilleren. Case 4 beskriver hvor man skal rykke frem til det nærmeste rederi. Dette har vi gjort ved at opdele feltets 4 rederier i 4 intervaller over feltets 40 felter. Vi starter med at definere en int PositionP som giver spillerens aktuelle posion. Derefter tjekker vi om spillerens position ligger i intervallet ]36-6[. Hvis spilleren gør dette så kalder vi funktionen player.setposition(6) som placerer spilleren på felt nummer 6 og efterfølgende en landonfield funktion så spilleren kan købe grunden. Hvis spilleren ikke ligger i dette interval så tjekker vi om spillerens position ligger i intervallet ]6-16[. Hvis spilleren gør dette så kalder vi funktionen player.setposition(16) som placerer spilleren på felt nummer 16 og efterfølgende en landonfield funktion så spilleren kan købe grunden. Hvis heller ikke dette opfyldes, så tjekker vi om spillerens position ligger i intervallet ]16-26[. Hvis spilleren gør dette så kalder vi funktionen player.setposition(26) som placerer spilleren på felt nummer2 6 og efterfølgende en landonfield funktion så spilleren kan købe grunden. Derefter tjekker vi om spillerens position ligger i intervallet ]26-36[. Hvis spilleren gør dette så kalder vi funktionen player.setposition(36) som placerer spilleren på felt nummer 36 og efterfølgende en landonfield funktion så spilleren kan købe grunden. 19/33

20 Case 5 beskriver hvor man skal rykke frem til et felt og hvis start passeres så indkasserer man Vi starter med at finde alle pladser i arrayet cardmovewm som er forskellige fra 0. Derefter tjekker vi om spillerens aktuelle position er større end den plads han ønskes rykket over til, som har en plads i arrayet. Hvis spillerens position er større så kaldes funktionen deposite og spilleren indkasserer 4000 kr. Derefter kaldes funktionerne setposition og landonfield, som placerer spilleren på feltet. Case 6 skulle være over fængselskortet, men dette er ikke implementeret. Case 7 beskriver hvor spilleren skal rykke 3 felter tilbage. Igen tjekker vi om cardmovet[nr] er forskellig fra nul. Vi sikrer os først at denne funktion virker ved felterne 1, 2 og 3, fordi der ellers vil opstå problemer når spilleren skal rykke 3 felter tilbage. Først defineres en int position over spillerens aktuelle positon. Så tjekker vi om spillerens position-3 er mindre 1, hvis ja så sættes position til at være position Hvis spilleren ikke er på felterne 1, 2 og 3 så er det en smule nemmere at få spilleren til at rykke 3 felter tilbage, dette gøres blot ved at benytte funktionen setpostion(position-3) og derefter landonfield. Case 8 skulle være over kortet MatadorLegatet, men dette er ikke implementeret. Case 9 beskriver hvor spilleren modtager 200 kr. fra hver medspiller. Vi starter med at definere en int i som sættes til nul. Så starter en while løkke, som kører så længe i er mindre end længden af spiller arrayet. Derefter indbetaler alle spillere 200 kr. til den pågældende spiller. I alle disse cases kører selvfølgelig også beløbtjek funktionen som tjekker om den pågældende spiller har penge nok til at betale bøder/afgifter osv. Efter Casene er kørt returner vi med en udskrift cardtext. GameBoard (Paw) GameBoard-klassen indeholder vores felter i arrayet felter[], som er af typen Field. Konstruktøren tager ingen argumenter. Desuden har vi metoderne getantalbryggerier(player player) og getantalrederier(player player) der ved hjælp af en while-løkke kører alle felterne i felter[] igennem. Hvis feltet ikke er tomt, tjekker om klassenavnet er lig den klasse man tjekker for (Brewery/Shipping). Hvis feltet er af den pågældende type, tjekker funktionen ved hjælp af feltets owned()-funktion om feltet er ejet af en spiller. Her bliver vi nødt til at typecaste feltet til at være Ownable for at kunne bruge de funktioner der relaterer til ejer. Hvis feltet er ejet, sammenlignes navnet på ejeren med den person som man tjekker for. Er disse navne ens, tælles variablen antalbryggerier/antalrederier én op. Til sidst returneres antallet. gettotalhouses(player player) og gettotalhotels(player player) optæller det antal huse og hoteller en spiller har. Funktionerne fungerer på nogenlunde samme måde som getantalbryggerier(player player) og getantalrederier(player player). En løkke kører altså alle felterne igennem. Løkken tjekker først hvert felt om det er tomt, så om klassen er af typen Street. Hvis den er ejet, tjekker den om ejeren er den samme som argumentets navn (player.getnavn()). Hvis de to navne er ens, sættes variablen feltetshuse til det antal huse der er på grunden. Hvis dette tal er større end 4 bliver tallet sat til nul (da der i dette tilfælde så vil være hotel på grunden). gettotalhouses(player player) returnerer så totalhouses. Den anden funktion 20/33

21 fungerer næsten på samme måde, men sætter variablen feltetshoteller til 1, hvis feltetshuse bliver nulstillet. gettotalhotels(player player) returnerer så til sidst totalhotels i stedet. propertylist(player player): Igen er samme fremgangsmåde brugt til at generere en streng med en oversigt over alle de felter, hvor funktionerne getowner() og player.getnavn() er lig hinanden. Klassen har så en tostring()-metode, som kører en while-løkke, der laver en streng, strengarray, som indeholder informationer om alle felterne. Herefter returneres strengen. Funktionen print() printer klassens tostring(). GameBoardController (Paw) Denne klasse styrer vores spil. Vi har en boolesk variabel, vundet, som angiver om spillet er vundet eller ej. Denne er fra starten af sat til falsk. Desuden har vi en instans af GameBoardet, kaldet Board. Klassen har 4 funktioner: menu(player player), turn(int spillernummer), start() og slut(): menu(player player) Først har vi lavet variablen valg, der er en int, som vi starter med at sætte til 99. Så længe valg er forskellig fra 0 og 1, køres en løkke: GameBoardBoundary ets menuboundary(player player)-funktion kaldes, hvorefter der bliver lavet en switch på valget: Hvis brugeren svarer 1 (Giv turen videre), sker der ikke noget, udover at den springer ud af switch en (kommandoen break). I case 2 bliver der sendt en streng med oplysninger om spillerens saldo til GameBoardBoundary ets printfunktion. case 3 kalder buysellhouse() på GameBoardBoundary, hvorefter vi laver en switch mere på brugerens nye valg (om han vil købe eller sælge huse). Svarer han her ja, bliver der udskrevet en oversigt over hans grunde, hvorefter han med tal skal vælge den grund han vil bygge på. Nu køres der så et par tjek, for at tjekke at han rent faktisk kan købe huse på grunden, hvorefter feltets buyhouse(player player)-funktion kaldes. Hvis han vil sælge huse, sker det samme, bortset fra at buyhouse(player player) erstattes af sellhouse(player player). I case 4 bruges print(string string) til at udskrive en oversigt over grunde ved at tage propertylist(player player) fra GameBoard som argument. case 0 er når spilleren giver op, her sker følgende: Først kaldes givopmenu(string playername) på GameBoardBoundary, hvor spilleren skal bekræfte sit valg. Herefter køres en switch på valget, hvor spillerens plads i arrayet spillere sættes til null, hvis han bekræfter sit valg (hvis han svarer 1). Herefter kaldes funktionen RIP(String playernavn) på GameBoardBoundary. 21/33

22 turn(int spillernummer) Denne funktion giver en spiller en tur. Først køres funktionen presstoroll(string spillernavn) på GameBoardBoundary. Herefter MatadorRafleBaegerets kast() og printøjne()-funktioner som kaster terningerne og udskriver en streng med information om terningernes øjne. Herefter bliver der udskrevet nogle ting med GameBoardBoundary ets print(string string)-funktion: Først det felt som spilleren er landet på, så feltets landonfield(player player)-metode og til sidst feltet en gang mere. Til sidst køres menu(player player). start() Først køres funktionen printascii_matador1() på GameBoardBoundary, som printer vores opstarts-asciilogo. Herefter køres opret()-funktionen på PlayerBoundary, hvor der bliver oprettet spillere. Nu køres spillet som en stor løkke. Løkken kører så længe vundet er lig falsk. I løkken sker følgende: i sættes til 0, hvorefter en ny løkke starter. i bruges her som spillerens nummer i vores spillerarray, spillere, som ligger i PlayerControlleren. Denne løkke kører så længe i er mindre er mindre end antallet af spillere og spillet ikke er vundet. I denne løkke sker følgende: Først tjekkes der om pladsen i arrayet indeholder en spiller (at pladsen ikke er lig med null). Dette fordi at pladsen i arrayet, spillere, sættes til null, når en spiller giver op. Hvis pladsen indeholder en spiller, tjekkes der om spilleren er i fængsel (om getjail() evalueres til sand). Er spilleren i fængsel, køres en landonfield(player player) med spiller nummer i som argument. Herefter udskrives det felt som spilleren er landet på, hvorefter menu(player player) bliver kaldt, igen med spiller nummer i i spillere som argument. Hvis spilleren derimod ikke er i fængsel (getjail() evalueres ikke til sand), køres funktionen turn() og spilleren får mulighed for at kaste osv. Derefter køres en løkke, som giver spilleren en tur mere, turn(), så længe han slår to ens. Inden den inderste løkken afsluttes, tjekker vi om de aktive spillere er mindre end 2, hvis dette er tilfældet, sættes vundet til sand. Til sidst forhøjer vi værdien af i med én. På denne måde kører den inderste løkke altså en runde med hver spiller så længe der ikke er fundet en vinder, mens den ydre løkke bliver ved med at køre runder indtil spillet er vundet. slut() Denne funktion kalder printslut(string vindernavn) på GameBoardBoundary et, med vinderens navn som argument (PlayerController.getWinner().getNavn()). GameBoardBoundary (Ahmet) Klassen GameBoardBoundary har til formål at kommunikere til brugeren, dvs. som en brugergrænseflade. Vi har startet ud med at lave en print funktion, der printer argumentet ud som er String string. Dernæst har vi oprettet en boundary menu, så spilleren kan købe og sælge huse. Dette har vi gjort ved at lave en public static int buysellhouse, hvorefter en string printes ud til spilleren, som bagefter skal returneres som en int 1 eller 2. Den næste metode buyhousemenu() giver spilleren en menu hvor spilleren kan vælg hvilken 22/33

23 grund der skal bygges på hvorefter valget returneres. Der er også blevet implementeret en menu hvor spilleren kan vælge at sælge huse på en bestemt grund, sellhousemenu(). Den næste menu vi har implementeret er en menu til fængsel, og funktionen hedder escapeprison(). Hvor der bliver spurgt hvorvidt spilleren ønsker at komme ud af fængslet. Spilleren får 2 valgmuligheder, hvorefter valget returneres til den klasse der kalder den. Den næste funktion er buyoption(), hvor spilleren bliver spurgt om grunden vil købes, hvorefter en boolean returneres. Dernæst har vi implementeret en menu, så spilleren kan have en række muligheder, såsom at give turen videre, vise saldoen, køb ehuse/hoteller, vise grunde og give op. Her kan man foretage sig en række af ting. Derefter har vi lavet en givopmenu(), som spørger spilleren om personen er helt sikker på at give op. Spilleren afgiver sit svar og valget returneres. Vi har også lavet en funktion printslut(string vindernavn) som udskriver vinderen af spillet og en funktion RIP(String playernavn) som fortæller den pågældende at han/hun er ude af spillet. BCE (Paw) Vi har overholdt BCE-modellen nogenlunde mellem GameBoardBoundary og GameBoardController, men resten af vores system er lidt rodet i forhold til BCE. Vores PlayerController og PlayerBoundary er lidt forkert delt op, og en del af vores entities har adgang direkte til GameBoardBoundary. Vi er klar over at det er dårligt design på denne måde at have forbindelser mellem boundary- og entityobjekter, men det er den måde vi i første omgang lavede det på, og har nu ikke tid til at lave det om. Skulle vi programmere det hele igen, ville vi helt sikkert ikke gøre det på samme måde, da vores kode flere steder kan være lidt svær at overskue, i forhold til de steder hvor det er opdelt efter BCE-modellen. 23/33

24 Design efter programmering (Humira) Use case I vores usecase før programmering havde vi lokaliseret alle de processer som vi forventede at vores system skal indeholde. Men på grund af manglende tid har Vi prioriteret nogle funktioner højere end andre og de funktionere som vi mente var mindst vigtige har vi ikke fået implementeret. De funktioner som vi har implementeret ses i diagrammet ovenover 24/33

25 Designklassediagram (Humira) 25/33

26 Diagrammet ovenover er designklassediagram over hele systemet, der viser interaktion mellem forskellige klasser vha. dependencies, nedarvning og de almindelige associations piller. Udover pillerne får man også overblik over hvilke metoder og attributter indgår i enkelte klasse. Sekvens for at købe grunde (Humira) 1. Gameboardcontrolleren bruger metoden kast() til at kaste terningerne som er i raflebægerklassen. Raflebæger klassen returnerer sum af terninger. 2. Gameboardcontrolleren bruger metoden move() og sum som argument for at rykke på felterne. Gameboardboundary kommunikere med player klassen fordi metoden movi() er lavet i player klassen. 26/33

27 3. Når spiller er rykket de antal felter som terningernes sum viser, så lander de på et af felterne. Gameboardboundary bruger metoden getposition() i player klassen for at få positionen. 4. Gameboardcontroller kør metoden landonfield() og argumentet player typen af Player på det felt som man lander på. 5. Street klassen bruger metoden owned() for at tjekke om der er en ejer af den pågældende felt. 6. Hvis grunden ikke har nogen ejer, så får brugeren mulighed for at købe grunden. Dette sker ved at Street klassen bruger metoden buyoption() som er i Gameboardboundary klassen. 7. Efter at buyoption metoden er kørt, så bruger street klassen buylot metoden for at køre transaktionen. Konstruktion og test (Humira) Vi har valgt at begynde konstruktionen af systemet på baggrund af de udarbejdede diagrammer og overvejelser som vi har gjort i designfasen. Vi blev enige om at vi vil undervejs i udviklingen benytte forskellige teststrategier for at sikre både at kvaliteten af systemet. Hermed sikre brugergrænsefladen og at input svarer overens med det forventede output i systemets dele. Vi tog udgangspunktet i V-modellens strategier. Hvor vi startede med analyse systemets krave, designede systemet vha. nogle diagrammer, implementerede og testede. V-modellens strategi går ud på, at man deler systemet op i fase og efter hver udviklingsfase, planlægger test, der berører den netop afsluttede fase. Man fortsætter derfor ikke til næste fase, før testen er planlagt. På den måde kan vi lave konklusioner efter hver afsluttet fase, og på denne måde mindsker man risikoen for, at senere hen i udviklingsforløbet må tilbage og rette fejl. Som vi har skrevet i afsnit Udviklingsstrategi havde vi tænkt os at implementerer således så den overholder kravet om BCE - modellen. Hvor vi deler systemet op i boundary, controller og entity klasser. Men på grund af manglende tid vi har desværre ikke nået det. Grunden til vi ønskede at overholde BCE i vores system, er at man holder brugergrænseflader(boundary) for sig, de arbejdende klasser(control) for sig, og de databærende klasser (Entity) for sig. På den måde skabes et godt overblik for dem, som ønsker at udvikle videre på systemet og man kan nemt klistre nye entitetsklasser på systemet, uden at ændre resten af systemet. Boundary objekter viser interaktion mellem aktør og systemet. Disse objekter rolle er at adskille systemet fra omgivelser. Controller har dobbelt rolle i systemet: Systemets skraldspand: udfører funktioner som ikke naturligt kan placeres på andre objekter. 27/33

28 Systemets leder: fordeler ansvar på systemets andre objekter og fastlægger sekvensen i udførelse af handlinger. Derudover styrer den use case realisering. Den gør selv ikke noget, men den giver ordre videre til andre objekter om at gør noget. Entity objekter er data lage og er baseret på logik om at sikre korrekte input. Disse objekter rolle er at adskille systemet fra omgivelserne, knytter sig typisk til en aktørs anvendelse af en uses case. når et system skal bygges ud fra BCE kravet, så laver man modeller for udvalgte Use Cases. Dette gør det nemt og overskueligt, og man ser tydeligt hvilke klasser, de enkelte scenarier berører. Vi valgt at prioriterer nogle funktioner højere end andre og de funktionere som vi mente var mindst vigtige har vi ikke fået implementeret. 28/33

29 Test (Michael) Om testene At foretage test af vores system har været kompliceret, især af to forskellige årsager: 1. På grund af den store mængde statiske funktioner der er, hvilket der også er blevet advaret imod 2. Det overordnede design af systemet, mangler at overholde nogen af de grundprincipper fra GRASP, især det om BCE modeller. Vi har lært at enkelte klasser ikke må kende til andre klasser, og i vores tilfælde er klasserne forgrenet på kryds og tværs. Dette har besværliggjort testen af systemet, for du kan ikke isolere metoder og teste dem hver for sig. Og på grund af den høje mængde statiske funktioner kan du ikke debugge dig frem til specifikke scenarier og teste af den vej. Eksempler på nogen af de problemer vi er stødt ind på mht. Test: I en normal test, ville det være hensigtsmæssigt at opstille et skema af en art, hvor du redegør for alle metoder, et input, et forventet resultat(output) og det reelle resultat. Dette meget omfattende stykke arbejde, at teste alle metoder, er som sagt besværliggjort på grund af den høje binding i vores system. Tingene er simpelthen ikke godt nok adskilt, i vores klasser, hvilket pejer på et dårligt design: Et tilfældigt eksempel kunne være vores buyhouse funktion: public void buyhouse(player player) { while(player.beløbtjek(huspris)==false){ GameBoardController.menu(player); } Som man ser allerede i 4 linie, så kalder den en menu fra vores GameBoardController, som gør at vi ikke kan kalde metoden i en eventuel testklasse for at teste at den fungerer som den skal. En evt. Løsning kunne have været at lave en mock GameBoardController lavet til det formål at teste metoderne, men igen er vores system designet på en sådan måde at det ikke er muligt. Test-klassen Vi har fundet en metode, Refuge, der ikke er statisk som vi kan teste i en dertil indrettet testklasse. Testen har 3 faser: Setup, Kørsel af testen og Analyse af resultatet I setup fasen, sætter vi systemet op, det er her objekter der skal bruges oprettes og variablerne sættes, eller sagt på en anden måde bestemmer vi input her. //setup 29/33

30 int expectedsaldo = ; Refuge testrefuge = new Refuge(1, "ko", 200); Player p1 = new Player(); Så køres testen og i sidste del sammenligner vi resultatet med det resultat vi forventer. //check result if (expectedsaldo == p1.getsaldo()) System.out.println("Succes"); else System.out.println("fail"); System.out.println("expected Saldo = " + expectedsaldo + " aktuel saldo = " + p1.getsaldo() ); Kopieret fra konsollen efter at have kørt programmet: Succes expected Saldo = aktuel saldo = Altså kan vi se at denne konkrete klasse virker som de skal Manuel test Af denne grund er størstedelen af testen af systemet foregået med personlig betjening. Dette kan gøres på to måder. Den ene måde er at starte et spil matador og bare køre spillet indtil du tilfældigvis rammer det scenarie du ønsker skal udspilles, og så være undersøge om metoden har kørt korrekt(passer saldoen på kontoen, betaler man den rette husleje afhængig af byggede huse på grunden osv.) Denne måde er langt fra optimal, men størstedelen af programmet er dog blevet testet på denne måde. Den anden måde er at køre programmet i debug og så skridt for skridt se hvordan systemet reagerer ved at køre det igennem. Til denne type test er det igen en hindring at vi har så mange statiske metoder, fordi så kan vi ikke tilgå variablerne manuelt og sætte dem til det vi selv ønsker, men til gengæld kan du se hvad der foregår inde i systemet. Vi har testet hvad vi føler er nogen af de essentielle funktioner for at vise princippet i denne type af test også: Test af prisonklassen: Her har vi foretaget en test af prisonklassen for at kontrollere den virker ordentligt. Vi har sat en spiller til at gå i fængsel, og vil betale os ud af fængslet. Vi kontrollerer så om den trækker penge, rykker spillerens position korrekt, printer de rigtige meddelelser osv. 30/33

DANMARKS TEKNISKE UNIVERSITET

DANMARKS TEKNISKE UNIVERSITET DANMARKS TEKNISKE UNIVERSITET Skriftlig prøve, 14. december 2018, 4 timer Side 1 af 18 Kursus navn: 02101 Indledende Programmering Kursus : 02101 Tilladte hjælpemidler: Ikke-digitale skriftlige hjælpemidler

Læs mere

Matador. Hvert hus koster: 2000 Et hotel koster: 2000 + 4 huse Pantsætningsværdien er 2000 kr.

Matador. Hvert hus koster: 2000 Et hotel koster: 2000 + 4 huse Pantsætningsværdien er 2000 kr. Matador Problembeskrivelse Matador består af en spilleplade med 40 felter, biler (som udgør spillebrikker), to terninger, huse, hoteller, lykkekort, pengesedler og skødekort. Hvert felt har et nummer og

Læs mere

Kursus i OOP og Java. Kursus i Objektorienteret programmering i Java

Kursus i OOP og Java. Kursus i Objektorienteret programmering i Java Kursus i OOP og Java Kursus i Objektorienteret programmering i Java Åben Dokumentlicens Dette foredragsmateriale er under Åben Dokumentlicens (ÅDL) Du har derfor lov til frit at kopiere dette værk Bruger

Læs mere

//Udskriver System.out.println("Hej " + ditfornavn + " " + ditefternavn + "."); System.out.println("Du er " + dinalder + " aar gammel!

//Udskriver System.out.println(Hej  + ditfornavn +   + ditefternavn + .); System.out.println(Du er  + dinalder +  aar gammel! Denne guide er oprindeligt udgivet på Eksperten.dk Brugerinput i Java Denne her artikel gennemgår diverse ting ved brug af brugerinput i Java. Den starter med det simple og fortæller derefter skridt for

Læs mere

SPIL HURTIGERE MONOPOLY PÅ TID

SPIL HURTIGERE MONOPOLY PÅ TID SPIL HURTIGERE BRAND Hvis du kender MONOPOLY og vil spille lidt hurtigere: 1. Start med, at bankøren blander ejendomskortene og giver 2 til hver spiller. Spillerne betaler med det samme prisen for ejendommene,

Læs mere

Forelæsning Uge 2 Torsdag

Forelæsning Uge 2 Torsdag Forelæsning Uge 2 Torsdag Niveauer af programbeskrivelser Statiske / dynamiske beskrivelser Klassevariabler og klassemetoder Variabler og metoder der et tilknyttet klassen (i stedet for at være tilknyttet

Læs mere

DRONNINGER (QUEENS) Opgave 1

DRONNINGER (QUEENS) Opgave 1 DRONNINGER (QUEENS) I denne opgave vil vi beskæftige os med det såkaldte 8-dronningeproblem, hvor man skal placerede 8 dronninger på et 8 x 8 skakbræt, således at ingen af dronningerne kan slå hinanden.

Læs mere

Lavet af Danni jensen og David Olsen

Lavet af Danni jensen og David Olsen Projekt Delfin Lavet af Danni jensen og David Olsen 19/5-2008 Indholdsfortegnelse. Side 1: Indholdsfortegnelse og forord. Side 2: Kravsliste. Side 3: Use Case Model. Side 4: Formandens aktørbeskrivelse

Læs mere

University of Southern Denmark Syddansk Universitet. DM502 Forelæsning 4

University of Southern Denmark Syddansk Universitet. DM502 Forelæsning 4 DM502 Forelæsning 4 Flere kontrolstrukturer for-løkke switch-case Metoder Indhold Arrays og sortering af arrays String-funktioner for-løkke Ofte har man brug for at udføre det samme kode, for en sekvens

Læs mere

www.hasbro.dk www.monopoly.co.uk

www.hasbro.dk www.monopoly.co.uk THE SIMPSONS & 2007 Twentieth Century Fox Film Corporation. All rights reserved. Distribueret i Norden af Hasbro Nordic, Ejby Industrivej 40, 2600 Glostrup. Made in Ireland www.hasbro.dk www.monopoly.co.uk

Læs mere

At klippe en streng over på det mest hensigtsmæssige sted

At klippe en streng over på det mest hensigtsmæssige sted Denne guide er oprindeligt udgivet på Eksperten.dk At klippe en streng over på det mest hensigtsmæssige sted Formålet med denne artikel er at kaste lidt lys over, hvordan man klipper en streng over på

Læs mere

Indledning. Hvorfor det forholder sig sådan har jeg en masse idéer om, men det bliver for meget at komme ind på her. God fornøjelse med læsningen.

Indledning. Hvorfor det forholder sig sådan har jeg en masse idéer om, men det bliver for meget at komme ind på her. God fornøjelse med læsningen. Indledning...2 Variabler...13 Eksempel: 1...13 Eksempel 2:...13 Eksempel 3:...15 Eksempel 4:...16 Metoder...17 Metode (intet ind og intet ud)...17 Metode (tekst ind)...18 Metode (tekst ind og tekst ud)...19

Læs mere

Hvad er Objekter - Programmering

Hvad er Objekter - Programmering Denne guide er oprindeligt udgivet på Eksperten.dk Hvad er Objekter - Programmering En rigtig god gennemgang af hvad objekter er! Hvordan de oprettes og anvendes! Det er helt klart til nybegyndere, som

Læs mere

2-6 SPILLERE. FORMÅL MED SPILLET At blive sidste spiller tilbage, efter at alle andre er gået bankerot.

2-6 SPILLERE. FORMÅL MED SPILLET At blive sidste spiller tilbage, efter at alle andre er gået bankerot. Hvis du kender Monopoly og vil spille lidt hurtigere: 1. Start med, at bankøren blander ejendomskortene og giver to til hver spiller. Spillerne betaler med det samme prisen for grundene, de modtager, til

Læs mere

Det sande Matador ( af Jonas Jensen, Gode Penge)

Det sande Matador ( af Jonas Jensen, Gode Penge) Det sande Matador ( af Jonas Jensen, Gode Penge) Regler: 3-4 spillere, 4 spillere er optimalt. Spilles kun 3 spillere fjernes rollen Den fornuftige Spilles på et matadorbræt med regler som i matador, hvis

Læs mere

Ugeseddel 4 1. marts - 8. marts

Ugeseddel 4 1. marts - 8. marts Ugeseddel 4 1. marts - 8. marts Læs følgende sider i kapitel 6 i lærebogen: s. 233 258 og s. 291 317 (afsnit 6.3 overspringes). Begynd at overveje, hvad afleveringsopgaven skal omhandle. Læs vejledningen,

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2018 Projekt, del II Institut for matematik og datalogi Syddansk Universitet 13. marts, 2018 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Opgaven fortsat. Opfølgning på Opgave 2 og Use Cases. Opgaven. Trin 1: Væsentlige begreber. Resultatliste: 100 bryst, herrer

Opgaven fortsat. Opfølgning på Opgave 2 og Use Cases. Opgaven. Trin 1: Væsentlige begreber. Resultatliste: 100 bryst, herrer Opfølgning på Opgave 2 og Use Cases originally by Michael R. Hansen modified/extended by Anne E. Haxthausen Informatics and Mathematical Modelling Technical University of Denmark Opgaven fortsat Efter

Læs mere

Programmering for begyndere Lektion 2. Opsamling mm

Programmering for begyndere Lektion 2. Opsamling mm Lektion 2 Opsamling mm God tone Der er indlagt spørge sessioner Lektion 2 - Agenda Programmering for Lidt ændringer til teknikken, herunder hvordan du genser en lektion Lidt generelle tilbagemeldinger

Læs mere

Kontrol-strukturer i PHP

Kontrol-strukturer i PHP Denne guide er oprindeligt udgivet på Eksperten.dk Kontrol-strukturer i PHP Denne artikel gennemgår kontrolstrukturer i PHP. 'if', 'switch', 'while' og 'for' bliver gennemgået. Den forudsætter lidt grundlæggende

Læs mere

Algoritmeskabeloner: Sweep- og søgealgoritmer C#-version

Algoritmeskabeloner: Sweep- og søgealgoritmer C#-version Note til Programmeringsteknologi Akademiuddannelsen i Informationsteknologi Algoritmeskabeloner: Sweep- og søgealgoritmer C#-version Finn Nordbjerg 1/9 Indledning I det følgende introduceres et par abstrakte

Læs mere

SWC eksamens-spørgsmål. Oversigt

SWC eksamens-spørgsmål. Oversigt SWC eksamens-spørgsmål Oversigt #1 Typer og variable #2 Aritmetik og logik #3 Klasser (definition, objekter) #4 Klasser (metoder) #5 Klasser (nedarvning, polymorfi) #6 Conditional statements #7 Repetition

Læs mere

Forelæsning Uge 2 Mandag

Forelæsning Uge 2 Mandag Forelæsning Uge 2 Mandag Sætninger Simple sætninger (assignment, interne og eksterne metodekald) Sammensatte sætninger (blok, selektion, gentagelse) Udtryk og operatorer Java syntax og style guide Afleveringsopgave:

Læs mere

Forelæsning Uge 2 Torsdag

Forelæsning Uge 2 Torsdag Forelæsning Uge 2 Torsdag Niveauer af programbeskrivelser Statiske / dynamiske beskrivelser Klassevariabler og klassemetoder Variabler og metoder der et tilknyttet klassen (i stedet for at være tilknyttet

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2018 Projekt, del II Institut for matematik og datalogi Syddansk Universitet 20. marts, 2019 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

class Time { int hours, min; } } Time t1; // Erklær variabel af type Time class Time1 { public static void main(string[] args) { Time t1; t1.

class Time { int hours, min; } } Time t1; // Erklær variabel af type Time class Time1 { public static void main(string[] args) { Time t1; t1. Programmering 1999 Forelæsning 4, fredag 10. september 1999 Klasser og objekter Felter, konstruktorer, this Eksempler på klasser: Time, Appointment Eksempler på metoder i Time og Appointment Klassefelter:

Læs mere

Klasse 1.4 Michael Jokil 03-05-2010

Klasse 1.4 Michael Jokil 03-05-2010 HTX I ROSKILDE Afsluttende opgave Kommunikation og IT Klasse 1.4 Michael Jokil 03-05-2010 Indholdsfortegnelse Indledning... 3 Formål... 3 Planlægning... 4 Kommunikationsplan... 4 Kanylemodellen... 4 Teknisk

Læs mere

Forelæsning Uge 2 Torsdag

Forelæsning Uge 2 Torsdag Forelæsning Uge 2 Torsdag Niveauer af programbeskrivelser Statiske / dynamiske beskrivelser Klassevariabler og klassemetoder Variabler og metoder der et tilknyttet klassen (i stedet for at være tilknyttet

Læs mere

Kapitel 4 Løkker i C#

Kapitel 4 Løkker i C# Kapitel 4 Løkker i C# Løkker en vigtig del af alle programmeringssprog, og C# er ikke andeles. En løkke er en måde at udføre en del af koden gentagne gange. Ideen er at du fortsætter med at udføre en opgave

Læs mere

Software Dokumentation

Software Dokumentation Software Dokumentation Jan Boddum Larsen Teknologi B og A på HTX Dokumentation af software i Teknologi I samfundet sker der en bevægelse mod mere digitale løsninger i teknologi. Det betyder at software

Læs mere

Eksempel: et ordresystem note 5 Lagdeling s. 1

Eksempel: et ordresystem note 5 Lagdeling s. 1 Eksempel: et ordresystem note 5 Lagdeling s. 1 Eksempel: et ordre-system NiceHair er et firma, som sælger udstyr, inventar og frisørartikler til frisørsaloner over hele landet. Det er ejet af et ægtepar

Læs mere

Abstrakte datatyper C#-version

Abstrakte datatyper C#-version Note til Programmeringsteknologi Akademiuddannelsen i Informationsteknologi Abstrakte datatyper C#-version Finn Nordbjerg 1/9 Abstrakte Datatyper Denne note introducerer kort begrebet abstrakt datatype

Læs mere

DM01 DM01. 3. Obl. Afl. Jacob Christiansen, 130282, jacob.ch@mail.tdcadsl.dk. D12, Elias 18/3-2003. Side 1 af 11

DM01 DM01. 3. Obl. Afl. Jacob Christiansen, 130282, jacob.ch@mail.tdcadsl.dk. D12, Elias 18/3-2003. Side 1 af 11 DM01 DM01 3. Obl. Afl. Jacob Christiansen, 130282, jacob.ch@mail.tdcadsl.dk D12, Elias 18/3-2003 Side 1 af 11 DM01 Indholdsfortegnelse: BILAG:...2 1 FORMÅL:...3 2 KLASSER:...4 2.1 DILEMMA:...4 2.1.1 METODER:...4

Læs mere

Kapitel 3 Betinget logik i C#

Kapitel 3 Betinget logik i C# Kapitel 3 i C# er udelukkende et spørgsmål om ordet IF. Det er faktisk umuligt at programmere effektivt uden at gøre brug af IF. Du kan skrive små simple programmer. Men når det bliver mere kompliceret

Læs mere

SPIL HURTIGERE MONOPOLY PÅ TID

SPIL HURTIGERE MONOPOLY PÅ TID SPIL HURTIGERE Hvis du kender MONOPOLY og vil spille lidt hurtigere: Start med, at bankøren blander ejendomskortene og giver 2 til hver spiller Spillerne betaler med det samme prisen for de ejendomme,

Læs mere

Løsning af møntproblemet

Løsning af møntproblemet Løsning af møntproblemet Keld Helsgaun RUC, oktober 1999 Antag at tilstandene i problemet (stillingerne) er repræsenteret ved objekter af klassen State. Vi kan da finde en kortest mulig løsning af problemet

Læs mere

University of Southern Denmark Syddansk Universitet. DM502 Forelæsning 2

University of Southern Denmark Syddansk Universitet. DM502 Forelæsning 2 DM502 Forelæsning 2 Repetition Kompilere og køre Java program javac HelloWorld.java java HeloWorld.java Debugge Java program javac -g HelloWorld.java jswat Det basale Java program public class HelloWorld

Læs mere

Kursusarbejde 3 Grundlæggende Programmering

Kursusarbejde 3 Grundlæggende Programmering Kursusarbejde 3 Grundlæggende Programmering Arne Jørgensen, 300473-2919 klasse dm032-1a 21. november 2003 Indhold 1. Kode 2 1.1. forestillinger.h............................................. 2 1.2. forestillinger.cc.............................................

Læs mere

5. OPSÆTNING DOKUMENTSKABELONER 5.1 TRIN

5. OPSÆTNING DOKUMENTSKABELONER 5.1 TRIN 5. OPSÆTNING DOKUMENTSKABELONER Under fanen Dok. skabeloner kan du arbejde med de skabeloner som du har i systemet, eller du kan oprette nye. I denne vejledning kigger vi på hvordan du kan tilrette selve

Læs mere

b) Udvid din implementation af forme til at understøtte.equals. To objekter af samme form er ens hvis de har samme værdier i felterne.

b) Udvid din implementation af forme til at understøtte.equals. To objekter af samme form er ens hvis de har samme værdier i felterne. Exercise 1: Opgave 9.1 på CodeJudge. a) Lav klasserne Cirkel, Rektangel og Kvadrat, som implementerer vedhæftede interface From.java (se CodeJudge). Lav Rektangel før du laver Kvadrat. Kan du bruge nedarvning

Læs mere

Indholdsfortegnelse for kapitel 2

Indholdsfortegnelse for kapitel 2 Indholdsfortegnelse for kapitel 2 Kapitel 2. Analyse.......................................................... 2 Analyse af 2.1...................................................... 2 Analysen af Database.................................................

Læs mere

Forelæsning Uge 2 Mandag

Forelæsning Uge 2 Mandag Forelæsning Uge 2 Mandag Objekters tilstand og opførsel BlueJ og Greenfoot Java Skabelse af objekter (via new-operatoren) Iteration (gentagelser) og parametrisering Forskellige slags variabler Afleveringsopgave:

Læs mere

Skriftlig eksamen i Datalogi

Skriftlig eksamen i Datalogi Roskilde Universitetscenter side 1 af 11 sider Skriftlig eksamen i Datalogi Modul 1 Sommer 2000 Opgavesættet består af 6 opgaver, der ved bedømmelsen tillægges følgende vægte: Opgave 1 10% Opgave 2 10%

Læs mere

Forelæsning Uge 2 Torsdag

Forelæsning Uge 2 Torsdag Forelæsning Uge 2 Torsdag Java syntax og style guide Sætninger Simple sætninger (assignment, interne og eksterne metodekald) Sammensatte sætninger (blok, selektion, gentagelse) Udtryk og operatorer Brug

Læs mere

Fable Kom godt i gang

Fable Kom godt i gang Fable Kom godt i gang Vers. 1.3.1 Opdateret: 29-08-2018 Indholdsfortegnelse 1. Installer programmet 3 2. Pak robotten ud 5 3. I gang med at programmere 6 4. Programmér Fable til at køre fra 90 til -90

Læs mere

OPBEVARING. INDHOLD: 1 spillebræt, 1 spilenhed, 6 MONOPOLY-bankkort, 6 brikker, 30 ejendomskort, 32 huse, 12 hoteller og 2 terninger.

OPBEVARING. INDHOLD: 1 spillebræt, 1 spilenhed, 6 MONOPOLY-bankkort, 6 brikker, 30 ejendomskort, 32 huse, 12 hoteller og 2 terninger. ALDER 8+ OPBEVARING 2-6 SPILLERE. Læg de 6 brikker i de særlige åbninger i bankørens bakke, så de ikke bliver ridset. 2. Vent på, at spilenheden slukker automatisk (den går i dvale, når den ikke har været

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2016 Projekt, del I Institut for matematik og datalogi Syddansk Universitet 29. februar, 2016 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Miniguide Wellnessbox Medarbejderversion 2.0

Miniguide Wellnessbox Medarbejderversion 2.0 Miniguide Wellnessbox Medarbejderversion 2.0 Indholdsfortegnelse 1. Wellnessbox HOVEDMENU 2. Wellnessbox hjælpepunkter og hovedmenu 3. KASSE: Åbn kassen 4. KASSE: Luk kassen 5. KASSE: Sælg vare 6. KASSE:

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2019 Projekt, del I Institut for matematik og datalogi Syddansk Universitet 27. februar, 2019 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Forelæsning Uge 3 Mandag

Forelæsning Uge 3 Mandag Forelæsning Uge 3 Mandag Niveauer af programbeskrivelser Statiske / dynamiske beskrivelser ArrayList Collection med variabelt antal elementer Der er mange andre Collection typer (se Collection interfacet

Læs mere

Dokumentation af programmering i Python 2.75

Dokumentation af programmering i Python 2.75 Dokumentation af programmering i Python 2.75 Af: Alexander Bergendorff Jeg vil i dette dokument, dokumentere det arbejde jeg har lavet i løbet opstarts forløbet i Programmering C. Jeg vil forsøge, så vidt

Læs mere

Spilstrategier. 1 Vindermængde og tabermængde

Spilstrategier. 1 Vindermængde og tabermængde Spilstrategier De spiltyper vi skal se på her, er primært spil af følgende type: Spil der spilles af to spillere A og B som skiftes til at trække, A starter, og hvis man ikke kan trække har man tabt. Der

Læs mere

AAU, Programmering i Java Intern skriftlig prøve 18. maj 2007

AAU, Programmering i Java Intern skriftlig prøve 18. maj 2007 AAU, Programmering i Java Intern skriftlig prøve 18. maj 2007 Opgavebesvarelsen skal afleveres som enten en printerudskrift eller som et passende dokument sendt via email til fjj@noea.dk. Besvarelsen skal

Læs mere

Dm071 / Dm072 - Obligatorisk projekt 3: Design af model

Dm071 / Dm072 - Obligatorisk projekt 3: Design af model Dm071 / Dm072 - Obligatorisk projekt 3: Design af model Fag: Projektet omhandler emner fra fagene Software Design og Software Konstruktion. Formål: Formålet med projektet er at give dig mulighed for sammen

Læs mere

Listen over reserverede ord er meget lang, men de væsentligste vil jeg beskrive her i denne artikel:

Listen over reserverede ord er meget lang, men de væsentligste vil jeg beskrive her i denne artikel: Denne guide er oprindeligt udgivet på Eksperten.dk SQL og ASP En artikel omkring simpel SQL og hvordan disse opbygges, udformes og udføres, sådan at man kan få et brugbart resultat i ASP. Dette ligefra

Læs mere

Skriftlig eksamen i Datalogi

Skriftlig eksamen i Datalogi Roskilde Universitetscenter side 1 af 9 sider Skriftlig eksamen i Datalogi Modul 1 Vinter 1999/2000 Opgavesættet består af 6 opgaver, der ved bedømmelsen tillægges følgende vægte: Opgave 1 5% Opgave 2

Læs mere

Fable Kom godt i gang

Fable Kom godt i gang Fable Kom godt i gang Opdateret: 26-03-2018 Indholdsfortegnelse 1. Først skal du installere programmet på din computer 3 2. Når programmet er installeret er du klar til at pakke robotten ud 4 3. Nu er

Læs mere

Noter til C# Programmering Iteration

Noter til C# Programmering Iteration Noter til C# Programmering Iteration Programflow Programmer udfører det meste af deres arbejde vha. forgrening og løkker. Løkker Mange programmeringsproblemer kan løses ved at gentage en handling på de

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

Ide med Diff. Mål. Tidsplan. 1.uge: 2.uge:

Ide med Diff. Mål. Tidsplan. 1.uge: 2.uge: Side 1 af 5 Ide med Diff. Min ide med differenertierings modulet er at lave et program som kan vise 3d objekter, og få lavede en konverter som kan konventer 3ds filer over til noget som flash kan bruge.

Læs mere

Indhold. Side 2 af 26

Indhold. Side 2 af 26 Tema Design Design, Programmering og test af Adressebog Fra d. 17 april til 20 april 2012 Vejledere: Gunhild Marie Andersen Kis Boisen Hansen Gruppe B Deltagere Side 1 af 26 Indhold Indledning.... 3 Kodestandard...

Læs mere

En liste, hvor der kun kan angives et svar. En dropdown menu, hvori kun et svar kan vælges

En liste, hvor der kun kan angives et svar. En dropdown menu, hvori kun et svar kan vælges Huskeseddel til uv-evaluering 1. Sådan oprettes en undersøgelse Klik på ikonet Surveys og dernæst det grønne plus Ny undersøgelse. Navngiv din undersøgelse og vælg under Basic options, om der skal være

Læs mere

Roskilde Amatør Matador klub Regler for sæsonen

Roskilde Amatør Matador klub Regler for sæsonen Roskilde Amatør Matador klub Regler for sæsonen 2017-2018 1 Om disse regler 1.1 Reglerne er en præcisering og et tillæg til de gængse matadorregler. Såfremt en af nedenstående paragraffer i modstrid med

Læs mere

2-6 SPILLERE. Superheltespillet, hvor du handler med ejendomme. www.hasbro.dk

2-6 SPILLERE. Superheltespillet, hvor du handler med ejendomme. www.hasbro.dk Superheltespillet, hvor du handler med ejendomme Spider-Man og alle relaterede figurer: TM & 2007 Marvel Characters, Inc. Spider-Man-filmelementer: 2002-2007 Columbia Pictures Industries, Inc. Alle rettigheder

Læs mere

PHP Snippets. De små korte. Skrevet af Daniel Pedersen

PHP Snippets. De små korte. Skrevet af Daniel Pedersen PHP Snippets De små korte Skrevet af Daniel Pedersen Indhold PHP Snippets De små korte er en samling af små og praktiske kode eksempler med kort forklaring, som med formål at kunne benyttes til opsalgsværk

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2013 Projekt, del I Institut for matematik og datalogi Syddansk Universitet 5. marts, 2013 Dette projekt udleveres i to dele. Hver del har sin deadline, således

Læs mere

Introduktion til funktioner, moduler og scopes i Python

Introduktion til funktioner, moduler og scopes i Python Denne guide er oprindeligt udgivet på Eksperten.dk Introduktion til funktioner, moduler og scopes i Python Denne artikel er fortsættelsen af "I gang med Python", som blevet publiceret her på sitet for

Læs mere

Programmering C RTG - 3.3 09-02-2015

Programmering C RTG - 3.3 09-02-2015 Indholdsfortegnelse Formål... 2 Opgave formulering... 2 Krav til dokumentation af programmer... 3 ASCII tabel... 4 Værktøjer... 5 Versioner af ASCII tabel... 6 v1.9... 6 Problemer og mangler... 6 v2.1...

Læs mere

Michael Jokil 11-05-2012

Michael Jokil 11-05-2012 HTX, RTG Det skrå kast Informationsteknologi B Michael Jokil 11-05-2012 Indholdsfortegnelse Indledning... 3 Teori... 3 Kravspecifikationer... 4 Design... 4 Funktionalitet... 4 Brugerflade... 4 Implementering...

Læs mere

Forelæsning Uge 4 Mandag

Forelæsning Uge 4 Mandag Forelæsning Uge 4 Mandag Algoritmeskabeloner Kan (ved simple tilretningerne) bruges til at implementere metoder, der gennemsøger en arrayliste (eller anden objektsamling) og finder objekter, der opfylder

Læs mere

Assignment #5 Toolbox Contract

Assignment #5 Toolbox Contract Assignment #5 Toolbox Contract Created by: René Kragh Trine Randløv E mail address cph rk70@cphbusiness.dk 23 11 2014 1 Introduktion Dette dokument indeholder en vertikal kontrakt for et system som skal

Læs mere

Projekt - Visual Basic for Applications N på stribe

Projekt - Visual Basic for Applications N på stribe Projekt - Visual Basic for Applications N på stribe Mikkel Kaas og Troels Henriksen - 03x 3. november 2005 1 Introduktion Spillet tager udgangspunkt i det gamle kendte 4 på stribe, dog med den ændring,

Læs mere

Vejledning til. DUI-LEG og VIRKEs

Vejledning til. DUI-LEG og VIRKEs Vejledning til DUI-LEG og VIRKEs Medlemssystem version 1.0 Opdateret 1. november 2009 Indholdsfortegnelse Sådan får du en kode til systemet...3 Sådan logger du ind på systemet...3 Forsiden og ændring af

Læs mere

Vejledning til Kilometer Registrering

Vejledning til Kilometer Registrering Vejledning til Kilometer Registrering iphone Appen som holder styr på dit firma og privat kørsel. Udviklet af Trisect Development 2011. www.trisect.dk For iphone version 4.2 og nyere. Med Kilometer Registrering

Læs mere

Skak, backgammon & dam

Skak, backgammon & dam Skak, backgammon & dam da Spillevejledning Varenummer: 349 582 Made exclusively for: Tchibo GmbH, Überseering 18, 22297 Hamburg, Germany www.tchibo.dk Tchibo GmbH D-22290 Hamburg 92630AB6X6VII 2017-07

Læs mere

ViKoSys. Virksomheds Kontakt System

ViKoSys. Virksomheds Kontakt System ViKoSys Virksomheds Kontakt System 1 Hvad er det? Virksomheds Kontakt System er udviklet som et hjælpeværkstøj til iværksættere og andre virksomheder som gerne vil have et værktøj hvor de kan finde og

Læs mere

Python 3 kursus lektion 1:

Python 3 kursus lektion 1: Python 3 kursus lektion 1: Her laves et nyt program Her køre programmet! Her skrives koden: Gem (CTRL-s) Tryk F5 (for at køre) www.madsmatik.dk d.14-01-2016 1/5 At skrive til skærmen: Hello World Man kan

Læs mere

Mircobit Kursus Lektion 3 (Du skal her vælge Lets Code Og nederst Microsoft Block Editor.)

Mircobit Kursus Lektion 3   (Du skal her vælge Lets Code Og nederst Microsoft Block Editor.) Mircobit Kursus Lektion 3 http://microbit.org/ (Du skal her vælge Lets Code Og nederst Microsoft Block Editor.) I sidste lektion var der en opgave man selv skulle prøve at løse. Man skulle lave et tabel

Læs mere

Regnetest B: Praktisk regning. Træn og Test. Niveau: 9. klasse. Med brug af lommeregner

Regnetest B: Praktisk regning. Træn og Test. Niveau: 9. klasse. Med brug af lommeregner Regnetest B: Praktisk regning Træn og Test Niveau: 9. klasse Med brug af lommeregner 1 INFA-Matematik: Informatik i matematikundervisningen Et delprojekt under INFA: Informatik i skolens fag Et forskningsprogram

Læs mere

Roskilde Amatør Matador klub Regler for sæsonen 2014-2015

Roskilde Amatør Matador klub Regler for sæsonen 2014-2015 1 Om disse regler Roskilde Amatør Matador klub Regler for sæsonen 2014-2015 1.1 Reglerne er en præcisering og et tillæg til de gængse matadorregler. Såfremt en af nedenstående paragraffer i modstrid med

Læs mere

Bemærk! Et PHP script har kun brug for at forbinde én gang til databaseserveren. Det kan så sagtens udføre flere kommandoer vha. denne forbindelse.

Bemærk! Et PHP script har kun brug for at forbinde én gang til databaseserveren. Det kan så sagtens udføre flere kommandoer vha. denne forbindelse. Mysqli Webintegrator Når vi arbejder med server-side scripting ( i vort tilfælde PHP), har vi ofte behov for at kunne tilgå data, som vi opbevarer i en database. Det kan f.eks. dreje sig om nyhederne i

Læs mere

Java Klasse nedarvninger

Java Klasse nedarvninger Denne guide er oprindeligt udgivet på Eksperten.dk Java Klasse nedarvninger Et let lille overblik i hvordan klasse nedarvning virker i java Skrevet den 07. dec 2011 af mochners I kategorien Programmering

Læs mere

Specialiseringen Rapport Lavede Af Rasmus R. Sørensen Side 1 af 6

Specialiseringen Rapport Lavede Af Rasmus R. Sørensen Side 1 af 6 Side 1 af 6 Indholdsfortegnelse INDHOLDSFORTEGNELSE 1 INTRO 3 STARTEN AF SPECIALISERINGEN 3 ANKOMST TIL SKOTLAND 4 DATABASER 5 NETVÆRK 5 INTERAKTION 5 AFSLUTNING AF SPECIALISERINGEN 5 KONKLUSION 6 Side

Læs mere

Python programmering. Per Tøfting. MacFest

Python programmering. Per Tøfting. MacFest Python programmering MacFest 2005 Per Tøfting http://pertoefting.dk/macfest/ Indhold Måder at afvikle Python program på Variabler Data typer Tal Sekvenser Strenge Tupler Lister Dictionaries Kontrolstrukturer

Læs mere

Spil Master Mind. Indledning.

Spil Master Mind. Indledning. side 1 af 16 Indledning. Spillet som denne rapport beskriver, indgår i et større program, der er lavet som projekt i valgfaget programmering C på HTX i perioden 9/11-98 til 12/1-99. Spillet skal give de

Læs mere

Greenfoot En kort introduktion til Programmering og Objekt-Orientering

Greenfoot En kort introduktion til Programmering og Objekt-Orientering Greenfoot En kort introduktion til Programmering og Objekt-Orientering Greenfoot er et computer-program, som kan benyttes til at skrive andre computer-programmer, i et programmeringssprog kaldet Java.

Læs mere

Forelæsning Uge 5 Mandag

Forelæsning Uge 5 Mandag Forelæsning Uge 5 Mandag Algoritmeskabeloner findone, findall, findnoof, findsumof (sidste mandag) findbest Brug af klassen Collections og interfacet Comparable BlueJ s Debugger Nyttig til at inspicere

Læs mere

Forelæsning Uge 2 Mandag

Forelæsning Uge 2 Mandag Forelæsning Uge 2 Mandag Sætninger Simple sætninger (assignment, interne og eksterne metodekald) Sammensatte sætninger (blok, selektion, gentagelse) Udtryk og operatorer Java syntax og style guide Afleveringsopgave:

Læs mere

01.03.2013. ectrl Fritekstfaktura

01.03.2013. ectrl Fritekstfaktura 01.03.2013 ectrl Fritekstfaktura Indholdsfortegnelse 1. Oprettelse af fritekstfaktura 3 2. Standardtekster 4 3. Udvidet fritekstfaktura 6 Udvidede funktioner på fakturahovedet 6 Linjeskabelon (udvidet

Læs mere

Programmering 1999 KVL Side 5-4. Klassen Time: metoder. Metoder i objektet giver mulighed for at ændre tilstanden, eller kigge på tilstanden.

Programmering 1999 KVL Side 5-4. Klassen Time: metoder. Metoder i objektet giver mulighed for at ændre tilstanden, eller kigge på tilstanden. Programmering 1999 Forelæsning 5, tirsdag 14. september 1999 Oversigt Mere om klasser og objekter Klassefelter: static Konstante felter: final Indkapsling og synlighed: private og public Overlæsning af

Læs mere

Løsningsforslag til Camp Let. Case Beskrivelse: Camp Let

Løsningsforslag til Camp Let. Case Beskrivelse: Camp Let Løsningsforslag til Camp Let Case Beskrivelse: Camp Let Firmaet Camp Let har til formål at udleje forskellige typer transportable ferieboliger. Det drejer sig i øjeblikket om campingbusser, campingvogne,

Læs mere

Noter til KAP HORN programmer den 23 januar 2006

Noter til KAP HORN programmer den 23 januar 2006 Noter til KAP HORN programmer den 23 januar 2006 Nyeste tiltag med KAP HORN programmer version 5.0.2: 1. Momsangivelsen er blevet udvidet med nye systemkonti 2. Speciel eksport af Finansrapporter 3. CRM

Læs mere

I denne artikel, vil der blive gennemgået de grundlæggende PHP-funktioner, såsom udskrift til skærmen, tid og dato og if-sætningen.

I denne artikel, vil der blive gennemgået de grundlæggende PHP-funktioner, såsom udskrift til skærmen, tid og dato og if-sætningen. Denne guide er oprindeligt udgivet på Eksperten.dk Grundlæggende PHP I denne artikel, vil der blive gennemgået de grundlæggende PHP-funktioner, såsom udskrift til skærmen, tid og dato og if-sætningen.

Læs mere

DMX styring med USB-interface

DMX styring med USB-interface DMX styring med USB-interface Introduktion...2 DMX bibliotek...3 Programmering af kanaler...7 Sådan skabes et show/en lyssekvens...11 Introduktion DMX LightPlayer er en avanceret men meget brugervenlig

Læs mere

DANSK SKOLEDATA APS. Tlf. 86 44 80 99 E-mail DSD@skoledata.dk DSA-Ventelisten

DANSK SKOLEDATA APS. Tlf. 86 44 80 99 E-mail DSD@skoledata.dk DSA-Ventelisten Indholdsfortegnelse Overordnet beskrivelse af programmets funktioner... 2 Log på... 2 Manuel oprettelse af elev.... 3 Optagelse af elever... 3 1 Gruppering og sortering af elever... 3 2 Udvælg aspiranter...

Læs mere

ADVARSEL: VIGTIGT: INFORMATION OM BATTERIER.

ADVARSEL: VIGTIGT: INFORMATION OM BATTERIER. VIGTIGT: INFORMATION OM BATTERIER GEM VENLIGST DENNE INFORMATION SOM FREMTIDIG REFERENCE. BATTERIERNE BØR UDSKIFTES AF EN VOKSEN. ADVARSEL: 1. Som med alle andre små batterier bør disse batterier opbevares

Læs mere

Skriftlig eksamen i Datalogi

Skriftlig eksamen i Datalogi Roskilde Universitetscenter Skriftlig eksamen i Datalogi Modul 1 Vinter 1998/99 Opgavesættet består af 5 opgaver, der ved bedømmelsen tillægges følgende vægte: Opgave 1 16% Opgave 2 12% Opgave 3 10% Opgave

Læs mere

ITWIN1. Afsluttende projekt. PhotoDays. Benjamin Sørensen (02284) Tomas Stæhr Berg (03539)

ITWIN1. Afsluttende projekt. PhotoDays. Benjamin Sørensen (02284) Tomas Stæhr Berg (03539) ITWIN1 Afsluttende projekt PhotoDays Benjamin Sørensen (02284) Tomas Stæhr Berg (03539) ITWIN1 - AFSLUTTENDE PROJEKT PhotoDays Benjamin Sørensen & Tomas Stæhr Berg 02284 & 03539 1 1 Underskrifter Rapporten

Læs mere

IT opgave. Informationsteknologi B. Vejleder: Karl. Navn: Devran Kücükyildiz. Klasse: 2,4

IT opgave. Informationsteknologi B. Vejleder: Karl. Navn: Devran Kücükyildiz. Klasse: 2,4 IT opgave Informationsteknologi B Vejleder: Karl Navn: Devran Kücükyildiz Klasse: 2,4 Dato:03-03-2009 1 Indholdsfortegnelse 1. Indledning... 3 2. Planlægning... 3 Kommunikationsplanlægning... 3 Problemstillingen...

Læs mere