Programutvecklingsprojekt, 2D1954 Slutlig rapport, VT2002

Projektledare: Kursledare: Dan Sydner, d99-dsy@d.kth.se Lars Kjelldal, KTH/NADA. 2002-05-03 lassekj@nada.kth.se

Systembeskrivning för Programutvecklingsprojekt, Big Brother

Lättanvänd fjärrstyrd kamera

2

Innehåll 1. SYSTEMSKISS.................................................................................................................... 3

2. SYSTEMBESKRIVNING SERVER.................................................................................... 4

2.1. GRUNDLÄGGANDE KONCEPTUELL LÖSNING....................................................................... 4 2.2. SERVERNS OLIKA MODULER ............................................................................................... 5 2.3. FLÖDEN OCH UTFORMNING AV MEDDELANDEN. ................................................................. 6 2.3.1. INITIERING ........................................................................................................................6 2.3.2. STYRNING .......................................................................................................................10 2.4. ATT LÄGGA TILL EN KAMERA ELLER ETT USERPRIORITYFILTER ..................................... 12 2.4.1. CAMERAINTERFACE.........................................................................................................12 2.4.2. USERPRIORITYFILTER......................................................................................................12

3. SYSTEMBESKRIVNING KLIENT................................................................................... 14

3.1. OM KLIENTEN .................................................................................................................. 14 3.2. HUVUDPROGRAM ............................................................................................................. 14 3.3. JOYSTICKHANTERING ...................................................................................................... 15 3.4. INLOGGNING.................................................................................................................... 16 3.5. KOMMANDOHANTERING .................................................................................................. 16 3.6. ÖVRIGA KLASSER............................................................................................................. 18 3.7. LITE OM VISUAL BASIC .................................................................................................... 18

3

1. Systemskiss

Joystick-signaler

USB

Kontrollkommandonför kamerastyrning

TCP/IP

KamerastyrningRS-232

Server

Klient

Figur 1 Systemets hårdvarukomponenter

Figur 1 visar schematiskt hur de olika hårdvarukomponenterna är sammankopplade. I rutorna tillhörande kommunikationsledningarna anges vilken typ av signaler som transporteras och på vilket sätt detta sker. Figuren illustrerar även avgränsningarna mellan systemets olika delar; klienten och servern.

4

2. Systembeskrivning server

2.1. Grundläggande konceptuell lösning

Ett grundläggande krav på servern är att den skall kunna styra alla sorters kameror. För att satisfiera detta krav laddar servern in en kameraspecifik modul dynamiskt. Eftersom olika kameror kan ha avsevärt skild funktionalitet måste varje kameraspecifik modul tillhandahålla en lista över till tillgängliga kamerakommandon samt hur dessa skall användas. Med hjälp av denna lista kan en generell klient anpassa sig till och styra alla tänkbara kameror. Flera klienter skall kunna koppla mot servern samtidigt. De olika klienternas önskemål om hur kameran skall styras måste hanteras på ett bra sätt. Men det finns inget generellt bra sätt att hantera detta därför finns även möjligheten att dynamiskt ladda in olika strategier för hur detta skall hanteras. Dessa strategier kallas för UserPriorityFilter. Alla inställningar på servern sker genom textfiler. Dessa läses in vid start av servern. Serverns inställningsfil heter server.cfg. I denna fil anges inställningar för serieporten, vilken IP-port servern lyssnar på, vad filen med användare finns, samt vilken kamera-och UserPriorityFiltermodul som skall laddas. Ett annat krav är att en godtycklig klientapplikation ska kunna kommunicera med servern och styra kameran. Detta ställer höga krav på kommunikationsprotokollet. Det måste vara plattforms- och programspråksoberoende samt lätt att förstå. Givet dessa villkor är ASCII-text ett bra val.

5

2.2. Serverns olika moduler

Servern är uppdelad i sju huvudmoduler (klasser). Nedan illustreras hur dessa klasser hänger ihop.

Server ServerThread

1 *

UserLogin

1

1

SerialPortCommuniator

«interface»CameraInterface

1

1

*

