English web site
TDDI02 Programmeringsprojekt
Projektförslag: Datorstött bibliotek
Projektförslag: Datorstött bibliotek
Nedan följer ett scenario i vilket en gammal bibliotekarie vill beställa ett enkelt(?) program av er. Hon har en del synpunkter på vad programmet bör klara av, och hennes systerson har bifogat lite idéer på hur man skulle kunna implementera det.Observera att deras `behov' och beskrivningar inte säkert är kompletta, samt att vissa saker de önskar sig är kanske onödiga eller skulle bli för dyra (d.v.s. för svåra) att implementera.
Det är er uppgift att utifrån denna luddiga problemformulering författa en kravspecifikation som beskriver exakt vad programmet skall klara av och hur det kommer att fungera gentemot användaren.
Scenario
I det lilla samhället Bastuträsk med 592 invånare (1989) finns ett litet bibliotek som vårdas ömt av bibliotekarien, f. d. lärarinnan fröken Olga Pettersson. Hennes bibliotek har på sistone blivit flitigt använt då det ingår en del kulturhistoriskt värdefulla verk i samlingarna. Detta har medfört att det börjar bli svårt att manuellt hålla ordning på vem som lånat vad, och när de lånat boken. Tidigare kände Fröken Pettersson sina kunder personligen, men nu har det blivit alldeles för många nya personer att hålla reda på. Behov av hjälpmedel finns alltså, och hennes 15-årige systerson har övertygat henne om att man bör köpa en enkel dator för att klara detta. Fröken Pettersson har nu vänt sig till Er för att beställa ett sådant system.En enkel behovsanalys som ni gjort gav snabbt beskedet att ett enkelt manuellt kortsystem skulle fylla Fröken Petterssons behov under överskådlig framtid. Det visar sig emellertid att de redan införskaffat en dator för ändamålet, då systersonen är så intresserad av (att leka med) datorer. Då inköpet gjorts för medel de fått från kommunen (Norsjö kommun i Västerbotten) anser Fröken Pettersson att den faktiskt även bör kunna användas till det den var avsedd för. Detta och hennes befogade oro över systersonens förmåga att skriva ett sådant program har lett till att hon nu vänt sig till er med följande beskrivning:
En bibliotekaries uppgifter
- Registrera nyinköpta böcker, d.v.s. anteckna deras titel och författare. Om boken redan finns, anteckna att ytterligare ett exemplar inköpts
- Skriva ut ett nytt lånekort till ny eller gammal kund
- Registrera ett lån, d.v.s. vilken bok, vem som lånar och dagens datum.
- 'Återlämna' en lånad bok.
-
Att på olika grunder leta efter böcker och författare, och få reda på
om de finns och i så fall om de finns inne eller är utlånade. Exempel
på frågor kan vara
`vilka böcker av Jan Guillou har ni' och `Har ni en bok som heter Mord Och Inga Visor'? - Att hålla en aktuell lista över alla böcker i biblioteket
- Att skicka ut påminnelselappar till de som lånat en bok för länge
- Samma information lagras på flera ställen, d.v.s. det finns onödig redundans i förslaget. Det skulle försvåra sökningar och ändringar av informationen.
- Datastrukturen var statisk (han föreslog en array med textsträngar), d.v.s. varje person kunde bara låna max 3 böcker, och den kunde bara hålla information om 5000 böcker. Datastrukturen skulle kanske räcka för dagens behov (det finns 4731 böcker i biblioteket) men skulle inte klara några större mängder nya böcker.
- Information om en bok, d.v.s. namnet på författaren och på boken.
- Information om en person, d.v.s. namn och adress.
- En koppling mellan en person och en bok som vi kan kalla ett lån.
Ni meddelar nu Fröken Pettersson att ni skall tänka på detta och återkomma med en kravspecifikation om några dagar. På väg hem kommer ni på att ni glömt fråga vilken sorts användargränssnitt de tänkt sig. Men, ni får väl ge ett förslag på något lämplig grafiskt system och se vad de tycker.
Kommentar till scenariot
Nedan följer lite idéer om hur man kan bygga upp en datastruktur för att handskas med böckerna enligt ovan. När ni börjar veta hur ni vill ha det, så skriver ni en designspecifikation (se `Handledning till projektuppgifterna' för en förklaring).Förslag på hur en datastruktur kan se ut
Ovan nämndes tre typer av information: BOK, PERSON och LÅN. Ett sätt att knyta ihop dessa poster i en pekarstruktur är att bilda två listor, en med alla BOK-poster och en med alla PERSON-poster. I varje PERSON-post `hänger' man sedan en lista med alla LÅN-poster som den personen gjort.
För att undvika att i varje LÅN-post lagra text som beskriver vilken bok som lånats och vem lånaren är, kan man istället låta LÅN-posten peka ut både vilken BOK som lånats och vem låntagaren är (d.v.s. en pekare tillbaka till PERSON-posten). Det kan även vara lämpligt att låta den bok som är utlånad (d.v.s. dess BOK-post) `peka tillbaka på' den LÅN-post som representerar lånet.
Om man vill hålla reda på flera exemplar av samma bok (ett svårare alternativ) kan man t.ex. ändra lite i beskrivningen ovan. Då man inte vill lagra namnet på boken på flera ställen, kan man ha en alternativ BOK-post (vi kan kalla den BOK-KOPIE-post) där det istället för namn på författare och titel finns en pekare tillbaka på det första exemplaret av boken. Det betyder att i listan av BOK-poster som nämndes ovan kan finnas både BOK-poster och BOK-KOPIE-poster, men att BOK-KOPIE-posterna alltid kommer efter en BOK-post.
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
