软件工程pptppt课件.ppt

《软件工程pptppt课件.ppt》由会员分享，可在线阅读，更多相关《软件工程pptppt课件.ppt（248页珍藏版）》请在三一文库上搜索。

1、李宣东李宣东 王林章王林章 陈鑫陈鑫 张天张天 南京大学计算机科学与技术系南京大学计算机科学与技术系 http:/ 软软 件件 工工 程程 2009 2 Software Engineering Group 课程介绍 一、课程主要内容 n软件工程原理、方法和技术 传统软件工程方法 面向对象软件工程（统一建模语言UML） 软件过程、管理与质量 n软件工程工具和项目实践 2009 3 Software Engineering Group n软件工程：实践者的研究方法 Roger S. Pressman著 黄柏素 梅宏 译 机械工业出版社 nhttp:/www.uml.org/ nhttp:/www

2、.omg.org/mda/ 2009 4 Software Engineering Group 二、参考文献 2009 5 Software Engineering Group 三、软件工程所面对的问题 大规模、复杂软件系统的开发和维护 现代软件工程面对的困境 n如何构造有效的过程、方法和工具以适应现代大现代大 规模、复杂性软件系统规模、复杂性软件系统的开发和维护 复杂设备中安全关键软件的正确性正确性 国家级分布式应用软件的可靠性可靠性 大型实时指挥软件的时效性时效性 大型网络软件的可维护性可维护性 互联网软件的安全性安全性 复杂软件系统的可生存性可生存性 2009Software Engin

3、eering Group 2004年12月20日，美空军第422测试评估大队的一 架F-22战斗机因软件问题在起飞过程中失控坠毁。 2007年2月9 日同样因软 件问题延迟 在日本部署 复杂设备中安全关键软件的复杂设备中安全关键软件的 正确性正确性 2009 7 Software Engineering Group 事件：美国F-22猛禽战斗机 多计算机 系统试图 同时访问 同一资源 引起的软 件失效 国家级分布式应用软件的国家级分布式应用软件的 可靠性可靠性 2009 8 Software Engineering Group 事件：美国电力监测与控制管理系统 原因是 空管软 件时钟 缺陷 大

4、型实时指挥软件的大型实时指挥软件的 时效性时效性 2009 9 Software Engineering Group 事件：美国空管软件 2005年11月1 日，东京证券 交易所因为软 件升级出现系 统故障，导致 早间股市停摆 。 大型网络软件的大型网络软件的 可维护性可维护性 2009 10 Software Engineering Group 事件：东京证券交易软件 n约80%的家庭用户感染了Spyware n美国2004年网络犯罪非法谋利105亿美元 n50%以上的安全漏洞是由软件缺陷引起的 2009 11 Software Engineering Group 互联网软件安全的几个数据

5、互联网软件的互联网软件的 安全性安全性 复杂软件系统的复杂软件系统的 可生存性可生存性 2009 12 Software Engineering Group 互联网安全趋势图 2002年NIST估计软件 造成美国年经济损失 约600亿美元，占GDP 的0.6% 2009 13 Software Engineering Group 2009 14 Software Engineering Group 我们的信息基础设施我们的信息基础设施 正建立在脆弱的软件之上正建立在脆弱的软件之上! n软件的根本问题任何机构和个人都无法确保所 开发的软件一定没有问题。 2009 15 Software Engi

6、neering Group 四、为什么？ Microsoft的承诺 n间接损害不赔付责任： 在法律所允许的最大范围内，Microsoft Corporation或其他供应商绝不就因使用或不能使用本“ 软件产品”所发生的其他损害负赔偿责任，即使 Microsoft Corporation事先被告知该损害发生的可能性 。 n若为Windows的每一次Bug出现赔偿1美分，比尔盖茨早已 一贫如洗。 n计算机系统（软件系统）： 2009 16 Software Engineering Group 五、建立人与机器之间的信任关系 数学系统 生物系统 人与机器之间的关系人与人之间的关系 2009 17 S

