Kecher / Hoffmann-Elbern / Will UML 2.5

Das umfassende Handbuch
7. Auflage 2021
ISBN: 978-3-8362-8449-3
Verlag: Rheinwerk
Format: EPUB
Kopierschutz: 0 - No protection

E-Book, Deutsch, 452 Seiten

Reihe: Rheinwerk Computing

Von den Grundlagen bis zum professionellen Einsatz - in unserem Handbuch erfahren Sie alles, was Sie für erfolgreiche Softwaremodellierung mit der UML wissen müssen. Lernen Sie alle Konzepte, Elemente und Diagrammtypen ausführlich kennen und knüpfen Sie anhand von Praxisbeispielen die Verbindung zum Code. Ob Sie etwas nachschlagen oder die UML von Grund auf verstehen möchten, dieses Handbuch bietet Ihnen das gesammelte UML-Wissen im Komplettpaket. Es behandelt den aktuellen Standard UML 2.5 und die Codebeispiele sind in den beiden wichtigsten Sprachen Java und C# verfasst.

Aus dem Inhalt:

• Grundlagen der Softwaremodellierung mit der UML 2.5
• Alle Diagrammtypen und Notationselemente
• UML in Projekten einsetzen
• Implementierungen mit Java oder C#
• Liste mit den häufigsten Fehlern und Verbesserungsvorschlägen zu jedem Diagrammtyp
• DIN-A2-Poster mit allen Diagrammtypen
• Zum Download auf der Verlagswebsite: Diagramme und Code der gezeigten Beispiele, Übersicht zu UML-Tools und Poster als PDF-Datei

Christoph Kecher ist Chief Information Officer (CIO) bei der HSBC Deutschland. Seine Tätigkeitsbereiche umfassen Data-Warehouse-Technologien, Java, .NET, UML und Software-Qualitätssicherung.

Autoren/Hrsg.

Kecher, Christoph

Hoffmann-Elbern, Ralf

Will, Torsten T.

Inhaltsverzeichnis

Materialien zum Buch ... 13  Vorwort ... 15  1.  Einführung ... 19  1.1 ... Weshalb muss Software modelliert werden? ... 19  1.2 ... Die Phasen bei der Softwareentwicklung ... 20  1.3 ... Was ist die UML? ... 22  1.4 ... Die Geschichte der UML ... 23  1.5 ... Von der UML 1.x zur UML 2.5 ... 24  1.6 ... Diagramme der UML 2.5 ... 26  1.7 ... Realisierung in Java und C# ... 33

TEIL I.  Strukturdiagramme ... 35  2.  Klassendiagramm ... 37  2.1 ... Anwendungsbereiche ... 37  2.2 ... Übersicht ... 38  2.3 ... Notationselemente ... 39  2.4 ... Lesen eines Klassendiagramms ... 111  2.5 ... Irrungen und Wirrungen ... 114  2.6 ... Zusammenfassung ... 116  3.  Objektdiagramm ... 121  3.1 ... Anwendungsbereiche ... 121  3.2 ... Übersicht ... 121  3.3 ... Notationselemente ... 122  3.4 ... Lesen eines Objektdiagramms ... 130  3.5 ... Irrungen und Wirrungen ... 131  3.6 ... Zusammenfassung ... 133  4.  Kompositionsstrukturdiagramm ... 135  4.1 ... Anwendungsbereiche ... 135  4.2 ... Übersicht ... 135  4.3 ... Notationselemente ... 136  4.4 ... Lesen eines Kompositionsstrukturdiagramms ... 151  4.5 ... Irrungen und Wirrungen ... 152  4.6 ... Zusammenfassung ... 153  5.  Komponentendiagramm ... 155  5.1 ... Anwendungsbereiche ... 155  5.2 ... Überblick ... 155  5.3 ... Notationselemente ... 156  5.4 ... Lesen eines Komponentendiagramms ... 166  5.5 ... Irrungen und Wirrungen ... 167  5.6 ... Zusammenfassung ... 169  6.  Verteilungsdiagramm ... 171  6.1 ... Anwendungsbereiche ... 171  6.2 ... Übersicht ... 171  6.3 ... Notationselemente ... 172  6.4 ... Lesen eines Verteilungsdiagramms ... 178  6.5 ... Irrungen und Wirrungen ... 179  6.6 ... Zusammenfassung ... 181  7.  Paketdiagramm ... 183  7.1 ... Anwendungsbereiche ... 183  7.2 ... Übersicht ... 183  7.3 ... Notationselemente ... 184  7.4 ... Lesen eines Paketdiagramms ... 201  7.5 ... Irrungen und Wirrungen ... 203  7.6 ... Zusammenfassung ... 204