1

«interface»UserPriorityFilter

* 1

Broadcaster

*

1

1

1

1

1

Var och en av dessa klasser har specifika ansvarsområden:

• Server: hanterar initiering, dynamisk laddning av kamera och UserPriorityFilter samt klienternas uppkopplingfas.

• UserLogin: validerar klienters behörighet, upprätthåller en lista på inloggade klienter • ServerThread: kommunicerar med klienten samt fördelar klientens begäran till rätt

mottagare. Det finns en ServerThread per klientkoppling (se diagrammet ovan). • UserPriorityFilter: avgör vilka begäran från klienterna som skall utföras och vilka som

skall refuseras. Denna klass är även mottagare av klientbegäran. En typ isk begäran är att ändra på klassens interna prioriteringsinställningar.

• Broadcaster: genom denna klass skickas meddelanden till en eller alla klienter (ServerThreads). Används för att meddela alla klienter om genomförda kameraoperationer. På dessa sätt kan alla klienter hålla sig uppdaterade.

• CameraInterface: översätter begäran från klienter till kameraspecifika kommandon samt läser eventuella svar från kameran. Tillhandahåller en lista över alla tillgängliga kommandon samt hur dessa skall användas.

• SerialPortCommunicator: sköter kommunikationen med serieporten.

6

2.3. Flöden och utformning av meddelanden.

Som nämndes tidigare skickas alla meddelanden mellan servern och klientapplikationen som ASCII-text. Strukturen på meddelandena är lik HTML-standarden med dess start- och sluttaggar. Detta gör att det är lätt för både människa och dator att läsa och skicka meddelanden. Ett problem med att använda ASCII-text är att radbryt kodas olika på olika plattformar. I detta protokoll används alltid \n (linefeed) som radbryt. Kommunikationen mellan server och klientapplikation sker i två faser. I den första fasen, initiering, loggar klienten in samt erhåller en komplett beskrivning över kamerans funktionalitet samt hur den ska användas. Denna kommunikation sker synkront. Den andra fasen, styrning, består kommunikationen av klientbegäran och svar från servern. Dessa meddelanden skickas asynkront.

2.3.1. Initiering

Nedan visas hur meddelanden skickas under fasen initiering.

Server

Klientapplikation

John Pohlman

Server

login()

UserLogin

validate user()

CameraInterfaceServerThread

login ok()

login ok()

new()

get avail list()

avail list()

avail list()

Det första som sker när en klientapplikation kopplar mot servern är att klienten skickar ett inloggningsmeddelande: LOGIN_REQUEST_START <användarnamn> <lösenord> LOGIN_REQUEST_END

7

Om inloggningen inte accepteras skickas följande meddelande och kopplingen stängs: LOGIN_RESPONSE_START LOGIN_FAILURE LOGIN_RESPONSE_END Om inloggningen accepteras skickas meddelandet: LOGIN_RESPONSE_START LOGIN_SUCCESS LOGIN_RESPONSE_END Sedan skickas den omtalade funktionalitetsbeskrivningen. Den har två huvuddelar: lista över tillgängliga kamerakommandon samt en lista över hur dessa skall användas. Listan över alla kamerakommandon har denna grammatik: CAMERA_AVAILABLE_COMMAND_LIST_START CAMERA_COMMAND_START <kamerakommandonamn> <användarvänligt namn> DESCRIPTION_START <en flerraders användarvänlig beskrivning> DESCRIPTION_END PARAM_LIST_START PARAM_START <namn på parameter> <typ av parameter, tex INTEGER_BOUNDED, samt

eventuella egenskaper hos parametern.> PARAM_END PARAM_LIST_END ANSWER_LIST_START ANSWER_START <namn på svarsparameter> ANSWER_END ANSWER_LIST_END CAMERA_COMMAND_END CAMERA_AVAILABLE_COMMAND_LIST_END Ett godtyckligt antal kamerakommandon, parametrar och svarsparametrar kan skickas. Om ett visst kamerakommando inte tar några parametrar skickas ingen parameterlista, detta gäller även svarsparametrar. Nedan följer två exempel på kamerakommandon, ett utan svarsparameter och ett utan parameter. CAMERA_COMMAND_START SET_MOTION_SPEED Sets the speed of the camera motion DESCRIPTION_START This command enables you the user to control the speed of the camera. DESCRIPTION_END PARAM_LIST_START

