Hugendubel.info - Die B2B Online-Buchhandlung 

Merkliste
Die Merkliste ist leer.
Bitte warten - die Druckansicht der Seite wird vorbereitet.
Der Druckdialog öffnet sich, sobald die Seite vollständig geladen wurde.
Sollte die Druckvorschau unvollständig sein, bitte schliessen und "Erneut drucken" wählen.
E-BookEPUB0 - No protectionE-Book
452 Seiten
Deutsch
Rheinwerk Verlag GmbHerschienen am30.09.20217. Auflage
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.mehr
Verfügbare Formate
BuchGebunden
EUR34,90
E-BookEPUB0 - No protectionE-Book
EUR34,90

Produkt

KlappentextVon 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.
Details
Weitere ISBN/GTIN9783836284493
ProduktartE-Book
EinbandartE-Book
FormatEPUB
Format Hinweis0 - No protection
Erscheinungsjahr2021
Erscheinungsdatum30.09.2021
Auflage7. Auflage
ReiheRheinwerk Computing
Seiten452 Seiten
SpracheDeutsch
Dateigrösse14942 Kbytes
Artikel-Nr.5864221
Rubriken
Genre9200

Inhalt/Kritik

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 ... 445mehr
Leseprobe


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


mehr