高レベル モデル (モジュール) の設計または低レベル モデルの設計を依頼されましたか? 低レベルのモデル設計では通常、より小さな問題またはドメインが必要になるため、高レベルのモデル設計では大きな問題またはドメインに取り組むことをお勧めします。
通常、要件/問題は質問者 (ユーザー/インタビュアー) から生じるため、ビジネス要件を定義する必要はもうありません。しかし、システムを設計する必要があります。
ハイレベルモデル
私は「Apple Genius Recommendation System」についてよく知らないので、よくあるPoint Of Sales問題である別の問題の類推を使用します。高レベル モデルでは、システム全体を定義します。通常約:
それはすべて高レベルのモデル/モジュールです。モデルを実現する方法について尋ねられた場合は、次の手順を実行します。
- ユーザーとシステム間の標準的なユース ケースを定義する
- ユース ケースを、リッチ ピクチャ (またはよく知られているもの) などの共同図に注ぎます。
例外のユース ケースを定義します。例外が簡単に定義できる場合は、すぐにモデル化してください。そうでない場合は、ビジネス チームとさらに議論するために例外をモデルにマークします。
一部のユース ケースの例外として、コミット済み注文の変更、頭金後のコミット済み注文の変更、支払い済み注文のキャンセル、商品の在庫切れなどがあります。
プロセスを繰り返します。通常、ステップ 3 はステップ 1 になる可能性があります (例外は、別のユースケースになる可能性があります)。
たとえば、コミットされた注文の変更は、発生する変更が多いため、使用例になる可能性があります。
追加のユース ケースの例外なしで 3 番目が完了すると (すべてのユース ケースが処理されます)、通常は を追加しvalue-additional operationsます。
これらの操作には、通知 (電子メール/画面上)、履歴データのメンテナンス、リマインダー、エラー処理などがあります。一部の操作は別のユース ケースでもある可能性があるため、1 番まで繰り返す必要がある場合があります。
たとえば、頭金決済中にエラーが発生した場合、頭金データを手動で入力する別のユースケースが必要になる場合があります。あるいは、別のシステムでリマインダー システムを維持する必要があるかもしれません。
低レベルモデルに移動
追加情報として、私は通常、注文状態などのユースケース/機能の状態図を使用します。
低レベルモデル
低レベルモデルは、高レベルからより小さな問題に取り組みます。簡単に言うと、高レベル (おそらく順序付け) から 1 つのユース ケースを取り上げ、そこから低レベルの設計を開始します。最初にクラス図を定義するのではなく、通常、何らかの形式のシーケンス図に取り組みます。いくつかの理由を次に示します。
- シーケンスは、入力の取得、データの取得、および応答の提供に関する同時実行ビューを提供します
- データベースや Web サービスなどの他のシステムとの関係についてよく理解できます。
- アプリの基本的なアーキテクチャに非常に役立つ、エントリ ポイントまたはインターフェイスに関する図を提供できます。
- クラス図に基づいて、クラス図ではなくシーケンス設計中に落とし穴を簡単に見つけることができます
次に、システム状態図 (編集可能、表示可能など) に進みます。
最後に、 と に続きdatabase designますclass diagram。
クラス図が最後のステップにあるのはなぜですか?
クラス図 (およびデータベース設計) は、プロセス全体に大きく依存しています。同時実行の発生方法、通知、外部システムとの相互作用などは、インターフェイスとクラス ダイアグラムの設計に影響を与える可能性があります。また、コードベースに最も近い設計でもあります。
これは完全に私の経験と意見です。