需求建模中的重要目的是要理解系统将处理的业务问题，以理解它的行为需求。至于面向对象的开发，您应该开发以对行为需求建模的基本构件是用例模型。用例图表是标准的“统一建模语言(UML)”构件之一。用例模型有两种基本风格：基本用例模型和系统用例模型。

　　基本用例模型，通常称为商业或抽象用例模型，对行为需求的与技术无关的视图建模。

　　系统用例模型，也称为具体用例模型或详细用例模型，为行为需求的分析建模，详细描述用户将如何使用系统，同时它还提及系统用户接口方面的问题。

　　什么是基本建模？

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

　　什么是用例？

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

　　比较系统用例和基本用例

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

　　系统用例嵌入了很多实现细节。例如，登记员的概念消失并且被术语系统取代，这表示已经决定自动处理许多有关参加的琐碎事件。系统用例的作者分析和描述了由混有关于将使用什么样的用户界面的隐含决策的问题所引发的需求；而基本用例的作者不这样做。

　　系统用例提及屏幕和报告，如“UI23安全性登录屏幕”和“UI89登记摘要报告”。基本用例不引用它们。这再一次反映了实现的详细信息；某人已经决定系统将作为屏幕（或许与HTML页面相反）和打印的报告实现。然而，基本用例也可以只简单地引用主要的用户界面元素（即，屏幕和报告的基本版本），并且告诉您，这是我推荐的作法。我没有在示例2中引用UI元素，以便为您提供没有执行这些任务的示例。
因为商业规则反映系统必须实现的域的基本特征，所以两种版本都引用商业规则定义，如“BR129确定参加资格”。

　　系统用例的步骤比基本用例的步骤多。实际上，这反映了我编写用例的风格；我相信每个用例步骤应该只反映一个步骤。这种方法有几个优点：用例更容易测试，因为每条语句都更加容易理解和验证；备用课程更加容易编写，因为当语句只做一件事时更容易从语句中分支。

　　用例步骤以主动语态、而不是以被动语态编写。语句“登记员通知学生有关收费情况”比语句“学生被登记员通知有关收费情况”更加简洁。

　　两个版本都以类似“用例结束”或“在某些情况下用例结束”的步骤结束，以表示已经完全定义了操作过程的逻辑。

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