Projektuppgift - Biblioteket 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 låntagare, böcker och lån ä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) 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 bibliotekssystem som hanterar kundernas lån av böcker och filmer. Tänk er att systemet ska användas av bibliotekarien (vid utlånings/återlämningsdisken) när de betjänar låntagarna i utlånings- och inlämningsdisken. Systemet ska uppfylla ett antal krav som kunden (biblioteket) 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: bibliotekarien som står i den kombinerade utlånings och återlämningsdisken och betjänar en låntagare. 2.1 Följande krav gäller för systemet (för G-nivå) 1. Systemet ska hantera information om låntagarna, varje låntagare har åtminstone ett namn, en adress, ett (unikt) personnummer och ett telefonnummer. Till varje kund hör också en lista som innehåller alla lån som den kunden gjort (både tidigare och nu aktuella utlåningar). 2. Systemet ska även hantera information om böckerna som biblioteket lånar ut. En bok har ett (unikt) id-nummer, en författare och en titel, samt en maximal utlåningstid (ni kan anta att det bara finns två varianter: vissa populära böcker kan bara lånas i 10 dagar, medan andra böcker kan lånas i två månader). 3. Ett lån hör till en viss specifik låntagare och gäller en specifik bok, lånet har dessutom ett datum och en tid för när utlåningen börjar, samt ett sista återlämningsdatum för lånet som beräknas baserat på maximal utlåningstid för den specifika boken. När boken lämnas tillbaka får lånet även ett faktiskt återlämningsdatum (utöver det beräknade datumet). 4. Det finns två olika typer av böcker: "vanliga" tryckta böcker och e-böcker. 5. En tryckt bok kan bara lånas ut till en kund i taget, och är därför alltid antingen utlånad eller tillgänglig i biblioteket.
6. En e-bok är en elektronisk version av en bok, som kan lånas ut till ett antal låntagare i taget (det maximala antalet samtidiga lån är olika för olika e-böcker). En e-bok kan därmed vara tillgänglig om inte maximalt antal aktiva lån uppnåtts, eller fullt utlånad om maximalt antal personer redan har aktiva lån på e-boken. För varje e-bok måste vi därför hålla reda på hur många som just nu har lånat boken. 7. När programmet startar, innan interaktionen med användarna börjar, ska information om böcker, låntagare och deras lån, inklusive både tidigare lån och just nu aktiva lån, 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 böcker/låntagare/lån som ska läsas in. 8. När programmet startas och data lästs in från fil listas sedan alla låntagare (åtminstone personnummer och namn skrivs ut på skärmen) och användaren (bibliotekarien) uppmanas välja en låntagare ur listan genom att mata in dennes personnummer. 9. När bibliotekarien valt en viss person listas den aktuella kundens tidigare lån, respektive aktuella lån på skärmen, i två separata listor, och kassören uppmanas att antingen välja ett lån att jobba vidare med genom att ange id-nummer för den utlånade boken (t ex om låntagaren vill återlämna en bok, eller bara se detaljer om lånet), eller ange att låntagaren vill göra ett nytt lån. 10. Om bibliotekarien har valt ett visst lån ska all information för det lånet och boken det gäller visas på skärmen (för varje lån visas alltså datum och tid för utlåning, sista återlämningsdatum, eventuellt faktiskt återlämningsdatum, samt bokens idnummer, titel, författare och typ - e-bok eller tryckt bok). 11. Låntagaren kan sedan avsluta lånet, d v s bekräfta återlämningen, genom att bibliotekarien anger ett kommando till systemet som betyder "återlämning". Lånet får då ett datum för återlämning - datum får matas in av kassören (ni behöver inte använda aktuell systemtid), och bokens status går från "utlånad" till "tillgänglig" för tryckta böcker, alternativt minskas antalet aktuella låntagare om det rör sig om en e-bok. 12. Om låntagaren istället valde att göra ett nytt lån visas först en lista med idnummer, titel och författare för alla böcker i systemet, och bibliotekarien uppmanas ange id-nummer för boken som låntagaren vill låna, samt datum och tid för utlåningen (datum och tid får matas in av kassören - ni behöver inte använda aktuell systemtid). Systemet kontrollerar att boken är tillgänglig, och om så är fallet registreras ett nytt lån för låntagaren (samt registrerar att boken lånats ut), och sista återlämningsdatum beräknas baserat på bokens maximala utlåningstid och det datum som användaren matat in. 13. När ett nytt lån eller en återlämning är utförd och klar, ska användaren (bibliotekarien) återigen få se listan över alla låntagare, för att vara redo att ta emot en ny kund (enligt krav 8). 14. Bibliotekarien 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 låntagarna och deras lån (inklusive alla återlämningar och nya lån 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 låntagare, en för böcker, en för lån 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 bibliotekarien, 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 bibliotekarien innan listan över låntagare visas på skärmen (se krav 8 ovan) och endast om bibliotekarien 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 lån ska även innehålla information om vilken bibliotekarie som hanterade utlåningen, d v s den aktuella bibliotekariens användarnamn ska lagras tillsammans med varje lån som denne utför åt låntagare (detta är ett tillägg till krav 3 ovan). Ni måste alltså hela tiden hålla reda på vilken
bibliotekarie som är inloggad. Nu ska även aktuellt datum och exakt tid för varje nytt lån eller återlämning 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 11-12 ovan). 18.3. Automatisk utloggning av bibliotekarien om ingen nytt lån eller återlämning genomförts på en viss tid, t ex 5 minuter. Om bibliotekarien 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 bibliotekarien blivit automatisk utloggad visas. 18.4. Bibliotekarien ska kunna lägga in nya låntagare och nya böcker i systemet, samt ta bort låntagare och böcker ur systemet. När programmet avslutas ska naturligtvis även alla dessa förändringar reflekteras i de data som skrivs ut i respektive fil.