软件工程课件

软件工程

SoftwareEngineering

第一章软件工程基础

主要内容计算机系统工程软件工程软件生存期模型软件开发方法软件工程环境软件与计算机的系统要素之间的关系大多数软件系统都是为了开发满足某种需求而建立。这些软件必须要计算机系统的支持。不论系统的自动化程度有多高，都需要人的参与。任何系统都必须配备使用手册及必要的表格和其他文档。在网络时代的应用系统中，绝大多数应用系统都离不开数据库和网络这样的基础设施。如图1.1所示。过程输出输入文档硬件软件人系统数据库、网络图1.1基于计算机的系统要素

1.1计算机系统工程

计算机系统工程：与构造基于计算机系统有关的过程、方法和技术。一种问题求解活动，目的是揭示与分析所期望的功能，并把这些功能分配到系统的各个独立系统元素中去。

计算机系统工程师与用户充分合作，以确认用户的目标与约束。1.1.1硬件与硬件工程

计算机系统工程师根据系统需求为硬件系统指派任务，产生硬件需求。硬件工程师根据硬件需求设计、制造或选择硬部件或设备。硬件工程过程分为三个阶段，即计划和定义阶段；设计和样机实现阶段；生产、销售和售后服务阶段。

硬件功能开发计划评审详细需求分析评审成本进度硬件规格说明(a)计划与定义阶段

该阶段的任务是制订开发计划，确定项目成本预算和工程进度，并进行详细需求分析，确定硬件规格说明。

设计图纸设计图纸样机设计分析评审建立样机与测试评审生产分析(b)设计与样机实现阶段

该阶段的任务是分析设计，画出设计图，必要时建造原型对样机进行测试，最后进行制造分析，画出生产图。产品备件制造质量保证制造评审返工维护机构(c)制造、销售与售后服务阶段该阶段的任务是按照质量保证计划和要求生产硬件产品。

1.1.2软件与软件工程

计算机软件：软件工程师设计和建造的产品。包括：可执行的程序+开发各阶段文档+各种数据。软件工程是研究软件生产和软件管理的工程科学。内容包括：市场调研、正式立项、需求分析、项目策划、概要设计、详细设计、编程、测试、试运行、产品发布、用户培训、产品复制、销售、实施、系统维护和版本升级等。

软件工程模型一般包括：软件项目的定义阶段、软件开发阶段、软件的检验、交付与维护阶段。原型(a)定义阶段软件项目计划评审需求分析或原型评审项目计划需求规格说明软件功能原型数据与结构设计评审过程设计评审程序编码评审详细设计规格说明概要设计规格说明源程序代码(b)开发阶段操作过程(c)检验、交付与维护阶段单元测试组装测试确认测试调试交付与销售评审维护评审用户文档测试计划测试过程测试结果修改的源程序代码因缺陷可能导致返回到前面步骤修改的文档代码1.1.3人类工程

关键是处理软件与人的交互问题。

现在“人机界面友好”的要求，已成为基于计算机系统的一项重要技术指标。人类工程包括下列步骤：

1.创建系统功能的外部模型2.确定为完成此系统功能人和计算机应分别完成的任务3.考虑界面设计中的典型问题4.借助CASE工具构造界面原型和最终实现设计模型5.从质量的角度对界面进行评估

1.1.4数据库工程

数据库系统是基于计算机系统的重要组成部分，它将有关的硬件、软件、数据和数据库管理人员结合起来，为用户提供信息服务。数据库系统的开发方法主要有：结构化生命周期开发方法、原型法、面向对象的开发方法等。数据库工程的任务数据库工程应完成下列任务：1.确定系统的各项指标并进行评估和计划制定2.论证、选择和配置数据库系统3.数据库设计与实现4.数据库的管理与维护1.1.5网络工程

网络工程是研究网络系统的规划、设计与管理的工程科学，要求工程技术人员根据既定的目标，严格依照行业规范，制定网络建设的方案，协助工程招投标、设计、实施、管理与维护等活动。

网络工程的任务网络工程应该完成以下任务：1.需求分析。2.总体设计分析，确定该网络的服务类型，进而确定系统建设的具体目标以及系统构件拓扑结构等。3.实施，即选择合适的设备，按设计方案实现网络建设。

4.验收与维护。1.2软件工程

1.2.1软件1.软件定义

(1)

在运行中能提供所希望的功能和性能的指令集（即程序）；

(2)

使程序能够正确运行的数据结构；

(3)描述程序研制过程、方法所用的文档。2.软件的特点

软件是一种逻辑实体，不是具体的物理实体，具有抽象性。

软件是通过人们的智力活动，把知识与技术转化成信息的一种产品，是在研制、开发中被创造出来的。

在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题。

软件的开发和运行经常受到计算机硬件系统的限制，软件对计算机硬件系统有着不同程度的依赖关系。

软件的开发尚未完全摆脱手工的开发方式。

软件的开发费用越来越高，成本相当昂贵。

软件的开发是一个复杂的过程，管理是软件开发过程中必不可少內容。1.2.2软件工程的概念

软件发展的四个阶段1950’s~1960’s中:

规模较小的程序，个体化的软件开发，只有程序清单。1960’s中~1970’中：“软件作坊”，广泛使用产品软件。1970’中~1980’s：微处理器的出现并广泛应用。分布式系统、嵌入智能。1980’s~:

网络迅速普及,强大的桌面系统、面向对象技术、专家系统、人工智能、神经网络、并行计算、网格计算、虚拟组织。软件发展过程中存在的问题软件开发能力不能满足人们的需要；社会对软件的依赖程度加大，人们普遍关注软件的安全和可靠性；若干年前开发的应用软件经过几十次修改已无人认识它的内部结构，己经不可维护；由于经济原因,嵌入式系统存在许多怪现象，企业不愿意投入资源再生产，而采取打补丁+时髦界面的方法。1.软件危机

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。典型表现：开发成本和进度的估计常常很不准确；用户对“已完成的”软件系统不满意；“闭门造车”；软件质量不可靠；软件常常是不可维护的；软件成本的比例逐年上升；软件产品“供不应求”；2.消除软件危机的途径

消除“软件就是程序”的错误观念。一个软件必须由一个完整的配置组成，事实上，软件是程序、数据及相关文档的完整集合。软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。成功的软件开发技术和方法。软件工具和软件工程支撑环境。3.软件工程的定义

1968年NATO计算机科学会议软件危机

根源

解决途径

软件工程“概括地说，软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它。”4.软件工程的目标

软件工程的目标是明确的，就是研制、开发与生产出具有良好软件质量和费用合算的产品。

采用工程化方法和途径来开发与维护软件。

应该开发和使用更好的软件工具。

采取必要的管理措施。

5.软件工程的基本原理（B.W.Boehm）用分阶段的生命周期计划严格管理坚持进行阶段评审错误出现的时间：在编代码之前（63%：37%）改正错误的代价：发现得月晚，开发代价越高实行严格的产品控制基线配置、变动控制采用现代程序设计技术结果应能清楚地审查开发小组的人员应该少而精承认不断改进软件工程实践的必要性6.软件工程研究的基本内容

