プロセスモデリングから自動化システム設計まで（後編）

「リスの一日」または有形資産会計自動化システム「Belka-1.0」のモデリングプロセスから設計まで（後編）

イラストは、A.S. プーシキン著「サルタン皇帝の物語」、児童文学社発行、モスクワ、1949 年、レニングラード、K. クズネツォフの絵に使用されました。

「リス」とは何の関係があるのでしょうか？

早速「リス」と何の関係があるのか​​説明していきます。 おとぎ話から借用した主題領域に基づいて UML を学習するための楽しいプロジェクトをインターネット上で見つけました (たとえば、 ここで [1]) と同様の例を生徒に用意して、最初はアクティビティ図、ユースケース図、クラス図の XNUMX 種類の図だけを学習できるようにすることにしました。 「翻訳の難しさ」に関する論争を避けるために、私は意図的に図の名前をロシア語に翻訳しません。 それが何のためにあるのかについては、後ほど説明します。 この例では、オーストラリアの会社の Enterprise Architect フレームワークを使用しています。 Sparxシステム [2] – 手頃な価格の優れたツール。 トレーニングセッションの一環として私が使用しているのは、 モデリオ [3] は、UML2.0 および BPMN 標準をサポートする優れた無料のオブジェクト指向設計ツールで、ビジュアル機能に関して不必要な付加機能はありませんが、言語の基礎を学ぶには十分です。

これらのプロセスで発生する重要な資産の会計処理を自動化していきます。

...
海に浮かぶ島(E1、E2)
島あられスタンド（E3、E1）
黄金のドームを持つ教会 (E4)
塔と庭園がある。 (E5、E6)
宮殿の前にトウヒが生えている (E7、E8)
そしてその下にはクリスタルハウスがあります。 (E9)
リスはそこに住んでいます、飼いならされています、(A1)
そう、なんというエンターテイナーなのでしょう！ (A1)
リスが歌を歌う (P1、A1)
はい、彼は木の実を全部かじります(P2)
そしてナッツは単純ではありません(C1)
すべての貝殻は金色です (C2)
カーネルは純粋なエメラルド。 (C3)
リスを守る従者たち（P3、A2）
様々な従者として彼女に仕える(P4)
そして事務員が配属されました(A3)
ナッツニュースの厳格な説明。 (P5、C1)
彼女に軍の名誉を与える。 (P6、A4)
貝殻からコインが注がれる（P7、C2、C4）
世界中に浮かんでみましょう。 (P8)
女の子がエメラルドを投げる（P9、A5、C3）
パントリーにありますが、ブッシェルの下にあります。 (E10、E11)
...
（A.S.プーシキン「サルタン皇帝の物語、彼の輝かしく強力な英雄ギドン・サルタノヴィチ王子と美しい白鳥姫の物語」、 このおとぎ話の制作はおそらく 1822 年に始まり、このおとぎ話はプーシキンによってコレクション「A. プーシキンの詩」（第 1832 部、130 年、181-XNUMX ページ）で初めて出版されました。 — ちなみに構想から出版まで10年！）

行の右側に書かれているコードについて少し説明します。 「A」（「Actor」から）は、その行にプロセスの参加者に関する情報が含まれていることを意味します。 「C」 (「クラス」から) – プロセスの実行中に処理されるクラス オブジェクトに関する情報。 「E」 (「環境」から) – プロセスを実行する環境を特徴付けるクラス オブジェクトに関する情報。 「P」（「プロセス」から） – プロセス自体に関する情報。

ちなみに、プロセスの正確な定義は、ビジネス、生産、技術などの異なるプロセスが存在するという事実だけが原因である場合でも、方法論的な論争の原因であると主張されています。 等々。 (たとえば、 ここで [4]と ここで [5])。 論争を避けるために、次の点に同意しましょう 私たちは、時間の経過に伴う再現性と自動化の必要性の観点から、このプロセスに興味を持っています。、つまりプロセス操作の任意の部分の実行を自動化システムに移すこと。

アクティビティ図使用上の注意

プロセスのモデル化を開始し、これにアクティビティ図を使用しましょう。 まず、上記のコードがモデル内でどのように使用されるかを説明します。 図の例を使用して説明する方が簡単ですが、同時にアクティビティ図のいくつかの要素 (必要な要素のほぼすべて) を分析します。
次の断片を分析してみましょう。

...
リスが歌を歌う (P1、A1)
はい、彼は木の実を全部かじります(P2)
そしてナッツは単純ではありません(C1)
すべての貝殻は金色です (C2)
カーネルは純粋なエメラルド。 (C3)
...

1 つのプロセス ステップ P2 と P1、参加者 A1、および 2 つの異なるクラスのオブジェクトがあります。クラス C3 のオブジェクトがステップに入力され、クラス C2 と CXNUMX のオブジェクトがこのステップ PXNUMX のアクティビティの結果として出力されます。プロセス。 この図では、次のモデリング要素を使用します。

私たちのプロセスの一部は次のように表すことができます (図 1)。

