软件工程方法与实践课件

软件工程方法与实践第2章软件过程电子教案第2章

软件过程2.1软件过程概述2.2典型的软件过程模型2.3面向对象的软件过程模型2.4小结2.1软件过程概述 软件工程是一种层次化技术，是建立在以质量焦点为基础的，分过程、方法和工具三个研究层次的综合技术。图2.1软件工程层次图工具方法过程质量焦点2.1.1过程、方法和工具

过程层（基础层）是方法和技术结合在一起的凝聚力。软件过程定义了一个关键过程区域（阶段）的划分，确立了各阶段之间的关系，其中规定了技术方法的采用、工程产品（模型、数据、文档等）的产生、质量的保证，以及对开发进程的适当管理。

方法层提供了建造软件在技术上“如何做”。软件工程方法涵盖在一系列开发过程的任务中。方法依赖于一组基本原则得以实施。这些原则控制了每一个技术区域的建模活动和其他描述技术。

工具层对过程和方法提供了自动化支持。2.1.2软件生存周期

软件生存周期（SoftwareLifeCycle）：一个软件项目从问题提出开始，直到软件产品最终退役（废弃不用）为止。软件生存周期方法学把整个生存周期划分为多个相对独立的较小阶段，给每个阶段赋予确定而有限的任务，从而降低了整个软件工程的难度，提高了软件开发生产率；对软件生存周期的每个阶段采用科学的、规范的方法和管理，使软件开发全过程以一种有条不紊的方式进行，保证了软件质量，提高了软件的可维护性和软件开发的成功率。软件过程开发标准的要点 ①采用生存周期方法学开发软件，必须从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行。 ②划分阶段应遵循的基本原则是各阶段的任务彼此之间尽可能相对独立，同一阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂程度，简化不同阶段之间的联系，有利于软件开发过程的组织和管理。 ③每个阶段有相对独立的任务，前一个阶段任务的完成是后一个阶段任务开始的前提和基础，而后一阶段任务的完成是前一阶段提出“解”的进一步具体化和实现细节。软件过程开发标准的要点

④每一个阶段的开始和结束都有严格标准。对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。每一个阶段结束之前，都必须对这个阶段的成果进行严格的技术复审和管理审查。审查的主要对象是每个阶段都应该提交的、最新版本的、高质量的相关文档资料。 ⑤完成每个阶段的任务，应该采用适合该阶段任务特点的规范方法和系统化技术。2.1.3软件过程模型

软件过程模型（软件生存周期模型），是把软件生存周期中软件生产活动的有序流程用一个合理的框架——开发模型规范描述。 软件过程模型是一种软件过程的抽象表示法，它从一个特定的角度表现一个开发过程。 软件过程模型主要是根据软件的类型、规模，特别是软件的开发方法、开发环境等多种因素确立模型。 2.1.4软件过程各阶段任务

各种软件过程模型虽然有所不同，一般都由软件定义、软件开发和软件维护三个时期组成，每个时期又可由多个阶段（子阶段）组成。 软件定义时期的活动是弄清软件“做什么”，软件开发时期的活动是集中解决软件“怎样做”，软件维护时期的活动是聚焦于软件的“修改/完善”，它们的主要活动特征可以概括为“What-How-Change”。软件定义时期各阶段任务

软件定义时期是了解用户（或客户）提出的需求、确定项目的总目标、考察和分析项目的可行性、导出实现项目目标应该采用的策略，系统的功能，并估计该项目需要的资源和成本，制定工程进度表等。 软件定义时期可以划分成问题定义、可行性研究、需求分析和开发计划四个阶段，其中，最核心的是需求分析阶段，所以，软件定义时期也可以称为需求分析时期。问题定义和可行性研究

问题定义主要是弄清“用（客）户需要解决什么问题”，提交关于问题性质、工程规模的系统目标与范围的说明文档。

可行性研究是确定所定义的问题是不是能够实现，值不值得实现。为此必须从抽象的概念出发，对项目做一次简化的需求分析和粗略的系统概要设计，寻求一种至数种在技术、经济、运行和法律诸方面都可行的解决方案，并给出可行性论证报告。

需求分析和开发计划

需求分析（阶段）的任务是分析用户对软件系统的全部需求，确定目标系统的逻辑模型，即目标系统是“做什么”的，并通过需求规格说明文档准确地表达。 开发计划的任务是在软件项目经过可行性研究和需求分析之后，制定出主要包括成本估计、资源配置、工程进度安排的软件项目开发和管理文档。

软件开发时期各阶段任务

软件开发时期的任务是设计和实现已定义的，并经过需求分析的软件系统。 软件开发时期通常划分成软件设计、软件实现和软件测试三个阶段。

软件测试也可以分解到软件实现的各个活动中，可重新划分成编码和单元测试、集成测试、系统测试三个阶段。甚至，还可以认为软件测试不是一个独立的阶段，因为它应该和所有软件生产活动并行进行。

软件设计阶段任务

软件设计阶段是为目标系统的逻辑模型设计出一种（不惟一的）软件实现模型，确定软件的总体结构、数据结构、算法细节和用户界面，并给出软件设计的详尽的软件设计说明文档。 软件设计阶段分成总体设计和详细设计两个子阶段。

总体设计是从需求规格说明文档导出软件结构图。

详细设计为软件结构图中的各个模块的数据结构、算法和模块接口等进行细节设计，并给出过程性描述。软件实现阶段任务

软件实现阶段的任务是把软件的设计用一种程序设计语言实现。实现阶段一般分成编码和系统集成两个步骤（或子阶段）进行。

编码是根据目标系统的性质和实际开发环境，选取一种适当的程序设计语言，把详细设计的模块过程性描述“翻译”成所选定程序语言的源程序。 对于多模块的系统集成是把所有的程序模块，按照它的软件结构组装（集成）成一个完整的软件系统。软件测试阶段任务

软件测试阶段完成产品交付前的“找错”和“改错”两大任务，其测试过程必须通过测试报告文档反映。 按照测试活动的目标，软件测试可细分为单元（模块）测试、综合（集成）测试、确认测试和系统（验收）测试等多个测试层次。

软件测试是对开发活动的技术复审，也可以分解到软件实现阶段的各个活动环节。软件维护时期（阶段）任务

软件维护时期（阶段）任务是在整个软件运行时期内，当发现错误时加以改正，以确保运行正常；当环境改变时修改软件，以适应新的环境；当用户有新要求时及时改进软件，以满足需求等一系列维护活动。 每一项维护活动一般都经过提出（或报告）维护问题、分析维护要求、提出维护方案、审批维护方案、确定维护计划、修改软件设计、修改程序、测试/验收、维护报告等一系列环节（维护活动实质是一次压缩和简化了的软件定义和开发过程）。2.2典型的软件过程模型 软件工程的前20年，软件过程模型的特征是“线性思维”，即把软件的开发活动分解成一系列线性的描述、开发、有效性验证和软件进化等基本过程活动，并且用单独的过程阶段来表现这些活动。 随着软件规模的不断增长，大型而复杂的软件采用渐增式或迭代式的开发理念，即把软件的描述、开发、有效性验证等主要开发活动交替进行，让开发的软件在迭代过程中逐步完成和完善。2.2.1瀑布模型

