软件工程全册课件

第1部分软件工程基础第1章软件及软件工程介绍1.1软件与软件危机软件的作用具有产品和产品生产载体的双重作用。作为产品，软件显示了由计算机硬件体现的计算能力，扮演着信息转换的角色：产生、管理、查询、修改、显示或者传递各种不同的信息。作为产品生产的载体，软件提供了计算机控制（操作系统）、信息通信（网络），以及应用程序开发和控制的基础平台（软件工具和环境）。

1.1软件与软件危机软件的概念

虽然软件对于现代的人并不陌生，但很多人对于软件的理解并不准确，“软件就是程序，软件开发就是编程序”的这种错误观点仍然存在。什么是软件？1.1软件与软件危机软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。程序是按事先设计的功能和性能要求执行的指令序列。数据是使程序能正常操纵信息的数据结构。文档是与程序开发，维护和使用有关的图文材料。1.1软件与软件危机软件的特性(1)

形态特性:软件是无形的、不可见的逻辑实体。度量常规产品的几何尺寸、物理性质和化学成分对它却是毫无意义的。

(2)

智能特性：软件是复杂的智力产品，它的开发凝聚了人们的大量脑力劳动，它本身也体现了知识实践经验和人类的智慧，具有一定的智能。它可以帮助我们解决复杂的计算、分析、判断和决策问题。(3)

开发特性:尽管已经有了一些工具（也是软件）来辅助软件开发工作，但到目前为止尚未实现自动化。软件开发中仍然包含了相当份量的个体劳动，使得这一大规模知识型工作充满了个人行为和个人因素。(4)

质量特性：目前还无法得到完全没有缺陷的软件产品。1.1软件与软件危机(5)

生产特性:与硬件或传统的制造业产品的生产完全不同，软件一旦设计开发出来，如果需要提供多个用户，它的复制十分简单，其成本也极为有限。(6)

管理特性：由于上述的几个特点，使得软件的开发管理显得更为重要，也更为独特。1.1软件与软件危机(7)

环境特性:软件的开发和运行都离不开相关的计算机系统环境，包括支持它的开发和运行的相关硬件和软件。软件对于计算机系统的环境有着不可摆脱的依赖性。

(8)

维护特性：软件投入使用以后需要进行维护，但这种维护与传统产业产品的维护概念有着很大差别。

1.1软件与软件危机(9)

废弃特性:与硬件不同，软件并不是由于被“用坏”而被废弃的

。

(10)

应用特性：软件的应用极为广泛，如今它已渗入国民经济和国防的各个领域，现已成为信息产业、先进制造业和现代服务业的核心，占据了无可取代的地位。1.1软件与软件危机软件危机暴发于上个世纪六十年代末。主要表现为：软件的发展速度远远滞后于硬件的发展速度，不能满足社会日益增长的软件需求。软件开发周期长、成本高、质量差、维护困难。1.1软件与软件危机软件危机典型例子：美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这个项目的负责人F.D.Brooks事后总结了他在组织开发过程中的沉痛教训时说：

……正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深。最后无法逃脱灭顶的灾难，……程序设计工作正像这样一个泥潭，……一批批程序员被迫在泥潭中拼命挣扎，……谁也没有料到竟会陷入这样的困境……1.1软件与软件危机具体来说，软件危机主要有以下一些典型表现:对软件开发成本和进度的估计常常很不准确。用户对“已完成的”软件系统不满意的现象经常发生。软件产品的质量往往靠不住。软件常常是不可维护的。软件通常没有适当的文档资料。软件成本在计算机系统总成本中所占的比例逐年上升。软件开发生产率提高的速度，既跟不上硬件的发展速度，也远远跟不上计算机应用迅速普及深入的趋势。1.1软件与软件危机除了软件本身的特点，软件危机发生的主要原因有：

缺乏软件开发的经验和有关软件开发数据的积累，使得开发工作的计划很难制定。软件人员与用户的交流存在障碍，使得获取的需求不充分或存在错误。软件开发过程不规范。如，没有真正了解用户的需求就开始编程序。随着软件规模的增大，其复杂性往往会呈指数级升高。需要很多人分工协作，不仅涉及技术问题，更重要的是必须有科学严格的管理。缺少有效的软件评测手段，提交用户的软件质量不能完全保证。1.1软件与软件危机彻底消除“软件就是程序”的错误观念。充分认识到软件开发应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。推广和使用在实践中总结出来的开发软件的成功技术、方法和工具。按工程化的原则和方法组织软件开发工作。如何摆脱软件危机?1.1软件与软件危机1.2软件工程及其基本原理软件工程的概念为了克服软件危机，1968年10月在北大西洋公约组织（NATO）召开的计算机科学会议上，FritzBauer首次提出“软件工程”的概念，试图将工程化方法应用于软件开发。在NATO会议上，FritzBauer对软件工程的定义是：“软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。”1993年IEEE给出的定义：“软件工程是：①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；②研究①中提到的途径。”。1.2软件工程及其基本原理软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发和维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好技术结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。1.2软件工程及其基本原理1.2软件工程及其基本原理软件工程的目标软件工程的目标是运用先进的软件开发技术和管理方法来提高软件的质量和生产率，也就是要以较短的周期、较低的成本生产出高质量的软件产品，并最终实现软件的工业化生产。

1.2软件工程及其基本原理软件的质量特性：功能性、可靠性、可使用性、效率、可维护性和可移植性。功能性是指软件所实现的功能达到它的设计规范和满足用户需求的程度；可靠性是指在规定的时间和条件下，软件能够正常维持其工作的能力；可使用性是指为了使用该软件所需要的能力；效率是指在规定的条件下用软件实现某种功能所需要的计算机资源的有效性；可维护性是指当环境改变或软件运行发生故障时，为了使其恢复正常运行所做努力的程度；可移植性是指软件从某一环境转移到另一环境时所做努力的程度。1.2软件工程及其基本原理质量目标之间的关系(1)关注大型软件的构造(2)中心课题是控制复杂性(3)软件经常变化(4)开发软件的效率非常重要(5)和谐地合作是开发软件的关键(6)软件必须有效地支持它的用户(7)在软件工程领域中是由一种文化背景的人替具有另一种文化背景的人创造产品1.2软件工程及其基本原理软件工程的本质特性(1)按软件生存周期分阶段制订计划并认真实施(2)坚持进行阶段评审(3)坚持严格的产品控制(4)使用现代软件开发技术(5)明确责任

(6)用人少而精(7)不断改进开发过程1.2软件工程及其基本原理软件工程的基本原理1.3软件生命周期概念

软件也有一个孕育、诞生、成长、成熟和衰亡的生存过程，我们称这个过程为软件生命周期或软件生存期。软件生存期由软件定义、软件开发和运行维护3个时期组成，每个时期又可划分为若干个阶段。

1.3软件生命周期软件定义时期

主要任务是解决“做什么”的问题，即确定工程的总目标和可行性；导出实现工程目标应使用的策略及系统必须完成的功能；估计完成工程需要的资源和成本；制订工程进度表。

通常又分为3个阶段：问题定义、可行性研究和需求分析。

1.3软件生命周期软件开发时期

