Filtern
Erscheinungsjahr
- 2008 (26) (entfernen)
Dokumenttyp
- Studienarbeit (26) (entfernen)
Schlagworte
- E-IMS (2)
- Programmierung (2)
- Robotik (2)
- VNUML (2)
- 3D-Modell (1)
- ATMega 16 (1)
- ATmega644 (1)
- ATtiny2313 (1)
- Abfragesprache (1)
- Anwendungssoftware (1)
- Bachelor (1)
- Bildverarbeitung (1)
- Blinder Fleck (1)
- Burg (1)
- ColorSym (1)
- Computergrafik (1)
- Computermodell (1)
- Computerspiel (1)
- Computertomografie (1)
- DHCPv6 (1)
- Diabetes (1)
- Diabetische Retinopathie (1)
- Digitale Steuerung (1)
- Dimensionality Reduction (1)
- Dimensionsreduzierung (1)
- EEPROM (1)
- EPROM (1)
- Electronic Government (1)
- Eye-Tracking (1)
- Farbkalibrierung (1)
- Farbsymmetrie (1)
- FastSLAM Algorithmus (1)
- Feature Extraction (1)
- GLSL (1)
- Gaze-Tracking (1)
- Generative Modellierung (1)
- Geometrie-Shader (1)
- Glaukom (1)
- Graph (1)
- Gupro (1)
- HNF-Algorithmus (1)
- Headerdaten Netzwerkpaket SOCK_RAW SOCK_PACKET (1)
- Heidelberg Retina Tomograph (1)
- Hermite-Normalform (1)
- ICP-Algorithmus (1)
- IPv6 (1)
- Informatik (1)
- Informationssystem (1)
- Internetzugang (1)
- Intranet-Zugang (1)
- Java (1)
- Java-Quelltext (1)
- Kantenverfolgung (1)
- Kondertal (1)
- Logging (1)
- Lokalisierung (1)
- Mail-Filter (1)
- Master (1)
- Medical Image Analysis (1)
- Medizinische Bildanalyse (1)
- Medizinische Bildverarbeitung (1)
- Merkmalsextrahierung (1)
- Mikrocontroller (1)
- Mikrocontroller AVR (1)
- Mobiles Multiplayerspiel (1)
- Modul (1)
- Modulhandbuch (1)
- Montageablauf (1)
- Morphologische Operatoren (1)
- Netzwerkschicht (1)
- Netzwerksimulation (1)
- Onlinespiele (1)
- OpenGL (1)
- Ornamentklassifikation (1)
- Packet Header SOCK_RAW SOCK_PACKET (1)
- Personentracking (1)
- Personenverfolgungssystem (1)
- Programmiergerät (1)
- Retina Befundbilder (1)
- Retina Fundus Bilder (1)
- Retina Fundus Images (1)
- SAC (1)
- Skriptsprache (1)
- Socket (1)
- Socket-Schnittstelle (1)
- Spam-Mail (1)
- Spieleentwicklung (1)
- SpoGA (1)
- SpoGa (1)
- TGraphen (1)
- Taktstraße (1)
- Transform Feedback (1)
- Transportschicht (1)
- UML (1)
- Universität Koblenz-Landau (1)
- Veranstaltung (1)
- Verbindungsschicht (1)
- Verwaltungsautomation (1)
- WLAN (1)
- Web Services (1)
- bachelor (1)
- colour calibration (1)
- computer science (1)
- diabetic retinopathy (1)
- dreidimensionale Computergraphik (1)
- eGroupware (1)
- edge linking (1)
- geometry shader (1)
- information system (1)
- master (1)
- medical image processing (1)
- module handbook (1)
- morphological operators (1)
- retina fundus images (1)
- transform feedback (1)
Für die Netzwerkprogrammierung hat sich auf breiter Front das Socket API nach Vorbild der Berkley Sockets durchgesetzt. Die "normalen" Sockets in Form von Stream- oder Datagram-Sockets erleichtern zwar die Programmierarbeit, verschleiern jedoch auch zahlreiche Details der Netzwerkkommunikation vor dem Programmierer. So ist man beispielsweise auf die Nutzung der Protokolle TCP oder UDP eingeschränkt und agiert zwangsläufig bereits auf dem Application-Layer des TCP/IP Referenzmodells. Für den Zugriff auf tiefer gelegene Netzwerkschichten, d.h. für den Zugriff auf die Headerdaten eines Netzwerkpaketes, hält das Socket API die sogenannten RAW Sockets bereit. Mit ihnen ist es möglich, alle IP Pakete inklusive Headerdaten zu lesen oder von Grund auf neu zu generieren. Hiermit ist es nun auch möglich, Protokolle zu verwenden, die dem Anwendungsprogrammierer bislang nicht zugänglich waren (z.B. ICMP oder OSPF) oder sogar eigene IP basierte Protokolle zu entwickeln. RAW Sockets stoßen an ihre Grenzen, wenn es darum geht auf den Data-Link-Layer der Netzwerkkommunikation zuzugreifen. Unter Linux gibt es hierfür einen weiteren Socket-Typ: Den PACKET Socket. Die Studienarbeit möchte einen Einstieg in die Programmierung mit den eher unbekannten RAW und PACKET Sockets schaffen. Dabei werden einige Beispielprogramme vorgestellt und mögliche Anwendungsgebiete aufgezeigt.
Ziel dieser Studienarbeit war es, Erfahrungen in der Grafik- und Spieleprogrammierung zu sammeln. Als Grundidee kam dabei die Erstellung eines 3-dimensionalen Terrains auf. Solche Terrains werden heutzutage nicht nur in der Spielebranche eingesetzt, wo sie in beinahe jedem Genre vertreten sind, sondern auch z.B. in der Geologie zur Erstellung von Simulationen von Plattentektonik. Die simple Erstellung eines 3-dimensionalen Terrains wäre für eine Studienarbeit jedoch zu trivial, daher sollte das Terrain spezielle Anforderungen erfüllen. Zum einen sollte das Terrain dynamisch erzeugt werden, d.h. der Benutzer des Programms hat Einfluss darauf, wie sich das Terrain entwickelt. Dies sollte vorzugsweise spielerisch eingebracht werden. Zum anderen sollte das Terrain zufällig generiert werden. Dies bedeutet, dass keine vormodellierte Landschaft genutzt, sondern jede Erhebung/- Vertiefung des Terrains mittels Zufallsfaktoren erzeugt werden sollte. Zusätzlich sollte das Terrain endlos erzeugt werden. Bei einer Bewegung über das Terrain sollte also niemals ein Ende erreicht werden. Also auch keine Kreistrecke, sondern ein wirklich endloses und stets anders aussehendes Terrain. Desweiteren sollte es dem Benutzer møglich sein, ein Fluggerät über das Terrain zu steuern. Dies gab dann auch die Chance, aus der oben genannten dynamischen Anforderung ein spielerisches Element zu machen, indem der Benutzer das Terrain durch Einsammeln von sogenannten TerraformItems beeinflussen kann. Die Steuerung eines Fluggerätes spielt auch für die geforderte Endlosigkeit des Terrains eine wichtige Rolle, da diese ohne eine Möglichkeit der Fortbewegung gar nicht nachprüfbar wäre. Das Problem mit der Endlosigkeit ist dabei, dass kein System endlosen Speicher zur Verfügung hat um das Terrain komplett zu speichern und dem Benutzer somit die Option zu bieten, die gleiche Strecke zurückzufliegen. Eine Lösung für diese Problematik wäre bei einer Kehrtwende das Terrain auch rückwärts wieder neu zu generieren. Der Einfachheit halber sollte stattdessen ein komplette Kehrtwende einfach nicht zugelassen werden. Eine Kollisionserkennung musste dann natürlich auch implementiert werden. Zum einen weil das Fluggerät ja nicht einfach wie ein Geist durch das Terrain hindurchgleiten sollte, zum anderen muss das Programm ja irgendwie das Einsammeln der oben angesprochenen TerraformItem-Objekte registrieren können. Weitere Objekte wie Bäume oder Felsen sollten das Terrain optisch aufwerten. Zu guter Letzt sollte noch eine simple Benutzeroberfläche erstellt werden, um dem Benutzer diverse Bedienelemente und Rückmeldungen zu bieten. Damit sollte es z.B. auch möglich sein dass Terrain direkt zu verändern.
In dieser Arbeit werden einige bekannte Spam Klassiffzierungsmethoden, welche für viele Anwendungen schon im Einsatz sind, kurz erläutert, um sie in einem neuen Szenario zu analysieren. In diesem Szenario wird nicht wie bei E-Mails üblich davon ausgegangen, dass die Nachrichten unbegrenzter Länge sein können, sondern dass es sich hierbei um Nachrichten begrenzter Länge handelt. Auch die Darstellungsform und der vermutliche Inhalt solcher Nachrichten werden aus einem speziellen Kontext heraus betrachtet. So wird davon ausgegangen, dass die Nachrichten auf einem Ticker eines Bildschirmes zu sehen sind, welcher in einer Universität angebracht ist. Somit werden die Nachrichteninhalte sich eher auf das universitäre Umfeld beziehen, wobei angenommen wird, dass die Nachrichteninhalte nur von einer abgeschlossenen Gruppe von Personen eingestellt werden. Nach der Erzeugung einiger Spam- und Hamnachrichten, die auf die Kriterien des Szenarios zutreσfn, werden Klassiffzierungsmethoden evaluiert. Am Ende der Analyse folgt eine Diskussion über die Verwendbarkeit jener Methoden in diesem Szenario. Abgeschlossen wird diese Untersuchung von einem Programm, welches die entsprechenden Methoden zur Klassifizierung implementiert.
Taktstraße
(2008)
Eine Taktstraße ermöglicht eine automatisierte Verarbeitung eines Werkstückes mit Hilfe von Förderbändern, Lichtschranken, Schiebern und Bearbeitungsstationen. Für eine vorgegebene Taktstraße wird eine Ansteuerung entwickelt. Dazu wird der Mikrocontroller ATMega16 von Atmel eingesetzt. Ein externer Controller sendet über den TWI-Bus Steuerbefehle an den mit der Taktstraße verbundenen Controller. Um die Taktstraße bedienbar zu machen, wird eine geeignete Platine entworfen sowie eine LCD-Bibliothek als Ausgabe- und Informationsmedium. Die Arbeit umfasst alle für ein Projekt im Rahmen eines Informatikstudiums benötigten Entwicklungsstadien von der Projektplanung über die Aneignung von spezifischem Grundlagenwissen, die Hard- und Softwareentwicklung bis hin zu ausführlichen Entwicklungs- und Testphasen.
Im Rahmen der Glaukomdiagnostik sind Größe und Position des Sehnervkopfes wichtige Parameter zur Klassifikation des Auges. Das Finden und exakte Markieren der Papille ist ein subjektiver Vorgang und kann von Arzt zu Arzt stark variieren. Ziel der Arbeit ist die Entwicklung eines automatischen Verfahrens zur Detektion der Papille. Zunächst wird der medizinische Hintergrund erläutert (Aufbau des Auges, Glaukom) und das bildgebende Verfahren, der Heidelberg Retina Tomograph, dargestellt. Nach einer Diskussion bisheriger Ansätze zur Detektion der Papille wird ein eigenes Verfahren entwickelt und detailliert beschrieben. Für bei der Implementation aufgetretene Probleme werden Ansätze zur Optimierung vorgeschlagen.
In dieser Studienarbeit werden neben den Grundlagen der Web Services, Komponenten und APIs zur Realisierung des Sticky Loggings aufgezeigt. Es wird ein Szenario zum Testen des Sticky Loggings beschrieben und als Web Services implementiert. Der Sticky-Logging-Formalismus wird erklärt und es wird eine API zur Erstellung der StickyLogs implementiert. Die StickyLogs werden innerhalb des SOAP-Attachments der SOAP-Nachrichten zwischen den Web Services ausgetauscht. Dazu wird eine Realisierung mit einem Messagehandler unter JAX-WS programmiert und erläutert.
In der vorliegenden Studienarbeit wird eine OpenGL-Applikation vorgestellt, die Geometrie-Shader in einem Feedback-Loop einsetzt, um auf der GPU Geometrie zu erzeugen. Dargelegt werden die erforderlichen Grundlagen Geometrie-Shader und Transform Feedback betreffend, die Umsetzung der Anwendung und die eingesetzten GLSL-Shader.
Im Rahmen dieser Studienarbeit wurde ein Faktenextraktor für Java-Quelltexte entwickelt. Der Javaextraktor generiert eine TGraph-Repräsentation der Quelltexte eines in Java implementierten Softwareprojekts. Dieser TGraph ist dann durch dieWerkzeuge des Gupro-Projekts weiter verarbeitbar. Der Javaextraktor kann Javaquelltexte bis einschließlich Javaversion 6 verarbeiten. Dazu wurde ein Werkzeug gefunden, welches den Parsingvorgang übernimmt, so dass diese Funktion nicht selbst implementiert werden musste. Zusätzlich wurde ein Javametamodell und entsprechendes Schema für den TGraph entwickelt. Die Knoten- und Kantentypen des Metamodells konnten automatisiert mit JGraLab aus dem Schema erzeugt werden.