Zeigen Sie das Verhalten eines Objekts während seines Lebens, von der Entstehung des Objekts bis zu seiner Zerstörung. Jedes Zustandsdiagramm repräsentiert einen Automaten.

Aktionsplan

Im Abschnitt „Beschreibung“ lernen Sie den grundlegenden Satz an Zustandsdiagrammsymbolen kennen, die zum Lesen von Diagrammen erforderlich sind.

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

Notizen (Beschreibung)

Hier ist der grundlegende Zeichensatz Zustandsdiagramme, notwendig, um das Diagramm lesen zu können. Nachdem Sie die anderen Abschnitte („Beispiel“, „Anwendung“) gelesen haben, können Sie verfassen Zustandsdiagramme auf sich allein!

Begriff	Bild	Beschreibung
Anfänglicher Pseudozustand		Ausgangszustand des Systems
Übergang		Übergang bedeutet den Übergang von einem Zustand in einen anderen.
Zustand		Identifiziert vom System ausgeführte Aktionen (z. B Möglichkeiten), was zu für die Akteure beobachtbaren Ergebnissen führt.
Zustand Aktivitätsstatus		Ein schwieriger Schritt in einem Präzedenzfall kann durch einen anderen Präzedenzfall dargestellt werden. In UML-Begriffen sagen wir, dass der erste Anwendungsfall den zweiten einschließt.
Endgültiger Zustand		Ermöglicht Ihnen, die Grenzen von Systemen oder Subsystemen zu definieren.
Interne Aktivitäten		Der Fall, in dem Staaten auf Ereignisse reagieren können, ohne einen Übergang durchzuführen. In diesem Fall werden Ereignis, Schutz und Aktivität innerhalb des Statusrechtecks ​​platziert.
Eingabeaktivität		Die Eingabeaktivität wird immer dann ausgeführt, wenn Sie einen Zustand betreten
Ausgabeaktivität		Exit-Aktivität – Wird immer dann ausgeführt, wenn Sie den Staat verlassen.
Superstaat		Es kommt häufig vor, dass mehrere Staaten gemeinsame Übergänge und interne Aktivitäten haben. In solchen Fällen können sie in Unterzustände umgewandelt werden und das Gesamtverhalten kann auf einen Oberzustand übertragen werden.
Parallelstaaten		Zustände können in mehrere parallele Zustände aufgeteilt werden, die gleichzeitig laufen.

Wie man Kreativitätstechniken nutzt

UML-Zustandsdiagramme eignen sich gut zur Beschreibung des Verhaltens eines einzelnen Objekts über mehrere Anwendungsfälle hinweg. Für die Beschreibung von Verhalten, das durch die Interaktion vieler Objekte gekennzeichnet ist, sind sie jedoch wenig geeignet. Daher ist es sinnvoll, auch andere Technologien in Verbindung mit Zustandsdiagrammen einzusetzen. Interaktionsdiagramme (Kapitel 4) eignen sich beispielsweise hervorragend zur Beschreibung des Verhaltens mehrerer Objekte in einem einzelnen Anwendungsfall, ebenso wie UML-Aktivitätsdiagramme eignen sich gut dazu, den grundsätzlichen Handlungsablauf mehrerer Objekte in mehreren Anwendungsfällen darzustellen.

Nicht jeder hält Zustandsdiagramme für selbstverständlich. Sehen Sie, wie Experten mit ihnen arbeiten. Es ist möglich, dass Ihre Teammitglieder nicht glauben, dass Statecharts für ihren Arbeitsstil geeignet sind. Dies ist nicht die größte Schwierigkeit; Sie müssen daran denken, verschiedene Arbeitstechniken gemeinsam anzuwenden.

Wenn Sie Zustandsdiagramme verwenden, versuchen Sie nicht, diese für jede Klasse des Systems zu zeichnen. Dieser Ansatz wird oft aus Gründen der formalen Vollständigkeit verwendet, ist aber fast immer eine Zeitverschwendung. Verwenden Sie Zustandsdiagramme nur für Klassen, die ein interessantes Verhalten aufweisen und bei denen das Zeichnen eines Zustandsdiagramms Ihnen hilft, zu verstehen, wie Dinge passieren.

Das glauben viele Experten Der UI-Editor und die Steuerobjekte 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 zur Beschreibung eine Reihe von Symbolen. Die Bedeutung dieser Zeichen finden Sie in der Tabelle im Abschnitt „Hinweise (Beschreibung)“. Jedes Zeichen hat seinen eigenen Namen (Begriff) und seine eigene Schreibweise. Außerdem wird jeder Begriff mit einer kurzen Erklärung versehen, um sein grundlegendes Wesen schnell zu verstehen.

Als nächstes empfehlen wir Ihnen, zum Abschnitt „Beispiele“ zu gehen Zustandsdiagramme um zu versuchen, verschiedene Diagramme zu lesen. Dann lohnt es sich, den Abschnitt „Anwendung“ zu studieren, denn obwohl die Anzahl der Diagrammtypen in UML gering ist, können Sie den maximalen Nutzen aus deren Verwendung nur dann ziehen, wenn Sie die entsprechenden Diagramme bestimmungsgemäß 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 zur Darstellung des Verhaltens eines Systems verwendet. Bei objektorientierten Ansätzen zeichnen Sie ein Zustandsdiagramm einer einzelnen Klasse, um das Verhalten eines einzelnen Objekts über seine Lebensdauer hinweg darzustellen.

Wann immer über endliche Automaten geschrieben wird, sind die Beispiele zwangsläufig Tempomatsysteme oder Verkaufsautomaten.
Wir entschieden uns für den Einsatz eines geheimen Bedienfeld-Controllers in einem gotischen Schloss. In diesem Schloss wollen wir unsere Schätze verstecken, damit sie schwer zu finden sind. Um an das Schloss des Safes zu gelangen, müssen wir die strategische Kerze aus dem Kandelaber entfernen, aber das Schloss erscheint nur, wenn die Tür geschlossen ist. Nachdem das Schloss erscheint, können wir den Schlüssel hineinstecken und den Safe öffnen. Für zusätzliche Sicherheit haben wir es so gestaltet, dass der Tresor erst geöffnet werden kann, nachdem die Kerze entfernt wurde. Wenn der Dieb diese Vorsichtsmaßnahme nicht beachtet, werden wir ein widerliches Monster freilassen, das den Dieb verschlingen wird.

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

Übergang bedeutet den Übergang von einem Zustand in einen anderen. Jeder Übergang hat eine eigene Bezeichnung, die aus drei Teilen besteht:
Trigger-Signatur/Aktivität. Alle davon sind optional. Allgemein, Trigger-ID ist das einzige Ereignis, das eine Zustandsänderung bewirken kann.

Der Schutz, sofern angegeben, ist eine logische Bedingung, die erfüllt sein muss, damit der Übergang stattfindet. Aktivität ist ein Verhalten des Systems während eines Übergangs. Dies kann jeder Verhaltensausdruck sein. Die vollständige Form eines ID-Triggers kann mehrere Ereignisse und Parameter umfassen. Der Übergang vom Wartezustand (Abb. 10.1) in einen anderen Zustand kann wie folgt gelesen werden: „Wenn im Wartezustand die Kerze entfernt wird, sehen Sie eine Sperre und wechseln in den Sperrzustand.“

Alle drei Teile der Übergangsbeschreibung sind optional. Das Überspringen von Aktivitäten bedeutet, dass während des Übergangs nichts passiert. „Abschirmungen überspringen“ bedeutet, dass der Übergang immer dann erfolgt, wenn ein Triggerereignis auftritt. Die Trigger-ID fehlt selten, kommt aber vor. Dies bedeutet, dass der Übergang sofort erfolgt, was hauptsächlich in aktiven Zuständen beobachtet werden kann.

Wenn ein Ereignis in einem bestimmten Zustand auftritt, kann aus diesem Zustand nur ein Übergang erfolgen, beispielsweise im Sperrzustand (Abb. 10.1), müssen sich die Schutzmaßnahmen gegenseitig ausschließen. Wenn ein Ereignis eintritt, es aber keine zulässigen Übergänge gibt – zum Beispiel das Schließen eines Safes im Wartezustand oder das Entfernen einer Kerze, wenn offene Tür, – Das Ereignis wird ignoriert.

Endgültiger Zustand ( Endzustand) bedeutet, dass die Ausführung der Zustandsmaschine abgeschlossen ist, wodurch das Controller-Objekt gelöscht wird. Für diejenigen, die unvorsichtig genug waren, in die Falle zu tappen: Da das Controller-Objekt nicht mehr existiert, sind wir gezwungen, das Kaninchen wieder in den Käfig zu stecken, den Boden zu wischen und das System neu zu starten.

Denken Sie daran, dass Zustandsmaschinen nur Objekte anzeigen können, die direkt beobachtet oder bearbeitet werden. Während Sie also erwarten könnten, dass wir bei geöffneter Tür etwas in den Safe hineinlegen oder etwas herausnehmen, haben wir dies im Diagramm nicht markiert, da der Controller uns darüber nichts sagen kann.

Wenn Entwickler über Objekte sprechen, beziehen sie sich oft auf den Zustand der Objekte, also auf die Kombination aller in den Feldern der Objekte enthaltenen Daten. Allerdings ist ein Zustand in einem Zustandsmaschinendiagramm ein abstrakteres Zustandskonzept; Der Punkt ist, dass die verschiedenen Staaten implizieren verschiedene Wege Reaktionen auf Ereignisse.

Interne Aktivitäten in einem Statechart

Staaten können auf Ereignisse reagieren, ohne einen Übergang durchzuführen interne Aktivitäten (interne Aktivitäten), wobei Ereignis, Schutz und Aktivität innerhalb des Statusrechtecks ​​platziert werden.

In Abb. 10.2 zeigt den Zustand mit internen Symbolaktivitäten und Hilfesystemereignissen, die Sie beobachten können Textfelder Editor Benutzeroberfläche. Interne Aktivität ist wie ein Selbstübergang – ein Übergang, der in den gleichen Zustand zurückkehrt. Die Syntax interner Aktivitäten basiert auf dem gleichen logischen Schema von Ereignissen, Schutzmaßnahmen und Verfahren.

In Abb. 10.2 zeigt auch besondere Aktivitäten: Input- und Output-Aktivitäten. Eingabeaktivität wird jedes Mal ausgeführt, wenn Sie einen Zustand betreten; Ausgabeaktivität- wann immer Sie den Staat verlassen. Interne Aktivitäten werden jedoch nicht initiiert Input- und Output-Aktivitäten; das ist der Unterschied zwischen interne Aktivitäten undSelbstübergänge .

Aktivitätszustände in einem Zustandsdiagramm

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

Zustand Suchen in Abb. 10.3 ist ein solcher Zustand Aktivitätsstatus: Laufende Aktivität wird durch ein Symbol angezeigt Tun/; daher der Begriff Do-Aktivität (aktiv sein). Nach Abschluss der Suche werden Übergänge ohne Aktivität durchgeführt, z. B. das Anzeigen neuer Geräte (Neue Hardware anzeigen). Tritt während einer Aktivität ein Abbruchereignis auf ( stornieren), Das Do-Aktivität unterbricht einfach und wir kehren zum Zustand zurück Fenster „Hardware aktualisieren“.

