Søkemaskiner. Svein Arne Haug Ståle A. Nygård

Transkript

1 Søkemaskiner Svein Arne Haug Ståle A. Nygård CIT270 Søkemaskiner Kandidatutdanning SWU Prosjektoppgave høsten 2002

2 Innholdsfortegnelse Innholdsfortegnelse 1. Forord og innledning Bakgrunn (og problemstilling) Problemanalyse Krav til datafilene Symbolforklaring / innhold i datafiler Beskrivelse av oppgave 1 (SearchCmd.java) Ideer / innvarianter Datastruktur Programbeskrivelse Tid for oppbygning og søking i datastrukturen Plassbehov (RAM) Beskrivelse av oppgave 2 (SearchCmd2.java) Ideer / innvarianter Programbeskrivelse Tid for oppbygning og søking i datastrukturen Beskrivelse av oppgave 3 (SearchCmd3.java) Ideer / innvarianter Datastruktur Programbeskrivelse Tid for oppbygning og søking i datastrukturen Plassbehov (RAM) Beskrivelse av oppgave 4 (SearchCmd4.java) Ideer / innvarianter Datastruktur Programbeskrivelse Tid for oppbygning og søking i datastrukturen Plassbehov (RAM) Beskrivelse av Utvidelser Ideer / innvarianter Datastruktur Programbeskrivelse Tid for oppbygging og søking i datastrukturen Plassbehov (RAM) Avprøving Softwaretest Konklusjon Vedlegg A Oppgavebeskrivelser Vedlegg B Brukerveiledning og eksempler Vedlegg C Kravspesifikasjon (Input/output) Vedlegg D Programmeringstekniske beskrivelser Vedlegg E Tidsmålinger Vedlegg F Softwaretest Vedlegg G Programkode

3 1. Forord og innledning 1. Forord og innledning Denne rapporten er utarbeidet av Ståle A. Nygård og Svein A. Haug høsten 2002 i et kurs om søkemaskiner ved HiNT i Steinkjer veiledet av Stephen Alstrup og Theis Rauhe ved IThøjskolen i København samt Hugo Norseth ved HiNT i Steinkjer. Våre forutsetninger for kurset er grunnleggende Java- og Pascal-kunnskaper. Steinkjer 22.november 2002 Ståle A. Nygård Svein A. Haug 2. Bakgrunn (og problemstilling) Bakgrunnen for denne rapporten er å lære om forskjellige typer søkemaskiner og sammenligne fordeler og ulemper mellom de forskjellige søkemaskinene med hensyn til blant annet søketid, tid ved innlesning av datafiler og behov for lagringsplass. Oppgavebeskrivelser er beskrevet i vedlegg A. Brukerveiledning for bruk av programmene er beskrevet i vedlegg B. 1

4 3. Problemanalyse 3. Problemanalyse Oppgavens fellesdel består av å løse 4 oppgaver basert på et program (SearchCmd) som implementerer en liten søkemaskin. Oppgavene går ut på å videreutvikle programmet SearchCmd slik at vi får forskjellige typer søkemaskiner som er organisert med forskjellige datastrukturer. Programmet SearchCmd er oppgitt som grunnlagsmateriale sammen med 3 datafiler som inneholder IT-C s hjemmesider. De 3 datafilene itcwww-small.txt, itcwwwmedium.txt og itcwww-big.txt har samme oppbygning men forskjellige størrelser, der den minste inneholder noen av IT-C s hjemmesider og den største inneholder alle IT-C s hjemmesider. Datafilene brukes som søkegrunnlag ved kjøring av programmet. Figur 3.1 viser et eksempel på hvordan datafilene er bygd opp. *PAGE: Her står et ord og et ord mere *PAGE: Her står mere og endnu mere : Figur 3.1: Eksempel på en datafil. 3.1 Krav til datafilene. Datafilene må være rene sekvensielle tekstfiler. Dersom programmet skal kjøres på et MS Windows OS (Win9x/WinNT/2000/XP) må datafila være av typen MS-DOS. Det må være kun ett ord eller en URL-adresse pr. linje (ord må være uten mellomrom). En linje som starter med en stjerne (*) blir tolket som en URL-adresse. Det settes likevel krav til at alle URL-adresser skal være kodet med prefikset *PAGE: etterfulgt av selve URL-adressen. Linjer som starter med andre tegn enn stjerne tolkes som et ord som forekommer i den hjemmesiden som har den URL-adressen som sist ble angitt i datafila. Den første linja i datafila må være en URL-adresse (dersom fila inneholder ord først vil ikke disse ordene være knyttet til en URL-adresse, og slike ord vil ikke ha noen mening i en søkemaskin etter ord som forekommer i hjemmesider). URL-adressene i datafila må forekomme kun en gang (dersom samme URL forekommer to ganger, vil dette behandles som to forskjellige hjemmesider, men med samme URL-adresse, og med hvert sitt innhold av ord). Dersom en hjemmeside ikke inneholder noen ord, har det ingen betydning for virkemåten av programmet. Det settes altså ikke noe krav til at tomme hjemmesider ikke kan forekomme. 2

5 3. Problemanalyse Ord i selve URL-adressene blir ikke behandlet som unike ord og blir dermed ikke søkbare. 3.2 Symbolforklaring / innhold i datafiler For å forstå bokstavene som brukes senere i rapporten til å beskrive innholdet i datafilene, har vi laget et enkelt eksempel som forklarer hva de betyr. En enkel generell datafil kan være slik som vist i venstre kolonne i tabellen: Eksempelfil *PAGE:1 aaa bbb *PAGE:2 bbb ccc bbb Tabell 3.1: Symbolforklaring Symbolforklaring Fra datafila til venstre kan man hente ut disse opplysningene : N = 7 ( antall linjer i datafila ) H = 2 ( antall hjemmesider *PAGE:1, *PAGE:2 ) U = 3 ( antall unike ord aaa, bbb, ccc ) S = 4 ( summen av antall unike ord på hver hjemmeside aaa, bbb + bbb, ccc ) Ved å inkludere tellere i programkoden er det mulig å trekke ut litt statistikk om innholdet i de vedlagte datafilene: Datafil Ant. tegn Ant. Linjer (N) Ant. URL (H) Ant. ord Ant. unike ord (U) Sum unike ord pr. URL (S) itcwww-small.txt itcwww-medium.txt itcwww-big.txt Tabell 3.2: Innholdet i de 3 datafilene 3