TEIL II.  Verhaltensdiagramme ... 207  8.  Anwendungsfalldiagramm ... 209  8.1 ... Anwendungsbereiche ... 209  8.2 ... Übersicht ... 210  8.3 ... Notationselemente ... 210  8.4 ... Lesen eines Anwendungsfalldiagramms ... 219  8.5 ... Irrungen und Wirrungen ... 221  8.6 ... Zusammenfassung ... 222  9.  Aktivitätsdiagramm ... 225  9.1 ... Anwendungsbereiche ... 225  9.2 ... Übersicht ... 226  9.3 ... Notationselemente ... 228  9.4 ... Lesen eines Aktivitätsdiagramms ... 295  9.5 ... Irrungen und Wirrungen ... 297  9.6 ... Zusammenfassung ... 299

10.  Zustandsdiagramm ... 303  10.1 ... Anwendungsbereiche ... 303  10.2 ... Übersicht ... 304  10.3 ... Notationselemente ... 305  10.4 ... Lesen eines Zustandsdiagramms ... 341  10.5 ... Irrungen und Wirrungen ... 343  10.6 ... Zusammenfassung ... 345

TEIL III.  Interaktionsdiagramme ... 349

11.  Sequenzdiagramm ... 351  11.1 ... Anwendungsbereiche ... 351  11.2 ... Übersicht ... 352  11.3 ... Notationselemente ... 353  11.4 ... Lesen eines Sequenzdiagramms ... 384  11.5 ... Irrungen und Wirrungen ... 386  11.6 ... Zusammenfassung ... 388

12.  Kommunikationsdiagramm ... 393  12.1 ... Anwendungsbereiche ... 393  12.2 ... Übersicht ... 393  12.3 ... Notationselemente ... 394  12.4 ... Lesen eines Kommunikationsdiagramms ... 399  12.5 ... Irrungen und Wirrungen ... 400  12.6 ... Zusammenfassung ... 401

13.  Timing-Diagramm ... 403  13.1 ... Anwendungsbereiche ... 403  13.2 ... Übersicht ... 403  13.3 ... Notationselemente ... 404  13.4 ... Lesen eines Timing-Diagramms ... 412  13.5 ... Irrungen und Wirrungen ... 413  13.6 ... Zusammenfassung ... 415

14.  Interaktionsübersichtsdiagramm ... 417  14.1 ... Anwendungsbereiche ... 417  14.2 ... Übersicht ... 417  14.3 ... Notationselemente ... 419  14.4 ... Lesen eines Interaktionsübersichtsdiagramms ... 421  14.5 ... Irrungen und Wirrungen ... 423  14.6 ... Zusammenfassung ... 424

TEIL IV.  Metamodellierung ... 427

15.  Profildiagramm ... 429  15.1 ... Anwendungsbereiche ... 429  15.2 ... Übersicht ... 430  15.3 ... Notationselemente ... 431  15.4 ... Lesen eines Profildiagramms ... 439  15.5 ... Irrungen und Wirrungen ... 441  15.6 ... Zusammenfassung ... 442  Index ... 445

Leseproben

2.3    Notationselemente

2.3.1    Klasse

Beschreibung

Eine Klasse (engl. Class) beschreibt eine Art Bauplan für Objekte mit der gleichen Struktur (Attribute) und dem gleichen Verhalten (Operationen).

Obwohl sich dieses Kapitel mit Klassen und Klassendiagrammen befasst und die Objekte und Objektdiagramme in Kapitel 3 behandelt werden, soll der Unterschied zwischen einer Klasse und einem Objekt bereits an dieser Stelle verdeutlicht werden:

Beschreibung: Instanzen

Als Instanzen oder Ausprägungen einer Klasse werden die nach ihrem Bauplan erstellten Objekte bezeichnet. Die Erstellung eines Objekts nach dem Bauplan einer Klasse nennt man Instanziierung.

