Taras Shymbra, Software-Ingenieur

Toll Enforcement Gantry

Ich habe in Deutschland zwischen 2002 und 2007 gearbeitet. Mein letztes Projekt war Entwicklung von Kontrollbrücken für LKW-Maut in Deutschland.

Ich hatte Verantwortung für mehrere Software-Module der Kontrollbrücke übernommen und befasste mich mit allen Aspekten des Datenmanagements, Entwicklung von Software zum Datenzugriff sowie Entwurf und Optimierung von Strukturen zur operativen Datenhaltung. Mein Aufgabengebiet umfasste auch die Kommunikation wie zum Beispiel Kurzstrecken-Kommunikation nach DSRC-Standard. Die Software war unter harten Echtzeit-Anforderungen entworfen, denn die Einrichtung kontrolliert LKWs im normalen Straßenverkehr.

Als verantwortlich für das Backend und die Kommunikation setzte ich mich besonders stark mit verschiedenen kryptographischen Technologien auseinander. Im Verlauf des Projekts vertiefte ich mich immer mehr in Kryptographie. Die erworbene Kompetenz erlaubte mir an sicherheitsrelevanten Aspekten des Projekts aktiv mitzuwirken.

Alle Projektteilnehmer wurden durch Anwendungen zur Quelltextverwaltung, Versionskontrolle und Fehlerverfolgung unterstützt, wobei im Mittelpunkt ein vollautomatischer Software-Build-Server stand. In diesem Arbeitsumfeld hatte ich gelernt für Probleme angemessene Lösungen zu finden, wobei bei meiner Arbeit die Balance zwischen technischer Innovation und pragmatischem Design eine zentrale Rolle spielte. Ich hatte viel über Software-Engineering und die Architektur großer Systeme gelernt, noch mehr aber über die ingenieurmäßige Entwicklung von umfangreicher mission critical Software-Systemen.

Neben Entwicklung von Software beschäftigte ich mich mit Erstellung von Pflichtenheften und Entwurfdokumenten. Ich habe unsere QM-Leute durch Konzeption von Testabläufen zum regressiven Testen sowie Roll-Out-Team bei Inbetriebnahmen und Fehlerbehandlungen unterstützt. Darüber hinaus koordinierte ich die Zusammenarbeit zwischen Entwicklern und Testern bei der Erarbeitung der Prüfspezifikationen

Im Projekt erledigte ich viele interessante und vielfältige Aufgaben. Termingerechte Bereitstellung von zwei wichtigen Features schon nach einigen Monaten seit meinem Einstieg ins Projekt erforderte effektive und schnelle Einarbeitung in neue Sachverhalte.

Die Einrichtung zur Mautkontrolle läuft jetzt im Wirkbetrieb. Nach dem Einschalten von Mautsystem beschäftigte ich mich hauptsächlich mit der kontinuierlichen Pflege der Software.

WINGS-FOR-SHIPS

Ich war im Bereich Geschäftsprozesse/Telematik im Forschungsinstitut für anwendungsorientierte Wissensverarbeitung (FAW) in Ulm, Deutschland als Wissenschaftlicher Mitarbeiter und Software-Entwickler von Anfang 2002 bis Mrz 2003 tätig. Meine letzte Aufgabe dort (nach Abschluss vom POWM) war Mitarbeit am Projekt WINGS-FOR-SHIPS (Maritime Intelligent Workplace for weather Information Network, Guidance and Supervision onboard ships).

Das Telematik-Projekt WINGS-FOR-SHIPS war durch EU gefördert und sollte der Seefahrt die Telematikdienste wie Verkehrsmanagement und Wetterinformation zur Verfügung stellen. Insbesondere Hochgeschwindigkeitsfähren, die Küsten in Rekordzeit verbinden, müssen in Sekundenschnelle auf enorme Informationsmengen zugreifen können. Dort sah IST der Europäischen Union den Bedarf für ein verteiltes Informationssystem, das Kapitäne bei kritischen Entscheidungen unterstützt. Dadurch sollten riskante Situationen vermieden und Schiffspassagen sichergestellt werden.

