第1章 モデリングとUML-03

モデリングワークフローABCD
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759949/89465298-d828-0b5c-34df-b6c9922eefef.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759949/68c8fff8-a8fb-b1b8-5a5c-0f7c085b2691.png)

要求とデザインを適切に行い、低コストで売れるシステムを製造するには、単なるスローガンではなく、必要なモデリングスキルを学び、実践する必要があります。
ソフトウェア開発は増分的で反復的に行われ、各反復周期では次のことを考える必要があります：
A- ビジネスモデリング（business modeling）- 改善が必要な目標組織の位置付けと、その組織が次に最も改善する必要がある問題を特定します。
B- 要件（requirements）- 組織の問題を改善するために、導入される情報システムが持つ必要がある全体的な機能とパフォーマンスを記述します。
C- 分析（analysis）- 機能要件を満たすために、導入される情報システムが包含する必要があるコアドメインメカニズムを抽出します。
D- デザイン（design）- 品質要件と設計の制約を考慮し、コアドメインメカニズムを選択した非コアドメインにマッピングして実装します。
上記のABCDはソフトウェア開発の4つのモデリングワークフローであり、AとBは販売問題を解決し、CとDはコスト問題を解決します。
UML記法を使用する場合、ABCDワークフローはこの図のようになります。詳細な内容については後でゆっくり説明します。
ABCDの危険性を理解していない
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759949/d08dad2b-5a0f-2039-1369-9a3b0a1137ea.png)

考える順番が逆になる
ソフトウェア開発者が「A-ビジネスモデリング」、「B-要件」、「C-分析」、「D-設計」の作業フローに概念を持っていない場合、どのような危険があるでしょうか？」
開発者に「何をしているのか」と尋ねると、「設計をしている」「ドキュメントを書いている」と答えるかもしれませんが、実際には、その時点で彼の脳は組織のプロセス（A-ビジネスモデリング）を考えたり、システムの機能要件（B-要件）を考えたり、システムが封装するドメイン概念の関係（C-分析）を考えたりしているかもしれませんが、彼はすべて「設計をしている」「ドキュメントを書いている」と答えます。
つまり、彼の脳では、ソフトウェア開発作業は単純に「コードを書く」と「設計（ドキュメントを書く）」に分けられています。彼が「コードを書いて」いない場合、彼はすべて「設計（ドキュメントを書く）」しています。
彼は「設計」または「ドキュメント」を、「コード」のより概要的または形象的な表現形式と見なしています。異なる「設計」または「ドキュメント」は、異なる視点からコードを見ることを可能にし、開発者がコードを異なる視点から観察できるようにします。
こうした誤解は、単なる「普通の」開発者に限定されません。マーティン・ファウラーのUMLに関するベストセラー『UMLの本質』では、UMLの3つの用途を提案しています：スケッチ、設計図、プログラミング言語、また、UMLモデルをコードのビューと見なすこともありますが、これは正しくありません。マーティン・ファウラーは特定のコミュニティではグルと見なされていますが、彼の他の著作である『リファクタリング』、『エンタープライズアプリケーションアーキテクチャのパターン』、『分析パターン』からは、彼の研究が主に「C-分析」と「D-デザイン」のワークフローに焦点を当てており、「A-ビジネスモデリング」と「B-要件」のワークフローにはあまり関与していないことが示されています。彼の「A-ビジネスモデリング」と「B-要件」に関する発言は慎重に扱う必要があります。他にも危険なのは、「ドキュメント」を「コード」のビューとして見る傾向で、これは思考の逆転を引き起こす可能性があります：ランダムにコーディングを行い（Dワークフローに直行）、それからコード（D）からA、B、およびCワークフローの内容を逆にエンジニアリングすることで、他のワークフローが単なる表面的な形式になることがあります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759949/ac71a69a-1c45-e0d5-59ce-10c098c0bef1.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759949/44e90a66-d09c-a849-e6e2-80c881a79545.png)

私が遭遇した逆転した考え方のいくつかのインスタンスを以下に示します：
★対話1
私：これはシステムのユースケースではないはずです（読者が「ユースケース」を理解していない場合は、単に「機能」と考えてください）。
開発者：はい！すでに書いてあります。システムがこのユースケースを提供していることを示すために実行します。
システムにこのユースケースが必要かどうかは、「A-ビジネスモデリング」から推論されます。ビジョンやビジネスシーケンス図などの手順を経て、必要であればシステムに含まれます。そうでなければ、含まれません。単に「コードを書いたので存在するはず」というわけではありません。
★対話2
私：これら2つのクラスの関係は一般化ではなく、関連であるはずです。
開発者：一般化です。信じないですか？コードを開いて見せます（または：逆エンジニアリングを使用してクラス図を生成します）。
一般化の関係が存在するかどうかは、ドメインロジックに基づいて判断されるべきです。ドメインロジックに含まれていない場合は、コードに含まれていないはずです。まず「人間は豚の一種である」というようなコードを書いてから「人間は豚の一種である」ということを証明しようとしてはいけません。
★対話3
私：AがBを集約（または合成）しています。これは違うようです。
開発者：その通りです。私のコードを見てください。Aは集約ルートであり、他のオブジェクトはまずAを呼び出し、データアクセスもAをアクセスユニットとして行います。
対話2と同様に、それが集約（または合成）関係であるかどうかは、ドメインロジックに基づいて判断されるべきです。
ドメインロジックに含まれていない場合は、コードでそのようにするべきではありません。
ABCDワークフローの概念と、異なるワークフローで必要な思考や表現を理解すると、もう「文書を書いています」とは言わなくなるかもしれません。「文書を書いています」と言うことは、単に「コードを書いていない」とか「文書編集ツールを使って仕事をしている」という意味になります。
あなたが書いている「文書」はどのようなものですか？「A - ビジネスモデリング」？「B - 要件」？「C - 分析」？私は書かずに図を描くだけですが、それは許されないのでしょうか？私は書かずに描かず、声で組織のプロセスをはっきりと表現しますが、それは許されないのでしょうか？私はWordでコーディングします（つまり、D - デザインですが）、それは許されないのでしょうか？私はC#で要件を書きます（つまり、B - 要件ですが）、それは許されないのでしょうか？
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759949/734ee089-d528-8b44-49e9-9330cea12852.png)

もっと意味のある表現としては、「ビジネスモデリングを行っています」、「要件に取り組んでいます」などがあります…。もし「文書」という言葉があなたにとってかけがえのない喜びをもたらすなら、「ビジネスモデリングの文書を書いています」と言うこともできます。
第二の危険は無計画な対応です。
![uploading...0]()


開発者はよく「変化に対応する」と話します。中には「変化を受け入れる」といったスローガンを唱える人もいますが、多くの人はどのような変化に対応すべきか、また正しくどのように対応すれば良いかを理解していません。
「変化」という言葉について話すとき、真実は次のいずれかの場合があります：
真実（1）：全く変化がない。
システムの要件（機能、パフォーマンス、制約）は変わっていません。以前は実装の問題により、要件を満たすことができなかったか、要件を満たすことができたが、システムの内部構造が合理的でないと考えられました。このような変更は「変化に対応する」とは言えず、「エラー修正」と呼ぶしかありません。
この場合、焦点を当てるべき作業フローは「C-分析」と「D-設計」です。
真実（2）：システムの機能は変わっていませんが、パフォーマンスと制約が変わりました。
たとえば、応答時間を短縮する必要がある、または実装プラットフォームを変更する必要がある場合です。
このような変更に対応するには、「D-設計」に焦点を当てる必要があり、実装アプローチを調整する必要があります。