Sie sind auf Seite 1von 46

Die UML in der Softwareentwicklung

SP1 : Kooperative Systeme, Design f. Kooperation


Prof. Wikarski

Einführung in UML
Objektorientierung
Diagrammtypen in der UML

Ingmar Böckmann boeckman@fh-brandenburg.de


Sebastian Mäder maeder@fh-brandenburg.de
Hendrik Wegener wegenerh@fh-brandenb urg.de
Einführung in die UML

Die Unified Modeling Language (UML) gehört zu den faszinierendsten Tools, die die
moderne Welt der Systementwicklung zu bieten hat.
Sie ist eine Sprache und Notation zur Spezifikation, Konstruktion, Visualisierung und
Dokumentation von Modellen für Softwaresysteme.
Es ist wichtig, immer die richtigen Werkzeuge und Methoden für die passenden
Aufgaben zu verwenden.
Die UML berücksichtigt die gestiegenen Anforderungen bezüglich der Komplexität heutiger
Systeme, deckt ein breites Spektrum von Anwendungsgebieten ab und eignet sich für
konkurrierende, verteilte, zeitkritische, sozial eingebettete Systeme und vieles mehr.
Was ist UML?

UML ist eine von der Object Management Group (OMG) standardisierte Notation und
Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen für die
objektorientierte Softwareentwicklung.

Warum UML?

Mit der UML können Systementwickler Pläne erstellen, die ihre Vision in einer
standardisierten, leicht verständlichen Form aufnehmen und anderen vermitteln.
Das kommunizieren der Vision ist von allerhöchster Wichtigkeit. Bevor die UML aufkam,
gipfelte Systementwicklung oft in einem Vorschlag der das Ziel entweder erreichte oder
verfehlte.
Die weitverbreitete Ansicht, Softwareentwicklung sei in erster Linie eine
technische Aufgabe, entpuppt sich bei näherer Betrachtung des
Entwicklungsprozesses als nur die halbe Wahrheit. Softwareentwicklung ist
heutzutage auch ein komplexer sozialer Prozess.
Kurz gesagt soll es die UML ermöglichen eine universelle Entwicklungsumgebung zu
schaffen, welche vom Systemanalytiker über den Kunden bzw. Anwender, bis hin
zum Systementwickler, für jeden verständlich und nachvollziehbar ist.

Wie ist die UML entstanden?

Angefangen hat alles mit der Idee der Objektorientierung, welche ca. 30 Jahre alt ist.
Während sich objektorientierte Programmierung Ende der 60’er Jahre, bis heute immer weiter
durchsetzte, erschienen objektorientierte Design- und Analysemethoden erst Anfang der 90’er
Jahre. In dieser Hinsicht verbindet man die UML ganz besonders mit den
„drei Amigos“, Grady Booch, James Rumbaugh und Ivar Jacobson. Das sind diejenigen,
welche die wichtigsten und grundlegenden Innovationen in die UML einbrachten.
Grady Booch und James Rumbaugh führten 1995 ihre Methoden zu einer gemeinsamen
Notation zusammen.
Zwei Jahre später integrierten Sie noch die Ideen Ivar Jacobson´s, im speziellen die Use
Cases. Diese Zusammenführung ermöglichte die Bildung eines Quasi- Standards UML.
Durch die Einreichung der Version 1.1 im Jahre 1997 bei der Object Management Group
(OMG) wurde die Standardisierung der UML herbeigeführt.
Die aktuelle Version 1.3 ist im Großen und Ganzen identisch und enthält nur wenige
Korrekturen und Neuerungen.
Die OMG ist momentan für die Weiterentwicklung der UML zuständig.
Ist UML die neue Wunderwaffe?

Mit fast religiösem Fanatismus wurde am Anfang der 90’er Jahre von einigen Leuten die
objektorientierte Analyse und diverse CASE –Tools als die Wunderwaffen für die
Softwareindustrie aufgenommen.
Strukturierte Techniken wurden als „heidnische Riten“ der antiken 70’er
Jahre verteufelt und die objektorientierten Techniken wurden als neue Religion definiert. Es
wurde teilweise von einer Revolution gesprochen. Dies ist sicherlich nicht so, allerdings hat
objektorientierte Softwareentwicklung, durch Einsatz von verschiedenen Sprachen, enorm an
Bedeutung dazu gewonnen. Gänzlich wird ein Großteil der webbasierten Entwicklung mit
Java durchgeführt, was nicht zuletzt auf die umfangreichen Möglichkeiten, welche diese
Sprache bietet, zurückzuführen ist. Die UML bietet die Möglichkeit Softwareentwicklung mit
Java durch Analyse und Design zu verbessern und professioneller zu gestalten. Auch gibt es
neue weiterentwickelte CASE – Tools welche die UML Notation benutzen und auch
unterstützen. Ein aktuelles Beispiel hierfür ist TogetherJ © von der Firma TogetherSoft. Es
soll in Zukunft so aussehen, dass man mit Hilfe von Modellierung eine Softwareentwicklung
betreibt die sich nahe am Geschäftsprozess orientiert. Man kann mit
UML–Modellierung eine Art „Code–Gerüst“ entwickeln und über Bibliotheken von
Methoden, speziell in Java, verfügen. Es kann schließlich mal so aussehen, dass ein Großteil
der Entwicklung durch Modellierung und Auswahl von Methoden erfolgt und der
Programmierer nur noch an diversen Stellen angreift. Allerdings hat man trotzdem in der
Praxis noch mit vielen Schwierigkeiten zu kämpfen und die Softwareentwicklung nutzt diese
Vorgehensweise noch nicht in dem Maße, wie es die Visionen einiger Leute erwartet haben.
Man kann auch mit objektorientierter Softwareentwicklung keine Garantie vergeben, dass
Projektpleiten verhindert werden.
Generell sind diese Technologien kein Allheilmittel, und um Peter Coad zu zitieren „Ein Narr
mit einem Werkzeug ist immer noch ein Narr“.
Dennoch ist das Entwicklungspotential enorm!
Softwareentwicklung mit der UML ist ein zukunftsorientiertes Thema, welches durch
ständige Weiterentwicklung und zunehmender professioneller Verwendung noch mehr an
Routine, Erfahrung und Gewicht gewinnen wird. Dies ist Grund genug auch in der
Wirtschaftsinformatik sich mit dieser Idee und Gedankenwelt auseinanderzusetzen, um
Zusammenhänge zwischen dem Geschäftsfall und der eigentlichen Entwicklung zu verstehen
und die UML zur Modellierung von Geschäftsprozessen zu verwenden.In unserer
Ausarbeitung werden wir die UML und deren Bestandteile erläutern, Verfahrenweisen des
Software–engineering vorstellen und herausfinden wo und wie die UML dort verwendet wird.
Wir gehen davon aus, dass Java als Programmiersprache verwendet und als aktueller Standard
anerkannt wird.
Objektorientierung

