Samarbejdende aktiviteter over netværk leder naturligt tanken hen på anvendel= se af multitast som kommunikationsmetode. Princippet går ud på at = alle klienter lytter efter datapakker på nettet indeholdende en defineret IP-multicastadresse. Når blot en eller flere klienter sender på samme adresse, vil alle modtage samme data. Der er altså ingen server involveret – kun datanettet. Problemet med multicast, er at der anven= des UDP som transportprotokol (ofte lukket da UDP er connection-less og derfor virker som ’reklamepostkasse’) og at multicast typisk ikke forwardes af rutere. Derfor ønskes en application som anvender unicast og TCP. Problemet er om d= er også skal anvendes en fast server eller denne centrale facilitet skal ligge i alle klienter hvor et abitreringssystem skal afgøre hvem der skal være server. Andre variationer findes også. Her vælg= es en client/server løsning.

Problemformule= ring

Udviklingen ønskes foretaget efter objektorienterede principper og programmeret = i Java. Der ønskes foretaget et design med stor vægt på komponen= ter og genbrug. Den grafiske brugergrænseflade ønskes udformet som= en komponent som let kan indlejres i en java frame eller en applet, som dereft= er kan tilkobles et bestemt rum. Der ønskes flere tavle-sessions, hvilk= et betyder, at flere tavler kan eksistere samtidigt på serveren og bruge= rne kan framelde og tilmelde en tavle-session i takt med at der skiftes rum i et virtuelt college.

Foranalyse=

Eftersom shared whiteboard nødvendigvis skal kommunikere over netværk v= il der i foranalysen blive undersøgt forskellige protokoller. Endvidere= vil eksisterende shared whiteboards blive undersøgt for at få en større viden om emnet. Til sidste vil et antal eksisterende teknolog= ier blive undersøgt i håb om at noget kan genbruges.=

Protokoller

TCP (Transport Control Protocol) [RFC793]

TCP er den gængse transportprotokol på internettet. Den er robust, og generelt et godt = valg til overførsel af data.

Den har dog en del kompli= kationer i forbindelse med realtids audio, bl.a. kan dens congestion control, hvor transmissionraten midlertidigt reduceres, skabe huller i datastrømme= n. Dette er brugbart for almindelig streaming media da den gennemsnitlige transmissions rate er mere konsistent, og tillader mange forbindelser at skalere sig mod hinnanden.

TCP bygger også p&a= ring; et data aknowledge system, som sikre at tabte pakker bliver retransmiteret. I forbindelse med audio kan det betyde at en sample ankommer efter den skulle være afspillet, og er derfor spildt båndbredde, da den er forældet.

HTTP (HyperTekst Transfer Protocol) [RFC1945]

HTTP bygges ovenpå = en TCP forbindelse, og fungere efter besked/svar princippet.

HTTP bruges hyppigt i for= bindelse med netradio, hvor en stabil strøm af data, der kan modtages gennem proxy servere og firewalls er ønskeligt. Der bruges ofte en meget st= or lokal buffer til at kompensere for TCP protokolens slowstart, og congestion kontrol, ofte 10-15 sekunder.

UDP (Universal Datagram Protocol) = [RFC768]

UDP bruges flittigt i Voi= ce over IP sammenhænge pga. det lave delay og meget høje udnyttelsesgr= ad. UDP er dog blokeret i visse firewall, men flere applikationer kompensere for dette ved at bygge sig op så det stille så lille et krav til hu= llet i firewallen som muligt. Ofte (se Team Speak og Pico Phone) ved at kun bruge én enkelt port, som kan ændres hvis tilpasning er nødvendigt. Client/Server modellen er også brugt, hvor man kan bruge en server mellem to firewalls, så indgående forbindelser = ikke er et krav.

RTP (Real Time Protocol)= [RFC1889]

RTP er en transport proto= kol brugt til lyd- og billedemedia, transmiteret over UDP, og giver faciliteter= til f.eks. synkronisering af lyd og billede, samt codec specificering.

RTP laver dog et vist ove= rhead, og skal kombineres med RTCP (Real Time Control Protocol) for at fungere optimalt.

SIP (Session Initiation Protoco= l) [RFC2543]

SIP eller Session initiate protokol, er en protokol standard beregnet til at brugere kan kalde op, og udveksle forskellige informationer før selve opkaldet. F.eks. om transportprotokol og codec.

SIP kan fungere ovenp&ari= ng; TCP eller UDP, og kan udveksle informationer om firewalls og evt. Proxy servere= i brug, og dermed hjælpe programmer med at etablere den bedst mulige forbindelse inden selve forbindelsen, og dermed opkaldet, bliver oprettet.<= /p>

Et muligt scenarie kunne = f.eks. være at finde ud af hvilke, om nogen, af klienterne den kan modtage U= DP pakker, eller og en alternativ transport løsning, f.eks. via TCP, sk= al søges.

Shared w= hiteboards

Coccinella [COCC]

Coccinella er en chatklient til instant messaging protokollen Jabber med shared whiteboard.

Jabber bruger XML i sin p= rotocol.

Test af Coccinella

Opsætn= ing:

· 2 Klienter kørte over jabber.dk

· = OS: Windows XP og Windows 2000

· Coccinella kræver et TCL[1] script fortolker installeret først

jabber.dk havde en averag= e round trip time på 25,5 ms.

Udfør= sel:

