Grundlagen einer einheitlichen Modellierungssprache. Werkzeuge zum Zeichnen von UML-Diagrammen Linientypen werden in Uml-Diagrammen verwendet

UML-Modell (UML-Modell) ist eine Sammlung einer endlichen Menge von Sprachkonstrukten, von denen die Hauptentitäten Entitäten und Beziehungen zwischen ihnen sind.

Die Entitäten und Modellbeziehungen selbst sind Instanzen der Metamodell-Metaklassen.

Wenn man das UML-Modell vom allgemeinsten Standpunkt aus betrachtet, kann man sagen, dass es ein Graph (genauer gesagt ein geladener Multi-Pseudo-Hyper-Digraph) ist, in dem Eckpunkte und Kanten mit zusätzlichen Informationen geladen werden und eine komplexe interne Struktur haben können. Die Eckpunkte dieses Diagramms werden als Entitäten bezeichnet, und die Kanten sind Beziehungen... Der Rest dieses Abschnitts bietet einen schnellen (vorläufigen), aber vollständigen Überblick über die verfügbaren Entitätstypen und -beziehungen. Zum Glück gibt es nicht zu viele von ihnen. In den folgenden Kapiteln des Buches werden alle Entitäten und Beziehungen noch einmal ausführlicher und anhand von Beispielen betrachtet.

1.4.1. Entitäten

Zur Vereinfachung der Anzeige können Entitäten in UML in vier Gruppen unterteilt werden:

  • strukturell;
  • verhalten;
  • gruppierung;
  • anmerkung.

Strukturelle Entitäten sollen, wie Sie sich vorstellen können, die Struktur beschreiben. In der Regel umfassen strukturelle Einheiten Folgendes.

Ein Objekt (Objekt) 1 ist eine Entität, die eindeutig ist und Status und Verhalten kapselt.

Klasse (Klasse) 2 - eine Beschreibung einer Reihe von Objekten mit gemeinsamen Attributen, die den Status bestimmen, und Operationen, die das Verhalten bestimmen.

Schnittstelle (Schnittstelle) 3 ist eine benannte Gruppe von Operationen, die eine Reihe von Diensten definiert, die von einem Verbraucher angefordert und von einem Dienstanbieter bereitgestellt werden können.

Zusammenarbeit (Zusammenarbeit) 4 - Eine Sammlung von Objekten, die interagieren, um ein Ziel zu erreichen.

Darsteller (Akteur) 5 - eine Entität, die sich außerhalb des modellierten Systems befindet und direkt mit diesem interagiert.

∇ Eine solche Beziehung besteht sicherlich, die in Abb. Diagrammtyphierarchie für UML 1 als Abhängigkeitsbeziehung mit einem Verfeinerungsstereotyp.

∇∇ In UML 1 gab es eine unfreiwillige Assoziation zwischen dem Kooperationsdiagramm und der gleichnamigen Entität, die nicht ganz richtig und manchmal irreführend war.

∇∇∇ In UML 2 hat sich die syntaktische und semantische Belastung des Zustandsdiagramms so stark geändert, dass der Name den Inhalt nicht mehr widerspiegelt.

Eine Liste der neuen Diagramme und ihrer Namen, die in diesem Buch verwendet werden, ist unten dargestellt.

  • Zusammengesetztes Strukturdiagramm
  • Paketdiagramm
  • Zustandsmaschinendiagramm
  • Kommunikationsdiagramm
  • Interaktionsübersicht Diagramm
  • Zeitdiagramm

In Abb. Diagrammtyphierarchie für UML 2 (Teil 1 und 2) ist ein Klassendiagramm, das die Beziehung von Diagrammen in UML 2 zeigt.

Später in diesem Kapitel werden wir alle dreizehn kanonischen Diagramme sehr kurz beschreiben, um einen bestimmten Kontext und ein bestimmtes Vokabular für die spätere Präsentation zu haben. Die Details sind in den verbleibenden Kapiteln des Buches aufgeführt.

Bevor wir jedoch mit dem nächsten Abschnitt fortfahren, wollen wir einen kleinen Exkurs darüber machen, wie der Standard die Formatierung von Diagrammen erfordert. Die allgemeine Vorlage für die Diagrammpräsentation ist unten dargestellt.

Es gibt zwei Hauptgestaltungselemente: einen äußeren Rahmen und ein Etikett mit dem Diagrammnamen. Wenn mit dem Rahmen alles einfach ist - es ist ein Rechteck, das den Bereich begrenzt, in dem sich die Diagrammelemente befinden sollen -, wird der Diagrammname in einem speziellen Format geschrieben (siehe Abb. 1). Notation für Diagramme.

Die angegebene komplexe Form der Registerkarte wird nicht von allen Werkzeugen unterstützt. Dies ist jedoch nicht erforderlich, da die Semantik primär und die Notation sekundär ist. Von nun an werden wir überall ein Rechteck als Beschriftung für das Diagramm verwenden, und dies sollte keine Verwirrung stiften.

Mögliche Tags (Typen) für Diagramme sind in der folgenden Tabelle aufgeführt. Die vom Standard angebotenen Tags werden in die zweite Spalte geschrieben. Wie die Praxis gezeigt hat, sind die von der Norm vorgeschlagenen Regeln jedoch nicht immer zweckmäßig und logisch begründet. Daher enthält die dritte Spalte der Tabelle eine Alternative, die unserer Meinung nach angemessen ist.

Tab. Diagrammtypen und Tags

Diagrammtitel Tag (Standard) Tag (vorgeschlagen)
Nutzungsdiagramm anwendungsfall oder uc anwendungsfall
Klassen Diagramm klasse klasse
Automatendiagramm zustandsmaschine oder stm zustandsmaschine
Aktivitätsdiagramm aktivität oder handlung aktivität
Sequenzdiagramm interaktion oder sd sd
Kommunikationsdiagramm interaktion oder sd comm
Komponentendiagramm komponente oder cmp komponente
Platzierungsdiagramm unentschlossen einsatz
Objektdiagramm unentschlossen objekt
Internes Strukturdiagramm klasse klasse oder komponente
Interaktionsübersichtsdiagramm interaktion oder sd interaktion
Synchronisationsdiagramm interaktion oder sd zeitliche Koordinierung
Paketdiagramm paket oder pkg paket

Alle UML-Diagramme können grob in zwei Gruppen unterteilt werden, von denen die erste allgemeine Diagramme sind. Allgemeine Diagramme hängen praktisch nicht vom Thema der Modellierung ab und können in jedem Softwareprojekt verwendet werden, ohne Rücksicht auf den Themenbereich, den Lösungsbereich usw.

1.5.1. Nutzungsdiagramm

Nutzungsdiagramm (Anwendungsfalldiagramm) ist die allgemeinste Darstellung des Funktionszwecks des Systems.

Das Verwendungsdiagramm soll die Hauptmodellierungsfrage beantworten: Was macht das System in der Außenwelt?

Das Verwendungsdiagramm verwendet zwei Arten von Kernentitäten, Anwendungsfälle 1 und Akteure 2, zwischen denen die folgenden grundlegenden Arten von Beziehungen hergestellt werden:

  • die Assoziation zwischen dem Akteur und Anwendungsfall 3;
  • verallgemeinerung zwischen den Akteuren 4;
  • verallgemeinerung zwischen Anwendungsfällen 5;
  • abhängigkeiten (unterschiedlicher Art) zwischen Anwendungsfällen 6.

Das Verwendungsdiagramm kann wie jedes andere 7 Kommentare enthalten. Darüber hinaus wird dringend empfohlen, dies zu tun, um die Lesbarkeit der Diagramme zu verbessern.

Die Grundelemente der im Verwendungsdiagramm verwendeten Notation sind nachstehend aufgeführt. Eine ausführliche Beschreibung finden Sie in Abschnitt 2.2.

1.5.2. Klassen Diagramm

Klassen Diagramm (Klassendiagramm) - die Hauptmethode zur Beschreibung der Struktur des Systems.

Dies ist nicht überraschend, da UML in erster Linie eine objektorientierte Sprache ist und Klassen die wichtigsten (wenn nicht die einzigen) Bausteine \u200b\u200bsind.

In einem Klassendiagramm wird ein Hauptentitätstyp verwendet: Klassen 1 (einschließlich zahlreicher Sonderfälle von Klassen: Schnittstellen, primitive Typen, Assoziationsklassen und viele andere), zwischen denen die folgenden grundlegenden Arten von Beziehungen hergestellt werden:

  • assoziation zwischen Klassen 2 (mit vielen zusätzlichen Details);
  • verallgemeinerung zwischen Klassen 3;
  • abhängigkeiten (verschiedener Typen) zwischen 4 Klassen und zwischen Klassen und Schnittstellen.

Einige der Elemente der Klassendiagrammnotation sind unten dargestellt. Eine ausführliche Beschreibung finden Sie in Kapitel 3.

1.5.3. Automatendiagramm

Automatendiagramm (Zustandsmaschinendiagramm) ist eine der Möglichkeiten, das Verhalten in der UML detailliert zu beschreiben, indem Zustände explizit hervorgehoben und Übergänge zwischen Zuständen beschrieben werden.

Im Wesentlichen handelt es sich bei Automatendiagrammen, wie der Name schon sagt, um einen Zustandsübergangsgraphen (siehe Kapitel 4), der mit vielen zusätzlichen Details und Details geladen ist.

Im Automatendiagramm wird ein grundlegender Entitätstyp verwendet - Zustände 1 und ein Beziehungstyp - Übergänge 2, aber für beide werden viele Sorten, Sonderfälle und zusätzliche Notationen definiert. Es macht keinen Sinn, sie alle in der Einführungsumfrage aufzulisten.

Eine detaillierte Beschreibung aller Variationen der Automatendiagramme finden Sie in Abschnitt 4.2. Die folgende Abbildung zeigt nur die Grundelemente der im Automatendiagramm verwendeten Notation.

1.5.4. Aktivitätsdiagramm

Aktivitätsdiagramm (Aktivitätsdiagramm) - eine Möglichkeit, das Verhalten anhand der Anzeige von Kontrollflüssen und Datenflüssen zu beschreiben.

Ein Aktivitätsdiagramm ist eine weitere Möglichkeit, ein Verhalten zu beschreiben, das visuell einem guten, altmodischen Flussdiagramm ähnelt. Aufgrund der modernisierten Notation, die mit dem objektorientierten Ansatz übereinstimmt, und vor allem aufgrund der neuen semantischen Komponente (freie Interpretation von Petri-Netzen) ist das UML-Aktivitätsdiagramm ein leistungsstarkes Werkzeug zur Beschreibung des Systemverhaltens.

Im Aktivitätsdiagramm wird ein Hauptentitätstyp verwendet - Aktivität 1 und ein Beziehungstyp - Übergänge 2 (Kontrolle und Datenübertragung). Es werden auch Konstruktionen wie Gabeln, Zusammenführungen, Verknüpfungen und Zweige 3 verwendet, die Entitäten ähnlich sind, dies jedoch nicht sind, sondern eine grafische Darstellung einiger Sonderfälle von Multiplace-Beziehungen darstellen. Die Semantik von Aktivitätsdiagrammelementen wird in Kapitel 4 beschrieben. Die im Aktivitätsdiagramm verwendeten Grundelemente der Notation sind nachstehend aufgeführt.

1.5.5. Sequenzdiagramm

Sequenzdiagramm (Sequenzdiagramm) ist eine Möglichkeit, das Verhalten eines Systems anhand einer Angabe der Sequenz der übertragenen Nachrichten zu beschreiben.

Tatsächlich ist ein Sequenzdiagramm eine Aufzeichnung des Protokolls einer bestimmten Sitzung der Systemoperation (oder eines Fragments eines solchen Protokolls). Bei der objektorientierten Programmierung ist die Übertragung von Nachrichten zwischen kommunizierenden Objekten zur Laufzeit am wichtigsten. In diesem Diagramm wird die Reihenfolge des Sendens von Nachrichten angezeigt, daher der Name.

Im Sequenzdiagramm wird ein Hauptentitätstyp verwendet - Instanzen interagierender Klassifizierer 1 (hauptsächlich Klassen, Komponenten und Akteure) und eine Art von Beziehung - Links 2, über die Nachrichten ausgetauscht werden 3. Es gibt verschiedene Möglichkeiten, Nachrichten zu senden, die sich in grafischer Notation durch den Pfeiltyp unterscheiden, der der Beziehung entspricht.

Ein wichtiger Aspekt des Sequenzdiagramms ist die explizite Anzeige des Zeitablaufs. Im Gegensatz zu anderen Diagrammtypen, mit Ausnahme von Synchronisationsdiagrammen, ist in einem Sequenzdiagramm nicht nur das Vorhandensein grafischer Beziehungen zwischen Elementen wichtig, sondern auch die relative Position von Elementen im Diagramm. Es wird nämlich angenommen, dass es standardmäßig eine (unsichtbare) Zeitachse gibt, die von oben nach unten gerichtet ist, und die später gesendete Nachricht wird unten gezeichnet.

Die Zeitachse kann horizontal gerichtet werden. In diesem Fall wird davon ausgegangen, dass die Zeit von links nach rechts fließt.