Die Objektorientierung ist eine Denkweise die es ermöglicht, in der realen Welt
vorkommende Gegenstände als Objekte zu definieren.
Diese Gegenstände werden auf wenige, in der jeweiligen Situation, semantische
Eigenschaften reduziert.
Mit dieser Denkweise soll es ermöglicht werden, diese realen Systeme sinnvoll in der
Softwareentwicklung umzusetzen.
Es gibt in der Objektorientierung Objekte, Klassen, Attribute und Methoden. Aus den
Beziehungen in der diese verschiedenen Faktoren stehen, ergibt sich die Objektorientierung.
Diese Beziehungen definieren sich durch verschiedene Regeln und Vorgehensweisen, welche
in diesem Kapitel genau beschrieben werden.
Klassen und Objekte

Definition Klasse (Bernd Oestereich Objektorientierte Softwareentwicklung S.223) :

„Eine Klasse ist die Definition der Attribute, Operationen und der Semantik für eine Menge
von Objekten. Alle Objekte einer Klasse entsprechen dieser Definition. „

Notation der Klasse:

Klassen werden durch Rechtecke dargestellt, die entweder nur den Namen der Klasse
(fettgedruckt), oder zusätzlich auch Attribute und Operationen beinhalten. Dabei werden diese
drei Rubriken – Klassenname, Attribute, Operationen – jeweils durch eine horizontale Linie
getrennt.
Klassennamen beginnen mit einem Großbuchstaben und sind Substantive im
Singular(Sammlungsklassen und Ähnliches ggf. im Plural).

Klassenname

Attribute:

Definition Objekt (Bernd Oestereich Objektorientierte Softwareentwicklung S.231) :

„Ein Objekt ist eine im laufenden System konkret vorhandene und agierende Einheit. Jedes
Objekt ist ein Exemplar einer Klasse. Ein Objekt enthält durch Attribute repräsentierte
Informationen, deren Struktur in der Klasse definiert ist. Ein Objekt kann die in der Klasse
definierten Nachrichten empfangen, das heißt es besitzt für jede definierte Nachricht
entsprechende Operationen. Das durch die Nachrichten definierte Verhalten gilt für alle
Objekte einer Klasse gleichermaßen, ebenso die Struktur ihrer Attribute.“

Notation des Objektes:

Objekte werden durch Rechtecke dargestellt die entweder nur ihren Namen tragen, zusätzlich
den Namen Ihrer Klasse oder auch die Werte bestimmter oder aller Attribute.

objekt
Um den Zusammenhang zwischen Klassen und Objekten zu verdeutlichen, möchten
wir hier ein kleines Beispiel einbringen.

Auto

Daimlerchrysler Vw Audi

Mecedeseklasse Mercedessklasse Golf Passat A4 A6

mercedese300:Mercedeseklasse

Auf die Attribute, welche für die Klassen genannt werden müssen, werden wir an
späterer Stelle noch eingehen.
Die drei Fahrzeughersteller Daimler Chrysler, VW und Audi sind nach dem Vorbild
Auto, als Unterklassen der Oberklasse Auto, entstanden. Die Klasse Auto an sich
existiert nicht als eigenständiges Objekt. Auch die Unterklassen Daimler, VW und
Audi existieren nicht als Objekt, zumindest nicht als Auto. Daimler, VW und Audi
bilden wieder Unterklassen, welche auch nicht als eigenständiges Objekt
existieren. Erst der Mercedes E 300 existiert als Objekt der Klasse Mercedes E
Klasse mit dem Attribut Seriennummer, welches ihn unverkennbar macht.
Abstrakte Klassen

Definition Abstrakte Klassen (Bernd Oestereich Objektorientierte Softwareentwicklung


S.228) :

„Von einer abstrakten Klasse werden niemals Objektexemplare erzeugt; Sie ist bewusst
unvollständig und bildet somit die Basis für weitere Unterklassen, die Exemplare (Objekte)
haben können.

Somit steht fest, dass abstrakte Klassen grundsätzlich keine Objekte erzeugen. Sie dienen
somit als Allgemeinbegriff, um einen Oberbegriff für eine Menge konkreter Begriffe
darzustellen.

Notation:

Der Eigenschaftswert {abstrakt} deklariert eine abstrakte Klasse. Dieser Wert steht immer
unter dem Klassennamen. Ansonsten unterscheidet sich die abstrakte Klasse im Aussehen
nicht von einer normalen Klasse. Man kann für die Darstellung einer abstrakten Klasse auch
einfach den Klassennamen kursiv setzen. Attribute, Operationen (Methoden), Zusicherungen,
etc. können auch Bestandteil dieser Klasse sein.

Klassenname Klassenname
{abstrakt}
Metaklasse

In Smalltalk, C++ und CLOS stellen Klassen auch nur Objekte dar. Das heißt es können an
Klassen ebenfalls Nachrichten gesendet werden und diese können Klassenattribute enthalten.

Da wir uns mit diesem Script ausschließlich auf OOSE mit JAVA beschränken, spielt dieser
Klassentyp in unserem Fall keine Rolle, da ein solche Klassentyp in JAVA nicht realisierbar
ist.
Parametrisierbare Klasse

Definition Parametrisierbare Klasse


(Bernd Oestereich Objektorientierte Softwareentwicklung S.226) :

„Eine parametrisierbare Klasse ist eine mit generischen formalen Parametern versehene
Schablone, mit der gewöhnliche (d.h. nicht-generische) Klassen erzeugt werden können.
Die generischen Parameter dienen als Stellvertreter für die aktuellen Parameter, die Klassen
oder einfache Datentypen repräsentieren. „

Einer Klasse werden nur für einen Teil der Attribute Werte zugewiesen, wodurch nicht ein
Objekt, sondern eine neue weitere Klasse entsteht. Diese nennt man jetzt parametrisierbare
Klasse. Diese dazugegebenen Werte nennt man ungebundene Parameter.

Notation:

Parametrisierbare Klassen werden wie Klassen dargestellt. Sie bekommen jedoch in der
oberen rechten Ecke eine Einblendung der Parameter in einem gestricheltem Rechteck.
Die dabei entstehenden Klassen haben eine Verfeinerungsbeziehung mit dem Stereotyp
<<bind>> zur parametrisierbaren Klasse hin.

Wartezimmer
I:Element

Warteschlange

aufnehmen()
entnehmen() Stau
Attribute

Definition Objekt (Bernd Oestereich Objektorientierte Softwareentwicklung S.233) :

„Ein Attribut ist ein (Daten -) Element, das in jedem Objekt einer Klasse gleichermaßen
enthalten ist und von jedem Objekt mit einem individuellen Wert repräsentiert wird.
Im Gegensatz zu Objekten haben Attribute außerhalb des Objektes, von dem Sie Teil sind,
keine eigene Identität. Attribute sind vollständig unter der Kontrolle der Objekte, von denen
sie Teil sind.“

