| 作者 |
内容 |
| jeanian |
请教高手,如何定义Use
Case ?
比如现在做一个销售管理系统,需要处理赊销,预付货款,现销等业务,而每种业务又各有其流程。
模式一:
package 销售
use case 赊销
活动: 下订单--〉发货出库--〉 收款
下订单子活动: 新建订单--〉查询库存--〉查询信用度--〉保存
发货出裤子活动:开出库单--〉出库--〉减少库存
收款子活动: 开收款单--〉收款——〉开发票
use case 预付货款
活动: 收款--〉下订单--〉发货出库
。。。
模式二:
package 销售
package 赊销
use case 下订单
活动: 新建订单--〉查询库存--〉查询信用度--〉保存订单
use case 发货出库
活动: 开出库单--〉出库--〉减少库存
use case 收款
活动: 开收款单--〉收款——〉开发票
package 预付货款
。。。
说明:
这两种模式中,模式一可以很好的表示出下订单,收款,出库之间的流程关系
但每个use case我觉得太大了,基本上快是一个子系统了
模式二可以详细的描述下订单,发货出库,收款的具体活动(脚本),但却无法表示在下订单,收款,出库之间的先后关系。
请教经验丰富的各位应该如何处理?或者该采用其他的什么表示方式? |
| 03/08/05 17:47 |
酷帖! 臭帖! 回复 |
|
酷帖评价: 臭帖评价: |
| 返回页首 |
|
| fdc_message |
回复:
请教高手,如何定义Use Case ?
如果你想清晰的表达出用例间的交互顺序,我认为你应该作一个动态图进行辅助性说明。用例的定义应该是一个有始有终的事物。include
、entend 严格的说不应该叫做用例。关于这些的说明请到《非程序员》中查看,有大师的解释。
我认为用例图并不能包打天下在分析的过程中用例会进行不断的拆分或者合并。具体用例图画到什么程度取决与你所在的阶段和你所要表的意图。 |
| 03/08/06 13:48 |
酷帖! 臭帖! 回复 |
酷帖评价: 臭帖评价: |
| 返回页首 |
|
| heyongbin |
建议:如果是在商务前期,简洁就好,系统架构层次体现;如目标是设计人员,细化好些。
fdc_message观点是经验啊,管见
|
| 03/08/06 14:31 |
酷帖! 臭帖! 回复 |
|
酷帖评价: 臭帖评价: |
| 返回页首 |
|