大学软件工程——原理、方法与应用（第二版）-肖孟强-大学教学资料课件PPT
收藏
资源目录
压缩包内文档预览：(预览前20页/共30页)
编号：21835904
类型：共享资源
大小：12.47MB
格式：ZIP
上传时间：2019-09-06
上传人：QQ24****1780
认证信息
个人认证
王**（实名认证）
浙江
IP属地：浙江
25
积分
- 关 键 词：
-
大学
软件工程
原理
方法
法子
应用
利用
运用
第二
孟强
教学
资料
课件
ppt
- 资源描述：
-
大学软件工程——原理、方法与应用（第二版）-肖孟强-大学教学资料课件PPT,大学,软件工程,原理,方法,法子,应用,利用,运用,第二,孟强,教学,资料,课件,ppt
- 内容简介：
-
21世纪高等院校规划教材软件工程原理、方法与应用肖孟强 王宗江 主 编中国水利水电出版社第1章 软件工程概论学习目标掌握软件的概念及特点 掌握软件危机的产生及消除途径 掌握软件工程的概念及其研究内容 掌握软件生存周期的定义及其模型 第1章 软件工程概论 教学内容 1.1 引 言 1.2 软件概述 1.3 软件危机 1.4 软件工程 1.5 软件生存周期 1.6 软件生存周期模型 本章小结 1.1 引 言 计算机及其相关技术的发展是很快的 ，但软件的开发没有摆脱手工制作的过程，开发人员对软件开发的认识存在一些偏差，严重影响了软件的发展。于是，许多计算机和软件科学家进行了一些尝试，把其他工程领域中行之有效的方法运用到软件开发中来，形成了软件工程。 本教材以大家都比较熟知的学生成绩管理系统为案例， 进行软件工程的讲解与学习。返回目录1.1 引 言学生成绩管理系统总体框图如下： 返回目录1.1 引 言 系统模块功能确定以后，下一步就要对模块的功能和性能、数据结构、用户界面等进行必要的设计；然后进入程序编码、软件测试等阶段，而后方可交付用户使用。 在用户使用的过程中，还要对程序进行不断的完善与修改，以满足用户的实际需要。返回目录1.2 软件概述 1.2.1 软件的定义 软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档组成的完整集合。 可以写作为：软件=程序+数据+文档。 程序：程序是按事先设计好的功能和性能要求执行的指令序列。 数据：数据是指程序能正常处理信息的数据和数据结构。 文档：文档是与程序运行和维护有关的图文资料。 返回目录1.2 软件概述1.2.2 软件的特点（1） 软件具有抽象特征。（2） 软件具有无明显制造过程特征。（3） 软件无备件的特征。（4） 手工制作特征。（5） 成本昂贵特征。1.2 软件概述1.2.3 软件的分类 1按软件功能进行划分 （1）系统软件 （2）支撑软件 （3）应用软件 2按软件规模进行划分 按开发软件所需的人力、时间以及完成的源程序行数，可确定六种不同规模的软件。如表1.1所示。1.2 软件概述表1.1软件规模的分类 1.2 软件概述1.2.4 软件的发展 1程序设计阶段 20世纪40年代中期到20世纪60年代中期 2.程序系统阶段 20世纪60年代中期到20世纪70年代中期 3.软件工程阶段 20世纪70年代中期到20世纪90年代 4.第四代技术阶段 1.3 软件危机 20世纪60年代中期以后，一些开发大型软件系统的要求提了出来。然而软件技术的进步一直未能满足形势发展的需要，在大型软件的开发过程中出现了复杂程度高、研制周期长、正确性难以保证的三大难题。遇到的问题找不到解决办法，致使问题堆积起来，形成了人们难以控制的局面，出现了所谓的“软件危机”。 软件危机是指在软件开发和维护中所产生的一系列严重的问题。一是如何开发软件，满足用户对软件的需求，二是如何维护数量众多的已有软件。 1963年，美国用于控制火星探测器的计算机软件中的一个“，”号被误写为“。”，而致使飞往火星的探测器发生爆炸，造成高达数亿美元的损失。返回目录1.3 软件危机1.3.1 软件危机产生的原因（1）软件是逻辑部件，缺乏“可见性”，且软件产品往往规模庞大，维护困难。（2）软件一般要使用510年，在这段时间里，软件需求发生变化等，都需要及时地对软件进行维护，以延长软件的使用寿命。（3）软件开发技术落后，生产方式和开发工具落后。（4）软件开发人员忽视软件需求分析的重要性，轻视软件维护。1.3.2 软件危机的表现形式（1）软件发展速度跟不上硬件的发展和用户的需求。（2）对软件成本和进度估计不准确，用户不满意。（3）软件产品质量差，可靠性不能保证 。（4）软件产品可维护性差。 （5）软件没有合适的文档资料。 1.3 软件危机1.3.3 解决软件危机的途径（1）应该加强软件开发过程的管理。（2）推广使用开发软件的成功技术与方法，并且不断探索更好的技术与方法。（3）开发和使用好的软件工具,建立软件工程支持环境。 总之，为了解决软件危机，既要有技术措施（好的方法和工具），又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。 1.4 软件工程 1968年和1969年北大西洋公约组织成员国软件工作者两次召开会议（NATO会议），讨论摆脱软件危机的办法，提出了软件工程的概念，试图建立并使用正确的工程方法开发出成本低、可靠性好并能高效运转的软件，从而解决或缓解软件危机。返回目录1.4 软件工程1.4.1 软件工程的定义及目标 人们曾从不同的角度，给软件工程下过各种定义。 Fritz Bauer曾经为软件工程下了定义：“软件工程是为了经济地获得能够在实际机器上有效运行的可靠软件而建立和使用的一系列完善的工程化原则。” 1983年IEEE给出的定义为：“软件工程是开发、运行、维护和修复软件的系统方法”，其中，“软件”的定义为：计算机程序、方法、规则、相关的文档资料以及在计算机上运行时所必需的数据。 中华人民共和国国家标准GB/T114571995软件工程术语的定义是：“软件工程是软件开发、运行、维护和引退的系统方法”。 许多定义的主要思想都是强调在软件开发过程中需要应用工程化原则的重要性。软件工程是指导计算机软件开发和维护的工程学科。 1.4 软件工程 软件工程的目标可概括为：在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性并满足用户要求的软件产品。图1.2 软件工程目标之间的关系 1.4 软件工程1.4.2 软件工程学的范畴 软件工程学所研究的主要内容包括：软件开发技术和软件工程管理两个方面。其中：软件开发技术包含：1软件开发方法学（Software Development Methods） （1）传统方法学 传统方法学也称为生命周期方法学或结构化范型 （2）面向对象方法学 面向对象 = 对象 + 类 + 继承 + 消息通信2软件工具（Software Tools）3软件工程环境（Software Engineering Environment，简称SEE） 4软件工程管理1.4 软件工程1.4.3 软件过程 软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 在完成开发任务时必须进行一些开发活动，并且使用适当的资源，在过程结束时将把输入转化为输出。因此，ISO 9000把过程定义为“使用资源将输入转化为输出的活动所构成的系统。”此处，“系统”的含义是广义的：“系统是相互关联或相互作用的一组要素。”1.4 软件工程1.4.4 软件工程的基本原理 著名软件工程专家B.W.Boehm综合有关专家和学者的意见并总结了多年来开发软件的经验，于1983年在一篇论文中提出了软件工程的7条基本原理:（1）用分阶段的生命周期计划严格管理（2）坚持进行阶段评审（3）实行严格的产品控制（4）采用现代程序设计技术（5）软件工程结果应能清楚地审查（6）开发小组的人员应该少而精（7）承认不断改进软件工程实践的必要性 遵循前6条基本原理，能够实现软件的工程化生产；按照第7条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。 1.5 软件生存周期1.5.1 软件生存周期定义 软件生存周期是从设计软件产品开始到产品不能使用为止的时间周期。软件产品从问题定义开始，经过开发、使用和维护，直到最后被淘汰的整个过程就是软件生存周期。 概括地说，软件生命周期由软件定义、软件开发和运行维护（也称为软件维护）3个时期组成，每个时期又进一步划分成若干个阶段。返回目录1.5 软件生存周期1定义时期 主要任务是：确定软件开发工程必须完成的总目标；确定工程可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。软件定义时期通常进一步划分成3个阶段，即问题定义、可行性研究和需求分析。 2开发时期 具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：总体设计、详细设计、编码和单元测试、综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。 3维护时期 主要任务是使软件持久地满足用户的需要。具体地说，当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件以满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。1.5 软件生存周期1.5.2 软件生存周期划分阶段的原则 软件生存周期划分阶段的原则如下：（1）各阶段的任务彼此间尽可能相对独立。这样便于逐步完成各个阶段的任务，能够简化各个阶段的工作，容易确立系统开发计划。（2）同一阶段的工作任务性质尽可能相同。这样有利于软件工程的开发和组织管理，明确系统各类开发人员的分工与职责范围，以便协同工作，保证质量。1.5 软件生存周期1.5.3 软件生存周期各阶段的任务 1问题定义 该阶段是软件生存期中最短的一段。该阶段要确定系统“解决什么问题”。系统分析员通过问题定义阶段弄清楚问题的性质、软件系统的目标和规模，并以书面的形式向用户提交，请用户审查和认可。 2可行性研究 该阶段对问题定义阶段确定的系统目标进行全面地分析，研究完成该项软件任务的可行性，探讨解决问题的可能方案，并对可利用的资源（计算机硬件、软件、人力等）、成本、可取得的效益、开发的进度做出估算，制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查。1.5 软件生存周期1.5.3 软件生存周期各阶段的任务3需求分析 该阶段主要解决的问题是“目标系统必须做什么”，也就是要深入描述软件的功能和性能；确定软件设计的限制和软件与其他系统元素的接口；定义软件的其他有效性需求，并用“需求规格说明书”的形式准确地表达出来，提交管理机构评审。 4软件设计 该阶段是软件工程的技术核心，主要任务是把已确定了的各项需求转换成一个相应的体系结构，通常细分成总体设计和详细设计两个阶段。 总体设计：又称概要设计，需要解决的问题是“应该如何较宏观地解决问题”。 详细设计：该阶段需要解决的问题是“如何具体地实现这个系统”。1.5 软件生存周期1.5.3 软件生存周期各阶段的任务 5编码和单元测试 该阶段的主要任务就是按照选定的语言把软件设计转换成计算机可以接受的程序代码， 即写成以某一种特定程序设计语言表示的“源程序清单”。 6综合测试 测试是保证软件质量的重要手段，其主要方式是在设计测试用例的基础上检验软件的各个组成部分。 7运行/维护 其原因可能有：运行中发现了错误需要修正；为适应变化了的工作环境，需要做适当变更；为增强软件的功能需做变更等。因此，软件人员在这一时期的主要工作就是做好软件维护。1.6 软件生存周期模型1.6.1 瀑布模型（Waterfall model） 瀑布模型（也称线性顺序模型或软件生存周期模型），是W.Royce在1970年提出的。瀑布模型遵循软件生存期的划分，明确规定各个阶段的任务，各个阶段的工作自上而下、顺序展开，如同瀑布流水，逐级下落。 瀑布模型把软件生存周期划分为计划时期（或定义时期）、开发时期和运行时期。这三个时期又分别细分为若干个阶段，参看图1.4。 返回目录1.6 软件生存周期模型图1.4 软件生存周期的瀑布模型 1.6 软件生存周期模型瀑布模型软件开发具有以下几个特征：1阶段间的顺序性和依赖性 2推迟实现的观点3质量保证的观点 瀑布模型为软件开发和软件维护提供了一种有效的管理图式。根据这一图式制定开发计划、进行成本预算、组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证了软件产品及时交付，并达到预期的质量要求。 但其最为突出的缺点是该模型缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。这些问题的存在对软件开发会带来严重影响，最终可能导致开发出的软件并不是用户真正需要的软件，并且这一点在开发过程完成后才有所察觉。 1.6 软件生存周期模型1.6.2 快速原型模型 是快速建立起来的可以在计算机上运行的程序，它能完成的功能往往是最终产品能完成功能的一个子集。 快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通常用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用经过多次调整原型使其满足用户的需求之后，开发人员便可以将用户的真正需求确定下来；第二步则是在第一步的基础上开发用户满意的软件产品。 此模型可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。1.6 软件生存周期模型1.6.3 增量模型 图1.5 增量模型 1.6 软件生存周期模型 由于增量模型将整个产品分解成若干个构件进行逐步交付，因此软件开发可以较好地适应需求的变化，用户可以不断地看到所开发软件的可运行中间版本，从而降低了开发风险。 增量模型也存在如下缺陷：由于各个构件是逐渐并入已有的软件体系结构中，所以加入构件必须不破坏以构造好的系统部分，这需要软件具备开放式的体系结构。在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型，但是也很容易退化为边做边改的方式，从而使软件过程的控制失去整体性。1.6 软件生存周期模型1.6.4 螺旋模型（spiral model） 1986年，B.W.Boehm提出了螺旋模型。螺旋模型将瀑布模型与演化模型结合起来，并且加入两种模型均忽略了的风险分析，弥补了两者的不足。螺旋模型沿着螺线旋转，如图1.6所示，在笛卡尔坐标的四个象限上分别表达了四个方面的活动，即： （1） 制定计划确定软件目标，选定实施方案，弄清项目开发的限制条件； （2） 风险分析分析所选方案，考虑如何识别和消除风险； （3） 实施工程实施软件开发； （4） 客户评估评价开发工作，提出修正建议。 1.6 软件生存周期模型 图1.6 螺旋模型 本 章 小 结随着软件规模的不断扩大，引发了软件危机，从而导致了软件工程的出现。本章介绍了软件、软件工程、软件生存周期及其模型的一些基本概念，论述了软件工程学的基本范畴，阐述了目前比较常见的几种软件开发模型的基本理论、基本特点。软件工程的目标指明了软件开发项目应追求和应达到的标准。软件生存周期模型是从软件项目需求定义直至软件经使用后废弃为止，跨越整个生存周期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。目前常见的模型有瀑布模型、快速原型模型、增量模型、螺旋模型等。它们各有特色，开发人员可根据项目的不同特点，选用不同的开发模型。 返回目录第2章 可行性研究与需求分析 学习目标 ：了解软件问题的定义及可行性研究的任务、过程掌握成本效益分析方法了解软件需求分析的任务和需求获取的常用方法掌握快速原型方法掌握结构化分析方法第2章 可行性研究与需求分析 教学内容 2.1 问题定义与可行性研究 2.2 需求分析的任务 2.3 需求获取的常用方法 2.4 结构化分析方法 2.5 需求分析评审 本章小结 返回目录2.1 问题定义与可行性研究2.1.1 问题的定义（Problem Definition） 是软件定义的第一个阶段，该阶段主要明确“该软件开发项目要解决什么问题”。 必须明确以下问题：软件系统要完成的总体目标是什么？要开发软件的功能和性能是什么？软件系统在可靠性和质量上有何具体要求？开发该软件系统是否具备可行的技术？当前市场和竞争对手的情况怎样？开发该软件系统是否有成本和进度约束？该软件系统将来可能进行哪些扩充？2.1 问题定义与可行性研究2.1.2 可行性研究的任务 可行性研究的主要目的是用极少的代价在最短的时间内决定被开发的软件是否能开发成功。 （1）经济可行性：通过对被开发软件系统的成本效益的分析，估算系统的开发成本，估计系统可能取得的效益，确定待开发系统是否值得投资开发。 （2）技术可行性：从问题定义规格说明书提出的系统功能、性能以及实际系统的各种约束来分析，确定当前的技术及条件是否能实现整个系统。2.1 问题定义与可行性研究（3）法律可行性：分析在系统开发的全部过程中可能出现和涉及的法律问题，如合同、责任、知识产权、专利等问题。（4）运行可行性：判断新系统的运行方式是否可行。2.1 问题定义与可行性研究2.1.3 可行性研究的过程1可行性研究的步骤（1）确定系统的规模和目标（2）分析现有系统，设计新系统的高层系统模型（3）评审系统模型（4）设计和评价新系统的实现方案（5）制定行动方案（6）拟定开发计划（7）编制可行性报告2.1问题定义与可行性研究2可行性研究的工具 在进行可行性研究时，使用的主要工具为系统流程图。 系统流程图的基本作用是：以黑盒方式描述系统各部件（如人工处理、程序、数据库、图表等），它只描述了信息在系统各部件中的流动情况，不对信息在系统中的加工细节进行描述，所以它不同于程序流程图。 系统流程图包含一些基本符号，每个符号表示系统中的某个部件，如表2.1所示。 2.1问题定义与可行性研究例:学生成绩管理系统流程图 某校为了提高工作效率，对学生的成绩由计算机进行管理，由教务员在计算机上处理日常的学生成绩管理事务。 学生成绩管理系统主要功能要求如下：（1）编辑功能 录入学生成绩修改学生成绩删除学生成绩（2）查询功能 查询某学生成绩查询某班级成绩查询某课程成绩（3）统计功能 计算平均成绩统计不及格情况按分数段统计成绩排序学生成绩管理系统流程可用如图1.1所示的系统流程图来描述。2.1问题定义与可行性研究2.1.4 成本/效益分析 1成本估计（1）代码行技术（2）任务分解技术（3）自动估计成本技术 2成本/效益分析的方法（1）货币的时间价值 （2）投资回收期 （3）纯收入 （4）投资回收率 返回目录2.2 需求分析的任务2.2.1 确定对系统的综合要求2.2.2 分析系统的数据要求2.2.3 导出系统的逻辑模型2.2.4 修正系统开发计划返回目录2.3 需求获取的常用方法2.3.1常用的需求获取方法1访谈和会议2市场调查3访问用户和用户领域的专家4考察现场，跟踪现场业务流程5开发人员和用户共同组成联合小组返回目录2.3 需求获取的常用方法2.3.2 快速原型方法 绝大多数现代软件项目都适于采用快速原型技术进行开发。特别是如果软件产品产生大量的动态可视输出，要求大量的用户交互，或者问题领域涉及一些复杂的算法，它们要以进化方式开发，则需求分析阶段应该使用快速原型技术。2.3 需求获取的常用方法1原型的分类（1）废弃型（2）追加型或演化型2原型类型的选择2.3 需求获取的常用方法3快速原型开发模型（1）快速分析 （2）构造原型（3）运行和评价原型 （4）修正和改进（5）判定原型是否完成 (6）判断原型细节是否说明（7）原型细节的说明 （8）判定原型效果（9）整理原型和提供文档。2.4 结构化分析方法 SA（Structured Analysis，结构化分析方法）是20世纪70年代中期由EYourdon等人倡导的一种面向数据流的分析方法。 TDeMarco对SA所下的定义为“结构化分析就是使用DFD、DD、结构化语言、判定表和判定树等工具，来建立一种新的称为结构化说明书的目标文档”。这里的结构化说明书就是SRS。随着计算机的发展，结构化分析方法有了一些改进，但最基本的内容还是应用DFD、DD和PSPEC（Process Specification，加工说明）来描述系统的功能模型。 2.4 结构化分析方法 2.4.1 结构化分析的过程 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。为了达到这个目标，通常从数据流图的输出端着手分析，这是因为系统的基本功能是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。2.4 结构化分析方法图2.2面向数据流自顶向下求精过程2.4 结构化分析方法 使用结构化分析方法应遵守下述准则：（1）必须理解并描述问题的信息域，根据这条准则应该建立数据模型。（2）必须定义软件应完成的功能，这条准则要求建立功能模型。（3）必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。（4）必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。2.4 结构化分析方法2.4.2实体联系图 实体联系图简称为E-R图。E-R图中包含了实体（即数据对象）、联系和属性等3种基本成分。 1数据对象 可以由一组属性来定义的实体都可以被认为是数据对象。 2属性 属性定义了数据对象的特征。它可用来：为数据对象的实例命名;描述这个实例;建立对另一个数据对象的另一个实例的引用。 3联系 数据对象彼此之间相互连接的方式称为联系，也称为关系。实体与实体之间的关系，在E-R图中用连接两个实体的菱形框表示。 联系可分有3种类型： 一对一（1：1） 一对多（1：m） 多对多（n：m）2.4 结构化分析方法图2.3 学生成绩管理系统E-R图2.4 结构化分析方法2.4.3 数据规范化1规范化的三个条件2规范化的目的 消除冗余、多义性，使关系单纯化、方便操作、模式灵活。3关键字 是记录中的一个或一组字段（属性值），能唯一地标识一个记录（元组），如学号、职工号、课程号。4判断规范化程度的条件（三个范式） 关系规范化的程度，通常按属性间的依赖程度来区分，并以范式（NF）来表达。2.4 结构化分析方法2.4.4 数据流图1数据流图的图形符号表2.5数据流图基本符号的意义2.4 结构化分析方法2.4.4 数据流图数据流图的附加符号,表示数据流之间的关系。 表明多个数据流与加工之间关系的符号图2.4 表明多个数据流与加工之间关系的符号返回目录2.4 结构化分析方法2使用数据流图的注意事项（1）数据处理不一定是一个程序。（2） 一个数据存储不一定是一个文件。（3） 数据存储和数据流都是数据，数据存储是静止状态的数据，数据流是运动状态的数据。（4） 同一数据流图中，加工的个数不要太多。（5） 数据流图细化原则。如果数据流图过于复杂，可以画出分层数据流图。在对数据流图进行分层时，应注意以下几点: 父图与子图不平衡 分解的速度太快 不遵守加工编号规则2.4 结构化分析方法3.数据流图中各成分的命名方法 (1)为数据流或数据存储命名 数据流或数据存储的名字应代表整个数据流或数据存储的内容，而不是仅仅反映它的某些成分，命名时不要使用空洞的、缺乏具体含义的名字。 (2)为处理命名 一般应首先对数据流命名，然后再对与之相关联的处理命名。命名应该反映整个处理的功能。名字最好由一个具体的及物动词，加上一个具体的宾语组成。 (3)为数据源点/终点命名 为数据源点/终点命名时采用它们在问题域中习惯使用的名字。2.4 结构化分析方法4.数据流图的绘制 （1）画顶层数据流图。通常把整个系统当作一个大的加工，标出系统的输入、输出及数据的源点与汇点。 图2.5 学生成绩管理系统的顶层DFD2.4 结构化分析方法4.数据流图的绘制 （2）画第二层数据流图。 图2.6 学生成绩管理系统的分层DFD2.4 结构化分析方法4.数据流图的绘制（3）画第三层数据流图。第二层数据流图中的加工细节还不够清晰，需要把每个加工继续分解成更小的加工。图2.7 学生成绩管理系统查询细化DFD 2.4 结构化分析方法4.数据流图的绘制图2.8 学生成绩管理系统编辑细化DFD 2.4 结构化分析方法4.数据流图的绘制图2.9 学生成绩管理系统统计细化DFD 2.4 结构化分析方法2.4.5 数据字典 数据字典（Data Dictionary，DD）是结构化分析方法的另一种有力工具，在数据字典中建立的一组严密一致的定义有助于消除分析员和用户之间的沟通障碍，因此将消除许多可能的误解。对数据的这一系列严密一致的定义也有助于改进在不同的开发人员或不同的开发小组之间的通信。 同时，数据字典也是软件维护时使用的一种重要资料。如果要求所有开发人员都根据公共的数据字典描述数据和设计模块，则能避免许多麻烦的接口问题，提高开发的效率和质量。2.4 结构化分析方法1.数据字典的内容 是对数据流图中出现的所有数据元素给出定义。它对数据流图上的数据流名字、加工名字和文件名字给出了确切的解释，并按照字典的方式组织起来，以便于查询和维护。主要包括: 数据流词条描述 数据项词条描述 数据文件词条描述 加工逻辑词条描述 源点及汇(终)点词条描述2.4 结构化分析方法2.数据字典的数据定义方法 在对数据进行定义时，可以使用数据各成分的组合来表示该数据，这些组合又由更底层的成分组合进行定义。 表2-6 数据字典定义式中的符号2.4 结构化分析方法2.数据字典的数据定义方法 例如，在学生成绩管理系统中所用到的部分数据流、数据文件、数据项在数据字典中可以这样定义： （1）数据流条目。本例中的“课程成绩单”可如下定义： 数据流名：课程成绩单 数据流来源：“查询课程成绩”子加工1.5 数据流去向：“显示成绩”子加工1.6 数据流组成：课程成绩单=课程号+课程名+任课教师|指导教师+学号+姓名+成绩（+备注） 2.4 结构化分析方法2.数据字典的数据定义方法（2）数据文件条目。“学生成绩表”条目可用如下的方式定义。 文件名：学生成绩表 编号：01 别名：无 数据文件组成：学生成绩=学生学号+课程编码+成绩+备注 文件组织:以学号为记录关键字进行升序排列 由谁建立或修改：加工2.1、2.1、2.3 由谁使用：加工1.3、1.4、1.5、2.2、3.1、3.2、3.3、3.4 注释：备注域用于标识课程类别（必修/限选/任选）2.4 结构化分析方法2.数据字典的数据定义方法（3）数据项条目。“课程号”条目可用下面的方式定义。 数据项名：课程号 类型：数字 度：7 取值范围：00000009999999 相关的数据元素及数据结构：第1位：系编号;第23位：教研室编号; 第46位：课程序号;第7位：课堂号。2.4 结构化分析方法2.数据字典的数据定义方法（4）加工说明条目。加工说明是对数据流图中每个加工所进行的说明。 如“查询学生成绩” 条目在数据字典中可定义如下。 加工名：查询学生成绩 加工编号：1.3 输入：“查询数据” 加工逻辑：如果 输入数据是“学号+姓名” 可查询学生成绩 输入数据是“班级号+课程号” 可查询该班级成绩 输入数据是“课程号” 可查询该课程成绩 输出：学生成绩 注释：该加工可根据输入的查询数据，调用不同的子加工，可输入不同的查询信息。 2.4 结构化分析方法 总之，数据字典与数据流图应相辅相成、互相配合，并应遵守以下约定：有关数据的流向在数据流图中描述；有关数据的组成在数据字典中描述；有关数据的加工细节在数据字典中描述；编写数据字典时不能有遗漏和重复，即遵循不重不漏的原则；数据字典小的条目的排列要有一定规律，要能通过名字方便地查阅条目的内容，如按英文字母表顺序或按汉字笔划顺序排列或按功能分类等；数据字典的编写要易于更新修改。2.4 结构化分析方法2.4.6 状态转换图 1状态 状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。 2事件 事件是在某个特定时刻发生的事情，它是对引起系统做动作或（和）从一个状态转换到另一个状态的外界事件的抽象。 3符号 椭圆（或圆角矩形）：表示对象的一种状态，椭圆内部填写状态名。 箭头：表示从箭头出发的状态可以转换到箭头指向的状态。 事件：箭头上方可标引起状态转换的事件名。 实心圆：表示初始状态。 内部实心的同心圆：表示最终状态。 2.4 结构化分析方法2.4.6 状态转换图 图2.10状态图中使用的主要符号2.4 结构化分析方法2.4.6 状态转换图 4.画状态图的步骤（1）找出实体的所有状态。（2）分析在不同状态下，对象的行为准则有无差别，若无差别应将它们合并为一种状态。（3）分析从一种状态可以转换到哪几种状态，对象的什么行为能引起这种转换，有无状态转换的限制条件。 2.4 结构化分析方法2.4.6 状态转换图 5.状态转换图实例右图为电话系统的状态图2.4 结构化分析方法2.4.7 其他图形工具 1层次方框图图2.12 学生成绩管理系统层次方框图2.4 结构化分析方法2.4.7 其它图形工具 2Warnier图图2.13报纸编辑的Warnier图及其细化2.4 结构化分析方法2.4.7 其它图形工具 3IPO图图2.14学生成绩管理系统的IPO图返回目录2.5 需求分析评审 2.5.1 需求规格说明书 软件规格说明书中阐明的需求是经过认真研究和分析后定下来的，是软件开发人员和用户对问题的共同理解，可被当作是双方达成的协议书。由于其中规定的需求都是系统准备加以实现的，因此它应该作为软件设计和实现的基础和依据。在项目开发的最后阶段，其中规定的各项需求又将是产品验收的依据。当软件产品投入运行以后，如需进行适应性或扩充性维护，仍然需要软件规格说明书。由此可见，软件规格说明书在整个软件生存周期中都具有十分重要的作用。2.5 需求分析评审 2.5.2 评审过程 需求规格说明书提交给设计阶段之前，须进行需求评审。评审过程中发现存在错误或缺陷，及时进行更改或弥补，重新进行相应部分的初步需求分析、需求建模，修改需求规格说明书，并再进行评审。衡量需求规格说明书好坏的标准按重要性次序排列:（1）正确性 （2）无歧义性（3）完全性 （4）可验证性（5）一致性 （6）可理解性（7）可修改性 （8）可追踪性返回目录本 章 小 结可行性研究与需求分析是软件生存期中的基础，其根本的任务是确定所要开发的软件是否可行，以及确定用户对软件系统的需求。本章首先介绍了软件可行性研究的主要任务、步骤、工具及如何制订项目计划。介绍了两种常用的需求分析方法：结构化分析方法和快速原型方法介绍了需求分析的评审过程和需求规格说明书的写法。使读者更好地掌握软件需求分析的编写方法。返回目录第3章 软件设计 学习目标 ：了解软件设计的任务掌握模块划分的评价准则模块独立性的判别掌握结构化设计方法掌握一些常用的详细设计工具了解界面设计的设计问题、设计过程和设计指南第3章 软件设计 教学内容 3.1 软件设计的任务 3.2 软件结构设计 3.3 描绘软件结构的图形工具 3.4 面向数据流的设计方法 3.5 详细设计 3.6 人机界面设计 3.7 面向数据结构的设计方法 本章小结 返回总目录3.1 软件设计的任务 软件设计是一个把软件需求转换成软件表示的过程，软件设计分为两个阶段：概要设计：将软件需求转换为软件结构和数据结构，并编写概要设计说明书；详细设计：通过对软件结构的细化，得到软件的详细的算法和数据结构，产生描述软件的详细设计文档。3.1 软件设计的任务 概要设计又称为初步设计或总体设计，概要设计的基本任务有： 制定规范软件系统结构的总体设计处理方式设计数据结构设计可靠性设计编写概要设计阶段的文档概要设计评审3.2 软件结构设计 3.2.1 软件设计过程 1设想供选择的方案 2选取合理的方案 3推荐最佳方案 4功能分解 5设计软件结构 6设计数据库 7制定测试计划 8书写文档 9审查和复审3.2 软件结构设计3.2.2 软件结构设计基本原理 1抽象（1）过程抽象（2）数据抽象顶层模块是控制模块，用来协调程序（3）控制抽象 2逐步求精 3信息隐蔽 4局部化3.2 软件结构设计3.2.3 模块化模块具有3个基本属性：（1）功能：模块实现的功能（含该模块调用的子模块的功能）。（2）逻辑：描述模块内部怎么做。（3）状态：模块使用时的环境和条件。模块具有内部和外部两个特性：（1）外部特性：模块的名字、参数表等。（2）内部特性：完成模块功能的程序代码和模块内部数据。采用模块化的原理可以使软件结构清晰，原因主要有以下3方面：（1）程序错误通常局限在有关模块及其接口中。（2）修改错误只会涉及少数模块。（3）可以协同完成大型程序，各个部分的并行开发，提高生产效率。 3.2 软件结构设计3.2.4模块独立性 是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他模块的接口是简单的。 一般采用两个准则度量模块独立性，即模块与模块间的耦合性和模块内部的内聚性。 1藕合性 藕合是程序结构内不同模块之间相互关联程度的度量。它是由模块间接口的复杂程度、调用模块的方式及通过接口传递的信息类型决定的。 藕合划分为7类，按照从弱到强依次为：非直接耦合、数据耦合、特征耦合、控制耦合、外部耦合、公共耦合及内容耦合，其模块独立性依次变弱。如下图所示。返回目录3.2 软件结构设计返回目录图3.1 耦合性与模块独立性关系3.2 软件结构设计2内聚性 内聚性标志一个模块内部各元素彼此结合的紧密程度。内聚也划分为7类，按照从弱到强依次为：偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、信息内聚及功能内聚，如图所示。 3.2 软件结构设计 人们在开发计算机软件的长期实践中积累了丰富的经验，总结这些经验得出了一些启发式规则，如： 改进软件结构，提高模块独立性；模块规模应该适中；深度、宽度、扇出和扇入都应适当；模块的作用域应该在控制域之内；力争降低模块接口的复杂程度；设计的模块应是单入口单出口；模块功能应该可以预测。3.3 描绘软件结构的图形工具3.3.1 层次图和HIPO图 层次图用来描绘软件的层次结构，很适于在自顶向下设计软件的过程中使用。在图3.9中已经非正式地使用了层次图。 返回目录图3.9 学生成绩管理系统的层次图3.3 描绘软件结构的图形工具 在层次图（H图）里除了最顶层的方框之外，每个方框都加编号。编号规则和第2.4节中介绍的数据流图的编号规则相同，例如，图3.10加了编号后得到图3.10。像这样带编号的层次图称为HIPO图（层次图加输入/处理/输出图的英文缩写）。返回目录图3.10 学生成绩管理系统HIPO图3.3 描绘软件结构的图形工具3.3.2 结构图1结构图的符号（1）方框代表模块，框内注明模块的名字或主要功能。（2）方框之间的大箭头或直线表示模块的调用关系。（3）带注释的小箭头表示模块调用时传递的信息及其方向。尾部加空心圆的小箭头表示传递数据信息，加实心圆的小箭头表示传递控制信息。（4）选择结构：如书中图3.11（a）所示，条件符合时调用A，不符合时调用B。（5）循环结构：如书中图3.11（b）所示，模块M循环调用模块A、B、C。返回目录3.3 描绘软件结构的图形工具结构图的组成 有6种类型的模块：传入模块、传出模块、变换模块、协调模块，如下图所示，还有两种： 源模块：不调用其它模块的传入模块，只适用于传入部分的始端。最初的输入； 漏模块：不调用其它模块的传出模块，只适用于传出部分的末端。最后的输出。 返回目录图3.11 系统结构图中的模块类型3.4 面向数据流的设计方法 软件设计的本质是将需求分析阶段所产生的数据流图转换成软件结构图。结构化设计（SD）是国际上应用最广，技术上也较完善的系统设计方法，也是基于数据流的设计方法。3.4.1 基本概念 1变换流 变换型数据流图中数据的处理过程大致可分为3步，即输入数据、变换数据和输出数据，如图3.13所示。图3.13 变换型数据流图3.4 面向数据流的设计方法 将变换型数据流图映射为软件结构图的方法是：将数据流图的输入、变换和输出部分分别转换为输入、变换和输出模块；在输入、变换和输出模块之上增加总控模块，以调度这3个模块，协调完成任务。 转换后的软件结构图如图3.14所示。总控模块的工作过程如下： 调用输入模块，获取输入数据； 调用加工模块，将获取的输入数据传给加工模块，获取加工模块加工好的数据； 调用输出模块，将获取的加工好的数据传给输出模块，由输出模块输出该数据。图3.14 变换型软件结构图3.4 面向数据流的设计方法2.事务流 事务型数据流图有一个明显的事务中心，它接受一项事务，根据该事务的特点和性质，选择分配一个适当的处理单元，然后输出结果。所以，事务型数据流图由接受事务、事务中心和若干处理单元输出结果部分组成，如图3.15所示。 图3.15 事务型数据流图3.4 面向数据流的设计方法将事务型数据流图映射为软件结构图的方法是：将数据流图中的各个部分转换成软件结构图中的相应模块；增加调度模块，让它调度n个处理单元；让事务中心模块调度接受事务、调度和输出结果模块。转换后的软件结构图如图3.16所示。图3.16 事务型数软件结构图3.4 面向数据流的设计方法事务中心模块的工作过程如下：调用接受事务模块，接受一项事务；调用调度模块选择分配处理单元，获取处理结果；调用输出模块输出结果。3.4 面向数据流的设计方法3SC图中的模块调用（1）简单调用在SC图中，调用线的箭头指向被调用模块，如图3.17（a）所示。（2）选择调用SC图中用菱形符号来表示选择，如图3.17（b）所示。（3）循环调用SC图中用叠加在调用线上的环形箭头来表示，如图3.17（c）所示。图3.17 系统结构图中的模块调用3.4 面向数据流的设计方法3.4.2 变换分析 变换分析是将变换型数据流图映射成软件结构图的一系列步骤的总称。运用变换分析方法建立初始的变换型系统结构图，然后对它做进一步的改进，最后得到系统的最终结构图。下面以第2章中的图2.11所示的数据流图为例，介绍变换分析的步骤。（1）复审和精化数据流图。 重新复审需求分析阶段得到的数据流图，在必要时进行精化，力争做到使数据流图中每个处理加工都代表一个规模适中相对独立的子功能。 3.4 面向数据流的设计方法 在重画数据流图时，要注意以下几点：可以从物理输入到物理输出，或者相反. 还可以从顶层加工框开始，逐层向下。在精化后数据流图中不要出现控制逻辑，图中的箭头只表示数据流。不要去管系统的开始和结束（假定系统在不停地运行）。省略每一个加工框的简单例外处理。 第2章的图2.11是统计细化模块的数据流图，首先要根据需求分析说明书对该数据流进行复审，检查有无不当之处。另外，教务员需要将统计数据输入到计算机中，所以应在图中添加一个“输入统计数据”的加工，再对数据流图做进一步的精化，精化后的数据流图如图3.16所示。3.4 面向数据流的设计方法图3.16 精化后的统计细化DFD 3.4 面向数据流的设计方法（2）确定数据流图中含有变换型特征还是事务型特征。 从精化过程可以看出，来自教务员的统计数据通过3.6加工输入到计算机中，访问学生档案库，对访问的数据进行变换后再通过3.5加工输出给教务员，存在输入部分、输出部分和中心变换部分，显然，该数据流图是变换型的。但其中也可能遇到明显的事务型特征，这时可采用变换型为主，在局部采用事务型的设计方法。（3）区分输入流、输出流和中心变换部分，即标明流的边界。 首先确定输入和输出部分的边界，剩下的就是变换部分。不同的人员对输入和输出部分的划分有所不同，但对最终的软件结构影响不大。 在上步中确定了数据流图是变换型的，接下来的工作就是将这3部分划分出来。该数据流图的边界划分如图3.17所示。3.4 面向数据流的设计方法图3.17 统计细化DFD边界划分 3.4 面向数据流的设计方法（4）进行一级“因子化”分解，设计顶层和第一层模块。 先设计主模块，用程序名字为它命名，画在与中心变换相对应的位置上。做为系统的顶层，它调用下层模块，完成系统所要做的各项工作。系统结构第一层的设计方针是：为每一个逻辑输入设计一个输入模块，它为主模块提供数据；为每一个逻辑输出设计一个输出模块，它将主模块提供的数据输出；为中心变换设计一个变换模块，它将逻辑输入转换成逻辑输出。第一层模块与主模块之间传送的数据应与数据流图相对应。将上面描述的划分的数据流图转换为如右图3.20所示的软件结构图。图3.20 统计上层模块 3.4 面向数据流的设计方法（5）进行二级“因子化”分解，设计中、下层模块。 自顶向下，逐层细化，为每一个输入模块、输出模块、变换模块设计它们的从属模块。将图3.20描述的上层模块进行分解，设计中下层模块，得到的统计软件结构的二次分解图如图3.21所示。图3.21 统计软件结构的二次分解图 （6）利用一些启发式原则来改进系统的初始结构图，直到得到符合要求的结构图为止。3.4 面向数据流的设计方法3.4.3 事务分析 事务映射也是从分析数据流图开始，自顶向下，逐步分解，建立系统结构图。所不同的是由数据流图映射成的系统结构图不同。 下面以第2章中的图2.9所示的数据流图为例，介绍一下事务分析的步骤。（1）复审和精化数据流图。 本例中精化后的数据流图如图3.20所示 。3.4 面向数据流的设计方法图3.20 查询细化DFD 3.4 面向数据流的设计方法（2）确定数据流图中含有变换型特征还是事务型特征。（3）识别事务中心和每一条操作路径上的流特征。 事务中心通常位于几条操作路径的起始点上，可以从数据流图上直接找出来。输入路径必须与其他所有操作路径区分开来。（4）将数据流图映射为事务型系统结构图。 事务流应映射到包含一个输入分支和一个分类事务处理分支的程序结构上。输入分支结构的开发与变换流的方法类似。分类事务处理分支结构包含一个调度模块，它调度和控制下属的操作模块。 本例中所得的软件结构图如图3.23所示。3.4 面向数据流的设计方法图3.23 查询模块程序结构图 （5）“因子化”分解和细化该事务结构及每一条操作路径的结构。（6）优化软件结构图，进行软件详细设计。3.4 面向数据流的设计方法3.4.4 设计优化 1.模块功能的完善化 一个完整的功能模块，不仅应能完成指定的功能，而且还应能告诉使用者完成任务的状态，以及不能完成的原因。 2消除SC中的重复功能，改善软件结构 审查分析结构图。如果几个模块的功能有相似之处，可以分以下两种情况分别加以改进。 （1）完全相似 （2）局部相似 3模块的大小要保持适中 要求把模块的大小限制在一定的范围之内。3.4 面向数据流的设计方法4保持高扇入/低扇出原则 扇出表示一个模块直接调用（或控制）的其他模块的数目。扇入则定义为调用（或控制）一个给定模块的模块个数。 通常上层扇出比较高，中层扇出较少，底层扇入到有高扇入的公用模块中。5作用域/控制域原则 模块的作用域不要超出控制域； 其位置离受它控制的模块越近越好。6. 力争降低模块接口的复杂程度7. 设计单入口单出口的模块8. 模块功能应该可以预测 3.5 详细设计 3.5.1 详细设计概述 在概要设计完成后，进一步就要考虑实现各个模块规定的功能，也就是进行软件的详细设计，也称为过程设计。 在详细设计阶段，要根据概要设计对每个模块的定义进行设计，以实现指定的功能、算法和外部接口所要求的模块内部的数据结构和程序的逻辑结构。模块设计要完成的工作包括：详细的算法过程设计内部数据结构设计程序逻辑结构设计3.5 详细设计 详细设计的重点在如何描述程序的逻辑结构。只有有了好的详细设计，才能设计出可维护性好质量好的软件。详细设计阶段主要采用结构化程序设计方法（Structured Programming，SP），与SA和SD方法相衔接。当前流行的表示程序逻辑结构的方式有3种：图形描述语言描述表格描述 其中图形描述工具主要有程序流程图、N-S图及PAD图等；语言描述工具主要有PDL；表格描述有判定表及判定树等。返回目录3.5 详细设计 3.5.2 程序流程图 程序流程图（Program Flow Chart）又称为程序框图。 为使用流程图描述结构化程序，必须限制流程图只能使用如图3.28所给出的5种基本控制结构。 3.5 详细设计 任何复杂的程序流程图都应由这5种基本控制结构组合或嵌套而成。顺序型：几个连续的加工步骤依次排列，执行时按先后顺序执行选择型：依逻辑判断式的取值决定选择两个加工中的一个来执行先判定型循环：先对循环控制条件进行判定，成立时，重复执行选定的加工否则退出循环后判定型循环：先执行一次循环体，再对结束循环控制条件进行判定，成立时，退出循环，否则重复执行循环体多情况型选择：列举多个加工情况，根据控制变量的取值，选择执行其一3.5 详细设计 例如，在对某科课程的成绩统计各分数段的人数时，程序流程图可用图3.29来表示。3.5 详细设计 常用标准程序流程图符号3.5 详细设计 3.5.3 N-S图（盒图） N-S图也称盒图（Box-Diagram），是由Nassi 和Shneiderman提出的一种符合结构化程序设计原则的图形描述工具。 在N-S图中，相应规定了5种图形构件，如图3.28所示。图3.28 N-S图的5种基本控制结构3.5 详细设计例3.1根据图3.29所示的流程图画出相应的N-S图返回目录3.5 详细设计但当问题很复杂时，N-S图可能很大，在一张纸上画不下时，可用分层N-S图表示，如图3.32（b）所示。返回目录（a) (b) 图3.32 N-S图的扩展表示3.5 详细设计从上面两图可以看出，N-S图有以下几个特点：图中每个矩形框都是明确定义了的功能域。图中的控制转移不能任意规定，必须遵守结构化程序设计要求。从图中可以很容易地确定局部数据和全局数据的作用域。图中很容易表现嵌套关系及模块的层次结构。返回目录3.5 详细设计 3.5.4 PAD图 PAD（Problem Analysis Diagram，问题分析图），是日本日立公司提出的用结构化程序设计思想表现程序逻辑结构的图形工具。现在已被ISO认可。 PAD也设置了5种基本控制结构的图式，并允许递归使用。这5种基本控制结构如图3.31所示。图3.31 PAD的基本控制结构 3.5 详细设计 其中：表示按顺序先执行A，再执行B。给出了判断条件为P的选择型结构。当P为真时执行上面的A框中的内容，当P为假时执行下面的B框中的内容。如果这种选择型结构只有A框，没有B框，表示该选择结构中只有THEN后面有执行语句A，没有ELSE部分。与中P是循环判断条件，S是循环体。是CASE型结构。当判定条件P1时，执行A1框的内容，P2时，执行A2框的内容，Pn时，执行An框的内容。3.5 详细设计例3.2将图3.29所示的程序流程图转换为用PAD图表示返回目录3.5 详细设计 PAD的执行顺序是从上到下，从左到右，即从最左主干线的上端的结点开始，自上而下依次执行。 每遇到判断或循环，就自左而右进入下一层，从表示下一层的纵线上端开始执行，直到该纵线下端，再返回上一层的纵线的转入处。如此继续，直到执行到主干线的下端为止。 用PAD所表达的程序，结构清晰并且结构化程度高。作为一种详细设计的工具，它比流程图更易读，且由于PAD是一种树形结构，比流程图更容易在计算机上处理，容易将PAD图转换成程序。另外，PAD除了可以描述程序的逻辑结构，还可以描述数据结构。返回目录3.5 详细设计3.5.5 判定表与判定树1判定表（Decision Table） 判定表一般由4部分组成：左上半部分列出所有条件、左下半部分列出所有动作、右上半部分列出各种条件组合，右下半部分列出和每组条件取值组合对应的动作。其结构图如图3.33所示。图3.33 判定表结构示意图 判定表的优点是能够简洁，无二义性的描述所有的处理规则。 缺点是它所表示的是静态逻辑，是在某种条件组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构。因不能成为一种通用的设计工具，一般配合其他工具一起使用。3.5 详细设计例3.3某“订货单处理程序”的处理逻辑描述如下： “如果订货金额不足500元且未过期，则向客户发出批准单和提货单，已过期的，什么也不发；如果订货金额超过500元但不足1000元，则发出批准单和提货单，对已过期的，还要发过期通知单；如果订货金额超过1000元，不论是否过期，都要发出批准单和提货单。” 试用判定表表示出该逻辑。判定表如表3.2所示。3.5 详细设计表3.2 判定表实例 3.5 详细设计2判定树（Decision Tree） 判定树实质上是判定表的一种变形，本质上是一样的。 判定树的优点是形式简单、比较直观、易于掌握和使用。 缺点是不如判定表简洁。 对于例3.3的描述可用判定树表示成如图3.34所示的形式：图3.34 判定树实例返回目录3.5 详细设计3.5.6 过程设计语言PDL（Program Design Language） PDL是一种用于描述功能模块的算法设计和加工细节的语言，称为设计程序用语言。它是一种伪码是一个笼统的名称，现在有许多种不同的过程设计语言在使用。 1结构 关键字 + 自然语言下面是一个用PDL说明的例子：PROCEDURESPELLCHECKISBEGINsplit document into single words -*把整个文档分离成单词 look up words in dictionary -*在字典中查这些单词 display words which are not in dictionary -*显示字典中查不到 的单词 create a new dictionary -*造一新字典 END spellcheck3.5 详细设计2特点 PDL作为一种用于描述程序逻辑设计的语言，具有以下特点：有固定的关键字外语法，提供全部结构化控制结构、数据说明和模块特征。内语法使用自然语言来描述处理特性。有数据说明机制，包括简单的（如标量和数组）与复杂的（如链表和层次结构）的数据结构。有子程序定义与调用机制，用以表达各种方式的接口说明。返回目录3.5 详细设计3语法、关键字 （1）数据说明： TYPE （2）程序块： BEGIN END （3）子程序结构 PROCEDURE （4）基本控制结构： 顺序结构： 选择结构 IF-THEN-ELSE 重复型结构：包括后测试型、先测试型、下标型三种： REPEAT UNTILL DO WHILE DO FOR 多路选择语句：CASE OF (5)输入/输出结构 READ/WRITE TO返回目录3.6 人机界面设计 用户界面是软件开发环境的重要组成部分，用户界面的好坏直接影响软件系统的质量。必须重视软件的用户界面设计，开发出更具竞争力的软件来。 3.6.1 设计问题 在设计人机界面的过程中，几乎总会遇到下述4个问题：系统响应时间、用户帮助设施、出错信息处理和命令交互。不幸的是，许多设计者直到设计过程后期才开始考虑这些问题，这样做往往导致出现不必要的设计反复、项目延期和用户产生挫折感。最好在设计初期就把这些问题作为重要的设计问题来考虑，这时修改比较容易，代价也低。下面讨论这4个设计问题。返回目录3.6 人机界面设计1. 系统响应时间 系统响应时间指从用户完成某个控制动作(例如，按回车键或点击鼠标)，到软件给出预期的响应(输出信息或做动作)之间的这段时间。 系统响应时间有两个重要属性，分别是长度和易变性。 （1）长度：如果系统响应时间过长，用户就会感到紧张和沮丧。但是，响应时间过短，这会迫使用户加快操作节奏，从而可能会犯错误。 （2）易变性：指系统响应时间相对于平均响应时间的偏差，在许多情况下，这是系统响应时间的更重要的属性。即使系统响应时间较长，响应时间易变性低也有助于用户建立起稳定的工作节奏。例如，稳定在1秒的响应时间比从0.1秒到2.5秒变化的响应时间要好。用户往往比较敏感，他们总是担心响应时间变化暗示系统工作出现了异常。返回目录3.6 人机界面设计2. 用户帮助设施 常见的帮助设施可分为集成的和附加的两类。 （1）集成的帮助设施：从一开始就设计在软件里面。 （2）附加的帮助设施：是在系统建成后再添加到软件中的。 具体设计帮助设施时，必须解决下述的一系列问题。 （1） 提供部分功能的帮助信息还是提供全部功能的帮助信息。 （2）用户请求方式：有3种选择：帮助菜单，特殊功能键和HELP命令。 （3）显示帮助信息方式：有3种选择：独立的窗口，指出参考某个文档(不理想)和在屏幕固定位置显示简短提示。 （4）返回正常的交互方式：有两种选择：屏幕上的返回按钮和功能键。 （5）帮助信息的组织方式：有3种选择：平面结构（通过关键字访问），层次结构和超文本结构。返回目录3.6 人机界面设计3. 出错信息处理出错信息和警告信息，是出现问题时交互式系统给出的“坏消息”。一般说来，交互式系统给出的出错信息或警告信息，应该具有下述属性。(1) 信息应该用用户可以理解的术语描述问题。(2) 信息应该提供有助于从错误中恢复的建设性意见。(3) 信息应该指出错误可能导致哪些负面后果(例如，破坏数据文件)，以便用户检查是否出现了这些问题，并在确实出现问题时及时解决。(4) 信息应该伴随着听觉上或视觉上的提示，例如，在显示信息时同时发出警告铃声，或者信息用闪烁方式显示，或者信息用明显表示出错的颜色显示。(5) 信息不能带有指责色彩，也就是说，不能责怪用户。返回目录3.6 人机界面设计4. 命令交互在提供命令交互方式时，必须考虑下列设计问题：（1）是否每个菜单选项都有对应的命令?（2）采用何种命令形式?有3种选择：控制序列(例如，Ctrl+P)，功能键和键入命令。（3）学习和记忆命令的难度有多大?忘记了命令怎么办?（4）用户是否可以定制或缩写命令?（5）命令宏机制：利用这种机制用户可以用自己定义的名字代表一个常用的命令序列。需要使用这个命令序列时，用户无须依次键入每个命令，只需输入命令宏的名字就可以顺序执行它所代表的全部命令。返回目录3.6 人机界面设计3.6.2 设计过程用户界面设计是一个迭代过程，具体设计过程如下：（1）先创建设计模型，实现模型-用户界面原型。（2）用户试用并评估该原型，向设计提出对界面的评价。（3）设计者根据用户的意见修改设计并实现下一级原型不断进行下去，直到用户感到满意为止。一旦建立成用户界面原型，就要对其进行评估，评估的标准如下：（1）系统及其界面规格说明的长度和复杂程度，预示了用户学习使用该系统所需的工作量。（2）命令或动作的数量、命令的平均参数个数或动作中单个操作的个数，预示了系统的交互时间和总体效率。（3）动作、命令和系统状态的数量，预示了用户学习使用系统时需要记忆的内容的多少。（4）界面风格、帮助设施和出错处理协议，预示了界面的复杂程度和用户对界面的接受程度。返回目录3.6 人机界面设计3.6.3 人机界面设计指南1. 一般交互指南 (1) 保持一致性 (2) 提供有意义的反馈 (3) 要求用户确认 (4) 允许取消操作 (5) 减少记忆的信息量。 (6) 提高效率 (7) 允许犯错误 (8) 按功能对动作分类 (9) 提供帮助设施(参见3.6.1节) (10) 命令名要简单返回目录3.6 人机界面设计3.6.3
- 温馨提示:
1: 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
人人文库网所有资源均是用户自行上传分享，仅供网友学习交流，未经上传用户书面授权，请勿作他用。
川公网安备: 51019002004831号