Arkitekturspecifikation

Transkript

1 I Tal-Lab kan ingen höra dig skrika Arkitekturspecifikation Redaktör: Version: 1.0 Datum: Sammanfattning STUM är ett system för talsyntes. Det utvecklas åt avdelningen för Human- Centered Systems (HCS) vid (IDA) vid Linköpings Tekniska Högskola (LiTH). Syftet med projektet STUM är att utveckla en applikation för att utvärdera en ny metod för talsyntes. Detta dokument beskriver den övergripande arkitekturen hos systemet. Applikationen är ett forskningsverktyg och därför ställs det höga krav på att den är överblickbar, lätt att underhålla och går att vidareutveckla. Mot bakgrund av detta har arkitekturen gjorts mycket modulär och delarna är i så stor utsträckning som möjligt helt självständiga. Slutligen har flera olika implementationsmöjligheter analyserats och utvärderats med hänsyn till möjliga fortsättningsprojekt.

2 Projektidentitet Projektgrupp STUM (IDA) Projektmedlemmar Namn Ansvarsområde Telefon E-post Ali Aghajani Projektledare Kjell Enblom Dokumentansvarig Filip Klasson Kvalitetsansvarig Johan Millving Designansvarig 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 Den första versionen av dokumentet färdigställdes Efter genomläsning och kommentering av projektgruppens alla medlemmar omarbetades i stort sett samtliga kapitel och ett nytt avsnitt om säkerhet lades till. 1.0 Rättning enligt inspektionsprotokoll. Förtydligande av avsnitt 5.2 om testbarhet och tillägg av förklaringar i bilaga A. ii

4 iii

5 1 Inledning Syfte Översikt Läsanvisningar Dokumentberoenden Distribution Förkortningar och ordförklaringar Systemöversikt Bakgrund Projektmål Systemmiljö Övergripande designbeslut Objektorientering Implementationsspråk Java Hantering av befintlig kod i C och Tcl/Tk Plattform Analys av användningsscenarion Databasunderhåll Beskrivning Analys Talsyntes Beskrivning Analys Sammanfattning Arkitektur Klasser Testbarhet Database DatabaseGUI SynthesizerGUI Synthesizer Visualizer Identifiering och analys av kritiska klasser Kritiska designmoment Kritisk funktionalitet Anmärkning angående animering av ansikte Säkerhetsanalys Informationssäkerhet Systemsäkerhet Nätverkssäkerhet Analys av prestanda Analys av skalbarhet Alternativ design Alternativ arkitektur i tre lager Filformat iv

6 6.1 Databas Rörelsedata Ljuddata Kodbibliotek Orator SQLite J2SE Designanvisningar Användande av UML Designmetodik Testbarhet Skalbarhet Databas Referenser Externa dokument Interna dokument Källhänvisning Befintliga dokument Planerade dokument Bilaga A Modulgränssnitt A.1 Relationen mellan klasserna A.2 Datatyper A.2.1 SynthesizerGUI A.2.2 Synthesizer A.2.3 Processor A.2.4 Visualizer A.2.5 DatabasGUI A.2.6 Database Bilaga B Aktivitetsdiagram B.1 Lägga till post i databas B.2 Radera post i databas B.3 Redigera post i databas...31 B.4 Talsyntes Bilaga C Spårbarhet C.1 Funktionella krav C.2 Icke-funktionella krav v

7 1 Inledning Detta kapitel är en kort översikt av dokumentet i sin helhet. Det inleds med en beskrivning av dokumentets syfte, därefter följer läsanvisningar och dokumentberoenden. Kapitlet avslutas med en genomgång av tekniska termer, förkortningar och begrepp som är av särskild betydelse i projektet. 1.1 Syfte Syftet med arkitekturspecifikationen är att ge en övergripande presentation av systemets struktur, de grundläggande designbeslut som fattats och de riktlinjer som tagits fram för det fortsatta arbetet. Dokumentet skall även lyfta fram hur de krav som ställts i kravspecifikationen [2005, Sandström] skall uppfyllas och därmed fungera som länk mellan kravoch designspecifikationerna. Slutligen skall dokumentet hitta och belysa svagheter i det tänkta systemets utformning vilka kan skapa problem i ett senare skede. 1.2 Översikt Kapitel 1 förklarar dokumentets syfte samt ger en översikt av dispositionen med läsanvisningar för olika målgrupper. Det klargör dokumentberoenden och förklarar ord och förkortningar som används. Kapitel 2 presenterar kunden, ger en kort bakgrund till projektet och sammanfattar målsättningen med arbetet. Kapitel 3 handlar om grundläggande designbeslut som fattats på grund av de icke-funktionella kraven, projektgruppens erfarenheter och projektets karaktär. Kapitel 4 tar genom att analysera systemets användningsfall fram en övergripande struktur. Kapitel 5 konkretiserar denna struktur genom att fastslå en klasshierarki för implementationen. Därefter analyseras arkitekturen utifrån krav på skalbarhet, säkerhet och prestanda. Kritiska moduler identifieras och diskuteras. Slutligen presenteras en alternativ design. Kapitel 6 ger några korta riktlinjer för väsentliga filformat. Kapitel 7 presenterar befintliga kodbibliotek som skall, eller eventuellt skall, användas vid design och implementation. Kapitel 8 innehåller specifika riktlinjer för det fortsatta designarbetet. Kapitel 9 är en sammanställning av referenser som gjorts tidigare i dokumentet. Bilaga A innehåller alla modulgränssnitt och en översikt av hur de hänger samman. Bilaga B innehåller detaljerade aktivitetsdiagram som illustrerar hur de olika klasserna samverkar. Bilaga C är en återkoppling av samtliga krav ifrån kravspecifikationen [Sandström, 2005] för att underlätta spårbarheten i arkitekturen. Kapitel 1: Inledning 1

