[技術討論]再談新概念的建立和應用

北京-FireSpider 男  20:16:32

清潤老師，請教您個問題：業務場景指的是業務流程嗎？

青潤  20:16:51

應該不是。

北京-FireSpider 男  20:19:25

我看業務場景活動圖，怎麼感覺根業務流程圖是一樣的。

青潤  20:19:56

業務場景活動圖？怎麼又一個新概念？

青潤  20:21:01

業務流程圖就是流程圖，業務場景活動圖，呵呵，如果這麼說，兩者應該是同等的。

只是，國人創造概念的心思怎麼比解決問題強烈那麼多？

北京-FireSpider 男  20:21:19

比如這個

青潤  20:22:03

我想強調一點，3這張圖有嚴重的錯誤。

在我剛剛寫的那篇文字中，對時序圖的來源進行了分析，騰訊的內部培訓材料裡，關於這部分也是完全錯誤的。

雖然還有一些爭議，但是，我這次的論證應該足夠豐富了。

北京-FireSpider 男  20:22:56

哦

青潤  20:23:11

5.9.8 Sequence Diagram在需求階段的錯誤使用

這是一個可能有爭議的話題，不過，考慮了很久後還是決定放在這裡。

Use Case的闡述中使用Sequence Diagram，把設計模型中的常用表示圖用在了需求分析階段！這樣的跨階段使用完全是違背了時序圖建立的本意和用途的，一般而言，需求階段只需要使用狀態活動圖或者泳道圖，這不是時序圖來進行這樣的細節描述。

另外，需求階段的產物一般而言會要求使用者可以看懂，而使用者一般不會看懂比較專業的時序圖或者協作圖（時序圖和協作圖是可以1v1直接轉換的）的表達方式，只有狀態/活動圖或者泳道圖才適合在需求階段使用。

北京-FireSpider 男  20:23:12

我去看看，在微博裡？

青潤  20:23:19

即使在2008年筆者曾經提供給西安楚凡使用的Use Case闡述模型化的表示方法中，也只是用到了泳道圖就解決了這個問題，而不需要使用時序圖來表達。

另外，現在確實有很多書籍資料中把時序圖用在需求階段進行需求細化的表示，可是他們確實忘記了，在UML的表述中，時序圖是和協作圖1v1轉換的，如果你使用了時序圖在需求階段，那麼協作圖用於需求階段也應該是可以的，但是，卻幾乎沒有看到過協作圖用於需求階段的例子。

最後，即使是用例細化的過程中，涉及到用例大小度量和數量計算的時候，這個時候往往是需要考慮專案規模的，也就是需要度量開發週期的時候，用例的大小度量和數量的基礎，用狀態/活動圖以及泳道圖中的元用例/活動/狀態作為基礎進行計算是一個非常方便的方法，而在時序圖中則很難找到合適的對應關係。

另外， Sequence diagram應該是來源於Rumbaugh的OMT方法中的動態模型和Jacobson的OOSE方法的時序圖，在 OOSE方法中時序圖是設計模型階段的組成部分，並不是需求階段使用的。在OMT方法中的動態模型中強調：“動態模型描述與時間和操作順序有關的系統特徵——激發事件、事件序列、確定事件先後關係的狀態以及事件和狀態的組織。”因此也是屬於分析設計階段的內容，不是需求階段的表示方法。

雖然筆者有過一些關於用法上不拘一格的觀點，但是，凡此種種，至少到目前為止，並沒有必須把時序圖用於需求階段的鐵證。因此，筆者還是建議在需求階段或者說在任何階段都不要信手拿來主義，把其他階段的表示法拿來就用，這是不合適的。

這段話我貼過來。

北京-FireSpider 男  20:23:47

好的，我看看。

青潤  20:23:49

這是騰訊培訓資料中的。

即使在RUP裡面也從來沒有出現時序圖在用例模型階段出現的例子。

國人的創造能力不可謂不豐富，但是，不分來源的，把鞋非要放在腦袋上當帽子，這實在有點過分了。

北京-FireSpider 男  20:32:08

嗯，聽老師這麼一說，感覺茅塞頓開。

北京-FireSpider 男  20:33:20

看各類資料，技術概念太多，我現在感覺有點亂了，呵呵。

青潤  20:33:43

UML是語言，語言是表達的工具，必須表達恰當才可以。

工具必須在適合的環境用。

舉個不一定恰當的例子，在家裡很多老人罵自己的孩子是龜兒子，龜孫子。你如果出門用在別人家孩子身上，你看人家是否和你拼命。

北京-FireSpider 男  20:34:54

呵呵，是的。

青潤  20:35:05

環境，必須用得恰當。

上面那個語言的例子就是說要用在恰當的環境中，不能隨便拿來就用，的確，這也表示了同樣的意思，但是不能想用就用呀。