Sowohl Do-Aktivitäten als auch gewöhnliche Aktivitäten stellen die Manifestation eines bestimmten Verhaltens dar. Der entscheidende Unterschied zwischen beiden besteht darin, dass normale Aktivitäten „augenblicklich“ stattfinden und nicht durch normale Ereignisse unterbrochen werden können, wohingegen Aktivitäten für eine begrenzte Zeit ausgeführt und unterbrochen werden können, wie in Abbildung 1 dargestellt. 10.3. Die Instantanität wird für verschiedene Systeme unterschiedlich interpretiert; Bei Echtzeitsystemen kann dies mehrere Maschinenanweisungen erfordern und bei Desktop-Software kann es mehrere Sekunden dauern.

IN UML 1 Mit dem Begriff wurden gewöhnliche Tätigkeiten bezeichnet Aktion(Aktion) und der Begriff Aktivität(Aktivität) wurde nur für verwendet Do-Aktivitäten.

Superstaaten

Es kommt häufig vor, dass mehrere Staaten gemeinsame Übergänge und interne Aktivitäten haben. In solchen Fällen können sie in Unterzustände umgewandelt werden und das Gesamtverhalten kann auf einen Oberzustand übertragen werden, wie in Abb. 10.4. Ohne einen Superstaat müssten wir einen Übergang ziehen stornieren(Abbrechen) für alle drei Staaten innerhalb eines Staates Geben Sie die Verbindungsdetails ein.

Parallelstaaten

Zustände können in mehrere parallele Zustände aufgeteilt werden, die gleichzeitig laufen. In Abb. Abbildung 10.5 zeigt einen einfachen Wecker, der entweder eine CD oder ein Radio einschalten und entweder die aktuelle Uhrzeit oder die Weckzeit anzeigen kann.

Die Optionen CD/Radio und Aktuelle Uhrzeit/Alarmzeit sind parallel. Wenn Sie dies mithilfe eines nichtparallelen Zustandsdiagramms darstellen wollten, würden Sie beim Hinzufügen von Zuständen ein unordentliches Diagramm erhalten. Die Trennung der beiden Verhaltensbereiche in zwei Zustandsdiagramme macht es viel klarer.

Reis. 10.5 beinhaltet auch Stand der Vorgeschichte(Geschichtspseudozustand). Dies bedeutet, dass die Radio-/CD-Option beim Einschalten der Uhr in den Zustand wechselt, in dem sich die Uhr beim Ausschalten befand. Der aus der Vorgeschichte kommende Pfeil zeigt, welcher Zustand ursprünglich existierte, als es keine Vorgeschichte gab.

Implementierung von Statecharts

Ein Zustandsdiagramm kann im Wesentlichen auf drei Arten implementiert werden: mithilfe einer verschachtelten Switch-Anweisung, eines Zustandsmusters und einer Zustandstabelle. Der direkteste Ansatz für die Arbeit mit Zustandsdiagrammen ist eine verschachtelte Switch-Anweisung, wie in Abb. 10.6.

Obwohl diese Methode unkompliziert ist, ist sie selbst für diesen einfachen Fall sehr langwierig. Darüber hinaus kann es bei diesem Ansatz sehr leicht zu einem Kontrollverlust kommen, daher empfehlen wir, ihn auch in elementaren Situationen nicht anzuwenden.
Das Zustandsmuster stellt eine Hierarchie von Zustandsklassen zur Handhabung des Zustandsverhaltens dar. Jeder Zustand in einem Zustandsdiagramm hat seine eigene Unterklasse von Zuständen. Der Controller verfügt für jedes Ereignis über Methoden, die einfach an die Zustandsklasse weiterleiten. Das Zustandsdiagramm in Abb. 10.1 könnte mit den in Abb. dargestellten Klassen implementiert werden. 10.7.

An der Spitze der Hierarchie steht eine abstrakte Klasse, die eine Beschreibung aller Methoden enthält, die Ereignisse verarbeiten, jedoch ohne Implementierung.
Für jeden spezifischen Zustand reicht es aus, die Handler-Methode für ein bestimmtes Ereignis neu zu schreiben, das einen Übergang vom Zustand aus initiiert.
Eine Zustandstabelle stellt ein Zustandsdiagramm als Daten dar.

Das Diagramm in Abb. 10.1 kann in tabellarischer Form dargestellt werden. 10.1.
Anschließend erstellen wir einen Interpreter, der die Laufzeitstatustabelle verwendet, oder einen Codegenerator, der Klassen aus dieser Tabelle generiert.

Offensichtlich wird die meiste Arbeit an der Zustandstabelle einmal erledigt, sie kann dann jedoch immer dann verwendet werden, wenn ein Zustandsproblem gelöst werden muss. Die Laufzeitstatustabelle kann ohne Neukompilierung geändert werden, was einigermaßen praktisch ist. Die Statusvorlage lässt sich einfacher zusammenstellen, und obwohl für jeden Status eine separate Klasse erforderlich ist, ist die Menge an Code, die geschrieben werden muss, recht gering.

Die gezeigten Implementierungen sind fast minimal, geben aber 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 besser, auf irgendeine Form der Codegenerierung zurückzugreifen, um dies zu erreichen.

Abonnieren Sie die Neuigkeiten der Website. Das Abonnementformular finden Sie in der rechten Spalte der Website.

Wenn Sie lernen möchten, wie man als Freelancer professionell arbeitet, laden wir Sie zum „“-Kurs ein.

        Unified Modeling Language (UML) ist eine Sprache zur Spezifikation, Visualisierung, Design und Dokumentation Softwaresysteme sowie Geschäftsmodelle und andere Nicht-Software-Systeme. UML ist eine Kombination von Ingenieurtechniken, die bereits erfolgreich zur Modellierung großer und komplexer Systeme eingesetzt wurden

        Die Schöpfer von UML präsentieren es als eine Sprache zum Definieren, Darstellen, Entwerfen und Dokumentieren von Softwaresystemen, Geschäftssystemen und anderen Systemen unterschiedlicher Art. UML definiert eine Notation und ein Metamodell. Notation ist eine Sammlung grafischer Objekte, die in Modellen verwendet werden; es ist die Syntax der Modellierungssprache.

        UML bietet ausdrucksstarke Werkzeuge zum Erstellen visuelle Modelle, welche:

• werden von allen am Projekt beteiligten Entwicklern einheitlich verstanden;
• sind ein Kommunikationsmittel innerhalb des Projekts.

        Unified Modeling Language (UML):

• hängt nicht von objektorientierten (OO) Programmiersprachen ab;
• hängt nicht von der verwendeten Projektentwicklungsmethodik ab;
• kann jede OO-Programmiersprache unterstützen.

        UML ist offen und verfügt über Tools zur Erweiterung des Basiskerns. UML kann zur sinnvollen Beschreibung von Klassen, Objekten und Komponenten in verschiedenen Fachbereichen verwendet werden, die sich häufig stark voneinander unterscheiden.

UML-Diagramme

        Rational Rose stellt dem Systemdesigner die folgenden Arten von Diagrammen zur Verfügung, deren sequentielle Erstellung es Ihnen ermöglicht, ein vollständiges Bild des gesamten entworfenen Systems und seiner einzelnen Komponenten zu erhalten:

• Anwendungsfalldiagramm;
• Bereitstellungsdiagramm (Topologiediagramme);
• Statechart-Diagramm;
• Interaktionsdiagramm; Aktivitätsdiagramm;
• Sequenzdiagramm;
• Kollaborationsdiagramm;
• Klassen Diagramm;
• Komponentendiagramm (Komponentendiagramme);
• Verhaltensdiagramme;
• Aktivitätsdiagramm;
• Implementierungsdiagramme;

        Jedes dieser Diagramme spezifiziert unterschiedliche Vorstellungen über das Systemmodell. Gleichzeitig stellt das Anwendungsfalldiagramm ein konzeptionelles Modell des Systems dar, das den Ausgangspunkt für die Konstruktion aller anderen Diagramme bildet. Ein Klassendiagramm ist ein logisches Modell, das die statischen Aspekte des strukturellen Designs eines Systems widerspiegelt, und Verhaltensdiagramme, die ebenfalls Arten eines logischen Modells sind, spiegeln die dynamischen Aspekte seiner Funktionsweise wider. Implementierungsdiagramme dienen der Darstellung der Komponenten eines Systems und verweisen auf dessen physikalisches Modell.

        Von den oben aufgeführten Diagrammen dienen einige zur Bezeichnung von zwei oder mehr Unterarten. Als eigenständige Darstellungen werden folgende Diagramme verwendet: Anwendungsfälle, Klassen, Zustände, Aktivitäten, Abläufe, Kooperation, Komponenten und Einsatz.

        Für UML-Diagramme gibt es drei Arten von visuellen Symbolen, die im Hinblick auf die darin enthaltenen Informationen wichtig sind:

• Kommunikation, die durch verschiedene Linien in der Ebene dargestellt werden;
• Text, innerhalb der Grenzen einzelner geometrischer Formen enthalten;
• grafische Symbole, neben den visuellen Elementen der Diagramme dargestellt.

        Bei der grafischen Darstellung von Diagrammen empfiehlt es sich, folgende Regeln einzuhalten:

• jedes Diagramm muss eine vollständige Darstellung eines Fragments des modellierten Themenbereichs sein;
• Die im Diagramm dargestellten Modelleinheiten müssen auf derselben konzeptionellen Ebene sein.
• alle Informationen über Entitäten müssen im Diagramm klar dargestellt werden;
• Diagramme sollten keine widersprüchlichen Informationen enthalten;
• Diagramme sollten nicht mit Textinformationen überladen werden;
• Jedes Diagramm muss für die korrekte Interpretation aller seiner Elemente autark sein.
• Die Anzahl der Diagrammtypen, die zur Beschreibung eines bestimmten Systems erforderlich sind, ist nicht streng festgelegt und wird vom Entwickler festgelegt.
• Systemmodelle sollten nur die Elemente enthalten, die in der UML-Notation definiert sind.

Entitäten in UML

        In UML sind vier Arten von Entitäten definiert: Struktur, Verhalten, Gruppierung und Anmerkung. Entitäten sind die wichtigsten objektorientierten Elemente der Sprache, mit denen Modelle erstellt werden.

        Strukturelle Einheiten sind Substantive in UML-Modellen. Typischerweise stellen sie statische Teile des Modells dar, die konzeptionellen oder physikalischen Elementen des Systems entsprechen. Beispiele für Struktureinheiten sind „Klasse“, „Schnittstelle“, „Kollaboration“, „Anwendungsfall“, „Komponente“, „Knoten“, „Akteur“.

        Verhaltensentitäten sind dynamische Komponenten des UML-Modells. Dies sind Verben, die das Verhalten des Modells in Zeit und Raum beschreiben. Es gibt zwei Haupttypen von Verhaltensentitäten:

• Interaktion ist Verhalten, dessen Kern der Austausch von Nachrichten zwischen Objekten in einem bestimmten Kontext ist, um ein bestimmtes Ziel zu erreichen;
• Automat – ein Verhaltensalgorithmus, der eine Folge von Zuständen definiert, die ein Objekt oder eine Interaktion als Reaktion auf verschiedene Ereignisse durchläuft.

        Gruppieren von Entitäten sind die organisierenden Teile des UML-Modells. Dabei handelt es sich um Blöcke, in die das Modell zerlegt werden kann. Eine solche primäre Entität existiert in einer einzigen Kopie – dies ist ein Paket.

        Pakete sind ein universeller Mechanismus zum Organisieren von Elementen in Gruppen. Struktur-, Verhaltens- und andere Gruppierungseinheiten können in einem Paket platziert werden. Im Gegensatz zu Komponenten, die tatsächlich existieren, während das Programm läuft, sind Pakete rein konzeptioneller Natur, das heißt, sie existieren nur während des Entwicklungsprozesses.

        Anmerkungsobjekte- Dies sind die erklärenden Teile des UML-Modells: Kommentare zur zusätzlichen Beschreibung, Klarstellung oder Anmerkungen zu einem beliebigen Element des Modells. Es gibt nur eins Grundtyp Anmerkungselemente - Hinweis. Notizen werden verwendet, um Diagramme mit Kommentaren oder Einschränkungen zu versehen, ausgedrückt in informellem oder formellem Text.

Beziehungen in UML

        Die folgenden Arten von Beziehungen sind in der UML-Sprache definiert: Abhängigkeit, Assoziation, Verallgemeinerung und Implementierung. Diese Beziehungen sind die wichtigsten Verbindungskonstrukte der UML und werden auch als Entitäten zum Aufbau von Modellen verwendet.

        Abhängigkeit- Dies ist eine semantische Beziehung zwischen zwei Entitäten, bei der eine Änderung in einer von ihnen, unabhängig, die Semantik der anderen, abhängigen, beeinflussen kann.

        Verband– eine strukturelle Beziehung, die eine Reihe semantischer oder logischer Verbindungen zwischen Objekten beschreibt.

        Verallgemeinerung ist eine Beziehung, in der ein generisches Elementobjekt (Vorfahr) durch ein spezialisiertes Elementobjekt (Nachkomme) ersetzt werden kann. Gleichzeitig erbt ein Nachkomme (Kind) gemäß den Prinzipien der objektorientierten Programmierung die Struktur und das Verhalten seines Vorfahren (Elternteil).

        Realisierung ist eine semantische Beziehung zwischen Klassifikatoren, bei der ein Klassifikator eine Verpflichtung definiert und der andere deren Erfüllung garantiert. Implementierungsbeziehungen treten in zwei Fällen auf:

• zwischen Schnittstellen und den Klassen oder Komponenten, die sie implementieren;
• zwischen Präzedenzfällen und den Kooperationen, die sie umsetzen.

Gemeinsame UML-Mechanismen

        Um ein System in UML genau zu beschreiben, werden sogenannte allgemeine Mechanismen verwendet:

• Spezifikationen;
• Ergänzungen (Verzierungen);
• gemeinsame Spaltungen;
• Erweiterungen (Erweiterbarkeitsmechanismen).

        UML ist nicht nur eine grafische Sprache. Hinter jedem grafischen Element steht seine Notation Spezifikation, enthält eine Textdarstellung des entsprechenden Sprachkonstrukts. Beispielsweise verfügt ein Symbol für eine Klasse über eine Spezifikation, die deren Attribute, Operationen und Verhalten beschreibt, obwohl das Symbol in einem Diagramm visuell oft nur einen kleinen Teil dieser Informationen widerspiegelt. Darüber hinaus kann das Modell eine andere Darstellung dieser Klasse enthalten, die völlig unterschiedliche Aspekte davon widerspiegelt, aber dennoch mit der Spezifikation übereinstimmt. Daher wird die grafische UML-Notation zur Visualisierung des Systems und die Verwendung von Spezifikationen zur Beschreibung seiner Details verwendet.

        Fast jedes UML-Element verfügt über eine einzigartige grafische Darstellung, die eine visuelle Darstellung seiner wichtigsten Eigenschaften bietet. Die Entitätsnotation „Klasse“ enthält ihren Namen, ihre Attribute und Operationen. Die Klassenspezifikation kann weitere Details enthalten, beispielsweise die Sichtbarkeit von Attributen und Operationen, Kommentare oder einen Hinweis darauf, dass die Klasse abstrakt ist. Viele dieser Details können als Grafiken oder Text visualisiert werden. Ergänzungen zu einem Standardrechteck, das die Klasse darstellt.

        Bei der Modellierung objektorientierter Systeme gibt es eine gewisse Aufteilung vertretene Einheiten.

        Zunächst gibt es eine Unterteilung in Klassen und Objekte. Eine Klasse ist eine Abstraktion und ein Objekt ist eine konkrete Verkörperung dieser Abstraktion. In dieser Hinsicht zeichnen sich fast alle Sprachkonstrukte durch eine Klasse/Objekt-Dualität aus. Somit gibt es Präzedenzfälle und Instanzen von Präzedenzfällen, Komponenten und Instanzen von Komponenten, Knoten und Instanzen von Knoten. In einer grafischen Darstellung ist es üblich, für ein Objekt dasselbe Symbol wie für eine Klasse zu verwenden und den Namen zu unterstreichen.

        Zweitens gibt es eine Unterteilung in eine Schnittstelle und deren Implementierung. Eine Schnittstelle deklariert Verpflichtungen, und eine Implementierung stellt die konkrete Implementierung dieser Verpflichtungen dar und stellt sicher, dass die deklarierte Semantik genau befolgt wird. Aus diesem Grund zeichnen sich fast alle UML-Konstrukte durch eine Schnittstelle/Implementierung-Dualität aus. Beispielsweise werden Präzedenzfälle durch Kooperationen und Operationen durch Methoden umgesetzt.

        UML ist eine offene Sprache, das heißt, sie ermöglicht kontrollierte Erweiterungen, um die Merkmale von Domänenmodellen widerzuspiegeln.

Zu den UML-Erweiterungsmechanismen gehören:

• Stereotypen (Stereotyp) – Erweitern Sie das UML-Vokabular und ermöglichen Sie die Erstellung neuer Stereotypen auf der Grundlage vorhandener Sprachelemente, die sich auf die Lösung eines bestimmten Problems konzentrieren.
• markierte Werte – erweitern die Eigenschaften grundlegender UML-Konstrukte und ermöglichen die Aufnahme zusätzlicher Informationen in die Elementspezifikation;
• Einschränkungen (Einschränkungen) – Erweitern Sie die Semantik von UML-Konstrukten, sodass Sie neue Regeln erstellen und bestehende aufheben können.

        Zusammen ermöglichen Ihnen diese drei Spracherweiterungsmechanismen, sie entsprechend den Anforderungen des Projekts oder den Merkmalen der Entwicklungstechnologie zu ändern.

Anwendungsfalldiagramm

        Mit diesem Diagrammtyp können Sie eine Liste der Vorgänge erstellen, die das System ausführt. Diese Art von Diagramm wird häufig als Funktionsdiagramm bezeichnet, da auf der Grundlage einer Reihe solcher Diagramme eine Liste von Anforderungen an das System erstellt und die Menge der vom System ausgeführten Funktionen bestimmt wird.

        Anwendungsfalldiagramme beschreiben die Funktionalität eines Systems oder was das System tun soll. Die Entwicklung des Diagramms hat folgende Ziele:

• Bestimmen Sie die allgemeinen Grenzen und den Kontext des modellierten Themenbereichs.
• allgemeine Anforderungen an das Funktionsverhalten des entworfenen Systems formulieren;
• ein erstes konzeptionelles Modell des Systems für seine anschließende Detaillierung in Form logischer und physikalischer Modelle entwickeln;
• Erstellen Sie eine Erstdokumentation für die Interaktion der Systementwickler mit ihren Kunden und Benutzern.

        Das Wesentliche des Anwendungsfalldiagramms ist wie folgt. Das entworfene System wird als eine Reihe von Entitäten oder Akteuren dargestellt, die über Anwendungsfälle mit dem System interagieren. In diesem Fall ist ein Akteur oder Akteur jede Entität, die von außen mit dem System interagiert. Es könnte eine Person sein technisches Gerät, Programm oder jedes andere System, das als Einflussquelle auf das simulierte System dienen kann, wie vom Entwickler selbst bestimmt. Anwendungsfall dient dazu, die Dienste zu beschreiben, die das System dem Akteur bereitstellt.

        Der Zweck eines Anwendungsfalls besteht darin, einen vollständigen Aspekt oder ein Fragment des Verhaltens einer Entität zu definieren, ohne deren interne Struktur preiszugeben. Eine solche Entität kann ein System oder ein beliebiges Element des Modells sein, das sein eigenes Verhalten aufweist.

        Jeder Anwendungsfall entspricht einem separaten Dienst, den die modellierte Entität auf Anfrage des Akteurs bereitstellt, d. h. er bestimmt, wie diese Entität verwendet wird. Ein Dienst, der auf Anfrage eines Akteurs initialisiert wird, ist eine vollständige, unteilbare Abfolge von Aktionen. Das heißt, nachdem das System die Bearbeitung der Anfrage abgeschlossen hat, muss es zu zurückkehren der Ausgangszustand um für die folgenden Anfragen bereit zu sein

        Anwendungsfälle können sowohl zur Festlegung externer Anforderungen an das zu entwerfende System als auch zur Festlegung des funktionalen Verhaltens bereits verwendeter Systeme verwendet werden bestehendes System. Die Gesamtheit der Anwendungsfälle sollte alle möglichen Aspekte des erwarteten Verhaltens des Systems definieren. Darüber hinaus stellen Use Cases implizit Anforderungen dar, die definieren, wie Akteure mit dem System interagieren müssen, um die bereitgestellten Dienste korrekt betreiben zu können. Der Einfachheit halber können viele Anwendungsfälle als separates Paket behandelt werden.

        Beispiele für Anwendungsfälle können folgende Aktionen sein: Überprüfen des Status des Girokontos des Kunden, Erteilen einer Bestellung zum Kauf von Waren, Einholen zusätzlicher Informationen über die Kreditwürdigkeit des Kunden, Anzeigen eines grafischen Formulars auf dem Bildschirm und andere Aktionen.

