Chris Rupp, Stefan Queins & die SOPHISTen

UML 2 glasklar - 4. Auflage

Praxiswissen für die UML-Modellierung

4. aktualisierte und erweiterte Auflage
580 Seiten

© 2012 Carl Hanser Verlag München

Print-ISBN 978-3-446-43057-0
 

Egal ob Umsteiger, Aufsteiger oder Freak, dieses Buch erklärt Ihnen von A wie Aktivitätsdiagramm bis Z wie Zustandsautomat die Elemente der mächtigsten und besten UML Version, die es je gab.

In diesem Buch lernen Sie die UML auf dem aktuellsten Stand kennen. Hier finden Sie alle Diagramme der UML ausführlich beschrieben und erfahren, wie Sie sie in Ihrem Projekt richtig anwenden.

Als UML-Neuling erhalten Sie eine schrittweise Einführung in die Basiselemente, als UML-Erfahrener können Sie die übersichtliche Darstellung der Notationsmittel der UML 2 als Nachschlagewerk nutzen.
Wer sich auf die Prüfung zum Certified Professional für Requirements Engineering – Advanced Level Requirements Modeling des IREB e. V. vorbereiten will, erfährt, welche Teile der UML für ihn relevant sind.

Egal ob Umstieg, Aufstieg oder Freak – dieses Buch erklärt Ihnen alles rund um UML - von A wie Aktivitätsdiagramm bis Z wie Zustandsautomat.

