【文档说明】软件工程软件设计概述lyh课件.ppt，共(84)页，750.000 KB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-50499.html

以下为本文档部分文字说明：

第四章软件设计概述第1页，共84页。讨论要点•如何将分析模型转换成软件设计？•作为软件工程师在软件设计方面应使用哪些基本原则和概念？第2页，共84页。§4.1软件设计的目标和任务§4.2软件设计基本概念§4.

3模块化设计§4.4其他设计问题的处理§4.5设计文档及其复审教学内容：第3页，共84页。教学目的及要求：深刻理解软件设计阶段的概念和任务；掌握模块化设计的思想；第4页，共84页。§4.1软件设计的任务软件需求：解决“做什么”软件设计：解决“怎么做”第5页，共84页。软件设计的任务•问

题结构(软件需求)•从软件需求规格说明书出发，形成软件的具体设计方案。映射软件结构第6页，共84页。1.软件的总体结构主要回答的问题软件的组成部分软件的层次关系模块的内部处理逻辑模块之间的界面第7页，共84页。2.软件设计的问题工具—如何

描述软件的总体结构方法—用什么方法从问题结构导出软件结构评估准则—什么样的软件结构是“最优的”第8页，共84页。3.软件设计方法结构化设计方法(SD)面向数据结构的设计方法(JSD方法)面向对象的设计方法(OOD)第9页，共84页。4.软件设计分为两个阶段：(1)概要设计(总

体设计)确定软件的结构以及各组成成分(子系统或模块)之间的相互关系。(2)详细设计确定模块内部的算法和数据结构，产生描述各模块程序过程的详细文档。第10页，共84页。§4.2软件设计的基本概念1.模块与构件2.抽象与细化3.信息隐蔽4.软件复用第

11页，共84页。1.模块与构件模块化：把程序划分成若干个模块，每个模块完成一个子功能，把这些模块集总起来组成一个整体，可以完成指定的功能，满足问题的功能。模块：一个拥有明确定义的输入、输出和特性的程序实体。第12页，共84页。1.模块与构件构件：可重复使用的软件

组件。经过适当设计和实现的类也可以称为构件，他们在某个领域中具有一定的通用性，可以在不同的计算机软件系统中复用。将这些构件储存起来变成一个构件库，就为基于构件的软件开发模型提供了技术基础。第13页，共84页。模块•

模块是具有一定功能的可以用名词调用的程序语句集合，如：–独立的汇编程序–COBOL的段和节–Pascal过程–FORTRAN的子程序第14页，共84页。概要设计的基本概念•将系统划分成模块•决定每个模块的功能•决定模块的调用关系•决定模块的界面，即

模块间传递的数据第15页，共84页。2.抽象(Abstraction)与细化抽象:解决问题时只考虑与问题有关的方面，不考虑与问题无关的方面。即抽出事物的本质特性而不考虑细节。第16页，共84页。抽象(Abstraction)抽象原则应用举例WindowsN

T一体化的I/O系统设计文件管理网络管理设备管理高速缓冲存储器ＯＳ对虚拟文件的字节流,虚拟文件可为任何设备和实体抽象第17页，共84页。•在逐步细化中，特别强调这种分解的“逐步”性质，即每一部分仅较其前一部增加“少量”的

细节。这样，在相邻两部之间就只有微小的变化，不难验证它们的内容是否等效。细化：即分解。第18页，共84页。3.信息隐蔽(InformationHiding)信息隐蔽的含义：有效的模块化可以通过定义一组独立模块来实现，这些模块相互之间只

交流软件功能必需的信息。换句话说：模块所包含的信息，不允许其它不需要这些信息的模块访问，独立的模块间仅仅交换为完成系统功能而必须交换的信息。信息隐蔽：对模块内部信息访问的约束信息隐蔽的基本原则：功能独立，高内聚且低耦合第19页，共84页。高可复用

性的期望：•功能复用是代码级的，它基于必要的功能理解，而功能的语义是不一致的、多理解的。•希望软件复用是全方位的，不但是代码级的复用，还应该有源程序级的复用。面向对象方法的高可复用性：对象的语义表示是唯一的，这使得代码级的复用简单且自然。类的继承性是源程序级的复用机制，