6 4. Beskrivelse av oppgave 1 (SearchCmd.java) 4. Beskrivelse av oppgave 1 (SearchCmd.java) 4.1 Ideer / innvarianter I oppgave 1 skal vi lage et program (en søkemaskin ) som skal søke etter om et angitt ord finnes i et sett med gitte hjemmesider. Hjemmesidene er på forhånd parset og lagret i en tekstfil (se kapittel 3). Hele datafila skal leses inn av programmet og lagres i minnet (RAM). Innlesing av alle ord og URL-er til primærminnet vil være nødvendig for å kunne gi en rask respons på mange søk. Hver linje (ord eller URL) blir lest inn fra datafila. Det blir allokert plass i minnet, og innholdet på hver linje blir lagret i minnet som en tekststreng. Ved å legge strengene inn i sammensatt objekter vil man kunne lenke ordene sammen ved at det første ordet peker til det neste ordet, som peker til det neste ordet, osv. Ordene ligger tilfeldig lagret i minnet, så for å søke i ordene må man hele tiden holde rede på det første elementet i den lenkede listen. Hvordan lenkede lister gjøres i Java, beskrives i vedlegg D detaljerte beskrivelser. Når datafilen er lest inn i minnet, vil det være mulig å skrive inn ord som det skal søkes etter. Programmet vil gi tilbakemelding på om ordet finnes eller ikke. Søkingen gjøres ved å gå igjennom den lenkede listen fra start mot slutt, men dersom ordet blir funnet er det ikke nødvendig å gå igjennom resten av den lenkede listen og søkingen avsluttes. 4.2 Datastruktur Ord og URL-adressene i datafila leses inn i en enkel lenket liste som er realisert vha. klassen HTMLlist. Objektet HTMLlist består av en streng og en neste-peker. Hver linje (ord/url) i datafila legges fortløpende inn i datastrukturen, man skiller altså ikke mellom URL er og innholdsord. Tilgang til listen gjøres ved å ta vare på første element (start) i listen (se figur 4.1). Neste-pekeren til siste element skal bestandig peke til null. *PAGE: *PAGE: Her står et ord Her start Figur 4.1: Enkelt lenket liste bestående av HTMLlist-objekter 4

7 4. Beskrivelse av oppgave 1 (SearchCmd.java) 4.3 Programbeskrivelse Programmets hovedfunksjonalitet: Filnavnet gis innledningsvis til programmet som leser inn datastrukturen fra angitt fil, og returnerer en peker til starten av den lenkede listen. Etter at datastrukturen er på plass i den lenkede listen, gir programmet brukeren anledning til å angi søkeord fra tastaturet i en løkke som avbrytes når brukeren kun trykker <Enter>. Hvordan legges nye elementer til i listen? I readhtmllist-metoden leses ord og URL er sekvensielt fra fila, og legges inn som nye elementer (objekter) på slutten av den lenkede listen. En current-peker holder rede på siste element i lista, samtidig som en start-peker tar vare på første element (start-pekeren blir tilslutt overført som returverdi på metoden). Figurene 4.2a-d viser hvordan nye elementer legges til i 4 trinn: siste ord name nytt current null Strengen name peker på den siste innleste linja (ordet/url en) fra datafila ( nytt ). Ordet ord er siste element i listen, neste-pekeren peker nemlig på null. Figur 4.2a Leser nytt navn fra datafila siste ord name nytt current null tmp null Et nytt HTMLlist-objekt opprettes (tmp), og streng-feltet til det nye objektet settes til å peke på det nye ordet fra fila (neste-pekeren settes til å peke på null ). Figur 4.2b Oppretter et nytt HTMLlist-objekt siste ord name nytt Det nye elementet hektes på listen ved at neste-pekeren til current -elementet settes til å peke på det nye. current tmp null Figur 4.2c Det nye HTMLlist-objektet kobles til den eksisterende datastrukturen. 5

8 4. Beskrivelse av oppgave 1 (SearchCmd.java) siste ord name nytt Current -pekeren flytter seg et hakk videre (settes til å peke på det nye elementet, som nå blir det siste i listen). current tmp null Figur 4.2d Flytter pekeren Current til slutten av lista. Søking i lista med exists: For hver gang man skal søke etter om et angitt ord finnes, kaller man opp exists-metoden med starten på den lenkede listen og søkeordet som parametre. Metoden søker gjennom den lenkede listen etter det angitte ordet, og returnerer true ved første forekomst av søkeordet. Listen søkes gjennom ved å benytte en peker ( l ) som flytter seg fra element til element (se figur 4.3a): *PAGE: *PAGE: Her står et ord Her str next l Figur 4.3a: Pekeren l peker på står Pekeren l flyttes til neste element ved å sette den til å peke på det samme elementet som neste-pekeren peker på (l = l.next, se figur 4.3b): *PAGE: *PAGE: Her står et ord Her str next l Figur 4.3b: Pekeren l flyttes til å peke på et 6

9 4. Beskrivelse av oppgave 1 (SearchCmd.java) For hvert element sjekkes det om objektets streng er det samme som det angitte søkeordet ( word ): word ord et ord str next str next l Figur 4.4: Søkerutinen har funnet det angitte søkeordet Det kunne vært fristende å skrive testen på om ordene var like på denne måten i Java: if(l.str == word), men det vil i dette tilfellet ikke gi forventet resultat. Siden en streng er et objekt, vil denne setningen egentlig sjekke om l.str og word peker på samme streng-objekt. Av figuren ser vi at dette ikke er tilfelle (de to forekomstene av ord befinner seg på forskjellige minneadresser i primærlageret). Vi tar derfor i stedet i bruk en metode som String-klassen tilbyr oss, nemlig den boolske metoden equals: if (l.str.equals(word)). Denne metoden sjekker to strenger bokstav for bokstav, og sammenligner dem ( o = o, r = r, d = d ) for å finne ut om begge ordene har nøyaktig samme bokstavsammensetning (metoden returnerer i vårt tilfelle true ). Equals-metoden er mere ressurskrevende enn å bruke = =. 4.4 Tid for oppbygning og søking i datastrukturen. Hvor lag tid i minutter og sekunder det tar å bygge opp og søke i datastrukturen, er avhengig av hvilken datamaskinkapasitet programmet kjøres på og vil variere fra datamaskin til datamaskin. Da er det ikke så interessant å beskrive det reelle tidsforbruket. For å angi tidsforbruket mer generelt kan man beskrive tiden ved hjelp av O-notasjon. Tidsforbruk ved oppbygging av hele datastrukturen i SearchCmd kan beskrives som O(N) (tidsforbruket øker lineært med antall linjer i datafila). Det utføres ingen søk i datastrukturen ved oppbygging, man legger bare til nye objekter sist i den enkelt lenka lista. Tidsforbruk ved søking i datastrukturen kan beskrives som O(N), hvor N er antall objekter i datastrukturen. Det kan hende at ordet man søker etter ligger først i datastrukturen, da vil man raskere få resultatet enn om ordet ligger sist i datastrukturen. Ved bruk av o-notasjon kan man beskrive worst case hendelse som i dette tilfellet krever mest tid, og det vil være hvis man må søke gjennom alle objektene (N) i datastrukturen. 7

10 4. Beskrivelse av oppgave 1 (SearchCmd.java) 4.5 Plassbehov (RAM) I SearchCmd vil det opprettes ett objekt for hvert ord og for hver URL. Antall objekter vil bli det samme som antall linjer i datafilen. Plassbehovet for tekststrengene vil være 2 byte pr. tegn (en tekststreng pr. ord eller URL-adresse), mens plassbehovet for hvert objekt i den lenkede listen vil være 4 byte pr. peker (objektene består av 2 pekere: en til tekststrengen og en til neste objekt i listen), og i tillegg 4 byte for hele objektet. Dvs. at hvert objekt har behov for 12 byte. Formelen for plassbehov for datastrukturen i SearchCmd blir da (c = ant. tegn i datafila, N = ant. objekter/linjer): T = 2 c + 12 N [byte] (formel 4.1) Datafil Ant. Tegn (c) Plassbehov Ant. Linjer (N) Plassbehov Totalt tekststrenger objekter plassbehov (T) itcwww-small.txt KB KB 93 KB itcwww-medium.txt KB KB KB itcwww-big.txt KB KB KB Tabell 4.1: Plassbehov SearchCmd 8

