Erklärung - fh-muenster.de€¦ · DOORS bietet viele weitere Möglichkeiten, die das Arbeiten mit formalen Anforderungen für den Benutzer erleichtern auf die hier jedoch nicht

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

8

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.

http://www.telelogic.de/corp/Products/doors/index.cfm

2 Anforderungsmanagement-Tool DOORS

9


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.

http://www.telelogic.de/campaigns/2005/global�/doors_yphise_report/index.cfm?campaigncode=000547-002318

http://www.telelogic.de/campaigns/2005/global�/doors_yphise_report/index.cfm?campaigncode=000547-002318

http://www.cbronline.com/article_cbr.asp?guid=D1099CB2-5A30-492C-9EBE-24E87771123C

http://www.cbronline.com/article_cbr.asp?guid=D1099CB2-5A30-492C-9EBE-24E87771123C


10

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.


11

DOORSDatabase

ProjectFolder

Formal ModuleDescriptive

ModuleLink Module

Linksets Object ...

Attribute

Attribute type

DOORS basetype

String IntegerReal

TextDateUsernameEnumerati

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


12

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-


13

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


14

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.


15

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“.

3 Requirements Interchange Format (RIF)

16


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.


17

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.

http://www.automotive-his.de/download/Requirements_Interchange_Format_V_1_0a.pdf



18

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.

IT1

IT2 + roleName

*

+ roleName

*

• 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.

IT1

IT2 + roleName

1

+ roleName

1

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.


19

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.


20

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.

<SPEC-OBJECT> … </SPEC-OBJECT>


21

Beispiel 2:

Die Attribute eines Informationstyps werden als Unterelemente in XML abgebildet. Die Wer-te der Attribute werden innerhalb der verschachtelten Elemente gespeichert.

<RIF> <IDENTIFIER> … </IDENTIFIER> <TITLE> … </TITLE> <COMMENT> … </COMMENT> <AUTHOR> … </AUTHOR> <VERSION> … </VERSION> <COUNTRY-CODE> … </COUNTRY-CODE> <CREATION-TIME> … </CREATION-TIME> <SOURCE-TOOL-ID> … </SOURCE-TOOL-ID> … </RIF>

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.

RIF

+ identifier + title+ comment + author + version+ countryCode + creationTime + sourceToolId


22

Beispiel:

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.

<SPEC-OBJECT> <IDENTIFIER> … </IDENTIFIER> <LONG-NAME> … </LONG-NAME> <DESC> … </DESC> <LAST-CHANGE … </LAST-CHANGE> …

</SPEC-OBJECT>

3.5.3 Komposition

Aggregierte Klassen werden in verschachtelte XML Elemente abgebildet. Ist die Multiplizität einer Komposition gleich eins, wird die aggregierte Klasse wie ein Attribut behandelt. Beispiel 1:

Identifiable

+ identifier : String + longName : String [0 .. 1]+ desc : String [0 .. 1]+ lastChange : DateTime

SpecElementWithUserDefinedAttributes

SpecObject

EnumValue

EmbeddedValue

+ key : int + otherContent : String

+ properties 1

+ properties 1


23

Die Klasse EmbeddedValue ist Teil der Klasse EnumValue.

<ENUM-VALUE> … <PROPERTIES>

<KEY> … </KEY> <OTHER-CONTENT> … </OTHER-CONTENT>

</PROPERTIES> …

</ENUM-VALUE>

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:

Die Klasse EnumValue wird im XML Element SPECIFIED-VALUES verschachtelt.

<DATATYPE-DEFINITION-ENUMERATION> … <SPECIFIED-VALUES>

<ENUM-VALUE> … </ENUM-VALUE> <ENUM-VALUE> … </ENUM-VALUE> <ENUM-VALUE> … </ENUM-VALUE>

</SPECIFIED-VALUES> …

</DATATYPE-DEFINITION-ENUMERATION>

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.

DatatypeDefinitionEnumeration

EnumValue

+ specifiedValues * { ordered }

+ specifiedValues * { ordered }


24

Beilspiel:

Eine Instanz des Informationstyps SpecGroup verweist auf Instanzen des Informationstyps SpecObject. <SPEC-GROUP> … <SPEC-OBJECTS> <SPEC-OBJECT-REF> … </SPEC-OBJECT-REF> <SPEC-OBJECT-REF> … </SPEC-OBJECT-REF> <SPEC-OBJECT-REF> … </SPEC-OBJECT-REF> … </SPEC-OBJECTS> … </SPEC-GROUP>

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.

SpecGroup

SpecObject

1 .. *

+ specObjects *

1 .. *

*

http://www.automotive-his.de/his-ergebnisse.htm

4 Konzept zur Implementierung

25


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


26

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.


27

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).


28

DOORSTM IRqA TM 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 <RIF-XHTML:OBJECT> Elements auf das Bild verweisen. Innerhalb des Elements <RIF-XHTML:OBJECT> 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 <RIF-XHTML:OBJECT> 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


29

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.


30

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.

Object (ID 1)

Object (ID 9)

Object (ID 15) Object (ID 14)

Object (ID 10)

Object (ID 16) Object (ID 17)Table header

Row 2

Cell 1_1 Cell 1_2

Row 1

Cell 2_1 Cell 2_2

Row 3

Cell 3_1 Cell 3_2

Module

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.


31

Nach dem RIF Modell befinden sich alle Objekte (SpecObjects) innerhalb des Informations-elements SpecType und jede Hierarchie (SpecHierarchyRoot) bezieht sich auf ein SpecType Informationselement. Um die Datenkonsistenz zu gewährleisten und ein korrektes Mapping zu ermöglichen werden die gewöhnlichen Objekte und die Objekte einer Tabelle getrennt. Abbildung 4-3 veranschaulicht die Funktionsweise des Mappings von DOORS Tabellen, das Beispiel bezieht sich auf das Modul in der Abbildung 4-1.

1 | header 1

9 | header 1.1

15 | requirement 1

2 | DOORS_TABLE

14 | requirement 2

10 | header 1.2

17 | requirement 4

2 | DOORS_TABLE

4 | cell 1_1

5 | cell 1_2

6 | Row 2

3 | Row 1

7 | cell 2_1

8 | cell 2_2

11 | Row 2

12 | cell 3_1

13 | cell 3_2

SpecType 1 SpecType 2

SpecRelation

Abbildung 4-3: Beispiel zum Mapping von DOORS Tabellen

Alle Objekte mit Ausnahme der Tabellen werden in der RIF-Datei innerhalb der Klasse Spec-Type gespeichert und haben eine eigene Hierarchiedefinition (SpecHierarchyRoot). Die Ta-bellenobjekte (Table header, row, cell) werden in eine weitere Instanz der Klasse SpecType gespeichert. Tritt beim Exportieren der Objekte eines Moduls eine Tabelle auf, wird diese durch ein „normales“ Objekt, das mit einer besonderen Konvention gekennzeichnet werden muss, ersetzt. Das gekennzeichnete Objekt verweist dann auf den Kopf der Tabelle in der zweiten SpecType Klasse. Somit ist gewährleistet, dass ein AM-Tool, welches keine Tabellen unterstützt, trotzdem die Daten entnehmen und zugleich eine DOORS Datenbank beim Import, die Tabelle rekon-struieren kann.


32

4.4 Export/Import nach RIF Standard

4.4.1 Allgemein

Der Export/Import setzt eine vorhandene Installation von MSXML Parser 6.012 voraus. Es ist eine Schnittstelle zwischen DXL und dem MSXML Parser 6.0 erforderlich. Beim Export wird die Struktur der RIF-Datei mit Hilfe des MSXML Parsers 6.0 erstellt. Beim Import wird die Struktur der RIF-Datei mit Hilfe des MSXML Parsers 6.0 ausgelesen.

4.4.2 Erstexport eines Dokuments nach RIF Use Case 3

Das AM-Tool, das dieses Dokument exportiert, ist zugleich der Erzeuger des Dokuments. Der formatierte Text (z.B. im Attribut Object Heading oder Object Text) in DOORS muss in ein entsprechendes XHTML Format transformiert werden. Z.B. werden alle Überschriften des ersten Levels, in der RIF-Datei mit dem Tag <rif-xhtml:h1> umklammert. Formatierung wie bold, italic, underline, strikethru, subscript und superscript sind mit XHTML realisierbar. Ablauf:

• Initialisiere XML-Datei und XML-Parser • übertrage DOORS Basistypen (RIF: DatatypeDefinition) • übertrage Attributdefinitionen (RIF: SpecTypes) • fülle Attribute mit Werten (RIF: SpecObject) • übertrage Objekthierarchie (RIF: SpecHierarchyRoot) • definiere Objektgruppen (RIF: SpecGroups) • übertrage Objektreferenzen (RIF: SpecRelations) • übertrage Zugriffsrechte (RIF: AccessPolicies)

Alle Identifier müssen neu generiert werden.

4.4.3 Erstimport eines Dokuments nach RIF Use Case 3

Das AM-Tool, das das Dokument importiert, ist nicht der Erzeuger des Dokuments. Das im-portierte Dokument wird in einem neuen Modul in der Datenbank gespeichert. Es wird also kein Abgleich zwischen dem importierten Modul und einem älteren, bereits in der Datenbank vorhandenen Modul, durchgeführt. Voraussetzung für das Erstellen eines neuen Moduls sind entsprechende Zugriffsrechte in der Ziel-Datenbank. Beim Importieren eines DOORS Doku-ments können die Attribute der Import-Datei in die Attribute der DOORS Datenbank 1:1 ge-mappt werden. Bei einer RIF-Datei, die nicht von DOORS erstellt wurde, muss beim Import überprüft werden, welche Attribute 1:1 in die DOORS Datenbank gemappt werden können und welche als benutzerdefinierte Attribute gespeichert werden. Dazu müsste man sich mit den Attributen der anderen AM-Tools auseinandersetzen, weil z.B. einige Attribute zweier AM-Tools zwar denselben Nutzen, aber andere Bezeichnungen haben können. Attribute, die nicht 1:1 gemappt werden können, bekommen in der Import Datenbank ein Präfix mit dem Namen der Export Datenbank vorangestellt. Ablauf:

12 Erhältlich unter www.microsoft.com.

http://www.microsoft.com/

http://www.microsoft.com/


33

• erstelle neues Modul (bzw. neue Module) in DOORS • ergänze, falls nötig, DOORS Basistypen um weitere benutzerdefinierte Datentyp-

definitionen • erstelle Objekte in DOORS und fülle die entsprechenden Attribute • setze in der RIF-Datei definierte Zugriffsrechte • erstelle Objektstruktur • erstelle Referenzen zwischen Objekten

Alle Identifier werden aus der RIF-Datei entnommen.

4.4.4 Export eines Antwortdokuments nach RIF Use Case 4

Das AM-Tool, welches das Dokument exportiert, ist nicht der Erzeuger des Dokuments. Ab-sicht dabei ist das Dokument samt Änderungen an das Erzeugertool zurückzuschicken. Inhalt der Attribute des Erzeugers darf nicht geändert werden. Anhängen von Attributen an das Ori-ginaldokument ist möglich. Es ist auch möglich ein neues Dokument, das mit dem Original-dokument verlinkt ist, als Antwortdokument zurückzuschicken. Dieser Austauschvorgang würde dem RIF Use Case 3 ähneln. Bereits vorhandene Id's, die beim Import des Originaldo-kuments gespeichert worden sind, müssen weiterverwendet werden. Ergänzende Informati-onselemente bekommen eine neue Id zugewiesen. Ablauf:

• siehe 4.4.2 Erstexport eines Dokuments nach RIF Use Case 3 Abweichungen:

• benutzt werden bereits generierte Id für vorhandene Informationselemente • für neue Elemente werden neue Id's generiert

4.4.5 Import eines Originaldokuments mit Kommentaren nach RIF Use Case 4

Der Importeur in diesem Fall ist der Erzeuger des Originaldokuments. Kommentare und/oder neue Attribute müssen in dem Originaldokument ergänzt werden ohne die ursprünglichen Daten zu modifizieren. Ein Vergleich des Originaldokumentes mit dem kommentierten Do-kument anhand der RIF Identifier muss vorgenommen werden. Id's von zugefügten Informa-tionselementen müssen gespeichert werden. Ablauf:

• siehe 4.4.3 Erstimport eines Dokuments nach RIF Use Case 3 Abweichungen:

• es wird kein neues Modul erstellt • überprüfe ob Informationselement bereits vorhanden ist


34

• wenn ja, überprüfe den Inhalt der Informationselemente auf Gleichheit und warne Benutzer, wenn die Originalspezifikation geändert wurde. Änderungen an der Ori-ginalspezifikation werden nicht übernommen.

• wenn nein, behandele Informationselement wie beim Erstimport

4.4.6 Export eines aktualisierten Dokuments nach RIF Use Case 5

Es muss immer das ganze Dokument und nicht nur die geänderten Werte exportiert werden. Ablauf:

• siehe 4.4.4 Export eines Antwortdokuments nach RIF Use Case 4 Abweichungen:

• siehe 4.4.4 Export eines Antwortdokuments nach RIF Use Case 4

4.4.7 Import eines aktualisierten Dokuments nach RIF Use Case 5

Das aktualisierte Dokument muss mit der vorherigen Fassung des Dokumentes abgeglichen werden. Änderungen in der Originalspezifikation sind erlaubt. Ablauf:

• siehe 4.4.3 Erstimport eines Dokuments nach RIF Use Case 3 Abweichungen:

• es wird kein neues Modul erstellt • überprüfe ob Informationselement bereits vorhanden ist • wenn ja, vergleiche den Inhalt der beiden Informationselemente und nehme ggf.

eine Änderung vor • wenn nein, behandele Informationselement wie beim Erstimport

4.4.8 Import/Export nach RIF Use Case 2

Untergeordnete Use Cases: 3,4,5. Es soll ein Lasten/Pflichtenheftaustauschprozess unterstützt werden. Die untergeordneten Use Cases erschließen das Use Case 2.

4.4.9 Sonstige RIF Use Cases

Nach RIF Use Case 6 sollen Kommentare von mehreren Kritikern im RM-Tool des Erzeugers angezeigt werden. Dies wird durch das RIF Use Case 4 erschlagen. RIF Use Case 7 wird durch die Use Cases 3 und 5 ermöglicht.


35

4.5 Benutzerschnittstelle

4.5.1 Allgemein

Der Benutzer muss eine Möglichkeit haben über das Menü die Export- oder Importfunktionen aufrufen zu können. Ein Wizard begleitet den Benutzer während des Austauschvorgangs. Ü-ber den Wizard muss vorerst festgestellt werden, um welche Art von Dokumentenaustausch es sich handelt (Erstexport, Erstimport, Reexport, Reimport).

4.5.2 Export

Der Benutzer kann folgende Einstellungen vornehmen:

• Auswahl eines Moduls oder Auswahl mehrerer Module über einen Datenbank-explorer

• Angabe des Zielpfads der RIF-Datei • Angabe des Pfads der Datei mit den Id's • Auswahl der Attribute, welche exportiert werden sollen • RIF spezifische Angaben, z.B. Autor der RIF-Datei, Version, Titel, Kommentar

etc. • Bei einem Reexport muss der Benutzer den Pfad der vorhandenen Datei mit den

Id's angeben

4.5.3 Import

Folgende Eigenschaften soll der Benutzer einstellen können:

• Auswahl eines Pfades für das neue Modul in der Datenbank über einen Datenban-kexplorer

• Auswahl der RIF-Datei • Auswahl des Pfades für die Id-Datei • Bei einem Reimport muss ein vorhandenes Modul ausgewählt werden, welches

mit dem aus der RIF-Datei abgeglichen werden soll

5 OLE-Anbindung mit DXL

36


DXL unterstützt das von Microsoft entwickeltes Objektsystem Object Linking and Embed-ding (OLE) [OLE]. Die OLE-Schnittstelle in DXL erlaubt es u.a. auf den MSXML Parser zuzugreifen. Nachfolgend werden die wichtigsten Funktionen und deren Anwendung vorge-stellt.

5.1 OleCreateAutoObject()

Prototyp: OleAutoObj oleCreateAutoObject(string autoObjName)

Öffnet eine Verbindung zum Automation Interface. autoObjName beinhaltet den Namen des OLE-Objektes. Über den Rückgabewert vom Typ OleAutoObj werden die Eigenschaften des OLE-Objektes zugänglich und Methoden können aufgerufen werden. Die Anwendung, die die Schnittstelle zum Objekt unterstützt, wird gestartet.

5.2 put()

Prototyp: void put( OleAutoArgs autoArgs, [string argName,] {string|int|char|bool|OleAutoObj} value )

Speichert den Wert der Variable value in die Variable autoArgs . Optional kann in argName der Name der Variable value übergeben werden. autoArgs ist ein Argumentenblock, der mehrere Werte verschiedener Typen gleichzeitig speichern kann.

5.3 clear()

Prototyp: void clear(OleAutoArgs autoArgs)

Leert den Inhalt des Argumentenblocks autoArgs .


37

5.4 olePut()

Prototyp: string olePut( OleAutoObj autoObj, string propertyName, {string|int|char|bool|OleAutoObj} newValue )

Setzt am OLE-Objekt autoObj die Eigenschaft mit dem Namen aus propertyName und den Wert aus newValue .

5.5 oleMethod()

Prototyp: string oleMethod( OleAutoObj autoObj, string methodName [,OleAutoArgs autoArgs [,{string|int|char|bool|OleAutoObj} result]] )

Ruft am OLE-Objekt autoObj eine Methode mit dem Namen aus methodName auf. Optional kann ein Argumentenblock autoArgs übergeben und der Rückgabewert von einem entspre-chenden Typ festgelegt werden. Bei Erfolg ist der Rückgabewert NULL und bei Fehler ein String mit der Fehlerbeschreibung.

5.6 Beispiele

Wie die OLE Routinen oben deutlich machen, bedarf es in DXL einiger Vorarbeit um diese korrekt aufrufen zu können. Die folgenden Beispiele sollen das Prinzip der OLE Schnittstelle in DXL anhand der MSXML API verdeutlichen.

5.6.1 Kreierung eines XML Elements

/* Schnittstelle zum XML Dokument */ OleAutoObj xmlDoc = oleCreateAutoObject(MSXML_INTE RFACE) /* globaler Argumentenblock wird initialisiert */ OleAutoArgs args = create OleAutoObj createElement(string elementName) {

OleAutoObj newElement = null string sError = ""

/* Erstellen eines XML Elements mit vorgegebenen E lementnamen */ /* Zuerst muss der globale Argumentenblock zurückg esetzt werden */

clear(args)

/* Setzen des Argumentenblocks mit entsprechenden Argumenten */


38

put(args, elementName)

/* Aufruf der MSXML Methode createElement() mit de m Argumentenblock. * newElement dient als Speicher für den Rückgabew ert. */

sError = oleMethod(xmlDoc, "createElement", args, n ewElement) if( sError != "" || null(newElement) ){ /* Error handling */ } return newElement

}

Die Funktion createElement() kreiert ein neues XML Element und liefert dieses als Rück-gabewert. Nach der Ausführung dieser Routine wird in der XML-Datei noch keine Ausgabe zu finden sein. Der Aufruf OleAutoObj newElement = createElement("NEW-ELEMENT ")

Erstellt das XML-Element <NEW-ELEMENT />

das aber keiner konkreten Position im Dokument zugewiesen ist – „Es hängt in der Luft“.

5.6.2 Text-Eigenschaft eines Elements setzen

