Simona Jammer, Helmut Vaschauner, Marko Keuschnig. Adaptive Streaming and Telecontrolling of a car like robot

Größe: px
Ab Seite anzeigen:

Download "Simona Jammer, Helmut Vaschauner, Marko Keuschnig. Adaptive Streaming and Telecontrolling of a car like robot"

Transkript

1 Simona Jammer, Helmut Vaschauner, Marko Keuschnig Adaptive Streaming and Telecontrolling of a car like robot GUI Design, Streaming Control, Control of robot Bakkalaureatsarbeit zur Erlangung des akademischen Grades Bakkalaureus der technischen Wissenschaften Angewandte Informatik Universität Klagenfurt Fakultät für Wirtschaftswissenschaften und Informatik Begutachter: Univ.-Prof. Dr.-Ing. Kyandoghere Kyamakya Institut: Institut für Intelligente Systemtechnologien 22. März 2010

2

3 Inhaltsverzeichnis Inhaltsverzeichnis Tabellenverzeichnis iii v Abbildungsverzeichnis viii 1. Einleitung Motivation Ziel Aufgabenstellung Client Anzeige für Videostream Steuerungselemente Kamera Statusanzeige Software für Roboter Übertragung der Daten via WLAN Technologien Entwicklungsumgebungen Eclipse Netbeans Borland JBuilder Projektmanagement Subversion Programmiersprachen Java C Video Streaming Java Media Framework (JMF)

4 ii Freedom for Media in Java (FMJ) Java Media Components (JMC) Adobe Flash Java Binding for VLC (JVLC) Datenübertragung Local Area Network (LAN) Serielle Übertragung (RS-232) Speicherung Extensible Markup Language (XML) Datenspeicherung mit Java Protokollierung Java Logging API Jakarta Log4J GUI Librarys substance - look and feel library forms - swing layout manager Hardware Roboter MOMO Racing Force Feedback Wheel Kameras Projektplanung Softwareentwicklungsprozess Inception Phase Elaboration Phase Construction Phase Transition Phase Iterativer Ansatz Statische Struktur Architektur im RUP Aufteilung in Module Multimedia Windows Multimedia Linux De- und Encodierung GUI Windows Kommunikationskanal Robotersteuerung Meilensteine Meilenstein Meilenstein Meilenstein

5 Inhaltsverzeichnis iii 4.4 COCOMO - Aufwandabschätzung Organic Mode Semi-Detached Mode Embedded Mode Aufwandberechnung Zeitmanagement Risikoanalyse Ticketsystem Implementierung Client Client Layout Keyboard and Mouse Control JVLC Panel Streaming External Player Server Installationsanleitung und Verwendung Anforderung Betriebssysteme Java Kameras VLC Media Player DAO-Communications Library Server Installation Aufbau Client JSmooth NSIS Ausblick Literaturverzeichnis A. Abkürzungsverzeichnis

6 iv Inhaltsverzeichnis

7 Tabellenverzeichnis 3.1 Stringrepräsentation Zellenkonstanten Stringrepräsentation Kriterien der Modi Koeffizienten COCOMO Koeffizienten für Aufwand und Dauer Risikoelement Projektausfall Risikoelement Know-How Risikoelement Studiumwechsel Risikoelement Motivation Risikoelement Aufgabenverteilung Risikoelement Aufgabendefinition Risikoelement USB-Treiber Risikoelement Datenrate USB-Bus Risikoelement Robotersteuerung

8 vi Tabellenverzeichnis

9 Abbildungsverzeichnis 1.1 DAO-Roboter Subclipse Views (a) Repository Browser (b) Synchronisation View Störende Artefakte bei zu geringer Bandbreite Überblick über die Architektur des Java Media Frameworks Zustände und Zustandsübergänge eines Controllers VideoLan Streaming Solution [Vid06] Kommunikationskanal Schichtenarchitektur von RMI RMI: Elemente und Ablauf Konfigurationspanel der Clientanwendung Forms Beispiel Logitech Lenkrad QuickCam R Pro for Notebooks RUP Modell [IBM07] RUP Phasen [IBM06] Use Case Design-Entwurf GUI RUP Iterativer Ansatz [IBM03] RUP Artefakte[Cor03b] RUP Sichten[Cor03a] Meilenstein Meilenstein Meilenstein COCOMO Aufwandschätzung in den Phasen [Mau02] COCOMO Zeitschätzung in den Phasen [Mau02] Beispiel Ticketsystem Beispiel SVN-Commit Events

10 viii Abbildungsverzeichnis 5.1 Klassendiagramm der Oberfläche Screenshot des Client mit Videos Konfigurationsdialog (a) Konfiguration der Videoquellen (b) Server Einstellungen (c) Gemeinsame Konfiguration External Player Ausschnitt des Registry Editors VLC Media Player VLC - Dialogfenster für Geräteauswahl Inhaltsverzeichnis der Serversoftware Oberfläche der Serversoftware Übersicht der einzelnen Menüpunkte JSmooth Anwendung

11 1 Einleitung Das Institut für Informatik-Systeme, Forschungsgruppe für Verkehrsinformatik, arbeitet momentan gemeinsam mit dem Institut für Informationstechnologie an der Entwicklung eines fahrenden Roboters ( car-like robot ), genannt DAO (siehe Abbild 1.1). Dieser Roboter soll mit Kameras ausgestattet werden, welche Videos aus seiner direkten Umgebung an einen entfernten Rechner schickt. Die Videos sollen über ein Funknetzwerk (WLAN) per Streaming in Echtzeit übertragen werden und dadurch am zentralen Rechner als Hilfe für die entfernte Steuerung des Roboters dienen. 1.1 Motivation Dem Benutzer soll es ermöglicht werden, den Robotor aus der Ferne zu steuern, zu überwachen sowie verbale und bildhafte Kommunikation mittels diesem Roboter zu betreiben. Für die Überwachung sendet der Roboter über ein Wireless Lan vier Kamerabilder zum Client des Benutzers. Durch die übertragenen Bilder kann sich der Benutzer einen Überblick der Umgebung machen und den DAO-Roboter daraufhin steuern. In Zukunft soll der Roboter durch die entfernte Steuerung und die mitgelieferten Umgebungsbilder dem Benutzer kleine Wege und Aufgaben ersparen. Als Ansporn galt der Postweg. So soll es möglich sein, durch die Steuerung zur Poststelle zu fahren und die Post abzuholen, ohne sich dabei als User nach draußen zu bewegen. 1.2 Ziel Insgesamt sind am Roboter vier Kameras angebracht. Diese Kameras nehmen die vier Blickrichtungen des Roboters auf. Alle vier Kameras senden zu jeder Zeit gemeinsam die Videobilder zum Client. Da es durch die gemeinsame

12 2 Kap. 1: Einleitung Übertragung der Videokameras zu Engpässen im Netzwerk kommen kann, wird die Qualität (Auflösung, Farbtiefe, Komprimierungsfaktor) gegebenenfalls soweit eingeschränkt, dass es zumindest zu einer flüssigen Übertragung kommt. Zur Kommunikation steht ein Videokanal von der Kamera des Clients zum Display des Roboters, sowie ein beidseitiger Audiokanal zur Verfügung. Dem Benutzer soll es möglich sein, eines der Kamerabilder genauer zu betrachten. In diesem Fall wird das ausgewählte Kamerabild so detailreich wie nur möglich übertragen. Die Übertragung der übrigen drei Kameras bleibt dabei bestehen, jedoch eventuell mit einer weiteren Einschränkung der Übertragungsqualität. Damit der Benutzer den Roboter auch steuern kann, werden über die Cursor-Tasten des Clients Steuerungsbefehle zum Roboter gesandt. Abb. 1.1: DAO-Roboter

13 2 Aufgabenstellung In unserem Projekt mussten wir eine Software zur Telecontrolling des Car like robot entwickeln. Im genaueren mussten wir am Roboter vier Kameras installieren und die Videos dieser Kameras zu einer Client-Anwendung übertragen. Weiters musste es dem Client möglich sein, den Roboter mittels Maus oder Tastatur zu steuern. Da die Datenübertragung über eine Funkverbindung gemacht wird, muss darauf geachtet werden, dass bei einem Verbindungsabbruch Maßnahmen getroffen werden, um einen Unfall zu vermeiden. Außerdem sollte bei schlechter Verbindung die Qualität der Videos vermindert werden, damit das Bild trotzdem flüssig am Client zu sehen ist. Verzögerungen beim Videostreamen könnten dazu führen, dass man ein Hinderniss zu spät erkennt und somit nicht rechtzeitig darauf reagieren kann. Es sollte auch die Möglichkeit bestehen, vom Client zum Roboter einen Videostrom zu übertragen, da der Roboter als Postgefährt gedacht war und somit die Kommunikation vom Kunden und dem Postbeauftragten gewährleistet wäre. 2.1 Client Die Client Software sollte die Möglichkeit bieten, die vier Videoströme des Roboters darzustellen, wobei ein ausgewählter Strom in hoher Qualität vorhanden sein sollte und die anderen in weniger guter Qualität. Weiters sollte es die Software ermöglichen, das eigene Webcam Video darzustellen und zum Roboter zu übertragen. Die Steuerung des Roboters sollte auch über diese Software möglich sein. Bei einem Verbindungsabbruch muss dem Client Benutzer sofort eine Meldung angezeigt werden, dass die Verbindung unterbrochen ist. Der Roboter muss sofort stehen bleiben, da ohne Video nicht auf Hindernisse reagiert werden kann. Dies muss aber über die Serversoftware

14 4 Kap. 2: Aufgabenstellung gesteuert werden, da keine Verbindung zum Client besteht Anzeige für Videostream Die Videoströme sollten so angezeigt werden, dass zumindest die Konturen der Umgebung wahrgenommen werden können. Also sollte bei einer Adaption des Videostroms zuerst auf unwichtige Eigenschaften verzichtet werden, wie zum Beispiel die Farbe Steuerungselemente Über den sicheren Kommunikationskanal werden dem Roboter Steuerungsbefehle des Clients übermittelt. Diese umfassen die am Roboter zur Verfügung gestellten Befehle zur Vorwärts- und Rückwärts-Beschleunigung, sowie zum Lenken des Roboters. Am Client werden die Steuerungsbefehle vom Benutzer über die Tastatur unter Verwendung der Cursortasten entgegengenommen Kamera Auf dem Roboter werden vier Kameras angebracht, um eine Rundumsicht garantieren zu können. Diese Kameras sollten eine hohe Auflösung anbieten, um die Umgebung auch gut erkennen zu können. Bei Bandbreitenengpässen am Wireless LAN wird die Qualität dieser Videos verringert. Dieses Transcodieren wird vom VLC Player gemacht Statusanzeige Die Statusanzeige soll den Verbindungszustand darstellen. Weiters sollte sie so gestaltet werden, dass der User bei Änderungen sofort auf diesen Bereich aufmerksam wird. 2.2 Software für Roboter Der Server überträgt die Videoströme von den Kameras zur Client Anwendung. Weiters müssen die Hardwaredriver von der Serversoftware ansprechbar sein, damit der Roboter gesteuert werden kann. Durch ein ständiges Lebenszeichen wird überprüft, ob die Verbindung zwischen Clientsoftware und Serversoftware vorhanden ist. Sobald diese unterbrochen wird, muss der Roboter sofort abgestoppt werden. 2.3 Übertragung der Daten via WLAN Die Steuerungsdaten und die Videodaten sollen über eine WLAN Verbindung vom Roboter zur Clientanwendung und umgekehrt übertragen werden. Dabei

15 2.3 Übertragung der Daten via WLAN 5 muss beachtet werden, dass bei einem Abbruch ein Mechanismus den Roboter sofort abstoppt.

16 6 Kap. 2: Aufgabenstellung

17 3 Technologien 3.1 Entwicklungsumgebungen In den folgenden Unterkapiteln werden die drei Entwicklungsumgebungen Eclipse, Netbeans und Borland JBuilder beschrieben. In unserem Projekt kam nur eine frei verfügbare Software in Frage. In diesem Bereich sind Eclipse und Netbeans führend. Da wir mit Eclipse besser vertraut waren als mit Netbeans, haben wir uns letztendlich doch für Eclipse entschieden. Außerdem sind für Eclipse alle Plugins vorhanden, die wir benötigen. Dazu gehören das Subversion Plugin und das Latex Plugin Eclipse Eclipse ist eine erweiterbare Entwicklungsumgebung für viele Programmierund Modellierungssprachen und unterstützt auch Teamentwicklung und Versionierung, sei es mit CVS oder Subversion. Eclipse unterstützt Debugging und Refactoring im großen Stil (wenn man zum Beispiel den Namen einer Klasse ändert, werden in allen betroffenen Klassen die Klassennamen geändert, auf Wunsch werden auch die Kommentare durchsucht und entsprechend geändert) und Testen. Wir haben bei unserer Entwicklung folgende Eclipse Plugins verwendet: Subclipse - Subversion Unterstützung für Eclipse Texlipse - Latex Plugin für Eclipse Kernpakate, welche für die Java Entwicklung unter Eclipse notwendig sind. Subclipse unterstützt viele Befehle, die von Subversion zur Verfügung gestellt werden. Weiters gibt es eine Reihe von Views, wie beispielsweise den in Abbildung 3.1a gezeigten Repository Browser. Um das Projekt am Server

18 8 Kap. 3: Technologien (a) Repository Browser (b) Synchronisation View Abb. 3.1: Subclipse Views betrachten zu können, ist der Synchronisationsview verantwortlich. Er bietet eine hierarchische Struktur der Files oder Folders, die entweder am Server oder Client liegen und liefert die aktuellste Versionierung. Weiters können auch Konflikte leicht zu sehen sein. Die folgende Abbildung 3.1b zeigt den Synchronisationsview. Das Latex Plugin für Eclipse steht noch am Anfang seiner Entwicklung. Es gibt erst wenige Features, jedoch funktionieren die notwendigsten Aufgaben, wie automatisches kompilieren beim Abspeichern funktionieren einwandfrei. Darüberhinaus bietet es Syntaxhighlighting und Codekompletierung an. Eine kleine Menge von Sonderzeichen sind über das Menü von Eclipse wählbar Netbeans NetBeans IDE (oft auch nur NetBeans genannt) ist eine Entwicklungsumgebung, die komplett in der Programmiersprache Java geschrieben wurde und auf der NetBeans Plattform läuft. Im Gegensatz zu Eclipse, ist Netbeans auf Swing aufgebaut und nicht auf AWT. Dies ist wichtig, wenn man sich entscheidet eine Rich Client Plattform (RCP) für die eigene Applikation zu nutzen. NetBeans IDE wurde hauptsächlich für die Programmiersprache Java entwickelt und unterstützt unter anderem C, C++ und dynamische Programmiersprachen. Zusätzlich wurden sogenannte Packs entwickelt, welche der IDE eine große Anzahl der Funktionsmöglichkeiten bieten. NetBeans ist ein Open-Source-Projekt, welches als Plattform für eigene Anwendungen verwendet werden kann (Rich Client Platform). Mit einem sehr großen Nutzerkreis, ständig wachsender Community und über hundert Partnern weltweit, ist NetBeans eine der führenden integrierten Entwicklungsumgebungen. Mittlerweile hat sie sich auf dem zweiten Platz, gleich hinter

19 3.1 Entwicklungsumgebungen 9 Eclipse etabliert. Für NetBeans gibt es eine Reihe von Erweiterungen, sogenannte Plugins. Diese integrieren in die IDE spezielle Techniken oder Tools. Die kommerziellen oder freien Plugins können über die Projektseite, oder direkt aus der NetBeans IDE bezogen werden. Über eine einfache Funktion werden sie anschließend in die IDE integriert. Die Modularisierung der NetBeans IDE geht so weit, dass z.b. das komplette Projektmanagement ausgetauscht werden kann. So ist es z.b. möglich, ein Maven-Plugin zu installieren und darüber Java-Projekte zu verwalten. Im Gegensatz zu den Plugins, erweitern die so genannten Packs das Einsatzgebiet der IDE auf Bereiche wie Mobile-, Enterprise- und C/C++-Entwicklung. Um dies zu erreichen, liefern die Packs eine ganze Sammlung von Modulen und Bibliotheken für ein bestimmtes Einsatzgebiet. Ihre Größe kann einige Megabyte erreichen, weshalb sie nicht von vornherein mit der Basis-IDE ausgeliefert werden, sondern als einzelne Downloads zur Verfügung stehen. Neben der Basis IDE werden folgende Packs angeboten: Java SE (für die Entwicklung von Desktop Java-Anwendungen) Web und Java EE (für die Entwicklung von Unternehmens-Anwendungen) Mobility (für die Entwicklung von mobilen Anwendungen) Ruby (Erweiterung für die Programmiersprache Ruby) C/C++ (Erweiterung für die Programmiersprachen C und C++) UML Modelling (UML Modellierung und Design) SOA (Werkzeuge für die Nutzung dienstorientierte Architektur) Plattform (Basis für die Entwicklung von Desktop-Anwendung) [Mic09] Borland JBuilder JBuilder ist eine Java-Entwicklungsumgebung der Firma CodeGear (früher Borland), die komplett in Java geschrieben wurde. Es gibt eine kostenlose Version (Foundation) zum Download, welche auch für kommerzielle Zwecke eingesetzt werden darf und bereits grafische GUI-Erstellung ermöglicht, jedoch im Umfang den kostenpflichtigen Developer- und Enterprise-Editionen nachsteht. Weiterhin basiert der neue Borland C++BuilderX (nicht zu verwechseln mit C++Builder) auf dem Code des JBuilders, der dadurch weitgehende Plattformunabhängigkeit erreicht. Mit Einführung der Version JBuilder 2007 hat sich das Produkt stark gewandelt. Es handelt sich nun nicht mehr um eine eigenständige IDE, sondern lediglich um ein Plugin für das Framework Eclipse. Während das aktuelle Produkt für Neukunden, welche mit Eclipse gearbeitet haben, eine

20 10 Kap. 3: Technologien Funktionserweiterung darstellt, müssen sich die bisherigen Anwender stark umgewöhnen und teilweise auf lieb gewonnene Grundfunktionen des Editors verzichten. Des Weiteren sind bestehende GUI-Klassen, die im Borland UI- Designer erstellt wurden, teilweise nicht mehr im Visual Editor der neuen Version bearbeitbar. Mittlerweile ist der JBuilder 2008 veröffentlicht worden. Dieser wird in zwei kostenpflichtigen Versionen, der Professional und der Enterprise Edition angeboten. Eine in der Funktionalität eingeschränkte Version ist derzeit noch nicht in Sicht [Tec09]. 3.2 Projektmanagement Unter dem Begriff Projektmanagement ist die Verteilung der Aufgaben und die Überwachung dieser Aufgaben gemeint. Es gibt für solche Probleme eine Reihe von Tools, um diese Arbeit zu vereinfachen. In unserem Fall wurde dieser Task relativ klein gehalten, da wir nur zu dritt waren. Am Anfang hatten wir nur einen Subversion Server, der das gemeinsame und gleichzeitige Arbeiten auf dem Source Code und der Dokumentation sehr vereinfacht hat. Danach haben wir einen bedingt frei zugänglichen Subversion Server mit Ticketingsystem und einer Möglichkeit zur Verwaltung der Repositories und Benutzer über ein Webinterface gefunden und verwendet. Dieser Dienst kann auf der Webseite in Anspruch genommen werden Subversion Subversion (SVN) ist eine Open-Source-Software, ähnlich wie CVS (Concurrent Versioning System) zur Versionsverwaltung von Dateien und Verzeichnissen. Wir haben Subversion auf der Linux-Distribution Ubuntu installiert, da durch das Paketmanagement die Installation einfach durchzuführen ist. Installation von Subversion auf Ubuntu Installation der benötigten Pakete: sudo apt get i n s t a l l s u b v e r s i o n libapache2 svn libapache mod dav apache2 SSL aktivieren: sudo a2enmod s s l sudo sh c " echo Listen 443 >> / etc / apache2 / ports. conf " Zertifikat erstellen: Für Ubuntu bis zu Feisty Fawn Version. sudo apache2 s s l c e r t i f i c a t e

21 3.2 Projektmanagement 11 Es wird der Servername dazu verwendet, um Zugang zu dem Web Server zu erhalten. Für Ubuntu gilt das ab der Feisty Fawn Version. sudo apt get i n s t a l l s s l c e r t sudo mkdir / e t c / apache2 / s s l sudo / usr / s b i n /make s s l c e r t / usr / s h a r e / s s l c e r t / s s l e a y. c n f / e t c / apache2 / s s l / apache. pem Virtuellen Host erstellen: sudo cp / e t c / apache2 / s i t e s a v a i l a b l e / default / e t c / apache2 / s i t e s a v a i l a b l e / $SITENAME sudo vim / e t c / apache2 / s i t e s a v a i l a b l e /$SITENAME ändern : NameVirtualHost : <V i r t u a l H o s t :443 > hinzufügen : SSLEngine on S S L C e r t i f i c a t e F i l e / e t c / apache2 / s s l / apache. pem SSLProtocol a l l SSLCipherSuite HIGH:MEDIUM Seite aktivieren: sudo a 2 e n s i t e $SITENAME sudo / e t c / i n i t. d/ apache2 r e s t a r t A warning that complaints about f a i l u r e o f s e r v e r name d e t e r m i n a t i o n can be f i x e d by adding ServerName $SERVERNAME to the main Apache c o n f i g / e t c / apache2 / apache2. c o n f Repository hinzufügen: Mit dem f o l g e n d e n setup können danach mehrere R e p o s i t o r i e s g e h o s t e t werden. sudo mkdir / var / svn sudo svnadmin c r e a t e / var / svn /$REPOS sudo chown R www data :www data / var / svn /$REPOS sudo chmod R g+ws / var / svn /$REPOS Basisauthentifizierung hinzufügen: sudo htpasswd2 c m / e t c / apache2 / dav svn. passwd $AUTH USER Aktivierung und Konfiguration von WebDAV und SVN: Folgendes zu / e t c / apache2 /mods a v a i l a b l e / dav svn. c o n f hinzufügen : DAV svn SVNParentPath / var / svn AuthType Basic AuthName " Subversion Repository " AuthUserFile / e t c / apache2 / dav svn. passwd Require v a l i d u s e r SSLRequireSSL and for non anonymous a c c e s s comment out : #<LimitExcept GET PROPFIND OPTIONS REPORT> #</LimitExcept>

22 12 Kap. 3: Technologien ( o p t i o n a l l y the same c o n f i g u r a t i o n can be s e t for p a r t i c u l a r v i r t u a l host only, i. e. / e t c / apache2 / s i t e s a v a i l a b l e /$SITENAME) Zum Schluss noch den Webserver mit folgendem Befehl neu starten: sudo / e t c / i n i t. d/ apache2 r e s t a r t [Zar07] Wir verlagerten das Projekt auf einen frei zugänglichen Subversion- Server, da die Bedienung einfacher war (wie zum Beispiel Benutzerverwaltung und Erstellung von neuen Repositories). Außerdem bietet dieser Server unter anderem auch die Möglichkeit Tickets zu verteilen, Milestones zu erstellen und verantwortliche Personen zu definieren und vieles mehr. 3.3 Programmiersprachen In unserem Projekt waren wir mit den Programmiersprachen Java und C konfrontiert. Am meisten beschäftigten wir uns mit Java, da unsere ganze Software in Java geschrieben ist. Der einzige Kontakt, den wir mit C hatten, entstand über die JVLC Bibliothek, die über das Java Native Interface (JNI/JNA) auf die DLL s des VLC Players zugreift. In den folgenden Kapiteln werden Java und C kurz beschrieben Java Java ist eine objektorientierte Programmiersprache. Sie ist plattformunanhängig. Das heißt, dass man den Code nur einmal schreiben muss und auf allen anderen Betriebsystemen, für die es eine Java Virtual Machine gibt, verwenden kann, ohne den Code verändern zu müssen. Der Java Code wird auf Bytecode übersetzt. Dieser Bytecode wird dann von der Virtual Machine in Maschinencode übersetzt. Die Virtual Machines werden von Sun für die gängigsten Betriebssysteme geschrieben (wie zum Beispiel Windows, Linux und Solaris, Apple entwickeln die JVM s selbst). Die Grundidee der objektorientierten Programmierung ist die softwaretechnische Abbildung in einer Art und Weise, wie wir Menschen auch Dinge der realen Welt erfahren. Die Absicht dahinter ist, große Softwareprojekte einfacher verwalten zu können und die Qualität der Software zu erhöhen. Ein weiteres Ziel der Objektorientierung ist ein hoher Grad der Wiederverwendbarkeit von Softwaremodulen [Ull07] C C ist eine Programmiersprache, die auf fast allen Computersystemen zur Verfügung steht. Dennis Ritchie entwickelte C für die Programmierung des

