1

クラス図を描くように頼むと、ほとんどの例はシステムのドメイン クラスを識別し、それらの間の関係を示します。しかし、それらのドメイン クラス内のビジネス メソッドも示しています。通常、ドメイン クラスはアプリケーション内で DTO として機能し、フィールドと getter および setter が認識している必要があります。

たとえばDoctor、ドメイン クラスです。もしそうなら、私たちはcreatePrescription()正しい方法を持つことができませんか？そのメソッドは、ドメイン クラスを使用する他のビジネス impl クラスにある必要がありますDoctor。

描画されたクラス図については、以下のリンクを確認してください。

http://umldiagramtutorial.blogspot.com/2012/10/hospital-management-system-class-diagram.html

私が言っているのは、Doctorドメインクラスにはそれらのメソッドがなく、代わりにクラスにあるべきだということDoctorMgtImplです。それが正しいか？

4

2 に答える 2

1

これは、UML の問題というよりも、設計/OOP の問題です。SOLIDの原則を順守している場合、あなたの主張は正しいです。つまり、1 つのオブジェクト (医師) に異なる責任を与えているということです。さらに、それDoctorは抽象ではなく、非常に具体的なものです。

一方、このクラス モデルは、システムでアクティブなエンティティとは何か、それらの機能は何か、それらがどのように相互作用するかについての概要を提供します。このダイアグラムは、さまざまなクラス (MVC の使用、インターフェイスの追加など) を使用して実装できます。UML ダイアグラムは実装の最初のポイントですが、実装は (そしてほとんどの場合) ダイアグラムに示されているとおりであってはなりません (なぜなら、実装する理由はダイアグラムから生成されるからです)。

于 2012-12-06T08:26:57.337 に答える
1

@vainoloに同意します。あなたの質問は実装にのみ関連しています。私は、エンティティがこの病院管理システムに非常に似ているプロジェクトに貢献しました。使用した主なエンティティを確認できますが、すべての DTO と DAO を最上位クラス図に入れているわけではありません。実装に関して、私たちが採用したアーキテクチャは、永続的なドメイン モデル クラス (例: Doctor.java)、コーダーフレンドリーな CRUD 操作でこれらの永続的なクラスを処理する DAO、インターフェースと実装を備えた DAO を使用するステートレス ビジネス レイヤー (「マネージャー」) でした。 、マネージャーを使用するコントローラー。これらすべてのクラスをモデル化するには、何日もかかったでしょう。UML クラス図の目的は、コードを表すことではないと判断しました。この方法をお勧めします:)

于 2013-08-21T09:02:22.440 に答える