Das FAW war ein der zahlreichen Projekt-Partnern aus verschiedenen EU-Länder. Wir waren beauftragt den zentralen Server zu entwerfen. Dafür haben wir eine Referenzarchitektur des Backend erstellt, die notwendigen Komponenten evaluiert und eine Pilot-Lösung implementiert. Die Java Technologie, Apache Tomcat, PostgeSQL unter RedHat Linux waren für die Pilot-Lösung eingesetzt. Die kostengünstigeren Open-Source Produkten waren natürlich bevorzugt.

Im Projekt beschäftigte ich mich hauptsächlich mit dem Datenmodell des Systems. Angefangen mit der ER-Datenmodellierung, hatte ich anschließend ein physikalisches relationales Datenschema mit ca. 30 Tabellen entworfen, das die Informationen über Wetter, Schiffe, Hafen und Route beinhaltete.

Alle Projekt-Partner trafen sich regelmäßig zur Besprechungen. Ich war mit meinem Kollegen bei einem Review-Meeting zum Aufzeigen der ersten Version der Serveranwendung im Februar 2003 in Nizza dabei. Dort wurde die softwaretechnische Architektur des Servers akzeptiert und das Projekt war in die Entwicklungsphase weitergegangen.

Beim Entwurf vom WINGS-FOR-SHIPS lernte ich viel über Projektarbeit in einem internationalen Team.

POWM

Vor meiner Arbeit am Projekt WINGS-FOR-SHIPS beteiligte ich mich im FAW in Ulm an der Entwicklung eines maßgeschneiderten Softwarewerkzeugs für prozessorientiertes Wissensmanagement POWM für einen deutschen Fahrzeughersteller. Die Anwendung ermöglichte es den Ingenieuren, die Planung, Dokumentation und Durchführung von Engineeringprojekten in verteilten Arbeitsumgebungen auszuführen. Die Philosophie des Tools war, Wissen über Prozesse, die eine besonders wichtige Ressource eines Unternehmens zur Wettbewerbssicherung und Innovationsfähigkeit sind, zu erfassen und wieder verwenden. Einer der größten Vorteile des Tools bestand darin, dass die Prozesse und ihre Bausteine bei Wiederverwendung an projektspezifische Rahmenbedingungen angepasst werden könnten. Das POWM war eine Oracle-basierte Enterprise-Lösung.

Ich war für das MyPowm-Modul verantwortlich. Das MyPowm-Modul stellte eine personalisierte Ansicht der Prozesse, und dazugehörigen Aktivitäten sowie Dokumente eines Benutzers dar. Meine Aufgaben umfassten vor allem die Entwicklung und Optimierung von der grafischen Benutzeroberfläche mit der JFC-Klassenbibliothek (Swing).

Die Effizienz und Übersichtlichkeit der graphischen Oberfläche waren die Hauptanforderungen an dem MyPowm-Modul. Das GUI sollte dem Benutzer die Möglichkeit bieten auf seine geplanten Aktivitäten und auf die mit diesen Aktivitäten verknüpften Dokumente sowie Prozesse rasch zugreifen. Deshalb waren die Aktivitäten und Dokumente in Tabellen repräsentiert.

Zur tabellarischen Darstellung war die JFC-Bibliothek benutzt. Zur Integration der anwendungsspezifischen Datenklassen (wie z.B. "Activity" oder "Dokument") mit dem Datenmodell kamm ein frei verfügbares Framework iData zum Einsatz. Dieses Framework bietete eine zusätzliche Sicht der Indirektion zwischen den Datenobjekten und den View-Klassen. Im Rahmen der Model-View-Controller Architektur erleichterte diese Sicht die Programmierung von komplexen und erweiterten Benutzeroberflächen. Jede Zelle eines TabelModels wird als ein eigenständiges intelligentes iData-Objekt dargestellt. Die Klasse eines iData-Objekts implementiert die Funktionalität die für den Abruf von Datenobjekten sowie für ihre graphische Darstellung und Editieren zuständig ist. Das iData Framework eliminierte mehrfache Verdoppelung von prinzipiell identischen Codeteilen.

