2.3 需求分析建模

2.3.1 用例建模

多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求，系统地阐述成用使用用例（Use Case）的方法进行需求获取和建模。虽然使用用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心怎样开发软件。用例是系统开发中用来描述系统需求，从用户的角度描述系统的场景，概括有关参与者和用例信息的一个图形化模型，描述了系统、子系统和类的一致的功能集合，表示了角色和用例之间的关系，表现为系统和一个或多个外部交互者（角色）的消息交互动作序列，主要包括系统、用例、角色和关联。用例组成如图2-3所示。

其中，一个用例可描述软件系统和一个外部角色（Actor）之间的一次交互。角色可以是人、软件、硬件或其他与系统交互的实体。如用户、外部系统和外部处理，通过建立关联与系统交互，如图2-4所示。

（1）扩展关系：若一个用例中加入一些新的动作后构成一个新的用例。

（2）使用关系：当一个用例使用另一个用例时，这两个用例构成使用关系。

（3）组合关系：用例之间存在类似的行为，或相互之间存在必要的关系，可以将相关的用例以封装方式加以组合。

一个使用用例描述了系统和一个外部“执行者”（Actor）的交互顺序，这体现执行者完成一项任务并给某人带来益处。执行者是指一个人，或另一个软件应用，或一个硬件，或其他一些与系统交互以实现某些目标的实体。执行者可以映像到一个或多个可以操作的用户类的角色。例如，图2-5所示的“图书馆的管理系统”中的“请求出借图书”使用用例包括一个名为“请求者”的执行者。在“图书馆的管理系统”中设有一个客户类叫请求者，但是图书管理员和图书供应商均可充当这一角色。使用用例为表达用户需求提供了一种方法，而这一方法必须与系统的业务需求相一致。分析者和用户必须检查每一个使用用例，在把它们纳入需求之前决定其是否在项目所定义的范围内。基于“使用用例”方法进行需求获取的目的在于：描述用户需要使用系统完成的所有任务。在理论上，一个用例就是系统向用户提供的一个有价值结果的某项功能，使用用例的结果集将包括所有合理的系统功能。

用例通过描述“系统”和“活动者”之间的交互来描述系统的行为。用例模型在需求分析中很重要，它从用户的角度看待系统，是用户导向的，用户可以根据自己所对应的用例来不断细化自己的需求。建立用例模型的顺序是：

（1）确定谁会直接使用该系统。它们都会成为参与者（Actor）。

（2）选取其中一个参与者。

（3）定义该参与者希望系统做什么，参与者希望系统能够提供的服务成为一个用例。

（4）对每件事参与者何时会使用系统，通常会发生的操作过程成为用例基本过程。

（5）描述该用例的基本过程。

（6）考虑可变情况，创建相应的扩展用例。

（7）复审不同用例的描述，找出其中相同点作为共同的用例。

（8）重复步骤（2）～（7），找出每一个用例。

2.3.2 数据建模

通常大型系统中都要处理大量的数据，使用大型数据库，系统需求分析建模就是定义系统处理的数据的逻辑结构。比较广泛采用的数据建模技术是实体-关系建模，它描述了数据实体以及实体之间的关系和相关的属性，基本图形表示如图2-6所示。

例如，两个实体学生和教师的关系，如图2-7所示，表明了教师教学生，学生被教师教授之间的关系。

实体（Entity）：需要一个概念来抽象地表示一组类似事物的所有实例，称这个概念为实体。是需要收集数据和存储数据的人、地点、对象、事件或概念的类。可以归类为：

（1）人（Persons）：代理、承包商、客户、部门、分部、雇员、导师、学生、供应商。

（2）地点（Places）：销售地区、建筑物、房间、分支办公室、校园。

（3）对象（Objects）：图书、机器、部件、产品、原材料、软件许可证、软件包、工具、汽车模型、汽车。

（4）事件（Events）：奖励、取消、分类、飞行、开发票、订单、注册、续借、获取、预订、销售、旅行。

（5）概念（Concepts）：账号、时间段、债劵、课程、基金、资格、股票。

属性：是实体的描述性性质或特征。包括基本属性和复合属性，基本属性是实体的一条特定信息，如学生实体中的姓名、学号等；而复合属性是包括许多相关属性的属性，如生日是由年月日三个基本属性组成。每个属性都有相应的数值和取值范围。

构造数据模型的方法为：

● 获取实体；

● 上下文数据模型；

● 基于键的数据模型；

● 概化层次体系，确定子类与超类的继承关系；

● 具有完整属性的数据模型，确定属性。

2.3.3 过程建模

在需求分析阶段，数据流（也称信息流）是系统分析的基础。所谓数据流，形象地说就是系统中“流动的数据结构”。数据流图（Data Flow Diagram, DFD）从数据传递和加工的角度出发，刻画数据流从输入到输出的移动和变换过程，它能够清晰地反映系统必须完成的逻辑功能。

