2017-07-19 18 views
0

私は、自分のアプリケーションで行われたWebサービス呼び出しを文書化するためのシーケンス図を作成するように求められました。Webサービスコールのシーケンス図の良い例は?

私は実際にシーケンス図を理解していません。彼らは読みにくいです。たくさんの行がありますが、たくさんのテキストはありません。例えば、私のアプリケーションが特定のサービスを呼び出し、一連のデータを渡して別のデータセットを取得したことを示す場合、このデータをすべて表示するには、ラインアウトとラインバックに十分な余裕がありませんそれがGETまたはPOSTであることを指摘し、この情報がなければ、ダイアグラムはあまり役に立たないという点では最小限に抑えられています。私は、テキストファイルやwikiにこれを書いておくほうがずっと簡単です。しかし、私は普及しているシーケンスダイアグラムがどのようになっているかを見ているので、私はそれらを「得る」わけではないと思う。

だから私は今3つの質問を持っている:

(1)誰かが私のWebサービス呼び出しのためのシーケンス図のいくつかの特に良い/有用な例を示すことができるので、私はこれが正しく行われているか確認できますか?

(2)フローに異なるWebサービスコールが発生するロジックパスが異なる場合、単一のシーケンス図でif/then/elseでこれらを表現するか、可能性ごとに異なるシーケンス図を作成する必要がありますか?

(3)シーケンス図はUMLに基づいていますが、UMLはどのように「言語」ですか?それはテキスト表現ではありません。それは流れ図のような何かを図式化するより多くの方法のようです。

答えて

2

あなたの場合のシーケンス図の目的は、特定の情報を同僚(または将来の自己)に伝えることです。この答えを書き込むための最良の方法がないのと同じように、「最良の」方法はありません。私はすでにこの答えに言い直しています。そして、1年後に私の答えを再読したら、私はおそらくそれをもう一度言い換えて、もっと明確にするでしょう。

ここでも図は同じです。シーケンスダイアグラムの目的を理解していると仮定してダイアグラムを自分で理解できない場合、他の人もそれを理解しません。

たぶん、あなたのケースでは、このようなものが

enter image description here

を十分可能性が第一の通信上の焦点は、後に仕様をUMLする「適合」であることを心配。

(3)手話をテキストの代わりに使用しても、手話を言語と見なしますか?

同様に、UMLにはさまざまな概念を表す視覚的要素の「語彙」があります。ライフラインとメッセージのシーケンス図は、アクター(クラス)間の一連の通信を表します。また、ダイアグラムにメモを追加して、意図を明確にすることもできます。

(2)あなたは両方を行うことができます。繰り返しますが、決定的な要因はコミュニケーションの明確さです。単一のダイアグラムがあまりにも混乱している場合は、それを分解し、別のダイアグラムを作ります(ちょうどあなたがメソッドとクラスを分割するように)。経験則は、図全体で同じレベルの抽象化を維持することです。突然実行時の詳細に突入すると、非常に迅速に混乱する可能性があります。

(1)最初に、ダイアグラムの「語彙」を学ぶことをお勧めします。uml-diagrams.org、次に何かを描き、あなたがそれを理解しているか、他の人がそれを理解しているかどうかを確認してください。あなたがそれをより良く言い直すことができると思えば、図を投げ捨てるのを恐れないでください。

このすべてのデータ

を表示するために戻って出て行と行に十分なスペースがツーリングの問題のように聞こえるがほとんどありません。もっと離れて線を置くか、PlantUMLのようなものを使ってください。 (または実際のUMLツールを使用します。)

図は、次にそれを分割、テキスト注釈を追加し、それを豊か

非常に有用ではないのポイントに最小限のです。ある点のみを説明するために部分のマニュアルを使用してください。唯一のドキュメンテーション・アーティファクトとしてダイアグラムを使用する必要はありません。

関連する問題