Anhand des iData habe ich auch die Sortierung und Filterung der Tabellen rasch implementiert wobei die Einstellungen des Filters in einer XML-Datei abgelegt sein können. Dazu könnten die Eigenschaften wie Status oder Priorität des jeweils ausgewählten Elements direkt in der Tabelle verändert werden.

Es hat sich gezeigt das die Verwendung eines geeigneten Open Source Frameworks nicht nur die Entwicklungszeit reduziert sondern auch die Widerverwendbarkeit erhöht und mehrfache Verdoppelung von prinzipiell identischen Codeteilen (z.B. dieselbe Klasse ist bei der Darstellung von Status sowohl einer Aktivität als auch eines Dokuments benutzt worden) eliminiert.

Die Entwicklungsarbeiten des POWM werden in der Entwicklungsumgebung Intellij IDEA durchgeführt wobei eine Menge von XP-Techniken und Werkzeugen wie Java-Ant, JUnit, CVS, Refactoring (das Konzept wird durch die IDEA unterstützt) angewandt war.

Zudem habe ich dem Entwicklerteam geholfen der Quelltextverwaltung CVS einzuführen. Unter anderem habe ich den CVS-Server konfiguriert, das Projekt unter CVS-Verwaltung gestellt und mich mit der Beratung zu verschiedenen Aspekten der Verwendung des WinCVS befasst.

TDM Framework

Im Anschluss an meine Arbeit am Projekt POWM im FAW in Ulm, konnte ich recht gute Erfahrung mit dem Konzept Model-View-COntroller (MVC) sowie mit der Manipulation von Daten erwerben. Es handelt sich vor allem um solche Arten der Datenmanipulation wie Sortierung und Filterung von Daten, die in Tabellen oder Listen dargestellt sind. Aus dieser Erfahrung ist ein frei verfügbares Framework TDM (Tabular Data Manipulation) entstanden.

Der Leitgedanke des TDMs ist einfach: einfache Manipulation von Daten eines Modells ohne Veränderung des Inhalts dieses Datenmodells zu ermöglichen und damit die Daten von deren Darstellung zu trennen.

Hier können Sie das TDM herunterladen. Zum Framework gibt es auch ein Design-Dokument Tabular Data Representation Manipulation.

SMIL Player

Von 1999 bis 2001, arbeitete ich in der israelischen Firma InterObject schon während meines Studiums der Informatik. Ich arbeitete in der Niederlassung in der Stadt Lemberg, Ukraine. Damals noch als ein Startup bot InterObject hochwertige Beratung und Projektumsetzungen für Unternehmen in der Telekommunikationsbranche sowie in der Halbleiterindustrie an.

Bei dieser Firma war ich im Bereich der objektorientierten Softwareentwicklung tätig und beteiligte mich an der Implementierung großer Software-Systeme. Als Programmierer bei InterObject sammelte ich Praxiserfahrung in allen wichtigeren OO-Programmiersprachen: Java, Smalltalk und C++

In dem letzten Projekt bei der Firma InterObject (vorher beteiligte ich mich am Projekt ProCell) wurde ein Multimedia-System und zwar ein von Grund auf neues SMIL Player in C++ entwickelt. SMIL (Synchronized Multimedia Integration Language) ist eine XML-Sprache, die Integration von Multimediaobjekten wie Audio, Video, Grafiken und Texten zur Präsentationsdarstellung ermöglicht.

Ein Jahr lang arbeitete ich auch in einem Team von fünf Mitarbeitern an diesem Softwareprodukt mit. Zunächst nahm ich an der Einrichtung von Architektur des Players aktiv teil, ihr wurde nämlich bereits von Anfang an höhere Aufmerksamkeit geschenkt.

Eine der zentralen und wesentlichen Erfordernisse war es, der SMIL-Player sollte auf den verschiedenen Plattformen laufen. Um sowohl die Portabilität als auch die Reduktion der Komplexität zu erzielen, basierte die Komponentenarchitektur des Players, auf mehreren hierarchisch angeordneten Schichten von Abstraktionen. Der Player wurde als ein modulares System entworfen. Die Komponente der untersten Schicht, Media-Presentation-Objects (MPO) realisierte die Wiedergabe von Audio- und Video-Datenstrmen wobei für die Windows-Version des Players die DirectX-Klassenbibliothek eingesetzt wurde. Die nächste Systemschicht implementierte die Execution-Engine, die grundsätzliche, zeitliche und räumliche Modele der SMIL realisierte. Eine weitere Schicht, das Modul SMIL-Data-Handling, war für die Analyse von SMIL-Dokumenten sowie für Anpassung an Benutzerpräferenzen (Bit-Rate, Sprache, Bildschirmauflösung) zuständig. Benutzerschnittstelle des Players mit dem Skin-Support (wechselnde Oberflächen) wurde durch die Komponente der höchsten Schicht realisiert.

