| 四、UML中的用例及用例图概述
（1）用例及用例图产生的技术背景概述
- 在软件系统的分析与设计中，必须要了解并准确描述用户的功能需求，以便于确定建立的对象。
- 很长时间以来，无论是传统的软件开发方法还是面向对象的开发方法，都采用自然语言（如中文）来描述对系统的需求
- 其缺点是没有统一的格式，缺乏描述的形式化，随意性较大，常常产生理解上的含混及不确定性。
- 在这种背景下，有关专家提出了用例（Use Case）的概念及其图形表示方法——用例图，这种方法很快得到广泛的应用。
（2）参与者和用例
- 参与者（Actor）表示系统用户能扮演的角色(role)，这些用户可能是人、也可能是其他的计算机或者一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外，并且它们必须能刺激系统部分并接收返回。
- 在本项目中的参与者主要有用户和系统统管理员，而管理员使用控制面板对系统和用户管理，也就是进行系统设置，管理用户、用户组、权限，查看系统访问日志及用户使用情况等的统计信息。
- 在前面的学校课程管理系统中的示例中则有三个Actor 在不同的应用中互动。这三个Actor分别是学生，讲师以及系统管理者。而学生Actor
使用了系统中浏览课程以及注册课程的功能，而系统管理者Actor 则是负责管理注册的学员，编排课程以及确认课程。讲师则是主导课程的Actor，他可以浏览，开办以及移除课程(当然，必须是这个讲师自己的课程)
（3）所要注意的问题
- 用户与参与者之间的关系
- 一个用户可以抽象为多个参与者，如：张三即可以是网上书店的读者，也可以是管理员
- 一个参与者可以包含多个用户，如：网上书店的读者可以是张三和李四
（4）用例（UseCase）及其定义
- 它描述了当主角之一给系统特定的刺激时系统的活动，是主角通过系统完成一个过程时出现的一组事件，最终以实现一种功能。
- 通常，用例侧重于功能，但不重点描述该功能的实现细节。
- 用例的大小划分一般以事件流在10个步骤左右为好。
（5）用例的分类
- 业务用例（Business Use Case）
指系统提供的业务功能与参与者的交互，表现问题领域中各实体间的联系和业务往来活动。它用于建立问题领域的业务用例模型。
- 系统用例（System Use Case）
指参与者与系统的交互，它表现了系统的功能需求和动态行为。
注意：用例确定的只是交流的目的，而不是交流的手段
客户并不需要了解执行者、用例这些概念。用例能告诉开发团队“去向客户了解什么”（目的），不能告诉你如何向客户去了解（手段）；
手段可以有很多种，文档研究、问卷调查、访谈、观察、研究竞争对手、开会、原型、场景演示…，使用用例思维来指导这些交流手段，会使交流更有目的，更加高效。因为以场景方式表达的需求本来就比一条条列出的需求要便于交流。
（6）用例的层次化
按照抽象层次，用例图可以划分为系统层（最高层）、子系统层（可以再细分）和对象类层（最低层）。
- 系统层用例图描述系统提供的全部服务。
- 子系统层用例图描述子系统提供的服务，它的外部交互者可以是其他的子系统或高一层的参与者。
- 对象类层的用例图描述对象类提供的功能片或操作，它的外部交互者可以是其他对象类或高一层活动者。
（7）用例建模的主要步骤
- 确定边界（区分敌我---找出系统外部的活动者和外部系统，确定系统的边界和范围）和参与者
- 确定用例（功能实现的）优线级和相互依赖关系
- 对用例进行分层（适当分解和细化用例，用例需要细化到什么程度？）
- 编写主成功场景，并尽可能列出所有扩展条件。编写扩展处理的步骤。
五、如何编写用例
（1）编写用例时，最应该注意的几种问题
- 编写功能需求，而不是编写使用设想文本
- 描述属性与方法，而不是描述习惯用法
- 编写的用例过于简要并且把自己与用户界面完全隔离
- 回避详细的边界对象名称，同时从第三者的角度而不是用户角度编写用例，并用采用被动式
- 仅仅描述用户交互，而忽略系统响应
（2）用例示例点评
- 错误用例
用例：提取现金
范围：ATM系统
主执行者：储户
1.储户插入ATM卡，并键入密码
2.储户按“取款”按钮，并键入取款数目
3.储户取走现金、ATM卡并拿走收据
4.储户离开
- 修正上面的用例
问题原因：没有系统
修正后：
范围：ATM系统
主执行者：账户持有者
1.通过读卡机，储户插入ATM卡
2.ATM系统从卡上读取银行ID、账号、加密密码，并用主银行系统验证银行ID和帐号
3.储户键入密码，ATM系统根据上面读出的卡上加密密码，对密码进行验证。
4.储户选择取款，并键入取款数量。
5.ATM系统通知主银行系统，传递储户账号和取款数量，并接收返回的确认信息和储户账户余额。
6.ATM系统输出现金、ATM卡，显示账户余额的收据。
7.ATM系统记录事务到日志文件。
- 错误用例
用例：提取现金
范围：ATM系统
主执行者：储户
1.收集ATM卡，键入密码
2.收集取款事务类型
3.收集提取金额
4.验证账户上是否有足够储蓄金额
5.输出现金、收据和ATM卡
6.复位
- 修正上面的用例
问题原因：没有主持行者
修正后：
范围：ATM系统
主执行者：账户持有者
1.通过读卡机，储户插入ATM卡
2.ATM系统从卡上读取银行ID、账号、加密密码，并用主银行系统验证银行ID和帐号
3.储户键入密码，ATM系统根据上面读出的卡上加密密码，对密码进行验证。
4.储户选择取款，并键入取款数量。
5.ATM系统通知主银行系统，传递储户账号和取款数量，并接收返回的确认信息和储户账户余额。
6.ATM系统输出现金、ATM卡，显示账户余额的收据。
7.ATM系统记录事务到日志文件。
- 错误用例
用例：买东西
范围：采购应用系统
主执行者：顾客
1.系统显示输入ID及密码屏幕。
2.顾客键入ID和密码，然后按OK。
3.系统验证顾客ID及密码，并在屏幕上显示个人信息。
4.顾客键入姓名、街道地址、城市、州、邮编、电话号码，然后按OK。
5.系统验证是否为老客户
6.系统显示可用商品列表
7.顾客选取需要购买的商品及数量，完成时按DONE。
8.系统通过库存辅助系统验证购买商品是否有足够库存。
9. … …
- 修正上面的用例
问题原因：过多用户接口细节
修正后：
1. 顾客使用ID和密码进入系统
2. 系统验证顾客身份。
3. 顾客提供姓名、地址、电话号码
4. 系统验证顾客是否为老顾客
5. 顾客选择购买商品及相关数量
6. 系统由库存系统验证购买商品是否有足够库存。
六、用例图
（1）用例图的作用
- 利用用例图可以实现从用户角度来描述系统所应该具有的功能，同时并能够指出各功能的操作者；
- 也能够显示出与系统进行交互的外部参与者及其使用方式。
- 在一个用例图中，一般主要包含有系统边界、参与者、用例和用例关系（通信、使用和扩展等三种形式）。
（2）用例之间的关系及其UML的图示
用例除了与参与者有联系外，各个用例之间也可能会存在一定的联系。这些联系包括：泛化关联、包含关联、扩展关联等。
- 泛化关联：它代表一般与特殊的关系，它充分体现了面向对象的继承性：子类具有父类的所有属性，还可以拥有自己的属性特点及行为。在UML中泛化关联用空心三角箭头的实线表示：其方向从特殊指向一般。
xmsz2_03"/>
- 包含关联：它指一个基本用例的行为包含了另一个用例的行为，这种关联是一种依赖关系，被包含的用例不能独立存在，只能作为包含它的用例的一部分。在UML中其表示方法为用一条虚箭线从基本用例指向被包含的用例，并标有构造型<>（在Visio中为<>）。
xmsz2_04"/>
- 扩展关联：其基本含义与泛化关联类似，但是对于扩展用例有更多的规则，即基本的用例必须声明若干新的规则，扩展用例只能在这些基本的用例上进行扩展以增加新的行为。
例如，保存图书信息用例可以是图书信息修改和图书信息录入用例的扩展，它们之间存在着扩展关系。在UML中，其图形表示方法为在用例图上用一条从基本用例指向扩展用例的虚箭线表示，并在线上标注购造型<>。
xmsz2_05"/>
七、UML用例图在本项目中的具体应用
（1）确定本项目系统中的角色（参与者）的种类
在本项目的设计中主要是要考虑有多少种不同类型的用户？都是哪几种类型的用户，用户的角色如何定义；用户的访问权限如何分配等。
- 在网上书店应用中
根据应用的要求，可能会有图书信息的浏览者(Visitor，没有进行购买行为的用户)、图书的购买者（Reader）、图书信息的发布者(Publisher)、管理员(Manager如财务人员)以及超级管理员(Administrator，系统管理员)。
- 在网上银行应用中
根据应用的要求，可能会有个人用户和企业用户、管理员(Manager如财务人员)以及超级管理员(Administrator，系统管理员)。
- 确定角色的权限
在设计的时候我们也已经把这些角色与相应的一些操作绑定在一起。如：
Publisher 拥有 Publish_Operation + Modify_Operation +Delete Operation
Visitor 拥有 Visit_Operation,
Reader拥有 Visit_Operation + change ,
Manager 拥有 Visit Money Operation +Sum Money Operation
Administrator 负责 Create_User_Operation+ Delete_User_Operation+
Assign_Permission_Operation+ Deassign_Permission_Operation +Assign_Role_Operation+Deassign_Role_Operation
（2）设计出本电子商务项目系统中的各个模块的用例（UseCase）
- 确定系统边界线
- 通过使用系统边界线矩形框来框定系统中的各个用例同时也通过它能够很清楚地划定内外部事物，因为在系统中所有的用例都应该放在矩形的内部，而在外部是所有该系统的活动者，并且它们被线连到用例。
- 在系统边界线内的每一件事物都是系统的一部分，而在系统边界线外的每一件事物都是系统的外部。
- 用例图的主要作用
在需求分析阶段,可以利用用例图来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统(用例)的功能要求。
本系统中的网上书店的主要用例如下:
xmsz2_06"/>
- 本系统中的网上银行的主要用例如下
客户主要进行银行帐户的查询、存钱和取钱、转帐交易，也可以修改密码等功能。其用例图如下所示：
xmsz2_07"/>
|
