Vom Modellieren von Prozessen zur Entwicklung eines automatisierten Systems (Teil 1)

Ein Tag im Leben eines Eichhörnchens oder vom Modellieren von Prozessen zur Planung eines automatisierten Systems zur Verwaltung von materiellen Werten "Eichhörnchen-1.0" (Teil 1)

Verwendete Illustration zu "Das Märchen vom Zaren Saltan" von A.S. Puschkin, Verlag "Kinderliteratur", Moskau, 1949, Leningrad, Illustrationen von K. Kuznetsov

Was hat es mit dem «Eichhörnchen» auf sich?

Ich werde sofort erklären, was es mit dem «Eichhörnchen» auf sich hat. Als ich im Internet auf amüsante Projekte stieß, die UML in Bezug auf Themen aus Märchen (zum Beispiel, [1]) lehren, wollte ich für meine Studenten ebenfalls ein solches Beispiel vorbereiten, um zunächst drei Diagrammarten zu lernen: Aktivitätsdiagramm, Anwendungsfalldiagramm und Klassendiagramm. Ich übersetze die Diagrammnamen absichtlich nicht ins Russische, um Streitigkeiten über "Übersetzungsschwierigkeiten" zu vermeiden. Was wofür gedacht ist, erkläre ich etwas später. In diesem Beispiel verwende ich die Umgebung Enterprise Architect von der australischen Firma hier Sparx Systems [2] – ein gutes Werkzeug zu einem fairen Preis. Und im Rahmen der Unterrichtsstunden wende ich Modelio an Modelio [3], ein gutes kostenloses Werkzeug für objektorientierte Modellierung, das die UML2.0 und BPMN Standards unterstützt, ohne übermäßige grafische Möglichkeiten, aber völlig ausreichend, um die Grundlagen der Sprache zu lernen.

Wir planen die Automatisierung der Buchhaltung von materiellen Werten, die in diesen Prozessen auftritt.

…
Eine Insel im Meer liegt, (E1, E2)
Der Grad steht auf der Insel (E3, E1)
Mit den goldkuppligen Kirchen, (E4)
Mit Türmchen und Gärten; (E5, E6)
Eine Fichte wächst vor dem Palast, (E7, E8)
Und darunter ein gläsernes Haus; (E9)
Ein Eichhörnchen wohnt dort, (A1)
Und was für ein Scherzbold! (A1)
Das Eichhörnchen singt Lieder, (P1, A1)
Und knabbert Nüsse, (P2)
Doch die Nüsse sind nicht einfach, (C1)
Alle Schalen sind golden, (C2)
Die Kerne reiner Smaragd; (C3)
Die Diener bewachen das Eichhörnchen, (P3, A2)
Sie dienen ihm mit verschiedener Hilfe (P4)
Und ein strenger Diakon wird zugeteilt (A3)
Strenge Buchführung über die Nüsse; (P5, C1)
Das Heer verleiht ihm Ehre; (P6, A4)
Aus den Schalen gießen sie Münzen, (P7, C2, C4)
Und lassen sie überall im Umlauf; (P8)
Die Mädchen streuen Smaragde (P9, A5, C3)
In die Vorratskammern, und unter den Deckel; (E10, E11)
…
(A.S. Puschkin "Die Sage von Zar Saltan, seinem ruhmreichen und mächtigen Heldensohn Fürst Guidon Saltanowitsch und der schönen Zarin Schwan") Die Arbeit an dem Märchen begann vermutlich im Jahr 1822, erstmals wurde das Märchen von Puschkin in der Sammlung „Gedichte A. Puschkins“ (Bd. III, 1832, S. 130—181) veröffentlicht. — 10 Jahre vom Entwurf bis zur Veröffentlichung, übrigens!)