図 1. アクティビティ図の一部

スペースを整理し、アクティビティ図を構造化するために、UML 表記法の古典的な使用の観点から、非標準的なアプローチを使用します。 しかし、これにはいくつかの理由があります。 まず、モデリングを開始する直前に、いわゆる モデル契約、ここには記法を使用するすべての機能が記録されます。 第 6 に、このアプローチは、ソフトウェア システムを作成する実際のプロジェクトのビジネス モデリングの段階で繰り返し適用され、成功しました。結果は、私たちの小規模な著者チームによって対応する著作権オブジェクト [7] に記録され、トレーニング マニュアルにも使用されました [ XNUMX]。 アクティビティ図の場合、図フィールドが「スイム レーン」を使用して構造化されていることを定義します。 トラック名は、そのトラックに配置されるチャート要素のタイプに対応します。

「入力および出力アーティファクト」: このトラックには、オブジェクト要素 (使用されるオブジェクト、または何らかのプロセス ステップの実行の結果であるオブジェクト) が含まれます。
「プロセスステップ」: ここに、プロセス参加者のアクションであるアクティビティ要素を配置します。
"参加者"： プロセスにおけるアクション実行者の役割を示す要素のパス。それらに対して、同じモデリング要素 Object (オブジェクト) を使用しますが、それに「アクター」ステレオタイプを追加します。
次のトラックは "ビジネスルール" このトラックでは、プロセスのステップを実行するためのルールをテキスト形式で配置します。このために、モデリング要素 Note (メモ) を使用します。
このパスを使用することもできますが、ここで停止します。 「ツール」 プロセス自動化のレベルに関する情報を収集します。 パスも役に立つかもしれません 「参加者の役職と部署」、ロールをプロセス参加者の役職や部門にリンクするために使用できます。

私が今説明したものはすべて断片です モデリング規則、契約のこの部分は、XNUMX つの図を構成するためのルール、そしてそれに応じてそれを書いたり読んだりするためのルールに関係します。

"レシピ"

次に、システムを具体的にモデル化するオプションを考えてみましょう アクティビティ図から。 これは選択肢の XNUMX つにすぎません。もちろん、これが唯一の選択肢ではないことに注意してください。 アクティビティ図は、プロセス モデリングから自動化システムの設計への移行における役割の観点から興味深いものです。 これを行うために、方法論的な推奨事項、つまり XNUMX つの段階だけで構成され、XNUMX 種類の図の開発のみを提供する一種のレシピを遵守します。 このレシピを使用すると、自動化したいプロセスの正式な説明を取得し、システム設計用のデータを収集するのに役立ちます。 また、UML の学習を始めたばかりの学生にとって、これは、UML や最新のモデリング ツールにあるさまざまな視覚的手段やテクニックに溺れないようにする、ある種の救命手段です。

実際、ここにレシピ自体があり、「おとぎ話」の主題領域用に作成された図に従ってください。

ステージ 1. アクティビティ図の形式でプロセスを説明します。 10 ステップを超えるプロセスの場合は、プロセス ステップ分解原則を適用して図の読みやすさを向上させることが合理的です。

ステージ 2. 自動化できるものを選択する (たとえば、図上でステップを強調表示できます)。

ステージ 3. 自動化されたステップにはシステムの機能を割り当てる必要があります (関係は多対多になる可能性があります)、ユースケース図を描きます。 これらは私たちのシステムの機能です。

ステージ4. ASの内部構成をクラス図で説明してみよう - クラス。 アクティビティ図の「入力オブジェクトと出力オブジェクト (ドキュメント)」スイムウェイは、オブジェクト モデルとエンティティ関係モデルを構築するための基礎です。

ステージ 5. 「ビジネス ルール」トラックのメモを分析しましょう、それらはさまざまな種類の制限や条件を提供し、それらは徐々に非機能要件に変換されます。
結果として得られる図のセット (アクティビティ、ユースケース、クラス) は、かなり厳密な表記法で形式化された説明を提供します。 明確な読み方があります。 これで、技術仕様の作成、要件仕様の明確化などを行うことができます。

モデリングを始めましょう。

ステージ 1. アクティビティ図の形式でプロセスを説明する

「スイミング」レーンを使用してダイアグラム フィールドを構造化したことに注意してください。各レーンには同じタイプの要素が含まれています (図 2)。 上で説明した図の要素に加えて、追加の要素を使用します。それらを説明しましょう。

決定 (Decision) は図のプロセスの分岐点を示し、スレッドのマージ (Merge) は再統合の点を示します。 遷移条件は遷移上の角括弧内に記述されます。

XNUMX つのシンクロナイザー (フォーク) の間で、並列プロセスの分岐を示します。
私たちのプロセスは、開始点を XNUMX つだけ、つまりエントリ ポイント (初期) を XNUMX つだけ持つことができます。 ただし、特定の図ではなく、いくつかの完成 (最終) が存在する可能性があります。