主要任务是解决“如何做”的问题，即具体设计和实现在前一个时期定义的软件。

由概要设计、详细设计、编码和测试4个阶段组成。

1.3软件生命周期软件运行维护时期主要任务是使软件持久地满足用户的需要，通常有4类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件，使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。1.3软件生命周期开发过程中的典型文档①软件需求规格说明书：描述将要开发的软件做什么。②项目计划：描述将要完成的任务及其顺序，并估计所需要的时间及工作量。③软件测试计划：描述如何测试软件，使之确保软件应实现规定的功能，并达到预期的性能。④软件设计说明书：描述软件的结构，包括概要设计及详细设计。⑤用户手册：描述如何使用软件。1.3软件生命周期各个阶段所要完成的基本任务问题定义与可行性研究本阶段要回答的关键问题是“到底要解决什么问题？在成本和时间的限制条件下能否解决问题？是否值得做？”(2)需求分析本阶段要回答的关键问题是“目标系统应当做什么？”(3)软件设计设计是软件工程的技术核心。本阶段要回答的关键问题是“如何实现目标系统？”1.3软件生命周期各个阶段所要完成的基本任务(4)程序编码和单元测试本阶段要解决的问题是“正确地实现已做的设计”，即“如何编写正确的、可维护的程序代码？”(5)集成和系统测试测试是控制软件质量的重要手段，本阶段的主要任务是做集成测试和系统测试。(6)软件运行和维护已交付的软件投入正式使用，便进入运行阶段。这一阶段可能持续若干年。软件在运行中可能由于多方面的原因，需要对它进行修改。

1.4软件工程方法学概念软件工程包含技术和管理两方面的内容，是技术和管理紧密结合所形成的工程学科。通常将软件开发全过程中使用的一整套技术方法的集合称为方法学(methedology)，也称为范型(paradigm)。目前使用最广泛的软件工程方法学：传统方法（结构化方法），面向对象方法。1.4软件工程方法学三要素：方法、工具和过程。软件工程方法为软件开发提供了“如何做”的技术;软件工具为软件工程方法提供了自动的或半自动的软件支撑环境;过程是为了获得高质量的软件所需要完成的一系列任务框架，它规定了完成各项任务的工作步骤。1.4软件工程方法学结构化方法也称为生命周期方法学或结构化范型。将软件生命周期的全过程依次划分为若干个阶段，采用结构化技术来完成每个阶段的任务。特点：

(1)强调自顶向下顺序地完成软件开发的各阶段任务;(2)结构化方法要么面向行为，要么面向数据，缺乏使两者有机结合的机制。1.4软件工程方法学面向对象方法是将数据和对数据的操作紧密地结合起来的方法。软件开发过程是多次反复迭代的演化过程。面向对象方法在概念和表示方法上的一致性，保证了各项开发活动之间的平滑过渡。对于大型、复杂及交互性比较强的系统，使用面向对象方法更有优势。1.5软件工程知识体系及知识域介绍软件工程教育(3个历史时期)

(1)1978年以前：软件工程教育以计算机专业的一门孤立的课程形式存在。

(2)1978—1988年期间：早期的研究生学位教育，开始建立软件工程专业的研究生学位教育项目。

(3)1988年以后：快速发展的研究生学科教育，使软件工程的理论快速发展，其中，卡内基·梅隆大学软件工程研究所（SEI）的影响不可忽视。

1.5软件工程知识体系及知识域介绍软件工程知识体软件工程已从计算机科学与技术中脱离出来，逐渐形成了一门独立的学科。对其知识体系的研究从20世纪90年代初就开始了。标志是美国Embry-Riddle航空大学计算与数学系ThomasB.Hilburn教授的“软件工程知识体系指南”（GuidetoSoftwareEngineeringBodyofKnowledge，SWEBOK）研究项目。1.5软件工程知识体系及知识域介绍软件工程知识体系指南的目标(1)促使软件工程本体知识成为世界范围的共识。(2)澄清软件工程与其他相关学科，如与计算机科学、项目管理、计算机工程以及计算机数学之间的关系，并且确定软件工程学科的范围。(3)反映软件工程学科内容的特征。(4)确定软件工程本体知识的各个专题。(5)为相应的课程和职业资格认证材料的编写奠定基础。

1.5软件工程知识体系及知识域介绍软件工程知识体系指南的内容

SWEBOK指南将软件工程知识体系划分为10个知识域（knowledgeareas，KA），分为两类过程。一类是开发与维护过程，包括软件需求、软件设计、软件构造、软件测试和软件维护；另一类是支持和组织过程，包括软件配置管理、软件工程管理、软件工程过程、软件工程工具与方法和软件质量。每个知识域还可进一步分解为若干论题。

1.5软件工程知识体系及知识域介绍软件工程知识体系指南的内容1.5软件工程知识体系及知识域介绍每个知识域又可分解为若干子知识域，如表所示。1.6软件产业的形成与发展我国软件产业的形成

软件产业是以开发、研究、经营、销售软件产品或软件服务为主的企业组织及其在市场上的相互关系的集合。软件产业是信息产业的核心，是国民经济基础性、战略性产业，直接关系国家政治、经济和社会的安全。目前我国软件产业链已经初步形成，在其形成的过程中，我国的软件产业主要经历了萌芽期、起步期、进入期和发展期4个阶段。进入了2000年以后，中国的软件企业开始进入网络软件时期。

1.6软件产业的形成与发展全球软件产业的发展到目前为止，全球软件产业的发展已经经历了比较完整的5代。第一代：早期专业的服务公司（1949—1959年）第二代：早期软件产品公司（1959—1969年）第三代：强大的企业解决方案提供商的出现（1969—1981年）第四代：客户大众市场软件（1981—1994年）第五代：互联网增值服务（1994年至今）

1.6软件产业的形成与发展软件产业的发展模式目前得到公认的产业发展模式有美国模式、印度模式、爱尔兰模式、日本模式等。

美国模式——技术与服务领导型美国的软件产业主要由3个部分组成。

(1)以商业销售或租赁为目的，设计和生产软件产品的公司。

(2)开发因特网和电子商务技术，提供网上信息和服务的公司。

(3)专为计算机提供软件服务的公司。1.6软件产业的形成与发展软件产业的发展模式印度模式——国际加工服务型

印度的软件产业属于外向型的产业，以外包服务为主，软件企业对于促进印度的出口起了十分重要的作用。

爱尔兰模式——生产本地化型根据欧洲市场20多种不同语言的实际需要，爱尔兰将自己定位为美国软件公司产品欧洲化版本的加工基地，吸引跨国软件公司和国际知名学府在国内建立研发和分支机构，实现国外软件产品本地化。1.6软件产业的形成与发展软件产业的发展模式日本和欧洲模式——嵌入式系统开发型日本以硬件带动软件发展，其软件属于嵌入式的。松下、东芝、日立等跨国公司都有自己的软件公司，他们研发的软件产品往往随着企业的各类产品出口世界各地。德国模式——企业级应用及自主研发型德国软件产业可分为“主要软件企业”和“辅助软件企业”两类。第一类除从事数据处理服务的企业外，还包括数据处理设备制造商。第二类是指机械制造、电子、通信、汽车、金融服务等行业的企业。

