Das UML-Diagramm ist grafisch. UML-Diagramm. Arten von UML-Diagrammen. Hauptmenü des Programms

UML-Diagramm ist eine spezialisierte grafische Beschreibungssprache, die für die Objektmodellierung bei der Entwicklung verschiedener Software entwickelt wurde. Diese Sprache hat ein breites Profil und ist ein offener Standard, der verschiedene grafische Notationen verwendet, um ein abstraktes Modell des Systems zu erstellen. Die UML wurde entwickelt, um die Definition, Visualisierung, Dokumentation und das Design aller Arten von Softwaresystemen bereitzustellen. Es ist erwähnenswert, dass das UML-Diagramm selbst keine Programmiersprache ist, es bietet jedoch die Möglichkeit, darauf basierend einen separaten Code zu generieren.

Warum wird es benötigt?

Die UML endet nicht mit der Modellierung aller Arten von Software. Außerdem wird diese Sprache heute aktiv für die Modellierung verschiedener Geschäftsprozesse, die Durchführung von Systems Engineering sowie die Darstellung von Organisationsstrukturen verwendet.

Mit der UML können Softwareentwickler eine vollständige Konvention in den grafischen Notationen durchsetzen, die verwendet werden, um allgemeine Konzepte wie Komponente, Generalisierung, Klasse, Verhalten und Aggregation darzustellen. Dadurch wird eine stärkere Fokussierung auf Architektur und Design erreicht.

Es ist auch erwähnenswert, dass es mehrere Arten solcher Diagramme gibt.

Klassen Diagramm

Ein UML-Klassendiagramm ist ein statisches Strukturdiagramm, das entwickelt wurde, um die Struktur eines Systems zu beschreiben sowie Attribute, Methoden und Abhängigkeiten zwischen mehreren verschiedenen Klassen anzuzeigen.

Es ist erwähnenswert, dass es mehrere Standpunkte zum Aufbau solcher Diagramme gibt, je nachdem, wie sie verwendet werden:

• Konzeptionell. In diesem Fall beschreibt das UML-Klassendiagramm das Modell einer bestimmten Domäne, und es werden darin nur Klassen von angewendeten Objekten bereitgestellt.
• Spezifisch. Das Diagramm wird im Entwurfsprozess verschiedener Informationssysteme verwendet.
• Implementierung. Das Klassendiagramm umfasst alle Arten von Klassen, die direkt im Programmcode verwendet werden.

Komponentendiagramm

Ein UML-Komponentendiagramm ist ein vollständig statisches Strukturdiagramm. Es soll die Aufteilung eines bestimmten Softwaresystems in verschiedene Strukturkomponenten sowie die Verbindungen zwischen diesen demonstriert werden. Ein UML-Komponentendiagramm als solches kann alle Arten von Modellen, Bibliotheken, Dateien, Paketen, ausführbaren Dateien und vielen anderen Elementen verwenden.

Verbund-/Verbundstrukturdiagramm

Das UML Composite / Composite Structure Diagram ist ebenfalls ein statisches Strukturdiagramm, wird jedoch verwendet, um die interne Struktur von Klassen darzustellen. Wenn möglich, kann dieses Diagramm auch das Zusammenspiel von Elementen in der internen Struktur der Klasse demonstrieren.

Eine Unterform davon ist das UML-Diagramm der Kooperation, mit dem die Rollen sowie das Zusammenspiel verschiedener Klassen innerhalb der Grenzen der Kooperation demonstriert werden können. Sie sind sehr praktisch, wenn Sie Entwurfsmuster modellieren müssen.

Es ist erwähnenswert, dass UML-Klassendiagrammtypen und zusammengesetzte Strukturtypen gleichzeitig verwendet werden können.

Bereitstellungsdiagramm

Dieses Diagramm wird verwendet, um Arbeitsknoten sowie alle Arten von Artefakten zu simulieren, die auf ihnen bereitgestellt wurden. UML 2 stellt Artefakte auf verschiedenen Knoten bereit, während die erste Version ausschließlich Komponenten bereitstellt. Daher wird das UML-Bereitstellungsdiagramm hauptsächlich von der zweiten Version verwendet.

Zwischen dem Artefakt und der von ihm implementierten Komponente wird eine manifeste Abhängigkeit gebildet.

Objektdiagramm

In dieser Ansicht können Sie einen vollständigen oder teilweisen Snapshot des Systems anzeigen, das zu einem bestimmten Zeitpunkt erstellt wird. Es zeigt alle Instanzen von Klassen eines bestimmten Systems vollständig an und zeigt die aktuellen Werte ihrer Parameter sowie die Verbindungen zwischen ihnen an.

Paketdiagramm

Dieses Diagramm ist struktureller Natur und sein Hauptinhalt sind alle Arten von Paketen sowie die Beziehung zwischen ihnen. In diesem Fall gibt es keine strikte Trennung zwischen mehreren Strukturdiagrammen, weshalb ihre Verwendung meistens nur der Bequemlichkeit halber angetroffen wird und keine semantische Bedeutung hat. Es ist erwähnenswert, dass verschiedene Elemente andere UML-Diagramme bereitstellen können (Beispiele: Pakete und die Paketdiagramme selbst).

Ihre Verwendung erfolgt, um die Gruppierung mehrerer Elemente nach einem bestimmten Kriterium zu gewährleisten, die Struktur zu vereinfachen und die Arbeit mit dem Modell dieses Systems zu organisieren.

Aktivitätsdiagramm

Ein UML-Aktivitätsdiagramm zeigt die Zerlegung einer bestimmten Aktivität in mehrere Komponenten. In diesem Fall bezieht sich der Begriff "Aktivität" auf die Spezifikation eines bestimmten ausführbaren Verhaltens in Form einer parallelen, sowie koordinierten sequentiellen Ausführung verschiedener untergeordneter Elemente - verschachtelte Aktivitätstypen und verschiedene Aktionen, die durch Threads verbunden sind, die von der Ausgänge eines bestimmten Knotens auf die Eingänge eines anderen.

UML-Aktivitätsdiagramme werden häufig verwendet, um verschiedene Geschäftsprozesse, parallele und sequentielle Berechnungen zu modellieren. Sie simulieren unter anderem alle möglichen technologischen Verfahren.

Automatendiagramm

Diese Ansicht wird auch als UML-Zustandsdiagramm bezeichnet. Verfügt über eine vorgestellte Zustandsmaschine mit einfachen und zusammengesetzten Zuständen und Übergängen.

Eine Zustandsmaschine ist eine Spezifikation einer Folge verschiedener Zustände, die ein bestimmtes Objekt durchläuft, oder einer Interaktion als Reaktion auf einige Ereignisse in seinem Leben, sowie die Reaktionen des Objekts auf solche Ereignisse. Eine Zustandsmaschine, die ein UML-Statechart verwendet, wird an das Quellelement angehängt und verwendet, um das Verhalten seiner Instanzen zu definieren.

Als Analoga zu solchen Diagrammen können die sogenannten Drachenschemen verwendet werden.

Anwendungsfalldiagramme

Das UML-Use-Case-Diagramm bildet alle Beziehungen ab, die zwischen den Akteuren entstehen, sowie die verschiedenen Anwendungsfälle. Seine Hauptaufgabe besteht darin, sich als vollwertiges Mittel bereitzustellen, mit dem ein Kunde, ein Endbenutzer oder ein Entwickler gemeinsam das Verhalten und die Funktionalität eines bestimmten Systems diskutieren können.

Wenn ein UML-Anwendungsfalldiagramm bei der Modellierung eines Systems verwendet wird, wird der Analyst Folgendes tun:

• Trennen Sie das simulierte System klar von seiner Umgebung.
• Identifizieren Sie die Akteure, die Art und Weise ihrer Interaktion mit diesem System sowie die erwartete Funktionalität.
• Im Glossar werden als Themenbereich verschiedene Konzepte festgelegt, die sich auf eine detaillierte Beschreibung der Funktionsweise dieses Systems beziehen.

Wird ein Nutzungsdiagramm in UML entwickelt, beginnt die Vorgehensweise mit einer textlichen Beschreibung, die in der Zusammenarbeit mit einem Kunden eingeholt wird. Gleichzeitig ist anzumerken, dass verschiedene nicht-funktionale Anforderungen bei der Erstellung eines Modells von Anwendungsfällen vollständig entfallen und für sie bereits ein separates Dokument erstellt wird.

Kommunikation

Ein Kommunikationsdiagramm ist ebenso wie ein UML-Sequenzdiagramm transitiv, d. h. es drückt die Interaktion an sich aus, demonstriert sie aber gleichzeitig auf unterschiedliche Weise und kann bei Bedarf mit der erforderlichen Genauigkeit transformiert werden in eine andere.

Das Kommunikationsdiagramm bildet die Interaktionen ab, die zwischen den verschiedenen Elementen der Verbundstruktur auftreten, sowie die Rollen der Kooperation. Der Hauptunterschied zu einem Sequenzdiagramm besteht darin, dass es die Beziehung zwischen mehreren Elementen klar anzeigt und die Zeit nicht als separate Dimension verwendet wird.

