大部分讲 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)