2

したがって、ドメインモデルを構築することは、チームとしてアプローチするときに最もよく起こると私が思うことであることは間違いありません。モデリングセッションには、技術的ではなく「ビジネス」のメンバーである誰かを巻き込むことさえあります。適切な人を部屋に入れてホワイトボードに物を打ち込むと、多くのことがすばやく完了します。しかし、あなたがその贅沢を持っていない時代はどうですか？複雑なドメインモデルを単独で構築する必要がある場合はどうでしょうか。私はこの1か月ほどこれを行っており、次のことを行っています。

  1. 名詞の識別から始めて、Class-Role-Collaborationsを使用して関係を分析します
  2. モデル、パーティなどを改良するために使用できる分析パターンを探します。
  3. 基本を理解したらすぐに、IDEを無効にして、XUnitテストの作成を開始し、モデルが必要なことを実行できることを示します。

これらの手法はうまく機能しましたが、真の共同作業ほど効率的かどうかはわかりません。概念がxまたはyの要件に違反していることに後で気付くだけで、その概念に夢中になるのは簡単だと思います。オブジェクト/ドメインモデルがターゲットに確実に収まるようにするために、単独で作業するときにどのような手法を使用しましたか？

4

2 に答える 2

3

やり方は人それぞれだと思いますが…

私はほとんどの場合、クラス図 (通常は UML に似た紙の上) から始め、クラスとそのアリティ間の関係に特に注意を払います。この段階での検証は、主に、エンティティの高レベルのセマンティクスが一緒になって意味があるかどうかを理解しようとしています。

次に、主要な機能、特にコラボレーションに関係する機能のスケッチを開始します。コラボレーション内のオブジェクトが関係を通じて相互に到達できることを確認してください。この段階では、描画ツール (StarUML) を使用します。

そしてゲダンケン実験。私は頭の中で考えられる最もトリッキーなユースケースを検討し、与えられた設計でそれらに対処する方法を想像できるかどうかを確認します。これは疑似コードではなく、主要なタスク/関数のそれぞれをステップ実行し、ダイアグラムの行に従って、コールバックや循環依存関係などを見逃していないことを確認するだけです.

1 つの鍵は、おそらく十分に機能するだろうと自分で納得するまで、デザインの特定の側面に過度に固執しないことだと思います。私の考えでは、デザインを評価/検証するために精神的にステップを踏むことができない場合は、問題の理解が不足しているか、紙のデザインが十分に完成していないかのどちらかです...

次に、時間が許す限り、それを脇に置いて、本当に違うものを思いつくことができるかどうか見てみましょう...

于 2008-10-09T19:48:10.050 に答える
1

すべてを自分で構築する場合は、順応性があることを確認してください。最初のショットですべてを考える方法はないからです。

大きな紙を用意してください。すべてを引き出して、ぐちゃぐちゃに。完璧にすることを心配しないでください。考えたことをすべて書き留め、役に立たないことが判明したものに取り消し線を引いてください。紙は、あなたの心がいたるところにオブジェクトモデルの断片を吐き出したように見えます. すでに書き留められていることを考えるときは、それらを目立たせてください。このプロセスの最後には混乱が生じますが、多くの良いアイデアが生まれることは間違いありません。現時点では、これを人に見せることをお勧めしますが、それは論外だとおっしゃっていたので、先に進みます。

次に、UML ツールを使用してコンピューターの前に座り、ブレイン ダンプのハイライトに似たものを計画します。オブジェクト モデルの主要な部分について考えてから、それらの部分を連携させるためのより小さな部分について考えてください。何かが決まったら、その UML をコードに変換し、それが機能するかどうかを確認するためにいくつかのテストを書き始めます。すすいで繰り返します。

于 2008-10-09T20:20:41.200 に答える