Notation:
Attributnamen beginnen mit Kleinbuchstaben, Klassennamen mit Großbuchstaben,
Eigenschaftswerte und Zusicherung stehen in geschweiften Klammern. Besteht ein
Attributname aus mehreren Wörtern, so werden diese Wörter zusammengeschrieben, während
das erste mit kleinem Buchstaben beginnt wird jedes weitere Wort mit einem Großbuchstaben
begonnen. Die Wörter werden aber ohne Lehrzeichen zwischen den einzelnen Wörtern
geschrieben. Man beginnt nur wegen der besseren Lesbarkeit jedes weitere Wort mit einem
Großbuchstaben. Sinn dieser Schreibweise ist, dass aus den Attributen später JAVA-Code
erzeugt wird und eine getrennte Schreibweise nicht verarbeitet werden könnte.
z.B.: raederZahl, serienNummer
Ein grafisches Beispiel dazu befindet sich auf der folgenden Seite.
Auto

raederZahl
motor
lenkrad
karosserie

DaimlerChrysler Vw Audi

MecedesEKlasse MercedesSKlasse Golf Passat A4 A6

mercedesE300:MercedesEKlasse

serienNummer

Dieses Beispiel wurde durch einige Attribute ergänzt. Die Attribute der Klassen vererben sich
bis auf die Objekte. Das heißt, dass auf jede Unterklasse die Attribute der jeweiligen
Oberklasse zutreffen und jedes Objekt die Attribute der ihm übergeordneten Klasse annimmt.
In diesem Beispiel wurden nicht alle Klassen mit Attributen ausgestattet.
Zusicherung

Definition Zusicherung:

Zusicherungen sind Attribute, welche Bedingungen oder Vorraussetzungen definieren, die


ein Objekt erfüllen muss.
Diese sind notwendig, um ein Objekt genauer zu beschreiben und für weitere Verwendungen
abzugrenzen.
Ein Auto zum Beispiel hat auch diverse Zusicherungen, welche es zu definieren gilt. Es hat
beispielsweise immer 4 Räder.
Somit sieht unsere Klasse wieder anders und genauer beschrieben aus.

Notation: Zusicherungen werden in geschweifte Klammern gefasst.

Auto

raederZahl {raederZahl =4}


motor
lenkrad
karosserie
Methode / Operation / Nachricht

Definition Methode / Operation:

Eine Operation ist das, was eine Klasse bewirken kann oder was Sie (oder eine andere Klasse)
mit dieser Klasse bewirken können.
Genauso wie man Zusatzinformationen für Attribute anzeigen kann, kann man auch
Zusatzinformationen für Operationen anzeigen.
In den Klammern, die auf einen Operationsnamen folgen, kann man den Parameter zeigen,
auf den die Operation angewendet wird, sowie den Typ dieses Parameters.
Eine Methode implementiert eine Operation, sie ist eine Sequenz von Anweisungen.
Die Nachricht überbringt einem Objekt die Information darüber, welche Aktivität von ihm
erwartet wird und fordert es so zur Ausführung einer Operation auf.
Diese besteht aus einem Selektor (einem Namen) und einer Liste von Argumenten. Dieser
Selektor besitzt genau einen Empfänger.

Eine Operation trägt innerhalb einer Klasse eine eindeutige Signatur, die sich aus dem Namen
der Operation und eventuell vorhandenen Parametern (Argumenten) zusammensetzt.
Notation: Name der Operation beginnt mit Kleinbuchstaben. Ein Argument trägt einen, mit
einem Kleinbuchstaben beginnenden, Namen und wird eventuell durch die Nennung eines
Datentyps bzw. einer Klasse näher beschrieben.

Auto

raederZahl {raederZahl = 4}
motor
lenkrad
karosserie

fahren() : Integer
fahren(km : Integer)

Zwischen Argumentname (km) und –typ (Integer) steht ein Doppelpunkt (km :
Integer).
Der Rumpf einer Operation enthält den Code zur Implementierung und ist deshalb
programmiersprachenspezifisch.

Bei der Namensgebung von Operationen mit Argumenten, ist besondere Sorgfalt
geboten. Man sollte möglichst aktive Verben, also einschlägige Tätigkeitswörter
verwenden.
Schnittstelle (Interfaces)

Definition Schnittstelle (Bernd Oestereich Objektorientierte Softwareentwicklung S.240) :

„Schnittstellen beschreiben einen ausgewählten Teil des extern sichtbaren Verhaltens von
Modellelementen (hauptsächlich in Klassen und Komponenten). Schnittstellen sind abstrakte
Klassen (genauer:Typen),
die ausschließlich abstrakte Operationen definieren.“

Notation: Schnittstellenklassen tragen das Stereotyp <<interface>>, ansonsten werden sie


wie gewöhnliche Klassen notiert. Sie benötigen keine Attribute, da sie nur Operationen
enthalten. Diese Operationen definieren nur Signaturen, sind abstrakt und sollten deshalb
kursiv gesetzt werden.

<<interface>>
Klasse
Vererbung

Die Vererbung ist ein weiteres grundlegendes Konzept der Objektorientierung. Es ist ein
Mechanismus, der Gemeinsamkeiten zwischen verschiedenen Klassen, sowie zwischen
Klassen zu ihren Objekten beschreibt.
Als Instanz einer Klasse weist ein Objekt auch sämtliche Charakteristika seiner Klasse auf.
Somit wird die Definition einer Klasse oder eines Objektes erleichtert, wenn diese einer (oder
mehreren) vorher definierten Klasse ähnlich ist.
Dieses Prinzip bildet die Grundlage für eine wichtige Technik, nämlich die ausdrückliche
Beschreibung von Gemeinsamkeiten. Generell funktioniert die Vererbung nach einem
hierarchischen Top- Down Verfahren.
Somit erbt zum Beispiel ein Objekt sämtliche Eigenscha ften aller ihr hierarchisch
darüberliegenden instanziierten Klassen.

Definition Vererbung (Bernd Oestereich Objektorientierte Softwareentwicklung S.261) :

„Vererbung ist ein Programmiersprachenkonzept, daher ein Umsetzungsmechanismus für die


Relation zwischen Ober- und Unterklasse, wodurch Attribute und Operationen der Oberklasse
auch den Unterklassen zugänglich werden.

Generalisierung und Spezialisierung sind Abstraktionsprinzipien zur hierarchischen


Strukturierung der Semantik eines Modells.“

Notation:

Notiert wird eine Vererbungsbeziehung durch einen großen nicht ausgefüllten Pfeil, wobei
der Pfeil von der Unterklasse zur Oberklasse zeigt. Die Pfeile werden wahlweise direkt oder
zu einer zusammengefassten Linie dargestellt. Die direkt gezeichneten Pfeile erlauben ein
flexibles Layout und sind auch von Hand sehr gut zu zeichnen. Die mit einer Linie
zusammengefassten Pfeile betonen stärker die Gemeinsamkeit der Unterklassen, sodass sie
eine Spezialisierung der Oberklasse sind.
Mehrfachvererbung

