作者tinlans ( )
看板OOAD
標題Re: [問題] 大型系統用 use-case driven 來 modeli …
時間Sat Oct 20 16:35:15 2007
※ 引述《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 (
[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 16:41)
1F：推 seLain:可以請問一下你們 team 用的 process model ? 10/20 19:56
2F：→ seLain:是 RUP 嗎 ? 因為看文章一直提到, 另外, 10/20 19:57
3F：→ seLain:你認為 leader 是很了解 RUP 且很有信心地在使用, 10/20 19:57
4F：→ seLain:或是感覺像是為了 OO 或是 UML 而使用 RUP ? 10/20 19:58
5F：→ seLain:另外, use case 的問題, 就我所知目前沒有你可能想要的 10/20 19:58
6F：→ seLain:明確的寫法或是規則. 但是我個人時時記得的一個大原則是 10/20 19:59
7F：→ seLain:OO process 的最重要特點之一在於把持適當的 abstraction 10/20 20:00
8F：→ seLain:往往當 use cases 寫的太細時, 曝露了很多不必要的 details 10/20 20:00
9F：→ seLain:使得後續的 design variation 減少, 這可不是好事 10/20 20:01
10F：→ seLain:太過詳細的 use cases 會使得 architect 沒有空間做事 10/20 20:01
11F：→ seLain:所以基本上我寫 use cases 時, 所有 actors 只由 10/20 20:02
12F：→ seLain:context diagram 而來 (幾乎...應該還沒有例外過) 10/20 20:02
13F：→ seLain:所以上述的一些寫法對我來說其實有些...難以理解 10/20 20:04
14F：→ seLain:修正某一句 : 在適當的 level 把持適當的 abstraction 10/20 20:04
15F：推 seLain:還有前述對於 UI 的說法我也不太能接受... 10/20 20:06
16F：→ seLain:我之前有從 UI design 的角度整理過 use cases 寫法 10/20 20:07
18F：推 PsMonkey:為甚麼不回文..... 10/21 00:14
19F：推 tinlans:是 RUP 的變形，因為每個 leader 都不會想完全遵循 RUP， 10/21 07:01
20F：→ tinlans:所以讓我一直很好奇完全照 RUP 走的話哪些是對的。 10/21 07:01
21F：推 tinlans:真要回答第三行的話，應該說 leader 對自己那套很有自信.. 10/21 12:28
22F：推 seLain:ok, thank you. 請原諒我沒有直接回文, 因為我沒有意思 10/21 16:06
23F：→ seLain:參與此 thread 後續討論, 如果回文後又有人回, 就沒辦法 10/21 16:07
24F：→ seLain:假奘沒看見 :p 10/21 16:07
25F：推 H45:有人回你的推文，你也沒辦法假裝看不見吧.... 10/22 03:05
26F：推 godfat:不是每個人都會一直回頭看推文吧 10/22 14:05