7、oftware Engineering Group 第一部分 传统软件工程方法 n问题定义 n需求分析 n概要设计 n详细设计 n编 码 n测 试 n维 护 定义义 分析 设计 编码 测试 维护 2009 18 Software Engineering Group 传统软件工程方法 1、基本概念 2、系统定义 3、需求分析 4、设计 5、编码 6、测试 7、维护 2009 19 Software Engineering Group 内容组织 n软件 计算机系统中的程序及其有关文件。 n程序 计算任务中的处理对象和处理规则的描述。 n文件 为了便于了解程序所需的资料说明。 2009 20 Sof

8、tware Engineering Group 一、基本概念（1.1） n软件的作用 2009 21 Software Engineering Group l用户与硬件的接口 l计算机系统的指挥者 l计算机系统结构设计的重要依据 1.1基本概念 n软件的发展过程 2009 22 Software Engineering Group l第一阶段：从第一台计算机上的第一个程序的出 现到实用的高级程序设计语言出现之前（1946- 1956）； l第二阶段：从实用的高级程序设计语言出现到软 件工程出现之前（1956-1968）； l第三阶段：软件工程（1968- ）。 1.1基本概念 n软件的分类 2

9、009 23 Software Engineering Group l系统软件 l支撑软件（中间件middleware） l应用软件 硬件平台硬件平台 系统软件系统软件 支撑软件支撑软件 硬件平台硬件平台 系统软件系统软件 支撑软件支撑软件中间件中间件 应用软件应用软件应用软件应用软件 1.1基本概念 n软件危机 2009 24 Software Engineering Group l供求关系失调 l开发费用失控，进度拖延 l可靠性差 l难以维护 1.1基本概念 n产生软件危机的原因（软件本身的特点） 2009 25 Software Engineering Group l软件开发进展情况较难

10、衡量 l软件开发质量难以评价 l管理和控制软件开发过程相当困难 l软件没有“磨损”概念，软件维护通常意味着改进 或修改原来的设计 1.1基本概念 n产生软件危机的原因（软件开发人员的错误观点） 2009 26 Software Engineering Group l产生软件危机的原因（软件开发人员的错误观点 ） l“有一个对目标的概括描述就足以着手编写程序了 ，许多细节可以在以后再补充” l“所谓软件开发就是编写程序并设法使它运行” l“用户对软件的要求不断变化，然而软件是柔软而 灵活的，可以轻易地改动” l“软件投入生产性运行以后需要的维护工作并不多 ，而且维护是一件很容易做的简单工作” 1

11、.1基本概念 n软件工程 2009 27 Software Engineering Group 应用计算机科学、数学及管理科学等原理， 以工程化原则、方法解决软件问题的工程。其中 ，计算机科学、数学用于构造模型与算法，工程 科学用于制定规范、设计范型、降低成本及确定 权衡，管理科学用于计划、资源、质量、成本等 管理。 1.1基本概念 n软件工程的基本内容 2009 28 Software Engineering Group l软件设计方法论 l软件工具 l软件工程标准和规范 l软件工程管理 l软件工程理论 1.1基本概念 n软件工程的基本原理： 2009 29 Software Enginee

12、ring Group l严格按照计划进行管理 l坚持进行阶段评审 l实行严格的产品控制 l采用现代的程序技术 l结果要能清晰地审计 l开发小组人员素质要好，数量不宜多 l要承认不断改善软件工程实践的必要性 1.1基本概念 n软件生存期（过程）模型 软件生存期是软件产品或系统一系列相关活 动的全周期。从形成概念开始，经过研制，交付 使用，在使用中不断增补修订，直到最后被淘汰 ，让位于新的软件产品的过程。对软件生存期的 不同划分，形成了不同的软件生存期模型。 2009 30 Software Engineering Group 1.1基本概念 n瀑布式软件生存期模型 定义 分析 设计 编码 测试