它允许用已有的程序构架来简单地构造新的应用。并且仍保持高维护性，这种技术带来复用概念的新突破。4.软件复用：利用已有的现成构件，不必一切都从头做起。第20页，共84页。§4.3模块化设计1.分解2.模块独立性内聚耦合自顶向下与自底向上设计第21页，共84页。模块化(Modular

ity)模块化是好的软件设计的一个基本准则从整体上把握问题,隐蔽细节复杂问题较小问题分解可减小解题所需的总的工作分解第22页，共84页。C(p1)>C(p2)则E(p1)>E(p2)其中：p1和p2是两个问题C(x)是由x问题决定的复杂性E(x)是解决x

问题所需要的工作量C(p1+p2)>C(p1)+C(p2)E(p1+p2)>E(p1)+E(p2)试验发现模块划分得越小成本越低，但是集成成本却随着模块划分得越小成本越高。如何确定模块化分的最小成本区，并保证模块的最佳性能，是设计活

动中的主要任务之一。1.分解＂各个击破＂理论第23页，共84页。模块数与开发工作量的关系成本或工作量模块数量软件总成本集成成本成本/模块M最小成本区域第24页，共84页。2.模块的独立性①模块独立性的概念•模块完成独立的功能•符合信

息隐蔽和信息局部化原则•模块间关连和依赖程度尽量小第25页，共84页。②模块独立性的度量•模块独立性取决于模块的内部和外部特征。•SD方法提出的定性的度量标准：•模块自身的内聚性•模块之间的耦合性第26页，共84页。•内容耦合：一个模块直接修改另一个模块的内容•公共耦合：两个以

上的模块共同引用一个全局数据•外部耦合：若允许一组模块访问同一个全局变量•控制耦合：接收模块的动作依赖于控制信号•标记耦合：两个模块接口的参数包含相同的内部结构•数据耦合：仅是模块之间的数据传递•非直接耦合：模块之间没有消息传递低高耦合----模块之间的依赖程度第27页，共84页。•

偶然内聚：各成分之间并没有关系，只是把分散在多处的功能合在一起•逻辑内聚：仅仅是逻辑功能相关成分合在一起•时间内聚：必须在同一时间执行，并无功能逻辑的成分合在一起•过程内聚：过程顺序相关的功能成分合在一起•通讯内聚：需要对相同的外部数据进行操作的成分合在一起•顺序内聚

：一个内部成分的输出是另一个内部成分的输入，将它们合起来•功能内聚：只完成单一的功能低高内聚----模块内部各成分之间的关联程度第28页，共84页。2.模块独立性的度量之一：内聚性一个模块内部各成分之间相互关联的强度设计目标：高内聚

(一模块的所有成分都直接参与并且对于完成同一功能来说都是最基本的)第29页，共84页。软件设计的概念和原理内聚：一个模块内各个元素彼此结合的紧密程度。偶然内聚：一个模块完成一组任务，任务之间的关系很松散。公

共语句。逻辑内聚：若干个逻辑功能类似的任务组成一个模块。时间内聚：若干个任务必须在同一段时间内执行。如初始化工作。低内聚中内聚高内聚过程内聚：模块内的处理元素是相关的，且必须以特定次序执行。通信内聚：模块中所有元素都使用同一个输入数据，和/或产生同一个输出数据。顺序内聚：模块中所有处理元素和同

一个功能密切相关，且这些处理必须顺序执行。功能内聚：所有处理元素属于一个整体，完成一个单一的功能。模块A模块B模块CS1;S2;模块A模块B模块C模块A模块B模块C模块D第30页，共84页。模块的内聚性类型模块独立性弱(功能分散)强(功能单一)巧合内聚逻辑内聚时

间内聚过程内聚通信内聚信息内聚功能内聚低高内聚性第31页，共84页。(1)巧合内聚(偶然内聚)模块内各部分间无联系ABCMMOVEOTORREADFILEFMOVESTOT模块M中的三个语句没有任何联系缺点

：可理解性差，可修改性差。例:第32页，共84页。(2)逻辑内聚把几种相关功能(逻辑上相似的功能)组合在一模块内,每次调用由传给模块的参数确定执行哪种功能。第33页，共84页。逻辑内聚模块ABCEFGABCEFGA1B1C1EFG模块内部逻辑E、F、G逻辑功能相似，组成新模块EFG公用代码段公