对于大多数数据处理系统来说，从数据流的角度来描述一个企事业组织的业务活动是比较合适的。数据流图描述了一个组织有哪几个组成部分，也描述了来往于各部分之间的数据流。

1．数据流图的基本成分

数据流图有四种基本符号，如图2-8所示。矩形代表数据源点或终点，圆形（或圆角矩形）代表数据加工，两条平行线（或开口矩形）代表数据存储，箭头代表数据流。

（1）数据的源点或终点。数据的源点或终点用于反映数据流图与外部实体之间的联系，表示图中的输入数据来自哪里或处理结果送向何处。

（2）数据流。箭头代表数据的流向，数据名称总是标在箭头的边上。

（3）加工。加工也称为数据处理，是对系统中的数据流进行的某些操作或变换。图中每个加工都要有对应的名称，最常见的名称是由一个表明具体动作的动词和一个表明处理对象的名词构成的，如登录成绩、统计成绩等。

（4）数据存储。在数据流图中用于保存数据的数据文件被称为数据存储，它可以是数据库文件或任何其他形式的数据组织。

注意：加工与文件之间数据流的方向，如果加工要读文件，则数据流是从文件流出的；如果加工要写文件或修改文件，则数据流是流向文件的；如果加工既要读文件又要写文件，则数据流是双向的。

一般来说，除了流向文件或从文件流出的数据流不必命名外，每个数据流必须有一个合适的名字。名字一方面是为了区别，同时也是给人一个直观的印象，使人容易理解这个数据流的含义。为数据流命名时，可从其组成成分或含义的角度来考虑，在图2-9中，“取款单”和“合理取款单”的组成是相同的，但后者是经检查后认为合理的（如它的“账号”和“户名”相符），这样的命名就易于理解。

数据流图的基本要点是描绘“做什么”，而不考虑“怎么做”。通常数据流图要忽略出错处理，也不包括诸如打开和关闭文件之类的内部处理。

2．数据流与加工之间的关系

在数据流图中，可以有两个以上的数据流进入同一个加工，也可以有两个以上的数据流从同一个加工中流出，这样的多个数据流之间往往存在一定的关系。为了表示这些数据流之间的关系，需要在数据流图中给这些数据流对应的加工加上一定的标记符号。在表2-3中列出了加工中常见的几种关系的表示方法（表中以从加工流入或流出两个数据流为例）。

【例2-1】 设一个工厂采购部每天需要一张订货报表。订货的零件数据有：零件编号、名称、数量、价格、供应者等。零件的入库、出库事务通过计算机终端输入订货系统。当某零件的库存数少于给定的库存量临界值时，就应该再次订货。

数据流分析：

● 数据源点：仓库管理员（负责入库或出库事务给订货系统）；

● 数据终点：采购员（接收每天的订货报表）；

● 数据流：事务，订货；

● 数据存储：订货信息，库存清单；

● 处理：处理事务，产生报表。

（1）数据流。数据流可以从加工流向加工，也可以从加工流向文件或从文件流向加工，也可以从源点流向加工或从加工流向终点，如图2-10所示。

应该注意的是，数据流图中描述的是数据流而不是控制流。图2-11中“取下一张卡片”是一个控制流而不是数据流，因为并没有任何数据沿着这个箭头流动，所以这个箭头应该从图中删去。

（2）加工。加工是对数据进行的操作。图2-10中“处理事务”、“产生报表”等都是加工。加工的名字也应适当地反映这个加工的含义，使之容易理解。

每个加工还有一个编号，编号说明这个加工在层次分解中的位置。

（3）文件。文件是暂时存储的数据。图2-10中有“库存清单”、“订货信息”等文件。文件的名字也应适当地选择，以便理解。

注意：加工与文件之间数据流的方向，如果加工要读文件，则数据流是从文件流出的；如果加工要写文件或修改文件，则数据流是流向文件的；如果加工既要读文件又要写文件，则数据流是双向的。

在图2-10中，加工“处理事务”要检查库存清单中是否有需要的货物，因此要查阅库存清单文件，如果有所需要的货物，库存清单文件需要进行修改，因此，该文件是可读写的文件，采用双向箭头；同时，在缺货情况下需要将缺货情况写入到订货信息文件中，该文件采用单箭头只写方式；如果是只读文件，图中的箭头从文件流出。

（4）源点和终点。一个数据处理系统的内部用数据流、文件和加工三种成分表示一般已够了，然而为了便于理解，有时还可以画出数据流的源点和终点来说明它的来龙去脉。

源点和终点通常是存在于系统之外的人员和组织，在图2-10中，“仓库管理员”是数据流“事务”的源点，“采购员”是数据流“订货报表”的终点。画出源点和终点只是起到注释作用，帮助理解而已，所以源点和终点的表达不必很严格。

