「リスの一日」または有形資産会計自動化システム「Belka-1.0」のモデリングプロセスから設計まで（後編）
前回までのシリーズのまとめ
В 私たちは、おとぎ話のプロットに基づいた 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. プーシキン「サルタン皇帝の物語、その栄光と力強い息子グヴィドン・サルタノヴィチ王子と美しい白鳥の王女の物語」、 )
この例では、オーストラリアの会社の Enterprise Architect 環境を使用しています。 [2]、トレーニング セッションの枠組みで私が使用するのは、 [3]。
プロセスは異なることを思い出させてください。たとえば、次のように知ることができます。 [4]と [5]。
モデリングと設計に適用されるアプローチの詳細については、[6、7] を参照してください。
完全な UML 仕様については、次を参照してください。 [8]。
いよいよ次のステップに進み、システムの機能や内部組織の設計を始めます。 図の番号付けは続行されます。
ステージ 3. 自動化されたステップにはシステムの機能を割り当てる必要があります
開発中の自動化システム (AS) は、ナッツ類の厳密な記録を保持するように設計されています。 強調表示された各ステップについて (図 3、図 4 を参照) )、これを自動化します。「システムは ～ できる必要がある」という構造のようなものを使用して機能要件を書き留め、ユースケース図を作成します。 現在、私たちは実際に新しいルールでモデリング契約を補完しています。 どのような要素を使用するかを説明します。
「ユーザー ロール」と「機能」の間には「関連付け」関係 (図 5) を使用します。これは、このロールを持つユーザーがこの機能を実行できることを意味します。
図 5. 関連タイプの関係の使用
「機能」から「要件」まで、「実装」リンク (図 6) を描画して、この要件がこれらの機能によって実装されることを示します。関係は「多対多」である可能性があります。 XNUMX つの機能が複数の要件の実装に関与する場合もあれば、要件を実装するために複数の機能が必要になる場合もあります。
図 6. 実装関係の使用
ある関数の実行に他の関数の実行が必要であり、それが必要な場合は、「Include」ステレオタイプ (包含) を備えた「Dependence」接続を使用します (図 7)。 特定の条件下で追加関数の実行が必要な場合は、「Extend」ステレオタイプ (拡張機能) を持つ「Dependence」接続を使用します。 すべてを覚えておくのは非常に簡単です。「含める」 - 常に、「拡張する」 - 時々。
図 7. リンク タイプ「依存関係 (含める)」の使用
その結果、図は次のようになります (図 8)。
図8. ユースケース図（ASの機能モデル）
さらに、ユースケース図はユーザーの役割をモデル化するために使用されます (図 9)。
図 9. ユースケース図 (AS ユーザーの役割)
ステージ4. ASの内部構成をクラス図で説明してみよう
プロセスの入力および出力成果物に関する情報を使用して (アクティビティ図 - 図 2、図 3、図 4 を参照)、クラス図を作成します。 「クラス」モデリング要素とそれらの間のさまざまなタイプの関係を使用します。
「全体」の関係を示すために、「集合体」タイプの関係 (図 10) を使用します。ナッツが全体で、殻とカーネルが部分です。
図 10. 全体の部分の関係
その結果、図の一部は次のようになります (図 11)。 クラスは色でマークされており、プロセスのテキスト説明で直接強調表示されています。
図 11. クラス図
クラス図は、自動インベントリ プロセスの概念モデルに関連するものだけでなく、環境 (図 12) や「隣接」プロセス (図 13) などの実行環境に関連する他の成果物をモデル化するためにも使用されました。それは自動化プロセスに影響を与える可能性がありますが、まだ私たちの注意の焦点にはなっていません (システムが開発され、この情報が役立つと想定しています)。
図 12. クラス図 (環境)
継承関係は、一般化された「親」クラス「Building」の下に、さまざまな建物である「子」クラスが一般化されたことを示しています。
図 13. クラス図 (アーティファクトの詳細)
「状況に対する反応」は「視覚制御データ」に依存します。 いくつかの依存関係については、「トレース」ステレオタイプは、プロセスの説明では明示的に示されていないが、自動化には必要なクラスから、説明で正確にインスタンスが示されているクラスまでのトレースを示すために使用されます。
ステージ 5. 「ビジネス ルール」トラックのメモを分析しましょう
ルールが指定されているため (図 2 を参照) ):
- ステップの 2 つを XNUMX つの部分に分割する必要がある場合、XNUMX 番目の部分は特定の条件下でのみ実行されます。
- ナッツの会計を行うために特定の役人を任命する。
- 手法 (要素の白色)。これは、要素がプロセスの説明に明示的にリストされていないことを示します。
図を作成するときに、これらのルールはすべてすでに使用されていることに注意してください。
最後に
そこで、5 つの段階を経て 3 種類の図を作成しました。 モデリング環境でのモデルの構成について、もう 14 つコメントを追加します。 開発するモデルの構造化に役立つフレームワークは多数ありますが、これはこの記事の主題ではないため、プロジェクトを秩序正しく維持するための次の単純なパッケージのセットに限定します: ビジネス プロセス、機能モデル、成果物、参加者、環境 (図 XNUMX)。
図 14. プロジェクト パッケージの構造
したがって、私たちは、自動化されたビジネスプロセスのモデル、機能モデル、概念レベルでのシステムの内部組織のモデルなど、さまざまな角度から重要な資産の会計システムを記述する一貫したモデルを開発しました。
ソースのリスト
- サイト「UML2.ru」。 アナリストコミュニティフォーラム。 一般セクション。 例。 UML 図形式のおとぎ話の例。 [電子リソース] アクセスモード: インターネット:
- スパークスシステムのウェブサイト。 [電子リソース] アクセスモード: インターネット:
- モデリオのウェブサイト。 [電子リソース] アクセスモード: インターネット:
- 大百科事典。 プロセス（解釈）。 [電子リソース] アクセスモード: インターネット:
- ウェブサイト「効果的な管理の組織」。 ブログ。 見出しは「ビジネスプロセス管理」。 ビジネスプロセスの定義。 [電子リソース] アクセスモード: インターネット:
- 知的活動の結果の製品の登録および寄託に関する証明書番号 18249。 アルフィモフ R.V.、ゾロツキナ E.B.、クラスニコワ S.A. 「Enterprise Architect を使用した主題領域のモデリング」というタイトルの教材の原稿 // 2011。
- Zolotukhana E.B.、Vishnya A.S.、Krasnikova S.A. ビジネスプロセスのモデリング。 - M .: KURS、NITs INFRA-M、EBS Znanium.com。 — 2017年。
- OMG 統一モデリング言語 (OMG UML) 仕様。 バージョン2.5.1。 [電子リソース] アクセスモード: インターネット:
出所： habr.com