Re: [問題] 大型系統用 use-case driven 來 modeli …
以下就我能夠回答的來討論....
有些問題對我而言有些深奧，所以不知道怎麼回覆
※ 引述《tinlans ( )》之銘言：
: 大部分講 UML 和 OOAD 的書都會說：
: 設計 use-case diagram 的時候要避免採用 functional decomposition 的方式
: 很普遍的惡例就是 actor 跟一個 use case 有 association，
: 然後再由那個 use case 放射狀 ----<<include>>---> 到一堆 use cases，
: 然後巢狀延伸不斷一層接一層的 include 下去，
: 變成樹狀結構。
: 但是在幫大型系統 modeling 的時候，
: 不管怎樣似乎都會被帶進 functional decomposition 的狀況，
: use-case 寫來寫去都會不小心變成 tree 狀，
: 一路殺到 actor 根本不需要知道的深度去。
: （問題 1：是不是實務上出現這種狀況也能被接受呢？）
雖然實務上寫到太深入的細節，對於 Designer, Coder 有些幫助
但是如你所說的，這個 use-case diagram 不會是以 actor 的角度來看系統
反而是以 system 的角度來看功能了！
這樣的 use-case diagram 在搞錯需求或是需求變更的時候特別麻煩
因為 system 的細節都已經畫在 use-case diagram 上面
而那些 actor 真正關心的「大功能」很容易失焦
use-case diagram 因此而改來改去恐怕不是一件好現象。
反之，如果確信 use-case diagram 沒有畫錯，當然可以這麼做....
: 有書會主張用 package 包住 use-case，
: 然後讓 actor 跟整個 package 建立 association，
: 表面上看起來似乎是一種解決的方法，
: 可惜並沒有見過具體的例子是這麼做的。
: （問題 2：不知道這種做法究竟可不可行？有板友嘗試過嗎？）
這樣做只是多畫一個框框罷了。
package 一般拿來包住兩個或多個 sibling use-case
而不太會拿來包住一個 use-case 和其 extend, include 的 use-case
如果是那種又長又深的樹狀 use-case diagram, 可不是 package 有辦法救得了的。
: 以前在外面跟 team 做 project 時，
: 用的是 rational 的 CASE tools，
: 然後 tool 裡的 use-case model template，
: 會提示說先用 package 分割出所謂的 functional areas，
: 然後每個 functional area 再獨立一張 use-case diagram，
: 上層再來一張簡明扼要的 use-case overview diagram；
: （問題 3：這種做法是正規的方式嗎？還是說只是一種撇步？）
我不知道正不正規，但是看你的敘述之後
這應該是指「多層」的 use-case diagram 吧？
他不畫成又長又深的「樹狀」 use-case diagram
而是先把「大功能」畫成一張 use-case overview diagram
再把每個「大功能」另外畫一份描述「小功能」的 use-case diagram
我不敢保證這麼做是不是好，但是個人覺得這個 sense 很棒。
但是話又說回來....
「問題 1.」的 tree-like use-case diagram 也只是把這一種的 use-case diagram
畫在同一張圖上面吧？
以這個角度來看，這兩張圖是很類似的。
: 我看我們 SA 一開始都是做傳統的需求分析，
: 交給 architect 切完 functional areas 之後，
: 才開始用 use-case 做分析。
: 但是這樣一層一層切會有兩個主要問題：
: 1. 一路爬到系統中下層的 package (functional area) 時，
: 扮演 actor 的物件會越來越弔詭，
: 已經不是書上常看到的那種「人」或「外部系統」了。
: （問題 4：是不是說 use-case 不該被用在這麼下層呢？）
也許 actor 會變， system 也會變 (笑)
我覺得上面那種「多份」型 use-case diagram 就不太容易有這個問題
每一份 use-case diagram 參與的 actor 可以不完全相同。
舉例而言，雖然最上層的 use-case diagram 裡面有一個 actor 是 user
但是在最下層的 use-case diagram 的 actor 也許是 system controller
換言之，在底層的 diagram 不一定是 user 使用 system
反倒是自己系統的某一部分使用自己系統的另一部分
好比說 thread controller 使用 connection behavior
: 2. 根據 rational 講的那套 analysis class 分類法，
: 也就是分成 boundary、control、entity 這三種的方法，
: boundary 一般被解讀成 UI 相關的 classes，
: 所以下層 package 的 analysis classes 都只出現後兩種。
: （問題 5：究竟在 use-case 邊界上但與 UI 無關的 class 算不算 boundary？）
我不了解 use-case 邊界上但與 UI 無關的 class 是指什麼？
: 而當時這位 SA 的主張是，
: 當拿到一個現成的大型軟體系統 source code，
: 而只打算新增一個 subsystem 到裡面去，
: 或是修改/擴充某個 subsystem 時，
: 習慣上述 1. 的情況會很方便進行分析。
: （問題 6：當遇到他所說的這種需求時，真的只有這種解法嗎？）
否。
我猜想你會這樣問，心中應該已經有答案了吧？
: 也曾經在其它 team 裡有 SA 抱持著不一樣的做法，
: 他強調 use-case model 就是給 stakeholder 看的，
: 所以只有要講給他們聽懂的最上層使用 use-case，
: 找 analysis classes 時也只是挑出非常大而粗糙的 classes，
: 用一些很含糊的 interaction diagram 和 state machine diagram 等等的圖帶過；
: 在 design 時才交給 architect 和 SD 大動作切割 functional areas，
: 而有些 analysis class 會變成一大個 subsystem 或是 component。
: （問題 7：這種做法看似循序漸進而正規，但遇上問題 6 的狀況時不知該如何應付？）
我個人的認知是：
問題 7 和 問題 6 的狀況不太一樣，所以適合的解決辦法也不太一樣。
假如我今天要開發的是一個獨立的新系統
那麼最好先弄清楚「客戶」的「需求」是什麼
為了讓「客戶」能夠了解我們系統的功能
畫出最精簡而且能夠涵蓋整個系統的 use-case diagram 才不會失焦
「客戶」並不需要知道「細節」有哪些，只要確定我們所認知的需求和客戶的相同即可。
這個時候，用循序漸進的方法可能會好一些。
以上是我個人的看法。
: 這些問題可說是長年以來的疑惑，
: 敘述的部分可能真的有點冗長，
: 問題可能也太多，
: 不過還是請熟悉這方面的板友不吝賜教了，
: 如果能介紹用 UML 來 modeling 大型軟體系統的書也是非常歡迎，
: 這種書真的找很久了，
: 但是書上範例的規模都沒有想像中的大，
: functional area 只切一層就搞定的範例實在很難解釋我的疑惑。
: 順便列一下還算新又讀過的書以免重複 (OOAD 全名太長直接簡寫)：
: 1. O'Reilly 的 Head First OOAD
: 2. O'Reilly 的 Learning UML 2.0
: 3. O'Reilly 的 UML 2.0 in a nutshell
: 4. Addison-Wesley 的 UML 2 And The Unified Process 2/e
: 5. Course Technology 的 OOAD with the Unified Process
: 6. IBM Press 的 Project Management with the IBM Rational Unified Process
: 7. IBM Press 的 Implementing the IBM Rational Unified Process and Solutions
: 8. IBM Press 的 Visual Modeling with IBM Rational Software Architect and UML
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.116.247.13
討論串 (同標題文章)
OOAD 近期熱門文章
PTT數位生活區 即時熱門文章
0
18
