需求开发指南

需求开发指南

公司

拟制： 审核： 批准： 生效日期：

文档编号：XXX_需求开发指南 版本号： 机密等级：内部公开

修改记录

修订号 作者 日期 简要说明

目 录

1 2 3 4 5

简介 .............................................................................................................. 错误!未定义书签。

目的 ..................................................................................... 错误!未定义书签。 适用范围 ............................................................................. 错误!未定义书签。 术语表 ................................................................................. 错误!未定义书签。

确信系统边界 .............................................................................................. 错误!未定义书签。

目的 ..................................................................................... 错误!未定义书签。 确信执行者 ......................................................................... 错误!未定义书签。 确信誉例 ............................................................................. 错误!未定义书签。 描述执行者和用例 ............................................................. 错误!未定义书签。 处置时刻 ............................................................................. 错误!未定义书签。 潜在的边界问题 ................................................................. 错误!未定义书签。 确信项目范围 ..................................................................... 错误!未定义书签。 边界和范围的图形化 ......................................................... 错误!未定义书签。

编写大体用例 .............................................................................................. 错误!未定义书签。

大体用例 ............................................................................. 错误!未定义书签。

进入与退出标准 ........................................................................... 错误!未定义书签。 事件流 .......................................................................................... 错误!未定义书签。

大体用例的评审 ................................................................. 错误!未定义书签。 表示形式 ............................................................................. 错误!未定义书签。 其他需求 ............................................................................. 错误!未定义书签。 大体途径 ............................................................................. 错误!未定义书签。 可选途径 ............................................................................. 错误!未定义书签。 文档化可选项 ..................................................................... 错误!未定义书签。 场景 ..................................................................................... 错误!未定义书签。 关联用例和执行者 ............................................................. 错误!未定义书签。

高级用例 ...................................................................................................... 错误!未定义书签。

包括 ..................................................................................... 错误!未定义书签。 扩展 ..................................................................................... 错误!未定义书签。 继承 ..................................................................................... 错误!未定义书签。 接口 ..................................................................................... 错误!未定义书签。

图形化用例 .................................................................................................. 错误!未定义书签。

6 7

活动图 ................................................................................. 错误!未定义书签。 时序图 ................................................................................. 错误!未定义书签。

图解用户界面 .............................................................................................. 错误!未定义书签。 常见错误 ...................................................................................................... 错误!未定义书签。

1 简介

1.1 目的

介绍需求开发顶用到的方式，供项目组在需求开发中学习利用。

1.2 适用范围

适用于公司软件开发人员、需求开发工程师。

1.3 术语表

请参见《CMMI术语表》。

2 确信系统边界

2.1

目的

➢ 将项目的参与者定位到一个一起的和明确的方向上。

➢ 确信系统中有什么（必需为创建他们投入大量精力），系统外有什么（不需要创建，

可是必需考虑与它们的接口）。

➢ 估量项目规模，概念要创建系统的哪些部份（在一按时刻段和必然预算的基础上）。

2.2

确信执行者

咱们将采纳用例分析技术，通过确信执行者和用例来确信系统边界。在一些参考资料中，咱们会常常看到“外部实体”那个术语，咱们以为外部实体和执行者具有一样的含义。

执行者是同系统交互的事物，包括人、其它软件、硬件设备、数据存储或网络。每一个执行者概念一种特定的角色，每一个系统之外的实体能够用一个或多个执行者来代表。执行者老是在系统之外，不是系统的一部份。提出以下问题会帮忙分析员确信执行者： ➢ 谁利用那个系统？ ➢ 谁安装那个系统？

➢ 谁启动系统？ ➢ 谁保护系统？ ➢ 谁关闭系统？

➢ 哪些其它的系统利用那个系统？ ➢ 谁从那个系统获取信息？ ➢ 谁为那个系统提供信息？

➢ 是不是有情形自动在估量的时刻发生？

