UML系统分析与设计教程(第2版) 课件 第6章 用例图.ppt

ZhenyanJiZhenyanJi*UML系统分析与设计SystemAnalysisDesign冀振燕北京交通大学第六章用例图用例图参与者用例用例图的应用UML系统分析与设计第2版ZhenyanJi*UML系统分析与设计第2版ZhenyanJi*用例图用例模型描述的是系统外部的参与者所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和最终用户反复讨论的结果，也是开发者和用户对需求规格定义达成的共识。用例图用例模型描述了待开发系统的功能需求将系统看作黑盒，从外部参与者的角度来理解系统驱动了需求分析之后各阶段的开发工作，用例不仅在开发过程中保证了系统所有功能的实现，还被用于验证和检测所开发的系统是否满足系统需求，从而影响到开发工作的各个阶段和UML的各个模型。UML系统分析与设计第2版ZhenyanJi*UML系统分析与设计第2版ZhenyanJi*用例图用例图的3种建模元素用例(UseCase)参与者(Actor)依赖关系、类属关系和关联关系。用例图描述了用例、参与者以及它们之间的关系。用例图UML系统分析与设计第2版ZhenyanJi*UML系统分析与设计第2版ZhenyanJi*用例图参与者和用例之间存在的关联关系通常被称为通信关联，因为它代表着参与者和用例之间的通信。这个关联可以是双向导航（从参与者到用例，并从用例到参与者），也可以是单向导航（从参与者到用例，或从用例到参与者）。导航的方向表明了是参与者发起了和用例的通信，还是用例发起了和参与者的通信。UML系统分析与设计第2版ZhenyanJi*用例图在UML中用来实现用例的元素是协作（Collaboration），协作是实现用例行为的类和其他元素的总称。如图所示，可以用协作“Dealwithbill”（处理账单）来实现用例“Payforbill”（付账单）。通常，每个给定的用例都会由一个相应的协作来实现，所以大多数情况下不必显式地为这种关系建模。UML系统分析与设计第2版ZhenyanJi*参与者参与者（Actor）代表了与系统接口的事物或人，它是具有某一种特定功能的角色。因此，参与者是虚拟的概念，它可以是人，也可以是外部系统或设备。同一个人可能对应着多个参与者，因为一个人可能扮演了多个角色。参与者不是系统的一部分，它们处于系统的外部。UML系统分析与设计第2版ZhenyanJi*参与者如何识别参与者？可以通过回答一系列问题●谁是系统的主要用户？ ●谁从系统获得信息？●谁向系统提供信息？ ●谁从系统删除信息？●谁支持、维护系统？ ●谁管理系统？●系统需要与其他哪些系统交互（包含其他计算机系统和其他应用程序）？●系统需要操纵哪些硬件？ ●在预设的时间内，有事情自动发生吗？●系统从哪里获得信息？ ●谁对系统的特定需求感兴趣？●几个人在扮演同样的角色吗？ ●一个人扮演几个不同的角色吗？●系统使用外部资源吗？ ●系统要用在什么地方？UML系统分析与设计第2版ZhenyanJi*参与者识别参与者需要注意：参与者代表角色。当建立用例模型时，参与者是用来模拟角色的，而不是用来模拟物理的、现实世界的人、组织或系统本身。角色不是对职位进行建模。UML系统分析与设计第2版ZhenyanJi*参与者UML系统分析与设计第2版ZhenyanJi*用例用例（UseCase）是对系统行为的动态描述可以增进系统设计人员、开发人员与用户的沟通，正确地理解系统需求；还可以划分系统与外部实体的界限。用例是系统设计的起点，是类、对象、操作的来源，可以通过逻辑视图的设计，获得软件的静态结构。UML系统分析与设计第2版ZhenyanJi*用例如何识别用例？可以通过以下问题帮助识别：●每个参与者的任务是什么？●有参与者要创建、存储、改变、删除或读取系统中的信息吗？●什么用例会创建、存储、改变、删除或读取这个信息？●参与者需要通知系统外部的突然变化吗？●需要通知参与者系统中正在发生的事情吗？●什么用例将支持和维护系统？●所有的功能需求都能被用例实现吗？UML系统分析与设计第2版ZhenyanJi*用例在描述用例事件流时，每个软件项目都应使用一个标准模板。下面给出一个目前应用最广泛的模板。 X.用例XX（用例名）的事件流 X.1前置条件（Pre-Conditions） X.2后置条件（Post-Conditions） X.3