以下就我能够回答的来讨论.... 有些问题对我而言有些深奥，所以不知道怎麽回覆 ※ 引述《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