11 5. Beskrivelse av oppgave 2 (SearchCmd2.java) 5. Beskrivelse av oppgave 2 (SearchCmd2.java) 5.1 Ideer / innvarianter Søkemaskinen i oppgave 1 gir kun en tilbakemelding på om ordet det søkes etter finnes blant hjemmesidene som er lest inn fra datafila. I oppgave 2 skal programmet i tillegg skrive ut alle hjemmesider som inneholder det ordet som det søkes etter. Det er da 2 nye problemer som må løses: Man må vite hvilken hjemmeside ordet som er funnet tilhører, og man må sørge for at hver URL skrives ut kun en gang i tilfelle ordet finnes flere ganger i samme hjemmeside. Datastrukturen blir bygd opp likt i SearchCmd og SearchCmd2, og er beskrevet i kapittel 4.2. Derfor vil det heller ikke bli noen forandringer i plassbehovet (se kapittel 4.5). 5.2 Programbeskrivelse Siden programmet nå skal skrive ut alle URL-adresser til websider hvor ordet det søkes etter forekommer, må hele den lenkede listen gjennomløpes for å finne alle forekomster av søkeordet. I søkemetoden benyttes en egen peker (tmp) som holder rede på det siste objektet som inneholdt en URL-adresse, slik at man vet hvilken webside (URL) man er inne i når søkeordet finnes. I vedlegg D vises en skisse av hvordan denne søkingen foregår. Hver URL-adresse skrives ut bare en gang: Ordet det søkes etter kan forekomme flere ganger på samme webside. For å unngå at programmet skriver ut samme URL-adresse flere ganger, benyttes en boolsk variabel (skrevetut) som settes sann når websiden til et ord skrives ut første gang, og nullstilles (settes usann) hver gang man har funnet en ny webside (URL). 5.3 Tid for oppbygning og søking i datastrukturen. Tid for oppbygging og søking i datastrukturen i SearchCmd2 uttrykkes likt som i SearchCmd og er beskrevet i kapittel 4.4. Ulempen med SearchCmd2 er at man må søke gjennom hele datastrukturen mens man i SearchCmd kan avslutte søket i datastrukturen når den finner ordet det søkes etter. SearchCmd skriver heller ikke ut URL-adressene og sparer tid på det (men vil selvsagt være mindre anvendelig da man ikke vet hvilke websider som inneholder søkeordet). 9

12 6. Beskrivelse av oppgave 3 (SearchCmd3.java) 6. Beskrivelse av oppgave 3 (SearchCmd3.java) 6.1 Ideer / innvarianter Datastrukturen som benyttes i oppgave 1 og oppgave 2 (en enkeltlinket liste) er veldig enkel å implementere, men er både plasskrevende og tidskrevende å søke i ved store mengder data. Ved store datamengder vil datastrukturen være så plasskrevende at programmet kan avbrytes pga. mangel på ledig minne. Dette skyldes at hvert enkelt ord og hver enkelt URL-adresse blir lagret i minnet. Siden absolutt alle ordene blir lagret en gang i SearchCmd 1 og 2, vil det forekomme at like ord blir lagret flere ganger. Dette har sin naturlige årsak i at for eksempel det danske språket består av et begrenset antall ord, og enkelte ord vil da nødvendigvis gjenta seg. Hvis vi analyserer alle IT-C sine hjemmesider ser vi for eksempel at disse totalt består av over 2,7 millioner ord, mens antall unike ord kun er om lag (ca dersom vi ser bort fra bruk av små og store bokstaver). For å redusere minneplass og søketid gjør vi om datastrukturen slik at kun unike ord blir lagret i minnet i en lenket liste. I tillegg har hvert ord en peker til en lenket liste med URLadresser hvor dette ordet forekommer. Dersom ordet finnes på en eneste hjemmeside består listen med URL-adresser kun av et objekt, og dersom ordet finnes på flere hjemmesider vil listen med URL-adressen inneholde alle URL-adressene hvor ordet finnes. Ulempen med den nye plassbesparende datastrukturen, er at man mister en del informasjon om hjemmesidene. Man har ikke lengre mulighet til å finne ut hvor mange ganger et ord forekommer på en enkelt side, og det vil ikke være mulig å søke etter ord i rekkefølge ( fraser ). 6.2 Datastruktur Ved innlesing av datafilen blir de unike ordene som finnes på websidene lest inn i en enkel lenket liste. Den realiseres ved hjelp av klassen Wordlist som består av en streng (hvor ordet blir lagret), en peker til første objektet i HTMLlist (som inneholder en lenket liste over URLadressene hvor ordet finnes) og en neste-peker til neste Wordlist-objekt. 10

13 6. Beskrivelse av oppgave 3 (SearchCmd3.java) *PAGE: et *PAGE: står null Her null null null Figur 6.1: Datastruktur for SearchCmd3 med Wordlist-objekter (ord) vertikalt og HTMLlistobjekter (URL-adresser) horisontalt. Figur 6.1 viser skjematisk hvordan deler av datastrukturen i SearchCmd3 ser ut etter innlesing. Hver linje i datafila som inneholder et ord og som ikke er en URL-adresse, legges inn i den lenka lista med Wordlist-objekter (som går vertikalt i figur 6.1). Den lenkede lista av Wordlist-objekter består av unike ord, dvs. hvert ord finnes bare en gang i lista. Pekere til hjemmesider som inneholder det unike ordet i Wordlist legges i en lenket liste med HTMLlist-objekter (angitt horisontalt i figur 6.1). Også den lenkede lista av HTMLlistobjekter er unik, dvs. for hvert unike ord er kun de websider hvor dette ordet finnes angitt èn gang selv om ordet finnes flere ganger på en side. Tekststrengen til en bestemt URL-adresse lagres kun en gang i RAM, men det kan være mange pekere (fra HTMLlist-objekter) som refererer til denne adressen. Lengden på ordlisten vi må søke igjennom for å finne et ord reduseres som sagt, men fremdeles må vi søke sekvensielt fra starten av listen til vi eventuelt har kommet fram til objektet i listen hvor ordet finnes. Men når vi har funnet dette ordet har vi med en gang tilgang til en lenket liste over alle URL-adressene som skal skrives ut på skjermen. 6.3 Programbeskrivelse Hvordan legges nye Wordlist-objekter til i datastrukturen? Ved innlegging av et nytt ord i Wordlist-lenken, legges det nye objektet til i starten av den lenkede lista med en nestepeker til det siste innlagte Wordlist-objektet og en peker til HTMLlist-objektet. HTMLlist-objektet inneholder pekeren til URL-adressen til websiden der ordet finnes (lasturl), og en nestepeker som peker til null. Figur 6.2 visualiserer dette. At Wordlist-objektet legges til i starten, og ikke i slutten av lenken, betyr at startpekeren hele tiden refererer til det siste innlagte elementet og man slipper å benytte en ekstra hjelpepeker for å angi siste innlagte objekt. 11

