信息系统的开发与管理教程
中国人民大学：左美云
zuomy@ruc.edu.cn
第六章
一、结构化方法
结构化方法遵循的基本原则
? 面向用户的观点；
? 严格区分工作阶段, 每个阶段有明确的任务
和应得到的成果；
? 按照系统的观点, 自顶向下地完成系统的研
制工作；
? 充分考虑变化的情况；
? 工作成果文献化, 标准化 。
结构化方法的不足和局限性
? 开发周期长 。
? 早期的结构化方法注重系统功能, 兼顾数据
结构方面不够 。
? 结构化程序较低的系统, 在开发初期难于锁
定功能要求 。
二、数据流图
系统分析
? 系统分析要回答新系统, 做什么, 这个关键
性的问题 。
? 系统分析是研制信息系统最重要的阶段, 也
是最困难的阶段 。 系统分析的困难主要来自
三个方面,
– 问题空间的理解
– 人与人之间的通讯
– 环境的不断变化
? 数据流图是结构化系统分析的主要工具 。 结
构化系统分析采用介于形式语言和自然语言
之间的描述方式, 通过一套分层次的数据流
图, 辅以数据字典, 小说明等工具描述系统 。
数据流（程）图
数据流程图
? 数据流图描述数据流动, 存储, 处理的逻辑
关系, 也称为逻辑数据流图 （ Logical Data
Flow Diagram）, 一般简称为 DFD。
? 数据流图用到四个基本符号, 即,
– 外部实体
– 数据流
– 数据存储
– 数据处理过程
外部实体
? 外部实体指系统以外又与系统有联系的人或
事物 。 它表达该系统数据的外部来源或去处,
例如顾客, 职工, 供货单位等等 。 外部实体
也可以是另外一个信息系统 。
数据处理
? 处理指对数据的逻辑处理功能, 也就是对数据的变换功能 。
? 在数据流图中, 用带圆角的长方形表示处理,
长方形分为三个部分：标识部分；功能描述
部分；功能执行部分 。
数据流
? 数据流是指处理功能的输入或输出, 用一个
水平箭头或垂直箭头表示 。 箭头指出数据的
流动方向 。
? 数据流可以是信件, 票据, 也可以是电话,
等等 。
数据存储
? 数据存储表示数据保存的地方 。 这里, 地方,
并不是指保存数据的物理地点或物理介质,
而是指数据存储的逻辑描述 。
? 在数据流图中, 数据存储用右边开口的长方
条表示 。 在长方条内写上数据存储的名字 。
? 为了区别和引用方便, 再加一个标识, 用字
母Ｄ和数字组成 。
数据流（程）图的其他表示法
三、数据流图案例
学籍管理系统顶层 DFD
学籍管理系统 的第一层 DFD
“成绩管理”框的展开 第 2层
“分析期末成绩”框的展开 第 3层
“确定异动情况”框的展开 第 4层
关于数据流图层次的划分
? 展开的层次与管理层次一致, 也可以划分得
更细 。 处理块的分解要自然, 注意功能的完
整性 。
? 一个处理框经过展开, 一般以分解为 4～ 10个
处理框为宜 。
? 最下层的处理过程用几句话, 或者用几张判
定表, 或一张简单的 HIPO图能表达清楚 。 其
工作量一个人能承担, 若是计算机处理, 一
般不超过 100条程序语句 。
检查数据流图的正确性
? 数据守恒, 或称为输入数据与输出数据匹配
? 在一套数据流图中的任何一个数据存储, 必定有流
入的数据流和流出的数据流, 即写文件和读文件,
缺少任何一种都意味着遗漏某些加工 。
? 父图中某一处理框的输入, 输出数据流必须出现在
相应的子图中, 否则就会出现父图与子图的不平衡 。
? 任何一个数据流至少有一端是处理框 。 换言之, 数
据流不能从外部实体直接到数据存储, 不能从数据
存储到外部实体, 也不能在外部实体之间或数据存
储之间流动 。
提高数据流图的易理解性
? 简化处理间的联系 。
– 在数据流图中, 处理框间的数据流越少, 各个处
理就越独立, 所以我们应尽量减少处理框间输入
输出数据流的数目 。
? 均匀分解
? 适当的命名
四、数据字典
数据字典
? 系统分析中所使用的数据字典, 主要用来描
述数据流图中的数据流, 数据存储, 处理过
程和外部实体 。
? 数据字典把数据的最小组成单位看成是数据
元素 （ 基本数据项 ）, 若干个数据元素可以
组成一个数据结构 （ 组合数据项 ） 。
? 数据结构是一个递归概念 。
? 数据元素组成数据结构, 数据结构组成数据
流和数据存储 。
? 数据字典中有六类条目：数据元素, 数据结
构, 数据流, 数据存储, 外部实体, 处理 。
数据元素
? 数据元素是最小的数据组成单位, 也就是不
可再分的数据单位, 如学号, 姓名等 。
? 对每个数据元素, 需要描述以下属性,
– 名称
– 别名
– 类型 （ 字符型还是数字型等 ）
– 取值范围和取值的含义
– 长度
– 除以上内容外, 数据元素的条目还包括对该元素
的简要说明, 与它有关的数据结构等等 。
数据元素条目的一个例子
数据结构
? 数据结构的描述重点, 是数据之间的组合关
系, 即说明这个数据结构包括哪些成分 。
? 一个数据结构可以包括若干个数据元素或
（ 和 ） 数据结构 。 这些成分中有三种特殊情
况,
? 任选项：这是可以出现, 也可以省略的项,
用, 〔 〕,表示 。
? 必选项：在两个或多个数据项中, 必须出现
其中的一个称为必选项 。 必选项的表示办法,
是将侯选的多个数据项用, { }”括起来 。
? 重复项 。 即可以多次出现的数据项 。
数据结构条目的一个例子
数据流
? 关于数据流, 在数据字典中描述以下属性,
– 数据流的来源；
– 数据流的去处；
– 数据流的组成 （ 一个数据流可包含一个或多个数
据结构 ） ；
– 数据流的流通量；
– 高峰时的流通量 。
数据流条目的一个例子
数据存储
? 数据存储的条目, 主要描写该数据存储的结构, 及
有关的数据流, 查询要求 。
? 有些数据存储的结构可能很复杂, 如, 学籍表,,
包括学生的基本情况, 学生动态, 奖惩记录, 学习
成绩, 毕业论文成绩等, 其中每一项又是数据结构 。
? 这些数据结构有各自的条目分别加以说明, 因此在
,学籍表, 的条目中只需列出这些数据结构, 而不
要列出这些数据结构的内部构成 。
? 数据流图是分层的, 下层图是上层图的具体化 。 同
一个数据存储可能在不同层次的图中出现 。 描述这
样的数据存储, 应列出最低层图中的数据流 。
数据存储条目的一个例子
处理框条目的一个例子
外部实体条目的一个例子
五、系统设计
系统分析与系统设计
? 系统设计包括总体 （ 概要 ） 设计和详细设计两大部
分 。
? 系统分析阶段要回答的中心问题是系统, 做什么,,
即明确系统功能 。 这个阶段的成果是系统的逻辑模
型 。
? 系统设计要回答的中心问题是系统, 怎么做,, 即
如何实现系统分析说明书规定的系统功能 。 这一阶
段, 要根据实际的技术条件, 经济条件和社会条件,
确定系统的实施方案, 即系统的物理模型 。
? 系统设计的目标是从保证系统的变更性入手, 设计
出一个易于理解, 容易维护的系统 。
系统设计应注意的问题
? 把系统划分为这样一些部分, 其中每一部分的功能
简单明确, 内容简明易懂, 易于修改 。 我们把这样
的部分称为模块 。
? 系统分成模块的工作按层次进行 。
? 每一个模块应尽可能独立 。 即尽可能减少模块间的
调用关系和数据交换关系 。 当然, 系统中的模块不
可能与其它模块没有联系, 只是要求这种联系尽可
能少 。
? 模块间的关系要阐明 。 这样, 在修改时可以追踪和
控制 。
总体设计的任务
? 将系统划分成模块；
? 决定每个模块的功能；
? 决定模块的调用关系；
? 决定模块的界面, 即模块间信息的传递 。
? 总体设计：从数据流图导出结构图
变换分析和事务分析
? 变换分析
– 找出主加工, 逻辑输入和逻辑输出
– 设计顶层模块和第一层模块
– 设计中, 下层模块
? 事务分析
? 数据流图层次的转换
变换分析
事务分析 1
事务分析 2
数据流图的层次与模块结构
六、详细设计
详细设计的任务
? 代码设计；
? 数据库设计；
? 输入设计；
? 输出设计；
? 人机对话设计；
? 处理过程设计 。
代码设计的原则
? 唯一性
? 合理性
? 可扩充性
? 简单性
? 适用性
? 规范性 （ 国家有关编码标准 ）
? 系统性
? 编写代码表
输入输出设计的原则
? 输出设计包括以下几方面的内容,
– 确定输出内容
– 选择输出设备与介质
– 确定输出格式
? 输入设计应遵循以下原则,
– 最小量原则 。
– 简单性原则 。
– 早检验原则 。
– 少转换原则 。
? 输入设计的内容包栝,
– 确定输入数据内容
– 确定数据的输入方式
– 确定输入数据的记录格式
– 输入数据的正确性校验
– 确定输入设备 。
人机对话设计
? 对话要清楚, 简单, 用词要符合用户观点和
习惯 。
? 对话要适应不同操作水平的用户, 便于维护
和修改 。
? 错误信息提示的设计要有建设性 。
? 关键操作要强调和警告 。
人机对话和处理过程设计
? 人机对话设计
– 对话要清楚, 简单, 用词要符合用户观点和习惯
– 对话要适应不同操作水平的用户, 便于维护和修改
– 错误信息提示的设计要有建设性 。
– 关键操作要强调和警告 。
? 处理过程的设计
– 处理过程设计的关键是用一种合适的表达方法来描
述每个模块的执行过程 。
– 日常用的描述方式有流程图, 盒图 （ NS图 ）,
PAD图 。
流程图
NS图
PAD图
七、系统实施
? 硬件准备
? 软件准备
? 人员培训
? 数据准备
系统实施阶段的任务
第七章
一、原型法
原型法的思想
?在投入大量的人力, 物力之前,
在限定的时间内, 用最经济的方
法构造一个系统原型, 使用户尽
早看到未来系统的概貌, 在系统
原型的实际运行中与用户一起发
现问题, 提出修改意见, 不断完
善原型, 使它逐步满足用户的要
求 。
原型法的步骤
? 明确用户基本信息需求
? 建立初始原型：构成初始原型时要注意两个
原则,
– ① 集成原则 。 尽可能用现成软件和模型来构成,
这需要相应的工具；
– ② 最小系统原则 。 耗资一般不超过总投资的 10％,
但能反映系统的基本特性, 并能扩充和完善 。
? 评价原型
? 修改和完善原型
原
型
法
的
步
骤
原型法的优点
? 增进用户与开发人员之间的沟通
? 用户在系统开发过程中起主导作用
? 辨认动态的用户需求
? 启迪衍生式的用户需求
? 缩短开发周期, 降低开发风险
二、面向对象方法
（一）,OO基本概念
对象
? 对象是一些属性及专用服务的封装体, 它是问题空
间中一些东西的抽象 。
? 由以上定义可知, 对象就是我们在问题空间中要考
虑的那些人或事物 。 它具有一组属性和一组操作 。
这些属性的值刻画了一个对象的状态, 而这些操作
是对象的行为, 通过它们改变对象的状态 （ 即属性
值 ） 。
? 数据和操作封装于对象的统一体中, 而不是分开 。
这样, 对象就具有较强的独立性和自治性, 具有很
好的模块性, 为软件重用奠定了坚实的基础 。
? 与对象相关的一个概念是对象类 （ Object Class） 。
对象类简称类, 是有相似属性和行为的多个对象的
集合 。 例如, 对象, 客车,,, 货车,,, 拖车,
等, 它们属一个共同的类, 车辆, 。
封装和继承
? 封装即信息隐藏 。 对象是一个很好的封装体 。 它向
外提供的界面包括一组数据结构 （ 属性 ） 和一组操
作 （ 服务 ）, 而把内部的实现细节 （ 如函数体 ） 隐
蔽起来 。
? 继承指对象继承它所在类的结构, 操作和约束, 也
指一个类 （ 子类 ） 继承另一个类 （ 父类 ） 的结构,
操作和约束 。 继承体现了一种共享机制 。
? 继承一个单一的父类时叫单继承, 如果有两个以上
的父类则是多继承 。 前者继承关系是单一的, 体系
结构表现为树；后者继承关系复杂, 呈网状结构 。
? 继承的作用在于信息组织和分类, 简化对象及类的
创建工作量 。 利用继承性, 只要在原有类的基础上
增加, 删除或修改少量数据和方法就可以得到子类
消息
? 一条消息告诉一个对象做什么, 它指出：发送者, 接
收者, 需要执行的服务, 需要的参数 。
? 例如, 对象汽车具有, 行驶, 这项操作, 为了让汽车
以时速 50公里的时速行驶, 需要向汽车对象传送, 行
驶, 和, 时速 50公里, 的消息, 来触发这个对象 。
? 值得注意的是,, 消息传递, 与传统的, 过程调用,
的区别 。
? 发送消息只是触发对象 。 接受对象收到消息后, 按消
息及消息调用自己的操作来改变状态或返回结果 。 因
此, 同样的输入参数可能因对象的初始状态不同而得
到不同的终态, 或输出不同的结果 。 而过程调用则只
要输入相同的参数, 输出总是一样的 。
（二）,OO方法的特点
OO遵循的法则及其特性
? 三个构造法则,
– 区分对象及其属性, 例如, 区分一棵树和树的大
小；
– 区分整体对象及其组成部分, 例如, 区分一棵树
和树枝；
– 不同对象类的形成及区分, 例如, 所有树的类和
所有车辆的类 。
? OO的优良特性
– 抽象性, 封装性, 继承性, 多态性
多态性
? 多态性又叫多形性, 指相同的操作 （ 或函数,
或过程 ） 可作用于多种类型的对象并获得不
同的结果 。
? 在面向对象方法中, 可给不同类型的对象发
送相同的消息, 不同的对象分别作出不同的
处理 。
? 例如, 给整数对象和复数对象定义不同的数
据结构和加法运算, 但可以给它们发送相同
的消息, 做加法运算,, 整数对象接收此消
息后做整数加法, 复数对象则做复数加法,
产生不同的结果 。 多态性增强了软件的灵活
性, 重用性, 可理解性 。
（三）面向对象分析
面向对象分析的特点
? 面向对象的分析 （ OOA） 要求把问题空间分
解成一些类或对象, 找出这些对象的特点
（ 即属性和服务 ）, 以及对象间的关系 （ 一
般 /特殊, 整体 /部分关系 ）, 并由此产生一个
规格说明 。
? OOA有助于改善：问题空间的理解, 人与人
之间的通讯和需求的不断变化 。
? OOA由五个主要步骤构成：标识对象, 标识
结构, 定义主题, 定义属性 （ 及实例连接 ）,
定义服务 （ 及消息连接 ） 。
标识对象
? 寻找对象：寻找对象应从问题空间, 文字资
料和图片资料入手, 寻找结构, 其他系统,
设备, 要记住的事件, 人扮演的角色, 地点
和组织单元等, 以便发现可能的对象 。
? 挑剔对象 。 对那些不必记住的事物与服务,
单个属性或派生结果 （ 如, 年龄, 是, 出生
日期, 的派生结果 ）, 就要考虑它们可能并
不是对象 。
? 命名对象 。 用单个名词或形容词加名词作对
象名, 尽量选择反映主题的标准词汇作对象
名 。
车辆登记和发照（发驾驶执照）系统
? 车主购车后持相关证件到主管部门登记注册, 缴纳
费用, 获得牌照 。 注册后, 登录车况信息和车主信
息 。 系统维护下列信息,
– 组织机构 （ 名称, 经理, 地址, 电话等 ）
– 职员 （ 用户名, 审查, 开始日期, 结束日期等 ） ；
– 车主 （ 合法名, 地址, 电话等 ） ；
– 发照 （ 号码, 所有权证件, 费用等 ） ；
– 注册 （ 日期, 品牌, 费用等 ） ；
– 车辆 （ 号码, 年份, 制造厂, 厢体颜色, 自重, 载客量,
燃料, 价格等 ） ；
– 另外还有,
? 对货车：现时自重
? 对摩托车,× 自重
? 对拖车,× 燃料, × 载客量
? 对旅游拖车：厢体号, 长度 。
登记和发照系统中的对象
标识结构
? 分类结构
– 分类结构有助于刻画出问题空间的类成员层次 。
它通过搜集公共特性, 并把这种特性扩充到特例
之中, 显示现实世界事件的通用性及专用性 。
– 继承的概念是分类结构的一个重要组成部分 。
– 定义分类结构时, 要分析通用类是否表达了专用
类的共性, 专用类是否表示了个性 。 子类把不需
继承的服务和属性标记为, X”。
? 组装结构
– 组装结构刻画了一个整体及其组成部分 。 例如,
一辆汽车由发动机, 传动装置和刹车装置组成 。
登
记
和
发
照
系
统
中
的
结
构
标识主题
? 首先, 对每个对象和每个结构增加一个相应主题,
如果主题的个数超过 7个左右, 则进一步提炼主题,
一旦对象和结构之间的连接得到标识, 根据需要,
把紧耦合的主题合在一起提供一个更好的模型概观
供读者理解 。
? 然后, 列出主题及主题层上各主题之间的消息连接 。
? 最后, 对主题进行编号, 在层次图上列出主题以指
导读者从一个主题到另一个主题 。 每一层都可以组
织成按主题划分的图 。
登记和发照系统中的主题
标识属性
? 标识属性 。
? 属性定位 。
– 通用属性应放在结构的高层, 特殊属性放在低层
– 如果一个属性适用于大多数的特殊分类, 可将其放在通
用的地方, 然后在不需要的地方把它覆盖 （ 即用, ×,等
记号指出不需要继承该属性 ）
– 如果发现某个属性的值有时有意义, 有时却不适用, 则
应考虑分类结构 。
– 根据发现的属性, 还可修订对象 。
? 标识实例连接 。
– 多重性：一对一 （ 1:1） 的, 一对多 （ 1:M）, 多对多
（ M,M）
– 参与性：表示实例连接是强制的还是任意的？
描
述
实
例
之
间
关
系
的
符
号
登
记
和
发
照
系
统
中
的
属
性
标识服务
? 服务可定义为：收到一条消息之后所执行的
处理 。
? 服务定义了对象及类所需的行为 。 行为分为,
– 有直接动因的行为；
– 进化史上的相似行为；
– 功能相似的行为 。
? 标识服务 （ 即对象的行为 ） 的策略分别对应
于上述三类行为,
– 直接动因对应：状态 —事件 —响应 （ 辅助策略 ） ；
– 进化史对应：对象生命历程 （ 辅助策略 ） ；
– 功能对应：最基本的服务 （ 基本策略 ） 。
标识服务的基本策略
? Occur（ 实例的增加, 修改, 删除和选择 ）
? Calculate（ 计算 ） ；
? Monitor（ 监控 ） 。
? 这三种基本服务提供了标识服务的基本策略, 所有
的 OOA模型都使用, Occur”服务；
? 当一个实例需要另一个实例中说明的处理结果时,
使用它的, Calculate”服务；
? 而有关实时处理的那一部分将使用, Monitor”服务,
,Monitor”服务执行对外界系统, 设备或用户的运
行监控 。
对象生命历程的辅助策略
? 定义基本的对象生命历程序列：增加, 修改,
选择和删除；
? 检查每一步的演变：扩展每一步, 反映出增
加, 修改, 删除的演变；
? 增加基本序列：对象或分类结构响应其他事
件吗？
? 增加服务：根据扩展的每一步增加服务, 一
般所增加的服务是对象的基本服务的演变 。
状态 —事件 —响应的辅助策略
? 定义系统的主要状态；
? 对每一个状态, 列出外部事件和所需的响应；
? 根据事件和响应增加服务 （ 和消息连接 ） 。
? 辅助策略有助于发现可能遗漏的, Calculate”
和, Monitor”服务 。
建立消息连接
? 首先在已经存在实例连接的对象和分类结构
之间增加消息连接,
? 然后检查对象和分类结构, 包括封装在其中
的属性, 寻找一个实例所需要的另一个实例
的服务, 从中找到消息,
? 再次在发送者的服务说明中建立消息连接的
文档, 在接收者的服务说明中建立相应的执
行服务的文档 。
? 最后详细说明服务 。
登
记
和
发
照
系
统
中
的
服
务
（四）面向对象设计
OOD的内容
? 问题空间部分的设计 （ PDC）
? 人机交互部分的设计 （ HIC）
? 任务管理部分的设计 （ TMC）
? 数据管理部分的设计 （ DMC）
问题空间部分的设计（ PDC）
? PDC的设计策略包括三部分：运用 OOA的结果；改
进 OOA的结果；增补 OOA的结果 。
? 对 OOA结果的增补原因和准则包括,
– 重用设计和编程的类：为了重用而引进现成的类 。
– 把问题空间专用类组合在一起：附加一个根类把所有类
组织起来 。
– 通过增添一般类而建立协议：引进一个附加类, 作为有
相似服务及相应属性的一般类 。
– 改进性能：为改进速度, 可能合并一些高度耦合的类,
还可能在类及对象中扩充一些保存临时结果的属性或一
些低层控制块；
– 提供数据管理部分：增加属性和服务使对象能够被保存；
– 增加低层成分：增加类来反映一些低层的逻辑细节；
– 调节继承的支持级别：如果 OOA的结果包括多继承, 而
编程语言只支持单继承甚至无继承时, 就要作相应调整 。
多继承展平为单继承
人机交互部分的设计（ HIC）
? 对人分类 。 把人按技能层次, 组织层次, 不同身份进行分类,
增加与系统交互的人的子集 。
? 描术人及其任务脚本 。 对每一类人, 描述其身份, 目的, 特
征, 关键的成果因素 （ 必须 / 想要 …, 喜欢 / 不喜欢 / 有偏
见 … ） 熟练程度及任务剧本 。
? 设计命令层 。 命令层可能以菜单屏面或菜单条或一系列图符
呈现给人们, 要按使用频度及用户工作步骤排列服务名 。 宽
度一般为 7± 2。
? 设计详细的交互 。 考虑的准则有：一致性；操作步骤少；不
要, 哑播放,, Undo；趣味与吸引力 。
? 继续做原型 。 做几个可候选的原型, 让人们一个一个地试用,
要达到, 臻于完善,, 由衷地满意 。
? 设计 HIC类 。 设计 HIC类, 从组织窗口和部件的人机交互设
计开始, 窗口作基本类, 部件作属性或部分类, 特殊窗口作
特殊类 。 每个类包括窗口的菜单条, 下拉菜单, 弹出菜单的
定义, 每个类还定义了用来创造菜单, 加亮选择等所需的服
务 。
任务管理部分的设计（ TMC）
? 识别事件驱动任务 。 事件驱动任务是指睡眠任务
（ 不占用 CPU）, 当某个事件发生时, 任务被此事
件触发, 任务醒来作相应处理, 然后又回到睡眠状
态 。
? 识别时钟驱动任务 。 按特定的时间间隔去触发任务
进行处理, 如某些设备需要周期性的数据采集和控
制 。
? 识别优先任务和关键任务 。 把它们分离开来进行细
致的设计和编码, 保证时间约束或安全性 。
? 识别协调者 。 增加一个任务来协调诸任务, 这个任
务可以封装任务之间的协作 。
? 审查每个任务, 使任务数尽可能少 。
? 定义每个任务：包括任务名, 驱动方式, 触发该任
务的事件, 时间间隔, 如何通讯等 。
OOD的评价
? 对每一种不同的方案有不同的设计, 一个好的设计
就是经过权衡选择使整个生命周期内系统总开销最
少的那个设计 。
? OOD的评判标准包括：耦合, 内聚, 重用及其他 。
– OOD的其他评判标准包括结构的深度, 设计的简单性和
清晰度, 公认的优雅风格等 。
? 耦合分交互耦合和继承耦合 。
– 交互耦合指两个对象间传递消息以实现交互 。 这种耦合
越小越好, 因为信息传输量越小, 对象的独立性和模块
性就越强, 当一个部分改动时, 对另一部分的影响就越
小 。 如果几个对象的耦合度实在太大, 可以考虑合并成
一个对象 。
– 继承耦合表示子类与父类的联系程度, 这种耦合度越大
越好, 因为应尽可能利用现有的一般类 。
第八章
（一）、硬系统思想
“硬, 系统方法的实质
? 存在一个目标状态 S1 和一个当前状态 S0,
并且有各种方式从 S0到达 S1。
（二）、软系统特点
软系统方法论面对的问题
? 有结构的问题是, 硬, 系统思想和大部分运筹学所
关心的问题 。
? 无结构的问题, 是目标阐明本身就是问题的那类问
题 。
? 认识问题, 定义问题, 求解问题, 问题得解 。 这对
于描述许多有结构问题的处理是足够的, 但其中有
两个方面不适于处理无结构的问题 。
– 首先, 这样的问题虽然是, 可认识的,, 但不是, 可定
义的, 。
– 第二, 对于人类活动系统中的问题, 历史常常改变了议
事日程 。
? 与人类活动系统在现实世界中的表现有关的问题是
一种感到不满意的状况 。 这种状况是不能精确定义
的 。 它介于就要成为现实和可能成为现实这两种感
觉中间 。
（三）、软系统案例
软系统案例 ——问题
? 生产计划和生产安排确实混乱；
? 质量控制实际上根本不存在；
? 按生产科长的看法, 一个产品性能及其最终用途的市场说明将使大部分问题得到解决；
? 各地区的销售代理人与生产总部之间没有良好的关系；
? 各分销店的代理人实际上只关心自己的事情；
? 没有有效的, 最为基本的关于生产和销售成本的金融信息；
? 而新任命的财务科长却想使大家确信他已改组了所有的帐目系统；
? 客户的抱怨声频繁不断；
? 在整个公司这一层次上缺乏计划, 并且管理科长根本没有把计划作为一个不断进行的过程的概念；
? 各个层次的管理信息流非常稀少而且是随意的；
? 整个公司的士气低落等等 。
软系统案例 ——困难？
? 对这些觉察到的问题中的任何一个的处理都有希望
获得某些改进, 但如此多的潜在问题使得他们无从
选择 。
? 如果这些问题连接成一个整体将使公司破产, 那么
对其中任何一个问题的解决又有什么用呢？
? 另一方面, 如果问题的聚集促使他们把公司考虑为
一个整体, 即作为一个研究重心所在的, 系统,,
那么系统分析 （ 即, 硬, 的, 目标导向的方法论 ）
这一智慧武器看来是无效的了 。
– 它需要首先定义系统的目标, 作为构造模型和在各候选
方法中选择的先决条件 。 但这在操作上是无用的, 因生
存这个明显的目标并不能使切克兰德他们采取下一步行
动 。
软系统案例 ——抽象？
? 切克兰德与研究小组面对困境没有放弃, 经过六周
的研究他们有了研究结果,
? 首先, 选择一种观点, 该观点以一种看起来与无数
问题有关的特定方式把公司看作一个整体, 然后根
据这种观点从逻辑上推出系统的结果 。
? 这意味着不是简单地把所要研究的, 系统, 看作为
一个单一的可描述实体的, 公司,, 或者说是一个
与问题无关的概念, 而是看作为一个与问题的核心
相关的公司 。
? 即这个作为研究对象的系统被认为是一个概念系统：
它促成并接受顾客对某一范围产品的订货, 以其专
长尽快地和有效地满足这些订货, 从而保证订货的
不断增长 。
软系统案例 ——解决？
? 这包含了这样一个观点：由于公司处于破产的边缘,
最重要的是在几个月内对作为公司运转基础的人类
活动系统作出某些改进 。
? 当然, 该公司是一个, 加工订货, 的系统, 对公司
的生产计划和安排系统, 公司计划系统和销售系统
都必须给予关注 。
? 前六周的研究所做的只是建立一个, 加工订货, 系
统的概念模型, 这是为了能看到系统的可改进之处 。
? 对公司的所有业务综合考察, 并把系统中的决策顺
序分离出来转换为一个系统模型, 决策顺序的逻辑
导致了一种系统结构, 它使得必需信息的目的, 来
源, 内容和接收都在一个确定的系统中流动 。
? 这种思想导致要设立两个部门, 一个部门面向顾客,
一个部门面向生产 。
? 接下来是使艾尔代尔纺织有限公司的实际活动逐渐
接近系统模型 。
软系统案例 ——启示？
? 上述研究以及切克兰德以前进行的其它研究
结果表明这样一个事实：问题求解者面对的
不是定义那些被认为是给定的系统目标, 而
是在众多的可能中选择何者是, 系统, 。
? 这种情景要求作出选择, 并为前后一致起见,
要清晰地陈述这种选择 。 这样看起来有用的
就是, 通过构造一个包含在这种选择中的人
类活动系统的概念模型来推算出选择的结果 。
? 在艾尔代尔的情形中是一个, 加工订货, 系
统 。 然后把系统模型与问题情景中实际观察
到的事物加以比较以提出并证明有用的变革
建议 。
（四）、软系统方法论
方
法
论
梗
概
软系统方法论 ——1
? 上图表示一个从 1到 7的时间序列, 这只是一种便于
描述的逻辑顺序 。 例如, 有可能从阶段 4开始一个
方案 。 原则上起点可以放在任何地方 。 有时返工和
重复也是必要的 。
? 方法论包含两种类型的活动 。
– 阶段 1,2,5,6,7是, 现实世界, 的活动, 必须包括问
题情景中的人 。
– 阶段 3,4,4a,4b是, 系统思想, 活动, 是否包括问题
情景中的人取决于具体的研究情景 。
? 一般说来, 前一类活动的语言可以是问题情景中的
任何规范的语言 。 因为在这一阶段, 现实世界的高
度复杂性通过翻译成更高层次的系统论的语言 （ 或
元语言 ） 而得到阐明和理解 。
软系统方法论 ——2
? 阶段 1和阶段 2是, 表达, 阶段, 即建立尽可
能多的问题情景 （ Problem Situation）, 在
问题情景中感到有问题 。
? 阶段 3包括命名一些看起来可能与假设的问题
相关的系统, 并简明地定义这些系统是什么 。
– 目的是得到一个对某些系统性质的简洁清楚的陈
述, 这些系统日后可能被看出与改善问题情景有
关 。 这当然不是固定的, 随着理解的加深, 该陈
述随时都可以进行反复的修改 。
– 阶段 3的这些定义被称之为, 根定义, （ Root
Definition）, 旨在表明囊括选出的系统的基本性
质 。
软系统方法论 ——3
? 给出这个定义之后, 阶段 4的任务是构造在根
定义中得到命名和定义的人类活动系统的概
念模型 （ Conceptual Model） 。 构造模型的
语言要求非常简单, 但却是细致的和有力的 。
? 构造模型的活动由 4a和 4b加以促进和补充,
? 4a是运用一般人类活动系统的模型来检查所
构造的模型是否有根本缺陷；
? 4b的任务则是修改模型, 如果有必要, 把模
型转变为其他更适于特定问题的形式 。
– 例如, 用系统动力学的语言重新表述可能更为恰
当, 或者把它重新表述为一个, 社会 —技术系
统, 。
软系统方法论 ——4
? 无论这种转变发生与否, 阶段 4所形成的模型
都要在阶段 5中, 进入现实世界,, 并与对现
实的知觉相比较 。 这种, 比较, 的目的是引
起一场与问题情景有关的人员的讨论 。
? 讨论的结果将在阶段 6确定可能的变革 。 这些
变革应同时满足两个标准：在所考查情景的
历史前提下, 它们应是合乎需要的和可行的 。
? 阶段 7的任务是把阶段 6的决定付诸行动以改
善问题情景 。
（五）、硬软方法论比较
硬软系统方法论比较 ——1
? 硬, 软两种方法论的主要差别是,
? 前者把问题和需求当作是, 给定的,, 因而
一开始提出的问题是：, 设计什么系统来解
决问题？, 或者, 什么系统将满足这个需
要？,
? 而后者却不得不允许后面的阶段出现完全不
可预料的回答 。
? 这样, 软方法论包含了比较阶段, 而在硬方
法中没有相应的阶段 。 在比较阶段, 系统思
想为关于变革的讨论提供了一个框架 。 而硬
方法此时忙于实施设计好的系统 。
硬软系统方法论比较 ——2
? 对于武器系统这样一个具体的对象, 如果采
用兰德式的系统分析, 其结果是产生一个具
体的武器系统, 但运用软系统方法论的分析,
则可能建议裁军, 让步, 或政治协商, 当然
也可能是具体的武器系统 。
? 撇开这种主要区别, 软方法论可以看作一般
情形, 而硬方法论是其中的一种特例 。 如果
讨论的问题有足够的良好定义, 则概念化就
成了系统设计,, 改善概念模型, 转化为
,优化定量模型,, 实施某些变革就成为实
施一个设计好的系统 。
（六）、多视点方法
分析员、问题情景、方法论
信息系统开发方法的适应性
? 戴维斯 （ Davis） 1982年提出信息系统开发方
法的应变性问题, 认为应该根据特定情景选
择相应的方法 。 他认为选择方法的关键是环
境不确定性程度 。 以下四个方面影响环境的
不确定性 。
– 系统的复杂性和不良结构 。
– 变迁的当前状态 。
– 受影响的用户数, 他们的技能 。
– 系统分析员的技能与经验 。
? 多视点方法是一种柔性框架, 它综合了多种
已经使用的方法, 提供多种开发技术与工具
供使用者根据具体问题情景选用 。
多视点方法的目标
? 多视点 （ Multiview)方法以软系统方法论为
指导, 综合了 20世纪 70年代以来几个重要方
面的研究成果, 把人类活动系统分析, 社
会 —技术系统观点, 数据分析与结构化分析
结合起来, 为信息系统开发创立了一个理论
框架 。 这种方法充分考虑所有系统使用者的
不同观点, 有助于回答下列五个问题,
– 拟建的信息系统如何促进组织目标的实现？
– 它能适应组织中使用者的工作过程吗？
– 有关人员能很好地操作计算机和使用它的输出吗
– 系统完成哪些信息处理功能？
– 系统的技术要求是什么？
谁的目标？
? 多数计算机专家, 程序员和技术系统分析员主要关
心第五个问题, 而多数系统的使用者对第四个问题
最感兴趣 。
– 在学院里, 多数计算机系的教学围绕着这两个方面 。 这
也许完全适合于这些方面的计算机专家 。 但是, 这两个
问题的正确回答, 还不足以保证信息系统的成功 。
? 第三个问题与人 —机界面有关 。
? 工会关心第二个问题 。
? 企业主管始终关心第一个问题, 不幸的是许多资深
的经理为之困惑 。
多视点方法的主要目标
? 信息系统常被视为有行为和社会结果的技术系统,
这种看法过于狭隘 。 把信息系统看作日益广泛地应
用信息技术的社会系统更为恰当 。 技术仅是它的一
个成分 。
? 更广泛透视信息系统, 需要识别到信息系统项目中
一系列利益相关者, 包括,
– 新系统的需求者和授权者,
– 负责信息系统相关部门的经理,
– 应用系统的工作人员,
– 建立和维护系统的计算机人员,
– 以及系统外的用户 （ 例如收到计算机输出的发票和表格
的顾客 ） 。
? 多视点方法的主要目标之一就是帮助他们互相沟通,
明确需求, 提出建议 。 由于他们看问题的角度不同,
要实现这一目标并不容易 。
多视点方法的实施 ——1
? 多视点方法的实施, 通常从顾问与总经理讨论项目
安排开始 。 他们要回答上述第一个问题,
– 组织投资信息技术希望实现什么目标？
– 是减少书面工作, 减少人员及其他成本, 还是获得更有
见识的决策？
? 这个阶段还要研究所定的目标是否可行, 拟建的信
息系统是不是实现目标的最好途径 。 答案也许是重
新考虑目标, 改善手工操作, 继续进行有关计算机
化的研究 。 也可能要求在计算化的同时, 或者在此
之前, 要改善现有的系统 。
? 在这之后, 分析员找出需要收集和处理的信息, 以
及需要完成的信息处理功能 。
多视点方法的实施 ——2
? 完成上述阶段的工作, 不需要数据库管理系统, 软
件包等等专门的计算机技术知识 。
? 通过这些工作, 分析员明白了系统的需求, 可与供
应商洽谈采购计算机系统的事宜, 从人文和技术角
度对系统提出要求, 适宜的定价和服务支持 。
? 若公司有自己的数据处理部门, 则技术分析员和程
序员可以根据需求说明书建设合适的系统 。 若购买
或建设这样一个系统有困难, 则需要对某些阶段再
次研究 。
? 具体情况不同, 多视点方法的实施可以有很大的差
别 。 目标是否清楚确定, 用户实际参与程度, 情况
复杂程度, 管理类型和观点, 这些因素都会影响项
目进程 。 从这一角度看, 多视点方法是开发信息系
统的一种探索方法 。
多视点方法的轮廓或阶段
? 一般来讲, 这种方法包括五个阶段, 每个阶
段都有相应看问题的观点和处理相应问题的
方法 。 这五个阶段是,
– 人类活动系统分析；
– 信息分析 （ 也称为信息模型化 ） ；
– 社会 —技术分析与设计；
– 人 —机界面设计；
– 技术方面设计 。
Multiview轮廓
多视觉方法的简明图
人
类
活
动
系
统
分
析
人类活动系统分析 ——1
? 这个阶段可以分成 4个子阶段, 10个步骤,
– 理解问题情景 （ 步骤 1—3）
– 构建系统模型 （ 步骤 4—7）
– 比较系统模型与现实 （ 步骤 8）
– 决策与执行 （ 步骤 9,10）
? 图中描绘富图 （ rich picture） 就是反复的过程 。 富
图显示处理过程的构造及相互之间的联系 。 图的要
素包括系统的客户, 参与的人员, 需完成的任务,环境, 系统的业主 。
? 问题的解 决者从富图抽取问题 主题 （ problem
themes）, 这是指图中可能引发问题因而值得更详
细研究的对象 。 如两个部门之间缺乏通讯, 供应不
足, 等等 。
? 得出主题之后, 问题解决者设想和命名相关系统（ relevant systems） 。 相关系统使问题主题更明白
清晰 。
人类活动系统分析 ——2
? 例如,
– 问题主题：两个部门冲突
– 相关系统：消除冲突系统或重新划分部门边界系统
? 本阶段最重要的讨论, 是比较几个不同的相关系统,
并从中选取最适用的一个 。 问题解决者与业主必须
决定用什么观点描述相关系统 。 例如消除冲突系统
– 可以描述为, 为使冲突最小而采用严格的行为和决策规
则的系统,,
– 也可以描述为, 行动者充分加强部门之间通讯和理解的
综合决策系统,,
– 甚至也可以描述成, 任何把不同意见汇集于中心体而使
部门之间的冲突减少到最小的系统, 。
人类活动系统分析 ——3
? 选定一种特定观点或根定义 （ root definition） 之后, 还要
进一步推敲 。 根定义可以从它必须包括的要素进行分析检
查, 例如,
– 系统的业主是谁？
– 是否包括了全部行动者？
– 系统的受益者, 受害者分别是谁？ 等等 。
? 若业主和问题解决者对得到的根定义都表示满意, 则可以
列出覆盖根定义所规定系统必不可少的活动的动词表, 构
建系统的概念模型 （ conceptual model） 。
? 根定义描述了系统, 是什么,, 而概念模型描述系统将要
,做什么, 。
? 用形式概念系统和其它系统思想对概念模型进行核查, 使
之更完善更适用 。
? 下一步是将完善的概念模型与富图表达的, 现实世界, 进
行比较, 找出二者的差别, 与业主讨论改善问题情景的措
施 。
信息分析 ——1
? 这一阶段也称为建立信息模型 （ information
modelling）, 目的是根据上一阶段得到的根
定义和概念模型, 分析系统的实体与功能 。
这个阶段不考虑最终如何开发系统 。
? 开发功能模型
– 首先识别系统的主功能,
– 然后将主功能逐层分解为子功能, 直到系统分析
员认为不必再分解为止 。 问题情景复杂程度不同,
分解层数也不同, 一般可分解四至五层 。
– 数据流图 （ data flow diagrams） 是进行功能分
解, 表达功能模型的工具 。
信息分析 ——2
? 开发实体模型
– 开发实体模型, 系统分析员需要从相应领域抽取和命名
实体 。
– 实体 （ entity） 是需要保持记录的任何事物 。 例如, 根据
问题情景, 实体可以是客户, 销售或者是病人, 病床 。
– 实体之间的关系也需建立, 如, 病人使用病床,,, 医
生诊疗病人, 。
– 深入理解问题情景对于识别实体及其关系十分重要 。
? 上一阶段的工作即人类活动分析为建立实体模型打
下了良好的基础 。
? 实体模型 （ entity model） 是一张图 。 在实体模型
图中, 实体用方框表示, 实体之间的联系用线和箭
头表示 。
社
会—
技
术
分
析
与
设
计
社会 —技术方面的分析与设计
? 信息系统的建设者一方面要考虑人及其需要,
考虑具体的工作环境, 另一方面要考虑组织
结构, 考虑计算机系统及其必要的工作任务 。
? 这个阶段的工作主要是,
– 选择社会配置满足社会方面的目标,
– 选择技术配置满足技术目标 。
– 综合这两方面产生社会 —技术选择 。
– 这些选择先按满足上述要求排列, 再按成本, 资
源, 约束排列 。
– 用这种办法找出, 最好的, 社会 —技术解决方案,
并确定对应的计算机任务, 角色集 （ role-sets）
和人承担的任务 。
人机界面设计
? 前面几个阶段关心的是系统, 做什么,, 这
个阶段和下一阶段考虑如何达到提出的要求 。
? 第二阶段导出的实体模型以及第三阶段导出
的计算机任务, 角色集和人员任务是本阶段
的输入 。
? 这个阶段关心的是人 —机界面的技术设计 。
? 人 —机界面确定下来之后, 需要达到的技术
要求也应设计 。 这些要求是下一阶段的输入 。
技术方面的设计
? 这一阶段的输入是第二阶段得到的实体模型
和第四阶段的技术要求 。
– 前者描述相关领域的实体及实体间的关系,
– 后者描述了系统的详细技术要求 。
? 系统分析员在这一阶段的任务, 就是应用各
种技术手段进行有效的设计, 写出完整的系
统设计说明书 。
需
求
的
技
术
说
明
中国人民大学：左美云
zuomy@ruc.edu.cn
第六章
一、结构化方法
结构化方法遵循的基本原则
? 面向用户的观点；
? 严格区分工作阶段, 每个阶段有明确的任务
和应得到的成果；
? 按照系统的观点, 自顶向下地完成系统的研
制工作；
? 充分考虑变化的情况；
? 工作成果文献化, 标准化 。
结构化方法的不足和局限性
? 开发周期长 。
? 早期的结构化方法注重系统功能, 兼顾数据
结构方面不够 。
? 结构化程序较低的系统, 在开发初期难于锁
定功能要求 。
二、数据流图
系统分析
? 系统分析要回答新系统, 做什么, 这个关键
性的问题 。
? 系统分析是研制信息系统最重要的阶段, 也
是最困难的阶段 。 系统分析的困难主要来自
三个方面,
– 问题空间的理解
– 人与人之间的通讯
– 环境的不断变化
? 数据流图是结构化系统分析的主要工具 。 结
构化系统分析采用介于形式语言和自然语言
之间的描述方式, 通过一套分层次的数据流
图, 辅以数据字典, 小说明等工具描述系统 。
数据流（程）图
数据流程图
? 数据流图描述数据流动, 存储, 处理的逻辑
关系, 也称为逻辑数据流图 （ Logical Data
Flow Diagram）, 一般简称为 DFD。
? 数据流图用到四个基本符号, 即,
– 外部实体
– 数据流
– 数据存储
– 数据处理过程
外部实体
? 外部实体指系统以外又与系统有联系的人或
事物 。 它表达该系统数据的外部来源或去处,
例如顾客, 职工, 供货单位等等 。 外部实体
也可以是另外一个信息系统 。
数据处理
? 处理指对数据的逻辑处理功能, 也就是对数据的变换功能 。
? 在数据流图中, 用带圆角的长方形表示处理,
长方形分为三个部分：标识部分；功能描述
部分；功能执行部分 。
数据流
? 数据流是指处理功能的输入或输出, 用一个
水平箭头或垂直箭头表示 。 箭头指出数据的
流动方向 。
? 数据流可以是信件, 票据, 也可以是电话,
等等 。
数据存储
? 数据存储表示数据保存的地方 。 这里, 地方,
并不是指保存数据的物理地点或物理介质,
而是指数据存储的逻辑描述 。
? 在数据流图中, 数据存储用右边开口的长方
条表示 。 在长方条内写上数据存储的名字 。
? 为了区别和引用方便, 再加一个标识, 用字
母Ｄ和数字组成 。
数据流（程）图的其他表示法
三、数据流图案例
学籍管理系统顶层 DFD
学籍管理系统 的第一层 DFD
“成绩管理”框的展开 第 2层
“分析期末成绩”框的展开 第 3层
“确定异动情况”框的展开 第 4层
关于数据流图层次的划分
? 展开的层次与管理层次一致, 也可以划分得
更细 。 处理块的分解要自然, 注意功能的完
整性 。
? 一个处理框经过展开, 一般以分解为 4～ 10个
处理框为宜 。
? 最下层的处理过程用几句话, 或者用几张判
定表, 或一张简单的 HIPO图能表达清楚 。 其
工作量一个人能承担, 若是计算机处理, 一
般不超过 100条程序语句 。
检查数据流图的正确性
? 数据守恒, 或称为输入数据与输出数据匹配
? 在一套数据流图中的任何一个数据存储, 必定有流
入的数据流和流出的数据流, 即写文件和读文件,
缺少任何一种都意味着遗漏某些加工 。
? 父图中某一处理框的输入, 输出数据流必须出现在
相应的子图中, 否则就会出现父图与子图的不平衡 。
? 任何一个数据流至少有一端是处理框 。 换言之, 数
据流不能从外部实体直接到数据存储, 不能从数据
存储到外部实体, 也不能在外部实体之间或数据存
储之间流动 。
提高数据流图的易理解性
? 简化处理间的联系 。
– 在数据流图中, 处理框间的数据流越少, 各个处
理就越独立, 所以我们应尽量减少处理框间输入
输出数据流的数目 。
? 均匀分解
? 适当的命名
四、数据字典
数据字典
? 系统分析中所使用的数据字典, 主要用来描
述数据流图中的数据流, 数据存储, 处理过
程和外部实体 。
? 数据字典把数据的最小组成单位看成是数据
元素 （ 基本数据项 ）, 若干个数据元素可以
组成一个数据结构 （ 组合数据项 ） 。
? 数据结构是一个递归概念 。
? 数据元素组成数据结构, 数据结构组成数据
流和数据存储 。
? 数据字典中有六类条目：数据元素, 数据结
构, 数据流, 数据存储, 外部实体, 处理 。
数据元素
? 数据元素是最小的数据组成单位, 也就是不
可再分的数据单位, 如学号, 姓名等 。
? 对每个数据元素, 需要描述以下属性,
– 名称
– 别名
– 类型 （ 字符型还是数字型等 ）
– 取值范围和取值的含义
– 长度
– 除以上内容外, 数据元素的条目还包括对该元素
的简要说明, 与它有关的数据结构等等 。
数据元素条目的一个例子
数据结构
? 数据结构的描述重点, 是数据之间的组合关
系, 即说明这个数据结构包括哪些成分 。
? 一个数据结构可以包括若干个数据元素或
（ 和 ） 数据结构 。 这些成分中有三种特殊情
况,
? 任选项：这是可以出现, 也可以省略的项,
用, 〔 〕,表示 。
? 必选项：在两个或多个数据项中, 必须出现
其中的一个称为必选项 。 必选项的表示办法,
是将侯选的多个数据项用, { }”括起来 。
? 重复项 。 即可以多次出现的数据项 。
数据结构条目的一个例子
数据流
? 关于数据流, 在数据字典中描述以下属性,
– 数据流的来源；
– 数据流的去处；
– 数据流的组成 （ 一个数据流可包含一个或多个数
据结构 ） ；
– 数据流的流通量；
– 高峰时的流通量 。
数据流条目的一个例子
数据存储
? 数据存储的条目, 主要描写该数据存储的结构, 及
有关的数据流, 查询要求 。
? 有些数据存储的结构可能很复杂, 如, 学籍表,,
包括学生的基本情况, 学生动态, 奖惩记录, 学习
成绩, 毕业论文成绩等, 其中每一项又是数据结构 。
? 这些数据结构有各自的条目分别加以说明, 因此在
,学籍表, 的条目中只需列出这些数据结构, 而不
要列出这些数据结构的内部构成 。
? 数据流图是分层的, 下层图是上层图的具体化 。 同
一个数据存储可能在不同层次的图中出现 。 描述这
样的数据存储, 应列出最低层图中的数据流 。
数据存储条目的一个例子
处理框条目的一个例子
外部实体条目的一个例子
五、系统设计
系统分析与系统设计
? 系统设计包括总体 （ 概要 ） 设计和详细设计两大部
分 。
? 系统分析阶段要回答的中心问题是系统, 做什么,,
即明确系统功能 。 这个阶段的成果是系统的逻辑模
型 。
? 系统设计要回答的中心问题是系统, 怎么做,, 即
如何实现系统分析说明书规定的系统功能 。 这一阶
段, 要根据实际的技术条件, 经济条件和社会条件,
确定系统的实施方案, 即系统的物理模型 。
? 系统设计的目标是从保证系统的变更性入手, 设计
出一个易于理解, 容易维护的系统 。
系统设计应注意的问题
? 把系统划分为这样一些部分, 其中每一部分的功能
简单明确, 内容简明易懂, 易于修改 。 我们把这样
的部分称为模块 。
? 系统分成模块的工作按层次进行 。
? 每一个模块应尽可能独立 。 即尽可能减少模块间的
调用关系和数据交换关系 。 当然, 系统中的模块不
可能与其它模块没有联系, 只是要求这种联系尽可
能少 。
? 模块间的关系要阐明 。 这样, 在修改时可以追踪和
控制 。
总体设计的任务
? 将系统划分成模块；
? 决定每个模块的功能；
? 决定模块的调用关系；
? 决定模块的界面, 即模块间信息的传递 。
? 总体设计：从数据流图导出结构图
变换分析和事务分析
? 变换分析
– 找出主加工, 逻辑输入和逻辑输出
– 设计顶层模块和第一层模块
– 设计中, 下层模块
? 事务分析
? 数据流图层次的转换
变换分析
事务分析 1
事务分析 2
数据流图的层次与模块结构
六、详细设计
详细设计的任务
? 代码设计；
? 数据库设计；
? 输入设计；
? 输出设计；
? 人机对话设计；
? 处理过程设计 。
代码设计的原则
? 唯一性
? 合理性
? 可扩充性
? 简单性
? 适用性
? 规范性 （ 国家有关编码标准 ）
? 系统性
? 编写代码表
输入输出设计的原则
? 输出设计包括以下几方面的内容,
– 确定输出内容
– 选择输出设备与介质
– 确定输出格式
? 输入设计应遵循以下原则,
– 最小量原则 。
– 简单性原则 。
– 早检验原则 。
– 少转换原则 。
? 输入设计的内容包栝,
– 确定输入数据内容
– 确定数据的输入方式
– 确定输入数据的记录格式
– 输入数据的正确性校验
– 确定输入设备 。
人机对话设计
? 对话要清楚, 简单, 用词要符合用户观点和
习惯 。
? 对话要适应不同操作水平的用户, 便于维护
和修改 。
? 错误信息提示的设计要有建设性 。
? 关键操作要强调和警告 。
人机对话和处理过程设计
? 人机对话设计
– 对话要清楚, 简单, 用词要符合用户观点和习惯
– 对话要适应不同操作水平的用户, 便于维护和修改
– 错误信息提示的设计要有建设性 。
– 关键操作要强调和警告 。
? 处理过程的设计
– 处理过程设计的关键是用一种合适的表达方法来描
述每个模块的执行过程 。
– 日常用的描述方式有流程图, 盒图 （ NS图 ）,
PAD图 。
流程图
NS图
PAD图
七、系统实施
? 硬件准备
? 软件准备
? 人员培训
? 数据准备
系统实施阶段的任务
第七章
一、原型法
原型法的思想
?在投入大量的人力, 物力之前,
在限定的时间内, 用最经济的方
法构造一个系统原型, 使用户尽
早看到未来系统的概貌, 在系统
原型的实际运行中与用户一起发
现问题, 提出修改意见, 不断完
善原型, 使它逐步满足用户的要
求 。
原型法的步骤
? 明确用户基本信息需求
? 建立初始原型：构成初始原型时要注意两个
原则,
– ① 集成原则 。 尽可能用现成软件和模型来构成,
这需要相应的工具；
– ② 最小系统原则 。 耗资一般不超过总投资的 10％,
但能反映系统的基本特性, 并能扩充和完善 。
? 评价原型
? 修改和完善原型
原
型
法
的
步
骤
原型法的优点
? 增进用户与开发人员之间的沟通
? 用户在系统开发过程中起主导作用
? 辨认动态的用户需求
? 启迪衍生式的用户需求
? 缩短开发周期, 降低开发风险
二、面向对象方法
（一）,OO基本概念
对象
? 对象是一些属性及专用服务的封装体, 它是问题空
间中一些东西的抽象 。
? 由以上定义可知, 对象就是我们在问题空间中要考
虑的那些人或事物 。 它具有一组属性和一组操作 。
这些属性的值刻画了一个对象的状态, 而这些操作
是对象的行为, 通过它们改变对象的状态 （ 即属性
值 ） 。
? 数据和操作封装于对象的统一体中, 而不是分开 。
这样, 对象就具有较强的独立性和自治性, 具有很
好的模块性, 为软件重用奠定了坚实的基础 。
? 与对象相关的一个概念是对象类 （ Object Class） 。
对象类简称类, 是有相似属性和行为的多个对象的
集合 。 例如, 对象, 客车,,, 货车,,, 拖车,
等, 它们属一个共同的类, 车辆, 。
封装和继承
? 封装即信息隐藏 。 对象是一个很好的封装体 。 它向
外提供的界面包括一组数据结构 （ 属性 ） 和一组操
作 （ 服务 ）, 而把内部的实现细节 （ 如函数体 ） 隐
蔽起来 。
? 继承指对象继承它所在类的结构, 操作和约束, 也
指一个类 （ 子类 ） 继承另一个类 （ 父类 ） 的结构,
操作和约束 。 继承体现了一种共享机制 。
? 继承一个单一的父类时叫单继承, 如果有两个以上
的父类则是多继承 。 前者继承关系是单一的, 体系
结构表现为树；后者继承关系复杂, 呈网状结构 。
? 继承的作用在于信息组织和分类, 简化对象及类的
创建工作量 。 利用继承性, 只要在原有类的基础上
增加, 删除或修改少量数据和方法就可以得到子类
消息
? 一条消息告诉一个对象做什么, 它指出：发送者, 接
收者, 需要执行的服务, 需要的参数 。
? 例如, 对象汽车具有, 行驶, 这项操作, 为了让汽车
以时速 50公里的时速行驶, 需要向汽车对象传送, 行
驶, 和, 时速 50公里, 的消息, 来触发这个对象 。
? 值得注意的是,, 消息传递, 与传统的, 过程调用,
的区别 。
? 发送消息只是触发对象 。 接受对象收到消息后, 按消
息及消息调用自己的操作来改变状态或返回结果 。 因
此, 同样的输入参数可能因对象的初始状态不同而得
到不同的终态, 或输出不同的结果 。 而过程调用则只
要输入相同的参数, 输出总是一样的 。
（二）,OO方法的特点
OO遵循的法则及其特性
? 三个构造法则,
– 区分对象及其属性, 例如, 区分一棵树和树的大
小；
– 区分整体对象及其组成部分, 例如, 区分一棵树
和树枝；
– 不同对象类的形成及区分, 例如, 所有树的类和
所有车辆的类 。
? OO的优良特性
– 抽象性, 封装性, 继承性, 多态性
多态性
? 多态性又叫多形性, 指相同的操作 （ 或函数,
或过程 ） 可作用于多种类型的对象并获得不
同的结果 。
? 在面向对象方法中, 可给不同类型的对象发
送相同的消息, 不同的对象分别作出不同的
处理 。
? 例如, 给整数对象和复数对象定义不同的数
据结构和加法运算, 但可以给它们发送相同
的消息, 做加法运算,, 整数对象接收此消
息后做整数加法, 复数对象则做复数加法,
产生不同的结果 。 多态性增强了软件的灵活
性, 重用性, 可理解性 。
（三）面向对象分析
面向对象分析的特点
? 面向对象的分析 （ OOA） 要求把问题空间分
解成一些类或对象, 找出这些对象的特点
（ 即属性和服务 ）, 以及对象间的关系 （ 一
般 /特殊, 整体 /部分关系 ）, 并由此产生一个
规格说明 。
? OOA有助于改善：问题空间的理解, 人与人
之间的通讯和需求的不断变化 。
? OOA由五个主要步骤构成：标识对象, 标识
结构, 定义主题, 定义属性 （ 及实例连接 ）,
定义服务 （ 及消息连接 ） 。
标识对象
? 寻找对象：寻找对象应从问题空间, 文字资
料和图片资料入手, 寻找结构, 其他系统,
设备, 要记住的事件, 人扮演的角色, 地点
和组织单元等, 以便发现可能的对象 。
? 挑剔对象 。 对那些不必记住的事物与服务,
单个属性或派生结果 （ 如, 年龄, 是, 出生
日期, 的派生结果 ）, 就要考虑它们可能并
不是对象 。
? 命名对象 。 用单个名词或形容词加名词作对
象名, 尽量选择反映主题的标准词汇作对象
名 。
车辆登记和发照（发驾驶执照）系统
? 车主购车后持相关证件到主管部门登记注册, 缴纳
费用, 获得牌照 。 注册后, 登录车况信息和车主信
息 。 系统维护下列信息,
– 组织机构 （ 名称, 经理, 地址, 电话等 ）
– 职员 （ 用户名, 审查, 开始日期, 结束日期等 ） ；
– 车主 （ 合法名, 地址, 电话等 ） ；
– 发照 （ 号码, 所有权证件, 费用等 ） ；
– 注册 （ 日期, 品牌, 费用等 ） ；
– 车辆 （ 号码, 年份, 制造厂, 厢体颜色, 自重, 载客量,
燃料, 价格等 ） ；
– 另外还有,
? 对货车：现时自重
? 对摩托车,× 自重
? 对拖车,× 燃料, × 载客量
? 对旅游拖车：厢体号, 长度 。
登记和发照系统中的对象
标识结构
? 分类结构
– 分类结构有助于刻画出问题空间的类成员层次 。
它通过搜集公共特性, 并把这种特性扩充到特例
之中, 显示现实世界事件的通用性及专用性 。
– 继承的概念是分类结构的一个重要组成部分 。
– 定义分类结构时, 要分析通用类是否表达了专用
类的共性, 专用类是否表示了个性 。 子类把不需
继承的服务和属性标记为, X”。
? 组装结构
– 组装结构刻画了一个整体及其组成部分 。 例如,
一辆汽车由发动机, 传动装置和刹车装置组成 。
登
记
和
发
照
系
统
中
的
结
构
标识主题
? 首先, 对每个对象和每个结构增加一个相应主题,
如果主题的个数超过 7个左右, 则进一步提炼主题,
一旦对象和结构之间的连接得到标识, 根据需要,
把紧耦合的主题合在一起提供一个更好的模型概观
供读者理解 。
? 然后, 列出主题及主题层上各主题之间的消息连接 。
? 最后, 对主题进行编号, 在层次图上列出主题以指
导读者从一个主题到另一个主题 。 每一层都可以组
织成按主题划分的图 。
登记和发照系统中的主题
标识属性
? 标识属性 。
? 属性定位 。
– 通用属性应放在结构的高层, 特殊属性放在低层
– 如果一个属性适用于大多数的特殊分类, 可将其放在通
用的地方, 然后在不需要的地方把它覆盖 （ 即用, ×,等
记号指出不需要继承该属性 ）
– 如果发现某个属性的值有时有意义, 有时却不适用, 则
应考虑分类结构 。
– 根据发现的属性, 还可修订对象 。
? 标识实例连接 。
– 多重性：一对一 （ 1:1） 的, 一对多 （ 1:M）, 多对多
（ M,M）
– 参与性：表示实例连接是强制的还是任意的？
描
述
实
例
之
间
关
系
的
符
号
登
记
和
发
照
系
统
中
的
属
性
标识服务
? 服务可定义为：收到一条消息之后所执行的
处理 。
? 服务定义了对象及类所需的行为 。 行为分为,
– 有直接动因的行为；
– 进化史上的相似行为；
– 功能相似的行为 。
? 标识服务 （ 即对象的行为 ） 的策略分别对应
于上述三类行为,
– 直接动因对应：状态 —事件 —响应 （ 辅助策略 ） ；
– 进化史对应：对象生命历程 （ 辅助策略 ） ；
– 功能对应：最基本的服务 （ 基本策略 ） 。
标识服务的基本策略
? Occur（ 实例的增加, 修改, 删除和选择 ）
? Calculate（ 计算 ） ；
? Monitor（ 监控 ） 。
? 这三种基本服务提供了标识服务的基本策略, 所有
的 OOA模型都使用, Occur”服务；
? 当一个实例需要另一个实例中说明的处理结果时,
使用它的, Calculate”服务；
? 而有关实时处理的那一部分将使用, Monitor”服务,
,Monitor”服务执行对外界系统, 设备或用户的运
行监控 。
对象生命历程的辅助策略
? 定义基本的对象生命历程序列：增加, 修改,
选择和删除；
? 检查每一步的演变：扩展每一步, 反映出增
加, 修改, 删除的演变；
? 增加基本序列：对象或分类结构响应其他事
件吗？
? 增加服务：根据扩展的每一步增加服务, 一
般所增加的服务是对象的基本服务的演变 。
状态 —事件 —响应的辅助策略
? 定义系统的主要状态；
? 对每一个状态, 列出外部事件和所需的响应；
? 根据事件和响应增加服务 （ 和消息连接 ） 。
? 辅助策略有助于发现可能遗漏的, Calculate”
和, Monitor”服务 。
建立消息连接
? 首先在已经存在实例连接的对象和分类结构
之间增加消息连接,
? 然后检查对象和分类结构, 包括封装在其中
的属性, 寻找一个实例所需要的另一个实例
的服务, 从中找到消息,
? 再次在发送者的服务说明中建立消息连接的
文档, 在接收者的服务说明中建立相应的执
行服务的文档 。
? 最后详细说明服务 。
登
记
和
发
照
系
统
中
的
服
务
（四）面向对象设计
OOD的内容
? 问题空间部分的设计 （ PDC）
? 人机交互部分的设计 （ HIC）
? 任务管理部分的设计 （ TMC）
? 数据管理部分的设计 （ DMC）
问题空间部分的设计（ PDC）
? PDC的设计策略包括三部分：运用 OOA的结果；改
进 OOA的结果；增补 OOA的结果 。
? 对 OOA结果的增补原因和准则包括,
– 重用设计和编程的类：为了重用而引进现成的类 。
– 把问题空间专用类组合在一起：附加一个根类把所有类
组织起来 。
– 通过增添一般类而建立协议：引进一个附加类, 作为有
相似服务及相应属性的一般类 。
– 改进性能：为改进速度, 可能合并一些高度耦合的类,
还可能在类及对象中扩充一些保存临时结果的属性或一
些低层控制块；
– 提供数据管理部分：增加属性和服务使对象能够被保存；
– 增加低层成分：增加类来反映一些低层的逻辑细节；
– 调节继承的支持级别：如果 OOA的结果包括多继承, 而
编程语言只支持单继承甚至无继承时, 就要作相应调整 。
多继承展平为单继承
人机交互部分的设计（ HIC）
? 对人分类 。 把人按技能层次, 组织层次, 不同身份进行分类,
增加与系统交互的人的子集 。
? 描术人及其任务脚本 。 对每一类人, 描述其身份, 目的, 特
征, 关键的成果因素 （ 必须 / 想要 …, 喜欢 / 不喜欢 / 有偏
见 … ） 熟练程度及任务剧本 。
? 设计命令层 。 命令层可能以菜单屏面或菜单条或一系列图符
呈现给人们, 要按使用频度及用户工作步骤排列服务名 。 宽
度一般为 7± 2。
? 设计详细的交互 。 考虑的准则有：一致性；操作步骤少；不
要, 哑播放,, Undo；趣味与吸引力 。
? 继续做原型 。 做几个可候选的原型, 让人们一个一个地试用,
要达到, 臻于完善,, 由衷地满意 。
? 设计 HIC类 。 设计 HIC类, 从组织窗口和部件的人机交互设
计开始, 窗口作基本类, 部件作属性或部分类, 特殊窗口作
特殊类 。 每个类包括窗口的菜单条, 下拉菜单, 弹出菜单的
定义, 每个类还定义了用来创造菜单, 加亮选择等所需的服
务 。
任务管理部分的设计（ TMC）
? 识别事件驱动任务 。 事件驱动任务是指睡眠任务
（ 不占用 CPU）, 当某个事件发生时, 任务被此事
件触发, 任务醒来作相应处理, 然后又回到睡眠状
态 。
? 识别时钟驱动任务 。 按特定的时间间隔去触发任务
进行处理, 如某些设备需要周期性的数据采集和控
制 。
? 识别优先任务和关键任务 。 把它们分离开来进行细
致的设计和编码, 保证时间约束或安全性 。
? 识别协调者 。 增加一个任务来协调诸任务, 这个任
务可以封装任务之间的协作 。
? 审查每个任务, 使任务数尽可能少 。
? 定义每个任务：包括任务名, 驱动方式, 触发该任
务的事件, 时间间隔, 如何通讯等 。
OOD的评价
? 对每一种不同的方案有不同的设计, 一个好的设计
就是经过权衡选择使整个生命周期内系统总开销最
少的那个设计 。
? OOD的评判标准包括：耦合, 内聚, 重用及其他 。
– OOD的其他评判标准包括结构的深度, 设计的简单性和
清晰度, 公认的优雅风格等 。
? 耦合分交互耦合和继承耦合 。
– 交互耦合指两个对象间传递消息以实现交互 。 这种耦合
越小越好, 因为信息传输量越小, 对象的独立性和模块
性就越强, 当一个部分改动时, 对另一部分的影响就越
小 。 如果几个对象的耦合度实在太大, 可以考虑合并成
一个对象 。
– 继承耦合表示子类与父类的联系程度, 这种耦合度越大
越好, 因为应尽可能利用现有的一般类 。
第八章
（一）、硬系统思想
“硬, 系统方法的实质
? 存在一个目标状态 S1 和一个当前状态 S0,
并且有各种方式从 S0到达 S1。
（二）、软系统特点
软系统方法论面对的问题
? 有结构的问题是, 硬, 系统思想和大部分运筹学所
关心的问题 。
? 无结构的问题, 是目标阐明本身就是问题的那类问
题 。
? 认识问题, 定义问题, 求解问题, 问题得解 。 这对
于描述许多有结构问题的处理是足够的, 但其中有
两个方面不适于处理无结构的问题 。
– 首先, 这样的问题虽然是, 可认识的,, 但不是, 可定
义的, 。
– 第二, 对于人类活动系统中的问题, 历史常常改变了议
事日程 。
? 与人类活动系统在现实世界中的表现有关的问题是
一种感到不满意的状况 。 这种状况是不能精确定义
的 。 它介于就要成为现实和可能成为现实这两种感
觉中间 。
（三）、软系统案例
软系统案例 ——问题
? 生产计划和生产安排确实混乱；
? 质量控制实际上根本不存在；
? 按生产科长的看法, 一个产品性能及其最终用途的市场说明将使大部分问题得到解决；
? 各地区的销售代理人与生产总部之间没有良好的关系；
? 各分销店的代理人实际上只关心自己的事情；
? 没有有效的, 最为基本的关于生产和销售成本的金融信息；
? 而新任命的财务科长却想使大家确信他已改组了所有的帐目系统；
? 客户的抱怨声频繁不断；
? 在整个公司这一层次上缺乏计划, 并且管理科长根本没有把计划作为一个不断进行的过程的概念；
? 各个层次的管理信息流非常稀少而且是随意的；
? 整个公司的士气低落等等 。
软系统案例 ——困难？
? 对这些觉察到的问题中的任何一个的处理都有希望
获得某些改进, 但如此多的潜在问题使得他们无从
选择 。
? 如果这些问题连接成一个整体将使公司破产, 那么
对其中任何一个问题的解决又有什么用呢？
? 另一方面, 如果问题的聚集促使他们把公司考虑为
一个整体, 即作为一个研究重心所在的, 系统,,
那么系统分析 （ 即, 硬, 的, 目标导向的方法论 ）
这一智慧武器看来是无效的了 。
– 它需要首先定义系统的目标, 作为构造模型和在各候选
方法中选择的先决条件 。 但这在操作上是无用的, 因生
存这个明显的目标并不能使切克兰德他们采取下一步行
动 。
软系统案例 ——抽象？
? 切克兰德与研究小组面对困境没有放弃, 经过六周
的研究他们有了研究结果,
? 首先, 选择一种观点, 该观点以一种看起来与无数
问题有关的特定方式把公司看作一个整体, 然后根
据这种观点从逻辑上推出系统的结果 。
? 这意味着不是简单地把所要研究的, 系统, 看作为
一个单一的可描述实体的, 公司,, 或者说是一个
与问题无关的概念, 而是看作为一个与问题的核心
相关的公司 。
? 即这个作为研究对象的系统被认为是一个概念系统：
它促成并接受顾客对某一范围产品的订货, 以其专
长尽快地和有效地满足这些订货, 从而保证订货的
不断增长 。
软系统案例 ——解决？
? 这包含了这样一个观点：由于公司处于破产的边缘,
最重要的是在几个月内对作为公司运转基础的人类
活动系统作出某些改进 。
? 当然, 该公司是一个, 加工订货, 的系统, 对公司
的生产计划和安排系统, 公司计划系统和销售系统
都必须给予关注 。
? 前六周的研究所做的只是建立一个, 加工订货, 系
统的概念模型, 这是为了能看到系统的可改进之处 。
? 对公司的所有业务综合考察, 并把系统中的决策顺
序分离出来转换为一个系统模型, 决策顺序的逻辑
导致了一种系统结构, 它使得必需信息的目的, 来
源, 内容和接收都在一个确定的系统中流动 。
? 这种思想导致要设立两个部门, 一个部门面向顾客,
一个部门面向生产 。
? 接下来是使艾尔代尔纺织有限公司的实际活动逐渐
接近系统模型 。
软系统案例 ——启示？
? 上述研究以及切克兰德以前进行的其它研究
结果表明这样一个事实：问题求解者面对的
不是定义那些被认为是给定的系统目标, 而
是在众多的可能中选择何者是, 系统, 。
? 这种情景要求作出选择, 并为前后一致起见,
要清晰地陈述这种选择 。 这样看起来有用的
就是, 通过构造一个包含在这种选择中的人
类活动系统的概念模型来推算出选择的结果 。
? 在艾尔代尔的情形中是一个, 加工订货, 系
统 。 然后把系统模型与问题情景中实际观察
到的事物加以比较以提出并证明有用的变革
建议 。
（四）、软系统方法论
方
法
论
梗
概
软系统方法论 ——1
? 上图表示一个从 1到 7的时间序列, 这只是一种便于
描述的逻辑顺序 。 例如, 有可能从阶段 4开始一个
方案 。 原则上起点可以放在任何地方 。 有时返工和
重复也是必要的 。
? 方法论包含两种类型的活动 。
– 阶段 1,2,5,6,7是, 现实世界, 的活动, 必须包括问
题情景中的人 。
– 阶段 3,4,4a,4b是, 系统思想, 活动, 是否包括问题
情景中的人取决于具体的研究情景 。
? 一般说来, 前一类活动的语言可以是问题情景中的
任何规范的语言 。 因为在这一阶段, 现实世界的高
度复杂性通过翻译成更高层次的系统论的语言 （ 或
元语言 ） 而得到阐明和理解 。
软系统方法论 ——2
? 阶段 1和阶段 2是, 表达, 阶段, 即建立尽可
能多的问题情景 （ Problem Situation）, 在
问题情景中感到有问题 。
? 阶段 3包括命名一些看起来可能与假设的问题
相关的系统, 并简明地定义这些系统是什么 。
– 目的是得到一个对某些系统性质的简洁清楚的陈
述, 这些系统日后可能被看出与改善问题情景有
关 。 这当然不是固定的, 随着理解的加深, 该陈
述随时都可以进行反复的修改 。
– 阶段 3的这些定义被称之为, 根定义, （ Root
Definition）, 旨在表明囊括选出的系统的基本性
质 。
软系统方法论 ——3
? 给出这个定义之后, 阶段 4的任务是构造在根
定义中得到命名和定义的人类活动系统的概
念模型 （ Conceptual Model） 。 构造模型的
语言要求非常简单, 但却是细致的和有力的 。
? 构造模型的活动由 4a和 4b加以促进和补充,
? 4a是运用一般人类活动系统的模型来检查所
构造的模型是否有根本缺陷；
? 4b的任务则是修改模型, 如果有必要, 把模
型转变为其他更适于特定问题的形式 。
– 例如, 用系统动力学的语言重新表述可能更为恰
当, 或者把它重新表述为一个, 社会 —技术系
统, 。
软系统方法论 ——4
? 无论这种转变发生与否, 阶段 4所形成的模型
都要在阶段 5中, 进入现实世界,, 并与对现
实的知觉相比较 。 这种, 比较, 的目的是引
起一场与问题情景有关的人员的讨论 。
? 讨论的结果将在阶段 6确定可能的变革 。 这些
变革应同时满足两个标准：在所考查情景的
历史前提下, 它们应是合乎需要的和可行的 。
? 阶段 7的任务是把阶段 6的决定付诸行动以改
善问题情景 。
（五）、硬软方法论比较
硬软系统方法论比较 ——1
? 硬, 软两种方法论的主要差别是,
? 前者把问题和需求当作是, 给定的,, 因而
一开始提出的问题是：, 设计什么系统来解
决问题？, 或者, 什么系统将满足这个需
要？,
? 而后者却不得不允许后面的阶段出现完全不
可预料的回答 。
? 这样, 软方法论包含了比较阶段, 而在硬方
法中没有相应的阶段 。 在比较阶段, 系统思
想为关于变革的讨论提供了一个框架 。 而硬
方法此时忙于实施设计好的系统 。
硬软系统方法论比较 ——2
? 对于武器系统这样一个具体的对象, 如果采
用兰德式的系统分析, 其结果是产生一个具
体的武器系统, 但运用软系统方法论的分析,
则可能建议裁军, 让步, 或政治协商, 当然
也可能是具体的武器系统 。
? 撇开这种主要区别, 软方法论可以看作一般
情形, 而硬方法论是其中的一种特例 。 如果
讨论的问题有足够的良好定义, 则概念化就
成了系统设计,, 改善概念模型, 转化为
,优化定量模型,, 实施某些变革就成为实
施一个设计好的系统 。
（六）、多视点方法
分析员、问题情景、方法论
信息系统开发方法的适应性
? 戴维斯 （ Davis） 1982年提出信息系统开发方
法的应变性问题, 认为应该根据特定情景选
择相应的方法 。 他认为选择方法的关键是环
境不确定性程度 。 以下四个方面影响环境的
不确定性 。
– 系统的复杂性和不良结构 。
– 变迁的当前状态 。
– 受影响的用户数, 他们的技能 。
– 系统分析员的技能与经验 。
? 多视点方法是一种柔性框架, 它综合了多种
已经使用的方法, 提供多种开发技术与工具
供使用者根据具体问题情景选用 。
多视点方法的目标
? 多视点 （ Multiview)方法以软系统方法论为
指导, 综合了 20世纪 70年代以来几个重要方
面的研究成果, 把人类活动系统分析, 社
会 —技术系统观点, 数据分析与结构化分析
结合起来, 为信息系统开发创立了一个理论
框架 。 这种方法充分考虑所有系统使用者的
不同观点, 有助于回答下列五个问题,
– 拟建的信息系统如何促进组织目标的实现？
– 它能适应组织中使用者的工作过程吗？
– 有关人员能很好地操作计算机和使用它的输出吗
– 系统完成哪些信息处理功能？
– 系统的技术要求是什么？
谁的目标？
? 多数计算机专家, 程序员和技术系统分析员主要关
心第五个问题, 而多数系统的使用者对第四个问题
最感兴趣 。
– 在学院里, 多数计算机系的教学围绕着这两个方面 。 这
也许完全适合于这些方面的计算机专家 。 但是, 这两个
问题的正确回答, 还不足以保证信息系统的成功 。
? 第三个问题与人 —机界面有关 。
? 工会关心第二个问题 。
? 企业主管始终关心第一个问题, 不幸的是许多资深
的经理为之困惑 。
多视点方法的主要目标
? 信息系统常被视为有行为和社会结果的技术系统,
这种看法过于狭隘 。 把信息系统看作日益广泛地应
用信息技术的社会系统更为恰当 。 技术仅是它的一
个成分 。
? 更广泛透视信息系统, 需要识别到信息系统项目中
一系列利益相关者, 包括,
– 新系统的需求者和授权者,
– 负责信息系统相关部门的经理,
– 应用系统的工作人员,
– 建立和维护系统的计算机人员,
– 以及系统外的用户 （ 例如收到计算机输出的发票和表格
的顾客 ） 。
? 多视点方法的主要目标之一就是帮助他们互相沟通,
明确需求, 提出建议 。 由于他们看问题的角度不同,
要实现这一目标并不容易 。
多视点方法的实施 ——1
? 多视点方法的实施, 通常从顾问与总经理讨论项目
安排开始 。 他们要回答上述第一个问题,
– 组织投资信息技术希望实现什么目标？
– 是减少书面工作, 减少人员及其他成本, 还是获得更有
见识的决策？
? 这个阶段还要研究所定的目标是否可行, 拟建的信
息系统是不是实现目标的最好途径 。 答案也许是重
新考虑目标, 改善手工操作, 继续进行有关计算机
化的研究 。 也可能要求在计算化的同时, 或者在此
之前, 要改善现有的系统 。
? 在这之后, 分析员找出需要收集和处理的信息, 以
及需要完成的信息处理功能 。
多视点方法的实施 ——2
? 完成上述阶段的工作, 不需要数据库管理系统, 软
件包等等专门的计算机技术知识 。
? 通过这些工作, 分析员明白了系统的需求, 可与供
应商洽谈采购计算机系统的事宜, 从人文和技术角
度对系统提出要求, 适宜的定价和服务支持 。
? 若公司有自己的数据处理部门, 则技术分析员和程
序员可以根据需求说明书建设合适的系统 。 若购买
或建设这样一个系统有困难, 则需要对某些阶段再
次研究 。
? 具体情况不同, 多视点方法的实施可以有很大的差
别 。 目标是否清楚确定, 用户实际参与程度, 情况
复杂程度, 管理类型和观点, 这些因素都会影响项
目进程 。 从这一角度看, 多视点方法是开发信息系
统的一种探索方法 。
多视点方法的轮廓或阶段
? 一般来讲, 这种方法包括五个阶段, 每个阶
段都有相应看问题的观点和处理相应问题的
方法 。 这五个阶段是,
– 人类活动系统分析；
– 信息分析 （ 也称为信息模型化 ） ；
– 社会 —技术分析与设计；
– 人 —机界面设计；
– 技术方面设计 。
Multiview轮廓
多视觉方法的简明图
人
类
活
动
系
统
分
析
人类活动系统分析 ——1
? 这个阶段可以分成 4个子阶段, 10个步骤,
– 理解问题情景 （ 步骤 1—3）
– 构建系统模型 （ 步骤 4—7）
– 比较系统模型与现实 （ 步骤 8）
– 决策与执行 （ 步骤 9,10）
? 图中描绘富图 （ rich picture） 就是反复的过程 。 富
图显示处理过程的构造及相互之间的联系 。 图的要
素包括系统的客户, 参与的人员, 需完成的任务,环境, 系统的业主 。
? 问题的解 决者从富图抽取问题 主题 （ problem
themes）, 这是指图中可能引发问题因而值得更详
细研究的对象 。 如两个部门之间缺乏通讯, 供应不
足, 等等 。
? 得出主题之后, 问题解决者设想和命名相关系统（ relevant systems） 。 相关系统使问题主题更明白
清晰 。
人类活动系统分析 ——2
? 例如,
– 问题主题：两个部门冲突
– 相关系统：消除冲突系统或重新划分部门边界系统
? 本阶段最重要的讨论, 是比较几个不同的相关系统,
并从中选取最适用的一个 。 问题解决者与业主必须
决定用什么观点描述相关系统 。 例如消除冲突系统
– 可以描述为, 为使冲突最小而采用严格的行为和决策规
则的系统,,
– 也可以描述为, 行动者充分加强部门之间通讯和理解的
综合决策系统,,
– 甚至也可以描述成, 任何把不同意见汇集于中心体而使
部门之间的冲突减少到最小的系统, 。
人类活动系统分析 ——3
? 选定一种特定观点或根定义 （ root definition） 之后, 还要
进一步推敲 。 根定义可以从它必须包括的要素进行分析检
查, 例如,
– 系统的业主是谁？
– 是否包括了全部行动者？
– 系统的受益者, 受害者分别是谁？ 等等 。
? 若业主和问题解决者对得到的根定义都表示满意, 则可以
列出覆盖根定义所规定系统必不可少的活动的动词表, 构
建系统的概念模型 （ conceptual model） 。
? 根定义描述了系统, 是什么,, 而概念模型描述系统将要
,做什么, 。
? 用形式概念系统和其它系统思想对概念模型进行核查, 使
之更完善更适用 。
? 下一步是将完善的概念模型与富图表达的, 现实世界, 进
行比较, 找出二者的差别, 与业主讨论改善问题情景的措
施 。
信息分析 ——1
? 这一阶段也称为建立信息模型 （ information
modelling）, 目的是根据上一阶段得到的根
定义和概念模型, 分析系统的实体与功能 。
这个阶段不考虑最终如何开发系统 。
? 开发功能模型
– 首先识别系统的主功能,
– 然后将主功能逐层分解为子功能, 直到系统分析
员认为不必再分解为止 。 问题情景复杂程度不同,
分解层数也不同, 一般可分解四至五层 。
– 数据流图 （ data flow diagrams） 是进行功能分
解, 表达功能模型的工具 。
信息分析 ——2
? 开发实体模型
– 开发实体模型, 系统分析员需要从相应领域抽取和命名
实体 。
– 实体 （ entity） 是需要保持记录的任何事物 。 例如, 根据
问题情景, 实体可以是客户, 销售或者是病人, 病床 。
– 实体之间的关系也需建立, 如, 病人使用病床,,, 医
生诊疗病人, 。
– 深入理解问题情景对于识别实体及其关系十分重要 。
? 上一阶段的工作即人类活动分析为建立实体模型打
下了良好的基础 。
? 实体模型 （ entity model） 是一张图 。 在实体模型
图中, 实体用方框表示, 实体之间的联系用线和箭
头表示 。
社
会—
技
术
分
析
与
设
计
社会 —技术方面的分析与设计
? 信息系统的建设者一方面要考虑人及其需要,
考虑具体的工作环境, 另一方面要考虑组织
结构, 考虑计算机系统及其必要的工作任务 。
? 这个阶段的工作主要是,
– 选择社会配置满足社会方面的目标,
– 选择技术配置满足技术目标 。
– 综合这两方面产生社会 —技术选择 。
– 这些选择先按满足上述要求排列, 再按成本, 资
源, 约束排列 。
– 用这种办法找出, 最好的, 社会 —技术解决方案,
并确定对应的计算机任务, 角色集 （ role-sets）
和人承担的任务 。
人机界面设计
? 前面几个阶段关心的是系统, 做什么,, 这
个阶段和下一阶段考虑如何达到提出的要求 。
? 第二阶段导出的实体模型以及第三阶段导出
的计算机任务, 角色集和人员任务是本阶段
的输入 。
? 这个阶段关心的是人 —机界面的技术设计 。
? 人 —机界面确定下来之后, 需要达到的技术
要求也应设计 。 这些要求是下一阶段的输入 。
技术方面的设计
? 这一阶段的输入是第二阶段得到的实体模型
和第四阶段的技术要求 。
– 前者描述相关领域的实体及实体间的关系,
– 后者描述了系统的详细技术要求 。
? 系统分析员在这一阶段的任务, 就是应用各
种技术手段进行有效的设计, 写出完整的系
统设计说明书 。
需
求
的
技
术
说
明