Noch deutlicher wird es mit einem Beispiel aus der realen Welt. Beispielsweise stellt ein vom Architekten erstellter Bauplan die Klasse eines Gebäudes dar. Die tatsächlich nach diesem Bauplan erbauten Gebäude werden dagegen als Objekte der Klasse bezeichnet.

Das Einfamilienhaus der Familie Müller und das Einfamilienhaus der Familie Schmidt sind Objekte, die aus dem gleichen Bauplan erstellt sein können. In der Objektorientierung spricht man davon, dass die Objekte des gleichen Typs bzw. aus der gleichen Klasse erzeugt sind.

Bei einer Software für ein Restaurant wäre der Bauplan für ein Einfamilienhaus kaum dienlich. Dort bräuchte man eher Klassen wie beispielsweise Restaurant, Tisch, Stuhl, Kellner, Koch, Bestellung, Vorspeise, Hauptgericht, Dessert oder Menü. Und auch ein Gast könnte als Klasse nützlich sein.

Das Notationselement für eine Klasse besteht im einfachsten Fall aus einem rechteckigen Kasten und dem Namen der Klasse.

Abbildung 2.2     Die einfachste Darstellung einer Klasse

Lediglich der Klassenname muss angegeben werden und innerhalb eines Namensraums eindeutig sein (Details zu Namensräumen finden Sie in Kapitel 7, »Paketdiagramm«). Die UML definiert keine Einschränkungen bezüglich der Namensgebung. Gewisse Sonderzeichen sind allerdings in manchen Programmiersprachen als Klassennamen nicht zugelassen. Es empfiehlt sich, Klassennamen mit einem Großbuchstaben zu beginnen und den Rest des Namens auf Buchstaben (keine Umlaute) und Zahlen zu beschränken.

Realisierung in Java und C#

Die Deklaration einer Klasse erfolgt sowohl in Java als auch in C# mit dem Schlüsselwort class:

class Gast
{
}

Listing 2.1     /beispiele/java/kap2/kap_2_3_1/Gast.java und /beispiele/c#/kap2/kap_2_3_1/Gast.cs (Download der Beispiele: www.rheinwerk-verlag.de/5335)

Selbstverständlich handelt es sich bei der obigen Klasse Gast um ein sehr triviales Exemplar eines Datentyps. Normalerweise zeichnen sich Klassen vor allem durch ihre Eigenschaften aus. Der Fachbegriff lautet Attribute. Genauso wichtig sind die Funktionen, die sie durchführen können. Auch hierbei verwendet die UML-Spezifikation einen speziellen Fachbegriff, nämlich Operationen.

Um auch die Attribute und die Operationen anzuzeigen, wird das Notationselement einer Klasse um zwei weitere Abschnitte erweitert: eines für die Attribute und eines für die Operationen. Auf diese beiden Abschnitte gehen wir in den nun folgenden Unterkapiteln ein.

2.3.2    Attribut

Abbildung 2.3     Attribute einer Klasse

Beschreibung

Attribute (engl. Attributes) stellen strukturelle Eigenschaften einer Klasse dar.

Man unterscheidet zwei Arten von Attributen:

• Instanzattribute definieren den Zustand von aus dieser Klasse gebildeten Objekten zur Laufzeit. Für jedes Objekt wird das jeweilige Attribut bei der Instanziierung separat erzeugt.

• Klassenattribute sind für alle Objekte der Klasse nur genau einmal und unabhängig von der Instanziierung von Objekten vorhanden. Sie werden im Unterschied zu Instanzattributen unterstrichen dargestellt.

Attribute können die folgenden Bestandteile enthalten (eckige Klammern bedeuten »optional«):

[Sichtbarkeit] [/] Name [:Typ] [Multiplizität] [=Vorgabewert] [{Eigenschaft}]

