2009-7-20 1
课名,软 件 工 程主 讲,谢 明 志
Email,tommyshell@163.com
使用教材：软件系统开发技术（修订版）
潘锦平 施小英 姚天昉西安电子科技大学出版社
2009-7-20 2
第一章 软件工程概述
2009-7-20 3
§ 1.1 软件工程的背景和历史
1968年由 NATO (北大西洋公约组织 )在德国
Garmish召开的学术会议上,Feitz Bauer首先提出了,软件工程,概念。
2009-7-20 4
软件工程与编程
前者是一门学科，一种科学理论来指导软件系统开发，标准化，
自动化的过程
考虑如何分解一个系统，以便各人分工开发；考虑如何说明每个部分的规格要求；
怎样才能易于维护
单纯的代码编写
是软件工程发展的前身
是软件工程中占据很少时间和空间的一部分
2009-7-20 5
计算机学科的发展计算机科学
(CS)
计算机科学
(CS)
计算机工程
(CE)
软件工程
(SE)
信息系统
(IS)
计算学科
(computing discipline)
2009-7-20 6
60年代以来
工厂管理
病人监护
工资统发
图书馆管理
机票预定
学籍管理早期 第二阶段 第三阶段 第四阶段
面向批处理?多用户?分布式系统?强大的桌面系统
有限的分布?实时?嵌入,智能,?面向对象技术
自定义软件?数据库?低成本硬件?专家系 统
软件产品?消费者的影响?人工神经网络
并行计算
网络计算机
1950 1960 1970 1980 1990 2000
Evolution of software#
2009-7-20 8
为什么发展如此之快
不准确的时间和金钱的估算
软件质量的低下
相对硬件产品开发软件开发费用的增加
维护、增强软件系统的必要性
硬件价格大幅度下降
2009-7-20 9
软件技术面临的问题
规模
复杂性
生产率
Windows95有 1000万行代码
Windows2000有 5000万行代码例：
Exchange2000和 Windows2000开发人员结构
Exchange2000 Windows2000
项目经理 25人 约 250人开发人员 140人 约 1700人测试人员 350人 约 3200人
2009-7-20 11
,人月神话,焦油坑
史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、
猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
2009-7-20 12
软件危机的主要特征
软件开发周期大大超过规定日期 ;
软件开发成本严重超标 ;
软件质量难于保证。
2009-7-20 13
软件工程的定义
Fritz Bauer在 NATO会议上给出的定义：
,软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而确立和使用的健全的工程原理（方法）。,
2009-7-20 14
软件工程的定义（ 2）
IEEE【 IEE83】 给出的软件工程定义：
,软件工程是开发、运行、
维护和修复软件的系统方法。,
2009-7-20 15
软件工程的定义（ 3）
IEEE【 IEE93】 给出了一个更加综合的定义：
,将系统化的、规范的、可度量的方法应用于软件的开发、
运行和维护的过程，即将工程化应用于软件中。,
软件工程是一门交叉学科软件工程的主要研究内容
软件开发技术,软件开发方法学软件开发过程软件工具和软件工程环境
软件工程管理,软件管理学软件经济学软件心理学软件工程所包含的内容不是一成不变的，
随着人们对软件系统的研制开发和生产的理解。
应用发展的眼光看待它。
2009-7-20 17
软件工程 —一种层次化技术工具方法过程质量焦点
Software engineering layers
软件工程三个要素,方法、工具、过程
2009-7-20 18
软件工程与一般工程的差异
软件是逻辑产品而不是实物产品
软件的功能依赖于硬件和软件的运行环境以及人们对它的操作
软件设计的复杂性
软件特征,功能的多样性实现的多样性能见度低软件结构合理性差
智力密集及知识产权保护
2009-7-20 19
软件工程知识结构
2001年 5月 ISO/IEC JTC 1（ ISO和 IEC的第一联合技术委员会）发布了,SWEBOK指南 V0.95(试用版 )》
SWEBOK把软件工程学科的主体知识分为 10个知识领域。
2009-7-20 20
软件工程知识结构
软件需求
软件设计
软件构造
软件测试
软件维护
软件配置管理
软件工程管理
软件工程过程
软件工程工具和方法
软件质量
2009-7-20 21
,软件工程”课程与其它软件专业课的区别
(1) 立足于系统的整体。
(2) 讲授系统分析、系统设计、
测试及维护的理论和方法。
(3) 构筑一个软件系统，实践软件开发全过程。
2009-7-20 22
,软件工程”课程教学的目标
转变对软件的认识：
上升程序 系统
转变思维定式：
上升程序员 系统工程师
(系统分析员 )
2009-7-20 23
软件产品的标准化软件开发过程的标准化
2009-7-20 24
软件的工业化生产过程应具备的特点：
明确的工作步骤
详细具体的规范化文档
明确的质量评价标准
,一个好的工业，应有一套良好的标准来配套”
2009-7-20 25
软件工程技术的两个特点
强调规范化
强调文档化
2009-7-20 26
§ 1.2 软件和软件生命期模型
(Software Life Cycle)
软件产品或软件系统从设计、投入使用到被淘汰的全过程。
2009-7-20 27
软件生存期的阶段划分
(1)可行性研究与计划
(2)需求分析
(3)总体设计
(4)详细设计
(5)实现
(6)集成测试
(7)确认测试
(8)使用和维护成长期（开发期）
怀孕期（计划期 ）
成年期（运行期）
2009-7-20 28
新的国际标准定义的软件生存过程（ 1995
ISO/IEC 12207）
软件生存期过程支持过程 组织过程主要过程获取过程供应过程开发过程运行过程维护过程文档编制过程配置管理过程质量保证过程验证过程确认过程联合评审过程审核过程问题解决过程管理过程基础设施过程改进过程培训过程
2009-7-20 29
软件工作的范围只考虑编写程序涉及整个软件生存周期扩展到
2009-7-20 30
软件开发模型是软件开发全部过程、活动和任务的 结构框架 。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。 软件开发模型也常称为：
软件过程模型软件生存周期模型软件工程范型软件开发模型可行性研究与计划需求分析设计编码运行维护测试定义阶段开发阶段维护阶段瀑布模型 (Waterfall Model)
2009-7-20 32
开发软件不仅仅是编程开发维护设计编写模块测试联合测试分析
2009-7-20 33
按照传统瀑布模型开发软件的特点
1.阶段间具有顺序性和依赖性。
2.推迟实现的观点。
3.每个阶段必须完成规定的文档 ;
每个阶段结束前完成文档审查,
及早改正错误。
2009-7-20 34
原型模型 （快速原型模型 ）
原型范型用户测试运行原型建造 /修改原型听取用户意见采用原型模型的软件生存周期分析定义系统需求生成原型系统设计程序设计编码测试运 行和维护原型化含原型化的软件生存期
2009-7-20 36
§ 1.3 软件质量的评价
成功的标准,
用户在 用用户可很容易做完要做的事
失败的根本原因：
开发人员写出的东西达不到用户要求 (人的问题,技术问题 )
2009-7-20 37
质量与生产率
质量是软件需求方最关心的问题，用户即使不图物美价廉，也要求个货真价实
质量与生产率之间有着内在的联系，高生产率必须以质量合格为前提
质量与生产率的提高就指望程序员与程序经理
非得在质量与生产率之间分个主次不可，那么应该是质量第一，生产率第二
2009-7-20 38
质量与生产率（ 2）
质量直接体现在软件的每段程序中，高质量自然是开发人员的技术追求，也是职业道德的要求
高质量对所有的用户都有价值，而高生产率只对开发方有意义
如果一开始就追求高生产率，容易使人急功近利，留下隐患
2009-7-20 39
不贪污的官就是好官吗
,运行正确,的程序就是高质量的程序吗？
也许运行速度很低并且浪费内存；也许代码写得一塌糊涂
2009-7-20 40
软件的质量因素
软件的质量因素很多，如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等等（还可以列出十几个）
一般说来倾向于可维护性、可靠性、可理解性和效率
2009-7-20 41
软件质量因素分类和武学分类正确性与精确性易用性可理解性与简洁性性能与效率可复用性与可扩充性少林派、武当派华山派昆仑派峨嵋派崆峒派
2009-7-20 42
正确性与精确性
机器不会主动欺骗人，软件运行不正确或者不精确一般都是人造成的
需求分析错了，那么对客户而言这个软件也存在错误
如果软件没有 100% 地按需求规格执行，那么这个软件也存在错误
程序员要为,正确,,,精确,四个字竭尽全力
2009-7-20 43
性能与效率
用户都希望软件的运行速度高些（高性能），
并且占用资源少些（高效率）
旧社会地主就是这么对待长工的：干活要快点，
吃得要少点
通过优化算法、数据结构和代码组织来提高软件系统的性能与效率优化的关键
工作是找出限制性能与效率的,瓶颈,
2009-7-20 44
易用性
导致软件易用性差的根本原因是开发人员犯了
,错位,的毛病：他以为只要自己用起来方便，
用户也一定会满意
当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用,友好,来评价易用性
2009-7-20 45
可理解性与简洁性 （ Note 1）
开发人员只有在自己思路清晰时才可能写出让别人能理解的程序
编程时还要注意不可滥用技巧，应该用自然的方式编程
简洁是一种美
如果把学术文章写得很简洁，让人很容易理解，
它往往中不了
2009-7-20 46
可复用性与可扩充性
一种方式是原封不动地使用现成的软件构件
一种方式是对现成的软构件进行必要的扩充后再使用
可复用性好的程序一般也具有良好的可扩充性
2009-7-20 47
可行性研究与计划需求分析设计编码运行维护测试测试已经开始返回上级，再 …,.
瀑布模型的质量保障体系
2009-7-20 48
小结 （ Note 2）
软件的高质量主要是设计出来的
不是,管,出来的
更不能依赖质量检查。
2009-7-20 49
第二章可行性研究与计划
2009-7-20 50
系统流程图 （ Note 3）
输入单据磁盘文件处理输出单据
2009-7-20 51
数据流程图数据源点和终点变换数据的加工文件数据逻辑关系符号：与、或、异或
2009-7-20 52
§ 2.1可行性研究基本概念
可行性研究的任务,
可行性研究的主要任务是,了解客户的要求及现实环境，从技术、经济和社会因素等三方面研究并论证本软件项目的可行性，编写可行性研究报告，制定初步项目开发计划。,
2009-7-20 53
可行性研究的内容
(1)技术可行性
(2)经济可行性
(3)操作可行性
(4)社会可行性 (法律可行性 )
(5)抉择
2009-7-20 54
技术可行性 (Note 4)
度量一个特定技术信息系统解决方案的实用性及技术资源的可用性考虑的问题
开发风险分析
资源分析
相关技术的发展（现有技术能否实现新系统，技术难点、建议采用技术的先进性）
2009-7-20 55
经济可行性度量系统解决方案的性能价格比考虑的问题成本 /效益分析
有形成本、效益
无形成本、效益价值和成本的关系
质量与价值、成本的关系
价值 /成本的均衡
2009-7-20 56
经济可行性考虑的问题 (Note 5)
成本和效益的估算
开发成本的估算
开发效益的估算
运行成本的估算
运行效益的估算
2009-7-20 57
成本分析
代码行技术
（ page 19）
任务估算技术
（ page 20）
总成本、总人力相对误差在 内
Putnam估算模型
（ page 21 ）
COCOMO模型比较复杂
20%?
2009-7-20 58
效益分析
系统的经济效益＝使用新系统增加收入＋使用心系统可以节省的运行费用
总的效益和软件生存周期有关
货币的时间价值（ page23）
投资回收期（ page23）
投资回收率（ page23）
纯收入（ page23）
投资回收率
2009-7-20 59
系统开发和每年运行费用举例
1.系统开发费用（一次）
.2名系统分析员 (450小时 /名,45美元 /小时 ) $40,500
.5名系统开发人员 (275小时 /名,36美元 /小时 )$49,500
.1名数据库管理员 (30小时 /名,42美元 /小时 ) $1,260
.2名技术写作者 (120小时 /名,25美元 /小时 ) $6,000
.1名秘书 (160小时 /名,15美元 /小时 ) $2,400
2009-7-20 60
系统开发和每年运行费用举例
,1名数据通讯专家 (60小时 /名,42美元 /小时 )
$2,400
2名在转换期间数据输入人员
$49,500
(40小时 /名,12美元 /小时 )
2009-7-20 61
系统开发和每年运行费用举例培训：
三天的开发人员内部培训课程 $7,000
30个用户，三天的内部培训课程 $10,000
物资：
复印 $500
磁盘、纸张等消耗品 $650
2009-7-20 62
系统开发和每年运行费用举例购买硬件、软件：
20台工作站 Windows软件 $1,000
20台工作站内存升级 $8,000
网络软件 $17,500
20台工作站办公软件产品 $20,000
系统开发总费用 $161,670
2009-7-20 63
系统开发和每年运行费用举例
2.年运行费用（每年）
人员：
维护程序员 /分析员 (250小时 /年,42美元 /小时 )
$10,500
网络管理员 (300小时 /年,50美元 /小时 ) $15,000
购买硬件、软件升级：
硬件 $5,000
软件 $6,000
物资和杂项 $3,500
每年总运行费用 $40,000
2009-7-20 64
操作可行性
用户使用可能性
时间进度可行性
组织和文化上的可行性
2009-7-20 65
社会可行性 (法律可行性 )
开发项目是否会在社会上或政治上引起侵权、破坏或其它责任问题
2009-7-20 66
可行性研究计划的完成
可行性研究计划
2009-7-20 67
§ 2.3 可行性研究的步骤 （ page15）
(1)复查确认系统目标、规模
(2)研究正使用系统工作流程
(3)导出新系统高层逻辑模型
(4)重新定义问题
(5)导出和评价供选择的方案
(6)推荐可行的方案
(7)草拟开发计划
(8)编写可行性研究报告，送审
2009-7-20 68
第三章 需求分析和规格说明
2009-7-20 69
§ 3.1 为什么需要需求分析
开发人员往往急于求成
希望对开发进行指导
希望开发人员对用户的要求理解
希望用户理解开发人员
测试部门有理可依
2009-7-20 70
需求分析的任务准确地 定义 未来系统的目标，确定为了满足用户的需求系统必须做什么。用
<需求规格说明书 > 规范的形式准确地表达用户的 需求 。
2009-7-20 71
什么是用户需求
思考、涉及的几个问题
如何识别、获取需求?
你能够采取何种手段与用户进行交流沟通?
何为需求建模?
你如何理解模型与建模?
2009-7-20 72
软件需求分析的几个阶段
问题分析
问题评估和方案综合
建模
规约
复审系统分析员的主要 焦点 是,做什么
（ what）,,不是,怎样做（ how）,
2009-7-20 73
需求获取面临的挑战 (Note 6)
客户说不清楚需求
需求易变性
问题的复杂性和对问题空间理解的不完备性与不一致性
2009-7-20 74
§ 3.2 需求获取的常用方法 （ Note 7）
建立分析小组领域专家,主角系统分析员：导演
客户访谈
问题分析与确认某出版社系统调查表编号 提出问题
1 您在哪个部门工作？
2 出版业务流程是什么？
3 您每日都处理那些文件、数据、报表？
4 工作中手工处理特别麻烦的事情是什么？
5 工作中手工处理什么问题解决不了？影响效率的问题有哪些？
6 您认为提高工作效率，节省工作时间，减轻工作强度可采取哪些办法？
某出版社系统调查表编号 提出问题
7 您的部门需要成本核算和统计的内容有哪些？
8 您的部门采用计算机管理工作情况如何？
9 如何改进业务流程使之更合理？
10 哪些问题是目前传统手工方法根本无法解决的？
11 出版社计算机管理信息系统需要解决什么问题？
2009-7-20 77
听一个故事 （ Note 8）
主人公：
C o n t o s o制药公司的高级管理长官
Gerhard
C o n t o s o公司的信息系统开发小组的新管理员 Cynthia
内容：
客户的需求观
2009-7-20 78
谁是客户
客户是指直接或间接从产品中获得利益的个人或组织
软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者 ( s
t a k e h o l d e r )或是获得产品所产生的结果的人。
2009-7-20 79
客户与开发人员之间的合作关系
（ Note 10）
高质量的需求来源于客户与开发人员之间有效的交流与合作
通常，开发人员与客户或客户代理人成为一种对立关系
2009-7-20 80
软件客户需求权利书（ 1） （ Note 11）
客户有如下权利：
1,要求分析人员使用符合客户语言习惯的表达。
2,要求分析人员了解客户系统的业务及目标。
3,要求分析人员组织需求获取期间所介绍的信息，
并编写软件需求规格说明。
4,要求开发人员对需求过程中所产生的工作结果进行解释说明。
5,要求开发人员在整个交流过程中保持和维护一种合作的职业态度。
2009-7-20 81
软件客户需求权利书（ 2） (Note 12)
6,要求开发人员对产品的实现及需求都要提供建议，拿出主意。
7,描述产品使其具有易用、好用的特性。
8,可以调整需求，允许重用已有的软件组件。
9,当需要对需求进行变更时，对成本、影响、得失（ t r a d e - o ff）有个真实可信的评估。
10,获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。
2009-7-20 82
软件客户需求义务书 （ 1） (Note 13)
客户有下列义务：
1,给分析人员讲解业务及说明业务方面的术语等专业问题。
2,抽出时间清楚地说明需求并不断完善。
3,当说明系统需求时，力求准确详细。
4,需要时要及时对需求做出决策。
5,要尊重开发人员的成本估算和对需求的可行性分析。
2009-7-20 83
软件客户需求义务书（ 2） （ Note 14）
6,对单项需求、系统特性或使用实例划分优先级。
7,评审需求文档和原型。
8,一旦知道要对项目需求进行变更，要马上与开发人员联系。
9,在要求需求变更时，应遵照开发组织确定的工作过程来处理。
10,尊重需求工程中开发人员采用的流程（过程）。
2009-7-20 84
“签约,意味着什么 (Note 15)
客户与开发人员关系中的重要部分
客户代表经常把,签约,看作是毫无意义的
更为重要的是签名是建立在一个需求协议的基线上
与你的重要客户一起讨论权利书和义务书，以达成协议，并付诸实践
2009-7-20 85
高质量的需求过程带来的好处 (Note 16)
开发后期和整个维护阶段的重做的工作大大减少
强调需求质量并不能引起某些人的重视,他们错误地认为在需求上消耗多少时间就会导致产品开发推迟多少时间
将选定系统的需求明确地分配到各软件子系统，
强调采用产品工程的系统方法。这样能简化硬软件的集成
2009-7-20 86
优秀需求具有的特性 (Note 17)
1,完整性
2,正确性
3,可行性
4,必要性
5,划分优先级
6,无二义性
7,可验证性
2009-7-20 87
§ 3.3 需求获取的内容
1.用户需求分类
(1)功能性需求,
定义了系统做什么（描述系统必须支持的功能和过程）
(2)非功能性需求（技术需求）,
定义了系统工作时的特性
（描述操作环境和性能目标）
2009-7-20 88
两类需求包括的内容
(1) 功能
(2) 性能
(3) 环境
(4) 界面
(5) 用户或人 的因素
(6) 文档
(7) 数据
(8) 资源
(9) 安全保密
(10)软件成本消耗与开发进度
(11)质量保证
2009-7-20 89
(1) 功能需求
系统做什么？
系统何时做什么？
系统何时及如何修改或升级？
2009-7-20 90
(2) 性能需求软件开发的技术性指标例如：
存储容量限制
执行速度、相应时间
吞吐量
2009-7-20 91
(3) 环境需求
硬件设备,机型、外设、接口、
地点、分布、温度、
湿度、磁场干扰等
软件,操作系统网络数据库
2009-7-20 92
(4) 界面需求
有来自其它系统的输入吗？
到自其它系统的输出吗？
对数据格式有规定吗？
对数据存储介质有规定吗？
2009-7-20 93
(5) 用户或人的因素
用户类型？
各种用户熟练程度？
需受何种训练？
用户理解、使用系统的难度？
用户错误操作系统的可能性？
2009-7-20 94
(6) 文档需求
需哪些文档？
文档针对哪些读者？
2009-7-20 95
(7) 数据需求
输入、输出数据的格式？
接收、发送数据的频率？
数据的准确性和精度？
数据流量？
数据需保持的时间？
2009-7-20 96
(8) 资源需求
软件运行时所需的数据、软件。
内存空间等资源。
软件开发、维护所需的人力、
支撑软件、开发设备等。
2009-7-20 97
(9) 安全保密要求
需对访问系统或系统信息加以控制吗？
如何隔离用户之间的数据？
用户程序如何与其它程序和操作系统隔离？
系统备份要求？
2009-7-20 98
(10) 软件成本消耗与开发进度需求
开发有规定的时间表吗？
软硬件投资有无限制？
2009-7-20 99
(11) 质量保证
系统的可靠性要求？
系统必须监测和隔离错误吗？
规定系统平均出错时间？
出错后，重启系统允许的时间？
系统变化如何反映到设计中？
维护是否包括对系统的改进？
系统的可移植性？
2009-7-20 100
怎样写需求分析报告
作报告时要先从宏观上讲一、二、三、四、五，
再从细节上讲 A,B,C,D,E。需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题
如图
S = { D1,D2,D3,… Dn }
Di = { P1,P2,P3,… Pm }
Pj = { F1,F2,F3,… Fk }
2009-7-20 101
怎样写需求分析报告
2009-7-20 102
§ 3.4 需求的开发和管理整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适需求工程域的层次分解示意图
2009-7-20 103
需求开发 (Note 18)
问题获取（ e l i c i t a t i o n）
分析 ( a n a l y s i s )
编写规格说明（ s p e c i f i c a t i o n）
验证（ v e r i f i c a t i o n）
2009-7-20 104
知识技能 (Note 19)
绝大部分的软件开发人员都没有接受过高效需求工程所需技能的正规培训
培训需求分析人员所有的开发人员都应接受一个基本的需求工程培训
培训软件需求的用户代表和管理人员参与软件开发的用户代表应接受为期一天左右,关于需求工程的培训，开发管理者和客户管理者也应参加
让开发人员了解应用领域的基本概念组织一些简短的关于客户业务活动、术语、目
标等方面的讨论会以帮助开发人员对应用领域有个基本了解
2009-7-20 105
需求获取 (1)(Note 20)
确定需求开发过程
编写项目视图和范围文档项目视图
将用户群分类并归纳各自特点
选择每类用户的产品代表
建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求
2009-7-20 106
需求获取 (2)(Note 21)
让用户代表确定使用实例
召开应用程序开发联系会议
分析用户工作流程观察用户执行业务任务的过程
确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质量特点
通过检查当前系统的问题报告来进一步完善
可查看需求是否有足够的灵活性以允许重用一些已有的软件组件
2009-7-20 107
需求分析 （ Note 22）
绘制系统关联图。
建立数据字典。
为需求建立模型。
建立用户接口原型。
确定需求优先级。
2009-7-20 108
需求规格说明（ SRS） （ Note 23）
采用原始模板在你的组织中要为编写软件需求文档定义一种标准模板
指明需求的来源
为每项需求注上标号制定一种惯例来为每项需求提供一个独立的可识别的标号或记号
记录业务规范业务规范
创建需求跟踪能力矩阵
2009-7-20 109
需求验证 （ Note 24）
对需求文档进行正式审查
以需求为依据编写测试用例
编写用户手册在需求开发早期即可起草一份用户手册
确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的
2009-7-20 110
需求管理 (Note 25)
确定一个选择、分析和决策需求变更的过程
建立变更控制委员会
评估每项选择的需求变更
跟踪所有受需求变更影响的工作产品
建立需求基准版本和需求控制版本文档
维护需求变更的历史记录记录
跟踪每项需求的状态建立一个数据库
衡量需求稳定性记录基准需求的数量和变更数量
使用需求管理工具商业化的需求管理工具
2009-7-20 111
项目管理 （ Note 26）
选择一种合适的软件开发方法生存周期
项目开发计划的进度安排将会不断改变
发生需求变更时协商项目约定
编写文档和管理与需求相关的风险
跟踪需求工程所耗的工作量
2009-7-20 112
分析编写文档评审，商议基准需求说明需求变更过程管理客户需求市场当前基线 修正后基线市场，
客户，
管理项目环境需求开发与需求管理之间的界限
(Note 27)
2009-7-20 113
§ 3.5 改进需求过程 (Note 28)
软件开发过程的改进有以下两个主要目标：
解决在以前项目或目前项目中遇到的问题。
防止和避免你可能在将来的项目中要遇到的问题。
2009-7-20 114
四条改进软件的原则 (Note 29)
改进过程应该是革命性的、彻底的、连续的、
反复的
人们和组织机构都只有在他们获得激励时才愿意变更
过程变更是面向目标的
将改进活动看作一些小项目
2009-7-20 115
过程改进周期 (Note 30)
评价当前采用的方法指定活动改进计划创建、实验和实施新过程评价结果图：软件开发过程改进的周期发现和建议活动计划新的过程，
实验结果，
获得经验实施情况怎样活动计划的效果如何新过程是否达到预期目标？ 计划下一步的改进周期
2009-7-20 116
§ 3.6 软件需求与风险管理 （ Note 31）
听一个故事：
同样在 C o n t o s o制药公司
主人公
,化学制品跟踪系统”的项目管理人员 D a v e
首席程序员 H e l e n
首席测试员 R a m e s h
内容
需求工程的风险 为何物？
2009-7-20 117
软件风险管理的要素 （ Note 32）
风险管理 就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。风险管理提供了一种标准的方法来指出风险并把风险因素编成文档，评估其潜在的威胁，以及确定减少这些
风险评价（ risk assessment）
风险避免（ risk avoidance）
风险控制（ risk control）
2009-7-20 118
编写项目风险文档 (Note 33)
2009-7-20 119
与需求有关的风险
下面介绍的风险因素是按需求工程中获取、分析、编写规格说明、验证和管理汇总起来的，
并推荐了一些方法用于降低风险发生的可能性或减轻风险发生给项目带来的影响。
这张清单仅仅是一个起点，在你做项目逐渐积累经验过程中，加入你的风险因素清单和减轻风险的策略。使用这里提供的条目来帮助你识别需求风险并采用条件 —结果的格式来书写风险说明。
2009-7-20 120
需求获取 （ Note 34）
1) 产品视图与范围
2) 需求开发所需时间
3) 需求规格说明的完整性和正确性
4) 对革新产品的需求
5) 明确非功能需求
6) 客户赞同产品需求
7) 未加说明的需求
8) 把已有的产品作为需求基线
9) 给出期望的解决办法
2009-7-20 121
需求分析 （ Note 35）
1) 划分需求优先级
2) 带来技术困难的特性
3) 不熟悉的技术、方法、语言、工具或硬件平台
2009-7-20 122
需求规格说明 （ Note 36）
1) 需求理解
2) 时间压力对 T B D的影响
3) 具有二义性的术语
4) 需求说明中包括了设计
2009-7-20 123
需求验证 （ Note 37）
1) 未经验证的需求
2) 审查的有效性
2009-7-20 124
需求管理 (Note 38)
1) 变更需求
2) 需求变更过程
3) 未实现的需求
4) 扩充项目范围
2009-7-20 125
建立项目视图与范围 (Note 39)
一个项目可能包括一些与软件没有直接关系的需求，例如：硬件的购买、产品的安装、维护或广告。但在此，我们只关心与软件产品有关系的业务需求。
2009-7-20 126
通过业务需求确定项目视图 (Note 40)
项目视图可以把项目参与者定位到一个共同和明确的方向上
项目视图描述了产品所涉及的各个方面和在一个完美环境中最终所具有的功能
市场需求文档 & 视图和范围的文档
来自各个渠道的业务需求可能会发生冲突
2009-7-20 127
项目视图和范围文档的模板 (Note 41)
a,业务需求
a.1 背景
a.2 业务机遇
a.3 业务目标
a.4 客户或市场需求
a.5 提供给客户的价值
a.6 业务风险
b,项目视图的解决方案
b.1 项目视图陈述
b.2 主要特性
b.3 假设和依赖环境
c,范围和局限性
c.1 首次发行的范围
c.2 随后发行的范围
c.3 局限性和专用性
d,业务环境
d.1 客户概貌
d.2 项目优先级
e,产品成功的因素
2009-7-20 130
模型 (model)
模型,现实世界某些重要方面的表示 。
有时我们使用术语,抽象,来表示模型，
因为我们从现实世界中 抽象 出对我们特别有用的东西。
2009-7-20 131
抽象 (模型化 )
源于实验科学,主要要素为数据采集方法和假设的形式说明,模型的构造与预测实验分析结果分析,
在为可能的算法数据结构和系统结构等构造模型时使用此过程,
抽象的结果是概念符号模型
2009-7-20 132
§ 3.4 需求分析的步骤当前系统目标系统物理模型逻辑模型逻辑模型物理模型模型化 抽象化具体化 实例化怎么做做什么当前系统目标系统需求定义
2009-7-20 133
逻辑模型和物理模型
模型是对对象系统的形式化的特征抽象，概括性或近似地表示
构造模型的过程是一个抽象、分析的过程。
对象系统模型系统抽象 （映射）
模型应用模型构造的过程逻辑模型 物理模型
(本质模型、概念模型 ) (实施模型、技术模型 )
现行系统目标系统描述重要的业务功能，无论系统是如何实施的。
描述现实系统是如何在物理上实现的。
描述新系统的主要业务功能和用户新的需求，无论系统应如何实施。
描述新系统是如何实施的（包括技术）。
2009-7-20 135
分析阶段中常用的模型
（逻辑模型）
数据流图（ DFD）?
实体 ― 联系图
（ ERD ）?
类图?
实例图?
时序图?
状态图
协作图?
事件列表?
数据流定义?
数据元素定义?
……
2009-7-20 136
数据流图
(DFD,Data Flow Diagram)(Note 42)
描述逻辑模型的图形工具,表示数据在系统内的变化。
DFD可以用来表示一个系统或软件在任何层次上的抽象。 较大型软件系统 DFD分成多层
(子图、父图概念 ),可以表示数据流和功能的进一步的细节。
2009-7-20 137
数据流程图的表示 （ page 29-32）
数据源点和终点变换数据的加工文件数据逻辑关系符号：与、或、异或
2009-7-20 138
画数据流图 （ page 32－ 33）
规则：由外向里画
画系统的输出、输入
化系统的内部
画加工的内部
2009-7-20 139
应该注意的几个问题 （ page 33-34）
适当地命名
画数据流而不是控制流
先考虑稳定状态
忽略琐碎的枝节
随时准备重画
2009-7-20 140
分层数据流图
对于大型系统，往往使用一张数据流图画出所有数据流和加工是不可能的
自顶向下逐层分解
不要一下子引入过多细节，应该逐步增加细节
例子（ page 35）：
图 3.13（ a）画出了 …,.。图 3说明,产生新文件,…… 。显然 …… 。
2009-7-20 141
由顶向下画分层数据流图 （ page 37）
描绘中应该注意的问题：
编号
父图和子图的平衡
局部文件
分解的程度
2009-7-20 142
实例 ——运动会管理系统
自学 3.3.5节（ Page 40）
2009-7-20 143
数据流图的改进
检查数据流图的正确性
数据守恒 （ page 41-42）
文件的使用 （ page 42）
父图和子图的平衡 （ page 42-43）
提高数据流图的易理解性
简化加工间的联系 （ page 43）
分解的均匀 （ page 43）
适当地命名 （ page 43-44）
重新分解 （ page 44）
2009-7-20 144
数据实体关联图 (Note 43)
与数据流图描绘了系统中发生的过程一样，实体联系图（ entity-relationship diagram，
E R D）描绘了系统的数据关系
分析实体联系图有助于对业务或系统数据组成的理解和交互，并暗示产品将有必要包含一个数据库。
实体（ e n t i t y）是物理数据项（包括人）
或者数据项的集合，这对所分析的业务或所要构造的系统是很重要的
2009-7-20 145
化学制品仓库存货清单化学制品容器存储 执行化学制品请求
1
M
M
1
“化学制品跟踪系统,的实体联系图
2009-7-20 146
需求建模实例酒店管理系统 的局部 DFD
已预订的入住预订请求预订 预订确认未预订的入住已预订的入住请求未预订的入住请求客人数据客房数据预订确认信息客人信息夜审结算信息 财务系统时钟
2009-7-20 147
需求建模实例：
某金融贸易系统用例图 (UML)
风险分析交易估计进行交易进行交易接待员酒店系统财务系统
2009-7-20 148
需求建模实例：
用例图举例（ UML）
签定一份保险单客户保险销售人员销售统计客户统计需求建模实例：
UML类图实例 (Note 44)
客人姓名地址身份证号码护照号码 ……
预订
……
入住住宿编号付款方式 ……
退房……
客房状态日期人数
……设置状态
……
客房
……
服务日期数量设置 ……
读取 ……
服务类别名称价格设置 ……
1 0..*
1
0..*
0..*
0..11..*
1
0..*
1*
2009-7-20 150
需求建模实例：
描述 客房状态的状态图 (Note 45)
取消预定已预订空闲占用 维修事件创建
2009-7-20 151
需求建模实例：
接电话的顺序图 （ UML）
受话者 交换机 远程交换机 受话者拿起话筒听通话声拨号码
......
铃响信号 铃响铃响停止信号拿起话筒铃响停止
<10
d
e
a
b
c
{b-a<1}
{e-d<5}
{c-b<10}
路径
2009-7-20 152
需求建模实例：
UML协作图举例计算机 队列打印服务器 打印机打印文件打印机忙保存打印文件打印机空闲打印文件
2009-7-20 153
§ 3.5 数据词典
(DD,DataDictionary)
DD是对所有与系统相关的数据元素的一个有组织的列表,以及 精确的、严格的定义,使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解
2009-7-20 154
词典与数据流图之间关系 （ page 44）
数据流图描述了系统的,分解,；
依靠,词典,来说明各个成分的含义；
数据流图中所有名字的定义就构成一本词典；
数据流图和词典结合在一起构成了,需求说明书,
数据流图中出现的每一个数据流名、每一个文件名和每一个加工名在词典中都应该有一个条目给出这个名字的定义。
2009-7-20 155
词典条目的各种类型 （ page,45）
四个类型条目
数据流
文件
数据项（指不在分解的数据单位）
加工
词典条目的实例 （ page 46－ 47）
结合上次自习的内容自行学习本节
2009-7-20 156
需求建模实例：
数据字典条目的定义预订请求＝客人数据＋住宿期限 +客房类别客人数据＝客人姓名 +地址 +身份证号码
+[护照号码 ] +支付方式身份证号码 =十进制 15{数字 }18
护照号码＝字母 + 8{数字 }8
字母＝,A”…,Z”
十进制数字＝,0”…,9”
2009-7-20 157
需求建模实例：
数据字典条目的定义
F1:航班信息文件 ＝ {航空公司名称＋航班号
＋起点＋终点＋日期 ＋起飞时间＋降落时间 }
航空公司名称＝ 2{字母 }4
航班号＝ 3{十进制数字 }3
字母＝,A”…,Z”
十进制数字＝,0”…,9”
起点＝终点＝ 1{汉字 }10
起飞时间＝降落时间＝时＋分
2009-7-20 158
需求建模实例：
数据字典条目的定义时＝,00”…,23”
分＝,00”…,59”
日期＝年＋月＋日年＝ [2000｜ 2001｜ 2002｜ 2004]
月＝,01”…,12”
日＝,01”…,31”
2009-7-20 159
§ 3.6 小说明
数据流图中每一个基本加工（即不再进一步被分解的加工）都必须有一个,小说明,
小说明中应精确描述用户要求一个加工,做什么,
加工的激发条件
加工逻辑
加工优先级
加工执行频率
出错处理
2009-7-20 160
结构化的语言 （ page 51）
构成方式
语态
词汇
举例
2009-7-20 161
判定表与判定树 （ page 54-56）
有些问题不易用单纯的语言表达
判定表组成：
条件桩
条件条目
操作桩
操作条目
判定树
2009-7-20 162
§ 3.7 模型的作用
在建模过程中了解系统
通过抽象降低复杂性
有助于回忆所有的细节
有助于开发小组间的交流
有助于与用户的交流
为系统的维护提供文档
2009-7-20 163
需求分析建模方法分析建模方法
结构化分析 (传统建模方法 )
面向对象分析
2009-7-20 164
模型的作用计算机世界现实世界影射计算机世界现实世界 结构化开发方法结构化分析结构化设计结构化编程
OOA
OOD
OOP
面向对象开发方法模型的作用
2009-7-20 166
结构化分析模型的组成结构数据流图
(DFD)
E-R图状态 变 迁图
(STD图 )
加工说明控制说明数据对象说明数据字典
（ DD）
2009-7-20 167
面向对象分 析模型的组成结构对象 -关系模型类 /对象模型对象 -行为模型使用实例
(Use Case)
操作、
2009-7-20 168
重点小结
2009-7-20 169
§ 3.8 结构化分析方法
(Structured Analisys,SA)
基于数据流技术的分析方法需求获取应遵循的三条基本原则：
分解
抽象
投影
2009-7-20 170
分析模型的元素
数据字典 (DD),模型核心 (中心库 )
E-R图 (ERD)：
数据流图 (DFD)
指明数据在系统中移动时如何被变换 ;
描述对数据流进行变换的功能 ;
DFD中每个功能的描述包含在加工规约 (小说明 )。
状态变迁图 (STD)
指明作为外部事件的结果,系统将如何动作。
2009-7-20 171
E-R图是数据建模的基础客人入住客房状态客房服务 服务类别姓名地址身份证号码护照号码电话
……
客房号床位数房间类别价格 1
……
住宿编号住宿时间支付方式
……
日期，客人数状态 (已预定 /占用 /维修中 )
……
日期，数量
……
名称，价格
……
2009-7-20 172
将分析模型转换为软件设计数据字典数据流图
E-R图状态变迁图加工规约控制规约数据对描述象数 据 设 计体系结构设计接口设计过程设计分析模型 设计模型
2009-7-20 173
§ 3.9 实例 考务处理系统功能
(1)对考生送来的报名单进行检查 ;
(2)对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站 ;
(3)对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格标准审定合格者 ;
(4)制作考生通知单 (含成绩及合格 /不合格标志 )
送给考生 ;
(5)按地区进行成绩分类统计和试题难度分析，
产生统计分析表。
2009-7-20 174
实例 考务处理系统功能考务处理系统的分层 DFD
如下：
2009-7-20 175
顶层数据流图考生考务处理系统考试中心阅卷站不合格报名单报名单准考证考生通知单 成绩清单合格标准错误成绩清单考生名单统计分析表
2009-7-20 176
0层数据流图登记报名单报名单准考证
1
统计成绩
2不合格报名单考生通知单成统计分析表考生名册绩清单合格标准考生名单成绩 清单错误
2009-7-20 177
一层数据流图 (a)
检查报名单报名单准考证
1.1
编准考证号
1.2不合格报名单考生名册考生名单合格报名单登记考生
1.3
2009-7-20 178
一层数据流图 (b)
检查成绩清单
2.1 审定合格者
2.2
考生名册正确成绩清单制作通知单
2.3分析统计成绩
2.4分析试题难度
2.5
试题得分清单考生通知单难度分析表合格标准分类统计表成绩清单错误成绩清单 经审定的成绩清单
S
21
3
2.22.1
2.3
3.1 3.2
顶层
（不编号）
0层
1层
2009-7-20 180
数据字典举例
F1:航班信息文件 ＝ {航空公司名称＋航班号
＋起点＋终点＋日期 ＋起飞时间＋降落时间 }
航空公司名称＝ 2{字母 }4
航班号＝ 3{十进制数字 }3
字母＝,A”…,Z”
十进制数字＝,0”…,9”
起点＝终点＝ 1{汉字 }10
起飞时间＝降落时间＝时＋分
2009-7-20 181
再来看看 ——
结构化分析模型的组成结构数据流图
(DFD)
E-R图状态 变 迁图
(STD图 )
加工说明控制说明数据对象说明数据字典
（ DD）
2009-7-20 182
§ 3.11 需求分析的其他工作 （ page 63）
确定设计限制
确定验收标准
编写,初步用户手册,
复查需求说明书
2009-7-20 183
补充知识
UML语言和图
2009-7-20 184
UML简介 （ Note L1）
UML定义
由信息系统三位专家 Grady Booch，
James Rumbaugh和 Ivar Jacobon
OMG组织采奶作为业界标准
2009-7-20 185
UML的开发历程 （ Note L2）
Booch’91其它方法 OMT-1 OOSE
Booch’93 OMT-2
UML 0.8
UML 0.9&0.91
UML 1.0
UML 1.1
UML同行专家意见
OMG认证
10/95
10/96 & 9/96
OMG审核,1/97
OMG修正,9/97
OMG采用,11/97
UML 1.3
2009-7-20 186
UML架构 （ Note L3）
UML由图和元模型组成
元元模型层
元模型层
模型层
用户模型层
2009-7-20 187
UML的模型、视图、图与系统架构的建模 （ Note L4）
用例视图
逻辑视图
并发视图
组件视图
展开视图
2009-7-20 188
UML与面相对象的软件分析与设计
（ OOA&D） （ Note L5）
标准的表示方法
与软件开发的成功经验集成
2009-7-20 189
UML的应用领域 （ Note L6）
UML被用来为系统建模，它可应用的范围非常广泛
在不同系统中的应用
信息系统
技术系统
嵌入式实时系统
分布式系统
商业系统
2009-7-20 190
在软件开发不同阶段的应用 （ Note L7）
需求分析
分析
设计
构造
测试
2009-7-20 191
静态建模：用例和用例图 （ Note L8）
用例模型的基本组成：用例、角色和系统
用例图,
风险分析交易估计进行交易进行交易接待员酒店系统财务系统
2009-7-20 192
发现角色 （ Note L9）
通过回答下泪问题，可以帮助建模者发现角色
使用系统主要功能的人是谁？
需要借助于系统完成日常工作的人是谁？
谁来维护、管理系统，保证系统正常工作
系统控制的硬件设备有哪些？
系统需要与哪些其它系统交互？
对系统产生的结果感兴趣的人或事是哪些？
2009-7-20 193
发现用例 （ Note L10）
询问以下问题
角色需要从系统中获得哪种功能？角色需要做什么？
角色需要读取、产生、删除、修改或存储系统中的信息吗？
系统中发生的事件需要通知角色吗？
如果用系统的新功能处理角色的日常工作是简化了还是提高了工作效率？
2009-7-20 194
UML中的用例 （ Note L11）
2009-7-20 195
用例之间的关系 （ Note L12）
2009-7-20 196
描述用例
（ Note L13）
2009-7-20 197
测试用例 （ Note L14）
用例可用于测试系统的正确性和有效性。
正确性表明系统的实现符合规格说明。
有效性保证开发的系统是用户真正需要的系统
2009-7-20 198
实现用例 （ Note L15）
UML中实现用例的基本思想是用协作表示用例，而协作又被细化为用若干个图。
协作的实现用脚本描述。
2009-7-20 199
第四章 设 计 方 法
2009-7-20 200
主要内容 （ Note 46）
▲ 什么是结构化设计
▲ 结构化设计方法的主要思想
▲ 结构化设计的重要组成部分
▲ 结构化设计的方法
2009-7-20 201
结构化设计的工作原理（ Note 47）
结构化设计目标
结构化设计的优点
利用模块结构减少开发和维护软件的费用
2009-7-20 202
软件设计分为两个阶段：
(1)概要设计 (总体设计 )（ Page 66）
确定软件的结构以及各组成成分
(子系统或模块 )之间的相互关系。
(2)详细设计确定模块内部的算法和数据结构，产生描述各模块程序过程的详细文档。
2009-7-20 203
模块
模块是鱼油一定功能的可以用名词调用的程序语句集合，如：
独立的汇编程序
COBOL的段和节
Pascal过程
FORTRAN的子程序
汇编的宏
2009-7-20 204
控制结构 (程序结构 )
控制结构是软件模块间关系的表示
2009-7-20 205
控制结构图示：
2009-7-20 206
控制结构的层次规则
只有一个顶层 (0层 )模块
0层外任一模块都会在它的邻层存在一模块与它有关
同层模块间不发生联系
2009-7-20 207
软件结构度量术语深度宽度扇出扇入
(模块的层数 )
(同一层最大模块数 )
(一个模块直接调用的模块数 )
(调用一个给定模块的模块个数 )
2009-7-20 208
模块化 (Modularity)
模块化是好的软件设计的一个基本准则从整体上把握问题,隐蔽细节复杂问题 较小问题分解可减小解题所需的总的工作分解
2009-7-20 209
抽象 (Abstraction)
抽象原则应用举例
Windows NT一体化的 I/O系统设计文件管理网络管理设备管理高速缓冲存储器
Ｏ
Ｓ
对虚拟文件的字节流,
虚拟文件可为任何设备和实体抽象
2009-7-20 210
例,将问题 (P1+P2)分解为 P1,P2
设函数 C(x)定义问题 x 的复杂程度函数 E(x)确定解决问题 x 需要的工作量对问题 P1和 P2,如,
C(P1) > C(P2)
显然,E(P1) > E(P2)
有规律,C(P1+P2) > C(P1)+C(P2)
E(P1+P2) > E(P1)+E(P2)
＂ 各个击破 ＂ 理论
2009-7-20 211
模块度 (Note 48)
成本或工作量模块数量软件总成本集成成本成本 /模块
M
最小成本区域
2009-7-20 212
结构化设计的适用范围 （ Note 49）
尤其适用于采用结构化程序设计实现的系统
结构化设计并不是一种广泛适用的系统设计技术
什么人来完成设计呢？
结构化设计的结果
2009-7-20 213
SA与 SD的关系 （ Note 50）
结构化分析的结果 结构化设计的工具数据流图 初始结构图生存周期字典的数据部分设计数据字典伪码 实现方面 伪码实体关系图 数据库设计事务框图 分层、细化事务模型
2009-7-20 214
SD来源于 SA
来源：结构化分析 来源：结构化分析 来源：结构化分析数据流图字典项伪码实体关系图事务框图环境的限制 质量的标准转化分析 细化设计进入实现阶段初始结构框图
2009-7-20 215
概要设计的基本概念
将系统划分成模块 （ Page 66）
决定每个模块的功能 （ Page 66）
决定模块的调用关系 （ Page 66）
决定模块的界面，即模块间传递的数据 （ Page 66）
2009-7-20 216
结构化设计（ SD方法）概要
相对独立、单一功能的模块（ page 67）
块间联系和块内联系（ page 67）
描述方法（ page 68）
步骤（ page 69）
2009-7-20 217
结构图 (SC Structure Chart)
结构图主要成分 （ page 68）
模块 ——用方框表示，方框中写有模块的名字，
一个模块的名字应适当地反映这个模块的功能，
这就在某种程度上反映了块内联系；
调用 ——从一个模块指向另一个模块的箭头表示前一模块中含有对后一模块的调用；
数据 ——调用箭头边上的小箭头表示调用时从一个模块传入送给另一个模块的数据，小箭头也指出了传送的方向。
2009-7-20 218
结构图 (SC Structure Chart)
SD方法在概要设计中的主要表达工具约定：
编辑学生记录读学生记录学生数据无此学生学号不加区分的数据数据信息控制信息
2009-7-20 219
SC中的四种模块传入模块
(a) (b)
A
A
传出模块
B
B
变换模块
(c)
C D
协调模块
E
(d)
E F F
2009-7-20 220
SC中的选择调用
A
CB D
A根据内部判断决定是否调用 B
A按另一判定结果选择调用 C或 D
2009-7-20 221
SC中的循环调用
A
B C
A根据内在的循环重复调用 B,C等模块
2009-7-20 222
结构图 (SC)举例医院管理系统门诊管理药房管理药库管理病房管理财务管理处 方挂号处理挂 号 费总 计挂号单挂号费总计 出库处理 进药管理病历管理 处方管理 常规处理
2009-7-20 223
酒店管理信息系统功能结构图
H M I S
收银管理子系统收银管理子系统 收银管理子系统客人登记预定登记客房处理历史记录客房查询预定查询餐桌安排菜单作业营业结帐汇总打印各类查询初始设置客帐处理退房处理夜审处理客帐查询报表打印
2009-7-20 224
大型零售商场管理信息系统功能结构图
TM M I S
系统维护
P
O
S
系统零售实时系统商品进货管理商品批发管理商品库存管理商品及商品帐管理顾客管理连锁店管理财务管理人事工资管理计划统计管理经理查询
2009-7-20 225
信息隐蔽 (Information Hiding)
模块所包含的信息，不允许其它不需要这些信息的模块访问，独立的模块间仅仅交换为完成系统功能而必须交换的信息 。
2009-7-20 226
块间联系
块间联系大小：
方式,作用,数量
联系方式（ Page 71）
用过程语句调用,直接引用
共用信息的作用（ Page 73）
公用信息的数量（ Page 74）
表格 4.1（ page 75）
2009-7-20 227
块内联系
偶然型（ Page 76）
逻辑型（ Page 76）
瞬时型（ Page 77）
通讯型（ Page 77）
顺序型（ Page 78）
功能型（ Page 78）
2009-7-20 228
偶然内聚 (巧合内聚 )
A B C
M MOVE O TO R
READ FILE F
MOVE S TO T
模块 M中的三个语句没有任何联系缺点：可理解性差,可修改性差例,
2009-7-20 229
逻辑内聚
把几种相关功能（逻辑上相似的功能）
组合在一模块内，每次调用由传给模块的参数确定执行哪种功能。
2009-7-20 230
逻辑内聚模块
A B C
E F G
A B C
EFG
A1 B1 C1
EFG模块内部逻辑
E,F,G逻辑功能相似，组成新模块 EFG
缺点,增强了耦合程度 (控制耦合 )
不易修改，效率低公用代码段公用代码段
2009-7-20 231
时间内聚 (经典内聚 )
模块完成的功能必须在同一时间内执行，这些功能只因时间因素关联在一起。
例如,初始化系统模块、
系统结束模块、
紧急故障处理模块等均是时间性聚合模块,
2009-7-20 232
过程内聚（顺序性组合）
模块内各处理成分相关，
且必须以特定次序执行
2009-7-20 233
过程内聚模块读入成绩单审查成绩单统计成绩打印成绩读入并审查成绩单统计并打印成绩单
2009-7-20 234
通信内聚
模块内各部分使用相同的输入数据，或产生相同的输出结果
2009-7-20 235
通信内聚模块例产生工资报表计算平均工资职工工资记录职工工资报表平均工资产生职工工资报表并计算平均工资模块
2009-7-20 236
信息内聚
模块完成多个功能，各功能都在同一数据结构上操作，每一功能有唯一入口。
2009-7-20 237
信息内聚模块符 号 表查找 登录 删除 修改几个加工同时引用一个共同的数据
2009-7-20 238
功能内聚
模块仅包括为完成某个功能所必须的所有成分。
模块所有成分共同完成一个功能，缺一不可内聚性最强
2009-7-20 239
块间联系
无直接关系型
数据耦合
标记耦合
控制耦合
外部耦合
公共耦合
内容耦合
2009-7-20 240
(1) 无直接耦合两个模块没有直接关系 (模块 1和模块 2)，模块独立性最强。
模块 1 模块 2
模块 3 模块 4
241
(2) 数据耦合一模块调用另一模块时，被调用模块的输入、输出都是简单的数据 (若干参数 )。
属松散耦合。
242
数据耦合举例开发票计算水费单价数量 金额
243
(3) 标记耦合 (复合型耦合 )
如两个模块通过传递 数据结构 (不是简单数据，而是记录、数组等 )加以联系，或都与一个 数据结构 有关系,
则称这两个模块间存在标记偶合。
244
标记耦合举例计算水电费计算水费 计算电费住户情况 水费电费住户情况
,住户情况,是一个 数据结构,图中模块都与此数据结构有关,
,计算水费,和,计算电费,本无关,由于引用了此数据结构产生依赖关系,它们之间也是标记偶合,
245
将标记耦合修改为数据耦合举例计算水电费计算水费 计算电费本月用水量本月用电量水费电费
246
(4) 控制耦合一模块向下属模块传递的信息 (开关量、标志等控制被调用模块决策的变量 ) 控制了被调用模块的内部逻辑。
247
控制耦合举例
A
计算平均分或最高分
B
平均 /最高
(控制信号 ) 成绩读入分数输出结果计算平均分 计算最高分平均 /最高?
B
248
控制耦合增加了理解和编程的复杂性，调用模块必须知道被调模块的内部逻辑，增加了相互依赖
(1)将被调用模块内的判定上移到调用模块中进行
(2)被调用模块分解成若干单一功能模块去除模块间控制耦合的方法
249
改控制耦合为数据耦合举例
A
计算平均分
B1
平均成绩 最高成绩计算最高分
B2
250
(5) 外部耦合
一组模块均与同一外部环境关联 (例如,I/O模块与特定的设备、格式和通信协议相关联 ),它们之间便存在外部耦合。
外部偶合必不可少,但这种模块数目应尽量少。
251
(6) 公共耦合 (公共数据区耦合 )
一组模块引用同一个公用数据区 (也称全局数据区、公共数据环境 )。
公共数据区 指：
全局数据结构
共享通讯区
内存公共覆盖区等
252
公共耦合举例
Ａ
公共数据区
CB
模块 A,B,C间存在错综复杂的联系
253
(1)软件可理解性降低
(2)诊断错误困难
(3)软件可维护性差，
(4)软件可靠性差
(公共数据区及全程变量无保护措施 )
慎用公共数据区和全程变量 !!!
公共耦合存在的问题
254
(7) 内容耦合一模块直接访问另一模块的内部信息 (程序代码或数据）
最不好的耦合形式 !!!
A B A
B
模块代码重叠
Entry1
……
Entry1
……
多入口模块
2009-7-20 255
系统结构的形态 （ Note 52）
形态（ morphology）所指的是系统结构所表现出来的形状。
深度、宽度、扇出和扇入
Page 68,描述方式,
模块、调用、数据
一个模块在结构图中只能出现一次
输入模块在作，输出模块在右，计算模块居中
2009-7-20 256
系统结构的影响范围和控制范围
系统中某一层上模块中的判定或者条件语句
（例如 If语句）在系统中会产生多种后果，根据该判定的结果去执行或不执行其他层的某个处理或数据。
该处理就是,条件依赖,于某个判定
判定的,影响范围,是指包含,条件依赖,于改判定的处理的全部模块
一个模块的,控制范围,是指模块本身和它的全体子模块
2009-7-20 257
影响范围和控制范围
影响范围应该是这个判定所在模块的控制范围的一个子集
但是实际上，在系统中控制范围和影响范围的关系常常并非如此。
影响范围和控制范围 （ note 53）
Top
A
Y
B
B1
X
影响范围
Top
A B
B1 B2
X
Top
Y
A B
X
A
Y
B
B1 B2
X
判定图 1.影响范围在控制范围之外图 2.影响范围在控制范围之内，但判定位置太高图 3.影响范围在控制范围之内，正确实现图 4.理想的影响范围和控制范围
2009-7-20 259
耦合、内聚与模块独立性关系
耦合与内聚都是模块独立性的定性标准，
都反映模块独立性的良好程度。但耦合是直接的主导因素，内聚则辅助耦合共同对模块独立性进行衡量。
2009-7-20 260
设计技巧
2009-7-20 261
面向数据流的设计方法
SD以数据流图为基础，它定义了把 DFD
变换成 软件结构 的不同 映射 方法映射DFD
(问题结构 ) 软件系统的结构 (程序结构 )
2009-7-20 262
系统结构特征可归纳为两种典型形式
变换型结构
事务型结构数据流图可分为两种类型,
变换型数据流
事务型数据流变换中心输入 输出变换型 结构事务中心接受路径动作路径事务型结构由输入、变换中心和输出三部分组成具有在多种事务中选择执行某类事物的能力基本模型 特征
2009-7-20 264
基本模型变换型数据流结构事务型数据流结构传入 变换 传出变换中心传入部分传出部分事务分析事务中心动作
1
动作
2
动作
3
接受接受部分
2009-7-20 265
变换型数据流举例输入信息物理输入格式检查 处理 显示正确信息 结果物理输出数据变换中心逻辑输入逻辑输出传入部分 传出部分特点：具有明确的传入、变换 (或称主加工 ) 和传出界面的 DFD
2009-7-20 266
事务型数据流图举例
I M
L
N
O
A
B
C
D
F
E
G
H
2009-7-20 267
大型系统 DFD中,变换型和事务型结构往往共存,
T
事务中心传入 变换 传出
2009-7-20 268
面向数据流设计方法的设计步骤
(1)精化 DFD
(2)确定 DFD类型
(3)把 DFD映射到系统模块结构设计出模块结构的上层
(4)基于 DFD逐步分解高层模块设计出下层模块
(5)根据模块独立性原理，精化模块结构
(6)模块接口描述面向数据流方法的设计过程精化数据流图区分事务中心和数据接收路径映射成变换结构流类型区分输入和输出分支映射成事务结构用启发式设计规则精化软件结构导出接口描述和全程数据结构复查详细设计
“事务,,变换,
事务分析 变换分析
2009-7-20 270
SD方法的两种映射过渡方法变换型 DFD
事务型 DFD
初始 SC
初始 SC
变换分析事务分析
2009-7-20 271
初始的 SC
主模块输入模块 主加工模块 输入模块事务控制模块接受模块 动作发送模块动作 1模块 动作 2模块 动作 3模块由变换分析产生由事务分析产生
2009-7-20 272
(1) 变换分析设计方法步骤：
(1)区分传入、变换中心、
传出部分，在 DFD 上标明分界线
B CA
D E
Q
P R
W
U V
a b
c
ed
r
p
u
w
v
变换中心传入部分传出部分
2009-7-20 274
变换分析设计方法
步骤：
(2)第一级分解 (建立初始 SC框架 )
设计顶层和第一层模块第一级分解的方法
MC
MTMA ME
2009-7-20 276
第一级分解后的 SC
MC
MTMA ME 第一层顶层
c,e
c,e u,w
u,w
传入模块 传出模块中心变换模块
2009-7-20 277
变换分析设计方法
步骤,
(3)第二级分解 (分解 SC各分支 )
自顶向下分解，设计出每个分支的中、下层模块
2009-7-20 278
传入分支的分解 (1)
MA
C
B
A
b
a
c
E
D
d
e
c,e
2009-7-20 279
传入分支的分解 (2)
MA
Get C
b
a
c
Read D
d
e
c,e
B to C
b c d e
a b
Get E
Get B D to E
A to BRead D
2009-7-20 280
传出分支的分解
ME
W
Write V
u
u
w,u
v v v
Put U
U to V
ME
U Write W
ww u
w,u
V
(1) (2)
2009-7-20 281
中心加工分支的分解
MT
PQ R
e
c,p r
u,wp
r
2009-7-20 282
(2) 事务分析设计方法任何情况下都可使用变换分析方法设计软件结构，但如数据流具有明显的事务特点时 (有一个明显的事务中心 ),以采用事务分析方法为宜。
2009-7-20 283
事务分析设计方法
步骤：
(1)在 DFD上确定事务中心、接收部分和发送部分。
(2)画出 SC框架，把 DFD上的三部分分别映射为事务控制模块、接收模块和动作发送模块。
(3)分解细化接收分支和发送分支，
完成初始 SC。
用户命令交互子系统ＤＦＤ
读用户命令密码命令密码显示信息系统参数数据用户命令读系统数据 配置信息显示信息和状态命令分析处理读密码命令类型开 /关命令建立配置文件原配置数据激活 /非活动系统与文件中密码比较格式化配置数据配置 命令检验信息过程重试信息四位数字 检验信息检验信息
A/D信息格式化配置数据格式化配置数据
2009-7-20 285
初始的 SC
主模块输入模块 主加工模块 输入模块事务控制模块接受模块 动作发送模块动作 1模块 动作 2模块 动作 3模块由变换分析产生由事务分析产生
2009-7-20 286
事务分析的映射方法总控调度
C路径B路径A路径
A路径
B路径C路径接收路径
2009-7-20 287
用户命令交互子系统初始的 SC
用户执行模块读用户命令 命令处理密码处理控制器现用 /非现用系统系统设置控制器用户命令交互子系统ＤＦＤ
读用户命令密码命令密码显示信息系统参数数据用户命令读系统数据 配置信息显示信息和状态命令分析处理读密码命令类型开 /关命令建立配置文件原配置数据激活 /非活动系统与文件中密码比较格式化配置数据配置 命令检验信息过程重试信息四位数字 检验信息检验信息
A/D信息格式化配置数据格式化配置数据
2009-7-20 289
用户命令交互子系统的 SC
用户执行模块读用户命令 命令处理密码处理控制器现用 /非现用系统系统设置控制器读系统数据建立配置文件显示信息与状态用户命令交互子系统ＤＦＤ
读用户命令密码命令密码显示信息系统参数数据用户命令读系统数据 配置信息显示信息和状态命令分析处理读密码命令类型开 /关命令建立配置文件原配置数据激活 /非活动系统与文件中密码比较格式化配置数据配置 命令检验信息过程重试信息四位数字 检验信息检验信息
A/D信息格式化配置数据格式化配置数据
2009-7-20 291
用户命令交互子系统的 SC
用户执行模块读用户命令 命令处理密码处理控制器现用 /非现用系统系统设置控制器读系统数据建立配置文件显示信息与状态读密码用文件比较密码密码输出控制器产生无效信息
2009-7-20 292
事务流设计举例
I M
L
N
A
B
C
D
F
E
G
事务中心
2009-7-20 293
事务流设计举例取 A
总控
A
L M N
G
D
B C F
E
（主模块）
事务加工模块
2009-7-20 294
动作分支的典型结构
P
T 2T 1 T i
A 2
D 2
A 1
D 1
A 3 A j
D k
事务层操作层细节层处理层 主模块事务加工模块操作模块细节模块
2009-7-20 295
事务流设计举例取 A
总控
A
L M N
G
D
B C F
E
动作 1 动作 n….
细节模块 1 细节模块 2 ….
（操作模块）
（细节模块）
2009-7-20 296
事务型数据流图举例
I M
L
N
OA
B
C
D
F
E
G
H
2009-7-20 297
事务流设计举例 (另一种画法 )
输入 A
XX系统变换控制
A
L M
A
G
D
B C
FE
输出 E,F,G
E,F,G E,F,G
输出 HO
E,F、
G H H
N
2009-7-20 298
(3) 混合流设计举例
3 4
1
2
6
7
5
8
10
9
11
变换中心传 入 传 出事务型
2009-7-20 299
混合流设计举例
T
事务中心 传入 变换 传出接收部分发送部分
2009-7-20 300
混合流设计举例
AB
T1
变换中心传入 传出
T2
T3
a
b b1b2
b3
c1
c2
c3
d e g
f j
Ｌ
m
事务流子系统
BC CD DE
EH
HK
FJ
KL
LMh
k
2009-7-20 301
混合流设计举例输入 D
XX系统变换控制 输出 K
输入 C
d
c
输出 LCD DE FJ EH HK KL
c d
d k
k
k
L L
输出 MLM
m mL事务子系统
2009-7-20 302
体系结构设计优化
2009-7-20 303
体系结构设计优化将初始 SC根据模块独立性原则进行精化,对模块进行合并、分解修改、调整，
得到高内聚、低耦合模块，得到易于实现、易于测试和易于维护的软件结构，
产生设计文档的最终 SC。
2009-7-20 304
改进软件结构设计的指导原则
(软件结构设计的启发式规则 )
(1)模块功能的完善化
(2)消除重复功能
(3)将模块的影响限制在模块的控制范围内
(4)深度、宽度、扇出和扇入适中
(5)模块大小适中
(6)降低模块接口的复杂性
(7)模块功能可预测
(8)避免模块的病态连接
(9)根据设计约束和可移植性要对软件打包
2009-7-20 305
(1) 模块功能的完善化完整的模块应包括三部分：
(1)执行规定功能部分
(2)出错处理部分
(3)需返回给调用者数据时，
返回是否正确结束标志。
2009-7-20 306
(2)消除重复功能
Q1
C
Q2
C
Q1 Q2
C改进前
Q1,Q2功能相似
X Y
Q’
X Y X Y
重复部分 改进方法 1：将 Q1,Q2
合并为 Q’
不可取改进方法 2：
将 Q1,Q2的公共部分分离出来
2009-7-20 307
(3)将模块的影响限制在模块的控制范围内
C
H
D E
G
X
F
A I
L
J KB
模块 C的控制范围,C,D,E,F,G,H
如果模块
C 作出的决策影响了模块 L，
L超出了 C
的控制范围
2009-7-20 308
(4) 减少高扇出争取高扇入编外人员工资取得工资数据计时制工资额薪金制工资额编外人员税款编外人员扣款常规扣款税收扣款计算实发工资避免平铺结构
2009-7-20 309
增加中间层降低扇出编外人员工资取得工资数据计时制工资额薪金制工资额编外人员税款编外人员扣款常规扣款税收扣款计算实发工资计时工人实发工资计薪工人实发工资编外人员实发工资
2009-7-20 310
(5) 模块大小适中模块过大：可理解程度下降模块过小：开销大于有效操作系统接口复杂
2009-7-20 311
(6)降低模块接口的复杂性
接口传递信息应简单且和模块功能一致。
2009-7-20 312
(7) 模块功能可预测模块看成黑盒子，相同输入产生相同输出，其功能为可预测的。
模块带有内部状态其功能可能是不可预测的。难理解、难测试、难维护。
2009-7-20 313
防止模块功能过分局限功能单一的模块具有高内聚。
但如任意限制局部数据结构的大小，过分限制控制流中可做的选择或外部接口的模式，模块功能就过分局限，使用范围过分狭窄，缺乏灵活性和可扩充性。
2009-7-20 314
(8)避免模块的病态连接防止指向模块中间的分支或引用
（针对内容耦合）
2009-7-20 315
(9)根据设计约束和可移植性需求对软件打包打包指用来为特定环境组装软件的技术
2009-7-20 316
小结：结构化设计
2009-7-20 317
结构化设计的质量标准 （ Note 51）
结构图
耦合度
聚合度信息隐蔽的目的：
提高模块的独立性，减少修改或维护时的影响面。
2009-7-20 318
结构图 （ note 51a）
A
CB D
A
B
Z
X.Y
A
CB D
1
重复调用和一次调用条件调用
2009-7-20 319
耦合度 (Note 51b)
结构化设计方法的重要成果是把影响耦合度的因素归结为如下原则：
连系方式的类型：用过程语句调用低于直接调用
接口的复杂性：接口间传递信息的数量
连系的作用：传送信息流的类型，数据型、控制型或混合型
耦合时间：按执行时间、装入时间、连接时间及编译时间来区分。
2009-7-20 320
连系的作用 (Note 51c)
混合型的例子：当一个模块修改另一个模块的代码时，对修改者来说修改的代码是当作数据来处理的。而对被修改者来说，则是一种对
,控制,的变动。
控制型的例子：模块 A通过用作控制信号的开关量实际上控制着模块 B的工作。
2009-7-20 321
控制型耦合转变为数据型耦合 (Note
51d)
一般来说，控制型耦合是不必要的，可以通过分裂模块等方法把控制型耦合转变成数据型耦合。
A
取阴历取阳历
A
取阳历日期或取阴历日期日期类型选择 阴历日期阳历日期
2009-7-20 322
用三个封装级别表示的软件结构原始代码行
0级程序模型
(子程序或过程 )
1级 2级类 /对象结构
2009-7-20 323
结构设计（或 1级）标准，用以管理每一对封装级别的元素之间的相互关系内聚结构化设计
0级结构体
（代码行）
1级结构体
（程序）
TO：
FROM：
0级结构体
（代码行）
1级结构体
（程序）
输出端耦合性内聚 是指度量一个给定的程序内的多行代码的单一功能性
，以确定是否达到该程序所要实现的目的。
耦合性 用来度量程序之间联系的次数和强度
2009-7-20 324
上表的扩展：包括 2级封装（所有的类）
内聚结构化设计
0级结构体
（代码行）
1级结构体
（程序）
TO：
FROM：
0级结构体
（代码行）
1级结构体
（程序）
输出端耦合性
—
2级结构体
（类）
—
—
类的耦合2级结构体（类） 类的内聚类的内聚 是模仿了一个程序的内聚。
类的耦合性 是一种度量类之间联系的次数和强度的方法。
2009-7-20 325
无耦合－没有依赖关系松散耦合－有少量依赖关系紧密耦合－有很多依赖关系图形表示耦合关系
2009-7-20 326
耦合强度依赖的因素：
一模块对另一模块的引用
一模块向另一模块传递的数据量
一模块施加到另一模块的控制的数量
模块间接口的复杂程度
2009-7-20 327
模块间耦合的类型 （ page 74）
低 无直接耦合耦 数据耦合合 标记耦合性 控制耦合外部耦合公共耦合高 内容耦合模块独立性弱
(低耦合 )
强
(中耦合 )
(较强耦合 )
(强耦合 )
2009-7-20 328
聚合度 （ Note 51e）
七层聚合类型
偶然型
逻辑型
瞬时型
通讯型
顺序型
功能型
2009-7-20 329
详细设计的基本概念 (page 108)
详细设计工具：
(1) 图形工具
流程图
盒图
问题分析图
(2) 表格工具
(3) 语言工具
2009-7-20 330
结构化程序设计（ SP）方法
结构定理
在结构定理的基础之上,Dijkstra主张避免 GOTO语句，而仅仅使用三种基本结构反复嵌套来构造程序。
自顶向下逐步加细
2009-7-20 331
SP方法实用的描述方式
流程图（ FC）
盒图（ NS）
问题分析图（ PAD）
程序设计语言（ PDL）
2009-7-20 332
系统流程图（ FC）
早于 DFD的一种建模工具。以图形方式说明系统中的控制流和数据流。
Dijkstra主张避免使用 GOTO语句，而仅仅使用顺序、选择和循环等三种基本结构来表示系统流程图示例初始处理数据检查、库存询问、库存分配定货处理帐单处理启动定货销售工作结束定货或询问显示数据顾客文卷库存文卷库存文卷接受的定货文卷临时定货文件显示选择查问库存的初始显示输入查询输入错询问回答检查定货单说明定货单发票询问定货
2009-7-20 334
本章结束软件设计
2009-7-20 335
补充内容
2009-7-20 336
面向对象的方法论
方法论是如何对复杂系统进行,抽象,
的工作，以及如何建立抽象模型 。
2009-7-20 337
面向对象分析建模 (OOA)
面向对象分析方法确实不同于结构化分析方法吗？
Fichman,R.G and C.F.Kemerer,
在,Object-oriented Conventional Analysis
and Design Methodologies” 中阐述：
我们的结论是面向对象分析方法表现了相对面向过程的方法学（如结构化分析）的根本性变化，而且相对面向数据的方法学仅仅是增量性的变化。面向过程的方法学在建模过程中的关注点不是对象的内在性质，从而导致了和面向对象的三个基本原理相正交的问题域模型。
2009-7-20 338
面向对象分析方法
面向对象分析方法使得软件工程师能够通过对象、属性和操作（作为主要的建模成分）的表示来对问题建模。
建立分析模型 5个基本原则：
（ 1） 建模信息域；
（ 2） 描述模块功能；
（ 3） 表示模型行为；
（ 4） 分解以模型显示更多细节；
（ 5） 早期模型表示问题的本质，而后期模型提供实现细节。
2009-7-20 339
OOA的意图
是定义所有和被求解的问题相关的类（及同类关联的关系和行为），为了达到这个目标，必须完成以下任务
2009-7-20 340
OOA的意图
（ 1）必须在客户和软件工程师之间沟通了解基本的用户需求；
（ 2）必须标识类 (定义属性和方法 )；
（ 3）必须刻划类层次；
（ 4）表示对象对象关系（对象连接）；
（ 5）必须建模对象行为；
（ 6）任务 (1)到 (5)递进地反复使用，直至完成建模
2009-7-20 341
流行的几种面向对象方法
Booch方法
Coad-Yourdon方法
Rumbaugh 方法 (简称 OMT）
（ Object Modeling Technology)
Jacobson 方法（简称 OOSE）
由 Rumbaugh,Booch,Jacobson
提出的统一建模语言
(Unify Modeing Language简称 UML)
2009-7-20 342
不同面向对象分析方法的相似步骤：
（ 1）使用基本需求作为指南选择类和对象；
（ 2）为对象标识属性和操作；
（ 3）定义组织类的结构和层次；
（ 4）建造对象 -关系模型的；
（ 5）建造对象 -行为模型。
2009-7-20 343
统一的 OOA方法
由 Rumbaugh,Booch,Jacobson 提出的统一建模语言 (Unify Modeing
Language简称 UML)
UML是一种定义良好，易于表达，功能强大且普遍实用的建模语言。
2009-7-20 344
UML的开发历程
Booch’91其它方法 OMT-1 OOSE
Booch’93 OMT-2
UML 0.8
UML 0.9&0.91
UML 1.0
UML 1.1
UML同行专家意见
OMG认证
10/95
10/96 & 9/96
OMG审核,1/97
OMG修正,9/97
OMG采用,11/97
UML 1.3
2009-7-20 345
OMT (对象建模技术
Object Modeling Technology)
对象建模技术将使用三种不同的模型从不同侧面来描述现实世界，即使用 对象模型,动态模型 和 功能模型三种模型。
OMT是一种 自底向上 和 自顶向下 相结合的方法。 OMT的第一步是从问题的陈述入手，构造系统模型，这是一种自底向上的归纳过程；系统模型建立后的工作就是分解，这是一种基于服务 (Service)的分解。这种从具体到抽象、再从抽象到具体的分析、设计过程符合人类的思维规律，使得需求分析更为彻底，系统可维护性也得以改善。
2009-7-20 346
OMT对象模型技术对象模型 动态模型 功能模型基本模型,
三个模型分别从不同角度分析系统
2009-7-20 347
OMT将开发过程划分为四个阶段
1,分析：分析人员从问题陈述入手开始，建立一个表示现实世界重要性质的应用领域模型。
2,系统设计：系统设计阶段要求做出有关整个系统结构的高层决策，在这一阶段中，目标系统应该根据分析模型和所设置的系统整体结构划分为若干子系统。系统设计人员必须确定哪能些性能需要优化，选择处理问题的策略，做出初步的资源分配。
2009-7-20 348
OMT将开发过程划分为四个阶段
3,对象设计：设计模型是在分析模型的基础上添加实现细节来完成的，在增加工这细节时，设计人员应该遵守在系统设计阶段确定的策略
4,实现：对象设计阶段所产生的对象类和联系最后都必须翻译成具体的程序设计语言，数据库或硬件实现，
在开发过程中，程序设计应该是相对简单机械的部分，
因为所有最困难的决策已经在设计阶段做出，目标语言在某种程度上可能影响设计决定，但设计决不应该依赖程序设计语言的细节，虽然目标语言在某种程序上可能影响设计决策
2009-7-20 349
分析模型
对象模型,描述静态结构,定义做事情的实体
功能模型,描述处理 (数据变换 ),
指明系统应,做什么,
动态模型,描述交互过程,规定什么时候做
2009-7-20 350
OMT模型系统分析和设计过程概观图产生需求结构及对象设计建立模型问题描述对象模型、动态模型、功能模型详细的对象模型详细的动态模型详细的功能模型分析阶段设计阶段
2009-7-20 351
实例：饮料自动售货机系统设置一个饮料自动售货机可以放置五种不同或部分相同的饮料，可由厂商根据销售状况自动调配，并可随时重新设置售价，但售货机最多仅能放置 50罐饮料，其按钮设计在各种饮料样本的下方，若经金额计算器累计金额足够，则选择键灯会亮；若某一种饮料已销售完毕，则售完灯会亮。
2009-7-20 352
实例：饮料自动售货机系统销售顾客将硬币投入售货机，经累加金额足额的饮料选择键灯亮，等顾客按键选择。顾客按键后饮料由取物楼掉出，并自动结算及找钱。
取消交易顾客可在按下选择键前任何一个时刻，拉动退币杆取消交易收回硬币。
2009-7-20 353
步骤
(1)找出对象及其关联
(2)赋予类及关联的属性数据
(3)组织类的结构
OMT的 对象图
2009-7-20 354
找出饮料自动售货机系统中的对象设置一个饮料自动售货机可以放置五种不同或部分相同的饮料，可由厂商根据销售状况自动调配，并可随时重新设置售价，但售货机最多仅能放置 50罐饮料，其按钮设计在各种饮料样本的下方，若经 金额计算器 累计金额足够，则选择键灯会亮；若某一种饮料已销售完毕，则售完灯会亮。
2009-7-20 355
找出饮料自动售货机系统中的对象销售顾客 将硬币投入 售货机,经累加金额足额的饮料 选择键 灯亮，等顾客按键选择。顾客按键后饮料由取物楼掉出，并自动结算及找钱。
取消交易顾客可在按下选择键前任何一个时刻，拉动 退币杆 取消交易收回硬币。
2009-7-20 356
对象模型描述系统内部对象结构，包括对象本身的定义、对象的属性、操作，以及对象与其它对象之间的关系。
对象模型是 OMT方法论中最重要的部分，动态模型、功能模型都将依次而建立 对象模型以对象图形式呈现，对象图由类构成。
饮料自动售货机 系统 对象图贩卖机饮料号码价格投币 -接受饮料掉出金额显示按纽退币杆售完显示存量计算器饮料号码存量递减售完显示重置选择钮选择钮状态灯亮灯熄售完灯亮按钮顾客姓名硬币投币 -置入拿取饮料退币杆退币杆状态拉动金额计算器金额累加找零重置购买选取被拉动属于属于属于属于
2009-7-20 358
建立数据字典为所有模型实体准备一个数据字典,精确描述每一个对象类,包括,
成员
约束
关联、属性、操作
2009-7-20 359
动态模型用来描述系统与时间相关的动态行为即系统的控制逻辑，表现对象彼此间经过相互作用后，随时间改变的不同运算顺序。
动态模型以,事件,（ Events）和
,状态,（ States）为其模型的主要概念。
动态模型以状态图形式呈现
2009-7-20 360
动态模型
事件,?瞬时发生的行为；
引起对象状态转换的控制信息 。
事件类和属性举例：
飞机起飞（航线、航班号、城市）
按动鼠标按钮（按钮、位置）
……,.
2009-7-20 361
动态模型状态,对象属性和对象关联的抽象形式状态的特征表示方法举例：
状态,闹铃响描述,闹铃响表示预定时间到产生本状态的事件序列：
设置闹钟（预定时间）
不包括清除闹铃的任何后续操作当前时间 =预定时间表征本状态的条件：
闹铃 =开，从预定时间起没有按键的情况下，
目标时间?当前时间?目标时间 =20秒
2009-7-20 362
动态模型本状态接受的各种时间：
事件 动作 下一个状态当前时间 =目标时间 +20 重新设置闹钟 正常按下按钮（任意按钮） 重新设置闹钟 正常
2009-7-20 363
动态模型表示方法
状态图状态和事件的网络，侧重描述每一类对象的动态行为
2009-7-20 364
状态图状态 1
Do:活动 1 状态 2.…...
事件 1[条件 1] / 动作 1 结束事件初始事件空闲 可视菜单左边按钮按下 /显示弹出菜单左边按钮弹起 /擦除弹出菜单光标移动 /高亮菜单项弹出菜单动作
2009-7-20 365
举例,饮料自动售货机系统的状态图投入硬币
（有效的）
按下选择饮料键
Do:显示售货机在备用所有灯都关闭
Do:显示金额总数
Do:显示金额已够饮料选择灯亮取出饮料结算找零扣减存量完成交易饮料“售完”灯亮投入硬币金额
(1元,5元,10元 )
金额不足再投币存量为零无效的硬币取消取消回到备用状态回到备用状态时序图举例,打电话的时序挂断电话电话切断挂断电话通 话 通 话停止振铃停止振铃响应电话电话振铃铃 声拨 号 (3)
拨 号 (7
拨 号 (3)
拨 号 (2)
电话忙音结束拨 号 (8)
电话忙音开始拿起听筒电话线 接电话者打电话者举例,饮料自动售货机 系统 的时序图存量为零找零扣减存量灯亮余额饮料结算选择键 #
选择按纽灯亮金额总够显示总额总额累加投入硬币金额计算器 存量计算器顾客 售货机 选择键 售完灯
2009-7-20 368
功能模型用来描述系统中数据的变换。
传统 DFD + 控制流对象 A 对象 B过程 1 过程 2
数据存储区控制流数据流
2009-7-20 369
基于三个模型的分析步骤
需求陈述
对象建模
动态建模
功能建模
添加操作反复建模
2009-7-20 370
OMT支持整个软件生命周期,
需求分析、系统设计、系统实现、
测试与维护。
2009-7-20 371
OMT支持整个软件生命周期,
1,分析阶段,理解应用问题,建立 对象模型、
动态模型和功能模型，说明对象关联、控制流及数据变换。
2,系统设计阶段,确定 系统框架,考虑并发任务、通讯机制和数据存储策略。
3,对象设计阶段,从实现的角度 细化 分析对象模型、动态模型和功能模型
4,实现阶段,具体代码实现
2009-7-20 372
OMT方法的特点,
开发重点在分析阶段
强调数据结构而不是功能
形式化描述能力强
开发步骤的衔接良好
重复性的开发过程
2009-7-20 373
Yourdon的 OOA方法以类与对象图及对象状态图为辅助工具，建立问题域的五层模型,
OOA模型被划分为五个层次 (五个视图 )
2009-7-20 374
分析阶段由五个活动组成：
(1) 标识类及对象
(2) 标识结构
(3) 标识主题
(4) 定义属性及实例连接
(5) 定义服务及消息连接五个步骤常根据需要交叉进行
OOA的结构 类的边界
Class &object layer
(类及对象层 )
Attribute layer
(属性层 )
Service layer
(服务层 )
Structure layer
(结构层 )
Subject layer
(主题层 )
实例的边界实例连接消息连接主题服务属性
2009-7-20 376
步骤 1,识别类与对象
(1)发现对象主要策略,
考虑问题域?
人员?
组织?
物品?
设备?
事件?
表格结构
考虑系统边界?
人员?
设备?
外系统
考虑系统责任
2009-7-20 377
重点
问题域描述中的 名词,往往是候选的及对象 ;根据问题域结构可提取候选的类及对象 ;
2009-7-20 378
重点
与系统发生作用的 其它系统 和必要的 设备 可作为候选的类及对象 ;
如,打印机等
(分析阶段可不把与实现有关的计算机部件作为候选的类及对象 )
2009-7-20 379
重点
系统必须观测,记忆 的与时间有关的事件 可作为候选的类及对象 ;
如：建立帐户的日期打开一个帐户等
与系统发生交互的 人 及系统必须保留其信息的人,可作为候选的类及对象 ;
如：柜员、储户等
这些人所属的 组织 单位，可作为候选的类及对象 ;
如：总行、分行等
2009-7-20 380
重点
系统必须记忆、且不在问题域约束中的顺序 操作过程 (为了指导人机交互 )
可作为候选的类及对象 ;
如：柜员事务、远程事务等。
其中属性是操作过程名,操作特权及操作步骤的描述 ;
系统需了解掌握的物理位置、办公地点 等可作为候选的类及对象 ;
如,ATM机器、帐户等
2009-7-20 381
(2)审查和筛选
舍弃无用的类
对象的精简?
只有一个属性的对象?
只有一个服务的对象
推迟到 OOD考虑的对象
2009-7-20 382
帐册
@上级系统接口供货员销售事件商品特价商品 计量商品
@收款机商品一览表超市销售管理系统 (对象层 )
2009-7-20 383
步骤 2,定义属性与服务
定义属性
定义服务对象的状态与状态转换图例：栈的状态 /服务对照表
2009-7-20 384
例：栈状态转换图空半满满创建压入 (未满 )
弹出 (未空 )
压入
(报错 )
弹出 (报错 )
弹出 (已空 )
压入弹出压入 (已满 )
2009-7-20 385
定义服务对象行为分类发现服务的策略审查与调整识别对象的主动行为服务的详细说明 (服务解释、消息协议、
消息发送、约束条件、服务流程图 )
超市销售管理系统 (特征层 )
帐册前班节余销售事件表收入累计上交款本班节余接班计帐报帐交班
@上级系统接口帐目目册
@消息发送查帐报帐价格更新种类增删供货员缺货登记表缺货登记供货销售事件收款人购物清单应收款……
销售计划入帐商品编号名称单价架上数量下限售出补充价格更新特价商品开始日期结束日期计量商品
*单价计量单位计价方式
*售出
*补充
*价格更新
@收款机本班收款员开始时间结束时间
@登录售货结帐商品一览表商品目录检索种类增删
2009-7-20 387
建立数据字典为所有模型实体准备一个数据字典,
精确描述每一个对象类,包括,
成员
约束
关联、属性、操作
2009-7-20 388
对象字典举例：
类名 父类 提供的服务 需要的服务帐户
ATM
银行
出纳员
2009-7-20 389
步骤 3,定义结构与连接
初步确定关联
对应于描述性动词或动词短语
需求陈述中隐含
根据问题域知识得出
筛选
完善
2009-7-20 390
步骤 3,定义结构与连接
分析标识对象之间的关系
对象之间的分类关系：一般 -特殊结构
对象之间的组成关系：整体 -部分结构
对象之间的静态联系：实例连接
对象之间的动态关系：消息连接
2009-7-20 391
从一般类发现特殊类公司职员股东姓名身分证号码
……
股份
……
职员工资
……
公司职员姓名身分证号码股份工资
……
…… …… ……
……
？
？
2009-7-20 392
从特殊类发现一般类公司职员股东姓名身分证号码
……
股份
……
职员工资
……
…… ……
……
股东姓名身分证号码股份
…………
职员姓名身分证号码工资
…………
？
2009-7-20 393
收款机类成为可供本领域其它系统复用的领域构件 收款机
A
B
C
现钞收款机
D
E
F
现钞收款机
A
B
C
D
E
F
X
Y
Z Z
X
Y
为支持复用建立结构取消没有特殊属性的特殊类大学生 研究生研究方向指导教师
……
学生姓名学号班级
……
……
研究生研究方向指导教师
……
学生姓名学号班级
……
……
2009-7-20 395
通过增加属性简化一般 -特殊结构人员……
……
男人
……
……
女人
……
……
……
……
美国人
……
……
日本人
……
……
人员性别国籍……
……
中国人
2009-7-20 396
两种结构的变通冷藏车
……
……
汽车
……
……
制冷设备
……
……
冷藏车
……
……
汽车
……
……
制冷设备
……
……
仅用一般
-特殊结构两种结构同 用冷藏车
……
……
汽车
……
……
制冷设备
……
……
仅用整体
-部分结构
2009-7-20 397
用整体 -部分结构实现复用车床
……
……
机床 ……
……
刨床
……
……
起重机 ……
……
电动机 …
………
钻床
……
……
送料车 ……
……
2009-7-20 398
筛选：删除下列关联
已删去的类间的关联
无关或实现关联
瞬时事件
三元关联
派生关联
2009-7-20 399
步骤 4,定义服务及消息连接
分析和认识对象之间在行为上的往来关系
2009-7-20 400
顺序系统中的消息传递主动对象 A
a
被动对象 B
b
被动对象 C
c
被动对象 D
d1 d2
运行开始运行结束服务执行消息发送控制点返回示意
2009-7-20 401
并发系统中的消息传递主动对象 A 主动对象 B
被动对象 D
任务 Task1
线程 Ta
控制线程之间的消息连接控制点返回示意被动对象 C 被动对象 E
控制线程内部的消息连接任务 Task2
线程 Tb
2009-7-20 402
多个控制线程之间的消息与顺序系统中消息的不同之处
(1)并发执行的控制线程之间传送的 消息的不同用途：
向 接收者发出访问请求
向接收者提交数据
向接收者发布通知或事件信息
向接收者传递同步控制信号
(2)消息的同步与异步
(3)接收者对消息的不同响应方式
(4)发送者对消息处理结果的不同期待方式
(5)消息的接收者是否唯一?
定向消息
广播消息
2009-7-20 403
OOA对消息的表示 —消息连接消息连接是 OOA（或 OOD） 模型中对对象之间行为依赖关系的表示识别和表示的主要问题,?
对象之间是否存在消息？
消息是同一线程内部的还是不同线程之间的？
每一种消息是从发送者哪个服务发出的？
由接收者哪个服务响应处理的？
消息是同步还是异步？
发送者 是否等待消息的处理结果？
2009-7-20 404
如何建立消息连接
(1)建立控制线程内部的消息连接基本策略：,服务模拟,
,执行路线追踪,
具体做法：
人为地模拟当前服务的执行，通过考虑需要请求其它对象的服务来发现新消息。
分析该消息的发送者与接收者在执行时是否属于同一控制线程
2009-7-20 405
(2)建立控制线程之间的消息连接对每个控制线程考虑：?
它在执行时是否需要请求其它控制线程中的对象为它提供服务？由哪个对象发出？由哪个对象中的服务处理？
它在执行时是否要向其它控制线程中的对象提供或索取数据？
它在执行时是否将产生对其它控制线程的执行有影响的事件？
各个控制线程的并发执行是否要传递同步控制信号
一个控制线程在何种条件下中止执行？
中止后在何种条件下由其它控制线程用何法唤醒?
2009-7-20 406
(3)对象分布问题及对消息的影响
每台处理机上分布的一组对象中至少应有一个主动对象；
同一台处理机上的对象之间的消息通信既可能是一个控制线程内部的，也可能是不同控制线程之间的。
(关系层,完整的类图 )
帐册前班节余销售事件表收入累计上交款本班节余接班计帐报帐交班
@上级系统接口帐目目册
@消息发送查帐报帐价格更新种类增删供货员缺货登记表缺货登记供货销售事件收款人购物清单应收款
……
销售计划入帐商品编号名称单价架上数量下限售出补充价格更新特价商品开始日期结束日期计量商品
*单价计量单位计价方式
*售出*补充
*价格更新
1 m
商品一览表商品目录检索种类增删
1m
@收款机本班收款员开始时间结束时间
@登录售货结帐
2009-7-20 408
步骤 5,标识主题 (主体 )
Coad/Yourdon方法中主题的概念：
主题是把一组具有较强联系的类组织在一起而得到的类的集合。
2009-7-20 409
主题概念及其用途
主题层是在 OOA基本模型 (类图 )之上建立一个能帮助人们从不同的认识层次来理解系统的补充模型；
主题一种比类和对象抽象层次更高、粒度更大的概念，用以建立系统的高层抽象视图；?
主题有助于指导系统设计者或用户等理解一个大的系统模型,有助于组织一个大项目的工作。
2009-7-20 410
主题概念的特点
是由一组类构成的集合?
一个主题内部的对象类应具有某种意义上的内在联系
描述系统中相对独立的组成部分（如一个子系统）
描述系统中某一方面的事物（如人员、设备）
解决系统中某一方面的问题（如输入输出）?
主题的划分有一定的灵活性和随意性
2009-7-20 411
如何划分主题
把每个结构作为一个主题；
(选取结构中最上层的类作为一主题 )
通过实例连接互相联系的类可划分到一个主题；
把不属于任何结构，也没有实例连接的类作为一个主题。
2009-7-20 412
如何精练主题从 问题域 和 接口复杂性 两方面入手,
使用问题域精练主题,即用整体 /部分结构对问题域进行划分,而不是按功能分解方法划分,
按高内聚低偶合原则,通过使主题间依赖性和交互性最小原则保留能反映子问题域的主题,
主题数目 >7个左右,则进一步精练主题,
2009-7-20 413
何时引入主题依赖于模型自身复杂性
小系统,不需引入主题 ;
中等系统,先标识类及对象,
然后引入主题 ;
大系统,先标识主题,对问题域进行划分,分给不同的任务组
2009-7-20 414
主题层次的控制
中小型系统可只设一层主题，最多不超过两层；
大型系统可只设两层主题，最多不超过三层 。
(关系层,完整的类图 )
帐册前班节余销售事件表收入累计上交款本班节余接班计帐报帐交班
@上级系统接口帐目目册
@消息发送查帐报帐价格更新种类增删供货员缺货登记表缺货登记供货销售事件收款人购物清单应收款
……
销售计划入帐商品编号名称单价架上数量下限售出补充价格更新特价商品开始日期结束日期计量商品
*单价计量单位计价方式
*售出*补充
*价格更新
1 m
商品一览表商品目录检索种类增删
1m
@收款机本班收款员开始时间结束时间
@登录售货结帐
1
1 1
1
33
33
2
2
2
2
2009-7-20 416
第五章 人机界面设计
2009-7-20 417
概念
人机界面（ Human Computer Interface,简称
HCI）通常也称为 用户界面界面设计 主要包括三个方面：
设计软件构件之间的接口
设计模块和其他非人的信息生产者和消费者的界面
设计人（如用户）和计算机间的界面
2009-7-20 418
界面的设计原则
分析用户类型
应用程序和界面分离
一致性
尽量减少用户工作
提供反馈
出错处理和帮助功能
增加可视化图形表示
2009-7-20 419
黄金规则在有关界面设计的著作中，
Theo Mandel创造了 三条 黄金原则,
置用户于控制之下
减少用户的记忆负担
保持界面一致
2009-7-20 420
黄金规则：置用户于控制之下
Mandel定义的一组允许用户操作控制的原则,
以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
提供灵活的交互
允许用户交互可以被中断和撤消
当技能级别增加时可以使交互流水化并允许定制交互
使用户隔离内部技术细节
设计应允许用户和出现在屏幕上的对象直接交互
2009-7-20 421
黄金规则：减少用户的记忆负担
Mandel定义了一组设计原则，使界面能够减少用户记忆负担,
减少对短期记忆的要求
建立有意义的缺省
定义直觉性的捷径
界面的视觉布局应该基于真实世界的隐喻
以不断进展的方式揭示信息
2009-7-20 422
界面举例 MSN
2009-7-20 423
界面举例红心大战缺省值
2009-7-20 424
黄金规则：保持界面一致用户应以一致的方式展示和获取信息
所有可视信息的组织均按照均按照贯穿所有屏幕显示所保持的设计标准
输入机制被约束到有限的集合，在整个应用中被一致地使用
从任务到任务的导航机制被一致地定义和实现
2009-7-20 425
帮助保持界面一致性的设计原则
允许用户将 当前任务 放入有意义的语境
在应用系列内保持一致性
如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要改变它
2009-7-20 426
用户友好性设计用户友好性 一般属软件的性能特性，它独立于所有具体功能，却影响着所有功能的重用性。
用户友好性 应体现在与用户有接口的软件特性上。
用户友好性的根本 目的 是为了软件可重用性、可维护性。
2009-7-20 427
用户友好性的标志
可操作性
健壮性
易学习性
可扩展性
2009-7-20 428
界面设计模型
软件工程师创建的 设计模型
（ design model）
人员工程师创建的 用户模型
（ user model）
终端用户对未来 系统的假想 （ sysytem
perception或 user’s model）
系统实现后得到的 系统映象 （ sysytem
image）
四种模型可能相差甚远，
界面设计人员的任务就是消除这些差距，导出一致的界面表示设计用户界面要考虑四种模型：
2009-7-20 429
用户界面设计过程用户界面设计过程包括四种不同的框架,
用户、任务和环境分析及建模
界面设计
界面构造
界面确认
2009-7-20 430
用户分析
偶然型
生疏型
熟练型
专家型
新手
对系统有了解的中级用户
对系统有了解的经常用户用户类型,
2009-7-20 431
影响用户行为特性的因素
人 -机匹配性
人的固有技能
人的固有弱点
用户的知识经验
用户对系统的期望和态度
2009-7-20 432
用户对计算机系统的要求
让用户灵活地使用
适应不同类型用户
系统的行为及效果对用户透明
用户对系统的期望和态度
提供联机帮助功能
人机交互尽可能和人际通信相似
2009-7-20 433
用户技能方面的使用需求
应让系统去适应用户
使用易于理解、掌握的准自然语言
一致性的系统设计
用户对系统的期望和态度
能通过系统学习
系统提供演示及范例
2009-7-20 434
用户习性方面的使用需求
系统应让用户有耐心
系统应很好地对付人的易犯错误
系统应对不同用户提供不同交互方式
2009-7-20 435
用户经验、知识方面的使用需求
系统应能让未经专门训练的用户使用
系统能对不同经验用户做出不同反应
提供同一系统的一致性，建立标准化人 -
机界面
系统必须适应用户在应用领域的知识变化，提供动态的自适应的设计
2009-7-20 436
用户对系统的期望方面的要求
用户界面应提供形象、生动、美观的布局显示和操作环境
系统处理问题应尽可能简单，提供学习机制
系统应对不同用户提供不同交互方式
2009-7-20 437
人 -机界面的交互方式菜单界面按显示形象分类,
正文菜单
图标菜单
正文图标混合菜单按屏幕位置和操作风格分类,
固定
浮动
下拉式
嵌入式菜单举例图标式菜单 菜单条弹出式菜单弹出式帮助文本
2009-7-20 439
菜单举例下拉式菜单、瀑布式菜单瀑布式菜单
2009-7-20 440
菜单举例
2009-7-20 441
菜单举例
2009-7-20 442
菜单举例
2009-7-20 443
对话对话形式,
(1)必须回答式
(2)无需回答式
(3)警告式对话实现方式,
(1)标准对话
(2)定做式对话
2009-7-20 444
界面其他元素
3,功能键
4,图符界面
5,填表界面
6,命令语言界面
7,查询语言界面
8,自然语言界面
2009-7-20 445
控制界面的设计
(1)用控制对话选择操作命令
(2)用菜单界面进行控制
(3)用功能键定义操作命令
(4)用图标表示对象或命令
2009-7-20 446
界面设计过程的步骤
建立任务的目标和意图
为每个目标和意图制定特定的动作序列
按在界面上执行的方式对动作序列进行规约
指明系统状态，即执行动作时的界面表现
定义控制机制，即用户可用的改变系统状态的设备和动作
指明控制机制如何影响系统状态
指明用户如何通过界面上的信息解释系统状态
2009-7-20 447
定义界面对象和动作为创建描述图符的图形设计和放置、描述性屏幕文字的定义、窗口的规约和命名、菜单项的规约的屏幕布局提供基础。
响应时间、命令和动作结构、错误处理和帮助设施等设计问题应该在精化设计模型时考虑。
2009-7-20 448
导航方式线性层次
2009-7-20 449
导航方式网络式混合式
2009-7-20 450
数据输入界面设计数据输入的规则
明确的输入
明确的动作
明确的取消
确认删除
提供反馈
允许编辑
提供复原（ Undo）
自由格式
提示输入的范围
2009-7-20 451
数据显示界面设计数据显示的规则
只显示必要的数据
在一起使用的数据显示在一起
显示出的数据应与用户执行的任务有关
每一屏数据的数量不应超过整个屏幕面积的 30%
屏幕布局规则
尽量少用代码和缩写
多个显示画面，应建立统一格式
提供明了的标题、标栏及其它提示信息
遵循用户习惯
采用颜色、字符大小、下划线、不同字体等方式强化重要数据
2009-7-20 452
界面举例
2009-7-20 453
界面举例
2009-7-20 454
界面举例
2009-7-20 455
界面举例
2009-7-20 456
第五章 软件测试
2009-7-20 457
编程阶段的基本概念 （ page 126）
编程的定义
编程的目标
什么是程序可读性
2009-7-20 458
程序设计语言 （ page 127）
程序设计语言的种类
BASIC
COBOL
FORTRAN
PASCAL
C
LISP
其他语言
2009-7-20 459
选择语言 （ page 130）
项目的应用领域
算法和计算复杂性
软件的执行环境
性能因素
数据结构的复杂性
软件开发人员的水平
2009-7-20 460
SP方法和编程 （ page 130）
SP方法帮助产生简单清晰的程序
程序内部文档（ Note ）
序言性注释
描述性注释
编程风格
变量名的选择
表达式的书写
2009-7-20 461
程序的效率 （ Note 54）
效率主要指处理机时间和存储器容量两个方面。
可从三个方面讨论效率问题：
程序运行时间
存储器效率
输入 /输出的效率
2009-7-20 462
第六章 软件测试
2009-7-20 463
基本概念
软件开发过程必须伴有质量保证活动。
软件测试是软件质量保证的关键元素，
代表了规约、设计和编码的最终检查。
2009-7-20 464
动态测试方法
(1)选取定义域有效值,或定义域外无效值,
(2)对已选取值决定 预期的结果
(3)用选取值执行程序
(4)执行结果 与 (2)结果相比,
不吻和程序有错,
2009-7-20 465
测试用例设计选择测试用例是软件测试员最重要的一项工作。
测试用例的属性,
属性 描述
name 测试用例的名称
location 可执行的完全路径名
input 输入数据或命令
oracle 与测试输入相比较的期待测试结果
log 测试生产的输出
2009-7-20 466
软件测试信息流软件配置测试测试配置测试工具结果分析排错可靠性分析测试结果错误预期结果出错率改正的软件预测的可靠性需求规格说明书软件设计说明书被测源程序测试计划测试用例
(测试数据 )
测试驱动程序
2009-7-20 467
测试活动和相关工作产品项目协议对象设计 客户开发人员 用户集成策略系统分解功能性需求非功能性需求单元测试集成测试结构测试功能测试性能测试用户手册验收测试安装测试现场测试日常操作
2009-7-20 468
测试设计中需要考虑的 22种测试类型
黑盒测试
白盒测试
单元测试
累计综合测试
集成测试
功能测试
系统测试
端到端测试
健全测试
衰竭测试
接受测试
负载测试
强迫测试
性能测试
可用性测试
安装 /卸载测试
恢复测试
兼容测试
安全测试
比较测试
Alpha测试
Beta测试
2009-7-20 469
测试的方法与技术软件测试的策略和方法静态测试方法动态测试方法人工测试方法计算机辅助静态分析方法白盒测试方法黑盒测试方法
2009-7-20 470
动态黑盒测试 — 闭着眼睛测试软件软件输入不深入代码细节的测试方法称为动态黑盒测试。
软件测试员充当客户来使用它。
输出
2009-7-20 471
动态白盒测试 —带上 X光眼镜测试
3581322.293419985680302829734315
250*(1+0.015)*((1+0.015)^360-1)/0.015 250*(1+0.015)*((1+0.015)^360-1)/0.015
假如知道一个盒子包含一台计算机,而另一个盒子是人用纸笔计算,就会选择不同的测试用例了解软件的运作方式会影响测试手段
2009-7-20 472
黑盒测试又称,功能测试数据驱动测试基于规格说明书的测试
2009-7-20 473
白盒测试又称,开盒测试结构测试玻璃盒测试基于覆盖的测试,
根据被测程序的逻辑结构设计测试用例 ;
力求提高测试覆盖率 ;
2009-7-20 474
黑盒测试与白盒测试比较黑盒测试 是从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例,是根据程序 外部特征 进行测试。
白盒测试 是根据程序 内部逻辑结构 进行测试。
2009-7-20 475
黑盒测试与白盒测试优缺点比较黑盒测试 白盒测试优点缺点性质
① 适用于各阶段测试
②从产品功能角度测试
③容易入手生成测试数据
① 可构成测试数据使特定程序部分得到测试
②有一定的充分性度量手段
③可或较多工具支持
① 某些代码得不到测试
②如果规格说明有误，
则无法发现
③不易进行充分性测试
① 不易生成测试数据 (通常 )
② 无法对未实现规格说明的部分进行测试
③工作量大，通常只用于单元测试，有应用局限是一种 确认 技术，回答
,我们在构造一个正确的系统吗？,
是一种 验证 技术，回答
,我们在正确 地构造一个系统吗？,
2009-7-20 476
黑盒测试与白盒测试不论黑盒还是白盒测试都 不能进行穷尽测试,所以软件测试不可能发现程序中存在的所有错误,因此需精心设计测试方案,力争尽可能少的次数,测出尽可能多的错误,
2009-7-20 477
黑盒测试与白盒测试能发现的错误
C BA
D
-只能用黑盒测试发现的错误A
-只能用白盒测试发现的错误
-两种方法都能发现的错误
-两种方法都不能发现的错误
B
C
D
2009-7-20 478
白盒测试的测试用例设计逻辑覆盖法
(1)语句覆盖
(2)判定覆盖
(3)条件覆盖
(4)判定 /条件覆盖
(5)条件组合覆盖
(6)路径覆盖
(7)点覆盖
(8)边覆盖
2009-7-20 479
举例：
例,PROCEDURE SAMPAL
(A,B,REAL； VAR X,REAL);
BEGIN
IF (A>1) AND (B=0)
THEN X:=X/A
IF (A=2) OR (X>1)
THEN X:=X+1
END;
2009-7-20 480
举例：
开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
2009-7-20 481
(1)语句覆盖
使程序中每个语句至少执行一次
2009-7-20 482
语句覆盖开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
2009-7-20 483
语句覆盖只需设计一个测试用例,
输入数据,A=2,B=0,X=4
即达到了语句覆盖 ;
语句覆盖是 最弱 的逻辑覆盖
2009-7-20 484
(2)判定覆盖 (分支覆盖 )
使每个判定的真假分支都至少执行一次
2009-7-20 485
判定覆盖 (分支覆盖 )
开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
2009-7-20 486
例,可设计两组测试用例,
A=3,B=0,X=3 可覆盖 c,d分支
A=2,B=1,X=1 可覆盖 b,e分支两组测试用例可覆盖所有判定的真假分支判定覆盖仍是 弱 的逻辑覆盖
2009-7-20 487
(3)条件覆盖使每个判定的每个条件的可能取值至少执行一次
2009-7-20 488
条件覆盖第一判定表达式,
设 条件 A>1 取真 记为 T1
假 T1
条件 B=0 取真 记为 T2
假 T2
第二判定表达式,
设 条件 A=2 取真 记为 T3
假 T3
条件 X>1 取真 记为 T4
假 T4
2009-7-20 489
条件覆盖开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
满足条件,T1,T1,
T2,T2
T3,T3
T4,T4
2009-7-20 490
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
1 0 3 abe T1,T2,T3,T4 b,e
2 1 1 abe T1,T2,T3,T4 b,e
两个测试用例 覆盖了四个条件八种可能取值 。
未覆盖 c,d分支,不满足判定覆盖的要求,
条件覆盖不一定包含判定覆盖判定覆盖也不一定包含条件覆盖
2009-7-20 491
(4)判定 /条件覆盖选取足够多的测试用例,使判断中的每个条件的所有可能取值至少执行一次,
同时每个判断本身的所有可能判断结果至少执行一次,
2009-7-20 492
判定 /条件覆盖开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
满足条件,T1,T1,
T2,T2
T3,T3
T4,T4
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
2 0 4 ace T1,T2,T3,T4 c,e
2 1 1 abd T1,T2,T3,T4 b,d
能同时满足判定、条件两种覆盖标准。
取值。
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
2 0 3 ace T1,T2,T3,T4 c,e
2 1 1 abe T1,T2,T3,T4 b,e
1 0 3 abe T1,T2,T3,T4 b,e
1 1 1 abd T1,T2,T3,T4 b,d
2009-7-20 495
(5)条件组合覆盖所有可能的条件取值组合至少执行一次
A>1,B=0
A>1,B≠0
A≯ 1,B=0
A≯ 1,B≠0
A=2,X>1
A=2,X≯ 1
A≠2,X>1
A≠2,X≯ 1
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
2 0 4 ace T1,T2,T3,T4 c,e
2 1 1 abe T1,T2,T3,T4 b,e
1 0 2 abd T1,T2,T3,T4 b,d
1 1 1 abd T1,T2,T3,T4 b,d
2009-7-20 497
(6)路径覆盖覆盖每一个可能的路径测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
1 1 1 abd T1,T2,T3,T4 b,d
1 1 2 abe T1,T2,T3,T4 b,e
3 0 1 acd T1,T2,T3,T4 c,d
2 0 4 ace T1,T2,T3,T4 c,e
2009-7-20 498
基本路径测试法
通过分析由控制构造的环路的复杂性，
导出基本路径集合，从而设计测试用例，
保证这些路径至少通过一次。
2009-7-20 499
黑盒测试的测试用例设计等价类划分法把所有可能的输入数据 (有效的和无效的 )划分成若干个等价的子集 (称为等价类 ),使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同,
可从每个子集中选取一组数据来测试程序
2009-7-20 500
例,某报表处理系统要求用户输入处理报表的日期，日期限制在 2001年 1
月至 2005年 12月，即系统只能对该段期间内的报表进行处理，如日期不在此范围内，则显示输入错误信息。
系统日期规定由年、月的 6位数字字符组成，前四位代表年，后两位代表月。
如何用等价类划分法设计测试用例,
来测试程序的日期检查功能？
2009-7-20 501
如何划分等价类？
有效等价类 (合理等价类 )
无效等价类 (不合理等价类 )
划分等价类的标准：
覆盖
不相交
代表性
2009-7-20 502
划分等价类的规则 （ page 157）
(1)如果输入条件规定了取值范围，
可定义一个有效等价类和两个无效等价类。
例 输入值是学生成绩，范围是 0～ 100
0 100
有效等价类
1≤ 成绩 ≤ 100
无效等价类成绩 >100
无效等价类成绩 <0
～
2009-7-20 503
划分等价类的规则：
(2)如果输入条件代表集合的某个元素，则可定义一个有效等价类和一个无效等价类。
2009-7-20 504
划分等价类的规则
(3)如规定了输入数据的一组值,且程序对不同输入值做不同处理,
则每个允许的输入值是一个有效等价类,并有一个无效等价类
(所有不允许的输入值的集合 )。
例：输入条件说明学历可为,专科,本科,
硕士,博士 四种之一,则分别取这四种这四个值作为 四个有效等价类,另外把四种学历之外的任何学历作为无效等价类
2009-7-20 505
用等价类划分法设计测试用例步骤
(1)形成等价类表,每一等价类规定一个唯一的编号；
(2)设计一测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类,
重复这一步骤,直到所有有效等价类均被测试用例所覆盖；
(3)设计一新测试用例,使其只覆盖一个无效等价类,重复这一步骤直到所有无效等价类均被覆盖；
2009-7-20 506
划分等价类的规则
(4)如果规定了输入数据必须遵循的规则,可确定一个有效等价类 （ 符合规则 ） 和若干个无效等价类 （ 从不同角度违反规则 )。
(5)如已划分的等价类各元素在程序中的处理方式不同,则应将此等价类进一步划分成更小的等价类 。
2009-7-20 507
第一步：等价类划分输入等价类 有效等价类 无效等价类报表日期的类型及长度 3位数字字符 (1)
有非数字字符 (4)
少于 6个数字字符 (5)
多于 6个数字字符 (6)
年份范围 在 2001～ 2005之间 (2) 小于 2001 (7)大于 2005 (8)
月份范围 在 1～ 12之间 (3)
“报表日期,输入条件的等价类表小于 1 (9)
大于 12 (10)
2009-7-20 508
第二步为有效等价类设计测试用例对表中编号为 1,2,3的 3个有效等价类用一个测试用例覆盖,
测试数据 期望结果 覆盖范围
200105 等价类 (1)(2)(3)输入有效
2009-7-20 509
第三步：为每一个无效等价类设至少设计一个测试用例测试数据 期望结果 覆盖范围
001MAY 等价类 (4)输入无效
20015 等价类 (5)输入无效
2001005 等价类 (6)输入无效
200005 等价类 (7)输入无效
200805 等价类 (8)输入无效
200100 等价类 (9)输入无效
200113 等价类 (10)输入无效不能出现相同的测试用例本例的 10个等价类至少需要 8个测试用例例,对招干考试系统“输入学生成绩”
子模块设计测试用例招干考试分三个专业,准考证号第一位为专业代号,如,1-行政专业,
2-法律专业,
3-财经专业,
行政专业准考证号码为,110001～ 111215
法律专业准考证号码为,210001～ 212006
财经专业准考证号码为,310001～ 314015
例,准考证号码的等价类划分有效等价类,
(1) 110001 ～ 111215
(2) 210001 ～ 212006
(3) 310001 ～ 314015
无效等价类,
(4) -? ～ 110000
(5) 111216 ～ 210000
(6) 212007 ～ 31000
(7) 314016 ～ +?
例,计算给定月份中天数的方法接口
(java):
Class MyGregorianCalender{
……
public static in getNumDaysInMonth(int
month,int year){…}
……
}
getNumDaysInMonth( )方法有两个参数,月和年,年份的有效输入是从 0到 maxInt.
课名,软 件 工 程主 讲,谢 明 志
Email,tommyshell@163.com
使用教材：软件系统开发技术（修订版）
潘锦平 施小英 姚天昉西安电子科技大学出版社
2009-7-20 2
第一章 软件工程概述
2009-7-20 3
§ 1.1 软件工程的背景和历史
1968年由 NATO (北大西洋公约组织 )在德国
Garmish召开的学术会议上,Feitz Bauer首先提出了,软件工程,概念。
2009-7-20 4
软件工程与编程
前者是一门学科，一种科学理论来指导软件系统开发，标准化，
自动化的过程
考虑如何分解一个系统，以便各人分工开发；考虑如何说明每个部分的规格要求；
怎样才能易于维护
单纯的代码编写
是软件工程发展的前身
是软件工程中占据很少时间和空间的一部分
2009-7-20 5
计算机学科的发展计算机科学
(CS)
计算机科学
(CS)
计算机工程
(CE)
软件工程
(SE)
信息系统
(IS)
计算学科
(computing discipline)
2009-7-20 6
60年代以来
工厂管理
病人监护
工资统发
图书馆管理
机票预定
学籍管理早期 第二阶段 第三阶段 第四阶段
面向批处理?多用户?分布式系统?强大的桌面系统
有限的分布?实时?嵌入,智能,?面向对象技术
自定义软件?数据库?低成本硬件?专家系 统
软件产品?消费者的影响?人工神经网络
并行计算
网络计算机
1950 1960 1970 1980 1990 2000
Evolution of software#
2009-7-20 8
为什么发展如此之快
不准确的时间和金钱的估算
软件质量的低下
相对硬件产品开发软件开发费用的增加
维护、增强软件系统的必要性
硬件价格大幅度下降
2009-7-20 9
软件技术面临的问题
规模
复杂性
生产率
Windows95有 1000万行代码
Windows2000有 5000万行代码例：
Exchange2000和 Windows2000开发人员结构
Exchange2000 Windows2000
项目经理 25人 约 250人开发人员 140人 约 1700人测试人员 350人 约 3200人
2009-7-20 11
,人月神话,焦油坑
史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、
猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
2009-7-20 12
软件危机的主要特征
软件开发周期大大超过规定日期 ;
软件开发成本严重超标 ;
软件质量难于保证。
2009-7-20 13
软件工程的定义
Fritz Bauer在 NATO会议上给出的定义：
,软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而确立和使用的健全的工程原理（方法）。,
2009-7-20 14
软件工程的定义（ 2）
IEEE【 IEE83】 给出的软件工程定义：
,软件工程是开发、运行、
维护和修复软件的系统方法。,
2009-7-20 15
软件工程的定义（ 3）
IEEE【 IEE93】 给出了一个更加综合的定义：
,将系统化的、规范的、可度量的方法应用于软件的开发、
运行和维护的过程，即将工程化应用于软件中。,
软件工程是一门交叉学科软件工程的主要研究内容
软件开发技术,软件开发方法学软件开发过程软件工具和软件工程环境
软件工程管理,软件管理学软件经济学软件心理学软件工程所包含的内容不是一成不变的，
随着人们对软件系统的研制开发和生产的理解。
应用发展的眼光看待它。
2009-7-20 17
软件工程 —一种层次化技术工具方法过程质量焦点
Software engineering layers
软件工程三个要素,方法、工具、过程
2009-7-20 18
软件工程与一般工程的差异
软件是逻辑产品而不是实物产品
软件的功能依赖于硬件和软件的运行环境以及人们对它的操作
软件设计的复杂性
软件特征,功能的多样性实现的多样性能见度低软件结构合理性差
智力密集及知识产权保护
2009-7-20 19
软件工程知识结构
2001年 5月 ISO/IEC JTC 1（ ISO和 IEC的第一联合技术委员会）发布了,SWEBOK指南 V0.95(试用版 )》
SWEBOK把软件工程学科的主体知识分为 10个知识领域。
2009-7-20 20
软件工程知识结构
软件需求
软件设计
软件构造
软件测试
软件维护
软件配置管理
软件工程管理
软件工程过程
软件工程工具和方法
软件质量
2009-7-20 21
,软件工程”课程与其它软件专业课的区别
(1) 立足于系统的整体。
(2) 讲授系统分析、系统设计、
测试及维护的理论和方法。
(3) 构筑一个软件系统，实践软件开发全过程。
2009-7-20 22
,软件工程”课程教学的目标
转变对软件的认识：
上升程序 系统
转变思维定式：
上升程序员 系统工程师
(系统分析员 )
2009-7-20 23
软件产品的标准化软件开发过程的标准化
2009-7-20 24
软件的工业化生产过程应具备的特点：
明确的工作步骤
详细具体的规范化文档
明确的质量评价标准
,一个好的工业，应有一套良好的标准来配套”
2009-7-20 25
软件工程技术的两个特点
强调规范化
强调文档化
2009-7-20 26
§ 1.2 软件和软件生命期模型
(Software Life Cycle)
软件产品或软件系统从设计、投入使用到被淘汰的全过程。
2009-7-20 27
软件生存期的阶段划分
(1)可行性研究与计划
(2)需求分析
(3)总体设计
(4)详细设计
(5)实现
(6)集成测试
(7)确认测试
(8)使用和维护成长期（开发期）
怀孕期（计划期 ）
成年期（运行期）
2009-7-20 28
新的国际标准定义的软件生存过程（ 1995
ISO/IEC 12207）
软件生存期过程支持过程 组织过程主要过程获取过程供应过程开发过程运行过程维护过程文档编制过程配置管理过程质量保证过程验证过程确认过程联合评审过程审核过程问题解决过程管理过程基础设施过程改进过程培训过程
2009-7-20 29
软件工作的范围只考虑编写程序涉及整个软件生存周期扩展到
2009-7-20 30
软件开发模型是软件开发全部过程、活动和任务的 结构框架 。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。 软件开发模型也常称为：
软件过程模型软件生存周期模型软件工程范型软件开发模型可行性研究与计划需求分析设计编码运行维护测试定义阶段开发阶段维护阶段瀑布模型 (Waterfall Model)
2009-7-20 32
开发软件不仅仅是编程开发维护设计编写模块测试联合测试分析
2009-7-20 33
按照传统瀑布模型开发软件的特点
1.阶段间具有顺序性和依赖性。
2.推迟实现的观点。
3.每个阶段必须完成规定的文档 ;
每个阶段结束前完成文档审查,
及早改正错误。
2009-7-20 34
原型模型 （快速原型模型 ）
原型范型用户测试运行原型建造 /修改原型听取用户意见采用原型模型的软件生存周期分析定义系统需求生成原型系统设计程序设计编码测试运 行和维护原型化含原型化的软件生存期
2009-7-20 36
§ 1.3 软件质量的评价
成功的标准,
用户在 用用户可很容易做完要做的事
失败的根本原因：
开发人员写出的东西达不到用户要求 (人的问题,技术问题 )
2009-7-20 37
质量与生产率
质量是软件需求方最关心的问题，用户即使不图物美价廉，也要求个货真价实
质量与生产率之间有着内在的联系，高生产率必须以质量合格为前提
质量与生产率的提高就指望程序员与程序经理
非得在质量与生产率之间分个主次不可，那么应该是质量第一，生产率第二
2009-7-20 38
质量与生产率（ 2）
质量直接体现在软件的每段程序中，高质量自然是开发人员的技术追求，也是职业道德的要求
高质量对所有的用户都有价值，而高生产率只对开发方有意义
如果一开始就追求高生产率，容易使人急功近利，留下隐患
2009-7-20 39
不贪污的官就是好官吗
,运行正确,的程序就是高质量的程序吗？
也许运行速度很低并且浪费内存；也许代码写得一塌糊涂
2009-7-20 40
软件的质量因素
软件的质量因素很多，如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等等（还可以列出十几个）
一般说来倾向于可维护性、可靠性、可理解性和效率
2009-7-20 41
软件质量因素分类和武学分类正确性与精确性易用性可理解性与简洁性性能与效率可复用性与可扩充性少林派、武当派华山派昆仑派峨嵋派崆峒派
2009-7-20 42
正确性与精确性
机器不会主动欺骗人，软件运行不正确或者不精确一般都是人造成的
需求分析错了，那么对客户而言这个软件也存在错误
如果软件没有 100% 地按需求规格执行，那么这个软件也存在错误
程序员要为,正确,,,精确,四个字竭尽全力
2009-7-20 43
性能与效率
用户都希望软件的运行速度高些（高性能），
并且占用资源少些（高效率）
旧社会地主就是这么对待长工的：干活要快点，
吃得要少点
通过优化算法、数据结构和代码组织来提高软件系统的性能与效率优化的关键
工作是找出限制性能与效率的,瓶颈,
2009-7-20 44
易用性
导致软件易用性差的根本原因是开发人员犯了
,错位,的毛病：他以为只要自己用起来方便，
用户也一定会满意
当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用,友好,来评价易用性
2009-7-20 45
可理解性与简洁性 （ Note 1）
开发人员只有在自己思路清晰时才可能写出让别人能理解的程序
编程时还要注意不可滥用技巧，应该用自然的方式编程
简洁是一种美
如果把学术文章写得很简洁，让人很容易理解，
它往往中不了
2009-7-20 46
可复用性与可扩充性
一种方式是原封不动地使用现成的软件构件
一种方式是对现成的软构件进行必要的扩充后再使用
可复用性好的程序一般也具有良好的可扩充性
2009-7-20 47
可行性研究与计划需求分析设计编码运行维护测试测试已经开始返回上级，再 …,.
瀑布模型的质量保障体系
2009-7-20 48
小结 （ Note 2）
软件的高质量主要是设计出来的
不是,管,出来的
更不能依赖质量检查。
2009-7-20 49
第二章可行性研究与计划
2009-7-20 50
系统流程图 （ Note 3）
输入单据磁盘文件处理输出单据
2009-7-20 51
数据流程图数据源点和终点变换数据的加工文件数据逻辑关系符号：与、或、异或
2009-7-20 52
§ 2.1可行性研究基本概念
可行性研究的任务,
可行性研究的主要任务是,了解客户的要求及现实环境，从技术、经济和社会因素等三方面研究并论证本软件项目的可行性，编写可行性研究报告，制定初步项目开发计划。,
2009-7-20 53
可行性研究的内容
(1)技术可行性
(2)经济可行性
(3)操作可行性
(4)社会可行性 (法律可行性 )
(5)抉择
2009-7-20 54
技术可行性 (Note 4)
度量一个特定技术信息系统解决方案的实用性及技术资源的可用性考虑的问题
开发风险分析
资源分析
相关技术的发展（现有技术能否实现新系统，技术难点、建议采用技术的先进性）
2009-7-20 55
经济可行性度量系统解决方案的性能价格比考虑的问题成本 /效益分析
有形成本、效益
无形成本、效益价值和成本的关系
质量与价值、成本的关系
价值 /成本的均衡
2009-7-20 56
经济可行性考虑的问题 (Note 5)
成本和效益的估算
开发成本的估算
开发效益的估算
运行成本的估算
运行效益的估算
2009-7-20 57
成本分析
代码行技术
（ page 19）
任务估算技术
（ page 20）
总成本、总人力相对误差在 内
Putnam估算模型
（ page 21 ）
COCOMO模型比较复杂
20%?
2009-7-20 58
效益分析
系统的经济效益＝使用新系统增加收入＋使用心系统可以节省的运行费用
总的效益和软件生存周期有关
货币的时间价值（ page23）
投资回收期（ page23）
投资回收率（ page23）
纯收入（ page23）
投资回收率
2009-7-20 59
系统开发和每年运行费用举例
1.系统开发费用（一次）
.2名系统分析员 (450小时 /名,45美元 /小时 ) $40,500
.5名系统开发人员 (275小时 /名,36美元 /小时 )$49,500
.1名数据库管理员 (30小时 /名,42美元 /小时 ) $1,260
.2名技术写作者 (120小时 /名,25美元 /小时 ) $6,000
.1名秘书 (160小时 /名,15美元 /小时 ) $2,400
2009-7-20 60
系统开发和每年运行费用举例
,1名数据通讯专家 (60小时 /名,42美元 /小时 )
$2,400
2名在转换期间数据输入人员
$49,500
(40小时 /名,12美元 /小时 )
2009-7-20 61
系统开发和每年运行费用举例培训：
三天的开发人员内部培训课程 $7,000
30个用户，三天的内部培训课程 $10,000
物资：
复印 $500
磁盘、纸张等消耗品 $650
2009-7-20 62
系统开发和每年运行费用举例购买硬件、软件：
20台工作站 Windows软件 $1,000
20台工作站内存升级 $8,000
网络软件 $17,500
20台工作站办公软件产品 $20,000
系统开发总费用 $161,670
2009-7-20 63
系统开发和每年运行费用举例
2.年运行费用（每年）
人员：
维护程序员 /分析员 (250小时 /年,42美元 /小时 )
$10,500
网络管理员 (300小时 /年,50美元 /小时 ) $15,000
购买硬件、软件升级：
硬件 $5,000
软件 $6,000
物资和杂项 $3,500
每年总运行费用 $40,000
2009-7-20 64
操作可行性
用户使用可能性
时间进度可行性
组织和文化上的可行性
2009-7-20 65
社会可行性 (法律可行性 )
开发项目是否会在社会上或政治上引起侵权、破坏或其它责任问题
2009-7-20 66
可行性研究计划的完成
可行性研究计划
2009-7-20 67
§ 2.3 可行性研究的步骤 （ page15）
(1)复查确认系统目标、规模
(2)研究正使用系统工作流程
(3)导出新系统高层逻辑模型
(4)重新定义问题
(5)导出和评价供选择的方案
(6)推荐可行的方案
(7)草拟开发计划
(8)编写可行性研究报告，送审
2009-7-20 68
第三章 需求分析和规格说明
2009-7-20 69
§ 3.1 为什么需要需求分析
开发人员往往急于求成
希望对开发进行指导
希望开发人员对用户的要求理解
希望用户理解开发人员
测试部门有理可依
2009-7-20 70
需求分析的任务准确地 定义 未来系统的目标，确定为了满足用户的需求系统必须做什么。用
<需求规格说明书 > 规范的形式准确地表达用户的 需求 。
2009-7-20 71
什么是用户需求
思考、涉及的几个问题
如何识别、获取需求?
你能够采取何种手段与用户进行交流沟通?
何为需求建模?
你如何理解模型与建模?
2009-7-20 72
软件需求分析的几个阶段
问题分析
问题评估和方案综合
建模
规约
复审系统分析员的主要 焦点 是,做什么
（ what）,,不是,怎样做（ how）,
2009-7-20 73
需求获取面临的挑战 (Note 6)
客户说不清楚需求
需求易变性
问题的复杂性和对问题空间理解的不完备性与不一致性
2009-7-20 74
§ 3.2 需求获取的常用方法 （ Note 7）
建立分析小组领域专家,主角系统分析员：导演
客户访谈
问题分析与确认某出版社系统调查表编号 提出问题
1 您在哪个部门工作？
2 出版业务流程是什么？
3 您每日都处理那些文件、数据、报表？
4 工作中手工处理特别麻烦的事情是什么？
5 工作中手工处理什么问题解决不了？影响效率的问题有哪些？
6 您认为提高工作效率，节省工作时间，减轻工作强度可采取哪些办法？
某出版社系统调查表编号 提出问题
7 您的部门需要成本核算和统计的内容有哪些？
8 您的部门采用计算机管理工作情况如何？
9 如何改进业务流程使之更合理？
10 哪些问题是目前传统手工方法根本无法解决的？
11 出版社计算机管理信息系统需要解决什么问题？
2009-7-20 77
听一个故事 （ Note 8）
主人公：
C o n t o s o制药公司的高级管理长官
Gerhard
C o n t o s o公司的信息系统开发小组的新管理员 Cynthia
内容：
客户的需求观
2009-7-20 78
谁是客户
客户是指直接或间接从产品中获得利益的个人或组织
软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者 ( s
t a k e h o l d e r )或是获得产品所产生的结果的人。
2009-7-20 79
客户与开发人员之间的合作关系
（ Note 10）
高质量的需求来源于客户与开发人员之间有效的交流与合作
通常，开发人员与客户或客户代理人成为一种对立关系
2009-7-20 80
软件客户需求权利书（ 1） （ Note 11）
客户有如下权利：
1,要求分析人员使用符合客户语言习惯的表达。
2,要求分析人员了解客户系统的业务及目标。
3,要求分析人员组织需求获取期间所介绍的信息，
并编写软件需求规格说明。
4,要求开发人员对需求过程中所产生的工作结果进行解释说明。
5,要求开发人员在整个交流过程中保持和维护一种合作的职业态度。
2009-7-20 81
软件客户需求权利书（ 2） (Note 12)
6,要求开发人员对产品的实现及需求都要提供建议，拿出主意。
7,描述产品使其具有易用、好用的特性。
8,可以调整需求，允许重用已有的软件组件。
9,当需要对需求进行变更时，对成本、影响、得失（ t r a d e - o ff）有个真实可信的评估。
10,获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。
2009-7-20 82
软件客户需求义务书 （ 1） (Note 13)
客户有下列义务：
1,给分析人员讲解业务及说明业务方面的术语等专业问题。
2,抽出时间清楚地说明需求并不断完善。
3,当说明系统需求时，力求准确详细。
4,需要时要及时对需求做出决策。
5,要尊重开发人员的成本估算和对需求的可行性分析。
2009-7-20 83
软件客户需求义务书（ 2） （ Note 14）
6,对单项需求、系统特性或使用实例划分优先级。
7,评审需求文档和原型。
8,一旦知道要对项目需求进行变更，要马上与开发人员联系。
9,在要求需求变更时，应遵照开发组织确定的工作过程来处理。
10,尊重需求工程中开发人员采用的流程（过程）。
2009-7-20 84
“签约,意味着什么 (Note 15)
客户与开发人员关系中的重要部分
客户代表经常把,签约,看作是毫无意义的
更为重要的是签名是建立在一个需求协议的基线上
与你的重要客户一起讨论权利书和义务书，以达成协议，并付诸实践
2009-7-20 85
高质量的需求过程带来的好处 (Note 16)
开发后期和整个维护阶段的重做的工作大大减少
强调需求质量并不能引起某些人的重视,他们错误地认为在需求上消耗多少时间就会导致产品开发推迟多少时间
将选定系统的需求明确地分配到各软件子系统，
强调采用产品工程的系统方法。这样能简化硬软件的集成
2009-7-20 86
优秀需求具有的特性 (Note 17)
1,完整性
2,正确性
3,可行性
4,必要性
5,划分优先级
6,无二义性
7,可验证性
2009-7-20 87
§ 3.3 需求获取的内容
1.用户需求分类
(1)功能性需求,
定义了系统做什么（描述系统必须支持的功能和过程）
(2)非功能性需求（技术需求）,
定义了系统工作时的特性
（描述操作环境和性能目标）
2009-7-20 88
两类需求包括的内容
(1) 功能
(2) 性能
(3) 环境
(4) 界面
(5) 用户或人 的因素
(6) 文档
(7) 数据
(8) 资源
(9) 安全保密
(10)软件成本消耗与开发进度
(11)质量保证
2009-7-20 89
(1) 功能需求
系统做什么？
系统何时做什么？
系统何时及如何修改或升级？
2009-7-20 90
(2) 性能需求软件开发的技术性指标例如：
存储容量限制
执行速度、相应时间
吞吐量
2009-7-20 91
(3) 环境需求
硬件设备,机型、外设、接口、
地点、分布、温度、
湿度、磁场干扰等
软件,操作系统网络数据库
2009-7-20 92
(4) 界面需求
有来自其它系统的输入吗？
到自其它系统的输出吗？
对数据格式有规定吗？
对数据存储介质有规定吗？
2009-7-20 93
(5) 用户或人的因素
用户类型？
各种用户熟练程度？
需受何种训练？
用户理解、使用系统的难度？
用户错误操作系统的可能性？
2009-7-20 94
(6) 文档需求
需哪些文档？
文档针对哪些读者？
2009-7-20 95
(7) 数据需求
输入、输出数据的格式？
接收、发送数据的频率？
数据的准确性和精度？
数据流量？
数据需保持的时间？
2009-7-20 96
(8) 资源需求
软件运行时所需的数据、软件。
内存空间等资源。
软件开发、维护所需的人力、
支撑软件、开发设备等。
2009-7-20 97
(9) 安全保密要求
需对访问系统或系统信息加以控制吗？
如何隔离用户之间的数据？
用户程序如何与其它程序和操作系统隔离？
系统备份要求？
2009-7-20 98
(10) 软件成本消耗与开发进度需求
开发有规定的时间表吗？
软硬件投资有无限制？
2009-7-20 99
(11) 质量保证
系统的可靠性要求？
系统必须监测和隔离错误吗？
规定系统平均出错时间？
出错后，重启系统允许的时间？
系统变化如何反映到设计中？
维护是否包括对系统的改进？
系统的可移植性？
2009-7-20 100
怎样写需求分析报告
作报告时要先从宏观上讲一、二、三、四、五，
再从细节上讲 A,B,C,D,E。需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题
如图
S = { D1,D2,D3,… Dn }
Di = { P1,P2,P3,… Pm }
Pj = { F1,F2,F3,… Fk }
2009-7-20 101
怎样写需求分析报告
2009-7-20 102
§ 3.4 需求的开发和管理整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适需求工程域的层次分解示意图
2009-7-20 103
需求开发 (Note 18)
问题获取（ e l i c i t a t i o n）
分析 ( a n a l y s i s )
编写规格说明（ s p e c i f i c a t i o n）
验证（ v e r i f i c a t i o n）
2009-7-20 104
知识技能 (Note 19)
绝大部分的软件开发人员都没有接受过高效需求工程所需技能的正规培训
培训需求分析人员所有的开发人员都应接受一个基本的需求工程培训
培训软件需求的用户代表和管理人员参与软件开发的用户代表应接受为期一天左右,关于需求工程的培训，开发管理者和客户管理者也应参加
让开发人员了解应用领域的基本概念组织一些简短的关于客户业务活动、术语、目
标等方面的讨论会以帮助开发人员对应用领域有个基本了解
2009-7-20 105
需求获取 (1)(Note 20)
确定需求开发过程
编写项目视图和范围文档项目视图
将用户群分类并归纳各自特点
选择每类用户的产品代表
建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求
2009-7-20 106
需求获取 (2)(Note 21)
让用户代表确定使用实例
召开应用程序开发联系会议
分析用户工作流程观察用户执行业务任务的过程
确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质量特点
通过检查当前系统的问题报告来进一步完善
可查看需求是否有足够的灵活性以允许重用一些已有的软件组件
2009-7-20 107
需求分析 （ Note 22）
绘制系统关联图。
建立数据字典。
为需求建立模型。
建立用户接口原型。
确定需求优先级。
2009-7-20 108
需求规格说明（ SRS） （ Note 23）
采用原始模板在你的组织中要为编写软件需求文档定义一种标准模板
指明需求的来源
为每项需求注上标号制定一种惯例来为每项需求提供一个独立的可识别的标号或记号
记录业务规范业务规范
创建需求跟踪能力矩阵
2009-7-20 109
需求验证 （ Note 24）
对需求文档进行正式审查
以需求为依据编写测试用例
编写用户手册在需求开发早期即可起草一份用户手册
确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的
2009-7-20 110
需求管理 (Note 25)
确定一个选择、分析和决策需求变更的过程
建立变更控制委员会
评估每项选择的需求变更
跟踪所有受需求变更影响的工作产品
建立需求基准版本和需求控制版本文档
维护需求变更的历史记录记录
跟踪每项需求的状态建立一个数据库
衡量需求稳定性记录基准需求的数量和变更数量
使用需求管理工具商业化的需求管理工具
2009-7-20 111
项目管理 （ Note 26）
选择一种合适的软件开发方法生存周期
项目开发计划的进度安排将会不断改变
发生需求变更时协商项目约定
编写文档和管理与需求相关的风险
跟踪需求工程所耗的工作量
2009-7-20 112
分析编写文档评审，商议基准需求说明需求变更过程管理客户需求市场当前基线 修正后基线市场，
客户，
管理项目环境需求开发与需求管理之间的界限
(Note 27)
2009-7-20 113
§ 3.5 改进需求过程 (Note 28)
软件开发过程的改进有以下两个主要目标：
解决在以前项目或目前项目中遇到的问题。
防止和避免你可能在将来的项目中要遇到的问题。
2009-7-20 114
四条改进软件的原则 (Note 29)
改进过程应该是革命性的、彻底的、连续的、
反复的
人们和组织机构都只有在他们获得激励时才愿意变更
过程变更是面向目标的
将改进活动看作一些小项目
2009-7-20 115
过程改进周期 (Note 30)
评价当前采用的方法指定活动改进计划创建、实验和实施新过程评价结果图：软件开发过程改进的周期发现和建议活动计划新的过程，
实验结果，
获得经验实施情况怎样活动计划的效果如何新过程是否达到预期目标？ 计划下一步的改进周期
2009-7-20 116
§ 3.6 软件需求与风险管理 （ Note 31）
听一个故事：
同样在 C o n t o s o制药公司
主人公
,化学制品跟踪系统”的项目管理人员 D a v e
首席程序员 H e l e n
首席测试员 R a m e s h
内容
需求工程的风险 为何物？
2009-7-20 117
软件风险管理的要素 （ Note 32）
风险管理 就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。风险管理提供了一种标准的方法来指出风险并把风险因素编成文档，评估其潜在的威胁，以及确定减少这些
风险评价（ risk assessment）
风险避免（ risk avoidance）
风险控制（ risk control）
2009-7-20 118
编写项目风险文档 (Note 33)
2009-7-20 119
与需求有关的风险
下面介绍的风险因素是按需求工程中获取、分析、编写规格说明、验证和管理汇总起来的，
并推荐了一些方法用于降低风险发生的可能性或减轻风险发生给项目带来的影响。
这张清单仅仅是一个起点，在你做项目逐渐积累经验过程中，加入你的风险因素清单和减轻风险的策略。使用这里提供的条目来帮助你识别需求风险并采用条件 —结果的格式来书写风险说明。
2009-7-20 120
需求获取 （ Note 34）
1) 产品视图与范围
2) 需求开发所需时间
3) 需求规格说明的完整性和正确性
4) 对革新产品的需求
5) 明确非功能需求
6) 客户赞同产品需求
7) 未加说明的需求
8) 把已有的产品作为需求基线
9) 给出期望的解决办法
2009-7-20 121
需求分析 （ Note 35）
1) 划分需求优先级
2) 带来技术困难的特性
3) 不熟悉的技术、方法、语言、工具或硬件平台
2009-7-20 122
需求规格说明 （ Note 36）
1) 需求理解
2) 时间压力对 T B D的影响
3) 具有二义性的术语
4) 需求说明中包括了设计
2009-7-20 123
需求验证 （ Note 37）
1) 未经验证的需求
2) 审查的有效性
2009-7-20 124
需求管理 (Note 38)
1) 变更需求
2) 需求变更过程
3) 未实现的需求
4) 扩充项目范围
2009-7-20 125
建立项目视图与范围 (Note 39)
一个项目可能包括一些与软件没有直接关系的需求，例如：硬件的购买、产品的安装、维护或广告。但在此，我们只关心与软件产品有关系的业务需求。
2009-7-20 126
通过业务需求确定项目视图 (Note 40)
项目视图可以把项目参与者定位到一个共同和明确的方向上
项目视图描述了产品所涉及的各个方面和在一个完美环境中最终所具有的功能
市场需求文档 & 视图和范围的文档
来自各个渠道的业务需求可能会发生冲突
2009-7-20 127
项目视图和范围文档的模板 (Note 41)
a,业务需求
a.1 背景
a.2 业务机遇
a.3 业务目标
a.4 客户或市场需求
a.5 提供给客户的价值
a.6 业务风险
b,项目视图的解决方案
b.1 项目视图陈述
b.2 主要特性
b.3 假设和依赖环境
c,范围和局限性
c.1 首次发行的范围
c.2 随后发行的范围
c.3 局限性和专用性
d,业务环境
d.1 客户概貌
d.2 项目优先级
e,产品成功的因素
2009-7-20 130
模型 (model)
模型,现实世界某些重要方面的表示 。
有时我们使用术语,抽象,来表示模型，
因为我们从现实世界中 抽象 出对我们特别有用的东西。
2009-7-20 131
抽象 (模型化 )
源于实验科学,主要要素为数据采集方法和假设的形式说明,模型的构造与预测实验分析结果分析,
在为可能的算法数据结构和系统结构等构造模型时使用此过程,
抽象的结果是概念符号模型
2009-7-20 132
§ 3.4 需求分析的步骤当前系统目标系统物理模型逻辑模型逻辑模型物理模型模型化 抽象化具体化 实例化怎么做做什么当前系统目标系统需求定义
2009-7-20 133
逻辑模型和物理模型
模型是对对象系统的形式化的特征抽象，概括性或近似地表示
构造模型的过程是一个抽象、分析的过程。
对象系统模型系统抽象 （映射）
模型应用模型构造的过程逻辑模型 物理模型
(本质模型、概念模型 ) (实施模型、技术模型 )
现行系统目标系统描述重要的业务功能，无论系统是如何实施的。
描述现实系统是如何在物理上实现的。
描述新系统的主要业务功能和用户新的需求，无论系统应如何实施。
描述新系统是如何实施的（包括技术）。
2009-7-20 135
分析阶段中常用的模型
（逻辑模型）
数据流图（ DFD）?
实体 ― 联系图
（ ERD ）?
类图?
实例图?
时序图?
状态图
协作图?
事件列表?
数据流定义?
数据元素定义?
……
2009-7-20 136
数据流图
(DFD,Data Flow Diagram)(Note 42)
描述逻辑模型的图形工具,表示数据在系统内的变化。
DFD可以用来表示一个系统或软件在任何层次上的抽象。 较大型软件系统 DFD分成多层
(子图、父图概念 ),可以表示数据流和功能的进一步的细节。
2009-7-20 137
数据流程图的表示 （ page 29-32）
数据源点和终点变换数据的加工文件数据逻辑关系符号：与、或、异或
2009-7-20 138
画数据流图 （ page 32－ 33）
规则：由外向里画
画系统的输出、输入
化系统的内部
画加工的内部
2009-7-20 139
应该注意的几个问题 （ page 33-34）
适当地命名
画数据流而不是控制流
先考虑稳定状态
忽略琐碎的枝节
随时准备重画
2009-7-20 140
分层数据流图
对于大型系统，往往使用一张数据流图画出所有数据流和加工是不可能的
自顶向下逐层分解
不要一下子引入过多细节，应该逐步增加细节
例子（ page 35）：
图 3.13（ a）画出了 …,.。图 3说明,产生新文件,…… 。显然 …… 。
2009-7-20 141
由顶向下画分层数据流图 （ page 37）
描绘中应该注意的问题：
编号
父图和子图的平衡
局部文件
分解的程度
2009-7-20 142
实例 ——运动会管理系统
自学 3.3.5节（ Page 40）
2009-7-20 143
数据流图的改进
检查数据流图的正确性
数据守恒 （ page 41-42）
文件的使用 （ page 42）
父图和子图的平衡 （ page 42-43）
提高数据流图的易理解性
简化加工间的联系 （ page 43）
分解的均匀 （ page 43）
适当地命名 （ page 43-44）
重新分解 （ page 44）
2009-7-20 144
数据实体关联图 (Note 43)
与数据流图描绘了系统中发生的过程一样，实体联系图（ entity-relationship diagram，
E R D）描绘了系统的数据关系
分析实体联系图有助于对业务或系统数据组成的理解和交互，并暗示产品将有必要包含一个数据库。
实体（ e n t i t y）是物理数据项（包括人）
或者数据项的集合，这对所分析的业务或所要构造的系统是很重要的
2009-7-20 145
化学制品仓库存货清单化学制品容器存储 执行化学制品请求
1
M
M
1
“化学制品跟踪系统,的实体联系图
2009-7-20 146
需求建模实例酒店管理系统 的局部 DFD
已预订的入住预订请求预订 预订确认未预订的入住已预订的入住请求未预订的入住请求客人数据客房数据预订确认信息客人信息夜审结算信息 财务系统时钟
2009-7-20 147
需求建模实例：
某金融贸易系统用例图 (UML)
风险分析交易估计进行交易进行交易接待员酒店系统财务系统
2009-7-20 148
需求建模实例：
用例图举例（ UML）
签定一份保险单客户保险销售人员销售统计客户统计需求建模实例：
UML类图实例 (Note 44)
客人姓名地址身份证号码护照号码 ……
预订
……
入住住宿编号付款方式 ……
退房……
客房状态日期人数
……设置状态
……
客房
……
服务日期数量设置 ……
读取 ……
服务类别名称价格设置 ……
1 0..*
1
0..*
0..*
0..11..*
1
0..*
1*
2009-7-20 150
需求建模实例：
描述 客房状态的状态图 (Note 45)
取消预定已预订空闲占用 维修事件创建
2009-7-20 151
需求建模实例：
接电话的顺序图 （ UML）
受话者 交换机 远程交换机 受话者拿起话筒听通话声拨号码
......
铃响信号 铃响铃响停止信号拿起话筒铃响停止
<10
d
e
a
b
c
{b-a<1}
{e-d<5}
{c-b<10}
路径
2009-7-20 152
需求建模实例：
UML协作图举例计算机 队列打印服务器 打印机打印文件打印机忙保存打印文件打印机空闲打印文件
2009-7-20 153
§ 3.5 数据词典
(DD,DataDictionary)
DD是对所有与系统相关的数据元素的一个有组织的列表,以及 精确的、严格的定义,使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解
2009-7-20 154
词典与数据流图之间关系 （ page 44）
数据流图描述了系统的,分解,；
依靠,词典,来说明各个成分的含义；
数据流图中所有名字的定义就构成一本词典；
数据流图和词典结合在一起构成了,需求说明书,
数据流图中出现的每一个数据流名、每一个文件名和每一个加工名在词典中都应该有一个条目给出这个名字的定义。
2009-7-20 155
词典条目的各种类型 （ page,45）
四个类型条目
数据流
文件
数据项（指不在分解的数据单位）
加工
词典条目的实例 （ page 46－ 47）
结合上次自习的内容自行学习本节
2009-7-20 156
需求建模实例：
数据字典条目的定义预订请求＝客人数据＋住宿期限 +客房类别客人数据＝客人姓名 +地址 +身份证号码
+[护照号码 ] +支付方式身份证号码 =十进制 15{数字 }18
护照号码＝字母 + 8{数字 }8
字母＝,A”…,Z”
十进制数字＝,0”…,9”
2009-7-20 157
需求建模实例：
数据字典条目的定义
F1:航班信息文件 ＝ {航空公司名称＋航班号
＋起点＋终点＋日期 ＋起飞时间＋降落时间 }
航空公司名称＝ 2{字母 }4
航班号＝ 3{十进制数字 }3
字母＝,A”…,Z”
十进制数字＝,0”…,9”
起点＝终点＝ 1{汉字 }10
起飞时间＝降落时间＝时＋分
2009-7-20 158
需求建模实例：
数据字典条目的定义时＝,00”…,23”
分＝,00”…,59”
日期＝年＋月＋日年＝ [2000｜ 2001｜ 2002｜ 2004]
月＝,01”…,12”
日＝,01”…,31”
2009-7-20 159
§ 3.6 小说明
数据流图中每一个基本加工（即不再进一步被分解的加工）都必须有一个,小说明,
小说明中应精确描述用户要求一个加工,做什么,
加工的激发条件
加工逻辑
加工优先级
加工执行频率
出错处理
2009-7-20 160
结构化的语言 （ page 51）
构成方式
语态
词汇
举例
2009-7-20 161
判定表与判定树 （ page 54-56）
有些问题不易用单纯的语言表达
判定表组成：
条件桩
条件条目
操作桩
操作条目
判定树
2009-7-20 162
§ 3.7 模型的作用
在建模过程中了解系统
通过抽象降低复杂性
有助于回忆所有的细节
有助于开发小组间的交流
有助于与用户的交流
为系统的维护提供文档
2009-7-20 163
需求分析建模方法分析建模方法
结构化分析 (传统建模方法 )
面向对象分析
2009-7-20 164
模型的作用计算机世界现实世界影射计算机世界现实世界 结构化开发方法结构化分析结构化设计结构化编程
OOA
OOD
OOP
面向对象开发方法模型的作用
2009-7-20 166
结构化分析模型的组成结构数据流图
(DFD)
E-R图状态 变 迁图
(STD图 )
加工说明控制说明数据对象说明数据字典
（ DD）
2009-7-20 167
面向对象分 析模型的组成结构对象 -关系模型类 /对象模型对象 -行为模型使用实例
(Use Case)
操作、
2009-7-20 168
重点小结
2009-7-20 169
§ 3.8 结构化分析方法
(Structured Analisys,SA)
基于数据流技术的分析方法需求获取应遵循的三条基本原则：
分解
抽象
投影
2009-7-20 170
分析模型的元素
数据字典 (DD),模型核心 (中心库 )
E-R图 (ERD)：
数据流图 (DFD)
指明数据在系统中移动时如何被变换 ;
描述对数据流进行变换的功能 ;
DFD中每个功能的描述包含在加工规约 (小说明 )。
状态变迁图 (STD)
指明作为外部事件的结果,系统将如何动作。
2009-7-20 171
E-R图是数据建模的基础客人入住客房状态客房服务 服务类别姓名地址身份证号码护照号码电话
……
客房号床位数房间类别价格 1
……
住宿编号住宿时间支付方式
……
日期，客人数状态 (已预定 /占用 /维修中 )
……
日期，数量
……
名称，价格
……
2009-7-20 172
将分析模型转换为软件设计数据字典数据流图
E-R图状态变迁图加工规约控制规约数据对描述象数 据 设 计体系结构设计接口设计过程设计分析模型 设计模型
2009-7-20 173
§ 3.9 实例 考务处理系统功能
(1)对考生送来的报名单进行检查 ;
(2)对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站 ;
(3)对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格标准审定合格者 ;
(4)制作考生通知单 (含成绩及合格 /不合格标志 )
送给考生 ;
(5)按地区进行成绩分类统计和试题难度分析，
产生统计分析表。
2009-7-20 174
实例 考务处理系统功能考务处理系统的分层 DFD
如下：
2009-7-20 175
顶层数据流图考生考务处理系统考试中心阅卷站不合格报名单报名单准考证考生通知单 成绩清单合格标准错误成绩清单考生名单统计分析表
2009-7-20 176
0层数据流图登记报名单报名单准考证
1
统计成绩
2不合格报名单考生通知单成统计分析表考生名册绩清单合格标准考生名单成绩 清单错误
2009-7-20 177
一层数据流图 (a)
检查报名单报名单准考证
1.1
编准考证号
1.2不合格报名单考生名册考生名单合格报名单登记考生
1.3
2009-7-20 178
一层数据流图 (b)
检查成绩清单
2.1 审定合格者
2.2
考生名册正确成绩清单制作通知单
2.3分析统计成绩
2.4分析试题难度
2.5
试题得分清单考生通知单难度分析表合格标准分类统计表成绩清单错误成绩清单 经审定的成绩清单
S
21
3
2.22.1
2.3
3.1 3.2
顶层
（不编号）
0层
1层
2009-7-20 180
数据字典举例
F1:航班信息文件 ＝ {航空公司名称＋航班号
＋起点＋终点＋日期 ＋起飞时间＋降落时间 }
航空公司名称＝ 2{字母 }4
航班号＝ 3{十进制数字 }3
字母＝,A”…,Z”
十进制数字＝,0”…,9”
起点＝终点＝ 1{汉字 }10
起飞时间＝降落时间＝时＋分
2009-7-20 181
再来看看 ——
结构化分析模型的组成结构数据流图
(DFD)
E-R图状态 变 迁图
(STD图 )
加工说明控制说明数据对象说明数据字典
（ DD）
2009-7-20 182
§ 3.11 需求分析的其他工作 （ page 63）
确定设计限制
确定验收标准
编写,初步用户手册,
复查需求说明书
2009-7-20 183
补充知识
UML语言和图
2009-7-20 184
UML简介 （ Note L1）
UML定义
由信息系统三位专家 Grady Booch，
James Rumbaugh和 Ivar Jacobon
OMG组织采奶作为业界标准
2009-7-20 185
UML的开发历程 （ Note L2）
Booch’91其它方法 OMT-1 OOSE
Booch’93 OMT-2
UML 0.8
UML 0.9&0.91
UML 1.0
UML 1.1
UML同行专家意见
OMG认证
10/95
10/96 & 9/96
OMG审核,1/97
OMG修正,9/97
OMG采用,11/97
UML 1.3
2009-7-20 186
UML架构 （ Note L3）
UML由图和元模型组成
元元模型层
元模型层
模型层
用户模型层
2009-7-20 187
UML的模型、视图、图与系统架构的建模 （ Note L4）
用例视图
逻辑视图
并发视图
组件视图
展开视图
2009-7-20 188
UML与面相对象的软件分析与设计
（ OOA&D） （ Note L5）
标准的表示方法
与软件开发的成功经验集成
2009-7-20 189
UML的应用领域 （ Note L6）
UML被用来为系统建模，它可应用的范围非常广泛
在不同系统中的应用
信息系统
技术系统
嵌入式实时系统
分布式系统
商业系统
2009-7-20 190
在软件开发不同阶段的应用 （ Note L7）
需求分析
分析
设计
构造
测试
2009-7-20 191
静态建模：用例和用例图 （ Note L8）
用例模型的基本组成：用例、角色和系统
用例图,
风险分析交易估计进行交易进行交易接待员酒店系统财务系统
2009-7-20 192
发现角色 （ Note L9）
通过回答下泪问题，可以帮助建模者发现角色
使用系统主要功能的人是谁？
需要借助于系统完成日常工作的人是谁？
谁来维护、管理系统，保证系统正常工作
系统控制的硬件设备有哪些？
系统需要与哪些其它系统交互？
对系统产生的结果感兴趣的人或事是哪些？
2009-7-20 193
发现用例 （ Note L10）
询问以下问题
角色需要从系统中获得哪种功能？角色需要做什么？
角色需要读取、产生、删除、修改或存储系统中的信息吗？
系统中发生的事件需要通知角色吗？
如果用系统的新功能处理角色的日常工作是简化了还是提高了工作效率？
2009-7-20 194
UML中的用例 （ Note L11）
2009-7-20 195
用例之间的关系 （ Note L12）
2009-7-20 196
描述用例
（ Note L13）
2009-7-20 197
测试用例 （ Note L14）
用例可用于测试系统的正确性和有效性。
正确性表明系统的实现符合规格说明。
有效性保证开发的系统是用户真正需要的系统
2009-7-20 198
实现用例 （ Note L15）
UML中实现用例的基本思想是用协作表示用例，而协作又被细化为用若干个图。
协作的实现用脚本描述。
2009-7-20 199
第四章 设 计 方 法
2009-7-20 200
主要内容 （ Note 46）
▲ 什么是结构化设计
▲ 结构化设计方法的主要思想
▲ 结构化设计的重要组成部分
▲ 结构化设计的方法
2009-7-20 201
结构化设计的工作原理（ Note 47）
结构化设计目标
结构化设计的优点
利用模块结构减少开发和维护软件的费用
2009-7-20 202
软件设计分为两个阶段：
(1)概要设计 (总体设计 )（ Page 66）
确定软件的结构以及各组成成分
(子系统或模块 )之间的相互关系。
(2)详细设计确定模块内部的算法和数据结构，产生描述各模块程序过程的详细文档。
2009-7-20 203
模块
模块是鱼油一定功能的可以用名词调用的程序语句集合，如：
独立的汇编程序
COBOL的段和节
Pascal过程
FORTRAN的子程序
汇编的宏
2009-7-20 204
控制结构 (程序结构 )
控制结构是软件模块间关系的表示
2009-7-20 205
控制结构图示：
2009-7-20 206
控制结构的层次规则
只有一个顶层 (0层 )模块
0层外任一模块都会在它的邻层存在一模块与它有关
同层模块间不发生联系
2009-7-20 207
软件结构度量术语深度宽度扇出扇入
(模块的层数 )
(同一层最大模块数 )
(一个模块直接调用的模块数 )
(调用一个给定模块的模块个数 )
2009-7-20 208
模块化 (Modularity)
模块化是好的软件设计的一个基本准则从整体上把握问题,隐蔽细节复杂问题 较小问题分解可减小解题所需的总的工作分解
2009-7-20 209
抽象 (Abstraction)
抽象原则应用举例
Windows NT一体化的 I/O系统设计文件管理网络管理设备管理高速缓冲存储器
Ｏ
Ｓ
对虚拟文件的字节流,
虚拟文件可为任何设备和实体抽象
2009-7-20 210
例,将问题 (P1+P2)分解为 P1,P2
设函数 C(x)定义问题 x 的复杂程度函数 E(x)确定解决问题 x 需要的工作量对问题 P1和 P2,如,
C(P1) > C(P2)
显然,E(P1) > E(P2)
有规律,C(P1+P2) > C(P1)+C(P2)
E(P1+P2) > E(P1)+E(P2)
＂ 各个击破 ＂ 理论
2009-7-20 211
模块度 (Note 48)
成本或工作量模块数量软件总成本集成成本成本 /模块
M
最小成本区域
2009-7-20 212
结构化设计的适用范围 （ Note 49）
尤其适用于采用结构化程序设计实现的系统
结构化设计并不是一种广泛适用的系统设计技术
什么人来完成设计呢？
结构化设计的结果
2009-7-20 213
SA与 SD的关系 （ Note 50）
结构化分析的结果 结构化设计的工具数据流图 初始结构图生存周期字典的数据部分设计数据字典伪码 实现方面 伪码实体关系图 数据库设计事务框图 分层、细化事务模型
2009-7-20 214
SD来源于 SA
来源：结构化分析 来源：结构化分析 来源：结构化分析数据流图字典项伪码实体关系图事务框图环境的限制 质量的标准转化分析 细化设计进入实现阶段初始结构框图
2009-7-20 215
概要设计的基本概念
将系统划分成模块 （ Page 66）
决定每个模块的功能 （ Page 66）
决定模块的调用关系 （ Page 66）
决定模块的界面，即模块间传递的数据 （ Page 66）
2009-7-20 216
结构化设计（ SD方法）概要
相对独立、单一功能的模块（ page 67）
块间联系和块内联系（ page 67）
描述方法（ page 68）
步骤（ page 69）
2009-7-20 217
结构图 (SC Structure Chart)
结构图主要成分 （ page 68）
模块 ——用方框表示，方框中写有模块的名字，
一个模块的名字应适当地反映这个模块的功能，
这就在某种程度上反映了块内联系；
调用 ——从一个模块指向另一个模块的箭头表示前一模块中含有对后一模块的调用；
数据 ——调用箭头边上的小箭头表示调用时从一个模块传入送给另一个模块的数据，小箭头也指出了传送的方向。
2009-7-20 218
结构图 (SC Structure Chart)
SD方法在概要设计中的主要表达工具约定：
编辑学生记录读学生记录学生数据无此学生学号不加区分的数据数据信息控制信息
2009-7-20 219
SC中的四种模块传入模块
(a) (b)
A
A
传出模块
B
B
变换模块
(c)
C D
协调模块
E
(d)
E F F
2009-7-20 220
SC中的选择调用
A
CB D
A根据内部判断决定是否调用 B
A按另一判定结果选择调用 C或 D
2009-7-20 221
SC中的循环调用
A
B C
A根据内在的循环重复调用 B,C等模块
2009-7-20 222
结构图 (SC)举例医院管理系统门诊管理药房管理药库管理病房管理财务管理处 方挂号处理挂 号 费总 计挂号单挂号费总计 出库处理 进药管理病历管理 处方管理 常规处理
2009-7-20 223
酒店管理信息系统功能结构图
H M I S
收银管理子系统收银管理子系统 收银管理子系统客人登记预定登记客房处理历史记录客房查询预定查询餐桌安排菜单作业营业结帐汇总打印各类查询初始设置客帐处理退房处理夜审处理客帐查询报表打印
2009-7-20 224
大型零售商场管理信息系统功能结构图
TM M I S
系统维护
P
O
S
系统零售实时系统商品进货管理商品批发管理商品库存管理商品及商品帐管理顾客管理连锁店管理财务管理人事工资管理计划统计管理经理查询
2009-7-20 225
信息隐蔽 (Information Hiding)
模块所包含的信息，不允许其它不需要这些信息的模块访问，独立的模块间仅仅交换为完成系统功能而必须交换的信息 。
2009-7-20 226
块间联系
块间联系大小：
方式,作用,数量
联系方式（ Page 71）
用过程语句调用,直接引用
共用信息的作用（ Page 73）
公用信息的数量（ Page 74）
表格 4.1（ page 75）
2009-7-20 227
块内联系
偶然型（ Page 76）
逻辑型（ Page 76）
瞬时型（ Page 77）
通讯型（ Page 77）
顺序型（ Page 78）
功能型（ Page 78）
2009-7-20 228
偶然内聚 (巧合内聚 )
A B C
M MOVE O TO R
READ FILE F
MOVE S TO T
模块 M中的三个语句没有任何联系缺点：可理解性差,可修改性差例,
2009-7-20 229
逻辑内聚
把几种相关功能（逻辑上相似的功能）
组合在一模块内，每次调用由传给模块的参数确定执行哪种功能。
2009-7-20 230
逻辑内聚模块
A B C
E F G
A B C
EFG
A1 B1 C1
EFG模块内部逻辑
E,F,G逻辑功能相似，组成新模块 EFG
缺点,增强了耦合程度 (控制耦合 )
不易修改，效率低公用代码段公用代码段
2009-7-20 231
时间内聚 (经典内聚 )
模块完成的功能必须在同一时间内执行，这些功能只因时间因素关联在一起。
例如,初始化系统模块、
系统结束模块、
紧急故障处理模块等均是时间性聚合模块,
2009-7-20 232
过程内聚（顺序性组合）
模块内各处理成分相关，
且必须以特定次序执行
2009-7-20 233
过程内聚模块读入成绩单审查成绩单统计成绩打印成绩读入并审查成绩单统计并打印成绩单
2009-7-20 234
通信内聚
模块内各部分使用相同的输入数据，或产生相同的输出结果
2009-7-20 235
通信内聚模块例产生工资报表计算平均工资职工工资记录职工工资报表平均工资产生职工工资报表并计算平均工资模块
2009-7-20 236
信息内聚
模块完成多个功能，各功能都在同一数据结构上操作，每一功能有唯一入口。
2009-7-20 237
信息内聚模块符 号 表查找 登录 删除 修改几个加工同时引用一个共同的数据
2009-7-20 238
功能内聚
模块仅包括为完成某个功能所必须的所有成分。
模块所有成分共同完成一个功能，缺一不可内聚性最强
2009-7-20 239
块间联系
无直接关系型
数据耦合
标记耦合
控制耦合
外部耦合
公共耦合
内容耦合
2009-7-20 240
(1) 无直接耦合两个模块没有直接关系 (模块 1和模块 2)，模块独立性最强。
模块 1 模块 2
模块 3 模块 4
241
(2) 数据耦合一模块调用另一模块时，被调用模块的输入、输出都是简单的数据 (若干参数 )。
属松散耦合。
242
数据耦合举例开发票计算水费单价数量 金额
243
(3) 标记耦合 (复合型耦合 )
如两个模块通过传递 数据结构 (不是简单数据，而是记录、数组等 )加以联系，或都与一个 数据结构 有关系,
则称这两个模块间存在标记偶合。
244
标记耦合举例计算水电费计算水费 计算电费住户情况 水费电费住户情况
,住户情况,是一个 数据结构,图中模块都与此数据结构有关,
,计算水费,和,计算电费,本无关,由于引用了此数据结构产生依赖关系,它们之间也是标记偶合,
245
将标记耦合修改为数据耦合举例计算水电费计算水费 计算电费本月用水量本月用电量水费电费
246
(4) 控制耦合一模块向下属模块传递的信息 (开关量、标志等控制被调用模块决策的变量 ) 控制了被调用模块的内部逻辑。
247
控制耦合举例
A
计算平均分或最高分
B
平均 /最高
(控制信号 ) 成绩读入分数输出结果计算平均分 计算最高分平均 /最高?
B
248
控制耦合增加了理解和编程的复杂性，调用模块必须知道被调模块的内部逻辑，增加了相互依赖
(1)将被调用模块内的判定上移到调用模块中进行
(2)被调用模块分解成若干单一功能模块去除模块间控制耦合的方法
249
改控制耦合为数据耦合举例
A
计算平均分
B1
平均成绩 最高成绩计算最高分
B2
250
(5) 外部耦合
一组模块均与同一外部环境关联 (例如,I/O模块与特定的设备、格式和通信协议相关联 ),它们之间便存在外部耦合。
外部偶合必不可少,但这种模块数目应尽量少。
251
(6) 公共耦合 (公共数据区耦合 )
一组模块引用同一个公用数据区 (也称全局数据区、公共数据环境 )。
公共数据区 指：
全局数据结构
共享通讯区
内存公共覆盖区等
252
公共耦合举例
Ａ
公共数据区
CB
模块 A,B,C间存在错综复杂的联系
253
(1)软件可理解性降低
(2)诊断错误困难
(3)软件可维护性差，
(4)软件可靠性差
(公共数据区及全程变量无保护措施 )
慎用公共数据区和全程变量 !!!
公共耦合存在的问题
254
(7) 内容耦合一模块直接访问另一模块的内部信息 (程序代码或数据）
最不好的耦合形式 !!!
A B A
B
模块代码重叠
Entry1
……
Entry1
……
多入口模块
2009-7-20 255
系统结构的形态 （ Note 52）
形态（ morphology）所指的是系统结构所表现出来的形状。
深度、宽度、扇出和扇入
Page 68,描述方式,
模块、调用、数据
一个模块在结构图中只能出现一次
输入模块在作，输出模块在右，计算模块居中
2009-7-20 256
系统结构的影响范围和控制范围
系统中某一层上模块中的判定或者条件语句
（例如 If语句）在系统中会产生多种后果，根据该判定的结果去执行或不执行其他层的某个处理或数据。
该处理就是,条件依赖,于某个判定
判定的,影响范围,是指包含,条件依赖,于改判定的处理的全部模块
一个模块的,控制范围,是指模块本身和它的全体子模块
2009-7-20 257
影响范围和控制范围
影响范围应该是这个判定所在模块的控制范围的一个子集
但是实际上，在系统中控制范围和影响范围的关系常常并非如此。
影响范围和控制范围 （ note 53）
Top
A
Y
B
B1
X
影响范围
Top
A B
B1 B2
X
Top
Y
A B
X
A
Y
B
B1 B2
X
判定图 1.影响范围在控制范围之外图 2.影响范围在控制范围之内，但判定位置太高图 3.影响范围在控制范围之内，正确实现图 4.理想的影响范围和控制范围
2009-7-20 259
耦合、内聚与模块独立性关系
耦合与内聚都是模块独立性的定性标准，
都反映模块独立性的良好程度。但耦合是直接的主导因素，内聚则辅助耦合共同对模块独立性进行衡量。
2009-7-20 260
设计技巧
2009-7-20 261
面向数据流的设计方法
SD以数据流图为基础，它定义了把 DFD
变换成 软件结构 的不同 映射 方法映射DFD
(问题结构 ) 软件系统的结构 (程序结构 )
2009-7-20 262
系统结构特征可归纳为两种典型形式
变换型结构
事务型结构数据流图可分为两种类型,
变换型数据流
事务型数据流变换中心输入 输出变换型 结构事务中心接受路径动作路径事务型结构由输入、变换中心和输出三部分组成具有在多种事务中选择执行某类事物的能力基本模型 特征
2009-7-20 264
基本模型变换型数据流结构事务型数据流结构传入 变换 传出变换中心传入部分传出部分事务分析事务中心动作
1
动作
2
动作
3
接受接受部分
2009-7-20 265
变换型数据流举例输入信息物理输入格式检查 处理 显示正确信息 结果物理输出数据变换中心逻辑输入逻辑输出传入部分 传出部分特点：具有明确的传入、变换 (或称主加工 ) 和传出界面的 DFD
2009-7-20 266
事务型数据流图举例
I M
L
N
O
A
B
C
D
F
E
G
H
2009-7-20 267
大型系统 DFD中,变换型和事务型结构往往共存,
T
事务中心传入 变换 传出
2009-7-20 268
面向数据流设计方法的设计步骤
(1)精化 DFD
(2)确定 DFD类型
(3)把 DFD映射到系统模块结构设计出模块结构的上层
(4)基于 DFD逐步分解高层模块设计出下层模块
(5)根据模块独立性原理，精化模块结构
(6)模块接口描述面向数据流方法的设计过程精化数据流图区分事务中心和数据接收路径映射成变换结构流类型区分输入和输出分支映射成事务结构用启发式设计规则精化软件结构导出接口描述和全程数据结构复查详细设计
“事务,,变换,
事务分析 变换分析
2009-7-20 270
SD方法的两种映射过渡方法变换型 DFD
事务型 DFD
初始 SC
初始 SC
变换分析事务分析
2009-7-20 271
初始的 SC
主模块输入模块 主加工模块 输入模块事务控制模块接受模块 动作发送模块动作 1模块 动作 2模块 动作 3模块由变换分析产生由事务分析产生
2009-7-20 272
(1) 变换分析设计方法步骤：
(1)区分传入、变换中心、
传出部分，在 DFD 上标明分界线
B CA
D E
Q
P R
W
U V
a b
c
ed
r
p
u
w
v
变换中心传入部分传出部分
2009-7-20 274
变换分析设计方法
步骤：
(2)第一级分解 (建立初始 SC框架 )
设计顶层和第一层模块第一级分解的方法
MC
MTMA ME
2009-7-20 276
第一级分解后的 SC
MC
MTMA ME 第一层顶层
c,e
c,e u,w
u,w
传入模块 传出模块中心变换模块
2009-7-20 277
变换分析设计方法
步骤,
(3)第二级分解 (分解 SC各分支 )
自顶向下分解，设计出每个分支的中、下层模块
2009-7-20 278
传入分支的分解 (1)
MA
C
B
A
b
a
c
E
D
d
e
c,e
2009-7-20 279
传入分支的分解 (2)
MA
Get C
b
a
c
Read D
d
e
c,e
B to C
b c d e
a b
Get E
Get B D to E
A to BRead D
2009-7-20 280
传出分支的分解
ME
W
Write V
u
u
w,u
v v v
Put U
U to V
ME
U Write W
ww u
w,u
V
(1) (2)
2009-7-20 281
中心加工分支的分解
MT
PQ R
e
c,p r
u,wp
r
2009-7-20 282
(2) 事务分析设计方法任何情况下都可使用变换分析方法设计软件结构，但如数据流具有明显的事务特点时 (有一个明显的事务中心 ),以采用事务分析方法为宜。
2009-7-20 283
事务分析设计方法
步骤：
(1)在 DFD上确定事务中心、接收部分和发送部分。
(2)画出 SC框架，把 DFD上的三部分分别映射为事务控制模块、接收模块和动作发送模块。
(3)分解细化接收分支和发送分支，
完成初始 SC。
用户命令交互子系统ＤＦＤ
读用户命令密码命令密码显示信息系统参数数据用户命令读系统数据 配置信息显示信息和状态命令分析处理读密码命令类型开 /关命令建立配置文件原配置数据激活 /非活动系统与文件中密码比较格式化配置数据配置 命令检验信息过程重试信息四位数字 检验信息检验信息
A/D信息格式化配置数据格式化配置数据
2009-7-20 285
初始的 SC
主模块输入模块 主加工模块 输入模块事务控制模块接受模块 动作发送模块动作 1模块 动作 2模块 动作 3模块由变换分析产生由事务分析产生
2009-7-20 286
事务分析的映射方法总控调度
C路径B路径A路径
A路径
B路径C路径接收路径
2009-7-20 287
用户命令交互子系统初始的 SC
用户执行模块读用户命令 命令处理密码处理控制器现用 /非现用系统系统设置控制器用户命令交互子系统ＤＦＤ
读用户命令密码命令密码显示信息系统参数数据用户命令读系统数据 配置信息显示信息和状态命令分析处理读密码命令类型开 /关命令建立配置文件原配置数据激活 /非活动系统与文件中密码比较格式化配置数据配置 命令检验信息过程重试信息四位数字 检验信息检验信息
A/D信息格式化配置数据格式化配置数据
2009-7-20 289
用户命令交互子系统的 SC
用户执行模块读用户命令 命令处理密码处理控制器现用 /非现用系统系统设置控制器读系统数据建立配置文件显示信息与状态用户命令交互子系统ＤＦＤ
读用户命令密码命令密码显示信息系统参数数据用户命令读系统数据 配置信息显示信息和状态命令分析处理读密码命令类型开 /关命令建立配置文件原配置数据激活 /非活动系统与文件中密码比较格式化配置数据配置 命令检验信息过程重试信息四位数字 检验信息检验信息
A/D信息格式化配置数据格式化配置数据
2009-7-20 291
用户命令交互子系统的 SC
用户执行模块读用户命令 命令处理密码处理控制器现用 /非现用系统系统设置控制器读系统数据建立配置文件显示信息与状态读密码用文件比较密码密码输出控制器产生无效信息
2009-7-20 292
事务流设计举例
I M
L
N
A
B
C
D
F
E
G
事务中心
2009-7-20 293
事务流设计举例取 A
总控
A
L M N
G
D
B C F
E
（主模块）
事务加工模块
2009-7-20 294
动作分支的典型结构
P
T 2T 1 T i
A 2
D 2
A 1
D 1
A 3 A j
D k
事务层操作层细节层处理层 主模块事务加工模块操作模块细节模块
2009-7-20 295
事务流设计举例取 A
总控
A
L M N
G
D
B C F
E
动作 1 动作 n….
细节模块 1 细节模块 2 ….
（操作模块）
（细节模块）
2009-7-20 296
事务型数据流图举例
I M
L
N
OA
B
C
D
F
E
G
H
2009-7-20 297
事务流设计举例 (另一种画法 )
输入 A
XX系统变换控制
A
L M
A
G
D
B C
FE
输出 E,F,G
E,F,G E,F,G
输出 HO
E,F、
G H H
N
2009-7-20 298
(3) 混合流设计举例
3 4
1
2
6
7
5
8
10
9
11
变换中心传 入 传 出事务型
2009-7-20 299
混合流设计举例
T
事务中心 传入 变换 传出接收部分发送部分
2009-7-20 300
混合流设计举例
AB
T1
变换中心传入 传出
T2
T3
a
b b1b2
b3
c1
c2
c3
d e g
f j
Ｌ
m
事务流子系统
BC CD DE
EH
HK
FJ
KL
LMh
k
2009-7-20 301
混合流设计举例输入 D
XX系统变换控制 输出 K
输入 C
d
c
输出 LCD DE FJ EH HK KL
c d
d k
k
k
L L
输出 MLM
m mL事务子系统
2009-7-20 302
体系结构设计优化
2009-7-20 303
体系结构设计优化将初始 SC根据模块独立性原则进行精化,对模块进行合并、分解修改、调整，
得到高内聚、低耦合模块，得到易于实现、易于测试和易于维护的软件结构，
产生设计文档的最终 SC。
2009-7-20 304
改进软件结构设计的指导原则
(软件结构设计的启发式规则 )
(1)模块功能的完善化
(2)消除重复功能
(3)将模块的影响限制在模块的控制范围内
(4)深度、宽度、扇出和扇入适中
(5)模块大小适中
(6)降低模块接口的复杂性
(7)模块功能可预测
(8)避免模块的病态连接
(9)根据设计约束和可移植性要对软件打包
2009-7-20 305
(1) 模块功能的完善化完整的模块应包括三部分：
(1)执行规定功能部分
(2)出错处理部分
(3)需返回给调用者数据时，
返回是否正确结束标志。
2009-7-20 306
(2)消除重复功能
Q1
C
Q2
C
Q1 Q2
C改进前
Q1,Q2功能相似
X Y
Q’
X Y X Y
重复部分 改进方法 1：将 Q1,Q2
合并为 Q’
不可取改进方法 2：
将 Q1,Q2的公共部分分离出来
2009-7-20 307
(3)将模块的影响限制在模块的控制范围内
C
H
D E
G
X
F
A I
L
J KB
模块 C的控制范围,C,D,E,F,G,H
如果模块
C 作出的决策影响了模块 L，
L超出了 C
的控制范围
2009-7-20 308
(4) 减少高扇出争取高扇入编外人员工资取得工资数据计时制工资额薪金制工资额编外人员税款编外人员扣款常规扣款税收扣款计算实发工资避免平铺结构
2009-7-20 309
增加中间层降低扇出编外人员工资取得工资数据计时制工资额薪金制工资额编外人员税款编外人员扣款常规扣款税收扣款计算实发工资计时工人实发工资计薪工人实发工资编外人员实发工资
2009-7-20 310
(5) 模块大小适中模块过大：可理解程度下降模块过小：开销大于有效操作系统接口复杂
2009-7-20 311
(6)降低模块接口的复杂性
接口传递信息应简单且和模块功能一致。
2009-7-20 312
(7) 模块功能可预测模块看成黑盒子，相同输入产生相同输出，其功能为可预测的。
模块带有内部状态其功能可能是不可预测的。难理解、难测试、难维护。
2009-7-20 313
防止模块功能过分局限功能单一的模块具有高内聚。
但如任意限制局部数据结构的大小，过分限制控制流中可做的选择或外部接口的模式，模块功能就过分局限，使用范围过分狭窄，缺乏灵活性和可扩充性。
2009-7-20 314
(8)避免模块的病态连接防止指向模块中间的分支或引用
（针对内容耦合）
2009-7-20 315
(9)根据设计约束和可移植性需求对软件打包打包指用来为特定环境组装软件的技术
2009-7-20 316
小结：结构化设计
2009-7-20 317
结构化设计的质量标准 （ Note 51）
结构图
耦合度
聚合度信息隐蔽的目的：
提高模块的独立性，减少修改或维护时的影响面。
2009-7-20 318
结构图 （ note 51a）
A
CB D
A
B
Z
X.Y
A
CB D
1
重复调用和一次调用条件调用
2009-7-20 319
耦合度 (Note 51b)
结构化设计方法的重要成果是把影响耦合度的因素归结为如下原则：
连系方式的类型：用过程语句调用低于直接调用
接口的复杂性：接口间传递信息的数量
连系的作用：传送信息流的类型，数据型、控制型或混合型
耦合时间：按执行时间、装入时间、连接时间及编译时间来区分。
2009-7-20 320
连系的作用 (Note 51c)
混合型的例子：当一个模块修改另一个模块的代码时，对修改者来说修改的代码是当作数据来处理的。而对被修改者来说，则是一种对
,控制,的变动。
控制型的例子：模块 A通过用作控制信号的开关量实际上控制着模块 B的工作。
2009-7-20 321
控制型耦合转变为数据型耦合 (Note
51d)
一般来说，控制型耦合是不必要的，可以通过分裂模块等方法把控制型耦合转变成数据型耦合。
A
取阴历取阳历
A
取阳历日期或取阴历日期日期类型选择 阴历日期阳历日期
2009-7-20 322
用三个封装级别表示的软件结构原始代码行
0级程序模型
(子程序或过程 )
1级 2级类 /对象结构
2009-7-20 323
结构设计（或 1级）标准，用以管理每一对封装级别的元素之间的相互关系内聚结构化设计
0级结构体
（代码行）
1级结构体
（程序）
TO：
FROM：
0级结构体
（代码行）
1级结构体
（程序）
输出端耦合性内聚 是指度量一个给定的程序内的多行代码的单一功能性
，以确定是否达到该程序所要实现的目的。
耦合性 用来度量程序之间联系的次数和强度
2009-7-20 324
上表的扩展：包括 2级封装（所有的类）
内聚结构化设计
0级结构体
（代码行）
1级结构体
（程序）
TO：
FROM：
0级结构体
（代码行）
1级结构体
（程序）
输出端耦合性
—
2级结构体
（类）
—
—
类的耦合2级结构体（类） 类的内聚类的内聚 是模仿了一个程序的内聚。
类的耦合性 是一种度量类之间联系的次数和强度的方法。
2009-7-20 325
无耦合－没有依赖关系松散耦合－有少量依赖关系紧密耦合－有很多依赖关系图形表示耦合关系
2009-7-20 326
耦合强度依赖的因素：
一模块对另一模块的引用
一模块向另一模块传递的数据量
一模块施加到另一模块的控制的数量
模块间接口的复杂程度
2009-7-20 327
模块间耦合的类型 （ page 74）
低 无直接耦合耦 数据耦合合 标记耦合性 控制耦合外部耦合公共耦合高 内容耦合模块独立性弱
(低耦合 )
强
(中耦合 )
(较强耦合 )
(强耦合 )
2009-7-20 328
聚合度 （ Note 51e）
七层聚合类型
偶然型
逻辑型
瞬时型
通讯型
顺序型
功能型
2009-7-20 329
详细设计的基本概念 (page 108)
详细设计工具：
(1) 图形工具
流程图
盒图
问题分析图
(2) 表格工具
(3) 语言工具
2009-7-20 330
结构化程序设计（ SP）方法
结构定理
在结构定理的基础之上,Dijkstra主张避免 GOTO语句，而仅仅使用三种基本结构反复嵌套来构造程序。
自顶向下逐步加细
2009-7-20 331
SP方法实用的描述方式
流程图（ FC）
盒图（ NS）
问题分析图（ PAD）
程序设计语言（ PDL）
2009-7-20 332
系统流程图（ FC）
早于 DFD的一种建模工具。以图形方式说明系统中的控制流和数据流。
Dijkstra主张避免使用 GOTO语句，而仅仅使用顺序、选择和循环等三种基本结构来表示系统流程图示例初始处理数据检查、库存询问、库存分配定货处理帐单处理启动定货销售工作结束定货或询问显示数据顾客文卷库存文卷库存文卷接受的定货文卷临时定货文件显示选择查问库存的初始显示输入查询输入错询问回答检查定货单说明定货单发票询问定货
2009-7-20 334
本章结束软件设计
2009-7-20 335
补充内容
2009-7-20 336
面向对象的方法论
方法论是如何对复杂系统进行,抽象,
的工作，以及如何建立抽象模型 。
2009-7-20 337
面向对象分析建模 (OOA)
面向对象分析方法确实不同于结构化分析方法吗？
Fichman,R.G and C.F.Kemerer,
在,Object-oriented Conventional Analysis
and Design Methodologies” 中阐述：
我们的结论是面向对象分析方法表现了相对面向过程的方法学（如结构化分析）的根本性变化，而且相对面向数据的方法学仅仅是增量性的变化。面向过程的方法学在建模过程中的关注点不是对象的内在性质，从而导致了和面向对象的三个基本原理相正交的问题域模型。
2009-7-20 338
面向对象分析方法
面向对象分析方法使得软件工程师能够通过对象、属性和操作（作为主要的建模成分）的表示来对问题建模。
建立分析模型 5个基本原则：
（ 1） 建模信息域；
（ 2） 描述模块功能；
（ 3） 表示模型行为；
（ 4） 分解以模型显示更多细节；
（ 5） 早期模型表示问题的本质，而后期模型提供实现细节。
2009-7-20 339
OOA的意图
是定义所有和被求解的问题相关的类（及同类关联的关系和行为），为了达到这个目标，必须完成以下任务
2009-7-20 340
OOA的意图
（ 1）必须在客户和软件工程师之间沟通了解基本的用户需求；
（ 2）必须标识类 (定义属性和方法 )；
（ 3）必须刻划类层次；
（ 4）表示对象对象关系（对象连接）；
（ 5）必须建模对象行为；
（ 6）任务 (1)到 (5)递进地反复使用，直至完成建模
2009-7-20 341
流行的几种面向对象方法
Booch方法
Coad-Yourdon方法
Rumbaugh 方法 (简称 OMT）
（ Object Modeling Technology)
Jacobson 方法（简称 OOSE）
由 Rumbaugh,Booch,Jacobson
提出的统一建模语言
(Unify Modeing Language简称 UML)
2009-7-20 342
不同面向对象分析方法的相似步骤：
（ 1）使用基本需求作为指南选择类和对象；
（ 2）为对象标识属性和操作；
（ 3）定义组织类的结构和层次；
（ 4）建造对象 -关系模型的；
（ 5）建造对象 -行为模型。
2009-7-20 343
统一的 OOA方法
由 Rumbaugh,Booch,Jacobson 提出的统一建模语言 (Unify Modeing
Language简称 UML)
UML是一种定义良好，易于表达，功能强大且普遍实用的建模语言。
2009-7-20 344
UML的开发历程
Booch’91其它方法 OMT-1 OOSE
Booch’93 OMT-2
UML 0.8
UML 0.9&0.91
UML 1.0
UML 1.1
UML同行专家意见
OMG认证
10/95
10/96 & 9/96
OMG审核,1/97
OMG修正,9/97
OMG采用,11/97
UML 1.3
2009-7-20 345
OMT (对象建模技术
Object Modeling Technology)
对象建模技术将使用三种不同的模型从不同侧面来描述现实世界，即使用 对象模型,动态模型 和 功能模型三种模型。
OMT是一种 自底向上 和 自顶向下 相结合的方法。 OMT的第一步是从问题的陈述入手，构造系统模型，这是一种自底向上的归纳过程；系统模型建立后的工作就是分解，这是一种基于服务 (Service)的分解。这种从具体到抽象、再从抽象到具体的分析、设计过程符合人类的思维规律，使得需求分析更为彻底，系统可维护性也得以改善。
2009-7-20 346
OMT对象模型技术对象模型 动态模型 功能模型基本模型,
三个模型分别从不同角度分析系统
2009-7-20 347
OMT将开发过程划分为四个阶段
1,分析：分析人员从问题陈述入手开始，建立一个表示现实世界重要性质的应用领域模型。
2,系统设计：系统设计阶段要求做出有关整个系统结构的高层决策，在这一阶段中，目标系统应该根据分析模型和所设置的系统整体结构划分为若干子系统。系统设计人员必须确定哪能些性能需要优化，选择处理问题的策略，做出初步的资源分配。
2009-7-20 348
OMT将开发过程划分为四个阶段
3,对象设计：设计模型是在分析模型的基础上添加实现细节来完成的，在增加工这细节时，设计人员应该遵守在系统设计阶段确定的策略
4,实现：对象设计阶段所产生的对象类和联系最后都必须翻译成具体的程序设计语言，数据库或硬件实现，
在开发过程中，程序设计应该是相对简单机械的部分，
因为所有最困难的决策已经在设计阶段做出，目标语言在某种程度上可能影响设计决定，但设计决不应该依赖程序设计语言的细节，虽然目标语言在某种程序上可能影响设计决策
2009-7-20 349
分析模型
对象模型,描述静态结构,定义做事情的实体
功能模型,描述处理 (数据变换 ),
指明系统应,做什么,
动态模型,描述交互过程,规定什么时候做
2009-7-20 350
OMT模型系统分析和设计过程概观图产生需求结构及对象设计建立模型问题描述对象模型、动态模型、功能模型详细的对象模型详细的动态模型详细的功能模型分析阶段设计阶段
2009-7-20 351
实例：饮料自动售货机系统设置一个饮料自动售货机可以放置五种不同或部分相同的饮料，可由厂商根据销售状况自动调配，并可随时重新设置售价，但售货机最多仅能放置 50罐饮料，其按钮设计在各种饮料样本的下方，若经金额计算器累计金额足够，则选择键灯会亮；若某一种饮料已销售完毕，则售完灯会亮。
2009-7-20 352
实例：饮料自动售货机系统销售顾客将硬币投入售货机，经累加金额足额的饮料选择键灯亮，等顾客按键选择。顾客按键后饮料由取物楼掉出，并自动结算及找钱。
取消交易顾客可在按下选择键前任何一个时刻，拉动退币杆取消交易收回硬币。
2009-7-20 353
步骤
(1)找出对象及其关联
(2)赋予类及关联的属性数据
(3)组织类的结构
OMT的 对象图
2009-7-20 354
找出饮料自动售货机系统中的对象设置一个饮料自动售货机可以放置五种不同或部分相同的饮料，可由厂商根据销售状况自动调配，并可随时重新设置售价，但售货机最多仅能放置 50罐饮料，其按钮设计在各种饮料样本的下方，若经 金额计算器 累计金额足够，则选择键灯会亮；若某一种饮料已销售完毕，则售完灯会亮。
2009-7-20 355
找出饮料自动售货机系统中的对象销售顾客 将硬币投入 售货机,经累加金额足额的饮料 选择键 灯亮，等顾客按键选择。顾客按键后饮料由取物楼掉出，并自动结算及找钱。
取消交易顾客可在按下选择键前任何一个时刻，拉动 退币杆 取消交易收回硬币。
2009-7-20 356
对象模型描述系统内部对象结构，包括对象本身的定义、对象的属性、操作，以及对象与其它对象之间的关系。
对象模型是 OMT方法论中最重要的部分，动态模型、功能模型都将依次而建立 对象模型以对象图形式呈现，对象图由类构成。
饮料自动售货机 系统 对象图贩卖机饮料号码价格投币 -接受饮料掉出金额显示按纽退币杆售完显示存量计算器饮料号码存量递减售完显示重置选择钮选择钮状态灯亮灯熄售完灯亮按钮顾客姓名硬币投币 -置入拿取饮料退币杆退币杆状态拉动金额计算器金额累加找零重置购买选取被拉动属于属于属于属于
2009-7-20 358
建立数据字典为所有模型实体准备一个数据字典,精确描述每一个对象类,包括,
成员
约束
关联、属性、操作
2009-7-20 359
动态模型用来描述系统与时间相关的动态行为即系统的控制逻辑，表现对象彼此间经过相互作用后，随时间改变的不同运算顺序。
动态模型以,事件,（ Events）和
,状态,（ States）为其模型的主要概念。
动态模型以状态图形式呈现
2009-7-20 360
动态模型
事件,?瞬时发生的行为；
引起对象状态转换的控制信息 。
事件类和属性举例：
飞机起飞（航线、航班号、城市）
按动鼠标按钮（按钮、位置）
……,.
2009-7-20 361
动态模型状态,对象属性和对象关联的抽象形式状态的特征表示方法举例：
状态,闹铃响描述,闹铃响表示预定时间到产生本状态的事件序列：
设置闹钟（预定时间）
不包括清除闹铃的任何后续操作当前时间 =预定时间表征本状态的条件：
闹铃 =开，从预定时间起没有按键的情况下，
目标时间?当前时间?目标时间 =20秒
2009-7-20 362
动态模型本状态接受的各种时间：
事件 动作 下一个状态当前时间 =目标时间 +20 重新设置闹钟 正常按下按钮（任意按钮） 重新设置闹钟 正常
2009-7-20 363
动态模型表示方法
状态图状态和事件的网络，侧重描述每一类对象的动态行为
2009-7-20 364
状态图状态 1
Do:活动 1 状态 2.…...
事件 1[条件 1] / 动作 1 结束事件初始事件空闲 可视菜单左边按钮按下 /显示弹出菜单左边按钮弹起 /擦除弹出菜单光标移动 /高亮菜单项弹出菜单动作
2009-7-20 365
举例,饮料自动售货机系统的状态图投入硬币
（有效的）
按下选择饮料键
Do:显示售货机在备用所有灯都关闭
Do:显示金额总数
Do:显示金额已够饮料选择灯亮取出饮料结算找零扣减存量完成交易饮料“售完”灯亮投入硬币金额
(1元,5元,10元 )
金额不足再投币存量为零无效的硬币取消取消回到备用状态回到备用状态时序图举例,打电话的时序挂断电话电话切断挂断电话通 话 通 话停止振铃停止振铃响应电话电话振铃铃 声拨 号 (3)
拨 号 (7
拨 号 (3)
拨 号 (2)
电话忙音结束拨 号 (8)
电话忙音开始拿起听筒电话线 接电话者打电话者举例,饮料自动售货机 系统 的时序图存量为零找零扣减存量灯亮余额饮料结算选择键 #
选择按纽灯亮金额总够显示总额总额累加投入硬币金额计算器 存量计算器顾客 售货机 选择键 售完灯
2009-7-20 368
功能模型用来描述系统中数据的变换。
传统 DFD + 控制流对象 A 对象 B过程 1 过程 2
数据存储区控制流数据流
2009-7-20 369
基于三个模型的分析步骤
需求陈述
对象建模
动态建模
功能建模
添加操作反复建模
2009-7-20 370
OMT支持整个软件生命周期,
需求分析、系统设计、系统实现、
测试与维护。
2009-7-20 371
OMT支持整个软件生命周期,
1,分析阶段,理解应用问题,建立 对象模型、
动态模型和功能模型，说明对象关联、控制流及数据变换。
2,系统设计阶段,确定 系统框架,考虑并发任务、通讯机制和数据存储策略。
3,对象设计阶段,从实现的角度 细化 分析对象模型、动态模型和功能模型
4,实现阶段,具体代码实现
2009-7-20 372
OMT方法的特点,
开发重点在分析阶段
强调数据结构而不是功能
形式化描述能力强
开发步骤的衔接良好
重复性的开发过程
2009-7-20 373
Yourdon的 OOA方法以类与对象图及对象状态图为辅助工具，建立问题域的五层模型,
OOA模型被划分为五个层次 (五个视图 )
2009-7-20 374
分析阶段由五个活动组成：
(1) 标识类及对象
(2) 标识结构
(3) 标识主题
(4) 定义属性及实例连接
(5) 定义服务及消息连接五个步骤常根据需要交叉进行
OOA的结构 类的边界
Class &object layer
(类及对象层 )
Attribute layer
(属性层 )
Service layer
(服务层 )
Structure layer
(结构层 )
Subject layer
(主题层 )
实例的边界实例连接消息连接主题服务属性
2009-7-20 376
步骤 1,识别类与对象
(1)发现对象主要策略,
考虑问题域?
人员?
组织?
物品?
设备?
事件?
表格结构
考虑系统边界?
人员?
设备?
外系统
考虑系统责任
2009-7-20 377
重点
问题域描述中的 名词,往往是候选的及对象 ;根据问题域结构可提取候选的类及对象 ;
2009-7-20 378
重点
与系统发生作用的 其它系统 和必要的 设备 可作为候选的类及对象 ;
如,打印机等
(分析阶段可不把与实现有关的计算机部件作为候选的类及对象 )
2009-7-20 379
重点
系统必须观测,记忆 的与时间有关的事件 可作为候选的类及对象 ;
如：建立帐户的日期打开一个帐户等
与系统发生交互的 人 及系统必须保留其信息的人,可作为候选的类及对象 ;
如：柜员、储户等
这些人所属的 组织 单位，可作为候选的类及对象 ;
如：总行、分行等
2009-7-20 380
重点
系统必须记忆、且不在问题域约束中的顺序 操作过程 (为了指导人机交互 )
可作为候选的类及对象 ;
如：柜员事务、远程事务等。
其中属性是操作过程名,操作特权及操作步骤的描述 ;
系统需了解掌握的物理位置、办公地点 等可作为候选的类及对象 ;
如,ATM机器、帐户等
2009-7-20 381
(2)审查和筛选
舍弃无用的类
对象的精简?
只有一个属性的对象?
只有一个服务的对象
推迟到 OOD考虑的对象
2009-7-20 382
帐册
@上级系统接口供货员销售事件商品特价商品 计量商品
@收款机商品一览表超市销售管理系统 (对象层 )
2009-7-20 383
步骤 2,定义属性与服务
定义属性
定义服务对象的状态与状态转换图例：栈的状态 /服务对照表
2009-7-20 384
例：栈状态转换图空半满满创建压入 (未满 )
弹出 (未空 )
压入
(报错 )
弹出 (报错 )
弹出 (已空 )
压入弹出压入 (已满 )
2009-7-20 385
定义服务对象行为分类发现服务的策略审查与调整识别对象的主动行为服务的详细说明 (服务解释、消息协议、
消息发送、约束条件、服务流程图 )
超市销售管理系统 (特征层 )
帐册前班节余销售事件表收入累计上交款本班节余接班计帐报帐交班
@上级系统接口帐目目册
@消息发送查帐报帐价格更新种类增删供货员缺货登记表缺货登记供货销售事件收款人购物清单应收款……
销售计划入帐商品编号名称单价架上数量下限售出补充价格更新特价商品开始日期结束日期计量商品
*单价计量单位计价方式
*售出
*补充
*价格更新
@收款机本班收款员开始时间结束时间
@登录售货结帐商品一览表商品目录检索种类增删
2009-7-20 387
建立数据字典为所有模型实体准备一个数据字典,
精确描述每一个对象类,包括,
成员
约束
关联、属性、操作
2009-7-20 388
对象字典举例：
类名 父类 提供的服务 需要的服务帐户
ATM
银行
出纳员
2009-7-20 389
步骤 3,定义结构与连接
初步确定关联
对应于描述性动词或动词短语
需求陈述中隐含
根据问题域知识得出
筛选
完善
2009-7-20 390
步骤 3,定义结构与连接
分析标识对象之间的关系
对象之间的分类关系：一般 -特殊结构
对象之间的组成关系：整体 -部分结构
对象之间的静态联系：实例连接
对象之间的动态关系：消息连接
2009-7-20 391
从一般类发现特殊类公司职员股东姓名身分证号码
……
股份
……
职员工资
……
公司职员姓名身分证号码股份工资
……
…… …… ……
……
？
？
2009-7-20 392
从特殊类发现一般类公司职员股东姓名身分证号码
……
股份
……
职员工资
……
…… ……
……
股东姓名身分证号码股份
…………
职员姓名身分证号码工资
…………
？
2009-7-20 393
收款机类成为可供本领域其它系统复用的领域构件 收款机
A
B
C
现钞收款机
D
E
F
现钞收款机
A
B
C
D
E
F
X
Y
Z Z
X
Y
为支持复用建立结构取消没有特殊属性的特殊类大学生 研究生研究方向指导教师
……
学生姓名学号班级
……
……
研究生研究方向指导教师
……
学生姓名学号班级
……
……
2009-7-20 395
通过增加属性简化一般 -特殊结构人员……
……
男人
……
……
女人
……
……
……
……
美国人
……
……
日本人
……
……
人员性别国籍……
……
中国人
2009-7-20 396
两种结构的变通冷藏车
……
……
汽车
……
……
制冷设备
……
……
冷藏车
……
……
汽车
……
……
制冷设备
……
……
仅用一般
-特殊结构两种结构同 用冷藏车
……
……
汽车
……
……
制冷设备
……
……
仅用整体
-部分结构
2009-7-20 397
用整体 -部分结构实现复用车床
……
……
机床 ……
……
刨床
……
……
起重机 ……
……
电动机 …
………
钻床
……
……
送料车 ……
……
2009-7-20 398
筛选：删除下列关联
已删去的类间的关联
无关或实现关联
瞬时事件
三元关联
派生关联
2009-7-20 399
步骤 4,定义服务及消息连接
分析和认识对象之间在行为上的往来关系
2009-7-20 400
顺序系统中的消息传递主动对象 A
a
被动对象 B
b
被动对象 C
c
被动对象 D
d1 d2
运行开始运行结束服务执行消息发送控制点返回示意
2009-7-20 401
并发系统中的消息传递主动对象 A 主动对象 B
被动对象 D
任务 Task1
线程 Ta
控制线程之间的消息连接控制点返回示意被动对象 C 被动对象 E
控制线程内部的消息连接任务 Task2
线程 Tb
2009-7-20 402
多个控制线程之间的消息与顺序系统中消息的不同之处
(1)并发执行的控制线程之间传送的 消息的不同用途：
向 接收者发出访问请求
向接收者提交数据
向接收者发布通知或事件信息
向接收者传递同步控制信号
(2)消息的同步与异步
(3)接收者对消息的不同响应方式
(4)发送者对消息处理结果的不同期待方式
(5)消息的接收者是否唯一?
定向消息
广播消息
2009-7-20 403
OOA对消息的表示 —消息连接消息连接是 OOA（或 OOD） 模型中对对象之间行为依赖关系的表示识别和表示的主要问题,?
对象之间是否存在消息？
消息是同一线程内部的还是不同线程之间的？
每一种消息是从发送者哪个服务发出的？
由接收者哪个服务响应处理的？
消息是同步还是异步？
发送者 是否等待消息的处理结果？
2009-7-20 404
如何建立消息连接
(1)建立控制线程内部的消息连接基本策略：,服务模拟,
,执行路线追踪,
具体做法：
人为地模拟当前服务的执行，通过考虑需要请求其它对象的服务来发现新消息。
分析该消息的发送者与接收者在执行时是否属于同一控制线程
2009-7-20 405
(2)建立控制线程之间的消息连接对每个控制线程考虑：?
它在执行时是否需要请求其它控制线程中的对象为它提供服务？由哪个对象发出？由哪个对象中的服务处理？
它在执行时是否要向其它控制线程中的对象提供或索取数据？
它在执行时是否将产生对其它控制线程的执行有影响的事件？
各个控制线程的并发执行是否要传递同步控制信号
一个控制线程在何种条件下中止执行？
中止后在何种条件下由其它控制线程用何法唤醒?
2009-7-20 406
(3)对象分布问题及对消息的影响
每台处理机上分布的一组对象中至少应有一个主动对象；
同一台处理机上的对象之间的消息通信既可能是一个控制线程内部的，也可能是不同控制线程之间的。
(关系层,完整的类图 )
帐册前班节余销售事件表收入累计上交款本班节余接班计帐报帐交班
@上级系统接口帐目目册
@消息发送查帐报帐价格更新种类增删供货员缺货登记表缺货登记供货销售事件收款人购物清单应收款
……
销售计划入帐商品编号名称单价架上数量下限售出补充价格更新特价商品开始日期结束日期计量商品
*单价计量单位计价方式
*售出*补充
*价格更新
1 m
商品一览表商品目录检索种类增删
1m
@收款机本班收款员开始时间结束时间
@登录售货结帐
2009-7-20 408
步骤 5,标识主题 (主体 )
Coad/Yourdon方法中主题的概念：
主题是把一组具有较强联系的类组织在一起而得到的类的集合。
2009-7-20 409
主题概念及其用途
主题层是在 OOA基本模型 (类图 )之上建立一个能帮助人们从不同的认识层次来理解系统的补充模型；
主题一种比类和对象抽象层次更高、粒度更大的概念，用以建立系统的高层抽象视图；?
主题有助于指导系统设计者或用户等理解一个大的系统模型,有助于组织一个大项目的工作。
2009-7-20 410
主题概念的特点
是由一组类构成的集合?
一个主题内部的对象类应具有某种意义上的内在联系
描述系统中相对独立的组成部分（如一个子系统）
描述系统中某一方面的事物（如人员、设备）
解决系统中某一方面的问题（如输入输出）?
主题的划分有一定的灵活性和随意性
2009-7-20 411
如何划分主题
把每个结构作为一个主题；
(选取结构中最上层的类作为一主题 )
通过实例连接互相联系的类可划分到一个主题；
把不属于任何结构，也没有实例连接的类作为一个主题。
2009-7-20 412
如何精练主题从 问题域 和 接口复杂性 两方面入手,
使用问题域精练主题,即用整体 /部分结构对问题域进行划分,而不是按功能分解方法划分,
按高内聚低偶合原则,通过使主题间依赖性和交互性最小原则保留能反映子问题域的主题,
主题数目 >7个左右,则进一步精练主题,
2009-7-20 413
何时引入主题依赖于模型自身复杂性
小系统,不需引入主题 ;
中等系统,先标识类及对象,
然后引入主题 ;
大系统,先标识主题,对问题域进行划分,分给不同的任务组
2009-7-20 414
主题层次的控制
中小型系统可只设一层主题，最多不超过两层；
大型系统可只设两层主题，最多不超过三层 。
(关系层,完整的类图 )
帐册前班节余销售事件表收入累计上交款本班节余接班计帐报帐交班
@上级系统接口帐目目册
@消息发送查帐报帐价格更新种类增删供货员缺货登记表缺货登记供货销售事件收款人购物清单应收款
……
销售计划入帐商品编号名称单价架上数量下限售出补充价格更新特价商品开始日期结束日期计量商品
*单价计量单位计价方式
*售出*补充
*价格更新
1 m
商品一览表商品目录检索种类增删
1m
@收款机本班收款员开始时间结束时间
@登录售货结帐
1
1 1
1
33
33
2
2
2
2
2009-7-20 416
第五章 人机界面设计
2009-7-20 417
概念
人机界面（ Human Computer Interface,简称
HCI）通常也称为 用户界面界面设计 主要包括三个方面：
设计软件构件之间的接口
设计模块和其他非人的信息生产者和消费者的界面
设计人（如用户）和计算机间的界面
2009-7-20 418
界面的设计原则
分析用户类型
应用程序和界面分离
一致性
尽量减少用户工作
提供反馈
出错处理和帮助功能
增加可视化图形表示
2009-7-20 419
黄金规则在有关界面设计的著作中，
Theo Mandel创造了 三条 黄金原则,
置用户于控制之下
减少用户的记忆负担
保持界面一致
2009-7-20 420
黄金规则：置用户于控制之下
Mandel定义的一组允许用户操作控制的原则,
以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
提供灵活的交互
允许用户交互可以被中断和撤消
当技能级别增加时可以使交互流水化并允许定制交互
使用户隔离内部技术细节
设计应允许用户和出现在屏幕上的对象直接交互
2009-7-20 421
黄金规则：减少用户的记忆负担
Mandel定义了一组设计原则，使界面能够减少用户记忆负担,
减少对短期记忆的要求
建立有意义的缺省
定义直觉性的捷径
界面的视觉布局应该基于真实世界的隐喻
以不断进展的方式揭示信息
2009-7-20 422
界面举例 MSN
2009-7-20 423
界面举例红心大战缺省值
2009-7-20 424
黄金规则：保持界面一致用户应以一致的方式展示和获取信息
所有可视信息的组织均按照均按照贯穿所有屏幕显示所保持的设计标准
输入机制被约束到有限的集合，在整个应用中被一致地使用
从任务到任务的导航机制被一致地定义和实现
2009-7-20 425
帮助保持界面一致性的设计原则
允许用户将 当前任务 放入有意义的语境
在应用系列内保持一致性
如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要改变它
2009-7-20 426
用户友好性设计用户友好性 一般属软件的性能特性，它独立于所有具体功能，却影响着所有功能的重用性。
用户友好性 应体现在与用户有接口的软件特性上。
用户友好性的根本 目的 是为了软件可重用性、可维护性。
2009-7-20 427
用户友好性的标志
可操作性
健壮性
易学习性
可扩展性
2009-7-20 428
界面设计模型
软件工程师创建的 设计模型
（ design model）
人员工程师创建的 用户模型
（ user model）
终端用户对未来 系统的假想 （ sysytem
perception或 user’s model）
系统实现后得到的 系统映象 （ sysytem
image）
四种模型可能相差甚远，
界面设计人员的任务就是消除这些差距，导出一致的界面表示设计用户界面要考虑四种模型：
2009-7-20 429
用户界面设计过程用户界面设计过程包括四种不同的框架,
用户、任务和环境分析及建模
界面设计
界面构造
界面确认
2009-7-20 430
用户分析
偶然型
生疏型
熟练型
专家型
新手
对系统有了解的中级用户
对系统有了解的经常用户用户类型,
2009-7-20 431
影响用户行为特性的因素
人 -机匹配性
人的固有技能
人的固有弱点
用户的知识经验
用户对系统的期望和态度
2009-7-20 432
用户对计算机系统的要求
让用户灵活地使用
适应不同类型用户
系统的行为及效果对用户透明
用户对系统的期望和态度
提供联机帮助功能
人机交互尽可能和人际通信相似
2009-7-20 433
用户技能方面的使用需求
应让系统去适应用户
使用易于理解、掌握的准自然语言
一致性的系统设计
用户对系统的期望和态度
能通过系统学习
系统提供演示及范例
2009-7-20 434
用户习性方面的使用需求
系统应让用户有耐心
系统应很好地对付人的易犯错误
系统应对不同用户提供不同交互方式
2009-7-20 435
用户经验、知识方面的使用需求
系统应能让未经专门训练的用户使用
系统能对不同经验用户做出不同反应
提供同一系统的一致性，建立标准化人 -
机界面
系统必须适应用户在应用领域的知识变化，提供动态的自适应的设计
2009-7-20 436
用户对系统的期望方面的要求
用户界面应提供形象、生动、美观的布局显示和操作环境
系统处理问题应尽可能简单，提供学习机制
系统应对不同用户提供不同交互方式
2009-7-20 437
人 -机界面的交互方式菜单界面按显示形象分类,
正文菜单
图标菜单
正文图标混合菜单按屏幕位置和操作风格分类,
固定
浮动
下拉式
嵌入式菜单举例图标式菜单 菜单条弹出式菜单弹出式帮助文本
2009-7-20 439
菜单举例下拉式菜单、瀑布式菜单瀑布式菜单
2009-7-20 440
菜单举例
2009-7-20 441
菜单举例
2009-7-20 442
菜单举例
2009-7-20 443
对话对话形式,
(1)必须回答式
(2)无需回答式
(3)警告式对话实现方式,
(1)标准对话
(2)定做式对话
2009-7-20 444
界面其他元素
3,功能键
4,图符界面
5,填表界面
6,命令语言界面
7,查询语言界面
8,自然语言界面
2009-7-20 445
控制界面的设计
(1)用控制对话选择操作命令
(2)用菜单界面进行控制
(3)用功能键定义操作命令
(4)用图标表示对象或命令
2009-7-20 446
界面设计过程的步骤
建立任务的目标和意图
为每个目标和意图制定特定的动作序列
按在界面上执行的方式对动作序列进行规约
指明系统状态，即执行动作时的界面表现
定义控制机制，即用户可用的改变系统状态的设备和动作
指明控制机制如何影响系统状态
指明用户如何通过界面上的信息解释系统状态
2009-7-20 447
定义界面对象和动作为创建描述图符的图形设计和放置、描述性屏幕文字的定义、窗口的规约和命名、菜单项的规约的屏幕布局提供基础。
响应时间、命令和动作结构、错误处理和帮助设施等设计问题应该在精化设计模型时考虑。
2009-7-20 448
导航方式线性层次
2009-7-20 449
导航方式网络式混合式
2009-7-20 450
数据输入界面设计数据输入的规则
明确的输入
明确的动作
明确的取消
确认删除
提供反馈
允许编辑
提供复原（ Undo）
自由格式
提示输入的范围
2009-7-20 451
数据显示界面设计数据显示的规则
只显示必要的数据
在一起使用的数据显示在一起
显示出的数据应与用户执行的任务有关
每一屏数据的数量不应超过整个屏幕面积的 30%
屏幕布局规则
尽量少用代码和缩写
多个显示画面，应建立统一格式
提供明了的标题、标栏及其它提示信息
遵循用户习惯
采用颜色、字符大小、下划线、不同字体等方式强化重要数据
2009-7-20 452
界面举例
2009-7-20 453
界面举例
2009-7-20 454
界面举例
2009-7-20 455
界面举例
2009-7-20 456
第五章 软件测试
2009-7-20 457
编程阶段的基本概念 （ page 126）
编程的定义
编程的目标
什么是程序可读性
2009-7-20 458
程序设计语言 （ page 127）
程序设计语言的种类
BASIC
COBOL
FORTRAN
PASCAL
C
LISP
其他语言
2009-7-20 459
选择语言 （ page 130）
项目的应用领域
算法和计算复杂性
软件的执行环境
性能因素
数据结构的复杂性
软件开发人员的水平
2009-7-20 460
SP方法和编程 （ page 130）
SP方法帮助产生简单清晰的程序
程序内部文档（ Note ）
序言性注释
描述性注释
编程风格
变量名的选择
表达式的书写
2009-7-20 461
程序的效率 （ Note 54）
效率主要指处理机时间和存储器容量两个方面。
可从三个方面讨论效率问题：
程序运行时间
存储器效率
输入 /输出的效率
2009-7-20 462
第六章 软件测试
2009-7-20 463
基本概念
软件开发过程必须伴有质量保证活动。
软件测试是软件质量保证的关键元素，
代表了规约、设计和编码的最终检查。
2009-7-20 464
动态测试方法
(1)选取定义域有效值,或定义域外无效值,
(2)对已选取值决定 预期的结果
(3)用选取值执行程序
(4)执行结果 与 (2)结果相比,
不吻和程序有错,
2009-7-20 465
测试用例设计选择测试用例是软件测试员最重要的一项工作。
测试用例的属性,
属性 描述
name 测试用例的名称
location 可执行的完全路径名
input 输入数据或命令
oracle 与测试输入相比较的期待测试结果
log 测试生产的输出
2009-7-20 466
软件测试信息流软件配置测试测试配置测试工具结果分析排错可靠性分析测试结果错误预期结果出错率改正的软件预测的可靠性需求规格说明书软件设计说明书被测源程序测试计划测试用例
(测试数据 )
测试驱动程序
2009-7-20 467
测试活动和相关工作产品项目协议对象设计 客户开发人员 用户集成策略系统分解功能性需求非功能性需求单元测试集成测试结构测试功能测试性能测试用户手册验收测试安装测试现场测试日常操作
2009-7-20 468
测试设计中需要考虑的 22种测试类型
黑盒测试
白盒测试
单元测试
累计综合测试
集成测试
功能测试
系统测试
端到端测试
健全测试
衰竭测试
接受测试
负载测试
强迫测试
性能测试
可用性测试
安装 /卸载测试
恢复测试
兼容测试
安全测试
比较测试
Alpha测试
Beta测试
2009-7-20 469
测试的方法与技术软件测试的策略和方法静态测试方法动态测试方法人工测试方法计算机辅助静态分析方法白盒测试方法黑盒测试方法
2009-7-20 470
动态黑盒测试 — 闭着眼睛测试软件软件输入不深入代码细节的测试方法称为动态黑盒测试。
软件测试员充当客户来使用它。
输出
2009-7-20 471
动态白盒测试 —带上 X光眼镜测试
3581322.293419985680302829734315
250*(1+0.015)*((1+0.015)^360-1)/0.015 250*(1+0.015)*((1+0.015)^360-1)/0.015
假如知道一个盒子包含一台计算机,而另一个盒子是人用纸笔计算,就会选择不同的测试用例了解软件的运作方式会影响测试手段
2009-7-20 472
黑盒测试又称,功能测试数据驱动测试基于规格说明书的测试
2009-7-20 473
白盒测试又称,开盒测试结构测试玻璃盒测试基于覆盖的测试,
根据被测程序的逻辑结构设计测试用例 ;
力求提高测试覆盖率 ;
2009-7-20 474
黑盒测试与白盒测试比较黑盒测试 是从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例,是根据程序 外部特征 进行测试。
白盒测试 是根据程序 内部逻辑结构 进行测试。
2009-7-20 475
黑盒测试与白盒测试优缺点比较黑盒测试 白盒测试优点缺点性质
① 适用于各阶段测试
②从产品功能角度测试
③容易入手生成测试数据
① 可构成测试数据使特定程序部分得到测试
②有一定的充分性度量手段
③可或较多工具支持
① 某些代码得不到测试
②如果规格说明有误，
则无法发现
③不易进行充分性测试
① 不易生成测试数据 (通常 )
② 无法对未实现规格说明的部分进行测试
③工作量大，通常只用于单元测试，有应用局限是一种 确认 技术，回答
,我们在构造一个正确的系统吗？,
是一种 验证 技术，回答
,我们在正确 地构造一个系统吗？,
2009-7-20 476
黑盒测试与白盒测试不论黑盒还是白盒测试都 不能进行穷尽测试,所以软件测试不可能发现程序中存在的所有错误,因此需精心设计测试方案,力争尽可能少的次数,测出尽可能多的错误,
2009-7-20 477
黑盒测试与白盒测试能发现的错误
C BA
D
-只能用黑盒测试发现的错误A
-只能用白盒测试发现的错误
-两种方法都能发现的错误
-两种方法都不能发现的错误
B
C
D
2009-7-20 478
白盒测试的测试用例设计逻辑覆盖法
(1)语句覆盖
(2)判定覆盖
(3)条件覆盖
(4)判定 /条件覆盖
(5)条件组合覆盖
(6)路径覆盖
(7)点覆盖
(8)边覆盖
2009-7-20 479
举例：
例,PROCEDURE SAMPAL
(A,B,REAL； VAR X,REAL);
BEGIN
IF (A>1) AND (B=0)
THEN X:=X/A
IF (A=2) OR (X>1)
THEN X:=X+1
END;
2009-7-20 480
举例：
开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
2009-7-20 481
(1)语句覆盖
使程序中每个语句至少执行一次
2009-7-20 482
语句覆盖开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
2009-7-20 483
语句覆盖只需设计一个测试用例,
输入数据,A=2,B=0,X=4
即达到了语句覆盖 ;
语句覆盖是 最弱 的逻辑覆盖
2009-7-20 484
(2)判定覆盖 (分支覆盖 )
使每个判定的真假分支都至少执行一次
2009-7-20 485
判定覆盖 (分支覆盖 )
开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
2009-7-20 486
例,可设计两组测试用例,
A=3,B=0,X=3 可覆盖 c,d分支
A=2,B=1,X=1 可覆盖 b,e分支两组测试用例可覆盖所有判定的真假分支判定覆盖仍是 弱 的逻辑覆盖
2009-7-20 487
(3)条件覆盖使每个判定的每个条件的可能取值至少执行一次
2009-7-20 488
条件覆盖第一判定表达式,
设 条件 A>1 取真 记为 T1
假 T1
条件 B=0 取真 记为 T2
假 T2
第二判定表达式,
设 条件 A=2 取真 记为 T3
假 T3
条件 X>1 取真 记为 T4
假 T4
2009-7-20 489
条件覆盖开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
满足条件,T1,T1,
T2,T2
T3,T3
T4,T4
2009-7-20 490
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
1 0 3 abe T1,T2,T3,T4 b,e
2 1 1 abe T1,T2,T3,T4 b,e
两个测试用例 覆盖了四个条件八种可能取值 。
未覆盖 c,d分支,不满足判定覆盖的要求,
条件覆盖不一定包含判定覆盖判定覆盖也不一定包含条件覆盖
2009-7-20 491
(4)判定 /条件覆盖选取足够多的测试用例,使判断中的每个条件的所有可能取值至少执行一次,
同时每个判断本身的所有可能判断结果至少执行一次,
2009-7-20 492
判定 /条件覆盖开始
(A>1) AND (B=0)
(A=2) OR (X>1)
返回
X=X/A
X=X+1
F
F
T
T
a
b
d
c
e
满足条件,T1,T1,
T2,T2
T3,T3
T4,T4
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
2 0 4 ace T1,T2,T3,T4 c,e
2 1 1 abd T1,T2,T3,T4 b,d
能同时满足判定、条件两种覆盖标准。
取值。
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
2 0 3 ace T1,T2,T3,T4 c,e
2 1 1 abe T1,T2,T3,T4 b,e
1 0 3 abe T1,T2,T3,T4 b,e
1 1 1 abd T1,T2,T3,T4 b,d
2009-7-20 495
(5)条件组合覆盖所有可能的条件取值组合至少执行一次
A>1,B=0
A>1,B≠0
A≯ 1,B=0
A≯ 1,B≠0
A=2,X>1
A=2,X≯ 1
A≠2,X>1
A≠2,X≯ 1
测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
2 0 4 ace T1,T2,T3,T4 c,e
2 1 1 abe T1,T2,T3,T4 b,e
1 0 2 abd T1,T2,T3,T4 b,d
1 1 1 abd T1,T2,T3,T4 b,d
2009-7-20 497
(6)路径覆盖覆盖每一个可能的路径测试用例 通过 满足的 覆盖
A B X 路径 条件 分支
1 1 1 abd T1,T2,T3,T4 b,d
1 1 2 abe T1,T2,T3,T4 b,e
3 0 1 acd T1,T2,T3,T4 c,d
2 0 4 ace T1,T2,T3,T4 c,e
2009-7-20 498
基本路径测试法
通过分析由控制构造的环路的复杂性，
导出基本路径集合，从而设计测试用例，
保证这些路径至少通过一次。
2009-7-20 499
黑盒测试的测试用例设计等价类划分法把所有可能的输入数据 (有效的和无效的 )划分成若干个等价的子集 (称为等价类 ),使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同,
可从每个子集中选取一组数据来测试程序
2009-7-20 500
例,某报表处理系统要求用户输入处理报表的日期，日期限制在 2001年 1
月至 2005年 12月，即系统只能对该段期间内的报表进行处理，如日期不在此范围内，则显示输入错误信息。
系统日期规定由年、月的 6位数字字符组成，前四位代表年，后两位代表月。
如何用等价类划分法设计测试用例,
来测试程序的日期检查功能？
2009-7-20 501
如何划分等价类？
有效等价类 (合理等价类 )
无效等价类 (不合理等价类 )
划分等价类的标准：
覆盖
不相交
代表性
2009-7-20 502
划分等价类的规则 （ page 157）
(1)如果输入条件规定了取值范围，
可定义一个有效等价类和两个无效等价类。
例 输入值是学生成绩，范围是 0～ 100
0 100
有效等价类
1≤ 成绩 ≤ 100
无效等价类成绩 >100
无效等价类成绩 <0
～
2009-7-20 503
划分等价类的规则：
(2)如果输入条件代表集合的某个元素，则可定义一个有效等价类和一个无效等价类。
2009-7-20 504
划分等价类的规则
(3)如规定了输入数据的一组值,且程序对不同输入值做不同处理,
则每个允许的输入值是一个有效等价类,并有一个无效等价类
(所有不允许的输入值的集合 )。
例：输入条件说明学历可为,专科,本科,
硕士,博士 四种之一,则分别取这四种这四个值作为 四个有效等价类,另外把四种学历之外的任何学历作为无效等价类
2009-7-20 505
用等价类划分法设计测试用例步骤
(1)形成等价类表,每一等价类规定一个唯一的编号；
(2)设计一测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类,
重复这一步骤,直到所有有效等价类均被测试用例所覆盖；
(3)设计一新测试用例,使其只覆盖一个无效等价类,重复这一步骤直到所有无效等价类均被覆盖；
2009-7-20 506
划分等价类的规则
(4)如果规定了输入数据必须遵循的规则,可确定一个有效等价类 （ 符合规则 ） 和若干个无效等价类 （ 从不同角度违反规则 )。
(5)如已划分的等价类各元素在程序中的处理方式不同,则应将此等价类进一步划分成更小的等价类 。
2009-7-20 507
第一步：等价类划分输入等价类 有效等价类 无效等价类报表日期的类型及长度 3位数字字符 (1)
有非数字字符 (4)
少于 6个数字字符 (5)
多于 6个数字字符 (6)
年份范围 在 2001～ 2005之间 (2) 小于 2001 (7)大于 2005 (8)
月份范围 在 1～ 12之间 (3)
“报表日期,输入条件的等价类表小于 1 (9)
大于 12 (10)
2009-7-20 508
第二步为有效等价类设计测试用例对表中编号为 1,2,3的 3个有效等价类用一个测试用例覆盖,
测试数据 期望结果 覆盖范围
200105 等价类 (1)(2)(3)输入有效
2009-7-20 509
第三步：为每一个无效等价类设至少设计一个测试用例测试数据 期望结果 覆盖范围
001MAY 等价类 (4)输入无效
20015 等价类 (5)输入无效
2001005 等价类 (6)输入无效
200005 等价类 (7)输入无效
200805 等价类 (8)输入无效
200100 等价类 (9)输入无效
200113 等价类 (10)输入无效不能出现相同的测试用例本例的 10个等价类至少需要 8个测试用例例,对招干考试系统“输入学生成绩”
子模块设计测试用例招干考试分三个专业,准考证号第一位为专业代号,如,1-行政专业,
2-法律专业,
3-财经专业,
行政专业准考证号码为,110001～ 111215
法律专业准考证号码为,210001～ 212006
财经专业准考证号码为,310001～ 314015
例,准考证号码的等价类划分有效等价类,
(1) 110001 ～ 111215
(2) 210001 ～ 212006
(3) 310001 ～ 314015
无效等价类,
(4) -? ～ 110000
(5) 111216 ～ 210000
(6) 212007 ～ 31000
(7) 314016 ～ +?
例,计算给定月份中天数的方法接口
(java):
Class MyGregorianCalender{
……
public static in getNumDaysInMonth(int
month,int year){…}
……
}
getNumDaysInMonth( )方法有两个参数,月和年,年份的有效输入是从 0到 maxInt.