非常に多くの矢印があり、多数の要素と接続があるため、まずプロセスの段階を特定し、次にこれらの段階の分解を実行できます。 しかし、明確にするために、「おとぎ話」のプロセス全体を XNUMX つの図で示したいと思います。もちろん、矢印が「くっついていない」ことを確認する必要があり、何が接続されているかを正確に追跡することが可能です。何に。

図 2. アクティビティ図 - プロセスの全体図

なぜなら詩的な行では、プロセスの詳細の一部が省略されており、復元する必要があり、白い背景の要素で示されています。 これらの詳細には、ストレージおよび処理のための転送/受信ステップと、いくつかの入出力アーティファクトが含まれます。 このステップでもプロセスが完全には明らかにされないことに注意してください。 送信ステップと受信ステップを別々に指定する必要があり、さらにシェル用に別のステップを追加する必要があります。また、最初にこれらすべてのマテリアル値をどこかに一時的に保存する必要があるなどと考えられます。 等々。
また、ナッツの起源についての疑問、つまりナッツはどこから来て、どうやってリスに届くのかという疑問は未解決のままであることにも注意してください。 そして、この質問 (メモ内の赤いフォントで強調表示されています - Note 要素) は、別の学習が必要です。 このようにアナリストは、少しずつ情報を収集し、仮説を立て、対象分野の専門家から「OK」「NOOK」をもらうという仕事をするのですが、システムを作る際のビジネスモデリングの段階では、非常に重要でかけがえのない人材です。

プロセスステップ P5 が XNUMX つの部分から構成されていることにも注意してください。

そして、各部分を分解してより詳細に検討します (図 3、図 4)。 これらの特定のステップ内で実行されるアクティビティは自動化されます。

図 3. アクティビティ図 - 詳細 (パート 1)

図 4. アクティビティ図 - 詳細 (パート 2)

ステージ 2. 自動化できるものを選択する

自動化するステップは、図上で色付きで強調表示されます (図 3、図 4 を参照)。

これらはすべて、プロセスの XNUMX 人の参加者、つまり事務員によって実行されます。

• ナットの重量に関する情報をステートメントに入力します。
• ナットの転送に関する情報を明細書に入力します。
• ナッツが殻と粒に変化する事実を記録します。
• ナッツカーネルに関する情報をステートメントに入力します。
• ナッツの殻に関する情報をリストに入力します。

行われた作業の分析。 次は何ですか？

そのため、私たちは多くの準備作業を行いました。自動化するプロセスに関する情報を収集しました。 モデリングに関する合意を形成し始めました (これまでのところ、アクティビティ図の使用に関してのみ)。 プロセスのシミュレーションを実行し、そのステップのいくつかを分解しました。 私たちは自動化するプロセスのステップを特定しました。 これで次のステップに進み、システムの機能と内部組織の設計を開始する準備が整いました。

ご存知のとおり、実践のない理論は無意味です。 ぜひ自分の手で「モデリング」を試してみてください。これは、提案されたアプローチを理解するのにも役立ちます。 たとえば、モデリング環境で作業できます。 モデリオ [3]。 全体的なプロセス図のステップの一部のみを分解しました (図 2 を参照)。 実際のタスクとして、Modelio 環境ですべての図を繰り返し、「保存および処理のための転送/受信」ステップの分解を実行することが求められる場合があります。
特定のモデリング環境での作業はまだ検討していませんが、これは独立した記事やレビューの対象になる可能性があります。

記事の後半では、UML ユースケース図とクラス図を使用して、ステージ 3 ～ 5 で必要なモデリングと設計のテクニックを分析します。 つづく。

ソースのリスト

1. サイト「UML2.ru」。 アナリストコミュニティフォーラム。 一般セクション。 例。 UML 図形式のおとぎ話の例。 [電子リソース] アクセスモード: インターネット: http://www.uml2.ru/forum/index.php?topic=486.0
2. スパークスシステムのウェブサイト。 [電子リソース] アクセスモード: インターネット: https://sparxsystems.com
3. モデリオのウェブサイト。 [電子リソース] アクセスモード: インターネット: https://www.modelio.org
4. 大百科事典。 プロセス（解釈）。 [電子リソース] アクセスモード: インターネット: https://dic.academic.ru/dic.nsf/enc3p/246322
5. ウェブサイト「効果的な管理の組織」。 ブログ。 見出しは「ビジネスプロセス管理」。 ビジネスプロセスの定義。 [電子リソース] アクセスモード: インターネット: https://rzbpm.ru/knowledge/pochemu-processy-stali-s-pristavkoj-biznes.html
6. 知的活動の結果の製品の登録および寄託に関する証明書番号 18249。 アルフィモフ R.V.、ゾロツキナ E.B.、クラスニコワ S.A. 「Enterprise Architect を使用した主題領域のモデリング」というタイトルの教材の原稿 // 2011。
7. Zolotukhana E.B.、Vishnya A.S.、Krasnikova S.A. ビジネスプロセスのモデリング。 - M .: KURS、NITs INFRA-M、EBS Znanium.com。 — 2017年。

出所： habr.com