8

PARAM_START Motion speed INTEGER_BOUNDED 1 100000 PARAM_END PARAM_LIST_END CAMERA_COMMAND_END CAMERA_COMMAND_START GET_MOTION_SPEED Gets the speed of the camera motion DESCRIPTION_START This command enables you the user to read the speed of the camera. DESCRIPTION_END ANSWER_LIST_START ANSWER_START The speed of the motion

ANSWER_END ANSWER_LIST_END CAMERA_COMMAND_END Beskrivningen av hur ovanstående kamerakommandon skall användas har följande grammatik: CAMERA_COMMAND_GROUP_LIST_START CAMERA_COMMAND_GROUP_START <användarvänligt namn på gruppen av kommandon> <typ av grafisk komponent samt en lista på

kamerakommando som komponenten använder> CAMERA_COMMAND_GROUP_END CAMERA_COMMAND_GROUP_LIST_END En kamerakommandogrupp består av ett antal logiskt sammanhängande grafiska komponenter. Listan kan innehålla ett godtyckligt antal grupper och varje grupp kan innehålla ett godtyckligt antal grafiska komponenter. Det finns i nuläget två olika typer av grafiska komponenter: klickknapp och tryck-släppknapp. Klickknappen använder sig av ett kamerakommando. Detta kamerakommando skickas när knappen klickas. Tryck-släppknappen använder sig av två kamerakommandon. Det första skickas när knappen trycks ner, det andra när knappen släpps upp. Här följer ett exempel för en grupp med två grafiska komponenter: CAMERA_COMMAND_GROUP_START The focus camera command group CONTROL_TYPE_CLICK_BUTTON GO_INTO_MANUAL_FOCUS CONTROL_TYPE_PUSH_RELEASE_BUTTON FOCUS_NEAR FOCUS_STOP

9

CAMERA_COMMAND_GROUP_END

10

2.3.2. Styrning

Nedan visas hur ett meddelande av typen kamerabegäran skickas och hanteras under fasen styrning.

Server

Klientapplikation

John Pohlman

CameraInterfaceServerThread UserPriorityFilter

camera request()

accept request()

ok()

handle request()

camera response()

camera response()

Alla meddelanden som skickas under fasen styrning skickas asynkront, dvs klientapplikationen kan skicka begäran vid godtycklig tidpunkt och servern kan skicka meddelanden till klientapplikationen vid godtycklig tidpunkt. Som visas i diagrammet ovan går alla begäran genom UserPriorityFilter innan de skickas till respektive mottagare. Om en begäran accepteras skickas den vidare, annars avbryts begäran och ett felmeddelande skickas. Detta felmeddelande har följande grammatik: USER_PRIORITY_FILTER_ERROR_RESPONSE_START REQUEST_REJECTED ERROR_MESSAGE_START <felmeddelande> ERROR_MESSAGE_END REQUEST_COPY_START <kopia av den begäran som avslogs> REQUEST_COPY_END USER_PRIORITY_FILTER_ERROR_RESPONSE_END Det finns två typer av begäran som klientapplikationen kan skicka: UserPriorityFilter-begäran och kamerabegäran.

11