瀑布模型（WaterfallModel）也称线性顺序模型。 瀑布模型把开发过程分成固定的、相对独立的各个阶段，每个阶段都有确定的、有限的任务，而且在各个阶段采用一些规范的开发方法和管理手段，力求保证软件质量和提高软件生产率。 瀑布模型各个阶段的工作顺序展开，恰如“奔流不息、拾级而下”的瀑布，故而得名。瀑布模型

问题定义软件维护（运行时期）图2.2软件过程的瀑布模型退役需求分析软件设计软件实现软件测试瀑布模型的特点

1．阶段的“里程碑”标志 2．阶段间的顺序性和依赖性 3．复审/验证环节 4．瀑布模型的适用于预先确定型系统2.2.2快速原型模型

快速原型模型（RapidPrototypeModel，简称原型模型）打破了瀑布模型的“线性”特征，是一种系统原型化的子集扩展式开发模式。 原型模型方法采用合理的抽象，快速建立一个旨在展示目标系统主要功能的软件“样品”————原型系统，取代形式的、僵硬的（不易更改的）的规格说明，用户通过实际试用原型系统而提供真实的反馈意见。抛弃式原型模型需求分析软件维护（运行时期）图2.3软件过程的抛弃式原型模型退役原型开发原型评价软件设计软件实现用户反馈抛弃式原型模型的特点

抛弃式原型模型建立原型的目的是，评价目标系统的某一个或某一些特性，以便更准确地确定需求，或者更严格地验证设计方案。使用完之后就把该原型系统抛弃掉，然后再重新构造正式的目标系统。 抛弃式原型模型本质上仍属于瀑布模型，建立原型系统只不过是“需求分析”和“有效性验证”的一种辅助手段，需求分析阶段结束时原型系统的生存周期也就终止。演化式原型模型是交付目标系统建立/完善原型系统充分吗？否图2.4软件过程的演化式原型模型使用原型系统需求抽象描述演化式原型模型的特点

演化式原型模型是一种迭代式的动态开发方法。 ①演化式的原型开发，必须从对用户需求把握准确的部分做起，优先处理这部分工作，而对用户需求把握程度较差的部分和模糊的需求靠后安排，可以在用户明确要求之后再处理。 ②原型系统的演化过程，可以有效提高系统可靠性、健壮性和可维护性。 ③有效地快速进行原型的建立和迭代，提高开发效益。 ④原型的开发提高系统与用户的友善性，并能提早进行实际系统的应用培训。2.2.3增量模型

增量模型（IncrementalModel）把软件描述、设计、实现活动分解成一系列相互有联系的增量构件的迭代开发，是瀑布模型顺序特征和快速原型模型迭代特征相结合的一种软件构件化的模型。 增量式的开发过程，首先根据客户需要提供的服务的优先次序，确定一系列交付增量，每个增量提供系统功能的一个子集。随着开发过程的进展，每次迭代产生一个可发布的（可执行的）软件增量构件。 增量模型

图2.5软件过程的增量模型增量设计规格说明实现和测试与系统集成开发增量i：目标系统增量需求需求分析设计系统结构开发增量系统验证系统未完成2.2.4螺旋模型

螺旋模型（SpiralModel）是增加了风险分析和规避措施的“原型+瀑布”的迭代式开发模型，由于一系列活动和活动间的回溯过程用螺旋线描述，故而得名。 螺旋模型是一种迭代模型，每迭代一次，螺旋线就前进一周。当项目开发过程沿螺旋线按顺时针方向前进时，每一个螺旋周期都包括风险分析（开发的中、后期实际是设计或实现的风格分析）。螺旋模型需求分析确定目标,选择方案,设定约束条件计划下一阶段风险（风格）分析，风险解决开发、验证本级产品开发原型,原型评价定义仿真或模型、基准测试图2.6软件过程的螺旋模型规格说明设计测试实现2.3.1面向对象的基本概念

为了提高软件系统的稳定性、可维护性和复用性，人们在实践中逐渐创造出软件工程的一种新途径——面向对象方法学。 从20世纪80年代末开始，面向对象的软件开发得到快速发展，特别是90年代中期出现的统一建模语言（UML），把各种面向对象分析方法和设计方法综合成一个统一标准，使面向对象方法学成为一种主流型的软件工程方法。 对象的基本概念

⑴

对象（Object） 对象是现实世界中任何有意义的、与所要解决的问题有关系的个体或事物的抽象表示，是它的属性（静态的）和相关操作（动态的）的统一封装体。属性表示对象的性质，属性值规定了对象所有可能的状态。对象的操作（或称做行为）是该对象可以实现的外部服务（响应外部发来的消息，提供服务）。 对象的定义，一般采用以下格式描述：对象∷=<ID，MS，DS，MI>对象的基本概念

⑵类（Class） 人类习惯于把现实世界中有相似特征的事物归为一类，所以分类是认识客观世界的基本方法。 类是对具有相同属性和相同操作行为的一组相似对象的抽象描述，通常这种描述也包括对怎样创建该类的新对象的说明。所以，类用于表示某些对象的属性和行为的共同特征。对象的基本概念

⑶实例（Instance） 类是现实世界中并不真正存在的一组相似对象的抽象。实例是由某个特定的类所描述的一个具体的对象，也就是说，对象是类的一个实例。 实际上，类是建立对象时使用的“样板”，按照这个样板建立的是一个个具体的对象。使用“对象”，既可以指一个具体的对象，也可以泛指一般的对象；而使用“实例”，必然是指一个具体的对象。对象的基本概念

⑷继承（Inheritance） 继承在面向对象方法中表示类之间的内在联系，以及对属性和行为的共享。 类之间可以存在继承机制，即类共享基类中定义的数据和方法。类的继承具有传递、单继承和多重继承性质。 在面向对象方法中，大量存在的“部分—整体”关系，表示为类之间的聚集关系。在聚集关系下，类组成了一个有“部分—整体”层次结构的系统。“部分”类的对象是“整体”类对象的一个组成部分。对象的基本概念

⑸消息（Message） 消息是某个对象执行它的类所定义的某个操作的规格说明。消息传递是对象与其外部世界相互关联的惟一途径。 对象可以向其他对象发送消息以请求服务，也可以响应其他对象传递的消息，完成自身某些操作，从而服务于其他对象。面向对象方法的特点

面向对象方法是综合运用对象、类、继承、消息四个核心概念进行软件开发的方法。面向对象=对象+分类+继承+消息通信 ①与人类习惯思维方法的一致性 ②稳定性好 ③可复用性好 ④可维护性好

面向对象软件的开发特点 ◆面向对象方法并不是基于某个开发模式的技术，它适用于任何开发模式。 ◆面向对象方法的开发活动在软件生存周期的分析、设计和实现阶段之间反复迭代，重点是放在的分析阶段。这是因为，面向对象方法在开发早期就定义了一系列面向问题的对象，即建立了一个对象模型。整个开发过程统一使用了这些对象，并不断地充实和扩充对象模型。不仅如此，所有其他概念，如功能、关系、事件等，也都是围绕对象模型组成的。面向对象软件的开发特点 ◆为了保证从分析阶段得到的对象信息，在以后的开发阶段被使用，并被不断地充实和扩充，面向对象开发过程的各个阶段使用统一的概念和描述符号。那么，各个阶段的划分自然就不重要、不明显了。因此，开发阶段界限模糊，或者说开发过程是“无缝”连接的。这有利于实现开发过程的逐步求精、开发活动的多次反复迭代。

