Dokumentenaustausch nach RIF Standard in DOORS - Alex Besstschastnich Bachelorarbeit
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Dokumentenaustausch nach
RIF Standard in DOORS
Bachelorarbeit
Alex Besstschastnich
Fachbereich Elektrotechnik und Informatik
Betreuer / Prüfer
Prof. Dr. Nikolaus Wulff
Andreas Hensel
Erklärung Hiermit versichere ich, dass ich die vorliegende Arbeit und die zugehörige Implementierung selbstständig verfasst und dabei nur die angegebenen Quellen und Hilfsmittel verwendet habe. Bielefeld, 15.09.06 Alex Besstschastnich
Danksagung An dieser Stelle möchte ich die Gelegenheit nutzen allen zu danken, die mich während meines Studiums und bei der Entstehung dieser Bachelorarbeit in vielfacher Art und Weise unter- stützt haben. Mein besonderer Dank gilt meinen Eltern, ohne deren Verständnis und große Unterstützung mein Studium und diese Arbeit nicht möglich gewesen wären. Herr Prof. Dr. Nikolaus Wulff hat mich während dieser Arbeit betreut und half mir mit ver- schiedenen Anmerkungen. Andreas Hensel hat mich in der Firma Telelogic mit hilfreichen Diskussionen und fachlicher Kritik unterstützt. Beiden möchte ich für Ihre Mühe sehr danken.
Kurzzusammenfassung
Diese Arbeit beschäftigt sich mit dem standardisierten Austauschformat RIF, nachdem Do-
kumente zwischen Datenbanken verschiedener und gleicher Hersteller ausgetauscht werden
sollen. Im Verlauf dieser Arbeit wird das Anforderungsmanagement-Tool DOORS vorgestellt
und ein Konzept für die Umsetzung der RIF Spezifikation in der Datenbank DOORS ausge-
arbeitet. Im Konzept werden mögliche Lösungsansätze und deren Vor- und Nachteile behan-
delt. Die Funktionsweise der OLE-Schnittstelle in DOORS wird erläutert und Teile des Kon-
zepts werden in der Implementierung umgesetzt. Anschließend werden Unstimmigkeiten und
auftretende Probleme bei der Umsetzung erwähnt.
Der Sourcecode und vorhandene Dokumentationen werden nach Fertigstellung dieser Arbeit
der Firma Telelogic zur Verfügung gestellt.
Um mehr Übersichtlichkeit beim Lesen zu verschaffen werden die Regeln der Textformatie-
rung nachfolgend vorgestellt
• Die Grundschriftart ist Times New Roman.
• Sourcecodeabschnitte und XML-Passagen sind in Currier New hervorgehoben.
• Kommentare innerhalb eines Codeabschnitts sind in Currier New und grün mar-
kiert.
• Klassen und Dateinamen werden kursiv gekennzeichnet.
• Verweise auf externe Quellen werden blau und unterstrichen dargestellt.
• Interne Verweise werden nicht extra hervorgehoben.
Inhaltsverzeichnis 1 Einleitung ................................................................................................ 8 2 Anforderungsmanagement-Tool DOORS ........................................... 9 2.1 Einführung...................................................................................................................9 2.2 Die Datenbank .............................................................................................................9 2.3 Formale Module ........................................................................................................11 2.3.1 Objekte und Attribute ................................................................................................12 2.3.2 Attributtypen und Basistypen ....................................................................................13 2.4 DOORS eXtension Language (DXL)........................................................................14 3 Requirements Interchange Format (RIF).......................................... 16 3.1 Einführung.................................................................................................................16 3.2 Use Cases...................................................................................................................17 3.3 Beziehungen zwischen Informationstypen................................................................18 3.4 Modell........................................................................................................................18 3.4.1 Grundstruktur ............................................................................................................18 3.4.2 Klasse Identifiable .....................................................................................................19 3.5 Abbilden der Klassenbeziehungen in XML ..............................................................20 3.5.1 Generelle Regeln .......................................................................................................20 3.5.2 Generalisierung..........................................................................................................21 3.5.3 Komposition ..............................................................................................................22 3.5.4 Assoziation ................................................................................................................23 3.6 XML-Schemas...........................................................................................................24 4 Konzept zur Implementierung............................................................ 25 4.1 Vorbemerkung ...........................................................................................................25 4.2 RIF Identifier .............................................................................................................25 4.2.1 Allgemein ..................................................................................................................25 4.2.2 Funktionen der Identifier ...........................................................................................25 4.2.3 Relevante Elemente für persistente RIF Identifier ....................................................26 4.2.4 Relevante Elemente für nicht persistente RIF Identifier ...........................................26 4.2.5 Schlussfolgerung .......................................................................................................26 4.3 DOORS Features .......................................................................................................27 4.3.1 Basistypen (Base Types) ...........................................................................................27 4.3.2 Attribute.....................................................................................................................27 4.3.2.1 Allgemein ..................................................................................................................27 4.3.2.2 Object Heading und Object Text ...............................................................................27 4.3.2.3 Systemattribute ..........................................................................................................28 4.3.3 Bilder .........................................................................................................................28 4.3.4 OLE Objekte..............................................................................................................29 4.3.5 Tabellen .....................................................................................................................29 4.4 Export/Import nach RIF Standard .............................................................................32 4.4.1 Allgemein ..................................................................................................................32 4.4.2 Erstexport eines Dokuments nach RIF Use Case 3 ...................................................32 4.4.3 Erstimport eines Dokuments nach RIF Use Case 3...................................................32
4.4.4 Export eines Antwortdokuments nach RIF Use Case 4 ............................................33 4.4.5 Import eines Originaldokuments mit Kommentaren nach RIF Use Case 4 ..............33 4.4.6 Export eines aktualisierten Dokuments nach RIF Use Case 5 ..................................34 4.4.7 Import eines aktualisierten Dokuments nach RIF Use Case 5 ..................................34 4.4.8 Import/Export nach RIF Use Case 2 .........................................................................34 4.4.9 Sonstige RIF Use Cases.............................................................................................34 4.5 Benutzerschnittstelle..................................................................................................35 4.5.1 Allgemein ..................................................................................................................35 4.5.2 Export ........................................................................................................................35 4.5.3 Import ........................................................................................................................35 5 OLE-Anbindung mit DXL................................................................... 36 5.1 OleCreateAutoObject()..............................................................................................36 5.2 put() ...........................................................................................................................36 5.3 clear().........................................................................................................................36 5.4 olePut() ......................................................................................................................37 5.5 oleMethod() ...............................................................................................................37 5.6 Beispiele ....................................................................................................................37 5.6.1 Kreierung eines XML Elements ................................................................................37 5.6.2 Text-Eigenschaft eines Elements setzen....................................................................38 5.6.3 Anbinden eines Elements ..........................................................................................38 6 Implementierung .................................................................................. 40 6.1 Einleitung ..................................................................................................................40 6.2 Werkzeuge und Hilfsroutinen....................................................................................41 6.2.1 MSXML Parser 6.0 ...................................................................................................41 6.2.2 GUID Schnittstelle ....................................................................................................41 6.2.3 Datenbank Browser ...................................................................................................42 6.3 Datenfluss zwischen den Komponenten....................................................................43 6.3.1 Erstexport ..................................................................................................................43 6.3.2 Erstimport ..................................................................................................................44 6.4 Abhängigkeiten der Source-Dateien..........................................................................45 6.5 Basisfunktionen .........................................................................................................47 6.5.1 Export ........................................................................................................................47 6.5.2 Import ........................................................................................................................47 6.5.3 Gemeinsame Routinen...............................................................................................48 6.6 Erstexport eines Moduls ............................................................................................49 6.6.1 Ablauf ........................................................................................................................49 6.6.2 Export Dialogbox ......................................................................................................49 6.6.3 Processing Instruction ...............................................................................................51 6.6.4 Wurzelelement RIF....................................................................................................52 6.6.5 Datentypen.................................................................................................................52 6.6.6 Attributdefinitionen ...................................................................................................54 6.6.7 Attributwerte..............................................................................................................55 6.6.8 Objekthierarchie ........................................................................................................56 6.6.9 Identifier ....................................................................................................................56 6.7 Erstimport eines Moduls............................................................................................57 6.7.1 Ablauf ........................................................................................................................57 6.7.2 Import Dialogbox ......................................................................................................58 6.7.3 Initialisierung des MSXML Parsers ..........................................................................59
6.7.4 Modul ........................................................................................................................59 6.7.5 Datentypen und Attributtypen ...................................................................................60 6.7.6 Attributdefinitionen ...................................................................................................61 6.7.7 Attributwerte..............................................................................................................62 6.7.8 Objekthierarchie ........................................................................................................63 6.7.9 Identifier ....................................................................................................................65 6.8 Performance...............................................................................................................67 7 Unstimmigkeiten zwischen RIF Spezifikation und XML-Schema.. 69 7.1 Allgemein ..................................................................................................................69 7.2 Klasse RIF .................................................................................................................69 7.3 Klasse EnumValue ....................................................................................................70 7.4 Assoziation der Klasse AttributeValueEmbeddedDocument....................................70 7.5 Assoziation mit der Klasse DatatypeDefinitionComplex..........................................71 7.6 Klasse SpecHierarchy................................................................................................71 8 Zusammenfassung und Ausblick ........................................................ 72 9 Abbildungsverzeichnis ......................................................................... 73 10 Literaturverzeichnis............................................................................. 74
1 Einleitung
1 Einleitung
Das Anforderungsmanagement [AM] ist eine wichtige Managementaufgabe für fehlerarme
und effiziente Entwicklung komplexer Systeme. Ziel des Anforderungsmanagement ist es, in
Projekten Anforderungen an ein Produkt und deren Komponenten zu managen und struktu-
riert zu beschreiben, dabei sollen Inkonsistenzen zwischen verschiedenen Anforderungen (u-
ser requirements, system requirements) aus verschiedenen Projektphasen (Entwurf, Design,
Test usw.) aufgedeckt und beseitigt werden. In der Planungs- und Analysephase eines Ent-
wicklungsprozesses sollte verstärkt Anforderungsmanagement betrieben werden, um eine
spätere Kostensteigerung durch Fehlkalkulation eines Projekts vorzubeugen. Korrekturen zu
frühen Zeitpunkt vermeiden höhere Kosten zu späteren Projektphasen.
Früher wurden Anforderungen in Papierform erfasst und archiviert. Da die Anforderungen
eines Auftraggebers, z.B. in Form eines Lastenheftes, meist unstrukturiert, unsymmetrisch,
unvollständig und widersprüchlich sind, sind Änderungen in einem Anforderungsdokument
nur schwer einzupflegen. Mit der Computerisierung wurden viele Tools für das Anforde-
rungsmanagement entwickelt, unter anderem das zurzeit marktführende Produkt DOORS1 der
Firma Telelogic. Mit diesen Anforderungsmanagement-Tools (AM-Tools) lassen sich Anfor-
derungen strukturiert in elektronischer Form verwalten. Benutzt ein Auftraggeber und ein
Auftragnehmer das gleiche AM-Tool, so wird zwischen den beiden beteiligten Parteien der
Austausch der Anforderungsdokumente vereinfacht – falls vom AM-Tool unterstützt.
Das AM-Tool DOORS bietet die Möglichkeit ein Dokument zu importieren oder zu exportie-
ren, kann jedoch zwei gleiche Dokumente verschiedener Versionen nicht synchronisieren. Da
DOORS in der Automobilindustrie sehr stark verbreitet ist, hat die Herstellerinitiative Soft-
ware (HIS) vor einigen Jahren die Anforderungen an einen synchronisierten Dokumenten-
austausch ausformuliert und u.a. an die Firma Telelogic herangetragen. Daraufhin entwickelte
Telelogic ein Skript mit der Bezeichnung eXchange, welches als Add-On zur DOORS-
Anwendung eingesetzt werden kann. Inzwischen hat HIS die Anforderungen erweitert und zu
einer Spezifikation zusammengefasst, dem Requirements Interchange Format (RIF). Das
Skript eXchange ist sehr spezifisch auf DOORS zugeschnitten und kann nicht ohne großen
Aufwand auf RIF umgestellt werden.
Ziel dieser Bachelorarbeit ist, die Schnittstelle für den herstellerunabhängigen Austausch von
Dokumenten nach dem RIF Standard weitgehend zu analysieren. Es gilt zu überprüfen, wel-
che Probleme oder Restriktionen mit dem RIF Modell verbunden sind. Eine partikuläre Imp-
lementierung soll die Möglichkeiten des Austausches nach dem RIF Standard veranschauli-
chen und zu einer weiteren Version als Basis dienen. Dabei setzt das RIF Projekt nicht auf das
bereits vorhandene Skript eXchange auf, sondern ist eine Neuimplementierung.
1
Siehe auch http://www.telelogic.de/corp/Products/doors/index.cfm.
8
2 Anforderungsmanagement-Tool DOORS
2 Anforderungsmanagement-Tool DOORS
2.1 Einführung
DOORS2 [DOORS] ist ein weltweit bekanntes und marktführendes Werkzeug der Firma Tele-
logic3 [Tlogic] zum Verwalten von Anforderungen. Mit diesem Werkzeug lassen sich Anfor-
derungen strukturiert beschreiben und übersichtlich bearbeiten. Änderungen der Anfor-
derungen können leicht eingepflegt und zurückverfolgt werden. Referenzen zwischen den
einzelnen Anforderungen sind realisierbar. Mit Hilfe von Baselines lassen sich ältere Zu-
stände eines Moduls speichern. DOORS bietet viele weitere Möglichkeiten, die das Arbeiten
mit formalen Anforderungen für den Benutzer erleichtern auf die hier jedoch nicht weiter ein-
gegangen werden soll, weil diese für den Dokumentenaustausch nach RIF Standard keine
primäre Rolle spielen. In diesem Kapitel werden die wichtigsten Eigenschaften von DOORS
vorgestellt um die Struktur und Arbeitsweise des Werkzeuges verständlich zu machen.
2.2 Die Datenbank
DOORS basiert auf einer Client-Server Architektur und ist eine hierarchische Datenbank, die
absichtlich dem Windows-Look angepasst wurde, um die Bedienbarkeit zu vereinfachen. Ü-
ber ein Anmeldefenster, siehe Abbildung 2-1, muss sich der Benutzer beim Server registrie-
ren. Der Server kann sowohl auf dem lokalen Rechner als auch in einem Netzwerk laufen.
Abbildung 2-1: Anmeldefenster in DOORS
Projekte und Ordner ermöglichen eine Strukturierung der Daten. Die eigentlichen Daten, oder
Anforderungen, werden in Modulen gespeichert. Es gibt in DOORS drei Arten von Modulen,
das Link Module, das Descriptive Module und das Formal Module. Link Modules sind dafür
da, um Referenzen zwischen Objekten, die auch in unterschiedlichen Modulen gespeichert
sein können, zu verwalten und anschaulich darzustellen. Descriptive Modules sind eine Art
Container, wo Daten temporär und unstrukturiert abgelegt werden können. Auf beide soll hier
nicht weiter eingegangen werden. Der Fokus sei auf die Formalen Module gerichtet, weil die-
se die tatsächlichen Daten enthalten. Abbildung 2-2 zeigt die Datenbankansicht in DOORS.
2
Telelogic gewann mit DOORS den Yphise Award 2005, siehe http://www.telelogic.de/campaigns/2005/global-
/doors_yphise_report/index.cfm?campaigncode=000547-002318.
3
Telelogic ist unter den „CBR’s ten most influential companies in application development“, siehe
http://www.cbronline.com/article_cbr.asp?guid=D1099CB2-5A30-492C-9EBE-24E87771123C.
9
2 Anforderungsmanagement-Tool DOORS
Abbildung 2-2: Datenbankansicht in DOORS
Abbildung 2-3 verdeutlicht den hierarchischen Aufbau der DOORS Datenbank. In der blan-
ken Datenbank ist es nur möglich einen Ordner (Folder) oder ein Projekt (Project) zu kreieren,
wobei ein Projekt nur ein spezieller Ordner ist und sich nur in der Implementierung von einem
Ordner unterscheidet. Sowohl ein Ordner als auch ein Projekt können verschiedene Module
enthalten. Das Formale Modul enthält eine beliebige Anzahl von Objekten, die wiederum aus
mehreren Attributen zusammengesetzt sind. Ein Attribut ist von einem benutzerdefinierten
oder systemdefinierten Attributtyp. Eine Attributdefinition wird auf eine der sieben DOORS
Basistypen abgebildet.
102 Anforderungsmanagement-Tool DOORS
DOORS
Database
Folder Project
Descriptive
Link Module Formal Module
Module
Linksets Object ...
Attribute
Attribute type
DOORS base
type
String Real Integer
Enumerati
Username Date Text
on
Abbildung 2-3: Hierarchischer Aufbau der DOORS Datenbank
2.3 Formale Module
Formale Module beinhalten die eigentlichen Daten. Ein Projekt wird meistens in mehrere
Module aufgeteilt, wobei sich jedes Modul auf ein bestimmtes Thema bezieht. Die Informa-
tion innerhalb eines Moduls wird in Objekte und Attribute aufgeteilt. Abbildung 2-4 zeigt die
vorgegebene Ansicht (Default View) eines Moduls. Eine Ansicht erlaubt es unerwünschte
112 Anforderungsmanagement-Tool DOORS
Attribute eines Moduls zu verstecken und nur die anzuzeigen, die für einen Benutzer relevant
sind.
Abbildung 2-4: Default View eines Formalen Moduls
In dem rechten Ausschnitt des Fensters stellen die Spalten die Attribute und die Zeilen die
Objekte dar. In dem linken Ausschnitt sieht man die hierarchische Strukturierung der Objekte
eines Moduls.
2.3.1 Objekte und Attribute
Attribute werden in zwei Arten unterteilt, die Systemattribute, die bei jeder Kreierung eines
neuen Moduls immer vorhanden sind, und die benutzerdefinierten Attribute. Systemattribute
sind nicht löschbar und teilweise auch nicht änderbar, wie z.B. das Attribut ID in der
Abbildung 2-4, das eine absolute Nummer eines Objekts darstellt. Dieses Attribut wird von
DOORS gefüllt und identifiziert jedes Objekt innerhalb eines Moduls eindeutig. Weitere von
DOORS vorgegebene Attribute sind z. B. Created By oder Modified On. In der Abbildung 2-4
ist Objekttyp ein benutzerdefiniertes Attribut, das die Werte Anforderung und leeres Feld an-
nehmen kann.
Im Vergleich zu normalen Spalten setzt sich die Hauptspalte aus zwei Attributen zusammen,
das Attribut Object Heading und Object Text. Die Hauptspalte kann entweder das Attribut
Object Heading oder das Attribut Object Text gleichzeitig darstellen.
Das Attribut Object Heading stellt die Überschrift eines Absatzes dar und wird durch eine
größere und fettere Schrift gekennzeichnet. Object Heading besitzt zudem noch eine automa-
122 Anforderungsmanagement-Tool DOORS
tische heading number, die die Objektstruktur kenntlich macht. Die heading number ändert
sich automatisch, wenn die Struktur der Objekte, z.B. durch verschieben, löschen oder erstel-
len, verändert wird. Das Attribut Object Text beinhaltet den konkreten Text und wird in der
Standard Schrift dargestellt.
Ein Objekt besteht entweder aus dem Attribut Object Heading, oder dem Attribut Object Text,
und die dazugehörigen vorgegebenen oder benutzerdefinierten Attribute. Jedes Objekt besitzt
eine Absolute Nummer und kann innerhalb eines Moduls eindeutig identifiziert werden.
2.3.2 Attributtypen und Basistypen
DOORS stellt insgesamt sieben Basistypen zur Verfügung: Integer, Real, String, Enumera-
tion, User Name, Date und Text. Einen Basistyp Boolean gibt es in DOORS nicht, stattdessen
wird ein Attributtyp Boolean vom Basistyp Enumeration definiert, der die Werte true und
false annehmen kann. Eigene Definitionen von Attributtypen sind durch Verwendung oder
Manipulation der Basistypen möglich. In der Abbildung 2-4 ist z.B. das Attribut Priorität
vom benutzerdefiniertem Typ Priorität, der Attributtyp Priorität wiederum ist vom Basistyp
Enumeration. Die identische Namensgebung des Attributtyps und Attributnamen hängt damit
zusammen, dass der Attributtyp Priorität für genau ein Attribut vorgesehen ist.
Abbildung 2-5 zeigt die Attributtypen und Basistypen eines Moduls in DOORS. Der Basistyp
und dessen eindeutige Benennung definieren einen Attributtypen.
Abbildung 2-5: Attributtypen und Basistypen in DOORS
132 Anforderungsmanagement-Tool DOORS
Die Attributdefinitionen eines Moduls, zu sehen in der Abbildung 2-6, leiten sich von den in
der Abbildung 2-5 definierten Attributtypen ab. Ein Attribut kann für ein Objekt, für das gan-
ze Modul, oder für beide zusammen existieren. Weitere Eigenschaften eines Attributs sind
default value, multi valued und inherit value (geerbter Wert).
Abbildung 2-6: Attributdefinitionen und Attributtypen in DOORS
2.4 DOORS eXtension Language (DXL)
DOORS eXtension Language, nachfolgend auch DXL genannt, ist eine Skriptsprache, die
speziell für DOORS entwickelt wurde. DXL wird in vielen Teilen von DOORS verwendet,
um Hauptmerkmale, wie Import oder Export von Dateiformaten, Rückverfolgung Analyse
(traceability analysis) oder Modulwerkzeuge, zur Verfügung zu stellen. Die DXL-Schnitt-
stelle ist eine Erweiterung zur graphischen Benutzerschnittstelle, über die dem Benutzer, der
seine eigenen Skripte schreibt, die Möglichkeit gegeben wird, die DOORS Umgebung zu
erweitern und individuell anzupassen.
DXL ist mehr für den technischen Benutzer gedacht, der Programme für die Endbenutzer
schreibt, die dann als Add-On zur DOORS Anwendung eingepflegt werden können. Die Syn-
tax von DXL ist ähnlich der aus der Programmiersprache C oder C++ und selbst viele Basis-
funktionen stimmen überein, deswegen wird an dieser Stelle die Syntax4 von DXL nicht ex-
plizit vorgestellt. Auf einzelne Spezialisierungen wird in den einzelnen Beispielen einge-
gangen. DXL ist keine typisierte Skriptsprache.
4
Semikolon am Zeilenende sind nicht zwingend notwendig, aber erlaubt.
142 Anforderungsmanagement-Tool DOORS
DOORS bietet keinen Compiler, Debugger oder Editor mit Syntaxhervorhebung, sondern
lediglich ein Formular mit dem man DXL Skripte editieren und ausführen kann. Über ein
Ausgabefenster werden Fehler oder Warnungen ausgegeben. Abbildung 2-7 zeigt ein DXL-
Formular mit einem Codeausschnitt.
Abbildung 2-7: DXL Eingabeformular
Um das Arbeiten mit DXL angenehmer zu gestalten, wurde der Editor UltraEdit5 [UE] ver-
wendet, der als Shareware frei im Internet verfügbar ist. Dieser erlaubt es über eine Konfi-
gurationsdatei (wordfile.txt) eigene Wörter oder Wortgruppen für die Syntaxhervorhebung zu
definieren. Solch eine Konfigurationsdatei war bereits vorhanden und musste nur dem Editor
bekannt gemacht werden, um die Syntaxhervorhebung für DXL zu aktivieren.
5
Gewann 2005 die Auszeichnung für „Best Application for Shareware Industry Conference“.
153 Requirements Interchange Format (RIF)
3 Requirements Interchange Format (RIF)
3.1 Einführung
RIF [RIF] ist ein standardisiertes Austauschformat für Anforderungen, deren Initiative in der
deutschen Automobilindustrie startete. Die Herstellerinitiative Software (HIS) [HIS] ist ein
Zusammenschluss der fünf deutschen Automobilhersteller Audi, BMW, Daimler-Chrysler,
Porsche und Volkswagen. Mit dem zunehmenden Einsatz von Anforderungsmanagement-
Tools (AM-Tools) wird die Notwendigkeit zum toolunabhängigen Austausch von Anforde-
rungen immer größer. Im Jahre 2005 hat die HIS die Anforderungen an ein einheitliches An-
forderungsformat in Form einer Spezifikation mit UML [UML] ausgearbeitet und veröffent-
licht. Ziel des einheitlichen und herstellerübergreifenden Austauschformats ist es, den Auf-
wand beim ständigen Austausch von Anforderungen zwischen Automobilhersteller und den
vielen Zulieferern, zu verringern und die Anwendungsmöglichkeiten der Austauschformate zu
erweitern.
Abbildung 3-1: RIF Einsatzweise6
Abbildung 3-1 zeigt die gewünschte Einsatzweise des einheitlichen Austauschformats. Vor-
aussetzung für das Funktionieren des toolunabhängigen Dokumentenaustausches ist die Ko-
operationsbereitschaft der Tool-Hersteller7, die die RIF-Schnittstelle eigenständig implemen-
tieren müssen.
Das Requirements Interchange Format basiert auf der XML-Formalisierung [XML], somit ist
es möglich die RIF-Datei gegen ein XML-Schema, welches ebenfalls zu der RIF Spezifika-
tion vorhanden ist, zu validieren.
6
Quelle: RIF Spezifikation
7
Es ist auch für jeden Benutzer von DOORS möglich über die DXL Schnittstelle eine eigene RIF Lösung zu
implementieren und eventuell zu verkaufen.
163 Requirements Interchange Format (RIF)
Nachfolgend wird das RIF Modell zusammengefasst vorgestellt. Alle Informationen über das
RIF Modell sind in der Spezifikation wieder zu finden. Die UML Diagramme in diesem Ka-
pitel wurden der RIF Spezifikation entnommen.
3.2 Use Cases
Die Anwendungsfälle, die mit dem RIF Standard unterstützt werden sollen, wurden von der
HIS und deren Partner ermittelt und zusammengestellt. Der zweite Anwendungsfall wird we-
gen seiner Komplexität in drei Unterpunkte aufgeteilt. Für detaillierte Beschreibung der An-
wendungsfälle siehe Kap. 2 Use Cases Supported by RIF in der RIF Spezifikation.
UC-1 Externe Kreierung einer Spezifikation. Es muss möglich sein eine komplette Spezifi-
kation, die von einem externen Partner erstellt wurde, in das eigene AM-Tool zu la-
den. Dem Erzeuger der Spezifikation soll dabei freigestellt sein, ob er ein AM-Tool
einsetzt oder nicht. Ziel ist es, dass die extern erstellte Spezifikation erfolgreich in die
Datenbank des Beauftragten (Kunden) importiert werden kann.
UC-2 Austausch einer Spezifikation zwischen Kunden und Lieferanten (Lasten-
/Pflichtenheftaustauschprozess). Der Kunde schickt seine Anforderungen an mehrere
Lieferanten. Die Lieferanten kommentieren die Kundenanforderungen und erstellen
anhand dieser die Systemanforderungen mit eventuellen Verlinkungen zwischen den
Kunden- und Systemanforderungen. Der Lieferant schickt die kommentierten Kun-
denanforderungen und die entsprechenden Systemanforderungen an den Kunden zu-
rück. Sowohl bei den Kundenanforderungen als auch bei den Systemanforderungen
muss es sich nicht unbedingt um neue Dokumente handeln, es können auch Ergänzun-
gen oder Aktualisierungen sein.
UC-3 Senden einer ersten Version einer Spezifikation, oder Teile einer Spezifikation, an
einen oder mehrere Partner.
UC-4 Senden einer Antwort zu einer vorher verschickten Spezifikation. Partner1 schickt
eine Spezifikation an Partner2. Partner2 importiert die Spezifikation und antwortet auf
diese in Form von Kommentaren und/oder einer neuen Antwortspezifikation mit Refe-
renzen zwischen der Originalspezifikation und der Antwortspezifikation. Zum Schluss
hat Partner1 die Antwort aller Partner in seinem AM-Tool.
UC-5 Senden einer aktualisierten Version einer Spezifikation an einen Partner. Partner1
schickt eine Aktualisierung der Spezifikation an Partner2. Beim Import der aktuali-
sierten Version in die AM-Tool-Datenbank des Partner2 müssen Änderungen zwi-
schen der älteren und aktualisierten Version der Spezifikation sichtbar gemacht wer-
den.
AF-6 Externe Überprüfung (review) einer Spezifikation. Der Kunde schickt eine Spezifika-
tion an einen oder mehrere Überprüfer. Die Überprüfer kommentieren die Spezifika-
tion und schicken diese zurück an den Kunden. Der Kunde importiert die Kommentare
der einzelnen Überprüfer. Die Kommentare aller Überprüfer zu den entsprechenden
Anforderungen sind in der Datenbank des Kunden sichtbar.
173 Requirements Interchange Format (RIF)
UC-7 Korrigieren einer Spezifikation durch einen Korrektor. Ein Kunde sendet eine Spezifi-
kation an einen Korrektor. Der Korrektor ändert die Spezifikation und sendet die kor-
rigierte Version der Spezifikation an den Kunden zurück. Der Kunde hat nach dem
Import der korrigierten Version die Möglichkeit beide Versionen abzugleichen.
3.3 Beziehungen zwischen Informationstypen
In dem RIF Modell werden insgesamt drei Beziehungstypen nach UML Standard zwischen
Informationstypen verwendet:
• Aggregation
Informationstyp1 (IT1) beinhaltet IT2, oder IT2 ist Teil von IT1.
+ roleName
IT1 * IT2
• Generalisierung
IT2 erbt alle Eigenschaften, d.h. Attribute und Beziehungen, von IT1.
IT1 IT2
• Assoziation
IT1 assoziiert IT2. Assoziationen sind immer einseitig. IT1 enthält eine Referenz
auf IT2.
+ roleName
IT1 1 IT2
3.4 Modell
3.4.1 Grundstruktur
Das Klassendiagramm in der Abbildung 3-2 veranschaulicht die RIF Grundstruktur. Der In-
formationstyp RIF ist der Rumpf einer RIF-Datei. Innerhalb dieser RIF-Datei gibt es immer
nur eine Instanz der Klasse RIF. Das Attribut checksum, welches inzwischen in identifier um-
benannt wurde, beinhaltet eine eindeutige Id, anhand dieser ein Dokument eindeutig identifi-
ziert werden kann. Nachfolgend seien die wichtigsten Klassen, die Teil der RIF Klasse sind,
erläutert. Die in den Klassen verwendete Abkürzung Spec steht für Specification.
183 Requirements Interchange Format (RIF)
Abbildung 3-2: UML Diagramm des RIF Modells
AccesPolicy: Erlaubt die Vergabe von Zugriffsrechten auf Informationselemente. Einge-
schränkte Zugriffsrechte werden benötigt, wenn z. B. bestimmte Anforderungen während des
Austauschvorgangs nicht verändert werden dürfen.
DatatypeDefinition: Abstrakte Superklasse für drei konkrete Arten von Datentypen simple,
komplexe und Aufzählungsdatentypen. Simple Datentypen sind Integer, String, Real und
Boolean. Komplexe Datentypen sind DatatypeDefinitionXmlData, DatatypeDefinitionBina-
ryFile und DatatypeDefinitionEmbeddedDocument. Ein Aufzählungsdatentyp (enumeration
type) hat vordefinierte Werte, die er annehmen kann.
SpecType: Beinhaltet die Definitionen aller Attribute in einem Modul, die innerhalb der RIF-
Datei verwendet werden.
SpecObject: Enthält die Werte der in SpecType definierten Attribute.
SpecRelation: Speichert Referenzen zwischen SpecObject’s.
SpecGroup: Fasst mehrere SpecObject’s zu einer Gruppe zusammen.
SpecHierarchyRoot: Wurzel einer Objekthierarchie eines Moduls (SpecType).
3.4.2 Klasse Identifiable
Jedes Informationselement innerhalb der RIF-Datei, das von anderen Informationselementen
referenzierbar sein soll, erbt von der Klasse Identifiable in der Abbildung 3-3. Das Attribut
identifier beinhaltet eine eindeutige Id, über die ein Informationselement angesprochen wer-
den kann.
193 Requirements Interchange Format (RIF)
Abbildung 3-3: Klasse Identifiable
3.5 Abbilden der Klassenbeziehungen in XML
3.5.1 Generelle Regeln
Jeder konkrete Informationstyp im RIF Modell wird auf ein XML Element abgebildet. Der
Name des XML Elements besteht ausschließlich aus Großbuchstaben. Bei zusammengesetz-
ten Namen im RIF Modell werden diese in XML durch ein Bindestrich („-“) getrennt.
Beispiel 1:
SpecObject
Der RIF Informationstyp SpecObject wird auf ein XML Element mit dem Namen SPEC-
OBJECT abgebildet.
…
203 Requirements Interchange Format (RIF)
Beispiel 2:
RIF
+ identifier
+ title
+ comment
+ author
+ version
+ countryCode
+ creationTime
+ sourceToolId
Die Attribute eines Informationstyps werden als Unterelemente in XML abgebildet. Die Wer-
te der Attribute werden innerhalb der verschachtelten Elemente gespeichert.
…
…
…
…
…
…
…
…
…
3.5.2 Generalisierung
Im RIF Modell erbt die Klasse SpecObject von der abstrakten Klasse SpecElementWithUser-
DefinedAttributes, die wiederum von der Klasse Identifiable erbt. In den eckigen Klammern
stehen die Multiplizitäten der Attribute. Die standardmäßige Multiplizität ist 1, optional kön-
nen Attribute auch andere Multiplizitäten haben z.B. [0…1]. Das Attribut desc darf in diesem
Fall weggelassen, oder höchstens ein Mal aufgeführt werden.
213 Requirements Interchange Format (RIF)
Beispiel:
Identifiable
+ identifier : String
+ longName : String[0 .. 1]
+ desc : String[0 .. 1]
+ lastChange : DateTime
SpecElementWithUserDefinedAttributes
SpecObject
Es werden nur die konkreten Klassen des RIF Modells auf ein XML Element abgebildet. Die
Klasse SpecObject enthält alle Attribute der Klassen SpecElementWithUserDefinedAttributes
und Identifiable.
…
…
…3 Requirements Interchange Format (RIF)
Die Klasse EmbeddedValue ist Teil der Klasse EnumValue.
…
…
…
…
Bei Aggregationen mit einer Multiplizität größer eins, wird die aggregierte Klasse in mehre-
ren XML Elementen hintereinander aufgelistet. Die vielfachen Instanzen werden in ein XML
Element, das den Namen des Rollennamen der Aggregation trägt, verschachtelt.
Beispiel 2:
DatatypeDefinitionEnumeration
* {ordered} + specifiedValues
EnumValue
Die Klasse EnumValue wird im XML Element SPECIFIED-VALUES verschachtelt.
…
…
…
…
…
3.5.4 Assoziation
Assoziationen werden in XML mit Hilfe der eindeutigen ID’s realisiert. Jedes Informations-
element, das identifizierbar oder referenzierbar sein soll, erbt von der abstrakten Klasse Iden-
tifiable und somit auch das Attribut identifier. Der Wert des Attributs identifier identifiziert
ein Informationselement eindeutig.
233 Requirements Interchange Format (RIF)
Beilspiel:
SpecGroup
1.. *
* + specObjects
SpecObject
Eine Instanz des Informationstyps SpecGroup verweist auf Instanzen des Informationstyps
SpecObject.
…
…
…
…
…
…
3.6 XML-Schemas
Ein XML-Schema [XMLSchem] ist eine komplexe Sprache zur Beschreibung eines XML-
Typsystems8. Im Vergleich zu DTD’s [DTD] werden durch XML-Schemas mehr Eigenschaf-
ten geboten, XML-Dokumente zu definieren [XSDvsDTD]. Das Validieren eines Dokumen-
tes nach einem bestimmten Schema ist jedoch aufwendiger und bedarf eines Zusatzwerk-
zeugs. Zweck eines Schemas ist es, eine Klasse von XML-Dokumenten zu definieren.
In der RIF Spezifikation sind zwei XML-Schemas [RIFSchem] enthalten, die als Vorlage für
die Entwickler dienen sollen. Unter http://www.automotive-his.de/his-ergebnisse.htm können
beide Schemas rif.xsd und rif-xhtml.xsd heruntergeladen werden.
Das RIF-Schema (rif.xsd) beschreibt alle Datentypen und die Struktur einer RIF Austausch-
datei. Innerhalb einer RIF-Datei ist es möglich zwischen den RIF-Namensraum und XHTML-
Namensraum zu wechseln. Dies erlaubt es ein Dokument nach zwei Schemas, das RIF- und
XHTML-Schema, zu validieren. Das XHTML-Schema (rif-xhtml.xsd) basiert auf der
XHTML Spezifikation Version 1.1. Die temporäre Umschaltung von der RIF-Namensgebung
zur XHTML-Namensgebung, ermöglicht es die Formatierung eines Textes, z.B. den Inhalt9
des DOORS Attributs Object Text, in der RIF-Datei zu übertragen.
8
Definition aus www.wikipedia.de
9
Der Inhalt des Attributs Object Text wird in der DOORS Datenbank im Rich Text Format abgespeichert.
244 Konzept zur Implementierung
4 Konzept zur Implementierung
4.1 Vorbemerkung
Vor der Implementierung der RIF-Schnittstelle in DOORS wurde ein Konzept erstellt, das auf
die wichtigsten Merkmale eines Dokumentenaustausches nach RIF Standard eingeht. Im
Konzept werden mehrere mögliche Varianten zur Umsetzung einer konkreten Anforderung
behandelt. Vor- und Nachteile einer Lösung werden genannt und die Entscheidung für einen
Lösungsweg begründet. Damit soll ein Überblick über eventuelle Restriktionen in der Um-
setzung und die Umsetzmöglichkeiten verschafft werden.
Dieses Konzept dient als Grundlage für die Implementierung der RIF-Schnittstelle in DOORS
und geht über die aktuelle Implementierung hinaus.
4.2 RIF Identifier
4.2.1 Allgemein
Aus der RIF Struktur wird ersichtlich, dass für jedes Informationselement in der RIF-Datei
eine "Identifier" vergeben werden muss. Dies betrifft auch Elemente wie z.B. Datentypen,
Attributtypen, Attributwerte, Objekte etc. (Siehe RIF Spezifikation 3.2.1.1 Identifiable). Alle
Identifier sind "lifetime identifiers" und müssen bei den Austauschvorgängen für ein und das-
selbe Informationselement nicht mehr geändert werden.
Das Generieren von Identifiern für die RIF-Datei stellt kein Problem dar, viel wichtiger dabei
ist folgende Fragen zu beantworten:
• Welchen Zweck dienen welche Identifier?
• Welche Identifier müssen tatsächlich gespeichert werden?
• Wie müssen/können diese Identifier (in DOORS) gespeichert werden?
• Wann müssen die Identifier generiert und gespeichert werden?
Die Identifier werden nach dem Konzept von "Globally Unique Identifier" kreiert. Die GUID
ist 16 Byte (128 Bit) lang. Eine Schnittstelle zwischen DOORS DXL und der Windows API
zum Generieren der GUID in DXL wurde bereits von Telelogic im Kundenauftrag realisiert
und wurde für die RIF-Implementierung wieder verwendet.
4.2.2 Funktionen der Identifier
Eine Identifier muss nicht nur innerhalb einer RIF-Datei eindeutig sein, sondern auch inner-
halb aller zuvor erstellten RIF-Dateien. Alle Identifier sind "lifetime identifiers", müssen also
nicht von einem AM-Tool, das das Dokument importiert und später reexportiert, geändert
werden. Sie dienen für Referenzen von einem Informationselement zum anderen Informati-
onselement innerhalb einer RIF-Datei und zum eindeutigen Identifizieren eines Informations-
elements. Die Eindeutigkeit der Identifier ermöglicht den Vergleich eines exportierten und
254 Konzept zur Implementierung
reimportierten Elements, somit wird eine Änderung oder eine Kreierung eines Informations-
elements beim Reimport erkannt. Ein Vergleich zweier Elemente anhand einer ID ist immer
in den RIF Use Cases 2, 4, 5, 6 erforderlich.
4.2.3 Relevante Elemente für persistente RIF Identifier
Um einen Vergleich eines exportierten Moduls mit einem reimportierten Modul zu ermögli-
chen, müssen alle Elemente, die während des Austauschvorgangs modifiziert werden können,
eine persistente Identifier beinhalten. Modifizierbare Elemente in Bezug auf die in der RIF-
Datei übertragenen Zugriffsrechte sind z.B.: Attributwerte, Object Text, Object Heading.
DOORS Systemattribute, die in DOORS nur als read-only verfügbar sind, aber in einem Part-
nertool als benutzerdefinierte Attribute mit Schreibrechten abgelegt werden. Das Modul sel-
ber muss ebenfalls identifizierbar sein, da es nach der RIF Spezifikation auch möglich sein
soll mehrere Module in einer RIF-Datei zu übertragen.
4.2.4 Relevante Elemente für nicht persistente RIF Identifier
Bei Datentypdefinitionen oder Attributtypen ist es nicht zwingend erforderlich deren ID's zu
speichern, weil dort eine Modifikation ausgeschlossen sein sollte. Eine Änderung eines Attri-
buttypen z.B., würde den ganzen Datenaustausch inkonsistent machen und sollte unterbunden
werden. Auch wenn die ID's von Datentypen nicht gespeichert werden, ist es immer noch
möglich aus der RIF-Datei heraus zwei Datentypen auf Gleichheit zu überprüfen. Identifier,
die nur innerhalb der RIF-Datei Sinn machen, müssen nicht persistent sein. Diese sind z.B.
Referenzen innerhalb der RIF-Datei.
Genauer: Wird in der RIF-Datei z.B. ein Datentyp Integer definiert, so verweisen alle folgen-
den Attribute, die vom Typ Integer sind, auf diesen Datentyp. Da der Datentyp aber keinen
konkreten Wert beinhaltet, ist es unnötig seine Identifier zu speichern.
Andersherum aber müssen diese Identifier zumindest temporär gespeichert werden, damit
eine Verlinkung beim Generieren der RIF-Datei überhaupt möglich ist.
4.2.5 Schlussfolgerung
Es werden alle Id's gespeichert, die entweder mehr als einmal während des Austauschvor-
gangs benötigt werden, oder als Assoziation zwischen den RIF Daten und den DOORS Daten
dienen, z.B. die DOORS Absolute Number eines Objekts mit der ID eines Objekts aus der
RIF-Datei. Diese Identifier werden vorerst in eine Skip Liste gespeichert, um den Zugriff zu
vereinfachen.
Eine Skip Liste ist ein dynamischer assoziativer Container für string-Werte in DXL. Die Id's
sind die Werte der Skip Liste. Um die Schlüssel der Skip Liste eindeutig zu machen, besteht
jeder Schlüssel aus einem Präfix und einen Namen. Das Präfix ist eine Abkürzung für den
Informationstyp, für welchen die Identifier verwendet wird. Der Name steht für den Namen
des Informationstyps. Am Ende eines Austauschvorgangs stehen alle Id's in der Skip Liste.
Die Skip Liste wird mit allen Id's in eine Textdatei übertragen ohne zu überprüfen, welche
Identifier für die Wiederverwendung relevant sind und welche nicht.
264 Konzept zur Implementierung
4.3 DOORS Features
4.3.1 Basistypen (Base Types)
Das RIF unterstützt nicht alle DOORS Basistypen, somit müssen einige der DOORS Basisty-
pen auf die RIF Datentypen, möglichst ohne Verluste, abgebildet werden. Nachfolgende Ta-
belle verschafft einen Überblick über das Mapping von DOORS Basistypen auf RIF Datenty-
pen.
DOORS base types RIF data types
Integer DatatypeDefinitionInteger
Real DatatypeDefinitionReal
String DatatyptDefinitionString
Unter Vorbehalt! Der Text eines Attributs vom Typ String
lässt sich in DOORS immer noch formatieren (z.B. italic,
bold, etc.). Dies ist jedoch nicht in der RIF-Datei möglich.
Enumeration DatatypeDefinitionEnumeration
Date DatatypeDefinitionString
Im RIF gibt es keinen Datentyp Date. Alle DOORS Attribute
vom Basistyp Date werden in der RIF-Datei auf den Daten-
typ String abgebildet.
Text DatatypeDefinitionEmbeddedDocument
Die Richtext-Formatierung aus DOORS wird in der RIF-
Datei mit XHTML realisiert.
User name DatatypeDefinitionString
Einen Datentyp User name gibt im RIF nicht. Alle DOORS
Attribute vom Typ User name werden im RIF auf den Typ
String abgebildet.
4.3.2 Attribute
4.3.2.1 Allgemein
Beim Exportieren eines Dokuments werden alle Attribute (Systemattribute, benutzerdefinierte
Attribute) gleich gehandhabt. Über RIF Access policy kann man auf Systemattribute einge-
schränkte Zugriffsrechte vergeben.
4.3.2.2 Object Heading und Object Text
Beim Import eines Dokuments, das ebenfalls von DOORS kreiert wurde, können Object Hea-
ding und Object Text 1:1 gemappt werden, weil die Namen der Attribute in DOORS mit de-
nen in der RIF-Datei übereinstimmen. Beim Import eines Dokuments aus einer anderen Tool-
familie muss überprüft werden, welche Attribute aus der Fremddatenbank auf die Attribute
Object Heading und Object Text abgebildet werden können.
Beispiel: Direkte Abbildung der Attribute anderer AM-Tools auf die DOORS Attribute Ob-
ject Heading und Object Text und umgekehrt (siehe RIF Appendix C: Mapping Table).
274 Konzept zur Implementierung
DOORSTM IRqATM CaliberTM
Object Heading Name Requirement Type
Object Text Description Requirement Description
Es muss eine Liste aller Namen gleicher Attribute verschiedener AM-Tools geführt werden,
um möglichst viele Attribute direkt abbilden zu können.
4.3.2.3 Systemattribute
Beim Import können Systemattribute nicht 1:1 gemappt werden, weil diese in DOORS nicht
vom Benutzer änderbar sind. Um trotzdem die Daten der Systemattribute importieren zu kön-
nen, werden benutzerdefinierte Attribute, mit dem Namen der Systemattribute und einem Prä-
fix, angelegt.
4.3.3 Bilder
Es gibt zwei Methoden Bilder in einer RIF-Datei zu übertragen. Die erste Methode ist, die
Bilder außerhalb der RIF-Datei zu speichern und mit Hilfe eines
Elements auf das Bild verweisen. Innerhalb des Elements befinden
sich keine Daten. Die zweite Methode ist, die Bilder in der Base64 Codierung direkt in die
RIF-Datei einzubinden. Dabei werden die Base64 codierten Daten innerhalb des Elements
gespeichert.
Vorteil der zweiten Methode ist, dass alle Daten in einer Datei gespeichert werden und somit
die Wahrscheinlichkeit, dass die Daten verlustfrei übertragen werden, größer ist. Der Nachteil
zeigt sich bei großen Bildern, oder großen Menge an Bildern, da steigt die Größe der RIF-
Datei stark an und die RIF-Datei wird sehr unübersichtlich.
Die erste Methode hat den Vorteil, dass die RIF-Datei klein und übersichtlich gehalten wird.
Der Nachteil ist jedoch, dass die Daten getrennt abgespeichert werden und beim Verschicken
gepackt werden müssen um einen verlustfreien Austausch zu gewährleisten.
Da eine RIF-Datei mit mehreren Tausend Objekten schnell eine Größe von mehreren Mega
Bytes erreicht, macht es Sinn RIF-Dateien generell zu packen10, bevor sie verschickt werden,
dazu kommt noch, dass DOORS keine Möglichkeit bietet ein Bild in einer Base64 Codierung
auszugeben. Es müsste eine externe Applikation z.B. über die OLE-Schnittstelle gesteuert
werden, um ein Bild nach der Base64 Codierung auszugeben. Somit werden Bilder generell
extern gespeichert und anschließend mit der RIF-Datei in ein ZIP Dateiformat gepackt.
Zum Exportieren von Bildern steht in DOORS folgende Routine zur Verfügung
string exportPicture(Object obj,
string fileName,
int format),
mit der sich Bilder in das Format PNG11 exportieren lassen. Die Routine
10
Siehe RIF Spezifikation Kapitel 4.3 Packaging.
11
Portable Network Graphics Format
284 Konzept zur Implementierung
bool importPicture(string pictureName,
string fileName,
string format)
dient zum Importieren eines Bildes vom Typ BMP, DIB, EPSF und UNKNOWN.
4.3.4 OLE Objekte
Das Exportieren von OLE Objekten in eine RIF-Datei ist in DOORS nicht ohne Restriktionen
oder großen Aufwand möglich. OLE Objekte werden im Rich Text Format (RTF) in DOORS
gespeichert. In der eXchange Lösung wird der ganze Rich Text String mit den enthaltenen
OLE Objektinformationen eines Attributs von einer DOORS Datenbank in eine andere
DOORS Datenbank übertragen, ohne einzelne Informationen der OLE Objekte herauszufil-
tern. Für die Lösung nach dem RIF Standard ist diese Idee ungeeignet, weil mit einem Rich
Text String die Importdatenbank ggf. nichts anfangen kann und die Methode nicht der RIF
Spezifikation entspricht.
Die Schwierigkeit bei OLE Objekten ist, dass ein OLE Objekt nicht automatisch mit einer
Datei assoziiert und somit nicht einfach aus DOORS exportiert werden kann. Das RTF spei-
chert jedoch den Namen der Anwendung, die gestartet wird, wenn ein OLE Objekt geöffnet
werden soll, über die eine Dateiendung generiert werden kann.
Eine Möglichkeit ist es OLE Objekte in Bilder umzuwandeln und in das PNG-Format zu ex-
portieren, der Zweck eines OLE Objekts erlischt jedoch in der Importdatenbank. Eine weitere
Möglichkeit ist es den Rich Text String mit dem enthaltenen OLE Objekt zu segmentieren
und die benötigten Daten in eine Datei mit einer entsprechenden Endung zu speichern.
Der Import eines OLE Objekts kann im Vergleich zum Export mit einer Routine
bool oleInsert(Object o,string fileName)
durchgeführt werden. fileName ist der vollständige Pfad einer Datei, die als OLE Objekt im
DOORS Objekt o eingefügt wird.
4.3.5 Tabellen
Tabellen werden in DOORS wie Objekte behandelt, dabei ist jede Zelle ein einzelnes Objekt.
Abbildung 4-1 zeigt ein Auszug eines Moduls mit einer Tabelle. Auf der linken Seite ist die
hierarchische Struktur der Objekte zusehen und auf der rechten Seite die Objekte mit den At-
tributen ID, Object Level und das Hauptattribut (Object Heading bzw. Objekt Text). Nach der
Struktur folgt die Tabelle unmittelbar nach dem Objekt mit der ID 15 und ist auch auf dersel-
ben Ebene wie das vorherige Objekt. Die Zellen der Tabelle befinden sich jedoch zwei Ebe-
nen unterhalb der Ebene des Tabellenkopfes. In der Abbildung 4-1 sind die Zellen der Tabelle
auf der fünften hierarchischen Ebene.
294 Konzept zur Implementierung
Abbildung 4-1: Auszug eines Moduls mit einer Tabelle
Abbildung 4-2 veranschaulicht den hierarchischen Aufbau einer Tabelle. Das Table Header
Objekt ist die Wurzel einer Tabelle. Unterhalb des Table Header Objekts folgen die Row Ob-
jekte und unterhalb der Row Objekte folgen erst die eigentlichen Zellenobjekte, die auch den
Inhalt der Tabelle repräsentieren. Die Objekte Table Header und Row werden nicht in der
Datenbank aufgeführt, verursachen aber trotzdem ein zweifache Unterstufung der Zellenob-
jekte.
Module
Object (ID 1)
Object (ID 9) Object (ID 10)
Object (ID 15) Table header Object (ID 14) Object (ID 16) Object (ID 17)
Row 1 Row 2 Row 3
Cell 1_1 Cell 1_2 Cell 2_1 Cell 2_2 Cell 3_1 Cell 3_2
Abbildung 4-2: Hierarchischer Aufbau einer Tabelle
Bei den Tabellen ist es wichtig, dass die vorhandenen Daten in den Zellen in andere AM-
Tools eingepflegt werden können und noch wichtiger ist, dass eine Tabelle beim Importieren
in eine DOORS Datenbank rekonstruiert werden kann. Der folgende Gedanke zum Abbilden
der DOORS Tabellen basiert auf dem Vorschlag aus der Mapping Tabelle der RIF Spezifika-
tion.
30Sie können auch lesen