23 3.4 Video Streaming 13 UNIX Betriebssystems. Sie zählt zu den sogenannten prozeduralen Programmiersprachen. Um den Wildwuchs zahlreicher Dialekte einzudämmen, wurde C mehrfach standardisiert (C89, C95, C99, ISO-C). Abgesehen vom Mikrocontrollerbereich, wo eigene Dialekte existieren, sind die meisten aktuellen PC-/Server-Implementierungen eng an den Standard angelehnt; eine vollständige Implementierung aktueller Standards ist aber selten. In den meisten C-Systemen mit Laufzeitumgebung steht auch die genormte Standard C Library zur Verfügung. Dadurch können C-Programme, die keine hardwarenahe Programmierung enthalten, in der Regel gut auf andere Zielsysteme portiert werden. Konzeptionell ist C auf eine einfache Kompilierbarkeit ausgelegt. Die Verbreitung von C ist hoch. Viele Programmierschnittstellen für Anwendungsprogramme, werden in Form von C-Schnittstellen implementiert [KR90]. 3.4 Video Streaming Zeitbasierte Medien können aus unterschiedlichen Quellen stammen: Lokale Dateien auf einen Datenträger, lokale Eingabegeräte wie Mikrofon oder Videokamera, aber auch Datenströme aus einem Netzwerk. Eine rechtzeitige Bearbeitung und Zustellung der multimedialen Daten ist für alle diese Quellen von entscheidender Bedeutung. Bei der Übertragung sind meist mehrere Bearbeitungsschritte notwendig. Dabei gilt zu beachten, dass Medien meist aus mehreren Spuren (Tracks) aufgebaut sind. Um einen bestehenden Datenstrom bearbeiten zu können, müssen diese Spuren vorher aufgeteilt (demultiplexed) werden. Die so gewonnenen einzelnen Datenströme, können dekodiert und eventuell in ein neues Datenformat konvertiert werden. Durch diesen Vorgang entsteht eine gewisse Latenzzeit, die vor allem bei der Synchronisation der einzelnen Datenströme zu beachten ist. Insbesonders wenn Daten nicht lokal, sondern über ein Netzwerk verteilt werden, kann es vorkommen, dass Pakete zu spät eintreffen, oder verloren gehen. Ein Anwender empfindet solch verloren gegangene Pakete meist als störende Pausen, oder es bilden sich Artefakte (siehe Abbild 3.2), welche unter Umständen das Videosignal unbrauchbar machen. Um den Paketverlust gering zu halten, gibt es eine Reihe von möglichen Gegenmaßnahmen. So könnte die Framerate, eventuell die Bildgröße, oder aber auch die Anzahl der Farben verkleinert werden. Die Umwandlung eines färbigen Videostreams in Graustufen, verbraucht so eine viel geringere Bandbreite. Welche Gegenmaßnahmen gesetzt werden, hängt vom jeweiligen Einsatz ab. Für unser Projekt sind alle oben genannten Maßnahmen denkbar. Bei der Steuerung des Roboters kommt es vor allem auf eine unterbrechungsfreie Übertragung an, wobei

24 14 Kap. 3: Technologien Abb. 3.2: Störende Artefakte bei zu geringer Bandbreite die Latenzzeit so gering wie nur möglich gehalten werden soll. Plötzlich auftretende Hindernisse müssen so schnell wie möglich erkannt werden, dabei wird es nicht darauf ankommen, ob das Bild in Farbe, oder in Graustufen übertragen wird. Für die Übertragung von Videostreams stehen eine Menge von Möglichkeiten zur Verfügung. Die Entscheidung über die verwendete Programmiersprache Java ist bereits gefallen. Einige der diesbezüglich von uns untersuchten Technologien, inklusive deren Vor- und Nachteile, werden in den folgenden Unterkapitel beschrieben Java Media Framework (JMF) Mit JMF soll es auf einfache Weise möglich sein, Java-Programme zu schreiben, welche zeitbasierte Medien verarbeiten oder präsentieren. Für die Einund Ausgabe stehen eine Reihe von Ressourcen, wie z.b. Mikrofon, Kamera, Datei-System, oder aber auch eine einfache Ausgabe über Lautsprecher oder Bildschirm zur Verfügung. Während die wichtigsten Audioformate von Sun mittlerweile weitgehend implementiert sind, benötigen einige Videoformate (wie zum Beispiel H.261) die Unterstützung durch ein sogenanntes Performance Pack, welches betriebssystemspezifische Erweiterungen enthält. Diese Zusatzmodule sind zur Zeit vor allem für Windows und Solaris vorhanden, jedoch sind durch den flexiblen Plugin-Mechanismus des JMF weitere Plattformen denkbar. Das Hauptaugenmerk liegt bei dem Java Media Framework API auf einer einheitlichen, auf Plattformunabhängigkeit hin ausgerichteten Architektur, welche Entwickler zum Speichern und Abspielen multimedialer Daten in Applets und Java-Anwendungen einsetzen können. Mit dem JMF API können vielseitige Player erstellt werden, welche die Daten lokal oder auch

25 3.4 Video Streaming 15 aus dem Netzwerk beziehen. Javakompatible Plattformen sind in der Lage, die am häufigsten genutzten Datei- und Medienformate, unabhängig vom Netzwerkprotokoll aufzubereiten, zu steuern und zu synchronisieren. Bereits bestehende Applets und Java-Anwendungen können mit dem JMF-Player um die Wiedergabe multimedialer Inhalte erweitert werden. JMF ist Teil der Java Media APIs, welche aus zahlreichen Klassen aus den Bereichen Audio/Video-Aufnahme und Wiedergabe, Animation, 2D und 3D Grafik, verteiltes Arbeiten an einem Projekt, Spracherkennung und -synthese, komplexe Bildebearbeitung, sowie vielzähligen weiteren vergleichbaren Technologien besteht. JMF unterstützt Anwendungen durch seine mächtigen Funktionalität, vor allem in der Kommunikation und Medienvearbeitung. Für plattformspezifische Optimierungen oder Erweiterungen durch den Entwickler, bietet die offene Architektur der JMF API genügend Raum. Standardmäßig werden bereits vielzählige Formate unterstützt wie beispielsweise MPEG-1, AVI, QucikTime, AU, MIDI, WAV, TIFF-Dateien und viele mehr, wobei einige der angegebenen Formate auf systemspezifische Erweiterungen zurückgreifen. Wenn Medien mehrere Datenkanäle (Tracks) enthalten, spricht man von gemultiplexten oder zusammengesetzten Medienströmen. JMF stellt verschiedene Optionen, zum automatischen Demultiplexen und Verteilen auf mehreren sogenannten Playern zur Verfügung. Wie die Daten zur Präsentation aufbereitet werden müssen, legt das Format eines Medienstroms fest. Um solche Medien in einem Netzwerk identifizieren zu können, verwendet JMF einen sogenannten MediaLocator, welcher vom Aufbau her Ähnlichkeiten zu einer URL aufweist, jedoch weitere Charakteristika eines Medienstroms beschreibt. Üblicherweise erfolgt die Medienpräsentation über Ausgabegeräte wie Bildschirm und Lautsprecher. JMF beinhaltet das abstrakte Modell der DataSink, welches zusätzlich die Ausgabe auf einen Datenträger, oder die Übertragung in einem Netzwerk erlaubt. Die Anwenderschnittstelle ist durch sogenannte Presentation Controls realisiert, welche unter anderem die Funktionalität eines Videorekorders nachahmen. JMF ist flexibel genug, dass nur die für die Anwendung notwendigen Steuerelemente verwendet werden müssen und bietet so genügend Freiraum für den Anwendungsprogrammierer. In der Abbildung 3.4 wird zunächst ein grobflächiger Überblick über die Architektur des Java Media Frameworks geliefert. An der Spitze befinden sich Anwendungen, die auf die Funktionalität des darunterliegenden JMF zugreifen. Je nach Art der Anwendung wird auf die untergeordneten Schichten über das RTP Session Manager API, einer spezifischen Erweiterung von Sun zur Bearbeitung von RTP Strömen, oder auf das JMF Presentation and Processing API zugegriffen. Auf Grund dessen,

26 16 Kap. 3: Technologien Abb. 3.3: Überblick über die Architektur des Java Media Frameworks dass im Plugin-API alle (De-)Multiplexer, Effects, Codecs und Renderer registriert werden, spielt dieses Application Programming Interface innerhalb des JMF eine ausschlaggebende Rolle. Sollte ein bestimmtes Format nicht unterstützt werden, besteht an dieser Stelle die Option, eigene Erweiterungen zu integrieren. Bei der Bearbeitung eines Medienstroms wird ein sogenannter Flow-Graph aufgebaut, der genau die Schritte vom Datenempfang bis zur Präsentation widerspiegelt. Während dem Aufbau dieser Bearbeitungskette, werden die verfügbaren Komponenten analysiert und wenn möglich, zu einer Einheit zusammengeführt. Sollte für ein bestimmtes Format keine passenden Komponenten vorhanden sein, so wird eine Exception generiert. Zeitmodell Das Java Media Framework API verwendet intern eine Zeitdarstellung, mit einer Auflösung im Nanosekundenbereich. Hier werden grundlegende Operationen zur Zeitmesseung und -synchronisation definiert, welche für die Medienpräsentation von großer Bedeutung sind. Managertypen Die Basis für das Java Media Framework API bilden eine Reihe von Interfaces, welche das Verhalten und die Interaktion von Objekten definieren, die letztlich zum Aufnehmen, Bearbeiten und Präsentieren von zeitbasierten Medien dienen. Eigene Entwicklungen oder Erweiterungen von Fremdanbietern, können über den Manager, welcher eine zwischengelagerte Schicht darstellt, in das bestehende Framework integriert werden. Ereignismodell Das Ereignismodell des Java Media Framework stellt die Grundlage für die Kommunikation einer Anwendung mit den JMF-Komponenten dar. Die vielfälti-

27 3.4 Video Streaming 17 gen, von JMF generierten Zustands- und Fehlermeldungen, können so auf einfachstem Wege ausgewertet werden. Datenmodell Alle Eigenschaften einer Datenquelle (der genaue Ort, das Protokoll, die verwendete Software zur Bereitstellung der Daten,... ) werden von DataSource gekapselt. Ein DataSource-Objekt kann nur einer Quelle zugewiesen werden, vervielfältigt, oder zu einer neuen DataSource zusammengemischt werden. Controls Ein Control hat die Fähigkeit die Arbeitsweise eines Controllers zu beeinflussen. Das Verhältnis Controller zu Control ist am besten vergleichbar mit einem Fernseher und seiner Fernbedienung. Controller Ein Controller ist prinzipiell im Zustand Started oder Stopped. Zur feineren Unterteilung von Stopped, wurden noch die Zustände Unrealized, Realizing, Realized, Prefetching und Prefetched eingeführt, welche die unterschiedlichen Stadien der Belegung der Ressourcen widerspiegeln (Abbild 3.4). Ein Controller verhart niemals in einem Zustand, sondern ist immer Abb. 3.4: Zustände und Zustandsübergänge eines Controllers auf dem Weg zu einem neuen Zielzustand. Für den Anwendungsprogrammierer gibt es die Möglichkeit, den aktuellen, sowie den Zielzustand eines Controlls abzufragen. Der Einsatz eines Controllers setzt zwei wichtige Schritte voraus: Zum Einem muss der aktuell Zustand eines Controllers überwacht werden und zum Anderen muss gegebenenfalls ein Zustandsübergang initiiert werden. Für die Zustandsübergänge existieren fünf Methoden: realize, prefetch, deallocate, syncstart und stop.

28 18 Kap. 3: Technologien Player Durch einen Player wird ein eingehender Datenstrom bearbeitet und zu einem bestimmten Zeitpunkt wieder ausgegeben. Wie die Daten verarbeitet und angezeigt werden, kann vom Player selbst nicht kontrolliert werden. Die Klasse Player besitzt sechs verschiedene Zustände, wobei einige Methodenaufrufe in bestimmten Zuständen nicht erlaubt sind. Beispielsweise kann einem gestarteten Player kein weiterer Controller zugewiesen werden. Processor Durch einen Processor wird die Funktionalität eines Players erweitert. So ist es möglich, Medien nicht nur direkt abzuspielen, sondern die Daten auch anderen Playern oder Prozessoren weiter zu reichen. Dieser Mechanismus ermöglicht eine Kettenbildung mit verschiedenen dazwischen liegenden Arbeitsschritten. Am Ende so einer Verarbeitungskette kann zum Beispiel ein Player oder eine Ausgabedatei stehen. Persönliche Erfahrung und Entscheidungsgrundlage JMF ist wie Java, ein Podukt von Sun und sollte daher besonders leicht in Java eingebunden werden können. Die Features dieser API entsprechen zum überwiegenden Teil genau unseren Vorgaben und es gibt reichlich Literatur. Genau aus diesen Gründen haben wir uns von Anfang an sehr genau mit dieser API beschäftigt. Je intensiver wir uns mit unserer Arbeit auseinander gesetzt haben, desto mehr wurde uns klar, dass wir nach eventuellen Alternativen Ausschau halten sollten. Die API ist leider nicht plattformunabhängig und scheint noch nicht vollkommen ausgereift zu sein. Es gab immer wieder unerwartete, nicht nachvollziehbare Abstürze. Selbst die Fülle an Literatur und Forenbeiträgen konnte uns nicht weiter helfen. Die Entwicklung der Java Sound API, sowie von JMF, steht nun seit längerer Zeit still. Es hat nicht den Anschein, dass die Firma Sun diese beiden APIs in nächster Zeit weiter entwickeln wird. Deshalb haben wir uns auch dazu entschieden, JMF nicht zu nutzen, auch wenn es durchaus interessante Ansätze bietet Freedom for Media in Java (FMJ) Freedom for Media in Java ist ein Open-Source Projekt, welches sich zum Ziel gesetzt hat, das von Sun entwickelte und mittlerweile eingestellte JMF zu ersetzen. FMJ soll dabei vollkommen kompatibel zu JMF sein, denn es kann der gleiche Sourcecode verwendet werden. Deshalb ist FMJ, vor allem für bereits bestehende JMF-Projekte, besonders interessant.

29 3.4 Video Streaming 19 Intern setzt FMJ auf bereits bestehende Bibliotheken auf, die gesondert am jeweiligen System installiert sein müssen. Zurzeit werden FFMPEG, Theora und GStreamer unterstützt. Persönliche Erfahrung und Entscheidungsgrundlage FMJ ist eine noch recht neue API und steht momentan mitten in der Entwicklungsphase und wird außerdem von Sun offiziell nicht unterstützt. Auch wenn es schon einige recht beeindruckende Demos gibt, welche die FMJ-API verwendet, wollten wir uns nicht auf eine halbfertige Lösung stützen. Aus diesem Grund fiel unsere Entscheidung zu Beginn unseres Projektes auch gegen FMJ. Für zukünftige Projekte könnte diese API jedoch eine echte Alternative werden Java Media Components (JMC) Nach dem Sun die Entwicklung von JMF mit Ende des Jahres 2004 eingestellt hat, ist dem breiten Publikum nun im Dezember 2008 ein völlig neuer Ansatz vorgestellt worden. Sun will mit dem Paket JavaFX eine echtes Konkurrenz-Produkt zu Adobe-Flash und Silverlight von Microsoft auf den Markt positionieren. JMC ist in JavaFX fix integriert und ermöglicht eine einfache Verarbeitung und Wiedergabe von Videostreams. Persönliche Erfahrung und Entscheidungsgrundlage Die Beispiele und Demos von JavaFX sehen recht beeindruckend aus. Auch wenn JavaFX eher für webbasierte Anwendungen gedacht ist, können auch Standalone Applikationen erzeugt werden. Leider ist JavaFX und das darin enthaltene JMC erst am Ende unseres Projekts veröffentlicht worden. Eine eventuelle Umstellung auf diese Technik war für uns nicht sinnvoll Adobe Flash Flash findet heutzutage auf vielen Webseiten Anwendung. Bei der Verwendung dieser Technik, wäre es in unserem Fall am sinnvollsten, auch für den Client eine Homepage zu gestalten. Die Firma Adobe bietet dafür eine unfangreiche Entwicklungsumgebung an. Flash-Seiten sind auf fast allen grafischen und aktuellen Browsern lauffähig. Das zu Grunde liegende Betriebssystem spielt so weit auch keine Rolle. Aus der Sicht der Plattformunabhängigkeit bietet Flash eine wirkliche Alternative, die es zu überdenken gilt. Vor allem deshalb, weil Flash mit Action-Script mittlerweile ein recht mächtige Programmiersprache bietet.

30 20 Kap. 3: Technologien Für das Streamen von Videos im Flash eigenen Format, bedarf es einen Server, welcher das Real Time Messaging Protocol (RTMP) unterstützt. Dieses wurde von Adobe entwickelt, um Video- und Audiodaten zwischen Media Server und Flash-Client zu übertragen. Für das Streamen von Videos gibt es eine Reihe von bereits bestehenden Serverlösungen, welche nun kurz beschrieben werden: Macromedia Flash Media Server (FMS) Bei FMS handelt es sich um einen kommerziellen Server. Die Kosten dafür liegen im vierstelligen Eurobereich. Es wird aber auch eine Testversion angeboten, welche einen gleichzeitigen Zugriff von maximal 10 Benutzern erlaubt und nicht kommerziell verwendet werden darf. Wowza Media Server Zwei ehemalige Adobe-Mitarbeiter haben den Wowza Streaming Server entwickelt. Die Alternative zum Macromedia Flash Media Server läuft auf Java 5. Serverseitig kommt ebenfalls Java als Programmiersprache in Verwendung. Auf der Clientseite wird auf die gewöhnliche Action-Script-API zurückgegriffen, die auch für den Macromedia Flash Media Server gültig ist. Der Wowza Media Server ist, genau wie der Macromedia Flash Media Server, eine kommerzielle Serverlösung und ist in etwa gleich teuer. Allerdings gibt es auch für Wowza eine Testversion mit eingeschränktem, gleichzeitigem Zugriff, welche nicht kommerziell genutzt werden darf. Red5 Als günstigere Alternative zu den beiden oben erwähnten Servern, bietet sich der Red5-Server des Projektes OSFlash an. Der kostenlose Open Source RTMP-Server bietet eine ausreichende Funktionalität. Er bietet eine direkte Unterstützung für die Übertragung von Audio- und Videodaten, was eine Umsetzung der geforderten Echtzeitkommunikation erheblich vereinfacht. Schon mit der Standardinstallation des Red5-Servers werden die wichtigsten Module mitgeliefert, womit eine schnelle und einfache Demonstration seines Funktionsumfangs erlaubt ist. Modifikationen oder Weiterentwicklungen sind leicht umsetzbar. Alle Module liegen als Quelltext vor. Die verwendete Programmiersprache ist Java. Besonders erwähnenswert ist die recht umfangreiche Dokumentation zu dieser API, welche eine gute Grundlage für eigene Lösungen bietet. Persönliche Erfahrung und Entscheidungsgrundlage Flash bietet prinzipiell alle Techniken, die unsere Anforderungen erfüllen. Mit Action-Script steht eine mächtige Programmiersprache zur Verfügung.

31 3.4 Video Streaming 21 Es gibt eine Reihe von Streaming-Server für das Verteilen von multimedialen Datein. Die Problematik in unserem Fall besteht darin, dass wir Videostreams in beiden Richtungen, vom Server zum Client und umgekehrt, bewerkstelligen müssen. Die Folge wäre, dass auch der Client mit einem Streaming- Server versehen werden müsste. Die Ansteuerung und Kommunikation der Streaming-Server in beiden Richtungen wäre so viel zu kompliziert. Darüberhinaus steht noch die Problematik der Kommunikation mit dem Roboter im Raum Java Binding for VLC (JVLC) JVLC ist eine Java Multimedia Library, die auf den frei verfügbaren VLC Media Player aufbaut. Damit kann auf besonders einfache Weise der volle Funktionsumfang des VLC Media Players genutzt werden. VLC Media Player (VLC) Die Entwicklung des VLC Media Players wurde 1999 von einigen französischen Studenten gestartet. Mittlerweile sind etwa 50 Programmierer aus über 20 Ländern am Projekt beteiligt. VLC steht unter der GPL und ist somit frei verfügbar. Der Anlass für die Entwicklung dieses Projekts bestand in dem Vorhaben, den Universitäts-Campus mit Video-Streams eines TV-Senders zu versorgen. Ursprünglich bestand das Projekt aus zwei verschieden Teilbereichen: Der VideoLAN Server diente zum Streamen von DVDs, digitalen TV- Signale und einer begrenzten Anzahl von Audio- und Videoformaten. Der VLC Media Player zur Wiedergabe von Streams aus einem Netzwerk. Mittlerweile ist aber die Funktionalität des VideoLAN Servers komplett im VLC Media Player integriert. Die Weiterentwicklung des Servers war nicht mehr notwendig und ist gestoppt worden. Durch die Integration des Streaming Servers, ist es nun mit der grafischen Bedienoberfläche des VLCs auf noch einfachere Weise möglich, ein Videostream zu definieren und über das Netzwerk zu verteilen. Es werden hierfür eine Vielzahl von Protokollen wie UDP, RTP, HTTP oder MMS unterstützt. Es stehen sowohl IPv4- und IPv6-Adressbereiche zur Verfügung. Die beiden Streaming-Methoden Unicast und Multicast sind ebenfalls möglich. Aber auch die Player-Komponente des VLCs hat sich erweitert. Neben dem bereits oben erwähnten abspielen von Streams aus dem Netzwerk, ist es mittlerweile auch möglich, multimediale Daten von lokalen Dateien, DVDs, VCDs, CDs, Mikrofone, Videokameras und digitalen TV zu verarbeiten. (Ein Überblick bietet dazu das Abbild 3.5) Zusätzlich können eine Reihe von Fil-

32 22 Kap. 3: Technologien Abb. 3.5: VideoLan Streaming Solution [Vid06] tern und verschieden Effekte in Echtzeit angewand werden. Besonders hervorzuheben ist die Vielseitigkeit von VLC, die sich aus der Fähigkeit ergibt, nahezu jedes Format und jede Datei verarbeiten zu können. Selbst unvollständige oder bruchstückhafte Dateien stellen kein Problem dar. Dabei werden vom VLC-Team keine Decoder oder Encoder selbst entwickelt, denn VLC greift hierzu auf bereits bestehende Projekte zurück. Die bekanntesten sind FFmpeg, libmpeg2 und x264. Diese werden mit speziell entwickelten Demultiplexern kombiniert. Dadurch ist das Leseverhalten und die Fehlertoleranz deutlich besser als bei anderen Playern, welche die selben Codecs verwenden. VLC ist auf den wichtigsten, modernen Betriebssystemen lauffähig. Dazu zählen Linux, Mac OS X, Microsoft Windows, BeOS, Syllable und BSD. Aus den oben genannten Gründen kommt der VLC Media Player vor allem bei privaten Benutzern, in Schulen und Universitäten, aber auch bei professionellen Anwendern immer mehr zum Einsatz. Besonders geschätzt wird die hohe Kompatibilität mit der großen Anzahl an unterstützten Formaten und Codecs. Persönliche Erfahrung und Entscheidungsgrundlage Zur Verarbeitung von multimedialen Medien hat sich der VLC Media Player zu einem richtigen Alleskönner entwickelt. Auch in unserem privaten Bereich hat er sich schon seit langem zum Standard-Player etabliert. VLC erfüllt bei