Die folgende Abbildung zeigt die grundlegenden Elemente der Notation, die in einem Sequenzdiagramm verwendet werden. Um die interagierenden Objekte selbst zu bestimmen, wird die Standardnotation verwendet - ein Rechteck mit dem Namen der Klassifiziererinstanz. Die von ihr ausgehende gepunktete Linie wird als Lebenslinie 4 bezeichnet. Dies ist keine Bezeichnung für eine Beziehung im Modell, sondern ein grafischer Kommentar, der das Auge des Lesers in die richtige Richtung lenken soll. Die Figuren in Form von schmalen Streifen, die der Lebenslinie überlagert sind, sind ebenfalls keine Bilder der modellierten Einheiten. Dies ist ein grafischer Kommentar, der die Zeiträume zeigt, in denen das Objekt das Ausführungsereignis 5 besitzt, oder mit anderen Worten, das Objekt wird aktiviert. Kombinierte Interaktionsfragmente (kombiniertes Fragment) 6 ermöglichen es dem Sequenzdiagramm, die algorithmischen Aspekte des Interaktionsprotokolls widerzuspiegeln. Weitere Informationen zur Sequenzdiagrammnotation finden Sie in Kapitel 4.

1.5.6. Kommunikationsdiagramm

Kommunikationsdiagramm (Kommunikationsdiagramm) - eine Methode zur Beschreibung des Verhaltens, die semantisch einem Sequenzdiagramm entspricht.

Tatsächlich ist dies dieselbe Beschreibung der Nachrichtenaustauschsequenz interagierender Klassifiziererinstanzen, die nur in anderen grafischen Mitteln ausgedrückt wird. Darüber hinaus können die meisten Tools Sequenzdiagramme automatisch in Kommunikationsdiagramme konvertieren und umgekehrt.

Somit wird sowohl im Kommunikationsdiagramm als auch im Sequenzdiagramm ein Haupttyp von Entitäten verwendet - Instanzen von interagierenden Klassifizierern 1 und ein Typ von Beziehungsverbindungen 2. Der Schwerpunkt liegt hier jedoch nicht auf der Zeit, sondern auf der Struktur der Verknüpfungen zwischen bestimmten Instanzen.

Die Abbildung zeigt die grundlegenden Elemente der Notation, die in einem Kommunikationsdiagramm verwendet werden. Um die interagierenden Objekte selbst zu bestimmen, wird die Standardnotation verwendet - ein Rechteck mit dem Namen der Klassifiziererinstanz. Die relative Position von Elementen im Kooperationsdiagramm spielt keine Rolle - nur die Verbindungen (meistens Assoziationsfälle) sind wichtig, entlang derer Nachrichten übertragen werden 3. Die hierarchische Dezimalnummerierung wird verwendet, um die Reihenfolge der Nachrichten über die Zeit anzuzeigen.

1.5.7. Komponentendiagramm

Komponentendiagramm (Komponentendiagramm) - zeigt die Beziehungen zwischen Modulen (logisch oder physikalisch), aus denen das simulierte System besteht.

Der Haupttyp der Entitäten im Komponentendiagramm sind die Komponenten 1 selbst sowie die Schnittstellen 2, über die die Beziehung zwischen den Komponenten angegeben wird. In einem Komponentendiagramm gelten folgende Beziehungen:

  • implementierungen zwischen Komponenten und Schnittstellen (eine Komponente implementiert eine Schnittstelle);
  • abhängigkeiten zwischen Komponenten und Schnittstellen (Komponente verwendet eine Schnittstelle) 3.

Die Abbildung zeigt die grundlegenden Elemente der Notation, die in einem Komponentendiagramm verwendet werden. Eine ausführliche Beschreibung finden Sie in Kapitel 3.

1.5.8. Platzierungsdiagramm

Platzierungsdiagramm (Bereitstellungsdiagramm) zeigt zusammen mit der Anzeige der Zusammensetzung und der Beziehungen von Systemelementen, wie sie sich zur Laufzeit physisch auf Computerressourcen befinden.

Daher werden im Platzierungsdiagramm im Vergleich zum Komponentendiagramm zwei Arten von Entitäten hinzugefügt: Artefakt 1, bei dem es sich um die Implementierung von Komponente 2 und Knoten 3 handelt (es kann sich entweder um einen Klassifizierer handeln, der den Typ eines Knotens beschreibt, oder um eine bestimmte Instanz), sowie um eine Zuordnungsbeziehung zwischen Knoten 4, die zeigen, dass die Knoten zur Laufzeit physisch verbunden sind.

Die Abbildung zeigt die Grundelemente der im Platzierungsdiagramm verwendeten Notation. Um zu zeigen, dass eine Entität Teil einer anderen ist, wird entweder die Abhängigkeitsbeziehung "Bereitstellen" 5 angewendet oder die Form einer Entität wird innerhalb der Form einer anderen Entität 6 platziert. Eine ausführliche Beschreibung des Diagramms finden Sie in Kapitel 3.

11.1. Struktur der einheitlichen Modellierungssprache

Einheitliche Modellierungssprache (UML) ist derzeit der De-facto-Standard zur Beschreibung (Dokumentation) der Ergebnisse des Entwurfs und der Entwicklung objektorientierter Systeme. Die UML-Entwicklung begann 1994 mit Grady Booch und James Rambeau von Rational Software. Im Herbst 1995 trat Ivar Jacobson ihnen bei und im Oktober desselben Jahres wurde eine vorläufige Version 0.8 der Unified Method veröffentlicht. Seitdem wurden mehrere Versionen der UML-Spezifikation veröffentlicht, von denen zwei den Status eines internationalen Standards haben:

UML 1.4.2 - "ISO / IEC 19501: 2005. Informationstechnologie. Offene verteilte Verarbeitung. Einheitliche Modellierungssprache (UML). Version 1.4.2" (dt. "Informationstechnologie. Offene verteilte Verarbeitung. Einheitliche Modellierungssprache (UML). Version 1.4.2 ");

UML 2.4.1 - "ISO / IEC 19505-1: 2012. Informationstechnologie. OMG UML. Teil 1. Infrastruktur" (dt. "Informationstechnologie - Objektverwaltungsgruppe Unified Modeling Language ( OMG UML) - Teil 1: Infrastruktur ") und" ISO / IEC 19505-2: 2012. Informationstechnologie. Modellierungssprache für Unified Object Management Group (OMG UML). Teil 2. Überbau "(dt." Informationstechnologie - Objekt Unified Modeling Language (OMG UML) der Verwaltungsgruppe - Teil 2: Überbau ").

Die neueste offizielle Sprachspezifikation finden Sie unter www.omg.org.

Die allgemeine Struktur der UML ist in der folgenden Abbildung dargestellt.

Zahl: 11.1. UML-Struktur

11.2. UML-Semantik und -Syntax

Semantik - ein Abschnitt der Linguistik, der die Bedeutung von Spracheinheiten untersucht, hauptsächlich ihre Wörter und Phrasen.

Syntax - Möglichkeiten, Wörter und ihre Formen zu Phrasen und Sätzen zu kombinieren, Sätze zu komplexen Sätzen zu kombinieren und Aussagen als Teil des Textes zu erstellen.

In Bezug auf die UML definieren Semantik und Syntax einen Präsentationsstil (Modellbildung), der natürliche und formale Sprachen kombiniert, um grundlegende Konzepte (Modellelemente) und Mechanismen für deren Erweiterung darzustellen.

11.3. UML-Notation

Notation ist eine grafische Interpretation der Semantik für ihre visuelle Darstellung.

Die UML definiert drei entitätstyp :

Strukturell - eine Abstraktion, die ein konzeptuelles oder physisches Objekt widerspiegelt;

Gruppierung - ein Element, das für eine semantische Vereinheitlichung von Diagrammelementen verwendet wird;

Erläuterung (Anmerkung) - Ein Kommentar zu einem Diagrammelement.

Die folgende Tabelle enthält eine kurze Beschreibung der wichtigsten Entitäten, die in der grafischen Notation verwendet werden, und der wichtigsten Möglichkeiten, sie anzuzeigen.

Tabelle 11.1. Entitäten

Eine Art Name Bezeichnung Definition (Semantik)
Strukturell
(Klasse)
Viele Objekte mit einer gemeinsamen Struktur und einem gemeinsamen Verhalten

(Objekt)
Eine Abstraktion einer realen oder imaginären Entität mit klar definierten konzeptuellen Grenzen, Individualität (Identität), Zustand und Verhalten. Aus UML-Sicht sind Objekte Klasseninstanzen (Entitätsinstanzen).

(Darsteller)

Techniker
Pfaddienste
Eine Entität außerhalb des Systems, die mit dem System interagiert und dessen Funktionalität verwendet, um bestimmte Ziele zu erreichen oder bestimmte Probleme zu lösen. Somit ist der Akteur eine externe Informationsquelle oder ein externer Informationsempfänger.

(Anwendungsfall)
Beschreibung der vom System ausgeführten Aktionen, die zu einem signifikanten Ergebnis für den Akteur führen

(Zustand)
Beschreibung des Momentes im Leben eines Unternehmens, in dem es eine bestimmte Bedingung erfüllt, eine Aktivität ausführt oder auf das Eintreten eines Ereignisses wartet
Zusammenarbeit
(Zusammenarbeit)
Beschreibung einer Reihe von Instanzen von Akteuren, Objekten und deren Interaktion bei der Lösung eines bestimmten Problems

(Komponente)
Der physische Teil des Systems (Datei), einschließlich Systemmodule, die die Implementierung eines konsistenten Satzes von Schnittstellen ermöglichen

(Schnittstelle)

iBerechnung
Eine Reihe von Operationen, die einen Dienst (eine Reihe von Diensten) definieren, der von einer Klasse oder Komponente bereitgestellt wird

(Knoten)
Der physische Teil des Systems (Computer, Drucker usw.), der Ressourcen zur Lösung des Problems bereitstellt
Gruppierung
(Paket)
Allgemeiner Mechanismus zum Gruppieren von Elementen.
Im Gegensatz zu einer Komponente ist ein Paket ein rein konzeptionelles (abstraktes) Konzept. Besondere Fälle des Pakets sind das System und das Modell

(Fragment)
Der Bereich der spezifischen Interaktion zwischen Akteur- und Objektinstanzen

(Aktivitätspartition)
Eine Gruppe von Operationen (Verantwortungsbereich), die von einer Entität (Akteur, Objekt, Komponente, Knoten usw.) ausgeführt werden.

(unterbrechbare Aktivitätsregion)
Eine Gruppe von Operationen, deren normale Abfolge aufgrund des Einsetzens einer nicht standardmäßigen Situation unterbrochen werden kann
Erklären Hinweis
(Kommentar)
Artikelkommentar. Wird mit einer gestrichelten Linie an das kommentierte Element angehängt

Einige Quellen, insbesondere [,], unterscheiden auch Verhaltensentitäten wechselwirkungen und endliche ZustandsmaschinenAus logischer Sicht sollten sie jedoch als Diagramme klassifiziert werden.

Einige der oben genannten Entitäten implizieren ihre detaillierte Beschreibung in Zerlegungsdiagrammen. Im Diagramm der obersten Ebene sind sie mit einem speziellen Symbol oder einer speziellen Beschriftung gekennzeichnet.

Die folgende Tabelle enthält eine Beschreibung aller Typen beziehungen UML wird in Diagrammen verwendet, um Beziehungen zwischen Entitäten anzuzeigen.

Tabelle 11.3. Beziehungen

Name Bezeichnung Definition (Semantik)
Verband Eine Beziehung, die eine sinnvolle Beziehung zwischen zwei oder mehr Entitäten beschreibt. Die allgemeinste Art von Beziehung
Anhäufung Ein Subtyp der Assoziation, der die Beziehung "Teil" - "Ganzes" beschreibt, in der der "Teil" getrennt vom "Ganzen" existieren kann. Die Raute wird von der "ganzen" Seite angezeigt. Die Beziehung wird nur zwischen Entitäten desselben Typs angezeigt
Komposition Ein Subtyp der Aggregation, in dem "Teile" nicht getrennt vom "Ganzen" existieren können. In der Regel werden "Teile" gleichzeitig mit dem "Ganzen" erstellt und zerstört.
Abhängigkeit Eine Beziehung zwischen zwei Entitäten, bei der eine Änderung in einer Entität (unabhängig) den Status oder das Verhalten einer anderen Entität (abhängig) beeinflussen kann. Eine unabhängige Entität wird auf der Seite des Pfeils angezeigt
Verallgemeinerung Die Beziehung zwischen einer generischen Entität (Vorfahr, Elternteil) und einer spezialisierten Entität (Kind, Kind). Das Dreieck wird von der übergeordneten Seite angezeigt. Die Beziehung wird nur zwischen Entitäten desselben Typs angezeigt
Realisierung Eine Beziehung zwischen Entitäten, bei der eine Entität eine Aktion definiert, die eine andere Entität ausführen soll. Beziehungen werden in zwei Fällen verwendet: zwischen Schnittstellen und Klassen (oder Komponenten), zwischen Anwendungsfällen und Kollaborationen. Die Pfeilseite zeigt die Entität an, die die Aktion definiert (Schnittstelle oder Anwendungsfall).

Für Assoziation, Aggregation und Zusammensetzung, vielzahl (Englische Multiplizität), die die Gesamtzahl der Instanzen von Entitäten kennzeichnet, die an der Beziehung teilnehmen. Es wird normalerweise auf jeder Seite der Beziehung in der Nähe der entsprechenden Entität angezeigt. Die Multiplizität kann auf folgende Arten angegeben werden:

- * - eine beliebige Anzahl von Kopien, einschließlich keiner;