8 1.3 Läsanvisningar För en fullständig bild av arkitekturen rekommenderas en fullständigt genomläsning kapitel för kapitel. Den som redan är bekant med projektmålen och ställda krav, och vill försäkra sig om att arkitekturen uppfyller dessa, bör först läsa kapitel 4 och avsnitt 5.1 för att få en översiktlig bild av strukturen. Därefter läsa och följa hänvisningarna i bilaga C som återkopplar alla krav till resten av dokumentet. För en läsare som inte redan är bekant med projektet, och inte har intresse av tekniska detaljer, rekommenderas enbart kapitel 2, 3 och eventuellt delar av 4. För den som vill sätta sig in i och förstå arkitekturen samt de val som gjorts bör lägga extra vikt vid att läsa kapitel 4, 3, 5 och 6. Den som skall arbete med vidare design bör därefter noggrant studera kapitel 8 och detaljerna i bilagorna A och B. 1.4 Dokumentberoenden Arkitekturspecifikationen bygger vidare på följande dokument. Ändringar i dessa kan medföra att dokumentet måste omarbetas: Projektplan, [Aghajani, 2005] Kravspecifikation, [Sandström, 2005] Dokument som bygger vidare på det här dokumentet och som påverkas av ändringar är: Designspecifikation [Millving, 2005] Programmeringshandbok [Rasmussen, 2005] Testplan [Janowski, 2005] Systemförvaltningsdokumentation [Enblom, 2005] 1.5 Distribution Detta dokument skall distribueras till följande mottagare: Dokumentexaminatorerna Johan Fagerström och Jonas Wallgren Projektgruppens handledare Sten Sunnergren Kunden, kontaktpersoner Bertil Lyberg och Mustapha Skhiri Projektgruppens dokumentpärm 1.6 Förkortningar och ordförklaringar Talsyntes Naturligt tal Konkatenering Difon Konsekutiva Satsanalys Metod eller process för framställning av konstgjort tal. Inspelning av mänskligt tal. Samman-slagning/-fogning av delar. Benämning på ljudbärande halvstavelser. På varandra följande. Språklig analys av text för att identifiera dess grammatiska struktur. 2 Kapitel 1: Inledning

9 HCS IDA LiTH LiU Signalbehandling Talkurvan Human-Centered Systems. En avdelning vid IDA. vid LiTH. Linköpings Tekniska Högskola, en del av LiU. Linköpings Universitetet. Matematisk manipulation av signaler. I den aktuella applikationen handlar det om anpassning av talkurvan. En signal som beskriver tonläget hos naturligt tal. Kapitel 1: Inledning 3

10 4 Kapitel 1: Inledning

11 2 Systemöversikt Detta kapitel inleds först med en kort beskrivning av kunden och bakgrunden till projektet. Därefter följer en kort beskrivningen av projektets mål, och slutligen förklaras i vilken miljö systemet är tänkt att användas. En mer detaljerad beskrivning återfinns i kravspecifikationen [Sandström, 2005]. 2.1 Bakgrund Vid avdelningen för Human-Centered Systems vid vid bedrivs bland annat forskning inom området talsyntes. Vid avdelningen finns både lingvister och datavetare. Vid avdelningen finns idag intresse av att utvärdera en ny metod för talsyntes som bygger på sammanfogning av längre bitar naturligt tal än vad som tidigare använts. Den tidigare metoden använder difoner, delar mindre än stavelser, och implementerades i ett projekt som heter Orator. Detta beskrivs delvis i [Projekt Orator, 2005]. I den nya metoden skall längre bitar av naturligt tal användas; ord och stavelser 2.2 Projektmål Projektets mål är att implementera den nya metoden för talsyntesen så att denna kan utvärderas. Den framtagna applikationen är ett forskningsverktyg och tänkt som första byggsten i ett större mer långsiktigt projekt, därför måste det vara lätt att förändra och vidareutveckla. Systemet skall omfatta en databas med naturligt tal, ett verktyg för att underhålla databasen och en applikation för att experimentera med talsyntesen. 2.3 Systemmiljö Systemet skall bestå av ett enda program. Programmet skall vara självständig och inte beroende av andra applikationer utöver kod- och operativsystemspecifika bibliotek. Till applikationen finns endast en användare åt gången och programmet körs på användarens egen arbetsstation. Kapitel 2: Systemöversikt 5

12 6 Kapitel 2: Systemöversikt