2.3

确信誉例

用例是系统的一种行为，它为执行者产生一种能够估量的价值结果，它描述执行者想要系统完成的情形。从执行者的角度看，用例应该是一个完整的任务，一个用例行为常常是在一个相对较短的时刻段内完成。若是用例的各部份被分在不同的时刻段，尤其是被不同的执行者执行时，最好仍是将各部份作为单独的用例对待。用例通常由执行者启动，因此咱们能够从执行者角度动身，判定有哪些用例。考虑以下问题：

➢ 执行者希望系统提供什么样的功能？

➢ 系统存储信息吗？执行者将要创建、读取、更新或删除什么信息？ ➢ 系统是不是需要把自身内部状态的转变通知给执行者？

➢ 系统必需明白哪些外部的事件？执行者将如何通知系统这些事件？

➢ 如何修复系统？是不是需要把系统关闭或在系统运行的情形下进行系统保护？

2.4

描述执行者和用例

用一个名字和简单的话描述每一个执行者和用例。建议采纳“执行者列表”和“用例

表”别离描述执行者和用例。

表1 执行者列表

执行者名称 客户代表 客户 执行者描述 ABC公司处理客户请求的雇员 从ABC公司订购商品的人

表2 用例表

用例 客户发送订单 触发器 新订单 来源 客户 动作 生成新订单 响应 实时连接 订单确认 订单细节 交易处理

目的地 信用卡部门 客户 发货部门 银行 ➢ 用例：引发系统去执行某种操作的情形；

➢ 触发器：系统如何明白那个用例发生了？或是进入系统的数据，或是概念好的时刻点。 ➢ 来源：执行者；

➢ 动作：当用例发生时，系统做了什么操作？

➢ 响应：系统产生了什么样的输出结果（若是有的话）？ ➢ 目的地：哪个执行者取得了产生的输出结果？

第一，对每一个用例来讲，系统怎么明白某一事件发生了呢？用来通知系统某一事件发生了的事物称为触发器。关于一个外部事件，触发器确实是系统必需处置的数据抵达了。关于临时事件，触发器是某一个时刻点。

第二，当用例发生时，系统该做些什么呢？系统对用例的响应称为动作。

最后，动作致使系统产生什么响应呢？响应是系统的输出结果。一个动作通常会有多个响应。目的地确实是系统发送响应的地址，也确实是执行者。注意，有些时候不需要系统响应。

2.5

处置时刻

在用例中要紧用两种方式来处置时刻。一个方式是把时刻看成一个执行者，然后由时刻执行者启动用例。第二种方式是把它看成系统的一部份，用例在某个时刻自己启动。

2.6

潜在的边界问题

若是某些需求需要一个执行者来处置，可是那个执行者又超出了已经确信的执行者的范围，如何办？需要确信那个执行者是不是真的是系统的一部份。若是不是，那么需求也就不能成为系统的一部份；若是是，那么看一看对它的描述，可能需要从头概念执行者或它的角色以使系统边界清楚。若是执行者变成系统的一部份，可能需要从头概念用例。当你发觉新的需求时，应该考虑的一些问题如下：

➢ 这些需求是不是对系统是必需的？ ➢ 这些需求是系统在逻辑上能够完成的吗？ ➢ 新的需求将如何阻碍咱们目前的风险分析？ ➢ 这些需求是不是能够被系统目前的执行者处置？ ➢ 这些需求是客户希望系统去做的吗？ ➢ 这些需求会使产品在市场上变得不同凡响吗？

2.7

确信项目范围

确信了系统的边界以后，需要为系统确信一个范围。一个项目有特定的开始和终止的时刻，用于完成项目目标的资金也有必然的。因此，必然要清楚地概念系统将要包括和不包括的成份。利用需求优先级的方式确信系统必需包括的情形，并确信没有必要的情形确实

被放在了一边。