Nicht negative ganze Zahl - die Multiplizität ist streng festgelegt und entspricht der angegebenen Zahl (zum Beispiel: 1, 2 oder 5);

Bereich nicht negativer Ganzzahlen "erste Zahl .. zweite Zahl" (zum Beispiel: 1..5, 2..10 oder 0..5);

Ein Zahlenbereich von einem bestimmten Anfangswert bis zu einer beliebigen endgültigen "ersten Zahl .. *" (zum Beispiel: 1 .. *, 5 .. * oder 0 .. *);

Aufzählung nicht negativer Ganzzahlen und durch Kommas getrennter Bereiche (zum Beispiel: 1, 3..5, 10, 15 .. *).

Wenn die Multiplizität nicht angegeben wird, wird angenommen, dass ihr Wert 1 ist. Die Multiplizität der Entitätsinstanzen, die an der Abhängigkeit, Verallgemeinerung und Implementierung teilnehmen, wird immer als 1 angenommen.

Die folgende Tabelle beschreibt mechanismen zu erweitern wird verwendet, um die Semantik von Entitäten und Beziehungen zu klären. Im Allgemeinen ist ein Erweiterungsmechanismus eine Textzeichenfolge in Klammern oder Anführungszeichen.

Tabelle 11.4. Verlängerungsmechanismen

Name Bezeichnung Definition (Semantik)
Stereotyp
(Stereotyp)
« » Eine Bezeichnung, die die Semantik eines Notationselements angibt (z. B. eine Abhängigkeit mit dem Stereotyp "include" wird als Einschlussbeziehung behandelt, und eine Klasse mit dem Stereotyp "border" ist eine Grenzklasse).
Wachzustand
(Wachzustand)
Boolesche Bedingung (zum Beispiel: oder [Identifizierung abgeschlossen])
Einschränkung
(Zwang)
{ } Regel zur Einschränkung der Semantik des Modellelements (z. B. (Ausführungszeit weniger als 10 ms))
Markierter Wert
(markierter Wert)
{ } Neue oder qualifizierende Eigenschaft eines Notationselements (zum Beispiel: (Version \u003d 3.2))

Zusätzlich zu Stereotypen, die in Anführungszeichen als Textzeichenfolge angegeben sind, können grafische Stereotypen in Diagrammen verwendet werden. Die folgende Abbildung zeigt Beispiele für Standard- und stereotype Anzeigen.

a) Standardbezeichnung b) Standardbezeichnung
mit Textstereotyp
c) grafisches Stereotyp

Zahl: 11.2. Beispiele für Standard- und stereotype Klassenanzeige

Diagramm ist eine Gruppierung von Notationselementen, um einen Aspekt des zu entwickelnden Informationssystems darzustellen. Diagramme sind normalerweise zusammenhängende Diagramme, in denen Entitäten Eckpunkte und Beziehungen Bögen sind. Die folgende Tabelle enthält eine kurze Beschreibung der UML-Diagramme.

Tabelle 11.5. Diagramme

Diagramm Geplanter Termin
durch den Grad der physischen Verwirklichung durch Anzeige der Dynamik nach angezeigtem Aspekt

(Anwendungsfall)
Zeigt Systemfunktionen, Interaktion zwischen Akteuren und Funktionen an Logisch Statisch Funktionell

(Klasse)
Zeigt eine Reihe von Klassen, Schnittstellen und Beziehungen zwischen ihnen an Logisch oder
physisch
Statisch Funktional und informativ

(Paket)
Zeigt eine Reihe von Paketen und die Beziehung zwischen ihnen an Logisch oder
physisch
Statisch Komponente
Verhalten
(Verhalten)

(Zustandsmaschine)
Zeigt die Zustände einer Entität und Übergänge zwischen ihnen während ihres Lebenszyklus an Logisch Dynamisch Verhalten

(Aktivität)
Zeigt Geschäftsprozesse im System an (Beschreibung der Verhaltensalgorithmen)
Interaktionen
(Interaktion)

(Reihenfolge)
Zeigt die Reihenfolge der Nachrichtenübermittlung zwischen Objekten und Akteuren an

(Kommunikation)
Ähnlich wie bei einem Sequenzdiagramm, jedoch liegt der Schwerpunkt auf der Struktur der Interaktionen zwischen Objekten
Implementierung
(Implementierung)

(Komponente)
Zeigt Systemkomponenten (Programme, Bibliotheken, Tabellen usw.) und die Verknüpfungen zwischen ihnen an Körperlich Statisch Komponente

(Einsatz)
Zeigt die Platzierung von Komponenten nach Hosts sowie deren Konfiguration an

Der UML 2.x-Standard definiert außerdem zusätzliche, hochspezialisierte Diagramme:

Ein Objektdiagramm ist ähnlich, aber Objekte werden anstelle von Klassen angezeigt.

Zeitdiagramm - beschreibt den Zustand eines Objekts über die Zeit;

Zusammengesetztes Strukturdiagramm - beschreibt die Ports (einschließlich Schnittstellen) einer Klasse für die Interaktion mit anderen Klassen;

Profildiagramm - ähnlich der Beschreibung der darin enthaltenen Klassen;

Das Interaktionsübersichtsdiagramm ist ähnlich, jedoch mit versteckten Interaktionsfragmenten (Fragmente mit einem ref-Tag). Es ist eine kontextuelle (konzeptionelle), deren Elemente in separaten Zerlegungsdiagrammen konkretisiert werden.

Für eine erweiterte konzeptionelle Darstellung der internen Architektur des Systems erlaubt der Großteil während der Konstruktion die Verwendung etablierter grafischer Stereotypen für die sogenannten. Ein solches Diagramm heißt 1, gehört jedoch nicht zur Liste der durch den UML-Standard definierten Diagramme.

Bei der Entwicklung eines separaten Modells des Systems werden verschiedene Diagrammtypen erstellt. Darüber hinaus werden bei der Entwicklung eines Modells eines komplexen Systems in der Regel mehrere Diagramme desselben Typs erstellt. Gleichzeitig ist es möglich, keine separaten Diagrammtypen zu erstellen, wenn dies nicht erforderlich ist. Beispielsweise sind Diagramme und austauschbar, sie werden nur für Objekte mit komplexem Verhalten erstellt. Die folgende Tabelle enthält Anleitungen zur Notwendigkeit, Diagramme nach Systemmodell zu entwickeln (zu verfeinern).

Tabelle 11.6. Modelle und Diagramme verknüpfen

Die Tabelle zeigt das Testmodell nicht, da im Rahmen seiner Konstruktion keine Diagramme entwickelt, sondern auf Vollständigkeit und Konsistenz überprüft (getestet) werden.

Ein Teil der Diagramme nach ihrer Erstellung erfordert die Entwicklung und Verfeinerung im Rahmen der Entwicklung des nächsten Modells (technologischer Prozess). So sollte zum Beispiel bei der Entwicklung geklärt werden. In Modellen.

4. Definieren Sie das Konzept "".

Die UML ist eine universelle grafische Modellierungssprache zum Spezifizieren, Visualisieren, Entwerfen und Dokumentieren aller Artefakte, die bei der Entwicklung von Softwaresystemen entstehen.

Es gibt viele gute Bücher, die ausführlich über die UML beschreiben (manchmal sogar sehr detailliert). Ich möchte die grundlegenden Konzepte über Diagramme, Entitäten und Beziehungen zwischen ihnen an einer Stelle sammeln, um sie schnell wieder aufzurufen, so etwas wie einen Spickzettel.

Die Notiz verwendet Materialien aus Büchern: Ivanov D. Yu., Novikov F. A. Einheitliche Modellierungssprache UML und Leonenkov. UML-Tutorial.

Beginnen wir mit dem Editor. Unter Linux habe ich verschiedene UML-Editoren ausprobiert. Am meisten hat mir das UMLet gefallen, obwohl es in Java geschrieben ist, sich sehr schnell bewegt und die meisten Entitätsvorlagen darin enthalten sind. Es gibt auch ArgoUML, einen plattformübergreifenden UML-Editor, der ebenfalls in Java geschrieben ist, funktionsreich ist, aber mehr verlangsamt.

Ich entschied mich für UMLet, setze es unter Arch Linux und Ubuntu:

# für Arch Linux yaourt -S umlet # Für Ubuntu sudo apt-get install umlet

In UML können alle Entitäten in die folgenden Typen unterteilt werden:

  • strukturell;
  • verhalten;
  • gruppierung;
  • anmerkung;

In der UML werden vier Haupttypen von Beziehungen verwendet:

Abhängigkeit - zeigt an, dass sich eine Änderung in einer unabhängigen Entität irgendwie auf die abhängige Entität auswirkt. Grafisch wird eine Abhängigkeitsbeziehung als gestrichelte Linie dargestellt, wobei ein Pfeil von der abhängigen Entität zur unabhängigen Entität zeigt.

Verband - findet statt, wenn eine Entität direkt mit einer anderen verbunden ist (oder mit anderen - die Zuordnung kann nicht nur binär sein). Die Zuordnung wird grafisch als durchgezogene Linie mit verschiedenen Ergänzungen dargestellt, die verwandte Entitäten verbinden.

Verallgemeinerung ist eine Beziehung zwischen zwei Entitäten, von denen eine ein spezieller (spezialisierter) Fall der anderen ist. Grafisch wird die Verallgemeinerung als eine Linie mit einem dreieckigen, nicht schattierten Pfeil am Ende dargestellt, der von der bestimmten (Unterklasse) zur allgemeinen (Oberklasse) gerichtet ist.

Implementierung - Eine Implementierungsbeziehung zeigt an, dass eine Entität eine Implementierung einer anderen ist. Grafisch ist die Implementierung als gestrichelte Linie mit einem dreieckigen unbemalten Pfeil am Ende dargestellt, der von der realisierenden Entität zur realisierbaren Entität gerichtet ist.

BEIM UML 2 definiert 13 Arten von Diagrammen. Standardmäßig sollte jedes Diagramm ein Feld mit einem Rechteck (untere rechte Ecke abgeschrägt) in der oberen linken Ecke haben, das die Diagramm-ID (Tag) und den Titel angibt.

Diagramme zur Darstellung der Systemstruktur:

  • Komponentendiagramm (Tag komponente);
  • Bereitstellungsdiagramm (Tag einsatz);
  • Klassendiagramm (Klassendiagramm, Tag klasse);
  • Objektdiagramm (Tag objekt);
  • Internes Strukturdiagramm (zusammengesetztes Strukturdiagramm, Tag klasse);

Diagramme zur Darstellung des Systemverhaltens:

  • Interaktionsdiagramm (Tag zeitliche Koordinierung);
  • Aktivitätsdiagramm (Tag aktivität);
  • Sequenzdiagramm (Tag sd);
  • Kommunikationsdiagramm (Tag comm);
  • Zustandsmaschinendiagramm (Tag zustandsmaschine);
  • Interaktionsübersicht Diagramm Tag interaktion);

Diagramme unterscheiden sich:

  • Nutzungsdiagramm (Anwendungsfalldiagramm, Anwendungsfall-Tag);
  • Paketdiagramm (Tag paket);

Nutzungsdiagramm

Nutzungsdiagramm (Anwendungsfalldiagramm) ist die allgemeinste Darstellung des Funktionszwecks des Systems.

Wenn man ein Anwendungsfalldiagramm als Modell eines Systems betrachtet, kann man es einem Black-Box-Modell zuordnen. Jeder Anwendungsfall definiert eine Folge von Aktionen, die vom entworfenen System ausgeführt werden müssen, wenn es mit dem entsprechenden Akteur interagiert.

Das Verwendungsdiagramm verwendet zwei Arten von grundlegenden Entitäten: Anwendungsfälle und Akteure, zwischen denen die folgenden grundlegenden Arten von Beziehungen hergestellt werden.

Assoziationsbeziehung - Diese Beziehung legt fest, welche spezifische Rolle der Akteur bei der Interaktion mit der Anwendungsfallinstanz spielt. Eine Assoziationsbeziehung wird durch eine durchgezogene Linie zwischen dem Akteur und dem Anwendungsfall angezeigt. Diese Zeile kann zusätzliche Symbole wie Name und Multiplizität enthalten.

Expansionsverhältnis - definiert, wie sich die Instanzen eines bestimmten Anwendungsfalls auf einen allgemeineren Anwendungsfall beziehen, dessen Eigenschaften basierend auf der Kombination dieser Instanzen bestimmt werden. Wenn also eine Erweiterungsbeziehung von Anwendungsfall A zu Anwendungsfall B besteht, bedeutet dies, dass die Eigenschaften der Instanz von Anwendungsfall B aufgrund der Eigenschaften von erweitertem Anwendungsfall A erweitert werden können.

Eine Erweiterungsbeziehung zwischen Anwendungsfällen wird durch eine gestrichelte Linie mit einem Pfeil (Abhängigkeitsbeziehungsfall) angezeigt, der vom Anwendungsfall weg zeigt, der eine Erweiterung des ursprünglichen Anwendungsfalls darstellt.

Verallgemeinerungsbeziehung dient dazu, die Tatsache anzuzeigen, dass ein Anwendungsfall A auf Anwendungsfall B verallgemeinert werden kann. In diesem Fall ist Variante A eine Spezialisierung von Variante B. In diesem Fall wird B als Vorfahr oder Elternteil von A bezeichnet, und Variante A ist ein Nachkomme von Variante mit V.

Grafisch wird diese Beziehung durch eine durchgezogene Linie mit einem offenen Dreieckspfeil gekennzeichnet, der den übergeordneten Anwendungsfall angibt.