13 3 Övergripande designbeslut Detta kapitel beskriver övergripande designbeslut så som: logisk struktur, implementationsspråk och plattform. Systemet skall återanvända kod ifrån ett gammalt projekt och hur denna skall hanteras beskrivs här. 3.1 Objektorientering Vid utformning av systemets arkitektur har vi valt att använda en objektorienterad struktur. Detta för att systemet skall bli modulärt. Ett modulärt system är oftast enklare att underhålla, vidareutveckla och återvända delar ifrån. 3.2 Implementationsspråk Java Systemet skall utvecklas i Java. Anledningarna till detta är flera. Dels är det ett modernt objektorienterat språk och vi har valt en objektorienterad struktur för arkitekturen, dels är det det språk projektgruppen har störst erfarenhet av. Slutligen är det ett plattformsoberoende språk med en omfattande utvecklingsmiljö och ett stort klassbibliotek Hantering av befintlig kod i C och Tcl/Tk Orator är implementerat i en blandning av C och Tcl/Tk. Eftersom delar av denna kod skall återanvändas av vårt projekt kommer dessa delar även fortsättningsvis att vara skrivna i C och Tcl/Tk. Java innehåller ett ramverk som heter JNI och som används för att anropa kompilerad plattformsberoende kod. Detta gränssnitt skall användas för att i språket C kapsla in koden ifrån Orator och sedan anropa den ifrån vår Javakod. 3.3 Plattform Kunden har ställt krav på att systemet i första hand skulle gå att exekvera på Windows XP men ändå vara relativt enkelt att porta till andra plattformar. Koden ifrån Orator går att kompilera för både Windows och Unix. I och med valet av Java som implementationsplattform kommer den nyutvecklade koden redan från början att gå att köra på ett stort antal operativsystem. Kapitel 3: Övergripande designbeslut 7

14 8 Kapitel 3: Övergripande designbeslut

15 4 Analys av användningsscenarion Det finns endast två olika användningsscenarion för applikationen. Dessa beskrivs utförligt i kravspecifikationen [Sandström, 2005]. Här följer en kort översikt av dessa och en analys av vilken funktionalitet de kräver av implementationen samt hur denna kan grupperas i separata moduler. 4.1 Databasunderhåll Beskrivning Applikationens databas innehåller tal- och rörelsedata kopplat till ord och stavelser som har märkts upp enligt särskilda uttalskonventioner. Systemet skall ge användaren möjlighet att underhålla databasen, det vill säga: lägga till, radera och uppdatera data Analys För att systemet skall kunna tillhandahålla denna funktionalitet krävs det att en databas implementeras med de funktionerna och att det finns ett användargränssnitt för att använda dessa. Slutsatsen blir att följande moduler behöver ingå i systemets arkitektur: En databas. Ett användargränssnitt för databasen. 4.2 Talsyntes Beskrivning Systemet skall ge användaren möjlighet att mata in text, märka upp denna enligt givna uttalskonventioner och sedan omvandla detta till syntetiskt tal och animerade ansiktsrörelser som sedan spelas upp för användaren Analys Genom att bryta ned omvandlingen från text till tal och ansiktsrörelser i delomvandlingar identifieras följande konsekutiva delmoment: 1. Inmatning av text. 2. Uppmärkning av text. 3. Sönderdelning av text i delelement. 4. Matchning av delelement mot databas. 5. Konkatenering av sökresultat. 6. Uppspelning och visualisering. Närliggande steg har identifierats, grupperats och avgränsats i separata moduler. Dessa moduler är: Moment ett och två är de enda steg som interagerar med användaren. De placeras därför i ett interaktivt användargränssnitt. Moment tre placeras i samma modul som användargränssnittet eftersom sönderdelningen hänger ihop med uppmärkningen. Att placera den i en annan modul skulle troligtvis innebära att extra databehandling måste Kapitel 4: Analys av användningsscenarion 9

16 göras. Vid uppmärkning av texten skapas datastrukturer som kan behövas även vid sönderdelningen och då måste dessa tas fram i båda modulerna. Moment fyra och fem placeras i en särskild syntesmodul. Denna modul kommunicerar utöver de angränsande modulerna i omvandlingsprocessen även med den tidigare identifierade databasmodulen. Det sista momentet placeras i en egen modul. Slutsatsen blir att följande moduler kommer att behövas i arkitekturen: Användargränssnitt för inmatning och uppmärkning av text. Talsynteskomponent. Visualiseringskomponent. 4.3 Sammanfattning Med utgångspunkt i de användningsfall som beskrivs i kravspecifikationen [Sandström, 2005] har följande övergripande struktur för systemet tagits fram: 10 Kapitel 4: Analys av användningsscenarion

