Grundlegende UML-Diagramme. Grunddiagramme der UML. Interne Aktivitäten im Statechart

& nbsp & nbsp & nbsp & nbsp Die Unified Modeling Language (UML) ist eine Sprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von Softwaresystemen sowie von Geschäftsmodellen und anderen Nicht-Softwaresystemen. UML ist eine Verschmelzung von Engineering-Techniken, die zuvor erfolgreich zur Modellierung großer und komplexer Systeme eingesetzt wurden.

& nbsp & nbsp & nbsp & nbsp Die Schöpfer von UML repräsentieren es als eine Sprache zum Definieren, Darstellen, Entwerfen und Dokumentieren von Softwaresystemen, Geschäftssystemen und anderen Systemen unterschiedlicher Art. UML definiert Notation und Metamodell. Eine Notation ist eine Sammlung von grafischen Objekten, die in Modellen verwendet werden; es ist die Syntax einer Modellierungssprache.

Die UML & nbsp & nbsp & nbsp & nbsp UML bietet ausdrucksstarke Werkzeuge 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 Projektentwicklungsmethodik ab;
• kann jede OO-Programmiersprache unterstützen.

& nbsp & nbsp & nbsp & nbsp UML ist Open Source und auf den zugrunde liegenden Kern erweiterbar. In UML können Sie Klassen, Objekte und Komponenten in verschiedenen, oft sehr unterschiedlichen Themenbereichen sinnvoll beschreiben.

UML-Diagramme

& nbsp & nbsp & nbsp & nbsp Rational Rose stellt dem Systemdesigner die folgenden Diagrammtypen zur Verfügung, deren sequentielle Erstellung es Ihnen ermöglicht, sich ein vollständiges Bild des gesamten entworfenen Systems und seiner einzelnen Komponenten zu machen:

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

& nbsp & nbsp & nbsp & nbsp Jedes dieser Diagramme konkretisiert eine andere Sicht auf das Systemmodell. In diesem Fall stellt das Use-Case-Diagramm ein konzeptionelles Modell des Systems dar, das Ausgangspunkt für die Konstruktion aller anderen Diagramme ist. Ein Klassendiagramm ist ein logisches Modell, das die statischen Aspekte des strukturellen Designs eines Systems widerspiegelt, und Verhaltensdiagramme, die ebenfalls 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 obigen Diagrammen werden einige verwendet, um zwei oder mehr Unterarten anzuzeigen. Als unabhängige Darstellungen werden folgende Diagramme verwendet: Anwendungsfälle, Klassen, Zustände, Aktivitäten, Sequenz, Kooperation, Komponenten und Deployments.

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

• Verbindungen, die durch verschiedene Linien in der Ebene dargestellt werden;
• Text innerhalb der Grenzen einzelner geometrischer Formen enthalten;
• grafische Symbole in der Nähe der Grafiken der Diagramme gezeichnet.

& nbsp & nbsp & nbsp & nbsp Bei der grafischen Darstellung von Diagrammen empfiehlt es sich, folgende Regeln zu beachten:

• jedes Diagramm sollte eine vollständige Darstellung eines Fragments der simulierten Domäne sein;
• die im Diagramm dargestellten Entitäten des Modells müssen sich auf derselben konzeptionellen Ebene befinden;
• alle Informationen über Entitäten müssen im Diagramm klar dargestellt werden;
• Diagramme sollten keine widersprüchlichen Informationen enthalten;
• Diagramme sollten nicht mit Textinformationen überladen werden;
• jedes Diagramm muss für die korrekte Interpretation aller seiner Elemente autark sein;
• die Anzahl der Diagrammtypen, die zur Beschreibung eines bestimmten Systems erforderlich sind, ist nicht streng festgelegt und wird vom Entwickler bestimmt;
• Systemmodelle dürfen nur die Elemente enthalten, die in 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 wichtigsten objektorientierten Elemente der Sprache, mit der Modelle erstellt werden.

& nbsp & nbsp & nbsp & nbsp Strukturelle Einheiten sind Substantive in UML-Modellen. Typischerweise stellen sie statische Teile des Modells dar, die konzeptionellen oder physikalischen Elementen des Systems entsprechen. Beispiele für strukturelle Entitäten sind Klasse, Schnittstelle, Kooperation, Anwendungsfall, Komponente, Knoten, Akteur.

& nbsp & nbsp & nbsp & nbsp Verhaltensentitäten sind 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 Essenz der Austausch von Nachrichten zwischen Objekten in einem bestimmten Kontext ist, um ein bestimmtes Ziel zu erreichen;
• Automat - ein Verhaltensalgorithmus, der die Folge von Zuständen bestimmt, die ein Objekt oder eine Interaktion als Reaktion auf verschiedene Ereignisse durchläuft.

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

& nbsp & nbsp & nbsp & nbsp Pakete sind ein universeller Mechanismus zum Organisieren von Elementen in Gruppen. Strukturelle, verhaltensbezogene und andere Gruppierungsentitäten können im Paket platziert werden. Im Gegensatz zu Komponenten, die tatsächlich existieren, während das Programm läuft, sind Pakete rein konzeptionell, dh sie existieren nur während des Entwicklungsprozesses.

& nbsp & nbsp & nbsp & nbsp Anmerkungselemente sind erklärende Teile des UML-Modells: Kommentare für zusätzliche Beschreibungen, Erläuterungen oder Anmerkungen zu jedem Element des Modells. Es gibt nur einen grundlegenden Typ von Anmerkungselementen, Anmerkungen. Eine Notiz 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 Glue-Konstrukte in der UML und werden auch verwendet, um Modelle zu erstellen.

& nbsp & nbsp & nbsp & nbsp Abhängigkeit ist eine semantische Beziehung zwischen zwei Entitäten, bei 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 Menge semantischer oder logischer Verbindungen zwischen Objekten beschreibt.

& nbsp & nbsp & nbsp & nbsp Verallgemeinerung ist eine Beziehung, in der ein spezialisiertes Elementobjekt (Nachkomme) durch ein generisches Elementobjekt (Vorfahre) ersetzt werden kann. Gleichzeitig erbt das Kind nach den Prinzipien der objektorientierten Programmierung die Struktur und das Verhalten seines Elternteils (Elternteil).

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

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

Gängige UML-Mechanismen

& nbsp & nbsp & nbsp & nbsp Für eine genaue Beschreibung des Systems in UML werden die sogenannten allgemeinen Mechanismen verwendet:

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

& nbsp & nbsp & nbsp & nbsp UML ist nicht nur eine grafische Sprache. Jedes grafische Element seiner Notation hat Spezifikation die die textuelle Repräsentation des entsprechenden Sprachkonstrukts enthält. Ein Klassensymbol hat beispielsweise eine Spezifikation, die seine Attribute, Operationen und sein Verhalten beschreibt, obwohl das Symbol in einem Diagramm visuell oft nur einen kleinen Teil dieser Informationen widerspiegelt. Darüber hinaus kann das Modell eine andere Darstellung dieser Klasse enthalten, die völlig andere Aspekte davon widerspiegelt, aber dennoch der Spezifikation entspricht. So wird die grafische UML-Notation verwendet, um das System zu visualisieren und mit Hilfe von Spezifikationen seine Details zu beschreiben.

& nbsp & nbsp & nbsp & nbsp Fast jedes UML-Element verfügt über eine einzigartige grafische Darstellung, die eine visuelle Darstellung seiner wichtigsten Eigenschaften bietet. Die Entitätsnotation "Klasse" enthält ihren Namen, ihre Attribute und Operationen. Eine Klassenspezifikation kann andere Details enthalten, wie 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 in das Standardrechteck, das die Klasse darstellt.

& nbsp & nbsp & nbsp & nbsp Bei der Modellierung objektorientierter Systeme gibt es eine gewisse Teilung vertretenen Einheiten.

& nbsp & nbsp & nbsp & nbsp Zunächst gibt es eine Einteilung in Klassen und Objekte. Eine Klasse ist eine Abstraktion, und ein Objekt ist eine konkrete Verkörperung dieser Abstraktion. In dieser Hinsicht zeichnen sich fast alle Sprachkonstrukte durch eine Klasse/Objekt-Dualität aus. 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 die Dualität von Schnittstelle/Implementierung aus. Anwendungsfälle werden beispielsweise durch Genossenschaften und Operationen durch Methoden umgesetzt.

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

