0

UML は理解できますが、基本的な分析を行うのに苦労しているようです。プロジェクトの例を次に示します。

目的は、登録ユーザーが別のユーザーを購入して所有し、ステータス メッセージを変更できるページまたは Facebook アプリケーションを設計することです。

各ユーザーは 1000 ポイントで開始し、別のユーザーを 500 ポイントで購入できます。これにより、他のユーザーがユーザーを 30 分間購入するのを防ぐことができます。取引が完了すると、購入者は 200 ポイント、購入したユーザーは 200 ポイントを獲得します。100ポイント使うごとに20ポイント獲得。ユーザーが購入されるたびに、価値が 200 増加します。毎日 300 ポイントが与えられます。

メンバーは、検索機能またはリストを通じて他のメンバーを見つけることができます。

管理者は、ユーザー情報を表示したり、ゲームに関する情報を取得したり、ボーナス ポイントを付与したりできます。

Use Case ActorsUserとAdministrator. ユース ケースは、、、Search（ユーザーの場合）および、、（Buy管理者の場合）です。シーケンス図に関しては、必要なクラスと操作を決定するときに行き詰まっています。ModifyView user informationView game informationGive bonus points

この例を使い始めるにあたって、どのようなアドバイスやアプローチを与えることができますか? このテーマに関する本を何冊か読んでみましたが、混乱しています。

4

2 に答える 2

2

いくつかのクラスができるまで、シーケンス図を作成しても意味がありません。

表記にこだわっているように聞こえます。あなたの問題についてもっと心配してください。UMLは、オブジェクト指向ソフトウェアシステムを記述する方法についてのアイデアを取り込むための標準的な表記法にすぎません。重要なのは表記法ではなく、アイデアです。

解決しようとしている問題の適切なオブジェクト表現を取得することについてもっと心配してください。問題は何よりもまずである必要があります。「私のシステムは何をする必要がありますか？」そうです、ユースケース図にアクターが誰であるかを尋ねる人は誰もいません。

はい、2人のアクターとしてユーザーと管理者がいるようです。「ユーザーの検索」や「ゲームポイントの追加」などの操作があります。（どこかに隠れている「プレイゲーム」はありますか？）

于 2011-10-10T09:55:13.907 に答える
1

オプションである場合は、UML の代わりに SysML を使用することを検討してください。SysML はシステム分析/設計用に設計されているため、UML が持つ詳細を表現するためのモデリング要素がすべて含まれているわけではありません。ただし、要件 (UML にはありません) があり、もちろんユース ケース、アクティビティなどもあります。

しかし、もっと重要なことは、一連のユース ケースからクラスの設計に到達できるとは思わないということです。またはできますが、おそらく悪いでしょう。

これは、設計は分析の改良ではなく、質的に異なるものであるためです。分析は設計に入力されます (つまり、システムは何をすべきか) が、どのようなエラー報告戦略を使用するかはユース ケース モデルではわかりません。あなたのコードは採用する必要があります。または、あなたの場合、最大のデザイン ドライバーは実際にはユース ケースではなく、Facebook API でこれを実装するという事実です。

したがって、私ができる最善のアドバイスは、分析を行っているときに設計について心配しないことです。クラスのことは忘れて、システムの実装方法ではなく、システムが何をすべきかを決定します。

于 2011-10-11T10:56:18.543 に答える