Uml-Beschreibung. UML-Diagramme. Interne Aktivitäten im Statechart

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

Eine kurze Geschichte der UML

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

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

UML ist eine Sprache

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

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

UML-Vokabular

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

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

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

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

Diagramme. Die UML bietet die folgenden Diagramme:

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

Ansicht der Modellsteuerung. Pakete.

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

Was die UML bietet.

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

Und der letzte ...

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

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 die UML ausführlich beschreiben (an manchen Stellen sogar sehr detailliert), ich möchte an einer Stelle die grundlegenden Konzepte zu Diagrammen, Entitäten und Verbindungen zwischen ihnen zum schnellen Abrufen sammeln, so etwas wie ein Spickzettel .

Die Notiz verwendet Materialien aus Büchern: Ivanov D. Yu., Novikov F. A. Unified Modeling Language UML und Leonenkow. UML-Tutorial.

Entscheiden wir uns zunächst für den Editor. Unter Linux habe ich verschiedene UML-Editoren ausprobiert, am meisten hat mir das UMLet gefallen, obwohl es in Java geschrieben ist, es sich sehr schnell bewegt und die meisten Entity-Templates darin enthalten sind. Es gibt auch ArgoUML, einen plattformübergreifenden UML-Editor, ebenfalls in Java geschrieben, funktionsreich, aber langsamer.

Ich habe mich darauf festgelegt UMLet, setze es unter Arch Linux und Ubuntu:

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

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

• strukturell;
• verhaltensauffällig;
• Gruppierung;
• Anmerkung;

Es gibt vier Haupttypen von Beziehungen, die in der UML verwendet werden:

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

Verband- findet statt, wenn eine Entität in direkter Beziehung zu einer anderen steht (oder zu anderen - die Assoziation kann nicht nur binär sein). Eine Assoziation wird grafisch als durchgezogene Linie mit verschiedenen Zusätzen dargestellt, die verwandte Entitäten verbinden.

Verallgemeinerung ist eine Beziehung zwischen zwei Entitäten, von denen eine ein spezieller (Spezial-)Fall der anderen ist. Grafisch wird die Generalisierung als Linie mit einem dreieckigen, nicht schattierten Pfeil am Ende dargestellt, der vom Besonderen (Unterklasse) zum Allgemeinen (Überklasse) 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, nicht schraffierten Pfeil am Ende dargestellt, der von der realisierenden zur realisierbaren Instanz führt.

V UML 2 ist definiert 13 Arten von Diagrammen. Standardmäßig sollte jedes Diagramm ein Kästchen 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 des Systemaufbaus:

• 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 Komm);
• Zustandsmaschinendiagramm (Tag Zustandsmaschine);
• Interaktionsübersichtsdiagramm-Tag Interaktion);

Diagramme unterscheiden sich:

• Nutzungsdiagramm (Use-Case-Diagramm, Use-Case-Tag);
• Paketdiagramm (Tag Paket);

Nutzungsdiagramm

Nutzungsdiagramm(Use-Case-Diagramm) ist die allgemeinste Darstellung des funktionalen Zwecks des Systems.

Betrachtet man ein Use-Case-Diagramm als Modell eines Systems, kann man es einem Black-Box-Modell zuordnen. Jeder Anwendungsfall definiert eine Abfolge von Aktionen, die das entworfene System ausführen muss, wenn es mit dem entsprechenden Akteur interagiert.

Das Nutzungsdiagramm verwendet zwei Arten von Grundentitäten: Anwendungsfälle und Akteure, zwischen denen die folgenden Grundtypen von Beziehungen hergestellt werden.

Assoziationsbeziehung- Diese Beziehung legt fest, welche spezifische Rolle ein Akteur spielt, wenn er mit einer Instanz eines Anwendungsfalls interagiert. 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 darauf bestimmt werden, wie diese Instanzen miteinander kombiniert werden. Wenn also eine Erweiterungsbeziehung von Anwendungsfall A zu Anwendungsfall B besteht, bedeutet dies, dass die Eigenschaften der Instanz von Anwendungsfall B aufgrund des Vorhandenseins von Eigenschaften in erweitertem Anwendungsfall A erweitert werden können.

Eine Erweiterungsbeziehung zwischen Anwendungsfällen wird durch eine gestrichelte Linie mit einem Pfeil (Abhängigkeitsbeziehungsfall) angezeigt, der von dem Anwendungsfall wegzeigt, der eine Erweiterung des ursprünglichen Anwendungsfalls ist.

Generalisierungsbeziehung dient dazu, die Tatsache anzuzeigen, dass ein bestimmter Anwendungsfall A auf Anwendungsfall B verallgemeinert werden kann. In diesem Fall ist Option A eine Spezialisierung von Option B. In diesem Fall wird B in Bezug auf A als Vorfahr oder Elternteil bezeichnet, und Option A ist ein Nachkomme in Bezug auf die Optionsnutzung von V.

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

Eine Generalisierungsbeziehung zwischen Anwendungsfällen wird verwendet, wenn beachtet werden muss, 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 die Verhaltenssequenz des anderen Anwendungsfalls aufgenommen wird.

Die Einbeziehungsbeziehung 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 (Abhängigkeitsbeziehungsfall) gekennzeichnet, der vom Basisanwendungsfall zum eingeschlossenen Anwendungsfall zeigt.

Klassen Diagramm

Klassen Diagramm(Klassendiagramm) ist die wichtigste Methode, um die statische Struktur eines Systems zu beschreiben.