/* Globale Variablen */ … void setTextProperty(OleAutoObj element, string sTe xt) { string sError = "" /* Setze Eigenschaft "text" des Elements "element" */ sError = olePut(element, "text", sText) if( sError != "" ){ /* Error handling */ } }

Die Routine setTextProperty() setzt die Text-Eigenschaft eines übergebenen Elements. Der Aufruf setTextProperty(newElement, "Text eines Elements")

mit dem XML-Element newElement aus dem vorherigen Beispiel (5.6.1), bewirkt folgende Manipulation <NEW-ELEMENT>Text eines Elements</NEW-ELEMENT>.

5.6.3 Anbinden eines Elements

/* Globale Variablen */ … void appendElement(OleAutoObj parent, OleAutoObj el ement) { string sError = ""


39

clear(args) put(args, element) /* Das Element "element" wird als Unterelement zu "parent" * angehängt */ sError = oleMethod(parent, "appendChild", args) if( sError != "" ){ /* Error handling */ } }

Nach der erfolgreichen Ausführung dieser Routine appendElement(parentElement, newElement)

wird das Element newElement , aus den vorherigen Beispielen, an das Elternelement parent-

Element angehängt und in das Dokument geschrieben. Die Ausgabe sieht wie folgt aus: <PARENT-ELEMENT> <NEW-ELEMENT>Text eines Elements</NEW-ELEMENT> </PARENT-ELEMENT>

6 Implementierung

40

6 Implementierung

6.1 Einleitung

Die Implementierung basiert auf dem in Kapitel 4 besprochenen Konzept. Der Dokumenten-austausch nach RIF Standard ist nicht vollständig entwickelt und beinhaltet nicht alle vorge-sehenen Features. Es wurden grundlegende Funktionen implementiert, die als Basis für die Weiterentwicklung dienen sollen. Die Import- und Exportroutine sind über die Menüleiste des Datenbankfensters aufrufbar, siehe Abbildung 6-1.

Abbildung 6-1: Import/Export als Untermenü in der Datenbank

Unterstützte Anwendungsfälle:

• Externe Kreierung einer Spezifikation nach RIF Use Case 1 • Senden einer ersten Version einer Spezifikation nach RIF Use Case 3 • Importieren einer ersten Version einer Spezifikation nach RIF Use Case 3

In den nachfolgenden Unterpunkten wird auf den Umfang der Implementierung in Detail ein-gegangen.

6 Implementierung

41

6.2 Werkzeuge und Hilfsroutinen

6.2.1 MSXML Parser 6.0

MSXML13 [MSXML], auch bekannt als Microsoft Core Services, ist eine COM basierte API zum Parsen und Verarbeiten von XML Dokumenten. Die aktuelle Version der frei verfügba-ren Software von Microsoft ist 6.0 und stellt Implementierungen der folgenden Komponenten bereit:

• XML 1.0 (DOM u. SAX2 API’s) • XML Schema (XSD) 1.0 • XPath 1.0 • XSLT 1.0

Für die Implementierung der RIF Schnittstelle werden nur die ersten drei Komponenten des MSXML Parsers verwendet. Um XML 1.0 und das XML Schema verwenden zu können muss zuerst eine Schnittstelle zwischen der MSXML API und DXL kreiert werden. OleAutoObj xmlDoc = oleCreateAutoObject("Msxml2.DO MDocument.6.0") OleAutoObj schemaCache = oleCreateAutoObject("Msxml 2.XMLSchemaCache.6.0")

Über die OLE-Objekte xmlDoc und schemaCache lassen sich Methoden der XML 1.0 und XML-Schema API aufrufen und deren Eigenschaften bestimmen. XPath 1.0 [XPATH] wird benötigt um Adressteile einer XML Datei direkt anspringen zu kön-nen, dies hat zur Folge, dass Iterationen über Elemente eingespart werden und die Ausführung des Codes sich positiv auf die Laufzeit auswirkt. Um XPath 1.0 verwenden zu können muss die Eigenschaft SelectionLanguage des Parsers auf XPath gesetzt werden.

6.2.2 GUID Schnittstelle

Eine Globally Unique Identifier14 (GUID) wurde von Microsoft auf dem Standard der Univer-sally Unique Identifier15 (UUID) implementiert. Die UUID ist eine global eindeutige Zahl, die aus 128 Bit besteht. Obwohl die Eindeutigkeit der generierten UUID’s nicht garantiert werden kann, geht die Wahrscheinlichkeit, dass gleiche UUID’s generiert werden, mit 2128 gesamt möglichen eindeutigen Schlüssel gegen null. Eine UUID wird in fünf Gruppen unterteilt. Beispiel UUID: E5310177-2B3B-4F19-AEB6-3A56F2A451EF

13 Erhältlich unter www.microsoft.com/downloads. 14 Siehe Literaturverzeichnis unter [GUID] 15 Siehe Literaturverzeichnis unter [UUID]

http://www.microsoft.com/downloads

6 Implementierung

42

Aufbau einer UUID: UUID = time-low(4) "-" time-mid(2) "-" time-high-an d-version(2) "-" clock-seq-and-reserved(1) clock-seq-low(1) "-" no de(6)

Der Zeitstempel ist 60 Bit groß und wird im 100-Nanosekunden Intervall seit dem Beginn des Gregorianischen Kalenders angegeben. In Klammern stehende Werte repräsentieren die Grö-ße der Gruppe in Bytes. Erläuterung der fünf Gruppen: time-low: untere Bits des Zeitstempels time-mid: mittlere Bits des Zeitstempels time-high-and-version: obere Bits des Zeitstempels (12 Bit) und Version-

nummer (4 Bit) clock-seq-and-reserved: Obere Bits der Clock Sequen ce (6 Bit) und 2 reser-

vierte Bits clock-seq-low: Untere Bits der Clock Sequence node: Eindeutiger Identifizierer des erzeugten Node s,

beispielsweise die MAC-Adresse

Für ein früheres Telelogic Projekt wurde bereits eine Schnittstelle für DXL entwickelt, die es ermöglicht die GUID API unter Windows zu nutzen. Die Schnittstelle muss vorerst installiert werden. Wie der MSXML Parser wird auch die GUID API über ein OLE-Objekt in DXL ein-gebunden. exportGuid = oleCreateAutoObject("CreateGuid.DOORS Interface")

6.2.3 Datenbank Browser

Der Datenbank Browser, siehe Abbildung 6-2, gibt die Struktur der Datenbank in einer Dia-logbox wieder, über die der Benutzer Ordner, Projekte und Module selektieren kann. Über einen Knopf können verschiedene Routinen des Datenbank Browsers angestoßen werden, u.a. eine Routine zum Auswerten der selektierten Objekte. Die Implementierung des Datenbank Browsers befindet sich in der Datei DbBrowser.inc, die in die RIF-Implementierung einge-bunden wird. Im Dokumentenaustausch nach dem RIF Standard dient der Datenbank Browser als Schnittstelle für den Benutzer zur Auswahl eines Moduls in der DOORS Datenbank.

6 Implementierung

43

Abbildung 6-2: Datenbank Browser

6.3 Datenfluss zwischen den Komponenten

6.3.1 Erstexport

Abbildung 6-3 verdeutlicht den Datenfluss zwischen den einzelnen Komponenten beim Erst-exportvorgang. Der Benutzer, der das Skript in DOORS ausführt, braucht Lesezugriff auf die Daten (Modul) in DOORS. Der GUID Generator liefert die GUID’s für die Informations-typen. Mit einem schreibenden Zugriff auf die MSXML API werden die Daten aus der DOORS Datenbank in den MSXML DOM Baum [DOM] übertragen. Nach dem alle Daten vollständig übertragen wurden, wird der DOM Baum in eine XML Datei und alle generierten GUID’s in eine Textdatei gespeichert. Die neu generierte XML Datei ist das RIF Dokument.

6 Implementierung

44

GUID SaveFile RIF Export Script

DOORS Database

Serialize the DOM tree toan XML document

Save GUID's

Read Access

RIFDocument Parser

MSXML API

Treebuilding

GUID Generator

Generate GUID

DOM Tree

Root Element

Element 1

Element 2

...

...

Write Access

Abbildung 6-3: Datenfluss zwischen den Komponenten beim Erstexport

6.3.2 Erstimport

In der Abbildung 6-4 ist der Datenfluss zwischen den Komponenten beim Erstimportvorgang zu sehen. Die Komponente GUID Generator entfällt beim Erstimport, weil alle GUID’s aus der RIF-Datei entnommen werden. Das Import Skript leitet das Einlesen der RIF-Datei in den MSXML Parser ein. Der Parser generiert den DOM Baum der RIF-Datei. Das Import Skript greift mit einem lesenden Zugriff auf die MSXML API zu und liest iterativ die Daten aus dem DOM Baum und speichert diese mit einem schreibenden Zugriff in die DOORS Datenbank. Am Ende des Erstimports sind die Daten aus dem RIF Dokument in der DOORS Datenbank und die GUID’s der Informationstypen in einer Textdatei gespeichert.

6 Implementierung

45

GUID SaveFile

Parser

MSXML API

RIF Import Script

DOORS Database

Treebuilding

Save GUID's

Write Access

RIFDocument Parsing

DOM Tree

Root Element

Element 1

Element 2

...

...

Read Access

Abbildung 6-4: Datenfluss zwischen den Komponenten beim Erstimport

6.4 Abhängigkeiten der Source-Dateien