17 5 Arkitektur I detta kapitel konkretiseras den övergripande struktur som tagits fram i kapitel 4 och systemets arkitektur definieras som en klasshierarki i Java. 5.1 Klasser Vi har funnit att de moduler som tagits fram i kapitel 4 är direkt överförbara till klasser i Java-implementationen, och att dessa är en tillräcklig uppsättning basklasser för att realisera arkitekturen. Klasserna döps till: Klassnamn Database DatabaseGUI SynthesizerGUI Synthesizer Visualizer Beskrivning Databas-abstraktionen/-implementationen Användargränssnittet för databasunderhåll. Användargränssnittet för talsyntes. Talsyntesklassen Klassen för uppspelning av tal och ansiktsrörelser Tabell 1: Modulklasser I bilaga A beskrivs klassernas inbördes relationer och beroenden. Där återfinns även definitioner av publika gränssnitt och datatyper. I bilaga B finns aktivitetsdiagram som illustrerar hur de olika användningsfallen i kapitel 4 realiserats av klasserna och hur klasserna samverkar med varandra. 5.2 Testbarhet På grund av systemets objektorienterade struktur och väl avgränsade klasser med tydliga gränssnitt finns det mycket goda möjligheter att testa deras olika funktionalitet var för sig och oberoende av varandra Database Databasklassens funktionalitet kan verifieras genom att ta fram ett testscenario där specifika data lagras, återläses och verifieras. Med kända testdata kan sedan även alla sök och uppdateringsmetoder testas. Databasen kan även stresstestas med skräpdata. Även skalbarheten kan undersökas på samma sätt DatabaseGUI För detta användargränssnitt kan användsfallen verifieras genom att följa ett särskilt testprotokoll som innefattar alla ställda krav. Istället för att anropa databasen kan ett särskilt ramverk för testerna skrivas så att data- och kontrollflöda kan inspekteras. Ramverket kan även fungera som ett mellanlager mellan klassen och den riktiga databasen för att göra integrationstest. Kapitel 5: Arkitektur 11

18 5.2.3 SynthesizerGUI Testning kan ske enligt samma mönster som för DatabaseGUI Synthesizer Denna klass är fullständigt deterministisk. Det vill säga att för varje givet indata finns endast ett möjligt ut-data. Därmed är funktionaliteten för denna klass enkel att verifiera Visualizer Denna klass kan testas genom att ta fram ett testprotokoll och sedan mata klassen med statiska in-data och observera visualiseringen. 5.3 Identifiering och analys av kritiska klasser Det finns två aspekter av denna analys. Den ena är klasser som är kritiska ur design- och implementationsperspektiv och den andra är klasser som är av kritisk betydelse för funktionen vid användning av det färdiga systemet Kritiska designmoment Ur design- och implementationsperspektiv är databas- och visualiseringsklasserna kritiska. Problemet med visualiseringsdelen rör det animerade ansikte som bygger på plattformsberoende kompilerad kod som skall återanvändas ifrån Orator och integreras i systemets Java-implementation. En annan svårighet ligger i att synkronisera det uppspelade talet med det animerade ansiktet vid visualiseringen. Problemet med databasen är att det är en komplicerad klass där designarbetet kan bli en betydande belastning för projektgruppen. I avsnitt 5.5 diskuteras mer utförligt några alternativ gällande designen av databasen Kritisk funktionalitet Eftersom systemet har en så pass avgränsad uppgift, och är uppbyggt av ett mycket litet antal klasser, så måste samtliga klasser fungera under körning för att systemet skall vara användbart. Ingen klass är därmed funktionellt sett viktigare än någon annan Anmärkning angående animering av ansikte Det animerade ansiktet i visualiseringsklassen är inte ett baskrav. Kunden är väl medveten om de problem som finns med det, och ser hellre att tonvikten i arbetet läggs på processen text-till-tal än att lösa allt för stora problem med koden ifrån Orator. Kunden ser återanvändandet av den befintliga koden ifrån Orator som en tillfällig lösning och planerar att ersätta det med ett nytt egenutvecklat ansikte i framtiden. Arkitekturen har därför inte anpassats särskilt för att underlätta integrationen med det gamla ansiktet utan istället för att få en ren och stabil arkitektur i vilken ett nytt ansikte kan utvecklas. 12 Kapitel 5: Arkitektur