Folgende Fragen werden u.a. beantwortet:

  • Welche Diagramme gibt es in der UML?
  • Aus welchen Elementen bestehen die Diagramme?
  • Worauf sollte ich bei der Modellierung mit einem bestimmten Diagramm achten?
  • Wie kann ich die UML an meine Projektbedürfnisse anpassen?
  • Wie werden die wichtigsten Diagramme im Programmcode abgebildet?
  • Was benötige ich wirklich von der UML?
  • About

    Viele Tipps und praktische Unterstützung für den richtigen Einsatz der UML 2.4 in Projekten

    • Neu in der 4. Auflage: Ein ausführliches Kapitel zur Anwendung der UML 2.4 in der Analysephase als Vorbereitung zum CPRE Advanced Level Modeling
    • Mit einer Übersicht der wichtigsten Notationselemente der UML 2.4 zum Heraustrennen
    • Mit einem Vorwort von Chris Kobryn
  • Die Themen

    Einführung:
    Grundkonzepte und –elemente der UML
    Analyse mit der UML
    Analyse in der UML
    Die UML in der Realisierung

    Strukturdiagramme:
    Klassendiagramm
    Paketdiagramm
    Objektdiagramm
    Kompositionsstrukturdiagramm
    Komponentendiagramm
    Verteilungsdiagramm

    Verhaltensmodellierung:
    Use-Case-Diagramm
    Aktivitätsdiagramm
    Zustandsautomat
    Sequenzdiagramm
    Kommunikationsdiagramm
    Timing-Diagramm
    Interaktionsübersichtsdiagramm

    Weiterführendes:
    Tailoring
    UML 2 Profile
    SysML

  • Leseprobe

    Damit Sie sich einen Eindruck von unserem neuen Buch machen können, stellen wir Ihnen hier Kapitel 12 sowie das Inhaltsverzeichnis als Leseprobe zur Verfügung.


    Wir wünschen Ihnen viel Spaß beim Lesen.

    Kapitel 12 - Use-Case-Diagramm

  • Linknummern und Ergänzungen zu UML 2 glasklar

    Sie finden an einigen Stellen unseres Buches Angaben zu weiterführenden Informationen auf unserer Website.
    Diese Verweise sind mit Linknummern versehen worden, die es Ihnen erleichtern, Informationen über spezielle Themen auf unserer Webseite wiederzufinden.
    Über diese Seite gelangen Sie zu den Linknummernseiten der UML 2 glasklar Buch Reihe, sortiert nach Auflage, Kapiteln und Linknummer.
     

    Viel Spass beim weiteren Vertiefen Ihrer UML Kenntnisse.

    UML 2 glasklar - 4. Auflage

    Kapitel 6

    [6-1] Codebeispiele für Klassen
    [6-2] Codebeispiele für Attribute
    [6-3] Eigenschaftswerte union, subsets, redefines
             (in Arbeit)
    [6-4] für weitere Attribute siehe [6-2]
    [6-5] Codebeispiele für Operationen
    [6-6] Codebeispiele für Schnittstellen
    [6-7] Codebeispiele für Parametrisierte Klassen
    [6-8] Codebeispiele für Generalisierung
    [6-9] Assoziationen (in Arbeit)

    Kapitel 7

    [7-1] Paketierbare Elemente (in Arbeit)
    [7-2] Namensraum (in Arbeit)


    UML 2 glasklar - 3. Auflage

    Kapitel 3

    [3-1] Coverage Map der OMG

    Kapitel 6

    [6-1] Übersicht über alle Classifier (in Arbeit)
    [6-2] Codebeispiele für Klassen
    [6-3] Codebeispiele für Attribute
    [6-4] Eigenschaftswerte union, subsets, redefines
            (in Arbeit)
    [6-5] Codebeispiele für Operationen
    [6-6] Codebeispiele für Schnittstellen
    [6-7] Codebeispiele für Parametrisierte Klassen
    [6-8] Codebeispiele für Generalisierung
    [6-9] Assoziationen (in Arbeit)

    Kapitel 7

    [7-1] Paketierbare Elemente (in Arbeit)
    [7-2] Namensraum (in Arbeit)


    UML 2 glasklar - 2. Auflage


  • FAQ's rund um die UML

    In welchem Stadium befindet sich die UML 2.0-Standardisierung? Kann UML 2.0 schon eingesetzt werden?

    Die Arbeiten an UML 2.0 wurden seitens der Einreicher abgeschlossen und die Spezifikation durch die Analysis and Design Task Force der OMG per Abstimmung angenommen. Ebenso hat das OMG Architecture Board die Spezifikation verabschiedet und in den Stand einer OMG Adopted Specification erhoben.
    Mit dem Ende der aktiven Arbeiten und den beiden Abstimmungen hat die UML 2.0 daher ihren endgültigen Ausbaustand erreicht.

    In der aktuellen Finalisierungsphase wird die durch die OMG-Gremien angenommene Spezifikation durch die Finalization Task Force überarbeitet und editorielle (hierunter fallen schlichte Tipp- und Kopierfehler), sowie kleinere technische Fehler behoben. Die Finalization Task Force wird jedoch keine gravierenden Änderungen (wie die Entfernung bestehender oder Hinzunahme neuer Diagrammtypen) an der bestehenden Spezifikation vornehmen.
    Daher kann die Arbeit an UML 2.0 als abgeschlossen angesehen und die aktuelle Spezifikation durchaus für erste Projekte herangezogen werden. Dies illustrieren insbesondere auch Aktivitäten seitens der Werkzeughersteller, die bereits mit der Implementierung der UML 2.0 in ihren Produkten begonnen haben.

    Welche (bekannten) „Kinderkrankheiten“ der UML 2.0 besitzen das Aktivitäts-, das Sequenz- und das Aktivitätsdiagramm?

    Das Klassendiagramm weist inzwischen keine Kinderkrankheiten mehr auf. Da es als Basis der gesamten UML auch im Metamodell breite Verwendung findet und mit einer Historie, die bis in die 1970er Jahre zurückreicht, über eine lange Vorgeschichte verfügt, sind dessen graphische Primitive inzwischen sehr ausgereift. Einige „klassische Schwächen“ des UML-Klassendiagramms, beispielsweise im Umfeld der Semantikdefinition von Komposition und Aggregation, sind allerdings auch kaum verändert präsent.
    Die Verhaltensdiagramme hingegen verfügen über eine deutlich kürzere und gleichermaßen bewegtere Historie. Sie wurden erst relativ spät in die UML integriert und in den 1.x-er Spezifikationsversionen etwas stiefmütterlich behandelt. In der Version 2.0 wurden alle Diagrammtypen zur Darstellung dynamischen Verhaltens einer deutlichen Überarbeitung unterzogen, welche sich in spürbarem Mächtigkeitsgewinn auszahlt.
    Allerdings -- und dies bildet sicherlich die prägendste „Kinderkrankheit“ der Version 2.0 -- wurde sowohl auf die konsequente und vollständige Integration der den dynamischen Diagrammen zugrundeliegenden Bassstandards wie MSCs verzichtet, als auch innerhalb der UML keine verbindliche Semantikdefinition festgelegt.


    Welche Neuerungen bei UML 2.0 haben aus Ihrer Sicht die größte Bedeutung?
    Wo sehen Sie die wichtigsten Benefits für Entwickler?

    Der Standardisierungsprozess hat den Wünschen der Anwender an vielen Stellen Rechnung getragen. Gleichwohl präsentiert sich das Update auf 2.0 eher als leise Evolution denn als Revolution, da die an der Standardisierung Beteiligten der Versuchung, eine neue UML zu erfinden, widerstanden haben.
    In der Menge der Änderungen fallen dem Betrachter vor allem zwei Bereiche auf:
    Die Änderungen an der Basis der Sprache und im Bereich der Verhaltensmodellierung.
    Das Metamodell der UML wurde grundlegend überarbeitet, insbesondere wurden die semantische Beschreibung der Elemente präziser gefasst, sowie Redundanzen und Inkonsistenzen beseitigt. Dadurch ist die UML in der neuesten Version kompakter und in sich schlüssiger geworden. Für den Anwender erleichtert dies das Erlernen und die Anwendung der UML, da die vorhandenen Basiskonzepte in verschiedenen Diagrammen mit dem gleichen Verhalten und gleicher Bedeutung eingesetzt werden können. Daneben profitieren von diesen Änderungen in besonderem Maß natürlich auch die Toolhersteller.

    Anders als der Bereich der Diagramme zur statischen Modellierung, der vergleichsweise geringfügige Änderungen erfuhr, wurde der Bereich der dynamischen Diagramme einer umfangreichen Umstrukturierung und Erweiterung unterzogen. So wurde die Semantik und Notation des Aktivitäts- wie des Sequenzdiagramms völlig überarbeitet, zwei neue Sichten eingeführt (Timing- und Interaktionsübersichtsdiagramm) und das Kollaborationsdiagramm wurde in Kommunikationsdiagramm umgetauft. Neue Möglichkeiten der Verhaltensmodellierung, wie die Schachtelung und Vererbung von Diagrammen oder die Darstellung von verschiedenen Interaktionen in einem Diagramm, unterstützen Reengineering-Ansätze und Top-Down-Vorgehensmodelle.

    Mit dem Timing-Diagramm und verbesserten Modellierungsmöglichkeiten von zeitlichem Verhalten und Nebenläufigkeit in Interaktionen empfiehlt sich die UML auch stärker als bisher für die Modellierung in der Geschäftsprozessanalyse oder von Systemen im technischen Umfeld. Schließlich verbessern neue Kontrollstrukturen und das von den Petri-Netzen entliehene Tokenkonzept im Aktivitätsdiagramm die Möglichkeiten des Anwenders, Abläufe gezielter zu steuern. Abläufe sind nun durch geeignete Werkzeuge simulierbar und können beispielsweise auf Erreichbarkeit einzelner Kontrollflusszweige und Verklemmungsfreiheit untersucht werden können.


    Es gab die Kritik, UML 2.0 sei mit Features überfrachtet. Ist diese Kritik berechtigt?

    Auf den ersten Blick mag man angesichts von drei neuen Diagrammen (damit hat die UML jetzt derer 13) und erweiterter Mächtigkeit bei den bereits existierenden den Eindruck gewinnen, dass im Zuge der Standardisierung widerspruchslos den Bedürfnissen unterschiedlichster Anwendergruppen nachgegeben wurde. Und sicherlich enthält auch die UML 2.0 Modellierungskonstrukte, denen kaum eine breite Anwendung beschieden sein wird.

    Dafür präsentiert sich die UML 2.0 mit einer sauberen Basis, einem aufgeräumten und von Redundanzen befreiten Metamodell. Dies macht sie -- trotz aller Erweiterungen -- schlanker und vor allem verständlicher. Sicher gilt auch für die UML 2.0, dass das beste Werkzeug wenig nützt, wenn es falsch eingesetzt wird, aber auch die 1.x-Version erforderte für eine Erfolg versprechende Anwendung im Projekt ein gezieltes Tailoring.

    Wird es für Softwaredesigner und Entwickler eventuell schwieriger, sich in der neuen Version von UML zurechtzufinden? Wo erwarten Sie Umstellungs-Schwierigkeiten?

    Für den erfahrenen UML-Anwender gibt es sicherlich einen gewissen Umgewöhnungsbedarf: So hat sich die graphische Repräsentation einiger Elemente geändert (ein Zustand sieht aus wie eine frühere Aktivität) und Bezeichnungen geändert (das frühere Aktivitätsdiagramm heißt jetzt Aktivität und eine Aktivität heißt jetzt Aktion). Ob man das „alte“ Kollaborationsdiagramm nun als Kommunikationsdiagramm bezeichnet, ändert wenig an seiner Anwendung, allerdings ist es nicht mehr äquivalent zum Sequenzdiagramm, da letzteres in seiner Mächtigkeit stark erweitert wurde. Beachten sollte der Anwender außerdem, dass die UML 2.0 in weiten Bereichen nicht abwärtskompatibel zu ihren Vorgängerversionen ist.


    Ab wann erwarten Sie Tools, die UML 2 umfassend oder doch zumindest größtenteils abdecken? Wie kann sich der Entwickler bis dahin helfen?

    Natürlich können auch wir nur über den Zeitplan von Toolherstellern mutmaßen. Zur Zeit ist noch kein Tool auf dem Markt, das die UML 2.0 angemessen unterstützt. Vermutlich werden viele Toolhersteller die Neuerungen nach und nach übernehmen. In Erwartung dessen wurde die UML im neuen Standard in drei unterschiedlich komplexe Erfüllungsebenen und Erfüllungspunkte eingeteilt, welche wiederum Notationselemente auf einer Ebene zu Gruppen zusammenfassen. Dies ermöglicht den Anbietern von Modellierungstools die schrittweise, auf ihre jeweilige Zielgruppe zugeschnittene Umsetzung der neuen UML-Version.

    Was würden Sie Softwaredesignern/Entwicklern raten, die über einen Wechsel von UML 1.x zu 2.0 nachdenken? Ist ein Wechsel zu 2.0 in jedem Fall notwendig?

    Die Erweiterungen der dynamischen Diagrammtypen, wie beispielsweise das Sequenz- oder Aktivitätsdiagramm, sind für sich alleine genommen schon ein guter Grund für den Wechsel. Ein Wechsel ist vor allem dann ratsam, wenn ein wesentlicher Aspekt Ihrer Modellierungstätigkeit auf der Beschreibung des Systemverhaltens liegt und Sie diese Diagramme intensiv nutzen. Gleiches gilt für die Modellierung technischer Systeme, insbesondere wenn Sie die Kommunikation von Komponenten oder das Zeitverhalten eines Systems abbilden wollen.

    Sinnvoll ist der Umstieg auf UML 2.0 aber auch, wenn Sie häufig Datenströme oder Workflows modellieren, wie bei der Darstellung von Geschäftsprozessen. Und schließlich eröffnet Ihnen die UML 2.0 auch neue Möglichkeiten bei der Generierung von Code oder Architekturen basierend auf einem MDA-Ansatz, oder bei sich schnell ändernden, architektonischen Umfeldern wie EAI (Enterprise Application Integration).


    Gibt es Möglichkeiten, die UML eigenen Bedürfnissen anzupassen?

    Es gibt 2 grundsätzliche Mechanismen, die UML zu erweitern:
    >Metamodellveränderung (sog. heavyweight extension)
    >Profile (sog. lightweight extensions)
    Letztere ergänzen nur die UML, indem sie das Metamodell der UML unberührt lassen und nur erweitern bzw. gültige Regeln einschränken, es werden aber keine Elemente wie Klassen oder Assoziationen hinzugefügt oder weggenommen. In der UML stehen für diese Anpassungen drei Konstrukte zur Verfügung: Stereotypen, tagged values und in OCL formulierte constraints. Eine konkrete Sammlung dieser Konstrukte bezeichnet man als Profil. Der Begriff bzw. die Idee des Profils hat sich mit der UML 2.0 gegenüber den Vorgängerversionen nicht geändert. Allerdings sind Profile inzwischen eigene Metamodell-Elemente der UML, somit können Sie auch Profile modellieren. Profile sind einfach ausgedrückt, nichts anderes als Pakete, deren Elemente in erster Linie Ausprägungen der Anpassungskonstrukte sind.


    Inwieweit werden zukünftig Sequenzdiagramme zur Geschäftsprozessmodellierung an Stelle der Aktivitätsdiagramme eingesetzt werden?

    Im Gegensatz zu früheren UML-Versionen ist es ja nun möglich, mittels Sequenzdiagrammen durch die erweiterte Mächtigkeit (Modellierung von Parallelität, Wiederholungen usw.) Abläufe darzustellen.

    Aktivitätsdiagramme werden in der Geschäftsprozessmodellierung auch in den nächsten Jahren eine vorherrschende Stellung einnehmen. Insbesondere da viele Umsteiger aus anderen Notationen die prozess- oder flussorientierte Darstellung kennen und sich hier leicht zurechtfinden. Zudem wurden grobe Mängel in den UML 1.x Aktivitätsdiagrammen mit der UML 2.0 ausgeräumt (z.B. bietet UML 2.0 verbesserte Konstrukte zur Modellierung des Objektflusses an). Dies macht diese Diagrammart noch attraktiver.

    Die Vorteile der Sequenzdiagramme im Vergleich mit den Aktivitätsdiagrammen sind die Möglichkeiten zur präzisen Angabe zeitlicher Abläufe und Ereignisreihenfolgen; besonders im Zusammenhang mit Interaktionen. Deren Bedarf ist für die Geschäftsprozessmodellierung aber eher als gering einzuschätzen. Wenn es auf die reine Darstellung der Kommunikation im Rahmen der Geschäftsprozessmodellierung ankommt, ist ein Kommunikationsdiagramm vorzuziehen.

    In zukünftigen UML-Versionen, welche möglicherweise mit einer formalen Grammatik ausgestattet sein werden, dürften die Unterschiede zwischen Aktivitätsdiagrammen und Sequenzdiagrammen vermutlich eher gering sein. Der erste Schritt wurde bereits unternommen, indem die Mechanismen zur Einbindung von Objekten in Aktivitätsdiagramme verbessert wurden. Vielleicht wird es dann möglich sein, auf Knopfdruck zwischen Aktivitätsdiagrammen und Sequenzdiagrammen hin- und herzuschalten. Es ist auch bezeichnend für die UML 2.0, dass man die Diagramme immer mehr als Sicht (view) auf ein Modell betrachtet. Die Kunst wird in der Zukunft sein, die richtige Sicht (d.h. das richtige Diagramm) auszuwählen


    Was ist die genaue Semantik einer Aktion, die über mehrere ausgehende Kanten verfügt? Stimmt es, dass an jeder ausgehenden Kante ein separates Token angeboten wird. Wird daher der Kontrollfluss gemäß der Anzahl der ausgehenden Kanten aufgespalten?

    Es ist zwar richtig, dass an allen ausgehenden Kanten Tokens angeboten werden, aber hierdurch wird keine nebenläufige Verarbeitung erzeugt. Sobald ein Token von einer Folgeaktion (d.h. von einem Folgeknoten) konsumiert (angenommen) wird, stehen die anderen angebotenen Tokens nicht mehr zur Verfügung. Mit anderen Worten, egal wieviele Tokens am Ausgang einer Aktion zur Verfügung stehen, es verlässt in der Regel nur genau ein Token die Aktion.


    Warum wird im Downloaddokument zum Klassendiagrammkapitel zur Darstellung mengenwertiger Beziehungen die veraltende Java-Klasse Vector verwendet?

    Geschwindigkeitsmessungen zeigen, dass Operationen auf Vector-Objekten einerseits deutlich (je nach Rechner bis zu 180%) schneller ausgeführt werden als beispielsweise auf Ausprägungen von LinkedList, zum anderen besitzt Vector einen deutlich höheren Bekanntheitsgrad als die erst in Java 1.4 eingeführten Nachfolger.
    Konzeptionell unterscheidet sich jedoch die gewählte Implementierung nicht von ihren Nachfolgern, daher kann Vector ohne Mächtigkeitsverlust gegen eine andere Klasse der Collection-API ausgetauscht werden.


    Falls ein Synchronisationsknoten mit einer OR join-Spezifikation versehen ist (siehe Buch S. 237 unten), werden dann ankommende Tokens trotzdem verschmolzen?

    Leider beantwortet die UML-Spezifikation diesen Sachverhalt nicht hinreichend, da im Standard nur der „Normalfall“ also das Synchronisieren mit der Tokenverschmelzung erläutert ist. In unserem Beispiel aus Abbildung 10.74 sind wir eigentlich von einem XOR ausgegangen, d. h. dass nie gleichzeitig die Stadt mit dem Auto oder dem Zug besucht wird.

    Würden jedoch 2 Tokens vorliegen, d. h. 1 Token in der Aktion Zug fahren und 1 Token in Auto fahren, so dürften die beiden Tokens nicht verschmolzen werden. Ansonsten wäre die Äquivalenz zum Verbindungsknoten im rechten Teil der Abbildung nicht gegeben.

    Kann man mit Profilen auch Änderungen am Metamodell durchführen?

    Nein. Im allerersten Dokument zu Profilen war dies noch vorgesehen. Davon hat man sich mittlerweile aber verabschiedet. Dummerweise sind in den offiziellen Profildokumenten aber immer Metamodelländerungen aufgeführt, diese befinden sich aber in extra Dokumentabschnitten und gehören streng genommen nicht zu dem Profil an sich.


    Warum gehören eigentlich Use-Cases zu den Verhaltensdiagrammen? Ein Use-Case-Diagramm stellt doch eher ein Struktur- als ein Verhaltensdiagramm dar.

    Im Rahmen der UML 2 wurde der Fokus bei den Use-Case-Diagrammen leicht verschoben. Man sieht nun nicht mehr das Use-Case-Diagramm -- also die Statik -- im Vordergrund, sondern stattdessen den einzelnen Use-Case bzw. seine Beschreibung und die dahinterstehenden Abläufe (obwohl diese nicht mit dem Use-Case-Diagramm ausgedrückt werden, sondern vielmehr durch Aktivitätsdiagramme, Zustandsautomaten und meist durch Text).

    Im Metamodell der UML äußerst sich diese Zwitterstellung durch eine Mehrfachvererbung: Ein Use-Case ist dort sowohl ein Classifier (ähnlich wie eine Klasse, also eine statische Schnittstelle) als auch ein Behaviour (ein Verhalten, ähnlich wie eine Aktion). Prinzipiell steht aber die letzte Sichtweise bei den UML-Autoren im Vordergrund und genau deswegen die Verschiebung zu den Verhaltensdiagrammen.

    Das Use-Case-Diagramm an sich zeigt aber „nur“ statisch die angebotenen Dienstleistungen. Wobei deutlich herausgestellt wurde, dass ein Use-Case einem beliebigen Classifier zugeordnet werden kann, z.B. auch einer Komponente. Damit modellieren Sie eben das angebotene „Dienstleistungsspektrum“ einer Komponente.

  • Errata

    4. Auflage

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

    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 <> Cocktail anstatt <> 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

    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.

