Arkitekturspecifikation - Lysator

“I Tal-Lab kan ingen höra dig skrika” 

Arkitekturspecifikation 

Redaktör: Andreas Rasmussen 

Version: 1.0 

Datum: 2005-10-11 

Sammanfattning 

STUM är ett system för talsyntes. Det utvecklas åt avdelningen för Human- 

Centered Systems (HCS) vid Institutionen för datavetenskap (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.

Projektidentitet 

Projektgrupp 

STUM 

PUM 1 2005 

Linköpings tekniska högskola 

Institutionen för datavetenskap (IDA) 

Projektmedlemmar 

Namn Ansvarsområde Telefon E-post 

Ali Aghajani Projektledare 073-0460493 aliag988@student.liu.se 

Kjell Enblom Dokumentansvarig 076-2353375 kjeen007@student.liu.se 

Filip Klasson Kvalitetsansvarig 076-2311778 filkl784@student.liu.se 

Johan Millving Designansvarig 070-9788619 johmi359@student.liu.se 

Andreas Rasmussen Implementationsansvarig 070-3718879 andra583@student.liu.se 

Gustav Veide Systemansvarig 070-5514745 gusve322@student.liu.se 

Patrik Sandström Kundansvarig 073-5464898 patsa014@student.liu.se 

Thomas Janowski Testansvarig 070-9507595 tomja961@student.liu.se 

E-postlista för hela gruppen 

pum1@und.ida.liu.se 

Hemsida 

www-und.ida.liu.se/~pum1 

Kund 

Institutionen för datavetenskap 

Kundkontakt 

Bertil Lyberg, berly@ida.liu.se 

Mustapha Skhiri, mussk@ida.liu.se 

Handledare 

Sten Sunnergren, sten.sunnergren@ekhosat.se 

Examinator och kursansvarig 

Robert Kaminski, IDA



PUM 1 2005 

Arkitekturspecifikation 1.0 

Andreas Rasmussen 

2005-10-11 

Dokumenthistorik 

Version Datum Utfärdade ändringar Utfärdade av 

0.1 2005-10-03 Den första versionen av dokumentet färdigställdes. Andreas Rasmussen 

0.2 2005-10-05 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 2005-10-11 Rättning enligt inspektionsprotokoll. Förtydligande av 

avsnitt 5.2 om testbarhet och tillägg av förklaringar i 

bilaga A. 



ii



PUM 1 2005 



2005-12-06 

iii



PUM 1 2005 



2005-10-11 

1 Inledning .................................................................................................................. 1 

1.1 Syfte ..................................................................................................................................... 1 

1.2 Översikt ............................................................................................................................... 1 

1.3 Läsanvisningar ..................................................................................................................... 2 

1.4 Dokumentberoenden ............................................................................................................ 2 

1.5 Distribution .......................................................................................................................... 2 

1.6 Förkortningar och ordförklaringar ....................................................................................... 2 

2 Systemöversikt ........................................................................................................ 5 

2.1 Bakgrund ............................................................................................................................. 5 

2.2 Projektmål ............................................................................................................................ 5 

2.3 Systemmiljö ......................................................................................................................... 5 

3 Övergripande designbeslut .................................................................................... 7 

3.1 Objektorientering ................................................................................................................. 7 

3.2 Implementationsspråk .......................................................................................................... 7 

3.2.1 Java .............................................................................................................................. 7 

3.2.2 Hantering av befintlig kod i C och Tcl/Tk ................................................................... 7 

3.3 Plattform .............................................................................................................................. 7 

4 Analys av användningsscenarion .......................................................................... 9 

4.1 Databasunderhåll ................................................................................................................. 9 

4.1.1 Beskrivning .................................................................................................................. 9 

4.1.2 Analys .......................................................................................................................... 9 

4.2 Talsyntes .............................................................................................................................. 9 

4.2.1 Beskrivning .................................................................................................................. 9 

4.2.2 Analys .......................................................................................................................... 9 

4.3 Sammanfattning ................................................................................................................. 10 

5 Arkitektur .............................................................................................................. 11 

5.1 Klasser ............................................................................................................................... 11 

5.2 Testbarhet .......................................................................................................................... 11 

5.2.1 Database ..................................................................................................................... 11 

5.2.2 DatabaseGUI .............................................................................................................. 11 

5.2.3 SynthesizerGUI .......................................................................................................... 12 

5.2.4 Synthesizer ................................................................................................................. 12 

5.2.5 Visualizer ................................................................................................................... 12 

5.3 Identifiering och analys av kritiska klasser ....................................................................... 12 

5.3.1 Kritiska designmoment .............................................................................................. 12 

5.3.2 Kritisk funktionalitet .................................................................................................. 12 

5.3.3 Anmärkning angående animering av ansikte ............................................................. 12 

5.4 Säkerhetsanalys ................................................................................................................. 13 

5.4.1 Informationssäkerhet ................................................................................................. 13 

5.4.2 Systemsäkerhet .......................................................................................................... 13 

5.4.3 Nätverkssäkerhet ........................................................................................................ 13 

5.5 Analys av prestanda ........................................................................................................... 13 

5.6 Analys av skalbarhet .......................................................................................................... 13 

5.7 Alternativ design ............................................................................................................... 14 

5.7.1 Alternativ arkitektur i tre lager .................................................................................. 14 

6 Filformat ................................................................................................................ 17 

iv



PUM 1 2005 



2005-10-11 

6.1 Databas .............................................................................................................................. 17 

6.2 Rörelsedata ........................................................................................................................ 17 

6.3 Ljuddata ............................................................................................................................. 17 

7 Kodbibliotek .......................................................................................................... 19 

7.1 Orator ................................................................................................................................. 19 

7.2 SQLite ................................................................................................................................ 19 

7.3 J2SE ................................................................................................................................... 19 

8 Designanvisningar ................................................................................................. 21 

8.1 Användande av UML ........................................................................................................ 21 

8.2 Designmetodik ................................................................................................................... 21 

8.3 Testbarhet .......................................................................................................................... 21 

8.4 Skalbarhet .......................................................................................................................... 21 

8.5 Databas .............................................................................................................................. 22 

9 Referenser .............................................................................................................. 23 

9.1 Externa dokument .............................................................................................................. 23 

9.2 Interna dokument ............................................................................................................... 23 

9.2.1 Källhänvisning ........................................................................................................... 23 

9.2.2 Befintliga dokument .................................................................................................. 23 

9.2.3 Planerade dokument ................................................................................................... 23 

Bilaga A Modulgränssnitt .............................................................................................................. 25 

A.1 Relationen mellan klasserna ............................................................................................. 25 

A.2 Datatyper .......................................................................................................................... 25 

A.2.1 SynthesizerGUI ......................................................................................................... 26 

A.2.2 Synthesizer ................................................................................................................ 26 

A.2.3 Processor ................................................................................................................... 26 

A.2.4 Visualizer .................................................................................................................. 27 

A.2.5 DatabasGUI ............................................................................................................... 27 

A.2.6 Database .................................................................................................................... 28 

Bilaga B Aktivitetsdiagram ............................................................................................................ 29 

B.1 Lägga till post i databas .................................................................................................... 29 

B.2 Radera post i databas ........................................................................................................ 30 

B.3 Redigera post i databas .....................................................................................................31 

B.4 Talsyntes ........................................................................................................................... 32 

Bilaga C Spårbarhet ....................................................................................................................... 33 

C.1 Funktionella krav .............................................................................................................. 33 

C.2 Icke-funktionella krav ....................................................................................................... 34 

v



PUM 1 2005 



2005-10-11 

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



PUM 1 2005 



2005-10-11 

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



PUM 1 2005 



2005-10-11 

HCS 

IDA 

LiTH 

LiU 

Signalbehandling 

Talkurvan 

Human-Centered Systems. En avdelning vid IDA. 

Institutionen för datavetenskap 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



PUM 1 2005 



2005-10-11 

4 Kapitel 1: Inledning



PUM 1 2005 



2005-10-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 Institutionen för datavetenskap 

vid Linköpings tekniska högskola 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



PUM 1 2005 



2005-10-11 

6 Kapitel 2: Systemöversikt



PUM 1 2005 



2005-10-11 

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 

3.2.1 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. 

3.2.2 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



PUM 1 2005 



2005-10-11 

8 Kapitel 3: Övergripande designbeslut



PUM 1 2005 



2005-10-11 

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 

4.1.1 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. 

4.1.2 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 

4.2.1 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. 

4.2.2 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



PUM 1 2005 



2005-10-11 

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



PUM 1 2005 



2005-10-11 

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. 

5.2.1 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. 

5.2.2 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



PUM 1 2005 



2005-10-11 

5.2.3 SynthesizerGUI 

Testning kan ske enligt samma mönster som för DatabaseGUI. 

5.2.4 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. 

5.2.5 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. 

5.3.1 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. 

5.3.2 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. 

5.3.3 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



PUM 1 2005 



2005-10-11 

5.4 Säkerhetsanalys 

5.4.1 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. 

5.4.2 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. 

5.4.3 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: 




PUM 1 2005 



2005-10-11 

• 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. 

5.7.1 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 




PUM 1 2005 



2005-10-11 

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. 




PUM 1 2005 



2005-10-11 




PUM 1 2005 



2005-10-11 

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



PUM 1 2005 



2005-10-11 

18 Kapitel 6: Filformat



PUM 1 2005 



2005-10-11 

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



PUM 1 2005 



2005-10-11 

20 Kapitel 7: Kodbibliotek



PUM 1 2005 



2005-10-11 

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



PUM 1 2005 



2005-10-11 

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



PUM 1 2005 



2005-10-11 

9 Referenser 

9.1 Externa dokument 

[Projekt Orator, 2005] Projekt Orator (2005), LeveransRapport fas 4,5, DataDesign 

2005-08-31 

[OMG, 2003] Object Management Group, Inc. “OMG Unified Modeling Language 

Specification”, 

9.2 Interna dokument 

9.2.1 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: 

http://und.ida.liu.se/~pum1/dokument 

9.2.2 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. 

9.2.3 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



PUM 1 2005 



2005-10-11 

24 Kapitel 9: Referenser



PUM 1 2005 



2005-10-11 

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



PUM 1 2005 



2005-10-11 

A.2.1 



+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



PUM 1 2005 



2005-10-11 

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



PUM 1 2005 



2005-10-11 

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



PUM 1 2005 



2005-10-11 

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



PUM 1 2005 



2005-10-11 

B.2 Radera post i databas 

30 Bilaga B: Aktivitetsdiagram



PUM 1 2005 



2005-10-11 

B.3 Redigera post i databas 

Bilaga B: Aktivitetsdiagram 31



PUM 1 2005 



2005-10-11 

B.4 Talsyntes 

32 Bilaga B: Aktivitetsdiagram



PUM 1 2005 



2005-10-11 

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



PUM 1 2005 



2005-10-11 

C.2 Icke-funktionella krav 

Krav Benämning Kapitel/Modul 

I-1.1 Separat system 2.3 

I-1.2 Systemmiljö - Windows 3.2.1 

I-1.3 Systemmiljö - Unix 3.2.1 

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

Arkitekturspecifikation - Lysator

Create successful ePaper yourself

Delete template?

Save as template?