14 6. Beskrivelse av oppgave 3 (SearchCmd3.java) *PAGE: et start lasturl står null Her null null null Figur 6.2: Innleggelse av nye Wordlist-objekter Hvordan legges nye HTMLlist-objekter til i datastrukturen? Hvis metoden search() finner ut at et ord som registreres ved innlesing finnes fra før i Wordlist-lenken, vil man ikke legge til et nytt Wordlist-objekt i den lenkede lista, men legge til et nytt HTMLlist-objekt først i HTMLlist-lenka under det eksisterende ordet. Fordelen med å legge til HTMLlist-objektet først i lista er ved søking. Man trenger bare å se på det første objektet i lista for å avgjøre om URL-adressen er registrert tidligere. Det nye HTMLlist-objektet legges til kun hvis aktuelle URL-adresse ikke finnes i lista fra før. Fordi en og samme URL-adresse kun kan forekomme en gang i datafila og datafila sekvensielt blir lest inn, er vi sikre på at det siste URL-adressen står først i HTML-listen dersom ordet allerede finnes på siden. Vi trenger derfor ikke å søke gjennom hele HTMLlist-lenka. Vedlegg D beskriver hvordan et objekt legges til først i en lenket liste. Sjekk på om samme ord forekommer flere ganger på en webside : Dersom et ord forekommer flere ganger på samme webside, skal det ikke legges til et nytt HTMLlist-element under dette aktuelle Wordlist-elementet. Url-strengen til det første HTMLlist-elementet kan nås direkte vha. notasjonen: u.url.str (se figur 6.3 nedenfor): *PAGE: mere lasturl *PAGE: u str url str null 12

15 6. Beskrivelse av oppgave 3 (SearchCmd3.java) Figur 6.3: Sjekk på om URL en på ordet er registrert fra før For å sjekke om aktiv URL (lasturl) allerede er registrert, kan man benytte equals-metoden for å sjekke om de to tekststrengene er like: if (lasturl.equals(u.url.str)). Men siden tekststrengen til URL en er et objekt som det kun blir satt av plass til en gang i RAM en (men med flere pekere mot seg), ser vi av figur 6.3 at lasturl i virkeligheten står å peker på det samme streng-objektet som u.url.str. I stedet for å benytte den ressurskrevende equalsmetoden (som må kontrollere tegn for tegn), så kan vi altså heller sjekke om de to pekerne står å peker på samme plass i RAM en. I dette tilfellet kan vi derfor benytte oss av følgende måte å sjekke dette på: if (lasturl == u.url.str). Dette vil være langt mer effektivt enn å bruke equals-metoden. 6.4 Tid for oppbygning og søking i datastrukturen. Tidsforbruk ved oppbygging av datastrukturen i SearchCmd3 kan beskrives som O(N U), hvor N = antall linjer i datafila og U = antall unike ord. Tidsforbruk ved søking i datastrukturen kan beskrives som O(U), hvor U er antall unike ord i datastrukturen (antall Wordlist-objekter). 6.5 Plassbehov (RAM) I SearchCmd3 vil det bli opprettet ett objekt for hvert unike ord, og et objekt for hver webside det unike ordet forekommer i. Tekststrengene til en URL-adresse blir kun lest inn en plass i RAM en (med flere pekere mot seg). Derfor vil målet på antall tekstrenger bli: antall unike ord + antall URL er. Hvis vi videre regner med at hver tekststreng i snitt består av 5 tegn (10 byte), vil plassbehovet for tekststrenger (t) i denne datastrukturen anslagsvis bli (U = ant. unike ord, H = ant URL er): t 10 (U + H) [byte] (formel 6.1) For hvert unike ord blir det som sagt opprettet ett objekt av typen Wordlist. Disse objektene består av 3 peker. Dvs. plassbehovet for hvert objekt blir byte = 16 byte. Formelen for plassbehovet for den lenkede listen med Wordlist-objekter (w) blir da: w = 16 U [byte] (formel 6.2) I tillegg til dette vil det for hvert unike ord være en lenket liste med pekere til URL-adresser hvor dette ordet forekommer (minimum en URL-adresse for hvert unike ord). Selv om tekststrengen til hver URL-adresse er lagret kun en gang vil det altså som regel være flere objekter som peker til URL-adressen (en hjemmeside består jo selvfølgelig som oftest av flere 13

16 6. Beskrivelse av oppgave 3 (SearchCmd3.java) enn 1 unikt ord). Hvert objekt i denne lenkede listen med HTMLlist-objekter har et plassbehov på = 12 byte. Den endelige formelen på plassbehovet (T) for SearchCmd3 blir da (S = ant. HTMLlist-objekter se ellers symbolforklaring i kapittel 3.2): T = t+w+12 S = 26 U+10 H+12 S [byte] (formel 6.3) Datafil Antall linjer (N) Unike ord (U) URL (H) Plass tekststrenger (t) Plass Wordlistobjekter (w) URLobj. (S) Plass URLobjekter (12 S) Total plass (T) itcwww-small.txt KB 24 KB KB 66 KB itcwwwmedium.txt KB 309 KB KB KB itcwww-big.txt KB KB KB KB Tabell 6.1: Plassbehov i minnet for datastrukturen i SearchCmd3 Ved overgangen fra SearchCmd2 til SearchCmd3 gjorde vi om datastrukturen fra en enkeltlenket liste med alle ord og alle URL-adresser, til en lenket liste med unike ord og flere lenkede lister med URL-adresser (en for hvert unike ord). Hvis vi sammenligner de to versjonene, ser vi bl.a. at plassbehovet for den største datafila i SearchCmd3 er kun 21% av plassbehovet for den samme datafila i SearchCmd2: Datafil Antall linjer Plassbehov Plassbehov S3:S2 (N) SearchCmd2 SearchCmd3 itcwww-small.txt KB 66 KB 0,71 itcwww-medium.txt KB KB 0,36 itcwww-big.txt KB KB 0,21 Tabell 6.2: Sammenligning mellom SearchCmd3 og SearchCmd2 14

17 7. Beskrivelse av oppgave 4 (SearchCmd4.java) 7. Beskrivelse av oppgave 4 (SearchCmd4.java) 7.1 Ideer / innvarianter Innlesing av datafila til datastrukturen i SearchCmd3 med gjentatte sekvensielle søk i en lenket liste, er veldig tidkrevende ved store datamengder. For å kunne gjøre innlesning og søking raskere, må vi derfor benytte oss av tabeller (arrays). Når en tabell opprettes angir man antallet tabellelementer tabellen skal ha. Programmet sørger for at fortløpende plass blir allokert i minnet. Ved bruk av tabeller får man derfor direkte (rask) tilgang til tabellelementene ved hjelp av indeks-nummeret. I vårt program deler vi opp den ene lange ordlisten i flere mindre lister. Når man har flere lister ord kan legges i (og søkes etter) må man opprette en sammenheng mellom ord og hvilken liste det skal tilhøre. Denne sammenhengen kalles en hashingfunksjon, og de ulike listene som ordene kan legges inn i kalles bøtter. Bøttene realiseres som elementer i en hashingtabell, og hashingfunksjonen gir oss den riktige indeksen (bøtten). 7.2 Datastruktur Forskjellen på denne datastrukturen i forhold til datastrukturen i SearchCmd3 er at vi lager en tabell av typen WordList i tillegg til datastrukturen i SearchCmd3. Dette er vist i figur 7.1. Vi benytter oss av en hashtabell-datastruktur, hvor vi har direkte tilgang via tabellindeksene til flere små Wordlist-lenker: null null null null null Figur 7.1 : Hashtabell-datastruktur for SearchCmd4 15

