UML软件工程组织
为基本用例建模
Scott W. Ambler
总裁，Ronin International  2000 年 7 月 20 日
 
基本建模
用例
比较
示例 1
示例 2
参考资料
关于作者
　
基本建模是以使用为核心的设计的基本方面。本周 Scott Ambler 介绍有关开发基本用例模型的一些背景知识和建议。

需求建模中的重要目的是要理解系统将处理的业务问题，以理解它的行为需求。至于面向对象的开发，您应该开发以对行为需求建模的基本构件是用例模型。用例图表是标准的“统一建模语言 (UML)”构件之一。用例模型有两种基本风格：基本用例模型和系统用例模型。
  • 基本用例模型，通常称为商业或抽象用例模型，对行为需求的与技术无关的视图建模。
  • 系统用例模型，也称为具体用例模型或详细用例模型，为行为需求的分析建模，详细描述用户将如何使用系统，同时它还提及系统用户接口方面的问题。


什么是基本建模？
基本建模是以使用为核心的设计的基本方面——它是一种软件开发方法，Software for Use 一书（请阅读参考资料）详细描述了该方法。基本模型旨在通过与技术无关、理想化和抽象的描述来表示问题本质。产生的设计模型更加灵活，它使更多选项公开并且在技术方面更容易进行更改。基本模型比具体表示法更加强健，这是因为在需要更改需求和更改实现技术时，它们更易保持有效。用法的基本模型强调目的，即用户试图实现什么任务以及他们这样做的原因。简而言之，基本模型是表示系统需求的理想构件。

什么是用例？
用例是向参与者提供重要价值的操作序列。认识它的另一种途径是：用例描述实际参与者与系统交互的方式。基本用例是一种简化、抽象且通用的用例，它以独立于技术和实现的方式描述用户的意图。基本用例是一种结构化的叙述，用应用程序领域和用户的语言来表达，它包含对任务或交互的简化、通用、抽象、与技术无关且独立于实现的描述。从担当某个（或某些）系统角色的用户的观点来看，基本用例是完整而有意义的，并且设计得很好，这就体现了交互背后的目的或意图。

比较系统用例和基本用例
请仔细查看示例 1 和示例 2 提供的两种版本的用例“参加研习班”，前者显示了简化的系统用例（也称作传统或具体用例），后者将它表示为基本用例。经过观察，我们会发现以下一些有趣事项：

  1. 系统用例嵌入了很多实现细节。例如，登记员的概念消失并且被术语系统取代，这表示已经决定自动处理许多有关参加的琐碎事件。系统用例的作者分析和描述了由混有关于将使用什么样的用户界面的隐含决策的问题所引发的需求；而基本用例的作者不这样做。
  2. 系统用例提及屏幕和报告，如“UI23 安全性登录屏幕”和“UI89 登记摘要报告”。 基本用例不引用它们。这再一次反映了实现的详细信息；某人已经决定系统将作为屏幕（或许与 HTML 页面相反）和打印的报告实现。然而，基本用例也可以只简单地引用主要的用户界面元素（即，屏幕和报告的基本版本），并且告诉您，这是我推荐的作法。 我没有在示例 2 中引用 UI 元素， 以便为您提供没有执行这些任务的示例。
  3. 因为商业规则反映系统必须实现的域的基本特征，所以两种版本都引用商业规则定义，如“BR129 确定参加资格”。
  4. 系统用例的步骤比基本用例的步骤多。实际上，这反映了我编写用例的风格；我相信每个用例步骤应该只反映一个步骤。这种方法有几个优点：用例更容易测试，因为每条语句都更加容易理解和验证；备用课程更加容易编写，因为当语句只做一件事时更容易从语句中分支。
  5. 用例步骤以主动语态、而不是以被动语态编写。语句“登记员通知学生有关收费情况”比语句“学生被登记员通知有关收费情况”更加简洁。
  6. 两个版本都以类似“用例结束”或“在某些情况下用例结束”的步骤结束，以表示已经完全定义了操作过程的逻辑。

通常，传统或系统用例本身对有关基本技术实现和有待设计的用户界面方面所作的假设太多，通常是隐藏的或暗示的。在分析和设计期间，这是一个较好的特性，但对于您的需求实现来讲，并不理想。另一方面，基本用例基于用户的目的或意图，而不是基于实现目的或意图可能依据的具体步骤或机制。编写基本用例作为所需的构思工作的一部分，然后在分析和设计期间，将它们发展成系统用例。

示例 1：“参加研习班”系统用例

名称： 参加研习班

描述：
允许有资格的学生参加研习班。

前提：
是在校注册学生。

结果：
在学生有资格且有空位的条件下，允许学生参加他们想参加的课程。

基本行动过程：

  1. 学生想参加研习班。
  2. 该学生从“UI23 安全登录屏幕”将他的姓名和学号输入系统。
  3. 系统根据“BR129 确定参加资格”商业规则来验证该学生是否有资格参加学校里的研习班。
  4. 系统显示指出可用研习班列表“UI32 研习班选择屏幕”。
  5. 学生指定他想参加的研习班。
  6. 系统根据“BR130 确定学生参加研习班的资格”商业规则来确认该学生是否有资格参加研习班。
  7. 系统根据“BR143 验证学生研习班课程表”商业规则来验证研习班是否适合该学生的现有课程表。
  8. 系统根据课程分类表中公布的费用、相应的学生费用和相应的税来计算研习班的费用。使用“BR 180 计算学生费用”和“BR45 计算研习班税款”商业规则。
  9. 系统通过“UI33 显示研习班费用屏幕”显示费用。
  10. 系统询问该学生是否仍然想参加本次研习班。
  11. 该学生表示他想参加研习班。
  12. 系统允许该学生参加研习班。
  13. 系统通过“UI88 研习班注册摘要屏幕”通知该学生注册成功。
  14. 系统根据商业规则“R100 为学生开具研习班帐单”给该学生开出参加本次研习班的费用帐单。
  15. 系统询问该生是否想打印注册报告书。
  16. 学生表明他想打印报告书。
  17. 系统打印注册报告书 -“UI89 注册摘要报告书”。
  18. 当学生拿到打印的说明后，用例结束。



示例 2：“参加研习班”基本用例

名称： 参加研习班

描述：
允许有资格的学生参加研习班。

前提：
是在校注册学生。

结果：
在学生有资格且有空位的条件下，允许学生参加他们想参加的课程。

基本行动过程：

  1. 学生想参加研习班。
  2. 学生将他的姓名和学号提交给登记员。
  3. 登记员根据“BR129 确定参加资格”商业规则来验证该学生是否有资格参加学校里的研习班。
  4. 学生从可用的研习班清单中指定他想要参加的研习班。
  5. 登记员根据“BR130 确定学生参加研习班的资格”商业规则来确认该学生是否有资格参加研习班。
  6. 登记员根据“BR143 验证学生研习班课程表”商业规则来验证研习班是否适合该学生的现有课程表。
  7. 登记员根据课程分类表中公布的费用、相应的学生费用和相应的税来计算研习班的费用。使用“BR 180 计算学生费用”和“BR45 计算研习班税款”商业规则。
  8. 登记员通知学生有关费用情况。
  9. 登记员验证学生是否仍想参加研习班。
  10. 该学生表示他想参加研习班。
  11. 登记员允许该学生参加研习班。
  12. 登记员根据商务规则“BR100 为学生开具研习班帐单”将适当的费用添加到学生的帐单中。
  13. 登记员向学生提供他已进行的确认。
  14. 用例结束。

参考资料
有关用例建模的详细信息，请参阅：

关于作者
Scott W. Ambler 是 Ronin International 的总裁，该公司是一家专门提供面向对象软件过程指导、体系结构建模和 Enterprise JavaBean (EJB) 开发的咨询企业。他自己著作了或者与其他人合著了几本有关面向对象开发的书籍，包括最近出版的 The Object Primer 2nd Edition，该书详细介绍了本文所概述的主题。可以通过 scott.ambler@ronin-intl.com 和他的网站 www.ambysoft.com 与他联系。
版权所有：UML软件工程组织