Eine Verallgemeinerungsbeziehung zwischen Anwendungsfällen wird verwendet, wenn Sie beachten möchten, dass untergeordnete Anwendungsfälle alle Attribute und Verhaltensweisen der übergeordneten Anwendungsfälle aufweisen.

Einschlussquote Zwischen zwei Anwendungsfällen gibt an, dass ein bestimmtes Verhalten für einen Anwendungsfall als zusammengesetzte Komponente in der Verhaltenssequenz eines anderen Anwendungsfalls enthalten ist.

Eine Einschlussbeziehung von Anwendungsfall A zu Anwendungsfall B zeigt an, dass jede Instanz von Option A die für Option B angegebene Funktionalität enthält.

Grafisch wird diese Beziehung durch eine gestrichelte Linie mit einem Pfeil (Option für Abhängigkeitsbeziehung) vom Basisanwendungsfall zum eingeschlossenen Anwendungsfall gekennzeichnet.

Klassen Diagramm

Klassen Diagramm (Klassendiagramm) ist die Hauptmethode zur Beschreibung der statischen Struktur eines Systems.

In einem Klassendiagramm wird ein Haupttyp von Entitäten verwendet: Klassen (einschließlich zahlreicher Sonderfälle von Klassen: Schnittstellen, primitive Typen, Assoziationsklassen usw.), zwischen denen die folgenden grundlegenden Arten von Beziehungen hergestellt werden: Abhängigkeiten, Assoziationen, Verallgemeinerungen, Implementierungen.

Suchtbeziehung zeigt im Allgemeinen eine semantische Beziehung zwischen zwei Modellelementen oder zwei Sätzen solcher Elemente an, die keine Assoziations-, Generalisierungs- oder Implementierungsbeziehung ist. Eine Abhängigkeitsbeziehung wird in einer Situation verwendet, in der eine Änderung in einem Modellelement möglicherweise eine Änderung in einem anderen abhängigen Modellelement erfordert.

Eine Abhängigkeitsbeziehung wird grafisch als gestrichelte Linie zwischen den entsprechenden Elementen mit einem Pfeil an einem ihrer Enden dargestellt, wobei der Pfeil von der Abhängigkeitsclientklasse zur unabhängigen Klasse oder Quellklasse zeigt.

Über dem Pfeil befinden sich möglicherweise spezielle Schlüsselwörter (Stereotypen):

  • "Zugriff" - dient dazu, die Zugänglichkeit öffentlicher Attribute und Operationen der Quellklasse für Clientklassen anzuzeigen;
  • "bind" - Die Client-Klasse kann eine Vorlage für die nachfolgende Parametrisierung verwenden.
  • "ableiten" - Die Attribute der Client-Klasse können aus den Attributen der Quellklasse berechnet werden.
  • "import" - öffentliche Attribute und Operationen der Quellklasse werden Teil der Client-Klasse, als ob sie direkt darin deklariert wären;
  • "verfeinern" - gibt an, dass die Client-Klasse aus historischen Gründen als Verfeinerung der Quellklasse dient, wenn während der Arbeit am Projekt zusätzliche Informationen angezeigt werden.

Assoziationsbeziehung entspricht einer Beziehung zwischen den Klassen. Diese Beziehung wird durch eine durchgezogene Linie mit zusätzlichen speziellen Symbolen angezeigt, die einzelne Eigenschaften einer bestimmten Assoziation charakterisieren. Der Name der Assoziation sowie die Namen und die Vielzahl der Rollenklassen der Assoziation können als zusätzliche Sonderzeichen verwendet werden. Der Name einer Vereinigung ist ein optionales Element ihrer Bezeichnung.

Aggregationsverhältnis findet zwischen mehreren Klassen statt, falls eine der Klassen eine bestimmte Entität ist, die andere Entitäten als Bestandteile enthält. Wird verwendet, um Teil-zu-Ganz-System-Beziehungen darzustellen.

Zusammensetzungsbeziehung ist ein Sonderfall einer Aggregationsbeziehung. Diese Beziehung dient dazu, eine spezielle Form der Beziehung "Teil-Ganzes" hervorzuheben, in der sich die Bestandteile in gewissem Sinne innerhalb des Ganzen befinden. Die Besonderheit der Beziehung zwischen ihnen liegt in der Tatsache, dass die Teile nicht isoliert vom Ganzen wirken können, dh mit der Zerstörung des Ganzen werden alle seine Bestandteile zerstört.

Verallgemeinerungsbeziehung ist eine Beziehung zwischen einem allgemeineren Element (Elternteil oder Vorfahr) und einem privateren oder spezielleren Element (Kind oder Nachkomme). Bei Anwendung auf ein Klassendiagramm beschreibt diese Beziehung die hierarchische Struktur von Klassen und die Vererbung ihrer Eigenschaften und ihres Verhaltens. Dies setzt voraus, dass die Nachkommenklasse alle Eigenschaften und das Verhalten der Vorfahrenklasse sowie ihre eigenen Eigenschaften und Verhaltensweisen hat, die die Vorfahrenklasse nicht hat.

Automatendiagramm

Automatendiagramm (Zustandsmaschinendiagramm) oder zustandsdiagramm In UML 1 (Zustandsdiagramm) ist eine Möglichkeit, das Verhalten in UML detailliert zu beschreiben. Im Wesentlichen sind Automatendiagramme, wie der Name schon sagt, ein Diagramm von Zuständen und Übergängen eines endlichen Automaten, der mit vielen zusätzlichen Details und Details geladen ist.

Ein Zustandsdiagramm beschreibt den Prozess des Änderns der Zustände nur einer Klasse bzw. einer Instanz einer bestimmten Klasse, dh es modelliert alle möglichen Änderungen des Zustands eines bestimmten Objekts. In diesem Fall kann eine Änderung des Zustands eines Objekts durch äußere Einflüsse von anderen Objekten oder von außen verursacht werden. Um die Reaktion eines Objekts auf solche äußeren Einflüsse zu beschreiben, werden Zustandsdiagramme verwendet.

Im Automatendiagramm wird ein Haupttyp von Entitäten verwendet - Zustände und ein Typ von Beziehungsübergängen -, aber für beide werden viele Sorten, Sonderfälle und zusätzliche Notationen definiert. Der Automat repräsentiert die dynamischen Aspekte des modellierten Systems in Form eines gerichteten Graphen, dessen Eckpunkte Zuständen entsprechen und dessen Bögen Übergängen entsprechen.

Ausgangszustand ist ein Sonderfall eines Zustands, der keine internen Aktionen enthält (Pseudozustände). Das Standardobjekt befindet sich zum ersten Mal in diesem Zustand. Es dient dazu, im Zustandsdiagramm den Grafikbereich anzuzeigen, von dem aus der Zustandsübergangsprozess beginnt.

Finale (endgültig) Ein Zustand ist ein Sonderfall eines Zustands, der auch keine internen Aktionen enthält (Pseudozustände). Das Standardobjekt befindet sich in diesem Zustand, nachdem der Automat seine Arbeit zum letzten Mal beendet hat.

Aktivitätsdiagramm

Bei der Modellierung des Verhaltens eines entworfenen oder analysierten Systems muss nicht nur der Prozess der Änderung seiner Zustände dargestellt werden, sondern auch die Merkmale der algorithmischen und logischen Implementierung der vom System ausgeführten Operationen detailliert beschrieben werden.

Aktivitätsdiagramm (Aktivitätsdiagramm) ist eine andere Möglichkeit, Verhalten zu beschreiben, das visuell einem guten alten Flussdiagramm des Algorithmus ähnelt. Wird verwendet, um den Prozess der Ausführung von Vorgängen zu simulieren.

Die Hauptrichtung bei der Verwendung von Aktivitätsdiagrammen besteht darin, die Implementierungsmerkmale von Klassenoperationen zu visualisieren, wenn Algorithmen für deren Ausführung vorgestellt werden müssen.

Im Aktivitätsdiagramm wird ein Hauptentitätstyp verwendet - Aktion und ein Typ von Beziehungsübergängen (Kontrollübertragungen). Es werden auch Konstruktionen wie Gabeln, Zusammenführungen, Verknüpfungen und Zweige verwendet. Es wird empfohlen, ein Verb mit erklärenden Wörtern als einfachen Aktionsnamen zu verwenden.

Sequenzdiagramm

Sequenzdiagramm (Sequenzdiagramm) beschreibt das Systemverhalten "anhand von Beispielen".

Tatsächlich ist ein Sequenzdiagramm eine Aufzeichnung des Protokolls einer bestimmten Sitzung der Systemoperation (oder eines Fragments eines solchen Protokolls). Bei der objektorientierten Programmierung ist die Übertragung von Nachrichten zwischen kommunizierenden Objekten die wichtigste Laufzeit. In diesem Diagramm wird die Reihenfolge des Sendens von Nachrichten angezeigt, daher der Name.

Im Sequenzdiagramm wird ein Hauptentitätstyp verwendet - Instanzen interagierender Klassifizierer (hauptsächlich Klassen, Komponenten und Akteure) und ein Beziehungstyp - die Links, über die Nachrichten ausgetauscht werden.

Mögliche Nachrichtentypen (Bild aus larin.in):

Kommunikationsdiagramm

Kommunikationsdiagramm (Kommunikationsdiagramm) - eine Methode zur Beschreibung des Verhaltens, die semantisch einem Sequenzdiagramm entspricht. Tatsächlich ist dies dieselbe Beschreibung der Nachrichtenaustauschsequenz interagierender Klassifiziererinstanzen, die nur in anderen grafischen Mitteln ausgedrückt wird.

Daher wird sowohl im Kommunikationsdiagramm als auch im Sequenzdiagramm ein Hauptentitätstyp verwendet - Instanzen interagierender Klassifizierer und ein Typ von Beziehungsverbindungen. Der Schwerpunkt liegt hier jedoch nicht auf der Zeit, sondern auf der Struktur der Verknüpfungen zwischen bestimmten Instanzen.

Komponentendiagramm

Komponentendiagramm (Komponentendiagramm) - zeigt die Beziehung zwischen Modulen (logisch oder physikalisch), aus denen das simulierte System besteht.

Der Haupttyp von Entitäten in einem Komponentendiagramm sind die Komponenten selbst sowie die Schnittstellen, über die die Beziehung zwischen Komponenten angezeigt wird. In einem Komponentendiagramm gelten folgende Beziehungen:

  • implementierungen zwischen Komponenten und Schnittstellen (eine Komponente implementiert eine Schnittstelle);
  • abhängigkeiten zwischen Komponenten und Schnittstellen (eine Komponente verwendet eine Schnittstelle);

Platzierungsdiagramm

Platzierungsdiagramm (Bereitstellungsdiagramm) zeigt zusammen mit der Anzeige der Zusammensetzung und der Beziehungen von Systemelementen, wie sie sich zur Laufzeit physisch auf Computerressourcen befinden.

Im Platzierungsdiagramm werden im Vergleich zum Komponentendiagramm zwei Arten von Entitäten hinzugefügt: ein Artefakt, bei dem es sich um die Implementierung einer Komponente und eines Knotens handelt (es kann sich entweder um einen Klassifizierer handeln, der den Typ eines Knotens beschreibt, oder um eine bestimmte Instanz) sowie eine Zuordnungsbeziehung zwischen Knoten, die diese Knoten anzeigt zur Laufzeit physisch verbunden.

Objektdiagramm

Objektdiagramm (Objektdiagramm) - ist eine Instanz eines Klassendiagramms.

Im Objektdiagramm wird ein Hauptentitätstyp verwendet: Objekte (Klasseninstanzen), zwischen denen bestimmte Beziehungen angegeben werden (meistens Assoziationsinstanzen). Objektdiagramme sind Hilfsdiagramme - tatsächlich handelt es sich um Beispiele (man könnte sagen, Speicherauszüge), die zeigen, was Objekte sind und welche Verbindungen zwischen ihnen zu einem bestimmten Zeitpunkt in der Funktionsweise des Systems bestehen.

Internes Strukturdiagramm (zusammengesetztes Strukturdiagramm) wird für eine detailliertere Darstellung von Strukturklassifikatoren verwendet, hauptsächlich Klassen und Komponenten.

Der strukturelle Klassifikator wird als Rechteck mit dem Namen des Klassifikators oben angezeigt. Im Inneren befinden sich Teile. Es kann mehrere Teile geben. Teile können miteinander interagieren. Dies wird durch Anschlüsse verschiedener Art angezeigt. Die Position an der Außenkante des Teils, an dem der Anschluss befestigt ist, wird als Anschluss bezeichnet. Die Anschlüsse befinden sich auch am äußeren Rand des Strukturklassifikators.

Interaktionsübersichtsdiagramm Ein Interaktionsübersichtsdiagramm ist eine Art Aktivitätsdiagramm mit einer erweiterten Syntax: Interaktionsnutzungslinks, die durch Sequenzdiagramme definiert sind, können als Elemente eines Interaktionsübersichtsdiagramms fungieren.

Synchronisationsdiagramm

Synchronisationsdiagramm (Timing-Diagramm) ist eine spezielle Form des Sequenzdiagramms, bei der besonderes Augenmerk auf die Änderung der Zustände verschiedener Instanzen von Klassifizierern und deren Timing gelegt wird.

Paketdiagramm

Paketdiagramm (Paketdiagramm) ist das einzige Tool, mit dem Sie die Komplexität des Modells selbst verwalten können.

