UML整理（一）

最近看开发文档的用例，虽然不是自己写的，但是在审批的过程中发现了很多问题，今天开始就将自己知道都积累下来吧。

一，Actor

我们所谓的参与者（Actor）实质上是指业务主角（business actor）。一般我们都称为参与者（actor），而实际上actor分为两种：业务主角（business actor）和业务工人（business worker）。

其中如何区分这两个角色呢？

1.谁主动向系统发出动作的？

2.谁有完整的业务目标？

3.系统为谁服务？

如果这三个答案对谁都是否定的，那这个谁一定是业务人员。比如：预订机票，通过人工服务订票，其中这个人工服务就是业务工人，不属于业务主角。

 

二，Use Case

一个系统的功能性是由一些对系统有愿望的参与者要做的一些事情构成的，事情完成后就达成参与者的一个愿望，当全部参与者的所有愿望都能通过用例来达到，那么这个系统就被确定下来了。

用例的特性：

1.用例是相对独立的。不需要与其他用例交互而独立完成参与者的目的。

   如：取钱时一个有效的用例，填写取款单却不是。因为完整的目的是取到钱，没有人会为了填写取款单而专门跑一趟银行

2.用例的执行结果是对参与者来说是可观测的和有意义的

   如：登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但单纯的输入密码确实没有意义，输完了呢？有什么结果吗？

3.这件事必须有一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动一个用例。

4.用例必然是以动宾短语形式出现的

5.一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元。甚至部署单元。

 

当写单元测试用例时，可更深切地体会到用例的这些特征。

 

用例和功能的区别：

先举例说明：客户代表（主角）说：我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是存钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以缴纳水电费；为了安全起见，ATM上有警示小心骗子的提示条，还有摄像头；如果输入三次密码错误，卡片自动吞没

从以上的需求哪些是有效用例呢?

1.支持跨行业务（×）        这是一个业务规则，限定业务范围

2.插入卡片（×）              这是一个过程步骤，不是完整目标

3.输入密码（×）              这是一个过程步骤，不是完整目标

4.选择服务（×）              这是一个过程步骤，不是完整目标

5.取钱（√）                    这是一个有效完整的目标

6.存钱（√）                    这是一个有效完整的目标

7.挂失卡片（√）              这是一个有效完整的目标

8.缴纳费用（√）              这是一个有效完整的目标 

9.警示骗子（×）              已超出了系统边界范围 

10.三次错误吞卡（×）      这是一个业务规则，限定业务范围

 

结论：

1.功能是脱离使用者的愿望而存在的。比如XXX工具能做什么，一般是事物固有的特性。

   用例描述的是使用者的愿望，使用者对系统的要求。

2.功能是孤立的，输入——>计算——>输出。描述的是一个个点，如果要达到某个目的，则需要额外加上顺序将点串起来，面向过程的设计思想

   用例是系统性的，她需要描述谁在什么情况下通过什么方式得出什么结果。很明确性的去达成某个特定的目标

3.若非要从功能的角度解释用例，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对不同的应用场景，这些“”

功能体现不同的组合方式。并且不是先有了这些“功能”才组合成某个场景，而是先有了场景，才分解出“功能”。

 

举例说明：

功能的角度：电视的描述：能开关，能显示，能调频，能调声，以上是独立的

用例的角度：一个人要看电视为目的的用例，第一步打开电视，调自己喜欢的频道，如果声音不合适，可以调节一下，以上是因人的需求而关联起来的。