Institut for Datalogi Aalborg Universitet

Transkript

1 Institut for Datalogi Aalborg Universitet Titel: M.I.B Tema: Udvikling af programmel Projektperiode: DAT1, 2. september december 2006 Projektgruppe: d101a Gruppemedlemmer: David-Sebastian Bahr Pelle Abelsen Hede Kristian Riishøj Jensen Robin Damsgaard Larsen Mikkel Larsen Pedersen Vejleder: Nicolaj Søndberg-Jeppesen Kopier: 7 Antal sider: 158 Synopsis: Denne rapport er skrevet af gruppe d101a på DAT1-semestret 2006 på Institut for Datalogi på Aalborg Universitet. Rapporten dokumenterer udviklingen af et bibliotekssystem specifikt designet til at håndtere administrationen af MI-gruppens bibliotek. Den anvendte udviklingsmetode er en tilpasset vandfaldsmodel, baseret på vandfaldsmetoden præsenteret i Objekt Orienteret Analyse & Design af Mathiassen et al. samt andre metoder præsenteret i denne kilde. Emner der berøres i rapporten omhandler hovedsagligt udviklingen af programmel i C# med et objektorienteret perspektiv, men kommer også ind omkring hvorledes man kan gemme data i et program, hvorledes data kan hentes fra eksterne resurser over internettet, hvorledes et system kan håndtere afsendelse af mails via. eksterne mailservers og hvordan en variant af Boyer-Moore s søgealgoritme kan implementeres i C#. Det udviklede system er implementeret i C# med.net 2.0 -frameworket.

2 Indhold 1.1 Forord Læsevejledning I Analyse Formål Omgivelser Problem- og anvendelsesområde Systemdefinition Stakeholders Problemområdet Struktur Klasser Definition Klassediagram Adfærdsmønster Tilstandsdiagrammer Anvendelsesområdet Brug Oversigt Aktører Brugsmønstre Funktioner Funktionsliste Specifikation af funktioner Brugergrænsefladen Mål for brug Begrebsmæssig model Interaktionsform Generel interaktionsmodel I

3 4.8 Den tekniske platform Anbefalinger Anbefalinger Strategi II Design 33 6 Indledning Indledning Formål Rettelser til analysen Teknisk platform Udstyr Basisprogrammel Designsprog Arkitektur Designkriterier og arkitektoniske krav Faktortabel Generiske designbeslutninger Komponentarkitektur Eksemplarisk design Komponenter Modelkomponenten Funktionskomponenter BibController LånerController Brugergrænsefladekomponenten Præsentationsmodel III Implementation 56 9 Implementation Indledning Ikke-implementerede features Ikke-analyserede features Dokumentation af programmet DBS-komponent II

4 9.5.1 Serialisation og deserialisation MySQL-databaser Modelkomponent Funktionskomponent Controllere Oprettelse af en låner Aflevering Brugergrænseflade Forsiden Usability-teknikker Exception-håndtering Søgealgoritme Boyer-Moores algoritme Test af vores metode imod alternativer Unit testing Unit test: Litteratur Unit test: LaanerController Testresultater Konklusion IV Studierapport Usability test Forsøgsopstilling og andre præparationer Forsøget Testopgaver Problemliste Vurdering Videre arbejde Proces Indledning Udviklingsmodel Produktrappporten Analysen Design Vurdering Konklusion 122 III

5 A Appendix 124 A.1 Faktortabel A.2 Interview med bruger A.2.1 Spørgsmål A.2.2 Interview nr A.2.3 interview nr A.2.4 interview nr A.3 Proof of concept af brugsmønstre A.4 Interaktionselementer A.5 MySQL-databasen A.6 Testplan A.6.1 Formål A.6.2 Hovedspørgsmål A.6.3 Brugerprofil A.6.4 Metode A.6.5 Opgaveliste A.6.6 Omgivelser og udstyr A.6.7 Testlab-roller A.6.8 Dataindsamling A.7 Transkribering A.8 Interaktionsrum Litteratur 159 IV

6 FORORD 1.1 Forord I denne rapport vil vi præsentere vores brug af de generelle arbejdsmetoder vi har stiftet kendskab til igennem dette semester. Disse vil blive brugt til at foretage en analyse, designe, implementere og teste et IT-system. Det implementerede IT-system er udviklet som et svar på MI-gruppens ønske om digitalisering af deres bibliotek og deres arbejdsgang heri. A- nalyse-afsnittet har til formål at identificere problem- og anvendelsesområdet og efter en analyse af disse, vil vi præsentere vores anbefalinger til videre arbejde. Design-afsnittet vil vi vise, hvorledes designkravene påvirker arkitekturen af systemet og den videre ansvarsfordeling på systemets komponenter. Implementations-afsnittet vil dokumentere interessante dele i implementationen af systemet samt evaluere det udviklede system. En samlet evaluering af systemet foretages som afslutning på implementationsafsnittet, hvor det overordnede produkt (både rapport og system) evalueres. Slutteligt vil en studierapport dokumentere diverse studierelaterede akademiske øvelser, foretaget i relation til projektet, såsom unit tests, usabilitytest med videre samt, hvilken effekt disse kunne have haft som en indkorporeret del af udviklingsmetoden. Slutteligt vil vi gerne takke MI-gruppen for et godt samarbejde under projektet, og deres deltagelse under diverse interviews og tests af programmet. Vi vil også gerne takke vores vejleder, samt reviewer Jens Henrik Hosbond for den konstruktive kritik, gode forslag og vejledning i relation til projektet. 1

7 LÆSEVEJLEDNING 1.2 Læsevejledning I rapporten anvendes følgende notation for lettere at kunne identificere nøglebegreber i teksten. Tabel 1.2 viser notationen, samt eksempler på h- vorledes notationen benyttes i teksten. Element Notation Eksempel Klasse Skrives med fed skrift. Vi er nået frem til de overordnede klasser rolle og litteratur. Hændelse Skrives med Litteratur skal kunne lånes, kursiveret skrift. afleveres, tilføjes... Aktør Skrives med For aktørerne låner og understreget skrift. bibliotekar udarbejdes der aktørspecifikationer. Attributter Skrives indkapslet i. Attributten status angiver, om en bruger er aktiv i systemet eller ej. Konkrete I design-dokumentet Opret reservation anvendes funktioner vil konkrete funktioner da til at... blive skrevet med kursiv. Tabel 1.1: Rapportens notation 2

8 Del I Analyse 3

9 OMGIVELSER 2.1 Formål Formålet med systemet er at effektivisere og simplificere administrationen og brugen af Maskinintelligens-gruppens (MI-gruppen) bibliotek. Det bestræbes at udvikle et system, der bringer effektivisering i forhold til det nuværende papirbaserede system på en række områder. I øjeblikket findes der kun proceedings, bøger og Ph.D.-afhandlinger i boglisten. I det udviklede system ønskes også mulighed for registrering af artikler og tidsskrifter, således disse også kan registreres som lånte, på samme måde som bøger og lignende. Der ønskes også funktionaliteter til nemmere udlån af litteratur og bedre administration på allerede udlånt litteratur. Der ønskes envidere funktionalitet, som muliggør reservering af litteratur. Vi vil i det følgende benævne bøger, Ph.D.-afhandlinger, artikler, proceedings, tidsskrifter osv. som litteratur, da denne betegnelse dækker over alle litteraturtyperne i spil. 2.2 Omgivelser For at illustrere behovet for et alternativt bibliotekssystem til afhjælpelse af de almindelige administrationsrelaterede opgaver forbundet MI-gruppens bibliotek, bliver der i det følgende afsnit beskrevet den nuværende situation samt det nuværende system i anvendelse. Maskinintelligens-gruppen (MI-gruppen) på Institut for Datalogi har et fagbibliotek i lokale E1-101a. Her kan Ph.D.-studerende, ansatte og gæster låne forskelligt litteratur. Det er imidlertid blevet en større opgave at administrere biblioteket. Litteraturen skal stå på en litteraturliste som personer i MI-gruppen kan skrive sig på, når de vil udføre lån. Hver gang et nyt stykke litteratur skal føjes til listen skal en større process gennemføres. Først skal litteraturen skrives ind i en BibTeX-entry, som vha. et script bliver genereret til en HTML-fil med hjælp fra TeX2HTML. Derefter skal denne litteraturliste udskrives og hænges på opslagstavlen i biblioteket. Informationer vedrørende lån anføres manuelt fra den gamle liste til den nye af bibliotekaren. Denne opdateringsproces er træg og langsommelig, og der hersker bred enighed om, at den vil kunne simplificeres dette ønskes løst vha. et ITsystem. De nuværende lånere har også et problem med det nuværende En proceeding er en samling af artikler fra en konference. 4

10 PROBLEM- OG ANVENDELSESOMRÅDE analoge system, idet det ofte er besværligt at finde den litteratur man ønsker at låne på boglisten. På nuværende tidspunkt kan man ikke låne f.eks. artikler, hvilket ligeledes ønskes integreret i et nyt bibliotekssystem. Som yderligere beskrivelse er ovennævnte arbejdsgang beskrevet grafisk i et rigt billede på figur 2.1. Konflikterne beskrevet i teksten ovenfor noteres ved krydsede klinger i figuren. Lånere skriver sig på bogliste ved lån af litteratur Boglisten udskrives Bogliste Bibliotekaren opdaterer boglisten manuelt med hvilke lånere der har lånt de forskellige bøger Digital bogliste Digital bogliste opdateres Bibliotekarens computer Et nyt stykke litteratur tilføjes biblioteket Bibliotekar Figur 2.1: Rigt billede over problemområdet. 2.3 Problem- og anvendelsesområde Figur 2.2 viser hvorledes et bibliotekssystem kunne indgå i biblioteket ud fra kriterierne defineret i BATOFF-kriterierne i afsnit 2.4. I kassen Låner, vil en typisk bruger sidde i sit gruppelokale og være i stand til at lave opslag i systemet. Det kunne f.eks. være hvorvidt en given bog er udlånt og om man ønsker at reservere denne eller hente en BibTeX-entry til en bog. I kassen Bibliotek vil de enkelte brugere kunne foretage alle de handlinger, som også kan udføres i kassen Låner, samt foretage handlinger som udlån og aflevering af litteratur. Dette betyder implicit at vi ønsker mulighed for senere at implementere en slags klient til systemet således, at lånere kan få 5

11 SYSTEMDEFINITION adgang til dele af systemets funktionalitet via. en ekstern klient. I kassen Bibliotekar vil den pågældende bibliotekar være i stand til at indføre nye bøger og andet litteratur og indføre nye brugere i systemet. Låneren, i sit eget kontor Bogreol Efter omorganisering Bibliotekscomputer Bogreol Bogliste Bibliotekar Bibliotekarens computer Figur 2.2: Transitionsbillede over den gamle arbejdsgang til det nye system. 2.4 Systemdefinition Et af de første trin i udviklingen af systemdefinition var at øge vores kendskab til projektets problemområde, som er de omgivelser, der skal administreres og overvåges af vores færdige system. Derfor var det vigtigt at se, hvordan det nuværende bibliotekssystem fungerer (se evt. afsnit 2.2). Besøget har givet gruppen en større forståelse for den nuværende situation i biblioteket og hjalp med at identificere konflikterne i dette, som det nye system skal løse. På denne baggrund har vi udarbejdet de såkaldte BATOFF-kritierer for det nye system. Definition på BATOFF (fra [Mathiassen et al., 2001, s.37-38]) er: Betingelser: Betingelserne for systemets udvikling og brug. Anvendelsesområde: De dele af en organisation, som administrerer, overvåger eller styrer et problemområde. 6

12 SYSTEMDEFINITION Teknologi: Den teknologi, som systemet udvikles til og ved hjælp af. Objekter: De væsentlige objekter i et problemområde. Funktioner: De systemfunktioner, som understøtter arbejdsopgaver i anvendelsesområdet. Filosofi: Den filosofi, der ligger bag IT-systemets anvendelse. Samlet er vi nået frem til følgende: B: Systemet skal designes på en sådan måde, at lånere ved hjælp af selvbetjening hurtigt og enkelt kan udføre deres gøremål (Låne, aflevere, reservere, se afleveringsfrister osv.) i biblioteket, samt at bibliotekarens arbejdsgang lettes. A: Anvendelsesomådet dækker personer med direkte relation til MIgruppen. Det vil sige tilknyttede professorer, lektorer, adjunkter, Ph.D.- studerende, og forskningsassistenter(se desuden stakeholder-undersøgelsen 2.5 på næste side for yderligere uddybning). T: Systemet skal kunne køre på en almen PC med.net- og netværksundersøttelse. O: Bibliotekets litteratur, lånere og bibliotekarer er de væsentligste objekter i problemområdet. F: Systemet skal kunne varetage de daglige funktioner i et bibliotek såsom lån og reserverationer, samt fungere som et værktøj til at varetage administrationen af lånere og litteratur, således den fungerende bibliotekars arbejdsgang lettes. F: Systemet skal fungere som et administrativt værktøj. Ud fra disse kriterier udarbejdede vi den endelige systemdefinition som lyder: Et system der skal varetage de daglige funktioner i et bibliotek på selvbetjeningsbasis. Systemet skal primært administrere litteratur men skal også administrere brugere, afleveringsfrister og andre relaterede biblioteksfunktioner. Systemet skal baseres på en almen PC med.net- og netværksunderstøttelse. Designet skal udføres på en sådan måde, at brugeren hurtigt og enkelt kan udføre deres gøremål i biblioteket. 7

13 STAKEHOLDERS 2.5 Stakeholders For at forstå hvilke områder en implementering af vores system kan påvirke, har vi udført en stakeholder-undersøgelse [Preece et al., 2002, s. 171]. Primære stakeholders er personer der ofte bruger systemet, sekundære stakeholders er personer der ikke benytter systemet direkte og personer der benytter systemet gennem en mellemmand, som for eksempel kunne være bibliotekaren. Tertiære stakeholders er personer der bliver påvirket af systemets implementation i omgivelserne. I vores tilfælde er lånerne og bibliotekaren de primære stakeholders, da de benytter systemet ofte. De sekundære stakeholders kan identificeres som gæste-ph.d.-studerende samt gæste-lektorer, idet de typisk vi tilgå MI-gruppens bibliotek ved at benytte en mellemmand såsom bibliotekaren eller etablerede lånere. De tertiære stakeholders kan identificeres som bibliotekaren og teknikerne tilknyttet bygningen, idet de indirekte er påvirket af systemets implementation, da de står for den daglige drift. Hvis en låner for eksempel har problemer, henvender han/hun sig til bibliotekaren, som i visse tilfælde måske går videre til teknikerne. 8

14 Kapitel 3 Problemområdet 3.1 Struktur Analysen af problemområdet skal afdække modellerede objekter og hændelser. Afsnittet vil først præsentere de klasser, attributter og hændelser som vi mener modellerer problemområdet. Herefter vil den struktur de indgår i, argumenteres for og vises. Endeligt vil de forskellige adfærdsmønstre vises vha. en hændelsestabel og deres adfærd vil blive modelleret i tilstandsdiagrammerne. 3.2 Klasser I dette afsnit vil vi se nærmere på klasserne samt deres attributter og hændelser. Klasserne har vi fundet ved at observere de enkelte elementer i problemområdet. Vi er nået frem til de overordnede klasser rolle og litteratur. Klassen rolle er inddelt i låner og bibliotekar og litteratur er inddelt i bog, Ph.D.-afhandling, tidsskrift, artikel og proceeding. Vi vil præsentere argumentation for superklasserne rolle og litteratur samt forklare hvorfor disse er abstrakte klasser Definition Når man betragter et objekt i den virkelige verden, er der forskellige måder man kan søge at beskrive den på, f.eks. farve, størrelse og form. Denne tanke har vi anvendt til at finde attributter for de følgende klasser, ved systematisk at opremse kendetegn for de enkelte klasser. Dette er ikke en fuldstændig metode til at finde attributter og en vis delmængde er derfor 9

15 KLASSER også fundet gennem afledning fra adfærdsmønstre, som vil blive beskrevet nærmere i afsnit 3.3. Litteratur Ved at observere de forskellige litteraturtyper i MI-gruppens bibliotek er vi kommet frem til tabel 3.1 på modstående side, der viser attributterne, som subklasserne indenfor litteratur besidder. Klasserne er listet i den øverste vandrette række, mens de tilhørende mulige attributter er listet i den venstre lodrette kolonne. Et kryds i et felt angiver en tilhørende attribut. Attributten litteraturid dækker over materialets tilsvarende ID internt i bibliotekssystemet. Hvert stykke litteratur har således et individuelt identifikations flag, således det er lettere at finde i systemet og finde ud af hvem den er lånt af. Attributten lånt af angiver information om hvilken låner der evt. har lånt litteraturen og attributten reserveret af angiver hvilken låner der eventuelt har reserveret litteraturen. Litteraturen indeholder således selv information om hvem der har lånt eller reserveret det. Som det kan aflæses af tabellen, er det kun attributterne forfatter, forlag, udgave, isbn, resume og editor, som varierer fra subklasse til subklasse; de øvrige attributter er fælles for resten af klasserne. Dermed kan der introduceres en abstrakt klasse, litteratur, som indeholder disse attributter og lader de øvrige klasser kun specifikt indeholde de førnævnte attributter, der skiller sig ud. De øvrige klasser indeholder dog også attributterne, som er i den abstrakte litteratur klasse, idet dennes attributter nedarves til de øvrige klasser. Litteratur klassen er abstrakt, da der ikke findes konkrete objekter i problemområdet af klassen litteratur. Ligeledes har vi set på hændelser (en samlet oversigt ses i tabel 3.4 på side 13). Litteratur skal kunne lånes, afleveres, tilføjes, reserveres, fjernes, hjemkaldes, bortkomme og findes igen. I forhold til det allerede eksisterende bibliotekssystem har vi tilføjet hændelsen reserveret. Lån og aflevering gøres i det analoge system ved at tilføje eller slette sit navn på boglisten ud for det stykke litteratur man ønsker at låne eller aflevere. Tilføjelse og fjernelse af litteratur i samme system, udføres ved hhv. at tilføje eller slette bogen på listen, og derefter udskrive en opdateret liste. En bog kan erklæres bortkommen ved at skrive det på listen. Vi vil nu se på den abstrakte klasse rolle. Grunden til at rolle er defineret som værende abstrakt, er fordi der ikke konkret eksisterer konkrete objekter af klassen rolle, men at egenskaber og attributter nedarves fra denne til dens subklasser. Rolle er en fælles betegnelse for de roller en bruger kan 10

16 KLASSER Attributter Artikel Proceeding Ph.D.-afh. Tidsskrift Bog Forfatter Titel Keywords ISBNnummer Forlag Sideantal Udgave Årstal Placering Resume Editors LitteraturID Udlånt af Reserveret af Afleveringsfrist Tabel 3.1: Attributter for subklasserne af superklassen litteratur 11

17 KLASSER tage, når han interagerer med systemet og kan splittes op i to underoller; interaktionen med systemet kan ske som låner eller bibliotekar. Vi har valgt at se på låner og bibliotekar hver for sig. Låner Attributterne for klassen låner kan ses i tabel 3.2. En låners attributter består hovedsagligt af information om en givet låner i systemet. Attributterne dækker over en låners navn, -adresse, hans lån, hans reservationer samt hviklen status i systemet han har på nuværende tidspunkt. Generelt set er attributterne ret sigende og findes også i den virkelige verden, mens attributten Status angiver, om den pågældende bruger er aktiv i systemet eller ej. Atributter: Låner Fornavn Efternavn Lokale Telefon Status Tabel 3.2: Attributter for klassen låner Af hændelser en person af klassen låner kan komme ud for eller udføre kan nævnes, at han kan tilføjes, slettes, afgå samt låne, aflevere og reservere litteratur. Disse hændelser kan ses opsamlet i en hændelsestabel på figur 3.4 på næste side. Bibliotekar En bibliotekars attributter er lidt forskellige fra en låners, da man også gerne vil vide hvor man kan få fat i ham, skulle der være noget galt med systemet. En bibliotekars attributter er navngivet sigende og dækker generelt over information man kunne forestille sig kunne være nyttig til hverdagen. Attributten status dækker over om han er aktiv eller ej. Bibliotekaren skal kunne tilføje og fjerne brugere og litteratur samt erklære litteratur bortkommet og funden. Vi har valgt kun at lade bibliotekaren varetage disse administrative opgaver, da man må formode, at bibliotekaren har det bedste overblik over systemet. Bemærk her, at bibliotekaren ikke automatisk betragtes som en låner i systemet, selvom han måske i praksis selv bruger systemet i rollen som låner. Attributterne for klassen bibliotekar findes i tabel 3.3. De hændelser en bibliotekar kan være ude for eller kan udføre ses opsummeret i hændelsestabellen i tabel 3.4 på modstående side. 12

18 KLASSER Atributter: Bibliotekar Fornavn Efternavn Lokale Telefon Status Tabel 3.3: Attributter for klassen bibliotekar Samlet beskriver tabel 3.4 klasserne og deres hændelser. Tegnet * beskriver at en hændelse kan foregå fra ingen til flere gange, mens + beskriver at hændelsen kan foregå ingen eller én gang. Hændelse \Klasse Litteratur Låner Bibliotekar Lånt * * Afleveret * * Reserveret * * Tilføjet + * Meldt bortkommet * * Meldt fundet * * Hjemkaldt * Fjernet + * Oprettet + * Afgået + + Ansat + Slettet + * Tabel 3.4: Hændelsestabel Klassediagram Forholdene mellem klasserne beskrevet i sidste afsnit kan modelleres i et klassediagram, der således viser de indbyrdes relationer imellem disse. Diagrammet laves for at skabe overblik over hvorledes de forskellige klasser indgår i en helhed i det system som ønskes designet. Figur 3.1 på den følgende side følger reglerne opstillet i [Mathiassen et al., 2001] for associering, aggregering og generalisering. Associeringsstrukturen beskrives ved en linje mellem objekter og beskriver en sammenhæng mellem dem, såsom kender eller er-forbundet-med. Aggregeringsstrukturen 13

19 ADFÆRDSMØNSTER Ph.D.-afhandling Bog Person Adjunkt Gæste-professor Litteratur Bibliotekar Låner Gæste-Ph.D.-stud Proceeding 0..* Professor Ph.D.-stud 2..* Artikel Tidsskrift Lektor 2..* 0..* Figur 3.1: Klassediagrammet beskrives ved en linje med en diamant på enden af stregen mellem objekter. Denne struktur anvendes til at beskrive et objekt ud fra dets bestanddele. En generaliseringsstruktur er en mængde specialiserede klasser med relation til en generel klasse(superklasse). Denne relation kan vises med linier gående fra de specialiserede klasser til superklassen, med en pil for enden af linien til denne. Artikel, bog, Ph.D.-afhandling,tidsskrift og proceeding kan hermed siges at have en er-en relation til den generelle, abstrakte superklasse litteratur. Kardinaliteterne ude for aggregeringerne angiver en mængdesammenhæng i aggegeringen. Eksempelvis kan kardinaliterne ved proceeding og artikel, i klassediagrammet, læses som, Nul eller flere proceedings kan indeholde to eller flere artikler. Grunden til, at antallet af artikler skal være 2 skyldes, at en proceeding, der kun indeholder en artikel, er en artkel i sig selv og ikke en artikel samling. En proceeding består derfor altid minimum af 2 artikler. 3.3 Adfærdsmønster For at kortlægge de forskellige klassers adfærd i systemet, udarbejdes tilstandsdiagrammer for de enkelte klasser. Tilstandsdiagrammerne beskriver, hvilke tilstande et objekt fra en given klasse kan befinde sig i og hvilke handlinger objekterne kan foretage sig fra de oprettes til de dør i systemet. Ved at kortlægge deres adfærd, øges forståelsen af hvorledes de indgår i systemet. Nedenfor ses tilstandsdiagrammerne for klasserne fra klassediagrammet på figur

20 ADFÆRDSMØNSTER Tilstandsdiagrammer Bibliotekar Tilføjer Fjerner Melder bortkommet Afgår Ansættes Opretter Sletter Melder fundet Ansættes Sletter Tilføjer Fjerner Opretter Melder bortkommet Melder fundet I stilling Afgår Figur 3.2: Tilstandsdiagram for klassen Bibliotekar Bibliotekar Adfærdsmønstret for et objekt af bibliotekar-klassen ses på figur 3.2. En bibliotekar oprettes ved sin oprettelse i systemet. Bibliotekaren kan foretage en række handlinger, som hovedsagligt ikke ændrer ved dennes egen tilstand, men påvirker dens omgivelser (navnlig litteratur og låner). Når en bibliotekar melder sin egen afgang, dør denne i systemet. Låner Afleverer Reserverer Låner Afgår Oprettes Oprettes Eksisterer Afleverer Reserverer Afgår Låner Figur 3.3: Tilstandsdiagram for klassen Låner Låner Adfærdsmønstret for en låner ses på figur 3.3. En låner oprettes ved sin oprettelse i systemet. En låner kan udføre en række handlinger uden at ændre sin egen tilstand. Først ved sin afgang dør et objekt af låner-klassen. Litteratur Adfærdsmønstret for objekter af klassen litteratur ses på figur 3.4 på den følgende side. Et objekt af klassen litteratur fødes ved at det pågældende stykke litteratur tilføjes til bibliotekets litteratursamling. Tilstandsændringer sker når litteraturen udlånes. Det vil sige når et objekt af klassen låner påvirker et objekt af klassen litteratur ved at foretage et 15

21 ADFÆRDSMØNSTER Litteratur Tilføjes Lånes Reserveres Afleveres Fjernes Meldes bortkom. Hjemkaldes Meldes fundet Tilføjes Ledig Meldes fundet Meldes bortkom. Afleveres Lånes Hjemkaldes Reserveres Meldes bortkom. Meldes fundet Fjernes Udlånt Fjernes Figur 3.4: Tilstandsdiagram for superklassen litteratur lån, ændres tilstanden af litteratur-objektet til udlånt. Ved en lignende proces kan et udlånt objekt af litteratur-klassen afleveres. Derudover kan et udlånt litteratur-objekt også blive reserveret af et objekt fra klassen låner. Et objekt af klassen litteratur kan dø på to måder. Det kan bortkomme (både når det er udlånt og ulånt) eller hvis en bibliotekar fjerner litteraturen fra systemet og biblioteket (f.eks. hvis et stykke litteratur er forældet). 16

22 Kapitel 4 Anvendelsesområdet 4.1 Brug Efter at have analyseret problemområdet, skal anvendelsesområdet analyseres. Anvendelsesområdet er tidligere defineret som En organisation, der administrerer, overvåger eller styrer et problemområde. I vores bibliotekssystem vil anvendelsesområdet være defineret som aktørerne og de handlinger, der foretages i det nuværende bibliotek, samt handlinger der ønskes mulighed for at udføre, som det udviklede system siden skal hjælpe aktørerne med at foretage. For at identificere disse handlinger detaljeres aktørerne og deres forventede brug af bibliotekssystemet. Dette gøres blandt andet ved hjælp af en aktørtabel, der giver oversigt over hvilken interaktion de forskellige typer aktører har med systemet, en aktørspecifikation, der fastlægger de forskellige aktørers grundlæggende behov når de interagerer med systemet, samt detaljerede brugsmønstre, der viser de førnævnte interaktioner. Af aktører i anvendelsesområdet kan nævnes bibliotekarer samt lånere, der skal anvende systemet til at administrere elementer i problemområdet såsom boglisten og litteraturen Oversigt I henhold til OOA&D-metoden er det hensigtsmæssigt at se på, hvordan aktører interagerer med vores system med henblik på at tilpasse systemet bedst muligt til anvendelsesområdet. Dette gøres ved at udarbejde såkaldte brugsmønstre, der giver et overblik over interaktion mellem aktører og systemet. Figur 4.1 på næste side viser en sammenhæng mellem de relevante brugsmønstre og aktørerne. Senere i kapitlet vil vi præsentere de enkelte brugsmønstre. 17

23 BRUG Interaktionsform\ Aktør Låner Bibliotekar Lån litteratur Reserver litteratur Aflever litteratur Søg litteratur Søg låner Slet låner Opret låner Tilføj litteratur Fjern litteratur Meld litteratur bortkommet Meld litteratur funden Rediger litteratur Rediger låner Opret bibliotekar Rediger bibliotekar Tabel 4.1: Aktørtabellen afspejler aktørene låner og bibliotekar og deres interaktion med systemet Denne tabel kan grafisk modelleres, som på figur 4.1 på modstående side. Dette kaldes et brugsmønsterdiagram, og viser sammenhængen mellem de forskellige interaktionsmuligheder aktørerne har med systemet. Ved at benytte et brugsmønsterdiagram kan man også hurtigt identificere om systemets aktører har fælles brugsmønstre og fælles interaktionsrum Aktører For aktørerne låner og bibliotekar udarbejdes der aktørspecifikationer. En aktørspecifikation består af en aktørs rolle i forhold til bibliotekssystemet, og en aktørkarakteristik der beskriver hvilke specielle forhold, der gør sig gældende for en aktørs interaktion med systemet. Eksempler gives i aktørspecifikationen for at gøre det lettere at anskueliggøre, hvordan en aktør kan interagere med systemet. Aktørspecifikationerne kan ses på tabel 4.2 på side 20 og tabel 4.3 på side 22. Det bør noteres at selvom begge aktører har brug for en vis grad af sikkerhed i systemet, er det meget forskelligt hvilken grad af sikkerhed de behøver. De fejl en låner kan udføre i systemet, er begrænset til at påvirke informationsrelationer i henhold til, hvilke lån og reservationer andre lånere har udført. Hvis en låner udfører en af disse fejl, har det ikke en 18

24 BRUG Lån Litteratur Reserver Litteratur Aktør Låner Aflever Litteratur Søg Litteratur Rediger låner Søg Låner Slet Låner Opret Låner Tilføj litteratur Slet litteratur Aktør Bibliotekar Meld litt. bortkommet Meld litt. funden Rediger litteratur Opret bibliotekar Rediger bibliotekar Figur 4.1: Overordnet brugsmønsterdiagram. Diagrammet afspejler henholdsvis låner og bibliotekar som aktører og hvilke brugsmønstre disse vil have i vores system 19

25 BRUG Aktør: Låner Formål: En person i MI-gruppen. Generelt for alle personer er, at de nemt og hurtigt skal kunne finde og låne en bog. Karakteristik: Systemets lånere har generelt behov for at kunne udføre deres gøremål uden større risiko for fejl. Disse fejl kan for eksempel være at låne litteratur i det forkerte brugernavn eller låne det forkerte stykke litteratur. Lånere kan have et varierende kendskab til brug af computersystemer. Eksempler: En låner ønsker at låne et givent stykke litteratur og foretager opslag i systemet på det pågældende værk. Såfremt værket er tilgængeligt, kan låneren nu låne værket. Hvis værket er udlånt, kan låneren vælge at se, hvilken anden låner der har lånt det, eller vælge at reservere materialet til efter materialets aflevering. Tabel 4.2: Aktørspecifikation for lånere direkte indflydelse på systemets drift, idet lånere kun indirekte bør kunne ændre i systemets data. Derimod har en bibliotekar mulighed for at udføre ændringer i systemet, der kan påvirke hele dets drift, idet han kan redigere direkte i systemets data ved at redigere eller slette disse. Derfor har en bibliotekar brug for høj sikkerhed, således driften ikke forstyrres utilsigtet. Ydermere skal systemet være sikret fra ekstern adgang, der ikke har relation til MI-gruppen, idet det ville være uhensigtsmæssigt, hvis folk uden tilknytning til biblioteket kunne ændre i systemets data Brugsmønstre Brugsmønstrene er udarbejdet med udgangpunkt i de hændelser, som er tilknyttet klasserne, samt hvordan brugerne vil interagere med systemet. For at øge overskueligheden er brugsmønstrene for at udføre et lån og udføre en reservation adskilt, selvom disse principielt ville være delmønstre af et samlet brugsmønster i en normal arbejdsgang. Figur 4.2 på næste side viser brugsmønstret for lån af litteratur i biblioteket. Indirekte vises også brugsmønstret for søgning. En låner befinder sig i biblioteket ved biblioteksterminalen, hvorefter han søger efter litteratur. Ved succesfuld søgning, registrerer han litteraturen som lånt under sit navn, hvorefter det er muligt at foretage en ny søgning eller afslutte handlingen. Reservationsbrugsmønstret set på figur 4.3 på modstående side følges af 20

