需求分析与用例建模

第二章需求分析与用例建模
2．1 需求分析阶段的工作
需求分析是一项软件工程活动，它包括：
1.需求获取
a)刻画出软件的功能和性能；
b)指明软件与其他系统元素的接口；
c)建立软件必须满足的约束。

2.需求建模
需求分析建立起来的模型为日后软件设计人员提供了可被翻译成数据、体系结构、接口和过程设计的模型。

3.需求规格说明
需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。

4.需求评审
a)需求分析研究的对象是用户的要求。

b)必须全面理解用户的各项要求，准确表达被接受的用户要求。

c)只有经过确切描述的软件需求才能成为软件设计的基础。

相应地，需求分析的过程可以分成四个阶段：
1.问题识别（需求获取）
a)研究系统的可行性分析报告和软件项目实施计划。

b)从系统角度来理解软件并评审用于产生计划估算的软件范围是否恰当；
c)确定对目标系统的需求；
d)提出这些需求实现条件，以及需求应达到的标准。

2.分析与综合（需求建模）
a)进行各种要求的一致性检查；
b)逐步细化所有的软件功能；
c)分解数据域，分配给各个子功能；
d)找出系统各成分之间的联系、接口特性和设计限制。

e)判断是否存在不合理的用户要求或用户尚未提出的潜在要求。

f)综合成系统的解决方案，给出目标系统的详细逻辑模型。

3.需求描述：编制需求分析阶段的文档
a)软件需求规格说明SRS；
b)初步的用户手册 User Guide；
c)确认测试计划；
d)修改和完善软件开发计划。

4.需求评审(验证）
作为需求分析阶段工作的复查手段，应该对功能的正确性、文档的一致性、完备性、准确性和清晰性，以及其它需求给予评价。

本实验指导书将主要介绍面向对象的分析建模技术。

2．2 用例建模的步骤
2.2.1 用例图中的重要概念
•参与者(Actor)
参与者(Actor)是系统外部的一个实体(可以是任何的事物或人)，它以某种方式参与了用例的过程。

参与者通过向系统输入或请示系统输入某些事件来触发系统的执行。

参与者由他们参与用例时所担当的角色来表示。

参与者包括人(Human Actor)和外部系统参与者(System Actor)。

系统的用户是人参与者，用户通过与系统的交互操纵系统，完成所需要的工作。

但参与者不一定是人，也可以是一个外部系统，该系统与本系统相互作用，交换信息外部系统可以是软件系统，也可以是个硬设备，例如在数据录入设备中的扫描仪，自动化生产系统上的数控机床等。

注意参与者之间也可以有继承等关联关系。

例如下图所示：本科生和研究生均是学生。

本科生
研究生
图2.1 参与者继承关系示意图
•用例(Use Case)
用例是对一个系统或一个应用的一种单一的使用方式所作的描述，是关系单个活动者在与系统对话中所执行的处理行为的陈述序列。

用例是一个叙述型的文档，用来描述参与者(Actor)使用系统完成某个事件时的事情发生顺序。

用例是系统的使用过程，更确切地说，用例不是需求或者功能的规格说明，但用例也展示和体现出了其所描述的过程中的需求情况。

用例描述活动者与系统交互中的对话。

例如，活动者向系统发出请示做某项数据处理，并向系统输入初始数据，系统响应活动者的请示进行所要求的处理，把结果返回给活动者。

这种对话表达了活动者与系统的交互过程，它可以用一系列的步骤来描述。

这些步骤构成一个“场景”(Scenario)，而“场景”的集合就是用例。

全部的用例构成了对于系统外部可见的描述。

从这些定义可知，用例是对系统的用户需求(主要是功能需求)的描述，用例表达了系统的功能和所提供的服务。

•用例间关系
用例除了与其参与者发生关联外，还可以具有系统中的多个关系，这些关系包括：泛化关系、包含关系和扩充关系。

应用这些关系是为了抽取出系统的公共行为和变体。

1)泛化关系(Generalization)
一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。

