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 (en SUN-arbetsstation) 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
Systersonen har, efter att ha läst listan ovan, påpekat att i ett
hockey-program som ägs av en kompis till honom kan man skriva
t.ex. `SÖK G*' och på det viset söka efter alla spelare vars namn
börjar på G. Han påpekar vidare att man naturligtvis måste kunna
stänga av datorn mellan körningarna utan att förlora någon
information. Vidare bifogade han en skiss på hur man skulle kunna
lagra all information. Ni har dock förkastat den på följande grunder:
-
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.
Däremot har ni redan på detta stadium identifierat tre olika typer av
information som med lämplig sammansättning kan lösa det mesta av
ovanstående:
-
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.
Eftersom ni tänker skapa en dynamisk datastruktur (en som kan växa
allt eftersom man stoppar in nya saker) vill ni kanske använda någon
form av pekarstruktur. De tre typerna av information ovan skall då
förstås förses med lämplig plats för pekare till varandra.
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 menysystem eller
kommandosystem 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
(tpm@ida.liu.se),
20 september 1998.
Med tack till Torbjörn Jonsson, Peter Loborg m fl.