19 5.4 Säkerhetsanalys Informationssäkerhet Applikationen innehåller inget särskilt skydd för den data som lagrats i databasen. Eftersom applikationen är ett forskningsverktyg är detta varken nödvändigt eller önskvärt. Istället eftersträvas enkelhet och tillgänglighet i lagringsmodellen Systemsäkerhet Eftersom applikationen är helt självständig påverkar den inte säkerheten hos det övriga systemet. Kraschar applikationen så påverkar det inga andra program. Java-plattformen innebär dessutom ett extra lager mellan applikationen och operativsystemet så risken för att eventuella fel i koden skall innebära säkerhetsrisker är inte stor Nätverkssäkerhet Applikationen innehåller inga moduler som kommunicerar med några nätverk. Nätverkssäkerheten är därmed inte en fråga som berör systemet. 5.5 Analys av prestanda Den prestandakritiska delen av arkitekturen är sökningen i databasen och visualiseringen. Om sökningen tar för lång tid kommer det antingen innebära att talet hackar eller att det blir längre pauser mellan meningarna. Exakt vilket beror på hur synkroniseringen med visualiseringen implementeras efter designen. I visualiseringen är det framför allt det animerade ansiktet som ställer krav på en snabb dator och ett modernt grafikkort. Tal är en av naturen långsam process så prestandan får ses som tillfredsställande ifall applikationen kan spela upp syntetiskt tal utan hack och extra pauser. Med tanke på att applikationen dessutom är ett forskningsverktyg och inte skall samköras med andra tillämpningar finns det inte i dagsläget någon anledning att utöver detta försöka minimera minnes- och processorbelastningen. 5.6 Analys av skalbarhet Skalbarheten hos applikationen beror på skalbarheten hos databasen. I sitt ursprungliga utförande kommer den att innehålla väldigt lite data vilket ger högst begränsade användningsområden, och inte ställer särskilt höga krav på databasens implementation. Därmed kommer eventuella begränsningar i databasimplementationen inte att märkas i inledningsskedet. Om det i ett senare skede visar sig att databasimplementationen trots allt inte är tillräckligt effektiv går det tack vare den modulära designen enkelt att byta ut den mot en ny eller exempelvis bygga ett abstraktionslager mot en kraftfull kommersiell databasmotor. Skalbarheten när det gäller vidareutveckling begränsas inte bara av arkitekturen utan även av den metod för talsyntes som den bygger på. De vidareutvecklingar kunden kunnat identifiera har tagits i beaktning vid utvecklingen av arkitekturen. De två viktigaste av dessa är: Kapitel 5: Arkitektur 13

20 Vid konkatenering av bitar med naturligt tal uppkommer diskontinuiteter i talkurvan vid varje skarv. Genom att infoga en signalbehandlingsmodul mellan syntes- och visualiseringskomponenterna kan detta korrigeras. Att manuellt tvingas märka upp ren text vid inmatningen begränsar användningsområdet av applikationen och ställer höga krav på användarens kunskaper i lingvistik. Genom att använda satsanalys kan uppmärkningen ske automatiskt. Genom att byta ut användargränssnittet för uppmärkning mot en modul som gör detta arbete automatiskt kan ren text matas in. I designanvisningarna i kapitel 8 finns under ett särskilt avsnitt 8.4 förslag på hur designen redan från början kan förberedas för dessa vidareutvecklingar. 5.7 Alternativ design Systemet har en väldigt specifik uppgift. Det innebär att det innehåller få moment. Därmed kommer det oavsett metod att resultera i en arkitektur som består av få moduler. De moduler som valts har en tydlig logisk koppling till den funktionalitet de innesluter. Varje modul innesluter endast en aktivitet och det finns inte två moduler som överlappar varandra någonstans. Att göra någon annan naturlig uppdelning på den övergripande nivån är svårt. Möjligtvis skulle det kunna tänkas att moduler kan sönderdelas. Risken med det är att arkitekturen då kommer att innehålla implementationsdetaljer som egentligen inte hör hemma i den övergripande strukturen. En bra sönderdelning har hittats, och när denna övervägdes ledde detta fram till en alternativ modell med tre isolerade lager som presenteras nedan Alternativ arkitektur i tre lager Den konkreta skillnaden mot den valda arkitekturen är att modulen som implementeras av klassen DatabaseGUI har splittrats i två moduler: Modul DatabaseGUI DatabaseControl Beskrivning Innehåller enbart själva användargränssnittet för att manipulera databasen. Låter användaren lägga till, söka, ändra och radera poster i databasen. Finns mellan DatabaseGUI och Database. Dess uppgift är att abstrahera bort lågnivåanrop till databasen som användargränssnittet inte behöver samt att verifiera den data som användaren försöker spara i databasen. Tabell 2: Nya klasser efter splittring Rent konceptuellt introduceras tre logiska lager som är fullständigt isolerade ifrån varandra. Det vill säga att moduler i ett lager enbart kan kommunicera med moduler i de närmast angränsande lagren. Lagren är i tur och ordning uppifrån och ned: Interaktion Logik Lagring 14 Kapitel 5: Arkitektur

21 I dessa tre lager går det nu att sortera in våra sex moduler utan ytterligare förändringar av den arkitektur vi valt: Lager Interaktion Logik Lagring Moduler DatabaseGUI, SynteziserGUI, Visualizer DatabaseControl, Syntesizer Database Tabell 3: Placering av klasser i lagerstrukturen vilket illustreras i följande figur: I aktivitetsdiagrammen som presenteras i bilaga B skulle inte själva aktiviteteten (flödesdiagrammet) utan enbart avgränsningen mellan modulerna behöva förändras för att stämma med 3-lagerdesignen. Kapitel 5: Arkitektur 15

22 16 Kapitel 5: Arkitektur

23 6 Filformat I detta kapitel beskrivs de filformat, eller riktlinjer för filformat, som kommer att användas av applikationen. 6.1 Databas Databasen kommer att lagras på disk. Det exakta formatet för detta kommer att fastslås under designarbetet och är en direkt konsekvens av databasmotorns utformning. I kapitel 8.5 anges att databasen om möjligt skall implementeras med kodbiblioteket SQLite. I så fall kommer detta databasformat att användas. 6.2 Rörelsedata Rörelsedata tas genom manuellt arbete fram med ett särskilt datorsystem som projektgruppen har tillgång till i tal-laboratioriet vid HCS. Resultatet är en textfil innehållandes en matris med X-, Y- och Z-koordinater. 6.3 Ljuddata Projektgruppen har spelat in ljuddata och sedan bearbetat detta i ett datorprogram som heter WaveSurfer. Detta program utvecklas vid Kungliga Tekniska högskolan, avdelning Speech, music and hearing (TMH). WaveSurfer kan hantera ett flertal olika standardformat för ljud. Vilket av dessa som visar sig vara bäst lämpade för implementationen av STUM skall noggrant utredas vid framtagandet av designspecifikationen som i detalj skall utforma implementationen. Kapitel 6: Filformat 17