用例间的泛化关系和类间的泛化关系类似，即在用例泛化中，子用例表示父用例的特殊形式。

子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变已继承的行为。

当系统中具有一个或多个用例是较一般用例的特化时，就使用用例泛化。

2)包含关系(Include)
虽然每个用例的实例都是独立的，但是一个用例可以用其它更简单的用例来描述。

一个用例可以简单地包含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作饮食关系。

在这种情况下，新用例不是初始用例的一个特殊例子，并且不能被初始用例所代替。

饮食关系把几个用例的公共步骤分离成一个单独的被包含用例。

用例间的包含关系允许包含提供者用例的行为到用户用例的事件中。

把包含用例称为客户用例，被包含用例称为提供者用例，包含用例提供功能给客户用例。

要使用包含关系，就必须在客房用例中说明提供者用例行为被饮食的详细位置。

这一点和功能调用有点类似，事实上，它们在某种程序上具有相似的语义。

3)扩展关系(Extend)
一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系。

扩展关系是把新行为插入到已有用例的方法。

基础用例提供了一组扩展点(Extension points)，在这些扩展点中可以添加新的行为，而扩展用例提供了一组插入片段，这些片段能够被插入到基础用例的扩展点。

基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。

事实上，基础用例没有扩展也是完整的，这一点与包含关系有所不同。

一个用例可能有多个扩展点，每个扩展点也可以出现多次。

但一般情况下，基础用例的执行不会涉及扩展用例的行为，如果特定条件发生，扩展用例的行为才被执行，然后流继续。

扩展关系为处理异常或构建灵活系统框架提供了一种有效的方法。

2.2.2 用例建模的主要步骤
1.调查系统需求
2.确定系统范围和系统边界
3.确定用例和行为者
4.描述用例
5.用例分类
6.建立用例图
7.定义用例的层次结构
2．3 案例分析：某高校艺术类招生考试管理系统的需求分析和用例建模
在本节中，我们选取一个实际开发案例作为实验指导的示范案例。

该案例将贯穿整个实验指导书，旨在演示整个系统分析设计的过程和思路。

同时，在下一节中，还提供了一些单独的实验指导，并附有详细的使用Rational Rose进行用例建模的过程，帮助大家加强实践，完成练习。

普通高等院校的招生工作是由教育部网上录取系统统一进行的。

但一些特殊类别的考生录取，例如艺术类、体育类等，高校需要在进行专业课考试和文化课考试之后自主录取。

这里选取的就是苏州大学艺术类招生考试管理系统的原型。

2.3.1 需求概述
艺术类招生考试管理系统主要工作分为两个阶段：高考前专业课考试管理阶段和高考后的考生录取阶段，由此可初步构造两个用例，如图所示。

考生录取处理必须依赖于专业考试处理的结果，即具有被录取资格的考生必须是经过专业课考试并获得合格证者。

考生录取处理
图2.2 艺术类招生考试管理系统总体用例图
经与用户的沟通，确认招生考试管理需包括的工作，概括起来有：
z专业考试评分，即提供评分专家现场评分。

z考生基本信息处理，即对考生基本信息的录入、修改、删除等。

z考生专业成绩处理，即对考生专业成绩（包括考试状态等）的录入、核对等。

z考生文化成绩处理，即对考生文化成绩的录入、核对等。

z专业考试合格证处理，即通过预测合格线等操作，最终确定专业考试合格线和打印合格证等。

z预录取处理，即通过预录取策略的设置来获取预录取的名单并提供手工调整预录取功能。

z最终录取处理，即设置最终录取名单。

z信息查询，包括专业总分和专业考试合格证查询、预录取结果查询等。

z报表，包括专业考试总报表和录取总报表，以及相关统计报表等。

z数据导入导出，包括考生基本信息导入、考生专业分数、文化分数的导入，以及专业考试合格名单导出、预录取、录取结果导出等功能。

z系统基本信息维护，如用户信息、日志查询、编号表维护、系统参数维护等。