Session blev oprette og de forskellige tegneredskaber blev undersøgt med henblik på konsistens og resulterende latenstid.

Resultat:

Brugervenlighed

Selvom ingen af testpersonerne kendte jabber v= ar det meget intuitivt.

Coccinella, når sessionen er igang, vold= te heller ikke de store problemer.

Antallet af funktioner er passende, og de er a= lle anvendelige.

Latenstid

Overførslen af simple figure som firkan= ter og cirkler foregik med lav latens (ca. 1 sek eller under).

Farvelægning af firkanter og cirkler for= egik med samme lave latenstid.

Stregtegning varierede meget(fra næsten ubemærkeligt til 1 min i værste tilfælde). Det var af stor betydning hvor kompliceret tegningen var.

Et billede (bitmap) blev sat ind. Det nå= ede ikke frem.

Bugs

Programmet var temmelig fejbehæftet p&ar= ing; Windows platformen.

Fejlene var af forskellige karakter og i regle= n af kritisk art.

Efter flere forsøg blev det konstateret= at når session forsøges startet er det ikke altid den når f= rem til modtageren, dette resulterer ofte i flere forskellige vinduer men kun et der skal bruges.

Ved erase all funktionen efterfulgt af undo funktionen blev der genereret en fejlmeddelelse.

Network Assistant [NETA]
Network Assistent er et L= AN chatprogram med indbygget shared whiteboard og eventlogger.

Test af Network Assistant

Opsætn= ing:

· 2 klienter, ingen server opsætning

· = OS: Windows XP og Windows 2000

Udfør= sel:

Session blev oprettet og = de forskellige tegneredskaber med videre blev undersøgt med henblik på konsistens og resulterende latenstid.

Resultat:

Brugervenlighed

Network Assistant er meget brugervenligt. Brugergrænsefladen er opbygget så der er konsistens med microso= fts brugergrænseflade.

Ved whiteboardet er kun simple funktioner til = stede. Det er ikke muligt at slette enkelte streger eller ændre på indholdet af whiteboardet på andre måder end ved at slette hele whiteboardet eller tegne oven i den eksisterende tegning.

Latenstid

Network Assistant havde meget lav latens.

På intet tidspunkt blev der observeret latenstider på over 2 sekunder.

Bugs

Ingen bugs blev fund<= /a>

Teknologier

Servlets [DJSE] [TYJS] [JSSE] [PJSP]
Java servlets er et frame= work til at skrive webserverapplikationer, almindeligvis ved at bruge HTTP protokole= n.

De har en række for= dele i forhold til andre serverside løsninger mht. Til dynamisk content og = serving.

Buzzwords som effektivitet (kompleksitetsmæssigt), platformsuafhængighed, sikkerhed, pålidelighed og fleksibilitet gør sig gældende.

Endvidere er almindelige firewalls og proxys ikke noget problem, eftersom servlets bruger TCP port 8= 0, som også benyttes af webservices generelt.

Dog kan TCP protokollen introducere for meget overhead i denne sammenhæng.

Mica [MICA]
Mica er et objektorienter= et grafisk framework, specielt bygget til at underbygge implemenation og manipulation af grafikeditore, tegneprogrammer og brugergrænseflader.=

Mica giver udvidet support til display li= sts, event handling, action dispatching, coordinate transforms og connectivity.<= o:p>

En ulempe ved mica er ris= ikoen for at introducere for meget overhead når objekter skal overfø= res.

XML [XML]
XML, Extensible Markup La= nguage, er et simpelt og meget fleksibelt opsætningssprog. XML er som så= ;dan ikke et værktøj, men bliver bl.a. brugt i Jabber som er brugt i forbindelse med Coccinellas netværks del.

Formatet kan eventuelt br= uges til at formatere grafikken, der skal sendes over netværket. Eftersom XML = er et tekstformat, og formateringen derfor er i ren tekst, er der en risiko fo= r at der introduceres for stort et overhead hvis mange små objekter skal t= ransmitteres. I så fald skal der tages ekstra skridt for at minimere dette, hvilket indebærer risiko for at bevæge sig væk fra den objektorienterede tankegang.

Analyse af anvendelsesområde

I analysen af anvendelsesområdet analyseres de aktører de enkelte delproblemer skal interagere med. For at give et større overblik, vil opdelingen af problemstillingen blive klarlagt.=

Problemopdeling

Shared whiteboard bliver = delt op i whiteboardklient og whiteboardserver, på henholdsvis klientsiden og serversiden, for nemmere at kunne beskrive den ønskede funktionalite= t. Dette er visualiseret i Figur 1.

Figur 1 Shared whiteboards delproblemer=

Idenfikation af aktøre

De to delproblemers anven= delsesområde har tilsammen følgende aktøre.

Netværk

Netaktøren represe= nterer det netværk, som forbinder de enkelte computere med hinanden. Det er = en vigtig aktør på grund af netværkets nondeterministiske n= atur og fastlægelsen af de protokoller der skal anvendes for at kunne kommunikere over netværket.

Bruger

Brugeraktøren er d= en aktør som interagerer med systemet udefra. Brugeren stiller i dette projekt krav om funktionalitet og grafik. Brugeren er på samme tid producer og consumer.

Whiteboardklient

Usecase

For at finde de brugsmønstre der gør sig gældende ved whiteboardkliente= n, opstilles et brugsmønsterdiagram for denne.

