Von der Prozessmodellierung bis zum Entwurf eines automatisierten Systems (Teil 2)

"Ein Tag im Leben eines Eichhörnchens" oder von Modellierungsprozessen bis zum Entwurf eines automatisierten Systems zur Berücksichtigung von Materialwerten "Eichhörnchen-1.0" (Teil 2)

Die Illustration für A. S. Puschkins Geschichte von Zar Saltan wurde verwendet, veröffentlicht von Children's Literature, Moskau, 1949, Leningrad, Zeichnungen von K. Kuznetsov

Zusammenfassung der vorherigen Serie

Im ersten Teil haben wir einen Themenbereich „Märchen“ verwendet, der von Beispielen für die Untersuchung von UML-Diagrammen auf der Grundlage von Märchenplots inspiriert wurde (siehe zum Beispiel hier [1]). Vor Beginn der Modellierung haben wir uns auf die Verwendung einiger Elemente des Aktivitätsdiagramms geeinigt und begonnen, eine Modellierungsvereinbarung zu formulieren. Basierend auf diesen Vereinbarungen haben wir in der ersten Phase den Prozess in Form von Aktivitätsdiagrammen beschrieben und in der zweiten Phase die Prozessschritte identifiziert, für die eine Automatisierung erforderlich (und möglich) ist.

Ich möchte Sie daran erinnern, dass wir die Abrechnung von Materialwerten, die in diesen Prozessen entstehen, automatisieren werden.

...
Die Insel liegt am Meer (E1, E2)
Stadt auf der Insel steht (E3, E1)
Mit Kirchen mit goldenen Kuppeln (E4)
Mit Türmen und Gärten; (E5, E6)
Fichte wächst vor dem Palast (E7, E8)
Und darunter ist ein Kristallhaus; (E9)
Das Eichhörnchen lebt dort manuell (A1)
Was für ein Entertainer! (A1)
Eichhörnchen singt Lieder, (P1, A1)
Ja, Nüsse nagen an allem, (P2)
Und die Nüsse sind nicht einfach, (C1)
Alle Muscheln sind golden, (C2)
Die Kerne sind reiner Smaragd; (C3)
Diener bewachen das Eichhörnchen (P3, A2)
Sie dienen ihr als eine andere Dienerin (P4)
Und der Angestellte wurde bestellt (A3)
Strenge Darstellung von Nüssen; (P5, C1)
Begrüßt ihre Armee; (P6, A4)
Aus einer Muschel eine Münze gießen (P7, C2, C4)
Ja, schwebe um die Welt; (P8)
Mädchen gießen Smaragd (P9, A5, C3)
In den Vorratskammern, aber im Hintergrund; (E10, E11)
...
(A.S. Puschkin "Die Geschichte von Zar Saltan, von seinem glorreichen und mächtigen Helden Prinz Gvidon Saltanovich und von der schönen Prinzessin Swans", wie man glaubt, eine freie Behandlung der Volksgeschichte "Knietief in Gold, Ellbogen seiner Hand in Silber". die von Puschkin auf verschiedene Weise aufgenommen wurde )

In diesem Beispiel verwende ich die Enterprise Architect-Umgebung der australischen Firma Sparx Systems [2] und im Rahmen der Schulungssitzung Modelio [3].
Ich möchte Sie daran erinnern, dass die Prozesse unterschiedlich sind. Sie können sich beispielsweise hier [4] und hier [5] kennenlernen.
Weitere Informationen zu den angewandten Ansätzen zum Modellieren und Entwerfen finden Sie in [6, 7].
Die vollständige UML-Spezifikation finden Sie hier [8].

Jetzt können wir mit den nächsten Schritten fortfahren und mit dem Entwurf der Funktionen des Systems und seiner internen Organisation beginnen. Die Nummerierung der Figuren wird fortgesetzt.

Stufe 3. Der automatisierte Schritt muss mit der Funktion oder den Funktionen des Systems übereinstimmen

Das entwickelte automatisierte System (AS) ist so konzipiert, dass Nüsse streng aufgezeichnet werden. Für jeden ausgewählten Schritt (siehe Abbildung 3, Abbildung 4 im 1. Teil ), den wir automatisieren werden, schreiben wir die funktionalen Anforderungen auf, wobei wir ungefähr die folgende Konstruktion anwenden: „Das System muss die Möglichkeit haben, implementiert zu werden ...“ und das Anwendungsfalldiagramm entwickeln. Jetzt ergänzen wir unsere Modellierungsvereinbarung tatsächlich um neue Regeln. Lassen Sie mich erklären, welche Elemente wir verwenden werden.

Zwischen der „Benutzerrolle“ und der „Funktion“ verwenden wir die Zuordnungszuordnung (Abbildung 5). Dies bedeutet, dass für einen Benutzer mit dieser Rolle die Ausführung dieser Funktion verfügbar ist.

Abbildung 5. Verwenden der Zuordnungstypkommunikation

Von der "Funktion" zur "Anforderung" zeichnen wir die Verbindung "Implementierung" (6), um zu zeigen, dass diese Anforderung durch diese Funktionen implementiert wird. Die Beziehung kann "viele zu viele" sein, d. H. Eine Funktion kann an der Implementierung mehrerer Anforderungen beteiligt sein, und es kann mehr als eine Funktion erforderlich sein, um eine Anforderung zu implementieren.

Abbildung 6. Verwenden einer Beziehung vom Typ "Implementierung"

