(Song) 17:10:46
想问一下青润，在分析模型阶段，最终是要得到什么结果？在一个大系统中，需要针对每个用例做分析模型吗？这一点在你的书中没有提到呀，也许是我看的不认真吧。
(青润) 17:11:10
这一点，我的书中写了。
(青润) 17:11:44
不过，不够明确，这也是另外一个朋友三个月前提出来的。我在我的blog上作了补充修订。你可以去看看。
(青润) 17:12:15
但是，应该可以从书中看出来的。
(Song) 17:12:37
我也是看到了，就是不明白，并且很多用例，虽然业务不一样，但是根据MVC来做分析类和序列图，基本都是一样的描述
(青润) 17:13:06
那是因为没有做业务细分，所以你才会有这种类似的感觉。
(Song) 17:14:41
例如采购入库、销售出库等，的确是不同的业务不同的用例，但是在分析模型中，结合MVC，画出序列图，感觉都是大同小异的。
(Song) 17:15:16
我也知道分析模型阶段需要做，RUP也提到这个过程
(青润) 17:15:27
看起来是相似的。本来分析模型阶段，差别就不是很大，他主要是对用例阐述的需求做了一个直接的拉伸。
可以做一个比方：
不知道这里有没有学过autocad的，那里的三维建模中有一个技术，就是拉伸。拉伸以后，得到的就是简单的三维造型体。这就是分析模型。
然后加上设计模式和业务细分后，得到设计模型，就是在这个简单的三维拉伸造型体上作了更细的雕琢，这个时候，得到的就是设计模型。
(Song) 17:15:44
可是总感觉分析模型阶段很多工作是重复劳动。
(青润) 17:16:47
不要这么认为，每一个用例阐述都是有特点的，不是简单的相似性处理，如果你发现所有的内容都一样，那么，有一个结果你可以知道，那就是：你们的需求肯定没做好！小心后面的反噬。呵呵
(Song) 17:16:55
就是有人想从用例分析直接来做设计模型
(Song) 17:17:12
(Song) 17:17:41
也许是吧，需求阶段都迭代了4、5次了，感觉仍然不够好。
(青润) 17:17:46
呵呵，只要他的系统是显示系统，那么，他会感受到反噬的后果的。
53184236(原来如此) 17:18:01
我觉得关键是对领域的熟悉程度了，
如果很熟悉，直接过渡到设计模型没什么不可以
(Song) 17:18:20
现在我是强制要求他们必须做分析模型^_^
(青润) 17:18:57
任何事物的发展都是有规律的，必须由浅入深，如果你跨越了一些阶段，必然就会忽略一些在那些阶段应该处理的问题。即使再熟悉，你也不可能遇到两个完全一样的系统。
(小亲哥) 17:19:07
^Q^
(Song) 17:19:24
那么，分析模型阶段我最需要关注的是什么方面呢？
(青润) 17:20:35
业务间的区别，业务间的关系，业务的实现流程。主要还是这三个。我说了，分析模型，就是一个三维拉伸效果图，简单，但是，有她的必要性。因为通过做分析模型，你会发现一些用例阐述中被遗忘的内容。
(Song) 17:21:55
谢谢，我下去再好好理解。
另外，你的书中也提到，在分析模型阶段，也有一个分包的过程，怎么着手呢？
(青润) 17:22:10
这要看业务了。
(青润) 17:23:01
不同的业务会有不同的方式，同时还要看你们公司如何看待你们所开发的这个项目，这就是项目的长期规划和短期研发成本间的冲突问题。这就不是一两句话能够说清楚地了。
(Song) 17:23:15
这个包与设计模型阶段的分包是一样的意思吗？它们与导出代码的类层次包是一样吗？
(青润) 17:23:39
是的。一般来说是一样的。
(Song) 17:24:24
非常感谢你，我现在下班要赶回广州了，下周再向你请教几个疑问。
(青润) 17:24:59
没关系，只要我有时间。你这些问题比较有价值，所以，我愿意和你讨论。呵呵
(Song) 17:25:29
好，如果有机会，很想请你来我们公司做一个培训，呵呵
(青润) 17:25:38
可以。那没有问题。
(Song) 17:25:51
再见，我下了
(青润) 17:25:58
好的。再见!
本文地址：http://com.8s8s.com/it/it33611.htm