24 18 Kapitel 6: Filformat

25 7 Kodbibliotek 7.1 Orator Orator är en befintlig applikation som avdelningen Human-Centered System vid Institutionen för Datavetenskap vid Linköpings universitet tillhandahållit källkoden för. Applikationen är utvecklad i C och Tcl/Tk. Koden är skyddad av upphovsrätt och projektgruppen har skrivit på ett avtal som reglerar användandet av denna. I Orator finns en implementation av ett animerat ansikte som skall återanvändas i implementationen. 7.2 SQLite SQLite är en inbäddad miniimplementation av en generell databasmotor med ett SQL-gränssnitt. Kodbibliotektet är implementerat i C och måste därför utnyttjas genom JNI om det skall användas i implementationen. SQLite är fritt att använda (public-domain) och har en mycket liberal licens. Om möjligt skall detta användas till databasimplementationen. 7.3 J2SE I Java 2 Standard Edition ingår ett stort klassbibliotek. Detta kodbibliotek kommer att användas så mycket som möjligt. Kapitel 7: Kodbibliotek 19

26 20 Kapitel 7: Kodbibliotek

27 8 Designanvisningar Detta kapitel ger övergripande riktlinjer för det fortsatta arbetet med designspecifikationen. Här bestäms standardisering av diagram och annan strukturerad notation. Riktlinjer för designen av klasserna ges. 8.1 Användande av UML I designspecifikationen skall UML [OMG, 2003] genomgående användas för alla typer av diagram. Om någon annan standard ändå måste användas skall detta tydligt framgå och notationen beskrivas ordentligt. 8.2 Designmetodik I detta dokument har en objektorienterad analys av systemet gjorts och arkitekturen har avgränsats i fem stycken klasser. Samspelet mellan dessa klasser, och gränssnittet mellan dem, har klarlagts. I designspecifikationen skall implementationen av var och en av dessa i detalj beskrivas. Vilken designmetodik som används för detta spelar ingen roll så länge det resulterar i klassimplementationer som fyller sin funktion och följer de specificerade gränssnitten. Eftersom klasserna har väldigt olika uppgifter är det inte alls säkert att det finns en enhetlig metodik som passar alla. Därför behöver inte samma designmetodik användas för alla klasser. Istället skall var och en av klasserna designas med den för modulen lämpligaste metodiken. Klasserna kan därmed utvecklas i stort sett oberoende av varandra. Det är dock mycket viktigt att designen, och designmetodiken, för var och en beskrivs mycket noggrant och alla designval tydligt motiveras. 8.3 Testbarhet Vid designarbetet skall särskild hänsyn till riktlinjer i den övergripande testplanen tas och designval som försvårar testarbetet skall undvikas om möjligt. 8.4 Skalbarhet För att redan från början anpassa arkitekturen för framtida tillägg föreslås två konkreta designval. Klassen SyntesizerGUI har som uppgift att ta in information ifrån användaren och producera en följd av datastrukturer, som representerar uppmärkt tal, vilka kan skickas vidare till Syntesizer för vidare bearbetning. Denna metod att interaktivt omvandla ren text till uppmärkt och sönderdelad text är bara en tänkbar lösning. Andra tänkbara lösningar som diskuterats är en scanner/parser för en särskild uppmärkningssyntax eller att automatiskt system som självständigt omvandlar texten. Den förstnämnda varianten förkastades pågrund av att den var oflexibel och ställde stora krav på användaren. Den andra varianten är ett relativt avancerat fortsättningsprojekt. För att underlätta implementationen av olika alternativ i första steget föreslås att en virtuell klass som implementerar gränssnittet används och att SynthesizerGUI sedan ärvs från den. Kapitel 8: Designanvisningar 21

