帮我解决一个我最困惑的问题

kissmoon

那么 管理商店 这个东西是在什么时候体现出来？
是在 签定合同 这个业务用例的 活动图里吗？

kissmoon

原帖由 张恂 于 2010-8-10 17:16 发表
>> 现在用rose，就糊涂了

感觉你不知道 UML 业务建模应该怎么做。

呵呵，说得太对了

这是刚开始用，刚开始要求

张恂

原帖由 kissmoon 于 2010-8-10 17:16 发表
那么 管理商店 这个东西是在什么时候体现出来？
是在 签定合同 这个业务用例的 活动图里吗？

对，大致如此。

kissmoon

配送 是个业务用例
那仓库里的货物的管理，是不是一个业务用例？

lodge

恩, 系统设计的第一步是要明确系统的目的(这和UML无关)
假定 你要做的系统是这样一个系统, 商店用它预约送货. 公司用它制定送货计划

下面根据这些假设来做系统用例:

用例1(ACTOR 商店): 预约 送货
用例2(ACTOR 公司): 查询 送货计划
用例3(ACTOR 商店): 取消 送货预约
用例4(ACTOR 公司): 确认 送货

事件流
用例1
事前条件: 商店已同公司签有送货合同
事后条件: 商店承认送货预约有效
1. 商店向系统提交身份验证
2. 系统确认用户身份后要求商店输入送货信息
3. 商店向系统提交输入送货信息(送货时间, 货物和数量)
4. 系统提示商店确认预约的有效性
5. 商店承认有效性
6. 系统登记送货预约并通知商店预约完了

-其它用例略

* 个人认为, BUC和SUC的主要差异 在于BUC强调用户的操作流, 而SUC强调系统和ACTOR的互动, 二者的差异通常表现在对事件流的定义, 而用例自身并无很大差别
上面做的是SUC, 而BUC的事件流可以定义成以下形式

事前条件: 商店已同公司签有送货合同
事后条件: 商店承认送货预约有效
1. 商店向公司提交身份验证
2. 公司确认用户身份后要求商店提供送货信息
3. 商店向公司提交输入送货信息(送货时间, 货物和数量)
4. 公司提示商店确认预约的有效性
5. 商店承认有效性
6. 公司登记送货预约并通知商店预约完了

lodge

原帖由 kissmoon 于 2010-8-10 16:02 发表
公司的业务是 从批发商购货，卖给商店。

从系统的角度说，
有个商店管理，功能是记录商店的联系信息，方便送货及以后的统计。

1、这个需求可以当作 管理商店 的业务用例吧？ 这个业务用例 对应的 actor 是什么？
2、管理商店，相应的操作就是新增、修改、删除这些操作，那么这个的流程有吗？我怎么感觉不到流程，所以画不出活动图？
3、如果从这个业务用例找系统用例，那么系统用例会是什么？

这个最简单的操作，我感觉却是很头晕

常言说得好, 不识庐山真面目只缘身在此山中. 站在系统内部考虑系统用例是系统分析的大忌.
上面说的"新增、修改、删除"是系统内部的处理, 只有在考虑系统的实现方法时才会有这样的理解.
这种功能定义是不能够解释业务内容和需求的.

打个比方, 你出门遇到熟人, 他问你去哪里?
以你上面思考方式,  你的回答是 去打出租车->你说明了去的方法, 却没有回答问题
而回答 去超市买东西 才是确切的回答 不是吗?

kissmoon

原帖由 lodge 于 2010-8-11 00:31 发表
恩, 系统设计的第一步是要明确系统的目的(这和UML无关)
假定 你要做的系统是这样一个系统, 商店用它预约送货. 公司用它制定送货计划

下面根据这些假设来做系统用例:

用例1(ACTOR 商店): 预约 送货
用例2(ACTOR 公司): 查询 送货计划
用例3(ACTOR 商店): 取消 送货预约
用例4(ACTOR 公司): 确认 送货

对商店来说，因为“预约”后，也会想查看 预约 送货 的信息，需要一个 管理（查询） 送货预约 用例吗？

张恂

原帖由 kissmoon 于 2010-8-10 17:28 发表
配送 是个业务用例
那仓库里的货物的管理，是不是一个业务用例？

如果你能把货物管理的完整流程写出来，那么它就是一个 BUC。

否则，它很可能是一个包。

lodge

原帖由 kissmoon 于 2010-8-11 09:04 发表


对商店来说，因为“预约”后，也会想查看 预约 送货 的信息，需要一个 管理（查询） 送货预约 用例吗？

这里所设计的用例都来源于对实际业务的假设, 如果你认为需要加一个也无妨啦.

要注意的是, 用例是针对实际业务建立的模型, 在真实的开发中, 需要对各业务进行大量的调查和分析, 才能作出准确的用例
切记不可闭门造车随意假定, 更不可根据系统的繁简对业务流程进行修改.

kissmoon

需求调研，这个过程会进行的：-）