Einige Informationen zu den Codes, die rechts neben den Zeilen stehen. „A“ (von „Actor“) bedeutet, dass in der Zeile Informationen über einen Prozessbeteiligten enthalten sind. „C“ (von „Class“) – Informationen über die Klassenobjekte, die im Verlauf der Prozesse verarbeitet werden. „E“ (von „Environment“) – Informationen über die Klassenobjekte, die die Umgebung der Prozesse charakterisieren. „P“ (von „Process“) – Informationen über die Prozesse selbst.

Übrigens beansprucht auch die genaue Definition des Prozesses, ein Ausgangspunkt für methodologische Streitigkeiten zu sein, zumindest weil es unterschiedliche Arten von Prozessen gibt: Geschäfts-, Produktions-, Technologieprozesse usw. (man kann sich beispielsweise informieren über hier [4] und hier [5]). Um Streitigkeiten zu vermeiden, vereinbaren wir, dass wir den Prozess aus der Perspektive seiner Wiederholbarkeit über die Zeit und der Notwendigkeit zur Automatisierung betrachten, d.h. die Übertragung der Ausführung eines Teils der Operationen des Prozesses auf ein automatisiertes System.

Hinweise zur Verwendung des Aktivitätsdiagramms

Lassen Sie uns mit der Modellierung unseres Prozesses beginnen, indem wir das Aktivitätsdiagramm verwenden. Zunächst möchte ich erklären, wie die oben genannten Codes in das Modell integriert werden. Es ist einfacher, dies mit einem grafischen Beispiel zu veranschaulichen, und wir werden gleichzeitig einige (fast alle notwendigen) Elemente des Aktivitätsdiagramms besprechen.
Analysieren wir den folgenden Ausschnitt:

…
Das Eichhörnchen singt Lieder, (P1, A1)
Und knabbert Nüsse, (P2)
Doch die Nüsse sind nicht einfach, (C1)
Alle Schalen sind golden, (C2)
Die Kerne reiner Smaragd; (C3)
…

Wir haben zwei Schritte des Prozesses P1 und P2, einen Teilnehmer A1 und Objekte aus drei verschiedenen Klassen: Ein Objekt der Klasse C1 tritt in Schritt ein, während die Objekte der Klassen C2 und C3 als Ergebnis der Aktivitäten dieses Schrittes P2 unseres Prozesses ausgegeben werden. Für das Diagramm verwenden wir die folgenden Modellierungselemente.

Der Ausschnitt unseres Prozesses kann ungefähr so dargestellt werden (Abbildung 1).

Abbildung 1. Ausschnitt aus dem Aktivitätsdiagramm

Um den Raum zu organisieren und das Aktivitätsdiagramm zu strukturieren, verwenden wir einen nicht ganz Standardansatz, was die klassische Anwendung der UML-Notation angeht. Dafür gibt es mehrere Gründe. Erstens erstellen wir vor dem Beginn der Modellierung ein sogenanntes Modeling Agreement., in dem wir alle Besonderheiten der Notation festhalten. Zweitens wurde dieser Ansatz bereits mehrfach erfolgreich in der Phase der Geschäftsmodellierung bei realen Projekten zur Erstellung von Softwaresystemen angewandt. Die Ergebnisse wurden von unserem kleinen Autorenteam in dem entsprechenden urheberrechtlich geschützten Objekt [6] dokumentiert und fanden auch in einem Lehrbuch [7] Anwendung. Für das Aktivitätsdiagramm definieren wir, dass das Diagrammfeld durch „Schwimmstreifen“ – Swim Lanes strukturiert wird. Der Name des Streifens entspricht dem Typ der Diagrammelemente, die auf diesem Streifen platziert werden.

