[軟體工程]從概要設計與詳細設計的關係談起到業務用例和元用例的展現

以下討論來自“理論與推演”群中的對話。

 

2013-01-31

北京-FireSpider 男13:28:45

青潤老師，請教個問題：軟體架構設計和軟體概要設計是什麼關係？

青潤14:20:25

概要設計是從需求延伸的，架構設計著眼於系統整體的邏輯實現。著眼角度不同。

北京-FireSpider 男 14:27:29

哦，那也就是說，概要設計不涉及系統實現的問題嗎？

青潤 14:27:54

概要設計是分模組進行的，架構設計是需要考慮所有模組的。

青潤 14:28:24

起始點不同，考慮的範圍也不同，另外，概要設計一般是需求的進一步細化，在我的書中稱之為半數字化的設計。

青潤 14:28:32

詳細設計才是完全數字化的設計。

青潤 14:28:54

也就是說，架構設計在概要設計的時候開始起作用，但是完全起作用要在詳細設計的時候才有。

北京-FireSpider 男 14:29:16

哦。

青潤 14:29:48

如果你看了我書中對應的部分，可以看到概要和詳細設計的區別，很明顯，也很明確。

北京-FireSpider 男 14:30:29

是不是可以這樣說：概要設計對應用例分析階段，與系統實現無關，也就與架構設計無關了。而詳細設計階段對應用例設計階段，因為與實現有關，因此就與架構有關了。

青潤 14:31:02

這個說法是不對的。

青潤 14:31:13

沒有用例設計階段。

青潤 14:31:26

針對uc的設計就是從概要設計到詳細設計，推進下去的。

青潤 14:32:03

概要設計，一般來說，是簡單的mvc劃分，詳細設計的時候會增加一些具體細節的設計模式和一些具體設計方法的應用。

北京-FireSpider 男 14:33:49

用例設計改為用例實現的說法呢？

青潤 14:36:24

沒聽說過。

青潤 14:36:44

用例實現是說：use case realization這個關係嗎？

青潤 14:37:57

如果是這樣的話，我認為的這個說的是：業務用例到系統用例的對應實現關係。

也就是說，哪些業務用例是需要在本次開發中實現的，就會轉換為對應的系統用例儲存下來，其他的uc都將被規划到以後的開發中或者不實現

北京-FireSpider 男 14:37:58

我也有點糊塗。很多書上的系統分析設計都是基於系統用例的。現有用例分析，然後就是設計，難到設計不是針對用例的？

青潤 14:38:39

設計必須是針對用例的，所以很多書中都跨越了這一段，因為他們說不清楚。

青潤 14:39:00

我的書中的需求階段中對此有很詳細的介紹，我可以給你一個做說明。

北京-FireSpider 男 14:39:19

好的

北京-FireSpider 男 14:39:33

您的書，今天我忘帶了，所以沒法看到。

青潤 14:42:16

青潤 14:42:34

我才注意到，書中並沒有針對這一段內容的介紹，是培訓中講過的內容。

北京-FireSpider 男 14:42:48

嗯

青潤 14:43:02

業務用例，到系統實現的用例之間會有一個處理過程，這個過程決定哪些使用者提出的需求直接實現。

青潤 14:43:19

buc和uc之間是m：1或者1：m的關係

北京-FireSpider 男 14:43:29

嗯

青潤 14:43:37

基本不會有M：N的關係，也就是不建議存在buc拆分的問題。

青潤 14:44:39

青潤 14:44:48

這張圖基本上覆蓋了這些情況。

青潤 14:45:08

前面說錯了，應該是buc到uc之間是M：1的關係。

北京-FireSpider 男 14:46:51

哦，是這樣。

青潤 14:47:28

這張圖是06年給總參培訓時候的一張圖，因為不涉及機密，可以使用。

北京-FireSpider 男 14:48:56

我想想，這一塊我好想還是存在理解誤區。

青潤 14:49:06

嗯。

北京-FireSpider 男 14:56:13

這種buc和uc之間的映射關係，應該是指包含子buc的buc，對吧。因為一個粒度比較大，還包含很多子buc的buc，它可能因為子buc映射為多個uc而表現出：一個buc對應多個uc的情況。

青潤 14:57:00

其實這裡面buc完全可以做成我的元用例的概念。

北京-FireSpider 男 14:57:13

嗯

青潤 14:57:17

做的非常細，細到無法再分割，然後進行組合，形成實際的uc。

北京-FireSpider 男 15:05:52

這個是請假業務的流程圖：

北京-FireSpider 男 15:07:18

如果把請假表示為一個業務用例的話，它下面的處理節點也算作業務用例。就會出現：請節業務用例包含“填寫請假申請單”、“部門經理審批”、“總經理審批”、“行政歸檔”四個子業務用例。

北京-FireSpider 男 15:07:56

從“填寫請假申請單”、“部門經理審批”、“總經理審批”、“行政歸檔”直接建立系統用例，得到系統用例：填寫請假申請單”、“部門經理審批”、“總經理審批”、“行政歸檔”。

北京-FireSpider 男 15:08:33

同時，請假也直接建立一個系統用例。這樣就會出現：請節系統用例包含“填寫請假申請單”、“部門經理審批”、“總經理審批”、“行政歸檔”四個子系統用例。

北京-FireSpider 男 15:14:32

是不是就是這樣的呢？

