Einführung. Einführung

Transkript

1 Einführung Einführung Im Oktober 1994 haben sich Grady Booch und Jim Rumbaugh bei der Rational Software Corporation zusammengeschlossen, um ihre erfolgreichen Methoden zu einem einheitlichen Industriestandard weiterzuentwickeln. Es entstand zunächst der Vorgänger der Unified Modeling Language (UML), der unter dem Namen Unified Method 0.8 publiziert wurde. Seit Herbst 1995 wirkte auch Ivar Jacobson an der Entwicklung der UML mit. Im Oktober 1996 wurde die Version 0.91 der UML veröffentlicht. Im September 1997 wurde die Version 1.1 der UML publiziert, in die zusätzlich die Ideen verschiedener UML- Partner eingeflossen sind. Die UML 1.1 wurde von der Object Management Group (OMG) im November 1997 als Standard verabschiedet. Die Weiterentwicklung der UML wurde vollständig an die OMG übertragen. Im Juli 1998 wurde von der OMG die UML 1.2 intern freigegeben. Alle Änderungen waren redaktionell und hatten keine Auswirkungen auf den technischen Inhalt. Im Juni 1999 publizierte die OMG die UML 1.3. Wichtige Verbesserungen waren die Beseitigung von Inkonsistenzen zwischen verschiedenen Dokumenten. Außerdem wurden Definitionen und Erklärungen präziser beschrieben. Auch inhaltlich wurden geringfügige Änderungen vorgenommen. Im Mai 2002 erschien die UML 1.4, die kleinere Verbesserungen und einige Erweiterungen enthielt. Auch die UML 1.5, die im März 2003 veröffentlicht wurde, enthielt kleinere Korrekturen. Eine umfangreiche Überarbeitung führte zur UML 2.0, die gegenüber der Version 1.x wesentliche Erweiterungen und Änderungen enthält. Das betrifft beispielsweise die Aktivitäts- und Sequenzdiagramme. Außerdem wurde das Metamodell, d. h. das UML-Modell zur Spezifikation der UML, vollständig überarbeitet. Die ersten Dokumente wurden von der OMG im August 2003 veröffentlicht. Im Oktober 2004 wurde eine korrigierte Version dieses Dokuments fertiggestellt und im 1. Quartal 2005 öffentlich publiziert. In den weiteren Jahren folgten weitere Versionen mit Änderungen und Ergänzungen. Im Februar 2009 wurde die UML 2.2 publiziert. Sie ist bei Drucklegung dieses Buchs die offizielle UML-Version der OMG und wird in diesem Buch verwendet. 1

2 UML-Notationselemente UML-Notationselemente Objekt In der objektorientierten Softwareentwicklung besitzt ein Objekt (object) einen bestimmten Zustand und reagiert mit einem definierten Verhalten auf seine Umgebung. Außerdem besitzt jedes Objekt eine Identität, die es von allen anderen Objekten unterscheidet. Ein Objekt kann ein oder mehrere andere Objekte kennen. Man spricht von Objektbeziehungen (links) zwischen Objekten. Der Zustand (state) eines Objekts umfasst die Attribute bzw. deren aktuelle Werte und die jeweiligen Objektbeziehungen zu anderen Objekten. Attribute sind inhärente, unveränderliche Merkmale des Objekts, während die Attributwerte Änderungen unterliegen können. Das Verhalten (behavior) eines Objekts wird durch eine Menge von Operationen beschrieben. Eine Änderung oder eine Abfrage des Zustandes ist nur mittels der Operationen möglich. Das Objekt wird in der UML als Rechteck dargestellt, das in zwei Felder aufgeteilt werden kann. Im oberen Feld wird das Objekt wie folgt bezeichnet: :Klasse bei einem anonymen Objekt wird nur der Klassenname angegeben. objekt:klasse wenn das Objekt über einen Namen angesprochen werden soll. objekt wenn der Objektname ausreicht, um das Objekt zu identifizieren und der Name der Klasse aus dem Kontext ersichtlich ist. Die Bezeichnung eines Objekts wird immer unterstrichen. Objektnamen beginnen in der UML mit einem Kleinbuchstaben, Klassennamen mit einem Großbuchstaben. Anonyme Objekte werden verwendet, wenn es sich um irgendein Objekt der Klasse handelt. Objektnamen dienen dazu, ein bestimmtes Objekt der Klasse für den Systemanalytiker zu benennen. 2