2.3.2软件开发统一过程

软件开发统一过程（RUP，RationalUnifiedProcess）是基于面向对象统一建模语言UML的一种面向对象的软件过程模型。 RUP遵循了逐步求精的、迭代的开发策略。RUP是以使用实例（用例）为驱动，以系统架构为中心的一个迭代式的增量过程。 RUP分成初始、细化、构造和移交四个阶段，每个阶段又分成若干次迭代，每次迭代都经过一个核心工作流程。RUP初始阶段的主要工作

初始阶段确定所设立的项目是否可行。 ①对需求有一个大概的了解，确定系统中的大多数角色和用例（简要的）。 ②划分主要子系统，给出系统的体系结构概貌。 ③分析项目执行的风险。 ④考虑时间、经费、技术、项目规模和效益等因素。 ⑤制定出开发计划。RUP细化阶段的主要工作

细化阶段识别出剩余的大多数用例。对当前迭代的每个用例进行细化，分析用例的处理流程、状态细节，以及可能发生的状态改变。

①分析项目是否存在需求、技术、技能、政策等风险。 ②进行高层分析和设计，并做出结构性决策。建立简要体系结构，包括用例列表、领域概念模型和技术平台等。 ③为构造阶段制定计划。

RUP构造和移交阶段的主要工作

构造阶段识别出最后剩余的用例。每一次迭代开发都对用例进行分析、设计、编码、测试和集成过程，所得到产品满足项目需求的一个子集。 在代码完成后，要保证其符合标准和设计规则，并要进行质量检查。对于新出现的变化，要通过逆向工具把代码转换为模型，对模型进行修改，再重新产生代码，以保证软件与模型同步。

移交阶段完成最后的软件产品和产品验收测试，并编制用户文档，进行用户培训等工作。2.3.3构件集成模型

构件集成模型（ComponentIntegrationModel）是基于软件复用理念，利用预先封装好的软件构件构造应用软件系统的面向对象过程模型。 构件集成模型主要依赖于可存取的可复用构件，以及能集成构件的框架平台。构件应在某个领域中具有一定的通用性，可以在不同的软件系统中被复用。 构件集成模型融合螺旋模型很多特征，是支持软件开发的迭代方法。这种面向复用的过程模型减少了需要开发的软件数量，加快了软件交付，降低了开发成本和开发风险。构件集成模型存入构件库图2.7面向对象软件过程的构件集成模型侯选构件规格说明开发构件提取构件下一次迭代构件库查找构件构件集成验证2.4小结 ◆本章介绍软件生存周期、软件（开发）过程、软件过程模型等基本概念，概述软件过程从问题定义到退役的阶段划分和各个阶段的任务，着重讨论传统的顺序型软件过程模型，演化式软件过程模型和面向对象软件过程模型的特点。 ◆软件工程是建立在以质量焦点为基础，分过程、方法和工具三个层次的一门层次化技术。软件工程的基础层是软件（开发）过程。软件过程是软件（产品）生产活动的一个框架，可以分解成一系列有序的开发阶段。2.4小结 ◆软件过程模型集中体现了软件工程的方法和技术等多方面因素，其研究和应用是软件工程学的核心内容。 ◆传统的顺序性软件过程模型和演化性软件过程模型主要采用了系列化的结构化开发技术。软件过程呈“线性”特征，开发活动比较有序、清晰和规范。但是，开发出的软件产品的稳定性、可复用性和可维护性都比较差。 面向对象软件过程模型的特点是开发阶段界限模糊、 开发过程逐步求精、开发活动反复迭代。软件工程方法与实践第3章软件需求分析电子教案第3章

软件需求分析3.1需求分析概述3.2非形式化需求分析

3.3结构化需求分析3.4需求分析的描述3.5小结3.1需求分析概述

软件需求分析是在计算机系统的软件功能分配和软件设计之间起着重要桥梁作用的一项软件工程活动。 需求分析（工程）是发现、求精、建模和规约目标系统的过程，即指出软件目标产品必须“做什么”，描述软件系统提供的服务和所受到的约束，是一个对服务和约束的发现、分析、建立文档和检验的过程。 3.1.1需求分析的任务

需求分析的任务是包括建立并在软件项目计划中细化的软件范围、创建所需数据信息和控制流、操作行为的模型，以及分析可选择的解决方案，并将它们分配到各软件元素中去。 软件系统的需求分析可分为功能需求、非功能需求、领域需求和系统数据要求四个方面进行。3.1.2需求分析过程

需求分析过程是一个包括创建和维持系统需求文档所必需的一切活动的过程。系统模型可行性报告图3.1需求分析过程及相应文档可行性研究需求导出和分析需求描述文档编写需求有效性验证需求规格说明文档软件原型可行性研究

①研究系统是否符合机构的总体目标； ②研究系统能否在现有技术条件、预算和时间限制内完成； ③研究系统能否把已存在的其他系统集成。 可行性研究任务是信息评估、信息汇总和可行性报告。信息评估是找出和分析相关的信息；信息汇总是建立系统的逻辑模型，并从技术可行性、经济可行性、操作可行性和时间可行性等方面探索解决方案；可行性研究报告给出是否要开发系统的意见和建议。需求导出和分析

需求导出和分析是软件开发人员和客户/用户一起调查系统应用领域的活动，以加深对需求的理解。从一个活动到另一个活动会有持续的反馈，是一个重复的过程。图3.2需求导出和分析过程模型需求描述需求文档领域了解需求检查需求收集需求分类优先排序冲突解决过程入口需求描述和验证

需求描述是对系统开发需求的正式表述，以需求规格说明文档（或称为软件需求说明书）的形式给出。

需求有效性验证是对需求规格说明文档执行有效性、一致性、完备性、现实性和可检验性等类型的检查。 需求有效性验证主要采用需求评审、原型建立、测试用例等技术。3.1.3需求分析的原型技术 采用原型法快速建立原型系统是需求分析工程行之有效的一种需求分析策略。 采用快速原型法的需求分析增加了客户和开发者之间的相互交流，尤其是客户和快速原型开发组之间的交流，并几乎一直保持这种交流，直到原型系统得到客户的许可。3.2.1会谈

会谈有正式会谈和非正式会谈两种形式。

非正式会谈以一种较自由的形式，交换对问题的看法，主要是了解问题的性质、需要解决的方案、所需的人数和能力，关注客户的目标和收益。

正式会谈将根据一些事先准备好的议题全面展开讨论，得出结论性的意见。多视点的需求分析

对于任何中、大型系统，通常有多个不同类型的用（客）户，必然会有不同的视点考虑。从不同视点观察一个问题，可以得到不同的解决方法。 对于有多视点（客户）的需求分析过程，关键是发现众多视点的存在，考察不同视点接收的服务，收集这些信息并提供一个框架以解决不同视点提出的需求冲突。具体分为视点识别、视点组织、视点文档编写和视点系统映射四部分内容。多视点的服务层次示例所有视点客户银行职员服务运行诊断添加纸发送消息服务查询余额提取现金账户持有者外部客户出纳员管理者工程师服务添加现金服务记名支票发送消息交易列表汇票清单划转资金图3.4自动柜员机（ATM）系统部分视点的服务层次示例图3.2.2调查表 在事务环境中，获得事务处理需求信息常用调查表、分析报表、摄像等方法。 ◆向客户组织相关人员提出（书面的）调查表问答，并对其进行汇总分析。 ◆分析客户事务信息的各种报表（报表的字段能说明工作流程和各个环节的相关重点）。 ◆在工作现场安装摄像机，准确记录工作流程。3.2.3场景分析