& nbsp & nbsp & nbsp & nbsp UML-Erweiterungsmechanismen umfassen:

• Stereotypen (Stereotypen) - Erweitern Sie das UML-Vokabular, um basierend auf bestehenden Sprachelementen neue zu erstellen, die auf die Lösung eines bestimmten Problems ausgerichtet sind;
• Tagged-Wert – 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 Ihnen diese drei Spracherweiterungsmechanismen die Anpassung an die Anforderungen des Projekts oder die Besonderheiten der Entwicklungstechnologie.

Anwendungsfalldiagramm

& nbsp & nbsp & nbsp & nbsp Mit diesem Diagrammtyp können Sie eine Liste der Operationen erstellen, die das System ausführt. Diese Art von Diagramm wird oft als Funktionsdiagramm bezeichnet, da auf der Grundlage einer Menge solcher Diagramme eine Liste von Systemanforderungen erstellt wird und die Menge der vom System ausgeführten Funktionen bestimmt wird.

Abbildung - 1. Diagramm der Anwendungsfälle

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

• die allgemeinen Grenzen und den Kontext der simulierten Domäne definieren;
• allgemeine Anforderungen an das Funktionsverhalten des entworfenen Systems formulieren;
• ein erstes konzeptionelles Modell des Systems für seine spätere Detaillierung in Form von logischen und physikalischen Modellen entwickeln;
• erstellen erste Dokumentationen für die Interaktion der Systementwickler mit ihren Kunden und Benutzern.

& nbsp & nbsp & nbsp & nbsp Die Essenz des Anwendungsfalldiagramms ist wie folgt. Das zu entwerfende System wird als eine Menge von Entitäten oder Akteuren dargestellt, die durch Anwendungsfälle mit dem System interagieren. In diesem Fall ist ein Akteur oder ein Akteur jede Entität, die von außen mit dem System interagiert. Dabei kann es sich um eine Person, ein technisches Gerät, ein Programm oder jedes andere System handeln, das, wie der Entwickler selbst bestimmt, Einfluss auf das modellierte System nehmen kann. Anwendungsfall dient zur Beschreibung der Dienste, die das System dem Akteur erbringt.

& 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 zu offenbaren. Eine solche Entität kann ein System oder ein beliebiges Element eines Modells sein, das sein eigenes Verhalten hat.

& nbsp & nbsp & nbsp & nbsp Jeder Anwendungsfall entspricht einem separaten Dienst, den die modellierte Entität auf Anfrage des Akteurs bereitstellt, dh bestimmt, wie diese Entität verwendet wird. Der Dienst, der auf Wunsch des Akteurs initialisiert wird, ist eine vollständige, unteilbare Abfolge von Aktionen. Das bedeutet, dass das System nach Abschluss der Auftragsbearbeitung in seinen ursprünglichen Zustand zurückkehren muss, um die nächsten Aufträge ausführen zu können.

& nbsp & nbsp & nbsp & nbsp Use Cases können verwendet werden, um sowohl externe Anforderungen an das entworfene System zu spezifizieren als auch das funktionale Verhalten eines bestehenden Systems zu spezifizieren. Die Gesamtheit der Anwendungsfälle sollte alle möglichen Seiten des erwarteten Verhaltens des Systems definieren. Darüber hinaus stellen Use Cases implizit Anforderungen, die bestimmen, wie Akteure mit dem System interagieren müssen, um mit den bereitgestellten Diensten korrekt arbeiten zu können. Der Einfachheit halber können viele Anwendungsfälle als separates Paket betrachtet werden.

& nbsp & nbsp & nbsp & nbsp Beispiele für Anwendungsfälle sind: den Status des Girokontos eines Kunden prüfen, eine Bestellung zum Kauf eines Artikels aufgeben, zusätzliche Informationen über die Kreditwürdigkeit eines Kunden einholen, ein grafisches Formular auf einem Bildschirm anzeigen, und andere Aktionen.

Klassen Diagramm

& nbsp & nbsp & nbsp & nbsp Im Zentrum der objektorientierten Programmierung steht die Entwicklung eines logischen Modells eines Systems in Form eines Klassendiagramms. Ein Klassendiagramm (Klassendiagramm) dient der Darstellung der statischen Struktur eines Systemmodells in der Terminologie der Klassen der objektorientierten Programmierung. 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 Diagrammsymbole ermöglichen die Darstellung einer komplexen Hierarchie von Systemen, Klassenbeziehungen (Klassen) und Schnittstellen (Schnittstellen). Diese Art von Diagramm ist inhaltlich dem Kollaborationsdiagramm entgegengesetzt, das Systemobjekte anzeigt. Mit Rational Rose können Sie Klassen mit diesem Diagrammtyp in einer Vielzahl von Notationen erstellen. wie eine Wolke. Somit ist eine Klasse nur eine Vorlage, nach der in Zukunft ein bestimmtes Objekt erstellt wird.

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

& nbsp & nbsp & nbsp & nbsp Klasse in der UML-Sprache wird es verwendet, um eine Menge von Objekten zu bezeichnen, die die gleiche Struktur, das gleiche Verhalten und die gleichen Beziehungen zu Objekten anderer Klassen 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 (Statechart-Diagramm)

& 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, d. h. es modelliert alle Zustandsänderungen eines Objekts als seine Reaktion auf äußere Einflüsse.

& nbsp & nbsp & nbsp & nbsp Statecharts werden am häufigsten verwendet, um das Verhalten einzelner Objekte zu beschreiben, können aber auch verwendet werden, um die Funktionalität anderer Modellkomponenten wie Anwendungsfälle, Akteure, Subsysteme, Operationen und Methoden zu spezifizieren.

Abbildung - 2. Zustandsdiagramm

& nbsp & nbsp & nbsp & nbsp Ein Zustandsdiagramm ist eine besondere Art von Graph, der einen Automaten repräsentiert. Die Ecken des Graphen sind die möglichen Zustände des Automaten, dargestellt durch die entsprechenden grafischen Symbole, und die Bögen zeigen seine Übergänge von Zustand zu Zustand an. Zur detaillierteren Darstellung einzelner Elemente des Modells können Zustandsdiagramme 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 in Form eines diskreten Raums mit einer endlichen Anzahl von Zuständen und Übergängen darzustellen.

& nbsp & nbsp & nbsp & nbsp Die Dauer der Anwesenheit des Systems in einem der möglichen Zustände überschreitet deutlich die Zeit, die für den Übergang von einem Zustand in einen anderen benötigt wird. Es wird davon ausgegangen, dass im Grenzfall die Übergangszeit gleich Null sein kann (sofern nicht anders angegeben), d. h. die Änderung der Objektzustände kann sofort erfolgen.

& nbsp & nbsp & nbsp & nbsp Das Verhalten der Maschine wird als sequentielle Bewegung entlang des Graphen von Scheitelpunkt zu Scheitelpunkt unter Berücksichtigung der Orientierung der sie verbindenden Bögen modelliert.

& nbsp & nbsp & nbsp & nbsp Folgende 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 beliebig lange in einem separaten Zustand verbleiben, wenn keine Ereignisse eintreten;
• die Zeit, zu der sich die Maschine in einem bestimmten Zustand befindet, sowie die Zeit, die benötigt wird, um einen bestimmten Zustand zu erreichen, werden in keiner Weise angegeben;
• die Anzahl der Zustände des Automaten muss endlich sein und alle müssen explizit angegeben werden. Einzelne Pseudozustände dürfen keine Spezifikationen haben (Anfangs- und Endzustand). In diesem Fall werden ihr Zweck und ihre Semantik vollständig aus dem Kontext des Modells und des betrachteten Zustandsdiagramms bestimmt;
• der Automatengraph sollte keine isolierten Zustände und Übergänge enthalten. Für jeden Zustand, mit Ausnahme des Anfangszustands, muss ein vorheriger Zustand definiert werden, und jede Transition muss zwei Zustände des Automaten verbinden;
• der Automat sollte keine widersprüchlichen Übergänge enthalten, wenn das Objekt gleichzeitig in zwei oder mehr aufeinanderfolgende Zustände gehen kann (außer bei parallelen Unterautomaten). In der UML können Konflikte durch die Einführung von Guard-Bedingungen vermieden 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 von Besonderheiten auf.