26 BRUG Lån Låner Litteratur Søg Litt. ikke fundet Søgning mislykket Søg i litteratur Vis resultat Lån i litteratur Søg igen Søg igen Søg Litt. fundet Søg litt. Resultat vist Søgning vellykket Afslut Litt. lånt Lån litt. Afslut Afslut Figur 4.2: Brugsmønster for lån af litteratur Reservation Låner Litteratur Søg igen Litt. ikke fundet Søgning mislykket Udfør Søgning Udfør Reservation Gå til bibliotek Søg Søg litt. Resultat vist Søg igen Søg igen Litt. fundet Reserver litt. Søgning vellykket Afslut Afslut Litt. res. Afslut Figur 4.3: Brugsmønster for reservation af litteratur 21

27 BRUG Aktør: Bibliotekar Formål: Bibliotekaren skal udføre handlinger såsom at tilføje og fjerne brugere og litteratur, samt erklære litteratur for bortkommet og fundet. De handlinger, der udføres i rollen som bibliotekar, kan fælles betegnes som administration af bibliotek. Karakteristik: En bibliotekar har brug for høj sikkerhed i systemet, herved udtrykt ved lav risiko for at lave fejl og at der ikke forekommer uønsket datatilgang fra eksterne kilder. En bibliotekar skal ikke kunne slette en bog eller en låner ved et uheld. Derudover har bibliotekaren behov for at handlinger kan udføres simpelt og hurtigt. Eksempler: Bibliotekaren modtager besked om en ny person ved MI-gruppen og opretter derefter denne som låner i systemet vha. denne adresse. Ydermere opretter bibliotekaren nyt litteratur i systemet, således dette er tilgængeligt for lånere. Tabel 4.3: Aktørspecifikation for bibliotekar Aflevering Aflever litt. Låner Litteratur Aflever litt. Litt. afleveret Slut Aflever litteratur Figur 4.4: Brugsmønster for aflevering af litteratur lånere, i et mønster meget lig med brugsmønstret for et lån. I stedet for at man decideret får lov til at låne et stykke litteratur, bliver en låner ved reservation registreret som havende reserveret det pågældende litteratur, hvorefter der kan foretages endnu en søgning eller man kan afslutte processen. Figur 4.4 viser brugsmønstret for aflevering af litteratur. Brugsmønstret beskriver situationen hvor en låner ønsker aflevere en mængde litteratur. Handlingen for aflevering udføres for hvert stykke litteratur, der skal afleveres. Dette fortsætter indtil al ønsket litteratur er afleveret, hvorefter handlingen afsluttes, og brugsmønstret er gennemført. Vedligeholdelsesmønstret set på figur 4.5 på modstående side følges af bibliotekaren. Ved indikation af, at systemet skal vedligeholdes, har bibliotekaren mulighed for at udføre de handlinger, som anses for værende al- 22

28 BRUG Vedligehold bibliotek Rediger låner Slet litt. Rediger litt. Tilføj litt. Bibliotekar Låner Litteratur Vedligehold biblio. Slut Slet låner Opret låner Tilføj litt. Slet litt. Meld litt. bortkom. Meld litt. funden Rediger låner Rediger litt. Opret låner Slet låner Meld litt. bortkommet Meld litt. funden Figur 4.5: Brugsmønster for vedligeholdelse af bibliotek Tilføj litteratur Tilføj litt. Bibliotekar Litteratur Tilføj litt. Tilføj litt. Litt. tilføjet Slut Figur 4.6: Brugsmønster for tilføjelse af litteratur mene for bibliotekarens arbejdsgang. Herunder er mønstret slet låner, opret låner, tilføj litteratur som tidligere beskrevet, fjern litteratur, meld litteratur bortkommet, meld litteratur funden, rediger låner og rediger litteratur. Figur 4.6 viser brugsmønstret for at tilføje litteratur til systemet. Bibliotekaren modtager et nyligt anskaffet litteratur og indikerer overfor systemet, at der ønskes et stykke litteratur tilføjet. Et givent stykke materiale tilføjes systemet og handlingen kan hermed enten afsluttes såfremt der ikke er mere litteratur der skal tilføjes, eller gentages såfremt der er mere litteratur der skal tilføjes systemet. Handlingerne tilføj litteratur, slet litteratur, litteratur bortkommet og opret bruger og de andre handlinger beskrevet i figur 4.5 følger et mønster meget lig dette, og er derfor ikke selvstændigt beskrevet. 23

29 FUNKTIONER 4.2 Funktioner I det følgende afsnit vil systemets funktioner fastlægges på baggrund af brugsmønstrene, samt de klasser og hændelser som er identificeret i beskrivelsen af problemområdet. Formålet med funktionsanalysen er at udarbejde en komplet funktionsliste med specifikationer af systemets mere komplekse funktioner Funktionsliste Nedenfor i tabel 4.4 vises den komplette funktionsliste af systemet fundet gennem undersøgelse af brugsmønstrene i forrige afsnit. Funktionerne dække de mest almindelige handlinger som vi mener kan foretages i et bibliotek. Søg litteratur Kompleks Aflæsning Søg låner Kompleks Aflæsning Reserver litteratur Kompleks Opdatering Lån litteratur Medium Opdatering Opret låner Medium Opdatering Meld litt. bortkommet Medium Opdatering Meld litt. fundet Medium Opdatering Opret bibliotekar Medium Opdatering Aflever litteratur Simpel Opdatering Vis lån Simpel Aflæsning Vis reserveringer Simpel Aflæsning Rediger låner Simpel Opdatering Slet låner Simpel Opdatering Tilføj materiale Simpel Opdatering Rediger litteratur Simpel Opdatering Rediger låner Simpel Opdatering Rediger bibliotekar Simpel Opdatering Tabel 4.4: Funktionsliste Specifikation af funktioner Dette afsnit vil indeholde en udspecificering af de mere komplekse funktioner i den samlede funktionsliste. Hensigten med den udspecificeringen er at skabe større overblik over systemets mere komplekse funktioner, og hvilke subfunktioner de gør brug af. 24

30 FUNKTIONER Søg litteratur Søg Bog Kompleks Aflæsning Søg Artikel Kompleks Aflæsning Søg Ph.D..afhandling Kompleks Aflæsning Søg Proceeding Kompleks Aflæsning Søg Tidsskrift Kompleks Aflæsning Tabel 4.5: Specificering af Søg litteratur Funktionen for søgning i litteratur udspecificeret i tabel 4.5 er en del af brugsmønstret for at låne et stykke litteratur. Funktionen dækker over søgning i systemets tilgængelige information omkring litteratur, og består således af forskellige typer af søgning i de respektive mængder af litteratur. Dette gøres med en søgealgoritme, som anvender en række keywords påhæftet objekter af litteratur klassens subklasser, samt anden information såsom titel og forfatter til at finde relevente hits. Søg låner fungerer principielt på samme måde, dog søger den i listen over registrerede/aktive lånere via. eller anden information og derfor udspecificeres denne ikke her. Reservation Aflæs litteraturstatus Medium Aflæsning Opret reservation Medium Opdatering Tabel 4.6: Specificering af Reserver litteratur Funktionen for reservation af litteratur specificeret i tabel 4.6 består af 2 underfunktioner. Den ene har til formål at aflæse litteraturstatus og den anden at registrere reservationen. Den første har til formål at aflæse status for det stykke litteratur en låner ønsker at låne. Hvis litteraturen allerede er lånt ud eller reserverert, vil denne funktion give besked om, at litteraturen allerede er udlånt, og returnere tidligst mulige dato for lån. Skulle en låner ønske at reservere dette stykke udlånte litteratur, anvendes den sidstnævnte funktion til at udregne datoen for, hvornår litteraturen er tilgængelig igen samt opdatere systemets data med den nye reservation. Resten af funktionerne i listen er ikke vældigt interessante at udspecificere, da de hovedsagligt bare opdaterer en mængde information påhæftet et objekt eller en liste, eller viser gældende information om litteratur objekter for en låner eller en bibliotekar. 25

31 MÅL FOR BRUG 4.3 Brugergrænsefladen For at finde ud af, hvilken type brugergrænseflade systemet skal benytte, er det nødvendigt at gøre sig nogle overvejelser omkring, hvorledes brugbarhed og brugeroplevelse prioriteres samt hvilken begrebsmæssige model, der benyttes. Derudover skal det overvejes, hvilke interaktionsformer brugeren skal anvende for at tilgå systemet samt hvilke interaktionsrum vi kan forvente at skulle udspecificere senere i designfasen. Ydermere er der udarbejdet et mock-up-interface for bibliotekssystemets lånere på baggrund af foregående undersøgelser. Til slut beskrives kort den tekniske platform systemet er planlagt til at fungere på. 4.4 Mål for brug For at definere hvilke mål for design vi vil forsøge at realisere [Stage, 2006], har vi udarbejdet en usability-tabel. Tabel 4.7 på modstående side viser, h- vorledes vi har valgt at prioritere design mål for systemet for de forskellige brugertyper inden for kategorierne anvendelighed og brugeroplevelse. Ved tidligt at prioritere, hvilke af disse aspekter, vi finder vigtige for systemets fremtidige brugere, får vi et bedre overblik over, hvilken type interaktivt system, vi skal designe. Idet vi skal udvikle et system til administration af et forskningsbibliotek, har vi overvejende vægtet aspekterne i hele kategorien anvendelighed højt for både de fremtidige lånere og bibliotekarer, idet systemet skal være let tilgængeligt og letanvendeligt for at man tager sig tid til at benytte det. Hvis ikke disse krav er overholdt, kan det medføre, at brugerne finder systemet besværligt og ikke ønsker at benytte det. I kontrast er aspekterne inden for kategorien brugeroplevelse generelt vægtet lavt, idet vi ikke vil lægge ret stor vægt på, om brugerne f.eks. finder det sjovt eller æstetisk tilfredsstillende at benytte systemet. Som en uddybende bemærkning til tabellen, bemærkes det nok at den er på engelsk. Grunden til dette er at oversættelsen af kravene Effectiveness og Efficiency er stort set det samme. Det betyder at man ikke rigtig kan skelne mellem de to i en dansk version af tabellen, og derfor er det engelske sprog bibeholdt. Yderligere vil vi gerne specificere, hvad ordene Effectiveness og Efficiency så dækker over, da disse begreber kan give anledning til forvirring. Effectiveness dækker over, hvor godt systemet udfører de opgaver, det er beregnet til [Preece et al., 2002]. Efficiency dækker over, hvor godt systemet er til at assistere brugere af systemet i at bruge systemet mest effektivt [Preece et al., 2002]. 26

32 BEGREBSMÆSSIG MODEL Vigtigt+ Vigtigt Vigtigt- N/A Anvendelighed Effectiveness Efficiency Safety Utility Brugeroplevelse Learnability Memorability Satisfying Enjoyable Fun Entertaining Helpful Motivating Aesthetically pleasing Supportive of creativity Rewarding Emotically fulfilling Tabel 4.7: Symbolet angiver en låner i systemet og symbolet angiver bibliotekaren. En markering i N/A kolonnen betyder vi har valgt ikke at gøre en bevidst indsats for at opfylde disse krav. 4.5 Begrebsmæssig model Inden en bestemt interaktionsform for bibliotekssystemet lægges fast, er det værd at bruge et øjeblik på at undersøge hvilke muligheder der eksisterer. Interaktionsformer er typisk baseret på en eller flere kendte begrebsmæssige modeller, som beskriver en række grundprincipper inden for brugergrænsefladedesign. I grove træk forklarer begrebsmæssige modeller hvordan en brugergrænseflade præsenteres for brugeren af et system og på hvilke måder de prioriterer brugervenlighed. De fire overordnede begrebsmæssige modeller beskrives her og vurderes efter kravene til vores system. Denne vurdering skal afklare hvilken type interaktionsform vi i sidste ende benytter i vores system. Følgende begreber er fundet i [Preece et al., 2002]: 27

33 BEGREBSMÆSSIG MODEL Instruktion Denne model er fokuseret på kommandolinje-betjening, med meget begrænset feedback. Selvom man er i stand til at producere fleksible og effektive grænseflader vha. kommandolinjevinduer, er det langt fra sikkert, at en grænseflade kan designes, som målgruppen kan benytte. Derudover kræver et kommandolinje-betjent system ofte mere optræning før det kan benyttes effektivt af en bruger, idet man typisk skal huske de forskellige kommandoer udenad, hvilket i sidste ende fører til at der kan gå lang tid før en bruger kan benytte det effektivt. Brugerne som skal benytte bibliotekssystemet i dette projekt er alle medlemmer af MI-gruppen på Aalborg Datalogisk Institut. Det er blevet vurderet at hvert medlem i MI-gruppen er i stand til at benytte sig af grænseflader sammenlignelige med de som benyttes i Windows, men de er muligvis ikke alle i stand til at gøre brug af mere minimalistiske grænseflader (f.eks. en Shell ). Idet bibliotekssystemet helst skal kunne bruges effektivt direkte efter implementering vurderes det, at en kommandolinje-betjent grænseflade ikke vil være et optimalt valg. Konversation Ent anden begrebsmæssig model er den konversationsbaserede model. En af fordelene ved denne model er den lette tilgængelighed for nybegyndere. Igennem en virtuel konversationspartner (eller et velstruktureret system til understøttelse af skreven naturligt sprog) kan den nye låner få adgang til mange af systemets tilgængelige funktioner, og med rimelig lethed lære at benytte disse. [Preece et al., 2002] fremstiller dog flere eksempler på konversationsbaserede grænseflader, som viser denne models skyggesider. Grænseflader baseret på denne model har tendenser til fejl grundet manglende gennemarbejdethed og systemet kan for eksempel fejlfortolke en brugers hensigt grundet grammatik- eller stavefejl. I et bibliotekssystem vil en grænseflade baseret udelukkende på denne model være ret usikker, idet systemdesignet skal tage højde for samtlige fejl en bruger kan begå i indtastningsfasen under dialogen. Hvis systemet melder fejl tilbage for mange gange, eller det er for komplekst at anvende, risikeres det, at en bruger opgiver at benytte systemet. Derfor vurderes denne interaktionsform ikke som optimal for vores bibliotekssystem. Udforskning og browsing Denne model er baseret på at gøre information let tilgængelig. Lånere bliver præsenteret for en grafisk grænseflade, som let kan navigeres rundt i, så de kan finde den ønskede information med relativt lidt besvær. Denne model er dog ikke beregnet til at manipulere information. Hvis man tager udgangspunkt i et bibliotekssystem ville dette betyde, at låneren ville være i stand til enkelt at finde et ønsket 28

34 INTERAKTIONSFORM stykke litteratur, men han ville ikke være istand til udføre lån, aflevering reservation eller lignende. Derfor kan denne begrebsmæssige model ikke benyttes uden modificering, til brug som forbillede for et bibliotekssystem, hvor der løbende skal kunne registreres information om litteratur og lånere. Manipulation og navigering Den sidste model lægger vægt på en intuitiv tilgang til grænseflader. Det vil sige, at brugerne præsenteres med virtuelle koncepter, som let kan forstås ved den repræsentative relation til objekter i den virkelige verden. En fremtrædende udgave af denne model er direkte manipulation, som præsenteret i [Preece et al., 2002]. Et typisk eksempel på en grænseflade af denne type, er de som anvendes i Windows- eller Linux-baserede styresystemer, der anvender både intuitiv informations-browsing samt vinduer til f.eks. visning og adskillelse af elementer. Det vurderes, at man med fordel kan tage udgangspunkt i denne begrebsmæssige model til et bibliotekssystem, idet den både tillader let adgang til information samt relativt let adgang til manipulation af e- lementer. Overordnet set falder valget på denne begrebsmæssige model, idet den opfylder både kravet om at der kan manipuleres elementer og data, samt navigeres let rundt i programmets forskellige interaktionsrum. 4.6 Interaktionsform Når en begrebsmæssig model er valgt, skal der undersøges, hvilken måde en bruger skal anvende systemet. Af de fire interaktionsformer Menu, Kommando, Dialog og Skemaudfyldelse vurderes, hvilke typisk vil blive benyttet inden for den valgte begrebsmæssige model. Det ses ud fra de mulige handlinger lånere og bibliotekarer har brug for at udføre i det planlagte bibliotekssystem, at navigerings- og opdateringsfunktioner primært benyttes. Disse kan, sammenholdt med den begrebsmæssige model, implementeres i en grænseflade ved en kombination af interaktionsformerne Menu, Dialog og Skemaudfyldelse. Interaktionsformen Menu tiltænkes anvendt i den henseende at agere primært navigeringsværktøj for lånere såvel som bibliotekarer, mens interaktionsformen Dialog vil blive anvendt i situationer, hvor sikkerhed er kritisk; det kan eksempelvis være i situationer, hvor en handling som sletning af bog skal bekræftes. Skemaudfyldelse vil f.eks. blive brugt jævnligt af bibiotekaren i den kontekst, at det anvende når der skal tilføjes en ny låner eller nyt litteratur til systemet, hvor informationer om den nye låner eller litteratur skal indtastes. Disse interaktionsformer indgår dog i mange 29

35 GENEREL INTERAKTIONSMODEL Figur 4.7: Udsnit af systemets interaktionsrum af det planlagte systems aspekter idet både låner og bibliotekar får mulighed for at påvirke systemet på forskellig vis. Det ses at interaktionsformen Kommando udelades på baggrund af det faktum, at indlæringskurven for et strengt kommandobaseret system er relativt høj og derved ikke hensigtsmæssigt at anvende. 4.7 Generel interaktionsmodel På baggrund af aktørtabellen, brugsmønstrene og funktionstabellen identificeres systemets interaktionsrum således, at der skabes overblik over de forskellige handlinger som systemets brugere skal have mulighed for at udføre via. grænsefladen. Det bør noteres, at interaktionsrummet kun i- dentificerer de basale funktioner og vinduer systemet skal indeholde for at fungere. Der bør senere under designprocessen overvejes, hvilke andre interaktionsrum, der er nødvendige for at skabe en sammenhæng mellem brugeren og bibliotekarens interaktionsrum. Interaktionsrummene er udarbejdet og siden samlet, hvoraf et udsnit kan ses på figur 4.7. De komplette interaktionsrum kan ses i appendix A.8. Med udgangspunkt i foregående afsnit, har vi også udarbejdet en mockup af vores systems main-vindue som ses på figur 4.8 på modstående side. Mock-up en er en skitseret prototype over hvorledes brugergrænsefladen kunne se ud, således der er et fælles referencepunkt at tale om, når brugergræsnefladen senere skal designes. Inspirationen til denne mock-up er fundet i [Preece et al., 2002]. Principielt kunne man på dette tidspunkt udarbejde mock-ups til alle interaktionsrummene fundet på dette tidspunkt, 30

36 DEN TEKNISKE PLATFORM men eftersom vi regner med at revidere designet for brugergrænsefladen mange gange i løbet af designfasen, har vi ikke gjort dette. Figur 4.8: Mockup af systemets generelle brugergrænseflade for en bruger 4.8 Den tekniske platform Bibliotekssystemet skal implementeres på en PC med understøttelse af.net 2.0 -framework, således systemet kan kodes med programmeringssproget C#. Ydermere skal platformen have netværksadgang, hvilket giver mulighed for eventuelt at implementere mulighed for at tilgå systemet gennem MI-gruppens intranet. Det vurderes at systemets systemkrav bliver forholdsvis simple, således platformen det køres på ikke absolut skal indeholde det sidste nye hardware. Idéen er at det skal være muligt at benytte en ældre platformsmodel, således implementeringsomkostningerne holdes lavt, mens de primære krav (.NET 2.0 og netværksunderstøttelse) stadig er opfyldt. 31

37 Kapitel 5 Anbefalinger 5.1 Anbefalinger I forbindelse med vores undervisning i systemudvikling og programmeringssprog, herunder kan særligt nævnes kurser i Objekt Orienteret Programmering i C# og udvikling af brugergrænseflader, mener vi at have gode muligheder for at udvikle os selv som studerende, men også være i stand til at levere et IT-system, som lever op til de opstillede krav i systemetdefinitionen i afsnit 2.4 på side Strategi Vi har fastslået at vi har et tilfredsstillende kendskab til både problem og anvendelsesområdet for IT-systemet. Med udgangspunkt i denne viden kan vi begynde at producere et brugbart design til IT-systemet og senere påbegynde implementationen af selve IT-systemet. Da vores kendskab til udvikling med C# sker fortløbende med vores projektarbejde, mener vi at det er en fordel at vi bruger en slags prototyping til design og implementering af selve systemet, og vi arbejder derfor iterativt med henholdsvis implementering og design-fasen af projektet. Dette betyder at vi ikke længere følger den klassiske vandfaldsmodel, men benytter en modificeret version af denne, som tillader os at iterere tilbage i processen. 32

38 Del II Design 33

39 Kapitel 6 Indledning 6.1 Indledning Denne sektion beskriver designdokumentet for vores system. Designdokumentet er primært udarbejdet i henhold til standarden fra OOA&D metoden og vil beskrive systemets designmæssige krav; det være sig emner som systemets anvendte arkitektur, den tekniske platform. Formålet med dokumentet er at beskrive de hovedbeslutninger, der er taget omkring nøglefaktorer for systemets design, samt redegøre for, hvordan systemet tænkes implementeret Formål Det designede system skal lette håndteringen af de administrative gøremål i MI-gruppens bibliotek for både lånerne og bibliotekaren. Systemet skal være nyttigt i administrationen af bibliotekets brugere, simplificere og effektivisere tilføjelse af, udlån af, aflevering af og søgning i bibliotekets litteratur samt tilføje muligheden for at reservere litteratur Rettelser til analysen Vi har efter analysen valgt at indføre følgende funktionalitet i vores design. Det kunne være smart at hente bogoplysninger pr. ISBN-nummer, sådan at man ikke behøver selv at indtaste titel, forfatter osv. Til dette formål kan vi bruge en offentlig ISBN-database. Se mere herom i implementationen. 34

40 TEKNISK PLATFORM Når reserveret litteratur bliver ledig, skal låneren modtage en mail herom ligesom at han skal modtage en mail hvis en afleveringsdato overskrides. Som det kort nævnes i analysen, vil vi undersøge mulighederne for at konstruere en ekstern klient til systemet sådan at man kan foretage opslag og udvalgte andre gøremål fra en lokation forskellig fra selve bibioteket. 6.2 Teknisk platform I dette afsnit præsenteres kravene for hvilket udstyr, systemet skal kunne køre på, samt hvilket software og designsprog, vi har brugt gennem designforløbet Udstyr Bibliotekssystemet skal kunne køre på en almindelig PC med Windows / Linux operativsystem med understøttelse af.net 2.0. Derudover bør det være muligt at opsætte et databasesystem, såsom MySQL-server eller lignende, på PC en eller en netværksserver til datalagring. Yderligere skal der være fuld netværksadgang, således at man kan hente bogoplysninger pr. ISBN-nummer, få adgang til en mailserver, når der skal sendes mails, om at reserveret litteratur er blevet ledig og modtage forespørgsler fra en ekstern klient Basisprogrammel Til udvikling af vores system benyttes programmeringssproget C# og.net 2.0 -framework. Selve udviklingen foregår på Windows XP -styresystemet med udviklingsværktøjet Visual Studio 2005 fra Microsoft Designsprog Designsproget i designdokumentet er baseret på UML-notation som anvendt i [Mathiassen et al., 2001]. 35

41 Kapitel 7 Arkitektur 7.1 Designkriterier og arkitektoniske krav For yderligere at definere hvilke kriterier, bibliotekssystemet skal overholde, har vi udarbejdet en tabel hvori de forskellige designkriterier er opstillet. Disse vægtes i henhold til forventningen til systemets funktionalitet efter hvor vigtige de er at opfylde i det endelige design. Vægtningen af kriterierne defineres som værende meget vigtige (vigtigt+), vigtigt, mindre vigtigt (vigtigt-), irrelevant eller trivielt opfyldt. En nærmere specificering og argumentation for valget inden for hvert kriterium følger i dette afsnit. Ve henviser til tabel 7.1 på modstående side. Brugbart Vi har valgt at prioritere systemets brugbarhed som meget vigtigt. Det vil sige, at systemet skal opfylde kravene defineret i afsnit 4.4, således systemet er effektivt at anvende for de tiltænkte brugere, samt at det kan løse de tiltænkte arbejdsopgaver. Derudover skal det kunne tilpasses tilgængeligt hardware for at holde implementationsomkostningerne nede. Sikkert Som nævnt i aktørspecifikationen for bibliotekar i tabel 4.3 på side 22, er der brug for høj sikkerhed; dels imod fejl og dels imod uønsket datatilgang. Da systemet er tiltænkt at operere på intranettet på Institut for Datalogi, sætter vi prioriteringen af sikkerhed som mindre vigtigt, da kravet om ingen uønsket datatilgang grundet den naturligt høje sikkerhed i omgivelserne, ses som opfyldt. I afsnit 7.2 tager vi stilling til det andet aspekt af sikkerhed, mere præcist fejlmeddelser til brugeren af systemet. Effektivt Dette kriterium dækker over, om systemet udnytter den tekniske platforms ressourcer effektivt. Vi vurderer, at dette kriterie er irrele- 36

42 DESIGNKRITERIER OG ARKITEKTONISKE KRAV Kriterie Vigtigt+ Vigtigt Vigtigt- Irrelevant Triv. opf. Brugbart Sikkert Effektivt Korrekt Pålideligt Vedligeholdbart Testbart Fleksibelt Forståeligt Genbrugbart Flytbar Integrerbart Skalerbart Tabel 7.1: Prioritering af designkriterier vant, da det er tiltænkt, at en arbejdsstation vil være dedikeret til kun at køre bibliotekssystemet og ikke andre applikationer. Deraf følger, at systemet principielt ikke behøver at benytte alle ressourcer effektivt, idet hele den tekniske platforms ressourcer er tilgængelige og at disse er tilstrækkeligt til at køre systemet. Korrekt Vi har vægtet vigtigheden af at implementere systemet korrekt højt i henhold til de i systemdefinitionen opstillede krav. For at programmet skal kunne anvendes af dets tiltænkte brugere, er det vigtigt, at både basale og avancerede funktionaliteter er implementeret således, at de virker efter hensigten og at brugerne kan anvende dem. Pålideligt Vi har vægtet dette kriterie som værende meget vigtigt, idét systemet skal virke efter hensigten i alle brugssituationer uden diverse pludseligt opståede fejl og nedbrud. Baggrunden for denne vægtning er, at brugeren gerne skulle føle tilfredshed (baseret på effektivitet) ved at benytte systemet og det har en virker bare som det skal -effekt. Effektiv fejlhåndtering, med brugbare fejlmeddelelser er derfor vigtige at sætte fokus på. Vedligeholdbart Vi har valgt at sætte kriteriet vedligeholdbart til vigtigt, da vi har vurderet, at de vedligeholdsmæssige omkostninger skal væ- 37

43 DESIGNKRITERIER OG ARKITEKTONISKE KRAV re lave for eventuelle fremtidige udviklere. Systemet skal ikke kræve rutinemæssige opdateringer, idet dette vil kræve meget arbejde fra en udvikler eller bibliotekar, resulterende i øgede driftsomkostninger. Testbart Der er ikke decideret afsat ressourcer til at sikre systemet er testbart, derimod integreres dette som en del af udviklingsprocessen. Dette medfører, vi har vægtet kriteriet testbart til irrelevant, idet der afsættes den mængde ressourcer, der skal til, for at systemets funktioner virker som de skal. Fleksibelt Det vurderes, at der helst ikke skal være noget aspekt i systemet, som senere skal ændres efter implementationen af programmet er gennemført. Vi har derfor vurderet systemkriteriet fleksibelt til at være irrelevant. Forståeligt Kriteriet her dækker over den indsats, der skal til for systemudviklere at opnå en sammenhængende forståelse af systemet, dvs. om det eksempelvis er forholdsvis let at overskue konsekvenser ved indførelse af nye idéer i designet eller ændring af eksisterende elementer. Begreber som abstraktion, ansvarssamling og mønstre er nøglebegreber når man snakker om øgning af forståelighed. I vores design har vi valgt at vægte det mindre vigtigt, da vi ikke regner med at andre programmører skal overtage dette projekt, og vi selv har et behov for at kunne danne vores egne erfaringer omkring konsekvenser ved eksempelvist indførelse af nye idéer. Genbrugbart Prioriteringen af kriteriet genbrugbart har vi vægtet som irrelevant. Det udviklede system er skræddersyet til administration af MIgruppens forskningsbibliotek og genbrugbarheden er derfor ikke vægtet som et vigtigt kriterium at opfylde. Vi bekymrer os på nuværende tidspunkt ikke om, om andre forskningsgrupper vil kunne få gavn af det udviklede system. Det er dog som nævnt vigtigt, at koden bag systemet er forståelig for os og eventuelle teknikerne. Flytbar Systemet skal implementeres i C#, da det er et krav at vi anvender dette programmeringssprog. Eftersom C#-applikationer kan afvikles på både Windows- og Linux-maskiner, vurderer vi kriteriet til at være trivielt opfyldt. 38

44 DESIGNKRITERIER OG ARKITEKTONISKE KRAV Integrerbart På nuværende tidspunkt har MI-gruppen muligheder for at søge i andre forskningsdatabaser igennem f.eks. AUBOLINE, og derfor har vi valgt ikke at benytte sådanne som integrerede dele i vores system. På denne baggrund foretages vægtningen integrerbart til at være mindre vigtigt. Skalerbart Idet MI-gruppen ikke består af mere end 9 mennesker, har vi ikke vægtet skalerbarheden af systemet særligt højt, idet det er på nuværende tidspunkt bliver skræddersyet til deres behov. Derfor er vægtningen af dette punkt irrelevant, da vi ikke har intentioner om at systemet skal kunne anvendes i større organisationer end MI-gruppen efter færdiggørelse Faktortabel Ved at lave en faktortabel over designkriterier, funktionelle og non-funktionelle krav, kan vi søge at sikre os at bevare overblikket og ikke undervurdere forskellige aspekter af systemudviklingen og dens krav. Grundet mængden af faktorer, har vi her valgt at vise de to vigtigste faktorer for projektet i tabel 7.2 og 7.3 på næste side. Resten ses i appendix A.1 og A.2. Faktor MKS Flex. Virk. Pri. R/S Persistens Alt, der bør gemmes, skal gemmes. alle dele af skal være ind- Gælder for Persistenslaget Må ej belaste systemet. vor persistens nemt, at systemet, h- kapslet så er en god idé. Eventuelt bruges en database ved endelig implementation. Tabel 7.2: Faktortabel 39 det er nemt at skifte til database senere. H H, da ingen af os har erfaring med dette i C#.

