Systemförvaltning. Sammanfattning. Redaktör: Kjell Enblom Version: 1.0 Datum: I Tal-Lab kan ingen höra dig skrika

Transkript

1 I Tal-Lab kan ingen höra dig skrika Systemförvaltning Redaktör: Version: 1.0 Datum: Sammanfattning STUM är ett system för talsyntes. Det utvecklades åt avdelningen för Human- Centered Systems (HCS) vid (IDA) vid Linköpings Tekniska Högskola. Syftet med projektet STUM var att utveckla en applikation för att utvärdera en ny metod för talsyntes. Detta dokument beskriver hur systemet är designat och implementerat. Dokumentet tar upp vad som behöver kännas till för att kunna installera, underhålla och vidareutveckla systemet.

2 Projektidentitet Projektgrupp STUM Linköpings tekniska högskola (IDA) Projektmedlemmar Namn Ansvarsområde Telefon E-post Ali Aghajani Projektledare Dokumentansvarig Filip Klasson Kvalitetsansvarig Johan Millving Designansvarig Andreas Rasmussen Implementationsansvarig Gustav Veide Systemansvarig Patrik Sandström Kundansvarig Thomas Janowski Testansvarig E-postlista för hela gruppen Hemsida www-und.ida.liu.se/~pum1 Kund Kundkontakt Bertil Lyberg, Mustapha Skhiri, Handledare Sten Sunnergren, Examinator och kursansvarig Robert Kaminski, IDA

3 Dokumenthistorik Version Datum Utfärdade ändringar Utfärdade av Dokumentet påbörjades Efter kommentering: Rättat stavfel. Ändrat så att alla URL:er är i Courier. Ändrat så att datorkommandon är kursiva. Lade till i 3.2 att inga kända fel finns. Lade till nackdel med att inte kontrollera ljudformat för alla ljuddata. Lade till Testrapport i kapitlet referenser. Lade till beskrivningar av klasserna Processor, ProcessorCore, Synthesizer, SynthesizerCore, Visualizer och VisualizerCore i kapitel Efter inspektion: Rättat stavfel. Tagit bort 4.2 som inte längre är giltigt. Justerat layouten på figur 1. Ändrat så att STUM står med versaler konsekvent genom hela dokumentet. ii

4 iii

5 1 Inledning Syfte Läsanvisningar Dokumentöversikt Dokumentberoende Distribution Förklaring av begrepp Systemöversikt Inledning Bakgrund Syfte Övergripande beskrivning Användare Programspråk Systemkrav Moduler Begränsningar Databasen Restlista Ej uppfyllda krav Kända fel Nödlösningar Nya ljudfiler via det grafiska databasgränssnittet Utökningar och förbättringar Databasen Problem Förbättringsförslag: Extern databas Förbättringsförslag: Indexering av externa filer Synthesizer Förbättringsförslag: Datacache DataBaseGUI Problem Förbättringsförslag Installation och vidareutveckling Källkod Installation Krav Kompilering Starta användargränssnittet Starta grafiska databasgränssnittet Starta konsoldatabasprogrammet Vidareutveckling Katalogstruktur Klasser J2SE Databasen iv

6 6.6.5 Javadoc Ansiktsdata Testning Referenser Externa dokument Interna dokument Källhänvisning Refererade dokument Bilaga A Javadoc v

7 1 Inledning Detta kapitel beskriver dokumentets upplägg och innehåll samt innehåller generell information om dokumentet. 1.1 Syfte Dokumentets syfte är att ge en beskrivning av det implementerade STUM-systemet för att kunna installera, underhålla och vidareutveckla det. Dokumentet vänder sig i första hand till tekniker som skall installera STUM och till tekniker och utvecklare som skall underhålla och vidareutveckla det. 1.2 Läsanvisningar För att få en snabb översikt över vad dokumentet innehåller rekommenderas kapitlet Inledning avsnitt 1.3 Dokumentöversikt. För att få en översikt över vad STUM är och hur det är uppbyggt rekommenderas kapitel 2 Systemöversikt. För att få en mer detaljerad bild av hur systemet installeras och vidareutvecklas rekommenderas kapitel 6 Installation och vidareutveckling. Kapitel 1: Inledning 1

