ADD - KTH

ADD 1.1
18 mars, 2003
Mobile3D
Författare och projektmedlemmar:
Anders Samuelsson
Erik Tigerholm
Gunnar Höyland
Mario Fredriksson
Mats Svensson
Mikael Olsson
Rickard Strand
Robin Dyer
Stefan Wikell
MM & M
Mini Me and Me
Sammanfattning
Projektgruppen Mini Me and Me har för avsikt att utveckla ett
funktionabellt 3D-modellerande program för mobila handdatorer.
Mobile3D ADD 1.0 är ett dokument fyllt med fakta om hur detta
program ska implementeras, vilka krav som ställs på mjukvaran,
beskriver programmets komponenter och i vilken ordning dessa bör
implementeras.
1
2
3
4
5
Introduktion .................................................................................................................. 7
1.1 Syfte..................................................................................................................... 7
1.2 Kort beskrivning av produkten ............................................................................ 7
1.3 Definitioner och förkortningar ............................................................................ 7
1.4 Referenser ............................................................................................................ 9
1.4.1 Böcker ..................................................................................................... 9
1.4.2 Webbsidor ............................................................................................. 10
1.5 Överblick över dokumentet ............................................................................... 10
System översikt .......................................................................................................... 13
2.1 System design .................................................................................................... 13
System innehåll .......................................................................................................... 14
3.1 Externa gränssnitt .............................................................................................. 14
3.1.1 Exportering ........................................................................................... 14
3.1.2 Konvertering ......................................................................................... 14
System design ............................................................................................................. 15
4.1 Design metoder.................................................................................................. 15
4.1.1 Klass diagram ....................................................................................... 15
4.1.2 Sekvens diagram .................................................................................. 15
4.1.3 MVC .................................................................................................... 15
4.2 Beskrivning av enskilda komponenter .............................................................. 16
4.2.1 GraphicalObject ................................................................................... 17
4.2.2 UserCommand ..................................................................................... 17
4.2.3 Controller ............................................................................................. 17
4.2.4 ToolbarHandler .................................................................................... 17
4.2.5 Renderer ............................................................................................... 18
4.2.6 View ..................................................................................................... 18
4.2.7 Camera ................................................................................................. 18
4.2.8 DataModel ............................................................................................ 19
4.3 Spara till ett internt filformat ............................................................................. 19
4.3.1 Specifikation för Mobile3D Format (M3F) ......................................... 20
Komponentbeskrivning .............................................................................................. 23
5.1 Mobile3DMain .................................................................................................. 23
5.1.1 Typ ....................................................................................................... 23
5.1.2 Syfte ..................................................................................................... 23
5.1.3 Funktion ............................................................................................... 23
5.1.4 Delkoponenter ...................................................................................... 23
5.1.5 Beroenden ............................................................................................ 24
5.1.6 Interface ............................................................................................... 24
5.1.7 Resurser ................................................................................................ 24
5.1.8 Referenser ............................................................................................ 24
5.1.9 Metod ................................................................................................... 24
5.1.10 Data ...................................................................................................... 24
5.2 DataModel ......................................................................................................... 24
5.2.1 Typ ....................................................................................................... 24
5.2.2 Syfte ..................................................................................................... 25
5.2.3 Funktion ............................................................................................... 25
5.2.4 Delkomponenter ................................................................................... 26
5.3
5.4
5.5
5.6
5.2.5 Beroenden ............................................................................................ 26
5.2.6 Interface ............................................................................................... 26
5.2.7 Resurser ................................................................................................ 27
5.2.8 Referenser ............................................................................................ 27
5.2.9 Metod ................................................................................................... 27
5.2.10 Data ...................................................................................................... 27
Camera............................................................................................................... 27
5.3.1 Typ ......................................................................................................... 27
5.3.2 Syfte ..................................................................................................... 27
5.3.3 Funktion ............................................................................................... 28
5.3.4 Delkomponenter ................................................................................... 28
5.3.5 Beroenden ............................................................................................ 28
5.3.6 Interface ............................................................................................... 29
5.3.7 Resurser. ............................................................................................... 29
5.3.8 Referenser ............................................................................................ 29
5.3.9 Metod ................................................................................................... 29
5.3.10 Data ...................................................................................................... 29
GraphicalObject ................................................................................................. 30
5.4.1 Typ ....................................................................................................... 30
5.4.2 Syfte ..................................................................................................... 30
5.4.3 Funktion ............................................................................................... 30
5.4.4 Delkomponenter ................................................................................... 31
5.4.5 Beroenden ............................................................................................ 31
5.4.6 Interface ............................................................................................... 31
5.4.7 Resurser. ............................................................................................... 31
5.4.8 Referenser ............................................................................................ 32
5.4.9 Metod ................................................................................................... 32
5.4.10 Data ...................................................................................................... 32
Controller........................................................................................................... 32
5.5.1 Typ ....................................................................................................... 32
5.5.2 Syfte ..................................................................................................... 32
5.5.3 Funktion ............................................................................................... 33
5.5.4 Delkomponenter ................................................................................... 34
5.5.5 Beroenden ............................................................................................ 34
5.5.6 Interface ............................................................................................... 34
5.5.7 Resurser ................................................................................................ 35
5.5.8 Referenser ............................................................................................ 35
5.5.9 Metod ................................................................................................... 36
5.5.10 Data ...................................................................................................... 36
UndoStack ......................................................................................................... 36
5.6.1 Typ ....................................................................................................... 36
5.6.2 Syfte ..................................................................................................... 36
5.6.3 Funktion ............................................................................................... 36
5.6.4 Delkomponenter ................................................................................... 37
5.6.5 Beroenden ............................................................................................ 37
5.6.6 Interface ............................................................................................... 37
5.6.7 Resurser ................................................................................................ 38
5.6.8 Referenser ............................................................................................ 38
5.6.9 Metod ................................................................................................... 38
5.6.10 Data ...................................................................................................... 39
5.7 Undo .................................................................................................................. 39
5.7.1 Typ ....................................................................................................... 39
5.7.2 Syfte ..................................................................................................... 39
5.7.3 Funktion ............................................................................................... 40
5.7.4 Delkomponenter ................................................................................... 40
5.7.5 Beroenden ............................................................................................ 40
5.7.6 Interface ............................................................................................... 40
5.7.7 Resurser ................................................................................................ 40
5.7.8 Referenser ............................................................................................ 41
5.7.9 Metod ................................................................................................... 41
5.7.10 Data ...................................................................................................... 41
5.8 UserCommand ................................................................................................... 41
5.8.1 Typ ....................................................................................................... 41
5.8.2 Syfte ..................................................................................................... 41
5.8.3 Funktion ............................................................................................... 42
5.8.4 Delkomponenter ................................................................................... 43
5.8.5 Beroenden ............................................................................................ 44
5.8.6 Interface ............................................................................................... 44
5.8.7 Resurser ................................................................................................ 44
5.8.8 Referenser ............................................................................................ 45
5.8.9 Metod ................................................................................................... 45
5.8.10 Data ...................................................................................................... 45
5.9 View .................................................................................................................. 45
5.9.1 Typ ....................................................................................................... 45
5.9.2 Syfte ..................................................................................................... 45
5.9.3 Funktioner ............................................................................................ 46
5.9.4 Delkomponenter ................................................................................... 46
5.9.5 Beroende .............................................................................................. 46
5.9.6 Interface ............................................................................................... 46
5.9.7 Resurser ................................................................................................ 47
5.9.8 Referenser ............................................................................................ 47
5.9.9 Metod ................................................................................................... 47
5.9.10 Data ...................................................................................................... 48
5.10 Renderer ............................................................................................................ 48
5.10.1 Typ ....................................................................................................... 48
5.10.2 Syfte ..................................................................................................... 48
5.10.3 Funktioner ............................................................................................ 48
5.10.4 Delkomponenter ................................................................................... 49
5.10.5 Beroende .............................................................................................. 49
5.10.6 Interface ............................................................................................... 49
5.10.7 Resurser ................................................................................................ 49
5.10.8 Referenser ............................................................................................ 49
5.10.9 Metod ................................................................................................... 49
5.10.10 Data ...................................................................................................... 50
5.11 ToolbarHandler ................................................................................................. 50
5.11.1 Typ ....................................................................................................... 50
5.11.2 Syfte ..................................................................................................... 50
5.11.3 Funktion ............................................................................................... 50
6
7
5.11.4 Delkomponenter ................................................................................... 51
5.11.5 Beroende .............................................................................................. 51
5.11.6 Interface ............................................................................................... 51
5.11.7 Resurser ................................................................................................ 51
5.11.8 Referenser ............................................................................................ 52
5.11.9 Metod ................................................................................................... 52
5.11.10 Data ...................................................................................................... 52
5.12 Toolbar .............................................................................................................. 52
5.12.1 Typ ....................................................................................................... 52
5.12.2 Syfte ..................................................................................................... 52
5.12.3 Funktioner ............................................................................................ 52
5.12.4 Delkomponenter ................................................................................... 53
5.12.5 Beroende .............................................................................................. 53
5.12.6 Interface ............................................................................................... 53
5.12.7 Resurser ................................................................................................ 53
5.12.8 Referenser ............................................................................................ 53
5.12.9 Metod ................................................................................................... 54
5.12.10 Data ...................................................................................................... 54
5.13 Button ................................................................................................................ 54
5.13.1 Typ ....................................................................................................... 54
5.13.2 Syfte ..................................................................................................... 54
5.13.3 Funktioner ............................................................................................ 54
5.13.4 Delkomponenter ................................................................................... 54
5.13.5 Beroende .............................................................................................. 55
5.13.6 Interface ............................................................................................... 55
5.13.7 Resurser ................................................................................................ 55
5.13.8 Referenser ............................................................................................ 55
5.13.9 Metod ................................................................................................... 55
5.13.10 Data ...................................................................................................... 55
Resursuppskattning och riskanalys. ............................................................................ 56
6.1 Resursuppskattning ........................................................................................... 56
6.2 Riskhantering..................................................................................................... 57
6.2.1 Arbetet med riskanalysen ..................................................................... 58
6.3 Resursuppskattning ........................................................................................... 58
Spårningsmatris .......................................................................................................... 60
1 Introduktion
1.1 Syfte
Syftet med det här dokumentet är att tolka mjukvarukraven för att
kunna skapa en design som motsvarar produktens syfte. Detta vill vi
göra heltäckande så att alla krav i SRD:n kommer med.
Informationen behöver inte skrivas lika lättillgängligt i ADD:n som i
URD:n då vi inte avser att visa upp ADD:n för någon annan än
projektgruppen. I detta dokument ingår också en lite noggrannare
analys av risker som kan påverka projektet i alla avseenden, samt en
planering över de olika komponenterna.
1.2 Kort beskrivning av produkten
Mobile3D är ett program för handdatorer som kan användas av 3Dprogrammerare och 3D-designers för att lätt kunna skapa enkla
tredimensionella bilder på resande fot. Det är enkelt för nya
användare att komma igång med programmet. Den version som
kommer att hinna bli klar under det här projektet kommer att vara en
nedbantad forskningsversion. Därför duger den endast till att
utforska vad som är möjligt att genomföra med java på handdatorer.
Produkten kommer dock att vara utbyggbar för vidare utveckling
efter projektets slut.
1.3 Definitioner och förkortningar
Java
Programspråk som används för att göra program
för olika ändamål. Man måste använda sig av en
virtuell maskin för att köra ett javaprogram.
Detta för att programmet ska vara
plattformsoberoende.
Plattformsoberoende Oberoende av vilket operativsystem
programmet körs på.
Virtuell maskin
Program som används för att tolka och köra
javaprogram.
J2SE
Standardversionen av programspråket java som
används för att göra plattformsoberoende
program för stationära datorer.
J2ME
Reducerad javaversion som används för att
programmera handdatorer och andra bärbara
enheter.
VRML
Virtual Reality Modeling Language – Filformat
som används för att spara tredimensionella
grafiska bilder i form av text.
MIDP
Mobile Information Device Profile – En
javaomgivning som gör det möjligt att skapa
och köra javaprogram på bärbara enheter.
OpenGL
Ett slags hjälpmedel för att göra grafiska bilder
och spel genom att programmera.
Palm
Den handdator som har flest marknadsandelar.
Den är liten men inte lika snabb som en Pocket
PC. Den har Palm OS som operativsystem.
Palm Vx
En handdator som är tillverkad av Palm. Den
har en processorhastighet på 20 MHz, en
skärmstorlek på 160x160 och 8 MB i
internminne.
Pocket PC
Lite större handdator än Palm. Den är snabbare
och har dessutom en version av Windows,
Windows CE, som operativsystem.
HotSync
Program som används för att koppla ihop en
Palm och en stationär eller bärbar PC. Detta
görs för att synkronisera informationen i
adressboken, kalendern och mailboxen och i
eventuella andra program. Dessutom används
HotSync till att överföra filer och program till
och från handdatorn.
ActiveSync
Pocket PC´s motsvarighet till Palmens HotSync.
Palm OS
Operativsystemet som Palm använder sig av.
Det är fönsterbaserat och kan bara köra program
som är anpassade för Palm OS.
Emulator
Ett program för PC eller Mac för att simulera en
Palm eller Pocket PC. Detta är ett nyttigt
hjälpmedel när man programmerar handdatorn.
Windows CE
Operativsystemet som används i Pocket PC. Det
är en variant av Windows vilket gör att många
användare känner igen sig.
KVM
K Virtual Machine – En ny virtuell maskin som
byggts upp från grunden. Det är anpassat för att
kunna köras på bärbara enheter med litet
minnesutrymme.
MVC
Model-View-Controller – Objektorienterad
struktur som används för att dela upp
programmet i olika delar. Dessa delar är
modellen som är själva funktionaliteten, vyn
som är gränssnittet och controllern som
bestämmer vad som ska göras.
Conduit-program
Pluginprogram som körs när HotSync startas.
Detta program kan t.ex. kopiera filer från
handdatorn till stationära datorn.
Klassdiagram
Ett diagram som i det här dokumentet beskriver
vilka klasser vi har och hur de relaterar till
varandra.
Use Case
En beskrivning av hur arbetsgången hos
specifika funktioner vanligtvis går till vid
användandet av programmet.
SD
Sequence Diagram – Ett sekvensdiagram är ett
diagram som beskriver ett use-case grafiskt.
1.4 Referenser
1.4.1 Böcker
Ames, A., Nadeau, D. & Moreland J. 1996. The VRML
Sourcebook. ISBN 0-471-14159-3
Angel, E. 2000. Interactive Computer Graphics. Andra
upplagan. ISBN 0-201-38597-X
Enrique Ortiz, C. & Giguère, E. 2001. Mobile
Information Device Profile for Java2 Micro Edition.
ISBN 0-471-03465-7
Kalwick, D. 1996. 3D Graphics - Tips, tricks, &
techniques. ISBN 0-12-394970-X
Pogue, D. 1998. PalmPilot - The Ultimate Guide.
ISBN 1-56592-420-7
Gamma, E., Helm, R., Johnson, R., Vlissides, J. 1994.
Design Patterns. ISBN 0-201-63361-2
1.4.2 Webbsidor
http://java.sun.com/products/midp/
http://java.sun.com/products/cldc/
http://wireless.java.sun.com/
http://wireless.java.sun.com/j2me/index.html
http://www.gamedev.net/
http://www.palm.com
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
http://www.nada.kth.se/projects/proj03/minime/
http://www.opengl.org/
http://www.vrml.org/
http://www.palm.com/developers/
http://www.palmsource.com/developers/
http://www.palmos.com/dev/tools/
1.5 Överblick över dokumentet
Kapitel 1: Introduktion
1.1
Syfte – En beskrivning av syftet med det här dokumentet och
vad vi får ut av det.
1.2
Kort beskrivning av produkten – En kort beskrivning av
produktens omfattning efter det här projektet.
1.3
Definitioner och förkortningar – Förklaringar på tekniska
termer och förkortningar som används i detta dokument.
1.4
Referenser – Samling av böcker och webbsidor från vilka vi
har fått information till detta dokument.
1.5
Överblick över dokumentet – Den här avdelningen som
beskriver mer i detalj vad man hittar under varje rubrik.
Kapitel 2: Överblick över systemet
2
Överblick över systemet – Beskriver hur produkten
kommunicerar med externa system. Beskriver också systemdesignen
på ett lite mindre detaljerat sätt. (Systemdesignen beskrivs mer
detaljerat i kap 3 och 4.)
Kapitel 3: Systeminnehåll
3
Systeminnehåll – Beskriver vad systemet innehåller och hur
systemet använder sig av externa program.
Kapitel 4: Systemdesign
4.1
Designmetod – Beskriver vilken designmetod som använts.
4.2
Uppdelning av komponenter – Ger en överblick över de
största komponenterna. Identifierar dataflödet mellan komponenter.
(Komponenterna kommer att beskrivas i detalj i kap 5).
Kapitel 3: Systeminnehåll
5.n
Komponentnamn – Ett passande namn för komponenten.
5.n.1
Typ – Beskriver vilken typ komponenten är. Detta kan vara
t.ex. en klass eller ett program.
5.n.2
Syfte – Beskriver syftet med komponenten och hänvisar till
ett numrerat krav från SRD:n.
5.n.3
Funktion – Beskriver komponentens funktionalitet samt
dess gränssnitt.
5.n.4
Delkomponenter – Listar alla delkomponenter som
används av denna komponent.
5.n.5
Beroenden – Beskriver de logiska villkoren för att använda
komponenten.
5.n.6
Interface – Beskriver hur komponenten kommunicerar
med andra komponenter.
5.n.7
Resurser – Listar kraven som komponenten ställer på de
externa systemen.
5.n.8
Referenser – Referenser till dokument som behövs för att
förstå komponenten.
5.n.9
Metod – Beskriver hur denna komponent kommunicerar
med sina delkomponenter.
5.n.10
Data – Beskriver i detalj (så väl det går) värden på de
lokala variablerna och datastrukturerna som hör till komponenten.
Kapitel 6: Resursuppskattning och riskanalys
6.1
Prioritet – Ger en överblick över komponenternas prioritet.
6.2
Riskanalys – En noggrannare analys av riskerna och vad man
kan göra för att minska dem.
6.3
Resursuppskattning – Ger en planering av återstoden av
projektet. Där framgår också i stora drag vilka i gruppen som ska
göra vad.
Kapitel 7: Överblick över systemet
7
Spårningsmatris – Ger en tabell över vilka komponenter i
ADD:n som kommit från vilka mjukvarukrav i SRD:n.
2 System översikt
Vårat system är baserat på MVC (Model/view/Controller) konceptet.
Ytterligare systeminehåll är externa system så som
Exporteringsprogram och Konverteringsprogram.
2.1 System design
Vårat system består I huvudsak av följande komponenter.
 GraphicalObject
 UserCommand
 Controller
 ToolbarHandler
 Renderer
 View
 Camera
 DataModel