Der Vollständigkeit halber erklären wir an dieser Stelle die Mehrfachvererbung, obwohl sie
nicht von JAVA unterstützt wird und
kritisch gesehen Probleme schaffen kann.
Bei der Mehrfachvererbung besitzt eine Klasse mehr als eine Oberklasse.
In JAVA gibt es lediglich Einfachvererbung, um den Problemen aus dem Weg zu gehen, die
durch Mehrfachvererbung entstehen können.
Um die Einschränkungen in den Designmöglichkeiten, die bei Einfachvererbung entstehen, zu
vermeiden, wurde mit Hilfe der Interfaces eine neue, restriktive Art der Mehrfachvererbung
eingeführt.
Somit wurden, speziell für JAVA, Interfaces als Ersatzkonstrukt geschaffen, welche genau
dieses Feature bieten.

Mensch
bewusstsein

denken()

Mann Frau

Kind
Polymorphismus

Gleichnamige Methoden in unterschiedlichen Klassen, sind möglicherweise auch voneinander


verschieden. Zum Beispiel ist eine Methode getPosition in der Klasse Kreis anders, als in der
Klasse Rechteck.
Man könnte meinen, dass diese Regel Programmierer mehr betrifft als den Modellierer, da er
diese Methoden ja entwickelt und an die verschiedenen Klassen anpasst.
Aber Polymorphismus ist auch für Modellierer wichtig. Es ermöglicht ihm, den Kunden in
dessen eigener Sprache und Verstehensweise anzusprechen.

Definition Polymorphie (Bernd Oestereich Objektorientierte Softwareentwick lung S.59) :

„Was vom Namen her wie eine Krankheit klingt, ist tatsächlich einer der Eckpfeiler, die die
Objektorientierung so mächtig machen.
Das Vererbungsprinzip sowie die dynamische Typisierung einiger Programmiersprachen oder
das Interface-Konzept bilden die Basis zur Polymorphie.
Polymorphie heißt, dass eine Operation sich (in unterschiedlichen Klassen) unterschiedlich
verhalten kann. Es gibt zwei Arten der Polymorphie: statische Polymorphie (Überladung) und
dynamische Polymorphie.“

Fenster Tür

öffnen() öffnen()
Zusammenfassung

Objektorientierung ist ein Gedankenzusammenspiel oder vielleicht auch „Weltanschauung“ ,


welche aus wenigen Grundprinzipien besteht. Ein Objekt ist eine Instanz einer Klasse. Eine
Klasse ist eine allgemeine Kategorie von Objekten, die dieselben Attribute und Operationen
haben. Wie viele Methoden und Attribute man bei der Erzeugung eines Objektes
berücksichtigt entscheidet der unmittelbare Problembereich.

Vererbung ist eine der wichtigsten Grundprinzipien der Objektorientierung. Ein Objekt erbt
die Methoden und Attribute einer Klasse. Auch eine Klasse kann Attribute und Methoden von
einer anderen Klasse erben.

Polymorphismus ist ebenfalls von Bedeutung. Er ermöglicht es, dass Methoden aus
verschiedenen Klassen, den selben Namen haben können. Wobei jede dieser Klassen die
Methode anders ausführt.
Nützlich ist dieses Prinzip, um Bezeichnungen nach belieben verwenden zu können und somit
den zu modellierenden Geschäftsprozess, für jeden zu veranschaulichen.

Objekte verbergen vor anderen Objekten und vor der Außenwelt, was ihre Operationen
leisten. Jedes Objekt stellt eine Schnittstelle zur Verfügung, damit andere Objekte es zum
ausführen Ihrer Methoden veranlassen können.

Objekte arbeiten zusammen, indem sie einander Nachrichten senden. Dabei handelt es sich
um Anforderungen zum Ausführen von Operationen.

Normalerweise sind Objekte miteinander assoziiert. Die Assoziation kann mehrere Formen
haben. Ein Objekt in der einen Klasse kann sich mit beliebig vielen Objekten einer anderen
Klasse assoziieren.

Die Aggregation ist eine Art Assoziation. Ein aggregiertes Objekt besteht aus einer Menge
von Objekt-Elementen. Diese Komposition ist eine Sonderform der Aggregation. In einem
zusammengesetzten Objekt bestehen die einzelnen Elemente nur als ein Teil der Gesamtheit.
Diagrammtypen
Die UML beinhaltet eine Vielzahl verschiedener Diagrammtypen und Darstellungsformen. Es
ist dadurch möglich, zu jedem Zeitpunkt der Softwareentwicklung das optimale Diagramm
einzusetzen. Genauso ist dadurch immer die beste Sicht, auf das Projekt, für jede an der
Entwicklung beteiligten Person gewährleistet.
Es werden nicht immer alle Diagrammtypen für die Entwicklung benötigt.
Zusammengenommen bieten sie aber die Möglichkeit einer optimalen Visualisierung, des zu
modellierenden Prozesses.
Prinzipiell sagen auch alle Diagramme das selbe aus, nur ist die Gewichtung anders.
Ein Anwendungsfalldiagramm (UseCase) stellt eine Ablaufbeschreibung dar, welche
absichtlich einfach gehalten ist, während Sequenzdiagramme den zeitlichen Ablauf der
Prozesse darstellen.
Wir haben uns bisher nur mit statischen Klassendiagrammen beschäftigt, welche
hauptsächlich die Klassen, Objekte und ihre Beziehungen zueinander beschreiben. Es stellt
damit, unserer Ansicht nach, den wichtigsten, kompliziertesten und umfangreichsten
Diagrammtyp dar. Außerdem ist er entscheidend für die objektorientierte
Softwareentwicklung. Im folgenden wollen wir auf die verschiedenen Diagrammtypen, ihre
Einsatzbereiche und Darstellung eingehen. Um das Zusammenspiel der Diagrammtypen zu
veranschaulichen, werden wir im zweiten Vortrag ein Fallbeispiel präsentieren. Man kann die
verschiedenen Diagramme in unterschiedliche Gruppen aufteilen, oder auch separat
behandeln. Das Anwendungsfalldiagramm, das Klassendiagramm, Verhaltensdiagramme und
Implementierungsdiagramme sind die verschiedenen Diagrammtypen.
Das Anwendungsfalldiagramm (UseCase)
Der Anwendungsfall ist ein mächtiges Konzept, das einem Analytiker hilft zu verstehen, wie
sich ein System verhalten sollte. Er hilft Ihnen, die Anforderungen aus der Anwendersicht zu
sammeln.
Die Visualisierung ermöglicht Ihnen, die Anwendungsfälle den Benutzern zu zeigen, sodass
diese Ihnen zusätzliche Informationen liefern können. Es ist nun einmal Tatsache, dass die
Benutzer oft mehr wissen, als sie artikulieren können: Der Anwendungsfall hilft, das Eis zu
brechen.
Darüber hinaus können Sie in einer grafischen Darstellung Anwendungsfalldiagramme mit
anderen Diagrammtypen kombinieren.
Ein Ziel des Systemanalyse-Prozesses ist, eine Sammlung von Anwendungsfällen
hervorzubringen. Der Grundgedanke dabei ist, diese Sammlung, die das System aus
Anwendersicht darstellt, katalogisieren und referenzieren zu können. Wenn es an der Zeit ist,
das System auszubauen, dient der Anwendungsfallkatalog als Grundlage, um die
Anforderungen an diesen Ausbau zu sammeln.