Die Hauptelemente der Notation sind Pakete und Abhängigkeiten mit unterschiedlichen Stereotypen.

Entity-Relationship-Modell (ER-Modell)

Analog klassendiagramme (UML) vielleicht ER-Modell, die beim Entwurf von Datenbanken verwendet wird (relationales Modell).

Das Entity-Relationship-Modell (ER-Modell) ist ein Datenmodell, mit dem Sie konzeptionelle Schemata der Domäne beschreiben können. Das ER-Modell wird beim (konzeptionellen) Datenbankdesign auf hoher Ebene verwendet. Mit seiner Hilfe ist es möglich, die Schlüsselentitäten hervorzuheben und die Verbindungen zu bestimmen, die zwischen diesen Entitäten hergestellt werden können. Wikipedia

Jedes Fragment des Themenbereichs kann als eine Reihe von Entitäten dargestellt werden, zwischen denen eine Reihe von Verbindungen bestehen.

Grundlegendes Konzept:

Die Essenz (Entität) ist eine Entität, die auf eine Weise identifiziert werden kann, die sie beispielsweise von anderen Entitäten unterscheidet KUNDE 777... Eine Entität ist eigentlich eine Reihe von Attributen.

Entitätssatz (Entitätssatz) - Ein Satz von Entitäten desselben Typs (mit denselben Eigenschaften).

Kommunikation (Beziehung) ist eine Assoziation zwischen mehreren Entitäten.

Domain (Domäne) - Eine Reihe von Werten (Bereich) eines Attributs.

Es gibt drei Arten von binären Links:

  • eins zu eins - Eine einzelne Instanz einer Entität einer Klasse ist einer einzelnen Instanz einer Entität einer anderen Klasse zugeordnet, z. B. HEAD - DEPARTMENT.
  • 1 bis N. oder eins zu viele - Eine einzelne Instanz einer Entität einer Klasse ist vielen Instanzen einer Entität einer anderen Klasse zugeordnet, z. B. DEPARTMENT - EMPLOYEE.
  • N bis M. oder viel zu viel - Viele Instanzen einer Entität einer Klasse sind vielen Instanzen einer Entität einer anderen Klasse zugeordnet, z. B. EMPLOYEE - PROJECT.
  • Ein Glossar grundlegender UML-Konzepte

    Objekt - eine Entität, die einzigartig ist und Status und Verhalten einschließt.

    Klasse (Klasse) - eine Beschreibung einer Reihe von Objekten mit gemeinsamen Attributen, die den Status bestimmen, und Operationen, die das Verhalten bestimmen.

    Schnittstelle - eine benannte Gruppe von Operationen, die eine Reihe von Diensten definiert, die von einem Verbraucher angefordert und von einem Dienstanbieter bereitgestellt werden können.

    Zusammenarbeit - eine Reihe von Objekten, die interagieren, um ein Ziel zu erreichen.

    Darsteller - eine Entität, die sich außerhalb des modellierten Systems befindet und direkt mit diesem interagiert.

    Komponente - ein modularer Teil des Systems mit einem genau definierten Satz erforderlicher und bereitgestellter Schnittstellen.

    Artefakt - eine Information, die im Softwareentwicklungsprozess verwendet oder generiert wird. Mit anderen Worten, ein Artefakt ist eine physische Implementierungseinheit, die von einem Modellelement (z. B. einer Klasse oder Komponente) abgeleitet wird.

    Knoten - eine Computerressource, auf der sich Artefakte befinden und bei Bedarf ausgeführt werden.

    Verhaltensentitäten sollen das Verhalten beschreiben. Es gibt nur zwei grundlegende Verhaltensentitäten: Zustand und Aktion.

    Zustand - eine Zeitspanne im Lebenszyklus eines Objekts, in der das Objekt eine bestimmte Bedingung erfüllt und seine eigene Aktivität ausführt oder auf das Eintreten eines Ereignisses wartet.

    Aktion - primitive Atomberechnung.

    Maschine ist ein Paket, das eine Reihe von Konzepten definiert, die erforderlich sind, um das Verhalten einer modellierten Entität als diskreten Raum mit einer endlichen Anzahl von Zuständen und Übergängen darzustellen.

    Klassifikator ist ein Deskriptor einer Reihe von Objekten des gleichen Typs.

    Zusätzliche Lektüre

    • Fowler M. UML. Grundlagen, 3. Auflage
    • Booch G., Rambeau D., Jacobson I. UML. Handbuch

& nbsp & nbsp & nbsp & nbsp Die Unified Modeling Language (UML) ist eine Sprache zum Spezifizieren, Visualisieren, Erstellen und Dokumentieren von Softwaresystemen sowie Geschäftsmodellen und anderen Nicht-Softwaresystemen. UML ist eine Zusammenführung von Engineering-Techniken, die zuvor erfolgreich zur Modellierung großer und komplexer Systeme eingesetzt wurden.

& nbsp & nbsp & nbsp & nbsp Die Entwickler von UML repräsentieren es als eine Sprache zum Definieren, Darstellen, Entwerfen und Dokumentieren von Softwaresystemen, Geschäftssystemen und anderen Systemen verschiedener Art. UML definiert Notation und Metamodell. Eine Notation ist eine Sammlung grafischer Objekte, die in Modellen verwendet werden. Es ist die Syntax einer Modellierungssprache.

Die UML & nbsp & nbsp & nbsp & nbsp bietet aussagekräftige Tools zum Erstellen visueller Modelle, die:

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

& nbsp & nbsp & nbsp & nbsp Unified Modeling Language (UML):

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

Die & nbsp & nbsp & nbsp & nbsp UML ist Open Source und auf den zugrunde liegenden Kern erweiterbar. In UML ist es möglich, Klassen, Objekte und Komponenten in verschiedenen Themenbereichen sinnvoll zu beschreiben, die sich oft stark voneinander unterscheiden.

UML-Diagramme

& nbsp & nbsp & nbsp & nbsp Rational Rose stellt dem Systemdesigner die folgenden Diagrammtypen zur Verfügung, mit deren sequentieller Erstellung Sie sich ein vollständiges Bild des gesamten entworfenen Systems und seiner einzelnen Komponenten machen können:

  • Anwendungsfalldiagramm (Anwendungsfalldiagramme);
  • Bereitstellungsdiagramm (Topologiediagramme);
  • Zustandsdiagramm;
  • Interaktionsdiagramm; Aktivitätsdiagramm (Aktivitätsdiagramme);
  • Sequenzdiagramm (Diagramme von Aktionssequenzen);
  • Kollaborationsdiagramm;
  • Klassendiagramm (Klassendiagramme);
  • Komponentendiagramm
  • Verhaltensdiagramme (Verhaltensdiagramme);
  • Aktivitätsdiagramm (Aktivitätsdiagramm);
  • Implementierungsdiagramme

& nbsp & nbsp & nbsp & nbsp Jedes dieser Diagramme konkretisiert eine andere Ansicht des Systemmodells. In diesem Fall stellt das Anwendungsfalldiagramm ein konzeptionelles Modell des Systems dar, das der Ausgangspunkt für die Erstellung aller anderen Diagramme ist. Ein Klassendiagramm ist ein logisches Modell, das die statischen Aspekte des strukturellen Entwurfs eines Systems widerspiegelt, und Verhaltensdiagramme, die auch Varianten eines logischen Modells sind, spiegeln die dynamischen Aspekte seiner Funktionsweise wider. Implementierungsdiagramme werden verwendet, um die Komponenten eines Systems darzustellen und auf sein physikalisches Modell zu verweisen.

& nbsp & nbsp & nbsp & nbsp Von den oben aufgeführten Diagrammen werden einige verwendet, um zwei oder mehr Unterarten anzugeben. Die folgenden Diagramme werden als eigenständige Ansichten verwendet: Anwendungsfälle, Klassen, Status, Aktivitäten, Reihenfolge, Zusammenarbeit, Komponenten und Bereitstellungen.

& nbsp & nbsp & nbsp & nbsp Es gibt drei Arten von visuellen Symbolen für UML-Diagramme, die für die darin enthaltenen Informationen wichtig sind:

  • verbindungen, die durch verschiedene Linien in der Ebene dargestellt werden;
  • textinnerhalb der Grenzen einzelner geometrischer Formen enthalten;
  • grafische Symbolein der Nähe der Grafiken der Diagramme gezeichnet.

& nbsp & nbsp & nbsp & nbsp Bei der grafischen Anzeige von Diagrammen wird empfohlen, die folgenden Regeln einzuhalten:

  • jedes Diagramm sollte eine vollständige Darstellung eines Fragments der simulierten Domäne sein.
  • die im Diagramm dargestellten Modellentitäten müssen dieselbe konzeptionelle Ebene haben.
  • alle Informationen zu 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 zur Beschreibung eines bestimmten Systems erforderlichen Diagrammtypen ist nicht streng festgelegt und wird vom Entwickler festgelegt.
  • systemmodelle dürfen nur die Elemente enthalten, die in der UML-Notation definiert sind.

Entitäten in UML

& nbsp & nbsp & nbsp & nbsp Die UML definiert vier Arten von Entitäten: Struktur, Verhalten, Gruppierung und Annotation... Entitäten sind die grundlegenden objektorientierten Elemente der Sprache, mit der Modelle erstellt werden.

& nbsp & nbsp & nbsp & nbsp Strukturelle Einheiten sind Substantive in UML-Modellen. In der Regel stellen sie statische Teile des Modells dar, die konzeptionellen oder physischen Elementen des Systems entsprechen. Beispiele für strukturelle Einheiten sind "Klasse", "Schnittstelle", "Kooperation", "Anwendungsfall", "Komponente", "Knoten", "Akteur".

& nbsp & nbsp & nbsp & nbsp Verhaltensentitätensind dynamische Komponenten des UML-Modells. Dies sind Verben, die das Verhalten eines 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.
  • der Automat ist ein Verhaltensalgorithmus, der die Folge von Zuständen bestimmt, durch die ein Objekt oder eine Interaktion als Reaktion auf verschiedene Ereignisse geht.

& nbsp & nbsp & nbsp & nbsp Entitäten gruppierensind die organisierenden Teile des UML-Modells. Dies sind die Blöcke, in die das Modell zerlegt werden kann. Es gibt eine einzige Kopie einer solchen primären Entität - dies ist ein Paket.

& nbsp & nbsp & nbsp & nbsp Pakete sind ein universeller Mechanismus zum Organisieren von Elementen in Gruppen. Struktur-, Verhaltens- und andere Gruppierungsentitäten können in das Paket eingefügt werden. Im Gegensatz zu Komponenten, die tatsächlich existieren, während ein Programm ausgeführt wird, sind Pakete rein konzeptionell, dh sie existieren nur während der Entwicklung.

& nbsp & nbsp & nbsp & nbsp Anmerkungsentitätensind erklärende Teile des UML-Modells: Kommentare zur zusätzlichen Beschreibung, Erläuterung oder Anmerkungen zu einem beliebigen Element des Modells. Es gibt nur einen Grundtyp für Anmerkungselemente - die Anmerkung. Ein Hinweis wird verwendet, um Kommentare oder Einschränkungen zu Diagrammen bereitzustellen, die in informellem oder formellem Text ausgedrückt werden.

Beziehungen in UML

& nbsp & nbsp & nbsp & nbsp Die folgenden Beziehungstypen sind in der UML definiert: Abhängigkeit, Assoziation, Verallgemeinerung und Implementierung... Diese Beziehungen sind die wichtigsten Klebekonstrukte in UML und auch die Art und Weise, wie Entitäten zum Erstellen von Modellen verwendet werden.

& nbsp & nbsp & nbsp & nbsp Abhängigkeitist eine semantische Beziehung zwischen zwei Entitäten, in der eine Änderung in einer von ihnen, unabhängig, die Semantik der anderen, abhängig beeinflussen kann.

& nbsp & nbsp & nbsp & nbsp Verband - eine strukturelle Beziehung, die eine Reihe von semantischen oder logischen Verbindungen zwischen Objekten beschreibt.

& nbsp & nbsp & nbsp & nbsp Verallgemeinerung ist eine Beziehung, in der ein spezialisiertes Elementobjekt (Nachkomme) ein generisches Elementobjekt (Vorfahr) ersetzen kann. Gleichzeitig erbt das Kind (Kind) gemäß den Prinzipien der objektorientierten Programmierung die Struktur und das Verhalten seines Elternteils (Elternteils).

& nbsp & nbsp & nbsp & nbsp Realisierung ist eine semantische Beziehung zwischen Klassifizierern, in der ein Klassifizierer eine Verpflichtung definiert und der andere deren Erfüllung garantiert. Die Implementierungsbeziehung tritt in zwei Fällen auf:

  • zwischen Schnittstellen und den Klassen oder Komponenten, die sie implementieren;
  • zwischen Anwendungsfällen und den Kollaborationen, die sie implementieren.

Gemeinsame UML-Mechanismen

& nbsp & nbsp & nbsp & nbsp Um das System in UML genau zu beschreiben, werden die sogenannten allgemeinen Mechanismen verwendet:

  • spezifikationen;
  • ergänzungen (Verzierungen);
  • abteilungen (gemeinsame Abteilungen);
  • erweiterungsmechanismen.