Figur 2 Usecasediagram for whiteboardkl= ient

I Figur 2 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000D0000005F005200= 65006600360033003400330034003000310031000000 er brugsmønsterdiagrammet for whiteboardklienten vist. De to aktøre er brugeren og netværket. Brugsmønstrene er kort beskrevet i det følgende.

Delprobl= emer

For nemmere at kunne over= skue realisationen af brugsmønstrene deles whiteboardklienten op i tre delproblemer. Disse delproblemer er et delproblem for hver aktør, som varetager grænsefladen til disse, og et delproblem, som er kernefunktionaliteten af white boardet, og interfacer til de to andre delproblemer.

Figur 3 Whiteboardklientens delprobleme= r

I Figur 3 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000D0000005F005200= 65006600360033003400330034003100300034000000 ses det samlede problem delt op i de tre dele, hv= oraf den første omhandler interaktion med brugeren, den anden omhandler whiteboard funktionalitet og den tredje omhandler kommunikation med netværket. Delproblemerne vil i det følgende fremgå ved = hver deres swimlane.

Swimlanes

På de følgen= de aktivitetsdiagrammer er adskillelser og kommunikation mellem delproblemerne vist. Aktivitetsdiagrammerne viser hvad der sker når en bruger eller netværket interagere med systemet.

Figur 4 Manipuler whiteboard brugsmønster

Figur 4 viser aktivitetsdiagrammet for manipuler white bo= ard. Brugeren manipulerer whiteboardet ved hjælp af UI. Herefter opdateres white boardet, og opdateringen sendes ved hjælp af klientsession.

Figur 5 Modtag opdatering brugsmø= ;nster

Figur 5 viser aktivitetsdiagrammet for modtag opdatering. Opdateringen bliver modtaget over nettet, hvorefter white boardet bliver opdateret.

Figur 6 vælg tegneindstillinger brugsmønstret

Figur 6 viser aktivitetsdiagrammet for vælg tegneindstillinger. Fra UI vælges indstillinger, som opdateres i white boardet.

Figur 7 vælg figur brugsmø= nstret

Figur 7 viser aktivitetsdiagrammet for brugsmønstr= et se figurinfo. Brugeren vælger en figur gennem UI, hvorefter white boa= rdet viser informationen for brugeren.

Figur 8 Gem fil brugsmønstret

Figur 8 viser aktivitetsdiagrammet for brugsmønstr= et gem. Brugeren vælger at gemme gennem UI, hvorefter white boardet vise= r en filvælgermenu. Brugeren vælger herefter filen. Endelig bliver w= hite boardet gemt i den valgte fil.

Figur 9 Åbn fil brugsmønst= ret

Figur 9 viser brugsmønstret hent white board fra f= il. Først vælger brugeren at åbne en fil ved hjælp af = UI. Herefter viser white boardet en filvælger, så brugeren kan vælge hvilken fil der skal åbnes. Filen åbnes, og whiteboardet bliver opdateret i henhold til indholdet i filen. Endelig bliv= er opdateringerne sendt ved hjælp af klient session.

Funktionstabel

I dette afsnit vil aktivi= teterne fundet i det foregående blive nedbrudt til funktioner, enten i forhol= det en til en eller i forholdet en aktivitet til flere funktioner.

Aktiviteter	Funktioner	Beskrivelse
Send besked	Send	Send sender sessionsrelevant data til klientsession.=
Vælg figur	Vælg figur	Vælg figur lytter efter de hændelser der= kendetegner en brugers ønske om at vælge en figur.
Vis figurinfo	Vis figurinfo	Viser et tooltip med brugeren der har tegnet det pågældende elements navn.
Vælg tegneindstillinger	Vælg tegneindstillinger	Viser en brugergrænseflade hvori tegneindstill= inger som tykkelse af streg, farve og fyldfarve kan vælges.
Sæt tegneindstillinger	Sæt tegneindstillinger	Sætter de valgte tegneindstillinger.
Gem	Gem	Gem funktionen reagerer på hændelsen gem= , som indtræffer når brugeren vælger at gemme whiteboardet i = en fil.
Åbn	Åbn	Åbn funktionen reagerer på hændels= en åbn, som indtræffer når brugeren vælger at å= ;bne en fil.
Vis filvælger	Vis filvælger	Viser en brugergrænseflade, hvori det er mulig= t at vælge filen der skal tilgåes.
Vælg fil	Vælg fil	Vælg fil reagerer på hændelsen vælg fil.
Filbehandling	Læs fil Skriv fil	Læs fil læser et whiteboard fra en fil.<= /p> Skriv fil skriver et whiteboard ned i en fil
Manipuler white board	Tilføj element Slet element Ændr element	Tilføj element funktionen indsætter et element på white boardet. Slet element sletter et element på whiteboarde= t. Ændr element ændrer på et element på whiteboardet.
Send opdatering	Send	Send sender den indpakkede opdatering via klientsess= ion.
Modtag opdatering	Modtag	Modtag modtager en indpakket opdatering fra klientse= ssion.

Whiteboardserver

Usecase

For at finde de funktione= r som skal implementers i det endelige produkt udarbejdes usecase for white board serveren.

Figur 10 Usecasediagram for whiteboardse= rver