& nbsp & nbsp & nbsp & nbsp In der UML ist state eine abstrakte Metaklasse, die verwendet wird, um eine einzelne Situation zu modellieren, in der bestimmte Bedingungen erfüllt sind. State kann als Satz spezifischer Werte für die Attribute einer Klasse oder eines Objekts angegeben werden. Änderungen an einzelnen Attributwerten spiegeln Änderungen des Zustands 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 notwendig, nicht nur den Prozess der Zustandsänderung darzustellen, sondern auch die Merkmale der algorithmischen und logischen Implementierung der von das System.

& 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 widerzuspiegeln. Mit dieser Art von Diagramm können Sie nicht nur die Abfolge von Prozessen, sondern auch die Verzweigung und sogar die Synchronisation von Prozessen darstellen.

& nbsp & nbsp & nbsp & nbsp Mit dieser Art von Diagrammen können Sie Algorithmen für das Verhalten von Objekten beliebiger Komplexität entwerfen, die auch zum Erstellen von Blockdiagrammen verwendet werden können.

& nbsp & nbsp & nbsp & nbsp Aktivitätsdiagramme werden verwendet, um den Prozess der Ausführung von Operationen in der UML-Sprache zu modellieren. Die von ihnen verwendete grafische Notation ist der Statechart-Notation insofern sehr ähnlich, als sie auch Zustände und Übergänge enthält. Jeder Zustand im Aktivitätsdiagramm entspricht der Ausführung einer elementaren Operation, und der Übergang zum nächsten Zustand wird erst nach Abschluss dieser Operation durchgeführt.

& nbsp & nbsp & nbsp & nbsp Aktivitätsdiagramme können somit als Sonderfall von Zustandsdiagrammen betrachtet werden. Sie ermöglichen es Ihnen, in der UML-Sprache Funktionen der prozeduralen und synchronen Steuerung zu implementieren, da interne Aktivitäten und Aktionen abgeschlossen werden. 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.

& nbsp & nbsp & nbsp & nbsp Im Kontext der UML Aktivität ist eine Sammlung einzelner Berechnungen, die von der Maschine durchgeführt werden und zu einem Ergebnis oder einer Aktion (Aktion) führen. Das Aktivitätsdiagramm zeigt die Logik und Abfolge der Übergänge von einer Aktivität zur anderen, und die Aufmerksamkeit des Analytikers ist auf die Ergebnisse gerichtet. Das Ergebnis der Aktivität kann zu einer Zustandsänderung des Systems oder zur Rückgabe eines Wertes führen.

