第3 章 静态建模用例和用例图

第3 章 静态建模用例和用例图
        用例模型是把应满足用户需求的基本功能(集)聚合起来表示的强大工具。对于正在
构造的新系统，用例描述系统应该作什么；对于已构造完毕的系统，用例则反映了系统能够。完成什么样的功能构建用例模型是通过开发者与客户（或最终使用者）共同协商完成的，他们要反复讨论需求的规格说明，达成共识，明确系统的基本功能，为后阶段的工作打下基础。
       用例模型的基本组成部件是用例、角色和系统。用例用于描述系统的功能，也就是从
外 部用户的角度观察，系统应支持哪些功能，帮助分析人员理解系统的行为，它是对系统功能的宏观描述。一个完整的系统中通常包含若干个用例，每个用例具体说明 应完成的功能，代表系统的所有基本功能（集）。角色是与系统进行交互的外部实体，它可以是系统用户，也可以是其它系统或硬件设备，总之，凡是需要与系统交 互的任何东西都可以称作角色。系统的边界线以内的区域（即用例的活动区域）则抽象表示系统能够实现的所有基本功能。在一个基本功能集已经实现的系统中，系 统运转的大致过程是外部角色先初始化用例，然后用例执行其所代表的功能，执行完后用例便给角色返回一些值，这个值可以是角色需要的来自系统中的任何东西。
        在用例模型中，系统仿佛是实现各种用例的“黑盒子”，我们只关心该系统实现了哪
些功能，并不关心内部的具体实现细节（比如系统是如何做的？用例是如何实现的？）用例模型主要应用在工程开发的初期，进行系统需求分析时使用通过分析描述使开发者在头脑中明确需要开发的系统功能有哪些。
引入用例的主要目的是：

• 确定系统应具备哪些功能，这些功能是否满足系统的需求（开发者与用户协商达成共识的东西）。
• 为系统的功能提供清晰一致的描述，以便为后续的开发工作打下良好的交流基础，方便开发人员传递需求的功能。
• 为系统验证工作打下基础。通过验证最终实现的系统能够执行的功能是否与最初需求的功能相一致，保证系统的实用性。
• 从需求的功能（用例）出发，提供跟踪进入系统中具体实现的类和方法，检查其是否正确的能力。特别是为复杂系统建模时，常用用例模型构造 系统的简化版本（也就是精化系统的变化和扩展能力，使系统不要过于复杂），然后，利用该用例模型跟踪对系统的设计和实现有影响的用例。简化版本构造正确之 后通过扩展完成复杂系统的建模。

        用例模型由用例图构成用。例图中显示角色、用例和用例之间的关系。用例图在宏观
上给出模型的总体轮廓，而用例的真正实现细 节描述则以文本的方式书写。用例图所表示的图形化的用例模型（可视化模型）本身并不能提供用例模型必需的所有信息。也就是说，从可视化的模型只能看出系统 应具有哪些功能，每个功能的含义和具体实现步骤必须使用用例图和文本描述（它记录着实现步骤）。
        在进行定义系统，发现角色和用例、描述用例、定义用例之间的关系，验证最终模型
的 有效性等工作时，需要建立用例模型。从另一个角度来说，有各种不同的人员需要使用用例模型。客户（或最终用户）使用它因为它详细说明了系统应有的功能 （集）且描述了系统的使用方法，这样当客户选择执行某个操作之前，就能知道模型工作起来是否与他的愿望相符合；开发者使用它，因为它帮助开发者理解系统应 该作些什么工作，为其将来的开发工作（比如，建造其它的模型、架构的设计和实现）奠定基础；系统集成和测试的人员使用它因为它，可用于验证被测试的实际系 统与其用例图中说明的功能（集）是否一致；还有涉及市场、销售、技术支持和文档管理这些方面的人员也同样关心用例模型。
        用例模型也就是系统的用例视图。用例视图在建模过程中居于非常重要的位置，影响
着系统中其它视图（比如逻辑和物理架构）的构建和解决方案（满足基本功能需求）的实现，因为它是客户和开发者共同协商反复讨论确定的系统基本功能（集）。
        开发者既可以把用例视图用于构建一个新系统的功能视图。还可以把已有的用例视图
修改或扩充后产生新的版本，也就是在现有的视图上加入新功能（即在视图中加入新的角色和用例）。