& nbsp & nbsp & nbsp & nbsp UML ist nicht nur eine grafische Sprache. Jedes grafische Element seiner Notation hat spezifikationenthält die Textdarstellung des entsprechenden Sprachkonstrukts. Beispielsweise hat ein Klassensymbol eine Spezifikation, die seine Attribute, Operationen und sein Verhalten beschreibt, obwohl das Symbol in einem Diagramm visuell häufig nur einen kleinen Teil dieser Informationen widerspiegelt. Darüber hinaus kann das Modell eine andere Darstellung dieser Klasse enthalten, die völlig unterschiedliche Aspekte widerspiegelt, aber dennoch der Spezifikation entspricht. Daher wird die grafische UML-Notation verwendet, um das System zu visualisieren und mithilfe von Spezifikationen seine Details zu beschreiben.

& nbsp & nbsp & nbsp & nbsp Fast jedes UML-Element verfügt über eine eindeutige grafische Darstellung, die eine visuelle Darstellung seiner wichtigsten Merkmale bietet. Die Entitätsnotation "Klasse" enthält ihren Namen, ihre Attribute und Operationen. Eine Klassenspezifikation kann andere Details enthalten, z. B. 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 gerendert werden. Ergänzungen auf das Standardrechteck, das die Klasse darstellt.

& nbsp & nbsp & nbsp & nbsp Bei der Modellierung objektorientierter Systeme gibt es eine bestimmte Einteilungvertretenen Einheiten.

& nbsp & nbsp & nbsp & nbsp Zunächst erfolgt eine Unterteilung in Klassen und Objekte. Eine Klasse ist eine Abstraktion, und ein Objekt ist eine konkrete Verkörperung dieser Abstraktion. In dieser Hinsicht sind fast alle Sprachkonstrukte durch eine Klasse / Objekt-Dualität gekennzeichnet. Es gibt also Anwendungsfälle und Anwendungsfallinstanzen, Komponenten und Komponenteninstanzen, Knoten und Knoteninstanzen. In der grafischen Darstellung ist es üblich, für ein Objekt dasselbe Symbol wie für eine Klasse zu verwenden und den Namen zu unterstreichen.

& nbsp & nbsp & nbsp & nbsp Zweitens gibt es eine Unterteilung in die Schnittstelle und deren Implementierung. Die Schnittstelle deklariert Verpflichtungen, und die Implementierung stellt die konkrete Verkörperung dieser Verpflichtungen dar und stellt sicher, dass die deklarierte Semantik genau befolgt wird. Aus diesem Grund zeichnen sich fast alle UML-Konstrukte durch eine Dualität zwischen Schnittstelle und Implementierung aus. Beispielsweise werden Anwendungsfälle von Genossenschaften und Operationen nach Methoden implementiert.

& nbsp & nbsp & nbsp & nbsp UML ist eine offene Sprache, dh sie ermöglicht kontrollierte Erweiterungen, um die Besonderheiten von Domänenmodellen widerzuspiegeln.

& nbsp & nbsp & nbsp & nbsp Zu den UML-Erweiterungsmechanismen gehören:

  • stereotypen (Stereotypen) - Erweitern Sie das UML-Vokabular und ermöglichen Sie es, basierend auf vorhandenen Sprachelementen neue zu erstellen, die auf die Lösung eines bestimmten Problems ausgerichtet sind.
  • tagged Value - Erweitert die Eigenschaften grundlegender UML-Konstrukte, sodass zusätzliche Informationen in die Elementspezifikation aufgenommen werden können.
  • einschränkungen - Erweitern Sie die Semantik von UML-Konstrukten, sodass Sie neue Regeln erstellen und vorhandene Regeln überschreiben können.

& nbsp & nbsp & nbsp & nbsp Zusammen ermöglichen diese drei Spracherweiterungsmechanismen, dass Sie es an die Anforderungen des Projekts oder die Besonderheiten der Entwicklungstechnologie anpassen können.

Anwendungsfalldiagramm

& nbsp & nbsp & nbsp & nbsp Mit diesem Diagrammtyp können Sie eine Liste der vom System ausgeführten Vorgänge erstellen. Dieser Diagrammtyp wird häufig als Funktionsdiagramm bezeichnet, da auf der Grundlage eines Satzes solcher Diagramme eine Liste der Systemanforderungen erstellt und der vom System ausgeführte Satz von Funktionen bestimmt wird.


Abbildung - 1. Anwendungsfalldiagramm

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

  • definieren Sie die allgemeinen Grenzen und den Kontext der simulierten Domäne.
  • allgemeine Anforderungen an das Funktionsverhalten des entworfenen Systems formulieren;
  • entwicklung eines ersten konzeptionellen Modells des Systems für seine anschließende Detaillierung in Form von logischen und physikalischen Modellen;
  • bereiten Sie die erste Dokumentation für die Interaktion der Systementwickler mit ihren Kunden und Benutzern vor.

& nbsp & nbsp & nbsp & nbsp Das Anwendungsfalldiagramm sieht im Wesentlichen wie folgt aus. Das zu entwerfende System wird als eine Reihe von Entitäten oder Akteuren dargestellt, die mithilfe von Anwendungsfällen mit dem System interagieren. In diesem Fall ist ein Akteur (Akteur) oder ein Akteur eine Entität, die von außen mit dem System interagiert. Dies kann eine Person, ein technisches Gerät, ein Programm oder ein anderes System sein, das als Einflussquelle auf das modellierte System dienen kann, wie der Entwickler selbst feststellt. Anwendungsfall dient zur Beschreibung der Dienste, die das System dem Akteur bereitstellt.

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

& nbsp & nbsp & nbsp & nbsp Jeder Anwendungsfall entspricht einem separaten Dienst, den die modellierte Entität auf Anforderung des Akteurs bereitstellt, dh bestimmt, wie diese Entität verwendet wird. Der Dienst, der auf Anfrage des Akteurs initialisiert wird, ist eine vollständige, unteilbare Folge von Aktionen. Dies bedeutet, dass das System nach Abschluss der Verarbeitung der Anforderung in den ursprünglichen Zustand zurückkehren muss, um für die nächsten Anforderungen bereit zu sein.

& nbsp & nbsp & nbsp & nbsp Anwendungsfälle können sowohl zum Festlegen externer Anforderungen für das entworfene System als auch zum Festlegen des Funktionsverhaltens eines vorhandenen Systems verwendet werden. Die Gesamtheit der Anwendungsfälle sollte alle möglichen Aspekte des erwarteten Verhaltens des Systems definieren. Darüber hinaus legen Anwendungsfälle implizit Anforderungen fest, die bestimmen, wie Akteure mit dem System interagieren müssen, um mit den bereitgestellten Diensten ordnungsgemäß arbeiten zu können. Der Einfachheit halber können mehrere Anwendungsfälle als separates Paket betrachtet werden.

Beispiele für Anwendungsfälle können sein: Überprüfen des Status des Girokontos eines Kunden, Aufgeben einer Bestellung für den Kauf eines Artikels, Abrufen zusätzlicher Informationen zur Kreditwürdigkeit eines Kunden, Anzeigen eines grafischen Formulars auf einem Monitorbildschirm und andere Aktionen.

Klassen Diagramm

& nbsp & nbsp & nbsp & nbsp Im Zentrum der objektorientierten Programmierung steht die Entwicklung eines logischen Systemmodells in Form eines Klassendiagramms. Das Klassendiagramm (Klassendiagramm) wird verwendet, um die statische Struktur des Systemmodells in der Terminologie von Klassen der objektorientierten Programmierung darzustellen. Ein Klassendiagramm kann insbesondere verschiedene Beziehungen zwischen einzelnen Entitäten der Domäne wie Objekten und Subsystemen widerspiegeln sowie deren interne Struktur und Arten von Beziehungen beschreiben.


Abbildung - 2. Klassendiagramm

& nbsp & nbsp & nbsp & nbsp Mit Diagrammsymbolen können Sie eine komplexe Hierarchie von Systemen, Klassenbeziehungen (Klassen) und Schnittstellen (Schnittstellen) anzeigen. Dieser Diagrammtyp ist inhaltlich dem Collaboration-Diagramm entgegengesetzt, in dem Systemobjekte angezeigt werden. Mit Rational Rose können Sie Klassen mit diesem Diagrammtyp in verschiedenen Notationen erstellen. wie eine Wolke. Eine Klasse ist also nur eine Vorlage, mit der in Zukunft ein bestimmtes Objekt erstellt wird.

& nbsp & nbsp & nbsp & nbsp Ein Klassendiagramm ist ein Diagramm, dessen Eckpunkte Elemente vom Typ "Klassifikator" sind, die durch verschiedene Arten von Strukturbeziehungen verbunden sind. Ein Klassendiagramm kann auch Schnittstellen, Pakete, Beziehungen und sogar einzelne Instanzen wie Objekte und Beziehungen enthalten.

& nbsp & nbsp & nbsp & nbsp Klasse (Klasse) In der UML wird es verwendet, um eine Reihe von Objekten zu bezeichnen, die dieselbe Struktur, dasselbe Verhalten und dieselben Beziehungen zu Objekten anderer Klassen aufweisen. Die Klasse wird grafisch als Rechteck dargestellt, das zusätzlich durch horizontale Linien in Abschnitte oder Abschnitte unterteilt werden kann. Diese Abschnitte können den Klassennamen, Attribute (Variablen) und Operationen (Methoden) enthalten.

Zustandsdiagramm (Zustandsdiagramm)

& nbsp & nbsp & nbsp & nbsp Jedes Zustandsdiagramm in UML beschreibt alle möglichen Zustände einer Instanz einer bestimmten Klasse und mögliche Folgen ihrer Übergänge von einem Zustand in einen anderen, dh es modelliert alle Änderungen in den Zuständen eines Objekts als Reaktion auf äußere Einflüsse.

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



Abbildung - 2. Zustandsdiagramm

& nbsp & nbsp & nbsp & nbsp Ein Zustandsdiagramm ist eine spezielle Art von Grafik, die einen Automaten darstellt. Die Eckpunkte des Graphen sind die möglichen Zustände des Automaten, dargestellt durch die entsprechenden Grafiksymbole, und die Bögen bezeichnen seine Übergänge von Zustand zu Zustand. Zustandsdiagramme können für eine detailliertere Darstellung einzelner Elemente des Modells ineinander verschachtelt werden.

& nbsp & nbsp & nbsp & nbsp Im UML-Metamodell maschine ist ein Paket, das eine Reihe von Konzepten definiert, die erforderlich sind, um das Verhalten einer modellierten Entität als diskreten Raum mit einer endlichen Anzahl von Zuständen und Übergängen darzustellen.

& nbsp & nbsp & nbsp & nbsp Die Dauer der Systempräsenz in einem der möglichen Zustände überschreitet die Zeit, die für den Übergang von einem Zustand in einen anderen benötigt wird, erheblich. Es wird angenommen, dass im Grenzfall die Übergangszeit gleich Null sein kann (sofern nicht anders angegeben), dh die Änderung der Objektzustände kann sofort erfolgen.

& nbsp & nbsp & nbsp & nbsp 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.

& nbsp & nbsp & nbsp & nbsp Die folgenden Voraussetzungen müssen für die Maschine erfüllt sein:

  • der Zustand, in den ein Objekt gehen kann, wird nur durch seinen aktuellen Zustand bestimmt und hängt nicht von der Geschichte ab.
  • zu jedem Zeitpunkt kann sich der Automat nur in einem seiner Zustände befinden. Gleichzeitig kann der Automat für einen beliebigen Zeitraum in einem separaten Zustand bleiben, wenn keine Ereignisse auftreten.
  • die Zeit, zu der sich der Automat in einem bestimmten Zustand befindet, sowie die Zeit, um einen bestimmten Zustand zu erreichen, sind in keiner Weise angegeben.
  • die Anzahl der Zustände des Automaten muss endlich sein, und alle müssen explizit angegeben werden. Einzelne Pseudozustände haben möglicherweise keine Spezifikationen (Start- und Endzustände). In diesem Fall werden ihr Zweck und ihre Semantik vollständig aus dem Kontext des Modells und dem betrachteten Zustandsdiagramm bestimmt.
  • der Automatendiagramm sollte keine isolierten Zustände und Übergänge enthalten. Für jeden Zustand, mit Ausnahme des Anfangszustands, muss ein vorheriger Zustand bestimmt werden, und jeder Übergang muss zwei Zustände des Automaten verbinden;
  • der Automat sollte keine widersprüchlichen Übergänge enthalten, wenn ein Objekt gleichzeitig in zwei oder mehr aufeinanderfolgende Zustände wechseln kann (außer bei parallelen Unterautomaten). In der UML können Konflikte vermieden werden, indem Schutzbedingungen eingeführt werden.

zustände ist nicht nur im UML-Metamodell von grundlegender Bedeutung, sondern auch in der angewandten Systemanalyse. Das gesamte Konzept eines dynamischen Systems basiert auf dem Konzept eines Staates. Die Zustandssemantik in der UML weist eine Reihe spezifischer Merkmale auf.

& nbsp & nbsp & nbsp & nbsp In der UML bezieht sich state auf eine abstrakte Metaklasse, die zum Modellieren einer einzelnen Situation verwendet wird, in der bestimmte Bedingungen erfüllt sind. Der Status kann als eine Reihe spezifischer Werte für die Attribute einer Klasse oder eines Objekts angegeben werden. Änderungen an einzelnen Attributwerten spiegeln Änderungen im Status der modellierten Klasse oder des modellierten Objekts wider.

Aktivitätsdiagramm