1.6软件产业的形成与发展软件工程在软件产业中的作用一方面，软件产业离不开软件工程理论及标准的指导；另一方面，软件产业的发展需要大量软件工程人才。软件工程理论是人们从长期的软件工程实践中总结出来的，对软件开发起着重要的指导作用。软件产业的发展需要大量的软件工程人才。实际情况已经证明，软件产业的竞争不仅是技术和资本的竞争，从根本上来讲是人才的竞争。

小结对软件及软件工程进行了概要介绍介绍了软件的作用、概念、特性及软件危机的主要表现；对软件工程的概念、软件工程的基本原理以及软件工程知识体系进行了简要介绍;最后介绍了软件产业的形成与发展以及软件工程在软件产业中的重要性。小结介绍了软件生命周期方法软件生命周期方法将软件生命周期划分为若干个相对独立的阶段，每个阶段都完成一定的任务；基本上按顺序完成各个阶段的任务；在完成每个阶段的任务时采用结构化技术和适当的软件工具；在每个阶段结束之前都进行严格的技术复审和管理复审。

软件生命周期方法使软件开发结束了之前的混乱状态。That'sAll!第一部分软件工程基础第2章软件需求获取与确定2.1软件需求获取的任务软件需求（softwarerequirement）是为了解决用户的问题或实现用户的目标，用户所需的软件必须满足的能力和条件。获取软件需求要涉及到多种人员，每种人员对需求的描述是不同的主要的需求种类业务需求：描述了使用软件系统要达到什么目标。系统需求：为了满足用户解决问题需要的条件或能力，系统或系统成分必须满足或具有的条件或能力。功能需求：规定了软件必须实现的功能性需求。非功能需求:在满足功能需求的基础上，软件系统还必须具有一定的特性和必须遵循一定的约束，非功能需求描述相应的特性和约束。2.2软件需求的获取与确认过程2.3快速原型化方法原型法（prototyping）是这样的一种软件开发技术，通过开发软件的初期版本让用户进行反馈来确定软件的可行性，研究开发技术或开发过程支持的其他问题。快速原型化（rapidprototyping）是一种原型法，它的重点是在开发过程的早期就开发出原型，使反馈和分析提前，以支持开发过程[1]。2.3快速原型化方法（1）演示原型通过演示原型向用户展示一些界面，让用户判断基于该原型的系统是否能够满足他们的要求。（2）技术验证原型该原型在技术层上实现软件的部分功能，以验证技术上的可行性。2.4基于用况的方法基于用况的方法通过建立用况模型来获取与确定需求。在建立用况模型时，要确定系统边界，找出在系统边界以外与系统交互的事物，然后从这些事物与系统进行交互的角度，通过用况来描述这些事物怎样使用系统，以及系统向它们提供什么功能。2.4.1系统边界系统边界是系统的所有内部成分与系统以外各种事物的分界线。系统只通过边界上的有限个接口与外部的系统使用者（人员、设备或外系统）进行交互。

2.4.1系统边界现实世界中的事物与系统的关系包括如下几种情况：■某些事物位于系统边界内，作为系统成分。■

某些事物位于系统边界外，作为参与者。■某些事物可能既有一个对象作为其抽象描述，而本身（作为现实世界中的事物）又是在系统边界以外与系统进行交互的参与者。■某些事物即使属于问题域，也与系统责任没有什么关系。认识清楚上述事物之间的关系，也就划分出了系统边界。2.4.2参与者参与者(actor)定义了一组在功能上密切相关的角色，当一个事物与系统交互时，该事物可以扮演这样的角色。参与者的表示法2.4.2参与者识别参与者参与者是在系统之外的与系统进行交互的任何事物。这些事物可为人员、外部系统或设备。

2.4.2参与者人员 直接使用系统的人员是参与者。这里强调的是直接使用，而不是间接使用。外部系统 所有与本系统交互的外部系统都是参与者。相对于当前在正在开发的系统而言，外部系统可以是其他子系统、下级系统或上级系统，也即任何与它进行协作的系统，但对这样的系统的开发并不是开发本系统的人员的责任。设备 识别所有与系统交互的设备：这样的设备与系统相连并向系统提供外界信息，也可能系统要向这样的设备提供信息，设备在系统的控制下运行。2.4.3用况用况(usecase)是描述系统的一项功能的一组动作序列，这样的动作序列表示参与者与系统间的交互，系统执行该动作序列要为参与者产生结果。用况名用况的表示法2.4.3用况使用用况来可视化、详述、构造和文档化所希望的系统行为。尽管用况中描述的行为是系统级的，但在用况内所描述的交互中的动作应该是详细的，准则是对用况的理解不产生歧义即可。若描述得过于综合，则不易认识清楚系统的功能。用况描述中的一个动作应该描述参与者或系统要完成的交互中的一个步骤。在用况中只描述参与者和系统彼此为对方直接地做了些什么事，不描述怎么做，也不描述间接地做了些什么。系统所产生的结果，是指系统对参与者的动作要做出响应。用况描述的是参与者所使用的一项系统功能，该项功能应该相对完整。也即应该保证用况是某一项功能的完整的规格说明，而不能只是其中的一个片段。在用况描述中，由参与者首先发起交互的可能性较大，但有些交互也可能是由系统首先发起的。收款员收款输入开始本次收款的命令；作好收款准备，应收款总数置为0，输出提示信息；for顾客选购的每种商品do

输入商品编号；

if此种商品多于一件then

输入商品数量

endif；检索商品名称及单价；货架商品数减去售出数；

if货架商品数低于下限then

通知供货员请求上货

endif；计算本种商品总价并打印编号、名称、数量、单价、总价；总价累加到应收款总数；endfor；打印应收款总数；输入顾客交来的款数；计算应找回的款数，打印以上两个数目，应收款数计入帐册。例2.4.3用况用况与参与者之间的关系

一个参与者可以同多个用况交互，一个用况也可以同多个参与者交互。把参与者与用况间的这种交互关系称为关联。若没做具体的规定，交互是双向的，即参与者能够对系统进行请求，系统也能够要求参与者采取某些动作。把参与者和用况之间的关联表示成参与者和用况之间的一条实线。若要明确地指出参与者和用况之间的通讯是单向的，就在关联线上接收通讯的那端加一个箭头，用以指示方向。

2.4.3用况收款检查售货员统计员2.4.3用况1）包含

A……用况XA……用况YA(A)……(A)……用况X用况Y<<include>>

<<include>>

2.4.3用况

从基用况到被包含用况的包含关系表明：基用况在它内部说明的某一（些）位置上显式地使用供应者用况的行为的结果。通过一个敞开的虚线箭头表示用况之间的包含关系，该箭头从基用况指向被包含的用况。这个箭头用关键字<<include>>标记。被包含用况基用况<<include>>2.4.3用况2.4.3用况1）扩展

If…AIF…C……IF…AIF…C……用况X用况YACIF…(A)IF…(C)……IF…(A)IF…(C)……用况X用况Y<<extend>>

<<extend>>

2.4.3用况

