业务用例模型实际上就是企业经营业务的一种描述，为了建立完整、准确的企业用例模型，应该将注意力专注于企业的业务做了些什么事情，而不应该集中于如何做。虽然这样可能会产生一些业务用例相冲突，相重复的情况，但是RUP的思想在于迭代，这项工作完全可以在接下去的迭代周期内完善。
业务用例模型是和企业业务最贴近的计算机模型。它的很多思想和企业日常经营如出一辙。在企业的日常活动中，业务的种类可能有很多种。在一些讲述ERP思想的文章中，通常会强调三类：
一种是和主营业务密切相关的工作，例如银行的营业部、信贷部、押汇部等。这种工作通过人的劳动，将一种资源转变为另一种资源，产生价值。
一种是管理型的工作，例如公司的管理层，财务部门等。这种工作本身并不产生价值，但是它通过指导、管理、检测第一种工作，加大第一种工作的产出价值。
还有一种称为支持工作，例如系统管理、安全等。它并不是很重要，具有支持其他工作的性质。
业务模型同样可以使用这种分类。通过这种分类，可以更好的把握核心业务用例，为下一步的工作打好基础。
有很多业务用例是由业务主角触发的，RUP中也把和业务主角有关联关系的业务用例称为核心业务用例（Core Business Use Case）。这强调了构建业务模型的目的是为了提供以用户为中心的服务。这也是我们建立业务用例的时候应该注意的。
当然，有时候业务用例的触发是为了产生用户需要的结果。例如企业的市场调查行为就不是由业务主角触发，而是企业积累了大量用户请求的结果。而对于管理型、支持型的，不直接和业务主角的客户类发生联系，但是也有其特定的业务主角，如管理型的业务用例需要和董事会为发生联系，支持型的业务用例可能和供应商发生联系。
在建立了基本的业务用例模型之后，对此模型进行精化是非常有必要的，这时候，在上一章中我们介绍的用例的扩展关系和使用关系就有了用武之地。除了这两种关系，还有一种新的关系。
7. 在业务建模中使用关系
泛化关系（Generalization）：根据我的理解，可以把它看作我们比较熟悉的继承关系很相似的一种关系。Generalization一词含有一般化、概括的意思。它是一个相对抽象的词。虽然它和继承关系非常相似，但是它们在使用环境和产生目的方面都有相异之处。下图描述了四个业务实体之间的泛化关系：
文章来源于领测软件测试网 https://www.ltesting.net/
