OO-OKSTRA - objektorientierte Weiterentwicklung des OKSTRA^®

Zentraler Leitgedanke des OKSTRA^® ist es, Interoperabilität zu schaffen zwischen unterschiedlichen IT-Landschaften bei Straßenbau- und Verkehrsverwaltungen, Ingenieurbüros sowie der Industrie. Der OKSTRA^® in seiner jetzigen Form verwirklicht dieses Ziel durch den Austausch von Daten in Form von Dateien in einem standardisiertem Format auf der Basis eines standardisierten Objektverständnisses.

Der heutige Ansatz kann durch die Verwendung von objektorientierter Technologie entscheidend verbessert werden. Der grundsätzliche Paradigmenwechsel soll an einem einfachen Szenario erläutert werden (Hinweis: Das Szenario soll nur zur Verdeutlichung der grundsätzlichen Unterschiede dienen und erhebt keinen Anspruch auf sachliche Korrektheit!):

Aufgabe

"Der Mitarbeiter A.S. der Straßenbauverwaltung benötigt im Zuge einer Straßenneubauplanung die Gesamtfläche der betroffenen Flurstücke. Er kennt den von der geplanten Trasse betroffenen Korridor."

Bisherige Vorgehensweise

• A.S. nimmt Kontakt zur zuständigen Stelle auf und vereinbart die Lieferung der Flurstücksdaten im betroffenen Gebiet. Dabei müssen eine Reihe von Punkten vereinbart werden: Das Format der Austauschdatei, das Referenzsystem der Geometrie, das Koordinatensystem der Geometrie usw.
• Die zuständige Stelle liefert nach einigen Tagen die Datei. A.S. muss die Datei in sein Entwurfssystem einlesen. Dafür muss dieses das vereinbarte Format und die vereinbarten weiteren Parameter kennen und verarbeiten können. Dieser Schritt bereitet in der Praxis immer wieder Probleme. A.S. kann nun in seinem Entwurfssystem eine Verschneidung des Korridors mit den Flurstücken durchführen. Dabei muss sein Entwurfssystem die über die Grenzen definierten Flurstücksflächen bilden.
• Von den gefundenen 147 Flurstücken können nun die Flächengrößen berechnet werden - erneut unter Bildung der über die Grenzlinien definierten Flächen. Die Flächengrößen werden aufsummiert.

Vorgehensweise mit OKSTRA^®

• Analog zur bisherigen Vorgehensweise mit der wesentlichen Vereinfachung, dass mit dem OKSTRA^® ein standardisiertes Format vorliegt und auch bisher ergänzend auszutauschende Parameter Bestandteil des OKSTRA^® sind.
• Ergebnis: Der Datenaustausch wird signifikant vereinfacht, eine grundsätzliche Änderung der Vorgehensweise erfolgt nicht.

Vorgehensweise mit objektorientiertem OKSTRA^®

• A.S. markiert in seinem Entwurfssystem den Korridor und ruft eine Funktion zur Berechnung der betroffenen Flurstücke auf.
• Das Entwurfssystem von A.S. nimmt über eine Online-Schnittstelle Kontakt zu einem Server der zuständigen Stelle auf und autorisiert sich.
• Es setzt eine Selektion ab, die alle Flurstücksobjekte erfragt, deren Fläche sich mit der Korridorfläche schneidet. Der Server liefert die Identifikatoren der gefundenen Flurstücke zurück (nicht die gesamten Flurstücksdaten!).
• Das Entwurfssystem meldet A.S., dass 147 Flurstücke gefunden wurden. A.S. stößt eine Funktion zur Berechnung der Flächengröße der Flurstücke in der Ergebnismenge an. Das Entwurfssystem verbindet sich erneut mit dem Server und fragt die 147 Flurstücke nach ihrer Flächengröße. Das Ergebnis wird aufsummiert und A.S. angezeigt.

Dadurch wird die Möglichkeit geschaffen, von einer datenbasierten zu einer dienstebasierten Architektur des Informationstransportes überzugehen: Ausgetauscht werden nicht mehr die Daten eines Objekts, sondern die Objekte beantworten Fragen und führen Aufträge aus. Der Geschäftsablauf wird nicht mehr durch den Datenlieferanten bestimmt, sondern durch den Nutzer.

Die Nutzung einer Online-Schnittstelle, die eine dramatische Beschleunigung des Ablaufs ermöglicht, ist nicht auf objektorientierte Ansätze beschränkt. In der Realität haben sich aber die entsprechenden IT-Standards im Kontext objektorientierter Technologien entwickelt.

Die Vorteile des objektorientierten OKSTRA^®