Auf einem Klassendiagramm wird ein Haupttyp von Entitäten verwendet: Klassen (einschließlich zahlreicher Spezialfälle von Klassen: Interfaces, primitive Typen, Assoziationsklassen usw.), zwischen denen die folgenden Grundtypen von Beziehungen hergestellt werden: Abhängigkeiten, Assoziationen, Generalisierungen , Implementierungen.

Suchtbeziehung bezeichnet im Allgemeinen eine semantische Beziehung zwischen zwei Modellelementen oder zwei Sätzen solcher Elemente, die keine Assoziations-, Generalisierungs- oder Implementierungsbeziehung ist. Eine Abhängigkeitsbeziehung wird in einer Situation verwendet, in der eine Änderung in einem Element des Modells eine Änderung in einem anderen abhängigen Element im Modell erfordern kann.

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

Über dem Pfeil können spezielle Schlüsselwörter (Stereotypen) stehen:

• "access" - dient dazu, die Zugänglichkeit von öffentlichen Attributen und Operationen der Quellklasse für Client-Klassen anzuzeigen;
• "bind" - die Client-Klasse kann eine Vorlage für ihre nachfolgende Parametrisierung verwenden;
• "derive" - ​​​​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 wären sie direkt in ihr deklariert;
• "refine" - zeigt an, dass die Client-Klasse aus historischen Gründen als Verfeinerung der Quellklasse dient, wenn während der Arbeit am Projekt zusätzliche Informationen auftauchen.

Assoziationsbeziehung entspricht der Existenz einer Beziehung zwischen den Klassen. Diese Beziehung wird durch eine durchgezogene Linie mit zusätzlichen Sonderzeichen gekennzeichnet, die einzelne Eigenschaften einer bestimmten Assoziation charakterisieren. Als zusätzliche Sonderzeichen können der Name der Assoziation sowie die Namen und die Multiplizität der Rollenklassen der Assoziation verwendet werden. Der Name des Vereins ist ein optionaler Bestandteil seiner Benennung.

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

Zusammensetzungsbeziehung ist ein Sonderfall einer Aggregationsrelation. Diese Beziehung dient dazu, eine besondere Form der Beziehung "Teil-Ganzes" hervorzuheben, bei der die Bestandteile gewissermaßen innerhalb des Ganzen liegen. Die Besonderheit der Beziehung zwischen ihnen liegt darin, dass die Teile nicht isoliert vom Ganzen wirken können, dh mit der Zerstörung des Ganzen werden alle seine Bestandteile zerstört.

Generalisierungsbeziehung ist eine Beziehung zwischen einem allgemeineren Element (Eltern oder Vorfahren) und einem privateren oder speziellen Element (Kind oder Nachkomme). Auf ein Klassendiagramm angewendet, beschreibt diese Beziehung die hierarchische Struktur von Klassen und die Vererbung ihrer Eigenschaften und ihres Verhaltens. Es wird davon ausgegangen, dass die Nachkommenklasse alle Eigenschaften und das Verhalten der Vorfahrenklasse hat und auch eigene Eigenschaften und Verhalten hat, die die Vorfahrenklasse nicht hat.

Automatendiagramm

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

Ein Zustandsdiagramm beschreibt den Vorgang der Zustandsänderung nur einer Klasse bzw. einer Instanz einer bestimmten Klasse, dh es modelliert alle möglichen Zustandsänderungen eines bestimmten Objekts. Dabei kann eine Zustandsänderung 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 Beziehung - Übergänge, aber für beide sind viele Varianten, Sonderfälle und zusätzliche Notationen definiert. Der Automat stellt die dynamischen Aspekte des modellierten Systems in Form eines gerichteten Graphen dar, dessen Ecken Zuständen und Bögen Übergängen entsprechen.

Ausgangszustand ist ein Sonderfall eines Zustands, der keine internen Aktionen enthält (Pseudozustände). Das Standardobjekt befindet sich zum Anfangszeitpunkt in diesem Zustand. Sie dient dazu, im Zustandsdiagramm anzuzeigen, ab welchem ​​Grafikbereich der Zustandsübergangsprozess beginnt.

Finale (final) ein Zustand ist ein Sonderfall eines Zustands, der auch keine internen Aktionen enthält (Pseudo-Zustände). Das Standardobjekt befindet sich in diesem Zustand, nachdem der Automat seine Arbeit im letzten Moment beendet hat.

Aktivitätsdiagramm

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

Aktivitätsdiagramm(Aktivitätsdiagramm) ist eine weitere Möglichkeit, Verhalten zu beschreiben, das optisch dem guten alten Flussdiagramm des Algorithmus ähnelt. Wird verwendet, um den Prozess der Durchführung von Operationen zu simulieren.

Die Hauptrichtung bei der Verwendung von Aktivitätsdiagrammen besteht darin, die Besonderheiten der Implementierung von Klassenoperationen zu visualisieren, wenn es notwendig ist, Algorithmen für deren Ausführung zu präsentieren.

Im Aktivitätsdiagramm wird ein Haupttyp von Entitäten verwendet - Aktion und ein Typ von Beziehung - Übergänge (Übergaben der Kontrolle). Auch verwendet werden solche Konstruktionen wie Gabeln, Merges, Joins, Branchs. Es wird empfohlen, ein Verb mit erklärenden Wörtern als einfachen Aktionsnamen zu verwenden.

Sequenzdiagramm

