TUDOOR - Ein Java Adapter für Telelogic DOORS Jae-Won Choi, Anna Trögel, Ingo Stürmer Model Engineering Solutions GmbH Abstract: Im Bereich des Requirements Engineering hat sich DOORS der Firma Telelogic als Marktführer durchgesetzt. Externe Applikationen, die auf Funktionalitäten zurückgreifen wollen, die DOORS nicht zur Verfügung stellt, wie z.b. Verlinkung der Anforderungen zu Test- und Modellierungswerkzeuge von Software oder die Verwaltung von DOORS Modulen, mussten bisher die DOORSspezifischen DXL-Scriptsprache oder die C-API von DOORS verwenden. Für Java-Anwendungen wird derzeit keine direkte Unterstützung von DOORS geboten. Daher haben wir TUDOORS entwickelt, eine allgemeine Java Schnittstelle für DOORS, die auf einem DOORS Meta-Modell basiert. Der Beitrag stellt TUDOOR in seiner Gundfunktionalität vor, beschreibt dessen Anwendung, sowie Auszüge aus dem DOORS Meta-Modell und den Prozess der Java Adapter-Generierung. 1 Der Java Adapter TUDOOR Das Werkzeug DOORS der Firma IBM/Telelogic ist de-facto-marktführer im Bereich des Requirements Engineering für Software-Projekte. DOORS wird z.b. zur Definition und Strukturierung von Anforderungen an Software(-Systeme) verwendet. Die darüber hinaus benötigten Funktionalitäten, wie z.b. Dokumentengenerierung, Verlinkung der Anforderungen zu Test- und Modellierungswerkzeuge von Software, kurz: die Anbindung externer Applikationen an DOORS, wird für Java Applikationen nicht direkt unterstützt. DOORS bietet eine C-API und eine Scriptsprache, die DOORS extension Language (DXL) an, die den externen, lesenden und schreibenden Zugriff auf DOORS erlaubt. DXL ist im Vergleich zu gängigen Programmiersprachen, wie Java oder C, eine wenig verbreitete Scriptsprache, die nur von Experten verstanden wird. Die C-API stellt eine sinnvolle Alternative zu DXL dar, ist aber nicht mehr zeitgemäß, da heutzutage Java der de-facto-standard ist, um Anwendungen zu entwickeln. Aus diesem Grund haben wir TUDOOR [MES09] entwickelt, eine generische Java Schnittstelle, die den lesenden und schreibenden Zugriff auf DOORS über Java-Klassen ermöglicht. Der Zugriff auf DOORS über Java-Klassen bietet folgende Vorteile: (1) Man benötigt nur noch Java-Kenntnisse, um mit externen Anwendungen an DOORS anzukoppeln. Dies erlaubt die effiziente und kostengünstige Entwicklung von Add-Ons z.b. zur Analyse und Visualisierung von Anforderungsdokumenten; (2) Die Produktivität der Entwickler steigert sich deutlich, da die Kopplung an DOORS nicht mehr umständlich in einer Skriptsprache implementiert werden muss. Ferner ist eine Ankopplung an Standard-Java-Bibliotheken (z.b. für GUI Visualisierungen) wesentlich einfacher; (3) Die Schnittstelle unterstützt den direkten Zugriff auf Meta-Informationen sowie die Formulierung generischer Algorithmen, die mit Script-Sprachen kaum oder nur sehr schwer realisiert werden können. 189
Das Grundprinzip von TUDOOR bzw. des Java Adapters ist in Abb. 1 gezeigt. Der Adapter besteht aus Java- und DXL-Dateien, die in einem JAR-File bereitgestellt werden. Die Java Dateien enthalten alle Klassen, die zur Anbindung an DOORS benötigt werden. Diese Java-Klassen basieren auf dem DOORS Meta-Modell (siehe Kapitel 2), das alle DOORS Objekte, Daten und Methoden beschreibt. Das JAR-File selbst wird von der externen Java-Applikation verwendet, die auf DOORS zugreifen möchte. Abb.1 Funktionsweise und Kommunikationswege von TUDOOR Die Java-Klassen des Adapters kapseln die DXL Befehle, die für den direkten Zugriff auf DOORS benötigt werden. Da alle verfügbaren DXL Befehle einen zu großen Funktionsumfang für den einzelnen Nutzer ermöglichen, wie z.b. gewolltes bzw. ungewolltes Auslesen oder Löschen von Inhalten, für die keine Berechtigung besteht, stellt der Adapter eine nur lesbare DXL Whitelist bereit, die alle erlaubten DXL Befehle enthält. D.h. der Funktionsumfang ist auf ein sicheres und erlaubtes Subset der DXL Scriptsprache eingeschränkt. 2 DOORS Meta-Modell Dieses Kapitel stellt das in TUDOOR zu Grunde liegende DOORS Meta-Modell vor. Um die Integration und den Austausch von Daten verschiedener Applikationen zu ermöglichen, ist die Verwendung von Standards zum Verwalten von Metadaten praktikabel. Eine einheitliche Repräsentation von Metainformationen sollte dafür sowohl mehrere Abstraktionsebenen von Metadaten, als auch generische, präzise definierte Sprachelemente abbilden können. Eine solche Sprache bietet die von der OMG entworfene Meta Object Facility (MOF) [OMG06], die mit der graphischen Notation von UML erstellt wird. Das DOORS Meta-Modell basiert auf einer formalen Beschreibung von DOORS in Form eines MOF-konformen UML Modells (vgl. Abb. 2). Auf diese Weise kann die Struktur des Werkzeugs auf einer abstrakten Meta-Ebene plattform- und sprachunabhängig beschrieben werden, auch besser bekannt als Platform Independent Model (PIM) aus dem MDA-Bereich. Mit Hilfe des in der MOF-Spezifikation definierten XMI 1 -Formats kann dieses Meta-Modell aus dem jeweiligen Modellierungswerkzeug exportiert und in beliebige andere Formate übertragen werden. Daraus ergibt sich der Vorteil mit dem 1 XMI XML Metadata Interchange (OMG) 190
einmalig erstellten DOORS Meta-Modell Adapter für Anwendungen verschiedener Programmiersprachen entwickeln zu können. Für den in Java implementierten DOORS- Adapter werden mit der vom Java Community Process (JCP) verabschiedeten Spezifikation JMI 2 -konforme Java Schnittstellen generiert. Deren Implementierung und die Instanziierung der Klassen erlaubt das Erzeugen, Verwalten, Ändern und Löschen der Daten in DOORS. Beschrieben wird der Workflow von der Meta-Modell Erstellung bis hin zur Schnittstellengenerierung und Implementierung in Kapitel 3. Abb. 2: Ausschnitt des DOORS Meta-Modells (Datenmodell) Das in Enterprise Architect modellierte Meta-Modell gliedert sich in mehrere Pakete, die verschiedene Funktionalitäten von DOORS widerspiegeln, sowie DOORS Datentypen definieren: (1) DataModel, (2) DisplayControl, (3) BaselineControl, (4) AccessRights, (5) BaseTypes. Im Datenmodell sind alle wesentlichen Elemente der DOORS-Struktur möglichst exakt 3 abgebildet. UML Klassen repräsentieren darin DOORS Elemente, Attribute ihre jeweiligen Eigenschaften und Assoziationen ihre Beziehung zueinander. Abb. 2 zeigt beispielhaft einen Ausschnitt des Datenmodells. Die Klasse DoorsFolder erbt demzufolge die Eigenschaften, wie Name (name) und Beschreibung (description), eines DoorsItems und führt wiederum eine Liste mit Kindelementen vom Typ DoorsItem, wodurch die hierarchische Ordnerstruktur von DOORS abgebildet wird. Jeder DoorsFolder hat zusätzlich eine Liste von DoorsModules. Ein DoorsModule muss von DoorsItem erben. Sowohl 2 JMI Java Metadata Interface (SUN) 3 Im Zweifelsfall erfolgt hier eine Klärung in Zusammenarbeit mit dem DOORS Support. 191
DoorsFolder als auch DoorsProject haben eine Liste von Modulen. Diese Beziehung wird durch die Assoziation FolderProjectHasItems abgebildet. Das Paket Display- Control bildet die Funktionalität der Views 4 ab, die für Formal und Descriptive Module erstellt werden können. Im BaselineControl Paket ist die Möglichkeit Zwischenstände von Modulen zu speichern und im Access Paket die Zugriffsberechtigungen auf DOORS Elemente modelliert. DOORS Objekttypen sind im Paket BaseTypes definiert. 3 Generierung des Java-Adapters Abb. 3: Workflow: Generierung des TUDOOR Java Adapters MOFLON [AKRS08] ist ein in Java entwickeltes Meta-CASE Tool, das im Rahmen des gleichnamigen Forschungsprojekts an der TU Darmstadt, Fachgebiet Echtzeitsysteme, entstanden ist. Das Tool wird derzeit aktiv weiterentwickelt und dient zur Modellierung von MOF-konformen Modellen und deren Transformationen. Es bietet darüber hinaus die Möglichkeit MOF-konforme Modelle, die in anderen Applikationen modelliert wurden, über das XMI-Format zu importieren und durch Transformationen Java-Code zu generieren. Im Falle Java Adapters für DOORS wird mit Hilfe von MOFLON aus dem zuvor in Enterprise Architect erstellten Meta-Modell Java-Code generiert. Der Workflow für die Generierung des Adapters ist in Abb. 3 gezeigt. Zunächst werden die benötigten Funktionalitäten im DOORS EA Meta-Modell hinterlegt. Hierbei wird versucht das Verhalten von DOORS möglichst exakt abzubilden 5. Über das MOFLON Framework werden JMI-konforme Schnittstellen für die Java-Klassen generiert. Anschließend werden Funktionalitäten der Java-Klassen manuell implementiert. 4 Views definieren im DOORS Client unterschiedliche Sichten auf Module. So können in Views unter anderem angegeben werden, welche Attribute eines Moduls sichtbar sein sollen. 5 Im Zweifelsfall erfolgt hier eine Klärung in Zusammenarbeit mit dem DOORS Support. 192
4 Zusammenfassung und Ausblick Die Adaptergenerieurung aus einem Meta-Modell für die Kopplung von Werkzeugen wird zukünftig eine wichtigere Rolle einnehmen. Die Entwicklung von TUDOOR zeigt, dass die modell-getriebene Softwareentwicklung einen Teil der Entwicklungsarbeit abnehmen und dadurch bestimmte Prozesse vereinfachen und weniger fehleranfällig gestalten kann. Durch die Generierung von Schnittstellen und Standardimplementierungen entfallen Routinearbeiten und Flüchtigkeitsfehler in diesen Teilen der Architektur. Dies setzt jedoch ein zuvor korrekt erstelltes Meta-Modell voraus. Der Adapter lässt viel Spielraum für zukünftige Erweiterungen, wie z.b.: (1) Transaktionskonzept: Derzeit werden über die setter-methoden Daten sofort in die DOORS Datenbank geschrieben. Sinnvoll wäre hier ein Transaktionsmechanismus, bei dem der Beginn und das Ende einer solchen Transaktion explizit angegeben werden kann. So wären Rückfalloptionen möglich, falls während einer Transaktion etwas nicht wie gewünscht verläuft oder diese explizit abgebrochen wird; (2) Verschlüsselte Kommunikation: DOORS wird auch für die Verarbeitung sensibler Daten eingesetzt. Daher stellt die verschlüsselte Übertragung der Daten eine wertvolle Ergänzung dar. Hiermit kann sichergestellt werden, dass die Kommunikationswege vor unerlaubten Zugriffen abgesichert werden; (3) Bidirektionale Kommunikation: Eine weitere sinnvolle Ergänzung ist die bidirektionale Kommunikation zwischen dem DOORS Client und dem Adapter. Sie soll es ermöglichen, Veränderungen die über den DOORS Client gemacht werden, direkt an den Adapter zu senden. So wäre sichergestellt, dass die im Adapter geladenen Daten immer aktuell sind, ohne aufwendige Polling-Mechanismen in periodischen Abständen durchführen zu müssen. Literatur [AKRS08] [Daimler08] C. Amelunxen, F. Klar, A. Königs, T. Rötschke, A. Schürr: "Metamodel-based Tool Integration with MOFLON", 30th International Conference on Software Engineering, New York: ACM Press, 05 2008, ACM Press, 807-810. Daimler AG, Evaluierung vorhandener Java-DOORS-Schnittstellen, interner Bericht, Juni 2008. [MES09] Model Engineering Solutions GmbH, TUDOOR, Produktinformation, http://www.model-engineers.com/our-products.html, 2009. [OMG06] Object Management Group. Meta Object Facility (MOF), Core Specification, January 2006. 193