作者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