SOPHIST > UML 2 glasklar > Errata
Errata UML2 glasklar

Errata

Sie haben einen Fehler im Buch gefunden und möchten ihn melden? Schreiben Sie bitte eine E-Mail an buch@remove-this.uml-glasklar.com. Wir freuen uns sehr über Ihr Engagement!

 

4. Auflage

 

Seite XIX: Die Firma SOPHIST Technologies existiert nicht mehr und somit kann Chris Rupp auch nicht Geschäftsführerin dieser Firma sein ;-)

4. Auflage



TEXT

Seite XIX: Die Firma SOPHIST Technologies existiert nicht mehr und somit kann Chris Rupp auch nicht Geschäftsführerin dieser Firma sein ;-)


Programm

Speaker

Vorträge

Anmeldung

Sonstiges

 

3. Auflage

Seite 2: letzter Absatz:"Ich fühle mich jedoch durch Bücher wie dieses ermutigt, das die UML 2 ...." und nicht wie im Buch ",dass ..."

Seite 3: Im ersten Satz muss es heißen " ... liegt in Ihren Händen."

Seite 40: Abschnitt Notation: hier muss es in der letzten Zeile " ... und steht in geschweiften Klammern."

Seite 42: Abbildung 4.17: die untere Operation muss subtrahieren und nicht substrahieren heißen.

Seite 61: Abbildung 5.3: Die extend-Beziehung zwischen Rampe anfordern und Tür öffnen muss umgekehrt gezeichnet werden, da Rampe anfordern durch Tür öffnen erweitert wird.

Seite 63: Im letzten Abschnitt gab es ein kleines Durcheinander bei der Beschreibung der Verfeinerung. Richtigerweise wird der Use Case Türen schließen durch ein Aktivitätsdiagramm verfeinert. In diesem Aktivitätsdiagramm gibt es die Aktivität Tür schließen, welche wiederum durch ein Aktivitätsdiagrammm verfeinert.

Seite 135: In der Beschreibung der Abbildung 6.31 muss es in der ersten Zeile ".... mit den Subtypen Textverarbeitung und Antivirensoftware." heißen.

Seite 159: Abbildungsunterschrift zu Abbildung 6.73: Die richtige Abbildungsunterschrift lautet "Substituierung einer ganzen Zahl". Substituierung eines Drinks ist an dieser Stelle natürlich Unsinn

Seite 250: Leider ist hier ein alter Fehler nicht komplett ausgemerzt worden. Der Akteur ist ein spezieller Classifier und nicht eine spezielle Klasse. Da Attribute und Operationen aber bei der Klasse definiert werden, ist die Klassennotation des Akteurs nicht eine alternative Darstellungsform. Allerdings ist eine Klasse auch ein Classifier. Demnach kann man in einem Use-Case Diagramm auch Klassen als Akteure haben.

Seite 356: Explicit Entry: Hier heißt es, dass "Vor dessen Eintrittsverhalten wird das Austrittsverhalten des zusammengesetzten Zustands ausgeführt,...". Es muss korrekterweise "Vor dessen Eintrittsverhalten wird das Eintrittsverhalten des zusammengesetzten Zustands ausgeführt, ..."

 

2. Auflage

Seite 41: Im Abschnitt Notation muss es heißen:" ... und steht in geschweiften Klammern."

Seite 58: Mitte: Bei der Erklärung des Begriffs MOF heißt es: Das UML 2-Metamodell (M1-Schicht) ist MOF konform, ...". Natürlich handelt es sich beim Metamodell um die M2-Schicht und nicht um die M1-Schicht.

Seite 90: 1. Zeile: Die Übersetzung für ein Verhaltensmerkmal muss BehavioralFeature und nicht BehavioralClassifier lauten

Seite 113: 1. Satz unter Operationsdeklaration. Es muss "Eine Operation muss gemäß ..." heißen

Seite 116: Abbildung 6.15 Bei der Operation ~op4... wurde die schließende Klammer vergessen. Richten lautet die Operation ~op4(out param3:String[1..*]{ordered}):KlasseB

Seite 124: Abbildung 6.24 Korrekterweise muss es Templatebindung statt Parameterbindung und Parameterbindung statt Parameterverwendung heißen.

Seite 124: 2. Absatz: 2. Satz: Richtig muss der Satz lauten: Zur Verwendung als Telefonbuch wird der Parameter an den Typ Adresse gebunden, zur Nutzung als Gästebuch erfolgt die Bindung an Gast."

Seite 144: Bei den Modellierungskonventionen für Navigationsrichtungen sind die Punkte b) und c) identisch und somit ein Punkt zuviel.

Seite 152: Abbildung 6.65 Das Supplier Element ist natürlich das (unabhängige Element).

Seite 172: Im letzten Absatz haben wir das Wörtchen "können" vergessen. Der erste Satz lautet dann richtigerweise: "Als alternative Darstellung können Sie einen Import ..."