I Figur 10<= !--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000D0000005F005200= 65006600360033003400330034003200350038000000 ses aktøren net som repræsenterer netværket. White board serveren modtager data fra nettet, sender data over nettet, og modtager sessionsændringer. Usecasene er uddybet i det efterfølgende.

Swimlanes

Figur 11 Modtag opdatering brugsmø= ;nster

Figur 11 viser aktivitetsdiagrammet for usecasen modtag. Serveren modtager en white board opdatering fra nettet, som bliver brugt ti= l at opdatere modellen af whiteboardet på serveren. Herefter sendes opdateringen ud over netværket til alle klienter i samme gruppe som sender af opdateringen.

Funktionstabel

I dette afsnit vil aktivi= teterne fundet i det foregående blive nedbrudt til funktioner, enten i forhol= det en til en eller i forholdet en aktivitet til flere funktioner.

Aktiviteter	Funktioner	Beskrivelse
modtag opdatering	modtag	Modtager data fra whiteboardklienten og sender det t= il alle whiteboardklienterne.

Design og implementering

Eftersom udviklingen af whiteboardet har været stærk iterativt og præget af udstrakt brug af prototyping bliver der i det efterfølgende ikke skelnet mellem beslutninger taget under design og implementering.

Arkitektur

Whiteboardklienten best&a= ring;r af tre dele. Messages delen, som sørger for at encode og decode besk= eder der skal sendes eller er blevet modtaget over netværket, Whiteboard delen, den del der kan tegnes på og Tools delen, som er værktøjer der kan bruges til at tegne på DrawingArea del= en. Whiteboardserveren består af en enkelt komponent som videresender beskeder modtaget over netværket.

Et deploymentdiagram der = viser hvordan de forskellige komponenter er fordelt ud kan ses i figur Figur 12.

= Figur 12 Deployment af Shared Whiteb= oard

<= o:p>

Whiteboard

Repræsentationen af Whiteboardet ses i = Figur 13.

Figur 13

Whiteboard komponenten ha= r ansvar for at vise whiteboardet samt for at kommunikere med whiteboardserveren. Derudover er den ansvarlig for at whiteboardet bliver startet rigtigt op, derunder for at starte Tools komponenten.

WBStart

WBStarts opgave er at instanciere Whiteboard på = samme måde, lige meget om WBStart bliver brugt som en applet eller eksekver= et i en Java Virtual Machine (JVM). Klassen WBStart kan ses i figur Figur 14.

Figur 14 Klassen WBStart

WBStart nedarver fra JApplet og indeholder funktionen = init for at kunne blive startet som en applet og indeholder funktionen main for = at kunne blive eksekveret i en JVM.

FileManager

FileManager indeholder statiske funktioner til at gemme billeder som filer og hente billeder i filer. Klassen kan ses i Figur 15.

Figur 15 Klassen FileManager

WBPopupMenu

Klassen WBPopupMenu ses i Figur 16.

Figur 16 Klassen WBPopupMenu

WBPopupMenu nedarver fra JPopupMenu og bliver vist som en popup menu på whiteboardet. Den implementerer MouseListener for at kunne fange events genereret af DrawingA= rea og derved kunne reagere på højreklik med musen på denne. Derudover er WBPopupMenu sin egen ActionListener for at kunne fange events genereret når en bruger klikker på de enkelte menupunkter i popupmenuen. WBPopupMenu bruger FileManager til at hente billeder fra filer= og gemme billeder i filer.

Whiteboard

Whiteboard klassen er den øverste klasse i Whiteboards klassehierakiet. Klasen kan ses i Figur 17.

Figur 17 Klassen Whiteboard

Whiteboards opgaver best&= aring;r i at instanciere klasser længere nede i klassehierakiet, vise disse klassers grafiske representation og ekstern kommunikation til whiteboardserveren.

MessageListener

MessageListener er et int= erface til klasser som ønsker at blive gjort opmærksom på Messa= ges der er færdige til at blive sendt over netværket.

Figur 18 Interfacet MessageListener

DrawingTabbedPane

DrawingTabbedPane viser e= t antal Drawingareas som på et JTabbedPane. Klassen kan ses i Figur 19.

Figur 19 Klassen DrawingTabbedPane

DrawingTabbedPane inds&ae= lig;tter Toolbox og WBPopupMenu som EventListeners på Drawingarea når den bliver instancieret.

DrawingArea

DrawingArea viser tegneområdet som et JPanel. Klassen kan ses i Figur 20<= !--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000D0000005F005200= 65006600360033003400330034003400340038000000 .

Figur 20 Klassen DrawingArea

For at fjerne flimmer i g= rafikken bliver der brugt double buffering til at optegne billedet. DrawingArea indeholder en liste af Drawables, drawableList, som endnu ikke er blevet verificeret af serveren, for at sørge for at de enkelte klienter er synkroniserede. Denne list kan tilgås med operationerne add og remove. Operationen paint bruges til at tegne en Drawable på DrawingArea.

WBConfig

WBConfig interfacet er en opremsning af indstillingsmulighederne for whiteboardet.

Messages

Klasserne i Messages er s= om set i figur Figur 21, med Message som superklassen alle klasser nedarv= er fra.

Figur 21 Messages klasse diagram

Objekterne bliver encodet= som byte arrays, så de kan sendes over netværket, ved at kalde enco= de funktionen, som i hvert objekt kalder encode funktionen i den klasse de nedarver fra, før de selv enkoder data, og returnerer det som et byte array. Et sekvensdiagram som viser dette kan ses i Figur 22<= !--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000D0000005F005200= 65006600360033003400330034003400370039000000 .