8 1.3 Dokumentöversikt 1. Inledning Detta kapitel beskriver dokumentets upplägg och innehåll samt innehåller generell information om dokumentet. 2. Systemöversikt Innehåller en övergripande beskrivning av hur systemet är uppbyggt och strukturerat. Systemöversikten går bland annat igenom vilka moduler STUM består av, vilket programspråk det är utvecklat i och vilka begränsningar som finns. 3. Restlista Beskriver krav som inte har blivit implementerade och tar upp kända fel och begränsningar. 4. Nödlösningar Beskriver den nödlösning som finns som gäller inläggning av nya ljuddata via det grafiska gränssnittet. 5. Utökningar Beskrivning av utökningar och förbättringar som projektgruppen och kund har kommit på under projektets gång. 6. Installation och vidareutveckling Beskrivning av hur systemet kompileras och installeras och en beskrivning av systemet för den som ska vidareutveckla STUM. 7. Testning Beskrivning av hur testning av delarna i STUM har utförts och kan utföras. 8. Referenser En lista med referenser. Bilaga A: Javadoc Javadoc för alla klasser och metoder. 2 Kapitel 1: Inledning

9 1.4 Dokumentberoende Inga andra dokument är beroende av detta dokument. 1.5 Distribution Detta dokument kommer att distribueras till följande: Dokumentexaminatorerna Thomas Gustafsson och Angela Johansson. Projektgruppens handledare Sten Sunnergren. Kunden, kontaktpersoner Bertil Lyberg och Mustapha Skhiri. Projektgruppens dokumentpärm. Kapitel 1: Inledning 3

10 1.6 Förklaring av begrepp I det här avsnittet defineras begrepp som förekommer i dokumentet. Derby Difoner Javadoc Java Swing JDBC JVM Konkatenering Orator Stavelser Tal Tallabbet Talsyntes Talsyntesmotor Uppmärkt ord Derby är en databasimplementation helt skriven i Java som kan köras utan någon extern server-process. Delbitar av stavelser. Dokumentation som ligger i programkodsfilerna som beskriver klasser, metoder och attribut. Den färdiga dokumentationen sparas i HTML-format. Javabibliotek för att skapa grafiska gränssnitt. Java Database Connectivity, ett javagränssnitt mot databaser. Virtuell javamaskin i vilken den kompilerade javakoden körs. Sammanslagning av data. Orator är ett talsyntessystem som bygger på konkatenering av difoner. I Orator finns ett animerat ansikte för uppspelning av rörelser. Delbitar av ord. T ex är ordet flickan uppdelat i två modifierade stavelser, flik och kan. Här avses ljudet av ord och satser. Ett rum på där det finns utrustning för att spela in tal- och rörelsedata. Metoder för att generera mänskligt tal på syntetisk väg med hjälp av datorer. Metoden som är aktuell för detta projekt är talsyntes genom konkatenering av ord och stavelser. Den del av systemet som genererar talet. Uppmärkningen av ett ord beskriver hur ett ord betonas. Samma ord låter alltså olika beroende på hur det är uppmärkt. Tabell 1: Förklaring av begrepp 4 Kapitel 1: Inledning

