0

提案したシステム用に以下の図を作成しましたが、いくつか質問があります。

このプロジェクトには、プログラム (Java)、Web サイト、およびデータベースの 3 つのコンポーネントがあります。

プログラムを使用して、ユーザーはデータを生成し、データベースに送信できます。これは、Web インターフェイスを介してユーザーが表示できます。

図からわかるように、「データのエクスポート」<<extend>>「情報を Web サイトに渡す」があります。(データベースは、PHP を介してデータベースからデータを取得します)。これは、「データのエクスポート」が「Web サイト インターフェイス境界」にある必要があるということですか。

また、3 番目の境界を追加する場合、それは悪い習慣ですか?

提案されたユースケース

4

1 に答える 1

1

あなたの主な質問に具体的に答えるために、ユースケース（拡張など）とユースケースの封じ込め（パッケージやシステム境界など）の間のリンクに関する強い要件はありません

しかし、それとは別に、あなたの図について非常にぎこちないように思えるいくつかのことを言わせてください:

  • この情報が図に含まれている必要があります。このユースケースを実行するアクターはどれですか? ここでは、データベースはパフォーマーではないと想定しているため、下部の 3 つのユース ケースを除いて、この図のユース ケースはこのルールを尊重していません。
  • 2 つのユース ケースの間ではなく、アクターとユース ケースの間にのみ線を引くことができます。ここで、たとえば、Export data と Query database の間で、どういう意味ですか? <<include>>データ エクスポート プロセスの一部がデータベースにクエリを実行することを意味する場合は、クエリ データベースを指す矢印との関係が必要です。これは、クエリ データベースがインポート データの必須のサブ ユース ケースであることを意味します。まぁ勝手な推測ですが…
  • あなた<<extend>>の s も正しいかどうかわかりません。ここで意味することは、権限を付与するときに、必要に応じて資格情報を確認し、情報を Web サイトに渡すときに、必要に応じてデータをエクスポートできるということです。私はそれがあなたが意味するものではないと確信しています。

最後の 2 つの点を要約すると、次のようになります。

Main use case ------------> sub use case
              <<include>>

Main use case <------------ optional sub use case
               <<extend>>

UML 構文で、インクルードとエクステンドの間で矢印が逆になっているのは非常に面倒ですが、そのように機能します。私のせいじゃない ：）

于 2013-03-28T22:32:39.023 に答える