Programutvecklingsprojekt 2D1954 - FairWay FairWay 1.0 SDD Systemdesignbeskrivning Av: Åke Djärf Stockholm, 1 maj 2000
Innehåll 1 Inledning...3 1.1 Syfte...3 1.2 Tillämpning...3 1.3 Revisionshistorik...3 1.4 Definitioner och förkortningar...4 1.5 Dokumentöversikt...4 2 Referenser...5 3 Övergripande konstruktionsbeslut...5 3.1 Allmänt...5 3.1.1 Dokument...5 3.1.2 Funktioner...5 3.1.3 Datormiljö...6 3.1.4 Användare...6 4 Arkitektur...7 4.1 Komponenter...7 4.1.1 Client...8 4.1.2 ClientHandler...8 4.1.3 Calc...8 4.1.4 Controller...8 4.1.5 InfoController...8 4.1.6 GenTool...9 4.1.7 CalcDataModel...9 4.1.8 PathDataModel...9 4.1.9 PreCalc...9 4.1.10 PreCalcData... 10 4.1.11 BaseData... 11 4.2 Gränsytor... 11 5 Kravspårbarhet... 11 2
1 Inledning 1.1 Syfte Syftet med detta dokument är att utgöra en beskrivning av FairWaysystemet i sin helhet, att vara huvuddokument vad avser systemdesign samt att vara sammanhållande dokument för de olika SSDD (Sub System Design Description) som mer i detalj beskriver design av ingående delkomponenter. 1.2 Tillämpning Tänkta användare av detta dokument är i första hand projektgruppen själva. Detta dokument är styrande vad avser systemdesign. 1.3 Revisionshistorik Datum Utfärdare Beskrivning 00-02-27 Åke Djärf Dokumentet upprättat 00-02-29 Åke Djärf Ändrat i enlighet med möte 000229 00-04-27 Åke Djärf Slutlig version framställd 00-04-27 Kristoffer Andersson Tillägg i InfoController och PreCalc 3
1.4 Definitioner och förkortningar Begrepp Förklaring BaseData Grundläggande information avseende en mässa/ utställning. Denna information består t.ex. av en karta över utställningsområdet, namn och beskrivning av alla utställare och koordinater för dessas fysiska placering i lokalen. Calc Huvudsaklig beräkningsmodul. Denna modul beräknar den kortaste väg en besökare måste ta givet en lista över platser som skall besökas. Client Den dator/ applikation/ motsvarande där användaren interagerar med FairWay-systemet. ClientHandler Den delmodul som direkt kommunicerar med användaren. Controller Kontrollmodul som givet en arbetsbegäran från ClientHandler begär beräkning av Calc-modulen. CalcDataModel Uppläst grunddata för beräkning. Detta är en wrapper -klass runt den distansmatris som skapats av PreCalc-modulen. PathDataModel Uppläst grunddata för beräkning. Detta är dels en wrapper -klass runt den närmaste-grann matris som skapats av PreCalc-modulen och dels den modul som beräknar/ infogar de mellanliggande noder som krävs för att erhålla en fullständig tur. InfoController En wrapper runt BaseData. Tanken med denna modul är att säkerställa kontroll över det antal sessioner/ motsv som samtidigt är aktiva mellan ClientHandler och BaseData. PreCalc Administrationsmodul som i förväg utför vissa grundberäkningar. PreCalc data Lagrat utdata från PreCalc Server Den dator/ applikation som interagerar med användaren och där beräkningar, lagring av BaseData m.m. görs. OCR Optical character recognition 1.5 Dokumentöversikt Detta dokument är som tidigare nämnts huvuddokument vid design. Varje delkomponent/ modul har sin egen beskrivning (SSDD), där detaljnivån är högre. 4
2 Referenser Nedanstående lista beskriver de dokument som refereras från detta dokument, antingen som styrande dokument eller som utgör detaljspecificering av detta dokument. [1]. Kravspecifikation [2]. Analys [3]. SSDD Calc [4]. SSDD Client [5]. SSDD ClientHandler [6]. SSDD Controller [7]. SSDD InfoController [8]. SSDD PreCalc [9]. IDD 3 Övergripande konstruktionsbeslut 3.1 Allmänt För att kunna säkerställa att detta uppdrag blir genomförbart och användbart inom den tidsram som satts upp i kravspecifikationen har vi blivit tvungna att ställa upp en del avgränsningar på systemet. Dessa är satta på ett sätt som gör att de, om de följs, ger en minimal och generell lösning på problemet. Avsikten med att bara utveckla en prototyp är att fokus ska ligga på basfunktionaliteten och att vi därefter ska kunna bygga ut systemet till en färdig produkt. 3.1.1 Dokument Ett av kraven i kravspecifikationen är att engelska ska användas i all kod samt i alla leveransdokument. För att projektet inte ska fastna eller dra ut på tiden, på grund av nyttjandet av ett språk skiljt från modersmålet i all dokumentation, kommer de dokument som produceras av projektgruppen men som inte ingår i leveransdokumenten att skrivas på svenska. 3.1.2 Funktioner Systemet ska kunna läsa in statiska indata beskrivande mässan, företagen och deras position i mässlokalen. För att förenkla inläsningen behöver grundsystemet bara stödja indata på textformat. Systemet behöver alltså inte ha någon funktionalitet liknande optisk teckenigenkänning (OCR). 5
Problemet att finna den kortaste vägen genom mässlokalen som passerar alla av användaren utvalda utställare är en variant av ett välkänt och beräkningstungt problem, nämligen TSP (Traveling Salesman Problem). Detta innebär att lösningsförslaget med största sannolikhet måste begränsas till en approximation av den kortaste vägen. För att få fram denna approximation kan vi utnyttja oss av någon av de approximationsalgoritmer som finns för att lösa TSP. Presentationen av lösningsförslaget ska helst ske genom att vägen ritas ut på en karta på skärmen. Det räcker dock med en vägbeskrivning i textformat, t.ex. en lista med alla utställare som måste passeras innan man kommer fram till de utvalda utställarna. För att minska tidsåtgången för beräkningen av den approximativt optimala vägen bör systemet göra lämpliga förberäkningar vid uppstart och inläsning av indatat. 3.1.3 Datormiljö Systemet skall vara portabelt och inte bundet till någon speciell typ av operativsystem. Vi har därför beslutat att göra det Web-baserat, men att det enkelt ska kunna vidareutvecklas för att tillgodose andra användargränssnitt. Eftersom ingen betalning för systemet är garanterad, bör utvecklarna så gott som det går hålla sig till det som är gratis. Utvecklingsspråk kommer därför med största sannolikhet vara Java. 3.1.4 Användare Det förutsätts att mässbesökaren vet vilka företag som han/hon vill besöka, inte bara vilken bransch som företagen ska tillhöra. Den tekniskt ansvarige, som sköter inläsningen av mässbeskrivningen i systemet, ska kunna överföra mässbeskrivningen på det textformat som grundsystemet kräver. 6
4 Arkitektur Systemet är, om inte per definition, så i alla fall till sin idé ett fleranvändarsystem där ett antal klienter via en URL kan ansluta till en applikationsserver för att få tillgång till mässinformation i form av utställarförteckning, orienteringskarta. Klienten (användaren) skall kunna välja den/de utställare som han/hon önskar besöka och till svar erhålla en karta med den kortaste vägen mellan valda utställare. Den presenterade vägen skall börja och sluta i en fördefinierad start-/ slutpunkt. Inom ramen för detta projekt skall ett enanvändarsystem implementeras, men systemet skall designas så att skalbarhet erhålls. indata Client Server Base data resultat Bild 1. Övergripande systemstruktur. 4.1 Komponenter Bild 2. Översikt av delsystemstruktur. 7
4.1.1 Client Client är ingen egentligen del av FairWay utan är snarare ett samlingsbegrepp som innefattar alla typer av HTTP baserade klientprogramvaror såsom Netscape och Internet Explorer. Även WAPtelefoner är en typ HTTP baserade klienter och innefattas således av Client. 4.1.2 ClientHandler Detta är det delsystem som kommunicerar med Client och med FairWays innre kontrollsystem (InfoController och Controller). Då ClientHandler skall kommunicera med Client via HTTP skall ClientHandler implementeras med hjälp av Java Servlets teknologi. ClientHandlern tar emot en HTTP-request från klienten (POST eller GET). Denna begäran utgörs av oftast av en lista över de utställare som klienten önskar besöka. Denna begäran vidarebefordras till Controller för behandling. När (TSP-) beräkningen är klar, returnerar Controller den kortaste vägen mellan angivna utställare. ClientHandler utför även saker såsom att rita kartor och presentera listor över tillgängliga utställare för Client. Detta görs på kommando av Client, varvid ClientHandler måste kommunicera med InfoController för att rekvirera lämpliga data. 4.1.3 Calc Detta är den modul där TSP- beräkningen utförs. Indata är de noder som användaren önskar besöka och utdata är den ordning i vilken dessa noder skall besökas. Calc skall använda en s.k. farthest-insertion algoritm [3] för att utföra denna beräkning. Att observera är att detta endast är en del av den fullständiga beräkningen, se även Controller. 4.1.4 Controller Controller anropar Calc och begär en lösning av probleminstansen. Returvärdet från Calc skickas till PathDataModel så att mellanliggande noder kan beräknas/ insättas i turen för att på så sätt erhålla den kompletta tur som skall returneras till ClientHandler. 4.1.5 InfoController InfoController är en wrapper runt BaseData och gör det därmed lättare att växla representationen av BaseData. Den ser till att 8
abstraktionsnivån ökar och gränssnitten mot ClientHandlern, PreCalc och GenTool blir gemensamt och enkelt. InfoController är tänkt att dels leverera karta och aktuell utställarinfo till ClientHandler samt indata till PreCalc. GenTool ska ges stora möjligheter att hämta, ändra och lägga till information. 4.1.6 GenTool GenTool är ett administratörsgränssnitt som skall användas när man matar in en mässa i systemet. Man kan i det tala om var montrar, gångar och entréer finns och hur man kan gå mellan dessa. Man kan även mata in information om de olika utställarna. 4.1.7 CalcDataModel Detta är endast en wrapper-klass runt den distansmatris (avståndet mellan samtliga noder i grafen) som förberäknats av PreCalc. Denna CalcDataModel skickas efter initiering som argument till Calc. 4.1.8 PathDataModel PathDataModel är dels en wrapper runt den närmaste-granne matris som förberäknats av PreCalc, men modulen utför även de beräkningar som krävs för att, givet en lösning från Calc, sätta in de mellanliggande noder som krävs för att erhålla en komplett tur mellan de noder som mässbesökaren önskar besöka. 4.1.9 PreCalc Detta är en administrationsmodul som skall göra nödvändiga förberäkningar/modifieringar av BaseData så att den beräkning som Calc skall göra går så snabbt som möjligt. De förberedande beräkningar som skulle kunna göras av PreCalc är att beräkna närmaste vägen från nod x till samtliga övriga noder och spara resultatet som en kvadratisk matris. (Mycket) preliminär algoritmbeskrivning: Givet BaseData som består av: - kartan över utställningsområdet med montrarna - uppgifter om montrarnas placering i utställningshallen - uppgifter om vägarna mellan montrarna - uppgifter om utställarna skall PreCalc plocka ut: 9
- grafens noder (dessa kan tidigare ha tagits fram manuellt eller automatiserat ur kartan och lagts i BaseData) - en grannlista (dessa kan tidigare ha tagits fram manuellt eller automatiserat ur kartan och lagts i BaseData) och beräkna: - kortaste avståndet mellan alla noder - vägen som utgör det kortaste avståndet Om mässan innehåller n noder (montrar och vägkorsningar) erhålls två n 2 - matriser. I bild 3 torde den kortaste vägen mellan A och F vara A-B-C-E-F, med en totallängd av 30. Nodernas koordinater ges av (x,y) och kanterna ges av möjliga gångvägar enligt kartan. 5 E 18 22 F C 2 D 14 5 9 A 2 B Bild 3. Exempel på kortastevägen instans. Den erhållna n 2 - matrisen sparas i PreCalcData och läses in vid systemstart. Baserat på denna matris utförs den begärda TSPberäkningen. Denna beräkning tolkar n 2 - matrisen enligt bild 4. F 30 A Bild 4. Exempel på TSP-avstånd. 4.1.10 PreCalcData PreCalcData ska innehålla en distansmatris, med kortaste avstånden mellan alla noder, och närmaste-väg matris, som beskriver hur den närmaste vägen mellan alla noder går. Datat sparas i form av en fil. 10
4.1.11 BaseData BaseData är en vanlig databas som vi har valt att använda den fria motorn Hypersonic SQL till. Den stödjer det mesta av SQL-standarden och har flera möjliga anslutningssätt, vi ansluter via http-protokollet. 4.2 Gränsytor Gränsytor mellan delkomponenter framgår av Konstruktionsbeskrivning, interna gränssnitt (IDD). 5 Kravspårbarhet Spårbarhet mellan krav och delkomponent framgår av respektive delkomponents SSDD. 11