成立了用例表以后，系统分析员能够和用户进一步沟通协商，也能够召开联系会议，确信列表中的用例哪些是在项目范围之内的，哪些是项目范围之外的。

考虑以下问题有助于确信下面的范围：

➢ 是不是能够应付得了把这些需求添加到打算和预算上去？ ➢ 是不是应该再有一个后期的版本？

➢ 若是咱们不能不此刻考虑这些，是不是能够把其它需求移到后期版本？

2.8

边界和范围的图形化

利用用例图，描述项目的边界和范围。

能够用Visio画用例图。下面是用例图用到的图形符号。

图1 用例的图形符号

系统边界永1<>接口1<>主角1执行者用例系统边界接口扩展包含

下面是一个“定单处置系统”的边界和范围图，本文后续的部份，都将以“定单处置系统”为例子。

图2 定单处置系统用例图

订单处理Order**transfer package*Order State*******运输公司客户**CatalogSend goods***********Withdraw*caculate fee**Cancel Order供应商客户代表职员

需要注意的是，万万不要以为有了用例图，就能够够不写文档了。事实上，图形仅仅是更直观地表现用户需求的一种方式，文字描述仍是必不可少的。咱们建议采纳的文字描述方式仍是上文提到的 “用例列表”。

3 编写大体用例

3.1

大体用例

每一个用例必需包括一些细节，这些细节告知咱们需要完成哪些步骤才能实现那个用例的功能。咱们需要考虑大体功能、所有可选方案、异样情形，进入用例之前和退出用例时必需正确的因素。用例能够包括条件、分支和循环。

此刻让咱们看一个可能的用例例子：定单处置系统。

表3 定单处置系统的用例

进入标准：一个合法的用户已经登录到这个系统； 事件流： 1. 当客户选择订购货物时，用例开始； 2. 客户输入他的姓名和地址； 3. 如果客户只输入邮编，系统将给出城市名； 4. 客户输入想购买产品的代码； 5. 系统为每一项给出产品描述和价格； 6. 系统保存连续的已经订购的产品清单； 7. 客户输入信用卡支付信息； 8. 客户选择submit； 9. 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统转发支付信息。如果客户提交的信息不正确，系统将提示客户修改； 10. 当支付确认后，订单就被标记上已经确认，同时返回给用户一个订单ID，用例结束。如果支付没有被确认，系统将提示客户改正支付信息或者取消。如果客户选择修改信息，就回到第7步；如果选择取消，用例结束。 退出标准：如果订单没有被取消，它将被保存在系统里，并做上标记。

3.1.1 进入与退出标准

进入与退出标准表示用例开始和终止时会发生什么，即在用例开始时系统必需处在什么状态，用例终止时系统必需处在什么状态。不管紧随用例以后是哪个分支或选择，退出标准都必需为真。

3.1.2 事件流

从执行者的角度看，事件流是一系列陈述句，它列出了用例的各个步骤：告知咱们它如何开始，利用一个像“当……时用例开始”的描述。用例是为软件做的，软件如何明白何时用例开始？一样地，用例如何终止？能够利用如“用例终止”的短语清楚地陈述它。

利用分支能够表示选择。为了表示分支，咱们能够利用一个if语句。

当需要重复一个或一系列步骤时，能够利用循环。要清楚地指出循环在哪儿开始和在哪儿终止，还要清楚地指出如何终止。咱们能够利用for语句或while语句来表示循环。

3.2

大体用例的评审

用例的编写进程中需要进行多次评审，大体用例终止以后，是最正确的评审时刻。咱们给出第一次评审用例的大体原那么。

➢ 用例的每一步都应该是一个简单的陈述句，缺省时这些步骤按时刻顺序执行。若是这些

步骤能够按任何顺序发生，需要清楚地描述。

➢ 幸免试图做得太细，咱们将随着时刻的推动添加更多的细节，可是这一时期，咱们是在