3 Objekt Im unteren Feld werden optional die im jeweiligen Kontext relevanten Attribute des Objekts eingetragen. Die UML ermöglicht folgende Alternativen: attribut : Typ = Wert attribut = Wert empfehlenswert, da anhand des Werts oft erkannt werden kann, um welche Art von Typ es sich handelt. attribut sinnvoll, wenn der Wert des Attributs nicht von Interesse ist. Objekte und ihre Ob - jektbeziehungen untereinander werden im Objektdiagramm (object diagram) spezifiziert. Es beschreibt Objekte, Attributwerte und Objektbeziehungen zwischen Objekten zu einem bestimmten Zeitpunkt. Objektdiagramme sind sozusagen Momentaufnahmen bzw. Schnappschüsse des Systems. Meistens werden anonyme Objekte verwendet. Konkrete Objekte sind nur in Ausnahmefällen interessant. Zustand (Daten) und Verhalten (Operationen) eines Objekts bilden eine Einheit. Die Daten eines Objekts können nur mittels Operationen gelesen und geändert werden (Geheimnisprinzip). Die Objektidentität (object identity) ist die Eigenschaft, die ein Objekt von allen anderen Objekten unterscheidet. Sie bedeutet, dass alle Objekte aufgrund ihrer Existenz unterscheidbar sind, auch wenn sie zufällig identische Attributwerte besitzen. Die Identität eines Objekts kann sich nicht ändern. Keine zwei Objekte können dieselbe Identität besitzen. Besitzen zwei Objekte mit unterschiedlichen Identitäten dieselben Attributwerte, so spricht man von der Gleichheit der Objekte. Der Objektname identifiziert ein Objekt im Objektdiagramm. Im Gegensatz zur Objektidentität muss er nur im betrachteten Kontext, d. h. innerhalb eines Diagramms, eindeutig sein. Besitzen Objekte in verschiedenen Diagrammen denselben Namen, so kann es sich um unterschiedliche Objekte handeln. Alle gleichartigen Objekte, d. h. Objekte mit denselben Operationen und gleichen Attributen aber im Allgemeinen unterschiedlichen Attributwerten! gehören zu der gleichen Klasse. Jedes Objekt ist Exemplar einer Klasse. 3

4 UML-Notationselemente Stereotyp Bei der Definition vieler UML-Elemente wird das Konzept der Stereotypen (stereotype) verwendet. Es ermöglicht, existierende Modellelemente mit einer geänderten Semantik zu versehen. Beispielsweise gibt der Stereotyp «enumeration» an, dass zwar das Klassensymbol verwendet wird, es sich aber nicht um eine»normale«klasse handelt, sondern das Klassensymbol zur Spezifikation eines Aufzählungstyps verwendet wird (Abbildung unter Attributtyp). Die UML bietet eine Reihe von vordefinierten Stereotypen, die auch Schlüsselworte (keywords) genannt werden. Der UML-Modellierer kann selbst weitere Stereotypen definieren. Klasse Eine Klasse (class) definiert für eine Kollektion von Objekten deren Struktur (Attribute), Verhalten (Operationen) und Beziehungen (Assoziationen und Generalisierungsstrukturen). Sie besitzt einen Mechanismus, um neue Objekte zu erzeugen (object factory). Das Verhalten (behavior) einer Klasse wird durch die Nachrichten beschrieben, auf die diese Klasse bzw. deren Objekte reagieren können. Eine Nachricht (message) aktiviert eine Operation gleichen Namens. Die Klassensymbole werden zusammen mit weiteren Symbolen, z. B. Assoziation und Generalisierung, in das Klassendiagramm eingetragen. Bei großen Systemen ist es im Allgemeinen sinnvoll oder notwendig, mehrere Klassendiagramme zu erstellen. Der Klassenname ist ein Substantiv im Singular. Er beschreibt also ein einzelnes Objekt der Klasse. Beispiele: Mitarbeiter, PKW, Kunde. 4

5 Parametrisierte Klasse Der Klassenname muss innerhalb eines Pakets, besser jedoch innerhalb des gesamten Systems, eindeutig sein. Bei Bedarf wird er in der UML wie folgt erweitert: Paket::Klasse. Classifier Das Konzept des Classifiers ist neu in der UML 2. Man kann sich das Konzept des Classifiers ganz grob als Verallgemeinerung des Klassenkonzepts vorstellen. Da viele Elemente der UML ähnliche Eigenschaften wie die Klasse besitzen, werden diese Eigenschaften im Classifier zusammengefasst und von dort an die jeweiligen Elemente vererbt. Die Abbildung zeigt einen Ausschnitt aus dem Metamodell der UML 2. Der Classifier wird in UML-Modellen nicht direkt verwendet, sondern nur zur Spezifikation des Metamodells und Definition der UML-Konzepte benötigt. Parametrisierte Klasse Eine parametrisierte Klasse (parameterized class, template) ist eine Beschreibung einer Klasse mit einem oder mehreren formalen Parametern. Sie definiert daher eine Familie von Klassen. Jeder Parameter besteht aus dem Namen und dem Typ. Der Typ entfällt, wenn der Parametername bereits einen Typ darstellt. Die Parameterliste darf nicht leer sein. Mehrere Parameter in der Liste werden durch Kommata 5

