自動車修理工場がどのように機能するかを図とドキュメントでシミュレートすることで、UML を学んでいます。私が抱えている問題の 1 つは、事後条件 (または GOTO) ステートメントに関するものです。
破線の << include >> 関係は前提条件のみですか? ユースケースのバブルは互いに接続してロジック パスをたどることができますか?
だから、これは私がこれまでに持っているものです.. 1) 「支払いの決済」バブルは間違った場所にありますか? 他のバブルに << インクルード >> するべきでしたか? 2) 車を修理するのは技術者なので、'request service' バブルを技術者にも関連付ける必要がありますか?
画像
ユースケースはクラスのようなものです。それらには、継承 (拡張) と、includes や uses などの関係があります。
前提条件は、一般的な関係の制約です。ユースケースのテキストに事前条件と事後条件を書く人もいます。描くことはできますが、必須ではありません。
ユースケースのバブルを順番に並べようとしないでください。それが、アクティビティ図とシーケンス図の目的です。それが物語のテキストです。それはユーザーがすでに知っていることです。
また、ユースケースを超高水準のプログラミング言語として扱うために多くの時間を無駄にしないでください。アクターは自分が何をしているのかをすでに知っていることを忘れないでください。彼らは物事を順序付けするのに助けを必要としません。
アクター、ユース ケース、およびユース ケースの基本的な「拡張」、「用途」、「組み込み」を把握することに集中する必要があります。ユース ケース モデルはプログラミングではありません。ユース ケース図は、「誰が」「何を」のナレッジ キャプチャです。
アクターができることを定義するセキュリティ モデルのようなものと考えてください。順序、シーケンス、およびその他の詳細は、俳優が何をするかほど重要ではありません。
アクターに関連付けられたアクター (技術者やフロント デスクなど) がある場合、アクターがシステムの外部で対話することを意味します。あなたは、技術者がシステムにログインして仕事をしたり、時間を記録したりすることは決してないと言っています。
技術者が実際にログインして仕事を取得し、時間を記録する場合、技術者はいくつかのユースケースに参加します。
ユースケースはプログラミングではありません。それらは俳優がすることです。ユースケースは、大きな共通のソフトウェアに組み込まれているという利点によって結び付けられています。ユース ケース間でデータ フローやロジックの矢印を描く必要はありません。それらはすべて、ほぼ独立している可能性があります。
システムを設計するときは、いくつかの順序でユース ケースを接続する UI 機能とデータベース機能を実装します。