从基用况到扩展用况的扩展关系表明：按基用况中指定的扩展条件，把扩展用况的行为插入到由基用况中的扩展点定义的位置。

通过敞开的虚线箭头表示用况之间的扩展关系，该箭头从提供扩展的用况指向基用况。这个箭头用关键字<<extend>>标记。可以在这个关键字附近表示这个关系的条件。基用况扩展用况<<extend>>基用况是可单独存在的，但是在一定的条件下，它的行为可以被另一个用况的行为扩展。在扩展用况中可定义一组行为增量，在其中定义的行为离开基用况单独是没意义的。一个扩展用况可以扩展多个用况，一个用况也可以被多个用况扩展，甚至一个扩展用况自身也可以被其他扩展用况来扩展。2.4.3用况

一个扩展点是基用况中的一个位置，在这样的位置上，如果扩展条件为真，就在其中插入扩展用况中描述的全部动作序列或其中的一部分，并予以执行。执行完后，基用况继续执行扩展点下面的行为。如果扩展条件为假，扩展不会发生。

可以把扩展点列在用况中的一个题头为“扩展点”的分栏中。以一种适当的方式给出扩展点的位置描述，通常采用普通的文本。

基用况扩展用况2.4.3用况3）泛化用况之间的泛化关系就像类之间的泛化关系一样。子用况继承父用况的行为和含义；子用况还可以增加或覆盖父用况的行为；子用况可以出现在父用况出现的任何位置（父和子均有具体的实例）。用一个指向父用况的带有封闭的空心箭头的实线来表示用况之间的泛化关系。

BA捕获用况1）利用参与者捕获用况

对所有的参与者（把自己作为参与者），提问下列问题：■

每个参与者的主要任务是什么？——粗粒度■

它们参加了什么在本质上是不同的过程？能完成特定功能的每一项活动明确地是一个用况。这些参与者参与的活动，通常会导致其它用况。

2.4.3用况2）从系统功能角度捕获用况（1）以穷举的方式检查用户对系统的功能需求是否能在各个用况中体现出来。（2）以穷举的方式考虑每一个参与者与系统的交互情况，看看每个参与者要求系统提供什么功能，以及参与者的每一项输入信息将要求系统作出什么反映，进行什么处理。（3）考虑对例外情况的处理。针对用况描述的基本流，要详尽地考虑各种其他的情况

（4）

一个用况描述一项功能，这项功能不能过大。例如，把一个企业信息管理系统粗略地分为生产管理、供销管理、财务管理和人事管理等几大方面的功能，就显得粒度太大了，应该再进行细化。（5）一个用况应该是一个完整的任务，通常应该在一个相对短的时间段内完成。如果一个用况的各部分被分配在不同的时间段，尤其被不同的参与者执行，最好还是将各部分作为单独的用况对待。2.4.3用况场景用况抽象3）、使用场景技术

如果不能顺利地确定一个用况的描述，可“角色扮演”技术。2.4.3用况描述用况用况文档模板用况名描述：对该用况的一句或两句的描述。参与者：该用况的参与者。包含：该用况所包含的用况，以及包含它的用况。扩展：该用况可以扩展的用况，以及扩展它的用况。泛化：该用况的子用况和父用况。前置条件：启动该用况所必须具备的条件。细节：该用况的细节。（基本流与可选流）后置条件：在该用况结束时确保成立的条件。例外：在该用况的执行的过程中可能引起的例外*。限制：在应用中可能出现的任何限制*。注释：对该用况是重要的任何附加信息。2.4.3用况2.4.4用况图用况图是一幅由一组参与者、一组用况以及这些元素之间的关系组成的图。处理取款单业务员输入处理取款命令Include检查口令收集客户的取款单上的信息；加急（扩展点）{如果客户选择了加急}extend处理加急取款单……检查口令基本流：系统提示客户输入密码。客户按键输入密码，并按“输入”按钮确认。系统校验这个密码，如果有效，系统承认这次登录。可选流：客户可以在任何时间按“取消”按钮取消输入，然后该用况重新开始。可选流：客户可以在确认之前的任何时刻清除密码，并重新输入密码。可选流：如果客户输入了一个无效的密码，用况重新开始。如果连续3次无效，系统将禁止用户再次输入口令。2.5需求管理（1）需求标识和分类 若功能需求的数目较大且以后往往要发生变化，需要为每个功能性需求指定一个唯一的标识，为以后的引用需求、变更需求、跟踪需求和复用需求提供便利。 最简单的方式是为每个需求赋予一个唯一的序列号。可以为序列号规定一个结构，如用序列号的前2项描述需求的类型。 也可以按功能需求的抽象层次来进行数字编号

2.5需求管理若需求量较大，则应该进行分类组织，以便编写文档和使用。采用数字编号的方式为需求指定标识时，也可能涉及对需求分类的问题。常见的分类方式有：现场记录下来的用户工作场景；从场景抽象出来的用况；业务规则；功能性需求；软件质量的属性，如安全、可靠和易用等；外部接口需求，如用户界面、硬件接口与其它软件的接口等；对设计与实现等约束；业务数据项的定义，如数据项的数据格式、数据类型、缺省值等；等等。2.5需求管理（2）变更管理需求变化是不可避免的。在软件利益相关者对软件需求达到共识后，需要定义需求基线。需求基线是经过正式评审与同意、用作下一步开发的基础的软件需求。后续的需求变更必须遵循正式的变更控制过程。按照上述要求，进行需求管理要定义控制需求变更的过程，用以管理所有提议的变更。2.5需求管理（3）需求跟踪即使进行简单的需求变更都会影响软件的其它地方。进行需求追踪的一种常见做法是建立需求跟踪矩阵。通常用矩阵的列给出需求项，行给出与该需求项相关的其它需求项、实现元素或测试用例等。可根据需要定义需求矩阵中的需求关系，如依赖关系、从属关系、精化关系和实现关系等。

2.5需求管理第2部分结构化软件开发方法第3章结构化分析建模3.1软件需求分析阶段的任务可以把软件需求分析阶段的工作分为4个步骤，即获取需求、分析需求、定义需求和验证需求，如图所示。

软件需求分析阶段的工作步骤3.1软件需求分析阶段的任务需求获取通过启发、引导从客户（或用户）那里得到的原始需求是他们的业务要求（needs），简称为N。这是分析之前获取的需求，其中可能存在一些实际问题，这些问题只有通过分析才能得到解决，直接把获取的需求作为软件设计阶段的依据将会导致严重的后果。

3.1软件需求分析阶段的任务需求分析

认真研究获取的需求，必须考虑以下几方面：

(1)完整性：每项获取的需求都应给出清楚的描述，使得软件开发工作能够取得设计和实现该功能所需要的全部必要信息。

(2)正确性：获取的每项需求必须是准确无误的，并且需求描述无歧义性。

(3)合理性：各项需求之间、软件需求与系统需求之间应是协调一致的，不应存在矛盾和冲突。

3.1软件需求分析阶段的任务需求分析

(4)可行性：包括技术可行性、经济可行性、社会可行性。

(5)充分性：获取的需求是否全面、周到。