11 2 Systemöversikt 2.1 Inledning Bakgrund På avdelningen för Human-Centered Systems bedrivs bland annat forskning om talsyntes. Deras forskning avser talsyntes genom konkatenering av ljudfragment inspelade av en människa och lagrade i en databas. Kunden har sedan tidigare ett färdigt system för animering till inkommande talspecifikation, kallat Orator [Projekt Orator, 2005]. Talsyntesen som styr Orator bygger på difoner. I Orator spelas talsyntesen upp som tal samt rörelser på ett animerat ansikte. Kunden var intresserad av ett liknande talsyntessystem som bygger på konkatenering av uppmärkta ord och stavelser. Detta till skillnad från Orator som är uppbyggt av ännu mindre delbitar av ord dvs difoner. Kunden ville att systemet som projektgruppen fick i uppdrag att utveckla i framtiden skall vidareutvecklas till ett helt eget system. Kravet var att systemet skall kunna spela upp både tal och rörelser med en talsyntes som i slutändan svårligen kan skiljas från den individ som genererat taldatabasen Syfte Kunden ville att projektgruppen skulle utveckla ett system som skall bli den första byggstenen i ett större system för talsyntes. Målet med det här projektet var att bygga upp en databas med tal och rörelsemönster samt skapa ett färdigt, separat system som kan spela upp konkatenerat tal. Kundens huvudsakliga mål var inte att få en talsyntes av hög kvalitet utan ett system för att testa en annan typ av talsyntes än den som de använt tidigare. Det är under dessa premisser projektet har utvecklats. Följande avsnitt beskriver hur systemet är uppbyggt. 2.2 Övergripande beskrivning Tanken är att en användare skriver in en sekvens av ord samt en uppmärkning för dessa. Resultatet blir att systemet spelar upp ljud motsvarande användarens sekvens av ord. För att göra detta skall systemet gå igenom indatat ord för ord, leta upp rätt ord i databasen, hämta ut motsvarande data och slutligen konkatenera ihop datat. När samtliga ord gått igenom denna process skall ljudet spelas upp. Om en sökning på ett ord misslyckas skall systemet dela upp ordet i stavelser och på samma sätt söka efter stavelser och sedan sätta ihop dessa till det ursprungliga ordet. Kapitel 2: Systemöversikt 5

12 Ta ut ord Konkatenera tal Spela upp Sök ord Sista ordet? ja nej Figur 1: Förenklat flödesschema över talsyntesmotorn Systemet består av en databas och en motor för sökning och bearbetning av data. Databasen består av ord och stavelser samt en uppmärkning av varje ord och stavelse för att beskriva hur det betonas. I databasen lagras samma ord på flera olika platser beroende på hur det betonas. Varje ord märks därför upp enligt speciella regler. För varje ord och stavelse med respektive uppmärkning lagras tal- och rörelsedata. Databasen är expanderbar så att användaren själv kan lägga till ord och stavelser. För att användaren skall kunna ändra innehållet i databasen finns ett gränssnitt mellan databasen och användaren. Systemet består av: En databas med uppmärkt tal. Gränssnitt till databasen för att kunna lägga till data. En sökmotor för att söka i databasen. Moduler för bearbetning av data (ta ut ord samt konkatenera). Modul för uppspelning av ljud. Användargränssnitt för inmatning av uppmärkt text. Talsyntesmotor Användargränssnitt Databas Figur 2: Systembeskrivning 6 Kapitel 2: Systemöversikt

13 2.3 Användare Till det här systemet identifieras bara en typ av användare som i fortsättningen kallas just användare. Användaren av systemet har inte som mål att få ut en talsyntes som låter bra. Användarens intresse ligger snarare i att testa hur denna metod för talsyntes fungerar i stort och identifiera brister och möjligheter till vidareutveckling. I projektet STUM har följande antaganden om användaren gjorts: Olika teknisk bakgrund. Vill utvärdera hur denna typ av syntes fungerar i praktiken. Förväntar sig inte ett perfekt resultat. Vet vilka ord som finns i databasen. Har kunskaper i talsyntes. Kan, givet ett visst indata, förutsäga resultatet av talsyntesen. 2.4 Programspråk STUM är utvecklat i programspråket Java. 2.5 Systemkrav Följande minimikrav ställs för att kompilera, installera och utveckla STUM: Windows eller Unix som operativsystem. Javakompilator 1.5 eller senare. Databassystemet Derby version eller senare. Vid kompilering med hjälp av make krävs den Make som följer med SunOS 5.10 eller senare. 2.6 Moduler STUM består av modulerna StumGUI, DataBaseGUI, Synthesizer, DataBase, Visualizer och databasen Derby. Kapitel 2: Systemöversikt 7

