Home

Belegarbeit ( - 5.3 MB) - Technische Universität Dresden

1. Abbildung 2 1 Vereinfachte Darstellung der aktuellen Konfiguration am Baggersimulator kann jedoch nur getestet werden wenn diese auch auf derselben Maschine verfiigbar sind Um die Im plementierung neuer Komponenten m glichst einfach zu gestalten darf es aus deren Sicht also keinen Unterschied zwischen lokaler und verteilter Kommunikation geben Abbildung 2 2 zeigt u a den DirectInputMapper eine in C implementierte Eingabekomponente von Robert Biirger die mit Hilfe von DirectX verschiedenste Standardeingabeger te wie Tastaturen M use oder Joysticks in das Simulations und VR System integriert Um diese f r eine neue Anwendung nut zen zu k nnen muss der Entwickler lediglich die ben tigten Eingabekan le definieren indem er einer Taste einem Knopf oder einer Bewegungsachse eine Kanalnummer zuordnet und festlegt auf welchen Wertebereich die von der Hardware signalisierten Eingabeereignisse abgebildet werden sollen Mit Hilfe des DirectInputMappers der Visualisierung von Joscha Metze und einer generischen Simula tionskomponente die im Rahmen dieser Arbeit entstanden ist wurde eine Vielzahl neuer Anwendungs felder erschlossen In Kapitel 6 wird darauf n her eingegangen 2 2 SZENARIOANALYSE 9 Host Development Environment Host Development Environment Input DirectinputMapper Input1 DirectinputMapper
2. zu verwendende XML Schema bekannt ist Ein weiterer gro er Vorteil ist dass kein spezieller Interface Compiler wie z B bei CORBA ben tigt wird sondern ein Standard XSL Prozessor verwendet werden kann Aus lizenzrechtlichen Gr nden und um die Erweiterbarkeit zu gew hrleisten wurde von Stefan Spickereit trotzdem ein kompakter XSL Prozessor mit dem NET Framework entwickelt Dieser gene riert aus der Schnittstellenbeschreibung und den Transformationsregeln die in den XSLT Stylesheets festgelegt sind den entsprechenden Quellcode Die Implementierung der XSLT Stylesheets die in Kooperation mit Stefan Spickereit erfolgte orientierte sich an den bereits vorhandenen Stylesheets f r C von Jan St hmer Die neuen Datentypen 3 1 und Features erforderten jedoch eine Anpassung der Transformationsvorschriften Hier sind neben den M g lichkeiten zur Definition funktionsspezifischer Fehlerwerte und Timeouts vor allem die Threadsicherheit und die M glichkeit zum Abfangen von Nachrichten zu nennen Nachdem die XML Beschreibung der Schnittstelle in C oder C Code transformiert wurde m ssen daraus noch die entsprechenden dynamischen Bibliotheken kompiliert werden Um den Erstellungsprozess zu vereinfachen wurden Batch Dateien bzw Shell Scripts bereitgestellt die nur noch mit dem Namen der Schnittstelle als Parameter aufgerufen werden m ssen um die ge w nschten Dynamic Link Libraries zu erhalten Intern kommt dabei NAnt zum Ein
3. using NUnit Framework using odonet_cs namespace UnitTestingExamples TestFixture public class MessageTest private Message message SetUp public void Setup this message new Message lt summary gt This Test determines lt summary gt Test public void SerializeTest if a simple message can be serialized properly 43 will be the payload of the message this message Writelnt 43 this message SequenceNumber 7 4 bytes for length 4 bytes for message type 4 bytes for sequence number 4 bytes for the payload byte expected 16 0 0 0 0 0 0 0 7 0 0 0 43 0 0 0 byte result this message Serialize Assert AreEqual expected result 5 2 TESTWERKZEUGE 53 5 2 2 Zanebug Zanebug zan basiert auf NUnit und erweitert es ist jedoch ausschlie lich f r Windows verf gbar Neben einigen neuen Attributen fallen im Vergleich zu NUnit vor allem die wesentlich umfangreichere graphische Benutzerschnittstelle und Funktionen zur Performance Messung auf Die aktuelle Version 1 6 0 ist gr tenteils kompatibel mit NUnit in der Version 2 2 7 Zanebug ist ebenfalls Open Source Software und ist unter der Apache2 0 Lizenz verf gbar die der zlib libpng Lizenz sehr hnlich ist apa Mit den Attributen TestSetUp und TestTearDown ist es m glich testspezifische Setup und Tear Down Methoden TestSetUp TestTearDown anzugeben D
4. e Dienstgiitekriterien Dienstg tekriterien besser bekannt als Quality of Service QoS beschrei ben Kanaleigenschaften die der Anwendung von der Transportschicht zugesichert werden Neben oberen und unteren Grenzen f r die verschiedenen Performanzkriterien sollen auch minimal und maximal zul ssige Schwankungen vereinbart und garantiert werden k nnen Da verteilte Echtzeit anwendungen wenig tolerant gegen ber Schwankungen der Kanalqualit t sind w ren zugesicherte bertragungseigenschaften eine echte Bereicherung In der Praxis sind QoS f hige Netzwerke al lerdings noch selten Die beste L sung bieten ATM Netzwerke wobei die Hardware auf Grund mangelnder Verbreitung sehr teuer ist Einen Kompromiss k nnten die Ans tze Integrated Ser vices IntServ RFCc und Differentiated Services DiffServ RFCa die beide auf IP aufsetzen darstellen siehe auch Kap03 Zwar werden auch hier spezielle Router ben tigt diese k nnten jedoch auf Grund der hohen Marktdurchdringung von Ethernet in Zukunft g nstiger werden 2 4 Programmiermodell und Aufrufsemantik Zu den Aufgaben einer Middleware geh rt es die Heterogenit t der darunterliegenden Programmierspra chen Betriebssysteme Hardwarekomponenten und Netzwerke zu maskieren Dazu ist es notwendig ein einheitliches Programmiermodell zu definieren dessen Abstraktionsniveau den Erwartungen der Anwen dungsentwickler entspricht Verschiedene Modelle haben in der Praxis weite Verbrei
5. 2 2 SZENARIOANALYSE 7 Die Erfahrungen mit der bestehenden Implementierung haben gezeigt dass eine weitere Eigenschaft nicht fehlen darf e Verwaltbarkeit Konfigurationsmanagement eine globale Sicht auf alle Komponenten sowie eine zentrale Zustandskontrolle sind im allt glichen Betrieb unerl sslich 2 2 Szenarioanalyse In einem flexibel gestalteten verteilten Simulations und VR System sind zahlreiche Kombinationen der einzelnen Module denkbar Um die daraus entstehenden Anforderungen an die Netzwerkkommunikati onsschicht ableiten zu K nnen m ssen m glichst vielf ltige Szenarien betrachtet werden Dabei ist es sicherlich hilfreich von den konkreten bereits bekannten Konfigurationen auszugehen um diese dann um neue Systeme zu erweitern Zur Veranschaulichung sollen Diagramme verwendet werden die auf UML Verteilungs und Kompo nentendiagrammen basieren Die Quader beschreiben dabei einzelne Computer welche immer einen Namen haben Darin enthalten sind Komponenten eines bestimmten Typs bei denen der Name optional ist Die Pfeile stellen abstrakte gerichtete Kommunikationsbeziehungen dar 2 2 1 Baggersimulator Die momentane Konfiguration des Baggersimulators ist aus Diagramm 2 1 ersichtlich Das Herz dieses Systems ist die Simulation sie empf ngt die Eingabedaten wie Beschleunigung oder Lenkrichtung von der Baggerkabine CAB Modul Daraus und mit Hilfe der Terraininformation aus der Datenbank berechnet si
6. Der Aufruf von Socketfunktionen erfordert System Calls und ist deshalb teuer weshalb deren Anzahl minimiert werden sollte 38 4 IMPLEMENTIERUNG zuverl ssigen Kanal ausgetauscht wird ist die Implementierung jedoch wesentlich einfacher als bei den Datagramm orientierten Transporttypen 4 3 und 4 4 Von einem TCP Socket k nnen beliebig viele Bytes gelesen werden unabh ngig davon wie viele Bytes gesendet wurden Dagegen m ssen bei UDP Sockets immer genau so viele Bytes gelesen werden wie vorher auch gesendet wurden Ein TcpPeerHandle liest immer so viele Bytes wie m glich aus dem Puffer des assoziierten Sockets Danach wird die Nachrichtenl nge bestimmt und unterschieden ob f r die Zusammensetzung der Nach richt alle Bytes gelesen wurden ob noch Bytes fehlen oder ob mehr Bytes als n tig gelesen wurden Die Bytes die zur aktuell verarbeiteten Nachricht geh ren werden in den messageBuffer kopiert ber schiissige Bytes landen im overflowBuffer Falls nach dem ersten Aufruf der Receive Funktion des Sockets noch Bytes fehlen werden in einem weiteren Aufruf genau die Anzahl fehlender Bytes vom Socket gelesen und an den messageBuffer angeh ngt Wurde eine Nachricht vollst ndig empfan gen wird sie deserialisiert und ein Empfangsereignis ausgel st bei dem sie der ReceiveMessage Methode des Coordinators bergeben wird Danach beginnt der Prozess wieder von neuem wobei aber zun chst der overflowBuffer gele
7. gibt es die einfach zu verwendende Klasse ManualResetEvent die den Zugriff auf die verwen dete Bedingungsvariable kapselt und synchronisiert F r die Implementierung in C wurde daf r die verbreitete C Bibliothek SDL Simple DirectMedia Layer sdl verwendet Hier muss der Zugriff auf die Bedingungsvariable allerdings manuell ber einen Mutex synchronisiert werden Dazu wurde das einfache Struct WaitHandle definiert welches neben der Referenzen auf den Mutex und die Bedin gungsvariable die er sch tzen soll das Flag isLocked enth lt Dieses Flag ist notwendig damit ein Empfangsthread beim ausf hren der ReceiveMessage Methode des Coordinators erkennen kann ob noch auf die Antwortnachricht gewartet wird oder ob ein anderer Empfangsthread bereits den Eingang der Antwort gemeldet hat Ist dies nicht der Fall muss die Nachricht gel scht werden Ein weiterer Un terschied der SDL Bedingungsvariablen zum ManualResetEvent von NET ist dass der assoziierte Das Signal ginge dann verloren was je nach dem wie den Threads die Rechenzeit zugeteilt wird bei lokaler Kommunikation durchaus vorkommt 2 Alternativ h tte genauso gut die Pthreads Bibliothek verwendet werden k nnen 4 1 BERBLICK UND UNTERSCHIEDE DER IMPLEMENTIERUNGEN IN C UND C 35 Mutex nach dem Eintreffen eines Signals sofort wieder gesperrt wird Damit Empfangsthreads auch nach dem Eintreffen der ersten Antwort nicht f r immer blockieren muss de
8. lt returntype type double gt lt parameter type int name valueID gt lt message gt lt message name GetStringArray id 10 error error lt returntype type string gt lt parameter type int name valueID gt lt message gt lt message name SetByte id 11 error 0 gt lt returntype type int gt lt parameter type int name valueID gt lt parameter type byte name value gt lt message gt lt message name SetInt id 12 error 9999 gt lt returntype type int gt lt parameter type int name valueID gt lt parameter type int name value gt lt message gt lt message name SetFloat id 13 error 9999 gt lt returntype type int gt lt parameter type int name valueID gt lt parameter type float name value gt lt message gt lt message name SetDouble id 14 error 9999 gt lt returntype type int gt lt parameter type int name valueID gt lt parameter type double name value gt lt message gt lt message name SetString id 15 error error gt lt returntype type string gt lt parameter type int name valueID gt lt parameter type string name value gt lt message gt lt message name SetByteArray id 16 error 255 gt lt returntype type int gt lt parameter type int name valueID gt lt parameter type byte name value gt 99 9999 gt 9999 999
9. onsschicht Jeder Stub hat seinen eigenen Coordinator den er zum Senden von Nachrichten zum Emp fangen von Antworten oder f r den Aufruf von Callback Funktion benutzen Kann Handelt es sich dabei um einen Client ServerStub werden die SendMessage Aufrufe auf Aufrufe der SendMessage Methode des zugeh rigen NetworkClient abgebildet welcher die Nachricht an alle verbundenen Ser ver bertr gt Falls eine Antwort erwartet wird muss ein ServerStub unmittelbar nach dem Aufruf der SendMessage Methode die WaitForReturnMessage Methode des Coordinators aufrufen wel che die Anwortnachricht oder im Falle eines Timeouts null zur ckgibt Damit dieser Aufruf so lan ge blockiert bis entweder die Antwort eingetroffen ist oder das Timeout Intervall berschritten wurde wird beim Aufruf der SendMessage Methode eine Bedingungsvariable in den Zustand nicht signali siert nonsignaled versetzt Innerhalb der Wait ForReturnMessage Methode wird der aufrufende Thread an dieser Bedingungsvariable so lange schlafen gelegt bis ein Empfangsthread signalisiert dass die Nachricht eingetroffen ist oder die maximale Wartezeit berschritten wurde Das Sperren der Be dingungsvariable muss vor dem Senden der Nachricht geschehen damit es nicht passieren kann dass die Antwortnachricht eintrifft bevor WaitForReturnMessage aufgerufen wurde und die Bedin gungsvariable auf signalisiert signaled gesetzt wird ohne dass auf das Signal gewartet wird In C
10. Abschlie end soll anhand von Listing 4 1 gezeigt werden wie eine Minimalkonfiguration f r einen ControlCentreAnnouncer und einen passenden Cont rollerStub aussieht 4 6 Automatische Generierung benutzerdefinierter Bibliotheken Als Technologie f r die automatische Generierung benutzerdefinierter Stubs bietet sich XML zur Defini tion der gew nschten Funktionen 3 1 1 in Kombination mit XSL Transformationen zur automatischen Codegenerierung an Die Schnittstellenbeschreibungen lassen sich mit XML einfach erstellen und sind gut menschen und maschinenlesbar Viele XML Editoren bieten au erdem Eingabehilfen an sofern das Die Kommunikation zwischen Kontrollzentrum und Komponenten wird momentan ausschlie lich ber TCP unterst tzt 4 6 AUTOMATISCHE GENERIERUNG BENUTZERDEFINIERTER BIBLIOTHEKEN 43 Listing 4 1 Konfigurationsdatei f r ControlCentre Kommunikation lt xml version 1 0 encoding utf 8 gt lt configuration name controlcentre_configuration gt lt section id network gt lt object id ControlCentreAnnouncer type ControlCentreAnnouncer gt lt attr name autoconnectport gt 4000 lt attr gt lt object gt lt object id ControllerStubServer type ControllerStub gt lt attr name port gt 3000 lt attr gt lt object gt lt object id ControllerStubClient type ControllerStub gt lt attr name autoconnectport gt 4000 lt attr gt lt object gt lt section gt lt configuration gt
11. Dies ist bei der Konfiguration der Testsysteme zu ber cksichtigen Die Benutzerfreundlichkeit der Software und das zugeh rige Handbuch sollten am besten durch ein unabh ngiges Team getestet werden Die Entwickler neigen oft dazu betriebsblind zu werden und fehlerhaftes oder st rendes Verhalten zu bersehen Um auch Systemtests m glichst fr h durchf hren zu k nnen sollten schon vor dem Release noch unfer tige Versionen fixiert und zum Testen freigegeben werden 5 2 Testwerkzeuge Die Automatisierung von Testabl ufen ist ein m hsames Unterfangen wenn geeignete Werkzeuge feh len Zun chst muss eine Testumgebung bereitgestellt werden Dazu geh ren Testdaten Betriebssystemres sourcen und im Kontext von Systemtests auch die Hardwareumgebung Soll ein Test h ufig wiederholt werden kann die automatisierte Initialisierung der Testumgebung Zeit sparen und Fehler vermeiden Um die Tests auszuf hren kann eine eigens daf r geschriebene Testapplikation eine Script Sprache oder ein Testframework zum Einsatz kommen Nach der Ausf hrung m ssen die Ergebnisse ausgewertet und protokolliert werden k nnen Bei Programmen die eine Datenbank verwenden muss auch von au erhalb des zu testenden Programms darauf zugegriffen werden k nnen Um verteilte Systeme zu testen ben tigt man m glicherweise Werkzeuge die den Netzwerkverkehr mitschneiden oder sogar manipulieren k n nen Sollen Tests automatisiert werden die eine Anwendung
12. ISO RPC ISO IEC CD 11578 N6561 kann als gescheitert betrachtet werden Da C jedoch nur von der kommerziellen Implementierung der Distinct Corporation unterst tzt wird propriet re Software aber weitgehend vermieden werden soll ist diese L sung nicht optimal Bei den weitergehenden objektorientierten Ans tzen kommunizieren nicht mehr Clientprozesse mit Ser verprozessen sondern Objekte im Adressraum eines Clients mit Objekten im Adressraum eines Servers Der einfachste Vertreter dieser Kategorie ist Java RMI Remote Method Invocation rmi universeller ist der von der OMG vorgestellte Standard CORBA Common Object Request Broker cor Die damit ein hergehende Vereinfachung des Programmiermodells wird allerdings mit einem hohem Performanzverlust erkauft Diese L sungen sind schon alleine deshalb f r die verteilte Echtzeitsimulation unbrauchbar Daneben gibt es noch Message Queue Systeme manchmal auch Message Passing Systeme genannt Hier werden Nachrichten von einer Warteschlange auf Clientseite zu einer Warteschlange auf Serverseite bertragen Neben vielen kommerziellen Implementierungen gibt es eine Vielzahl an freien Alternativen Diese Systeme wurden f r die asynchrone Daten bertragung in Umgebungen mit eingeschr nkter Kon nektivit t entwickelt weshalb synchrone Aufrufmechanismen fehlen Zusammenfassend l sst sich feststellen dass ein RPC System die Anforderungen an die Netzwerkkom munikationsschicht am besten erf l
13. Michael LACOSTE Jerome LEPILLEUR Baptiste BAKKER Bastiaan ROBBINS Steve CppUnit Wiki http cppunit sourceforge net cppunit wiki FrontPage SUBBIAH Palani Die Bitfehlerrate hinterfragt http www elektroniknet de index php id 1123 72 Literaturverzeichnis Tan96 tesa tesb TPCF vis zan zli TANENBAUM Andrew S Computer networks 3 Prentice Hall Europe 1996 ISBN 0 13 394248 1 MUTANT DESIGN LIMITED Hrsg TestDriven NET http www testdriven net MUTANT DESIGN LIMITED Hrsg TestDriven NET Software License Terms http www testdriven net purchase_licenses aspx Two Michael C POOLE Charlie CANSDALE Jamie FELDMAN Gary NUnit http www nunit org MICROSOFT Hrsg Visual Studio Team System http msdn microsoft com vstudio teamsystem default aspx ADAPDEV TECHNOLOGIES Hrsg Adapdev Technologies LLC Zanebug http www adapdev com zanebug OPEN SOURCE INITIATIVE Hrsg The zlib libpng License http www opensource org licenses zlib license html 73 A Listings Listing A 1 Beispiel einer Netzwerkkonfiguration lt xml version 1 0 encoding iso 8859 1 gt lt configuration name SimpleStubTestConfiguration xmlns xsi http www w3 org 2001 XMLSchema instance xsi noNamespaceSchemalocation odoconfig xsd gt lt section id network gt lt object id SimpleClientStubTcp type ClientStub gt l
14. name valueID gt lt parameter type int name value gt lt message gt lt for this method Int32 MinValue is chosen to indicate an error gt lt message name GetInt id 2 error 0x80000000 gt lt returntype type int gt lt parameter type int name valueID gt lt message gt lt message name SetIntArray id 3 gt lt returntype type void gt lt parameter type int name valueID gt lt parameter type int name value gt lt message gt lt the timeout in ms is optional default is according to stub configuration gt lt 01010 describes a three dimensional array filled with zeros gt lt in this case it is an integer array as specified by the element returntype gt lt message name GetIntArray id 4 timeout 1000 error 0 0 0 gt lt returntype type int gt lt parameter type int name valueID gt lt message gt lt messagetable gt std string Die zugeh rigen Arraydatentypen sind unter C jetzt immer als getypte Vektoren std vector realisiert Neu ist die M glichkeit String Arrays zu bertragen und dass jeder Funk tion ein individueller Timeout und Fehlerr ckgabewert zugewiesen werden kann Alle unterst tzten Datentypen sind in Tabelle 3 1 zusammengefasst An dieser Stelle sei au erdem noch auf die XData Klasse der Lore Bibliothek hingewiesen die neben impliziten Typkonvertierungen zwischen vielen primitiven Datenty
15. rige Nach richt verloren ging oder ihre Interpretation und Ausf hrung auf Serverseite noch nicht abgeschlossen ist Um zwischen fehlenden Werten und Zeit berschreitungen unterscheiden zu k nnen werden verschiede ne Fehlerwerte verwendet Daneben gibt es Tests die gro e Nachrichten versenden um das Verhalten gt Wenn die Anfragen auf Serverseite nicht in der Reihenfolge abgearbeitet werden in der sie ankommen muss das nat rlich als Bug angesehen werden W hrend der Implementierung der Netzwerkschicht ist aber genau dieser Fehler aufgetreten weshalb f r diesen Fall die Tests erweitert werden mussten 5 5 TESTERGEBNISSE 63 der NetworkPeers zu untersuchen wenn die Nachrichtengr e die Puffergr e der Sockets bersteigt Um zu testen ob bei einer Zeit berschreitung auch wirklich der festgelegte Fehlerwert zur ckgegeben wird sendet der Client eine Anfrage an den Server welcher in diesem Fall aber erst nach Ablauf des Timeout Intervalls antwortet so dass beim Client der Fehlerwert erwartet werden kann Neben diesen Basistests wurde ebenfalls gepr ft ob auch bei einer gro en Zahl von Clients der Abbau der Verbindun gen und das Freigeben der Ressourcen problemlos von statten geht Mit Zanebug wurde das Verhalten der NetworkPeers unter Stress getestet indem die einzelnen Tests sehr oft wiederholt wurden Bei der Implementierung der Testf lle wurden zun chst f r jeden Transporttyp eigene Testklassen ver wendet u
16. sch ftslogik und von dort zur Datenhaltung oder in die umgekehrte Richtung ein Bottom Up Ansatz als g nstiger erweisen Bei einer mehrschichtigen Architektur kann es vorteilhaft sein sich von den inneren Schichten nach oben und unten vorzuarbeiten Middle Out Im einzelnen m ssen Integrationstests die Korrektheit von Transaktionen ber mehrere Programmeinhei ten das Zusammenspiel der verschiedenen Schichten und die richtige Reaktion auf Ereignisse Events sicherstellen Integrationstests sollten so bald wie m glich durchgef hrt werden um Schw chen im Ent wurf fr hzeitig aufzudecken 5 1 3 Systemtests Systemtests sind die letzten Tests vor den Abnahmetests mit dem Kunden Sie sollen sicherstellen dass das Gesamtsystem alle Anforderungen zufriedenstellend erf llt Der Systemtest berpr ft ob die ge w nschte Funktionalit t vollst ndig umgesetzt ist wie leistungsf hig das System bei hoher Belastung ist ob Sicherheitsaspekte ausreichend ber cksichtigt wurden und wie gut das System in verschiedenen Umgebungen funktioniert Daneben betrifft der Systemtest auch implizite Anforderungen also Anfor derungen die es nicht ins Pflichtenheft geschafft haben vom Kunden aber erwartet werden Neben der Benutzerfreundlichkeit muss au erdem noch das Benutzerhandbuch berpr ft werden Systemtests stellen also im wesentlichen die Vollst ndigkeit der Umsetzung der Anforderungen sicher F r einen Systemtest gelten Anforderungen a
17. 2 TCP 37 gesetzt werden das einen ClientStub dazu veranlasst seinen Dienst ber einen periodischen Broadcast auf dem autoconnectPort anzuk ndigen Alle ServerStubs die genauso konfiguriert sind verbinden sich dann nach ihrem Start automatisch mit diesem ClientStub Der Dienst eines TcpNetworkServers wird wie bei allen NetworkServern immer mit der Deploy Service Methode gestartet Darin wird eine Liste f r die Verbindungen angelegt und ein Socket Accept Socket erstellt der an dem Netzwerkinterface das in der Konfiguration angegeben wur de auf Verbindungsversuche der Clients warten soll Wird kein lokaler Name angegeben oder wird das angegebene Netzwerkinterface nicht gefunden wird der Socket an das erste Netzwerkinterface gebunden Die Annahme neuer Verbindungen geschieht mit Hilfe eines daf r erzeugten Threads der die Accept Thread Methode ausf hrt Dabei blockiert dieser Thread innerhalb einer Schleife an der Accept Methode des Accept Sockets bis eine neue Verbindung aufgebaut wurde Ist der Aufruf von Accept erfolgreich liefert er einen neuen Socket zur ck der mit dem Client verbunden ist Damit von diesem Socket Daten empfangen werden k nnen wird ein neuer Thread erzeugt der daf r zust ndig ist an diesem Socket auf ankommende Daten zu warten Receive Thread F r den sp teren Zugriff auf den Socket und den Thread werden sie einem neuen TcpPeerHandle zugewiesen welches somit als Repr sentant f r
18. A lokaler Aufruf R ckgabewert lokaler Aufruf R ckgabewert Y Y ServerStub ClientStub A A Marshalling Unmarshalli Unmarshalling Marshalling Y Y ODONet ODONet A A Serialisierung Deserialisierung Deserialisierung Serialisierung Y Y Transportschicht Transportschicht Abbildung 3 2 Client Server Architektur Um zuk nftigen Missverst ndnissen vorzubeugen K nnen nur ServerStubs also Objekte auf Clientseite einen Kommunikationsvorgang initiieren wohingegen ClientStubs ausschlie lich Antwortnachrichten verschicken k nnen Au erdem kann ein Server nur noch einen Dienst anbieten Soll eine Anwendung mehrere Dienste be reitstellen muss pro Dienst ein ClientStub instanziiert werden Dadurch steigt zwar der Speicherbedarf ein wenig die Komplexit t der Netzwerkbibliothek wird allerdings reduziert so dass eine Leistungsstei gerung m glich ist 3 1 3 Konfiguration Um die einzelnen Module m glichst einfach zu neuen verteilten Anwendungen verkn pfen zu k nnen m ssen sie flexibel konfigurierbar sein Neben der physikalischen Verteilung und den Verbindungseigen schaften gibt es anwendungsabh ngig weitere Parameter die eingestellt werden k nnen sollen Die Konfiguration der Kommunikationsendpunkte geschieht anders als beim RPC ber XML Dateien Beim RPC kommen ein Verzeichnisdienst Directory Service und pro Host e
19. Bestimmte Mechanismen wie z B der Aufbau einer Pseudoverbindung zur Kommunikation ber UDP oder die Serialisierung von Nachrichten zu Byte Arrays m ssten in C mehr oder weniger aufw ndig nachimplementiert werden Bei der ersten Version der Netzwerkbibliothek wurde die HawKNL haupts chlich verwendet weil sie eine einheitliche Programmierschnittstelle zu den Sockets unter Windows und Linux bereitstellt Auf Grund zahlreicher Einschr nkungen und der fehlenden Unterst tzung f r C wird diese Bibliothek bei der Neuimplemen tierung nicht mehr verwendet Weil bei der Verwendung externer Bibliotheken aber generell das Problem besteht dass bestimmte m glicherweise dringend ben tigte Funktionen nicht zur Verf gung stehen und Anpassungen an die eigenen Anforderungen meist mit sehr hohem Aufwand verbunden sind wird bei der Neuimplementierung direkt mit Sockets gearbeitet Wie die Grundstruktur des Entwurfs umgesetzt wurde und wie sich die Implementierung in C von der in C unterscheidet wird in Abschnitt 4 1 erl utert Alle weiteren Abschnitte dieses Kapitels besch fti gen sich mit den Aspekten der Implementierung die einer zus tzlichen Dokumentation bed rfen weil 34 4 IMPLEMENTIERUNG sich wichtige Zusammenh nge nicht unmittelbar aus dem Quellcode ablesen lassen 4 1 berblick und Unterschiede der Implementierungen in C und C Wie schon in 3 3 beschrieben ist der Coordinator die zentrale Klasse der Netzwerkkommunikati
20. Can CDKO1 cor Fea Fow haw How OPEN SOURCE INITIATIVE Hrsg Apache License Version 2 0 http www opensource org licenses apache2 0 php BEUST C dric Why unit tests are disappearing http beust com weblog archives 000319 html CATALYST DEVELOPMENT Hrsg Introduction to TCP IP Blocking vs Non Blocking Sockets http www developerfusion co uk show 28 8 OPEN SOURCE INITIATIVE Hrsg The BSD License http www opensource org licenses bsd license php CANSDALE Jamie Zero Friction Unit Testing for Visual Studio NET http weblogs asp net nunitaddin COULOURIS George DOLLIMORE Jean KINDBERG Tim Distributed Systems Con cepts and Design 3 Addison Wesley 2001 ISBN 0 201 61918 0 OBJECT MANAGEMENT GROUP Hrsg CORBA http www corba org FEATHERS Michael A Set of Unit Testing Rules http www artima com weblogs viewpost jsp thread 126923 FOWLER Martin Mocks aren t Stubs http www martinfowler com articles mocksArentStubs html HAWK SOFTWARE Hrsg HawkNL Hawk Network Library http www hawksoft com hawknl HOWER Chad Z Introduction to Indy http www swissdelphicenter ch en showarticle php id 4 70 Literaturverzeichnis iee98 Kap03 KBP01 gp lib McC Met05 MSD06 nco New NMW05 IEEE Standard for Distributed Interactive Simulation Application Protocols The Insti
21. Coordinator die Nachrichten lediglich an den ClientStub weiter der dann 32 3 ENTWURF den passenden Eventhandler aufruft und dessen R ckgabewert in eine Antwortnachricht verpackt die wiederum vom Coordinator zur ckgesendet wird Die Zuordnung welche Antwort zu welcher Nachricht geh rt geschieht mit Hilfe von Laufnummern Eine Antwortnachricht hat stets die selbe Laufnummer wie die Nachricht der urspr nglichen Anfrage W nschenswert w re es auch dass mehrere Threads gleichzeitig Stubfunktionen aufrufen k nnen um so die Antwortzeiten zu verk rzen Der Coordinator eines Clients m sste dann eine synchronisierte Warte schlange f r die Antwortnachrichten verwalten und alle Funktionen m ssten threadsicher implementiert werden Wie in 2 4 schon festgestellt muss die Abarbeitung der Anfragen auf Serverseite aber sehr schnell geschehen so dass auch daf r mehrere Threads verwendet werden m ssten Weil dadurch aber an vielen Stellen Betriebssystemsperren Mutexe oder Locks eingesetzt werden m ssten und die M g lichkeiten zur Parallelisierung der Kommunkikation ber ein einzelnes Socket ohnehin eingeschr nkt sind erscheint es sinnvoller gleich mehrere Stubs an Stelle mehrerer Threads zu verwenden Dadurch wird die Konfiguration zwar aufw ndiger und es wird auch mehr Speicher belegt die Leistungsf higkeit d rfte bei dieser L sung jedoch deutlich besser sein Der Einsatz von Sperren ist teuer weil daf r zwischen Kerne
22. Leistungssteigerung erm glicht es physikalisches Verhalten in Echtzeit zu berechnen und somit neuartige Spielkonzepte umzusetzen Ab bildung 2 5 Ein Beispiel wird in Kapitel 7 gezeigt 2 3 Abgeleitete Anforderungen an die Kommunikationsschicht Aus der Szenarioanalyse lassen sich mehr oder weniger offensichtliche Anforderungen an die Nachrich ten bermittlung ableiten e Performanz Um zu kl ren welche Aspekte der Leistungsf higkeit der Netzwerkschicht f r das Die Begriffsdefinitionen wurden gr tenteils aus CDK01 entnommen und bersetzt Andere Autoren verwenden z T ab weichende Definitionen 12 2 ANFORDERUNGSANALYSE Host Player1 Host Player2 I I Input1 DirecilnputMapper Input2 DirectInputMapper InputPlayer1 InputPlayer2 Host Galyeserver Simulation DataManipulation DataRetrieval Database 4 VisualisationParameters SoundParameters Host Output1 Host Oupua N Visualisation1 Visualisation Visualisation2 Visualisation gt Sound1 Sound Sound2 Sound gt Abbildung 2 5 Multiplayer Spiel mit Echtzeit Physiksimulation Simulations und VR System von besonderer Bedeutung sin
23. Netzwerkbibliothek in C und in C implementiert und getestet werden muss erscheint der zu s tzliche Aufwand f r das Testen in Isolation recht hoch Zus tzlich zur Einarbeitungszeit in Mocking Frameworks f r C und C kommt noch hinzu dass Mono noch nicht voll kompatibel zu Microsofts NET 2 0 ist Der Einsatz einer Mocking L sung f r C unter Linux k nnte dadurch erheblich erschwert werden Insgesamt erscheint es also sinnvoller nur solche Klassen isoliert zu testen bei denen das ohne gr ere nderungen am Programmcode und ohne Mock Objekte oder Netzwerkemulation m glich ist Die Fehlerfreiheit soll also im Wesentlichen mit Systemtests sichergestellt werden was zwar einerseits die Fehlerlokalisierung erschwert auf der anderen Seite den Aufwand f r das Testen der Netzwerkbi bliothek aber erheblich reduziert Die einzelnen Testf lle K nnen aus der Anforderungsanalyse abgeleitet werden Es ist also zu pr fen ob die Verbindungen wie gew nscht aufgebaut werden ob alle unterst tz ten Datentypen 3 1 1 fehlerfrei von den verschiedenen Transporttypen 3 2 1 bertragen werden und ob Nachrichten auf entsprechende Funktionsaufrufe abgebildet werden welche im Falle einer Zeit ber schreitung den festgelegten Fehlerwert zur ckliefern 3 1 1 Dabei muss auch das Verhalten bei gr e ren Nachrichten untersucht werden Au erdem ist in jedem Fall noch zu pr fen ob die Kommunikation zwischen den Instanzen und dem Kontrollzentrum reibu
24. Sektionen k nnen verwendet werden um z B die Netzwerkkonfiguration von der Konfiguration der Kameras einer Visualisierung zu trennen Den Zugriff auf die Konfigurationsdateien erm glicht die Klasse Configuration im Namensraum Util der Lore Bibliothek Nach der Instanziierung dieser Klasse mit dem Pfad zur Konfigurationsdatei als Konstruktorparameter k nnen einzelne Konfigurationsobjekte Klasse ConfigObject anhand ihres Namens abgefragt werden Alternativ k nnen alle Konfigurationsobjekte die bestimmten Bedingungen bez glich Sektion Typ oder Name gen gen ausgew hlt werden Danach m ssen die Konfigurationsob jekte noch auf selbstdefinierte Klassen abgebildet werden wobei f r alle attrib Elemente der Kon figurationsdatei eine ffentliche Variable mit dem selben Namen gesucht wird die dann den Wert aus der Datei zugewiesen bekommt Mit Hilfe der Klasse Configuration ist es nun auch m glich neue Konfigurationsdateien anzulegen Ver nderungen an bestehenden Konfigurationen zu speichern oder ver schiedene Konfigurationsdateien zusammenzuf hren Damit ist es nun u a m glich die physikalische Verteilung der Module aus einer Anwendung heraus festzulegen F r die Konfiguration der Stubs wurde die Klasse NetworkConfigEntry entworfen die Variablen f r alle relevanten Netzwerkparameter enth lt Die Werte dieser Variablen werden aus dem entspre chenden Konfigurationsobjekt bernommen Neben dem immer ben tigten Verbindungstyp
25. Virtual Reality environments In Proceedings of Virtual Environments Eurographics ACM 2005 Literaturverzeichnis 71 Pac02 R 04 RFCa rfcb RFCc rfcd rfce rfcf rmi RS sdi SFL Sub Packeteer Inc Packeteer Technical White Paper Series Response Time Technology May 2002 R TZMANN Manfred Software Testing amp Internationalisierung 2 Galileo Computing 2004 ISBN 3 89842 539 8 IETF Hrsg An Architecture for Differentiated Services http www ietf org rfc rfc2475 txt IETF Hrsg Binding Protocols for ONC RPC Version 2 http www ietf org rfc rfcl833 txt IETF Hrsg Integrated Services in the Internet Architecture an Overview http www ietf org rfc rfcl633 txt IETF Hrsg RPC Remote Procedure Call Protocol Specification Version 2 Memo http www ietf org rfc rfcl057 txt IETF Hrsg RPC Remote Procedure Call Protocol Specification Version 2 Standards Track http www ietf org rfc rfcl831 txt IETF Hrsg TCP Congestion Control http www ietf org rfc rfc2581 txt SUN MICROSYSTEMS Hrsg Java Remote Method Invocation http java sun com products jdk rmi R HRL Martin SCHMIEDL Stefan Ich habe Tests also kann ich http www dotnet magazin de itr online_artikel psecom id 252 nodeid 31 html SDL PROJECT Hrsg Simple DirectMedia Layer http www libsdl org index php SOMMERLADE Eric FEATHERS
26. Wertgleichheit Equality AreEqual AreNotEqual zahlreiche berladungen f r den Ver gleich von primitiven Werten oder Objek ten Referenzgleichheit Identity AreSame AreNotSame Con Contains berpr ft ob eine Liste ein best tains Objekt enth lt Vergleich Comparison Greater Less Vergleich von primitiven Werte oder Ob jekten die IComparable implementieren Typ Type InstanceOf NotInstanceOf Bedingung Condition IsTrue IsFalse IsNull Hilfsmethoden Utility Fail Ignore Fail l sst einen Test fehlschlagen und kann dazu benutzt werden eigene Assertion Methoden zu schreiben Mit Ignore kann ein Test zur Laufzeit ignoriert werden Tabelle B 1 NUnit Assertions Auszug 90 ANHANGB TABELLEN Attribut Funktion TestFixture Markiert eine Testklasse als solche Test Markiert eine Testmethode als solche SetUp Markiert eine Methode die vor jedem Test aufgerufen werden soll pro TestFixture nur einmal erlaubt TearDown Markiert eine Methode die nach jedem Test aufgerufen werden soll pro TestFixture nur einmal erlaubt TestFixtureSetUp Markiert eine Methode die vor dem ersten Test einer Testklasse aufgeru fen werden soll pro TestFixture nur einmal erlaubt TestFixtureTearDown Markiert eine Methode die nach dem letzten Test einer Testklasse aufge rufen werden soll pro TestFixture nur einmal erlaubt ExpectedExcept
27. Zanebug eine ideale Infrastruktur um die Leistungsf higkeit einzelner Systemteile zu untersuchen Der integrierte Performance Monitor erlaubt es eine Vielzahl an Leistungsmerkmalen zu berwachen Neben den typischen Metriken zum Speicherverbrauch CPU Last oder Netzwerkauslastung lassen sich z B detaillierte Statistiken zur CLR Common Language Runti me den wichtigsten Netzwerkprotokollen und wichtigen Betriebssystemdiensten anzeigen Abbildung 5 2 zeigt eine kleine Auswahl von TCP Metriken nach der Ausf hrung einiger Tests Wie der Autor Sean McCormack in einem Artikel ber die Entwicklung dieses Testwerkzeugs schreibt siehe McC stellte das NET Konzept der Anwendungsdom nen AppDomains die gr te Heraus forderung bei der Realisierung von Zanebug dar Anwendungsdom nen sind isolierte Umgebungen in 54 5 AUTOMATISIERTES TESTEN Eizanebug 1 6 0 0 http www adapdev com File Mode Test Options Reports Help About lol x 212 212 Nannaa Percent Passed Stop J Runon build m Assembly Iteration Fixture Iteration M Test Iteration n mmm wun Pe Summary Formatted Results All Failed Passed Ignored Console Console Error Debug Trace Assemblies Perfmon Test Log Controls Columns FUHMO Line Thickness Rows Load Counters Refresh Display 2 v 4 hs fi Wi fi sec v Ro pts y O RSVP Dienst N O RSVP Schnittstellen O Server O Serverwarteschlangen O Spei
28. default timeout value The result must be the value defined in SimpleInterface xml 9999 signaling a timeout lt summary gt Test public void TimeoutTest this timeoutEventDelegate new SimpleClientStub SetIntEventDelegate clientStubTestHelper clientStub_TimeoutEvent i this clientStub SetIntEvent this setIntEventDelegate this clientStub SetIntEvent this timeoutEventDelegate int expected 1 int result serverStub SetInt expected 0 Assert AreEqual expected result result serverStub SetInt expected 500 Assert AreEqual 9999 result Test public void SetAndGetIntTest this clientStub SetIntEvent this timeoutEventDelegate this clientStub SetIntEvent this setIntEventDelegate int valueID serverStubTestHelper CreateRandomInt int expected serverStubTestHelper CreateRandomInt Assert AreEqual 0 serverStub SetInt valueID expected int result serverStub GetInt valuelID Assert AreEqual expected result Test public void SetAndGetStringArrayTest int valueID serverStubTestHelper CreateRandomInt string expected serverStubTestHelper CreateRandomStringArray Assert AreEqual OK serverStub SetStringArray valueID expected string result serverStub GetStringArray valueID Assert AreEqual expected result 88 ANHANG A LISTINGS 89 B Tabellen Art der Zusicherung Methoden Bemerkung
29. der typsichere Funktionszeiger auf eine einfache Art und Weise realisiert werden k nnen Angelehnt an die Syntax dieser Bibliothek wird bei der automatischen Generierung der spezialisier ten Stubs f r jede ben tigte Callback Funktion eine Methode der Form Connect lt Name der Funkti on gt Slot lt Name der Funktion gt Slot slot erzeugt die den bergebenen sigc slot mit dem zugeh rigen sigc signal verbindet Der zu bergebende Slot kann vom Anwender durch einen Aufruf der Funktion sigc mem fun erzeugt werden der die ausf hrende Instanz und ein Zeiger auf eine Methode dieser Instanz bergeben werden muss Um die Implementierung der verschiedenen NetworkPeers siehe 4 2 4 3 und 4 4 in C zu ver einfachen und m glichst nahe an der C Implementierung zu bleiben wurden manche NET Klassen in C nachimplementiert Die C Versionen dieser Klassen MemoryStream BinaryReader BinaryWriter und Bitconverter sind jedoch nicht vollst ndig weil nur die wirklich ben tig ten Funktionen umgesetzt wurden um den zus tzlichen Aufwand m glichst gering zu halten Weiterhin wurde die Klasse Socket definiert die als H llklasse f r den Zugriff auf die vom Betriebssystem be Dieses Verhalten entspricht dem AutoResetEvent von NET processIncomingMessage wird auch auf Clientseite aufgerufen Dort spielt das aber nur eine Rolle wenn Nachrichten durch ein InterceptMessageDelegate abgefangen werden sollen Beim Empfang einer Nach
30. in der Implementierung Sicherheitsaspekte nicht ber cksichtigt eher f r LAN als f r WAN geeignet 7 keine Socketpuffergr en einstellbar mit angepassten Puffern w re Leistungssteigerung m g lich 3 2 1 unn tige Konvertierung von Host Byte Order in Network Byte Order und zur ck 3 2 2 keine Auswahl unter mehreren Netzwerkkarten m glich kein spezifisches Bind 4 2 UDP Implementierung nur f r kleine Nachrichten geeignet zudem unvorhersagbares Ver halten bei Puffer berlauf 4 3 weiterhin wird nach jeder gesendeten Nachricht auf eine Empfangsbest tigung gewartet und die Nachricht bei Ausbleiben derselben wiederholt hohe Latenz obwohl gerade die UDP Kommunikation kurze Verz gerungen bieten soll 2 5 EVALUATION DER BESTEHENDEN NETZWERKKOMMUNIKATIONSSCHICHT 17 Teile der Implementierung haben sich als berfl ssig herausgestellt je ein Socket zum Senden bzw Empfangen CRC f r alle Nachrichten berfl ssig da bereits in TCP und UDP realisiert urspr nglich mehrere verschiedene Dienste pro Peer angedacht aber unvollst ndige Umset zung Feature nicht nutzbar aber Codekomplexit t erh ht 18 2 ANFORDERUNGSANALYSE 19 3 Entwurf Die Anforderungsanalyse die Evaluation der bestehenden Netzwerkbibliothek und die Erfahrungen in der Praxis haben gezeigt dass beim urspr nglichen Entwurf wichtige Aspekte nicht beachtet wurden und die Implementierung an vielen Stellen verbessert werde
31. ist also z B bei der Projektion einer bewegten Szene in eine f nfwandige CAVE f r die zehn Visualisierungsinstanzen ben tigt werden ist dieser Ansatz aber unzureichend Bessere L sungen versprechen Multicasting 1 n oder Broadcasting 1 all Beide Technologien erlauben das gleichzeitige Versenden von Nachrich ten an mehrere Empf nger Multicasting w re w nschenswert weil Nachrichten damit exklusiv an eine festgelegte Gruppe von Empf ngern gesendet werden k nnen Eine Broadcast Nachricht hingegen muss zun chst von allen Knoten eines Subnetzes akzeptiert werden damit diese ent scheiden k nnen ob sie die Nachricht verarbeiten sollen oder nicht Der effizienteren Ausnutzung der Bandbreite beim Multicasting steht allerdings die geringere Verf gbarkeit der ben tigten Netz werkhardware gegen ber e Gleichlaufschwankungen Jitter Bezogen auf Netzwerke ist mit Jitter die Varianz der Latenz oder der Daten bertragungsrate gemeint Da der reibungslose Betrieb eines VR Systems harte Echt zeitanforderungen stellt machen sich Gleichlaufschwankungen leicht bemerkbar Dieses Problem kommt am deutlichsten bei der Verarbeitung von Eingaben zu tragen Das liegt zum einen daran dass Eingabenachrichten unter Umst nden nicht verworfen werden k nnen diskrete Ereignisse 14 2 ANFORDERUNGSANALYSE wie z B Mouseclicks k nnten sonst unregistriert bleiben zum anderen wirken variable Verz ge rungen bei der Steuerung besonders st rend
32. name servernames gt 141 76 71 139 lt attr gt lt attr name port gt 3000 lt attr gt lt object gt lt section gt lt configuration gt 3 2 Schnittstelle zur Transportschicht Bisher gab es keine klar definierte Schnittstelle zur Transportschicht Die Klasse NetworkPeer ver sendete die Nachrichten je nach aktueller Konfiguration ber TCP UDP oder Broadcast Durch die dazu notwendigen Fallunterscheidungen wurden die Funktionen zum Senden und Empfangen sehr gro und damit schwer les und erweiterbar Auch der Code f r die Initialisierung und die Zerst rung eines Net workPeers wurde dadurch sehr un bersichtlich Um die Erweiterbarkeit hinsichtlich verschiedener Protokolle und Netzwerktechnologien zu verbessern wurde eine Schnittstelle definiert die eine geeignete Abstraktion zur darunterliegenden Transportschicht bieten soll Abbildung 3 3 In der folgenden Beschreibung werden der Einfachheit halber nur die Be zeichnungen f r C verwendet die quivalenten Umsetzungen der Interfaces durch abstrakte Klassen in C hei en genauso wobei an Stelle des I f r Interface ein Abstract vorangestellt wird Als Basis f r alle Klassen die den Zugriff auf das Netzwerk erm glichen sollen wurde das Interface INetworkPeer definiert Ein NetworkPeer muss lediglich Ereignisse ber empfangene Nachrichten 2Mit Peers sind in diesem Zusammenhang keine gleichberechtigten Kommunikationspartner gemeint Der Begriff soll f
33. neuer Module wurde begleitend zu dieser Arbeit ein einfaches Simulationsframe work geschaffen mit dem ohne gro en Aufwand neue Anwendungen erstellt werden k nnen Mit dem DirectInputMapper von Robert B rger als Eingabekomponente der Visualisierung von Joscha Metze als Ausgabekomponente und einer generischen Simulationsanwendung dazwischen kann sich der Entwick ler ganz auf die Programmierung seiner Simulation beschr nken Neue Simulationen implementieren dazu das Interface ISimulationPlugin das die zwei Methoden InputChanged und DoStep definiert Beide Methoden werden vom Framework aufgerufen wobei InputChanged die neuen Ein gaben bergeben bekommt und in DoStep genau ein diskreter Simulationsschritt implementiert werden soll Unmittelbar nach jedem Aufruf von DoStep wird das Ergebnis an die Visualisierung bertragen Als DLL erstellt k nnen die Simulationsplugins dann von der Simulationsanwendung GenericSimu Die Benutzung w rde erschwert die Performanz w rde verringert und die Implementierung w re aufw ndig und fehleran f llig Beim Point to Point Tunneling Protocol kann es je nach Konfiguration Probleme mit dem Broadcasting geben IPSec hinge gen ist in der Konfiguration recht aufw ndig 68 7 AUSBLICK lation exe geladen und ausgef hrt werden Eine erste Verwendung fand dieses Framework bei einer Praktikumsarbeit zur Vorlesung VR und Simulation von Prof Dr Markus Wacker an der HTW Dres den Ab
34. oder die eigent liche Simulation auf mehrere Rechner verteilt neueste Technologien schnell integriert und heterogene Systeme vereint werden Die eigens daf r entwickelte Netzwerkkommunikationsschicht bietet dem An wendungsentwickler spezialisierte Schnittstellen die er nur in einer XML basierten IDL Interface De finition Language zu beschreiben braucht um daraus mit einer XSL Transformation automatisch den passenden C Code zu erzeugen Umfassende Ideen zur Erweiterung des Systems bedingen jedoch eine Evaluation und Erweiterung dieser Netzwerkkommunikationsschicht Zus tzlich zur Plattformunabh ngigkeit Windows Linux soll durch die Integration von C auch eine gewisse Unabh ngigkeit von der Programmiersprache erreicht werden Bei dieser Gelegenheit ist zu untersuchen ob die momentane Definition der Schnittstelle alle aktuell ben tigten Funktionen anbietet und inwieweit die bestehende Implementierung vereinfacht oder verbes 4 1 EINLEITUNG sert werden kann Um die Korrektheit der Implementierung weitgehend sicherzustellen soll untersucht werden welche Werkzeuge und Strategien f r das automatisierte Testen der Netzwerkschicht geeignet sind 2 Anforderungsanalyse Das verteilte Kommunikations und Visualisierungssystem ODO ist mittlerweile zu einem umfangrei chen Framework f r VR Simulationen herangewachsen Um die Entwicklung neuer Komponenten zu vereinfachen und damit zu beschleunigen soll den am Projekt beteili
35. r beliebige Kommunikationsteilnehmer stehen egal ob sie die Client oder die Serverrollen einnehmen 26 3 ENTWURF INetworkPeer ES Interface IDisposable Properties OP MetworkConfigEntry get INetworkConfigEntry OF Receive vent get set ReceiveEventDelegate E Methods FieReceive vent Message message void INetworkClient ES INetworkServer A Interface Interface INetworkPeer INetworkPeer E Methods Methods ConnectToserver IWetworkConfigEntry configEntry boo DeployServie NetworkConfigEntry configEntry boo Disconnect void SendReturnMessage AbstractPeerHandle client ReturnMessage message void Y SendWessage loServers Message message void Q Stopservicef void IConnectionOriented Interface A Properties ES ConnectEvent get set ConnectEventDelegate EZI DiscomnectEvent get set DisconnectEventDelegate E Methods DiconnectPeerf AbstractPeerHandle peerHandle void Abbildung 3 3 C Klassendiagramm der Schnittstelle zur Transportschicht signalisieren und seine Konfiguration INetworkConfigEntry ver ffentlichen Davon abgeleitet sind die Interfaces INetworkServer und INetworkClient Ein NetworkClient muss Verbindungen zu Servern auf und abbauen k nnen und den Versand von Nachrichten erm gli chen Ein NetworkServer muss Funktionen zum Bereitstellen und zur Beendigung eines Dienstes im plementieren und Antwortnachrich
36. 9 gt error 9999 9999 9999 gt gt 77 lt message gt lt message name SetIntArray id 17 error 9999 gt lt returntype type int gt lt parameter type int name valueID gt lt parameter type int name value gt lt message gt lt message name SetFloatArray id 18 error 9999 gt lt returntype type int gt lt parameter type int name valueID gt lt parameter type float name value gt lt message gt lt message name SetDoubleArray id 19 error 9999 gt lt returntype type int gt lt parameter type int name valueID gt lt parameter type double name value gt lt message gt lt message name SetStringArray id 20 error error gt lt returntype type string gt lt parameter type int name valueID gt lt parameter type string name value gt lt message gt lt message name SetByteVoid id 21 gt lt returntype type void gt lt parameter type int name valueID gt lt parameter type byte name value gt lt message gt lt message name SetIntVoid id 22 gt lt returntype type void gt lt parameter type int name valueID gt lt parameter type int name value gt lt message gt lt message name SetFloatVoid id 23 gt lt returntype type void gt lt parameter type int name valueID gt lt parameter type float name value gt lt mess
37. AbstractPeerHandle ReturnMessageDestination get return returnMessageDestination set returnMessageDestination value Ga Ga Sa Ge Ga Ga Sa S IER Ga EE EE E E H Ga ER S S Ge H S S nratented pleUdpPeerHandle Loaded in 0 32 Abbildung 5 4 Testabdeckung der Klasse Message mit NCover Client verschiedene Anfragen an den Server gestellt deren Ergebnis dann mit dem erwarteten Ergebnis verglichen wird Da der Benutzer der Netzwerkbibliothek die M glichkeit hat sie um spezialisierte Schnittstellen zu er weitern muss die f r die Tests verwendete Schnittstelle m glichst allgemein gehalten werden Dazu wurde das Interface Simple definiert das Methoden zum Setzen und zum Auslesen aller unterst tzten Datentypen und R ckgabewerte anbietet Listing A 2 Der daraus erzeugte ServerStub sendet in den Basistests einzelne zuf llige Werte der verschiedenen Datentypen an den ClientStub welcher sie in ei ner Hashtabelle bzw einer std map speichert Anschlie end wird der zuvor bertragene Wert vom Client wieder abgefragt und berpr ft ob beide Werte gleich sind Die Speicherung in einer Hashtabelle ist n tig weil der Server einen Fehlerwert zur ckliefern muss falls nach einem Wert gefragt wird der vorher gar nicht bertragen wurde Dies k nnte z B der Fall sein wenn zur bertragung des Wertes vom Client zum Server eine Funktion mit R ckgabetyp void verwendet wird und die dazugeh
38. AutoconnectEvent Nested Types Abbildung 3 5 C Klassendiagramm des Coordinators nisse bei ihrem Coordinator Wird der Coordinator gestartet werden entweder die Verbindungen zu den Servern aus der Konfiguration hergestellt oder der Serverdienst bereitgestellt Sind die Stubs so konfi guriert dass die Verbindung automatisch aufgebaut werden soll sendet der Coordinator des ClientStubs in regelm igen Abst nden eine AutoConnectMessage ber einen zus tzlichen Broadcast Client Die Coordinatoren der ServerStubs haben dann jeweils einen zus tzlichen Broadcast Server der diese Dienstank ndigungen empf ngt und an den Coordinator weiterleitet welcher dann eine Verbindung zum angek ndigten Dienst herstellt Um dem Benutzer der Netzwerkbibliothek blockierende Funktionsaufrufe zu erm glichen muss ein Coordinator Bedingungsvariablen condition variables einsetzen Der Aufruf einer ServerStub Funktion erzeugt eine Nachricht die der Coordinator zum Senden an den NetworkClient bergibt Wird ein R ck gabewert erwartet blockiert der aufrufende Thread an einer Sperre bis signalisiert wird dass die Ant wortnachricht eingetroffen ist oder bis der Timeout Wert berschritten wurde Trifft die Antwortnach richt ein wird sie vom ServerStub ausgewertet und der Funktionsaufruf terminiert mit dem R ckgabe wert Im Falle eines Timeouts wird der in der Schnittstellendefinition festgelegte Fehlerwert zur ckgege ben Auf Serverseite reicht der
39. ControlCentre1 ControlCentre ControlCentre2 ControlCentre ReportProcess ExecuteScript ReportP p StateControl EPITTETOCESS Register StateControl RequestRegistration N Host lnstance1 ost Instance2 Host lnstance3 Module1 Module Module2 Module Module3 Module tl AA 2 A AAA Abbildung 2 4 ControlCentre tisch w ren jedoch auch andere Konfigurationen denkbar z B eine ressourcenhungrige Simulation die parallelisiert werden muss Parallele verteilte Simulationen sind seit Jahren Forschungsgegenstand Am erfolgreichsten scheint der vor milit rischem Hintergrund entstandene IEEE Standard f r Distributed Interactive Simulation IEEE Std 1278 1a 1998 siehe 1ee98 zu sein Da dieses Problem momentan im Umfeld des Maschinensimulators keine Rolle spielt soll bei beim Entwurf der Netzwerkkommunikati onsschicht auch nicht n her darauf eingegangen werden Sollte dennoch irgendwann ein solches System entwickelt werden w re zun chst zu pr fen ob die angebotenen Funktionen der Netzwerkschicht eine Synchronisation auf Anwendungsebene erlauben 2 2 5 Multiplayer Spiel Wie beim Maschinensimulator k nnen auch bei einem Spiel einzelne Komponenten auf verschiede ne eigenst ndige Rechner verteilt werden Die damit einhergehende
40. G clientStub SendVector3D Lore Datatypes XData 0 23 3 14 C clientStub gt SendVector3D lore XData 0 23 3 14 3 1 2 Client Server Architektur Die im uspr nglichen Entwurf geplante Peer to Peer Architektur wurde nur unvollst ndig umgesetzt Die automatische Generierung spezialisierter Bibliotheken unterst tzte nur das Client Server Prinzip so dass gleichberechtigte Kommunikationspartner Peers von Hand programmiert werden mussten Auch in den Konfigurationsdateien und im Quellcode wurden die Kommunikationsendpunkte nicht konsequent als Peers sondern als Client oder Server bezeichnet Teilweise herrschte dabei unter den Entwicklern Uneinigkeit welcher Kommunikationsendpunkt als Server und welcher als Client zu bezeichnen sei Um die Rollenverteilung unmissverst ndlicher zu machen wurde ein Proxy Konzept umgesetzt Wie beim RPC werden die Proxies Stellvertreterobjekte als Stubs bezeichnet Der ServerStub ist dabei ein Proxyobjekt ber das ein Client Serverfunktionen aufrufen kann Auf Serverseite werden ber den Cli entStub Antwortnachrichten verschickt Dieser Ansatz erscheint sinnvoll weil die Verteilung der Kom 3 1 SICHT AUF DIE KOMMUNIKATIONSSCHICHT 23 ponenten ohnehin nicht ganz transparent ist der Anwendungsentwickler also wei ob er eine entfernte oder eine lokale Funktion aufruft Abbildung 3 1 2 verdeutlicht die gew hlte Architektur Clientprozess Serverprozess A
41. GPL Lizenz lgp verbreitet Anders als bei den bisher vorgestellten Werkzeugen kann bei CppUnit nicht mit Attributen gearbeitet werden Die Runtime Type Information RTTI von C erm glicht zwar einfache Typabfragen zur Laufzeit weitergehende Reflection Mechanismen wie sie zur Definition und Auswertung von Attributen n tig w ren fehlen jedoch Deshalb verwendet CppUnit wie viele andere Unit Testing Frameworks auch das Konzept der Vererbung um dem Testrunner die Testklassen und Testf lle bekannt zu machen In C w rde der Testfall aus 5 2 1 wie in den Listings 5 2 und 5 3 aussehen Listing 5 2 MessageTest h fifndef _MESSAGETEST_H_ define _MESSAGETEST_H_ include lt cppunit extensions HelperMacros h gt include AbstractStub h include Message h class MessageTest public CPPUNIT NS TestFixture CPPUNIT_TEST_SUITE MessageTest CPPUNIT_TEST SerializeTest CPPUNIT_TEST_SUITE_END private Messagex message public void setUp void tearDown protected void SerializeTest tendif Die Assertions sind in CppUnit als Makros definiert CPPUNIT ASSERT EQUAL expected actual kann zwei Werte vergleichen wenn sie die folgenden Bedingungen erf llen e Sie sind vom gleichen Typ e Sie k nnen mit dem Operator lt lt in einen std strstream serialisiert werden e Sie k nnen mit dem Operator verglichen werden Daneben gibt es u a noch CPPUNIT_ASSERT condition mit d
42. Klassen erm glichen es Testf lle relativ einfach in einem ausf hrbaren Programm zusammenzufassen F r das Testen dyna mischer Bibliotheken wird ein Kommandozeilenprogramm mitgeliefert das die Testergebnisse in eine XML Datei schreiben kann Zusammenfassend l sst sich sagen dass mit CppUnit obwohl es lange nicht so komfortabel zu benutzen ist wie die vorgestellten Unit Testing Frameworks f r C recht einfach umfangreiche Tests formuliert durchgef hrt und protokolliert werden k nnen 5 2 TESTWERKZEUGE 57 5 2 4 TestDriven NET TestDriven NET tesa von Mutant Design Limited ist kein Unit Testing Framework sondern ein Add In f r Visual Studio NET das viele andere Werkzeuge f r Unit Tests in die Entwicklungsumgebung integriert Eine Einzellizenz des ehemals NUnitAddIn genannten Werkzeugs kostet f r den kommerzi ellen Einsatz 135 F r Studenten Open Source Entwickler oder zum Ausprobieren ist die Software kostenlos verf gbar Aktuell ist die Version 2 0 RCI die auch die Integration in Visual Studio 2005 voll unterst tzt Laut Herstellerangaben lassen sich alle wichtigen Unit Testing Frameworks integrie ren darunter auch NUnit Zanebug und Visual Studio Team System Tats chlich werden die popul rsten Werkzeuge bereits unterst tzt und die kontinuierliche Weiterentwicklung wird die Zusammenarbeit mit weiteren Tools erm glichen Can TestDriven NET erm glicht es Tests direkt ber das Kontextmen von V
43. SE 2 5 Evaluation der bestehenden Netzwerkkommunikationsschicht Die eingehende Betrachtung der bestehenden Netzwerkbibliothek ergab dass die wichtigsten Anforde rungen zum gr ten Teil erf llt werden Vor allem bei der Administrierbarkeit und Erweiterbarkeit gibt es aber noch Defizite Im folgenden sollen diese Probleme aber auch kleinere Schw chen bei Entwurfs und Implementierungsdetails stichpunktartig aufgef hrt werden e Verwaltung Konfiguration und globale Zustandskontrolle schwierig oder nicht m glich keine Mechanismen um zur Laufzeit die Verteilung der Komponenten zu ermitteln 2 2 3 globale Zustandskontrolle noch gar nicht ber cksichtigt 2 2 3 statische Konfiguration relativ unflexibel Anwendung kann sie nur lesen nicht aber ver n dern und speichern 3 1 3 e Erweiterbarkeit problematisch keine festgelegte Schnittstelle zur Transportschicht statt dessen nur eine Klasse f r alle Transporttypen gt if tcp else if udp else if broadcast 3 2 kaum Dokumentation teilweise missverst ndliche Namensgebung e Aufrufsemantik und Programmiermodell k nnten flexibler gestaltet sein kein funktionspezifischer Fehlerr ckgabewert bei automatisch generierten Schnittstellen de finierbar 3 1 1 default timeout 1000 ms f r alle Funktionsaufrufe hardcoded 3 1 1 und 3 1 3 bei Broadcasting keine selektiven Antworten m glich sondern Anwort auch immer Broad cast 3 2 1 e Schw chen
44. Simulation1 Simulation Simulationt Simulation Visualisation1 Visualisation Visualisation1 Visualisation Visualisation2 Visualisation Abbildung 2 2 Entwicklung neuer Komponenten 2 2 3 Kontrollzentrum Momentan gibt es noch keine Komponente die die begueme Verwaltung des verteilten Systems gestattet F r diese Aufgabe wurde in NMWOS ein spezielles Modul das Kontrollzentrum ControlCentre kon zipiert Bei der prototypischen Implementierung durch Benny Wegener wurde aber festgestellt dass die von der Netzwerkschicht angebotene Schnittstelle teilweise erweitert werden muss Im folgenden werden deshalb der Entwurf dieser Anwendung und die daraus entstehenden Anforderungen an die Netzwerk schicht erl utert Um die Zusammenarbeit der einzelnen Komponenten zentral koordinieren zu k nnen wurde ein Zu standsautomat definiert den jedes Modul implementieren muss Abbildung 2 3 Initial Abbildung 2 3 Zustandsautomat einer Komponente Initial befinden sich alle Komponenten im Zustand Stopped in dem sie ausschlie lich auf weitere An weisungen warten Im Zustand Started verrichtet die Komponente ihre Aufgabe Der Zustand Paused 10 2 ANFORDERUNGSANALYSE ist abh ngig von der Art der Komponente ein Eingabemodul
45. TECHNISCHE UNIVERSIT T DRESDEN FAKULT T INFORMATIK INSTITUT F R SOFTWARE UND MULTIMEDIATECHNIK PROFESSUR F R COMPUTERGRAPHIK UND VISUALISIERUNG PROF DR STEFAN GUMHOLD Gro er Beleg Anforderungsanalyse Definition und Implementierung einer Netzwerkkommunikationsschicht f r ein modulares Simulations und VR System Markus M ller Mat Nr 2815730 Betreuer Dipl Inf FH Benjamin Neidhold Dresden 19 September 2006 Inhaltsverzeichnis 1 Einleitung 2 Anforderungsanalyse 2 1 Allgemeine Anforderungen an verteilte Virtual Reality Umgebungen 2 2 Szenarioanalyse seca u wo e a he rd 2 2 1 Baggersimulator 2 2 2 Entwicklung neuer Komponenten 2 2 3 Kontrollzentrum E a a d Gi et 2 2 4 Verteilte Simulation 2 2 5 Mulupla yer Spiel asta bg Kai In erh ie baie he Go 2 3 Abgeleitete Anforderungen an die Kommunikationsschicht 2 4 Programmiermodell und Aufrufsemantik 2 5 Evaluation der bestehenden Netzwerkkommunikationsschicht 3 Entwurf 3 1 Sicht auf die Kommunikationsschicht 3 1 1 Unterst tzte Funktionen und Datentypen 3 1 2 Client Server Architektur 31 3 Konfiguration s c Git A BR en 3 2 Schnittstelle zur Transportschicht 3 2 1 Unterst tz
46. age gt lt message name SetDoubleVoid id 24 gt lt returntype type void gt lt parameter type int name valueID gt lt parameter type double name value gt lt message gt lt message name SetStringVoid id 25 gt lt returntype type void gt lt parameter type int name valueID gt lt parameter type string name value gt lt message gt lt message name SetByteArrayVoid id 26 gt 78 ANHANG A LISTINGS lt returntype type void gt lt parameter type int name valueID gt lt parameter type byte name value gt lt message gt lt message name SetIntArrayVoid id 27 gt lt returntype type void gt lt parameter type int name valueID gt lt parameter type int name value gt lt message gt lt message name SetFloatArrayVoid id 28 gt lt returntype type void gt lt parameter type int name valueID gt lt parameter type float name value gt lt message gt lt message name SetDoubleArrayVoid id 29 gt lt returntype type void gt lt parameter type int name valueID gt lt parameter type double name value gt lt message gt lt message name SetStringArrayVoid id 30 gt lt returntype type void gt lt parameter type int name valueID gt lt parameter type string name value gt lt message gt lt messagetable gt Listing A 3 M
47. age unpackedMessage Message Deserialize messageAsByteArray MemoryStream messageData MemoryStream TestHelper getField message data MemoryStream unpackedMessageData MemoryStream TestHelper getField unpackedMessage data Assert AreEqual messageData GetBuffer unpackedMessageData GetBuffer Assert AreEqual MessageType DEFAULT unpackedMessage Type x not neccessary buffer equality is already tested above unpackedMessage SetReadPointerToBeginningOfPayload Assert AreEqual 12314 unpackedMessage ReadInt Assert AreEqual 33432 unpackedMessage ReadInt Assert AreEqual 88 unpackedMessage ReadInt Assert AreEqual 44 unpackedMessage ReadInt Assert AreEqual 255 unpackedMessage ReadInt x x 83 Test public void PackAndUnpackReturnMessageTest ReturnMessage returnMessage new ReturnMessage message byte messageAsByteArray returnMessage Serialize Message unpackedMessage Message Deserialize messageAsByteArray Assert AreEqual MessageType RETURN unpackedMessage Type Listing A 4 LocalSimpleStubTest cs using using using using using using using System System Collections System Collections Generic NUnit Framework odonet_cs Lore Util Simple namespace odonet_cs_test Shortened Version of the testclass for systemtests via loopback interface In the full version all parameter a
48. alle unterst tzten Parameter und R ckgabetypen beinhaltet lt xml version 1 0 encoding utf 8 gt lt messagetable name Simple gt lt message name GetByte id 1 error 255 gt lt returntype type byte gt lt parameter type int name valueID gt lt message gt lt message name GetInt id 2 error 9999 gt lt returntype type int gt lt parameter type int name valueID gt lt message gt lt message name GetFloat id 3 error 9999 gt lt returntype type float gt lt parameter type int name valueID gt lt message gt lt message name GetDouble id 4 error 9999 gt lt returntype type double gt lt parameter type int name valueID gt lt message gt lt message name GetString id 5 error error gt lt returntype type string gt lt parameter type int name valueID gt lt message gt lt message name GetByteArray id 6 error 0 0 0 gt lt returntype type byte gt 76 ANHANG A LISTINGS lt parameter type int name valueID gt lt message gt lt message name GetIntArray id 7 error 9999 99 lt returntype type int gt lt parameter type int name valueID gt lt message gt lt message name GetFloatArray id 8 error 9999 lt returntype type float gt lt parameter type int name valueID gt lt message gt lt message name GetDoubleArray id 9
49. angen erzeugt dieser einen neuen InstanceStub und speichert die entfernte IP Adresse zusammen mit dem Port als Schl ssel in einer Hashtabelle um mehrfache Verbindungen zu vermeiden Danach werden zuerst der Server und dann der Client des neuen InstanceStub gestartet Durch den Verbindungsversuch des InstanceStub wird beim Server des ControllerStub ein Ereig niss ausgel st mit dem die IP Adresse und der Port des Servers des InstanceStub ermittelt wer den kann zu dem unmittelbar danach die Verbindung hergestellt wird Innerhalb dieser Ereignisbe handlungsroutine wird auch der BroadcastClient gestoppt so dass keine weiteren Nachrichten vom ControlCentreAnnouncer empfangen werden k nnen Weil der gesamte Verbindungsaufbau aber doch etwas dauert kann es vorkommen dass die Anfragen des ControlCentreAnnouncer mehr fach beantwortet werden weshalb dieser letzlich daf r verantwortlich sein muss dass zu jedem Control lerStub nurein InstanceStub erzeugt wird Beim Abbau der Verbindungen ist zu beachten dass ein InstanceStub dem ControlCentreAnnouncer mitteilt dass seine Verbindung verloren ging so dass der ControlCentreAnnouncer den entsprechenden Schl ssel aus der Hash Tabelle l scht und damit wieder eine Verbindung zum korrespondierenden ControllerStub aufbauen kann Verliert ein ControllerStub die Verbindung zu seinem InstanceStub wird der BroadcastClient wieder gestartet so dass er wieder Nachrichten vom ControlCentreAnnouncer empfangen kann
50. atform Invoke der die Aufrufe von verwaltetem NET Code auf Aufrufe von nicht verwalteten Win32 Code abbildet MSD06 Auf der anderen Seite bietet eine Neuimplementierung die Chance die bestehende Bibliothek noch ein mal kritisch zu betrachten Die Evolution des gesamten Systems K nnte inzwischen neue Anforderungen an die Netzwerkkommunikationsschicht hervorgebracht haben die nicht mehr optimal erf llt werden Zus tzlich zu den allgemeinen Anforderungen kann weil die urspr ngliche Bibliothek schlie lich schon von mehreren Entwicklern ber einen l ngeren Zeitraum genutzt wird auch die Erf llung nicht explizit genannter Qualit tsmerkmale vor allem die Benutzbarkeit gepr ft werden Deshalb und weil sowohl die systematische Evaluation eines Softwaresystems als auch die die Im 6 2 ANFORDERUNGSANALYSE plementierung begleitenden Tests Klar formulierte Anforderungen bedingen soll trotz bestehender Im plementierung zun chst ein Top Down Ansatz verfolgt werden Dies beinhaltet die Analyse m glicher Szenarien und Anwendungsf lle die Festlegung der ben tigten Schnittstellen und die Auswertung der Erfahrungen der am Projekt beteiligten Personen 2 1 Allgemeine Anforderungen an verteilte Virtual Reality Umgebungen F nf zentrale Anforderungen an ein verteiltes Simulations und VR System wurden bereits in Met05 herausgearbeitet und sollen hier noch einmal kurz zusammengefasst werden e Flexibilit t Der zentra
51. ber eine graphische Benutzerschnittstelle ansprechen sind Capture and Replay Werkzeuge vonn ten In diesem Kapitel soll eine Auswahl an Werkzeugen vorgestellt werden die die Testautomation bei der Implementierung der Netzwerkschicht erleichtern k nnen Auf Werkzeuge zum Testen von Datenbank zugriffen oder graphischen Benutzerschnittstellen GUT wird deshalb nicht eingegangen Obwohl eine Netzwerkbibliothek f r ein verteiltes Simulations und VR System entwickelt wird kann das Testen von verteilten Systemen wegen der Komplexit t dieses Themas nur kurz in 5 5 angesprochen werden 50 5 AUTOMATISIERTES TESTEN 5 2 1 NUnit NUnit TPCF ist sicherlich eines der popul rsten Unit Testing Frameworks berhaupt Urspr nglich war es eine einfache Portierung von JUnit auf die Net Sprachen Mit der Version 2 0 wurde es aber komplett berarbeitet um Net spezifische Features wie Attributierungs oder Reflectionmechanismen voll ausnutzen zu k nnen Die aktuelle Version 2 2 8 ist jedoch nur f r Windows verf gbar das letzte offizielle Release f r Mono Version 2 2 ist schon recht alt und unterst tzt nicht alle Features NUnit ist Open Source Software und wird unter der zlib libpng Lizenz verbreitet die den Gebrauch nur sehr wenig einschr nkt zli Allen Testframeworks ist gemeinsam dass sie dem Tester viel Arbeit abnehmen so dass dieser sich auf das Schreiben der Testf lle konzentrieren kann Die Testf lle werden in derselben Sp
52. ber erst dann als umgesetzt wenn sie implementiert und getestet wurden Damit ist es ebenfalls Gegenstand eines Systemtests zu berpr fen ob die Funktions tests vollst ndig sind Dazu werden die Dokumente aus der Analysephase herangezogen Aus den dort angegebenen Anwendungsf llen und Szenarien ergeben sich direkt die Anforderungen deren korrekte Umsetzung durch Unit und Integrationstests berpr ft worden sein muss Soll die Software auf unterschiedlichen Betriebssystemen lauff hig sein muss das Verhalten unter den verschieden Umgebungen untersucht werden Dabei ist zu beachten dass es nicht nur bei unterschiedli chen Systemfamilien wie Linux Windows oder Mac OS zu abweichendem Laufzeitverhalten kommen kann sondern auch innerhalb der Systemfamilien gravierende Unterschiede zwischen den Versionen exi stieren Zum einen liegt das daran dass die Systemkomponenten anders verwaltet werden zum anderen k nnen auch Updates oder Service Packs das Laufzeitverhalten beeinflussen Dazu kommen au erdem noch unterschiedliche Versionen von Komponenten von denen die Software abh ngig ist DLL Hell Weiterhin sollten auch die Installierbarkeit die Konfigurierbarkeit und schlie lich die Deinstallierbar keit auf den verschiedenen Plattformen berpr ft werden Neben dem Betriebssystem K nnen auch die Hardware und die zugeh rigen Treiber einen entscheidenden Einfluss auf den korrekten Ablauf eines 5 2 TESTWERKZEUGE 49 Programms nehmen
53. bildung 7 1 zeigt das Ergebnis von Ren Schulte Ren Janovsky und Torsten B r ein virtuelles Dosenschie en mit schneller Physiksimulation Abbildung 7 1 Virtuelles Dosenschie en Gelingt es trotz der Verteilung auf verschiedene Computer nicht bestimmte Simulationen in Echtzeit durchzuf hren k nnte eine Anwendung entwickelt werden die die Ausgabe der Simulationskomponen te aufzeichnen und danach mit ver nderter Geschwindigkeit abspielen kann Wenn diese Anwendung dann den gleichen ServerStub wie die Simulationskomponente und den gleichen ClientStub wie die Visualisierungskomponente verwendet kann sie zwischen diesen beiden Modulen zugleich als Relay agieren so dass auch w hrend der Aufzeichnung der Simulationsergebnisse eine Visualisierung statt finden kann Die Callback Funktionen des ClientStubs m ssten dann so implementiert werden dass ihr Aufruf mit Zeitstempel und allen bergebenen Parametern protokolliert wird und dass wiederum die ent sprechende ServerStub Funktion aufgerufen wird Beim Abspielen w rde diese Anwendung dann die Simulationskomponente ersetzen und an Hand der gespeicherten Zeitstempel und Parameter direkt mit der Visualisierungskomponente kommunizieren Noch wird die neue Netzwerkbibliothek noch nicht von allen bestehenden Modulen verwendet welche Erweiterungen letztlich wirklich ben tigt werden wird erst der Praxiseinsatz zeigen 69 Literaturverzeichnis apa Beu blo bsd
54. cher Di Suchdienst O System TCP Segments sec Connections E stablished Connections Active O Connections Passive O Connection Failures O Connections Reset O Segments Received sec O Segments Sent sec Segments Retransmitted sec O Telefonie O Terminaldienste O Terminaldienstesitzungen O Thread v 4 gt Machine Name Frequency Density Start Stop Abbildung 5 2 Performance Monitor von Zanebug denen Programme ausgef hrt werden Immer wenn ein Programm eine Assembly l dt wird sie zur aktu ellen Anwendungsdom ne hinzugef gt und vor Ver nderungen gesch tzt Damit trotzdem neue Versio nen der geladenen dynamischen Bibliotheken erstellt werden k nnen ohne dass Zanebug dazu beendet werden muss wird die zu testende Assembly kopiert und die Kopie geladen Dabei galt es wohl einige Fallstricke zu berwinden und letztlich funktioniert dieser Mechanismus auch noch nicht fehlerfrei Es kann passieren dass Tests nach dem ersten Durchlauf nicht erneut gestartet werden k nnen erst nach einer Verz gerung starten oder dass das Programm nicht korrekt beendet wird Das Programmfenster wird dann zwar geschlossen der Prozess aber lebt weiter und muss manuell beendet werden 5 2 TESTWERKZEUGE 55 5 2 3 CppUnit CppUnit SFL ist die erste Portierung von JUnit nach C Es ist quelloffen und l sst sich unter allen wichtigen Betriebssystemen einsetzen CppUnit wird ausschlie lich als Source Code unter der L
55. d sollen zun chst die relevanten Be griffe und Zusammenh nge gekl rt werden Latenz Die Latenz beschreibt die Zeit die vergeht bis nach dem Absenden der Nachricht erstmals Daten auf der Empf ngerseite verf gbar werden Diese Verz gerung kommt durch den Netzwerkstack und die Laufzeit im bertragungsmedium zustande Dateniibertragungsrate Die Datentransferrate ist die Geschwindigkeit mit der Daten zwi schen zwei Computern ausgetauscht werden k nnen nachdem die bertragung begonnen hat Nachrichtenlaufzeit Die Zeit die ben tigt wird um eine Nachricht zu bertragen berechnet sich wie folgt Nachrichtenl nge Nachrichtenlauf zeit Latenz 4 Daten bertragungsrate Round Trip Time Die Round Trip Zeit ist die Summe aus der Laufzeit einer Nachricht von der Quelle zum Ziel und der Laufzeit der Antwort vom Ziel zur Quelle Antwortzeit Die Antwortzeit auch als Gesamtverz gerung bezeichnet setzt sich aus der Round Trip Time und der Verarbeitungszeit auf dem Zielrechner Server Delay zusammen nach Pac02 2 3 ABGELEITETE ANFORDERUNGEN AN DIE KOMMUNIKATIONSSCHICHT 13 Von diesen Performanzkriterien stellt sich die Latenz als am wichtigsten heraus weil mit Aus nahme der Daten bertragungsrate alle anderen Gr en von ihr abh ngen Damit ist sie sowohl f r Nachrichten ohne R ckgabewert als auch f r Nachrichten zu denen eine Antwort erwartet wird von h chster Relevanz denn
56. den neuen Client angesehen werden kann Schlie lich wird dieses PeerHandle zur Liste clients des TcpNetworkServers hinzugef gt und die Schleife beginnt von Neuem Der Verbindungsaufbau eines TcpNetworkClient ist weniger aufw ndig Innerhalb der Connect To Server Methode wird ein neuer Socket erstellt der wie in der DeployService Methode an ein be stimmtes Netzwerkinterface gebunden wird Danach wird mit dem Aufruf der Connect Methode des Sockets die Verbindung zum angegebenen Server hergestellt Wie beim Server werden der verbunde ne Socket und ein neuer Receive Thread anschlie end einem TcpPeerHandle zugewiesen welches beim TcpNetworkClient in die Liste servers aufgenommen wird Nachdem eine Verbindung aufgebaut wurde kann die SendMessageToServers Methode des Cli ents dazu verwendet werden eine Nachricht nacheinander an alle Server zu schicken Dazu wird die Nachricht in ein Byte Array serialisiert welches f r jeden Server mit einem einzigen Send Aufruf an den jeweiligen Socket bergeben wird Die SendMessageToClient Methode eines TcpNet work Server hingegen sendet die Nachricht nur an den Client der durch das beim Aufruf bergebene Peer Handle repr sentiert wird Dabei ist zu beachten dass die Implementierung der ReceiveThread Methode des entfernten PeerHandles bei allen Transporttypen an die Implementierungen der Sende funktionen angepasst sein muss Bei der Kommunikation ber TCP bei der ein Byte Strom ber einen
57. der Message Klasse gezeigt werden Listing 5 1 Erstellt man daraus eine dynamische Bibliothek kann man sie mit der Anwendung NUnit GUI ffnen und den Test starten Mit diesem Testrunner lassen sich mehrere Assemblies laden wobei ber Check boxen ausgew hlt werden kann welche Tests ausgef hrt werden sollen Abbildung 5 1 zeigt das Fenster der Anwendung nach der Durchf hrung des Tests E Unit TestingExamples nunit NUnit D x File View Project Test Tools Help Tests Categories DM E UnitTestingExamples UnitT estingE xamples nunit Run Stop SerializeT est 2 04 E UnitTestingE amples UnitT estingE xamples dll 2 09 UnitTestingExamples 3 08 MessageTest OS SerializeTest Errors and Failures Tests Not Run Console Out Console Error a Clear All Check Failed JV Word Wrap Text SerializeT est Test Cases 1 Abbildung 5 1 NUnit GUI unter Windows NUnit ist frei verf gbar einfach zu benutzen und bietet in der aktuellen Version eine Vielzahl von vor definierten Assertions und Attributen von denen eine Auswahl in den Tabellen B 1 und B 2 zusammen gefasst sind Dass man NUnit aber trotzdem noch verbessern kann wird der n chste Abschnitt zeigen 2Seit der k rzlich erschienenen Version 4 0 unterst tzt JUnit ebenfalls die Testdeklaration durch Attribute 52 5 AUTOMATISIERTES TESTEN Listing 5 1 MessageTest cs
58. e den neuen Systemzustand und sendet die resultierenden Parameter an die Ausgabemodule Motion Sound und Visualisierung Die Manipulation der Landschaft also das Baggern ist noch nicht implementiert Die Visualisierung ist meist mehrfach instanziiert drei Instanzen f r die Projektion in der Kuppel zwei Instanzen f r die R ckspiegel und eine Instanz f r den Kontrollraum Bei Pr sentationen vor gr erem Publikum werden zwei weitere Instanzen f r eine Powerwall ben tigt Alle anderen Module laufen auf jeweils genau einem Rechner 2 2 2 Entwicklung neuer Komponenten Die Entwicklung neuer Komponenten geschieht normalerweise zun chst auf einem einzelnen Rechner Die Zusammenarbeit eines neuen Moduls etwa einer neuen Simulation mit den bestehenden Modulen 8 2 ANFORDERUNGSANALYSE Host Sound Sound Host Cab lt Cab SoundParameters SimulationControl Terraininformation Host lnput Host Database Database Simulation Host Motion A TerrainManipulation a E MotionControl 4 N Tumor Motion E S 0 VisualisationParameters P E TerrainInformation VisualisationParameters Terraininformation R I Visualisation Visualisation Host Visualisation2
59. e in der urspr nglichen Implementierung verwendet wurde um den Timeout Wert f r eine einzelne besonders gro e Nachricht zu erh hen ist weggefallen da bei der neuen Implementierung Timeouts pro Stub und pro Funktion von au en konfigurierbar sind Die Laufnummer wird ben tigt um Antwortnachrichten den zugeh rigen Anfragenachrichten zuordnen zu k nnen Die Nutzdaten werden von den spezialisier ten Funktionen der Stubs geschrieben Die Identifikationsnummern mit denen Nachrichten und Funk tionen aufeinander abgebildet werden k nnen sind anwendungsspezifisch und werden deshalb auch im Nutzdatenteil der Nachricht bertragen Ungew hlich ist dass die Nachrichten auf Byte Arrays in Little Endian Byte Order h chstwertiges Byte zuerst abgebildet werden Meistens wird f r die bertragung ber ein Netzwerk die Big Endian Byte Order h chstwertiges Byte zuletzt verwendet die deshalb auch als Network Byte Order bezeich net wird Da im Umfeld des Baggersimulators weitgehend PCs verwendet werden und PCs immer Little Endian Maschinen sind ist es naheliegend die berfl ssige Konvertierung von Host Byte Order in Network Byte Order und zur ck nicht durchzuf hren Statt dessen m ssen Rechner die mit Big Endian Byte Order arbeiten die Bytes vor dem Senden und nach dem Empfangen entsprechend drehen Auch f r die Implementierung in C hat sich dieses Vorgehen als praktisch erwiesen weil die zur Spei cherung der Byte Repr sentation verw
60. eist vernachl ssigt Das Ergebnis sind Tests die von anderen Klassen Integrationstests siehe 5 1 2 oder einer komplexen Infrastruktur abh ngig sind Systemtest siehe 5 1 3 Michael Feathers der Entwickler von CppUnit hat deshalb einen Satz von Regeln verfasst der zwar keine v llige Isolation der zu testenden Klasse fordert den Begriff Unit Test aber trotzdem auf ein sinnvolles Ma einschr nken soll Fea Nach seiner Definition ist ein Test kein Unit Test wenn e erein Datenbanksystem benutzt e eriiberein Netzwerk kommuniziert e er das Dateisystem ber hrt e ernicht gleichzeitig mit jedem anderen Unit Test durchgef hrt werden kann e wenn die Umgebung speziell konfiguriert werden muss Letztlich geht es bei diesen Einschr nkungen darum dass solche Tests in jedem Fall sehr schnell und ohne gro en Aufwand durchf hrbar sein m ssen Feathers verwischt dadurch aber die Grenze zwischen isolierten Unit Tests bei denen ausschlie lich die Korrektheit einer einzelnen Klasse berpr ft wird und funktionalen Tests bei denen alle Teile des Systems involviert sein k nnen Anh nger des Test Driven 5 1 ARTEN VON TESTS 47 Development argumentieren aber dass es zwar sinnvoll sei schnelle und langsame Tests voneinander zu trennen es m sse aber trotzdem zwischen Unit Tests und Integrations oder Systemtests unterschie den werden Durch das isolierte Testen einzelner Klassen sei es einfacher eine hohe Testabdeckung zu e
61. elche dann unmittelbar verwendet werden k nnen Die urspr ngliche Netzwerkbibliothek f r C von Joscha Metze wurde komplett berarbeitet und um eine Implementierung in C erweitert Damit wurden zus tzlich zu Windows und Linux NET 2 0 und Mono 2 0 als Plattformen f r die Entwicklung neuer Komponenten erschlossen Neben der Abstraktion von der Programmiersprache wurde durch den neuen Entwurf auch die Integration neuer Netzwerk technologien wie z B ATM oder Myrinet erm glicht Weiterhin wurden spezielle Kommunikationsend punkte implementiert mit denen ber das Kontrollzentrum alle Module einer verteilten Anwendung berwacht und gesteuert werden k nnen Bei der Schnittstellendefinition k nnen nun funktionsspezifische Timeout Intervalle und Fehlerwerte an gegeben werden so dass erstmals eine angemessene Behandlung von Zeit berschreitungen erm glicht wird Daneben gestatten zahlreiche neue Konfigurationsparameter mit denen z B die Sende und Emp fangspuffergr en oder die zu verwendende Netzwerkkarte festgelegt werden k nnen eine bessere An passung an die Systemumgebung Die wichtigste Neuerung jedoch ist die ausf hrliche Dokumentation Neben aussagekr ftigen Kommen taren im Quellcode sind begr ndete Entwurfsentscheidungen und Erkl rungen zu wichtigen Aspekten der Implementierung unverzichtbar f r die Weiterentwicklung der Netzwerkbibliothek durch andere Per sonen Ohne diese Hilfsmittel ist der Einarbeitungsaufwand imm
62. em ein boolscher Wert berpr ft 56 5 AUTOMATISIERTES TESTEN Listing 5 3 MessageTest cpp include MessageTest h CPPUNIT TEST SUITE REGISTRATION MessageTest void MessageTest setUp this gt message new Message void MessageTest tearDown delete message void MessageTest SerializeTest this gt message gt Writelnt 43 this gt message gt SetSequenceNumber 7 byte expected 16 0 0 0 0 0 0 0 7 0 0 0 43 0 0 O bytex result this gt message gt Serialize for int i 0 i lt 16 i CPPUNIT ASSERT EOUAL expected i result i wird und CPPUNIT_FAIL message das immer fehl schl gt und die bergebene Nachricht ausgibt Mit CPPUNIT_ASSERT_THRON expression ExceptionType gibt es auch unter CppUnit die M glichkeit zu testen ob alle Ausnahmen wie erwartet ausgel st werden Die Testregistrierung findet in der Header Datei mit dem Makro CPPUNIT_TEST testMethod statt Um die Tests ausf hren zu k nnen muss dem Projekt noch die TestRunner Klasse hinzugef gt werden die ohne nderungen aus den mitgelieferten Beispielen verwendet werden kann Damit l sst sich dann eine einfache Anwendung erstellen die die Testergebnisse auf der Konsole ausgibt Zur Erstellung einer Testanwendung mit graphischer Oberfl che gibt es f r Windows die Klasse MfcTestRunner oder alter nativ die vom Quasar Toolkit von Trolltech abh ngige Klasse OtTestRunner Beide
63. en Eine einfache Ot Testrunner Implementierung bringt jedoch wenig Vorteile so dass der Aufwand f r die Installation und die Einar beitung in das Ot Toolkit zu hoch erscheint F r das Unit Testing eignen sich besonders die Klassen Message und NetworkConfigEntry Die Klasse NetworkConfigEntry hat die statische Methode Validate INetworkConfigEntry die berpr fen soll ob ein Konfigurationsobjekt alle ben tigten Informationen enth lt und fehlende Wer te so weit wie m glich mit voreingestellten Werten belegt oder Ausnahmen ausl st falls dies nicht m g lich ist Die Unit Tests dieser Klasse bestehen im Wesentlichen darin zu berpr fen ob ung ltige oder fehlende Werte als solche erkannt werden und ob die richtigen Default Werte eingesetzt werden bzw ob alle erwarteten Ausnahmen mit aussagekr ftigen Fehlermeldungen ausgel st werden Bei der Message Klasse wurden neben den Konstruktoren alle Methoden zum Lesen oder Schreiben der unterst tzten Datentypen und die Methoden zum Serialisieren und Deserialisieren getestet Listing A 3 Ungetestet blieben lediglich einfache Properties bzw Getter und Setter Methoden Damit wurden 94 der Me thoden dieser Klasse getestet Abbildung 5 4 zeigt das Fenster des zur Feststellung der Testabdeckung verwendeten Werkzeugs NCover nco Beim Entwurf der Systemtests ist zu beachten dass die Kommunikation zwischen den Implementie rungen in C und C getestet werden k nnen muss Dazu
64. endeten Klassen intern auch immer mit Little Endian Byte Order arbeiten 3 3 Kommunikationssteuerung Um die anwendungsspezifischen Bibliotheken und damit auch die XSLT Stylesheets von der verwen deten Transportschicht unabh ngig zu machen ist es n tig die Implementierungen der Stubs und der NetworkPeers durch Indirektion zu entkoppeln Diese Aufgabe soll die Klasse Coordinator ber nehmen Ein Coordinator Abbildung 3 5 muss f r jeden Stub die passenden NetworkPeers erzeugen Verbindungen auf und abbauen und die Aufrufe der spezialisierten Stubfunktionen auf Sende und Emp fangsoperationen der NetworkPeers abbilden k nnen Je nach bergebenem INetworkConfigEntry muss der Coordinator eine Instanz eines Network Servers oder NetworkClients erzeugen und bei dieser Eventhandler f r ankommende Nachrichten und Verbindungsereignisse registrieren Die Stubs wiederum registrieren Eventhandler f r die selben Ereig 3 3 KOMMUNIKATIONSSTEUERUNG 31 Coordinator Sealed Class gt Disposelt Fields Properties S ConnectEvent S DisconnectEvent S IsStarted S NetworkPeer S ReceiveEvent Methods Y ConnectEventHandler Y Coordinator Y DisconnectEventHandler Y Dispose Y GetSequenceNumber ReceiveAutoconnectMessage Y ReceiveMessage SendAutoConnectMessage Y SendMessage Y Start a StartServiceAnnouncement Stop Y StopServiceAnnouncement Y WaitForReturnMessage 1 overload Events 7 autoconnectEvent gt
65. ens weil auf eigentlich l ngst beantwor tete Fragen neue Antworten gefunden werden m ssen 66 6 ERGEBNISSE 67 7 Ausblick Viele Unzul nglichkeiten der alten Netzwerkkommunikationsschicht wurden bei der Neuimplementie rung beseitigt Dennoch konnten aus Zeitgr nden nicht alle Ideen zur Verbesserung umgesetzt werden Da die Bibliothek nach wie vor ausschlie lich f r den Einsatz in lokalen Netzen ausgelegt ist die Be r cksichtigung aller Sicherheitsfragen die die Kommunikation ber das Internet betreffen aber nicht sinnvoll erscheint sollte die Kommunikation ber ein Wide Area Network ber ein virtuelles privates Netzwerk VPN statt finden Welches Protokoll PPTP IPSec sich dabei am besten eignet ist noch zu kl ren Neben kleineren Optimierungen und der Integration weiterer Netzwerktechnologien w ren auch kom plexere Implementierungen der NetworkPeers f r den Zugriff auf die Transportschicht denkbar So w re z B eine zuverl ssige Broadcast Implementierung f r die differentielle Daten bertragung ber einen Broadcast Kanal w nschenswert Dazu m ssten auf Empf ngerseite alle Pakete aller unvollst ndigen Nachrichten zwischengespeichert und fehlende Pakete ber einen separaten Kommunikationskanal er neut angefordert werden Der Sender k nnte die Paketwiederholungen ber dieselbe zus tzliche Verbin dung zustellen oder aber ber den Broadcast Kanal an alle verteilen F r die Entwicklung
66. er nicht praktikabel bestimmte Ob jekte vor jedem Test neu zu kreieren etwa weil die Objekte zustandslos sind oder weil ihre Erzeugung aufw ndig ist In diesem Fall sollten sie vom Konstruktor der Testklasse oder von der von manchen Testframeworks dazu angebotenen Test Fixture Setup Methode bereitgestellt werden Die Testf lle selbst werden ebenfalls als Methoden formuliert die wiederum Methoden des Testobjekts aufrufen und mit Hilfe von Zusicherungen Assertions berpr fen ob die zur ckgegebenen Werte bzw SUnit das erste Unit Testing Framework berhaupt wurde von Kent Beck f r Smalltalk entwickelt JUnit ist eine SUnit Portierung auf Java Fast alle Unit Testing Frameworks sind einfache bersetzungen von SUnit oder JUnit in die Zielspra che 5 2 TESTWERKZEUGE 51 die nderungen des Objektzustands den Erwartungen entsprechen Nach jedem Test wird die Tear Down Methode der Testklasse aufgerufen Sie stellt das Gegenstiick zur Setup Methode dar und soll die allokierten Ressourcen nach jedem Test wieder freigeben NUnit nutzt modernste Sprachmittel um das Schreiben von Tests m glichst einfach zu gestalten Mittels Attributen werden Testklassen und Testmethoden als solche markiert so dass das bei den anderen Test frameworks iibliche Ableiten von einer Basistestklasse und das explizite Registrieren der Testmethoden entf llt siehe 5 2 3 Wie beguem damit Tests erstellt werden k nnen soll an Hand eines Testfalls
67. erbindungen ist dabei nicht ausreichend da weder angenommen werden kann dass das Kontrollzentrum bereits gestartet wurde bevor die anderen Komponenten gestartet werden noch dass alle Komponenten bereits laufen wenn das Kontrollzentrum gestartet wird Der Mechnismus den herk mmliche Stubs zum automatischen Verbindungsaufbau verwenden siehe 4 2 ist aber ebenfalls ungeeignet weil die individuelle Adressierbarkeit der Instanzen dann nicht gegeben ist Um dieses Pro blem zu l sen wurde der ControlCentreAnnouncer geschaffen Dieser wird vom Kontrollzentrum dazu benutzt alle Module die einen Cont rollerStub gestartet haben aufzufinden und eine Verbin 42 4 IMPLEMENTIERUNG dung zu ihnen herzustellen Dazu sendet der ControlCentreAnnouncer auf dem angegebenen Port Broadcast Mitteilungen und generiert f r jeden noch nicht registrierten Cont rollerStub von dem ei ne Antwort empfangen wird einen neuen bereits verbundenen InstanceStub Im einzelnen l uft der Verbindungsaufbau wie folgt ab Der ControllerStub erzeugt seinen Client und seinen Server mit den Parametern aus der Konfigurationsdatei wobei aber zun chst nur der Server gestartet wird Zus tz lich dazu wird ein BroadcastClient erzeugt der auf Nachrichten vom ControlCentreAnnouncer wartet Sobald eine solche Nachricht eintrifft antwortet der ControllerStub mit einer Nachricht die die IP Adresse und den Port seines Servers enth lt Wird diese Nachricht wiederum vom Announ cer empf
68. erer angeben kann welche Funktionen des Mock Objekts von der zu testenden Klasse w hrend des Tests aufgerufen werden m ssen und welcher Wert dann zur ckgegeben werden soll Hier wird also vor allem getestet ob bestimmte Funktionen auf gerufen wurden und nicht was ihr Aufruf bewirkt Interaktionsbasierte Tests sind also eher Integrations als Unit Tests auch wenn Mock Objekte ein wichtiges Hilfsmittel zum isolierten Testen einzelner Klas sen darstellen Ob der Aufwand betrieben werden sollte eine bestimmte Unit in Isolation zu testen muss von Fall zu Fall abgew gt werden Unit Tests K nnen Integrations oder Systemtests nicht ersetzen sie k nnen aber die Zahl der notwendigen Testf lle in diesen Phasen reduzieren Au erdem wird das Auf finden von Fehlerursachen durch das isolierte Testen von Klassen erheblich vereinfacht Der Fehler kann nur in der getesteten Klasse lokalisiert sein 5 1 2 Integrationstests Die Aufgabe von Integrationstests ist es das korrekte Zusammenspiel von Klassen oder Komponen ten sicherzustellen Normalerweise werden die Programmeinheiten schrittweise zu gr eren Einheiten zusammengesetzt um im Fehlerfall die Ursachen schneller auffinden und beheben zu k nnen F r die Richtung in welcher die Assemblierung stattfinden sollte l sst sich keine allgemein g ltige Empfehlung 48 5 AUTOMATISIERTES TESTEN geben Je nach Architektur kann sich ein Top Down Ansatz also von der Benutzerschnittstelle zur Ge
69. ern Dieses Ziel kann jedoch nur erreicht werden wenn das Testen in den Entwicklungsprozess integriert ist Der Programmierer muss also selbst zum Tester werden und die Teilergebnisse seiner Arbeit kontinu ierlich berpr fen Zun chst kostet die Testautomatisierung aber viel Zeit und Geld Sowohl KBPO1 als auch R 04 veranschlagen einen im Vergleich zu einer manuellen berpr fung zehnmal h heren Aufwand f r die Erstellung automatisierter Tests Zus tzlich m ssen die Tests w hrend der ganzen Ent wicklungszeit gepflegt werden nderungen und Erweiterungen des Programms oder neue Szenarien die ebenfalls gepr ft werden sollen bedingen eine Anpassung und Weiterentwicklung der Tests Die schnelle Reproduzierbarkeit der Testabl ufe kann die zus tzlichen Kosten allerdings schnell wieder rela tivieren Ist die Basisfunktionalit t der Software stets durch Tests abgesichert k nnen kritische Fehler oft fr hzeitig erkannt werden Das Risiko in sp ten Projektphasen noch schwerwiegende Fehler beseitigen zu m ssen kann durch das parallele Testen minimiert werden Die Automatisierung von Tests kann und soll die klassischen Methoden zur Sicherstellung der Korrekt heit von Software aber nicht ersetzen Die Modellvalidierung und Code Reviews durch das Entwick lungsteam adressieren andere Bereiche der Qualit tssicherung Ebenso wenig sollte bei gr eren Pro jekten auf eigenst ndige Tester oder eine Beta Version f r ein breites Testpublik
70. ert wird indem die L nge der n chsten Nachricht ausgewertet wird und dann aus den bereits empfangenen Bytes so lange Nachricht rekonstruiert und weitergeleitet werden bis neue Daten geladen werden m ssen Diese Implementierung ist effizienter als die der al ten Netzwerkbibliothek bei der auch bei der TCP bertragung Pakete fester L nge verschickt wurden Trotzdem besteht hier noch Optimierungspotenzial wobei der Programmcode aber schon in der eben beschriebenen Version trotz ausf hrlicher Kommentare schwer zu verstehen ist 4 3 UDP Weil die Kommunikationsbeziehungen zwischen den verschiedenen Modulen normalerweise von l nge rer Dauer sind also nicht auf wenige Aufrufe beschr nkt sind bot es sich an auch die UDP Implementier ung verbindungsorientiert zu gestalten Da es f r Sockets zur Datagramm Kommunikation aber keine Accept Methode gibt musste ihr Verhalten nachgeahmt werden Ein UdpNetworkServer wartet des halb auf ein Paket eines beliebigen UdpNetworkClient das ein bestimmtes Byte Muster CONNECTION_ REOUEST PATTERN enth lt Trifft es ein erstellt er einen neuen Socket und bindet ihn damit die ser vom Betriebssystem einen neuen Port zugewiesen bekommt Anschlie end wird ber den Accept Socket das CONNECTION REPLY PATTERN zusammen mit dem neuen Port an den Client gesendet Diese Bezeichnung steht verallgemeinernd f r SimpleUdpNetworkServer und RobustUdpNetworkServer entspricht aber keiner K
71. essageTest cs using System using System Collections Generic using System Text using System IO using odonet_cs using NUnit Framework namespace odonet_cs_test TestFixture public class MessageTest private Message message SetUp public void Setup this message new Message lt summary gt Tests everything which the constructors of the different message types have in common lt summary gt 79 Test public void BaseConstructorTest MemoryStream data MemoryStream TestHelper getField message data BinaryReader reader BinaryReader TestHelper getField message reader BinaryWriter writer BinaryWriter TestHelper getField message writer Assert IsNotNull data Assert IsNotNull reader Assert IsNotNull writer length and id field have been reserved and message type was written 12 3 x sizeof int Assert AreEqual 12 data Position check that length and id are initially set to 0 data Position data Seek 0 SeekOrigin Begin Assert AreEqual 0 message ReadInt 8 2 x sizeof int data Position data Seek 8 SeekOrigin Begin Assert AreEqual 0 message ReadInt lt summary gt Additionally tests if the type was set correctly lt summary gt Test public void OrdinaryMessageConstructorTest MessageType type MessageType TestHelper getField message type Assert AreEqual MessageTy
72. ests ben tigt werden Das Ziel dabei ist aber nicht im Voraus jeden einzelnen Testfall zu identifizieren sondern vielmehr m gliche Teststrategien aufzuzeigen die ein schnelles risikoorientiertes Testen der Software erm glichen Beim Unit Testing 5 1 1 ergeben sich die Testf lle aus den Methoden der zu testenden Unit die mit m glichst vielf ltigen Parameterkombinationen aufgerufen werden sollten Zuerst sollte immer der Best Case getestet werden In diesem Fall sind alle bergabeparameter vorhanden und besitzen g ltige Wer te M glicherweise empfiehlt es sich auch die minimal und maximal zul ssigen Werte f r bestimmte Parameter zu berpr fen Minimum Case und Maximum Case Im Error Case wird die Reaktion der Funktion auf fehlende oder ung ltige Werte getestet Ob es ausreicht die ffentliche Schnittstelle einer Klasse zu testen oder ob auch private Methoden berpr ft werden sollen ist unter Entwicklern umstritten Das Testen privater Methoden bedeutet zun chst einen Mehraufwand weil sie nicht direkt aufgerufen werden k nnen Bei C h lt sich dieser aber in Grenzen Die Sichtbarkeit der Methoden einer Klasse l sst sich leicht ndern weil nicht vor jeder einzelnen Deklaration angegeben wird ob die Methode ffentlich gesch tzt oder privat sein soll Statt dessen werden sie in der Header Datei zu Sektio nen die die Sichtbarkeit bestimmen zusammengefasst Die Schnittstelle einer Klasse kann dann e
73. fekt durch eine Implementierung bei der ein Broadcast Server die Antworten nicht selbst wieder an alle sondern auschlie lich an den Client sendet 3 2 2 Nachrichtenformat Die Hauptaufgabe der Nachrichtenklassen ist es Nachrichten so zu serialisieren dass sie ber das Netz werk bertragen und auf der Empf ngerseite wieder deserialisiert werden k nnen Auf Senderseite wer den Header und Payload Nutzdaten auf ein Byte Array abgebildet aus dem auf Empf ngerseite die Nachricht rekonstruiert wird Den Aufbau von Odonet Nachrichten zeigt Grafik 3 4 Der Header besteht aus je einem Integer Wert f r L nge Typ und Laufnummer der Nachricht Grunds tzlich h tten an Stelle von Integer Werten auch Short Werte ausgereicht Short ist jedoch ein plattformabh ngiger Datentyp 3 1 1 Den Wertebereich auf positive Werte einzuschr nken unsigned int ist nicht n tig weil die L nge einer Nachricht in der Praxis durch den verf gbaren Hauptspeicher beschr nkt ist L nge Typ Laufnummer Nutzdaten Abbildung 3 4 Nachrichtenformat 30 3 ENTWURF Da die L nge auf Empf ngerseite zun chst unbekannt ist muss sie mitgesendet werden Der Typ be stimmt die Nachrichtenklasse Neben der einfachen Nachrichtenklasse Message gibt es noch zwei weitere Klassen die Klasse ReturnMessage f r Antwortnachrichten und die Klasse Autoconnect Message f r den automatischen Verbindungsaufbau Die Klasse LargePacketMessage di
74. gten Mitarbeitern und Studenten die M glichkeit gegeben werden die Programmiersprache C und das Microsoft NET Framework zu nutzen C ist einfacher zu beherrschen als C weniger fehleranf llig und durchg ngig objektorientiert was einen sauberen objektorientierten Entwurf erleichtert Die umfangreiche Klassenbibliothek des NET Frameworks und das Microsoft Visual Studio Net 2003 2005 verringern die Entwicklungszeiten neuer Anwendungen Allerdings stellt die Entwicklungsumgebung f r die Programmierung in C nicht die selben Werkzeuge zur Verf gung wie f r die Programmierung in C So werden z B f r C noch nicht einmal grundlegendste Refactoringaufgaben wie das Umbenennen von Klassen oder Variablen unter st tzt Auch die automatische Anweisungsvervollst ndigung IntelliSense arbeitet beim Schreiben von C Code weniger komfortabel als beim Schreiben von C Code Ein weiterer Nachteil ist dass die automatische Generierung einer Dokumentation aus C Quellcode nicht von Visual Studio unterst tzt wird sondern externe Werkzeuge wie Doc oder Doxygen ben tigt werden Um Komponenten die in C implementiert sind in das Gesamtsystem zu integrieren ist eine Anpassung der Netzwerkkommunikationsschicht n tig Prinizipiell K nnte man dazu ohne allzu gro en Aufwand eine H llklasse in C schreiben die den Zugriff auf die bestehende C Bibliothek erlaubt Die Com mon Language Runtime von NET bietet dazu einen Mechanismus namens Pl
75. h tten sich viele Fehler bestimmt leichter lokalisieren lassen Die unterschiedlichen Werkzeuge f r C und C und die unvollst ndige Implementierung von Mono 2 0 stellten das Verh ltnis von Aufwand und Nutzen im Fall der Netzwerkbibliothek jedoch in Frage Soll eine Software aber auf eine Programmiersprache und eine Plattform beschr nkt bleiben lie en sich durch diesen Ansatz auch wenn er zun chst recht aufw ndig erscheinen mag vermutlich viele Debug Sessions sparen bertragen auf das isolierte Testen einzelner Module des verteilten Simulations und VR Systems k nnten Mock Objekte an Stelle der Ser verStubs verwendet werden um den gesamten Dienst einer Komponente nachzuahmen Ein neues Modul lie e sich so unabh ngig von anderen noch nicht implementierten oder potentiell fehlerhaften Modulen entwickeln und testen 65 6 Ergebnisse Die im Rahmen dieser Arbeit entstandene Middleware erm glicht es Simulations und VR Anwendungen ohne gro en Aufwand auf verschiedene Rechner zu verteilen Dazu k nnen hnlich wie beim Remote Procedure Call anwendungsspezifische Kommunikationsendpunkte generiert werden die es erm gli chen entfernte Funktionsaufrufe weitgehend wie lokale Funktionsaufrufe aussehen zu lassen Der Er stellungsprozess f r diese Kommunikationsendpunkte wurde gr tenteils automatisiert so dass sich aus der Schnittstellenbeschreibung in XML direkt die entsprechenden dynamischen Bibliotheken erzeugen lassen w
76. hohe Verz gerungen verursachen nicht tolerierbare zeitliche Diskon tinuit ten Die Daten bertragungsraten hingegen haben in lokalen Netzen mittlerweile ein sehr hohes Niveau erreicht so dass sich diese Gr e erst bei sehr gro en Nachrichten limitierend auf die Echtzeitf higkeiten des Systems auswirkt e Zuverl ssigkeit Wie schon in Met05 dargestellt wird die Zuverl ssigkeit der bertragung durch Korrektheit Reihenfolgetreue und Verlustrate bestimmt Es hat sich gezeigt dass f r das Simulations und VR System sowohl zuverl ssige als auch unzuverl ssige bertragungskan le w nschenswert sind Die Nachrichten des ControlCentres z B m ssen in jedem Fall zugestellt werden Wie schnell die bertragung stattfindet ist dabei zweitrangig Wenn dagegen die Simulation die absoluten Po sitionen und Rotationen der animierten Objekte an die Visualisierung schickt m ssen enge Zeit grenzen eingehalten werden Der Verlust einzelner Nachrichten ist dabei tolerierbar weil zeitnah neue Daten eintreffen werden e Multicasting Neben der einfachen Nachrichten bermittlung zwischen zwei Modulen muss es au erdem m glich sein Nachrichten auch an mehrere Module gleichzeitig zu schicken Generell k nnte man zwar dieselbe Nachricht nacheinander an alle Zielmodule senden serielles Unica sting aber mit steigender Nachrichtenlaufzeit und Empf ngerzahl driften die Empfangszeiten immer weiter auseinander Wenn echte Gleichzeitigkeit gefordert
77. ientStubConfig new NetworkConfigEntry NetworkConfigEntry serverStubConfig new NetworkConfigEntry select the first ClientStub and the first ServerStub and save its attributes allClientStubConfigObjects 0 Deserialize clientStubConfig allServerStubConfigObjects 0 Deserialize serverStubConfig this clientStub new SimpleClientStub clientStubConfig this serverStub new SimpleServerStub serverStubConfig region register server side delegates this setIntEventDelegate new SimpleClientStub SetIntEventDelegate clientStubTestHelper clientStub_SetIntEvent i clientStub SetStringArrayEvent new SimpleClientStub SetStringArrayEventDelegate clientStubTestHelper clientStub_SetStringArrayEvent i clientStub GetIntEvent new SimpleClientStub GetIntEventDelegate clientStubTestHelper clientStub_GetIntEvent i clientStub GetStringArrayEvent new SimpleClientStub GetStringArrayEventDelegate clientStubTestHelper clientStub_GetStringArrayEvent i endregion bool clientStubStarted clientStub Start bool serverStubStarted serverStub Start lt summary gt Realeases allocated resources by calling dispose on server and clientStub lt summary gt TestFixtureTearDown public void TestFixtureTearDown serverStub Dispose clientStub Dispose lt summary gt Creates 1 server and CLIENTCOUNT clients After the clients connected irstly all client
78. iese Erweiterung ist zwar nicht unverzicht bar schlie lich k nnte einfach eine weitere Testklasse mit anderen Setup und Tear Down Methoden definiert werden kompakter und zeitsparender ist sie aber in jedem Fall Ebenfalls praktisch ist das Repeat Attribut mit dem angegeben werden kann wie oft ein Test durchlaufen werden soll Bei der Alternative einer von Hand programmierten Schleife innerhalb der Testmethode ist zu beachten dass die Setup und Tear Down Methoden nur einmal vor und nach jedem Test vom Testrunner aufgerufen werden Zustandsbehaftete Objekte m ssen also innerhalb der Schleife erzeugt werden um die Forde rung nach den gleichen Bedingungen f r jeden Testdurchlauf nicht zu verletzen F r die Programmierung mit mehreren Threads gibt es die M glichkeit einen Test mit IsMultithreaded zu markieren Der Testrunner erzeugt dann transparent einen neuen Thread der den Test ausf hrt Deadlocks und andere Fehler die durch Nebenl ufigkeit entstehen lassen sich wegen der Wiederholbarkeit der Tests mit einer gr eren Wahrscheinlichkeit als bei manuellen Tests auffinden F r jeden Test l sst sich einstellen wie oft er durchlaufen werden soll und wie lange zwischen den einzelnen Durchg ngen pausiert werden soll Damit eignet sich Zanebug hervorragend f r Stresstests und Systemtests innerhalb komplexer Umgebungen bei denen auf andere Systemteile gegebenenfalls gewartet werden muss Mit diesen Eigenschaften ausgestattet bietet
79. ik der TU Dresden ein interaktiver Forschungs und Entwicklungssimulator f r mobile Arbeitsmaschinen in Betrieb genommen Gebaut wurde er von der EADS Dornier GmbH Friedrichshafen in Zusammenarbeit mit Mitarbeitern der TU Dresden Dabei entstand ein hochmodernes modulares Simulations und VR System Ein gro er Teil der verwendeten Software war allerdings nicht quelltextoffen was die Auswahl neuer Forschungs und Anwendungsgebiete stark begrenzte Deshalb wurde 2005 von Joscha Metze das verteilte Kommunikations und Visualisierungssystem ODO Object Oriented Distributed Open Framework vorgestellt Met05 Ziel der Arbeit war es den Grund stein f r ein flexibles VR System zu legen das h chsten Erwartungen an verschiedenste virtuelle Welten gerecht wird Der L sungsansatz war weitgehend unabh ngige Komponenten zu schaffen die Nach richten ber eine festgelegte Kommunikationsschnittstelle austauschen so dass bestehende und neu entwickelte Komponenten unterschiedlicher Plattformen zu neuen Gesamtsystemen kombiniert werden k nnen Der Schwerpunkt lag neben der Implementierung der Kommunikationsschicht auch auf der Entwicklung einer von der eigentlichen Simulation entkoppelten flexibel erweiterbaren Visualisierung die h chsten qualitativen Anspr chen gerecht wird Dieses Konzept wurde sp ter zu einem verallgemeinerten VR System erweitert NMW05 Durch den modularen Aufbau k nnen verschiedene Komponenten wie Datenbasis Visualisierung
80. in RPC D mon zum Ein satz rfcb Dadurch wird die Verteilung der Komponenten zwar v llig transparent auf der anderen Seite wird jede Anwendung dadurch von der Existenz eines Verzeichnisdienstes abh ngig Auf die Vertei lungstransparenz kann aber zugunsten der Einfachheit verzichtet werden da das Simulations und VR System normalerweise ein geschlossenes System unter der Kontrolle weniger Administratoren ist und es nicht prim r dazu gedacht ist dezentral zu arbeiten 24 3 ENTWURF Die Verwendung von XML bietet sich hier besonders an weil sich die Konfigurationdateien damit so wohl von Hand als auch aus einem Programm heraus erstellen oder bearbeiten lassen XML wird zwar schon l nger zur Konfiguration bestimmter Komponenten des Baggersimulators verwendet das Schema wurde jedoch komplett berarbeitet An Stelle des Formats von Joscha Metze mit dem ausschlie lich Netzwerkverbindungen und Visualisierungsparameter festgelegt werden konnten tritt eine generische Beschreibung mit der alle Module konfiguriert werden k nnen Eine Konfigurationsdatei Kann nach dem neuen Schema mehrere Sektionen beinhalten in denen Objekte mit ID und Typinformation enthalten sind Die ID ist als eindeutiger Name des Objekts zu vergeben Typinformationen sind je nach Anwendung vom Entwickler frei w hlbar und erlauben eine flexible Ka tegorisierung der Objekte Die eigentlichen Parameter werden den Objekten als Elemente mit Namen und Wert zugewiesen
81. inen Programmabsturz zur Folge haben Um dies zu vermeiden istes wenig sinnvoll alle Mechanismen von TCP nachzubilden denn oberhalb der Transportschicht wird man niemals die Effizienz von TCP erreichen k nnen Trotzdem sollte es eine Implementierung auf Basis von UDP geben mit der zumindest schwere Fehler vermieden werden k nnen Da UDP nicht wie TCP verbindungsorientiert sondern verbindungslos arbeitet jedes Paket also unab h ngig von anderen Paketen zugestellt wird ist es m glich ein Paket gleichzeitig an mehrere Empf n ger zu schicken Die Netzwerkbibliothek soll es erm glichen dass Broadcast Clients auch Anfragen an Broadcast Server stellen k nnen bei denen die schnellste Antwort als R ckgabewert genommen wird Dadurch kann es beim Broadcasting sogar noch leichter zu Problemen durch volle Empfangspuffer kom men Jeder NetworkPeer der Broadcast Nachrichten empfangen soll muss zun chst alle Nachrichten die er auf dem ihm zugewiesenen Port empf ngt entgegennehmen auswerten und an die n chsth here Schicht weiterleiten Versendet ein Broadcast Client Anfragen mit R ckgabewert an mehrere Broadcast Server und antworten diese ebenfalls ber Broadcast Nachrichten empf ngt jeder Server jede Antwort und muss sie verarbeiten ohne dass er an der Nachricht interessiert w re Dadurch f llen sich zum einen die Puffer zum anderen wird Rechenzeit verbraucht in der die Puffer geleert werden k nnten Vermie den werden kann dieser Ef
82. infach ver ndert werden indem mit dem Pr prozessor gesch tzte oder private Sektionen ffentlich gemacht werden Bei C hingegen w re eine bedingte Kompilierung aufw ndiger weil bei jeder Methode Code f r den Pr prozessor eingef gt werden m sste Alternativ dazu k nnte man das NET Reflection API benutzen um nicht ffentliche Methoden aufzurufen Wird bei der Kompilierung einer C Assembly angegeben dass sie Reflection unterst tzen soll wird sie mit Metadaten angereichert die es u a erm g lichen zur Laufzeit alle enthaltenen Methoden zu ermitteln und aufzurufen Diese Vorgehensweise ist allerdings sehr unpraktisch wenn viel Refactoring betrieben wird weil alle Reflectionmethoden Strings entgegennehmen die den Bezeichnungen der Eigenschaften Methoden oder Klassen entsprechen m s sen Werden diese Namen ge ndert m ssen auch alle bergebenen Strings angepasst werden Visual Studio 2005 bietet beim Umbenennen zwar an nach Zeichenketten zu suchen die von dieser nderung betroffen sein k nnten diese Suche ist aber nicht intelligent so dass immer noch Handarbeit f r den Pro grammierer bleibt Ein weiterer Grund gegen das Testen privater Methoden ist dass LA angenommen werden kann dass wenn beim Testen der ffentlichen Methoden einer Klasse keine Fehler auftreten wohl auch die privaten Methoden korrekt funktionieren miissen Der gro e Vorteil beim Testen privater Methoden ist allerdings dass eventuell auftretende Fehler
83. ion Markiert eine Methode bei deren Ausf hrung eine Ausnahme Excepti on erwartet wird Damit kann berpr ft werden ob Ausnahmen korrekt ausgel st und propagiert werden Ignore Deaktiviert einen Test Tabelle B 2 NUnit Attribute Auszug 91 Danksagung Mein Dank gilt neben meinem Betreuer Benjamin der immer Zeit f r ausgiebige Diskussionen und hilfreiche Ratschl ge fand auch besonders Stefan Spickereit f r die Unterst tzung bei der Entwicklung der XSLT Stylesheets und der Implementierung der Netzwerkbibliothek in C Weiterhin m chte ich mich bei meiner Freundin f r ihre Geduld und ihr Verst ndniss bedanken 92 Danksagung 93 Erkl rungen zum Urheberrecht Es wurden keine Texte oder Bilder bernommen 94 Erkl rungen zum Urheberrecht
84. ist der Begriff unzuverl ssige Kommunikation nicht mehr ganz zutreffend Werden bestimmte Rahmenbedingungen eingehalten kommen nahezu alle Pakete in der richtigen Reihenfolge beim Empf nger an Die maximal zul ssige Bitfehlerrate beim Gigabit Ethernet Standard z B liegt bei 1071 Sub Stati stisch kommt es also bei einer Paketgr e von 512 Byte erst nach 244 Millionen Paketen zu einem Fehler der dann durch den Cyclic Redundancy Check innerhalb der Transportschicht erkannt wird und letztlich in einem verlorenen Paket resultiert blicherweise gibt es in lokalen Netzen auch nur eine Route vom Sender zum Empf nger so dass auch UDP Pakete den Empf nger immer in der korrekten Reihenfolge erreichen Dramatischer kann sich das Fehlen der Fluss und berlaststeuerung auswirken Kommen beim Emp f nger mehr Pakete an als er verarbeiten kann gehen sie unweigerlich verloren Hiervon sind nicht nur die Kommunikationsendpunkte sondern auch dazwischen liegende Switches oder Router betroffen So lange eine Nachricht nicht auf mehrere Pakete verteilt werden muss ist das Resultat eines Paketver lusts lediglich ein Timeout auf den die Anwendung angemessen reagieren kann Gehen jedoch Teile einer Nachricht verloren kann es passieren dass nachfolgende Pakete falsch interpretiert werden was im schlimmsten Fall zum Absturz der gesamten Anwendung f hrt Beide Protokolle sollten mit der Netzwerkbibliothek nutzbar sein Die Zuverl ssigkeit
85. isual Studio auszuf hren Damit entf llt das Hin und Herwechseln zwischen Entwicklungsumgebung und Testwerkzeug was wiederum den Entwicklungsprozess beschleunigt Einzelne Testmethoden k nnen ber das Kontextmen des Tex teditors aufgerufen werden sollen mehrere Testklassen oder ganze Testprojekte durchlaufen werden geschieht das ber das Kontextmen des Solution Explorers Abbildung 5 3 a E odonet_cs_test_nunit a Properties H aj References H CA broadcast odonet_cs_test_nunit E Ey tcp SZ Za Properti GO Build 1 CoordinatorTestTcp cs H LS Referent E c LocalsimpleStubTestTcp cs ze Cg broadca Rebuild ee LocalSimpleStubTestTcottoid_cs EN 1 LocalStubTestTcp La tcp Run Test s A MessageTest cs Y Open Coverage Clean A SimpleClientStub cs i b Bedera Seda ita r Zanebug Project Dependencies E RoundTripTimeTest 3 view Code Project Build Order S View Class Diagram a Run Test s b Test With Abbildung 5 3 Kontextmenii TestDriven NET Neben dem RunTest s Eintrag gibt es noch den Men punkt Test With mit dem Tests mit dem Debugger durchlaufen werden k nnen Ist das Tool NCover nco installiert kann man ber dieses Men die Testabdeckung Code Coverage berpr fen ber das Kontextmen von Testprojekten k nnen au Berdem die unterst tzten externen Testwerkze
86. kPeers ableiten zu k nnen TCP bietet als zuverl ssiges Protokoll der Transportschicht die garantierte Zustellung und Reihenfolge treue von Nachrichten Erreicht wird dies durch die Retransmission von verloren gegangenen Segmenten und einer Flusssteuerung in Kombination mit einer berlastkontrolle congestion control Um die Zustellung sicherzustellen muss der Empf nger dem Sender mitteilen welche Segmente er emp fangen hat Bleibt eine solche Best tigung f r ein bestimmtes Paket f r eine l ngere Zeit aus wird es vom Sender neu bertragen Das Timeout Intervall wird dabei von TCP dynamisch an die bertragungs charakteristik der Verbindung angepasst Die Flusssteuerung erfolgt mit dem Schiebefensterprotokoll sliding window protocol Tan96 Die Schiebefenstergr e bestimmt die Anzahl der Pakete die der Sender versenden kann ohne dass er daf r vom Empf nger eine Best tigung erhalten hat Zus tzlich zu einer Mitteilung ber bereits empfangene Pakete wird dem Sender vom Empf nger mitgeteilt wie viele neue Daten dieser senden darf Diese Flusskontrolle ist notwendig weil ankommende Pakete verworfen werden m ssten falls die Empfangs puffer bereits voll sind Die Wiederholung von Paketen w rde in diesem Fall den Empf nger nur noch mehr berlasten Eng verbunden mit der Flusssteuerung ist die berlastkontrolle rfcf Aufgabe der berlastkontrolle ist es die Schiebefenstergr e zu optimieren Ist das Schiebefen
87. l und User Space gewechselt werden muss 33 4 Implementierung Bei der Umsetzung des Entwurfs sollte ber cksichtigt werden dass der Programmcode leichter zu lesen und zu warten ist wenn die Implementierungen f r C und C m glichst hnlich gestaltet werden Weil die C Version der Netzwerkbibliothek aber ohne eine zus tzliche Laufzeitumgebung Common Language Runtime bzw Mono Runtime einsetzbar sein soll kann nicht auf die umfangreiche Klassenbi bliothek des NET Frameworks zur ckgegriffen werden Statt dessen muss die Implementierung in C dem Standard folgen und nur Bibliotheken verwenden die f r beide Betriebssysteme verf gbar sind Dabei ist zu beachten dass das Lizensierungsmodell auch eine kommerzielle Nutzung gestattet aber nicht die Offenlegung des Quelltextes verlangt Beide Forderungen werden z B von der BSD Lizenz bsd und der LGPL lgp erf llt wobei die LGPL aber vorschreibt dass Ver nderungen an der durch sie gesch tzten Bibliothek publiziert werden m ssen Beim Einsatz von Low Level Netzwerkbibliotheken ist zudem zu beachten dass sie f r C und C zur Verf gung stehen sollten Bei der von der ersten Implementierung der Netzwerkbibliothek verwen deten HawkNL Hawk Network Library haw ist dies nicht der Fall Prinzipiell k nnte man diese Open Source Netzwerkbibliothek zwar trotzdem nutzen ihren urspr nglichen Zweck die Programmie rung zu vereinfachen erf llt sie dann jedoch nur noch bedingt
88. lasse der Implementierung und wird deshalb wie die folgenden verallgemeinernden Bezeichnungen auch nicht gesperrt gesetzt W rde die Verbindungsbest tigung ber den neu erzeugten Socket gesendet k nnte das zu Problemen mit Firewalls f hren 4 3 UDP 39 und ein entsprechendes PeerHandle mit Receive Thread zur clients Liste hinzugef gt Im Gegensatz dazu erstellt ein UdpNetworkClient einen neuen Socket sendet das CONNECTION_REQUEST_PATTERN und wartet auf das CONNECTION_REPLY_PATTERN und den neuen Port Trifft diese Benachrichti gung ein wird der auf Serverseite neu angelegte Socket mittels eines Connect Aufrufs als Default Ziel f r alle folgenden Send Operationen festgelegt Danach wird ein zugeh riges PeerHandle erzeugt und in die servers Liste aufgenommen Weil die Mechanismen zum Verbindungsabbau aber ebenfalls nicht fehlen d rfen wurde festgelegt dass ein leeres Paket als Indikator f r einen kontrollierten Ver bindungsabbau an den entfernten Kommunikationspartner gesendet werden soll so dass dieser darauf entsprechend reagieren kann F r die Kommunikation ber Datagramme gibt es zwei verschiedene Implementierungen SimpleUdp bestehend aus SimpleUdpNetworkServer SimpleUdpNetworkClient und SimpleUdp PeerHandle und RobustUdp bestehend aus RobustUdpNetworkServer RobustUdpNetwork Client und RobustUdpPeerHandle SimpleUdp ist die effizienteste Implementierung wenn aus schlie lich kurze Nach
89. le Aspekt im Design des Gesamtsystems ist die flexible Nutzbarkeit Eine Vielzahl von neuen Anwendungsfeldern Forschungsgebieten oder Technologien soll schnell und einfach erschlie bar sein e Skalierbarkeit Die M glichkeiten der Plattform auf der eine Anwendung l uft sollen optimal genutzt werden Zur Leistungssteigerung soll eine transparente Verteilung der Anwendung auf mehrere Rechner m glich sein e Heterogenit t Die Komponenten und damit auch die Kommunikation zwischen ihnen sollten auf unterschiedlichen Plattformen lauff hig sein e Synchronisation Da alle Komponenten unabh ngig von einander lauff hig sein sollten kann es zur Konkurrenz zwischen ihnen kommen Der Zugriff auf gemeinsame Daten muss synchronisiert werden e keine Diskontinuit ten Zeitliche oder rtliche Diskontinuit ten f hren zum Verlust der Immersion des Benutzers er wird an die Existenz der Maschine erinnert Drei weitere wichtige Anforderungen aus CDKO01 die f r verteilte Systeme jeder Art von Bedeutung sind wurden nicht explizit genannt e Transparenz Bestimmte Aspekte der Verteilung sollen dem Anwendungsentwickler verborgen bleiben e Fehlerbehandlung Jeder Prozess jeder Computer und jedes Netzwerk kann unabh ngig von den anderen Teilen des Systems Fehler verursachen Eine Komponente muss angemessen darauf rea gieren k nnen e Sicherheit Verf gbarkeit Vertraulichkeit und Integrit t m ssen gew hrleistet sein
90. len kann Neben blockierenden Funktionsaufrufen sollten aber grund s tzlich auch asynchrone Aufrufe m glich sein Weiterhin soll der Anwendungsentwickler festlegen k nnen welchen Wert eine Funktion zur ckgeben soll wenn ein Timeout aufgetreten ist Die Netzwerk schicht kennt die Bedeutung der R ckgabewerte nicht deshalb kann dort auch kein Fehlerwert festgelegt werden Zus tzliches Optimierungspotential k nnte durch die Unterst tzung von Multithreading erschlossen wer den Der Anwendungsentwickler k nnte dann synchrone Funktionsaufrufe mit R ckgabewert durch die Verwendung von mehreren Threads parallelisieren Dadurch lie en sich die Antwortzeiten verk rzen weil neue Anfragen bereits gestellt werden k nnten w hrend andere Threads noch auf ihre Antworten Nachrichtenlauf zeit Ausf hrungszeit gt warten n Aufrufe k nnen so maximal um den Faktor min 1 4 n beschleunigt wer den Aus der Formel ist ersichtlich dass wesentliche Verbesserungen nur m glich sind wenn die Lauf zeit im Verh ltnis zur Ausf hrungszeit Server Delay gro ist Typischerweise sind in einem LAN die Nachrichtenlaufzeiten aber relativ gering so dass in diesem Fall nur dann eine Verbesserung zu erwar ten ist wenn die Abarbeitung der Anfragen auf Serverseite sehr schnell geschieht und die Nachrichten relativ gro sind Das Minimum wird gebildet weil pro Aufruf maximal die Laufzeit eingespart werden kann 16 2 ANFORDERUNGSANALY
91. m ohne Konfigurationsdateien arbeiten zu k nnen Daraus resultierte jedoch eine starke Co deduplikation und damit letzlich ein erh hter Wartungsaufwand und eine zus tzliche Fehlerquelle Au Berdem ist es mit den einfachen Konsolen Testrunnern schwierig einzelne Tests auszuw hlen so dass sich die Konfiguration ber Dateien als sinnvoller erwiesen hat Damit wird nur eine Implementie rung der Testf lle ben tigt Welcher Transporttyp getestet werden soll wird vor der Testausf hrung ber Konfigurationsdateien festgelegt Um die Implementierung der einzelnen Testklassen m glichst einfach zu halten und auch dort Codeduplikation zu vermeiden wurden die Klassen Testhelper und SimpleStubTestHelper eingef hrt Die Klasse Testhelper vereinfacht u a den Zugriff auf Re flectionmethoden wohingegen ein SimpleStubTestHelper im Wesentlichen die Implementierun gen der Callback Methoden des SimpleClientStub enth lt Die Implementierungen der Schnittstelle des Kontrollzentrums wurde mit einfachen Anwendungen ge testet Im Hinblick auf den komplizierteren Entwurf mit Client und ServerStub f r jeden Kommunika tionspartner bei dem die Verbindungsverwaltung den Hauptunterschied zu den anderen Kommunikati onsendpunkten ausmacht ist eine eigenst ndige Anwendung die weniger aufw ndige L sung Au erdem stellen diese Testanwendungen prototypische Implementierungen f r das Kontrollzentrum dar die dann um den zus tzlich ben tigten Funktionsumfang er
92. mpleUdpServer lt attr gt lt attr name port gt 3000 lt attr gt lt attr name timeout gt 500 lt attr gt lt attr name autoconnect gt 0 lt attr gt lt attr name autoconnectport gt 4000 lt attr gt lt object gt lt object id SimpleServerStubSimpleUdp type ServerStub gt lt attr name name gt lt attr name type gt SimpleUdpClient lt attr gt lt attr name servernames gt localhost lt attr gt lt attr name port gt 3000 lt attr gt lt attr name timeout gt 500 lt attr gt lt attr name autoconnect gt 0 lt attr gt lt attr name autoconnectport gt 4000 lt attr gt lt object gt lt object id SimpleClientStubRobustBroadcast type ClientStub gt lt attr name name gt lt attr name type gt RobustBroadcastServer lt attr gt lt attr name servernames gt lt attr name localname gt localhost lt attr gt lt attr name port gt 3000 lt attr gt lt attr name timeout gt 1000 lt attr gt lt attr name autoconnect gt 0 lt attr gt lt attr name nodelay gt 0 lt attr gt lt attr name sendbuffersize gt 8192 lt attr gt lt attr name receivebuffersize gt 8192 lt attr gt lt object gt lt object id SimpleServerStubRobustBroadcast type ServerStub gt lt attr name name gt lt attr name type gt RobustBroadcastClient lt attr gt lt attr name servernames gt localhost lt attr gt lt attr name localname gt localhost lt attr gt lt attr name port gt 3000 lt attr g
93. muss ein NetworkConfigEntry Objekt meistens noch weitere Attribute wie Port oder Servername besitzen Au erdem gibt es eine Vielzahl an optionalen Attributen wie z B Default Timeout oder Socketpuffer gr en Um die Konfiguration der Netzwerkverbindungen von der verwendeten Netzwerktechnologie unabh ngig zu machen wurde das leere Interface INetworkConfigEntry definiert So kann bei Bedarf eine neue Implementierung zur Bibliothek hinzugef gt werden ohne dass Konstruktor oder Aufrufparameter bei den Stubs oder den internen Klassen der Kommunikationsschicht ge ndert werden m ssen 3 2 SCHNITTSTELLE ZUR TRANSPORTSCHICHT 25 An dieser Stelle soll nur eine sehr einfache Beispielkonfiguration Listing 3 2 gezeigt werden ein aus f hrlicheres Beispiel findet sich im Anhang Listing A 1 Details sind der Anwenderdokumentation zu entnehmen Listing 3 2 Einfache Konfigurationsdatei lt xml version 1 0 encoding utf 8 gt lt configuration name example configuration gt lt section id network gt lt a TCP server that listens for connections on port 3000 gt lt object id ExampleClientStub type NetworkServer gt lt attr name type gt TcpServer lt attr gt lt attr name port gt 3000 lt attr gt lt object gt lt a TCP client that connects to the server 141 76 71 139 gt lt object id ExampleServerStub type NetworkClient gt lt attr name type gt TcpClient lt attr gt lt attr
94. n k nnte Deshalb wurde ein neuer Entwurf erarbeitet der sich in den Grundz gen zwar noch an die alte Netzwerkkommunikationsschicht anlehnt die Benutzung aber vereinfacht und die Transportschicht austauschbar macht 3 1 Sicht auf die Kommunikationsschicht Wie in 2 4 festgestellt soll das Programmiermodell der Netzwerkommunikationsschicht an dem des Re mote Procedure Call angelehnt sein Um dieses Abstraktionsniveau zu erreichen muss es m glich sein die Schittstelle zur Kommunikationsschicht um anwendungsspezifische Funktionen zu erweitern Dazu sind Mechanismen erforderlich die aus der Beschreibung einer Funktion entsprechende Bibliotheken f r das Marshalling und Unmarshalling erzeugen k nnen 3 1 1 Anwendung anwendungsspezifische Bibliotheken ODONet Transportschicht Abbildung 3 1 Schichtenarchitektur Neben den exportierten Funktionen ist es f r den Anwendungsentwickler vor allem relevant wie er die Kommunikationsendpunkte konfigurieren und verwenden kann Bisher waren die Konfigurations 20 3 ENTWURF m glichkeiten stark eingeschr nkt daher musste ein flexibleres Konzept erarbeitet werden Die einfache Benutzung der alten Netzwerkbibliothek sollte durch eine Peer to Peer Architektur erm glicht werden in der Praxis Konnte sich dieser Ansatz aber nicht durchsetzen weswegen jetzt wieder ein einfaches Client Server System realisiert werden soll 3 1 2 3 1 1 Unterst tzte Funktionen und Da
95. nd return types are tested TestFixture public class LocalSimpleStubTest private SimpleClientStub clientStub private SimpleServerStub serverStub private SimpleStubTestHelper clientStubTestHelper private SimpleStubTestHelper serverStubTestHelper These delegates must be stored because the timeout test needs different callbacks than SetAndGetIntTest If NUnit provided a TestSetup attribute as Zanebug does that solution would be better private SimpleClientStub SetIntEventDelegate setIntEventDelegate private SimpleClientStub SetIntEventDelegate timeoutEventDelegate public LocalSimpleStubTest Logger AddListener new LogListenerConsole Logger Priority Warning true lt summary gt Creates server and client and registers the server side delegates used in the other tests lt summary gt 84 ANHANG A LISTINGS TestFixtureSetUp public void TestFixtureSetUp this clientStubTestHelper new SimpleStubTestHelper this serverStubTestHelper new SimpleStubTestHelper load config from file Configuration configuration new Configuration connection conf get all objects of type ClientStub from config file IList lt ConfigObject gt allClientStubConfigObjects configuration Select network ClientStub x IList lt ConfigObject gt allServerStubConfigObjects configuration Select network ServerStub x NetworkConfigEntry cl
96. nen die einen R ckgabewert erwarten angegeben werden Ein Default Fehlerwert kann nicht festgelegt werden weil die Kommuni kationsschicht die Bedeutung der R ckgabewerte nicht kennt Deswegen muss der Programmierer selbst daf r sorgen einen Fehlerwert zu finden der sich von regul ren R ckgabewerten unterscheidet ber das Attribut id wird ein anwendungsspezifisches Protokoll definiert das es erm glicht Funktionen und Nachrichten aufeinander abzubilden Diese Identifikationsnummer muss innerhalb einer Schnittstellen definition eindeutig sein F r gr tm gliche Flexibilit t sollten m glichst viele Datentypen bei der Definition der Funktionen erlaubt sein Die Evaluation der bestehenden Netzwerkkommunikationsschicht ergab jedoch dass die Verwendung der primitiven Datentypen short und long zu Problemen f hren wird sobald Prozesso rarchitekturen unterschiedlicher Wortbreite eingesetzt w rden Da an diesen Datentypen kein dringen der Bedarf besteht werden sie nicht weiter unterst tzt Es bleiben also byte int float double 3 1 SICHT AUF DIE KOMMUNIKATIONSSCHICHT 21 Listing 3 1 Einfache Schnittstellenbeschreibung lt xml version 1 0 encoding utf 8 gt lt messagetable name example interface gt lt a value for attribute error is mandatory if the returntype is different from void gt lt message name SetInt id 1 error ERROR gt lt returntype type string gt lt parameter type int
97. ngslos funktioniert 2 2 3 5 4 Testdurchf hrung Wie aus dem letzten Kapitel hervorgeht sind die meisten Tests nicht als Unit Tests sondern als Sy stemtests geplant Trotzdem k nnen die meisten Testf lle mit den in 5 2 vorgestellten Werkzeugen recht einfach realisiert werden F r die Tests in C ist jedoch zu beachten dass Zanebug gar nicht unter Mo 5 4 TESTDURCHF HRUNG 61 no lauff hig ist und NUnit nur in der Version 2 2 0 weit verbreitet ist Der aktuellen Version 2 4 Beta 1 wurde jedoch ein NAnt Build Script hinzugef gt mit dem sich ein NUnit Konsolen Testrunner f r Mono 2 0 erstellen l sst Das Fehlen eines graphischen Frontends l sst sich verschmerzen wenn daf r das Programmieren der Tests durch die neuen Assertions und Attribute erleichtert wird Um die Tests unter Windows sowohl mit NUnit als auch mit Zanebug das vor allem f r Last oder Performanztests interessant ist durchf hren zu k nnen m ssen die Testprojekte auf die NUnit Version 2 2 7 beschr nkt werden mit der Zanebug voll kompatibel ist Durch die Abw rtskompatibilit t der neueren Versionen k nnen die Testprojekte dann auch ohne nderungen unter Mono verwendet werden F r das Testen der C Version wird ebenfalls nur die einfache Konsolenl sung von cppUnit verwendet Alternativ w re noch eine Implementierung mit einer graphischen Benutzeroberfl che die auf der f r Windows und Linux verf gbaren Qt Bibliothek aufsetzen m sste in Frage gekomm
98. nwendungen sind blockierende Sockets aber das Mittel der Wahl weil die Programmierung mit Threads durch die sequentielle Abarbeitung der Socketaufrufe er heblich vereinfacht wird 4 2 TCP Die einfachste Implementierung der Schnittstelle zur Transportschicht stellen die Klassen TcpClient TcpServer und TcpPeerHandle dar Deshalb sollen auch die gemeinsamen Grundz ge der Funkti onsweise aller Implementierungen an dieser Stelle erl utert werden Wie bei den Implementierungen f r UDP oder Broadcast instanziiert der Coordinator in seinem Konstruktor je nach Konfiguration einen Client oder einen Server und registriert bei diesem eine Callback Funktion f r ankommende Nach richten ReceiveMessage Bei verbindungsorientierten NetworkPeers werden au erdem Callback Funktionen f r Verbindungsereignisse registriert Damit die NetworkPeers ihre Arbeit aufnehmen muss die Start Methode des Coordinators aufgerufen werden die dann entweder den Serverdienst startet oder die Verbindung zu allen in der Konfiguration angegebenen Servern aufbaut Alternativ zur stati schen Konfiguration der Verbindungen kann in der Konfigurationsdatei auch das Flag autoconnect F r die dazu notwendige bedingte Komplilierung m ssen die Pr prozessordefinitionen wIN32 bzw LINUX verwendet wer den Bei Anwendungen mit sehr vielen schnell wechselnden Clients beispielsweise bei einem Webserver kann die Verwendung asynchroner Sockets vorteilhaft sein 4
99. oubles message ReadDoubleArray Test public void WriteAndReadStringArrayTest string strings new string wenn du denkst du_denkst dann denkst du nur du denkst message WriteStringArray strings message SetReadPointerToBeginningOfPayload Assert AreEqual strings message ReadStringArray Test public void WriteAndReadMultipleValuesTest byte bytes new byte 0 112 110 255 82 ANHANG A LISTINGS float floats new float float Math PI float Math E OF 3 14F double doubles new double Math PI Math E OD 3 14D Double MaxValue Double MinValue Double Positivelnfinity message WriteByteArray bytes message Writelnt 12 message WriteFloat 0F message Writelnt Int32 MaxValue message WriteFloatArray floats message WriteDoubleArray doubles message SetReadPointerToBeginningOfPayload Assert AreEqual bytes message ReadByteArray Assert AreEqual 12 message ReadInt Assert AreEqual OF message ReadFloat Assert AreEqual Int32 MaxValue message ReadInt Assert AreEqual floats message ReadFloatArray Assert AreEqual doubles message ReadDoubleArray Test public void PackAndUnpackMessageTest message Writelnt 12314 message Writelnt 33432 message Writelnt 88 message Writelnt 44 message Writelnt 255 byte messageAsByteArray message Serialize Mess
100. pe DEFAULT type lt summary gt Additionally tests if the type was set correctly lt summary gt Test public void ReturnMessageConstructorTest Message dummyMessage new Message dummyMessage SequenceNumber 666 message new ReturnMessage dummyMessage MessageType type MessageType TestHelper getField message type int sequenceNumber int TestHelper getField message sequenceNumber Assert AreEqual MessageType RETURN type Assert AreEqual 666 sequenceNumber Test public void SetReadPointerToBeginningOfPayloadTest ANHANG A LISTINGS message Writelnt 12 message Writelnt 0 message Writelnt Int32 MaxValue message Writelnt 22 message Writelnt 924324 message Writelnt 12443434 MemoryStream data MemoryStream TestHelper getField message data message SetReadPointerToBeginningOfPayload 12 3 x sizeof int Assert AreEqual 12 data Position Test public void WriteAndReadByteTest message WriteByte 112 message SetReadPointerToBeginningOfPayload Assert AreEqual 112 message ReadByte Test public void WriteAndReadIntTest message Writelnt 12 message SetReadPointerToBeginningOfPayload Assert AreEqual 12 message ReadInt Test public void WriteAndReadFloatTest message WriteFloat 3 14152F message SetReadPointerToBeginningOfPayload Assert AreEqual 3 14152F me
101. pen auch die Serialisierung struktu rierter Daten in Strings der Form valuel value2 valueN beherrscht Bei der Deserialisie rung werden diese pipe separierten Strings dann wieder auf den passendsten Array Datentyp abgebildet Am Lehrstuhl f r Computergrafik wird diese Funktionalit t h ufig daf r verwendet um ber XML Dateien programmiersprachenunabh ngig Daten zwischen verschiedenen Anwendungen auszutauschen Ein Beispiel soll verdeutlichen wie diese Funktionalit t genutzt werden kann IStrings werden ASCII codiert Werden Zeichen aus einer 8 bit Erweiterung verwendet also z B deutsche Umlaute kann es abh ngig von der Plattform und den Lokalisierungseinstellungen zu Problemen kommen 22 3 ENTWURF primitive Datentypen Array Datentypen C C C C byte typedef byte unsigned charx byte std vector lt byte gt int int int std vector lt int gt float float float std vector lt float gt double double double std vector lt double gt string std string string std vector lt std string gt Tabelle 3 1 Unterst tzte Datentypen Der Anwendungsentwickler m chte einen dreidimensionalen Vektor doppelter Genauigkeit verschicken Dazu definiert er folgendene Funktion siehe auch 4 6 EPC void SendVector3D double vector C void SendVector3D std vector lt double gt Der Aufruf der Funktion k nnte dann wie folgt aussehen LP
102. pf ngerseite berpr ft werden Das letzte Paket einer Nachricht wird mit der Laufnummer 1 als solches markiert Bei Nachrichten die in ein einziges Paket passen w rden m ssen allerdings trotzdem zwei Pakete gesendet werden das erste Paket welches die Nachricht enh lt und ein zweites leeres Paket mit der Laufnummer 1 das das Ende der Nachricht markiert W rde schon das erste Paket mit der Laufnummer 1 gesendet k nnte es passieren dass es auf Empf ngerseite falsch interpretiert wird Wenn das abschlie ende Paket der vorherigen Nachricht auf Grund voller Empfangspuffer verloren gegangen ist wird die neue Nach 40 4 IMPLEMENTIERUNG richt als der noch fehlende Teil interpretiert was je nach Situation zu Nachrichten mit falschem Inhalt oder Socketfehlern f hren kann Eine Nachricht mit fehlerhaften Inhalt kommt genau dann zu Stande wenn die L nge des fehlenden Pakets mit der L nge des Pakets der neuen Nachricht bereinstimmt andernfalls kommt es auf Grund unerwarteter Datagramm Gr en zu Socketfehlern In den Stresstests siehe 5 4 machte sich der Verlust eines einzelnen Pakets in der Regel durch zwei bis drei aufeinanderfol gende Timeouts bemerkbar Abst rze oder Nachrichten mit falschem Inhalt wurden effektiv verhindert Der Grund f r diese Zeit berschreitungen ist dass der Sender nicht wei dass ein Paket verloren gegan gen ist und deshalb ungehindert Pakete sendet die der Empf nger so lange verwerfen muss bis e
103. pfangen und konsumiert wird und deshalb niemals beim eigentlichen Empf nger ankommt Aus diesem Grund muss ein Kommunikations teilnehmer auf unterschiedlichen Ports senden und empfangen wozu wiederum zwei Sockets ben tigt werden Damit bei der Konfiguration von BroadcastPeers nicht zwei Ports angegeben werden m ssen wurde festgelegt dass ein BroadcastServer auf dem Port aus der Konfigurationsdatei empf ngt und auf dem n chsth heren Port sendet wohingegen ein BroadcastClient auf dem Port aus der Konfiguration sendet und auf dem n chsth heren Port empf ngt Die Implementierung der Sende und Empfangsfunktionen f r das Broadcasting unterscheidet sich nur H n chsth herer Port Port 1 4 5 KONTROLLZENTRUM 41 unwesentlich von denen f r Udp wobei im Receive Thread bei der RobustBroadcast Implementierung f r jedes empfangene Paket zus tzlich berpr ft wird ob es von dem Sender stammt von dem das er ste Paket der aktuellen Nachricht entgegen genommen wurde Ist dies nicht der Fall wird das Paket verworfen damit es nicht passieren kann dass eine Nachricht aus den Paketen unterschiedlicher Kom munikationsteilnehmer zusammengesetzt wird 4 5 Kontrollzentrum F r die Kommunikation zwischen den verschiedenen Modulen und dem Kontrollzentrum wurden spezi elle Stubs geschaffen die allgemein als ControlCentreStubs bezeichnet werden Davon abgeleitet gibt es angelehnt an die Terminolgie der prototypischen Implementier
104. r Mutex nach dem beding ten Warteaufruf SDL_CondWait Timeout wieder manuell entsperrt werden Ein Server ClientStub hingegen kann keine Anfragen versenden und wird deshalb auch niemals auf Antwortnachrichten warten Statt dessen wird vom Coordinator die registrierte Callback Funktion die Methode ProcessIncomingMessage des zugeh rigen ClientStubs aufgerufen sobald eine Anfrage eintrifft Dort wird die Nachricht interpretiert und wiederum in einen Aufruf einer Callback Funktion umgesetzt Welche Funktion aufgerufen werden soll muss der Anwender nach der Instanziierung des ClientStubs festlegen Falls diese Funktion einen Wert zur ckliefert also nicht vom Typ void ist wird eine ReturnMessage erzeugt die ebenfalls der SendMessage Methode des Coordinators berge ben wird Dieser bildet den Aufruf in diesem Fall aber auf einen Aufruf der SendReturnMessage Methode ab bei dem zus tzlich zur zu sendenden Antwort das einzige Ziel der Nachricht berge ben wird Zur Umsetzung der Callback Mechanismen wurden in C Delegates verwendet die die einfache Definition typsicherer Funktionszeiger erlauben Bei der Implementierung in C sollten C Funktionszeiger vermieden werden Die Umsetzung mit typsicheren C Funktionszeigern war aber nicht m glich weil die Klasse die die Callback Funktion enthalten soll zum Zeitpunkt der Generie rung der angepassten Bibliotheken nicht bekannt ist Deshalb wurde die Bibliothek libsigc lib ver wendet mit
105. r wieder den Beginn einer neuen Nachricht empf ngt Weil der Puffer eines Sockets nach dem Verlust eines Pakets aber nicht einfach geleert werden kann sondern alle Datagramme zun chst entgegengenommen werden m ssen kann es eine Weile dauern bis der Empfangspuffer geleert ist so dass es passieren kann dass der Anfang nachfolgender Nachrichten verloren geht welche dann wiederum verworfen werden m ssen 4 4 Broadcast F r das Broadcasting von Nachrichten gibt es ebenfalls eine einfache SimpleBroadcast und eine robuste Implementierung RobustBroadcast Da die Kommunikation beim Broadcasting nicht verbindungsori entiert erfolgt werden keine Listen mit PeerHandles zur Repr sentation der entfernten Kommunikations partner ben tigt Statt dessen hat jeder BroadcastServer oder BroadcastClient ein BroadcastPeerHand le das sog receivePeerHandle ber dessen Socket der assoziierte Receive Thread Nachrichten entgegen nimmt und einen sog sendSocket ber den Nachrichten versendet werden k nnen Die Verwendung zweier Sockets ist zwingend notwendig wenn Antworten auf Broadcast Anfragen nicht wieder auf dem Broadcast Kanal gesendet werden sollen Selektive Antwortnachrichten m ssen ber einen SendTo Aufruf mit der Zieladresse als Parameter an den Socket bergeben werden Anders als beim Broadcasting wird ein gew hnliches UDP Paket aber vom ersten Empf nger aus dem Netz genom men so dass es passieren kann dass das Paket vom Sender selbst em
106. rache wie die zu testende Unit verfasst und zu sogenannten Test Suites zusammengefasst Meistens ist es g nstig pro Klasse eine Test Suite und pro Methode mindestens einen Testfall zu definieren Test Suite sollten wie derum zu Testprojekten zusammengefasst werden welche dann je nach Framework zu ausf hrbaren Konsolenprogrammen oder dynamischen Bibliotheken kompiliert werden k nnen Die einfachere Vari ante sind die Konsolenprogramme Sie beschr nken sich normalerweise auf das Ausf hren der Testf lle und eine einfache Ausgabe der Testergebnisse Komfortabler sind Testprogramme mit einer graphischen Benutzerschnittstelle bei denen die Tests als dynamische Bibliotheken geladen werden Um die Reproduzierbarkeit der Testergebnisse zu gew hrleisten muss ein Testframework daf r sorgen dass jeder Testdurchlauf unter m glichst gleichen Voraussetzungen statt findet Deshalb ruft der Testrun ner des Frameworks vor jedem einzelnen Test die Setup Methode der Testklasse auf mit der weitge hend gleiche Bedingungen geschaffen werden sollen Die Gesamtheit der Objekte die zum Ausf hren der Tests einer Testklasse ben tigt wird bezeichnet man als Test Fixture Damit alle Tests unabh ngig voneinander und in beliebiger Reihenfolge durchgef hrt werden k nnen sollte das Erzeugen und In itialisieren von Instanzen der zu testenden Klasse und eventuell ben tigter Hilfsklassen immer in der Setup Methode geschehen Manchmal ist es jedoch nicht n tig od
107. richt wird der Sender und damit das Ziel der Antwortnachricht im Feld ReturnMessageDestination der Nachricht gespeichert 36 4 IMPLEMENTIERUNG reitgestellten Sockets fungiert und so die Unterschiede bei der Socketprogrammierung unter Windows und Linux maskiert Ein weiterer Unterschied bei den Implementierungen in den unterschiedlichen Programmiersprachen ist dass alle C Klassen die zur Konfiguration verwendet werden sollen z B NetworkConfigEntry auf Grund fehlender Reflection F higkeiten von der Klasse lore Serializable abgeleitet wer den m ssen Dabei ist es erforderlich die Methoden LoadFrom lore ConfigObject und SaveTo lore ConfigObjectx geeignet zu berschreiben Bei der Implementierung aller NetworkPeers und PeerHandles wurden ausschlie lich blockierende block ing Sockets verwendet Die Kommunikation l uft dabei synchron ab was bedeutet dass der Aufruf ei ner Socketfunktion erst zur ckkehrt wenn die Operation abgeschlossen ist Im Gegensatz dazu findet bei nicht blockierenden non blocking Sockets die Kommunikation asynchron statt Alle Funktionsaufrufe kehren ohne R ckgabewert unmittelbar zur ck Sobald die Operation abgeschlossen ist und ein Ergebnis vorliegt wird dies ber ein Ereignis signalisiert und die entsprechende Callback Funktion aufgerufen blo Blockierende Sockets haben zu Unrecht einen schlechten Ruf der wohl noch aus Windows 3 x Zeiten herr hrt How F r die meisten A
108. richten versendet werden sollen und der Sender nicht schneller ist als der Emp f nger Die Puffer der Sockets m ssen dabei in jedem Fall mindestens so gro sein wie die eingestellte Paketgr e sonst kommt es unmittelbar zu einem Socketfehler Da in dieser einfachen Implementierung immer Pakete fester L nge versendet werden kann die bertragungsleistung optimiert werden indem die Konfiguration der beteiligten Stubs angepasst wird Wie gro die Nachrichten zur bertragung mit tels SimpleUdp sein d rfen l sst sich nicht allgemein festlegen Wenn eine Nachricht gr er ist als die eingestellte Paketgr e wird sie auf mehrere Pakete aufgeteilt die nacheinander zugestellt werden Mit steigender Senderate erh ht sich jedoch auch die Wahrscheinlichkeit eines Puffer berlaufs welcher un weigerlich Paketverluste zur Folge hat Wie in 3 2 1 schon beschrieben reichen die Konsequenzen eines Paketverlusts von der Zeit berschreitung bis hin zum Absturz der Anwendung Um diese Probleme zu entsch rfen ohne eine vollst ndige Fluss und berlastkontrolle wie bei TCP zu implementieren werden den Paketen bei RobustUdp zus tzliche Informationen hinzugef gt wobei die Pakete diesmal von variabler Gr e sind um den zus tzlichen Overhead zum Teil zu kompensieren Die Idee hinter RobustUdp ist Paketverluste zu erkennen und die betroffenen Nachrichten zu verwer fen Dazu werden den Paketen beim Senden fortlaufende Nummern gegeben die auf der Em
109. rreichen lose gekoppelten Code zu erzeugen und nderungen schnell zu integrieren New Oft kann eine Klasse ihre Aufgaben aber nicht ohne die Hilfe anderer Klassen erf llen Soll eine solche Klasse trotzdem unabh ngig von den anderen getestet werden k nnen die Instanzen der Hilfsklassen durch Stubs oder Mock Objekte ersetzt werden Stubs sind m glichst einfache Versionen dieser Hilfs klassen Sie implementieren zwar dieselbe Schnittstelle ihre Funktionen liefern normalerweise aber nur vordefinierte Werte zur ck Sie werden oft eingesetzt um Objekte zu ersetzen die schwierig zu erzeugen oder zu manipulieren sind Deshalb sind sie meist an den R ndern eines Systems zu finden wo sie Da tenbanken Webservices oder andere Dienste ersetzen Mock Objekte haben prinzipiell dieselbe Aufgabe wie Stubs werden aber anders benutzt Martin Fowler einer der Mitbegr nder des Extreme Program ming sieht den wesentlichen Unterschied zwischen Stubs und Mocks im Teststil den sie vorantreiben Fow W hrend bei den Stubs das zustandsbasierte Testen gef rdert wird wird durch Mock Objekte ein interaktionsbasierter Teststil unterst tzt Unit Tests sind in der Praxis meist zustandsbasierte Tests Eine Funktion eines Objekts wird aufgerufen und anschlie end wird berpr ft ob der zur ckgegebene Wert korrekt ist oder ob das Objekt den gew nschten Zustand angenommen hat Noch nicht so weit verbreitet ist der interaktionsbasierte Ansatz bei dem der Programmi
110. s will be disposed and after that the server will be disposed No exception shall occur lt summary gt Test public void DisposeClientsFirstTest const int CLIENTCOUNT 100 ArrayList clients new ArrayList CLIENTCOUNT NetworkConfigEntry clientStubConfig new NetworkConfigEntry clientStubConfig type TRANSPORTTYPES TcpServer clientStubConfig port 4321 NetworkConfigEntry serverStubConfig new NetworkConfigEntry serverStubConfig type TRANSPORTTYPES TcpClient serverStubConfig servernames new string localhost serverStubConfig port 4321 serverStubConfig timeout 25 SimpleClientStub simpleClientStub new SimpleClientStub clientStubConfig SimpleServerStub simpleServerStub try for int i 0 i lt CLIENTCOUNT i simpleServerStub new SimpleServerStub serverStubConfig clients Add simpleServerStub for int i 0 i lt CLIENTCOUNT i simpleServerStub SimpleServerStub clients i simpleServerStub Dispose simpleClientStub Dispose catch Exception test not passed Assert Fail lt summary gt Creates 1 server and 100 clients After the clients connected firstly the server will be disposed and after that all clients will be ANHANG A LISTINGS disposed No exception shall occur lt summary gt Test public void DisposeServerFirstTest const int CLIENTCOUNT 100 ArrayList clients ne
111. satz das die XSLT Transformation und die Kompilierung ausf hrt F r C wird zus tzlich eine kompilierte Hilfedatei chm generiert Abbildung 4 1 skizziert diese Verarbeitungskette 4 IMPLEMENTIERUNG batch file shell script NAnt interface definition XSLT processor source code compile amp link dynamic link library oc ef dependencies XSLT stylesheet Abbildung 4 1 Transformationspipeline 45 5 Automatisiertes Testen Automatisierte Tests spielen mittlerweile eine enorm wichtige Rolle bei der Qualit tssicherung von Soft ware Die klassische Pr fung der Fehlerfreiheit von Anwendungen durch Tester die oft erst nach der vollst ndigen Implementierung stattfindet ist angesichts der Komplexit t heutiger Anwendungen und Systemumgebungen nicht mehr ausreichend Durchschnittlich kommen auf 1000 Zeilen Programmcode mindestens zwei Fehler RS Um auch bei gro en Projekten deren Codebasis mehrere Millionen Zeilen umfassen kann die Anzahl der Fehler klein zu halten sind neue Strategien zur Qualit tssicherung notwendig Neben zahlreichen Verbesserungen bei den integrierten Entwicklungsumgebungen haben sich deshalb neue Testwerkzeuge und neue Vorgehens modelle bei der Softwareentwicklung etabliert Ziel der Testautomation ist es Fehler aufzudecken und die Suche nach ihren Ursachen zu erleicht
112. schneller lokalisiert werden k nnen Isolierte Unit und Integrationstests sind f r die Netzwerkbibliothek allerdings schwierig zu realisieren Denn was ist der Zweck einer Funktion wenn sie niemals aufgerufen wird 60 5 AUTOMATISIERTES TESTEN Durch die Schichtenarchitektur sind die meisten Klassen von anderen Klassen abh ngig Zwar k nnten Mock Objekte dazu verwendet werden an den Schnittstellen zwischen den Schichten die jeweils darun terliegende Schicht zu ersetzen mit Mock Objekten kann jedoch nur berpr ft werden ob die richtigen Funktionen mit den richtigen Parametern aufgerufen wurden Soll das Verhalten ber Threadgrenzen hin weg untersucht werden im Fall der Netzwerkbibliothek also z B nach dem Versenden einer Nachricht ber einen Ersatz NetworkClient auf das Eintreffen einer Antwort gewartet werden kann nicht mehr mit Mocking Frameworks gearbeitet werden Statt dessen m ssten manuell Ersatzimplementierungen Stubs geschaffen werden die auf eine ebenfalls eigens f r diesen Zweck implementierte Netzwerke mulation zugreifen Damit lie e sich ohne gro en Aufwand ein direkter Austausch von Nachrichtenre ferenzen mittels einer statischen Klasse realisieren Bei der Nachahmung komplexerer Aufgaben etwa dem Auf oder Abbau von Verbindungen oder der Emulation des Zeitverhaltens muss allerdings hin terfragt werden ob der dazu notwendige Aufwand noch in einem vern nftigen Verh ltnis zum Nutzen steht Da die
113. sollte Eingaben ignorieren eine Simulati on sollte nach dem aktuellen Simulationsschritt anhalten eine Visualisierung k nnte weiterlaufen oder einen Bildschirmschoner anzeigen Damit die Zustands berg nge ber das ControlCentre ausgel st werden k nnen ist zun chst eine globale Sicht auf das Gesamtsystem n tig d h die physische Verteilung aller beteiligten Module muss erfasst werden k nnen und jede Instanz muss einzeln adressierbar sein In einer statischen Konfiguration bei der jede Instanz immer auf dem selben Rechner ausgef hrt wird ist das nicht problematisch Mechanismen die die physische Verteilung in einer dynamischen Umgebung zur Laufzeit bestimmen k nnen fehlen jedoch in der bisherigen Implementierung der Netzwerkkommunikationsschicht Neben der globalen Sicht auf die eben definierten Ausf hrungszust nde sollte das ControlCentre auch ei ne globale Sicht auf Ausf hrungsfehler erm glichen Ohne eine zentrale Auswertung von Fehlern k nn te es aufw ndig sein am Gesamtverhalten des Systems festzustellen welche Komponente einen Fehler verursacht hat Um auch noch das Auffinden der Fehlerursachen zu erleichtern wurden die Fehlerstu fen debug info warning error und critical festgelegt und somit die Basis f r die zentrale Protokollierung der Aktivit ten aller Instanzen geschaffen Weiterhin soll das ControlCentre eine spezielle Scripting Schnittstelle anbieten mit der Scripts zur La
114. ssage ReadFloat Test public void WriteAndReadDoubleTest message WriteDouble 3 14152D message SetReadPointerToBeginningOfPayload Assert AreEqual 3 14152D message ReadDouble Test public void WriteAndReadStringTest message WriteString chanter alouette message SetReadPointerToBeginningOfPayload Assert AreEqual chanter alouette message ReadString Test public void WriteAndReadByteArrayTest 81 byte bytes new byte 0 112 110 255 message WriteByteArray bytes message SetReadPointerToBeginningOfPayload Assert AreEqual bytes message ReadByteArray Test public void WriteAndReadIntArrayTest int ints new int 0 1 2 Int32 MaxValue Int32 MinValue message WritelntArray ints message SetReadPointerToBeginningOfPayload Assert AreEqual ints message ReadIntArray Test public void WriteAndReadFloatArrayTest float floats new float float Math PI float Math E OF 3 14F hi message WriteFloatArray floats message SetReadPointerToBeginningOfPayload Assert AreEqual floats message ReadFloatArray Test public void WriteAndReadDoubleArrayTest double doubles new double Math PI Math E OD 3 14D Double MaxValue Double MinValue Double Positivelnfinity hi message WriteDoubleArray doubles message SetReadPointerToBeginningOfPayload Assert AreEqual d
115. ster zu klein wird die Bandbreite nicht voll ausgenutzt Ist es zu gro m ssen sehr viele Segmente zwischengespeichert werden um sie im Fehlerfall wiederholt bertragen zu k nnen Die Anpassung der Fenstergr e geschieht zun chst mit dem Slow Start Algorithmus Initial darf nur ein Segment bertragen werden Mit jeder Best tigung ber den erfolgreichen Empfang der zuletzt gesendeten Pakete wird die Schiebefenstergr e bis zu einem bestimmten Maximalwert meist 64kB verdoppelt Danach erh ht ein anderer Algorithmus die TCP berlastvermeidung congestion avoidance die Gr e des Fensters linear Wird das Timeout Intervall f r eine Best tigung berschritten beginnt der Slow Start Algorithmus von neuem und drosselt dadurch die Senderate 3Oft liest man im Zusammenhang mit der Uberlastkontrolle von einem Uberlastfenster congestion window Letzlich ist dies aber nur ein Wert der die aktuell nutzbare Schiebefenstergr e limitiert Deshalb soll Schiebefenstergr e hier immer das Minimum von Schiebefenstergr e und berlastfenstergr e bezeichnen 28 3 ENTWURF Im Gegensatz zu TCP bietet UDP weder die garantierte Zustellung von Paketen noch ihre Reihenfolge treue Auch Mechanismen zur Fluss und berlaststeuerung fehlen Der Verwaltungsaufwand ist jedoch geringer so dass gegen ber TCP kleinere Latenzen erreicht werden k nnen Beschr nkt man die Kom munikation jedoch auf lokale drahtgebundene Netze
116. t lt attr name timeout gt 1000 lt attr gt lt attr name autoconnect gt 0 lt attr gt lt attr name nodelay gt 0 lt attr gt lt attr name sendbuffersize gt 8192 lt attr gt lt attr name receivebuffersize gt 8192 lt attr gt lt object gt lt object id SimpleClientStubSimpleBroadcast type ClientStub gt lt attr name name gt lt attr name type gt SimpleBroadcastServer lt attr gt lt attr name servernames gt lt attr name localname gt localhost lt attr gt 75 lt attr name port gt 3000 lt attr gt lt attr name timeout gt 1000 lt attr gt lt attr name autoconnect gt 0 lt attr gt lt attr name nodelay gt 0 lt attr gt lt attr name sendbuffersize gt 8192 lt attr gt lt attr name receivebuffersize gt 8192 lt attr gt lt object gt lt object id SimpleServerStubSimpleBroadcast type ServerStub gt lt attr name name gt lt attr name type gt SimpleBroadcastClient lt attr gt lt attr name servernames gt localhost lt attr gt lt attr name localname gt localhost lt attr gt lt attr name port gt 3000 lt attr gt lt attr name timeout gt 1000 lt attr gt lt attr name autoconnect gt 0 lt attr gt lt attr name nodelay gt 0 lt attr gt lt attr name sendbuffersize gt 8192 lt attr gt lt attr name receivebuffersize gt 8192 lt attr gt lt object gt lt section gt lt configuration gt Listing A 2 Schnittstellenbeschreibung die
117. t attr name type gt TcpServer lt attr gt lt attr name port gt 3000 lt attr gt lt attr name timeout gt 500 lt attr gt lt attr name autoconnect gt 0 lt attr gt lt attr name autoconnectport gt 4000 lt attr gt lt object gt lt object id SimpleServerStubTcp type ServerStub gt lt attr name type gt TcpClient lt attr gt lt attr name servernames gt localhost lt attr gt lt attr name port gt 3000 lt attr gt lt attr name autoconnect gt 0 lt attr gt lt attr name autoconnectport gt 4000 lt attr gt lt object gt lt object id SimpleClientStubRobustUdp type ClientStub gt lt attr name name gt lt attr name type gt RobustUdpServer lt attr gt lt attr name port gt 3000 lt attr gt lt attr name timeout gt 500 lt attr gt lt attr name autoconnect gt 0 lt attr gt lt attr name autoconnectport gt 4000 lt attr gt lt object gt lt object id SimpleServerStubRobustUdp type ServerStub gt lt attr name name gt lt attr name type gt RobustUdpClient lt attr gt lt attr name servernames gt localhost lt attr gt lt attr name port gt 3000 lt attr gt lt attr name timeout gt 500 lt attr gt lt attr name autoconnect gt 0 lt attr gt lt attr name autoconnectport gt 4000 lt attr gt lt object gt 74 ANHANG A LISTINGS lt object id SimpleClientStubSimpleUdp type ClientStub gt lt attr name name gt lt attr name type gt Si
118. te Transporttypen 3 2 2 Nachrichtenformat 3 3 Kommunikationssteuerung 4 Implementierung 4 1 berblick und Unterschiede der Implementierungen in C und CF 10 11 11 14 16 19 19 20 22 23 25 27 29 30 4 5 Kontrollzentrum 2 30 aiem Te ea he he ee ia Ge o gu 4 6 Automatische Generierung benutzerdefinierter Bibliotheken 5 Automatisiertes Testen 3 1 Arten von Tests osassa anta Voda Ma dub dE AE Gg ananas Le SLL Unit Tests 2 4 2 2 8 2 deg DR ee 5 1 2 Integrationstests 9 1 37 SYStEMIESIS san Kit ee d rar ol b dara 3 2 Testwerkze ge tiva bee Sl o Naeh dt SA ue E a ik SL NUNIT is shed co a he dt guda ee Tg tu gat d a ie e EA AE ZANe BUS un au A E ga AE OE A rira ee a uga E EA 3 23 OO gr dg a ES a E TE E AE NES e AR 5 24 TestDriven NED ei a A EE bik ae 5 2 5 Visual Studio Team System 3 3 Testplan ng Zu diardu J ITE mauve AUD eugi ar Me UE der 5 4 Testdurchf hr ng 042 1052 A dd ee A Ta KE SAGU dgn al RO dr GE 5 3 Testergebnisse skn n ss E a e erea o 6 Ergebnisse 7 Ausblick Literaturverzeichnis A Listings B Tabellen 45 46 46 47 48 49 50 53 55 57 58 59 60 63 65 67 69 73 89 1 Einleitung Im Mai 2003 wurde am Institut f r F rdertechnik Baumaschinen und Logist
119. ten verschicken k nnen Die Beschr nkung auf das Versenden von Antwortnachrichten dient der strengeren Durchsetzung einer klaren Trennung von Client und Server rolle Initiator einer Kommunikation ist stets der Client Ein Server kann nur auf Anfragen reagieren niemals jedoch proaktiv Anfragen versenden Manche Anwendungen insbesondere das Kontrollzentrum siehe 2 2 3 m ssen informiert werden wenn eine neue Verbindung angenommen oder eine bestehende Verbindung beendet wurde Network Peers die verbindungsorientiert arbeiten m ssen daher das Interface IConnectionOriented imple mentieren und Abonennten ber Verbindungsereignisse informieren Die Parameter aller in diesen Interfaces definierten Funktionen und Ereignissen sind generisch Es wer den keine Annahmen ber die Transportschicht oder die verwendete Netzwerktechnologie getroffen so dass die Erweiterbarkeit auch jenseits von TCP IP und UDP IP sichergestellt ist 3 2 SCHNITTSTELLE ZUR TRANSPORTSCHICHT 27 3 2 1 Unterst tzte Transporttypen Wie in 2 3 dargestellt soll die Netzwerkschicht sowohl zuverl ssige als auch unzuverl ssige Kommuni kation erm glichen Das Transmission Control Protocol TCP und das User Datagram Protocol UDP scheinen daf r geeignet Zun chst soll verdeutlicht werden was Zuverl ssigkeit und Unzuverl ssigkeit im Kontext dieser Protokolle bedeuten um anschlie end die Anforderungen an die Implementierung der verschiedenen Networ
120. tentypen Wie beim RPC soll die Netzwerkkommunikationsschicht das Marshalling und Unmarshalling transparent machen so dass der Anwendungsentwickler Funktionen aufrufen kann ohne sich um das Zusammen stellen Versenden und Interpretieren von Nachrichten k mmern zu m ssen Dazu gibt es wie bisher die M glichkeit die Schnittstelle zur Netzwerkschicht durch die automatische Generierung spezialisierter Kommunikationsendpunkte zu erweitern Um diese schnell und einfach zur Verf gung stellen zu k n nen muss zun chst eine Schnittstellenbeschreibungssprache Interface Definiton Language festgelegt werden Der Programmierer spezifiziert damit die von ihm ben tigten Funktionen welche dann automa tisch in C oder C Quellcode bersetzt und anschlie end kompiliert werden siehe 4 6 Die bisher verwendete Interface Definition Language war nicht optimal deshalb wurde sie durch ein neues Schema ersetzt Durch die Verwendung von XML Attributen an Stelle von XML Elementen wird die Beschreibung einer Schnittstelle kompakter und l sst sich zudem einfacher parsen und bersetzen Ein kleines Beispiel soll die neue Schnittstellenbeschreibungssprache illustrieren Listing 3 1 Der Entwickler beschreibt also die Signatur der ben tigten Funktionen und optional einen Timeout Wert der angibt wie viele Millisekunden ein Aufruf dauern darf Liegt nach Ablauf dieser Zeit kein Ergeb nis vor wird der Fehlerwert zur ckgegeben Dieser muss f r alle Funktio
121. tung erfahren und sollen deshalb kurz vorgestellt werden Der Remote Procedure Call RPC ist die einfachste und lteste Variante rfcd rfce Ziel des RPC ist es entfernte Prozeduraufrufe wie lokale Prozeduraufrufe LPC aussehen zu lassen Dazu verpackt der Clientprozess die Aufrufparameter in Nachrichten die vom entfernten Serverprozess entgegenge nommen interpretiert und auf Funktionsaufrufe abgebildet werden Falls eine Antwort ben tigt wird sendet der Serverprozess auf die gleiche Weise eine Nachricht an den Client zur ck Die Umwandlung der Aufrufparameter in ein Nachrichtenformat wird als Marshalling bezeichnet die Interpretation der Nachrichten und das Abbilden auf Funktionsaufrufe hei t Unmarshalling F r den Anwendungsent wickler sind beide Prozesse transparent Urspr nglich lief ein entfernter Aufruf immer synchron ab d h der Client blockierte so lange bis er eine Antwort vom Server erhielt Diese Aufrufsemantik ist jedoch nicht immer angemessen deshalb kamen sp ter asynchrone Erweiterungen dazu so dass der Client Aufrufe absetzen kann ohne auf die Antworten warten zu m ssen Statt dessen werden Callback Funktionen definiert die vom RPC System 2 4 PROGRAMMIERMODELL UND AUFRUFSEMANTIK 15 aufgerufen werden sobald die Antworten eingetroffen sind Die wichtigsten Implementierungen des RPC sind ONC RPC Open Network Computing RPC auch SunRPC genannt und DCE RPC Distributed Computing Environment
122. tute of Electrical and Electronics Engineers Inc 1998 ISBN 0 7381 0174 5 KAPPLER Thomas Quality of Service und Internet Telefonie http www stud uni karlsruhe de uphr files Quality 200f 20Service 20und 20Internet Telefonie ausarbeitung html Universi tat Karlsruhe February 2003 KANER Cem BACH James PETTICHORD Bred Lessons learned in Software Testing 1 John Wiley amp Sons 2001 ISBN 0471081124 OPEN SOURCE INITIATIVE Hrsg GNU Lesser General Public License http www opensource org licenses lgpl license php SCHULZE Martin Hrsg CUMMING Murray Hrsg libsigc The Typesafe Callback Framework for C http libsigc sourceforge net MCCORMACK Sean Zanebug The development of an automated unit testing tool http linux sys con com read 105673 1 htm METZE Joscha Entwicklung eines Visualisierungssystems fiir Virtual Reality Simulationen 2005 MSDN Echtzeitverhalten von NET Compact Framework http www microsoft com germany msdn library net compact framework EchtzeitverhaltenVonNETCompactFramework mspx mfr true Microsoft April 2006 CODE MORTEM INC Hrsg NCover Code Coverage for NET http ncover org NEWMAN Sam Why unit tests are important http www magpiebrain com blog 2005 09 18 why unit tests are important NEIDHOLD Benjamin METZE Joscha WACKER Markus Towards a general concept for distributed visualisation of simulations in
123. uf zeit auf den Modulen abgesetzt und zur Ausf hrung gebracht werden k nnen Im Wesentlichen sollen damit Konfigurationsparameter wie z B die Aufl sung einer Visualisierungsinstanz manipulierbar ge macht werden Um die Administration einzelner Module aber auch ganzer verteilter Anwendungen zu vereinfachen wurde ein Konfigurationsmanagmentkonzept entworfen bei dem die Ausgangsparameter aller verwen deten Module in so genannten Workspaces organisiert sind Dazu wurde ein generisches Beschrei bungsformat definiert mit dem sowohl die Verteilung siehe auch 3 1 3 als auch die komponentenspe zifischen Konfigurationsparameter festgelegt werden k nnen Da das ControlCentre das einzige Modul ist welches eine globale Sicht auf das gesamte System hat muss es zudem das Workspacemanagement ber die Scripting Schnittstelle bernehmen Abbildung 2 4 soll die Aufgaben des ControlCentres noch einmal zusammenfassen 2 2 4 Verteilte Simulation Grunds tzlich soll die beliebige Verteilung der Instanzen einer Simulations und VR Anwendung auf eine variable Anzahl von Rechnern m glich sein In der Praxis wurden bisher mehrere Visualisierungen auf mehrere Standard PCs verteilt um so die h chstm gliche visuelle Qualit t zu erreichen Theore 2 3 ABGELEITETE ANFORDERUNGEN AN DIE KOMMUNIKATIONSSCHICHT 11 Host Input Host ControlCentre Input DirectinputMapper
124. uge aufgerufen werden die dann automatisch die neueste Version der zugeh rigen Bibliothek bergeben bekommen Abbildung 5 3 b Diese Information findet sich auf der Website aber gar nicht mehr so leicht tesb 58 5 AUTOMATISIERTES TESTEN 5 2 5 Visual Studio Team System Microsoft bietet mit dem Visual Studio Team System vis eine umfangreiche Sammlung von Werkzeu gen f r das Visual Studio 2005 an Neben der sehr teuren Visual Studio Team Suite ca 12000 die die Entwicklungsumgebung und alle Werkzeuge umfasst gibt es Pakete die speziell auf die Bed rfnisse von Softwarearchitekten entwicklern oder testern zugeschnitten sind und jeweils nur eine Teilmenge aller Features enthalten F r den stolzen Preis von 6000 bekommt der Software Tester Werkzeuge mit denen sich mit minimalem Aufwand Unit Tests Tests f r Webanwendungen Lasttests oder generische Tests f r externe Anwendungen erstellen und durchf hren lassen Prinzipiell besteht die M glichkeit all diese Tests auch mit frei verf gbaren oder g nstigeren Tools von Drittanbietern durchzuf hren Der wesentliche Vorteil der Microsoft L sung ist aber dass alles aus einem Guss ist und deshalb eine h here Produktivit t erreicht werden kann Konfigurations oder Kompatibilit tsprobleme wie sie bei den Werkzeugen verschiedener Hersteller auftreten k nnen werden so vermieden 5 3 TESTPLANUNG 59 5 3 Testplanung Die Testplanung soll kl ren welche T
125. um verzichtet werden Au enstehende haben oft eine andere Herangehensweise und andere Erwartungen als die Programmierer so dass von ihnen ganz andere M ngel wahrgenommen und wertvolle Verbesserungsvorschl ge gemacht 46 5 AUTOMATISIERTES TESTEN werden k nnen 5 1 Arten von Tests Die Popularit t von automatischen Tests ist in den letzten Jahren enorm gestiegen Das h ufig disku tierte Vorgehensmodell des Extreme Programming d rfte dazu einen gro en Teil beigetragen haben Viele Praktiken des Extreme Programming wie z B das Refactoring und die kontinuierliche Integration Continous Integration sind erst mit automatisierten Tests effizient durchf hrbar F r die Testgetriebene Entwicklung Test Driven Development bilden sie sogar die Grundlage Allerdings werden Automa tisiertes Testen und Unit Testing f lschlicherweise oft synonym verwendet weshalb dieses Kapitel Unit Tests von anderen Testarten abgrenzen soll 5 1 1 Unit Tests Ein Unit Test ist ein automatisierter Test der einzelne Programmeinheiten auf funktionale Korrektheit und Vollst ndigkeit pr ft Wie gro diese Programmeinheiten sein d rfen ist unter Experten umstritten G ngige Praxis ist dass f r jede zu testende Klasse eine Testklasse erstellt wird Die traditionelle Defini tion von Unit Tests fordert au erdem dass nur eine einzige Klasse in Isolation von allen anderen getestet wird Beu Diese Forderung wird von den Programmierern aber m
126. ung des Kontrollzentrums von Benny Wegener die Klassen Cont rollerStub und InstanceStub Ein InstanceStub wird auf Seite des Kontrollzentrums verwendet um eine bestimmte Instanz einer Komponente anzusprechen Mit einem ControllerStub k nnen Komponenten Nachrichten an das Kontrollzentrum schicken Die erste Schwierigkeit bei der Implementierung bestand darin dass beide Arten von Stubs proaktiv Nachrichten versenden Clientrolle ebenso aber auch Anfragen beantworten k nnen m ssen Server rolle was die strenge Unterscheidung von Client und Server aber nicht erlaubt siehe 3 1 2 Damit nicht bei jeder Komponente zwei Stubs f r die Kommunikation mit dem Kontrollzentrum instanziiert und kon figuriert werden m ssen wurde eine Sonderl sung geschaffen so dass jeder ControlCentreStub gleichzeitig als Client und als Server agieren kann Intern arbeitet jeder ControlCentreStub dazu mit zwei Coordinatoren einer mit einem TcpNetworkServer einer mit einem TcpNetworkClient Werden Funktionen des ControlCentreStub aufgerufen sendet der Client Coordinator die resul tierenden Anfragen an den entfernten ControlCentreStub Ankommende Anfragen werden vom Server Coordinator in Aufrufe der registrierten Callback Funktion umgesetzt Die zweite Anforderung die schwierig umzusetzen war ist dass das Kontrollzentrum die physische Ver teilung aller laufenden Module erfassen und jedes Modul einzeln ansprechen k nnen muss Eine stati sche Konfiguration der V
127. von TCP wird immer dann ben tigt wenn der korrekte Empfang der Nachrichten wichtiger ist als die Geschwindig keit mit der sie zugestellt werden Zu dieser Nachrichtenklasse geh ren z B die Steuernachrichten des Kontrollzentrums oder Daten die differentiell bertragen werden und damit von allen vorangehenden Daten abh ngen Die differentielle Daten bertragung ist immer dann unumg nglich wenn eine ber tragung der gesamten Daten zu langsam w re Ein Beispiel hierf r ist das Baggern mit dem Baggersi mulator Die nderungen am Terrain m ssen f r den Benutzer sofort sichtbar sein ein hochaufgel stes Mesh umfasst jedoch mehrere Megabyte so dass selbst eine Gigabit Ethernet Verbindung schnell an ih re Grenzen st t wenn entsprechend viele Simulationsschritte pro Sekunde durchgef hrt werden sollen Obwohl die Zuverl ssigkeit bei dieser Nachrichtenklasse wichtiger ist als die Laufzeit sollte die Imple mentierung nat rlich trotzdem die bestm gliche Performanz bieten So w ren z B durch konfigurierbare Socket Puffergr en mit wenig Aufwand erhebliche Leistungssteigerungen bei der Kommunikation ber ein Wide Area Network WAN m glich UDP hingegen ist immer dann sehr gut geeignet wenn der Verlust einzelner Nachrichten tolerierbar ist 3 2 SCHNITTSTELLE ZUR TRANSPORTSCHICHT 29 die Zustellung aber so schnell wie m glich ablaufen soll Nicht tolerierbar sind dagegen falsch interpre tierte Nachrichten oder Ausnahmen die e
128. w ArrayList CLIENTCOUNT NetworkConfigEntry clientStubConfig new NetworkConfigEntry clientStubConfig type TRANSPORTTYPES TcpServer clientStubConfig port 4321 NetworkConfigEntry serverStubConfig new NetworkConfigEntry serverStubConfig type TRANSPORTTYPES TcpClient serverStubConfig servernames new string localhost serverStubConfig port 4321 serverStubConfig timeout 25 SimpleClientStub simpleClientStub new SimpleClientStub clientStubConfig SimpleServerStub simpleServerStub try for int i 0 i lt CLIENTCOUNT i simpleServerStub new SimpleServerStub serverStubConfig clients Add simpleServerStub simpleClientStub Dispose for int i 0 i lt CLIENTCOUNT i simpleServerStub SimpleServerStub clients i simpleServerStub Dispose catch Exception test not passed Assert Fail lt summary gt This test is abusing the SetInt method for testing timeout behavior because the signature fits best The first parameter is an integer which will be returned unmodified by the server side delegate The second parameter is an integer which will tell the server thread how long it shall sleep Zr The test first assures that the test setup works correctly by sending 87 a message telling the server not to sleep After that a message is sent to the server telling it to sleep for 500 ms which is the
129. weitert werden k nnen 5 5 Testergebnisse Durch das automatisierte Testen der Netzwerkbibliothek konnten Fehler gefunden und eleminiert wer den die von manuellen Tests vermutlich gar nicht erfasst worden w ren Vor allem Fehler die durch Nebenl ufigkeiten im Programmfluss entstehen sind durch herk mmliche Testmethoden kaum repro duzierbar Durch wiederholte Stresstests konnten Synchronisationsfehler und Probleme beim Freigeben von Ressourcen provoziert werden die unter Normalbedingungen nur u erst selten entstehen w rden deren Auswirkungen aber bis zum Absturz der Anwendung reichen k nnen 64 5 AUTOMATISIERTES TESTEN Die Lokalisierung dieser Fehler war aber trotz zahlreicher aussagekr ftiger Debug Ausgaben im Pro grammcode der Netzwerkbibliothek oft sehr schwierig Um das Zusammenspiel des Hauptthreads mit den Empfangsthreads beim Debuggen einigerma en kontrollieren zu k nnen sind mehrere Debugger Instanzen unverzichtbar am besten sogar auf unterschiedlichen Rechnern Erschwerend kamen beim De buggen der Netzwerkbibliothek noch die Zeit berschreitungen hinzu so dass die Konfiguration je nach Situation angepasst werden musste In jedem Fall erfordert die Suche nach Multithreading bedingten Fehlern eine genaue Kenntnis des Programmcodes damit einzelne Debug Schritte immer in einer sinn vollen Reihenfolge ausgef hrt werden k nnen Durch die Verwendung eines Mocking Frameworks zum isolierten Testen einzelner Units
130. wurden verschiedene Testprojekte f r die verschiedenen Programmiersprachen angelegt je eines f r lokale Tests und je ein Client bzw Server projekt f r entfernte Tests In den lokalen Testprojekten finden sich neben den Unit Tests Systemtests bei denen ein lokaler Server und ein lokaler Client erzeugt werden die dann ber das Loopback Device miteinander kommunizieren Bei den Testprojekten f r entfernte Tests wird entweder ein Server oder ein Client erzeugt Die Serverprojekte beinhalten allerdings gar keine Testf lle Es wird lediglich ein Server erzeugt der eingehende Anfragen bearbeitet Die eigentlichen Tests finden in den Clientprojekten statt Dort wird zun chst ein Client mit einem vorher gestarteten Server verbunden Anschlie end werden vom 62 5 AUTOMATISIERTES TESTEN File View Help leBnale 23 pz OIS SISA ET Coveraged xml 2 3 ed Lore20 0 YReadByte 100 G odonet_cs 4 E odonet_cs 4 VReadByte rray 100 4 ReadDouble 1 100 3 YReadDoubleArray 100 11 YReadFloat 100 4 YReadFloatArray 100 11 GReadint 100 3 GReadint rray 100 11 ReadString 100 5 ReadStringArray 100 LR sequenceNumber 100 SSerialize 100 YSetReadPointerToBeginningOfPayload 12 100 andle 0 Oy Message 94 Ag rkConfigEntry 0 9 get return sequenceNumber Ag tException 0 30 set seguenceNumber value 4 ReturnMessage 100 3 ob a protected AbstractPeerHandle returnMessageDestination public

Belegarbeit ( - 5.3 MB) - Technische Universität Dresden

Contents

Download Pdf Manuals

Related Search

Related Contents

Belegarbeit ( - 5.3 MB) - Technische Universit&auml;t Dresden

Contents

Download Pdf Manuals

Related Search

Related Contents

Belegarbeit ( - 5.3 MB) - Technische Universität Dresden