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：是不是實務上出現這種狀況也能被接受呢？）
: 有書會主張用 package 包住 use-case，
: 然後讓 actor 跟整個 package 建立 association，
: 表面上看起來似乎是一種解決的方法，
: 可惜並沒有見過具體的例子是這麼做的。
======
很抱歉, 用問題發問與討論問題. 對這行不是那麼熟練, 但分析與合成
的設計方法, 各行各業是很通用的.
1.use-case 顧名思義是 "案例", 案例就是整包的.
2.functional decomposition 是假設功能有原始與基本的成員, 這種
基本成員是基本組成, 被假設成 "不該再被分割", 因此大塊功能可
以被分解成基本成員與其間的連繫關係, 基本成員則是可複製可再
應用.
3.稱為案例, 就表明是特殊狀況(不是通則), 也是會有組成的成員及其
因 "特定"關係 組成的 "特異"功能, 這是從組件往上打包成一團的
思惟, 因為案例可能就不是基本(或基礎)成員, 但反正就是不想再細
分先將就湊合著用. 案例的基本成分是跟要組織成整個功能系統的基
本成員在本質或特性上, 有可能有所不同, 因此, 暫不先強求要由基
本成員組成. 案例的特異功能應該是有特殊不同的成員或異常的連繫
所造成的, 這種特異成份顯然是無法由基礎成份所組成.
實例: 物質由原子組成是中性不帶電的, 這種原子組成的物沒有電磁場
也沒有放射性. 但帶有電荷或移動電子組成的物質, 或是會自動
崩裂的物質則是特異的, 要合成後者, 不能用前者的基本原子組
成. 後者就是案例.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.115.1.146
討論串 (同標題文章)
OOAD 近期熱門文章
PTT數位生活區 即時熱門文章
-4
30