软件工程学分为：理论与结构、方法、工具与环境、管理和规范等。

理论与结构包括：程序正确性证明理论、软件可靠性理论、软件成本估算模型、软件开发模型、模块划分原理等。

软件开发技术包括：软件开发方法学、软件工具和软件开发环境。

软件工程管理包括：软件开发管理和软件经济管理。1.2.3软件生命周期

软件生存周期就是从提出软件产品开始，直到该软件产品被淘汰的全过程。我国软件工程标准将软件生命周期分成以下几个阶段：软件定义:确定软件开发总目标；确定工程的可行性；导出实现策略及系统功能；估计资源和成本，并且制定工程进度表。问题定义、可行性研究、需求分析软件开发:具体设计和实现在前一个时期定义的软件总体设计、详细设计、编码和单元测试、综合测试软件维护:使软件持久地满足用户的需要。软件生命周期(续1)1.问题定义

“要解决的问题是什么?”

确定用户要求解决的性质、工程的目标和规模。2.可行性研究

“对于上一个阶段所确定的问题有行得通的解决办法吗?”

经济可行性、技术可行性、法律可行性、不同的方案3.需求分析

“为了解决这个问题，目标系统必须做什么”确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景。规格说明书(specification)软件生命周期(续2)4.总体设计（概要设计）

“概括地说，应该怎样实现目标系统?”

设计出实现目标系统的几种可能的方案。推荐一个最佳方案。5.详细设计

“应该怎样具体地实现这个系统呢?”

设计出程序的详细规格说明。6.编码和单元测试写出正确的容易理解、容易维护的程序模块仔细测试编写出的每一个模块。7.综合测试集成测试和验收测试，现场测试或平行运行8.软件维护使系统持久地满足用户的需要。改正性维护，适应性维护，完善性维护，预防性维护。1.3软件生存期模型

软件生存期模型反映软件生存周期内各种工作应如何组织及，以及各个阶段应如何衔接。软件生存期模型是跨越整个软件生存周期的系统开发、运作、维护所实施的全部工作和任务的结构框架。

常用的软件生存期模型有：瀑布模型、原型模型、螺旋模型、基于四代技术模型、喷泉模型和增量模型。1.3.2瀑布模型

(Waterfallmodel)瀑布模型又称生存周期模型，由B.M.Boehm提出，是软件工程的基础模型。

理想的瀑布模型实际的瀑布模型瀑布模型的特点阶段间具有顺序性和依赖性各个阶段如同瀑布流水，逐级下落，自上而下、相互衔接的固定次序。

推迟实现的观点清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现。质量保证的观点(文档驱动)每个阶段都必须完成规定的文档每个阶段结束前都要对所完成的文档进行评审瀑布模型的缺点模型缺乏灵活性。开发过程一般不能逆转，否则代价太大规格说明很难理解：“我知道这是按我的要求做的，但不是我想要的样子。”软件的实际情况必须到项目开发的后期客户才能看到。（文档驱动的两面性）1.3.3快速原型模型

快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。用户测试运行原型建造/修改原型

听取用户意见1.快速原型模型的优点快速原型的本质是“快速”，主要帮助建立正确的规格说明。原型模型给用户以机会，更改心中原先设想的、不尽合理的最终系统。原型模型可以低风险开发柔性较大的计算机系统。原型模型使系统更易维护，生成对用户更友好的最终系统。原型模型使总的开发费用降低，开发时间缩短。有利于开发与培训的同步2.缺点

对于开发者不熟悉的领域，可能会把次要部分当作主要框架，从而做出不切题的原型。

原型迭代不收敛于开发者预先定义的目标。原型过快收敛于需求集合，而忽略了一些基本点。

资源规划和管理较为困难，随时更新文档也带来麻烦。

长期在原型环境上开发，只注意得到满意的原型，容易“遗忘”用户环境和原型环境的差异。

3.原型模型的应用范围对所开发的领域比较熟悉而且有快速的原型开发工具项目招投标时，可以以原型模型作为软件的开发模型进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非常适合的比较瀑布模型—试图一次就获得正确的产品快速原型—频繁变化，然后废弃1.3.4螺旋模型

1988年，BarryBoehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析。该模型通常用来指导大型软件项目的开发，它将开发划分为制订计划、风险分析、实施开发和客户评估四类活动。

简化版本：瀑布模型+风险分析每个阶段之前确定目标，可供选择的办法及其限制条件风险分析每个阶段之后评估计划下一阶段简化的螺旋模型完整的螺旋模型

螺旋模型的优点容易确定什么时候已经对某一阶段的产品充分测试完毕维护和开发之间没有什么本质上的差别

螺旋模型的缺点仅适合于大型软件风险驱动既是优点也是缺点1.3.5基于四代技术模型软件工程的第四代技术（4GT）包含一系列的软件工具。共同点：使软件设计者在较高级别上说明软件的某些特征；软件工具根据说明，自动生成源代码。支持第四代技术模型的软件开发环境和工具要求较高，例如数据库查询的非过程语言、报告生成器、数据操纵、屏幕交互及定义、以及代码生成；高级图形功能；电子表格功能。优点：极大地降低了软件的开发时间，并显著提高了构造软件的生产率。缺点：目前4GT并不比程序设计语言更容易使用，而且这类工具生成的结果源代码是“低效的”，使用4GT开发的大型软件系统的可维护性令人怀疑的。1.3.6喷泉模型

在面向对象方法中，提出了与瀑布模型相对应的喷泉模型，该模型的主要特点是认为软件生命周期的各个阶段是相互重叠和多次反复的。喷泉模型主要支持面向对象的开发方法。系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。在开发活动，即分析、设计和编码之间不存在明显的边界。

图1.9喷泉模型

1.3.7增量模型

也称：渐增模型把软件产品作为一系列增量构件来设计、编码、集成和测试。瀑布模型和快速原型模型的目标交付给客户一个完整的、可用的产品增量模型的优点每个阶段交付一个可用的产品减少一个全新产品给客户带来的心理上的影响分阶段地交付产品不需要大的资金支出需求经常变化，增量模型的灵活性使其具有更加优越的适用性增量模型的困难需要一个开放的结构，方便构件的加入增量模型本身就是一个矛盾的名词1.4软件开发方法