Sequenzdiagramm(Sequenzdiagramm) ist eine Möglichkeit, das Systemverhalten "anhand von Beispielen" zu beschreiben.

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

Im Sequenzdiagramm wird ein Haupttyp von Entitäten verwendet - Instanzen von interagierenden Klassifikatoren (hauptsächlich Klassen, Komponenten und Akteure) und ein Beziehungstyp - die Verbindungen, über die Nachrichten ausgetauscht werden.

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

Kommunikationsdiagramm

Kommunikationsdiagramm(Kommunikationsdiagramm) - eine Art der Verhaltensbeschreibung, die semantisch einem Sequenzdiagramm entspricht. Tatsächlich ist dies dieselbe Beschreibung der Nachrichtenaustauschsequenz von interagierenden Klassifikatorinstanzen, nur in anderen grafischen Mitteln ausgedrückt.

Somit wird sowohl im Kommunikationsdiagramm als auch im Sequenzdiagramm ein Haupttyp von Entitäten verwendet - Instanzen von interagierenden Klassifikatoren und ein Typ von Beziehung - Verbindungen. Der Schwerpunkt liegt hier jedoch nicht auf der Zeit, sondern auf der Struktur der Verbindungen zwischen bestimmten Instanzen.

Komponentendiagramm

Komponentendiagramm(Komponentendiagramm) - zeigt die Beziehung zwischen Modulen (logisch oder physisch), 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 den Komponenten angezeigt wird. In einem Komponentendiagramm gelten die folgenden 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 Darstellung der Zusammensetzung und der Beziehungen von Systemelementen, wie sie sich zur Laufzeit physisch auf den Computerressourcen befinden.

Im Platzierungsdiagramm werden im Vergleich zum Komponentendiagramm zwei Arten von Entitäten hinzugefügt: ein Artefakt, das die Implementierung einer Komponente ist, und ein Knoten (es kann entweder ein Klassifikator sein, der den Typ eines Knotens beschreibt, oder eine bestimmte Instanz ) sowie eine Assoziationsbeziehung zwischen Knoten, die zeigt, dass Knoten zur Laufzeit physisch verbunden sind.

Objektdiagramm

Objektdiagramm(Objektdiagramm) - ist eine Instanz eines Klassendiagramms.

Im Objektdiagramm wird ein Haupttyp von Entitäten verwendet: Objekte (Klasseninstanzen), zwischen denen bestimmte Beziehungen angegeben werden (meistens Assoziationsinstanzen). Objektdiagramme haben einen Hilfscharakter - tatsächlich sind sie Beispiele (man könnte sagen, Speicherauszüge), die zeigen, was Objekte sind und welche Verbindungen sie zu einem bestimmten Zeitpunkt im Funktionieren des Systems haben.

Internes Strukturdiagramm(Composite Structure Diagram) dient der detaillierteren Darstellung von strukturellen Klassifikatoren, vor allem von Klassen und Komponenten.

Der strukturelle Klassifikator wird als Rechteck dargestellt, in dessen oberem Teil der Name des Klassifikators steht. Innen sind die Teile. Es können mehrere Teile sein. Teile können miteinander interagieren. Dies wird durch verschiedene Konnektoren angezeigt. Die Stelle an der Außenkante des Teils, an dem der Stecker befestigt wird, wird als Port bezeichnet. Ports befinden sich auch am äußeren Rand des Strukturklassierers.

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

Synchronisationsdiagramm

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

Paketdiagramm

Paketdiagramm(Paketdiagramm) ist das einzige Werkzeug, 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, das beim Entwurf von Datenbanken verwendet wird (relationales Modell).

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

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

Grundlegendes Konzept:

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

Entitätssatz(Entitätsmenge) - eine Menge von Entitäten desselben Typs (mit denselben Eigenschaften).

Verbindung(Beziehung) ist eine Verbindung 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, zum Beispiel HEAD - DEPARTMENT;
• 1 bis N oder eins zu vielen- eine einzelne Instanz einer Entität einer Klasse ist mit vielen Instanzen einer Entität einer anderen Klasse verbunden, zum Beispiel ABTEILUNG - MITARBEITER;
• N nach M oder viel zu viel- viele Instanzen einer Entität einer Klasse sind mit vielen Instanzen einer Entität einer anderen Klasse verbunden, zum Beispiel MITARBEITER - PROJEKT;
Ein Glossar der grundlegenden UML-Konzepte

Objekt- eine Einheit, die einzigartig ist und Zustand und Verhalten kapselt.

Klasse- eine Beschreibung einer Menge von Objekten mit gemeinsamen Attributen, die den Zustand bestimmen, und Operationen, die das Verhalten bestimmen.

Schnittstelle- eine benannte Menge 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 klar definierten Satz erforderlicher und bereitgestellter Schnittstellen.

Artefakt- eine Information, die im Prozess der Softwareentwicklung verwendet oder erzeugt wird. Mit anderen Worten, ein Artefakt ist eine physische Implementierungseinheit, die von einem Modellelement (wie einer Klasse oder Komponente) abgeleitet wird.

Knoten- eine Rechenressource, auf der sich Artefakte befinden und ggf. ausgeführt werden.

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

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

Aktion- primitive atomare Berechnung.

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

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

Zusätzliche Lektüre

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

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

Die Entitäten und Beziehungen des Modells selbst sind Instanzen der Metaklassen des Metamodells.