搜集需求，而不是详细分析或设计。另一方面，用例还要完整，开始和终止时都必需超级清楚，确保这一系列的步骤大体上包括了完成用例功能所需要的一切。

➢ 用例是一个转达工具，只有它们向读者转达关于系统如何工作的信息时才有效。因此考

虑谁会阅读用例是很重要的，是最终用户、市场专家、开发人员仍是治理人员？不管是谁，他们必需能够明白得用例。若是他们不能明白得用例，那个用例就需要改写了。 ➢ 不要担忧如何才能利用例完美，那个进程的特点确实是不断反复。要持续查看已经完成

的工作，而且精简它，以反映了解到的情形。用例质量会随着分析员对系统了解的深切而提高。

➢ 必需在用例中包括足够的信息，以判定是不是用了特定的用例处置了特定的功能。

3.3

表示形式

能够超级正式地或较自由地表示用例，但要清楚用例的读者，从而选择一个易于被读者同意的形式。咱们推荐了两种形式，项目领导能够从当选择。

一种是用编号序列来表示用例（表4），另一种是用表格形式表示（表5）。

表4 取消定单用例的编号序列表示

1. 当客户收到取消订单的请求时，用例开始； 2. 客户代表输入一个订单ID； 3. 客户代表按下“查找”； 4. 系统显示这个订单的内容； 5. 客户代表选择取消； 6. 系统将该订单做上取消标志； 7. 记账系统收到向客户账号中加钱的通知，用例结束。

表5 取消定单用例的表格形式

客户代表 1. 接收到一个取消订单的请求 2. 输入一个订单ID； 3. 按下“查找” 5. 选择取消 系统 4. 显示订单内容 6. 给该订单打上取消标志 记账系统 7. 向客户账号中加钱

3.4

其他需求

分析员编写用例的时候，可能会发觉一些需求对执行者并非可见，或有一些特殊的需求很难在用例中表示。

这些需求需要和用例一路记录下来，它们一样是系统的一个组成部份。当构建和测试系统时，必需将它们考虑进去。你能够将它们归到其他的需求文档，这些文档和用例文档编排在一路。

有时这些需求是非功能性的需求，如可用性、平安性、稳固性、可保护性等方面的内容。 若是需求是针对一个特殊的用例，能够在用例描述中添加一个专门的需求部份：“特殊需求”。

其他文档常常是伴随用例开发出来的，这些文档包括一个术语表、一个数据概念文档和用户接口的指导原那么。还需要一个文档，它列出了需要解决的重要问题。

到目前为止，咱们已经确信了用例的大体途径。可是一个完整的用例描述可能相当复杂，并非像最开始时所写的那样，它会随着时刻的推移不断进展。

3.5

大体途径

用例的大体事件流确信了以后，还要考虑所有可能的犯错条件。一个完整的用例描述可能相当复杂，它是随着时刻的推移不断进展的。事件流分为两个部份：大体途径和可选途径。

当一切运转正常时咱们就取得了大体途径。没有故障、没有错误，是一个完美的境遇。每一个用例都必需有一个大体途径。

3.6

可选途径

大体途径确信了以后，就要扩充可选途径。

一个可选途径指的是不同于大体途径而许诺不同的事件序列的途径。客户能够从用例的假设干情形中挑选一件情形来做，最可能的选择归入大体途径。关于明显有可能随时发生的情形来讲，可选途径超级有效。

找出可选途径的方式确实是沿着大体途径一条一条地找，而且考虑： ➢ 在那个点上，还能够执行别的活动吗？ ➢ 在那个点上，有无什么能够犯错的？ ➢ 有什么随时可能发生的行为吗？

另一种方式确实是用以下典型问题去发觉可选途径： ➢ 执行者退出应用程序； ➢ 执行者取消指定操作； ➢ 执行者请求帮忙；

➢ 执行者提供了不正确的数据；

➢ 执行者提供了不完整的数据；