Dieser Typ zeichnet sich durch ein völlig freies Format zur Anordnung mehrerer Objekte und Verknüpfungen ähnlich wie in einem Objektdiagramm aus. Wenn die Reihenfolge der Nachrichten in diesem freien Format beibehalten werden muss, werden sie chronologisch nummeriert. Das Lesen dieses Diagramms beginnt mit der ursprünglichen Nachricht 1.0 und wird dann in der Richtung fortgesetzt, in der Nachrichten von einem Objekt an ein anderes weitergegeben werden.

Die meisten dieser Diagramme zeigen genau die gleichen Informationen, die uns ein Sequenzdiagramm liefert. Da es jedoch eine andere Art der Informationsdarstellung verwendet, sind bestimmte Dinge in einem Diagramm viel einfacher zu identifizieren als in einem anderen. Es ist auch erwähnenswert, dass ein Kommunikationsdiagramm deutlicher zeigt, mit welchen Elementen jedes einzelne Element interagiert, während ein Sequenzdiagramm deutlicher zeigt, in welcher Reihenfolge die Interaktionen stattfinden.

Sequenzdiagramm

Ein UML-Sequenzdiagramm zeigt die Interaktionen zwischen mehreren Objekten, die nach ihrem Auftretenszeitpunkt geordnet sind. Dieses Diagramm zeigt die zeitlich geordneten Interaktionen zwischen mehreren Objekten. Es zeigt insbesondere alle an der Interaktion beteiligten Objekte sowie die komplette Abfolge der von ihnen ausgetauschten Nachrichten an.

Die Hauptelemente in diesem Fall sind die Bezeichnungen verschiedener Objekte sowie vertikale Linien, die den Zeitverlauf anzeigen, und Rechtecke, die die Aktivität eines bestimmten Objekts oder die Ausführung einer beliebigen Funktion durch dieses darstellen.

Kooperationsdiagramm

Mit dieser Art von Diagrammen können Sie Interaktionen zwischen mehreren Objekten demonstrieren, indem Sie von der Abfolge der Sendenachrichten abstrahieren. Diese Art von Diagrammen in kompakter Form zeigt absolut alle gesendeten und empfangenen Nachrichten eines bestimmten Objekts sowie die Formate dieser Nachrichten an.

Da es sich bei Sequenzdiagrammen und Kommunikationsdiagrammen lediglich um unterschiedliche Ansichten derselben Verfahren handelt, bietet Rational Rose die Möglichkeit, ein Kommunikationsdiagramm aus einem Sequenzdiagramm oder umgekehrt zu erstellen und diese vollautomatisch zu synchronisieren.

Interaktionsübersichtsdiagramme

Dies sind UML-Diagramme, die eine Untermenge von Aktivitätsdiagrammen sind, die sowohl Sequenzelemente als auch Kontrollflusskonstrukte enthalten.

Es ist erwähnenswert, dass dieses Format Kollaborations- und Sequenzdiagramme kombiniert, die eine Möglichkeit bieten, die Interaktion zwischen mehreren Objekten in dem sich bildenden System aus verschiedenen Blickwinkeln zu betrachten.

Synchronisationsdiagramm

Es ist ein alternatives Sequenzdiagramm, das die Zustandsänderung auf einer Lebenslinie mit einer bestimmten Zeitskala deutlich zeigt. Kann in verschiedenen Echtzeitanwendungen sehr nützlich sein.

Was sind die Vorteile?

Bemerkenswert sind mehrere Vorteile, die das UML-Nutzungsdiagramm und andere auszeichnen:

• Die Sprache ist objektorientiert, wodurch die Technologien zur Beschreibung der Ergebnisse der durchgeführten Analyse und des Designs Programmiermethoden in allen möglichen objektorientierten Sprachen moderner Art semantisch nahe kommen.
• Mit dieser Sprache kann das System aus nahezu allen möglichen Blickwinkeln beschrieben werden und ebenso werden verschiedene Aspekte seines Verhaltens beschrieben.
• Alle Diagramme sind relativ einfach zu lesen, auch wenn Sie sich relativ schnell mit der Syntax vertraut gemacht haben.
• UML ermöglicht sowohl die Erweiterung als auch die Einführung eigener grafischer und textueller Stereotypen, was zu ihrer Verwendung nicht nur in der Softwareentwicklung beiträgt.
• Die Sprache hat sich ziemlich verbreitet und entwickelt sich auch sehr aktiv.

Mängel

Obwohl das Erstellen von UML-Diagrammen viele Vorteile hat, werden sie häufig für die folgenden Mängel kritisiert:

• Redundanz. Kritiker sagen in den allermeisten Fällen, dass die UML zu groß und komplex ist, und dies ist oft nicht gerechtfertigt. Es enthält viele überflüssige oder praktisch nutzlose Konstruktionen und Diagramme, und am häufigsten bezieht sich diese Kritik auf die zweite Version und nicht auf die erste, da in neueren Überarbeitungen mehr Kompromisse "vom Ausschuss entwickelt" enthalten sind.
• Diverse semantische Ungenauigkeiten. Da die UML durch eine Kombination aus sich selbst, Englisch und OCL definiert wird, fehlt ihr die Steifigkeit, die Sprachen innewohnt, die durch die Technik der formalen Beschreibung genau definiert werden. In bestimmten Situationen beginnt die abstrakte Syntax von OCL, UML und Englisch, sich zu widersprechen, während sie in anderen Fällen unvollständig ist. Eine ungenaue Beschreibung der Sprache selbst betrifft sowohl Benutzer als auch Tool-Anbieter, was letztendlich aufgrund der einzigartigen Interpretation verschiedener Spezifikationen zu Inkompatibilitäten von Tools führt.
• Probleme im Prozess der Implementierung und des Studiums. Alle oben genannten Probleme führen zu gewissen Schwierigkeiten bei der Einführung und dem Erlernen der UML, und dies gilt insbesondere dann, wenn die Führung Ingenieure zwingt, sie gewaltsam einzusetzen, obwohl sie keine Vorkenntnisse haben.
• Der Code spiegelt den Code wider. Eine andere Meinung ist, dass nicht schöne und attraktive Modelle wichtig sind, sondern die funktionierenden Systeme selbst, dh der Code ist das Projekt. Entsprechend dieser Sichtweise besteht die Notwendigkeit, einen effizienteren Weg zum Schreiben von Software zu entwickeln. Die UML wird für Ansätze geschätzt, die Modelle kompilieren, um ausführbare Dateien oder Quellcode zu regenerieren. In Wirklichkeit reicht dies jedoch möglicherweise nicht aus, da der Sprache Turing-Vollständigkeitseigenschaften fehlen und jeder generierte Code letztendlich durch das begrenzt wird, was ein UML-Interpretertool annehmen oder definieren kann.
• Nichtübereinstimmung beim Laden. Dieser Begriff stammt aus der Theorie der Systemanalyse, um die Unfähigkeit des Inputs eines bestimmten Systems zu bestimmen, den Output eines anderen zu erkennen. Wie jedes Standardnotationssystem kann die UML einige Systeme effizienter und prägnanter darstellen als andere. Daher neigt der Entwickler eher zu Lösungen, die bequemer sind, um alle Stärken der UML sowie anderer Programmiersprachen zu verweben. Dieses Problem wird offensichtlicher, wenn die Entwicklungssprache nicht den Grundprinzipien der objektorientierten orthodoxen Doktrin entspricht, dh nicht versucht, nach den Prinzipien der OOP zu arbeiten.
• Versucht vielseitig zu sein. UML ist eine universelle Modellierungssprache, die versucht, mit jeder heute verfügbaren Verarbeitungssprache kompatibel zu sein. Damit das Designteam im Kontext eines bestimmten Projekts das ultimative Ziel erreichen kann, ist es notwendig, die anwendbaren Fähigkeiten dieser Sprache auszuwählen. Darüber hinaus gehen die Möglichkeiten, den Anwendungsbereich der UML in einem bestimmten Bereich einzuschränken, durch einen nicht vollständig ausformulierten, aber selbst kritikwürdigen Formalismus.

Daher ist die Verwendung dieser Sprache nicht in allen Situationen relevant.

UML oder Unified Modeling Language ist eine grafische Beschreibungssprache für die Objektmodellierung in der Softwareentwicklung. Der Einsatz von UML ist aber nicht auf die IT beschränkt, ein weiterer großer praktischer Anwendungsbereich von UML ist die Geschäftsprozessmodellierung, das Systems Engineering und die Abbildung von Organisationsstrukturen. Die UML ermöglicht es Softwareentwicklern, sich auf grafische Notationen zu einigen, um gemeinsame Konzepte darzustellen und sich auf Design und Entwicklung zu konzentrieren.

UML-Vorteile

• Die UML verwendet grafische Symbole für die Elemente des zu modellierenden Systems, und die UML-Diagramme sind einfach zu verstehen;
• Die UML ermöglicht es, Systeme aus nahezu allen erdenklichen Gesichtspunkten unter Berücksichtigung unterschiedlicher Aspekte zu beschreiben;
• UML ist objektorientiert: Ihre Analyse- und Konstruktionsmethoden sind den Programmiermethoden moderner OOP-Sprachen semantisch nahe;
• UML ist ein offener Standard. Der Standard entwickelt und entwickelt sich von Version zu Version weiter und erfüllt modernste Anforderungen an die Beschreibung von Systemen;
• enthält einen Erweiterungsmechanismus, der die Einführung zusätzlicher Text- und Grafikarten ermöglicht, was den Einsatz der UML nicht nur im IT-Bereich ermöglicht.