• Sichtbarkeit
  Die Sichtbarkeit definiert, welche externen Klassen auf das jeweilige Attribut lesend und schreibend zugreifen können. Sie wird durch eines der folgenden Symbole dargestellt:

  • +
    public (öffentlich): Ein öffentliches Attribut ist für alle Klassen sichtbar.

  • #
    protected (geschützt): Geschützte Attribute sind nur für Klassen sichtbar, die sich in der Vererbungshierarchie unterhalb der besitzenden Klasse befinden. Details über Vererbung finden Sie in Abschnitt 2.3.12.

  • -
    private (privat): Private Attribute sind nur in der Klasse selbst sichtbar.

  • ~
    package (Paket): Das Attribut ist nur für Klassen sichtbar, die sich in demselben Paket befinden wie die besitzende Klasse. Paketdiagramme werden in Kapitel 7 behandelt.

  Obwohl die Angabe der Sichtbarkeit optional ist, definiert die UML keinen Vorgabewert und überlässt dies den Programmiersprachen. Java und C# definieren beispielsweise die Sichtbarkeit package als Default.

• /
  Der Schrägstrich spezifiziert, dass das Attribut aus anderen Werten berechnet (abgeleitet) werden kann. Es braucht somit nicht separat gespeichert zu werden. Beispielsweise braucht das Attribut freundeEinladen nicht gespeichert zu werden, denn dies soll vom geldbetrag abhängen (geldbetrag > MIN).

• Name
  Der Name ist der einzige nicht optionale Bestandteil einer Attributspezifikation. UML definiert keine Einschränkungen für Namen, sodass prinzipiell alle verfügbaren Buchstaben und Sonderzeichen verwendet werden können. Aufgrund der Beschränkungen der meisten Programmiersprachen empfiehlt es sich jedoch, die Namen mit einem Kleinbuchstaben zu beginnen (keine Umlaute) und auf jegliche Sonderzeichen außer dem Unterstrich (_) zu verzichten (Zahlen sind akzeptabel).
  Üblicherweise verwendet man für Attributnamen Substantive wie status, geld, groesse, alter usw.

• :Typ
  Will man den Typ des Attributs definieren, muss dem Namen ein Doppelpunkt folgen. Jeder Datentyp kann als Typ verwendet werden, z. B. boolean, char, int, String, Gericht, Menuepunkt oder Gast.

• Multiplizität
  Die Anzahl der Elemente einer Datenreihe wird mit der Multiplizität spezifiziert. Sie wird in eckigen Klammern dargestellt, ähnlich der Definition von Arrays in den meisten Programmiersprachen.

  Die Angabe besteht aus den Bestandteilen [UntereGrenze..ObereGrenze]. Die untere Grenze definiert die minimale Anzahl der Elemente. Die obere Grenze spezifiziert dementsprechend die maximale Anzahl. Verzichtet man auf die Angabe der unteren oder oberen Grenze, definiert man eine genaue Anzahl der Elemente. Ein paar Beispiele sollten die Verwendung der Multiplizität verdeutlichen:

  • [1]
    Es darf nur genau ein Element dieses Attributs zur Laufzeit existieren. Dies ist der Standardwert, falls man auf die Angabe der Multiplizität verzichtet.

  • [1..2]
    Nur ein oder zwei Elemente sind erlaubt.

  • [1..*]
    Mindestens ein Element (ohne Obergrenze) ist gefordert.

  • [0..*] oder [*]
    Beliebig viele Elemente sind erlaubt.

• =Vorgabewert
  Der...

Über Autor(innen)

Hoffmann-Elbern, Ralf
Ralf Hoffmann-Elbern ist seit vielen Jahren als C#-Entwickler tätig. In seinem Programmieralltag spielt UML eine wichtige Rolle bei der Planung seiner Projekte.

Will, Torsten T.
Torsten T. Will, Jahrgang 1970, beschäftigte sich bereits während seines Diploms in Informatik mit Programmiersprachen und ihren Konzepten. C++ hat ihn schon in seinen Anfängen fasziniert und begleitet. Andere Programmierprojekte bewältigte er vor allem in Pascal, Java, Scala und Python. Seit 2004 schreibt er im Fachmagazin c't gelegentlich über C++ und Python. Was dann noch an Zeit übrig bleibt, geht in die Fotografie.

Kecher, Christoph
Christoph Kecher ist Chief Information Officer (CIO) bei der HSBC Deutschland. Seine Tätigkeitsbereiche umfassen Data-Warehouse-Technologien, Java, .NET, UML und Software-Qualitätssicherung.