➢ 执行者提供了一个执行用例的可选方式； ➢ 系统崩溃； ➢ 系统不可用。

每一个可选途径需要一个名字或一个简单的描述，如表6所示。

表6 通过度类订购货物附加的可选项

不完整的数据 不正确的数据 可选行为 取消操作 系统崩溃 系统不可用 没有付费；订单不完整；运送地址不完整 密码错误、用户名错误、产品代码错误、无效支付。 客户通过支票付款、客户通过发邮件或电话订购。 客户取消这次订购 系统在订购过程中崩溃 系统没有响应、客户不能登录、订单丢失

关于每一个大体途径，简单地列出所有你能够想到的可选途径和异样情形。识别出可选途径和异样后，用新的假设更新假设列表。这张列表将在评审时提交给由用户、客户、市场人员组成的评委。

3.7

文档化可选项

重要而复杂的可选途径还需要一系列步骤去细化它们的行为，能够用写大体途径的方式去写可选途径。

咱们将用订购货物用例大体途径，利用不同的方式调整它，从多方面说明此类技术，而且讨论每种技术的优缺点。

表7 原先的订购货物用例

事件流： 基本路径： 1. 当客户选择订购货物时用例开始； 2. 客户输入他的姓名和地址； 3. 当客户输入产品代码 a) 系统显示产品描述和价格； b) 系统在该客户的订单中添加这个物品的价格 4. 客户输入信用卡支付信息； 5. 客户选择submit； 6. 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息； 7. 当支付被确认后，订单也被标记上已经确认，同时返回给客户一个订单ID，用例结束。

第一个技术是直接往用例文本中添加可选项，适本地添加新的标号步骤。那个技术的优势是能够超级容易地看到用例中可能的行为，缺点是它会致使用例难以明白得和阅读。添加的内容以蓝色字体表示。（表7）。

表7 添加可选项的订购货物用例

事件流： 基本路径： 1. 当客户选择订购货物时用例开始； 2. 客户输入他的姓名和地址； 3. 如果客户只输入邮编，系统给出城市。 4. 客户输入将要订购产品的代码 5. 对每个输入的代码 a) 如果系统中有该产品代码，系统提供该产品的介绍和价格，并在该客户的订单中添加这个物品的价格。 b) 如果系统中没有这个产品代码则打印出错信息，提示客户输入新的产品代码。 6. 客户输入信用卡支付信息； 7. 客户选择submit； 8. 系统核查支付信息。 9. 如果所有的信息都正确，用例就从第13步继续执行。 10. 如果客户没有输入支付信息，系统提示客户输入支付信息或取消。 11. 如果客户选择取消，用例结束； 12. 如果客户输入新的支付信息并选择submit，用例从第8步开始重复。 13. 系统把该订单作为未完成的交易保存，同时向记账系统提供支付信息； 14. 如果记账系统确认支付信息正确，订单被标上已经确认，一个订单ID就返回给客户，用例结束。 15. 如果记账系统返回错误，系统就打印出错信息，提示客户输入新的支付信息或者取消； 16. 如果客户选择取消，用例结束； 17. 如果客户选择输入新的支付信息，用例从第6步开始重复。

第二个技术是在原先的基础上，在段落中增加可选项。这比前面的例子更易于阅读，而以前的步骤成为那个用例的大体明白得的题目，可选项细节和错误处置成为编号步骤的下级段落。这种方式不改变原先的步骤编号。（表8）。

表8 在段落中添加可选项的订购货物用例