För en mer ingående beskrivning av dessa komponenter se 4.2.
3 System innehåll
Här ges en beskrivning av system innehållet. Externa system så som
exportering och konvertering.
3.1 Externa gränssnitt
Här nedan beskrivs exporttering av vårt program. Samt hur det
görs.
3.1.1 Exportering
Vi kommer att utveckla ett system för att kunna synkronisera våra
data mellan en handdator och en vanlig dator.
3.1.1.1 HotSync
Detta behöver vi för att kunna överföra våra 3d filer från palm Vx till
andra plattformar.
HotSync Conduit-program för att exporttera till VRML. Vi kommer
att göra en conduit-program till HotSync. Den kommer exporttera 3dobject på palmpilot till VRML .
Previllkor: Vi har en plattform som stödjer HotSync.
Postvillkor: Vi har konverterat alla våra 3d-object på handdatorn till
VRML på den stationära datorn.
(1) Stoppa handdatorn i dockan.
(2)Tryck på HotSync knappen.
(3) HotSyncManager startas på datorn.
(4) HotSyncManager startar vårt program på datorn.
(5) Vårt program läser in 3d-objektet från handdatorn omvandlar det
till VRML.
3.1.2 Konvertering
Vi kommer att använda oss av ett VRML konverteringsprogram.
Detta program kommer att konvertera vårt interna dataformat till
VRML.
4 System design
Här pressenteras de metoder vi använt oss av under våran
konstruktion till systemdesignen.
4.1 Design metoder
Som grund har vi använt oss av MVC (Model/View/Controller) för
att få struktur på vårat program.
Vi har också använt oss av UML sekvens diagram för att kunna
visualisera hur olika komponenter samverkar med varandra. Vi har
även använt oss av modifierade klass diagram för att visa vilka
komponenter som ingår i våran systemdesign.
4.1.1 Klass diagram
Klass diagram ger en överblick över vilka komponenter som finns på
en hög nivå. Detta gör det enkelt att se vilka funktioner som en
enskild komponenterna ansvarar för. Varje klass innehåller
information om klassnamn, attribut och metoder.
4.1.2 Sekvens diagram
Sekvens diagram visar strukturer på olika delar i modellen på hög
nivå. Det används när man vill visa under ett händelseförlopp, hur
olika komponenter samverkar med varandra. Tidsaxeln är vertikal
och anropen mellan komponenterna sker horisontellt.
4.1.3 MVC
När vi började med projektet bestämde vi oss för att ha basstrukturen
MVC (Model/View/Controller).
Ut efter denna design metod har vi sen kunnat utveckla de resterande
komponenterna till vårat system.
Model:
Våran model kommer att hantera de data och funktioner som behövs
för att abstrakt representera och manipulera våran 3d värld som vi
arbetar på. Den kommer att styra vårat koordinat system, kameran,
olika objekt med mera. Våran modell kommer att få information från
våran Controller. Modellen kommer då att bearbeta informationen
och eventuellt skicka resultatet till View.
View:
Våran View kommer att vara ansvarig för allt som ritas ut på
skärmen. View får data från både Controller och Model om vad som
händer och vet då vad den ska rita upp på skärmen.
Controller:
Controllern kommer att ta hand om indata från användaren, det vill
säga i huvudsak av användarens interaktion med handdatorns
pekskärm. Controller kommer att bestämma hur indata från
användaren ska tolkas och kommer därefter att skicka informationen
vidare till antingen Model och (eller) View.
Model-View-Controller samt Huvudprogram och Toolbar API
4.2 Beskrivning av enskilda komponenter
Våran systemdesign består av ett antal olika komponenter som ska
kunna kommunicera med varandra för att program ska kunna göra det
den är avsedd för.
Följande är de huvudkomponenter vårat system består av:
 GraphicalObject
 UserCommand
 Controller
 ToolbarHandler
 Renderer
 View
 Camera
 DataModel