Figur 22 Sekvensdiagram for enkodning af objekter af klassen Message

På den måde bliver data tilhørende = de enkelte klasser pakket ned som vist på eksemplet af et nedpakket obje= kt af klassen MEllipse i

Figur 23 Formatet for et enkodet objekt = af klassen Message

Et enkodet objekt kan rek= onstruktureres ved at kalde konstruktoren i den klasse den er blevet enkodet ud fra med by= te arrayet som input. Ved at kalde konstuktoren fra superklassen bliver data enkodet ved hjælp af superklassens encode funktion dekodet. Et sekvensdiagram som viser hvordan byte arrayet bliver dekodet kan ses i Figur 24.

Figur 24 Sekvensdiagram for dekodning af objekter af klassen Message

Message

Message er den øverste klasse i Message hieraki= et og kan ses i Figur 25.

Figur 25 Klassen Message

Message opgave bestå= ;r i at identificere objekter af klasser der nedarver fra Message som unikke objekt= er, selvom de har været encoded som et byte array og decoded til et objek= t af klassen Message igen. Dette gøres ved at generere et tilfældigt tal, sessionId, for hvert whiteboard, så de enkelte klienter kan skel= nes fra hinanden og et fortløbende tal, idNr, for hvert objekt af klassen Message, så de enkelte objekter af klassen Message instancieret p&ari= ng; de enkelte klienter kan skelnes fra hinanden. Equals funktionen fra klassen Object er overskrevet så sammenligningen sker på baggrund af id= Nr og sessionId.

Drawable

Drawable nedarver fra Mes= sage og kan ses i Figur 26.

Figur 26 Klassen Darwable

Den indeholder informatio= n om hvilket DrawingArea Drawable skal tegnes på. Endvidere har den en abstract funktion, paint, som bliver kaldt når børn af Drawable skal tegnes på et DrawingArea.

DeltaDrawingArea

DeltaDrawingArea nedarver= fra Drawable og kan ses i

Figur 27 Klassen DeltaDrawingArea

DeltaDrawingArea indehold= er information nødvendigt når der skal tegnes på et eksisterende DrawingArea. color er den farve der skal tegnes med, strokeWid= th er bredden af stregen i pixels og fill er en boolsk værdi som udtrykk= er om objektet som skal tegnes skal fyldes ud eller ej.

Envidere har den en abstr= acte funktioner, create, som skal overskrives af nedarvende klasser så den returnerer en ny instans af den nedarvende klasse, setStartingPoint, som sk= al overskrives af nedarvende klasser så udgangspositionen bliver gemt i = den og setPoint, som skal overskrives af nedarvende klasser så de gemmer = det punkt der er blevet sat. Endvidere skal setPoint returnere en boolsk værdi, hvorvidt hele drawingArea skal gentegnes eller ej.

FullDrawingArea

FullDrawingArea nedarver = fra Drawable og kan ses i

Figur 28 Klassen FullDrawingArea

FullDrawingArea indeholder billedet fra et DrawingArea, så det kan sendes over netværket.<= /p>

MText

MText nedarver fra DeltaDrawingArea og kan ses i Figur 29.

Figur 29 Klassen MText

MText indeholder text skr= evet på DrawingArea og begyndelseskoordinaterne for teksten, x og y, s&ari= ng; tekst kan sendes over netværket.

MDelete

MDelete nedarver fra DeltaDrawingArea og kan ses i Figur 30.

Figur 30 Klassen MDelete

DELETE_STROKE_MULTIPLIER er den faktor strokeWidth bli= ver ganget med før der bliver slettet på drawingArea, så MDe= lete bliver tegnet større end en tilsvarende streg.

MElipse

MElipse nedarver fra DeltaDrawingArea og kan ses i Figur 31.

Figur 31 Klassen MEllipse

MEllipse indeholder begyndelseskoordinaterne, højden og vidden for en ellipse, x, y, w o= g h, så den kan sendes over netværket. Operationen paint tegner en ellipse som beskrevet i variablene.

MMultiLine

Klassen MMultieLine kan ses i Figur 32<= !--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000D0000005F005200= 65006600360033003400330034003500380039000000 .

Figur 32 Klassen MMultiLine

MMultiLine indeholder en = liste af x- og y-koordinater, så en mængde sammenhængende streger = kan tegnes.

MRectangle

Klassen MRectangel kan ses i Figur 33<= !--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000D0000005F005200= 65006600360033003400330034003500390038000000 .

Figur 33 Klassen MRectangle

MRectangle indeholder begyndelseskoordinaterne, højden og vidden for et rektangel, x, y, w= og h, så den kan sendes over netværket. Operationen paint tegner et rektangel som beskrevet i variablene.

Tools

Værktøjerne = til whiteboard er organiseret som vist i Figur 34.

Figur 34 Klassediagram over klasser i to= ols.

Toolbox modtager events f= ra objekter af klassen DrawingArea og videresender dem til det valgte Tool, hvorved objekter af klassen DrawingArea kan manipuleres. Dette kan ses p&ar= ing; sekvensdiagrammet i Figur 35.

Figur 35 Sekvensdiagram over håndteringen af events på whiteboardet