Mit der Skriptsprache DXL ist es, wie im Kapitel 2.4 besprochen, nicht möglich eigene Typen und Klassen zu definieren. Umso schwieriger war es eine ordentliche und wieder verwend-bare Struktur zwischen den einzelnen Komponenten beizubehalten. In der Abbildung 6-5 sind die Abhängigkeiten der einzelnen Source-Dateien dargestellt. Die implementierten Funktio-nen wurden nach Anwendungsebenen sortiert und in einzelne Dateien ausgelagert. Alle Funktionen, die von außerhalb aufgerufen werden, sind mit einem Präfix in dem Funkti-onsnamen versehen. In der Abbildung 6-5 ist das Präfix der Funktionen innerhalb einer Datei hinter dem Doppelpunkt aufgelistet. Das kleine e im Präfix steht für Export und das kleine i für Import. Die zwei Hauptdateien sind Export.dxl und Import.dxl. Sie beinhalten die Anwenderschnitt-stelle zu dem Export- und Importvorgang. Die Include-Dateien sind auf drei Pakete (Ordner) aufgeteilt den Export-, Import- und Miscellaneous-Ordner. Innerhalb der Export- und Import-Ordner gibt es eine weitere Unterteilung der Dateien. Der Ordner XML-Schemas beinhaltet das RIF-Schema und das XHTML-Schema, die zum Validieren der Dokumente in den Parser geladen werden. Dateien mit der Endung *.dxl können in DOORS als add-on eingebunden werden und die Dateien mit der Endung *.inc sind Include-Dateien und können von anderen Dateien heraus eingebunden werden.

6 Implementierung

46

Innerhalb des Export- und Import-Ordners stellt die Datei mit dem Präfix DOM Funktionen zu Verfügung, die auf der Ebene der DOM-Struktur angewendet werden. Diese Funktionen bieten eine allgemeine Schnittstelle zu dem XML-Parser und sind eine Basis für weitere Funktionen. Dateien mit dem Präfix RIF enthalten Funktionen, die eine Ebene über der DOM-Struktur arbeiten. Sie benutzen die DOM-Funktionen um RIF spezifische Daten zu erzeugen. DOORS als Präfix in einem Dateinamen bedeutet, diese Datei enthält Funktionen, die DOORS spezifische Daten auf die RIF-Struktur abbilden. In Constants.inc sind globale Variablen und Konstanten definiert. TagList.inc enthält alle RIF spezifischen Tag-Namen und in Miscellaneous.inc stehen allgemeine Funktionen, die entwe-der sowohl beim Export als auch beim Import benötigt werden, oder keinem anderen Paket zuzuordnen sind.

MiscellaneousXML-Schemas

ImportExport

Export.dxl : EXP Import.dxl : IMP

RIF_Import.inc : RIFi

DOM_Import.inc : DOMi

Constants.inc

DbBrowser.inc : DBB

TagList.inc

Miscellaneous.inc

DOORS_Export.inc : DRSe

RIF_Export.inc : RIFe

DOM_Export.inc : DOMe

rif.xsd

rif-xhtml.xsd

Abbildung 6-5: Abhängigkeiten der einzelnen Source-Dateien

6 Implementierung

47

6.5 Basisfunktionen

Die Basisfunktionen dienen als Wrapperfunktionen für die DOM Methoden der MSXML A-PI. Die Wrapperfunktionen verwenden in den meisten Fällen mehrere DOM Methoden und enthalten Fehlerabfragen. Sie werden verwendet um die Navigation zwischen den XML Ele-menten zu erleichtern, und den Quellcode übersichtlicher zu gestalten. Der Zweck und die Funktionsweise der Wrapperfunktionen werden nachfolgend erläutert.

6.5.1 Export

DOMe_elementText(): Kreiert ein neues Element unterhalb eines angegebenen Elternelements. Die Text-Eigenschaft des neuen Elements wird gesetzt. Rückgabewert ist das neu kreierte Ele-ment.

<parent> <new_child>Dies ist ein Text</new_child> </parent>

DOMe_nodeElement():

Kreiert ein neues Knotenelement unterhalb eines angegebenen Elternelements. Als Rückgabewert wird das neue Element geliefert.

<parent> <new_child /> </parent>

DOMe_textNode():

Setzt die Text-Eigenschaft eines Knotenelements. <parent><child /></parent> -> <parent> Ein Text<child /></parent>

Wird in dem RIF-XHTML Namensraum verwendet um einen Text in XHTML zu formatieren.

DOMe_validate(): Validiert das Dokument nach dem vorher geladenen Schema. Bei einem nicht validen Dokument wird eine Error-Nachricht mit Details zurückgegeben.

6.5.2 Import

DOMi_getNumChilds(): Liefert die Anzahl der Unterelemente erster Ebene eines Elternelements. Als Eltern-element kann ein XPath oder eine Variable vom Typ OleAutoObj angegeben werden.

DOMi_getText(): Liest den Text eines Elements. Der Pfad des Elements wird über den XPath angege-ben.

6 Implementierung

48

DOMi_selectElement(): Selektiert ein Element, dessen Pfad über den XPath angegeben wird.

DOMi_getTextFromChild(): Liest den Text eines Kindelements erster Ebene unterhalb des Elternelements. Das El-ternelement ist vom Typ OleAutoObj.

DOMi_getNamedChild(): Sucht in einer Ebene unter der des Elternelements nach einem Kindelement.

DOMi_findElemBelow(): Sucht in allen ebenen unterhalb des Elternelements nach einem Unterelement. Die Su-che erfolgt rekursiv.

6.5.3 Gemeinsame Routinen

appSchemToDoc(): Bindet das RIF-Schema und das XHTML-Schema an den MSXML Parser. Zum La-den eines XML-Schemas in eine Schemacollection wird die folgende XML DOM Me-thode benötigt: SchemaCollection.add( namespaceURI, schemaLocation )

Die Schemacollection wird über die Eigenschaft (Property) DOMDocument.schemas = SchemaCollection

des Dokuments, an das Dokument angehängt. Die vereinfachte Implementierung ohne Fehlerabfrage in DXL sieht folgendermassen aus: /********************** RIF-Schema **************** ******/ // globalen Argumentenblock zurücksetzen clear(args) // Argumentenblock mit Namespace und Pfad des RIF-S chemas füllen put(args, "http://automotive-his.de/schema/rif") put(args, "C:\\RIF_Project\\XML_Schemas\\rif.xsd") // RIF-Schema zum Schemacache hinzufügen sError = oleMethod(schemaCache, "add", args) /********************* XHTML-Schema *************** ******/ clear(args) // Argumentenblock mit Namespace und Pfad des XHTML -Schemas füllen put(args, "http://automotive-his.de/schema/rif-xhtm l") put(args, "C:\\RIF_Project\\XML_Schemas\\rif-xhtml. xsd")

6 Implementierung

49

// XHTML-Schema zum Schemacache hinzufügen sError = oleMethod(schemaCache, "add", args) // Schemacache anbinden an das Dokument über das Pr operty "schemas" sError = olePut(xmlDoc, "schemas", schemaCache)

saveSkip():

Speichert die globale Skip Liste mit den Identifiern aller Informationstypen in eine Textdatei.

6.6 Erstexport eines Moduls

6.6.1 Ablauf

Im Vergleich zu dem Konzept soll hier der implementierte Ablauf eines Erstexportvorgangs vorgestellt werden. Nach jeder Abarbeitung einer Prozedur, wird diese auf Erfolg überprüft. Erst wenn eine Prozedur erfolgreich abgearbeitet wurde, beginnt die Abarbeitung der nächs-ten Prozedur.

• Globale Variablen und Schnittstellen initialisieren • Export Dialogbox erstellen • Auf Eingabe von Benutzer warten • Eingabe auf Richtigkeit und Vollständigkeit überprüfen • Auswahl der Attribute • MSXML Parser initialisieren • Processing Instruction der XML-Datei setzen • RIF Informationselement erstellen und als DOM Wurzel setzen • Datentypen erstellen (Datatypes) • Attributdefinitionen erstellen (SpecTypes) • Attribute mit Werten füllen (SpecObjects) • Objekthierarchie übertragen • Dokument validieren • Identifier speichern • DOM Baum in XML-Datei speichern • Globale Variablen und Schnittstellen freigeben

6.6.2 Export Dialogbox

Die Export Dialogbox in Abbildung 6-6 dient zu Demonstrations-Zwecken und soll das Aus-führen des Exportskripts veranschaulichen. Es soll das zu exportierende Modul gewählt wer-den. Im ersten Eingabefeld soll der Pfad der RIF-Datei angegeben werden und im zweiten Eingabefeld der Pfad für die Textdatei mit den GUID’s.

6 Implementierung

50

Abbildung 6-6: Export Dialogbox

Über den Export-Button wird vorerst eine weitere Dialogbox aufgerufen, um die gewünschten Attribute auszuwählen, siehe Abbildung 6-7.

Abbildung 6-7: Dialogbox zur Auswahl der Attribute

Nach der Auswahl der Attribute wird der Exportvorgang angestoßen. Nachdem die Daten erfolgreich in die RIF-Datei übertragen wurden, erscheint eine Infobox mit einer Bestätigung.

6 Implementierung

51

Zur Kontrolle wird in der Infobox das Quellmodul, die Zieldatei und die benötigte Zeit ange-zeigt, siehe Abbildung 6-8.

Abbildung 6-8: Infobox zur Bestätigung des erfolgreichen Exportvorgangs

6.6.3 Processing Instruction

Das XML Element Processing Instruction gibt Anweisung über die Verarbeitungsweise des Dokuments. Nach der RIF Spezifikation soll das Dokument dem XML 1.0 Standard und einer UTF-8 Zeichencodierung entsprechen. Folgende Routine setzt die Processing Instruction ei-ner XML Datei. Der Einfachheit halber werden die Fehlerroutinen an dieser Stelle nicht auf-geführt. string DOMe_processingInstr(string target, string d ata){ OleAutoObj newItem string sError = "" /*set XML version and processing instruction param eter*/ clear(args) put(args, target) put(args, data) sError = oleMethod(xmlDoc,"createProcessingInstruc tion",args,newItem) if( sError != "" || null(newItem) ){ /* Error handling */ } /* append processing instruction element to xml-fi le */ clear(args) put(args, newItem) sError = oleMethod(xmlDoc, "appendChild", args) if( sError != "" ){ /* Error handling */ } return sError }

