UMLシーケンス図でアルゴリズムを表すのに十分な深さはありますか？
3つの単純なクラスがあります。 LoginController、UsersCatalogおよびUser。 UsersCatalogにはUserの配列があります。ログインの簡単なプロセスを表す必要があります。
LoginControllerには、同じパラメータを使用してメソッドlogin(username, password)を呼び出すだけのメソッドauthenticate(username, password)があります。
これで、メソッドauthenticateが一致するUserオブジェクトを探して返すことは明らかです。質問は次のとおりです。シークアルゴリズムを表す必要がありますか？シークアルゴリズムを表すのは低レベルすぎませんか？
反対に、Userクラスへのアクセスはシークアルゴリズムの内部にあるため、それを表さない場合、Userクラスへのアクセスを表さない。
これはより広い質問の一部です。 UMLシーケンス図でアルゴリズムを表すのに十分な深さの基準はありますか？
一般に、考慮すべき2つのことがあります。
- UMLドキュメントの対象読者
- プロジェクトの成功にとってアルゴリズムがどれほど重要か
これらの図は、技術者以外の（またはソフトウェア以外の）顧客向けの設計レビューの一部として作成していますか？はいの場合は、アルゴリズムを含めないでください。レベルが低すぎると、聴衆を失います。
ダイアグラムは、メンテナンスプログラマーの全体的なリファレンスとして使用されますか？このシークアルゴリズムに特別な、新しい、または技術的に革新的なものは何もないと仮定して、気にしないでください。コメントで十分かもしれません。
または、何らかの理由で、ソフトウェアがこのシークを効率的に実行することが重要になる場合があります。または確実に。または、アルゴリズム自体が特別で、新しいか、技術的に革新的です。その場合は、擬似コード、UMLシーケンス図など、適切な形式で文書化してください。プロジェクトの成功にとって重要な場合は、将来、図が参照される可能性があります。
シーケンス図は、対象となる主要なオブジェクト（User、LoginControllerなど）間のメッセージ交換の順序を指定するのに適しています。オブジェクトがメッセージを受信すると、受信によってオブジェクトの内部に何らかのロジックが発生します（オブジェクトのクラスで指定）。走る。そのロジックの機能を説明するアルゴリズムは、シーケンス図には記載されていません。 可能性がありますクラスにリンクされているアクティビティ図（フローチャート）に文書化されています。アルゴリズムを視覚的に説明したい場合は、アクティビティ図を使用してください。