Arten von UML-Diagrammen

Es gibt 14 Arten von Diagrammen in UML. Sie können in 2 Kategorien unterteilt werden:

• strukturell Darstellen der Informationsstruktur;
• Verhaltensauffälligkeiten Darstellung des Verhaltens des Systems und verschiedener Aspekte von Interaktionen. Eine eigene Unterart von Verhaltensdiagrammen wird betrachtet Interaktionsdiagramme.

Hierarchie der UML-Diagrammtypen,
dargestellt durch Klassendiagramm

Strukturdiagramme

1. Klassen Diagramm ist ein Schlüsselelement in der objektorientierten Modellierung. Mit Hilfe dieses Diagramms (eigentlich durch Klassen, ihr Attribute, Methoden und Abhängigkeiten zwischen Klassen) beschreibt das Domänenmodell und die Struktur des modellierten Systems.
2. Komponentendiagramm zeigt die Aufteilung des Programmcodes in große Blöcke (Strukturkomponenten) und zeigt Abhängigkeiten zwischen ihnen. Komponenten können Pakete, Module, Bibliotheken, Dateien usw. sein.
3. Objektdiagramm zeigt einen vollständigen oder teilweisen Ausschnitt des modellierten Systems zu einem bestimmten Zeitpunkt. Es repräsentiert Klasseninstanzen (Objekte), ihren Zustand (aktuelle Attributwerte) und Beziehungen zwischen ihnen.
4. Verbundstrukturdiagramm demonstriert die interne Struktur von Klassen und, wenn möglich, die Wechselwirkungen zwischen den Elementen dieser Struktur.
5. Paketdiagramm zeigt Pakete und Beziehungen zwischen ihnen. Diese Art von Diagrammen dient dazu, die Struktur des Modells zu vereinfachen (und dementsprechend damit zu arbeiten), indem die Elemente des Modells nach bestimmten Kriterien zu Gruppen zusammengefasst werden.
6. Bereitstellungsdiagramm simuliert den Einsatz von Softwarekomponenten ( Artefakte) zu Rechenressourcen / Hardwarekomponenten ( Knoten).
7. Profildiagramm beschreibt einen Erweiterungsmechanismus, mit dem die UML auf eine Vielzahl von Domänen und Branchen zugeschnitten werden kann.

Beispiel für ein UML-Klassendiagramm

Verhaltensdiagramme

1. Aktivitätsdiagramm zeigt Aktionen ( Aktionen) von denen einige Aktivitäten ( Aktivität). Aktivitätsdiagramme werden verwendet, um Geschäftsprozesse, Arbeitsabläufe, sequentielle und parallele Berechnungen zu modellieren.
2. Anwendungsfalldiagramm(oder Anwendungsfalldiagramm) beschreibt die Beziehung zwischen den Akteuren (Charakteren) und den Anwendungsfällen des modellierten Systems (seine Fähigkeiten). Der Hauptzweck eines Diagramms besteht darin, eine zentrale Anlaufstelle für Kunden, Entwickler und Endbenutzer zu sein, um gemeinsam über ein System – seine Fähigkeiten und sein Verhalten – zu diskutieren.
3. Zustandsdiagramm stellt das dynamische Verhalten einer Entität dar und zeigt, wie diese Entität in Abhängigkeit von ihrem aktuellen Zustand auf verschiedene Ereignisse reagiert. Dies ist im Wesentlichen ein Zustandsdiagramm aus der Atomtheorie.
4. Kommunikationsdiagramm(in früheren Versionen Kooperationsdiagramm) zeigt die Wechselwirkungen zwischen den Teilen der Verbundstruktur und die Rollen der Kollaboration. Das Diagramm zeigt deutlich die Beziehung zwischen Elementen (Objekten).
5. Sequenzdiagramm verwendet, um eine Sequenz von Objektinteraktionen zu visualisieren. Zeigt den Lebenszyklus eines bestimmten Objekts und die Interaktion von Akteuren (Akteuren) innerhalb eines Anwendungsfalls, die Abfolge der Nachrichten, die sie austauschen.
6. Interaktionsübersichtsdiagramm enthält einen Teil des Sequenzdiagramms und Kontrollflusskonstrukte. Hilft, das Zusammenspiel von Objekten aus verschiedenen Blickwinkeln zu betrachten.
7. Synchronisationsdiagramm- ein separater Untertyp von Interaktionsdiagrammen, der auf Timing spezialisiert ist. Diagramme dieser Art werden verwendet, um das Verhalten von Objekten über einen bestimmten Zeitraum zu studieren.

Die UML ist heute die Standardnotation für die visuelle Modellierung von Softwaresystemen, die im Herbst 1997 von der Object Managing Group (OMG) übernommen wurde und von vielen objektorientierten CASE-Produkten unterstützt wird.

Der UML-Standard bietet die folgenden Diagramme zur Modellierung:

· Use-Case-Diagramm - zur Modellierung der Geschäftsprozesse einer Organisation oder eines Unternehmens und zur Ermittlung der Anforderungen an das zu erstellende Informationssystem;

· Klassendiagramm (Klassendiagramm) - zur Modellierung der statischen Struktur der Klassen des Systems und der Verbindungen zwischen ihnen;

Verhaltensdiagramme

· Interaktionsdiagramme;

· Sequenzdiagramme - um den Prozess des Austauschs von Nachrichten zwischen Objekten innerhalb eines einzigen Anwendungsfalls zu simulieren;

· Kollaborationsdiagramm – zur Modellierung des Messaging-Prozesses zwischen Objekten innerhalb eines Anwendungsfalls;

· Statechart-Diagramm - zur Modellierung des Verhaltens von Systemobjekten beim Übergang von einem Zustand in einen anderen;

· Aktivitätsdiagramm - zur Modellierung des Verhaltens des Systems im Rahmen verschiedener Anwendungsfälle oder Modellierungsaktivitäten;

Implementierungsdiagramme:

Komponentendiagramme - um die Hierarchie der Komponenten (Subsysteme) eines Informationssystems zu modellieren;

· Bereitstellungsdiagramm - um die physische Architektur des entworfenen Informationssystems zu modellieren.

In Abb. 1.1 stellt ein integriertes Modell des Informationssystems vor, einschließlich der grundlegenden Diagramme, die in diesem Kursprojekt entwickelt werden sollen.

Reis. 1. Ein integriertes Modell eines Informationssystems in der Notation der UML-Sprache

4.2. Anwendungsfalldiagramm

Ein Anwendungsfall ist eine Abfolge von Aktionen, die vom System als Reaktion auf ein Ereignis ausgeführt werden, das von einem externen Objekt (Akteur) ausgelöst wird. Ein Anwendungsfall beschreibt eine typische Interaktion zwischen einem Benutzer und einem System. Im einfachsten Fall wird der Anwendungsfall ermittelt, indem mit dem Benutzer die Funktionen besprochen werden, die er in einem gegebenen Informationssystem implementieren möchte. In der UML wird ein Anwendungsfall wie folgt abgebildet:

Abb. 2. Anwendungsfall

Akteur ist die Rolle, die der Benutzer in Bezug auf das System spielt. Schauspieler repräsentieren Rollen, nicht bestimmte Personen oder Berufsbezeichnungen. Obwohl sie in Use-Case-Diagrammen als stilisierte menschliche Figuren dargestellt werden, kann der Akteur auch ein externes Informationssystem sein, das einige Informationen aus dem System benötigt. Zeigen Sie Akteure in Ihrem Diagramm nur dann an, wenn sie wirklich einige Anwendungsfälle benötigen. In der UML werden Akteure als Formen dargestellt:

Abb. 3. Schauspieler (Schauspieler)

Es gibt drei Haupttypen von Schauspielern:

· Benutzer;

· Systeme;

· Andere Systeme, die damit interagieren;

Die Zeit wird zu einem Akteur, wenn der Start von Ereignissen im System davon abhängt.

4.2.1. Beziehungen zwischen Anwendungsfällen und Akteuren

In UML unterstützen Anwendungsfalldiagramme verschiedene Arten von Beziehungen zwischen Diagrammelementen:

Kommunikation,

Inklusion (einschließen),

Verlängerung (verlängern),

Verallgemeinerung.

Kommunikationsverbindung Ist die Beziehung zwischen dem Anwendungsfall und dem Akteur. In der UML werden Kommunikationsverbindungen mit einer einseitigen Assoziation (durchgezogene Linie) dargestellt.

Abb. 4. Beispiel für eine Kommunikationsverbindung

Aufnahme-Link gilt in Situationen, in denen ein Systemverhalten in mehr als einem Anwendungsfall wiederholt wird. Diese Links werden normalerweise verwendet, um eine wiederverwendbare Funktion zu modellieren.

Erweiterungslink wird verwendet, um Änderungen im normalen Verhalten eines Systems zu beschreiben. Es ermöglicht einem Anwendungsfall, bei Bedarf die Funktionalität eines anderen Anwendungsfalls zu verwenden.

Abb. 5. Beispiel für die Verbindung von Inklusion und Erweiterung