45 GENERISKE DESIGNBESLUTNINGER Faktor MKS Flex. Virk. Pri. R/S Systemet Det skal være let Gælder for Bør implementeres H H, da vi skal være og fri fra større hele systemet, snarligt for stadig und- let at bruge tekniske vanskeligheder inklusiv afklaring af h- ervises på både for at kunne for bibliote- vorledes syste- dette område, hverdagsbrugere, benytte både den karen met gøres bedst er bruger- lokale klient og muligt brugergrænsefladen såvel som selve bibliotekssystemet. venligt. endnu ikke for dem der Det må fastlagt. sjældent ikke tage flere bruger det minutter at lede efter en given bog for derefter at låne den, uanset teknisk kendskab hos den enkelte. Brugere må helst ikke på noget tidspunkt gå i stå eller befinde sig i en situation, hvor det næste skridt er uklart. Tabel 7.3: Faktortabel Forkortelser fra faktortabellen MKS står for kortelse for fleksibilitet. Her er tale om, hvilke dele af systemet, mål og kvalitetscenariet gælder for. Virk. er en forkortelse for virkning og omhandler faktorens indvirkning på systemet og eventuelle implementeringsrækkefølge. Pri. er en forkortelse for prioritet ; vi har her valgt at bruge H, MH, M, L som værende kriterier for prioritering af den enkelte faktor. H angiver, at faktoren har en høj prioritet, MH at faktoren har en middelhøj prioritet, M at faktoren har en middel prioritet og L at faktoren har en lav prioritet. R/S står for risiko og sværhedsgrad. Her benytter vi den samme notation som for prioritets-kolonnen, dog tilknyttes her en kommentar omkring sværhedsgraden af implementationen af faktoren. 7.2 Generiske designbeslutninger Vi vil i dette afsnit beskrive de generiske designbeslutninger. Begrebet omhandler det fænomen at lægge et skema for design af alle kategorier. F.eks. kunne en kategori være en fejlmeddelelse til brugeren. Man kunne opstille nogle retningslinjer for, hvordan en sådan skulle designes. Dog har vi 40

46 GENERISKE DESIGNBESLUTNINGER valgt ikke at lægge for meget fokus på æstetisk design, da vi har prioriteret funktionalitet højere. Persistens Som det nævnes i faktortabellen tabel A.1 på side 125, ønskes al information om objekter lagret. Det skyldes, at man ikke kan gemme alt i arbejdshukommelsen og forvente at systemet aldrig skal genstartes eller går uventet ned. Vi har indledningsvis valgt at bruge serialisation og deserialisation i C#. Serialisation er en måde, hvorpå objekter samt andre objekter der refereres til fra dette objekt, kan gemmes til en fil. Ved deserialisation kan objektet og referencerne genetableres til den tilstand, de befandt sig i, da de blev serialiseret. Hvis f.eks. en klasse skal serialiseres, kan det gøres på 2 måder. Den kan mærkes med [Serializable]: 1 [ S e r i a l i z a b l e ] 2 public c l a s s S e r i a l i s e r b a r K l a s s e 3 { } Den kan også nedarve fra interfacet ISerializable: 1 using System. Runtime. S e r i a l i z a t i o n ; 2 3 public c l a s s S e r i a l i s e r b a r K l a s s e : I S e r i a l i z a b l e 4 { 5 S e r i a l i z a t i o n I n f o i n f o ; 6 StreamingContext context ; 7 8 public void GetObjectData ( S e r i a l i z a t i o n I n f o info, 9 StreamingContext context ) 10 { 11 t h i s. i n f o = i n f o ; 12 t h i s. context = context ; } 16 } Vi vil implementere serialisation på en sådan måde, at programmet til en hver tid kan lukkes ned uden unødig tab af data. Vi vil berøre dette emne nærmere under implementationen. 41

47 KOMPONENTARKITEKTUR Fejlmeddelelser Uforståelige fejlmeddelelser i en given applikation er et velkendt fænomen. Ofte er det svært at forstå, hvad en fejlmeddelelse betyder. Vi har valgt at alle fejl lavet af en låner eller en bibliotekar skal behandles ens og indeholde en præcis beskrivelse af problemet. Vi vil konkret implementere en exception UserException med parametrene titel og meddelelse. Bekræftelse på større operationer For bibliotekaren skal der til enhver større operation, såsom sletning af litteratur og lånere, gives bekræftelse før operationen foretages. Det skyldes, at der er et stort arbejde forbundet med genoprettelse, hvis f.eks. bibliotekaren er kommet til at tage fejl af eksempelvis mikkelp og mikkel og en forkert låner slettes. Ingen meddelelse om succes En tankegang fra Unix er, at hvis en given kommando uden output til terminalen udføres, gives der kun feedback, h- vis der opstår fejl. Såfremt at kommandoen eksekveres uden fejl, kan brugeren antage, at kommandoen er udført korrekt. Samme tankegang vil vi forsøge at følge i implementeringen af systemet. 7.3 Komponentarkitektur Med udgangspunkt i designkriterierne i afsnit 7.1 har vi benyttet et kombineret klient-servermønster for systemet som ses på figur 7.1 på næste side. Komponenten Biblioteksystem angiver det system som værende det stykke programmel, som er installeret på den fysiske PC i biblioteket. Modelkomponentens primære ansvar er at styre de objekter, der repræsenteres i problemområdet, herunder information om lånere og litteraturen i biblioteket. Funktionskomponenternes primære opgave er at tilføje funktionalitet til modellen. Funktionskomponenterne er derved en samling af de funktioner, der skal til for at sætte systemet i stand til at afvikle de brugsmønstre, som er beskrevet i analysen i afsnit 4.1. Grænsefladekomponenten håndterer interaktionen mellem systemet og aktørerne, herunder både lånere, bibliotekarer og andre systemer. Vores grænsefladekomponent består af tre mindre komponenter. En af dem en systemgrænsefladekomponent til kommunikation med andre systemer som eksempelvis den eksterne klient; denne bliver dog ikke implementeret i selve systemet, men vil blive udspecificeret i implementationsafsnittet. De resterende udgør henholdsvis en BrugerGrænseFladeKlientkomponent, som repræsenterer brugergrænsefladen, som præsenteres for 42

48 KOMPONENTARKITEKTUR lånere i biblioteket og en BrugerGrænseFladeBibliotekar-komponent (BG- FBibliotekar) som repræsenterer brugergrænsefladen, som præsenteres for bibliotekaren. Funktionskomponenten er delt op i tre mindre komponenter, navnlig Net- Funktioner, LånerController og BibController. NetFunktioner er en komponent, som udgør de funktioner, der benytter sig af netværksadgang. Låner er den mængde funktioner, en låner i biblioteket kan benytte, mens Bibliotekar er den mængde funktioner, en bibliotekar i systemet kan foretage. Denne adskillelse mellem lånere, eksterne klienter og bibliotekaren medfører en vis sikkerhed, da lånere hermed ikke kan slette bøger, eksterne klienter kan ikke oprette lånere osv. Endelig har vi modelleret et komponent Ekstern Klient, som kun består af et enkelt delkomponent i form af en brugergrænsefladekomponent. Denne komponent anvendes hvis eksterne brugere af systemet ønsker at foretage opslag i systemet og eventuelt lave reservationer. Vi har overvejet at denne bør implementeres således at den vises i en internetbrowser, hvilket medfører at vi kun har brugergrænsefladekomponenten at tage hensyn til. Denne kommunikerer med systemet gennem netværkskomponenten. <<Komponent>> Ekstern Klient <<Komponent>> Bibliotekssystem <<Komponent>> <<Grænseflade>> BGFEkstern <<Komponent>> <<Komponent>> <<Komponent>> Systemgrænseflade BGFKlient BGFBibliotekar <<Funktionslag>> <<Komponent>> <<Komponent>> <<Komponent>> <<Komponent>> ISBNDB.COM NetFunktioner LånerController BibliotekarController <<Modellag>> <<Komponent>> Model << Persistenslag>> <<Komponent>> DBS Figur 7.1: Systemets komponentarkitektur 43

49 EKSEMPLARISK DESIGN Som det ses på figur 7.1, bruges der lagdeling til at styre ansvarsfordeling mellem de forskellige komponenter. Som det kan ses, kobles den eksterne brugergrænsefladekomponent til systemgrænsefladekomponenten i det øverste lag i Bibliotekssystemets grænseflade. Endvidere angiver pilenes retning, at der er tale om en lukket-streng arkitektur, hvor alle funktioner altid vil kommunikere nedad i lagdelingen, og hvor det enkelte lag kan kan kommunikere med det lag umiddelbart under og over det selv. Dette betyder, at hvis vi ønskede at ændre en komponent, behøver vi kun at ændre i den ovenliggende komponent og den givne komponent. Et problem ved en lukket-streng arkitektur er, at et lag kun er en begrænset udvidelse af et underliggende lag. Desuden bruges der i figur 7.1 controllere, som vil blive omtalt i afsnit Eksemplarisk design Vi vil i dette afsnit søge at beskrive, hvorledes de generiske design beslutninger i afsnit 7.2 på side 40 vil påvirke vores arkitektur. Dette gøres ved at beskrive implementeringen af nogle af vores vigtigste brugsmønstre. Vi vil starte med at vise, hvorledes Opret Låner (del af brugsmønstret på figur 4.5 på side 23) skal implementeres, og bagefter vil vi vise, hvorledes Lån (på figur 4.2 på side 21) kan implementeres, da disse to blandt de vigtigste brugsmønstre for systemet. Vi bruger GRASP til at fordele afsvaret til de forskellige dele. GRASP står for General Responsibility Assignment Software Patterns og giver nogle retninglinjer for ansvarsfordeling (se evt. [Larman, 1997, kap. 16]). Der findes flere GRASP-mønstre hvoraf vi har valgt at bruge creator-mønstret, hvori ansvaret for et nyt objekt er tildelt den klasse, der har har data til initialisering af de(t) objekt(er) som skal oprettes. Yderligere har vi valgt rollecontrollere, der vil blive uddybet i afsnit 8.2. Opret Låner En ny låner oprettes ved at bibliotekaren åbner sit vindue for låneroprettelse. Herefter indtastes fornavn, efternavn, lokale, mailadresse og telefonnummer i fem tekstfelter. Et tryk på opret låner vil hermed initiere et kald til bibliotekarens controller (diskuteres i afsnit 8.2 på side 48), som vil teste om hvorvidt et lånerobjekt med samme mailadresse eksisterer i forvejen. Såfremt låneren ikke eksisterer, vil et nyt lånerobjekt blive oprettet med disse attributter. Hvis en låner eksisterer med den indtastede mailadresse, skal der returneres en fejlbesked til bibliotekaren, ellers skal 44

50 EKSEMPLARISK DESIGN bibliotekaren gå udfra, at oprettelsen er sket uden fejl. Se evt. afsnit 7.2 på side 42 for yderligere uddybning af denne. På figur 7.2 på næste side ses sekvensdiagrammet for brugsmønstret. Lån Følgende diagram på figur 7.3 på side 47 viser, hvorledes et lån foretages af låneren. Låneren indtaster søgeord og ved efterfølgende søgning, vil der blive foretaget et kald til controlleren. Denne vil teste om hvorvidt der findes litteratur, som passer til søgeordet. Såfremt det gør, returneres en liste med de emner, som svarer til søgeordet. Låneren kan nu markere det eller de materialer, som findes passende, og trykke på lån. Herefter bliver låneren bedt om at indtaste sit unikke brugernavn, som tjekkes for validitet. Lånet oprettes ved at de stykker litteratur, låneren tilføjede til lånelisten, bliver knyttet til det brugernavn, låneren indtastede, og slutteligt opdateres litteraturens status ved at controlleren videregiver ansvaret til den funktion, der haransvaret for det. 45

51 EKSEMPLARISK DESIGN Figur 7.2: Sekvensdiagram for oprettelse af låner 46

52 EKSEMPLARISK DESIGN Figur 7.3: Sekvensdiagram for et simpelt lån 47

53 Kapitel 8 Komponenter 8.1 Modelkomponenten Modelkomponenten detaljeres ved at udarbejde et klassediagram, der beskriver systemets anvendte klasser samt klassernes respektive attributter. Modelkomponenten for vores system ses på figur 8.1 på næste side. Klassediagrammet er baseret på analysens klassediagram som ses på figur 3.1 på side 14, men er udbygget med yderligere klasser identificeret ved at undersøge hændelserne i tilstandsdiagrammerne ligeledes fra analysen (Se side 3.3 på side 14). Disse nye klasser er fundet ved at vurdere hændelserne for hver klasse, om de er private og om de kan ske flere gange. Hændelser, der kan forekomme flere gange for en enkelt klasse, er udspecificeret i deres egne klasser. Således kan en seperat instans af hændelsen betragtes som et objekt af den pågældende klasse. Attributterne til klasserne er dels attributterne identificeret i analysen, samt atributter der kan tilskrives en tilstandsværdi, som repræsenterer de private hændelser, som kun forekommer én gang for et objekt af klassen. Kardinaliteterne på det udbyggede klassediagram beskriver således ikke kun hvor mange objekter af et element, der indgår i en helhed, men også hvor mange gange en given hændelse kan ske. I de følgende underafsnit beskrives attributterne for de enkelte klasser i modelkomponentens designklassediagram. 8.2 Funktionskomponenter Vi vil i dette afsnit beskrive funktionskomponenterne. På baggrund af det faktum, at vi ikke har nogle store beregningsfunktioner, og at vi har mange opdateringsfunktioner, har vi valgt at udspecificere funktionslaget i controllere. En controller er et objekt, der har til ansvar at udføre forskellige 48

54 FUNKTIONSKOMPONENTER Figur 8.1: Designklassediagrammet for modelkomponenten og controllere (funktionslaget) 49

55 FUNKTIONSKOMPONENTER handlinger for andre givne objekter. Controlleren kan ses som en ansvarsfordeler, da den ikke udfører opgaver selv, men sørger for, at opgaverne bliver delt ud til andre funktioner og klasser, der har forstand på opgaven. Herefter returnerer den resultatet fra den efterspurgte handling videre til metoden, som efterspurgte resultatet til at starte med. Der findes forskellige slags controllere; vi bruger rolle-controllere, hvor rollen som låner eller bibliotekar vil have tilhørende handlinger på deres controller. Ved at bruge controllere, opnår vi lav kobling, som beskrevet i [Mathiassen et al., 2001, s. 266], hvilket er en fordel i situationer, hvor udskiftninger i et system kan komme på tale - eksempelvis hvis vi i vores system på et tidspunkt er nødsaget til at gå fra databaser til i stedet at gemme data i flade filer. For at opnå lav kobling skal klasserne designes så disse er mere uafhængige og mere genbruglige. I funktionskomponenten vil vi gerne have høj samhørighed som det er beskrevet i [Mathiassen et al., 2001, s. 267]. Samhørighed står for den indre sammenhæng i en klasse eller en komponent, som her. Hvis man f.eks. forsøger at dele samhørige klasser, kan det lede til en høj grad af kobling, hvilket vi, som skrevet, ville undgå. Når man snakker om høj samhørighed i en komponent, er det relationen mellem de klasser, der udgør komponenten. Der er mange muligheder for at se, om der er høj samhørighed i en komponent. Bl.a. gøres dette ved at undersøge, om komponentens klasser hænger sammen begrebsmæssigt eller at strukturerne mellem klasserne og objekterne hhv. primært er generalisering og aggregering. Dele, der er programeret med høj samhørighed, vil for det meste indeholde færre fejl og derved koste mindre set i et udviklingsperspektiv BibController I sekvensdiagrammet for brugsmønstret Opret låner har vi valgt at bruge en controller ved navn BibController, der har ansvar for de 8 bibliotekarhandlinger Opret låner, Slet låner, Rediger låner, Tilføj litteratur, Slet litteratur, Rediger litteratur Meld bortkommen og Meld funden. På figur 8.1 på forrige side ses controlleren med de indeholdte funktioner. Beskrivelse af funktioner Herunder følger operationsspecifikationer for BibControllers komplekse funktioner. De to mest komplekse funktioner specificeres i tabel 8.1 på næste side og tabel 8.2 på modstående side. 50

56 FUNKTIONSKOMPONENTER Opret låner Funktionsnavn: OpretLaaner(string _fornavn, string _efternavn, string _lokale, string _mail, int _telefonnr) : void Kategori: Opdatering, passiv Formål: Opretter en låner i systemet. Inddata: Lånerens fornavn, efternavn, lokalenummer, adresse og telefon nummer. Betingelser: At der ikke allerede eksisterer en låner med samme brugernavn. Effekt: Et nyt objekt af klassen låner oprettes med de givne inddata. Objektet tilføjes en liste over samtlige lånere i systemet. Algoritme: N/A Datastrukturer: N/A Placering: Bibliotekar Involverede objekter: Bibliotekar, Låner Udløsende hændelser: N/A Tabel 8.1: Operationsspecifikation for OpretLaaner Tilføj litteratur Funktionsnavn: TilfoejLitteratur(...) : void Kategori: Opdatering, passiv Formål: Opretter et stykke litteratur i systemet. Inddata: Afhænger af typen af litteratur. Funktionen overloades i hver litteraturtypes klasse. Betingelser: Der tjekkes, om der findes et objekt med det givne ISBN-nummer eller ISSN-nummer (hvis det er relevant for typen af litteratur). tjekkes andre attributter. Effekt: Et objekt af den givne litteraturtype oprettes, bliver tildelt et unikt litteraturid i systemet og tilføjes en liste over samtlig litteratur i systemet. Algoritme: N/A Datastrukturer: N/A Placering: Bibliotekar Involverede objekter: Bibliotekar, den givne litteraturtypes klasse Udløsende hændelser: N/A Tabel 8.2: Operationsspecifikation for TilfoejLitteratur 51

57 FUNKTIONSKOMPONENTER LånerController Ligeledes har vi valgt at bruge en controller ved navn LånerController, der har ansvar for lånerhandlingerne Lån litteratur, Aflever litteratur, Søg litteratur, Reserver litteratur, Aflæs litteraturstatus og Rediger oplysninger. Controlleren kan ses på figur 8.1 på side 49. Beskrivelse af funktioner Herunder følger operationsspecifikationer for LånerControllers komplekse funktioner. De to mest komplekse funktioner specificeres i tabel 8.3 og tabel 8.4 på næste side. Søg litteratur Funktionsnavn: SoegLitteratur(...) : ArrayList Kategori: Aflæsning, passiv Formål: Funktionen skal kunne søge igennem litteraturen på et søgeord (simpel søgning) eller på et udvalg af attributter (avanceret søgning). Der returneres en liste med hits til låneren. Alle stykker litteratur, som matcher kriterierne vises uanset om de er ledige, bortkomne eller udlånte Inddata: Søgeord eller forskellige kriterier Betingelser: N/A Effekt: Et søgeresultat returneres. Algoritme: N/A Datastrukturer: N/A Placering: Låner Involverede objekter: Låner, de søgte litteraturtypers klasser Udløsende hændelser: N/A Tabel 8.3: Operationsspecifikation for SoegLitteratur 52

58 BRUGERGRÆNSEFLADEKOMPONENTEN Reserver litteratur Funktionsnavn: ReserverLitteratur(...) : void Kategori: Opdatering, passiv Formål: Funktionen skal kunne reservere litteratur for en låner. Inddata: LitteraturID Betingelser: LitteraturID et der gives som inddata, skal findes i systemet. Effekt: Litteraturen reserveres til låneren ved at tilføje låneren til det givne stykke litteraturs reservationsliste. Algoritme: N/A Datastrukturer: N/A Placering: Låner Involverede objekter: Låner, de søgte litteraturtypers klasser Udløsende hændelser: N/A Tabel 8.4: Operationsspecifikation for ReserverLitteratur 8.3 Brugergrænsefladekomponenten Brugergrænsefladekomponenten definerer, hvilke typer vinduer, samt hvilke typer udprintninger et program har til rådighed. Idet vores system mest består af informationshåndtering, vil der være en del forskellige vinduer, der skal defineres til hver interaktionsrum, samt en række udprintsfunktioner til at vise indhold fra modellen i disse vinduer. Derudover bliver der også brug for en række vinduer, hvorigennem en låner eller en bibliotekar kan påvirke modellen. Brugergrænsefladekomponenten vil da sende disse forespørgsler videre gennem funktionskomponenten, således at de forespurgte ændringer kan udføres og vises på skærmen. Selve brugergrænsefladekomponenten indeholder to delkomponenter, der kan beskrives som en vinduekomponent og en udskriftskomponent. Vinduekomponenten indeholder elementer til at indkapsle og vise elementer på brugergrænsefladen, og kan blandt andet være strukturer som boundingboxes, knapper, menuer og andre elementer der bare præsenterer programmet. Udskriftskomponenten indeholder elementer som tilføjer indhold hentet ud fra modellen til vindueskomponentens elementer. Det kan for eksempel være indhold på listeform, billeder eller andet, som oftest indeholdes i vinduekomponenter. Komponenter fra både vinduekomponenten og udskriftskomponenten kombineres således til en samlet brugergrænseflade, der præsenteres for en bruger af systemet enten via. BGF Kli- 53

59 BRUGERGRÆNSEFLADEKOMPONENTEN ent komponenten i vores komponentarkitektur eller via. BGFBibliotekar (se figur 7.1 på side 43). De enkelte elementer i henholdsvis vinduekomponenten og udskriftskomponenten er fundet ved at se på funktionslisten (se tabel 4.4 på side 24) og interaktionsrummene (se afsnit 4.7 på side 30) i analysedokumentet Præsentationsmodel Ud fra brugergænsefladekomponentens delkomponenter udarbejdes en præsentationsmodel. Præsentationsmodellen er en eksplicit model af hvorledes systemet skal navigeres af en bruger og hvorledes systemets forskellige vinduer er opbygget, samt deres relationer til hinanden. Formålet er at give både udvikler og kunde et overblik over, hvordan systemet kommer til at se ud således, at ændringer ændringer i designetkan fanges inden det kodes. Derved skulle det være muligt for en udvikler at programmere brugergrænsefladen i henhold til kundens ønsker, og derved spare arbejde idet brugergrænsefladen allerede passer til kundens forventninger. Præsentationsmodellen udarbejdes på baggrund af interaktionsrummene identificeret i analyseafsnit 4.7, hvori de forskellige interaktionsrum identificeredes ved undersøgelse af aktørtabellen, brugsmønstrene og funktionstabellen. Disse interaktionsrum bliver således eksplicit defineret og sat sammen til en præsentationsmodel. Præsentationsmodellen er opbygget som en variant af et klassediagram, hvori et interaktionsrums input, output og operationer defineres inden i de respektive klasser. Input og output er således et interaktionsrums attributter, mens dets operationer defineres som funktioner der kan udføres deri. Præsentationsmodellen kan ses på figur 8.2 på næste side. 54

60 BRUGERGRÆNSEFLADEKOMPONENTEN Figur 8.2: Præsentationsmodel af brugergrænsefladen 55

61 Del III Implementation 56

62 Kapitel 9 Implementation 9.1 Indledning Med analyse og design arbejdet overstået, kan vi nu tage fat i selve implementationen af systemet. I dette kapitel vil vi se nærmere på nogle centrale dele af vores analyse og design er implementeret og hvorledes implementationen ændrer ved vores eksisterende klassediagram. En ting er at analysere sig frem til en ideel struktur for systemet, men ofte kan ens valg af sprog og øvrig teknologi have en indflydelse på ens design, som analysen ikke kunne afdække på forhånd. Vi har som tidligere nævnt (i afsnit 6.2.2) valgt at implementere systemet i C#. Dette valg medfører igen nogle ændringer for systemet, da brugen af eksempelvis.net-framework ikke direkte afspejles i vores design. Vi har derudover valgt at sproget i systemets brugergrænseflade skal være engelsk, fordi der ikke ligger et krav om at kunne beherske dansk i tale og skrift, og fordi flere personer på instituttet ikke taler dansk. Vi formoder at alle brugere kan engelsk til en vis grad, hviklet burde gøre at systemets fremtidige brugere vil kunne tilgå brugergrænsefladen og benytte systemet på lige fod. 9.2 Ikke-implementerede features Efter designprocssen var overstået blev vi opmærksomme på flere features, som vi ikke vil implementere i grundsystemet. Begrundelsen for at fravælge at implementere disse features, er at vi med høj sandsynlighed enten ikke vil kunne implementere dem korrekt, eller at de ville tage for lang tid at implementere. 57

63 IKKE-ANALYSEREDE FEATURES Ekstern klient Vi har valgt ikke at implementere den eksterne klient som vi tidligere har omtalt i arkitekturen og andre steder. Vi har valgt at kategorisere dette som et emne til videre arbejde, idet det at finde ud af at lave forbindelse mellem systemet og en ekstern klient var sværere at implementere end vi havde forventet. Derfor har vi undladt at spilde alt for meget energi på en feature, som ikke er strengt nødvendig for systemets funktionalitet. Indlæsning af BibTeX For at få indlæst den eksisterende BibTeX-fil fra MI-gruppens gamle system (se afsnit 2.2) planlagde vi at programmere en stand-alone applikation der vil kunne indlæse denne fil, oprette objekter over litteratur i filen og gemme dem i databasen. Vi valgte ikke at programmere denne applikation da vi mente at vi var bedre tjent ved at programmere selve bibliotekssystemet færdigt og få systemet gennemtestet. Desuden mener vi også at, hvis MI-gruppen vælger at benytte vores system, vil det ikke være en stor opgave at skrive en applikation, ikke nødvendigvis i C#, der kan udføre opgaven. 9.3 Ikke-analyserede features Undervejs i implementeringen af et system er det ikke unormalt at blive opmærksom på svagheder eller deciderede mangler i ens analyse af et givent problem eller designet af løsningen. Vi er stødt på følgende emner, hvor vi har været i tvivl omkring hvorvidt vi skulle udarbejde tilsvarende analyse og design for disse, som for de øvrige brugsmønstre, da vi skulle til at implementere disse i systemet. Disse brugsmønstre er; håndtering af reservationer og lånt litteratur i forhold til afleveringsdatoer, udsendelse af s omkring hjemkomne reservationer eller litteratur overskeredet afleveringsdato, generering af BibTeX-entries og endelig generering/visning af statistik. Af pladshensyn vil vi begrænse os til blot at beskrive disse funktioner og henvise til kildekoden på den vedlagte cd-rom for den interesserede læser. Notificationhandleren Notificationhandleren sørger for at sende ud til lånere om tilgængelige reservationer og litteratur, som har overskredet afleveringsfristen. En flygtig tanke, som berørte os hen mod afslutningen af implementationen var, hvorledes overgangen fra en reservation til et lån skulle foregå. Selve problemstillingen om overgangen mellem reservation og aflevering eksisterer ikke i MI-gruppens nuværende bibliotek da 58

64 IKKE-ANALYSEREDE FEATURES reservation ikke er en mulighed; men i og med, at ønsket om reservation er defineret under BATOFF kriterierne i afsnit 2.4, var det et emne som vi mente var relevant at undersøge. Med udgangspunkt i dette, har vi skrevet en funktion, som på et klokkeslæt angivet af bibliotekaren, traverserer mængden af litteratur og undersøger om det enkelte litteratur er udlånt. Såfremt at afleveringsdatoen er mindre end den aktuelle dato, vil det pågældende litteratur blive tilføjet til en liste. En tilsvarende funktion køres kort efter, hvor den mængde litteratur, hvor litteraturens attribut reserveretaf ikke er tom og attributten låntaf er tom tilføjes en anden liste. Listerne genereret af de to funktioner sendes derefter videre i funktionen, hvor der sørges for at s bliver udsendt til de korrekte modtagere. Disse s indeholder da en autogeneret besked om, at det lånte litteratur skal afleveres eller, at litteratur er ledigt til lån. Netcontroller Netcontroller er en klasse i programmet, som indeholder netværksrelateret funktionalitet. Denne er kun kort beskrevet i komponentarkitetkturen i afsnit 7.1. Derudover er den ikke analyseret selvstændigt. Klassen indeholder specifikt funktionaliteten til at foretage opslag på en ekstern ISBN-database og sende mails til systemets brugere. Dette burde have været dokumenteret i både analyse og design afsnittene i produktrapporten. Statistik Under implementationen opstod der en idé om at det kunne være smart med en slags statistik i systemet, som kunne anvendes til forskellige formål både en bibliotekar og en låner kunne have gavn af. Denne ikke dokumenterede feature var baseret på tanken om at det skulle være muligt at se hvilken låner, der for eksempel havde lånt et specifikt stykke litteratur flest gange. Derved kunne andre lånere kontakte vedkommende om råd angående materialet og søge hjælp hos denne idet det forventes, at den hyppigste låner af et stykke litteratur også har et godt kendskab til litteraturens emner. Denne måde at anvende statistik på kræver imidlertid mere information end vi reelt har implementeret i systemet, og eksisterer derfor ikke i sin færdige form i den endelige version af systemet. Færdiggørelse af denne feature er blevet overladt som et emne til videre arbejde, skulle der udvikles videre på systemet. 59

65 DBS-KOMPONENT 9.4 Dokumentation af programmet Vi har valgt at bruge programmet doxygen til at generere dokumentation af vores programs kildekode. Doxygen kan generere HTML-filer og TeXfiler ud fra kommentarer skrevet i koden og præsentere disse på en hensigtmæssig måde, som giver et let overblik over strukturen af koden. Kommentarerne skal være XML-kommentarer før deklarationen af metoden som nævnt på 06/XMLC/, almindelige C-kommentarer som /* <kommentar> */ eller C++kommentarer hvor der bruges /// <kommentar>. Til programmet hører også en kort installationsvejledning, som i grove træk beskriver de trin som skal tages, for at programmet kan fungere på en lokal PC er. Den samlede dokumentation af programmet ligger på den vedlagte CD-rom. 9.5 DBS-komponent Som nævnt i afsnit 7.2 på side 41, havde vi i sinde at benytte serialisation til at håndtere persistens. Vi er dog i løbet af implementationen af systemet gået over til at benytte en MySQL-database for lettere at få fuld kontrol over skrivningen til persistenslaget. Hvis man f.eks. vil tilføje noget til en eksisterende ArrayList bliver man vha. serialisation nødt til at hente hele listen ind fra disken, tilføje noget til den og gemme den igen. Dette virker anderledes hensigtmæssigt vha. en MySQL-database, idet der direkte kan modificeres i en MySQL database, skulle det blive nødvendigt at rette fejl i systemets data. Vi vil kort gennemgå, hvordan de to forskellige persistensmetoder benyttes. Dels for at forklare, hvordan vi har benyttet MySQL-databaser, men også for at vise, at vi ved hvordan serialisation skal benyttes. Se evt. appendix A.3, der viser et tidligt stadie af vores kildekode, hvor vi benytter serialisation. Afsnittet blev oprindeligt afleveret sammen med designdokumentet, som dokumentation af vores arbejde med programmering til et review Serialisation og deserialisation Eksemplet vi vil gennemgå er et ganske simpelt program, der når det starter op, giver brugeren lov til enten at starte en ny session eller genoptage en gammel. En ny session består af, at brugeren indtaster en besked, som 60

