2

アプリケーション サーバーとして Ruby on Rails を使用し、フロントエンドとして Java クライアントを使用してインベントリ システムを作成しています。

プロジェクトの一部では、統合クラス図 (すべてのクラスを含み、関係を示すクラス図) を作成することが義務付けられています。クラスの設計方法と以前に教えられた方法は、Boundary-Entity-Controller (BCE) パターンを使用して適切なクラスを作成することでしたが、MVC アーキテクチャを使用する Rails を使用しているため、それらは直接競合します。 2 つのパターンの間には 1:1 の相関関係がないため、特にこの場合の「ビュー」が単なる XML であることを考慮すると、ビューのクラス図はなく、境界クラスはコントローラーの入力とビューの出力。

これまでのところ、クラス ダイアグラムは Rails 関連のクラスのみを取り上げています (クライアント クラスはほとんどが UI であるため)。これまでに行ったことの結果は次のとおりです (100 万のゲッターとセッターがあるという事実は無視してください。プロジェクトの要件であるため、実際にはそのように実装することはありません。使用しますattr_accessor)。 ここで見るものは何もない....

それで、私たちは正しい軌道に乗っていますか？追加/編集/移動するものはありますか? 組み込みの ActiveRecord バリデータ メソッド ( など) を正確にモデル化するにはどうすればよいでしょうvalidates_numericality_of :priceか?

どんな助けでも大歓迎です！ありがとう。

4

2 に答える 2

0

いくつかの制約が与えられているようです。私の理解が正しければ、分析では BCE を使用し、アーキテクチャでは MVC を使用していました。RUP には、これらの目的のための 2 つのモデル (分析モデルと設計モデル) があり、どちらもクラス図で表されます。したがって、BCE アプローチと MVC アーキテクチャを 1 つの巨大な図で使用したことを示したい場合は、設計の RoR に基づいて分析とソリューション クラスから境界、コントロール、およびエンティティを描画し、依存関係を使用してそれらを<<trace>>ステレオタイプに接続できます。 .

RoR で検証メソッドがどのように実装されているかは完全にはわかりませんが、私の推測では、モデル クラス定義で validates... メソッドを呼び出すと、特定のモデル クラスは、新しいプライベート メソッドを使用したメタプログラミングによって強化されます。検証フェーズのコールバック。これについてはよくわかりませんが、それが真実で、メタプログラミングが関係している場合、問題があります。私の知る限り、メソッドを追加した後にクラスを表示する図 (クラス レベルのオブジェクト図のようなもの...) を描画するか、パッケージ マージによってメタプログラムをモデル化することもできますが、これも簡単ではありません。

于 2010-12-16T12:42:10.533 に答える
0

BCE と MVC の間の競合を正しく分析しました。それでは、クラスをマップしてみましょう。

  • Employee, Store, Product,Location は明らかに«entity»
  • EmployeeController、StoreController、ProductController、LocationController は、明らか«control»に個々のエンティティのシンプルな管理に対応しています。
  • ActiveRecordは実体ではありません。これは、解析モデルではなく、より洗練された設計モデルに既にいることを示しています。それでも、このクラスは実装にのみ貢献するため、«entity» を使用できます。
  • ManagerそしてReceiver、私が適切に分類するにはややあいまいです。ただし、 が の特別な役割を表すと想定されている場合は、継承よりEmployeeも構成を使用する方がよいでしょう。一般化/専門化の関係は、この柔軟性を許しません。従業員が作成された場合、その従業員は生涯マネージャーまたはレシーバーのいずれかになります。EmployeeEmployeereceivermanager

あまり明確ではないのは、XxxController実際にユースケースに対応しており、寄与するクラス間の調整を実際に行っているかどうかです。

  • Maintain employee recordsユースケースは通常、代わりになどの動詞で表されEmployeeControllerます。
  • ユースケースでは、複数のエンティティにアクセスする必要がある場合があります。たとえば、従業員の記録を維持することの 1 つは、店舗に従業員を割り当てることです。コントローラーはすべてのオブジェクト間の調整を担当するため、ストアにもアクセスする必要があります。これは、従業員に割り当てられたストアが実際に存在し、割り当てを許可するステータスにあることを確認する必要があるためです (たとえば、"StoreShutDownDefinitively 」）。Aそして、これは現在の図ではまったく明確ではありません.

最後になりましたが«boundary»、アクター (ユーザーまたはリモート システム) とユース ケースの間のすべてのリンクに対して、原則として a が期待されます。XML を作成するだけでは不十分です。XML を別のシステムに送信するか、XML を画面に表示し、必要に応じてスクロールする必要があります。Aさらに、リクエストに対応するか、別のレコードをクエリする機会をユーザーに与える必要があるかもしれません。

  • 分析モデルでは、リンクされたアクターと同じ数の «境界» クラスがあります。
  • しかし、設計モデルでは、複数の境界をすべてカバーする 1 つのクラスにまとめて再グループ化することができます。ただし、少なくとも 1 つの境界クラスが必要です。
  • RoRはわかりませんが、あの記事の図をよく理解すれば、あなたの境界はビューとルーティングに対応していると思います。従来の MVC では、コントローラーも境界内に配置されます。しかし、記事の詳細を見ると、RoRActionControllerは実際には MVC コントローラーよりもユースケース (つまり、「コントロール」) に近いという印象を受けます。
于 2020-09-07T21:58:02.340 に答える