- Universität Zürich

- Universität Zürich
Seminar in Software Engineering
Spezifikationsverfahren
Wintersemester 2000/2001
28.November 2000
Prof. Dr. Martin Glinz
Nancy Schett
OBJEKTORIENTIERTE
SPEZIFIKATION
UML
Verfasser
Marcel Schleinkofer
Inhaltsverzeichnis
Inhaltsverzeichnis
1
EINLEITUNG.................................................................................................................3
2
ÜBERBLICK ÜBER DIE OBJEKTORIENTIERUNG .....................................................3
2.1
2.2
3
3.1
3.2
4
4.1
4.2
4.3
Meilensteine in der Entwicklung der Objektorientierung..................................................... 3
Die wichtigsten Begriffe der Objektorientierung .................................................................. 4
OBJEKTORIENTIERTE SPEZIFIKATION ....................................................................5
Was bedeutet objektorientierte Spezifikation? ..................................................................... 5
Objektorientierte Spezifikation mit UML – eine kurze Geschichte...................................... 6
ÜBERBLICK ÜBER UML..............................................................................................7
Grundlagen der UML................................................................................................................ 7
Darstellung der verschiedenen Diagrammarten ................................................................... 8
Erweiterungsmechanismus von UML .................................................................................. 14
5
VORGEHENSMODELLE ............................................................................................15
6
ZUSAMMENFASSUNG ..............................................................................................17
7
BEWERTUNG UND FAZIT .........................................................................................17
8
ANHANG A: BESTEHENDE CASE-TOOLS FÜR UML..............................................18
9
ANHANG B: ORGANISATIONEN IM ZUSAMMENHANG MIT UML ..........................18
LITERATURVERZEICHNIS ...............................................................................................18
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 2/18
Kapitel 1 Einleitung
1 Einleitung
Die vorliegende Arbeit, welche im Rahmen des Seminars „Spezifikationsverfahren“ im Wahlgebiet Software Engineering erarbeitet wurde, befasst sich mit der objektorientierten Spezifikation. Dabei stellt
sich die Frage, was genau unter objektorientierter Spezifikation verstanden wird und welchen Stellenwert UML dabei einnimmt.
Um an das Thema heranzuführen, soll als erstes ein kurzer Überblick über die Entstehung und die wichtigsten Begriffe der Objektorientierung gegeben werden, um anschliessend der Frage nachzugehen,
was genau unter objektorientierte Spezifikation verstanden wird.
Was UML ist und welchen Stellenwert diese Sprache innerhalb der objektorientierten Spezifikation besitzt, wird danach aufgezeigt. Der UML wird denn in diesem Manuskript auch am meisten Raum gegeben. Trotzdem: Die Beschreibung der UML kann sich im Rahmen dieser Arbeit nur mit den wichtigsten
Gesichtspunkten befassen, da es sich um ein sehr umfangreiches Konstrukt handelt. UML liefert eine
grosse Zahl von Methoden zur Spezifikation und Modellierung.
Die Autoren der UML, Grady Booch, Jim Rumbaugh und Ivar Jacobson, geben zwar eine grosse Vielfalt
an Modellierungswerkzeugen vor, legen sich aber nicht auf ein Vorgehensmodell fest. Es wird also nicht
aufgezeigt, wie man bei einem Softwareprojekt, insbesondere bei der Spezifikation vorgehen kann. Die
drei UML-Autoren haben aber natürlich auch hier ein Rezept zur Hand, das sich „Rational Unified Process“ nennt und einen praktikablen, auf UML abgestimmten Entwicklungsprozess aufzeigt. Dieses Vorgehensmodell wird zum Schluss vorgestellt, damit man sich die Anwendung der UML besser vorstellen
kann.
Im Anhang zu diesem Text finden sich einige Adressen für objektorientiert CASE-Tools, welche sich der
UML bedienen. Ausserdem listet er wichtige Organisationen im Zusammenhang mit der UML auf.
2 Überblick über die Objektorientierung
Nun, was bedeutet die objektorientierte Sichtweise überhaupt und welches sind die Grundlagen der Objektorientierung?
In diesem Kapitel werden die wichtigsten Meilensteine, welche zur Objektorientierung führten, sowie die
Hauptbegriffe der Objektorientierung als Verständnisgrundlage für die weiteren Kapitel dargelegt. Allerdings wird vorausgesetzt, dass die Beschäftigung mit diesem Thema nicht zum ersten Mal geschieht.
Deshalb ist das Kapitel eher als Repetition zu verstehen, denn als Ersteinführung.
2.1 Meilensteine in der Entwicklung der Objektorientierung
Welche wichtigen Stationen gab es nun in den vergangenen Jahren, bis der Begriff Objektorientierung
mit denjenigen Begriffen besetzt war, mit
Simula 1967
denen er es heute ist?
Parnas 1972
Die Abbildung (1) zeigt
die drei Hauptlinien,
Entity-RelationshipAbstrakte Datentypen
die der ObjektorientieModel, 1976
rung ihre EigenschafInformation Hiding &
ten gaben. Alle BegrifDatenabstraktion
fe werden im nächsten
Vererbung &
Abschnitt kurz erläuObjektmodelle
Ada, Modula2
Polymorphie
tert.
Simula war eine der
OODB
ersten ProgrammierSmalltalk
sprachen mit objektorientierten Prinzipien.
Objektorientierung
Abb. (1)
Meilensteine der Objektorientierung nach [Glinz99a], Kap. 2
Aus dieser Programmiersprache stammen die Idee der Vererbung und des Polymorphismus. 1972
beschreibt David Parnas in einem wegweisenden Artikel "On the Criteria to Be Used in Decomposing
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 3/18
Kapitel 2 Überblick über die Objektorientierung
Systems Into Modules" (Communications of the ACM, Dezember 1972) die Prinzipien des Information
Hidings. Auch Chen muss mit seinem Entity Relationship Model aus dem Jahre 1976 zu einem der Urahnen der Objektorientierung gezählt werden, denn er beschreibt in seinen Modellen Gegenstände als
Objekte.
2.2 Die wichtigsten Begriffe der Objektorientierung
Nachdem im letzen Abschnitt die drei wichtigsten Einflussgrössen auf die Objektorientierung aufgezeigt
wurden, sollen jetzt die wichtigsten Begriffe und Prinzipien der Objektorientierung knapp erläutert werden. Die folgenden Begriffsklärungen stützen sich auf [Glinz99a], Kap. 2 ab.
Objekte und Klassen stehen im Zentrum der Objektorientierung. Die beiden Begriffe sind in der Objektorientierung wie folgt zu verstehen:
Objekte
Objekte sind individuelle, von anderen Objekten eindeutig unterscheidbare Elemente der Realität.
Klassen
Eine Menge von gleichartigen Objekten, die wiederum als Einheit aufgefasst wird,
nennt man Klasse. Die Klasse enthält Attribute und Verhalten (meist Operationen
genannt)
Klassen können mit anderen Klassen (oder sich selbst) in Beziehung stehen. Es lassen sich drei Arten
von Beziehungen unterscheiden:
Assoziationen
Eine Assoziation beschreibt eine Verbindung zwischen Klassen. Die Objekte einer
Klasse sind Merkmale einer anderen Klasse. Assoziationen werden i.d.R. dadurch
realisiert, dass die beteiligten Klassen entsprechende Referenzattribute erhalten.
Assoziationen zwischen Klassen sind den Assoziationen im ERM sehr ähnlich.
Benutzung
Die Attribute oder Operationen einer anderen Klasse können in einer Klasse dazu
benutzt werden, um eigene Attribute und Operationen bereitzustellen.
Vererbung
Eine Klasse kann von einer Oberklasse (meist „Superklasse“ genannt) abgeleitet
werden und „erbt“ dabei die Eigenschaften und Methoden der Superklasse. Die Unterklasse verfügt nun über die Attribute und Operationen der Superklasse, ohne
diese lokal zu definieren. Zusätzlich kann die abgeleitete Klasse weitere Eigenschaften und Methoden besitzen oder die vererbten anders definieren (Überschreiben).
In der objektorientierten Welt bedeutet das Wort Polymorphismus, dessen Übersetzung „Vielgestaltigkeit“ heisst, folgendes:
Polymorphismus
Es ist zwischen horizontalem und vertikalem Polymorphismus zu unterscheiden.
Das erstere bedeutet, dass eine Klasse mehrere Methoden oder Konstruktoren
gleichen Namens mit unterschiedlichen Parameterlisten enthalten kann. Diese Methoden können möglicherweise auch zu unterschiedlicher Wirkung führen. Beim
vertikalen Polymorphismus ist gemeint, dass in einer Vererbungshierarchie mehrere Definitionen einer Methode mit derselben Schnittstelle bestehen können. Hierbei wird erst bei der Laufzeit entschieden, welche Methode aufgerufen wird (dies
wird späte Bindung oder dynamisches Binden genannt). Die aufzurufende Methode wird dadurch bestimmt, dass die Klassenhierarchie von der spezialisiertesten
Klasse aufwärts durchsucht wird.
Information Hiding Dahinter steckt nach [Pomb], Seite 525, die Idee, aus Sicherheitsgründen und zur
Erhöhung der Änderungsflexibilität, die Datenstrukturen, resp. den Aufbau und die
Funktionsweise einer Klasse vom Benutzer zu verbergen. Dies wird dadurch realisiert, dass eine Methode mit einer bestimmten Schnittstelle versehen wird, welche
nach Aussen hin bekannt ist und gewisse Voraussetzungen verlangt. Die Methode
ist ihrerseits dafür zuständig, eine dem Nutzer der Methode bekannte Operation zu
tätigen, ohne dass dieser über den inneren Mechanismus der Methode Kenntnis
besitzen muss.
Abstrakte Datentypen
Unter diesem Begriff versteht man die Zusammenfassung von Daten und der mit
ihnen ausführbaren Operationen innerhalb einer Klasse.
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 4/18
Kapitel 3 Objektorientierte Spezifikation
3 Objektorientierte Spezifikation
Bisher wurde aufgezeigt, wie die Objektorientierung entstanden ist und was im Wesentlichen darunter
zu verstehen ist. Nun soll ein Schritt weitergegangen werden und es wird eine Antwort auf die Frage,
was objektorientierte Spezifikation ist, gesucht. Ausserdem zeigt dieses Kapitel, welche Rolle UML beim
objektorientierten Spezifizieren spielt. Einen tieferen Einblick in die UML verschafft dann das nächste
Kapitel.
3.1 Was bedeutet objektorientierte Spezifikation?
Was ist sind die Grundideen, Methoden und Vorgehensweisen der objektorientierten Spezifikation?
Nach [Glinz99b], Seite 99ff., handelt es sich bei dieser Art der Spezifikation um konstruktive, teilformale
Methoden. Die Grundidee dabei ist, ein System durch eine Menge von Objekten zu spezifizieren. Jedes
dieser Objekte beschreibt einen geschlossenen Teil der Daten, der Funktionalität und des Verhaltens
dieses Systems. Gleichartige Objekte werden durch Klassen modelliert.
Die Spezifikation von nicht-funktionale Anforderungen an Softwaresysteme, wie Leistungsmerkmale,
Randbedingungen und besondere Qualitäten, wird bei der objektorientierten Spezifikation ausser acht
gelassen.
Die funktionalen Anforderungen dagegen werden durch Klassenmodelle, Szenarien und Anwendungsfallmodelle, sowie ein Glossar modelliert. Um die einzelnen Objekte und deren Verhalten zu identifizieren, zählt [Glinz98] vier Verfahrenselemente auf:
§ Szenarien/Anwendungsfallanalysen
§ Objektanalyse
§ Ereignis-/Reaktionsanalyse
§ CRC-Karten
Diese vier Methoden sollen nun beschrieben werden:
Szenarien-/Anwendungsfallanalyse
Zunächst wird ein System durch Beispielsszenarien mit konkreten, beispielhaften Vorgängen beschrieben. Diese verallgemeinert man anschliessend zu Typszenarien (auch use cases genannt). Das
Ergebnis dieses Schrittes kann mit den anderen drei Verfahrenselementen weiterverarbeitet werden.
Objektanalyse
Bei der Objektanalyse analysiert man die vorhandene textliche Beschreibung einer Problemstellung
nach bestimmten Prinzipien, die da wären:
Grammatische Subjekte sind mögliche Kandidaten für Objekte.
Verben beschreiben das Verhalten und die Beziehungen der Objekte untereinander.
Adjektive präzisieren Objekte und liefern Anhaltspunkte für deren Attribute.
Resultat der Objektanalyse ist ein Modell der Objekte und Klassen des Systems (Erläuterungen zur
Darstellung von Klassen erfolgen im nächsten Kapitel).
Ereignis-/Reaktionsanalyse
Das Prinzip dieser Methode ist es, sämtliche Ereignisse zu bestimmen, welche eine Reaktion des zu
modellierenden Systems erfordern. In der Folge bestimmt man alle geforderten Reaktionen auf diese
Ereignisse und untersucht sie detailliert.
Resultat dieser Methode sind wiederum Modelle der Objekte und Klassen, sowie des Verhaltens (Erläuterungen zur Darstellung von Verhalten erfolgen im nächsten Kapitel).
CRC- Karten (Class, Responsibilities, Collaborations)
Diese Idee geht auf [Wirfs90] zurück und meint Karteikarten, auf denen der Name der Klasse(Class), ihre Aufgaben(Responsabilities) und ihre Zusammenarbeit(Collaborations) mit anderen Klassen notiert
werden. Die Arbeit mit den CRC-Karten kann so aussehen, dass zuerst mit der Objektanalyse Kandida-
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 5/18
Kapitel 3 Objektorientierte Spezifikation
ten für Klassen ermittelt werden und für jede Klasse dabei eine Karte erstellt wird. In der Folge vervollständigt man diese, z.B. durch die Anwendung der Ereignis/Reaktionsanalyse oder das Durchspielen
von Szenarien.
Diese vier Verfahrenselemente stellen Möglichkeiten dar, wie Objekte und Klassen identifiziert und charakterisiert werden können. Sie stehen also ganz am Anfang des Spezifikationsprozesses.
Im Laufe der Geschichte der objektorientierten Spezifikation wurden aber eine ganze Reihe von Methodenverbunden entwickelt, mit denen die zentralen Aspekte vor allem auch dargestellt werden können.
Hier beginnt die Geschichte der UML. Als man nämlich nicht mehr nur einige, sondern an die 50 Sprachendialekte für die Modellierung der Anforderungen besass, beschlossen die Vertreter der wichtigsten,
die Stärken ihrer Methoden zu vereinen.
Damit ist der Geschichte der UML ein wenig vorgegriffen.
3.2 Objektorientierte Spezifikation mit UML – eine kurze Geschichte
Die Idee der Objektorientierung wurde in den frühen 70er Jahren aufgegriffen und bald wurden auch die
ersten objektorientierten Computersprachen entwickelt. Neuer ist dagegen der Ansatz der objektorientierten Spezifikation. Dies wurde erst Anfang der 90er Jahre thematisiert und entwickelt.
Bis 1994 gab es ca. 50 objektorientierte Methoden für die Spezifikation und Modellierung zunehmend
komplexerer Anwendungen. Die Tabelle zeigt die drei Methoden, die sich als die wichtigsten entpuppen
sollten.
Autor
Methode
Stärke
Booch
OOAD
besondere Ausdruckskraft während Entwurfs- und Konstruktionsphasen
Jacobson
OOSE (Object-Oriented SoftAnwendungsfälle als Mittel zur Erfassung von
ware Engineering)
Anforderungen
Rumbaugh OMT (Object Modeling Techbesonders nützlich für Analyse und für datenintensive
nique)
Systeme
Abb. (2) Liste der wichtigsten, objektorientierten Methoden
Die Geschichte der UML begann dann 1994, nach [Booch99], Seite xx-xxii:
Oktober 94
Booch (Rational Software Corporation) und Rumbaugh (bisher General Electric,
neu Rational) beginnen die Ideen der jeweils anderen Methoden aufzugreifen.
Ziele der Vereinheitlichung waren:
- Einen Industriestandard zu schaffen.
- Systeme von der Idee bis zum ausführbaren Ergebnis mit objektorientierten
Techniken zu modellieren.
- Eine Modellierungssprache zu entwickeln, die sowohl von Menschen als auch von
Rechnern benutzt werden kann.
Oktober 1995
Version 0.8 dieser Unified Method erscheint. Gleichzeitig stiess Jacobson zu Rational und das Projekt wurde erweitert um OOSE einzugliedern.
Juni 1996
Version 0.9 der UML wurde veröffentlicht. Während des ganzen Jahres 1996 erbaten und erhielten die Autoren Reaktionen aus der Softwareengineering-Gemeinde.
Als klar wurde, dass sich UML durchsetzen würde, gründete man ein UMLKonsortium mit Partnern wie Digital Equipment Corporation, HP, I-Logix, Intellicorp,
IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments und Unisys.
Januar 1997
UML 1.0, das aus der Zusammenarbeit mit dem Konsortium entstand, wurde bei
der Object Management Group (OMG) zur Standardisierung eingereicht.
Juli 1997
Version 1.1 , zur Standardisierung eingereicht. Am 14. November 97 wurde sie von
der OMG angenommen. Übernahme der Weiterentwicklung von UML von der OMG
Revision Task Force (RTF) .
Herbst 1998
Version 1.2 der UML.
Juni 1999
Version 1.3 erscheint.
UML hat sich mittlerweile zu einem Quasi-Standard entwickelt und hat die anderen Einzelmethoden
ziemlich verdrängt. UML stellt eine Reihe von weiteren Verfahrenselementen, oder eher Darstellungsmöglichkeiten von objektorientierten Spezifikationen zur Verfügung. Die Darstellung dieser Diagramme
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 6/18
Kapitel 4 Überblick über UML
erfordert ein vertieftes Analysieren der Anforderungen, wobei wiederum die vier Verfahrenselemente Objektanalyse, Ereignis-/Reaktionsanalyse, Szenarien/Anwendungsfallanalyse und CRC-Karten helfen.
Hinweis
Wie aus dieser Chronologie ersichtlich, ist UML eng mit der Firma Ration Corporation verbunden. Die Firma unterstützt die drei UML-Gurus, welche auch „Amigos“ genannt werden, in ihrer Tätigkeit grosszügig, versteht es aber selbstverständlich diese Aktivitäten für einen positiven Geschäftsgang zu nutzen. Vieles, das über UML gesagt werden kann und muss, ist aus den oben genannten
Gründen mit Rational verbunden und auch unter diesem Gesichtspunkt zu betrachten.
4 Überblick über UML
UML wurde also aus den verschiedenen objektorientierten Methoden, die Anfang der 90er Jahre entstanden, entwickelt. Was die Inhalte und Methoden der UML sind, soll in diesem Kapitel geklärt werden.
In einem ersten Teil geht es darum, grundsätzlich aufzuzeigen, was UML ist und in wo UML im Entwicklungsprozess anzusiedeln ist. UML besteht, um dies vorwegzunehmen, aus einem grossen Teil von
Darstellungsmethoden. Diese werden im zweiten Teil diese Kapitels dargelegt. Allerdings ist hier anzumerken, dass es nicht um eine vollständige Übersicht gehen kann. Dazu ist UML viel zu umfangreich.
4.1 Grundlagen der UML
Nun was ist die UML? Die drei Buchstaben sind die Abkürzung für Unified Modelling Language. Es handelt sich also um eine Modellierungssprache. Laut den Autoren Booch, Rumbaugh und Jacobson, geht
es genauer gesagt um eine Visualisierungssprache, die zur Erstellung von Modellen geeignet ist (in
[Boo99], S. 16-17). UML ist demgemäss eine
§ Spezifizierungssprache, die das Erstellen von präzisen, unzweideutigen und vollständigen Modellen erlaubt, welche das zu entwickelnde System abbildet.
§ Konstruktionssprache, die mittels entsprechender Case-Tools
§ das Forwardengineering ermöglicht: aus einem UML-Modell kann Code in einer Programmiersprache generiert werden.
§ das Reverse-Engineering erlaubt: aus Code der in einer Programmiersprache vorliegt, kann ein
Modell in der UML rekonstruiert werden.
§ allerdings keine visuelle Programmiersprache ist.
§ Dokumentationssprache zur Darstellung von Anforderungen, Architektur, Entwurf, Projektplänen,
Tests und Prototypen von Softwaresystemen.
Die UML stellt hierfür eine ganze Reihe an Diagrammen zur Verfügung, welche die durchgehende und
konsistente Darstellung verschiedenster Aspekte eines Systems unter unterschiedlichen Gesichtspunkten erlaubt (Anm. des Autors: dies ist mindestens ein Anspruch, den die Autoren erheben). Es sind dies
die folgenden Diagramme:
Zweck
Diagramm
Anwendungsfallanalyse
Anwendungsfalldiagramme (Use Case)
Klassenidentifikation
Klassendiagramm, Objektdiagramm
Verhaltensdiagramme:
Verhaltensmodellierung
Aktivitätsdiagramme
Sequenzdiagramme
Kollaborationsdiagramme
Zustandsdiagramme (State diagram)
Implementationsdiagramme:
Implementationsaspekt
Komponentendiagramm (Component diagram)
Einsatzdiagramm (Deployment diagram
Abb. (3) UML Diagrammarten und deren Zweck
Die Beschreibung eines Vorgehensmodells für die Entwicklung gehört nicht zur UML. Es ist also nicht
definiert, in welcher Phase des Softwareentwicklungsprozesses die einzelnen Diagramme angewendet
werden sollen. Dennoch ist es vom Sinn und Zweck der Diagramme her einigermassen klar, wo die einzelnen Diagramme benutzt werden sollten. In der untenstehenden Darstellung hat der Autor dieser Arbeit, den Versuch unternommen, die UML-Diagramme den Phasen eines Softwareentwicklungsprozes-
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 7/18
Kapitel 4 Überblick über UML
ses zuzuordnen, aufzuzeigen, wo die besprochenen Verfahrenselemente ihren Platz haben und welche
Resultate dabei entstehen. Die Darstellung ist von links nach rechts zu lesen, dabei aber in den einzelnen Phasen von oben nach unten. Wie oben bereits gesagt, ist UML auch nicht nur für die Spezifikation
des Systems anwendbar, sondern ebenso für den Entwurf und die Realisierung, was sich in der Darstellung darin äussert, dass die Diagramme in der Designphase einerseits verfeinert und ergänzt werden.
Andrerseits wird darin das System aufgrund der Spezifikation entworfen.
Hinweis
Alle diese UML-Elemente sind relativ unscharf und deshalb auch nicht genau einer Phase
zuzuordnen. Die Darstellung ist deswegen vor allem als Hilfe zum gedanklichen Einordnen von UML zu
verstehen. Der Softwareprozess kann natürlich genauso auch wiederholt (iterativ) durchlaufen werden.
KlassenAnwendungsidentifikation fallanalyse
ProjektDefinition
Konzipierung Entwurf
Realisierung
Komponententest
Spezifikation
Analyse
Szenarien
Use Case
Systemtest
Einführung
Use Case
Fachlexikon
Explorative Prototypen
Objektanalyse
CRC
Impl. 1) Verhaltensmodellierung
Ereignis-/
Reaktionsanalyse
Klassendiagram
Objektdiagramm
Klassendiagram
Objektdiagramm
verfeinern
Aktivitätsdiagramm
Aktivitätsdiagramm
Sequenzdiagramm
Sequenzdiagramm
Kollaborationsdiagramm
Zustandsdiagramm
Komponentendiagramm
Einsatzdiagramm
Dokumentation
Prototypen
UML
Abb. (4)
Verfahren
Ergebnis
1)
Implementationsaspekt
Symbolisiert Output resp. Input:
Die Use Cases werden durch Objektanalyse, CRC etc. weiterverarbeitet.
Softwareentwicklungsphasen mit UML- und nicht UML-Elementen innerhalb eines ergebnisorientierten Softwareentwicklungs-Phasenmodells nach [Glinz99b], S. 25
4.2 Darstellung der verschiedenen Diagrammarten
Bereits im ersten Absatz dieses Kapitels wurden die neun Diagrammarten, welche UML zur Zeit zur Verfügung stellt, aufgelistet. Diese sollen nun detaillierter beschrieben werden. Ziel ist es, ein Verständnis
für die wichtigsten Aspekte der Darstellung zu schaffen. Weil ein durchgehendes Beispiel zu viel Raum
benötigt hätte, sind die Beispiele so gehalten, dass sie die wichtigsten Aspekte aufzeigen, ohne immer
beispielhaft zu sein.
Für weitere Details sei im Übrigen das Buch von Bernd Oesterreich [Oest98] empfohlen. Die Diagramme werden in der Reihenfolge von Abb. (3). erläutert.
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 8/18
Kapitel 4 Überblick über UML
Anwendungsfalldiagramme (Use Case)
Definitionen
Akteur
Use Case
Szenario
Anwender des Systems.
Eine, durch genau einen Akteur angestossene Folge von Ereignissen, welche für
die Akteure zu einem wahrnehmbaren Ergebnis führen. Ein Use Case ist im Gegensatz zum Szenario (nächste Definition) verallgemeinert und deshalb auch als
Typszenario bezeichnet.
Ein einzelner Use Case ist gegebenenfalls weiter zerlegbar, wobei darauf zu achten, dass jeder Teil-Use Case wiederum diesen Anforderungen genügt.
Spezielle Abfolgen von Anwendungsfällen, mit konkreten und beispielhaften Akteuren, Ereignissen und Ergebnissen.
Beschreibung
Das Anwendungsfalldiagramm zeigt die Beziehungen zwischen Akteuren und den Use Cases auf.
Sinnvollerweise modellieren Anwendungsfälle nur diejenigen Aktivitäten, die durch die zu entwickelnde
Software unterstützt werden sollen.
Beziehungen unter Anwendungsfällen können mit den Stereotypen «uses» (in manchen CASE-Tools
auch «include») und «extends» angeschrieben sein.
«uses
Der Use Case von dem aus der Pfeil ausgeht, verwendet denjenigen Use Case,
auf den der Pfeil zeigt.
«extends»
Der Use Case von dem aus der Pfeil ausgeht, erweitert oder variiert den anderen.
Zweck
§ Verständnis für die Anwendungswelt
schaffen.
§ Identifizieren der Aktionen, welche mit
dem System durchgeführt werden sollen.
Notation
§ Entsprechend Legende und Beispieldiagramm.
§ Jeder Use Case wird im Anschluss an
das Erstellen des Diagramms, als
strukturierter Text notiert.
Abb. (5)
Use Case Diagramm nach [Oest98]
Klassendiagramm
Definitionen
Begriffsdefinition von Klasse siehe Kapitel 2.2
Beschreibung
Im Klassendiagramm wird die statische Struktur der Klassen in einem System, sowie ihre Beziehungen
untereinander dargestellt.
Zweck
Visualisierung und Modellierung der statischen Struktur eines Systems
Notation
Klassen
Rechtecke, die entweder nur den mit dem Namen der Klasse (fettgedruckt) oder
zusätzlich mit den Attributen und Operationen bezeichnet sind.
Abstrakte Klassen Abstrakte Klassen besitzen unter dem Namen die Bezeichnung „{abstract}“
Interfaces
Sie tragen oberhalb des Namens das Stereotyp „«Interface»“
Attribute und Operationen
Zusätzlich zu den spezifischen Angaben, welche am besten aus dem Bild abgelesen werden können, ist es bei beiden möglich, Zusicherungen in der Form {Zusicherung} anzugeben.
Sichtbarkeit
+ public, # protected, - private
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 9/18
Kapitel 4 Überblick über UML
Vererbung
Assoziation
Aggregation
Komposition
Packages
Pfeil mit leerer Pfeilspitze, die auf die Superklasse zeigt.
Analog zum ERM können im Klassendiagramm Assoziationen angegeben werden.
Im Beispiel bes0chäftigt eine Firma in der Rolle als „Arbeitgeber“ eine unbestimmte Anzahl an Mitarbeitern in der Rolle als „Arbeitnehmer“.
1 Eine Aggregation ist die Zusammensetzung eines Objektes aus einer Menge von
Einzelteilen. Kennzeichnend für die Aggegatklasse (das Ganze)ist, dass sie Aufgaben stellvertretend für ihre Teile wahrnimmt.
Die Komposition ist ein Spezialfall der Aggregation. Die Kardinalität auf der Seite
des Aggregats kann nur 1 sein. Die Lebensdauer eines Teils ist gleich derjenigen
des Ganzen.
Klassen können zu Packages zusammengefasst werden. Das Beispiel zeigt das
Package1
Klasse
Package
Aggregation
Assoziation
Komposition
Vererbung
Abb. (6)
Notation und Beispiele von Klassendiagrammen
Objektdiagramm
Definitionen
Begriffsdefinition von Objekten, siehe Kapitel 2.2
Beschreibung
Das Objektdiagramm zeigt eine Menge von Objekten und ihre Beziehungen zu einem bestimmten Zeitpunkt. Es dient dazu, den statischen Teil einer Interaktion zu visualisieren, wozu die kollaborierenden
Objekte gehören, nicht aber die Nachrichten.
Zweck
Objektdiagramme haben den Zweck, Instanzen von Klassen zu modellieren.
Notation
Die Notation von Objektdiagrammen ist ähnlich wie die des Klassendiagramms. Allerdings wird der Name des Objektes unterstrichen und die diskriminierenden Attribute werden meistens angegeben.
Abb. (7)
Notation und Beispiel zu einem Objektdiagramm
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 10/18
Kapitel 4 Überblick über UML
Verhaltensdiagramm: Aktivitätsdiagramme
Definitionen
Aktivität
Transition
Synchronisationslinie
Swimlane
Ein einzelner Schritt in einem Verarbeitungsablauf. Sie besitzt einen internen Zustand. Eine oder mehrere Transitionen folgen dem Abschluss der Aktivität automatisch.
Dieser Begriff wird in der UML als Übergang von einem Zustand zu einen anderen
verstanden.
Linie, bei der „gewartet“ werden muss, bis alle Eingangstransitionen stattgefunden
haben, oder von wo aus mehrere Transitionen zeitgleich ausgehen.
Bezeichnet einen Verantwortlichkeitsbereich.
Beschreibung
Aktivitätsdiagramme beschreiben die Ablaufmöglichkeiten eines Systems mit Hilfe von Aktivitäten. Es ist
eine spezielle Form des Zustandsdiagramms, das überwiegend Aktivitäten enthält.
In den Abläufen können Entscheidungen, Parallelität und Verantwortlichkeiten modelliert werden.
Zweck
Diese Diagrammart wird benutzt, um parallele Prozesse und Verantwortlichkeiten zu modellieren.
Notation
Start- und Endzustand wie im Zustandsdiagramm
Aktivität
Transition
Synchronisationslinie
Objektzustand
Objekt
Wenn eine Aktivität eine Änderung eines Objektzustandes herbeiführt, so wird das
geänderte Objekt so dargestellt. (siehe auch Beispiel).
siehe Beispiel.
Swimlanes
Abb. (8)
Aktionsdiagramm nach [Boo99] Seite 301
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 11/18
Kapitel 4 Überblick über UML
Verhaltensdiagramm: Sequenzdiagramme
Definitionen
objekt1
objekt2
1: new()
{a-b>2 sec} 2: Nachricht()
3: Antwort
Eine Nachricht ist ein Austausch von Informationen zwischen
Objekten, i.d.R. als Methodenaufrufe implementiert.
Beschreibung
Eine Sequenz zeigt eine Abfolge von Nachrichten zwischen ausgewählten Objekten, in einer bestimmten zeitlichen Phase, wobei
der zeitliche Ablauf betont wird. Die Zeit verläuft von oben nach
unten.
Zweck
4: delete()
Abb. (9)
Visualisierung des Nachrichtenaustausches zwischen Objekten
und insbesondere der zeitliche Ablauf, resp. die Abhängigkeiten
der Nachrichtenabfolge.
Sequenzdiagramm nach [Oest98], S. 307
Notation
Objekte
Objekt
Lebenslinien
Nachricht
Antwort
Zusicherungen
Gestrichelte, senkrechte Linien (=Lebenslinie) mit einem Rechteck am oberen Ende, in das der Objektname geschrieben ist.
Die Überlagerung der Lebenslinien durch nicht ausgefüllte, senkrechte Balken zeigt
den Steuerungsfokus an. Er gibt an, welches Objekt gerade aktiv ist.
Waagerechte Linie mit geschlossenem Pfeil. Die Nachricht wird in der Form nachricht(argument) notiert.
Steht in Textform über einer Linie mit offener Pfeilform: antwort
Werden in der Form {Zusicherung} angegeben.
Speziell zu beachten sind die Nachrichten new() und delete(), welche beide eine spezielle, im Beispiel
zu sehende, Notation aufweisen, aber von den meisten CASE-Tools so nicht unterstützt werden.
Verhaltensdiagramm: Kollaborationsdiagramme
Alternative Begriffe
Zusammenarbeitsdiagramm, Objektdiagramm, Kooperationsdiagramm
Definitionen
Iteration
Wiederholtes Senden einer Nachricht.
Beschreibung
Ein Kollaborationsdiagramm zeigt die Interaktionen zwischen ausgewählten Objekten in einer bestimmten Situation. Es zeigt die gleichen Sachverhalte wie das Sequenzdiagramm, doch wird die Objektstruktur und die Aufrufe ins Zentrum gerückt. Der zeitliche Verlauf der Nachrichten wird hier mit Nummern
verdeutlicht.
Zweck
Das Kollaborationsdiagramm eignet sich besonders, um spezielle Ablaufsituationen zu klären.
Notation
Assoziationslinien
Sequenznummern
Linie mit Nachricht in Textform und Pfeil, der die Richtung der Nachricht zeigt.
Nummern zeigen die zeitliche Abfolge. Interaktionsauslösende Nachrichten, die von
ausserhalb des Systems kommen, erhalten keine Nummer. Löst der Aufruf einer
Nachricht weiter Nachrichten aus, so erhalten diese Unternummern wie z.B. 1.1
Vorgänger-Bedingung
Aufzählung der Sequenznummern anderer Nachrichten, die bereits gesendet sein
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 12/18
Kapitel 4 Überblick über UML
müssen. Die Nummern werden mit Komma getrennt und mit „/“ abgeschlossen.
Bsp: 1.1,2.3/
Können mit Stern nach einer Sequenznummer dargestellt werden und allenfalls mit
Pseudocode versehen sein: 1,2,* oder 1,2,* [i:=1..n]
Iterationen
Abb. (10)
Kollaborationsdiagramm nach [Oest98], S. 305
Verhaltensdiagramm: Zustandsdiagramme (state diagram)
Definitionen
Zustand
Ereignis
Ein Zustand gehört zu genau einer Klasse und stellt eine Zusammenfassung einer
Menge von möglichen Attributwerten dar, die die Objekte dieser Klasse einnehmen
können.
Ein Ereignis besteht aus einem Namen und einer List möglicher Argumente.
Beschreibung
Ein Zustandsdiagramm beschreibt die wesentlichen Zustände einer einzelnen, interessierenden Klasse
und die Ereignisse, welche
dazu führen. Nicht jede Variablenänderung ist zu modellieren, sondern nur die
massgeblichen Zustände.
Zweck
Das Zustandsdiagramm
wird benutzt, um das dynamische Verhalten einer
Klasse zu modellieren.
Abb. (11) Notation und
Beispiel zu Zustandsdiagrammen, nach [Wahl98]
Notation
Drei spezielle Aktionen sind:
Entry, exit
wird automatisch beim Eintritt, in einen Zustand ausgelöst.
Exit
wird automatisch beim Verlassen in einen Zustand ausgelöst.
Do
wird wieder ausgelöst, solange der Zustand aktiv ist, d.h. nicht verlassen wird.
Implementationsdiagramm: Komponentendiagramm
Definitionen
Komponente
Ausführbares Softwaremodul mit eigener Identität und wohldefinierten Schnittstellen.
Beschreibung
Ein Komponentendiagramm wird benutzt, um die Organisation einer Menge von Komponenten und die
Abhängigkeit zwischen ihnen aufzuzeigen. Es zeigt die Abhängigkeiten zwischen Quellcode, ausführ
baren Dateien, Bibliotheken, Tabellen und Dokumenten im Mittelpunkt. Abhängigkeiten der Komponenten werden mit gestrichelten Pfeilen dargestellt.
Zweck
Komponentendiagramme werden benutzt, um die Organisation und Abhängigkeit von Komponenten zu
zeigen.
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 13/18
Kapitel 4 Überblick über UML
Notation
Siehe Abbildung.
Abb. (12) Notation und Beispiel eines Komponentendiagrammes, Quelle [Wahl98]
Implementationsdiagramm: Einsatzdiagramm (Deployment diagram)
Alternative Begriffe
Konfigurationsdiagramm, Verteilungsdiagramm
Definitionen
Knoten
Darunter wird hier ein zur Laufzeit physisch vorhandenes Objekt, das über Rechenleistung bzw. Speicher verfügt. Beispiele dafür sind: Computer, Geräte.
Beschreibung
Verteilungsdiagramme zeigen, welche Komponenten und Objekte auf welchen Knoten (Prozessen,
Computern) laufen und welche Kommunikationsbeziehungen bestehen.
Zweck
Dieses Diagramm hat die Aufgabe, die Hardware und die darauf verteilte Software zu modellieren. Ausserdem zeigt es auf, welche
Kommunikationsbeziehungen zwischen den
einzelnen Teilen herrscht.
Notation
Knoten werden als Quader dargestellt. Für die
Komponenten und Klassen wird die aus den
anderen Diagrammen übliche Notation verwendet. Allerdings werden häufig auch Icons für die
Darstellung der Knoten verwendet.
Die Verbindungslinien stellen physische Kommunikationspfade dar.
Abb. (13) Notation und Beispiel eines Deployment-Diagrammes nach [Oest98], S. 323
4.3 Erweiterungsmechanismus von UML
Bei der Beschreibung der UML-Diagramme trat verschiedentlich der Begriff „Stereotyp“ auf. Nun dabei
handelt es sich um einen sogenannten Erweiterungsmechanismus von UML. Ausser diesem gibt es
noch weitere. Was dies bedeutet, soll nun dargelegt werden.
UML kennt sogenannte Erweiterungsmechanismen, die es erlauben, UML kontrolliert zu erweitern. Stereotypen, Eigenschaftswerte und Einschränkungen sind dazu zu zählen. Eigenschaftswerte werden hier
nicht weiter beschrieben, da sie zu wenig häufig zum Einsatz kommen.
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 14/18
Kapitel 5 Vorgehensmodelle
Stereotypen sind projekt-, unternehmens- oder methodenspezifische Erweiterungen vorhandener Modellelemente von UML. In der Praxis geben Stereotypen vor allem die möglichen Verwendungszusammenhänge einer Klasse, einer Beziehung oder eines Paketes an. Ein Beispiel dafür ist eine Klasse,
resp. ein Interface, das als Observer im Modell-, View-, Controller-Muster benutzt wird. Die Klasse würde dann mit dem Zusatz «Observer» versehen werden.
Notiert werden Stereotypen, wie bereits gezeigt, als Name in französischen Anführungszeichen: «Name». Optional kann ein stereotypisiertes Element auch durch ein typisches Symbol wiedergegeben werden. ([Boo99], Seite 87)
Einschränkungen geben Bedingungen an, die auf das Modell zutreffen müssen, damit es wohlgeformt
ist. Bsp. in [Boo99], S89. Einschränkungen können als formloser Text beschrieben werden, oder in der
OCL (Object Constraint Language) beschrieben sein. Eine Einschränkung wird als geklammerter Text
wiedergegeben, der in der Nähe des assoziierten Elements steht.
5 Vorgehensmodelle
Im vorhergehenden Kapitel wurden die Diagramme, welche die UML zur Verfügung stellt, beschrieben.
Dabei wurde auch gesagt, dass UML kein eigentliches Vorgehensmodell vorgibt, obwohl die Diagramme
natürlich trotzdem eine gewisse Vorgehensweise implizieren. Inzwischen gibt es verschieden Vorschläge für Vorgehensmodelle. Hier soll der von den UML-Autoren vorgeschlagene Entwicklungsprozess in
seinen wichtigsten Merkmalen vorgestellt werden. Die folgenden Grundzüge sind angelehnt an [Rat]
und [Boo99],S. 501 ff.
The Rational Unified Process (RUP)
Die drei „Amigos“ haben ihren Prozess gemäss der übliche Namensgebungskonvention der RationalProdukte „Rational Unified Process“ (RUP) genannt. Das Ziel dieses Prozesses besteht in der Entwicklung von Software, die
Inception
Elaboration
Construction
Transition
Phasen
höchstmögliche Qualität
besitzt, den Ansprüchen
Requirements
der Endanwender genügt
und Zeitpläne und Budgets
Iteration in der Elaboratieinhält.
onsphase
Analyses
Zusammengefasst sind die
wichtigsten Aspekte des
RUP die folgenden:
Design
Der Prozess durchläuft die
4 Phasen Etablierung (inception), Entwurf (elaboration), Konstruktion (construction), Übergang (transition).
Implementation
Test
Workflows
Iterationen
Itereation 2 ....................................................
Itereation 1
Itereation n
................................................ Itereation n-1
Abb. (14) Nach [Jaco99], S. 11
Jede Phase besteht aus Requirement, Analyse, Design, Implementation und Tests. Allerdings in unterschiedlichem Ausmass, was die Grafik mit der Höhe der Kurven veranschaulicht. Am Ende jeder Phase
soll ein neues lauffähiges Inkrement vorhanden sein, das die weitere Planung und Risikoabschätzung,
sowie Problemerkennung unterstützt.
In der Etablierungsphase geht es um die grobe Erfassung der Geschäftsfälle auf einer relativ hohen
Abstraktionsebene. Dabei sollen alle Use Cases identifiziert und die wichtigsten beschrieben werden.
Auf der anderen Seite müssen hier Erfolgskriterien für das Projekt festgelegt, das Risiko eingeschätzt
und das Projekt budgetiert werden. Ausserdem muss ein Phasenplan mit den wichtigsten Meilensteinen
erstellt werden und die Ressourcenplanung gemacht werden. Weitere wichtige Ergebnisse dieser Phase
sind:
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 15/18
Kapitel 5 Vorgehensmodelle
§
Ein Übersichtsdokument mit den Kernanforderungen, den wichtigsten Features und den hauptsächlichen Rahmenbedingungen.
§ Ein erstes Use Case Model, das allerdings erst zu ca. 10%-20% der gesamten Anwendungsfälle detailliert beschreibt.
§ Ein Projekt-Glossar
§ Einer oder mehrere Prototypen
Ziel der Entwurfsphase ist die Analyse des Problembereichs, die Erstellung eines tragfähigen architektonischen Konzeptes, den Projektplan genau zu entwickeln und die grössten Risiken des Projektes zu
eliminieren. In dieser Phase wird ein ausführbarer Prototyp in einer oder mehreren Iterationen erstellt.
Dieser Prototyp sollt im mindesten die wichtigsten Use Cases aus Phase eins beinhalten. Weitere Ergebnisse dieser Phase sind:
§ Ein Use Case Model, das mindestens zu 80% komplett ist. Die meisten Anwendungsfälle müssen
beschrieben sein.
§ Zusätzliche Anforderungen, die nicht durch Use Cases erfasst werden, müssen geklärt sein.
§ Eine Beschreibung der Software Architektur
§
Ein ausführbarer Prototyp, der einen Querschnitt durch das ganze System darstellt.
§
Eine revidierte Liste der Risiken und der Geschäftsfälle
In der zweitletzten Phase, der Konstruktionsphase werden alle verbleibenden Komponenten und Anwendungsfunktionen entwickelt, ins Produkt integriert und getestet. Ziel ist das Produkt soweit fertigzustellen, dass es für die Übergabe an den Anwender bereit ist. Weitere Ergebnisse dieser Phase sind:
§ Das Handbuch für den Anwender
§ Die technische Beschreibung des Produktes
Während der Übergangsphase wird die Software beim Endanwender eingesetzt. In der Regel ergeben
sich dann weitere Anforderungen oder Anpassungen, die Entwicklungsaufwand erfordern. Deshalb beginnt man diese Phase mit einer Beta-Version des Systems, die später durch ein erstes produktives Release ersetzt wird. Am Ende dieser Phase werden die Erfahrungen ausgewertet und entschieden, ob ein
weiterer Entwicklungszyklus begonnen werden soll. Weitere Aufgaben dieser Phase:
§ Anwender-Training und Ausbildung des Supports
§ Marketing und Distributionsaktivitäten
Zusammenfassend kann gesagt werden, dass es sich um einen iterativen Prozess handelt. Für einfache Systeme kann es völlig legitim sein, das ganze Problem zu definieren, die ganze Lösung zu entwerfen, die Software zu entwickeln und dann das fertige Produkt zu testen. Für komplexe Systeme ist dieser Ansatz aber nicht geeignet. Bei einem iterativen Ansatz wird ein Problem deshalb durch
aufeinanderfolgende Verfeinerungen angegangen. Die Lösung ist nicht von Anfang an vollständig,
sondern wird durch Teillieferungen inkrementell über mehrere Zyklen wachsen. Dadurch kann neuen
Anforderungen und veränderten Geschäftsinteressen Rechnung getragen werden.
Die Entwicklung ist im Rational Unified Process architekturorientiert. Durch die Förderung einer frühen Entwicklung und Überprüfung einer Softwarearchitektur soll die parallele Entwicklung, die Wiederverwendung von Komponenten und letztlich die Wartbarkeit des Systems erleichtert werden.
Die Entwicklungsaktivitäten sind im Rational Unified Process anwendungsfallgesteuert. Mit Nachdruck wird darauf geachtet, dass Systeme auf der Basis eines gründlichen Verständnisses der Art und
Weise, wie das ausgelieferte System benutzt werden soll, entwickelt werden.
Der Rational Unified Process ist konfigurierbar. Wenn auch kein Prozess für alle Branchen und Situationen geeignet ist, so ist dieses Vorgehensmodell doch anpassbar und kann skaliert werden, um den Anforderungen von Projekten gerecht zu werden. Bestandteil des Prozesses sind deswegen Richtlinien,
wie man den Prozess an die Bedürfnis einer Organisation anpassen kann.
Der Rational Unified Process fördert objektive, projektbegleitende Qualitätssicherung und Risikomanagement.
An dieser Stelle sei auf die entsprechende Literatur zur Vertiefung verwiesen [Jaco99], um sich eingehender mit diesem Vorgehensmodell verwiesen.
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 16/18
Kapitel 6 Zusammenfassung
6 Zusammenfassung
Mit der Objektorientierung, welche sich seit den frühen 70er Jahren entwickelte, wuchs auch das Bedürfnis die Spezifikation entsprechend objektorientiert zu betreiben. Verschiedene Ansätze und Methoden dafür wurden Anfang der 90er Jahre entwickelt. Um dem Methodenkrieg ein Ende zu bereiten, wurden verschiedene Methoden zur Unified Modelling Language zusammengefasst. Diese Sprache ist mittlerweile zu einem Industriestandard geworden.
Kern der UML sind eine ganze Anzahl von Diagrammen, welche helfen, ein System zu modellieren, zu
visualisieren und zu dokumentieren. Die Möglichkeiten von UML beschränken sich dabei nicht auf das
Spezifizieren von Anforderungen, sondern geben darüber hinaus auch ein Werkzeug in die Hand, um
Systeme zu entwerfen. Auf der anderen Seite überlässt UML dem Entwickler die Vorgehensweise, also
die Abfolge der zu erstellenden Diagramme und auch die Verfahrenselemente, welche helfen z.B. Klassen zu identifizieren. Als Verfahrenselemente bieten sich für die objektorientierte Spezifikation die Objektanalyse, Ereignis-/Reaktionsanalyse, Szenarien und CRC-Karten an. Als Vorgehensweise für den
ganzen Entwicklungszyklus empfehlen die UML-Autoren den Rational Unified Process, einen anwendungsfallgetriebenen, architekturorientierten und konfigurierbaren Prozess.
7 Bewertung und Fazit
Die Beschäftigung mit der objektorientierten Spezifikation, insbesondere mit UML hat einige Stärken,
Schwächen und Grenzen der objektorientierten Spezifikation zum Vorschein kommen lassen.
Stärken der objektorientierten Spezifikation lassen sich folgende aufzählen:
§
§
§
§
§
§
§
Unterstützt und zwingt zu strukturiertem Vorgehen, Spezifizieren, Analysieren und Implementieren
Anwendung von Frameworks und Design-Patterns wird mit UML vereinfacht.
Schnellere Entwicklung.
UML ist ein Industriestandard
Grosses Informationsangebot über UML
Erweiterbarkeit von UML
Werkzeuge vorhanden
Schwächen sind:
§ im Fehlen von Möglichkeiten zur Dekomposition von Systemen.
§ In der entstehenden Unübersichtlichkeit bei grossen Systemen.
§ In der fehlenden Möglichkeit der Konsistenzprüfung zwischen den einzelnen Modellen.
§ Schlechte, z.T. sehr unstrukturierte Beschreibung der UML v.a. durch die Autoren. Dadurch eher
mühsame Auseinandersetzung mit dem Thema und nicht unbeträchtlicher Einarbeitungsaufwand.
§ Die Diagramme der UML überlappen sich teilweise und sind relativ unscharf abgegrenzt.
§ Die UML ist zu stark auf diesen Diagrammen aufgebaut. Zu wenig in ein Gesamtkonzept eingebettet. Dieses Manko wird durch den RUP teilweise wettgemacht.
§ Durch die z.T. sehr ungenauen Beschreibungen, welche auch von jedem Autor wieder etwas anders
gemacht wird, dürfte es schwierig sein, eine erneute „Dialektvielfalt“ zu vermeiden.
§ Die objektorientierte Spezifikation sieht keine Möglichkeiten zur Spezifikation von nicht-funktionalen
Anforderungen vor.
Grundsätzlich ist UML sicherlich als grosser Fortschritt bei der objektorientierten Spezifikation zu werten
und ein Schritt auf dem richtigen Weg zu mehr Qualität im Software Engineering. Es bleibt aber zu hoffen, dass die bestehenden Mängel in kommenden Versionen ausgemerzt werden und zwar vor allem im
Sinne einer Überarbeitung der bestehenden Syntax und Semantik, nicht jedoch in der Neuerfindung zusätzlicher Diagramme.
Zum Schluss ein Zitat von [Glinz]:
Gebrauch’ sie wohl, die UML, doch brauch sie mit Bedacht,
denn andernfalls ist allzu schnell, nUr Mist und heisse Luft gemacht.
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 17/18
Kapitel 8 Anhang A: Bestehende CASE-Tools für UML
8 Anhang A: Bestehende CASE-Tools für UML
Es gibt mittlerweile eine ganze Reihe von Case-Tools, welche die visuelle Softwareentwicklung mit der
UML unterstützen. Prinzipiell verfolgen alle einen ähnlichen Ansatz. Man modelliert z.B. ein Klassenmodell und das Tool generiert nebenbei z.B. die Java Klassen, Methoden, Attribute und was es da noch automatisch zu generieren gibt. Auch ist das Reverseengineering bei den meisten Tools integriert: aus Code kann automatisch das entsprechende Modell generiert werden.
Die Unterstützung der UML-Diagramme ist noch nicht bei allen Tools komplett vorhanden, doch kann
man vermutlich bei den meisten Programmen darüber hinwegsehen (ausser man müsse einen Vortag
über UML schreiben...)
In [JavaMag] findet sich ein entsprechender Bericht über die folgenden Tools, die meistens als Testversion heruntergeladen werden können.
§ Together von togethersoft, pure Java, www.togethersoft.com
§ Rational Rose von Rational, www.rational.com
§ GDPro4.1 von PrecisionSoftwareGmbH, www.precision.de
§ Innovator 6.2 von MIDGmbH, www.mid.de
§ Argo/UML Version 0.7.0, Open Source Projekt der Firma Tigris, http://argouml.tigris.org
§ OEW von Innovative Software, www.isg.de
§ objectiFVersion 4.5, Download bei microTOOL GmbH, www.microtool.de
9 Anhang B: Organisationen im Zusammenhang mit UML
§
§
§
UML wurde durch die Object Management Group standardisiert: www.omg.org
Seit Herbst 98 wird UML von der OMG Revision Task Force (RTF) weiterentwickelt.
The precise UML group beschäftigt sich ebenfalls mit der Weiterentwicklung von UML und zwar versucht sie mit dem Internet als Plattform die UML zu klären und präziser werden zu lassen, die Korrektheit von UML zu prüfen und die Entwicklung von UML-Case-Tools zu fördern, welche UML strikte umsetzen. Die Adresse ist: http://www.cs.york.ac.uk/puml/
Literaturverzeichnis
[JavaMag]
[Oest98]
[Boo99]
[Jaco99]
[Wahl98]
[Rat]
[Glinz99]
[Glinz99a]
[Glinz99b]
[Glinz98]
[Pomb]
[Wirfs90]
Java Magazin, Ausgabe 7/2000, Software & Support Verlag GmbH, Frankfurt am
Main
Bernd Oesterreich: Objektorientierte Softwareentwicklung, 4. Auflage, Oldenbourg
Verlag München Wien, 1998
Grady Booch, Jim Rumbaugh, Ivar Jacobson: „Das UML-Benutzerhandbuch“, erschienen im Addison Wesley Verlag, 2. Auflage, 1999
Jacobson, Rumbaugh, Booch, „The Unified Software Development Process“, erschienen im Addison-Wesley Verlag, 1999
„UML kompakt“ von Günter Wahl, erschienen im OBJEKTspektrum 2/1998,
Internet: http://www/sigs.de/publications/docs/obsp/umlkompt/umlkompt.htm
Rational Unified Process: Best Practices for Software Development Teams, von Rational,
http://www.rational.com/products/whitepapers/100420.jsp#4
Prof. Dr. Martin Glinz, Unified Modeling Language im Überblick, Vortragsreihe der
ALUMNI Wirtschaftsinfomratik Universität Zürich, September 1999
Prof. Dr. Martin Glinz, Architektur und Enwurf von Software, Vorlesungsskript, April
99
Prof. Dr. Martin Glinz, Software Engineering I, Skript zur Vorlesung WS 99/00, August 99
Prof. Dr. Martin Glinz, Objektorientierte Spezifikation mit UML, Vorlesungsskript WS
98/99
Informatik-Handbuch, 2. Auflage, Carl Hansen Verlag München Wien, 1999
R. Wirfs-Brock, B. Wilkerson, L. Wiener, Responsibility-Driven Design: Adding to
your Conceptual Toolkit. ROAD, 1994
Seminar in Software Engineering, Spezifikationsverfahren
Date: 28.11.2000
Objektorientierte Spezifikation, UML
Seite 18/18
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement