Sidste dSoftArk aflevering

1
Sidste dSoftArk aflevering
Gruppe 14
December 19, 2007
Til validering af standard træk (dvs. der ikke er en checker i bar, for den respektive
spiller, og han ikke vil flytte den til bear off).
Vi betragter vores validering som en boolsk funktion med følgende parametre
v( move, player, board-state, die-value), hvilket betyder at det er det vi har
tilgængeligt at regne p˚a.
Vi startede med at definere en funktion dist(f,t) (from og to henholdsvis)
der beregner afstanden mellem 2 felter.
Som vores første slice i partitioneringen ligger de to tilfælde:
dist(f, t) = dice − value - Valid
dist(f, t) = dice − value - Invalid
f og t er afledt af move parametren.
dist(f, t) = dice − value ↑
dist(f, t) = dice − value
Som en lille note s˚a er en valid partitioner markeret med ↑
Som det næste definerede vi en color(c) funktion der giver farven p˚a et felt,
vi kan s˚a opdele vores partitionering yderligere Med hensyn til color, s˚a vil vi
ogs˚a gerne skelne mellem farven p˚a spilleren, p˚a den m˚ade om han er none eller
ej. vores første farve inddeling bliver derfor
player = none som er invalid. Den næste m˚ade som vi vil skelne mellem farver
p˚a, er om felt farven p˚a from feltet er det samme som spilleren eller ej. det giver
os 2 yderligere:
color(f) = player ∧ player = none - Invalid
color(f) = player ∧ player = none - Valid
1

color(f) = player∧player = NONE
color(f) = player ∧ player = NONE
player = NONE
dist(f, t) = dice − value ↑
dist(f, t) = dice − value
Det sidste vi skal have checket er om et felt er blocked (om der st˚ar 2 af
fjendens brikker der eller mere). I vores partitionering har vi nu lige præcis
en partition der er valid, den vil vi arbejde videre med, og efterlade de andre
som de er (I dette eksempel bliver de restende 5 partitioner ikke valid af at vi
finindeler dem). Vi definerer en ny funktion isBlocked(f, p) der afgør om et felt
er blocked ud fra et felt og en player, lidt mere detaljeret kunne den beskrives
s˚aledes:
isBlocked(f, p) = count(f) >= 2 ∧ color(f) = p
læg mærke til at vi brugte funktionen count, den tæller antallet af brikker p˚a et
felt. vi opdeler nu den valide partition i 2 nye, defineret ud fra: isblocked(f, player)
- Invalid
¬isblocked(f, player) - Valid
dist(f, t) = dice − value
color(f) = player ∧ player = NONE
color(f) = player ∧ player = NONE
↑ ¬isBlocked(t, player)
Udfra denne partionering er vi nu endt op med en masse ækvivalensklasser.
De er intuitivt disjunkte da enhver slice vi har lavet har været mere eller mindre
binær, og begge tilfælde er dækket, alle tilfælde er dækket og der er ingen
ækvivalensklasser der overlapper hinanden.
Udfra ækvivalensklasserne skal vi have følgende tests:
2
player = NONE

en Hvor terningen ikke matcher distancen brikken flyttes, men derudover er alle
regler overholdt, dette tester klassen . Vi kan s˚a argumentere for at vi ikke
behøver en test i og da de alligevel vil fejle.
I samtlige af de næste tests lader vi terninge værdien matche distancen.
I denne test lader vi player være none, og udfører derefter et ellers helt legalt
træk, den skulle gerne fejle, vi har s˚aledes testet klassen . I den næste test
prøver vi at flytte p˚a modstanderens brik, det svarer til at teste klassen ,
der skal naturligvis ogs˚a melde false.
I næste test vil vi prøve at flytte en brik hen p˚a et felt hvor den st˚ar 2 af
modstanderens brikker. Denne test giver klassen , og er invalid.
i den sidste test prøver vi at udføre et fuldstændig legalt træk, der er valid,
og s˚a burde vi jo ogs˚a f˚a en true p˚a den. Dette tester
Det er diskutabelt om der burde have været en finere inddeling, f.eks. med
blocked tilfældet, kunne man har haft mere end 2 brikker p˚a feltet, netop 2
brikker p˚a feltet og mindre en 2 brikker p˚a feltet
2
Her skal vi lave en analyse af situatinen n˚ar en spiller har en brik p˚a bar feltet.
Det jo ˚abentlyst at vi ikke behøver at starte forfra men kan egentlig blot forfine
vore nuværende partitionering, da regelsættet her blot er en stramning af det
foreg˚aende. Vi vil derfor kun kigge p˚a den valide partion fra det foreg˚aende, og
s˚a m˚a man tænke sig til at den kan copy pastes oven p˚a det tilsvarende felt fra
opgave 1.
Her kan vi igen bruge count funktionen, denne benytter vi til at tælle antallet
af brikker i bar (vi har valgt ikke at skelne, det er nødagtig det samme
hvadenten du er rød eller sort.
vi har s˚aledes 2 tilfælde:
count(bar) = 0 og count(bar) > 0 Hvis vi er i det første tilfælde s˚a er det
egentlig blot reglerne fra opgave 1 der gælder (partitionen er alts˚a lovlig) det
andet tilfælde skal dog subinddeles lidt. Reglerne siger at hvis der ligger en brik
p˚a bar s˚a skal den flyttes inden en anden m˚a flyttes.
Det giver jo anledning til 2 partionener:
from = bar - Valid
from = bar - Invalid
Vi ender s˚aledes op med denne partition:
↑ count(bar) > 0 ∧ from = bar count(bar) > 0 ∧ from = bar ↑ count(bar) = 0
3

Denne repartitionering giver kun anledning til 2 ekstra test: Et normalt valid
move, hvor der dog ligger en brik i bar. Denne skal give false, og den tester .
I den sidste test ligger der en brik p˚a bar, og den flyttes helt legalt, Dette tester
3
.
behøver vi ikke teste da den allerede er testet i opgave 1.
De ekstra tests som i følge vores systematiske test-forløb skal tilføjes til vores
system er følgende:
• playerIsNONEbutValidMove
• rightDistColorNotPlayer1of2
• rightDistColorNotPlayer2of2
• MoveFromColorNONE
• MoveTooFar
• MoveTooShort
En kort analyse heraf følger nu.
• playerIsNONEbutValidMove
Her vælger.... flaf
• rightDistColorNotPlayer1of2
Nummer 2
• rightDistColorNotPlayer2of2
Nummer 3
• MoveFromColorNONE
Nummer 4
• MoveTooFar
Nummer 5
• MoveTooShort
Nummer 6
4