„Eingangs- und Ausgangsartefakte“: auf diesem Streifen werden die Elemente Objects – Objekte angeordnet, die verwendet werden oder das Ergebnis eines bestimmten Schrittes im Prozess darstellen.
„Prozessschritte“: hier platzieren wir die Elemente Activity – die Aktionen der Prozessbeteiligten.
„Teilnehmer“: ein Streifen für die Elemente, die die Rollen der Ausführenden in unserem Prozess kennzeichnen werden. Für sie verwenden wir dasselbe modellierende Element Object – Objekt, fügen ihm jedoch das Stereotyp „Actor“ hinzu.
Der nächste Streifen heißt „Geschäftsregeln“ Auf diesem Abschnitt werden wir die Regeln für die Durchführung der Schritte des Prozesses in Textform festhalten, und dafür werden wir das modellierende Element Note – Anmerkung – verwenden.
Hier halten wir an, obwohl wir zusätzlich auch den Abschnitt nutzen könnten „Tools“ zur Sammlung von Informationen über den Automatisierungsgrad des Prozesses. Ein weiterer Abschnitt könnte hilfreich sein „Positionen und Abteilungen der Teilnehmer“, den man verwenden kann, um Rollen mit Positionen und Abteilungen der Prozessbeteiligten zu verknüpfen.

All das, was ich gerade beschrieben habe, ist ein Teil des Modellierungsabkommens, dieser Teil des Abkommens betrifft die Regeln für die Organisation eines Diagramms und entsprechend die Regeln für dessen Erstellung und Lesbarkeit.

„Rezept“

Jetzt betrachten wir die Option, ein System speziell aus dem Aktivitätsdiagramm zu modellieren. Dies ist nur eine von vielen Möglichkeiten. Ich möchte darauf hinweisen, dass es natürlich nicht die einzige ist. Das Aktivitätsdiagramm wird für uns von Bedeutung sein, da es den Übergang von der Prozessmodellierung zur Planung eines automatisierten Systems erleichtert. Dazu werden wir uns an methodische Empfehlungen halten – eine Art Rezept, das aus insgesamt fünf Phasen besteht und die Erstellung von drei Arten von Diagrammen vorsieht. Die Anwendung dieses Rezepts hilft dabei, eine formalisierten Beschreibung des Prozesses zu erhalten, den wir automatisieren möchten, und relevante Daten für den Systementwurf zu sammeln. Für Studierende, die mit UML beginnen, ist dies eine Art Rettungsring, der verhindert, in der Vielzahl von grafischen Mitteln und Techniken, die in UML und modernen Modellierungstools vorhanden sind, unterzugehen.

Hier ist das Rezept, gefolgt von den Diagrammen, die für unser „märchenhaftes“ Fachgebiet erstellt wurden.

Schritt 1. Wir beschreiben den Prozess in Form eines Aktivitätsdiagramms. Für Prozesse, die mehr als 10 Schritte umfassen, ist es sinnvoll, das Prinzip der Dekomposition der Prozessschritte anzuwenden, um die Lesbarkeit des Diagramms zu erhöhen.

Schritt 2. Identifizieren Sie, was automatisiert werden kann (Schritte können beispielsweise in einem Diagramm hervorgehoben werden).

Schritt 3. Dem automatisierbaren Schritt ist eine oder mehrere Funktionen des Systems zuzuordnen (es kann eine viele-zu-viele-Beziehung bestehen), wir zeichnen ein Use-Case-Diagramm. Dies sind die Funktionen unseres Systems.

Schritt 4. Wir beschreiben die interne Organisation des AAS mithilfe eines Klassendiagramms – Klassendiagramm. Der Fluss Pfad „Eingangs- und Ausgangsobjekte (Dokumente)“ im Aktivitätsdiagramm ist die Grundlage für den Aufbau des Objektmodells und des Entität-Beziehung-Modells.

Schritt 5. Wir analysieren die Notizen auf dem Pfad „Geschäftsregeln“, sie geben verschiedene Arten von Einschränkungen und Bedingungen vor, die schrittweise in nicht-funktionale Anforderungen überführt werden.
Die erhaltene Menge an Diagrammen (Aktivität, Use-Case, Klasse) bietet uns eine formalisierte Beschreibung in einer ziemlich strengen Notation, d.h. sie hat eine eindeutige Lesbarkeit. Jetzt können wir die technische Spezifikation entwickeln, die Anforderungsspezifikation klären usw.