6 UML-Notationselemente getrennt. Eine parametrisierte Klasse kann Attribute enthalten, die abhängig von den Parametern definiert sind. Damit eine parametrisierte Klasse benutzt werden kann, müssen deren formale Parameter an aktuelle Parameter gebunden werden. Die parametrisierte Klasse wird auch als generische Klasse bezeichnet. Das Binden bzw. die Bindung einer konkreten Klasse an eine parametrisierte Klasse geschieht mithilfe des Generalisierungspfeils und einer gestrichelten Linie, die mit dem Stereotypen «bind» beschriftet ist. Die Zuordnung der aktuellen an die formalen Parameter erfolgt in der Form: formalerparameter->aktuellerparameter, wobei es sich bei dem aktuellen Parameter um einen Typ oder einen Wert handeln kann. Die parametrisierte Klasse Queue besitzt die üblichen Operationen insert() und delete(). Der Parameter T beschreibt einen Typ. Daher sind für diesen Parameter keine weiteren Angaben notwendig. Der Parameter n vom Typ int gibt die maximale Größe der Queue an und besitzt den voreingestellten Wert 5. Welche und wie viele Elemente die Queue verwalten soll, wird (noch) nicht bestimmt. Daher wird das Attribut queue mithilfe des Typs T und der Multiplizität [0..n] definiert. Diese parametrisierte Klasse bildet die Vorlage für die»normalen«klassen. Bei der Klasse Adressbuch wird der Parameter T mit Person und der Parameter n mit dem Wert 100 ersetzt. Im Adressbuch können also maximal 100 Personen gespeichert werden. Bei der Klasse FloatQueue wird nur der Parameter T durch den Parameter float ersetzt. Da für den Parameter n keine Angabe erfolgt, wird der voreingestellte Wert übernommen. In einem Objekt dieser Klasse können also maximal 5 Zahlen vom Typ float gespeichert werden. 6

7 Attribut Schnittstelle Eine Schnittstelle (interface) beschreibt eine oder mehrere Signaturen von Operationen. Diese abstrakten Operationen müssen nicht mit {abstract} gekennzeichnet werden, weil eine Schnittstelle keine anderen Operationen enthalten darf und eine Unterscheidung daher nicht notwendig ist. Für die Notation der Schnittstelle wird das Klassensymbol verwendet, das mit dem Schlüsselwort «interface» gekennzeichnet ist. Von Schnittstellen können im Gegensatz zur Klasse keine Objekte erzeugt werden, sondern Schnittstellen sind sozusagen»leere Hüllen«, die von Klassen realisiert werden müssen. Die Realisierung einer Schnittstelle durch eine Klasse (bzw. durch einen Classifier) bedeutet, dass alle in der Schnittstelle aufgeführten Operationen realisiert werden müssen. Eine Schnittstelle kann auch durch mehrere Classifier realisiert werden. Umgekehrt kann ein Classifier beliebig viele Schnittstellen realisieren. Schnittstellen werden modelliert, um von anderen Klassen benutzt zu werden. Die benutzende Klasse muss nicht wissen, wie die Schnittstelle realisiert ist, sondern ihr reicht das extern wahrnehmbare Verhalten. Attribut Attribute (attributes) beschreiben die Daten, die von den Objekten einer Klasse angenommen werden können. Jedes Attribut ist von einem bestimmten Typ. Alle Objekte einer Klasse besitzen dieselben Attribute, jedoch unterschiedliche Attributwerte. 7