Generalisierungslink gibt an, dass mehrere Akteure oder Klassen gemeinsame Eigenschaften haben.

Abb. 6. Beispiel für einen Generalisierungslink

4.3.

Interaktionsdiagramme beschreiben das Verhalten von interagierenden Objektgruppen. Typischerweise deckt ein Interaktionsdiagramm das Verhalten von Objekten innerhalb nur eines Anwendungsfalls ab. Ein solches Diagramm zeigt eine Reihe von Objekten und die Nachrichten, die sie miteinander austauschen.

Nachricht Ist das Mittel, mit dem das Senderobjekt das Empfängerobjekt auffordert, eine seiner Operationen auszuführen.

Informative Nachricht Ist eine Nachricht, die das Empfängerobjekt mit einigen Informationen versorgt, um seinen Zustand zu aktualisieren.

Anfragenachricht (abfragend) Ist eine Nachricht, die die Ausgabe einiger Informationen über das Empfängerobjekt anfordert.

Imperative Nachricht Ist eine Nachricht, die den Empfänger auffordert, etwas zu unternehmen.

Es gibt zwei Arten von Interaktionsdiagrammen: Sequenzdiagramme und Kollaborationsdiagramme.

4.3.1. Sequenzdiagramme

Sequenzdiagramm spiegelt den Fluss von Ereignissen wider, die innerhalb eines einzelnen Anwendungsfalls auftreten.

Alle Akteure (Akteure, Klassen oder Objekte), die an einem bestimmten Szenario (Anwendungsfall) beteiligt sind, werden oben im Diagramm angezeigt. Pfeile entsprechen Nachrichten, die zwischen einem Akteur und einem Objekt oder zwischen Objekten weitergegeben werden, um erforderliche Funktionen auszuführen.

In einem Sequenzdiagramm wird ein Objekt als Rechteck mit einer vertikalen gestrichelten Linie nach unten gezeichnet. Diese Zeile heißt die Lebensader eines Objekts ... Es ist ein Fragment des Lebenszyklus eines Objekts im Interaktionsprozess.

Jede Nachricht wird als Pfeil zwischen den Lebenslinien zweier Objekte dargestellt. Nachrichten werden in der Reihenfolge angezeigt, in der sie auf der Seite von oben nach unten erscheinen. Jede Nachricht ist mindestens mit dem Nachrichtennamen gekennzeichnet. Optional können Sie auch Argumente und einige Kontrollinformationen hinzufügen. Sie können die Selbstdelegation anzeigen - eine Nachricht, die ein Objekt an sich selbst sendet, wobei der Pfeil der Nachricht auf dieselbe Lebenslinie zeigt.

Reis. 7. Beispiel für ein Sequenzdiagramm

4.3.2. Kooperationsdiagramm

Kooperationsdiagramme den Ereignisfluss innerhalb eines bestimmten Szenarios (Use-Case) anzeigen. Nachrichten sind nach Zeit geordnet, obwohl sich Kollaborationsdiagramme mehr auf Beziehungen zwischen Objekten konzentrieren. Ein Kollaborationsdiagramm stellt alle Informationen dar, die ein Sequenzdiagramm enthält, aber ein Kollaborationsdiagramm beschreibt den Ereignisfluss anders. Es macht es einfacher, die Verbindungen zwischen Objekten zu verstehen.

In einem Kollaborationsdiagramm zeigen Pfeile wie in einem Sequenzdiagramm Nachrichten an, die für einen bestimmten Anwendungsfall ausgetauscht werden. Ihre zeitliche Abfolge ist durch die Nummerierung der Nachrichten gekennzeichnet.

Reis. 8. Beispiel für ein Kooperationsdiagramm

4.4. Klassen Diagramm

4.4.1. Allgemeine Information

Klassen Diagramm definiert die Typen von Klassen des Systems und verschiedene Arten von statischen Verbindungen, die zwischen ihnen bestehen. Klassendiagramme stellen auch Klassenattribute, Klassenoperationen und Einschränkungen dar, die für Beziehungen zwischen Klassen gelten.

Ein UML-Klassendiagramm ist ein Graph, dessen Knoten Elemente der statischen Struktur des Projekts (Klassen, Interfaces) sind und Bögen die Beziehungen zwischen Knoten (Assoziationen, Vererbung, Abhängigkeiten) sind.

Das Klassendiagramm zeigt die folgenden Elemente:

· Paket - eine Reihe von Modellelementen, die logisch miteinander verbunden sind;

· Klasse - eine Beschreibung der allgemeinen Eigenschaften einer Gruppe ähnlicher Objekte;

· Schnittstelle ist eine abstrakte Klasse, die einen Satz von Operationen definiert, die ein Objekt einer beliebigen Klasse, die dieser Schnittstelle zugeordnet ist, anderen Objekten zur Verfügung stellt.

4.4.2. Klasse

Klasse ist eine Gruppe von Entitäten (Objekten), die ähnliche Eigenschaften haben, nämlich Daten und Verhalten. Ein einzelner Vertreter einer Klasse wird als Klassenobjekt oder einfach als Objekt bezeichnet.

Unter dem Verhalten eines Objekts versteht man in UML beliebige Regeln für die Interaktion eines Objekts mit der Außenwelt und mit den Daten des Objekts selbst.

In den Diagrammen wird die Klasse als Rechteck mit durchgehendem Rahmen dargestellt, das durch horizontale Linien in 3 Abschnitte unterteilt ist:

Der obere Abschnitt (Namensabschnitt) enthält den Klassennamen und andere allgemeine Eigenschaften (insbesondere den Stereotyp).

Der mittlere Abschnitt enthält eine Liste von Attributen

Unten befindet sich eine Liste von Klassenoperationen, die ihr Verhalten widerspiegeln (von der Klasse ausgeführte Aktionen).

Alle Abschnitte von Attributen und Operationen werden möglicherweise nicht angezeigt (sowie beide gleichzeitig). Für einen fehlenden Abschnitt müssen Sie keine Trennlinie ziehen und irgendwie auf das Vorhandensein oder Fehlen von Elementen darin hinweisen.

Zusätzliche Abschnitte, wie z. B. Ausnahmen, können nach Ermessen einer bestimmten Implementierung eingeführt werden.

Reis. 9. Beispiel für ein Klassendiagramm

4.4.2.1.Klassenstereotypen

Klassenstereotypen sind ein Mechanismus zur Kategorisierung von Klassen.

In der UML sind drei Hauptklassenstereotypen definiert:

Grenze

Entität

Kontrolle.

4.4.2.2.Grenzklassen

Grenzklassen sind Klassen, die sich an der Grenze des Systems und der gesamten Umgebung befinden. Dies sind Anzeigen, Berichte, Schnittstellen zu Hardware (wie Drucker oder Scanner) und Schnittstellen zu anderen Systemen.

Um die Grenzklassen zu finden, müssen Sie die Anwendungsfalldiagramme untersuchen. Für jede Interaktion zwischen einem Akteur und einem Anwendungsfall muss es mindestens eine Grenzklasse geben. Es ist diese Klasse, die es dem Akteur ermöglicht, mit dem System zu interagieren.

4.4.2.3.Entitätsklassen

Entitätsklassen enthalten gespeicherte Informationen. Sie sind für den Benutzer von größter Bedeutung und verwenden daher oft Begriffe aus dem Fachgebiet in ihrem Namen. Normalerweise wird für jede Entitätsklasse eine Tabelle in der Datenbank erstellt.

4.4.2.4.Kontrollklassen

Kontrollklassen sind dafür verantwortlich, die Aktionen anderer Klassen zu koordinieren. Normalerweise hat jeder Anwendungsfall eine Kontrollklasse, die die Ereignisfolge für diesen Anwendungsfall steuert. Die kontrollierende Klasse ist für die Koordination zuständig, trägt aber selbst keine Funktionalität, da die anderen Klassen ihr nicht viele Nachrichten senden. Stattdessen verschickt er selbst viele Nachrichten. Die Managerklasse delegiert einfach die Verantwortung an andere Klassen, weshalb sie oft als Managerklasse bezeichnet wird.

Es kann andere Kontrollklassen im System geben, die mehreren Anwendungsfällen gemeinsam sind. Beispielsweise kann es eine SecurityManager-Klasse geben, die für die Überwachung von Sicherheitsereignissen verantwortlich ist. Die Klasse TransactionManager ist für die Koordinierung von Nachrichten im Zusammenhang mit Datenbanktransaktionen verantwortlich. Es können andere Manager vorhanden sein, die sich mit anderen Elementen des Systembetriebs befassen, wie beispielsweise der gemeinsamen Nutzung von Ressourcen, der verteilten Datenverarbeitung oder der Fehlerbehandlung.

Zusätzlich zu den oben genannten Stereotypen können Sie Ihre eigenen erstellen.

4.4.2.5.Attribute

Ein Attribut ist eine Information, die einer Klasse zugeordnet ist. Attribute speichern gekapselte Klassendaten.

Da die Attribute innerhalb der Klasse enthalten sind, werden sie von anderen Klassen ausgeblendet. Daher müssen Sie möglicherweise angeben, welche Klassen Attribute lesen und ändern dürfen. Diese Eigenschaft wird als Attributsichtbarkeit bezeichnet.