14 Användargränssnitt StumGUI Synthesizer Visualizer Grafiskt databasgränssnitt DataBaseGUI DataBase Derby Databasen Figur 3: Modulöversikt 2.7 Begränsningar Detta avsnitt beskriver begränsningar i olika delar av systemet Databasen En begränsning i databasen är att ljuddata ej får överskrida 500 kilobyte när det sparas i databasen. Detta gäller databasen Derby version Kapitel 2: Systemöversikt

15 3 Restlista Detta kapitel återkopplar till Kravspecifikationen [Sandström, 2005] och förklarar hur väl det slutliga systemet överenstämmer med det som kunden ursprungligen önskade. 3.1 Ej uppfyllda krav En stor del av projektet bestod från början av att skapa en koppling mellan vår applikation och den redan utvecklade applikationen Orator för att spela upp ansiktsrörelser. Ett antal krav handlar därför om hur de två applikationerna fungerar tillsammans. På grund av komplexiteten i koden till Orator, med dålig eller ingen kommentering, samt kod som svårligen kan brytas ur sitt sammanhang, togs beslutet att helt släppa kopplingen till Orator. Detta besult påverkar endast kraven på systemet och har inte påverkat designen. Det betyder att systemet är öppet för en framtiden sammankoppling med Orator eller en alternativ egenutvecklad applikation med liknande syfte. Många krav påverkas i mindre utsträckning av detta, oftast endast med språkliga förändringar, men följande krav har helt utgått på grund av att de saknar relevans utan Orator: Funktionellt krav 1.5. Icke-funktionellt krav 1.1. Icke-funktionellt krav 3.3. Alla övriga krav i kravspecifikationen har uppfyllts. 3.2 Kända fel Applikationen har i dag inga av utvecklarna kända fel. Kapitel 3: Restlista 9

16 10 Kapitel 3: Restlista

17 4 Nödlösningar 4.1 Nya ljudfiler via det grafiska databasgränssnittet När nya ljudfiler ska läggas till i databasen via det grafiska databasgränssnittet måste användaren ange exakt sökväg till filen. I dag finns det ingen grafisk filhanterare implementerad för detta. I Java Swing finns stöd för grafisk filhanterare vilket kan användas för att implementera en sådan till det grafiska databasgränssnittet. Nödlösningen påverkar inte resten av systemet. Kapitel 4: Nödlösningar 11

18 12 Kapitel 4: Nödlösningar

19 5 Utökningar och förbättringar 5.1 Databasen Problem Databasmotorn Derby som integerats i applikationen skalar dåligt när databasen innehåller stora mängder data. Dessutom är den långsam på att hantera stora fält med binärdata. Ljuddata som lagras i databasen kan ej överskrida 500 kilobyte. Eftersom systemet sparar både ljud- och ansiktsdata direkt i databasen innebär det att båda dessa begränsingar påverkar applikationen så fort antalet ord och stavelser i databasen börjar växa Förbättringsförslag: Extern databas Självständiga databasmotorer som till exempel MySQL, Oracle eller PostgreSQL är betydligt snabbare och skalar mycket bättre än den integerade Derby-motorn. De kan även lagra större ljuddata. Eftersom all databasåtkomst i applikationen sker genom ett gränssnitt som implementeras av klassen Database.java är de ändringar som behöver göras för att byta underliggande databasmotor begränsade till denna klass. Klassen använder JDBC för att kommunicera med Derby. Det är samma gränssnitt som kan användas till de självständiga databaserna vilket innebär att ändringar i koden blir minimala. Att skifta till en extern databasmotor innebär att applikationen inte längre är självständig utan blir beroende av en fungerande installation av den valda databasen. En fördel med detta blir att flera klienter kan dela på samma databas över ett nätverk, vilket är omöjligt att göra idag Förbättringsförslag: Indexering av externa filer En annan lösning är att behålla Derby men att ändra databasstrukturen. Istället för att lagra ljud- och ansiktsdata direkt i databasen så lagras dessa istället i en extern binärfil och databasen innehåller enbart ett index till denna. 5.2 Synthesizer Förbättringsförslag: Datacache Det finns ett antal små hjälp- och bindeord som är frekvent förekommande i vanligt tal. Genom att införa en datacache skulle dessa kunna hämtas därifrån istället för från databasen. Det skulle eliminera många sökningar i databasen och potentiellt snabba upp hela syntesprocessen. 5.3 DataBaseGUI Problem Idag är det endast möjligt att lyssna på ljuddata via det grafiska användargränssnittet. Kapitel 5: Utökningar och förbättringar 13