北京-FireSpider 男 15:14:28

北京-FireSpider 男 15:15:46

北京-FireSpider 男 15:15:55

畫錯了。

北京-FireSpider 男 15:16:10

北京-FireSpider 男 15:16:38

請假系統用例與這幾個業務用例的關係是不是就可以認為是：多個業務用例對應一個系統用例呢？

北京-FireSpider 男 15:16:55

北京-FireSpider 男 15:17:07

而這裡是不是可以認為是：一個系統用例對應一個業務用例呢？

青潤 15:57:34

關於這個問題，你應該去看一下我元用例概念的定義和解析。

青潤 15:58:01

請假這個業務用例之下的各個用例是否已經無法拆分，如果可以拆分就可以繼續拆，直到成為元業務用例為止。

青潤 15:58:36

而用例必須是合理的，也就是說，必須是多個元用例的組合。

元業務用例和元用例可能是1：1的關係，目前這個問題還需要深入的進行一下邏輯分析才能確定是否都是1：1的關係。

北京-FireSpider 男 16:01:49

關於元用例，我覺得必須配合介面原型才能知道，憑著大腦去推演，好像挺難，有時只管的表示一下子就能判斷出來。

青潤 16:02:14

這個完全不需要

青潤 16:02:27

元用例的建立本來是為了進行用例規模度量的。

青潤 16:03:01

也就是用於用例複雜度計算，同時可以評估開發工作量的，後來我把它延伸到進行需求的完整實現的細節上。

北京-FireSpider 男 16:07:54

“元業務用例和元用例可能是1：1的關係”，如果多個“元業務用例”對應一個“元用例”是不是可以認為“元業務用例”還需要進一步拆分呢？

青潤 16:08:18

是不是說反了？呵呵

青潤 16:08:26

應該是元用例還需要進一步拆分。

北京-FireSpider 男 16:08:35

哦，對，呵呵。

青潤 16:08:38

一般來說元業務用例對元用例就是1：1

青潤 16:08:55

而且元用例就是元業務用例推到過來的，這個過程不需要進行合并。

北京-FireSpider 男 16:08:56

嗯

青潤 16:09:17

而往往系統沒有那麼複雜的時候就不需要太多元用例的概念，直接用元業務用例映射過來組合成用例即可。

青潤 16:09:25

沒必要把簡單的事情也分幾個步驟來操作。

青潤 16:09:36

否則，就是自己把自己複雜化了。

青潤 16:10:00

所以，一般來說不存在這個假設，只有可能是元業務用例過於複雜，並不是最小化的，所以，需要考慮拆分。

青潤 16:10:30

也就是說，在流程圖中如果某個活動還有子項活動的時候，那就需要考慮這個活動的拆分，形成更多的元業務用例，否則是不需要考慮的。

北京-FireSpider 男 16:12:44

您前面圖的，“公文撰寫”和“發送EMAIL”兩個業務用例，實際上在系統實現上，“發送EMAIL”可能是內建的，就是在“公文撰寫”完畢並提交，自動發送EMAIL。這樣的話，就是多個業務用例對應一個系統用例了。

青潤 16:13:15

對，多個業務用例對應一個系統用例，這是很常見的。

青潤 16:13:35

業務用例可以討論的很細，甚至直接到達元用例的層級。

北京-FireSpider 男 16:13:43

嗯

北京-FireSpider 男 16:14:27

呵呵，好像很需要動腦筋思考商務資訊化的事情啊。

青潤 16:14:46

呵呵。

北京-FireSpider 男 16:14:46

不同的人，可能做出不同的分析出來。

青潤 16:15:01

這裡面才能分割出來，那些需要系統實現，哪些不需要。

北京-FireSpider 男 16:29:56

需要拆分業務用例的，我覺得這涉及業務重構了。

青潤 16:30:15

也可能是業務重構，也可能是業務調研不清楚。

北京-FireSpider 男 16:30:32

需要將一個業務用例映射為多個系統用例的，應該是涉及業務重構了。

北京-FireSpider 男 16:30:39

嗯

青潤 16:30:56

其實，大概有三分之一的使用者需求變化責任在程式員身上，是因為不瞭解使用者業務或者沒有調研清楚造成的結果。

北京-FireSpider 男 16:32:42

嗯，很有可能。

青潤 16:33:13

不是很有可能，是事實，呵呵。只不過，程式員涉及到自身，不願意承認而已。

青潤 16:33:21

我們不是神，不是所有的需求都能理解的。

青潤 16:33:29

需要過程，需要時間。

青潤 16:33:38

理解錯誤，也在所難免。

北京-FireSpider 男 16:33:42

但比如我們現在做的石油管線巡檢，原始業務是管道管理員給巡線員埋紙條，讓巡線員去找紙條，以此作為考核指標。但上GPS巡線後，業務方式完全發生變化了。

青潤 16:33:52

只不過，我們處於行業內，難免想要給自己做一些掩蓋。

北京-FireSpider 男 16:33:55

雖然營運目標一致，但是業務實現方式完全不同了。

北京-FireSpider 男 16:34:06

這時的業務節點，其實就需要重構了。

青潤 16:34:17

這屬於業務改革，那就是另外的事情了。

北京-FireSpider 男 16:34:22

嗯

北京-FireSpider 男 16:54:23

多謝清潤老師的耐心講解。青潤 16:54:35

不客氣。