Ein Attribut kann für diesen Parameter vier mögliche Werte haben:

Öffentlich (allgemein, offen). Dieser Sichtbarkeitswert geht davon aus, dass das Attribut für alle anderen Klassen sichtbar ist. Jede Klasse kann den Wert des Attributs anzeigen oder ändern. In der UML-Notation wird dem gemeinsamen Attribut ein "+"-Zeichen vorangestellt.

Privat (geschlossen, geheim). Das entsprechende Attribut ist für keine andere Klasse sichtbar. Ein privates Attribut wird gemäß der UML-Notation mit einem "-" gekennzeichnet.

Geschützt Ein solches Attribut steht nur der Klasse selbst und ihren Nachkommen zur Verfügung. Die UML-Notation für ein geschütztes Attribut ist das Zeichen "#".

Paket oder Implementierung Geht davon aus, dass dieses Attribut generisch ist, jedoch nur innerhalb seines Pakets. Diese Art der Sichtbarkeit wird durch kein spezielles Symbol gekennzeichnet.

Mit Hilfe von Geschlossenheit oder Sicherheit kann vermieden werden, dass der Wert eines Attributs von allen Klassen des Systems geändert wird. Stattdessen wird die Logik zum Ändern eines Attributs in dieselbe Klasse wie das Attribut selbst eingeschlossen. Die von Ihnen festgelegten Sichtbarkeitsparameter wirken sich auf den generierten Code aus.

4.4.2.6.Betrieb

Operationen implementieren klassenspezifisches Verhalten. Eine Operation besteht aus drei Teilen - Name, Parameter und Rückgabetyp.

Parameter sind die Argumente, die von der "Eingabe"-Operation empfangen werden. Der Rückgabetyp bezieht sich auf das Ergebnis der Aktion der Operation.

In einem Klassendiagramm können Sie sowohl die Namen der Operationen als auch die Namen der Operationen zusammen mit ihren Parametern und dem Rückgabetyp anzeigen. Um die Arbeitsbelastung des Diagramms zu reduzieren, ist es sinnvoll, bei einigen nur die Namen der Operationen und bei anderen ihre vollständige Signatur anzuzeigen.

In der UML haben Operationen die folgende Notation:

Operationsname (Argument: Datentyp von Argument, Argument2: Datentyp von Argument2, ...): Rückgabetyp

Es sind vier verschiedene Arten von Transaktionen zu berücksichtigen:

Durchführungsoperationen;

Kontrollvorgänge;

Zugriffsvorgänge;

Hilfsoperationen.

Implementierungsvorgänge

Implementor-Operationen implementieren einige Geschäftsfunktionen. Solche Operationen können durch Untersuchung von Interaktionsdiagrammen gefunden werden. Diagramme dieses Typs konzentrieren sich auf Geschäftsfunktionen, und jede Nachricht im Diagramm kann höchstwahrscheinlich einer Implementierungsoperation zugeordnet werden.

Jeder Implementierungsschritt muss leicht auf die entsprechende Anforderung zurückführbar sein. Dies wird in verschiedenen Phasen der Simulation erreicht. Eine Aktivität wird aus einer Nachricht in einem Interaktionsdiagramm abgeleitet, Nachrichten werden aus einer detaillierten Beschreibung eines Ereignisflusses abgeleitet, die basierend auf einem Anwendungsfall generiert wird, und dieser wird aus Anforderungen abgeleitet. Die Möglichkeit, diese gesamte Kette zu verfolgen, stellt sicher, dass jede Anforderung in Code umgesetzt wird und jeder Codeabschnitt eine Anforderung implementiert.

Steuervorgänge

Manageroperationen steuern die Erstellung und Zerstörung von Objekten. Klassenkonstruktoren und -destruktoren fallen in diese Kategorie.

Zugriffsvorgänge

Attribute sind normalerweise privat oder geschützt. Andere Klassen müssen jedoch manchmal ihre Werte anzeigen oder ändern. Dafür gibt es Zugriffsoperationen. Dieser Ansatz ermöglicht es, Attribute sicher innerhalb einer Klasse zu kapseln und sie so vor anderen Klassen zu schützen, ermöglicht aber dennoch einen kontrollierten Zugriff auf sie. Es ist üblich, Get- und Set-Operationen für jedes Klassenattribut zu erstellen.

Hilfsbetriebe

Hilfsoperationen sind die Operationen einer Klasse, die sie zur Erfüllung ihrer Aufgaben benötigt, von denen andere Klassen aber nichts wissen sollten. Dies sind private und geschützte Operationen der Klasse.

Gehen Sie folgendermaßen vor, um Transaktionen zu identifizieren:

1. Erkunden Sie Sequenzdiagramme und kooperative Diagramme. Die meisten Meldungen in diesen Diagrammen sind Implementierungsaktivitäten. Reflektierende Botschaften werden Hilfsoperationen sein.

2. Betrachten Sie Kontrolloperationen. Möglicherweise müssen Sie Konstruktoren und Destruktoren hinzufügen.

3. Betrachten Sie Zugriffsvorgänge. Für jedes Klassenattribut, mit dem andere Klassen arbeiten müssen, müssen Sie Get- und Set-Operationen erstellen.

4.4.2.7.Anschlüsse

Eine Beziehung ist eine semantische Beziehung zwischen Klassen. Es ermöglicht einer Klasse, die Attribute, Operationen und Beziehungen einer anderen Klasse kennenzulernen. Mit anderen Worten, damit eine Klasse in einem Sequenzdiagramm oder einem kooperativen Diagramm eine Nachricht an eine andere senden kann, muss eine Beziehung zwischen den beiden bestehen.

Es gibt vier Arten von Beziehungen, die zwischen Klassen hergestellt werden können: Assoziationen, Abhängigkeiten, Aggregationen und Generalisierungen.

Kommunikationsverband

Assoziation ist die semantische Verbindung zwischen Klassen. Sie werden im Klassendiagramm als normale Linie gezeichnet.

Reis. 10. Kommunikationsverband

Assoziationen können wie im Beispiel bidirektional oder unidirektional sein. In der UML werden bidirektionale Assoziationen als einfache Linie ohne Pfeile oder mit Pfeilen auf beiden Seiten gezeichnet. Bei einer unidirektionalen Assoziation wird nur ein Pfeil dargestellt, der seine Richtung anzeigt.

Die Richtung der Assoziation kann durch Untersuchung von Sequenzdiagrammen und kooperativen Diagrammen bestimmt werden. Wenn alle Nachrichten an sie nur von einer Klasse gesendet und nur von einer anderen Klasse empfangen werden, aber nicht umgekehrt, besteht zwischen diesen Klassen eine unidirektionale Beziehung. Wird mindestens eine Nachricht in die Gegenrichtung gesendet, muss die Assoziation bidirektional sein.

Assoziationen können reflektierend sein. Die reflexive Assoziation geht davon aus, dass eine Instanz einer Klasse mit anderen Instanzen derselben Klasse interagiert.

Kommunikationssucht

Abhängigkeitsbeziehungen spiegeln auch die Beziehung zwischen Klassen wider, aber sie sind immer unidirektional und zeigen, dass eine Klasse von den Definitionen der anderen abhängt. Klasse A verwendet beispielsweise Methoden der Klasse B. Wenn sich Klasse B ändert, müssen Sie die entsprechenden Änderungen in Klasse A vornehmen.

Die Abhängigkeit wird als gestrichelte Linie zwischen zwei Diagrammelementen dargestellt, und das am Ende des Pfeils verankerte Element wird als abhängig von dem am Anfang dieses Pfeils verankerten Element betrachtet.

Reis. 11. Kommunikationssucht

Beim Generieren von Code für diese Klassen werden ihnen keine neuen Attribute hinzugefügt. Es werden jedoch die sprachspezifischen Aussagen generiert, die zur Unterstützung der Kommunikation erforderlich sind.

Link-Aggregation

Aggregationen sind eine engere Form der Assoziation. Aggregation ist eine Verbindung zwischen einem Ganzen und einem Teil davon. Sie können beispielsweise eine Klasse für Auto sowie Klassen für Motor, Reifen und Klassen für andere Teile des Autos haben. Als Ergebnis besteht ein Objekt der Klasse Car aus einem Objekt der Klasse Engine, vier Objekten von Tyres usw. Aggregationen werden als Linie mit einer Raute für eine Klasse als Ganzes visualisiert:

Reis. 11. Kommunikationsaggregation

Neben der einfachen Aggregation führt die UML eine stärkere Form der Aggregation ein, die Komposition genannt wird. Je nach Komposition kann ein Objektteil nur zu einem Ganzen gehören, zudem fällt in der Regel der Lebenszyklus der Teile mit dem des Ganzen zusammen: Sie leben und sterben mit ihm. Jede Entfernung des Ganzen erstreckt sich auf seine Teile.

Dieses kaskadierende Löschen wird oft als Teil der Definition von Aggregation angesehen, ist jedoch immer impliziert, wenn die Rollenvielfalt 1..1 ist; Wenn beispielsweise ein Kunde gelöscht werden muss, muss diese Löschung für Bestellungen (und wiederum für Bestellpositionen) gelten.

Zeigen Sie das Verhalten eines Objekts während seines Lebens an, von der Erstellung des Objekts bis zu seiner Zerstörung. Jedes Zustandsdiagramm repräsentiert eine Art Automat.

