Projektuppgift - Gymmet 2013
1. Projekt - syfte, instruktioner och uppgift Syftet med den här projektuppgiften är att ni nu ska tillämpa allt det ni har lärt er i kursens två labbdelar, dvs både kunskaper från del 1 och 2 av labbarna. Ni får välja mellan ett par olika uppgifter, men får färdiga krav från oss. Det kan tyckas lite tråkigt, men det finns ett par anledningar till det: dels vill vi vara säkra på att uppgiften både innehåller ett antal moment som gör att ni faktiskt får öva på just det som ni tidigare gjort i labbarna, dvs att vi täcker in ett antal moment som ni ska kunna efter kursens slut, men å andra sidan vill vi inte att uppgiften ska bli för svår för er, vilket är lätt hänt om ni får bestämma själva vad ni vill göra, utan precis på en "lagom" nivå för en nybörjarkurs i programmering. När ni löser uppgiften, tänk på att försöka använda alla principer som ni lärt er under kursens gång. Vi förutsätter att ni åtminstone tänker på följande: o Objektorienterad design av er programvara - vi lägger stor vikt vid att ni funderar igenom hur ni ska dela upp era klasser, om det är lämpligt att t ex använda arv någonstans och att ni i så fall faktiskt gör det, vilka data som ska lagras i vilken klass och hur ni tillämpar principerna om inkapsling, vilka metoder som finns i vilken klass etc. Uppgiften går att lösa på många olika sätt, men handledarna kommer hjälpa er att "tänka" så objektorienterat som möjligt eftersom det är ett av huvudsyftena med projektet. Är ni osäkra - kolla med handledaren om er struktur är ok så tidigt som möjligt! o Övriga programmeringsprinciper vi har lärt oss - ni har t e x lärt er att undvika svenska tecken, att namnge alla variabler och metoder på ett sätt som faktiskt säger något om vad de har för funktion (t ex inte bara en bokstav), och att strukturera er kod så att ingen metod är längre än ca 20 rader kod (annars bryter ni ut delar av koden i nya metoder som ni anropar). o Robusta program - er programvara ska i princip inte kunna "krascha" (eller bara avslutas innan användaren bett om det) oavsett vilka indata som användaren matar in i systemet. Tänk på att kontrollera alla indata innan ni använder dem i systemet, och be användaren mata in nya data om något verkar fel, utan att programmet avslutas och användaren får börja om. Tänk även på att fånga upp alla eventuella undantag och hantera dem på lämpligt sätt. Testa ert system med oväntade och felaktiga indata innan ni lämnar in er lösning - ett bra sätt kan vara att be en kompis att använda programmet, utan att först ge personen detaljerade instruktioner om vad han eller hon får göra. o Välkommenterad kod - er kod ska innehålla så mycket kommentarer att handledaren direkt kan förstå vad som händer på varje rad i programmet. Det är inte nödvändigt att kommentera varje rad, om det är helt uppenbart vad som utförs (t ex en enkel utskrift), men åtminstone varje beräkning, metodanrop eller annan operation (t ex loop eller if-sats) ska ha en förklarande kommentar i koden. Utöver dessa kommentarer "inne i koden" ska ni även dokumentera ert program genom att använda Javadoc. Det innebär att åtminstone varje publik klass, variabel och metod ska ha en kommentar formaterad enligt Javadoc-syntax, och ni ska generera och lämna in resulterande HTML-sidor för hela projektet.
1.1 Planering På kurshemsidan hittar du mer information om examination och deadlines, så se till att läsa den noga. Återkom även till kurshemsidan med jämna mellanrum för att se så att det inte har blivit några ändringar! Sammanfattningsvis kan man säga att ert projekt kommer att innehålla tre delar: o Kravanalys och design o Implementation och test o Dokumentation Kravanalys och design innebär att ni går igenom kraven i det här dokumentet och planerar för hur ert program ska se ut, dvs vilka klasser ska programmet innehålla, hur är de relaterade till varandra, var ska main-metoden finnas, vilka klass- och instansvariabler ska varje klass ha osv. Det här ska ni göra på papper, innan ni ens börjar programmera, och visa upp för handledaren på det första mötet (deadline 17/1). Syftet är att handledaren redan innan ni ens har skrivit en enda rad kod ska kunna se om ni är "på rätt väg" eller inte, men det är inget "test" utan handledaren kommer istället att hjälpa er och tipsa er om en bättre struktur om ni inte har tänkt helt rätt från början! Syftet är att se till att ni "tänker objektorienterat" från början och inte hamnar på fel spår och får göra om en massa sen när ni börjat implementera er kod. Implementation innebär att ni skapar de klasser ni har planerat att ert program ska ha, och skriver koden för de variabler och metoder de ska innehålla. I implementationsdelen ingår även att testa programmet så att det gör vad det ska och inte "kraschar" vid oväntade indata. Tänk på att kommentera er kod medan ni skriver den, så att ni själva kan komma tillbaka och se hur ni tänkte lite senare! För att ni inte ska fastna på momentet att läsa in data från fil, får ni två färdiga textfiler som innehåller data ni kan använda som testdata när ni kör ert program. Tänk på att programmet ska fungera med vilka andra indatafiler som helst, bara de heter likadant, ligger på samma ställe på hårddisken, och innehåller data som är formaterat på samma sätt - handledarna kommer att testa era program med indatafiler som innehåller andra kunder, gymkort och gymbesök än vad ni har i era filer! Ni får även en halvfärdig klass som ni kan använda som ett kodskelett för den klass som sköter inläsning av data från fil. När ni har kompletterat den klassen med kod för att skapa instanser av era egna klasser, baserat på indata från filerna, är det dags att återigen ha ett avstämningsmöte med handledaren (deadline 31/1). Syftet är att se till att ni återigen "tänker objektorienterat" och använder era klasser på rätt sätt - har ni hamnat på fel spår kommer handledaren ge er tips på hur ni kan göra istället. När ni känner att ni är klara med hela implementationen är det dags att demonstrera projektet för handledaren (deadline 21/2). Handledaren kommer att vilja köra ert program och själv testa funktionaliteten, och ni kommer att få nya textfiler med indata (samma namn och samma format) som ert program ska kunna använda utan att behöva modifieras på något sätt. Handledaren kommer även att vilja diskutera koden med er och ni förväntas enskilt (dvs vardera medlemmen i gruppen) förväntas kunna beskriva vad varje del i koden gör (se till att ha bra kommentarer i koden), och vilka delar som löser vilka delproblem - så om ni har delat upp uppgiften mellan er under arbetets gång, var noga med att förklara era lösningar för varandra innan redovisningen, annars riskerar ni att inte får godkänt!
Slutligen ska ni dokumentera er lösning, dels genom att generera HTML-sidor baserat på era Javadoc-kommentarer i kod-filerna och dels genom att skriva en rapport om ert program. När ni är klara med både implementationen och dokumentationen (deadline 21/2) lämnar ni in koden, HTML-filerna och rapporten (i pdf eller Word-format) i en gemensam zip-fil i LISAM. Deadlines för respektive moment hittar ni på kurshemsidan, men tänk på att för att vara säkra på att hinna klart med projektet rekommenderar vi att ni är klara med varje moment lite innan sista deadline! Se veckoplaneringen för lämpliga tider när varje del bör vara genomförd - lämpligt är att ha pratat med handledaren om er design redan innan juluppehållet, dvs i vecka 51, och att sedan visa upp koden för att läsa in data från fil och skapa era objekt redan i vecka 3 eller 4. Ni kan jobba med projektet på labbtid, men tiden kommer förmodligen inte att räcka till, så planera även in tid utanför schemalagd labbtid då ni jobbar med projektet. Tänk också på att det är ni själva som bokar tid med er handledare för alla möten och redovisningar - på labbtillfällena fram till 31/1 prioriterar handledarna att svara på frågor om labbarna, bara i mån av tid kan ni visa upp er design, eller kod från projektet. Boka därför in möten utanför labbtid med er handledare för dessa möten/redovisningar, men tänk på att handledarna kan vara upptagna och kanske inte har tid att träffa er just dagen för deadline, så var ute i god tid! 2. Projektuppgift Ett medlemssystem hanterar medlemmarnas gymkort och besök på ett litet gym, som har både gruppaktiviteter som aerobics och spinning samt ett gym för styrketräning. Tänk er att systemet ska användas av gympersonalen (kassörerna) när de betjänar kunderna i gymmets kassa. Systemet ska uppfylla ett antal krav som kunden (gymmet) har ställt upp. För att den tänkta kunden ska acceptera systemet (d v s för att ni ska få G på projektet) ska samtliga krav i listan nedan (punkterna 1-15 i avsnitt 2.1) vara uppfyllda - detta kommer er handledaren att testa när ni demonstrerar projektresultatet för honom/henne. Systemet har bara en typ av användare: gympersonalen som står i gymmets kassa och betjänar en kund när han eller hon vill träna. 2.1 Följande krav gäller för systemet (för G-nivå) 1. Systemet ska hantera information om gymmets medlemmar (kunder), varje kund har åtminstone ett namn, en adress, ett (unikt) personnummer och ett telefonnummer. 2. Systemet ska även hantera information om medlemskap i gymmet, dvs gymkort. Ett gymkort har ett (unikt) kortnummer, ett pris (som kunden betalat när denne köpte kortet) och ett utgångsdatum när det upphör att gälla. Varje gymkort ägs av exakt en kund, men en kund kan ha flera gymkort. Ett gymkort ska även hålla reda på en lista över tidigare gymbesök, d v s träningstillfällen, som registrerats på kortet när innehavaren kommit till gymmet för att träna. 3. Varje träningstillfälle har ett datum och en tid, en passtyp (på det här gymmet finns tre typer av pass: spinning, aerobics, och gym), samt en titel på det pass som kunden deltog i (en text, t ex "aerobics, intensiv", "spinning 45min soft" eller kanske bara "gymmet" om besökaren valde att styrketräna i gymmet på egen hand).
4. Det finns två olika typer av gymkort: periodkort och klippkort. 5. Ett periodkort är ett kort där kunden kan gå på så många pass denne vill under en viss period, dvs hur många besök som helst fram till kortets utgångsdatum. Alla periodkorten gäller även för vilka träningstillfällen som helst, dvs för alla tre typerna av pass (spinning, aerobics och gym). 6. Ett klippkort är ett kort som gäller bara för ett visst antal besök (antalet varierar), och dessutom bara för en viss typ av aktivitet, dvs antingen bara för besök i gymmet, bara för aerobicspass, eller bara för spinningpass. Liksom alla gymkort har klippkorten ett utgångsdatum, men kunden kan inte heller använda kortet för ett besök om kortet tar slut på grund av att 0 klipp återstår på kortet, även om det sker före utgångsdatum, dvs för kortet måste vi även hålla reda på antalet kvarvarande klipp. 7. När programmet startar, innan interaktionen med användarna börjar, ska information om kunder och deras gymkort, inklusive tidigare besök på gymmet, läsas in från textfiler på hårddisken. Programmet kan förutsätta att filerna ligger på en förutbestämd plats, med ett förutbestämt namn, och att innehållet är formaterat på ett förutbestämt sätt, men vi vet inte i förväg hur många kunder/kort/besök som ska läsas in. 8. När programmet startas och data lästs in från fil listas sedan alla kunder (åtminstone personnummer och namn skrivs ut på skärmen) och användaren (kassören) uppmanas välja en kund ur listan genom att mata in dennes personnummer. 9. När kassören valt en viss person listas den aktuella kundens samtliga periodkort respektive klippkort på skärmen (även de som har gått ut eller är fullt utnyttjade), i två separata listor, och kassören uppmanas välja vilket kort att jobba vidare med genom att ange dess kortnummer. Här listas alltså alla kort, dvs även tidigare kort med utgångsdatum som passerats eller där det inte finns några klipp kvar, detta för att även kunna visa information om tidigare kort kunden haft. 10. När kassören har valt ett visst periodkort eller klippkort ska all information för det kortet visas på skärmen, inklusive alla tidigare träningstillfällen som registrerats på kortet. För varje träningstillfälle visas datum, tid, passtyp och titeln på passet. 11. Gymbesökaren kan sedan registrera sitt besök, dvs ett nytt träningstillfälle, med kassörens hjälp. Om det valda kortet är ett periodkort ska kunden kunna registrera ett nytt träningstillfälle på kortet oavsett vilken typ av pass det gäller (aerobics, spinning eller gymträning), så länge utgångsdatum på kortet inte passerats. Om det valda kortet är ett klippkort kan kunden bara registrera ett besök om typen av klippkort överensstämmer med typen av pass som kunden försöker registrera ett besök på, samt om det återstår minst ett klipp på kortet och utgångsdatum på kortet inte har passerat. 12. Varje träningstillfälle (besök) på gymmet registreras på kortet genom att lagras i en lista över tidigare träningstillfällen för det kortet, med tillhörande datum, klockslag, typ av pass, och titel på det specifika passet. Datum och tid får matas in av kassören - ni behöver inte använda aktuell systemtid, och även typ och titel på passet matas in av kassören. Om kortet är ett klippkort räknas antalet kvarvarande klipp ned med 1 för varje nytt träningstillfälle som läggs in. 13. När ett träningstillfälle är registrerat och klart, ska användaren (gymkassören) återigen få se listan över alla kunder, för att vara redo att ta emot en ny kund (enligt krav 8).
14. Gymkassören ska i detta läge (när alla kunder listas) kunna avsluta programmet genom att skriva något kommando i terminalfönstret. 15. Innan programmet avslutas ska all information om gymmets kunder, deras kort och träningstillfällen (inklusive alla ändringar och nya besök som genomförts sen programmet startades), återigen lagras i de textfiler varifrån informationen lästes in vid programstarten. 2.2 Extra krav för VG För att kunna få VG på projektet krävs att ni även visar förmåga att själva läsa in er på något område som vi inte har gått igenom i detalj i kursen. Här har ni tre val, (1) att läsa in er mer på grafiska gränssnitt, (2) att läsa in er på hur man kan koppla ett Javaprogram till en databas och hur man designar en sådan databas, eller (3) att utöka funktionaliteten i systemet och läsa in er på eventuella klasser och metoder i Javas standardbibliotek som ni inte använt tidigare och som behövs för detta (ni kan behöva klasser som vi inte gått igenom alls i kursen). Detta innebär att för att få VG måste ni, utöver ovanstående krav (1-15), lösa EN av följande uppgifter (d v s er lösning täcker in en av följande punkter, antingen 16, 17, eller 18, helt och hållet - det går alltså inte att välja lite från varje punkt utan ni måste täcka in åtminstone en av dessa helt och hållet): 16. All interaktion med användaren sker genom ett grafiskt gränssnitt, d v s via fönster, menyer, knappar osv, istället för genom text och meddelanden i terminalfönstret. Detta innebär alltså att krav 7-14 ovan ska använda ett grafiskt gränssnitt för alla in- och utmatningar som krävs, samt för att visa all information som systemet visar för användaren, eventuella felmeddelanden, och för att avsluta programmet (t ex genom en "avsluta"-knapp). 17. All information som systemet behöver läsa in när programmet startar, lagras i en databas (istället för direkt som textfiler på hårddisken - detta krav ersätter alltså krav 7 och 15 ovan), och innan programmet avslutas lagras den uppdaterade informationen i databasen. Databasen ska vara designad med olika tabeller som lagrar information om objekt av olika typer, dvs det kan t ex finnas en särskild tabell för information om kunder, en för kort, en för träningstillfällen osv. Stäm av designen av databasen och dess tabeller med handledaren vid första mötestillfället om ni planerar att välja detta VG-alternativ. Observera även att ni förmodligen inte kan installera ett databashanteringssystem på era konton på IDA. Väljer ni detta alternativ måste ni alltså antingen använda ett system som redan finns installerat (på de flesta datorer i PC-pularna ska MySQL vara installerat), eller så måste ni köra programmet på er egen dator. 18. Utöka systemet med följande funktionalitet (alla punkter 18.1-18.4 måste finnas med i er lösning om ni väljer detta alternativ): 18.1. Inloggning för kassören, d v s, när programmet startas måste denne logga in med sitt användarnamn och lösenord innan några andra funktioner i systemet blir tillgängliga (detta är ett nytt krav, utöver 1-15 ovan), dvs systemet ska fråga om användarnamn och lösenord för kassören innan listan över kunder visas på skärmen (se krav 8 ovan) och endast om kassören skriver rätt ska man kunna komma vidare i systemet. Ni behöver dock inte ta hänsyn till säkerheten, d v s ingen kryptering behövs och ni kan lagra och hantera lösenord i klartext. Användaren får även försöka hur många gånger som helst om man skriver fel användarnamn och/eller lösenord, utan att programmet avslutas. Användarnamn och lösenord ska finnas lagrade på
hårddisken i en separat fil, varifrån de läses in och lagras i en lämplig datastruktur samtidigt som övriga data läses in från fil när programmet startas. 18.2. Varje träningstillfälle som registreras på ett kort ska även innehålla information om vilken kassör som registrerade det, d v s den aktuella kassörens användarnamn ska lagras tillsammans med varje träningstillfälle som denne registrerar åt kunden (detta är ett tillägg till krav 3 ovan). Vid varje nytt träningstillfälle, dvs besök på gymmet, ska den här informationen automatiskt lagras i det nya träningstillfälle som skapas (detta är ett tillägg till krav 12 ovan). Ni måste alltså hela tiden hålla reda på vilken kassör som är inloggad. Nu ska även aktuellt datum och exakt tid för varje transaktion hämtas automatiskt (d v s med hjälp av tiden från systemklockan, istället för att användaren matar in datum och tid - detta krav modifierar krav 10 ovan). 18.3. Automatisk utloggning av kassören om ingen ny registrering genomförts på en viss tid, t ex 5 minuter. Om kassören försöker göra någon operation efter att tiden gått ut ska programmet återgå till inloggningsskärmen som visades när programmet startade (se krav 18.1) och ett meddelande om att kassören blivit automatisk utloggad visas. 18.4. Kassören ska kunna lägga in nya kunder i systemet (samt ta bort kunder ur systemet), och kunderna ska kunna köpa nya gymkort (både periodkort och klippkort). När programmet avslutas ska naturligtvis även alla dessa förändringar reflekteras i de data som skrivs ut i respektive fil.