13、维护 2009 31 Software Engineering Group 强调阶段的划分及其顺序性 、各阶段工作及其文档的完 备性，是一种严格线性的、 按阶段顺序的、逐步细化的 开发模式。 1.1基本概念 瀑布式软件生存期模型把软件开发过程划分成 若干阶段，每个阶段的任务相对独立，便于不同 人员分工协作，从而降低了整个软件开发工程的 困难程度。在软件生存期的每个阶段都采用科学 的管理技术和良好的方法与技术，而且每个阶段 结束之前，都从技术和管理两个角度进行严格的 审查，经确认之后才开始下一阶段的工作。 2009 32 Software Engineering Group 1.1基本概念 瀑布

14、式模型的特点： 2009 33 Software Engineering Group l结构简单明了；历史较长、应用面广泛、为广大 软件工作者所熟悉；已有与之配套的一组十分成 熟的开发方法和丰富的支撑工具。 l确定了需求分析的绝对重要性，但是在实践中要 想获得完善的需求说明是非常困难的；反馈信息 慢。 1.1基本概念 n软件质量要素： 2009 34 Software Engineering Group l正确性：软件产品准确执行软件规格说明中所规 定的能力。 l健壮性：在异常条件下软件仍能运行的能力。 l可靠性：软件在给定的时间内和规定的环境条件 下，按规格说明的规定成功地运行的概率。可靠

15、性理解为正确性和健壮性之和。 1.1基本概念 2009 35 Software Engineering Group SE Humor 1.1基本概念 1、问题定义的关键任务 确切地定义用户要求解决的问题，也就是确 定问题的性质、工程的目标和规模。 2009 36 Software Engineering Group 二、问题定义（1.2 ） 可行性研究 对软件进行分析与估算 确定软件作用范围 可行性研究： 2009 37 Software Engineering Group l经济可行性 l技术可行性 l法律可行性 l不同的方案 1.2 问题定义 对软件进行分析与估算： 2009 38 Sof

16、tware Engineering Group l确定软件的范围 l估算完成软件开发任务所需的资源 l估算软件的成本 l估算和安排软件开发项目的进度 1.2 问题定义 确定软件的作用范围 2009 39 Software Engineering Group 详细描述软件的任务和具体的要求，抱括软 件的功能、性能、接口和可靠性等四个方面的内 容。 1.2 问题定义 l范围（研制的目标，主要功能，其他特性，开发 概况） l资源（人力资源、硬件资源、软件资源、可用性 资源窗口） l成本 l进度安排 2009 40 Software Engineering Group 2、软件计划： 1.2 问题定义

17、 l软件需求分析是软件生存期的一个重要阶段，是软件开发项 目得以成功的基础。其最根本的任务是确定为了满足用户的 需要软件系统必须做什么。 l软件需求分析是一个不断发现和决定的过程，在此过程中， 软件开发者和软件申请者（用户）同样起着重要的作用。 l在需求分析与说明过程中，需要大量交换意见，其间充满着 传错信息和发生误解的可能性： l“我知道你相信你明白了你认为我所说的是什么，但是我不 能肯定你是否意识到你听到的并不是我所指的意思 ” 。 2009 41 Software Engineering Group 三、需求分析（1.3 ） 1、需求分析几点说明 2009 42 Software Eng

18、ineering Group 1.3 需求分析 2、软件需求分析实现以下几个目标： 2009 43 Software Engineering Group l给出软件系统的数据流程图与数据结构，构造一 个完全的系统逻辑模型； l提出详细的功能说明确定设计限定条件，规定性 能要求； l密切与用户的联系，使用户明确自己的任务，以 便实现上述两项目标。 1.3 需求分析 3、软件需求分析包括的工作： 2009 44 Software Engineering Group l问题的认识 需求分析人员通过频繁与用户联系，充分理解用户提 出的每一个功能与性能要求，从软件系统特征、软件开 发全过程以及软件计划给