Aktionsplan

Untersuchen Sie im Abschnitt Beschreibung den grundlegenden Satz von Zustandsdiagrammsymbolen, die Sie zum Lesen von Diagrammen benötigen.

Nachdem Sie die anderen Abschnitte (Beispiel, Anwendung) gelesen haben, können Sie selbst versuchen, Zustandsdiagramme zu zeichnen.

Hinweise (Beschreibung)

Dies ist der grundlegende Zeichensatz Zustandsdiagramme erforderlich, um das Diagramm lesen zu können. Nachdem Sie die anderen Abschnitte ("Beispiel", "Anwendung") gelesen haben, können Sie Zustandsdiagramme auf sich allein!

Begriff	Bild	Beschreibung
Anfänglicher Pseudozustand		Ausgangszustand des Systems
Übergang		Übergang bedeutet, von einem Zustand in einen anderen zu wechseln.
Zustand		Gibt die vom System durchgeführten Aktionen (kann Optionen beinhalten) an, die zu den beobachteten Ergebnissen der Akteure führen.
Zustand Aktivitätsstatus		Ein komplexer Schritt in einem Anwendungsfall kann durch einen anderen Anwendungsfall repräsentiert werden. In UML-Begriffen sagen wir, dass der erste Anwendungsfall den zweiten umfasst.
Endzustand		Ermöglicht Ihnen, die Grenzen von Systemen oder Subsystemen zu definieren.
Interne Aktivitäten		Der Fall, in dem Zustände auf Ereignisse reagieren können, ohne einen Übergang durchzuführen, in diesem Fall werden Ereignis, Schutz und Aktivität innerhalb des Zustandsrechtecks ​​platziert.
Eingabeaktivität		Die Eingabeaktivität wird ausgeführt, wenn Sie den Status betreten
Ausgabeaktivität		Exit Activity - Wird ausgeführt, wenn Sie den Status verlassen.
Superstaat		Es kommt oft vor, dass mehrere Staaten gemeinsame Übergänge und interne Aktivitäten haben. In solchen Fällen können Sie sie in Unterzustände umwandeln und das allgemeine Verhalten in einen Superzustand verschieben.
Parallele Zustände		Zustände können in mehrere gleichzeitige Zustände unterteilt werden, die gleichzeitig ausgeführt werden.

Wie man die Kreativitätstechnik anwendet

UML-Zustandsdiagramme eignen sich gut, um das Verhalten eines einzelnen Objekts in mehreren Anwendungsfällen zu beschreiben. Sie sind jedoch wenig geeignet, um ein Verhalten zu beschreiben, das durch die Interaktion vieler Objekte gekennzeichnet ist. Daher ist es sinnvoll, andere Technologien in Verbindung mit Zustandsdiagrammen zu verwenden. Interaktionsdiagramme (Kapitel 4) beschreiben beispielsweise perfekt das Verhalten mehrerer Objekte in einem einzigen Anwendungsfall und UML-Aktivitätsdiagramme gut, um den grundlegenden Fluss mehrerer Objekte in mehreren Anwendungsfällen zu zeigen.

Nicht jeder hält Statecharts für natürlich. Sehen Sie, wie Spezialisten mit ihnen arbeiten. Es ist möglich, dass Ihre Teammitglieder der Meinung sind, dass Statecharts nicht für ihren Arbeitsstil geeignet sind. Dies ist nicht die größte Schwierigkeit; Sie müssen daran denken, verschiedene Arbeitstechniken zu teilen.

Wenn Sie Zustandsdiagramme verwenden, versuchen Sie nicht, diese für jede Klasse des Systems zu zeichnen. Dieser Ansatz wird oft verwendet, um formal strenge Vollständigkeit zu gewährleisten, ist aber fast immer Energieverschwendung. Verwenden Sie Zustandsdiagramme nur für Klassen, die ein interessantes Verhalten zeigen, bei denen das Erstellen eines Zustandsdiagramms Ihnen hilft, zu verstehen, wie die Dinge laufen.

Viele Experten glauben, dass Der UI-Editor und die Steuerelemente verfügen über Funktionen, die bei der Anzeige mithilfe eines Zustandsdiagramms nützlich sind.

Wie lernt man

Hier haben wir versucht, das Lernen so einfach wie möglich zu gestalten. UML-Zustandsdiagramme.

Wie viele andere Sprachen verwendet es eine Reihe von Zeichen, um es zu beschreiben. Die Bedeutung dieser Symbole entnehmen Sie bitte der Tabelle im Abschnitt "Anmerkungen (Beschreibung)". Jedes Zeichen hat seinen eigenen Namen (Begriff) und Schreibweise. Außerdem wird jeder Begriff mit einer kurzen Erklärung versehen, um seinen Kerninhalt schnell zu verstehen.

Weiter empfehlen wir den Abschnitt "Beispiele" Zustandsdiagramme um sich im Lesen verschiedener Diagramme zu versuchen. Dann lohnt es sich, den Abschnitt "Anwendungen" zu studieren, denn obwohl die Anzahl der Diagrammtypen in der UML gering ist, können Sie den maximalen Nutzen aus deren Verwendung nur ziehen, wenn Sie die entsprechenden Diagramme für ihren vorgesehenen Zweck verwenden.

Anwendungsbeispiel

Zustandsmaschinendiagramme Ist eine bekannte Technologie zur Beschreibung des Verhaltens eines Systems. Zustandsdiagramme gibt es in der einen oder anderen Form seit 1960 und in den Anfängen der objektorientierten Programmierung wurden sie verwendet, um das Verhalten eines Systems darzustellen. Bei objektorientierten Ansätzen zeichnen Sie ein Zustandsdiagramm einer einzelnen Klasse, um das Verhalten eines einzelnen Objekts während seiner Lebensdauer darzustellen.

Immer wenn sie über Zustandsautomaten schreiben, werden unweigerlich Tempomatsysteme oder Verkaufsautomaten als Beispiele genannt.
Wir haben uns entschieden, den geheimen Kontrollpanel-Controller in der gotischen Burg zu verwenden. In diesem Schloss wollen wir unsere Schätze so verstecken, dass sie schwer zu finden sind. Um an das Schloss des Tresors zu gelangen, müssen wir eine strategische Kerze aus dem Kandelaber ziehen, aber das Schloss erscheint nur, wenn die Tür geschlossen ist. Nach dem Erscheinen des Schlosses können wir den Schlüssel hineinstecken und den Safe öffnen. Für zusätzliche Sicherheit haben wir darauf geachtet, dass der Tresor erst geöffnet werden kann, nachdem die Kerze entfernt wurde. Wenn der Dieb diese Vorsichtsmaßnahme nicht beachtet, werden wir ein abscheuliches Monster entfesseln, das den Dieb verschluckt.

In Abb. 10.1 zeigt Zustandsdiagramm die Controller-Klasse, die mein ungewöhnliches Sicherheitssystem verwaltet. Ein Zustandsdiagramm beginnt mit dem Zustand des zu erstellenden Controller-Objekts: Zustände Warten... Dies ist im Diagramm mit . gekennzeichnet anfänglicher Pseudozustand das ist kein Zustand, hat aber einen Pfeil, der auf den Anfangszustand zeigt.
Das Diagramm zeigt, dass sich der Controller in einem von drei Zuständen befinden kann: Warten, sperren und öffnen... Das Diagramm zeigt auch die Regeln, nach denen die Steuerung von einem Zustand in einen anderen übergeht. Diese Regeln werden in Form von Übergängen dargestellt - Linien, die Zustände verbinden.

Übergang bedeutet, von einem Zustand in einen anderen zu wechseln. Jeder Übergang hat ein eigenes Label, das aus drei Teilen besteht:
Trigger-Signatur / Aktivität... Alle von ihnen sind optional. Allgemein, Trigger-ID Ist das einzige Ereignis, das eine Zustandsänderung verursachen kann.

Schutz, falls angegeben, ist eine boolesche Bedingung, die erfüllt sein muss, damit der Übergang stattfindet. Aktivität ist ein Verhalten des Systems während des Übergangs. Es kann ein beliebiger Verhaltensausdruck sein. Die vollständige Form einer Triggerkennung kann mehrere Ereignisse und Parameter umfassen. Der Übergang vom Wartezustand (Abb. 10.1) in einen anderen Zustand kann gelesen werden als „Im Wartezustand, wenn die Kerze entfernt wird, sehen Sie die Sperre und gehen in den Sperrzustand“.

Alle drei Teile der Übergangsbeschreibung sind optional. Aktivität überspringen bedeutet, dass während des Übergangs nichts passiert. Überspringen von Guards bedeutet, dass immer ein Übergang erfolgt, wenn ein auslösendes Ereignis eintritt. Die Trigger-ID fehlt selten, aber es kommt vor. Dies bedeutet, dass der Übergang sofort erfolgt, was vor allem in Aktivitätszuständen zu beobachten ist.

Wenn ein Ereignis in einem bestimmten Zustand auftritt, dann kann von diesem Zustand nur ein Übergang erfolgen, zum Beispiel in den Lock-Zustand (Abb. 10.1), die Schutzmaßnahmen müssen sich gegenseitig ausschließen. Wenn ein Ereignis eintritt, aber keine erlaubten Übergänge vorhanden sind – zum Beispiel das Schließen eines Safes im Wartezustand oder das Entfernen einer Kerze bei geöffneter Tür – wird das Ereignis ignoriert.