Alle Komponente des Players wiesen eine wohldefinierte Funktionalität auf und einzeln entwickelt und getestet werden könnten. Deshalb war effektive Teamarbeit erfolgreich, weil jedes einzelne Mitglied die Verantwortung für jede einzelne Komponente übernahm. Die Zusammenfügen von Komponenten zu einem System und allgemeine Problemlösung waren die kollektiven Aufgaben.

Ich war für das Execution-Engine des Players eigenständig verantwortlich. Diese Komponente implementierte die SMIL-Kernfunktionalität und war nur für die Aufgaben wie zeitliche Steuerung des Ablaufs und Kontrolle des Layouts eine Multimediapräsentation zuständig. Die beinhaltete keine Funktionen, die mit dem Mediatyp eines Multimediaobjektes in Zusammenhang stehen, weil die SMIL-Spezifikation keine Vorschriften für die Formate von Multimedia-Dateien enthält. Die SMILEE interpretierte eine SMIL Präsentation, synchronisierte ihre SMIL Mediaelemente und steuerte die Bestandteile der unteren Schicht für die Medienwiedergabe.

Der objektorientierte Entwurf der SMILEE-Komponente geschah unter Verwendung der UML und Rational Rose. Bei der Realisierung und Testen der Komponente wurden STL-Klassenbibliothek sowie Entwurfsmuster und Frameworks (CppUNIT usw.) verwendet. Die Werkzeuge NuMega BoundsChecker und NuMega TrueCoverage kamen für das Testen und Debuggen vom Player und dessen Komponenten unter Windows-Platform zum Einsatz.

Die Portierung der SMILEE auf die Pocket PC Architektur (Compaq-iPaq mit Windows CE 3.0) wurde mit der Hilfe von eMbedded Visual C++ durchgeführt. Da die Komponente völlig betriebssystemunabhängig war wurde sie in die WindowsCE Ausführungsumgebung ganz schnell lauffähig gemacht.

Bei der Entwicklung des Players hatte das Projektteam die Techniken der Extreme Programming (XP) sowie Prinzipien iterativer und agiler Softwareentwicklungsprozess eingesetzt. Die XP-Techniken ermöglichten es, während der Entwicklung auf sich rasch ändernde Anforderungen zu reagieren.

Die Entwicklung des SMIL-Players und nämlich der SMILEE-Komponente war eine der größten Herausforderungen meiner Berufslaufbahn. Die Komponente basierte auf erprobten und bekannten GoF-Entwurfsmustern.

ProCell

Im Weiteren, wenn ich bei InterObject arbeitete, wirkte ich am Projekt ProCell im Bereich der Halbleiterindustrie.

Bezüglich der Systemarchitektur ist ProCell sehr ähnlich dem Lynx Projekt. Die Software wurde für die Maschine für Verarbeitung des Fotolacks entwickelt. Das ControlWORKS Framework sowie VisualWorks für Smalltalk wurden auch für die Entwicklung des Procell eingesetzt. Das ProCell wurde auch als eine verteilte Softwarelösung aufgebaut, die aus zwei Smalltalk-Images, Maschine-Controlling-Image und das Host-Image bestand. Die Maschine bestand aus mehreren Prozesskammern und die Wafer wurden mit vier Roboter transportiert.