Brugeren tegner på DrawingArea. De generede events bliver hørt af Toolbox, som sender d= em videre til det valgte Tool. Det valgte Tool instancierer en subklasse til M= essage, og modificerer den som Toolet fortolker den modtagne event. Denne Message bliver tegnet på DrawingArea, hvorefter Brugeren enten tegner videre på den samme Message, eller bliver færdig med at tegne. Hvis brugeren tegner videre bliver den instancierede Message modificeret endnu engang. Når brugeren har tegnet færdigt bliver messageCreated k= aldt i Whiteboard, som sender den færdige Message over netværket.

Toolbox

Toolbox klassens opgaver består i at vise Tools i Whiteboardet og videresende events fanget på DrawingArea til det valgte Tool. Klassen Toolbox kan ses i Figur 36.

Figur 36 Klassen Toolbox

Toolbox implementerer KeyListener, MouseListener og MouseMotionListener. Metoderne i Toolbox send= er events fanget fra DrawingArea til currentTool ved at kalde tilsvarende funktioner i tool, handleMouseClicked for mouseClicked og så videre.<= /p>

DrawingConfiguration

DrawingConfiguration klas= sens opgave består i at gemme indstillinger af Tools et centralt sted. Kla= ssen DrawingConfiguration kan ses i Figur 37.

Figur 37 KlassenDrawingConfiguration

strokeColor er den farve = streger skal tegnes med, strokeWidth er den tykkelse streger skal tegnes med i pixe= ls og fill er om objekter skal tegnes fyldt ud eller tomme.

Tool

Klassen Tool kan ses i Figur 38.

Figur 38 Klassen Tool

Tool er en abstrakt klass= e, hvis opgave er at stille en række callbackfunktioner til rådighed for klasser, som nedarver fra tool. Callbackfunktionerne bliver kaldt når= der forgår events på DrawingArea. Tool nedarver fra JButton, og bli= ver derved fremstillet som en knap i ToolBox. Objekter af klassen Tool er deres egen ActionListener og sætter sig selv som valgte Tool i Toolbox når den bliver klikket på.

PressDragRelease

PressDragRelease nedarver= fra Tool og er universalværktøjet for whiteboardet. Klassen PressDragRelease kan ses i Figur 39.

Figur 39 Klassen PressDragRelease

Alt som skal tegnes ved at presse v= enstre museknap ned på DrawingArea, trække musen rundt på DrawingArea og slippe venstre museknap på DrawingArea for at afslutte tegningen, tegnes ved hjælp af toolet PressDragRelease. Et tilstandsdiagram der beskriver PressDragRelease kan ses i Figur 40.

Figur 40 Tilstandsdiagram for objekter af klassen PressDragRelease

Hændelser press, drag og release svarer til de t= re funktioner fra Tool som er overskrevet af PressDragRelease, HandleMousePres= sed, HandleMouseDragged og HandleMouseReleased.

PressDragRelease opererer på DeltaDrawingAreas, så en ny subklasse til DeltaDrawingArea kan gives til PressDragReleas= e, hvorved Whiteboardet nemt kan udbygges med flere tegneredskaber. Objekter af klassen PressDragRelease bliver brugt til at tegne rektangler, elipser, frihåndstegning og til at slette.

TextTool

TextTool nedarver fra Too= l og overskriver funtionerne handleMouseReleased i Tool. Klassen TextTool kan se= s i Figur 41.

Figur 41 Klassen TextTool

Når musens venstre = knap bliver sluppet på DrawingArea poppes en JTextField op, hvori der kan skrives. Ved endt skrivning bliver der instancieret et objekt af klassen MT= ext som bliver sendt til Whiteboard.

FillChooserTool

FillChooserTool nedarver = fra Tool og overskriver actionPerformed, så FillChooserTool ikke bliver valgt = som det aktive Tool i Toolbox når der bliver klikket på Toolet i Toolboxen, men i stedet ændrer på om rektangler og ellipser skal tegnes fyldt ud eller tomme. Klassen FillchooserTool kan ses i Figur 42= .

= Figur 42 Klassen FillChooserTool

ColorTool

K= lassen ColorTool kan ses i Figur 43.

Figur 43 Klassen ColorTool

Ligesom FillChooserTool n= edarver ColorTool fra Tool, og overskriver actionePerformed i Tool, så ColorT= ool ike bliver valgt som det aktive tool, men i stedet åbner en color cho= oser dialog, hvor der kan vælges en farve. DrawingConfiguration bliver efterfølgende opdateret, så color er tilgængelig for alle tools.

StrokeWidthChooser

StrokeWidthChooser, som ses i Figur 44<= !--[if gte mso 9]> 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000D0000005F005200= 65006600360033003400330034003700370039000000 , nedarver ikke fra Tool som de andre værktøjer, men i stedet fra JSlider, så den bliver en sl= ider i stedet for en knap.

Figur 44 Klassen StrokeWidthChooser

StrokeWidthChooser er sin egen ChangeListener og opdat= erer DrawingConfiguration når StrokeWidth bliver ændret, så StrokeWidth er tilgængelig for alle tools.

Whiteboardserver

Klassediagramme for WhiteboradServeren kan ses i Figur 45.

Figur 45 Klassen SServer