场景（情景）分析是从软件系统的一个交互场景示例中得到需求分析信息，然后将其以形式化方式表示出来。 场景分析是用户在某种程度上演示产品的应用“样本”，通过交互实例片断细节（情景）的描述，实现对某个目标产品的表述。每个情景可能包含一个或多个交互，它们能在不同的细节层次上提供不同类型的情景信息。 情景开始于一个框架，在导出过程中，细节被逐渐增加，直到产生交互的一个完整的描述。场景（情景）内容 通常，一个场景（情景）可能包括： ①在场/情景开始部分有一个系统状态描述； ②一个关于标准事件流的描述； ③一个关于哪儿会出错，以及如何处理错误的描述； ④有关其他可能在同一时间进行的活动的信息； ⑤在场/情景完成后系统状态的描述。3.3结构化需求分析

需求分析方法很多，每种分析方法都有其独特之处。所有分析方法均与如下一些操作原则相关联。 ①必须表示和理解问题的信息域； ②必须定义软件将完成的功能； ③必须表示软件的行为（作为外部事件的结果）； ④必须划分描述信息、功能和行为的模型，从而使得可以以层次的方式揭示细节； ⑤分析过程应该从要素信息移向细节实现。3.3.1结构化分析方法

◆在需求工程中，分析员创建系统模型，以便可以更好地理解数据和控制流、处理功能和操作行为，以及信息内容，并综合系统的功能、非功能要求和数据要求的分析结果导出系统详细的逻辑模型。这种用一系列结构化的系统模型来描述系统需求的方法称为结构化分析方法（SA，StructuredAnalysis）

。 ◆结构化分析方法是一种系统建模技术，是适用于大型数据处理系统的、面向数据流的需求分析方法。3.3.1结构化分析方法

◆结构化需求分析方法一般采用一些指导性原则： ①在开始建立分析模型之前先理解问题。 ②开发原型模型，使用户了解将如何进行人机交互。 ③记录每个需求的起源和原因，有效地保证需求的可追踪性和可回溯性。 ④使用多个需求分析视图，建立数据模型、功能模型和行为模型。 ⑤给需求赋予优先级，优先开发重要的功能，提高开发生产效率。 ⑥努力删除含糊性。3.3.2结构化分析模型 ◆系统模型不是系统的“替代”，而是抛弃了具体细节的系统的一个抽象。 ◆系统模型可以从以下不同的角度表述系统： ①从外部看，它是对系统分析上下文或系统环境建模； ②从行为上看，它是对系统行为建模； ③从结构上看，它是对系统的体系结构和系统处理的数据结构建模。 ◆不同的系统模型基于不同的抽象方法。3.3.2结构化分析模型 ◆结构化分析模型必须达到以下主要目标： ①描述客户的需要； ②建立软件设计的基础； ③定义在软件完成后可以确认的一组需求。 ◆结构化分析模型有数据模型、状态转换模型、 实体-关系模型等。

结构化分析模型的体系结构数据字典实体-关系图数据流图加工规约数据对象描述状态转换图控制规约图3.5结构化分析模型的体系结构结构化分析模型

分析模型结构的核心是数据字典（DD）包含了软件使用或生产的所有数据对象描述的中心数据库。 分析模型结构的中间层有三种视图。 数据流图（DFD）服务于两个目的：一是指明数据在系统中移动时如何被变换，二是描述对数据流进行变换的功能和子功能。数据流图可以用于信息域的分析，并作为功能建模的基础。 实体-关系图（E-RD）描述数据对象之间的关系。结构化分析模型

状态转换图（STD）指明作为外部事件的结果，系统将如何动作。状态转换图表示系统的各种行为模式，以及在状态间转换的方式，是行为建模的基础。 分析模型结构的外层是描述。在实体-关系图中出现的每个数据对象的属性可以使用数据对象描述来描述。在数据流图中出现的每个加工/处理的功能描述包含在加工规约中。软件控制方面的附加信息包含在控制规约中。1.数据流图数据源点或终点变换数据的处理数据存储数据流图3.6数据流图的基本符号或或或

数据流图是逐步细化地描绘系统“做什么”的，通常作为软件分析和软件设计的工具，对更详细的设计也有所帮助。数据流图应用示例

【例3.1】一个采购部每天需要一张定货报表的数据流图。 ⑴数据流分析 ⑵系统基本模型数据流图（最抽象的） ⑶数据流图的逐步求精 第一步求精：定货系统基本模型可细化为“处理事务”和“产生报表”两个主要功能。 第二步求精：对定货系统模型可以进一步求精。定货系统数据流图（1）采购员事务定货报表图3.7定货系统基本模型的数据流图仓库管理员定货系统定货信息库存清单图3.8定货系统数据流图：第一步求精定货信息库存信息采购员定货报表产生报表仓库管理员处理事务事务定货系统数据流图（2）仓库管理员采购员处理入库事务入库事务出库事务定货报表图3.9定货系统数据流图：第二步求精处理定货定货信息处理出库事务产生报表定货信息库存清单库存信息图书销售数据流图（1）信用状态图3.13图书销售数据流图：第一步求精顾客数据顾客处理订单订单发货清单图书细节图书数据图书销售数据流图（2）顾客处理订单图书细节信用状态订单顾客数据发货清单图3.14图书销售数据流图：第二步求精聚集订单向图书供应商订购图书供应商订购的图书有现货的图书细节待订单图书数据图书销售数据流图（3）图3.15图书销售数据流图：第三步求精账目发货清单生成账目清单付款账目清单发货细节发货细节顾客处理订单图书细节信用状态订单顾客数据聚集订单向图书供应商订购图书供应商订购的图书有现货的图书细节待订单图书数据2.状态转换图

状态模型是一种描述系统对内部或者外部事件响应的行为模型。它描述系统状态和事件，以及事件引发系统在状态间的转换。 状态模型一般采用状态转换图（状态图）标记方法。 状态图描述了系统中某些复杂对象的状态变化，主要有状态、变迁和事件三种描述。状态转换图应用示例

【例3.2】一个复印机控制软件简化的状态图。图3.10复印机软件简化的状态图读命令复印重加载纸诊断问题闲置与“读命令”相关非卡纸与“读命令”相关卡纸与“完成问题”相关“满”和“开始”与“复印”相关复印与“读命令”相关满与“读命令”相关3.实体-关系图

系统建模的一个重要方面是定义系统处理的数据的逻辑结构。实体—关系模型描述数据实体、关联以及实体属性。该模型用实体-关系图描述现实世界中的实体，而不涉及实体在系统中的实现方法。 实体彼此间的联系分为三类：一对一（1:1）联系，一对多（1:N）联系，多对多（M:N）联系。 属性是实体或联系所具有的性质。通常一个实体有若干个属性。联系也可以有属性。 实体-关系图应用示例

【例3.3】一个学生管理系统的实体-关系图。

图3.11学生管理系统的实体-关系图成绩NM工号姓名性别职称职务学历教师教1学号姓名性别系别年级住址学生学N课程号课名学时学分课程4.数据字典