19、出的资源和时间约束，来确定 软件开发的总策略。 l评价与综合 需求分析人员必须求得数据的流程和数据结构，评价 优缺点；结合用户要求，修改现行的系统，提出新系统 的功能，加以细化；提出软件的约束条件、响应时间、 存储条件等。 1.3 需求分析 l建立需求说明书 软件需求说明书包含软件功能、性能、接口、有效性 和逻辑模型的描述。为了证实软件能否被成功实现就要 规定相应的检验标准，这些标准在软件开发期间将作为 测试的依据。 l复审 由软件开发人员和用户共同对需求说明书进行严格的 审查。 2009 45 Software Engineering Group 1.3 需求分析 4、软件需求分析人员应该具

20、备的特征： 2009 46 Software Engineering Group l善于领会一些抽象的概念，重新整理使之成为各 种逻辑成分，并根据各种逻辑成分综合出问题的 解决办法； l善于从各种相互冲突或混淆的原始资料中吸取恰 当的论据； l能够理解用户的环境及领域知识； 1.3 需求分析 l具备把系统的硬件和软件部分应用于用户环境的 能力； l具备良好的书面和口头形式进行讨论和交换意见 的能力； l具有“既能看到树木，又能看到森林”的能力。 2009 47 Software Engineering Group 1.3 需求分析 6、结构化分析方法（SA） 2009 48 Software

21、Engineering Group lSA方法采用“抽象”和“分解”两个基本手段，用抽 象模型的概念，按照软件内部数据传递、变换关 系，由顶向下逐层分解，直到找到满足功能需要 的所有可实现的软件元素为止。 lSA方法采用“分解”的方式来理解一个复杂系统，“ 分解”需要有描述手段，数据流程图就是作为描 述信息流程和分解的手段而引入的。 1.3 需求分析 n数据流程图 2009 49 Software Engineering Group l 表示外部实体，代表数据源和数据池。 l 表示数据存储，代表系统加工的数据所存储的 地方。 l 表示加工，代表接收输入，经过变换，继而 产生输出的处理过程。 l

22、 表示数据流，代表数据的流向和路径。 流程图符号介绍 1.3 需求分析 5、基本系统模型 输入n 输出n 软件系统 输入1 输入2 输出2 输出1 . . . . . . 2009 50 Software Engineering Group 软件系统的全部功能被表示成一个单一的信息变换过程 1.3 需求分析 例：病员监视系统 病员病历 病员 监视 系统 病员 护士 护士 基本模型 病情信号 报告 警告信号 病历数据 请求提出报告 2009 51 Software Engineering Group 1.3 需求分析 本地 监视 中央 监视 报告 产生 更新 病历 护士 护士 病员 病员病历 病

23、员的病情界限 警告信号 病员数据 请求报告 经过整理后的病员数据 病情信号 2009 52 Software Engineering Group 1.3 需求分析 分解 病情信号 整理病员 数据 检查是 否超出 界限 产生警告 信号 时钟 整理后的 病员数据 日期时间 病员病情界限 体温 血压 脉搏 病员数据 警告信号 2009 53 Software Engineering Group 1.3 需求分析 数据流程图的特点： 2009 54 Software Engineering Group l可以表示任何一个系统（人工的、自动的、或混 合的）中的数据流程； l每个表示加工的圆圈可能需要进一

24、步分解以求得 对问题的全面理解； l着重强调的是数据流程而不是控制流程。 1.3 需求分析 推导数据流程图的简单准则： 2009 55 Software Engineering Group l第一层数据流程图应当是基本的系统模型； l应当仔细说明原始的输入/输出文件； l所有箭头和圆圈均应当加上标注（使用有意义 的名字）； l必须保持信息的连续性； l每次只加工一个圆圈。 1.3 需求分析 顶层顶层 数据流图图 随着需求分析 活动动的深入 ，较较高抽象 级别级别 的复杂杂 加工逐步精化 为为一系列相 互关联联的数 据流和子加工 。 数据流图图的精化与平衡 n逐层层精化必须须保持 数据流图图的平