Seite 178: 5. Absatz: Der Satz muss lauten "Sie benötigen daher nicht das vollständige Wissen der unten stehenden Kapitel, sondern Sie können sich auf die in den Metamodellabschnitten gezeigten Klassen beschränken"

Seite 223: Bei der Aufzählung der Stereotypen in einem Komponentendiagramm hat sich im ersten Punkt ein kleiner Fehler eingeschlichen. Dort heißt es: "Eine Komponente kann dabei mehr als ein Artefakt gleichzeitig manifestieren". Richtig muss es lauten: "Eine Komponente kann dabei durch mehr als ein Artefakt gleichzeitig manifestiert werden."

Seite 246f: Die Annahme, dass Use-Cases Attribute und Operationen haben können ist leider etwas veraltet. Die aktuell gültige Definition von Use-Cases lässt dies nicht zu. Dies betrifft Abbildungen 12.7 und 12.10 und die zugehörigen Texte.

Seite 260: Die Erläuterungen zur Abbildung 12.40 sind nicht ganz korrekt. Hier nun die korrigierte Fassung: Zum Beispiel wird Use-Case A nach dem Schritt 2 durch Use-Case B mit den Schritten 1-4 erweitert und dann nach dem Schritt 4 durch Use-Case C mit den Schritten 1-3 erweitert.

Seite 270: Im Abschnitt "Verweildauer von Tokens" wurde irrtümlicherweise die Abbildung 13.8 referenziert. Die richtige Abbildung auf die referenziert werden muss ist die Abbildung 13.6

Seite 290: Abbildung 13.52: Der untere Objektknoten muss mit <<centralBuffer>> Cocktail anstatt <<centralBuffer>> Glas beschriftet werden.

Kapitel 14: Die richtige Abkürzung für den Rahmenkopf des Zustandsautomaten lautet "stm". Das gilt für den gesammten Text des Kapitels und alle Abbildungen.

Seite 340: Abbildung 14.3: Die Beschriftung des Diagramm Rahmenkopfs muss "uc Authentifizieren" heißen. Vergleichen Sie hierzu auch Kapitel 4.1.2 "Diagramm, Diagrammtyp & Sicht"

Seite 341: Abbildung 14.4: Die Beschriftung des Diagramm Rahmenkopfs muss "class PKW" heißen. Vergleichen Sie hierzu auch Kapitel 4.1.2 "Diagramm, Diagrammtyp & Sicht"

Seite 360: Abs. 4, letzte Zeile: Hier muss korrekterweise auf Abbildung 14.38 und nicht auf 14.40 verwiesen werden.

Seite 427: Abbildung 15.22 Metamodellausschnitt ist unvollständig. Eine Interaktion ist auch eine Spezialisierung von InteractionFragment, vgl Superstructure Fig. 327

Seite 427: Abbildung 15.22: Der Rollenname mit der Sichtbarkeit an der Generalisierung ist nicht korrekt und hat sich irrtümlicherweise dort eingeschlichen.

Seite 429: Abbildung 15.25: Die Beschriftung des Rahmenkopfs des Diagramms muss "class Motor" statt "sd" heißen.Vergleichen Sie hierzu auch Kapitel 4.1.2 "Diagramm, Diagrammtyp & Sicht"

 

1. Auflage (2. Nachdruck)

Seite 148: Leider hat sich bei der Beschreibung des Stereotyps manifest ein Logikdreher eingeschlichen. Korrekt muß der Satz heißen:
Eine mit dem Stereotyp manifest versehene Abhängigkeitsbeziehung verbindet ein oder mehrere Artefakte mit einer durch sie realisierten Komponente.

 

1. Auflage (1. Nachdruck)

Seite 46: In der Tabelle mit den gültigen Attributspezifikationen sollte der erste Eintrag public zähler int lauten.

Seite 51: Die letzten beiden Zeilen des C++-Beispiels lauten korrekt:
const string AttMix::att5("Test");
double AttMix::pi=3.1415;

Seite 65: Die Angabe des Schlüsselwortes virtual vor den Methoden einfuegen und loeschen fehlt.
Ebenso fehlt das Schlüsselwort public vor SortierteListe in der Vererbungsdeklaration.

Seite 75: Der C++-Code sollte wie folgt lauten:

#include <stdio.h>

class Person {
//Eigenschaften
public:
virtual void trinke(int c) = 0;
};
class Partyveranstalter : public Person {
public:
void trinke(int c) {
printf("Partyveranstalter trinkt\n");
}
};
class Partyteilnehmer : public Person {
public:
void trinke(int c) {
printf("Partyteilnehmer trinkt\n");
}
};
class Gastgeber : public virtual Partyteilnehmer, public virtual Partyveranstalter {
//Eigenschaften
};

int main(int argc, char** argv) {
Partyveranstalter pv;
pv.trinke(1);
Partyteilnehmer tn;
tn.trinke(2);
Gastgeber gg;
((Partyteilnehmer)gg).trinke(1);
((Partyveranstalter)gg).trinke(1);
gg.trinke(99);
}

