《软件开发生命周期与统一建模语言UML》-曹静-子教案04.pptVIP

第4章 用例图 4.1 用例概述 4.1.1 用例建模的目的 4.1.2 定义用例图 4.1.3 用例图的主要组件 4.2 识别参与者 4.2.1 捕获需求 4.2.2 识别参与者 第四章 用例图 4.3 识别用例 4.3.1 识别用例的方法 4.3.2 用例的命名规则 4.4 用例间的关系 4.4.1 泛化关系 4.4.2 包含关系 4.4.3 扩展关系 4.5 用例文档 第四章 用例图 4.6 重构系统的用例模型 4.7 用例建模实例——书店借书系统 4.7.1 建立用例模型的步骤 4.7.2 确定系统边界 4.7.3 识别参与者 4.7.4 识别用例 4.7.5 建立用例图 4.7.6 书写用例文档 4.7.7 通过关系整理用例 第四章 用例图 教学要求 掌握：用例图定义、用例图的标记符组件以及如何建立用例图模型。 理解：用例图建模的原因、泛化技术，以及包含与扩展关系。 了解：描述用例的方法。 4.1 用例图概述 用例建模的目的 利用“系统”的观点来分析问题、解决问题。 使用计算机逻辑来模拟描述系统本身，包括系统的组成、关系、系统的各种可能状态以及系统中可能产生的过程和过程引起的切换。 可以利用一个容易理解的模型来描述用户如何使用这个系统、系统和客户以及系统和外部系统之间的交互过程，这个模型也就是通常我们所说的使用UML设计新系统的起始点——用例图。 4.1 用例图概述 定义用例图 用例图是有关系统细节的最高形式。它能准确地说明客户对他们要开发的应用程序期望有什么样的功能 用例图是一种在系统完成后能使管理机构、用户和其他干系人了解其功能的极好方法。 4.1 用例图概述 用例图的主要组件 用例图包含4个基本组件：参与者（Actor）、用例（Use Case）、关系、系统。 （1）参与者。参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。 （2）用例。用例代表系统的某项完整的功能，是动作步骤的集合。系统的功能是通过参与者使用用例来实现的。 4.1 用例图概述 用例图的主要组件 用例图包含4个基本组件：参与者（Actor）、用例（Use Case）、关系、系统。 （3）关系。除了用例和参与者之间的关联关系以外，还可以定义参与者之间的泛化关系，用例之间有包含、扩展和泛化关系。 （4）系统。系统指一个软件系统、一项业务、一个商务活动、一台机器等。 (图见书) 4.2 识别参与者 捕获需求 收集需求的方式有访谈、问卷调查、实地观察、使用原型、特定群体调查、用户指导等。需求的来源主要是人、各种现有成品（如报表、培训手册、视频记录等）、现有的软件系统或人工系统。 通过各种形式记录下收集到的需求信息，经过整理，从中获取有价值的信息来建立系统模型。 4.2 识别参与者 识别参与者的方法 识别参与者的思路，可以从以下几个方面来考虑： （1）谁使用系统的主要功能？ （2）谁改变系统的数据？ （3）谁从系统获取信息？ （4）谁需要系统的支持以完成日常工作任务？ （5）谁负责维护、管理并保持系统正常运行？ （6）系统需要处理哪些硬设备？ （7）系统需要和哪些外部系统交互？ （8）谁对系统运行产生的结果感兴趣？ （9）有无时间、气温等内部或外部条件？ 4.3 识别用例 识别用例的方法 在识别用例的过程中，可以从以下几个方面来考虑： （1）特定参与者希望系统提供什么功能。 （2）系统是否存储和检索信息，如果是，由哪个参与者触发。 （3）当系统改变状态时，是否通知参与者。 （4）是否存在影响系统的外部事件。 4.3 识别用例 用例的命名规则 用例名是一个字符串，用例是从用户的角度来描绘系统的功能，因此命名的基本原则是：从参与者的角度出发进行命名（如使用“登录”而不用“身份验证”），使用动词加宾语的结构，尽量使用行业术语（如使用“报销”，而不用“交钱”）。 系统中用例太多时需求要适当分组（包），这时可以通过在用例名后面加上双冒号和包名来表示该用例是属于哪个包的。 4.4 用例间的关系 泛化关系 用例与用例之间也存在着泛化关系，通常用于表示同一业务目的（父用例）的不同技术实现（各个子用例）。 4.4 用例间的关系 包含关系 在包含关系中，基本用例吸收了被包含的用例的行为，如果没有后者它将是不完整的。 包含关系的划分有两个好处：一是被包含用例被抽取出来，基本用例得以简化；二是可以抽象出公共事件流，实现功能代码的复用。 4.4 用例间的关系 扩展关系 如果在完成某个功能的时候有时会执行另一个功能，则用扩展关系来表示。扩