L6 - Modellierung von Systemen

Die UML ist eine grafische Modellierungssprache, die in den 1990er-Jahren entwickelt wurde, um verschiedene Aspekte eines Systems zu modellieren.

Die UML umfasst 14 verschiedene Diagrammtypen für die Modellierung verschiedener Systemaspekte.

Strukturdiagramme modellieren den Aufbau, die Elemente, Zusammensetzung und Schnittstellen von Systemen, um zu zeigen, woraus ein System besteht.

Verhaltensdiagramme werden genutzt, um darzustellen, was in einem System und an seinen Schnittstellen abläuft.

Die UML wird weltweit in der Industrie und Forschung zur Modellierung, Dokumentation, Spezifikation und Visualisierung von komplexen Softwaresystemen eingesetzt.

Die Object Management Group (OMG) veröffentlicht und pflegt die UML als Industriestandard.

Nein, die UML ist keine Programmiersprache oder ein Vorgehensmodell, sondern eine Modellierungssprache, die verschiedene Softwaretechnikkonzepte vereinheitlicht.

Ein UML-Diagramm bietet eine spezifische Sicht auf ein System oder einen Sachverhalt.

Geschäftsobjekte und deren Eigenschaften werden im Klassendiagramm der UML modelliert.

Ein Aktivitätsdiagramm in der UML modelliert interne Abläufe eines Systems.

Ein UML-Modell besteht aus einer Menge von UML-Diagrammen, wobei jedes Diagramm zu genau einem Modell gehört.

Nein, alle Informationen in einem UML-Modell sind in mindestens einem Diagramm enthalten.

Ja, Modellelemente können in mehreren Diagrammen vorkommen, ohne mehrfach im Modell enthalten zu sein.

Ein Geschäftsobjekt kann beispielsweise mit seinen Eigenschaften in einem Klassendiagramm und gleichzeitig in einem Aktivitätsdiagramm zur Modellierung eines Ablaufs dargestellt werden.

Ein UML-Diagramm ist Teil eines UML-Modells, das aus einer Menge verschiedener Diagramme besteht.

Alle Informationen in einem UML-Modell sind in mindestens einem der zugehörigen Diagramme enthalten.

Ja, Modellelemente können in verschiedenen Diagrammen auftauchen, ohne dass sie mehrfach im Modell repräsentiert werden.

Da die Diagramme zu einem Modell gehören, ist klar erkennbar, dass identische Elemente in verschiedenen Diagrammen dasselbe Objekt oder Konzept repräsentieren.

Verschiedene Diagrammtypen bieten spezifische Sichten auf ein System, was es ermöglicht, unterschiedliche Aspekte und Verhaltensweisen zu modellieren.

Die UML definiert die erlaubten Modellelemente sowie deren grafische Darstellung für jeden Diagrammtyp.

Obwohl die Bedeutung eines Begriffs in der UML festgelegt ist, kann sich die grafische Darstellung je nach Diagrammtyp unterscheiden, um verschiedene Aspekte des Systems zu betonen.

Die Trennung ermöglicht automatische Transformationen von UML-Modellen in andere Formate oder Programmcode und erlaubt projekt- oder firmenspezifische Anpassungen der UML.

Die UML legt fest, wie Elemente verbunden werden dürfen und welche Bedeutung diese Verbindungen haben, z. B. Klassen, die im Klassendiagramm über Assoziationen oder Vererbung miteinander verbunden sind.

Die UML spezifiziert, dass Klassen in einem Klassendiagramm über Assoziationen oder Vererbung miteinander verbunden sind, nicht aber direkt, um die korrekte semantische Bedeutung zu erhalten.

Ein Use-Case-Diagramm dient dazu, die wichtigsten Funktionen eines Systems sowie dessen Schnittstellen in die Umgebung zu visualisieren.

Es bietet einen Überblick über das System selbst und seine direkte Umgebung.

Es dokumentiert das Verhalten des Systems aus Sicht der Nutzer oder der über technische Schnittstellen angebundenen Umsysteme, jedoch keine Reihenfolgen, Aufrufbeziehungen oder Datenstrukturen.

Es hilft, den Systemkontext zu bestimmen und zu dokumentieren sowie die notwendigen Schnittstellen des Systems zu identifizieren.

Es verdeutlicht keine spezifischen Reihenfolgen von Aktionen, Aufrufbeziehungen oder Datenstrukturen.

Ein Anwendungsfall ist die Hauptfunktion eines Systems, die ausgeführt werden muss, um ein bestimmtes Ergebnis zu erzielen.