& nbsp & nbsp & nbsp & nbsp Bei der Modellierung des Verhaltens eines entworfenen oder analysierten Systems ist es erforderlich, nicht nur den Prozess der Änderung seiner Zustände darzustellen, sondern auch die Merkmale der algorithmischen und logischen Implementierung der vom System ausgeführten Operationen detailliert darzustellen.

& nbsp & nbsp & nbsp & nbsp Tatsächlich kann diese Art von Diagrammen auch verwendet werden, um die Zustände eines modellierten Objekts widerzuspiegeln. Der Hauptzweck eines Aktivitätsdiagramms besteht jedoch darin, die Geschäftsprozesse eines Objekts wiederzugeben. Mit dieser Art von Diagramm können Sie nicht nur die Abfolge von Prozessen anzeigen, sondern auch Verzweigungen und sogar Synchronisierungen von Prozessen.

& nbsp & nbsp & nbsp & nbsp Mit dieser Art von Diagrammen können Sie Algorithmen für das Verhalten von Objekten beliebiger Komplexität entwerfen, einschließlich der Erstellung von Blockdiagrammen.

& nbsp & nbsp & nbsp & nbsp Aktivitätsdiagramme werden verwendet, um den Prozess der Ausführung von Operationen in UML zu modellieren. Die in ihnen verwendete grafische Notation ist der Notation des Zustandsdiagramms sehr ähnlich, da diese Diagramme auch Zustands- und Übergangssymbole enthalten. Jeder Zustand im Aktivitätsdiagramm entspricht der Ausführung einer Elementaroperation, und der Übergang zum nächsten Zustand wird nur ausgeführt, wenn diese Operation abgeschlossen ist.

& nbsp & nbsp & nbsp & nbsp Somit können Aktivitätsdiagramme als Sonderfall von Zustandsdiagrammen betrachtet werden. Mit ihnen können Sie die Funktionen der prozeduralen und synchronen Steuerung in der UML implementieren, da interne Aktivitäten und Aktionen abgeschlossen sind. Die Hauptrichtung bei der Verwendung von Aktivitätsdiagrammen besteht darin, die Implementierungsmerkmale von Klassenoperationen zu visualisieren, wenn Algorithmen für deren Ausführung vorgestellt werden müssen.

& nbsp & nbsp & nbsp & nbsp Im Kontext der UML aktivität ist eine Sammlung von Einzelberechnungen, die von der Maschine durchgeführt werden und zu einem Ergebnis oder einer Aktion (Aktion) führen. Ein Aktivitätsdiagramm zeigt die Logik und die Abfolge der Übergänge von einer Aktivität zur anderen an, während die Aufmerksamkeit des Analytikers auf die Ergebnisse gerichtet ist. Das Ergebnis der Aktivität kann zu einer Änderung des Systemzustands oder zur Rückgabe eines bestimmten Werts führen.

& nbsp & nbsp & nbsp & nbsp Aktionsstatus ist ein Sonderfall eines Zustands mit einer Eingabeaktion und mindestens einem Übergang, der den Zustand verlässt. Dieser Übergang setzt implizit voraus, dass die Eingabeaktion bereits abgeschlossen ist. Der Aktionszustand kann keine internen Übergänge haben, da er elementar ist. Eine übliche Verwendung des Aktionszustands besteht darin, einen einzelnen Schritt bei der Ausführung eines Algorithmus (einer Prozedur) oder eines Kontrollflusses zu simulieren.

Sequenzdiagramm

& nbsp & nbsp & nbsp & nbsp Bei der Betrachtung von Zustands- und Aktivitätsdiagrammen wurde festgestellt, dass diese Diagramme zwar zur Angabe der Dynamik des Verhaltens von Systemen verwendet werden, die Zeit jedoch nicht explizit in ihnen vorhanden ist. Der zeitliche Aspekt des Verhaltens kann bei der Modellierung synchroner Prozesse, die die Interaktion von Objekten beschreiben, von erheblicher Bedeutung sein. Die UML verwendet Sequenzdiagramme, um die Interaktion von Objekten über die Zeit zu modellieren.

& nbsp & nbsp & nbsp & nbsp Das Sequenzdiagramm zeigt nur diese objektedie direkt an der Interaktion beteiligt sind. Der entscheidende Punkt für Sequenzdiagramme ist die Dynamik der Interaktion von Objekten über die Zeit.

& nbsp & nbsp & nbsp & nbsp In UML hat ein Sequenzdiagramm zwei Dimensionen. Die erste von links nach rechts in Form vertikaler Linien, von denen jede die Lebenslinie eines separaten Objekts darstellt, das an der Interaktion teilnimmt. Ganz links im Diagramm ist das Objekt dargestellt, das die Interaktion initiiert. Rechts ist ein anderes Objekt dargestellt, das direkt mit dem ersten interagiert. Somit bilden alle Objekte in einem Sequenzdiagramm eine Reihenfolge, die durch die Reihenfolge oder den Aktivitätsgrad von Objekten bei der Interaktion miteinander bestimmt wird.

& nbsp & nbsp & nbsp & nbsp Grafisch wird jedes Objekt als Rechteck dargestellt und befindet sich am oberen Rand seiner Lebenslinie. Der Objektname und der Klassenname werden in das Rechteck geschrieben, getrennt durch einen Doppelpunkt. In diesem Fall wird der gesamte Datensatz unterstrichen, was ein Merkmal des Objekts ist.

& nbsp & nbsp & nbsp & nbsp Die zweite Dimension des Sequenzdiagramms ist die vertikale Zeitachse von oben nach unten. Der oberste Teil des Diagramms entspricht dem anfänglichen Zeitpunkt. Objektinteraktionen werden durch Nachrichten implementiert, die von einem Objekt zu einem anderen gesendet werden. Nachrichten werden als horizontale Pfeile mit dem Nachrichtennamen angezeigt und ihre Reihenfolge wird durch den Zeitpunkt des Auftretens bestimmt. Das heißt, Nachrichten im obigen Sequenzdiagramm werden früher ausgelöst als die unten befindlichen. Die Skala auf der Zeitachse wird nicht angezeigt, da das Sequenzdiagramm nur die zeitliche Reihenfolge früherer und späterer Interaktionen modelliert.

Kollaborationsdiagramm

& nbsp & nbsp & nbsp & nbsp Das Hauptmerkmal des Kooperationsdiagramms ist die Fähigkeit, nicht nur die Abfolge der Interaktion, sondern auch alle strukturellen Beziehungen zwischen Objekten, die an dieser Interaktion teilnehmen, grafisch darzustellen.


Abbildung - 3. Das Diagramm der Zusammenarbeit

& nbsp & nbsp & nbsp & nbsp Mit diesem Diagrammtyp können Sie die Interaktion von Objekten beschreiben und von der Reihenfolge der Nachrichten abstrahieren. Alle empfangenen und gesendeten Nachrichten eines bestimmten Objekts und die Arten dieser Nachrichten werden in dieser Art von Diagrammen in kompakter Form wiedergegeben.

& nbsp & nbsp & nbsp & nbsp Zunächst zeigt das Kooperationsdiagramm in Form von Rechtecken die an der Interaktion beteiligten Objekte, die den Namen des Objekts, seine Klasse und möglicherweise Attributwerte enthalten. Ferner werden wie im Klassendiagramm Assoziationen zwischen Objekten in Form verschiedener Verbindungslinien angezeigt. In diesem Fall können Sie die Namen der Zuordnung und die Rollen, die Objekte in dieser Zuordnung spielen, explizit angeben. Zusätzlich können dynamische Links - Nachrichtenflüsse dargestellt 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 Sequenz der Nachrichteninitialisierung angibt.

& nbsp & nbsp & nbsp & nbsp Im Gegensatz zu einem Sequenzdiagramm zeigt ein Kollaborationsdiagramm nur Beziehungen zwischen Objekten, die in einer Interaktion eine bestimmte Rolle spielen. Dieses Diagramm zeigt die Zeit nicht als separate Dimension. Daher kann die Sequenz von Interaktionen und gleichzeitigen Streams unter Verwendung von Sequenznummern angegeben werden. Wenn Sie die Beziehungen zwischen Objekten in Echtzeit explizit angeben müssen, tun Sie dies am besten in einem Sequenzdiagramm.

& nbsp & nbsp & nbsp & nbsp Konzept zusammenarbeit ist eines der grundlegenden Konzepte in der UML. Es dient dazu, eine Reihe von Objekten zu bezeichnen, die mit einem bestimmten Zweck im allgemeinen Kontext des modellierten Systems interagieren. Der Zweck der Zusammenarbeit selbst besteht darin, die Merkmale der Implementierung der wichtigsten Einzeloperationen im System festzulegen. Kooperation definiert die Struktur des Systemverhaltens im Hinblick auf die Interaktion der Teilnehmer an dieser Kooperation.

& nbsp & nbsp & nbsp & nbsp Die Zusammenarbeit kann auf zwei Ebenen dargestellt werden:

  • spezifikationsebene - zeigt die Rollen von Klassifikatoren und die Rolle von Assoziationen in der betrachteten Interaktion;
  • beispielstufe - Gibt die Instanzen und Beziehungen an, die separate Rollen in der Zusammenarbeit bilden.

& nbsp & nbsp & nbsp & nbsp Ein Kooperationsdiagramm auf Stücklistenebene zeigt die Rollen, die die an der Interaktion beteiligten Elemente spielen. Die Elemente der Zusammenarbeit auf dieser Ebene sind Klassen und Assoziationen, die die getrennten Rollen von Klassifikatoren und Assoziationen zwischen den Teilnehmern an der Zusammenarbeit bezeichnen.

& nbsp & nbsp & nbsp & nbsp Ein Kooperationsdiagramm auf Beispielebene wird durch eine Sammlung von Objekten (Klasseninstanzen) und Beziehungen (Zuordnungsinstanzen) dargestellt. Die Links werden durch Nachrichtenpfeile 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 erforderlich, alle Eigenschaften oder alle Assoziationen darzustellen, da im Kooperationsdiagramm nur die Rollen der Klassifizierer vorhanden sind, nicht jedoch die Klassifizierer selbst. Während der Klassifizierer eine vollständige Beschreibung aller seiner Instanzen erfordert, erfordert die Rolle des Klassifizierers die Beschreibung nur der Eigenschaften und Assoziationen, die für die Teilnahme an einer bestimmten Zusammenarbeit erforderlich sind.

& nbsp & nbsp & nbsp & nbsp Daraus folgt eine wichtige Konsequenz. Dieselbe Gruppe von Objekten kann an verschiedenen Genossenschaften teilnehmen. Abhängig von der betrachteten Zusammenarbeit 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 Zuordnungen zwischen Diagrammelementen angeben muss.

Komponentendiagramm

& nbsp & nbsp & nbsp & nbsp Dieser Diagrammtyp ist für die Verteilung von Klassen und Objekten nach Komponenten im physischen Entwurf des Systems vorgesehen. Diese Art von Diagramm wird häufig als Einheitsdiagramm bezeichnet.



Abbildung - 4. Komponentendiagramm

& nbsp & nbsp & nbsp & nbsp Ein vollständiger Entwurf eines Softwaresystems besteht aus einer Reihe von Modellen der logischen und physischen Ebene, die miteinander konsistent sein müssen. Die UML verwendet Implementierungsdiagramme, um Modelle von Systemen physisch darzustellen, einschließlich komponentendiagramm und bereitstellungsdiagramm.

& nbsp & nbsp & nbsp & nbsp Das Komponentendiagramm beschreibt im Gegensatz zu den zuvor diskutierten Diagrammen die Merkmale der physikalischen Darstellung des Systems. Sie können die Architektur des in der Entwicklung befindlichen Systems definieren, indem Sie Abhängigkeiten zwischen Softwarekomponenten herstellen, 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.

& nbsp & nbsp & nbsp & nbsp Das Komponentendiagramm wurde für folgende Zwecke entwickelt:

  • visualisierung der allgemeinen Struktur des Quellcodes des Softwaresystems;
  • spezifikationen der ausführbaren Version des Softwaresystems;
  • sicherstellung der Wiederverwendung einzelner Fragmente des Programmcodes;
  • darstellungen von konzeptionellen und physischen Datenbankschemata.

& nbsp & nbsp & nbsp & nbsp Systemanalytiker und -architekten sowie Programmierer sind an der Entwicklung von Komponentendiagrammen beteiligt. Ein Komponentendiagramm bietet einen konsistenten Übergang von einer logischen Ansicht zu einer bestimmten Implementierung eines Projekts in Form von Programmcode. Einige Komponenten können nur in der Phase der Kompilierung des Programmcodes vorhanden sein, andere in der Phase seiner Ausführung. Ein Komponentendiagramm spiegelt die allgemeinen Abhängigkeiten zwischen Komponenten wider, wobei letztere als Klassifizierer betrachtet werden.

& nbsp & nbsp & nbsp & nbsp Um physische Entitäten in der UML-Sprache darzustellen, wird ein spezieller Begriff verwendet - komponente... Die Komponente implementiert eine Reihe von Schnittstellen und dient zur allgemeinen Bezeichnung der Elemente der physikalischen Darstellung des Modells. Zur grafischen Darstellung der Komponente wird ein spezielles Symbol verwendet - ein Rechteck mit zwei kleineren Rechtecken auf der linken Seite. In das große Rechteck werden der Name der Komponente und gegebenenfalls einige zusätzliche Informationen geschrieben. Die Darstellung dieses Symbols kann je nach Art der mit der Komponente verknüpften Informationen geringfügig variieren.