66 DBS-KOMPONENT serialiseres. I en gammel session hentes den sidste besked, Der blev skrevet vha. deserialisation. Programmets Main-metode er beskrevet i efterfølgende kildekode: 1 public s t a t i c void Main ( ) 2 { 3 Console. WriteLine ( " " ) ; 4 Console. WriteLine ( " Tryk 0 f o r gammel og 1 f o r ny : " ) ; 5 i n t input = Convert. ToInt32 ( Console. ReadLine ( ) ) ; 6 i f ( input ==0) 7 (new S e r i a l T e s t ( ) ). Gammel ( ) ; 8 else 9 (new S e r i a l T e s t ( ) ).Ny( ) ; 10 } Message besked ; Læg mærke til objektet af typen Message, der er oprettet efter Main-metoden. Objektet oprettes her så det kan benyttes af både SerialTest.Ny og Serial- Test.Gammel. SerialTest.Ny spørger brugeren efter en besked og serialiserer den vha. GemSession: 1 public void GemSession ( Message besked, s t r i n g filename ) 2 { 3 Console. WriteLine ( " [Gemmer t i l disk ] " ) ; 4 using ( FileStream s = new FileStream ( filename, FileMode. Create ) ) 5 { 6 IFormatter f = new BinaryFormatter ( ) ; 7 f. S e r i a l i z e ( s, besked ) ; 8 } 9 } En FileStream instantieres med et filnavn og FileMode.Create. På denne måde bliver filen oprettet, hvis den ikke eksisterer og overskrevet, hvis den eksisterer. Herefter serialiseres beskeden vha. IFormatter.Serialize, som kan findes i namespacet SYSTEM.RUNTIME.SERIALIZATION. Gammel henter en gammel besked ind vha. HentSession: 1 public Message HentSession ( s t r i n g f i l n a v n ) 61

67 DBS-KOMPONENT 2 { 3 Console. WriteLine ( " [ Henter f r a disk ] " ) ; 4 using ( FileStream s = new FileStream ( filnavn, FileMode. Open) ) 5 { 6 IFormatter f = new BinaryFormatter ( ) ; 7 return f. D e s e r i a l i z e ( s ) as Message ; 8 } 9 } Filen åbnes og der deserialiseres vha. IFormatter.Deserialize. Den gemte streng hentes og vises på skærmen MySQL-databaser Forbindelser til MySQL-databaser foregår uden de store vanskeligheder i C# vha. namespacet SYSTEM.DATA.ODBC. En metode til at gøre MySQL databaser tilgængelige på i Windows er følgede: Lad os antage at vi har en MySQL database installeret, og ønsker at kunne bruge den til at gemme output fra et C# program. Først hentes ODBC-driveren fra MySQL s hjemmeside. I Windows skal man derefter under Control Panel Administrative Tools Data Sources (ODBC) åbne tabben Bruger-DSN. I denne tab vælges tilføj, hvorefter man finder og tilføjer en MySQL OD- BC 3.51 driver fra listen i vinduet, der popper op. Herefter skal man, i vores tilfælde, skrive bibsystemodbc i data source name textboksen, fyr.cs.aau.dk i server tekstboxen, d101a i User tekstboxen, kodeordet til databasen i password-tekstboxen og til sidst sættes den valgte database til MI-bibsystem. Derefter testes forbindelsen. Hvis der er korrekt oprettet forbindelse til databasen, trykkes Ok. Datakilden skulle nu gerne være vist som værende oprettet i bruger-datakilde-vinduet. Skrivning Først oprettes en OdbcConnection: 1 OdbcConnection minodbc = new OdbcConnection ( "DSN= bibsystemodbc " ) ; mysql-connector-odbc win32.msi/from/ dotsrc.org/mysql/ På en dansk windows installation er stien Kontrolpanel Administration Data kilder(odbc) 62

68 DBS-KOMPONENT Parameteren bibsystemodbc henviser til det data source name man tilføje databasen til Data Sources med. Herefter kan man i sin kildekode f.eks. skrive programkode til tilføjelse af en bog til databasen: 1 s t r i n g bogstring = "INSERT INTO Boeger VALUES( " + a. Isbn + ", " + a. T i t e l +... ) ; " ; 2 t r y 3 { 4 minodbc. Open ( ) ; 5 OdbcCommand kommando = new OdbcCommand( ) ; 6 kommando. Connection = minodbc ; 7 kommando. CommandText = ( bogstring ) ; 8 kommando. ExecuteNonQuery ( ) ; 9 } 10 catch ( OdbcException e ) 11 { 12 throw new BibException ( " Database e r r o r ", e. Message ) ; 13 } 14 f i n a l l y 15 { 16 minodbc. Close ( ) ; 17 } I et try-statement åbnes forbindelsen til databasen og kommandoen til skrivning til databasen eksekveres. En eventuel OdbcException fanges og bliver genkastet som en BibException. I et finally-statement lukkes forbindelsen til databasen (finally-statements udføres uanset om en exception er blevet kastet eller ej). Indlæsning Herunder ses et modificeret eksempel på indlæsningsprocessen for bøger. Værdier fra databasen indlæses og skrives til et objekt af den korrekte litteratur subklasse, som efterfølgende tilføjes en ArrayList: 1 public ArrayList HentBoeger ( ) 2 { 3 OdbcConnection hentbogodbc = new OdbcConnection ( "DSN =bibsystemodbc " ) ; 4 ArrayList r e t u r L i s t e = new ArrayList ( ) ; 5 s t r i n g bog = " s e l e c t from Boeger ; " ; 6 s t r i n g isbn ; s t r i n g t i t e l ; s t r i n g f o r f a t t e r ;... ; 7 i n t a a r s t a l ;... ; 63

69 DBS-KOMPONENT 8 9 OdbcCommand HentKommando = new OdbcCommand( ) ; 10 OdbcDataReader l a e s e r ; 11 t r y 12 { 13 hentbogodbc. Open ( ) ; 14 HentKommando. Connection = hentbogodbc ; 15 HentKommando. CommandText = ( bog ) ; 16 l a e s e r = HentKommando. ExecuteReader ( ) ; 17 while ( l a e s e r. Read ( ) ) 18 { 19 isbn = l a e s e r. GetString ( 0 ) ; 20 t i t e l = l a e s e r. GetString ( 1 ) ; 21 f o r f a t t e r = l a e s e r. GetString ( 2 ) ; 22 a a r s t a l = I n t 3 2. Parse ( l a e s e r. GetString ( 3 ) ) ; } } catch ( OdbcException e2 ) 27 { 28 throw new BibException ( " Database e r r o r ", e2. Message ) ; 29 } 30 f i n a l l y 31 { 32 l a e s e r. Close ( ) ; 33 hentbogodbc. Close ( ) ; 34 } return r e t u r L i s t e ; 37 } Ligesom i det foregående eksempel åbnes en OdbConnection. I strengen bog gemmes en MySQL kommando, der vælger alt fra den tabel i databasen, der hedder Boeger. Herefter eksekveres kommandoen vha. et OdbcCommand-objekt og en OD- BCDataReader kaldet laeser initialiseres. While-løkken forsætter så længe, at der er flere bøger at indlæse. Visse dele af kildekoden er udeladt i rapporten (markeret med...), idet der blot instantieres bogobjekter med de indlæste parametre deri, hvorefter de tilføjes til ArrayListen returliste, som defineredes i starten af metoden. Til slut 64

70 FUNKTIONSKOMPONENT returneres denne liste. Al litteratur af typen Bog er nu indlæst i en ArrayList som kan anvendes i programmet. På samme måde som i eksemplerne, anvendes forskellige kommandoer sent til MySQL databasen alt efter hvilken data man ønsker at hente ud. Det vurderes at denne måde at gemme og hente objekter på er mere fleksibel end at anvende persistens vha. serialisation. 9.6 Modelkomponent Én ting er, at vi nu har demonstreret, hvorledes vi håndterer persistens på vores data. En anden ting er, hvorledes vi håndterer vores data mens de lever i systemet. Litteratur består af en abstrakt klasse Litteratur, som implementerer alle fælles attributter, som tidligere vist i 4.1. Konkrete objekter såsom en bog eller en artikel nedarver således fra denne klasse og implementere kun selv de attributter, som kan betegnes for værende særegne for disse. Individers omgang med systemet håndteres via to roller, bibliotekar og låner, som begge arver fra interfacet Person. Disse vil blive beskrevet videre i afsnit Undervejs i implementationen har vi afdækket et programmatisk behov for at opbevare konkrete objekter af litteratur, såsom bøger og proceedings i en generisk klasse Set<Litteratur>, som vi bruger flere steder i systemet til at håndtere mængder af litteratur. 9.7 Funktionskomponent Som nævnt benytter vi os af controllere i funktionslaget og disse controllere udgør funktionskomponenten i vores program. Controllere har, som nævnt i afsnit 8.2, en række praktiske udnyttelser og konsekvenser. I denne sektion vil vi beskæftige os med den konkrete implementation af disse; der vil blive gennemgået kodeeksempler samt detaljerede beskrivelser, som vil illustrere og beskrive den praktiske implementation Controllere Vores system indeholder to centrale controllere: BibController og LaanerController. Hver især har de til opgave at modtage kald fra brugergrænsefladen eller fra andre komponenter i funktionslaget og sende forespørgslerne 65

71 FUNKTIONSKOMPONENT videre i i den lagdelte arkitektur til den komponent, der har ansvar for at udføre de handlinger, der er blevet efterspurgt. Vi vil nu give konkrete eksempler i form af kildekode og tilhørende forklaringer på, hvordan controllerne er implementerede. Eksemplerne vil tage udgangspunkt i henholdsvis opgaven for en bibliotekar, at oprette en bog, og opgaven for en låner, at låne en bog. Oprettelse af en bog Efter bibliotekarens indtastning af bogens detaljer og efterfølgende tryk på knappen Create i Create literature -vinduet, er det BibControlleren, der kaldes. Den konkrete handling, der skal foregå, er, at et bogobjekt skal oprettes i modellaget og straks efter lagres i persistenslaget; slutteligt skal objektet returneres til brugergrænsefladen med henblik på at præsentere litteraturid et for bibliotekaren således at vedkommende kan mærke den fysiske bog med dens litteraturid. Ved tryk på knappen udføres nedenstående kildekode. Programkoden er taget fra OPRETLITTV.CS. 1 i f ( radiobog. Checked ) 2 { 3 Bog nybog = null ; 4 t r y 5 { 6 B i b C o n t r o l l e r bib = new B i b C o n t r o l l e r ( ) ; 7 ISBN i i i = new ISBN ( textisbn. Text ) ; 8 nybog = bib. OpretBog ( i i i. RemoveHyphens ( textisbn. Text ), t e x t T i t e l. Text, t e x t F o r f a t t e r. Text, I n t 3 2. Parse ( t e x t S i d e a n t a l. Text ), textudgave. Text, I n t 3 2. Parse ( t e x t A a r s t a l. Text ), t e x t F o r l a g. Text, textkeywords. Text, richresume. Lines ) ; 9 MessageBox. Show ( " The ID o f th e Book i s " + nybog. L i t t e r a t u r I D + ". ", " L i t e r a t u r e I D ", MessageBoxButtons. OK, MessageBoxIcon. Information ) ; 10 } 11 catch ( UserException egg ) 12 { 13 MessageBox. Show ( egg. ToString ( ), egg. t i t e l, MessageBoxButtons.OK, MessageBoxIcon. Error ) ; 66

72 FUNKTIONSKOMPONENT 14 } 15 catch ( FormatException ) 16 { 17 MessageBox. Show ( " Input in the f i e l d s Year and Pages must contain only p o s i t i v e i n t e g e r s. ", " Input e r r o r ", MessageBoxButtons.OK, MessageBoxIcon. Error ) ; 18 } 19 } I ovenstående eksempel oprettes instanser af klassen BibController og ISBN; derved er klassernes metoder tilgængelige. Metoden OpretBog, udbudt af det bib, som på baggrund af parametrene har til formål at returnere et objekt af typen Bog kaldes. Parametrene i metodekaldet bliver læst ind fra tekstfelterne i brugergrænsefladen. En MessageBox vises indeholdende den nyoprettede bogs genererede litteraturid, således at bibliotekaren kan mærke bogen. De øvrige linier afslutter håndteringen af eventuelle exceptions, der måtte blive fanget under oprettelsen af bogen. Metoden OpretBog, som befinder sig i funktionslaget, er vist nedenfor. (taget fra BIBCONTROLLER.CS) 1 public Bog OpretBog ( s t r i n g _isbn, s t r i n g _ t i t e l, s t r i n g _ f o r f a t t e r, i n t _sideantal, s t r i n g _udgave, i n t _ a a r s t a l, s t r i n g _forlag, s t r i n g _keywords, s t r i n g [ ] _resume ) 2 { 3 Bog bog = new Bog ( _isbn, _ t i t e l, _ f o r f a t t e r, _sideantal, _udgave, _ a a r s t a l, _forlag, _keywords, _resume ) ; 4 P e r s i s t e n s pm = new P e r s i s t e n s ( ) ; 5 bog. L i t t e r a t u r I D = pm. GenererBogLitteraturID ( ) ; 6 pm. OpretBog ( bog ) ; 7 return bog ; 8 } En ny instans af klassen Bog oprettes med parametre som OpretBog er kaldt med i det foregående eksempel. For at kunne skrive bogen til databasen oprettes en ny instans af klassen Persistens til operationer i persistenslaget. LitteraturID et tildeles bogobjektet, hvor metoden GenererBogLitteraturID kaldes. Dernæst kaldes metoden OpretBog, som har til opgave at oprette 67