& nbsp & nbsp & nbsp & nbsp Aktionsstatus ist ein Sonderfall eines Zustands mit einer Eingabeaktion und mindestens einer den Zustand verlassenden Transition. 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 (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 verwendet werden, um die Dynamik des Verhaltens von Systemen zu spezifizieren, 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. UML verwendet Sequenzdiagramme, um die Interaktion von Objekten über die Zeit zu modellieren.

& nbsp & nbsp & nbsp & nbsp Das Sequenzdiagramm zeigt nur diese Objekte die direkt an der Interaktion beteiligt sind. Der Kernpunkt 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 von vertikalen Linien, die jeweils die Lebenslinie eines separaten an der Interaktion beteiligten Objekts darstellen. Ganz links im Diagramm ist das Objekt dargestellt, das die Interaktion initiiert. Rechts ist ein weiteres Objekt abgebildet, das direkt mit dem ersten interagiert. Somit bilden alle Objekte im Sequenzdiagramm eine Art Ordnung, die durch die Reihenfolge oder den Aktivitätsgrad der Objekte 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 durch einen Doppelpunkt getrennt in das Rechteck geschrieben. 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 Anfangszeitpunkt. 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, die sich im obigen Sequenzdiagramm befinden, werden früher ausgelöst als diejenigen, die sich darunter befinden. Der Maßstab auf der Zeitachse ist nicht angegeben, da das Sequenzdiagramm nur die zeitliche Ordnung früher-später Wechselwirkungen modelliert.

Kooperationsdiagramm

& nbsp & nbsp & nbsp & nbsp Das Hauptmerkmal des Kooperationsdiagramms ist die Möglichkeit, nicht nur den Ablauf der Interaktion, sondern auch alle strukturellen Beziehungen zwischen den an dieser Interaktion beteiligten Objekten grafisch darzustellen.

Abbildung - 3. Kooperationsdiagramm

& nbsp & nbsp & nbsp & nbsp Mit dieser Art von Diagramm können Sie die Interaktion von Objekten beschreiben, abstrahiert von der Reihenfolge der Übertragung von Nachrichten. 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 Das Kooperationsdiagramm in Form von Rechtecken stellt zunächst die an der Interaktion teilnehmenden Objekte dar, die den Namen des Objekts, seine Klasse und ggf. die Werte der Attribute enthalten. Außerdem werden wie im Klassendiagramm Assoziationen zwischen Objekten in Form verschiedener Verbindungslinien angezeigt. In diesem Fall können Sie die Namen der Assoziation und die Rollen, die Objekte in dieser Assoziation spielen, explizit angeben. Zusätzlich können dynamische Links - Nachrichtenströme abgebildet werden. Sie werden auch als Verbindungslinien zwischen Objekten dargestellt, über denen sich ein Pfeil befindet, der die Richtung, den Nachrichtennamen und die Sequenznummer in der allgemeinen Reihenfolge der Nachrichteninitialisierung anzeigt.

& nbsp & nbsp & nbsp & nbsp Im Gegensatz zu einem Sequenzdiagramm stellt ein Kollaborationsdiagramm nur Beziehungen zwischen Objekten dar, die in einer Interaktion bestimmte Rollen spielen. Dieses Diagramm zeigt die Zeit nicht als separate Dimension an. Daher kann die Reihenfolge von Interaktionen und parallelen Strömen anhand von Sequenznummern bestimmt werden. Wenn Sie die Beziehungen zwischen Objekten in Echtzeit explizit angeben müssen, tun Sie dies daher am besten in einem Sequenzdiagramm.

& nbsp & nbsp & nbsp & nbsp Konzept Zusammenarbeit ist eines der grundlegenden Konzepte der UML. Es dient dazu, eine Menge 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 einzelnen wichtigsten Operationen im System zu spezifizieren. Kooperation definiert die Struktur des Verhaltens des Systems im Hinblick auf die Interaktion der Teilnehmer dieser Kooperation.

& nbsp & nbsp & nbsp & nbsp Kooperation kann auf zwei Ebenen dargestellt werden:

• Spezifikationsebene - zeigt die Rollen von Klassifikatoren und die Rolle von Assoziationen in der betrachteten Interaktion;
• Beispielebene - gibt die Instanzen und Beziehungen an, die separate Rollen in der Kooperation bilden.

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

& nbsp & nbsp & nbsp & nbsp Ein Kooperationsdiagramm auf Beispielebene wird durch eine Sammlung von Objekten (Klasseninstanzen) und Beziehungen (Assoziationsinstanzen) dargestellt. In diesem Fall werden die Links durch Nachrichtenpfeile ergänzt. Auf dieser Ebene werden nur Objekte angezeigt, die in direktem Zusammenhang mit der Implementierung einer Operation oder eines Klassifikators stehen. Dabei ist es gar nicht nötig, alle Eigenschaften bzw. alle Assoziationen abzubilden, da nur die Rollen der Klassifikatoren auf dem Kooperationsdiagramm vorhanden sind, nicht aber die Klassifikatoren selbst. Während also der Klassifikator eine vollständige Beschreibung aller seiner Instanzen erfordert, erfordert die Rolle des Klassifikators nur die Beschreibung der Eigenschaften und Assoziationen, die für die Teilnahme an einer bestimmten Kooperation erforderlich sind.

& nbsp & nbsp & nbsp & nbsp Daraus folgt eine wichtige Konsequenz. Ein und dieselbe Menge von Objekten kann an verschiedenen Genossenschaften teilnehmen. Je nach betrachteter Kooperation können sich sowohl die Eigenschaften einzelner Objekte als auch die Verbindungen zwischen ihnen ändern. Dies unterscheidet ein Kollaborationsdiagramm von einem Klassendiagramm, das alle Eigenschaften und Assoziationen zwischen Diagrammelementen anzeigen muss.

Komponentendiagramm

& nbsp & nbsp & nbsp & nbsp Diese Art von Diagramm ist für die Verteilung von Klassen und Objekten nach Komponenten im physischen Design des Systems gedacht. Diese Art von Diagramm wird oft als Einheitsdiagramm bezeichnet.

Abbildung - 4. Komponentendiagramm

& nbsp & nbsp & nbsp & nbsp Ein vollständiger Entwurf eines Softwaresystems ist ein Satz von Modellen der logischen und physikalischen Ebene, die miteinander konsistent sein müssen. Die UML verwendet Implementierungsdiagramme, um Modelle von Systemen physisch darzustellen, die Folgendes umfassen: Komponentendiagramm und Bereitstellungsdiagramm.

& nbsp & nbsp & nbsp & nbsp Das Komponentendiagramm beschreibt im Gegensatz zu den bisher betrachteten Diagrammen die Merkmale der physikalischen Darstellung des Systems. Es ermöglicht Ihnen, die Architektur des zu entwickelnden Systems zu definieren, indem Sie Abhängigkeiten zwischen Softwarekomponenten herstellen, die Quellcode und ausführbarer Code sein können. Die wichtigsten grafischen Elemente eines Komponentendiagramms sind Komponenten, Schnittstellen und deren Abhängigkeiten.

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

• Visualisierung der allgemeinen Struktur des Quellcodes des Softwaresystems;
• Spezifikationen der ausführbaren Version des Softwaresystems;
• Sicherstellung der Wiederverwendbarkeit einzelner Fragmente des Programmcodes;
• Darstellungen konzeptioneller und physischer Datenbankschemata.

& nbsp & nbsp & nbsp & nbsp An der Entwicklung von Komponentendiagrammen sind Systemanalytiker und -architekten sowie Programmierer beteiligt. Ein Komponentendiagramm bietet einen konsequenten Übergang von einer logischen Sicht zu einer konkreten Implementierung eines Projekts in Form von Programmcode. Einige Komponenten können nur in der Phase der Kompilierung des Programmcodes existieren, andere in der Phase ihrer Ausführung. Ein Komponentendiagramm spiegelt die allgemeinen Abhängigkeiten zwischen Komponenten wider und betrachtet letztere als Klassifikatoren.

& nbsp & nbsp & nbsp & nbsp Um physikalische Einheiten in der UML-Sprache darzustellen, wird ein spezieller Begriff verwendet - Komponente... Die Komponente implementiert einen bestimmten Satz von Schnittstellen und dient zur allgemeinen Bezeichnung der Elemente der physikalischen Repräsentation des Modells. Um das Bauteil grafisch darzustellen, wird ein spezielles Symbol verwendet - ein Rechteck mit links eingefügten zwei kleineren Rechtecken. Innerhalb des großen Rechtecks ​​steht der Name der Komponente und ggf. einige Zusatzinformationen. Die Darstellung dieses Symbols kann je nach Art der mit der Komponente verbundenen Informationen geringfügig abweichen.

Bereitstellungsdiagramm

& nbsp & nbsp & nbsp & nbsp Diese Art von Diagrammen dient der Analyse der Hardware des Systems, dh der "Hardware", und nicht der Programme. In einer direkten Übersetzung aus dem Englischen bedeutet Deployment "Deployment", aber der Begriff "Topologie" spiegelt das Wesen dieser Art von Diagrammen 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 welchen Computermitteln es implementiert ist. Wenn ein Programm entwickelt wird, das lokal auf dem Computer des Benutzers läuft und keine Peripheriegeräte und Ressourcen verwendet, müssen keine zusätzlichen Diagramme entwickelt werden. Bei der Entwicklung von Unternehmensanwendungen kann das Vorhandensein solcher Diagramme äußerst nützlich sein, um die Probleme der rationellen Platzierung von Komponenten zu lösen, um die verteilten Rechen- und Kommunikationsressourcen des Netzwerks effektiv zu nutzen, die 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 Deployment-Diagramm soll die Elemente und Komponenten des Programms visualisieren, die nur in der Phase seiner Ausführung (Laufzeit) existieren. In diesem Fall werden nur die Komponenten-Instanzen des Programms präsentiert, 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 deren Beziehungen. Im Gegensatz zu logischen Ansichtsdiagrammen ist ein Bereitstellungsdiagramm für das System als Ganzes einheitlich, da es die Besonderheiten seiner Implementierung vollständig widerspiegeln muss. Die Entwicklung eines Deployment-Diagramms ist in der Regel der letzte Schritt bei der Spezifikation des Softwaresystemmodells.

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

• die Verteilung der Systemkomponenten durch ihre physischen Knoten bestimmen;
• physikalische Verbindungen zwischen allen Knoten der Systemimplementierung im Stadium ihrer Ausführung zeigen;
• Identifizieren Sie Engpässe im System und konfigurieren Sie seine Topologie neu, um die erforderliche Leistung zu erzielen.

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

Funktionen der Desktop-Benutzeroberfläche von Rational Rose

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

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

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

• Hauptmenü des Programms
• Diagrammfenster
• Dokumentationsfenster
• Browser Fenster
• Log-Fenster

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

Hauptmenü des Programms

Das Hauptmenü des Programms ist nach dem allgemein anerkannten Standard erstellt und hat die folgende Form (Abb. 7).

Einzelne Menüpunkte, deren Zweck sich aus ihren Namen ergibt, vereinen ähnliche Operationen bezogen auf das gesamte Projekt als Ganzes. Einige der Menüpunkte enthalten bekannte Funktionen (Projekt öffnen, Diagramme ausgeben und drucken, in die Zwischenablage kopieren und verschiedene Diagrammelemente aus der Zwischenablage einfügen). Andere sind so spezifisch, dass sie einen zusätzlichen Lernaufwand erfordern (Optionen zur Generierung von Programmcode, Konsistenzprüfung von Modellen, Anbindung weiterer Module).

Abbildung - 7. Das Aussehen des Hauptmenüs des Programms

Standard-Symbolleiste

Die Standardsymbolleiste befindet sich unterhalb des Hauptmenüs des Programms und sieht so 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. Aussehen der Standardsymbolleiste

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

Browser Fenster

Standardmäßig befindet sich das Browserfenster 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 in Ihrem Projekt zu finden. In diesem Fall wird jedes Element, das der Entwickler dem Modell hinzufügt, sofort im Browserfenster angezeigt. Dementsprechend können wir, nachdem wir ein Element im Browserfenster ausgewählt haben, es im Diagrammfenster visualisieren oder seine Spezifikation ändern. Der Browser ermöglicht Ihnen auch, Modellelemente in Paketen zu organisieren und Elemente zwischen verschiedenen Ansichten des Modells zu verschieben. Auf Wunsch kann das Browserfenster an einer anderen Stelle der Arbeitsoberfläche platziert 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

Dedizierte Symbolleiste

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

Abbildung - 10. Erscheinungsbild einer dedizierten 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 für bestimmte Werkzeuge hinzufügen oder entfernen. Die Tastenbelegung finden Sie in den Tooltips, die erscheinen, nachdem der Mauszeiger über die entsprechende Schaltfläche gehalten wird.

Diagrammfenster

Das Diagrammfenster ist der Hauptarbeitsbereich seiner Oberfläche, in dem verschiedene Ansichten des Projektmodells visualisiert werden. Standardmäßig befindet sich das Diagrammfenster auf der rechten Seite der Arbeitsoberfläche, seine Position und Größe kann 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 Elemente des Modells enthält (Abb. 11).

Der Name des Diagramms, das sich in diesem Fenster befindet, wird in der Titelleiste des Programms (oberste Zeile des Programms) oder, wenn das Fenster nicht auf Vollbild erweitert wird, in der Titelleiste des Diagrammfensters angezeigt . Im Diagrammfenster können mehrere Diagramme gleichzeitig vorhanden sein, aber nur eines davon kann aktiv sein. Zum Beispiel in Abb. 11 ist das Bereitstellungsdiagramm aktiv, obwohl andere Diagramme verfügbar sind. Das Umschalten zwischen den Diagrammen kann durch Auswahl der gewünschten Ansicht in der Standardsymbolleiste oder über den Menüpunkt Fenster erfolgen. Beim Aktivieren eines separaten Diagrammtyps ändert sich das Aussehen einer speziellen Symbolleiste, die an einen bestimmten Diagrammtyp angepasst ist.

Abbildung - 11. Das Aussehen 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 -> Dokumentation aktiviert werden und erscheint dann unterhalb des Browsers (Abb. 12).

Das Dokumentationsfenster dient, wie der Name schon sagt, zur Dokumentation der Elemente der Modellansicht. Sie können eine Vielzahl von Informationen hineinschreiben, und das, 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 aktiviert, die sich auf ein separates ausgewähltes Element des Diagramms beziehen. In diesem Fall können Sie ein Element entweder im Browserfenster oder im Diagrammfenster auswählen. Wenn dem Diagramm ein neues Element hinzugefügt wird (zB eine Klasse), wird automatisch dessen Dokumentation generiert, die leer ist (keine Dokumentation). Anschließend führt der Entwickler selbstständig die notwendigen erklärenden Informationen ein, die sich während der Projektarbeit merken und ändern können.

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

Abbildung - 12. Erscheinungsbild des Dokumentationsfensters

Log-Fenster

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

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

Abbildung - 13. Aussehen des Protokollfensters

Fazit

& nbsp & nbsp & nbsp & nbsp Die UML wird mit der Zeit 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 operiert im Kern jeder der Spezialisten mit Modellkonzepten in seinem Wissensgebiet. Und genau dieser Modellaspekt lässt sich mit der UML-Sprache spezifizieren.

& nbsp & nbsp & nbsp & nbsp In diesem Zusammenhang nimmt die Bedeutung der UML-Sprache deutlich zu, da sie zunehmend die Merkmale einer Wissensrepräsentationssprache annimmt. Gleichzeitig ermöglicht das Vorhandensein bildlicher Mittel zur Darstellung der Struktur und des Verhaltens eines Modells in der UML eine adäquate Darstellung deklarativen und prozeduralen Wissens und nicht weniger wichtig eine semantische Korrespondenz zwischen diesen Formen von Wissen. All diese Merkmale der UML lassen den Schluss zu, dass sie in naher Zukunft die ernsthaftesten Aussichten hat.

Dieser Artikel untersucht die neue Ära der Softwareentwicklung, ihre Auswirkungen auf die neuen Anforderungen an die UML und die Best Practices zu deren Erfüllung.
& nbsp 7. "Datenmodellierung in Rational Rose" Sergey Trofimov Beschreibt die Modellierung der physikalischen Datendarstellung mit Rational Rose
& nbsp 8. Die UML-Sprache. Allgemeines Verständnis der UML-Sprache: Strukturen, grafische Elemente und Diagramme der Sprache.
& nbsp 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. Geschichte der UML
& nbsp 11. UML ist eine einheitliche Modellierungssprache. Dieses Material enthält erste Informationen über die Methoden zur Beschreibung von Softwaresystemen und Notationen, die in der UML verwendet werden.
& nbsp 12. Die UML-Sprache. Benutzerhandbuch. Von Grady Booch, James Rambeau, Ivar Jacobson
& nbsp 13. "UML-Diagramme in Rational Rose" Sergey Trofimov
& nbsp 14. "Analyse und Design. Visuelle Modellierung (UML) Rational Rose" Konstantin Domolego
& nbsp 15. Bibliothek von Gennadi Vernikov. Vollständige Beschreibungen der Design- und Modellierungsstandards.
& nbsp 16. "Ein Beispiel für die Beschreibung eines Themenbereichs unter Verwendung von UML in der Entwicklung von Softwaresystemen" Ye.B. Zolotukhina, R. V. Alfimov. Der Artikel zeigt ein konkretes Beispiel für einen möglichen Ansatz zur Domänenmodellierung basierend auf der Verwendung der Unified Modeling Language (UML).

& nbsp & nbsp & nbsp & nbsp

11.1. Struktur der Unified Modeling Language

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 von Grady Booch und James Rambeau von Rational Software. Im Herbst 1995 schloss sich Ivar Jacobson ihnen an, und im Oktober desselben Jahres wurde eine vorläufige Version 0.8 der Unified Method veröffentlicht. Seitdem sind mehrere Versionen der UML-Spezifikation erschienen, von denen zwei den Status eines internationalen Standards haben:

UML 1.4.2 - "ISO / IEC 19501: 2005. Informationstechnologie. Offene verteilte Verarbeitung. Unified Modeling Language (UML). Version 1.4.2" (eng. "Informationstechnologie. Offene verteilte Verarbeitung. Unified Modeling Language (UML). Version 1.4.2");

UML 2.4.1 - "ISO / IEC 19505-1: 2012. Informationstechnologie. OMG UML. Teil 1. Infrastruktur" (eng. "Informationstechnologie - Object Management Group Unified Modeling Language (OMG UML) - Teil 1: Infrastruktur") und" ISO / IEC 19505-2: 2012. Informationstechnologie. Unified Object Management Group Modeling Language (OMG UML). Teil 2. Überbau "(eng." Informationstechnologie - Object Management Group Unified Modeling Language (OMG UML) - Teil 2 : Überbau").

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

Der allgemeine Aufbau der UML ist in der folgenden Abbildung dargestellt.

Reis. 11.1. UML-Struktur

11.2. UML-Semantik und -Syntax

Semantik - eine Sektion der Linguistik, die die Bedeutung von Spracheinheiten untersucht, hauptsächlich ihre Wörter und Wendungen.

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

So definieren Semantik und Syntax, wie auf die UML angewendet, einen Präsentationsstil (Modellbildung), der natürliche und formale Sprachen kombiniert, um grundlegende Konzepte (Modellelemente) und Mechanismen zu 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 konzeptionelles oder physisches Objekt widerspiegelt;

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

Erklärend (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)
Struktur	(Klasse)		Viele Objekte mit einer gemeinsamen Struktur und Verhalten
	(Objekt)		Eine Abstraktion einer realen oder imaginären Entität mit klar definierten konzeptionellen Grenzen, Individualität (Identität), Zustand und Verhalten. Aus UML-Sicht sind Objekte Klasseninstanzen (Entitätsinstanzen)
	(Darsteller)	Ingenieur Wegedienste	Eine systemexterne Entität, die mit dem System interagiert und seine Funktionalität nutzt, um bestimmte Ziele zu erreichen oder bestimmte Probleme zu lösen. Somit ist der Akteur eine externe Quelle oder ein Empfänger von Informationen.
	(Anwendungsfall)		Beschreibung der vom System durchgeführten Aktionen, die zu einem für den Akteur bedeutsamen Ergebnis führen
	(Zustand)		Beschreibung des Moments im Leben eines Wesens, in dem es eine bestimmte Bedingung erfüllt, eine Aktivität ausführt oder auf das Eintreten eines Ereignisses wartet
	Zusammenarbeit (Zusammenarbeit)		Beschreibung einer Menge von Instanzen von Akteuren, Objekten und ihrer Interaktion im Prozess der Lösung eines bestimmten Problems
	(Komponente)		Der physische Teil des Systems (Datei), einschließlich der Systemmodule, die die Implementierung eines konsistenten Satzes von Schnittstellen ermöglichen
	(Schnittstelle)	iBerechnung	Ein Satz von Operationen, der einen Dienst (Satz von Diensten) definiert, 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
	(unterbrechbarer Aktivitätsbereich)		Eine Gruppe von Vorgängen, deren normaler Ablauf aufgrund einer nicht standardmäßigen Situation unterbrochen werden kann
Erklären	Notiz (Kommentar)		Artikelkommentar. Wird mit einer gestrichelten Linie an das kommentierte Element angehängt

In einigen Quellen, insbesondere [,], werden auch Verhaltensentitäten unterschieden Interaktionen und endliche Automaten, aber aus logischer Sicht sind sie als Diagramme einzuordnen.

Einige der oben genannten Entitäten werden implizit in Zerlegungsdiagrammen detailliert beschrieben. 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 Beziehung UML, die in Diagrammen verwendet wird, um Beziehungen zwischen Entitäten anzuzeigen.

Tabelle 11.3. Beziehung

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 Untertyp der Assoziation, der die Beziehung "Teil" - "Ganzes" beschreibt, wobei 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		Eine Unterart der Aggregation, bei der "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 Zustand 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 Seite der Eltern angegeben. Die Beziehung wird nur zwischen Entitäten desselben Typs angezeigt
Realisierung		Eine Beziehung zwischen Entitäten, wobei eine Entität eine Aktion definiert, zu deren Durchführung die andere Entität verpflichtet. 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 Komposition, 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 angegeben. Die Multiplizität kann wie folgt angegeben werden:

- * - beliebig viele Kopien, auch keine;

Nicht-negative ganze Zahl - die Multiplizität ist streng festgelegt und gleich 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 abschließenden "ersten Zahl .. *" (zB: 1 ​​.. *, 5 .. * oder 0 .. *);

Aufzählung von nicht-negativen ganzen Zahlen und durch Kommas getrennten Bereichen (zB: 1, 3..5, 10, 15 .. *).

Wenn die Multiplizität nicht angegeben ist, wird ihr Wert mit 1 angenommen. Die Multiplizität der an der Abhängigkeit, Generalisierung und Implementierung beteiligten Entitätsinstanzen wird immer mit 1 angenommen.

Die folgende Tabelle beschreibt Mechanismen zur Erweiterung verwendet, um die Semantik von Entitäten und Beziehungen zu klären. Im Allgemeinen ist der Erweiterungsmechanismus eine Textkette, die in Klammern oder Anführungszeichen eingeschlossen ist.

Tabelle 11.4. Erweiterungsmechanismen

Name	Bezeichnung	Definition (Semantik)
Stereotyp (Stereotyp)	« »	Eine Bezeichnung, die die Semantik eines Notationselements angibt (Beispiel: Eine Abhängigkeit mit dem Stereotyp "include" wird als Inklusionsrelation betrachtet, und eine Klasse mit dem Stereotyp "Boundary" ist eine Boundary-Klasse)
Wachzustand (Wächterzustand)		Boolesche Bedingung (zum Beispiel: oder [Identifikation abgeschlossen])
Einschränkung (Zwang)	{ }	Regel, die die Semantik des Modellelements einschränkt (z. B. (Ausführungszeit weniger als 10 ms))
Getaggter Wert (getaggter Wert)	{ }	Neue oder qualifizierende Eigenschaft eines Notationselements (zum Beispiel: (Version = 3.2))

Neben Stereotypen, die als Textkette in Anführungszeichen angegeben sind, können in Diagrammen auch grafische Stereotypen verwendet werden. Die folgende Abbildung zeigt Beispiele für Standard- und Stereotyp-Anzeigen.

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

Reis. 11.2. Beispiele für Standard- und Stereotyp-Klassenanzeige

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

Tabelle 11.5. Diagramme

Diagramm			Termin
				nach dem Grad der physikalischen Verwirklichung	durch Anzeige von Dynamik	nach angezeigtem Aspekt
(Anwendungsfall)			Zeigt Systemfunktionen, Interaktion zwischen Akteuren und Funktionen an	Logisch	Statisch	Funktional
(Klasse)			Zeigt eine Reihe von Klassen, Schnittstellen und Beziehungen zwischen ihnen an	Logisch oder körperlich	Statisch	Funktional und informativ
(Paket)			Zeigt eine Reihe von Paketen und die Beziehung zwischen ihnen an	Logisch oder körperlich	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 von Verhaltensalgorithmen)
	Interaktionen (Interaktion)	(Reihenfolge)	Zeigt die Reihenfolge der Weitergabe von Nachrichten zwischen Objekten und Akteuren an
		(Kommunikation)	Ähnlich einem Sequenzdiagramm, jedoch liegt der Schwerpunkt auf der Struktur der Interaktionen zwischen Objekten