Die Systemgrenze definiert den Umfang des Systems und trennt es von seiner Umgebung. Alle Elemente außerhalb dieser Grenze befinden sich außerhalb des Systems.

Ein Akteur ist eine Rolle oder ein anderes System, das mit dem betrachteten System interagiert, indem es Auslöser für Anwendungsfälle ist oder für die Erreichung eines Ergebnisses benötigt wird.

Akteure befinden sich immer außerhalb der Systemgrenze.

Akteure, die mit dem System interagieren, werden direkt mit den betreffenden Anwendungsfällen (Use Cases) verbunden.

Das Use-Case-Diagramm dient der einfachen Darstellung der Systemfunktionen nach außen, der Kommunikation mit Anwendern oder dem Management sowie der Dokumentation des Systemüberblicks und der Bestimmung des Systemkontexts.

Es kann schwierig sein, die richtige Ebene zu finden, weil oft zu kleine und dadurch zu viele Anwendungsfälle dokumentiert werden.

Eine Faustregel ist: Ein Anwendungsfall beschreibt eine Aufgabe, die in mehreren Schritten erledigt wird und mit der ein Akteur ein bestimmtes Ergebnis erzielen möchte. Typischerweise meldet sich der Nutzer am System an oder begibt sich zum System.

Anwendungsfälle sollten als Aktivität beschrieben werden, die mit einem Verb benannt wird.

Die Hauptfunktion eines UML-Aktivitätsdiagramms besteht darin, detaillierte Abläufe mit Bedingungen, Schleifen und Verzweigungen zu visualisieren.

Aktivitätsdiagramme eignen sich besonders, wenn Aufgaben in ihre einzelnen Schritte zerlegt werden sollen, z. B. zur Detaillierung von Anwendungsfällen aus einem Use-Case-Diagramm.

Im Gegensatz zum Use-Case-Diagramm, in dem explizit keine Reihenfolgen oder Bedingungen modelliert werden, visualisiert das Aktivitätsdiagramm detaillierte Abläufe mit Bedingungen, Schleifen und Verzweigungen.

Die im Aktivitätsdiagramm verwendeten Notationselemente ähneln denen von Prozessmodellen wie EPK und BPMN und dienen der Darstellung von Aktivitäten, Entscheidungen, Schleifen usw.

Eine Aktion entspricht dem Aufruf oder der Durchführung eines bestimmten Verhaltens und bestimmt das Verhalten der Aktivität.

Der Kontrollfluss ist eine gerichtete Kante mit einer Pfeilspitze, die den logischen Ablauf zwischen den Aktionen einer Aktivität festlegt.

Der Startknoten legt den Startpunkt der Aktivität fest, an dem der Kontrollfluss beginnt. Er hat ansonsten keine weitere Bedeutung.

Der Endknoten markiert das Ende der Aktivität. Sobald dieser erreicht ist, wird die Aktivität beendet.

Aktivitäten sind komplexe Aktionen, die noch weiter detailliert werden können. Sie werden als Aktivität modelliert und durch ein Notationssymbol ähnlich einer Aktion mit einem zusätzlichen Symbol in Form einer Gabel dargestellt.

Normalerweise folgen Aktionen und Aktivitäten in einem Aktivitätsdiagramm einer festgelegten Reihenfolge.

Nachdem eine Aktion gestartet wurde, müssen die Nachfolger dieser Aktion warten, bis die aktuelle Aktion beendet ist.

Die Nachfolger einer Aktion können erst durchgeführt werden, wenn die aktuelle Aktion abgeschlossen wurde, es sei denn, es wurde die parallele Durchführung von Aktionen modelliert.

Die parallele Durchführung ermöglicht es, dass mehrere Aktionen gleichzeitig stattfinden, ohne auf das Ende einer vorherigen Aktion warten zu müssen.

Wenn eine Bedingung nicht erfüllt ist, wird der Ablauf an dieser Stelle gestoppt und der Kontrollfluss nicht berücksichtigt.

Ein Verzweigungsknoten spaltet eine Kante in mehrere Alternativen auf. Der Ablauf geht dann auf genau einer der ausgehenden Kanten weiter. Dies entspricht einem logischen XOR.

Ein Verbindungsknoten führt alle eingehenden Kanten zusammen. Der Ablauf setzt fort, sobald der Fluss einer Kante den Knoten erreicht. Es findet keine Synchronisation statt, es wird nicht auf die anderen eingehenden Kanten gewartet.