33 3.5 Datenübertragung 23 weitem all unsere Anforderungen, trotzdem entwickelt sich der Medienkünstler stetig weiter. Durch JVLC steht uns eine zusätzliche API zur Verfügung, welche uns auf einfachste Weise den vollen Zugriff auf alle Möglichkeiten des VLCs gewährleistet. Das Erstellen, Bearbeiten, Filtern und Codieren von Videostreams ist durch die Übergabe einer Media Resource Locator (MRL) und dazugehöriger Parameterliste einfach zu realisieren. Lediglich beim Einbinden des Videosignals, in eine mit Java erzeugten GUI, gab es unter Mac OS X Probleme. Der VLC Media Player scheint für uns die beste, zur Zeit verfügbare Technik für unsere Ansprüche zu sein. Deshalb haben wir uns auch an dieser Grundlage bedient. 3.5 Datenübertragung Um den Robotor steuern zu können, muss der Kommunikationskanal mehrere Medien durchqueren. Eine Übersicht dazu, wird im Abbild 3.6 dargestellt. Der Arbeitsplatz wird sich meist in einem Local Area Network (LAN) Abb. 3.6: Kommunikationskanal befinden und kann, sofern eine Internetverbindung besteht, weltweit vertreten sein. Der Roboter selbst, befindet sich in einem Wireless Local Area Network (WLAN) und bildet somit den eigentlichen Flaschenhals bei der Kommunikation. Durch den ständigen Standortwechsel des Roboters, kann keine gleichmäßige Verbindungsqualität garantiert werden. Am Roboter ist ein Industrierechner montiert, welcher die Steuersignale über ein serielles Kabel (RS-232) zur Steuerungselektronik sendet. Für diese Übertragungswege wurden Strategien für eine optimale Realisierung anhand ihrer Vor- und Nachteile überlegt, wobei die verwendete Programmiersprache JAVA sein soll Local Area Network (LAN) Die Übertragung der Daten über Wireless Local Area Network (WLAN) bringt einige Schwierigkeiten bzw. Probleme mit sich, die zu beachten sind.

34 24 Kap. 3: Technologien Da sich der Roboter bewegt und daher ständig den Standort ändert, wird sich auch die Signalstärke des Übertragungsweges fortlaufend ändern. Die Folgen daraus sind, dass die maximale Datenübertragungsrate ständigen Schwankungen ausgeliefert sein wird. Kurzzeitige Ausfälle, die zum Verbindungsabbruch führen können, sind zu erwarten. Im schlimmsten Fall, könnte der Roboter sogar gänzlich den Bereich des Empfangs verlassen. Die verwendete Technologie sollte diese Problemfälle erkennen und geeignete Gegenmaßnahmen erlauben. Wünschenswert wäre eine Messung der aktuellen Verbindungsstärke (Signalstärke) und der maximalen Übertragungsrate, besonders im Bezug auf die Datenpakete der fünf Kameras. Java Sockets Java hat seit der Version das Packet java.net fix integriert. Mit diesem Packet ist es möglich, Socket-Verbindungen zu realisieren. Ein Socket dient zur Abstraktion und ist ein Verbindungspunkt in einem TCP/IP-Netzwerk. Java bietet dabei zwei unterschiedliche Typen an: Stream Sockets Ein Stream-Socket baut eine feste Verbindung zu einem Rechner auf. Dabei bleibt die Verbindung für die Dauer der Übertragung bestehen. Dies macht nur Sinn, wenn die Verbindung relativ stabil ist und auch für die gesamte Dauer der Übertragung aufrechterhalten werden kann. Die so übertragenen Datenpakete kommen in der Reihenfolge am Zielrechner an, in der sie abgeschickt wurden. Geht ein Datenpaket bei der Übertragung zum Zielrechner verloren, wird es automatisch erneut gesendet. Auf diese Weise ist gewährleistet, dass auch alle Pakete in der richtigen Reihenfolge am Ziel ankommen. Datagramm Sockets Ein Datagramm-Socket benötigt im Gegensatz zum Stream-Socket keine feste Verbindung zum Zielrechner, setzt auf UDP auf. Da jedes Paket bei Datagramm-Sockets einzeln losgeschickt wird, könnte theoretisch jedes Paket einen anderen Weg zum Zielrechner nehmen. Es wird dabei nicht überprüft, ob die einzelnen Datenpakete in der richtigen Reihenfolge am Zielsystem ankommen. Verloren gegangene Pakete werden ignoriert und nicht automatisch erneut verschickt. Im Gegensatz zu Stream-Sockets, die auf einen bestimmten Host fixiert sind und nur mit diesem Daten austauschen können, sind Datagramm-Sockets flexibler. Über einen Datagramm-Socket kann theoretisch mit verschiedenen Rechnern kommuniziert werden. Der jeweils zu kontaktierende Host wird nicht bei der Initialisierung des Sockets festgelegt, sondern im abgeschickten Datagramm vermerkt, in dem die Adresse des Zielund des Ausgangsrechners hinterlegt ist.

35 3.5 Datenübertragung 25 Persönliche Erfahrung und Entscheidungsgrundlage Der Vorteil der Socket-Programmierung ist, dass es fixer Bestandteil von Java ist und somit keine weitere Bibliothek eingebunden werden muss. Ein möglicher Nachteil der Socket-Programmierung ist der erhöhte Programmieraufwand. Dieser ergibt sich aus dem Zustand, dass man für eine stabile, sichere und wie in unserem Fall adaptive Anpassung, selber Sorge tragen muss. Die Verwendung von Stream-Sockets erzwingen das erfolgreiche Versenden aller Datenpakete. Dies kann zu Problemen bei einem ausgelasteten Netzwerk führen, denn die Übertragung des Videostreams wird erst dann fortgesetzt, wenn alle Datenpakete am Zielsystem angelangt sind. Das Ergebnis wäre, dass das Videosignal zu stottern beginnt und sich die Verzögerung in die Länge zieht. Eine Übertragung in Echtzeit wäre nicht mehr möglich. Aufgrund der sich ständig wechselnden Netzwerkverbindung, würde sich das Datagramm-Socket anbieten. Das Versenden von UDP-Paketen wäre somit leicht möglich, was besonders für die Übertragung der Video-Streams geeignet wäre. Die Verwendung von Datagrammen lässt verloren gegangene Datenpakete fallen. Das Videosignal kann dabei nach wie vor in Echtzeit übertragen werden, jedoch entstehen dadurch Artifakte im Videobild. Wenn der Inhalt der Pakete geschickt aufgebaut wird, kann auf den Status der Netzwerkverbindung ein Rückschluss gezogen werden. So könnte jedes Datenpaket eine fixe aufsteigende ID enthalten. Der Empfänger kann das Eintreffen der Datenpakete analysieren und so die Anzahl der zu spät eingetroffenen, oder gar verloren gegangenen Pakete ermitteln. Je schlechter die Verbindung ist, desto mehr Datenpakete werden verloren gehen. Anhand dieser Analyse könnten so die Eigenschaften der Videostreams dynamisch angepasst werden (Bitrate, Dimension, Anzahl der Farben). Remote Method Invocation (RMI) RMI stellt einen Mechanismus zur sogenannten verteilten Anwendungsprogrammierung bereit. Es ermöglicht den Zugriff auf entfernte Objekte (Remote Objects) und die Nutzung deren Dienste. Entfernte Objekte werden als solche bezeichnet, wenn sie sich auf einer anderen Java Virtual Machine (JVM) befinden. Diese kann sogar auf einen anderen Rechner laufen und ermöglicht damit die Kommunikation über verschiedene Netzwerke. Die Plattformunabhängigkeit der Java-Architektur läßt RMI zu einem mächtigen Werkzeug werden, da es auf einfache Weise möglich ist, Programmcodes im Netzwerk zu verteilen, auch wenn sich die Partner auf verschiedenen Plattformen befinden. Die Übertragung von reinen Daten im Netzwerk ist relativ einfach zu erledigen. Die Verteilung von Programmcodes und damit der Zugriff auf

36 26 Kap. 3: Technologien die Dienste eines entfernten Rechners, erfordert jedoch einen aufwändigeren Kommunikationsprozess. Es benötigt ein Protokoll, welches sich um die Datenerstellung und die Kommunikationssteuerung kümmert. Das Ziel von RMI ist es, den Programmierer bei der Erstellung eines solchen Kommunikationsprotokolls zu unterstützen. Dies führt zu einer deutlichen Reduzierung des Programmieraufwands. Übersicht RMI setzt wie Common Object Request Broker Architecture (CORBA) auf Remote Procedure Call (RPC) auf. Das Prinzip von RPC ist es, den Zugriff auf entfernte Serverfunktionen wie lokale Prozeduraufrufe erscheinen zu lassen. Die eigentliche Verbindung zwischen Server und Client übernehmen dabei sogenannte Stellvertreterobjekte (Proxies). Allerdings stammt RPC noch aus der prozeduralen Welt, RMI und CORBA sind dagegen objektorientiert. Seit JDK Version 1.1 ist RMI fixer Bestandteil von JAVA und wird durch das Paket java.rmi.* implementiert. RMI bietet mehrere Protokolle an, zwischen denen der Anwendungsprogrammierer wählen kann. Dabei muss man sich nicht um die Details der Protokolle kümmern. Hier eine Liste der zur Verfügung stehenden Protokolle: Java Remote Method Protocol (JRMP) ist das Standardprotokol. RMI IIOP dient zur Integration in CORBA. RMI über HTTP ist getunnelt und kann daher Firewalls umgehen. SSL verschlüsselt zur sicheren Kommunikation. Architektur Die RMI-Architektur ist, so wie TCP eine Schichtenarchitektur, welche aus drei Schichten (Layern) besteht: Transportlayer, Remote Reference Layer und Stub/Skeleton Layer. Der Aufbau ist in Abbild 3.7 dargestellt. Abb. 3.7: Schichtenarchitektur von RMI Der Transportlayer (Netzwerkschicht) umfasst den Networklayer des jeweiligen Host. Der Remote Reference Layer beinhaltet die Verbindungs-

37 3.5 Datenübertragung 27 Semantik, er implementiert die Verbindungsdetails und die Übertragungsprotokolle. Der Stub/Skeleton Layer beherbergt die komplizierten Details der Kommunikation und verbirgt sie vor dem Anwendungsprogrammierer. Virtuelle Verbindung Erzeugt wird der Stub am Server. Sobald ein Client erfolgreich mit dem Server verbunden ist und ein entferntes Objekt aufruft, wird ihm das dazugehörige Stub-Objekt übergeben. Die Aufgabe eines Stubs besteht darin, alle Methoden über das Netzwerk dem referenzierten Skeleton-Objekt am Server weiter zu leiten. Der Client interaktiert somit nur mit dem Stub-Objekt. Der Skeleton befindet sich am Server. Seine Aufgabe besteht darin, Methodenaufrufe, welche vom dazugehörigen Stub über das Netzwerk versand worden sind, entgegen zu nehmen und dem entfernten Objekt weiter zu leiten. Funktionsweise Um RMI verwenden zu können, sind drei Komponenten notwendig: Der Client mit dem Remote Interface Der Server welcher die Remote Objekte beinhaltet Der Namensdienst (RMI Registry), über den die Remote Objekte vom Server registriert und vom Client abgefragt werden können. Das Remote Interface definiert und beschreibt das Verhalten der Funktionen, welche am Server zur Verfügung stehen, ohne diese zu implementieren. Die Remote-Objekte implementieren das Remote Interface. Vom Server können eine oder mehrere Instanzen eines Remote-Objekts erstellt werden. Die RMI Registry ist eine Implementierung eines einfachen Namensdienstes und Bestandteil des RMI Paketes. Hier werden die Remote-Objekte vom Server registriert. Die Referenzen der Remote-Objekte können von den Clients abgefragt werden. Der Ablauf eines Funktionsaufrufs, wie er in Abbild 3.8 dargestellt ist, lässt sich mit folgenden fünf Punkten beschreiben: 1 Zuerst muss die RMI-Registry vom Server gestartet werden 2 Danach instanziert der Server ein oder mehrer Remote-Objekte und meldet diese am Namensdienst an. 3 Ab diesem Zeitpunkt kann der Client vom Namensdienst eine Referenz auf das Remote-Objekt erhalten. 4 Mit der vom Namensdienst erhaltenen Referenz, kann der Client die entfernte Funktion am Server aufrufen.

38 28 Kap. 3: Technologien Abb. 3.8: RMI: Elemente und Ablauf 5 Im letzten Schritt liefert der Server dem Client den entsprechenden Rückgabewert. Sollte bei der Kommunikation ein Fehler aufgetreten sein, wird stattdessen eine Exception geworfen. Persönliche Erfahrung und Entscheidungsgrundlage Die Vorteile von RMI: Es ist einfach zu erlernen und stellt einen geringen Implementierungsaufwand dar. Da es fixer Bestandteil der JDK ist, sind keine zusätzlichen Lizenzen notwendig. Das Umgehen von Firewalls ist prinzipiell möglich. Es bietet ein hohes Abstraktionsniveau, d.h. die eigentliche Kommunikation bleibt unsichtbar. Es unterstützt eine Client-Server Architektur, über welche ein dynamischer Programmcode-Austausch (durch Serialisierung) möglich ist. RMI beinhaltet einen Distributed Garbage Collector, welcher entfernte Objekte, die nicht mehr im Programm verlinkt sind, automatisch aus dem Speicher entfernt. Zu den indirekten Zielen von RMI gehört ein Lastausgleich, sowie die Erhöhung der Skalierbarkeit von Programmen. Dies alles hat uns zur Entscheidung gebracht, RMI für die Kommunikation zwischen Client und Server zu verwenden.

39 3.5 Datenübertragung Serielle Übertragung (RS-232) Die Kommunikation zwischen dem Zentralrechner und dem Roboter wird über ein serielles Kabel (RS-232) abgewickelt. Die Schnittstelle wird von der Hardware des Roboters vorgegeben. Im Gegensatz zu der WLAN-Verbindung, sind hier keine allzu großen Schwierigkeiten bei der Übertragung zu erwarten. Vor allem deshalb, weil hier lediglich Steuerungsdaten, wie etwa Geschwindigkeit und Lenkeinschlag, zu übermitteln sind. Trotzdem gilt hierbei zu beachten, dass die Bandbreite für die Übertragung relativ begrenzt ist. Sie ist abhängig von der Länge des Kabels. Sie verläuft von nur wenigen 50 Bit/Sekunde bis maximal 460 Kilobit/Sekunde. Auch für diese Kommunikationsschnittstelle stehen eine Reihe von Technlogien zur Auswahl, die von uns untersucht wurden und in den nächsten Unterkapiteln beschrieben werden. Java Communications Die Java Communications API ermöglicht die Verwendung von Hardwareschnittstellen aus Java-Programmen. So können beispielsweise parallele, serielle oder USB-Schnittstellen verwendet werden. Die Communications API dient bei Java dazu, weitgehend plattformunabhängig auf diese Schnittstellen zugreifen zu können. Das Paket ist kein fixer Bestandteil der JDK, sondern muss gesondert von Sun heruntergeladen werden. Der aktuelle Link befindet sich unter Die Installation des Paketes ist aber vom verwendeten Betriebsystem abhängig. Der Grund liegt in der Tatsache, dass zwar der notwendige Sourcecode plattformunabhängig ist, jedoch intern das Paket auf native Routinen des jeweiligen Betriebsystem zugreift, welche bei der Installation zu beachten sind. Installation unter Windows Um die API in Windows verwenden zu können, sind folgende Schritte notwendig: Zuerst muss das entsprechende Paket von Sun herunter geladen werden. Es enthält Dokumentation, Beispielprogramme und die notwendigen Java- Erweiterungsdateien win32com.dll, comm.jar und javax.comm.properties. Um diese in die eigene Programmierumgebung einzubinden, müssen sie in die hier angegebenen Verzeichnisse kopiert werden, wobei jdk das Basis- Verzeichnis der JDK-Installation bezeichnen soll (also z.b. c:\jdk1.5). 1 win32com.dll wird ins Verzeichnis jdk\jre\bin kopiert. 2 comm.jar wird ins Verzeichnis jdk\jre\lib\ext kopiert. 3 Der CLASSPATH-Eintrag muss nicht geändert werden.

40 30 Kap. 3: Technologien Persönliche Erfahrung und Entscheidungsgrundlage Der Vorteil dieser API ist, dass sie weitgehend plattformunabhängig ist und kostenlos von Sun heruntergeladen werden kann, jedoch muss man sich vorher registrieren. Der Nachteil der Communications-API ist, dass die Installation und Konfiguration vom jeweilig verwendeten Betriebssystem abhängig ist. DaoCommNative.dll Von den Entwicklern der Robotersteuerung wird eine eigene Bibliothek, für das Ansprechen des Roboters, bereit gestellt. Die Bibliothek wurde für Windows entwickelt und steht als Dynamic Link Library (DLL) zur Verfügung, kann aber mit Java als Native Library eingebunden werden. Die Bibliothek bietet alle möglichen Funktionen für die Ansteuerung des Roboters. Persönliche Erfahrung und Entscheidungsgrundlage Der Vorteil liegt in der einfachen Handhabung. Die Library kümmert sich um die gesamte Protokollierung der zu versendenden Nachrichten. Aus der Sicht des Java Programmierers stehen eine Reihe von Funktionen zur Verfügung, welche die eigentlichen Steuerungs- und Kontrollbefehle des Roboters verkapseln. Jede Funktion liefert eine fix definierte Statusmeldung zurück, aus der ersichtlich wird, ob der Befehl erfolgreich dem Roboter übergeben worden ist. Ein Fehler in der Komunikation oder gar ein Verbindungsabbruch kann so leicht analysiert werden. Der große Nachteil dieser Library besteht darin, dass sie nur unter Windows lauffähig ist und somit die Plattformunabhängigkeit von Java zu nichte macht. 3.6 Speicherung Jedes professionelle Programm sollte die Möglichkeit bieten, Programmeinstellungen speichern zu können. Systemeinstellungen können so, den Wünschen des Anwenders entsprechend, leicht angepasst werden. Für die Java-Umgebung gibt es auch hierfür eine Reihe von Möglichkeiten, die nun in den nächsten Unterkapiteln vorgestellt werden Extensible Markup Language (XML) Für das Speichern der Daten bietet sich in vielen Fällen das XML-Format an. Es gibt eine Reihe von Parsern, welche die grundlegenden Funktionen für die Verarbeitung der Daten übernehmen. Für XML-basierte Parser gibt es drei verschiedene Verarbeitungstypen:

41 3.6 Speicherung 31 Push-API: Nach dem Callback-Prinzip ruft der Parser Methoden über Ereignisprozeduren auf und meldet so das Vorhandensein eines Elements. Der populärste Vertreter diser Methode ist Simple API for XML (SAX). Pull-API: Wie mit einem Tokenizer wird über die Elemente gegangen. Der populärste Vertreter dieser Methode ist Streaming API für XML (StAX), eine konkrete Umsetzung ist zum Beispiel der XML Pull Parser (XPP). DOM-orientierte APIs: Repräsentieren den gesamten XML-Baum im Speicher. Vertreter dieser Methode sind zum Beispiel W3C-DOM, JDOM, dom4j und XOM. Simple API for XML (SAX) SAX wurde entwickelt, um das schnelle Verarbeiten der Daten zu ermöglichen. Es ist kontrovers zu DOM und nicht so speicherhungrig, da das XML- Dokument nicht vollständig im Speicher abgelegt ist. Aus diesem Grund ist es vor allem für sehr große Dokumente prädestiniert. SAX basiert auf einem Ereignismodell, wonach die XML-Datei wie ein Datenstrom gelesen wird. Darauf folgend wird für erkannte Elemente ein Ereignis ausgelöst. Dieses Verfahren hat allerdings einen Nachteil: Ein wahlfreier Zugriff auf die einzelnen Elemente ist hier nicht möglich. Die durch das Ereignismodell gelieferten Elemente müssen zwischengespeichert werden. Streaming API für XML (StAX) Im Gegensatz zu den Push-APIs, bei denen die Methoden beim Parsen bereitgestellt werden, wird bei StAX aktiv der nächste Teil eines XML-Dokuments angefordert. Dieses Prinzip beruht auf dem Iterator Design-Pattern, welches auch von der Collection-API bekannt ist. Dabei werden die beiden grundsätzlichen Verarbeitungsmodelle Cursor und Iterator unterschieden. Die Verarbeitung mittels Cursor ist einfacher und schneller, jedoch nicht so flexibel. Die Iterator-Verarbeitung ist im Gegenzug dazu flexibel, jedoch ein wenig aufwändiger als die Cursor-Verarbeitung. Trotz allem sind sich die beiden Formen sehr ähnlich. Document Object Model (DOM) Das Document Object Model ist eine Spezifikation des W3C. Es definiert eine Menge an programmiersprachenunabhängigen und abstrakten Schnittstellen. Darin enthalten ist der lesende und schreibende Zugriff auf wohlgeformte XML-Dokumente. Unterstützt wird aber auch HTML und eine Reihe weiterer Formate. Bei DOM-orientierten APIs wird das ganze XML-Dokument im Speicher gehalten, wodurch ein wahlfreier Zugriff auf die einzelnen Elemente

42 32 Kap. 3: Technologien ermöglicht wird. Bei besonders großen Dokumenten kann es aber dadurch in einigen Fällen zu Problemen kommen. Einige, speziell für Java abgestimmte APIs, werden nun in den nächsten Unterkapiteln vorgestellt: Java API for XML Processing (JAXP) Die bereits erwähnten Technologien wie DOM, SAX, XPath, StAX sind erst einmal reine APIs. Grundsätzlich sind für diese APIs verschiedene Implementierungen denkbar, jeweils mit Schwerpunkten wie Speicherverbrauch, Performance, Unicode-4-Unterstützung und so weiter. Die Abhängigkeit von bestimmten Klassen stellt einen Nachteil bei einer direkten Nutzung der Parser dar. Sun hat aus diesem Grund eine eigene API mit dem Namen Java API for XML Processing (JAXP) entwickelt, die als Abstraktionsschicht über folgende Technologien liegt: DOM (Level 3) SAX (Version 2.0.2) StAX XSLT (Version 1.0) XPath (Version 1.0) Java-Based Document Object Model (JDOM) Document Object Model (DOM) ist eine von vielen Programmiersprachen unterstütze Entwicklung von W3C. Das Standard-DOM ist so konzipiert, dass es eine strikte Hierarchie erzeugt wird und somit die Unabhangigkeit einer Programmiersprache gegeben ist. Um XML-Dokumente leicht und effizient mit einer programmierfreundlichen Java-API nutzen zu können, ist JDOM prädestiniert. Ähnlich wie beim Document Object Model, wird ein XML-Dokument als Baum im Hauptspeicher repräsentiert, jedoch wurde JDOM speziell für Java entwickelt. JDOM ist in der Lage, SAX-Ereignisse auszulösen, wodurch eine Zusammenarbeit von JDOM mit SAX ermöglicht wird. Die Ergebnisse von JDOM können so mit SAX-basierten Tools weiterverarbeitet werden. JDOM lässt sich auch sehr gut in Umgebungen einsetzen, in denen weitere Tools zur Verarbeitung von XML genutzt werden Datenspeicherung mit Java Java selbst bietet eine Reihe von Möglichkeiten, um Systemeinstellungen persistent zu speichern. Die wichtigsten Vertreter werden in den nächsten Unterkapiteln erläutert:

