Systembeskrivning.

KTH Institutionen för Numerisk Analys och Datalogi Systembeskrivning RedInc www.nada.kth.se/projects/prom03/redinc Uppdragsgivare: Projektmedlemmar: Harald Kjellin Daniel Oscarsson Rikard Laxhammar Tommy Pettersson Thomas Jansson Karin Råde Ulf Rustas Emil Stridfeldt Mikael Nyqvist Alexander Ahl Stockholm 2004-05-15

Innehållsförteckning 1 Inledning...3 2 Översikt...3 2.1 Moduler...3 2.2 Samverkan mellan modulerna...3 2.3 Användning av systemet...4 3 Modulernas implementation...4 3.1 XML-lagret...4 3.1.1 RedInc:s DTD...5 3.1.2 RedInc:s XML-fil...6 3.2 Databas...6 3.2.1 Area...7 3.2.2 Template...7 3.2.3 RedIncUser...7 3.2.4 Object...7 3.2.5 Attribute...7 3.2.6 AttributeValue...7 3.3 Programlogik/Servlet-lagret...7 3.3.1 RedIncParser...8 3.3.2 Servlets...8 3.3.3 Flödesdiagram...8 2

1 Inledning Detta dokument är en systembeskrivning över RedInc. RedInc är en generell inkrementell webbdatabas, som möjliggör för småföretag att utifrån en generell plattform modulera en webbdatabas efter egna önskemål och behov före och under drift. Dokumentet riktar sig till den som vill förstå hur RedInc är uppbyggt tekniskt. Här presenteras en överblick av systemets olika delar, hur de samverkar, hur systemet är tänkt att användas samt en djupare inblick i varje moduls funktionalitet och uppbyggnad. 2 Översikt I detta avsnitt ges en enkel översiktlig bild av systemet. Hur det är uppbyggt, samspelet mellan delarna och hur systemet är tänkt att användas. 2.1 Moduler RedInc:s idé bygger på tre delar; en generell plattform, en inkrementell databas, som kan nås via Internet. RedInc består därför av tre lager eller moduler: XML-lager, Databas, Programlogik / Servlet-lager. XML-lagret motsvarar den generella plattformen. Här specificeras funktioner och utseende på gränssnittet. Lagret innehåller två komponenter, en XML-fil (därav namnet på lagret) samt en DTD, (Document Type Definition). DTD:n fungerar som ett ramverk för XML-filen, som måste följa DTD:n. Databasen är kort och gott en databas där data lagras, hämtas eller ändras. Den är inkrementell, dvs antalet attribut och tabeller kan förändras under drift efter önskemål och behov. Kommunikationen mellan modulerna, och mellan systemet och slutanvändare via nätet sköts av Programlogik / servletlagret. Här parsas XML-sidorna så att databasen initieras och användargränssnittet skapas automatiskt mot slutanvändaren. 2.2 Samverkan mellan modulerna Ett XML-dokumentet parsas av en javaparser i Programlogiklagret när administratören har gjort en uppdatering. Programmet genererar de htmlsidor och script som utgör slutanvändarens kontakt med systemet. Servletlagret styr hur data skall skickas mellan de olika lagren, t.ex. vid en sökning där slutanvändaren skriver in sina sökparametrar som sedan skickas till lagret där dessa sätts in i SQL-satser och körs mot databasen. Svaret från 3

sökningen skickas sedan tillbaka och presenteras för slutanvändaren på html-form, genererad av servletlagret. 2.3 Användning av systemet Systemet har två användare; administratörer och slutanvändare. Det är XML-lagret som är administratörens kontaktyta mot systemet. I denna kan administratören editera XML-dokumentet för de funktioner som skall finnas i det specifika systemet. Administratören kan alltså med stor frihet utveckla ett specifikt system inom det givna ramverket, som specificeras av DTD:n. Därefter genomför administratören parsningen och systemet är färdigt att användas av slutanvändaren. Figur 1 visar hur interaktionen mellan systemet å ena sidan och administratör och slutanvändare å andra sidan fungerar. Administratör XML -fil DTD RedInc Klient/Webbrowser Webbserver Programlogik/Servlet Slutanvändare Databas Figur 1. Moduler och användare 3 Modulernas implementation I detta avsnitt betraktas de olika systemdelarna XML-lagret, databasen och programlogik/servletlagret mer ingående. Deras syfte, design och implementation beskrivs. 3.1 XML-lagret Syftet med det här lagret är att vara plattformen för RedInc, som efter specificering anger funktionalitet och gränssnitt mot slutanvändaren. Modulen består därför av två delar; en definition som ger ett ramverk för den andra delen, innehållsspecifikationen. Detta lager utgör administratörens möjlighet att styra vilken funktionalitet systemet skall ha. 4

