我被要求創建一個序列圖來記錄我的應用程序所做的Web服務調用。Web服務調用序列圖的好例子？
我真的不明白順序圖。他們很難閱讀 - 很多線條，而不是很多文字。例如，如果我想表明我的應用程序調用特定服務，傳遞一組數據並獲取不同的數據集，則線路上沒有足夠的空間，並且返回的行顯示所有這些數據並指出它是一個GET或一個POST，沒有這些信息，這個圖就是極簡主義的，因爲它不是非常有用。我發現在文本文件或wiki上記錄像這樣的東西要容易得多。但是我看到了序列圖的流行程度，所以我認爲我不會'獲取'它們。
所以我有三個問題現在：
（1）可有人告訴我要Web服務調用的序列圖的一些特別好的/有用的例子，所以我可以看到如何做到這一點嗎？ （2）當一個流程有不同的邏輯路徑導致不同的Web服務調用時，我應該用if/then/else在單個序列圖中表示這些代碼，還是爲每種可能性創建不同的序列圖？ （3）我明白序列圖是基於UML的，但UML是一種「語言」？沒有文字表示，對吧？它似乎更像是一種繪製某種東西的方式，如流程圖。
在你的案例序列圖的目的是傳達某些信息給你的同事（或未來的自我）。實際上沒有什麼「最好」的方法來處理它，就像沒有最好的方法來寫這個答案一樣 - 我已經重寫了這個答案，如果我要在一年內重新閱讀我的答案，我可能會再次將它重新說清楚一點。
這裏的圖表也是如此;如果你自己不瞭解圖（假設你理解序列圖的目的），那麼其他人也不會理解它。
也許在你的情況是這樣的可能就夠了
注重溝通第一，擔心被「兼容」後來到UML規範。
（3）即使使用手勢而不是文本，您是否會將手語作爲一種語言？
類似地，UML有一個代表各種概念的視覺元素的「詞彙表」---具有生命線和消息的序列圖表示行動者（類）之間的一系列交流。此外，您可以添加註釋到您的圖表來闡明您的意圖。
（2）你可以同時做。再次，決定因素是溝通的清晰度 - 如果單個圖表太雜亂，那麼將其分解並製作另一個圖表，或多打幾個（就像分割方法和類一樣）。經驗法則是在整個圖表中保持相同的抽象級別 - 突然潛入實施細節可能會非常快速地混淆它。
（1）最好的開始方法是首先學習圖的「詞彙」，例如uml-diagrams.org，然後畫一些東西，看看你是否理解它，或者其他人是否理解它;如果您覺得自己可以更好地「重新說服」，不要害怕丟掉圖表。
那裏幾乎沒有足夠的空間就行了，併線回以顯示所有這些數據
聽起來像一個工具的問題;只需將線條拆開，或者使用諸如PlantUML這樣的東西就可以。 （或者使用一個實際的UML工具。）
圖是簡約到不是非常有用
那麼豐富，添加文字標註的點，把它分解了。使用它作爲文檔部分來說明僅某些點;您不必將該圖用作唯一的文檔工件。