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

Attribute:

Klassenname

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{abstrakt}

Klassenname

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.

Warteschlange

aufnehmen()entnehmen()

I:Element

Wartezimmer

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.

raederZahlmotorlenkradkarosserie

Auto

DaimlerChrysler Vw Audi

MecedesEKlasse MercedesSKlasse Golf Passat A4 A6

serienNummer

mercedesE300:MercedesEKlasse

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.

raederZahl {raederZahl =4}motorlenkradkarosserie

Auto

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.

fahren() : Integerfahren(km : Integer)

raederZahl {raederZahl = 4}motorlenkradkarosserie

Auto

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.

denken()

bewusstsein

Mensch

FrauMann

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

öffnen()

Fenster

öffnen()

Tür

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.

ActorUse Case (Anwendungsfall)

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

Kunde

Lieferantenvertreter

Geldeinsammler

Kunde

Geldeinsammler

Lieferantenvertreter

Getränkeautomat

Getränk ziehen

Auffüllen

Geld holen

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.

PC-einschalten

Initialisieren

do/BootupArbeiten Herunterfahren Herunterfahren

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

frühstücken

hungrig

wieder schlafengehen

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

Kunden anrufen,Termin machen

(Termin außer Haus)

HaustechnikerConsultant

Notebookvorbereiten

Konferenzimmervorbereiten

Kunden treffen

Nachfasschreibenschicken

Angebot erstellen

Angebot anKunden 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

DruckenOffice-Paketschließen

Datei ausdrucken

Datei speichern

Tabellenkalkulation öffnen und nutzen

Grafikprogramm öffnen und nutzen

Dokument tippen

Datei speichern

Datei erzeugen

drucken(Datei) drucken(Datei)

:Drucker

[keine Tabellen erforderlich]

[keine Grafik erforderlich]

[Grafik erforderlich]

[Tabellen erforderlich]

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.

:Name3

:Name1

:Name2

1:Add()

3:update()

2:Modify()

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

:Ausgabe

:Automatenfront

:Register

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

3:ausliefern(Getränk)

einwerfen(Eingabe, Getränk)

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

Ausliefern (Getränk)

Senden(Eingabe)

Einwerfen(Eingabe)

Wählen(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 ).

Die.class

Die.java Craps.java

Craps.class

AWTEventMulticaster

Crapshoot

java.awt.event

ActionListener

java

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 Knoten 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

UnternehmensSuchprogramme

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.

Telefonverzeichnisdes Unternehmens

Suchprogramm Suchergebnisse

Server

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

Telefonverzeichnisdes Unternehmens

Suchprogramm Suchergebnisse

Server

Präsentationsprogramm

Kunde

<<Kommunikation>>

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 JavaTM 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