数据字典是管理各种分析模型中出现的有关命名描述的一个集合（通常采用卡片集形式）。 数据字典一般由数据流、数据流分量、数据存储和处理四类元素的定义组成。处理常用输入-处理-输出（IPO）视图描述。如果信息是一个复合对象，它还应有其组成部分描述。 由数据元素组成数据信息的方式有顺序、选择和重复三种基本类型。可以使用这三种类型的任意组合定义数据字典中的任何条目。数据字典应用示例

【例3.4】定货系统中部分卡片形式的数据定义。名字：定货报表别名：定货信息描述：每天需要定货的零件表定义：定货报表=零件编号+零件名称+定货数量+价格+1{供应者}3

位置：输出到打印机名字：零件编号别名：描述：惟一标识一个特定零件的关键组成定义：零件编号=8位字符位置：定货报表、定货信息库存清单名字：定货数量别名：描述：某个零件一次定货的数目定义：定货数量=[1|2|3|4|5]位置：定货报表定货信息名字：价格别名：价格范围描述：目前参考价格或者上下限定义：价格=1{零件单价}2位置：定货报表定货信息库存清单图3.12数据字典卡片方式示例3.3.3结构化分析步骤

⑴问题描述 ⑵画分层的数据流图 ⑶决定哪些部分需要计算机化和怎样计算机化 ⑷数据细节描述 ⑸定义处理逻辑 ⑹定义物理资源 ⑺确定输入/输出规格说明，确定有关数值 ⑻确定硬件需求 ⑼根据结构化分析模型，建立系统规格说明文档3.3.4结构化分析实例

图书馆系统的问题描述： ①一个图书馆藏有图书和期刊杂志两大类书籍，每种图书/杂志可以有多册。 ②图书馆可以维护（注册、更新和删除）图书资料。 ③图书馆管理员负责与借书者打交道。 ④借书者可以预约目前借不到的书或杂志。 ⑤所有人员都可以浏览图书馆的图书信息和各种告示。 ⑥系统能在流行的技术环境下运行，有一个良好的图形交互界面。 ⑦系统应具有良好的可扩展性。图书馆系统功能分析 ①浏览功能：所有人员都可以浏览图书馆的图书信息。 ②借还功能：借书者可以借/续借、还、预约图书。 ③图书管理功能：图书管理人员可以做录入、更新和销毁等图书信息维护工作。 ④借书者管理：系统管理人员可以进行注册、更改、注销借书者信息等维护工作。建立数据流图

分析图书馆系统有哪些外部用户，即角色。图书馆系统主要有一般浏览者、借书者、一般管理员和系统管理员四类外部用户。浏览者浏览图书图3.16图书馆系统的基本逻辑模型图书信息浏览命令借/还功能数据流图图3.17借/还功能（第一步）DFD图3.18借/还功能（修改）DFD借书者显示信息借书还书续借预约管理员借书者书目号和借书证号书目号书目号标题号和借书证号借书还书续借预约管理员借书者书目号和借书证号书目号书目号标题号和借书证号维护功能数据流图图3.19维护功能（第一步）DFD图3.20维护功能（修改）DFD注册借书者注销借书者录入新书更改借者更新图书销毁图书处理罚金管理员管理员录入标题删除标题修改标题销毁书目修改书目录入新书标题信息标题号标题号书目信息书目号书目号管理员借书功能细化的数据流图管理员借书者验证借书者和图书书号借书证号创建借书记录显示失败信息更新借书者更新图书信息显示借书成功不允许借书记录图书信息允许图3.21借书功能细化的数据流图借书者建立实体-关系图 图书馆系统有“图书”和“借书者”两个实体。 在数据流图的分析中发现“图书”实体，没有真正区别借书和预约的关系。借书者是借一本具体的书，即“书目”，而预约图书指的是此类书，而不是指具体的某册书目。因此，要用“标题”实体区分二者，即预约的是书的“标题”，而不是“书目”。 外部实体除了“借书者”，还有“系统管理员”。因此，必须考虑有严格授权进入的权限。图书馆系统实体-关系图注册/更改/注册借书目条码号分类号ISBN录入/更新/删除ISBN号书名作者出版社馆藏数价格可借数图3.22图书馆系统的实体-关系图系统管理工号姓名性别权限密码标题借书证号条码号借书日期归还日期续借次数借书记录借书证号姓名性别地址身份借书数罚金借书者还包含续借借书证号ISBN预约日期图书号预约建立状态转换图

图书可借条件：图书馆库存的该图书的可借册数（n）大于预约该图书的借书者数目（m）。

借出在架借还图3.24书目实体状态图可借不可借图3.23标题实体状态图还书[n<=m+1]借书[n>m+1]还书[n=m]借书[m=n+1]建立数据字典

图书馆系统的图书信息分为“标题”和“书目”。标题描述抽象的书的信息，书目则是具体的每一本书的信息。

名称：标题别名：抽象的图书描述：描述一个抽象的图书的信息定义：标题=ISBN+书名+作者+出版社+出版日期版次+价格+目录+内容简介+馆藏数+可借数+预约数位置：图书查询,借书,还书,预约名称：书目别名：具体的书描述：对应标题的具体的一本书定义：书目=条码号+分类号+ISBN位置：借书、还书、更新图3.25“标题”和“书目”的卡片描述3.4需求分析的描述

需求规格说明文档（SRS，SoftwareRequirementSpecification）是需求分析任务的最终“产品”。SRS是软件工程项目的第一份，也是最重要的一份文档。 ①相当于客户和开发商之间的一项合同； ②精确地描述产品做什么，以及产品的约束条件等； ③给软件设计提供了一个蓝图，给系统验收提供了一个验收标准集。 SRS的读者范围广泛，有系统用（客）户、管理者、需求分析工程师、系统测试工程师和系统维护工程师等。需求规格说明文档（SRS） 需求规格说明文档（SRS）应满足以下描述要求： ①应该只叙述系统的外部行为； ②应该定义实现上的约束； ③应该是容易改变的，是系统维护人员的的参考工具； ④应该记录系统的整个生命周期； ⑤应该对未料到的事件给出可接受的反应。SRS的内容框架

IEEE/ANSI830-1993标准和我国GB856D-1988国家标准，给出了需求规格说明文档（SRS）的内容框架：

1引言 1.1编写目的 1.2项目背景（单位和与其他系统的关系） 1.3定义（专门术语和缩写词） 2任务概述 2.1目标 2.2运行环境 2.3条件限制SRS的内容框架

3数据描述 3.1静态数据 3.2动态数据 3.3数据库描述 3.4数据字典 3.5数据采集 4功能需求 4.1功能划分 4.2功能描述 5性能需求 5.1数据精确度

5.2时间特性 5.3适应性6运行需求 6.1用户界面 6.2硬件接口 6.3软件接口 6.4故障处理 7其他需求（检测或验收标准、可用性、可维护性、可移植性、安全保密等）3.5小结

◆需求分析常采用原型技术快速建立系统原型，有助于理解、建立和验证系统需求。 ◆结构化系统分析（SA）方法是基于抽象和分解的一种典型的建模技术，其表述模型的工具有数据流图（DFD）、数据字典（DD）、实体-关系图（E-RD）和状态图（STD）等。