3.1软件需求分析阶段的任务需求分析由于分析的过程会对获取的需求做部分调整，也即从获取的需求N中去掉了一些a，又补充了一些c，从而得到的是分析的需求R1（b+c）。

3.1软件需求分析阶段的任务需求定义将已经过分析的需求清晰、全面、系统、准确地描述成为正式的文档，这一步定义需求的工作就是编写需求规格说明。

3.1软件需求分析阶段的任务需求验证为了确保已定义的需求（需求规格说明）准确无误，并能为客户（或用户）理解和接受，需要对其进行严格的评审。

3.2结构化分析方法简介结构化分析方法传统的分析建模方法称为结构化分析（structuredanalysis，SA）方法。最有代表性的是一种面向数据流进行需求分析的方法，最初于20世纪70年代由D.Ross提出，后来又经过扩充，形成了今天的结构化分析方法的框架。

3.2结构化分析方法简介结构化分析模型结构化分析方法是一种建模技术，它建立的分析模型如图所示。3.3功能建模概念功能建模的思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。功能模型用数据流图来描述。3.3功能建模数据流图的基本图形符号3.3功能建模

多个数据流之间的关系

3.3功能建模环境图环境图（contextdiagram）也称为顶层数据流图（或0层数据流图），它仅包括一个数据处理过程，也就是要开发的目标系统。环境图的作用是确定系统在其环境中的位置，通过确定系统的输入和输出与外部实体的关系确定其边界。3.3功能建模典型的环境图招生系统需求描述学校首先公布招生条件，考生根据自己的条件报名，之后系统进行资格审查，并给出资格审查信息；对于资格审查合格的考生可以参加答卷，系统根据学校提供的试题及答案进行自动判卷，并给出分数及答题信息，供考生查询；最后系统根据学校的录取分数线进行录取，并将录取信息发送给考生。3.3功能建模招生系统的环境图3.3功能建模数据流图的分层对于稍微复杂一些的实际问题，在数据流图上常常出现十几个甚至几十个加工，这样的数据流图看起来不直观，不易理解，分层的数据流图能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。

3.3功能建模招生系统的分层数据流图

3.3功能建模数据流图的分层示意图

3.3功能建模实例研究银行储蓄系统的业务流程：储户填写的存款单或取款单由业务员键入系统；如果是存款则系统记录存款人姓名、住址（或电话号码）、身份证号码、存款类型、存款日期、到期日期、利率、密码（可选）等信息，并印出存单给储户；如果是取款而且开户时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并印出利息清单给储户。要求画出分层的数据流图，并细化到2层数据流图。3.3功能建模(1)识别外部实体及输入输出数据流。外部实体：储户、业务员。输入数据：如果需要储户输入密码，储户才直接与系统进行交互。储户填写的存款或取款信息通过业务员键入系统，可以将存款及取款信息抽象为事务。输出数据：存款单，利息清单。

3.3功能建模(2)画出环境图（顶层数据流图）

3.3功能建模(3)画出一层数据流图

3.3功能建模(4)画出二层数据流图对一层图中的“处理存款”及“处理取款”进行进一步分解，得到二层数据流图，即处理存款的数据流图和处理取款的数据流图。

处理存款的数据流图3.3功能建模(4)画出二层数据流图处理取款的数据流图3.4数据建模在结构化分析方法中，使用实体—关系建模技术来建立数据模型。这种技术是在较高的抽象层次（概念层）上对数据库结构进行建模的流行技术。实体—关系模型表示为可视化的实体—关系图（entity-relationshipdiagram，ERD），也称为ER图。ER图中仅包含3种相互关联的元素：数据对象（实体）、描述数据对象的属性及数据对象彼此间相互连接的关系。

3.4数据建模数据对象数据对象是目标系统所需要的复合信息的表示，所谓复合信息是具有若干不同属性的信息。在ER图中用矩形表示数据对象。在实际问题中，数据对象（实体）可以是外部实体、事物、角色、行为或事件、组织单位、地点或结构等。

3.4数据建模属性属性定义数据对象的特征，如数据对象学生的学号、姓名、性别、专业等，课程的课程编号、课程名称、学分等。在ER图中用椭圆或圆角矩形表示属性，并用无向边将属性与相关的数据对象连接在一起。

3.4数据建模关系不同数据对象的实例之间是有关联关系的，在ER图上用无向边表示。在无向边的两端应标识出关联实例的数量，也称为关联的重数。从关联重数的角度可以将关联分为３种。(1)一对一（1:1）关联(2)一对多（1:m）关联(3)多对多（m:n）关联实例关联还有“必须”和“可选”之分。

3.4数据建模关联数量的表示在ER图中用圆圈表示所关联的实例是可选的，隐含表示“0”，没有出现圆圈就意味着是必须的。出现在连线上的短竖线可以看成是“1”。

3.4数据建模关联关系举例3.4数据建模关系的属性关系本身也可能有属性，这在多对多的关系中尤其常见，如学生和课程之间的关系可起名为“选课”，其属性应该有学期、成绩等。关系属性的表示：在表示关系的无向边上再加一个菱形框，并在菱形框中标明关系的名字，关系的属性同样用椭圆形或圆角矩形表示，并用无向边将关系与其属性连接起来。

3.4数据建模关系的属性3.4数据建模银行储蓄系统的ER图3.5行为建模状态转换图（简称状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图中使用的主要符号如图所示。3.5行为建模状态状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式，状态规定了系统对事件的响应方式。状态可能有：初态（初始状态）、终态（最终状态）和中间态。在一张状态图中只能有一个初态，而终态则可以有多个，也可以没有。

3.5行为建模状态的表示：初态用实心圆表示，终态用牛眼图形表示，中间态用圆角矩形表示。3.5行为建模状态转换状态图中两个状态之间带箭头的连线称为状态转换。状态的变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式。如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。3.5行为建模状态转换下图为计算机应用软件的启动过程，在这个过程中没有外部事件触发，每个状态下的活动完成时，状态发生转换。

3.5行为建模事件事件是在某个特定时刻发生的事情，它是对引起系统做动作或从一个状态转换到另一个状态的外部事件的抽象。事件表达式的语法如下：

事件说明（守卫条件）/动作表达式(1)事件说明的语法如下：

事件名（参数表）(2)守卫条件是一个布尔表达式。如果同时使用守卫条件和事件说明，则当且仅当事件发生且布尔表达式成立时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真，状态转换就发生。(3)动作表达式是一个过程表达式，当状态转换开始时执行该表达式。3.5行为建模存款过程的状态图(考虑新开户)3.5行为建模取款过程的状态图3.6数据字典数据字典以词条方式定义在数据模型、功能模型和行为模型中出现的数据对象及控制信息的特性，给出它们的准确定义，包括数据流、加工、数据文件、数据元素，以及数据源点、数据汇点等。

数据字典成为把3种分析模型黏合在一起的“黏合剂”，是分析模型的“核心”。3.6数据字典词条描述对于在数据流图中每一个被命名的图形元素均加以定义；其内容包括图形元素的名字，图形元素的别名或编号，图形元素类别（如加工、数据流、数据文件、数据元素、数据源点或数据汇点等）、描述、定义、位置等。