Aufgrund der Komplexität des Zusammenspiels zwischen Robotern, Wafern und Prozesskamern war die Waferflusssteuerung in solcher Maschine nicht trivial. Das Scheduler-Subsystem des ControlWORKS war für Waferflusssteuerung verantwortlich. Der Scheduler basierte auf einem komplexen regelbasierten Entscheidungssystem das über mit Hilfe der Scheduler-Regel Entscheidungen trifft. Die Regeln angeben welcher Prozessschritt einer Prozesssequenz als nächster ausgeführt werden muss. Der Scheduler der in regelmäßigen Abständen abläuft, überprüft derzeitig verfügbare, alternative Prozessschritte und stimmt sie mit allen Regeln ab. Sie vergeben jedem Prozessschritt eine Note um die die Reihfolge der Ausführung zu bestimmen.

Meine Aufgabe war im Projekt war die Einführung des Features "Pilot Wafer Flow". Bei der Entwicklung dieses Features war eine Menge von Unteraufgaben zusammengestellt, inklusive Entwurf und Programmierung der Benutzeroberfläche (Roboteranimation), Eingabe neuer und Modifizierung bestehender Scheduler-Regeln. Eine weietere Aufgabe bestand in der Konfiguration des Schedulers, um sowohl die Laufzeit von Wafer durch die Maschine zu minimieren als auch den Durchsatz der gesamten Maschine zu maximieren.

Das ProCell ließ sich erfolgreich ohne Zugang zur Maschine entwickeln, weil das Maschine-Controlling-Image simuliert werden konnte. Das Feature "Pilot Wafer Flow" wurde im Entferntesten implementiert. Erst nachdem es in der Simulation fertig war, musste das Feature mit der echten Maschine in Betrieb genommen werden. Deshalb war ich auf Dienstreisereiste in San Jose,USA, wo ich mich mit der Vor-Ort-Beratung und Problembeseitigung des "Pilot Wafer Flow" Features beim Kunden Unternehmen befasste.