Klassen Diagramm

        Der zentrale Punkt in der objektorientierten Programmierung ist die Entwicklung eines logischen Modells des Systems in Form eines Klassendiagramms. Ein Klassendiagramm dient zur Darstellung der statischen Struktur eines Systemmodells in der Terminologie objektorientierter Programmierklassen. Ein Klassendiagramm kann insbesondere verschiedene Beziehungen zwischen einzelnen Domänenentitäten wie Objekten und Subsystemen abbilden sowie deren interne Struktur und Beziehungsarten beschreiben.

        Diagrammsymbole ermöglichen Ihnen die Anzeige einer komplexen Hierarchie von Systemen, Beziehungen zwischen Klassen (Klassen) und Schnittstellen (Schnittstellen). Dieser Diagrammtyp ist inhaltlich das Gegenteil des Kollaborationsdiagramms, das Systemobjekte anzeigt. Mit Rational Rose können Sie Klassen erstellen, die diesen Diagrammtyp in verschiedenen Notationen verwenden. ähnlich einer Wolke. Somit ist eine Klasse lediglich eine Vorlage, nach der in Zukunft ein bestimmtes Objekt erstellt wird.

        Ein Klassendiagramm ist ein Graph, dessen Scheitelpunkte verbundene Elemente vom Typ „Klassifikator“ sind verschiedene Arten Strukturelle Beziehungen. Ein Klassendiagramm kann auch Schnittstellen, Pakete, Beziehungen und sogar einzelne Instanzen wie Objekte und Beziehungen enthalten.

        Klasse In UML wird es verwendet, um eine Menge von Objekten zu bezeichnen, die die gleiche Struktur, das gleiche Verhalten und die gleichen Beziehungen zu Objekten anderer Klassen haben. Grafisch wird die Klasse als Rechteck dargestellt, das zusätzlich geteilt werden kann horizontale Linien in Abschnitte oder Abschnitte. Diese Abschnitte können den Klassennamen, Attribute (Variablen) und Operationen (Methoden) enthalten.

Zustandsdiagramm

        Jedes Zustandsdiagramm in UML beschreibt alle möglichen Zustände einer Instanz einer bestimmten Klasse und mögliche Abfolgen ihrer Übergänge von einem Zustand in einen anderen, d. h. es modelliert alle Zustandsänderungen eines Objekts als seine Reaktion auf externe Einflüsse.

Zustandsdiagramme werden am häufigsten zur Beschreibung des Verhaltens einzelner Objekte verwendet, können aber auch zur Angabe der Funktionalität anderer Modellkomponenten wie Anwendungsfälle, Akteure, Subsysteme, Operationen und Methoden verwendet werden.

        Ein Zustandsdiagramm ist eine spezielle Art von Graph, der einen bestimmten Automaten darstellt. Die Eckpunkte des Diagramms sind die möglichen Zustände der Maschine, dargestellt durch die entsprechenden Grafiksymbole, und die Bögen zeigen ihre Übergänge von Zustand zu Zustand an. Zustandsdiagramme können verschachtelt werden, um eine detailliertere Darstellung einzelner Modellelemente zu ermöglichen.

        Im UML-Metamodell Maschine ist ein Paket, das viele Konzepte definiert, die erforderlich sind, um das Verhalten der modellierten Entität in Form eines diskreten Raums mit einer endlichen Anzahl von Zuständen und Übergängen darzustellen.

        Die Dauer, in der sich das System in einem der möglichen Zustände befindet, übersteigt die Zeit, die für den Übergang von einem Zustand in einen anderen aufgewendet wird, erheblich. Es wird davon ausgegangen, dass im Grenzfall die Übergangszeit gleich Null sein kann (sofern nicht anders angegeben), d. h. die Änderung der Objektzustände kann sofort erfolgen.

        Das Verhalten des Automaten wird als sequentielle Bewegung entlang des Graphen von Scheitelpunkt zu Scheitelpunkt modelliert, wobei die Ausrichtung der sie verbindenden Bögen berücksichtigt wird.

        Für die Maschine müssen folgende zwingende Bedingungen erfüllt sein:

• Der Zustand, in den ein Objekt gelangen kann, wird nur durch seinen aktuellen Zustand bestimmt und hängt nicht von seiner Vorgeschichte ab.
• Zu jedem Zeitpunkt kann sich der Automat nur in einem seiner Zustände befinden. Gleichzeitig kann der Automat beliebig lange in einem separaten Zustand bleiben, wenn keine Ereignisse eintreten;
• Die Zeit, die sich die Maschine in dem einen oder anderen Zustand befindet, sowie die Zeit, die benötigt wird, um den einen oder anderen Zustand zu erreichen, werden in keiner Weise spezifiziert.
• Die Anzahl der Zustände des Automaten muss endlich sein und alle müssen explizit angegeben werden. Einzelne Pseudozustände verfügen möglicherweise nicht über Spezifikationen (Anfangs- und Endzustände). In diesem Fall werden ihr Zweck und ihre Semantik vollständig aus dem Kontext des Modells und des betrachteten Zustandsdiagramms bestimmt;
• Der Automatengraph sollte keine isolierten Zustände und Übergänge enthalten. Für jeden Zustand außer dem Anfangszustand muss ein vorheriger Zustand bestimmt werden, und jeder Übergang muss zwei Zustände der Maschine verbinden;
• Der Automat sollte keine widersprüchlichen Übergänge enthalten, wenn das Objekt gleichzeitig in zwei oder mehr aufeinanderfolgende Zustände übergehen kann (außer im Fall paralleler Unterautomaten). In UML ist eine Konfliktbeseitigung durch die Einführung von Schutzbedingungen möglich.

Zustand ist nicht nur im UML-Sprachmetamodell, sondern auch in der angewandten Systemanalyse von grundlegender Bedeutung. Das gesamte Konzept eines dynamischen Systems basiert auf dem Zustandskonzept. Die Zustandssemantik in der UML-Sprache weist eine Reihe spezifischer Merkmale auf.

        In UML ist ein Zustand eine abstrakte Metaklasse, die zur Modellierung einer bestimmten Situation verwendet wird, in der bestimmte Bedingungen erfüllt sind. Der Status kann als Satz spezifischer Klassen- oder Objektattributwerte angegeben werden. Änderungen an einzelnen Attributwerten spiegeln Änderungen im Status der modellierten Klasse oder des modellierten Objekts wider.

Aktivitätsdiagramm

        Bei der Modellierung des Verhaltens eines Systems, das entworfen oder analysiert wird, ist es notwendig, nicht nur den Prozess der Zustandsänderung darzustellen, sondern auch die Merkmale der algorithmischen und logischen Implementierung der vom System durchgeführten Operationen detailliert darzustellen.

        Tatsächlich dieser Typ Diagramme können auch verwendet werden, um die Zustände des modellierten Objekts darzustellen. Der Hauptzweck eines Aktivitätsdiagramms besteht jedoch darin, die Geschäftsprozesse des Objekts darzustellen. Mit diesem Diagrammtyp können Sie nicht nur den Ablauf von Prozessen, sondern auch die Verzweigung und sogar Synchronisation von Prozessen darstellen.

        Mit diesem Diagrammtyp können Sie Algorithmen für das Verhalten von Objekten beliebiger Komplexität entwerfen, einschließlich der Erstellung von Blockdiagrammen.

        Um den Prozess der Ausführung von Operationen in der UML-Sprache zu modellieren, werden Aktivitätsdiagramme verwendet. Die darin verwendete grafische Notation ähnelt in vielerlei Hinsicht der Notation eines Zustandsdiagramms, da diese Diagramme auch Zustands- und Übergangssymbole enthalten. Jeder Zustand in einem Aktivitätsdiagramm entspricht dem Abschluss einer elementaren Operation, und der Übergang zum nächsten Zustand erfolgt erst, wenn diese Operation abgeschlossen ist.

        Somit können Aktivitätsdiagramme als Sonderfall von Zustandsdiagrammen betrachtet werden. Sie ermöglichen es Ihnen, die Funktionen der prozeduralen und synchronen Steuerung aufgrund des Abschlusses interner Aktivitäten und Aktionen in der UML-Sprache zu implementieren. Der Hauptzweck von Aktivitätsdiagrammen besteht darin, die Implementierungsmerkmale von Klassenoperationen zu visualisieren, wenn Algorithmen für deren Implementierung vorgestellt werden müssen.

        Im Kontext der UML-Sprache Aktivität ist eine Reihe einzelner Berechnungen, die von einem Automaten durchgeführt werden und zu einem Ergebnis oder einer Aktion führen. Ein Aktivitätsdiagramm zeigt die Logik und Reihenfolge der Übergänge von einer Aktivität zur anderen und lenkt die Aufmerksamkeit des Analysten auf die Ergebnisse. Das Ergebnis einer Aktivität kann zu einer Änderung des Systemzustands oder zur Rückgabe eines Werts führen.

        Aktionsstatus ist ein Sonderfall eines Zustands mit einer Eingabeaktion und mindestens einem Übergang, der den Zustand verlässt. Bei diesem Übergang wird implizit davon ausgegangen, dass die Eingabeaktion bereits abgeschlossen wurde. Der Aktionszustand kann keine internen Übergänge haben, da er elementar ist. Eine häufige Verwendung eines Aktionszustands besteht darin, einen Schritt bei der Ausführung eines Algorithmus (einer Prozedur) oder eines Kontrollflusses zu modellieren.

Sequenzdiagramm

        Bei der Betrachtung von Zustands- und Aktivitätsdiagrammen wurde festgestellt, dass diese Diagramme zwar zur Spezifizierung der Dynamik des Systemverhaltens verwendet werden, Zeit in ihnen jedoch nicht explizit vorhanden ist. Der zeitliche Aspekt des Verhaltens kann bei der Modellierung synchroner Prozesse, die die Interaktionen von Objekten beschreiben, von Bedeutung sein. Um die Interaktion von Objekten im Zeitverlauf zu modellieren, verwendet UML Sequenzdiagramme.

        Nur diese Objekte, die direkt an der Interaktion beteiligt sind. Der entscheidende Punkt Bei Sequenzdiagrammen handelt es sich um die Dynamik der Interaktion von Objekten über die Zeit.

        In UML hat ein Sequenzdiagramm zwei Dimensionen. Die erste verläuft von links nach rechts in Form vertikaler Linien, von denen jede die Lebenslinie eines einzelnen an der Interaktion beteiligten Objekts darstellt. Das Objekt ganz links im Diagramm ist das Objekt, das die Interaktion initiiert. Rechts befindet sich ein weiteres Objekt, das direkt mit dem ersten interagiert. Somit bilden alle Objekte in einem Sequenzdiagramm eine bestimmte Reihenfolge, die durch die Reihenfolge oder den Aktivitätsgrad der Objekte bei der Interaktion miteinander bestimmt wird.

        Grafisch wird jedes Objekt als Rechteck dargestellt und befindet sich im oberen Teil seiner Lebenslinie. Schreiben Sie in das Rechteck den Objektnamen und den Klassennamen, getrennt durch einen Doppelpunkt. In diesem Fall wird der gesamte Datensatz hervorgehoben, was ein Zeichen für das Objekt ist.

        Die zweite Dimension eines Sequenzdiagramms ist die vertikale Zeitachse, die von oben nach unten verläuft. Der oberste Teil des Diagramms entspricht dem Anfangszeitpunkt. Objektinteraktionen werden durch Nachrichten implementiert, die von einem Objekt an ein anderes gesendet werden. Nachrichten werden als horizontale Pfeile mit dem Nachrichtennamen dargestellt und ihre Reihenfolge wird durch den Zeitpunkt des Auftretens bestimmt. Das bedeutet, dass Nachrichten, die sich weiter oben im Sequenzdiagramm befinden, vor denen gestartet werden, die sich weiter unten befinden. Der Maßstab auf der Zeitachse ist nicht angegeben, da das Sequenzdiagramm nur die zeitliche Reihenfolge von „früher-später“-Interaktionen modelliert.