6 Implementierung

52

6.6.4 Wurzelelement RIF

Das Wurzelelement RIF, beschrieben im Kapitel 3.4 Seite 18, ist die Wurzel des DOM-Baumes in der RIF-Datei und wird mit dem Aufruf olePut(xmlDoc, "documentElement", objRoot)

gesetzt. Der Benutzer kann die Attribute title, comment, author und version im RIF Informa-tionstyp bestimmen, um die RIF-Datei zu spezifizieren. Über XML-Attribute des Wurzelelements RIF wird der Namensraum (namespace) und der Ort der verwendeten Schemas (schema location) in der RIF-Datei angegeben.

6.6.5 Datentypen

Die Routine DRSe_baseAttrTypes() exportiert die DOORS Datentypen in die RIF-Datei. Als Übergabeparameter wird u.a. ein Feld mit den Namen der zu exportierenden Attribute übergeben. Es werden nur die Datentypen der angegebenen Attribute exportiert. Die Datenty-pen, die entweder vom Basistyp Date oder vom Basistyp Username abgeleitet sind, werden in RIF auf den Datentyp String abgebildet. Das Flussdiagramm in der Abbildung 6-9 verdeut-licht den Exportvorgang der DOORS Datentypen.

6 Implementierung

53

Attributtypbestimmen

Attribut-typ bereitsexportiert?

Attributliste = {"A1", "A2", ".."}

SelektiereAttributliste[i]

i = 0

i = i +1

Bestimme Min undMax Grenzen

Attributtyp =Boolean?

Bestimme Min undMax Grenzen

RIF:DatatypeDefinition

Integer


Real


String


Boolean


Document


Enumeration

JaNein

Basistyp =Integer?

BT = Real?

BS = String?

BT = Date?

BT =Username?

BT = Text?

BT =Enumeration?

Nein

Fehlerbehandlung

Nein

Nein

Nein

Nein

Nein

Nein

Ja

Ja

Ja

Ja

Ja

Ja

Ja Ja

Nein

Basistypbestimmen

i < AnzahlAttribute?

Return

Ja

Nein

Abbildung 6-9: Flussdiagramm zum Exportieren der Datentypen

6 Implementierung

54

6.6.6 Attributdefinitionen

Die Definitionen der Attribute wird äquivalent zu den Datentypendefinitionen durchgeführt. Als Übergabeparameter der Routine DRSe_attrDef() muss dasselbe Feld mit den Attribut-namen übergeben werden, welches auch für die Definition der Datentypen verwendet wurde. Anhand der Basistypen der Attribute wird entschieden, welche Attributdefinitionen erstellt werden müssen AttributDefinitionSimple, AttributDefinitionComplex oder AttributDefiniti-onEnumeration. Die Attributdefinitionen AttributDefinitionSimple und AttributDefinition-Enumeration können vorgegebene (default) Werte beinhalten, wobei die Attributdefinition Enumeration auch mehrere default Werte gleichzeitig aufweisen kann. Abbildung 6-10 zeigt ein grobes Flussdiagramm, welches den Exportvorgang der Attributdefinitionen verdeutlicht.

BestimmeAttributtyp

Attributliste = {"A1", "A2", ".."}


i = 0

i = i +1

RIF:AttributDefinition

Simple

RIF:AttributeDefinition

Enumeration

RIF:AttributeDefinition

Complex

Basistyp =Integer?

BT = Real?

BS = String?

BT = Date?BT =

Username?

BT = Text?

BT =Enumeration?

Nein

Fehlerbehandlung

Nein

Nein

Nein Nein

Nein

Nein

Ja

Ja

JaJa Ja

Ja

Ja

BestimmeBasistyp

Bestimme defaultvalue(s)


Return

Ja

Nein

Abbildung 6-10: Flussdiagramm zum Exportieren der Attributtypen

6 Implementierung

55

6.6.7 Attributwerte

Nach dem Flussdiagramm in der Abbildung 6-11 werden die Attributwerte eines Moduls in die RIF-Datei übertragen. Im Flussdiagramm sind zwei Schleifen enthalten zum einen über alle Objekte eines Moduls und zum anderen über die ausgewählten Attribute eines Objekts. Über den Basistyp eines Attributs wird der zugehörige RIF Wertekontainer AttributeValue-Simple, AttributeValueComplex oder AttributeValueEnumeration ermittelt.

Attributliste ={"A1", "A2", ".."}

i = 0

Selektierenächstes Objekt

Selektiere erstesObjekt im Modul

i >= AnzahlAttribute?

nächstes Obj.vorhanden?

ReturnJa Nein

Nein

BestimmeAttributtyp


i = i +1

RIF:AttributeValue

Simple

RIF:AttributeValueEnumeration

RIF:AttributeValue

Complex

Basistyp =Integer?

BT = Real?

BS = String?

BT = Date?BT =

Username?

BT = Text?

BT =Enumeration?

Nein

Fehlerbehandlung

Nein

Nein

Nein Nein

Nein

Nein

Ja

Ja

JaJa Ja

Ja

Ja

BestimmeBasistyp

Ja

Abbildung 6-11: Flussdiagramm zum Exportieren der Attributwerte

6 Implementierung

56

6.6.8 Objekthierarchie

Nachdem alle Objekte, Attribute und Definitionen in die RIF-Datei übertragen wurden, wird anschließend die hierarchische Struktur der Objekte exportiert. Das Flussdiagramm in der Abbildung 6-12 zeigt den Abarbeitungsverlauf der strukturierten Objekte. Anhand des Levels des aktuellen Objekts und des Levels des folgenden Objekts in DOORS wird unterschieden,

InitialisiereWurzelelemente

der Objekt-hierarchie

Selektiere erstesObjekt im Modul

Level = Level desaktuellen Obj.

LevelNext = Leveldes nächsten Obj.

LevelNext= Level?

LevelNext= -1?

LevelNext=Level+1?

LevelNext< Level?

SpecHierarchyElement kreieren

ChildrenKnotenelement

kreieren

Selektierenächstes Objekt

im Modul

BestimmeElternelement

Level = Level - 1

Ja Return

Nein

Nein

Nein

Nein

Ja

Ja

Return

Nein

Abbildung 6-12: Flussdiagramm zum Exportieren der Objekthierarchie

6.6.9 Identifier

Die Identifier werden, wie im Kapitel 4.2.5 behandelt, gespeichert. Abbildung 6-13 zeigt ei-nen Beispiel einer generierten Textdatei, die im Standard Editor geöffnet wurde.

6 Implementierung

57

Abbildung 6-13: Beispiel gespeicherter ID's beim Erstexportvorgang

Die Identifier (rechts) werden durch einen Tabulator von dem eindeutigen Bezugsnamen (links) getrennt. Die Präfixe16 sind Abkürzungen für die Informationselemente, so steht z.B. AT_ für AttributeType und MOD_ für Modulname. Die Objekte in DOORS werden über de-ren Absolute Number und dem Präfix SOe_ mit den zugehörigen Identifier verknüpft. Das Präfix SOe_ steht für specification object export und die Nummer dahinter ist die Absolute Number dieses Objekts in DOORS.

6.7 Erstimport eines Moduls

6.7.1 Ablauf

Im Vergleich zu dem Konzept soll hier der implementierte Ablauf eines Erstimportvorgangs vorgestellt werden. Nach jeder Abarbeitung einer Prozedur, wird diese auf Erfolg überprüft. Erst wenn eine Prozedur der Sequenz erfolgreich abgearbeitet wurde, beginnt die Abarbeitung der nächsten Prozedur.

• Globale Variablen und Schnittstellen initialisieren • Import Dialogbox erstellen • Auf Eingabe vom Benutzer warten • Eingaben auf Richtigkeit und Vollständigkeit überprüfen • MSXML Parser initialisieren und Dokument laden • Source-Tool der RIF-Datei für korrektes Mapping bestimmen • Modul in DOORS anlegen • Datentypen kreieren, falls notwendig • Attribute erstellen

16 Vollständige Namen der Präfixe sind in der Datei Constants.inc zu finden.

6 Implementierung

58

• Attribute mit Werten füllen • Objekthierarchie setzen • Skip Liste mit den Id’s in eine Datei speichern • Modul speichern und schließen • Globale Variablen und Schnittstellen freigeben

6.7.2 Import Dialogbox

Die Import Dialogbox in Abbildung 6-14 ist identisch zu der Export-Dialogbox. Es soll ein Projekt oder Ordner in der Datenbank für das zu importierende Modul ausgewählt werden. Im ersten Eingabefeld soll der Pfad der neu kreierten RIF-Datei angegeben werden und im zwei-ten Eingabefeld der Pfad für die Textdatei mit den GUID’s.

Abbildung 6-14: Import Dialogbox

Nachdem die Daten erfolgreich aus der RIF-Datei in der Datenbank gelandet sind, erscheint eine Infobox mit einer Bestätigung. Zur Kontrolle wird in der Infobox die Quelldatei, das Zielmodul und die benötigte Zeit angezeigt, siehe Abbildung 6-15.

6 Implementierung

59

Abbildung 6-15: Infobox zur Bestätigung des erfolgreichen Importvorgangs

6.7.3 Initialisierung des MSXML Parsers

Während des Initialisierungsprozesses werden die beiden Schemas mit der Routine appSchemToDoc()

an das XML Dokument gebunden. Mit den Eigenschaften olePut(xmlDoc, "async", false) olePut(xmlDoc, "validateOnParse", true)

wird bestimmt, dass das Dokument synchron eingelesen, d. h. die load Methode blockiert beim Laden einer XML-Datei, und gleichzeitig validiert wird. Die Namensräume werden mit der Eigenschaft SelectionNamespaces und der Methode setProperty() gesetzt. put(args, "SelectionNamespaces") put(args,"xmlns:xsi='http://www.w3.org/2001/XMLSch ema-instance' xmlns='http://automotive-his.de/schema/r if' xmlns:rif-xhtml='http://automotive-his.de/sch ema/rif-xhtml' ") oleMethod(xmlDoc, "setProperty", args)