◆需求规格说明文档（SRS）是需求分析的“产品”，是软件工程项目的第一份，也是最重要的一份文档。它是系统需求的全面描述，是客户与开发商之间的合同， 是系统验收、开发和维护的基础。软件工程方法与实践第4章软件设计电子教案第4章

软件设计4.1软件设计概述4.2面向数据流分析（DFA）的设计

4.3面向数据的设计

4.4软件详细设计4.5特定应用软件的设计4.6小结4.1软件设计概述

软件设计是生成将要构造的目标系统“怎么做”的模型描述，即对将要实现的软件系统的体系结构、系统的数据、系统模块间的接口，以及所采用的算法给出详尽的描述。 传统的结构化软件设计有两种方法：

面向行为的设计是基于数据处理过程的软件设计，也称为结构化设计（SD）方法，如面向数据流分析（DFA）的设计方法。

面向数据的设计是基于输入/输出数据结构的软件设计，如Jackson方法（JSD）和逻辑构造程序方法（LCP）。4.1.1软件设计过程

软件设计是一系列迭代步骤的设计过程。 设计模型是设计过程的集中体现。设计模型首先描述所设计的软件的整体，然后逐步求精设计，以提供构造每个细节的指南。 软件设计包括总体设计、详细设计和设计测试三部分。软件设计的这三项活动在各具特色的软件设计方法中，是以不同的过程形式表现的。软件设计的三类活动 1.软件总体设计，也称为概要设计，软件结构设计，或高层设计。软件结构设计主要是仔细地分析需求规格说明，研究开发产品的模块划分，形成具有预定功能的模块组成结构，表示出模块间的控制关系，并给出模块之间的接口。 2.软件详细设计，也称为模块过程设计，或低层设计。详细设计是为结构设计中的各个模块设计过程细节，确定模块所需的算法和数据结构等。 3.软件设计的测试和复审，确保设计的正确和优化。软件结构设计过程

软件设计中最重要的是软件结构设计。软件结构设计过程一般采用以下步骤： ①设计供选择的方案； ②选取合理的方案； ③推荐最佳方案； ④功能分解和设计软件结构； ⑤数据库设计； ⑥制定软件设计测试计划； ⑦编制设计文档； ⑧审查和复审。软件设计的指导原则

①设计过程不应该受“隧道视野”的限制。 ②设计对于分析模型应该是可跟踪的。 ③设计者应该尽可能使用可复用的设计构件。 ④软件设计的结构应该尽可能模拟问题域的结构。 ⑤设计应该表现出一致性和集成性。 ⑥设计应该能够适应修改。 ⑦在创建设计时，就应该考虑能够评估其质量。 ⑧应该复审每一步设计，以减少语义性错误。4.1.2软件模块化设计

模块是一个独立命名的，拥有明确定义的输入、输出和特性的程序实体，可以通过名字访问，可单独编译。

软件的模块化设计是指把一个大型软件系统的全部功能，按照一定的原则合理地划分为若干个模块，每个模块完成一个特定子功能，所有的这些模块以某种结构形式组成一个整体。 软件模块化设计的指导思想是分解、抽象、逐步求精、信息隐蔽和模块独立性。1.软件模块化

软件模块化必须保证科学、合理地进行模块分解。这与逐步求精、抽象和信息隐蔽等概念紧密相关。 一个软件系统的各个模块之间是相互关联的，模块划分的数量越多，模块间的联系也越多。模块本身的复杂性和工作量虽然随着模块变小而减少，模块的接口工作量却随着模块数增加而增大。因此，软件模块化应把模块数控制在一定的范围内，可得到最小总开发工作量（最小成本）。 模块数和开发工作量的关系图4.1模块数和开发工作量的关系开发工作量模块数最小成本区模块成本接口成本总成本软件模块化分解过程

软件模块化分解过程是对系统自顶向下、从抽象到具体的有层次的思维和求解过程。软件结构每一层次中的模块，表示了对软件抽象层次的一次精化。这不仅使软件结构清晰，容易理解和设计，提高了软件的可靠性和可修改性，而且有助于软件的测试、调试和开发过程的组织管理。2.模块独立性

模块独立性是模块化、抽象、信息隐蔽等概念的直接结果，也是判断模块化结构是否合理的标准。 模块独立性是指开发具有独立功能而和其他模块没有过多关联的模块，也就是说，使每个模块完成一个相对独立的特定子功能，并且和其他模块之间的关系尽可能简单。 模块独立性体现了有效的模块化，有两大优点： 第一，独立的模块由于分解了功能，简化了接口，使得软件比较容易开发。 第二，独立的模块比较容易测试和维护。模块的内聚和耦合

模块独立性可以由两个定性标准度量，即模块自身的内聚（Cohesion）程度和模块之间的耦合（Coupling）程度，前者也称为块内联系或模块强度，后者也称为块间联系。 模块独立性愈高，则块内联系越强（内聚性强/高），块间联系越弱（耦合度弱/低）。 模块内聚程度的划分偶然性内聚弱逻辑性内聚时间性内聚过程性内聚通信性内聚顺序性内聚功能性内聚强低内聚中内聚高内聚

内聚性是从功能的角度对模块内部聚合能力的量度。高（强）内聚是模块独立性追求的目标。 “一个模块一个功能”已成为模块化设计的一条重要准则。应尽量使用高、中内聚性的模块；低内聚性模块可维护性差，应尽可能避免使用。 模块耦合程度的划分非直接耦合弱数据耦合特征耦合控制耦合外部耦合公共耦合内容耦合强弱耦合中耦合强耦合较强耦合

耦合度是一个软件结构不同模块之间互连程度的度量。 耦合度的强弱取决于模块接口的复杂程度，以及通过接口的数据类型和数目。弱（低）耦合是模块独立性追求的目标。应尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，最好不用内容耦合。3.模块化设计的优化

优良的软件模块化设计往往能导致程序设计的高效。软件模块化设计常采用以下优化策略： ①改进软件结构，提高模块独立性。 ②在满足模块化要求的前提下尽量减少模块数量。 ③模块规模应适中。 ④软件结构的深度、宽度、扇入数和扇出数都要适当。⑤模块的作用域应该在控制域之内。 ⑥力求降低模块接口的复杂程度，设计单入口、单出口的模块。4.1.3软件系统结构模型

大型软件系统总是被分解成一系列子系统，由子系统提供一些相关的服务。软件体系结构设计过程就是识别出这些子系统，并建立子系统控制和通信的框架，最后给出软件体系结构的一个描述。 软件系统结构模型可分成系统构成模型和系统控制模型。1.软件系统构成模型

对于不同类型的软件系统，系统体系结构依赖于系统的构成模式。

容器模型是构成一个系统的子系统的集合模型。 容器模型子系统交换信息的协调有两种方法： ①全部共享数据放在一个中央数据库中，所有子系统都能从中存取数据。 ②每个子系统用各自的数据库与其他子系统进行数据交互，通过消息传递来实现。

共享容器模型示例设计编辑器代码生成器项目存储设计转换器程序生成器设计分析器报告生成器图4.4CASE工具集成系统的系统结构示例客户机/服务器模型及示例网络目录服务器目录视频服务器电影文件图片服务器图片文件web服务器超文本文件图4.5电影和图片库系统的系统结构示例客户1客户2客户n………

