第三部分UML基础(第三章节用例).pptVIP

第三部分UML基础 --第三章用例、用例建模 用例模型是把应满足用户需求的基本功能集聚合起来表示的强大工具。 对于正在构造的新系统，用例描述系统应该作什么； 对于已构造完毕的系统，用例则反映了系统能够完成什么样的功能。 构建用例模型，是通过开发者与客户或最终使用者共同协商完成的。他们要反复讨论需求的规格说明，达成共识，明确系统的基本功能为后阶段的工作打下基础。 用例模型的基本组成部件是：用例、角色和系统。 1、用例：用于描述系统的功能。也就是从外部用户的角度，观察系统应支持哪些功能；帮助分析人员理解系统的行为。它是对系统功能的宏观描述。 一个完整的系统中通常包含若干个用例，每个用例具体说明应完成的功能，代表系统的所有基本功能集。 2、角色：是与系统进行交互的外部实体，它可以是系统用户，也可以是其它系统或硬件设备，总之凡是需要与系统交互的任何东西都可以称作角色。 3、系统的边界线以内的区域即用例的活动区域，则抽象表示系统能够实现的所有基本功能。 非必须，但在未熟悉之前，最好画出。 在一个基本功能集已经实现的系统中，系统运转的大致过程是： 外部角色先初始化用例 然后用例执行其所代表的功能 执行完后，用例便给角色返回一些值（这个值可以是角色需要的，来自系统中的任何东西）。 在用例模型中，系统仿佛是实现各种用例的“黑盒子”。 我们只关心该系统实现了哪些功能，并不关心内部的具体实现细节（比如系统是如何做的、用例是如何实现的）。 用例模型主要应用在工程开发的初期——进行系统需求分析时使用，通过分析描述，使开发者在头脑中明确需要开发的系统功能有哪些。 引入用例的主要目的是： 确定系统应具备哪些功能，这些功能是否满足系统的需求（开发者与用户协商达成共识的东西）。 为系统的功能提供清晰一致的描述，以便为后续的开发工作打下良好的交流基础，方便开发人员传递需求的功能。 为系统验证工作打下基础。通过验证最终实现的系统能够执行的功能是否与最初需求的功能相一致，保证系统的实用性。 从需求的功能（用例）出发，提供跟踪进入系统中具体实现的类和方法，检查其是否正确的能力。 特别是为复杂系统建模时，常用用例模型构造系统的简化版本 精化系统的变化和扩展能力，使系统不要过于复杂； 然后利用该用例模型，跟踪对系统的设计和实现有影响的用例。 简化版本构造正确之后，通过扩展，完成复杂系统的建模。 用例模型由用例图构成。用例图中显示角色、用例和用例之间的关系。 用例图在宏观上给出模型的总体轮廓；而用例的真正实现细节描述，则以文本的方式书写。 用例图所表示的图形化的用例模型（可视化模型），本身并不能提供用例模型必需的所有信息。 也就是说从可视化的模型只能看出系统应具有哪些功能，每个功能的含义和具体实现步骤，必须使用用例图和文本描述，它记录着实现步骤。 在进行定义系统，发现角色和用例、描述用例、定义用例之间的关系、验证最终模型的有效性等工作时，需要建立用例模型。 不同的人员需要从不同的角度使用用例模型： 客户或最终用户使用用例模型，因为它详细说明了系统应有的功能集，且描述了系统的使用方法。这样当客户选择执行某个操作之前，就能知道模型工作起来是否与他的愿望相符合。 开发者使用它，因为它帮助开发者理解系统应该作些什么工作，为其将来的开发工作（比如建造其它的模型、架构的设计和实现）奠定基础。 系统集成和测试的人员使用它，因为它可用于验证被测试的实际系统与其用例图中说明的功能集是否一致。 此外，还有涉及市场、销售、技术支持和文档管理这些方面的人员也同样关心用例模型。 用例模型也就是系统的用例视图，用例视图在建模过程中居于非常重要的位置。影响着系统中其它视图（比如逻辑和物理架构的构建）和解决方案的实现，因为它是客户和开发者共同协商、反复讨论确定的系统基本功能集。 3.1 用 例 图 在UML 语言中，用例模型（也就是用例视图）是由用例图描述的。 用例模型可以由若干个用例图组成。用例图中包含系统、角色和用例等三种模型元素。 图示用例图时，既要画出三种模型元素，同时还要画出元素之间的各种关系（通用化、关联、依赖）如图3-1所示 用例内容即该用例所代表功能的具体实现过程，通常用普通的文字书写在UML语言中，用例内容被看作用例元素的文档性质。 另一种描述用例内容的工具，是活动图。用例图与活动图相比，前者的描述更易被用户理解，也易于同其他用户交流信息。 3.2 系 统 系统是用例模型的一个组成部分，代表的是一部机器或一个商务活动等等，而并不是真正实现的软件系统。 系统的边界用来说明构建的用例模型的应用范围。比如一台自助式售货机（被看作系统）应提供售货、供货、提取销售款等功能，这些功能在自动售货机之内的区域起作用，自动售货机之外的情况不考虑。 准确定义系统的边界（功能）并不总是容易的事，因为严格地划