Use Case (Anwendungsfall)


Actor Actor

In einem Anwendungsfallmodell steht ein Strichmännchen für einen Actor(Akteur), eine


Ellipse für einen Use Case(Anwendungsfall) und eine Assoziationslinie für die
Kommunikation zwischen Actor und Use Case.
Zu beachten ist, dass ein Actor, obwohl als „Männchen“ dargestellt, nicht unbedingt eine
Person sein muss. Es kann sich hierbei auch durchaus um ein Gerät oder ähnliches handeln.

Definition Anwendungsfall (Bernd Oestereich Objektorientierte Softwareentwicklung S.207) :

Ein Anwendungsfall beschreibt eine Menge von Aktivitäten eines Systems aus der Sicht
seiner Akteure, die für die Akteure zu einem wahrnehmbaren Ergebnis führen. Ein
Anwendungsfall wird stets durch einen Akteur initiiert. Ein Anwendungsfall ist ansonsten
eine komplette, unteilbare Beschreibung
Ein Anwendungsfall

Getränkeautomat

Getränk ziehen

Kunde Kunde

Auffüllen

Lieferantenvertreter Lieferantenvertreter

Geld holen

Geldeinsammler Geldeinsammler

Obige Abbildung zeigt ein Anwendungsfallmodell für einen Getränkeautomaten. Akteure


stellen in diesem Fall der Kunde, Lieferantenvertreter und Geldeinsammler dar. Dieses
Anwendungsfallmodel ist sehr grob gehalten und es wäre denkbar, es durch diverse
Verfeinerungen zu präzisieren.
Es gibt Möglichkeiten, solche Use Cases mit Hilfe weiterer Verfeinerungen genauer
auszuarbeiten. Solche sind include, extend, Generalisierung und Gruppierung. Diese
Möglichkeiten sollen an dieser Stelle aber nur namentlich genannt werden und nicht weiter
beschrieben, da die generelle Funktionsweise des Anwendungsfalldiagramms jetzt klar sein
dürfte.
In der Regel sind Anwendungsfalldiagramme Teil eines Entwurfsdokuments, auf das sich
Kunde und Entwicklungsteam beziehen. Jedes Diagramm bekommt eine eigene Seite. Auch
jedes Szenario jedes Anwendungsfalls erhält eine eigene Seite, auf der Folgendes in Textform
aufgeführt ist:

Der Akteur, der den Anwendungsfall initiiert


Die Vorbedingungen für den Anwendungsfall
Schritte, die in das Szenario hineinführen
Folgen, die sich nach Abschluss des Szenarios ergeben
Der Akteur der von dem Anwendungsfall profitiert
Das Klassendiagramm
Klassendiagramme sind der zentrale Bestandteil der UML und beschreiben die statische
Struktur der Objekte eines Systems und ihre Beziehungen untereinander.
Sämtliche Bestandteile der UML können mit dem Klassendiagramm dargestellt werden. Wir
haben bereits im Laufe des Vortrags für die Darstellung von Bestandteilen der
Objektorientierung die Notationen eines Klassendiagramms verwendet. Es ist auch für die
Softwareentwicklung der wichtigste Bestandteil der UML, da es möglich ist mit diesem
Diagrammtyp den Programmcode zu visualisieren. Klassendiagramme finden auch in den
meisten CASE–Tools die zur Softwareentwicklung verwendet werden, einen festen Platz. Es
ist auch die am weitesten bekannte Notation der UML.
Um mit leichtverständlichen Worten zu erklären wie die Klassendiagramme funktionieren,
sollte man vielleicht einmal versuchen, sich zu überlegen, von welchen Dingen man so
umgeben ist.
Mit beinahe hundert prozentiger Sicherheit haben alle dieser Gegenstände irgendwelche
Attribute(Eigenschaften). Wahrscheinlich legen sie auch irgendein Verhalten an den Tag.
Dieses Verhalten bezeichnen wir als Operationen.
Außerdem ist es wohl möglich, die verschiedenen Gegenstände in Kategorien einzuteilen. Als
Beispiel könnte man anführen, dass ein Sessel, ein Schrank und ein Tisch in die Kategorie
Möbel fallen. Die Kategorie Möbel fällt in die Kategorie Einrichtungsgegenstände, usw.
Diese Kategorien bezeichnet man als Klassen. Klassen sind also nichts anderes als Kategorien
oder Gruppen von Dingen, mit ähnlichen Attributen und gemeinsamen Verhaltensweisen.
Klassendiagramme machen also nichts anderes, als die Beziehungen und das Zusammenspiel
zwischen Klassen und Objekten darzustellen. Das tun sie unter Einbeziehung von Attributen
und Operationen. Deshalb stellen sie wahrscheinlich die genaueste Wiederspiegelung des zu
modellierenden Prozesses dar. Und genau aus diesem Grund sind wir im ersten Teil dieses
Vortrags, vor allem auf diese Art von Diagramm eingegangen.
Verhaltensdiagramme
Unter Verhaltensdiagrammen versteht man eine Anzahl von verschiedenen Arten von
Diagrammtypen. Verhaltensdiagramme selbst sind also kein selbständiger Diagrammtyp.
Unter Verhaltensdiagrammen versteht man:

- Zustandsdiagramme ( S.27 )
Aktivitätsdiagramme ( S.28 )
Kollaborationsdiagramme ( S.32 )
Sequenzdiagramme ( S.34 )

Im folgenden sollen diese kurz vorgestellt werden.


Das Zustandsdiagramm

Mit dem Zustandsdiagramm tritt ein Element an die Reihe, das zeigt, welche Änderungen mit
der Zeit auftreten. Wenn man Systeme modelliert, muss man auch über ein Mittel verfügen,
Änderungen zu modellieren.
In einem Zustandsdiagramm ändern Objekte ihren Zustand als Reaktion auf Ereignisse und
den Zeitablauf.
Wenn man einen Schalter umlegt, ändert das Licht seinen An-/Aus- Zustand, oder nach einer
gewissen Zeitperiode ändert eine Waschmaschine ihren Zustand von waschen auf spülen. Das
Zustandsdiagramm ist in der UML für genau diese Änderungen zuständig.

Das Zustandsdiagramm präsentiert die Zustände, in denen sich ein Objekt befindet ,
zusammen mit seinen Übergängen (transitions) zwischen diesen Zuständen und zeigt den
Anfangs- und Endpunkt einer Sequenz von Zustandsänderungen. Es zeigt die Zustände eines
einzelnen Objektes.

