開発者は、システム設計中に作成されたクラス図を順守する必要がありますか？

Question

クラス図はシステム要件をモデルにしているため、これらの要件に基づいてソリューションを作成することが重要です。クラス図を言ったら、それを厳密に接着する必要がありますか？リファクタリングはどうですか？図が私が取り残されていると思ういくつかのデザインの原則を提供しなかった場合はどうなりますか？

Answer 1

短い答え：いいえ。

出力は、それが想定されるビジネス機能を実行する（できればテストされた）動作する必要があります。そのタスクをどのように達成するかは、義務付けられるべきではありません（再び、NASAで働いていない限り）。

足の不自由なアナロジー：私はタクシーに乗り、どこに行くべきかを伝えます。私は彼らに任せて私をそこに連れて行きます。私は彼らが私を安全かつタイムリーにそこに連れて行くことを信じています。私はそこに座ってタクシーの運転手をマイクロ管理して、彼のターン信号をいつオンにするか、どのくらいのアクセルを押すか、いつガスを得るかを彼に伝えるつもりはありません。それが彼の仕事です。

Answer 2

要件にクラス図がありますか？要件ではなく、仕様の一部である必要がありますが、みんなのショップは異なると思います;）仕様を遵守することが重要です。そうしないと、アプリケーションの別の領域に逸脱しても知らずに影響を与えている可能性があります。仕様が間違っている場合は、再開し、変更を伝え、レビューしてからコードを変更します。あなたが同意しないときでさえ。ある実装が別の実装よりも選択された理由のすべてを知っているわけではありません。

Answer 3

以下のポイントがあなたの決定を下す前に考慮するために提示されています。そのアイデアは、あなたのようなケースに一般的に影響する要因を調べることです。

ポイント0：実装スタイルが何であれ、すべてのビジネスルールを実装する必要があります。

ポイント1：UMLでは、クラス図はモデル全体の一部にすぎません。ユースケース、シーケンスなどの定義されたクラスを利用する他の図があります。

ポイント2：RDBMSを使用したOOアプリケーションでは、オブジェクトの最初のアプローチを使用してアプリケーションが構築されているか、データの最初のアプローチを使用して構築されるかを決定する必要があります。これに基づいて、ドメインモデルが構築されます。 2種類のモデルは非常に異なる場合があります。見る： オブジェクトリレーショナルインプ。ミスマッチ.

ポイント3：OOおよび部分的には、ポイント＃3の結果として、データベースレイヤーを表すオブジェクトは、他のアプリケーションレイヤーまたはサービスで使用されるオブジェクトとは異なる場合があります。 Webサービスを使用している場合、APIは、ビジネスレイヤー定義とデータレイヤー定義とは異なる方法でオブジェクトを定義する可能性もあります。

ポイント4：UMLモデルにはフェーズがあり、通常は方法論によって定義されます 開発モデルのマッピング。プロセス, 、各フェーズは異なるモデルを生成する場合があります。もちろん、実装フェーズモデルを変更することは、その影響のために最も望ましくなく、最も重要です。

ポイント5：プロジェクトのライフサイクル段階での変更の影響、他の仲間の労働者やDBAでの既存のデータ、その既存のデータを考慮する必要があります。