14

最初のステップで、DFD を作成しました。次に、クラス図の作成に進みました。そうしているうちに、まずER図を作成する必要があると感じました。クラス図に取り込めない詳細がたくさんあったからです。それで、私の質問はERDを最初に作成するか、クラス図を作成する必要がありますか?

あなたの貴重な情報は大歓迎です!!! 読んでくれてありがとう

4

4 に答える 4

12

モデリングするときは、その時点で自分にとって最も意味のある順序で図を作成するという観点から考える傾向があります。それが最初にクラス図である場合もあれば、エンティティ関係図である場合もあれば、シーケンス図である場合もあります。覚えておくべき主なことは、物事を理解し、他の人も理解できるように書き留めようとしているということです。自分の考えを整理する最善の方法は何かを心配することは、それを理解し、理解している部分を書くことほど役に立ちません。

[編集]: FWIW、私はまた、紙やホワイトボードでモデリングを開始する傾向があり、進行中であると理解していることに近づいたときにのみ、コンピューターの使用に切り替えます. (私は単にコンピューターで絵を描くのが好きではないのだと思います。) 重要なのは、モデリングは理解することであり、(あまり) コンピューターについてではないということです。

于 2010-04-26T09:39:30.957 に答える
3

オブジェクト指向の純粋主義者は、クラス図を最初に作成する傾向があります。データベースのバックグラウンドを持つ人々は、最初に ER 図を作成し、これからクラス図を「派生」させます (このアプローチは、オブジェクト指向の純粋主義者に嫌われています)。

私はハイブリッドアプローチを好みます。

最初にエンティティを識別します。これは、データベースとアプリケーション (クラス) の両方の観点から同じである必要があります。

エンティティの概要について合意したら、クラス図と ER 図を並行して進めます。これは、「関係」がそれぞれ異なるためです。(それらに取り組んでいるのがあなただけの場合は、最初にクラス図から始めて、次に ERD から始めます。ただし、最初に実体を特定します)。

私の意見では、データベースとアプリケーション (Java/C#...) の両方で、高レベルのエンティティは同じでなければなりません。また、共通のベースを使用することは非常に簡単です。特に、さまざまな部分 (クラス、データベース) で作業しているさまざまな人がいる場合はなおさらです。

于 2010-04-26T09:54:36.193 に答える
2

それは本当にあなたのアプリケーションに依存すると思います。&私はUMLについて少し知っており、標準のUMLクラス図を使用するだけで関係の多重度と主キーをモデル化できることを知っているので、多くの場合、クラス図で十分です. オブジェクト指向の分析と設計、ユースケース、ユースケースの実現、および分析クラスを使用するのが好きなので、クラス図から始めるのが好きです。一方、優れたデータベース設計には、正規化と、場合によっては非正規化、データ クエリのさまざまな最適化が求められます。私は個人的に、ほとんどのアプリケーションのリレーショナル部分を単なるストレージ メカニズムと見なしており、オブジェクト指向プログラミングの観点からシステムについて考えています。これは、たとえば Ruby on Rails で特に役立ちます。

于 2010-04-26T16:02:48.870 に答える
0

ER図は最初は最悪です - オブジェクト図と継承ツリーのメソッドに関するより多くの情報を含むオブジェクト図よりも情報が少ないため、ER図では両方の要素が欠落します。

そのため、オブジェクト階層 (クラス図) から始めて、マッピング側に移るのがよいでしょう ;)

于 2010-04-26T09:38:48.887 に答える