用代码段缺点：增强了耦合程度（控制耦合）不易修改，效率低。第34页，共84页。(3)时间内聚模块完成的功能必须在同一时间内执行，这些功能只因时间因素关联在一起。例如：初始化系统模块、系统结束模块、紧急故障处理模块等。第3

5页，共84页。(4)过程内聚模块内各处理成分相关，且必须以特定次序执行。第36页，共84页。过程内聚模块建立方程组系数矩阵全部任务纳入一个模块，得到一过程性模块高斯消去法回代高斯消去法解题流程第37页，共84页。过程内

聚模块读入成绩单读入并审查成绩单审查成绩单统计成绩打印成绩统计并打印成绩第38页，共84页。(5)通信内聚模块内各部分使用相同的输入数据，或产生相同的输出结果。第39页，共84页。通信内聚模块例产生工资报表计算平均工资职工工资记录职工工资报表

平均工资产生职工工资报表并计算平均工资模块第40页，共84页。通信内聚模块例开领书单登记售书发票领书单售书登记表文件删除修改第41页，共84页。(6)顺序内聚一个内部成分的输出是另一个内部成分的输入，将它们合起来。建立方程组系数矩阵高斯消去法回代高斯消去法解题

流程第42页，共84页。(7)功能内聚模块仅包括为完成某个功能所必须的所有成分。(模块所有成分共同完成一个功能，缺一不可)内聚性最强第43页，共84页。模块独立性的度量之二耦合性是模块间相互依赖程度的度量，耦合的强弱取决于模块间接口的复杂程度，进入或访问一

个模块的点，以及通过接口的数据。耦合性越高，模块独立性越弱第44页，共84页。软件设计的概念和原理----耦合1.非直接耦合2.数据耦合3.特征耦合4.控制耦合5.外部耦合6.公共耦合7.内容耦合弱耦合中耦合较强耦合强耦合模块1模块2模块3模块4数据耦合通过简单变量交换数据特征耦合通

过数据结构交换数据非直接耦合模块之间没有信息传递模块A模块B模块C模块D模块L模块N全局性数据结构公共耦合Flag=1?S1S2模块1控制耦合模块之间传递的是控制信息TF全局性简单变量外部耦合模块A模块B内容耦合•访问其

它模块的内部数据•直接跳到其他模块内部执行第45页，共84页。无耦合－没有依赖关系松散耦合－有少量依赖关系紧密耦合－有很多依赖关系第46页，共84页。耦合强度依赖的因素一模块对另一模块的引用一模块向另一模块传递的数据量

一模块施加到另一模块的控制的数量模块间接口的复杂程度第47页，共84页。(1)非直接耦合两个模块没有直接关系(模快1和模快2)，模块独立性最强。模块1模块2模块3模块4第48页，共84页。(2)数据耦合一模块调用另一模块时，被调用模块的输入、输出都是简

单的数据，属松散耦合。开发票计算水费单价数量金额第49页，共84页。数据耦合举例计算水电费计算水费计算电费用水量用电量水费电费第50页，共84页。(3)标记耦合(特征耦合)如两个模块通过传递数据结构(不是简单

数据，而是记录、数组等)加以联系，或都与一个数据结构有关系,则称这两个模块间存在标记偶合。第51页，共84页。标记耦合举例计算水电费计算水费计算电费住户情况水费电费住户情况“住户情况”是一个数据结构，图中

模块都与此数据结构有关。“计算水费”和“计算电费”本无关，由于引用了此数据结构产生依赖关系，它们之间也是标记偶合。第52页，共84页。将标记耦合修改为数据耦合举例计算水电费计算水费计算电费本月用水量本月用电量水费电费第53页，共84页。(4)控制耦合一模块通

过开关量、标志、名字等控制信息，明显地控制另一模块的功能。A计算平均分或最高分B平均/最高成绩第54页，共84页。控制耦合举例读入分数输出结果计算平均分计算最高分平均/最高?调用逻辑性模块B时，须先传递控制信号(平均分/最高分)，以选择所需的操作。控制模块必须知道被控模块的内部逻辑，增强了相

互依赖。B第55页，共84页。控制耦合增加了理解和编程的复杂性，调用模块必须知道被调模块的内部逻辑，增加了相互依赖。去除模块间控制耦合的方法：(1)将被调用模块内的判定上移到调用模块中进行；(2)被调用模块分解成若干单一功能模块。第56页，共84页。改控制耦合为