Ein Parallelisierungsknoten teilt die eingehende Kante in mehrere parallele Abläufe auf, entsprechend einem logischen AND. Er kann zu einem logischen OR erweitert werden, wenn die ausgehenden Kanten mit Bedingungen versehen werden.

Ein Synchronisationsknoten führt eingehende Kanten zu einem gemeinsamen Ablauf zusammen. Es wird gewartet, bis alle Flüsse an allen eingehenden Kanten ankommen.

Die Faustregel besagt, dass eine Verzweigung immer mit einer Zusammenführung und eine Parallelisierung immer mit einer Synchronisation wieder geschlossen werden sollte.

Im Requirements Engineering wird das UML-Aktivitätsdiagramm zur Verfeinerung und Detaillierung von Anwendungsfällen verwendet. Es dient zur Darstellung von Abläufen zusammen mit fachlichen Ausführungsbedingungen und kann auch erforderliche Aktionen im Fehlerfall oder in Ausnahmesituationen beschreiben.

Anstelle eines Aktivitätsdiagramms können Abläufe auch mit BPMN (Business Process Model and Notation) oder EPK (Ereignisgesteuerte Prozesskette) modelliert werden.

Das UML-Klassendiagramm wird im Requirements Engineering genutzt, um Geschäftsobjekte, ihre Eigenschaften und Beziehungen untereinander zu dokumentieren, meist in einer reduzierten Form ohne implementierungsnahe Informationen wie Sichtbarkeiten oder technische Datentypen.

In fachlichen Anforderungen liegt der Fokus auf der Dokumentation von Geschäftsobjekten und anderen fachlichen Entitäten. Daher werden oft Details wie Methoden und technische Datentypen bewusst weggelassen, um die Modellierung auf das Wesentliche zu konzentrieren.

In der objektorientierten Systementwicklung ist das UML-Klassendiagramm eine häufig genutzte Dokumentationsform, um die Struktur von Klassen, deren Attribute und Methoden sowie deren Beziehungen untereinander zu spezifizieren und zu dokumentieren.

Nein, das UML-Klassendiagramm kann auch zur Analyse und Dokumentation fachlicher Aspekte genutzt werden, ohne dass am Ende ein objektorientiertes System daraus erstellt wird.

Klassen werden in Form eines Rechtecks dargestellt, in das der Name der Klasse geschrieben wird.

Die relevanten Eigenschaften einer Klasse, auch Attribute genannt, werden als separate Rechtecke unterhalb des Klassennamens notiert.

Eine Klasse mit Attributen besteht aus zwei zusammenhängenden Rechtecken: das obere Rechteck enthält den Namen der Klasse, das untere Rechteck listet die Attribute der Klasse auf.

Zu jedem Attribut ist mindestens der Name erforderlich. Weitere Details wie Datentypen und Defaultwerte können angegeben werden, sind jedoch nicht zwingend erforderlich und können im Entwicklungsprozess ergänzt werden.

Der Beziehungstyp „hat/kennt“ drückt aus, dass eine Klasse eine andere Klasse „hat“ oder „kennt“. Es beschreibt, wie Klassen miteinander verbunden sind, z. B. ein Versicherungsnehmer hat Kinder oder ein Verkäufer kennt seine Kunden.

Der Beziehungstyp „besteht aus“ wird verwendet, um auszudrücken, dass eine Klasse ein Bestandteil einer anderen Klasse ist. Das wird genutzt, wenn eine Klasse ein größeres Konstrukt darstellt, dessen Elemente nicht einfach durch Attribute beschrieben werden können, z. B. ein Auto besteht aus einem Motor, Rädern, Türen usw.

Der Beziehungstyp „ist ein“ drückt aus, dass eine Klasse A von der Art her eine Klasse B ist, aber spezifischere Attribute und Methoden hat. Zum Beispiel ist ein Pkw ein Auto oder ein Kunde ist eine Person.

Beziehungen zwischen Klassen werden durch Linien bzw. Pfeile modelliert, die die entsprechenden Klassen verbinden. Die einfachste Form ist eine durchgezogene Linie.

Multiplizitäten geben Mengenangaben für Beziehungen an und werden an beiden Enden einer Beziehung notiert. Links von ".." steht die Untergrenze und rechts von ".." die Obergrenze der Mengenangaben.

Die Mengenangaben für Beziehungen werden an die Enden der Linien zwischen den Klassen notiert, typischerweise in Form von Zahlen oder Sternen (z. B. 0..1 oder *).

