讨论下一个案例

miller3000

最初由 corespeed 发布
[B]thank a lot !你说的非常清楚。。。这和书上强调的是一样的。。。。提出一个小地方在命名时
usercase命名为maintain business rule会不会更贴近意义些能？ [/B]

完全同意你更名的说法。

miller3000

最初由 corespeed 发布
[B]这就是误导我的文档！大家批判下 [/B]

你的文档我大致看了一下，好像是大学课程注册系统。如果就这样简单的系统实现，其实划分的比较细到每一个动作，对于作分析设计也是比较清楚明了的，也未尝不可。但是不能够把它的分析设计作为标准，因为项目和项目毕竟是不同的。在Rational公司的分析案例中也是这个problem statement，但是它的分析好像不是这样的。我有点忘了。

gagaghost

To miller3000:
如果是象您这样说的，那开发用例又怎样解释？
我个人认为：
开发用例时还是需要将用例进行细分！
欢迎扔砖头！！呵呵。

corespeed

我个人的观点和理解是做为usercase是抓大放小，maintain bussiness rule是概括，然后在sequence diagram中体现对象之间的通讯过程。在sequence diagram中可以体现browser、delete\add\等操作。我的观点对吗？

miller3000

其实我认为这样根据实际情况，如果我们有一个statement 是：增加订单、修该订单、删除订单、取消订单和return订单。这时候我们怎么样来抽取case呢？这时候我们就不能够笼统的定义为维护订单。但是我们的系统对用户的管理有增、删、改和取消，我想我们就可以定义为一个case.

corespeed

最初由 miller3000 发布
[B]其实我认为这样根据实际情况，如果我们有一个statement 是：增加订单、修该订单、删除订单、取消订单和return订单。这时候我们怎么样来抽取case呢？这时候我们就不能够笼统的定义为维护订单。但是我们的系统对用户的管理有增、删、改和取消，我想我们就可以定义为一个case. [/B]

其实你谈到的第一种情况和我们前面谈的问题很相近，我觉得是否应该在抽取case，定义成一个维护订单的usercase，然后在后面的
sequence diagram中细画和反映增加订单、修该订单、删除订单、取消订单和return订单呢？
因为在usercase中是在需求分析阶段，应该是取大不取小的哦！

john_zhu

最初由 corespeed 发布
[B]在一个计费项目中，如果涉及优惠处理，有操作员可以定制业务处理规则，如什么时段采用什么优惠规则，
[/B]

这是正确的需求，可以针对这个需求建立用例

[B]同时adminstrator拥有浏览、删除、修改优惠规则等权利，如果是用usecase表示应该如何表示。欢迎大家积极参与讨论。
[/B][/QUOTE]
这是功能的划分，既然功能都已经划分好了，还分什么用例，用例是基于StakeHolder的，而非开发者心中的功能分割！
：（

首先从用户的角度来看，需要将“浏览、删除、修改”进行重新定义，为什么需要这些功能，用户并不是要这些功能，用户要求的是你划分一些功能然后满足他的需求。

miller3000

最初由 corespeed 发布
[B]


其实你谈到的第一种情况和我们前面谈的问题很相近，我觉得是否应该在抽取case，定义成一个维护订单的usercase，然后在后面的
sequence diagram中细画和反映增加订单、修该订单、删除订单、取消订单和return订单呢？
因为在usercase中是在需求分析阶段，应该是取大不取小的哦！ [/B]

同意，我错了。其实他们都是一个用例。当我们在往深处看的时候，其实就是对一个对象的不同动作而已，是不分的。

corespeed

感谢miller3000的指点，通过讨论我已经明确了一些一直以来的困惑！其实这是我已前负责的一个IP计费项目中的很小的一个案例。。。有空我们多交流！

miller3000

最初由 corespeed 发布
[B]感谢miller3000的指点，通过讨论我已经明确了一些一直以来的困惑！其实这是我已前负责的一个IP计费项目中的很小的一个案例。。。有空我们多交流！比较可惜的是竟然没听到斑竹的声音。 [/B]

以后多多交流，我所愿尔。斑竹可能比较忙