28 På samma sätt är den avslutande visualiseringsklassen Visualizer endast en tänkbar lösning. En annan lösning skulle till exempel kunna vara en klass som exporterar talet och ansiktsrörelse som en filmsekvens som kan brännas på en DVD skiva eller liknande. Därför föreslås att även klassen i sista steget implementeras som en virtuell basklass och att Visualizer ärvs av denna. En annan vidareutveckling av systemet är att introducera signalbehandling mellan Synteziser- och Visualizer-klasserna. För att underlätta detta föreslås att en virtuell basklass Processor implementeras mellan dessa och att en enkel klass Passthrough ärvs av denna och vars enda funktion är att släppa igenom data i oförändrat skick. 8.5 Databas Eftersom systemet skall vara skalbart är det önskvärt att hitta en färdig generell databasmotor som kan användas i projektet. Vid framtagandet av detta dokument har, som nämnts tidigare i kapitel 7.2, kodbiblioteket SQLite hittats och utvärderats. Om möjligt skall detta användas för implementation av databasen. Kan andra kodbibliotek eller lösningar hittas och dessa visar sig vara bättre lämpade för designen skall dessa användas. Kravet på systemet att det skall vara självständigt förbjuder dock lösningar som kopplar applikationen mot externa databassystem så som MySQL eller PostgreSQL. Då design av en generell databasmotor är ett arbete minst lika stort eller större än resten av erbetet med applikationen så är det inte ett alternativ ifall vi själva skall implementera kärnan i databasen. En egenutvecklad databas blir därmed applikationsspecifik och innebär att skalbarheten blir sämre. Eventuella förändringar i datastrukturen i framtiden kan bli arbetskrävande. Därför skall en egenutvecklad applikationsspecifik databas endast övervägas ifall alla andra möjligheter uttömts. 22 Kapitel 8: Designanvisningar

29 9 Referenser 9.1 Externa dokument [Projekt Orator, 2005] Projekt Orator (2005), LeveransRapport fas 4,5, DataDesign [OMG, 2003] Object Management Group, Inc. OMG Unified Modeling Language Specification, < 9.2 Interna dokument Källhänvisning Interna dokument finns tillgängliga på projektgruppens nätplats vid Institutionen för datavetenskap vid. Adressen dit är: Befintliga dokument [Aghajani, 2005] Aghajani, Ali (2005), Projektplan, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Sandström, 2005] Sandström, Patrik (2005), Kravspecifikation, Institutionen för Datavetenskap vid Linköpings universitet, Linköping Planerade dokument Följande dokument har ännu inte tagits fram men är en del av det fortsatta arbetet med systemet och nämns i detta dokument. [Millving, 2005] Millving, Johan (2005), Designspecifikation, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Rasmussen, 2005] Rasmussen, Andreas (2005), Programmeringhandbok, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Enblom, 2005] Enblom, Kjell (2005), Systemförvaltningsdokument, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Janowski, 2005] Janowski, Thomas (2005), Testplan, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. Kapitel 9: Referenser 23

30 24 Kapitel 9: Referenser

31 Bilaga A Modulgränssnitt I det här kapitlet beskrivs Java-klasserna som implementerar de moduler arkitekturen delats upp i. A.1 Relationen mellan klasserna Pilarna beskriver funktionellt beroende. Det vill säga att modulen vid pilens ände anropas av modulen vid pilens start. A.2 Datatyper För att minska ned antalet klassmetoder definieras en ren dataklass som kapslar in den data som skall transporteras runt i systemet. Denna klass skall heta Phrase men den kommer inte att fullständigt specifieras här. Anledningen till detta förklaras ned. För lagring och hantering av ljud- och rörelsedata finns två helt olika designalternativ. Antingen så lagras data inuti databasen eller så är databasen enbart ett index över en eller flera externa binärfiler. Beroende på vilket kommer datatypen att innehålla olika information. För att inte föregripa och i onödan låsa in detaljdesignen i detta avseende lämnas det beslut till senare då konsekvenserna av de olika strukturerna är lättare att bedömma. Phrase skall dessutom innehålla information om uttalsuppmärkningen av textstycket som datatypen skall representera. Exakt hur denna skall göras, och vilken information som behövs, beror på implementationen. Då det är kunden och inte projektgruppen som besitter den nödvändiga kunskapen i lingvistik kommer kunden aktivt att delta i implementationsdesignen för att hitta bästa möjliga representation. Därför definieras ej heller denna del av datastrukturen i detta skede. Bilaga A: Modulgränssnitt 25

32 A.2.1 SynthesizerGUI SynthesizerGUI +SynthesizerGUI() +show(): void +hide(): void Tabell 4: Klassmetoder SynthesizerGUI Denna klass implementerar användargränssnittet för talsyntesen. Denna klass använder: Phrase, Synthesizer,Visualizer och Processor. Inga övriga kommentarer. A.2.2 Synthesizer 26 Bilaga A: Modulgränssnitt Synthesizer +Synthesizer() +synthesize(phrase: Phrase, visualizer: Visualizer): boolean +synthesize(phrase: Phrase, processor: Processor): boolean Tabell 5: Klassmetoder för Synthesizer Denna klass implementerar talsyntesmotorn (konkateneringsprocessen). Denna klass använder: Phrase, Database, Visualizer och Processor. Metoden synthesize anropas med en instans av dataklassen Phrase som innehåller text med information om uttalsmärkning. Den matchar denna mot informationen i databasen, kompletterar datastrukturen med tal- och rörelsedata och vidarebefodrar den därefter till det givna Visualizer- eller Processorobjektet för vidare behandling. A.2.3 Processor Det här är en utökning av den grundläggande arkitekturen som föreslås i kapitel 8.4 för att redan från början förbereda arkitekturen för vidare utveckling. +Processor(visualizer: Visualizer) +Processor(processor: Processor) +process(phrase: Phrase: void) Processor Tabell 6: Klassmetoder för Processor Denna klass är tänkt som en abstrakt basklass från vilken olika typer av signal och databehandling kan implementeras mellan konkatenering och återkoppling till användaren. Denna klass använder: Phrase, Processor och Visualizer. En instans av Processor-klassen har en dedikerad funktion därför anges målklassen (konsumenten) i konstruktorn. Utdata ifrån objektet konsumeras antingen av ännu ett Processor-objekt, och en lång kedja av signalbehandling