结构化方法面向数据结构方法面向对象方法原型法1.4.1结构化方法结构是指系统内各组成要素之间的相互联系、相互作用的框架。结构化方法:强调结构的合理性，以及所开发软件的结构合理性，由此提出了一组提高软件结构合理性的准则，如分解和抽象、模块的独立性、信息隐蔽等。针对不同的开发活动，有结构化分析、结构化设计、结构化编程和结构化测试等。结构化分析方法结构化分析方法给出一组帮助系统分析人员产生功能规约的原理和技术。利用图形表示用户需求，以数据流图和控制流图为基础，伴以数据词典，并配上结构化语言、判定表和判定树等等描述手段，从而达到为解决问题而建立模型。结构化分析的步骤结构化分析的步骤如下：（1）进行系统分析，做出反映当前物理模型的数据流图；（2）推导出等价的逻辑模型的数据流图；（3）设计新的逻辑系统，生成数据词典描述；（4）建立人机接口界面，提出可供选择的目标系统的物理模型数据流图；（5）确定各种方案的成本和风险等级，据此对各种方案进行分析；（6）选择一种方案；（7）建立完整的需求规约。结构化设计结构化设计通常与结构化分析衔接起来使用，以数据流图为基础，得到软件模块结构。结构化设计的步骤如下：（1）评审和细化数据流图；（2）确定数据流图的类型；（3）把数据流图映射到软件模块结构，设计出模块结构的上层；（4）基于数据流图逐步分解高层模块，设计中下层模块；（5）对软件模块结构进行优化，得到更为合理的软件结构；（6）描述模块接口。1.4.2面向数据结构方法面向数据结构方法是结构化方法的变形，它着重数据结构而不是数据流。结构化方法:以分析信息流为主，用数据流图来表示信息流；面向数据结构方法:从分析数据结构入手，即分析信息结构，并用数据结构图来表示，再在此基础上进行需求分析，导出软件的结构。面向数据结构方法:Warmer法、Jackson法以及DSSD（数据结构系统开发）方法等。面向数据结构的开发方法包括：分析和设计活动。Jackson方法实例：把系统开发分为描述和实现两个阶段。描述阶段建立一个与系统相关的客观世界的模型，并在此基础上确定系统功能。实现阶段在具体的计算机软硬件环境下，实现系统功能。1.4.3面向对象方法起源:面向对象编程语言OOP（面向对象编程）---〉OOD（面向对象设计）+OOA（面向对象分析）----〉OOM(面向对象的软件开发方法）面向对象方法的开发步骤：

1）从问题陈述入手，构造系统模型（对象模型）。

2）逐层分解成各级子系统。

1.4.4原型法原型法首先构造一个功能简单的原型系统，然后通过对原型系统逐步求精，不断扩充完善得到最终的软件系统。原型法的主要优点：1）一种支持用户的方法，使得用户在系统生存周期的设计阶段起到积极的作用；2）它能减少系统开发的风险，特别是在大型项目的开发中，由于对项目需求的分析难以一次完成，应用原型法效果更为明显。1.5软件工程环境软件工程环境是软件工程学的组成部分，也是实现软件生产工程化的重要基础。软件工程环境的定义

“软件工程环境是一组方法、过程及计算机程序的整体化构建，支持从需求定义、程序生成直到维护的整个软件生存期”。软件工程环境是相关的一组软件工具的集合，支持一定的软件开发方法或按照一定的软件开发模型组织而成。软件工程环境支持应用软件的全部或部分自动生产过程，大大提高了软件的生产率，降低了软件的成本，改善了软件的质量。现普遍用CASE一词来描述软件工程环境。主要内容项目管理概述

项目管理基本概念

项目管理活动

2.1项目管理概述

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目管理的根本目的是为了让软件项目，尤其是大型项目的整个软件生命周期都能在管理者的控制之下，以预定成本按期、按质的完成软件，然后交付用户使用。

软件项目管理的特殊性软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。

项目管理包括4种基本活动计划：计划涉及详细规定出要取得的结果；产生这些结果所需要的活动和任务；决定时间表和估计所需的资源。

组织：组织规定了项目的组织和角色、责任的定义。控制：控制确定正在进行的活动何时偏离了计划。

终止：终止是结束项目。

项目可以分成几个阶段

项目概念：关于项目的想法开始出现，通常伴随着成本效益分析和技术可行性研究。项目定义：包括以下活动

问题定义：客户和项目经理定义系统的规模、协议标准和目标日期。

初始的软件项目管理计划（SPMP）：项目经理提供对项目总的看法、项目结果的描述、工作分解结构、角色和责任、项目时间表、所需资源的预算和怎样定义和处理风险的描述。

初始的软件体系结构项目协议定义：规定系统规模和交付日期。

项目开始：项目经理设置了项目的基础设施，雇用参与者，把他们组成团队，并总结项目。项目开始包括以下活动基础设施设立：项目经理必需为项目的基础设施制定需求。这些需求描述了项目参与者之间的交流渠道。

技能定义：项目经理定义开发者的技能和兴趣，并在技能矩阵中记录它。

团队集合：项目经理分配团队参与者，定义团队功能且选择团队领导。项目经理也为团队成员定义所需的额外培训和课程。最后，项目经理为团队分配工作包。

项目总结：项目经理，团队领导和客户正式开始启动项目。项目稳定状态：团队领导要负责跟踪团队状态和在团队会议上提出问题。包括以下活动项目规模定义控制风险管理项目重计划项目终止：提交项目结果并收集项目历史。主要活动有

交付客户验收测试安装事后分析2.2项目管理基本概念

在项目计划中一个主要的任务是把整个工作包分解成更小的任务。这包括2件事：定义合适的任务和定义任务间的依赖关系。

2.2.1任务和活动

任务是一项已经定义得很好的工作，该工作可分配给一个项目参与者或分配给一个团队。

任务是管理有关项目工作的最小的单元。任务包括对任务和持续时间的描述，还包括分配给所扮演角色的参与者。

2.2.2工作产品，工作包和角色

工作包描述了要生产的工作产品，要完成工作所需要的资源，所希望的持续时间，输入之间的相互依赖，也详细说明了验收规则和相关的个体或组织的单元的名字。

工作包是重要的管理产物，我们把它们分配给参与者去做。在任务定义之后可以定义工作包。

任何交付给用户的工作产品叫交付品，例如用户手册。2.2.3工作分解结构

在一个项目中，全体任务的层次描述叫工作分解结构（WBS）。

工作分解结构是一个要做工作的非常简单的模型。

注意:工作分解结构不表示活动的顺序。

2.2.4任务模型

任务通过暂时的依赖关系联系起来。例如建屋顶的任务不能在建墙任务结束前开始。

任务及其依赖关系的集合叫任务模型或者网络图。

完成任务有一个持续时间，由项目经理在项目开始前估算。一旦知道了任务间依赖关系和任务的持续时间，项目经理能计算出项目能被完成的最短可能时间。该时间在任务模型中表现为最长路径，即关键路径。关键路径经过项目的第一项任务到最后一项任务，其长度由任务的持续时间相加计算出来。在关键路径上的任务延迟会导致整个项目的延迟，从而使项目延期。任务的最迟完成时间是在不耽误项目的其他要完成的任务时，任务能被推迟的最大时间。2.2.5技能矩阵

技能矩阵是在项目中关于要完成任务的人的技能、知识和兴趣的一张简单表。技能矩阵的一行表示来自工作分解结构的工作单元——任务、活动和项目功能。一列表示项目参与者。矩阵中的一项为任务，定义了特定参与者的技能和知识层次。我们把3种项目区分开：主要技能、次要技能和兴趣。主要技能使一个人能胜任领导一个工作单元。次要技能使一个人能参与任务。兴趣表示在任务中一个人感兴趣但不具备该技能。2.2.6组织

组织由组织单元及其交互组成。最小组织单元是一个参与者（也叫个人或成员）。一组参与者能组成部门、处或小组。

2.2.7呈现组织结构

组织的表现及其信息结构通常叫组织图。

2.2.8软件项目管理计划

软件项目管理计划（SPMP）中的文件在项目总结大会之前创建，并且当任务完成和步骤更新的时候被更新，这种更新将贯穿整个项目。SPMP的使用者包括管理者和开发者。SPMP有五部分。1.

介绍1.1项目概况1.2项目交付品1.3文档的演化1.4参考书1.5定义和缩写表2.

项目组织2.1过程模型2.2组织结构2.3组织边界和接口2.4项目责任3.

管理过程3.1管理目标和优先级3.2假设，依赖和限制3.3风险管理3.4监督和控制机制4.

技术过程4.1方法，工具和技术4.2软件文档4.3项目支持功能5.

工作元素，日程表和预算软件项目管理计划（SPMP）

2.3项目管理活动

在项目定义期间，项目经理的主要活动是定义组织结构和定义工作产品、任务、时间表和角色。团队领导在项目定义阶段的最后时刻参加项目，他们的主要工作是在稳定状态下监督和管理团队。

2.3.1计划项目

定义问题、确定初始任务模型和组织结构、评估所需的资源，如人员和资金。这一阶段要完成以下的工作：1．问题陈述：记述了当前情况、要支持的功能和系统要使用的环境，也要定义客户希望的产品、交付日期和一套验收标准，可能也指定了开发环境中的限制，例如要用的编程语言。

2．顶层设计：顶层设计描述了系统的软件体系结构，应由软件结构师完成。软件结构师定义主要的子系统及其服务，但还不定义子系统的界面。3．软件项目管理计划（SPMP）：描述了项目的所有管理方面，特别是工作分解结构、日程表、组织、工作包和预算。2.3.2组织项目

雇用参与者、确定技能、为参与者分配角色和责任并组织指导与项目总结有关的会议。

1．设立交流设施2．定义技能3．分配管理角色4．分配技术角色5．处理技能缺乏6．选择团队规模三个成员。

四个成员。

五个或六个成员。这是规模理想的软件开发团队。

七个成员。

八个和更多成员。7．聚集团队8．总结会议9．对项目范围达成一致在项目总结完成和对项目范围取得一致后，项目进入稳定状态。

2.3.3控制项目

项目监督、风险管理和项目协议。

为了在项目稳定阶段做出有效的决定，项目经理需要准确的状态信息。不幸的是，搜集准确的状态信息非常困难。

可以用如下一些工具来搜集状态信息。1.会议2.度量标准：度量财政状态。度量技术进度。度量稳定性。度量模块性。度量成熟性。3.管理风险：风险管理关注项目定义中可能存在的问题，并希望在在严重影响交付日期或预算之前说明这些内容。风险管理的关键点是能准确及时地报告风险和问题。风险管理的第一步是定义风险。风险可以是管理方面的，也可以是技术方面的。

标明风险的优先级能使项目经理专注于关键风险的管理。风险按它们能变成问题的可能性，以及当风险变成问题时，对项目发生的潜在影响，能被分成4类：

很可能的，存在高潜在影响

不太可能的，存在高潜在影响很可能的，存在低潜在影响不太可能的，存在低潜在影响。

主要内容需求分析的概念和原则

传统的软件需求分析基础

3.1需求分析的概念和原则

需求分析的基本任务是准确地回答“系统必须做什么？”这一核心问题。

需求分析是发现、求精、建模和规约的过程。这一过程包括：详细精化最初由系统分析员建立在软件项目计划中确定的软件范围，创建所需数据流、控制流以及操作行为的模型，在此基础上选择解决方案。

问题定义阶段在需求分析之前，需要描述和定义问题。问题定义阶段必须回答的关键问题是“要解决的问题是什么”。通过对系统的实际用户和使用部门负责人的访问调查，最后得出一份双方都满意的文档。问题定义阶段是软件生存周期中最简短的阶段，一般只需要一天甚至更少的时间。

可行性研究阶段

这个阶段要回答的关键问题是“对于上一个阶段所确定的问题有行得通的解决办法吗？”

系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程。如果系统分析员通过可行性研究之后，得出该工程项目不值得做的结论时，应该及时中止投资该工程项目，可以避免更大的浪费。

3.1.1需求分析

需求分析是一种软件工程活动，使得系统分析员能够刻划出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束。需求分析是软件设计师进行软件分解的基础，需求分析建造了软件处理的数据模型、功能模型和行为模型。需求分析为软件设计师提供了可被翻译成数据、体系结构、界面和过程设计的模型，最后，需求规约为软件设计师和客户提供了软件建造完后，进行质量评估的依据。

1.软件需求的概念和分类

比较权威的需求的定义来自于IEEE软件工程标准词汇表中的定义：l

用户解决问题或达到目标所需要的条件。l

系统或系统部件要满足合同、标准、规范或其他正式规定的文档所要具有的条件。l

反映上面两条的文档说明。IEEE公布的需求定义分别从用户和软件工程师的角度阐述了什么是需求，需求一方面反映了系统的外部行为，另一方面反映了系统的内部特性，反映的方式是需求文档。比较通俗的需求定义如下：需求是指明系统必须实现什么的规格说明，它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

需求的类别

功能需求：指定系统必须提供的服务，通过需求分析应该划分出系统必须完成的所有功能；性能需求：指定系统必须满足的定时约束或容量约束；可靠性和可用性需求：定量地指定系统的可靠性与可用性；出错处理需求：说明系统对环境错误应该怎样响应；接口需求：描述应用系统与其环境通信的格式；约束：描述了应用系统应遵守的限制条件；

逆向需求：说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除发生误解的那些逆向需求；将来可能提出的要求：应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。2.需求分析的任务

需求分析的任务是借助于当前系统的物理模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题。所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求。必须全面理解用户的各项要求，但只能接受合理的要求。要将软件的需求准确地表达出来，形成软件需求说明书。

需求分析的任务

获得当前系统的物理模型：首先，分析、理解当前系统是如何运行的，并用一个具体的模型来反映自己对当前系统的理解。

抽象出当前系统的逻辑模型：在理解当前系统“怎样做”的基础上，取出非本质因素，抽取出“做什么”的本质。

建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，明确目标系统要“做什么”，从而从当前系统的逻辑模型中，导出目标系统的逻辑模型。

对目标系统逻辑模型进行补充：具体内容如用户界面、启动和结束、出错处理、系统输入输出、系统性能、其他限制等等。

3．需求分析的主要工作

软件需求分析可被划分成5个工作阶段：问题分析；问题评估和方案综合；建模；规约；复审。

例1.

汽车零件的主要供应商需要一个库存控制系统，系统分析员发现与当前的手工系统相关的问题包括：（1）不能快速地获得部件的状况；（2）更新卡片文件需要2至或3天的工作量；（3）由于没有办法查找相关厂商的部件信息，而使得对同一厂商同一货品多次再订货，等等。一旦问题被标识出来，系统分析员将确定新系统该产生什么信息，以及将提供什么信息。

例2.

客户希望得到指明什么零件从库存中取出、以及还剩余多少相似零件的日报表。客户指明一旦当该零件离开仓库时库存管理员就该记载每个零件的标号。通过对当前问题和希望的信息（输入和输出）进行的评估，系统分析员开始综合一个或多个解决方案。为了便于开始，必须详细地定义系统的数据、处理功能和行为。

例3.

在例1与例2的基础上，一些可以进一步思考内容是，一旦已经建立这些信息，就该考虑针对实现的基本体系结构，那么客户/服务器方法似乎是合适的，但是它确实属于软件计划的范围吗？似乎需要一个数据库管理系统，但是，该数据库系统真的是用户需要的吗？继续这种评估和综合的过程，直至分析员和客户均确信针对后面的开发步骤软件确实已被适当地刻划了。

在整个评估和综合过程中，分析员的主要焦点是“做什么”，而不是“怎么做”。在问题评估和综合解决方案的活动中，系统分析员创建系统模型，以便可以更好地理解数据流和控制流、处理功能和操作行为以及信息内容。

4.系统分析员的主要能力

在整个系统分析活动中，系统分析员起着关键的作用，其本人应该具备突出的能力，如：能掌握抽象概念，能对其进行分类，能从中综合出解的能力；能从冲突或者混淆中吸取恰当事实的能力；能弄清用户环境的能力；能为用户系统恰当配置软硬件的能力能较好地用书面和口头形式进行沟通的能力有“从树木见森林”的能力。

3.1.2需求获取

软件需求分析中需要很好的的相互沟通，沟通总是要在两方或多方间进行。

客户和系统分析员之间最常用的交流方式，是通过预备会议或访谈进行的。获取用户需求的主要方法是调查研究。做好准备制定调研计划准备调研资料访谈用户写调研报告评审系统分析员所问的第一组问题可以关注客户、整体目标和收益。接下来的下一组问题使得系统分析员能够对问题做更好的理解，使得客户能够表达其关于解决方案的感觉，最后一组问题关注于会议的效果。FAST方法

也可以采用一种面向团队的需求收集方法，该方法被应用在分析和规约的早期阶段，被称为便利的应用规约技术，即FAST技术。该方法鼓励建立客户和系统分析员之间的合作，由他们共同工作来标识问题、提出解决方案的要素、商议不同的方法以及刻画出初步的解决方案需求。

FAST方法的基本原则

在中立的地点举行会议，由系统分析员和客户出席。

建立准备和参与会议的规则。建议一个足够正式的议程，以便可以对所有重要的、而又是足够非正式的问题进行自由交流。有一个“协调者”控制会议过程。使用一种“定义机制”记录有关信息。会议的目标是标识问题、提出解决方案的要素、商议不同的方法以及在有利于完成目标的氛围中，刻画出初步的解决方案需求。3.1.3分析原则

在过去20年，研究者已经开发出一些实用分析方法及相应的建模符号，每种分析方法有独特的观点，然而，所有分析方法都遵循以下操作原则：必须表示可理解的问题信息域。必须定义软件将完成的功能。必须表示软件的行为。必须划分描述信息、功能和行为的模型，从而能以层次的方式揭示细节。分析过程应该从要素信息移向细节实现。

除了上面提到的操作性分析原则，Davis提出了一组针对需求工程的指导性原则：

在开始建立分析模型前，先充分理解问题。开发原型，使得用户能够了解如何进行人机交互。记录每个需求的起源及原因。使用多个需求视图。建立数据、功能和行为模型，为软件工程师提供三种不同的视图。给需求赋予优先级。努力删除歧义性。1.信息域

所有的应用软件均可称为数据处理系统。信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息，这些信息被进一步变换为输出。沿着这个变换路径，可能从现存的数据存储中引入附加的信息。数据的变换是程序必须完成的功能或子功能，在两个变换（功能）间流动的数据和控制定义了每个功能的接口。信息结构表示了各种数据和控制项的内部组织，

2.建模

我们创建模型，以获得对将要建造的实际实体有更好的理解。要对软件变换的信息、对变换发生的功能（和子功能）、以及对变换发生时的系统行为进行建模。在软件需求分析阶段，我们创建系统模型，这些模型着重于描述系统必须做什么而不是如何去做。我们常使用图形符号创建模型。

功能模型：记录软件的变换信息，为了达到此目标必须至少完成三个常见功能：输入、处理和输出。行为模型：一个计算机程序总是存在于某个状态，仅当某事件发生时才被改变。行为模型创建了软件状态的表示，以及导致软件状态变化的事件表示。

需求分析阶段创建模型的作用模型帮助分析员理解系统的信息、功能和行为，因此，使得需求分析任务更容易实现。

模型变成了复审的焦点，因此，也成为确定规约的完整性、一致性和精确性的重要依据。模型变成了设计的基础，为设计者提供了软件要素的表示视图，该表示可被转化到实现中去。

3.划分

实际的问题经常太大而且复杂难于进行整体理解，我们往往将这样的问题划分为易于理解的子问题，并建立各子问题间的接口，以便完成整个功能。第四条操作性分析原则建议划分软件的信息、功能和行为域。3.1.4需求规格说明

软件需求规格说明是分析任务的最终产物，美国国家标准局、IEEE以及美国防部门均已提出了软件需求规约（以及其他软件工程文档）的候选格式。

软件需求规格说明必须正确地定义所有的软件需求；除了设计上的特殊限制之外，软件需求规格说明中一般不描述任何设计、验证或项目管理的细节。

需求必须描述的基本问题功能——所设计的软件要做什么；

性能——软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等；

强加给实现的设计限制——在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标准；

属性——可移植性、正确性、可维护性及安全性等方面的考虑因素；

外部接口——与人、硬件、其他软件和其他硬件的相互关系。

软件需求规格说明的大纲

1前言1.1目的1.2范围1.3定义、缩写词、略语1.4参考资料2项目概述2.1产品描述2.2产品功能2.3用户特点2.4一般约束2.5假设和依据

3具体需求3.1功能需求3.1.1功能需求1

引言

输入

加工

输出3.1.2功能需求2……

3.1.n功能需求n

3.2外部接口需求3.2.1用户接口3.2.2硬件接口3.2.3软件接口3.2.4通信接口3.3性能需求3.4设计约束3.4.1其他标准的约束3.4.2硬件的限制…………

3.5属性3.5.1安全性3.5.2可维护性…………

3.6其他需求3.6.1数据库3.6.2操作3.6.3场合适应性…………

附录索引3.1.5评审

需求审查是需求分析阶段工作的最后一步，是由软件软件工程师和客户一起进行并完成的。目的是发现软件需求规格说明中的错误、二义性和遗漏的需求。复审首先在宏观的级别上进行，复审者试图保证软件需求规格说明是完整的、一致的、精确的。然后复审会更详细，关注软件需求规格说明中的措词。3.2传统的软件需求分析基础

结构化的分析方法是最经典的需求分析方法。适用于数据处理类型软件的需求分析。它提供的工具包括：数据流图、数据字典、结构化英语、判定表和判定树。

系统的分析模型必须达到三个主要目标：（1）描述客户的需要；（2）建立创建软件设计的基础；（3）定义在软件完成后可以被确认的一组需求。实体—关系图状态—迁移图数据流图数据对象描述加工规格说明数据字典控制规格说明模型的核心是数据字典——一个包含了软件使用或生产的所有数据对象描述的中心库。实体-关系图描述数据对象间的关系，实体-关系图是用来进行数据建模活动的。数据流图有两个目的：指明数据在系统中移动时如何被变换；描述对数据流进行变换的功能（和子功能）。它可以用于信息域的分析，作为功能建模的基础。状态转换图指明系统将如何动作。为此，状态转换图表示了系统的各种行为模式（称为“状态”），以及在状态间进行变迁的方式，状态转换图是行为建模的基础。3.2.1数据流图

任何软件系统（或计算机系统）从根本上来说，都是对数据进行加工或变换的工具。

1.组成符号

例4.下面以教材购销系统中的教材销售为例，说明如何画数据流图。从用户调查中了解到某高校向学生销售教材的手续是：先由系办公室的张秘书开购书证明，学生凭证明找教材科的王会计开购书发票，向李出纳员交付书款，然后到书库找赵保管员领书。现欲将上述手工操作改为计算机处理，试画出教材销售过程的数据流图。

首先找出数据的源点和终点，即找出数据源与数据汇，由此确定系统的边界。由于是由学生开始购书，最后由学生领书，因此数据的源点和终点都是“学生”。第二步找出加工，需要从描述中抽象出系统要完成的工作。学生须凭购书证明得到购书发票，然后交付书款，得到领书凭证，最后领书。其间能由计算机完成的工作是审查学生的购书凭证并开出发票，按发票开出领书单，由此我们得到2个加工（审查并开发票，并领书单）。

第三步要找出数据流。

学生向系统提交购书单，学生从系统得到领书单，在加工之间要传输发票信息，这样我们得到3个数据流。同时还要注意在“审查并开发票”加工中排除了无效的书单，它也因作为一个数据流，因此最后得到4个数据流：购书单，发票，领书单，无效书单。我们还要补充数据存储。数据存储一般不能通过系统描述确定，而要在设计数据流图时按照需要添加。

实际上在审查购书单和开出发票之前，至少要查阅两个文件：①各班学生用书表，②教材存量表。

把这两个文件加进上图中，并给加工添上编号，就得到计算机售书系统的完整的数据流图。2.命名

数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。给这些成分起名字时应该仔细推敲。下面讲述在命名时应注意的问题：

为数据流（或数据存储）命名

名字应代表整个数据流（或数据存储）的内容，而不是仅仅反映它的某些成分。考生姓名分类后的姓名录取分类注意合适的命名，尽量用现实存在的表格、单据。不要使用空洞的、缺乏具体含义的名字（如“数据”、“信息”、“输入”之类）。不要把控制流作为数据流。汇款单格式错误合格的汇款单核准的汇款单格式检查计算汇费取下一个考生成绩录取分类为处理命名通常先为数据流命名，再为与之相关联的处理命名

名字应该反映整个处理的功能，而不是它的一部分功能。名字最好有一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能跟恰当些。如果在为某个处理命名时遇到了困难，则很可能是分解不恰当造成的，应该考虑重新分解。数据的源点和终点并不需要在系统中实现，它们只是系统的外围环境（可能是人员、计算机外部设备或传感器等）。通常为数据的源点和终点命名是采用它们在问题中习惯使用的名字，如“学生”，“管理员”。

3.分层数据流图

对任何一层数据流图来说，我们称它的上层图为父图，在它下一层的图则称为子图。

在多层数据流图中，顶层流图仅包含一个加工，它代表将被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据。底层流图是指其加工不需再做分解的数据流图，它处在最底层。中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。

4．数据流图实例

建立数据流模型的基本步骤概括地说，就是自外向内、自顶向下、逐层细化、完善求精。

例5.

建立一个简化的商业自动化系统。其中：售货员负责录入销售的商品（商品名，编号，单价，数量），有时要根据特定情况对销售的商品进行修改或删除。收款员负责收取现金，并将多交的付款退还用户。销售经理需要随时查询整个部门的销售情况（时间，商品编号，销售金额），并在每日结束时，统计各类商品的销售金额。

首先：建立系统环境，确定系统边界，画出顶层DFD。

其中：1数据流为：销售的商品，日销售额等

2数据源点为：营业员，经理，收款员

3数据终点为：经理，收款员

4加工名为：要建立的系统名字然后自顶向下，逐层分解。

A、按人或部门的功能要求，将加工“打碎”，形成：录入、修改或删除商品信息录入、修改现金额,并计算余额查询商品销售情况计算日销售额123注：需给每一加工编号B、”分派”数据流，形成：录入、修改或删除商品信息

2录入、修改现金额,并计算余额查询商品销售情况计算日销售额销售的商品现金额现金余额查询要求销售情况日销售额13其中：要根据特定的加工要求进行分派；保持与顶层数据流的一致；可以不引入数据源和数据终点。C、引入文件，使之形成一个有机整体—系统录入、修改或删除商品信息录入、修改现金额,并计算余额查询商品销售情况计算日销售额销售的商品现金额现金余额查询要求销售情况日销售额销售文件123注：到一个文件，既有输入流，又有输出流，则可简化为，并可不给出标识。至此，体现精化，形成0层数据流图。

继续A、B、C：自顶向下，逐层分解。例如：加工3查询商品销售情况计算日销售额查询要求销售情况日销售额销售文件3可分解为：3.1判定要求查询要求

3.2统计销售情况

3.3计算日销售额销售文件查询要求2查询要求1销售情况日销售额5.注意事项

画数据流图不是画流程图。数据流图只描述“做什么”，不描述“怎么做”和做的顺序，而流程图表述对数据进行加工的次序和细节。

父图和子图的平衡。正常情况下，父图和子图的输入数据和输出数据应分别保持一致，称为父子平衡。

局部文件。随着数据流图的分解，在下层数据流图中允许出现父图中没有的文件。

要遵守加工编号规则。顶层加工不编号；第二层的加工编为1，2，…，n号；第三层编为1.1，1.2，…，n.1，n.2，…等号，依此类推。

分解的深度与层次。逐层分解时，要求加工分解到足够简单，易于理解为止，这一加工也就是我们常说的基本加工。分解的层次多少是合适的，这应当根据问题的复杂程度来确定。可以参考以下一些经验性的原则。

一个加工的分解，最多不要超出7个子加工。分解在逻辑上应合理、自然，不能硬性分割。

在保证数据流得以理解的前提下，尽量少分解层次。分解要均匀。即在一张数据流图中，尽量少出现有些加工已是基本加工，有些还要分解好几层的情况。

3.2.2数据字典

数据字典的作用，就是描述软件中的每个数据和加工的具体含义，以保持数据在系统中的一致性。

有了数据流图和数据字典才算是较完整地描述了一个系统。数据流图和数据字典是需求规格说明书的主要组成部分。

数据字典要对数据流图中出现的所有名字（数据流、加工、数据存储）进行定义。

在数据字典中，描述数据元素之间的关系时，可以使用自然语言也可采用以下符号：

=等价于（或定义为）

+与

[|]或（从方括号内由“|”号隔开的分量中选择一个）

{}重复（）选择

常常使用上限和下限符号，以进一步注释表示重复的括号。例如：和1{A}5都表示A重复5次。

数据流条目学生=学号+姓名+性别+系+年级+选修课程选修课程=课程号+课名+学时+学分+课表课表={星期几+第几节+教室}年级=[1|2|3|4]=[1..4]文件条目列出数据存储的组成数据项及文件的组织方式航班目录文件={航班号+起点+终点+时间}组织：按航班号次序排列加工条目只列出基本加工的小说明描述加工逻辑，也包括与加工有关的其他信息用结构化自然语言描述1、数据流:销售的商品=商品名+商品编号+单价+数量+日期现金额=余额=非负实数查询要求=[商品编号|日期]查询要求1=商品编号查询要求2=日期销售情况=商品名+商品编号+金额日销售额={类名+现金额}2、数据存贮:销售文件={销售的商品}3、数据项给出加工小说明可以使用判定表、判定树判断表Ⅰ条件类别Ⅱ条件组合

Ⅲ操作Ⅳ操作执行例如：考试总分>=620>=620<620

单科成绩有满分有不及格有满分发升级通知书yyn

发留级通知书nny

发重修通知书nyn3.2.3实体－关系图（E-R图）

实体－关系图中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。

是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，而且与软件系统中的实现方法无关。

1.数据对象、属性与关系

数据对象是软件必须理解的复合信息的抽象。

数据对象彼此间是有关联的。属性定义了数据对象的特征。它可用来：①

为数据对象的实例命名；②

描述这个实例；③

建立对另一个数据对象的另一个实例的引用。数据对象彼此之间相互连接的方式称为联系，也称为关系。

联系可分为以下3种类型

一对一联系（1∶1）

一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。

一对多联系（1∶N）

每位教师可以教多门课程，但是每门课程只能由一位教师来教，则某校教师与课程之间存在一对多的联系。

多对多联系（M∶N）一个学生可以学多门课程，而每门课程可以有多个学生来学，则学生与课程间的联系是多对多的。

2.实体－关系图实例

例12.

在教学管理中，一个教师可以教授零门、一门或多门课程，每位学生也需要学习几门课程。用E-R图描述。

3.2.4状态转换图

状态转换图（简称为状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果，系统将做哪些动作（例如，处理数据）。

1.组成部分及其符号表示

状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。

在状态图中定义的状态主要有：初态（即初始状态）、终态（即最终状态）和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。

状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。

事件是在某个特定时刻发生的事情，它是对引起系统做动作或系统状态转变的外界事件的抽象。状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。

当有多个进程申请占用CPU运行的时，有关CPU分配的进程的状况，可以用以下状态迁移图表示。

CPU分配的状态迁移表

2.状态转换图实例

画出电话系统的状态图。没有人打电话时电话，电话处于闲置状态；有人拿起听筒，则进入拨号音状态，到达这个状态后，电话的行为是响起拨号音并计时；这时如果拿起听筒的人改变主意不想打了，他把听筒放下（挂断），电话重又回到闲置状态；如果拿起听筒很长时间不拨号（超时），则进入超时状态；……。

软件设计的基本目的就是回答“系统应该如何实现？”这个问题。软件设计的任务，就是把分析阶段产生的软件需求规格说明转换为用适当手段表示的软件设计，并形成软件设计文档。4.1软件设计的目标和任务

1.软件设计的目标软件设计一般都包括数据设计、体系结构设计、接口设计和过程设计(或称构件级设计)等设计活动。软件设计的过程和目标就是，根据用信息域表示的软件需求，以及功能和性能需求，进行数据设计、系统结构设计、过程设计。在每个设计活动中，软件开发者应用导致高质量的基本概念和原则，产生软件的数据设计模型、体系结构设计模型、接口设计模型和过程设计模型。软件设计过程最终目标是产生一个设计规约，该规约包括描述数据、体系结构、接口和构件的设计模型。体系结构设计定义软件主要结构性元素之间的关系。数据设计将分析阶段创建的信息模型转变成实现软件所需的数据结构。接口设计描述软件内部模块之间以及软件与人之间是如何通信的。构件级设计将软件体系结构的结构性元素转变成对软件构件的过程性描述，即描述软件构件的详细内部设计细节。4.1软件设计的目标和任务

2.软件设计的任务从工程管理的角度来看，传统的软件设计任务通常分两个阶段完成。第一个阶段是概要设计，即总体设计。第二阶段是详细设计阶段，即过程设计。4.2软件设计基本概念

4.2.1模块与模块化

1．模块模块是指这样一组程序语句，它包括输入、输出和逻辑处理功能、内部信息及其运行计划。模块指可单独命名且可通过名字访问的过程函数、子程序或宏调用。4.2软件设计基本概念

模块具有以下几种特征：接口，模块的输入输出；功能，指模块实现什么功能，有什么作用；逻辑，描述模块内部如何实现需求及所需数据；状态，该模块的运行环境，模块间调用与被调用关系。4.2软件设计基本概念

2．模块化模块化就是将程序划分成若干个独立的模块，每个模块完成一个特定子功能，每个模块既是相对独立的，又是相互联系的，它们共同完成系统指定的各项功能。模块化的目的是为了降低软件的复杂性。4.2软件设计基本概念模块化论据：C(x)定义为表示问题x复杂性的函数；E(x)定义为解决问题x所需要工作量（以时间计算）的函数；则，对p1和p2两个问题，若C(p1)>C(p2)，则E(p1)>E(p2)。4.2软件设计基本概念一有趣的特性。即：C(p1+p2)>C(p1)+C(p2)；E(p1+p2)>E(p1)+E(p2)。上述表达式意味着：“分而治之”的结论。4.2软件设计基本概念图4.2软件设计成本与模块数量关系图最小成本区域M软件总成本模块数量成本或工作量集成成本成本/模块4.2软件设计基本概念4.2.2抽象与逐步求精

1．抽象抽象是指从一些事物中抽取其本质的共同的特性，而忽略其非本质细节的差异。在抽象的最高层次使用问题环境的语言，在较低层次上使用更过程化的方法，把面向问题的术语和面向实现的术语结合起来描述问题的解法。4.2软件设计基本概念2．逐步求精逐步求精是一种先总体、后局部的思维原则，也就是一种逐层分解、分而治之的方法。从在高抽象级别定义的功能陈述（或信息描述）开始，该陈述概念性地描述了功能或信息，但没有提供有关功能内部工作的情况或信息的内部结构。求精是设计者详细描述的原始声明，在后续求精（详细描述）活动中，提供越来越多的细节。4.2软件设计基本概念4.2.3信息隐藏信息隐蔽是在设计和确定模块时，使得一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说，是不能访问的。4.2软件设计基本概念4.2.4模块独立性模块独立性（ModuleIndependence）概括了把软件划分为模块时要遵守的准则，也是判断模块构造是不是合理的标准，同时也是模块化和抽象及信息隐藏概念的直接产物。坚持模块的独立性，一般认为是获得良好设计的关键。换句话说，希望这样设计软件结构，使得每个模块只完成系统要求的一个相对独立的特定子功能，并且和其他模块之间的关系很简单。4.2软件设计基本概念为什么模块的独立性很重要呢？第一，有效的模块化（即具有独立的模块）软件比较容易开发出来。第二，独立模块比较容易测试和维护。独立性可以从两个方面来度量，即模块本身的内聚（Cohesion）和模块之间的耦合（Coupling）。4.2软件设计基本概念1．内聚这是从功能角度对模块内部聚合能力的量度。按照由弱到强的顺序，Myers把模块内部聚合能力分为7类，在图中，从左到右内聚强度逐步增强。

低内聚中内聚高内聚①偶然性内聚CoincidentalCohesion②逻辑性内聚LogicalCohesion③时间性内聚TemporalCohesion④过程性内聚ProceduralCohesion⑤通信性内聚CommunicationalCohesion⑥顺序性内聚SequentialCohesion⑦功能性内聚FunctionalCohesion

①②③④⑤⑥⑦4.2软件设计基本概念①偶然性内聚块内各组成成分在功能上是互不相关的。XYZWA=B+CGETCARDPUTOUTPUTIFI=5THENE=0……4.2软件设计基本概念②逻辑性内聚这种模块把几种相关、相似功能组合在一起，每次被调用时，由传递给模块的参数来确定该模块应完成哪一种功能。XYZWABCDXYZWABCD4.2软件设计基本概念③时间性内聚如果一个模块所包含的任务必须在同一“时间”内完成，则这个模块的块内联系称为时间性内聚。紧急意外故障处理关闭文件报警保留现场...4.2软件设计基本概念④过程化内聚当一个模块中包含的一组任务必需按照某一特定的次序执行时，就称为过程性内聚模块。建立方程组系数矩阵高斯消去法回代4.2软件设计基本概念⑤通信性内聚模块内部的各个成分都使用同一种输入数据，或者产生同一个输出数据。它们靠公用数据而联系在一起，故称为通信性内聚。开领书单登记售书删除修改发票领书单售书登记表文件4.2软件设计基本概念⑥顺序性内聚如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行，通常一个处理元素的输出数据作为下一个处理元素的输入数据，则成为顺序性内聚。A输入系数求解打印方程解.4.2软件设计基本概念⑦功能性内聚如果一个模块包括仅为完成某一具体任务所必需的所有成分，或者说模块中所有成分结合起来是为了完成一个具体的任务，此模块则为功能强模块。4.2软件设计基本概念2．耦合耦合是对软件内部模块之间相互联系的度量。按照Myers的划分，也归纳为7类。①②③④⑤⑥⑦弱耦合中耦合较强耦合强耦合①非直接耦合NoDirectCoupling②数据耦合DataCoupling③特征耦合StampCoupling④控制耦合ControlCoupling

⑤外部耦合ExternalCoupling⑥公共耦合CommonCoupling⑦内容耦合ContentCoupling

4.2软件设计基本概念①非直接耦合若两个模块没有直接关系，它们之间的联系完全是通过主程序的控制和调用来实现的，便称这两个模块为非直接耦合，这样独立性最强。ACBD无块间联系4.2软件设计基本概念②数据耦合若一个模块访问另一个模块，且被访问模块的输入和输出都是数据项参数，则称这两个模块之间的联系为数据耦合。通过变元传递数据AB……4.2软件设计基本概念③特征耦合若两个以上的模块都需要其余某一数据结构的子结构时，不使用其余全局变量的方式而是用记录传递的方式，这样的耦合称为特征耦合。模块1与模块2为同级模块，相互之间没有信息传递，属于非直接耦合。模块3、4都是模块1的下属模块。模块1调用它们时，可通过参数表与它们交换数据。如果交换的都是简单变量，便构成数据耦合（如模块1、3之间）；如果交换的是数据结构，便构成特征耦合（如模块1与模块4之间）。模块1模块2模块3模块44.2软件设计基本概念④控制耦合控制耦合是中等强度的耦合。此时在模块间传递的信息不是一般的数据，而是用作控制信号的开关值或标志量（Flag）。4.2软件设计基本概念⑤外部耦合若允许一组模块访问同一个全局变量，可称它们为外部耦合。B……A有名公共区4.2软件设计基本概念⑥公共耦合若允许一级模块访问同一个全局性数据结构，则称之为公共耦合。⑦内容耦合最强的一类耦合称为内容耦合。如果一个模块可以直接调用另一模块中的数据，或者允许一个模块直接转移到另一模块中去。4.2软件设计基本概念4.2.5软件体系结构4.2.6程序结构程序结构也称作控制层次，它代表了程序构件（模块）的组织（常常是结构化的）并暗示了控制的层次结构。4.2.7数据结构

扇出数：2扇入数：4Mabcdghienomlkjf宽度深度4.3软件设计原则

Davis提出了一系列软件设计的原则，下面的内容是在这些原则上的总结和扩充：设计过程应该能够预测和评估。应该是可跟踪的。设计应该重视资源重用。软件设计的结构应该（尽可能）模拟问题域的结构。4.3软件设计原则

设计应该表现出一致性和集成性。设计应该适应扩展和变更。设计应该考虑软件的容错性和处理错误、异常的能力。设计不是编码，编码也不是设计。在创建设计时就应该能够评估质量，而不是在事情完成之后。应该评审设计以减少概念性（语义性）错误。4.4软件程序结构的启发式设计准则与优化1．改进软件结构，降低耦合并提高内聚，以提高模块独立性。2．模块规模应该适中经验表明，一个模块的规模不应过大，模块的总行数应控制在10到100行的范围内，最好为30至60行，能在一张打印纸内容纳下，这样理解和阅读都较方便。3．保持适当的扇入和扇出一个模块的扇入数表明有多少个上级模块直接调用它。扇出数衡量的是被一个模块直接控制的其他模块的数量。通常扇出数3—4为宜，最好不超过5—7。4．模块的作用域应该在控制域内一个模块的控制域，是模块本身及其所有从属以及最终的从属模块（即所有可供它调用的下级模块）。一个模块的作用域，是受这个模块中决策影响的其他模块。只要模块中含有一些依赖于这个判定的操作，这个模块就在这个判定的作用范围之内。图4.23判定位置违反了作用域/控