20 5.3.2 Förbättringsförslag Det är önskvärt att kunna spela upp ljudfiler från det grafiska databasgränssnittet. När ett ord eller en stavelse har lagts till eller sökts fram i databasen vill man ha en möjlighet att kunna höra hur det låter. DataBaseGUI bör kunna kommunicera med Synthesizer på samma sätt som StumGUI. 14 Kapitel 5: Utökningar och förbättringar

21 6 Installation och vidareutveckling 6.1 Källkod Källkoden till STUM finns att få tag på ~pum1/source. Källkoden till Derby finns att få tag på db.apache.org/derby/. 6.2 Installation Krav För att kompilera och installera STUM krävs följande programvaror: Källkoden till STUM. Javakompilator och JVM 1.5 eller senare. Databassystemet Derby version eller senare. Om make används, Make krävs den Make som följer med SunOS 5.10 eller senare Kompilering För att kompilera STUM börja med att lägga in källkoden. Gå därefter till katalogen STUM. Det finns två metoder för att kompilera källkoden. Antingen används make eller skriptet compile (compile.bat i Windows). Om make används skriv: make Om skriptet compile eller compile.bat används skriv:./compile alternativt compile De färdigkompilerade filerna kommer att läggas i katalogen class som återfinns under katalogen STUM. 6.3 Starta användargränssnittet För att starta användargränssnittet kör programmet stumgui. 6.4 Starta grafiska databasgränssnittet För att starta det grafiska databasgränssnittet kör programmet dbgui. Alla ljuddata som importeras i databasen ska vara okomprimerade. 6.5 Starta konsoldatabasprogrammet Det finns även ett konsolprogram för att ansluta till databasen och för att skicka SQL-anrop till den. Starta konsolprogrammet med:./dbconsole Anslut därefter i konsolprogrammet till stumdb i Derby med: connect jdbc:derby:stumdb ; Därefter används SQL-kommandon. Se manualen till Derby. Kapitel 6: Installation och vidareutveckling 15

22 6.6 Vidareutveckling Katalogstruktur STUM är organiserat i en katalogstruktur enligt nedan. stum class derby stumdb src javadoc Figur 4: Katalogstruktur Katalogen class innehåller kompilerade javafiler. Katalogen derby innehåller databasprogramfilerna. Katalogen stumdb innehåller databasen med allt databasinnehåll. Katalogen src innehåller källkoden till STUM. Katalogen javadoc innehåller den genererade javadoc. Katalogträdet för STUM kan placeras var som helst i datorns katalogträd Klasser Nedan följer en översikt över alla klasser. För beskrivning av den notation som används i figuren se kapitel 2.2 Designnotation i Designspecifikation [Millving, 2005]. Figur 5: Klassöversikt Klasserna som ingår i användargränsnitten och klassen för gränsnittet mot databasen, deras metoder och attribut finns i figur 6 nedan. Stum är huvudklassen genom vilken applikationen startas. 16 Kapitel 6: Installation och vidareutveckling