3.6数据字典数据流词条数据流是数据结构在系统内传播的路径，数据流词条应包括以下几项内容。①数据流名：要求与数据流图中该图形元素的名字一致。②简述：简要介绍它产生的原因和结果。③组成：数据流的数据结构。④来源：数据流来自哪个加工或作为哪个数据源的外部实体。⑤去向：数据流流向哪个加工或作为哪个数据汇点的外部实体。⑥流通量：单位时间数据的流通量。⑦峰值：流通量的极限值。3.6数据字典数据元素词条数据流图中的每个数据结构都是由数据元素构成的，数据元素是数据处理中最小的、不可再分的单位，它直接反映事物的某一特征。①类型：数据元素分为数字型与文字型。数字型又分为离散值和连续值，文字的类型用编码类型和长度区分。②取值范围：离散值的取值或是枚举的（如3，17，21），或是介于上下界的一组数（如2..100）；连续值一般是有取值范围的实数集（如0.0..100.0）。对于文字型，文字的取值需加以定义。③相关的数据元素及数据结构。3.6数据字典数据存储文件词条数据存储文件是数据保存的地方。一个数据存储文件词条应有以下几项内容。①文件名：要求与数据流图中该图形元素的名字一致。②简述：简要介绍存放的是什么数据。③组成：文件的数据结构。④输入：从哪些加工获取数据。⑤输出：由哪些加工使用数据。⑥存取方式：分为顺序、直接、关键码等不同存取方式。⑦存取频率：单位时间的存取次数。3.6数据字典加工词条加工可以使用诸如判定表、判定树、结构化语言等形式表达，主要描述如下。①加工名：要求与数据流图中该图形元素的名字一致。②编号：用以反映该加工的层次和父子关系。③简述：加工逻辑及功能简述。④输入：加工的输入数据流。⑤输出：加工的输出数据流。⑥加工逻辑：简述加工程序和加工顺序。3.6数据字典数据源点及数据汇点词条对于一个数据处理系统来说，数据源点和数据汇点应比较少。

①名称：要求与数据流图中该外部实体的名字一致。②简述：简要描述是什么外部实体。③有关数据流：该实体与系统交互时涉及哪些数据流。④数目：该实体与系统交互的次数。3.6数据字典数据结构描述在数据字典的编制中，分析员最常用的描述数据结构的方式有定义式、Warnier图等。定义式。在数据流图中，数据流和数据文件都具有一定的数据结构，因此，必须以一种清晰、准确、无二义性的方式来描述数据结构。Warnier图。Warnier图是表示数据结构的另一种图形工具，它用树形结构来描绘数据结构。3.6数据字典定义式中的符号3.6数据字典定义式举例：存折3.6数据字典存折的定义格式存折＝户名＋所号＋账号＋开户日＋性质＋（印密）＋

1{存取行}50所号＝“001”..“999”户名＝2{字母}24账号＝“00000000001”..“99999999999”开户日＝年＋月＋日性质＝“1”..“6”

印密＝（“0”|“000001”..“999999”）

存取行＝日期＋（摘要）＋支出＋存入＋余额＋操作＋复核日期＝年＋月＋日年＝“0001”..“9999”月＝“01”..“12”日＝“01”..“31”3.6数据字典存折的定义格式摘要＝1{字母}4支出＝金额存入＝金额余额＝金额金额＝“0000000.01”..“9999999.99”操作＝“00001”..“99999”复核＝“00001”..“99999”字母＝[“a”..“z”|“A”..“Z”]3.6数据字典Warnier图举例：存折3.7加工规格说明在对数据流图的分解中，位于层次树最低层的加工也称为基本加工或原子加工，对于每一个基本加工都需要进一步说明，这称为加工规格说明。在编写基本加工的规格说明时，主要目的是要表达“做什么”，而不是“怎样做”。3.7加工规格说明加工规格说明应满足如下的要求：(1)对数据流图的每一个基本加工，必须有一个加工规格说明。(2)加工规格说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则。(3)加工规格说明必须描述实现加工的策略而不是实现加工的细节。(4)加工规格说明中包含的信息应是充足的，完备的，有用的，没有重复的多余信息。

3.7加工规格说明决策表决策表由4个部分组成：左上部分是条件茬，在此区域列出了各种可能的单个条件；左下部分是动作茬，在此区域列出了可能采取的单个动作；右上部分是条件项，在此区域列出了针对各种条件的每一组条件取值的组合；右下部分是动作项，这些动作项与条件项紧密相关，它指出了在条件项的各组取值的组合情况下应采取的动作。3.7加工规格说明决策表举例商店业务处理系统中“检查订货单”的决策表。3.7加工规格说明决策表的改进

如果表中有两条或更多的处理规则具有相同的动作，并且其条件项之间存在着某种关系，就可设法将它们合并。

3.7加工规格说明建立决策表的步骤(1)列出与一个具体过程（或模块）有关的所有处理。(2)列出过程执行期间的所有条件（或所有判断）。(3)将特定条件取值组合与特定的处理相匹配，消去不可能发生的条件取值组合。(4)将右部每一纵列规定为一个处理规则，即对于某一条件取值组合将有什么动作。3.7加工规格说明决策树决策树（decisiontree）也是用来表达加工逻辑的一种工具，有时侯它比决策表更直观。检查订货单的决策树

3.8需求规格说明需求分析阶段的重要任务之一是根据分析的结果编写需求规格说明，经过严格评审并得到用户确认之后，作为这个阶段的最终成果。按照国家标准GB/T8567—2006《计算机软件文档编制规范》，涉及需求规格说明的文档有“软件需求规格说明（SRS）”、“数据需求说明（DRD）”等。小结传统软件工程方法学使用结构化分析技术完成用户需求的分析工作。需求分析是发现、求精、建模、规格说明和复审的过程。为了更好地理解问题，人们常常采用建立模型的方法，结构化分析实质上就是一种建模活动，在需求分析阶段通常建立数据模型、功能模型和行为模型。That'sAll!第2部分结构化软件开发方法第4章总体设计4.1软件设计的概念及目标软件设计的概念

设计是一项核心的工程活动。在20世纪90年代早期，Lotus1-2-3的发明人MitchKapor在Dr.Dobbs杂志上发表了“软件设计宣言”，其中指出：“什么是设计？设计是你站在两个世界——技术世界和人类的目标世界——而你尝试将这两个世界结合在一起……”。4.1软件设计的概念及目标软件设计的概念

罗马建筑批评家Vitruvius提出了这样一个观念：“设计良好的建筑应该展示出坚固、适用和令人赏心悦目”。4.1软件设计的概念及目标软件设计的目标软件设计的目标涉及性能、可靠性、成本、维护等多个方面的目标。一般来说，可以从需求规格说明书中选择重要的质量属性，作为设计目标，如性能目标、可靠性目标等，而成本和维护方面往往需要从客户和供应商那里得到。4.1软件设计的概念及目标性能准则