客户机/服务器模型的主要组成部分是： ①一组给其他子系统提供服务的单机服务器。 ②一组向服务器请求服务的客户机。 ③一个连接客户机和服务器的网络（可选）。抽象机模型及示例

抽象机模型（分层模型）是把子系统组织成有层次的接口模型。每一层定义为一个抽象机（由其下层抽象机的代码构成），每一层抽象机给上一层提供服务，同时调用下一层的服务。 抽象机模型的分层方法支持了系统的增量式开发。通信介质应用层表示层会话层传输层网络层数据链路层物理层用户B图4.6OSI参考模型的系统结构示例应用层表示层会话层传输层网络层数据链路层物理层用户A2.软件系统控制模型

软件体系结构设计除了要明确系统构成模型之外，还要给出系统的控制模式。 在体系结构层次上的控制模式主要反映子系统之间的控制流程。 系统控制模型有集中式控制和基于事件控制的两个一般性的建模方法。 集中式控制模型 在集中控制模型中，一个子系统被定义为系统控制器来负责管理其他系统的执行。集中控制模型又可分调用—返回模型和管理者模型两类。 ①调用—返回模型控制始于系统（程序）的顶层，在子系统（程序）调用过程中，控制逐步传递到更低的层次中。该模型适用于顺序执行的系统。 ②管理者模型的一个系统组件被指定为系统管理者，控制其他系统过程的启动、终止和协调。该模型适用于并发系统。集中式控制模型示例系统控制器故障处理器用户界面图4.7实时系统的集中式控制模型传感器进程传动装置进程计算进程事件驱动控制模型 事件驱动控制模型是基于外部产生的事件驱动系统的。 ①广播模型：发生的事件广播到所有子系统，任何能处理该事件的子系统都会响应（适用于分布式系统）。 ②中断驱动模型：由中断处理器对外部中断进行检测，在其他组件中处理这些中断（适用于硬件实时系统）。 4.1.4软件设计说明文档

“设计先于编码”，这是软件工程“推迟实现”基本原则的又一体现。软件系统设计是把软件需求“变换”为用于构造软件的蓝图。所以，它的“输入”是需求规格说明文档，“输出”是软件设计说明文档。而设计说明文档又是软件实现的“输入”，即编码的蓝图。 软件设计说明文档是设计规约的模板，详细描述了所有设计信息。 4.2面向数据流分析的设计

面向数据流分析（DFA，DataFlowAnalysis）的设计是从数据流图（DFD）分析模型映射为软件模块组成结构设计的描述，是一种结构化的软件体系结构设计方法，也称为结构化设计（SD，StructuredDesign）方法。 面向数据流分析的设计能与大多数需求规格说明技术配合，可以使模块化达到高内聚性。4.2.1数据流类型

根据数据信息的“流动”特点，有两种数据流类型。 1．变换型数据流（变换流） 信息在“流”经系统的过程中，整个数据流呈现了以输入、变换、输出的顺序方式，沿一定路径前行的特征。 2．事务型数据流（事务流） 当数据流经过一个具有“事务中心”特征的数据处理时，它可以根据事务类型从多条路径的数据流中选择一条活动通路。数据流类型示图图4.9事务数据流模型……活动通路……………………事务中心⊕⊕⊕时间输入流输出流变换流外部表示内部表示图4.8变换数据流模型信息4.2.2DFA的设计步骤 ①复查基本系统逻辑模型，并精化系统数据流图，使数据流图中的每个处理都表示一个规模适中、相对独立的子功能。 ②分析数据流图，确定数据流具有变换特征还是事务特征。一般，大多数系统的全局特性都可以认为是变换流模型。当遇到全局或者局部有明显事务流特征时，应采用相应的事务分析的设计。 ③如果是变换流模型，确定输入流和输出流的边界（也分别称为最高输入/输出抽象点），输入流边界和输出流边界之间就是变换流，也称为“变换中心”。如果是事务流模型，要确定“事务中心”和各个事务动作流。4.2.2DFA的设计步骤

④采用自顶向下、逐步求精的方式完成模块分解，确定相应的软件组成结构，并对每一个模块给出一个简要说明，包括模块接口信息、模块内部信息、过程陈述、约束等。 ⑤根据模块独立性原理和运用设计度量标准，对导出的软件结构进行优化，得到具有尽可能高的内聚性，尽可能松散耦合的模块结构。

4.2.3DFA设计技术

面向数据流分析的设计分变换流分析设计和事务流分析设计两种。 1．变换流分析设计 变换流分析设计的要点是分析数据流图，确定输入流、输出流边界，根据输入、变换、输出三个数据流分支将软件映射成一个标准的“树型”体系结构。 4.2.3DFA设计技术

2．事务流分析设计 事务流分析设计是把事务流映射成包含一个输入分支和一个分类处理多个分支的软件结构。输入分支的映射方法和变换分析映射出输入结构的方法相似，即从事务中心的边界开始，把沿着接收流通路的处理映射成一个个模块。分类处理分支结构包含了一个分类控制模块和它下层的各个动作模块。数据流图的每一个事务动作流路径应映射成与其自身的信息流特征相一致的结构。 4.2.4DFA设计实例

汽车数字化仪表板控制软件有多个输入数据流和输出数据流，既有变换流，又有事务流。所以，适合于用变换流分析和事务流分析的综合型设计方法。

问题定义和数据流描述：

汽车数字化仪表板控制软件分成两大功能子系统：定时采样处理子系统和功能键处理子系统。整个仪表板控制软件的主控程序按设定的定时周期，用中断方式调用采样处理子系统；按巡回检测的方式，实时监控功能按键动作。定时采样处理子系统分析

仪表板定时采样子系统定时读取车轴旋转计数信号和油料传感器信号，经采集、变换和相关计算，在数字显示窗口动态地显示汽车速度、里程、油耗等当前相关信息。 该子系统的数据流图，具有典型的变换流特征。输入流和输出流的边界用虚线表示。 注意，边界划分可能出现的偏差会在结构的优化中得到纠正。定时采样子系统数据流图输入流边界输出流边界图4.14汽车仪表板定时采样处理子系统的数据流图和输入/输出流边界的划分车轴旋转信号产生里程显示信号/秒(sps)采集求平均(rpm)读旋转信号转换转/分计算里程里程显示平均(sps)公里值判断超速值发出振铃声超速信号(rpm)(mph)超速警铃加速度符号显示确定加减速产生显示符号加/减/匀速指示计算速度产生速度显示速度显示公里/小时(mph)(mph)计算油料消耗产生油耗显示油耗显示油耗量(mpg)(gph)燃料传感信号读信号校验模/数转换燃烧流计算燃油量燃烧值功能键处理子系统分析

仪表板上有6个功能键和10个数字键（0~9），可以选择不同功能按键，完成相关控制操作。

仪表板功能键处理子系统的数据流图（省略了部分数据流名字）具有典型的事务流特征。事务中心是“判别功能号”，有6个动作流分支分别对应6个功能键。其中，启动点火、限速设定、计费单价设定、显示油压和油温4个动作流分支具有变换流特征。功能键处理子系统数据流图⊕图4.15汽车仪表板功能键处理子系统的数据流图读功能按键值作废提示判别功能号接收限速值接收点火码接收单价值读取油温油压作废上次按键里程值清零产生油温/压值⊕⊕⊕⊕⊕显示油温油压判别正确？读数字键值读数字键值计费单价设置限速设置读数字键值按数字键出错按数按数提示字键字键按功能键启动点火里程单元单价单元点火密码限速单元定时采样子系统软件结构设计 根据“定时采样处理”的数据流图（图4.14）确定的输入流和输出流边界，把该子系统映射成变换流分析设计的软件结构模式。 首先建立系统的第一级分解，并确定分解模块的命名，分别是“接收传感器信号”、“数据转换处理”、“驱动仪表板显示”模块（图4.16）