Die Eigenschaft SelectionLanguage wird auf XPath gesetzt. Anschließend werden aufgetre-tene Fehler beim Parsen behandelt.

6.7.4 Modul

Über den XPath werden vorerst die benötigten Daten für ein neues Modul aus der RIF-Datei entnommen. Es wird der Name, die Beschreibung und die Id aus dem Informationstyp Spec-Type für ein neues Modul benötigt. Der Name steht in sName = DOMi_getText("//SPEC-TYPES/SPEC-TYPE/LONG- NAME", sErrMsg),

die Beschreibung in sDesc = DOMi_getText("//SPEC-TYPES/SPEC-TYPE/DESC" , sErrMsg)

und die Id findet man im Attribut sId = DOMi_getText("//SPEC-TYPES/SPEC-TYPE/IDENTIF IER", sError).

6 Implementierung

60

Der verwendete Parameter sErrMsg wird per Referenz übergeben und speichert bei erfolglo-sem Aufruf die Fehlermeldung. Mit dem Aufruf Module m = create(sName, sDesc, "", 1, false)

wird ein neues Modul kreiert. sName ist der Pfad des neuen Moduls in der Datenbank und sDesc ist die Beschreibung des Moduls. Der dritte Parameter ist das Präfix und wird leer ge-lassen. Parameter vier ist die Startnummer der Absolute number der Objekte in diesem Modul und der letzte Parameter bestimmt, ob das neue Modul angezeigt werden soll oder nicht.

6.7.5 Datentypen und Attributtypen

Die in der RIF-Datei definierten Datentypen werden auf Gleichheit mit den DOORS Datenty-pen überprüft. Ein RIF Datentyp wird auf einen DOORS Datentyp direkt abgebildet, wenn der Name (LongName) und der Typ (DatatypeDefinition) der RIF-Datei mit dem Namen ei-nes Attributtyps und dessen Basistyps in DOORS übereinstimmen. Stimmt entweder der Na-me, oder der Typ nicht überein, muss ein neuer benutzerdefinierter Datentyp in DOORS krei-ert werden. Das Flussdiagramm in Abbildung 6-16 verdeutlicht den Importvorgang der RIF Datentypen. Der Name eines Datentyps wird aus dem Element LONG-NAME einer Datentypdefinition entnommen. Der Datentyp Boolean muss in DOORS nicht angelegt werden, weil er stan-dardmäßig in einem neuen Modul vorhanden ist. Integer und Real dagegen sind Datentypen, die die Eigenschaft besitzen begrenzt zu werden, es ist also möglich einen minimalen und maximalen Wert anzugeben.

6 Implementierung

61

i = 0

i < AnzahlDatentypen?

Navigiere zumDatentyp(i)

DTD =Integer?

DTD = Real?

DTD = String?

DTD =Document?

DTD =Boolean?

DTD = Enum.?

i = i +1

Kreiere Attributtypvom Basistyp

Integer mitBegrenzung

Kreiere Attributtypvom Basistyp

String

Kreiere Attributtypvom BasistypEnumeration

begrenzt?

Kreiere Attributtypvom BasistypInteger ohneBegrenzung

Attributtypbereits

definiert?

Kreiere Attributtypvom Basistyp Real

mit Begrenzungbegrenzt?

Kreiere Attributtypvom Basistyp Realohne Begrenzung

DefiniereEnumeration

Werte

Ja

Ja

Ja

Nein

Nein

Nein

Nein

Nein

Ja

Ja

Ja

Ja

Ja

Nein

Ja

Nein

DTD := Datentypdefinition inder RIF-Datei

ReturnNein

Abbildung 6-16: Flussdiagramm zum Importieren der Datentypen

6.7.6 Attributdefinitionen

Über die XPath Funktion des MSXML Parsers wird zu den Attributen SpecAttributes eines Spezifikationstyps SpecType navigiert. Der vollständige XPath sieht folgendermaßen aus

//SPEC-TYPES/SPEC-TYPE/SPEC-ATTRIBUTES .

Sollten mehrere Spezifikationstypen in einer RIF-Datei vorhanden sein, wird nur der erste importiert. Bei dem iterativen Abarbeiten der Attributdefinitionen wird kontrolliert, ob eine Definition eines Attributs bereits in DOORS vorhanden ist. Sollte dies nicht der Fall sein, wird ein neues Attribut angelegt, andererseits wird das Attribut übersprungen. Der Attribut-typ, der zum Erstellen einer neuen Attributdefinition vorhanden sein muss, wird aus der Skip Liste entnommen.

6 Implementierung

62

i = 0


Navigiere zumAttribut(i)

i = i +1

Attribut-definition

vorhanden?Ja

Ja

Nein

Suche Attributtypin Skip Liste

Kreiere Attribut

SelektiereElement

SpecAttributes

ReturnNein

Abbildung 6-17: Flussdiagramm zum Importieren der Attributdefinitionen

6.7.7 Attributwerte

Die Werte der Attribute werden nach dem folgenden Flussdiagramm, siehe Abbildung 6-18, übernommen. Es wird über die Objekte (SpecObject) und über deren Werte (Value) iteriert.

6 Implementierung

63

Selektiere erstesSpecObject

VergleicheSpecType

Kreiere Objekt inDOORS

selektiere erstesValue

Ist letztesValue?

Ist letztesSpecObject?

fülle Attribut mitWert

Ja

Nein

Nein

Ja

Attribut-definition vor-

handen?

Nein

Ja

Return

Selektiere(nächstes)SpecObject

selektierenächstes Value

Abbildung 6-18: Flussdiagramm zum Importieren der Attributwerte

6.7.8 Objekthierarchie

Die Objekthierarchie in DOORS wird aktualisiert, nachdem alle Objekte kreiert und die Attri-bute gesetzt wurden. Abbildung 6-19 zeigt das Klassendiagramm der Baumstruktur der Ob-jekthierarchie in RIF. Es gibt ein Wurzelelement SpecHierarchyRoot, das über die Klasse SpecHierarchy mehrere Referenzen auf Objekte enthalten kann. Ein Baumknoten wird über eine Komposition der Klasse SpecHierarchy mit sich selber und einem Rollennamen children realisiert.

6 Implementierung

64

Abbildung 6-19: Klassendiagramm der RIF Objekthierarchie

Nach dem Flussdiagramm in der Abbildung 6-20, wird die Objekthierarchie aus der RIF-Datei auf die importierten Objekte in der Datenbank übertragen. Der DOM Baum der RIF-Datei wird ab dem Element SpecHierarchyRoot rekursiv durchlaufen. Zur Startzeit sind das Elternelement und das vorherige Objekt unbekannt und werden auf null gesetzt. Mit einem Element, ist ein DOM-Element aus der RIF-Datei gemeint und einem Objekt, ein DOORS-Objekt. Das Elternelement ist das erste Element der höchsten Ebene (Level 1) und stellt in der Daten-bank das erste Objekt dar. Alle weiteren Objekte werden entweder hinter oder unter das El-ternobjekt verschoben. Das Durchlaufen des Knotenelements CHILDREN führt zur Erhöhung des Levels der nachfolgenden Elemente. Wird das SPEC-HIERARCHY Element durchlaufen, wird es als neues Elternelement gesetzt und die Routine rekursiv aufgerufen. Das assoziierte Objekt des Informationstyps SpecHierarchy wird anhand der Levelnummer in die korrekte Position eingepflegt. Die Routine beendet sich, wenn im SPEC-HIERARCHY kein Knotenelement CHILDREN vorhanden ist, oder wenn keine SPEC-HIERARCHY Elemente einer Ebene vorhanden sind.

SpecHierarchyRoot

SpecHierarchy

SpecObject

+ children* { ordered }

+ children* { ordered }

+ children* { children}

+ children* { children}

+ object

1 + object

1

6 Implementierung

65

Elternelementbestimmen understen Knoten(CHILDREN)selektieren

Aktuelles Objekthinter vorherigesO. verschieben

Eltern-element = 0?

Tag = SPEC-HIERARCHY ?

Tag =CHILDREN?

Level = Level + 1

Vorh.Objekt != 0?

Leveldes vorh. O. <

Level

Leveldes vorh. O. =

Level

Aktuelles Objektunter vorherigesO. verschieben

Ja

Nein

Nein

Ja

Ja

Ja

Nein

Ja Ja

rekursiv

NeinFehler

Nein

ReturnNein

Elternelement = 0Vorheriges Objekt = 0

Level (aktuelles Objekt) = -1

Unter-elemente?

SelektiereKnotenelement(CHILDREN)

Neuer Aufruf füralle SPEC-

HIERARCHYElemente der

aktuellen Ebene

Return

Nein

Ja

Abbildung 6-20: Flussdiagramm zum Importieren der Objekthierarchie

6.7.9 Identifier

Die Identifier aller Informationselemente, mit Ausnahme der Identifier des Informationstyps SpecObject, werden wie beim Exportvorgang in eine Textdatei gespeichert. Die Objekte in der Erzeugerdatenbank weisen in der Regel keine durchgehende Absolute number (AN) auf, weil während der Erstellung oder Bearbeitung, Objekte gelöscht oder verschoben werden können. Die Objekte in der Import Datenbank dagegen, werden sequenziell kreiert und haben somit durchgehend – ohne Lücken – aufsteigende AN. Dies führt zu unterschiedlichen AN zweier gleicher Objekte in verschiedenen Datenbanken, somit reicht es auf der Importseite nicht mehr aus, die Identifier nur mit der AN eines importierten Objekts zu verknüpfen. Die

6 Implementierung

66