43 3.6 Speicherung 33 Java I/O In Java fix integriert befindet sich das Paket java.io.*. Hierbei handelt es sich um das grundlegende Paket für die Ein- und Ausgabe von Daten und ermöglicht so die dauerhafte und flexible Speicherung der Daten auf einen Datenträger. Nachteilig ist, dass sich der Anwendungsprogrammierer selbst um alle Details der Speicherung und vor allem der Organisation (Aufbau) der Dateien kümmern muss. Java Properties Bis einschließlich JDK 1.3 galten Property-Dateien als adäquate Mittel zur persistenten Speicherung von System- und Benutzereinstellungen in Java- Anwendungen. Property-Dateien weisen jedoch den Nachteil auf, dass man zum Speichern und zum Laden immer den genauen Pfad kennen muss, unter welchem die jeweilige Property-Datei zu finden ist. Der Grund liegt in dem Zustand, dass es kein Standardverzeichnis gibt, in dem diese Dateien abgelegt werden. Weiters wird keine hierarchische Strukturierung und Unterscheidung zwischen benutzerdefinierten und systemweiten Einstellungen unterstützt. Aus diesen Gründen sind Property-Dateien nur bedingt flexibel und die Verwaltung ist abhängig von einem proprietärem Code, welcher individuell entwickelt wird. Neben der Möglichkeit auf vom System vordefinierte Properties zu zugreifen, besteht auch die Option eigene Properties zu definieren, welche meist benutzerdefinierte Konfigurationseinstellungen enthalten. Diese werden üblicherweise gemeinsam mit dem Klassendateien abgelegt und werden so, als Ressource in die Anwendung geladen. Sinnvoll ist die Verwendung von derartigen Property-Dateien nur dann, wenn die Konfiguration einmal beim Deployment der Anwendung durchgeführt und danach nicht mehr geändert wird, denn die Property-Datei wird auf diese Weise als Teil der Klassen (z.b. in einem Java Archive) ausgeliefert und sollte vom Endanwender nicht editiert werden. Auf solche Property- Dateien ist der Zugriff nur lesend möglich und die Speicherung der Datei relativ zu einer Klassendatei ist nicht durchführbar. Falls der Wunsch besteht in einer Anwendung selbst eine Property-Datei zu schreiben, dann muss die Schreiboperation über File-Streams realisiert werden, welche direkt auf das Dateisystem zugreifen. Java Preferences Java Preferences ist die wohl mächtigste von Sun bereitgestellte API für das Speichern von Konfigurationsadateien. Hier eine Liste der wichtigsten Merkmale:

44 34 Kap. 3: Technologien Kapselung der zugrundeliegenden Speicherungsform. Die dabei entstehenden Einstellungen werden in einem plattformspezifischen Backing-Store abgelegt (z.b. Registry unter Windows, nicht sichtbare Dateien im Home- Verzeichnis unter Unix oder LDAP-Directory). Austausch von Einstellungen über ein XML-Format zwischen verschiedenen Plattformen. Unterstützung von System- und Benutzereinstellungen. Alle Einstellungen werden über das Preferences-API in einer hierarchischen Struktur abgelegt, wobei die Knoten Schlüssel-Wert-Paare enthalten (analog zur Windows-Registry). Dabei liegt eine Unterteilung in System- und Benutzerbereich vor: Systembereich: Hier sollten einmalig verfügbare, allgemeine oder programmbezogene Informationen gespeichert werden, wie beispielsweise das Installationsverzeichnis. Benutzerbereich: Hier sollten hingegen nur benutzerbezogene Einstellungen wie z.b. Fenstergröße oder Schriftart abgelegt werden. Für jeden Benutzer können spezifische Einstellungen abgelegt werden, indem jeder Betriebssystembenutzer über einen privaten Benutzerbereich verfügt. Alle diese Bereiche haben einen eigenen Wurzelknoten, wobei jeder der hierarchisch gegliederten Knoten einen Namen trägt und die Wurzelknoten durch ein Backslash zu trennen sind. Aufgrund dessen, dass der Benutzer- und Systembereich komplett voneinander getrennt sind, gibt es auch zwei unterschiedliche Wurzelknoten. Um einzelne Einstellungsknoten auffinden zu können, muss der Anwendungsprogrammierer vom Wurzelknoten über einen Pfad ausgehend suchen. Der Aufbau ähnelt einem Dateisystem, bei dem die Knoten die Verzeichnisse und Einstellungen die Rolle der Dateien übernehmen. Grundsätzlich werden alle Einstellungen im Preferences-API intern als Zeichenketten gespeichert. Trotzdem stehen dem Anwendungsprogrammierer eine Reihe von Datentypen zur Verfügung. Darunter sind neben Boolsche- Werte auch Ganzzahlige- und Kommawerte, sowie natürlich auch Zeichenketten enthalten. Abhängig vom verwendeten Betriebssystem, werden die Daten auf unterschiedliche Weise gespeichert. Um eine Plattformunabhängigkeit zu erreichen wird für den Anwendungsprogrammierer eine abstrakte Schnittstelle angeboten. Wie und wo die Daten tatsächlich abgespeichert werden, ist für die Anwendung somit irrelevant.

45 3.7 Protokollierung 35 Unter dem Betriebssystem Windows werden die Einstellungen in der Windows-Registry gespeichert. Der Wurzelknoten für den Benutzerbereich befindet sich in HKEY CURRENT USER/Software/JavaSoft/Prefs. Der Wurzelknoten für Systemeinstellungen ist HKEY LOCAL MACHINE/Software/Java- Soft/Prefs. Java-Einstellungen werden bereits an allen untergeordneten Knoten dargestellt. An den Datentypen in der Windows-Registry kann man erkennen, dass Java wirklich alle Einstellungen in Zeichenketten ablegt, obwohl auch die Registry mehrere Datentypen unterstützt. Unter Linux/Solaris werden die Einstellungen als versteckte Dateien gespeichert. Hierbei wird jeder Knoten auf ein Verzeichnis abgebildet und die Einstellungen, welche sich innerhalb des Knotens befinden, werden in einer XML-Datei abgelegt. Die Benutzereigenschaften landen bei Unix lokal unter HOME/.java/.userPrefs und die Systemeigenschaften liegen unter /etc/.java/.systemprefs. MAC OS X legt ebenfalls Dateien in einer XML-Datei ab, die Benutzereinstellungen werden im Verzeichnis HOME/Library/Preferences abgelegt. Durch die Implementierung einer benutzerdefinierten PreferencesFactory, kann man Einstellungen in einer SQL-Datenbank oder einem LDAP-Server speichern, insofern man nicht die vordefinierten Persistenz-Mechanismen nutzen möchte. 3.7 Protokollierung Im Laufe der Entwicklungsphase einer Anwendung ist es zur Gewohnheit geworden, dass Fehler mit Hilfe von Debuggern eliminiert werden, was als recht schnelle und zuverlässige Methode gilt. Im alltäglichen Produktionsbetrieb ist dies aber nicht mehr so leicht möglich. Hierbei hilft das Konzept des Loggings. Der System.out.println() Befehl, welcher häufig verwendet wird um bestimmte Warnungen zur Lokalisierung von Fehlern heraus zu geben, sollte jedem Java-Programmierer geläufig sein. Logging erstreckt sich jedoch weit über diese Funktion hinaus. Durch diese Anwendung können Fehler nicht nur zur Entwicklungszeit eingegrenzt werden. Es besteht auch die einfache Möglichkeit, Programmabläufe zu überprüfen. Sobald Logging-Routinen im Programm enthalten sind, können diese jederzeit aktiviert und dazu benutzt werden, die Überwachung des Verhaltens der Anwendung zur Laufzeit vorzunehmen. Durch die Loggersysteme wird dem Programmierer mehr alsnur die Fehlererkennung und deren Beseitigung erleichtert. Durch dieses System wird sogar die Wartung und Überwachung einer Applikation drastisch vereinfacht, indem zum Beipsiel die Ressourcenverwaltung, auftretende Fehler oder Systemabstürze aufgezeichnet werden und somit später ausgewertet werden

46 36 Kap. 3: Technologien können Java Logging API Ein eigenes Logging-Interface wird seit der Version 1.4 des Java Development Kits von Sun zur Entwicklungsumgebung mitgeliefert. Es ist im Paket java.util.logging abgelegt. Es bietet unter anderem die Möglichkeit mehrerer Log Levels, verschiedener Ausgabeformate und dynamischer Konfigurationen. Zu den geläufigsten Funktionen der Java Logging API zählen Logger, Log Levels, Handler, Formatter und Log Manager. Nachstehend wird erklärt, wie die einzelnen Klassen zur Anwendung kommen. Logger Ein Logger ist ein Pflichtbestandteil, der in jede Applikation implementiert werden muss, insofern von dieser aus etwas gelogged werden soll. Jeder Logger ist namentlich benannt, wobei der verwendete Name normalerweise auf dem Namen des Paketes und dem Klassennamen basiert. Diese Namen bestehen aus einer Punkt-Zeichen-Sequenz, welche hierarchisch im sogenannten Namespace geordnet sind. Verschiedene Optionen ermöglichen es auch, anonyme Logger zu erstellen, welche nicht in die Logger Hierarchie aufgenommen werden. Log Levels Um die Dringlichkeit einer Meldung festzulegen, werden die Log Levels der Java Logging API genutzt. Eine Reihe von standardisierten Dringlichkeitsstufen, welche beispielsweise für die Steuerung der Logging Ausgabe verwendet werden, sind in die Klasse Level enthalten. Die Log Levels in absteigender Ordnung sind: 1 SEVERE (höchste Dringlichkeit) 2 WARNING 3 INFO 4 CONFIG 5 FINE 6 FINER 7 FINEST (niedrigste Dringlichkeit) Weiters gibt es noch die Level ALL und OFF, um jede Meldung zu loggen bzw. um das Logging auszuschalten. Durch eine Initialisierung eines Loggers mit einem gewissen Log Level, werden alle Meldungen mit diesem Level und mit allen darüber liegenden aufgezeichnet.

47 3.7 Protokollierung 37 Handler Jedem Logger ist der Zugriff auf eine Anzahl von Handlern gewährleistet. Ein Handler Objekt bekommt eine Log-Meldung von einem Logger übergeben und exportiert diese zu einem bestimmten Ziel. ConsoleHandler: Gibt die Log-Meldung auf der Konsole aus. FileHandler: Schreibt die Log-Meldung in eine Datei. MemoryHandler: Legt die Log-Meldung in einem Puffer ab. SocketHandler: Schreibt die Log-Meldung auf einen Socket. StreamHandler: Schreibt die Log-Meldung in einen OutputStream Es besteht auch die Möglichkeit, mehrere Handler hintereinander zu schalten, wodurch es beispielsweise möglich wäre, einen File-Handler hinter einen Memory-Handler zu schalten. Formatter Im Regelfall besitzt jeder Handler einen Formatter, durch welchen das Format der Log-Meldung vorgewählt werden kann. Zur Zeit stehen folgende Formatter zur Verfügung: SimpleFormatter: Generiert die Log-Meldung als Klartext XMLFormatter: Generiert die Log-Meldung im Standard XML Format Log-Manager Eine zentrale Komponente der Logger stellt der Log-Manager dar. Folgende Funktionen werden durch diese Komponente bereitgestellt: Verwaltung und Erstellung der Logger im Namespace Erzeugen von anonymen Loggern Verwaltung der Konfigurationseinstellungen Systemweit ist nur ein globales Exemplar des Log Managers verfügbar Jakarta Log4J Log4j ist eine populäre JAVA Logging-API, welche den Anwendungsprogrammieren eine feingranulare Kontrolle über die einzelnen Logausgaben erlaubt. Dadurch ist eine Reduzierung der Menge an Logausgaben, bei gleichzeitiger Verminderung der Kosten, für das Logging möglich. Der Verwaltungsaufwand ist bei der Anwendung von Log4j sehr gering gehalten, denn sind die Log- Anweisungen einmal im Code, können sie ganz einfach durch entsprechende Konfigurationsdateien aktiviert bzw. deaktiviert werden.

48 38 Kap. 3: Technologien Die aktuelle Version von Log4j kann einschließlich Dokumenation und vollständigen Quellcode von als Freeware herunter geladen werden. Die Installation dieser Anwendung ist einfach zu handhaben, es muss lediglich das ausgepackte Java-Archiv in den Klassenpfad aufgenommen werden. Log4j beinhaltet drei Hauptkomponenten:Loggers, Layouts und Appenders. Loggers Loggers sind benannte Entitäten, bei denen die Groß- und Kleinschreibung der Buchstaben berücksichtigt wird. Die Namen folgen dabei einer hierarchischen Namenskonvention. Die einzelnen Generationen (oder auch Hierarchieebenen) werden mit einem Punkt getrennt. Beispiel org.apache ist eine Obermenge von org.apache.log4j, oder anders ausgedrückt org ist der Vater von org.apache. An der Spitze der Hierarchie ist stets der Root-Logger, welcher immer existiert und keinen Namen trägt. Dem Logger können folgende Standard Levels zugeordnet werden: TRACE, DEBUG, INFO, WARN, ERROR und FATAL. Bei diesen Levels gibt es ebenfalls eine Rangordnung. Hierbei gilt: TRACE < DEBUG < INFO < WARN < ERROR < FATAL. Appenders Ein Teil des Funktionsumfangs von Log4j ist es, Logger-Meldungen selektiv ein- oder auszuschalten. Das Versenden der Logger-Meldungen an verschiedene Standorten, sogenannten Appenders, ist möglich. Folgende Appenders werden zurzeit unterstützt: Unix Syslog Deamon Java Message Service (JMS) NT Event Logger Remote Socket-Server (Stichwort zentrale Überwachung) Dateien (klassische Logger-Dateien) GUI-Komponenten Konsolen An jeden Logger können mehrere Appenders angehängt werden. Somit kann also die gleiche Meldung in eine Logdatei und an einen Remote-Socker-Server versandt werden. Layouts Bei Log4j ist es möglich die Meldungen mit Hilfe von Layouts zu formatieren. Dadurch kann eine bessere Lesbarkeit erreicht werden.

49 3.8 GUI Librarys GUI Librarys Da bei Java die Standardlayoutmanager recht komplex in der Anwendung und in der Verständlichkeit sind, wird in diesem Projekt die forms-bibliothek von JGoodies verwendet. Außerdem sollte eine Applikation auch ansprechend sein, deswegen wird die substance-bibliothek verwendet. In den Folgenden zwei Unterkapiteln werden diese Bibliotheken beschrieben substance - look and feel library Die substance-bibliothek ist eine Look and Feel Bibliothek welche mehrere sogenante Skins beinhaltet. Weiters kann man Komponenten zusätzlich noch beeinflussen, insofern man zum Beispiel bei einem Button die Ränder entfernen will. Dies geschieht über die sogenannten ClientProperties. Um substance verwenden zu können, muss man lediglich dem UIManger das gewünschte Look and Feel angeben. In dem folgenden Codebeispiel wird ein JFrame mit dem BusinessBlackSteel-Look and Feel erzeugt. public s t a t i c void main ( S t r i n g [ ] a r g s ) throws Exception { UIManager. setlookandfeel (new SubstanceBusinessBlackSteelLookAndFeel ( ) ) ; JFrame. setdefaultlookandfeeldecorated ( true ) ; S w i n g U t i l i t i e s. i n v o k e L a t e r (new Runnable ( ) { public void run ( ) { new JFrame ( ). s e t V i s i b l e ( true ) ; } }) ; } In Abbildung 3.9 wurden die Buttons mittels den Clientproperties verändert. Es wurden alle vier Seiten entfernt, außerdem wurde das Flat Property gesetzt, damit der Button flach aussieht und zum Schluss wurde noch der ButtonShaper neu gesetzt, da bei diesem Look and Feel sonst der Button eine eliptische Form gehabt hätte. Abb. 3.9: Konfigurationspanel der Clientanwendung In dem folgeden Codebeispiel kann man sehen wie die Properties gesetzt werden.

50 40 Kap. 3: Technologien this. p u t C l i e n t P r o p e r t y ( SubstanceLookAndFeel.FLAT PROPERTY, Boolean.TRUE) ; this. p u t C l i e n t P r o p e r t y ( SubstanceLookAndFeel.BUTTON SHAPER PROPERTY, new ClassicButtonShaper ( ) ) ; this. p u t C l i e n t P r o p e r t y ( SubstanceLookAndFeel.BUTTON SIDE PROPERTY, EnumSet. o f ( SubstanceConstants. Side. RIGHT, SubstanceConstants. Side.BOTTOM, SubstanceConstants. Side. LEFT, SubstanceConstants. Side.TOP) ) ; forms - swing layout manager Der forms-layoutmanager soll es dem Programmierer vereinfachen ein Layout zu erstellen. Er entspricht besser den menschlichen Vorstellungen als die herkömmlichen Layoutmanager wie z.b.: Gridbaglayout, Flowlayout, Boxlayout, usw. Der forms-layoutmanager folgt folgenden Prinzipien: Verwende einen Grid für einen einzelnen Container oder für viele Container. Trenne Eigenschaften. Stelle eine starke Layoutspezifizierungssprache zur Verfügung. Erlaube Stringrepräsentationen um den Code zu verkürzen. Grid Systeme sind einfach zu verstehen und werden von Designern oft verwendet. In manchen Layoutmanagern werden die Eigenschaften oft in einer einzelnen Klasse kombiniert: Die Spezifikation des Layouts, das Füllen des Panels mit den Komponenten und das Setzen der Komponentengrenzen. Auf der anderen Seite gibt es bei manchen Layoutmanager nicht die Möglichkeit gemeinsame Designs zu verwenden. Aus diesem Grund werden die Eigenschaften in verschiedene Klassen getrennt, damit man sie nachher nach Belieben kombinieren kann. Mit dem Formlayout beschreibt man das Design bevor das Panel befüllt wird und bevor die Komponentengrenzen gesetzt werden. Die Sprache ist so gestaltet, dass sich ein Anwendungsprogrammierer schnell vorstellen kann, wie das Design gestaltet ist. Um die Lesbarkeit weiter zu vebessern, ist es erlaubt den Grid in einer menschlich lesbaren Stringrepräsentation zu beschreiben. Darüberhinaus wird die Länge des Codes auf diese Weise stark verkürzt. Beispiel Am Anfang betrachten wir ein kleines Beispiel, um zu zeigen, wie leicht verständlich das FormLayout ist. Dieses Beispiel ist in Abbildung 3.10 zu sehen.