系统的用户应包含校领导、招生办公室领导、招生办公室工作人员（包括信息录入员等）和其他相关部门的相关人员等；对不同类型的用户，对应不同的使用权限，这些权限将由招生管理人员自行配置。

其中最主要的用户是大学招生办公室的招生人员，他们本身熟悉艺术类招生的相关政策和工作流程，会中文输入，能够使用VFP等工具手动地完成整个艺术招生流程。

同时，他们具有使用教育部网上招生系统的经验，并形成了一定的操作习惯。

因而YSZS系统应做到界面友好，能提供帮助和纠错，并尽可能满足用户的操作习惯。

对于工作量较大的信息录入人员，系统力求做到操作简单方便，帮助用户提高输入速度和正确率。

2.3.2 用例建模
与系统核心功能相关的主要有两种用户：招生人员与信息录入员。

招生人员负责协调整个招生工作，可以参与到招生工作的各阶段中；而信息录入员则主要负责考生信息与考生成绩录入工作。

在用例建模中这两种用户被定义为行为者。

下面主要细化已提出的两个用例：考生录取处理与专业考试处理。

1)专业考试处理功能可分为：
z专业考试基础信息维护
z考生基本信息处理
z考生专业成绩处理
z专业考试合格证处理
z招生计划信息处理
2)考生录取处理功能可分为
z各省文化考试基础信息维护
z考生文化成绩处理
z考生志愿信息处理
z预录取处理
z最终录取处理
根据以上分析，构造第二层用例图如下，
(f
招生计划信息处理
图2.3专业考试处理用例图
用例建模的过程，除了图之外，还必须给出必要的解释。

否则，建模是不完整的。

图2.3的解释如下。

该图是对图2.2的“专业考试处理”功能的细化。

如图，“专业考试处理”用例包含（include）了“专业考试基础信息维护”等5个子用例。

其中信息录入员因为权限的关系，仅参与“考生基本信息处理”和“考生专业成绩处理”两个用例，而且在这两个子用例中间也只有录入信息和核对信息的功能，不能做信息的修改。

而招生人员具备所有用例中的处理功能（除录入员的录入功能外）。

5个子用例之间也有一定的关联，首先，“考生基本信息处理”子用例依赖于“专业考试基础信息维护”子用例，这是因为，“考生基本信息处理”中间的部分内容（如考生的考试课目），是由该考生的报考的专业决定的，而专业的情况，是“专业考试基础信息维护”的功能。

类似的，“考生专业成绩处理”子用例依赖于“专业考试基础信息维护”和“考生基本信息处理”子用例，这是因为，要进行考生专业成绩的录入，维护等工作，必须在考生的基本信息和考生所报考专业的考试信息都完整的情况下进行。

“专业考试合格证处理”子用例依赖于“招生计划信息处理”和“考生专业成绩处理”
子用例，这是因为发放专业考试合格证的前提是考生专业成绩和招生计划都处理完毕。

(f
最终录取处理
图2.4考生录取处理用例图
图2.4是图2.2中“考生录取处理”功能的细化，解释如下。

如图，“考生录取处理”包含（include）了“各省文化考试基础信息维护”等5个子用例。

信息录入员参与了“考生文化成绩处理”和“考生志愿信息处理”2个子用例，并且仅有录入信息和核对信息的权限，不具有修改和维护的权限。

招生人员具备所有用例的处理功能（除录入员的录入功能外）。

5个子用例之间也具备一定依赖关系。

“考生文化成绩处理”子用例依赖于“各省文化考试基础信息维护”子用例，因为要录入并维护考生的文化成绩，前提是该考生所在省份所考类别的文化课课目的信息是完整准确的。

“预录取处理”子用例依赖于“考生志愿信息处理”和“考生文化成绩处理”两个子用例，因为考生志愿、文化成绩、专业成绩、招生计划（后两者需要依赖“专业课考试处理”用例，图2.4无法表示，可从图2.2中看到）决定了预录取的结果。

“最终录取处理”是一个审批和微调的过程，需要依赖于“预录取处理”的结果。

2．4 实验指导：如何在Rose中构建用例图
为了加深读者对前面章节介绍知识的理解，本节通过实例系统来说明用例图的创建过程。

需要说明的是，在本节以及后面的静态、动态和物理建模部分，我们选取的实例是终端销售系统和剧院售票系统的简化模型，二者之间虽有关联但又有所区别，这样安排的目的旨在读者在阅读、分析和比较建模实例的基础上能更快达到触类旁通的效果。

下面将具体介绍如何使用Rational Rose建立系统用例图。

2.4.1 实例系统背景介绍
实例1：终端销售系统[1]
终端销售系统主要用于大型购物超市的销售业务处理，主要包括：顾客挑选的商品在收银台前被识别，顾客可以通过现金或银行卡两种方式进行结账。

当某些条件被满足时，收银台自动转入快速模式以加快收银速度。

收银员可以通过收银台上的特定按钮切换回正常模式，指示灯的颜色指示收银台当前所处模式。

该终端销售系统亦提供订购商品、改变商品价格、生成各种报表、计算每家供应商交货到指定企业的平均时间等相关功能。

具体来讲，以顾客挑选的商品在收银台前被识别，顾客可以通过现金或银行卡两种方式进行结账为例，详细描述如下：a. 顾客带着挑选好的商品来到收银台前准备结账，收银员准备一次新交易。

b. 收银员通过键盘或条形码扫描仪输入顾客购买的商品，相同商品多于一件时，收银员可以输入商品数量，交易系统记录每一件商品及数量并小计金额。

当收银台位于快速模式时，一次结账商品数目不能超过预先定义的最大商品数目。

c. 当所有商品都已输入时，收银员指示交易系统本次交易输入结束，系统计算交易额，收银员告诉顾客所需支付的金额总数。

d. 顾客既可以使用银行卡结账也可以使用现金结账。

如果是现金结账，收银员输入接收的金额总数，系统记录接收的金额总数并计算需要找零数目。

如果是银行卡付账，输入银行卡信息，交易系统与银行系统进行通信并等待授权，只有在收到确认之后交易才会成功。

在快速模式下，只能使用现金付账。

付账完成之后，超市的库存目录被更新，完整交易记入系统日志。

实例2：剧院售票系统[2]
剧院售票系统主要由售票亭、售票终端和售票办公室应用程序组成。

售票亭接受顾客的订票请求。

顾客通过售票亭或售票员购票，预约购票只能通过售票员，售票监督可以通过该系统对售票情况进行监督。

当顾客在售票亭购票时只能使用信用卡付账，而在售票员处购票时既可以使用现金也可以使用信用卡付账。

除此之外，该系统还可以提供换票、验票等功能。

顾客订票时有如下规则：顾客可以多次订票，但每一次订票只能由一个顾客来执行。

有两种订票方式：个人票或套票；前者只预订一张票，后者可以预订多张票，但不得少于三张且不多于六张。

每一张票不是个人票就是套票中的一张，但是不能又是个人票又是套票中的一张。

每场演出都有多张票可供预订，每张票对应一个唯一的座位号。

每次演出用剧目名、日期和时间来标识。

2.4.2 确定系统参与者
确定系统参与者首先要分析系统所涉及的问题领域和系统运行的主要任务：分析使用该系统主要功能的是哪些人，谁需要该系统的支持以完成其工作，注意：参与者可以是人，也可以是其他计算机系统和进程。

根据实例1背景介绍，可以确定以下几点：作为销售系统，顾客（Customer）自然是其最重要的参与者之一，与此同时与之直接进行交互的收银员（Cashier）也是系统中不可缺少的；从系统管理者的角度来看，超市经理（Store Manager）可以改变商品价格、订购商品、查看库存报表，仓库经理（Stock Manager）确认订购的商品，企业经理（Enterprise Manager）可以查看企业内多个超市的销售状况以及交货信息；除此之外，银行信用卡系统（Bank）、现金盒（Cash Box）、打印机（Printer）、条形码扫描仪（Bar Code Scanner）、读卡器（Card Reader）、显示灯（Light Display）等也是都是系统的参与者。

2.4.3 确定系统用例
用例是系统参与者与系统在交互过程中所需要完成的事务，识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。

针对该终端销售系统识别用例如下所示：
(1)处理销售（Process Sale）：顾客挑选的商品在收银台前被识别，顾客可以通过现金或银行卡两种方式
进行结账；
(2)管理快速结账（Manage Express Checkout）：当某些条件被满足时，收银台自动转入快速模式，以加
快收银速度。

收银员可以通过收银台上的特定按钮切换回正常模式。

指示灯的颜色指示收银台当前所处模式；
(3)订购商品（Order Products）：该交易系统提供订购商品的功能；
(4)接收订购商品（Receive Ordered Products）：检查到货商品的正确性并更新商品库存目录；
(5)显示超市报表（Show Stock Reports）：交易系统生成各种与超市相关的报表；
(6)显示交货报表（Show Delivery Reports）：交易系统能够计算每家供应商交货到指定企业的平均时间；
(7)改变价格（Change Price）：系统提供了改变商品价格的功能。

2.4.4 使用Rose绘制用例图的步骤
一般情况下，用例图是使用UML对软件系统进行面向对象建模需要绘制的第一个图，也是RUP软件过程的焦点??所在。

在用Rational Rose创建所有的模型之前，首先要新建一个工程，当然亦可跳过此步，因为打开Rational Rose默认就是一个新建工程，最后只需在结束编辑时保存即可。

下面我们将正式开始绘制我们的第一个用例图，首先在Use Case View包结点上单击鼠标右键，选择New →Use Case Diagram，如图2.5所示。

此时在Use Case View树形结构下多了一个名为NewDiagram的图标，该图标就是新建用例图的图标，单击鼠标右键为之重命名为POS，双击用例图图标，出现用例图编辑区和编辑工具栏，如图2.6所示。

图2.5 新建用例图
图2.6 用例图的编辑区和编辑工具栏
用例图编辑工具栏中的默认图标按钮是用例图创建过程中最常用的按钮，用户可以根据需要自行定制和添加工具栏中的图标按钮，操作方法如下：右键单击编辑工具栏的空白处（注意不要点到图标按钮），在弹出的菜单中选择Customize菜单项后出现“自定义工具栏”对话框，即可自行添加，如图2.7所示。

另外也可以选择菜单项View→Toolbars→Configure …来定制工具栏。

图2.7 自定义工具栏对话框
添加参与者和用例的方法相当方便，只需要在编辑工具栏中单击要添加的图标，再单击用例图编辑区的相应位置，重要的是在添加参与者和用例之后我们需要为之设置各自的属性，方法是双击添加的参与者或用例在弹出的Use Case Specification对话框中设置，如图2.8所示。

添加用例后，我们可以继续为该用例添加子图（包括用例图、时序图、协作图等），操作方法是在Diagrams 选项卡下，在空白区域单击鼠标右键添加相应子图；为了对其做更为详细的说明，通常我们还可以将它关联到一个说明文档，操作方法是在Files选项卡下，单击鼠标右键选择Insert File，如图2.9和图2.10所示。

为参与者和用例、以及用例与用例之间添加关系是绘制用例图的难点之一，参与者与用例之间一般都是关
联关系，所以在工具栏上先选择关联按钮，然后在连接参与者与用例之间拖动鼠标即可。

除了关联关系之外，用例之间的关系还包括包含关系、扩展关系和泛化关系，上述几种关系的绘制方法与前面的方法类似，只不过要在关系的属性设置窗口中选择关系的类型，如图2.11所示。

图2.8 用例属性设置对话框
图2.9 添加用例说明文档
图2.10添加用例说明文档示例
图2.11选择关系的类型
综上所述，终端销售系统相对较为完整的用例图则如图2.12所示，其中需要说明的是《extend》和《include》
之间的区别：包含关系的实质是将多个用例中的公共部分抽取出来作为一个单独的用例，这样其他用例就可以重用公共用例而不必进行重复描述。

基用例和包含用例之间存在依赖关系，实际执行时，包含用例是插入到基用例中的某个位置上的，这个位置就是扩展点。

事实上，包含关系在某种程度上也可以看作是扩展关系的一种特殊情况，也就是说扩展条件始终未真。

在通常情况下，包含关系并不指明具体的扩展点。

对于终端销售系统的用例图，需要说明的一点是：银行的信用卡子系统、打印机、读卡器、现金盒、条形码扫描仪、显示灯也是系统的参与者，这里在图中略去。

（具体的用例说明请参看前面“确定系统用例部分”）
图2.12 终端销售系统用例图
剧院售票系统售票处的用例图如图2.13所示。

执行者包括售票员、主管和售票亭。

售票亭是另一个系统，它接受顾客的订票请求。

在售票处的应用模型中，顾客不是执行者，因为顾客不直接与售票处打交道。

用例包括通过售票亭或售票员购票，购预约票，售票监督。

图2.13 售票处用例图
用例说明：
¾buy tickets：顾客通过售票亭或工作人员购票。

¾buy subscription：顾客只能通过工作人员购买预约票。

¾make charges：购票和购预约票都必须通过信用卡付账。

¾survey sales：主管对售票过程进行监督。

2．5 本章练习
1. 一台饮料自动售货机能提供六种不同的饮料，售货机上有六个按钮，分别对应于这六种饮料，顾客可通过按钮来选择所要的饮料。

每个按钮旁边有一个指示灯，用来表明该售货机中是否还有这种饮料可售。

售货机有一个硬币槽和找零槽，用来收钱和找零。

假设现在有一位顾客投币购买矿泉水，不用找零。

请给出描述上述场景的用例图。

2. 现有一医院病房监护系统，病症监视器安置在每个病房，将病人的病症信号实时传送到中央监视系统进行分析处理。

在中心值班室里，值班护士使用中央监视系统对病员的情况进行监控，根据医生的要求随时打印病人的病情报告，定期更新病历，当病症出现异常时，系统会立即自动报警，并实时打印病人的病情报告，立即更新病历。

请根据现场情景，对医院病房监护系统进行需求分析，建立系统的用例图。

3. 设计一个电子投票系统。

一次电子投票可能涉及到一个或者多个职位的竞选，每个职位的竞选涉及到多个候选人。

在一个具体的职位竞选时，投票人能看到该职位的名称以及相应的候选人（每个职位的候选人不超过5个），投票者只能为该职位选中一个候选人。

每个职位的竞选作为一屏独立的信息提交给投票者，投票机由一名监督员启动。

为了将电子信息装载到投票机上，监督员必须输入验证码。

电子信息是以文件的形式存储在服务器上的，该文件包含这次电子投票的标题以及每个职位竞选的信息。

当信息装载到投票机上时，监督员审核这些信息。

如果信息有误，监督员将终止该程序并重新装载数据；如果信息是正确的，监督员将再次输入验证码进行确认，此时投票可以开始。

每个投票者在投票前必须输入自己的身份证号码，以避免多次投票给同一候选人。

投票者可以查看每个职位的竞选信息并投票，也可以翻屏的方式返回先前的屏幕修改投票决定。

当投票结束时，投票者将看到自己给每个职位的投票结果（职位的名称和每个候选人的得票数）将以独立的一屏信息显示。

监督员在审查完这些结果后，关掉机器。

试画出上述场景的用例图。

参考文献
1. C. Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development [M]. 3rd Edition, Prentice Hall PTR, 2005.
2. J. Rumbaugh, I. Jacobson, G. Booch. The Unified Modeling Language Reference Manual [M]. 2nd Edition, Addison-Wesley, 2004.。