• Aktualität: Jedes reale Objekt des bestehenden und geplanten Straßennetzes braucht nur einmal repräsentiert zu werden. Diese eindeutige Repräsentation spiegelt den aktuellen Zustand des realen Objektes jederzeit wieder, d.h. der Lebenslauf des realen Objektes findet seine Entsprechung in seiner Repräsentation. Aktualitätsprobleme durch mögliche unkoordinierte Pflege verschiedener Kopien einer Objektrepräsentation können entfallen.
• Redundanzfreiheit: Informationsaustausch erfolgt statt durch den Austausch der Objekte durch Nachrichten zwischen den Objekten. Die angeforderten Informationen müssen daher nicht alle physisch vorgehalten werden. Stattdessen können sie flexibel aus Basisdaten durch Berechnung ermittelt werden.
• Transparenz: Die Berechnungsverfahren können selbst vom Zustand des befragten Objektes (z.B. Genauigkeit und Detaillierung der Objektdaten) abhängig gemacht werden, ohne dass die anfragende Instanz das Wissen hierüber benötigt.
• Konsistenz und Regelkonformität: Die Daten eines Objektes können vor dem Zugriff durch andere Instanzen wirkungsvoll geschützt werden, da alle Zugriffe sich in Form von Operationen abspielen. Damit lassen sich die Konsistenz der Basisdaten und ihre Übereinstimmung mit den existierenden Regelwerken sicherstellen.
• Wartungsfreundlichkeit: Die Auswirkung von Änderungen der Regelwerke auf die Software, die den OKSTRA^® nutzt, ist bei einem OO-Design deutlich geringer. Während bei einem statischen Design sich Datenformate ändern können und damit tiefgreifende Änderungen der betroffenen Softwaresysteme notwendig werden können, ist bei OO-Design häufig gar keine Änderung der nutzenden Software erforderlich, da die Implementation der Regeln von der nutzenden Software (den Clients) in die OKSTRA^®-Objekte verlagert ist.

Kernideen objektorientierter Architekturen

• Objekte übernehmen klar definierte und begrenzte Verantwortlichkeiten
• Objekte kooperieren miteinander durch den Austausch von Nachrichten
• Der Empfang einer Nachricht kann den Zustand eines Objektes beeinflussen.
• 
  
• Objekte haben eine unverwechselbare und unveränderbare Identität. Nachrichten verwenden diese Identität als Adresse.
• Objekte bieten Dienste in Form von Schnittstellen an. Diese definieren für das Objekt verfügbare Operationen, durch die die Nachrichten ausgetauscht werden. Ein Objekt ist von außen nur über Operationen zugänglich.

Zielsetzung des Forschungsprojekts Objektorientierter OKSTRA^®

Der objektorientierte OKSTRA^® beschreibt nicht die Architektur von Anwendungen, sondern ein standardisiertes Angebot von Diensten, mit denen sich Anwendungen regelkonform, herstellerneutral, plattformunabhängig, technisch aktuell und wirtschaftlich realisieren lassen.

Das Forschungsvorhaben konzentrierte sich auf die Klärung der Frage, wie eine objektorientierte Modellierung für den OKSTRA^® hergestellt werden kann. Als Primärziel des Forschungsprojektes wurde die Bereitstellung und Dokumentation der methodisch-analytischen Hilfsmittel für eine später durchzuführende durchgängige Modellierung festgelegt. Die hierzu gewonnenen Ergbnisse sind in einem 200-seitigen Leitfaden niedergelegt.

Die Realisierung des objektorientierten Designs erfolgt durch die Definition von Operationen zu den OKSTRA^®-Objekten. Welche Operationen benötigt werden, ergibt sich daraus, was mit den Objekten angestellt werden soll, d.h. letztlich sind die Geschäftsprozesse des Straßen- und Verkehrswesens ausschlaggebend dafür, welche Fähigkeiten die OKSTRA^®-Objekte benötigen.

Eine Erweiterung des bestehenden OKSTRA^® in einen OO-OKSTRA^® erfordert daher zunächst eine Inventur und Klassifizierung der Geschäftsprozesse und ihrer Zusammenhänge. Für die Geschäftsprozesse zu einer Neubaumaßnahme wurde im Forschungsvorhaben ein derartiger Geschäftsprozesskatalog erarbeitet. Jeder zur Untersuchung anstehende Geschäftsprozess wird mit den Verfahren der objektorientierten Geschäftsprozessodellierung in Aktivitäten und Anwendungsfälle zerlegt und formal strukturiert. Aus der Analyse dieser Untereinheiten bildet sich zunächst die Objektwelt des Geschäftsprozesses. Aus dem Zusammenwirken der Objekte werden ihre Verantworlichkeiten und daraus ihre Nachrichten-Austausch-Beziehungen abgeleitet. Diese werden als Operationen formal gefasst. Eng zuammenwirkende Objekte bilden die Grundlage für fachliche Dienste, die in geeigneter Realisierung (z.B. als Web Services) zur Unterstützung des untersuchten Geschäftsprozesses eingesetzt werden können. Als Musterbeispiel für eine Modellierung eines maßnahmenbezogenen Prozesses wurde die Kostenberechnung innerhalb einer Baumaßnahme ausgewählt (Siehe hierzu den erarbeiteten Leitfaden)

Der Einsatz von OO-Technologien erfordert auch den Einsatz neuer Werkzeuge zur Formulierung und Vermittlung des OO-OKSTRA-Modells sowie zur Realisierung der Kommunikation zwischen den OKSTRA^®-Objekten. Beispiele sind die Nutzung des de-facto-Standards bei objektorientierten Modellierungssprachen UML und der weitgehende Einsatz von "Internetstandards" wie XML und SOAP. Daneben existieren eine ganze Reihe weiterer Standardisierungsvorschläge für Kernaufgaben in verteilten, dienstebasierten Systemen (u.a. Ereignisverarbeitung, Transaktionen und Sicherheit)

In den folgenden Dokumenten finden Sie detailliertere Informationen zu den Ergebnissen aus diesem Forschungsvorhaben:

Zurück zur OOKSTRA-Übersicht.