Was ist KOMET?

Abbildung 1: Eine typische KOMET-Anwendung
(Klicken Sie ins Bild, um es zu Vergrößern)

KOMET ist eine Plattform mit deren Hilfe sich nahezu beliebige Softwareprodukte zu einem System "aus einem Guß" zusammenstellen lassen. In Szenarien, wo Ergebnisse eines Programmes als Eingangsdaten eines anderen dienen, können diese Informationen dank einer ausgeklügelten semantischen Datenbeschreibung vollautomatisch abgefragt und übertragen werden.

Eine KOMET-Anwendung besteht aus drei wesentlichen unabhängingen Teilen, mit Hilfe einer eigens entwicklten formalen Sprache (KometML, siehe unten) miteinander kommunizieren: Es spielt dabei kaum eine Rolle, ob es sich bei dem Solver um eine neue Software handelt oder um ein Programm, das schon früher erstellt wurde. Im letzteren Fall wird ein kleines Hilfsprogramm (Wrapper) geschrieben, das mit EUS-Kern und Alt-Anwendung kommuniziert (siehe Abbildung 1).

Abbildung 2: Die KOMET-Architektur
(Klicken Sie ins Bild, um es zu Vergrößern)

Die technische Grundlage liefert die KOMET-Architektur, die in Abbildung 2 schematisch dargestellt ist. Man erkennt sehr schön, wie die 3-Schichten-Architektur aus dem IT-Umfeld die von Sprague (1980) eingeführten Subsysteme aus dem EUS-Umfeld widerspiegeln

Hauptaufgabe des EUS-Kerns ist es zwischen den Subsystemen zu vermitteln und Anfragen der Solver sowie der Planungskomponente zu beantworten. Diese Anfragen und auch die Antworten des Systemkerns werden in KometML, einem XML-Dialekt, kodiert.

Abbildung 3: Das Vorgehensmodell
(Klicken Sie ins Bild, um es zu Vergrößern)

Die KOMET-Architektur hat ihren Namen von der Komponenten-Orientierten Methode, die bei deren Entwicklung konsequent angewendet wurde. Ziel einer komponentenorientierten Softwareentwicklungsmethode ist der Aufbau einer Gesamtanwendung aus unabhängigen Einzelteilen, so genannten Software-Komponenten, die zusammenarbeiten. Der Softwareentwicklungsprozess als solches erfolgte in mehreren Phasen, das zugrunde liegende Wasserfallmodell wurde ein wenig abgewandelt, und somit einer komponentenorientierten Softwareentwicklung angepasst (Abbildung 3).

Die Planungsanwendung sowie alle Solver sind echte Softwarekomponenten, da sie über alle Eigenschaften verfügen, die sowohl bei Szypersky (1999) als auch bei Griffel (1998) als Erkennungsmerkmale von Komponenten genannt werden.


Martin Döllerer - zuletzt geändert am 01.01.1970 um 01:00 Uhr