4

ドメインモデル図とクラス図の両方を設計するとき、何を入れるべきか理解するのに苦労しています。

私が言いたいことの例を挙げます：

Administratorとを持つ休暇スケジューラ プログラムを実行していEnd-Usersます。は、プログラムへのAdministrator登録、特権の変更などのいくつかのことを行います。休暇の日などを選択できます。End-UsersEnd-User

最初に and をドメイン モデルの概念として定義しAdministrator、End-User後でクラス図のクラスとして定義しました。クラス図では、両方のクラスが次のようないくつかのメソッドを持つことになりました

Administrator.RegisterNewUser();
Administrator.UnregisterUser(int id);

等

しばらくして、実際にはAdministratorとの両方End-Userがアクターであることに気付きました。おそらく、このデザインは完全に間違っていたのでしょう。管理者クラスとエンド ユーザー クラスにユース ケースの要求を実行するためのメソッドを入力する代わりに、ドメインから他のクラスを定義してそれらを実行し、コントローラにユース ケースを処理させることができます (実際には、それぞれに 1 つずつ実行することにしました)。使用事例）。たとえば、クラスでこれらのメソッドを使用する代わりに、 UserDatabase.RegisterNewUser()andを使用できます。UserDatabase.UnregisterUser(int id);Administrator

アイデアは、休暇スケジューラ全体を、一連の機能を持ち、認証などのことを気にしない「クローズドプログラム」と考えようとすることです。外の世界に見せたいのは、そのコントローラーです。

これは正しいアプローチですか？それとも、私はこれを完全に間違っていますか？アクターをドメインモデル/クラス図に入れるのは一般的に悪い考えですか? これにはどのような経験則がありますか?

私の講師はApplying UML and Patternsに従っていますが、これはひどいと思います。そのため、この記述されたアクター モデルの状況に関する詳細情報をどこで調べられるか知りたいです。

この新しいアプローチは、私が以前に行ったこととは根本的に異なるため、私はまだこれらすべてについて少し混乱しています。

4

2 に答える 2

4

あなたが推測するように、あなたの設計が完全に間違っているとは言いません。実際、管理者とエンドユーザーは、クラス図で何らかの形で表す必要がある有効なドメイン オブジェクトです。これら 2 つのエンティティをアクターとして識別したからといって、それらをドメインから除外する必要があるという意味ではありません。覚えておいてください。ドメインはスコープ、つまり「関連コンテキスト」、つまり、関連する役割を果たす一連の有用なオブジェクトです。解決。

モデルを構成する基本的なオブジェクトから始めて、ブレインストーミングのように、それ以上の分析を行わずに書き留めるだけでよいでしょう...

  • 休暇
  • 位置
  • 旅行代理店
  • スケジュール
  • ユーザー
  • 予約
  • 予約サービス (これは、休暇の予約にアクセスするためのインターフェイスになる可能性があります)

次に、それらのオブジェクト間の関係を確立してみてください。適切なオブジェクトを選択していないことを意味する関係が見つからない場合、それらが同じ問題ドメインの一部である場合、それらは何らかの形で関連している必要があります。

しばらくすると、オブジェクトが欠落していることに気づき、可能な限りカプセル化して、正しい抽象化を表現しようとするでしょう。デザイン パターンがその助けになるかもしれません。

すべての可能なオブジェクトがそのすべてのプロパティとメソッドで表現されている場合、まだ完成していませんが、完全に機能する設計が必要です。

頭の中にたくさんの理論が必要だとわかっているので、恐れずに始めてください。私自身、このアプローチを仕事で何度もうまく使用してきました。

最後に、UML Distilledのコピーを取得します。

よろしく、

于 2010-06-05T03:02:24.563 に答える
2

ドメイン モデリングと、ユース ケースからクラス図に至るまでのプロセスについて、もっと学ぶべきだと思います。分類子としてのアクターはクラス図の一部にすることができますが、分析と設計に使用されるクラス図は、開発するシステムをモデル化しており、アクターは外部エンティティです。ユース ケースとユース ケース図を使用する場合の目標は、機能要件と非機能要件を特定することです。したがって、開発するシステムの範囲と、開発中のシステムと相互作用する外部エンティティ (ロールまたはシステム) を定義します。ユースケース図では、システムで実現されるすべてのユースケースを包含するシステム境界を表すボックスを見つけることがありますが、アクターは箱から出しています。ドメインをモデル化するときは、通常、システムのことを完全に忘れてしまいます。ドメインがどのように機能するかを把握したいからです。多くの場合、ドメイン モデリングには特別な図とモデリング要素が使用されます。先ほど言ったように、ポイントはシステムが使用されるドメインを理解することです。分析および設計フェーズのクラス図は、開発中のシステムを記述するため、内部にアクターは存在できません。

于 2010-06-05T10:57:55.580 に答える