33 kan därmed upprättas, eller ett Visualizer-objekt för återkoppling till användaren. Metoden process tar ett Phrase-objekt, manipulerar dess innehåll och vidarebefodrar det till konsumenten. A.2.4 Visualizer +Visualizer() +visualize(phrase: Phrase: void) +reset(): void Visualizer Tabell 7: Klassmetoder för Visualizer Denna klass är tänk som en abstrakt basklass från vilken olika typer av återkoppling till användaren kan implementeras. I den aktuella implementation är detta uppspelning av tal och animering av rörelsedata. Denna klass använder: Phrase. Inga övriga kommentarer. A.2.5 DatabasGUI DatabaseGUI +DatabaseGUI() +show(): void +hide(): void Tabell 8: Klassmetoder för DatabaseGUI Denna klass implementerar ett användargränssnitt för att manipulera och inspektera innehållet i databasen. Denna klass använder: Database och Visualizer. Inga övrig kommentarer. Bilaga A: Modulgränssnitt 27

34 A.2.6 Database Database +Database(identifier: String) +add(phrase: Phrase): boolean +findtext(text: String): long +findsyntax(syntax: String): long +findfirst(): long +findlast(): long +findnext(): long +findprev(): long +getphrase(entry: long): Phrase +getcurrentphrase(): Phrase +getcurrententry(): long +update(phrase: Phrase): boolean +update(phrase: Phrase, node: long): boolean +remove(entry: long): boolean +removecurrent(): boolean +close(): void Tabell 9: Klassmetoder för Database Denna klass implementerar en databas eller fungerar som abstraktionslager för en befintlig implementation. Denna klass använder: Inga andra klasser i arkitekturen. Argumentet till konstruktorn finns där för att gränssnittet redan från början skall innefatta möjligheten att arbeta med flera olika databaser. Detta är inte aktuellt i nuläget. 28 Bilaga A: Modulgränssnitt

35 Bilaga B Aktivitetsdiagram Denna bilaga innehåller diagram som illustrerar hur funktionaliteten är fördelad mellan systemets huvudklasser samt hur dessa samverkar i de mest centrala användningsfallen. B.1 Lägga till post i databas Bilaga B: Aktivitetsdiagram 29

36 B.2 Radera post i databas 30 Bilaga B: Aktivitetsdiagram

37 B.3 Redigera post i databas Bilaga B: Aktivitetsdiagram 31

38 B.4 Talsyntes 32 Bilaga B: Aktivitetsdiagram

39 Bilaga C Spårbarhet Detta avsnitt beskriver var de krav som definierats i kravspecifikationen återfinns i arkitekturspecifikationen. Detta för att lätt kunna fastställa att alla krav kan uppfyllas med den nuvarande arkitekturen. I kravspecifikationen [Sandström, 2005] återfinns en mer detaljerad beskrivning av kraven. Tabellerna innehåller det kravnummer och kravnamn som finns i kravspecifikationen [Sandström, 2005]. För de funktionella kraven anges vilken modul som gör att kravet uppfylls. Alla icke-funktionella krav går inte att hänvisa till en speciell modul utan det kan istället finnas en hänvisning till ett kapitel i arkitekturspecifikationen som tar upp kravet. Vissa icke-funktionella krav kan ej härledas till arkitekturspecifikationen eftersom de handlar om datainnehåll i databasen och är kopplade till det datainsamlingsarbete projektgruppen måste att göra för systemet över huvudet taget skall kunna utvecklas, testas och användas. Dessa har markerats med texten Datainsamling. C.1 Funktionella krav Krav Benämning Modul F-1.1 Inmatning av uppmärkt text SynthesizerGUI F-1.2 Ta ut uppmärkt ord SynthesizerGUI F-1.3 Ta ut uppmärkt stavelse Synthesizer F-1.4 Konkatenera tal och rörelsemönster Synthesizer F-1.5 Koppling till Orator Visualizer F-1.6 Spela upp ljud Visualizer F-2.1 Lägg till data DatabaseGUI F-2.2 Ta bort data DatabaseGUI F-2.3 Söka efter uppmärkta ord Database F-2.4 Söka efter uppmärkt stavelse Database Bilaga C: Spårbarhet 33

40 C.2 Icke-funktionella krav Krav Benämning Kapitel/Modul I-1.1 Separat system 2.3 I-1.2 Systemmiljö - Windows I-1.3 Systemmiljö - Unix I-2.1 Innehåll-Data 6.1 I-3.1 Datainsamling Datainsamling I-3.2 Innehåll-kvantitet Datainsamling I-3.3 Synkronisering Datainsamling I-4.1 Användarvänlighet SynthesizerGUI 34 Bilaga C: Spårbarhet