23 StumGUI har funktioner för användargränssnittet vid talsyntes. Det visar ett fönster för inmatning av den text som användaren vill syntetisera. DataBaseGUI har funktioner för användargränssnittet vid databashantering. Den erbjuder funktioner så att användaren kan underhålla sin databas genom att lägga till och ta bort enskilda ord och stavelser med tillhörande ljuddata. DataBase är den centrala klassen som har hand om kopplingen mellan applikationen och den underliggande databasen. Figur 6: Användargränssnittklasserna Datatypsklassernas metoder och attribut finns i figur 7 nedan. Phrase är en klass som fungerar som en datatyp och representerar ett ord eller en stavelse. Varje Phrase-objekt består av ett SOUND och ett FACE-objekt. Sound är en klass som representerar ljuddata för en fras. Face är en klass som representerar ansiktsdata för en fras. Figur 7: Datatyper Kapitel 6: Installation och vidareutveckling 17

24 Klasserna Synthesizer, Visualizer, Processor, ProcessorCore, SynthesizerCore och VisualizerCore och deras metoder och attribut finns i figur 8. Klasserna Processor och ProcessorCore är abstrakta klasser. Processor är en abstrakt basklass som utgör ett generellt ramverk för att implementera olika steg i databehandlingar av ett Phrase-objekt. Processor utgör det publika gränssnittet av ramverket men är enbart ett skal som internt exekverar ett ProcessorCore-objekt på en egen tråd. Klassen innehåller en abstrakt metod vars uppgift är att skapa det ProcessorCore-objekt som skall användas. ProcessorCore är en abstrakt basklass som utgör kärnan i ramverket för att implementera de olika stegen i databehandlingen. Här ingår asynkron felhantering, synkronisering av trådar, trådsäker buffring osv. Klassen innehåller tre abstraka metoder. Deras uppgift är att verifiera indata, behandla indata samt städa upp efter databehandlingen. Klasserna Synthesizer, SynthesizerCore, Visualizer och VisualizerCore är konkreta klasser. Synthesizer ärvs ifrån Processor. Synthesizer innehåller en privat klass som heter SynthesizerCore och implementerar den abstrakta metoden som skapar ett objekt av den typen. Klassen är det publika gränssnittet mot talsyntesmotorn. SynthesizerCore ärvs ifrån ProcessorCore och implementerar själva kärnan i talsyntesen. Detta görs genom att implementera de tre abstrakta metoderna i basklassen. Den första verifierar att inkommande Phrase-objekt innehåller text och märkning. Den andra matchar innehållet mot databasen och skapar Phrase-objekt som dessutom innehåller ljud- och ansiktsdata och den tredje städar upp de interna datastrukturerna när talomvandlingen avslutats. Visualizer ärvs ifrån Processor. Visualiser innehåller en privat klass som heter VisualizerCore och implementerar den abstrakta metoden som skapar ett objekt av den typen. Klassen är det publika gränssnittet mot visualiseringen, det vill säga uppspelningen av det syntetiska talet. VisualizerCore ärvs ifrån ProcessorCore och implementerar den slutgiltiga uppspelningen av det genererade ljuddatat. Detta görs genom att implementera de tre abstrakta metoderna i basklassen. Den första verifierar att inkommande Phrase-objekt innehåller ljuddata, den andra spelar upp ljuddatat på datormaskinen och den tredje städar upp klassens interna datastrukturer när talomvandlingen avslutats. 18 Kapitel 6: Installation och vidareutveckling

