Projektuppgift - Banken 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, konton och transaktioner ä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 banksystem hanterar kundernas bankkonton och lån. Tänk er att systemet ska användas av bankpersonalen (kassörerna) när de betjänar kunderna i bankkassan. Systemet ska uppfylla ett antal krav som kunden (banken) 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: bankkassören som står i banken kassa och betjänar en kund. 2.1 Följande krav gäller för systemet (för G-nivå) 1. Systemet ska hantera information om bankkunderna, varje kund har åtminstone ett namn, en adress, ett (unikt) personnummer och ett telefonnummer. 2. Systemet ska även hantera information om konton. Ett konto har ett (unikt) kontonummer och ett aktuellt saldo. Varje konto ägs av exakt en kontoinnehavare. Ett konto ska även innehålla en lista över tidigare transaktioner, d v s uttag/betalningar och insättningar som gjorts. 3. Varje transaktion har ett datum och en tid, samt ett meddelande/kommentar (text) och ett belopp som kan vara positivt eller negativt beroende på vad kunden har gjort för transaktion. 4. Det finns två olika typer av konton: sparkonton och lån. 5. Ett sparkonto är ett konto där saldot alltid är positivt, dvs får aldrig bli mindre än 0. På ett sparkonto kan man göra insättningar och uttag. 6. Ett lån är ett konto där saldot alltid är negativt, och där man inte kan utöka lånet, d v s du kan aldrig låna mer pengar på ett befintligt lån, utan bara betala av på det så att det negativa saldot hela tiden närmar sig 0. 7. När programmet startar, innan interaktionen med användarna börjar, ska information om kunder och deras konton, inklusive tidigare transaktioner på
konton, 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/konton/transaktioner som ska läsas in. 8. När programmet startas och data lästs in från fil listas sedan alla kunder (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 sparkonton respektive lån på skärmen, i två separata listor, och kassören uppmanas välja vilket konto/lån att jobba vidare med genom att ange dess kontonummer. 10. När kassören har valt ett visst sparkonto eller lån ska det aktuella saldot för det kontot samt alla tidigare transaktioner på kontot/lånet visas på skärmen (för varje transaktion visas datum, tid, meddelandetexten samt beloppet för transaktionen). 11. Kontohavaren kan sedan genomföra sitt bankärende med kassörens hjälp. Om det valda kontot är ett lån ska kunden kunna betala av på detta lån, d v s kassören minskar lånebeloppet på lånet med ett givet belopp som kunden anger (tänk er att kunden betalar motsvarande summa vid disken). Om det valda kontot är ett sparkonto kan kunden istället göra ett uttag eller en insättning, d v s kassören ska kunna minska/öka saldot på ett bankkonto med ett givet belopp (tänk er att kunden och kassören utbyter kontanter över disk). 12. Varje transaktion på kontot eller lånet ska lagras i listan över transaktioner för det sparkontot/lånet, med tillhörande klockslag och datum för transaktionen (datum och tid får matas in av kassören - ni behöver inte använda aktuell systemtid) samt en kommentar som kassören skriver in. 13. När en transaktion är utförd och klar, ska användaren (bankkassören) återigen få se listan över alla kunder, för att vara redo att ta emot en ny kund (enligt krav 8). 14. Bankkassö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 bankens kunder, deras konton och transaktioner (inklusive alla ändringar och nya transaktioner 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 8-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 konton, en för transaktioner 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 bankkunder 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 transaktion ska även innehålla information om vilken kassör som utförde den, d v s den aktuella kassörens användarnamn ska lagras tillsammans med varje transaktion som denne utför åt kunden (detta är ett tillägg till krav 3 ovan). Vid varje ny transaktion, t ex insättning eller uttag, ska den här informationen sedan automatiskt lagras i den nya transaktionen 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 12 ovan). 18.3. Automatisk utloggning av kassören om ingen ny transaktion 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, och kunderna ska kunna öppna nya sparkonton och ta nya lån i banken, samt avsluta konton och lån. När programmet avslutas ska naturligtvis även alla dessa förändringar reflekteras i de data som skrivs ut i respektive fil.