Zustand

Obige Abbildung zeigt die Notation für ein Zustandsdiagramm. Das Symbol eines Zustands
ist ein Rechteck mit abgerundeten Ecken. Für einen Zustandsübergang steht eine
durchgezogene Linie mit einem Pfeil. Der ausgemalte Kreis steht für den Anfangspunkt einer
Zustandssequenz und ein ausgemalter Kreis mit einer Kreislinie drumherum (Ochsenauge,
Bullseye) steht für den Endpunkt.
Dieses Zustandssymbol lässt sich noch verfeinern, indem innerhalb des Rechteckes von oben
nach unten der Zustandsname, die Zustandsvariablen sowie die Aktivität eingezeichnet wird.
Diese Angaben werden durch eine horizontale Linie voneinander getrennt.

Initialisieren

Arbeiten Herunterfahren Herunterfahren


PC-einschalten do/Bootup

Ein Beispiel für ein Zustandsdiagramm. Eine Erläuterung ist wohl nicht nötig.
Das Aktivitätsdiagramm

Das Aktivitätsdiagramm der UML ist dem vielbekannten Flussdiagramm sehr ähnlich. Es
zeigt Schritte (passenderweise als Aktivitäten bezeichnet) sowie Entscheidungspunkte und
Verzweigungen. Es ist nützlich, um zu zeigen, was in einem Geschäftsprozess oder einer
geschäftlichen Operation eigentlich geschieht. Sie werden feststellen, dass es ein integraler
Bestandteil der Systemanalyse ist.
Aktivitätsdiagramme sind dazu geschaffen, eine vereinfachte Sicht auf das zu bieten, was
während einer Operation oder eines Prozesses passiert. Es ist eine Erweiterung des
Zustandsdiagramms, allerdings hebt das Aktivitätsdiagramm besonders die Aktivitäten
hervor.

Aktivität 1

Aktivität 2

Die obige Abbildung zeigt den Anfangs- und Endpunkt, zwei Aktivitäten sowie ein
Übergang. Die Notation entspricht der des Zustandsdiagramms.
Aufwachen

nicht hungrig hungrig

wieder schlafen
frühstücken
gehen

Ein Beispiel für ein Aktivitätsdiagramm. Man erkennt hier das Aktivitätsdiagramme
dazu geeignet sind verschiedene Möglichkeiten darzustellen, um
Entscheidungsmöglichkeiten zu visualisieren.
Es gibt noch weitere Möglichkeiten Aktivitätsdiagramme darzustellen. Die wohl
bekannteste und am meisten benutzte sind wohl die „Schwimmbahnen“.

Verkäufer Consultant Haustechniker

Kunden anrufen,
Termin machen

(Termin außer Haus) Notebook Konferenzimmer


vorbereiten vorbereiten

Kunden treffen

Nachfasschreiben
schicken

Angebot erstellen

Angebot an
Kunden schicken

Das ist ein Beispiel für die Schwimmbahn-Version des Aktivitätsdiagramms. Es zeigt
die einzelnen Aktivitäten, welche von den Rollen(Verkäufer, Consultant,
Haustechniker) ausgeführt werden.
Als letztes zum Thema Aktivitätsdiagramme möchten wir an dieser Stelle das sogenannte
Hybriddiagramm vorstellen. Es stellt eine weitere, sehr gebräuchliche Form des
Aktivitätsdiagramms dar.

Textverarbeitung
öffnen

Datei erzeugen

Datei speichern

Dokument tippen

[Grafik erforderlich] Grafikprogramm öffnen und nutzen

[keine Grafik erforderlich]

[Tabellen erforderlich] Tabellenkalkulation öffnen und nutzen

[keine Tabellen erforderlich]

Datei speichern

Datei ausdrucken drucken(Datei) drucken(Datei)

Office-Paket
Drucken
schließen

:Drucker

Dieses Beispieldiagramm verfeinert die Aktivität Datei drucken.


Das Kollaborationsdiagramm

Das Kollaborationsdiagramm stellt dar, wie Objekte interagieren. Es zeigt die Objekte
zusammen mit den Nachrichten, die vom Einen zum Anderen übertragen werden. In dieser
Diagrammform wird der Kontext und die Gesamtorganisation der interagierenden Objekte
dargestellt. Das Kollaborationsdiagramm bietet eine räumliche Darstellung der
Objektinteraktion.

:Name1 1:Add()

:Name2
3:update()

2:Modify()
:Name3

Hier sieht man den Symbolvorrat des Kollaborationsdiagramms. Um die


Anwendungsmöglichkeiten des Kollaborationsdiagramms zu verdeutlichen, bringen wir an
dieser Stelle ein einfaches Beispiel. Siehe nächste Seite à.
einwerfen(Eingabe, Getränk)

:Automatenfront 1:hinzufügen(Eingabe, Getränk)

:Register
3:ausliefern(Getränk)

:Ausgabe
2:ausliefern(Getränk)

Dieses Diagramm stellt das Szenario für die Benutzung eines Getränkeautomaten dar. Im
Einzelnen vollzieht sich die Sequenz so:

1. Der Kunde wirft das Geld in den Geldschlitz einer Automatenfront


2. Der Kunde wählt ein Getränk
3. Das Geld fällt in das Geldzählwerk
4. Das Geldzählwerk prüft, ob das gewählte Getränk vorrätig ist.
5. Das dies ein optimales Szenario ist, nehmen wir an, das Getränk ist vorrätig und das
Geldzählwerk aktualisiert sein Geldbestand.
6. Das Zählwerk veranlasst, dass der Getränkeschacht das Getränk durch die
Getränkeausgabe an der Automatenfront ausliefert.

Dieses Diagramm könnte verfeinert werden in dem ein „kein-passendes-Geld-Szenario“


berücksichtigt wird.
Das Sequenzdiagramm

Das Sequenzdiagramm besteht aus Objekten, die in üblicher Weise dargestellt sind, aus
Nachrichten, sowie der Zeitdauer, die als Fortschritt in senkrechter Richtung dargestellt wird.
Bei diesem Diagrammtyp wird besonders der zeitliche Ablauf betont.
Im Grunde zeigt das Sequenzdiagramm die gleichen Sachverhalte wie das
Kollaborationsdiagramm (à S. 31) allerdings aus einer anderen Perspektive. Beim
Kollaborationsdiagramm steht die Zusammenarbeit der Objekte im Vordergrund, und der
zeitliche Ablauf wird durch die nebenbei aufgeführten Zahlen dargestellt.
Bei dem Sequenzdiagramm steht der zeitliche Ablauf im Vordergrund, welche in senkrechter
Richtung dargestellt wird. Die Zeit beginnt also oben und schreitet noch unten hin voran.
Somit findet eine weiter oben stehende Nachricht früher statt, als weiter unten befindliche
Nachrichten.
In der links - rechts Dimension werden die Objekte angeordnet und die oben – unten
Dimension zeigt den Zeitverlauf.
Es gibt im Sequenzdiagramm Nachrichten, die von einem Objekt zum nächsten gehen. Diese
Nachrichten können einfach, synchron oder asynchron sein.