事件流： 基本路径： 1. 当客户选择订购货物时用例开始； 2. 客户输入他的姓名和地址； 如果客户只输入邮编，系统提供城市。 3. 客户输入产品代码 4. 对每个输入的产品代码 a) 系统给出该产品的介绍和价格。 如果系统中没有这个产品代码则显示出错信息，提示客户输入新的产品代码。 b) 系统在该客户的订单中添加这个物品的价格 若物品未找到，订单保持不变； 循环结束。 5. 客户输入信用卡支付信息； 6. 客户选择submit； 7. 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息； 如果客户没有输入支付信息，系统将提示客户输入支付信息或取消；如果客户选择取消，用例结束。入客户输入新的支付信息，客户选择submit，用例从第7步重复。 8. 当支付被确认后，订单也被标记上已经确认，同时返回给客户一个订单ID，用例结束。 如果记账系统返回错误，系统打印出错信息，提示客户输入新的支付信息或者取消。如果客户选择取消，用例结束。如果客户选择输入新的支付信息，用例从第5步重复。

第三个技术是把可选项放在用例文档的其他部份，那个部份称为可选途径部份，它紧接着大体途径（表9）。那个方式的优势是大体途径很容易明白得，同时又有足够的空间来展现可选项的细节。可是缺点是查找关于每一可选项的所有信息时，必需阅读好几页文档。

表9 利用可选途径部份的订购货物用例

事件流： 基本路径： 1. 当客户选择订购货物时用例开始； 2. 客户输入他的姓名和地址； 3. 客户输入产品代码 4. 对每个输入的产品代码 c) 系统显示产品描述和价格； d) 系统在该客户的订单中添加这个物品的价格 5. 客户输入信用卡支付信息； 6. 客户选择submit； 7. 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息； 8. 当支付被确认后，订单也被标记上已经确认，同时返回给客户一个订单ID，用例结束。 可选路径： 在第7步，如果有任何不正确的信息，系统提示客户修改这些信息； 在选择submit之前的任何时候，客户可以取消这次订购，用例结束； 在第8步，如果支付没有确认，系统将提示客户去修正支付信息或取消。如果客户选择修正信息，就回到基本路径的第5步，否则用例结束。

表9中的可选项部份能够用与大体途径相同的方式书写，见表10。 事件流： 基本路径： 1. 当客户选择订购货物时用例开始； 2. 如果客户只输入邮编，系统提供城市。 3. 客户输入他的姓名和地址； 4. 客户输入产品代码 5. 对每个输入的产品代码 e) 系统显示产品描述和价格； f) 系统在该客户的订单中添加这个物品的价格 循环结束。 6. 客户输入信用卡支付信息； 7. 客户选择submit； 8. 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息； 9. 当支付被确认后，订单也被标记上已经确认，同时返回给客户一个订单ID，用例结束。 可选路径： 可选项1：不正确的数据 1. 如果有任何不正确的信息，可选项就从基本路径的第8步开始； 2. 系统提示客户修正错误的信息； 3. 基本路径从第8步开始继续执行。 可选项2：取消 1. 在订购货物用例的任何时候，客户都可能选择取消； 2. 系统提示客户验证是否取消； 3. 客户选择“OK”键，用例结束。

可选途径细化到什么程度？很多情形下，没必要写下整个的步骤序列，只需要用简练的话描述可选途径引发的变更。

3.8

场景

任意一条贯穿用例的特定途径，咱们称为场景。上述订购货物的用例中，包括的场景有一个正确付款的完整的账单抵达；缺少支付的定单抵达；缺少送货地址的定单抵达。

3.9

关联用例和执行者

咱们已经把用例的细节写出来了，明白谁开始用例――执行者，可是咱们尚未考虑如何以图示的形式表示执行者和用例之间的关系。它们之间的关系是通过通信关联表示的，启动方向是通过在通信关联中添加箭头实现的。咱们用例子来讲明，见图3和图4。

由客户启动订购货物用例由系统启动的获得订单状态用例OrderingOrder state客户客户图3图4

4 高级用例

开发了大体用例以后，系统分析员可能会发觉有必要对大体用例进行优化。用于优化的技术有包括、扩展、继承和接口。