18 7. Beskrivelse av oppgave 4 (SearchCmd4.java) 7.3 Programbeskrivelse Forandring i virkemåten i forhold til SearchCmd3 er beskrevet under. Ny metode hashingfunksjon : Metoden mottar søkenavnet og størrelsen på hashingtabellen og returnerer et positivt heltall (indeksen i hash-tabellen for gitt søkeord) mellom 0 og Vi har valgt å avsette en fast størrelse på tabellen med 5000 plasser pga. at vi ikke vet hvor mange unike ord datafila består av på forhånd. Ved den største datafila vil det i gjennomsnitt bli ca. 15 ord pr. bøtte. Det ideelle hadde vært å hatt kun ett Wordlist-objekt i hver bøtte. Forandringer i metoden readhtmllist : Ved innlesing av et ord, vil programlinja int h=word.hashcode()%tabstorrelse; gi en heltallsverdi h mellom og Det positive heltallet benyttes som en indeks i hashtabellen, altså ordet lagres under plass h i hashtabellen. HashCode er beskrevet nærmere i vedlegg D. Ellers bygges resten av datastrukturen opp slik som i SearchCmd3 med WordListobjekter og HtmlList-objekter i lenkede lister beskrevet i kapittel Tid for oppbygning og søking i datastrukturen. Tidsforbruk ved oppbygging av hele datastrukturen i SearchCmd4 kan beskrives som O(N). Man får direkte aksess til riktig hashingbøtte. Den eneste søkingen som utføres er evt. i de få Wordlist-objektene som finnes i hashingbøtta og vil ikke ta lang tid. Tidsforbruket ved søking i datastrukturen kan beskrives som O(1). 7.5 Plassbehov (RAM) I forhold til SearchCmd3 må det nå i tillegg settes av plass til hashingtabellen. Vår hashingtabell består av heltall av typen int. Slike heltall tar opp 4 byte, og siden vi opererer med en fast størrelse på hashingtabellen i SearchCmd4 (5 000 elementer) vil plassbehovet for denne tabellen være fast på = byte: Datafil Antall linjer (N) Plassbehov SearchCmd3 Plassbehov SearchCmd4 itcwww-small.txt KB 86 KB itcwww-medium.txt KB KB itcwww-big.txt KB KB Tabell 7.1: Plassbehov i minnet for datastrukturen i SearchCmd4 16

19 8. Beskrivelse av Utvidelser 8. Beskrivelse av Utvidelser 8.1 Ideer / innvarianter I forhold til SearchCmd4 skal det gjøres 4 utvidelser av programmet: 1) Størrelsen på hashingtabellen skal endres dynamisk under innlesing til datastrukturen ved at man på forhånd har satt en grense på hvor mange objekter som skal legges i hver bøtte ( tabelldobling ), 2) datastrukturen skal gjøres mer plassbesparende ved å benytte indekstabell i stedet for en URL-liste for å holde rede på hvilke hjemmesider et ord befinner seg på, 3) boolsk søking skal gjøres mulig (AND og OR), og 4) prefikssøking og sufikssøking skal gjøres mulig (for eksempel å kunne søke på hus* for å finne alle hjemmesider hvor ord som begynner på hus finnes, eller søke på *vogn for å finne alle hjemmesider hvor ord som ender på vogn finnes). I SearchCmd4 ser vi at det er URL-objektene (S) som dominerer plassbehovet. I den største datafila tar URL-objektene opp 85 % av totalplassen. Et plassbesparende alternativ for å holde rede på URL-adressene til et ord vil være å lage en felles tabell som inneholder URLadressene, og så benytte indeksene i denne tabellen i en tabell med indekser ut fra hvert ord. Et shortheltall ( til ) opptar 2 byte, mens et sammensatt listet lenkeobjekt opptar 12 byte. Ved å benytte en tabell med indekser for å holde rede på et ords URL-adresser, vil det også være enklere å foreta boolske sammenligninger (AND og OR), siden dette kan gjøres ved å sammenligne to heltallstabeller. Felles for metodene som skal beregne boolske operasjoner, er at to tabeller med URL-indekser sammenlignes, og en svar -tabell (med indekser) opprettes. For å kunne benytte prefikssøk lager vi en tabell som består av alle de unike ordene. Denne tabellen sorteres ved hjelp av quicksort -algoritmen. Ved hjelp av den rekursive binærsøk - metoden i den sorterte tabellen, vil det nå være mulig å kjapt finne ut hvilke ord (ofte flere ord) som passer med prefiks-mønsteret. Dette skyldes at når ordene er sortert, vil ordene som passer med søkemønsteret komme etter hverandre i tabellen. For å kunne benytte sufiks-søk (ord som ender på et gitt mønster: *vogn) kan man før søkingen tar til lage enda en tabell som inneholder alle søkeordene snudd på hodet (hvert ord invertert). For eksempel vil husvogn bli lagt inn i denne tabellen som ngovsuh. Denne inverterte tabellen sorteres også, og søk i tabellen gjøres på samme måte som ved prefiks-søk: sufikssøk etter *vogn blir det samme som prefikssøk etter ngov* i den inverterte tabellen. 17