AN eines Objekts der Exportdatenbank wird mit der neuen AN eines Objekts der Importda-tenbank verknüpft. Die neue AN auf der Importseite zeigt auf die alte Id des Objekts. Abbildung 6-21 veranschaulicht die Umgangsweise der Id’s gleicher Objekte und verschiede-ner AN.

12345678910

12345

RIF-DateiErstexport Import

Eindeutige Objekt-ID'sin der ErzeugerDOORS Datenbank

Eindeutige Objekt-ID'sin der Import DOORSDatenbank

Guid_ModulName.txt

...SOe_1 3F7614A8-3ADC-4D38-8160-0E9B3D17FEB7SOe_2 5B51CA10-88D7-4179-B20D-8E8EAFD502D2SOe_4 F3E6FB21-B560-4F2A-B341-9D0FCEED37D2SOe_7 66148864-0C7C-4716-8618-2B5CC5D4D640SOe_10 9FFF7935-6B6A-4D1D-9F92-49E6A7A568E2.....

Guid_ModulName.txt

...SOe_1 SOi_1SOe_2 SOi_2SOe_4 SOi_3SOe_7 SOi_4SOe_10 SOi_5SOi_1 3F7614A8-3ADC-4D38-8160-0E9B3D17FEB7SOi_2 5B51CA10-88D7-4179-B20D-8E8EAFD502D2SOi_3 F3E6FB21-B560-4F2A-B341-9D0FCEED37D2SOi_4 66148864-0C7C-4716-8618-2B5CC5D4D640SOi_5 9FFF7935-6B6A-4D1D-9F92-49E6A7A568E2...

GelöschteObjekte

Abbildung 6-21: Beispiel gespeicherter Id's beim Importvorgang

6 Implementierung

67

6.8 Performance

Nach der Implementierung des Export- und Importvorgangs wurden einige Performancemes-sungen durchgeführt. Die gemessenen Werte sollen einen groben Überblick über die Ge-schwindigkeit des Export- und Importvorgangs verschaffen. Das Diagramm in der Abbildung 6-22 zeigt den RIF Export- und Importgraphen. Die Y-Achse stellt die Zeit in Sekunden dar, die für den Vorgang benötigt wurde und die X-Achse die Anzahl der Objekte, die exportiert bzw. importiert wurden. Bei der Messung wurde nur das Hauptattribut (Object Heading und Object Text) berücksichtigt. Bilder, Tabellen oder OLE-Objekte innerhalb des Hauptattributs wurden nicht mit eingebunden. Der Inhalt der Testobjekte besteht durchschnittlich aus 80 Zeichen. Die Größe der XML-Datei mit 25 Tausend Objekten beträgt unkomprimiert ca. 22 MB und mit WinZip komprimiert nur ca. 3,5 MB. Rund 200 Tausend Wörter und 2 Mio. Zeichen wurden bei 25 Tausend Objekten exportiert.

Export/Import Performance

8009; 78

25220; 318

16048; 1611996, 150

4006, 540

8009, 1800

0

200

400

600

800

1000

1200

1400

1600

1800

2000

0 5000 10000 15000 20000 25000 30000

Anzahl Objekte

Zei

t in

Sek

un

den

RIF Export RIF Import

Abbildung 6-22: Performance des Export- und Importvorgangs

6 Implementierung

68

Die Performance des Exportvorgangs liegt mit 5 Minuten bei 25 Tausend Objekten im ak-zeptablen Bereich. Der Import dagegen schafft bis 3 Tausend Objekte innerhalb von 5 Minu-ten, somit steigt die Dauer des Import mit zunehmenden Objekten nicht linear an. Der lineare Zeitverlauf beim Exportvorgang hängt damit zusammen, dass während des Vor-gangs die Größe des Moduls konstant bleibt, weil nur ein lesender Zugriff auf das Modul er-folgt. Beim Import dagegen wird das Moduls in der Datenbank während des ganzen Import-vorgangs permanent erweitert. Bei wachsender Objektanzahl wird das Verwalten der Objekte zunehmend aufwendiger und deshalb auch langsamer. Operationen z.B. zum Selektieren oder Kreieren eines Objekts, werden bei steigender Objektanzahl zunehmend zeitaufwendiger und verursachen somit einen nicht linearen Zeitverlauf des Importvorgangs.

7 Unstimmigkeiten zwischen RIF Spezifikation und XML-Schema

69


7.1 Allgemein

Bei der Implementierung der RIF Schnittstelle in DOORS sind einige Unstimmigkeiten zwi-schen der RIF Spezifikation und dem dazugehörigen RIF XML-Schema aufgetreten. In der RIF Spezifikation vorgegebene Klassennamen und Assoziationen stimmten nicht vollkommen mit denen aus dem RIF-Schema überein. Die Differenzen kamen erst beim Parsen oder Vali-dieren einer RIF-Datei zum Vorschein und mussten zwischen dem RIF-Schema und der Spe-zifikation zuerst auf einen Nenner gebracht werden, um von vornherein verifizierte Doku-mente laden und erstellen zu können. Dabei wurde das RIF-Schema an die RIF Spezifikation angepasst. Nachfolgend werden die Klassen vorgestellt, die zwischen der Spezifikation und dem RIF-Schema Unterschiede aufweisen. Alle Diagramme auf der linken Seite beziehen sich auf die RIF Spezifikation und auf der rechten Seite auf das RIF-Schema.

7.2 Klasse RIF

Abbildung 7-1: Klasse RIF in der Spezifikation (links) und im Schema (rechts)

Das Attribut identifier, definiert in der RIF Spezifikation (3.2.1 General Structure), ist im Schema17 (rif.xsd Zeile 494) nicht enthalten.

17 Es ist das RIF-Schema gemeint. Diese Namenskonvention gilt für dieses ganze Kapitel.

RIF

identifier title comment version countryCode creationTime sourceToolId

RIF

title comment version countryCode creationTime sourceToolId


70

7.3 Klasse EnumValue

Abbildung 7-2: Rollenname der Assoziation mit der Klasse EnumValue in der Spezifikation (links) und im

Schema (rechts)

In der RIF Spezifikation (3.2.2.2 Enumeration data types) weicht der Rollenname der Asso-ziation zwischen den Klassen DatatypeDefinitionEnumeration und EnumValue vom Schema (rif.xsd Zeile 374) ab. Der Rollenname im Schema wurde auf specifiedValues geändert.

7.4 Assoziation der Klasse AttributeValueEmbeddedDocument

Abbildung 7-3: Assoziation der Klasse AttributeValueEmbeddedDocument in der Spezifikation (links) und im

Schema (rechts)

Nach der RIF Spezifikation (3.2.2.3 Complex data types) assoziiert die Klasse AttributeVa-lueEmbeddedDocument über den Rollennamen definition die Klasse AttributeDefinition-Complex. Grundsätzlich verweist eine Klasse mit einem Attributwert auf eine Klasse mit einer Attributdefinition und erst die Klasse mit der Attributdefinition referenziert auf einen kon-kreten Datentyp. Im Schema (rif.xsd Zeile 175) referenziert die Klasse AttributeValueEmbed-dedDocument direkt auf eine Klasse mit einer Datentypdefinition.


EnumValue

+ specifiedValues

* + specifiedValues

*


EnumValue

+ enumValues

* + enumValues

*

AttributDefinitionComplex

AttributeValueEmbeddedDocument

DatatypeDefinitionDocument

AttributeValueEmbeddedDocument

+ definition 1

+ definition 1

+ definition 1

+ definition 1


71

7.5 Assoziation mit der Klasse DatatypeDefinitionComplex

Abbildung 7-4: Assoziation der Klasse DatatypeDefinitionComplex in der Spezifikation (links) und im Schema

(rechts)

Nach der RIF Spezifikation (3.2.2 RIF datatypes) assoziiert die Klasse AttributeDefinition-Complex die Klasse DatatypeDefinitionComplex und im Schema (rif.xsd Zeile 111) ist keine Assoziation implementiert.

7.6 Klasse SpecHierarchy

Abbildung 7-5: Rollennamen der Assoziation zwischen der Klasse SpecHierarchy und SpecObject in der Spezifi-

kation (links) und im Schema (rechts)

Nach RIF Spezifikation (3.2.1.5 SpecHierarchyRoots) assoziiert die Klasse SpecHierarchy über den Rollennamen object die Klasse SpecObject. Der Rollenname derselben Assoziation im Schema (rif.xsd Zeile 616) ist specObject.

AttributeDefinitionComplex

AttributeDefinitionComplex

DatatypeDefinitionComplex

DatatypeDefinitionComplex

+ type 1

+ type 1

SpecObject

SpecObject

SpecHierarchy

SpecHierarchy

+ object1

+ object1

+ specObject1

+ specObject1

8 Zusammenfassung und Ausblick

72

8 Zusammenfassung und Ausblick