但是，咱们的目的是制作一个清楚易懂的文档。因此，关于最终用户，唯一的优化技术是包括（Include）。其它技术――扩展（Extend）、接口（Interface）和继承（Inheritance）只是开发人员感爱好的，不是最终用户关切的。

4.1

包括

若是你发觉自己常常裁剪或粘贴同一部份内容，就意味着你已经有了能够重用的通用部份了，你能够用一种包括关系来抽象这种通用行为。从概念一个你在很多地址都需要用到的步骤开始，把这些步骤放在一个用例里，然后给它命名。

比如在定单处置系统中，通过客户ID、定单ID和客户名等一系列步骤来搜索一个定单，这种搜索需要在很多的用例顶用到，包括取得定单状态、取消定单、退货等等，咱们称那个用例为搜索定单。此刻从原始用例中抽出这些步骤，把它们替换成一个引用，指向新组成的用例（表11）。

表11 搜索定单用例

1. 当客户键入订单ID、客户ID或者客户名时，用例开始； 2. 客户点击Find； 3. 如果客户键入订单ID a) 系统显示订单，用例结束 4. 如果客户键入客户名或者客户ID a) 系统返回当前客户的所有订单表 b) 客户在这个列表中选择一个订单 c) 系统显示这个订单，然后用例结束。

表12 有包括关系的取消定单用例

1. 客户键入请求取消一个订单，用例开始 2. 包含搜索订单； 3. 如果这个订单状态被确认 a) 系统标志订单取消 b) 系统通知记账系统向客户账号中加钱，用例结束； 5. 如果订单状态是已运送 a) 系统通知发货部门，用例结束。

当取消定单用例执行到搜索定单步骤的时候，就会执行搜索定单中的步骤，然后返回到取消定单继续执行以下的步骤。用例图的表示方式如下（图5）：

Cancel Order包含客户Find order图5

4.2

扩展

扩展一样用于有条件地扩展已有效例的行为，这是一种在不改变原始用例的情形下增加用例行为的一种方式。因为扩展技术不是必不可少的，咱们建议系统分析员尽可能不利用。

4.3

继承

在用例图中，继承能够在执行者或用例之间利用。继承是一个“种属”关系，其中一个元素是其它元素的一种。执行者之间的继承意味着一个执行者能够完成另一个执行者的一样任务，它也补充额外的角色，它以一样的方式与相同的用例进行交互。用例之间的继承意味

着一个用例是另一个用例的特殊的版本。那个特殊的用例从一个通用用例中继承行为或增加行为。

看一下在定单处置系统中（图2）的一个简单例子。客户和客户代表有相同的与之进行交互的用例集合。咱们通过加入执行者之间的继承能够使得用例图大为简化。见图6。

Ordering**Internet Ordering客户**Order stateTele OrderingSale Report**客户代表图6

4.4

接口

接口是为执行者、用例或二者概念的。一个接口能够告知咱们希望实体做什么。接口不是执行者或用例的一部份，是对怎么样与执行者和用例交互的一种描述。你能够为任何执行者和用例设置多个接口。

第一步：概念接口。接口由名字和操作符号组成，一个操作符号告知咱们操作发生时传输何种数据和在操作终止时将何种数据返回给咱们，操作告知咱们希望实体做什么。仍是考虑订购货物的例子，咱们发觉从库存系统中取得产品描述和价钱是必需的，咱们为库存系统概念接口如下：

表13 接口的例子

PRODUCT INFO接口 得到产品描述和价格，返回产品描述、价格、库存数量

第二步，把它们加到用例图中。执行者和接口之间直线的意思是执行者支持接口；虚线表示利用那个接口的用例，见图7。

订单处理Product Info产品信息界面更新库存界面Product Number库存系统图7

若是执行者不是人，那么那个接口将是一段程序命令，用它来与执行者进行交互。比如，若是执行者是一个网络，接口可能是TCP/IP命令。若是执行者是与定单处置系统相交互的库存系统，就需要找出什么样的命令能够发送到库存系统，这些命令将到库存系统执行者的接口。