Kollaborationsdiagramm

        Hauptmerkmal Kooperationsdiagramme sind die Fähigkeit, nicht nur den Ablauf einer Interaktion, sondern auch alle strukturellen Beziehungen zwischen den an dieser Interaktion beteiligten Objekten grafisch darzustellen.

        Mit dieser Art von Diagramm können Sie die Interaktionen von Objekten beschreiben und dabei von der Reihenfolge der Nachrichtenübertragung abstrahieren. Ein solches Diagramm zeigt in kompakter Form alle empfangenen und gesendeten Nachrichten eines bestimmten Objekts und die Art dieser Nachrichten.

        Das Kooperationsdiagramm stellt zunächst die an der Interaktion beteiligten Objekte in Form von Rechtecken dar, die den Namen des Objekts, seine Klasse und ggf. Attributwerte enthalten. Darüber hinaus werden, wie im Klassendiagramm, Assoziationen zwischen Objekten in Form verschiedener Verbindungslinien angezeigt. In diesem Fall können Sie die Namen der Assoziation und die Rollen, die Objekte in dieser Assoziation spielen, explizit angeben. Darüber hinaus können dynamische Zusammenhänge – Nachrichtenflüsse – abgebildet werden. Sie werden auch als Verbindungslinien zwischen Objekten dargestellt, über denen sich ein Pfeil befindet, der die Richtung, den Nachrichtennamen und die Sequenznummer in der allgemeinen Reihenfolge der Nachrichteninitialisierung angibt.

        Im Gegensatz zu einem Sequenzdiagramm stellt ein Kooperationsdiagramm nur die Beziehungen zwischen Objekten dar, die bestimmte Rollen in der Interaktion spielen. Dieses Diagramm zeigt die Zeit nicht als separate Dimension. Daher kann die Reihenfolge von Wechselwirkungen und parallelen Flüssen anhand von Sequenznummern bestimmt werden. Wenn Sie die Beziehungen zwischen Objekten in Echtzeit explizit angeben müssen, ist es daher besser, dies in einem Sequenzdiagramm zu tun.

        Konzept Zusammenarbeit ist eines der Grundkonzepte der UML-Sprache. Es dient dazu, eine Reihe von Objekten zu bezeichnen, die im allgemeinen Kontext des modellierten Systems mit einem bestimmten Zweck interagieren. Der Zweck der Zusammenarbeit selbst besteht darin, die Implementierungsmerkmale der einzelnen wichtigsten Operationen im System festzulegen. Kooperation definiert die Struktur des Systemverhaltens im Hinblick auf die Interaktion der Teilnehmer dieser Kooperation.

        Zusammenarbeit kann auf zwei Ebenen dargestellt werden:

• Spezifikationsebene – zeigt die Rollen von Klassifikatoren und die Rollen von Assoziationen in der betrachteten Interaktion;
• Beispielebene – zeigt Instanzen und Beziehungen an, die individuelle Rollen in der Zusammenarbeit bilden.

        Ein Kooperationsdiagramm auf Spezifikationsebene zeigt die Rollen, die die an der Interaktion beteiligten Elemente spielen. Die Elemente der Zusammenarbeit auf dieser Ebene sind Klassen und Assoziationen, die die individuellen Rollen von Klassifikatoren und Assoziationen zwischen Teilnehmern der Zusammenarbeit bezeichnen.

        Das Kooperationsdiagramm auf Beispielebene wird durch eine Reihe von Objekten (Instanzen von Klassen) und Verbindungen (Instanzen von Assoziationen) dargestellt. In diesem Fall werden die Verbindungen durch Meldepfeile ergänzt. Auf dieser Ebene werden nur Objekte angezeigt, die in direktem Zusammenhang mit der Implementierung der Operation oder des Klassifikators stehen. In diesem Fall ist es überhaupt nicht notwendig, alle Eigenschaften oder alle Assoziationen abzubilden, da das Kooperationsdiagramm nur die Rollen von Klassifikatoren enthält, nicht jedoch die Klassifikatoren selbst. Während also ein Klassifikator eine vollständige Beschreibung aller seiner Instanzen erfordert, erfordert die Rolle eines Klassifikators die Beschreibung nur derjenigen Eigenschaften und Assoziationen, die für die Teilnahme an einer bestimmten Zusammenarbeit erforderlich sind.

        Daraus folgt eine wichtige Konsequenz. Der gleiche Satz von Objekten kann an verschiedenen Kooperationen teilnehmen. Je nach betrachteter Kooperation können sich sowohl die Eigenschaften einzelner Objekte als auch die Verbindungen zwischen ihnen ändern. Dies unterscheidet ein Kollaborationsdiagramm von einem Klassendiagramm, das alle Eigenschaften und Zusammenhänge zwischen den Elementen des Diagramms angeben muss.

Komponentendiagramm

        Diese Art von Diagramm dient dazu, Klassen und Objekte während des physischen Entwurfs eines Systems auf Komponenten zu verteilen. Diese Art von Diagramm wird oft als Moduldiagramm bezeichnet.

        Ein vollständiges Softwaresystemprojekt ist eine Reihe von Modellen logischer und logischer Systeme körperliche Ebenen, die miteinander konsistent sein müssen. UML verwendet Implementierungsdiagramme, um Systemmodelle physisch darzustellen, darunter: Komponentendiagramm Und Bereitstellungsdiagramm.

        Ein Komponentendiagramm beschreibt im Gegensatz zu den zuvor besprochenen Diagrammen die Merkmale der physischen Darstellung des Systems. Es ermöglicht Ihnen, die Architektur des zu entwickelnden Systems zu bestimmen, indem Sie Abhängigkeiten zwischen Softwarekomponenten festlegen, bei denen es sich um Quellcode und ausführbaren Code handeln kann. Die wichtigsten grafischen Elemente eines Komponentendiagramms sind Komponenten, Schnittstellen und Abhängigkeiten zwischen ihnen.

        Das Komponentendiagramm wurde für folgende Zwecke entwickelt:

• Visualisierung allgemeine Struktur Quellcode Software System;
• Spezifikationen der ausführbaren Version des Softwaresystems;
• Gewährleistung der Wiederverwendung einzelner Fragmente Programmcode;
• Darstellungen konzeptioneller und physischer Datenbankschemata.

        An der Entwicklung von Komponentendiagrammen sind sowohl Systemanalytiker und -architekten als auch Programmierer beteiligt. Ein Komponentendiagramm bietet einen konsistenten Übergang von einer logischen Darstellung zu einer konkreten Umsetzung eines Projekts in Form von Softwarecode. Einige Komponenten können nur in der Kompilierungsphase des Programmcodes vorhanden sein, andere in der Phase seiner Ausführung. Ein Komponentendiagramm spiegelt die allgemeinen Abhängigkeiten zwischen Komponenten wider und behandelt letztere als Klassifikatoren.

        Um physische Einheiten in der UML-Sprache darzustellen, wird ein spezieller Begriff verwendet – Komponente. Die Komponente implementiert einen bestimmten Satz von Schnittstellen und dient der allgemeinen Bezeichnung der Elemente der physischen Darstellung des Modells. Zur grafischen Darstellung des Bauteils dient es Sonderzeichen- ein Rechteck mit zwei kleineren Rechtecken links eingefügt. Innerhalb des großen Rechtecks ​​steht der Name der Komponente und ggf. einige davon Weitere Informationen. Das Aussehen dieses Symbols kann je nach Art der mit der Komponente verbundenen Informationen leicht variieren.

Bereitstellungsdiagramm

        Diese Art von Diagramm ist für die Analyse der Hardware des Systems gedacht, also der Hardware, nicht der Programme. Direkt aus dem Englischen übersetzt bedeutet „Deployment“ „Bereitstellung“, aber der Begriff „Topologie“ spiegelt das Wesen dieses Diagrammtyps genauer wider.

        Die physische Darstellung eines Softwaresystems kann nicht vollständig sein, wenn keine Informationen darüber vorliegen, auf welcher Plattform und auf welchen Rechenmitteln es implementiert ist. Wenn Sie ein Programm entwickeln, das lokal auf dem Computer des Benutzers ausgeführt wird und nicht verwendet wird Peripheriegeräte und Ressourcen ist es nicht erforderlich, zusätzliche Diagramme zu entwickeln. Bei der Entwicklung von Unternehmensanwendungen kann das Vorhandensein solcher Diagramme äußerst nützlich sein, um Probleme der rationellen Platzierung von Komponenten zu lösen, um verteilte Rechen- und Kommunikationsressourcen des Netzwerks effektiv zu nutzen, Sicherheit zu gewährleisten und andere.

        Bereitstellungsdiagramme werden verwendet, um die allgemeine Konfiguration und Topologie eines verteilten Softwaresystems in UML darzustellen.

        Das Bereitstellungsdiagramm dient zur Visualisierung der Elemente und Komponenten eines Programms, die nur zur Laufzeit vorhanden sind. In diesem Fall werden nur Programminstanzkomponenten dargestellt, bei denen es sich um ausführbare Dateien oder dynamische Bibliotheken handelt. Die Komponenten, die zur Laufzeit nicht verwendet werden, werden im Bereitstellungsdiagramm nicht angezeigt. Daher können Komponenten mit Programmquellcode nur im Komponentendiagramm vorhanden sein. Sie sind im Bereitstellungsdiagramm nicht angegeben.

        Das Bereitstellungsdiagramm enthält grafische Bilder Prozessoren, Geräte, Prozesse und Verbindungen zwischen ihnen. Im Gegensatz zu logischen Darstellungsdiagrammen ist ein Bereitstellungsdiagramm für das gesamte System einheitlich, da es die Merkmale seiner Implementierung vollständig widerspiegeln muss. Die Entwicklung eines Bereitstellungsdiagramms ist normalerweise der letzte Schritt bei der Spezifikation eines Softwaresystemmodells.

        Bei der Entwicklung eines Deployment-Diagramms werden folgende Ziele verfolgt:

• Bestimmen Sie die Verteilung der Systemkomponenten auf ihre physischen Knoten.
• physische Verbindungen zwischen allen Knoten der Systemimplementierung in der Phase ihrer Ausführung zeigen;
• Identifizieren Sie Systemengpässe und konfigurieren Sie die Topologie neu, um die erforderliche Leistung zu erzielen.

        Bereitstellungsdiagramme werden gemeinsam von Systemanalysten, Netzwerkingenieuren und Systemtechnikern entwickelt.