20 8. Beskrivelse av Utvidelser 8.2 Datastruktur URL-tabell Per hashtabell *Page1 *Page *Page3 shorttabell *Page4 Figur 8.1 : Datastruktur for utvidelser i SearchCmd5 Ved oppbygging av datastrukturen erstattes som sagt HTMLlist-objektene med Short-tabeller. Indeks 0 i Short-tabellene er avsatt til å holde rede på hvilken indeks i sin egen tabell som sist ble opptatt (figur 8.2 skisserer dette tydelig), dette fordi man da slipper å søke gjennom Shorttabellen for å finne første ledige indeks (som vil være tallet 0). URL-adressene lagres i en egen tabell (urltab) fra indeks 1 og utover. Når et ord skal registreres i datastrukturen, vil det i Short-tabellen som representerer dette ordet bli lagret et tall. Tallet er indeksnummeret i urltab som har URL-adressen til websiden som ordet finnes på. Grunnen til at ikke indeks 0 i urltab benyttes er at Short-tabellene initieres med (tallet) 0 når de opprettes. Alle tabeller i datastrukturen utvides (dobles) automatisk hvis de blir for små. Figur 8.1 viser at ordet Per befinner seg på 2 hjemmesider (første indeks i Short-tabellen), og disse har indeksnumrene 1 og 4. Hvis vi slår opp dette i URL-tabellen ser vi at dette er hjemmesidene *PAGE1 og *PAGE Programbeskrivelse Ved sortering av String-tabellene og søking i dem, benyttes de ferdige metodene Sort.quicksort og BinarySearchRecursive.binarySearch som følger med læreboka Data Structures & Problem Solving Using JAVA av Mark Allen Weiss. Dobling av hashingtabellen: I SearchCmd5 vil størrelsen til hashingtabellen endres dynamisk underveis i oppbyggingen av datastrukturen. Vi har laget en metode dobletabell som sørger for å utføre doblingen. Variabelen antwordlist bestemmer hvor mange elementer det skal være i hver bøtte (vi har satt dette tallet til 5), og variabelen antbotter holder hele tiden rede på hvor mange bøtter tabellen består av til enhver tid. Dobling-metoden kjøres dersom det i gjennomsnitt er mer enn 5 (antwordlist) elementer i hver bøtte (antunikeord > Searcher.antBotter * Searcher.antWordlist). Metoden dobletabell tar imot hashingtabellen som parameter, og kopierer ordene i den opprinnelige hashingtabellen inn i en ny midlertidig tabell som er dobbelt så stor. Den nye tabellen retureres til slutt (metoden kalles opp med tabell = dobletabell(tabell)). 18