25、衡 n数据流与加工精化 必须须保持一致 n需求分析活动动只求 对问题对问题 全面、清晰 的理解，不考虑软虑软 件设计细节设计细节 例子例子: :商店商店业务处业务处 理系理系统统 第一第一层层数据流数据流图图 加加细细每一个加工框每一个加工框 销销售售细细化化 采采购细购细 化化 l数据流程图中，所有的图形元素都进行了命名，所有 名字的定义集中起来就构成一本数据字典。 l数据字典最重要的用途是作为分析阶段的工具。在数 据字典中建立的一组严密一致的定义有助于改进分析 员和用户之间的通信，因此将消除许多可能的误解。 对数据的这一系列严密一致的定义也有助于改进在不 同的开发人员之间或者不同开发小组之

26、间的通信。如 果要求所有开发人员都根据公共的数据字典描述数据 或设计模块，则能避免许多麻烦的接口问题。 2009 62 Software Engineering Group n数据字典 1.3 需求分析 l信息结构是各个数据成分之间逻辑关系的一种表 示方法。 l数据结构决定信息的组织、存取方法、结合性程 度以及不同的处理方案。 l典型的数据结构包括标量项、顺序向量、n维空 间、链接表等。 2009 63 Software Engineering Group n信息结构 1.3 需求分析 分层数据结构表示法： 2009 64 Software Engineering Group l分层框图 lW

27、arnier图 1.3 需求分析 l分层框图 2009 65 Software Engineering Group 分层框图把信息用多层方框按照树形结构组 织起来。在结构的顶层，用一个方框代表 整个结构。下面各层由表示不同信息类别 的方框组成，它们可以看成是上一层方框 的子集。在该图的最低一层，每个框包含 单独的数据实体。 1.3 需求分析 XX公司销售产品 计算机软件计算机服务计算机硬件 存储器备件处理机应用系统软件服务培训 操作系统编译程序工具 编辑 程序 测试驱 动程序 设计辅 助工具 . . . . . . . . . . . . . . . . . . . . . . . . . .

28、 2009 66 Software Engineering Group 分层框图示例 1.3 需求分析 lWarnier图 2009 67 Software Engineering Group Warnier图把信息表示成一种树形数据结构 。可以规定某些信息种类或信息量是重复 性的，也可以说明在某一种类中信息是有 条件出现的。 1.3 需求分析 计算机系统 系统软件 应用软件 操作系统（P1） 编译程序（P2） 工 具 编 辑（P3） 测试驱动（P4） 设计辅助（P5） 2009 68 Software Engineering Group Warnier图示例 1.3 需求分析 7、软件需求说

29、明书 2009 69 Software Engineering Group 1. 概述 2. 信息描述 (1) 数据流程图 (2) 数据字典 (3) 数据结构 (4) 系统接口说明 (5) 内部接口 5. 参考文献 6. 附录 3. 功能说明 (1) 功能 (2) 处理说明 (3) 设计的限制 4. 检验标准 (1) 性能界限 (2) 测试种类 (3) 预期的软件响应 (4) 应考虑的特殊问题 1.3 需求分析 8、初步的用户手册 2009 70 Software Engineering Group l手册的准备迫使分析人员从用户的角度来看 待软件，从而及早考虑接口方面的人机环境 工程。 l用

30、户可以审查一个明确描述人机接口的实际 文件。 当确定了人机交互作用的软件需求后，准备一 份初步的用户手册是作为对所要求文件的补充往往 是有用的，这种手册将起到两个作用： 1.3 需求分析 9、软件需求说明的审查 2009 71 Software Engineering Group l审查需求的一致性 l审查需求的现实性 l审查需求的完整性和有效性 1.3 需求分析 软件需求说明审查中的问题 2009 72 Software Engineering Group l所规定的软件目标和任务与系统的目标和任务相符合吗 ？ l与所有系统成分的重要接口都已被描述了吗？ l研制项目的数据流程图、数据字典、数

31、据结构充分确定 了吗？ l图表都清楚吗？每个图表在不加补充说明的情况下能被 理解吗？ l主要功能在规定的范围之内吗？每一种功能被充分说明 了吗？ 1.3 需求分析 l设计的限制条件是现实的吗？ l开发的技术风险是什么？ l考虑过软件需求的其他方案吗？ l检验标准是否详细？他们能否确认系统是成功的？ l有无遗漏、重复或不一致的地方？ l用户是否审查了初步的用户手册？ l软件计划中的估算是否需要修改？ 2009 73 Software Engineering Group 1.3 需求分析 10、用于软件需求分析的工具 2009 74 Software Engineering Group l自然语言