Funktionen der Rational Rose-Arbeitsoberfläche

        Das Rational Rose CASE-Tool implementiert allgemein anerkannte Standards für die Bedienoberfläche des Programms, ähnlich wie bekannte visuelle Programmierumgebungen. Nach der Installation von Rational Rose auf dem Computer des Benutzers, die selbst Anfängern praktisch keine Schwierigkeiten bereitet, führt der Start dieses Programms unter MS Windows 95/98 zum Erscheinen einer funktionierenden Oberfläche auf dem Bildschirm (Abb. 6).

Abbildung - 6. Gesamtansicht der Arbeitsoberfläche des Rational Rose-Programms

        Die Bedienoberfläche von Rational Rose besteht aus verschiedenen Elementen, die wichtigsten sind:

• Hauptmenü des Programms
• Diagrammfenster
• Dokumentationsfenster
• Browser Fenster
• Protokollfenster

Betrachten wir kurz den Zweck und die Hauptfunktionen jedes dieser Elemente.

Hauptmenü des Programms

Das Hauptmenü des Programms ist im allgemein anerkannten Standard erstellt und sieht so aus (Abb. 7).

Einzelne Menüpunkte, deren Zweck aus ihren Namen hervorgeht, fassen ähnliche Vorgänge zusammen, die sich auf das gesamte Projekt als Ganzes beziehen. Einige der Menüpunkte enthalten bekannte Funktionen (Öffnen eines Projekts, Drucken von Diagrammen, Kopieren und Einfügen verschiedener Diagrammelemente aus der Zwischenablage). Andere sind so spezifisch, dass ihr Studium möglicherweise zusätzlichen Aufwand erfordert (Optionen zur Codegenerierung, Überprüfung der Modellkonsistenz, Anbindung zusätzlicher Module).

Abbildung - 7. Aussehen Hauptmenü des Programms

Standard-Symbolleiste

Die Standardsymbolleiste befindet sich unterhalb des Hauptmenüs des Programms und sieht folgendermaßen aus (Abb. 8). Einige der Tools sind nicht verfügbar (das neue Projekt enthält keine Elemente). Die Standardsymbolleiste bietet schnellen Zugriff auf die Menübefehle, die Entwickler am häufigsten verwenden.

Abbildung 8. Aussehen der Standardsymbolleiste

Der Benutzer kann das Erscheinungsbild dieses Panels nach eigenem Ermessen anpassen. Wählen Sie dazu den Menüpunkt Extras -> Optionen und öffnen Sie die Registerkarte Symbolleisten. Auf diese Weise können Sie verschiedene Werkzeugschaltflächen ein- oder ausblenden und ihre Größe ändern.

Browser Fenster

Das Standardbrowserfenster befindet sich auf der linken Seite der Arbeitsoberfläche unter der Standardsymbolleiste (Abb. 9).

Der Browser organisiert Modellansichten in einer hierarchischen Struktur, die die Navigation vereinfacht und es Ihnen ermöglicht, jedes Modellelement im Projekt zu finden. In diesem Fall wird jedes Element, das der Entwickler dem Modell hinzufügt, sofort im Browserfenster angezeigt. Dementsprechend können wir durch Auswahl eines Elements im Browserfenster dieses im Diagrammfenster visualisieren oder seine Spezifikation ändern. Mit dem Browser können Sie außerdem Modellelemente in Paketen organisieren und Elemente zwischen verschiedenen Ansichten des Modells verschieben. Auf Wunsch kann das Browserfenster über den Menüpunkt „Ansicht“ an einer anderen Stelle der Arbeitsoberfläche platziert oder ganz ausgeblendet werden. Sie können die Größe des Browsers auch ändern, indem Sie den äußeren Rahmen mit der Maus ziehen.

Abbildung - 9. Browser-Erscheinungsbild

Spezielle Symbolleiste

Zwischen dem Browserfenster und dem Diagrammfenster befindet sich im mittleren Teil der Arbeitsoberfläche eine spezielle Symbolleiste. Standardmäßig wird eine Symbolleiste zum Erstellen eines Modellklassendiagramms angeboten (Abb. 10).

Abbildung - 10. Darstellung einer speziellen Symbolleiste für ein Klassendiagramm

Die Position der speziellen Symbolleiste kann geändert werden, indem der Bedienfeldrahmen an die gewünschte Position verschoben wird. Sie können die Zusammensetzung des Bedienfelds auch anpassen, indem Sie einzelne Schaltflächen für bestimmte Werkzeuge hinzufügen oder entfernen. Tastenzuordnungen können anhand von Tooltips erlernt werden, die angezeigt werden, nachdem der Mauszeiger über der entsprechenden Schaltfläche schwebt.

Diagrammfenster

Das Diagrammfenster ist der Hauptarbeitsbereich seiner Oberfläche, in dem verschiedene Ansichten des Projektmodells visualisiert werden. Standardmäßig befindet sich das Diagrammfenster auf der rechten Seite der Arbeitsoberfläche, seine Position und Größe können jedoch auch geändert werden. Wenn bei der Entwicklung eines neuen Projekts der Projektassistent nicht verwendet wurde, ist das Diagrammfenster ein leerer Bereich, der keine Modellelemente enthält (Abb. 11).

Der Name des Diagramms, das sich in diesem Fenster befindet, wird in der Titelleiste des Programms (oberste Zeile des Programms) oder, wenn das Fenster nicht auf Vollbild maximiert ist, in der Titelleiste des Diagrammfensters angezeigt. Es können mehrere Charts gleichzeitig im Chartfenster vorhanden sein, von denen jedoch nur einer aktiv sein kann. Zum Beispiel in Abb. 11 Das aktive Diagramm ist das Bereitstellungsdiagramm, obwohl es auch andere Diagramme gibt. Der Wechsel zwischen Diagrammen kann durch Auswahl der gewünschten Ansicht in der Standardsymbolleiste oder über den Menüpunkt „Fenster“ erfolgen. Wenn Sie eine separate Diagrammansicht aktivieren, ändert sich das Erscheinungsbild einer speziellen Symbolleiste, die an die jeweilige Diagrammansicht angepasst ist.

Abbildung - 11. Aussehen des Diagrammfensters mit verschiedenen Arten von Modellansichten

Dokumentationsfenster

Das Dokumentationsfenster ist möglicherweise nicht standardmäßig auf dem Bildschirm vorhanden. In diesem Fall kann es über den Menüpunkt Ansicht -> Dokumentation aktiviert werden und erscheint anschließend unterhalb des Browsers (Abb. 12).

Das Dokumentationsfenster dient, wie der Name schon sagt, der Dokumentation der Elemente einer Modellansicht. Darin können Sie verschiedenste Informationen festhalten, und das Wichtigste - auf Russisch. Diese Informationen werden anschließend in Kommentare umgewandelt und haben keinen Einfluss auf die Ausführungslogik des Programmcodes.

Im Dokumentationsfenster werden die Informationen aktiviert, die sich auf das einzelne ausgewählte Element des Diagramms beziehen. In diesem Fall können Sie ein Element entweder im Browserfenster oder im Diagrammfenster auswählen. Wenn Sie dem Diagramm ein neues Element hinzufügen (z. B. eine Klasse), wird automatisch eine Dokumentation dafür generiert, die leer ist (keine Dokumentation). Anschließend gibt der Entwickler selbstständig die notwendigen erläuternden Informationen ein, die im Gedächtnis bleiben und im Laufe der Projektarbeit geändert werden können.

Wie bei anderen Fenstern der Arbeitsoberfläche können Sie auch beim Dokumentationsfenster die Größe und Position ändern.

Abbildung - 12. Aussehen des Dokumentationsfensters

Protokollfenster

Das Protokollfenster dient zur automatischen Aufzeichnung verschiedener Serviceinformationen, die während der Arbeit mit dem Programm generiert werden. Das Protokoll zeichnet den Zeitpunkt und die Art der vom Entwickler durchgeführten Aktionen auf, z. B. das Aktualisieren des Modells, das Anpassen von Menüs und Symbolleisten sowie Fehlermeldungen, die beim Generieren von Programmcode auftreten.

Das Protokollfenster ist auf der Arbeitsoberfläche immer im Diagrammfensterbereich vorhanden (Abb. 13). Es kann jedoch sein, dass es von anderen Kartenfenstern ausgeblendet oder minimiert wird. Sie können das Protokollfenster über das Menü Fenster->Protokoll aktivieren. In diesem Fall wird es über anderen Fenstern im rechten Bereich der Arbeitsoberfläche angezeigt. Dieses Fenster kann nicht vollständig entfernt, sondern nur minimiert werden.

Abbildung - 13. Darstellung des Protokollfensters

Abschluss

        Im Laufe der Zeit wird die UML-Sprache zum „Esperanto“, in dem Mathematiker, Systemanalytiker, Physiker, Programmierer, Manager, Wirtschaftswissenschaftler und Spezialisten anderer Berufe kommunizieren und ihr Fachwissen in einer einheitlichen Form präsentieren können. Denn im Grunde operiert jeder der Spezialisten mit Modelldarstellungen in seinem Fachgebiet. Und genau dieser Modellaspekt kann mit der UML-Sprache spezifiziert werden.

        In diesem Zusammenhang nimmt die Bedeutung der UML-Sprache deutlich zu, da sie zunehmend Merkmale einer Wissensrepräsentationssprache erhält. Gleichzeitig ermöglicht das Vorhandensein visueller Mittel zur Darstellung der Struktur und des Verhaltens des Modells in der UML-Sprache eine angemessene Darstellung des deklarativen und prozeduralen Wissens und, nicht weniger wichtig, die Herstellung einer semantischen Entsprechung zwischen diesen Formen von Wissen. All diese Merkmale der UML-Sprache lassen den Schluss zu, dass sie in naher Zukunft die größten Aussichten hat.

Dieser Artikel beschreibt die neue Ära der Softwareentwicklung, ihre Auswirkungen auf neue UML-Anforderungen und Best Practices für deren Erfüllung.
  7. „Datenmodellierung in Rational Rose“ Sergey Trofimov beschreibt die Modellierung der physischen Darstellung von Daten mit Rational Rose
  8. UML-Sprache. Allgemeines Verständnis der UML-Sprache: Strukturen, grafische Elemente und Sprachdiagramme.
  9. Praktische UML. Dieses Dokument ist eine Übersetzung des Dokuments „Practical UML. A Hands-On Introduction for Developers“. Praktische Einführung für Entwickler
  10. „Standardisierte objektorientierte Modellierungssprache UML“ Vendrov Alexander Mikhailovich. Geschichte der UML
  11. UML – einheitliche Modellierungssprache. Dieses Material enthält erste Informationen zu Methoden zur Beschreibung von Softwaresystemen und Notationen, die in UML verwendet werden
  12. UML-Sprache. Benutzerhandbuch. Autoren: Grady Booch, James Rumbaugh, Ivar Jacobson
  13. „UML-Diagramme in Rational Rose“ Sergey Trofimov
  14. „Analyse und Design. Visuelle Modellierung (UML) Rational Rose“ Konstantin Domolego
  15. Bibliothek von Gennadi Wernikow. Vollständige Beschreibungen der Design- und Modellierungsstandards.
  16. „Ein Beispiel für die Beschreibung eines Themenbereichs mithilfe von UML bei der Entwicklung von Softwaresystemen“ E.B. Zolotukhina, R.V. Alfimov. Der Artikel demonstriert anhand eines konkreten Beispiels einen möglichen Ansatz zur Domänenmodellierung auf Basis der Verwendung der Unified Modeling Language (UML).