4.2.1 GraphicalObject
En abstrakt representation av ett objekt. Innehåller uppgift om
position, rotation, valt eller inte, vilken typ av primitiv (om någon),
objektets noder och kanter mm. Kommunicerar med DataModel (se
2.4.8 samt 5.2).
4.2.2 UserCommand
UserCommand mottar information från ToolbarHandler. Information
från ToolbarHandler betyder antingen att aktivt UserCommandobjekt
ska bytas (ev. Till samma objekt) eller att användaren interagerar
med ritytan. Ett UserCommandobjekt representerar i princip en ikons
funktionalitet och avgör hur information från ToolbarHandler ska
tolkas. UserCommand skickar den tolkade informationen till
DataModel, View och Controller.
4.2.3 Controller
Controller får input från handdatorn. Om input har något med
pekskärmen att göra skickas de aktuella skärmkoordinaterna till
ToolbarHandler. Om input är något annat, t.ex. handdatorn mottar ett
telefonsamtal så vidtas lämplig åtgärd. Controller får data från
ToolbarHandler och Command och sänder data till DataModel och
View.
Klasser som utgör Controller.
4.2.4 ToolbarHandler
Varje verktygsfällt (se SRD 3.1.3.2) har en egen ToolbarHandler.
Dessa mottar skärmkoordinater från Controller och avgör om någon
knapp i verktygsfältet har de koordinaterna eller inte. Vidarebefordrar
informationen till rätt UserCommandobjekt. För att se hur
ToolbarHandler passar in i arkitekturen se 4.2.6.
4.2.5 Renderer
Renderer ansvarar för utritningen av den så kallade markeringsramen,
rutnätet (se SRD 3.1.2.2) och 3d-objekten till skärmen. I fallet att 3dobjekten ska ritas så hämtar/får Renderer information från DataModel
(via View), tolkar detta tillsammans aktuella tillstånds variabler och
ritar ut ofyllda polygoner till skärmen. Tillståndsvariabler är t.ex.
aktuell kameraposition, om polygonerna ska perspektivprojiceras
eller parallellprojiceras. Hur resultatet av projiceringarna (se SRD
3.1.2.2) blir beräknar renderer.
Får och mottar data från DataModel och Controller genom View.
4.2.6 View
Samordnar allt som ska ritas ut på skärmen och kommunicerar med
DataModel samt Controller. Dellegerar uppgifter till Renderer och
Toolbar.
View och dess delar.
4.2.7 Camera
Camera håller reda på vilken vy användaren för tillfället befinner sig
i, vinkel mot koordinataxlarna, zoomning, projektion mm. Den
ansvarar även för funktionaliteterna inzoomning, utzoomning och
förflyttning (se SRD 3.1.1.2). Camera får data från DataModel och
sänder data till View (se 4.2.6).
4.2.8 DataModel
DataModel får data från Controller (se 4.2.3) som den tolkar och
utifrån det t.ex. ändrar tillståndsvariabler eller skickar vidare
uppgifterna till Camera, GraphicalObject och View (se 4.2.6).
DataModel håller reda på alla objekt samt kameran, d.v.s. en
representation av 3d-världen.
DataModel utför även transformationerna på objekten, rotation,
förflyttning, skalning och radera (se SRD 3.1.1.1). DataModel ändrar
därmed data i GraphicalObject.
DataModel
4.3 Spara till ett internt filformat
När vi sparar en 3d primitiv gör vi detta i ett internt filformat. Den
information som behöver sparas i filen behöver innehålla följande:
 Figur typ Ex Cone eller Kub o.s.v.
 Filens namn.
 Allt som ligger i Camera.
 Allt som ligger i DataModel.
 Allt som ligger i GraphicalObject.
