Göm menyn

TDDI02 Programmeringsprojekt

Projektförslag: Hantering av ligaresultat


Projektförslag: Hantering av ligaresultat

Nedan följer ett scenario i vilket en person vill beställa ett enkelt(?) program av er. Han har en del synpunkter på vad programmet bör klara av, och har bifogat lite ideer på hur man skulle kunna implementera det.

Observera att `behovet' och beskrivningar inte säkert är kompletta, samt att vissa saker de önskar sig är onödiga eller skulle bli våldsamt dyra att implementera.

Det är er uppgift att utifrån denna luddiga problemformulering författa en funktionsspecifikation som beskriver exakt vad programmet skall klara av och hur det kommer att fungera gentemot användaren.

Scenario

Lars Gunnar Björklind har fått för mycket att göra. I sitt dagliga arbete på spelmonopolet TipsService behöver Björklind ständigt veta den aktuella poängställningen i diverse fotbollsligor runt hela landet. Tidigare, när det bara var en liga, klarade han att hålla informationen i minnet, men då antalet ligor har ökat kraftigt på senare år så går det inte längre.

Björklind har själv försökt att hitta ett sådant program på marknaden (d.v.s. i de programvaruhus som finns i stan) men har inte hittat något. Det närmaste han kommit var ett program skrivet av en kompis till honom. Då han provade programmet upptäckte han följande dumheter:

  • När man matade in lagen för en match och de mål som gjorts, och råkade stava fel på ett av lagen, så registrerade programmet automatiskt ett nytt lag med det felaktiga namnet och lagrade matchen där!
  • Det fanns ingen möjlighet att arbeta med flera ligor. Enda sättet var att med några kryptiska kommandon i något som kompisen kallade operativsystem döpa om några filer, och sedan starta programmet på nytt. Helt oacceptabelt!
  • När han satt och lagrade nya matchresultat för ett lag lite på måfå, så kraschade programmet och hela datorn startade om på nytt. Kompisen hade sagt något om att han lagt in för många matcher på ett och samma lag. På Björklinds fråga om hur man klarar ligor som växer sig större från år till år, hade kompisen mumlat något om `kompilera om' och `fixa i koden'. Mycket skumt! Och när det kraschade, så försvann naturligtvis alla ändringar som gjorts. Inte bra!
På er fråga hur han vill att ett program skall fungera, svarade han (ungefär) följande:
  • Helst vill jag kunna mata in lag för sig, d.v.s. registrera dom. Det är bra om man för varje lag kan ange vad som är deras hemmaplan. Sen är det bra om man i förväg kan skriva in vilka lag som spelar mot varandra, samt var och när dom gör det.
  • Sen kan man enkelt slå upp de eller de lag som spelat idag (eller något visst datum) och fylla i hur det gick. Det som skall registreras är ju bara hur många mål respektive lag gjort. Sedan kan väl datorn själv räkna ut om det var bortamål eller hemmamål?
  • Det kanske blir dyrt. Det kan räcka om man måste knappa in de båda lagen och deras mål den dag de möts.
  • Oavsett vilket vill jag kunna se vilka lag som finns med i ligan, och för ett visst lag alla matcher det laget gjort. Kanske inte samtidigt, det kan bli lite väl mycket. Fördelen med att i förväg kunna lägga in vilka matcher ett lag skall gå är att man då kan se vilka matcher ett lag har kvar, och utifrån matchstatistiken kunna spekulera i vilka motståndare just det laget kan/måste slå.
  • Just det, jag måste kunna titta på matchstatistiken för ett visst lag. Den brukar bestå av:
    • antal redan spelade matcher för ett lag
    • hur många som vunnits
    • antal oavgjorda matcher
    • antal förlorade dito
    • totala antalet lagda mål
    • och antalet insläppta mål
    • lagets poängställning
  • Om man kan variera hur programmet visar alla matcher så är det bra om en punkt är att visa matchstatistik och kvarvarande matcher....
  • Om det blir strömavbrott så att datorn stannar efter en halv dags användande, så är det bra om så lite information som möjligt försvinner. Kan den inte spara automatiskt med jämna mellanrum, t.ex. senast 10 minuter efter första osparade ändring eller när fem eller tio ändringar gjorts, vilket som nu inträffar först? Men det får inte bli så att den är oanvändbar i två minuter för att spara, d.v.s. om det tar tid att spara är det nog bra om den kan nöja sig med att bara spara ändringar. Sedan när man går ur programmet eller själv väljer det, så kan den göra om alla sparade ändringar till en enhet (vissa ändringar kan ju ta ut varandra!), t.ex. genom att spara all information på nytt och ta bort all ändringsinformation. Men den bör alltså kunna starta med att läsa in alla ändringar om sådana finnes.
Jaha, säger ni. Och det här var allt?
  • Nja, det är ju bra om programmet är så enkelt som möjligt att använda, d.v.s. det skall vara lätt att förstå vad de olika kommandona eller menyvalen gör bara på deras namn, och det bör finnas hjälp att få i programmet om hur det fungerar och vad man skall göra. Men om det skall vara kommandon, menyer eller något annat, det vet jag inte. Bara det blir bra!
Ni förklarar att det som sagts ovan bitvis kan vara lite besvärligt, och att ni därför kommer att dela in uppgifterna i flera grupper (sådant som måste vara med och lite besvärligare men önskvärda saker) i den kravspecifikation ni nu skall skriva. Sedan återkommer ni för att se att ni fattat problemet rätt. Det är inte säkert att ni kan lova att implementera de svårare delarna.

Kommentar till scenariot

Nedan följer lite idéer om hur man kan bygga upp en datastruktur för att handskas med lagen enligt ovan. När ni börjar veta hur ni vill ha det, så skriver ni en funktions- specifikation enligt ovan (se `Handledningen till projektuppgifterna' för en förklaring). Datastrukturen Av kommentarerna till `kompisens' program ovan kan man sluta sig till att Lars Gunnar vill ha en dynamisk datastruktur (en som växer allt eftersom man stoppar in saker i den). En sådan kan bestå av poster, som på något sätt ät hopkopplade med pekare, och frågan är då vilka sorters poster ni behöver. Ett sätt kan vara att ha en lista av LAG och en lista av MATCHer. Då ett lag spelar flera matcher, måste det i varje LAG finnas en lista av kopplingar till MATCHerna, d.v.s. någon typ av post där ena delen pekar ut en MATCH och andra delen pekar ut nästa post. I varje MATCH kan man då lagra (förutom datum för matchen) information om vad som är hemmalag och bortalag, (pekare till dessa LAG för att inte dubbellagra information!) samt hur många mål respektive lag gjort.

Rita upp, med lådor och pilar, hur datastrukturen kan se ut. Får ni oöverstigliga problem med val av datastruktur (d.v.s. förstår ni inte ovanstående exempel) har handledaren en mer handfast instruktion på vad ni skall göra. Den ger dock mindre utrymme åt er fantasi.

Lycka till!


Thomas Padron-McCarthy, 20 september 1998.
Med tack till Torbjörn Jonsson, Peter Loborg m fl.

Sidansvarig: Filip Strömbäck
Senast uppdaterad: 2017-06-26