数据耦合举例A计算平均分B1平均成绩最高成绩计算最高分B2第57页，共84页。控制耦合举例A发奖牌名次(开关量)奖牌控制耦合被调用模块内处理逻辑模式功能A功能B判别第58页，共84页。改控制耦合为数据耦合举例A发金牌发银牌发铜牌第59页，共84页。(5)外

部耦合一组模块均与同一外部环境关联(例如，I/O模块与特定的设备、格式和通信协议相关联)，它们之间便存在外部耦合。外部偶合必不可少，但这种模块数目应尽量少。第60页，共84页。(6)公共耦合(公共数据区耦合)一组模块引用同一个公用数据区(也称全局数据区、公共数据环境

)。公共数据区指：–全局数据结构–共享通讯区–内存公共覆盖区等第61页，共84页。公共耦合举例Ａｃｏｍｍｏｎ公共数据区松散的公共耦合ＢＡｃｏｍｍｏｎ公共数据区紧密的公共耦合Ｂ第62页，共84页。公共耦合举例Ａ公共数据区CB

模块A、B、C间存在错综复杂的联系第63页，共84页。公共耦合举例所有的公共耦合关系AEBCD6个模块共享一个公共数据区F第64页，共84页。(1)软件可理解性降低(模块间存在错综复杂的连系)(2)软件可维护性差(修改变量名或属性困难)(3)软件可靠性差(公共数据区及全程变量无保

护措施)慎用公共数据区和全程变量!!!公共耦合存在的问题：第65页，共84页。(7)内容耦合一模块直接访问另一模块的内部信息(程序代码或数据)。最不好内容耦合形式!!!第66页，共84页。发生内容耦合的情形(1)一模块直接访问另一模块的

内部数据(2)一模块不通过正常入口转到另一模块内(3)两模块有一部分代码重叠(4)一模块有多个入口第67页，共84页。模块化设计的原则和目标耦合是影响软件复杂程度和设计质量的重要因素目标：建立模块间耦

合度尽可能松散的系统。第68页，共84页。如何降低模块间耦合度？(1)如模块必须存在耦合，选择适当的耦合类型原则：尽量使用数据耦合少用控制耦合限制公共耦合的范围坚决避免使用内容耦合(2)降低模块间接口的复杂性第69页，共84页。接口复杂性与

耦合类型的关系接口复杂性接口方式接口数据的复杂性无接口关系直接引用过程调用语句数据项作参数数据结构，变量名作参数内容耦合其它耦合开关量，起控制变量作用公用数据区数据耦合标记耦合控制耦合外部耦合公共耦合非直接耦

合第70页，共84页。内聚与耦合密切相关，同其它模块强耦合的模块意味着弱内聚，强内聚模块意味着与其它模块间松散耦合。设计目标：力争强内聚、弱耦合。第71页，共84页。耦合、内聚与模块独立性关系耦合与内聚都是模块独立性的定性标准，都反映模块独立性的良好程度。但耦合是直接的主导因素

，内聚则辅助耦合共同对模块独立性进行衡量。第72页，共84页。3.自顶向下与自底向上设计（1）自底向上设计（Bottom-UpDesign)从一个局部开始，逐渐扩展到整个系统的设计方法。（2）自顶向下设计（Up-Botto

mDesign）首先对所设计的系统要有一个全面的理解。然后从顶层开始，连续地逐层向下分解，直至系统的所有模块都小到便于掌握为止。（3）两种设计的比较（Page79）第73页，共84页。§4.4其他设计问题•协同设计•用户界面设计•并发系统设计第74页，共84页。协同设计必须处理好的问题：1

）谁最合适设计系统的某一方面？2）如何编写文档使组内人员相互了解别人的设计？3）如何协调设计组件使整个系统统一？注意：在实施协同设计中，需要注意的一个主要问题是设计者的个人经验、理解和偏爱的不同。第75页，共84页。用户

界面设计•三条黄金指导规则（课本79页）第76页，共84页。并发系统设计•什么是并发？——允许多个活动同时发生而不互相干扰•如何确保同时执行的组件间对共享数据的一致性？第77页，共84页。§4.5设计文档及其

