TUDOOR - Ein Java Adapter für Telelogic DOORS
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
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 Funktiona-
litäten zurückgreifen wollen, die DOORS nicht zur Verfügung stellt, wie z.B. Ver-
linkung der Anforderungen zu Test- und Modellierungswerkzeuge von Software
oder die Verwaltung von DOORS Modulen, mussten bisher die DOORS-
spezifischen DXL-Scriptsprache oder die C-API von DOORS verwenden. Für Ja-
va-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 Anbin-
dung externer Applikationen an DOORS, wird für Java Applikationen nicht direkt unter-
stützt. DOORS bietet eine C-API und eine Scriptsprache, die DOORS eXtension Langu-
age (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 Ana-
lyse und Visualisierung von Anforderungsdokumenten; (2) Die Produktivität der Ent-
wickler steigert sich deutlich, da die Kopplung an DOORS nicht mehr umständlich in
einer Skriptsprache implementiert werden muss. Ferner ist eine Ankopplung an Stan-
dard-Java-Bibliotheken (z.B. für GUI Visualisierungen) wesentlich einfacher; (3) Die
Schnittstelle unterstützt den direkten Zugriff auf Meta-Informationen sowie die Formu-
lierung 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 wer-
den. 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 Funk-
tionsumfang 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 Adap-
ter 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 er-
möglichen, ist die Verwendung von Standards zum Verwalten von Metadaten praktika-
bel. Eine einheitliche Repräsentation von Metainformationen sollte dafür sowohl mehre-
re Abstraktionsebenen von Metadaten, als auch generische, präzise definierte Sprach-
elemente abbilden können. Eine solche Sprache bietet die von der OMG entworfene Me-
ta 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än-
gig beschrieben werden, auch besser bekannt als Platform Independent Model (PIM) aus
dem MDA-Bereich. Mit Hilfe des in der MOF-Spezifikation definierten XMI1-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)
190einmalig erstellten DOORS Meta-Modell Adapter für Anwendungen verschiedener Pro-
grammiersprachen entwickeln zu können. Für den in Java implementierten DOORS-
Adapter werden mit der vom Java Community Process (JCP) verabschiedeten Spezifika-
tion JMI2-konforme Java Schnittstellen generiert. Deren Implementierung und die In-
stanziierung der Klassen erlaubt das Erzeugen, Verwalten, Ändern und Löschen der Da-
ten 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 exakt3
abgebildet. UML Klassen repräsentieren darin DOORS Elemente, Attribute ihre jeweili-
gen Eigenschaften und Assoziationen ihre Beziehung zueinander. Abb. 2 zeigt beispiel-
haft 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 hierar-
chische 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.
191DoorsFolder 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 Views4 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 wur-
den, ü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 abzubilden5. Über das MOFLON
Framework werden JMI-konforme Schnittstellen für die Java-Klassen generiert. An-
schließ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.
1924 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 ab-
nehmen und dadurch bestimmte Prozesse vereinfachen und weniger fehleranfällig ges-
talten 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) Transakti-
onskonzept: Derzeit werden über die setter-Methoden Daten sofort in die DOORS Da-
tenbank geschrieben. Sinnvoll wäre hier ein Transaktionsmechanismus, bei dem der Be-
ginn 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 ver-
schlüsselte Übertragung der Daten eine wertvolle Ergänzung dar. Hiermit kann sicherge-
stellt werden, dass die Kommunikationswege vor unerlaubten Zugriffen abgesichert wer-
den; (3) Bidirektionale Kommunikation: Eine weitere sinnvolle Ergänzung ist die bidi-
rektionale 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] C. Amelunxen, F. Klar, A. Königs, T. Rötschke, A. Schürr: "Metamodel-based
Tool Integration with MOFLON", 30th International Conference on Software En-
gineering, New York: ACM Press, 05 2008, ACM Press, 807-810.
[Daimler08] Daimler AG, Evaluierung vorhandener Java-DOORS-Schnittstellen, interner Be-
richt, 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, Janu-
ary 2006.
193Sie können auch lesen