32、描述的问题 - 不可判定问题 lWhat to do - 可判定问题，需要无穷资源形 式化语言 lHow to do - 可判定问题，需要有穷资源 1.3 需求分析 l软件设计是把软件需求变为软件的具体方案 l软件设计包括两个阶段：概要设计和详细设计 l概要设计根据软件需求所确定的信息流程或信息 结构，导出软件的总体表示-软件结构或程序 过程 2009 75 Software Engineering Group 四、概要设计设计 （1.4 ） n关于软件设计 Design Data design Architectural design Interface design Component-

33、level design The design model 1、软件结构 2009 77 Software Engineering Group l软件结构是一种层次化的表示，其指出了由需求 分析隐含地确定的某一问题的软件解法的各个元 素（称之为模块）之间的相互控制关系 l软件结构的演变从确定问题开始，当该问题的每 个部分用一个或多个软件加以解决以后，整个问 题的解也就有了 软件结构概念 1.4 概要设计 P3 P1 P2 P4P5 S1S2 S3 S4S5 2009 78 Software Engineering Group 1.4 概要设计 软件结构的度量和术语 2009 79 Softwa

34、re Engineering Group l深度：表示控制的层数。 l宽度：表示控制（同一层次）总跨度。 l扇出数：指由一模块直接控制的其他模块的数目 。 l扇入数：指有多少个模块直接控制一个给定的模 块。 l上级模块 l下级模块 1.4 概要设计 Design Width Depth Fan-out Fan-in 2、程序过程 2009 81 Software Engineering Group 程序过程是用于描述每个模块的操作细节，是关 于模块算法的详细描述，它应当包括处理的顺序 、精确的判定位置、重复的操作以及数据组织和 结构等。 1.4 概要设计 3、模块 2009 82 Softwa

35、re Engineering Group 模块是数据说明、可执行语句等程序对象的 集合，是单独命名的并且可以通过名字来访问， 例如过程、函数、子程序、宏、modula等。 1.4 概要设计 4、模块化 2009 83 Software Engineering Group 软件被划分成独立命名和可独立访问的被称作模 块的构件，每个模块完成一个子功能，它们集成 到一起满足问题需求。 1.4 概要设计 模块化论据 2009 84 Software Engineering Group lC(x)定义为问题x的感知复杂性 lE(x)定义为解决问题x所需要的工作量 l对p1和p2两个问题， l 若 C(p

36、1) C(p2)，则 E(p1) E(p2) lC(p1 + p2) C(p1) + C(p2) lE(p1 + p2) E(p1) + E(p2) 1.4 概要设计 软件总成本 集成成本 成本/模块 模块数量 成本或工作量 最小成本区域 M 2009 85 Software Engineering Group 1.4 概要设计 实现模块化的手段 2009 86 Software Engineering Group l抽象：抽出事物的本质特性而暂时不考虑它们的 细节。 l信息隐蔽：应该这样设计和确定模块，使得一个 模块内包含的信息（过程和数据）对于不需要这 些信息的模块来说，是不可访问的。 1

37、.4 概要设计 l模块独立性：模块独立是指开发具有独立功能而 且和其它模块之间没有过多的相互作用的模块。 l模块独立的意义： 功能分割，简化接口，易于多人合作开发同 一软件； 独立的模块易于测试和维护。 2009 87 Software Engineering Group 模块独立性 1.4 概要设计 模块独立程度的衡量标准 2009 88 Software Engineering Group l耦合性：对一个软件结构内不同模块间互连程度 的度量。 l内聚性：标志一个模块内各个处理元素彼此结合 的紧密程度，理想的内聚模块只做一件事情。 1.4 概要设计 耦合分类 2009 89 Softwar