Der Verlauf dieser Arbeit hat gezeigt, dass das verlustfreie Mapping der DOORS Daten-struktur auf die RIF Datenstruktur nicht einfach zu realisieren und mit Restriktionen verbun-den ist. Der Dokumentenaustausch nach RIF Standard zwischen zwei DOORS Datenbanken ist sehr umständlich, weil ein doppeltes Mapping durchgeführt werden muss. Andersherum werden die Module in DOORS beim Export oder Import nach RIF Standard nicht manipuliert, was bei eXchange der Fall ist. Dies ermöglicht eine beliebige Anzahl an Austauschvorgängen eines Dokuments. Der Export und der Import einer RIF-Datei in DOORS sind nicht vollständig implementiert. Es werden nur die grundlegenden Funktionen und Eigenschaften unterstützt. Zu diesen gehö-ren sowohl vordefinierte als auch benutzerdefinierte Datentypen, Attributdefinitionen ein-schließlich der default values, Attribute, Objekte und die Objekthierarchie. Es wird ein Erst-export und ein Erstimport unterstützt. Eine ausführliche Schnittstelle zwischen DXL und dem MSXML Parser wurde geschaffen, die für eine weitere Implementierung als Basis dient. Das Konzept stellt den theoretischen Teil der Arbeit dar und ist weitreichender als die Imp-lementierung. Dort wurde u.a. der Umgang mit den Identifiern behandelt und der Ansatz für die Umsetzung der DOORS Features Tables, Pictures und OLE Objekte ausgearbeitet. Damit die Implementierung kommerziell eingesetzt werden kann, müssen weitere Entwick-lungen folgen. In erster Linie muss eine Synchronisation zweier Dokumente nach RIF Use Case 2 implementiert werden, um Dokumente reexportieren und reimportieren zu können. Anschließend sollte die konzeptuelle Beschreibung zu den DOORS Features umgesetzt wer-den. Die zurzeit prototypische Benutzeroberfläche muss selbstverständlich den Funktionali-täten der Implementierung und dem Benutzerkonform angepasst werden. Leider war es nicht möglich den Austausch der RIF-Dateien mit verschiedenen AM-Tools zu testen, weil noch kein anderes AM-Tool eine RIF-Schnittstelle anbietet. Die Unstimmigkeiten im Kapitel 7 deuten darauf hin, dass nur wenige Firmen sich mit der RIF Spezifikation befasst haben. Sollte der RIF Standard mehr Zustimmung von den Herstellern der AM-Tools bekom-men, müssen weitere einheitliche Konventionen zwischen den verschiedenen AM-Tools und somit weitere Versionen der RIF Spezifikation folgen.

9 Abbildungsverzeichnis

73

9 Abbildungsverzeichnis

Abbildung 2-1: Anmeldefenster in DOORS ............................................................................9 Abbildung 2-2: Datenbankansicht in DOORS.......................................................................10 Abbildung 2-3: Hierarchischer Aufbau der DOORS Datenbank...........................................11 Abbildung 2-4: Default View eines Formalen Moduls ..........................................................12 Abbildung 2-5: Attributtypen und Basistypen in DOORS.....................................................13 Abbildung 2-6: Attributdefinitionen und Attributtypen in DOORS ......................................14 Abbildung 2-7: DXL Eingabeformular ..................................................................................15 Abbildung 3-1: RIF Einsatzweise ..........................................................................................16 Abbildung 3-2: UML Diagramm des RIF Modells................................................................19 Abbildung 3-3: Klasse Identifiable ........................................................................................20 Abbildung 4-1: Auszug eines Moduls mit einer Tabelle .......................................................30 Abbildung 4-2: Hierarchischer Aufbau einer Tabelle............................................................30 Abbildung 4-3: Beispiel zum Mapping von DOORS Tabellen .............................................31 Abbildung 6-1: Import/Export als Untermenü in der Datenbank...........................................40 Abbildung 6-2: Datenbank Browser.......................................................................................43 Abbildung 6-3: Datenfluss zwischen den Komponenten beim Erstexport ...........................44 Abbildung 6-4: Datenfluss zwischen den Komponenten beim Erstimport............................45 Abbildung 6-5: Abhängigkeiten der einzelnen Source-Dateien.............................................46 Abbildung 6-6: Export Dialogbox..........................................................................................50 Abbildung 6-7: Dialogbox zur Auswahl der Attribute...........................................................50 Abbildung 6-8: Infobox zur Bestätigung des erfolgreichen Exportvorgangs ........................51 Abbildung 6-9: Flussdiagramm zum Exportieren der Datentypen ........................................53 Abbildung 6-10: Flussdiagramm zum Exportieren der Attributtypen .....................................54 Abbildung 6-11: Flussdiagramm zum Exportieren der Attributwerte .....................................55 Abbildung 6-12: Flussdiagramm zum Exportieren der Objekthierarchie ................................56 Abbildung 6-13: Beispiel gespeicherter ID's beim Erstexportvorgang....................................57 Abbildung 6-14: Import Dialogbox..........................................................................................58 Abbildung 6-15: Infobox zur Bestätigung des erfolgreichen Importvorgangs ........................59 Abbildung 6-16: Flussdiagramm zum Importieren der Datentypen ........................................61 Abbildung 6-17: Flussdiagramm zum Importieren der Attributdefinitionen...........................62 Abbildung 6-18: Flussdiagramm zum Importieren der Attributwerte .....................................63 Abbildung 6-19: Klassendiagramm der RIF Objekthierarchie ................................................64 Abbildung 6-20: Flussdiagramm zum Importieren der Objekthierarchie ................................65 Abbildung 6-21: Beispiel gespeicherter Id's beim Importvorgang ..........................................66 Abbildung 6-22: Performance des Export- und Importvorgangs.............................................67 Abbildung 7-1: Klasse RIF in der Spezifikation (links) und im Schema (rechts) .................69 Abbildung 7-2: Rollenname der Assoziation mit der Klasse EnumValue in der Spezifikation (links) und im Schema (rechts)...............................................70 Abbildung 7-3: Assoziation der Klasse AttributValueEmbeddedDocument in der Spezifikation (links) und im Schema (rechts)...............................................70 Abbildung 7-4: Assoziation der Klasse DatatypeDefinitionComplex in der Spezifikation (links) und im Schema (rechts).....................................................................71 Abbildung 7-5: Rollennamen der Assoziation zwischen der Klasse SpecHierarchy und SpecObject in der Spezifikation (links) und im Schema (rechts).................71

10 Literaturverzeichnis

74


[AM] A. Heßeler, G. Versteegen: Anforderungsmanagement, erste Auflage, Sprin-ger Verlag, Berlin, 2004.

[DOM] Microsoft: Document Object Model (DOM) Referenz,

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/d051f7c5-e882-42e8-a5b6-d1ce67af275c.asp, 2006.

Document Object Model (DOM) Level 1 Specification, Version 1.0,

http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/, 1998. [DOORS] A. Heßeler, G. Versteegen: Anforderungsmanagement (Einführungsstrate-

gien und Toolauswahl), erste Auflage, Springer Verlag, Berlin, 2004. [DTD] H. Behme, S. Mintert: XML in der Praxis (Kapitel 5: XML-DTD’s), http://www.linkwerk.com/pub/xmlidp/2000/, 2000. [GUID] Eintrag aus Wikipedia: Globally Unique Identifier, Version vom 25.07.06,

http://de.wikipedia.org/wiki/Guid, 2006. [HIS] Hersteller Initiative Software: Homepage, http://www.automotive-his.de,

2006. [MSXML] Microsoft: Microsoft XML Core Services (MSXML), Version 6.0,

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/b24aafc2-bf1b-4702-bf1c-b7ae3597eb0c.asp, 2006.

[OLE] D. Chappell: Understanding ActiveX and OLE, 1st edition, Microsoft Press, Washington, 1996. CSI: Object Linkink and Embedding (OLE), http://www.websites-

factory.de/catia/Oberflache/OLE/ole.html. [RTF] Microsoft: Rich Text Format Spezifikation, Version 1.5,

http://www.biblioscape.com/rtf15_spec.htm, 1997. [RIF] HIS: Requirements Interchange Format Spezifikation, Version 1.0a,

http://www.automotive-his.de/download/Requirements_Interchange_Format_V_1_0a.pdf, 2005.

[RIFSchem] HIS: RIF XML- und XHTML-Schema, http://www.automotive-

his.de/simutool.htm, 2005. [Tlogic] Telelogic: Homepage, www.telelogic.com. [UE] IDM Computer Solutions: UltraEdit Homepage, www.ultraedit.com.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/d051f7c5-e882-42e8-a5b6-d1ce67af275c.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/d051f7c5-e882-42e8-a5b6-d1ce67af275c.asp

http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/

http://www.linkwerk.com/pub/xmlidp/2000/

http://de.wikipedia.org/wiki/Guid

http://www.automotive-his.de/

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/b24aafc2-bf1b-4702-bf1c-b7ae3597eb0c.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/b24aafc2-bf1b-4702-bf1c-b7ae3597eb0c.asp

http://www.websites-factory.de/catia/Oberflache/OLE/ole.html

http://www.websites-factory.de/catia/Oberflache/OLE/ole.html

http://www.biblioscape.com/rtf15_spec.htm



http://www.automotive-his.de/simutool.htm

http://www.automotive-his.de/simutool.htm

http://www.telelogic.com/

http://www.ultraedit.com/


75

[UUID] Leach, et. al.: Universally Unique Identifier (UUID), Internet Engineering

Task Force (IETF) RFC 4122, http://www.ietf.org/rfc/rfc4122.txt, 2005. [UML] OMG: Unified Modeling Language (UML), Version 2.0, http://www.omg.org/docs/formal/05-07-04.pdf, 2005. M. J. Chonoles, J. A. Schardt: UML 2 für Dummies, 1. Auflage, mitp-

Verlag, Bonn, 2004. [XML] H. Behme, S. Mintert: XML in der Praxis,

http://www.linkwerk.com/pub/xmlidp/2000/, 2000. [XMLSchem] W3C Technical Reports and Publications: http://www.w3.org/TR/. [XPATH] J. Clark, S. DeRose: XML Path Language (XPath), Version 1.0,

http://www.w3.org/TR/1999/REC-xpath-19991116, 1999. [XSDvsDTD] M. Jervis: XML DTDs Vs XML Schema,

http://www.sitepoint.com/article/xml-dtds-xml-schema, 2002.

http://www.ietf.org/rfc/rfc4122.txt

http://www.omg.org/docs/formal/05-07-04.pdf

http://www.linkwerk.com/pub/xmlidp/2000/

http://www.w3.org/TR/

http://www.w3.org/TR/1999/REC-xpath-19991116

http://www.sitepoint.com/article/xml-dtds-xml-schema

Documents

Erklärung - fh-muenster.de€¦ · DOORS bietet viele weitere Möglichkeiten, die das Arbeiten mit formalen Anforderungen für den Benutzer erleichtern auf die hier jedoch nicht