Implementierung (Implementierung)	(Komponente)		Zeigt Systemkomponenten (Programme, Bibliotheken, Tabellen usw.) und Verknüpfungen zwischen ihnen an	Physisch	Statisch	Komponente
	(Einsatz)		Zeigt die Platzierung von Komponenten nach Hosts sowie deren Konfiguration an

Der UML 2.x-Standard definiert auch zusätzliche, hochspezialisierte Diagramme:

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

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

Verbundstrukturdiagramm – 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 handelt sich um einen kontextuellen (konzeptuellen), dessen Elemente in separaten Zerlegungsdiagrammen konkretisiert werden.

Zum Zwecke einer erweiterten konzeptionellen Darstellung der internen Architektur des Systems erlaubt der Großteil der Konstruktion die Verwendung etablierter grafischer Stereotypen für die sog. Ein solches Diagramm wird als 1 bezeichnet, gehört aber nicht zur Liste der Diagramme, die vom UML-Standard definiert werden.

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. Diagramme und sind beispielsweise austauschbar, sie werden nur für Objekte mit komplexem Verhalten erstellt. Die folgende Tabelle enthält eine Orientierungshilfe für die Notwendigkeit, Diagramme nach Systemmodell zu entwickeln (zu verfeinern).

Tabelle 11.6. Verknüpfen von Modellen und Diagrammen

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