Språket som använts för att implementera lagret är XML (därav namnet för lagret), vilket lämpar sig mycket väl för utbyte av information. XML är primärt en metod att sätta in data i en textfil. En XML-fil kan sedan specificeras av en dokumenttypsdefinition, DTD, dvs utgöra ett ramverk som talar om vilka dataelement som skall framträda i ett XML-dokument. RedInc har dels detta ramverk, dels en XML-fil. 3.1.1 RedInc:s DTD RedInc:s DTD har namnet Knowledge Base.dtd, och definierar dels vilken data som skall lagras i databasen, dels vilken funktionaliteten i systemet. Definitionen av data representeras av KB_DEF, som beskriver vilka objekttyper (templates) och attribut som lagras i databasen. KB_DEF beskriver också objekttypernas innehåll, dvs vilka underobjekttyper och dess attribut de innehåller. KB_DEF är enbart definierad av subelementen TEMPLATE och ATTRI- BUTE, och deras tillhörande attributlistor och subelement. TEMPLATE- och ATTRIBUTE-elementen kan förekomma i godtyckligt antal i XML-filen. Varje objekttyp identifieras unikt av dess namn med attributet template_name. Likaså gäller att varje attribut som ingår i databasen identifieras av dess namn med attributet attribute_name. Dessa måste explicit finnas i XML-filen. Objekttypernas subelement PROPERTY och SUB_PART är referenser till ATTRIBUTE and TEMPLATE objekten, och definierar vilka attribut och objekt av subelement som definierar objekt av en given objekttyp. RedInc tillhandahåller i nuvarande form tre huvudsakliga funktioner. Dessa är sökfunktionerna General Search, som är en generell sökning, och Specific Template Search, som är en specifik sökning, samt gränssnittsfunktionen Show object details. General Search kan ha upp till fyra olika fält för att söka på attributvärden, objekttyper (templates) och attributtyper (attributnamn). Det fjärde fältet används för att söka bland alla dessa. Specific Template Search används för att söka på en viss bestämd objekttyp. Detta bestäms av administratören på förhand, som genom XML-filen anger vilka attribut som slutanvändaren skall kunna söka på. I fältet för ett inkluderat attribut skriver slutanvändaren in det eller de attributvärden han/hon vill söka på. När slutanvändaren verkställer en sökning, oavsett sökfunktion, genereras en resultatlista. Administratören specificerar med Show object details vilka attribut hos de olika objekttyperna som skall visas. 5

3.1.2 RedInc:s XML-fil XML-filen knowledge-base.xml är administratörens huvudsakliga kontaktyta med RedInc. Här specificerar administratören vilken funktionalitet och data som skall visas för slutanvändaren. Denna specificering valideras av DTD:n. Innehållet i denna fil är således väldigt varierande utifrån varje enskilt behov, men måste alltid följa DTD-mallen. 3.2 Databas Realiseringen av ett dynamiskt inkrementellt databassystem kräver en relationsdatabas i grunden som beskriver relationerna mellan objekt, attribut, relationer, mallar, datatyper, osv. för all data vi vill lagra, dvs en databas som både hanterar data och metadata. Figur 2 nedan är en konceptuell bild av hur databasen ser ut. Figur 2. Diagram över databasen Databasen är skriven för att kunna köras i PostgreSQL. Som den är skriven idag fungerar den enbart i PostgreSQL. Den konceptuella modellen kan dock implementeras på vilken SQL-databas som helst så framtida versioner av systemet ska kunna skrivas oberoende av databastyp. Mycket av kommunikationen till och från databasen sker via ett lager stored procedures, dvs namngiva funktioner lagrade i databasen. Det ger databassystemet möjlighet att effektivare optimera uppslagen. Dessutom är det ett abstraktionslager, som ger mer möjlighet att kunna ändra implementationsdetaljer med minimala eller inga ändringar i det övriga systemet. Nedan är en kort sammanfattning av de olika tabellerna av hela databasens implementation. 6