25 Figur 8: Synthesizer För en mer detaljerad beskrivning av klasserna och deras metoder och attribut se kapitel 4 Detaljdesign i Designspecifikation [Millving, 2005]. För en mer detaljerad beskrivning av klasserna och hur dessa samverkar se bilaga B Aktivitetsdiagram i Arkitekturspecifikation [Rasmussen, 2005]. Klassernas funktionella beroenden finns beskrivna i A.1 i Arkitekturspecifikation [Rasmussen, 2005] J2SE För att spela upp ljudfiler används klassen javax.sound.sampled. Till användargränssnittet används klasserna java.awt och java.swing Databasen Databasen är uppbyggd av databasmotorn Derby. Derby är en databasimplementation helt skriven i Java som kan köras utan någon extern server-process. Derby behöver vissa inställningar i systemet innan det startas. Skalvariabeln DERBY_INSTALL måste ange var Derby finns installerad. Skalvariabeln CLASSPATH måste ange sökvägen till Derbys javafiler för att javamotorn ska hitta dem. DERBY_INSTALL och CLASSPATH sätts i stumgui, stumgui.bat, dbgui, dbgui.bat och i dbconsole respektive dbconsole.bat. Derby använder sig av J2SE-klasserna java.sql.* genom att implementera ett interface för konstruktionerna Connection, Statement och ResultSet. Se J2SE för ytterligare information om dessa. För mer information om Derby hänvisas till: I databasen ingår en tabell, Phrase, där datat i tabellen har följande attribut: Id, ett unikt nummer som används som nyckel. Phrase, den sparade texten utan uppmärkning. Marking, uppmärkningen av texten. Kapitel 6: Installation och vidareutveckling 19

26 Offset, tid som används i de fall då ansiktsrörelser och ljuddata är tidsförskjutna. Sounddata, ljuddatat lagrat i binärformat. Det lagrade ljudet är okomprimerat ljud. Facedata, ansiktsrörelser lagrade i binärformat. Figur 9: ER-diagram över databasen Javadoc Javadoc kan genereras med hjälp av programmet genjavdoc som följer med STUM. Starta därefter en webbläsare och ge sökvägen index.html i javadockatalogen under katalogen stum för att läsa dokumentationen Ansiktsdata I databasen finns stöd för ansiktsrörelser. Ansiktsrörelserna består av ett antal mätpunkter där antalet och vilka mätpunkter som ska användas bestäms av språkforskarna i samband med inspelning. Alla mätpunkter samplas 60 gånger per sekund vid inspelning. I de sparade filerna finns inga tidsangivelser. För att kunna synkronisera ljud och ansiktsrörelser krävs tidsangivelser. För att lägga till tidsangivelser för varje sampel kan följande awk-kommando användas på en unix-dator: awk BEGIN { time=0.0 } { printf "%2.3f %s\n", time, $0; time += 1.0/60; } infil > resultatfil För varje rad i indatat adderas 1/60 sekund och läggs i början på varje rad i resultatfilen. 20 Kapitel 6: Installation och vidareutveckling

27 7 Testning Utförliga tester är framtagna och finns beskrivna i Testplan [Janowski, 2005]. Systemet är utförligt testat före leverans enligt Testplan [Janowski, 2005]. För testresultat se Testresultat [Janowski, 2005]. Kapitel 7: Testning 21

28 22 Kapitel 7: Testning

29 8 Referenser 8.1 Externa dokument [Projekt Orator, 2005] Projekt Orator (2005), LeveransRapport fas 4,5, DataDesign Derby, Interna dokument Källhänvisning Interna dokument finns tillgängliga på projektgruppens nätplats vid Institutionen för datavetenskap vid Linköpings tekniska högskola. Adressen dit är: Refererade dokument [Sandström, 2005] Sandström, Patrik (2005), Kravspecifikation, Institutionen för datavetenskap vid Linköpings universitet, Linköping. [Millving, 2005] Millving, Johan (2005), Designspecifikation, Institutionen för datavetenskap vid Linköpings universitet, Linköping. [Janowski, 2005] Janowski, Thomas (2005), Testplan, vid Linköpings universitet, Linköping. [Janowski, 2005] Janowski, Thomas (2005), Testresultat, vid Linköpings universitet, Linköping. [Rasmussen, 2005] Rasmussen, Andreas (2005), Arkitekturspecifikation, Institutionen för datavetenskap vid Linköpings universitet, Linköping. Kapitel 8: Referenser 23

30 24 Kapitel 8: Referenser

31 1.0 Systemförvaltning Bilaga A Javadoc All javadoc till STUM finns på 25

32 26