利用接口技术的最要紧目的主若是两个问题，一个是成立用例和人机界面的联系，一个是确信誉例利用到的数据。

有关继承、接口、扩展的更进一步细节能够参考相关的文献。

5 图形化用例

咱们已经花了很多时刻为用例书写文本，可是，大伙儿都明白，一幅图表示的意思胜似千言万语，因此咱们建议适当的时候采纳图形的方式对用例进行描述。

所谓适当的时候，指的是以下两种情形。一种是系统分析员明白得用户的需求，可是不能准确地用文字描述，能够借助图形描述；另一种情形是不完全明白得用户的需求，能够借助图形进一步与用户进行沟通。

图形化的方式很多，典型的有活动图和时序图。这两种图各有所长，由项目领导依照项目的特点进行选择，也能够混合利用。

5.1

活动图

活动图类似于流程图。用活动图表示的益处是，客户也能够很容易地了解它，它提供了客户和软件开发人员的一起明白得的平台。咱们先参照订购货物用例画出简单活动图，然后再扩展条件分支和循环。能够在Visio当选择“UML活动”画出活动图。

登录提交选择订购货物信息验证输入姓名和地址订购标记为未完成交易输入产品代码发送支付信息到记账系统显示产品描述和价格订购标志为已确认计算新的总量显示订单ID图8 简单的活动图例子

登录提交[选择订购货物]选择订购货物[信息完整]订购标记为未完成交易输入姓名和地址[输入产品代码显示产品描述和价格发送支付信息到记账系统[输入产品代码计算新的总量订购标志为已确认[没有更多的产品号]输入信用卡信息显示订单ID图9 增加了条件的活动图例子

登录[取消已选的货物]显示订购选择表单[选择订购货物]显示订购表单图10 选择点的例子

5.2

时序图

有些情形下可能要强调执行者和系统之间交互的图，这时能够选择时序图。时序图显示了交互的实体和它们共享的信息，时序图以时刻来安排顺序，越往底部的步骤在时刻上越晚。

时序图包括所有在图上端的执行者和代表整个系统的一个对象。在每一个实体下面有一条虚线，它代表了那个实体的生命期。可在Visio当选择“UML序列”画出时序图。

订购货物用例的时序图客户订单处理系统记账系统库存系统数据库输入信用卡信息提交验证信息保存订单（未完成交易）从账号中取钱（数额）确认保存订单（确认）订单号显示订单号

6 图解用户界面

用户界面是项目的关键之一，在项目的初期时期利用快速原型法展现用户界面，让用户利用那个界面的样本，以便及早发觉各类各样的问题。

用户界面能够用一系列的图来表示，每当用户界面有重大改动的时候，就需要一个新的界面图来表示。

关于快速原型法的详细介绍请参见《》

7 常见错误

用例图提供了一种显示系统功能的静态图，活动图是用来显示工作流程的，一样都要把用例图和活动图结合起来利用。不要在用例图中通过用例之间的箭头显示工作流程。

太多的用例。不要为每一个可能的说明编写单独的用例，而是把大体进程、可选进程和例外集成起来写入一个简单的用例。也不要把交互顺序中的每一个步骤看成一个单独的用例。

用例的冗余。若是相同的函数出此刻多个用例中，就有可能多次重写函数的实现部份。为了幸免重复，能够利用“包括”关系。

用例中包括用户界面的设计。用例应该把重点放在用户利用系统做什么，而不强调屏幕上是怎么显示的。

用例中包括数据概念。应该把数据概念集中在适用于整个项目的数据字典中。

试图把每一个需求与一个用例相联系。用例可有效地捕捉大多数所期望的系统功能，可是可能有一些需求与用户任务或执行者之间没有交互关系，这时就需要编写非功能需求、外部接口等文档。