Ein Teil der Diagramme bedarf nach ihrer Erstellung einer Weiterentwicklung und Verfeinerung im Rahmen der Entwicklung des nächsten Modells (technologischer Prozess). So sollte beispielsweise während der Entwicklung geklärt werden. Bei Modellen.

4. Geben Sie dem Begriff "" eine Definition.

UML ist ein Akronym für Unified Modeling Language. Tatsächlich ist es eine der beliebtesten Techniken zur Modellierung von Geschäftsprozessen und eine internationale Standardnotation zum Spezifizieren, Visualisieren und Dokumentieren der Softwareentwicklung. Von der Object Management Group definiert, aus mehreren zusätzlichen UML-Notationssystemen hervorgegangen und mittlerweile zum De-facto-Standard für die visuelle Modellierung geworden. Das Grundprinzip jeder objektorientierten Programmierung beginnt mit der Erstellung eines Modells.

Die UML entstand aus dem Chaos rund um Softwareentwicklung und Dokumentation. In den 1990er Jahren gab es verschiedene Darstellungsformen von Softwaresystemen. Es bestand ein Bedarf an einer einheitlicheren visuellen UML-Darstellung dieser Systeme und wurde in den Jahren 1994-1996 von drei bei Rational Software arbeitenden Softwareingenieuren entwickelt. Es wurde später 1997 als Standard übernommen und bleibt es mit nur wenigen Aktualisierungen.

Grundsätzlich ist UML eine universelle Modellierungssprache im Bereich der Softwareentwicklung. Es spiegelt sich jedoch mittlerweile in der Dokumentation mehrerer Geschäfts- oder Workflow-Prozesse wider, beispielsweise in Aktivitätsdiagrammen. Diagramme vom Typ UML können als Ersatz für Flussdiagramme verwendet werden. Sie bieten sowohl eine standardisiertere Methode zur Modellierung von Arbeitsabläufen als auch eine breite Palette von Funktionen zur Verbesserung der Lesbarkeit und Effizienz.

Die Architektur basiert auf einem Metaobjekt, das die Grundlage für die Erstellung der UML definiert. Es ist genau genug, um eine gesamte Anwendung zu erstellen. Vollständig ausführbare UML kann auf mehreren Plattformen unter Verwendung verschiedener Technologien mit allen Prozessen während des gesamten Softwareentwicklungszyklus bereitgestellt werden.

UML ist für die Entwicklung einer visuellen Modellierungssprache durch Benutzer gedacht. Es unterstützt übergeordnete Designkonzepte wie Strukturen, Vorlagen und Zusammenarbeit. UML ist eine Sammlung von Elementen wie:

1. Anweisungen in der Programmiersprache.
2. Akteure - beschreiben die Rolle des Benutzers oder eines anderen Systems, das mit dem Objekt interagiert.
3. Tätigkeiten, die für die Ausführung des Werkvertrags durchzuführen und in Diagrammen dargestellt werden.
4. Ein Geschäftsprozess, der eine Reihe von Aufgaben umfasst, die einen bestimmten Service für Kunden erstellen, visualisiert durch ein Flussdiagramm sequenzieller Aktionen.
5. Logische und wiederverwendbare Softwarekomponenten.

UML-Diagramme fallen in zwei Kategorien. Der erste Typ umfasst sieben Diagrammtypen, die strukturelle Informationen darstellen, der zweite umfasst die anderen sieben, die allgemeine Verhaltenstypen darstellen. Diese Diagramme dienen der Dokumentation der Architektur von Systemen und sind direkt in die UML-Systemmodellierung eingebunden.

