Re: [問題] 大型系統用 use-case driven 來 modeli …

看板OOAD作者tinlans ( )時間17年前 (2007/10/20 16:35)推噓8(8推 0噓 18→)

留言26則, 5人參與討論串3/4 (看更多)

※ 引述《H45 (!H45)》之銘言： : : （問題 3：這種做法是正規的方式嗎？還是說只是一種撇步？） : 我不知道正不正規，但是看你的敘述之後 : 這應該是指「多層」的 use-case diagram 吧？ : 他不畫成又長又深的「樹狀」 use-case diagram : 而是先把「大功能」畫成一張 use-case overview diagram : 再把每個「大功能」另外畫一份描述「小功能」的 use-case diagram : 我不敢保證這麼做是不是好，但是個人覺得這個 sense 很棒。 : 但是話又說回來.... : 「問題 1.」的 tree-like use-case diagram 也只是把這一種的 use-case diagram : 畫在同一張圖上面吧？ : 以這個角度來看，這兩張圖是很類似的。是蠻類似的，但是有一點那種刻意為了避開樹狀 use-case，而造出樹狀 package 結構，再來逐層寫 use-case 的味道在，造成就算通通畫到同一個圖上，不同層次間的 use-cases 也不會有線連接在一起，說真的我也不清楚這麼做是好是壞，因為另一位 SA 強調 use-case diagram 只是給 stakeholder 理解用的。採用這套的 SA 是強調 use-case specification 的撰寫，也就是比較偏重詳細的文字敘述，主要理由是 use-case specification 裡會有 main flow 和 alter. flows 的欄位，這裡若使用純文字搭配簡單的 S + V + O 句型撰寫的話，可以方便進行 textual analaysis 以找出 candidate classes 和 candidate methods；而如果像是另一位 SA 的那種做法，就會在離開 system 表層部分後就失去進行 textual analysis 的機會，因為他強調之後找 class/method 的方法都是畫各式各樣的圖來抓，而不是特別強調從文字裡面挑。 : : （問題 5：究竟在 use-case 邊界上但與 UI 無關的 class 算不算 boundary？） : 我不了解 use-case 邊界上但與 UI 無關的 class 是指什麼？就 rational 相關書籍的說法，所謂 control class 是指 execute 一個 use-case 的 class，也就是內部包含了 use-case specification 所寫的 flows，而 UML 的書大都會說：use-case 必須是由 actor 引發，這時在比較上層的 analysis model 中，就會看到 actor ---> boundary class ---> control class 這種關係，也就是 user ---> UI class ---> control class；但是當寫到系統下層的時候，會有一個方便 actor (大系統內部的其它元件) 啟動 use-case 的 class，它的相對位置剛好落在上面 UI class 的位置 (但並不是 UI)，這種 class 就不知道該不該稱之為 boundary class；我看過有的 SA 一律把這種 class 當成 control class， boundary class 絕對要是 UI，所以離開系統上層之後， analysis model 就只會出現 control 和 entity classes；但是有些 SA 會一樣把它當成 boundary class，所以我一直搞不清楚哪種做法是正確的 (因為牽涉到 RUP 所以應該有正確性問題)。 : : 而當時這位 SA 的主張是， : : 當拿到一個現成的大型軟體系統 source code， : : 而只打算新增一個 subsystem 到裡面去， : : 或是修改/擴充某個 subsystem 時， : : 習慣上述 1. 的情況會很方便進行分析。 : : （問題 6：當遇到他所說的這種需求時，真的只有這種解法嗎？） : 否。 : 我猜想你會這樣問，心中應該已經有答案了吧？不好意思問得不是很清楚，可能應該補上一句「如果有其它解法的話，那又是怎麼做呢？」會這樣問的原因，的確是認為可能存在其它以 use-case driven 為前提的做法，不過說真的並沒有看過實際的例子是如此進行，所以也沒辦法非常確定。因為除了這個 team 會為這種事慢慢搞 OOAD 外，其它 team 幹這種事情都是傳統的土法煉鋼，也就是根本不管什麼 OOAD 直接硬上亂搞，以改到會動就交差了事的前提下進行工作，導致我在這方面的見識實在是比較淺薄。 -- Ling-hua Tseng (uranus@it.muds.net) 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 16:41)

推