第三章 信息系统分析
主要内容：系统分析的任务是 针对每一个子系
统进行详细的分析，然后制定出每个子系统的
逻辑结构。本章结合教学管理系统介绍信息系
统分析方法。
3.1 信息系统分析概述
? 3.1.1 信息系统分析的任务
– 详细了解每一个业务过程和业务活动的工作
流程及信息处理流程,理解 用户对信息系统
的需求，然后运用各类信息系统开发理论、
开发方法和开发技术确定出系统应具有的逻
辑功能，再用适当的方法 表达 出来，形成这
个系统的逻辑方案，这个方案不但要能够充
分反映用户的信息需求并和用户取得一致的
意见，而且要能够使系统设计员和程序员由
此设计、开发出一个计算机化的信息系统。
3.1.2 信息系统分析步骤
? 第一步、对现行系统进行详细的业务调查分析了解
各项需求
? 第二步、进行数据分析，建立数据库逻辑模型
? 第三步、依据数据库模型确定出新系统的逻辑功能
结构
? 第四步、整理各项文档资料，并提出系统分析总结
报告
需求调查主要内容
? 1、系统的功能要求。这是未来系统必须完成
的各项功能。
? 2、系统性能要求。如联机系统的响应时间、
系统需要的存储容量以及后援存储、重新启动
和安全性等方面的考虑 等。
? 3、运行要求。
? 4、将来可能提出的要求
系统分析工具
? 业务流程图
? 数据流程图
? 数据字典
? 数据库设计工具 —— 规范化设计
? 功能描述工具 —— 结构式语言、判断树、判断表
? 基于 UML的分析和设计工具 Rational Rose
3.1.3 信息系统分析的特点
? 1、用画图的方法，直观且容易理解
? 2,,自顶向下, 的工作原则
? 3、强调逻辑结构而不是物理实现
? 4、避免了重复工作
3.2 系统分析基本方法
?3.2.1 业务流程调查
基本图例
业务处理单位或部门
各类单证、报表等 数据存储或存档
业务功能描述
数据流动及方向
业务流程概述 （概述内容见第二章）
? 新生入学后填写的 学生情况登记表 报 各系、院后，再
上报 教务处教务科，教务科将这些报表 汇总 后与学校
招生办公室进行核对，准确无误后 存档 以备使用。每
年各个专业在制定完 教学计划 后，由教学秘书 交 系教
学办公室进行 审核,然后 上报 教务科，教务处和教务
科出面组织全校进行 讨论,协调各专业的教学执行计
划，最后形成年度 教学执行计划 下发 各系组织落实。
各系将落实后的 教师任务分配表 汇总再报 教务科。各
系教学办公室根据教学执行计划、教师任务分配表和
教室情况 排出本系课程表, 再报 教务科，由教务科进
行统一协调，最后 制定 出 全校课程表 下发 各院、系。
学校在部分专业中实施了学分制管理，在每学期开学
以前还要进行 学生选课 工作。期末考试结束后，各系
将 学生成绩 归档并进行学籍处理,然后将成绩及学籍
处理结果 报教务科审批 执行。另外教务科还要根据 教
师任课情况、学生情况 制定 各种 报表 上报 省教委、学
校及各有关单位。
对教学管理职能域进行调查形成的二级业务流程图
学籍处理
1
学生登记表
学生
招生
办公
室
各
院系
教务
处
学生档案
专业
教学
秘书
教学计划 制订
教学计划
2
教学计划
统计报表
处理
8
统计报表
校
领导
上级
主管
部门
各
院系
教师基本
信息管理
3
人事
处
教师信息表
教务
处
教室设施
管理
4
教师信息
教室信息
排课
5
教师任课
课表
学生
教师
各
院系
学生选课
6
成绩管理
7
学生成绩
教务
处
教务
处
教师任课
“学籍处理”业务的详细调查
? 对, 学籍处理, 业务的详细调查，可以了解到其业务
处理有：转专业、休复学、退学。学生的转专业、休
复学、退学（指自动退学）都要由本人提出 申请,经
系教学办公室 审查初步同意 后,报 教务处教务科进行
复核,最后 报 请校领导 批准 由教务处教务科负责 执行,
相应的 执行结果 要 记 入 学生情况档案 。每学期期末教
师将 学生成绩单 送 交 各系院后，由教学办公室负责将
学生成绩存档,在新学期的开学初期，各系、院要根
据学生的 学习成绩 进行 学籍处理,并报教务科 审批实
施 。另外每年各教学办公室还要对应届毕业生进行 毕
业资格审查,确定其毕业资格有三种类型：拥有毕业
证书和学位证书、仅拥有毕业证书、仅拥有结业证书，
然后报教务科复审 上报,再将证书下发学生，相应的
结果也要 载入 学生情况档案 。
对
“
学
籍
处
理
”
业
务
过
程
进
行
详
细
调
查
形
成
的
三
级
业
务
流
程
图
初步审查
学籍变动
申请
1.４
学生
学籍变动申请
院系
学生档案
初审后的学籍
变动申请
审查学籍
变动申请
1.５
教务
处
审查后的学籍
变动申请 审批
1.６
校长
审批后的学籍
变动申请
执行学籍
变更
1.７
学生成绩档案
初审
毕业资格
1.８
学生毕业资格
清单
审核及
报批
毕业资格
1.９
教务
处
院系
基于成绩
的
学籍处理
1,１０
审核后的学生
毕业资格清单
省教
委
学生学籍处理
清单 审核学籍
1, １１
学籍变动通知
学生
学籍变动通知
学生档案
毕业证书
学生登记表
核实学生
基本信息
1.1
核实后的学生
登记表
建立各院
系学生档
案
1.２
建立学生
档案
1.３
招生
办公
室
院系
院系学生档案 学生档案
教务
处
“制订教学计划”业务的详细调查
?, 制订教学计划, 业务过程的详细处理是：首先由各
专业教学委员会制订 教学计划,各专业的教学秘书将
整理后的教学计划 交 给院系教学办公室进行 汇总、审
核,然后 报 学校教务处，教务处将各专业教学执行计
划汇总后 召开 全校教学秘书及院系教务人员协调会，
最终 确定 本年度的 教学计划,并 下发 各院系。各院系
将教学计划下发给教研室主任 安排 教学任务，教研室
主任将 教学任务安排结果 汇总 成教师任课表 报 院系，
各院系再将 汇总 后的教师任课表 报 教务处。
对“制订教学计划”业务过程进行详细调查形成的三级业务流程图
教学计划
汇总
审核
教学计划
2.1
汇总后的院系
教学计划
教学计划
协调会
2.2
教研
室
主任
专业
教学
秘书
专业教学计划
院系
专业
教学
秘书
教务
处
教学计划
院系
教研
室
主任
教师任课表
汇总
教师任课
表
2.３
院系
院系教师任课表
汇总后的教师
任课表
汇总全校
教师
任课表
2.４
教师任课表
“排课”业务的详细调查
?, 排课, 业务过程的详细处理是：各院系根据
本单位的 教学计划和教师任课表 完成课表的 初
步排定 工作，其排课内容涉及到学生班级、教
师的上课时间安排，各院系将 排课结果 报教务
处后，由教务处 排定上课教室 。
对“排课”业务构成进行详细调查形成的三级业务流程图
教学计划
排定上课
时间
５,1
初步课表 排定上课
地点
５,2
课表
教务
处
院系
教学计划
院系教师任课表
教师信息
教室信息
院系
学生
教师
“统计报表处理”业务的详细调查
?, 统计报表处理, 业务过程的详细处理是：教
务处对 教师任课情况 进行 统计,并形成 开课情
况统计表 ；根据 学生档案 统计 各专业及班级学
生人数及学生变动情况，形成 班级学生人数统
计表、学生异动统计表 等等 。
对“统计报表处理”业务进行详细调查形成的三级业务流程图
教师开课
情况统计
８,1
教师开课
情况表
教务
处
学生档案
学生成绩
校领
导
上级
主管
部门
院系
院系教师任课表
按班级
统计学生
人数
８, ２
按班级
统计学生
变动情况
８, ３
教务
处
学生情况
统计表
学生异动情况
统计表
业务流程图的审查
? 首先要与用户一道共同审查这些业务流程图的整个工
作流程是否正确，是否有被遗漏的部分。
? 其次要检查业务流程图的一致性，即在高层流程图中
出现的各类报表、单证、数据存储等数据载体一定要
在低层的业务流程图中反映出来，相应地表示业务处
理单位或部门或人的业务处理的参与者、完成者也要
在低层的业务流程图中反映出来。
? 再次要检查低层的业务流程图中是否存在这样的业务
活动，它没有输入的数据载体或处理完毕不产生输出
的数据载体。如果存在则要仔细调查各项业务活动是
确实没有输入或没有输出的数据载体，还是将某些数
据载体遗忘。
? 最后要对各项业务活动和数据载体的名称进行审查，
确认名称定义的正确性和准确性，不能存在同名异义
或同义异名的现象。
3.2.2 数据分析建立数据模型
? 数据模型目前主要采用 关系模型 来描述
? 关系是一张二维表，表的每一行叫做一个 元组
（ Tupple）,是某个实体或实体之间联系中的
一个具体值，通常称为一条, 记录, 。每一列
叫做一个 属性 （ Attribute）,通常称为, 数据
元素, 或, 数据项,,每一个元组必须用 关键
字 （ Key） 来唯一识别元组。
关系的性质：
? 1,在任一列上, 数据项应该属于同一个属性；
? 2,表中的所有的行都是不相同的, 即不允许
有重复的组项出现；
? 3,行的顺序无关紧要；
? 4,在一个表中, 每一列有不同的名称, 并且
列的顺序也无关紧要 。
以, 学生情况登记表, 为例的关系规范化处理 过程
? 非规范的“学生情况登记表”
姓名
性
别
政治
面貌 出生年月 籍贯 ……
社会关系 本人简历
与本人关系 姓名 工作单位 起始至终止年月 所在单位 证明人
张力 男 团员 1970/10/09 广东 …… 父亲 张样 北京 1976/09— 1982/08 小学
张力 男 团员 1970/10/09 广东 …… 母亲 王蓝 北京 1982/09— 1988/08 中学
张力 男 团员 1970/10/09 广东 …… 1988/09— 至今 大学
? 数据的依赖关系：
学生姓名 → 性别；学生姓名 → 出生年月；学生姓名 → 籍贯；学生姓
名 → 政治面貌；
学生姓名, 与本人关系 → 姓名；学生姓名, 与本人关系 → 工作单位；
学生姓名, 起始至终止年月 → 所在单位；学生姓名, 起始至终止年
月 → 证明人
非规范化关系转换为第一规范化形式
—— （ A） 转换为（ B）、（ C） 两种方案
* 学生学号
学生姓名
出生年月
籍贯
政治面貌
性别
社会关系
* 与本人关系
姓名
工作单位
本人简历
* 起始至终止年月
所在单位
证明人
（ A ）
* 学生学号
学生姓名
出生年月
籍贯
性别
与本人关系 1
姓名 1
工作单位 1
与本人关系 2
姓名 2
工作单位 2
起始至终止年月 1
所在单位 1
证明人 1
起始至终止年月 2
所在单位 2
证明人 2
（ B ）
* 学生学号
学生姓名
出生年月
籍贯
性别
* 学生学号
* 与本人关系
姓名
工作单位
* 学生学号
* 起始至终止年月
所在单位
证明人
（学生基本信息 表）
（学生社会关系 表）
（学生本人简历 表）
（ C ）
第二规范化形式：
? 设有一关系如下：
? 属性之间的依赖关系,
学生学号 → 学生姓名
学生学号 → 性别
学生学号 → 出生年月
学生学号 → 籍贯
学生学号 → 政治面貌
学生学号、课程名称 → 成绩
学生学号 姓名 性别 出生年月 政治面貌 籍贯 课程名称 成绩
第一规范化形式转换为第二规范化形式
* 学生学号
学生姓名
性别
出生年月
籍贯
政治面貌
* 课程名称
成绩
* 学生学号
学生姓名
性别
出生年月
籍贯
政治面貌
* 课程名称
成绩
* 学生学号
第三规范化形式,
? 设有一关系如下：
? 属性之间的依赖关系,
学生学号 → 学生姓名
学生学号 → 性别
学生学号 → 出生年月
学生学号 → 籍贯
学生学号 → 政治面貌
学生学号 → 学生所在系
学生学号 → 系所在地点
学生所在系 → 系所在地点
学生学号 姓名 性别 出生年月 政治面貌 籍贯 学生所在系 系所在地点
第二规范化形式转换为第三规范化形式
* 学生学号
学生姓名
性别
出生年月
籍贯
政治面貌
学生所在系
系所在地点
* 学生学号
学生姓名
性别
出生年月
籍贯
政治面貌
学生所在系
* 学生所在系
系所在地点
教学管理系统总体方案中的主题数据库方案,
主题数据库标识 主题数据库名称
DB_ClassRoom 教室数据库
DB_Teacher 教师数据库
DB_Student 学生学籍管理数据库
DB_Grad 学生成绩数据库
DB_Stat 统计数据库
DB_Course 课程管理数据库
DB_TeachTask 教师任课数据库
DB_ClassTable 课表数据库
对每个主题数据库进行规范化处理
—— 数据一览表
主题数据库标识 主题数据库名称 数据库表标识 数据库表名称
DB_ClassRoom 教室数据库 DB_ClassRoom_base 教室基本信息表
DB_Teacher 教师数据库 DB_Teacher_base 教师基本信息表
DB_Student 学生学籍管理数据库 DB_Student_base
DB_Student_encourage
DB_Student_punish
DB_Student_update
DB_Student_after
学生基本信息表
学生奖励信息表
学生处分信息表
学生学籍变动信息表
学生课外活动信息表
DB_Grad 学生成绩数据库 DB_Grade_base
DB_Grade_makeup
学生成绩表
学生补考或重修成绩表
DB_Stat 统计数据库 DB_Stat_task
DB_Stat_class
DB_Stat_update
教师开课统计表
按班级统计信息表
按班级统计异动信息表
DB_Course 课程管理数据库 DB_Course_base 课程信息表
DB_TeachTask 教师任课数据库 DB_TeachTask_base 教师任课信息表
DB_ClassTable 课表数据库 DB_ClassTable_base 课表
为每一个关系表定义数据结构
主题数据库标识 主题数据库名称 数据库表标识 数据库表名称
DB_Studen 学生学籍管理数据库 DB_Student_base 学生基本信息表
数据元素标识 含义 类型 长度 小数位 是否关键字 是否为空
StudNo 学生学号 char 10 Y NOT NULL
StudName 学生姓名 varchar 18 NOT NULL
OldName 曾用名 varchar 18
Sex 性别 char 2 NOT NULL
Birthday 出生日期 Date NOT NULL
ID_Card 身份证号 varchar 18 NOT NULL
…… …… …… …… …… …… ……
值得注意的是，主题数据库的标识、表标识以及数据元素的标识一定要用能够明确表示其含义的字符来命名，
其命名也要遵循一定的规范来进行，否则一个系统中常常包含几十个表以及上千甚至更多的数据元素，如果命
名不当必将引起理解和协调等各方面的混乱。
3.2.3 功能分析建立新系统逻辑结构
? 新系统逻辑结构的描述工具是数据流程图
图例：
外部项：指不受系统控制，在系统以外的事物或人，它表达了该
系统数据处理的外部来源和去处。
数据流：数据流表明了数据的流动方向及其名称，它是数据载体
的表现形式之一。
数据存储：用来指明数据保存的地方。
处理功能：表达了对数据处理的逻辑功能
外部项
名称
标识
功能描述
外部项
数据流
数据存储
处理功能
数据存储名称
数据流名称
标识
功能完成者
? 功能分析是在业务流程调查和数据分析基础上
进行的，首先从底层的业务流程开始分析，将
能够由计算机进行处理的业务抽取出来，然后
再根据数据模型和抽取后的处理功能构造新系
统的逻辑结构。
“学籍处理”逻辑结构
学生档案
管理
1.1
学生基本信息表
( 学生学籍管理数据库)
学生
学生学籍
变动处理
1.2
学生学籍变动信息表
( 学生学籍管理数据库)
学生奖励
信息管理
1.3
学生奖励信息表
( 学生学籍管理数据库)
学籍变动申请
学生处分
信息管理
1.4
学生处分信息表
( 学生学籍管理数据库)
学生课外
活动
信息管理
1.5
学生课外活动信息表
( 学生学籍管理数据库)
学生工
作部
学生奖励通知
学生处分通知
学生课外活动信息
教务处
教务处
教务处
教务处
教务处
审核学籍
1.6
教务处
学生成绩表
( 学生成绩数据库)
学生补考或重修成绩表
( 学生成绩数据库)
毕业资格
审查
1.7
教务处
学生基本信息表
( 学生学籍管理数据库)
学生
学籍变动通知
学生登记表
“制定教学计划”逻辑结构
教学计划
信息管理
2.1
课程信息表
( 课程管理数据库)
教学
秘书
专业教学计划
教务处
教学计划
信息打印
2.2
教务处
院系
院系
教师任课
信息管理
2.3
教务处
教师任课信息表 教师任课信息表
( 教师任课数据库)
教学计划
教师基本信息表
( 教师数据库)
“排课”逻辑结构
排课
5.1课程信息表
( 课程管理数据库)
教务处
教师
教师任课信息表
( 教师任课数据库)
教师课表
教室基本信息表
( 教室数据库)
课表
( 课表数据库)
调整课表
5.2
教务处
打印教师
课表
5.3
教务处
打印学生
课表
5.4
教务处
打印教室
课表
5.5
教务处
学生
教室管
理员
院系
教室课表学生课表
打印班级
课表
5.5
教务处
班级课表
“统计报表处理”逻辑结构
教师开课
情况统计
8.1
教务处
上级主
管部门
教师任课信息表
(教 师任课数据库)
学生基本信息表
(学 生学籍管理数据库)
教师开课统计表
(统 计数据库)
校领导
院系
学生成绩表
(学 生成绩数据库)
按班级
统计
学生人数
8.2
教务处
按班级统计信息表
(统 计数据库)
按班级
统计
学生变动
情况
8.2
教务处
按班级统计异动信息表
(统 计数据库)
教师开课统计表
学生情况统计表
学生异动情况统计表
教学管理系统总体逻辑结构
学籍处理
1
教务处
上级主
管部门
教师任课数据库
学生学籍管理数据库
学生工
作部
院系
学生奖励通知
学生处分通知
学生课外活动信息
专业教
学秘书
制定教学
计划
2
教务处
课程管理数据库
教学计划
院系
教师任课信息表
教师基本
信息管理
3
教务处
教师数据库
人事处
教师信息表
教室设施
管理
4
教务处
教室数据库
排课
5
教务处
课表数据库
学生
学生登记表
学生
学籍变动通知
院系
教学计划
教师
教师
课表
学生
教室管
理员
院系
教室
课表
学生
课表
班级
课表
成绩管理
7
教务处
学生成绩数据库
网上
学生选课
6
学生
统计报表
处理
8
教务处
教师任课数据库
校领导
统计数据库
教师开课统计表
学生情况统计表
学生异动情况统计表
网上信息
查询
9
院系
逻辑功能的审查
? 第一、数据流程图本身的正确性检查。
? 第二、逻辑功能正确性检查。
? 第三、检查新系统逻辑功能是否符合总体规划
中的总体方案要求。
新系统的逻辑结构的特征：
? 1、系统内各功能部分之间的数据存储及交换
关系都是通过主题数据库来实现的，充分体现
了第一章中所提到的信息系统开发的基本原理
和前提。
? 2、数据库的建立首先经过了总体规划，在充
分考虑到全局利益的前提下形成的，因此解决
了由分散开发所带来的一系列问题。
? 3、数据流出现在相关的外部项和处理功能之
间，表明了该系统与外界的接口 。
3.2.4 处理功能的表达
? 用自然语言表达处理功能通常存在以下几类问题：
– 界限不明确
– 逻辑条件的次序不明确
– 意义模糊的形容词或副词
3.4.2.1 结构式语言
? 结构式语言使用的词汇主要有三类：
– 1,祈使句中的动词；
– 2,在数据字典中定义的名词；
– 3,某些逻辑表达式中的保留字 。
? 结构式语言使用的语句只允许有四类：
– 1,简单的祈使句
– 2,判断句
– 3,循环语句
– 4,上述三种的复合语句
祈使句（动词 +名词）
? 获得当月水表数
? 获得上月底水表数
? 当月水表数减去上月底的水表数, 得到本月实际用水吨数
? 1.20元乘以实际用水吨数得到水费
? 将水费加到应交房租水电费中
? 获得当月电表数
? 获得上月底电表数
? 当月电表数减去上月底的电表数, 得到本月实际用电度数
? 0.80元乘以实际用电度数得到电费
? 将电费加到应交房租水电费中
? 获得房租费
? 将房租费加到应交房租水电费中, 得到住户的应交房租水电费
判断句：
? 形式 1（一般形式）：
– 如果 条件 1（ 成立 ）
– 则 动作 A
– 否则 （ 条件 1不成立 ）
– 就 动作 B
? 形式 2（嵌套形式）：
– 如果 条件 1（ 成立 ）
– 则 如果 条件 2（ 成立 ）
– 则 动作 A
– 否则 （ 条件 2不成立 ）
– 就 动作 B
– 否则 （ 条件 1不成立 ）
– 就 动作 C
? 形式 3：
– 如果 条件 1 则 动作 A
– 如果 条件 2 则 动作 B
– …………
循环句：
? 一般形式：
对每一满足条件的记录, 循环执行
动作 A
3.4.2.2 判断树
? 判断树是用一种树型图形方式来表示多个条件、多个
取值所应采取的动作。看一张判断树图形的时候，要
从左边（树根）开始，沿着各个分支向右看，根据每
一个条件的取值状态可以找出应该采取的动作，所有
的动作都列在这张图的最右侧
? 方法：
– 首先确定有哪些条件
– 第二确定每一个条件有几种可能的状态，即有几种
取值
– 第三要确定有哪些动作
– 最后确定每一项动作要依赖哪些条件及取值。
举例：
? 学校的奖学金有两种, 且记为奖学金 A和奖学金 B。
? 对于奖学金 A,凡各科成绩平均在 88分以上, 单科成
绩不低于 75分, 英语平均在 80分以上者可申请一等奖
学金 （ 金额 400元 ） ；凡各科成绩平均在 85分以上, 单
科成绩不低于 70分, 英语平均在 80分以上者可申请二
等奖学金 （ 金额 300元 ） 。
? 对于奖学金 B,凡各科成绩平均在 92分以上, 单科成
绩不低于 85分, 英语平均在 90分以上者可申请特等奖
学金 （ 金额 1500元 ） ；凡各科成绩平均在 90分以上,
单科成绩不低于 80分, 英语平均在 85分以上者可申请
一等奖学金 （ 金额 800元 ） ；凡各科成绩平均在 88分以
上, 单科成绩不低于 75分, 英语平均在 80分以上者可
申请二等奖学金 （ 金额 400元 ） ；凡各科成绩平均在 85
分以上, 单科成绩不低于 70分, 英语平均在 80分以上
者可申请三等奖学金 （ 金额 300元 ）
? 两个条件：奖学金种类，成绩
? 第一个条件有两个状态：奖学金 A和奖学金 B。
? 第二个条件有六个状态：依据平均成绩、单科
最低成绩和英语平均成绩来最终确定。
? 有六个处理动作，即最后发放的奖学金金额。
判断树：
? 其中：
– 计算出学生的平均成绩，将值放入 G中；
– 计算出学生各科的最低成绩放入 D中；
– 计算出英语的平均成绩放入 E中 。
奖学金
政策
奖学金
种类
成绩
奖学金 A
奖学金 B
G 大于等于 8 8 且
D 大于等于 75 且 E 大于等于 8 0
G 大于等于 8 5 且
D 大于等于 70 且 E 大于等于 8 0
G 大于等于 9 2 且
D 大于等于 85 且 E 大于等于 9 0
G 大于等于 9 0 且
D 大于等于 80 且 E 大于等于 8 5
G 大于等于 8 8 且
D 大于等于 75 且 E 大于等于 8 0
G 大于等于 8 5 且
D 大于等于 70 且 E 大于等于 8 0
奖学金
金额
4 0 0 元
3 0 0 元
1 5 0 0 元
8 0 0 元
4 0 0 元
3 0 0 元
3.4.2.3 判断表
? 方法
– 首先确定有哪些条件
– 第二确定每一个条件有几种可能的状态，即
有几种取值
– 第三要确定有哪些动作
– 第四给出所有条件的组合
– 最后确定每一项动作要依赖哪些条件及取值。
举例：
? 某工厂人事部门对一部分职工重新分配工作, 其
分配原则如下：
?, 如果年龄不满 18岁, 文化程度是小学, 则脱产
学习, 文化程度是中学, 则当电工 。 如果年龄满
18岁但不满 40岁, 如果文化程度是小学或中学, 若
是男性, 则当钳工, 若是女性, 则当车工, 文化
程度是大学, 则当技术员 。 如果年满 40岁及以上
者, 文化程度是小学或中学, 则当材料员, 文化
程度是大学, 则当技术员 。,
? 有三个条件：性别、年龄、文化程度。
? 性别有 2个取值
? 年龄有 3个取值
? 文化程度有 3个取值
? 所有条件的组合有,2× 3× 3＝ 18个。
条件名称 取值 含义
性别 0 男
1 女
年龄 0 未满 18岁
1 满 18岁但不满 40岁
2 满 40岁及以上
文化程度 0 小学
1 中学
2 大学
判断表（初始）：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
性别 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1
年龄 0 0 0 1 1 1 2 2 2 0 0 0 1 1 1 2 2 2
文化程度 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2
脱产学习 ※ ※
当电工 ※ ※
当钳工 ※ ※
当车工 ※ ※
当技术员 ☆ ※ ※ ☆ ※ ※
当材料员 ※ ※ ※ ※
☆为后补动作
判断表（整理后）：
1 2 3 4 5 6 7 8 9
性别 0 0 1 1
年龄 0 0 1 1 2 2 1 1
文化程度 0 1 2 0 1 0 1 0 1
脱产学习 ※
当电工 ※
当钳工 ※ ※
当车工 ※ ※
当技术员 ※
当材料员 ※ ※
例：, 教师基本信息管理, 处理功能的描述
处理功能标识 3 处理功能名称 教师基本信息管理
相关数据库 教师数据库 相关数据库表 教师基本信息表
功能需求：
1,查询需求,（ 按学院, 专业查询教师基本信息 ）
输入查询条件
获得满足条件的教师基本信息
显示查询结果
2,输入需求,（ 有新教师报到后向教师基本信息表中输入教师基本信息 ）
获得新教师的基本信息
验证教师基本信息的正确性
如果基本信息无误
则 向教师基本信息表中插入一条记录
否则 提示：, 教师基本信息中有错误信息,
3,修改需求,（ 发现教师基本信息输入有错误或教师信息变更则允许修改 ）
输入要修改的教师工作证号
按工作证号查询教师基本信息
显示查询结果
在查询结果中修改基本信息
验证基本信息的正确性
如果基本信息无误
则 修改教师信息
否则 提示：, 教师基本信息修改有误,
4,删除需求,（ 当某位教师调离学校则删除该教师的基本信息 ）
获得要删除的教师工作证号
按工作证号查询教师基本信息
显示查询结果
删除该条记录
说明,1,如果教师在删除年度担任教学任务则不允许删除
2,教师的出生日期和身份证号中的出生日期必须相符
3,教师的职称必须是教授, 副教授, 讲师, 助教, 实习教师, 研究员, 副研究员, 助理研究员
3.3 基于 UML的系统分析方法
? UML（ 统一建模语言,Unified Modeling Language）
是目前被广泛使用的面向对象系统的建模方法，支持
该方法的典型工具是 Rational Rose（ Rational Rose的
使用方法简介见附录）。采用 UML进行系统分析形成
的分析模型由 功能模型、对象模型和动态模型 组成。
首先进行需求调查建立 功能模型，用用例图来描述 ；
然后是细化功能模型衍生出对象模型和动态模型,对
象模型用类图来描述,它描述了实现用例所需要的数
据和操作（或称方法）,动态模型用状态图和顺序图
来描述,它描述了功能实现过程的各种动态。
3.3.1 业务流程调查建立功能模型
? 用例图（ Use Case Diagram） 符号,
? 角色 （ Actor）, 角色是与系统交互的人或事物, 角色可以是用
户, 其它系统或时间 。 当时间作为角色时, 一般是指一定时间触
发系统中的某个事件 。
? 用例 （ Use Case）, 用例是系统的功能模块, 它描述人们如何使
用系统 。
? 关系分为通信关系, 使用关系和扩展关系 。
? 通信关系 （ Communicates Relationship）, 描述角色与用例之间
的关系, 某一个角色启动一个用例或一个用例启动一个角色 。
用例角色 通信关系 使用关系或扩展关系
?, 学籍管理员, 角色启动与, 学籍处理, 用例的通信
? 使用关系（ Uses Relationship）,表示一个用例可以利用另一个用例
提供的功能。
? 扩展关系（ Extends Relationship）,表示允许一个用例扩展另一个
用例提供的功能。
学籍
处理
学籍管理员
学籍
处理
学籍管理员
统计
处理
统计员
身份
验证
< <
e x
te n
d s
> >
< <
e x
te
n d
s >
>
学籍
处理
学籍管理员
统计
处理
统计员
身份
验证
< <
e x
te n
d s
> >
< <
e x
te
n d
s >
>
使用用例图来描述教学管理系统总体业务流程
数据管理员
教室设施管理
教师基本信息管理
教师
排课
学生选课
学生
成绩管理员
学籍管理员
专业教学秘
书
教务秘书
统计报表处理
学籍处理
成绩管理
统计员
制订教学计划
,学籍处理, 用例的扩展
核实学生基本信息
校长
院系学籍管
理员
建立院系学生档案
初步审核学籍变动申请
审查学籍变动申请
审批
初步审查毕业资格
基于成绩的学籍处理
审核学籍
执行学籍变更
学生
审核及报批毕业资格
学籍管理员
统计报表处
理
建立学生档案
“制订教学计划”用例的扩展
排课
院系教务秘
书
汇总审核教学计划 教学计划协调
汇总教师任课信息
下达教学计划
教务秘书
统计报表处
理
汇总全校教师任课信息
,排课, 用例的扩展
院系教务秘
书
排定上课时间
下达课表
教务秘书
教室设施管
理
排定上课地点
制订教学计
划
,统计报表处理, 用例的扩展
制订教学计
划
教师开课情况统计
按班级统计学生人数
统计员
学籍处理
按班级统计学生变动情况
成绩管理
生成教师开课情况表
生成学生情况统计表
生成学生异动情况统计表
3.3.2 分析数据建立对象模型
? 对象模型中类之间可以有四种关系：
– 关联,（ Associations） 是类之间的连接
– 依赖性：是类之间的连接, 但依赖性的连接总是单向的, 它显示
一个类依赖另一个类的定义
客户 供应商
– 累积：累积关系是强关联，它反映的是整体和个体之间的关系
– 一般化,显示类之间的继承关系。
人
学生信息 教师信息
学生学籍变动信息
学生信息
学生基本信息
学生奖励信息
学生处分信息
学生课外活动信息
教学管理系统对象模型
3.3.3分析活动建立动态模型
? 业务流程调查所建立的功能模型主要是强调真
实而接近现实管理业务，但功能模型中存在着
需要调整的处理方式和不能够由系统来实现的
用例，为此需要根据前面的对象模型和优化后
处理方式调整功能模型，使之成为未来信息系
统的逻辑结构。
,学籍处理, 优化后的功能模型
学生课外活动信息管理
学生处分信息管理
学生奖励信息管理
学生
学籍管理员
建立学生档案
统计报表处
理
学籍变动处理
院系学籍管理
员
审核学籍
成绩管理
毕业资格审查
,制定教学计划, 优化后的功能模型
打印教学计划教学计划管理
教务秘书
教师任课信息管理
统计报表处理
,排课, 优化后的功能模型
自动排课
制订教学计
划
教室设施管
理
教务秘书
调整课表
学生
打印教师课表
教师
打印教室课表
教室管理员
打印学生课表
院系学籍管理
员
优化后的教学管理系统总体功能模型
统计报表处理
数据管理员 教室设施管理
教师基本信息管理
专业教学秘
书
制订教学计划
学生选课
统计员
教师
教务秘书
学生
成绩管理员
学籍管理员
学籍处理
排课
成绩管理
网上信息查询
院系学籍管
理员
用结构式语言、判断树、判断表 在,用例说明窗口,描述 每一
个叶子层用例
用状态图描述 每一个叶子层用例
提示：出现
修改错误
获得查
询条件
获得添
加信息
获得要修改或删
除的教师信息
教师基本信
息管理页面
清空查
询条件
提示：出现
删除错误
提示：出现
添加错误
添加教师基
本信息页面
退出
显示查
询结果
修改存
盘
修改状
态
执行删
除
执行添
加
执行修
改
请求管理教师基本信息
请求清空查询条件
请求查询
请求退出
请求添加
返回
请求存盘
出错
正确
选择要修改或删除的教师信息
出错
请求删除
正确
请求修改
正确
出错
请求修改存盘
返回
返回
用
顺
序
图
描
述
每
一
个
叶
子
层
用
例
, 数 据管理
员
教师基本信
息管理页面
教师信息编
辑页面
教师实体
1,请 求清空
清空查询
条件
1.1,清空 查询条件
添加操作
2,请 求添加
2.1,打开 教师信息编辑页面
3,请 求存盘
3.1,验证 页面添加信息
3.2,执行 添加操作
查询操作
4,请 求查询
4.1,获得 查询条件
4.2,执行 查询操作
5,请 求修改
5.1,获得 修改信息
5.1.1,验证 页面修改信息
5.1.2,执行 修改操作
修改操作
6,请 求删除
删除操作
6.1,获得 删除信息
6.2,执行 删除操作
返回操作
7,请 求返回
7.1,执行 关闭页面返回操作
学籍
处理
学籍管理员
统计
处理
统计员
身份
验证
< <
e x
te
n d
s >
>
< <
e x
te
n d
s >
>
主要内容：系统分析的任务是 针对每一个子系
统进行详细的分析，然后制定出每个子系统的
逻辑结构。本章结合教学管理系统介绍信息系
统分析方法。
3.1 信息系统分析概述
? 3.1.1 信息系统分析的任务
– 详细了解每一个业务过程和业务活动的工作
流程及信息处理流程,理解 用户对信息系统
的需求，然后运用各类信息系统开发理论、
开发方法和开发技术确定出系统应具有的逻
辑功能，再用适当的方法 表达 出来，形成这
个系统的逻辑方案，这个方案不但要能够充
分反映用户的信息需求并和用户取得一致的
意见，而且要能够使系统设计员和程序员由
此设计、开发出一个计算机化的信息系统。
3.1.2 信息系统分析步骤
? 第一步、对现行系统进行详细的业务调查分析了解
各项需求
? 第二步、进行数据分析，建立数据库逻辑模型
? 第三步、依据数据库模型确定出新系统的逻辑功能
结构
? 第四步、整理各项文档资料，并提出系统分析总结
报告
需求调查主要内容
? 1、系统的功能要求。这是未来系统必须完成
的各项功能。
? 2、系统性能要求。如联机系统的响应时间、
系统需要的存储容量以及后援存储、重新启动
和安全性等方面的考虑 等。
? 3、运行要求。
? 4、将来可能提出的要求
系统分析工具
? 业务流程图
? 数据流程图
? 数据字典
? 数据库设计工具 —— 规范化设计
? 功能描述工具 —— 结构式语言、判断树、判断表
? 基于 UML的分析和设计工具 Rational Rose
3.1.3 信息系统分析的特点
? 1、用画图的方法，直观且容易理解
? 2,,自顶向下, 的工作原则
? 3、强调逻辑结构而不是物理实现
? 4、避免了重复工作
3.2 系统分析基本方法
?3.2.1 业务流程调查
基本图例
业务处理单位或部门
各类单证、报表等 数据存储或存档
业务功能描述
数据流动及方向
业务流程概述 （概述内容见第二章）
? 新生入学后填写的 学生情况登记表 报 各系、院后，再
上报 教务处教务科，教务科将这些报表 汇总 后与学校
招生办公室进行核对，准确无误后 存档 以备使用。每
年各个专业在制定完 教学计划 后，由教学秘书 交 系教
学办公室进行 审核,然后 上报 教务科，教务处和教务
科出面组织全校进行 讨论,协调各专业的教学执行计
划，最后形成年度 教学执行计划 下发 各系组织落实。
各系将落实后的 教师任务分配表 汇总再报 教务科。各
系教学办公室根据教学执行计划、教师任务分配表和
教室情况 排出本系课程表, 再报 教务科，由教务科进
行统一协调，最后 制定 出 全校课程表 下发 各院、系。
学校在部分专业中实施了学分制管理，在每学期开学
以前还要进行 学生选课 工作。期末考试结束后，各系
将 学生成绩 归档并进行学籍处理,然后将成绩及学籍
处理结果 报教务科审批 执行。另外教务科还要根据 教
师任课情况、学生情况 制定 各种 报表 上报 省教委、学
校及各有关单位。
对教学管理职能域进行调查形成的二级业务流程图
学籍处理
1
学生登记表
学生
招生
办公
室
各
院系
教务
处
学生档案
专业
教学
秘书
教学计划 制订
教学计划
2
教学计划
统计报表
处理
8
统计报表
校
领导
上级
主管
部门
各
院系
教师基本
信息管理
3
人事
处
教师信息表
教务
处
教室设施
管理
4
教师信息
教室信息
排课
5
教师任课
课表
学生
教师
各
院系
学生选课
6
成绩管理
7
学生成绩
教务
处
教务
处
教师任课
“学籍处理”业务的详细调查
? 对, 学籍处理, 业务的详细调查，可以了解到其业务
处理有：转专业、休复学、退学。学生的转专业、休
复学、退学（指自动退学）都要由本人提出 申请,经
系教学办公室 审查初步同意 后,报 教务处教务科进行
复核,最后 报 请校领导 批准 由教务处教务科负责 执行,
相应的 执行结果 要 记 入 学生情况档案 。每学期期末教
师将 学生成绩单 送 交 各系院后，由教学办公室负责将
学生成绩存档,在新学期的开学初期，各系、院要根
据学生的 学习成绩 进行 学籍处理,并报教务科 审批实
施 。另外每年各教学办公室还要对应届毕业生进行 毕
业资格审查,确定其毕业资格有三种类型：拥有毕业
证书和学位证书、仅拥有毕业证书、仅拥有结业证书，
然后报教务科复审 上报,再将证书下发学生，相应的
结果也要 载入 学生情况档案 。
对
“
学
籍
处
理
”
业
务
过
程
进
行
详
细
调
查
形
成
的
三
级
业
务
流
程
图
初步审查
学籍变动
申请
1.４
学生
学籍变动申请
院系
学生档案
初审后的学籍
变动申请
审查学籍
变动申请
1.５
教务
处
审查后的学籍
变动申请 审批
1.６
校长
审批后的学籍
变动申请
执行学籍
变更
1.７
学生成绩档案
初审
毕业资格
1.８
学生毕业资格
清单
审核及
报批
毕业资格
1.９
教务
处
院系
基于成绩
的
学籍处理
1,１０
审核后的学生
毕业资格清单
省教
委
学生学籍处理
清单 审核学籍
1, １１
学籍变动通知
学生
学籍变动通知
学生档案
毕业证书
学生登记表
核实学生
基本信息
1.1
核实后的学生
登记表
建立各院
系学生档
案
1.２
建立学生
档案
1.３
招生
办公
室
院系
院系学生档案 学生档案
教务
处
“制订教学计划”业务的详细调查
?, 制订教学计划, 业务过程的详细处理是：首先由各
专业教学委员会制订 教学计划,各专业的教学秘书将
整理后的教学计划 交 给院系教学办公室进行 汇总、审
核,然后 报 学校教务处，教务处将各专业教学执行计
划汇总后 召开 全校教学秘书及院系教务人员协调会，
最终 确定 本年度的 教学计划,并 下发 各院系。各院系
将教学计划下发给教研室主任 安排 教学任务，教研室
主任将 教学任务安排结果 汇总 成教师任课表 报 院系，
各院系再将 汇总 后的教师任课表 报 教务处。
对“制订教学计划”业务过程进行详细调查形成的三级业务流程图
教学计划
汇总
审核
教学计划
2.1
汇总后的院系
教学计划
教学计划
协调会
2.2
教研
室
主任
专业
教学
秘书
专业教学计划
院系
专业
教学
秘书
教务
处
教学计划
院系
教研
室
主任
教师任课表
汇总
教师任课
表
2.３
院系
院系教师任课表
汇总后的教师
任课表
汇总全校
教师
任课表
2.４
教师任课表
“排课”业务的详细调查
?, 排课, 业务过程的详细处理是：各院系根据
本单位的 教学计划和教师任课表 完成课表的 初
步排定 工作，其排课内容涉及到学生班级、教
师的上课时间安排，各院系将 排课结果 报教务
处后，由教务处 排定上课教室 。
对“排课”业务构成进行详细调查形成的三级业务流程图
教学计划
排定上课
时间
５,1
初步课表 排定上课
地点
５,2
课表
教务
处
院系
教学计划
院系教师任课表
教师信息
教室信息
院系
学生
教师
“统计报表处理”业务的详细调查
?, 统计报表处理, 业务过程的详细处理是：教
务处对 教师任课情况 进行 统计,并形成 开课情
况统计表 ；根据 学生档案 统计 各专业及班级学
生人数及学生变动情况，形成 班级学生人数统
计表、学生异动统计表 等等 。
对“统计报表处理”业务进行详细调查形成的三级业务流程图
教师开课
情况统计
８,1
教师开课
情况表
教务
处
学生档案
学生成绩
校领
导
上级
主管
部门
院系
院系教师任课表
按班级
统计学生
人数
８, ２
按班级
统计学生
变动情况
８, ３
教务
处
学生情况
统计表
学生异动情况
统计表
业务流程图的审查
? 首先要与用户一道共同审查这些业务流程图的整个工
作流程是否正确，是否有被遗漏的部分。
? 其次要检查业务流程图的一致性，即在高层流程图中
出现的各类报表、单证、数据存储等数据载体一定要
在低层的业务流程图中反映出来，相应地表示业务处
理单位或部门或人的业务处理的参与者、完成者也要
在低层的业务流程图中反映出来。
? 再次要检查低层的业务流程图中是否存在这样的业务
活动，它没有输入的数据载体或处理完毕不产生输出
的数据载体。如果存在则要仔细调查各项业务活动是
确实没有输入或没有输出的数据载体，还是将某些数
据载体遗忘。
? 最后要对各项业务活动和数据载体的名称进行审查，
确认名称定义的正确性和准确性，不能存在同名异义
或同义异名的现象。
3.2.2 数据分析建立数据模型
? 数据模型目前主要采用 关系模型 来描述
? 关系是一张二维表，表的每一行叫做一个 元组
（ Tupple）,是某个实体或实体之间联系中的
一个具体值，通常称为一条, 记录, 。每一列
叫做一个 属性 （ Attribute）,通常称为, 数据
元素, 或, 数据项,,每一个元组必须用 关键
字 （ Key） 来唯一识别元组。
关系的性质：
? 1,在任一列上, 数据项应该属于同一个属性；
? 2,表中的所有的行都是不相同的, 即不允许
有重复的组项出现；
? 3,行的顺序无关紧要；
? 4,在一个表中, 每一列有不同的名称, 并且
列的顺序也无关紧要 。
以, 学生情况登记表, 为例的关系规范化处理 过程
? 非规范的“学生情况登记表”
姓名
性
别
政治
面貌 出生年月 籍贯 ……
社会关系 本人简历
与本人关系 姓名 工作单位 起始至终止年月 所在单位 证明人
张力 男 团员 1970/10/09 广东 …… 父亲 张样 北京 1976/09— 1982/08 小学
张力 男 团员 1970/10/09 广东 …… 母亲 王蓝 北京 1982/09— 1988/08 中学
张力 男 团员 1970/10/09 广东 …… 1988/09— 至今 大学
? 数据的依赖关系：
学生姓名 → 性别；学生姓名 → 出生年月；学生姓名 → 籍贯；学生姓
名 → 政治面貌；
学生姓名, 与本人关系 → 姓名；学生姓名, 与本人关系 → 工作单位；
学生姓名, 起始至终止年月 → 所在单位；学生姓名, 起始至终止年
月 → 证明人
非规范化关系转换为第一规范化形式
—— （ A） 转换为（ B）、（ C） 两种方案
* 学生学号
学生姓名
出生年月
籍贯
政治面貌
性别
社会关系
* 与本人关系
姓名
工作单位
本人简历
* 起始至终止年月
所在单位
证明人
（ A ）
* 学生学号
学生姓名
出生年月
籍贯
性别
与本人关系 1
姓名 1
工作单位 1
与本人关系 2
姓名 2
工作单位 2
起始至终止年月 1
所在单位 1
证明人 1
起始至终止年月 2
所在单位 2
证明人 2
（ B ）
* 学生学号
学生姓名
出生年月
籍贯
性别
* 学生学号
* 与本人关系
姓名
工作单位
* 学生学号
* 起始至终止年月
所在单位
证明人
（学生基本信息 表）
（学生社会关系 表）
（学生本人简历 表）
（ C ）
第二规范化形式：
? 设有一关系如下：
? 属性之间的依赖关系,
学生学号 → 学生姓名
学生学号 → 性别
学生学号 → 出生年月
学生学号 → 籍贯
学生学号 → 政治面貌
学生学号、课程名称 → 成绩
学生学号 姓名 性别 出生年月 政治面貌 籍贯 课程名称 成绩
第一规范化形式转换为第二规范化形式
* 学生学号
学生姓名
性别
出生年月
籍贯
政治面貌
* 课程名称
成绩
* 学生学号
学生姓名
性别
出生年月
籍贯
政治面貌
* 课程名称
成绩
* 学生学号
第三规范化形式,
? 设有一关系如下：
? 属性之间的依赖关系,
学生学号 → 学生姓名
学生学号 → 性别
学生学号 → 出生年月
学生学号 → 籍贯
学生学号 → 政治面貌
学生学号 → 学生所在系
学生学号 → 系所在地点
学生所在系 → 系所在地点
学生学号 姓名 性别 出生年月 政治面貌 籍贯 学生所在系 系所在地点
第二规范化形式转换为第三规范化形式
* 学生学号
学生姓名
性别
出生年月
籍贯
政治面貌
学生所在系
系所在地点
* 学生学号
学生姓名
性别
出生年月
籍贯
政治面貌
学生所在系
* 学生所在系
系所在地点
教学管理系统总体方案中的主题数据库方案,
主题数据库标识 主题数据库名称
DB_ClassRoom 教室数据库
DB_Teacher 教师数据库
DB_Student 学生学籍管理数据库
DB_Grad 学生成绩数据库
DB_Stat 统计数据库
DB_Course 课程管理数据库
DB_TeachTask 教师任课数据库
DB_ClassTable 课表数据库
对每个主题数据库进行规范化处理
—— 数据一览表
主题数据库标识 主题数据库名称 数据库表标识 数据库表名称
DB_ClassRoom 教室数据库 DB_ClassRoom_base 教室基本信息表
DB_Teacher 教师数据库 DB_Teacher_base 教师基本信息表
DB_Student 学生学籍管理数据库 DB_Student_base
DB_Student_encourage
DB_Student_punish
DB_Student_update
DB_Student_after
学生基本信息表
学生奖励信息表
学生处分信息表
学生学籍变动信息表
学生课外活动信息表
DB_Grad 学生成绩数据库 DB_Grade_base
DB_Grade_makeup
学生成绩表
学生补考或重修成绩表
DB_Stat 统计数据库 DB_Stat_task
DB_Stat_class
DB_Stat_update
教师开课统计表
按班级统计信息表
按班级统计异动信息表
DB_Course 课程管理数据库 DB_Course_base 课程信息表
DB_TeachTask 教师任课数据库 DB_TeachTask_base 教师任课信息表
DB_ClassTable 课表数据库 DB_ClassTable_base 课表
为每一个关系表定义数据结构
主题数据库标识 主题数据库名称 数据库表标识 数据库表名称
DB_Studen 学生学籍管理数据库 DB_Student_base 学生基本信息表
数据元素标识 含义 类型 长度 小数位 是否关键字 是否为空
StudNo 学生学号 char 10 Y NOT NULL
StudName 学生姓名 varchar 18 NOT NULL
OldName 曾用名 varchar 18
Sex 性别 char 2 NOT NULL
Birthday 出生日期 Date NOT NULL
ID_Card 身份证号 varchar 18 NOT NULL
…… …… …… …… …… …… ……
值得注意的是，主题数据库的标识、表标识以及数据元素的标识一定要用能够明确表示其含义的字符来命名，
其命名也要遵循一定的规范来进行，否则一个系统中常常包含几十个表以及上千甚至更多的数据元素，如果命
名不当必将引起理解和协调等各方面的混乱。
3.2.3 功能分析建立新系统逻辑结构
? 新系统逻辑结构的描述工具是数据流程图
图例：
外部项：指不受系统控制，在系统以外的事物或人，它表达了该
系统数据处理的外部来源和去处。
数据流：数据流表明了数据的流动方向及其名称，它是数据载体
的表现形式之一。
数据存储：用来指明数据保存的地方。
处理功能：表达了对数据处理的逻辑功能
外部项
名称
标识
功能描述
外部项
数据流
数据存储
处理功能
数据存储名称
数据流名称
标识
功能完成者
? 功能分析是在业务流程调查和数据分析基础上
进行的，首先从底层的业务流程开始分析，将
能够由计算机进行处理的业务抽取出来，然后
再根据数据模型和抽取后的处理功能构造新系
统的逻辑结构。
“学籍处理”逻辑结构
学生档案
管理
1.1
学生基本信息表
( 学生学籍管理数据库)
学生
学生学籍
变动处理
1.2
学生学籍变动信息表
( 学生学籍管理数据库)
学生奖励
信息管理
1.3
学生奖励信息表
( 学生学籍管理数据库)
学籍变动申请
学生处分
信息管理
1.4
学生处分信息表
( 学生学籍管理数据库)
学生课外
活动
信息管理
1.5
学生课外活动信息表
( 学生学籍管理数据库)
学生工
作部
学生奖励通知
学生处分通知
学生课外活动信息
教务处
教务处
教务处
教务处
教务处
审核学籍
1.6
教务处
学生成绩表
( 学生成绩数据库)
学生补考或重修成绩表
( 学生成绩数据库)
毕业资格
审查
1.7
教务处
学生基本信息表
( 学生学籍管理数据库)
学生
学籍变动通知
学生登记表
“制定教学计划”逻辑结构
教学计划
信息管理
2.1
课程信息表
( 课程管理数据库)
教学
秘书
专业教学计划
教务处
教学计划
信息打印
2.2
教务处
院系
院系
教师任课
信息管理
2.3
教务处
教师任课信息表 教师任课信息表
( 教师任课数据库)
教学计划
教师基本信息表
( 教师数据库)
“排课”逻辑结构
排课
5.1课程信息表
( 课程管理数据库)
教务处
教师
教师任课信息表
( 教师任课数据库)
教师课表
教室基本信息表
( 教室数据库)
课表
( 课表数据库)
调整课表
5.2
教务处
打印教师
课表
5.3
教务处
打印学生
课表
5.4
教务处
打印教室
课表
5.5
教务处
学生
教室管
理员
院系
教室课表学生课表
打印班级
课表
5.5
教务处
班级课表
“统计报表处理”逻辑结构
教师开课
情况统计
8.1
教务处
上级主
管部门
教师任课信息表
(教 师任课数据库)
学生基本信息表
(学 生学籍管理数据库)
教师开课统计表
(统 计数据库)
校领导
院系
学生成绩表
(学 生成绩数据库)
按班级
统计
学生人数
8.2
教务处
按班级统计信息表
(统 计数据库)
按班级
统计
学生变动
情况
8.2
教务处
按班级统计异动信息表
(统 计数据库)
教师开课统计表
学生情况统计表
学生异动情况统计表
教学管理系统总体逻辑结构
学籍处理
1
教务处
上级主
管部门
教师任课数据库
学生学籍管理数据库
学生工
作部
院系
学生奖励通知
学生处分通知
学生课外活动信息
专业教
学秘书
制定教学
计划
2
教务处
课程管理数据库
教学计划
院系
教师任课信息表
教师基本
信息管理
3
教务处
教师数据库
人事处
教师信息表
教室设施
管理
4
教务处
教室数据库
排课
5
教务处
课表数据库
学生
学生登记表
学生
学籍变动通知
院系
教学计划
教师
教师
课表
学生
教室管
理员
院系
教室
课表
学生
课表
班级
课表
成绩管理
7
教务处
学生成绩数据库
网上
学生选课
6
学生
统计报表
处理
8
教务处
教师任课数据库
校领导
统计数据库
教师开课统计表
学生情况统计表
学生异动情况统计表
网上信息
查询
9
院系
逻辑功能的审查
? 第一、数据流程图本身的正确性检查。
? 第二、逻辑功能正确性检查。
? 第三、检查新系统逻辑功能是否符合总体规划
中的总体方案要求。
新系统的逻辑结构的特征：
? 1、系统内各功能部分之间的数据存储及交换
关系都是通过主题数据库来实现的，充分体现
了第一章中所提到的信息系统开发的基本原理
和前提。
? 2、数据库的建立首先经过了总体规划，在充
分考虑到全局利益的前提下形成的，因此解决
了由分散开发所带来的一系列问题。
? 3、数据流出现在相关的外部项和处理功能之
间，表明了该系统与外界的接口 。
3.2.4 处理功能的表达
? 用自然语言表达处理功能通常存在以下几类问题：
– 界限不明确
– 逻辑条件的次序不明确
– 意义模糊的形容词或副词
3.4.2.1 结构式语言
? 结构式语言使用的词汇主要有三类：
– 1,祈使句中的动词；
– 2,在数据字典中定义的名词；
– 3,某些逻辑表达式中的保留字 。
? 结构式语言使用的语句只允许有四类：
– 1,简单的祈使句
– 2,判断句
– 3,循环语句
– 4,上述三种的复合语句
祈使句（动词 +名词）
? 获得当月水表数
? 获得上月底水表数
? 当月水表数减去上月底的水表数, 得到本月实际用水吨数
? 1.20元乘以实际用水吨数得到水费
? 将水费加到应交房租水电费中
? 获得当月电表数
? 获得上月底电表数
? 当月电表数减去上月底的电表数, 得到本月实际用电度数
? 0.80元乘以实际用电度数得到电费
? 将电费加到应交房租水电费中
? 获得房租费
? 将房租费加到应交房租水电费中, 得到住户的应交房租水电费
判断句：
? 形式 1（一般形式）：
– 如果 条件 1（ 成立 ）
– 则 动作 A
– 否则 （ 条件 1不成立 ）
– 就 动作 B
? 形式 2（嵌套形式）：
– 如果 条件 1（ 成立 ）
– 则 如果 条件 2（ 成立 ）
– 则 动作 A
– 否则 （ 条件 2不成立 ）
– 就 动作 B
– 否则 （ 条件 1不成立 ）
– 就 动作 C
? 形式 3：
– 如果 条件 1 则 动作 A
– 如果 条件 2 则 动作 B
– …………
循环句：
? 一般形式：
对每一满足条件的记录, 循环执行
动作 A
3.4.2.2 判断树
? 判断树是用一种树型图形方式来表示多个条件、多个
取值所应采取的动作。看一张判断树图形的时候，要
从左边（树根）开始，沿着各个分支向右看，根据每
一个条件的取值状态可以找出应该采取的动作，所有
的动作都列在这张图的最右侧
? 方法：
– 首先确定有哪些条件
– 第二确定每一个条件有几种可能的状态，即有几种
取值
– 第三要确定有哪些动作
– 最后确定每一项动作要依赖哪些条件及取值。
举例：
? 学校的奖学金有两种, 且记为奖学金 A和奖学金 B。
? 对于奖学金 A,凡各科成绩平均在 88分以上, 单科成
绩不低于 75分, 英语平均在 80分以上者可申请一等奖
学金 （ 金额 400元 ） ；凡各科成绩平均在 85分以上, 单
科成绩不低于 70分, 英语平均在 80分以上者可申请二
等奖学金 （ 金额 300元 ） 。
? 对于奖学金 B,凡各科成绩平均在 92分以上, 单科成
绩不低于 85分, 英语平均在 90分以上者可申请特等奖
学金 （ 金额 1500元 ） ；凡各科成绩平均在 90分以上,
单科成绩不低于 80分, 英语平均在 85分以上者可申请
一等奖学金 （ 金额 800元 ） ；凡各科成绩平均在 88分以
上, 单科成绩不低于 75分, 英语平均在 80分以上者可
申请二等奖学金 （ 金额 400元 ） ；凡各科成绩平均在 85
分以上, 单科成绩不低于 70分, 英语平均在 80分以上
者可申请三等奖学金 （ 金额 300元 ）
? 两个条件：奖学金种类，成绩
? 第一个条件有两个状态：奖学金 A和奖学金 B。
? 第二个条件有六个状态：依据平均成绩、单科
最低成绩和英语平均成绩来最终确定。
? 有六个处理动作，即最后发放的奖学金金额。
判断树：
? 其中：
– 计算出学生的平均成绩，将值放入 G中；
– 计算出学生各科的最低成绩放入 D中；
– 计算出英语的平均成绩放入 E中 。
奖学金
政策
奖学金
种类
成绩
奖学金 A
奖学金 B
G 大于等于 8 8 且
D 大于等于 75 且 E 大于等于 8 0
G 大于等于 8 5 且
D 大于等于 70 且 E 大于等于 8 0
G 大于等于 9 2 且
D 大于等于 85 且 E 大于等于 9 0
G 大于等于 9 0 且
D 大于等于 80 且 E 大于等于 8 5
G 大于等于 8 8 且
D 大于等于 75 且 E 大于等于 8 0
G 大于等于 8 5 且
D 大于等于 70 且 E 大于等于 8 0
奖学金
金额
4 0 0 元
3 0 0 元
1 5 0 0 元
8 0 0 元
4 0 0 元
3 0 0 元
3.4.2.3 判断表
? 方法
– 首先确定有哪些条件
– 第二确定每一个条件有几种可能的状态，即
有几种取值
– 第三要确定有哪些动作
– 第四给出所有条件的组合
– 最后确定每一项动作要依赖哪些条件及取值。
举例：
? 某工厂人事部门对一部分职工重新分配工作, 其
分配原则如下：
?, 如果年龄不满 18岁, 文化程度是小学, 则脱产
学习, 文化程度是中学, 则当电工 。 如果年龄满
18岁但不满 40岁, 如果文化程度是小学或中学, 若
是男性, 则当钳工, 若是女性, 则当车工, 文化
程度是大学, 则当技术员 。 如果年满 40岁及以上
者, 文化程度是小学或中学, 则当材料员, 文化
程度是大学, 则当技术员 。,
? 有三个条件：性别、年龄、文化程度。
? 性别有 2个取值
? 年龄有 3个取值
? 文化程度有 3个取值
? 所有条件的组合有,2× 3× 3＝ 18个。
条件名称 取值 含义
性别 0 男
1 女
年龄 0 未满 18岁
1 满 18岁但不满 40岁
2 满 40岁及以上
文化程度 0 小学
1 中学
2 大学
判断表（初始）：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
性别 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1
年龄 0 0 0 1 1 1 2 2 2 0 0 0 1 1 1 2 2 2
文化程度 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2
脱产学习 ※ ※
当电工 ※ ※
当钳工 ※ ※
当车工 ※ ※
当技术员 ☆ ※ ※ ☆ ※ ※
当材料员 ※ ※ ※ ※
☆为后补动作
判断表（整理后）：
1 2 3 4 5 6 7 8 9
性别 0 0 1 1
年龄 0 0 1 1 2 2 1 1
文化程度 0 1 2 0 1 0 1 0 1
脱产学习 ※
当电工 ※
当钳工 ※ ※
当车工 ※ ※
当技术员 ※
当材料员 ※ ※
例：, 教师基本信息管理, 处理功能的描述
处理功能标识 3 处理功能名称 教师基本信息管理
相关数据库 教师数据库 相关数据库表 教师基本信息表
功能需求：
1,查询需求,（ 按学院, 专业查询教师基本信息 ）
输入查询条件
获得满足条件的教师基本信息
显示查询结果
2,输入需求,（ 有新教师报到后向教师基本信息表中输入教师基本信息 ）
获得新教师的基本信息
验证教师基本信息的正确性
如果基本信息无误
则 向教师基本信息表中插入一条记录
否则 提示：, 教师基本信息中有错误信息,
3,修改需求,（ 发现教师基本信息输入有错误或教师信息变更则允许修改 ）
输入要修改的教师工作证号
按工作证号查询教师基本信息
显示查询结果
在查询结果中修改基本信息
验证基本信息的正确性
如果基本信息无误
则 修改教师信息
否则 提示：, 教师基本信息修改有误,
4,删除需求,（ 当某位教师调离学校则删除该教师的基本信息 ）
获得要删除的教师工作证号
按工作证号查询教师基本信息
显示查询结果
删除该条记录
说明,1,如果教师在删除年度担任教学任务则不允许删除
2,教师的出生日期和身份证号中的出生日期必须相符
3,教师的职称必须是教授, 副教授, 讲师, 助教, 实习教师, 研究员, 副研究员, 助理研究员
3.3 基于 UML的系统分析方法
? UML（ 统一建模语言,Unified Modeling Language）
是目前被广泛使用的面向对象系统的建模方法，支持
该方法的典型工具是 Rational Rose（ Rational Rose的
使用方法简介见附录）。采用 UML进行系统分析形成
的分析模型由 功能模型、对象模型和动态模型 组成。
首先进行需求调查建立 功能模型，用用例图来描述 ；
然后是细化功能模型衍生出对象模型和动态模型,对
象模型用类图来描述,它描述了实现用例所需要的数
据和操作（或称方法）,动态模型用状态图和顺序图
来描述,它描述了功能实现过程的各种动态。
3.3.1 业务流程调查建立功能模型
? 用例图（ Use Case Diagram） 符号,
? 角色 （ Actor）, 角色是与系统交互的人或事物, 角色可以是用
户, 其它系统或时间 。 当时间作为角色时, 一般是指一定时间触
发系统中的某个事件 。
? 用例 （ Use Case）, 用例是系统的功能模块, 它描述人们如何使
用系统 。
? 关系分为通信关系, 使用关系和扩展关系 。
? 通信关系 （ Communicates Relationship）, 描述角色与用例之间
的关系, 某一个角色启动一个用例或一个用例启动一个角色 。
用例角色 通信关系 使用关系或扩展关系
?, 学籍管理员, 角色启动与, 学籍处理, 用例的通信
? 使用关系（ Uses Relationship）,表示一个用例可以利用另一个用例
提供的功能。
? 扩展关系（ Extends Relationship）,表示允许一个用例扩展另一个
用例提供的功能。
学籍
处理
学籍管理员
学籍
处理
学籍管理员
统计
处理
统计员
身份
验证
< <
e x
te n
d s
> >
< <
e x
te
n d
s >
>
学籍
处理
学籍管理员
统计
处理
统计员
身份
验证
< <
e x
te n
d s
> >
< <
e x
te
n d
s >
>
使用用例图来描述教学管理系统总体业务流程
数据管理员
教室设施管理
教师基本信息管理
教师
排课
学生选课
学生
成绩管理员
学籍管理员
专业教学秘
书
教务秘书
统计报表处理
学籍处理
成绩管理
统计员
制订教学计划
,学籍处理, 用例的扩展
核实学生基本信息
校长
院系学籍管
理员
建立院系学生档案
初步审核学籍变动申请
审查学籍变动申请
审批
初步审查毕业资格
基于成绩的学籍处理
审核学籍
执行学籍变更
学生
审核及报批毕业资格
学籍管理员
统计报表处
理
建立学生档案
“制订教学计划”用例的扩展
排课
院系教务秘
书
汇总审核教学计划 教学计划协调
汇总教师任课信息
下达教学计划
教务秘书
统计报表处
理
汇总全校教师任课信息
,排课, 用例的扩展
院系教务秘
书
排定上课时间
下达课表
教务秘书
教室设施管
理
排定上课地点
制订教学计
划
,统计报表处理, 用例的扩展
制订教学计
划
教师开课情况统计
按班级统计学生人数
统计员
学籍处理
按班级统计学生变动情况
成绩管理
生成教师开课情况表
生成学生情况统计表
生成学生异动情况统计表
3.3.2 分析数据建立对象模型
? 对象模型中类之间可以有四种关系：
– 关联,（ Associations） 是类之间的连接
– 依赖性：是类之间的连接, 但依赖性的连接总是单向的, 它显示
一个类依赖另一个类的定义
客户 供应商
– 累积：累积关系是强关联，它反映的是整体和个体之间的关系
– 一般化,显示类之间的继承关系。
人
学生信息 教师信息
学生学籍变动信息
学生信息
学生基本信息
学生奖励信息
学生处分信息
学生课外活动信息
教学管理系统对象模型
3.3.3分析活动建立动态模型
? 业务流程调查所建立的功能模型主要是强调真
实而接近现实管理业务，但功能模型中存在着
需要调整的处理方式和不能够由系统来实现的
用例，为此需要根据前面的对象模型和优化后
处理方式调整功能模型，使之成为未来信息系
统的逻辑结构。
,学籍处理, 优化后的功能模型
学生课外活动信息管理
学生处分信息管理
学生奖励信息管理
学生
学籍管理员
建立学生档案
统计报表处
理
学籍变动处理
院系学籍管理
员
审核学籍
成绩管理
毕业资格审查
,制定教学计划, 优化后的功能模型
打印教学计划教学计划管理
教务秘书
教师任课信息管理
统计报表处理
,排课, 优化后的功能模型
自动排课
制订教学计
划
教室设施管
理
教务秘书
调整课表
学生
打印教师课表
教师
打印教室课表
教室管理员
打印学生课表
院系学籍管理
员
优化后的教学管理系统总体功能模型
统计报表处理
数据管理员 教室设施管理
教师基本信息管理
专业教学秘
书
制订教学计划
学生选课
统计员
教师
教务秘书
学生
成绩管理员
学籍管理员
学籍处理
排课
成绩管理
网上信息查询
院系学籍管
理员
用结构式语言、判断树、判断表 在,用例说明窗口,描述 每一
个叶子层用例
用状态图描述 每一个叶子层用例
提示：出现
修改错误
获得查
询条件
获得添
加信息
获得要修改或删
除的教师信息
教师基本信
息管理页面
清空查
询条件
提示：出现
删除错误
提示：出现
添加错误
添加教师基
本信息页面
退出
显示查
询结果
修改存
盘
修改状
态
执行删
除
执行添
加
执行修
改
请求管理教师基本信息
请求清空查询条件
请求查询
请求退出
请求添加
返回
请求存盘
出错
正确
选择要修改或删除的教师信息
出错
请求删除
正确
请求修改
正确
出错
请求修改存盘
返回
返回
用
顺
序
图
描
述
每
一
个
叶
子
层
用
例
, 数 据管理
员
教师基本信
息管理页面
教师信息编
辑页面
教师实体
1,请 求清空
清空查询
条件
1.1,清空 查询条件
添加操作
2,请 求添加
2.1,打开 教师信息编辑页面
3,请 求存盘
3.1,验证 页面添加信息
3.2,执行 添加操作
查询操作
4,请 求查询
4.1,获得 查询条件
4.2,执行 查询操作
5,请 求修改
5.1,获得 修改信息
5.1.1,验证 页面修改信息
5.1.2,执行 修改操作
修改操作
6,请 求删除
删除操作
6.1,获得 删除信息
6.2,执行 删除操作
返回操作
7,请 求返回
7.1,执行 关闭页面返回操作
学籍
处理
学籍管理员
统计
处理
统计员
身份
验证
< <
e x
te
n d
s >
>
< <
e x
te
n d
s >
>