Lassen Sie uns mit der Modellierung beginnen.

Schritt 1. Wir beschreiben den Prozess in Form eines Aktivitätsdiagramms

Ich erinnere daran, dass wir das Diagrammfeld mit Hilfe von "schwimmenden" Bahnen strukturiert haben, wobei auf jeder Bahn Elemente gleichen Typs angeordnet sind (Abbildung 2). Neben den oben beschriebenen Diagrammelementen werden wir zusätzliche Elemente verwenden. Lassen Sie uns diese beschreiben.

Die Entscheidung (Decision) kennzeichnet im Diagramm den Verzweigungspunkt unseres Prozesses, während die Zusammenführung (Merge) den Punkt darstellt, an dem sich die Ströme wieder vereinigen. In den eckigen Klammern an den Übergängen sind die Bedingungen für den Übergang angegeben.

Zwischen zwei Synchronisatoren (Fork) werden wir parallele Prozesszweige anzeigen.
Unser Prozess kann nur ein Anfang – einen Eintrittspunkt (Initial) – haben. Ablegungen (Final) können jedoch mehrere sein, aber nicht für unser spezifisches Diagramm.

Es gibt eine Vielzahl von Pfeilen; bei einer großen Anzahl von Elementen und Verbindungen kann man zunächst die Prozessschritte hervorheben und anschließend diese Schritte weiter aufschlüsseln. Aber ich möchte unseren "märchenhaften" Prozess zur Veranschaulichung vollständig auf einem Diagramm darstellen, wobei natürlich darauf geachtet werden muss, dass die Pfeile "nicht kleben", sodass genau nachverfolgt werden kann, was mit was verbunden ist.

Abbildung 2. Aktivitätsdiagramm – Gesamtübersicht des Prozesses

Da in den poetischen Zeilen einige Prozessdetails weggelassen wurden, mussten sie wiederhergestellt werden, dargestellt mit Elementen auf weißem Hintergrund. Diese Details umfassen den Schritt „Speicherung/Übertragung zur Verarbeitung“ und mehrere Ein- und Ausgangsartefakte. Es ist erwähnenswert, dass dieser Schritt den Prozess nicht vollständig offenbart, da wir den Übertragungs- und den Empfangsschritt separat kennzeichnen müssten, und außerdem wäre es notwendig, einen eigenen Schritt für die Schalen hinzuzufügen und zudem zu bedenken, dass all diese materiellen Werte zuerst irgendwo vorübergehend gelagert werden müssen, usw. usf.
Lassen Sie uns auch beachten, dass die Frage nach der Herkunft der Nüsse bisher ohne Antwort geblieben ist – woher kommen sie und wie gelangen sie zum Eichhörnchen? Diese Frage (die in rot in der Notiz hervorgehoben ist – Element Note) erfordert eine gesonderte Bearbeitung! So arbeitet ein Analyst – Stück für Stück Informationen sammeln, Annahmen treffen und von Fachexperten – sehr wichtigen und einfach unverzichtbaren Personen in der Phase des Geschäftsmodellierens bei der Erstellung von Systemen – ein „Okay“ oder „Nicht-Okay“ erhalten.

Beachten Sie auch, dass der Schritt des Prozesses P5 aus zwei Teilen besteht.

Jeden Teil werden wir detaillierter aufschlüsseln und näher betrachten (Abbildung 3, Abbildung 4), da die Tätigkeiten, die speziell in diesen Schritten durchgeführt werden, automatisiert werden.

Abbildung 3. Aktivitätsdiagramm – Detaillierung (Teil 1)

Abbildung 4. Aktivitätsdiagramm – Detaillierung (Teil 2)

Schritt 2. Identifizieren Sie, was automatisiert werden kann

Die Schritte, die automatisiert werden sollen, sind in den Diagrammen farblich hervorgehoben (siehe Abbildung 3, Abbildung 4).