性能准则包括对系统速度和空间的需求。4.1软件设计的概念及目标可靠性准则可靠性准则决定了对减少系统崩溃及随后所造成危害所做的努力程度。4.1软件设计的概念及目标成本准则成本准则包括开发、配置和管理系统的成本。成本准则不仅包括设计上的考虑，还包括管理上的考虑。4.1软件设计的概念及目标维护准则护准则确定在完成开发后再改变系统的困难程度。4.1软件设计的概念及目标最终用户准则最终用户准则包括从用户视点出发所需的属性，但并没有覆盖性能准则和可靠性准则。

4.1软件设计的概念及目标设计目标的某些权衡空间与速度交付时间与功能交付时间与质量交付时间与人员配置

4.2软件设计的任务软件设计的主要任务是要解决如何做的问题，要在需求分析的基础上，建立各种设计模型，并通过对设计模型的分析和评估，来确定这些模型是否能够满足需求。软件设计是将用户需求准确地转化成为最终的软件产品的唯一途径，在需求到构造之间起到了桥梁作用。在软件设计阶段，往往存在多种设计方案，通常需要在多种设计方案之中进行决策和折中，并使用选定的方案进行后续的开发活动。4.2软件设计的任务软件设计的阶段与任务从工程管理的角度，可以将软件设计分为概要设计阶段和详细设计阶段。从技术的角度，传统的结构化方法将软件设计划分为体系结构设计、数据设计、接口设计和过程设计4部分；面向对象方法则将软件设计划分为体系结构设计、类设计/数据设计、接口设计和构件级设计4部分。4.2软件设计的任务软件设计的阶段与任务从管理和技术两个不同的角度对设计的认识。4.2软件设计的任务软件设计的阶段与任务体系结构设计：体系结构设计定义软件的主要结构元素及其之间的关系。类设计：类设计对分析阶段所建立的分析类模型进行细化，转化为设计类的实现及软件实现所要求的数据结构。

数据设计：传统方法主要根据需求阶段所建立的实体—关系图（ER图）来确定软件涉及的文件系统的结构及数据库的表结构。4.2软件设计的任务软件设计的阶段与任务接口设计：接口设计描述用户界面，软件和其他硬件设备、其他软件系统及使用人员的外部接口，以及各种构件之间的内部接口。构件级设计：构件级设计将软件体系结构的结构元素变换为对软件构件的过程性描述。过程设计：过程设计的主要工作是确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法。4.2软件设计的任务结构化设计与结构化分析的关系结构化分析的结果为结构化设计提供了最基本的输入信息。两者的关系如图所示。4.2软件设计的任务结构化设计方法的实施要点(1)研究、分析和审查数据流图。(2)根据数据流图决定问题的类型：变换型和事务型。针对两种不同的类型分别进行分析处理。(3)由数据流图推导出系统的初始结构图。(4)利用一些启发式原则来改进系统的初始结构图，直到得到符合要求的结构图为止。(5)根据分析模型中的实体关系图和数据字典进行数据设计，包括数据库设计或数据文件的设计。(6)在上面设计的基础上，并依据分析模型中的加工规格说明、状态转换图进行过程设计。(7)制定测试计划。4.3模块结构与数据结构模块结构及表示一般通过功能划分过程来完成软件结构设计。功能划分过程从需求分析确立的目标系统的模型出发，对整个问题进行分割，使其每一部分用一个或几个软件模块加以解决，整个问题就解决了。4.3模块结构与数据结构模块一个软件系统通常由很多模块组成，结构化程序设计中的函数和子程序都可称为模块，它是程序语句按逻辑关系建立起来的组合体。模块用矩形框表示，并用模块的名字标记它。4.3模块结构与数据结构模块的分类4.3模块结构与数据结构模块的结构模块结构最普通的形式就是树状结构和网状结构，如图所示。4.3模块结构与数据结构结构图结构图（structurechart，SC）是精确表达模块结构的图形表示工具。

(1)模块的调用关系和接口：在结构图中，两个模块之间用单向箭头连接。(2)模块间的信息传递：当一个模块调用另一个模块时，调用模块把数据或控制信息传送给被调用模块，以使被调用模块能够运行。

4.3模块结构与数据结构结构图模块间的调用关系和接口表示4.3模块结构与数据结构结构图(3)条件调用和循环调用：当模块A有条件地调用另一个模块B时，在模块A的箭头尾部标以一个菱形符号；当一个模块A反复地调用模块C和模块D时，在调用箭头尾部则标以一个弧形符号。

4.3模块结构与数据结构结构图(4)结构图的形态特征。在图中，上级模块调用下级模块，它们之间存在主从关系。相关概念：宽度、深度、扇入、扇出。4.3模块结构与数据结构数据结构及表示数据结构是数据的各个元素之间逻辑关系的一种表示。

数据结构设计应确定数据的组织、存取方式、相关程度，以及信息的不同处理方法。数据结构的组织方法和复杂程度可以灵活多样，但典型的数据结构种类是有限的，它们是构成一些更复杂结构的基本构件块。4.3模块结构与数据结构典型的数据结构4.4创建良好设计的原则分而治之和模块化

分而治之是人们解决大型复杂问题时通常采用的策略，将大型复杂的问题分解为许多容易解决的小问题，原来的问题也就容易解决了。软件的体系结构设计和模块化设计都是分而治之策略的具体表现。4.4创建良好设计的原则模块化模块化是将整体软件划分成独立命名且可独立访问的模块，不同的模块通常具有不同的功能或职责。每个模块可独立地开发、测试，最后组装成完整的软件。

4.4创建良好设计的原则模块化尽管模块分解可以简化要解决的问题，但模块分解并不是越小越好。模块大小、模块数目与成本的关系如下图。

4.4创建良好设计的原则模块独立性模块的独立性是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他的模块的接口是简单的。

一般采用两个准则度量模块独立性，即模块间的耦合和模块的内聚。耦合是模块之间的相对独立性（互相连接的紧密程度）的度量。内聚是模块功能强度（模块内部各个元素彼此结合的紧密程度）的度量。模块独立性比较强的模块应是高度内聚、松散耦合的模块。

4.4创建良好设计的原则松散耦合

耦合性是程序结构中各个模块之间相互关联的度量。它取决于各个模块之间接口的复杂程度、调用模块的方式以及哪些信息通过接口。一般模块之间可能的连接方式有7种，构成耦合性的7种类型，它们之间的关系如图所示。4.4创建良好设计的原则(1)非直接耦合。如果两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的，这就是非直接耦合。这种耦合的模块独立性最强。(2)数据耦合。如果一个模块访问另一个模块时，彼此之间是通过数据参数（不是控制参数、公共数据结构或外部变量）来交换输入、输出信息的，则称这种耦合为数据耦合。(3)标记耦合。如果一组模块通过参数表传递记录信息，就是标记耦合。

4.4创建良好设计的原则(4)控制耦合。如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合，如图所示。(5)外部耦合。一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。

4.4创建良好设计的原则(6)公共耦合。若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共耦合的复杂程度随耦合模块的个数增加而显著增加。如图所示，若只是两个模块之间有公共数据环境，则公共耦合有两种情况。4.4创建良好设计的原则(7)内容耦合。如果发生下列情形，两个模块之间就发生了内容耦合，如图所示。4.4创建良好设计的原则高度内聚