En begäran av typen UserPriorityFilter har följande grammatik: USER_PRIORITY_FILTER_REQUEST_START TAKE_CONTROL_OF_CAMERA | RELEASE_CONTROL_OF_CAMERA USER_PRIORITY_FILTER_REQUEST_END Om begäran gick bra att utföra skickas ett svar med följande grammatik: USER_PRIORITY_FILTER_OK_RESPONSE_START <namnet på användaren som berördes> REQUEST_COPY_START <kopia av den begäran som utfördes> REQUEST_COPY_END USER_PRIORITY_FILTER_OK_RESPONSE_END Om begäran däremot inte gick att utföra skickas samma typ av svar som när en begäran ej accepterades av UserPriorityFilter. En begäran av typen kamerabegäran har följande grammatik: CAMERA_REQUEST_START <kamerakommandonamn> <eventuell parameterlista> CAMERA_REQUEST_END Om kamerabegäran gick bra skickas ett svar ut till alla klientapplikationer. Detta svar har följande grammatik: CAMERA_OK_RESPONSE_START CAMERA_OK REQUEST_COPY_START <kopia av den begäran som utfördes> REQUEST_COPY_END CAMERA_ANSWER_START <lista över svaren från den fysiska kameran> CAMERA_ANSWER_END CAMERA_OK_RESPONSE_END I de fall där kameran inte ger några svarsparametrar utelämnas svarslistan. Men om det inte gick att utföra kamerabegäran skickas ett felmeddelande till den klientapplikation som skickade begäran. Felmeddelandet har liknande grammatik som felmeddelanden från UserPriorityFilter. I detta fall är grammatiken: CAMERA_ERROR_RESPONSE_START CAMERA_BUSY | CAMERA_PARAMETER_ERROR |

CAMERA_MODE_ERROR ERROR_MESSAGE_START <felmeddelande> ERROR_MESSAGE_END REQUEST_COPY_START <kopia av den begäran som gick fel> REQUEST_COPY_END CAMERA_ERROR_RESPONSE_END

12

2.4. Att lägga till en kamera eller ett UserPriorityFilter

För att utveckla/implementera en ny kamera (CameraInterface), eller UserPriorityFilter behöver utvecklaren bara implementera motsvarande gränssnitt. Alla andra klasser är generella. De fungerar med godtycklig implementation av kamera samt UserPriorityFilter. Arbetet att lägga till en ny kamera eller ett nytt UserPriorityFilter är således minimalt. Nedan följer en kort beskrivning av dessa gränssnitt.

2.4.1. CameraInterface

CameraInterface är det gränssnitt som en kamera implementerar. Gränssnittet består av följande tre metoder: initCamera(), handleRequest() samt getCameraAvailableCommandList(). Metoden initCamera() tar två argument: namnet på en inställningsfil samt en referens till SerialPortCommunicator objektet. Denna metod anropas av Servern när den startas. handleRequest() anropas när en klient har gjort en kamerabegäran, denna begäran skickas med som argument. Returvärdet från metoden skall innehålla svaret från den fysiska kameran. Det är ServerThread som anropar handeRequest(). Detta sker endast om klientens begäran har godkänts av UserPriorityFilter. Som sista metod måste även getCameraAvailableCommandList() implementeras. Denna metod anropas varje gång en ny klient kopplar mot servern. Den sträng som denna metod returnerar beskriver hela kamerans funktionalitet, alla kommandon, samt hur den skall användas.

2.4.2. UserPriorityFilter

Varje strategi för hur flera inloggade klienter skall hanteras skall implementera gränssnittet UserPriorityFilter. Detta gränssnitt består av tre metoder: initUserPriorityFilter(), acceptRequest() samt handleRequest(). Metoden initUserPriorityFilter() tar tre argument: en refe rens till UserLogin, Broadcaster samt namnet på en inställningsfil. Anropas när Servern startas. Den viktigaste metoden i detta gränssnitt är acceptRequest(). Det är genom denna metod som strategin verkar. Metoden anropas när en klient gör en begäran. Denna begäran ges som argument till acceptRequest(), även användaren ges som argument. Om strategin accepterar begäran returneras ett bifallande svar, annars ett nekande. Om klientens begäran accepterades

13

skickas den vidare till rätt mottagare av begäran. Metoden utgör ett filter mellan klienten och serverns olika moduler. En implementation av detta gränssnitt är inte bara ett filter utan även en mottagare av klientbegäran. Metoden handleRequest() tar användaren och dess begäran som argument. Genom denna metod kan klienter begära att få styra kameran.

14

3. Systembeskrivning klient