Die Multiplizitäten geben an, wie viele Instanzen einer Klasse mit einer anderen Klasse verbunden sind. Sie zeigen die Anzahl der Objekte, die in der Beziehung involviert sind, beispielsweise von einem zu vielen (1..*).

Das Klassendiagramm im Requirements Engineering dokumentiert Geschäftsobjekte, fachliche Entitäten, Personen, Objekte, Systeme und ihre relevanten Eigenschaften sowie Beziehungen und Abhängigkeiten zwischen diesen Elementen.

Das vorrangige Ziel besteht darin, das fachliche Problem zu dokumentieren, zu verstehen und zu kommunizieren. Es geht dabei um die Abbildung von Konzepten der fachlichen Umgebung, nicht um die Elemente eines spezifischen Systems.

Eine UML-Klasse repräsentiert ein fachliches Konzept, das eine Menge von Objekten mit ähnlichen Eigenschaften darstellt. Beispielsweise könnte eine Klasse "Kunde" oder "Artikel" sein.

Das Klassendiagramm wird nicht hauptsächlich genutzt, um Verhalten oder Abläufe zu modellieren oder darzustellen. Es konzentriert sich auf statische Konzepte und nicht auf dynamische Aspekte.

Ein UML-Zustandsdiagramm dokumentiert die fachlichen Zustände von Objekten oder Systemen und spezifiziert die möglichen Zustände sowie die Übergänge zwischen diesen Zuständen.

Während ein Aktivitätsdiagramm Aktionen und Abläufe modelliert, legt ein Zustandsdiagramm die Zustände fest, die ein Objekt oder System annehmen kann, sowie die Übergänge und Abhängigkeiten zwischen diesen Zuständen.

Die Hauptbestandteile eines UML-Zustandsdiagramms sind Zustände, Übergänge zwischen diesen Zuständen, Aktionen, die beim Übergang zwischen Zuständen ausgeführt werden, und Ereignisse, die Übergänge auslösen.

Zustände werden in einem Zustandsdiagramm in Rechtecken mit abgerundeten Ecken dargestellt und mit einem Namen versehen, der den Zustand beschreibt.

Übergänge sind Pfeile, die zeigen, wie das System oder Objekt von einem Zustand zum anderen übergeht. Sie werden mit Ereignissen oder Bedingungen verknüpft, die den Übergang auslösen.

Ein Zustand repräsentiert eine bestimmte fachliche Situation eines Objekts oder Systems, die fachliche Aussagen oder Aktivitäten impliziert.

Der Startzustand markiert den Beginn des Diagramms und zeigt die möglichen ersten Zustände des Objekts oder Systems an.

Der Endzustand markiert das Ende des Diagramms und zeigt die möglichen letzten Zustände des Objekts oder Systems an.

Ein Zustandsübergang bestimmt die Reihenfolge der Zustände und beschreibt, wie das System oder Objekt von einem Zustand zum nächsten übergeht.

Entscheidungen ermöglichen abhängig von einem aktuellen Ergebnis die Auswahl des nächsten Zustands, während Zusammenführungen mehrere Übergänge zu einem gemeinsamen Nachfolgezustand zusammenführen.

Trigger, Guard und Aktivität können einer Transition zugeordnet werden. Trigger sind Auslöser von Übergängen, Guards sind Bedingungen für den Übergang und Aktivitäten sind Aktionen, die beim Übergang ausgeführt werden.

Zustandsdiagramme werden genutzt, um Lebenszyklen oder fachliche Zustände von Geschäftsobjekten und Entitäten zu dokumentieren und zu modellieren.

Zustandsdiagramme fokussieren sich auf die Modellierung von Zustandsübergängen und erlauben eine kompakte Darstellung des Lebenszyklus eines Geschäftsobjekts oder fachlicher Entitäten.

Zustandsdiagramme können zeigen, welche Aktivitäten in bestimmten Zuständen erlaubt sind und ermöglichen eine kompakte Darstellung des Lebenszyklus von Geschäftsobjekten.

Zustandsdiagramme können die Aufrufreihenfolgen von Bildschirmmasken abbilden, wobei jeder Zustand einer Bildschirmmaske bzw. -seite entspricht und die Übergänge die Klickfolge des Nutzers darstellen.

Zustandsdiagramme bieten eine kompakte Darstellung des Lebenszyklus von Geschäftsobjekten, während komplexe Prozessdiagramme detailliertere Abläufe darstellen.