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 tarzan@cs.aau.dk, 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