Syftet med denna tekniska beskrivning är att förmedla en bild av hur klientimplementationen är strukturerad, utan att gräva ner sig allt för mycket i detaljer. Vi kommer därför att beskriva klientens olika delar var för sig, och detta på ett sätt som är begripligt också för en lekman.

3.1. Om klienten

Klientdelen av kamrastyrningsprogrammet Big Brother är en applikation skriven i Visual Basic 5. Valet av programmeringsspråk kan härledas till behovet av att få kontroll över en joystick i kombination med en önskan om ett grafiskt tilltalande, och lättanvänt användargränssnitt. Eftersom Visual Basic i kombination med Direct X tillgodoser båda dessa krav, föll det sig naturligt att använda just dessa. På en övergripande nivå skulle klienten kunna beskrivas utifrån fyra delar, vilka återges i bilden nedan. I själva verket är dock klienten något mer komplex än vad som av bilden framgår. Denna beskrivning tjänar dock väl för att illustrera hur vi har valt att strukturera vårt arbete. De olika delarna kommer att disskuteras mer i detalj i de efterföljande kapitlen.

3.2. Huvudprogram

Huvudprogrammet består egentligen bara av en klass (eller form för att använda adekvat Visual Basic-terminologi), mainWindow. mainWindow är den del som håller ihop resten av programmet; en slags spindeln i nätet. Förutom att vara klientens ansikte utåt sker också kommunikation med såväl joystick som kommunikation med den server – till vilken kameran är ansluten – genom mainWindow. Denna del av programmet bestämmer vad som skall skickas var, samt när detta skall ske.

Huvudprogram

Joystickhantering

Kommandohantering

Inloggning

15

3.3. Joystickhantering

Fyra klasser – i kombiantion med mainWindow – hanterar all input och output, samt eventuell processning av detta, som relaterar till joysticken och är av relevans för klienten. Hur dessa klasser förhåller sig till varandra återges i bild 2. Som framgår av bilden är de fyra klasserna Joystick, JoystickStatus, statComp och JoystickInfoForm.

Klassen Joystick är den som pratar med (den fysiska; till datorn anslutna) joysticken. Denna klass har en instans till ett Direct X-objekt vilket är det som verkligen sköter kommunikationen med joysticken. Klassen Joystick syftar mest till att göra det enkelt för något program att prata med en joystick (vilken som helst). Anledningen till att vi valt att använda oss av Direct X, är att om vi skulle valt att själva skriva kod för joystickhanteringen, skulle vi åta oss en näst intill omöjlig uppgift; åtminstone inom ramen för vårt projekt. Genom Direct X får vi nu uppgifter om anslutna joystickenheter, vad dessa kan samt information om deras status. Vi kan också relativt enkelt själva bestämma delar av deras funktionalitet. Varför skulle vi tacka nej till detta? I praktiken fungerar joystickhanteringen som följer: mainWindow skapar inledningsvis en instans av klassen Joystick. För att tillåtas att göra detta måste mainWindow registrera sig själv i Joystick (eg. skicka med en referens till sig själv) samt implementera en metod notif som tar emot en instans av klassen JoystickStatus. Klassen JoystickStatus är ingenting annat än en samling attribut som tillhandahåller information om joysticken aktuella status; t.ex. vilka knappar är nedtryckta, i vilken position är styrspaken etc. Så fort en förändring av joystickens tillstånd sker kommer en JoystickStatus- instans att skickas till mainWindows noify-metod. Från notify-metoden skickas därför meddelanden till kameraservern om de delar av kamerans funktionalitet som styrs via joysticken. Innan styrmeddelanden till kameran skickas till servern, kommer den aktuella joystickstatusen att jämföras med den tidigare. Om vi styr joysticken till ett läge som kan beskrivas av vädersträcket NW och sedan för spaken till läge SW, så kommer notify att anropas eftersom joysticken har ändrat sig i y- led; från N till S. För att vi skall kunna veta att ändringen gäller just y- led, och ingenting annat, måste vi jämföra två efterföljande tillstånd. Anledningen till att vi vill veta detta är därför att

mainWindow

JoystickInfoForm

Joystick

