私が書いたソフトウェアのシーケンス図をいくつか描かなければなりません。私のソフトウェアには、カスタムイベントをディスパッチするオブジェクトと、これらのイベントをリッスンする他のオブジェクトがあります。
Eventlisteners と dispatchEvent-function を説明するとき、私はそれを行う方法について少し混乱しています。私はたくさんグーグルで検索しましたが、正しいヒントを見つけることができませんでした:(
それとも、イベント処理を説明するのにシーケンス図は適していませんか?
ご協力いただきありがとうございます！
有用な図を作成するかどうかは、読者に伝えたい情報の種類に大きく依存するため、質問に対する決定的な答えはありません。私のアドバイスは次のとおりです。プログラムのすべての機能を 1 つの図だけで示すことはできません。イベント処理はしばしば複雑すぎて醜いです - それをより小さな部分に分割して、どの種類の図がどの側面を示したいのかを個別に決定してみてください。
それぞれについて、常に読者に焦点を当てる必要があります。読者に何を理解してもらいたいですか?
まず、ユーザー ストーリーを書き、ユース ケースを示すのが通常は最善です。それらは、プログラムが作成された機能を伝え、プロセスを識別し、プログラムについての考え方を整理するのに役立ちます。これらの各プロセスについて、物事がどのように機能するかを示すには、おそらくシーケンス図が最も役立ちます。たとえば、プログラムの機能の 1 つが画像のアップロードである場合、アップロード手順のみに関係する主要なコンポーネント、オブジェクト、および一連のイベントを示すシーケンス図を作成する必要があります。
次のステップは、残りのイベントとオブジェクトを分類することです。これらは、よりきめ細かいものであるか、ユーザーと直接対話しないものです。どのイベントが内部 (つまり、同じオブジェクト内でディスパッチおよび処理される) で、どれが外部 (いくつかのオブジェクト間) です。 、またはグローバル (アプリケーション全体に影響します)。これは、互いに相互作用するオブジェクトのグループを識別するのに役立ちます。
オブジェクトの複雑さに応じて、ステート ダイアグラムまたはフロー チャート内に内部イベント シーケンスを表示することがよくあります。
相互作用があまり複雑ではなく、 whenの代わりに誰が何を、なぜ行うかという点でより興味深いいくつかの小さなオブジェクト グループがある場合は、わずかに変更されたクラス図を使用できる可能性があります。多くの場合、フロー チャート、状態図、またはシーケンス図よりも便利です。
また、場合によっては、図がまったく役に立たないことにも注意してください。例を示す短いテキストを書いたり、表に情報を集めたりする方がはるかに役立つ場合があります。プログラムが何をどのように行うのかという概念を読者が理解したときに、ドキュメンテーションは完成します。それ以外の場合は、常にソース コードがあります。