内聚程度高的模块应当只完成软件过程中的一个单一的任务。一般模块的内聚性分为7种类型，它们的关系如图所示。4.4创建良好设计的原则(1)巧合内聚。又称为偶然内聚，当模块内各部分之间没有联系，或者即使有联系，这种联系也很松散，则称这种模块为巧合内聚模块，它是内聚程度最低的模块。

4.4创建良好设计的原则(2)逻辑内聚。这种模块把几种相关的功能组合在一起，每次被调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能。4.4创建良好设计的原则(3)时间内聚。又称经典内聚。这种模块大多为多功能模块，但模块的各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行，如初始化模块和终止模块。(4)过程内聚。如果一个模块内的处理是相关的，而且必须以特定次序执行，则称这个模块为过程内聚模块。(5)通信内聚。如果一个模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据，则称之为通信内聚模块。

4.4创建良好设计的原则(6)信息内聚。这种模块完成多个功能，各个功能都在同一数据结构上操作，每一项功能有一个唯一的入口点。4.4创建良好设计的原则(7)功能内聚。一个模块中各个部分都是完成某一具体功能必不可少的组成部分，或者说该模块中所有部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的，则称该模块为功能内聚模块。

4.4创建良好设计的原则提高抽象层次在进行软件设计时，设计开始时应尽量提高软件的抽象层次，按抽象级别从高到低进行软件设计。将软件的体系结构按自顶向下方式，对各个层次的过程细节和数据细节逐层细化，直到用程序设计语言的语句能够实现为止，从而最后确立整个系统的体系结构。4.4创建良好设计的原则复用性设计复用是指同一实体不做修改或稍加修改就可以多次重复使用，将复用的思想用于软件开发，称为软件复用。在软件的设计阶段，就要考虑软件复用问题，并进行复用性设计。复用性设计有两方面的含义：一是尽量使用已有的构件；二是如果确实需要创建新的构件，则在设计时应该考虑将来的可重复使用性。4.4创建良好设计的原则灵活性设计在设计中引入灵活性的方法如下。(1)降低耦合并提高内聚（易于提高替换能力）；(2)建立抽象（创建有多态操作的接口和父类）；(3)不要将代码写死（消除代码中的常数）；(4)抛出异常（由操作的调用者处理异常）；(5)使用并创建可复用的代码。4.4创建良好设计的原则预防过期

在设计中应遵循的预防过期的规则如下：(1)避免使用早期发布的技术。(2)避免使用针对特定环境的软件库。(3)避免使用软件库中文档不全或很少使用的功能。(4)避免使用小公司或可能不提供长期支持的公司提供的可复用构件或特殊硬件。(5)使用众多厂商支持的标准语言和技术。4.4创建良好设计的原则可移植性设计

软件的可移植性指的是软件不经修改或稍加修改就可以运行于不同软硬件环境（CPU、OS和编译器）的能力，可移植性是软件的质量要素之一。良好的可移植性可以延长软件的生命周期，拓展软件的应用环境。可移植性设计的主要目标是让软件在尽可能多的平台上运行。

4.4创建良好设计的原则可移植性设计

实现可移植性的规则主要有：(1)软件设计时应该将“设备相关程序”与“设备无关程序”分开，将“功能模块”与“用户界面”分开，这样可以提高可移植性。(2)避免使用特定环境的专有功能。(3)使用不依赖特定平台的程序设计语言。(4)小心使用可能依赖某一平台的类库。(5)了解其他语言可能依赖特殊硬件结构的功能和文本文件的差异。4.4创建良好设计的原则可测试性设计

实现在进行可测试性设计时，需要坚持以下原则。(1)坚持测试驱动设计（测试先行）的方法。一般先编写验收测试代码，再编写单元测试代码，编写和实现迭代进行。(2)函数小型化。尽量做到一个函数对应一个操作，使函数小型化。(3)数据的显示与控制分离。将处理代码与图形用户界面（GUI）分离。这样，各种GUI动作就变成了模型上的简单方法调用。

4.4创建良好设计的原则防御性设计

防御性设计技术的主要思想如下：(1)被调用操作为正常执行必须满足的条件称为前置条件，在调用一个操作时要确保该操作的前置条件成立。(2)被调用操作正常执行所得到的结果必须满足的条件称为后置条件，在被调用操作返回后要确保该操作的后置条件成立。(3)被调用操作在执行时一直保持成立的条件称为不变式。(4)前置条件、后置条件和不变式都是布尔表达式，其计算结果为假，表示有错误发生。(5)可以使用断言机制，在重要构件的边界应始终保留严格的断言检测。4.5面向数据流的设计方法面向数据流的设计方法也称为过程驱动的设计方法；这种方法与软件需求分析阶段的结构化分析方法相衔接，可以很方便地将用数据流图表示的信息转换成程序结构的设计描述；这种方法还能和编码阶段的“结构化程序设计方法”相适应，成为常用的结构化设计方法。4.5面向数据流的设计方法设计过程基于数据流方法的设计过程4.5面向数据流的设计方法典型的数据流类型和系统结构典型的数据流类型有变换型数据流和事务型数据流，数据流的类型不同，得到的系统结构也不同。通常，一个系统中的所有数据流都可以认为是变换流，但是，当遇到有明显事务特性的数据流时，建议采用事务型映射方法进行设计。4.5面向数据流的设计方法变换型数据流

变换型数据处理问题的工作过程大致分为3步，即取得数据、变换数据和给出数据，如图所示。4.5面向数据流的设计方法变换型系统结构图

变换型系统的结构图由输入、中心变换和输出3部分组成。

4.5面向数据流的设计方法事务型数据流

通常接受一项事务，根据事务处理的特点和性质，选择分派一个适当的处理单元，然后给出结果。完成选择分派任务的部分称为事务处理中心，或分派部件。

4.5面向数据流的设计方法事务型系统结构图

4.5面向数据流的设计方法简化的事务型系统结构图

事务型系统的结构图可以有多种不同的形式，如有多层操作层或没有操作层。如果调度模块并不复杂，可将其归入事务中心模块。4.5面向数据流的设计方法变换型映射方法系统数据处理问题的处理流程总能表示为变换型数据流图，进一步可采用变换型映射方法建立系统的结构图。也可能遇到明显的事务数据处理问题，这时可采用事务型映射方法。4.5面向数据流的设计方法变换分析方法的步骤

(1)重画数据流图。在需求分析阶段得到的数据流图侧重于描述系统如何加工数据，而重画数据流图的出发点是描述系统中的数据是如何流动的。(2)在数据流图上区分系统的逻辑输入、逻辑输出和中心变换部分。

4.5面向数据流的设计方法变换分析方法的步骤

(3)进行一级分解，设计系统模块结构的顶层和第一层。自顶向下设计的关键是找出系统树形结构图的根或顶层模块。首先设计一个主模块，并用程序的名字为它命名，然后将它画在与中心变换相对应的位置上。第1层设计：为每个逻辑输入设计一个输入模块，它的功能是为主模块提供数据；为每个逻辑输出设计一个输出模块，它的功能是将主模块提供的数据输出；为中心变换设计一个变换模块，它的功能是将逻辑输入转换成逻辑输出。4.5面向数据流的设计方法变换分析方法的步