Betrachtet man das UML-Modell ganz allgemein, so kann man sagen, dass es sich um einen Graphen (genauer gesagt um einen geladenen Multi-Pseudo-Hyper-Digraph) handelt, in dem die Ecken und Kanten mit zusätzlichen Informationen geladen sind und a komplexe innere Struktur. Die Ecken dieses Graphen heißen Entitäten und die Kanten sind Relationen... 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 davon nicht allzu viele. In den folgenden Kapiteln des Buches werden alle Entitäten und Beziehungen noch einmal ausführlicher und mit Beispielen betrachtet.

1.4.1. Entitäten

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

• strukturell;
• verhaltensauffällig;
• Gruppierung;
• Anmerkung.

Strukturelle Entitäten sollen, wie Sie sich vorstellen können, Strukturen beschreiben. Typischerweise umfassen strukturelle Entitäten Folgendes.

Ein Objekt(Objekt) 1 ist eine Einheit, die einzigartig ist und Zustand und Verhalten kapselt.

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

Schnittstelle(Schnittstelle) 3 ist ein benannter Satz von Operationen, der einen Satz 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(Aktor) 5 ist eine Entität, die sich außerhalb des modellierten Systems befindet und direkt mit diesem interagiert.

∇ Ein solcher Zusammenhang besteht durchaus, der in Abb. Diagrammtyphierarchie für UML 1 als Abhängigkeitsbeziehung mit einem Refine-Stereotyp.

∇∇ In UML 1 entstand eine unfreiwillige Assoziation zwischen einem Kooperationsdiagramm und einer 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 verä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 aufgeführt.

• Verbundstrukturdiagramm
• Paketdiagramm
• Zustandsmaschinendiagramm
• Kommunikationsdiagramm
• Interaktionsübersichtsdiagramm
• Zeitdiagramm

