Konzeption und Umsetzung eines Monitoringwerkzeuges f ¨ur UML

Transcription

Konzeption und Umsetzung eines
Monitoringwerkzeuges für UML-gestützte
Softwareentwicklung
Stephan große Austing
Christian Dänekas
Dirk Siemers
Individuelles Projekt an der Abteilung Wirtschaftsinformatik der Universität Oldenburg
Betreuer:
Dipl.-Inf. Kevin Hausmann
Prof. Dr.-Ing Axel Hahn
Oldenburg, 17. Oktober 2005
Inhaltsverzeichnis
1
Einleitung
4
2
Grundlagen
2.1 MDA - Model Driven Architecture: Dirk Siemers . .
2.1.1 Basistechnologien der MDA . . . . . . . . .
2.1.2 4-Schichten Metamodellarchitektur . . . . .
2.1.3 UML und XMI als Anwendungsdomäne . . .
2.2 UML: Dirk Siemers . . . . . . . . . . . . . . . . . .
2.2.1 CASE-Tools . . . . . . . . . . . . . . . . .
2.2.2 Klassendiagramme . . . . . . . . . . . . . .
2.2.3 Sequenzdiagramme . . . . . . . . . . . . . .
2.2.4 Zustandsdiagramme . . . . . . . . . . . . .
2.3 XMI: Dirk Siemers . . . . . . . . . . . . . . . . . .
2.3.1 eXtensible Markup Language . . . . . . . .
2.3.2 Aufbau einer XMI Datei . . . . . . . . . . .
2.4 Ontologien : Stephan große Austing . . . . . . . . .
2.4.1 Ontologiebegriff in der Informatik . . . . . .
2.4.2 Eigenschaften von Ontologiesprachen . . . .
2.4.3 RDF (Resource Description Framework) . .
2.4.4 RDF Schema . . . . . . . . . . . . . . . . .
2.4.5 OWL . . . . . . . . . . . . . . . . . . . . .
2.4.6 Das Semantic Web . . . . . . . . . . . . . .
2.5 Software-Metriken: Christian Dänekas . . . . . . . .
2.5.1 Motivation und Begriffsklärung . . . . . . .
2.5.2 Thematische Einordnung der Softwaremetrie
2.5.3 Softwarequalität . . . . . . . . . . . . . . .
2.5.4 Messen . . . . . . . . . . . . . . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
7
8
10
10
11
12
15
17
19
19
21
25
25
27
29
30
32
38
41
41
42
46
49
2
INHALTSVERZEICHNIS
2.5.5
2.5.6
2.5.7
3
Anforderungen und Klassifikation . . . . . . . . . . . . . . . . . . . . . 52
Prozessmetriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Produktmetriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Umsetzung
3.1 Software: Stephan große Austing . . . . . . . . . . . . .
3.1.1 Vorgehensweise der Software . . . . . . . . . .
3.1.2 Architektur . . . . . . . . . . . . . . . . . . . .
3.1.3 Benutzerschnittstelle . . . . . . . . . . . . . . .
3.1.4 Beispiele des Programmablaufs . . . . . . . . .
3.2 XSLT: Dirk Siemers . . . . . . . . . . . . . . . . . . . .
3.2.1 Stylesheet-Struktur . . . . . . . . . . . . . . . .
3.2.2 Ausdrücke . . . . . . . . . . . . . . . . . . . .
3.2.3 Template-Regeln . . . . . . . . . . . . . . . . .
3.2.4 Anwendung von Template-Regeln . . . . . . . .
3.2.5 Elemente der XSLT . . . . . . . . . . . . . . . .
3.3 XPath: Dirk Siemers . . . . . . . . . . . . . . . . . . .
3.3.1 Lokalisierungspfade . . . . . . . . . . . . . . .
3.3.2 Funktionen auf Knotenmengen . . . . . . . . . .
3.4 OWL Ontologie : Stephan große Austing . . . . . . . . .
3.4.1 Generelles Vorgehen . . . . . . . . . . . . . . .
3.4.2 Klassendiagramme . . . . . . . . . . . . . . . .
3.4.3 Sequenzdiagramme . . . . . . . . . . . . . . . .
3.4.4 Zustandsdiagramme . . . . . . . . . . . . . . .
3.5 XMI - OWL Umwandlungen: Dirk Siemers . . . . . . .
3.5.1 Klassendiagramme . . . . . . . . . . . . . . . .
3.5.2 Zustandsdiagramme . . . . . . . . . . . . . . .
3.5.3 Sequenzdiagramme . . . . . . . . . . . . . . . .
3.6 Entwurfsmonitoring durch Metriken: Christian Dänekas .
3.6.1 Konzept und Ausgangssituation . . . . . . . . .
3.6.2 Messobjekte . . . . . . . . . . . . . . . . . . .
3.6.3 Objektorientierung und Metriken . . . . . . . .
3.6.4 Entwicklung von Metriken für UML-Modelle . .
3.6.5 Berücksichtigung funktionaler Anforderungen .
3.6.6 Praktische Umsetzung der Metriken . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
59
59
61
63
66
68
69
70
70
71
72
75
76
77
78
78
80
82
84
86
86
91
96
99
99
101
103
106
118
120
INHALTSVERZEICHNIS
4
Ausblick
4.1 Ontologien: Stephan große Austing . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Metriken: Christian Dänekas . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 UML und XMI: Dirk Siemers . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
125
125
127
129
A Diagramme
135
B Screenshots
137
Kapitel 1
Einleitung
Die Entwicklung von Software ist eine anspruchsvolle Aufgabe. Der Grund hierfür liegt in ihrer
Charakteristik als immaterielles Gut. Der Prozess des Verstehens von Software gestaltet sich daher schwierig. Seit der Softwarekrise Mitte der 60er Jahre sind aus diesem Grunde Maßnahmen,
Prozesse und Modelle entwickelt worden, die ein besseres Verständnis von Software ermöglichen
sollen. Besonderes Interesse gilt in diesem Zusammenhang auch der Frage nach dem Fortschritt
im Prozess der Softwareentwicklung.
Die Beantwortung dieser Frage ist trotz der entwickelten Techniken des Software Engineering
nicht trivial. Im Gegensatz zu anderen Tätigkeiten, die ingenieurmäßiges Vorgehen verlangen,
wie zum Beispiel dem Bau einer Brücke, unterscheidet sich Software von Projekt zu Projekt
meist sehr stark. Oftmals können Erfahrungen aus vorherigen Projekten nur eingeschränkt genutzt werden, da Softwareprojekte innovative Technologien benutzen, um den wechselnden und
teilweise neuartigen Herausforderungen zu begegnen.
In diesem Projekt wird die Phase des Softwareentwurfs betrachtet. Der Entwurf einer Software ist von großer Bedeutung für den erfolgreichen Verlauf des Entwicklungsprozesses und die
Akzeptanz der resultierenden Software. Er bildet die Verbindung zwischen den Anforderungen
der Auftraggeber und der letztendlichen Implementierung. Eine Beurteilung des Projektstandes
in dieser Phase ist daher besonders wertvoll für den Erfolg des Projektes. Es wird untersucht,
inwieweit ein Monitoring des UML-Entwurfsprozesses softwaregestützt möglich ist.
Zunächst wird daher auf die Grundlagen der in diesem Projekt verwendeten Konzepte und Technologien eingegangen. Dies beinhaltet zunächst den Entwurf von Software als Model Driven
Architecture mit Hilfe der UML. Das Austauschformat XMI für Softwareentwurfsmodelle wird
als Schnittstelle zu diesem Projekt vorgestellt. Der Ansatz des Monitoring basiert auf Softwareontologien. Die Konzepte einer Ontologie und die im Projekt verwendete Ontologiesprache
4
KAPITEL 1. EINLEITUNG
5
OWL werden erläutert. Den Abschluss des Grundlagenteils bildet eine Einführung in die Prinzipien der Softwaremetrie.
Im zweiten Kapitel erfolgt die Darstellung des Transfers dieser Konzepte auf die mögliche praktische Umsetzung in Form eines Software-Tools. Zuerst wird die Arbeitsweise des Tools und die
Struktur der Software dargestellt. Grundlage für die Arbeit der Software bilden drei aufeinander
aufbauende Elemente:
XSLT-Dokumente werden benutzt um eine Transformation von Diagrammdaten vorzunehmen. Hierzu wurden Transformationsregeln für eine Umwandlung von XMI zu OWL
erstellt.
OWL-Ontologien bilden die Grundlage für ein erweitertes Diagrammmodell. Durch den
Einsatz der Ontologien wird das automatische Schlussfolgern auf den Diagrammen ermöglicht.
Für die Analyse auf den Diagrammmodellen wurden nach den Konzepten der Softwaremetrie eine Anzahl von Metriken entwickelt, die eine Bewertung des Fortschritts ermöglichen.
Den Abschluss bildet ein kritischer Rückblick auf die Umsetzung und ein Ausblick auf weitere
Möglichkeiten des Ansatzes. Es wird verdeutlicht, dass das Konzept sehr gut umsetzbar war.
Eine Erweiterung des Ontologiemodells würde es ermöglichen funktionale Anforderungen mit
Diagrammelementen und Diagrammelemente miteinander zu verknüpfen. Der letzte Teil umfasst
auch Vorschläge um diese Möglichkeiten in der Projektgruppe “Permeter“ zu nutzen und die
Fortschrittsbewertung zu verbessern.
Kapitel 2
Grundlagen
2.1
MDA - Model Driven Architecture: Dirk Siemers
Die Grundlagen über die Model Driven Architecture (MDA) geben einen Überblick über die von
uns verwendeten Technologien Unified modelling Language (UML) und XML Metadata Interchange (XMI). Es wird kurz auf die Basistechnologien der MDA eingegangen, um diese dann
in einem allgemeinen Zusammenhang zu bringen. Dieser ist für die Exportierung von UMLDiagrammen in XMI-Dokumente sehr wichtig. Die Technologien UML und XMI werden im
weiteren Verlauf in den Kapiteln 2.2 und 2.3 näher vorgestellt. In diesen wird einerseits die
UML mit denen von uns verwendeten Diagrammtypen erläutert und andererseits XMI mit einem
kurzen Exkurs in XML vorgestellt. Beide Technologien haben jedoch ihren Zusammenhang in
der MDA, desse Grundlagen im folgenden Abschnitt näher erläutert werden.
Im Rahmen der Softwareentwicklung repräsentieren Modelle die zentralen Elemente des Entwicklungsprozesses. MDA ist dabei ein Konzept der Object Management Group (OMG) und
wird als zukunftsweisender Schritt zur Automatisierung der Softwareerstellung in Richtung einer ingeneursmässigen Softwareentwicklung gesehen. Eine wichtige Überlegung dabei ist die
Trennung von plattformunabhängigen und plattformspezifischen Modellen, die beide unabhänig
voneinander wiederverwendet werden können. Ziel ist es den Aufwand der Softwareentwicklung oder potenzielle Fehler zu reduzieren.[MDA] Mit MDA soll Software somit schneller, kostengünstiger und qualitativ hochwertiger produziert werden.
Abbildung 2.1 zeigt das von der OMG verwendete Schichtenmodell der MDA, deren Bestandteile und das Zusammenspiel dieser. Der Kern des Modells beinhaltet die Technologien UML, Meta
Object Facility (MOF) und das Common Warehouse Metamodell (CWM). UML ist ein intergraler Bestandteil der MDA-Konzepte und dient der graphischen Beschreibung von Modellen. MOF
ist ein Standart zur Beschreibung von Metamodell-Sprachen, sie definiert Metamodelle wie z.B.
6
7
KAPITEL 2. GRUNDLAGEN
Abbildung 2.1: MDA
UML oder das CMW. Zusammengefasst bilden diese drei Technologien den Kern der Abbildung
2.1, die Modellierung. In der nächste Schicht des MDA-Modells befinden sich die für den Ablauf
der modellierten Anwendungen nötigen Techniken oder Plattformen. Hier befindet sich auch das
Austauschformat XMI. Für dieses Projekt ist nur das XMI von Bedeutung, daher wird auf die
anderen Techniken nicht weiter eingegangen und mit einem kleinen Überblick über die in der
MDA verwendeten Technologien fortgesetzt.
2.1.1
Basistechnologien der MDA
Die Model Driven Architecture verwendet zahlreiche standardisierte Techniken der OMG. Nur
durch diese Technologien lässt sich der konzeptuelle Gedanke der MDA umsetzen. Für die MDA
sind folgende Technologien von Bedeutung:
UML
Die Unified Modelling Language (UML) ist eine OMG Standartsprache um die Struktur
und das Verhalten von Systemen zu spezifizieren. Sie dient der graphischen Beschreibung
von Modellen. Die UML wird in dem Kapitel 2.3 näher erläutert.
UML-Profile
UML-Profile sind ein Mechanismus um den Sprachumfang der UML zu erweitern. So
8
kann UML an andere technische oder fachliche Domänen angepasst werden. UML-Profile
sind jedoch für dieses Projekt unerheblich, da der Anwendungsbereich des Projekts auf die
Softwareentwicklung mit UML auf Java-Basis festgelegt wurde.
MOF
Die Meta Object Facility (MOF) ist ein OMG Standard, nah mit der UML verbunden, welcher das Metadatenmanagement und die Definition von Metamodellsprachen erlaubt. Sie
ist auf der Meta-Metamodellebene (siehe Abbildung 2.2) angesiedelt und definiert damit
den Aufbau der Metamodellebene, auf welcher z.B. die UML oder das CWM liegen. Die
MOF wird im folgenden Abschnitt erläutert.
XMI
Die eXtensible Markup Language Metadata Interchange (XMI) ist ein XML-basiertes
Austauschformat für Modelle und ermöglicht den unabhänigen Austausch von XMI-Dokumenten
verschiedener Modellierungswerkzeuge unterschiedlichster Hersteller. Im Rahmen dieses
Projekts ist XMI die Schnittstelle zwischen unsere Software und den verwendeten Modellierungswerkzeug Poseideon. Sie wird in Kapitel 2.3 behandelt.
CWM
Das Common Warehouse Metamodell (CWM) ist ein standardisiertes Referenzmodell für
den Austausch und Zugriff von Metadaten in der Data Warehouse Domäne. Wie schon
erwähnt behandelt das Projekt nur die Softwareentwicklung anhand von UML-Modellen,
daher ist diese Technologie der MDA für uns nicht weiter von Bedeutung.
Für die weiter Ausarbeitung werden die Technologien UML und XMI genauer betrachtet. Sie
bieten die Möglichkeit den Entwicklungsstand von Projekten anhand derer XMI-Dokumente abzulesen. Da jedoch der Kontext von UML und XMI zu MDA und der MOF nicht verloren gehen
soll, wird in dem nächsten Abschnitt ein kleiner Überblick über die MOF und deren 4-Schichten
Metamodellarchitektur gegeben. Dieser Zusammenhang ist wichtig, damit als Ausblick nicht nur
UML-Modelle, sondern alle MOF-konformen Modelle verwendet werden können.
2.1.2
4-Schichten Metamodellarchitektur
Die Meta Object Facility (MOF) Spezifikation ist eine abstrakte Sprache und ein Framework zur
Verwaltung von plattformunabhängigen Metamodellen. Mit ihr lassen sich beliebige Metamodelle konkreter Modelliersprachen modellieren. Durch die Einteilung in verschiedene Metaebenen
lassen sich unterschiedliche objektorientierte Beschreibungssprachen ineinander überführen. Die
Einteilung der Daten erfolgt in vier Meta-Ebenen. Vergleich Sie hierzu die Abbildung 2.2.
9
Abbildung 2.2: 4-Schichten Metamodellarchitektur aus Protege
1. Meta-MetaModell (M3): Dies ist die Infrastruktur der Metamodellarchitektur. Hier wird
die Sprache definiert, mit der die Metamodelle der M2 beschrieben werden können. Elemente dieser Schicht sind z.B. eine Metaklasse oder ein Metaattribut. Die MOF selbst ist
Bestandteil dieser Ebene und definiert sich somit selbst.
2. MetaModell (M2): Ein Metamodell ist eine Instanz eines Meta-Metamodells, es definiert
die Sprache um die Modelle der M1 zu beschreiben. Auf dieser Ebene wird die UML und
deren Konzepte definiert.
3. Modell (M1): Diese Ebene ist eine Instanz des Metamodells und definiert die Sprache
zur Beschreibung der Dömane. Beispiele dieser Ebene sind Claas:Symptom oder Attribute:name der Klasse Symptom.
4. Information (M0): Dies ist eine Instanz des Modells und beschreibt verschiedene Ausprägungen einer bestimmten Domäne. So ist z.B. das Attribut name der Instanz einer Symptom-Klasse Rash (Ausschlag).
Die 4-Schichten Architektur bietet XMI die Möglichkeit MOF als Basis weiterer Metamodelle zu nutzen. Dies bedeutet, dass neben UML, welche in diesem Projekt genutzt wird, auch ande-
10
re MOF-Instanzen (Ausprägungen eines Meta-MetaModells), wie das CWM, mit XMI transportiert werden können. So können auch zukünftige Sprachen ohne Problem mit dem XMI übertragen werden, ohne das Format abzuändern oder zu erweitern.
2.1.3
UML und XMI als Anwendungsdomäne
Die nächsten beiden Kapitel behandeln die Themengebiete UML und XMI mit deren praktischen
Anwendung. Wobei die Grundlagen beider Ansätze anhand von Beispielen erläutert werden.
UML bietet die Möglichkeit mit von Hilfe CASE-Tools (siehe 2.2.1) Modelle in XMI abzubilden. In unserem Projekt wird das exportierte XMI-Dokument genutzt um den Entwicklungsstand von Softwareprojekten festzustellen. Das Kapitel UML beeinhaltet eine kleine Einführung
in die UML und eine Bechreibung der von uns verwendeten UML-Diagrammtypen. Dabei werden die Konzepte der einzelnen Diagrammtypen erläutert und nützliche Beispiele gegeben. Das
Kapitel XMI befasst sich mit der Umwandlung von UML-Modellen in XMI-Dokumente. Es
werden zunächst die Grundlagen von XML-Dokumenten erläutert, um dann genauer auf das
XMI-Format eingehen zu können.
2.2
UML: Dirk Siemers
Die Unified Modelling Language (UML) ist eine semantische Sprache, die im
Software-Entwicklungsprozess angewendet werden kann. Sie stellt Strukturen und Abläufe in
objektorientierten Stoftwaresystemen dar und ist ein Ergebnis objektorientierter Analyse- und
Designmethoden Anfang der 90er Jahre. Die beiden wichtigsten Personen zu der Zeit waren Grady Booch und James Rumbaugh, dessen Methoden sich zu den Beliebtesten ihrer Zeit entwickelten.[BRJ99]
So vereinigten Booch und Rumbaugh 1995 ihre Ansätze zu einer gemeinsamen Notation, der
UM (Unified Method). Kurze Zeit später änderten Sie den Namen in UML, da es sich bei ihren
Modellen nicht mehr um eine Methodik, sondern eher um eine Notation handelte. Noch im gleichen Jahr trat Dr. Ivar Jacobson, der Vater der Anwendungsfälle, der Gruppe bei und ergänzte
die UML mit seinen Ansätzen. Die erste Version UML, UML 0.8, war entstanden und sollte von
der Öffentlichkeit diskutiert werden. Noch 1995 wurde mit der OMG vereinbart einen UMLStandart zu entwickeln.
[Rof04] 1997 wurde schliesslich UML 1.0 verabschiedet, es folgte 2001 die Version 1.4, die aktuellste Version ist UML 2.0. Wir betrachten in unserem Projekt UML in der Version 1.4, da UML
2.0 zu Beginn unseres Projekts noch nicht offiziell verabschiedet wurde und die Version 2 von
dem verwendeten CASE-Tools Poseidon nur teilweise unterstützt wurde. UML ist eine einheitliche Beschreibungssprache. Als Sprache enthält sie eine standardisierte Notation mit Semantik
11
und der Definition eines Metamodells. Es gibt Bezeichner für diverse Begriffe der Objektorientierung, welche miteinander in Beziehung gebracht werden können. Weiter ist es mit der UML
möglich Begriffe, Beziehungen oder andere Abläufe mit Hilfe einer grafischer Notation festzuhalten. Dabei reichen schon ein Stift und ein Stück Papier aus um seine Ideen festzuhalten. Um
jedoch den MDA-Gedanken fortzusetzten werden spezielle Modellierungswerkzeuge genutzt.
Die sogenannten CASE-Tools.
2.2.1
CASE-Tools
Computer-Aided Software Engineering (CASE) bedeutet soviel wie computergestützte Softwareentwicklung. CASE-Tools bieten bei der Softwareentwicklung eine transparente und visuelle
Vorgehensweise an. So wird den Entwicklern ermöglicht, das zu realisierende System als Ganzes zu betrachten. Wir verwenden in diesem Projekt das CASE-Tool Poseidon in der Version
2.6 um UML-Diagramme zu modellieren. Die aktuellste Version des Tools ist in der Version 3.2
mit UML 2.0 Unterstützung verfügbar. Da dieses Projekt jedoch auf UML 1.4 festgelegt wurde,
wurde Poseidon in der Version 2.6 verwendet, da diese noch UML 1.4 unterstützt, wobei alle
späteren Versionen bereits UML 2.0 verwenden. Poseidon ist in der Comunity-Version kostenlos
verfügbar und bietet einen grossen Funktionsumfang für alle in der UML vorkommenden Diagrammtypen. Die modellierten Diagramme können direkt als XMI-Dokument abgespeichert und
somit für das Projekt genutzt werden. Neben Poseidon gibt es noch eine grosse Menge anderer
UML-Modellierungswerkzeuge, welche wie Poseidon auch direkte Codeerzeugung für diverse
OO-Sprachen anbieten. Alle Werkzeuge speichern ihre Modelle in dem standardisierten XMLFormat XMI. Wir haben Poseidon wegen seines grossen Funktionsumfangs und der kostenlosen
Comunity-Edition ausgewählt. Einen Überblick über CASE-Tools ist Internet unter der Adresse
http://www.jeckle.de/umltools.htm zu finden.
Die UML kann grundsätzlich in zwei Diagrammgruppen eingeteilt werden. Strukturdiagramme, welche Komponenten und Klassen beschreiben, und Verhaltensdiagramme, welchen den
Prozessfluss zwischen Komponenten, Klassen, Anwender und dem System realisieren. Klassendiagramme gehören zu den Strukturdiagrammen, wobei Sequenzdiagramme und Zustandsdiagramme den Verhaltensdiagrammen angehören. Bei der Fülle der Mögichkeiten ist das Projekt
auf diese drei Diagrammtypen beschränkt. Für das Projekt sind dies die wichtigsten Diagrammtypen, sie werden nun im weiteren Verlauf näher erläutert.
2.2.2
12
Klassendiagramme
Klassendiagramme beschreiben, welche Klassen existieren und wie diese zueinander in Beziehung stehen. Sie werden hauptsächlich in der Analyse- und der Entwurfsphase eines Projekts
entworfen und sind für jedes objektorientierte Projekt unverzichtbar. Zu Anfang der Entwurfsphase werden meist noch relativ fassbare Klassen entwickelt, die jedoch am Ende relativ abstrakt
werden können. Die modellierten Beziehungen von Klassen zueinander beschreiben später die
Pfade in den Aktivitäts- und Sequenzdiagrammen. Bei Klassendiagrammen muss man also zwischen Klassen und ihren Relationen unterscheiden. Es wird nun zunächst auf die Klassen eingegangen um dann ihre Beziehungen näher zu erläutern.
Klassen sind die wichtigsten Merkmale eines objekt-orientierten Systems. Eine Klasse ist
eine Beschreibung von Objekten, welche die gleichen Attribute, Operationen, Beziehungen und Semantiken aufweisen. Es ist möglich eine Klasse von einem oder mehrere Interfaces zu implementieren. Sie bilden das Vokabular im UML Entwicklungsprozess.[Oes05]
Soll beispielsweise ein Haus gebaut werden, so muss man sich überlegen, was alles benötigt
wird um das Haus fertigzustellen, wie z.B. Wände, Türen, Fenster, ein Dach, oder Licht.
All diese Dinge kann man voneinander unterscheiden, sie haben ihre eigenen Eigenschaften. Eine Wand besitzt einen Höhe, eine Breite und eine Tiefe. Dies gilt gleichermassen
für eine Tür, jedoch sollen Türen auch geöffnet werden können. Fenster müssen wie Türen
geöffnen werden können, sollten jedoch durchsichtig sein. Zu diesen unterschiedlichen Eigenschaften gibt es noch viele weitere individuelle Eigenschaft, wie z.B. unterschiedliche
Fenstergrössen oder Rahmenfarben. In der UML werden alle diese Dinge als Klassen modelliert. Vergleichen Sie dazu Abbildung 2.3.
Klassen werden in der UML als ein Rechteck dargestellt, welches je nach Austattung der
Klasse 3 Unterteilungen besitzen kann. Der Name der Klasse wird im obersten Fenster
mit dem evtl. Paketnamen eingetragen. Im zweiten Fenster befinden sich die Attribute,
im dritten die Operationen. Die drei wichtigsten Bestandteile einer Klasse werden nun im
Überblick näher erläutert:
Name Jede Klasse besitzt einen eindeutigen Namen, um sich von anderen Klassen unterscheiden zu können. Der Name ist ein einfacher Text-String. Es können auch Pfad-
13
Abbildung 2.3: Fenster Klasse
angaben für den Namen eingetragen werden, wie z.B. java::awt::Rectangle um das
Paket anzugeben, in der sich die Klasse befindet.
Attribute Ein Attribut einer Klasse beschreibt einen Bereich von Werten, den eine Instanz
der Klasse annehmen kann. Eine Klasse kann mehrere Attribute oder auch keine Attribute besitzen. Ein Attribut beschreibt eine Eigenschaft von dem was man modelliert haben möchte.
Operationen Eine Operation ist eine Methode oder Funktion, die von der Klasse ausgeführt wird oder die etwas an der Instanz einer Klasse verändert.
Beziehungen sind Verbindungen zwischen einzelnen Klassen. In unserem oberen Beispiel
stehen Wände zueinander in Relation mit Türen oder Fenstern. Man kann auch Wände,
Fenster und Türen zu einem Raum zusammenfassen, usw. In der UML ist die Art, wie
Dinge miteinander verbunden sind (physisch oder logisch), als Relation modelliert. Die
drei wichtigsten Arten von Relationen sind Abhängigkeiten, Generalisierungen und Assoziationen. Für jede Relation bietet die UML ein Darstellungsform an, vergleichen Sie
hierzu Abbildung 2.4, 2.5 und 2.6.
Abhängikeiten Eine Abhänigkeit kann unterschiedliche Ursachen haben, z.B. benutzt eine Klasse Fenster eine bestimmte Schnittstelle der Klasse Ereignis - ändert sich der
Zustand der Schnittstelle, so hat das auch Auswirkungen auf die schnittstellennutzende Klasse.
Generalsierungen Eine Generalisierung ist eine taxonomische1 Beziehung zwischen einer allgemeinen und einer speziellen Klasse, dabei erbt die spezielle Klasse die Ei1
Griech., taxis: Anordnung; Taxonomie: Einordnen in ein System
14
Abbildung 2.4: Beziehungen
Abbildung 2.5: Aggregation und Komposition
Abbildung 2.6: Mehrfachvererbung
15
genschaften (Attribute und Operationen) der allgemeinen Klasse und fügt spezielle
Eigenschaften hinzu. Es entsteht eine hierarchische Struktur. Ein Beispiel für eine
mögliche Mehrfachvererbung zeigt Abbildung 2.6.
Assoziationen Eine Assoziation beschreibt die Verbindung oder Beziehung zwischen zwei
oder mehreren Klassen. Es gibt ungerichtete und gerichtete Beziehungen, welche
verwendet werden um konkrete Zugehörigkeiten auszudrücken. Desweiteren ist es
möglich Multiplizitäten der Assoziation zuzuordnen. Diese beschreiben wieviele Objekte der einen Klasse einer anderen Klasse zugeordnet werden können. Ein Beispiel für verschiedene Multiplizitätenangaben wäre die Zuordnung von Reifen zu
verschiedenen Fahrzeugen. Spezielle Varianten der Assoziation sind die Aggregation
und Komposition. Vergleichen Sie hierzu Abbildung 2.5.
Aggregation Eine Aggregation ist eine “Ganzes-Teil-Beziehung“, wobei eine Klasse das Ganze repräsentiert und eine weitere Klasse ein Teil des Ganzen darstellt.
Durch diese Abhängigkeit haben die beteiligten Klassen keine gleichwertige Beziehung mehr.
Komposition Eine Komposition ist eine existenzabhängige Aggregation. D.h., dass
eine Klasse nicht ohne die assoziierte Klasse existieren kann. Ein Beispiel hierfür
ist die Abhängigkeit eines Inhaltsverzeichnisses zu einem Buch. Das Inhaltsverzeichnis kann ohne Buch nicht existieren, es ist an das Buch gebunden. Für den
umgekehrten Fall gilt dieses gleichermaßen, da ein Buch ohne Inhaltsverzeichnis
keinen Sinn ergeben würde.
2.2.3
Sequenzdiagramme
Sequenzdiagramme können verwendet werden, um die an einer Interaktion beteiligten Akteure
oder Objekte sowie die von ihnen generierten Ereignisse in einer zeitlichen Abfolge darzustellen.
Dazu wird eine zweidimensionale Darstellung benutzt. Die Vertikale beschreibt den zeitlichen
Verlauf, die Horizontale enthält die Objekte und deren Interaktionen. Der zeitliche Verlauf von
Objekten wird oft als Schwimmlinien bezeichnet, welche von oben nach unten verlaufen und als
gestrichelte Linie dargestellt werden. Wird ein Objekt gelöscht, so wird die Schwimmlinie am
Ende mit einem X markiert.
Nachrichten sind ein Kernelement von Sequenzdiagrammen. Sie werden zwischen den Objekten
gesendet und illustrieren den Kontrollfluss zwischen den Objekte, ihre Interaktionen und die Bedingungen, die den Fluss steuern. Wenn ein Objekt einen Prozess eines anderen Objekts anstoßen
will, oder Informationen an ein anderes Objekt übergeben will, so werden Nachrichten verwen-
16
det. Nachrichten können auch Bedingungen enthalten, diese werden mit eckigen Klammern an
der Nachricht mit angegeben. Erst bei einer Erfüllung der Bedingung, wird die zugehörige Nachricht an das andere Objekt gesendet. Bedingungen werden jedoch im Rahmen unsers Projekts
nicht genauer betrachtet, da diese keinen Informationsmehrwert für das Projekt bieten.
Für Sequenzdiagramme gibt es drei möglich Nachrichtentypen:
synchrone Nachrichten zeigen an, dass der Kontrollfluss solange nicht unterbrochen wird, bis
die ausgehende Nachricht, oder bis alle von der ausgehenden Nachricht angestossenen
Nachrichten beendet worden sind. Bei der Verwendung ist es dem Entwickler wichtig,
dass erst eine Nachricht abgearbeitet wird, bis der Kontrollfluss fortgesetzt werden darf.
Synchrone Nachrichten werden als ein durchgehender Pfeil mit einer schwarzen ausgefüllten Pfeilspitze dargestellt.
asynchrone Nachrichten werden benutzt, wenn das aktive Objekt nicht auf eine Antwort warten muss um den Kontrollfluss fortzusetzen. Ein Beispiel wären Schreibaktionen in eine
LOG-Datei. Asynchrone Nachrichten werden als ein durchgehender Pfeil mit einer halben
offenen Pfeilspitze dargestellt.
Rückgabe-Nachrichten zeigen an, dass die synchrone Nachricht abgearbeitet wurde und der
Kontrollfluss zu dem aufrufenden Objekt zurückgekehrt ist. Sie werden als gestrichelter
Pfeil mit einer offenen Spitze dargestellt.
Eine zusätzliche Möglichkeit in Sequenzdiagrammen ist die Erstellung von neuen Objekten
während des Kontrollflusses. Ein Anwendungsfeld wäre die Darstellung von Fehler- oder Nachrichtenfenstern, welche kurz angezeigt werden um dann wieder geschlossen und beendet zu werden. Hierfür werden zwei spezielle Nachrichtentypen verwendet.
create-Nachricht Ein neues Objekt wird mit einer << create >>-Nachricht auf das neue Objekt erstellt. Von diesen Zeitpunkt an können Nachrichten an das Objekt gesendet werden.
destroy-Nachricht Wird das Objekt nicht mehr benötigt, so kann es mit einer << destroy >>Nachricht wieder zerstört werden. Am Ende der Schwimmlinie des erstellten Objekts steht
nun, wie gewohnt, ein X. Vergleich Sie hierzu Abbildung 2.7.
Bei der Modellierung von Sequenzdiagrammen wird besonders auf den zeitlichen Verlauf der
Nachrichten geachtet. Dabei sollen die senkrechten Schwimmlinien diesen Verlauf hervorheben
und die Zusammenarbeit der Objekte illustrieren. Im Gesamtkontext des Modellierungsprozesses beschreiben Nachrichten einzelne Methoden eines Klassendiagramms und beziehen sich auf
einen konkreten Ablauf in einem Anwendungsfall.
17
Abbildung 2.7: Create und Destroy Beispiel
2.2.4
Zustandsdiagramme
Objekte können in ihrer Lebenszeit verschiedeneartige Zustände annehmen. Zustandsdiagramme
visualisieren diese Zustände und Ereignisse, welche zu Zustandsänderungen des Objekts führen.
Damit beschreibt ein Zustandsdiagramm einen endlichen Automaten, der sich zu jedem Zeitpunkt in einer Menge von endlichen Zuständen befindet. Zustandsdiagramme bestehen aus:
einem Anfangszustand
einer endlichen Menge von Zuständen
einer endlichen Menge von Ereignissen
einer endlichen Anzahl von Transitionen, die den Übergang des Objekts von einem zum
anderen Zustand beschreiben
einem oder mehreren Endzuständen
Diese Notationselemente eines Zustandsdiagrammes werden nun näher erläutert:
Zustand Ein Zustand ist eine endlichen nicht-leere Menge von Attributwerten, die die Objekte
einer Klasse annehmen können. Er gehört genau zu einer Klasse und kann in Zustandsdiagrammen durch drei Notationselemente dargestellt:
1. Normale Zustände
2. Startzustand
3. Endzustand
18
Jeder Zustand ist mit einem eindeutigen Namen definiert. Existiert ein weiterer Zustand mit
dem gleichen Namen, so beschreiben beide den selben Zustand eines Objekts. Zusätzlich
werden Zustände durch eine endliche Menge von Zustandsvariablen gekennzeichnet. Diese repräsentieren einen Teil der Klassenattribute des Objekts zu dem der Zustand gehört. Es
ist möglich spezielle Aktionen an Zustände zu binden, die bei bestimmten Zustandsänderungen, z.B. bei Erreichen oder Verlassen des Zustands, ausgelöst werden können. Da diese
Möglichkeit nicht viel Potenzial für die Fortschrittsmessung bietet, wird in der Ontologie
auf die Abbildung dieser Möglichkeiten verzichtet.
Ein Zustand beschreibt immer eine Zeitspanne zwischen zwei Ereignissen, wobei eine Attributänderung, die das Objekt maßgeblich verändert, einen Zustandsübergang auslöst.
Start- und Endzustände sind dabei besonders hervorzuheben, da ein Startzustand eines
Objekts keine eingehenden, sondern nur ausgehenden Transitionen, wobei der Endzustand
nur eingehenden und keine ausgehenden Transitionen erlaubt.
Zustände werden als ein Rechteck mit abgerundeten Ecken dargestellt, der Name des Zustands wird im Rechteck angezeigt. Ein Startzustand wird als ausgefüllter Kreis dargestellt.
Ein Endzustand wird mit einem kleineren ausgefüllten Kreis und einem zusätzlichen äusseren Ring dargestellt.
Oberzustand Ein Oberzustand beinhaltet eigene Zustände, Oberzuständen, Ereignissen und
Transitionen, kann jedoch mit anderen Zuständen Transitionen besitzen. Er beschreibt
einen Zustand, der durch weitere Zustände näher erläutert wird. Die Notation ist gleich
der von Zuständen, jedoch werden in dem Oberzustand selber weitere Zustände, Transitionen, usw. abgebildet.
Ereignis, Transition Ereignisse zeigen an, wie Zustände erreicht werden und wodurch Übergänge
ausgelöst werden. Ein Ereignis besteht aus einem Namen und einer Liste von möglichen
Argumenten. Zustandswechsel können zwei Ursachen haben:
1. Eine, für eine Transition definierte, Bedingung wird erfüllt.
2. Das Objekt erhält eine Nachricht.
Normalerweise reicht ein Ereignis, dessen Name auf den Pfeil zwischen den Zuständen
notiert wird, für einen Zustandswechsel aus. Existiert jedoch ein Ereignis ohne Namen,
so wird der Zustandsübergang automatisch ausgelöst, sobald eventuelle Aktionen des Zustands durchgeführt worden sind. Es können auch Bedingungen an Ereignisse gestellt werden. Dabei wird ein Zustandsübergang erst bei der Erfüllung der Bedingung ausgeführt.
Bedingungen können auch unabhänig von einem Ereignis an einem Zustandsübergang ge-
19
stellt werden.
Transitionsbeschreibungen werden in folgender Form über den Pfeilen dargestellt:
ereignis(argumente) [bedingung] / operation(argumente).
2.3
XMI: Dirk Siemers
Mit Hilfe von XML Metadata Interchange (XMI) lassen sich alle Modelle, die auf ein MOF
Metamodell basieren durch XML (eXtensible Markup Language) darstellen. Das XML-Format
wird dabei in einem Body und einer Document Type Definition (DTD) unterteilt, wobei die DTD
die Struktur des Bodies angibt. Das Format ist frei zugänglich und keinem speziellen Anbieter
zugeordnet.
Der eigentliche Aufbau von XMI besteht in der Generierung von XML-Vokabularen mit Hilfe eines standardisierten Formalismus. Dabei können sowohl DTDs, als auch XML Schema (ab XMI
Version 2.0) erzeugt werden. In der Standartdefinition von XMI sind bereits die Vokabulardefinitionen für die Darstellung von UML-basierter Modelle und die Definition zur Codierung von
Metamodellen gemäß dem MOF-Standart enthalten. Damit lassen sich nicht nur UML-Modelle,
sondern auch beliebige Metadaten beschreiben, solange sich diese mit Hilfe der MOF ausdrücken
lassen.
Die aktuellste Version der XMI ist die Version 2.1, welche am 01.09.2005 veröffentlicht wurde.
Wir nutzen in unserem Projekt jedoch eine älter XMI-Version (XMI Version 1.2), da das verwendeten CASE-Werkzeug Poseidon keine anderen Möglichkeiten anbietet. Durch die Nutzung des
XML-Formats können die exportierten Modelle einfacher erzeugt, verwaltet, durchsucht oder,
wie in unserem Fall weiterverarbeitet bzw. umgewandelt werden.
Die eigentliche Technologie hinter XMI ist XML. Um auf den Aufbau eines XMI-Dokuments
eingehen zu können, wird zunächst ein allgemeiner Überblick über die Thematik XML hergestellt. Dabei wird sowohl auf den Aufbau eines XML-Dokuments, als auch auf dessen Definition
eingegangen.
2.3.1
eXtensible Markup Language
Die eXtensible Markup Language (XML) ist eine Metasprache zur Definition von Dokumenttypen. Die Idee von XML ist es, Dokumente zu erstellen, die in ihrem Aufbau gewissen Grundmustern folgen. Regeln für diese Gemeinsamkeiten werden unabhängig von den eigentlichen
Daten in einer Document Type Definition (DTD) festgelegt. Dieser Zusammenhang soll anhand
eines Beispiels näher erläutert werden.
Hier ein Beispiel für eine XML-Datei:
20
<? xml v e r s i o n =” 1 . 0 ” e n c o d i n g =”UTF 8” ?>
< !DOCTYPE B u c h h a n d l u n g SYSTEM ” B u c h h a n d l u n g . d t d ” >
< ! D i e s i s t e i n Kommentar >

<Buch i d =” 1 ” >
< T i t e l>P e r A n h a l t e r d u r c h d i e
< A u t o r> D o u g l a s Adams< / A u t o r>
<ISBN>&keineISBN ;< / ISBN>
< / Buch>
<Buch i d =” 2 ” >
G a l a x i s< / T i t e l >
...
< / Buch>

Die Grundstruktur jedes XML-Dokuments besteht aus einem Prolog, gefolgt von ineinander geschachtelten Container-Elementen, dem Inhalt des Dokuments. In dem Beispiel besteht der Prolog zunächst aus einer XML-Deklaration, in welcher die Version und die Kodierung des XMLDokuments festgelegt wird. Hier wird XML in der Version 1.0 mit der UNICODE-Kodierung
UTF-8 verwendet. Die zweite Zeile bietet Informationen über die DTD, die die Struktur des
Dokuments festlegt. Hinter dem Befehl DOCTYPE wird der Wurzelknoten des Dokuments festgelegt, hier “Buchhandlung“, es folgt der Befehl SYSTEM nachdem dann die URI der DTD in
Anführungszeichen angegeben wird.
XML-Dokumente bestehen aus Elementen, die mit einem Start- und einem End-Tag gekennzeichnet werden. Der eigentliche Inhalt des Dokuments steht zwischen den Tags, oder innnerhalb
dieser Tags als Attribute. Ein Element beginnt mit einem Start-Tag, welches aus einer öffnenden
spitzen Klammer (<), gefolgt von dem Namen des Elements, besteht. In dem Start-Tag können
nach dem Namen noch Attribute des Elements, mit Freizeichen getrennt, angegeben werden. Geschlossen wird der Start-Tag mit einer schließenden spitzen Klammer (>). Nach dem Start-Tag
werden die Informationen des Elements angegeben. Das Element wird mit einem End-Tag ähnlich dem Start-Tag geschlossen. Das End-Tag besteht aus einer öffnenden Spitzen Klammer mit
einem Schrägstrich, um das Ende des Elements zu markieren (</), es folgt nochmals der Name des Elements mit einer abschließenden spitzen Klammer. End-Tags besitzen keine Atribute.
Start- und End-Tags können ineinander verschachtelt werden, jedoch ist dabei zu beachten, dass
das letzte Start-Tag vor einem übergeordnetem Start-Tag geschlossen wird. Diese Eigenschaft
beschreibt die Wohlgeformtheit (wellformedness) eines XML-Dokuments.
Die möglichen Tags und Attribute werden in der DTD eines XML-Dokuments festgehalten. Die
21
Reihenfolge der Vereinbarungen hat keine Bedeutung, sie müssen jedoch vollständig sein. So
kann überprüft werden kann, ob das Dokument nicht nur wohlgeformt, sondern auch gültig (valid) ist. Für das obige Beispiel ist die folgende DTD definiert:
<!ELEMENT Buchhandlung (Buch+)>
<!ELEMENT Buch (Titel,Autor,ISBN)>
<!ATTLIST Buch id ID #REQUIRED>
<!ELEMENT Titel (#PCDATA)>
<!ELEMENT Autor (#PCDATA)>
<!ELEMENT ISBN (#PCDATA)>
<!ENITY keineISBN "Keine ISBN vorhanden">
Für die DTD gibt es nur wenige Schlüsselwörter. Das wichtigste ist der Tag
<!ELEMENT Name (#Wert)>
Mit diesem Tag werden die Elemente definiert, die in einem XML Dokument verwendet werden
dürfen. Dabei wird auch ihre Häufigkeit und Struktur definiert. In dem Beispiel gibt es in der
Buchhandlung mindestens 1 bis mehrere Bücher (ausgedrückt durch das + hinter dem Element
“Buch“), die genau einen Titel, einen Autor und eine ISBN besitzen. Um die Attribute eines
Elements zu definieren, wird das Schlüsselwort
<!ATTLIST Elementname Attributliste>
verwendet. Bücher müssen in unserem Beispiel eine ID besitzen (ausgedrückt durch die Anweisung #REQUIRED). Das Attribut ID ermöglicht es in dem XML zu bestimmen, dass jedes Buch
eine eindeutige ID besitzt, mit der es refenziert werden kann. Eine Entity
<!ENTITY Referenzname Ersetzung>
beschreibt eine einfache Abkürzung, die durch einen definierten Text im XML Dokument ersetzt
wird. In dem Beispiel wird so die ISBN für das Buch auf den Wert keine ISBN vorhanden gesetzt.
Nachdem nun der grobe Aufbau eines XML-Dokuments und dessen DTD beschrieben wurde,
wird im folgenden Abschnitt auf den Aufbau einer XMI-Datei eingegangen. Dabei werden exemplarisch verschiedene Strukturen aus UML-Diagrammen mit XMI abgebildet.
2.3.2
Aufbau einer XMI Datei
Wie jedes XML-Dokument hat auch das XMI eine DTD. Die OMG (Object Management Group)
bietet für die UML-Version 1.4 die komplette DTD im Internet unter der Adresse
http://www.omg.org/docs/ad/02-05-02.dtd zu finden. Hier der DTD-Kopf für XMI der UMLVersion 1.4:
<!
>
22
<!
<!
<!
XMI i s t h e t o p l e v e l XML e l e m e n t f o r XMI t r a n s f e r t e x t
< !ELEMENT XMI
< ! ATTLIST
>
>
>
(XMI . h e a d e r ? , XMI . c o n t e n t ? , XMI . d i f f e r e n c e ,
XMI . e x t e n s i o n s )>
XMI
xmi . v e r s i o n CDATA #FIXED ” 1 . 1 ”
t i m e s t a m p CDATA #IMPLIED
v e r i f i e d ( t r u e j f a l s e ) #IMPLIED>
An dem Kopf der DTD kann man gut erkennen, dass ein XMI-Dokument in vier Teile unterteilt
ist XMI.header?, XMI.content?, XMI.difference*, XMI.extensions*. Die
Fragezeichen hinter dem Header und dem Content beschreiben, dass es genau einen Header
bzw. Content gibt, oder gar keinen (0..1). Die Sternchen hinter Difference und Extensions geben an, dass es null bis mehrere von diesen Elementen in einem XMI geben darf. Desweitern
werden die Elemente version timestamp und verified als Attribute an ein XMI-Dokument gestellt. Die von Poseidon aus den UML-Diagrammen extrahierten XMI-Dokumente beinhalteten
immer nur einen Header und den Content, daher werden genau diese Elements nun an einem
XMI-Dokument näher erläutert.
<? xml v e r s i o n = ’ 1 . 0 ’ e n c o d i n g = ’UTF 8 ’ ?>
<XMI xmi . v e r s i o n = ’ 1 . 2 ’ xmlns:UML = ’ o r g . omg . xmi . n a m e s p a c e .UML’
t i m e s t a m p = ’Mon Sep 15 09 : 0 1 : 4 3 GMT 2005 ’>
<XMI . h e a d e r>
<XMI . d o c u m e n t a t i o n>
<XMI . e x p o r t e r> N e t b e a n s XMI W r i t e r< / XMI . e x p o r t e r>
<XMI . e x p o r t e r V e r s i o n> 1 . 0< / XMI . e x p o r t e r V e r s i o n>
< / XMI . d o c u m e n t a t i o n>
< / XMI . h e a d e r>
<XMI . c o n t e n t>
<!
H i e r s t e h t d e r I n h a l t e i n e s XMI Dokuments
< / XMI . c o n t e n t>
< / XMI>
>
23
Abbildung 2.8: Eine Klasse, erstellt mit Poseidon 2.6
Wie jedes XML-Dokument beginnt auch das XMI mit dem XML-Kopf, d.h. der Definition von
XML-Version und der Kodierung. Es folgt das XMI-Element mit den Attribute XMI-Verision, Erstellungszeitpunkt und Namespace der XMI-Datei. Der Namespace ordnet dabei alle Elemente
in dem XMI genau der von der OMG erstellten DTD zu. Ein Namespace ist wichtig, da beliebige Variablennamen für Tags definiert werden können, wobei nur der Namespace die universelle
Eindeutigkeit von Elementen und Attributen garantiert.
Der XMI-Header ist ein Platzhalter für Informationen über das Modell. Das darauf folgende
Child-Element ist die “Documentation“. Hier können Informationen über Eigentümer und Exporter bzw. Exporterversion festgelegt sein. Der eigentliche Inhalt bzw. das Modell wird in dem
Element “Content“ beschrieben. Der Zusammenhang zwischen dem in der UML-Modell und
dem davon exportierten XMI-Content lässt sich anhand eines Beispiels am einfachsten erläutern.
Der folgende XMI-Code bezieht sich auf Abbildung 2.8. Diese beschreibt eine einfache Klasse
mit 2 Attributen und 2 Methoden, welche mit dem UML-Tool Poseidon hergestellt wurde.
<UML:Model
xmi . i d = ’ sm$ e 2 5 8 0 e : 1 0 6 a 6 5 b 9 4 7 a : 7 f f e ’
name = ’ M o d e l l 1 ’ i s S p e c i f i c a t i o n = ’ f a l s e ’
i s R o o t = ’ f a l s e ’ i s L e a f = ’ f a l s e ’ i s A b s t r a c t = ’ f a l s e ’>
<UML:Namespace . ownedElement>
<UML:Class
xmi . i d = ’ sm$ e 2 5 8 0 e : 1 0 6 a 6 5 b 9 4 7 a : 7 f f d ’
name = ’ F e n s t e r ’ v i s i b i l i t y = ’ p u b l i c ’
i s S p e c i f i c a t i o n = ’ f a l s e ’ isRoot = ’ f a l s e ’
i s L e a f = ’ f a l s e ’ i s A b s t r a c t = ’ f a l s e ’ i s A c t i v e = ’ f a l s e ’>

<!
>
24
H i e r s t e h e n d i e A t t r i b u t e und Methoden / O p e r a t i o n e n
<n U M L : C l a s s i f i e r . f e a t u r e >
< / UML:Class>
<UML:Namespace . ownedElement>
< / UML:Model>
Bei diesem Beispiel handelt es sich um ein Klassendiagramm, welches eine eindeutige ID über
das Attribut “xmi.id“ bekommt. Der Name des Diagramms ist “Modell 1“. Der Inhalt des Diagramms wird nach dem Element “UML.Namespace.ownedElement“ untergebracht. In diesem
Fall befindet sich dort nur ein Element, nämlich die modellierte Klasse “Fenster“, wie man an
dem Attribut “name“ des Elements “UML.Class“ sehen kann. Mit dem Attribut “visibility“ wird
die Zugriffsbeschränkung der Klasse festgehalten. Attribute und Methoden einer Klasse werden in dem Element “UML.Classifier.feature“ untergebracht. Attribute werden folgendermassen
beschrieben:
<U M L : A t t r i b u t e
xmi . i d = ’ sm$ e 2 5 8 0 e : 1 0 6 a 6 5 b 9 4 7 a : 7 f f c ’
name = ’ f a r b e ’ v i s i b i l i t y = ’ p r i v a t e ’
i s S p e c i f i c a t i o n = ’ f a l s e ’ ownerScope = ’ i n s t a n c e ’
c h a n g e a b i l i t y = ’ c h a n g e a b l e ’>

<UML:Class xmi . i d r e f = ’sm$ e 2 5 8 0 e : 1 0 6 a 6 5 b 9 4 7 a : 7 f f b ’ />


Wie in jedem XMI-Element, wird auch dem Atrtibut eine eindeutige ID (xmi.id) zugewiesen.
Neben dieser ID werden der Name des Attributs (farbe) und die Zugriffsbeschränkung (private)
beschrieben. Das Child-Element “UML.StructuralFeatrue.type“ ordnet das Attribut über die eindeutige ID (xmi.idref) der Klasse Fenster zu. Diese beiden Beispiele zeigen nur einen kleinen
Teil einer kompletten XMI Datei. Zu den inhaltlichen Informationen eines Diagramms werden
in Poseidon weiter Informationen zur Positionierung der Elemente gespeichert. Diese Informationen sind für uns nicht von Bedeutung und werden auch in der XSL Transformation nicht
berücksichtigt.
2.4
25
Ontologien : Stephan große Austing
In diesem Abschnitt wird der Begriff der Ontologie erläutert und es werden verschiedene Definitionen angeführt. Hierbei werden auch Anwendungsbeispiele benutzt und insbesondere wird auf
allgemeine Eigenschaften von Ontologiesprachen eingegangen. Es folgt eine Einführung in die
Ontologiesprachen RDF Schema und OWL, wobei die Verbindung zu den allgemeinen Eigenschaften hergestellt wird. Des Weiteren erfolgt eine Erläuterung der Bedeutung von Ontologien
für das Semantic Web. Die vorgestellten Technologien sind grundlegender Bestandteil dieses
Projektes und werden in der Software Rose verwendet.
2.4.1
Ontologiebegriff in der Informatik
Der Begriff Ontologie“ ist ein aus der Philosophie entlehnter Begriff. Er bezeichnet die Leh”
re vom Wesen des Seins an sich. Für informationsverarbeitendende Systeme lässt sich die Frage
nach dem Sein mit der Frage nach dem Darstellbaren übersetzen. So wird z.B. für eine Datenbank
durch ein Datenbankschema festgelegt, welche Werte in dieser stehen können. Dies schränkt die
Möglichkeiten des Darstellbaren explizit ein. Durch die Art einer Datenhaltung wird meistens
implizit festgelegt, welche Inhalte oder Konzepte dargestellt werden können. Dieser impliziten
Festlegung steht der Ontologiebegriff der Informatik gegenüber. Der wesentlich Aspekt von Ontologien in der Informatik ist die explizite Formalisierung der Konzepte und in welchem Verhältnis sie stehen können. Die Gestaltung dieses Begriffes zielt im Wesentlichen auf die Verwendung
im Bereich der Wissenrepräsentation ab. Ontologien sind hierbei ein Hilfsmittel um Wissen in
einer Organisation durch Informationssysteme erfassen zu können. Das Ziel einer Ontologie ist
ein einheitliches Verständnis durch die Softwaresysteme, als auch durch die mit den Systemen
arbeitenden Menschen.
Ontologien wurden zunächst im Bereich der künstlichen Intelligenz entwickelt um den Austausch von Wissen zu ermöglichen. In den 90er Jahren wurden sie zu einem beliebten Forschungsthema, nicht nur in diesem Bereich. Jedoch wurden auch sehr unterschiedliche Verständnisse von dem Begriff der Ontologie entwickelt. Eine knappe und allgemein akzeptierte Definition von Ontologie ist
An ontology is an explicit specification of a conceptualization.
[Gru93b] Eine solche Spezifikation kann nach Bunge z.B. durch Festlegung einer Menge von Begriffen erfolgen. Diese Begriffe verknüpft eine Ontologie mit menschenlesbaren Beschreibungen
des Gemeinten und formalen Axiomen, die die Interpretation und den Gebrauch der Begriffe einschränken. Diese Einschränkungen sollen verhindern, dass durch die unterschiedlichen Sichten
26
der beteiligten Systeme und Menschen ein nicht kongruentes Verständnis der Begriffe entsteht.
Die Begriffe einer Ontologie werden zumeist als Klassen bezeichnet. Die Zugehörigkeit von Objekten zu einer Klasse kann neben einer Beschreibung auch durch eine Aufzählung der Objekte
definiert werden. Einschränkungen zwischen Klassen werden auch als Regeln oder Relationen
bezeichnet. Sie können auch in natürlichsprachiger Form vorliegen. Eine Ontologie bezieht sich
in fast jedem Fall auf ein bestimmtes Anwendungsgebiet. Dieses wird als Domäne (Domain) der
Ontologie bezeichnet. Eine Ontologie sollte alle wesentlichen Begriffe der Domäne umfassen.
Sie kann dann als Vermittlungsschicht zwischen den beteiligten Systemen in der Domain benutzt
werden, wie in dem folgenden Beispiel:
ATOS In der Weltraumfahrt wurden viele verschiedene wissensbasierte Systeme eingesetzt um
den Status eines Weltraumfahrzeuges zu überwachen und zu kontrollieren. Diese Systeme
wurden zumeist unabhängig voneinander entwickelt und besitzen unterschiedliche Ansätze
zur Repräsentation der benötigten Informationen. Es war nicht wünschenswert einen gemeinsamen Ansatz für alle Systeme vorzugeben.
Um den Austausch von Informationen der Systeme untereinander und die Nutzung durch
höhere Systeme zu ermöglichen musste eine Austauschplattform entwickelt werden. In
dem durch die ESA betriebenen Projekt ATOS (Advanced Technology Operations Systems) wurden Softwareagenten für die Systeme entwickelt, die auf Basis einer gemeinsamen Ontologie miteinander kommunizieren. Dieses sollte ebenfalls die Wiederverwendbarkeit der Softwarekomponenten verbessern. [UG96]
In dem vorherigen Beispiel wurde eine Ontologie in maschinenlesbarer Form erstellt. Jedoch kann eine Ontologie auch in wesentlich weniger formeller Form vorliegen. Uschold und
Grüninger[UG96] unterscheidet zwischen vier Stufen der Formalisierung für explizite2 Ontologien. Im Bereich dieses Projektes wird von formellen, maschinenlesbaren Ontologien ausgegangen. Diese werden durch natürlichsprachige Beschreibungen ergänzt.
Welcher Grad von Formalisierung notwendig ist, hängt von der Komplexität der Domäne und der
Anzahl von unterschiedlichen Sichten auf die Domäne durch verschiedene Systeme und Menschen ab. Eine formelle Definition ist auf jeden Fall notwendig, wenn Softwareinformationssysteme auf den Ontologien arbeiten sollen. Dies zeigt auch das folgende Beispiel:
Produktontologie Bei der Zusammenlegung von Unternehmen derselben Industrie kommt es
zu Überschneidungen zwischen den Produkten der beiden Unternehmen. Wenn z.B. ein
2
Die Autoren sprechen in ihrem Artikel auch von impliziten Ontologien. Hiermit sind jedoch weniger Ontologien
in der Informatik gemeint.
27
Fotofinisher (Entwicklung von Fotos) einen Mitbewerber übernimmt, so kann eine Zusammenführung der Produktportfolios sinnvoll sein. Die Produkte werden sich aber oftmals unterscheiden, z.B. in Format, Papierqualität und Entwicklungszeit. Hier kann die
Erstellung einer Ontologie für die Entwicklung eines Abrechnungssystems in Verbindung
mit einer Bereinigung des Produktportfolios die Zusammenführung ermöglichen.
Ähnliche Probleme kann es bei automatisierten Bestellungen geben. MRP3 -Systeme können
nicht immer das benötigte Produkt in dem Angebot des Zulieferers identifizieren. An dieser Stelle könnten Softwareagenten die Zusammenarbeit zwischen den beiden Systemen
ermöglichen. Grundlage hierfür ist eine gemeinsame Ontologie für alle gehandelten Produkte und Dienstleistungen.
Ontologien werden oft mit taxonomischen4 Hierarchien von Klassen verglichen. Jedoch kann
eine Ontologie aus wesentlich komplexeren Regeln als Klassenzugehörigkeit ( a ist Instanz von
”
Klasse A“) oder Hierarchie ( A ist Oberklasse von B“) bestehen. Allgemein ist jede Form von
”
Regel denkbar, die eine Einschränkung im Gebrauch und Interpretation bewirkt. Es können z.B.
auch Regeln existieren, die die Anzahl der Objekte einer Klasse beschränken oder auch von der
Anzahl der Objekte einer anderen Klasse abhängig machen. Vgl. hierzu: [Gru93a].
2.4.2
Eigenschaften von Ontologiesprachen
Ontologien können mit Hilfe von speziellen Sprachen ausgedrückt werden. Im folgenden wird
eine formale Definition der Struktur einer Ontologiesprache durch Stuckenschmidt[SvH04] behandelt. Stuckenschmidt bezeichnet eine Ontologie auch als terminologische Wissensbasis.
Terminologische Wissensbasis. Eine Terminologische Wissensbasis ist ein Tripel =
hC; R; Oi;
(2.1)
wobei C eine Menge von Klassendefinitionen, R eine Menge von Relationendefinitionen und O
eine Menge von Objektdefinitionen ist.
Eine Ontologiesprache besteht aus drei Elementen, wobei Objekte zunächst keine Elemente
einer Ontologie im eigentlichen Sinn sind. Klassen oder auch Begriffe können durch Axiome
beschrieben werden
3
Material Requirement Planning: Materialbedarfsplanung
Eine Taxonomie ist eine Einteilung von Dingen in Gruppen. Bekanntes Beispiel hierfür ist die Einteilung des
Tierreichs. Hier liegt ebenfalls eine hierarchische Taxonomie durch die Stufen (Familie, Gattung, Art, etc.) vor.
4
28
Klassendefinitionen. Eine Klassendefinition ist ein Axiom von einer der folgenden Formen:
c (o ; :::; on), wobei c eine Klassendefinition und o ; :::; on Objektdefinitionen sind.
c v c , wobei c und c Klassendefinitionen sind.
Des Weiteren, gibt es die universelle Klasse >.
1
1
1
2
1
2
Die Äquivalenz einer Klassendefinition mit einer Menge von Objektdefinitionen kann über
die Beschreibung von gemeinsamen Eigenschaften ausgedrückt werden. Wie die Beschreibung
dieser Eigenschaften aussehen kann ist von Sprache zu Sprache sehr unterschiedlich. So wäre
z.B. für die Klasse Stadt als gemeinsame Eigenschaft mehr als 2000 Bewohner denkbar. Des
Weiteren können auch alle zugehörigen Objekte aufgezählt werden.
Der zweite Punkt zielt auf die Bildung von Ober- und Untergruppen ab. So kann die Menge der
europäischen Städte als Untermenge von allen Städten gebildet werden. Ergänzend kann dies
auch durch die Eigenschaft liegt in Europa geschehen, falls Kontinente Teil der Ontologie sind.
Relationdefinition. Eine Relationdefinition ist ein Axiom von einer der folgenden Formen:
r v (c ; c ), wobei r eine Funktionsdefinition und c und c
r v r , wobei r und r Funktionsdefinitionen sind.
Die universelle Rolle ist definiert als > >.
1
1
2
2
1
1
2
Klassendefinitionen sind.
2
Objekte der selben Klassen haben meistens ähnliche Beziehungen zu anderen Klasseninstanzen. So liegt z.B. eine Stadt innerhalb eines Landes und ein Bewohner lebt in einer bestimmten
Stadt. Mit einem Axiom der ersten Form kann ausgedrückt werden, dass zwischen jeweils einer
Instanz der Klassen c1 und c2 eine Funktion bzw. Rolle r bestehen kann. So kann, wenn Bewohner die Klasse c1 und Stadt die Klasse c2 sind, eine Relation r wohnt in definiert werden.
Diese Relationen sind binär, gerichtet und werden durch c1 in ihrem Grundbereich (domain) und
durch c2 in ihrem Zielbereich (Range) eingeschränkt. Mit dem zweiten Axiom kann ausgedrückt
werden, dass eine Relation eine Unterrelation einer bestehenden ist. Sie ist z.B. die Relation ist
Nachfahre von eine Unterrelation von ist verwandt mit.
Objektdefinition. Eine Objektdefinition ist ein Axiom von einer der folgenden Formen:
o : c, wobei c eine Klassendefinition und o ist ein Individuum ist
(o1 ; o2 ) :
r, wobei r eine Relationdefinition und o1 ; o2 Objektdefinitionen sind.
29
Für Ontologiesprachen ist es manchmal nicht hinreichend nur die Konzepte der Domäne
darzustellen. So kann es sinnvoll sein, einige Objekte innerhalb der Ontologie zu definieren.
Dies kann z.B. ein Land sein. Dies ist wichtig, falls die Zugehörigkeit zu einer Klasse über eine
Relation definiert ist. So kann die Klasse der französischen Städte über die Relation liegt in zum
Objekt Frankreich definiert werden. In der ersten Form wird ein Objekt über die Zugehörigkeit
zu einer Klasse definiert.
Die zweite Form ermöglicht das Einbringen von Relationeninstanzen in eine Ontologie. Hierzu
muss nur über zwei Objekte ausgesagt werden, dass die Relation r zwischen ihnen besteht.
2.4.3
RDF (Resource Description Framework)
Im folgenden soll auf die Ontologiesprachen RDF Schema und OWL eingegangen werden.
Hierbei liegt der Schwerpunkt bei OWL, da es die grundlegende Technologie für das Projekt
Rose ist. RDF und RDF Schema werden angeführt, da sie die Grundlage für OWL bilden.
Das RDF (Resource Description Framework) ist eine Empfehlung des W3C (World Wide
Web Consortium) für ein Datenmodell5 zur Beschreibung von Metadaten im Internet. Die offizielle Empfehlung durch das W3C erfolgte im Februar 1999. Die Spezifikationen sind unter
http://www.w3.org/RDF/ verfügbar. RDF ist an keine Notation gebunden und kann sowohl durch eine XML-Syntax, eine 3-Tupel-Notation, einen Graphen oder eine andere Darstellungsform repräsentiert werden. Am gebräuchlisten ist sicherlich die Verwendung der XMLSyntax. Zur Anschaulichkeit wird aber im folgenden eine Graphenrepräsentation benutzt.
RDF basiert auf drei wesentlichen Konzepten: Resources, Properties und Statements.
Resources Durch eine Resource kann ein Ding, eine Sache repräsentiert werden. Dies kann z.B.
ein Ort, eine Person, eine Adresse, eine schriftliche Ausarbeitung, eine Aufgabe oder ein
Ereignis sein. Jede Resource wird durch eine URI (Uniform6 Resource Identifier) identifiziert. Eine URI ist eine Zeichenfolge, die meist in einer URL(Unified Resource Locator)ähnlichen Form vorliegt. Dieses Dokument könnte z.B. mit der URI http://www.informatik.unioldenburg.de/ rose/ausarbeitung beschrieben werden. Im Gegensatz zur URL wird jedoch
nicht der Ort der Resource beschrieben. Wenn man diese URI in einem Webbrowser eingibt, gibt es keine Garantie, dass unter dieser Adresse ein Dokument zu finden ist. Eine
genaue Beschreibung der Syntax einer URI ist durch das W3C spezifiziert worden. Jedoch
reicht für diese Einführung in RDF die Vorstellung, das eine bestimmte Sache eindeutig
identifiziert wird.
5
6
In dieser Ausarbeitung wird von RDF auch als Sprache gesprochen, obwohl dies formal nicht korrekt ist.
In älteren W3C Dokumenten wird als Auflösung auch Universal Resource Identifier verwendet.
30
Abbildung 2.9: Graphenrepräsentation eines Statements
Properties Properties (Eigenschaften) sind Resourcen, die eine Beziehung zwischen zwei Resourcen beschreiben. Ein Beispiel hierfür ist wurde erstellt von, welches eine Beziehung
zwischen einer Person und einer Website beschreiben kann. Weitere Beispiele sind ist Besitzer von, ist Autor von und Alter.
Statements Durch Statements werden Aussagen in Form eines Tripels (Resource, Property, Value) gemacht. Der Value kann sowohl eine Resource als auch ein atomarer Wert sein.
Der Datentyp eines Value kann durch Verweise auf externe Definitionen wie die XMLDatentypen bestimmt werden.
Der Tupel (“Peter Riebken“,“ist Autor von“, “http://www.riebken.de/uebermich.htm“) gibt
die Aussage wieder, dass Peter Riebken Autor des Dokuments uebermich.htm ist. Statement lassen sich oft als Subjekt-Prädikat-Objekt-Satz lesen. Doch auch für das Statement
(“Peter Riebken“, “Alter“, 34) ist die Aussage deutlich.
Statements lassen sich als gerichtete Graphen darstellen. Hierbei werden Resource und Value durch Knoten und die Property durch eine Kante dargestellt. 2.9 repräsentiert das vorher
verwendete Beispiel.
Resources, Properties und Statements sind nur das Grundgerüst von RDF. Ein sehr mächtiges Element ist Reification, das es erlaubt Statements über Statements zu machen. Für die XMLSyntax bietet RDF einige Vereinfachungen. So gibt es Container-Elemente (rdf:Bag, rdf:Seq,
rdf:Alt) um Mengen und Ordnungen zu beschreiben, rdf:resource um die Äquivalenz
von zwei Resources auszudrücken, rdf:type um die Art einer Resource zu bestimmen sowie
eine optionale abgewandelte Syntax. Auf die Einzelheiten der XML-Syntax von RDF kann an
dieser Stelle nicht eingegangen werden. A Semantic Web Primer“ [AvH04] bietet hierzu eine
”
Einführung.
2.4.4
RDF Schema
Mit Hilfe von RDF können Aussagen über Dinge getroffen werden, ohne jedoch Annahmen über
eine Domäne zu treffen. So können zwar beliebige Aussagen über bestimmte Personen getroffen
werden, jedoch nicht über Personen im Allgemeinen. Eine Aussage der Form “Nur Personen
31
können Autoren von Webseiten sein.“ ist nicht möglich. Entsprechend kann sind auch unsinnige
Statements wie “Peter Riebken ist Autor von Johann Frechen“ möglich. Um dies zu vermeiden
können Aussagen über Konzepte wie Person und Webseite durch RDF Schema formuliert werden, was es zu einer Ontologiesprache macht.
RDF Schema ist ein Vorschlag des W3C für eine Sprache zur Formulierung von Ontologien in
RDF. Die offizielle Empfehlung erfolgte im März 2000. Die formalen Spezifikationen sind unter
http://www.w3.org/TR/rdf-schema [BG00] verfügbar. Im folgenden werden die allgemeinen Eigenschaften einer Ontologie an RDF Schema aufgezeigt.
RDF Schema besitzt ein Klassenkonzept. Abstrakte Objekte wie Person können als Klasse definiert werden. Einzelne Instanzen wie z.B. Peter Riebken können durch das bereits erwähnte
rdf:type dieser Klasse zugeordnet werden. Dies entspricht dem ersten Punkt der Klassendefinition 2.4.2. Klassen werden durch die Aufzählung ihrer Instanzen definiert. Klassen können
als Unterklassen von bestehenden Klassen definiert werden. Dies entspricht dem zweiten Punkt
der Definition. rdfs:Class bildet die universelle Klasse >.
Beziehungen zwischen Klassen können durch rdf:Property ausgedrückt werden. Dies ist
die Oberklasse aller Properties. Durch rdfs:domain können die Klassen definiert, auf denen die Property angewendet werden kann. Durch rdfs:range wird definiert welche Values
für ein Statement mit der Property möglich sind. Will man z.B. ausdrücken, dass nur Menschen Autoren von Webseiten sein können, so wird zunächst “ist Autor von“ als Instanz von
rdfs:Property definiert. Als rdfs:domain wird Person und als rdfs:range Webseite festgelegt. Dies entspricht der Relationdefinition 2.4.2. Eine Unterrelation kann ebenfalls
durch rdfs:subPropertyOf definiert werden. Die universelle Relation > > ist durch
rdfs:Property gegeben.
Objektdefinitionen sind innerhalb von RDF Schema nicht möglich. Da Klassenzugehörigkeit explizit durch rdf:type und nicht über Relationen zu Objekten bestimmt werden kann, wäre
dies auch nicht sinnvoll. Instanzen von Klassen können nur innerhalb von RDF gebildet werden.
Die Grafik 2.10 verdeutlicht das Verhältnis zwischen RDF-Schema Klassen und RDF Resources.
Die in der Ontologie definierte Property “ist Autor von“ kann nur in dem durch rdfs:domain
und rdfs:range definierten Kontext in Statements verwendet werden. Eine umfassendere
Einführung in RDF Schema ist an dieser Stelle nicht möglich. Das Augenmerk lag auf den allgemeinen Eigenschaften einer Ontologiesprache, die für Klassen- und Relationendefinitionen
dargelegt wurden. Die verwendeten Konzepte finden sich in erweiterter Form in OWL wieder,
das auf RDF und RDF Schema aufbaut. In OWL können Objektdefinitionen Teil der Ontologie
sein.
32
Abbildung 2.10: Verhältnis RDF Schema zu RDF
2.4.5
OWL
Die Ausdrucksmöglichkeiten von RDF und RDF Schema sind in vielerlei Hinsicht beschränkt.
So bietet RDF nur Unterklassen zum Ausdruck von Mengenverhältnissen. Einige Aspekte einer
Domäne können so nicht repräsentiert werden, was in den folgenden Beispielen gezeigt wird.
Lokaler Wertebereich einer Property: Mit Hilfe von rdfs:range können alle Klassen
des Wertebereichs einer Property definiert werden. Es können jedoch keine Einschränkungen für bestimmte Unterklassen getroffen werden. So kann in einer Tierontologie die Property frißt auf Pflanzen und andere Tiere zeigen. Es ist jedoch nicht möglich für eine vegetarische Unterklasse den Wertebereich auf Pflanzen zu beschränken.
Disjunkte Klassen: In RDF Schema kann keine Disjunktivität zwischen zwei Klassen ausgedrückt werden. Z.B. ist es möglich Mann und Frau als Unterklassen von Mensch zu
definieren. Jedoch kann nicht ausgedrückt werden, dass keine Resource Instanz von beiden Klassen sein kann.
Des Weiteren können keine Klassen über einen Mengenausdruck mit den Mengenoperatoren Vereinigung, Schnitt oder Komplement gebildet werden.
Einschränkungen der Kardinalität: Es ist in RDF Schema nicht möglich Kardinalitätsbeschränkungen für Relationen festzulegen. Dies wäre aber z.B. sehr sinnvoll um auszu-
33
drücken, dass ein Mensch genau zwei Eltern hat.
Spezielle Eigenschaften von Properties: Properties können Eigenschaften wie Transitivität
( größer als“) und Symmetrie ( verwandt mit“) besitzen.
”
”
Diese Mängel an Ausdrucksmöglichkeiten führten zur Entwicklung von komplexeren Ontologiesprachen durch Forschungsgruppen des W3C. Zwei Sprachen, DAML-ONT und OIL,
entstanden, die später zu DAML+OIL vereinigt wurden. Diese Sprache bildete die Grundlage
für die Entwicklung einer standardisierten Ontologiesprache für das Web, die OWL (Web Ontology Language)7 . Die offizielle Empfehlung durch das W3C efolgte im Februar 2004. Die Spezifikationen sind unter http://www.w3.org/2004/OWL/ verfügbar. OWL wird in einer
XML-Syntax notiert, von der es verschiedene Variationen gibt; Da die RDF-basierende Syntax
sehr schwer lesbar ist, wurden vereinfachte Formen entwickelt. Im folgenden werden nur die
Sprachelemente vorgestellt ohne die XML-Notation zu erläutern. Eine Sprachbeschreibung mit
Notationsbeispielen findet sich in [AvH04].
Klassen OWL übernimmt das Klassenkonzept aus RDF Schema. owl:Class ist eine Unterklasse von rdfs:Class. Somit steht zur Bildung von Unterklassen rdfs:subClassOf zur
Verfügung. OWL bietet darüber hinaus einige zusätzliche Elemente für Mengenrestriktionen auf
Klassen:
7
owl:disjointWith kann benutzt werden um disjunkte Klassen zu bilden. Ein Objekt
kann nicht eine Instanz von beiden Klassen gleichzeitig sein. Dies ist z.B. sinnvoll für die
Klassen Mann und Frau.
owl:equivalentClass ist das Gegenteil hierzu. Jede Instanz der Klasse ist auch eine
Instanz der anderen Klasse.
Durch owl:complementOf kann das Komplement einer Klasse ausgedrückt werden.
Hierzu gehört jedes Objekt, das nicht Instanz der Klasse ist. So kann z.B. die Klasse Mann
als Komplement zur Klasse Frau ausgedrückt werden, wenn sich die Ontologie auf Menschen beschränkt.
Der Buchstabendreher in der Abkürzung OWL wird oftmals durch eine Anlehnung an die Eule aus Milnes Pu
”
der Bär“ begründet, die als einziges Tier im Wald ihren Name schreiben konnte, wobei sie jedoch im englischen
Original WOL“ statt OWL“ schrieb. Jedoch wurde die Abkürzung eher aus praktischen Gründen wie Aussprache
”
”
und Eignung für Logos gewählt.
34
owl:unionOf bietet die Möglichkeit eine Klasse als Vereinigung von ein oder mehr
Klassen zu bilden. Z.B. kann die Klasse Lebewesen als Vereinigung von Mensch, Tier und
Pflanze gebildet werden
Durch owl:intersectionOf kann eine neuen Klasse als Schnittmenge von zwei oder
mehr Klassen gebildet werden. Jedes Objekt, dass eine Instanz jeder genannten Klasse ist,
ist Instanz der neuen Klasse. So kann z.B. die Klasse aller Wahlberechtigten durch die
Schnittmenge der Bürger mit den Volljährigen gebildet werden.
Diese Elemente können beliebig kombiniert werden um eine neue Klasse zu bilden. Des Weiteren
gibt es die Möglichkeit mit owl:oneOf Klassen durch Aufzählung aller Instanzen zu bilden.
So lässt sich z.B. die Klasse aller Wochentage einfach bilden.
Properties OWL besitzt zwei Arten von Properties: Objektproperties (Object Properties) und
Datatypeproperties (Datatype Properties). Objektproperties drücken Relationen zu anderen Objekten aus, z.B. ist Autor von“. Datatypeproperties verbinden Objekte mit Werten eines be”
stimmten Datentyps. Z.B. kann einer Person ein Alter zugeordnet werden, das eine nicht negative
ganze Zahl sein muss. Der Name muss entsprechend ein String sein. OWL definiert selber keine
Datentypen sondern benutzt die XML Schema Datentypen.
Properties können verschiedene Eigenschaften zugeordnet werden. Bei den erläuternden Graphen ist die Property, die mit Hilfe der Eigenschaft gefolgert werden kann, gestrichelt gezeichnet.
owl:inverseOf erlaubt es, eine Property als Inverse“ einer anderen Property zu defi”
nieren. Falls eine Property von einem Objekt A auf ein Objekt B zeigt, so zeigt die inverse
Property von B auf A. Beispiele hierfür sind frißt“ und wird gefressen“ bzw. ist Autor
”
”
”
von“ und wurde geschrieben von“. Diese Eigenschaft gilt entsprechend auch umgekehrt.
”
Abbildung 2.11: owl:inverseOf
35
owl:EquivalentProperty beschreibt die Äquivalenz von zwei Properties. Falls eine Property von einem Objekt A auf ein Objekt B zeigt, so zeigt auch die äquivalente
Property von A auf B . Beispiel hierfür ist frißt“ und kann gefüttert werden mit“. Diese
”
”
Eigenschaft gilt entsprechend auch umgekehrt.
Abbildung 2.12: owl:EquivalentProperty
owl:TransitiveProperty definiert eine Property als transitiv. Falls die Property
von einem Objekt A auf ein Objekt B und von B auf ein Objekt C zeigt, so zeigt diese
Property ebenfalls von A nach C . Beispiel hierfür ist ist älter als“.
”
Abbildung 2.13: owl:TransitiveProperty
owl:SymmetricProperty definiert eine Property als symmetrisch. Falls die Property
von einem Objekt A auf ein Objekt B zeigt, so zeigt diese Property ebenfalls von B auf
C . Beispiele hierfür sind ist verwandt mit“ und ist so groß wie“.
”
”
owl:FunctionalProperty beschreibt eine Property, für die pro Objekt nur ein Wert
angenommen werden kann. Beispiele hierfür sind Alter und hat Mutter“.
”
owl:InverseFunctionalProperty beschreibt eine Property, für die ein einzelner
Wert nicht für zwei verschiedene Objekte angenommen werden kann. So kann für die
Klasse Mann die Property ist Vater von“ mehrere Werte annehmen. Jedoch können zwei
”
unterschiedliche Objekte nicht den selben Wert annehmen.
36
Abbildung 2.14: owl:SymmetricProperty
Die Anwendbarkeit von Properties wird in OWL ebenfalls durch rdfs:domain und durch
rdfs:range definiert. Es gibt dazu die Möglichkeit für bestimmte Klassen weitere Einschränkungen zu treffen. Diese Einschränkungen werden durch owl:Restriction definiert und beziehen sich jeweils auf eine Property. Hierzu stehen folgende Restriktionselemente zur Verfügung.
owl:allValuesFrom bietet die Möglichkeit den Wertebereich noch stärker als durch
rdfs:range definiert einzuschränken. So kann z.B. in der Tierontologie der Wertebereich der Property frißt“ für Pflanzenfresser auf Pflanzen eingeschränkt werden.
”
owl:hasValue bestimmt, dass die angegebene Property einen bestimmten Wert haben
muss. Z.B. kann für die Klasse aller Autos die Property Anzahl Räder“ den Wert 4 haben
”
muss.
owl:someValuesFrom erzwingt, dass die Property mindestens einen Wert aus einem
angegebenen Wertebereich besitzen muss. So kann z.B. in der Tierontologie für Allesfresser garantiert werden, dass die Property frißt“ auf mindestens ein anderes Tier zeigt. Dies
”
kann für mindestens eine Pflanze“ wiederholt werden.
”
Mit den Restriktionen owl:minCardinality, owl:maxCardinality und
owl:cardinality können die Grenzen für die Kardinalität einer Property festlegt werden. So kann es z.B. sinnvoll sein, für eine Abteilung eine Mindestanzahl an Mitarbeiter
festzulegen.
Die Restriktionen werden in der XML-Syntax gebildet, indem die zu beschränkende Klasse als
Unterklasse einer anonymen Klasse definiert wird, die durch owl:Restriction beschrieben
wird. Die einzelnen Restriktionselemente können beliebig kombiniert werden.
Restriktionen erlauben es, Klassen in Abhängigkeit von Objekten zu definieren. So kann die
Menge der französischen Städte als Unterklasse aller Städte gebildet werden. Durch die Bildung
einer Restriktion auf der Property liegtIn kann diese Klasse abgegrenzt werden. Dies erfolgt
durch owl:hasValue, das den Wert auf Frankreich festlegt. Hierzu muss jedoch Frankreich
37
als Objekt Teil der Ontologie sein. Dies entspricht dem ersten Punkt der Objektdefinition 2.4.2
der allgemeinen Eigenschaften einer Ontologiesprache. Relationeninstanzen können auf diesen
Objekten innerhalb der Ontologie definiert werden, was dem zweiten Punkt entspricht.
Sprachebenen von OWL Für OWL wurden drei Sprachebenen definiert, da es sehr unterschiedliche Anforderungen hinsichtlich Ausdrucksstärke und Einfachheit einer Ontologiesprache gibt. Je mächtiger die OWL-Sprachebene ist, desto komplexer und ineffizienter wird der
Gebrauch durch Mensch und Maschine.
OWL Full bietet alle Sprachelemente von OWL. Zudem ist es vollständig kompatibel zu
RDF und RDF Schema. Hierdurch entsteht jedoch auch die Möglichkeit die Bedeutung
der eigenen Sprachelemente zu verändern. So können z.B. Restriktionen auf die Klasse
Property angewendet werden oder auch Einschränkungen der Kardinalität dieser Elemente
definiert werden. Die Möglichkeit Sprachelemente innerhalb der Sprache neu zu definieren
führt jedoch dazu, dass OWL Full unentscheidbar8 ist. Eine vollständige und effiziente
Unterstützung ist somit nicht möglich.
OWL DL(Description Logic) behebt diese Schwierigkeiten, indem es die Möglichkeiten
der Sprache einschränkt. Dadurch ist es jedoch nicht mehr vollständig kompatibel zu RDF.
In OWL DL können Sprachkonzepte nicht mehr innerhalb der Sprache benutzt werden.
Dadurch können die vordefinierten Semantiken der Sprache nicht mehr verändert werden
und OWL DL wird zu einer Beschreibungslogik.
Beschreibungslogiken sind eine Untermenge der Prädikatenlogik erster Ordnung und in
ihren Eigenschaften sehr gut untersucht. Unter anderem ist jede Beschreibungslogik entscheidbar. Dies ermöglicht das automatische Schlussfolgern durch Machinen. Die einzelnen Einschränkungen durch OWL DL sind:
– Eine Resource kann nur entweder eine Klasse, eine Datatype Property, eine Object
Property, eine Instanz, ein Datenwert oder ein Sprachelement sein. Dies bedeutet,
dass kein Sprachelement innerhalb der Sprache neudefiniert werden kann.
– Es können außerdem keine Kardinalitätsbeschränkungen für transitive Properties definiert werden.
Eine reguläre Sprache L ist entscheidbar, wenn es einen Algorithmus gibt, der in endlicher Zeit entscheiden
kann, ob ein Wort w Element der Sprache L ist. Hieraus ergibt sich, dass es keine Implementierung geben kann, die
das automatische Schlussfolgern vollständig unterstützt.
8
38
– Spezielle Eigenschaften von Properties wie owl:TransitiveProperty oder
owl:InverseFunctionalProperty können nur auf Object Properties angewandt werden.
OWL Lite ist eine weiter eingeschränkte Form von OWL. Die weggelassenen Sprachelemente sollen den Umgang mit OWL für Benutzer und Anwendungsentwickler vereinfachen. Es lassen sich z.B. einfache Taxonomien realisieren. OWL Lite besitzt die Eigenschaften von OWL DL. Zusätzlich gelten folgende Einschränkungen:
– owl:oneOf, owl:disjointWith, owl:unionOf, owl:complementOf und
owl:hasValue sind nicht erlaubt.
– Kardinalitätsbeschränkungen können nur die Werte 0 oder 1 besitzen.
2.4.6
Das Semantic Web
Das Internet bietet eine riesige, unüberschaubare Menge an Informationen. Jeden Tag kommen neue Inhalte hinzu, während andere verschwinden. Diese Inhalte liegen meistens in Form
von HTML-Dokumenten vor, die die Darstellung der Informationen vorgeben. Dadurch können
Browser Informationen in menschenlesbarer und möglichst auch ansprechender Form wiedergeben. Jedoch können Maschinen Informationen in dieser Form nicht verarbeiten und sind somit
nicht automatisch nutzbar. Der Ansatz menschenlesbare Informationen mit der Hilfe von künstlichen Intelligenzen verfügbar zu machen gestaltet sich als schwierig. Der Ansatz von der anderen
Seite, die Informationen im Internet in maschinenlesbarer und -verarbeitbarer Form darzustellen,
wird durch das Semantic Web verfolgt.
Die Entwicklung des Semantic Web erfolgt durch das W3C und insbesondere Tim Berners-Lee,
dem Erfinder des Internets“ als eine Erweiterung des bestehenden Internets:
”
Das Semantic Web ist eine Erweiterung des derzeitigen Internets, in dem Informationen in wohl definierten Bedeutungen gegeben werden, so dass es besser
die Zusammenarbeit von Computern und Personen ermöglicht. [TBLL01, (Übersetzung)]
Nützlich für den Menschen sollen die maschinenlesbaren Informationen vor allem durch Softwareagenten sein. Dies sind Programme, die weitgehend unabhängig von Benutzereingaben arbeiten und aus eigener Initiative aktiv werden. Sie kommunizieren mit anderen Agenten und sollen
Menschen als persönliche Assistenten“ unterstützen. Mit Hilfe des Semantic Web könnte z.B.
”
ein Agent bei einer Erkrankung des Benutzers nach einer geeigneten Praxis in der Nähe suchen.
39
Er würde mehrere mögliche Termine unter Berücksichtigung der vorhandenen Termine mit dem
Agenten der Praxis aushandeln und diese dann dem Benutzer vorlegen. Dieser wählt einen Termin aus und der Agent macht einen Eintrag im Terminbuch. Ein anderes Szenario wäre der Einkauf mit Hilfe von Agenten. Diese könnten Preise und Leistungen vergleichen und dem Benutzer
die für ihn günstigsten (und nicht zwingend billigsten) Angebote vorlegen. Die benötigten Informationen würde der Agent über die Internet-Seiten der Anbieter in einer eindeutigen Semantik
erhalten.
Es sind jedoch auch ganz andere Anwendungsmöglichkeiten denkbar. Diese reichen von persönlichen Aufgaben über Wirtschaftsprozesse bis zum wissenschaftlichen Austausch von Forschungserkenntnissen. Neben diesen bereits vorhandenen Ideen wird es sicherlich eine große Menge an
Möglichkeiten geben, an die noch nicht gedacht wurde.
Das Semantic Web soll durch eine Hierarchie von aufeinander aufbauenden Technologien ermöglicht
werden. Der Vorteil dieses Schichtenansatzes ist, dass die Entwicklung und Einführung der neuen Standards schrittweise erfolgen kann. Dies erleichtert den Einsatz der neuen Technolgien
für Entwickler. Jede Technologie sollte nach unten kompatibel sein. So sollen Agenten, die auf
OWL-Daten arbeiten auch RDF Dokumente verstehen können. Dass dieser Ansatz nicht unproblematisch ist, zeigt sich durch die Probleme von OWL Full. Hier musste durch OWL DL und
OWL Lite ein Kompromiss geschaffen werden. Nach oben hin sollen die Technologien teilweise
kompatibel sein. Das heißt, dass ein Programm teilweise Informationen verarbeiten kann, die in
einer höheren Ebene formuliert sind. Hierzu werden einfach alle nicht bekannten Elemente der
höheren Ebenen ignoriert.
Die Grundlage der Verständigung im Sematic Web bildet Unicode, ein universeller Kodierungsstandard für Schriftzeichen und URI. Hierauf setzt XML auf, das das Erstellen von Webdokumenten in einer benutzerdefinierten Syntax ermöglicht. RDF und RDF Schema liegen auf XML
auf. Diese Technologien sind zwar nicht abhängig von XML, jedoch gibt es eine XML-basierte
Syntax. Diese Schicht ist vor allem für Metadaten gedacht, so dass Sematic Web Dokumente sich
selbst beschreiben. Durch RDF Schema können diese Metadaten zu einem Kontext zugeordnet
werden.
Bei RDF Schema handelt es sich bereits um eine Ontologie Sprache. Jedoch wird eine ausdrucksstärkere Sprache benötigt, die es erlaubt auch komplexere Zusammenhänge zwischen Objekten darzustellen. Dadurch kann anwendungsspezifischen Wissen formuliert werden und erlaubt somit die Verwendung zur Erzeugung höherwertiger Dienste. Für diese Ebene ist seit Februar 2005 offiziell OWL vorgesehen.
Die Verarbeitung des Anwendungswissens kann auf der Logic Ebene durch sogenannte Reasoner erfolgen. Dies sind Programme, die aufgrund von gemachten Aussagen und Domänenwis-
40
Abbildung 2.15: Die Schichten des Semantic Web (Darstellung nach Tim Berners-Lee)
sen, wie es in OWL formuliert werden kann, neue Informationen gewinnen können. Beispiele
für Reasoner, die auf OWL arbeiten können sind RACER9 und PELLET10 . Da jedoch Reasoner
untereinander inkompatibel sind, soll als Proof Layer eine universelle Sprache für die Darstellung von Beweisen geschaffen werden. Die Programme sollen diese Sprache exportieren und
importieren können, um somit Beweise dem Semantic Web bereitzustellen.
Neben diesen Schichten werden digitale Signaturen die Echtheit von Daten und Beweisen sichern. Hierbei sollen Signaturen nicht nur einzelne Dokumente authentifizieren, sondern auch
die Berechnung von Vertrauenswürdigkeit durch die Reasoner ermöglichen. Durch den Beweis
von Schlussfolgerungen und die Authentifizierung der angenommenen Daten wird ein Netz des
”
Vertrauens“ auf dieselbe verteilte und chaotische Weise erzeugt wie das Internet heute.
Die Techniken des Semantic Webs setzen sich derzeit nur langsam durch. Dies liegt zum einem
daran, dass die Vorteile nicht direkt sichtbar sind wie beim normalen Internet. Anderseits braucht
es eine gewisse Verbreitung bis die Vorteile der Technologie deutlich werden. Es gibt derzeit nur
wenige Applikationen, die das Potential dieser Technik ausschöpfen, was als einer der Haupthindernisse aufgefasst wird [Zie03]. Diese Schwierigkeiten traten jedoch auch bei der Einführung
des Internets auf und konnten den Siegeszug“ dieser Technologien nicht verhindern.
”
9
10
http://www.racer-systems.com/
http://www.mindswap.org/2003/pellet/index.shtml/
2.5
41
Software-Metriken: Christian Dänekas
Dieser Abschnitt widmet sich dem Thema Software-Metriken. Um eine Basis für das Monitoring
von UML-Diagrammen zu schaffen und festzustellen, wie man Metriken dafür nutzen kann, soll
im folgenden zunächst geklärt werden, was Metriken sind. Dazu wird nach einer kurzen Einleitung dargestellt, wo die Softwaremetrie im Software-Entwicklungsprozess einzuordnen ist. Dies
führt zu einem besseren Verständnis, warum Software vermessen wird bzw. vermessen werden
sollte. Der Begriff der Qualität spielt dabei eine wichtige Rolle. Anschließend werden die für
Metriken essentiellen Grundlagen behandelt und eine Auswahl der in der Softwareentwicklung
bekannten Metriken für Sourcecode vorgestellt, die anschaulich die an Software messbaren Eigenschaften illustrieren.
2.5.1
Motivation und Begriffsklärung
Der Begriff Metrik entstammt dem Griechischen und lässt sich mit Die Kunst des Messens“
”
übersetzen. Eine Metrik drückt in Form einer Maßzahl einen beobachteten Sachverhalt zahlenmäßig aus. Den Begriff Metrik kann man in den verschiedensten Bereichen finden. In der
Mathematik zum Beispiel trifft man auf diesen im Zusammenhang mit der Abstandsmessung.
Man spricht dort auch vom metrischen Raum. Weiterhin findet man den Begriff auch in der Lyrik (Verslehre) oder der Musik (Lehre von den Taktarten) wieder.
Das Bestreben Sachverhalte durch Zahlenwerte auszudrücken findet man häufig auch im Bereich von wirtschaftlichen Tätigkeiten. Innerhalb von Unternehmen wird häufig auf Kennzahlen
zurückgegriffen, wenn es darum geht, Entscheidungen zu treffen, Prognosen aufzustellen oder
den Unternehmenserfolg zu kontrollieren und zu beurteilen. Diese Kennzahlen resultieren daraus, dass bestimmte Sachverhalte, wie etwa Absatzzahlen, gemessen werden und später ,zum
Zeitpunkt der Analyse, mit anderen Beobachtungen in Zusammenhang gebracht werden.
Da Softwareprojekte oftmals auch eine starke wirtschaftliche Komponente haben, da Zeit und
Kapital nur begrenzt vorhanden sind, ist es auch hier zunehmend interessant geworden, Metriken einzuführen, um den Verlauf des Projektes besser kontrollieren und damit frühzeitig Fehler
und Unzulänglichkeiten erkennen zu können. Dies soll im Gesamtzusammenhang gesehen dazu
führen, dass mehr Projekte im vorgegebenen Zeit und Kostenrahmen erfolgreich vollendet werden.
Sehr passend auf den Punkt gebracht wird die Motivation zur Einführung von Metriken im Um-
42
feld von Softwareprojekten von DeMarco in seinem Buch Controlling Software Projects“[Mar82].
”
Er hat dort einen Satz geprägt, der in vielen das Thema Software-Measurement betreffenden
Werken aufgegriffen wird:
You cannot control what you cannot measure.“
”
Anhand dieser Aussage wird klar, welche Bedeutung DeMarco der Aktivität des Messens beimisst. Im folgenden soll die Vermessung von Software dargestellt werden, wobei der Fokus im
weiteren Verlauf auf der Phase des Entwurfs liegen wird. Die Fragen warum man Messungen an
Software vornimmt, wie diese durchzuführen sind, welche Ansätze im Software-Measurement
bereits existieren und was tatsächlich messbar ist, sollen im folgenden beleuchtet werden.
2.5.2
Thematische Einordnung der Softwaremetrie
Wie im vorangehenden Abschnitt bereits angesprochen, sollen Metriken eine Ordnung auf komplexen Strukturen erzeugen, um diese überblicken zu können und damit zu kontrollieren. Eben
diese Aufgabe wird den Metriken auch in Bezug auf Software zuteil. Um einen geeigneten Überblick über dieses recht komplexe Aufgabenfeld zu erhalten, ist es erforderlich zu betrachten, in
welchem Rahmen die Vermessung von Software angewandt wird.
Software Engineering
Software-Projekte sind im Laufe der Zeit zunehmend komplexer und unüberschaubarer geworden. Der Grund hierfür ist zunächst einmal im Produkt, also der Software, zu suchen. Entgegen
der oft vertretenen Meinung bezeichnet der Begriff Software“ nicht allein das Programm an sich,
”
sondern alles, was dazu dient dieses Programm lauffähig zu machen. Neben dem Programm ist in
Bezug auf den Begriff der Software nach [Som01, S. 5] noch die Dokumentation sowie die Konfigurationsdateien zu berücksichtigen. Betrachtet man Software in dieser gesamtheitlichen Sicht,
wird schnell klar, das aus den hohen Anforderungen, die heute an Softwaresysteme gestellt werden, große und komplexe Software entsteht. Es ist leicht einzusehen, dass ein komplexes Produkt
auch einen komplexen Konstruktionsprozess nach sich zieht.
Historisch wurde die Komplexität der Softwareentwicklung den Entwicklern im Zuge der sogenannten Softwarekrise“ Ende der sechziger Jahre bewusst. Die Rechenkapazität der Hard”
ware hatte sich so stark gesteigert, dass die Entwickler vor Herausforderungen gestellt wurden,
mit denen sie nicht umzugehen wussten. Mit der ihnen plötzlich zur Verfügung stehenden Rechenleistung waren die Möglichkeiten der Software ebenfalls immens gestiegen. Bedingt durch
die mangelnde Strukturierung der Entwicklungsprozesse scheiterten viele Projekte, die Kosten
43
stiegen sehr stark an und Wartung von Software war kaum möglich. Aus diesem Grund wurden
die theoretische Konstrukte des Software Engineering“ geschaffen, die dem Projekt eine Struk”
tur verleihen, die Kontrolle ermöglicht. Software Engineering bezeichnet das ingenieurmäßige
Vorgehen bei der Entwicklung von Software. Software Engineering reicht von einer ersten Spezifikation bis hin zur Wartung der eingeführten Software und wird laut Ian Sommerville von zwei
Aspekten besonders charakterisiert (eigene Übersetzung [Som01, S. 6f]):
1. Es handelt sich um eine Ingenieursdisziplin:
Ingenieure sorgen dafür, dass Dinge funktionieren. Sie bedienen sich Theorien, Methoden
und Werkzeuge, wo diese passend sind, aber nutzen diese selektiv und versuchen Lösungen
für Probleme zu finden, auch wenn es keine passenden Theorien und Methoden gibt, die sie
stüzen. Weiterhin arbeiten Ingenieure innerhalb organisatorischer und finanzieller Grenzen
und versuchen daher Lösungen innerhalb dieser Grenzen zu finden.
2. Software Engineering befasst sich mit allen Aspekten der Softwareentwicklung:
Software Engineering befasst sich nicht nur mit den technischen Aspekten der Softwareentwicklung, sondern auch mit Aktivitäten wie Softwareprojekt-Management und der der
Entwicklung von Werkzeugen, Methoden und Theorien zur Unterstützung des Herstellungsprozesses.
Der Begriff Software-Engineering umfasst also ein breites Feld an Tätigkeiten. Diese verfolgen
das Ziel, sowohl den Prozess der Softwareentwicklung als auch die Software selbst besser beherrschbar zu machen. Im folgenden wird dargestellt, in welchem Rahmen sich diese Tätigkeiten
bewegen und welche Rolle dem Software-Measurement zukommt.
Software-Entwicklungsprozess
Die Komplexität von Software liegt in seiner Natur als System begründet. Ein System lässt sich
folgendermaßen definieren [Som01, S. 21]:
A system is a purposeful collection of interrelated components that work to”
gether to achieve some objective.“
Um die Entwicklung von Systemen beherrschbar zu machen, wurde das Modell system engi”
neering process“ geschaffen. Dieses Modell umfasst Phasen für alle Tätigkeiten innerhalb des
System-Lebenszyklusses von der Definition der Anforderungen bis hin zur Abschaffung des
Systems. Die Aussagen über Systeme im allgemeinen lassen sich auch auf Software übertragen.
44
Durch Schaffung entsprechend spezialisierter Modelle soll der Erfolg in der Softwareentwicklung gewährleistet werden.
Um solche Modelle entwickeln zu können müssen die fundamentalen Aktivitäten während der
Softwareentwicklung bekannt sein. Sommerville (vgl. [Som01, S. 43]) benennt diese folgendermaßen:
1.
Software specification“: Die funktionalen und nicht funktionalen Anforderungen an die
”
zu entwickelnde Software werden festgelegt.
2.
Software design and implementation“: Entwicklung einer Software, die die zuvor gestell”
ten Anforderungen erfüllt.
3.
Software validation“: Das richtige Verhalten“ der Software wird validiert.
”
”
4.
Software evolution“: Software entwickelt sich entsprechend der wechselnden Kundenan”
forderungen weiter.
Das älteste Prozessmodell der Softwareentwicklung ist das Wasserfallmodell. Das Modell des
system engineering process“ war ein wichtiger Einfluss bei der Entwicklung dieses Modells.
”
Diesem Vorbild folgend umspannt es den gesamten Lebenszyklus eines Softwareproduktes, welcher sich von den ersten Überlegungen bezüglich der Anforderungen bis zum Betrieb/Wartung
und der damit verbundenen Außerbetriebnahme der Software nach Beendigung des Einsatzes
erstreckt. Obwohl es eine Vielzahl an unterschiedlichen Ansätzen zur Gestaltung des Entwicklungsprozesses in der Softwareentwicklung gibt, so enthält das Wasserfallmodell alle fundamentalen Aktivitäten der Softwareentwicklung und ist aufgrund seiner Übersichtlichkeit gut geeignet,
um das Konzept der Maßnahmen zu verdeutlichen, die versuchen, Software besser kontrollierbar
zu machen. Die Phasen des Wasserfall-Modells sind in Abbildung 2.16 zu sehen und folgendermaßen zu verstehen:
1. Requirements definition: Die Anforderungsdefinition für das Softwaresystem. In Zusammenarbeit mit dem Auftraggeber werden die Anforderungen an das System festgelegt.
2. System and software design: Bezeichnet den Entwurf. Hier wird anhand der Anforderungsdefinition das Design der Software festgelegt, zum Beispiel mit Hilfe von UMLWerkzeugen.
3. Implementation and unit testing: Die einzelnen Programmteile/Module werden implementiert und einzeln getestet.
45
Abbildung 2.16: Das Wasserfall-Modell der Softwareentwicklung [Som01, S. 45]
4. Integration and system testing: Die Module werden zu einer Gesamtsystem integriert und
es finden entsprechende Tests des Systems statt.
5. Operation and maintenance: Das fertige System befindet sich im Einsatz und wird laufend
verbessert und angepasst.
Positionierung der Softwaremetrie
Das vorgestellte Wasserfallmodell (siehe Abbildung 2.16) ist eine der Maßnahmen im SoftwareEngineering, die die Softwareentwicklung erleichtern sollen. Es verschafft Orientierung, indem
es den Entwicklungsprozess in Phasen einteilt. Diese Maßnahme schafft mehrere kleinere Problembereiche, anstelle eines großen Gesamtproblems. Pro Phase sind bestimmte Tätigkeiten vorgesehen. Entsprechend setzt sich das Ergebnis einer jeden Phase aus den Ergebnissen der dort
durchgeführten Tätigkeiten zusammen. Diese Ergebnisse, man spricht oft auch von Dokumen”
ten“, dienen dann den Tätigkeiten der nachfolgenden Phase als Basis. Zum Beispiel dienen unter
anderem die UML-Diagramme der Entwurfsphase als Basis für die Implementierung dieses Entwurfs in einer Programmiersprache. Diese Grundeigenschaft ist allen Phasenmodellen gemein.
Doch die Einteilung von Prozessen in Phasen reicht allein nicht aus, um den Erfolg in der Softwareentwicklung sicherzustellen.
46
Das Problem, welches sich in diesem Zusammenhang nämlich stellt, ist, dass es nur schwer
erkennbar ist, ob die Tätigkeiten einer Phase und ihre produzierten Ergebnisse die Entwicklung
in die richtige Richtung vorantreiben. Um Erkenntnisse über die Tätigkeiten eines Prozesses und
ihre Ergebnisse zu gewinnen, sind Messverfahren notwendig. Metriken sollen die Möglichkeit
schaffen, zu einem Urteil über einen Betrachtungsgegenstand zu gelangen, und sind aufgrund
dessen im gesamten Anwendungsfeld des Software Engineering denkbar und wünschenswert.
Eine ständige Kontrolle der Tätigkeiten in der Softwareentwicklung kann z.B. unnötige Iterationszyklen im Prozessmodell und damit stark erhöhte Kosten oder gar das Scheitern der Entwicklung verhindern. Um gesicherte Aussagen hervorzubringen, sollte zuerst der zu beurteilende
Aspekt wohl definiert sein. Das allgemeine Ziel bei der Softwareentwicklung ist die Qualität.
Aufgrund seiner Allgemeinheit und seiner Funktion als zentrale Motivation für die Vermessung
von Software soll dieser Begriff im folgenden näher betrachtet werden.
2.5.3
Softwarequalität
Im vorangegangenen Abschnitt wurde deutlich, dass es für Metriken im Bereich des Software
Engineering viele potenzielle Anwendungsmöglichkeiten gibt. Es sind viele Zusammenhänge in
diesem Bereich denkbar, die durch Metriken quantifiziert werden könnten. Ein zentraler Aspekt
im Software Engineering ist dabei die Qualität. Von einer hohen Qualität hängt es zum Beispiel
ab, ob der Auftraggeber mit der entwickelten Software zufrieden ist, oder ob der Entwicklungsprozess erfolgreich abgeschlossen werden kann, was die zeitlichen oder finanziellen Restriktionen betrifft.
Ein erstes Problem, das der Begriff Qualität aufwirft ist, dass man Qualität nicht wirklich fassen kann. Dies liegt unter anderem daran, dass Qualität je nach Blickwinkel in einem gänzlich
anderem Licht erscheint. Es ist also kein gänzlich objektiv erfassbarer Begriff. Eine klassische
Definition von Qualität ist, dass ein Produkt die an es gestellten Anforderungen erfüllen sollte
(vgl. [Som01, S. 536], Zitat nach [Cro79]). Der Qualitätsbegriff in Bezug auf Software ist jedoch mit Problemen behaftet. So gibt es bei Software sowohl die Anforderungen des Kunden,
als auch Anforderungen der Entwickler. Der Kunde verlangt z.B. verschiedene Funktionen, die
ein Programm erfüllen soll. Eine für einen Entwickler denkbare Anforderung wäre, dass die
Software möglichst gut strukturiert sein sollte, um den zur Wartung der Software erforderlichen
Aufwand möglichst gering zu halten. Schon hier ist also Qualität nicht eindeutig festzustellen.
Eine weiteres Problem ist, dass sich nicht jede Anforderung eindeutig definieren lässt. Aus der
Sicht einer Person kann eine Anforderung also erfüllt sein, wohingegen sie aus einer anderen
Perspektive nicht erfüllt wird. Außerdem kann es bei der Definition von Anforderungen leicht
47
zu einem Informationsverlust kommen. Bestimmte Anforderungen können zwar durchaus von
Auftragnehmer und Auftraggeber gemeinsam schriftlich manifestiert worden sein, jedoch selbst
wenn diese alle erfüllt zu sein scheinen, kann das Produkt auf den Kunden noch mangelhaft wirken, da seine Vorstellung von bestimmten Eigenschaften der Software nicht unverändert den Weg
in die Anforderungsdefinition gefunden hat. Das Problem mit dem man sich in Bezug auf Qualität also auseinandersetzen muss ist, dass die Anforderungen an das zu entwickelnde Produkt
unvollständig sind und dieser Zustand der Software selbst entspringt. Neben den Anforderungen
haben zu dem auch weitere Faktoren, wie z.B. Fehler, Einfluss auf die Qualität des Produkts, was
die Komplexität des Qualitätsbegriffs weiter erhöht.
Softwarequalität ist also ein komplexer Aufgabenbereich, dem aus diesem Grund auch entsprechende Aufmerksamkeit geschenkt werden werden sollte. Man befasst sich damit unter dem
Banner quality management“. Der Posten im Management, der damit betraut ist, wird qua”
”
lity manager“ genannt. Die drei Aktivitäten des quality management benennt [Som01, S.537]
folgendermaßen:
1. Quality assurance (Qualitätssicherung)
2. Quality planning (Qualitätsplanung)
3. Quality control (Qualitätskontrolle)
Diese Aktivitäten bauen aufeinander auf. Das Ziel der Qualitätssicherung ist die Definition von
allgemeinen, unternehmensweiten Standards, die hohe Qualität fördern soll. Die Qualitätsplanung knüpft dort an und überträgt diese Standards auf ein Projekt. Es macht Sinn, dass diese an
die speziellen Eigenarten des Projekts angepasst werden. Die Qualitätskontrolle zielt letztendlich
darauf ab, dass die Richtlinien der Qualitätssicherung eingehalten werden.
Standards sind für die Orientierung bei komplexen Vorgängen sehr wichtig. So gibt es auch
für Qualität eine Sammlung internationaler Standards. Diese trägt den Namen ISO 9000. Die
ISO 9001 ist der allgemeinste dieser Standards. Er bezieht sich auf alle Organisationen, die damit beschäftigt sind ,mit Bezug auf die Qualität Produkte zu entwerfen, zu entwickeln oder zu
warten. Die Maßnahmen zur Qualitätssicherung werden im quality manual“ festgehalten und es
”
besteht mancherorts die Möglichkeit dieses als ISO 9000 konform zertifizieren zu lassen. Mehr
Informationen über die ISO 9000 findet sich z.B. in [Tha00, S. 31 ff].
In Hinblick auf die Qualität von Software ist es wichtig zu beachten, dass man sowohl die Produktqualität als auch die Prozessqualität sicherstellen muss. Dies ist in allen Phasen des quality managements zu beachten, da sich das Produkt und sein Entstehungsprozess nicht getrennt
48
Abbildung 2.17: Abhängigkeit der Produktqualität von der Prozessqualität [Som01, S. 543]
voneinander betrachten lassen, wenn man aussagekräftige Beobachtungen machen möchte. Der
Einfluss der Prozessqualität auf die Qualität des Produkts wurde aus der Massenproduktion abgeleitet und auf andere Herstellungsprozesse, darunter auch die Entwicklung von Software, übertragen. Der Zusammenhang wird in Abbildung 2.17 dargestellt. Rechnung getragen wird dem
Zusammenhang in der quality-assurance-Phase durch die Definition von Standards für Produkte
und Prozesse. Für das Softwareprodukt werden unter anderem Standards für die zu erstellenden
Dokumente (z.B. die Anforderungsdefinition), die Dokumentation der Software sowie Programmierrichtlinien festgelegt. Entsprechend werden die durchzuführenden Prozesse und die dort resultierenden Dokumente beschrieben.
Zur Kontrolle der Einhaltung der Qualitätsmerkmale in der quality-control-Phase existieren zwei
komplementäre Ansätze. Der erste Ansatz beschreibt die Erstellung von Reviews. Eine Gruppe
kontrolliert hierbei die Software, die Dokumentation und die dazugehörigen Entstehungsprozesse auf ihre Standardkonformität und meldet eventuelle Abweichungen an die ProjektmanagementAbteilung. Hierbei handelt es sich also um die manuelle Kontrolle der Qualität. Ein Beispiel für
die Erhöhung der Softwarequalität durch manuelle Kontrolle sind zum Beispiel bugreports“.
”
Im Eclipse-Projekt11 werden auf diese Weise Hinweise auf Fehler und Verbesserungsvorschläge
eingereicht, die mit einer detaillierten Beschreibung versehen werden und so auf Mängel der
Software hinweisen.
Der zweite Ansatz ist ist die automatische Verarbeitung der Software und ihrer Dokumentation
durch ein Anwendungsprogramm. An dieser Stelle können auch quantitative Messungen vorgenommen werden, die als Basis für die Vermessung der Daten durch Metriken dienen. Hier lässt
sich zur Verdeutlichung wiederum das Eclipse-Projekt heranziehen. Mit Hilfe von junit12 werden
11
12
http://eclipse.org/
http://www.junit.org/
49
dort Tests geschrieben, die sich automatisiert auf die zu testende Software anwenden lassen. Auf
diese Weise erhält man, die Validität der Tests vorausgesetzt, wertvolle quantitative Aussagen
über die Qualität der getesteten Komponenten.
Es ist also zu erkennen, welch hohen Stellenwert die Sicherung der Qualität im Software Engineering besitzt. Die Qualität ist das zentrale Merkmal der Softwareentwicklung. Will man Aussagen zum Fortschritt eines Softwareprojekts machen, ist die Qualität der Software zu beurteilen.
Metriken sollen einen Beitrag zur Qualitätssicherung leisten. Um den Nutzen von Metriken beurteilen zu können, sollen die theoretischen Grundlagen im folgenden dargestellt werden.
2.5.4
Messen
Was bisher in dieser Arbeit über Metriken ausgesagt wurde, ist vereinfacht ausgedrückt, dass sie
dazu dienen, Beobachtungen an einem Gegenstand quantitativ auszudrücken, so dass anschließend der entstandene Zahlenwert interpretiert werden kann. Es ist nachvollziehbar, dass dieser
Prozess sich einer Form von Abbildung bedienen muss. Die Herausforderung in diesem Zusammenhang ist die geeignete Abstraktion der vorliegenden Merkmale des Gegenstands. Dazu muss
man sich im klaren darüber sein:
Was für ein Objekt wird betrachtet? Welches Skalenniveau liegt vor?
Welche Transformationen/Relationen werden gewünscht bzw. wie soll die Metrik aussehen?
Welche Transformationen/Relationen sind auf diesem Objekt möglich?
Der in diesem Zusammenhang wichtige Begriff ist der des Skalenniveaus. Diese bestimmen,
was mit Messergebnissen auf mathematischer Ebene möglich ist. Die Hierarchie der Skalen ist
in Abbildung 2.18 zu sehen. Dabei schließen die Skalen in der Abbildung jeweils die innerhalb ihrer Fläche befindlichen Skalen ein. Ein Beispiel ist die Ordinalskala. Diese beinhaltet als
komplexere Skala laut Skalenhierarchie die einfachere Nominalskala. Dies bedeutet, dass alle
empirischen Relationen, die auf nominalskalierten Daten möglich sind, auch auf ordinalskalierten Daten zulässig sind. Jedoch muss man beachten, dass die Möglichkeit zur Transformation
einer Skala abnimmt, je komplexer diese ist. Welche Eigenschaften den einzelnen Skalenniveaus
gegeben sind, soll an dieser Stelle dargestellt werden.
Nominalskala Die Nominalskala wird für qualitative Merkmale verwendet. Diese zeichnet aus,
dass man außer der Prüfung auf Gleichheit oder Ungleichheit keine Operationen auf ihnen
ausführen kann. Weiterhin kann man Merkmale dieses Skalenniveaus klassieren und den
50
Abbildung 2.18: Skalenhierarchie [Bal98, S. 228]
Modus berechnen, also die Merkmalsausprägung bestimmen, die am häufigsten auftritt.
Ein Beispiel für ein nominalskaliertes Merkmal ist das Geschlecht.
Ordinalskala Merkmale der Ordinalskala lassen sich mittels einer Ordnungsrelation ordnen. Es
lassen sich also Aussagen darüber machen ob eine Merkmalsausprägung größer, kleiner
oder gleich als eine andere Ausprägung ist. Es sind Transformationen zulässig, die die
auf den Objekten bestehende Ordnung nicht verändern. Daraus folgt, dass jegliche monoton steigende Funktion als Transformation angewendet werden darf. Man kann außerdem
Median, Ränge und den Rangkorrelationskoeffizienten berechnen. Ein Beispiel für ordinalskalierte Merkmale sind Schulnoten.
Intervallskala Auf der Intervallskala sind nur noch positive lineare Funktionen zur Transformation erlaubt. Zwischen den Werten der der Intervallskala sind jedoch zusätzlich Differenzbeziehungen definiert und weitere statistische Operationen in Form von Arithmetischem
Mittel und Standardabweichung können berechnet werden. Ein Beispiel für diesen Skalentyp sind Temperaturwerte gemessen in C.
Rationalskala Auf dieser Skala sind proportionale Transformationen in Form von y = b x
erlaubt. Zusätzlich gegenüber der Intervallskala existiert ein absoluter Nullpunkt. Ein Beispiel sind Längenmaße.
Absolutskala Auf der Absolutskala sind keine Transformationen mehr zugelassen bzw. nur
noch identische Transformationen. Die Absolutskala liegt bei Häufigkeiten resultierend
aus Zählvorgängen vor.
51
Die Skalen sind ein wichtiger Aspekt wenn es um die Messobjekte geht, jedoch darf auch hier
der Prozess nicht vernachlässigt werden. Ein geordnetes Vorgehen ist zwingend erforderlich um
Ergebnisse zu erhalten, die dem Validierungsprozess standhalten. Wallmüller (vgl. [Bal98, S.
226]) schlägt für die Gestaltung des Prozesses folgendes Vorgehen vor:
1. Definition der Messziele,
2. Ableitung der Messaufgaben aus den Messzielen,
3. Bestimmung der Messobjekte,
4. Festlegen der Messgröße und Messeinheit,
5. Zuordnung der Messmethoden und Messwerkzeuge zu den Messobjekten und Messgrößen,
6. Ermittlung der Messwerte,
7. Interpretation der Messwerte.
In diesem Modell für den Prozess des Messens wird auf wichtige Eigenschaften von Software Rücksicht genommen. Durch die Unterscheidung von Messzielen/Messaufgaben und der eigentlichen Messung am Messobjekt mit entsprechend wohldefinierten Meßmethoden wird klar,
dass es einen Unterschied gibt zwischen den Eigenschaften einer Software, die man beurteilen
möchte, und den Aspekten der Software, die tatsächlich quantitativ messbar sind. In [Som01]
wird zur Veranschaulichung dieses Sachverhaltes von internen und externen Softwaremerkmalen gesprochen. So sind externe Merkmale einer Software zum Beispiel Dinge wie Wartbarkeit
oder Zuverlässigkeit, also abstrakte Merkmale, die unter anderem von dem im vorhergehenden
Abschnitt angesprochenen Streben nach Qualität motiviert sind. Tatsächlich messen (im Sinne
von zählen) kann man jedoch nur das, was man vorliegen hat. Dies sind in Bezug auf Software
die Inhalte von Dingen wie Quellcode, UML-Modelle oder auch dazugehörige Dokumente. Dort
lassen sich dann bestimmte Muster finden oder Objekte zählen, was im weiteren Verlauf dieser
Ausarbeitung noch näher erläutert werden wird. Auch Fenton spricht diese wichtige Unterscheidung an. Er unterscheidet direkte und indirekte Messungen. Die Verbindung zwischen diesen
Messtechniken wird dort etwas klarer. Die direkte Messung erfolgt völlig unabhängig. Fenton
drückt dies folgendermaßen aus [FP97, S. 39]:
Direct measurement of an attribute of an entity involves no other attribute or entity.
”
For example, length of a physical object can be measured without reference to any
other object or attribute.“
52
Die indirekte Messung leitet hingegen komplexere Zusammenhänge aus den Ergebnissen direkter Messungen ab. Dies geschieht dadurch das mehrere direkt gemessene Größen in einen
bestimmten Zusammenhang gebracht werden, woraus dann eine neue indirekte“ Messgröße
”
entsteht. Auch hierfür findet Fenton wiederum ein einfaches Beispiel [FP97, S. 40]:
On the other hand, density of a physical object can be measured only indirectly
”
in terms of mass and volume; we the use a modell to show us that the relationship
among the three is
density
mass
= volume
“
Ein bekanntes Modell, welches eben diese Schwierigkeit der Softwarevermessung aufgreift und
zu mindern versucht, ist der Goal-Question-Metric Ansatz nach Basili und Rombach ([BR88]
vgl. [Som01, S. 567]). Der Weg von den Messzielen zu den Messverfahren in Form von geeigneten Metriken wird in diesem Modell beschrieben. Den Ausgangspunkt bilden die Ziele (Goals).
Es werden grob Ziele formuliert, die erreicht werden sollen. Die Formulierung ist an dieser Stelle
noch sehr allgemein. Die Fragen (Questions) stellen den nächsten Schritt dar. Zu jedem Ziel werden Fragen formuliert, die es genauer beschreiben. Von diesen Fragen ausgehend wird schließlich
versucht, Messverfahren, also Metriken (Metrics), zu definieren, die bei der Beantwortung der
formulierten Fragen helfen. Sind Metriken definiert worden, deren Ergebnisse zur Beantwortung
der Fragen beitragen, so ist auch der Bezug zu den Zielen hergestellt.
Der Weg von einem Messziel hin zu einer entsprechenden Metrik ist eine der zentralen Schwierigkeit in Hinblick auf die Definition und Anwendung von Metriken. Aus diesem Grunde ist die
Softwaremetrie bisher mehr ein theoretisches Forschungsfeld als eine in der praktischen Anwendung übliche Tätigkeit. Da die Anforderungen an Software und ihren Erstellungsprozess derart
wandelbar sind, wie in kaum einer anderen Ingenieursdisziplin, fehlt vielen Firmen/Projekten
die entsprechende Organisation ihrer Softwareprozesse. Auch existieren keine Standards in Bezug auf Metriken, was nach Sommerville viele Firmen davon abhält, Metriken einzuführen. Das
jedoch eine Vielzahl an Richtlinien und Modellen existiert, wird im weiteren Verlauf dargestellt
werden.
2.5.5
Anforderungen und Klassifikation
Durch das gesamte Konzept des Software Engineering existiert eine Trennung zwischen Prozess
und Produkt. So ist es auch im Bereich der Metriken. Der Gedanke, der hinter dieser Unterscheidung steckt ist, dass es kein qualitativ hochwertiges Produkt ohne hochwertigen Prozess geben
53
kann, wie bereits in Abschnitt 2.5.3 vorgestellt. Dies ist die grundlegende Klassifikation, die auf
Metriken angewandt wird [FP97, S. 74]. Diesen großen Metrikklassen wird später noch ein eigener Abschnitt gewidmet werden. Es gibt auch wesentlich feinere Klassifikationsansätze, jedoch
ist für die in dieser Arbeit verfolgten Ziele zunächst die grobe Einteilung ausreichend.
Unabhängig vom vorliegenden Metriktyp existieren allgemeine Anforderungen, die erfüllt werden sollten. Statt von Anforderungen wird in diesem Zusammenhang auch von Gütekriterien
gesprochen. Erst wenn diese erfüllt sind, ist die Qualität einer Metrik gesichert. Die Kriterienliste angelehnt an [Bal98, S. 227] sieht folgendermaßen aus:
1. Objektivität: Der Messende soll keine subjektiven Einflüsse auf die Messung haben können.
2. Zuverlässigkeit: Unter gleichen Bedingungen sollen stets gleiche Messergebnisse bei Wiederholung der Messung erzielt werden.
3. Validität: Messergebnisse sollen eindeutig in Bezug auf die Messgröße sein.
4. Normierung: Die Messergebnisse sollen sich auf eine Skala eindeutig abbilden lassen (siehe Abschnitt 2.5.4).
5. Vergleichbarkeit: Es ist möglich das Maß mit anderen in Relation zu setzen.
6. Ökonomie: Die Messung sollte günstig erfolgen können.
7. Nützlichkeit: Das Maß sollte praktisch anwendbar sein, also hilfreich in Bezug auf das
entsprechende Tätigkeitsfeld sein.
Diese Anforderungen sind leicht einsehbar, da sie darauf abzielen, dass der aus einer Metrik heraus berechnete Wert eine gesicherte Aussagekraft besitzt. Das gemeinhin schwierigste Kriterium
ist die Validität (vgl. [Bal98, S. 227]). Der Zusammenhang zwischen den internen Messungen
und den externen Merkmalen, über die man Aussagen treffen will, ist noch schwer nachzuweisen. Auf diese Problematik wurde auch bereits im vorangegangenen Abschnitt eingegangen.
2.5.6
Prozessmetriken
Der Zweck von Prozessmetriken besteht darin, Messungen am Prozess der Softwareerstellung
vorzunehmen. Auf diese Weise kann unter anderem die Effizienz des Prozesses beurteilt werden.
Während die Prozessmetriken keine Aussage über die Produktqualität liefern, so sind auf der anderen Seite Messungen am Produkt vorzunehmen, um diese im Zusammenhang mit dem Prozess
zu betrachten. Sommerville nennt drei Arten von Prozessmetriken (vgl. [Som01, S. 566]):
54
1. Die für die Fertigstellung eines bestimmten Prozesses aufgewandte Zeit: z.B. die Gesamtdauer des Projektes oder die Zeit pro Entwickler.
2. Die für einen bestimmten Prozess erforderlichen Ressourcen: z.B. Gesamtaufwand in Personentagen, Reisekosten, Computerressourcen.
3. Die Häufigkeit des Auftretens bestimmter Ereignisse: z.B. Anzahl gefundener Programmfehler, beantragter Anforderungsänderungen, etc..
[FP97, S. 74] wählt zur Klassifikation von Metriken zwischen dem Prozess an sich, den dort
entstehenden Produkten und den im Prozess verwendeten Ressourcen. Der Prozess bildet den
Rahmen in dem die Geschehnisse in der Softwareentwicklung sowie eigentlich jeder geordneten Tätigkeit ablaufen. Dies wurde auch schon in Zusammenhang mit Abbildung 2.17 deutlich.
Der dort gezeigte Zusammenhang zwischen Prozess und Produkt darf nicht vernachlässigt werden. Daher hat die Vermessung von Prozessen auch eine erhebliche Bedeutung in der Industrie
erlangt. Zur Beurteilung der Prozessqualität in Organisationen wurde das Process Capabili”
ty Maturity Modell“ vom Software Engineering Institute (SEI) entwickelt (siehe z.B. [Tha00,
S.135ff]). Dieses beurteilt die Reife“ der Prozesse auf einer Skala von fünf Stufen. Auch das im
”
Rahmen dieses Projekts entwickelte Tool verfolgt das Ziel, zur Verbesserung des Entwicklungsprozesses beizutragen. Der Fokus liegt dabei auf Messungen, die an dem vorliegenden Produkt
durchgeführt werden. Daher soll im folgenden dem zentralen Punkt des Interesses, dem Produkt,
besondere Aufmerksamkeit geschenkt werden.
2.5.7
Produktmetriken
In den bisherigen Abschnitten wurde die Notwendigkeit des ingenieurmäßigen Vorgehens bei
der Softwareentwicklung und der damit verbundenen Motivation, Software zu vermessen, eingegangen. Weiterhin sind die Grundlagen des Messens, sowie allgemeine Gütekriterien dargestellt
worden, die ein Maß für Software erfüllen sollte. Doch wie gestalten sich die Metriken für ein
oft subjektives und weiches“ Anwendungsfeld, wie es Software ist?
”
Ein zentraler Aspekt, der zum Erfolg der Softwareentwicklung beitragen soll, ist zunächst die
Vermessung des Produkts“, der Software selbst. Man spricht in diesem Zusammenhang von
”
Produktmetriken. Dabei werden von Sommerville (vgl. [Som01, S. 551]) zwei Typen von Produktmetriken unterschieden. Zum einen spricht er von Dynamischen Metriken“. Hierbei werden
”
die Messungen am Produkt während der Ausführung vorgenommen. Statische Metriken“ ist sei”
ne Bezeichnung für die Messungen, die an den Dokumenten“ angewandt werden, die das Pro”
dukt ausmachen, wie z.B. dem Sourcecode. Dies ist auch der zentrale Betrachtungsgegenstand
55
der Wissenschaft, was die Entwicklung anwendbarer Metriken für Softwareprodukte anbelangt.
Auf die Dynamischen Metriken“ wird an dieser Stelle nicht weiter eingegangen, da sich die
”
angestellten Überlegungen zu Softwaremetriken im weiteren Verlauf auf die Entwurfsphase des
Softwareentwicklungsprozesses beziehen und man dort lediglich statisches Betrachtungsmaterial findet. Daher sei in Bezug auf dieses Thema zur weiteren Information auf die Fachliteratur
verwiesen.
Wenn man nach Ansätzen und Modellen für die Vermessung von Software sucht, fällt auf, dass
der Schwerpunkt der Erforschung und Anwendung von Produktmetriken bisher in der Implementierungsphase liegt. Um dort die Qualität der Software zu beurteilen, werden verschiedene
andere Aspekte zunächst untersucht. Die Messungen, die vorgenommen werden, zielen auf die
Bestimmung von Dingen wie Länge, Funktionalität, Struktur oder Komplexität ab (vgl. [FP97,
S. 76]). Um Aussagen über derartige Dinge treffen zu können, sind oftmals schon komplexere, abgeleitete Metriken notwendig, also mathematische Verfahren, die aus direkt gemessenen
Größen andere Zusammenhänge ableiten, wie bereits beschrieben. In diesem Zusammenhang
existieren einige einschlägige Modelle, die sich in ihrer Funktionsweise zum Teil deutlich unterscheiden, jedoch das gleiche Ziel verfolgen, nämlich vorliegenden Quellcode quantitativ zu
erfassen und damit zur Qualitätssicherung beizutragen. Diese Modelle sollen vorgestellt werden, um die verschiedenen Messansätze kennenzulernen und im weiteren Verlauf beurteilen zu
können, inwieweit sich derartige Messkonstrukte auch auf UML-Modelle anwenden lassen.
Lines of Code
Eine auf den ersten Blick sehr einfache Metrik um die Länge eines Programms zu messen, ist
Lines of Code (LOC). Bei dieser Metrik werden die Programmzeilen gezählt und damit der Umfang eines Programms bestimmt. Doch schon bei dieser scheinbar einfachen Zählung lassen sich
schon große Probleme bzw. Unstimmigkeiten in der Anwendung finden. So ergibt sich zum Beispiel ein großer Unterschied, wenn in einem Fall Kommentarzeilen neben den Programmzeilen
mitgezählt werden und in einem anderen Fall nicht. Viele verschiedene Definitionen der LOCMetrik sind möglich. Es unterliegt zu jeder Zeit dem Anwendungszweck der Metrik, welche
Objekte zu messen, und welche zu ignorieren sind. Ein gutes, da sehr einfaches Beispiel sind
Leerzeilen in der LOC-Metrik (vgl. [Tha00, S. 43]). Was die Funktionalität eines Programms
betrifft, haben diese keinerlei Relevanz. Jedoch tragen sie viel zur Strukturierung und Übersichtlichkeit des Quellcodes bei. Wenn man also Metriken nicht sorgfältig und anwendungsbezogen
genug definiert, so kann man davon ausgehen, dass die ermittelten Ergebnisse wenn überhaupt
nur eine geringe Aussagekraft besitzen. Aus der einfachen LOC-Metrik lassen sich einige wei-
56
tere Metriken ableiten, wie z.B. die Anzahl der Fehler pro 1000 LOC (oder 1 KLOC). Auch
lässt sich die LOC-Metrik theoretisch dazu verwenden, die Produktivität von Programmierern
zu ermitteln, indem die Zahl der produzierten Programmzeilen pro Mannmonat“, also LOC
MM ,
”
ermittelt wird. Ein weiteres Problem mit der LOC-Metrik ist, dass die Anzahl der LOC bei unterschiedlichen Programmiersprachen auch völlig unterschiedlich ausfällt, was unter anderem
durch die unterschiedliche Mächtigkeit von Programmiersprachen und ihrer Konstrukte bedingt
ist. Daher gibt es z.B. Bestrebungen die LOC Einheit jeweils auf Assembler umzurechnen. Es ist
also nicht immer klar welche LOC im Verlauf eines Projektes berücksichtigt werden sollen und
wie LOC zu bewerten sind. Thaller gibt daher Regeln zur Berechnung an (vgl. [Tha00, S. 49]).
Zusammengefasst gibt er zur mathematischen Berechnung von LOC an:
Die Lines of Code (EF F LOC ) werden durch Zählung der Begrenzung für Sprachkonstrukte, z.B. dem Strichpunkt bei C, ermittelt. Dabei werden geänderte Programmzeilen
(CH LOC ) genauso gezählt wie neue (ALL LOC ). Wiederverwendete Programmzeilen
(RE LOC ) werden abgezogen. Mathematisch dargestellt ergibt sich:
EF F LOC
=
ALL LOC
+ CH
LOC
0:8
RE LOC
Die in einer beliebigen Programmiersprache ermittelten EF F LOC werden in Assembler
Equivalent umgerechnet (mit dem Faktor HOL EQ, der die Mächtigkeit der jeweiligen
Sprache im Vergleich mit Assembler angibt). Mathematische Darstellung:
AE LOC
=
EF F LOC
HOL EQ
Zusammenfassend kann man also sagen, dass LOC zwar aufgrund seiner Einfachheit sehr praktisch erscheinen mag, jedoch auch viele Mängel aufzuweisen hat. Daher wundert es nicht, dass
eine Fülle an weiteren Ansätzen existiert, die auf andere Weise versuchen, durch Messungen
gestützte Aussagen über Software zu treffen.
Function points
Ein von LOC gänzlich verschiedener Ansatz sind die Function Points (FP). Dieser Ansatz stammt
aus dem Jahre 1979 und wurde von A. J. Albrecht von IBM erdacht. Im Mittelpunkt steht hierbei
die Funktionalität der Software und nicht mehr deren Länge. Die Funktionen einer Software
erhielten in der ursprünglichen Fassung des Funktion Point Ansatzes eine Unterteilung in vier
Typen [Tha00, S. 51]:
57
1. Number of INPUTS (Eingaben: Abkürzung IT)
2. Number of OUTPUTS (Ausgaben: Abkürzung OT)
3. Number of INQUIRIES (Anfragen: Abkürzung IQ)
4. Number of MASTER FILES (Dateizugriffe: Abkürzung FT)
Jeder dieser Funktionstypen erhält eine Gewichtung Wi , wobei i den Index des Funktionstyps
(siehe oben) angibt. Die Gewichtungsfaktoren wurden für jeden Funktionstyp festgelegt. Hat
man für ein Projekt die Funktionen ermittelt und typisiert, so lassen sich also Aussagen über das
Ausmaß/den Umfang der Software, und damit über den damit verbundenen Aufwand treffen. Die
Formel stellt sich folgendermaßen dar:
FP
=
IT
W
1
+ OT
W
2
+ IQ
W
3
+ FT
W
4
Dieses Modell ebenfalls wie Lines of Code recht einfach gehalten. Es ist also nicht verwunderlich, dass das Function-Point-Verfahren noch einige Veränderungen erfahren hat um genauere
Ergebnisse zu erzielen. Der Grundgedanke dieses Verfahrens soll an dieser Stelle jedoch ausreichen. Diese beiden in den Grundzügen einfach gehaltenen Verfahren demonstrieren zwei sehr
verschiedene Herangehensweisen an die Vermessung von Software.
McCabe´s Cyclomatic Complexity
Ein weiterer prominenter Ansatz stammt von McCabe aus dem Jahre 1976. Die Metrik wird als
Cyclomatic Complexity“ (CC) bzw. im Deutschen als Zyklomatische Komplexität“ bezeich”
”
net. Während sich bei zuvor betrachteten Metriken LOC und FP mit dem Umfang einer Software
beschäftigen, wird hier versucht eine Aussage über die Komplexität einer Software zu treffen.
Dazu betrachtet man den Kontrollflussgraphen eines Software-Moduls. Nach [FP97, S. 293] berechnet sich McCabe´s Maßzahl folgendermaßen:
v (F ) = e
n+2
Dabei ist F der Kontrollflussgraph des Moduls, e die Anzahl der Kanten und n die Anzahl der
Knoten des Graphen. Das sich ergebende Maß v (F ) bezeichnet die Anzahl der linear unabhängigen Pfade im vorliegenden Programmfragment. CC ist eine sehr bekannte Metrik, jedoch lässt
sie sich nicht gut auf objektorientierte Programme anwenden, da diese meist eine sehr geringe Kontrollflusskomplexität besitzen und daher das Maß in diesem Kontext keine Aussagekraft
mehr besitzt. Jedoch zeigt CC durch die Analyse der Programmstruktur eine weitere Herangehensweise an die Vermessung von Software.
58
Halsteads Metrik
Ein weiterer Ansatz stammt von Maurice Halstead aus dem Jahre 1972. In diesem Ansatz werden die Operatoren (Sprachkonstrukte wie z.B. +, , (, ), WHILE, FOR, etc.) und die Operanden (z.B. Variablen, Konstanten, usw.) berücksichtigt und als Basis für verschiedene Aussagen
genutzt (vgl. [Tha00, S. 84]). Er unterscheidet hierbei noch die Anzahl von unterschiedlichen
Operanden und Operatoren (jeder Typ wird bei der Zählung also nur einmalig berücksichtigt)
sowie die Gesamtzahl dieser. Er benutzt hierfür folgende Bezeichnungen:
1 : Anzahl der verschiedenen Operatoren
2 : Anzahl der verschiedenen Operanden
N1 : Gesamtzahl an verwendeten Operatoren
N2 : Gesamtzahl an verwendeten Operanden
Daraus lassen sich verschiedene Maße berechnen. Dazu gehören z.B. die Programmlänge L =
N1 +N2 , das Programmvolumen V = L(log2 ) (mit = 1 +2 ), die Schwierigkeit D = 21 N22
und der Aufwand E = D V . Das Besondere an Halstead´s Ansatz ist das seine Metriken nicht
nur Bezug auf die quantitativen Elemente von Software nehmen sondern auch psychologische
Überlegungen mit einbeziehen. Zudem bildeten die Halstead-Metriken einen der ersten Ansätze
zur Software-Vermessung.
Es ist also zu sehen,dass sehr verschiedene Ansätze existieren, mit denen verschiedene Merkmale von Software in zahlenmäßige Größen übertragen werden. Dieses Zahlenmaterial bietet
durch die Beurteilung der Software einen Anhaltspunkt für Aussagen über den Verlauf und das
Vorankommen der Entwicklung. Die dargestellten Betrachtungen über Softwaremetriken bilden
den Orientierungspunkt für die weiteren metrikbezogenen Ausführungen in dieser Arbeit.
Kapitel 3
Umsetzung
3.1
Software: Stephan große Austing
Im folgenden soll die Implementierung der Software zu diesem Individuellen Projekt dargestellt
werden. Dies umfasst nicht die verwendeten Ontologien, Metriken und XMI-Dateien. Die Umsetzung dieser Elemente ist in separaten Abschnitten beschrieben. Das Programm wurde unter
dem Namen ROSE (RDF-Ontologiebasierte SoftwareentwurfEvaluierung) entwickelt. Es ist in
der Programmiersprache Java mit Hilfe der Entwicklungsumgebung Netbeans geschrieben worden.
Zunächst wird das Zusammenspiel der verwendeten Techniken erläutert. Danach folgt eine Beschreibung der Struktur des Programmes. Die Benutzeroberfläche wird kurz vorgestellt. In diesem Abschnitt sind zwei Screenshot der Software enthalten. Weitere Screenshots befinden sich
im Abschnitt zu den Metriken und im Anhang. Alle Programmabläufe können natürlich nicht in
dieser Ausarbeitung dargestellt werden. Exemplarisch folgen am Ende des Abschnitt zwei Beispiele zum Ablauf der Diagrammdatenverwaltung und zur Analyse.
3.1.1
Vorgehensweise der Software
Die Grundlage der Analysen bilden XMI-Dokumente. Diese werden durch das UML Modellierungswerkzeug Poseidon von Gentleware1 aus vorhandenen UML-Projekten exportiert werden.
Da diese Projekte einen hohen Umfang und viele verschiedene Diagrammtypen besitzen können,
wird aus jeder XMI-Datei nur ein Diagramm ausgelesen; Eine simultane Importierung eines gesamten Projektes ist mit den Möglichkeiten von XSLT nur schwer zu realisieren. Um das Im1
http://www.gentleware.com
59
KAPITEL 3. UMSETZUNG
60
Abbildung 3.1: Arbeitsprinzip der Software
portieren des richtigen Diagrammes zu garantieren, sollte in einem Projekt nur ein Diagramm
vorhanden sein.
Wenn die XMI-Dateien vorhanden sind, können sie in das Programm geladen werden. Hierzu
wird durch eine Hilfsklasse, dem XMILoader, eine XSLT-Transformation vorgenommen. Dieser bestimmt vorher den Diagrammtyp und die zu verwendende XSLT-Datei. Das Ergebnis der
Transformation ist ein OWL-Dokument, das in der Semantik der entsprechenden Diagrammontologie gefasst ist. Das Dokument wird der Datenverwaltung als String übergeben.
Die OWL-Dokumente werden permanent gespeichert und bei Bedarf geöffnet. Um eine Analyse
vorzunehmen wird durch die Analyzer-Klassen das Jena-Framework verwendet. Hierzu werden
die Dokumente in eine Ontologiemodellklasse geladen. Bei den Abfragen auf diesem Modell
werden durch einen Reasoner Schlussfolgerungen gezogen, die auf der verwendeten Ontologie
beruhen. Somit können aus den bereits vorhandenen Informationen weitere Zusammenhänge
ermittelt werden und somit für Metriken genutzt werden. Die Analyzer-Klassen kapseln die Verwendung der Ontologien und liefert nur die Werte der Metriken.
Die Benutzerschnittstelle bietet Möglichkeiten zur Kontrolle der Darstellung der Ergebnisse.
61
Desweiteren beinhaltet sie die notwendigen Dialoge für die Importierung und Verwaltung der
Diagramme.
3.1.2
Architektur
Die Architektur wird durch ein Klassendiagramm im Anhang dargestellt. Die einzelnen Attribute
und Methoden sind in diesem Diagramm nicht enthalten. Es wird nur eine allgemeine Sicht der
Architektur geboten. Im folgenden werden die verschiedenen Packages beschrieben aus denen
die Software besteht:
Das Defaultpackage besitzt den Namen rose. In diesem Package befinden sich nur eine Klasse, die Main.java. Diese Klasse bildet den Kern der Software, besitzt jedoch nur wenige Funktionen. Die anderen Klassen sind auf die Unterpackages verteilt.
Abbildung 3.2: Datenstruktur in ROSE
rose.project Dieses Package bietet die zur Verwaltung der Datenstrukturen 3.2 notwendigen Klassen.
Hierbei bildet ein Projekt das oberste Element. Die Software kann nur ein Projekt gleichzeitig geöffnet haben. In einem Projekt werden die Diagramme sowie die Anforderungen
verwaltet.
Jedes Diagramm liegt in ein oder meheren Versionen vor, welche separat voneinander gespeichert werden. Um die Eindeutigkeit bei den Bezeichnern zu garantieren, wird strikt
zwischen Diagram und Version unterschieden. Bei einem Diagramm handelt es sich immer
um eine Menge von Versionen. Dies wird durch eine Aggregationsbeziehung verdeutlicht.
Die Datenhaltung ist durch Interfaces modular gestaltet worden. So kann z.B. sowohl eine
dateibasierte als auch eine datenbankbasierte Implementierung vorgenommen werden. Die
Software besitzt jedoch derzeit nur eine dateibasierte Implementierung.
62
Abbildung 3.3: Dateibasierte Datenhaltung
Dateibasierte Datenhaltung Alle Daten der Projekte werden innerhalb des Programmunterordners projects verwaltet. In diesem Verzeichnis befindet sich die Datei roseProjects.xml. Diese beinhaltet Informationen über alle vorhandenen Projekte. Die Projekte
sind in jeweils eigenen Unterordnern dieses Verzeichnisses gespeichert. In diesen Projektverzeichnissen werden alle OWL-Dateien sowie die Datei project.xml abgelegt. Zur
Verbesserung der Performance der Diagrammanalyse werden die Ergebnisse in den project.xml-Dateien zwischengespeichert. Leider hat sich gezeigt, dass die Analyse selbst
bei kleineren Diagrammen sehr rechenintensiv ist. Deswegen wird jede Analyse zunächst
nur einmal vorgenommen und permanent gespeichert. Jedoch kann durch eine Update”
Funktion“ eine Neuberechnung erzwungen werden.
Für das Lesen und Schreiben der XML-Dokumente wurde die JDOM2 -Library eingebunden.
rose.gui Dieses Package umfasst alle für die Darstellung notwendigen Klassen. Die GUI wird durch
Java-Swing-Klassen gebildet. Es besteht im Gegensatz zu einer Webapplikation also keine
Notwendigkeit für einen eingerichteten Tomcat-Server.
2
http://www.jdom.org/
63
Die GUI-Klassen teilen sich in die Klasse rose.gui.MainFrame für das Hauptfenster, Klassen für die Darstellung der rechten Seite des Hauptfensters und Klassen für die Dialogfenster auf. Alle Klassen außer dem Hauptfenster werden bei Bedarf mit den beteiligten
Objekten der anderen Packages instanziert und angezeigt.
Die Klassen für die rechte Seite des Hauptfensters stellen die Metrikwerte dar. Für jede Diagrammart gibt es eine Ansicht für eine einzelne Version (AnalysisView) und eine
Ansicht für alle Versionen im zeitlichen Verlauf (ChartView). Die Darstellung der Metrikwerte im Verlauf geschieht über einen Graphen, der durch die JFreeChart3 -Library erzeugt
wird.
Die Klassen für die Dialoge sind:
– Projekt erstellen: rose.gui.NewProjectDialog
– Projekt öffnen: rose.gui.ProjectChooser
– Diagramm einstellen: rose.gui.NewDiagramDialog
– Version hinzufügen: rose.gui.AddVersionDialog
– Anforderung erstellen: rose.gui.NewRequirementDialog
rose.analysis In diesem Paket befindet sich für jeden Diagrammtyp eine Analyseklasse. Diese kann die
entsprechenden OWL-Dateien einlesen und Abfragen mit Hilfe eines Reasoners vornehmen. Diese Abfragen bilden die Grundlage für die Bildung der Werte für die Metriken.
Für die Ermittlung dieser Werte können sehr einfache Abfragen ausreichend sein. Jedoch
musste z.B. für die Ermittlung des längsten Vererbungspfades ein Graphenalgorithmus erstellt werden. Dieser sucht nach dem längsten Weg in dem gerichteten Graphen, der durch
rose:isParentOf als Kanten und rose:Entity als Knoten gebildet wird.
Die Grundlage für die Arbeit an den OWL-Dateien bildete das Jena Framework. Dieses
bietet eine umfassende API für die Arbeit an RDF und OWL und einen Reasoner.
rose.xmi Dieses Package beinhaltet alle für die Arbeit auf XMI-Dateien notwendigen Klassen. Dies
ist derzeit jedoch nur die Klasse rose.xmi.XMILoader. Ihre Funktion ist das Einlesen von
XMI-Dateien und das Bereitsstellen des entsprechenden OWL-Dokumentes.
3.1.3
Benutzerschnittstelle
Das Programmhauptfenster (Abbildung 3.4) ist in zwei Bereiche aufgeteilt; Der linke Bereich
dient der Auswahl des zu analysierenden Elementes. Im rechten Bereich werden die entsprechenden Analysen angezeigt. Die Darstellung der Datenstrukturen erfolgt über einen Baum. Durch
3
http://www.jfree.org/jfreechart/
64
einen Klick auf einen Knoten des Baumes werden die Informationen zu diesem Element auf der
rechten Seite des Hauptfensters dargestellt. Die Wurzel bildet der Projektname. Diesem sind die
einzelnen Diagramme direkt untergeordnet. Deren Tochterknoten bilden die verschiedenen Versionen.
Abbildung 3.4: Programmhauptfenster
Bei der Auswahl einer Version werden die einzelnen Werte für die Metriken auf der rechten Seite angezeigt. Durch einen Update“-Knopf wird das Neuberechnen dieser Werte erzwun”
gen. Wird ein Diagramm ausgewählt, so werden die Metrikenwerte im zeitlichen Verlauf durch
einen Graph dargestellt. Dieser Graph ist beliebig zoombar und lässt sich auch ausdrucken. Über
Häkchenboxen lässt sich die Metriken festlegen, die im Graph berücksichtigt werden. Durch
einen Klick auf den Projektknoten, die Wurzel des Projektbaumes, werden Informationen über
den Erfüllungsgrad der Software dargestellt. Diese Informationen werden wenn möglich auch
als Graph im zeitlichen Verlaufen angezeigt.
Das Öffnen von vorhandenen Projekten und das Erstellen von neuen Projekten geschieht in neuen Unterfenster. Diese werden durch die Auswahl der entsprechenden Einträge in der Menüleiste
65
unter dem Menüpunkt Projekt geöffnet. Bei der Öffnung eines Projektes steht nur eine Liste der
der Software bekannten Projekte zur Verfügung. Zu diesen werden Kurzbeschreibungen angezeigt.
Für die Erstellung eines neuen Projektes ist wichtig, dass der Projektname eindeutig ist. Deswegen erfolgt eine ständige Überprüfung des Projektnames bei dem Dialog zur Projekterstellung. Ist
der Name nicht mehr eindeutig, so wird der Ok“-Knopf deaktiviert und ein Hinweis angezeigt.
”
Zu einem Projekt sollte außerdem eine Beschreibung angegeben werden. Durch das Betätigen
des Ok“-Knopfs wird das leere Projekt erstellt und geladen.
”
Wenn ein Projekt geladen wurde, ist das Hinzufügen von Diagrammen möglich. Dies geschieht
Abbildung 3.5: Dialog zum Hinzufügen eines Diagramms
über den Eintrag Diagramm hinzufügen...“ im Menüpunkt Projekt. Der Dialog ist in Abbil”
dung 3.5 dargestellt. Wie bei der Erstellung eines neuen Projektes wird die Eindeutigkeit des
Namens überprüft und eine Beschreibung sollte angegeben werden. Es ist jedoch zwingend erforderlich, dass ein oder mehrere OWL-Dateien als initiale Versionen angegeben werden. Die
Dateien müssen nicht in Erstellungsreihenfolge angegeben werden, da im XMI-Header ein Zeitstempel steht. Der Diagrammtyp der XMI-Dateien kann automatisch bestimmt werden. Sofern
für die angegebenen Dateien derselbe Diagrammtyp ermittelt wurde und die anderen Bedingungen erfüllt sind, kann mit Ok“ das Diagramm erstellt werden.
”
3.1.4
66
Beispiele des Programmablaufs
In diesem Abschnitt werden zwei Beispiele zum Programmablauf erläutert. Dies soll einen Einblick in die Arbeitsweise der Software bieten. Hierbei kann nicht auf jedes Detail der Implementierung eingegangen werden. Ebenso wird durch die Sequenzdiagramme nur der grobe Ablauf
geschildert. Bei den angegebenen Methoden werden die Parameter nicht dargestellt.
Abbildung 3.6: Sequenzdiagramm für die Analyse auf Klassendiagrammen
Anzeige der Klassendiagrammanalysen Durch einen Klick auf eine Diagrammversion werden die Werte für das entsprechende Diagramm angezeigt. Hierzu wird eine neue Instanz des
rose.gui.ClassAnalysisView instanziert. Dies ist eine Unterklasse von JPanel und wird so in
dem Programmfenster eingebunden. Bei der Instanzierung von ClassAnalysisView werden die
benötigten Werte abgerufen. Dies geschieht über ein rose.gui.ClassDiagram-Interface. Die Software besitzt eine dateibasierte Implementierung rose.gui.FileClassDiagram, die dem ClassAnalysisView mit Hilfe des Konstruktors übergeben wird.
Bei einer Abfrage der Werte für die Metriken wird zunächst versucht, diese Werte aus einer
XML-Datei zu lesen. Aus Performancegründen werden die Ergebnisse der Analysen innerhalb
der Projektdatei abgespeichert. Sind noch keine Werte vorhanden, so werden diese zuerst ermittelt, in die Projektdatei geschrieben und die Abfrage erneut durchgeführt. Für die Ermittlung der
Werte, die auch manuell wiederholt werden kann, wird die Funktion update() verwendet. Bei
Aufruf dieser Funktion wird rose.analysis.ClassAnalyzer instanziert. Diese Klasse kapselt die
Analyse, die mit Hilfe der Jena-API durchgeführt wird. Jena bietet die Möglichkeit ein Ontolo-
67
giemodell zu bauen. Dieses wird im Konstruktur mit der Klassenontologie aufgebaut. Mit der
Funktion readOwlDiagram werden die Diagrammdaten, die sich in einer OWL-Datei befinden
eingelesen. Danach können Abfragen auf dem Modell gemacht werden, aus denen der ClassAnalyzer die Metrikwerte bildet. Der Ergebnisse der Abfragen wie getNumClasses() werden von
FileClassDiagram in die XML-Datei eingetragen. Mit einer erneuten Abfrage der Werte in der
XML-Datei werden diese an ClassAnalysisView zurückgeliefert und in die Darstellung eingebunden.
Abbildung 3.7: Sequenzdiagramm für die Erstellung eines neuen Diagramms
Erstellen eines neuen Diagrammes Wenn ein Projekt geöffnet ist, so kann durch den Dialog
Diagramm hinzufügen...“ ein neues Diagramm erstellt werden. Ein Diagramm besteht aus ein
”
oder mehreren Versionen. In dem Dialog der durch rose.gui.NewDiagramDialog gebildet wird,
muss zu jedem neuem Diagramm mindestens eine initiale Version angegeben werden. Da der
68
Diagrammname eindeutig sein muss, werden alle Diagrammnamen über die Funktion getDiagramNames() des übergebenen rose.project.Project-Interfaces ermittelt. Die Implementierung
des Interfaces geschieht durch rose.project.FileProject.
Wenn die OK“-Taste gedrückt wurde, so wird zunächst überprüft, ob mindestens eine Version
”
angegeben wurde. Für die Überprüfung und das Einstellen der Versionen wird die Klasse rose.xmi.XMILoader verwendet. Zunächst wird geprüft, ob alle angegebenen XMI-Dateien den selben Diagrammtyp besitzen, wozu die Funktion determineType(File xmiFile) benutzt wird. Ist dies
der Fall, so wird durch die Methode addDiagram() des FileProject ein neues rose.project.DiagramInterface erzeugt. Die Implementierung geschieht durch rose.project.FileDiagram.
Von allen XMI-Dateien wird eine Transformation zu OWL durch die XMILoader-Methode transform() vorgenommen. Das Ergebnis wird als String zusammen mit dem Timestamp-String der
XMI-Datei an das FileDiagram durch die Methode addVersion übergeben. FileDiagram schreibt
die OWL-Dokumente in Dateien im Projektverzeichnis und nimmt die Einträge in die project.xml vor. Weitere Diagrammversionen können später hinzugefügt werden.
3.2
XSLT: Dirk Siemers
Damit XML-Dokumente oder -Daten in eine Ontologie gebracht werden können, ist es erforderlich, die Originaldaten in das dafür notwendige Format zu transformieren. Als Teil der Stilkomponente von XML dient XSLT genau diesem Zweck.
Im November 1999 hat das World Wide Web Consortium (W3C) die XSL-Transformationen, kurz
XSLT, als Empfehlung herausgegeben. Die in XML entworfene Sprache soll es Programmierern
ermöglichen, aus beliebig strukturierten XML-Daten andere Formate zu erzeugen. In diesem
Projekt werden XMI-Dokumente in OWL-Dokumente und somit in eine Ontologie transformiert. Die Verarbeitung von XML-Quellen mit einem XSLT-Programm bedeutet grundsätzlich,
dass das Programm aus der Quelle einen Dokumentenbaum erzeugt und mit Hilfe des XSLTStylesheets in einen Zielbaum umwandelt.[uJT02]
Im Zusammenhang mit XSLT hat das W3C ebenfalls im November 1999, eine Sprache für den
Zugriff auf Teile eines XML-Baumes verabschiedet. Diese XML Path Language (XPath) beschreibt durch Ausdrücke, welche Elemente und Attribute für die Verwendung auszuwählen sind.
XSLT ist als Bestandteil für XSL, einer Stylesheet-Sprache für XML, entwickelt worden. Neben
XSLT enthält XSL noch ein XML-Vokabular, um Formatierungen zu spezifizieren. XSLT soll
auch unabhängig von XSL genutzt werden, ist jedoch nicht als universelle
XML-Transformationssprache gedacht.
Eine in XSLT ausgedrückte Transformation beschreibt Regeln für die Transformation durch die
69
Assoziation von Mustern in Templates eines Quellbaumes in einen Ergebnisbaum. Dabei werden die Muster gegen Elemente des Quellbaumes getestet. Erfolgt dabei eine Übereinstimmung,
wird ein Template instanziiert um einen Teil des Ergebnisbaumes zu erstellen. Der Ergebnisbaum
und dessen Struktur ist unabhängig vom Quellbaum, er kann sich durch gefilterte Elemente des
Quellbaums oder durch umstrukturierte Elemente komplett von ihm unterscheiden. Desweiteren
können auch beliebige neue Strukturen durch ein Template hinzugefügt werden.
Ein Stylesheet enthält eine Menge von Template-Regeln, welche aus zwei Teilen bestehen. Einem Muster, das mit einem Knoten im Quellbaum geparst (verglichen) wird, und einem Template, welches instanziiert werden kann, um einen Teil des Ergebnisbaums zu bilden. Ein Vorteil dieses Aufbaus ist die Wiederverwendbarkeit eines Stylesheets auf Dokumente gleicher QuellbaumStruktur. Ein Template kann Elemente enthalten, welche eine literale Ergebniselement-Struktur
spezifizieren. Anweisungen innerhalb eines Templates können untergeordnete Quellelemente
selektieren und verarbeiten. Bei der Verarbeitung wird wiederum ein Ergebnisbaum-Fragment
durch Anwendung der Template-Regel und Instanziierung des Templates erzeugt.
Wenn ein Template instanziiert wird, wird es immer unter Beachtung eines aktuellen Knotens
und einer aktuellen Knotenliste instanziiert. Der aktuelle Knoten ist immer ein Mitglied der
aktuellen Knotenliste. Viele Operationen in XSLT sind relativ zum aktuellen Knoten, können
jedoch auch die Knotenliste oder den aktuellen Knoten wechseln, wobei zu beachten ist, dass
nach Abarbeitung der Operation wieder zum letzten aktuellen Knoten zurückgesprungen wird.
Die in XPath definierte Ausdruckssprache wird in XSLT genutzt, um Elemente zur Verarbeitung,
zur konditionalen Verarbeitung oder zur Erzeugung von Text auszuwählen.
3.2.1
Stylesheet-Struktur
XSLT-Namensraum Der XSLT-Namensraum besitzt die URI
http://www.w3.org/1999/XSL/Transform.
XSLT-Prozessoren müssen den XSLT-Namensraum-Mechanismus benutzen, um Elemente und Attribute aus dem XSLT-Namensraum zu erkennen. Dieser Namensraum ist eindeutig und kann nur durch die Angabe eines zusätzlichen Namensraums erweitert werden. Elemente des Namensraumes werden nur im Stylesheet und nicht im Quelldokument
erkannt. Jeder Namensraum mit zusätzlichen Anweisungselementen muss über ElementErweiterungs-Mechanismus identifiziert werden. Die W3C-Spezifikation benutzt den Präfix
xsl:, um Elemente des XSLT-Namensraums zu referentieren.
Stylesheet-Element Ein Stylesheet wird durch ein xsl:stylesheet-Element in einem XML-Dokument
dargestellt. Dabei muss ein Versions-Attribut im Start-Tag vorhanden sein. Das xsl:stylesheet-
70
Element kann verschiedene Elementtypen beinhalten, wobei jedes Kind des xsl:stylesheetElements ein Element der obersten Ebene darstellt. Benutzern ist es freigestellt in welcher Reihenfolge diese Elemente in einem XSLT angeordnet werden, mit Ausnahme der
xsl:import-Elemente. Diese müssen am Anfang des Dokuments aufgelistet werden.
3.2.2
Ausdrücke
XSLT benutzt eine durch XPath definierte Ausdruckssprache, auf welche im folgenden Kapitel noch näher eingegangen wird. Ausdrücke werden benutzt um einen bestimmten Knoten zur
Verarbeitung auszuwählen, spezielle Bedingungen an die Verarbeitung eines Knotens zu stellen,
oder um Text in dem Ergebnisbaum zu erzeugen. Sie stehen als Wert bestimmter Attribute in
XSLT definierten Elementen oder werden in geschweiften Klammern in Attribut-Templates eingetragen. Jeder Ausdruck bezieht sich auf seinen aktuellen Knoten und die damit verbundene
aktuelle Knotenliste.
3.2.3
Template-Regeln
Eine Template-Regel wird durch ein xsl:template-Element ausgedrückt. Die beiden wichtigsten Attribute des Elements sind das match- und das name-Attribut. Das match-Attribut ist ein
Muster, das einen oder mehrere Quellknoten identifiziert, auf denen die Regel angewendet wird.
Dieses Muster spezifiziert eine Menge von Bedingungen für einen Knoten. Ein Knoten, der diese
Bedingungen erfüllt, passt zu dem Muster. Werden die Bedingungen nicht erfüllt, so passt der
Knoten nicht zu dem Muster. Insbesondere Lokalisierungspfade, die bestimmte Bedingungen
erfüllen, werden als Muster genutzt. Ohne ein match-Attribut darf kein xsl:template-Element
existieren, es sei denn es ist ein name-Attribut für das xsl:template-Element definiert. Dann
beschreibt die Template-Regel eine bennannte Templateregel, welche nicht durch identifizierte
Knoten der Quelldatei, sondern durch die XSLT-Anweisung xsl:call-template aufgerufen wird.
xsl:template-Elemente müssen mindestens eines dieser beiden Attribute, können jedoch auch
beide beinhalten.
Durch ein xsl:apply-template-Element werden alle Kinder des Quellelements rekursiv verarbeitet. Wobei das select-Attribut des xsl:apply-template-Elements verwendet werden kann um nur
bestimmte Kinder des Quellelements auszuwählen. Der Wert des select-Attributs ist ein Ausdruck und wird als solcher behandelt.
Die Anwendung von Template-Regeln verdeutlichen den Gebrauch beider Elemente besonders.
71
3.2.4
Anwendung von Template-Regeln
Die bereits erwähnten Techniken erlauben schon kleinere Umwandlungsbeispiele. Mit den nun
folgenden Beispiel werden verschiedene Template-Regeln angewendet und im Anschluss an den
Beispielen erläutert:
XML-Daten:
<? xml
v e r s i o n =” 1 . 0 ” e n c o d i n g =”UTF 8” ?>

<Buch i d =” 1 ” >
< T i t e l>P e r A n h a l t e r d u r c h d i e
< A u t o r> D o u g l a s Adams< / A u t o r>
< / Buch>
<Buch i d =” 2 ” >
G a l a x i s< / T i t e l >
...
< / Buch>

XSLT-Stylesheet:
<x s l : s t y l e s h e e t
v e r s i o n =” 1 . 0 ”
x m l n s : x s l =” h t t p : / / www. w3c . o r g / 1 9 9 9 / XSL / T r a n s f o r m ”
xmlns =” h t t p : / / www. w3 . o r g / 1 9 9 9 / x h t m l ”>
< ! G i b t den Namespace ü f r XHTML an >
< ! B u c h h a n d l u n g w i r d a l s S t a r t k n o t e n ä g e w h l t >
< x s l : t e m p l a t e match =” B u c h h a n d l u n g ”>
< h t m l>
<h e a d>< t i t l e >B u c h h a n d l u n g< / t i t l e >< / h e a d>
<body>
< ! Der I n h a l t d e s XHTMLs w i r d u e b e r e i n T e m p l a t e
>
< x s l : a p p l y t e m p l a t e s />
< / body>
< / h t m l>
< / x s l : t e m p l a t e>
<! T e m p l a t e
<x s l : t e m p l a t e
ü f r e i n Buch
match =” Buch ”>
>
eingefuegt
72
ID d e s B u c h s :
< ! Den Wert d e s A t t r i b u t s ID a u s l e s e n >
< x s l : v a l u e o f s e l e c t =” @id ” />

< ! W e i t e r e K i n d e r d e s Buchs a u s l e s e n >
< / x s l : t e m p l a t e>
< / x s l : s t y l e s h e e t>
Als Ausgabe würde folgender Ergebnisbaum erstellt werden:
<html>
<head>
< t i t l e >B u c h h a n d l u n g< / t i t l e >
< / head>
<body>
ID d e s Buchs : 1
Per Anhalter durch die Galaxis
D o u g l a s Adams
ID d e s Buchs : 2
...
< / body>
< / html>
In diesem kleinen Beispiel ist bereits ein besonderes Element zur Generierung von Text, das
xsl:value-of -Element, benutzt worden. Für XSLT gibt diverse Elemente, die es dem Entwickler
ermöglichen bestimmte Attribute von Quellknotenelementen auszulesen, zu bearbeiten oder zu
vergleichen. Die wichtigsten Elemente werden im nächsten Abschnitt näher erläutert.
3.2.5
Elemente der XSLT
Erzeugung von Text Durch ein einfaches xsl:text-Element wird der in dem Element stehende
Text in dem Ergebnisdokument ausgegeben. Dies kann hilfreich sein, wenn ausgelesene
Werte nur durch ein Leerzeichen in dem Ergebnisdokument getrennt werden sollen. Beispielsweise
Vorname<xsl:text> </xsl:text>Nachname
Erzeugung von Kommentare Das xsl:comment-Element wird instanziiert, um einen Kommentar-
73
Knoten im Ergebnisbaum zu erzeugen. Der Inhalt des Elements ist der Zeichenkettenwert
des Kommentarknotens. Beispielsweise würde die Anweisung
<xsl:comment>Dies ist ein Kommentar !</xsl:comment>
folgende Ausgabe in dem Ergebnisdokument bewirken:

Attribute Das xsl:attribute-Element kann dazu benutzt werden um Attribute einem Ergebniselement hinzuzufügen. Dabei kann das Element auch durch eine XSLT-Anweisung erzeugt
worden sein. Der Name des hinzuzufügenden Attributes wird durch ein name-Attribut im
xsl:attribute-Element angegeben. Es besteht die Möglichkeit einen Namespace für das Attribut mit Hilfe eines namespace-Attributes zu definieren. Der Gebrauch eines xsl:attributeElements wird in dem Beispiel für bedingte Verarbeitung verdeutlicht.
Berechnung des erzeugten Textes Innerhalb eines Templates kann ein xsl:value-of -Element
benutzt werden, um Text zu berechnen. Dabei kann nicht nur Text aus dem Quellbaum
extrahiert werden, sondern auch der Wert einer Variable eingefügt werden. Diese Methode wurde bereits in dem Bücherei-Beispiel benutzt. Ein xsl:value-of -Element mit dem
notwendigen select-Attribut als Ausdruck wird instanziiert, um einen Textknoten im Ergebnisbaum zu erzeugen. Hier ein kleines Beispiel, in dem zuerst ein Attribut, dann ein
Kindsknoten als Wert ausgewählt wird:
< x s l : t e m p l a t e match =” Buch ”>
ID d e s B u c h s :
< x s l : v a l u e o f s e l e c t =” @id ” />
<n b>
< ! Den T i t e l d e s Buchs a u s l e s e n >
 T i t e l d e s B u c h s :
< x s l : v a l u e o f s e l e c t =” t i t e l ” />
<n b>
< / x s l : t e m p l a t e>
Textelemente können auch abgekürzt in geschweiften Klammern angegeben werden:
<!
Den A u t o r d e s Buchs a u s l e s e n
>
 A u t o r d e s B u c h s :
< ! Den Wert d e s A t t r i b u t s ID a u s l e s e n
>
74
f Autor g
<n b><n b r>
Wiederholung Wie in unserem Buchhandlungsbeispiel können XML-Dokumente eine bestimmte Regelmäßigkeit aufweisen. Die xsl:for-each-Anweisung erhält ein Template, welches
für jeden Knoten instanziiert wird, der durch das notwendige select-Attribut ausgewählt
wird. Hier ein kleines Beispiel um eine Tabelle aus der Buchhandlung zu erzeugen:
< t a b l e >< t b o d y>
< x s l : f o r e a c h s e l e c t =” B u c h h a n d l u n g / Buch ”>
< t r>
< t h>< x s l : v a l u e o f s e l e c t =” @id ” />< / t h>
< t d> T i t e l d e s B u c h s : f T i t e l g< / t d>
< t d> A u t o r d e s B u c h s : f A u t o r g< / t d>
< / t r>
< / x s l : f o r e a c h>
< / t b o d y>< / t a b l e >
Bedingte Verarbeitung Für XSLT gibt es zwei Möglichkeiten bedingte Verarbeitungen in einem Template zu ermöglichen.
1. xsl:if beschreibt eine einfache Wenn-Dann-Bedingung
2. xsl:choose beschreibt die Möglichkeit die Selektion einer Auswahl bei mehreren
Möglichkeiten.
Für ein xsl:if -Element ist ein test-Attribut vorhanden, welches einen Ausdruck angibt.
Nach Auswertung des Ausdrucks, wird das Ergebnisobjekt in einen boolschen-Wert gewandelt, der angibt, ob das in dem xsl:if -Element angegebene Template instanziiert werden darf, oder nicht.
xsl:choose-Elemente geben mit xsl:when-Elementen eine Menge von Möglichkeiten an.
Trifft jedoch keine dieser Möglichkeiten zu, kann auf ein optionales xsl:otherwise-Element
verwiesen werden. Beide Auswahlmöglichkeiten instanziieren ihre hinterlegten Templates
bei Erfüllung ihrer Bedingung. Die Bedingung für die Instanziierung eines xsl:otherwiseTemplates ist die negative Auswertung aller xsl:when-Elemente. Diese besitzen wie die
xsl:if -Elemente ein test-Attribut, welches auf gleicher Weise ausgewertet wird. Hier ein
kleines Beispiel zur Veranschaulichung:
< t r>
<x s l : i f
t e s t =” p o s i t i o n ( ) mod 2 =0 ”>
75
< x s l : a t t r i b u t e name=” b g c o l o r ”> r e d< / x s l : a t t r i b u t e >
</ x s l : i f>
< / t r>
Durch den Ausdruck des test-Attributs wird jeder zweiten Zeile das Attribut bgcolor mit
dem Wert red hinzugefügt. Jede zweite Zeile wird in der Tabelle so rot dargestellt. Die
Methode position() wird in dem Kapitel Xpath näher erläutert.
Variablen und Parameter Variablen werden mit einem xsl:variable-Element und einem name-Attribut angegeben. Der Inhalt der Variable wird über ein select-Attribut mit einem
Ausdruck als Wert ausgewählt. Wird kein select-Attribut angegeben, so ist der Wert der
Variable eine leere Zeichenkette.
< x s l : v a r i a b l e name=” x ” />
<! i s t g l e i c h z u s e t z e n m i t : >
< x s l : v a r i a b l e name=” x ” s e l e c t =” ’ ’ ” />
Variablen werden in Ausdrücken mit einem $ vor dem Namen benutzt.
3.3
XPath: Dirk Siemers
XPath wurde für die Verwendung von XSLT und XPointer entworfen und dient zur Adressierung
von Teilen eines XML-Dokuments. Zur Unterstützung dieser Aufgabe werden zusätzlich einfache Hilfsmittel für die Manipulation von Zeichenketten, Zahlen und boolschen Werten bereitgestellt. Um die Verwendung von XPath-Ausdrücken innerhalb von URIs und XML-Attributen zu
erleichtern, benutzt XPath eine kompakte Nicht-XML-Syntax. Xpath operiert auf der abstrakten,
logischen Struktur eines XML-Dokuments, nicht auf seiner äusseren Syntax. Der Name XPath
lässt sich von der auch in URLs genutzten Pfad-Notation (path) ableiten. Mit dieser kann auch in
der hierarchischen Struktur eines XML-Dokuments leicht navigiert werden. Neben der Verwendung für die Adressierung wurde Xpath so gestaltet, dass eine natürliche Teilmenge davon zum
Matching genutzt werden kann. Matching ist das Testen ob ein Knoten zu einem bestimmten
Muster passt. Diese Anwendung von XPath wird in dem Kapitel XSLT beschrieben. XPath modelliert ein XML-Dokument als einen Baum, der aus verschiedenen Knoten, z.B. Elementknoten,
Attributknoten oder Textknoten besteht. Die Berechnung des Zeichenkettenwerts eines Knotens
wird durch XPath definiert. XPath unterstützt in vollem Umfang XML-Namensräume. Besitzt
ein Knoten zusätzlich einen eigenen Namen, so wird der Name des Knotens als ein Paar aus
einem lokalen Bestandteil und einem gegebenfalls leeren Namensraum-URI modelliert.[Bec02]
76
Das primäre syntaktische Konstrukt in XPath ist der Ausdruck. Die Auswertung eines Ausdrucks
ergibt ein Objekt, das zu einem der folgenden vier Grundtypen gehört:
node-set (ungeordnete Menge von Knoten ohne Duplikate)
boolean (true oder false)
number (eine Gleitkommazahl)
string (Eine Zeichenkette bestehend aus UCS4 -Zeichen)
Ein Ausdruck wird immer bezüglich eines Kontextes ausgewertet. XSLT bestimmt, wie dieser
Kontext in XSLT unter Verwendung von XPath-Ausdrücken bestimmt wird. Ein wichtiger Ausdruck ist der Lokalisierungspfad, dieser wählt eine Knotenmenge relativ zu einem Kontextknoten
aus. Das Ergebnis des Ausdrucks ist genau die Knotenmenge, die die durch den Lokalisierungspfad ausgewählten Knoten enthält. Lokalisierungspfade können Ausdrücke rekursiv enthalten,
die zum Filtern von Knotenmengen benutzt werden.
3.3.1
Lokalisierungspfade
Das wichtigste, wenn auch nicht allgemeinste, grammatische Konstrukt der Sprache sind Lokalisierungspfade. Sie sind ein Spezialfall eines Ausdrucks und werden durch eine unkomplizierte
und eher verbale Syntax ausgedrückt. Für häufig genutzte Lokalisierungspfade gibt es eine Reihe
von Abkürzungen, mit denen sich diese kurz und knapp ausdrücken lassen. Es folgen nun einige
Beispiele:
4
child::Buch wählt die Buch-Kindelemente des Kontextknotens aus
child::* wählt alle Kindelemente des Kontextknotens aus
attribute::Autor wählt das Attribut Autor des Kontextknotens aus
descendant::* wählt alle Elemente aus, die Nachkommen des Kontextknotens sind
ancestor::* wählt alle Elemente aus, die Vorfahren des Kontextknotens sind
self::Buch wählt den Kontextknoten aus, falls dieser ein Buch ist
child::Buch/descendant::Autor wählt alle Autor-Elemente aus, die Nachkommen der BuchElemente des Kontextknotens sind
Universal Multiple-Octet Coded Character Set - siehe ISO/IEC 10646 bzw. ISO/IEC 10646, 2nd Edition
77
child::*/child::Autor wählt alle Autor-Enkelelemente des Kontextknotens aus
/ wählt die Wurzel des Dokuments aus
/descendant::Buch wählt alle Buch-Elemente aus, die im gleichen Dokument, wie der Kontextknoten enthalten sind
Ausgewählte Knotenmengen können durch nachgestellte Filterausdrücke in eckigen Klammern,
sogennante Prädikate, weiter eingeschränkt werden. Die folgenden Beispiele zeigen einige solcher Einschränkungen des Lokalisierungspfades:
child::Buch[position()=1] wählt das erste Buch-Kindelement des Kontextknotens aus
child::Buch[position()=last()] wählt das letzte Buch-Kindelement des Kontextknotens aus
child::Buch[child::Autor=’Douglas Adams’][postion()=1] wählt das erste Buch-Kindelement
aus, dessen Autor-Kindelement die Zeichenkette Douglas Adams enthält.
Um bestimmte Elemente mit einem Lokalisierungspfad zu erreichen gibt es zwei Möglichkeiten.
Entweder wird ein absoluter oder eine relativer Lokalisierungspfad benutzt. Ein relativer Lokalisierungspfad wird durch eine Folge von einem oder mehreren Lokalisierungsschritten gebildet,
die durch ein / voneinander getrennt sind. Die Schritte eines relativen Lokalisierungspfades werden von links nach rechts zusammengesetzt. Jeder Schritt wählt der Reihe nach eine Knotenmenge relativ zum Kontextknoten aus. Jeder Knoten in dieser Menge wird dann als Kontextknoten
für den nächsten Schritt benutzt.
Ein absoluter Lokalisierungspfad besteht aus einem / und einem optional folgenden relativen
Lokalisierungspfad, wobei ein / allein den Wurzelknoten des Dokuments auswählt. Ein folgender relativer Lokalisierungspfad würde die Knotenmenge auswählen, die ein Lokalisierungspfad
relativ zum Wurzelknoten des Dokuments auswählen würde.[Bec02]
Die Auswahl eines Knotens ist meist nur ein Hilfsmittel um Funktionen auf die ausgewählten
Knotenmengen auszuführen. Die wichtigsten Funktionen, die auf Knotenmengen angewendet
werden, werden im folgenden Abschnitt erklärt.
3.3.2
Funktionen auf Knotenmengen
last() Die Funktion last() liefert eine Zahl, die gleich der Kontextgröße des Kontextes des
ausgewerteten Ausdrucks ist.
position() Diese Funktion liefert eine Zahl die gleich der Kontextposition im Kontext des
ausgewerteten Ausdrucks ist. Ein Beispiel für den Gebrauch beider Funktionen ist:
78
child::Buch[position()=last()] wählt das letzte Buch-Kindelement des Kontextknotens aus
count(node-set) liefert die Anzahl der Knoten der übergebenen Knotenmenge. Die Funktion kann zur Bestimmung von Durchschnitt und Differenz zweier Mengen genutzt werden.
Folgendes Beispiel:
<!
D u r c h s c h n i t t d e r Mengen $ a und $b
$a [ count ($ a j$ b ) = count ($ b ) ]
<!
D i f f e r e n z b e i d e r Mengen
$a [ count ($ a j $ b ) != count ($ b ) ]
>
>
zur Erklärung: $a und $b stellen 2 Knotenmengen dar. $a ist in $b enthalten, wenn
count($b) = count($aj$b) Der Operant j berechnet die Vereinigung beider Knotenmengen.
id(object) Die Funktion id(object) wählt Elemente anhand ihrer eindeutigen ID aus. So
wählt z.B.:
id("42")/child::Buch
genau das Buch-Kindelement mit der eindeutigen ID 42 aus.
Die grundlegensten Möglichkeiten von XSLT und XPATH sind damit erläutert. Im folgenden
Kapitel wird nun zuerst auf die Erstellung von Ontologien eingegangen, um dann in dem Kapitel
XMI - OWL Umwandlung auf die Umwandlung von XMI-Dokumenten mittels XSLT und XPath
in OWL-Ontologien einzugehen.
3.4
OWL Ontologie : Stephan große Austing
In diesem Abschnitt wird die Gestaltung der Ontologien für die Software Rose erläutert. Hierbei
handelt es sich um OWL-Ontologien, die zunächst unabhängig voneinander stehen. Die Entwicklung der Ontologien verlief jedoch immer nach einem vergleichbaren Prozess. Deswegen
wird zunächst das generelle Vorgehen geschildert. Hiernach erfolgt die Darstellung der einzelnen Ontologien.
3.4.1
Generelles Vorgehen
Richtlinien Vor der Entwicklung der ersten Ontologie wurden einige Richtlinien aufgestellt.
Hierdurch sollte zum einem die Qualität der Ontologien verbessert werden, als auch eine Ver-
79
gleichbarkeit zwischen den Ontologien erreicht werden. Die Richtlinien sind zunächst aus dem
Artikel Ontology Development 101“ zur Ontologieentwicklung [NM01] und dem Protege-Tutorial
”
[HKR+ 04] entnommen worden und um einige Aspekte in Hinblick auf die Domäne erweitert
worden. Im Entwicklungsprozess kamen dann noch weitere Richtlinien hinzu.
Die Richtlinien bezüglich der Namensgebung waren:
Der Namensraum aller Elemente der Ontologie ist rose. Der URI-Prefix des Namensraumes ist http://informatik.uni-oldenburg.de/rose/#.
Klassen und Properties erhalten englische Bezeichner.
Die Bezeichner sollen möglichst kurz, soweit deren Bedeutung ersichtlich sein.
Klassen sollen mit Nomen bezeichnet werden.
Properties sollen mit Verben bezeichnet werden. Falls dies nicht ausreicht um die Property
zu beschreiben, so sollte der Bezeichner so gebildet werden, dass ein Statement (Klasse, Property, Klasse/Wert) die Form eines natürlichsprachigen Satzes erhält. So kann z.B.
die Property ist Vorfahre von nicht prägnant durch ein Verb ausgedrückt werden. Jedoch
ist der Bezeichner rose:isAncestorOf geeignet, da ein Statement die Form Person
isAncestorOf Person erhält. Die Bedeutung des Statements ist intuitiv erkennbar.
Klassenbezeichner beginnen mit einem Großbuchstaben
Propertybezeichner beginnen mit einem Kleinbuchstaben
In Hinblick auf die Anwendung wurden folgende Richtlinien gesetzt:
Jede Ontologie wird separat entwickelt und in einer separaten Datei gespeichert. Diese
Richtlinie verursachte im späteren Verlauf starke Probleme, auf die im Ausblick eingegangen wird.
Es werden nur die wichtigsten Elemente der Diagrammtypen modelliert. Die Dokumente sollen nicht jedes Detail des Diagramms wiedergeben, sondern eine allgemeine Beschreibung der Struktur aufzeigen. Die Ontologien sollen sich in ihrer Detailiertheit an
den Metriken orientieren. Deren Schwerpunkt liegt bei der Komplexität der Beziehungen
der Hauptelemente untereinander.
Die Ontologien sollen möglichst kompakt sein. Dies wirkt sich positiv auf die Performance
der Software aus und macht die Ontologien übersichtlicher.
Die entwickelten Ontologien müssen in OWL DL sein, da ein Reasoner für die Analysen
eingesetzt werden soll.
80
Werkzeuge Die Ontologien wurden mit dem Ontologiewerkzeug Protégé erstellt. Protege5 ist
eine Entwicklung unter der Leitung des Bereichs Stanford Medical Informatics an der Stanford
University School of Medicine. Beteiligt sind weitere Behörden aus dem Bereich Medizin und
Militär.
Protege unterstützt u.a. XML Schema, RDF und RDF Schema sowie OWL. Durch Plugins
können weitere Sprachen hinzugefügt werden oder Funktionen ergänzt werden. Weitere Funktionen können z.B. eine graphische Ausgabe der Ontologie oder andere Hilfswerkzeuge sein. Die
Entwicklung eigener Plugins ist möglich, da das Projekt als Open Source betrieben wird. Die
Software ist in Java geschrieben und somit für alle Java-fähigen Plattformen verfügbar.
Neben Protege können die Ontologien natürlich auch durch einen beliebigen Editor verändert
werden. Dies sollte jedoch nicht mit den original Protege Projektdateien geschehen, da es sonst
zu Problemen beim Öffnen des Projektes kommen kann.
Ablauf der Modellierung In allen UML-Diagrammen lassen sich Objekte identifizieren, die
durch Pfeile in Relation gebracht werden. Man kann durchaus UML-Diagramme als mathematische Graphen verstehen, wobei jedoch einige Elemente sehr stark von der üblichen Darstellungsweise abweichen. So sind unterschiedliche Pfeile für Relation und Vererbung eher als Beschriftungsfunktion zu verstehen. Trotzdem lassen sich in UML z.B. Klassen, Interfaces oder Zustände
als Knoten auffassen. Die Pfeile lassen sich entsprechend als Kanten eines solchen Graphen verstehen.
Hieraus kann man den Ansatz ableiten, alle Knoten in Klassen einzuordnen. Die Kanten werden entsprechend durch Relationen dargestellt. Der Aufteilung in Klassen kann durch den Typ
des Knoten erfolgen. So wird z.B. für Klassendiagramme eine Klasse Interface gebildet. Somit
lassen sich sehr anschauliche Statements wie Klasse istUnterklasseVon Klasse bilden. Dieser
Ansatz wurde bei der Modellierung so weit wie möglich verwendet. Jedoch gibt es auch hier
einige Einschränkungen. Dies zeigt sich insbesondere bei den Sequenzdiagrammen.
3.4.2
Klassendiagramme
Die Klassendiagramme besitzen wesentlich mehr unterschiedliche Elemente. Deswegen ist diese Ontologie wesentlich größer als die beiden anderen. Wie im vorherigen Abschnitt erläutert
wurden die verschiedenen Knoten des Graphen durch Klassen abgebildet. Neben diesen Klassen
wurden für die Methoden und Attribute von Klassen bzw. Interfaces eigene Klassen gebildet.
Auf die Beschreibung von Zugriffmodifizierer und Funktionsparameter wurde verzichtet. Die
5
http:://protege.stanford.edu/
81
angestrebten Analysen werden sich vor allem auf die Struktur des Diagramms beziehen. Hierbei
sind diese Elemente nicht von Bedeutung.
Im folgenden wird nicht auf jede Relation eingegangen. Die Darstellung der Ontologie konzentriert sich auf die Klassen. Diese werden in hierarchischer Struktur aufgeführt.
Abbildung 3.8: Struktur der Klassendiagrammontologie
rose:Entity bildet die Oberklasse für Klassen und Interfaces im Graphen. Jede Instanz
besitzt einen Namen (rose:hasName) und Attribute und Methoden (rose:hasMember).
Generalisierungen werden durch rose:isChildOf und rose:isParentOf dargestellt. In den Unterklassen sind Restriktionen gesetzt, so dass Klassen und Interfaces nur
untereinander Generalisierungsbeziehungen haben können.
Abhängigkeitsbeziehungen werden durch die Properties rose:hasDependencyTo und
rose:hasDependant dargestellt. Diese Properties sind zueinander invers. Assoziationsbeziehungen werden nicht mit einer Richtung modelliert. Dies ist eine Vereinfachung
für die XSLT-Gestaltung und hat betrifft keine Auswirkungen auf die Metriken. Eine Assoziation ist so in jedem Fall symmetrisch. Entsprechend ist die Property
rose:isAssociatedTo als symmetrische Property definiert. Die Unterklassen von
rose:Entity sind:
– rose:Class repräsentiert eine UML Klasse. Klassen können Interfaces implementieren (rose:implements).
– rose:Interface repräsentiert ein Interface. Diese besitzen nur Methoden, was
in der Ontologie durch eine Restriktion ausgedrückt wird.
rose:Member ist die Oberklasse für alle einer Klasse oder einem Interface zugehörigen
Elemente. Dies sind in dieser Ontologie Attribute und Operationen. Jedes Element besitzt
82
einen eindeutigen Namen (rose:hasName).
Durch rose:isMemberOf wird eine Klasse oder Interface angegeben, in der das Element verwendet wird. Diese Property ist invers zu rose:hasMember.
– rose:Attribute repräsentiert ein Attribut. Mit rose:hasType wird der Typ
der Variable ebenfalls als String angegeben. Hier wäre es möglich gewesen dies durch
eine Objektproperty abzubilden. Diese würde dann auf Klassen zeigen. Jedoch bedeutet dies einen hohen Aufwand, da jeder Datentyp als Klasse modelliert werden
müsste. Dies ist für Java-API-Klassen wie java.util.Vector nicht lohnenswert und für
Grunddatentypen wie Integer und Float problematisch. Da die Ontologie in OWL DL
ist, kann eine Property nicht gleichzeitig Objekt- und Datatypeproperty sein.
– rose:Method repräsentiert eine Operation der Klasse. Diese Klasse besitzt ebenfalls die Property rose:hasType. Hierdurch wird der Typ des Rückgabewerts angegeben. Es wurde keine weitere Property eingeführt, da jede Abfrage eines Attributs
in Java durch eine entsprechende Funktion substituiert werden kann und hierdurch die
Ontologie einfacher gehalten werden kann.
Durch rose:hasParameter kann eine beliebige Zahl an Parametern angegeben
werden. Hierbei wird der Typ des Parameters jeweils durch einen String angegeben.
Aus denselben Gründen wie bei rose:hasType wurde keine Objektproperty gebildet.
3.4.3
rose:Package stellt eine UML Package dar. Jede Instanz besitzt einen eindeutigen Name (rose:hasName). Ein Package kann einen Rahmen um andere Packages und Entitäten bilden. Dieses wird durch die Relation rose:contains abgebildet. Die dazu
inverse Property rose:isContainedBy besitzt als Domain Packages und Entitäten.
Sequenzdiagramme
Bei den Sequenzdiagrammen zeigen sich die Grenzen der Modellierung als Graph. Die verschiedenen Nachrichten, die zwischen einzelnen Objekten ausgetauscht werden können nicht ohne
weiteres als Kanten eines Graphen verstanden werden. Durch die vertikale Anordnung der Nachrichten wird eine Ordnung auf diesen definiert. Diese abzubilden war die Hauptschwierigkeit bei
diesem Diagrammtyp. Um dies zu ermöglichen wurden die Nachrichten als Klassen abgebildet.
rose:Object repräsentiert ein UML Objekt. Objekte besitzen einen eindeutigen Namen (rose:hasName) und sind Instanz einer UML-Klasse (rose:isInstanceOf).
Die UML-Klasse wird durch einen String benannt und kann auch weggelassen werden.
83
Abbildung 3.9: Struktur der Sequenzdiagrammontologie
Dies ist notwendig, da diese Information oftmals im Diagramm nicht vorhanden ist.
Die Verknüpfung der Nachrichten mit den Objekten erfolgt im Diagramm durch eine
sogenannte Schwimmlinie“. In der Ontologie sind hierzu die beiden Objektproperties
”
rose:isOwnerOf und rose:isTargetOf vorgesehen. Durch die erste Property wird
eine ausgehende Nachricht angegeben, durch die zweite eine eingehende Nachricht. Z.B.
gelten für die Abbildung 3.10 folgende Statements: Scheduler isOwnerOf begin“ und
”
Arbiter isTargetOf begin“.
”
Abbildung 3.10: Beispiel eines Sequenzdiagrammes
rose:Message ist die Oberklasse für alle UML-Nachrichten. Die Unterscheidung der
verschiedenen Nachrichtenarten erfolgt durch Unterklassen. Die Properties rose:hasOwner
und rose:hasTarget sind die inversen Properties zu den entsprechenden Properties
von rose:Object.
Durch rose:isMethod wird für die Nachricht die verwendete Methode bezeichnet.
Hierbei handelt es sich um eine Datatypeproperty des Typs String, da die Methoden nicht
Teil dieser Ontologie sind.
84
Die Ordnung der Statements wird durch die Properties rose:hasSuccessor und
rose:hasPredecessor beschrieben. Diese Objektproperties zeigen auf den Nachfolger bzw. den Vorgänger einer Nachricht. Z.B. gelten für die Abbildung 3.10 folgende
Statements: begin hasSuccessor found“ und found hasPredecessor begin“.
”
”
UML-Nachrichten gibt es in verschiedenen Ausprägungen. Dies wird durch die verschiedenen Unterklassen abgebildet:
– rose:CallMessage repräsentiert eine Call-Nachricht.
– rose:CreateMessage repräsentiert eine Create-Nachricht.
– rose:DestroyMessage repräsentiert eine Destroy-Nachricht.
– rose:ReturnMessage repräsentiert eine Return-Nachricht.
– rose:SendMessage repräsentiert eine Send-Nachricht.
3.4.4
Zustandsdiagramme
Die Zustandsdiagramme werden nur durch Zustände und Transitionen gebildet. Entsprechend
gibt es nur sehr wenige Klassen in dieser Ontologie. Die Abbildung von Transitionen durch Objektproperties scheint zunächst sehr praktisch zu sein, führt jedoch zu Problemen. In der Abbildung 3.12 führen zwei Transitionen von Zustand A zu Zustand B. Jede Transition hat ein anderes
auslösendes Ereignis und eine andere Ausgabe. Man muss also entsprechende Aussagen über die
Properties treffen, was in OWL DL nicht möglich ist. Da die Anzahl der Transitionen beliebig
ist, kann man diese Informationen nicht als eine Property eines beteiligten Zustands abbilden.
Somit müssen Transitionen als eigenständige Klasse abgebildet werden.
Abbildung 3.11: Struktur der Zustandsdiagrammontologie
85
Abbildung 3.12: Beispiel eines Zustandsdiagrammes
rose:State ist die Klasse aller Zustände. Jeder Zustand kann einen Namen besitzen
(rose:hasName). Anonyme Zustände besitzen keinen Namen.
Zustände können andere Zustände als Unterzustände beinhalten. Dies wird durch die Objektproperty rose:isSubstateOf und der dazu inversen Objectproperty
rose:isSuperstateOf abgebildet.
Auf die vom Zustand ausgehenden Transitionen zeigt die Objektproperty
rose:hasOutgoingTransition und auf eingehende Transitionen die Property
rose:hasIngoingTransition. Z.B. gelten in der Abbildung 3.12 folgende Statements: Warten hasOutgoingTransition Starten“ und Aktiv hasIngoingTransition Star”
”
ten“.
– rose:Endstate repräsentiert einen Endzustand. Diese Untermenge der Zustände
besitzt die Restriktion, dass der Zustand keine ausgehenden Transitionen besitzen
darf.
– rose:Startstate repräsentiert einen Startzustand. Diese Untermenge der Zustände
besitzt die Restriktion, dass der Zustand keine eingehenden Transitionen besitzen
darf.
rose:Transition bildet die Menge der Transitionen. Die Properties rose:goesTo
und rose:isFrom zeigen auf die beiden Enden der Transition. Sie sind die Inversen
zu den entsprechenden Properties von rose:State. Transitionen können einen Namen
rose:hasName, ein auslösendes Ereignis rose:hasTrigger, eine Transitionsbedingung rose:hasCondition und eine Ausgabe rose:hasOutput besitzen. Dies sind
Datatypeproperties des Typs String.
86
3.5
XMI - OWL Umwandlungen: Dirk Siemers
Um XMI-Dokumente in eine OWL-Form zu bringen, wurden zunächst einzelne UML-Diagramme
erzeugt und als XMI-Dokumente exportiert. Die inhaltlichen Aussagen der Diagramme wurden
dann mit Protege in OWL-Ontologien gebracht und als owl-Dokumente gespeichert. Das Ergebnis sind zwei Dokumenttypen, die zwar unterschiedliche Struktur haben, jedoch für das Projekt
die gleichen Inhalte besitzen. Ziel ist es nun den Inhalt aus dem Quell-XMI-Dokument in ein
Ergebnis-OWL-Dokument mit XSLT und XPath umzuwandeln. Die speziellen Umwandlungsschritte werden nun für die drei möglichen Diagrammtypen erläutert.
3.5.1
Klassendiagramme
Jedes mit Protege gespeicherte OWL-Dokument besteht zunächst aus einer Schemabeschreibung, die vor dem eigentlichen Inhalt des Dokuments aufgelistet wird. Durch die Nutzung von
Jena ist es jedoch nicht zwingend notwendig diese vor den inhaltlichen Aussagen des OWLDokumentes aufzuführen. Ohne eine Schemabeschreibung wirkt das XSLT kompakter und lässt
sich bedeutend besser lesen. Das XSLT-Grundgerüst für ein Klassendiagramm-OWL sieht folgendermassen aus:
<x s l : s t y l e s h e e t
<x s l : o u t p u t
y e s ” />
x m l n s : x s l =” h t t p : / / www. w3 . o r g / 1 9 9 9 / XSL / T r a n s f o r m ”
xmlns:UML=” o r g . omg . xmi . n a m e s p a c e .UML”
xmlns =” h t t p : / / www. i n f o r m a t i k . u n i o l d e n b u r g . de / r o s e # ”
x m l n s : r d f =” h t t p : / / www. w3 . o r g / 1 9 9 9 / 0 2 / 2 2 r d f s y n t a x n s #
”
x m l n s : r d f s =” h t t p : / / www. w3 . o r g / 2 0 0 0 / 0 1 / rdf schema # ”
x m l : b a s e =” h t t p : / / www. i n f o r m a t i k . u n i o l d e n b u r g . de / r o s e ”
x m l n s : o w l =” h t t p : / / www. w3 . o r g / 2 0 0 2 / 0 7 / owl # ”
v e r s i o n =” 1 . 0 ”>
method =” xml ” v e r s i o n =” 1 . 0 ” e n c o d i n g =” iso 8859 1 ” i n d e n t =”
< x s l : t e m p l a t e match =” / ”>
<r d f : R D F>
<x s l : a p p l y t e m p l a t e s
UML:Model ” / >
< / r d f : R D F>
< / x s l : t e m p l a t e>
s e l e c t =” / XMI / XMI . c o n t e n t /
87
Der Aufbau beschränkt sich auf die Standartelemente eines XSLT mit einer großen Namespacedefinition und einem Template, welches den Wurzelknoten des Dokuments auswählt. Durch
die Auswahl des Wurzelknotens wird das erste Element in das Ergebnisdokument eingetragen: <rdf:RDF>. Dies ist der Wurzelknoten des OWL-Dokuments. Das xsl:output-Element
im XSLT legt fest, dass das Ergebnisdokument ebenfalls ein xml-Dokument ist. Der eigentliche Inhalt des XMI-Dokuments wird über ein Template mit dem absoluten Lokalisierungspfad
/XMI/XMI.content/UML:Model angegeben. Ab diesem Knoten werden Inhalte aus dem XMIQuelldokument mit Hilfe von einzelnen Teplates in das OWL-Ergebnisdokument eingetragen.
Für den angegebenen Templatepfad /XMI/XMI.content/UML:Model muss es ein zu matchendes
Template geben. Dieses sieht folgendermaße aus:
< x s l : t e m p l a t e match =” / XMI / XMI . c o n t e n t / UML:Model ”>
< x s l : a p p l y t e m p l a t e s s e l e c t =” UML:Packages ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” UML:Namespace . ownedElement ” />
< / x s l : t e m p l a t e>
Klassendiagramme können Packages beinhalten, welche wiederum Klassen oder Interfaces beinhalten. In dem XMI-Dokument wird zwischen diesen Elementen unterschieden, ihre Zugehörigkeit wird hierarchisch abgebildet. Gehört eine Klasse oder ein Interface zu einem Package, so
sind sie Nachfahren des Package-Knotens. Im XMI-Dokument gehören jedoch nicht nur Klassen und Interfaces zu einem Package, sondern alle Elemente, die unter dem Knoten
UML:Namespace.ownedElement aufgelistet sind. Ein Package selber kann ebenfalls einem übergeodnetem Package zugeordnet sein. Dieses Template produziert keinen weiteren Inhalt im Ergebnisdokument, verweist jedoch auf zwei weitere Templates. Das wichtigere der beiden Templates ist das Folgende:
< x s l : t e m p l a t e match =” UML:Namespace . ownedElement ”>
< x s l : a p p l y t e m p l a t e s s e l e c t =” UML:Class ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : I n t e r f a c e ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : G e n e r a l i z a t i o n ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : A b s t r a c t i o n ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” UML:Dependency ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : A s s o c i a t i o n ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” UML:Package ” />
< / x s l : t e m p l a t e>
In diesem Template wird kein Inhalt für das Ergebinsdokument produziert, es wird auf mehrere
Templates verwiesen. Durch diese Templateverschachtelung, können Templates z.B. für mehrere Klassen wiederverwendet werden. Ein weiterer Vorteil dieser Anordnung ist die rekursive
88
Verwendung der Templates. So können Elemente eines Packages einfach durch Wiederverwendung dieses Templates ausgewertet werden. Ein mögliches Element stellt eine Klasse dar, dessen
Template folgendermaßen aussieht.
<!
TEMPLATE f u e r d i e K l a s s e n
>
< x s l : t e m p l a t e match =” UML:Class ”>
< x s l : i f t e s t =” a t t r i b u t e : : v i s i b i l i t y ”>
< ! ID d e r K l a s s e >
< C l a s s r d f : I D =” f a t t r i b u t e : : x m i . i d g ”>
< ! Name d e r K l a s s e >
<hasName r d f : d a t a t y p e =” h t t p : / / www. w3 . o r g / 2 0 0 1 /
XMLSchema# s t r i n g ”>
< x s l : v a l u e o f s e l e c t =” a t t r i b u t e : : n a m e ” />
< / hasName>
<! T e s t a u f e i n e P a k e t a b h a e n i g k e i t >
< x s l : i f t e s t =” p a r e n t : : / p a r e n t : : /
a t t r i b u t e : : v i s i b i l i t y ”>

</ x s l : i f>
<! E i n f u e g e n d e r K l a s s e n e i g e n s c h a f t e n >
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : C l a s s i f i e r . f e a t u r e ” />
< / C l a s s>
</ x s l : i f>
< / x s l : t e m p l a t e>
Das Template für Klassen testet vor Gebrauch, ob das XMI-Element UML:Class ein Attribut
visibility besitzt, welches angibt, ob die Klasse eine sichtbare Klasse des im UML-Diagramm
ist. Wird beispielsweise ein Stringwert für ein Attribut benutzt, so wird im XMI-Dokument eine
Klasse mit dem Namen String erstellt. Diese Klasse gehört nicht zur direkten Auswertung und
soll somit nicht berücksichtigt werden. Alle sichtbaren Klassen werden jedoch mit dem Element
<Class> in das Ergebnisdokument eingetragen. Das Attribut rdf:ID beschreibt eine eindeutige
Identifizierung der Klasse, welche über das Attribut xmi.id aus dem XMI-Dokument extrahiert
wird. Dies ist nur möglich, da bei der Erstellung von XMI-Dokumenten ebenfalls eindeutige
IDs für die Identifizierung der Klassen benutzt werden. Das erste Kindelement, welches zu der
Klasse im Ergebnisdokument gehört ist das hasName-Element. Dieses wird einfach über das
Attribute name aus dem XMI-Dokument ausgelesen. Es folgt eine weiterer Test auf die Paketzugehörigkeit der Klasse. Wie schon erwähnt, können Klassen direkte Nachfahren von Paketen
89
sein. In diesem Test wird mit der Überprüfung des Attributes visibility nachgesehen, ob ein Paket
in dem Diagramm sichtbar ist, oder nicht. Pakete die kein visibility-Attribut haben sind Pakete,
die nicht zur direkten UML-Modellierug gehören, daher müssen sie vernachlässigt werden. Ist
jedoch eine Paketzugehörigkeit festgestellt worden, so wird das Element <isContainedBy>
mit dem Attribute rdf:resource und der ID des zugehörgen Pakets als Wert in dem Ergebnisdokument eingetragen. Das letzte Element des Klassentemplates ist ein Verweiß auf das Klasseneigenschaftentemplate. Es behandelt den Unterknoten UML:Classifier.feature im XMI-Dokument,
welcher sowohl von Klassen, als auch von Interfaces genutzt wird. Zur Wiederverwendung wurder daher ein eigenes Template entworfen:
<!
TEMPLATE f u e r d i e K l a s s e n e i g e n s c h a f t e n
>
< x s l : t e m p l a t e match =” U M L : C l a s s i f i e r . f e a t u r e ”>
<! A t t r i b u t e d e r K l a s s e n e i n f u e g e n >
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : A t t r i b u t e ” />
<! O p e r a t i o n e n d e r K l a s s e n e i n f u e g e n >
< x s l : a p p l y t e m p l a t e s s e l e c t =” UML:Operation ” />
< / x s l : t e m p l a t e>
Dieses Template ist nur ein “Zwischentemplate“ um die mehrfach vorkommenden Attribute und
Operationen einer Klasse auch in deren Häufigkeit in das Ergebnisdokument einzutragen. Der
weitere Aufbau des XSLT-Dokuments wird nun beispielhaft an einem Atribut-Template verdeutlicht:
<!
TEMPLATE f u e r d i e A t t r i b u t e
>
< x s l : t e m p l a t e match =” U M L : A t t r i b u t e ”>
<hasMember>
< ! ID d e s A t t r i b u t s >
< A t t r i b u t e r d f : I D =” f@xmi . i d g ”>
< ! Typ d e s A t r i b u t s >
<h a s T y p e r d f : d a t a t y p e =” h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema#
s t r i n g ”>
< x s l : v a r i a b l e name=” i d r e f ” s e l e c t =” c h i l d : : / c h i l d : : /
a t t r i b u t e : : x m i . i d r e f ” />
< x s l : v a l u e o f s e l e c t =” / XMI / XMI . c o n t e n t / UML:Model /
UML:Namespace . ownedElement / UML:Package / UML:Namespace .
ownedElement / UML:Package / UML:Namespace . ownedElement /
c h i l d : : [ a t t r i b u t e : : x m i . i d =$ i d r e f ] / a t t r i b u t e : : n a m e ” / >
< / h a s T y p e>
90
<hasName
r d f : d a t a t y p e =” h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema#
s t r i n g ”>
< x s l : v a l u e o f s e l e c t =” p a r e n t : : / p a r e n t : : / a t t r i b u t e : : n a m e ”
/>
< x s l : t e x t> .< / x s l : t e x t>
< x s l : v a l u e o f s e l e c t =”@name” />
< / hasName>
<isMemberOf r d f : r e s o u r c e =” # f p a r e n t : : / p a r e n t : : /
a t t r i b u t e : : x m i . i d g ” />
< / A t t r i b u t e>
< / hasMember>
< / x s l : t e m p l a t e>
Attribute und Methoden werden im Ergebnisdokument innerhalb von Klassen mit dem Element
<hasMember> dargestellt. Diese wiederum beinhalten entweder ein <Attribute>- oder ein
<Method>-Element. Hier wird ein Attribut mit dem dazugehörigen <Attribute>-Element
dargestellt. Es besitzt eine eindeutige ID, welche wie bei der Klasse einfach durch das xmi.idAttribut genutzt werden kann. Das Element <hasType> ist schwieriger zu bestimmen, da der
Typ nur eine Referenz auf ein im XMI-Dokument angegebenes Element ist. Für die Bestimmung des referenzierten Elements wird zunächst die ReferenzID als Variable gespeichert und
dann mit xmi.id-Attributen von bestimmten Elementen im XMI-Baum verglichen. Gibt es eine
Übereinstimmung, so wird das Attribut name des übereinstimmenden Elements als Inhalt für das
Element <hasType> in das Ergebnisdokument eingetragen, z.B. “float“.
Der Name eines Attributes setzt sich aus dem Namen der Klasse und dem Namen des Attributs
zusammen, wobei beide mit einem Punkt voneinander getrennt werden. Diese Zusammensetzung wird als Inhalt in einem <hasName>-Element angegeben. Um die Zugehörigkeit eines
Attributes noch besser bestimmen zu können, wird diese in der Ontologie nicht nur über den
Namen, sondern auch über ein <isMemberOf>-Element festgelegt. Das <isMemberOf>Element beinhaltet nämlich eine Referenz auf die ID der dazugehörigen Klasse, welche im Großvaterknoten des Attributes, der Klasse, abgelegt ist.
Der prinzipielle Inhaltsaufbau für Klassen ist somit erläutert, jedoch beschränkt sich ein UMLDiagramm nicht nur auf Klassen sondern auch noch auf die Beziehungen zwischen den Klassen.
Beziehungen wurde bereits im Template für den Knoten UML:Namespace.ownedElement angesprochen. Das folgende Beispiel zeigt ein Template zur Erstellung von Vererbungsbeziehungen
zwischen zwei Klassen:
<!
TEMPLATE f u e r d i e G e n e r a l i s i e r u n g
>
< x s l : t e m p l a t e match =” U M L : G e n e r a l i z a t i o n ”>
91
< x s l : c h o o s e>
< x s l : w h e n t e s t =” U M L : G e n e r a l i z a t i o n . c h i l d / UML:Class ”>
< C l a s s r d f : I D =” f U M L : G e n e r a l i z a t i o n . c h i l d / UML:Class /
a t t r i b u t e : : x m i . i d r e f g ”>

< / C l a s s>
< / x s l : w h e n>
< x s l : w h e n t e s t =” U M L : G e n e r a l i z a t i o n . c h i l d / U M L : I n t e r f a c e ”>



< / x s l : w h e n>
< / x s l : c h o o s e>
< / x s l : t e m p l a t e>
Bei einer Vererbungsbeziehung für Klassen können entweder Klassen von Klassen oder Interfaces von Interfaces vererbt werden. Bei der Transformation muss also geprüft werden, ob das
“Kind“ der Generalisierung eine Klasse oder ein Interface ist. Diese Überprüfung wird hier
durch ein <xsl:choose>-Element vorgenommen. Der zu prüfende Wert wird in dem testAttribut festgelegt. Gibt es eine Übereinstimmung von Testausdruck und Knoten, so wird der
nachfolgende Inhalt in das Ergebnisdokument eingetragen. Die Generalisierungspartner werden
im XMI-Dokument in zwei unterschiedlichen Knoten dargestellt. Das “Kind“ steht in dem Knoten UML:Generalisierung:child, der Vater in dem Knoten UML:Generalisierung:parent.
3.5.2
Zustandsdiagramme
In einem Zustandsdiagramm wird generell zwischen Zuständen und Transitionen unterschieden. In einem XMI-Dokument ist dieses nicht anders. So werden Zustände und Unterzustände
in dem Knoten UML:StateMachine.top gespeichert, wobei die Transitionen unter dem Knoten UML:StateMachine.transitions gespeichert werden. Ziel des XSLT-Dokuments ist es die
Zustände und deren Transitionen auszulesen und umgeformt in das Ergebnisdokument einzutragen. Daher beginnt das XSLT-Stylesheet mit einem Template, welches den Wurzelknoten des
XMI-Dokuments auswählt und das rdf:RDF-Element in das Ergebnisdokument einträgt. Es folgen die beiden Templates für die Auswahl der Zustände und der Transitionen. Vergleichen Sie
92
folgenden Abschnitt:
<r d f : R D F>
<! Z u s t a e n d e >
<x s l : a p p l y t e m p l a t e s
s e l e c t =” / XMI / XMI . c o n t e n t / UML:StateMachine /
UML:StateMachine . t o p / U M L : C o m p o s i t e S t a t e / U M L : C o m p o s i t e S t a t e .
s u b v e r t e x ” />
<! T r a n s i t i o n e n >
< x s l : a p p l y t e m p l a t e s s e l e c t =” / XMI / XMI . c o n t e n t / UML:StateMachine /
UML:StateMachine . t r a n s i t i o n s ” / >
< / r d f : R D F>
< / x s l : t e m p l a t e>
Hier das entsprechende Template für die Zustände:
<!
Zustaende
>
< x s l : t e m p l a t e match =” / XMI / XMI . c o n t e n t / UML:StateMachine /
UML:StateMachine . t o p / U M L : C o m p o s i t e S t a t e / U M L : C o m p o s i t e S t a t e .
s u b v e r t e x ”>
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : P s e u d o s t a t e ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : S i m p l e S t a t e ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : F i n a l S t a t e ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : C o m p o s i t e S t a t e ” />
< / x s l : t e m p l a t e>
In Zustandsdiagrammen wird zwischen 4 “Zustandsarten“ unterschieden. Das Template für einen
Startzustand wird über den Vergleich mit dem Element UML:Pseudostate, das für einen Endzustand mit dem Element UML:FinalState aufgerufen wird. Einfache Zustände werden über das
Element UML:SimpleState und “Oberzustände“ mit dem Element UML:CompositeState verglichen. Das interessanteste Konstrukt dieser Zustände ist der “Oberzustand“. Dieser wird nicht nur
als Zustand verwendet, sondern kann auch mit anderen Zuständen Transitionen besitzen, und
beinhaltet wiederum eigene Start-, End-, Simple- und “Oberzustände. Das Template für diesen
Zustand sieht folgendermassen aus:
<!
TEMPLATE f u e r e i n e n O b e r z u s t a n d
>
< x s l : t e m p l a t e match =” U M L : C o m p o s i t e S t a t e ”>
< ! ID d e s Z u s t a n d s >
< S t a t e r d f : I D =” f c o n c a t ( ’ ROSE ’ , s u b s t r i n g
< ! Name d e s Z u s t a n d s >
a f t e r ( @xmi . i d , ’ :
’ ) ) g ”>
93
<hasName
r d f : d a t a t y p e =” h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema#
s t r i n g ”>
< x s l : v a l u e o f s e l e c t =”@name” />
< / hasName>
<! E i n f u e g e n d e r e i n g e h e n d e n T r a n s i t i o n e n >
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : S t a t e V e r t e x . i n c o m i n g ” />
<! E i n f u e g e n d e r a u s g e h e n d e n T r a n s i t i o n e n >
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : S t a t e V e r t e x . o u t g o i n g ” />
<! A u f e i n e n U n t e r z u s t a n d p r u e f e n >
< x s l : f o r e a c h s e l e c t =” U M L : C o m p o s i t e S t a t e . s u b v e r t e x / c h i l d : : ”
>

substring
< / x s l : f o r e a c h>
< / S t a t e>
<! E i n f u e g e n d e r U n t e r z u s t a e n d e >
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : C o m p o s i t e S t a t e . s u b v e r t e x ” />
< / x s l : t e m p l a t e>
Das Template beginnt mit dem zu vergleichenden Element UML:CompositeState. Wird dieses
Element gefunden, so wird ein State-Element in das Ergebnisdokument eingetragen. Dieses Element bekommt eine ID zugewiesen, die aus dem Attribut xmi.id des Elements UML:CompositeState
ausgelesen wird. Die ID wird vorher nach einem bestimmten Muster mittels substring-after() gefiltert und mit dem Präfix ROSE über concat() versehen. Dies ist notwendig, da die ID in einem
OWL-Dokument sonst ungültig werden könnte.
Nachdem nun das State-Element gesetzt worden ist, folgt das Elemente hasName mit dem Namen des Zustands. Die beiden folgenden Templates behandeln evtl. Transitionen des Zustands.
Hier der Inhal der Templates:
<!
Template f u e r die eingehende T r a n s i t i o n
>
< x s l : t e m p l a t e match =” U M L : S t a t e V e r t e x . i n c o m i n g ”>
< h a s I n g o i n g T r a n s i t i o n r d f : r e s o u r c e =” # f c o n c a t ( ’ ROSE ’ ,
s u b s t r i n g a f t e r ( c h i l d : : / a t t r i b u t e : : x m i . i d r e f , ’ : ’ ) ) g ” />
< / x s l : t e m p l a t e>
<!
Template f u e r die ausgehende T r a n s i t i o n
>
< x s l : t e m p l a t e match =” U M L : S t a t e V e r t e x . o u t g o i n g ”>
< h a s O u t g o i n g T r a n s i t i o n r d f : r e s o u r c e =” # f c o n c a t ( ’ ROSE ’ ,
s u b s t r i n g a f t e r ( c h i l d : : / a t t r i b u t e : : x m i . i d r e f , ’ : ’ ) ) g ” />
94
< / x s l : t e m p l a t e>
Durch den Gebrauch von Templates für eingehende, bzw. ausgehende Transitionen können diese
Templates auch bei Start-, End-, und SimpleStates genutzt werden. Für das hasIngoingTransition- bzw. hasOutgoingTransition-Element wird als Attribut das Attribut xmi.idref auf die referenzierte Transition benutzt. Diese ID wurde wiederum mit concat() und substring-after() behandelt. Das nächste Element eines “Oberzutands“ ist das isSuperstateOf -Element. Dieses fügt alle
Unterzustände zu dem Zustand hinzu:
<!
Auf e i n e n U n t e r z u s t a n d p r u e f e n
>
< x s l : f o r e a c h s e l e c t =” U M L : C o m p o s i t e S t a t e . s u b v e r t e x / c h i l d : : ”>

< / x s l : f o r e a c h>
Damit Unterzustände zu dem Zustand eingetragen werden können, muss der Zustand “Enkelkinder“Knoten besitzen. Diese werden mit dem select-Statement in dem xsl:for-each-Element übergeprüft. Es wird dabei bewusst auf “Enkelkinder“ getestet, da alle vier Zustandsarten Unterzustände des Zustands sein können. Sind Elemente vorhanden, so wird von jedem Element das
xmi.id-Attribut als Referenzattribut des Elements isSuperstateOf mit der bekannten Umwandlung angegeben. Nachdem der “Oberzustand“ mit dem EndTag State beendet wird, folgen nun
alle Unterzustände mit dem Verweiss auf das folgende Template:
<! D i e s s i n d U n t e r z u s t a e n d e >
< x s l : t e m p l a t e match =” / U M L : C o m p o s i t e S t a t e . s u b v e r t e x ”>
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : P s e u d o s t a t e ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : S i m p l e S t a t e ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : F i n a l S t a t e ” />
< x s l : a p p l y t e m p l a t e s s e l e c t =” U M L : C o m p o s i t e S t a t e ” />
< / x s l : t e m p l a t e>
Durch dieses Anordnung der Templates können alle Zustände des Diagramms rekursiv in das
Ergebnisdokument eingetragen werden.
Das Ergebnisdokument enthält bis jetzt alle Zustände mit deren Verweise auf eingehende und
ausgehenden Transitionen. Diese Transitionen werden durch ein eigenes Template in das Ergebnisdokument eingetragen:
<x s l : t e m p l a t e
match =” / XMI / XMI . c o n t e n t / UML:StateMachine /
UML:StateMachine . t r a n s i t i o n s / U M L : T r a n s i t i o n ”>
< T r a n s i t i o n r d f : I D =” f c o n c a t ( ’ ROSE ’ , s u b s t r i n g a f t e r ( a t t r i b u t e : : x m i .
i d , ’ : ’ ) ) g ”>
<!
95
Name d e r T r a n s i t i o n
>
<hasName r d f : d a t a t y p e =” h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema# s t r i n g ”>
< / hasName>

<goesTo
r d f : r e s o u r c e =” # f c o n c a t ( ’ ROSE ’ , s u b s t r i n g a f t e r (
UML:Transition . t a r g e t / c h i l d : : / a t t r i b u t e : : x m i . i d r e f , ’ :
>
<x s l : a p p l y
<x s l : a p p l y
<x s l : a p p l y
< / T r a n s i t i o n>
< / x s l : t e m p l a t e>
’ ) ) g” /
t e m p l a t e s s e l e c t =” U M L : T r a n s i t i o n . g u a r d ” / >
t e m p l a t e s s e l e c t =” U M L : T r a n s i t i o n . e f f e c t ” / >
t e m p l a t e s s e l e c t =” U M L : T r a n s i t i o n . t r i g g e r ” / >
Transitionen werden wie ihre Zustände mit einer eigenen eindeutigen ID versehen. Diese ID
wird in das Transition-Element als Attribut eingetragen. In diesem Element wird zunächst der
Name der Transition mit dem hasName-Element eingetragen. Es folgen die Elemente isFrom
und goesTo. Diese Elemente verweisen auf den Anfang und das Ende der Transition. Als Attribut
der Elemente wird eine Referenz auf die Transitionspartner angegeben. Eine Transitionen kann
ein Ereignis, eine Bedingung und eine Operation besitzen. Diese möglichen Erweiterungen der
Transition werden mit Templates behandelt, da sie nicht unbedingt auftreten müssen.
< x s l : t e m p l a t e match =” U M L : T r a n s i t i o n . g u a r d ”>
< h a s C o n d i t i o n r d f : d a t a t y p e =” h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema# s t r i n g ”
>
< x s l : v a l u e o f s e l e c t =” c h i l d : : / a t t r i b u t e : : n a m e ” />
< / h a s C o n d i t i o n>
< / x s l : t e m p l a t e>
Dieses Beispiel zeigt exemplarisch das Template für eine Bedingung. Existiert eine Bedinung,
so ist es nur wichtig, dass diese als Element der Transition vorkommt. Der eigentliche Inhalt der
Bedingung ist nebensächlich, daher wird nur der Name der Bedingung als Inhalt des hasCondition-Elements verwendet. So kann später überprüft werden, ob die richtige Bedingung zu einer
Transition ausgewählt wurde.
Der Aufbau eines XSLT-Stylesheet für Zustandsdiagramme ist damit exemplarisch beschrieben.
Der genaue Inhalt des Dokuments wird im Anhang aufgelistet.
3.5.3
96
Sequenzdiagramme
Für Sequenzdiagramme gibt es nur zwei wichtige Bestandteile. Diese sind Objekte und Nachrichten. In einem XMI-Dokument werden diese beiden Bestandteile als Elemente des Diagramms
gesehen. Sie werden in dem folgedem Template mit Templateaufrufen speziell ausgewählt um
sie daraufhin in das Ergebnisdokument einzutragen.
<r d f : R D F>
< ! T e m p l a t e ü f r d i e O b j e k t e >
< x s l : a p p l y t e m p l a t e s s e l e c t =” / XMI / XMI . c o n t e n t / UML:Model /
UML:Namespace . ownedElement / U M L : C o l l a b o r a t i o n / UML:Namespace .
ownedElement / UML:Object ” / >
< ! T e m p l a t e ü f r d i e M e s s a g e s >
< x s l : a p p l y t e m p l a t e s s e l e c t =” / XMI / XMI . c o n t e n t / UML:Model /
UML:Namespace . ownedElement / U M L : C o l l a b o r a t i o n / UML:Namespace .
ownedElement / UML:Message ” / >
< / r d f : R D F>
< / x s l : t e m p l a t e>
Wie für die anderen Diagramtypen auch, wird zuerst der Wurzelknoten des Dokuments ausgewählt um dann das rdf:RDF-Element als Start-Tag in das OWL-Ergebnisdokument einzutragen. Die beiden nächsten Aufrufe wählen den Inhalt für Sequenzdiagramme mit Hilfe von
Templates aus. Es wird zunächst das Template für Objekte betrachtet:
<!
TEMPLATE f u e r d i e O b j e k t e
>
< x s l : t e m p l a t e match =” / XMI / XMI . c o n t e n t / UML:Model / UML:Namespace .
ownedElement / U M L : C o l l a b o r a t i o n / UML:Namespace . ownedElement /
UML:Object ”>
< ! ID d e s O b j e k t s >
< O b j e c t r d f : I D =” f a t t r i b u t e : : x m i . i d g ”>
< ! Name d e s O b j e k t s >
<hasName r d f : d a t a t y p e =” h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema# s t r i n g ”>
< / hasName>
< / O b j e c t>
< / x s l : t e m p l a t e>
Die wichtigste Eigenschaft für ein Objekt ist die ID. Diese wird aus dem Attribut xmi.id aus dem
Quellbaum entnommen und dann als Attribut des Objekts in das Ergebnisdokument eingetragen.
97
Der Name des Objekts wird zunächst nur für Korrekturzwecke mit in das OWL-Dokument eingetragen. Er wird als Inhalt in dem Element hasName aus dem Attribut name eingetragen.
Für Objekte ist es nur wichtig, dass sie eine eindeutige ID besitzen, auf der die ein-, bzw. ausgehenden Nachrichten referenzieren können. Zur Veranschaulichung wird nun ein Teil des Message-Templates betrachtet:
<!
TEMPLATE f u e r d i e M e s s a g e s
>
< x s l : t e m p l a t e match =” / XMI / XMI . c o n t e n t / UML:Model / UML:Namespace .
ownedElement / U M L : C o l l a b o r a t i o n / UML:Namespace . ownedElement /
UML:Message ”>
< ! Typ d e r Message h e r a u s f i n d e n
B e v o r d e r äß u e r e Tag g e s e t z t werden kann muss h e r a u s g e f u n d e n
werden ,
w e l c h e U n t e r k l a s s e v o r l i e g t . Die U n t e r k l a s s e n s i n d :
CreateMessage
DestroyMessage
ReturnMessage
CallMessage
SendMessage
>
< ! Der Typ s t e h t i n dem k o r r e s p o n d i e r e n d e n U M L :S t i m u l us >
< x s l : v a r i a b l e name=” s t i m u l u s I d ” s e l e c t =” UML:Message .
c o n f o r m i n g S t i m u l u s / UML:Stimulus / a t t r i b u t e : : x m i . i d r e f ” / >
< x s l : c h o o s e>
<! C r e a t e A c t i o n >
< x s l : w h e n t e s t =” p a r e n t : : / UML:Stimulus [ @xmi . i d =$ s t i m u l u s I d ] /
UML:Stimulus . d i s p a t c h A c t i o n / U M L : C r e a t e A c t i o n ”>
< C r e a t e M e s s a g e r d f : I D =” f@xmi . i d g ”>
< ! Name d e r A c t i o n >
<hasName r d f : d a t a t y p e =” h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema#
s t r i n g ”>
< x s l : v a l u e o f s e l e c t =” . . / UML:Stimulus [ @xmi . i d =$ s t i m u l u s I d
] / a t t r i b u t e : : n a m e ” />
< / hasName>
< ! Owner d e r A c t i o n >
<hasOwner r d f : r e s o u r c e =” # f p a r e n t : : / UML:Stimulus [ @xmi . i d =$
s t i m u l u s I d ] / UML:Stimulus . s e n d e r / UML:Object / @xmi . i d r e f g ” / >
<! Z i e l d e r A c t i o n >
98
<h a s T a r g e t
r d f : r e s o u r c e =” # f p a r e n t : : / UML:Stimulus [ @xmi . i d =$
s t i m u l u s I d ] / UML:Stimulus . r e c e i v e r / UML:Object / @xmi . i d r e f g ”
/>
<! T e s t a u f v o r a u s g e h e n d e n A u f r u f >
< x s l : i f t e s t =” UML:Message . p r e d e c e s s o r / UML:Message / @xmi . i d r e f
”>
< h a s P r e d e c e s s o r r d f : r e s o u r c e =” # f UML:Message . p r e d e c e s s o r /
UML:Message / @xmi . i d r e f g ” / >
</ x s l : i f>
< / C r e a t e M e s s a g e>
< / x s l : w h e n>
< / x s l : c h o o s e>
< / x s l : t e m p l a t e>
Für jede Nachricht wird zunächst die ID aus dem XMI als Variable stimulusID gespeichert.
In der Ontologie wurden 5 Nachrichtentypen für Sequenzdiagramme festgelegt: CreateMessage, DestroyMessage, ReturnMessage, CallMessage und SendMessage. Diese 5 Typen gilt es nun
auch in dem XSLT zu unterscheiden. Mit dem Schlüsselwort xsl:choose werden 5 Möglichkeiten
geboten, die gespeicherte stimulusID der Message mit einer ID eines Stimulus zu vergleichen:
UML:Stimulus[@xmi.id=$stimulusId]
Gibt es eine Übereinstimmung von xmi.id und stimulusID muss der darauffolgende relative Pfad
zu einem Nachichtentypen stimmen. In dem Beispiel wurde exemplarisch eine CreateMessage
ausgewählt um den weiteren Inhalt des XSLTs zu beschreiben.
Erst wenn der Nachrichtentyp feststeht, kann das Start-Tag für die spezifische Nachricht gesetzt
werden. In diesem Fall wäre es das CreateMessage-Element. Wichtig dabei ist, dass als ID der
Nachricht die ID der Message und nicht des Stimulus angegeben wird. Jede Nachricht bekommt
zur Kontrolle einen Namen über das hasName-Element. Die beiden Elemente hasOwner und hasTarget verweisen jeweils auf Objekte die entweder Empfänger oder Sender der Nachricht sind.
Der letzte Teil des Templates ist ein Test auf einen vorausgehnden Aufruf. Besteht dieser Aufruf,
so wird das Element hasPredecessor mit der referenzierten Message mit in das Ergebnisdokument eingetragen.
3.6
3.6.1
99
Entwurfsmonitoring durch Metriken: Christian Dänekas
Konzept und Ausgangssituation
Die Konzepte der Softwarevermessung und einige bekannte Metriken, die nach diesen Konzepten entwickelt wurden, sind ihnen bereits vorgestellt worden. Das Ziel, welches im Rahmen des
Projekts verfolgt wird, ist die Unterstützung der Softwareentwicklung im Stadium des Entwurfs
durch Messungen. An diesem Punkt wird bereits ein großer Schwachpunkt bzw. eine zentrale Unzulänglichkeit der Tätigkeiten im Software-Measurement deutlich. Die Messtätigkeiten an
der Software finden bei den vorgestellten Konzepten erst auf Basis des Quellcodes statt. Dieser
wiederum liegt erst spät im Software-Entwicklungsprozess vor.
Hinzu kommt, dass sich viele Merkmale eines Softwareprodukts auch erst beurteilen lassen,
wenn es lauffähig ist. Reaktionszeiten von Softwareprogrammen sind ein gutes Beispiel. Auch
viele Fehler werden erst spät sichtbar. Generell findet man schneller messbare Größen, wenn
das Angebot an Daten, welches als Material zur Auswertung zur Verfügung steht, zunimmt. Je
näher sich das Produkt seiner Fertigstellung nähert, desto größer wird die Datenbasis, auf der
Messungen durchgeführt werden können und desto konkreter werden die Aussagen, die sich aus
den vorliegenden Daten ableiten lassen.
Aus der erst späten Beurteilung von Software ergibt sich das Problem, dass die Wahrscheinlichkeit, schwerwiegende Fehler übersehen zu haben, ebenfalls zunimmt. Daher erscheint es
wünschenswert, möglichst viele Informationen bereits früh im Projektverlauf zu sammeln und
auszuwerten. Prozessmodelle wie das Wasserfallmodell und seine verfeinerten und erweiterten
Nachfolger leisten in diesem Bereich bereits einen wichtigen Beitrag. Die Aufteilung der Tätigkeiten im Entwicklungsprozess macht die Masse der vorliegenden Aufgaben besser begreifbar.
Wie aber bereits vorgestellt wurde, sind Reviews und Metriken notwendig, um die Ergebnisse
einzelner Tätigkeiten messen, festhalten, darstellen und gegenüber den dafür definierten Anforderungen aus- und bewerten zu können. Es ist wünschenswert, eben diese Methoden im Idealfall
softwaregestützt durchführen zu können. Dies stellt zum einen eine große Herausforderung dar,
aufgrund der vorgestellten erschwerten Fassbarkeit von Software, jedoch bietet sich hier auch
die Möglichkeit, den Anstoß zu geben für eine den gesamten Software-Engineering-Prozess begleitende softwaregestützte Vermessung und Beurteilung des entstehenden Softwareprodukts.
Das Datenmaterial, welches im Entwurfsprozess vorliegt und auf dem der Fokus in diesem Projekt liegt, ergibt sich aus UML-Modellen. Diese visualisieren die Software und geben Auskunft
100
über Anwendungsfälle, die Architektur der modellierten Software, Kontroll- und Datenflüsse
usw.. Die Abstraktion, die durch ein Modell stattfindet, bietet den Vorteil der besseren Visualisierung eines komplexen Sachverhaltes. Da Softwaresysteme wie vorgestellt sehr komplex sein
können, ist die Übersicht, die durch ein solches Modell entsteht, gerade in der noch relativ frühen
Phase der Softwareentwicklung natürlich von großem Wert. Jedoch offenbart sich in Form der
abstrakten Darstellung auch der Nachteil der Modelle in Bezug auf die Vermessungsmöglichkeiten. In Anbetracht der Tatsache, dass selbst in Bezug auf die vorhandenen Metriken für die
Implementierung noch Uneinigkeit darüber herrscht, inwieweit die ermittelten Messwerte denn
tatsächlich eine gesicherte Aussagekraft über bestimmte Eigenschaften von Software besitzen,
wird schnell klar, dass konkrete Aussagen bei einem erhöhten Grad an Abstraktion weiter erschwert werden. Daher ist es erforderlich, bei der Definition von Metriken und bei den Messungen selbst, auf die speziellen Eigenschaften der UML einzugehen. Entgegen des Messobjekts
der vorhandenen und zum Teil etablierten Metriken im Softwarebereich handelt es sich bei der
UML nicht um Programmcode. Da die Messungen an den UML-Modellen darauf abzielen soll,
den Softwareentwicklungs-Prozess in dieser Phase zu begleiten, sind außerdem die Dokumente
zu berücksichtigen, die den Weg in die Entwurfsphase finden. Bei diesen Dokumenten handelt
es sich grob gesprochen um die Anforderungen, die in der vorangegangen Phase zwischen den
Entwicklern und dem Auftraggeber abgesprochen wurden und die von der Software zu erfüllen
sind. Auch diese Anforderungen sind von entscheidender Bedeutung für die Qualität der Software, denn eine stabile und sichere Software ist nicht von Nutzen, wenn sich mit dieser nicht die
Aufgaben erfüllen lassen, für die sie ursprünglich vorgesehen war.
Diese Betrachtungen bilden den Ausgangspunkt für die Messtätigkeiten, die von dem in diesem Projekt zu entwickelnden Tool zu unterstützen sind. Auf der einen Seite sind Messungen
an den vorliegenden Modellen durchzuführen, wie sie in ähnlicher Art und Weise auch schon
im Bereich der Implementierung angewandt werden. Auf der anderen Seite sind Messungen an
den Entwurfsmodellen notwendig, die nicht vollkommen automatisierbar sind. Diese Messungen
betreffen die angesprochenen Anforderungen, die an die zu entwickelnde Software gestellt werden und deren Funktionalität betreffen. Hierbei ist es das Ziel, den Review-Prozess bezüglich der
funktionalen Anforderungen in der Entwurfsphase durch Software zu unterstützen. Im folgenden
werden Ansätze und Modelle vorgestellt, die dieses Ziel erreichen sollen. Zunächst einmal soll
jedoch auf die zu untersuchenden Modelltypen der UML eingegangen werden. Der Fokus liegt
dabei auf den Elementen, Strukturen und anderen Eigenschaften, die an den Modellen unter dem
Aspekt der Vermessung interessant sind.
3.6.2
101
Messobjekte
Die Modellierung von objektorientierten Programmen findet mit den Modellen des Modellierungsstandards UML statt. Die Diagrammtypen dieses Standards haben die verschiedensten Aufgaben im Entwurfsprozess. Im Bereich dieses Projekts werden exemplarisch drei Diagrammtypen betrachtet und analysiert. Diese werden hier kurz vorgestellt. Dabei ist das Ziel, die Elemente
der Diagramme vorzustellen, die für quantitative Messungen zur Verfügung stehen und Eingang
in die entwickelte Ontologie gefunden haben.
Einer dieser Diagrammtypen, die es zu vermessen gilt, ist das Klassendiagramm. Hierin werden
die identifizierten Objektklassen mitsamt Zustand, Verhalten und ihren Beziehungen dargestellt.
Das Klassendiagramm ist ein zentrales Werkzeug in der UML. Seine Wichtigkeit wird auch an
der relativen Nähe zur Implementierung deutlich. Ein Klassendiagramm beinhaltet in abstrahierter Form alle Elemente eines Softwaresystems. Das Klassendiagramm ist ein statisches Modell.
Es gewährt einen Blick auf die statische Struktur des modellierten Systems. Durch seine Nähe
zur Implementierung bietet sich dieses Modell geradezu für Messungen im Modellbereich an,
lassen sich doch viele Elemente von objektorientierten Programmiersprachen in diesem Modell
wiederfinden und Messansätze auf den Bereich der Modellierung übertragen.
Im Falle des Klassendiagramms sind die folgenden Elemente von Interesse für die Konzeptuierung von Metriken:
Paket: Ein Paket beinhaltet einen Teil des modellierten Systems, also eine bestimmte Zahl
an Klassen und Interfaces.
Klasse, Interface: Dies sind die zentralen Elemente des objektorientierten Entwurfs.
Methode, Attribut: Modellieren das Verhalten und den Zustand der Klassen.
Assoziation, Abhängigkeit, Implementierung, Generalisierung (Vererbungsbeziehung):
Möglichkeiten, um Relationen zwischen den Systemelementen zu schaffen.
Ein weiterer zu vermessender Diagrammtyp ist das Sequenzdiagramm. Dieser Diagrammtyp
zählt zu den dynamischen Modellen. Das heißt, das dynamische Verhalten des Systems wird
modelliert, also z.B. die Reaktion des Systems auf Einflüsse aus der Systemumwelt. Im Fall der
Sequenzdiagramme wird die Interaktion zwischen den im System agierenden Objekten veranschaulicht. Dabei wird die Interaktion der Objekte durch das Versenden von Nachrichten dargestellt, wobei diese wiederum verschiedenen Typs sein können. Die Elemente dieses Diagrammtyps stellen sich wie folgt dar:
102
Objekt: Bei den Objekten handelt es sich um Instanzen der Klassen aus dem Klassendiagramm.
Nachricht: Man spricht auch von einem Call“. Es gibt verschiedene Typen von Nach”
richten. Dazu zählt die Instanziierung eines neuen Objekts, dessen Zerstörung, das Senden
einer Nachricht mit Abgabe des Kontrollflusses, eine Anwort auf solch eine Nachricht
sowie die Erzeugung eines neuen Kontrollflusses ohne Abgabe des eigenen.
Der dritte Diagrammtyp ist das Zustandsdiagramm, auch Statechart genannt. Bei diesem Diagramm handelt es sich wie beim Sequenzdiagramm um ein dynamisches Modell. Durch die
Zustandsdiagramme wird das interne Verhalten, also die Zustände“ in denen sich ein Objekt
”
befinden kann, modelliert. Das Zustandsdiagramm dringt damit noch weiter vor, was die Modellierung des Systemverhaltens anbelangt. Auch dieser Diagrammtyp bedient sich wieder unterschiedlicher Elemente, die im weiteren Verlauf für die Messung interessant sein könnten:
Zustand: Dieses Element beschreibt die Zustände (States) in denen sich das betrachtete
Objekt befinden kann. Es existieren mit dem Start- und dem Endzustand zwei Spezialfälle
eines Zustands. Es ist ebenfalls möglich, dass ein Zustand andere umschließt. Man spricht
dann von einem Oberzustand.
Transition: Der Übergang von einem Zustand in einen anderen erfolgt über Transitionen.
Diese können Trigger und Conditions besitzen, die den Übergang von einem Zustand zu
einem anderen kontrollieren. Weiterhin können Transitionen eine Ausgabe (Output) produzieren.
Die drei vorgestellten Diagrammtypen besitzen eine große Bedeutung bei dem Entwurf von Softwaresystemen und bieten sich daher für Messungen, die die Güte und die Vollständigkeit des Entwurfs betreffen, an. Im folgenden wird zu betrachten sein, in welcher Form bzw. bis zu welchem
Grad Messungen an eben diesen Diagrammtypen möglich sind. Ein weiterer wichtiger Punkt
wird aber auch sein, inwieweit Messungen im Zusammenhang mit dem Entwurf von Software
und der damit verbundenen Modellierungstätigkeit überhaupt sinnvoll sind. Es sollen sowohl automatisch ermittelbare Metriken entworfen werden, als auch Möglichkeiten untersucht werden,
den Abgleich von Anforderungen und vorliegenden UML Diagrammen zu ermöglichen. Im Zusammenhang mit dem klassischen“ Ansatz von Metriken soll zunächst ein Blick auf etablierte
”
Metriken aus dem Bereich der objektorientierten Programmierung geworfen werden.
3.6.3
103
Objektorientierung und Metriken
Mit dem Ursprung der Softwarevermessung in den 70er Jahren sind die bisher in dieser Arbeit vorgestellten Modelle noch unter den Paradigmen funktionsorientierter Programmierung
mit Programmiersprachen wie Fortran, Ada oder C entstanden. Die objektorientierten Konzepte
und Programmiersprachen stellen jedoch andere Anforderungen an Softwaremetriken. Ein gutes Beispiel für die Differenz der beiden Konzepte in Bezug auf die Vermessung ist McCabe´s
Metrik der zyklomatischen Komplexität. Durch das Klassenkonzept ist der Kontrollfluß an vielen Stellen objektorientierter Programme sehr einfach, obwohl die tatsächliche Komplexität des
Programms hoch ist. Die Metrik der zykomatischen Komplexität verliert dadurch in Bezug auf
objektorientierte Programme ihre Aussagekraft. Damit ist zu erkennen, dass für eine aussagekräftige Vermessung dieser Softwareprodukte neue Konzepte vonnöten sind. Dabei können zwar
auch vorhandene Konzepte weiterverwendet bzw. übertragen werden, jedoch sind viele speziell
auf objektorientierte Systeme ausgerichtet (vgl. [FP97, S. 317]). Als Beispiele für objektorientierte Metriken sollen an dieser Stelle zwei Suiten angeführt werden:
Die Metrik Suite nach Chidamber und Kemerer
Die MOOD-Suite nach Abreu
Bevor diese Sammlungen von Metiken vorgestellt werden, ist jedoch zu bemerken, dass gerade der Bereich der Metriken für objektorientierte Softwareprodukte sehr unübersichtlich ist. Die
vorhandenen Konzepte gehen meist in verschiedene Richtungen und es ist kein Konzept erkennbar, welches man als Standard oder allgemeiner als Orientierungshilfe in diesem Bereich betrachten könnte. In vielen Fällen fehlen sogar komplexere Modelle und man beschränkt sich auf
das Auszählen von Elementen wie Klassen oder Methoden. Die oben genannten Ansätze umfassen jeweils einige abgeleitete Metriken, die Aussagen über die Struktur und Komplexität solcher
Software durch die Beurteilung der ihr zugeordneten speziellen Eigenschaften ermöglichen.
Metriksuite nach Chidamber und Kemerer
Diese Sammlung von objektorientierten Metriken besteht aus 6 Maßzahlen. Der Fokus dieser
Metriken liegt auf der Implementierung einzelner Klassen. Beurteilt werden Aspekte objektorientierter Systeme wie der Grad der Kopplung von Klassen oder die Kohäsion (Zusammenhalt).
Diese Aspekte gehen auf die Ontologie von Bunge aus dem Jahr 1979 zurück [FP97, S. 317]).
Die Metriken lassen sich im einzelnen folgendermaßen beschreiben:
1. Weighted methods per class (WMC): Es wird davon ausgegangen, dass eine Klasse C
Methoden M1 ; M2 ; :::; Mn besitzt die jeweils eine Komplexität von c1 ; c2 ; :::; cn besitzen.
104
Summiert man diese Komplexitäten auf, erhält man eine Aussage über die Komplexität der
Klasse. Je höher die Komplexität, desto höher ist der Aufwand bei der Arbeit mit dieser
Klasse. Eine Klasse mit hohem WMC-Wert besitzt einen großen Einfluss auf die von ihr
erbenden Klassen und auch die Wahrscheinlichkeit von Fehlern nimmt mit erhöhter Zahl
komplexer Methoden und damit einem hohen Wert für WMC zu.
2. Depth of inheritance tree (DIT): Diese Metrik gibt die Anzahl der Oberklassen der betrachteten Klasse an, also den Weg von der betrachteten Klasse bis zur Wurzelklasse“.
”
Während ein hoher Wert die Nutzung des Vererbungskonzepts anzeigt, und damit eine
gute Strukturierung des Programms, steigt aber auch die Wahrscheinlichkeit von Fehlern.
Dies liegt darin begründet, dass eine tiefe Vererbungshierarchie zu erhöhter Komplexität
führt. Es werden Werte zwischen 5 und 8 als Obergrenze vorgeschlagen.
3. Number of children (NOC): Gibt die Anzahl der Klassen an, die direkt von der betrachteten Klasse erben. Je höher der Wert desto wichtiger ist die betrachtete Klasse und sollte
daher besondere Aufmerksamkeit genießen. NOC wird als Indikator für Wiederverwendung und geringere Fehlerwahrscheinlichkeit gesehen. Jedoch kann eine breite Vererbung
(im Gegensatz zur Tiefe bei DIT) auch ein Indikator für eine falsche Nutzung des Vererbungskonzepts sein.
4. Coupling between Object Classes (CBO): Misst den Grad der Kopplung der betrachteten
Klasse. Der Wert errechnet sich aus der Anzahl von Klassen, die von der betrachteten Klasse referenziert werden oder die diese referenzieren. Die Kopplung entsteht dabei durch den
Aufruf von Methoden anderer Klassen oder Nutzung derer Instanzvariablen. Jede Klasse
mit der die betrachtete gekoppelt ist wird einmal gezählt. Eine hohe Kopplung ist im objektorientierten Bereich nicht erwünscht. Außerdem erhöht diese wiederum die Komplexität
und damit die Wahrscheinlichkeit von Fehlern.
5. Response for a class (RFC): Dieser Wert ergibt sich aus der Summe aller aufgerufenen
Methoden einer Klasse, sowie der Zahl der klasseneigenen lokalen Methoden. Jede Methode wird einmalig gezählt. Auch hier zeigen hohe Werte zu eine hohe Komplexität an,
was wiederum die Wahrscheinlichkeit von Fehlern erhöht.
6. Lack of cohesion on methods (LCOM): Dieser Wert bezeichnet den Mangel an Zusammenhalt (Kohäsion) einer Klasse. Dieser wird bestimmt durch die Nutzung von Variablen
durch die Methoden der betrachteten Klasse. Um den Wert für LCOM zu ermitteln betrachtet man alle möglichen Methodenpaare der Klasse. Zur Berechnung wird die Zahl an Methodenpaaren, die mindestens eine Variable gemeinsam nutzen (diese Zahl soll an dieser
105
Stelle mit Q bezeichnet werden), von der Zahl der Paare die auf disjunkten Variablensätzen
arbeiten (als Bezeichnung wird P gewählt), subtrahiert. Ist Q > P , so ergibt sich 0 als Wert
für LCOM. Ansonsten berechnet sich LCOM als LCOM = P Q. Wünschenswert ist
der Wert 0 für diese Metrik. Nach Chidamber und Kemerer ist ein erhöhter LCOM Wert
Indikator dafür, dass die betrachtete Klasse mehr als eine Aufgabe erfüllt und daher die
Aufteilung dieser Klasse in mehrere Teile sinnvoll ist.
MOOD-Suite
Während die im vorangegangen Abschnitt betrachtete Metrik-Sammlung jeweils einzelne Klassen betrachtet und aus diesem Blickwinkel heraus die Merkmale einer Implementierung beurteilt, so werden die Metriken der MOOD-Suite über das gesamte betrachtete System berechnet.
MOOD steht für Metrics for Object Oriented Design“ und betrachtet die Konzepte der Objek”
torientierten Programmierung. Dazu zählen unter anderem Kapselung, Vererbung und Polymorphie. Alle Maße sind hierbei relativ, wobei niedrige Werte eine geringe Nutzung der objektorientierten Konzepte anzeigen und hohe Werte eine dementsprechend hohe Nutzung. Die Metriken
der MOOD-Suite stellen sich folgendermaßen dar 6 :
1. Method Hiding Factor (MHF): Diese Metrik trifft eine Aussage über die Verwendung
des Kapselungskonzepts im betrachteten System. Der Messwert ergibt sich als Quotient
der Anzahl der privaten Methoden und der Gesamtzahl der Methoden. Angestrebt werden
sollten Werte im mittleren Bereich. Eine zu hohe Kapselung schränkt die Funktionalität
des Systems zu stark ein.
2. Attribute Hiding Factor (AHF): Auch diese Metrik befasst sich wie MHF mit dem Konzept Information Hiding, in diesem Fall jedoch mit Bezug auf Attribute. Der Messwert
ergibt sich als Quotient der privaten Attribute und der Gesamtzahl aller Attribute. In Bezug auf Attribute sind hohe Meßwerte erwünscht. Idealerweise liegt der Wert bei 1, so dass
alle Attribute gekapselt und nur über entsprechende Methoden zugreifbar sind.
3. Method Inheritance Factor (MIF): Diese Metrik gibt Aufschluss über die Nutzung des
Vererbungskonzepts im betrachteten System. Dazu werden die ererbten Methoden im Verhältnis zur Gesamtzahl von Methoden betrachtet. Die Werte sollen sich wiederum im mittleren
Bereich bewegen.
4. Attribute Inheritance Factor (AIF): Diese Metrik berechnet sich wie die vorangegangene, wobei der Fokus nun auf den Attributen liegt. Auch hier sind mittlere Werte ein
6
siehe z.B. http://www.software-kompetenz.de/servlet/is/16211
106
Indikator für gutes Design.
5. Polymorphism Factor (PF): Der Grad des Einsatzes von Polymorphie wird durch das
Verhältnis überschriebener Methoden zur Gesamtzahl an Methoden gemessen. Der Wert
für diese Metrik sollte einmal mehr im mittleren Bereich liegen, da Polymorphie die
Software zwar dynamischer und leichter erweiterbar macht, jedoch auch die Komplexität
steigt, was zu Verständnisproblemen führen kann.
6. Coupling Factor (CF): Diese Metrik setzt die vorhandenen Kopplungen von Klassen (betrachtet werden alle Abhängigkeiten außer der Vererbung) mit der Zahl aller möglichen
Kopplungen ins Verhältnis. Eine geringe Kopplung ist wünschenswert, jedoch ist ein Wert
von 0 nicht sinnvoll, da nicht jeglicher Datenaustausch unterbunden werden kann und sollte. Ein gutes Beispiel für die Notwendigkeit von Datenaustausch sind GUI-Klassen.
3.6.4
Entwicklung von Metriken für UML-Modelle
Bewertung der OO-Metriken
Wenn man die Metrik-Suiten nach Chidamber/Kemerer und Abreu betrachtet, stellt man fest,
dass es durchaus möglich wäre, einige der Metriken nahezu unverändert auf das Modell der UML
zu übertragen. Der Diagrammtyp, der sich dafür anbietet, ist das Klassendiagramm. Dieses bietet
viele Elemente, die sich später im Programm-Quellcode der Implementierung wiederfinden: Pakete, Klassen, Methoden, Attribute und Relationen zwischen den Klassen. Die Metrik Weighted
methods per class aus der CK-Suite ist ein gutes Beispiel für die Möglichkeit, Metriken aus der
Implementierungsphase einzusetzen, zeigt aber gleichwohl auch Probleme bei dieser Vorgehensweise auf. So ist es in einem UML Klassendiagramm durchaus möglich, das zahlenmäßige Vorkommen von Methoden festzustellen. Das Problem dabei ist jedoch die Abstraktion des Modells.
Im Modell an sich werden ja schließlich nur die Methoden mitsamt ihrer Sichtbarkeit aufgeführt,
nicht aber ihre Implementierung. Um also WMC wirklich genau zu berechnen und die Komplexität der Methoden abzuschätzen wäre zumindest Pseudocode für die Methoden der betrachteten
Klasse erforderlich. Hier offenbart sich das erste Problem bei der Übertragung von Vermessungskonzepten aus der Implementierung in die Entwurfsphase. Diese Beobachtungen setzen sich bei
der weiteren Betrachtung der CK-Suite fort. So lassen sich die Metriken CBO, RFC und LCOM
ebenfalls erst korrekt errechnen, wenn zusätzlich zum eigentlichen Modell Pseudocode existiert.
Die Metriken DIT und NOC lassen sich jedoch ohne weitere Probleme auch aus dem Klassendiagramm heraus berechnen, da das Vorhandensein der Vererbungsbeziehung im Klassendiagramm
für diese Berechnungen bereits ausreicht. Auch die Metriken der MOOD-Suite sind zum größten
107
Teil auf UML Klassendiagramme anwendbar, lediglich die CF-Metrik benötigt mehr Information als das UML-Klassendiagramm im allgemeinen liefern kann.
Man kann also nach den bisherigen Beobachtung zu dem Schluss kommen, dass es prinzipiell durchaus möglich ist, die für Quellcode designten Metriken auf die UML zu übertragen. Was
jedoch im Kapitel über die Grundlagen des Messens von Software deutlich werden sollte, ist,
dass es von entscheidender Bedeutung ist, zu wissen, was man überhaupt misst und welches Ziel
man damit verfolgt. Die objektorientierten Metriken, die bisher beleuchtet wurden, versuchen
eine Aussage über die Qualität des Messobjekts, also der Software zu treffen. Die Beurteilung
der Qualität hängt dabei in beiden Fällen davon ab, inwieweit die Konzepte der Objektorientierung sinnvoll eingesetzt wurden. Das Problem, dem man sich gerade in der Phase des Entwurfs
stellen muss, ist verbunden mit dem hohen Maß an Kreativität. Es kommt oft zu Änderungen
und der Weg bis zum Endergebnis ist relativ lang und ungewiss (vgl. [vES03]). Messungen, die
auf der korrekten Nutzung der objektorientierten Konzepte basieren, ergeben jedoch nur einen
Sinn, wenn die Entwicklung relativ weit fortgeschritten ist man die Messung an Systemteilen
durchführt, die als vorerst vollständig angesehen werden. Gerade bei den Metriken, die über
das gesamte System erhoben werden, ist es wenig sinnvoll sie auszuwerten, bevor der Entwurf
abgeschlossen ist. Dies betrifft also im Besonderen Maße die Metriken der MOOD-Suite. Ein
unvollständiger Entwurf könnte also zu wenig aussagekräftigen und dadurch eventuell sogar irreführenden Ergebnissen führen. Somit ist festzustellen, dass Aussagen über die Güte des Entwurfs in Bezug auf das objektorientierte Konzept zwar durchaus zu einem frühen Zeitpunkt der
Entwicklung wünschenswert sind, sich jedoch in dieser Form nur schwer zum Monitoring des
Entwurfs während der kreativen Entwicklungsphase heranziehen lassen. Ein weiteres Problem
mit dieser Gattung von Metriken ist, dass sie sich direkt nur sinnvoll auf Klassendiagramme anwenden lassen, da nur dieses die Informationen liefern kann, die als Eingabe benötigt werden.
Allgemein gesprochen ist es jedoch durchaus sinnvoll, UML-Klassendiagramme bzw. einzelne
Klassen mit Hilfe dieser Methoden zu vermessen, da auf diese Weise Defizite bezüglich der OOKonzepte bereits sichtbar gemacht werden können, bevor es zur Implementierung des Modells
kommt. Eine Berücksichtigung dieser Faktoren im Zusammenhang mit der UML ist wünschenswert.
Darstellung der Vorgehensweise
Wie sich herausgestellt hat, sind die vorhandenen OO-Metriken zwar zum Teil auf die UML
übertragbar, lassen sich in der vorliegenden Form jedoch nur sinnvoll auf Klassendiagramme anwenden und entwickeln erst spät eine gesicherte Aussagekraft, da sie die OO-Eigenschaften des
108
Abbildung 3.13: Darstellung des Goal Question Metric Verfahrens [Tha00, S.156]
Messobjekts beurteilen. Der Entwurf mit Hilfe der UML erfordert eine andere Form der Beurteilung, wenn sich diese während der gesamten Entwurfstätigkeit anwenden lassen soll. Daher
sollen im folgenden Metriken entwickelt werden, die auf den Elementen der zu bewertenden Diagramme basieren. Es existieren bereits Ansätze in dieser Richtung, die in [vES03] beschrieben
werden. Diese werden im folgenden in den zu betrachtenden Kontext eingeordnet und angepasst. Dazu gehört auch, dass die Entwicklung mit Hilfe des Goal-Question-Metric Ansatzes
(GQM) durchgeführt wird, der bereits im Kapitel über die Grundlagen des Messens kurz angesprochen wurde. Der große Vorteil des GQM-Ansatzes ist, dass die gesammelten Daten mit den
Zielen des Messvorganges direkt in Verbindung stehen, da die Messmethoden (die Metrik) von
eben diesen Zielen ausgehend entwickelt wurden. Damit wird verhindert, dass für ein Projekt
unzählige Maßzahlen vorliegen, jedoch niemand die Eigenschaften des Systems oder die Ziele
innerhalb des Prozesses kennt, mit denen sie zusammenhängen. Es ist leicht einzusehen, dass im
Bereich Software, welche eine hohe Komplexität sowohl im Produkt als auch im Erstellungsprozess aufweist, die Zahl der messbaren Elemente sehr umfangreich ist. Aus diesem Grund sollte
die Aussage einer Maßzahl unbedingt bekannt sein. Einen Überblick über das GQM Verfahren
gibt Abbildung 3.13. Dabei ist gut zu erkennen wie der Weg von einem formulierten Ziel über
Fragen zu Metriken führt. Dadurch wird im Umkehrschluss der Weg von den Messungen, zu
entsprechenden Antworten und damit der Erreichung des Messziels geebnet.
109
Definition von Messzielen
Dem GQM Ansatz folgend ist es nun zunächst erforderlich, die Ziele festzulegen, die mit den
Messungen verfolgt werden sollen. Die daraus hervorgehenden Metriken sollen nicht die gleiche
Schwachstelle haben, wie die OO-Metriken. Während die zuvor betrachteten Metriken recht speziell auf die objektorientierten Konzepte ausgerichtet waren, ist nun der Abstraktion durch die
UML-Modelle Rechnung zu tragen und eine allgemeinere Ausgangsposition zu wählen. Daher
sollen die generischen Merkmale bei der Definition der Messziele im Vordergrund stehen.
Zunächst ist also die Frage, was die UML Diagramme auszeichnet bzw. was ihre Aufgabe ist.
Die Vielzahl an unterschiedlichen Diagrammtypen macht sie zu einem mächtigen Werkzeug mit
einer hohen Komplexität. Jedoch ist die Hauptaufgabe von Modellen immer noch die Visualisierung von komplexen Zusammenhängen. Aus diesem Grund macht es Sinn, die visuellen Aspekte
der UML-Diagramme zu betrachten. Fenton [FP97] nimmt bei seiner Betrachtung von Metriktypen unter anderem die Unterscheidung zwischen Umfang (Size) und Struktur (structure) vor.
Diese beiden Merkmale erscheinen mir im Zusammenhang mit Diagrammen als besonders wichtig, da sowohl der Umfang als auch die Struktur eines Diagramms einen großen Einfluss darauf
haben, ob eine grafische Darstellung wie ein UML-Diagramm verständlich ist oder nicht. Und in
Anbetracht der Tatsache, dass es sich in diesem Fall um ein Modell handelt, werden die in diesem
Zusammenhang beobachteten Eigenschaften des Modells sich mit Sicherheit auch im Resultat,
der Software niederschlagen. Zum einen finden die Strukturen des Modells Einzug in die Software und es erfolgt damit eine Abbildung dieser Eigenschaften, zum anderen ist anzunehmen, dass
im vermehrten Maße Fehler entstehen, wenn das Modell in seinem Umfang und seiner Struktur gewisse Grenzen überschreitet. Daher soll es in diesem Zusammenhang das Ziel sein, die
Ausprägung dieser Faktoren erfassen zu können. Daraus ergeben sich folgende Zielvorgaben:
Ziel 1: Es soll möglich sein den Umfang eines UML-Diagramms zu bestimmen.
Ziel 2: Es soll die Möglichkeit geben, Aussagen über die Struktur eines UML-Diagramms
zu treffen.
Da diese beiden Zielsetzungen sich auf die Modellierung mit UML im Allgemeinen beziehen,
gelten diese Zielsetzungen für die Vermessung aller Diagrammtypen (Klassendiagramm, Sequenzdiagramm, Zustandsdiagramm). Der nächste Schritt besteht nun darin, Fragen zu formulieren, deren Beantwortung zur Zielereichung beiträgt.
110
Ableitung von Fragestellungen
Da die Zielsetzung für alle drei Diagrammformen gilt, soll auch die Formulierung der Fragestellungen für alle Diagrammformen gültig sein. Zunächst betrachten wir das Ziel, den Umfang
eines Diagramms zu ermitteln. Wenn man sich an die Grundlegenden Metriken der Implementierung zurückerinnert, stößt man zunächst auf die LOC Metrik. Durch sie wurde ja bekanntlich
versucht, die Grundeinheiten zu ermitteln, aus denen Software besteht. Auch in Bezug auf UML
Modelle kann man die Frage stellen, wie groß die Anzahl bestimmter Elemente ist, um daraus
Rückschlüsse auf den Umfang des Modells zu gewinnen. Wir leiten also folgende Frage ab:
Frage 1: Wie groß ist die Anzahl eines bestimmten Elementtyps X im betrachteten Diagramm Y ?
Diese Fragestellung ist auf alle Diagrammtypen anwendbar wenn man sie auf den jeweiligen
Elementtyp anwendet (z.B. die Anzahl Klassen in einem Klassendiagramm). Sie bezieht sich
allerdings nur auf einzelne Elemente und nicht auf das gesamte Design. Daher sind weitere Fragen bezüglich des Umfangs wünschenswert. In [vES03] wird in Bezug auf den Umfang eines
UML-Diagramms die visuelle Ausdehnung sowie der Informationsgehalt, den ein Diagramm
beinhaltet, unterschieden. Die visuelle Ausdehnung hat einen großen Einfluss darauf, wie gut ein
Diagramm zu überblicken ist. Der Informationsgehalt hat ebenso einen großen Einfluss auf die
Verständlichkeit eines Diagramms. Also ergeben sich die folgenden Fragen aus Ziel 1:
Frage 2: Wie groß ist die visuelle Ausdehnung des UML Diagramms Y?
Frage 3: Wie viel Information beinhaltet das UML Diagramm Y?
Weiter stellt sich die Frage nach der Struktur eines UML-Diagramms. Um hier zu einem Ergebnis
zu kommen, ist es nötig herauszufinden, welche durch die Struktur bestimmte Eigenschaft interessant ist. Auch hier kann man zur Ideenfindung auf die Grundlagen des Software-Measurements
zurückblicken. Unter Struktur versteht man eine Ordnung oder einen Zusammenhang von Elementen. Einblick in die Struktur eines Programmstücks erhält man z.B. wenn der Kontrollfluss
betrachtet wird. Dieser wird oftmals durch einen Flussgraphen dargestellt, ein Graph bestehend
aus Knoten und Kanten. Metriken wie McCabe’s Cyclomatic Complexity versuchen aus dieser
Struktur eine Aussage über die Komplexität abzuleiten. Komplexität ist eine interessante Größe
in der Software-Entwicklung. Eine hohe Komplexität macht es zum Beispiel wahrscheinlicher,
dass Fehler auftreten oder übersehen werden. Auch in der Phase des Entwurf sollte man darauf
bedacht sein, Fehler zu vermeiden. Daher sollte man ebenso darauf bedacht sein eine unnötig
hohe Komplexität schon möglichst früh zu verhindern. Dazu muss man aber zunächst die Komplexität erfassen können. Daher wird aus Ziel 2 folgende Frage abgeleitet:
111
Frage 4: Wie hoch ist die Komplexität des UML Diagramms Y?
Die Beantwortung dieser Fragen ermöglicht wichtige Erkenntnisse über UML-Diagramme und
trägt nach [vES03] dazu bei, Fehler im Entwurf und damit auch im späteren Verlauf einer
Software-Entwicklung zu vermeiden. Aus diesem Grund sollen im folgenden Metriken aus diesen Fragestellungen abgeleitet werden.
Definition der Metriken
Aus den vier Fragen, die nun vorliegen sind nun Metriken abzuleiten, die eine Antwort dafür
liefern. Da es sich dabei um Fragestellungen handelt, die auf alle Diagrammtypen anwendbar
sind, werden von generischen Ansätzen Metriken entwickelt, die jeweils eine Anpassung an den
jeweils betreffenden Diagrammtyp erfahren.
Metrik zu Frage 1 Die Metriken zu Frage 1 gestalten sich noch recht einfach. Als Eingabe
erhalten sie ein UML-Diagramm und geben als Ergebnis die Anzahl der Elemente (im folgenden
abgekürzt mit Anz(Element)) aus, zu deren Zählung sie bestimmt sind. Beispiele für derartige
Metriken sind:
1. Für Klassendiagramme: Anzahl von Klassen, Interfaces, Methoden, Attributen, ...
2. Für Sequenzdiagramme: Anzahl von Objekten, Nachrichten, ...
3. Für Zustandsdiagramme: Anzahl von Zuständen, Transitionen, ...
Diese Metriken sind zwar sehr einfach, da es sich hierbei um direkte Metriken handelt, jedoch
sind sie durchaus dazu geeignet, ein Projekt zu quantifizieren und damit auch vergleichbar zu machen. Der Nachteil ist jedoch, dass viele Messungen nötig sind, um eine ganzheitliche Aussage
über den Umfang eines Projektes zu erhalten. Daher ist es sinnvoll eine abgeleitete Messgröße zu
nutzen um diese zu bestimmen. Frage 2 bietet den Ausgangspunkt für die Bildung einer solchen
Metrik.
Metrik zu Frage 2 Zur Bestimmung der visuellen Ausdehnung ist eine Festlegung von Konventionen notwendig. Da ein UML Diagramm ein zweidimensionales Gebilde darstellt, läßt sich
die visuelle Ausdehnung eines Diagramms als Produkt Laenge Breite bestimmen. In [vES03]
werden für Klassen- und Sequenzdiagramme weitere Vorschläge gemacht. Demnach wird die
Visuelle Ausdehnung eines Klassendiagramms anhand einer normierten Darstellung ermittelt,
in der alle Klassen und Interfaces vertikal angeordnet sind, so dass sich eine Art Stapel ergibt.
112
Die Relationen zwischen den Elementen werden für die Berechnung nicht berücksichtigt. Den
Elementen Klasse, Interface, Methode und Attribut wird jeweils die Höhe eins zugeordnet. Die
Breite wird mit eins veranschlagt. Zusätzlich sollen jedoch im Zusammenhang mit diesem Projekt auch Pakete berücksichtigt werden. Da Pakete in der visuellen Darstellung andere Elemente
umschließen, beeinflussen sie sowohl die Höhe als auch die Breite des Diagramms. Pro existierendem Pakete wird eine Erhöhung der Diagrammhöhe um 0.25 festgelegt. Die Breite wird
durch die Verschachtelungstiefe der Pakete beeinflusst. Wenn also z.B. in einem Paket ein weiteres befindet, beträgt diese Tiefe 2. Demnach würde sich die standardmäßige Diagrammbreite
durch diese Strukturierung von 1 um 2 0:25 = 0:5 auf 1; 5 erhöhen. Um die Breite des Diagramms zu erhalten muß die maximale Tiefe der Pakethierarchie (bezeichnet mit PackageDepth)
bekannt sein. In einem Diagramm ohne Pakete beträgt der Wert für PackageDepth 0. In der Summe mit der Mindestbreite 1 ergibt sich aus dem Faktor P ackageDepth 0:25 die Breite des
Diagramms an seiner breitesten Stelle. Aus diesen Betrachtungen ergibt sich das folgende Maß
für die visuelle Ausdehnung von Klassendiagrammen (ClassVis):
ClassV is =
(Anz (Klassen) + Anz (Interf aces) + Anz (M ethoden)
+
Anz (Attribute) + (Anz (P akete)
(1 + (P ackageDepth
0:25))
0:25))
Für die Zustandsdiagramme, die sich ähnlich frei anordnen lassen wie die Klassendiagramme,
wird das Maß StateVis in einer ähnlichen Weise berechnet:
StateV is =
((Anz (Zustaende)
(1 + (StateDepth
Anz (Oberzustaende)) + Anz (Oberzustaende)
0:25))
0:25)
Dabei muß für die Zustände, die weitere Zustände beinhalten (Oberzustände), wie bei den Paketen die maximale Tiefe der Hierarchie (StateDepth) für die Breite berücksichtigt werden. Dies
liefert dann in der Summe mit 1 (der Breite eines einfachen Zustands) die Breite des Diagramms.
Die Höhe erhöht sich für jeden Nicht-Oberzustand um 1, mit jedem Oberzustand wiederum um
0:25. Die Transitionen werden wie die verschiedenen Relationstypen des Klassendiagramms für
dieses Maß nicht berücksichtigt.
Die visuelle Ausdehnung eines Sequenzdiagrammes ist hingegen etwas anders zu bewerten.
Die Elemente befinden sich in einer festen Struktur und Anordnung, die nicht verändert werden kann ohne die Aussage des Diagramms zu verändern. Die Breite des Diagramms ergibt sich
113
aus der Anzahl der Objekte, deren Interaktion dargestellt wird, die Höhe wird von der Kopfzeile (bestehend aus den gerade angesprochenen Objekten) und durch die Anzahl der Nachrichten
bestimmt. In [vES03] wird die Veränderung der Diagrammhöhe pro Nachricht unabhängig vom
Typ mit 0; 5 berechnet und die Grundhöhe mit 1. Diesem Vorschlag schließen wir uns an. Damit
ergibt sich folgende Metrik zur Bestimmung der visuellen Ausdehnung von Sequenzdiagrammen
(SequenceVis):
SequenceV is = (1 + (0:5 Anz (N achrichten))) Anz (Objekte)
Metrik zu Frage 3 Die nächste Metrik die für die verschiedenen Diagrammtypen zu spezifizieren ist die Berechnung des Informationsgehalts. Der Grundansatz für diese Metrik besteht
darin, dass jeder Elementtyp eines UML-Diagramms einen Faktor erhält, der den Informationsgehalt dieses Elements bezeichnet. Die Aufgabe besteht also zunächst darin, die Ontologie
eines Diagrammtyps zu betrachten und eine Hierarchie zu definieren, die verschiedene Stufen
des Informationsgehalt beinhaltet. Der Informationsgehalt lässt sich dann durch die Summe aller
Elemente berechnen, die jeweils mit ihrer Gewichtung gemäß ihres Informationsgehaltes multipliziert wurden. Es ergibt sich also folgende Formel (vgl. [vES03]):
X
n
Inf
=
i=1
Elementanzahl(Ei ) Gewichtung (Ei )
Nun muss die Gewichtung für die Elemente der einzelnen Diagramme aufgestellt werden, um
ein spezielles Maß für jeden Diagrammtyp zu erhalten. Dazu wird an dieser Stelle Bezug auf
die Ontologien genommen, die im Verlauf des Projekts erstellt wurden. Die Grundüberlegung
dabei ist, die Gewichtung an der Hierarchie auszurichten, in der die Diagrammelemente sich
befinden. Aus diesem Grund erhalten in dieser Metrik die grundlegenden Strukturelemente eines Diagramms eine höhere Gewichtung, als Elemente, die von diesen abhängig sind und damit
unter anderem auch in größerer Anzahl auftreten. Die Hierarchie für die Elemente eines Klassendiagramms sind in der Abbildung 3.14 zu sehen. Die Pakete, die enthaltenen Entitäten und
die zwischen diesen existierenden Relationen erhalten als strukturverleihende Elemente in diesem Modell den Gewichtungsfaktor 1. Die Methoden und Attribute, die den Entitäten angehören
werden mit einem Wert von 0:25 gewichtet.
Auf ähnliche Weise erfolgt die Gewichtung der Elemente eines Sequenzdiagrammes, zu sehen in
Abbildung 3.15. Da dieser Diagrammtyp grundsätzlich auf strukturelle Aspekte ausgerichtet ist,
fällt die Zahl der Elementtypen hier etwas geringer aus. Im Grunde genommen existieren Objekte
114
Abbildung 3.14: Hierarchie für die Elemente von Klassendiagrammen mit Gewichtungen
bezüglich des durch sie erzielten Informationsgewinns
und Nachrichten. Daher wurden hier fast alle Elemente mit dem Faktor 1 gewichtet. Die Ausnahme wird hier vom ReturnCall gebildet. Dieser Nachrichtentyp dient dazu, den Kontrollfluss
wieder an ein Objekt zurückzugeben und ist damit abhängig von den anderen Nachrichtentypen.
Aus diesem Grund ist der Informationsgewinn durch dieses Element nicht so hoch wie bei den
übrigen und es erhält einen Gewichtungsfaktor von 0:25.
Abschließend bleibt die Betrachtung der Hierarchie von Zustandsdiagrammen, zu sehen in Abbildung 3.16. Auch hier werden die strukturgebenden Elemente mit dem Faktor 1 gewichtet. Dies
betrifft in diesem Fall die Zustände und die Transitionen. Die Elemente Trigger, Condition und
Output ergänzen ähnlich der Methoden und Attribute aus dem Klassendiagramm das Modell und
werden mit dem Faktor 0:25 gewichtet.
Metrik zu Frage 4 Gesucht wird ein Maß zur Bestimmung der Komplexität eines UMLDiagramms. Auf dem Weg zur Bildung eines Maßes muß man sich die Frage stellen, wodurch
die Komplexität eines Diagramms überhaupt bestimmt wird. Reduziert man die drei betrachteten Modelle aufs Einfachste, so bleiben Elemente übrig, die um Verbindungen untereinander
verfügen. Der vereinfachte Betrachtungsgegenstand, dessen Komplexität es zu beurteilen gilt,
ist also ein Graph bestehend aus Knoten und Kanten. Dabei soll die Annahme gelten, dass ein
Graph zunehmend unübersichtlicher wird, je größer die Anzahl an Kanten im Verhältnis zur Anzahl der Knoten wird. Die Vermessung von Software anhand eines Graphen erfolgte bereits früh
115
Abbildung 3.15: Hierarchie für die Elemente von Sequenzdiagrammen mit Gewichtungen
Abbildung 3.16: Hierarchie für die Elemente von Zustandsdiagrammen mit Gewichtungen
116
mit McCabe´s Metrik der zyklomatischen Komplexität, welche bereits im Abschnitt über die
Grundlagen des Software-Measurements beschrieben wurde.
Der hier vorgestellte Ansatz ist allgemein gefasst und lässt sich auf jeden der hier betrachteten
Diagrammtypen übertragen. So stellen in einem Klassendiagramm die Klassen und Interfaces die
Knoten dar, wobei die Kanten durch die Relationen repräsentiert werden können, die sich zwischen diesen Entitäten herstellen lassen, also Assoziationen, Abhängigkeiten, Implementierungsund Vererbungsbeziehungen. Pakete finden indirekt Eingang in die Metrik, da durch ihren Einsatz die Struktur des Modells beeinflusst wird. Für die Sequenzdiagramme lassen sich ähnliche
Muster finden. Hier sind die Objekte des Diagramms und die Nachrichten, die zwischen diesen
versendet werden, im Verhältnis zu betrachten. In einem Zustandsdiagramm werden die Entitäten
durch die Zustände repräsentiert, die Relationen durch die Transitionen zwischen ihnen. Dabei
werden Oberzustände, die weitere Zustände beinhalten, ebenso wie Pakete bei den Klassendiagrammen nicht direkt in die Metrik aufgenommen. Auch sie erfüllen die Funktion das Diagramm
besser zu strukturieren und beeinflussen auf diese Weise den sich ergebenden Wert.
In Bezug auf die Berechnung der Metrik wird die Annahme getroffen, dass eine Entität ohne
Relationen nicht sinnvoll ist, da sie keinen Bezug zum Gesamtsystem aufweist. Daher müssen
mindestens E 1 Relationen in einem Diagramm vorhanden sein, wenn E die Anzahl der Entitäten ist. Um für den Fall der niedrigsten möglichen Komplexität einen gleichen Meßwert unabhängig von der Zahl der Entitäten zu erhalten, wird in jedem Fall die Zahl der Entitäten um den
Wert 1 vermindert. Im Fall, dass nur eine Entität vorhanden ist, soll die Metrik den Standardwert
1 ergeben, der auch den niedrigsten Meßwert darstellt. Ein Wert unter 1 ist ein Anzeichen für
Fehler in der Modellierung. Unter Einbezug dieser Annahmen ergibt sich nach [vES03] folgende Metrik:
8
<1;
Kom =
:
Anzahl(Relationen)
Anzahl(Entitaeten 1) ;
falls Anzahl Entitaeten = 1
sonst
Setzt man nun für jeden Diagrammtyp die Elemente gemäß der oben beschriebenen Klassifikation ein, so erhält man das Diagrammspezifische Maß für die Komplexität des jeweiligen Diagrammtyps. Dieser Ansatz ist gut zur Repräsentation von Komplexität geeignet, denn auf der
einen Seite berücksichtigt er die erhöhten Schwierigkeiten beim Verständnis von Graphen mit
hoher Vernetzung, auf der anderen Seite stellt eine hohe Vernetzung der Entitäten in den betrachteten UML-Diagrammen auch ein hohes Maß an interner (wenn man die Statecharts betrachtet)
und externer (hauptsächlich bei Klassen- und Sequenzdiagrammen) Kommunikation und Inter-
117
aktion da. Es wird also die visuelle Komplexität des Diagramms und die potentielle Komplexität
des zu entwerfenden Systems berücksichtigt.
Beurteilung der Metriken
Die im vorangegangenen Kapitel beschriebenen Metriken sind für die Vermessung von UMLModellen sinnvoll. Sie betrachten die von [FP97] dargestellten Grundmerkmale von Software,
Umfang (size) und Struktur (structure). Diese Merkmale wiederum werden bei den klassischen
Metriken herangezogen, um Aussagen über Software zu treffen. Beispiele sind die klassische
Umfangsmetrik LOC und die Strukturmetrik CC nach McCabe. Diese generischen Merkmale
gewinnen in Bezug auf die Modelle der UML zusätzlich an Bedeutung, da diese Modelle stark
abstrahieren und weniger Informationen liefern als die Implementierung eines solchen Modells.
Die Metriken sind außerdem nicht nur bezogen auf ein einzelnes UML-Diagramm von Bedeutung. Betrachtet man die verschiedenen Messgrößen im Gesamtkontext des Entwurfs, so erhält
man aus den einzelnen Messgrößen heraus ein differenziertes Bild über den vorliegenden Softwareentwurf. Als Beispiel führen die Autoren von [vES03] die Parallelen der Maße zu denen von
Chidamber und Kemerer an. So werde der Aspekt der Kopplung in der Analyse der Sequenzdiagramme berücksichtigt, schrieben sie. Ebenso werde die Vererbung im Klassendiagramm berücksichtigt. Besonders wenn man die verschiedenen Maßzahlen im Zusammenhang betrachtet, ergeben sich Möglichkeiten aus Aussagen über die einzelnen Diagramme weiterführende Aussagen
über das Gesamtsystem treffen. In diesem Zusammenhang ergänzen Sequenz- und Zustandsdiagramme die Klassendiagramme um wertvolle Informationen. Die Autoren von [vES03] betonen,
dass UML-Diagramme nicht isoliert voneinander betrachtet werden sollten. Man kann also sagen, dass es sich bei den vorgestellten Metriken der visuellen Ausdehnung, informativen Größe
und Komplexität von UML-Diagrammen um einen sehr vielseitigen Ansatz handelt, um quantitative Aussagen über den Software-Entwurf zu treffen. Aus Erfahrungen in der Anwendung lassen
sich Grenzwerte ermitteln, in denen sich die Werte bewegen sollten und durch die unterschiedlichen Betrachtungsgegenstände (visuelle Größe, Menge an Information, Komplexität) bilden sie
die Eigenschaften eines Diagramms auf eine differenzierte Weise ab, was auch für die Visualisierung von Veränderungen der Diagramme im Laufe der Zeit von Nutzen ist. Diese Veränderungen
des Entwurfs im Laufe der Zeit abgebildet durch die entwickelten Metriken geben Aufschluss
über die Weiterentwicklung des Entwurfs und die damit verbundenen Fortschritte bzw. Mängel.
Eine Erweiterung der Beobachtungen auf andere Daigrammtypen der UML erscheint sinnvoll.
Betrachtet man jedoch die vorgestellten Ansätze für Softwaremetriken, so wird auch klar, dass
sich diese lediglich auf nichtfunktionale Anforderungen an Software beziehen. Die Qualität
118
und die an Software vorgenommenen Veränderungen werden im Zusammenhang mit SoftwareMetriken an den automatisch messbaren Merkmalen wie size“ oder structure“ festgemacht. Im
”
”
Kontext der Unterstützung der Software-Entwicklung durch Messungen sind jedoch funktionale
Anforderungen an die zu entwickelnde Software nicht zu vernachlässigen. Auf diesen Punkt soll
im folgendem Abschnitt eingangen werden.
3.6.5
Berücksichtigung funktionaler Anforderungen
Wie anhand der Ausführungen zu Softwaremetriken zu sehen ist, berücksichtigen die Maßzahlen des Software-Measurement nur allgemeine, nichtfunktionale Merkmale von Software zur
Beurteilung seiner Qualität. Der Grund hierfür ist das Prinzip der Metrik selbst. Ein Maß sollte objektiv sein, wurde im Abschnitt über die Grundlagen des Messens gefordert. Wenn jedoch
Anforderungen definiert werden, geschieht dies durch den Auftraggeber. Da die Anforderungen
menschlichen Ursprungs sind, ist Subjektivität nicht zu vermeiden, darüber hinaus sogar oftmals ein zentraler Bestandteil dieser. Deutlich wird diese Problematik an der Klassifizierung von
Anforderungen an Software. Diese werden zumeist in nichtfunktionale sowie funktionale Anforderungen unterschieden (siehe z.B. [Som01, S. 100 ff]). Die nichtfunktionalen Anforderungen
betreffen dabei Dinge wie die Zuverlässigkeit oder Stabilität. Solche Eigenschaften sollen mit
Hilfe von Metriken überprüfbar sein, indem diese Merkmale auf interne Merkmale von Software
zurückgeführt werden, wie bereits vorgestellt wurde. Die funktionalen Anforderungen betreffen
im Gegensatz dazu direkt die gewünschten Funktionen der Software. Die Vorstellung von der
Funktionsweise einer Software ist zum überwiegenden Teil subjektiver Natur. Es stellt sich also
die Frage, wie diese Form von Anforderung im Zusammenhang mit Softwareprojekten und der
Beurteilung von Softwarekomponenten und Softwaredokumenten zu behandeln ist.
Die Anforderungen an eine zu entwickelnde Software werden in der Phase der Anforderungsdefinition formuliert, die auch Teil des bereits vorgestellten Wasserfallmodells ist. Dies betrifft beide
Formen der Anforderungen an Software. [Som01] nennt zwei Möglichkeiten, die Anforderungen an Software festzuhalten. Eine dieser Formen ist die Benutzeranforderung. Dies bezeichnet
die Formulierung einer Anforderung in natürlicher Sprache. Hier äußern sich das grundlegende
Problem der Anforderungsdefintion: Mangelnde Genauigkeit bei der Formulierung von Anforderungen. Die Benutzeranforderungen dienen wiederum als Basis für die Systemanforderungen.
Die Systemanforderungen setzen die Benutzeranforderungen in eine formale Darstellung um.
Als Form der Darstellung wäre z.B ein Standardformular denkbar. Bei jeder Transformation einer Anforderung in eine alternative Darstellung ist darauf zu achten, dass keine Information bei
der Formalisierung verloren geht.
119
Im Zusammenhang mit der Aufgabe des Entwurfsmonitoring stellt sich die Frage, was eine Anforderung charakterisiert. Eine wichtige Eigenschaft in diesem Zusammenhang ist die Wichtigkeit dieser Anforderung für das Gesamtsystem. Im Zusammenhang mit der Klärung des Begriffs
der Qualität wurde auf das Eclipse-Projekt eingegangen. Das dort zum Zweck des bugreporting“
”
eingesetzte System7 sieht vor, dass ein gefundener Fehler mit einer Priorität versehen werden
kann. Ein ähnliches Vorgehen für die Gewichtung von Anforderungen erscheint sinnvoll. Auf
diese Weise lassen sich kritische Anforderungen von weniger wichtigen Anforderungen unterscheiden. Die zweite Eigenschaft, die eine Anforderung bezogen auf den Zweck der Beurteilung
eines Entwurf charakterisiert, ist ihr Status. Dabei sollen zunächst zwei Zustände existieren. Entweder ist eine Anforderung in einem Entwurf so berücksichtigt worden , dass sie erfüllt“ wird,
”
oder sie gilt als nicht erfüllt“. Für die zu entwickelnde Metrik, wird nach dem GQM-Prinzip
”
folgendes festgelegt:
Ziel 3: Es soll möglich sein, eine Aussage über Qualität und Vollständigkeit eines Entwurfs
in Bezug auf die funktionalen Anforderungen zu treffen.
Daraus leitet sich ab:
Frage 5: Wieviel Prozent der funktionalen Anforderungen wurden bereits berücksichtigt?
Für diese Frage ist eine Antwort in Form einer Metrik zu finden. Erforderlich sind zunächst
die Informationen über alle an ein Projekt gestellten funktionalen Anforderungen (eine Anforderung wird bezeichnet mit Ri , wobei jede Anforderung einen Index i 2 N besitzt). Darunter fällt ihr Status (bezeichnet mit Status(Ri )) und die Gewichtung der Anforderung (bezeichnet mit Gewichtung (Ri )). Die Summe aller Gewichtungen repräsentiert in diesem Zusammenhang die zu erfüllende Menge der funktionalen Anforderung. Wird nun eine Anforderung als
erfüllt betrachtet, wird ihre Gewichtung in der Summe der erfüllten Anforderungen als Summand berücksichtigt. Wird sie im Entwurf bisher nicht berücksichtigt, geht ihre Gewichtung
dementsprechend nicht in die Summe ein. Diese Unterscheidung soll über den genannten Faktor Status(Ri ) berücksichtigt werden, der entweder den Wert 1 besitzt (Anforderung erfüllt)
oder den Wert 0 (Anforderung nicht erfüllt). Durch Bildung des Quotienten aus der Summe
der Gewichtungen der erfüllten Anforderungen und der Summe aller Gewichtungen erhält man
den Anteil der Anforderungen, die bereits bei der Gestaltung des Entwurfs durch die UMLModelle berücksichtigt wurde. Der Vorteil bei der Verwendung von Gewichtungen ist, dass auf
diese Weise ein differenzierteres Bild vom Status des Gesamtprojekts entsteht. Dabei soll gelten:
Gewichtung (Ri ) 2 [1; 5]. Dieses Intervall möglicher Gewichtungen erscheint ausreichend, um
7
http://www.bugzilla.org/
120
die unterschiedliche Bedeutung verschiedener Anforderungen für das zu entwerfende Softwaresystem abzubilden. Um in Bezug auf die Maßzahl zu einer besser verständlichen Darstellung zu
gelangen wird der resultierende Wert mit dem Faktor 100 multipliziert. Auf diese Weise erhält
man als Ergebnis einen Wert in der Einheit Prozent. Unter Berücksichtigung dieser Eigenschaften ergibt sich also folgendes Maß zur Ermittlung des Entwurfsstatus bezüglich der funktionalen
Anforderungen (bezeichnet mit Fullfilled Functional Requirements“, kurz FFR):
”
n
Status(Ri ) Gewichtung (Ri )
100
F F R = i=1
n
i=1 Gewichtung (Ri )
P
P
Die Besonderheit an diesem Maß ist, dass es nicht den zur Verfügung stehenden Daten (also
den UML-Diagrammen repräsentiert in der verwendeten Ontologie) entspringt, sondern auf der
Basis von zusätzlichen Informationen, nämlich den definierten Anforderungen Ri und den vom
Reviewer gesetzten Werten Status(Ri ) und Gewichtung (Ri ), errechnet wird. Es handelt sich
um ein Maß welches auf das gesamte Projekt Bezug nimmt. Damit erfüllt es eine Aufgabe, die
von den zuvor entwickelten Metriken nicht erfüllt werden kann.
3.6.6
Praktische Umsetzung der Metriken
Die Metriken visuelle Ausdehnung, informative Größe, Komplexität und Fullfilled Functional
Requirements werden in der in diesem Projekt entwickelten Software benutzt, um den Entwurf
eines Softwareprojekts zu beurteilen. Das Projekt besteht dabei wie im Abschnitt Software beschrieben aus mehreren Diagrammen, die wiederum in mehreren Versionen vorliegen. Die Ontologie, die den Ausgangspunkt für die Vermessung dieser Diagramme darstellt, ist dabei so konzipiert, dass für jede Diagrammversion eine OWL-Datei erzeugt wird. Auf diesen OWL-Dateien
werden in der Software die Analysen für die Metriken durchgeführt. Für jedes Diagramm lässt
sich das zahlenmäßige Vorkommen eines jeden Elements der Ontologie ermitteln. Das erlaubt,
für jede Diagrammversion die genannten Metriken zu berechnen. Zusätzlich dazu wird die Zahl
der enthaltenen Ontologie-Elemente angegeben. Dies ermöglicht es, im Detail Informationen
darüber zu erhalten, aus welchen Elementen das momentan betrachtete Diagramm besteht. Gemeinsam mit den Metriken Vis, Inf und Kom (die jeweils wie dargestellt auf den vorhandenen
Diagrammtyp angepasst sind) bilden diese Zahlen das betrachtete Diagramm ab. Die Werte geben wie bereits angesprochen Auskunft über die Eigenschaften der Diagramme als Modell, lassen aber auch Rückschlüsse auf die Eigenschaften des modellierten Systems zu. Abhängig von
den Vorgaben, die an diesen Teil des Entwurfs gestellt wurden, erlauben sie ein Urteil über eine Verbesserung oder die Erreichung eines gesetzten Zieles für das Modell in der betrachteten
Version. Wenn Vorgaben an die Eigenschaften von Modellen existieren, entspringen diese Erfahrungswerten. So ist zum Beispiel die Erfahrung, ab wann ein UML-Diagramm zu groß ist, um
121
Abbildung 3.17: Ausgabe der Analysewerte für eine Diagrammversion
seine Funktion als übersichtliche Darstellung einer Systemkomponente zu erfüllen, nicht von
vornherein vorhanden. Durch die Anwendung der Metriken auf die Modelle gewinnt der Nutzer
immer genauere Vorstellungen davon, in welchem Bereich sich bestimmte Werte bewegen sollten. Die Darstellung der Werte in der Software ist in Abbildung 3.17 zu sehen.
Die Darstellung der Metriken beschränkt sich jedoch nicht nur auf deren textuelle Ausgabe. Um
die Messwerte übersichtlicher darzustellen, können sie für jedes Diagramm im zeitlichen Verlauf
betrachtet werden. Dabei werden auf der x-Achse die Timestamps der vorhandenen Diagrammversionen verzeichnet und auf die y-Achse die ausgewählten Messwerte zu den jeweiligen Zeitpunkten abgebildet. Auf diese Weise lässt sich sowohl das für die Beurteilung einer Diagrammversion interessante Datenmaterial darstellen, als auch zur Visualisierung der Entwurfstätigkeit
die Entwicklung der verschiedenen Werte für ein Diagramm im zeitlichen Verlauf betrachten.
Das bietet für die Durchführung eines Software-Entwurfs den Vorteil, zu jedem Zeitpunkt die
entwickelten Diagramme in einer kompakten Form vorliegen zu haben und auch historische Daten jederzeit zugreifen zu können. Über den Verlauf der Werte wird die Entwicklung der Modelle
ersichtlich und es wird ein Überblick über die im laufenden Prozess geleistete Arbeit erlaubt. Die
Daten der Grafik resultieren grundsätzlich aus allen Versionen des ausgewählten Diagramms. Be-
122
Abbildung 3.18: Visualisierung der Analysewerte für alle Versionen eines Diagramms
sonders interessante Abschnitte können aber frei ausgewählt werden, indem ein entsprechender
Rahmen um die betreffenden Daten gebildet wird. Weiterhin ist die Auswahl der zu visualisierenden Daten möglich. Ein Beispiel für die Ausgabe der Diagrammstatistik ist in Abbildung 3.18
zu sehen.
Auch die funktionalen Anforderungen an die zu entwickelnde Software können im Programm
definiert werden. Wenn eine Anforderung angelegt wird, so hat sie einen eindeutigen Namen zu
erhalten, eine Beschreibung der Anforderung sowie eine Gewichtung. Die Informationen über
die definierten Anforderungen werden in der Projektdatei im XML-Format abgelegt. Nach der
Definition einer Anforderung ist sie in der Software auswählbar. Dort werden die Informationen
über diese ausgegeben und es ist möglich, weitere Daten hinzuzufügen. So kann eine Anforderung eine Zuordnung zu verschiedenen Diagrammversionen erhalten. Dabei gilt in der jetzigen
Version, dass pro Diagramm eine Version zugeordnet werden kann. Ab dieser Version gilt die
Anforderung für das entsprechende Diagramm als implementiert. Erscheint eine Anforderung
ausreichend in den Entwurf integriert worden zu sein, so kann sie als erfüllt deklariert werden.
Markiert ein Benutzer die Anforderung als erfüllt und bestätigt dies durch Nutzung der Updatefunktion so wird das Datum des aktuellsten zugeordneten Diagramms als Erfüllungsdatum der
123
Abbildung 3.19: Bearbeiten einer funktionalen Anforderung
Anforderung festgelegt. Eine Anforderung kann aktuell nur als erfüllt deklariert werden, wenn
mindestens eine Zuordnung zu einer Diagrammversion vorliegt. Die Informationen über zugeordnete Diagrammversionen, den Status der Anforderung sowie das Erfüllungsdatum werden
ebenfalls in der XML-Projektdatei abgelegt. Die Zuordnungen von Diagrammversionen und der
Status einer Anforderung sind jederzeit veränderbar. Bereits als erfüllt aufgeführte Anforderungen können auch wieder den Status nicht erfüllt“ erhalten. Auf diese Weise soll ein flexibler und
”
intuitiver Umgang mit diesem Teil des Softwareentwurfs gewährleistet werden. Die Möglichkeit
zur Bearbeitung funktionaler Anforderungen wird in Abbildung 3.19 dargestellt.
Aus den Informationen über die funktionalen Anforderungen in der XML-Projektdatei lässt
sich die Metrik FFR für den aktuellen Zeitpunkt berechnen, so dass der Status des Projekts
bezüglich der funktionalen Anforderungen jederzeit ermittelt werden kann. Diese Metrik bietet
Unterstützung bei der ganzheitlichen Betrachtung des Entwurf. Daher ist auch hier eine Visualisierung der Daten vorhanden. Die Informationen über den Projektstatus sind durch die Auswahl
des Projektknotens in der Baumstruktur zu erreichen. Dort wird der aktuelle prozentuale Anteil
der erfüllten Anforderungen nach der FFR Metrik ausgegeben. In Form einer Verlaufskurve wird
außerdem der Erfüllungsgrad nach FFR über die Zeit dargestellt. Dazu wird pro vorhandenem
124
Abbildung 3.20: Visualisierung des Projektstatus bezüglich der funktionalen Anforderungen
Erfüllungsdatum der Wert für FFR errechnet und in den Graphen eingetragen. Eine derartige
Darstellung gibt Auskunft über den Projektverlauf und die Geschwindigkeit des Fortschritts in
Bezug auf die funktionalen Anforderungen. Ein Beispiel hierfür zeigt Abbildung 3.20.
In der Kombination verhelfen die entwickelten Metriken Projektmanagern dazu, Informationen über Softwareprojekte in einer leicht verständlichen und kompakten Form, basierend auf
den Eigenschaften der UML Diagramme, vorliegen zu haben. Das Zurückgreifen auf Zahlenmaterial gestaltet sich in der Praxis aufgrund des hohen Umfangs von Projekten bei manueller Erhebung oft als schwierig. Die Möglichkeit zur Visualisierung von Daten ist ein wichtiger
Punkt, der zum Verständnis von Zahlenmaterial beiträgt. Durch die Anwendung der Metriken in
Softwareentwürfen erhält man im Laufe der Zeit immer genauere Aussagen darüber, in welchen
Bereichen sich zum Beispiel die Komplexität von bestimmten Diagrammen bewegen sollte. Der
Erfolg bei der Arbeit mit Metriken ist in ihrer Anwendung begründet. Durch den Einsatz von
Metriken in Software wird die Erhebung von Datenmaterial erleichtert, was damit zu einer besseren Möglichkeit zur Anwendung und zum Verständnis der Metriken führt. Daher sollte diese
Entwicklung weiter vorangetrieben werden, da durch die Anwendung von Metriken Erfahrungswerte entstehen, die deren Nützlichkeit durch die Möglichkeit des Vergleichs weiter erhöhen.
Kapitel 4
Ausblick
In diesem Abschnitt erfolgt ein kritischer Rückblick auf die Ergebnisse diese individuellen Projektes. Insbesondere wird auf die Probleme bei den Teilaspekten eingegangen und Lösungsansätze vorgestellt, die auch in Hinblick auf die Projektgruppe “Permeter“ gedacht sind. Außerdem soll ein Ausblick auf mögliche Erweiterungen gegeben werden.
4.1
Ontologien: Stephan große Austing
Die Gestaltung der Ontologien war mit Hilfe des Protege-Werkzeugs sehr gut möglich. Durch
die separate Erstellung der Ontologien blieben diese sehr übersichtlich. Jedoch hat sich der Ansatz der getrennten Ontologien als problematisch erwiesen. So konnten keine Bezüge zu anderen
Diagrammontologien hergestellt werden, ohne eine andere Ontologie zu importieren. Durch das
gegenseitige Importieren wären die Ontologien zu einer Ontologie geworden. Dies stellt den
Sinn der einzelnen Ontologie in Frage, ist aber noch nicht das entscheidende Problem. Durch
die getrennte Verwaltung der Diagramme in dem Programm entstehen getrennte Wissensbasen.
Verweise bzw. Referenzen auf Objekte in anderen Diagrammen müssten mit Informationen zu
der entsprechenden Datei verknüpft werden, damit diese in die referenzierende Wissensbasis integriert werden kann. Diese Verweise müssten jeweils manuell nachträglich definiert werden.
Diese Vermischung zwischen Ontologie und Metadaten scheint fehleranfällig und aufwändig
und wurde deswegen in diesem Projekt nicht implementiert.
Ein Problem für die automatische Erfassung der Verweise ergibt sich durch die Speicherung
der referenzierten Objekte innerhalb der selben XMI-Datei; Die XSLT-Dokumente transformieren nur ein Diagramm aus einer XMI-Datei. Hierbei werden referenzierte Objekte aus anderen
Diagrammen nicht erfasst. Durch die XSLT-Dokumente kann ebenfalls nicht bestimmt werden,
welche Diagramme importiert werden. Um dies zu beheben müsste die Importierung neu kon125
KAPITEL 4. AUSBLICK
126
zipiert werden, was innerhalb dieses Projektes angesichts der verbliebenen Zeit nicht mehr zu
schaffen war.
Die beste Lösung für dieses Problem liegt wohl in der Zusammenführung der Ontologien. Hierbei sollte jedoch auf die Performance des Reasoners geachtet werden. Durch die Bildung einer
einheitlichen Ontologie wird ein UML-Modell, welches aus mehreren Diagrammen besteht, wesentlich besser abbildbar. Um die Größe der Ontologie nicht zu stark anwachsen zu lassen, sollten
keine für die Anforderungsverfolgung oder für die Metriken benötigten Details abgebildet werden.
Die Ontologien beziehen sich in diesem Projekt nur auf das Diagramm und nicht die ableitbare
Semantik für die Implementierung. So ist die Vererbungsbeziehung nicht als transitiv markiert. In
Hinsicht auf die Java-Implementierung ist eine Vererbungsbeziehung transitiv; Wenn eine Klasse C von Klasse B erbt und die Klasse B von A erbt, so erbt die Klasse C ebenfalls von A.
Jedoch gilt dies nicht entsprechend für das Diagramm. In diesem wird eine abgeleitet Vererbung
nicht eingezeichnet. Dies vereinfacht das Diagramm, was ebenfalls ein Qualitätsmerkmal eines
Entwurfs ist. Die in diesem Projekt entwickelten Metriken beziehen sich in erste Linie auf das
Diagramm und nicht die Semantik der Implementierung. Der Zweck der Software besteht in der
Bewertung des UML-Entwurfs. Dadurch geht jedoch auch viel Potential des Reasoners verloren.
Die Anfragen an die Semantik des Entwurfs werden nicht wesentlich vereinfacht. Die Abfrage
über ein Modell ist der Analyse einer XMI-Datei vorzuziehen. Jedoch stellt sich die Frage, ob
hierfür ein semantisches Modell verwendet werden muss. Ein großes Problem ist die Performance der Abfragen. Bereits ein Modell eines kleinen Diagramms benötigt sehr viel Rechenzeit.
Ein entscheidender Zugewinn durch die Ontologie wäre die Verfolgung der Implementierung
Abbildung 4.1: Diagramm und Implementierungssemantik
KAPITEL 4. AUSBLICK
127
von Anforderungen. Dies war zunächst für die Software vorgesehen. Jedoch ergibt sich hierbei
ein Problem durch die verschiedenen Versionen eines Diagramms. Diagrammelemente, die bestimmte Anforderungen an die Software erfüllen, können in einer anderen Version umbenannt
oder verschoben worden sein. Die Bestimmung des neuen Namens oder des neuen Ortes kann
nicht über die Software erfolgen. Diese Veränderung muss durch den Benutzer angegeben werden, was eine Darstellung der Diagrammelemente nötig macht. Die Darstellung muss zwar nicht
grafisch erfolgen, jedoch übertrifft dies die Möglichkeiten der Software. Stattdessen wurde ein
anderes Konzept entwickelt, welches jedoch nicht auf den Ontologien aufsetzt.
Insgesamt gesehen konnte durch die Ontologien ein Modell zur Bewertung eines Entwurfs entwickelt werden. Jedoch wäre das benötigte Modell auch durch reine XML-Strukturen darstellbar
gewesen. Dennoch werden interessante Möglichkeiten zur Bewertung von Diagrammen aufgezeigt. Durch die Einbindung des Domänenwissens konnte die Konstruktion des Modells wesentlich vereinfacht werden. Außerdem konnten durch den Einsatz eines Reasoners die benötigten
Abfragen einfacher gestaltet werden. Das Ontologiemodell bietet für weitere Entwicklungen viel
Potential um den Entwicklungsprozess besser abzubilden. Vor allem die Verbindung zwischen
Diagrammelementen und Anforderungen stellt eine interessante Möglichkeit dar, die weiterverfolgt werden sollte. Der Einsatz der Ontologien muss jedoch wesentlich umfassender gestaltet
werden und die Anforderungen umfassen. Für die Verwaltung von Anforderungen über mehrere
Versionen muss hierbei eine praktikable Lösung gefunden gefunden werden.
4.2
Metriken: Christian Dänekas
In Bezug auf die Aufgabe, Metriken zu entwickeln, die in der Phase des Entwurfs anwendbar
sind, wurden unterschiedliche Ansätze zu ihrer Lösung betrachtet. Der Ausgangspunkt für die
angestellten Überlegungen wurde von den theoretischen Grundlagen gebildet, die seit Beginn
der Siebziger Jahre für die Vermessung von Software geschaffen wurden. Es wurden zur Veranschaulichung Beispiele für klassische Maße der Software-Metrie angeführt. Bei der Recherche
nach Metriken, die in der Praxis bereits auf Softwareprodukte angewandt werden, wurde schnell
klar, das der Fokus dieser anerkannten“ Metriken auf der Implementierung der Software lag.
”
Dies galt bereits für die ersten Metriken wie LOC oder die Halstead-Metriken und setzt sich in
den Metriken für objektorientierte Programme fort. Hier wurde die Suite nach Chidamber und
Kemerer und die MOOD Suite nach Abreu betrachtet, deren Maßzahlen sich auf die Nutzung
objektorientierter Konzepte beziehen und auf diese Weise eine Aussage über die Qualität von
Software treffen.
KAPITEL 4. AUSBLICK
128
Die erarbeiteten Prinzipien der Softwaremetrie wurden im Anschluss einbezogen, um Metriken
für den Software-Entwurf zu entwickeln. Dazu wurden mit Hilfe des GQM-Prinzips zunächst
die Ziele der Messvorgänge definiert. Im Mittelpunkt standen dabei die Modelle der UML. Die
schließlich resultierenden Metriken sind auf Basis der Überlegungen aus [vES03] entstanden
und liefern für die betrachteten Diagrammtypen Aussagen über die Größe und die Struktur der
Diagramme. Diese beiden Aspekte standen bereits bei den klassischen Software-Metriken im
Fokus und auch die Konzepte der Objektorientierung wie die Kopplung von Objekten oder auch
die Vererbung fließen in das Konzept ein. Daher erscheinen sie als sinnvolle Maßnahme, um Informationen über den Umfang und die Komplexität der erstellten Diagramme zu erhalten. Die
Aussagekraft dieser Metriken weitet sich aus, wenn man die erhaltenen Zahlen der verschiedenen Diagrammtypen im Zusammenhang betrachtet. So schildern die Autoren von [vES03] z.B.,
dass die Komplexität eines Programmsystems noch viel detaillierter zu erkennen ist, wenn man
neben der Komplexität des Klassendiagramms die Sequenzdiagramme mit einbezieht. Aufgrund
dieser Eigenschaften der Metriken sind sie zur Vermessung des Software-Entwurfs gut geeignet.
Ein weiterer Aspekt eines Software-Entwurfs wurde ebenfalls berücksichtigt. Neben den nichtfunktionalen Eigenschaften, die den Modellen direkt entspringen, wurden zum Zweck einer
ganzheitlichen Sicht auf den Entwurf auch die funktionalen Anforderungen berücksichtigt. Durch
das dort entwickelte Maß wurde der Status des Entwurfs um die Berücksichtigung dieses Anforderungstyps ergänzt. Das Maß beurteilt den Erfüllungsgrad“ der an das Projekt gestellten
”
funktionalen Anforderungen. Diese gemeinsame Betrachtung von funktionalen und nichtfunktionalen Eigenschaften ist meiner Meinung nach erforderlich, um eine fundierte Beurteilung
bezüglich des Fortschreitens des Entwurfsprozesses zu erhalten. Auf diese Weise können potentielle Versäumnisse und Fehler bereits früh erkannt und damit vermieden werden.
Es hat sich im Laufe der Arbeit gezeigt, dass die Messung des Fortschritts eines Projekts eine
anspruchsvolle Aufgabe darstellt. Das Konzept der Softwarevermessung durch Metriken kommt
der Situation des Entwurfs nicht immer entgegen. Der Ausgangspunkt für die Konzepte zur Vermessung von Software, die in dieser Arbeit dargestellt wurden, wird von den Grundeigenschaften
von Software gebildet. Dies wurde besonders deutlich an den betrachteten Metriken für objektorientierte Programme, wo die Metriken stehts den Einsatz von objektorientierten Konzepten beurteilten. Da der Entwurfsprozess ein kreativer Prozess ist, sind präzise Zielsetzungen bezüglich
des Entwurfs schwer festzulegen. Fortschritt ist in Bezug auf den Entwurf darin zu sehen, dass
die Entwurfsqualität sich verbessert. Um diese Verbesserung feststellen zu können, müssen positive Veränderungen erkannt werden. Die Darstellung des UML-Entwurfs durch seine Visuelle
Ausdehnung, informative Größe und Komplexität versucht eine Beurteilung und Visualisierung
KAPITEL 4. AUSBLICK
129
der Veränderung auf der nichtfunktionalen Seite zu erleichtern, indem durch diese die Eigenschaften von einzelnen Diagrammen kompakt dargestellt werden. Auf diese Weise läßt sich die
Entwicklung der UML-Diagramme gut veranschaulichen.
Die funktionalen Anforderungen an eine Software bieten sich im Vergleich mehr an, um Zielsetzungen zu formulieren und diese im Verlauf des Entwurfsprozesses zu überprüfen. Jedoch
ist dies ohne eine subjektive Beurteilung des Entwurfs nicht zu erreichen, womit die Burteilung
dieser Aspekte nicht durch Metriken im eigentlichen Sinne nicht möglich ist, da diese objektive
und wiederholbare Ergebnisse fordern. Damit ist eine ganzheitliche Beurteilung eines UMLEntwurfs nur durch eine Kombination von Review-Prozess und Metriken möglich. Diese wurde
soweit möglich in das entwickelte Tool eingebracht.
Während der Arbeit an diesem Projekt wurden wie bereits erwähnt auch Verbesserungsmöglichkeiten bezüglich des Ontologiekonzepts deutlich. Mit einem Ansatz, der es erlaubt, Beziehungen zwischen den Elementen verschiedener Diagramme und auch den funktionalen Anforderungen herzustellen, sind weiterführende Beurteilungsmöglichkeiten denkbar, wie zum Beispiel
den Grad der Kopplung einer Klasse durch Beobachtungen am damit verbundenen Sequenzdiagramm festzustellen. Auch Erweiterungen in Bezug auf die funktionalen Anforderungen wären
damit denkbar. Mit Hilfe einer entsprechend detaillierten Abbildung der UML und der funktionalen Anforderungen könnte etwa eine Zuordung einer Anforderung zu einem Anwendungsfall
ausreichen, um über die Verbindungen der UML-Elemente die Berücksichtigung der Anforderung im UML-Entwurf nachzuvollziehen. Der Ansatz der Beurteilung von Softwareentwürfen
durch ein Softwaretool basierend auf den vorgestellten Aspekten ist nach der in diesem Projekt gemachten Erfahrung sinnvoll und birgt durch die eigesetzten Techniken Spielraum für die
individuelle Gestaltung und Erweiterung.
4.3
UML und XMI: Dirk Siemers
Obwohl XSLT Stylesheets eigentlich für die Domäne HTML und XHTML konzipiert wurden um
Inhalte von deren äußeren Darstellung zu kapseln, konnte XSLT und XPATH für die Erstellung
von OWL-Dokumenten relativ gut genutzt werden. Eines der nützlichsten Werkzeuge zur Gestaltung von Stylesheet war das Open-Source-Tool Treebeard. Es nutzt, den auch von uns verwendeten XSLT-Parser, Xalan1 um mit XML-Code und einem XSLT Stylesheet das gewünschtes Ergebnisdokument zu erstellen. Ein weiterer Vorteil des Programms ist die Darstellung von XML1
http://xml.apache.org/xalan-j/
KAPITEL 4. AUSBLICK
130
Code in Baum-Struktur, so konnte ein schneller Überblick über die Struktur und die verschiedenen Elemente eines XMI-Dokuments hergestellt werden. Treebeard produziert auf Knopfdruck
das gewünschte Ergebnisdokument und bietet bei Transformationsfehlern eine Konsole mit den
entsprechenden Fehlercodes. Die Erstellung von Stylesheets war somit eigentlich kein Problem,
jedoch gab es Grenzen durch inhaltliche Defizite des XMI-Dokuments. Beispielsweise konnten
Assoziation von Klassen nur über ein Assoziations-Element im XMI-Baum bestimmt werden.
Klassen selber “wussten“ garnicht, ob, und wenn ja, wen sie als Asssoziationspartner besitzen.
Dieses Defizit wurde jedoch durch die Umwandlung in OWL behoben, denn dort besitzen Assoziationen eine inverse Beziehung. Für die Bestimmung von Assoziationspartnern einer Klasse
xy reicht es die Klasse xy als Assoziationspartner in anderen Klassen zu erwähnen. Die Klasse
xy kann sich druch die inverse Beziehung der Assoziation damit auf die assoziierten Klassen
beziehen. Der damit entstanden Zusatz an Informationen bildet ein Mehrwert für das Projekt.
Die Verwendung von UML 1.4 und damit Poseidon 2.6 als CASE-Tool ist nicht der Stand der
Entwicklung. In Hinsicht auf die Projektgruppe Permeter ist es sinnvoller UML 2.0 und Poseidon
3.2 zu verwenden. Dies würde einen Vorteil bei der XSLT-Umformung bringen, denn Poseidon
exportiert UML-Diagramme ab der Version 3.0 mit korrekten IDs, somit entfallen die umständliche Stringumformungen im XSLT für die IDs. Die von Poseidon 2.6 erstellten IDs ergaben bei
der Verwendung mit XSLT zwar keine Schwierigkeiten, jedoch konnte JENA diese IDs nicht
korrekt verwalten. UML 2 bietet als weiteren Vorteil eine konsistentere Sprachdefinition und eine engere Zusammenarbeit mit der MOF.
Ein weiterer Ausblick ist die Untersuchung von weiteren MOF-konformen Modellen, wie dem
CWM. Dabei müsste jedoch zuerst die Beschaffenheit der XMI-Dokumente geprüft werden, um
klarzustellen ob diese auch für eine sinnvolle Umwandlung genutzt werden können.
Literaturverzeichnis
[AvH04]
Grigoris Antoniou and Frank van Harmelen. A Semantic Web Primer. The MIT
Press, Cambridge, 2004.
[Bal98]
Helmut Balzert. Lehrbuch der Software-Technik. Spektrum Akademischer Verlag,
Heidelberg, 1998.
[Bec02]
Oliver Becker. Xml path language (xpath) version 1.0 - deutsche Übersetzung. W3C
Recommendation, Februar 2002.
[BG00]
D. Brickley and R. V. Guha (Eds).
“resource description framework
(RDF) schema specification 1.0”.
W3C Recommendation, März 2000.
http://www.w3.org/TR/2000/CR-rdf-schema-20000327/.
[BR88]
V. R. Basili and H. D. Rombach. The TAME project: Towards improvement-oriented
software environments. IEEE Transactions on Software Engineering, 14(6):759–
773, June 1988.
[BRJ99]
Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, Reading, Massachusetts, USA, 1 edition, 1999.
[Cro79]
P. Crosby. Quality is free. McGraw-Hill, New York, 1979.
[FP97]
Norman Fenton and Shari Lawrence Pfleeger. Software Metrics: A Rigorous and
Practical Approach. International Thomson Computer Press, London, UK, second
edition, 1997.
[Gru93a]
T. R. Gruber. Toward principles for the design of ontologies used for knowledge
sharing. Technical report, Technical Report KSL-93-04, 1993.
[Gru93b]
T. R. Gruber. A translation approach to portable ontology specifications. Knowledge
Acquisition, 5(2):199–220, 1993.
131
LITERATURVERZEICHNIS
132
[HKR+ 04] Matthew Horridge, Holger Knublauch, Alan Rector, Robert Stevens, and Chris
Wroe. A practical guide to building owl ontologies using the protege-owl plugin
and co-ode tools, August 2004.
[Mar82]
Tom De Marco. Controlling Software Projects. Yourdon Press, 1982.
[MDA]
Omg model driven architecture. Die MDA ist die aktuelleste Strategie der OMG zur
modellgetriebenen und generativen Soft- und Hardwareentwicklung.
[NM01]
Natalya F. Noy and Deborah L. McGuinness. Ontology development 101: A guide to creating your first ontology. Technical report, Stanford Knowledge Systems
Laboratory, Mai 2001.
[Oes05]
Bernd Oestereich. Analyse und Design mit UML 2. Oldenbourg Verlag, 7 edition,
2005.
[Rof04]
Jason T. Roff. UML. mitp-Verlag, 1 edition, 2004.
[Som01]
Ian Sommerville. Software Engineering. Addison-Wesley, sixth edition, 2001.
[SvH04]
H. Stuckenschmidt and F. van Harmelen. Information Sharing on the Semantic Web.
Springer, Berlin, 2004.
[TBLL01] James Hendler Tim Berners-Lee and Ora Lassila. The semantic web. Scientific
American, März 2001.
[Tha00]
Georg Erwin Thaller. Software-Metriken einsetzen, bewerten, messen. Verlag Technik Berlin, second edition, 2000.
[UG96]
Mike Uschold and Michael Grüninger. Ontologies: Principles, methods and applications. Knowledge Engineering Review, 1(2):93–155, Juni 1996.
[uJT02]
Thomas Klute und Jens Thiemann. Xsl transformations (xslt) version 1.0 - deutsche
Übersetzung. W3C Recommendation, März 2002.
[vES03]
Heiko van Elsuwe and Doris Schmedding. Metriken für uml-modelle. Inform.,
Forsch. Entwickl., 18(1):22–31, 2003.
[Zie03]
Cai Ziegler. Web ontology languages (owl): Vokabulare fürs web. ix, Dezember
2003.
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-Schichten Metamodellarchitektur aus Protege . . . . . . . . . . . . . .
Fenster Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggregation und Komposition . . . . . . . . . . . . . . . . . . . . . . .
Mehrfachvererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create und Destroy Beispiel . . . . . . . . . . . . . . . . . . . . . . . .
Eine Klasse, erstellt mit Poseidon 2.6 . . . . . . . . . . . . . . . . . . .
Graphenrepräsentation eines Statements . . . . . . . . . . . . . . . . . .
Verhältnis RDF Schema zu RDF . . . . . . . . . . . . . . . . . . . . . .
owl:inverseOf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
owl:EquivalentProperty . . . . . . . . . . . . . . . . . . . . . . . . . . .
owl:TransitiveProperty . . . . . . . . . . . . . . . . . . . . . . . . . . .
owl:SymmetricProperty . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die Schichten des Semantic Web (Darstellung nach Tim Berners-Lee) . .
Das Wasserfall-Modell der Softwareentwicklung [Som01, S. 45] . . . . .
Abhängigkeit der Produktqualität von der Prozessqualität [Som01, S. 543]
Skalenhierarchie [Bal98, S. 228] . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
9
13
14
14
14
17
23
30
32
34
35
35
36
40
45
48
50
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
Arbeitsprinzip der Software . . . . . . . . . . . . . . . . . .
Datenstruktur in ROSE . . . . . . . . . . . . . . . . . . . .
Dateibasierte Datenhaltung . . . . . . . . . . . . . . . . . .
Programmhauptfenster . . . . . . . . . . . . . . . . . . . .
Dialog zum Hinzufügen eines Diagramms . . . . . . . . . .
Sequenzdiagramm für die Analyse auf Klassendiagrammen .
Sequenzdiagramm für die Erstellung eines neuen Diagramms
Struktur der Klassendiagrammontologie . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
60
61
62
64
65
66
67
81
133
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
134
ABBILDUNGSVERZEICHNIS
3.9
3.10
3.11
3.12
3.13
3.14
3.17
3.18
3.19
3.20
Struktur der Sequenzdiagrammontologie . . . . . . . . . . . . . . . . . . . . . . 83
Beispiel eines Sequenzdiagrammes . . . . . . . . . . . . . . . . . . . . . . . . . 83
Struktur der Zustandsdiagrammontologie . . . . . . . . . . . . . . . . . . . . . 84
Beispiel eines Zustandsdiagrammes . . . . . . . . . . . . . . . . . . . . . . . . 85
Darstellung des Goal Question Metric Verfahrens [Tha00, S.156] . . . . . . . . . 108
Hierarchie für die Elemente von Klassendiagrammen mit Gewichtungen bezüglich
des durch sie erzielten Informationsgewinns . . . . . . . . . . . . . . . . . . . . 114
Hierarchie für die Elemente von Sequenzdiagrammen mit Gewichtungen bezüglich
Hierarchie für die Elemente von Zustandsdiagrammen mit Gewichtungen bezüglich
Ausgabe der Analysewerte für eine Diagrammversion . . . . . . . . . . . . . . . 121
Visualisierung der Analysewerte für alle Versionen eines Diagramms . . . . . . . 122
Bearbeiten einer funktionalen Anforderung . . . . . . . . . . . . . . . . . . . . 123
Visualisierung des Projektstatus bezüglich der funktionalen Anforderungen . . . 124
4.1
Diagramm und Implementierungssemantik . . . . . . . . . . . . . . . . . . . . . 126
3.15
3.16
A.1 Klassendiagramm der Software Rose . . . . . . . . . . . . . . . . . . . . . . . . 136
B.1
B.2
B.3
B.4
Hauptfenster mit Diagrammstatistik . . . . . . . . . . .
Dialog zum Erstellen von neuen Projekten . . . . . . . .
Dialog zum Öffnen von Projekten . . . . . . . . . . . .
Dialog zum Einfügen neuer funktionaler Anforderungen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
138
139
139
140
Anhang A
Diagramme
135
ANHANG A. DIAGRAMME
Abbildung A.1: Klassendiagramm der Software Rose
136
Anhang B
Screenshots
137
Abbildung B.1: Hauptfenster mit Diagrammstatistik
Abbildung B.2: Dialog zum Erstellen von neuen Projekten
Abbildung B.3: Dialog zum Öffnen von Projekten
Abbildung B.4: Dialog zum Einfügen neuer funktionaler Anforderungen

Konzeption und Umsetzung eines Monitoringwerkzeuges f ¨ur UML

Transcription

Similar documents

Romanians and Bulgarians in Male Street Sex

Aufbau und Charakterisierung einer Magnetfalle zur simultanen

Einführung in XML - Lehrstuhl für Betriebliche Informationssysteme

Text, PDF - 4FriendsOnly.com Internet Technologies AG