38、e Engineering Group l无任何连接：两个模块中的每一个都能独立地工 作而不需要另一个的存在（最低耦合）。 l数据耦合：两个模块彼此通过参数交换信息，且 交换的仅仅是数据（低耦合）。 l控制耦合：两个模块之间传递的信息有控制成分 （中耦合）。 1.4 概要设计 l公共环境耦合：两个或多个模块通过一个公共环 境相互作用： 1、一个存数据，一个取数据（低耦合）； 2、都存取数据（低-中之间）。 l内容耦合： 1、一个模块访问另一个模块的内部数据； 2、两个模块有一部分程序代码重叠； 3、一个模块不通过正常入口而转移的另一个的内部； 4、一个模块有多个入口（意味着该模块有多个功能）

39、。 2009 90 Software Engineering Group 1.4 概要设计 内聚分类 2009 91 Software Engineering Group l偶然内聚：一组任务关系松散（低） l逻辑内聚：一组任务在逻辑上同属一类，例如均为输出（ 低） l时间内聚：一组任务必须在同一段时间内执行（低） l信息内聚：模块内所有元素都引用相同的输入或输出数据 集合（中） l顺序内聚：模块中的每个元素都是与同一功能紧密相关， 一个元素的输出是下一个元素的输入（高） l功能内聚：一个模块完成一个且仅完成一个功能（高） 1.4 概要设计 关于耦合性和内聚性的设计原则 2009 92 Sof

40、tware Engineering Group l力争尽可能弱的耦合性：尽量使用数据耦合，少 用控制耦合，限制公共环境耦合的范围，完全不 用内容耦合 l力争尽可能高的内聚性：力争尽可能高的内聚性 ，并能识别出低内聚性 1.4 概要设计 5、概要设计的启发式准则 2009 93 Software Engineering Group l改进软件结构，提高模块独立性 l模块规模应该适中（最好能写在一页纸上） l大模块分解不充分；小模块使用开销大，接口复杂 。 l尽量减少高扇出结构的数目，随着深度的增加争取 更多的扇入 l扇出过大意味着模块过分复杂，需要控制和协调过 多的下级模块。一般来说，顶层扇出高

41、，中间扇出 少，低层高扇入。 1.4 概要设计 l模块的作用范围保持在该模块的控制范围内 模块的作用范围是指该模块中一个判断所影 响的所有其它模块；模块的控制范围指该模块本 身以及所有直接或间接从属于它的模块。 l力争降低模块接口的复杂程度 模块接口的复杂性是引起软件错误的一个主 要原因。接口设计应该使得信息传递简单并且与 模块的功能一致。 2009 94 Software Engineering Group 1.4 概要设计 l设计单入口单出口的模块 避免内容耦合，易于理解和维护。 l模块的功能应该可以预测 相同的输入应该有相同的输出，否则难以理 解、测试和维护。 2009 95 Softw

42、are Engineering Group 1.4 概要设计 6、设计方法 2009 96 Software Engineering Group n结构化程序设计（Dijkstra） 结构化程序设计的基础建立在三种能够构成结构化程序 的逻辑构造（顺序，选择，重复）上。 n面向数据的设计方法 面向数据流的设计 面向数据结构的设计 1.4 概要设计 面向数据流的设计 2009 97 Software Engineering Group l面向数据流的设计方法把信息流映射成软件结构 l信息流的类型决定了映射的方法 l信息流有两种类型：变换流、事务流 1.4 概要设计 变换流 2009 98 Soft

43、ware Engineering Group 信息沿输入通路进入系统，同时由外部形式变 换成内部形式。进入系统的信息通过变换中心 ，经过加工处理以后再沿着输出通路变换成外 部形式离开系统。 1.4 概要设计 信息 外部表示 内部表示 时间 输入流输出流 变换中心 2009 99 Software Engineering Group 1.4 概要设计 2009 100 Software Engineering Group 事务流的特点是数据沿着接收通路把外部世界的 信息转换成一个事务项，然后，计算该事务项的 值，根据它的值激励起多条活动通路中的一条数 据流。发出多条通路的信息流中枢被称为“事务中