51 3.8 GUI Librarys 41 Abb. 3.10: Forms Beispiel Das hier generierte Form besteht aus fünf Zeilen und fünf Spalten. Angesprochen werden diese Felder mittels der CellConstraints, mit deren Hilfe man die einzelnen Komponenten in die richtigen Zellen platzieren kann. FormLayout l a y o u t = new FormLayout ( "pref, 4dlu, 50 dlu, 4dlu, min ", //column "pref, 2dlu, pref, 2dlu, pref " ) ; // rows this. setlayout ( l a y o u t ) ; this. add (new JLabel ( " Label 1" ), new C e l l C o n s t r a i n t s ( 1, 1) ) ; this. add (new JTextField ( ), new C e l l C o n s t r a i n t s ( 3, 1, 3, 1) ) ; this. add (new JLabel ( " Label 2" ), new C e l l C o n s t r a i n t s ( 1, 3) ) ; this. add (new JTextField ( ), new C e l l C o n s t r a i n t s ( 3, 3) ) ; this. add (new JLabel ( " Label 3" ), new C e l l C o n s t r a i n t s ( 1, 5) ) ; this. add (new JTextField ( ), new C e l l C o n s t r a i n t s ( 3, 5) ) ; this. add (new JButton ( "... " ), new C e l l C o n s t r a i n t s ( 5, 5) ) ; Zeilen und Reihen Spezifikation Die Spalten und Zeilendefinition wird mit Hilfe von drei Parametern, welche die Größe angeben, gemacht. Der nächste gibt die Standard Ausrichtung an und ist optional. Der letzte Parameter ist wieder optional und bestimmt das Verhalten beim Vergrößern oder Verkleinern. Man kann Instanzen von ColumnSpec und RowSpec verwenden oder man verwendet die String Repräsentation, die dann geparst wird und die Instanzen von ColumnSpec und RowSpec werden automatisch generiert. new FormLayout ( " right :pref, 10px, left : pref : grow ", // 3 columns "pref, 4px, pref, pref : grow " ) ; // 4 rows In dem vorangegangenen Codebeispiel kreierten wir ein Form mit drei Spalten und vier Zeilen. Alle Komponenten in der ersten Spalte werden rechts ausgerichtet und die Spaltengröße ist das Maximum der bevorzugten Breite von der innenliegenden Komponente. Die zweite Spalte definiert einen Abstand von 10 Bildpunkten. Die dritte Spalte ist links ausgerichtet und startet mit der maximalen Komponentenbreite und füllt den restlich verfügbaren Platz aus. ColumnSpec unterstützt folgende Ausrichtungen: left

52 42 Kap. 3: Technologien center right fill RowSpec unterstützt folgende Ausrichtungen: top center bottom fill Das sind Standardausrichtungen, die bei Bedarf für einzelne Komponenten überschrieben werden können. Eine Größe von Spalten und Zeilen kann folgendermaßen definiert werden: constant size component size bounded size Konstante Größen beginnen mit einem Wert, gefolgt von einer Einheit (Pixel, Points, Inches, Millimeter, Centimeter und Dialog Units - es können auch die Abkürzungen verwendet werden: px, pt, in, mm, cm und dlu). Komponentengrößen werden mit min, pref oder default angegeben. Das Vergrößerungsund Verkleingerungsverhalten wird mit einem nicht negativen Gewicht angegeben. In Tabelle 3.1 kann man sehen wie die Stringrepräsentation auszusehen hat. Komponentengrößen: Die Komponentengröße gibt der Zeile oder Spalte die Größe der innenliegenden Komponente an. Die Komponenten werden nach ihrer minimalen(min) oder gewünschten(pref) Größe gemessen. Dialog Units: Das Layout sollte sich anpassen, wenn Schriftgröße oder Auflösung verändert werden. Deswegen sollte man Dialog Units verwenden, da sie sich an der Schriftgröße orientieren und somit passt sich das Layout an, wenn Schriftgröße oder Auflösung verändert werden. Es gibt nur wenige Anwendungen, bei denen man Pixelwerte verwenden sollte, wie zum Beispiel bei einem Bild, dass nicht skalierbar ist. Bounded Sizes: Bounded Sizes erlauben es, obere und untere Grenzen für Spalten und Zeilen zu definieren, bevor sie verändert werden. Dies kann gemacht werden, um sicher zu stellen, dass ein Minimum oder Maximum einer Zelle nicht überschritten bzw. unterschritten wird.

53 3.8 GUI Librarys 43 columnspec ::= [columnalignment:] size [resizebehaviour] rowspec ::= [rowalignment:] size [resizebehaviour] columnalignment ::= LEFT CENTER RIGHT FILL L C R F rowalignment ::= TOP CENTER BOTTOM FILL T C B F size ::= constantsize componentsize boundedsize component- ::= MIN PREF DEFAULT M P D Size constantsize ::= integer integerunit double doubleunit integerunit ::= PX PT DLU doubleunit ::= IN MM CM boundedsize ::= MIN(constantSize;componentSize) MAX(constantSize;componentSize) resizebehaviour ::= NONE GROW GROW( double ) G( double ) Tab. 3.1: Stringrepräsentation Verhalten beim Vergroessern und Verkleinern: Spalten und Zeilen können wachsen, wenn der Layout Container größer wird als seine preferierte Größe. Standardmäßig wachsen die Zeilen und Spalten nicht. Der zusätzliche Platz wird an jene Spalten und Zeilen verteilt, die ein größeres Verkleinerungs- oder Vergrößerungsgewicht haben als 0.0 und zwar in dem Verhältnis wie auch die Gewichtung ist. Spalten und Zeilengruppen Spalten und Zeilengruppen werden dazu verwendet, einer Menge von Zeilen oder Spalten die gleiche Breite oder Höhe zuzuweisen. Dies ist wichtig, wenn man ein symmetrische oder besser ausbalancierte GUI gestalten will. Im folgenden Beispiel sind die Spalten zwei und vier gleich breit, die Zeile eins und vier haben die selbe Höhe und die Zeile zwei und drei haben die selbe Höhe. FormLayout l a y o u t = new Formlayout ( "p,d,p,d", "p,p,p,p" ) ; l a y o u t. setcolumngroups (new int [ ] [ ] { { 2, 4 } } ) ; l a y o u t. setrowgroups (new int [ ] [ ] { { 1, 4 }, { 2, 3 } } ) ; Zellen Bedingungen Jede Komponente die vom FormLayout verwaltet wird, besitzt ein dazugehöriges CellConstraint. Diese spezifiziert die Position und die Ausrichtung im Grid. Die Zeilen- und Spaltenagaben sind erforderliche Felder.

54 44 Kap. 3: Technologien Der Standardwert für Spalten und Zeilenausdehnung ist eins und die Ausrichtung wird von der jeweiligen Zelle und Spalte geerbt. Wenn es möglich ist, sollten die Ausrichtungen bei den Zeilen oder Spalten spezifiziert sein und nicht bei den jeweiligen Komponenten (dies erspart Wiederholungen im Source). Es gibt verschiedene Möglichkeiten die CellConstraints zu setzen: Die folgende Möglichkeit ist für den Menschen am leichtesten zu verstehen. C e l l C o n s t r a i n t s cc = new C e l l C o n s t r a i n t s ( ) ; cc. xy ( 2, 1) ; // second col, f i r s t row cc. xy ( 2, 1, " right, bottom " ) ; // a l i g n e d to r i g h t and bottom cc. xy ( 2, 1, "r, b" ) ; // a b b r e v i a t e d alignment cc. xywh ( 2, 1, 4, 3) ; // spans 4 c o l s, 3 rows cc. xywh ( 2, 1, 4, 3, " right, bottom " ) ; cc. xywh ( 2, 1, 4, 3, "r, b" ) ; Die zweite Möglichkeit verwendet Objekte statt Strings. Diese Art wird empfohlen, wenn nicht visuelle Builder verwendet werden. new C e l l C o n s t r a i n t s ( ) ; // f i r s t col, f i r s t row new C e l l C o n s t r a i n t s ( 2, 1) ; new C e l l C o n s t r a i n t s ( 2, 1, 4, 3) ; new C e l l C o n s t r a i n t s ( 2, 1, C e l l C o n s t r a i n t s.right, C e l l C o n s t r a i n t s.bottom) ; Die dritte Möglichkeit erlaubt die Angabe in einem einzigen String, um das CellConstraintobjekt zu erzeugen. C e l l C o n s t r a i n t s cc = new C e l l C o n s t r a i n t s ( ) ; new C e l l C o n s t r a i n t s ( "2, 1" ) ; new C e l l C o n s t r a i n t s ( "2, 1, r, b" ) ; new C e l l C o n s t r a i n t s ( "2, 1, 4, 3" ) ; new C e l l C o n s t r a i n t s ( "2, 1, 4, 3, r, b" ) ; Die String Syntax zur letzten Möglichkeit wird in der Tabelle 3.2 gezeigt: Eine detailierte Beschreibung kann dem Whitepaper auf der JGoodies Homepage [JGo09] entnommen werden. 3.9 Hardware In diesem Kapitel wird näher auf die Hardware eingegangen die wir verwendet haben, oder besser gesagt, für welche wir die Telecontrolling Software geschrieben haben Roboter Um das Fahrwerk des Roboter zu konstruieren, wurde ein Quad herangezogen und umgebaut. Es wurde der Benzinmotor gegen einen Elektromotor

55 3.9 Hardware 45 constraint ::= column, row [, colspan, rowspan][, halign, valign] column ::= integer row ::= integer colspan ::= integer rowspan ::= integer halign ::= LEFT CENTER RIGHT DEFAULT FILL L C R D F valign ::= TOP CENTER BOTTOM DEFAULT FILL T C B D F Tab. 3.2: Zellenkonstanten Stringrepräsentation ausgetauscht. Die Lenkung wird mittels zweier Servomotoren gesteuert. Weiters wurde ein Industriecomputer an dem Roboter angebracht und ein LCD Monitor in einem wasserdichten Gehäuse MOMO Racing Force Feedback Wheel Abb. 3.11: Logitech Lenkrad In Abbildung 3.11 ist jenes Lenkrad abgebildet, welches für die Steuerung des Roboters gedacht war. Steuerung Force-Feedback: Lassen Sie sich von der authentischen Richtungshilfe leiten. Sechs programmierbare Tasten: Meistern Sie Ihre Lieblings-Moves. Gas- und Bremspedale: Sofortige Reaktion mit den realistischen Pedalen mit Antirutschsystem.

56 46 Kap. 3: Technologien Schaltoptionen: Verwenden Sie entweder die Wippen am Lenkrad oder den manuellen Schalthebel. Komfort Lenkradring aus Vollgummi: Komfortabler Griff dank des nahtlosen Lenkradrings mit 28 cm Durchmesser. Haltevorrichtung mit drei Klemmen: Verrutschen oder Wackeln wird verhindert. Systemvoraussetzungen PC mit Pentium oder kompatiblem Prozessor 64 MB RAM 20 MB freier Festplattenspeicher CD-ROM-Laufwerk USB-Anschluss Windows 98 / 2000 / Me / XP / Vista Kameras Die auf dem Roboter eingesetzten Kameras stammen von der Firma Logitech R. Die genaue Bezeichnung lautet: QuickCam R Pro for Notebooks und ist in Abbild 3.12 ersichtlich. Die Kameras besitzen folgende Eigenschaften: Carl Zeiss R -Optik mit Autofokus: Diese Technik erlaubt laut Hersteller ein höheres Detailreichtum und Klarheit. Die Bilder sollen selbst bei Nahaufnahmen noch gestochen scharf erscheinen. Hohe Auflösung: Die Kameras liefern Videos mit einer Auflösung von 960 mal 720 Bildpunkten, was einer HD-Qualität entspricht. RightLight TM 2: Diese Technik passt die Bilder auch bei schlechter Beleuchtung oder bei Gegenlicht dynamisch an. Internes Mikrofon mit RightSound TM : Laut Hersteller können so deutlichere Gespräche ohne störendes Echo aufgenommen werden. Weitwinkelobjektiv und intelligente Gesichtsverfolgung: Hierzu liefert der Hersteler keine genaueren Angaben und ist anscheinend nur mit der mitgelieferten Software möglich. Verstellbare Monitorhalterung: Die Kameras können auf bis zu 20mm dicken Gegenständen befestigt werden. Tischständer: Mitgeliefert wurden auch 30,5cm hohe Tischständer, auf denen die Kameras montiert werden können.

57 3.9 Hardware 47 Abb. 3.12: QuickCam R Pro for Notebooks

58 48 Kap. 3: Technologien

59 4 Projektplanung Die Projektplanung in einem Softwareentwicklungsprozess ist einer der Hauptaufgaben des Projektmanagements. Besonders wichtig ist es, die einzelnen Projektschritte zu planen, um eine Software strukturiert zu entwickeln. Die Projektanforderungen müssen zuerst spezifiziert werden. Was will der Kunde? Ist das Projekt technisch umsetzbar? Hat das Projektteam das notwendige Know-How, um das Softwareprojekt durchzuführen? Das sind nur einige Hauptfragen, die zuerst betrachtet werden müssen. 4.1 Softwareentwicklungsprozess Der Softwareentwicklungsprozess ist ein sehr komplexer Vorgang. Es gibt verschiedene Modelle, mit deren Hilfe das Vorgehen der Softwareentwicklung festgelegt wird, beispielsweise Wasserfall-Modell, V-Modell, Spiralenmodell, oder der Rational Unified Process. Wir haben uns für die objektorientierte Vorgehensweise des Rational Unified Process entschieden. Der Rational Unified Process bzw. RUP stützt sich primär auf Anwendungsfälle und benutzt die Unified Modelling Language (UML) als Notationssprache. Wie die Grafik in Abbildung 4.1 veranschaulicht, legt der RUP sechs grundlegende Arbeitsschritte bzw. Workflows fest. 1 Geschäftsprozessmodellierung (Business Modeling) 2 Anforderungsanalyse (Requirements) 3 Analyse und Entwurf (Analysis and Design) 4 Implementierung (Implementation) 5 Test (Test) 6 Installation (Deployment)

60 50 Kap. 4: Projektplanung Abb. 4.1: RUP Modell [IBM07] Die sechs Workflows bilden den Grundstein jeder Software-Entwicklung. Der Verwendungszweck der einzelnen Workflows, wird hier kurz beschrieben. In dem Workflow Geschäftsprozessmodellierung werden zuerst alle Requirements des Kunden erfasst. Welche Prozesse sind für den Kunden wichtig? Es werden auch alle Arbeitsabläufe festgelegt. Mit der Hilfe von UML können Aktivitätsdiagramme erstellt werden, um die Arbeitsabläufe zu veranschaulichen. Auch die Entwicklungsumgebung muss hier festgesetzt werden. Wird mit anderen Systemen gearbeitet? Wenn ja, mit welchen? In der Anforderungsanalyse werden die Requirements der Software festgelegt. Use-Cases sind hier ein hilfreiches Mittel. Mit der Einbettung von Actors können sämtliche Use-Cases beschrieben werden. Sowie die Use-Cases festgelegt sind, wird auch die Software danach umgesetzt. In jedem Use-Case wird ein Standardszenario und Alternativszenarien beschrieben. Im Laufe der RUP-Phasen können sich Use-Cases auch ändern bzw. weiter entwickelt werden. In der Analyse- und Entwurfphase wird ein grobes UML-Klassendiagramm erstellt. Danach erfolgt über den Entwurf die Umsetzung der Softwareteile. Die Workflow Implementierung umfasst die weitergehende Umsetzung der Softwareteile in Programmcode. Eng gekoppelt mit der Workflow Implementierung erfolgt der Workflow Test. Nach jedem Durchlauf wird der Programmcode getestet. Fehler können da-

61 4.1 Softwareentwicklungsprozess 51 durch frühzeitig entdeckt werden. Auch die Funktionalität wird durch das Testen geprüft. Bei der Workflow Installation wird das Softwareprodukt für den Enduser zur Verfügung gestellt. Der RUP besitzt weiters noch drei Unterstützungsprozesse: Konfiguration- und Änderungsmanagement (Configuration and Change Management) Projektmanagement (Project Management) Umgebungsmanagement (Environment Management) Das Konfigurations- und Änderungsmanagement bietet zusätzlich Infrastruktur und Prozesse an, um neue Requirements und Verbesserungen so gut wie möglich systematisch zu erfassen. Wobei sich das Konfigurationsmanagement mit der Versionierung der Software beschäftigt. Um das Projektmanagement zu leiten, wird ein Verantwortlicher ausgewählt. Dieser Projektmanager hat die Aufgabe der Planung sämtlicher Phasen und Iterationen. Er ist für das ganze Team, sowie das Zeitmanagement verantwortlich. Gibt es Probleme muss der Projektmanager konsultiert werden. Der letzte Unterstützungsprozess ist das Umgebungsmanagement. Hier wird die Entwicklungsumgebung und auch alle Werkzeuge, die gebraucht werden, zur Verfügung gestellt. Die Hauptaufgabe des Umgebungsmanagements ist es, die Infrastruktur bereit zu stellen. Neben den Arbeitsschritten, die auf der vertikalen Achse liegen, repräsentiert die horizontale Achse die Zyklen, Phasen, Iterationen und Meilensteine. Diese Phasen gliedern sich in vier Hauptphasen: 1 Anfangsphase (Inception) 2 Ausarbeitungsphase (Elaboration) 3 Konstruktionsphase (Construction) 4 Übergangsphase (Transition) Der Zyklus der vier Hauptphasen ist abhängig nach Zeit und Ressourcen. Wie die folgende Abbildung 4.2 zeigt, wird für die Elaborationsphase die meiste Zeit in Anspruch genommen. Die notwendigen Ressourcen bilden auch hier den Hauptteil. Anhand der Zeit- und Ressourcenachse kann man den Entwicklungszyklus des Projekts deutlich erkennen.

62 52 Kap. 4: Projektplanung Abb. 4.2: RUP Phasen [IBM06] Im Folgenden werden die einzelnen Phasen des RUP kurz beschrieben und in späterer Folge auf das DAO-Softwareprojekt bezogen. Um einen allgemeinen Überblick des RUP zu gewähren, werden hier die Phasen erläutert Inception Phase Die Anfangsphase oder auch Inceptionphase genannt, setzt sich aus den wesentlichen Geschäftsfällen bzw. Anwendungsfällen auseinander. Hier erfolgt die genaue Spezifizierung der Vision des Endproduktes. In der Anfangsphase wird der Umfang des Softwareprojektes festgelegt, sowie Aufwandsabschätzungen und Risikoeinschätzungen vorgenommen. Das Hauptziel ist es, alle wichtigen Use-Cases zu identifizieren. Der Meilenstein dieser Phase ist die Zielsetzung. Wird dieser Meilenstein nicht erreicht, muss das SW- Projekt abgebrochen bzw. über eine Änderungen gesprochen werden. Der in Abbildung 4.3 dargestellte Use Case zeigt alle Funktionen, die mit dem System verbunden sind. Was kann ein User mit dem System machen? Ausnahmefälle werden hier noch nicht behandelt. Dieser Use Case beinhaltet alle Aktivitäten, die durch den User ausführbar sind. So kann sich der Benutzer am System anmelden und durch die Cursor-Tasten Steuerungsbefehle senden. Weiters kann er ein Video auswählen und das Mikrofon als Kommunikationsmedium nützen. Durch den Roboter kann ein User von außen lediglich ins Mikrofon vom DAO-Roboter sprechen. Durch einen Kommunikationskanal ist das System mit dem Roboter verbunden. Diese grobe Struktur beinhaltet die Hauptfunktionalität des Softwareprojekts.

63 4.1 Softwareentwicklungsprozess 53 Abb. 4.3: Use Case Elaboration Phase In der Ausarbeitungsphase wird die Architektur der Software geplant, die gebraucht werden, inklusive Ressourcen. Hier erfolgt die genaue Spezifizierung der Eigenschaften des Produktes. Der Meilenstein dieser Phase ist also die Architektur. Wenn dieser Meilenstein nicht erreicht wird, muss sowie in der Anfangsphase über ein Abbruch oder Änderung des Projektes nachgedacht werden.

64 54 Kap. 4: Projektplanung Die Architektur bzw. auch das Design muss im Vorfeld geplant werden. Das erste Design für die grafische Oberfläche wurde anhand des folgenden Entwurfs 4.4 entwickelt bzw. später weiterentwickelt. Abb. 4.4: Design-Entwurf GUI Construction Phase In der Konstruktionsphase wird das Software-Produkt erstellt. Die Implementierung und auch die Architektur des Projekts wird entwickelt bzw. weiter entwickelt. Mit dem Abschluss dieser Phase erfolgt das Endprodukt inklusive Benutzerhandbuch und Dokumentation. Der Meilenstein der Konstruktionsphase ist die erste Release der Software. Man spricht auch oft von einer Beta- Version, d.h die erste Inbetriebnahme der Software. Kann dieser Meilenstein nicht erreicht werden, muss die erste Release-Version weiter entwickelt werden Transition Phase In der Übergangsphase wird die Software zum ersten Mal für den End-User getestet. Hier erfolgt eine genaue Qualitätsprüfung, sowie Schulungen, Support und Wartung. In dieser Phase wird das Softwareprodukt für den Endbenutzer freigegeben. Der Meilenstein der Übergangsphase ist das fertige Produkt.

65 4.1 Softwareentwicklungsprozess Iterativer Ansatz Der RUP ist ein iterativer Prozess der risikoorientiert ist. Er baut auf das Spiralen-Modell auf. Nach jeder Iteration werden vorhandene Risiken reduziert. In jeder Iteration wird der gleiche Vorgang durchgeführt: 1 Planung 2 Spezifizierung, Design und Implementierung 3 Integration, Test und Entwicklung 4 Bewerten und Planen der nächsten Iteration Eine Iteration besteht aus den Schritten 1-4 und wird in jeder Phase wiederholt. Um den Vorgang besser zu visualisieren zeigt die folgende Abbildung 4.5 einen Überblick der Iteration über den Hauptworkflows. Abb. 4.5: RUP Iterativer Ansatz [IBM03] Es ergeben sich durch diesen iterativen Ansatz einige Vorteile gegenüber dem klassischen Wasserfallmodell. Es werden vorallem die Risiken minimiert und Änderungen im Projekt sind besser hand zu haben. Durch die Iterationen wächst auch die Qualität des Softwareprodukts.

66 56 Kap. 4: Projektplanung Statische Struktur Der Rational Unified Prozess besitzt eine statische Struktur. Bei jedem Workflow repräsentiert sich die Struktur wie folgt: Worker (Wer?) Aktivitäten (Wie?) Workflows (Wann?) Artefakte (Was?) Der Worker wird im Allgemeinen als Einzelperson oder auch als Gruppe von Personen gesehen. Speziell im RUP versteht man aber unter dem Begriff Worker eine Rolle. Diese Rolle kann bestimmte Tätigkeiten ausführen und besitzt eine bestimmte Anzahl von Artefakten. Ein Worker kann auch mehrere Rollen einnehmen. Also ist der Worker keine Person, sondern definiert lediglich einen Verantwortungsbereich. Ein Worker kann durch mehrere Personen repräsentiert werden. Weiters werden die einzelnen Aktivitäten von Workers durchgeführt. Als Output erhält man Artefakte. Sie beschreiben Produktteile eines Projekts. Der Begriff Artefakt findet speziell im RUP Anwendung und sind Dokumente die in Papierform vorliegen. Artefakte werden in folgende Sets laut Abbildung 4.6 kategorisiert. Abb. 4.6: RUP Artefakte[Cor03b]

67 4.1 Softwareentwicklungsprozess Architektur im RUP Der RUP ist ein architekturzentriertes Modell. Die Architektur des RUP umfasst die 4+1 Sicht. Durch diese Architektur werden unterschiedliche Sichtweisen laut der Abbidlung 4.7 deutlich. Abb. 4.7: RUP Sichten[Cor03a] Die logische Sicht beinhaltet die wichtigsten Klassen bzw. Komponenten auf der Designebene. Sie repräsentiert die Beziehungen zwischen den Klassen wie z.b.: die Vererbung. Die logische Sicht veranschaulicht im Wesentlichen, wie die Funktionen im System umgesetzt werden. Die Datenmodell Sicht stellt eine Verfeinerung der logischen Sicht dar. Sie spiegelt die Organisation der Schichten und Subsysteme wieder. Die Deployment Sicht wird ausschließlich für die Systemadministration verwendet. Sie beinhaltet Informationen über die Struktur des Systems und die Requirements an den Server, sowie Netzwerk und Hardware. Die Prozess Sicht visualisiert die Zusammensetzung der einzelnen Komponenten im Softwaresystem. Sie beinhaltet auch alle Zusatzanforderungen die gestellt werden. Weiters ist die sogenannte Use Case Sicht bzw. funktionale Sicht für das Anforderungsmanagement verantwortlich. Sie steht für die Interaktion zwischen User und System. Hier werden sämtliche Use Cases entwickelt. Grundsätzlich verwendet man die Architektur als Bauplan für das zu entwickelnde Softwaresystem. Ist die Architektur geplant, können die Use Cases und Komponenten erstellt werden. Der Workflow Analyse und Design schließt eine Lücke zwischen den Requirements des Kunden und der Implementierungsarbeit des Programmierers.

68 58 Kap. 4: Projektplanung 4.2 Aufteilung in Module Das Softwareprojekt lässt sich in verschiedene Teilmodulen gliedern. Da das Projektteam aus drei Projektmitgliedern besteht, gibt es für jedes Modul einen Betreuer der dafür verantwortlich ist. Folgende Teilmodule bzw. Aufgaben existieren beim DAO-SW-Projekt: Multimedia Windows Windows Installation für Client Auslesen der Video- und Audiodaten unter Windows Optimale Wiedergabe der Video- und Audiodaten Statistische Informationen für adaptives Streaming Betreuer: Marko Keuschnig Multimedia Linux Linux Installation für Server Effizientes ressourcenschonendes Auslesen der Video- und Audiodaten unter Linux Wiedergabe der Video- und Audiodaten Betreuer: Helmut Vaschauner De- und Encodierung De- und Encodierung der Video- und Audiodaten durch Zugriff auf die zur Verfügung gestellte Bibliothek Adaptives Streaming Versand der Daten via UDP und Wireless LAN Betreuer: Helmut Vaschauner GUI Windows Benutzeroberfläche Kamerawahl Robotersteuerung Einstellungen Betreuer: Marko Keuschnig

69 4.2 Aufteilung in Module Kommunikationskanal Kommunikationskanal zwischen Roboter und RCU herstellen sichere TCP Verbindung ständiges senden eines Lebenssignales Verbindungsabbruch-Handling Betreuer: Simona Jammer Robotersteuerung serielle Schnittstelle konfigurieren verarbeiten der Robotersteuerungsbefehle Einbinden der DLL Ansprechen der Robotersteuerungs-Schnittstelle Abbruchbedingungen falls kein Lebenssignal mehr empfangen wird Betreuer: Simona Jammer

70 60 Kap. 4: Projektplanung 4.3 Meilensteine Um ein Softwareprojekt umzusetzen, ist ein gutes Projektmanagement notwendig. Wie schon im Kapitel 4.2 beschrieben, legt der Rational Unified Prozess (RUP) nach jeder Phase einen Meilenstein fest. Meilensteine sind Ereignisse, die erreicht werden müssen, um ein Softwareprojekt fortzusetzen. Sie sind sogenannte Zwischenziele und bringen das Projekt Stück für Stück weiter Meilenstein 1 Abb. 4.8: Meilenstein 1

71 4.3 Meilensteine Meilenstein 2 Abb. 4.9: Meilenstein 2

72 62 Kap. 4: Projektplanung Meilenstein 3 Abb. 4.10: Meilenstein 3

73 4.4 COCOMO - Aufwandabschätzung COCOMO - Aufwandabschätzung Die Aufwandsabschätzung und Kostenabschätzung in einem Softwareprojekt ist ein sehr wichtiger Aspekt. Sind Kosten und Aufwände etwa zu hoch, muss überlegt werden, ob sich das Projekt auch wirtschaftlich rentiert. Daher ist es notwendig, schon im Vorfeld die Aufwände und Kosten für das Softwareprojekt genauer unter die Lupe zu nehmen. Ein Kostenmodell für die Softwareentwicklung ist das sogenannte COCO- MO (COnstructive COst MOdel). Es wird primär zur Kosten- bzw. Aufwandsschätzung benutzt. COCOMO verwendet mathematische Funktionen, solche Metriken bzw. Werte liefern einen recht guten Schätzwert in Verbindung mit den Kosten des Softwareprojekts. Auch verschiedene Parameter werden in die Kostenberechnung miteinbezogen. Wie viele Personenmonate bzw. Personenjahre werden gebraucht, um ein Softwareprojekt abzuschließen? Somit kann auch die Gesamtdauer des Softwareprojekts abgeschätzt werden. Das COCOMO-Modell behauptet sich mittlerweile schon in der Großindustrie und hat gute Erfahrungswerte nachzuweisen. Wie die Softwaremetriken genau im COCOMO definiert sind, wird hier folgend beschrieben. Der Hauptkostenfaktor d.h. Cost Driver für das COCOMO-Modell sind die Delivered Source Instructions (DSI). Hier werden die Codezeilen, die für das Projekt notwendig sind ermittelt. Die Einheit erfolgt in KDSI, d.h ein KDSI hat 1000 Instruktionen. Diese Einheit umfasst aber nur den reinen Code, der als Softwarendprodukt an den Kunden übergeben wird. Ein Code der für Testzwecke oder Support geschrieben wurde, wird hier nicht einbezogen. Abhängig von der Programmiersprache kann die Größe schwer abgeschätzt werden und wird im COCOMO nicht behandelt. Die Source Instructions sind eigentlich nur geschriebener und ausführbarer Code d.h. Delivered Source Instructions, wie auch Codezeilen oder Function Points, sind reine Metriken zur Größenbestimmung einer Software. Um ein Softwareprojekt zeitlich abzugrenzen, muss eine Entwicklungsperiode festgesetzt werden. Der Beginn einer Periode fängt mit dem Start des Produktdesigns an und endet mit dem Projektabschluss und Tests. Weitere Phasen die zu dem Projekt gehören, werden getrennt ermittelt. Gerechnet wird in COCOMO- Personenmonat bzw. Staff Month (SM). Ein Personenmonat besteht laut CO- COMO aus 152 Arbeitsstunden. Voraussetzung von COCOMO ist es auch, dass sich die Requirements nicht grundlegend ändern. Wird eine signifikante Anforderungsänderung vorgenommen, wird auch die Aufwandsabschätzung dahingehend geändert.

74 64 Kap. 4: Projektplanung Entscheidend für das COCOMO-Modell ist auch die Bestimmung der Komplexität. Man unterscheidet zwischen Organic Mode Semi-Detached Mode Embedded Mode Die drei werden in einfachen ( organic mode ), mittelschweren ( semi-detached ) oder komplexen ( embedded ) Softwareprojekten kategorisiert. Diese verschiedenen Projektmodi sind maßgebend für die COCOMO-Berechnung. Je nach Komplexität ändern sich die Koeffizienten, wobei die Formel gleichbleibend ist. Welche Werte die Kriterien der verschiedenen Modi aufweisen, zeigt die folgende Tabelle 4.1. Kriterium Organic Semi-detached Embedded Verständnis der Produktziele stark mittel schwach Know-How ähnlicher SW-Projekten stark mittel schwach Entwicklung komplexer Algorithmen minimal wenig beträchtlich Produktgröße 50KDSI 300KDSI alle Größen Tab. 4.1: Kriterien der Modi Organic Mode Im Organic Mode werden kleinere Softwareprojekte behandelt. Hier haben die Mitarbeiter meist einschlägige Erfahrungen mit ähnlichen Softwareprojekten, daher ist eine Einarbeitungsphase oft nicht so zeitaufwendig. Auch die Entwicklungsumgebung bleibt meistens gleich, d.h die Mitarbeiter arbeiten mit Ihnen schon bekannten Technologien. Deshalb wird hier die Aufwandsabschätzung anders kalkuliert Semi-Detached Mode Der Sem-Detached Mode ist eine Kombination zwischen Organic und Embedded Mode. Dieser Mode ist für mittelgroße Softwareprojekte geeignet. Um eine Vorstellung der Größenordnung zu gewinnen liegt der KDSI zwischen 50 und 300. Projekte die in diesem Modus liegen, sind schon komplexer. Das Projektteam weist meistens ein gemischtes Know-How auf. In einem Projektteam arbeiten Mitarbeiter, die mit der Technologie vertraut sind, jedoch auch unerfahrene Mitarbeiter.

75 4.4 COCOMO - Aufwandabschätzung Embedded Mode Im Embedded Mode sind die Projekte von einer anderen Komplexität. Hier werden auch Sicherheitsaspekte in ein Projekt hineinbezogen. Beispielsweise Systeme für Banken, oder auch Flugassistenzsysteme arbeiten mit dem Embedded Mode. Dieser Mode ist meist für Neuentwicklungen gedacht. Kennzeichnend für diesen Mode existiert auch dementsprechend eine lange Analyseund Design-Phase. Mit dem Abschluss dieser Phasen, werden gleichzeitig mehrere Programmierer mit dem Projekt beauftragt. Allein der Testaufwand liegt bei Embedded Mode Projekten schon bei einem fast so großem Aufwand wie bei Projekten im Organic Mode Aufwandberechnung Welche Koeffizienten die verschiedenen Modi besitzen, zeigt die folgende Tabelle 4.2. Anhand dieser Werte kann man die Personenmonate errechnen. Modi a b Organic Semidetached Embedded Tab. 4.2: Koeffizienten COCOMO Die Berechnung erfolgt nach einer mathematischen Formel: P ersonenmonat = a KDSI b (4.1) Anhand dieser Berechnung kann man den Aufwand in Personenmonate ermitteln. Bei unserem DAO-Projekt haben wir einen KDSI von 8. Als Modi wird der Organic-Mode ausgewählt, da der Umfang einem kleinen Projekt gleicht. P M = = 22 Als Ergebnis erhalten wir 22 Personenmonate. Nachdem die Kosten und Aufwände abgeschätzt wurden, erfolgt ein Plan für die genaue Phasenplanung und vorgesehene Dauer. Die Aufteilung variiert je nach Größe des Projekts. Beispielsweise werden bei größeren Softwareprojekten mehr Zeit für Integration und Test vorgesehen. Kleine Projekte, wie das DAO-Projekt, besitzen eine gleichmäßigere Arbeitsverteilung über den gesamten Entwicklungsprozess und benötigen für Integration- und Test

76 66 Kap. 4: Projektplanung eher weniger Ressourcen. Die folgende Abbildung 4.11 zeigt die prozentuelle Verteilung des Aufwands in den verschiedenen Phasen. Abb. 4.11: COCOMO Aufwandschätzung in den Phasen [Mau02] Die zweite Spalte bezieht sich genau auf unser DAO-Projekt mit 8 KD- SI. Wie in der Grafik 4.11 ersichtlich ist, liegt der Hauptaufwand in der Implementierungs- und Testphase. Je kleiner das Projekt ist, desto aufwendiger wird auch der Feinentwurf der Entwicklungsphase. Die Tabelle 4.11 gibt einen Gesamtüberblick aller Projektgrößen mit den verbundenen prozentuellen Aufwänden.

77 4.5 Zeitmanagement Zeitmanagement Ein gutes Zeitmanagement ist für die Softwareentwicklung sehr wichtig. Deadlines müssen eingehalten werden, denn der Kunde will das Endprodukt termingerecht geliefert bekommen. Das Einteilen der Aufgaben, Termine etc. ist nicht immer einfach. Speziell in der Softwareentwicklung kann sich das Zeitmanagement auch während des Projektes ändern bzw. verlängern. Um unvorhergesehene Ereignisse zu planen, sind Strategien und Techniken unerlässlich. Nachdem im Kapitel 4.4 sämtliche Aufwände durch das COCOMO-Modell kalkuliert wurden, wird im COCOMO auch die zeitliche Abschätzung behandelt. Die folgende Tabelle veranschaulicht eine prozentuelle Verteilung des Zeitaufwandes in den einzelnen Phasen. Ausgegangen wird vom Organic Mode, da das DAO-Projekt einen KDSI von 8 hat. Interessant ist die zweite Spalte der Tabelle Abb. 4.12: COCOMO Zeitschätzung in den Phasen [Mau02] Die Abbildung 4.12 zeigt prozentuell die Abschätzung der Zeit in den einzelnen Phasen. Der größte Zeitaufwand liegt in der Feinentwurf bzw. Implementierungsphase. Mit 59 Prozent des gesamten Zeitaufwandes muss in dieser Phase gerechnet werden und bildet somit den Hauptanteil des Projektes. An zweiter Stelle mit 22 Prozent, wird der Zeitaufwand für Integration und Test veranschlagt. Diese Werte decken sich im nachhinein sehr mit der tatsächlichen Projektdauer.

78 68 Kap. 4: Projektplanung Zur Berechnung der Dauer wird laut COCOMO folgende Formel herangezogen: T DEM = a P M b (4.2) Weiters werden die Koeffizienten für die Berechnung benötigt, die aus der Tabelle 4.3 entnommen wurden. Entwicklungsmodus Aufwand (PM) Dauer Organic 2.4KDSI P M 0.38 Semidetached 3.0KDSI P M 0.35 Embedded 3.6KDSI P M 0.32 Tab. 4.3: Koeffizienten für Aufwand und Dauer T DEM = = 8Monate Nach der Berechnung der geschätzten Dauer von 8 Monaten, wird die Anzahl der Personen die für das Projekt gebraucht werden berechnet. Man nehme den errechneten Aufwand von 22 Personenmonate und dividiert diesen Wert durch die Dauer von 8 Monaten. Das Ergebnis beträgt 3 Personen. Unser DAO-Projekt sollte daher 3 Projektmitglieder besitzen, was natürlich auch der Fall ist. Durch diese Berechnungen kann man ganz einfach sehr gute Schätzungen für die Softwareentwicklung tätigen.

79 4.6 Risikoanalyse Risikoanalyse Eine Risikoanalyse ist ein wichtiger Bestandteil jeder Softwareentwicklung. Es kann immer zu bestimmten Gefahrensituationen in Softwareprojekten kommen. Wer eine Risikoanalyse vorbereitet hat, kann diese Risiken abschwächen oder vermeiden. Risiken treten in der Regel bei jedem Softwareprojekt auf. Es können Probleme mit dem Projektpersonal entstehen oder auch in Verbindung mit der neuen Technologie. Die einzelnen Risikoelemente, die im Zusammenhang mit dem Projektteam entstehen können, werden hier kurz geschildert. In den folgenden Tabellen werden mehrere Attribute herangezogen. Gewichtet wird die Eintrittswahrscheinlichkeit der einzelnen Risikoelemente und auch die Priorität des Risikos. Mögliche Indikatoren, die ausschlaggebend für das Risiko sind, bzw. einen Plan zu erstellen wie Risiken vermindert werden können, werden hier ebenfalls behandelt. Der sogenannte Alarmplan ist die letzte Möglichkeit, um das Problem zu bewältigen. Die erste Tabelle 4.4 veranschaulicht jene Gefahr, wenn ein Projektmitglied für längere Zeit nicht zur Verfügung steht. Es kann Vorkommen das ein Teammitglied krankheitsbedingt ausfällt. Die Eintrittswahrscheinlichkeit ist in diesem Falle auf 0.5 gesetzt, was natürlich für das SW-Projekt schwerwiegende Folgen hat. Das Projekt wird sich um die Zeit des Ausfalles verlängern müssen. Risiko: Projektmitglied fällt längere Zeit aus Wahrscheinlichkeit: 0.5 Ausmaß: schwerwiegend Indikator: Krankheit, Unfall usw. Priorität: 2 Risiko-Minderung: Aufteilen der Arbeit Alarmplan: Verlängerung des Projekts um die Zeit des Ausfalles Tab. 4.4: Risikoelement Projektausfall Ein weiterer Risikofaktor ist mangelndes Know-How in einem Softwareprojekt. In der Regel weisen nicht alle Projektmitglieder das gleiche Wissen auf, so müssen jene Projektmitglieder mit fehlenden Erfahrungswerten sich in neue Technologien erst einarbeiten. Die Mitarbeiter müssen sich die Wissenslücken durch Fachliteratur oder Weiterbildungskurse aneignen.

80 70 Kap. 4: Projektplanung Risiko: Mitglieder haben fehlendes Know-How Wahrscheinlichkeit: 0.7 Ausmaß: schwerwiegend Indikator: wenig Erfahrung, ev. Kurse nicht absolviert Priorität: 2 Risiko-Minderung: Literatur/Internet, um Know-How zu erwerben Alarmplan: Projektleiter um Unterstützung bitten Tab. 4.5: Risikoelement Know-How Ein weiterer Risikofaktor, speziell während des 8-h Praktikums kann der Studiumswechsel eines Projektmitglieds sein. Auch diese Gefahr muss in Betracht gezogen werden, wobei die Eintrittswahrscheinlichkeit bei 0.01 liegt und daher sehr gering ist. Risiko: Projektmitglieder wechseln Studium Wahrscheinlichkeit: 0.01 Ausmaß: schwerwiegend Indikator: Student kündigt Wechsel an Priorität: 3 Risiko-Minderung: frühzeitiges Erfahren Alarmplan: Motivieren Tab. 4.6: Risikoelement Studiumwechsel Eine Gefahr, die sich sehr oft auch während unseres Studiums bemerkbar macht, sind Motivationsprobleme. Wichtig ist es, sich immer kleine Ziele zu setzen, um in kleinen Schritten zum Erfolg zu gelangen. Regelmäßiges Treffen der Teammitglieder kann die Motivationsprobleme minimieren bzw. vermindern. Risiko: Motivationsprobleme Wahrscheinlichkeit: 0.6 Ausmaß: mittel Indikator: andere Interessen / unpräzises Arbeiten Priorität: 2 Risiko-Minderung: unterstützen und motivieren / regelmäßiges Treffen Alarmplan: regelmäßiges Treffen / motivieren und unterstützen Tab. 4.7: Risikoelement Motivation

81 4.6 Risikoanalyse 71 Eine klare Aufgabenverteilung ist eine Voraussetzung um arbeiten zu können. Werden Aufgaben nicht eingeteilt, so kann es passieren, dass Mitarbeiter an den gleichen Aufgaben arbeiten und andere Aufgaben nicht erledigt werden. Ein Projektplan ist deshalb notwendig, um die strikte Aufgabenverteilung einzuhalten. Risiko: unklare Aufgabenverteilung Wahrscheinlichkeit: 0.15 Ausmaß: mittel Indikator: Mitarbeiter arbeiten das gleiche aus Priorität: 2 Risiko-Minderung: genaues Festhalten der Aufgaben im Projektplan Alarmplan: Missverständnis durch Projektleiter sofort klarstellen Tab. 4.8: Risikoelement Aufgabenverteilung Ein weiterer Risikofaktor kann eine unklare Aufgabendefinition mit sich bringen. Werden am Anfang die Requirements nicht klar definiert, kann sich dies durch das ganze SW-Projekt ziehen. Als Hilfe dienen Protokolle bei jedem Meeting. Risiko: unklare Aufgabendefinition Wahrscheinlichkeit: 0.7 Ausmaß: mittel Indikator: Missverständnisse zw. Projektleiter und Team Priorität: 2 Risiko-Minderung: Protokolle bei Meetings Alarmplan: klare Verhältnisse schaffen Tab. 4.9: Risikoelement Aufgabendefinition Neben personellen Risiken können auch technologie-spezifische Probleme auftreten. Da bei unserem Softwarepraktikum einige Technologien nicht bekannt sind, bestehen hier bei der Umsetzung noch erhöhte Risiken.

82 72 Kap. 4: Projektplanung Risiko: USB-Treiber Wahrscheinlichkeit: 0.4 Ausmaß: schwerwiegend Indikator: Treiber lässt sich nicht unter Linux installieren Priorität: 2 Risiko-Minderung: andere USB-Kamera Alarmplan: keine USB-Kamera Tab. 4.10: Risikoelement USB-Treiber Die Datenrate über den USB-Bus kann auch ein Risiko darstellen. Reicht die Datenrate nicht aus, muss über eine Änderung der Anzahl der Kameras nachgedacht werden. Risiko: Datenrate USB-Bus reicht nicht aus Wahrscheinlichkeit: 0.3 Ausmaß: mittel Indikator: Die Datenrate der 4 Kameras ist zu langsam Priorität: 2 Risiko-Minderung: Reduzieren der Kameras auf 3 Alarmplan: Auflösung zurücksetzen und 3 Kameras verwenden Tab. 4.11: Risikoelement Datenrate USB-Bus Ein weiteres Risiko bringt die Ansteuerung des Roboters mit sich. Kann eine sichere Kommunikationsschnittstelle geschaffen werden? Der Roboter muss in ständiger Verbindung mit der RCU stehen und sendet Lebenssignale in kurzen Zeitabständen. Risiko: Kommunikation zum Roboter Wahrscheinlichkeit: 0.5 Ausmaß: schwerwiegend Indikator: DAO-Roboter kann nicht gesteuert werden Priorität: 2 Risiko-Minderung: Kommunikation überprüfen Alarmplan: ständiges senden von Lebenssignale Tab. 4.12: Risikoelement Robotersteuerung

83 4.7 Ticketsystem Ticketsystem Während der gesamten Projektdauer wurde mit Hilfe eines SVN Repository gearbeitet. Ein zusätzliches Feature war das Ticketsystem. Jedes Projektmitglied verfügt über einen eigenen Account und hat somit Zugriff auf alle verfügbaren Daten. Dieses System war notwendig, um ein schnelles sowie sicheres Arbeiten zu gewähren. Jedes Teammitglied hat durch dieses System einen aktuellen Einblick über sämtliche Source-Files. Wie aber das Ticketssystem aufgebaut ist, veranschaulicht die Abbildung Der Projektleiter kann den einzelnen Projektmitgliedern Aufgaben bzw. Tickets erteilen. Wird ein Ticket akzeptiert, muss diese Aufgabe von dem Teammitglied erledigt werden. Durch dieses Ticketsystem wird eine klare Aufgabenverteilung gewährleistet und jedes Teammtiglied hat einen Überblick über die Aufgaben im Softwareprojekt. Abb. 4.13: Beispiel Ticketsystem Weiters ist es auch möglich, sämtliche Commit-Ereignisse durch ein Kommentar zu versehen. So erhalten die Teammitglieder einen Überblick, was gemacht wurde. Welches Teammitglied was und zu welcher Zeit und genau entwickelt hat, ist unter dem Stream-Register genau nachvollziehbar.

84 74 Kap. 4: Projektplanung Abb. 4.14: Beispiel SVN-Commit Events

85 5 Implementierung In diesem Kapitel gehen wir auf die wichtigsten Implementierungsdetails beim Client und beim Server ein. Weiters wird der Aufbau, die Struktur und das Layout der jeweiligen Applikation beschrieben. 5.1 Client Am Client werden alle vier Streams von den Kameras angezeigt. Weiters wird das eigene Bild angezeigt und zum Roboter übertragen. Man kann den Robotor entweder mit der Maus, der Tastatur oder dem Lenkrad steuern. Die Oberfläche besteht aus einem JFrame, worin dann zwölf JInternalFrames eingebettet werden. Bei den textitjinternalframes wird der Rahmen entfernt und deren Beweglichkeit innerhalb des JFrames blockiert. In jedes einzelne JInternalFrame wird dann, je nach Bedarf, ein Videoplayer, eine Statusanzeige oder ein Steuerelement eingefügt Client Layout Das Layout des Client sieht folgendermaßen aus: Die Oberfläche wurde in eine drei mal vier Matrix aufgeteilt. In jedes Feld dieser Matrix wird dann eine Komponente eingebettet. Es gibt JVLC Komponenten, welche die Videos darstellen können. Weiters gibt es eine Steurungskomponente, mit deren Hilfe man entweder über die Maus, oder über die Tastatur den Roboter steuern kann. Dann gibt es noch Komponenten, die das Hauptvideo steuern und letztendlich gibt es noch eine Komponente, die als Statusanzeige dient. Sie zeigt an, ob die Verbindung zum Server noch besteht oder nicht. Über das Menü kann man einen Konfigurationsdialog aufrufen, oder die Verbindung zum Server erstellen oder beenden. Weiters kann man die Applikation noch beenden, oder den About Dialog aufrufen. In dem Klassendigramm

86 76 Kap. 5: Implementierung Abb. 5.1: Klassendiagramm der Oberfläche aus Abbildung 5.1 sind nur die wichtigsten Klassen angeführt. Es wurden alle Listener und Parameter entfernt. Die Hauptklasse befindet sich in der Mitte, es ist der Workingframe. In dieser Klasse ist das ganze Layout festgelegt und alle anderen Komponenten sind in sie eingebettet. Das JVLCPanel ist die wichtigste Klasse und wird in einem extra Unterkapitel behandelt. Es beinhaltet den VLC Player und die Steuerung dafür. Der ParamHandler ist für das Auslesen der Parameter aus dem XML File zuständig, sowie für das Speichern jener Parameter, falls diese über den Konfigurationsdialog geändert werden. Die Klasse Status ist nur für die Anzeige zuständig, ob eine Verbindung mit dem Roboter besteht, oder auch nicht. Die Klasse Control ist für die Steuerung des Roboters mittels Maus oder Tastatur zuständig. Die Klassen ClientHandle und RobotClient sind für die Kommunikation zwischen Client und Server verantwortlich, wobei die eine Klasse das Lebenszeichen zur Verfügung stellt und die andere für den Verbindungsaufbau und den Verbindungsabbau dient und außerdem die Auswahl der Ströme ermöglicht (man kann bei jedem gewählten Videostrom die Auflösung des Videos mit angeben). In Abbildung 5.3a kann man sehen, dass man entweder lokal abgespeicherte Videos abspielen kann, oder den Videostrom via UDP öffnen kann. Für jeden Videostrom hat man die Möglichkeit die Quelle extra anzugeben.

87 5.1 Client 77 Abb. 5.2: Screenshot des Client mit Videos Wie in Abbildung 5.3b zu sehen ist, kann man hier die IP Adresse und die Port Adresse vom Server einstellen. In der letzten Abbildung 5.3c kann man den Pfad zum VLC Verzeichnis und den Pfad zum Plugin Verzeichnis angeben. Momentan wird nur der Pfad zum Pluginverzeichnis benötigt, da man den Pfad zum VLC selber in den Umgebungsvariablen von Windows setzen muss Keyboard and Mouse Control Die Steuerung mit der Maus ist über Buttons und den dazugehörigen Actionlistener realisiert. Dieser Listener ist bei der Control Komponente angehängt. Die Tastatursteuerung ist über einen Keylistener realisiert, der bei dem Workingframe eingehängt ist. In diesem Listener wird der Keycode abgefragt und entspricht dieser den Steuerungstasten, so wird dieser Event dem Server weitergeleitet. In folgendem Codefragment kann man sehen, wie auf den richtigen Keycode abgefragt wird. i f ( e. getkeycode ( ) == 38) { try { this. wf. g e t S e r v e r H a n d l e r ( ). i n c r e a s e S p e e d ( ) ; } catch ( RemoteException r e ) { r e. p r i n t S t a c k T r a c e ( ) ; } }

88 78 Kap. 5: Implementierung (a) Konfiguration der Videoquellen (b) Server Einstellungen (c) Gemeinsame Konfiguration Abb. 5.3: Konfigurationsdialog

89 5.1 Client JVLC Panel In diesem Unterkapitel wird das Herzstück der Clientapplikation genauer betrachtet. In dieser Klasse wird der VLC Player in eine Java Komponente eingebettet. Durch die Vorgabe der JVLC Programmierung, muss der Videooutput vom VLC Player in ein Java Canvas eingebettet werden. Dieses Canvas wird dann wiederum in ein JPanel eingebettet. Die JVLCPanel Klasse kann über zwei Konstruktoren aufgerufen werden. Der erste Konstruktor ermöglicht lediglich die Angabe der Quelle, die abgespielt oder gestreamt werden soll. Der zweite Konstruktor ermöglicht zusätzlich noch die Angabe von weiteren Argumenten in String Repräsentation. Dies wird benötigt, um das Bild von der Clientcamera streamen und anzeigen zu können. Erst wenn der Player gestartet wird, wird der Videooutput gesetzt. Dies geschieht, da in den JVLC Sourcen abgefragt wird, ob die Komponente in welcher der Videooutput gesetzt wird auch displayable ist. Eine Komponente ist erst dann displayable wenn sie auf setvisible = true gesetzt wurde. Weiters gab es noch Probleme beim Verändern der Größe. Wie zu sehen ist, mussten wir bei den setsize Methoden den Wert verringern, da sich ohne diese Maßnahme das Video innerhalb der Java Komponente immer weiter vergrößerte, bis nichts mehr zu sehen war. package at. u n i k l u. u n i k l u n i. c l i e n t. gui ; import java. awt. Dimension ; import javax. swing. JPanel ; import org. v i d e o l a n. j v l c. Audio ; import org. v i d e o l a n. j v l c. JVLC ; import org. v i d e o l a n. j v l c. MediaDescriptor ; import org. v i d e o l a n. j v l c. MediaPlayer ; import at. u n i k l u. u n i k l u n i. c l i e n t. l i s t e n e r. C l i e n t M e d i a P l a y e r L i s t e n e r ; import at. u n i k l u. u n i k l u n i. c l i e n t. l i s t e n e r. JVLCPanelComponentAdapter ; import at. u n i k l u. u n i k l u n i. param. c l i e n t. ParamHandler ; public class JVLCPanel extends JPanel { private s t a t i c f i n a l long s e r i a l V e r s i o n U I D = L ; private Audio audio ; private MediaDescriptor mediadescriptor ; private MediaPlayer p l a y e r ; private JVLC j v l c ; private ParamHandler pm; private JVLCCanvas j v c c = null ; / Constructor.

90 80 Kap. 5: source ( e. g. : C:/11 eclipseworkspace / t e s t v i d e o s / t en. mpg number / public JVLCPanel ( ParamHandler pm, S t r i n g s o u r c e ) { super ( ) ; this.pm = pm; this. j v c c = new JVLCCanvas ( this.pm. getvlcarg ( ) ) ; this. add ( j v c c ) ; j v l c = j v c c. getjvlc ( ) ; mediadescriptor = new MediaDescriptor ( j v l c, s o u r c e ) ; p l a y e r = mediadescriptor. getmediaplayer ( ) ; p l a y e r. a d d L i s t e n e r (new C l i e n t M e d i a P l a y e r L i s t e n e r ( ) ) ; audio = new Audio ( j v l c ) ; } addcomponentlistener (new JVLCPanelComponentAdapter ( ) ) ; public JVLCPanel ( ParamHandler pm, S t r i n g source, S t r i n g o ption ) { super ( ) ; this.pm = pm; this. j v c c = new JVLCCanvas ( this.pm. getvlcarg ( ) ) ; this. add ( j v c c ) ; j v l c = j v c c. getjvlc ( ) ; mediadescriptor = new MediaDescriptor ( j v l c, s o u r c e ) ; mediadescriptor. addoption ( option ) ; p l a y e r = mediadescriptor. getmediaplayer ( ) ; p l a y e r. a d d L i s t e n e r (new C l i e n t M e d i a P l a y e r L i s t e n e r ( ) ) ; audio = new Audio ( j v l c ) ; } addcomponentlistener (new JVLCPanelComponentAdapter ( ) ) ; public MediaPlayer getmediaplayer ( ) { return p l a y e r ; } / Set new source to p l a source / public void s e t S o u r c e ( S t r i n g s o u r c e ) { mediadescriptor = new MediaDescriptor ( j v l c, s o u r c e ) ; stop ( ) ; p l a y e r = null ; p l a y e r = mediadescriptor. getmediaplayer ( ) ; } / S t a r t p l a y e r. / public void play ( ) { j v l c. setvideooutput ( j v c c ) ; p l a y e r. play ( ) ; } /

91 5.1 Client 81 Stop p l a y e r. / public void stop ( ) { p l a y e r. stop ( ) ; } / Set mute / public void setmute ( boolean mute ) { audio. setmute ( mute ) ; } / Set volume / public void setvolume ( int volume ) { audio. setvolume ( volume ) ; } / Return / public JVLC getjvlcobject ( ) { return j v l c ; } / Set window s i z e. / public void s e t S i z e ( int width, int h e i g h t ) { this. j v c c. s e t S i z e ( width 10, h e i g h t 10) ; } } / Set window s i z e. / public void s e t S i z e ( Dimension dim ) { this. j v c c. s e t S i z e ( dim. width 10, dim. h e i g h t 10) ; } Streaming Das Streaming wird voll und ganz vom VLC Player übernommen. Man muss lediglich mittels Argumenten das Ziel angeben wohin man streamen will ( IP Adresse und Port Adresse werden benötigt). Beim Empfangen der Videodaten benötigt man nur die Port Adresse External Player Der externe Videoplayer wurde am Anfang der Entwicklungsphase ausgewählt, da wir Probleme hatten, ein Video zu streamen und gleichzeitig am Monitor

92 82 Kap. 5: Implementierung Abb. 5.4: External Player darzustellen. Mittlerweile haben wir dieses Video (von der Clientkamera) in die Applikation einbetten können. Somit ist der externe Videoplayer, dessen Klassenbeschreibung in Abbildung 5.4 zu sehen ist, hinfällig geworden. 5.2 Server Der Server befindet sich am Roboter. Die Software bildet einen Knotenpunkt zwischen der Hardware des Roboters und dem Clienten. Die Verbindung zum Clienten wird über Wireless-LAN realisiert, während mit dem Roboter über die serielle Schnittstelle des Rechners kommunziert wird. Für die Konfiguration und Steuerung des Servers steht eine umfassende grafische Oberfläche zur Verfügung. Nach dem alle notwendigen Konfigurationen eingestellt wurden, kann der Server gestartet werden. Der weitere Ablauf erfolgt automatisch. Das Programm wartet auf eine Verbindungsanforderung über WLAN. Nach einer erfolgreichen Verbindung werden Steuerungsbefehle direkt an den Roboter weitergegeben. Sofern vom Clienten ein Video-Signal übertragen wird, wird dieses am Bildschirm angezeigt. Zusätzlich werden Informationen über den aktuellen Netzwerkstatus zum Clienten und die Verbindung zum Roboter angezeigt. Der Server kann jeder Zeit wieder gestoppt werden. Dabei wird die Verbindung zum Clienten unterbrochen und der Roboter zum Stillstand gebracht.

93 6 Installationsanleitung und Verwendung Im Folgenden wird die Installation und Anwendung des abgeschlossenen Projekts erläutert. Es werden zwei Softwarekomponenten verwendet (Client und Server), die getrennt voneinander installiert und eingerichtet werden müssen. Die Serversoftware muss am Rechner des Roboters installiert und ausgeführt werden, während die Clientsoftware auf einen beliebigen Rechner verwendet werden kann. Zu Beginn wird auf die jeweiligen Systemanforderungen eingegangen. Anschließend werden die Installation, sowie die Anwendung beider Komponenten näher beschrieben. 6.1 Anforderung Plattformunabhängigkeit galt für dieses Projekt als eines der großen Ziele, dennoch mussten wir einige Kompromisse eingehen. Ursprünglich geplant war es, dass zumindest die drei Betriebssysteme Linux, Mac OS X und Windows unterstützt werden. Wie weit uns dies geglückt ist, soll im darauf folgenden Unterkapitel erläutert werden. Bei der Installation und Einrichtung der vier Kameras am Roboter sind einige unerwartete Probleme entstanden. In Kapitel wird daher gezeigt, wie die Kameras korrekt installiert und konfiguriert werden. Als Streamingserver wurde der als Open-Source geführte VLC Media Player (VLC) verwendet. In Kapitel wird beschrieben, was bei der Installation des VLC Media Player zu beachten ist und wie die Funktionsweise der Kameras getestet werden kann.

94 84 Kap. 6: Installationsanleitung und Verwendung Betriebssysteme Prinzipiell wurde darauf geachtet, dass die Software plattformunabhängig ist. Durch die Verwendung diverser externer Bibliotheken ist dennoch eine Einschränkung vorhanden. Client Software Der Client muss die vier Videostreams vom Roboter empfangen und darstellen. Im Normalfall befindet sich am Client ebenfalls eine Kamera, welche es anzuzeigen gilt. Die Daten müssen kodiert und als Stream dem Roboter übergeben werden. Um dies alles bewältigen zu können, setzt der Client auf den VLC Media Player (VLC) auf. Um VLC in einer Java-Umgebung verwenden zu können, ist das Paket JVLC notwendig. Damit ist es auf recht einfache Weise möglich, sämtliche Funktion des VLC Media Players zu verwenden. Der VLC Media Player ist prinzipiell für alle wichtigen Betriebssysteme verfügbar. Allerdings konnten wir JVLC nur unter Windows und Linux erfolgreich und vollständig zum Laufen bringen. Während das Versenden von Videostreams keine Probleme bereitete, war das Einbinden eines Videofensters in Java-Swing Komponenten unter Mac OS X nicht möglich. Server Software Prinzipiell ist auch die Serversoftware den gleichen Einschränkungen wie der Client ausgeliefert. Mac OS X scheidet somit auch hier als Betriebssystem aus. Um mit der Hardware des Roboters eine Kommunikation eingehen zu können, wurde uns eine eigene Bibliothek in Form einer DLL bereit gestellt. Diese ist leider nur unter Windows lauffähig. Somit ist der Server auch an dieses Beriebssystem gebunden Java Auf dem Betriebssystem muss mindestens die Java Plattform Standard Edition Version 6 (Java SE 6) installiert sein Kameras Dem Roboter stehen 4 USB-Kameras zur Verfügung. Bei der Installation und Verwendung dieser Kameras ist es zu einigen unerwartenden Problemen gekommen. In diesem Kapitel soll nun beschrieben werden, welche Lösungen und eventuelle Verbesserungsvorschläge wir diesbezüglich gefunden haben.

95 6.1 Anforderung 85 Zuweisung einedeutiger IDs bei baugleichen Kameras Die Kameras werden mittels einer ID angesprochen. Die Vergabe dieser ID wird von der Treibersoftware erledigt und kann während der Installation nicht vom Benutzer verändert werden. Leider ist die ID nicht eindeutig, sondern wird wie in unseren Fall, mit der Produktbezeichnung der Kamera gleich gesetzt. Selbst mit der mitgelieferten zusätzlichen Software der Firma Logitech R, gab es keine Möglichkeit die ID nach der Installation zu ändern. Die von uns entwickelte Serversoftware ist nur unter Windows lauffähig, deshalb werden die für die Einrichtung der Kamera-IDs notwendigen Schritte auch nur für dieses Betriebssystem beschrieben: Die Treibersoftware der Firma Logitech R richtet einige Konfigurationsdaten in der Registry ein. Darin enthalten ist auch die ID der jeweiligen Kamera. Achtung: Änderungen in der Registry können das Betriebssystem unter Umständen beschädigen. Änderungen sollten nur mit größter Sorgfalt erledigt werden! Damit der Inhalt der Registry geändert werden kann, muss mit Hilfe eines Command-Fensters der Befehl regedit eingegeben werden. Darauf hin öffnet sich der Regestry Editor. Die Einstellungen der vier Kameras sind in folgenden Verzeichnis hinterlegt: HKEY LOCAL MACHINE/SYSTEM/ControlSet001/Control/DeviceClasses In diesem Unterordner befinden sich normalerweise noch eine ganze Reihe weiterer Ordner, deren Name leider nicht auf den Inhalt zurückschließen lässt. Am einfachsten ist es, wenn man mit Hilfe des Registry Editors nach der ID der Kamera sucht. Das Problem ist aber, dass man diese wissen muss. Aufschluss darüber kann entweder die zu der Kamera gehörige Software geben, oder man kann mit Hilfe des VLC Media Players die mögliche ID erfassen. Das Testen der Kameras mit Hilfe des VLCs ist im Kapitel verfasst. In unserem Fall sind dabei vier Kameras mit der Kennung QuickCam for Notebooks Pro aufgelistet gewesen. Die Suche nach diesem Eintrag war schließlich auch im Registry Editor erfolgreich. Das Ergebnis ist in Abbild 6.1 sichtbar. Insgesamt wurde der Eintrag vier mal gefunden. Die vier Einträge wurden mit den Werten cam1, cam2, cam3 und cam4 ersetzt. Nach dem die Einträge in der Registry geändert und gespeichert wurden, kann das Ergebnis wieder mit VLC überprüft werden. Näheres dazu ist wieder im Kapitel festgehalten.

96 86 Kap. 6: Installationsanleitung und Verwendung Abb. 6.1: Ausschnitt des Registry Editors Obwohl eine Kamera angeschlossen ist, wird kein Bild übertragen Wenn alle vier Kameras gemeinsam über eine Hub auf nur einen USB- Anschluss am Rechner angeschlossen sind, kann es vorkommen, dass der USB-Bus überlastet ist. Die Folge ist, dass eine oder mehrere Kameras ausfallen. Deswegen ist es von vorne herein besser, die Kameras auf alle am Rechner befindlichen USB-Anschlüsse auf zu teilen. Ob alle Kameras verfügbar sind, kann entweder mit der mitgelieferten Treibersoftware, oder so wie in Kapitel beschrieben, mit dem VLC überprüft werden VLC Media Player Für die Übertragung der Videostreams wird der frei erhältliche VLC Media Player verwendet. Dieser muss lokal auf beiden Rechnern (Client und Server) installiert sein. Funktion der Kameras überprüfen Mit Hilfe des VLCs können die Verfügbarkeit und die Funktion der am Rechner angeschlossenen Kameras relativ leicht überprüft werden. Dazu muss der VLC gestartet werden. Der hier gezeigte Ablauf gilt für die Version (zu sehen in Abbild 6.2): Mit dem VLC ist es mit wenigen Abb. 6.2: VLC Media Player Maus-Klicks möglich, eine am System angeschlossene Kamera anzusprechen und das entsprechende Vidosignal darzustellen. Dazu muss im Menü der Punkt Medien gefolgt von Aufnahmegerät öffnen... ausgewählt werden.

97 6.2 Server 87 Das darauf erscheinende Dialogfenster (dargestellt in Abbild 6.3) kann alternativ auch mit der Tastenkombination CTR+C geöffnet werden. Im Bereich Abb. 6.3: VLC - Dialogfenster für Geräteauswahl Kartenauswahl - Video-Gerätename sollten in der Dropdown-Box alle am System angeschlossenen Kameras sichtbar sein. Ist dies nicht der Fall, kann durch die Schaltfläche Liste aktualisieren eine neue Initialisierung der Kameras gestartet werden. Wenn in der Dropdown-Box auch nach dieser Initialsierung nicht alle Kameras aufgelistet sind, liegt höchstwahrscheinlich ein Fehler bei der Installation oder Konfiguration der Kameras vor. Einige Ansätze zur Problemlösung sind im Kapitel vorhanden. Durch die Auswahl eines Gerätes aus der Dropdown-Box und der anschließenden Bestätigung der Schaltfläche Wiedergabe sollte sich am Desktop ein Videofenster öffnen, welches das Videosignal der entsprechenden Kamera darstellt DAO-Communications Library Für die Kommunikation mit der Hardware des Roboters ist die eigens entwickelte DLL DaoCommNative.dll notwendig. Im Konfigurationsmenü der Robotersoftware muss lediglich der Pfad angegeben werden, in dem diese Datei liegt. 6.2 Server Die Serversoftware ist für den Hauptrechner, welcher am Roboter montiert ist, entwickelt worden und muss auch auf diesem installiert werden. Im Folgenden wird die Installation, Konfiguration und Anwendung dieser Softwarekomponente beschrieben.

98 88 Kap. 6: Installationsanleitung und Verwendung Installation Die abgeschlossene Version der Serversoftware besteht aus einer Batch-Datei und einem Library Verzeichnis. Abb. 6.4: Inhaltsverzeichnis der Serversoftware In dem Library-Verzeichnis, wie es in Abbild 6.4 zu sehen ist, befinden sich drei Bibliotheken: daorobot.jar daonetwork.jar jvlc-core.jar Bei daorobot.jar handelt es sich um die Hauptbibliothek, welche die von uns entwickelte Serversoftware beinhaltet. daonetwork.jar beinhaltet einige Interfaces, welche für die Kommunikation über RMI benötigt werden. Damit die Serversoftware den VLC Media Player ansprechen kann, benötigt sie die JVLC-API, welche in jvlc-core.jar enthalten ist. Die Batchdatei startrobot.bat besteht lediglich aus zwei Zeilen und muss eventuell noch angepasst werden. s e t PATH=%PATH%;C: \ Programme\VideoLAN\VLC java j a r Djna. l i b r a r y. path=c: \ Programme\VideoLAN\VLC\ p l u g i n s. / l i b / daorobot. j a r In der ersten Zeile wird die PATH-Variable auf den Standort von VLC erweitert. Sollte sich VLC in einem anderen Verzeichnis befinden, so muss dies angepasst werden. In der zweiten Zeile wird der Plugin-Ordner von VLC angegegeben. Dieser muss gegebenenfalls auch angepasst werden Aufbau Beim grafischen Design der Serversoftware wurde darauf geachtet, möglichst große Symbole zu verwenden. Damit kann der Roboter während des Betriebes

99 6.2 Server 89 Abb. 6.5: Oberfläche der Serversoftware leichter überwacht und kontrolliert werden. Die gesammte Oberfläche wird in Abbild 6.5 dargestellt. Um unerwartete Fehler oder ein Fehlverhalten besser nachvollziehen zu können, wurde ein umfangreiches Logging eingebaut, welches sämtliche Aktionen protokolliert. Um den aktuellen Status der einzelnen Komponenten schnell erfassen zu können, gibt es im unteren Bereich eigene Symbole mit den jeweiligen Signalfarben. Prinzipiell kann die Oberfläche in vier verschiedene Bereiche eingeteilt werden: Das Menü Im Menü sind alle wichtigen Punkte für die Steuerung und Konfiguration der Software untergebracht. Dabei gibt es prinzipiell drei Hauptbereiche (Abbild 6.6): File Server Robot Abb. 6.6: Übersicht der einzelnen Menüpunkte

100 90 Kap. 6: Installationsanleitung und Verwendung Das File-Menü spiegelt den Kernbereich wieder. Hier kann über den Punkt Configuration der Konfigurationsdialog erreicht werden, welcher sämtliche Programmeinstellungen beinhaltet. Zusätzlich kann durch die Auswahl von Exit das Programm beendet werden. Im Menüpunkt Server sind zwei Einträge untergebracht, welche das Starten und Stoppen des Netzwerkservers erlauben. Nur wenn der Netzwerkserver gestartet ist, ist es einem Client von außen möglich, den Roboter zu steuern. Im Robot-Menü wird die serielle Kommunikation mit dem Roboter verwaltet. Durch Connect, wird versucht eine Verbindung mit der Steuerungselektronik des Roboters aufzubauen. Erst nach einer erfolgreichen Verbindung können Steuerungssignale zum Roboter weitergeleitet werden. Test bringt ein Dialog-Fenster zum Vorschein, mit Hilfe dessen die Funktionsweise des Roboters getestet werden kann. Disconnect trennt die Verbindung zum Roboter, danach ist es nicht mehr möglich den Roboter zu steuern. 6.3 Client Für die Installation der Client Applikation ist folgendes zu tun. Zu Beginn muss der frei erhältliche VLC Player in der Version 0.9.* installiert werden. Weiters muss der Pfad zu den Binaries des VLC Players in der PATH Variable der Windowsumgebungsvariable eingetragen werden. Dann benötigt man mindestens eine Java 1.6 Runtime Installation. Die Applikation selbst besteht aus einem ausführbaren Jar File und einer XML Datei, welche die Einstellungen der Applikation abgespeichert hat. Beide Dateien müssen in dem selben Verzeichnis vorhanden sein, damit man das Jar File ausführen kann. Somit wäre die Installation abgeschlossen. In den nächsten zwei Kapiteln möchten wir noch zwei Tools vorstellen. Mit dem einen kann man einen Windowsinstaller erstellen, und mit dem anderen ist es möglich, das Jar File in ein Windows executable File einzubetten JSmooth JSmoot generiert eine ausführbare Windows Datei (exe File) die alle nötigen Informationen enthält, um die Java Applikation zu starten (zum Beispiel: der Classpath, JVM Version, Java Properties und vieles mehr). JSmooth (Abbildung 6.7) kann die installierte Java Version überprüfen und bei Bedarf ist es möglich, entweder dem Benutzer eine Nachricht anzuzeigen, oder automatisch die JRE runterzuladen und zu installieren. Für unsere ausführbare Datei haben wir folgende Einstellungen in JSmooth vorgenommen: Beim Skeleton haben wir den Windowed Wrapper gewählt.

101 6.3 Client 91 Abb. 6.7: JSmooth Anwendung Im Application Bereich haben wir das Jar File und die Mainklasse ausgewählt. In der Executable Sektion gibt man den Namen an, die die ausführbare Datei haben soll (mit der Endung.exe!). Abschließend noch das Häkchen neben dem Satz Set the executbale folder as current directory of the application NSIS NSIS (Nullsoft Scriptable Install System) ist eine professionelle Open-Source Software um Windows Installer zu erzeugen. Damit jede Software auch benutzerfreundlich bleibt, muss nicht nur die Software selbst benutzerfreundlich sein, sondern der Installationsprozess muss ebenfalls schnell und unkompliziert von statten gehen. Mittels einer Scriptingsprache kann man die ganze Funktionalität, die der Installer haben muss, umsetzen. Man kann zum Beispiel Startmenüeinträge erstellen, Einträge in der Registry vornehmen, Umgebungsvariablen setzen und viele andere Einstellungen vornehmen, die notwendig sind, um den einwandfreien Start der Software zu gewähren. In dem folgendem Script, das für die Client Software erstellt wurde, zeigen wir einige Möglichkeiten, die durch den NSIS Installer Genertor geboten werden. Name " DAO Client Installer " o u t F i l e " daoclient - setup. exe " i n s t a l l D i r $PROGRAMFILES\ d a o C l i e n t # Zuerst Auswahl des I n s t a l l a t i o n s v e r z e i c h n i s s e s Page d i r e c t o r y Page i n s t f i l e s # Zuerst d i e B e s t a e t i g u n g ob man w i r k l i c h d e i n s t a l l i e r e n w i l l

Streaming Media - MPEG-4 mit Linux

Streaming Media - MPEG-4 mit Linux Streaming Media - MPEG-4 mit Linux Überblick Streaming Media Streaming Anbieter Benötigte Software Vorführung Videostreaming Streaming Was ist Streaming? Sender Daten Empfänger Kontinuierlicher Datenstrom

Mehr

Multimediatechnik / Video

Multimediatechnik / Video Multimediatechnik / Video Video-Streaming http://www.nanocosmos.de/lietz/mtv Streaming: Anwendungen TV und Internet IP-TV: Video on Demand, Live Streaming Zugesicherte Qualität (QoS, Quality of Service)

Mehr

Videostreaming. Josko Hrvatin DMT. Prof. Dr. Robert Strzebkowski. TFH-Berlin WS 05/06

Videostreaming. Josko Hrvatin DMT. Prof. Dr. Robert Strzebkowski. TFH-Berlin WS 05/06 Josko Hrvatin DMT Prof. Dr. Robert Strzebkowski TFH-Berlin WS 05/06 Streaming Media Streaming Media ist der Oberbegriff von Streaming Audio und Streaming Video und bezeichnet die aus einem Computernetzwerk

Mehr

Streaming Protokolle Jonas Hartmann

Streaming Protokolle Jonas Hartmann Streaming Protokolle Jonas Hartmann 1 Streaming Protokolle Inhaltsverzeichnis 1. Definition / Anwendungsfälle 2. Offizielle RFC Streaming Protokolle 3. Ein wichtiges proprietäres Protokoll 4. Konkreter

Mehr

... relevante Ports für Streaming bzw. Remote Control!

... relevante Ports für Streaming bzw. Remote Control! ... relevante Ports für Streaming bzw. Remote Control! Wenn Sie mit der Installation des IO [io] 8000 / 8001 beginnen, ist es am sinnvollsten mit einem minilan zu beginnen, da dies mögliche Fehlrequellen

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Video over IP / Videostreaming

Video over IP / Videostreaming Video over IP / Videostreaming - einige wenige Aspekte - Prof. Dr. Robert Strzebkowski Beuth Hochschule für Technik Berlin Unterscheidung: 'Echter Streaming' mit Streaming-Server HTTP-Download als 'Pseudostreaming'

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

R e m o t e A c c e s s. Cyrus Massoumi

R e m o t e A c c e s s. Cyrus Massoumi R e m o t e A c c e s s Präsentation im Seminar Internet-Technologie im Sommersemester 2008 von Cyrus Massoumi I n h a l t Was versteht man unter Remote Access Unsichere Remotezugriffe TELNET Remote Shell

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Proseminar Objektorientiertes Programmieren mit.net und C# Florian Schulz Institut für Informatik Software & Systems Engineering Einführung Was hat Cross-Plattform

Mehr

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung Fertigprodukte Bruno Blumenthal und Roger Meyer 18. Juli 2003 Zusammenfassung Dieses Dokument beschreibt die Fertigprodukte welche im Projekt NetWACS eingesetzt werden sollen. Es soll als Übersicht dienen

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1 Präsentation homevisu Familie Peter Beck Juni 2011 2011 p b e Peter Beck 1 Funktionensumfang Der Funktionsumfang das provisu Framework. Modular und durch Plug-In erweiterbar / anpassbar. Plug-In Schnittstelle

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

11.10.2010. Eine Einführung - FH Krefeld WS2010-11. NetBeans IDE

11.10.2010. Eine Einführung - FH Krefeld WS2010-11. NetBeans IDE NetBeans IDE 1 Entwicklungsumgebung: komplett in Java geschrieben läuft auf NetBeans Plattform wurde hauptsächlich für die Programmiersprache Java entwickelt unterstützt unter anderem C, C++ und dynamische

Mehr

Eclipse und Java Einheit 01: Einführung in Eclipse

Eclipse und Java Einheit 01: Einführung in Eclipse Eclipse und Java Einheit 01: Einführung in Eclipse Laith Raed Ludwig-Maximilians-Universität München Institut für Informatik: Programmierung und Softwaretechnik Prof.Wirsing Inhaltsverzeichnis 1 Hintergrundwissen

Mehr

JAVA. Ein kurzer Überblick. Thomas Karp

JAVA. Ein kurzer Überblick. Thomas Karp JAVA Ein kurzer Überblick Thomas Karp WAS IST JAVA? Java ist eine fast rein objektorientierte Sprache nicht JavaScript eine professionelle Sprache eine im Unterricht weit verbreitete Sprache für verschiedene

Mehr

Enigma2 Plugin Entwicklung mit Eclipse

Enigma2 Plugin Entwicklung mit Eclipse Enigma2 Plugin Entwicklung mit Eclipse Enigma2 Plugin Entwicklung mit Eclipse 1/15 Inhaltsverzeichnis 1 ÜBER... 3 2 INSTALLATION... 4 2.1 INSTALLATION VON ECLIPSE... 4 2.2 INSTALLATION VON PYDEV... 4 3

Mehr

Java-IDE-Vergleich Seite 1 / 5

Java-IDE-Vergleich Seite 1 / 5 Java-IDE-Vergleich Seite 1 / 5 Java-IDEs im Vergleich 1. Getestete IDEs: Borland JBuilder 3 Professional Edition IBM Visual Age 3 Entry Edition Sun Forte 1.01 Community Edition Microsoft Visual J++ 6.0

Mehr

Audiokommunikation im Computer. Andreas Jäger

Audiokommunikation im Computer. Andreas Jäger Audiokommunikation im Computer Wie kommunizieren die Teile einer DAW miteinander? Host Hardware Host Was gibt es in der Praxis zu beachten? Wo liegen Gefahren? Konkreter: Warum ist ASIO besser als MME?

Mehr

Software-Engineering 2. Software-Engineering 2. Entwicklungsumgebungen (IDE) IT works. Klaus Mairon www.mairon-online.de 22.03.

Software-Engineering 2. Software-Engineering 2. Entwicklungsumgebungen (IDE) IT works. Klaus Mairon www.mairon-online.de 22.03. Software-Engineering 2 Entwicklungsumgebungen (IDE) IT works. Klaus Mairon www.mairon-online.de 22.03.2009 1 Entwicklungsumgebungen, CASE-Tools, CASE-Werkzeuge unterstützen den Software-Entwicklungsprozess

Mehr

Netzwerk Technologien in LabVIEW

Netzwerk Technologien in LabVIEW Netzwerk Technologien in LabVIEW von Dirk Wieprecht NI Germany Hier sind wir: Agenda Agenda Bedeutung des Ethernet für die Messtechnik Ethernet-basierende Technologien in LabVIEW Low Level- TCP/IP Objekt

Mehr

1. Java Grundbegriffe

1. Java Grundbegriffe 1. Java Grundbegriffe Geschichte von Java Programmieren mit Java Interpretieren vs. Kompilieren Java Byte-Code Jave Virtual Machine Arbeitsmaterialien Allgemeine Informatik 2 SS09 Folie 1.1 Java, eine

Mehr

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2013 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

OpenLDAP, adieu? Ein LDAP Server in Java: ApacheDS Reality Check. Stefan Zörner

OpenLDAP, adieu? Ein LDAP Server in Java: ApacheDS Reality Check. Stefan Zörner OpenLDAP, adieu? Ein LDAP Server in Java: ApacheDS Reality Check Stefan Zörner Zusammenfassung. Short Talk: OpenLDAP, adieu? Ein LDAP Server in Java: ApacheDS Reality Check Das Apache Directory Projekt

Mehr

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel 2.6 Managed Code, Angepasste Java

Mehr

Sicherheit in Rich Internet Applications

Sicherheit in Rich Internet Applications Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Seite 2 Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Inhaltsverzeichnis Grundlagen Ajax und Mashups Adobe Flash-Player

Mehr

Verteilte Systeme - 1. Übung

Verteilte Systeme - 1. Übung Verteilte Systeme - 1. Übung Dr. Jens Brandt Sommersemester 2011 1. Rechnerverbünde Kommunikationsverbund: Beispiele: E-Mail (SMTP, POP/IMAP), Instant Messaging (XMPP, IRC, ICQ,...), Newsgroups (NNTP)

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

eclipse - Entwicklungsumgebung und mehr ETIS SS05

eclipse - Entwicklungsumgebung und mehr ETIS SS05 eclipse - Entwicklungsumgebung und mehr ETIS SS05 Gliederung Motivation Geschichte Architektur Platform Runtime Eclipse Platform Java Development Tools (JDE) Plugin Development Environment (PDE) Zusammenfassung

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

Subversion. Einstieg in die. Versionskontrolle

Subversion. Einstieg in die. Versionskontrolle Versionskontrolle mit Subversion Einstieg in die Versionskontrolle Dipl.Ing.(FH) K. H. Marbaise Agenda Wozu Versionskontrolle? Was leistet Versionskontrolle? Historie zu Subversion Projekt Handling Installation

Mehr

Apache HTTP-Server Teil 2

Apache HTTP-Server Teil 2 Apache HTTP-Server Teil 2 Zinching Dang 04. Juli 2014 1 Benutzer-Authentifizierung Benutzer-Authentifizierung ermöglicht es, den Zugriff auf die Webseite zu schützen Authentifizierung mit Benutzer und

Mehr

0. Einführung. C und C++ (CPP)

0. Einführung. C und C++ (CPP) C und C++ (CPP) 0. Einführung Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte Wissenschaften marc.rennhard@zhaw.ch Marc Rennhard, 05.01.2010,

Mehr

VRML Tools. Markus Czok, Carsten Rohde

VRML Tools. Markus Czok, Carsten Rohde VRML Tools Markus Czok, Carsten Rohde Viewer Viewer Def.: Englische Bezeichnung für (Datei-)Betrachter. Für die meisten im PC Bereich üblichen Datenformate gibt es derartige Viewer, die es erlauben den

Mehr

Open Source IDE - eclipse ETIS SS04

Open Source IDE - eclipse ETIS SS04 Open Source IDE - eclipse ETIS SS04 Gliederung Motivation Geschichte Architektur Platform Runtime Eclipse Platform Java Development Tools (JDE) Plugin Development Environment (PDE) Zusammenfassung 2 Motivation

Mehr

Remote Eclipse RCP Management

Remote Eclipse RCP Management Remote Eclipse RCP Management Diplomarbeit Durchgeführt in Zusammenarbeit mit Deutsches Elektronen-Synchrotron DESY 1. Betreuer: Prof. Dr. Züllighoven 2. Betreuer: Prof. Dr. Lamersdorf Eugen Reiswich 09.12.2008

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Java Micro Edition. Entwicklung mobiler JavaME-Anwendungen mit CLDC und MIDP. von Klaus D. Schmatz. 2., aktualis. u. erw. Aufl.

Java Micro Edition. Entwicklung mobiler JavaME-Anwendungen mit CLDC und MIDP. von Klaus D. Schmatz. 2., aktualis. u. erw. Aufl. Java Micro Edition Entwicklung mobiler JavaME-Anwendungen mit CLDC und MIDP von Klaus D. Schmatz 2., aktualis. u. erw. Aufl. Java Micro Edition Schmatz schnell und portofrei erhältlich bei beck-shop.de

Mehr

1. Interface. Wireshark (Ehtereal)

1. Interface. Wireshark (Ehtereal) Wireshark (Ehtereal) Das Programm Wireshark Network Protocol Analyzer dient dazu, wie der Name schon sagt, ersichtlich zu machen, welche Datenpakete die Netzwerkkarte empfängt bzw. sendet. In Form von

Mehr

Glossar. Launching auf.

Glossar. Launching auf. 243 Ad Hoc Distribution Die Ad Hoc Distribution ist eine Möglichkeit, um Ihre entwickelte Anwendung auf anderen Endgeräten zu verteilen. Diese Art der Verteilung erfolgt ohne den App Store. Die Anzahl

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

1 Installationen. 1.1 Installationen unter Windows

1 Installationen. 1.1 Installationen unter Windows 1 Installationen Dieses Kapitel beschreibt die Installationen, die für die Nutzung von PHP und MySQL unter Windows, unter Ubuntu Linux und auf einem Mac mit OS X notwendig sind. 1.1 Installationen unter

Mehr

Subversion. von Stefan Arndt, Christian Autermann und Dustin Demuth. 5. November 2009

Subversion. von Stefan Arndt, Christian Autermann und Dustin Demuth. 5. November 2009 Subversion von Stefan Arndt, Christian Autermann und Dustin Demuth 5. November 2009 Inhaltsverzeichnis 1 Versionierung 1 1.1 Zweck von Versionierung................................. 1 1.2 Geschichtliches......................................

Mehr

1. Software-Plattform Android Android. Was ist Android? Managed Code, Angepasste Java Virtual Machine

1. Software-Plattform Android Android. Was ist Android? Managed Code, Angepasste Java Virtual Machine 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel ab 2.6, aktuell 3.8 Managed Code,

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

Einführung zu den Übungen aus Softwareentwicklung 1

Einführung zu den Übungen aus Softwareentwicklung 1 Einführung zu den Übungen aus Softwareentwicklung 1 Dipl.-Ing. Andreas Riener Universität Linz, Institut für Pervasive Computing Altenberger Straße 69, A-4040 Linz riener@pervasive.jku.at SWE 1 // Organisatorisches

Mehr

Software-Engineering Grundlagen des Software-Engineering 7.3 Sourcecode-Verwaltung mit Versionsmanagement-Systemen Einführung in Subversion (SVN)

Software-Engineering Grundlagen des Software-Engineering 7.3 Sourcecode-Verwaltung mit Versionsmanagement-Systemen Einführung in Subversion (SVN) Software-Engineering Grundlagen des Software-Engineering 7.3 Sourcecode-Verwaltung mit Versionsmanagement-Systemen Einführung in Subversion (SVN) Prof. Dr. Rolf Dornberger Software-Engineering: 7.3 Versionsmanagement-Systeme

Mehr

POB-Technology Dokumentation. POB-Technology Produkte. Deutsche Übersetzung von roboter-teile.de Alle Rechte vorbehalten Seite 1 von 13

POB-Technology Dokumentation. POB-Technology Produkte. Deutsche Übersetzung von roboter-teile.de Alle Rechte vorbehalten Seite 1 von 13 POB-Technology Produkte Deutsche Übersetzung von roboter-teile.de Alle Rechte vorbehalten Seite 1 von 13 Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis... 2 Einführung...4 POB-EYE... 5 POB-LCD128...

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Rechnernetze Projekt SS 2015

Rechnernetze Projekt SS 2015 30/03/15 Seite 1 Aspektorientierte Programmierung logische Aspekte (Concerns) im Programm separieren Crosscutting Concerns (Ziel: generische Funktionalitäten über mehrere Klassen hinweg zu verwenden -

Mehr

Seminararbeit Ruby Uno Kartenspiel

Seminararbeit Ruby Uno Kartenspiel Seminararbeit Ruby Uno Kartenspiel Autor: Fabian Merki Fabian Merki 05.11.2006 1 von 10 Inhaltsverzeichnis Einleitung... 3 Die Idee... 4 Design und Implementierung in Ruby... 5 Testing... 7 Startbefehle...

Mehr

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation.

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. Inhalt 1 Übersicht 2 Anwendungsbeispiele 3 Einsatzgebiete 4 Systemanforderungen 5 Lizenzierung 6 Installation 7 Key Features 8 Funktionsübersicht (Auszug) Seite 2 von 14 1. Übersicht MIK.starlight bietet

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH

Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH von Dominick Baier (dbaier@ernw.de) und Jens Franke (jfranke@ernw.de) 1 Einleitung Dieses Dokument behandelt die flexible

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

E-Business Architekturen

E-Business Architekturen E-Business Architekturen Übung 3b Entwicklung eigener Service-Angebote 01.03.2015 Prof. Dr. Andreas Schmietendorf 1 Ziele der Übung Möglichkeiten zur Serviceimplementierung (ggf. auch Cloud) Umgang mit

Mehr

Web 2.0 Architekturen und Frameworks

Web 2.0 Architekturen und Frameworks Web 2.0 Architekturen und Frameworks codecentric GmbH Mirko Novakovic codecentric GmbH Quality Technische Qualitätssicherung in Software-Projekten mit Fokus auf Performance, Verfügbarkeit und Wartbarkeit

Mehr

Buzzword Bingo Game Documentation (Java based Game)

Buzzword Bingo Game Documentation (Java based Game) Buzzword Bingo Game Documentation (Java based Game) Meppe Patrick Djeufack Stella Beltran Daniel April 15, 2011 1 Inhaltsverzeichnis 1 Einleitung 3 2 Aufgabenstellung 3 3 Allgemeines zu Buzzword Bingo

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

How to: Unterstützung von Audio und Video

How to: Unterstützung von Audio und Video How to: Unterstützung von Audio und Video Dieses Dokument dient der Erläuterung von Optionen zur Unterstützung von Audio-und Videodateien in EXMARaLDA und gibt Empfehlungen für Medienformate. Inhalte A.

Mehr

Einführung... 1 Anwendungsszenarien multimedialer Client-Server Systeme... 1 Aufbau des Buches... 2 Die Entwicklung des multimedialen Internets...

Einführung... 1 Anwendungsszenarien multimedialer Client-Server Systeme... 1 Aufbau des Buches... 2 Die Entwicklung des multimedialen Internets... Inhaltsverzeichnis Einführung... 1 Anwendungsszenarien multimedialer Client-Server Systeme...... 1 Aufbau des Buches..... 2 Die Entwicklung des multimedialen Internets..... 4 1 Multimediale Client-Server-Systeme...

Mehr

Mobile Application Development

Mobile Application Development Mobile Application Development Android: Einführung Jürg Luthiger University of Applied Sciences Northwestern Switzerland Institute for Mobile and Distributed Systems Lernziele Der/die Kursbesucher/in kann

Mehr

Systemvoraussetzungen 14.0

Systemvoraussetzungen 14.0 Systemvoraussetzungen 14.0 CMIAXIOMA - CMISTAR 29. Oktober 2014 Systemvoraussetzungen 14.0 Seite 2 / 12 Inhaltsverzeichnis 1 Allgemeines... 3 1.1 Support Lifecycle Policy... 3 1.2 Test Policy... 3 1.3

Mehr

Internet-basierendes Autorensystem zur Erschließung historischen Kulturguts. Thorsten Ludewig. Juni 2004

Internet-basierendes Autorensystem zur Erschließung historischen Kulturguts. Thorsten Ludewig. Juni 2004 METEOR Internet-basierendes Autorensystem zur Erschließung historischen Kulturguts Thorsten Ludewig Juni 2004 1 Übersicht Was ist METEOR Architektur Technische Realisierung Zusammenfassung Zukünftige Entwicklungen

Mehr

Erfahrungen mit QuickTime Streaming. Bernhard Barz Uwe Pirr Humboldt-Universität zu Berlin Rechenzentrum

Erfahrungen mit QuickTime Streaming. Bernhard Barz Uwe Pirr Humboldt-Universität zu Berlin Rechenzentrum Erfahrungen mit QuickTime Streaming Bernhard Barz Uwe Pirr Humboldt-Universität zu Berlin Rechenzentrum Die großen Drei: Real Networks: RealAudio, RealVideo 12,1 % Apple Computer: QuickTime 7,4 % Microsoft:

Mehr

Installationsanleitung

Installationsanleitung Installationsanleitung Dieses Werk ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung der OutStart E-Learning GmbH unzulässig und

Mehr

Software Engineering I

Software Engineering I Software I Übungsblatt 1 + 2 Claas Pinkernell Technische Universität Braunschweig http://www.sse.cs.tu-bs.de/ Seite 2 Welche Werkzeuge? Programmiersprache Java Integrierte Entwicklungsumgebung Eclipse

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

4D Server v12 64-bit Version BETA VERSION

4D Server v12 64-bit Version BETA VERSION 4D Server v12 64-bit Version BETA VERSION 4D Server v12 unterstützt jetzt das Windows 64-bit Betriebssystem. Hauptvorteil der 64-bit Technologie ist die rundum verbesserte Performance der Anwendungen und

Mehr

31.01.2013. Vorlesung Programmieren. Versionskontrollsysteme. Ziele von VCS. Versionskontrolle

31.01.2013. Vorlesung Programmieren. Versionskontrollsysteme. Ziele von VCS. Versionskontrolle Vorlesung Programmieren Versionskontrolle Dr. Dennis Pfisterer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/pfisterer Versionskontrollsysteme Wie organisiert man die

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA Hauptseminar Management von Softwaresystemen Techniken der System-Integration EAI, Middleware, SOA, CORBA Betreuerin: Referent: Ulrike Hammerschall Alexey Krivoborodov Agenda Motivation Arten der Verteilung

Mehr

Erfahrungsbericht Live Streaming Peter Bagschik, VfL Oker (www.vfloker.de)

Erfahrungsbericht Live Streaming Peter Bagschik, VfL Oker (www.vfloker.de) Erfahrungsbericht Live Streaming Peter Bagschik, VfL Oker (www.vfloker.de) Für eine Sportveranstaltung im Kunstturnen sollte für interessierte Zuschauer ein Live Video im Internet übertragen werden. Da

Mehr

Webserver allgemein Voraussetzung für die Integration von Plone NginX Apache 2 Demonstration Zusammenfassung

Webserver allgemein Voraussetzung für die Integration von Plone NginX Apache 2 Demonstration Zusammenfassung Webserver allgemein Voraussetzung für die Integration von Plone NginX Apache 2 Demonstration Zusammenfassung Software zur Annahme und Verarbeitung von HTTP/HTTPs- Requests (Port 80/443) benutzerdefinierte

Mehr

Convision IP-Videoserver und die Sicherheitseinstellungen von Windows XP (SP2)

Convision IP-Videoserver und die Sicherheitseinstellungen von Windows XP (SP2) Inhalt Convision IP-Videoserver und die Sicherheitseinstellungen von Windows XP (SP2)... 1 1. Die integrierte Firewall von Windows XP... 2 2. Convision ActiveX und Internet Explorer 6... 3 3. Probleme

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

Deutschland 8,50 Österreich 9,80 Schweiz 16,80 sfr. www.dotnet-magazin.de 7.2011. Outlook-Kalender in WPF

Deutschland 8,50 Österreich 9,80 Schweiz 16,80 sfr. www.dotnet-magazin.de 7.2011. Outlook-Kalender in WPF z.net MAGAZIN dot Alle Beispiele und Quellcodes zu den Artikeln dieser Ausgabe Bonus-Video von der BASTA! Spring 2011 Architektur für die Cloud Testversionen TeamPulse Ranorex Automation Framework dotpeek

Mehr

Streaming Techniken zur Übertragung multimedialer Daten im Web Universität Paderborn

Streaming Techniken zur Übertragung multimedialer Daten im Web Universität Paderborn Streaming Techniken zur Übertragung multimedialer Daten im Web Universität Paderborn Vortrag im Seminar 3D-Grafik im Web Raphael Gräbener Übersicht Was ist Streaming Anwendungsbeispiele Broadcasting Audio-/

Mehr

Apache HTTP-Server Teil 1

Apache HTTP-Server Teil 1 Apache HTTP-Server Teil 1 Zinching Dang 24. November 2014 1 Apache HTTP-Server Apache HTTP-Server allgemein offizielle Namensherkunft: Apachen-Stamm in Nordamerika wurde 1994 auf Basis des NCSA HTTPd-Webservers

Mehr

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Konzept eines Datenbankprototypen 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Inhalt (1) Projektvorstellung & Projektzeitplan Softwarekomponenten Detailierte Beschreibung der System Bausteine

Mehr

BENS OS 2.x BENS OS 4.00

BENS OS 2.x BENS OS 4.00 Kurze Beschreibung von Änderungen und Neuerungen in BENS OS Vers. 4.00 BENS OS 2.x BENS OS 4.00 Sprache der Bedienoberfläche nur Englisch. HTML-Oberfläche. Unterstützte Druckprotokolle: LPR /IPP / Socket

Mehr

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS Piotr Kasprzak Agenda Laufzeitumgebung Java EE (J2EE) Motivation APIs / Technologien JBoss Entwicklungsumgebung Eclipse Ausblick Java EE -

Mehr

Der Raspberry Pi als Mediacenter

Der Raspberry Pi als Mediacenter Der Raspberry Pi als Mediacenter Autor: M. Völkl Städtische Berufsschule für Informationstechnik Der Raspberry Pi als Mediacenter Handlungssituation Sie sind Azubi der Firma SMART IT. Ihr Chef hat im Empfangsbereich

Mehr

Systemanforderungen Verlage & Akzidenzdruck

Systemanforderungen Verlage & Akzidenzdruck OneVision Software AG Inhalt Asura 9.5, Asura Pro 9.5, Garda 5.0...2 PlugBALANCEin 6.5, PlugCROPin 6.5, PlugFITin 6.5, PlugRECOMPOSEin 6.5, PlugSPOTin 6.5,...2 PlugTEXTin 6.5, PlugINKSAVEin 6.5, PlugWEBin

Mehr

PDF FormServer Quickstart

PDF FormServer Quickstart PDF FormServer Quickstart 1. Voraussetzungen Der PDF FormServer benötigt als Basis einen Computer mit den Betriebssystemen Windows 98SE, Windows NT, Windows 2000, Windows XP Pro, Windows 2000 Server oder

Mehr

ARTS Server 3.5. Produktbeschreibung. Uptime Services AG

ARTS Server 3.5. Produktbeschreibung. Uptime Services AG Uptime Services AG Brauerstrasse 4 CH-8004 Zürich Tel. +41 44 560 76 00 Fax +41 44 560 76 01 www.uptime.ch ARTS Server 3.5 Produktbeschreibung Uptime Services AG Inhaltsverzeichnis 1 Einleitung... 2 2

Mehr

eytron VMS Webanwendung Fehlersuche und -Behebung

eytron VMS Webanwendung Fehlersuche und -Behebung eytron VMS Webanwendung Fehlersuche und -Behebung 2009 ABUS Security-Center GmbH & Co. KG, Alle Rechte vorbehalten Diese Anleitung soll Ihnen Unterstützung für den Fall geben, dass die Webanwendung nach

Mehr