Mit einer einfachen Nachricht übergibt das Objekt die Ablaufsteuerung an ein anderes Objekt.
Einfache Nachrichten werden durch eine Pfeilspitze aus zwei Linien dargestellt.

einfache Nachricht

Wenn ein Objekt synchrone Nachrichten verschickt, dann wartet es, bevor es mit seiner
Arbeit fortfährt, auf eine Antwort. Synchrone Nachrichten haben eine ausgemalte Pfeilspitze.

synchrone Nachricht

Sendet es eine asynchrone Nachricht, so wartet es keine Antwort ab, bevor es seine Arbeit
wieder aufnimmt. Asynchrone Nachrichten werden durch eine halbe Pfeilspitze visualisiert.

asynchrone Nachricht
:Name 1 :Name 2

In einem Sequenzdiagramm sind die Objekte oben von rechts nach links angeordnet. Die
Lebenslinie eines Objekts ist eine gestrichelte Linie, die von dem Objekt nach unten abgeht.
Eine durchgezogene Linie mit Pfeil verbindet eine Lebenslinie mit einer anderen und stellt
eine Nachricht dar, die ein Objekt einem anderen sendet. Die Zeitdauer beginnt oben und
schreitet nach unten fort. Zwar ist es normalerweise ein Akteur, der die Sequenz initiiert, aber
das Akteurssymbol gehört nicht zum Symbolvorrat des Sequenzdiagramms.
:Automatenfront :Register :Ausgabe

Einwerfen(Eingabe)

Wählen(Getränk) Senden(Eingabe)

Ausliefern (Getränk)

Hier verwenden wir mal wieder das Beispiel des Getränkeautomaten, nur das wir in
diesem Fall das Sequenzdiagramm benutzen, um den zeitlichen Ablauf genauer zu
beschreiben.
Wir setzen voraus, dass in dem Getränkeautomaten drei Objekte die Arbeit, mit
der wir es zu tun haben, verrichten.
Die Automatenfront, das Geldzählwerk und die Getränkeausgabe sind diese
Objekte.
Außerdem nehmen wir an, dass das Geldzählwerk die Getränkeausgabe kontrolliert.
Um das Sequenzdiagramm zu erstellen, haben wir die gleichen 6 Sequenzschritte
wie zur Erstellung des Kollaborationsdiagramms verwendet. (à S. 33 )

Zusammenfassend ist zu sagen, dass man mit Hilfe des Sequenzdiagramms einen
Anwendungsfall, oder alle Szenarien einen Anwendungsfalls anzeigen lassen kann.
Es besteht ebenfalls die Möglichkeit im Beispiel if – Anweisungen oder while –
Schleifen zu visualisieren.
Implementierungsdiagramme
Unter Implementierungsdiagramme versteht man eine Anzahl von verschiedenen Arten von
Diagrammtypen. Implementierungsdiagramme selbst sind also kein selbständiger
Diagrammtyp.
Unter Implementierungsdiagrammen versteht man:

Komponentendiagramm ( S. 38)
Verteilungsdiagramm ( S. 42)

Im folgenden sollen diese kurz vorgestellt werden.


Das Komponentendiagramm

Eine Softwarekomponente ist ein physischer Teil eines Systems. Sie ist nicht im Kopf eines
Analytikers, sondern auf einem Computer angesiedelt.

Was ist eine Komponente?

Ein Tabelle, eine Datendatei, eine ausführbare Datei, eine *.dll, ein Dokument ... usw.

Welche Beziehung gibt es zwischen einer Komponente und einer Klasse?

Sie können sich eine Komponente als Softwareimplementierung einer Klasse vorstellen. Die
Klasse repräsentiert eine Abstraktion einer Menge von Attributen und Methoden. Eines darf
man bei Komponenten und Klassen nicht vergessen:

Eine einzige Komponente kann die Implementierung von mehr als einer Klasse sein.
Wenn sich die Komponente auf einem Computer befindet und ein funktionierender Teil des
Systems ist, warum sollte man sich dann die Mühe machen, sie zu modellieren?

Man modelliert Komponenten und ihre Beziehungen, um Folgendes zu erreichen:

1. Die Kunden können die Struktur im fertigen System sehen.


2. Die Entwickler haben eine Struktur, auf die sie hinarbeiten können.
3. Technische Autoren, die die Dokumentation und Hilfedateien liefern müssen, wissen,
worüber sie eigentlich schreiben.
4. Sie machen alles bereit zur Wiederverwendung.

Letzteres ist wahrscheinlich das Wichtigste am Komponentendiagramm.


Durch die Wiederverwendbarkeit der entwickelten Software, werden Ressourcen für weitere
Projekte geschaffen und die Erweiterbarkeit der Software gesichert. Man erreicht dadurch ein
effizienteres Arbeiten!
calculator.java

Im obigen Beispiel wird das Symbol für eine Komponente dargestellt. Das Hauptsymbol eines
Komponentendiagramms ist ein Rechteck, das links von zwei kleineren Rechtecken überlappt
wird.
Den Namen der Komponente schreibt man in das Symbol hinein. Dargestellt wird der Name
als eine Zeichenkette ( String ).
Crapshoot

Die.class Craps.class

Die.java Craps.java

java

java.awt.event

AWTEventMulticaster ActionListener

Um ein Beispiel für die Darstellung eines Komponentendiagramms zu liefern, haben wir uns
für ein Diagramm aus Roger Cadenheads Internetspiel Craps entschieden. (Roger Cadenhead
Teach Yourself Java 1.1 Programming in 24 Hours (Sams.net Publishing, 1997))
Die Web-Seite ist die Datei Craps.html. Der Quellcode des Applets befindet sich in der Datei
Craps.Java und der Objektcode in der Datei Craps.class. Der Quellcode für die Klasse Die
befindet sich in Die.Java und der entsprechende Objektcode in Die.class. Alle fünf Dateien
liegen in ein und demselben Verzeichnis; nennen wir es einfach Crapshoot.

