2011-01-13 15 views
2

このユースケースは複雑ですか?私は初めてユースケースを実装しようとしています。ボールパーク内でそれを取得しようとしています。このUMLユースケースはあまりにも詳細ですか?

Use Case Diagram

+0

図はユースケースではなく、ユースケース*ダイアグラム*を表しています。ユースケースは、ダイアグラムの各楕円に対応しています。 – CesarGon

+0

@CesarGon、私は残念それを知っていた。 – Jordan

答えて

4

ヨルダン、ご利用の場合は、上部にあるシステム名を逃しています。

クライアントの要件に適合していれば、過度に複雑なユースケース図はありません。

P.S:ところで、以下のユースケースダイアグラムは学校での私の課題の1つです(システム構築のためではありませんが、とにかく似ています)。それはあなたがそこにあるものよりも複雑ですが、システムがこれらのユースケースをすべて必要とするため、過度に複雑ではありません。 TwitterやFacebookのユースケースを描くと想像してみてください。

Use Case Diagram      マーライオン大学学生会のシステムユースケース図

+0

私は名前を忘れていない、私はそれが専有であるため、省略した。私は「予算の作成」と「予算の変更」を組み合わせることができると思いますか?または、ユースケースの表示も含める必要がありますか? – Jordan

+0

異なるアクションのためにユースケースを分けることは明らかであり、良いことです。これは、ユーザーが特定のオブジェクトに対して異なるアクションを実行できることを示しています。クライアントとプロジェクトチームの間の誤解を最小限に抑えるために、文書やUMLを明確かつ正確にする必要があります。私はすべての "予算の作成"、 "予算の更新"、 "予算のクリア"、 "予算の表示"を書いていたでしょう。 – mauris

0

過度に複雑に見えないが、あなたは内のアクションで、右、上行く部分が欠落していますボックスの使用/影響。たとえば、アカウントの追加はデータベースと通信することができます。この場合、右側のボックス(中央のボックスの外側)にDatabaseという名前のボックスを置き、アカウントの追加ポイントを追加します。

+0

これには注意してください。あなたが構築しているシステムの範囲外にある場合は、ボックス外のものだけを表示してください。 dbを使用してシステムを実装することもできますが、外部のシステムではなく/システムの一部であるため、diagには属しません。 – sfinnie

+0

私は永続性の明確な方法を持っていません。私は、フラットファイル、XML、データベースなどのためのいくつかの交換可能な永続モジュールを作成しようとしていました...しかし、それらのどれもシステムの範囲外です。これは最初の反復ではシングルユーザーのスタンドアロンアプリケーションであるため、実際にはアクターは1人だけです。私は複数の役割を予測することができますが、それはこの時点で過度のことです。このプロジェクトの私の最も重要な目標は柔軟性です。実装がすべてわかったので、初めてアプリケーションの設計を正しく文書化したかっただけです。 – Jordan

関連する問題