Whiteboardserveren best&a= ring;r af en enkelt klasse, SServer, som sender beskeder modtaget fra en whiteboardklient ud til alle whiteboardklienterne. Endvidere gemmes modtagne beskeder i et objekt af klassen DrawingTabbedPane. Når en bruger logg= er på whiteboardserveren bliver DrawingAreaer fra DrawingTabbedPane sendt til den nye whiteboardklient, så den har samme DrawingAreaer som de a= ndre klienter.

Resultater

Et screendump af det endelige produkt kan ses i Figur 46. Det viste Whiteboardet kører som en applet under Windows.

Figur 46 Whiteboardet

I venstre side ses den gr= afiske repræsentation af Toolbox med de forskellige tools, som kan bruges ti= l at manipulere drawingArea med. I midten ses den grafiske repræsentation = af DrawingArea med tabbed panes, som kan bruges til at skifte mellem de forske= llige whiteboards, i toppen.

Ved at højreklikke på whiteboardet åbnes WBPopupMenu med de to underpunkter Open og Save as, som det ses i

Figur 47 Whiteboardet med WBPopupMenu

Whiteboardet blev testet = på samme måde som de fundne whiteboards blev testet i foranalysen, da det ikke er muligt at måle latenstid fra noget er tegnet på et whiteboard til det dukker op på et andet.

Test

Opsætn= ing:

· 2 Klienter

· = OS: Windows XP og Windows 2000

· 1 Server

· OS: Windows 2000

· LAN

Udfør= sel:

Whiteboardserveren blev started på serverpc’eren, hvorefter whiteboardklienterne blev started på d= e to klientmaskiner med serverens IP-addresse som parameter.

Resultat:

Latenstid

Overførslen af simple figurer som firka= nter, cirkler og frihåndstegning foregik med lav latens (under et sekund).<= /p>

Overførsel af billeder, ved at åb= ne dem i whiteboardklienten, foregik også med lav latens (under et sekund).<= /p>

Konklusion

Der er udviklet et shared whiteboard ved hjælp af klient/server arkitekturen. Shared whiteboard= har et simpelt brugerinterface hvormed, der kan tegnes simple figure og skrives tekst, gemme og hente billeder. Overførslen af figurer og billeder o= ver netværket sker med lav latenstid.

Shared whiteboard er blev= et udviklet efter objektorienterede principper og implementeret i Java. Under udviklingen er der blevet lagt stor vægt på at shared whiteboard skulle være let at videreudvikle, hvilket har resulteret i et udbyggelsesvenligt produkt.

Derudover kan shared whit= eboard indgå som en delkomponent i andre projekter da whiteboardklienten kan indlejres i en Java frame eller en applet.

En begrænsning for = shared whiteboard er at det ikke er udviklet til flere tavlesessions, hvilket reulterer i at der skal være en server til hvert enkelt shared whiteboard.

Fremtidigt arbejde

Da hverken serveren eller= den brugte protokol, TCP, understøtter brugen af flere tavlesessioner kan der implementeres en sessionsprotokol mellem transportlaget og shared whiteboard.

Endvidere kan funktionali= teten udbygges med flere tegneredskaber.

Installering

Whiteboardklient i en applet

Sørg for at jar fil med whiteboard klienten er "signed" med et certifikat. Kend IP-addressen på en kørende whiteboard server.
Skriv jar filen ind på den hjemmeside hvor whiteboard skal vises. Det gøres såden:

<APPLET codebase=3D"../../../&quo= t; code=3D"vcollege/whiteboard/client/WBStart.class"

archive=3D"vcollege/whiteboard/clien= t/WBStart2_3.jar" width=3D800 height=3D600>

</APPLET>

Parameteren serverip bliv= er brugt af klienten til at connect til serveren. Ændr dens value til serverens IP-addresse.

Sørg for at hjemmesiden ligger på en webserver der understøtter applets. Webserveren og whiteboardserveren kan være samme ip/maksine.
Gå ind på hjemmesiden og appletten starter op automatisk i browsere= n.

Whiteboardserver

Find SServer.class filen. Den ligger som standard under vcollege/whiteboard/server. Serveren kører på TCP port 12= 58.
Start serveren ved: java SServer
Klienter kan nu connect til serveren og tegne på dennes whiteboard. Sørg for at klient- og serverversionerne er kompatible og at der ikke er problemer med proxyen for klienterne.

How To =

Tilføje features til whiteboard

Alle klasserne nævnt i den følgende tekst= kan findes i vcollege.whiteboard.client pakken(package). En god forståels= e af java syntax og semantic er at foretrække for at bruge denne how to, m= en nogle af emnerne kan udføres af de fleste brugere.

Popup menu (højre click på whiteb= oard)

Find WBPopupMenu class.
Tilføj et menu item til popupmenu i meto= den

private void createPopupMenu( JPopupMenu popmenu, ActionListener al) med eksempelvis popmenu.add(new JMenuItem("NAMETOAPPEAR", SHORTCUTKEY )).addActionListener(al);

SHORTC= UTKEY: er en tast som brugeren trykker på istedet for musen, referer til, ja= va api class KeyEvent. Kan også blot udelades.

Gå til

public void actionPerformed(ActionEvent e= )

og tilføj en if st= atement i begyndelsen af methoden, som her:

if (sourceText.equals("NAMETOAPPEAR")) {

//kode der skal eksekveres når brugeren trykker.

}

hvor NAMETOAPPEAR er det = samme som i 2.

Lav et nyt DeltaDrawingArea