44、 心”。 事务流 1.4 概要设计 T 事务 事务中心 活动通路 2009 101 Software Engineering Group 1.4 概要设计 l第1步 复查基本系统模型。 l第2步 复查并精化数据流图。 l第3步 确定数据流图具有变换特性还是事务特性。 l第4步 确定输入流和输出流的边界，从而孤立出变 换中心。 2009 102 Software Engineering Group 变换型分析 1.4 概要设计 2009 103 Software Engineering Group l第5步 完成“第一级分解”。 软件结构代表对控制的自顶向下的分配，所谓分解就 是分配控制的过程。

45、 对于变换流，数据图将被映射成一个特殊的软件结构 ，这个结构控制输入、变换和输出信息等处理过程：位于 软件结构最顶层的控制模块Cm协调下述从属的控制功能： （1）输入信息处理控制模块Ca，协调对所有输入数据的 接收； （2）变换中心控制模块Ct，管理对内部形式的数据的所 有操作； （3）输出信息控制模块Ce，协调输出信息的产生过程。 1.4 概要设计 Cm CtCaCe 2009 104 Software Engineering Group 1.4 概要设计 l第6步 完成“第二级分解”。 把数据流图中的每一个处理映射成软件结构中一个 适当的模块：从变换中心的边界开始沿着输入通路向外 移动，把

46、输入通路中每个处理映射成软件结构中Ca控制 下的一个低层模块；然后沿输出通路向外移动，把输出 通路中每个处理映射成直接或间接受Ce控制的一个低层 模块；最后把变换中心内的每个处理映射成受Ct控制的 一个模块。 l第7步 使用设计度量和启发式规则对得到的软件 结构进一步精化。 2009 105 Software Engineering Group 1.4 概要设计 B C D A Cm Ca BC A D 2009 106 Software Engineering Group 1.4 概要设计 l第1步 复查基本系统模型。 l第2步 复查并精化数据流图。 l第3步 确定数据流图具有变换特性还是事

47、务特 性。 l第4步 确定事务中心和每个活动通路的流程特 征。 2009 107 Software Engineering Group 事务型分析 1.4 概要设计 l第5步 把数据流图映射成一个适合于事务处理 的软件结构。 l第6步 对事务中心的结构和每个活动通路的结 构进行分解、合并和改进。 l第7步 使用设计度量和启发式规则对得到的软 件结构进一步精化。 2009 108 Software Engineering Group 1.4 概要设计 C通路 A通路 D G F E 接收通路 B通路 总控 E 调度 D G A-CTLB-CTL C-CTL F 2009 109 Software

48、 Engineering Group 1.4 概要设计 面向数据结构的设计： 2009 110 Software Engineering Group l面向数据结构的设计方法用信息结构导出程序过程 l面向数据结构的设计过程分为如下几步： （1）分析数据结构的特性； （2）用一些基本类型（如：顺序，选择和重复）来描述数 据； （3）把数据结构表示映射成软件的控制层次； （4）利用一组规则改进软件的层次结构； （5）最后得到软件的过程性描述。 1.4 概要设计 lJackson方法的精髓在于：应该把问题分解成仅 用三种结构化形式（顺序，选择和重复）来表示 的层次结构。 lJackson方法包括一种

49、数据结构符号和一组映射 或转换步骤。 2009 111 Software Engineering Group Jackson方法 1.4 概要设计 uJackson图（数据结构符号） ： A AA C#D#B*CDB#B 顺序重复选择 A seq do B; do C; do D; A end A iter do B; A end A select do B; A or do C; A or do D; A end 2009 112 Software Engineering Group 1.4 概要设计 uJackson图的特点： 2009 113 Software Engineering Group l便于表示层次结构，而且是对结构进行自顶向下 分解的有力工具； l形象直观，可读性好； l既能表示数据结构，又能表示程序结构。 1.4 概要设计 u建立程序结构 姓名年龄类别状态 这里类别可以是“教师”或“学生”两种。“状态”一项，如果 是教师则印出他的“工龄”，如果是学生则印出他的年级。 2009 114