Entdecken Sie die große Auswahl unserer Trainings

Unsere liebe SOPHIST Ente hat viele Freunde gefunden

Panel Diskussion - Das Expertenteam

AUS UNSEREM SOPHIST BLOG

Letzter Praxisvortrag für die SOPHIST DAYS 2018 steht!

In zwei Wochen ist es soweit – die SOPHIST DAYS 2018 finden statt. Mit dabei sind jetzt auch Matthias Strößner von der Robert Bosch Automotive Steering GmbH und Christian Bock von den SOPHISTen. Mit Ihrem Praxisvortrag SysEng 2.0 – Das …

„Videos im RE“ oder auch „Männer die auf Specs starren“

Stellen Sie sich vor, Sie teilen Ihre Systemanforderungen mit den Stakeholdern – alle Teilnehmer verstehen, nicken und Sie können zufrieden, ruhigen Gewissens nach Hause gehen. Der Klassiker unter den Träumen eines Requirements-Engineer. Der Grund dafür, dass dies manchmal fern der …

Alter Wein in neuen Schläuchen

Tut mir leid, es geht hier nur am Rande um Wein. Aber um ein ALTbekanntes Problem. Wie bekomme ich das Wissen, das in meinen Anforderungen dokumentiert ist, in die Köpfe der Weiterbearbeiter? Dieser Frage sind ein paar SOPHISTen nachgegangen und …