4.3.1 Specifikation för Mobile3D Format (M3F)
Inledning
M3F är ett binärt format som används för att lagra data som har
skapats i Mobile3D.
Formatet kommer också att stödjas av Mobile3D's
konverteringsprogram som har formatet som indata.
Filorganisation
M3F har inte en ”riktig” header som andra format, utan denna header
innehåller bara ett ”magiskt” tal (2 bytes) som används för att
verifiera att det är en M3F -fil. Detta identiferingstal är talet 029Ah.
Sedan kommer modellens namn (filnamn).
Position Data
00h
stringSize
01h
modelStr
StringSize anger hur många tecken (chars) modelStr innehåller.
ModelStr anger modellens namn.
Direkt efter detta namn så följer en serie av olika block. Varje block
börjar med ett tal som indikerar vad för sorts objekt blocket
innehåller. Giltiga data för dessa tal är:
01h
GrOBox
02h
GrOSphere
03h
GrOCone
04h
GrOCylinder
05h
CAMERA_FRONT
06h
CAMERA_SIDE
07h
CAMERA_TOP
08h
CAMERA_FREE
09h-FFh är reserverade för framtida bruk.
En M3F datafil kan innehålla ett godtyckligt antal av dessa objekt i
godtycklig ordning.
Fildetaljer
M3F-objekten GrOBox, GrOSphere, GrOCone och GrOCylinder har
samma datastruktur, vilket visas nedan:
Position
00h
02h
04h
06h
08h
0Ah
0Ch
0Eh
10h
Data
position_x
position_y
position_z
scale_x
scale_y
scale_z
rotate_x
rotate_y
rotate_z
Strukturen är alltså 36 bytes (9 integers) stor.
Position_x, position_y och position_z representerar positionen i
världen relativt till origo där objeket befinner sig.
Scale_x, scale_y och scale_z bestämmer hur objektet ska förändras
(skalas) i respektive axelriktning.
Rotate_x, rotate_y och rotate_z bestämmer hur mycket objektet skall
roteras i respektive rotationsaxel.
M3F-objekten CAMERA_FRONT, CAMERA_SIDE,
CAMERA_TOP, CAMERA_FREE har samma datastruktur, vilket
visas nedan:
Position
00h
02h
04h
06h
08h
0Ah
Data
position_x
position_y
position_z
look_at_x
look_at_y
look_at_z
Strukturen är alltså 24 bytes (6 integers) stor.
Position_x, position_y och position_z representerar positionen i
världen relativt till origo där kameran befinner sig.
Look_at_x, look_at_y och look_at_z representerar positionen i
världen relativt till origo som kameran tittar mot.
Behov: Ja.
Stabilt: Ja.
Källa: MM&M.
Prioritet: 1.
Verifierbarhet: Man kan ladda in en sparad modell.
Motivation: Nödvändig för att kunna lagra modell.
5 Komponentbeskrivning
Det här kapitlet innehåller en noggrannare beskrivning av varje
komponent beskriven i kap. 4. Komponenterna är uppdelade efter
Model-View-Controller-modellen (MVC, se Gamma) och listar varje
komponent som ingår i respektive del. Dock så stödjer inte J2ME
hela MVC-konceptet, vilket kommer innebära att den
implementerade designen kommer skilja sig något från den logiska.
Varje komponent kan ses som en som en delkomponent i antingen
Model, View eller Controller men kommer implementeras som en
egen klass.
Klassdiagrammen (se 4) är referens till respektive komponent.
5.1 Mobile3DMain
5.1.1 Typ
Komponent. Eventuellt Klass.
5.1.2 Syfte
Används för att knyta samman programmets delar och härifrån startar
exekveringen.
5.1.3 Funktion
5.1.3.1 main
Beskrivning: Initsierar kärnan programmet.
Argument: En String array.
Returnerar: void.
5.1.4 Delkoponenter
Äger direkt en DataModel (se 5.2) ,en View (se 5.9) samt en
Controller (se 5.5). Dessa komponenter/klasser utgör programmet.
5.1.5 Beroenden
Inga beroenden förekommer.
5.1.6 Interface
Se klassdiagram 4.?
5.1.7 Resurser
Inga externa resurser krävs.
5.1.8 Referenser
Resterande av kap 5.
5.1.9 Metod
Klassen är mycket liten, kommer endast att starta igång programmet.
DataModel dm = new DataModel();
Controller crtl = new Controller(dm);
View v = new View(ctrl, dm);
5.1.10 Data
Klassen består av en DataModel (se 5.2) ,en View (se 5.9) samt en
Controller (se 5.5).
5.2 DataModel
5.2.1 Typ
Klass. Kan även betraktas på komponentnivå.
5.2.2 Syfte
Model-klassens syfte och funktion är att tillhandahålla en datastruktur
för att lagra 3D-objekt. Model lagrar även de olika kamerorna. View
använder sedan metoder i Model för att rita ut objekten på skärmen.
Datastrukturen representerar hale 3D-modellen som kan ändras
oberoende av vad som visas av gränssnittet. Detta är viktigt eftersom
datarepresentationen eventuellt ska kunnas bytas i framtiden. Man
vill heller inte alltid visa samtliga ändringar i modellen på skärmen
av prestandaskäl.
5.2.3 Funktion
5.2.3.1 setActive
Beskrivning: Applikationen kan ha ett GraphicalObject aktivt, vilket
idikerar att objektet är markerat. För att sätta ett GraphicalObject
aktivt används denna metod.
Argument: Ett GraphicalObject.
Returnerar: void.
5.2.3.2 getActive
Beskrivning: Returnerar det just nu markerade 3D-objetet.
Argument: void.
Returnerar: Ett GraphicalObject.
5.2.3.3 addGrO
Beskrivning: Används för att lägga till ett 3D-objekt till
datastrukturen.
Argument: Ett GraphicalObject.
Retunerar: void.
5.2.3.4 deleteGrO
Beskrivning: Används för att ta bort ett 3D-objekt.
Argument: void.
Returnerar: Ett GraphicalObject. Detta för att kunna implementera
undo-funktionalitet.
5.2.3.5 getCamera
Beskrivning: Returnerar aktiv kamera.
Argument: void.
Returnerar: En Camera.
5.2.3.6 setActiveCamera
Beskrivning: Sätter en kamera som aktiv.
Argument: En Camera.
Returnerar: void.
5.2.3.7 getGrOVector
Beskrivning: Returnerar samtliga GraphicalObject i datastrukturen i
en Vector.
Argument: void.
Returnerar: En Vector innehållande samtliga GraphicalObject i
strukturen.
5.2.3.8 save
Beskrivning: Sparar ner den interna datastrukturen med 3D-objekt
och kameror till angivet filnamn i det interna filformatet (se 4).
Metoden kontrollerar att filnamnet är giltigt
Argument: En String innehållande ett filnamn.
Returnerar: void.
5.2.3.9 load
Beskrivning: Laddar in en i det interna filformatet (se 4) sparad 3Dmiljö från angiven fil.
Argument: En String innehållande ett filnamn.
Returnerar: void.
5.2.4 Delkomponenter
Model kommer att innehålla någon datastruktur (se 5.2.10)
5.2.5 Beroenden
Inga beroenden förekommer.
5.2.6 Interface
Se klassdiagram 4.? Kommunicerar genom de publika metoderna (se
5.2.3)
5.2.7 Resurser
Måste kunna läsa och skriva till sekundärminnet.
5.2.8 Referenser
Model-View-Controller konceptet se kap 4.?
Model-View-Controller konceptet se referenser kap 1.4
Model-View-Controller se Gamma
5.2.9 Metod
Model är enkelt uppbyggd, endast innehållande en datastruktur som
håller GraphicalObject-onjekten och de Camera:s som används.
Model gör själv inga förändringar eller modifieringar av dessa objekt
utan fungerar enbart som struktur för dem. Den interna datastrukturen
kan bytas ut genom att användbara datastrukturer implementerar
generella gränssnitt definierade i J2ME.
5.2.10 Data
En datastruktur kommer att finnas. Vilken är ännu ej fastställt men
troligen räcker en enkel dubbellänkad lista. Relativt få objekt
kommer att finnas så prestanda vid sökning av objekt är inget stort
problem. Däremot är det önskvärt att man enkelt och snabbt kan få
fram en lista av objekten.
Referenser till markerade objekt GraphicalObject:s och aktiv Camera
måste finnas.
5.3 Camera
5.3.1 Typ
Klass.
5.3.2 Syfte
Camera används för att representera en kamera och dess interna
tillstånd, exempelvis dess position och riktning. Utseendet på en 3Dmiljö är olika beroende på var kameran befinner sig och var det är
riktad mot. Man måste ha möjlighet att se ur olika vinklar.
5.3.3 Funktion
5.3.3.1 getDownVector
Beskrivning: Behövs för att kunna avgöra – utifrån kameran – vad
som är neråt.
Argument: void
Returnerar: En Vector3D
5.3.3.2 getRightVector
Beskrivning: Behövs för att kunna avgöra – utifrån kameran – vad
som är höger.
Argument: void.
Returnerar: En Vector3D.
5.3.3.3 setDistance
Beskrivning: Används för att ändra avstånd till rumments origo, dvs
koordinaten (0,0,0).
Argument: En int.
Returnerar: void.
5.3.3.4 getPosition
Beskrivning: Används för att hämta kamerans position.
Argument: void.
Returnerar: Vector3D.
5.3.3.5 moveTo
Beskrivning: Används för att flytta kameran.
Argument: Två heltal, motsvarande vinkel från origo.
Returnerar: void.
5.3.4 Delkomponenter
I en senare version kommer Camera fungera som en generalisering av
en parallellprojicerad kamera. Denna kommer då att ha samma
representation men måste skriva över en del metoder.
5.3.5 Beroenden
Behöver klassen Vector3D.
5.3.6 Interface
Se klassdiagram 4.?
5.3.7 Resurser.
Inga externa resurser krävs.
5.3.8 Referenser
Kamerabegreppet (se kap 1.4)
5.3.9 Metod
En förflyttning av kameran kan behöva närmare beskrivning. I den
perspektivprojicerade kameran så rör man på en imaginär sfär med
centrum i origo (se SRD 3.1). En förflyttning kan då göras antingen
genom att göra sfären mindre – använd setDistance(dist: int) – eller
genom att ange två vinklar som beskriver en förflyttning på sfären.
Den senare (sfäriska koordinater) beräknas utifrån formeln:
x=Rsin(v)cos(u)
y=Rsin(v)sin(u)
z=Rcos(v)
Där v och u mostsvarar vinklarna fi och theta i bilden och R är
sfärens radie.
5.3.10 Data
Camera kommer att internt representeras av dels en position, dels av
en punkt den är riktad mot. Denna respresentation fungerar i både
parallell och perspektivprojektioner.
5.4 GraphicalObject
5.4.1 Typ
Abstrakt klass.
5.4.2 Syfte
GraphicalObject behövs för att representera 3D-objekt.
5.4.3 Funktion
5.4.3.1 move
Beskrivning: Används för att uppdatera objektets
positionskomponent (se 5.4.10).
Argument: En Vector3D.
Returnerar: void.
5.4.3.2 rotate
Beskrivning: Används för att uppdatera objektets
rotationskomponent (se 5.4.10).
Argument: En Vector3D.
Returnerar: void.
5.4.3.3 scale
Beskrivning: Används för att uppdatera objektets
skalningskomponent (se 5.4.10).
Argument: En Vector3D.
Returnerar: void.
5.4.3..4 getPoints
Beskrivning: Abstrakt. Returnerar objektets samtliga punkter.
Argument: void.
Returnerar: en array av Vector3D
5.4.3.5 getLines
Beskrivning: Abstrakt. Returnerar objektets samtliga linjer.
Argument: void.
Returnerar: en array av Lines.
5.4.3.6 getPosition
Beskrivning: Returnerar objektets positionskomponent (se 5.4.10)
Argument: void.
Returnerar: Vector3D
5.4.3.7 getRotation
Beskrivning: Returnerar objektets rotationskomponent (se 5.4.10)
Argument: void.
Returnerar: Vector3D
5.4.3.6 getScale
Beskrivning: Returnerar objektets skalningskomponent (se 5.4.10)
Argument: void.
Returnerar: Vector3D
5.4.4 Delkomponenter
Då detta är en abstrakt klass så kommer den inte kunna instansieras.
Varje 3D-primitiv kommer därför bli en specialisering av
GraphicalObject. Dessa klasser kommer att vara:
(1) GrOSphere
(2) GrOCone
(3) GrOBox
(4) GrOCylinder
Dessa klasser kommer att definieras av olika uppsättningar av
punkter och linjer. Metoderna kommer att vara de samma som i den
generaliserade klassen och det är upp till konstruktorerna i varje
enskilt objekt att se till att det skapas på rätt sätt.
5.4.5 Beroenden
För att instansiera och använda objektet behövs en av
GraphicalObject ärvd klass. Dess konstruktor behöver indata som
kommer från användarens rörelser med pekpennan.
5.4.6 Interface
Se klassdiagram 4.?
5.4.7 Resurser.
Inga externa resurser krävs.
5.4.8 Referenser
Beskrivning av 3D-primitiver se kap URD.
5.4.9 Metod
Den enda metoder med funktionskropp kommer att vara:
Public void move(Vector3D v) {
position.setTo(v)
}
Public void rotate(Vector3D v) {
rotation.setTo(v)
}
Public void scale(Vector3D v) {
scale.setTo(v)
}
5.4.10 Data
Objektens struktur kommer att representeras av en samling punkter
och en samling linjer. Dessa representeras troligen bäst i form av en
array av vector3D och Lines.
5.5 Controller
5.5.1 Typ
Klass
5.5.2 Syfte
Controller implementerar det i java inbyggda interfacet Canvas.
Därigenom får canvas input från pekskärmen. Indata kan bestå i att:
pennan har satts ner på skärmen, pennan dras på skärmen, pennan
lämnar skärmen. Indata skickas vidare till aktivt Commandobjekt.
Se SRD 3.1.3.1
5.5.3 Funktion
5.5.3.1 penPressed
Beskrivning: Då pennan sätts ned på skärmen får penPressed de
skärmkoordinater (x, y) där pennan satts ned.
Argument: skärmkoordinater (x,y) av typen int.
Returnerar: void.
5.5.3.2 penDragged
Beskrivning: Då pennan dras på skärmen kommer penDragged
kontinuerligt att anropas med de nya skärmkoordinaterna (x, y) där
pennan befinner sig.
Argument: skärmkoordinater (x,y) av typen int.
Returnerar: void.
5.5.3.3 penReleased
Beskrivning: Då pennan lämnar skärmen får penReleased de
skärmkoordinater (x, y) som var de absolut senaste innan pennan
lyftes från skärmen.
Argument: skärmkoordinater (x,y) av typen int.
Returnerar: void.
5.5.3.5 setActiveCmd
Beskrivning: Det är alltid ett UserCommandobjekt (se 5.8) aktivt.
Vilket det är beror på input från användaren. setActiveCmd ändrar
aktivt UserCommandobjekt till det objekt den får som argument.
Argument: Ett UserCommandobjekt, cmd.
Returnerar: void.
5.5.3.6 setToolbarHandler
Beskrivning: Sätter aktivt ToolbarHandlerobjekt. Kan endast finnas
ett aktivt objekt och kommer i praktiken att sättas då programmet
initieras.
Argument: Ett ToolbarHandlerobjekt, tbh.
Returnerar: void.
5.5.4 Delkomponenter
UserCommand.
5.5.5 Beroenden
Inga.
5.5.6 Interface
Tar emot input från pekskärmen via ett canvasinterface och skickar
dessa vidare till ToolbarHandler (se 5.11). Om ToolbarHandler
returnerar false vidarebefordras informationen till aktivt
UserCommandobjekt. Om ToolbarHandler returnerar true så vidtas
inga vidare åtgärder.
Sekvensdiagram 5.5.6:1 visar dataflödet till och från Controller.
Sekvensdiagram 5.5.6:1
5.5.7 Resurser
Måste kunna få input från pekskärmen.
5.5.8 Referenser
UserCommand (5.8) och ToolbarHandler (5.11).
ADD 3.1.3.1
5.5.9 Metod
Controller gör inga beräkningar eller förändringar i datastrukturer.
Däremot kan referenserna till aktivt UserCommandobjekt och
ToolbarHandlerobjekt ändras. Det finns alltid ett och endast ett av
respektive objekt aktivt.
5.5.10 Data
Referenser till aktivt UserCommandobjekt och
ToolbarHandlerobjekt.
5.6 UndoStack
5.6.1 Typ
Klass.
5.6.2 Syfte
UndoStacken är en implementation av lagringsstrukturen stack. Den
lagrar Undoobjekt (se 5.7) som behövs för att undofunktionen (SRD
3.4.5.3) ska kunna realiseras. UndoStackens kapacitet, dvs. hur
många Undoobjekt den kan hålla, bestäms vid initieringen.
UndoStackens kapacitet kan alltså varieras beroende på
minnestillgång.
5.6.3 Funktion
5.6.3.1 push
Beskrivning: Lägger ett Undoobjekt sist i stacken. Om stacken är
full försvinner det Undoobjekt som ligger först i stacken.
Argument: Ett Undoobjekt.
Returnerar: void.
5.6.3.2 pop
Beskrivning: Returnerar det Undoobjekt som ligger sist i stacken
samt avlägsnar det från stacken. Om stacken är tom returneras null.
Det är i praktiken bara UserCommandobjektet CmdUndo (se 5.8)
som kommer att anropa den här funktionen.
Argument: void.
Returnerar: Ett Undoobjekt alternativt null om stacken är tom.
5.6.4 Delkomponenter
Undo.
5.6.5 Beroenden
Inga.
5.6.6 Interface
UndoStacken får anrop till pop från UserCommandobjektet
CmdUndo. Returnerar då det Undoobjekt som ligger först på stacken
eller null om den är tom. Aktivt UserCommandobjekt anropar push
med ett Undoobjekt som argument. Sekvensdiagram 5.6.6:1 visar
flödet till och från UndoStack.
Sekvensdiagram 5.6.6:1
5.6.7 Resurser
Kräver inga externa resurser.
5.6.8 Referenser
Undo (5.7), UserCommand (5.8), avsnittet om undofunktionen i SRD
(3.4.5.3)
5.6.9 Metod
Konstanten SIZE är given och större än noll. Vad det hela går ut på är
att Undoobjekten lagras i en array med kapaciteten SIZE. pop tar bort
det element som ligger sist i stacken och returnerar det, eventuellt
null om stacken är tom. Push lägger till ett objekt på stacken. Om
stacken är full så försvinner det objekt som ligger först. Här är
pseudokod på hur UndoStack kan fungera.
Undo undoarray[SIZE];
int last;
public Undo pop(){
Undo svar = undoarray[last];
undoarray[last] = null;
last--;
if(last == -1) last = size;
return svar;
}
public void push(Undo undoobj){
if(last == size-1)
last = 0;
else
last++;
undoarray[last] = undoobj;
}
5.6.10 Data
En array av Undoobjekt utgör stacken. Storleken på arrayen sätts vid
start av programmet och kan t.ex. baseras på minnesåtgång.
UndoStacken har dock som minst en kapacitet att lagra 1 objekt.
Arrayen implementeras cykliskt så att objekt i botten av stacken
försvinner allteftersom nya objekt läggs på stacken.
5.7 Undo
5.7.1 Typ
Klass.
5.7.2 Syfte
Undoobjekt behövs för att undofunktionen (SRD 3.4.5.3) ska kunna
implementeras. Undoobjekt lagras på UndoStack (5.6) och innehåller
information om vad aktivt UserCommandobjekt (5.8) har utfört eller
vilket UserCommandobjekt som har satts till aktivt. Vad
informationen består i är specifikt för varje UserCommand, men kan
vara t.ex. skärmkoordinater från Controller (5.5) till aktivt
UserCommandobjekt eller anrop från aktivt UserCommandobjekt till
View (5.9).
5.7.3 Funktion
5.7.3.1 execute
Beskrivning: Utför de handlingar som specificeras av Undoobjektets
innehåll. Syftet är att backa ett steg i händelsekedjan till det tillstånd
som var strax innan användaren utförde sin senaste operation.
T.ex. användaren har skapat en sfär. Användaren knackar på
undoikonen. Undoobjektet kommer då att radera den nyss skapade
sfären.
Argument: void.
Returnerar: void.
5.7.4 Delkomponenter
Inga.
5.7.5 Beroenden
Det UserCommand som skapar det specifika Undoobjektet.
5.7.6 Interface
Undoobjekt instansieras av ett UserCommandobjekt.
UserCommendobjektet CmdUndo anropar funktionen execute()
(5.7.3.1) i Undo.
Undo kan ändrar data i DataModel (5.2) och/eller anropa View.
5.7.7 Resurser
Inga.
5.7.8 Referenser
Avsnittet om undofunktionen i SRD (3.4.5.3), UndoStack (5.6),
UserCommand (5.8), Controller (5.5), View (5.9), DataModel (5.2).
5.7.9 Metod
Undo gör inga beräkningar utan lagrar bara information. När metoden
execute() anropas så kommer anrop till metoder i DataModel/View
att utföras.
T.ex. Användaren har just skapat en sfär, men ångrar sig och knackar
på undoikonen. UserCommandobjektet CmdUndo anropar
Undometoden execute() som i sin tur kommer att anropa deleteGrO()
metoden i DataModel.
5.7.10 Data
Varje Undoobjekt är specifikt för varje UserCommandobjekt, men
kan innehålla information om att ett visst objekt skapades eller att ett
objekt modifierades med vissa parametrar. Detta för att kunna
återskapa ett tidigare tillstånd. I praktiken innehåller ett Undoobjekt
ett eller flera metodanrop till DataModel och/eller View.
5.8 UserCommand
5.8.1 Typ
Abstrakt klass. Ett Interface.
5.8.2 Syfte
Att utgöra ett interface. Programmet kommer att innehålla en mängd
Cmd* klasser (där * ersätts av namnet på klassen). Varje Cmd* klass
motsvarar i princip en knapps funktionalitet. Varje Cmd* klass ärver
av UserCommand.
De Cmd* klasser som finns är (Se 5.8.4 för beskrivning av varje
Cmd*):
CmdScale, CmdMove, CmdDelete, CmdRotate, CmdCamMove,
CmdCamZoom, CmdChangeToView1, CmdChangeToView2,
CmdChangeToView3, CmdChangeToView4, CmdChangeToModify,
CmdChangeToCreate, CmdChangeToPosition, CmdCreateSphere,
CmdCreateBox, CmdCreateCone, CmdCreateCylinder, CmdUndo.
Varje UserCommandobjekt (dvs. Cmd* objekten) har förmåga att
tillverka Undoobjekt (5.7) och lägga dem på UndoStack (5.6).
Se SRD 3.1.3.3.
5.8.3 Funktion
5.8.3.1 press
Beskrivning: Anropas av Controller (5.5) då denna tar emot ett
penPressed(x,y) (5.5.3.1). Betyder att användaren har satt ner pennan
på pekskärmen i koordinat x, y.
Argument: int x, int y.
Returnerar: void.
5.8.3.2 dragTo
Beskrivning: Anropas av Controller då denna får ett
penDragged(x,y) (5.5.3.2). Betyder att användaren har förflyttat sin
penna från föregående position på pekskärmen utan att lyfta den.
Pennans nuvarande position är x, y
Argument: int x, int y.
Returnerar: void.
5.8.3.3 released
Beskrivning: Anropas av Controller då denna mottar ett
penReleased(x,y) (5.5.3.2). Betyder att pennan har lämnat
pekskärmen vid koordinat x, y.
Argument: int x, int y.
Returnerar: void.
5.8.3.4 start
Beskrivning: Anropas då ett Cmd* objekt ska börja behandla data.
Vanligtvis då det sätts till aktivt UserCommandobjekt i Controller.
Argument: void.
Returnerar: void.
5.8.3.5 abort
Beskrivning: Avbryter alla operationer som objektet för tillfället
håller på med, t.ex. beräkningar.
Argument: void.
Returnerar: void.
5.8.3.6 delete
Beskrivning: Avalokerar alla eventuella resurser som objektet har
reserverat. Anropas vanligtvis innan objektet slängs.
Argument: void.
Returnerar: void.
5.8.4 Delkomponenter
CmdScale Skalar det valda GrOobjektet utifrån data mottaget av
dragTo(x, y) (5.8.3.2) metoden.
CmdMove Flyttar det valda GrOobjektet utifrån data mottaget av
dragTo(x, y) metoden.
CmdDelete Raderar det valda GrOobjektet.
CmdRotate Roterar det valda GrOobjektet utifrån data mottaget av
dragTo(x, y) metoden.
CmdCamMove Flyttar kameran (se Camera 5.3) utifrån data
mottaget av dragTo(x, y) metoden.
CmdCamZoom Zoomar kameran.
CmdChangeToView1 Ändrar vyn till kamera 1 (parallellprojicerad).
(3.4.3.1 i SRD)
CmdChangeToView2 Ändrar vyn till kamera 2 (parallellprojicerad).
(3.4.3.1 i SRD)
CmdChangeToView3 Ändrar vyn till kamera 3 (parallellprojicerad).
(3.4.3.1 i SRD)
CmdChangeToView4 Ändrar vyn till kamera 4
(perspektivprojicerad). (3.4.3.2 i SRD)
CmdChangeToModify Ändrar till modifierarläget. Motsvarar
3.4.4.3.3 i SRDn.
CmdChangeToCreate Ändrar till skaparläget. Se SRD 3.4.4.3.1
CmdChangeToPosition Ändrar till kameraläget.
CmdCreateSphere Skapa sfär läget. Arbetar med data mottaget av
press(x, y), dragedTo(x,y) och released(x, y) (5.8.3.3) metoderna.
CmdCreateBox Skapa rätblock läget. Arbetar med data mottaget av
press(x, y), dragedTo(x,y) och released(x, y).
CmdCreateCone Skapa kon läget. Arbetar med data mottaget av
press(x, y), dragedTo(x,y) och released(x, y).
CmdCreateCylinder Skapa cylinder läget. Arbetar med data
mottaget av press(x, y), dragedTo(x,y) och released(x, y) metoderna.
CmdUndo Undo funktionaliteten. Anropar pop() (5.6.3.2) i
UndoStack (5.6) och därefter excecute() (5.7.3.1) i det Undoobjekt
som returneras. Implementerar undofunktionaliteten (SRD 3.4.5.3).
5.8.5 Beroenden
Utan Controller fyller UserCommand inget syfte. UserCommand
interfacet måste existera innan Cmd* klasser kan skapas.
5.8.6 Interface
Aktivt UserCommandobjekt, dvs. ett Cmd* objekt, får data från
Controller genom att Controller anropar funktioner i Cmd*. Hur den
informationen tolkas är olika för olika Cmd* objekt. Om Cmd* tolkar
informationen den får som relevant så utförs någon handling. Cmd*
instansierar då också ett Undoobjekt som beskriver hur handlingen
ska kunna upphävas och lägger den på UndoStack.
5.8.7 Resurser
Inga.
5.8.8 Referenser
Controller (5.5), Undo (5.7), UndoStack (5.6), Camera (5.3), Button
(5.13).
SRD 3.4.3.1, 3.4.3.2, 3.4.4.3.3, 3.4.4.3.1, 3.4.5.3.
SRD 3.1.3.3
5.8.9 Metod
De olika Cmd* klasserna är beskrivna i 5.8.4. Information skickas till
dessa oavsett om det är intressant information eller inte. Om
informationen är intressant avgörs av det Cmd* objektet som tar emot
informationen. Cmd* objekt kan anropa funktioner i DataModel,
View, Undo, UndoStack och Button (5.13).
5.8.10 Data
En klass som implementerar UserCommand innehåller egentligen
inte så mycket data. Vad de innehåller varierar mellan Cmd*
klasserna men kan vara t.ex. koordinater, rotationer och funktioner
för att beräkna avstånd. Alla UserCommandobjekt har förmågan att
skapa Undoobjekt.
5.9 View
5.9.1 Typ
View är av typen klass.
5.9.2 Syfte
View ansvarar för att visa en grafisk bild av DataModel (se 5.2) på
skärmen. Den tar även hand om utritning av ToolbarHandler (5.12).
Den gör detta genom att delegera ansvar till sina delkomponenter.
5.9.3 Funktioner
View är view delen i MVC konceptet. Den ansvarar alltså för den
grafiska presentationen av datamodellen. Den kommer att ärva ifrån
java.MicroEdition.LCDUI.Canvas i J2ME.
5.9.3.1 update
Beskrivning: Förebereder uppdatering av skärmen. Delegerar
ansvaret till Renderer (5.10) och ToolbarHandler. Vi försöker
optimera så att bara det som ändras beräknas. Argumentet vi fåd in är
det objektet som har ändrats.
Argument: void/GraphicalObject (se 5.4)/Camera (se 5.3)/Toolbar
Returnerar: void
5.9.3.2 drawBox
Beskrivning: Ritar en rektangel på skärmen. Man kan bara ha en
rektangel på skärmen samtidigt. Detta medför att bara den senaste
ritade rektangeln på skärmen visas.
Argument: heltalen x1,y1,x2,y2;
Returnerar: void
5.9.3.3 Paint
Beskrivning: Ritar om sig själv på g. Delegerar ansvar till sina
delkomponenter.
Argument: Graphics g i J2ME
Returnerar: void
5.9.4 Delkomponenter
Viewen har Renderer som en delkomponent. Renderer tar hand om
utskrivningen av DataModel.
5.9.5 Beroende
ToolbarHandler och Renderer måste vara implementerad.
5.9.6 Interface
Tar emot händelser från UserCommand och skriver dessa till
skärmen. För mer detaljer se kapitel 4.
5.9.7 Resurser
Inga resurser krävs för denna del.
5.9.8 Referenser
Design Pattern, Erich Gamma, Richard Helm, Ralph Johnson & John
Vlissides
Se J2ME referensen.
5.9.9 Metod
Allt börjar med att View får en update från ett UserCommandobjekt.
View dirigerar då händelser till de olika delkomponenterna. Sedan
kallar den rePaint() på sig själv. Då kommer systemet att kalla
paint(). Paint anropet kommer den också att dirigera vidare till sina
delkomponenter. Se sequence diagrams nedan.
5.9.10 Data
Ännu ej bestämt.
5.10 Renderer
5.10.1 Typ
Typen är klass.
5.10.2 Syfte
Renderer ansvarar för att visa en grafisk bild av DataModel.
5.10.3 Funktioner
Den här klassen tar hand om utritning av 3d-objekt på skärmen. Detta
är den del som vi kommer att optimera mest.
5.10.3.1 update()
Beskrivning: Förebereder för uppdatering av skärmen. Vi försöker
optimera så att bara det som ändras beräknas. Argumentet vi få in är
det objektet som har ändrats. Alla andra objekt måste vara lika sedan
senaste update utan argument.
Argument: void/GraphicalObject/Camera
Returnerar: void
5.10.3.2 paint()
Beskrivning: Ritar ut DataModel på skärmen
Argument: Graphics g
Returnerar: void
5.10.4 Delkomponenter
Denna komponent har inga delkomponenter.
5.10.5 Beroende
Kräver att DataModel är implementerad.
5.10.6 Interface
Blir kallad av View (5.9) och läser av alla GraphicalObjectobjekt och
Camera i DataModel.
5.10.7 Resurser
Använder inga resurser
5.10.8 Referenser
Interactive computer programming, Angels
5.10.9 Metod
Denna klass kommer att vara den största klassen. Det kommer
förmodligen att delas upp i småklasser men eftersom det är viktigt att
den har bra prestanda håller vi designen öppen.
Den ska gå igenom DataModels GrO objekt och Camera objektet och
skriva ut det till skärmen. I en förenklad variant utan optimeringar
kommer den att skapa en transformation matris för kameran som man
sedan multiplicerar med de matriser den skapar för GrO objekten. Se
pseudokod nedan. Som vi ser använder den klassen Matrix. Denna är
ännu inte definierad.
Matrix
CameraMatrix=CreateMatrixFromCamera(DataModel.
cam);
ForEach(GrO g=DataModel.GroArray()) begin
Matrix
ObjektMatrix=CreateMatrixFromObjekt(g)
Matrix FinalMatrix=new Matrix();
Vector3d FinalPoints[]=new
Vector3d[g.getPoints().length];
FinalMatrix.mul(CameraMatrix,ObjektMatrix);
FinalPoints.mul(FinalMatrix, g.getPoints());
Draw(FinalPoints,g.getLines());
End;
5.10.10 Data
Vi vet ännu inte vilken data den ska innehålla.
5.11
ToolbarHandler
5.11.1
Typ
ToolbarHandler är av typen klass.
5.11.2
Syfte
ToolbarHandlar tar hand om alla Toolbar (5.12). Man kan lägga till
Toolbars i ToolbarHandler. Den delegerar anrop för utritning och
pentryckningar till sina delkomponenter (Toolbar).
5.11.3
Funktion
5.11.3.1 addToolbar
Beskrivning: Lägger till en Toolbar.
Argument: ToolBar
Returnerar: void
5.11.3.2 press
Beskrivning: Bearbetar att någon har tryckt på skärmen
Argument: Var personen har tyckt, int x,y
Returnerar: Returnerar sant om vi tryckt på någon toolbar.
5.11.3.3 update
Beskrivning: Förbereder ToolbarHandler att det snart kommer en
paint(). Om vi skickar in ett Toolbar vet vi att det är bara denna
Toolbar som har ändrats sedan senaste update.
Argument: void/Toolbar
Returnerar: void
5.11.3.4 paint
Beskrivning: Skriver ut alla aktiva Toolbarobjekt på skärmen genom
att delegera det till de olika Toolbarobjekten.
Argument: Graphics gr
Returnerar: void
5.11.4 Delkomponenter
Har Toolbar som en delkomponent.
5.11.5 Beroende
De har inget beroende förutom genom underkomponenter.
5.11.6 Interface
Det är två stycken delar som använder denna klass, Controller (5.5)
och View (5.9). Controller använder press och View använder
funktionerna update och paint. Något viktigt att kommentera är att
denna klass inte ingår i Model-View-Controller konceptet riktigt.
Den kan man säga är en helt egen komponent som både View och
Controller använder sig av. Vi har valt denna lösning för att minska
kopplingar mellan de olika komponenterna.
5.11.7 Resurser
Använder inga resurser.
5.11.8 Referenser
Design Pattern, Erich Gamma, Richard Helm, Ralph Johnson & John
Vlissides
5.11.9 Metod
Denna klass kan beskrivas som en Facade pattern. Istället för att
kommunicera med alla komponenter skickar den vidare till sina
underkomponenter. Den gör inte detta fullständigt utan för t.ex. att
sätta olika Toolbar (5.11) aktiv använder man funktioner i den
berörda Toolbarojektet direkt.
5.11.10 Data
Ej ännu bestämt.
5.12 Toolbar
5.12.1 Typ
Klass
5.12.2 Syfte
Tar hand om en Toolbar. En Toolbar består av ett antal knappar. Den
tar hand om både utritning och vad som händer när man trycker på en
knapp.
5.12.3 Funktioner
5.12.3.1 addButton
Beskrivning: Lägger till en Button (5.12).
Argument: Button
Returnerar: void
5.12.3.2 setEnabled
Beskrivning: Om argumentet är sant sätts den till aktiv annars
inaktiv.
Argument: Boolean
Returnerar: void
5.12.3.3 paint
Beskrivning: Om den är aktiv ritar den ut sig själv genom att be sina
Buttonobjekt att rita ut sig själva.
Argument: Graphics gr
Returnerar: void
5.12.3.4 press
Beskrivning: Om vi har tryckt på Toolbar returnerar den sant. Den
anropar press i alla Buttonobjekt. Detta gör den bara om den är aktiv.
Argument: int x,int y
Returnerar: Boolean
5.12.4 Delkomponenter
Button är en delkomponent till Toolbar.
5.12.5 Beroende
Den är inte beroende på något för utom sina delkomponenter.
5.12.6 Interface
Se 5.10.9. UserCommand kommer att använda Toolbar genom att
sätta de olika Toolbar aktiva och inaktiva.
5.12.7 Resurser
Använder inga resurser
5.12.8 Referenser
Inga
5.12.9 Metod
Press, Paint skickas vidare till delkomponenterna.
5.12.10 Data
Den måste ha någon koordinat var den är någonstans på skärmen och
sedan behövs höjden och bredden. Detta sparas lämpligaste med int.
Sedan en lista med Button. Dessa sparas lämpligaste med Vector i
J2ME.
5.13
Button
5.13.1 Typ
Klass
5.13.2 Syfte
Hanterar en knapp. Har funktioner för pentryckningar och utritning
på skärmen. Varje Button har ett UserCommand.
5.13.3 Funktioner
5.13.3.1 press
Beskrivning: Om argumentet är inuti anropas start() i det
UserCommand som tillhör Button.
Argument: Var man har tryckt på Toolbarobjeketet. Int x, int y
Returnerar: Sant om man har trycket annars falskt
5.13.3.2 paint
Beskrivning: Ritar knappen på skärmen
Argument: Graphics gr
Returnerar: void
5.13.4 Delkomponenter
Button har inga delkomponenter
5.13.5 Beroende
Kan implementeras etappvis. För att den skall fungera fullständigt
måste UserCommand vara implementerad.
5.13.6 Interface
Se 5.10.6.
5.13.7 Resurser
Inga resurser krävs för denna del
5.13.8 Referenser
Design Pattern, Erich Gamma, Richard Helm, Ralph Johnson & John
Vlissides
5.13.9 Metod
Den enda medlemsfunktionen som anropar yttre funktioner är
press(int x,int y). De andra funktionerna är ganska självklara vad dom
gör.
Press(int x, int y) kontrollerar om man tryckt på knappen. Om man
har gjort det anropas start() i UserCommand objektet som är bunden
till button.
5.13.10 Data
Kommer att spara en bild på knappen. Det finns inbyggda klasser i
J2ME för att spara detta.
6 Resursuppskattning och riskanalys.
6.1 Resursuppskattning
De flesta komponenterna i arkitekturen kommer att implementeras i
ekonomi versionen. Detta säger inte att de flesta av funktionerna från
URD kommer att implementeras, utan snarare att komponenterna i
sig själva är utbyggbara i fråga om funktionalitet.
Komponenter som kommer att implementeras i standard versionen är
sådana tillhörande kon och cylinder funktionaliteten samt kamera
kommandot CmdCamZoom. I delux versionen implementeras undo
komponenter och komponenter tillhörande möjligheten till olika vyer.
På nästa sida finns en tabell med komponenter och deras prioritet.
6.2
Komponent
DataModel
Camera
GrO
GrOShpere
GrOBox
GrOCone
GrOCylinder
View
Renderer
ToolbarHandler
Toolbar
Button
Icon
Controller
UndoStack
Undo
Command
CmdScale
CmdMove
CmdDelete
CmdRotate
CmdChangeToView1
CmdChangeToView2
CmdChangeToView3
CmdChangeToView4
CmdChangeToModify
CmdChangeToCreate
CmdChangeToPosition
CmdChangeToNone
CmdCreateSphere
CmdCreateBox
CmdCreateCone
CmdCreateCylinder
CmdCamMove
CmdCamZoom
Riskhantering
Ekonomi Standard
Delux
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Denna riskhanteringsplan är en fortsättning från riskanalysen
som skapades i Software Requirements Document (SRD).
Riskerna ska kartläggas, analyseras och det ska göras en
handlingsplan för att minimera dessa risker.
Handlingsplanen(återfinns i 6.2.3) innehåller en behandling av alla
definierade risker även sådana som vi anser små. Anledningen till att
vi genomförde riskanalysen på detta sättet är att vi vill kontrollera
och minimera risken att projektet misslyckas.
Risk analysen är utförd enligt mallen (Risk Guideline: Template
Software Project Risk Factors). I kapitel 6.2.2 återfinns riskanalys
tabellen.
6.2.1 Arbetet med riskanalysen
Vi har medvetet valt att ha ganska låg profil på riskanalysarbetet. Vi
har en tremanna grupp som aktivt arbetar med riskanalysen och
riskhanteringen, i denna grupp ingår projektledaren. Att
projektledaren ingår i riskanalysgruppen är naturligt då han på detta
sätt fortlöpande får god insyn i projektet. Riskanalysgruppen har
enligt ovan beskriven modell analyserat projektets risker och
utarbetat en plan för att aktivt förebygga dessa risker.
6.3 Resursuppskattning
Vi har gjort en grovplanering av i vilken ordning vi ska implementera
de olika komponenterna i projektet. Här har vi också planerat in
testning. Testning av varje komponent och klass ligger i planeringen
för komponenterna. Utifrån vår planering har vi sedan delat upp oss i
grupper om tre personer där varje grupp har hand om en viss del av
projektet. En person i varje grupp har dessutom andra uppgifter som
gör att dessa personers insats i grupperna kan vara lite mindre än de
andras. Gruppindelningen är följande:
1.
2.
3.
Robin, Rickard och Stefan.
Erik, Gunnar och Mario
Mats, Mikael och Anders
Fig. Planering och gruppindelning av komponenterna.
En kort beskrivning av uppdelningen av delar, samt av de delar som
inte beskrivs i kap 5.
Design:
Del 1 – Den delen där alla hjälps åt att strukturera mer noggrant hur
varje del ska implementeras. Detta görs i grupperna. I denna fas
påbörjas också DDD:n.
Del 2 – Här fullföljs arbetet med dokumentationen bl.a. i DDD:n.
DataModel:
Del 1 – Här implementeras grundstommen i datamodellen. Dessa
delar är de som är viktigast för att köra andra komponenter.
Del 2 – Här implementeras spara och ladda till internt format.
GraphicalObject:
Del 1 – Här implementeras de grafiska objekten, sfär och kub.
Del 2 – Här implementeras kon och cylinder.
Camera:
Del 1 – Implementation av de viktigaste delarna för att kunna visa ett
objekt projicerat på skärmen.
Del 2 – Här implementeras de delar som behövs för
perspektivprojektion.
Renderer:
Del 1 – Här implementeras det viktigaste i renderer (som kommer att
bli väldigt avancerad) för att räkna på transformering och annat.
Del 2 – Här implementeras de delar som gör renderer fullständig.
Del 3 – Här optimeras renderer.
ADD
5.5.2
5.6.2
5.7.2
5.8.2
5.8.4
5.9
5.10
5.11
5.12
5.13
Command:
Del 1 – Här implementeras command så att man kan använda de
vanligaste funktionerna.
SRD
Del 2 – Här kommer
gruppen att implementera
3.1.3.1
fler funktioner som är lägre
prioriterade.
3.4.5.3
3.4.5.3
3.1.3.3
Systemtest:
3.4.3.1
Här testas programmet i sin
3.4.3.2
helhet enligt de planer vi
3.4.4.3.3
har lagt upp.
3.4.4.3.1
3.4.5.3
3.1.2.1
Testing:
3.1.2.2
Här testas programmet
3.1.3.2
fortlöpande så att vi vet
3.1.2.3
hela tiden att det fungerar
3.1.3.2
på alla plattformar och
3.1.2.3
under alla OS som vi angett
3.1.2.4
att det ska fungera på.
Manual:
Här skrivs och planeras det för manualen.
7 Spårningsmatris