Natürlich hängt Craps.html von Craps.class und von Die.class ab. Jede .class-Datei ist eine
Komponente und jede ist die Implementierung einer Klasse. Was jedoch nicht so unmittelbar
offensichtlich ist (um dies zu erkennen, müsste man den Quellcode lesen), ist, dass Craps.Java
und Die.Java beide das Paket Java.awt importieren (d.h. seine Klassen nutzen), also eine
Gruppe von Klassen, die eine GUI auf dem Bildschirm anzeigen und steuern. (AWT steht für
>>Abstract Windowing Toolkit<<).
Craps.Java ist ein Applet und erbt daher aus der Klasse Java.applet.Applet.
Außerdem importiert Craps.Java noch Java.awt.event und implementiert eine ActionListener
– Schnittstelle ( um auf Ereignisse wie Mausklicks reagieren zu können, die der Benutzer
initiiert ).
Mit dem Code stellt die Schnittstelle ActionListener einen Button bereit, den der Benutzer
anklicken kann, um eine Aktion auszuführen.
Ein Blick in eine JAVA – Referenz würde ihnen sagen, dass die Klasse
Java.awt.AWTEventMulticaster diese Schnittstelle implementiert.
Im Falle unseres Beispieles stellt das eine Paket das Verzeichnis mit den Dateien dar und das
andere mit dem Java Development Kit ©.

Wenn man aus einem bestehenden Code-Stück ein Modell entwickelt, nennt man dies
Reverse Engineering!

Das Komponentendiagramm stellt in gewisser Weise einen besonderen Diagrammtyp dar. Es


stellt nicht konzeptuelle Gegenstände wie eine Klasse oder einen Zustand dar, sondern einen
Gegenstand der realen Welt: eine Softwarewarekomponente.

Anzumerken ist das, obwohl wir für dieses Beispiel JAVA verwendet haben, das
Komponentendiagramm selbstverständlich auch andere Programmiersprachen anwendbar ist.
Das Verteilungsdiagramm

Das Verteilungsdiagramm wird auch Einsatzd iagramm genannt. Es ähnelt sehr stark dem
Komponentendiagramm. (à S. 38 )
Das Verteilungsdiagramm beschäftigt sich ähnlich wie das Komponentendiagramm nicht mit
der Modellierung des Prozesses an sich, sondern mit der Modellierung der zur Einsatz
kommenden Hardware.
Mit dem Verteilungsdiagramm wird der großen Bedeutung der Hardwarezusammensetzung
eines Mehrkomponentensystems eine Möglichkeit der Visualisierung verschafft. Aufgrund
der Tatsache das heutzutage ein System viele verschiedene Plattformen an weit gestreuten
Standorten umfassen kann, ist ein solider Plan für den Hardwareeinsatz das „A und O“ des
Systementwurfs. Die UML stellt Symbole zur Verfügung, mit denen man ein klares Bild
zeichnen kann, wie letztlich die Hardware eingerichtet sein sollte.

Knoten

Das wichtigste Hardwareelement ist ein Knoten. Dies ist ein generischer Name von jeder Art
von Computer – Ressource.
Zwei Arten von Knoten sind möglich :
Ein Prozessor ist ein Knoten, der eine Komponente ausführen kann.
Ein Gerät (device) ist ein Kno ten der dies nicht kann. Ein Gerät (z.B. ein Drucker oder ein
Monitor) bildet in der Regel irgendeine Art von Schnittstelle zur Außenwelt.
Dieser Knoten wird in der UML durch einen Würfel dargestellt. Diesen Würfel wird ein
Name gegeben und man kann darüber hinaus mit einem Stereotyp angeben, um welche Art
von Ressource es sich handelt.
Server

setzt ein:
Telefonverzeichnis des
Unternehmens
Suchprogramme

Der Name ist ein Textstring. Ist der Knoten Teil eines Pakets, so kann sein Name auch den
Paketnamen umfassen. Der Knoten kann in Abschnitte unterteilt werden, die wie oben
gezeigt, Informationen hinzufügen (z.B. die auf den betreffenden Knoten eingesetzten
Komponenten).
Eine andere Möglichkeit, auf die eingesetzten Komponenten hinzuweisen, ist, sie in
Abhängigkeitsbeziehungen in einem Knoten zu zeigen.

Server

Telefonverzeichnis
des Unternehmens

Suchprogramm Suchergebnisse

Hier werden Komponenten in Abhängigkeitsbeziehung mit einem Knoten gezeigt.


Server

Telefonverzeichnis
des Unternehmens

Suchprogramm Suchergebnisse

<<Kommunikation>>

Kunde

Präsentationsprogramm

Hier werden Verbindungen zwischen Knoten dargestellt. Zu beachten ist, dass eine
Verbindung nicht unbedingt ein Stück Draht oder Kabel sein muss. Es kann sich auch um eine
drahtlose Verbindung über Infrarot oder Satellit handeln.

Das Einsatzdiagramm der UML vermittelt einen Eindruck davon, wie das System, wenn es
komplett zusammengesetzt wurde, physisch aussieht. Ein System besteht aus Knoten, wobei
jeder Knoten durch einen Würfel dargestellt wird. Eine Linie zwischen zwei Würfeln
symbolisiert eine Verbindung zwischen zwei Knoten.
Besonders nützlich ist diese Art von Diagrammen um Netzwerke darzustellen.
To be Continued...
… kann man nach dieser kurzen Einleitung in die Welt der UML nur sagen!
In diesem ersten Teil unserer Ausarbeitung haben wir versucht die Grundlagen für den
zweiten Teil zu legen.
Unter Grundlagen verstehen wir die Gedankenwelt, also die Objektorientierung, sowie die
Syntax, also die UML- Diagrammtypen, welche Vorraussetzung für die Arbeit mit dieser
Technologie sind.
Nachdem man sich diese Abschnitte verinnerlicht hat, ist es möglich im zweiten Teil unserer
Ausarbeitung anhand eines Beispieles den Entwicklungsprozess zu erklären. Wir werden des
weiteren erläutern wie Softwareentwicklung funktioniert und wo und wie die UML dort
greift. Die Generierung von Code sowie das CASE – Tool TogetherJ werden Themen des
zweiten Teiles werden.

Wir hoffen mit dieser Ausarbeitung einen interessanten Ausblick in eine neue Technologie
und deren Möglichkeiten gegeben zu haben. Wobei an dieser Stelle betont werden sollte, dass
es sich wirklich nur um eine grobe Darstellung der Zusammenhänge der UML handelt.
Anhand dieses Scripts sollte man in der Lage sein, dass Konzept, den Sinn, die Anwendungs-
möglichkeiten der UML zu verstehen. Mehr nicht!

Ingmar Böckmann boeckman@fh-brandenburg.de


Sebastian Mäder maeder@fh-brandenburg.de
Hendrik Wegener wegenerh@fh-brandenburg.de
Literaturempfehlung

1. Bernd Oestereich – Objektorientierte Softwareentwicklung, 4. aktual. Auflage,


erschienen bei Verlag Oldenbourg
2. Guido Krüger - GoTo Java TM 2 , erschienen bei Verlag ADDISON-WESLEY
3. Peter Coad/Edward Yourdon – Objekt-orientierte Analyse, erscheinen bei Verlag
Prentice Hall Verlag
4. Prof. Dr. Hermann Krallmann – Systemanalyse im Unternehmen
Geschäftsprozessoptimierung, Partizipative Vorgehensmodelle, objektorientierte
Analyse, 2. aktual. Auflage, erschienen bei Verlag Oldenbourg