21 8. Beskrivelse av Utvidelser Søkestreng settes inn i en String-tabell (tilsoketabell): Søkestrengen kan nå inneholde flere ord, de boolske operatorene AND og OR, og i tillegg mulighet for bruk av jokere (*) foran og bak deler av ordet. For å plukke ut ordene (inkludert alle ord som passer med prefiks-mønsteret), og for å bestemme hvilken type sammenligning som skal gjøres (AND eller OR), har vi laget en metode tilsoketabell som gjør om søkestrengen til en String-tabell med et fast format. Noen eksempler: Søkestrengen ord1 AND ord2, returnerer en tabell med 3 elementer: { ord1, AND, ord2. Søkestrengen ord1 ord2 returnerer tabellen { ord1, OR, ord. Dersom det er flere enn 2 ord, vil tabellen bygges på med alle ordene, alltid med annethvert element som AND eller OR. Søkestrenen hus* kan for eksempel returnere tabellen { husleie, OR, hustru, OR husvogn. Metodene and og or : For å finne hjemmesider hvor to ord finnes, har vi laget en metode and. For å finne hjemmesider hvor det ene eller det andre ordet (eller begge) finnes, har vi laget en metode or. Felles for disse to metodene, er at de tar imot to short-tabeller som parameter, og returnerer en short-tabell (som svar på den boolske sammenligningen). Figur 8.2 viser hvordan metoden flytter seg igjennom de to short-tabellene (1-5) ved å flytte den minste pekeren (svar-tabellen opprettes samtidig som sammenligningene gjøres): Figur 8.2: Boolsk sammenligning av short-tabellene Metoden prefikssufiks : Metoden prefikssufiks tar imot en tekststreng som enten er et prefiks- eller sufiksord, og returnerer en String-tabell med alle ordene som passer til dette søkemønsteret. Hvis ordet er et sufiksord inverters ordet, og videre søking gjøres i den inverterte ordliste-tabellen. Hvis ordet er et prefiksord gjøres søking i den normale ordliste-tabellen. Siden tabellene er sortert, kan binærsøk-metoden brukes for å finne en (eller annen) indeks i tabellen som passer med søkemønsteret (benytter String-metoden substring i binærsøk-metoden for å sjekke dette). Med utgangspunkt i denne indeksen, vil programmet søke seg igjennom ordlisten oppover (med stadig mindre indekser) til man finner indeksen til det første ordet som passer med søkemønsteret (start-indeksen). Når man vet start-indeksen, kan man begynne å søke igjennom ordlisten nedover igjen for å legge inn alle ordene som passer med søkemønsteret i String-tabellen (som til slutt trimmes og returneres). 19

22 8. Beskrivelse av Utvidelser 8.4 Tid for oppbygging og søking i datastrukturen Tidsforbruk ved oppbygging av datastrukturen i SearchCmd5 er todelt. Først leses fila inn i den samme datastrukturen som SearchCmd4 (bruk av hashingtabell) samtidig som alle unike ord legges inn i en String-tabell. Tidsforbruket for dette kan som tidligere beskrives som O(N). At tabellene dobles automatisk vil ikke ha nevneverdig stor innvirkning på tidsforbruket, maksimalt 2N. Når hele datafila er innlest, sorteres String-tabellen ved hjelp av sorteringsalgoritmen quicksort. Denne algoritmen kan beskrives som O(U log 2 U), hvor U er antall ord i tabellen. Tidsforbruket ved søking etter ett enkelt (helt) ord i datastrukturen kan beskrives som O(1). Det samme gjelder boolske søk, for eksempel med n ord: n O(1) = O(1). Ved boolske søk får vi i tillegg søketiden ved sammenligning av 2 Short-tabeller. O- notasjonen for dette blir O(a+b) hvor a og b er lengden på de to tabellene. Dersom for eksempel a >> b ville det vært bedre å implementere en sammenligning med sekvensiell gjennomgang av b og bruk av rekursivt binærsøk i a. O-notasjonen for dette ville blitt O(b log 2 a). Dersom man benytter prefiks- eller sufikssøk søker man i den sorterte tabellen med binærsøkmetoden. O-notasjonen for dette blir da O(log 2 U), hvor U = antall unike ord. 8.5 Plassbehov (RAM) Dersom vi tar utgangspunkt i plassbehovet for SearchCmd4, så vil vi ved SearchCmd5 få følgende plassbehov: Antallet Wordlist-objekter vil være det samme som for SearchCmd4. HTML-list-objektene vil forsvinne, og erstattes av en tabell med String-objekter (URL-adresser) og en tabell med short-variabler for hvert unike ord. I tillegg vil det bli opprettet en (sortert) String-tabell (egentlig en tabell med pekere til allerede eksisterende tekststrenger) over alle unike ord. For å få til sufikssøk har vi i tillegg opprettet en ny tekstreng som inneholder det inverse ordet for hvert unike ord (samtlige ord baklengs), og opprettet en (sortert) String-tabell med disse. Dvs. at plassbehovet for tekstrengene til de unike ordene vil fordobles. Hvert element i String-tabellen med URL-adresser vil ta opp 4 byte (størrelsen på en peker). Det vil bli et element pr. URL-adresse, noe som vil gi følgende plassbehov (h t1 ) for Stringtabellen (H = ant. URL-adresser): h t1 = 4 H [byte] (formel 8.1) Hvert element i short-tabellene som inneholder en link til riktig URL-adresse i URLtabellen har et plassbehov på 2 byte (størrelsen på en short-variabel). Hvert unike ord har sin egen short-tabell, og størrelsen på disse tabellene vil variere alt ettersom hvor mange hjemmesider ordet finnes på. Det vil ikke være noen fast formel på hvor stor plass alle disse short-tabellene har behov for. Dette skyldes at vi benytter en dobling av tabellstørrelsen når en tabell blir sprengt slik at det blir ledig plass i tabellen. Størrelsen på tabellen vil da være 20

23 8. Beskrivelse av Utvidelser større enn eller lik antallet URL-adresser på hvert ord (i tillegg så vil det første tabellelementet gå bort i å administrere neste ledige plass i tabellen). For å måle det totale plassbehovet for disse short-tabellene (h t2 ) har vi inkludere tellere i programkoden som holder rede på det totale antallet short-elementer (e). Det totale plassbehovet for URL-tabellene blir da: h t2 = 2 e [byte] (formel 8.2) Dersom vi fremdeles regner med at hashingtabellen har fast størrelse (5 000 bøtter; dvs. 20 KB), og vi ser bort fra boolske søk og prefiks-/sufikssøk vil datastrukturen ha følgende plassbehov: T = t + w + h t1 + h t [byte] (formel 8.3) Datafil Antall linjer (N) Ant. URL (H) Plass tekststrenger (t) Plass Wordlistobjekter (w) Plass URLadressetabell (h t1 ) Ant. shortelementer (e) Plass URLtabeller (h t2 ) Total plass (T) itcwww-small.txt KB 24 KB 0 KB KB 67 KB itcwww-medium.txt KB 309 KB 2 KB KB 862 KB itcwww-big.txt KB KB 38 KB KB KB Tabell 8.1: Plassbehov i minnet for datastrukturen i SearchCmd5 Hvis vi sammenligner SearchCmd4 med SearchCmd5 (short-tabeller kontra lenkede lister) ser vi bl.a. at plassbehovet for datastrukturen i SearchCmd5 blir kun 37% av plassbehovet for datastrukturen i SearchCmd4: Datafil Antall linjer (N) Plassbehov Plassbehov Plassbehov S5:S3 SearchCmd2 SearchCmd4 SearchCmd5 itcwww-small.txt KB 86 KB 67 KB 0,78 itcwww-medium.txt KB KB 862 KB 0,48 itcwww-big.txt KB KB KB 0,37 Tabell 8.2: Sammenligning mellom de ulike programmene Dersom vi hadde trimmet short-tabellene (dvs. laget tabellene akkurat store nok, og fjernet det første administrasjons -elementet som holder rede på første ledige plass i tabellen), ville antall short-elementer vært det samme som antall HTML-list-objekter i SearchCmd4 ( elementer for itcwww-big.txt ). I den store datafila ville vi da ha spart ytterligere 907 KB. Plassbehovet ved innlesning ville likevel vært like stort som før trimming. Vi har derfor ikke implementert dette i vår foreløpige løsning. 21

24 8. Beskrivelse av Utvidelser For å benytte prefiks og sufikssøk må vi opprette to ekstra String-tabeller (u t2 og u t2 ) som har samme størrelse som antall unike ord (U): u t = u t1 + u t2 = 4 U + 4 U = 8 U [byte] (formel 8.4) I tillegg må hvert unike ord opprettes en ekstra gang i minnet i omvendt (invers) rekkefølge for å kunne foreta sufikssøk. Ekstra plassbehov for tekststrenger (t 2 ) vil da bli: t 2 = 2 U [byte] (formel 8.5) Dersom vi tar utgangspunkt i tallene fra tabell 9.1 vil det totale plassbehovet for SearchCmd5 inkludert prefiks og sufikssøk (T 2 ) bli: T 2 = T + 8 U + 2 U = T + 10 U [byte] (formel 8.6) Datafil Antall linjer (N) Ant. Unike ord (U) Plass uten prefiks og sufiks (T) Ekstra plass (10 U) Plass inkl. prefiks og sufiks (T 2 ) itcwww-small.txt KB 15 K 82 KB itcwww-medium.txt KB 193 KB KB itcwww-big.txt KB 722 KB KB Tabell 8.3: Plassbehov for datastrukturen i SearchCmd5 inkludert prefiks- og sufikssøk 22

25 9. Avprøving 9. Avprøving I vedlegg E finnes en detaljert oversikt over alle tidsmålinger. Oppbygging av datastrukturen: SearchCmd2: Vi ser at dersom datamengde økes 53 ganger (small -> medium) økes innlesingstida 33 ganger (small -> medium); dvs. tilnærmet lineært forhold mellom økning av data og økning i innlesingstid. O-notasjonen O(N) stemmer altså bra. Innlesing av alle hjemmesidene (itcwww-big.txt) førte til at vi fikk avbrudd i programmet (Exception: OutOfMemoryError). SearchCmd3: Dersom datamengden blir stor, vil det ta veldig lang tid å lese inn datafila til denne datastrukturen. På vår datamaskin gjorde vi et røft overslag, og fant ut at innlesing av alle hjemmesidene (itcwww-big.txt) kanskje ville ta om lag 50 timer (over 2 døgn). Forholdet mellom innlesingstidene for small- og medium-fila skal i følge O-notasjonen O(N U) bli 678, og ble i praksis Vi betrakter dette som bra nok til at vi kan konkludere med at O- notasjonen stemmer. SearchCmd4: Vi ser at bruk av hashingtabeller i SearchCmd4 gir en stor tidsbesparelse ved innlesing av store datamengder. Vi konkluderer her med at O-notasjonen O(N) stemmer veldig bra med faktiske målinger (se vedlegg E). Søketid: Vi ser at på vårt system så vil tiden det tar å skrive ut URL ene ta en stor del av den totale søketiden for forholdsvis små datamengder. Hvis vi derimot søker etter ord som ikke finnes, får vi et mål på hvor lang tid man bruker på selve søket gjennom hele datastrukturen (uten å skrive ut URL er). Dersom vi i tillegg foretar en mengde søk etter hverandre og tar den totale tiden på disse søkene, får vi verdier som er enda mer fri for støy. Hvis vi sammenligner SearchCmd4 med SearchCmd2 og 3 (med og uten hashingtabell) ser vi at vi ved en overgang til hashingtabell får en drastisk forbedring av effektiviteten til selve søket. Hvis vi ser på søketiden etter et ord som ikke finnes, så viser det seg at den i praksis er uavhengig av datamengden (0-1 ms). Dette stemmer bra med O-notasjonen som tilnærmet er O(1), men som i praksis er O(w), hvor w er maksimalt antall Wordlist-elementer i hver bøtte (på hver indeks). Ut ifra målingene i vedlegg E konkluderer vi med at O-notasjonene stemmer bra for alle søkemetodene. 23

26 10. Softwaretest 10. Softwaretest Mange feil i programmer oppdages tilfeldigvis når programmet blir brukt, men feil kan finnes på en mer systematisk og effektiv måte enn tilfeldig eksperimentering. Det er målet med en softwaretest. Det finnes enkle systematiske teknikker for å finne semantisk feil. Et program kan være syntaksmessig riktig men gir feil svar allikevel, dette er semantisk feil. Det er to viktige teknikker for softwaretesting, strukturell- og funksjonstest. Disse teknikkene er beskrevet i vedlegg F. 11. Konklusjon En søkemotor er et informasjonssystem som skal holde rede på store mengder data, og som man er avhengig av at det gis rask aksess til. For å gi rask tilbakemelding på søk må man ha dataene tilgjengelig i hurtigminnet (RAM), og for å få plass til store mengder data i det begrensede hurtigminnet må man lagre data på en plassbesparende måte. Dette er utfordringer som vi trinnvis løser i denne prosjektoppgaven. En datastruktur som inkluderer bruk av hashingtabeller gjør det praktisk mulig å lese inn store datamengder til en datastruktur hurtig, og gjør det samtidig mulig å foreta hurtige søk. Dette skyldes at bruk av tabeller gjør at vi får direkte tilgang til minneadresser (i forhold til sekvensiell tilgang som enkeltlenkede lister gir deg), og at bruk av en hashingfunksjon gjør det mulig å få en enkel og direkte sammenheng mellom et ord og plasseringen (indeksen) i hashingtabellen (en god hashingfunksjon sørger for at elementene blir forholdsvis jevnt fordelt mellom bøttene ). For å få en plassbesparende datastruktur, inkluderer man bruk av flere koblede tabeller. I vårt tilfelle benytter vi heltallstabeller for å holde rede på indeksene til de hjemmesidene et ord finnes på (en heltallstabell for hvert unike ord). Disse indeksene kobles mot en Stringtabell som inneholder selve URL-adressene. Dette er den samme tankemåten som man bruker ved design av relasjonsdatabaser. Det viser seg at en datastruktur med heltallstabeller gir en stor plassbesparelse i forhold til en tilsvarende datastruktur med lenkede lister. 24

27 Vedlegg A Oppgavebeskrivelser Vedlegg A Oppgavebeskrivelser Oppgave 1 Oppgave 1 (SearchCmd) går ut på å kjøre programmet SearchCmd og forstå det som skjer i programmet. Programmet skriver ut på skjermen om ordet brukeren søker etter finnes eller ikke. Inputfila organiseres i en enkeltlenka liste ved innlesning. Oppgave 2 I oppgave 2 (SearchCmd2) skal programmet SearchCmd modifiseres slik at alle websider som inneholder ordet brukeren søker etter, blir websidens URL-adresse skrevet ut. Inputfila organiseres i en enkeltlenka liste ved innlesning. Oppgave 3 I oppgave 3 (SearchCmd3) skal datastrukturen ved innlesning endres slik at alle unike ord som finnes på websidene organiseres som en enkeltlenka liste (WordList). Ut fra hvert unike ord i WordList lages ei enkeltlenka liste (HtmlList) som inneholder pekere til de websidene hvor ordet finnes. Programmet skal skrive ut websidenes URL-adresser som inneholder ordet det søkes etter. Oppgave 4 I oppgave 4 (SearchCmd4) skal datastrukturen fra oppgave 3 modifiseres slik at man i stede for å lage èn sammenhengende lenket liste(wordlist) med de unike ordene som forekommer på websidene, organiseres disse ved hjelp av en hashtabell datastruktur. Programmet skal skrive ut websidenes URL-adresser som inneholder ordet det søkes etter. Utvidelser Den utvidede oppgaven (SearchCmd5) implementerer en plassbesparende datastruktur, automatisk dobling av tabeller samt utvidede søkefunksjoner som boolsk søking hvor man kan søke på flere ord, prefiks søking som gjør at man kan søke på ord som starter med ønskede bokstaver som for eksempel hus (hus*) og suffiks søking som gjør det mulig å søke på ord som slutter med ønskede bokstaver som for eksempel vogn (*vogn). Programmet skal skrive ut websidenes URL-adresser som inneholder ordene det søkes etter. A1

28 Vedlegg B Brukerveiledning og eksempler Vedlegg B Brukerveiledning og eksempler Ved å kjøre programmet via kommandolinje må man først kompilere (oversette) programmet. Kompilering utføres ved bruk av kommandoen javac og kan benyttes slik c:\>javac SearchCmd.java. Det forutsettes at path en er satt riktig under miljøvariabler i Windows 2000, og at fila SearchCmd.java i dette tilfellet ligger på c:. For å starte programmet benyttes kommandoen java og kan for eksempel skrives slik c:\>java SearchCmd c:\itcwww-small.txt Husk å angi riktig tekstfil som skal benyttes som datafil. Når programmet starter kommer teksten Søg efter : opp. Her skrives ordet det søkes etter etterfulgt av <Enter>. Programmet avsluttes ved å trykke <Enter> uten å angi søkeord. Figur B.1: Eksempel på søk i itcwww-small.txt B1

29 Vedlegg C Kravspesifikasjon (Input/output) Vedlegg C Kravspesifikasjon (Input/output) Kravspesifikasjon fellesdel Ved oppstart av programmet må man angi hvilken datafil som skal benyttes som datagrunnlag for å søke i (for eksempel en av de 3 datafilene som er vedlagt oppgave). Programmet leser da inn informasjonen fra den valgte datafila og lagrer den i datastrukturen. Kravet til datafila som leses inn er beskrevet i kapittel 3.1. Når programmet kjøres, kan man via tastaturet skrive inn et ord man ønsker å søke etter og trykke <Enter>. Programmet vil da gi beskjed om ordet det søkes etter finnes eller ikke. Dersom man trykker kun <Enter> avsluttes programmet. Det er ikke nødvendigvis noe krav om at det angitte ordet skal være uten mellomrom, men siden programmet kun vil søke etter et ord i gangen vil man ikke finne noe dersom man oppgir flere ord på et søk. Input fra tastaturet begrenses av størrelsen på standard input-buffer i klassen BufferedReader, men vi går ut i fra at denne størrelsen er mer enn nok (det var ikke mulig å finne noe tall på størrelsen: The default is large enough for most purposes ). Bruk av danske og norske spesialtegn (æøåæøå) på Windows 9x/NT/2000/XP går greit dersom datafila er lagret i MS-DOS -format (dette kan for eksempel gjøres i tekstbehandlingsprogrammet WordPad ). Kravspesifikasjon utvidelser Generelle krav: For å kunne kjøre programmet må filene Sort.class og BinarySearchRecursive.class befinne seg i samme katalog som SearchCmd5.class. Disse klassene inneholder metodene quicksort og binarysearch som brukes i programmet. Krav til datafil: Kravet til datafila er det samme som før (se kapitel 3.1), men i tillegg må antall URLadresser i fila ikke overstige Krav til søkeord: Boolsk søking gjøres ved å benytte ordene (operatorene) AND eller OR med store bokstaver, og med mellomrom mellom ordene og operator. Søkeordet må ikke starte med AND eller OR. Dersom flere ord skrives fortløpende med mellomrom, men uten en operator, tolkes dette som OR-søking ( ord1 ord2 blir det samme som ord1 OR ord2 ). Flere AND- og OR-sammensetninger kan gjøres i samme søketekst ( ord1 AND ord2 AND ord3 OR ord4 ). Bruk av paranteser i søketeksten er ikke mulig. Bruk av operatoren NOT er ikke mulig. Prefiks- og sufikssøk gjøres ved å bruke stjerne (jokertegn) rett etter eller rett foran deler av ord det skal søkes etter (uten mellomrom). C1