statComp

JoystickStatus ⇒

⇐ status info

⇐ status info

16

vi inte vill skicka fler meddelanden än nödvändigt till servern. Ett alternativ hade annars varit att skicka alla styrmeddelanden till servern var enda gång vi blir ”notifyade”, t.ex. skicka instruktioner till kameran om att ”tilta” åt höger även om du kanske redan har bett den att göra det. Den jämförelse som ovan beskrivs utförs av klassen statComp (status compare), vilken ett antal funktioner som gör jämförelser av olika delar av joystickens output, t.ex. hastighetsändring (ändring av utslag kring någon axel) och riktningsändring. Avslutningsvis kan klassen JoystickInfoForm nämnas. Denna är en grafisk komponent som visar den aktuella joystickstatusen för användaren. Komponenten kan slås av och på via en meny i mainWindow.

3.4. Inloggning

Klientens inloggningsdel är synnerligen okomplicerad och beskrivs schematiskt av bild 3.

En klass ConnectForm – inloggningsdelens grafiska användargränssnitt – tillåter användaren att mata in uppgifter om vilken server han vill koppla upp sig mot. Han förväntas här också mata in uppgifter om sitt användarnamn samt sitt lösenord. En annan klass, HostList, ser sedan till att de inmatade uppgifterna sparas; HostList förser också ConnectForm med uppgifter om tidigare sparad data som ConnectForm använder vid uppstart. Efter det att användaren valt vilken dator han vill koppla upp sig mot, och matat in användaruppgifter, blir dessa data tillgängliga för mainWindow som sedan kan utföra uppkopplingen och inloggningen.

3.5. Kommandohantering

En grundidé vid utvecklingen av klienten har varit att man enkelt skall kunna styra kameran med joysticken. För att detta skall fungera är det av nödvändighet att endast en liten mängd av kamerans funktionalitet knyts till joysticken; vår utgångspunkt har faktisk varit att man inte skall behöva använda mer än en hand för att styra kameran, en föresatts vi också lyckats genomdriva. Ett ytterligare skäl till att endast en delmängd av kamerans funktionalitet knyts till joysticken, är att vår ambition har varit att klienten skall vara generell, d.v.s. klienten skall så långt det är

ConnectForm

HostList

mainWindow

17

möjligt gå att använda oavsett vilken kamera som skall styras. Vi har därför låtit joysticken styra sådana funktioner som kan antas finnas hos det stora flertalet kameror, t.ex. ”tilt” (upp/ner), ”pan” (vänster/höger) och ”zoom”. Att inte joysticken styr all kamerans funktionalitet betyder dock inte att inte klienten kan göra det. Möjligheten att t.ex. kunna styra kamerans kontrast (om en sådan funktion finns) är nog så viktig, även om det inte görs via joysticken. Möjliggörandet av detta sker via ”kommandogrupper”. När en lyckad uppkoppling mot en server sker (se kapitlet Inloggning) kommer servern att skicka en beskrivning över all tillgänglig funktionalitet hos den kamera som är ansluten till servern (för ytterligare information om detta hänvisas till den tekniska beskrivningen av servern). I denna beskrivning återfinns också vilka typer av kontroller som skall representera de olika kamerafunktionerna (t.ex. ”click”-knappar, ”push-release”-knappar, ”input”-fält etc.) samt hur dessa skall grupperas. Beskrivningen talar också om vad som skall hända då användaren använder en kontroll; vilket kommando som skall skicka till servern. Klientens uppgift är således att utifrån en av servern skickad kamerafunktionalitetsbeskrivning, generera ett användargränssnitt som implementerar denna kamerafunktionalitet. Bild 4 visar ur detta arbete är organiserat.

En kamerafunktionsbeskrivning kommer via mainWindow från servern. mainWindow skickar beskrivningen till InputHandler som parsar (analyserar) den och skapar för varje

mainWindow

InputHandler

CommandHolder

ParamType

CommandHash

GuiCommand

GuiCommand

Group

CommandForm

18