In Abb. Diagrammtyphierarchie für UML 2 (Teil 1 & 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 Vokabular für die spätere Präsentation zu haben. Die Details sind in den restlichen Kapiteln des Buches beschrieben.

Aber bevor wir zum nächsten Abschnitt übergehen, machen wir einen kleinen Exkurs darüber, wie der Standard die Formatierung von Diagrammen erfordert. Die allgemeine Diagrammpräsentationsvorlage wird unten gezeigt.

Es gibt zwei wesentliche Gestaltungselemente: einen äußeren Rahmen und ein Etikett mit dem Namen des Diagramms. Wenn mit dem Rahmen alles einfach ist - es ist ein Rechteck, das den Bereich begrenzt, in dem sich die Diagrammelemente befinden sollen, wird der Name des Diagramms in einem speziellen Format geschrieben, das in Abb. Notation für Diagramme.

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

Mögliche Tags (Typen) für Diagramme sind in der folgenden Tabelle aufgeführt. In der zweiten Spalte stehen die vom Standard angebotenen Tags. Wie die Praxis gezeigt hat, sind die von der Norm vorgeschlagenen Regeln jedoch nicht immer bequem und logisch begründet, daher enthält die dritte Spalte der Tabelle unserer Meinung nach eine vernünftige Alternative.

Tab. Diagrammtypen und Tags

Diagrammtitel	Etikett (Standard)	Etikett (empfohlen)
Nutzungsdiagramm	Anwendungsfall oder uc	Anwendungsfall
Klassen Diagramm	Klasse	Klasse
Automatendiagramm	Zustandsmaschine oder stm	Zustandsmaschine
Aktivitätsdiagramm	Aktivität oder Gesetz	Aktivität
Sequenzdiagramm	Interaktion oder sd	sd
Kommunikationsdiagramm	Interaktion oder sd	Komm
Komponentendiagramm	Komponente oder cmp	Komponente
Platzierungsdiagramm	undefiniert	Einsatz
Objektdiagramm	undefiniert	Objekt
Internes Strukturdiagramm	Klasse	Klasse oder Komponente
Interaktionsübersichtsdiagramm	Interaktion oder sd	Interaktion
Synchronisationsdiagramm	Interaktion oder sd	zeitliche Koordinierung
Paketdiagramm	Paket oder pkg	Paket

UML (Unified Modeling Language) ist eine grafische Beschreibungssprache für die Objektmodellierung in der Softwareentwicklung. UML ist eine breitgefächerte Sprache, ein offener Standard, der grafische Notation verwendet, um ein abstraktes Modell eines Systems namens UML-Modell zu erstellen. Die UML wurde entwickelt, um hauptsächlich Softwaresysteme zu definieren, zu visualisieren, zu entwerfen und zu dokumentieren. UML ist keine Programmiersprache, aber Codegenerierung ist möglich, indem UML-Modelle als interpretierter Code ausgeführt werden. Wikipedia

Kommerzielle Produkte

Microsoft Visio

Typ: kommerzielle Software

Ein beliebtes Softwareprodukt von Microsoft, mit dem Sie umfangreiche Diagramme, einschließlich UML, zeichnen können:

Ab der Version 2010 ist es möglich, Diagramme im Web zu veröffentlichen (SharePoint + Visio Services):

Visio-Viewer ist ein kostenloses Programm, mit dem Sie zuvor erstellte Visio-Diagramme anzeigen können. Sie können nach% D1% 81% D1% 81% D1% 8B% D0% BB% D0% BA% D0% B5% 20 herunterladen.

% 0A

Microsoft% 20Visual% 20Studio% 202010

% 0A

% D0% A2% D0% B8% D0% BF:% 20% D0% BA% D0% BE% D0% BC% D0% BC% D0% B5% D1% 80% D1% 87% D0% B5% D1% 81% D0% BA% D0% BE% D0% B5% 20% D0% 9F% D0% 9E% 20 (% D0% B5% D1% 81% D1% 82% D1% 8C% 20% D0% B1% D0 % B5% D1% 81% D0% BF% D0% BB% D0% B0% D1% 82% D0% BD% D0% B0% D1% 8F% 20Express% 20% D0% B2% D0% B5% D1% 80 % D1% 81% D0% B8% D1% 8F).

% 0A

% D0% 92% 20% D0% BF% D0% BE% D1% 81% D0% BB% D0% B5% D0% B4% D0% BD% D0% B5% D0% B9% 20% D0% B2% D0 % B5% D1% 80% D1% 81% D0% B8% D0% B8% 20 Microsoft% 20Visual% 20Studio% 202010% 20% D0% BF% D0% BE% D1% 8F% D0% B2% D0% B8% D0 % BB% D1% 81% D1% 8F% 20% D0% BD% D0% BE% D0% B2% D1% 8B% D0% B9% 20% D1% 82% D0% B8% D0% BF% 20% D0 % BF% D1% 80% D0% BE% D0% B5% D0% BA% D1% 82% D0% B0% 20-% 20 Modellierung,% 20% D0% BA% D0% BE% D1% 82% D0 % BE % D1% 80% D1% 8B% D0% B9% 20% D0% BF% D0% BE% D0% B7% D0% B2% D0% BE% D0% BB% D1% 8F% D0% B5% D1 % 82 % 20 % D1 % 80 % D0 % B8 % D1 % 81 % D0 % BE % D0 % B2 % D0 % B0 % D1 % 82 % D1 % 8C % 20 % D1 % 80 % D0 % B0 % D0 % B7 % D0 % BB% D0% B8% D1% 87% D0% BD% D1% 8B% D0% B5% 20UML% 20% D0% B4% D0% B8% D0% B0% D0% B3% D1% 80% D0 % B0 % D0% BC% D0% BC% D0% B0% 20% D0% B8% 20% D0% BF% D1% 80% D0% BE% D0% B2% D0% B5% D1% 80% D1% 8F % D1 % 82% D1% 8C% 20% D0% BD% D0% B0% D0% BF% D0% B8% D1% 81% D0% B0% D0% BD% D0% BD% D1% 8B% D0% B5 % 20 % D1% 80% D0% B5% D1% 88% D0% B5% D0% BD% D0% B8% D1% 8F% 20% D0% BD% D0% B0% 20% D1% 81% D0% BE % D0 % BE% D1% 82% D0% B2% D0% B5% D1% 82% D1% 81% D1% 82% D0% B2% D0% B8% D0% B5% 20% D1% 81% 20% D0 % BD % D0% B5% D0% BE% D0% B1% D1% 85% D0% BE% D0% B4% D0% B8% D0% BC% D0% BE% 20% D0% B0% D1% 80% D1 % 85 % D0 % B8 % D1 % 82 % D0 % B5 % D0 % BA % D1 % 82 % D1 % 83 % D1 % 80 % D0 % BE % D0 % B9.

% 0A

% D0% 9F% D0% BE% D0% B7% D0% B2% D0% BE% D0% BB% D1% 8F% D0% B5% D1% 82% 20% D0% B3% D0% B5% D0% BD % D0% B5% D1% 80% D0% B8% D1% 80% D0% BE% D0% B2% D0% B0% D1% 82% D1% 8C% 20 Sequenz% 20Diagramm% 20% D0% BD% D0% B0 % 20 % D0 % BE % D1 % 81 % D0 % BD % D0 % BE % D0 % B2 % D0 % B0 % D0 % BD % D0 % B8 % D0 % B8 % 20 % D0 % BA % D0 % BE % D0 % B4% D0% B0,% 20% D0% B2% D0% B8% D0% B7% D1% 83% D0% B0% D0% BB% D0% B8% D0% B7% D0% B8% D1% 80 % D0% BE% D0% B2% D0% B0% D1% 82% D1% 8C% 20% D1% 81% D0% B2% D1% 8F% D0% B7% D0% B8% 20% D0% B2% 20 % D0% BF% D1% 80% D0% BE% D0% B5% D0% BA% D1% 82% D0% B5% 20% D0% BC% D0% B5% D0% B6% D0% B4% D1% 83 % 20% D0% BA% D0% BE% D0% BC% D0% BF% D0% BE% D0% BD% D0% B5% D0% BD% D1% 82% D0% B0% D0% BC% D0% B8 , % 20 % D1 % 81 % D0 % B1 % D0 % BE % D1 % 80 % D0 % BA % D0 % B0 % D0 % BC % D0 % B8 % 20 % D0 % B8 % 20 % D1 % 81 % D1 % 81 % D1% 8B% D0% BB% D0% BA% D0% B0% D0% BC% D0% B8% 20% D0% B8% 20% D1% 82,% D0% B4.

% 0A

% D0% 9F% D1% 80% D0% B8% D0% BC% D0% B5% D1% 80% 20Use% 20case% 20% D0% B4% D0% B8% D0% B0% D0% B3% D1% 80 % D0% B0% D0% BC% D0% BC% D1% 8B,% 20% D0% BD% D0% B0% D1% 80% D0% B8% D1% 81% D0% BE% D0% B2% D0% B0% D0% BD% D0% BD% D0% BE% D0% B9% 20% D0% B2% 20Visual% 20Studio% 202010:

% 0A% 0A

% D0% 9A% D1% 80% D0% BE% D0% BC% D0% B5% 20% D1% 82% D0% BE% D0% B3% D0% BE,% 20% D0% B4% D0% BE% D1% 81% D1% 82% D1% 83% D0% BF% D0% B5% D0% BD% 20Visualisierung% 20und% 20Modellierung% 20Feature% 20Pack% 20 (% D0% B4% D0% BB% D1% 8F% 20 % D0% BF% D0% BE% D0% B4% D0% BF% D0% B8% D1% 81% D1% 87% D0% B8% D0% BA% D0% BE% D0% B2% 20MSDN),% 20 % D0% BA% D0% BE% D1% 82% D0% BE% D1% 80% D1% 8B% D0% B9% 20% D0% BF% D0% BE% D0% B7% D0% B2% D0% BE % D0% BB% D1% 8F% D0% B5% D1% 82:

% 0A

• % D0% B3% D0% B5% D0% BD% D0% B5% D1% 80% D0% B8% D1% 80% D0% BE% D0% B2% D0% B0% D1% 82% D1% 8C% 20 % D0% BA% D0% BE% D0% B4% 20% D0% BD% D0% B0% 20% D0% B1% D0% B0% D0% B7% D0% B5% 20UML% 20% D0% B4% D0 % B8% D0% B0% D0% B3% D1% 80% D0% B0% D0% BC% D0% BC% 20% D0% BA% D0% BB% D0% B0% D1% 81% D1% 81% D0 % BE% D0% B2
% 0A
• % D1% 81% D0% BE% D0% B7% D0% B4% D0% B0% D0% B2% D0% B0% D1% 82% D1% 8C% 20UML% 20% D0% B4% D0% B8% D0 % B0% D0% B3% D1% 80% D0% B0% D0% BC% D0% BC% D1% 8B% 20% D0% B8% D0% B7% 20% D0% BA% D0% BE% D0% B4 % D0% B0
% 0A
• % D0% B8% D0% BC% D0% BF% D0% BE% D1% 80% D1% 82% D0% B8% D1% 80% D0% BE% D0% B2% D0% B0% D1% 82% D1 % 8C% 20UML% 20% D0% B4% D0% B8% D0% B0% D0% B3% D1% 80% D0% B0% D0% BC% D0% BC% D1% 8B% 20% D0% BA% D0 % BB% D0% B0% D1% 81% D1% 81% D0% BE% D0% B2,% 20% D0% B4% D0% B8% D0% B0% D0% B3% D1% 80% D0% B0% D0% BC% D0% BC% D1% 8B% 20% D0% BF% D0% BE% D1% 81% D0% BB% D0% B5% D0% B4% D0% BE% D0% B2% D0% B0% D1% 82% D0% B5% D0% BB% D1% 8C% D0% BD% D0% BE% D1% 81% D1% 82% D0% B5% D0% B9,% 20% D0% B4% D0% B8 % D0% B0% D0% B3% D1% 80% D0% B0% D0% BC% D0% BC% D1% 8B% 20% D0% B2% D0% B0% D1% 80% D0% B8% D0% B0 % D0% BD% D1% 82% D0% BE% D0% B2% 20% D0% B8% D1% 81% D0% BF% D0% BE% D0% BB% D1% 8C% D0% B7% D0% BE % D0% B2% D0% B0% D0% BD% D0% B8% D1% 8F% 20% D1% 81% 20XMI% 202,1
% 0A
• % D1% 81% D0% BE% D0% B7% D0% B4% D0% B0% D0% B2% D0% B0% D1% 82% D1% 8C% 20% D0% B4% D0% B8% D0% B0 % D0% B3% D1% 80% D0% B0% D0% BC% D0% BC% D1% 8B% 20% D0% B7% D0% B0% D0% B2% D0% B8% D1% 81% D0% B8 % D0% BC% D0% BE% D1% 81% D1% 82% D0% B5% D0% B9% 20% D0% B4% D0% BB% D1% 8F% 20ASP.NET,% 20C% 20% D0% B8% 20C ++% 20% D0% BF% D1% 80% D0% BE% D0% B5% D0% BA% D1% 82% D0% BE% D0% B2
% 0A
• % D1% 81% D0% BE% D0% B7% D0% B4% D0% B0% D0% B2% D0% B0% D1% 82% D1% 8C% 20% D0% B8% 20% D0% BF% D1 % 80 % D0 % BE % D0 % B2 % D0 % B5 % D1 % 80 % D1 % 8F % D1 % 82 % D1 % 8C % 20 Lagen % 20 Diagramme % 20 % D0 % B4 % D0 % BB % D1 % 8F % 20 C % 20% D0% B8% 20C ++% 20% D0% BF% D1% 80% D0% BE% D0% B5% D0% BA% D1% 82% D0% BE% D0% B2
% 0A
• % D0 % BF % D0 % B8 % D1 % 81 % D0 % B0 % D1 % 82 % D1 % 8C % 20 % D1 % 81 % D0 % BE % D0 % B1 % D1 % 81 % D1 % 82 % D0 % B2 % D0% B5% D0% BD% D0% BD% D1% 8B% D0% B5% 20% D0% BF% D1% 80% D0% BE% D0% B2% D0% B5% D1% 80% D0% BA % D0% B8% 20% D0% B4% D0% BB% D1% 8F% 20Schicht% 20Diagramme
% 0A

% D0% A1% D0% BA% D0% B0% D1% 87% D0% B0% D1% 82% D1% 8C% 20Visualisierung% 20and% 20Modellierung% 20Feature% 20Pack% 20% D0% BC% D0% BE% D0 % B6% D0% BD% D0% BE% 20% D0% BF% D0% BE% 20% D1% 81% D1% 81% D1% 8B% D0% BB% D0% BA% D0% B5:% 20 http://msdn.microsoft.com/ru-ru/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

Chancen:

• Anwendungsfalldiagramm
• Bereitstellungsdiagramm (Topologiediagramme);
• Zustandsdiagramm;
• Aktivitätsdiagramm
• Interaktionsdiagramm
• Sequenzdiagramm
• Kooperationsdiagramm
• Klassen Diagramm
• Komponentendiagramm

Screenshots:

Open-Source-Programme

SternUML

Chancen:

• UML 2.0-Unterstützung
• MDA (Modellgetriebene Architektur)
• Plug-in-Architektur (Sie können in COM-kompatiblen Sprachen schreiben: C ++, Delphi, C #, VB, ...)

StarUML ist hauptsächlich in Delphi geschrieben, Sie können jedoch Komponenten in anderen Sprachen hinzufügen, zum Beispiel C / C ++, Java, Visual Basic, Delphi, JScript, VBScript, C #, VB.NET. Nachfolgend werden mehrere Screenshots gezeigt.

Klassen Diagramm:

Anwendungsfalldiagramm:

ArgoUML

Unterstützte Diagramme:

• Klasse
• Zustand
• Anwendungsfall
• Aktivität
• Zusammenarbeit
• Einsatz
• Reihenfolge

Chancen:

• Unterstützung für neun UML 1.4-Diagramme
• Plattformunabhängig (Java 5+)
• UML 1.4 Standard-Metamodell
• XMI-Unterstützung
• Export in GIF, PNG, PS, EPS, PGML und SVG
• Sprachen: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
• OCL-Unterstützung
• Forward-, Reverse-Engineering

Bildschirmfoto:

Alle UML-Diagramme lassen sich grob in zwei Gruppen einteilen, von denen die erste allgemeine Diagramme sind. Übersichtsdiagramme sind praktisch unabhängig vom Thema Modellierung und können in jedem Softwareprojekt ohne Rücksicht auf Themengebiet, Lösungsgebiet etc. verwendet werden.

1.5.1. Nutzungsdiagramm

Nutzungsdiagramm(Use-Case-Diagramm) ist die allgemeinste Darstellung des funktionalen Zwecks des Systems.

Das Nutzungsdiagramm soll die zentrale Modellierungsfrage beantworten: Was macht das System in der Außenwelt?

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

• die Assoziation zwischen Akteur und Anwendungsfall 3;
• Generalisierung zwischen Akteuren 4;
• Verallgemeinerung zwischen Anwendungsfällen 5;
• Abhängigkeiten (verschiedener Art) zwischen Anwendungsfällen 6.

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

Die Grundelemente der im Nutzungsdiagramm verwendeten Notation sind unten dargestellt. Eine detaillierte Beschreibung finden Sie in Abschnitt 2.2.

1.5.2. Klassen Diagramm

Klassen Diagramm(Klassendiagramm) ist die wichtigste Methode, um die Struktur eines Systems zu beschreiben.

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

In einem Klassendiagramm wird ein Haupttyp von Entitäten verwendet: Klassen 1 (einschließlich zahlreicher Spezialfälle von Klassen: Interfaces, primitive Typen, Assoziationsklassen und viele andere), zwischen denen die folgenden grundlegenden Arten von Beziehungen hergestellt werden:

• Assoziation zwischen den Klassen 2 (mit vielen zusätzlichen Details);
• Verallgemeinerung zwischen den Klassen 3;
• Abhängigkeiten (verschiedener Art) zwischen 4 Klassen und zwischen Klassen und Schnittstellen.

Einige der Elemente der Klassendiagrammnotation werden unten gezeigt. Eine ausführliche Beschreibung findet sich in Kapitel 3.

1.5.3. Automatendiagramm

Automatendiagramm(State-Machine-Diagramm) ist eine der Möglichkeiten, das Verhalten in der UML anhand der expliziten Hervorhebung von Zuständen und der Beschreibung von Übergängen zwischen Zuständen detailliert zu beschreiben.

Im Wesentlichen sind Automatendiagramme, wie der Name schon sagt, ein Zustandsübergangsgraph (siehe Kapitel 4), der mit vielen zusätzlichen Details und Details beladen ist.

Im Automatendiagramm wird ein Haupttyp von Entität verwendet - Zustände 1 und ein Beziehungstyp - Übergänge 2, aber für beide sind viele Varianten, Sonderfälle und zusätzliche Bezeichnungen 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, und die folgende Abbildung zeigt nur die Grundelemente der im Automatendiagramm verwendeten Notation.

1.5.4. Aktivitätsdiagramm

Aktivitätsdiagramm(Aktivitätsdiagramm) - eine Möglichkeit, Verhalten basierend auf der Angabe von Kontrollflüssen und Datenflüssen zu beschreiben.

Ein Aktivitätsdiagramm ist eine weitere Möglichkeit, ein Verhalten zu beschreiben, das optisch einem guten altmodischen Flussdiagramm ähnelt. Durch die modernisierte Notation, die dem objektorientierten Ansatz entspricht, und vor allem durch die neue semantische Komponente (freie Interpretation von Petri-Netzen) ist das UML-Aktivitätsdiagramm jedoch ein mächtiges Werkzeug, um das Verhalten eines Systems zu beschreiben.

Im Aktivitätsdiagramm wird ein Haupttyp von Entität verwendet - Aktivität 1 und ein Beziehungstyp - Übergänge 2 (Kontrolle und Datenübertragungen). Es werden auch Konstruktionen wie Forks, Merges, Joins, Branches 3 verwendet, die Entitäten ähneln, es aber nicht sind, sondern eine grafische Darstellung einiger Spezialfälle von mehrstelligen Relationen darstellen. Die Semantik von Aktivitätsdiagrammelementen wird in Kapitel 4 detailliert beschrieben. Die grundlegenden Elemente der Notation, die in einem Aktivitätsdiagramm verwendet werden, werden unten gezeigt.

1.5.5. Sequenzdiagramm

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

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

Im Sequenzdiagramm wird ein Haupttyp von Entitäten verwendet - Instanzen von interagierenden Klassifikatoren 1 (hauptsächlich Klassen, Komponenten und Akteure) und ein Beziehungstyp - Links 2, über die Nachrichten ausgetauscht werden 3. Es gibt mehrere Möglichkeiten, Nachrichten zu senden, die sich in grafischer Notation durch die Art des Pfeils unterscheiden, der der Relation entspricht.

Ein wichtiger Aspekt des Sequenzdiagramms ist die explizite Darstellung des Zeitablaufs. Im Gegensatz zu anderen Diagrammtypen, außer vielleicht Synchronisationsdiagrammen, ist in einem Sequenzdiagramm nicht nur das Vorhandensein grafischer Beziehungen zwischen Elementen von Bedeutung, sondern auch die relative Position der Elemente im Diagramm. Es wird nämlich davon ausgegangen, dass es eine (unsichtbare) Zeitachse gibt, die standardmäßig von oben nach unten gerichtet ist, und die später gesendete Nachricht ist unten eingezeichnet.

Die Zeitachse kann horizontal ausgerichtet sein, 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 bezeichnen, wird die Standardnotation verwendet - ein Rechteck mit dem Namen der Klassifikatorinstanz. Die davon ausgehende gestrichelte Linie wird als Lebenslinie bezeichnet 4. Dies ist keine Bezeichnung für eine Beziehung im Modell, sondern ein grafischer Kommentar, der den Blick des Lesers in die richtige Richtung lenken soll. Auch die der Lebenslinie überlagerten Figuren in Form schmaler Streifen sind keine Abbilder der modellierten Entitäten. Dies ist ein grafischer Kommentar, der die Zeitintervalle zeigt, in denen das Objekt das Ausführungsereignis 5 besitzt, oder mit anderen Worten, die Objektaktivierung erfolgt. Kombinierte Fragmentschritte 6 ermöglichen, dass ein Sequenzdiagramm die algorithmischen Aspekte eines Interaktionsprotokolls widerspiegelt. Weitere Informationen zur Notation von Sequenzdiagrammen finden Sie in Kapitel 4.

1.5.6. Kommunikationsdiagramm

Kommunikationsdiagramm(Kommunikationsdiagramm) - eine Art der Verhaltensbeschreibung, die semantisch einem Sequenzdiagramm entspricht.

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

Daher wird sowohl im Kommunikationsdiagramm als auch im Sequenzdiagramm ein Haupttyp von Entitäten verwendet - Instanzen von interagierenden Klassifikatoren 1 und ein Beziehungstyp - Links 2. Der Schwerpunkt liegt hier jedoch nicht auf der Zeit, sondern auf der Struktur der Verbindungen zwischen bestimmten Instanzen.

Die Abbildung zeigt die grundlegenden Elemente der Notation, die in einem Kommunikationsdiagramm verwendet werden. Um die interagierenden Objekte selbst zu bezeichnen, wird die Standardnotation verwendet - ein Rechteck mit dem Namen der Klassifikatorinstanz. Die relative Position der Elemente auf dem Kooperationsdiagramm spielt keine Rolle – wichtig sind nur die Links (meist Instanzen von Assoziationen), über die Nachrichten übertragen werden 3. Die hierarchische Dezimalnummerierung wird verwendet, um die Reihenfolge der Nachrichten im Zeitverlauf anzuzeigen.

1.5.7. Komponentendiagramm

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

Der Haupttyp von Entitäten im Komponentendiagramm sind die Komponenten 1 selbst sowie die Schnittstellen 2, über die die Beziehung zwischen den Komponenten angezeigt wird. In einem Komponentendiagramm gelten die folgenden 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 findet sich in Kapitel 3.

1.5.8. Platzierungsdiagramm

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

Daher werden im Platzierungsdiagramm im Vergleich zum Komponentendiagramm zwei Arten von Entitäten hinzugefügt: Artefakt 1, das die Implementierung von Komponente 2 und Knoten 3 ist (es kann entweder ein Klassifikator sein, der den Typ eines Knotens beschreibt, oder a spezifische Instanz) sowie eine Assoziationsbeziehung zwischen Nodes 4, die zeigt, dass die Nodes 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 in die Form einer anderen Entität 6 eingefügt. Eine detaillierte Beschreibung des Diagramms finden Sie in Kapitel 3.