UML-Diagramme werden als statische und dynamische Ansichten des Systemmodells dargestellt. Die statische Ansicht enthält Klassen- und Verbundstrukturdiagramme, die die statische Struktur hervorheben. Eine dynamische Ansicht stellt die Interaktion zwischen Objekten und Änderungen der internen Zustände von Objekten mithilfe von Sequenz-, Aktivitäts- und Zustandsdiagrammen dar.

Zur Vereinfachung der Modellierung steht eine Vielzahl von UML-Modellierungstools zur Verfügung, darunter IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner und Dia.

UML wird auf unterschiedliche Weise verwendet, sowohl in der Dokumentation zur Softwareentwicklung als auch in Geschäftsprozessen:

1. Skizzieren. In diesem Fall werden UML-Diagramme verwendet, um verschiedene Aspekte und Eigenschaften des Systems zu vermitteln. Dies ist jedoch nur eine Top-Level-Ansicht des Systems und wird wahrscheinlich nicht alle notwendigen Details enthalten, um das Projekt bis zum Ende durchzuführen.
2. Forward Design - Das Design der Skizze erfolgt vor der Codierung der Anwendung. Dies soll einen besseren Überblick über das System oder den Workflow bieten, den der Benutzer zu erstellen versucht. Viele Konstruktionsprobleme oder -fehler können identifiziert werden, was die allgemeine Gesundheit und das Wohlbefinden des Projekts verbessert.
3. Umgekehrtes Design. Sobald der Code geschrieben ist, erscheinen UML-Diagramme als eine Form der Dokumentation für verschiedene Aktivitäten, Rollen, Teilnehmer und Arbeitsabläufe.
4. Entwurf. In diesem Fall dient das Diagramm als vollständige Konstruktion, die nur die eigentliche Implementierung des Systems oder der Software erfordert. Dies geschieht häufig mit CASE-Tools (Computer Aided Software Engineering Tools). Der Hauptnachteil der Verwendung von CASE-Tools besteht darin, dass sie ein gewisses Maß an Wissen, Benutzerschulung sowie Management und Personal erfordern.

UML ist keine eigenständige Programmiersprache wie Java, C++ oder Python, kann aber mit den richtigen Tools zu einer Pseudo-UML werden. Um dieses Ziel zu erreichen, muss das Gesamtsystem in verschiedenen Diagrammen dokumentiert werden und mit der richtigen Software können die Diagramme direkt in Code übersetzt werden. Diese Technik kann nur nützlich sein, wenn das Zeichnen der Diagramme weniger Zeit in Anspruch nimmt als das Schreiben des eigentlichen Codes. Obwohl die UML für die Systemmodellierung entwickelt wurde, hat sie mehrere Anwendungen in Geschäftsbereichen gefunden.

Es folgt ein Beispiel-UML-Diagramm für die Geschäftsmodellierung.

Eine praktische Lösung wäre, den Prozessablauf für den Telesales durch ein Aktivitätsdiagramm zu visualisieren. Von dem Moment an, in dem die Bestellung als Eingabe aufgenommen wird, bis zu dem Moment, an dem die Bestellung abgeschlossen ist und eine bestimmte Ausgabe erfolgt.

Es gibt verschiedene Arten von UML-Diagrammen, und jedes erfüllt eine andere Aufgabe, unabhängig davon, ob es vor oder nach der Implementierung als Teil der Dokumentation entwickelt wird. Die beiden breitesten Kategorien, die alle anderen Typen umfassen, sind Verhaltensdiagramme und Strukturdiagramme. Wie der Name schon sagt, versuchen einige UML-Diagramme die Struktur eines Systems oder Prozesses zu analysieren und darzustellen, während andere das Verhalten eines Systems, seiner Teilnehmer und Komponenten beschreiben.

Die verschiedenen Typen unterteilen sich wie folgt:

1. Nicht alle der 14 verschiedenen Arten von UML-Diagrammen werden regelmäßig bei der Dokumentation von Systemen und Architekturen verwendet.
2. Auch bei der Verwendung von UML-Diagrammen gilt das Pareto-Prinzip.
3. 20 % der Diagramme werden 80 % der Zeit von Entwicklern verwendet.

Die am häufigsten verwendeten Elemente in der Softwareentwicklung sind:

• Nutzungsdiagramme;
• Klassendiagramme;
• Reihenfolge.

Aktionsdiagramme sind die wichtigsten UML-Diagramme zur Erstellung von Geschäftsprozessmodellen. In der Softwareentwicklung werden sie verwendet, um den Ablauf verschiedener Aktionen zu beschreiben. Sie können entweder sequentiell oder parallel sein. Sie beschreiben Gegenstände, die als Ergebnis von Aktivitäten verwendet, konsumiert oder produziert werden, und die Beziehung zwischen verschiedenen Aktivitäten.

All dies ist wichtig für die Modellierung von Geschäftsprozessen, die von einem zum anderen führen, da sie mit einem klaren Anfang und Ende verbunden sind. In einer Geschäftsumgebung wird dies auch als Geschäftsprozessabbildung bezeichnet. Die Hauptakteure sind Autor, Herausgeber und Herausgeber. Beispiele für UML umfassen die folgenden. Wenn ein Gutachter den Entwurf überprüft und beschließt, dass einige Änderungen vorgenommen werden müssen. Der Autor überarbeitet dann den Entwurf und gibt ihn erneut zurück, um die Übersicht zu analysieren.

Nutzungsdiagramm

Eckpfeiler des Systems - wird verwendet, um die Anforderungen für die Ebene des Systems zu analysieren. Diese Anforderungen werden in verschiedenen Anwendungsfällen ausgedrückt. Die drei Hauptkomponenten eines UML-Diagramms sind:

1. Funktional – präsentiert als Anwendungsfälle.
2. Ein Verb, das eine Handlung beschreibt.
3. Akteure - um mit dem System zu interagieren. Der Akteur kann Benutzer, Organisationen oder eine externe Anwendung sein. Die Beziehung zwischen den Teilnehmern wird durch gerade Pfeile dargestellt.

Zum Beispiel für ein Bestandskontrolldiagramm. In diesem Fall gibt es einen Eigentümer, einen Lieferanten, einen Manager, einen Lagerspezialisten und einen Lagerprüfer. Die runden Container stellen die Aktionen dar, die die Akteure ausführen. Mögliche Aktionen sind das Kaufen und Bezahlen von Aktien, die Überprüfung der Qualität der Aktien, die Rückgabe von Aktien oder deren Verteilung.

Diese Art von Diagramm ist gut geeignet, um dynamisches Verhalten zwischen Teilnehmern eines Systems darzustellen und seine Darstellung zu vereinfachen, ohne Implementierungsdetails widerzuspiegeln.

Vorübergehend

UML-Zeitdiagramme werden verwendet, um Objektbeziehungen darzustellen, wenn der Fokus zeitabhängig ist. Dabei ist es nicht interessant, wie Objekte interagieren oder sich gegenseitig verändern, sondern der Benutzer möchte sich vorstellen, wie Objekte und Subjekte entlang einer linearen Zeitachse agieren.

Jeder einzelne Teilnehmer wird durch eine Lebenslinie repräsentiert, die im Wesentlichen eine Linie ist, die die Stufen bildet, während sich der einzelne Teilnehmer von einer Stufe zur nächsten bewegt. Der Fokus liegt dabei auf der Dauer der Ereignisse und den davon abhängigen Veränderungen.

Die Hauptkomponenten eines Zeitdiagramms sind:

1. Lifeline ist ein Einzelmitglied.
2. State Timeline - Ein einzelner Lebenspfad kann verschiedene Zustände innerhalb eines Prozesses durchlaufen.
3. Dauerbeschränkung – Eine Zeitintervallbeschränkung, die die Dauer darstellt, die erforderlich ist, damit die Beschränkung erfüllt wird.
4. Zeitlimit - Begrenzen Sie das Zeitintervall, in dem der Teilnehmer etwas tun muss.
5. Zerstörungserscheinung - Das Erscheinen einer Nachricht, die einen einzelnen Teilnehmer zerstört und das Ende des Lebenszyklus dieses Teilnehmers darstellt.

Horizontale Diagramme, auch Zustandsdiagramme genannt, werden verwendet, um die verschiedenen Zustände einer Komponente innerhalb eines Systems zu beschreiben. Es braucht ein endgültiges Namensformat, da ein Diagramm im Wesentlichen eine Maschine ist, die mehrere Zustände eines Objekts beschreibt und wie es sich basierend auf internen und externen Ereignissen ändert.