Wenn ich am ProCell arbeitete, stand ich kurz vor dem Abschluss meines Studiums. In diesem Zusammenhang, schrieb ich im Rahmen dieses Projekt meine Diplomarbeit (Master's Thesis) "Automatisierte Prozesssteuerung bei Herstellung von Halbleitern".

Lynx

Nach dem Projekt SCU, ging es weiter bei InterObject mit Projekt Lynx für die Halbleiterfertigung. Ich hatte an dem Projekt im Mrz 2000 angefangen. Das Ziel des Projekts war die Erstellung eines SCADA-Systems (Supervisory Control And Data Acquisition) zum überwachen und Steuern von einem Cluster-Tool (Einzelwafer-Bearbeitung-Maschine für das "Chemical Vapor Deposition" CVD Verfahren) und zur Visualisierung von dessen Anlagenzuständen.

Unter einem Cluster-Tool versteht man eine Maschine, in der mehrere Prozessschritte integriert sind, um sie nicht in separaten Gerten auszuführen.

Das Lynx wurde als eine verteilte (Client-Server) Softwarelösung aufgebaut und basierte auf ControlWORKS Framework. Die zwei Bestandteile des Systems residierten in zwei Smalltalk-Images die auf verschiedenen Rechnern liefen. Das erste Image (Maschine-Controlling-Image) war für direkte Kommunikation mit Aktuatoren und Sensoren der Maschine verantwortlich. Es wurde auf einem Embedded-Rechner ausgeführt und diente als Server für das zweite Image. Das andere Image(Host-Image) umfasste die Funktionen die ein herkömmliches SCADA-System besitzt. So war es unter anderen für die folgenden Aufgaben zuständig: die Datenprotokollierung, Rezepturmanagement, Waferbewegung, Wafer-Los-Planung, Alarmmanagement, Ereignismanagement und Maschinenpflege. Deshalb, enthielt das Host Image auch die Benutzeroberfläche zur Steuerung der Maschine.

Im Rammen des Lynx Projekts beschäftigte ich mich mit dem Host-Image. Zur den Aufgaben die ich erfolgreich erfüllt hatte zahlen: Erstellung der Benutzeroberfläche sowohl zur Temperaturüberwachung in der Prozesskammer als auch zur Setzung von Prozessvariablen und Verbesserung des Bestandteils welches für das Alarmmanagement in der Prozesskammer verantwortlich war.

Bei Mitwirkung am Lynx Projekt erwarb ich meine erste Kompetenz an Entwurfsmustern und baute allmählich die Grundlage für die professionelle OO-Entwicklung.

SCU

Im Dezember 1999 fing ich bei der Firma InterObject an und mein erstes Projekt war SCU (System Configuration Utility). Dieses Projekt war überhaupt das erste industrielle Projekt meiner Berufslaufbahn und es hatte mit Java und Oracle zu tun. Es ging darum, ein Schalter-Konfigurations-Dienstprogramm für IP- Telefonie-Gateways als eine verteilte datenbankbasierte Java-Anwendung zu entwickeln.

Die verwendete Technologie basierte auf einer Drei-Schicht-Architektur. Auf der Ebene zwischen der Nutzerschnittstelle und der Datenbank wurde Objekt-to-Relational Mapping Funktionalität realisiert, wobei das JDBC für den Zugriff auf die relationale Datenbank Oracle eingesetzt wurde.

Meine Aufgabe war die Einführung von der graphischen Benutzeroberfläche, die als ein Java-Applet implementiert wurde. Die grafische Oberfläche implementierte ich mit den JFC-(Swing)-Klassen. Die Kommunikation zwischen der mittleren Schicht und der Benutzeroberfläche erfolgte durch das Java RMI. So kommunizierte die Benutzeroberfläche nicht direkt mit dem Datenbankserver, sondern mit einem RMI-Server.

Das Projektteam bestand aus vier Mitarbeitern. Zwar arbeitete am Projekt nur während vier Monaten hatte aber damals eine Menge über objektorientierte Programmierung, und den Software-Entwicklungsprozess gelernt sowie meine Teamfähigkeit verbessert.

YDV

Praxiserfahrungen im Bereich Software Entwicklung konnte ich bereits im 1998 im Rahmen meiner IAESTE-Praktika im Forschungsinstitut fr anwendungsorientierte Wissensverarbeitung in Ulm, Deutschland sammeln.

Während meiner Praktika beschäftigte ich mich mit der Forschung zur Informationsvisualisierung. Einer der Hauptschwerpunkte lag auf der Visualisierung von Graphen und Graphlayout Algorithmen. Ziel dieser Forschung war, Positionen fr die Knoten eines Graphen im Zusammenhang mit einem Graphlayout Algorithmus optimal zu bestimmen um schnelleres Verstehen und leichteres Arbeiten mit Graphen und Bäumen zu ermöglichen.

An der praktischen Seite der Forschung war die Entwicklung von einem webbasierten, interaktiven Werkzeug zur effektiven Suche im Yahoo-Katalog.

Das Werkzeug bekam den Namen YDV was fr Yahoo Directories Visualiser stand. Es erzeugte aus hierarchischen baumartigen Suchergebnissen einen 3 dimensionalen Datenraum, der graphisch in einem Web-Browser als eine VRML-Welt dargestellt wurde. Der Baum solches Datenraums enthielt an seinen Knoten Referenzen auf gefundene Dokumente. Jedes Dokument wurde als VRML-Würfel und die Beziehungen zwischen Dokumenten wurden als VRML-Zylinder repräsentiert.

Benutzer konnten durch den virtuellen Raum navigieren und ganz rasch sich im Suchergebnisse orientieren. Zudem konnte man schnell Detailinformation, wie z.B. Titel über interessierende Dokumente einholen.

Mit dem YDV wurde das Konzepts des "Informationsraums" implementiert. Da in räumlichen Strukturen man sich besser zurechtfinden und Zusammenhänge schneller erkennen kann, ermöglichte das YDV schnelle und verständliche Suche in umfangreichen Datenbeständen.

Für die Entwicklung des YDVs wurde ein Open-Source Perl-VRML-Modul verwendet. Dieses Modul wurde für die Erzeugung von VRML auf WWW-Servern über die CGI-Schnittestelle und zum Generieren abstrakter Welten konzipiert.

Das YDV bestand aus zwei Perl-Scripts. Das erste Script las und analysierte das HTML-Dokument mit den Suchergebnissen und bereitete seinen Inhalt für das zweite Script vor. Das zweite Script das, im Grunde genommen, das Perl-VRML-Modul verwendete, erstellte dann die VRML-Datei die an den Browser übermittelt wurde.

Projekte

Gebiete