3.2.1 Area Man ska kunna slå ihop flera gamla databaser till en samlingsdatabas i detta system. Dessa gamla databaser kan ha tabeller som heter likadant, så tabellen Area kan fungera som en mekanism för att undvika namnkrockar. Exempel: lönesystem, lagerregister. 3.2.2 Template Mallar för de objekt som man kan ha i databasen. Tillhör en Area. Alla objekt har en template som typ. Exempel: bil (i lagerregister), anställd (i lönesystem) 3.2.3 RedIncUser RedIncUser har namn och lösenord och kan äga objekt. Ägandeskap över objekt kan ev. leda till att man kan göra mer med dessa objekt än de slutanvändare som inte är ägare av dem, typ ta bort dem, etc. Det finns dock inte nu några sådana regler inlagda i själva databasen. 3.2.4 Object En instansiering av en objekttyp (template). Skillnaden mellan tabellerna Template och Object är skillnaden mellan begreppet bil och en specifik bil. Bil i Template anger vilka egenskaper och deras lagringstyper som bilar har, t ex typ: färg(kort text), däckstorlek(heltal) och motortyp (Object) för bilar. I bil i Object anger man vilka värden för dessa attribut en särskild bil har t ex (Svart, 19, ABC123). Man lagrar också en ägare, dvs antagligen den person som skapade objektet och som förmodligen har särskilda rättigheter över det. 3.2.5 Attribute Superklass för alla Attribut. Innehåller bara namn och en förklaringstext. Attribut kan tillhöra flera Templates. Attribut som personnummer och efternamn förekommer säkert i flera objekt. Exempel: Personnummer, Efternamn, Postadress, Däckstorlek. 3.2.6 AttributeValue Superklass för Attributvärdena. Innehåller bara en koppling mellan en attributtyp och ett objekt. Lagrar värdena för objekten. 3.3 Programlogik/Servlet-lagret Denna modul har två stora uppgifter. Den skall göra om XML-filer till htmlkod, som är grunden för webbgränssnittet för slutanvändaren, och konceptuella tabeller, metadatan för databasen. Detta görs av programmet RedIncParser. Dessutom skall modulen kommunicera med databasen genom html-sidorna. Detta görs med hjälp av servlets. Systemet är utvecklat och testat på en Tomcat-server, som webbserver, varvid endast denna typ av server hittills kan sägas vara den typ av server som system fungerar på. 7

3.3.1 RedIncParser Programmet RedIncParser.java läser in en XML-fil med mallar för hur databasens innehåll ska se ut. Mallarna verifieras gentemot DTD:n (se ovan), Knowledgebase.dtd, för att säkerställa att XML-filen är korrekt uppbyggd. Till exempel, tröja, som beskrivs i följande XML-fil: <TEMPLATE templateid = "troja"> <PROPERTY attribute = "material"></property> </TEMPLATE>... <ATTRIBUTE attributeid = "material"></attribute> I RedIncParser skapas ett object av den egna typen ObjectBase, i vilken objettyper och attribut sparas som egna datatyper i två hashtabeller. Där läggs troja in som objekttyp och material in som attribut och det skapas en koppling mellan troja och dess attribut material. Hashtabeller används sedan för att skapa tabeller i databasen, via programmet Database.java. I detta program används funktioner från DataLayer_PostgreSQL.java för att kommunicera med databasen. Enligt ovanstående exempel skapas tabellen troja med attributet material. Programmet RedIncParser skapar också html-sidor för inmatning och sökning i databasen för dessa mallar. För vårt exempel skapas t ex sidorna troja_insert.html och troja_search.html med ett inmatningsfält material för attributet. 3.3.2 Servlets Slutanvändaren kommunicerar med RedInc via html-sidor skapta av RedIncParser. Sidorna kommunicerar i sin tur med databasen via servlets. Dessa är programmerade i huvudsak i java med vissa slag av html-kod. Beroende på vilken funktionalitet som används av slutanvändaren används olika servlets. De servlets som finns är för operationerna: insättning, specifik sökning, generell sökning editering, radering Om vi vill lägga till en tröja i vårt exempel går vi till troja_insert.html och skriver in bomull i fältet för material. Servleten för insättning anropas då med information om både template- och attributnamn samt instansen bomull. Därefter läggs instansen i databasen. 3.3.3 Flödesdiagram Nedan visas ett flödes diagram, som visar gången för insättning av ett objekt 8

Slutanvändare Programlogik/Servlet Databas Klickar på länk för insättning Levererar html-sida specificerad enligt XML-fil, med formulär för insättning. Matar in värden Html-sidan anropar insättningsservlet med värden Servlet för insättning tar emot data och sänder till databasen Databasen lägger in data. Servlet för insättning redovisar resultatet av insättningen via htmlsida Resultatet visas. Figur 3. Flödesdiagram för insättning av element i databasen 9