„Ein Tag im Leben eines Eichhörnchens“ oder von der Modellierung von Prozessen bis zum Entwurf eines automatisierten Systems zur Bilanzierung von Sachwerten „Belka-1.0“ (Teil 2)
Zusammenfassung der vorherigen Serie
В Wir haben eine „Märchen“-Domäne verwendet, die von Beispielen für das Studium von UML-Diagrammen basierend auf Märchenhandlungen inspiriert wurde (siehe zum Beispiel [1]). Vor der Modellierung einigten wir uns auf die Verwendung einiger Elemente des Aktivitätsdiagramms und begannen mit der Bildung einer Modellierungsvereinbarung. Unter Berücksichtigung dieser Vereinbarungen haben wir im 1. Schritt den Prozess in Form von Aktivitätsdiagrammen beschrieben und im 2. Schritt die Prozessschritte identifiziert, für die eine Automatisierung erforderlich (und möglich) ist.
Ich möchte Sie daran erinnern, dass wir die in diesen Prozessen entstehende Aktivität der Bilanzierung materieller Werte automatisieren werden.
...
Eine Insel im Meer liegt, (E1, E2)
Hagel auf den Inselständen (E3, E1)
Mit Kirchen mit goldenen Kuppeln (E4)
Mit Türmen und Gärten; (E5, E6)
Vor dem Schloss wächst Fichte (E7, E8)
Und darunter ist ein Kristallhaus; (E9)
Dort lebt das Eichhörnchen, zahm, (A1)
Ja, was für ein Entertainer! (A1)
Eichhörnchen singt Lieder, (P1, A1)
Ja, er nagt alle Nüsse, (P2)
Und Nüsse sind nicht einfach, (C1)
Alle Muscheln sind golden, (C2)
Kerne reiner Smaragd; (C3)
Diener bewachen das Eichhörnchen, (P3, A2)
Diene ihr als Diener verschiedener Art (P4)
Und ein Sachbearbeiter wurde zugewiesen (A3)
Strenge Darstellung verrückter Neuigkeiten; (P5, C1)
Verleiht ihrer Armee Ehre; (P6, A4)
Aus den Muscheln wird eine Münze gegossen, (P7, C2, C4)
Lassen Sie sie um die Welt schweben; (P8)
Mädchen werfen Smaragd (P9, A5, C3)
In Vorratskammern, aber unter dem Scheffel; (E10, E11)
...
(A.S. Puschkin „Die Geschichte vom Zaren Saltan, von seinem glorreichen und mächtigen Sohn Fürst Gwidon Saltanowitsch und der schönen Schwanenprinzessin“, )
In diesem Beispiel verwende ich die Enterprise Architect-Umgebung eines australischen Unternehmens. [2] und im Rahmen von Schulungen nutze ich [3].
Ich möchte Sie daran erinnern, dass die Prozesse unterschiedlich sind. Sie können sie beispielsweise kennenlernen: [4] und [5].
Einzelheiten zu den angewandten Modellierungs- und Designansätzen finden Sie in [6, 7].
Die vollständige UML-Spezifikation finden Sie unter [8].
Wir sind nun bereit, mit den nächsten Schritten fortzufahren und mit der Gestaltung der Funktionen des Systems und seiner internen Organisation zu beginnen. Die Nummerierung der Abbildungen wird fortgesetzt.
Stufe 3. Einem automatisierten Schritt muss eine oder mehrere Funktionen des Systems zugewiesen werden
Das automatisierte System (AS), das entwickelt wird, ist darauf ausgelegt, Nüsse streng zu protokollieren, erinnern Sie sich? Für jeden hervorgehobenen Schritt (siehe Abbildung 3, Abbildung 4). ), die wir automatisieren werden, schreiben die Funktionsanforderung auf, indem wir etwa diese Konstruktion verwenden: „Das System muss in der Lage sein ...“ und entwickeln ein Anwendungsfalldiagramm. 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 Beziehung „Assoziation“ (Abbildung 5), was bedeutet, dass der Benutzer mit dieser Rolle diese Funktion ausführen kann.
Abbildung 5. Verwendung einer Assoziationstypbeziehung
Von „Funktion“ zu „Anforderung“ zeichnen wir den Link „Implementierung“ (Abbildung 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 Umsetzung mehrerer Anforderungen beteiligt sein, und es kann sein, dass mehr als eine Funktion zur Umsetzung der Anforderung erforderlich ist.
Abbildung 6. Verwenden einer Implementierungsbeziehung
Wenn eine Funktion für ihre Ausführung die Ausführung einer anderen Funktion erfordert und dies notwendig ist, verwenden wir die Verbindung „Abhängigkeit“ mit dem Stereotyp „Einschließen“ – Inklusion (Abbildung 7). Wenn unter bestimmten Bedingungen die Ausführung einer zusätzlichen Funktion erforderlich ist, verwenden wir die Verbindung „Dependence“ mit dem Stereotyp „Extend“ – eine Erweiterung. Alles ist sehr leicht zu merken: „Einbeziehen“ – IMMER und „Erweitern“ – MANCHMAL.
Abbildung 7. Verwendung des Beziehungstyps „Abhängigkeit (einschließen)“
Als Ergebnis sieht unser Diagramm in etwa so aus (Abbildung 8).
Abbildung 8. Anwendungsfalldiagramm (Funktionsmodell von AS)
Darüber hinaus wird das Use-Case-Diagramm zur Modellierung von Benutzerrollen verwendet (Abbildung 9).
Abbildung 9. Anwendungsfalldiagramm (Rollen von AS-Benutzern)
Stufe 4. Beschreiben wir die interne Organisation des AS mithilfe eines Klassendiagramms
Anhand von Informationen über die Eingabe- und Ausgabeartefakte unseres Prozesses (siehe Aktivitätsdiagramme – Abbildung 2, Abbildung 3, Abbildung 4) werden wir ein Klassendiagramm entwickeln. Wir werden die Modellierungselemente „Klasse“ und verschiedene Arten von Beziehungen zwischen ihnen verwenden.
Um die „Ganzteil“-Beziehung zu zeigen, verwenden wir die Beziehung vom Typ „Aggregation“ (Abbildung 10): Die Nuss ist das Ganze, und die Schalen und der Kern sind die Teile.
Abbildung 10. Ganz-Teil-Beziehung
Als Ergebnis wird ein Fragment unseres Diagramms etwa so aussehen (Abbildung 11). Klassen werden mit einer Farbe markiert, die wir direkt in der Textbeschreibung des Prozesses hervorgehoben haben.
Abbildung 11. Klassendiagramm
Das Klassendiagramm wurde auch verwendet, um andere Artefakte zu modellieren – nicht nur solche, die für das konzeptionelle Modell des automatisierten Inventarisierungsprozesses relevant sind, sondern auch solche, die sich auf die Ausführungsumgebung beziehen – die Umgebung (Abbildung 12) und „Nachbar“-Prozesse (Abbildung 13). die den automatisierten Prozess beeinflussen können, aber noch nicht im Fokus unserer Aufmerksamkeit stehen (wir gehen davon aus, dass sich das System weiterentwickeln wird und diese Informationen nützlich sein werden).
Abbildung 12. Klassendiagramm (Umgebung)
Die Vererbungsbeziehung zeigt die Verallgemeinerung verschiedener Gebäude, „untergeordneter“ Klassen, unter der verallgemeinernden „übergeordneten“ Klasse „Gebäude“.
Abbildung 13. Klassendiagramm (weitere Informationen zu Artefakten)
Die „Reaktion auf die Situation“ hängt von den „visuellen Kontrolldaten“ ab. Für mehrere Abhängigkeitsbeziehungen wird das Stereotyp „Trace“ verwendet, um die Rückverfolgung von Klassen, die in der Prozessbeschreibung nicht explizit angegeben sind, aber für die Automatisierung erforderlich sind, auf Klassen zu zeigen, deren Instanzen in unserer Beschreibung genau angegeben sind.
Stufe 5. Lassen Sie uns die Notizen zum Track „Geschäftsregeln“ analysieren
Als Regeln wurden festgelegt (siehe Abbildung 2). ):
- die Notwendigkeit, einen der Schritte in zwei Teile aufzuteilen, der zweite Teil wird nur unter bestimmten Bedingungen ausgeführt;
- Ernennung eines bestimmten Beamten zur Durchführung der Buchhaltung von Nüssen;
- eine Technik (weiße Farbe der Elemente), die anzeigt, dass das Element nicht explizit in der Prozessbeschreibung aufgeführt wurde.
Es ist zu beachten, dass wir alle diese Regeln bereits bei der Entwicklung von Diagrammen angewendet haben.
Abschließende Bemerkungen
Also haben wir 5 Phasen durchlaufen und 3 Arten von Diagrammen erstellt. Ich werde noch einen Kommentar zur Organisation unserer Modelle in der Modellierungsumgebung hinzufügen. Es gibt eine große Anzahl von Frameworks, die bei der Strukturierung der von uns entwickelten Modelle helfen. Dies ist jedoch nicht Gegenstand dieses Artikels. Daher beschränken wir uns auf die folgenden einfachen Pakete zur ordnungsgemäßen Wartung unseres Projekts: Geschäftsprozess, Funktionsmodell, Artefakte, Teilnehmer und Umgebung (Abbildung 14).
Abbildung 14. Die Struktur der Projektpakete
Daher haben wir konsistente Modelle entwickelt, die das System der Bilanzierung von Sachwerten aus verschiedenen Blickwinkeln beschreiben: ein Modell eines automatisierten Geschäftsprozesses, ein Funktionsmodell und ein Modell der internen Organisation des Systems auf konzeptioneller Ebene.
Liste der Quellen
- Website "UML2.ru". Analysten-Community-Forum. Allgemeiner Abschnitt. Beispiele. Beispiele für Märchen in Form von UML-Diagrammen. [Elektronische Ressource] Zugriffsmodus: Internet:
- Sparx Systems-Website. [Elektronische Ressource] Zugriffsmodus: Internet:
- Modelio-Website. [Elektronische Ressource] Zugriffsmodus: Internet:
- Großes enzyklopädisches Wörterbuch. Prozess (Interpretation). [Elektronische Ressource] Zugriffsmodus: Internet:
- Website „Organisation eines effektiven Managements“. Blog. Überschrift „Geschäftsprozessmanagement“. Definition des Geschäftsprozesses. [Elektronische Ressource] Zugriffsmodus: Internet:
- Zertifikat Nr. 18249 über die Registrierung und Hinterlegung eines Produkts als Ergebnis geistiger Tätigkeit. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Das Manuskript des Lehrmittels mit dem Titel „Modellierung des Fachgebiets mit Enterprise Architect“ // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellierung von Geschäftsprozessen. - M.: KURS, NITs INFRA-M, EBS Znanium.com. – 2017.
- Spezifikation der OMG Unified Modeling Language (OMG UML). Version 2.5.1. [Elektronische Ressource] Zugriffsmodus: Internet:
Source: habr.com