搞事情之 UML 的用例图

原文地址：PJ 的 iOS 开发平常

面向对象技术概述

面向对象的基本建模原则：抽象、封装、继承和分类。

面向对象的基本软件工程：OOA（面向对象的分析）、OOD（面向对象的设计）、OOP（面向对象的编程）和OOSM（面向对象的软件维护）

对象的概念是：对问题域中某个实体的抽象；类的概念是：对具备项目属性和行为的一个或多个对象的描述

属性的定义：描述对象静态特征的数据项；服务的定义：描述对象的动态特征（行为）的一个操做序列。

类的定义要包括：名称、属性和操做三要素。

面向对象呈现设计的三大特性：封装、继承和多态。

面向对象的系统分析要确立 3 个系统模型是对象模型、功能模型和动态模型。

用例图

参与者

参与者是指系统之外的、须要使用系统或与系统交互的外部实体，包括人、设备、外部系统等。

用例

用例是对一个活动者使用系统的一项功能时所进行的交互过程的一个文字描述序列。能够说，软件开发的过程是用例驱动的。

用例是对系统行为的动态描述，属于 UML 的动态建模部分。UML 中的建模机制包括静态建模和动态建模两部分，其中静态建模机制包括类图、对象图、构件图和部署图；动态建模机制包括用例图、顺序图、协做图、状态图和活动图。

理论上能够把一个软件系统的全部用例都画出来，但实际开发过程当中，进行用例分析时只需把那些重要的、交互过程复杂的用例找出来。不要试图把全部的需求都以用例的方式表示出来。需求有两种基本形式：功能性需求和非功能性需求。用例描述的只是功能性方面的需求，那些难以用 UML 表示的需求不少是非功能性需求。

泛化关系

官方解释：泛化表明通常的与特殊的关系，在用例之间的泛化关系中，子用例继承了父用例的行为和含义，子用例也能够增长新的行为和含义或覆盖父用例中的行为和含义。

PJ 的解释：子类和父类的关系。

包含关系

官方解释：包含关系指的是两个用例之间的关系，其中一个用例（基本用例）的行为包含了另外一个用例（包含用例）的行为。

PJ 的解释：把某一个功能进行重用。

【例 1】银行的 ATM 系统中，有“存款”、“取款”、“帐户余额查询”和“转帐”四个用例，都要求用户必须登陆了 ATM 机。也就是说，它们都包含了用户登陆系统的行为。所以，用户登陆系统的行为是这些用例中相同的动做，能够将它提取出来，单独的做为一个包含用例。

“存款”、“取款”、“查询用户余额”和“转帐”是基本用例，“登陆”是包含用例，以下图所示：

因为将共同的用户登陆系统行为提取出来，“存款”、“取款”、“查询用户余额”和“转帐”四个基本用例都再也不含有用户登陆系统的行为。

【例 2】网上购物系统，当注册会员在线购物时，网上购物系统须要对顾客的信用卡进行检查，检查输入的信用卡号是否有效，信用卡是否有足够的资金进行支付。

上图中有没有必要将检查信用的行为提取出来，单独构成一个用例（做为包含用例），当信用检查的行为只发生在“在线购物”活动中时，能够不用提取出来。当信用检查的行为还发生在其它活动中时，应该提取出来，以便实现软件重用。

拓展关系

官方解释：在拓展关系中，对于拓展用例的执行有更多的规则限制，基本用例必须声明若干个“拓展点”，而拓展用例只能在这些拓展点上增长新的行为和含义。

PJ 的解释：基本用例在知足必定条件后可进行选择执行拓展用例。

【例 3】图书借阅系统。当读者还书时，若是借书时间超期，则须要缴纳必定的滞纳金，做为罚款。

综合

【例 4】 网上购物系统，当注册会员浏览网站时，他可能临时决定购买商品，当他决定购买商品后，就必须将商品放进购物车，而后下订单。

若是网上购物系统的需求改成了：注册会员便可以直接在线购物，又能够浏览商品后临时决定在线购物，则能够改成下图所示：

用例描述

没有描述的用例就像是一本书的目录，人们只知道该目录的标题，但并不知道该目录的具体内容是什么，仅用图形符号表示的用例自己并不能提供该用例所具有的所有信息，必须经过文本的方式描述该用例的完整功能。实际上，用例的描述才是用例的主要部分，是后续的交互图分析和类图分析必不可少的部分。

用例描述了参与者和软件系统进行交互时，系统所执行的一系列动做序列，所以这些动做序列应该包含正常使用的各类动做序列（主事件流），并且还包含对非正常使用时软件系统的动做序列（子事件流）。

【例 1】 在银行 ATM 系统的 ATM 机上“取款”用例一个简单用例描述能够采起以下格式

