Page History

...

actor bruker
MemoryProgram -> Memory: nextItem()
Memory --> MemoryProgram: 3
MemoryProgram -> bruker: "Element nr. 1 er 3"
MemoryProgram -> bruker: "Gjenta element nr. 1 av 1"
bruker --> MemoryProgram: 3
MemoryProgram -> Memory: acceptItem()
Memory --> MemoryProgram: ok og ferdig
MemoryProgram -> Memory: nextItem()
Memory --> MemoryProgram: 4
MemoryProgram -> bruker: "Element nr. 2 er 4"
MemoryProgram -> bruker: "Gjenta element nr. 1 av 2"
bruker --> MemoryProgram: 3
MemoryProgram -> Memory: acceptItem()
Memory --> MemoryProgram: ok, men ikke ferdig
MemoryProgram -> bruker: "Gjenta element nr. 2 av 2"
bruker --> MemoryProgram: 4
MemoryProgram -> Memory: acceptItem()
Memory --> MemoryProgram: ok og ferdig
MemoryProgram -> Memory: nextItem()
Memory --> MemoryProgram: 4

class MemoryProgram {
}
class Memory {
	expectedItems
	acceptedCount
	nextItem()
	acceptItem()
}

MemoryProgram -right-> Memory: memory

Vi ser at Memory hovedsaklig tilbyr to tjenester: å generere nye tall i sekvensen og å ta imot et nytt tall (fra brukeren) og sjekke det mot fasiten. Det er dessuten underforstått at Memory må huske både tall-sekvensen og hvor langt brukeren har kommet i å gjenta den. Klassediagrammet til høyre er oppdatere i henhold til dette.

Dette er et godt utgangspunkt for å begynne å kode, og selv om det er mulig å fylle ut mer detaljer i diagrammet først, så er erfaringen at koding raskere skaper fremdrift ved å avdekke problemer og mulige løsninger.

Vi har valget mellom tre strategier: 1) skrive MemoryProgram og dermed avdekke mer presist hvilke metoder Memory må tilby, 2) skrive Memory først og tilpasse MemoryProgram deretter, eller 3) en hybrid strategi hvor vi jobber parallelt med begge to. Dette er ofte en smaksak, men jeg foretrekker ofte å jobbe topp-ned på skissestadiet, som vi er på nå, og bunn-opp med selve kodingen. Imidlertid kan en godt jobbe litt mer på papir, for å klargjøre i litt mer detalj hva hver metode er ment å gjøre, og da kan et objekttilstandsdiagram være nyttige, siden det illustrerer effekten av metodekall på den interne tilstanden, ikke bare sekvensen av kall. Her er et slikt diagram basert på eksemplet over:

...

object Memory1 {
	expectedItems = []
	acceptedCount = 0
}
object Memory2 {
	expectedItems = [3]
	acceptedCount = 0
}
Memory1 -down-> Memory2: nextItem() => 3
object Memory3 {
	expectedItems = [3]
	acceptedCount = 1
}
Memory2 -down-> Memory3: acceptItem() => ok og ferdig
object Memory4 {
	expectedItems = [3, 4]
	acceptedCount = 0
}
Memory3 -down-> Memory4: nextItem() => 4
object Memory5

...

 {
	expectedItems = [3, 4]
	

...

acceptedCount = 1
}
Memory4 -down-> Memory5: acceptItem() => ok, men ikke ferdig
object 

...

Memory6 {
	expectedItems = [3, 4]
	acceptedCount = 

...

2
}

...

Memory5 -down-> 

...

Memory6: 

...

acceptItem() => ok 

...

og ferdig
object 

...

Memory7 {
	expectedItems = [3, 4, 7]

...

	acceptedCount = 0
}
Memory6 -down-> Memory7: nextItem() => 7

Vi ser at Memory hovedsaklig tilbyr to tjenester: å generere nye tall i sekvensen og å ta imot et nytt tall (fra brukeren) og sjekke det mot fasiten. Det er dessuten underforstått at Memory må huske både tall-sekvensen og hvor langt brukeren har kommet i å gjenta den. Klassediagrammet til høyre er oppdatere i henhold til dette.

Dette er et godt utgangspunkt for å begynne å kode, og selv om det er mulig å fylle ut mer detaljer i diagrammet først, så er erfaringen at koding raskere skaper fremdrift ved å avdekke problemer og mulige løsninger.

Vi har valget mellom tre strategier: 1) skrive MemoryProgram og dermed avdekke mer presist hvilke metoder Memory må tilby, 2) skrive Memory først og tilpasse MemoryProgram deretter, eller 3) en hybrid strategi hvor vi jobber parallelt med begge to. Dette er ofte en smaksak, men jeg foretrekker ofte å jobbe topp-ned på skissestadiet, som vi er på nå, og bunn-opp med selve kodingen. Imidlertid kan en godt jobbe litt mer på papir, for å klargjøre i litt mer detalj hva hver metode er ment å gjøre, og da kan et objekttilstandsdiagram være nyttige, siden det illustrerer effekten av metodekall på den interne tilstanden, ikke bare sekvensen av kall. Her er et slikt diagram basert på eksemplet over:

Nå som vi vet hvordan hvert kall er ment å oppdatere den interne tilstanden, så kan vi skrive selve koden:

...