。 然后，自顶向下分别对这三个模块进行软件结构的第二级分解（图4.17）

。 最后，根据软件结构优化启发式规则，对该子系统进行结构优化（图4.18）

。定时采样子系统软件结构图驱动发光二极管图4.18仪表板定时采样处理子系统软件结构有关速度的处理和显示油耗的处理和显示定时采样处理子系统主控读旋转信号计数求平均燃料流A/D换算成油量确定加/减速计算速度显示油耗计算油耗显示加/减速度判断超速计算里程显示里程发出铃声功能键处理子系统软件结构设计

根据对“功能键处理”数据流图（图4.15）的事务中心和6路动作流分析，将该子系统映射成以事务流分析设计为主的软件结构模式（图4.19）。

功能键处理子系统软件结构图图4.19仪表板功能键控制子系统软件结构功能键处理子系统主控信息提示写入单元取点火密码启动点火显示油压显示油温键号分析点火处理限速设定里程清零单价设定作废按键油温油压处理功能键号读键值密码验证驱动发光二极管4.3面向数据的设计

面向数据设计方法是基于软件所处理的有层次结构的数据信息来设计软件。 面向数据设计方法淡化了软件结构的概念，主要借助一组有条不紊的步骤，确定单个模块或小规模（子）系统程序结构和处理过程的描述。因此，这一类方法适合于总体设计和详细设计“合而为一”的软件设计。4.3.1Jackson方法（JSD）

Jackson方法，也称JSD（JacksonStructuredDesign）方法。 程序=算法+数据结构，表明算法和数据结构是程序设计中两个不可分割的侧面。算法的结构往往在很大程度上依赖于它要处理的数据结构。因此，由数据结构导出它的程序结构是Jackson方法的基本思想。1.Jackson图

Jackson图既可以描述问题的数据结构，也可以描述软件的程序结构，其优点是便于表示层次结构，利于结构自顶向下分解，形象直观、可读性好。（a）顺序结构（b）选择结构（c）可选结构（d）重复结构图4.20Jackson图三种结构形式的示例BACDI（j）AB*S（i）BoDoACoBo—oAS（i）2.JSD方法设计步骤

1.确定问题的输入和输出数据的逻辑结构，用Jackson图描绘它们。 2.找出输入数据结构和输出数据结构中对应关系的数据单元。 3.根据下述三条规则从数据结构的Jackson图导出程序结构的Jackson图。 ①为每个有对应关系的数据单元，按照它们在数据结构图中的层次在程序结构图的相应层次画一个处理框。2.JSD方法设计步骤

②根据输入数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应层次分别为它们画上对应的处理框。 ③根据输出数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应层次分别为它们画上对应的处理框。 4.列出所有的操作和条件，包括分支条件和循环条件，并把它们分配到程序结构图的适当位置。 5.用某种形式的伪码给出程序结构图对应的过程描述。JSD方法与DFA方法设计步骤图解Jackson方法（JSD）数据结构程序结构程序过程性描述（Jackson图）（Jackson图）（伪码）程序分析程序设计映射面向数据流分析的设计方法（DFA）问题结构软件结构各个模块的过程性描述（DFD图）（软件结构图）（过程描述工具）概要设计详细设计映射3.JSD方法设计示例

设计一个“统计文件空格数和输出空格统计表”程序。 （a）输入数据结构（b）输出数据结构图4.22统计文件空格数的数据结构Jackson图I空格数字符串串信息*空格总数表格体输出表格正文文件I字符串*非空格o空格o字符*S3.JSD方法设计示例图4.24统计文件空格数的程序结构Jackson图I(1)空格总数处理文件统计表格处理字符串*23167分析字符串分析字符串*I(2)打印空格数8打印字符串109125413处理非空格o处理空格o分析字符S(3)11134.3.2Warnier方法（LCP）

Warnier方法，也称逻辑构造程序（LCP，LogicallyConstructedProgram）方法。

LCP方法采用的描述工具是Warnier图。

Warnier图（Warnier-Orr图）是用花括号、伪代码、少量说明和符号组成的有层次的“树”形式描述数据，或者程序信息的逻辑结构（可以表示重复、条件、或、非等逻辑）。1.Warnier图（示例） 1层2层3层4层 空格（0或i次） 字符⊕ 字符串（m次）非空格（0或j次）输入正文文件（k次）（0或1次）图4.25正文文件输入数据结构的Warnier图2.LCP方法设计步骤

①分析和确定输入数据和输出数据的逻辑结构，用Warnier图描绘数据结构； ②根据输入数据结构导出程序结构，并用Warnier图描述程序的处理层次； ③将程序结构图改成程序流程图，并自上而下依次给流程图的每个处理框编序号； ④列出每个处理框的操作细节，分类写出伪码指令，得到的程序伪码序列，即为所设计程序的过程性描述。3.LCP方法设计示例 从“统计正文文件空格数”程序的输入数据结构的Warnier图，导出程序处理层次的Warnier图。开始（1次）处理（0或1次）处理（0或1次）结束（1次）程序开始（1次）字符串（k次）字符串（0或1次）结束（1次）开始（1次）字符（m次）结束（1次）开始（1次）空格（0或i次）⊕非空格（0或j次）结束（1次）4.4软件详细设计

软件详细设计是定义模块的算法细节，并用某种形式描述出来。结构化程序设计技术是软件详细设计的基础，而一个良好的描述工具是表现其结构化程序设计的载体。 结构化的程序只需用三种基本逻辑结构（顺序结构、选择结构和循环结构）就能实现。它们都强调对功能域的维护，每一种逻辑结构都有可预测的逻辑结构，并且都是单入口和单出口。4.4.1结构化的程序设计 ①结构化程序设计是一种自顶向下、逐步求精的设计技术； ②用先全局后局部、先整体后细节、先抽象后具体的逐步求精设计的软件实现过程，进而开发的程序，有清晰的层次结构； ③单入口单出口的控制结构，使得程序的静态结构和它的动态执行情况比较一致； ④控制结构有明确的逻辑模型，易于理解和测试； ⑤程序的模块化，便于重用； ⑥程序逻辑结构清晰，有利于程序的正确性证明。4.4.2详细设计工具 软件详细设计主要有图形、表格和语言三类描述工具。

程序流程图描述程序的控制流程。程序流程图的优点是直观，便于初学者掌握；缺点是控制流不带任何约束，可随意转移控制，使得过程的结构不清晰，不便于逐步求精。（a）预处理（b）选择（c）多分支（d）循环上界（e）循环下界图4.27程序流程图的基本描述符号（f）开始/结束（g）准备（h）注释（i）虚线（j）省略（k）并行方式（l）控制流盒图（N-S图）

盒图（N-S图）很容易表示程序结构化的层次结构，确定局部和全局数据的作用域，使得程序结构较为清晰。

（d）循环（e）调用子程序图4.28盒图（N-S）的基本描述符号循