DeltaDrawingArea er de objecter der ændrer p&ari= ng; drawingarea’et, f.eks. en firkant, referer til klassebeskrivelsen for mere info. Som eksempel på et specialiseret DeltaDrawingArea kan anbefales MEllipse.

Opret en ny klasse som nedarver DeltaDrawingArea klassen.

pub= lic class NAVN extends DeltaDrawingArea

her er NAVN navnet p&arin= g; den ny klassen.

Da DeltaDrawingArea er en abstract klasse kræver den at en ræ= kke metoder som minimum implementeres. Disse er:

abstract void setStartingPoint(int x, int y);

&nb= sp; kaldes når startkoordinaten kendes.

    abstract boolean setPoint(int x, int y, java.awt.Graphics g);

            kaldes hvergang et nyt koordinat kendes(hvis f.eks. musen trækkes).

    abstract DeltaDrawingA= rea create();

            skal returnere en ny instans af det mest specialiseret object.

Skriv metoderne ind i kla= ssen (fjern abstract).

To andre metoder er nødvendige for at objecter transmitteres korre= kt over netværket. Tilføj følgende metoder:

    public ByteArrayOutput= Stream encode() {

        ByteArrayOutputStream baos =3D super.encode();

            //tilføj de ting til baos’en som er nødvendige for encodningen.

    }

og en constructor (virker= kun med nøjagtigt fingerprint)

    public NAVN(ByteArrayInputStream bais){

        super(bais);

//fjern de ting fra bais’en som du encoded ovenfor i samme rækkefølge.<= /o:p>

    }

NAVN er klassenavnet.

Klassen består også af Drawable(endnu en abstract klasse), her er = det nødevendig at implementer en metode om hvordan objected skal te= gnes (fjern abstract).

public abstract void paint(Graphics g);

grafik objectet g, er der= hvor grafikken skal tegnes på. Det udgør hele tegnefladen i størrelsen.

Hvis det giver mening at oprette objectet med tryk-træk-slip adfær(denne er så generel at det virker for stort set alle ting der skal tegnes, og det er jo netop tilfældet her), kan det= ny DeltaDrawingArea tilføjes i Toolbox umiddelbart ved brug af den allerede eksisterende PressDragRelease klasse. Find klassen Toolbox og tilføj i konstruktoren:

this.add(new PressDragRelease(this, createImageIcon("toolpics/FILNAVN.png", "ICON_NAVN"), n= ew NAVN()));

<= o:p>

NAVN er klassenavnet.

ICON_NAVN er et arbitr&ae= lig;rt navn, som ikke skal bruges til noget.

FILNAVN er navnet på= ; en billedfil som bliver billedet på iconet.

Kilder

[RFC2543] - SIP: Session initiation protocol

http://www.ietf.org/rfc/rfc2= 543.txt

<= o:p>

[RFC1889] - RTP: A transport protocol for real-time applications

http://www.ietf.org/rfc/rfc1= 889.txt

<= o:p>

[RFC768] – UDP: User datagram protocol

http://www.faqs.org/rfcs/rfc793.html

<= /span>

[RFC791] – IP: Internet protoc= ol

http://www.faqs.org/rfcs/rfc= 791.html

<= o:p>

[RFC793] – TCP: Transmission control protocol

http://www.faqs.org/rfcs/rfc= 793.html

<= o:p>

[RFC1945] <= span lang=3DEN-US style=3D'mso-ansi-language:EN-US'>HTTP: Hypertext Transfer Pro= tocol

http://www.faqs.org/rfcs/rfc= 1945.html

<= o:p>

[COCC] – Coccinella homepage=

http://hem.fyristorg.com/matben/

<= o:p>

[NETA] – Network Assistant h= omepage

http://www.gracebyte.com/nassi/

<= o:p>

[MICA] – The MICA Graphics F= ramework homepage

http://www.swfm.com/mica.htm

<= o:p>

[DJSE] – Developing Java Ser= vlets. James Goodwill ISBN: 0-672-31600-5

<= o:p>

[TYJS] – Teach Yourself Java= Server Pages. Jose Annunziato et al. ISBN: 0-672-32023-1

[JSSE] – Jav= aServer Pages, Second Edition. Hans Bergsten ISBN: 0-596-00317-X

[PJSP] – Proffesional Java Se= rver Programming. Danny Ayers et al. ISBN: 1-861002-77-7

[XML] – Extensible Markup Language (XML)

http://www.w3.org/XML/

<= o:p>

Indledning=

Foranalyse=

TCP (Transport Control Protocol) [RFC793]

HTTP (HyperTekst Transfer Protocol) [RFC1945]

UDP (Universal Datagram Protocol) = [RFC768]

RTP (Real Time Protocol)= [RFC1889]

SIP (Session Initiation Protoco= l) [RFC2543]

Coccinella [COCC]

Test af Coccinella

Opsætn= ing:

Udfør= sel:

Resultat:

Network Assistant [NETA] Network Assistent er et L= AN chatprogram med indbygget shared whiteboard og eventlogger.

Test af Network Assistant

Opsætn= ing:

Udfør= sel:

Resultat:

Whiteboardklient

Delprobl= emer

Whiteboardserver

Opsætn= ing:

Udfør= sel:

Resultat:

How To =

Network Assistant [NETA]
Network Assistent er et L= AN chatprogram med indbygget shared whiteboard og eventlogger.