8 UML-Notationselemente Der Attributname muss im Kontext der Klasse eindeutig sein. Außerhalb des Klassenkontextes verwendet man die Bezeichnung Klasse. attribut. Attributnamen beginnen mit einem kleinen Anfangsbuchstaben und dürfen beliebige Zeichen enthalten. Besteht der Attributname aus mehreren Wörtern, so empfiehlt die UML-Spezifikation, dass jedes neue Wort mit Ausnahme des Ersten mit einem Großbuchstaben begonnen wird. Man spricht hier von der Kamelhöcker-Notation. Ein Klassenattribut (class scope attribute) liegt vor, wenn nur ein Attributwert für alle Objekte einer Klasse existiert. Klassenattribute existieren auch dann, wenn es zu einer Klasse noch keine Objekte gibt. Um die Klassenattribute von den (Objekt-)Attributen zu unterscheiden, werden sie in der UML unterstrichen (z. B. klassenattribut). Der Wert eines abgeleiteten Attributs (derived attribute) kann jederzeit aus anderen Attributwerten berechnet werden. Abgeleitete Attribute werden mit dem Präfix»/«gekennzeichnet. Ein abgeleitetes Attribut darf nicht geändert werden. Attribute werden durch Angabe von Typ, Multiplizität, Anfangswert und Eigenschaftswerten spezifiziert. Attributtypen (siehe unten) können Datentypen oder selbst wieder Klassen sein. Für ein Attribut kann die Multiplizität (multiplicity) definiert werden. Diese Angabe erfolgt in eckigen Klammern. Sind bei der Multiplizität die untere und obere Angabe identisch, dann reicht ein einziger Wert, d. h. [5..5] = [5]. Ist die untere Grenze gleich null und die obere Grenze unspezifiziert, dann gilt [0..*] = [*]. Die Multiplizität [1] = [1..1] bedeutet, dass das Attribut genau einen Wert besitzt. Das heißt, dass dieser Wert beim Erzeugen eines Objekts der Klasse eingetragen werden muss. Falls keine Multiplizität angegeben wird, gilt [1] als Voreinstellung. Soll ausgedrückt werden, dass es sich um ein optionales Attribut handelt, das irgendwann einmal einen Wert erhalten kann, so muss die Multiplizität [0..1] angegeben werden. Ist die Obergrenze der Multiplizität größer als 1, dann handelt es sich um ein Attribut, das aus mehreren Werten bestehen kann. Der Anfangswert (default) legt fest, welchen Wert ein neu erzeugtes Objekt für dieses Attribut annimmt. Dieser Wert kann später geändert werden. 8

9 Attribut Eigenschaftswerte (property strings) spezifizieren, ob die Attribute bestimmte Eigenschaften oder Merkmale besitzen. Sie werden in geschweiften Klammern angegeben und mehrere Eigenschaftswerte werden durch Komma getrennt. Für Attribute bietet die UML standardmäßig folgende Eigenschaftswerte: readonly: Attributwert darf nicht mehr geändert werden. z. B. kontonr {readonly} subsets: Attribut besteht aus einer Menge von Werten. Die zulässigen Attributwerte bilden eine Teilmenge eines anderen Attributs. z. B. gerade Ziffern {subsets ziffern} mit den Werten 2, 4, 6, 8 und ungerade Ziffern {subsets ziffern} mit den Werten 1, 3, 5, 7, 9 und nullziffer {subsets ziffern} mit dem Wert 0. union: Attribut besteht aus einer Menge von Werten. Es ergibt sich aus der Vereinigung aller mit subsets definierten Teilmengen. z. B. ziffern {union} ordered: Wenn ein Attribut aus mehreren Werten besteht, dann wird dadurch festgelegt, dass sie geordnet sind. Besteht das Attribut nur aus einem Element, dann hat dieser Eigenschaftswert keine Wirkung. z. B. vorname[1..3] {ordered} mit den Attributwerten: Daniela, Maria, Elke. unique: Besteht das Attribut aus einer Menge von Werten, dann dürfen keine Duplikate vorkommen. z. B. lottozahlen[6] {unique} mit den Attributwerten: 7, 11, 14, 22, 31, 35. nonunique: Besteht das Attribut aus einer Menge von Werten, dann sind Duplikate erlaubt. z. B. noten[1..5] {nonunique} mit den Attributwerten: 1.0, , 2.0, 2.3. redefines: Attribut überschreibt eine geerbte Attributdefinition. In der Abbildung erbt die Klasse Mitarbeiter das Attribut nr und redefiniert es mit dem Namen personalnr. Für Attribute können Einschränkungen (constraints) in umgangs - sprachlicher oder in maschinenlesbarer Form definiert werden. Eine Einschränkung ist eine Invariante bzw. eine Zusicherung, die immer wahr sein muss. Einschränkungen werden als Text in 9

10 UML-Notationselemente geschweiften Klammern angegeben. Sie können durch die Modellierer beliebig spezifiziert werden und sich auf ein oder mehrere Attribute beziehen. Für jedes Attribut wird im Entwurf die Sichtbarkeit (visibility) angegeben. Die UML unterscheidet folgende Arten: public: sichtbar für alle Klassen, protected: sichtbar für alle Unterklassen und innerhalb der Klasse, private: sichtbar nur innerhalb der Klasse, package: sichtbar innerhalb des Paktes. Attributtyp Der Typ von Attributen kann in der UML modelliert werden durch: Datentypen, primitive Datentypen als Sonderfall der Datentypen, Aufzählungstypen als Sonderfall der Datentypen, Klassen. 10

11