Endzustand ( Endzustand) bedeutet, dass die Zustandsmaschine die Ausführung beendet hat, wodurch das Controller-Objekt gelöscht wird. Für diejenigen, die die Unachtsamkeit hatten, in die Falle zu tappen, berichten wir, dass wir gezwungen sind, das Kaninchen zurück in den Käfig zu stecken, den Boden zu waschen und das System neu zu starten, da das Kontrollobjekt nicht mehr existiert.

Denken Sie daran, dass Zustandsautomaten nur Objekte anzeigen können, die direkt beobachtet oder auf die reagiert wird. Während Sie also erwarten, dass wir bei geöffneter Tür etwas in den Tresor legen oder dort etwas mitnehmen, haben wir dies auf der Grafik nicht markiert, da die Steuerung nichts dazu zu sagen hat.

Wenn Entwickler von Objekten sprechen, beziehen sie sich oft auf den Zustand der Objekte, d. h. auf die Kombination aller Daten, die in den Feldern des Objekts enthalten sind. Der Zustand in einem Zustandsmaschinendiagramm ist jedoch ein abstrakteres Zustandskonzept; Der Punkt ist, dass verschiedene Zustände unterschiedliche Reaktionsweisen auf Ereignisse beinhalten.

Interne Aktivitäten im Statechart

Zustände können auf Ereignisse reagieren, ohne einen Übergang zu begehen, indem Sie . verwenden interne Aktivitäten (interne Aktivitäten), in diesem Fall werden Ereignis, Schutz und Aktivität innerhalb des Statusrechtecks ​​platziert.

In Abb. 10.2 stellt den Zustand mit internen Aktivitäten von Symbolen und Ereignissen des Hilfesystems dar, die Sie in den Textfeldern des Editors beobachten können Benutzeroberfläche... Interne Aktivität ist wie ein Selbstübergang – ein Übergang, der in denselben Zustand zurückkehrt. Die Syntax für interne Aktivitäten folgt der gleichen Ereignis-, Schutz- und Prozedurlogik.

In Abb. 10.2 zeigt auch besondere Aktivitäten: Input- und Output-Aktivitäten. Eingabeaktivität ausgeführt, wenn Sie einen Staat betreten; Ausgabeaktivität- wenn Sie den Staat verlassen. Interne Aktivitäten initiieren jedoch nicht Input- und Output-Aktivitäten; das ist der unterschied zwischen interne Aktivitäten undSelbstübergänge .

Die Aktivitätszustände im Statechart

In den bisher beschriebenen Zuständen ist das Objekt stumm und wartet auf das nächste Ereignis, bevor es etwas tut. Es sind jedoch Zustände möglich, in denen das Objekt eine gewisse Aktivität aufweist.

Zustand Suche in Abb. 10.3 ist ein solcher Zustand Aktivitätsstatus: laufende Aktivität wird durch das Symbol angezeigt tun /; daher der Begriff tun-aktivität (aktiv sein)... Nach Abschluss der Suche werden Übergänge ohne Aktivität durchgeführt, z. B. um neue Geräte anzuzeigen (Neue Hardware anzeigen)... Wenn ein Stornoereignis ( Abbrechen), dann tun-aktivität es unterbricht nur und wir kehren zum Zustand zurück Hardware-Fenster aktualisieren.

Sowohl Do-Aktivitäten als auch gewöhnliche Aktivitäten repräsentieren die Manifestation eines bestimmten Verhaltens. Der entscheidende Unterschied zwischen beiden besteht darin, dass normale Aktivitäten "momentan" sind und nicht durch normale Ereignisse unterbrochen werden können, während do-Aktivitäten für eine begrenzte Zeit laufen und unterbrochen werden können, wie in Abb. 10.3. Augenblicklichkeit wird für verschiedene Systeme unterschiedlich interpretiert; bei Echtzeitsystemen kann dies mehrere Maschinenanweisungen und bei Desktop-Software mehrere Sekunden dauern.

V UML 1 gemeinsame Aktivitäten wurden mit dem Begriff . bezeichnet Aktion(Aktion) und der Begriff Aktivität(Aktivität) wurde nur verwendet für Do-Aktivitäten.

Superstaaten

Es kommt oft vor, dass mehrere Staaten gemeinsame Übergänge und interne Aktivitäten haben. In solchen Fällen können Sie sie in Unterzustände umwandeln und das allgemeine Verhalten in einen Superzustand verschieben, wie in Abb. 10.4. Ohne Superstaat müsste man einen Übergang zeichnen Abbrechen(Abbrechen) für alle drei Staaten innerhalb eines Staates Verbindungsdetails eingeben.

Parallele Zustände

Zustände können in mehrere gleichzeitige Zustände unterteilt werden, die gleichzeitig ausgeführt werden. In Abb. 10.5 zeigt einen einfachen Wecker, der entweder eine CD oder ein Radio einschalten und entweder die aktuelle Uhrzeit oder die Weckzeit anzeigen kann.

CD/Radio-Optionen und aktuelle Uhrzeit/Signalzeit sind parallel. Wenn Sie dies mit einem nicht parallelen Zustandsdiagramm darstellen möchten, wäre es ein unübersichtliches Diagramm, wenn Sie Zustände hinzufügen müssen. Die Aufteilung der beiden Verhaltensbereiche in zwei Statecharts macht es deutlich anschaulicher.

Reis. 10.5 beinhaltet auch Hintergrundstatus(Geschichte Pseudozustand). Das bedeutet, dass beim Einschalten der Uhr die Radio-/CD-Option in den Zustand übergeht, in dem sich die Uhr beim Ausschalten befand. Der aus der Vorgeschichte hervorgehende Pfeil zeigt, welcher Zustand ursprünglich existierte, als es keine Vorgeschichte gab.

Zustandsdiagramme implementieren

Ein Zustandsdiagramm kann im Wesentlichen auf drei Arten implementiert werden: mit einer verschachtelten switch-Anweisung, einem Zustandsmuster und einer Zustandstabelle. Der einfachste Ansatz für die Arbeit mit Zustandsdiagrammen ist eine verschachtelte switch-Anweisung, wie sie in Abbildung 1 dargestellt ist. 10.6.

Obwohl diese Methode einfach ist, ist sie selbst für diesen einfachen Fall sehr lang. Darüber hinaus kann man bei diesem Ansatz sehr leicht die Kontrolle verlieren, daher empfehlen wir nicht, ihn auch in elementaren Situationen zu verwenden.
Das State-Muster stellt eine Hierarchie von Zustandsklassen zur Behandlung des Zustandsverhaltens dar. Jeder Zustand in einem Zustandsdiagramm hat seine eigene Unterklasse von Zustand. Der Controller hat Methoden für jedes Ereignis, die einfach an die Zustandsklasse weiterleiten. Das Zustandsdiagramm in Abb. 10.1 könnte mit den in Abb. 10.7.

An der Spitze der Hierarchie steht eine abstrakte Klasse, die eine Beschreibung aller Methoden enthält, die Ereignisse behandeln, jedoch keine Implementierung.
Für jeden bestimmten Zustand reicht es aus, die Handler-Methode für ein bestimmtes Ereignis neu zu schreiben, das den Übergang aus dem Zustand einleitet.
Eine Zustandstabelle repräsentiert ein Zustandsdiagramm als Daten.

Das Diagramm in Abb. 10.1 kann in Form einer Tabelle dargestellt werden. 10.1.
Wir bauen dann einen Interpreter, der die Zustandstabelle zur Laufzeit verwendet, oder einen Codegenerator, der Klassen basierend auf dieser Tabelle generiert.

Natürlich wird die meiste Arbeit an einer Zustandstabelle einmal gemacht, aber dann kann sie immer dann verwendet werden, wenn ein Zustandsproblem gelöst werden muss. Die Laufzeitstatustabelle kann ohne Neukompilierung geändert werden, was ziemlich praktisch ist. Das Zustandsmuster ist einfacher zu erstellen, und obwohl jeder Zustand eine separate Klasse erfordert, muss nur sehr wenig Code geschrieben werden.

Die angegebenen Implementierungen sind praktisch minimal, aber sie geben eine Vorstellung von der Verwendung Zustandsdiagramme... In jedem Fall führt die Implementierung von Zustandsmodellen zu einem eher stereotypen Programm, daher ist es in der Regel am besten, hierfür auf irgendeine Form der Codegenerierung zurückzugreifen.

Abonnieren Sie die Site-News. Das Anmeldeformular finden Sie in der rechten Spalte der Site.

Wenn Sie sich beruflich selbstständig machen wollen, laden wir Sie zum Kurs "" ein.

UML ist eine einheitliche grafische Modellierungssprache zum Beschreiben, Visualisieren, Entwerfen und Dokumentieren von OO-Systemen. UML soll den Prozess der Modellierung von Softwaresystemen basierend auf dem OO-Ansatz unterstützen, das Verhältnis von Konzept- und Softwarekonzepten organisieren, um die Probleme der Skalierung komplexer Systeme widerzuspiegeln. Modelle in UML werden in allen Phasen des Softwaresystemlebenszyklus verwendet, von der Geschäftsanalyse bis zur Systemwartung. Verschiedene Organisationen können UML nach Belieben anwenden, abhängig von ihren Problembereichen und verwendeten Technologien.