描述项	说明
用例名称	取款。
用例描述	在储户帐户有足够金额的状况下，为储户提供现金，并从储户帐户中减去所取金额。
参与者	储户。
前置条件	储户正确登陆系统。
后置条件	储户帐户余额被调整。
主事件流	（1）储户在主界面选择“取款”选项，开始用例（这个词的出现很重要）。（2）ATM 机提示储户输入欲取金额。（3）储户输入欲取金额。（4）ATM 确认该储户帐户是否有足够的金额。若是金额不够，则执行子事件流 b 。若是与主机链接有问题，则执行异常事件流 e。（5）ATM 机从储户账号中减去所取金额。（6）ATM 机向储户提供要取的现金。（7）ATM 机打印取款凭证。（8）进入主界面。ATM 机提供如下选项：存款、取款、查询和转帐。用例结束（这个词的出现一样很重要）。
子事件流 b	b1. 提示储户余额不够。b2. 返回主界面，等待储户从新选择选项。
异常事件流 e	e1. 提示储户主机链接不上。e2. 系统自动关闭，退出储户银行卡，用例结束。

一个复杂用例主要体如今基本操做流程和可选操做流程的步骤和分之过多，此时，能够采用“场景（或称脚本）”的技术来描述用例，而不是用大量的分之和附属流来描述用例。

用例建模

用例模型主要应用在需求分析时使用。

步骤

• 找出系统外部的参与者和外部系统，肯定系统的边界和范围；
• 肯定每个参与者所指望的系统行为，参与者对系统的基本业务需求；
• 把这些系统行为做为基本用例；
• 区分用例的优先级；
• 细化用例。使用泛化、包含、拓展等关系进行处理；
• 编写每一个用例的用例描述；
• 绘制用例图；
• 编写项目词汇表。

肯定系统边界

系统边界是指系统与系统之间的界限。系统能够认为是一系列的相互做用的元素造成的具备特定功能的有机总体。不属于这个有机总体的部分能够认为是外部系统。所以系统边界定义了油谁或什么参与者来使用系统，系统可以为参与者提供什么特定服务。系统边界决定了参与者。

【例 1】在一个仅为交易客户提供买卖基金的基金交易系统中，参与者为交易客户，交易客户可以操做的系统功能有买入基金和卖出基金。所以，系统有两个用例：买入基金和卖出基金。

进一步分析发现，基金的品种应该存在与该系统中，不然交易客户没法进行基金的买卖。但系统已存的两个用例都不能完成基金品种的管理，因此能够确认基金品种的管理应该在别的系统中完成。

因此，咱们须要开发这个系统，仅存在两个用例：买入基金、卖出基金。

【例 2】对例 1 作个调整。在一个既提供基金买卖又提供基金品种录入的基金交易系统中，交易客户，可以进行基金的买入和卖出。由于还须要对基金品种进行管理（录入、修改、删除和查询），由基金公司员工进行操做。因此该系统的参与者有交易客户和基金公司员工。系统边界能够改成下图所示：

如何肯定参与者

• 谁将使用系统的主要功能？
• 谁将须要系统的支持来完成她们的平常工做？
• 谁将必须维护、管理和确保系统正常工做？
• 谁将给系统提供信息、使用信息和维护信息？
• 系统须要处理哪些硬件设备？
• 系统使用外部资源吗？
• 系统须要与其余系统交互吗？
• 谁对系统产生的结果感兴趣？

须要注意的问题：

• 只要是参与者，对于子系统而言都是外部的；
• 参与者直接与系统进行交互；
• 参与者指的与系统直接交互时所扮演的角色，而不是特定的人或事物。好比，不是 PJ 与教务系统产生交互而是学生与教务系统产生交互；

如何肯定用例

识别用例能够从列出的参与者列表中从头开始寻找，考虑每一个参与者如何使用系统，须要系统提供什么样的服务。

• 参与者要向系统请求什么功能？
• 每一个参与者的特定任务是什么？
• 参与者须要读取、建立、撤销、修改和存储系统的某些信息吗？
• 参与者是否有须要通知系统的事件？系统是否有须要通知参与者的事件？
• 这些事件表明了哪些功能？
• 系统须要哪些输入输出功能？
• 是否全部的功能需求都被用例使用了？

须要注意如下问题：

• 每一个用例至少有一个参与者；
• 每一个参与者至少一个用例；
• 若是存在没有参与者的用例，再三检查后，仍是没有参与者，能够考虑把该用例并入其余用例中；
• 若是存在没有用例的参与者，再三检查后，该参与者仍是没有用例，能够考虑该参与者是如何与系统产生交互的，或由该参与者肯定一个新的用例，或实际上该参与者自己就是多余的。

项目词汇表

这什么鬼，没见过，没据说过......

其余问题

需求应该有层次的组织

系统的高层需求一版用不超过 12 个左右的用例进行表示，在其下的层次中，用例的数量不该超过当前用例的 5～10 倍。能够将用例划分为业务用例、系统用例和组件用例等。

不要从用例直接推导设计

用例应该描述参与者使用系统所遵循的顺序，但用例毫不说明系统内部采用什么步骤来响应参与者的刺激。

用例包

用例模型的调整

若是两个用例老是以一样的顺序被激活，可能须要将它们合并为一个用例。

不要过于详细

在进行用例描述时尚未考虑系统的设计方案，那么也不会涉及用户界面。