プロセスモデリングから自動化システムの設計まで（パート2）

「リスの人生の1日」またはモデリングプロセスから材料値の会計システム「Squirrel-1.0」の設計まで（パート2）

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

前シリーズのまとめ

最初の部分では、おとぎ話のプロットに基づくUMLダイアグラムの研究の例に触発された「おとぎ話」の主題領域を使用しました（たとえば、 ここ [1]を参照）。 モデリングを開始する前に、アクティビティ図のいくつかの要素の使用に同意し、モデリング契約の策定を開始しました。 これらの合意に基づいて、第1段階でプロセスをアクティビティ図の形式で説明し、第2段階で自動化が必要な（および可能な）プロセスステップを特定しました。

これらのプロセスで生じる重要な価値の会計処理を自動化することを思い出させてください。

...

島は海にあります（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.プーシキン「皇帝サルタンの物語、彼の栄光と力強い英雄のグビドン・サルタノヴィッチと美しい白鳥の王女」、 それは信じられているように、民話「金の膝の深さ、銀の手のひじ」の無料扱いプーシキンによってさまざまな方法で記録されました ）

この例では、オーストラリアの企業Sparx Systems [2]のエンタープライズアーキテクト環境を使用し、トレーニングセッションの一部としてModelio [3]を使用しています。

プロセスが異なっていることを思い出させてください。たとえば、 ここ [4]とここ [5]を知ることができます。

モデリングおよび設計に適用されるアプローチの詳細については、[6、7]を参照してください。

ここ [8]で完全なUML仕様を参照してください。

これで、次のステップに進み、システムとその内部組織の機能の設計を開始する準備ができました。 図の番号付けは継続されます。

ステップ3.自動化されたステップは、システムの機能と一致する必要があります。

開発された自動システム（AC）は、ナッツの厳密な記録を保持するように設計されています、覚えていますか？ 自動化する選択された各ステップ（ 第1部の図3、図4を参照）について、機能要件を書き留め、「システムは...を実装できる必要があります」というおよその構造を適用し、ユースケース図を作成します。 現在、モデリング契約に新しいルールを追加しています。 使用する要素を説明します。

「ユーザーロール」と「関数」の間では、アソシエーションアソシエーション（図5）を使用します。つまり、このロールを持つユーザーの場合、この関数の実行が可能です。

図5.関連付けタイプの通信の使用

「機能」から「要件」まで、「実装」関係（図6）を描き、この要件がこれらの機能によって実装されることを示します。関係は「多対多」、つまり 1つの機能が複数の要件の実装に関与する場合があり、要件を実装するために複数の機能が必要になる場合があります。

図6.実装タイプの関係の使用

1つの機能の実行に他の機能を実行する必要があり、それが必要な場合、「依存」というステレオタイプと「包含」という関係を使用します（包含）（図7）。 特定の条件下で追加機能の実行が必要な場合は、ステレオタイプ「拡張」-拡張の関係「依存」を使用します。 すべてを覚えるのは非常に簡単です。「含める」-常に、「延長」-時々です。

図7.「依存（包含）」タイプの関係の使用

その結果、図は次のようになります（図8）。

図8.ユースケース図（AS機能モデル）

さらに、ユースケース図を使用してユーザーロールをモデル化します（図9）。

図9.ユースケース図（スピーカーユーザーの役割）

ステージ4.クラス図を使用してASの内部組織を説明します

プロセスの入力および出力アーティファクトに関する情報を使用して（アクティビティ図-図2、図3、図4を参照）、クラス図を作成します。 「クラス」モデリング要素と、それらの間のさまざまなタイプの接続を使用します。

「全体」の関係を示すために、「集約」タイプの関係を使用します（図10）。ナットは全体であり、シェルとカーネルは部分です。

図10.「全体」という関係

その結果、図の断片は次のようになります（図11）。 色は、プロセスのテキスト説明で直接特定したクラスを示します。

図11.クラス図

クラス図は、他の成果物のモデル化にも使用されました-材料値の自動化プロセスの概念モデルに関連するものだけでなく、ランタイム環境に関連するもの-環境（図12）および「隣接」プロセス（図13）自動化されたプロセスに影響を与えますが、まだ注目されていません（システムが開発され、この情報が役立つと想定しています）。

図12.クラス図（環境）

継承関係は、一般化された「親」クラス「構造」の下の、さまざまな建物「子」クラスの一般化を示しています。

図13.クラス図（成果物に関する追加情報）

「状況への対応」は「ビジュアルコントロールデータ」に依存します。 いくつかの依存関係について、「トレース」ステレオタイプを使用して、プロセスの説明で明示的に示されていないが、自動化に必要なクラスのトレースを、説明に正確に示されているインスタンスのクラスに示します。

ステージ5.トラック「ビジネスルール」のメモを分析します

ルールが示されたように（ 第1部の図2 を参照）：

1. ステップの1つを2つの部分に分割する必要がある場合、2番目の部分は特定の条件下でのみ実行されます。
2. 特定の役人のナッツの会計の任命;
3. 技術的手法（要素の白色）、要素がプロセスの説明で明示的に示されていないことを示します。

ダイアグラムを開発するときにこれらのルールをすべて使用したことに注意してください。

結論の観察

そこで、5つの段階を経て、3種類の図を作成しました。 モデリング環境でのモデルの構成について少しコメントを追加します。 開発中のモデルの構造化に役立つ多くのフレームワークがありますが、これはこの記事の主題ではありません。したがって、プロジェクトを秩序正しく実行するための次の簡単なパッケージセットに限定します：ビジネスプロセス、機能モデル、アーティファクト、参加者、環境（図14）。

図14.プロジェクトパッケージの構造

したがって、さまざまな角度からの物質価値の会計システムを記述する一貫したモデルを開発しました：自動化されたビジネスプロセスのモデル、機能モデル、および概念レベルでのシステムの内部組織のモデル。

プロセスモデリングから自動化システムの設計まで（パート1）