kamerafunktion en CommandHolder som kommer att innehålla information om funktionens namn, beskrivning osv. En ParamType skapas, vilken håller reda på vilken typ av parametrar som den aktuella funktionen använder, t.ex. typ av parameter, min- och max-värden, namn, osv. Den skapade ParamTypen läggs sedan till den korrespondernade CommandHoldern. CommandHoldern stoppas in i en (hash)tabell för senare åtkomst. När hela den inledande beskrivningen har parsats (en CommandHolder med tillhörande ParamType har skapats och ”hashats” för var och en av kamerans funktioner), följer i beskrivningen vilka typer av knappar som hör till vilka funktioner. Utifrån denna del av beskrivningen skapas nu GuiCommands (grafiska representationer) för olika funktioner. Dessa grupperas också enligt den från servern erhållna beskrivningen i olika GuiCommandGroups. Det förefaller kanske läsaren märkligt att man inte skapar den grafiska representationen av en funktion samtidigt som man skapar det beskrivande objektet för samma funktion. Detta förfaringssätt är dock fullkomligt rimligt; först talar man om vad kan kameran, sedan talar man om vad utav detta skall klienten klara av och hur skall det se ut. Avslutningsvis visar man de skapade grupperna i ett för användaren smakfullt gränssnitt, ett CommandForm. CommandForm:en kommer sedan, utifrån användarens interaktion, att skicka kommandon till servern om utförande av funktioner; kommandona skickas i sedvanlig ordning via mainWindow. Den lösning – så som ovan beskrivits – borgar för att klienten i stor utsträckning är generell. Den vet inte i förväg vad en kamera som den kopplar sig mot kan, men användaren kommer likväl att kunna komma åt samtliga av kamerans funktioner.

3.6. Övriga klasser

Det finns två delar (klasser) av klientimplementationen som ännu inte nämnts, främst därför att de delvis faller utanför den inledande bild (bild 1) som inledningsvis gavs av klienten. Dessa två klasser är pc och PositionHolder. pc är en modul som innehåller strängkonstanter för alla de kommandon som kan skickas till en viss kameraserver. Dessa konstanter underlättar avsevärt vid kommunikation mer en kameraserver. Klassen (egentligen modulen; se appendix) genereras av Big Brother-severprogrammet och den intresserade hänvisas till serverns tekniska dokumentationen för ytterligare information. PostitionHolder är en klass som kan fråga en kamera efter dess position och sedan komma ihåg denna. Via mainWindows användargränssnitt kan man spara kamerapositioner i en lista för att senare ta fram dessa och på så sätt få kameran att återgå till en bestämd position. En mycket praktisk funktion. Dessvärre är den ganska kameraberoende varför den inte skall ses som en stående inslag i klientens funktionalitet.

3.7. Lite om Visual Basic

I den tekniska beskrivningen för Big Brother-klienten har samtliga av klientprogrammets delar beskrivits som klasser. Detta är dock inte sant även om det kategoriska användandet av

19

ordet klass tjänar det syftet att onödig förvirring för den oinitierade uteblir samtidigt som förståelsen för programmets funktionalitet, knappast blir lidande. För att tillgodose lystmätet hos puristen och den intresserade, bjuds här den faktiska indelningen av klientprogrammets delar samt en kort beskrivning av de olika kategorierna. Formulär Klasser Moduler CommandForm CommandHolder CommandHash ConnectForm GuiCommand GuiCommandGroupHash Joystick GuiCommandGroup HostList JoystickInfoForm JoystickStatus InputHandler mainWindow ParamType pc PositionEntry PositionHolder statComp Formulär: (eng. form) kan ses som en klass (se Klasser) som kan visas; är en container som

kan ha grafiska komponenter. Klasser: Kan ha metoder och attribut. Kan instantieras och skickas som argument till

metoder och funktioner. Moduler: En möjlighet att strukturera kod; likandne metoder och funktioner läggs i samma

modul. Metoder och funktioner som ligger i en modul är åtkomstbara från hela det övriga programmet (om inte annat sägs). Kan inte/behöver inte instansieras och kan inte heller skickas som argument till metoder och funktioner.