第五章 系统分析
一、系统分析概述
三、事物、对象及其关系属性
二、事件和事件的描述
四、需求建模
五、需求建模实例
一、系统分析概述
1、系统分析的用户视图
分析的目的：分析现实世界的 事物如何转化到计算机世界，使信息系统能最
终达到原来现实世界的目的。
分析的结果：产生对现实世界一组准确、完整、一致并且可以检验的系统模
型。
系统
拥有
者
系统
用户
系统
设计
者
系统
实施
者
关注数据 关注处理 关注接口 关注通信 系统开发
商务知识
数据需求
数据库范式
数据库程序
系
统
分
析
员
关注者
系
统
分析
与
设计
方
法
学
处
理
过
程 数据库
管理系统
销售与
咨询商
商务功能
处理需求
应用范式
与说明
商务地点
接口需求
通信环境
通信需求
系统分析阶段数据、功能和交互行为板块的用户视图
2、模型驱动的分析方法
模型驱动的方法强调对现有系统和目标系统采用图示的系统模型
来建立文档和提供验证手段。
用例图：功能视图 类图：数据视图 状态图：功能视图 顺序图：功能视图
功能模型 对象模型 动态模型
分析模型
3、系统分析中使用的逻辑模型
（ 1）事件和事件表
事件的相关要素：触发原因、消息来源、完成的动作、做出的响
应、事件要达到的目的。
（ 2）数据流
（ 1）结构化分析要素
要传递的数据集合
（ 3）数据流图
（ 4）实体 — 关系图
表示系统逻辑功能和信息联系的一种图形,
表示系统要素之间关系的一种图形。
（ 2）面向对象分析要素
（ 1）类图
类图反映系统的静态结构，类的实例对象具有行为，行为是系统
的动态特征，反映在特定的结构之下各组成部分的执行逻辑
类的表示
类名
属性 1
属性 2
操作 1（）
操作 n（）
类的类型 ?活动者类：代表出现在用例模型中的活动者
?业务类：描述业务的地点、物品、概念和事件
?用户界面类：是组成系统用户界面的屏幕显示、菜单和报表
类的属性
属性是描述对象静态特征的一个数据项。属性有属性名和属性值。
属性描述隐藏在对象内部的信息，由该对象的服务专门操作。
类的服务（操作）
服务也称为方法或操作，是信息系统为满足用户需求必须采取的
行动，是信息系统对事件的响应。
服务的定义取决于具体问题域和功能需求，应遵循信息隐藏原理，
执行单一的、高度内聚的功能。一个服务可以通过发送消息请求另
一个服务的支持。
类之间的联系 ?泛化 —特化
?聚合（整体 —部分）
?关联
?消息传递
泛化 — 特化联系
泛化 —特化联系反映类之间的一种继承关系
订单
邮件订单 电话订单 网上订单
聚合联系
也称整体 —部分联系。反映各组成部分和整体之间的关系。
计算机
内存 显示器 CPU 外存 键盘
1
1 1
1 1 1
1
1 1….* 1….*
关联联系
类之间的一种二元关系，表达对象之间的静态联系
教师 学生 0….* 1
（ 2）用例图
用例图描述系统的环境和系统的功能需求。
用例图中的关系
用例图中的关系有活动者与用例之间的关系和用例与用例之间的关系。
?活动者与用例之间的关系称为关联，描述活动者与用例之间的关系
?用例之间的关系：包含关系、扩展关系、泛化关系
?关联：表示参与者与其参与执行的用例之间的通信路径
?扩展：在基础用例上插入基础用例不能说明的扩展部分 <extend>
?包含：在基础用例之上插入附加行为，并具有明显描述 <include>
?泛化：用例之间一般与特殊的关系，其中特殊用例 (子用例）继承了一
般用例（父用例）的特性，并增加了新的特性。
包含的使用：如果两个以上的用例有大量一致的功能，可将该功能分解到另
一个用例中；一个用例功能太多时，可以用包含关系建立两个小用例。
包含与扩展的区别,
?在包含关系中一个用例总是在使用另一个用例的功能
?在扩展关系中，是根据某些条件有选择地使用另外一个用例功能。
下订单 查目录
查询产品 查供应商
安排付款
付现今 付支票
<extend>
<include>
<include> <include>
子用例
父用例
扩展用例
客户
（ 3）顺序图
显示场景或用例表中所发生的交互，它侧重于对消息时序的描述。
（ 4）协作图
协作图强调对象之间的关系组织，而不是对象之间信息传递的
时间性。协作图将消息名称前加上顺序号。
（ 5）状态图
状态图用于描述具有复杂动态行为的对象，表示一个对象状态
的演变。状态图的关键成分是状态和状态的转换
闲置
冷却
激活
预热
过冷
温度到达
过热
温度到达
过冷
加热
准备 /开关合上
过热 恒温器对象的状态图
（ 6）活动图
表现于一组事件相连的多个对象的状态变化，强调在计算过程
中顺序和并发的步骤
带泳道的活动图
请求服务
取订单
填写订单 付款
分发订单
收集订单
客户 销售 库房
二、事件和事件的描述
1、事件和系统需求
事件是指发生在确定的时间和地点，可以描述、并应该被系统记
录下来的事实。
系统分析首先应当考察对系统产生影响的外部事件。
2、事件的类型
（ 1）外部事件
由外部实体或动作参与者所引发的事件。外部事件将影响系统，
触发系统内部进行一系列工作。识别外部事件的关键点,
?外部实体对系统的数据输入
?由外部实体的需要而触发的系统内部事务处理
?外部实体想要获取某些信息
?外部实体的变化引发系统内部数据需要更新
（ 2）定时事件
又称临时事件。是由于系统到达某一时刻系统内部自动发生的事件。时
间事件是内部事件。
（ 3）状态事件
识别定时事件和状态事件的关键点,
?内部处理需要的临时输出结果；
?系统应当对外给出的结果；
?系统内部相关要素的状态依赖关系。
是系统内部由于某个要素状态的改变而触发其他要素状态改变的事件。
状态事件是内部事件。 。
3、识别事件
（ 1）准确区分事件、条件、响应和行为
例：用电客户到银行交纳电费的例子。
事件：用电客户交纳电费；
条件：有信用卡；卡上有足够的钱；
响应：银行从客户信用卡上划拨费用
如何区分事件与响应：判断两者能否分割开来。
（ 2）列出事件的时间顺序
通过跟踪事件处理的生命周期，列出事件的时间顺序。
（ 3）技术选择和系统控制
技术实现和系统控制也将引发一系列事件，这类事件大多在系统设计
阶段识别，但部分也需要在分析阶段识别。
4、事件列表
事件列表中要包括：事件、触发器、来源、动作、响应、目的地，六
大要素。
?触发器：事件与系统的接口。
?动作：事件消息传递给系统后，系统引发的一系列动作和行为。
?响应：系统对所发生事件的输出结果，可能是一个结果，也可能是一系
列其他事件或动作。
?目的地：系统产生结果的送达地。可能是外部实体、参与者，或内部调
用的其他系统。
事件 触发器 来源 动作 响应 目的地
客户申请办
理电子钱包
填写申请表并递交
给相关银行柜台
客户 核对客户身份证，检查客
户银行帐户和信用状态
登记客户自然情况，分配
密码，冲值，制成卡片
客户
例：“申办电子钱包”事件的事件列表
三、事物、对象及其关系属性
1、事物的类型
事物及其相关信息是系统要存储的数据。面向对象的分析中，事物是
系统交互作用的对象。运用面向对象中，类与对象的抽象机制，寻找这些
事物之间的内在关系。
通过事件列表对事件的分析，来研判相应事件影响了哪些事物。
事物
实体事物
边界事物
控制事物
实物
角色
地点位置
组织
交互行为
时间
2、对象之间的关系
对象之间发生的相互作用称为关系。对象之间的关系有一元关系、二元关
系、多元关系。
?一元关系：同一类对象之间的关系。例：人与人、部门与部门之间的关系
?二元关系：不同类对象之间的关系。例：客户与信用卡之间的关系。
?多元关系：存在于 3种或以上不同类对象之间的关系。
（ 1）对象类之间关系的图示方法
一对一的关系
客户帐号 电子钱包 1…………………1
在每个对象类端点上都有一个重数 1。
一对多的关系
在每个端点都有重数 0….n,或 *（表,1….n) 。
电子钱包 银行 1…………………*
多对多的关系
在一个端点上有一个重数 1，另一个端点有重数 0….n,或 *（表,1….n) 。
客户 银行 *…, 申办电子钱包, …*
例：一个项目有许多活动组成；一个活动有许多任务组成；一个任务消耗
若干资源，并产生若干工作成果；工作成果可以是：一个系统、一个模型、
一个文档；资源可以是：参与者、时间或设备。
用 UML的图形元素可表示为,
项目
活动
任务 工作成果 资源
文档
模型
系统 参与者
时间
设备
*由 ………,生产 消耗 ……….*
*
*
（ 2） UML描述关系的四种主要结构
依赖关系
一个对象以某种方式影响另一个对象，后者并不一定受前者影响。
聚集关系
一个对象是由其部分之和构成的关系。
关联关系
表示一般事物和特殊事物之间的关系
泛化关系
系统中对象之间发生某种联系。
3、对象的属性
属性是对类（对象）特征的描述。
系统分析关键是找出与类（对象）相关的属性。
能唯一标示一个类（对象）的属性称为关键字。
四、需求建模
1、需求的概念
面向对象的分析以用例模型描述系统的功能需求。
软件工程对需求的定义
需求包括从用户角度和从系统开发者角度描述的用户为解决某个问题
或实现某一目标，要求软件必须满足的条件或能力。
功能需求
信息系统必须包括的功能和行为。功能需求主要表现在事件列表中。
非功能需求
系统完成功能需求的能力。例如：过程方面、性能方面、外部特性方面等。
约束条件
限制系统解决方案的可选范围的需求，如硬件、软件、人员组成等。
信息系统
用户需求
约束条件 功能需求 非功能需求
常规需求 意外需求 期望需求
业务说明 分析人员经验 使用实例
由 ……,产生 由 ……,提示 由 ……,产生
2、需求描述的工具
UML需求描述 =事件表 +类图 +用例图 +交互图（顺序图、协作图） +状态图
（ 1）建立领域模型
建立领域模型是从事件表转化为类图的工作。
领域对象是系统工作环境中存在的事情或发生的事件。领域中有如下三类对象,
?现实世界的对象：表示现实世界中要通过系统处理的事物，如货物、地点等；
?业务对象：表示业务中需要进行操作的事物，如订单、合同、帐户等；
?发生和将要发生的事件：表示能够引发系统工作或对系统产生影响的事实，如
货物抵达、申请递交等。
类图、对象图的建立步骤
? 确定对象和类。包括寻找、列举和删除对象和类
?找出对象之间的关系。包括聚类、泛化、关联等
?整理对象和类之间的关系。如删除、分解关联等。
?确认对象属性。根据领域知识找出属性和属性值。
?建立数据字典。
?对类图和对象图的内容列出必要说明。
?反复修正类图和对象图。
例：从事件表到系统领域模型
客户
ID
订单
日期
货号
合同客户
合同号
付款方式
个别客户
电话
付款方式
商品条目
商品代码
目录期号
商品目录
目录期号
有效期
联系员工
员工号
1 *
1
*
*
1
*
0…1
电话订货系统事件表,
客户来电
查询客户号
查询商品目录
开订单
查询货物条目
查询客户类别
确定付款方式
……….,
（ 2）建立业务模型
业务模型除包括类图、对象图以外，还要画出用例图、活动图、顺序图
和状态图。
用例图从使用者角度描述系统。侧重从功能的角度描述业务过程的信
息，表达业务过程各个功能的组成部分，确定参与者，以及参与者使用的
业务用例。
例：电话订货系统的用例图
电话订货
查询订单
开列订单
验证客户
安排付款
审核使用
<extend>
<include>
<include>
<include>
<extend>
<extend> 客户
服务人员
例：用例图、类图、顺序图、状态图之间的关系
开列订单
验证客户
<extend>
用例图
服务人员
服务人员
订单
客户
商品条目 类图
顺序图 订单,…….,
客户,…….,
创建订单
验证客户
订单调出
订单分发 订单存档
订单入座 订单填写
订单类的状态图
例：活动图 — 描述单个业务用例的细节过程
创建订单
确认订单
提供优惠 填写订单
团体付费
信用卡付费
填写订单 个别订户 分支
同步条 团购订户
同步条
合并
（ 3）需求说明的补充
对于非功能需求，采用传统手段进行说明。内容有,
?可用性：用户可以使用系统的时间百分比。
?可靠性：系统正确运行的可靠程度。
?性能：系统功能之外增加的条件。如，容量、响应时间、带宽等。
?可支持性：为保持可维护性、可扩展性必须达到的要求。
?设计约束：对系统设计的限制。
?接口需求：系统与外部的接口，如：软件接口、硬件接口、通信接口等。
?其他需求：在线帮助、产品许可等。
? 参与者 （ Actor)是 UML的专门术语。特指 系统外部 介入系统的实体。可
以是人员、设备、其他系统等。
?参与者的输入，或请求系统输出是触发系统用例执行的根源。
?区分实体、参与者、角色。同一实体在不同用例面前可能扮演不同角色。
?业务用例中的角色经系统分析员提炼成为参与者。
3、功能分析
（ 1）识别参与者
功能分析的工作：识别参与者、定义系统边界、识别系统用例、识别用
例间的关系、建立用例模型，划分用例优先等级等。
提炼角色为参与者的步骤,
? 考虑所有可能与系统运行有关的人员、设备和其他系统；
?确定系统在输入、输出方面的参与者；
?确定系统操作和维护方面的参与者；
?将参与者 ——用户 ——角色联系起来；
?进行合理组织和合并，减少功能重叠，形成参与者和角色类别；
?对参与者命名
电话订货
查询订单
开列订单
验证客户
安排付款
审核使用
<extend>
<include>
<include>
<include>
<extend>
<extend> 客户
服务人员
（ 2）定义系统边界
大边框界定了系统边界
（ 3）识别系统用例
识别系统用例的两种方式：基于参与者的方式；基于事件的方式。
整理用例集
识别外部事件
发现服务对象
识别执行过程
创建订单
分析事件功能
识别参与者
通过系统必须
响应的外部事
件，找出系统
的边界和内外
联系
通过系统功能分
析，找出系统事
件与参与者的关
系，进而建立用
例
通过识别参与
者，确认最终
使用者和服务
对象
通过分析每个
参与者所发起
参加的执行过
程，确定转化
为用例的可能性
通过对参与者,
事件、过程、功
能及相互关系的
分析，建立用例
和用例集合
识别用例完成后，还要考虑以下问题,
? 每个参与者的特定任务是否完成？
?是否每个参与者都要从系统中创建、存储、改变、移动或读取信息？
?是否有特定任务或数据尚找不到参与者？
?是否需要将系统维护、支持的用例画上去？
?是否有其他重要的功能需求没有列上去？
（ 4）识别用例间的关系
? 用例之间也有关系之间所具有的关系，即：关联、聚集、泛化等。
?用例之间还有两种特殊的关系：包含、扩展。
包含关系,表示所触发用例的完成需要调用其他子用例。
扩展关系,表示可以选择的行为集合、特定条件下才发生的行为集合、或者不同流程等。
包含与扩展关系的区别,
? 描述的箭头方向,包含关系有主用例指向被包含用例；扩展关系由扩展
用例指向主用例。
?逻辑关系,包含关系表示只要有就必须完成的功能；扩展关系表示一种可
能的需要。
验证身份
核对 IC卡 核对密码
电话订货
查询订单
开列订单
验证客户
安排付款
审核使用
<extend>
<include>
<include>
<include>
<extend>
<extend> 客户
服务人员
（ 5）建立用例模型
使用用例图描述系统的一组用例、用例参与者、用例之间的关系和用
例与参与者之间的关系。
（ 6）划分用例的优先级
自上而下找出对系统最为重要的用例。并按以下原则对用例排序,
?以用例对系统商务模式的影响排序；
?以用例对商务模式的核心流程的影响排序；
?在每个级别内按功能实现的重要性排序；
?找出通用或实现简单的用例。
五、需求建模实例
1、学校教学管理系统需求建模
? 系统用户是：教学管理人员、教师、学生；
?系统功能：提供学生选修课程和学生成绩管理方面的服务。
（ 1）系统需求
? 学生选课管理：包括，新学期选修课程表生成、学生选课注册、
选修课查询、信息统计与报表生成、相关信息传递到财务管理系统。
?学生成绩管理：学生考试成绩录入、成绩查询、成绩汇总与报表
生成。
（ 2）确定系统范围和系统边界
? 教学管理系统的业务范围：只进行学生选课和考试成绩管理，不
包括其他教学管理；
?系统边界：本教学管理系统与学校教务管理系统和财务管理系统
有系统边界。教务管理系统只接受本系统汇总信息，不反馈；财务
系统接受相关信息，并反馈学生交费信息。
（ 3）参与者
? 学生
?教师
?教学管理人员
?教务管理系统
?财务管理系统
（ 4）确定用例
?,选修课管理”中的用例有：选修课程管理、选修课查询、选修课注册、
教师简历查询、选修课统计汇总。
?“学生成绩管理”中的用例有：学生成绩管理、学生成绩查询、学生
成绩统计汇总,
（ 5）分层用例绘制
选修课管理
学生成绩管理
教学管理员
教师
教务系统
学生
财务系统
教学管理系统
教务系统
学生成绩管理子系统
课程成绩查询
学生成绩管理
教学管理员
教师
学生
财务系统
学生成绩汇总
学生成绩查询
选修课注册
选修课管理 教学管理员 教师
学生 财务系统
选修课信息汇总
选修课查询
选修课管理子系统
教师简历查询
（ 6）用例汇总
选修课管理
学生成绩管理 教学管理员
教师
教务系统
学生
财务系统
课程成绩查询
学生成绩管理
学生成绩汇总
学生成绩查询
选修课注册
选修课管理
选修课信息汇总
选修课查询
教师简历查询
（ 7）用例之间的关系
选修课查询 教师
学生
身份验证 课程成绩查询
选修课注册
学生成绩查询
<include>
<include>
<include>
<include>
（ 8）建立对象类
主要的类如下,
?学生
?教师
?教学管理人员
?选修课表
?选课单
?课程
?成绩
（ 9）定义类之间的关系，建立类图
学生
1 教师
教学管理人员 选修课表
选课单
课程
成绩
*
1
1
*
*
1 *
* *
*
*
2、定单处理系统的用例模型
（ 1）系统包含的参与者
? 电话代理
?信用授权机构
?产品仓库系统
?货运系统
（ 2）系统与各类参与者的交互
系统与电话代理的交互
? 输入定单
?取消定单
?取消定单明细
?查询
系统与信用授权机构的交互
? 确认购买 (系统告诉信用机构通过信用卡和借记卡购买 )
?贷款帐户 (系统告诉信用机构记录帐户 )
系统与产品仓库的交互
? 请求发货
?取消发货请求
?退货处理
?查询库存
?接受订货
系统与货运系统的交互
? 运送货物
?退回定单物品
输入定单
查询
取消定单明细
取消定单 电话代理
贷款帐户
确认购买
信用授权机
构
退货处理
接受定单
取消发货请求
查询库存
请求发货
产品仓库系
统
退回定单物品
运送货物
货运系统
3、对用例模型的补充说明
? 用例功能的具体执行步骤对应着一个事件流,
?在用例模型中，有时使用场景 (scenario)来描述执行用例的一系列动作。
事件流,客户打电话给公司与定单办事员交谈。定单办事员验
证客户信息。如果是新客户，则创建一条客户记录。然后客户
请求订购产品，这会触发创建新定单。办事员确认该产品仍有
存货后，将产品订购数量添加到定单中。然后客户请求下一种
商品，办事员验证后将其加入到新定单中。最后，客户提供支
付信息，办事员对其验证。于是定单标为就绪状态，这个场景
就完成了。
异常情况,如果产品没有库存，则客户可以选择不订购该产品
或以延期定货的形式加入到定单。如果客户信誉不好，只有收
到支票后且客户还清债务时，定单才会送到客户手中。
例：客户创建电话定单的场景描述
一、系统分析概述
三、事物、对象及其关系属性
二、事件和事件的描述
四、需求建模
五、需求建模实例
一、系统分析概述
1、系统分析的用户视图
分析的目的：分析现实世界的 事物如何转化到计算机世界，使信息系统能最
终达到原来现实世界的目的。
分析的结果：产生对现实世界一组准确、完整、一致并且可以检验的系统模
型。
系统
拥有
者
系统
用户
系统
设计
者
系统
实施
者
关注数据 关注处理 关注接口 关注通信 系统开发
商务知识
数据需求
数据库范式
数据库程序
系
统
分
析
员
关注者
系
统
分析
与
设计
方
法
学
处
理
过
程 数据库
管理系统
销售与
咨询商
商务功能
处理需求
应用范式
与说明
商务地点
接口需求
通信环境
通信需求
系统分析阶段数据、功能和交互行为板块的用户视图
2、模型驱动的分析方法
模型驱动的方法强调对现有系统和目标系统采用图示的系统模型
来建立文档和提供验证手段。
用例图：功能视图 类图：数据视图 状态图：功能视图 顺序图：功能视图
功能模型 对象模型 动态模型
分析模型
3、系统分析中使用的逻辑模型
（ 1）事件和事件表
事件的相关要素：触发原因、消息来源、完成的动作、做出的响
应、事件要达到的目的。
（ 2）数据流
（ 1）结构化分析要素
要传递的数据集合
（ 3）数据流图
（ 4）实体 — 关系图
表示系统逻辑功能和信息联系的一种图形,
表示系统要素之间关系的一种图形。
（ 2）面向对象分析要素
（ 1）类图
类图反映系统的静态结构，类的实例对象具有行为，行为是系统
的动态特征，反映在特定的结构之下各组成部分的执行逻辑
类的表示
类名
属性 1
属性 2
操作 1（）
操作 n（）
类的类型 ?活动者类：代表出现在用例模型中的活动者
?业务类：描述业务的地点、物品、概念和事件
?用户界面类：是组成系统用户界面的屏幕显示、菜单和报表
类的属性
属性是描述对象静态特征的一个数据项。属性有属性名和属性值。
属性描述隐藏在对象内部的信息，由该对象的服务专门操作。
类的服务（操作）
服务也称为方法或操作，是信息系统为满足用户需求必须采取的
行动，是信息系统对事件的响应。
服务的定义取决于具体问题域和功能需求，应遵循信息隐藏原理，
执行单一的、高度内聚的功能。一个服务可以通过发送消息请求另
一个服务的支持。
类之间的联系 ?泛化 —特化
?聚合（整体 —部分）
?关联
?消息传递
泛化 — 特化联系
泛化 —特化联系反映类之间的一种继承关系
订单
邮件订单 电话订单 网上订单
聚合联系
也称整体 —部分联系。反映各组成部分和整体之间的关系。
计算机
内存 显示器 CPU 外存 键盘
1
1 1
1 1 1
1
1 1….* 1….*
关联联系
类之间的一种二元关系，表达对象之间的静态联系
教师 学生 0….* 1
（ 2）用例图
用例图描述系统的环境和系统的功能需求。
用例图中的关系
用例图中的关系有活动者与用例之间的关系和用例与用例之间的关系。
?活动者与用例之间的关系称为关联，描述活动者与用例之间的关系
?用例之间的关系：包含关系、扩展关系、泛化关系
?关联：表示参与者与其参与执行的用例之间的通信路径
?扩展：在基础用例上插入基础用例不能说明的扩展部分 <extend>
?包含：在基础用例之上插入附加行为，并具有明显描述 <include>
?泛化：用例之间一般与特殊的关系，其中特殊用例 (子用例）继承了一
般用例（父用例）的特性，并增加了新的特性。
包含的使用：如果两个以上的用例有大量一致的功能，可将该功能分解到另
一个用例中；一个用例功能太多时，可以用包含关系建立两个小用例。
包含与扩展的区别,
?在包含关系中一个用例总是在使用另一个用例的功能
?在扩展关系中，是根据某些条件有选择地使用另外一个用例功能。
下订单 查目录
查询产品 查供应商
安排付款
付现今 付支票
<extend>
<include>
<include> <include>
子用例
父用例
扩展用例
客户
（ 3）顺序图
显示场景或用例表中所发生的交互，它侧重于对消息时序的描述。
（ 4）协作图
协作图强调对象之间的关系组织，而不是对象之间信息传递的
时间性。协作图将消息名称前加上顺序号。
（ 5）状态图
状态图用于描述具有复杂动态行为的对象，表示一个对象状态
的演变。状态图的关键成分是状态和状态的转换
闲置
冷却
激活
预热
过冷
温度到达
过热
温度到达
过冷
加热
准备 /开关合上
过热 恒温器对象的状态图
（ 6）活动图
表现于一组事件相连的多个对象的状态变化，强调在计算过程
中顺序和并发的步骤
带泳道的活动图
请求服务
取订单
填写订单 付款
分发订单
收集订单
客户 销售 库房
二、事件和事件的描述
1、事件和系统需求
事件是指发生在确定的时间和地点，可以描述、并应该被系统记
录下来的事实。
系统分析首先应当考察对系统产生影响的外部事件。
2、事件的类型
（ 1）外部事件
由外部实体或动作参与者所引发的事件。外部事件将影响系统，
触发系统内部进行一系列工作。识别外部事件的关键点,
?外部实体对系统的数据输入
?由外部实体的需要而触发的系统内部事务处理
?外部实体想要获取某些信息
?外部实体的变化引发系统内部数据需要更新
（ 2）定时事件
又称临时事件。是由于系统到达某一时刻系统内部自动发生的事件。时
间事件是内部事件。
（ 3）状态事件
识别定时事件和状态事件的关键点,
?内部处理需要的临时输出结果；
?系统应当对外给出的结果；
?系统内部相关要素的状态依赖关系。
是系统内部由于某个要素状态的改变而触发其他要素状态改变的事件。
状态事件是内部事件。 。
3、识别事件
（ 1）准确区分事件、条件、响应和行为
例：用电客户到银行交纳电费的例子。
事件：用电客户交纳电费；
条件：有信用卡；卡上有足够的钱；
响应：银行从客户信用卡上划拨费用
如何区分事件与响应：判断两者能否分割开来。
（ 2）列出事件的时间顺序
通过跟踪事件处理的生命周期，列出事件的时间顺序。
（ 3）技术选择和系统控制
技术实现和系统控制也将引发一系列事件，这类事件大多在系统设计
阶段识别，但部分也需要在分析阶段识别。
4、事件列表
事件列表中要包括：事件、触发器、来源、动作、响应、目的地，六
大要素。
?触发器：事件与系统的接口。
?动作：事件消息传递给系统后，系统引发的一系列动作和行为。
?响应：系统对所发生事件的输出结果，可能是一个结果，也可能是一系
列其他事件或动作。
?目的地：系统产生结果的送达地。可能是外部实体、参与者，或内部调
用的其他系统。
事件 触发器 来源 动作 响应 目的地
客户申请办
理电子钱包
填写申请表并递交
给相关银行柜台
客户 核对客户身份证，检查客
户银行帐户和信用状态
登记客户自然情况，分配
密码，冲值，制成卡片
客户
例：“申办电子钱包”事件的事件列表
三、事物、对象及其关系属性
1、事物的类型
事物及其相关信息是系统要存储的数据。面向对象的分析中，事物是
系统交互作用的对象。运用面向对象中，类与对象的抽象机制，寻找这些
事物之间的内在关系。
通过事件列表对事件的分析，来研判相应事件影响了哪些事物。
事物
实体事物
边界事物
控制事物
实物
角色
地点位置
组织
交互行为
时间
2、对象之间的关系
对象之间发生的相互作用称为关系。对象之间的关系有一元关系、二元关
系、多元关系。
?一元关系：同一类对象之间的关系。例：人与人、部门与部门之间的关系
?二元关系：不同类对象之间的关系。例：客户与信用卡之间的关系。
?多元关系：存在于 3种或以上不同类对象之间的关系。
（ 1）对象类之间关系的图示方法
一对一的关系
客户帐号 电子钱包 1…………………1
在每个对象类端点上都有一个重数 1。
一对多的关系
在每个端点都有重数 0….n,或 *（表,1….n) 。
电子钱包 银行 1…………………*
多对多的关系
在一个端点上有一个重数 1，另一个端点有重数 0….n,或 *（表,1….n) 。
客户 银行 *…, 申办电子钱包, …*
例：一个项目有许多活动组成；一个活动有许多任务组成；一个任务消耗
若干资源，并产生若干工作成果；工作成果可以是：一个系统、一个模型、
一个文档；资源可以是：参与者、时间或设备。
用 UML的图形元素可表示为,
项目
活动
任务 工作成果 资源
文档
模型
系统 参与者
时间
设备
*由 ………,生产 消耗 ……….*
*
*
（ 2） UML描述关系的四种主要结构
依赖关系
一个对象以某种方式影响另一个对象，后者并不一定受前者影响。
聚集关系
一个对象是由其部分之和构成的关系。
关联关系
表示一般事物和特殊事物之间的关系
泛化关系
系统中对象之间发生某种联系。
3、对象的属性
属性是对类（对象）特征的描述。
系统分析关键是找出与类（对象）相关的属性。
能唯一标示一个类（对象）的属性称为关键字。
四、需求建模
1、需求的概念
面向对象的分析以用例模型描述系统的功能需求。
软件工程对需求的定义
需求包括从用户角度和从系统开发者角度描述的用户为解决某个问题
或实现某一目标，要求软件必须满足的条件或能力。
功能需求
信息系统必须包括的功能和行为。功能需求主要表现在事件列表中。
非功能需求
系统完成功能需求的能力。例如：过程方面、性能方面、外部特性方面等。
约束条件
限制系统解决方案的可选范围的需求，如硬件、软件、人员组成等。
信息系统
用户需求
约束条件 功能需求 非功能需求
常规需求 意外需求 期望需求
业务说明 分析人员经验 使用实例
由 ……,产生 由 ……,提示 由 ……,产生
2、需求描述的工具
UML需求描述 =事件表 +类图 +用例图 +交互图（顺序图、协作图） +状态图
（ 1）建立领域模型
建立领域模型是从事件表转化为类图的工作。
领域对象是系统工作环境中存在的事情或发生的事件。领域中有如下三类对象,
?现实世界的对象：表示现实世界中要通过系统处理的事物，如货物、地点等；
?业务对象：表示业务中需要进行操作的事物，如订单、合同、帐户等；
?发生和将要发生的事件：表示能够引发系统工作或对系统产生影响的事实，如
货物抵达、申请递交等。
类图、对象图的建立步骤
? 确定对象和类。包括寻找、列举和删除对象和类
?找出对象之间的关系。包括聚类、泛化、关联等
?整理对象和类之间的关系。如删除、分解关联等。
?确认对象属性。根据领域知识找出属性和属性值。
?建立数据字典。
?对类图和对象图的内容列出必要说明。
?反复修正类图和对象图。
例：从事件表到系统领域模型
客户
ID
订单
日期
货号
合同客户
合同号
付款方式
个别客户
电话
付款方式
商品条目
商品代码
目录期号
商品目录
目录期号
有效期
联系员工
员工号
1 *
1
*
*
1
*
0…1
电话订货系统事件表,
客户来电
查询客户号
查询商品目录
开订单
查询货物条目
查询客户类别
确定付款方式
……….,
（ 2）建立业务模型
业务模型除包括类图、对象图以外，还要画出用例图、活动图、顺序图
和状态图。
用例图从使用者角度描述系统。侧重从功能的角度描述业务过程的信
息，表达业务过程各个功能的组成部分，确定参与者，以及参与者使用的
业务用例。
例：电话订货系统的用例图
电话订货
查询订单
开列订单
验证客户
安排付款
审核使用
<extend>
<include>
<include>
<include>
<extend>
<extend> 客户
服务人员
例：用例图、类图、顺序图、状态图之间的关系
开列订单
验证客户
<extend>
用例图
服务人员
服务人员
订单
客户
商品条目 类图
顺序图 订单,…….,
客户,…….,
创建订单
验证客户
订单调出
订单分发 订单存档
订单入座 订单填写
订单类的状态图
例：活动图 — 描述单个业务用例的细节过程
创建订单
确认订单
提供优惠 填写订单
团体付费
信用卡付费
填写订单 个别订户 分支
同步条 团购订户
同步条
合并
（ 3）需求说明的补充
对于非功能需求，采用传统手段进行说明。内容有,
?可用性：用户可以使用系统的时间百分比。
?可靠性：系统正确运行的可靠程度。
?性能：系统功能之外增加的条件。如，容量、响应时间、带宽等。
?可支持性：为保持可维护性、可扩展性必须达到的要求。
?设计约束：对系统设计的限制。
?接口需求：系统与外部的接口，如：软件接口、硬件接口、通信接口等。
?其他需求：在线帮助、产品许可等。
? 参与者 （ Actor)是 UML的专门术语。特指 系统外部 介入系统的实体。可
以是人员、设备、其他系统等。
?参与者的输入，或请求系统输出是触发系统用例执行的根源。
?区分实体、参与者、角色。同一实体在不同用例面前可能扮演不同角色。
?业务用例中的角色经系统分析员提炼成为参与者。
3、功能分析
（ 1）识别参与者
功能分析的工作：识别参与者、定义系统边界、识别系统用例、识别用
例间的关系、建立用例模型，划分用例优先等级等。
提炼角色为参与者的步骤,
? 考虑所有可能与系统运行有关的人员、设备和其他系统；
?确定系统在输入、输出方面的参与者；
?确定系统操作和维护方面的参与者；
?将参与者 ——用户 ——角色联系起来；
?进行合理组织和合并，减少功能重叠，形成参与者和角色类别；
?对参与者命名
电话订货
查询订单
开列订单
验证客户
安排付款
审核使用
<extend>
<include>
<include>
<include>
<extend>
<extend> 客户
服务人员
（ 2）定义系统边界
大边框界定了系统边界
（ 3）识别系统用例
识别系统用例的两种方式：基于参与者的方式；基于事件的方式。
整理用例集
识别外部事件
发现服务对象
识别执行过程
创建订单
分析事件功能
识别参与者
通过系统必须
响应的外部事
件，找出系统
的边界和内外
联系
通过系统功能分
析，找出系统事
件与参与者的关
系，进而建立用
例
通过识别参与
者，确认最终
使用者和服务
对象
通过分析每个
参与者所发起
参加的执行过
程，确定转化
为用例的可能性
通过对参与者,
事件、过程、功
能及相互关系的
分析，建立用例
和用例集合
识别用例完成后，还要考虑以下问题,
? 每个参与者的特定任务是否完成？
?是否每个参与者都要从系统中创建、存储、改变、移动或读取信息？
?是否有特定任务或数据尚找不到参与者？
?是否需要将系统维护、支持的用例画上去？
?是否有其他重要的功能需求没有列上去？
（ 4）识别用例间的关系
? 用例之间也有关系之间所具有的关系，即：关联、聚集、泛化等。
?用例之间还有两种特殊的关系：包含、扩展。
包含关系,表示所触发用例的完成需要调用其他子用例。
扩展关系,表示可以选择的行为集合、特定条件下才发生的行为集合、或者不同流程等。
包含与扩展关系的区别,
? 描述的箭头方向,包含关系有主用例指向被包含用例；扩展关系由扩展
用例指向主用例。
?逻辑关系,包含关系表示只要有就必须完成的功能；扩展关系表示一种可
能的需要。
验证身份
核对 IC卡 核对密码
电话订货
查询订单
开列订单
验证客户
安排付款
审核使用
<extend>
<include>
<include>
<include>
<extend>
<extend> 客户
服务人员
（ 5）建立用例模型
使用用例图描述系统的一组用例、用例参与者、用例之间的关系和用
例与参与者之间的关系。
（ 6）划分用例的优先级
自上而下找出对系统最为重要的用例。并按以下原则对用例排序,
?以用例对系统商务模式的影响排序；
?以用例对商务模式的核心流程的影响排序；
?在每个级别内按功能实现的重要性排序；
?找出通用或实现简单的用例。
五、需求建模实例
1、学校教学管理系统需求建模
? 系统用户是：教学管理人员、教师、学生；
?系统功能：提供学生选修课程和学生成绩管理方面的服务。
（ 1）系统需求
? 学生选课管理：包括，新学期选修课程表生成、学生选课注册、
选修课查询、信息统计与报表生成、相关信息传递到财务管理系统。
?学生成绩管理：学生考试成绩录入、成绩查询、成绩汇总与报表
生成。
（ 2）确定系统范围和系统边界
? 教学管理系统的业务范围：只进行学生选课和考试成绩管理，不
包括其他教学管理；
?系统边界：本教学管理系统与学校教务管理系统和财务管理系统
有系统边界。教务管理系统只接受本系统汇总信息，不反馈；财务
系统接受相关信息，并反馈学生交费信息。
（ 3）参与者
? 学生
?教师
?教学管理人员
?教务管理系统
?财务管理系统
（ 4）确定用例
?,选修课管理”中的用例有：选修课程管理、选修课查询、选修课注册、
教师简历查询、选修课统计汇总。
?“学生成绩管理”中的用例有：学生成绩管理、学生成绩查询、学生
成绩统计汇总,
（ 5）分层用例绘制
选修课管理
学生成绩管理
教学管理员
教师
教务系统
学生
财务系统
教学管理系统
教务系统
学生成绩管理子系统
课程成绩查询
学生成绩管理
教学管理员
教师
学生
财务系统
学生成绩汇总
学生成绩查询
选修课注册
选修课管理 教学管理员 教师
学生 财务系统
选修课信息汇总
选修课查询
选修课管理子系统
教师简历查询
（ 6）用例汇总
选修课管理
学生成绩管理 教学管理员
教师
教务系统
学生
财务系统
课程成绩查询
学生成绩管理
学生成绩汇总
学生成绩查询
选修课注册
选修课管理
选修课信息汇总
选修课查询
教师简历查询
（ 7）用例之间的关系
选修课查询 教师
学生
身份验证 课程成绩查询
选修课注册
学生成绩查询
<include>
<include>
<include>
<include>
（ 8）建立对象类
主要的类如下,
?学生
?教师
?教学管理人员
?选修课表
?选课单
?课程
?成绩
（ 9）定义类之间的关系，建立类图
学生
1 教师
教学管理人员 选修课表
选课单
课程
成绩
*
1
1
*
*
1 *
* *
*
*
2、定单处理系统的用例模型
（ 1）系统包含的参与者
? 电话代理
?信用授权机构
?产品仓库系统
?货运系统
（ 2）系统与各类参与者的交互
系统与电话代理的交互
? 输入定单
?取消定单
?取消定单明细
?查询
系统与信用授权机构的交互
? 确认购买 (系统告诉信用机构通过信用卡和借记卡购买 )
?贷款帐户 (系统告诉信用机构记录帐户 )
系统与产品仓库的交互
? 请求发货
?取消发货请求
?退货处理
?查询库存
?接受订货
系统与货运系统的交互
? 运送货物
?退回定单物品
输入定单
查询
取消定单明细
取消定单 电话代理
贷款帐户
确认购买
信用授权机
构
退货处理
接受定单
取消发货请求
查询库存
请求发货
产品仓库系
统
退回定单物品
运送货物
货运系统
3、对用例模型的补充说明
? 用例功能的具体执行步骤对应着一个事件流,
?在用例模型中，有时使用场景 (scenario)来描述执行用例的一系列动作。
事件流,客户打电话给公司与定单办事员交谈。定单办事员验
证客户信息。如果是新客户，则创建一条客户记录。然后客户
请求订购产品，这会触发创建新定单。办事员确认该产品仍有
存货后，将产品订购数量添加到定单中。然后客户请求下一种
商品，办事员验证后将其加入到新定单中。最后，客户提供支
付信息，办事员对其验证。于是定单标为就绪状态，这个场景
就完成了。
异常情况,如果产品没有库存，则客户可以选择不订购该产品
或以延期定货的形式加入到定单。如果客户信誉不好，只有收
到支票后且客户还清债务时，定单才会送到客户手中。
例：客户创建电话定单的场景描述
