大部分講 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：是不是實務上出現這種狀況也能被接受呢？） 有書會主張用 package 包住 use-case， 然後讓 actor 跟整個 package 建立 association， 表面上看起來似乎是一種解決的方法， 可惜並沒有見過具體的例子是這麼做的。 （問題 2：不知道這種做法究竟可不可行？有板友嘗試過嗎？） 以前在外面跟 team 做 project 時， 用的是 rational 的 CASE tools， 然後 tool 裡的 use-case model template， 會提示說先用 package 分割出所謂的 functional areas， 然後每個 functional area 再獨立一張 use-case diagram， 上層再來一張簡明扼要的 use-case overview diagram； （問題 3：這種做法是正規的方式嗎？還是說只是一種撇步？） 我看我們 SA 一開始都是做傳統的需求分析， 交給 architect 切完 functional areas 之後， 才開始用 use-case 做分析。 但是這樣一層一層切會有兩個主要問題： 1. 一路爬到系統中下層的 package (functional area) 時， 扮演 actor 的物件會越來越弔詭， 已經不是書上常看到的那種「人」或「外部系統」了。 （問題 4：是不是說 use-case 不該被用在這麼下層呢？） 2. 根據 rational 講的那套 analysis class 分類法， 也就是分成 boundary、control、entity 這三種的方法， boundary 一般被解讀成 UI 相關的 classes， 所以下層 package 的 analysis classes 都只出現後兩種。 （問題 5：究竟在 use-case 邊界上但與 UI 無關的 class 算不算 boundary？） 而當時這位 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 的狀況時不知該如何應付？） 這些問題可說是長年以來的疑惑， 敘述的部分可能真的有點冗長， 問題可能也太多， 不過還是請熟悉這方面的板友不吝賜教了， 如果能介紹用 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 -- Ling-hua Tseng ([email protected]) Department of Computer Science, National Tsing-Hua University Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design Researching: Software pipelining for VLIW architectures Homepage: https://it.muds.net/~uranus --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.230.216.166 ※ 編輯: tinlans 來自: 61.230.216.166 (10/20 10:59)