UML oder Unified Modeling Language ist eine grafische Beschreibungssprache zur Objektmodellierung im Bereich der Softwareentwicklung. Doch der Einsatz von UML beschränkt sich nicht nur auf die IT; ein weiterer großer praktischer Einsatzbereich von UML ist die Modellierung von Geschäftsprozessen, Systemdesign und die Abbildung von Organisationsstrukturen. UML ermöglicht es Softwareentwicklern, sich auf grafische Notationen für die Darstellung zu einigen allgemeine Konzepte und konzentrieren sich auf Design und Entwicklung.

Vorteile von UML

• UML verwendet grafische Notationen für die Elemente des modellierten Systems, und UML-Diagramme sind relativ einfach zu verstehen;
• UML ermöglicht die Beschreibung von Systemen aus nahezu allen möglichen Blickwinkeln unter Berücksichtigung verschiedener Aspekte;
• UML ist objektorientiert: Seine Analyse- und Konstruktionsmethoden ähneln semantisch den Programmiermethoden, die in modernen OOP-Sprachen verwendet werden.
• UML ist ein offener Standard. Der Standard entwickelt und entwickelt sich von Version zu Version weiter und erfüllt die modernsten Anforderungen zur Beschreibung von Systemen;
• enthält einen Erweiterungsmechanismus, der die Eingabe zusätzlicher Text- und Grafiktypen ermöglicht, was den Einsatz von UML nicht nur im IT-Bereich ermöglicht.

UML-Diagrammtypen

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

• strukturell, repräsentiert die Informationsstruktur;
• Verhalten, das das Verhalten des Systems und verschiedene Aspekte von Interaktionen darstellt. Es wird ein separater Untertyp von Verhaltensdiagrammen betrachtet Interaktionsdiagramme.

Hierarchie der UML-Diagrammtypen,
dargestellt durch ein Klassendiagramm

Strukturdiagramme

1. Klassen Diagramm ist ein Schlüsselelement der objektorientierten Modellierung. Unter Verwendung dieses Diagramms (eigentlich durch Klassen, ihre 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) an 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 simulierten Systems zu einem bestimmten Zeitpunkt. Es repräsentiert Klasseninstanzen (Objekte), ihren Zustand (aktuelle Attributwerte) und die Beziehungen zwischen ihnen.
4. Zusammengesetztes Strukturdiagramm demonstriert die interne Struktur von Klassen und, soweit möglich, die Interaktionen zwischen Elementen dieser Struktur.
5. Paketdiagramm zeigt Pakete und Beziehungen zwischen ihnen. Diese Art von Diagramm dient dazu, den Aufbau des Modells (und damit die Arbeit damit) zu vereinfachen, indem Modellelemente nach bestimmten Kriterien zu Gruppen zusammengefasst werden.
6. Bereitstellungsdiagramm simuliert den Einsatz Softwarekomponenten ov ( Artefakte) zu Rechenressourcen/Hardwarekomponenten ( Knoten).
7. Profildiagramm beschreibt einen Erweiterungsmechanismus, der es ermöglicht, UML an eine Vielzahl von Fachgebieten und Branchen anzupassen.

Beispiel für ein UML-Klassendiagramm

Verhaltensdiagramme

1. Aktivitätsdiagramm zeigt Aktionen ( Aktionen), aus denen eine Aktivität besteht ( Aktivität). Aktivitätsdiagramme werden zur Modellierung von Geschäftsprozessen, technologischen Prozessen, sequentiellem und parallelem Rechnen verwendet.
2. Anwendungsfalldiagramm(oder Anwendungsfalldiagramm) beschreibt die Beziehung zwischen Akteuren (Akteuren) und Anwendungsfällen des modellierten Systems (seine Fähigkeiten). Der Hauptzweck des Diagramms besteht darin, ein universelles Werkzeug für Kunden, Entwickler und Endbenutzer zu sein, um gemeinsam das 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 abhängig von ihrem aktuellen Zustand auf verschiedene Ereignisse reagiert. Dies ist im Wesentlichen ein Zustandsdiagramm aus der Atomtheorie.
4. Kommunikationsdiagramm(V frühere Versionen Kooperationsdiagramm) zeigt die Wechselwirkungen zwischen den Teilen der Verbundstruktur und die Rollen der Zusammenarbeit. Das Diagramm zeigt explizit die Beziehungen zwischen Elementen (Objekten) an.
5. Sequenzdiagramm Wird verwendet, um die Abfolge von Objektinteraktionen zu visualisieren. Zeigt den Lebenszyklus eines bestimmten Objekts und die Interaktion von Akteuren (Akteuren) innerhalb eines bestimmten Anwendungsfalls, die Reihenfolge der Nachrichten, die sie austauschen.
6. Interaktionsübersichtsdiagramm Enthält einen Teil des Sequenzdiagramms und des Kontrollflussdesigns. Hilft, die Interaktion von Objekten aus verschiedenen Blickwinkeln zu betrachten.
7. Zeitdiagramm- 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 untersuchen.

UML ist eine einheitliche grafische Modellierungssprache zur Beschreibung, Visualisierung, Gestaltung und Dokumentation von OO-Systemen. UML soll den Prozess der Modellierung von Software auf Basis des OO-Ansatzes unterstützen, die Beziehung zwischen Konzept- und Programmkonzepten organisieren und die Probleme der Skalierung komplexer Systeme widerspiegeln. UML-Modelle werden in allen Phasen des Software-Lebenszyklus verwendet, von der Geschäftsanalyse bis zur Systemwartung. Abhängig von ihren Problembereichen und den von ihnen verwendeten Technologien können verschiedene Organisationen UML nach eigenem Ermessen verwenden.

Eine kurze Geschichte von UML

Bis Mitte der 90er Jahre hatten verschiedene Autoren mehrere Dutzend OO-Modellierungsmethoden vorgeschlagen, von denen jede ihre eigene grafische Notation verwendete. Gleichzeitig hatte jede dieser Methoden ihre Stärken, erlaubte jedoch nicht die Erstellung eines ausreichend vollständigen Modells des PS, das es „von allen Seiten“, also allen notwendigen Projektionen, zeigte (siehe Artikel 1). Darüber hinaus erschwerte das Fehlen eines OO-Modellierungsstandards den Entwicklern die Wahl der am besten geeigneten Methode, was die weitverbreitete Einführung des OO-Ansatzes in der Softwareentwicklung verhinderte.

Auf Wunsch der Object Management Group (OMG), der Organisation, die für die Übernahme 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 gelöst – G . Butch, D. Rambo und A. Jacobson haben gemeinsam die Version UML 1.1 erstellt, die 1997 von der OMG als Standard genehmigt wurde.

UML ist eine Sprache

Jede Sprache besteht aus einem Vokabular und Regeln für die Kombination von Wörtern, um sinnvolle Konstruktionen zu bilden. So sind insbesondere Programmiersprachen aufgebaut, beispielsweise UML. Seine Besonderheit besteht darin, dass das Sprachwörterbuch aus grafischen Elementen besteht. Jedem Grafiksymbol ist eine spezifische Semantik zugeordnet, sodass ein von einem Entwickler erstelltes Modell von einem anderen sowie von einem Softwaretool, das UML interpretiert, klar verstanden werden kann. Daraus folgt insbesondere, dass ein in UML dargestelltes Softwaremodell automatisch in eine OO-Programmiersprache (wie Java, C++, VisualBasic) übersetzt werden kann, sofern ein gutes visuelles Modellierungstool vorhanden ist, das UML unterstützt Wenn wir das Modell erstellt haben, erhalten wir auch einen Beispielprogrammcode, der diesem Modell entspricht.

Es sollte betont werden, dass UML eine Sprache und keine Methode ist. Es erklärt, aus welchen Elementen Modelle erstellt werden und wie man sie liest, sagt aber 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 den folgenden Artikeln besprochen wird.

UML-Wörterbuch

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

Entitäten sind Abstraktionen, die die Hauptelemente von Modellen sind. Es gibt vier Arten von Entitäten: Struktur (Klasse, Schnittstelle, Komponente, Anwendungsfall, Zusammenarbeit, Knoten), Verhalten (Interaktion, Zustand), Gruppierung (Pakete) und Anmerkung (Kommentare). Jeder Entitätstyp hat seinen eigenen grafische Darstellung. Entitäten werden beim Studium der Diagramme ausführlich besprochen.

Beziehung zeigen verschiedene Verbindungen zwischen Entitäten. UML definiert die folgenden Beziehungstypen:

• Sucht zeigt eine solche Verbindung zwischen zwei Entitäten, wenn eine Änderung in einer von ihnen – unabhängig – die Semantik der anderen – abhängig – beeinflussen kann. Abhängigkeit wird durch einen gepunkteten Pfeil dargestellt, der von der abhängigen Entität zur unabhängigen Entität zeigt.
• Verband ist eine strukturelle Beziehung, die zeigt, dass die Objekte einer Entität mit den Objekten einer anderen in Beziehung stehen. Grafisch wird eine Assoziation als Linie dargestellt, die die zugehörigen Entitäten verbindet. Assoziationen dienen der Navigation zwischen Objekten. Beispielsweise kann die Assoziation zwischen den Klassen „Order“ und „Product“ genutzt werden, um einerseits alle Produkte zu finden, die in einer bestimmten Bestellung angegeben sind, oder um andererseits alle Bestellungen zu finden, die dieses Produkt enthalten. Es ist klar, dass die entsprechenden Programme einen Mechanismus implementieren müssen, der eine solche Navigation ermöglicht. Ist eine Navigation nur in eine Richtung erforderlich, wird dies durch einen Pfeil am Ende der Zuordnung angezeigt. Ein Sonderfall der Assoziation ist die Aggregation – eine Beziehung der Form „Ganzes“ – „Teil“. Grafisch wird es durch eine Raute am Ende in der Nähe des Essenz-Ganzen hervorgehoben.
• Verallgemeinerung ist die Beziehung zwischen einer übergeordneten Entität und einer untergeordneten Entität. Im Wesentlichen spiegelt diese Beziehung die Eigenschaft der Vererbung für Klassen und Objekte wider. Die Verallgemeinerung wird als Linie dargestellt, die mit einem Dreieck endet, das auf die übergeordnete Entität gerichtet ist. Das Kind erbt die Struktur (Attribute) und das Verhalten (Methoden) des Elternteils, kann aber gleichzeitig über neue Strukturelemente und neue Methoden verfügen. UML ermöglicht Mehrfachvererbung, bei der eine Entität mit mehr als einer übergeordneten Entität verknüpft ist.
• Implementierung– die Beziehung zwischen einer Entität, die eine Verhaltensspezifikation definiert (Schnittstelle), und einer Entität, die die Implementierung dieses Verhaltens definiert (Klasse, Komponente). Diese Beziehung wird häufig bei der Modellierung von Komponenten verwendet und wird in den folgenden Artikeln ausführlicher beschrieben.