GI-Fachruppentreffen – „RE im Wandel der Gesellschaft“

Das diesjährige Treffen der Fachgruppe Requirements Engineering der Gesellschaft für Informatik (GI)  findet wie jedes Jahr in der letzten Novemberwoche statt. Heuer haben die SOPHISTen die Ehre, die Gastgeber für das Treffen am 29. – 30.11.2018 zum Thema „RE im …

Ein Crowdsourcing-Prozess – Die Durchführungsphase

Was Sie bei der Planung Ihres Crowdsourcings bedenken sollten, haben wir Ihnen bereits in unserem letzten Beitrag „Ein Crowdsourcing-Prozess: Die Planungsphase“ erläutert. Nun sehen wir uns das Kernstück des Prozesses an – die Durchführungsphase. Crowdsourcing vorbereiten Richtlinien ausarbeiten Erarbeiten Sie …

Copyright 2018

SOPHIST GmbH

Sie benötigen weitere Informationen?

Rufen Sie uns an und lassen Sie sich direkt an den richtigen Ansprechpartner durchstellen?

Tel:      +49 (0)9 11 40 90 00

E-Mail: heureka[at]sophist[dot]de

Unsere Bürozeiten sind:        Montag bis Donnerstag:                         Freitag:
                                              08:00 - 12:00 Uhr                                    08:00 - 12:00 Uhr
                                              13:00 - 18:00 Uhr                                    13:00 - 17:00 Uhr



Natürlich können sie auch gerne direkt per E-Mail diverse Abteilungen erreichen:

Rund um das Thema Trainings:

training[at]sophist[dot]de

 



Rund um das Thema Projekt- und Beratungstätigkeiten

vertrieb[at]sophist[dot]de

 



Rund um unsere Stellenangebote und Ihren Karrierechancen bei SOPHIST

DeineZukunft[at]sophist[dot]de


 

Zu Events und Marketing sowie unseren Publikationen

messe[at]sophist[dot]de

 

SOPHIST GmbH

Allgemein:

Internes Team

heureka@sophist.de
+49 (0)9 11 40 90 00

 

Bei Fragen und Anregungen zu unseren Trainings und zu Projekt- und Beratungstätigkeiten wenden Sie sich bitte an:

Trainingsadministration und Vertrieb

training[at]sophist[dot]de

vertrieb@sophist.de
+49 (0)9 11 40 90 00

 

 

Bei Fragen und Anregungen zu unseren Stellenangeboten und Ihren Karrierechancen bei SOPHIST sowie zu Events und Marketing wenden Sie sich bitte an:

HR und Marketing

DeineZukunft@sophist.de

messe@sophist.de
+49 (0)9 11 40 90 00