Eine kurze Geschichte der UML

Bis Mitte der 90er Jahre wurden mehrere Dutzend OO-Modellierungsmethoden von verschiedenen Autoren vorgeschlagen, von denen jeder seine eigene grafische Notation verwendete. Gleichzeitig hatte jede dieser Methoden ihre Stärken, erlaubte jedoch nicht den Aufbau eines ausreichend vollständigen PS-Modells, das es "von allen Seiten" zeigte, dh alle notwendigen Projektionen (siehe Artikel 1). Darüber hinaus machte es das Fehlen eines OO-Modellierungsstandards für Entwickler schwierig, die am besten geeignete Methode auszuwählen, was die weit verbreitete Verwendung des OO-Ansatzes bei der Softwareentwicklung verhinderte.

Auf Wunsch der Object Management Group (OMG) - der Organisation, die für die Annahme von Standards im Bereich Objekttechnologien und Datenbanken verantwortlich ist, wurde das dringende Problem der Vereinheitlichung und Standardisierung von den Autoren der drei beliebtesten OO-Methoden - G Buch, D. Rambo und A. Jacobson haben gemeinsam UML 1.1 entwickelt, das 1997 von der OMG als Standard anerkannt wurde.

UML ist eine Sprache

Jede Sprache besteht aus einem Vokabular und Regeln zum Kombinieren von Wörtern, um sinnvolle Konstruktionen zu erhalten. So sind insbesondere Programmiersprachen angeordnet, wie die UML. Seine Besonderheit besteht darin, dass das Sprachwörterbuch aus grafischen Elementen besteht. Jedes Grafiksymbol hat eine spezifische Semantik, sodass ein von einem Entwickler erstelltes Modell von einem anderen eindeutig verstanden werden kann, sowie ein Softwaretool, das die UML interpretiert. Daraus folgt insbesondere, dass ein in UML präsentiertes PS-Modell automatisch in eine OO-Programmiersprache (wie Java, C++, VisualBasic) übersetzt werden kann, d. h. wenn es ein gutes visuelles Modellierungswerkzeug gibt, das UML unterstützt , Modellbau , erhalten wir eine diesem Modell entsprechende Vorbereitung des Programmcodes.

Es sollte betont werden, dass die UML eine Sprache und keine Methode ist. Es erklärt, aus welchen Elementen Modelle erstellt und wie sie gelesen werden können, aber es sagt nichts darüber aus, welche Modelle in welchen Fällen entwickelt werden sollten. Um eine auf UML basierende Methode zu erstellen, ist es notwendig, diese um eine Beschreibung des Softwareentwicklungsprozesses zu ergänzen. Ein Beispiel für einen solchen Prozess ist der Rational Unified Process, der in nachfolgenden Artikeln diskutiert wird.

UML-Vokabular

Das Modell wird in Form von Entitäten und Beziehungen zwischen diesen dargestellt, die in Diagrammen dargestellt werden.

Entitäten Sind Abstraktionen, die die Hauptelemente von Modellen sind. Es gibt vier Arten von Entitäten: strukturell (Klasse, Schnittstelle, Komponente, Anwendungsfall, Kooperation, Knoten), verhaltensbezogen (Interaktion, Zustand), Gruppierung (Pakete) und Annotation (Kommentare). Jeder Entitätstyp hat seine eigene grafische Darstellung. Entitäten werden bei der Untersuchung von Diagrammen ausführlich besprochen.

Beziehung zeigen verschiedene Beziehungen zwischen Entitäten. Die UML definiert die folgenden Arten von Beziehungen:

• Sucht zeigt eine solche Verbindung zwischen zwei Entitäten, wenn eine von ihnen - unabhängig - verändert wird, kann dies die Semantik der anderen - abhängig - beeinflussen. Abhängigkeit wird durch einen gestrichelten Pfeil dargestellt, der von der abhängigen Entität zu der unabhängigen Entität zeigt.
• Verband Ist eine strukturelle Beziehung, die zeigt, dass Objekte in einer Entität mit Objekten in einer anderen verbunden sind. Eine Assoziation wird grafisch als Linie dargestellt, die die zu verknüpfenden Entitäten verbindet. Assoziationen werden verwendet, um zwischen Objekten zu navigieren. Durch die Zuordnung zwischen den Klassen "Bestellung" und "Produkt" kann man zum einen alle Waren finden, die in einer bestimmten Bestellung angegeben sind, oder zum anderen alle Bestellungen, in denen sich ein bestimmtes Produkt befindet . Es ist klar, dass die entsprechenden Programme einen Mechanismus für eine solche Navigation implementieren müssen. Wenn zum Navigieren nur eine Richtung erforderlich ist, wird dies durch einen Pfeil am Ende der Verknüpfung angezeigt. Ein Sonderfall einer Assoziation ist die Aggregation - eine Relation der Form "Ganzes" - "Teil". Grafisch wird es mit einer Raute am Ende in der Nähe des Entity-Ganzes hervorgehoben.
• Verallgemeinerung Ist eine Beziehung zwischen einer übergeordneten Entität und einer untergeordneten Entität. Im Wesentlichen spiegelt diese Beziehung die Vererbungseigenschaft für Klassen und Objekte wider. Die Generalisierung wird als Linie dargestellt, die mit einem Dreieck endet, das in Richtung der übergeordneten Entität zeigt. Das Kind erbt die Struktur (Attribute) und das Verhalten (Methoden) des Elternteils, kann aber gleichzeitig neue Strukturelemente und neue Methoden haben. Die UML ermöglicht die Mehrfachvererbung, wenn eine Entität mit mehr als einer übergeordneten Entität verknüpft ist.
• Implementierung- die Beziehung zwischen der Entität, die die Spezifikation des Verhaltens definiert (Schnittstelle) mit der Entität, die die Implementierung dieses Verhaltens definiert (Klasse, Komponente). Diese Beziehung wird häufig in der Komponentenmodellierung verwendet und wird in nachfolgenden Artikeln ausführlicher beschrieben.

Diagramme. Die UML bietet die folgenden Diagramme:

• Diagramme, die das Systemverhalten beschreiben:
• Zustandsdiagramme,
• Aktivitätsdiagramme,
• Objektdiagramme,
• Sequenzdiagramme,
• Kooperationsdiagramme
• Diagramme, die die physische Implementierung des Systems beschreiben:
• Komponentendiagramme
• Bereitstellungsdiagramme

Ansicht der Modellsteuerung. Pakete.

Wir haben bereits gesagt, dass es notwendig ist, ein Modell hierarchisch zu organisieren, damit ein Modell von einer Person gut verstanden wird, wobei auf jeder Hierarchieebene eine kleine Anzahl von Entitäten belassen wird. UML enthält ein Mittel zum Organisieren einer hierarchischen Darstellung eines Modells – Pakete. Jedes Modell besteht aus einer Reihe von Paketen, die Klassen, Anwendungsfälle und andere Entitäten und Diagramme enthalten können. Ein Paket kann andere Pakete enthalten, um Hierarchien zu erstellen. In der UML gibt es keine separaten Paketdiagramme, sie können jedoch in anderen Diagrammen erscheinen. Das Paket wird als Rechteck mit einer Registerkarte angezeigt.

Was die UML bietet.

• eine hierarchische Beschreibung eines komplexen Systems durch Zuweisen von Paketen;
• Formalisierung der funktionalen Anforderungen an das System unter Verwendung der Apparatur von Anwendungsfällen;
• Detaillierung der Anforderungen an das System durch Erstellen von Diagrammen von Aktivitäten und Szenarien;
• Hervorheben von Datenklassen und Erstellen eines konzeptionellen Datenmodells in Form von Klassendiagrammen;
• Hervorheben der Klassen, die die Benutzeroberfläche beschreiben, und Erstellen eines Bildschirmnavigationsschemas;
• eine Beschreibung der Interaktionsprozesse von Objekten bei der Ausführung von Systemfunktionen;
• Beschreibung des Verhaltens von Objekten in Form von Diagrammen von Aktivitäten und Zuständen;
• Beschreibung von Softwarekomponenten und deren Interaktion über Schnittstellen;
• eine Beschreibung der physikalischen Architektur des Systems.

Und der letzte ...

Trotz aller Attraktivität von UML wäre es ohne visuelle Modellierungswerkzeuge schwierig, sie in der realen Softwaremodellierung zu verwenden. Mit solchen Tools können Sie Diagramme schnell auf dem Bildschirm präsentieren, dokumentieren, leere Programmcodes in verschiedenen OO-Programmiersprachen generieren und Datenbankschemata erstellen. Die meisten von ihnen beinhalten die Möglichkeit des Reengineering von Programmcodes - das Wiederherstellen bestimmter Projektionen des SS-Modells durch automatische Analyse des Quellcodes von Programmen, was sehr wichtig ist, um die Konsistenz des Modells und des Codes zu gewährleisten und wenn Systeme entworfen werden, die die Funktionalität des Vorgängers übernehmen Systeme.