Seite 87: Leider ist das Klassendiagramm der Abbildung 3.38 nicht korrekt wiedergegeben.
Korrekt sollte die Abbidung wie folgt dargestellt sein:

Der zugehörige Text muß daher lauten.
Qualifizierte Assoziationen werden immer dann eingesetzt, wenn durch sie die Vielfachheit einer Assoziation herabgesetzt werden kann. Beispielsweise kann jeder Gast sicherlich eine Reihe verschiedener Cocktails konsumieren; die Multiplizität ist daher 1..*. Gleichzeitig wird derselbe Getränk zumeist nur von genau einem Gast genossen.
Wird jedoch ein bestimmter Cocktail, etwa der Lieblingscocktail einer Person, herausgegriffen (vorausgesetzt sie hat nur einen solchen), so ändert sich die Multiplizität zu 1..1, da die Kombination aus konsumierender Person (identifiziert durch ihren Namen) und konsumiertem Cocktail eindeutig wird.
[...]
Das Beispiel der Abbildung 3.38 zeigt Modifikation der Assoziation Getränkekonsum zu einer qualifizierten Assoziation. Genaugenommen wird im Beispiel sogar nur die gerichtete Teilassoziation von Person zu Cocktail verändert, welche der Rolle Gast eine nichtleere Menge von Cocktails zuordnet. Soll nun diese Menge so unterteilt werden, dass durch die Assoziation nur noch genau eine Cocktailaus-prägung referenziert wird, somit kann das Attribut Name der Klasse Person zur Qualifizierung des Cocktails herangezogen werden. Unter Berücksichtung dieses qualifizierenden Merkmals, d.h. unter Kenntnis des Gastes und seines (genau einen) Lieblingscocktails kann die Assoziation Getränkekonsum nun so verändert werden, dass der Person unter Einbezug des Namens nur noch genau ein Cocktail zugeordnet ist.

Seite 147: Die Abhängigkeitsbeziehung zwischen list.java und meinKlassendiagramm hat die falsche Richtung. Da list.java von meinKlassendiagramm abhängt muß die Abhängigkeitsrichtung genau invers zur aktuellen Darstellung verlaufen.

Seite 170: Die Zustände des rechts in der Graphik III.8 spezialisierten Zustandsautomaten sind nicht erreichbar. Das ist zwar formal korrekt, aber dennoch unschön ...
Wird der linkeste schwarze Pfeil in seiner Richtung umgekehrt, so sind auch die durch die Spezialisierung hinzugefügten Zustände erreichbar.

Seite 311: Der Automat der Abbildung 11.73 ist zwar formal korrekt, weißt jedoch eine logische Unzulänglichkeit auf. Ist die Anzahl der Eingaben nach einer Fehleingabe kleiner 3, so wird mit der
IN-Eingabe -- nicht der erneuten PIN-Prüfung -- fortgefahren.

Seite 385: Es muß Im Rahmen der Interaktion Y wird eine Lebenslinie ... heißen.

 

1. Auflage

Seite 12: Statt Unified Modelling Language muß es natürlich Unified Modeling Language heißen.

Seite 36: Leider wurde die Abbildung aus Platzgründen durch einen UML-unkundigen Graphiker „komprimiert“, wodurch sich eine Reihe von Fehlern eingeschlichen haben. Korrekt muß die Abbildung wie folgt aussehen (hier gehts zur Grafik).

Seiten 49, 51ff.: Im Text wird -- im Widerspruch zu den bekannten Nachkommastellen und möglichen abweichenden gesetzlichen Regelungen -- behauptet die ersten beiden Nachkommastellen der Zahl Pi betrügen 15, was jedoch vielmehr auf einen schlichten Tippfehler (ergänzt durch einen Copy-Paste-Error) als eine bis dato unbekannte mathematische Erkenntnis zurückzuführen ist.
In Abbildung 3.12 sind die Nachkommastellen hingegen richtig wiedergegeben.

Seite 78: Die Kennzeichnung der abgleiteten Assoziation durch einen Slash, der dem Assoziationsnamen vorangestelt wird, fehlt in Abbildung 3.27.

Seite 127: In Abbildung 6.4 sind die Kardinalitäten und Rollennamen der beiden Kompositionen fälschlicherweise am Ende bei WettenDass dargestellt. Diese gehören natürlich an das Assoziationsende bei Wette bzw. bei Wettpate.

Seite 399: In Abbildung 13.9 ist die Bezeichnung der Nachricht 2.1b nicht korrekt. Richtig muß sie 1.2.2a heißen.

Seite 426: In Abbildung 15.9 ist die Beschriftung von Verzweigungsknoten und Verbindungsknoten sind vertauscht wiedergeben.

Im Index wird unter dem Eintrag Aufzählungstyp auf Seite 36 verwiesen; richtig ist aber 37.

 

Steine

 

Anforderungen