Ein sehr einfaches Maschinenzustandsdiagramm wäre in einem Schachspiel. Ein typisches Schachspiel besteht aus Zügen von Weiß und Zügen von Schwarz. Weiß hat den ersten Zug, der damit das Spiel einleitet. Das Spielende kann unabhängig davon erfolgen, ob Weiß oder Schwarz gewinnt. Das Spiel kann in einem Match, Rücktritt oder Unentschieden enden (unterschiedliche Maschinenzustände). Statecharts werden hauptsächlich im Vorwärts- und Rückwärts-UML-Design verschiedener Systeme verwendet.

Aufeinanderfolgenden

Diese Art von Diagramm ist das wichtigste UML-Diagramm nicht nur in der Informatik-Community, sondern auch als Design-Schichtenmodell für die Entwicklung von Geschäftsanwendungen. Sie werden aufgrund ihres visuell selbsterklärenden Charakters gerne zur Beschreibung von Geschäftsprozessen verwendet. Wie der Name schon sagt, beschreiben Diagramme die Abfolge von Nachrichten und Interaktionen, die zwischen Subjekten und Objekten auftreten. Akteure oder Objekte können nur dann aktiv sein, wenn sie gebraucht werden oder wenn ein anderes Objekt mit ihnen kommunizieren möchte. Alle Mitteilungen werden in chronologischer Reihenfolge dargestellt.

Weitere Informationen finden Sie im folgenden Beispiel für ein UML-Sequenzdiagramm.

Wie das Beispiel zeigt, werden Strukturdiagramme verwendet, um den Aufbau einer Anlage darzustellen. Genauer gesagt wird eine Sprache in der Softwareentwicklung verwendet, um die Architektur eines Systems darzustellen und wie verschiedene Komponenten miteinander verbunden sind.

Das UML-Klassendiagramm ist der gebräuchlichste Diagrammtyp für die Softwaredokumentation. Da die meisten derzeit geschriebenen Programme noch auf dem objektorientierten Programmierparadigma basieren, ist es sinnvoll, Klassendiagramme zur Dokumentation von Software zu verwenden. Dies liegt daran, dass OOP auf UML-Klassen und den Beziehungen zwischen ihnen basiert. Kurz gesagt enthalten Diagramme Klassen mit ihren Attributen, auch Datenfelder genannt, und ihrem Verhalten, den sogenannten Memberfunktionen.

Genauer gesagt hat jede Klasse 3 Felder: Name oben, Attribute direkt unter dem Namen, Operationen / Verhalten unten. Die Beziehung zwischen den verschiedenen Klassen (dargestellt durch die Verbindungslinie) bildet ein Klassendiagramm. Das obige Beispiel zeigt ein einfaches Klassendiagramm.

Objekte

Wenn Sie UML-Strukturdiagramme besprechen, müssen Sie tiefer in die Konzepte der Informatik eintauchen. In der Softwareentwicklung werden Klassen als abstrakte Datentypen betrachtet, während Objekte als Instanzen gelten. Wenn es beispielsweise „Car“ gibt, das ein allgemeiner abstrakter Typ ist, dann wäre eine Instanz der „Car“-Klasse „Audi“.

UML-Objektdiagramme helfen Softwareentwicklern zu überprüfen, ob die generierte abstrakte Struktur in der Praxis, also bei der Erstellung von Objekten, eine tragfähige Struktur ist. Einige Entwickler betrachten dies als eine sekundäre Ebene der Genauigkeitsüberprüfung. Es zeigt Instanzen von Klassen an. Genauer gesagt hat die generische Klasse "Kunde" jetzt einen tatsächlichen Kunden, beispielsweise "James". James ist eine Instanz einer allgemeineren Klasse und hat die gleichen Attribute, jedoch mit den angegebenen Werten. Das gleiche wurde mit dem Konten- und Sparkonto gemacht. Sie sind beide Objekte ihrer jeweiligen Klassen.

Einsatz

Deployment-Diagramme werden verwendet, um die Beziehung zwischen Software und Hardware zu visualisieren. Genauer gesagt können Sie mit Bereitstellungsdiagrammen ein physisches Modell erstellen, wie Softwarekomponenten (Artefakte) auf Hardwarekomponenten, den sogenannten Knoten, bereitgestellt werden.

Ein typisches vereinfachtes Bereitstellungsmuster für eine Webanwendung wäre:

1. Knoten (Anwendungsserver und Datenbankserver).
2. Artefakte-Client-Anwendungsschema und -Datenbank.

Das Paketdiagramm ähnelt den Makros für die oben erläuterten UML-Bereitstellungsdiagramme. Verschiedene Pakete enthalten Knoten und Artefakte. Sie gruppieren Diagramme und Modellkomponenten in Gruppen, ähnlich wie ein Namespace verschiedene Namen einkapselt, die in gewisser Weise miteinander verbunden sind. Letztlich kann ein Paket auch von mehreren anderen Paketen erstellt werden, um komplexere Systeme und Verhaltensweisen darzustellen.

Der Hauptzweck eines Paketdiagramms besteht darin, die Beziehungen zwischen den verschiedenen Hauptkomponenten zu zeigen, aus denen ein komplexes System besteht. Programmierer empfinden diese Abstraktionsfunktion als einen guten Vorteil für die Verwendung von Paketdiagrammen, insbesondere wenn Details aus dem Bild weggelassen werden können.

Wie bei jeder anderen Sache im Leben braucht es die richtigen Werkzeuge, um etwas richtig zu machen. Um Software, Prozesse oder Systeme zu dokumentieren, verwenden Sie Tools, die UML-Annotationen und Diagrammvorlagen bieten. Es gibt verschiedene Software-Dokumentationstools, die Ihnen beim Zeichnen eines Diagramms helfen können.

Sie fallen normalerweise in die folgenden Hauptkategorien:

1. Papier und Stift sind einfach. Sie nehmen Papier und Stift, öffnen den UML-Syntaxcode aus dem Internet und zeichnen jede Art von Diagramm, die benötigt wird.
2. Online-Tools - Es gibt mehrere Online-Anwendungen, mit denen Sie Ihr Diagramm erstellen können. Die meisten von ihnen bieten ein kostenpflichtiges Abonnement oder eine begrenzte Anzahl von kostenlosen Charts an.
3. Kostenlose Online-Tools sind fast dieselben wie kostenpflichtige. Der Hauptunterschied besteht darin, dass die kostenpflichtigen auch Tutorials und vorgefertigte Vorlagen für bestimmte Diagramme anbieten.
4. Eine Desktopanwendung ist eine typische Desktopanwendung für Diagramme, und fast jedes andere Diagramm ist Microsoft Visio. Es bietet erweiterte Funktionen und Funktionen. Der einzige Nachteil ist, dass Sie dafür bezahlen müssen.

Damit ist klar, dass die UML ein wichtiger Aspekt bei der Entwicklung objektorientierter Software ist. Es verwendet grafische Notation, um visuelle Modelle von Systemprogrammen zu erstellen.

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 sowohl von einem anderen als auch von einem Softwaretool, das die UML interpretiert, eindeutig verstanden werden kann. Daraus folgt insbesondere, dass ein in UML präsentiertes PS-Modell automatisch in eine OO-Programmiersprache (wie Java, C++, VisualBasic) übersetzt werden kann, d. h. wenn es ein gutes visuelles Modellierungswerkzeug gibt, das UML unterstützt , Modellbau , erhalten wir eine diesem Modell entsprechende Vorbereitung des Programmcodes.

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

UML-Vokabular

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

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

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

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

Diagramme. Die UML bietet die folgenden Diagramme:

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

Ansicht der Modellsteuerung. Pakete.

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

Was die UML bietet.

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

Und der letzte ...

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

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

Aktionsplan

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

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

Hinweise (Beschreibung)

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

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

Wie man die Kreativitätstechnik anwendet

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

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

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

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

Wie lernt man

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

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

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

Anwendungsbeispiel

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

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

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

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

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

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

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

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

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

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

Interne Aktivitäten im Statechart

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

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

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

Die Aktivitätszustände im Statechart

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

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

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

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

Superstaaten

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

Parallele Zustände

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

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

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

Zustandsdiagramme implementieren

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

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

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

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

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

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

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

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