73 FUNKTIONSKOMPONENT bogen i persistenslaget. Slutteligt skal bogobjektet returneres til kalderen. Forløbet er nu kommet dertil, hvor bogobjektet er oprettet i modellaget og hvor controlleren videregiver ansvaret for at lagre objektet i persistenslaget. Som vist i kildekodeeksemplet ovenfor bliver ansvarsfordelingen konkret udført ved at instantiere et nyt Persistens-objekt og kalde metoderne GenererBogLitteraturID og OpretBog udbudt af dette objekt. Metoden OpretBog, som befinder sig i persistenslaget, er vist i afsnit på side 62 (taget fra PERSISTENS.CS). Lån af bog Vi vil nu gennemgå processen for lånet af en bog. Forløbet er udformet således, at et bogobjekt skal hentes ud i modellaget fra persistenslaget, tilføres nye oplysninger delvis baseret på lånerens input i tekstfelter og slutteligt genlagres i persistenslaget. Det følgende kodeeksempel er knyttet til knappen Make loan i vinduet Loan, der vises når en låner forsøger at låne et stykke litteratur uden at være logget ind. Som en uddybende bemærkning skal det nævnes, at _internliste, som at finde i eksemplet, er af typen ArrayList og bliver sendt med som parameter fra den kaldende metode; listen indeholder de stykker litteratur, som en låner har markeret til udlån efter en søgning. Koden er taget fra FORETAGRESERVATION.CS: 1 private void AccepterKnap_Click ( object sender, EventArgs e ) 2 { 3 Sikkerhed sk = new Sikkerhed ( ) ; 4 5 t r y 6 { 7 i f ( sk. EksistererLaanerPrBrugernavn ( mailadressetext. Text ) == f a l s e ) 8 { 9 MessageBox. Show ( " Username ", " The current username does not e x i s t in the system ", MessageBoxButtons.OK, MessageBoxIcon. Error ) ; 10 } 11 else i f ( mailadressetext. Text == " " ) 12 { 68

74 FUNKTIONSKOMPONENT 13 MessageBox. Show ( " Username ", " Please enter a username. ", MessageBoxButtons.OK, MessageBoxIcon. Error ) ; 14 } 15 else 16 { 17 i f ( l a a n l i s t e. Count > 0 ) 18 { 19 LaanerController laan = new LaanerController ( ) ; 20 laan. R e s e r v e r L i t t e r a t u r ( r e s L i s t e, mailadressetext. Text ) ; 21 laan. L a a n L i t t e r a t u r ( l a a n l i s t e, mailadressetext. Text ) ; 22 MessageBox. Show ( " to t i n g " ) ; 23 main. ReLoad ( ) ; 24 main. ReLoad ( ) ; 25 main. reservationsview. Rows. Clear ( ) ; 26 Close ( ) ; 27 } 28 else 29 { 30 LaanerController laan = new LaanerController ( ) ; 31 laan. R e s e r v e r L i t t e r a t u r ( r e s L i s t e, mailadressetext. Text ) ; 32 MessageBox. Show ( " en t i n g " ) ; 33 main. ReLoad ( ) ; 34 main. ReLoad ( ) ; 35 main. reservationsview. Rows. Clear ( ) ; 36 Close ( ) ; 37 } Første testes der i en if -statement om den angivne mailadresse eksisterer i systemet og viser en MessageBox med negativ tilbagemelding, hvis testen er negativ; ellers udføres handlingerne i else-blokken. I denne blok findes endnu en if -statement, der tjekker, om længden af laanliste er større end 0, i hvilket tilfælde der oprettes en instans af LaanerController, som anvendes til at udføre reservations- og lånemetoderne henholdsvis ReserverLitteratur og LaanLitteratur. Begge metoder tager to parametre, navnlig en liste 69

75 FUNKTIONSKOMPONENT med litteratur og indholdet af feltet mailadressetext. Umiddelbart efter metodekaldene vises en MessageBox, der angiver, at man er i færd med både at låne og reservere litteratur. Efterfølgende refreshes søgefeltet i hovedvinduet via metoden ReLoad, rækkerne i reservations- og lånelisten i hovedvinduet indeholdende litteraturobjekterne fjernes og slutteligt lukkes formen. Indtil videre i forløbet er LaanerControlleren kaldt via en knap i brugergrænsefladen med en forespørgsel om at foretage lån af det litteratur, som er på listen, og det brugernavn, litteraturen skal tilskrives. Nu er det LaanerControllerens opgave at videregive ansvaret om, at lånet skal registreres; det gøres i næste kodeeksempel herunder. Følgende er taget fra LAANERCONTROLLER.CS 1 public void L a a n L i t t e r a t u r ( ArrayList l i t t e r a t u r l i s t e, s t r i n g brugernavn ) 2 { 3 P e r s i s t e n s pm = new P e r s i s t e n s ( ) ; 4 pm. RegistrerLaan ( l i t t e r a t u r l i s t e, brugernavn ) ; 5 } Handlingen i denne metode består i at oprette et Persistens-objekt og efterfølgende kalde RegistrerLaan med to parametre med henblik på at lagre oplysningerne om det igangværende lån. Set på et højere abstraktionsniveau, består handlingen i at videregive ansvaret. Metoden RegistrerLaan vises nedenfor (taget fra PERSISTENS.CS). 1 public void RegistrerLaan ( ArrayList l, s t r i n g brugernavn ) 2 { 3 DateTime gg = DateTime.Now; 4 L i t t e r a t u r l i t t = null ; 5 Persons. Laaner l a a n e r = HentLaanerPrBrugernavn ( brugernavn ) ; 6 7 for ( i n t i = 0 ; i < l. Count ; i ++) 8 { 9 switch ( ( ( s t r i n g ) l [ i ] ). Substring ( 0, 3) ) 10 { 11 case " bog " : 70

76 FUNKTIONSKOMPONENT 12 l i t t = ( Bog ) H e n t E n k e l t L i t t e r a t u r ( ( s t r i n g ) l [ i ] ) ; laaner. AntalLaan = laaner. AntalLaan + 1 ; 15 l i t t. Laantaf = laaner. Mail ; 16 l i t t. Afleveringsdato = gg. AddDays ( 3 0 ) ; 17 l i t t. AntalLaan = l i t t. AntalLaan + 1 ; 18 OpdaterLaaner ( laaner ) ; 19 OpdaterBog ( ( Bog ) l i t t ) ; Først initialiseres nødvendige data; gg-objektet repræsenterer tiden i det øjeblik objektet oprettes og anvendes til at kontrollere låneperioden for stykke litteratur. Metoden HentLaanerPrBrugernavn med parameteren brugernavn kaldes og returværdien tildeles et laaner-objekt. Metoden findes andetsteds i persistenslaget og har til opgave at hente en låners informationer ud af databasen ud fra et brugernavn. En for-løkke påbegyndes, der løber til tælleren i er skarpt mindre end ls længde. Denne løkke anvendes i sammenhæng med en switch, der på baggrund af udtrykket i parantesen vælger den rigtige case at udføre. Udtrykket i parantesen caster det i de element i listen l til en streng som kommandoen Substring opererer på ved udtrække den understreng, der udgør 3 elementer i den originale streng, startende fra 0. Den understreng, der udtrækkes, udgør de efterfølgende cases. Casen, som eksekveres i forbindelse med oprettelse af en bog, er bog. I denne case sker der umiddelbart det, at litt tildeles et objekt Bog, der returneres af metoden HentEnkeltLitteratur. Argumentetet til medtodekaldet består i at caste det i de element i listen l til en streng, der resulterer i en streng, som beskriver typen af litteratur - eksempelvis Artikel. Ydermere bliver både lånerens totale antal lån på biblioteket og litteraturens totale antal lån øget med én med henblik på statistik. Låneperioden sættes til 30 dage, idet der lægges 30 dage til værdien af DateTime-objektet og derefter skrives til litt-objektet som attribut. Slutteligt kaldes metoderne OpdaterLaaner og OpdaterBog, som har til opgave at lagre de udførte ændringer i persistenslaget. Disse metoder befinder sig ligeledes i persistenslaget. Forløbet er nu kommet dertil, at de data, som skulle lagres, er blevet lagret og det er sket via persistenslaget. Det bemærkes her, at LaanerControlleren i overensstemmelse med de generiske designbeslutninger i afsnit 7.2 ikke returnerer noget til brugergrænsefladen. Dermed er forløbet for at låne en 71

77 FUNKTIONSKOMPONENT bog afsluttet. Opsamling Betragtes forløbenes struktur generelt, bemærkes det, at kaldet i begge tilfælde går fra brugergrænsefladen til controlleren i funktionslaget, hvorefter controlleren videregiver ansvaret for at lagre data til persistenslaget. Konsekvensen af denne arkitektur i systemet er, at det er forholdsvist problemfrit at skifte både brugergrænsefladen og persistenstype. Hvis bibliotekssystemet en dag skal afvikles på en ældre maskine, kunne brugergrænsefladen laves i en konsol vha. ASCII-grafik; i dette tilfælde vil det stort set kun være brugergrænsefladen, som skal skrives om, da funktionslaget og persistenslaget fungerer uafhængigt af brugergrænsefladen. Hvis derimod systemet skal benytte en anden type af persistens, eksempelvis flade filer ved serialization og deserialization, er det stort set kun persistenslaget, Persistens, der skal skrives om Oprettelse af en låner Dette afsnit vil omhandle den faktiske implementation af den opgave for bibliotekaren at oprette en låner i systemet. Afsnittet skal ses som et supplement til Opret låner i afsnit 7.4 på side 44, hvor opgaven at oprette en låner er beskrevet. For at forstå, hvorledes en låner oprettes i systemet vil det først blive beskrevet, hvorledes en låner er repræsenteret i systemet. Repræsentationen af alle brugere i systemet er defineret i PERSONS.CS. Klassen Person definerer de attributter, som gælder for enhver person i systemet. Disse attributter nedarves i de specialiserede klasser for en låner og en bibliotekar. Klassen Laaner og Bibliotekar s attributter adskiller sig kun ved, at en bibliotekar ikke har AntalLaan og AntalReservationer attributterne. Person klassen indeholder altså alle informationer, der ønskes gemt om en bibliotekar og en låner i systemet. Filen BIBCONTROLLER.CS håndterer ansvarsfordelingen af alle funktioner som en bibliotekar skal kunne udføre på systemet, heriblandt oprettelsen af lånere i systemet. Metoden for oprettelse af en låner beskrives nedenfor: 1 public void OpretLaaner ( s t r i n g _fornavn, s t r i n g _efternavn, s t r i n g _lokale, s t r i n g _mail, i n t _ t e l e f o n n r ) 2 { 3 Sikkerhed sk = new Sikkerhed ( ) ; 72

78 FUNKTIONSKOMPONENT 4 P e r s i s t e n s pm = new P e r s i s t e n s ( ) ; 5 i f ( sk. EksistererLaanerPrMail ( _mail ) == true ) 6 { 7 throw new UserException ( " User ", "A user corresponding to the mail address already e x i s t s. " ) ; 8 } 9 else i f (! ( _mail. IndexOf ) + 10 == _mail. Length )! ( _mail. Contains ( aau. dk" ) ) ( _mail. IndexOf )!= _mail. LastIndexOf ) )! ( _mail. Substring ( _mail. IndexOf ) ) aau. dk " )! _mail. Contains ) ) 10 { 11 throw new UserException ( " Input ", " I n v a l i d CS adress. " ) ; 12 } 13 else i f ( _fornavn. Contains ( " " ) _efternavn. Contains ( " " ) _ l o k a l e. Contains ( " " ) _mail. Contains ( " " ) _ t e l e f o n n r. Contains ( " " ) ) 14 { 15 throw new UserException ( " Input ", " The c h a r a c t e r i s i l l e g a l. " ) ; 16 } 17 else i f ( _fornavn == " " _efternavn == " " _ l o k a l e == " " _mail == " " _ t e l e f o n n r == " " ) 18 { 19 throw new UserException ( " Input ", " Please f i l l in every f i e l d. " ) ; 20 } 21 else 22 { 23 Persons. Laaner laaner = new Persons. Laaner ( _fornavn, _efternavn, _lokale, _mail, _ t e l e f o n n r ) ; 24 pm. OpretLaaner ( laaner ) ; 25 } 26 } 73

79 FUNKTIONSKOMPONENT Det ses at OpretLaaner er defineret således, at metoden skal kaldes med 5 parametre, som variablerne _fornavn, _efternavn, _lokale, _mail og _telefon efterfølgende refererer til. Klassen Sikkerhed og Persistens instantieres. Disse indeholder metoder til at kontrollere input for korrekthed samt metoder til at gemme data i systemets database. Efter instantiering kaldes der en metode EksistererLaanerPrMail som kontrollerer om en låner med den indtastede -adresse allerede findes i systemet. I givet fald kastes der en exception med en besked til bibliotekaren om, at en låner allerede findes med den angivne -adresse og derfor ikke kan oprettes igen i systemet. Da systemets brugernavne direkte tages ud fra brugernes - -adresse er det også vigtigt, at der ingen fejl er i -adressen, når en bruger oprettes. Dette kontrollerer if -sætningen vha. 5 betingelser, som skal være opfyldt, før brugeren kan oprettes. Når OpretLaaner kaldes, skal brugerens adresse sendes med som parameter, som strengen _mail efterfølgende referer til. 1. Der tjekkes om antallet af karakterer adderes med længden (10) er lig længden af længden af -adressen. Hvis ikke er endelsen strengen fra og noget andet 2. Hvis ikke -adressen er den ugyldig. 3. Hvis indexet af den første forekomst talt fra højre ende af strengen er forskellig fra den første forekomst talt fra venstre ende af strengen findes mindst i strengen. Vi skal her huske at h- vis ikke findes i strengen vil LastIndexOf og IndexOf begge returnere -1. skal forekomme som den sidste del af strengen. 5. For at håndtere tilfældet med at LastIndexOf og IndexOf begge returnerer -1, tjekkes der om stregen I tilfælde af at den indtastede -adressen fejler i et eller flere af punkter kastes en exception med meddelsen om at -adressen er ugyldig. Hvis alt går godt oprettes et nyt lånerobjekt laaner, hvor parametrene fra kaldet af OpretLaaner overføres som parametre til oprettelsen af det nye objekt laaner. Herefter kaldes metoden OpretLaaner med laaner objektet som parameter. OpretLaaner er en metode i persistens klassen, som har ansvaret 74

80 FUNKTIONSKOMPONENT for at oprette en låner, ud fra det laaner objektet metoden blev kaldt med som parameter, i databasen. Låneren eksisterer nu i databasen, hvor låner objektets attributter er blevet tilføjet i de passende tabeller i databasen, og proceduren for oprettelse af en låner er nu afsluttet Aflevering Der findes to afleveringsfunktioner implementeret i systemet. Den første afleveringsfunktion stiller brugeren en dialog til rådighed, hvor dennes lån, reservationer m.m. bliver vist. Her har brugeren mulighed for at krydse de materialer af, som ønskes afleveret. Den anden afleveringsfunktion, Quick Return, ligger placeret i hovedvinduet. Quick Return har til formål at tillade brugeren hurtigt at aflevere et enkelt materiale ved at indtaste litteraturid et for det pågældende materiale. Forskellen mellem de to afleveringsfunktioner ligger i, at det er påkrævet at låneren logger sig ind, for den almindelige afleveringsfunktion, hvorimod dette ikke er nødvendigt hos Quick Return funktionen. Vi har valgt at implementere Quick Return, da denne gør afleveringsprocessen væsentlig mindre tidsskrævende forudsat, at det kun er et eller få stykker litteratur, der ønskes afleveret. Vi vil kun beskrive hvorledes Quick Return funktionen er implementeret i- det den almindelige afleveringsfunktion er implementeret på lignende vis. Først vil det være relevant at beskrive, hvad der sker når brugeren trykker på return knappen i hoved vinduet efter at have indtastet et litteraturid. 1 private void buttonaflever_click_1 ( object sender, EventArgs e ) 2 { 3 LaanerController laan = new LaanerController ( ) ; 4 t r y 5 { 6 laan. QuickAflever ( t e x t L i t t e r a t u r I D A f l e v e r i n g. Text ) ; 7 t e x t L i t t e r a t u r I D A f l e v e r i n g. Text = " " ; 8 S e t S t a t u s B a r ( " Quick return completed " ) ; 9 } 10 catch ( UserException l e ) 11 { 12 MessageBox. Show ( l e. meddelelse, l e. t i t e l, MessageBoxButtons.OK, MessageBoxIcon. E r r o r ) ; 75

81 FUNKTIONSKOMPONENT 13 } 14 } Som det ses aktiveres en event når brugeren klikker på knappen Return. Klassen LaanerController instantieres. Denne har som tidligere nævnt i controller afsnittet, til opgave at modtage kald fra brugergrænsefladen og sende disse videre til den del i systemet, som udfører de låner relaterede handlinger. Metoden QuickAflever er en af låner controllerens metoder, og delegerer ansvaret videre til de metoder i persistensaget som er relaterede til Quick Return. Denne kaldes med det af lånerens indtastede litteraturid som parameter. Nedenfor ses koden for QuickAflever som findes i LAA- NERCONTROLLER.CS 1 public void QuickAflever ( s t r i n g l i t t i d ) 2 { 3 i f ( l i t t i d == " " ) 4 { 5 throw new UserException ( " Quick return ", " Please enter a l i t e r a t u r e I D. " ) ; 6 } 7 else i f ( HjaelpeFunktioner. G y l d i g t L i t t e r a t u r I D ( l i t t i d ) == f a l s e ) 8 { 9 throw new UserException ( " Quick return ", " Please enter a valid l i t e r a t u r e I D. " ) ; 10 } 11 else 12 { 13 P e r s i s t e n s pm = new P e r s i s t e n s ( ) ; 14 L i t t e r a t u r l i t t = pm. H e n t E n k e l t L i t t e r a t u r ( l i t t i d ) ; 15 i f ( l i t t. Laantaf == " n u l l " ) 16 { 17 throw new UserException ( " Quick return ", " The l i t e r a t u r e i s not loaned out. " ) ; 18 } 19 else 20 { 21 Persons. Laaner laaner = pm. HentLaanerPrMail ( l i t t. Laantaf ) ; 22 ArrayList l i s t e = new ArrayList ( ) ; 23 l i s t e. Add( l i t t. L i t t e r a t u r I D ) ; 76

82 BRUGERGRÆNSEFLADE 24 pm. R e g i s t r e r A f l e v e r i n g ( l i s t e, laaner. Brugernavn ) ; 25 } 26 } 27 } Det første der lægges mærke til er, at QuickAflever tager en string, littid, som input. Denne string indeholder det indtastede litteraturid som låneren tastede ind, og som metoden blev kaldt med, da låneren trykkede på knappen. If-sætningen på kontrollerer om strengen littid er tom. Der kontrolleres altså om brugeren overhovedet har indtastet et litteraturid. Er strengen tom, kastes der en exception med en besked til brugeren om, at denne skal indtaste et litteraturid. Er strengen ikke tom kontrollerer elseif-sætningen om litteraturid et er gyldigt. Hvis dette ikke er gyldigt kastes der en exception med besked til brugeren om, at denne skal indtaste et gyldigt litteraturid. Hvis litteraturid et er gyldigt instantieres persistens klassen, og metoden HentEnkeltLitteratur kaldes med det indtastede litteraturid som parameter. Denne undersøger om litteraturen svarende til litteraturid er udlånt. Hvis denne ikke er udlånt, kan litteraturen heller ikke afleveres, og der kastes en exception med besked til brugeren om, at materialet ikke er lånt ud. Hvis litteraturid et er gyldigt, og litteraturen er lånt ud, finder HentLaanerPrMail den låner, hvis -adresse er lig attributten litt.laantaf. Objektet Laaner refererer herefter til det objekt af typen låner som HentLaanerPrMail returnerer. Der oprettest nu en ny arrayliste, hvor litteraturid et, som netop blev hentet, bliver gemt. Til slut kaldes metoden RegistrerAflevering med den føroprettede arrayliste og låneren brugernavn som parameter. 9.8 Brugergrænseflade Vi har benyttet Visual Studio 2005 s indbyggede brugergrænsefladesigner til at fremstille brugergrænsefladen med. Her kan man nemt vha. træk-ogslip metoden, manipulere komponenter, da det i længden bliver trivielt at definere komponenters position og størrelse i kildekoden Forsiden Når programmet startes vises en fælles brugergrænseflade for bibliotekar og låner som på figur

83 BRUGERGRÆNSEFLADE Figur 9.1: Forsiden af programmet Vi vil kort gå igennem de centrale features: Søgning Ved indtastning i søgefeltet (nr. 1 på figuren) vil resultater tone frem løbende i søgeresultat-viewet (nr. 2 på figuren). Alt efter farven på de givne resultater kan låneren aflæse litteraturens status; grøn er ledig, gul er udlånt og rød er bortkommen. Ved at klikke i CheckBoxen i Loan? - kolonnen for et givet stykke litteratur overføres det til indkøbskurven i nederste højre hjørne (nr. 3 på figuren), hvor man kan udføre det endelig lån. Tilsvarende kan gøres for at reservere. Hvis man mangler flere informationer om et resultat kan man højreklikke på det i søgeresultat-viewet og få vist samtlige attributter for det pågældende stykke litteratur i et nyt vindue. Her kan man også få vist litteraturens BibTeX-entry og få den sendt til sin -adresse. Quick loan Hvis man ved, hvilket stykke man vil låne og har det pågældende litteraturs litteraturid, kan man i GroupBoxen (nr. 4 på figuren) med teksten Make quick loan hurtigt udføre et lån. Personlige menuer Under hhv. Librarian og User i menuen i toppen af vinduet (nr. 3 på figuren) kan bibliotekaren og låneren tilgå sin personlige menu. Her kan man for lånerens vedkommende se lån, reservationer og personlig information mm. og for bibliotekarens vedkommende kan man tilføje litteratur, oprette brugere osv. 78

84 BRUGERGRÆNSEFLADE For at tilgå disse menuers indhold, skal man være logget ind i systemet eller være parat til at logge sig ind i systemet. Den statiske klasse Login- Handler varetager netop dette udokumenterede designkrav. 1 public s t a t i c c l a s s LoginHandler 2 { 3 s t a t i c i n t systemtilstand = 0 ; 4 s t a t i c Persons. Laaner laanerloggedin = null ; 5 s t a t i c Persons. B i b l i o t e k a r bibliotekarloggedin = null ; 6 7 public s t a t i c i n t SystemTilstand { 8 s e t { systemtilstand = value ; } 9 get { return systemtilstand ; } 10 } public s t a t i c Persons. Laaner LaanerLoggedIn { 13 get { return laanerloggedin ; } 14 s e t { laanerloggedin = value ; } 15 } public s t a t i c Persons. B i b l i o t e k a r BibliotekarLoggedIn { 18 get { return bibliotekarloggedin ; } 19 s e t { bibliotekarloggedin = value ; } 20 } 21 } Ved opstart af systemet har SystemTilstand værdien 0. Hvis SystemTilstand er 0 og låneren vil tilgå sin personlige menu, bedes vedkommende om at indtaste sin brugernavn, hvorefter værdien sættes til 1. Tilsvarende vil den for en bibliotekar blive sat til 2. Værdiernes ændring symboliserer reelt tilstandsændringer som afstedkommer at for lånerens vedkommende er det nu muligt at tilgå de menu punkter som forefindes i menuen for låneren og vice versa for bibliotekaren. Under Menu vil det nu være muligt at trykke på Log out, hvilket sætter værdien tilbage til 1 igen. Hermed er menuerne igen låste og man er nødt til at logge ind igen for at kunne tilgå menuernes indhold Usability-teknikker Vi vil her redegøre for de forskellige usability-teknikker vi har brugt i designet af vores brugergrænseflade. 79

85 BRUGERGRÆNSEFLADE Gestalt-love Vi har brugt gestalt-lovene (se slides fra 5. kursusgang i DI- EB på CD-rom) til at designe vores brugergrænseflade. Lovene stammer oprindeligt fra psykologien og omhandler, hvordan former og indbyrdes forhold mellem objekter opfattes af den menneskelige hjerne. Ved synsindtryk vil hjernen prøve at organisere det der ses i helheder efter følgende 5 love: Nærhed: Objekter i umiddelbar nærhed repræsenterer en helhed. Ensartethed: Objekter med samme form, farve eller størrelse opfattes som en helhed. Lukkethed: Mønstre i objekter kan i visse tilfælde genkendes selvom mønstret ikke er fuldstændigt. Objekter der er grupperet i f.eks. en cirkel eller en firkant betragtes også som en helhed. Kontinuitet: Et fortsættende mønster genkendes som en helhed. Symmetri: Symmetri repræsenterer en sammenhængende helhed. Gode eksempler på lovene findes på Gestalt_psychology. I vores design kan man fornemme brugen af loven om lukkethed ved vores brug af GroupBox omkring knapper og felter, der hører sammen i en helhed. Loven om nærhed er brugt ved boksene og knapperne til lån og reservation da disse objekter har en samlet funktion. I vores brugergrænseflade har vi søgt at efterligne typiske Windows applikationers design, ved bla. at bruge knapper med samme form og farve som forefindes i Windows. Vi har også brugt den typiske skrifttype for Windows. Alt dette er gjort så learnability og memorabilty ville være høj for brugerne. Selve forsiden minder også om en Windows-vindue pga. vores valg af brugergrænseflade-designer. WIMP (Windows, Icons, Menues og Pointers) er en interaktionsform og er den mest udbredte af interaktionsformer, hvilket vi også bruger for at brugeren har mulighed for at genkende designet. Interaktionsform Som vi beskrev det i afsnit 4.6 bruger vi de tre forskellige interaktionsformer Dialog, Menu og Skemaudfyldelse til vores system. Eksempler på brugen af disse kan blandt andet ses, når man skal oprette litteratur eller tilføje nye lånere. F.eks. hvis man vil oprette et stykke litteratur (f.eks. en proceeding) skal man udfylde de felter der er mulige, efter man har trykket i RadioButtonen 80

86 EXCEPTION-HÅNDTERING for en proceeding. En proceeding indeholder forskellige artikler, og i programmet er det muligt at oprette disse artikler på samme tid. Dette gøres ved at udfylde TextBoxen nederst på vinduet og trykke på linket, hvorefter man udfylder artikelspecificationen. Dette er et typisk eksempel på skemaudfyldelse. Som nævnt tidligere har vi en menu i toppen af vores forside. Herudover benytter vi som skrevet ovenover RadioButtons i vinduer, hvor der skal vælges mellem flere funktionaliteter. Begge måder er eksempler på menuinteraktionsformen. Et eksempel på dialog-interaktionsformen er når en bibliotekar bliver s- purgt af systemet, om bekræftelse på at udføre en stor handling som f.eks. at slette en låner. 9.9 Exception-håndtering Vi klarer exception-håndtering på to måder. Håndtering af exceptions på brugergrænsefladen og håndtering af exceptions i funktionskomponenten. Lad os først se på funktionskomponenten: Som det vises i afsnit 9.5 håndterer vi exception-håndtering ved at fange exceptions af forskellige typer og kaste dem videre som en UserException. UserException er defineret som følger: 1 c l a s s UserException : Exception 2 { 3 public s t r i n g t i t e l, meddelelse ; 4 public UserException ( s t r i n g _ t i t e l, s t r i n g _meddelelse ) 5 : base ( _ t i t e l + _meddelelse ) 6 { 7 t i t e l = _ t i t e l ; 8 meddelelse = _meddelelse ; 9 } 10 public override s t r i n g ToString ( ) 11 { 12 return meddelelse ; 13 } 14 } Som det ses instantieres en UserException ved hjælp af en titel og en meddelse. Når vi i brugergrænsefladen endeligt fanger en UserException skrives denne til skærmen med MessageBox.Show: 81

87 SØGEALGORITME 1 catch ( UserException bib ) 2 { 3 MessageBox. Show ( bib. ToString ( ), bib. t i t e l, MessageBoxButtons.OK, MessageBoxIcon. E r r o r ) ; 4 } På denne måde bliver en MessageBox udstyret med en OK-knap og et rødt ikon der symboliserer en fejl. Vi håndterer eksplicit en exception i brugergrænsefladen ved f.eks. oprettelse af litteratur, hvor man kan specificere årstal for f.eks. en bog. Ved et tryk på Create forsøges indholdet af årstal-feltet konvereret til et heltal. Dette gøres i et try-statement med efterfølgende indfangning af en FormatException, der f.eks. udløses, hvis feltet indeholder karakterer, der ikke kan konverteres til heltal: 1 catch ( FormatException ) 2 { 3 MessageBox. Show ( " Der er i n d t a s t e t bogstaver i å r s t a l e l l e r s i d e a n t a l. ", " Indtastning i f e l t e r ", MessageBoxButtons.OK, 4 } MessageBoxIcon. Error ) ; Det virker omsonst først at smide en UserException og derefter fange den igen på samme sted. Derfor gør vi det på denne måde når det handler om at validere input Søgealgoritme Flere steder i vores system får vi brug for en algoritme, der kan udføre søgninger i data fra databasen, f.eks. i situationen, hvor man vil udføre en søgning gennem attributter på vores litteratur. Lad os først bemærke, at hvis man søger på ordet bayesian, vil man være interesseret i at få at vide, at der f.eks. er en bog med titlen bayesian inference og ikke bare få en meddelelse om, at der ingen litteratur er som matcher søgeordet præcist. Det vil derfor være hensigtmæssigt at se på søgning på delstrenge. Afsnittet vil også omhandle en søgning, hvor man søger igennem alle 82

88 SØGEALGORITME (udvalgte ) attributter på alle slags litteratur med nogle givne søgeord. Grunden til, at vi har valgt at implementere en søgealgoritme fremfor at bruge de indbyggede funktioner i MySQL-databasen eller en indbygget strengsøgningsalgoritme i C#, som f.eks. Contains i SYSTEM.STRING, er at vi mener, at det vil være interessant at se om vi kan gøre det bedre. Første spørgsmål vi skal have svar på er, hvordan vi skal udføre søgningen? Vi kunne prøve at anvende et binært søgetræ, men der vil være komplikationer forbundet med denne metode. Lad os se om vi kan finde strengen hund vha. et binært søgetræ som vist på figur 9.2. Vi har i eksemplet valgt at konstruere træet ud fra alfabetisk orden på det første bogstav i strengen. Børge Benny Mand Abe hund Bedste Dallas Tyv Figur 9.2: Et binært søgetræ For at finde strengen hund vil man gå til det højre deltræ, men man vil ikke finde strengen, da den ligger som delstreng i det venstre deltræ. Måske ville en anden ordning af træets knuder give det rigtige resultat, men man vil højst sandsynligt skulle prøve flere forskellige ordninger for forskellige søgeord, hvilket gør det svært at systematisere. I alle tilfælde af søgninger bliver vi nødt til at løbe al litteratur igennem samt alle attributter for ikke at overse et resultat, dvs. en lineær traversering, som ikke har nogen særlig god tidskompleksitet. Det vi kan forbedre, er måden hvorpå det, inden for et stykke litteratur, konstateres om søgeordet er indeholdt i et litteraturobjekts attributter. Attributterne titel, forfatter, keywords, editors og resume, hvor det er muligt. På hver type litteratur repræsenterer attributten interessestring de informationer, der skal søges igennem. 83

89 SØGEALGORITME Vi vil forsøge at blande en lineær traversering med at søge effektivt i et litteraturobjekts attirbutter. Vi vil nu præsentere vores metode. Vi har i koden skrevet en klasse Soegning, som initialiseres med en streng af søgeord som argument. I contructoren for klassen splittes strengen over komma, bliver sat til lower case og får fjernet mellemrum i enderne af hvert søgeord og assignes herefter til strengarrayet soegeord. Klassen tjener det formål at indkapsle den egentlige søgealgoritme, Boyer-Moores algoritme, som vi vil præsentere senere. Denne indkapsling foregår vha. metoderne SoegSpecifik(int nummer) og SoegFlere(int antal). SoegFlere(int antal) tager som input antallet af strenge i soegeord og returnerer søgeresultatet for disse ord som en generisk mængde af typen Litteratur. Ideen er, at SoegFlere ved inputtet i skal returnere søgeresultatet for fællesmængden mellem søgeresultatet for soegeord[i-1] og SoegFlere på i 1. Fællesmængden tages vha. metoden Intersection, der er indeholdt i Set<T> (se TING- TILSOEGNING.CS for en definition af Set<T>). Det er SoegSpecifik, der returnerer et søgeresultat for et enkelt ord, som en generisk mængde af typen Litteratur. De to funktioner er defineret som: 65 public Set < L i t t e r a t u r > SoegFlere ( i n t antalord ) 66 { 67 i f ( antalord == 1) 68 { 69 return SoegSpecifik ( 0 ) ; 70 } 71 else 72 { 73 return SoegFlere ( antalord 1). I n t e r s e c t i o n ( SoegSpecifik ( antalord 1) ) ; 74 } 75 } I definitionen af SoegSpecifik bruges Boyer-Moores algoritme (BoyerMoore- Matcher), der hurtigt kan konstatere om en streng indeholder en given delstreng. Vi analyserer denne algoritme i afsnit BoyerMooreMatcher tager som input strengen man vil søge i og den søgte streng og returnerer true eller false, alt efter om den søgte streng er indeholdt. I kildekoden nævnes ArrayListen _internliste, som indeholder alle stykker litteratur i systemet. Hvis et stykke litteratur fra denne liste matcher søgeordet, tilføjes det pågældende litteratur til den generisk mængde resultat, som til sidst returneres. 84

90 SØGEALGORITME 48 public Set < L i t t e r a t u r > SoegSpecifik ( i n t nummer) 49 { 50 Set < L i t t e r a t u r > r e s u l t a t = new Set < L i t t e r a t u r > ( ) ; foreach ( L i t t e r a t u r l in _ i n t e r n l i s t e ) 53 { 54 i f ( BoyerMoore. BoyerMooreMatcher ( l. I n t e r e s s e s t r i n g. ToLower ( ), soegeord [nummer ] ) ==true ) 55 { 56 r e s u l t a t. I n s e r t ( l ) ; 57 } 58 } 59 return r e s u l t a t ; 60 } Attributten interessestring sættes, som søgeordene, også til lower case som det ses ovenfor. På denne måde bliver søgningen ikke case sensitive. Som det fremgår af SoegFlere splittes problemet i at søge på flere søgeord ned til at tage fællesmængde over mængderne af resultater for hvert søgeord. Vi vil i følgende sætning vise korrektheden af dette. Sætning Ved algoritmens slut er resultatet lig fællesmængden over mængderne til de givne søgeord. Bevis. Beviset foregår ved induktion på antallet af søgeord. For ét søgeord returneres SoegSpecifik(0), som er resultatet for søgeordet. Trivielt er det fællesmængden af én mængde. Vi antager, at resultatet gælder for n 1 søgeord og vi vil nu vise, at det gælder for n søgeord. Hvis vi tager SoegFlere på n fås SoegFlere(n) = SoegFlere(n 1) SoegSpecifik(n 1). (9.1) Vi har fra induktionsantagelse et udtryk for SoegFlere(n-1) som vi sætter ind i (9.1). SoegFlere(n) = SoegSpecifik(0)... SoegSpecifik(n 2) SoegSpecifik(n 1). Herved fås resultatet. Vi vil nu analysere Boyer-Moores algoritme. 85

91 SØGEALGORITME Boyer-Moores algoritme Vi vil i dette afsnit se på Boyer-Moores algoritme. Igennem afsnittet vil delstreng repræsentere den streng vi søger efter. Ligeledes vil streng være den streng vi søger i. Lad os først overveje problemet i at afgøre om en delstreng i en streng. En simpel algoritme (implementeret i C#) til at afgøre problemet er som følger: string streng =...; string delstreng =...; int n = streng.length; int m = delstreng.length; for (int s = 0 ; s <= n-m ; s++) do if (delstreng == streng.substring(s,m)) then Console.WriteLine( Delstrengen blev fundet efter + Convert.ToString(s) + skift ); end end Metode string SimpelDelstrengCheck Algoritmen skubber delstreng (et skub omtales som et shift) langs streng indtil man muligvis finder, at de to strenge er ens for et givent shift. For hver af de n m + 1 mulige værdier af s skal der foretages m sammenligninger for at kontrollere om der for hver karakter i delstreng er overenstemmelse med karakterer i streng (overenstemmelse kaldes match; modsat mismatch). Algoritmen er derfor Θ((n m + 1)m). Denne algoritme er ikke optimal som vi vil se. Et argument er, at man ikke bruger informationen om et mismatch i en position i den næste position, selvom det kunne være nyttigt. F.eks. ville vi, hvis der imellem delstreng og streng er et mismatch og det pågældende tegn i streng ikke findes i delstreng, kunne shifte delstreng forbi mismatchet uden at bekymre os om matches. Betragt som eksempel figur s k r a l d e s p a n d... k u n d e Figur 9.3: Et mismatch findes Der er et mismatch mellem e i "kunde"og det andet s i "skraldespand". 86

92 SØGEALGORITME Da s ikke findes i "kunde"kan man shifte "kunde"sådan at k sættes under p i "skraldespand". Algoritmen Vi har valgt at skrive algoritmen som den står i [Cormen et al., 1990] med to forbehold; algoritmen er oversat til C#-syntaks og vores notation, samt at vi bruger en lettere modificeret udgave. Grunden til, at vi modificerer den er, at vi ikke har brug for at vide hvilket index algoritmen har fundet delstrengen på i strengen. Vi behøver kun at vide, at den er fundet. Input: Strenge delstreng og streng Output: True eller False alt efter om delstrengen er fundet. int n = streng.length; int m = delstreng.length; int[] gamma = ComputeGoodSuffix(delstreng, m); HashTable lambda = ComputeLastOccurrence(delstreng); int s = 0; while (s <= n-m) do int j=m; while (j>0 && delstreng[j-1] == streng[s+j-1]) do j = j-1; end if j == 0 then return true; s = s + gamma[0]; else s = s + Math.Max(gamma[j], j-(lambda[streng[s+j-1]]+1)); end end return false; Algoritme 2: Boyer-Moores algoritme Hvis man erstatter linjerne, hvor s tælles op med s = s + 1, har man den simple algoritme for delstrengsøgning. Det, at vi kan tælle s op med mere end 1, gør Boyer-Moores algoritme mere fordelagtig. Hvor man i den simple strengsøgningsalgoritme bare vil vide om streng er lig delstreng for forskellige shifts, sammenligner man i Boyer-Moores algoritme strengene bagfra. Algoritmen preprocesser som det første delstreng med metoderne ComputeGoodSuffix og ComputeLastOccurence, som kan ses i filen TINGTILSO- 87

93 SØGEALGORITME EGNING.CS. ComputeGoodSuffix returnerer et array af heltal (der er nulindekseret) der fortæller os hvor meget vi mindst kan shifte delstreng for, at et matchende suffix i delstreng ikke bliver mismatchet efter shiftet. ComputeLastOccurence returnerer en hash-tabel hvori man for hvert tegn i inputalfabetet Σ, kan slå en tilhørende værdi op. Værdien for tegn i delstreng er indexet af forekomsten af tegnet længst til højre i delstreng og for værdier ikke i delstreng er værdien -1. Dette skyldes at hvis vi for tegn der ikke er i delstreng skal have at j (lambda(streng[s + j 1]) + 1) = j, må vi i ComputeLastOccurrence returnere værdien 1 for tegn, der ikke er i delstreng, og ikke 0 som i litteraturen, for at kompensere for +1 når s tælles op med j (lambda(streng[s + j 1]) + 1). Dette +1 skyldes i øvrigt at nulindeksering gør at lambda bliver én for lille for tegn i delstreng. Som det ses virker algoritmen på den måde, at under forudsætning af at j > 0 og delstreng[j 1] == streng[s + j 1] bliver j talt 1 ned til at udsagnet bliver falsk eller at j bliver 0. Hvis j = 0 har vi kontrolleret, at alle m indgange i delstreng matcher de tilsvarende indgange i streng og vi har fundet en forekomst. I formuleringen af algoritmen i [Cormen et al., 1990] vil algoritmen ved j = 0 skrive til skærmen, at der er fundet en forekomst og fortsætte søgningen. Vi vælger som før nævnt at returnere true, hvilket i realiteten gør linjen s = s + gamma[0] overflødig. Hvis s > n m vælger vi at algoritmen skal returnere false. Der er to såkaldte heuristikker i spil: bad-character-heuristikken og goodsuffix-heuristikken. Det er disse der fortæller hvor meget vi kan øge s for kunne shifte delstreng så langt som muligt videre. Bemærk at heuristikkerne afhænger af ComputeGoodSuffix og ComputeLastOccurence. Lad os se et eksempel fra [Cormen et al., 1990]: Eksempel 1 Vi ønsker at finde ud af om strengen reminiscence er indeholdt i en større streng. Lad os antage, at vi har følgende situation (figur 9.4)... w r i t t e n _ n o t i c e _ t h a t... r e m i n i s c e n c e Figur 9.4: Et mismatch er fundet Ved j = 10 er der fundet et mismatch. Heuristikkerne foreslår følgende: En endelse af en streng f.eks. logi i datalogi. 88

94 SØGEALGORITME Bad-character-heuristikken: Det foreslås her at vi skal shifte reminiscence j (index på forekomst af i længst til højre i reminiscence + 1) = 4 til højre.... w r i t t e n _ n o t i c e _ t h a t... r e m i n i s c e n c e Figur 9.5: Bad-character-heuristikken Hvis ikke i fandtes i reminiscence ville vi som tidligere nævnt s- hifte strengen 10 tegn til højre (da lambda( i ) så ville være 0). Hvis forekomsten af i længst til højre i reminiscence er til højre for j = 10 foreslås et negativt antal shift (dette majoriseres af gammafunktionen der er positiv for j = 1, 2..., m). Good-suffix-heuristikken: ComputeGoodSuffix udregner integer-arrayet (12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 3, 3) så der foreslås at shifte reminiscence 3 shift til højre for at matche suffixet ce med den næste forekomst af ce (mod venstre).... w r i t t e n _ n o t i c e _ t h a t... r e m i n i s c e n c e Figur 9.6: Good-suffix-heuristikken I dette tilfælde foreslår bad-character-heuristikken det største antal shift. Tidskompleksitet af implementation Lad os definere T(l) som værende antallet af sammenligninger for SoegFlere på l søgeord. Vi har da følgende rekurrensligning T(1) = c 1 (9.2) T(l) = c 1 + T(l 1) + c 2, l > 1, (9.3) hvor c 1 er antal sammenligninger for SoegSpecifik og c 2 er antal sammenligninger for at bruge.intersection i Set<T>. 89

95 SØGEALGORITME Metoden.Intersection i Set<T> er O( A ) hvor A er mængden, der skal tages fællesmængde med. For SoegSpecifik skal vi kende nogle delresultater. ComputeGoodSuffix er O(m), ComputeLastOccurence er O(m + Σ ) og for hver af de n m + 1 mulige værdier af s (i værste tilfælde) er tjekket om hvorvidt de to strenge er ens, O(m). Samlet har vi i worst case m + m + Σ + (n m + 1)m 2(m + Σ + m(n m + 1)), hvilket betyder at Boyer-Moores algoritme er O(m + Σ + m(n m + 1)). Algoritmen skal i SoegFlere udføres L gange hvor L er mængden af litteratur. Bemærk desuden at der for l søgeord skal tages l 1 sammenmængder og at A L. Dvs. at vi får at T(l) er O( L (m + Σ + m(n m + 1)) + (l 1) L ) Test af vores metode imod alternativer For at undersøge vores påstande omkring fordelene vores måde at implementere søgningen på har vi valgt at udføre nogle test på vores implementation af Boyer-Moores algoritme, C# s.contains og MySQL s indbyggede søgealgoritmer. Det skal nævnes, at vi også indkapsler C# s.contains i vores rekursive algoritme. Vi har valgt kun at teste på tidsforbruget af de forskellige metoder, da f.eks. korrektheden tages for givet. Testen dækker søgeord af forskellig længde for at give et sandfærdigt billede. Testen er udført ved at starte et Stopwatch (indeholdt i namespacet System.Diagnostics) når søgningen påbegyndes og stoppe det lige efter søgningen er udført. En enkelt test på et søgeord udføres 15 gange for at minimere afvigelse, hvilket kan være forårsaget af ydre faktorer som vi ikke kan kontrollere. Herefter tages et gennemsnit over tiderne. Resultatet er vist i tabel 9.1 og tabel 9.2. Søgningen med MySQL er udført ved at udføre kommandoen SELECT * FROM <litteraturtype> WHERE MATCH (<attribut_1>,...,<attribut_n>) AGAINST ( +ord_1... +_ord_n IN BOOLEAN MODE) på databasen for hver type litteratur. Testen er udført på en standardpc med følgende specifikationer: 1800 Mhz, 512 MB RAM, Windows XP Pro, 100MBit netkort. 90

96 SØGEALGORITME Metode \ Søgt streng C Java Hanspeter Vores metode med Boyer-Moore 0, , ,0013 Vores metode med C# s.contains 0, , ,00018 MySQL 0, , , Tabel 9.1: Testresultat i sekunder algorithms Hanspeter,point Introduction,algorithms 0, , , , , , , , , Tabel 9.2: Testresultat i sekunder Som ses er Boyer-Moores algoritme langsommere end C# s.contains, men ikke meget. MySQL-søgningen er en del langsommere end Boyer-Moores algoritme. Dette illustreres på figur 9.7. Figur 9.7: Tidsforbrug for de forskellige metoder Det skal bemærkes at vi i flere tilfælde har oplevet at en MySQL-søgning tager omkring 2 sekunder, fordi databasen ikke svarer. Dette kan evt. skyldes den intensive brug af databasen, jf. at 15 forbindelser oprettes på få sekunder. Konklusionen på afsnittet er at Boyer-Moores algoritme ikke er hurtigere end C# s.contains men at vi har kunnet gøre det næsten lige så hurtigt. Desuden har vi opfyldt vores faktor-tabel (tabel A.1) om at søgningen 91

97 UNIT TESTING maksimalt må tage 5 sekunder, da vi ikke forventer at søgningen bliver meget langsommere ved at tilføje flere bøger Unit testing Som en akademisk øvelse har vi udført unit testing på udvalgte klasser i vores program. Unittesting er et princip inden for programmering, hvor man afprøver korrektheden af et programs moduler uafhængigt af hovedprogrammet [WikiPedia, 2006], og undersøger om instantiering af klasser og disses metoder er implementeret korrekt. Typisk vil unittesting indgå som den del af udviklingsmetoden Test Driven Development [Stott og Newkirk, 2006], hvor man inden, der overhovedet er skrevet en linje kode, skriver en test, som skal passeres for at koden er korrekt. Derefter skrives programkoden således, at den overholder de krav, der stilles i testen. Unittesting kan også bruges under andre udvikingsmetoder til at bekræfte, at ens programkode fungerer på forskellige stadier i udviklingen. For eksempel kan unittesting af et programmodul benyttes, hvis man ændrer en stump programkode i en metode, hvorved det verificeres, at ændringen ikke har ødelagt noget vitalt i metoden, hvad output angår, hvis testen udføres uden fejl. Unit testing kan også bruges ved udbyggelse af allerede fungerende funktioner i et program, således testen tager højde for disse ændringer, hvilket gør det lettere at debugge funktionen efterfølgende [Provost, 2006]. Ved programudvikling i C# kan man f.eks. benytte testframeworket NUnit [Two et al., 2006] til unittest af programmets klasser. Dette gøres ved at skrive test klasser til programmets individuelle klasser eller moduler, hvor der benyttes forskellige attributter og metoder forsynet med NUnit- -frameworket. Disse testklasser kompileres derefter som dynamic-linked libraries, som siden kan køres som tests med NUnit værktøjerne. Disse undersøger om testen overholder de opstillede krav vha. de indkodede assertionmetoder. Et eksempel på en klasse med indsatte NUnit-framework attributter og assertions kan ses listet nedenunder: 1 [ Test ] 2 public void B i b l i o t e k a r E k s i s t e n s T e s t ( ) 3 { 4 Assert. IsInstanceOfType ( typeof ( Persons. B i b l i o t e k a r ), T e s t B i b l i o t e k a r ) ; 5 S t r i n g A s s e r t. Contains ( " Legroskon ", T e s t B i b l i o t e k a r. Forname ) ; 92

98 UNIT TESTING 6 S t r i n g A s s e r t. Contains ( " Legroskon ", T e s t B i b l i o t e k a r. Efternavn ) ; 7 Assert. AreEqual ( 1, T e s t B i b l i o t e k a r. S t a t u s ) ; 8 S t r i n g A s s e r t. Contains ( " LL@cs. aau. dk", T e s t B i b l i o t e k a r. Mail ) ; 9 Assert. AreEqual ( , T e s t B i b l i o t e k a r. T l f ) ; 10 Assert. AreEqual ( 6, T e s t B i b l i o t e k a r. Id ) ; 11 S t r i n g A s s e r t. Contains ( "E 208 ", T e s t B i b l i o t e k a r. Lokale ) ; 12 } Generelt set skal man, hvis man beslutter sig for at benytte unittesting, teste alle klasserne igennem i et program. Dette er en meget tidskrævende process, hvis man skriver et større program, idet testene både skal planlægges, implementeres og udføres korrekt for samtlige klasser i programmet. På denne baggrund, og fordi vi ikke decideret har valgt at benytte testdriven development som udviklingsmetode har vi besluttet ikke at udføre unittesting af hele programmet, men blot demonstrere hvorledes det kan gøres. Til det formål har vi udvalgt tre klasser i vores program. Det drejer sig om de to kerne klasser Litteratur og Person samt klassen LaanerController idet de er meget repræsentative for vores program. Klasserne Person og Litteratur repræsenterer tilsvarende objekter i den virkelige verden i systemet og instantieres ofte mens klassen LaanerController indeholder en række metoder, der definerer, hvilke handlinger en egentlig låner kan udføre på de førnævnte objekter af Person og Litteratur klasserne. Idet testen for Person klassen minder meget om testen for Litteratur klassen er den ikke belyst i rapporten, men inkluderet i programmet for den interesserede læser Unit test: Litteratur Unttesten for Litteratur klassen har til formål at verificere, at de instantieres korrekt i systemet. For at undersøge dette, testes der om det instantierede objekts findes, om det er af den rigtige type og om dens attributter har de forventede værdier efter instantiering med klassens constructor. Disse testes kan listes som følgende: Eksistenstest - eksisterer objekterne efter oprettelse? Objekttypetest - er de eksisterende objekter af den type de er oprettet til at være? 93

99 UNIT TESTING Attributtest - er attributterne det som de er definerede til at være i subklassernes constructors? BibTeX-genereringstest - oprettes den rigtige BibTeX information ud fra subklassernes attributter? Artikeltest - kan en artikel defineres som indeholdt i et andet stykke litteratur? Til hver testtype udarbejdes præ- og post-betingelser, som skal overholdes for at testen kan betragtes som successfuld. Testen skrives da i henhold til disse således, at hvis betingelserne er overholdt efter programkodens udførsel i programmet vil testen betragtes som udført. Testene udføres for subklasser af Litteratur klassen, idet denne er abstrakt og den kun bruges til nedarvning af fælles attributter for dens subklasser. Testcase: Eksistenstest Eksistenstesten udføres for at teste om det er muligt at oprette litteratur af alle typer i systemet. En negativ test ville medføre, at der eksisterer en fejl i programmeringen, således der ikke kan oprettes litteratur af den givne type korrekt. Testcase: Objekttypetest Objekttypetesten er en supplerende test til eksistenstesten, idet det er relevant at teste om det oprettede objekt er af den rette type. Hvis testen fejler, er der en programmeringsfejl i instantieringen af objektet. Testcase: Attributtest Efter det er verificeret om objekterne eksisterer og om de er af den rette type testes der om attributterne, tilskrevet objekterne under oprettelse, er de forventede. Dette gøres under en attributtest, hvor værdien af hver enkelt attribut bekræftes. Hvis testen melder et negativt resultat betyder det, at der forefindes en fejl under instantieringen af objektet, hvilket med høj sandsynlighed betyder en fejl i constructoren. Testcase: BibTeX-genereringstest I litteraturklassens subklasser findes der metoder til at generere BibTex-information ud fra et objekts attributter, som siden tilskrives objektets BibTeX-attribut. Disse metoder er forskellige for hver subklasse, og testes individuelt for at verificere deres korekthed i henhold til, hvilket output disse returnerer. Der bekræftes om det output, som er resultatet af BibTeX-genereringsprocessen, stemmer overens med det forventede output. Hvis testen viser sig negativ, forefindes en fejl i BibTeX-genereringsprocessen. 94

100 UNIT TESTING Testcase: Artikeltest Litteraturtyperne Proceeding og Tidsskrift indeholder hver en række artikler, som også kommer til at eksistere i systemet med relation til deres forælderlitteratur. Dette tilhørsforhold defineres som en attribut på artiklen, der også skal testes for korrekt implementation. Hvis testen melder et negativt resultat betyder dette en fejl i implementationen af denne funktion således artikler ikke kan defineres som værende indholdt i andet litteratur Unit test: LaanerController Klassen LaanerController indeholder metoder, som kaldes fra brugergrænsefladen til at manipulere objekter i modellaget samt gemme ændringer til persistenslaget. Klassen har ansvar for at sende information videre til en anden klasse i systemet, som udfører de handlinger som LaanerControlleren forespørger. Disse handlinger består typisk i at manipulere data i persistenslaget således, at der registeres information om de lån eller reservationer en låner har foretaget, men også metoder til at udhente information om udlånt litteratur og lignende findes i LaanerController klassen. For at passere unittesten succesfuldt skal følgende tests kunne gennemføres korrekt: Et lån skal udføres korrekt. Information om lån skal kunne udhentes korrekt. En afevering skal kunne udføres korrekt. En reservation skal kunne foretages korrekt. En udhentning af information om reservationer test. Reserveret litteratur skal kunne afreserveres korrekt. Quicklån og quickafleverings test. Testene udføres med data fra den mysql database, der anvendes som persistenslag under implementeringen og derfor er det vigtigt, at denne indeholder de rette data for, at testen fungerer efter hensigten. Inden hver deltest, indlæses denne data ind fra databasen til oprettelse af et lånerobjekt samt to litteraturobjekter, der anvendes under testen. Testene, for reservation, udhentning af information om reservation og afreservation er ikke dokumenteret her i rapporten idet de i opbygning og udførsel minder 95

101 UNIT TESTING eget om de tilsvarende tests for lån og aflevering. Disse tests er istedet dokumenteret på den vedlagte Cd-rom i filen LAANERCONTROLLERTEST.CS eller i den vedlagte dokumentation. Testcase: Udfør lån Denne test har til formål at bekræfte metoden til at låne et stykke litteratur er implementeret korrekt. Først kaldes metoden til at låne et eller flere stykker litteratur med en arrayliste indeholdende litteraturid på litteraturen, der ønskes lånt samt låneren, der ønsker at låne det som argument. Det bekræftes, at en låners attribut for antal lån er ø- get tilsvarende antallet af foretagne lån efter udførsel af dette metodekald. Hvis denne tæller stemmer overens med det forventede, er testen udført med positivt resultat. Testcase: Udhentning af information om lån Denne test har til formål at bekræfte metoden til at udhente information om en låners lån er korrekt. Til det formål kaldes metoden til udhentning af en låners lån fra persistenslaget. Det bekræftes, at disse er identiske med de lån, der lige er foretaget. Hvis disse to lister stemmer overens, er testen udført med positivt resultat. Testcase: Udfør aflevering Denne test har til formål at bekræfte metoden til at aflevere litteratur er korrekt. Til det formål kaldes metoden til aflevering af en låners lån med en arrayliste indeholdende litteraturid for de stykker litteratur, der ønskes afleveret som argument. Det bekræftes derefter, at en låners attribut for antal lån er talt ned tilsvarende antal af elementer i arraylisten (såfremt alle elementer i listen stemmer overens med litteratur han har lånt). Testcase: Quicklån og quickaflevering Denne test har til formål at bekræfte, at metoderne til quicklån og quickaflevering, fungerer korrekt. Idet disse blot udfører hindandens modsatte handlinger, lån og aflever, testes de i samtidigt. Først kaldes metoden for quicklån og det bekræftes, at en låners antal lån er gået et enkelt lån op. Derefter hentes dette lån ud og det bekræftes, at dette er lig med lånet, der netop er foretaget. Derefter kaldes quickafleveringsmetoden for denne bruger samt det litteratur, der netop er lånt. Det bekræftes, at lånerens antal lån er gået ned med en. Hvis disse bekræftelser returnerer et positivt resultat, er testen udført korrekt. 96

102 KONKLUSION Testresultater Idet vi har anvendt unittesting, som en slags post-production test, har det medført, at testene generelt virkede trivielle. De udførte unittests gennemførtes korrekt idet klasserne, der benyttedes til testen, allerede gennem usecase testing og iterativ testing har været grundigt testet. Grunden til u- nittesting generelt har virket som en triviel øvelse er, at vores udviklingsmetode ikke har været gearet så meget til unittesting, idet programmeringsfasen i høj grad har benyttet sig af prototyping, istedet for formelle tests. Det kan blandt andet tilskrives en sen introduktion til testing i kurset Objekt Orientet Programmering, men også fordi der gennemgående har været en implicit forståelse for, hvad systemets forskellige metoder burde gøre inden disse blev implementeret. I retrospekt kunne man med fordel have anvendt unit testing som en integreret del af vores udviklingsproces, istedet for manuelt at bugteste programmet for fejl. Et problem, der viste sig under udarbejdelsen af unit testene, var at det var svært at planlægge en test for en klasse, der stadig var under udarbejdelse. Under testen af LånerControlleren var der for eksempel en del forvirring over, hvad de forskellige metoder som lån og aflevering modtog som input, idet de stadig var under implementation. Dette medførte at disse metoder blev skrevet om, således at de modtog ensartet input, baseret på erfaringerne gjort under testskrivningen. Til dette formål har unittesting vist sig nyttigt, idet det har vist, at vores kode i første omgang har været lettere forvirrende skrevet eller uhensigtsmæssigt dokumenteret. Testene kan findes på den vedlagte CD-rom Konklusion Som konklusion på produktrapporten gives en vurdering af programmet som det ser ud ved aflevering. Denne vurdering vil liste de features op i programmet, som vi er tilfredse med, samt liste de features vi ikke er så stolte af, eller features vi ikke føler er implementeret tilfredsstillende i programmets nuværende tilstand. Derudover gives en vurdering af programmet i forhold til de opstillede krav i systemdefintionen, de opstillede usability-mål og designkriterierne for at se om vi overordnet har opfyldt MI-gruppens og egne krav til systemet. Positive aspekter ved systemet Under udvikling af programmet er der en række features vi mener fungerer bedre end forventet, er innovative, 97

103 KONKLUSION eller som vi ikke har beskæftiget os med under dette semesters kursusgange, og derfor har udført ekstra research for at kunne implementere. 1. Vores søgemetode og måde at vise søgeresultater på, mener vi er en anderledes måde at anvende søgning i data i forhold til, hvorledes denne er implementeret i lignende bibliotekssystemer. Istedet for den traditionelle statiske søgning fundet i mange andre systemer, opdateres søgeresultatet løbende efter, hvilket input, der er modtaget, hvilket i vores øjne er en ret ny måde at gøre tingene på. Derudover har vi implementeret en version af Boyer-Moore søgealgoritmen, som returnerer et gyldigt søgeresultat inden for den ønskede tid i henhold til kravene i faktortabellen i A.1. Derudover viser resultaterne fra afsnit på side 90, at vores implementation af algoritmen søger mere effektivt end den indbyggede søgemetode i vores anvendte database.. 2. Vi har implementeret et automatisk mailing system i vores system, der sender mails ud til brugere, såfremt et stykke reserveret litteratur er ledigt eller et stykke litteratur har overskredet afleveringsdatoen. Det vil sige der er mulighed for automatisk at meddele systemets brugere, at litteratur kan afhentes eller skal afleveres, hvilket letter arbejdet for en bibliotekar. Således skal han/hun ikke manuelt skal gøre dette for hvert stykke litteratur i systemet. Vi mener, at denne funktion er en central del af et moderne bibliotekssystem og har således valgt at bruge den tid, der skulle til for at implementere det, på trods af en sådan funktionalitet ikke er dækket af vores kursusmateriale. 3. Istedet for at implementere serialisation som persistenslag i systemet, har vi valgt at benytte en MySQL database som persistenslag. Det betyder, at vi ikke direkte gemmer objekter i persistenslaget som ved serialisation, men i stedet gemmer objekternes attributter i databasen. Denne måde at gemme data på gør vi kan instantiere objekterne igen ud fra denne data. Beslutningen om at skifte til en database som persistenslag blev taget på baggrund af, at databaser er en kendt og velafprøvet måde at håndtere store mængder data på. For eksempel kan man hurtigt ændre i databasens indhold skulle det være nødvendigt, hvilket ikke er muligt ved serialisation. størrelser. Negative aspekter ved systemet De implementationer, designs eller features vi ikke er helt tilfreds med i programmet belyses i dette afsnit. Under 98

104 KONKLUSION udviklingen af systemet har der været dele af programmet som vi bevidst har nedprioriteret, idet der fra vores synspunkt har været vigtige ting at implementere. Disse nedprioriterede aspekter er også vigtige at vurdere, idet de kan lægge grund for yderligere udvikling. Ting som vi selv føler er fejl og mangler i systemet belyses også i dette afsnit, med forslag til udbedringer mm. af disse. 1. Controllerne i systemet indeholder i implementationen pt. ingen constructor, hvilket betyder de instantieres parameterløst. Det virker på en måde omsonst at instantiere et objekt af denne klasse for at bruge disse metoder, idet de egentligt aldrig ændrer sig eller ændrer tilstand. Som en løsning kunne man have gjort klasserne statiske, eller f.eks. instantiere controlleren med et låner eller bibliotekar-objekt. Sidstenævnte måde at implementere controllerne på, ville dog skabe en højere kobling og være i konflikt med vores arkitektur, idet funktionslaget skal holdes adskilt fra modellaget. Man kunne også argumentere for, at controllerne skulle defineres som singletons, da der højst kan arbejde en bibliotekar eller en låner med systemet ad gangen. På trods af disse argumenter har vi valgt at holde fast ved ideen om at instantiere controllerne for at bruge metoderne der, idet funktionslaget (som jo består af vores controllers) holdes som et slags separat, og ubundet lag i arkitekturen, hvilket svækker dens kobling til andre lag. 2. Systemet gør stor brug af DataGridViews, som vi har fundet er meget ufleksible hvad angår dynamisk opdatering. Hvis man øsnker at indholdet dynamisk skal opdateres, bliver man nødt til at opdatere dem og indlæse indholdet igen fra kilden, hvilket gør det et stort arbejde overhovedet at holde styr på om dette sker. Et eksempel er indkøbslisten i nederste venstre hjørne i hoved vinduet, hvortil der tilføjes de ønskede stykker litteratur til lån og reservation. Som systemet fungerer nu, kan man ved fjernelse af elementer fra indkøbslisten, ikke tilføje dem til den igen før DataGridView et med søgeresultater er opdateret, hvilket gøres med et tastetryk på F2 knappen på tastaturet. Skulle systemet videreudvikles, bør det overvejes om en del af det dynamiske indhold bør laves mere statisk, så der ikke foreligger så meget genindlæsningsarbejde. Det vil dog gå ud over dynamikken i systemet, så derfor vurderes det ikke kritisk at ændre det på nuværende tidspunkt, idet systemet egentligt fungerer med den manuelle opdatering. 3. Vi har efter en del irritation fundet ud af at måden hvorpå vi udfyl- 99

105 KONKLUSION der DataGridViews på, kan forbedres. Som det er nu, afbilder Data- GridViews som regel en ArrayList. Hvis man sorterer DataGridViewet (ved at trykke på det grå felt i toppen af en kolonne) flytter informationerne måske plads og en række med index i i DataGridView et vil nu muligvis ikke svare til index i i arraylisten, da listen selv ikke påvirkes af sorteringen. For at komme dette i forkøbet har vi fjernet muligheden for sortering hvilket ikke er den bedste løsning. I stedet kunne vi have brugt en BindingList eller en anden collection der implementerer IBindingList. Med denne vurdering i mente, opfylder vi så også målene defineret i systemdefinitionen (Se afsnit 2.4 på side 6)? Systemet indeholder grundlæggende funktionalitet til at varetage opgaverne i det nuværende bibliotekssystem, samt tilføjer ny funktionalitet til udførsel af diverse gøremål såsom basal reservation af litteratur. I den forstand opfylder systemet kravene fra systemdefinitionen, men det kan diskuteres om disse gøremål i biblioteket kan udføres hurtigt og enkelt. For at undersøge diverse usability problemer i systemet udførte vi en usabilitytest, som er dokumenteret i studierapporten afsnit 10 på side 102. Testresultaterne fra denne test viste at en uforberedt bruger oplevede en del problemer med vores system, men idet denne test kun blev udført på en enkelt testperson, mener vi ikke at den viser noget endeligt om vores system. Vi mener selv at kriterierne for effectiveness og efficency (se afsnit 4.4 på side 26) til dels er opfyldte, idet man efter at have anvendt systemet i et stykke tid, kan udføre de mest essentielle opgaver inden for rimelig tid. I henhold til designkriterierne i afsnit 7.1 på side 36, mener vi ikke at alle krav vægtet som meget vigtige er tilfredsstillende opfyldt, idet nogle avancerede funktioner ikke fungerer optimalt og brugbarheden ikke er i top. Overordnet er vi tilfredse med det udviklede system, men det er tydeligt for os, at der er plads til forbedringer. 100

106 Del IV Studierapport 101

107 Kapitel 10 Usability test Hen mod afslutningen af implementationen af systemet, udførte vi en usability test på vores system, for at opnå indsigt i hvordan andre mennesker end os selv som udviklere af systemet, opfatter og interagerer med systemet. Det giver sig selv, at når man selv sidder med systemet i hverdagen, opnår man en meget stor viden omkring alle de funktioner, man selv vælger at implementere, men ofte vil man selv ikke kunne gennemskue alle de forskellige måder et andet menneske vil opfatte systemet på. Eksempelvist hvis man implementerer et vindue, hvori det er muligt at højreklikke på alle objekterne for at aktivere en given funktion, kan man let blive overrasket, hvis det viser sig at ens fremtidige brugere forventer at skulle dobbeltklikke på objekterne, men systemet forbliver ikke-responderende eller i værste fald afslutter med en fejlbesked. Med denne forståelse i mente, vil vi nu kort beskrive vores erfaringer fra vores usabilitytest. Der foreligger en fuld transkription af usability testen i appendix A Forsøgsopstilling og andre præparationer Forud for forsøget var der udarbejdet en testplan på engelsk, da vores testperson ikke talte dansk. Denne testplan findes i appendix A.5 Den benyttede computer var den maskine som er til rådighed i testlokalet (subject room 1 på figur 10.1).Vi havde kort før selve forsøget installeret vores system på computeren og åbnet en ODBC-datakilde på computeren, så vores program kunne kommunikere med databasen. Forsøgsopstillingen kan ses afbildet på figur

108 TESTOPGAVER Figur 10.1: Forsøgsopstilling 10.2 Forsøget En person fra gruppen optrådte som testleder, som var sammen med vores indkaldte testperson. Resten af gruppen var i et andet lokale og udnyttede de tilgængelige faciliteter (videooptagelse af skærmbilledet og testpersonen ansigtudtryk) og skrev løbende kommentarer til testen Testopgaver Nedenfor kan ses en oversigt over de opgaver testpersonen skulle udføre: Opgave 1: Søgning af litteratur Find bogen Introduction to algorithms af Thomas H. Cormen. Er bogen ledig? 103

109 TESTOPGAVER Hvad er bogens ISBN-nummer? Opgave 2: Lån af litteratur Find bogen Coding and information theory af Steve Roman. Lån bogen. Gå til din låner-menu og verificer, at bogen er blevet lånt. Aflever bogen igen. Opgave 3: Reservation af litteratur Find bogen Interaction Design by Hanspeter Mössenböck. ISBNnummeret er X. Foretag en reservation af denne bog. Verificer ved hjælp af din låner menu, at bogen er reserveret. Afreserver bogen igen. Opgave 4: Oprettelse af litteratur Opret bogen C# to the point af Hanspeter Mössenböck. Bogen har ISBN-nummeret X. Verificer om bogen er blevet oprettet. Opgave 5: Oprettelse af lånere Opret låneren Jens Tarzan i systemet. Jens har [email protected], bor i lokale E3-104 og har telefonnummer Slet Jens igen. Opgave 6: Se statistik Find navnet på den mest aktive låner. 104

110 PROBLEMLISTE 10.4 Problemliste I dette afsnit vil vi vurdere de identificerede brugbarhedsproblemer usability testen afslørede. Vurderingen er baseret på et skema fra DIEB-forelæser Jan Stages hjemmeside og kan ses på figur Figur 10.2: Vurderingsskema Problemernes alvorlighed vurderes ud fra, hvor lang tid det tager for testpersonen, at løse eller formår at løse testopgaven, hvor stor irritation testpersonen føler ved løsningen af den givne opgave samt, hvor meget systemets reaktion afviger fra testpersonens forventede opfattelse af systemets reaktion. På tabel 10.1 ses de brugbarhedsproblemer, der opstod i forbindelse med usability testen af systemet, listet. Kategorien af de forskellige problemer er vurderet ud fra, hvilken grad disse har ført til problemer med at løse den givne opgave. 105

111 PROBLEMLISTE Brugbarhedsproblem Søgning: Søgeresultaterne opdateredes ikke korrekt Information: Overser højrekliksfunktion for at se mere information om materiale Information: Lån information er ikke forståelig Generelt: Kan ikke finde menu til at foretage lån Information: Kan ikke finde dato for, hvornår materiale kan afhentes Generelt: Overser afkrydsningsfelter for afreservering af materiale Generelt: Overser Hent ISBN fra net funktion Information: Tvivl om, hvorvidt et materiale er oprettet i systemet Kategori Kritisk Kritisk Kritisk Kritisk Kritisk Alvorlig Kosmetisk Kritisk Tabel 10.1: Problemliste Nedenfor beskrives, hvorledes de forskellige problemer listet på tabel 10.1 er oplevet af vores testperson. 1. Under testopgave 1 fandt testpersonen en bug i systemet. Testpersonen tastede søgeordene for bogen ind, men lavede en stavefejl og slettede derfor de forkert indtastede tegn igen. Her opstod en bug i systemet, idet brugen af backspace medførte, at søgeresultaterne ikke længere blev opdateret. Det endte derfor med, at testpersonen ikke var i stand til at finde på materialet pga. denne fejl i systemet og sad derfor fast i opgaven. Testlederen hjalp testpersonen med at lokalisere bogen for at kunne udføre næste delopgave. Her blev testpersonen bedt om, at undersøge om bogen er ledig. Testpersonen prøver at dobbeltklikke på materialet i håb om, at en menu med f- lere information kommer op. Under denne proces overser testpersonen statusfarverne i hovedvinduet ud for materialet, som angiver om materialet er udlånt eller ej. Testpersonen havde altså ikke behøvet at finde frem til More information -vinduet for at se materialets status. Testpersonen gik lidt i stå, idet systemet ikke reagerede på testpersonens dobbeltklikforsøg, som denne prøvede i håb om at finde flere informationer om materialet. Først efter et hint fra testlederen fandt testpersonen på at højreklikke på materialet for at finde frem til menuen med flere informationer. Her forstod testpersonen ikke, hvad notationen Free betød (systemets notation for at et materialet er ledigt). Testopgave 1 identificerede de 3 første problemer i problemlisten. Vi vurderer problemerne i testopgaven som kritiske, 106

112 PROBLEMLISTE idet testpersonen uden hjælp fra testlederen ikke ville have været i- stand til at gennemføre en søgning på materialet og derfor ikke være i stand til at løse de resterende delopgaver. 2. I testopgave 2 får testpersonens til opgave at finde en bog i systemet, låne denne og vha. låner menuen verificere, at bogen efterfølgende er blevet lånt. Efter at testlederen havde gjort opmærksom på søgefejlen, som opstod i testopgave 1, guidede testlederen testpersonen igennem søgningen således, at fejlen ikke ville opstå igen. Testpersonen finder frem til materialet og har ingen problemer med at udføre lånet. Testpersonen går herefter lidt i stå i forsøg på at finde frem til sin låner menu. Da denne finder menuen og verificerer at bogen er udlånt kommer testpersonen ved samme lejlighed til at aflevere materialet, hvorved han løste næste delopgave ved et tifælde. Vi kategoriserer dette problem som alvorligt, idet testpersonen brugte en del tid på at finde frem til låner menuen. 3. I testopgave 3 får testpersonen til opgave at reservere et materiale, verificere vha. lånermenuen, at materialet efterfølgende er reserveret og afreservere det igen. Testpersonen har ingen problemer med at reservere bogen, men er ikke istand til at lokalisere datoen for, h- vornår materialet kan afhentes. Under afreserveringsopgaven overser testpersonen afkrydsningsfelterne ud for materialet, som har til formål at afreservere materialet. Her går testpersonen periodisk i stå før denne lægger mærke til afkrydsningsfelterne. Vi vurderer dette problem som værende alvorligt idet testpersonen går periodisk i stå inden han finder afkrydsningsfelterne. 4. I testopgave 4 får testpersonen til opgave at sætte sig ind i bibliotekarens rolle og oprette en bog i systemet og efterfølgende verificere, at denne er oprettet. Testpersonen lægger mærke til note linket i systemet. Det var dog uheldigt, at dette ikke var rettet til engelsk. Testpersonen var derfor ikke istand til at læse noten om, hvorvidt Hent ISBN funktionen benyttes og undlod derfor også at benytte sig af denne funktion. Vi har karakteriseret dette problem som kosmetisk, idet problemet ikke direkte forhindrer testpersonen i at løse opgaven da det stadigvæk er muligt at indtaste ISBN nummeret manuelt. Der opstod ingen problemer i under testopgave 5 og 6, hvilket er derfor disse ikke indgår i listen ovenfor. Testpersonen gav efter testen udtryk for følgende ønsker til forbedring: 107

113 VURDERING Testpersonen synes, at der er for meget login arbejde i systemet. Det ville være ønskværdigt kun at skulle logge sig ind en gang, således, at en bruger først kan benytte systemet efter login Testpersonen gav udtryk for, at systemet gør for lidt brug af keyboardet. Testpersonen trykkede gentagne gange på enter, istedet for at klikke med musen. Testpersonen udtrykte forvirring over statusfarverne. Disse var å- benbart ikke indlysende og krævede en forklaring fra testlederen. Testpersonen gav udtryk for, at artikelspecifikation-vinduet (den højre del af vinduet til litteraturopretttelse) var forvirrende under testen og vil gerne have et lignende vindue, hvor nyoprettet litteratur dukker op som konfirmation på, at litteraturen rent faktisk er oprettet i systemet. Testpersonen gav udtryk for, at et personligt kodeord er ønskværdigt Testpersonen ønsker flere bekræftelser på at handlinger er udført Vurdering Dette afsnit vil beskrive de problemer, som er rettet fra usability testen samt de problemer, der ønskes rettet i tilfælde af en eventuel viderudvikling på vores system. Vi har valgt kun at implementere et af de brugbarhedsproblemer i testen. Dette begrundes med, at testen hovedsageligt blev udført for erfaringens skyld for dat1-medlemmerne i gruppen. Testen foregik på et meget sent tidspunkt i projektet, og da dette semesters primære formål ikke er usability test eller brugbarhed, men udvikling af programmel, har vi ikke haft den fornødne tid og de fornødne ressourcer til at prioritere usability testen på lige fod med andre dele i rapporten. Derfor har vi kun udført en usability test med én testperson. Der er dog bred enighed i gruppen om, at testen har biddraget med megen konstruktiv kritik, hvilket er derfor vi har inkluderet dens resultater som bilag. Vi har rettet brugbarhedsproblemet i forbindelse med søgningen. Brugen af backspace medførte at resultaterne af en søgning ikke blev opdateret. Når alle søgeord blev slettet og tastet ind på ny, f.eks. i tilfælde af stavefejl, blev resultaterne heller ikke opdateret. Dette har været et kritisk problem, idet det umuliggjorde korrekt søgning af litteratur, hvilket er grunden til, at vi har rettet dette ene brugbarhedsproblem. Vi har dog nogle forslag til rettelser i en eventuel videreudvikling: 108

114 VURDERING Det bør synliggøres, hvad statusfarverne på søgeresultaterne betyder. Dette kan gøres ved at implementere 3 små firkanter, indeholdende hver af de 3 statusfarver, hvor hver farves betydning noteres ved siden af. Således vil brugeren med det samme være opmærksom på, hvad statusfarverne repræsenterer og ikke være nødsaget til at huske de enkelte farvers betydning. Note-linket i opret-litteratur-vinduet, som beskriver brugen af hentning af bogoplysninger pr. ISBN-nummer, bør rettes og oversættes på engelsk, hvis dette skal være til nogen nytte I artikelspecifikations-vinduet skal sammenhængen med oprettelsen af en proceeding og tidsskrift. Desuden vil det være hensigtsmæssigt at implementere et lignende vindue, hvor nyoprettet litteratur bliver tilføjet. Dette vil virke som en bekræftelse på, at litteraturen reelt er oprettet i systemet. Låner- og bibliotekar-menuerne skal gøres mere tydelige så det undgås, at en bruger forveksler låner-menuen med bibliotekar-menuen. Dette kunne bl.a. gøres ved at øge skrifttypen på menuerne eller implementere menuerne som store ikoner. Datoen for afhentning af et reserveret materiale skal gøres mere tydeligt. Dette kunne implementeres i form af en bekræftelse, hvor brugeren, direkte efter at have reserveet et materiale, får besked, hvornår dette kan afhentes og et hint om, at denne også kan se datoen i sin låner menu. Afkrydsningsfelterne, som bruges til at afreservere litteratur blev overset. Disse kunne flyttes helt til venstre i en række, så de stemmer overens med læseretningen. Der kan implementeres et tooltip som gør brugeren opmærksom på afkrydsningsfelterne eller de kunne laves større og have en anden farve så disse fremgår tydeligere. Login funktionen skal udvides således, at denne også dækker quickaflevering og quick-lån, hvis en bruger er logget ind. I tilfælde af, at fremtidige usability test af systemet afslører, at flere brugere ønsker et personligt kodeord kan en sådan funktion være hensigtsmæssig at implementere. Testpersonen gav udtryk for, at systemet indeholdt for få bekræftelser. I overenstemmelse med vores generiske designbeslutninger i afsnit 7.2 har bekræftelser med vilje ikke været implementeret i særlig 109

115 VURDERING stort omfang. Hvis det viser sig, at flere testpersoner opfatter dette som et problem ville det være hensigtsmæssigt, at implementere konfirmationsbeskeder for de mest essentielle opgaver i systemet. Som det ses, har usability testen afsløret mange områder, som i systemet har brug for forbedringer. Vi har nu givet vores forslag til, hvorledes nogle af disse brugbarhedsproblemer kunne rettes og implementeres. Vi er opmærksomme på at denne ene test af systemet langt fra dækker alle svage områder, og yderligere test er påkrævet, hvis størsteparten af systemet brugbarhedsproblemer skal identificeres. Flere tests ville eksempelvis kunne afsløre om nogle af de fundne brugbarhedsproblemer er engangstilfælde eller om disse er generelle for majoriteten af brugere. Der er dog bred enighed i gruppen om, at testen generelt er forløbet med succes og har givet megen konstruktiv information, som vil være nyttig til fremtidig finpudsning og videre udvikling af systemet. 110

116 Kapitel 11 Videre arbejde I dette afsnit vil vi diskutere og beskrive vores planer for, hvilke dele af programmet, som behøver videreudvikling/omorganisering, hvis arbejdet skal fortsætte i fremtiden. De emner, vi behandler i dette afsnit, er fremkommet dels af vores egne diskussioner i gruppen efter implementationen, dels af Håndtering af reservation Systemets muligheder for reservation er ikke implementeret som vi kunne have ønsket det. Som det er nu er der ingen feature der sikrer at en låner er den første der modtager et stykke litteratur han/hun har reserveret, da litteraturen ikke bliver dedikeret til den der har reserveret det i det øjeblik det afleveres. Desuden skal en låner selv afreservere litteraturen før den kan lånes. Dette er naturligvis noget, der bør ændres under en videreudvikling af programmet, men på nuværende tidspunkt vurderes det ikke som en graverende fejl af gruppen. Det vurderes, at en midlertidig behandling af problemet kan være at gøre en låner opmærksom på, hvorledes en reservation lånes gennem tooltips eller lignende. En anden svaghed i reservationsaspektet af vores system, er, at et stykke litteratur kun kan være reserveret af en enkelt låner ad gangen. Dette medfører, at en låner jævnligt skal se efter, om et stykke litteratur er tilgængeligt til reservervation. En bedre implementation ville være, at en låner i stedet kunne skrive sig på en liste, som holder styr på rækkefølgen af reservationer. Vi mener ikke dette er en kritisk fejl, men det er dog et emne, der kan udarbejdes en løsning til ved videreudvikling af programmet. Lån af artikler I det tilfælde af at en artikel, indeholdt i en proceeding eller et tidsskrift, lånes bliver pågældende proceeding eller tidsskrift samt 111

117 KAPITEL 11. VIDERE ARBEJDE eventuelle andre indeholdt artikler ikke automatisk lånt. Det er en seriøs mangel i funktionaliteten, men vi mener ikke at en løsning på dette er kompliceret at implementere. Login-håndtering Systemets håndtering af login er ikke optimalt, idet en bibliotekar, selvom han både er låner og bilbiotekar i systemet, skal logge ind som låner selvom han allerede er logget ind som bibliotekar. Dette problem kunne omgås med et check i vores login-håndtering, der registrerer, om en bibliotekar allerede er logget ind og umiddelbart gør bibliotekaren i stand til at udføre handlinger som en låner i bibliotekarens eget brugernavn. Det ville reducere antallet af gange en bibliotekar bliver bedt om at indtaste sit brugernavn betragteligt. Ekstern klient Som tidligere nævnt har vi ikke valgt at implementere en ekstern klient; delvist på grund af tidspres og delvist fordi et sådant arbejde ligger langt ud over den viden vi har stiftet bekendtskab med i dette projekt. Alene de overvejelser, der ville ligge til grund for implementering af en sådan, ligger et stykke over det forventede niveau på dette semester. Gruppen har naturligvis gjort sig tanker omkring implementationen af en sådan klient og kommet frem til, at der eventuelt kunne tages udgangspunkt i den eksisterende kildekode til udfærdigelse af klienten. Bibliotekarfunktionerne og udlånsmulighederne skulle fjernes og det resterende produkt indpakket installeringsmekanisme, som kun skulle kunne hentes via en intern hjemmeside og kun ville være tilgængelig for personerne tilknyttet MI-biblioteket. Alternativt kunne man udfærdige en minimalistisk http-server, som kunne tage imod input fra internetbrowsere og generere output ud fra hvilke rettigheder, brugerne har; det igen kunne afgøres ud fra om de var lokaliseret på cs.aau.dk-domænet eller ikke. Denne server ville køre eksempelvis en ASP- eller PHP-baseret hjemmeside, hvor brugerne kunne udføre søgninger og foretage reservationer. En sådan løsning ville muligvis fjerne en del komplikationer omkring systemkompabilitet i modsætning til vores nuværende system, som må anses for værende ret bundet til en bestemt platform. Til gengæld vil den medføre et væsentligt større arbejde, da udfærdigelsen af klienten skrevet i et komplet andet sprog, i modsætning til den førnævnte løsning, effektivt betyder, der ikke er kode at bygge videre på, men skal skrives fra bunden. Backup og fortrydelse Et aspekt der slet berøres indtil videre, er muligheden for backup i tilfælde af fejl i enten systemet eller dets umiddelbare 112

118 KAPITEL 11. VIDERE ARBEJDE omgivelser, som kunne resultere i tabt data. For at systemet skulle kunne retfærdiggøre sig selv på længere sigt end bare et studieprojekt som dette, regner vi i gruppen det som en kritisk funktionalitet, at systemet indeholder en mekanisme til sikring af data på en jævnlig basis. En fortrydelsesmekanisme, som sætter systemet i stand til at gendanne data hvis eksempelvis en låner slettes utilsigtet, ville efter gruppens vurderinger ligeledes tilføre systemet god funktionalitet til gavn for bibliotekarerne. Statistik Statistikken i dens nuværende form er implementeret uden en større indsigt i, hvad en sådan reelt skal indeholde for at tilføre brugere med nyttig information om systemet generelt. Et alternativ ville være at systemet kunne udarbejde statistik over hvilken litteratur, der oftest udlånes og hvilken litteratur, hvor BibTeX-entryen oftest bliver læst. Med udgang i en sådan viden kunne eksempelvis indkøb af ekstra kopier af et stykke eftertragtet litteratur refærdiggøres over for de regnskabsansvarlige. Bayesianske netværk I forbindelse med søgetekstfeltet på forsiden af systemet, har vi haft flere overvejelser. På nuværende tidspunkt hentes al litteratur ind fra databasen på én gang, hvilket ikke har fremprovokeret problemer indtil videre, da vi kun har skrevet en stykker litteratur i databasen. Med andre ord, vi har aldrig undersøgt, hvorledes kommunikationen mellem databasen og systemet skalerer ved store mængder litteratur. En konkret overvejelse har gået på at omskrive tekstfeltet, således at der kun søges på databasen ved retur-tast eller knapsøgning, og via bayesianske netværk oplære systemet i at fange typiske tastefejl fra brugernes side. En sådan implementation ville gøre systemet og afrapporteringen af dets implementation til et oplagt emne i biblioteket og en fuldendt selvreference ville således være opfyldt. Modtagelse af ændringsforslag Det primære fokus er her på litteraturdetaljerne, som indtastes manuelt og derfor er udsat for den menneskelige faktor. Hvis eksempelvis en låner af et stykke litteratur finder ud af, at BibTeX-entrien for litteraturen ikke stemmer overens med bogens faktiske detaljer, har han ikke andre muligheder end at henvende sig til bibliotekaren for at få det rettet. Enten skal brugeren skrive en til bibliotekaren eller direkte henvende sig til ham i biblioteket eller på kontoret. Hvis der derimod var indbygget en funktionalitet i systemet, der enkelt og let satte 113

119 KAPITEL 11. VIDERE ARBEJDE en bruger i stand til at komme med forslag til bibliotekaren via eller eventuelt via Instant Messaging-teknologier, ville det være langt mere dynamisk og problemfrit for låneren at komme med forslag. Søgning i Vis Litteratur I forbindelse med Vis Litteratur vinduet vil det være hensigtsmæssigt at implementere en søgefunktion med lignende funktionalitet, som den der er implementeret i systemets Main vindue. Vinduet Vis Litteratur består i øjeblikket af en række tab s, en for hver litteraturtype i systemet samt en tab, som giver en oversigt over al litteratur i systemet. Dette betyder, at al litteratur skal hentes ind i disse lister når dette vindue åbnes, hvilket reducerer hastigheden, hvormed vinduet åbnes. Bibliotekaren er ligledes nødsaget til at rulle i disse lister (som med tiden kan blive meget uoverskuelige pga. antallet af materialer i biblioteket) fremfor at kunne benytte sig af en søgefunktion til at søge blandt disse. En fremtidig implementation af en søgefunktion vil derfor både øge hastigheden, hvormed vinduet åbnes samt skabe et bedre overblik over systemets samlede litteratur for bibliotekaren. 114

120 Kapitel 12 Proces 12.1 Indledning Dette afsnit har til formål at beskrive projektets udviklingsproces. Processen lægger vægt på de delaktiviteter i projektet som har gennemgået væsentlige iterationer, og beskriver hvordan disse iterationer har påvirket delaktiviteten, samt hvad grundlaget har været for iterationen. I projektets indledende fase blev vi præsenteret for vandfaldsmodellen som en mulig udviklingsmodel for projektet. Denne model blev forsøgt fulgt igennem projektetet, men vi har måtte erkende, at det ikke er muligt at udvikle et system efter vandfaldsmodellen uden at gennemgå en række iterationer i de forskellige faser. Den reelle udviklingsmodel vi har brugt er derfor baseret på vandfaldsmodellen, dog med mulighed for at iterere tilbage til tidligere trin i udviklingen. Den faktiske proces i analyse, design og implementationsfasen samt gruppens overvejelser, erkendelser og resulterende ændringer i forbindelse hermed, vil blive præsenteret og trinvis gennemgået i dette afsnit Udviklingsmodel Som antydet i indledningen, blev vi præsenteret for vandfaldsmodellen i SAD-kurset som mulig udviklingsmodel. Den klassiske vandfaldsmodel er en udviklingsmodel, hvor hvert trin i et udviklingsforløb afsluttes inden det næste påbegyndes. Den klassiske vandfaldsmodel ses illustreret nedenfor på figur

121 UDVIKLINGSMODEL Kravspecifikation Design Implementation Afprøvning Vedligeholdelse Figur 12.1: Den klassiske vandfaldsmodel Som det ses på figuren indeholder modellen 5 trin, som skal gennemgås i en udviklingsproces. Kravspecifikationen svarer i modellen svarer til analysen i projektet. Alle de analytiske aspekter i projektet, såsom analysen af problem- og anvendelsesområdet, klassediagrammet, funktionslisten m.m. danner tilsammen kravspecifikationen. Kravspecifikationen skal være færdiggjort inden næste trin, design, kan påbegyndes. Dette betyder, at når design fasen påbegyndes, er det ikke muligt at iterere tilbage til kravspecifikationen og foretage ændringer baseret på viden, der opnås i design fasen. Gruppen blev hurtigt opmærksomme på, at det var nødvendigt at foretage ændringer i analysedelen, hvis en balance mellem analysen og design skulle opretholdes. Derfor var det et problem for gruppen at følge vandfaldsmodellen som den var tænkt, og vi skiftede derfor over til tilpasset ses afbildet nedenfor på figur Den tilpasset vandfaldsmodel minder meget om den klassiske vandfaldsmodel. Den tillader dog udviklerne, at foretage ændringer i f.eks. designet ud fra senere opnået viden i designet. 116

122 UDVIKLINGSMODEL Kravspecifikation Design Implementation Afprøvning Vedligeholdelse Figur 12.2: Den tilpassede vandfaldsmodel Et procesdiagram over vores udviklingsproces kan ses nedenfor på figur Procesdiagrammet viser den overordnede proces for vores analyse, design, implementation og test. De sorte, vandrette søjler ude for analyse, design, implementation og testrækkerne angiver, hvornår en udviklingsfase er påbegyndt og hvor lang tid denne har varet. De dobbelte pile angiver en periode med re-iteration af forudgående arbejde, dog skal det bemærkes at disse perioder også har inkluderet produktionsperioder, hvor nyt materiale er udarbejdet. Det skal bemærkes at procesdiagrammet ikke er en præcis tidangivelse, men blot et skøn over hvor lang tid hver periode har taget. 117

123 PRODUKTRAPPPORTEN Iterationsfase Analyse Design: Implementering Test Review 1 Review 2 Aflevering Figur 12.3: Projektets procesdiagram 12.3 Produktrappporten Som et krav til projektet skulle der udarbejdes en produktrapport med dokumentation til det udviklede software, og dokumentere processen fra identificereing af problemerne der skulle løses under projektet, til løsning af disse gennem et software design. Der har således skullet laves en masse forberedende arbejde, før selve programmeringen af produktet har kunne kommet i gang i kraft af den udviklingmetode, som vi havde valgt at arbejde ud fra. Denne rapport skulle indholde et analyse dokument samt et designdokument, begge udarbejdet i henhold til standarder præsenteret under SAD undervisningen. I løbet af projektperioden har der to gange været mulighed for at få disse dokumenter reviewet af en ekstern reviewer, således vores arbejde kunne vurderes uafhængigt af vejleder og egen vurdering. Disse reviews har lagt grund for gennemgående iterationer i det endelige produkt, idet der ofte blev fundet ny information om et givent aspekt i analysen eller designet, da begge blev set i et andet perspektiv af revieweren Analysen Det første trin i analysen var at indsamle viden om projektets problemområde. Vi lagde ud med udspørge vores vejleder om hvorledes det n- uværende system fungerede, idet han er fungerende bibliotekar hos MIgruppens bibliotek, hvorefter vi besøgte selve biblioteket for at få en for- 118

124 PRODUKTRAPPPORTEN ståelse af problemområdet. Det næste trin var en fælles brainstorm blandt gruppens medlemmer, hvor vi skrev vores fælles opfattelse af de fokusområder, der indgår i et bibliotek op på en tavle. Den viden vi fik ud af besøget samt den fælles brainstorm blev brugt til at identificere konflikter i problemområdet. Det næste trin var at analysere anvendelsesområdet ud fra problemområdet, hvilket førte til udarbejdelsen af vores første klassediagram, de første brugsmønstre i systemet, en samlet funktionsliste, og en begrebsmæssig model passende til systemets tiltænkte brug. Efter at have arbejdet med analysen i en omtrent 14 dage, tog vi ud og interviewede et par brugere af det nuværende MI-bibliotek. De blev præsenteret for den udarbejdede systemdefinition og spurgt om diverse funktionaliteter de forventede et stykke software til adminstration af biblioteket skulle have, for at de ville betragte det som et nyttigt værktøj. Disse interviews lagde bund for nogle overvejelser omkring vores systems design og implementaion. Interview spørgsmålene samt svar på disse, kan findes i appendix A.2. Efter den første måndes tid i projektperioden, blev vi tilbudt at få vores analyse til review af en ekstern reviwer, for at få et andet perspektiv på vores dokumentation. Overordnet var vores analyse dokument i orden i henhold til hvad der kunne forventes i forhold til standarden for dette semester, men der var en del ænringer som skulle foretages i detaljer som vi enten havde misforstået eller som ikke var helt gennemarbejdet i forhold til metoderne præsenteret i [Mathiassen et al., 2001]. Blandt andet var vores klassediagram ikke helt korrekt udarbejdet og vores funktionsliste var mangelfuld, hvilket betød at vi måtte iterere tilbage over analysen og rette i dokumentet, inden vi kunne begynde at udarbejde designdokumentet. Generelt set var det på dette stadie at de første iterationer begyndte, idet der skulle rettes en del igennem før vi kunne gå videre med projektet Design Designfasen har muligvis været den fase i projektet, som forårsagede de væsentligste iterationer i analysen. Det kan ses på procesdiagrammet, at vi meget tidligt i designfasen blev nødt til at iterere tilbage til analysen, eksempelvis kan klasserne fundet i analysen nævnes som en af de delaktiviteter, der krævede en større revidering. Klasserne fundet i analysen var ikke tilstrækkeligt gennemtænkte eller veldefinerede og det var ikke muligt, at designe klasserne ud fra analysen således, at de dækkede ansvaret for systemets samlede funktionalitet. En større del af klasserne i analysen var defineret således, at de ikke pådrog sig at stå for et enkelt 119

125 PRODUKTRAPPPORTEN eller sammenhørende ansvar i systemet. Vi ville derfor opnå høj kobling og lav samhørighed, hvis vi skulle designe klasserne, som de var defineret i analysen. Høj kobling og lav samhørighed var netop, hvad vi ønskede at undgå, og derfor blev vi nødsaget til både at skabe nye klasser og ændre på de eksisterende, således at disse kunne udspecificeres og gøres realiserbare i designfasen. Derved kunne vi som ønsket opnå høj samhørighed og lav kobling i systemet. Funktionslisten i analysen blev vi også nødt til at iterere tilbage på, for at realisere vores design. Funktionerne i analysen dækkede ikke ansvaret for de samlede opgaver, som systemet blev designet til at håndtere. Vi blev derfor nødt til at tilføje, omdøbe og fjerne funktioner i analysens funktionsliste for at skabe balance mellem disse og de angivne funktioner i det senere designklassediagram. Som under analysefasen, blev der også her tilbudt at få vores design til review. Under dette review modtog vi input fra den samme eksterne kilde, som reviede vores analyse dokument, og overordnet vurderedes vores design som værende i overensstemmelse med standarden. Der blev her foreslået en række ændringer, idet der var uklarhed om blandt andet vores komponentarkitektur og designklassediagram, hvilket betød vi måtte foretage en større re-iteration for at få ændringerne på plads. Denne iteration blev dog udskudt efter reviewet, idet der var mere presserende emner inden for implementationen der skulle undersøges Vurdering Overordnet har vores proces båret præg af, at vi har måttet iterere igennem produktrapporten mange gange for at komme frem til en rapport, som afspejler det endelige produkt. Det har betydet at der er brugt meget tid på dobbeltarbejde, idet mange afsnit og overvejelser har været til revurdering undervejs, hvilket har betydet at man mange gange har skullet diskutere de samme emner. Dette har medført at der en gang imellem har været en slags iterationstræthed, hvor der ikke har været stemning for med det samme at tage en beslutning om et givent afsnit i rapporten. Det betød så, at når endelig tiden kom, hvor disse beslutninger ikke kunne udskydes længere, var en del information om hvorfor og hvordan de skulle ændres gået tabt, og der skulle således genovervejes hvordan man kunne få dem rettet i overensstemmelse med resten af rapporten. Som det ses på figur 12.3 på side 118 bar implementationsperioden præg af at være én stor iteration, idet man mange gange var nødt til at omskrive programmet pga. fejl og andre ting, der forårsagede at ændringer skulle foretages i programkoden. I nogle tilfælde har beslutninger taget under implemen- 120

126 PRODUKTRAPPPORTEN tationen også forårsaget at designet skulle revideres, idet nogle klasser er blevet overflødige pga. måden som data behandles og gemmes på i det endelige system. Generelt set har vi oplevet, at softwareudvikling i henhold til den tilpassede vandfaldsmodel kræver at man er villig til at re-iterere i- gennem hele projektet, men at den også giver en et mere solidt produkt, idet alle beslutninger bliver tilstrækkeligt gennemtænkt. Der er mange a- spekter i systemet som man principielt bare har kunne lade stå til istedet for at rette dem, men overordnet har de fleste af rettelserne betydet, at det har været lettere at gennemføre projektets senere stadier. 121

127 Kapitel 13 Konklusion I studierapporten har vi berettet om vores oplevelser med en usability test, vores forslag til videre arbejde på systemet, samt et tilbageblik på vores udviklingsproces. Usability testen har været med til at afdække flere usability problemer i vores system, som vi enten havde mistanke til kunne opstå, eller helt nye problemer som vi ikke vidste eksisterede. Når testresultaterne fra sådan en test evalueres, er det interessant at diskutere hvornår et problem skyldes at brugeren har svært ved at forstå systemet på grund af dets design, og hvornår problemet skyldes uvidende brugere, der f.eks. ikke er bekendt med at højreklik på en mus, også kan have en funktion. Da man selv skal udføre rettelser i systemet efter testen, kan man komme til at være ovenud kritisk overfor ens testbrugeres anvendelse af ens system; men på den anden side set bør man også være kritisk med hensyn til deres evner, når alvorligheden af fejlene skal vurderes. Udover at identificere usability problemer, har usability testen også tjent som en slags bugtest, hvor de essentielle funktioner i programmet er blevet afprøvet. Dette har medført, at op til flere uforudsete bugs i programmet blev fundet, således de kunne rettes til den endelige version. For eksempel opdagede vi en fejl i måden søgningen kaldes fra brugergrænsefladen. Som nævnt har vi ikke kunnet korrigere alle de fejl/usikkerheder som usability testen afdækkede. Disse er derfor kommet i afsnittet omkring videre arbejde, sammen med features vi har valgt at undlade at implementere. Vi har, på trods af en ellers god arbejdsindsats, ikke nået at implementere alle de ting i systemet, som vi gerne ville. For eksempel havde vi planer om at implementere mulighed for at kunne søge i litteraturdatabasen via. en ekstern klient, men idet vi til stadighed har været under oplæring i C#-sproget, kunne vi ikke afsætte tid til dette samtidigt med at vi skulle implementere vigtigere funktionalitet i systemet. Det betyder at program- 122

128 KAPITEL 13. KONKLUSION met ved aflevering ikke er som vi egentligt først havde tænkt os det. Vores design også har lidt en række knæk under implementationen, idet nogle ting i implementationen egentligt ikke blev analyseret før de blev tilføjet til systemet. I sammenhæng med SAD-kurset læste vi artiklen "A Rational Process: How and Why to Fake It?"af Parnas og Clements (vedlagt på CDrom). Artiklen argumenterer for at det ikke er muligt at udvikle software gennem en rationel proces, da vi kun er mennesker og at det vil være umuligt ikke at skulle tilbage og korrigere noget i det tidligere arbejde. Artiklen argumenterer herefter for hvorfor det alligevel kan være fornuftigt at fake en sådan proces. Dette gøres bla. fordi man så kan sammenligne sin proces med den perfekte proces og vurdere hvor man står i processen. Vi har i løbet af programmets udvikling forsøgt at fake vores udviklingsproces, men med mindre succes idet ikke alle ændringer foretaget under implementationsfasen er blevet tilføjet tilbage i produktdokumentationen. Det har betydet at koblingen mellem analysen, designet og implementationen ikke er så stærk som vi kunne have ønsket det. 123

129 Bilag A Appendix På de følgende sider ses rapportens bilag. 124

130 Tabel A.1: Faktor-tabel Faktor MKS Flex. Virk. Pri. R/S Persistens Alt, der bør gemmes, skal gemmes. Må ej belaste systemet. H Fjernadgang Intern søgning skal være tilstrækkelig tidseffektiv Må ej belaste systemet. Der kan foretages opslag i systemet inden for rimelig tid (0-5 sekunder). Reservation via fjernadgang foregår på lige fod med lånere i biblioteket. Først-tilmølle-princippet. En intern søgning skal i alle tilfælde tage maks. 1 sekund på maskinen i biblioteket. Gælder for alle dele af systemet, hvor persistens er en god idé. E- ventuelt bruges en database ved endelig implementation. Gælder for alle klienter, som tilgår systemet udefra. Gælder for den lokale pc. Persistenslaget skal være indkapslet så nemt, at det er nemt at skifte til database senere. Indtil videre kan fjernadgang foretages med en tyk klient i den endelige implementation. Bruges i en browser. Fremtidige udgaver kan eventuelt gemme de enkelte brugeres søgninger L H H, da ingen af os har erfaring med dette i C#. MH. Da ingen af os har erfaring med dette i C#. M A.1 Faktortabel

131 Tabel A.2: Faktor-tabel Faktor MKS Flex. Virk. Pri. R/S Bøger skal kunne tilføjes via. ISBNeller ISSN-numre Systemet skal være let at bruge både for hverdagsbrugere, såvel som for dem der sjældent bruger det Systemet skal kunne foretage opslag på eksterne ISBNeller ISSN-servere for at nedhente den nødvendige information. Vi er dog ikke klar over, om der findes nogen central database over bøger Det skal være let og fri fra større tekniske vanskeligheder at kunne benytte både den lokale klient og selve bibliotekssystemet. Det må ikke tage flere minutter at lede efter en given bog for derefter at låne den, uanset teknisk kendskab hos den enkelte. Brugere må helst ikke på noget tidspunkt gå i stå eller befinde sig i en situation, hvor det næste skridt er uklart. Gælder kun for den del af systemet, som skal foretage tilføjelser af ny litteratur Gælder for hele systemet, inklusiv for bibliotekaren Bør eventuelt først implementeres efter at de centrale dele af systemet er implementeret Bør implementeres snarligt for afklaring af h- vorledes systemet gøres bedst muligt brugervenligt. L H. Da vi ingen kendskab har hertil. H H, da vi stadig undervises på dette område, er brugergrænsefladen endnu ikke fastlagt.

132 INTERVIEW MED BRUGER A.2 Interview med bruger Vi vil i dette afsnit beskrive vores interviews med forskellige bruger fra MI-gruppen. Vi vil blandt andet opstille spørgsmålene til bruger og beskrive disse, samt vise brugernes svar til disse. Vi har valgt at bruge tre personer fra MI-gruppen til interviews. A.2.1 Spørgsmål 1. Hvad er dit navn og din alder? 2. Hvilke personlige interesser (hobbyer) har du? 3. Hvad er dit mål med din(e) hobby(er)? 4. Hvad er dit mål efter universitetstiden? 5. Hvordan vil du beskrive dit kendskab til computere? Har du brugt andre styresystemer og har du brugt internettet? 6. Hvor ofte bruger du biblioteket? 7. Hvad mener du om det nuværende bibliotekssystem? 8. Mener du der er nogle fejl eller mangler i systemet? 9. Har du noget kritik til den fremsendte systemdefinition? 10. Kan du se nogle mangler i den fremsendte systemdefinition? 11. Synes du om idéen at bruge en computer til udlån af bøgerne i biblioteket? 12. Ville du være villig til at deltage i en test af vores systemprototype? Vi vil nu beskrive spørgsmålene. Vi vil blandt andet beskrive hvad vi regner med at få ud af spørgsmålene men også hvad spørgsmålene skal bruges til. Spørgsmål 1-6 Disse spørgsmål stilles med henblik på at udbygge en persona til brug i brugsmønstre m.m. og afdække generel information om de interviewede. Spørgsmålene tager udgangspunkt i og er fortolkede ud fra slides fra DIEB. 127

133 INTERVIEW MED BRUGER 7. Hvad mener du om det nuværende bibliotekssystem? Vi forventer at få den enkelte brugers mening omkring det nuværende bibliotekssystem. 8. Mener du der er nogle fejl eller mangler i systemet? Vi forventer, ud fra dette ledende spørgsmål, at få udspecificeret, hvilket fejl og mangler der findes i systemet, således at vi kan undgå disse fejl og mangler i vores system. 9. Har du noget kritik til den fremsendte systemdefinition? Vi har inden interviewet med brugerne fremsendt vores systemdefinition og forventer både positiv og negativ kritik på denne. 10. Kan du se nogle mangler i den fremsendte systemdefinition? Dette spørgsmål er lavet for at frem provokere en mere detaljeret kritik af vores systemdefinition. Ydermere vil dette også være med til at vi bedre kommer til at forstå problemområdet. 11. Synes du om idéen at bruge en computer til udlån af bøgerne i biblioteket? Dette spørgsmål er fremkommet i den kontekst at afdække, om de kommende brugere reelt vil have en interesse i at benytte en computer. Hvis det viser sig at de kommende brugere ikke tager godt imod vores kommende system, må vi overveje alternative løsninger. 12. Ville du være villig til at deltage i en test af vores systemprototype? Det sidste spørgsmål afdækker blot om de interviewede ville være villige til at teste systemet. A.2.2 Interview nr. 1 Interviewet blev foretaget kl d. 27/ Svarene til de forskellige spørgsmål vil stå udenfor det pågældende nummer. 1. Hans navn er Yifeng Zeng og han er 30 år gammel. 2. Hans hobbies er bordtennis, badminton og tennis. 3. Mål til disse hobbies har han ikke så mange af. Han har allerede været mester i bordtennis ved MI-gruppen, så at blive det igen kunne være et mål. På dette tidspunkt var det en anden der havde titlen. 128

134 INTERVIEW MED BRUGER 4. Han er adjunkt (assistant professor) og vil muligvis blive der resten af sin arbejds tid. 5. Han synes selv at han har et godt kendskab. Han mener at systemet ikke skal være over kompleks eller være en enkel kommandoprompt. 6. Han bruger biblioteket ofte for at tjekke en proceeding eller anden litteratur. 7. Han har svært ved se hvor han skal skrive for at låne en bog og synes at det er noget komplekst. 8. Dette spørgsmål er dækket fra det forrige svar. 9. Han havde en masse spørgsmål til systemdefinitionen, men ingen ændringsforslag. 10. Det forrige svar dækker dette spørgsmål. 11. Han mener at det er en god ide med at bruge en computer til at låne bøger og anden litteratur. 12. Han ville gerne være med til en test af vores prototype. A.2.3 interview nr. 2 Interviewet blev foretaget kl d. 27/ Hans navn er Jens Dalgård Nielsen og han er 29 år gammel. 2. I fritiden før han fik så travlt som han har det nu, dyrkede han sport som løb, badminton og svømning. 3. Da det er sportshobbyer han har for at få motion er der ikke noget decideret mål. 4. Hans mål efter han er færdig på universitet, vil han helst ind i et privat firma hvor han kan have stor frihed og kan få en god økonomi. Det skulle være indenfor området datafinding og machinelogging, der går ud på at bygge programmer som automatisk kan finde mønstre i store mængder data, men også kan lave matematisk modeller til at beskrive data. 129

135 INTERVIEW MED BRUGER 5. Han mener selv at hans kendskab er bedre end gennemsnittet. Han bruger mellem timer om ugen på nettet. Efter hans mening skal det helst være en GUI der er nem og hurtig at bruge og at der ikke skal være spørgsmål der vil virke forvirrende. 6. Han bruger biblioteket næsten dagligt. 7. Han er den der i sin tid fandt på systemet og mente at det var en god løsning, men har skiftet mening. 8. Han mener at når man skal finde bogen i listen kan det være lidt irriterende. Han ved dog normalt hvor bogen står. 9. Han havde ingen kritik til systemdefinitionen, hvilken han mente var okay. Synes at det var godt at man kan søge på en bog i sit eget rum, og hvis den så var udlånt at man skal kunne se hvem der har bogen. 10. Det forrige svar dækker dette spørgsmål. 11. Han syntes det var en god ide at bruge en computer til at låne bøger med. 12. Han ville gerne være med, hvis vi i gruppen ville skrive om hvor lang tid det ville tage, da han ikke har tid når som helst. A.2.4 interview nr. 3 Interviewet blev foretaget kl d. 27/ Hans navn er Finn Verner Jensen, og han er 61 år. 2. Han laver amatørteater, kører en biograf og spiller golf i sin fritid. 3. Han har ingen deciderede mål med sine hobbies, andet end at bruge sin fritid. 4. Da han er ansat på universitet og på grund af sin alder, regner han med at han bliver indtil han skal pensioneres. 5. Han er en typisk Microsoft-produkt-bruger, dvs. udelukkende GUI (muligvis WIMP) og har ikke prøvet Linux. 6. Han bruger biblioteket jævnligt, dvs. 3-4 gange om ugen. 130

136 PROOF OF CONCEPT AF BRUGSMØNSTRE 7. Han mener at der er ikke mange bøger, så umiddelbart er det nuværende system ikke komplet ubrugeligt. Der er dog problemer med om bøgerne er hjemme. Det er svært at finde bøgerne (også pga. det faktum, at brugerne ikke sætter dem på plads). Hvis der dog kommer betragtelig flere bøger mener han, at det helt sikkert bliver nødvendigt med et nyt system. 8. Det forrige svar dækker også for dette spørgsmål. 9. Han synes som udgangspunkt at systemdefinitionen er ok, men der mangler noget om Nicolajs job. 10. Dette spørgsmål er dækket af det forrige svar. 11. Han synes at ideen med computeren er en god ting. Selvom der kom en søgefunktion fra arbejdsstationer, ville han ikke bruge den, da biblioteket ligger tæt på hans kontor. Desuden foretrækker han at gå derover af den grund, at han tit finder andre bøger end den han kom efter, som han synes er interessante og efterfølgende låner. Han mener desuden, at alle, via det nye system, bør kunne se, hvem der har en pågældende bog til enhver tid, hvis den er udlånt. 12. Han vil gerne være med, men vil kun afsætte en halv til en hel time og ikke en hel dag til testen. A.3 Proof of concept af brugsmønstre Vi vil i dette afsnit kommentere dele af vores kode for implementationen af brugsmønsteret for oprettelse af lånere. Formålet er at dokumentere, at koden er blevet skrevet skrevet efter designet. Så snart der klikkes på knappen Opret låner oprettes en instans bibbi af klassen BibController. Efter at have indtastet diverse oplysninger om den kommende låner trykker bibliotekaren Opret låner. 25 private void button1_click ( object sender, EventArgs e ) { 26 c o n t r o l l e r I O io = new c o n t r o l l e r I O ( ) ; 27 s t r i n g fn = fornavntext. Text ; 28 s t r i n g en = efternavntext. Text ; 29 s t r i n g lo = l o k a l e T e x t. Text ; 30 s t r i n g m = mailtext. Text ;

137 PROOF OF CONCEPT AF BRUGSMØNSTRE Figur A.1: Skærmbillede af Opret låner-vinduet 32 Laaner a=null ; 33 t r y 34 { 35 a = b i b b i. OpretLaaner ( fn, en, lo, m) ; 36 io. GemTilDisk ( a ) ; 37 } 38 catch ( BibException exce ) 39 { 40 MessageBox. Show ( exce. ToString ( ) ) ; 41 } 42 t h i s. Close ( ) ; 43 } En BibException bliver smidt i OpretLaaner i BibController, hvis nogle af inputstrengene til OpretLaaner er tomme. Den bliver fanget og en fejlmeddelse udskrives til skærmen. Funktionen GemTilDisk i ControllerIO henter den foreløbige lånerliste ind, tilføjer den nye låner og gemmer lånerlisten igen. 522 public void GemTilDisk ( Laaner laaner ) { 523 _ i n t e r n I O l i s t e = HentFraDisk ( ) ; 524 _ i n t e r n I O l i s t e.add( laaner ) ; 525 FileStream s = null ; 526 t r y { 527 s = new FileStream ( " l a a n l i s t e f i l. bin ", FileMode. Create ) ; 528 } catch ( ArgumentException ) { 529 Console. WriteLine ( " Argument E xce p ti on i n 132

138 PROOF OF CONCEPT AF BRUGSMØNSTRE GemTilDisk ( ) " ) ; 530 } catch ( IOException ) { 531 Console. WriteLine ( " IOException i n GemTilDisk " ) ; 532 } 533 System. Runtime. S e r i a l i z a t i o n. IFormatter f = new System. Runtime. S e r i a l i z a t i o n. Formatters. Binary. BinaryFormatter ( ) ; 534 f. S e r i a l i z e ( s, _ i n t e r n I O l i s t e ) ; 535 s. Close ( ) ; 536 } _internliste er et offentlig objekt af typen ArrayList, som altid initialiseres på ny i de enkelte metoder. Listen bruges som midlertidigt lager af de lånere, der hentes og skrives til disken. Fejlmeddelelser bliver udskrevet til skærmen. I vores implementation af brugsmønstret har vi også muligheden for at se lånere. Dette gøres vha. funktionen HentFraDisk, der læser lånerlisten ind i en ArrayList, som vises i et DataGridView. Figur A.2: Skærmbillede af Vis lånere -vinduet Billede A.2 viser hvorledes VisLaanere er implementeret, følgende kodeuddrag viser hvorledes indlæsningen af lånere fra controllerio foregår. 23 private void s_load ( object sender, EventArgs e ) { 24 c o n t r o l l e r I O io = new c o n t r o l l e r I O ( ) ; 25 _ i n t e r n l i s t e = io. HentFraDisk ( ) ; 26 foreach ( Laaner laaner in _ i n t e r n l i s t e ) { 27 VisLaanereDataGridView. Rows.Add( laaner. Fname, laaner. Ename, laaner. Lokale, laaner. Mail ) ; 28 } 133

139 INTERAKTIONSELEMENTER 29 } _internliste er det midlertidige lager hvori lånerne fra controllerio gemmes, indtil de læses ind i VisLaanereDataGridView. Selve indlæsningen HentFraDisk er, som vist, implementeret på controllerio-klassen. 565 public ArrayList HentFraDisk ( ) { 566 FileStream s = null ; 567 t r y { 568 s = new FileStream ( " l a a n l i s t e f i l. bin ", FileMode. Open) ; 569 } catch ( ArgumentException ) { 570 Console. WriteLine ( " Argument E xce p ti on i n HentFraDisk ( ) " ) ; 571 } catch ( IOException ) { 572 Console. WriteLine ( " IOException i n HentFraDisk ( ) " ) ; 573 } 574 System. Runtime. S e r i a l i z a t i o n. IFormatter f = new System. Runtime. S e r i a l i z a t i o n. Formatters. Binary. BinaryFormatter ( ) ; 575 _ i n t e r n I O l i s t e = f. D e s e r i a l i z e ( s ) as ArrayList ; 576 s. Close ( ) ; 577 return _ i n t e r n I O l i s t e ; 578 } A.4 Interaktionselementer Dette afsnit var indeholdt i designdokumentet, som det så ud til 2. review. Afsnittet er nu i appendix, da det blev brugt som en hjælp under designet, men ikke længere er aktuelt. Her følger en kort forklaring af de indeholdte interaktionsrum i præsentationsmodellen af brugergrænsefladekomponenten. 134

140 INTERAKTIONSELEMENTER Figur A.3: Grafisk design af Hoved Vindue Hoved Vindue Dette er det første vindue, brugeren bliver mødt med ved brug af systemet, og ses på figur A.3. Vinduets interaktionsform består i en menu, som giver adgang til at navigere rundt i systemet, samt skemaudfyldelse idét Hoved Vindue aggregeres af andre interaktionselementer som følger. Menuen i hovedvinduet består af punkterne: Aflevér Litteratur, Se Personlig Info, Bibliotekar Login og Logout. Menupunktet Logout er kun aktivt, såfremt en bibliotekar eller en låner er logget ind i systemet. Output Input Actions Mainmenu Menuvalg Vælg Aflevér Litteratur Vælg Se Personlig Info Vælg Bibliotekar Login Vælg Logout Interaktionselementer som aggregeres i hovedvinduet er: Søgeresultat Browser: Denne giver en bruger mulighed for at søge i bibliotekets litteratur og præsenterer det på listeform efter endt søgning. Det er dernæst muligt at tilføje litteratur direkte til udlånsliste og/eller se litteraturdetaljer. aflevering View: Fra denne får brugeren mulighed for, uden for systemets søgerutine, hurtigt at aflevere et stykke litteratur. I dette interaktionselement skal et brugernavn og et litteraturid indtastes for at benytte funktionaliteten. 135

141 INTERAKTIONSELEMENTER Reservationsliste View: Her kan brugeren se sine reservationer på et givent tidspunkt. Via denne har brugeren mulighed for dels at fjerne litteratur fra reservationslisten og dels at acceptere denne listes indhold. Udlånsliste View: I denne får brugeren vist sit lånte litteratur. Fra denne er det muligt for en bruger at fjerne lån fra listen og acceptere denne listes indhold. Quicklån View: Dette interaktionselement består af to indtastningsfelter, hvor brugeren indtaster dels sit brugernavn og et litteraturid. Det er derved muligt at låne et stykke litteratur uden at skulle i- gennem systemets søgerutine. I tilfælde hvor en låner ved, hvilket litteratur, han behøver, og hurtigt skal videre, kan denne funktion benyttes med fordel, da det eneste, der skal gøres fra lånerens side, er fysisk at finde litteraturen i biblioteket og dernæst benytte denne funktion. Litteraturdetalje View Interaktionselementet navigeres til via Søgeresultat Browser, når brugeren vælger at få vist detaljer om litteratur fra Søgeresultat Browseren. Fra Litteraturdetalje View er det muligt at tilføje litteraturen direkte til brugerens reservationsliste eller brugerens låneliste. Interaktionsformen for Litteraturdetalje View er dialog. Output Input Actions LitteraturDetaljer Lån Litteratur Tilføj til Reservationsliste Tilføj til Låneliste Login View Dette interaktionselement tillader brugeren at identificere sig til for systemet med henblik på at få adgang til andre interaktionselementer i systemet, som kræver identifikation. Interaktionsformen for dette interaktionselement består i dialog. Output Input Actions LoginFelt BrugerID Login Personlig Info Dette interaktionselement indeholder personlig information knyttet til den enkelte bruger. Det være sig brugerens personlige låneliste, reservationsliste og praktiske, formelle oplysninger om brugeren. Interaktionsformen er en kombination af dialog og skemaudfyldelse. 136

142 INTERAKTIONSELEMENTER Output Input Actions LånerInfo LånerInfo Rediger Låner Vis Udlånsliste Vis Reserveringer Lån View Dette interaktionselement afspejler information om, hvilken litteratur brugeren, som er logget ind, har lånt på dette tidspunkt. Informationen vises i form af en liste. Her er det muligt at aflevere litteratur repræsenteret på listen eller få vist detaljeret information om lånet i et andet interaktionselement dækket af Lånedetalje View. Interaktionsformen for Lån View er dialog. Output Input Actions Lånliste Lån Vælg Lån Aflever Lån Låndetalje View I dette interaktionselement er det muligt for en bruger at se detaljer om et lån. Lånet kan ligeledes afleveres. Interaktionsformen er dialog. Output Input Actions LånDetaljer Aflevér Lån Bekræft Aflevering View Her er det muligt for en bruger at bekræfte aflevering af litteratur. Skulle brugeren ved en simpel fejltagelse have kommet til at udføre en handlig, der resulterer i aflevering af et stykke litteratur, kan fejltagelsen afværges, idét handlingen først skal bekræftes i dette interaktionselement inden den rent faktisk udføres. Interaktionsformen er dialog. Output Input Actions AdvarselsBox Bekræft Aflevering Bekræft Aflevering Afbryd Aflevering Afbryd Aflevering Reservations View Her vises en liste over brugerens reservationer med muligheden for at markere litteratur på denne liste til nedlæggelse eller vise detaljer om den givne litteratur. Interaktionsformen er dialog. 137

143 INTERAKTIONSELEMENTER Output Input Actions Reservationsliste Reservation Vælg Reservation Nedlæg Reservation Reservations Detalje View I dette interaktionselement er det muligt at se detaljeret information om litteraturen, som er reserveret af brugeren. En anden handling udbudt af dette interaktionselement er at nedlægge reservationen. Interaktionsformen er dialog. Output Input Actions ReservationsDetaljer Nedlæg Reservation Bibliotekar View Dette interaktionselement fremkommer efter at have logget ind som bibliotekar, og indeholder et bredere udvalg af valgmuligheder til at administrere biblioteket. Output Input Actions BibliotekarMenu Bibliotekar Menuvalg Opret Låner Opret Bibliotekar Tilføj Litteratur Bibliotekar View aggregeres af Bibliotekar Søgeresultat Browser, analog til aggregeringen af Søgeresultat Browser til Hoved Vindue. Forskellen mellem de to søgeresultatbrowsere er, at browseren tilhørende bibliotekaren indeholder de ekstra søgemuligheder Søg Låner og Søg Bibliotekar. Det er ydermere muligt at vælge at få vist detaljer om markerede elementer i listen over søgte lånere eller søgte bibliotekarer respektivt via interaktionselementerne Bibliotekar Lånerdetalje View og Bibliotekar Bibliotekardetalje View. Siden Bibliotekar View er en udviddet tilstand af Hoved Vindue, er interaktionsformen ligeledes menu og skemaudfyldelse. Tilføj Litteratur View Her er det muligt for bibliotekaren at tilføje nyt litteratur til systemet ved at indtaste den respektive information. Interaktionsformen beror på skemaudfyldelse. Output Input Actions LitteraturInputFelt LitteraturDetaljer Tilføj Litteratur til Litteraturliste 138

144 INTERAKTIONSELEMENTER Opret Person View Her er det muligt for bibliotekaren at tilføje en ny person til systemet, det være sig en bibliotekar eller låner, ved at indtaste den respektive information. Interaktionsformen er her skemaudfyldelse. Output Input Actions PersonInputFelt Personinfo Tilføj Låner til Lånerliste Bibliotekarstatus Tilføj Bibliotekar til Lånerliste Bekræft Oprettelse View Oprettelsen af henholdsvis nytilkomne personer og ny litteratur i systemet skal bekræftes inden udførelse, hvilket skal ske via dette interaktionselement. Interaktionsformen må derfor være dialog. Output Input Actions Bekræft Oprettelse Bekræft Oprettelse Bekræft Oprettelse Annullér Oprettelse Annullér Oprettelse Annuller Oprettelse Bibliotekar Litteraturdetalje View Her listes detaljeret information om et givent stykke litteratur. Fra dette interaktionselement er det muligt at melde litteraturen bortkommen, melde litteraturen fundet, redigere de formelle litteraturdetaljer og slette det givne stykke litteratur. Interaktionsformen er derved skemaudfyldelse og dialog. Output Input Actions LitteraturDetaljer Redigér Litteratur Meld Litteratur Bortkommen Meld Litteratur Funden Redigér Litteratur Slet Litteratur Bibliotekar Lånerdetalje View I dette interaktionselement vises detaljeret information om en given låner i systemet. Via dette interaktionselement er det muligt at redigere lånerens oplysninger eller slette låneren fra systemet. Interaktionsformen forbundet med dette interaktionselement er således skemaudfyldelse. Output Input Actions LånerInfo LånerInfo Redigér Låner Slet Låner 139

145 INTERAKTIONSELEMENTER Slet Data Bekræftelses View Fjernelsen af en låner fra systemet, fjernelse af litteratur fra systemet eller fjernelse af en bibliotekar fra systemet er beskyttet mod utilsigtede handlinger gennem dette interaktionselement, som beder udstederen af slet-handlingen om en bekræftelse på handlingen. Interaktionsformen er dialog. Output Input Actions AdvarselsBox Bekræft Sletning Bekræft Sletning Afbryd Sletning Afbryd Sletning Bibliotekar Bibliotekardetalje View Her er listet formelle oplysninger om den valgte bibliotekar fra søgeresultatet. Det er fra dette interaktionselement muligt at redigere bibliotekarens oplysninger eller slette bibliotekaren fra systemet. Interaktionsformen består i skemaudfyldelse. Output Input Actions BibliotekarInfo BibliotekarInfo Redigér Bibliotekar Slet Bibliotekar 140

146 TESTPLAN PhDafhandling Proceeding Navn Datatype Navn Datatype titel varchar(45) titel varchar(45) forfatter varchar(45) editors varchar(45) aarstal integer aarstal integer sideantal integer sideantal integer keywords varchar(45) forlag varchar(45) resume varchar(45) keywords varchar(45) litteraturid varchar(45) resume varchar(45) antallaan integer litteraturid varchar(45) antalreservationer integer antallaan integer BibTeX longtext antalreservationer integer afleveringsdato varchar(20) BibTeX longtex IndeholdtI varchar(300) afleveringsdato varchar(20) laantaf varchar(45) IndeholdtI varchar(300) type varchar(45) laantaf varchar(45) reserveretaf varchar(45) type varchar(45) status int(1) reserveretaf varchar(45) status int(1) Tabel A.3: PhDafhandling og Proceedings opbygning A.5 MySQL-databasen Som tidligere forklaret har vi valgt at benytte en MySQLdatabase til håndtering af persistens i projektet. Vi vil her lige kort skitsere hvilke tabeller vi har valgt at databasen skal bestå af og hvilke datatyper vi har valgt at bruge til de enkelte attributter i modellaget. Eftersom Proceeding og Tidskrift er identitiske på databasen, vises kun strukturen for Proceeding. A.6 Testplan A.6.1 Formål Formålet med testen er at afdække systemets brugbarhed. Det skal undersøges, om en låner/bibliotekar på det nuværende MI-bibliotek kan benytte systemet og løse en række grundliggende opgaver ved hjælp af systemet. 141

147 TESTPLAN Artikel Boeger Navn Datatype Navn Datatype titel varchar(45) isbn varchar(20) forfatter varchar(45) titel varchar(45) aarstal integer forfatter varchar(45) sideantal integer aarstal integer keywords varchar(45) sideantal integer resume varchar(45) keywords varchar(45) litteraturid varchar(45) resume varchar(45) antallaan integer litteraturid varchar(45) antalreservationer integer antallaan integer BibTeX longtext antalreservationer integer afleveringsdato varchar(20) BibTeX longtext IndeholdtI varchar(300) afleveringsdato varchar(20) laantaf varchar(45) IndeholdtI varchar(300) type varchar(45) laantaf varchar(45) reserveretaf varchar(45) type varchar(45) status int(1) reserveretaf varchar(45) status int(1) Tabel A.4: Artikel og Boeger s opbygning litteraturid Bog integer Artikel integer Proceeding integer Tidsskrift integer PhDafhandling integer 142

148 TESTPLAN Laanere Bibliotekar fornavn varchar(50) id integer efternavn longtext fornavn varchar(45) mail varchar(40) efternavn varchar(45) lokale longtext mail varchar(45 kontortlf integer lokale varchar(45) antallaan integer tlf integer antalreservationer integer status integer status int(1) antallogins integer A.6.2 Hovedspørgsmål Testen skal benyttes til at afdække eventuelle komplikationer ved dets brug for en førstegangsbruger, samt hjælpe med at identificere funktionalitetsmangel/overflødighed. Nøglespørgsmål omfatter følgende: A.6.3 Kan brugeren anvende systemet effektivt til udførsel af de mest almindelige opgaver i MI-biblioteket? Kan disse opgaver udføres i overkommelig tid i relation til opgavernes kompleksitet? Overholder systemet de opstillede kriterier til designet? Brugerprofil Der tages udgangspunkt i de aktuelle brugere af det nuværende MI-bibliotek; det vil sige en gruppe med forskellig grad af IT erfaring, rangerende fra erfarne til meget erfarne IT brugere. Alle testpersoner anvender allerede det nuværende bibliotekssystem, så det forventes, at alle testpersoner er indeforstået med de reelle omgivelser i biblioteket som systemet er designet til at administere. Testpersonerne anskaffes gennem vores vejleder kontakt og eventuelt ved direkte kontakt til specifikke personer, som vi tidligere i projektet har interviewet. Efter disse interview spurgte vi om vi måtte tage kontakt, når projekproduktet skulle testes, så der skulle være god mulighed for at få systmet testet af forskellige brugere. A.6.4 Metode Metoden der anvendes til testen, omfatter en eller flere sessions i AAU s usability lab. Testpersonen gives en kort introduktion til systemet, til for- 143

149 TESTPLAN målet med testen og bedes tænke højt under testen således skjult information kan afdækkes. Tænke højt metoden går ud på at testpersonen siger hvad hun vil gøre for at løse en opgave, således man kommer ind i personens tankgang. Testpersonen skal, under opsyn af testleder, udføre en række basale opgaver i systemet alt efter hans tidligere erfaring med det nuværende MI-bibliotekssystem (Låner/bibliotekar rolle). Alternativt kan alle testpersoner teste hele systemets funktionalitet, således alt bliver grundigt gennemtestet på tværs af testpersonernes tidligere erfaring med biblioteksadministration (Rangerende fra ingen til megen erfaring). A.6.5 Opgaveliste Til testen skal testpersonen i rollen som låner udføre disse opgaver: Opgave 1: Søgning af litteratur Find bogen "Introduction to algorithms"af Thomas H. Cormen. Er bogen ledig? Hvad er bogens ISBN-nummer? Opgave 2: Lån af litteratur Find bogen "Coding and information theory"af Steve Roman Lån bogen Gå til din låner-menu og verificer at bogen er blevet lånt. Aflever bogen igen. opgave 3: Reservation af litteratur Find bogen "Interaction Design"af Preece, Rogers og Sharp. Reservere denne bog. Gå til din låner-menu og verificere at du har reserveret bogen. fjern reservationen igen. Men er testpersonen i rollen som bibliotekar skal han ud over de foregående opgaver udføre disse opgaver: Opgave 4: Oprettelse af litteratur 144

150 TESTPLAN Opret bogen "C# to the point"af Hanspeter Mössenböck. Bogen har ISBN-nummeret X. Verificer at bogen er blevet oprettet i systemet. Opgave 5: Oprettelse af lånere Opret låneren "Jens Tarzan"i systemet. Jens har [email protected], bor i lokale E3-104 og har telefonnummer Slet Jens igen. Opgave 6: Se statistik Find den mest aktive låner. A.6.6 Omgivelser og udstyr Testen udføres i AAU s usability lab med tilhørende udstyr til dokumentation af testen. Det antages, at der skal anvendes video/audio faciliteter til denne dokumentation, idet der blandt andet benyttes tænke højt metoden, samt værktøj til at optage testpersonens færden på brugergrænsefladen. Det kunne eventuelt også være nyttigt med en videooptagelse af brugeren, idet kropssprog kan være nyttig til at identificere mulige problemer/frustrationer over systemet, som ellers ikke kunne opfanges. A.6.7 Testlab-roller Det forventes at der kræves op til flere personer til at udnytte de nødvendige faciliteter. Disse roller er defineret nedenfor. Testleder Testlederen skal fungere i en observerende rolle og skal kun hjælpe en testperson, såfremt denne går helt i stå med en opgave. Hvis testpersonen giver udtryk for, at denne sidder fast, skal testlederen bestræbe sig på at give ledende information og ikke give direkte information til, hvordan opgaven løses. Slår dette fejl, må testlederen gerne vise testpersonen, hvad det næste skridt i processen er. Testlederen bør bestræbe sig på ikke at stresse en testperson ud. 145

151 TESTPLAN Testlogger Testloggeren tager notater under testen, og noterer kort de væsentligste problemer som en testperson oplever. Loggerens arbejde er at opfange information on the fly, således det bliver letter at efterbehandle testeresultaterne. Loggeren befinder sig ikke i samme lokale som testpersonen, men benytter video/audio feedback fra testlokalet til sit arbejde. Teknikoperatøren Teknikoperatøren sørger for at de tekniske faciliteter er i orden og indstillet til testen. Derudover skal han sørge for løbende at sikre kvaliteten af video/audio optagelser, ved at indstille lydstyrke på mikrofoner og ved at sørge for at testpersonens handlinger både på computerskærmen og på videooptagelsen er tydelige. A.6.8 Dataindsamling Der bør indsamles data om, om opgaverne kan udføres korrekt og hvor lang tid en given opgave tager for hver testperson. Disse resultater skal kunne anvendes til at identificere flaskehalse i systemet. Audiodata fra testen skal hjælpe med at afkode problemer testpersonen oplever ved at optage testpersonens tale. Eftersom testen udføres som en tænke højt test, vil der her typisk være en god mængde data, som en testlogger ikke kan nå at opfange. Videodata fra testen skal dække brugerens hænder, torso og ansigt ligeligt, således et samlet indtryk af kropssprog kan aflæses. Denne data kan blandt andet bruges til at afkode om en testperson er nervøs, går i stå eller verificere om testpersonen nu gør det han/hun siger (ved f.eks. dobbeltklik). Program interaktion logges vha. et stykke programmel, som kan optage hvorledes en testperson benytter det testede programs brugergrænseflade. Denne data benyttes til analyse af mulige navigerings problemer og lignende. Testloggeren nedskriver sin data i et tekstdokument eller lignende i naturligt sprog eller stikordsform alt efter dennes kompetence. Denne data er ment som et supplement til testens video/audio data. Hver testperson debriefes efter den praktiske test med et spørgeskema, hvori en testperson bedes om at vurdere i hvor høj grad følgende designkriterier er opfyldt: Primære kriterier: Brugbarhed Korrekthed Pålidelighed 146

152 TRANSKRIBERING Sekundære kriterier: Sikkert Forståeligt Resultaterne af disse undersøgelser skal anvendes til vurdering af systemets design, således det kan undersøges, om de overordnede mål er overholdt. Spørgeskemaerne vil være en kort liste af de ovenstående kriterier koblet sammen med en skala fra 1 til 10 alt efter hvor godt kriteriet er opfyldt, som eksemplificeret nedenstående: Kriterie Brugbarhed Korrekthed Pålidelighed Sikkert Forståeligt I hvor høj grad....mener du systemet opfylder systemdefinitionens krav?..følte du at systemet gjorde som du forventede ved manipulation af brugergrænsefladen?..følte du at systemet var konsekvent mht. opførslen af diverse brugergræsnefladeelementer?..opfylder systemet dine krav til sikkerhed omkring brugerlogin og sikkerhed mod fejl?..forstår du hvad hver enkelt testede funktionalitet gør for dig som bruger? Ud fra optagelser af hver testperson identificeres usability-problemer i en sådan grad, at større fejl og mangler kan rettes inden den endelige version af systemet. Dette gøres i en process efterfølgende selve testen af en til flere personer, således flest mulige problemer kan opfanges. A.7 Transkribering Y: Oh this is English/Danish version? I: It s English I: Yes. Y: There are some words in Danish., but you can... can 147

153 TRANSKRIBERING I: Remember, we are testing the system, not you. Y: Ok. I: So the first excercise is concerning search of literature. So you have to find the book, Introduction to Algorithm s by Thomas H. Cormen. Y: Hrmm. Yes. I: And I want you to think loud, when you have an idea in the head. Just say it to the microphone. Just speak it loud. Y: So now I have to... I: So, so You have to search for the book. Y: But first I have to log into the system, right? I: No. Y: No? Ok. I: Introduction to algorithms. Y: Introduction to... I: Just introduction... not an Y: No... I: No you found a bug! Try introduction. Laughter Y: I didn t find this book? Y: Oh no. This... right? I: Yeah. I think I found a bug in the system. Y: Oh this is capital. I: Yes. Y: All nice. I: No. 148

154 TRANSKRIBERING Y: No it s not so good. I: I think it s because there is a bug in the system. Because when you press backspace, it forgets about the result. You see like this. There it is. Y: No I think when I enter here... I should spell this name correctly? I: Yes exactly. But if you spelled wrong, and then you press backspace... Y: Some times I don t know... okay. I: Yeah. You found the first bug. Y: Ok. For example I should enter Introduction and I enter and find this book. It should be fine? I: Ok let s try just to spell it. You found the book. Y: You found the book. Y: No no. I: Yeah it is Introduction to Algorithms by Thomas. Y: But this should be here? I: Yeah but they both match the input. Y: Ok. I: Is the book avaiable? Y: The state here, it indicates. I want to click... I: What could you else do, maybe right click? Y: More information I think... Free... What do you mean by free? I: No. Loaned out by. It s free. Y: It s free. So it s free. So I could reserve? I: You could loan it, if you want it to. Y: But reservation? 149

155 TRANSKRIBERING I: No. Because it has to be loaned out. Y: Ok because now it is avaiable, so I only... I: What is the isbn number of the book? You have already seen it. Y: Yeah I have already seen it. I: Yeah ok. Y: But I would like to be able to double click, to appear information. I: Yes. Ok new session. That was the first excercise. Now we have to find the book Coding and Information Theory. Y: Here? I: Yeah that s right. Make a loan for this book. Y: But I should check whether it is available or not. Am I right? I: No you... Y: Beacuse this indicates that it is available? So this is green. Green indicates the available book. If it is not available, the green will become red? I: Yellow. Y: Yellow. Ok that s fine. Here, and I loan. How can I confirm? I: What? Yeah, yeah. Exactly. And I have already made a user for you, with your... yes. Y: Username? I: Y, f, z, c, yes just the ordinary. Yes ok. Y: Ok so this become yellow. Ok I see. I: Yes. You have... Y: Return day. This one... I: Ok next excercise is, verify using your usermenu, that you have loaned the book. 150

156 TRANSKRIBERING Y: This are for... here... Again, allright. I: No it doesn t. Y: Oh. I: Ok, what do you see? Y: Huh? I: Ah ok. That was the next excercise. You did it. Y: Ok, I return. I think it should become green. I: Yeah it does. There, coding and... you have to refresh with the... Find the book, Interaction Design by Preece, Rogers and Sharp. Y: In here. I: Now we have the problem. Y: Oh no. Enter... this one? I: Yes. What do you see about the book. Y: This has been borrowed right? Maybe I could reserve? I: Yes that is the excercise. Y: Here? I: Yes. Y: And I m not used to enter my username so many times, I think. I: Ok. And now... yeah exactly, verify that you have reserved it. Y: Ok, can I know, that I borrowed this book. It is available from this day, it means... this book will be returned there, right? So I could receive this book from the library at that date right? I: Yes, that date. Cancel the reservation. Y: Cancel reservation... Ok

157 TRANSKRIBERING I: What do you think? Y:...Should we click here? I: Yes exactly. Y: And then close the window and refresh. I: That was the excercises for the user. Now we want to test excercise, as the librarian. So we want to add some literature. And you also... Y: Username? I: Yes. Y: Login and cancel should be changed. I: Ok. The book is called C# To The Point, and it has an ISBN number. Oh that s in danish sorry. It says X. Y: And the name? I: It was called c#. C and the hash. Just forget about that... to the point. Yeah. Y: The author? I: He is called Hans Peter. Y: Hans Peter? I: Yeah. And then just write something. Y: I should write the year. I: This year. 300, publisher I don t know. Y: Keyword. Create? I: Yes. Y: It should appear I think. Should appear here. I: It s says the books id is, it s danish. Y: BookID? 152

158 TRANSKRIBERING I: Yeah the book id. Y: That s ok? Where is this one? Article specification? I: It is if you press proceeding. Y: Article? I: No proceeding or journal, then you want to specify the contained articles. But since you don t get it, it s a usability problem. Y: I don t know because, if I create a book, maybe I would like to see the book has been created really. I can not be sure, that this book has been created in the library. I: Yeah I understand. Y: I don t know what has happend here. I doesn t matter. So close this one? Ok, or clear? I: Just close. Y: Close. I: And then verify that the book has been added. Y: I could use this one. Here. I: Exactly. Y: More information, here. I: No I think because there are several. It is this one. Ok then you want to add a user. Y: User. I: Yes, he is called Jens. Y: He is quite busy now. I: And Tarzan for surname. Y: Tarzan. Office, E3. ?.Et? This one? 153

159 TRANSKRIBERING I: Yes. Y: Et where is et. It s quit different for me, this keyboard. I: And then the telephone number. Do you remember? Y: I don t know. I: Oh just... it s an error. Just type... just write something else. Not Tarzan just write. It s because it has already been created. And then I want you to delete Jes. Y: This guy? I: Yes. Ok. That s good. Ok. And the last excercise, watch statistics, and then we want you to find the name of the most active user. Y: Acitive user ok. This line should be... I: Yeah that s right. Thank you very much. Y: Ok that s all. I: Yes. Y: Ok that s good. I: But I have to find a pencil because we want you to ask you 5 questions just about... Just one moment. Y: Yeah no problem. I: We have already asked you some questions about this systemdefnition, it s in danish. The system has to take care of the daily functions in the library. So you can do your own business in the library. How do you think, it fullfills this system definition? That you can do your own business and login and...? Y: But I think, personally I have to login here. All right? I: Yeah. Y: And then after I performed some activities, it will be recorded automatically. 154

160 TRANSKRIBERING I: To much login? Y: Yeah to much login. I: Ok did the system manipulate the gui as you expected. Did it react to your click as you wanted it to? Y: I think I more like the keyboard. More keyboard. For the most it should suppose some keyboard. I: Do you characterize the behaviour of the GUI as consistent. Is it the same in all windows? Y: You just (...) one article or something else then. I: Yes. Y: Because there are some information very confusing. I: Confusing? Y: Yeah confusing. I: Do the security aspects, no password and no confirmation on a successfull completed task match your requirements? Do you want a password? You said you wanted some confirmation on the book added? Y: I think there should be some password. I: And also you said when you added the book C# you wanted a screen that said, now it s added. Confirmation. Y: Yeah. When I do something in this system, I want to see the information, what it has done. I think this is quite important. And this is very important features for to you. I: Ok. Just the last question. Do you understand what the functionalities in the system does for you as the user? Y: Sure. I: Ok. Thank you very much. 155

161 INTERAKTIONSRUM A.8 Interaktionsrum Lånerens interaktionsrum findes på den vedlagte Cd-rom. Diagrammerne er ikke med i den digitale version af rapporten pga. formaterings problemer, idet disse diagrammer er fold-out diagrammer af en størrelsesorden svarende til A3 format, eller større. 156

162 INTERAKTIONSRUM 157

163 158 INTERAKTIONSRUM

164 Litteratur [Cormen et al., 1990] Cormen, T. H., Leiserson, C. E. og Rivest, R. L. (1990). Introduction to Algorithms. The MIT Press, 1. udgave. [Larman, 1997] Larman, C. (1997). Applying UML and Patterns: An introduction to object-oriented analysis and design. Prentice Hall PTR. [Mathiassen et al., 2001] Mathiassen, L., Munk-Madsen, A., Nielsen, P. A. og Stage, J. (2001). Objekt Orienteret Analyse & Design. Marko ApS. [Preece et al., 2002] Preece, Rogers og Sharp (2002). Interaction Design. John Wiley & Sons, co. [Provost, 2006] Provost, P. (2006). dotnet/tdd_in_dotnet.asp. [Stage, 2006] Stage, J. (2006). ~jans/courses/hci-courses/dieb-2006/spisesedler/ spiseseddel02.htm. [Stott og Newkirk, 2006] Stott, W. og Newkirk, J. (2006). ExtremeProgramming/default.aspx#S8. [Two et al., 2006] Two, M. C., Poole, C., Cansdale, J. og Feldman, G. (2006). [WikiPedia, 2006] WikiPedia (2006). wiki/unit_test