Wenn eine Funktion für ihre Ausführung die Ausführung einer anderen Funktion erfordert und dies erforderlich ist, verwenden wir die Beziehung „Abhängigkeit“ mit dem Stereotyp „Einschließen“ - Einschluss (Abbildung 7). Wenn die Ausführung einer zusätzlichen Funktion unter bestimmten Bedingungen erforderlich ist, verwenden wir die Beziehung "Abhängigkeit" mit dem Stereotyp "Erweitern" - Erweiterung. Alles ist sehr leicht zu merken: "Einschließen" - IMMER und "Erweitern" - MANCHMAL.

Abbildung 7. Verwenden einer Beziehung vom Typ „Abhängigkeit (Einbeziehung)“

Infolgedessen sieht unser Diagramm ungefähr so ​​aus (Abbildung 8).

Abbildung 8. Anwendungsfalldiagramm (AS-Funktionsmodell)

Darüber hinaus werden anhand des Anwendungsfalldiagramms Benutzerrollen modelliert (Abbildung 9).

Abbildung 9. Anwendungsfalldiagramm (Benutzerrollen der Sprecher)

Stufe 4. Wir beschreiben die interne Organisation des AS anhand des Klassendiagramms

Unter Verwendung von Informationen zu den Eingabe- und Ausgabeartefakten unseres Prozesses (siehe Aktivitätsdiagramme - Abbildung 2, Abbildung 3, Abbildung 4) entwickeln wir ein Klassendiagramm. Wir werden die Modellierungselemente „Klasse“ und verschiedene Arten von Verbindungen zwischen ihnen verwenden.

Um die Beziehung „ganzer Teil“ zu zeigen, verwenden wir die Beziehung vom Typ „Aggregation“ (Abbildung 10): Die Nuss ist das Ganze, und die Schalen und der Kernel sind Teile.

Abbildung 10. Die Beziehung "ganzer Teil"

Infolgedessen sieht ein Fragment unseres Diagramms ungefähr so ​​aus (Abbildung 11). Die Farbe gibt die Klassen an, die wir direkt in der Textbeschreibung des Prozesses identifiziert haben.

Abbildung 11. Klassendiagramm

Das Klassendiagramm wurde auch verwendet, um andere Artefakte zu modellieren - nicht nur solche, die sich auf das konzeptionelle Modell des automatisierten Prozesses zur Berücksichtigung von Materialwerten beziehen, sondern auch auf die Laufzeitumgebung - die Umgebung (Abbildung 12) und die "benachbarten" Prozesse (Abbildung 13), die dies können um den automatisierten Prozess zu beeinflussen, stehen aber noch nicht im Fokus unserer Aufmerksamkeit (wir gehen davon aus, dass sich das System entwickeln wird und diese Informationen nützlich sein werden).

Abbildung 12. Klassendiagramm (Umgebung)

Die Vererbungsbeziehung zeigt eine Verallgemeinerung verschiedener Gebäude, "untergeordnete" Klassen, unter der verallgemeinernden "übergeordneten" Klasse "Struktur".

Abbildung 13. Klassendiagramm (zusätzliche Informationen zu Artefakten)

"Reaktion auf die Situation" hängt von "visuellen Inspektionsdaten" ab. Für mehrere Abhängigkeitsbeziehungen wird das Stereotyp "Ablaufverfolgung" verwendet, um die Ablaufverfolgung von Klassen anzuzeigen, die in der Prozessbeschreibung nicht explizit angegeben sind, aber für ihre Automatisierung erforderlich sind, zu Klassen, für die in unserer Beschreibung eine genaue Angabe vorliegt.

Stufe 5. Wir analysieren die Notizen auf dem Track "Business Rules"

Die Regeln wurden angegeben (siehe Abbildung 2 im 1. Teil ):

1. Da einer der Schritte in zwei Teile aufgeteilt werden muss, wird der zweite Teil nur unter bestimmten Bedingungen ausgeführt.
2. Ernennung zur Durchführung der Bilanzierung von Nüssen eines bestimmten Beamten;
3. technische Technik (weiße Farbe der Elemente), die angibt, dass das Element in der Prozessbeschreibung nicht explizit angegeben wurde.

Es ist zu beachten, dass wir alle diese Regeln bereits bei der Entwicklung von Diagrammen verwendet haben.

Schlussbemerkungen

Also haben wir 5 Stufen durchlaufen und 3 Arten von Diagrammen erstellt. Fügen Sie einen kleinen Kommentar zur Organisation unserer Modelle in der Modellierungsumgebung hinzu. Es gibt eine große Anzahl von Frameworks, die zur Strukturierung der in der Entwicklung befindlichen Modelle beitragen. Dies ist jedoch nicht Gegenstand dieses Artikels. Daher beschränken wir uns auf die folgenden einfachen Pakete, um unser Projekt ordnungsgemäß durchzuführen: Geschäftsprozess, Funktionsmodell, Artefakte, Teilnehmer und Umgebung (Abbildung 14).

Abbildung 14. Projektpaketstruktur

Aus diesem Grund haben wir konsistente Modelle entwickelt, die das System der Berücksichtigung von Materialwerten aus verschiedenen Blickwinkeln beschreiben: ein Modell eines automatisierten Geschäftsprozesses, ein Funktionsmodell und ein Modell der internen Organisation des Systems auf konzeptioneller Ebene.

Von der Prozessmodellierung bis zum Entwurf eines automatisierten Systems (Teil 1)