Diagramme. UML stellt die folgenden Diagramme bereit:

• Diagramme, die das Verhalten des Systems beschreiben:
• Zustandsdiagramme
• Aktivitätsdiagramme,
• Objektdiagramme,
• Sequenzdiagramme,
• Kollaborationsdiagramme;
• Diagramme, die die physische Implementierung des Systems beschreiben:
• Komponentendiagramme;
• Bereitstellungsdiagramme.

Modellsteuerungsansicht. Pakete.

Wir haben bereits gesagt, dass ein Modell, damit es von Menschen gut verstanden wird, hierarchisch organisiert sein muss und auf jeder Ebene der Hierarchie eine kleine Anzahl von Entitäten verbleibt. UML umfasst 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, wodurch Hierarchien erstellt werden können. UML bietet keine separaten Paketdiagramme, diese können jedoch in anderen Diagrammen erscheinen. Das Paket wird als Rechteck mit einem Lesezeichen dargestellt.

Was UML bietet.

• hierarchische Beschreibung eines komplexen Systems durch Identifizierung von Paketen;
• Formalisierung funktionaler Anforderungen an das System mithilfe der Anwendungsfallapparatur;
• Detaillierte Systemanforderungen durch Erstellung von Aktivitätsdiagrammen und Szenarien;
• Identifizieren von Datenklassen und Erstellen eines konzeptionellen Datenmodells in Form von Klassendiagrammen;
• Identifizieren von Klassen, die die Benutzeroberfläche beschreiben, und Erstellen eines Bildschirmnavigationsschemas;
• Beschreibung der Interaktionsprozesse von Objekten bei der Ausführung von Systemfunktionen;
• Beschreibung des Objektverhaltens in Form von Aktivitäts- und Zustandsdiagrammen;
• Beschreibung von Softwarekomponenten und deren Interaktion über Schnittstellen;
• Beschreibung der physischen Architektur des Systems.

Und das Letzte...

Trotz aller Attraktivität von UML wäre der Einsatz in der realen Softwaremodellierung ohne visuelle Modellierungswerkzeuge schwierig. Mit solchen Tools können Sie Diagramme schnell auf dem Bildschirm darstellen, dokumentieren, Programmcode-Vorlagen in verschiedenen OO-Programmiersprachen generieren und Datenbankschemata erstellen. Die meisten von ihnen beinhalten die Möglichkeit, Programmcodes neu zu gestalten – bestimmte Projektionen des Softwaremodells durch automatische Analyse der Quellcodes von Programmen wiederherzustellen, was sehr wichtig ist, um die Übereinstimmung zwischen Modell und Codes sicherzustellen und wenn Systeme entworfen werden, die die Funktionalität von Vorgängersystemen erben.

Was ist UML?

Wenn Sie sich die Bilder ansehen Suchmaschinen, dann wird es klar UML– es geht um Diagramme, Pfeile und Quadrate. Wichtig ist, dass UML übersetzt wird als Einheitliche Modellierungssprache. Das Wort Unified ist hier wichtig. Das heißt, unsere Bilder werden nicht nur von uns verstanden, sondern auch von anderen, die UML kennen. Es stellt sich heraus, dass es so ist internationale Sprache Diagramme zeichnen.

Wie Wikipedia sagt

UML ist eine grafische Beschreibungssprache für die Objektmodellierung in der Softwareentwicklung, Geschäftsprozessmodellierung, Systemdesign und Darstellung von Organisationsstrukturen.

Anwendung

Aber was ist, wenn Sie es selbst zeichnen möchten und nicht einmal die Ultimate-Version von Idea haben? Wenn wir die IntelliJ Idea Community Edition verwenden, haben wir keine andere Wahl. Dazu müssen Sie verstehen, wie ein solches UML-Diagramm aufgebaut ist. Zuerst müssen wir Graphviz installieren. Dies ist eine Reihe von Dienstprogrammen zur Visualisierung von Diagrammen. Es wird von dem Plugin verwendet, das wir verwenden werden. Nach der Installation müssen Sie ein Verzeichnis hinzufügen Behälter aus dem installierten Verzeichnis Graphviz V Umgebungsvariable Umfeld WEG. Wählen Sie anschließend in IntelliJ Idea im Menü Datei -> Einstellungen aus. Wählen Sie im Fenster „Einstellungen“ die Kategorie „Plugins“, klicken Sie auf die Schaltfläche „Repositorys durchsuchen“ und installieren Sie das PlantUML-Integrations-Plugin. Warum ist dieser so gut? PlantUML? Es verwendet eine Diagrammbeschreibungssprache namens „ Punkt„Und dadurch ist es universeller, da diese Sprache nicht nur von PlantUML verwendet wird. Darüber hinaus können wir alles, was wir unten tun, nicht nur in der IDE, sondern auch in tun Onlineservice planttext.com. Nach der Installation des PlantUML-Plugins können wir über „Datei“ -> „Neu“ UML-Diagramme erstellen. Erstellen wir ein Diagramm vom Typ „UML-Klasse“. Dabei wird automatisch eine Vorlage mit einem Beispiel generiert. Löschen wir seinen Inhalt und erstellen wir unseren eigenen, bewaffnet mit einem Artikel aus Habr: Klassenbeziehungen – von UML bis Code. Und um zu verstehen, wie man das im Text darstellt, nehmen wir das PlantUML-Handbuch: plantuml-Klassendiagramm. Ganz am Anfang steht eine Tabelle, die zeigt, wie Zusammenhänge zu beschreiben sind:

Auch die Zusammenhänge selbst können wir hier betrachten: „Beziehungen zwischen Klassen in UML. Beispiele.“ Beginnen wir auf der Grundlage dieser Materialien mit der Erstellung unseres UML-Diagramms. Fügen wir den folgenden Inhalt hinzu, der die beiden Klassen beschreibt: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Um das Ergebnis in Idea anzuzeigen, wählen Sie „Ansicht“ -> „Werkzeugfenster“ -> „PlantUML“. Wir erhalten lediglich zwei Quadrate, die Klassen darstellen. Wie wir wissen, implementieren diese beiden Klassen die List-Schnittstelle. Diese Klassenbeziehung wird Implementierung genannt. Um eine solche Verbindung darzustellen, verwenden Sie einen Pfeil mit einer gepunkteten Linie. Lassen Sie es uns darstellen: Schnittstelle List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для nächster Typ Verbindung hinzufügen, werden wir der Beschreibung der ArrayList-Klasse einen Eintrag darüber hinzufügen Paket privat Array von Elementen: ~ Object elementData Jetzt wollen wir zeigen, dass die ArrayList einige Objekte enthält. In diesem Fall lautet der Verbindungstyp: Anhäufung(Anhäufung). Das Aggregat ist in diesem Fall ArrayList, weil es enthält andere Objekte. Wir wählen die Aggregation, weil Objekte in der Liste ohne die Liste leben können: Sie sind keine integralen Bestandteile der Liste. Ihre Lebensdauer ist nicht an die Lebensdauer der Liste gebunden. Aggregat wird aus dem Lateinischen als „zusammengebaut“ übersetzt, also etwas, das aus etwas besteht. Im Leben gibt es beispielsweise eine Pumpeinheit, die aus einer Pumpe und einem Motor besteht. Das Gerät selbst kann zerlegt werden, wobei einige seiner Komponenten übrig bleiben. Zum Beispiel zum Verkauf oder zur Eingliederung in eine andere Einheit. So ist die Liste. Und dies wird in Form einer leeren Raute in der Nähe der Einheit und einer durchgehenden Linie ausgedrückt. Stellen wir es uns wie folgt dar: class Object ( ) ArrayList o- Object Nun wollen wir zeigen, dass die Klasse LinkedList im Gegensatz zu ArrayList Node enthält – Container, die auf gespeicherte Daten verweisen. In diesem Fall sind Knoten Teil der LinkedList selbst und können nicht separat leben. Node speichert den Inhalt nicht direkt, sondern enthält nur einen Link dazu. Wenn wir beispielsweise einer LinkedList eine Zeile hinzufügen, fügen wir einen neuen Knoten hinzu, der einen Link zu dieser Zeile sowie einen Link zum vorherigen und nächsten Knoten enthält. Diese Art der Verbindung wird aufgerufen Komposition(Komposition). Um ein Komposit (das aus Teilen besteht) anzuzeigen, wird eine farbige Raute gezeichnet, zu der eine durchgehende Linie führt. Schreiben wir dies nun in Form einer Textanzeige der Verbindung: class Node ( ) LinkedList * -- Node Und jetzt müssen wir lernen, wie man einen weiteren wichtigen Verbindungstyp anzeigt - Sucht(Abhängigkeitsverhältnis). Es wird verwendet, wenn eine Klasse eine andere verwendet und die Klasse die verwendete Klasse nicht enthält und nicht ihr Nachkomme ist. Beispielsweise können LinkedList und ArrayList einen ListIterator erstellen. Lassen Sie uns dies als Pfeile mit einer gepunkteten Linie anzeigen: Klasse ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Sie können so detailliert wie nötig darauf eingehen. Alle Bezeichnungen sind hier angegeben: „PlantUML – Klassendiagramm“. Darüber hinaus ist das Zeichnen eines solchen Diagramms nichts Übernatürliches, und wenn Sie an Ihren Aufgaben arbeiten, können Sie es schnell von Hand zeichnen. Dadurch werden Fähigkeiten zum Durchdenken der Anwendungsarchitektur entwickelt und dabei geholfen, Mängel in der Klassenstruktur der Anwendung zu erkennen. frühen Zeitpunkt, nicht, wenn Sie bereits den Tag damit verbracht haben, das falsche Modell zu implementieren. Ich denke, das ist ein guter Grund, es auszuprobieren?)

Automatisierung

Da Maven nicht im Mittelpunkt dieses Artikels steht, finden Sie Antworten auf Ihre Maven-Fragen im Maven Users Center. Öffnen Sie im generierten Projekt die Projektbeschreibungsdatei zur Bearbeitung, pom.xml. Kopieren wir den Inhalt aus der Beschreibung der Installation von UML-Java-Docklet. Das in der Beschreibung verwendete Artefakt konnte im Maven Central-Repository nicht gefunden werden. Aber bei mir hat es damit funktioniert: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. Das heißt, Sie müssen in dieser Beschreibung nur ersetzen Gruppen-ID Mit " info.leadinglight" An " com.chfourie„und die Version installieren“ 1.0.0 ". Danach können wir in dem Verzeichnis ausführen, in dem sich die Datei befindet pom.xml diese Befehle: mvn clean install und mvn javadoc:javadoc . Wenn wir nun die generierte Dokumentation öffnen (Explorer-Ziel\site\apidocs\index.html), sehen wir die UML-Diagramme. Die Umsetzung wird hier übrigens schon korrekt dargestellt)

Abschluss