Alle Aufgaben werden von einem Prozessbeteiligten durchgeführt – Diakon der Anordnung:

• Erfasst die Gewichtsinformationen der Nüsse in das Protokoll;
• Erfasst die Informationsübertragung der Nüsse im Protokoll;
• Dokumentiert die Umwandlung der Nüsse in Schalen und Kerne;
• Erfasst die Informationen über die Kerne der Nüsse in das Protokoll;
• Erfasst die Informationen über die Schalen der Nüsse in das Protokoll.

Analyse der geleisteten Arbeit. Was kommt als Nächstes?

Wir haben also eine umfangreiche Vorarbeit geleistet: Wir haben Informationen über den Prozess gesammelt, den wir automatisieren wollen; wir haben begonnen, ein Modellvereinbarung zu erstellen (bislang nur bezüglich der Nutzung eines Aktivitätsdiagramms); wir haben den Prozess modelliert und sogar einige seiner Schritte dekomponiert; wir haben die Schritte des Prozesses identifiziert, die wir automatisieren möchten. Jetzt sind wir bereit, zu den nächsten Etappen überzugehen und mit dem Entwurf der Systemfunktionen sowie seiner internen Organisation zu beginnen.

Wie bekannt ist, ist Theorie ohne Praxis nichts. Es ist unbedingt erforderlich, das "Modellieren" selbst auszuprobieren, da dies hilfreich ist, um die vorgeschlagene Vorgehensweise zu verstehen. Zum Beispiel könnte man in einer Modellierungsumgebung arbeiten. Modelio [3]. Wir haben nur einen Teil der Schritte des allgemeinen Prozessdiagramms dekomponiert (siehe Abbildung 2). Als praktische Aufgabe könnte angeboten werden, alle Diagramme in der Umgebung Modelio zu wiederholen und den Schritt "Übertragung/Empfang zur Lagerung und Verarbeitung" zu dekomponieren.
Wir betrachten die Arbeit in bestimmten Modellierungsumgebungen derzeit nicht, aber das könnte Gegenstand eigenständiger Artikel und Übersichten werden.

Im zweiten Teil des Artikels werden wir Methoden der Modellierung und Planung untersuchen, die in den Phasen 3-5 notwendig sind. Wir werden UML-Diagramme, insbesondere Anwendungsfall- und Klassendiagramme, verwenden. Fortsetzung folgt.

Quellenverzeichnis

1. Website «UML2.ru». Forum der Analysten-Community. Allgemeiner Bereich. Beispiele. Beispiele von Märchen, die in Form von UML-Diagrammen dargestellt sind. [Elektronische Ressource] Zugriff: Internet: http://www.uml2.ru/forum/index.php?topic=486.0
2. Website von Sparx Systems. [Elektronische Ressource] Zugriff: Internet: https://sparxsystems.com
3. Website von Modelio. [Elektronische Ressource] Zugriff: Internet: https://www.modelio.org
4. Großes Enzyklopädisches Wörterbuch. Prozess (Interpretation). [Elektronische Ressource] Zugriff: Internet: https://dic.academic.ru/dic.nsf/enc3p/246322
5. Website „Organisation effektives Management“. Blog. Kategorie „Management von Geschäftsprozessen“. Definition eines Geschäftsprozesses. [Elektronische Ressource] Zugriff: Internet: https://rzbpm.ru/knowledge/pochemu-processy-stali-s-pristavkoj-biznes.html
6. Zertifikat Nr. 18249 über die Registrierung und Hinterlegung von Ergebnissen geistiger Aktivität. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuskript eines Lehr- und Methodikhandbuchs mit dem Titel „Modellierung von Fachgebieten mit Enterprise Architect“ // 2011.
7. Zolotuchina E.B., Vishnia A.S., Krasnikova S.A. Modellierung von Geschäftsprozessen. — M.: KURS, NIZ INFRAM, EBS Znanium.com. — 2017.

Quelle: habr.com