复审（P81）•软件设计说明书•设计复审第78页，共84页。讨论：编程时是否应该多使用技巧？本人观点：就软件开发而言，技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不为人熟知。若在程序中用太多的技巧，可能

会留下隐患，别人也难以理解程序。鉴于一个局部的优点对整个系统而言是微不足道的，而一个错误则可能是致命的。作者建议用自然的方式编程，少用技巧。《狼三则》的故事告诉我们“失败的技巧通常是技俩”。当我们在编程时无法判断是用了

技巧还是用了技俩，那就少用。《卖油翁》的故事又告诉我们“熟能生巧”，表明技巧是自然而然产生的，而不是卖弄出来的。卖油翁的绝技是可到中央电视台表演的，而他老人家却谦虚地说：“没啥没啥，用熟了而已”。第79页，共84页。聪明人一定反应敏捷，善于接受新事物。他能迅速进入一

个新领域，给你一个头头是道的解释。他提出的问题往往一针见血、击中要害。他能及时掌握所学知识，并且博闻强记，他能把本来认为互不相干的领域联系在一起使问题得到解决。他富有创新精神与合作精神……比尔·盖茨曾这样描述聪明[Cusumano1996]

：第80页，共84页。好的程序经理应该具备以下几个条件：•一、技术水平是程序员队伍中的最高级别•每个程序员骨子里头都有一股傲气，如果你不能技压群雄，他们就不会听你指挥。一个技术水平较差的人被任命为程序经理真是个悲剧，就

象一个略有权势的太监，表面上有人对他点头哈腰，背后却被人鄙视。•二、能做最多且最难的工作•程序经理编程要快且好。别人要干一天的活，他半天就能做完，这样才会有精力去搞管理。程序经理应负责系统分析、系统设计这类最难的开发工作，并指导不同水平的程序员把各自的工作做好。如果人手不够，程

序经理要能同时干几个人的活。第81页，共84页。•三、有人格魅力•软件开发是智力创作过程，你不能指望仅通过执行规章制度来产生好的作品。很多软件公司的程序经理都不是管理专业出身的，他们也不可能为了搞好管理而成天玩弄心机。技术出色的程序经理一般少有心术

不正的，所以管理的重点应是“以身作则”、“公正待人”。如果程序经理在上班时趴在桌上睡觉，其他程序员也会这样干。如果程序经理发现有两个程序员趴在机器旁睡觉，不能只对其中一个大声吼叫：“你一编程就想睡觉，看看人家，在睡觉时都想着编程。”•如果管理者没有人格

魅力，就没有人信服你，团队就不会有凝聚力，乌合之众不可能开发出优秀的软件。•结论：一个有活力的软件公司的各级经理都不会这样感叹，“因为我啥也不会干，所以只好当领导。”第82页，共84页。程序员升为经理后是否还要编程？•让我们先看看Microsoft公司的系统软件部门与应用软件部门的领导是

怎样看待这个问题的[Cusumano1996]。WindowsNT3.0项目的软件经理娄·帕雷罗里让他手下的经理们像他一样每天花一半的时间编写代码：–我在组内制定了许多规则，其中最重要的一条是每个人都得编程，谁也别想坐在那儿发号施令……我发现管理者很容易失去目标，他们总是无法认识到

问题的本质并且反应迟缓。如果你始终不放弃编写代码，你就能对项目的进展情况了如指掌，及时发现并解决问题……我大概每天花一半的时间编写代码并寻找项目的缺陷。第83页，共84页。•作为应用软件领域的经理，克里

斯·彼得斯也持同样的看法。在他任Word项目总经理时就认为：•在一些大公司内部，各部门经理把具体操作的层次向下移。你一旦当上开发部门经理，很快就会以自己身居高位、日理万机为由放弃编程；同样地，开发小组的组长会以自己重任在肩而不愿编程；至于程

序员也会觉得自己十分繁忙、分身无术而不再多编写程序。虽然我是270名员工的领导，似乎不再需要做什么具体的工作了，但我还是为Word新版本编写了一个特性•程序员升为经理后一定要编程，这个道理已经说得很清

楚了。最怕的是“虚心接受，坚决不做”；或者仅是做个样子，每天花一分钟时间编程，编译器还没运行完就关掉了。第84页，共84页。