1、2.1 Use Case 图,1. 需求分析与用例图,2018/10/9,3,需求分析的困难性,2018/10/9,4,需求分析原则,分析软件系统的功能设置时，应该把重点放在描述软件系统的外部边界上，即重点考虑用户对软件系统的功能设置的合理性、方便性和运行效率的要求，而不应该在需求分析阶段就过多地考虑软件系统的结构和内部实现机制。这是在对软件系统进行需求分析时，应该遵循的一个重要原则,2018/10/9,5,需求分析的途径：用例图,用例视图支持产品外部功能描述的视图 用例视图从软件产品的使用者的角度而不是开发者的角度，描述用户对待开发的产品的需求，分析产品所需的功能、动态行为 因此容易理解,2
2、活动者,2018/10/9,7,(1)概述,对软件产品的需求分析就是定义软件系统的边界，包括两个方面的内容： 分析软件产品与外界的联系 确定软件产品与外界的联系时包含动态行为及其相互关系 在UML中，下列建模元素为上述两个方面的内容提供支持： 活动者(actor) 用例(use case) 它们存在于用例视图中，所在模型图： 用例图(use case diagram),2018/10/9,8,(2) 定义,活动者：位于系统之外并和系统进行交互的一类对象 用它可以对软件系统与外界发生的交互进行分析和描述 软件系统在和外界发生交互时涉及的具体的对象，在UML里，用活动者来建模,2018/10/9,
3、9,(3) 活动者建模的对象,软件系统的使用者： 软件系统的使用者要通过使用软件和系统交互，使用者处于系统之外 随着软件系统的应用领域的不同，在用例视图模型中代表系统使用者的活动者的数目也有可能不同 对于那些通用的软件产品，如：文字处理软件、网络通讯软件、图形绘制软件，它们的使用者通常是不需要分类的，只需要一个活动者就可以代表其所有的用户 对于那些专业化较强的专用软件系统，如，管理信息系统、工业生产流程控制系统等，它们的使用者随其在软件的应用领域的职责的不同，对软件的使用方式也会有所不同，例如，在一个公司的管理信息系统中，公司的管理者对信息系统的存取权限将高于公司的普通员工，有必要对软件系统的
4、使用者进行分类，多个不同的活动者将同时出现在用例视图模型中,2018/10/9,10,活动者除了可以代表作为人的软件使用者之外，还可以代表直接和软件系统交互的软件系统赖以运行的软/硬件平台以及与软件系统有信息交换的计算机外部设备 例如，绘图软件 它调用操作系统提供的图形绘制接口，控制图形在显示设备上的输出，这时可以把操作系统的的图形接口和图形输出设备用一个活动者来建模 类似的情形也可以应用于描述软件系统的计算结果的保存上，软件系统的计算结果通常都是通过操作系统的文件存取接口以文件的形式存放在计算机的外部存储器上的，在为软件系统的边界建模时，如果需要强调软件系统的结果的保存，就可以把操作系统的文
5、件存取接口和文件本身用一个活动者来代表,2018/10/9,11,3 用例,2018/10/9,13,1) 概述,指定活动者以后，需要详细描述活动者和软件系统交互的具体内容，对交互所代表的软件系统的功能进行分类，对这些功能详细指定其代表的软件系统的动态行为 在UML里，软件系统的功能和其代表的动态行为是用用例来建模的,2018/10/9,14,2) 什么是用例,用例代表系统为响应活动者引发的一个事件而执行的一系列的处理，而且这处理应该为系统作用者产生一种可见的价值 用例描述了当活动者和软件系统进行交互时，软件系统所执行的一系列的动作序列，这些动作序列不但应包含正常使用的各种动作序列，而且应包含
6、对非正常使用时软件系统的动作序列的描述 用例用来为软件系统所提供的功能及其动态特征建模，在考虑软件系统的功能划分时，要考虑功能设置的合理性和使用的方便性 一个用例代表活动者和系统的一次交互，用例视图中用例的设置，就代表了软件系统的功能的划分 为了得到合理而方便的软件系统的功能设置，必须仔细考虑每个用例代表的动态行为的内容，使得每个用例都能产生一个有价值的结果 在通过用例考虑软件系统的功能划分时，应使得功能的分布较为均衡、易于理解、易于使用，这也是用例的定义中所谓“产生可见的价值”的含义,2018/10/9,15,3) 用例的例子,假定设计开发一个名为“位图观察器(bmpviewer)”的软件产
7、品，它为用户提供图像显示和浏览的功能。经过对用户提出的功能需求的分析和整理，得出的用户期望得到的产品的功能如下： 打开一个bitmap文件 可对文件进行放大显示(Zoom-in) 可对文件进行缩小显示(Zoom-out) 可对文件进行浏览(Pan) 可将文件继续保存到磁盘,2018/10/9,16,利用用例和活动者的概念，把上述功能在通过用例在用例图上加以表达 在这里把上列的每项功能都用一个用例表示,2018/10/9,17,4) 用例与活动者的关联关系,活动者和软件系统的交互是具体地和特定的某项功能相联系的，而软件系统的功能在UML模型是用例，所以系统作用者和软件系统的交互表明了活动者和用户
8、之间存在着某种对应 为了表达活动者通过某项功能与系统交互，在UML模型中，可以通过用一条直线把活动者和用例相连接来表示,2018/10/9,18,这条直线在UML里代表关联关系 例如，图中“用户”和“打开文件”用例之间的关联关系代表用户对软件系统的打开文件功能的使用,2018/10/9,19,关联关系是UML的关系的一种，它代表两个类的对象之间的语义连接 未经过修饰的关联关系是双向的 两个类之间有关联关系，代表两个类之间可以互相访问，因而提供了它们进行交互的基础 在用例图中使用的关联关系通常被修饰为单向的关联关系，它在模型图被表示为一条带箭头的直线 单向关联关系是关联关系的一个特例，它由关联关
9、系经修饰而得，它意味着访问是有向的 在处于有向关联关系中的两个类中，位于箭头所指方向的类的对象可以被另一个类的对象访问，反之则不然,2018/10/9,20,和系统打交道的外部对象有3个，其中“用户”代表软件的使用者，它通过访问这项用例启动软件“打开文件”的功能。系统对这些事件应采取一系列的动作进行响应，响应的过程中，将访问硬盘中的数据，并更新显示 因此，有两个系统作用者与此相对应，“位图文件”，“显示窗口”：“显示窗口”代表用来显示位图的操作系统图形用户界面的一个窗口，“位图文件”代表保存在计算机外部存储器的位图文件 从这个例子也可以看到，活动者不仅仅代表人，还可以是软件或硬件系统,2018
10、/10/9,21,关联关系的有向性 在图中所示的用例中，“打开文件”对应的系统所采取的动作序列中涉及文件“读取”，但关联关系的箭头仍指向文件而不是反之。这是因为有向关联关系的箭头代表的是访问的方向，而不是数据的流向 数据文件不会（主动地）访问用例，所以对读取或保存文件，都应有同样的访问方向,5) 事件流与场景,2018/10/9,23,事件流,用例代表系统和活动者之间发生的一系列的事件，这些事件流构成了用户对系统功能的一次使用 在用例图中必须对事件流进行描述，以构成一个完备的用例模型 对事件流的描述包括四种形式，即： 形式文本 非形式文本 交互图 状态图 相应的UML成员作为这些描述的载体 文
11、本和正式文本可用注标（note）表示 交互图和活动图本身即是一个标准的UML成员,2018/10/9,24,主事件流（main flow of events）和次要事件流（alternative flow of events）用来区分对系统功能的合法使用和非法使用 主事件流（main flow of events）合法使用只有一个 次要事件流（alternative flow of events）可包含若干个 在描绘事件流时，必须用足够清晰的语言以使得一个普通的用户能够理解,2018/10/9,25,场景（Scenario）,一个用例可以有多个事件流，每一个事件流是一个完整的用户对系统的功能的
12、使用。 它们出于同一个目的，但出于事件流不同，使得系统产生的响应不同 这样的用例/事件流的对应关系正是前面讲到的UML公用划分机制的一个例子, 它是对系统功能使用的特例（合法或非法的）, 因此事件流是用例的实例（instance） 用例的实例在UML中被称为场景（Scenario）,6) 用例图中的关系,2018/10/9,27,(1)概述,在分析和整理活动者和系统用例的时候，可能用到： 使用关系 泛化关系 包含关系 扩展关系,2018/10/9,28,(2)使用关联,使用关联是指一个用例使用另一个用例的功能行为 使用关联用于在用例之间共享公共的功能行为 使用关联是一种泛化关联，在用例图上用一
13、个基本用例指向公共的用例的泛化箭头表示，并在箭线上标有构造型,2018/10/9,29,(3) 泛化关系,在UML中，两个类之间的泛化关系代表子类共享了超类的行为和结构。它实际上就是C+里面的类之间的继承和导出关系 在用例图中，活动者是类的变体 用例是具有类的特征的建模元素（分类符）, 因此，可以用泛化关系描述活动者或用例之间的继承,2018/10/9,30,在一个帐单管理系统中，用例 Phone Order和Internet Order在结构和行为方面存在很多相似之处。因此可以定义一个通用的用例 Place Order，来表示结构和公共的行为。抽象的用例Place Order 自身并不一定要
14、是完整的，但是它提供了一个公共的行为框架，子用例可以使自己完整,2018/10/9,31,(4) 包含关系,包含关系(include)：位于两个用例之间的包含关系意味着基用例显式地在其指定位置将另一个用例包含进来, 使其成为自己的行为的一部分 包含关系可用于提取共用的用例 在具有包含关系的两个用例中，被包含的那个用例不能单独存在，它只能以实例的形式存在于包含它的用例之中,2018/10/9,32,在一个ATM系统中，用例Withdraw Cash, Deposit Cash和Transfer Funds都需要包含系统识别客户这一功能。该行为可以提取出来作为一个新的包含用例，称为Identify
15、 Customer, 它被其它三个基用例所包含。这些基用例独立于具体的识别方法，该方法被封装在包含用例中。从基用例的观点看，它们不关心用户识别是从银行磁卡上识别出来的还是从视网膜扫描上识别出来的。它们只需要Identify Customer的结果, 就是客户的标识符 另一方面，从Identify Customer用例的角度看，它不关心基用例是如何使用客户标识的或者在执行它之前，发生了什么识别的方法始终是一样的,2018/10/9,33,2018/10/9,34,(5) 扩展关系,扩展关系：两个用例之间的扩展关系，代表基用例可以隐式地包含另一个用例作为其行为的一部分，包含的位置间接地由另一个用例
16、（扩展用例）确定。基用例可以独立于扩展用例单独存在 当一个用例有多个子流程时，可以用扩展关系对其进行扩展，使得此基用例的不同子流程能在不同的情形下以扩展用例的形式被激活 UML把包含关系和扩展关系表示为依赖关系的变体，而在某些工具（如ROSE）中，它们被表现为泛化关系的变体 ，在任何一种图形表示中，箭头所指的模型元素分别代表被包含的用例或被扩展用例(基用例), 而包含关系和扩展关系的变体标记分别是和,2018/10/9,35,2018/10/9,36,例子: 在电话系统中，用例Place Call由抽象用例Show Caller Identity扩展. 这是一个可选的服务，一般以 “Calle
17、r ID”来引用, 该服务可能被或不被接收方所需要。对从Show Caller Identity到Place Call 的扩展关系可以描述如下: 条件: Receiving party must have ordered the service “Caller ID“ 扩展点 (s): Show Identity insert the whole Show Caller Identity use case 我们也可以给扩展关系赋予多重性标记, 如果它被省略，那么就是1,2018/10/9,37,2018/10/9,38,Place Call用例将添加以下的内容: 扩展点Conference C
18、all发生在 第11步后. 扩展用例Place Conference Call可以描述成: Place Conference Call 用例 该用例扩展了Place Call. 它插在扩展点 Conference Call处. 基本流: 1. 呼叫方压下hang-up, link, 或者 flash 按钮. 2. 系统将产生三声短的嘟嘟声表示确认 312. 13.呼叫方从用例Place Call重新连接到接收方。,与基用例有312步骤的相同并不是好的现象。解决该问题的方法是将该公共部分放到一个包含用例中,2018/10/9,39,Retinal scan,Check password,Place rush order,在扩展关系中它是,基用例,，在特,定情形下，其动作,序列被,Place rush,order,扩展,扩展用例，它扩,展了,“,基用例,“Place order,的动,作序列,泛化关系,Track order,Place order,视网膜扫描,2018/10/9,40,作业,请使用用例图描述一个你所熟悉的软件系统,