Bereitstellungsdiagramm

& nbsp & nbsp & nbsp & nbsp Diese Art von Diagrammen dient zur Analyse der Hardware des Systems, dh "Hardware" und nicht der Programme. In einer direkten Übersetzung aus dem Englischen bedeutet Bereitstellung "Bereitstellung", aber der Begriff "Topologie" spiegelt die Essenz dieses Diagrammtyps genauer wider.


Abbildung - 5. Bereitstellungsdiagramm

& nbsp & nbsp & nbsp & nbsp Die physische Darstellung eines Softwaresystems kann nicht vollständig sein, wenn keine Informationen darüber vorliegen, auf welcher Plattform und auf welchem \u200b\u200bComputer es implementiert ist. Wenn ein Programm entwickelt wird, das lokal auf dem Computer des Benutzers ausgeführt wird und keine Peripheriegeräte und Ressourcen verwendet, müssen keine zusätzlichen Diagramme erstellt werden. Bei der Entwicklung von Unternehmensanwendungen kann das Vorhandensein solcher Diagramme äußerst nützlich sein, um Probleme der rationalen Platzierung von Komponenten zu lösen, um verteilte Computer- und Kommunikationsressourcen des Netzwerks effizient zu nutzen, Sicherheit zu gewährleisten und andere.

& nbsp & nbsp & nbsp & nbsp Bereitstellungsdiagramme sollen die Gesamtkonfiguration und Topologie eines verteilten Softwaresystems in UML darstellen.

& nbsp & nbsp & nbsp & nbsp Das Bereitstellungsdiagramm dient zur Visualisierung der Elemente und Komponenten des Programms, die nur in der Phase seiner Ausführung (Laufzeit) vorhanden sind. In diesem Fall werden nur die Komponenteninstanzen des Programms angezeigt, bei denen es sich um ausführbare Dateien oder dynamische Bibliotheken handelt. Komponenten, die zur Laufzeit nicht verwendet werden, werden im Bereitstellungsdiagramm nicht angezeigt. Komponenten mit Quellcodes von Programmen können also nur im Komponentendiagramm vorhanden sein. Sie werden im Bereitstellungsdiagramm nicht angezeigt.

& nbsp & nbsp & nbsp & nbsp Ein Bereitstellungsdiagramm enthält grafische Darstellungen von Prozessoren, Geräten, Prozessen und den Beziehungen zwischen ihnen. Im Gegensatz zu logischen Ansichtsdiagrammen ist ein Bereitstellungsdiagramm für das gesamte System einheitlich, da es die Besonderheiten seiner Implementierung vollständig widerspiegeln muss. Die Entwicklung eines Bereitstellungsdiagramms ist normalerweise der letzte Schritt in der Spezifikation des Softwaresystemmodells.

& nbsp & nbsp & nbsp & nbsp Bei der Entwicklung eines Bereitstellungsdiagramms werden folgende Ziele verfolgt:

  • bestimmen der Verteilung von Systemkomponenten durch ihre physischen Knoten;
  • zeigen Sie die physischen Verbindungen zwischen allen Knoten der Systemimplementierung in der Phase ihrer Ausführung an.
  • identifizieren Sie Systemengpässe und konfigurieren Sie die Topologie neu, um die erforderliche Leistung zu erzielen.

& nbsp & nbsp & nbsp & nbsp Bereitstellungsdiagramme werden gemeinsam von Systemanalysten, Netzwerkingenieuren und Systemingenieuren entwickelt.

Rational Rose Desktop-Funktionen

& nbsp & nbsp & nbsp & nbsp Das Rational Rose CASE-Tool implementiert allgemein anerkannte Standards für die Programmschnittstelle, ähnlich bekannten visuellen Programmierumgebungen. Nach der Installation von Rational Rose auf dem Computer des Benutzers, was selbst Anfängern praktisch keine Probleme bereitet, führt das Starten dieses Programms in der MS Windows 95/98-Umgebung zu einer Arbeitsoberfläche auf dem Bildschirm (Abb. 6).


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

& nbsp & nbsp & nbsp & nbsp Die Rational Rose-Arbeitsoberfläche besteht aus verschiedenen Elementen, von denen die wichtigsten sind:

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

Lassen Sie uns kurz den Zweck und die Hauptfunktionen jedes dieser Elemente betrachten.

Hauptmenü des Programms

Das Hauptmenü des Programms wird im allgemein anerkannten Standard erstellt und hat die folgende Form (Abb. 7).

Einzelne Menüpunkte, deren Zweck sich aus ihren Namen ergibt, kombinieren ähnliche Vorgänge, die sich auf das gesamte Projekt als Ganzes beziehen. Einige der Menüelemente enthalten vertraute Funktionen (Öffnen eines Projekts, Ausgeben und Drucken von Diagrammen, Kopieren in die Zwischenablage und Einfügen verschiedener Diagrammelemente aus der Zwischenablage). Andere sind so spezifisch, dass sie möglicherweise zusätzliches Lernen erfordern (Optionen zur Codegenerierung, Überprüfung der Modellkonsistenz, Einstecken zusätzlicher Module).

Abbildung - 7. Darstellung des Hauptmenüs des Programms

Standard-Symbolleiste

Die Standardsymbolleiste befindet sich unter dem Hauptprogrammmenü 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 ausführen.

Abbildung 8. Darstellung der Standardsymbolleiste

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

Browser Fenster

Das Browserfenster befindet sich standardmäßig auf der linken Seite der Arbeitsoberfläche unter der Standardsymbolleiste (Abb. 9).

Der Browser organisiert die 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. Nachdem wir ein Element im Browserfenster ausgewählt haben, können wir es im Diagrammfenster visualisieren oder seine Spezifikation ändern. Mit dem Browser können Sie auch Modellelemente in Paketen organisieren und Elemente zwischen verschiedenen Ansichten des Modells verschieben. Falls gewünscht, kann das Browserfenster an einer anderen Stelle der Arbeitsoberfläche positioniert oder über den Menüpunkt Ansicht ganz ausgeblendet werden. Sie können die Größe des Browsers auch ändern, indem Sie den Rand des äußeren Rahmens ziehen.

Abbildung - 9. Browser-Erscheinungsbild

Spezielle Symbolleiste

Eine spezielle Symbolleiste befindet sich zwischen dem Browserfenster und dem Diagrammfenster in der Mitte der Arbeitsoberfläche. Standardmäßig wird eine Symbolleiste zum Erstellen eines Klassendiagramms des Modells angeboten (Abb. 10).

Abbildung - 10. Darstellung einer speziellen Klassendiagramm-Symbolleiste

Sie können die Position der speziellen Symbolleiste ändern, indem Sie den Rahmen der Symbolleiste an die gewünschte Position verschieben. Sie können die Zusammensetzung des Bedienfelds auch anpassen, indem Sie einzelne Schaltflächen hinzufügen oder entfernen, die bestimmten Werkzeugen entsprechen. Die Tastenbelegung finden Sie in den QuickInfos, die angezeigt werden, nachdem der Mauszeiger über der entsprechenden Schaltfläche angehalten wurde.

Diagrammfenster

Das Diagrammfenster ist der Hauptarbeitsbereich seiner Benutzeroberfläche, in dem verschiedene Ansichten des Projektmodells visualisiert werden. Standardmäßig befindet sich das Diagrammfenster auf der rechten Seite der Arbeitsoberfläche. 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 in diesem Fenster wird in der Titelleiste des Programms (der obersten Zeile des Programms) oder, wenn das Fenster nicht auf Vollbild erweitert wird, in der Titelleiste des Diagrammfensters angezeigt. Es können mehrere Diagramme gleichzeitig im Diagrammfenster vorhanden sein, aber nur eines davon kann aktiv sein. Zum Beispiel in Abb. In 11 ist das Bereitstellungsdiagramm aktiv, obwohl es andere Diagramme gibt. Das Wechseln 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 für eine bestimmte Diagrammansicht angepasst wird.


Abbildung - 11. Das Erscheinungsbild des Diagrammfensters mit verschiedenen Ansichten des Modells

Dokumentationsfenster

Das Standarddokumentationsfenster ist möglicherweise nicht auf dem Bildschirm vorhanden. In diesem Fall kann es über den Menüpunkt Ansicht -\u003e Dokumentation aktiviert werden. Danach erscheint es unter dem Browser (Abb. 12).

Das Dokumentationsfenster soll, wie der Name schon sagt, die Elemente der Modellansicht dokumentieren. Sie können eine Vielzahl von Informationen hineinschreiben, und was wichtig ist - auf Russisch. Diese Informationen werden anschließend in Kommentare umgewandelt und haben keinerlei Einfluss auf die Logik der Programmcodeausführung.

Im Dokumentationsfenster werden die Informationen zum einzelnen ausgewählten Element des Diagramms aktiviert. Das Element kann entweder im Browserfenster oder im Diagrammfenster ausgewählt werden. Wenn dem Diagramm ein neues Element hinzugefügt wird (z. B. eine Klasse), wird automatisch die Dokumentation generiert, die leer ist (keine Dokumentation). Anschließend gibt der Entwickler selbständig die erforderlichen erklärenden Informationen ein, die gespeichert werden und während der Arbeit am Projekt geändert werden können.

Wie auch für andere Fenster der Arbeitsoberfläche können Sie die Größe und Position des Dokumentationsfensters ändern.

Abbildung - 12. Erscheinungsbild des Dokumentationsfensters

Protokollfenster

Das Protokollfenster dient zur automatischen Aufzeichnung verschiedener Serviceinformationen, die während der Arbeit mit dem Programm generiert wurden. Das Protokoll zeichnet die Zeit und die Art der Aktionen des Entwicklers 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 immer auf der Arbeitsoberfläche im Bereich des Diagrammfensters vorhanden (Abb. 13). Es kann jedoch durch andere Diagrammfenster geschlossen oder minimiert werden. Sie können das Protokollfenster über das Menü Fenster-\u003e Protokoll aktivieren. In diesem Fall wird es über anderen Fenstern im rechten Bereich der Arbeitsoberfläche angezeigt. Sie können dieses Fenster nicht vollständig entfernen, sondern nur minimieren.

Abbildung - 13. Erscheinungsbild des Protokollfensters

Fazit

& nbsp & nbsp & nbsp & nbsp Im Laufe der Zeit wird die UML zum "Esperanto", in dem Mathematiker, Systemanalytiker, Physiker, Programmierer, Manager, Ökonomen und Spezialisten anderer Berufe kommunizieren und ihr Fachwissen in einheitlicher Form präsentieren können. Schließlich arbeitet jeder Spezialist im Wesentlichen mit Modellkonzepten in seinem Wissensgebiet. Und dieser Modellaspekt kann mit Hilfe der UML-Sprache spezifiziert werden.

& nbsp & nbsp & nbsp & nbsp In dieser Hinsicht nimmt die Bedeutung der UML-Sprache erheblich zu, da sie zunehmend die Merkmale einer Wissensrepräsentationssprache annimmt. Gleichzeitig ermöglicht das Vorhandensein von Bildmitteln zur Darstellung der Struktur und des Verhaltens eines Modells in der UML eine adäquate Darstellung von deklarativem und prozeduralem Wissen und, nicht weniger wichtig, eine semantische Entsprechung zwischen diesen Wissensformen herzustellen. All diese Merkmale der UML lassen den Schluss zu, dass sie in naher Zukunft die ernsthaftesten Aussichten hat.

Dieser Artikel befasst sich mit der neuen Ära der Softwareentwicklung, ihren Auswirkungen auf die neuen Anforderungen an die UML und den Best Practices für deren Erfüllung.
7. "Datenmodellierung in Rational Rose" Sergey Trofimov Beschreibt die Modellierung der Darstellung physikalischer Daten mit Rational Rose
8. UML-Sprache. Allgemeines Verständnis der UML-Sprache: Strukturen, grafische Elemente und Diagramme der Sprache.
9. Praktische UML. Dieses Dokument ist eine Übersetzung von Practical UML. Eine praktische Einführung für Entwickler. Eine praktische Einführung für Entwickler
& nbsp 10. "Standardsprache der objektorientierten Modellierung UML" Vendrov Alexander Mikhailovich. UML-Geschichte
11. UML ist eine einheitliche Modellierungssprache. Dieses Material enthält erste Informationen zu Methoden zur Beschreibung von Softwaresystemen und Notationen, die in UML verwendet werden.
12. Die UML-Sprache. Handbuch. Von Grady Booch, James Rambeau und Ivar Jacobson
& nbsp 13. "UML-Diagramme in Rational Rose" Sergey Trofimov
& nbsp 14. "Analyse und Design. Visuelle Modellierung (UML) Rational Rose" Konstantin Domolego
15. Bibliothek von Gennady Vernikov. Vollständige Beschreibungen der Design- und Modellierungsstandards.
& nbsp 16. "Ein Beispiel für eine Domänenbeschreibung unter Verwendung von UML bei der Entwicklung von Softwaresystemen" Ye.B. Zolotukhina, R.V. Alfimov. Der Artikel zeigt ein spezifisches Beispiel für einen möglichen Ansatz zur Domänenmodellierung basierend auf der Verwendung der Unified Modeling Language (UML).

& nbsp & nbsp & nbsp & nbsp

Fortsetzung des Themas:
Programme

Abstract: In der Vorlesung werden die Aufgaben und Methoden der wirtschaftlichen Analyse der Durchführbarkeit von Maßnahmen zur Gewährleistung der Informationssicherheit in bestimmten ...