Analyse, Entwurf und Implementierung zuverlässiger Software

Institut für Informatik
Arbeitsgruppe Softwaretechnik
Warburger Str. 100
33098 Paderborn
Entwurf verlässlicher Echtzeitsysteme mit
Rational Rose RealTime
Ausarbeitung im Rahmen des Seminars
Analyse, Entwurf und Implementierung
zuverlässiger Software
von
Margarete Kudak
Mittelberg 7
33100 Paderborn
betreut durch
Dr. Holger Giese
Paderborn, Januar 2004
Inhaltsverzeichnis
1. Übersicht .................................................................................. - 4 1.1 Hintergrund und Entwicklung ............................................................................ - 4 1.2 Anwendungsbereiche und Ausrichtung.......................................................... - 4 1.3 Allgemeine Angaben............................................................................................. - 4 1.3.1 Systemanforderungen .................................................................................. - 4 1.3.2 Kosten ............................................................................................................... - 5 1.4 Unterstützte Notationen....................................................................................... - 5 1.5 Architektur............................................................................................................... - 5 1.5.1 Unterstützung für Teams.............................................................................. - 6 1.5.2 Entwicklungsprozess .................................................................................... - 6 -
2. Modellierung eines Beispiels.............................................. - 7 2.1 Klassen- und Capsulediagramme ..................................................................... - 7 2.2 Statecharts .............................................................................................................. - 8 2.3 Sequenzdiagramme .............................................................................................. - 9 2.4 Kollaborationsdiagramme................................................................................. - 10 2.5 Komponentendiagramme .................................................................................. - 10 2.6 Deploymentdiagramme ...................................................................................... - 11 -
3. Validierung & Verifikation .................................................. - 13 3.1 Simulation.............................................................................................................. - 13 3.2 Analysen ................................................................................................................ - 13 -
4. Echtzeitmodellierung .......................................................... - 15 4.1 Echtzeitmodell ...................................................................................................... - 15 4.2 Modellierung von Echtzeitverhalten............................................................... - 15 -
Weitere Möglichkeiten zur Modellierung von echtzeitfähiger
Software existieren nicht........................................................ - 15 5. Code Generierung................................................................ - 16 5.1 Umfang ................................................................................................................... - 16 5.2 Zielplattformen ..................................................................................................... - 16 5.3 Konzept .................................................................................................................. - 16 5.4 Qualität ................................................................................................................... - 16 -
6. Qualität.................................................................................... - 18 6.1 Case Tool spezifische Qualitätskriterien ...................................................... - 18 6.1.1 Konsistenzmanagement............................................................................. - 18 6.2 Allgemeine Qualitätskriterien........................................................................... - 18 6.2.1 GUI / Benutzerführung ................................................................................ - 18 6.2.2 Stabilität .......................................................................................................... - 18 6.2.3 Dokumentation.............................................................................................. - 18 6.2.4 Interoperabilität............................................................................................. - 19 -
7. Vergleich................................................................................. - 20 7.1 Übersicht................................................................................................................ - 20 7.1.1 Hintergrund / Entwicklung ......................................................................... - 20 7.1.2 Vergleich der Anwendungsbereiche/Ausrichtung .............................. - 20 7.1.3 Vergleich der Allgemeinen Angaben ...................................................... - 20 7.1.4 Vergleich der Notationen- /Sprachenunterstützung ........................... - 20 7.1.5 Architektur...................................................................................................... - 20 -2-
7.2 Validierung & Verifikation.................................................................................. - 20 7.3 Echtzeitmodellierung.......................................................................................... - 20 7.3.1 Welche Ausdrucksmöglichkeiten für Zeit werden unterstützt? ...... - 20 7.4 Code Generierung ............................................................................................... - 21 7.5 Qualität ................................................................................................................... - 21 7.6 Zusammenfassung.............................................................................................. - 21 -
8. Zusammenfassung .............................................................. - 22 -
-3-
1. Übersicht
Im Folgenden wird das UML Case Tool Rational Rose RealTime vorgestellt. Es
wurde im Rahmen des Seminars Analyse, Entwurf und Implementierung
zuverlässiger Software getestet.
Die hier gemachten Angaben beruhen auf eigener Erfahrung, der Dokumentation des
Case Tools und wissenschaftlichen Arbeiten, die unter Literaturhinweise aufgeführt
sind.
1.1 Hintergrund und Entwicklung
Rational Rose RealTime wurde von der Rational Software Corporation entwickelt, die
mittlerweile zu IBM gehört. Der Hautpsitz der Rational Software Corporation ist in
Cupertino, Kalifornien. Weltweit beschäftigt die Firma ca. 3500 Mitarbeiter.
1.2 Anwendungsbereiche und Ausrichtung
Laut Werbeprospekt ist Rational Rose RealTime eine Entwicklungsumgebung, die für
Real-Time Software maßgeschneidert ist. Entwicklern wird mit Rational Rose
RealTime ermöglicht Modelle eines Softwaresystems auf Basis von UML zu
erstellen.
Rational Rose RealTime beinhaltet folgende Grundfunktionen:
1)
2)
3)
4)
Darstellung von UML- Modellen
Generieren von Code (C, C++ und Java) für diese Modelle
Ausführen, Testen und Debuggen der Modelle
Nutzung von CM (Change Management) Systemen um die Entwicklung im
Team zu unterstützten
1.3 Allgemeine Angaben
1.3.1 Systemanforderungen
Rational Rose RealTime läuft unter Windows NT 4.0 build 1381, Windows 2000
Professional build 2128, Windows XP Professional build 2600, Solaris 2.6, 2.7, 2.8
(Solaris 2.8 empfohlen) und HPUX 10.20.
Für Windows NT, 2000 und XP wird ein Pentium mit 150 MHz (500 MHz empfohlen)
mit 128 MB Speicher (256 MB empfohlen), 552 MB Festplattenplatz für die
Installation und eine Auflösung von 1024x768 (1280x1024 empfohlen) benötigt.
Zusätzlich sollte ein Postscript Drucker vorhanden sein. Des Weiteren wird der
Internet Explorer 5.01 oder 5.5 oder der Netscape Navigator 4.7 oder 6.0 (Internet
Explorer 5.01 oder 5.5 empfohlen) benötigt. Windows NT 4.0 benötigt das Service
Pack 6a, Windows 2000 den Release Candidate 2.
Unter Unix wird für Solaris ein UltraSparc 10 mit 500 MB Speicher (UltraSparc 60 mit
600 MB empfohlen) vorausgesetzt. Für HPUX wird die Installation der HP 700 Serie
empfohlen. Es werden weiterhin 500 MB Speicher (600 MB empfohlen) und 370 MB
Festplattenplatz benötigt.
-4-
Falls mit Rational Rose RealTime C oder C++ Code generiert werden soll, muss ein
C oder ein C++ Compiler installiert sein. Für die Code Generierung für Java muss
das Sun JDK 1.3 vorhanden sein.
1.3.2 Kosten
Der Preis für eine Basisversion liegt laut [7] bei ca. 9045 € pro Arbeitsplatz Lizenz
und für Support pro Jahr bei ca. 1810 €.
1.4 Unterstützte Notationen
Rational Rose RealTime unterstützt Diagramme in der UML Version 1.4. Aktuell liegt
UML in der Version 1.5 vor. Laut Hersteller wird Rational Rose RealTime UML 2.0
unterstützten, kurz nachdem dieser Standard verabschiedet wird.
Die Software unterstützt folgende Struktur- und Verhaltensdiagramme:
• Struktur: Klassen-, Komponenten- und Deploymentdiagramme
• Verhalten: Use Case-, Zustand-, Sequenz- und Kollaborationsdiagramme
Aktivitätendiagramme werden nicht unterstützt. Neben den UML Diagrammen
werden Capsules, Ports, Protokolle und Capsule Strukturdiagramme unterstützt. Mit
diesen soll laut Hersteller eine echtzeitfähige Software modelliert werden können.
Capsules sind erweiterte Klassen. Sie besitzen zusätzlich Ports, die die
Kommunikation zwischen Capsules regeln. Diese Kommunikation wird durch ein
Protokoll definiert. Ein Capsule Strukturdiagramm beschreibt die innere Struktur einer
Capsule.
Für die Entwicklung eines ausführbaren Models müssen Klassendiagramme,
Zustandsdiagramme und Capsule Strukturdiagramme erstellt werden.
1.5 Architektur
Rational Rose RealTime bietet dem Nutzer die Möglichkeit ein komplettes Model zu
erstellen. Dies existiert aus vier verschiedenen Views.
Abbildung 1 zeigt ein Model mit dem Use Case View, dem Logical View, dem
Component View und dem Deployment View.
Im Use Case View können Use Cases, Kollaborations- und Sequenzdiagramme
angelegt werden. Mit Hilfe dieser Diagramme kann der Nutzer die Anforderungen, die
seine Software erfüllen soll, modellieren.
Der Logical View ist zuständig für Analyse, Design und Implementierung des
Systems. Hier wird die komplette Software durch alle Diagramme, bis auf
Komponenten- und Deploymentdiagramme modelliert. In dem Beispiel aus Abbildung
1 befinden sich die Capsules CommunicationCentre, CommunicationChannel
und Shuttle und das Protokoll ConvoyProtocol.
Im Component View kann der Nutzer Komponenten anlegen, die beschreiben,
welche Capsules, Protkolle und Klassen wie kompiliert werden. In Abbildung 1
existiert die Komponente ConvoyCreation.
Im Deployment View wird dann die Ausführung der Komponenten bestimmt. In
Abbildung 1 ist ein Knoten mit dem Namen Localhost definiert, der eine Instanz
der Komponente ConvoyCreation besitzt.
-5-
Abbildung 1 - Model
1.5.1 Unterstützung für Teams
Laut [4] werden die erstellten Models in einem Textformat gespeichert, so dass diese
in ein CM Tool exportiert werden können.
Geeignete CM Tools sind:
• Für Windows NT /2000: Rational ClearCase und Microsoft Visual SourceSafe
• Für UNIX: RCS (Revision ControlSystem) und SCCS (Source Code Control
System)
1.5.2 Entwicklungsprozess
Rational Rose RealTime bietet dem Nutzer an, die einzelnen Views der Reihe nach
abzuarbeiten. Als erstes soll der Benutzer Use Case Diagramme erstellen um sich so
über die Anforderungen seiner Software klar zu werden. Nachdem der Use Case
View bearbeitet wurde, wird der Logical View zur Analyse, Design und
Implementierung des Systems genutzt. Dazu werden alle Diagramme, bis auf
Komponenten- und Deploymentdiagramme erstellt. Sequenzdiagramme, Statecharts
und Capsule Strukturdiagramme können erst erstellt werden, nachdem die jeweiligen
Capsules und Klassen erstellt worden sind.
Danach wird der Component View bearbeitet. Der Nutzer kann mehrere
Komponenten erstellen, die angeben welche Capsules, Klassen und Protokolle wie
kompiliert werden. Im Anschluss daran wird der Deployment View fertig gestellt.
-6-
2. Modellierung eines Beispiels
Im Folgenden wird ein das in dem Seminar „Trends in der Softwaretechnik für
Echtzeitsysteme – Evaluation von Softwarewerkzeugen“ [6] vorgestellte Beispiel mit
Rational Rose RealTime zur Evaluierung der Software modelliert.
2.1 Klassen- und Capsulediagramme
Rational Rose RealTime bietet die Möglichkeit neben Klassendiagrammen auch
Capsules, Ports und Protokolle anzulegen, die aus der Real-Time Object-Oriented
Modelling Language [5] entstanden sind.
Eine Capsule besitzt alle Eigenschaften wie eine Klasse und kann um Ports erweitert
werden. Ein Port ist zuständig für die Kommunikation zwischen Capsules. Rational
Rose Real Time bietet die Möglichkeit neben eigenen Ports auch Timing, Frame und
Protocol Ports anzulegen. Das Case Tool besitzt eine Service Library mit der es
verschiedene Funktionen zur Verfügung stellt, die von den vordefinierten Ports
genutzt werden können. Mittels diesen Funktionen und den Timing Ports kann im
Ansatz echtzeitfähige Software modelliert werden.
Die Signale, die ein Port senden und empfangen kann, sind in einem Protokoll
definiert. Es existieren Ein- und Ausgangssignale.
Abbildung 2 zeigt ein Capsule Diagramm, das aus den Capsules Shuttle,
CommunicationCentre und CommunicationChannel und dem Protokoll
ConcoyProtocol besteht.
Abbildung 2 - Capsule Diagramm
Die Capsule CommunicationCentre besitzt eine Komposition zu den Capsules
Shuttle und CommunicationChannel. Shuttle definiert, wie auch eine Klasse,
Attribute und Methoden. Zusätzlich beinhaltet diese Capsule den Port
-7-
shuttle_comm, der die Signale des Protkolls ConvoyProtocol nutzt. Die Capsule
CommunicationChannel besitzt ebenfalls einen Port: channel_comm, der
ebenfalls das Protokoll ConvoyProtocol nutzt.
Das Protokoll ConvoyProtocol definiert die Signale ConvoyProposal,
ConvoyAccepted, ConvoyRejected und ConvoyEnded, die sowohl Ein- als auch
Ausgangssignale
sind.
Somit
können
die
Capsules
Shuttle
und
CommunicationChannel über diese Signale miteinander kommunizieren.
Zusätzlich bietet Rational Rose Real Time die Möglichkeit Capsule
Strukturdiagramme zu erstellen, die die innere Struktur einer Capsule beschreiben.
Abbildung 3 - Capsule Struktur Diagramm
Abbildung 3 zeigt ein Capsule Strukturdiagramm, das die Struktur der Capsule
CommunicationCentre zeigt, die durch eine Komposition mit den Capsules
CommunicationChannel und Shuttle verbunden ist. Das Diagramm zeigt zwei
Capsule Roles, die je einen Port besitzen und über einen Connector miteinander
verbunden sind.
Capsule Strukturdiagramme bieten keine neuen Informationen. Sie stellen lediglich
einen Teil des Capsule Diagramms anders dar, so dass in komplexeren Diagrammen
die Darstellung übersichtlicher wird.
Neben den Capsule Diagrammen können auch Klassendiagramme erstellt werden.
Die Darstellung der Klassendiagramme ist UML konform.
2.2 Statecharts
Statecharts beschreiben das Verhalten einer Capsule. Die von Rational verwendete
Notation ist nicht UML konform, da das After-Konstrukt nicht unterstützt wird [3].
Zudem können keine parallelen Zustände definiert werden. Diese beiden Umstände
machen die Modellierung von Statecharts in einigen Fällen um einiges schwieriger.
-8-
Abbildung 4 – Statechart
Abbildung 4 zeigt das Statechart, das das Verhalten der Capsule Shuttle
beschreibt. Nach Verlassen des Startzustandes befindet sich das Shuttle in dem
Zustand NotInConvoy. Erhält das Shuttle das Signal Proposal, so wechselt es in
den Zustand ConvoyPossible. Das Shuttle kann nun die Convoyfahrt ablehnen
oder annehmen. Sendet es das Signal Rejected, wird die Convoyfahrt abgelehnt
und der aktuelle Zustand ist NotInConvoy. Bei Senden des Signals Accepted
wechselt das Shuttle in den Zustand InConvoy und fährt nun mit dem anderen
Shuttle in Convoy. Die Convoyfahrt kann beendet werden, indem das Shuttle das
Signal End sendet oder von einem anderen Shuttle dieses empfängt.
Die Signale, die ein Shuttle senden oder empfangen kann, sind die Signale, die im
Protokoll ConvoyProtocol definiert sind.
Des Weiteren hat der Nutzer die Möglichkeit Entry und Exit Actions für Zustände
durch Code zu definieren. An Transitionen kann zusätzlich Code für die Action
Methode und ein Trigger, der aus Signalen und Code für den Guard besteht, definiert
werden.
Der Nutzer hat keine Möglichkeit echtzeitfähige Statecharts zu erstellen. Es kann
weder ein After-Konstrukt angegeben werden, noch ist es möglich zu definieren, wie
lange ein Schaltvorgang dauern muss.
2.3 Sequenzdiagramme
Abbildung 5 zeigt ein mit Rational Rose RealTime erstelltes Sequenzdiagramm. In
diesem Sequenzdiagramm kommunizieren zwei Instanzen, ShuttleOne und
ShuttleTwo, der Capsule Shuttle über eine Instanz der Capsule
CommunicationChannel miteinander. ShuttleOne sendet das Signal
ConvoyProposal an den CommunicationChannel. Dieser leitet das Signal an
ShuttleTwo weiter. ShuttleTwo antwortet dem CommunicationChannel mit
dem Signal ConvoyAccepted, das an ShuttleOne weiter gegeben wird. Nun
fahren beide Shuttle miteinander im Convoy. Die Convoyfahrt kann von beiden
-9-
Shuttles unterbrochen werden, indem sie an den CommunicationChannel das
Signal convoyEnded senden.
Der Nutzer hat die Möglichkeit bei der Definition von Nachrichten anzugeben,
welcher Port das Signal sendet, welcher Port das Signal empfängt und um welches
Signal es sich handelt. Zusätzlich können die Dauer der Nachricht und die Priorität
angegeben werden. Bezogen auf die Modellierung von echtzeitfähiger Software
bedeutet dies, dass der Nutzer zwar die Dauer einer Nachricht spezifizieren kann,
aber es nicht viel nutzt, da kein Code für Sequenzdiagramme generiert werden kann.
Rational Rose RealTime bietet zudem die Möglichkeit Sequenzdiagramme für
Klassen zu erstellen.
Abbildung 5 - Sequenzdiagramm
2.4 Kollaborationsdiagramme
Kollaborationsdiagramme in Rational Rose RealTime entsprechen zum größten Teil
den Capsule Strukturdiagrammen. In einem Kollaborationsdiagramm können
zusätzlich zu den Capsule Roles Classifiert Roles angegeben werden. Allerdings
können keine Ports definiert werden.
2.5 Komponentendiagramme
Rational Rose RealTime bietet die Möglichkeit mittels Komponentendiagrammen
anzugeben, welche Klassen, Capsules und Protokolle wie kompiliert werden. Dazu
werden ein oder mehrere Komponenten angelegt, die Referenzen auf die zu
kompilierenden Klassen, Capsules und Protokolle besitzen.
- 10 -
Abbildung 6 - Komponente
Abbildung 6 zeigt die Komponente ConvoyCreation, deren Referenzen zu einem
RT Java Project gehören. Die referenzierten Klassen, Capsules und Protokolle
werden somit mit einem RT Java Compiler kompiliert, der in dem Spezifikationsdialog
der Komponente näher beschrieben ist.
Abbildung 7 zeigt die Spezifikation der Komponente ConvoyCreation aus Abbildung
6. Die Komponente besitzt Referenzen auf die Capsules CommunicationCentre,
Shuttle, CommunicationChannel und das Protokoll ConvoyProtocol. Somit
wird für jede dieser Referenz eine Java-Klasse generiert und kompiliert.
Abbildung 7- Spezifikation der Komponente
2.6 Deploymentdiagramme
Deploymentdiagramme sind für die Ausführung der einzelnen Komponenten
zuständig. Rational Rose RealTime bietet die Möglichkeit neben Prozessoren, auch
Devices und Packages anzulegen.
- 11 -
Abbildung 8 - Prozessor
Abbildung 8 zeigt den Prozessor mit dem Namen Localhost, der eine Instanz der
Komponente ConvoyCreation besitzt. Er ist somit zuständig für die Ausführung
dieser Komponente. Abbildung 9 zeigt den Spezifikationsdialog von Localhost. Die
Instanz der Komponente ConvoyCreation, ConvoyCreationInstance, wird auf
einem Solarissystem mit der CPU sparc ausgeführt. Unter General wird der Name
des Prozessors angegeben.
Abbildung 9 - Deployment Spezifikation
- 12 -
3. Validierung & Verifikation
3.1 Simulation
Rational Rose RealTime bietet die Möglichkeit Sequenzdiagramme zu visualisieren.
Abbildung 10 - Visualisierung eines Sequenzdiagramms
Abbildung 10 zeigt ein Sequenzdiagramm aus einem Beispiel von Rational Rose
RealTime. Der Nutzer hat die Möglichkeit nachdem er sein Model kompiliert hat,
dieses auszuführen. Während der Ausführung wird der aktuelle Zustand bzw. die
aktuelle Transition des Statecharts hervorgehoben. Zusätzlich wird ein Trace File
erstellt. Das Trace File protokolliert die Zustandswechsel. Dabei werden u. a. der
Zeitpunkt und das Signal, das gesendet bzw. empfangen wurde gespeichert.
3.2 Analysen
Neben der Simulation bietet Rational Rose RealTime die Möglichlkeit
Sequenzdiagramme, Kollaborationsdiagramme und Capsule Strukturdiagramm zu
validieren. Abbildung 11 zeigt einen Dialog zur Validierung eines
Sequenzdiagramms. Bei der Validierung werden formale Abhängigkeiten überprüft.
Der Nutzer hat die Möglichkeit anzugeben, was genau geprüft werden soll. Bei der
Validierung aus Abbildung 11 hat Rational Rose RealTime herausgefunden, dass an
der Nachricht ConvoyEnded kein Signal spezifiziert wurde.
- 13 -
Abbildung 11 - Validierung von Sequenzdiagrammen
Zudem werden bei der Code Generierung Klassen- und Capsulediagramme validiert.
Hierbei wird überprüft, ob z.B. bei allen Methoden ein Rückgabetyp angegeben
wurde. Ist dies nicht der Fall, so erhält der Nutzer eine Fehlermeldung. Der Code
wird jedoch fehlerhaft erzeugt, so dass eine Inkonsistenz zwischen dem Model und
dem Code entsteht.
- 14 -
4. Echtzeitmodellierung
Im Folgenden wird erläutert, in wie fern mit Rational Rose RealTime echtzeitfähige
Software modelliert werden kann.
4.1 Echtzeitmodell
Laut Rational Rose bieten Capsules, Ports, Protokolle und Capsule Struktur
Diagramme die Möglichkeit echtzeitfähige Software zu modellieren. Zudem bietet das
Case Tool eine eigene Service Library an, die es dem Anwender ermöglicht
Methoden zu nutzen, die u. a. Echtzeitverhalten umsetzen können. Vor allen Dingen
Timing Ports nutzen Funktionen, die Echtzeitverhalten umsetzen.
4.2 Modellierung von Echtzeitverhalten
Echtzeitverhalten kann in Rational Rose RealTime nur durch Timing Ports modelliert
werden.
In Sequenzdiagrammen kann zwar die Dauer einer Nachricht spezifiziert werden,
aber die Code Generierung für Sequenzdiagramme ist nicht vorhanden. Statecharts
bieten kein Konstrukt um Echtzeitverhalten zu modellieren.
Der Nutzer hat die Möglichkeit Timing Ports durch Code, in dem er Methoden der
Service Library nutzt, zu ergänzen. Es kann z.B. ein Timer gestartet werden, der all n
Sekunden ein Signal an einen anderen Port sendet.
Weitere Möglichkeiten zur Modellierung von echtzeitfähiger Software existieren nicht.
- 15 -
5. Code Generierung
Rational Rose RealTime ermöglicht die Code Generierung von C, C++ und Java. Im
Folgenden wird die Code Generierung für Java beschrieben:
5.1 Umfang
Rational Rose RealTime generiert Code für Klassen, Statecharts, Capsules,
Protokolle und Capsule Strukturdiagramme. Für Klassen, Capsules und Protokolle
wird je eine Klasse angelegt. Die Attribute und Methoden werden aus dem Model
übernommen.
5.2 Zielplattformen
Rational Rose RealTime unterstützt keine plattformspezifische Code Generierung. Es
ermöglicht die Ausführung des generierten Codes auf folgenden Plattformen: AIX,
HPUX10, OSE, pSOS, Solaris, VRTX, VxWorks, Windows CE und Windows NT.
5.3 Konzept
Für die Java Code Generierung in Rational Rose RealTime werden zusätzlich ein
Make Programm, ein Java Compiler, ein Java Archiver und die Java Virtual Machine
benötigt.
Rational Rose RealTime erstellt für jede Klasse, jede Capsule und jedes Protokoll
eine eigene Klasse. Die vom Nutzer definierten Attribute und Methoden werden
korrekt in den generierten Code übernommen. Die definierten Ports befinden sich in
einer PortListe. Die generierte Klasse stellt zusätzlich Methoden zur Verfügung, die
es ermöglichen auf die einzelnen Ports zuzugreifen.
Das durch Statecharts beschriebene Verhalten und die durch Capsule
Strukturdiagramme beschriebene Struktur werden durch Implementierung von
Methoden in der dazugehörigen Capsule Java Klasse realisiert.
Bei der Generierung von Java Code, werden nicht nur die entsprechenden Java
Klassen erstellt, sondern noch zusätzliche andere Dokumente, wie zum Beispiel ein
Makefile und ein Pearl-Dokument, das den Klassenpfad enthält.
5.4 Qualität
Der von Rational Rose RealTime generierte Code weist keine Fehler auf. Lediglich,
wenn der Benutzer etwas falsch spezifiziert wird fehlerhafter Code erstellt. Gibt der
Benutzer z.B. keinen Rückgabetyp bei der Definition einer Methode an, so erhält der
Nutzer zwar eine Fehlermeldung, der Code wird jedoch trotzdem erstellt und als
Rückgabetyp wird void angenommen.
Ein Nachteil bei der Code Generierung ist, dass sehr viele Konstrukte genutzt
werden, die die Service Library zur Verfügung stellt.
protected void rtEnumeratePorts(
com.rational.rosert.Capsule.PortList list )
{
- 16 -
super.rtEnumeratePorts( list );
list.add( this.shuttle_comm );
}
Beispiel 1 - Nutzung der Service Library
Beispiel 1 zeigt einen Codeausschnitt aus der Capsule Shuttle. Die Methode
rtEnumeratePorts bekommt eine PortListe übergeben, in der der Port
shuttle_comm der Capsule Shuttle eingetragen wird. Die PortListe stammt
aus der Service Library von Rational Rose RealTime.
Bei der Generierung von Attributen und Methoden, die vom Nutzer definiert worden
sind, fällt auf, dass diese sehr stark kommentiert werden.
// {{{RME classAttribute 'position'
private float position = 0.0;
// }}}RME
Beispiel 2 - Attribut Deklaration
Beispiel 2 zeigt die Deklaration des Attributes position, die von einem Kommentar
umgeben ist. Dies weist daraufhin, dass das Case Tool die Kommentare benötigt um
den Code der Capsule korrekt in das Tool zu importieren.
- 17 -
6. Qualität
Im Folgenden werden die Case Tool spezifischen
Qualitätskriterien von Rational Rose RealTime vorgestellt.
und
die
allgemeinen
6.1 Case Tool spezifische Qualitätskriterien
6.1.1 Konsistenzmanagement
Im Allgemeinen wird der Nutzer bei der fehlerhaften Erstellung eines Diagramms
durch eine Fehlermeldung darauf hingewiesen. Der Nutzer hat allerdings die
Möglichkeit diese zu ignorieren. Bei Sequenz-, Kollaborations- und Capsule
Strukturdiagrammen werden die Diagramme nicht automatisch auf Fehler überprüft,
sondern werden nach der Modellierung mittels einer Validierungsfunktion überprüft.
Rational Rose RealTime unterscheidet bei der Modellierung die logische Sicht und
die grafische Sicht. In der logischen Sicht sind die vier Views, Use Case, Logical,
Component und Deployment View, mit ihren dazugehörigen Diagrammen aufgeführt.
Wird ein Diagrammteil aus der grafischen Sicht entfernt, so wird er nicht automatisch
aus der logischen Sicht entfernt. Löscht der Nutzer einen Diagrammteil aus der
logischen Sicht, so wird dieser ebenfalls aus der grafischen Sicht entfernt. Dies führt
zu Inkonsistenzen.
Zudem führt das Anlegen von Diagrammen in der logischen Sicht ebenfalls zu
Inkonsistenzen, da diese dann nicht in der grafischen Sicht angezeigt werden.
Werden Diagramme allerdings in der grafischen Sicht angelegt, so sind diese auch in
der logischen Sicht vorhanden.
6.2 Allgemeine Qualitätskriterien
6.2.1 GUI / Benutzerführung
Die Benutzerführung ist für erfahrene Modellierer sehr intuitiv. Die wichtigsten
Möglichkeiten finden sich sowohl im Menu, als auch in Form von Icons in einer
Toolbar wieder.
Der Nutzer hat außerdem die Möglichkeiten sich in einem gewissen Umfang seine
Benutzeroberfläche selbst zu konfigurieren. Er kann selbst entscheiden, welche Teile
der GUI er angezeigt haben möchte.
6.2.2 Stabilität
Rational Rose RealTime läuft in der getesteten Version unter Solaris sehr stabil,
wenn auch zu weilen etwas langsam.
6.2.3 Dokumentation
Rational Rose RealTime bietet eine sehr umfangreiche Dokumentation an. Für
Einsteiger sind vor allen Dingen die Beispiel Tutorials sehr hilfreich. Neben einer
Beschreibung liefert Rational die Beispiele auch als Datei mit, so dass diese mit
Rational Rose RealTime geöffnet werden können und mit wenigen Änderungen auch
ausgeführt werden können.
- 18 -
Allerdings werden einige Themen, wie zum Beispiel die Echtzeitmodellierung nicht
sehr ausführlich in der Dokumentation behandelt.
6.2.4 Interoperabilität
Neben Programmen, die für die Unterstützung für Teams notwendig sind (siehe
Kapitel 1.5.1), bietet Rational Rose RealTime die Möglichkeit zur Kooperation mit
allen anderen Programmen von Rational.
- 19 -
7. Vergleich
7.1 Übersicht
7.1.1 Hintergrund / Entwicklung
•
•
Von der Rational Software Corporation, die mittlerweile zu IBM gehört,
entwickelt
Entwicklung von Echtzeitsystemen auf Basis von UML und ROOM
7.1.2 Vergleich der Anwendungsbereiche/Ausrichtung
•
Entwicklungsumgebung für Real-Time Software
7.1.3 Vergleich der Allgemeinen Angaben
•
•
Entwicklungsplattform: Windows, Solaris, HPUX
Preis: Basisversion ca. 9045€ pro Lizenz; Support ca. 1810€ pro Jahr
7.1.4 Vergleich der Notationen- /Sprachenunterstützung
•
Siehe Tabelle Vergleich.pdf im Anhang
7.1.5 Architektur
•
Unterstützung für Teams mit Rational Clear Case, Microsoft Visual Source
Safe, RCS und SCCS möglich
7.2 Validierung & Verifikation
•
•
Simulation
o Zeitunterstützung: ja
o Visualisierung: Statecharts
o Debugging: k.A.
Modelchecking
o Zeitunterstützung
o Visualisierung
o Debugging
7.3 Echtzeitmodellierung
•
Zeitmodell:
o Hart/Weich: nicht definiert (hart?)
o Zeiteinheit (ms/ticks): nicht definiert
7.3.1 Welche Ausdrucksmöglichkeiten für Zeit werden unterstützt?
•
- 20 -
Ausdrucksmöglichkeiten für Zeit:
•
o Statecharts: nein
o Sequenzdiagramme: Dauer der Nachricht
o Weitere Diagrammarten: Capsules, Timing Ports
Eingebettete/Hybride Systeme:
o Extra Diagramme: nein
o Speicherrestriktionen: nein
o Integration kont. Modelle: nein
7.4 Code Generierung
•
Codegenerierung für Klassen, Capsules, Protokolle, Statecharts und Capsule
Strukturdiagramme
7.5 Qualität
•
•
•
•
•
•
•
Konsistenzmanagement: gut
Unterstützung Reengineering: ausreichend
GUI: gut
Benutzerführung: gut
Stabilität: sehr gut
Dokumentation: befriedigend
Interoperabilität: gut
7.6 Zusammenfassung
Rational Rose RealTime eignet sich sehr gut für die Modellierung von nicht
echtzeitfähiger Software. Lediglich die eingeschränkte Version der Statecharts und
die Inkonsistenzen zwischen der grafischen und der logischen Sicht trüben diesen
Eindruck ein wenig. Allerdings bietet Rational Rose RealTime außer den Timing
Ports keine weitere Möglichkeit Zeit zu spezifizieren.
- 21 -
8. Zusammenfassung
Rational Rose RealTime hilft dem Nutzer durch die Aufteilung in die vier
verschiedenen Views gut bei der Modellierung. Allerdings stören dabei die
Inkonsistenzen zwischen der logischen und der grafischen Sicht.
Laut Werbeprospekt bietet Rational Rose RealTime dank der zusätzlichen
Diagramme, die aus ROOM entstanden sind, die Möglichkeit echtzeitfähige Software
zu modellieren. Letztendlich bietet das Case Tool lediglich Timing Ports und eine
Service Library, die echtzeitfähige Software nur in Ansätzen unterstützen, da z.B.
keine Möglichkeit besteht Zeiten bei der Modellierung von Statecharts zu definieren.
Diagramme, wie Capsule Strukturdiagramme bieten keine neuen Informationen und
unterstützten die Echtzeitmodellierung nicht, sonder sollen lediglich die Darstellung
übersichtlicher gestalten.
Positiv fällt auf, dass es mit Rational Rose RealTime möglich ist ein Model zu
erstellen, Code daraus zu generieren, diesen zu kompilieren und auch auszuführen.
Es ist dabei zu empfehlen das Model schon während der Entwicklung auszuführen,
da sich bei einem umfangreichen Model Fehler einschleichen können, die nachher
schwer zu finden sind.
Der von Rational Rose RealTime generierte Code ist fehlerfrei. Nur die vielen
Kommentare stören die Lesbarkeit ein wenig.
Zusammenfassend lässt sich sagen, dass Rational Rose RealTime ein sehr
komplexes Tool ist, das für die Modellierung von echtzeitfähiger Software nur in
Ansätzen geeignet ist.
- 22 -
Literaturhinweise:
[1] Rational Home Page, www.rational.com, Januar 2004
[2] Dr. Ravi Shankar: UML RT for embedded systems, COT 6930: Computer as
components, 02.10.2003
[3] Lutz Bichler, Ansgar Radermacher, Andreas Schürr: Evaluating UML Extensions
for Modeling Real-time Systems, University of the German Federal Armed Forces
Munich, Neubiberg, Germany
[4] Peter Maurer: Heart and Soul – CASE Tools for Real Time Systems on the
Testbed, Karlsruhe, Germany, November 2001
[5] Bran Selic, Garth Gulkerson, Paul T. Ward: Real-Time Object-Oriented Modelling,
1994, John Wiley & Sons Inc
[6] Sven Burmester, Holger Giese, Matthias Tichy, Tobias Schumacher, Björn
Schwerdtfeger, Holger Sinnerbrink, Markus Zarbock: Trends in der Softwaretechnik
für Echtzeitsysteme – Evaluation von Softwarewerkzeugen; Seminararbeit; University
of Paderborn, Paderborn, Germany; january 2004
[7] Olaf Koth, Sven Wolter: Rational XDE Evaluation, Modellierung verteilter OOSysteme mit MDA, UML und MOF; Vortrag
- 23 -