除了上述四个基本成分之外，根据具体情况，数据流图中也可画出一些物质流。物质流可用粗箭头表示（如图2-12所示）。由于物质流与数据流往往是密切联系的，如一批货物同描述这批货物的清单一起从某个部门发出，在数据流图中画上物质流可能有助于理解，但是这类信息到最后总要从数据流图中抹去，因为软件系统只能处理数据流而不能处理物质。

数据流图中也可用*号表示“与”，用⊕号表示“或”。

图2-13表达的是：加工P执行时，需要用到数据流A“与”数据流B，而P输出数据流X“或”数据流Y。

3．数据字典

虽然数据流图能够形象、清晰地描述数据在系统中流动、加工、存储的情况，但数据流图中的许多构成要素，如数据流、数据存储、加工，仅依靠名称并不能反映出其本质含义，因此必须对这些构成元素进行严格的定义。作为对数据流图的补充，数据字典（Data Dictionary, DD）能够准确地定义数据流图中各组成成分的具体含义。

数据流图与数据字典是密切联系的，两者结合在一起才构成需求说明书。数据流图中出现的每一个数据流名、每一个文件名和每一个加工名在词典中都应有一个条目给出这个名字的定义。

（1）数据字典的基本符号。数据字典中可有以下四种类型的条目：数据流、文件、数据项、加工。

为了能够对数据流图中的各组成成分进行准确的定义，在数据字典中使用了多种特定含义的符号，如表2-4所示。

①数据流条目。数据流条目给出某个数据流的定义，它通常是列出该数据流的各组成数据项。例如：

● 数据流“成绩”由学号、姓名、班号、考试编号等数据项组成，则字典中的“成绩”条目是：

成绩=考试编号+学号+姓名+班号+课程名称+分数

● 数据流“学生成绩”由学号、姓名及若干行“课程名称”和“分数”等组成，则字典中“学生成绩”条目是：

学生成绩=学号+姓名+{课程名称+分数} +总分+平均分

②文件条目。文件的定义通常是列出其记录的组成数据项，还可指出文件的组织方式。例如：

③数据项条目。数据项条目给出某个数据单项的定义，通常是该数据项的值类型、允许值等，例如“账号”这个数据项的值可以是00000～99999之间的任意整数，则字典条目“账号”可写成账号=00000-99999，又如数据项“存期”可取1、3、5、8等几个值，则字典条目“存期”可写成：

存期=[1|3|5|8]

上面是采用公式的形式定义，但表现的内容不够丰富，下面介绍比较常用的字典条目的定义方法。

（2）数据字典中的条目及说明格式。数据字典是关于数据流图中各种成分详细定义的信息集合。可将其按照说明对象的类型划分为四类条目，分别是数据流条目、文件条目、数据项条目和加工条目。为了便于软件开发人员方便地查找所需的条目，应按照一定的顺序对字典中的不同条目进行排列。

【例2-2】 例2-1订货系统中部分卡片形式的数据定义，如图2-14所示。

4．加工说明

加工说明是对数据流图中每个加工所做的说明，由输入数据、加工逻辑和输出数据组成。加工逻辑阐明把输入数据转换为输出数据的策略，是加工说明的主体。

特别应注意的是：分析阶段的任务是理解和表达“用户的要求”，而不是具体考虑系统怎样实现的。所以对一个加工应描述的是用户要求这个加工“做什么”，而不是用编程语言来描述具体的加工过程。

加工说明通常用结构化语言（Structured Language）、判定表（Decision Table）或判定树（Decision Tree）作为描述工具。每个加工说明可以像字典中的条目一样记在卡片上。以下将分别对三种描述手段和加工说明卡片进行简单介绍。

（1）结构化语言。结构化语言是介于自然语言和形式化语言之间的一种半形式化语言，简单易懂。

结构通常可分为两层：外层和内层。外层主要描述逻辑的控制结构，如顺序、选择、循环，比较具体，可以借用某种程序设计语言提供的流程控制语句。内层比较灵活，可由分析员根据系统的具体特点以及用户的接受能力灵活决定，一般采用动宾结构的自然语言，主要描述“做什么”。

（2）判定表。判定表采用表格化的形式，适用于表达含有复杂判断的加工逻辑。条件越复杂，规则越多，越适宜用这种表格化的方式来描述。如果需要，还可在判定表中加上结构化语言，或者在结构化语言写的说明中插进判定表，以充分发挥它们各自的表现特长。

判定表的结构如图2-15所示，通常由4部分组成，其间用双线条或粗线条分开，左上部用于列出所有相关的条件，右上部用于列出所有可能的条件组合，左下部用于列出所有可能产生的动作，右下部用于列出在各种组合条件下需要进行的动作。