私は現在、大学のプロジェクトに取り組んでいますが、ある教師から、UML クラス図 (設計図と考えてください) にクラスが存在する可能性があると考えるのは間違っていると言われましたが、データには同等のものはありません。モデル。それから彼は、私の主張を証明するために反例を示すように私に圧力をかけましたが、私はそれを思いつきませんでした.
「Learning UML 2.0」、「Applying UML and Patterns」、UML 2 for dummies などの UML に関する本を何冊かチェックしましたが、クラス図に表示されるクラスに関する情報は見つかりませんでした。私は彼に実装クラスについて尋ねましたが、彼はそれらをクラス図に含めるべきではないと言いました。だから私はここで途方に暮れています。
投稿する前に、この質問も確認しました。
しかし、彼らは私が持っている質問を本当に解決しません。
あなたが持っているかもしれない洞察をありがとう。
教師もあなたも、UML と概念データ モデリング (ER モデリングと同じだと私は考えています) の違いに不必要に気を取られています。あなたと先生が議論している本当の問題は、使用するモデルに関係なく、分析と設計の違いです。
記述されたとおりに問題を図式化するか、または設計どおりに解決策を図式化する UML モデルを作成できます。最初のケースでは、実装クラスは問題のドメインに関連しないため、省略してください。2 番目のケースでは、それらを含める必要があります。最初のケースは分析です。2番目のケースはデザインです。
ER図に関しても同じ曖昧さが存在します。私を含む一部の人々は、問題自体に固有のデータ要件を表すためだけに ER モデルと ER 図を使用します。これは、「概念的なデータ モデリング」が最もよく意味するものです。このフレームワークでは、出現する必要がある唯一のエンティティは、主題自体に認識された現実があるエンティティであり、データベースまたはアプリケーション内の単なる構成要素ではありません。これが分析です。
しかし、テーブルのスキーマの設計を図式化するために ER ダイアグラムを使用する他の多くの人々 (おそらく大多数) がいます。このフレームワークでは、外部キーが含まれており、ジャンクション テーブルは対象エンティティではありませんが、エンティティのステータスに昇格されます。分析と設計の区別が明確に保たれている限り、これに本質的な問題はありません。
残念ながら、分析と設計の区別は、認識できないほどあいまいになっていることがよくあります。ここSOには、これのインスタンスが数十あります。
したがって、分析と設計の間の混乱があなたと教師の間の議論に忍び寄るのを許すと、議論はほとんどあらゆる方向に進んでしまう可能性があります。
「ある教師は、UMLクラス図（設計図と考える）に、データモデルに相当するクラスがない可能性があると考えるのは間違っていると言いました。その後、彼は私にカウンターを提供するように圧力をかけました。私の主張を証明するための例ですが、私はそれを考えることができませんでした。」
彼は正しい。概念分析/概念設計の段階では、UMLクラス図のこれらの長方形のボックスは「概念」を表しています。そして、「概念」が何であれ、その概念（の性質）、それに関連する他の概念、およびそれらの関係の性質を説明するために、いつでもその周りにE/R図を描くことができます。
UML についての私の理解では、ダイアグラムにあるべきものを定義していません。IBM サイトでこの例を見つけました: (画像が読み込まれなかったので、ここにリンクがあります: http://www.ibm.com/developerworks/webservices/library/ws-RESTservices/ )
確かに、サーブレットはドメイン モデルの一部ではありません。属性とメソッドを持つエンティティであるクラスをモデル化するために使用される UML クラス図。私見、それらがドメインモデルの一部であるか、アプリケーションをサポートする機能クラスであるかは問題ではありません。それらを顧客に見せる必要がある場合、それらはそこにある必要があります。