1、 第1页，共84页。讨论要点讨论要点如何将分析模型转换成软件设计？如何将分析模型转换成软件设计？作为软件工程师在软件设计方面应使用哪些基本原作为软件工程师在软件设计方面应使用哪些基本原则和概念？则和概念？第2页，共84页。4.1 4.1 软件设计的目标和任务软件设计的目标和任务4.2 4.2 软件设计基本概念软件设计基本概念4.3 4.3 模块化设计模块化设计4.4 4.4 其他设计问题的处理其他设计问题的处理4.5 4.5 设计文档及其复审设计文档及其复审第3页，共84页。第4页，共84页。4.1 4.1 软件设计的任务软件设计的任务 软件需求：解决软件需求：解决“做什么做什么”软件设计：解
2、决软件设计：解决“怎么做怎么做”第5页，共84页。软件设计的任务软件设计的任务 问题结构问题结构(软件需求软件需求)从软件需求规格说明书出发，形成软件的具体设计方从软件需求规格说明书出发，形成软件的具体设计方案。案。映射映射 软件结构软件结构第6页，共84页。1.1.软件的总体结构主要回答的问题软件的总体结构主要回答的问题u软件的组成部分软件的组成部分u软件的层次关系软件的层次关系u 模块的内部处理逻辑模块的内部处理逻辑u模块之间的界面模块之间的界面第7页，共84页。2.2.软件设计的问题软件设计的问题 u工具工具 如何描述软件的总体结构如何描述软件的总体结构u方法方法 用什么方法从问题结构导
3、出软件结构用什么方法从问题结构导出软件结构u评估准则评估准则 什么样的软件结构是什么样的软件结构是“最优的最优的”第8页，共84页。3.3.软件设计方法软件设计方法F结构化设计方法结构化设计方法(SD)(SD)F面向数据结构的设计方法面向数据结构的设计方法(JSD(JSD方法方法)F面向对象的设计方法面向对象的设计方法(OOD)(OOD)第9页，共84页。4.4.软件设计分为两个阶段：软件设计分为两个阶段：(1)(1)概要设计概要设计(总体设计总体设计)确定软件的结构以及各组成成分确定软件的结构以及各组成成分(子系统或模块子系统或模块)之间的相互关系。之间的相互关系。(2)(2)详细设计详细设
4、计 确定模块内部的算法和数据结构，产生描述各模确定模块内部的算法和数据结构，产生描述各模 块程序过程的详细文档。块程序过程的详细文档。第10页，共84页。4.2 4.2 软件设计的基本概念软件设计的基本概念1.1.模块与构件模块与构件2.2.抽象与细化抽象与细化3.3.信息隐蔽信息隐蔽4.4.软件复用软件复用第11页，共84页。1.1.模块与构件模块与构件模块化：模块化：把程序划分成若干个模块，每个模块完把程序划分成若干个模块，每个模块完成一个子功能，把这些模块集总起来组成一个整成一个子功能，把这些模块集总起来组成一个整体，可以完成指定的功能，满足问题的功能。体，可以完成指定的功能，满足问题的
5、功能。模块：模块：一个拥有明确定义的输入、输出和特性的一个拥有明确定义的输入、输出和特性的程序实体。程序实体。第12页，共84页。1.1.模块与构件模块与构件构件：构件：可重复使用的软件组件。可重复使用的软件组件。经过适当设计和实现的类也可以称为经过适当设计和实现的类也可以称为构件构件，他们在，他们在某个领域中具有一定的通用性，可以在不同的计算机软某个领域中具有一定的通用性，可以在不同的计算机软件系统中复用。将这些构件储存起来变成一个构件库，件系统中复用。将这些构件储存起来变成一个构件库，就为基于构件的软件开发模型提供了技术基础。就为基于构件的软件开发模型提供了技术基础。第13页，共84页。模
6、模 块块 模块模块是具有一定功能的可以用名词调用的程序语句是具有一定功能的可以用名词调用的程序语句集合，如：集合，如：独立的汇编程序独立的汇编程序COBOLCOBOL的段和节的段和节PascalPascal过程过程FORTRANFORTRAN的子程序的子程序第14页，共84页。概要设计的基本概念概要设计的基本概念将系统划分成模块决定每个模块的功能决定模块的调用关系决定模块的界面，即模块间传递的数据第15页，共84页。2.2.抽象抽象(Abstraction)(Abstraction)与细化与细化 抽象抽象:解决问题时只考虑与问题有关的方面，不考虑与解决问题时只考虑与问题有关的方面，不考虑与问题
7、无关的方面。即抽出事物的本质特性而不考虑细节。问题无关的方面。即抽出事物的本质特性而不考虑细节。第16页，共84页。抽象抽象(Abstraction)(Abstraction)抽象原则应用举例抽象原则应用举例Windows NTWindows NT一体化的一体化的I/OI/O系统设计系统设计文件管理文件管理网络管理网络管理设备管理设备管理高速缓冲存储器高速缓冲存储器对虚拟文件的字节流对虚拟文件的字节流,虚拟文件可为任何设虚拟文件可为任何设备和实体备和实体抽象抽象第17页，共84页。在逐步细化中，特别强调这种分解的在逐步细化中，特别强调这种分解的“逐步逐步”性质，即性质，即每一部分仅较其前一部增
8、加每一部分仅较其前一部增加“少量少量”的细节。这样，在相的细节。这样，在相邻两部之间就只有微小的变化，不难验证它们的内容是否邻两部之间就只有微小的变化，不难验证它们的内容是否等效。等效。细化：即分解。细化：即分解。第18页，共84页。3.3.信息隐蔽信息隐蔽(Information Hiding)(Information Hiding)信息隐蔽的含义：信息隐蔽的含义：有效的模块化可以通过定义一组独立模块有效的模块化可以通过定义一组独立模块来实现，这些模块相互之间只交流软件功能必需的信息。来实现，这些模块相互之间只交流软件功能必需的信息。换句话说：换句话说：模块所包含的信息，不允许其它不需要这些
9、信息模块所包含的信息，不允许其它不需要这些信息的模块访问，独立的模块间仅仅交换为完成系统功能而必的模块访问，独立的模块间仅仅交换为完成系统功能而必须交换的信息。须交换的信息。信息隐蔽：对模块内部信息访问的约束信息隐蔽的基本原则：功能独立，高内聚且低耦合第19页，共84页。高可复用性的期望：功能复用是代码级的，它基于必要的功能理解，而功能的语义是不一致的、多理解的。希望软件复用是全方位的，不但是代码级的复用，还应该有源程序级的复用。面向对象方法的高可复用性：对象的语义表示是唯一的，这使得代码级的复用简单且自然。类的继承性是源程序级的复用机制，它允许用已有的程序构架来简单地构造新的应用。并且仍保持
10、高维护性，这种技术带来复用概念的新突破。4.4.软件复用：软件复用：利用已有的现成构件，不必一切都从头做起。利用已有的现成构件，不必一切都从头做起。第20页，共84页。4.3 4.3 模块化设计模块化设计1.1.分解分解2.2.模块独立性模块独立性 内聚内聚 耦合耦合 自顶向下与自底向上设计自顶向下与自底向上设计第21页，共84页。模块化模块化(Modularity)(Modularity)模块化是好的软件设计的一个基本准则模块化是好的软件设计的一个基本准则 高层模块高层模块 从整体上把握问题从整体上把握问题,隐蔽细节隐蔽细节 复杂问题复杂问题 较小问题较小问题 分解分解 可减小解题所需的总的
11、工作可减小解题所需的总的工作分解分解第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)试验发现模块划分得越小成本越低模块划分得越小成本越低，但是，但是 集成成本集成成本却随着模块划分得越小成本越高。却随着模块划分得越小成本越高。如何确定模块化分的最小成本区，并保证模块的最佳性能，是设计活动如何确定模块化分的最小成本区，并保证模块的最佳性能，是设计活动中的
12、主要任务之一。中的主要任务之一。1.1.分解分解各个击破理论各个击破理论第23页，共84页。模块数与开发工作量的关系模块数与开发工作量的关系成成本本或或工工作作量量模块数量模块数量软件总成本软件总成本集成成本集成成本成本成本/模块模块M最小成本区域最小成本区域第24页，共84页。2.模块的独立性模块的独立性模块独立性的概念模块独立性的概念模块完成独立的功能模块完成独立的功能符合信息隐蔽和信息局部化原则符合信息隐蔽和信息局部化原则模块间关连和依赖程度尽量小模块间关连和依赖程度尽量小第25页，共84页。模块独立性的度量模块独立性的度量 模块独立性取决于模块的内部和外部特征。模块独立性取决于模块的内
13、部和外部特征。SDSD方法提出的定性的度量标准：方法提出的定性的度量标准：模块自身的内聚性模块自身的内聚性 模块之间的耦合性模块之间的耦合性 第26页，共84页。内容耦合：一个模块直接修改另一个模块的内容 公共耦合：两个以上的模块共同引用一个全局数据 外部耦合：若允许一组模块访问同一个全局变量 控制耦合：接收模块的动作依赖于控制信号 标记耦合：两个模块接口的参数包含相同的内部结构 数据耦合：仅是模块之间的数据传递非直接耦合：模块之间没有消息传递低低高高耦合-模块之间的依赖程度第27页，共84页。偶然内聚：各成分之间并没有关系，只是把分散在多处的功能合在一起 逻辑内聚：仅仅是逻辑功能相关成分合在
14、一起 时间内聚：必须在同一时间执行，并无功能逻辑的成分合在一起 过程内聚：过程顺序相关的功能成分合在一起 通讯内聚：需要对相同的外部数据进行操作的成分合在一起 顺序内聚：一个内部成分的输出是另一个内部成分的输入，将它们合起来 功能内聚：只完成单一的功能低低高高内聚-模块内部各成分之间的关联程度第28页，共84页。2.模块独立性的度量之一：内聚性模块独立性的度量之一：内聚性 一个模块内部各成分之间相互关联的强度一个模块内部各成分之间相互关联的强度 设计目标：高内聚设计目标：高内聚(一模块的所有成分都直接参与并且一模块的所有成分都直接参与并且对于完成同一功能来说都是最基本的对于完成同一功能来说都是
15、最基本的)第29页，共84页。软件设计的概念和原理内聚：一个模块内各个元素彼此结合的紧密程度。偶然内聚：一个模块完成一组任务，任务之间的关系很松散。公共语句。逻辑内聚：若干个逻辑功能类似的任务组成一个模块。时间内聚：若干个任务必须在同一段时间内执行。如初始化工作。低内聚中内聚高内聚过程内聚：模块内的处理元素是相关的，且必须以特定次序执行。通信内聚：模块中所有元素都使用同一个输入数据，和/或产生同一个 输出数据。顺序内聚：模块中所有处理元素和同一个功能密切相关，且这些处理必 须顺序执行。功能内聚：所有处理元素属于一个整体，完成一个单一的功能。模块A模块B模块CS1;S2;模块A模块B模块C模块A
16、模块B模块C模块D第30页，共84页。模块的内聚性类型模块的内聚性类型模模块块独独立立性性弱弱(功能分散功能分散)强强(功能单一功能单一)巧合内聚巧合内聚逻辑内聚逻辑内聚时间内聚时间内聚过程内聚过程内聚通信内聚通信内聚信息内聚信息内聚功能内聚功能内聚低低 高高 内聚性内聚性第31页，共84页。(1)(1)巧合内聚巧合内聚(偶然内聚偶然内聚)模块内各部分间无联系模块内各部分间无联系ABCMMOVE O TO RREAD FILE FMOVE S TO T模块模块M中的三个语句没有任何联系中的三个语句没有任何联系缺点：缺点：可理解性差，可理解性差，可修改性差。可修改性差。例例:第32页，共84页。
17、(2)(2)逻辑内聚逻辑内聚把几种相关功能把几种相关功能(逻辑上相似的功能逻辑上相似的功能)组合在一组合在一模块内模块内,每次调用由传给模块的参数确定执行每次调用由传给模块的参数确定执行哪种功能。哪种功能。第33页，共84页。逻辑内聚模块逻辑内聚模块ABCEFGABCEFGA1B1C1EFGEFG模块内部逻辑模块内部逻辑E E、F F、G G逻辑逻辑功能相似，组功能相似，组成新模块成新模块EFGEFG公用代码段公用代码段公用代码段公用代码段缺点：增强了耦合程度（控制耦合）不易修改，效率低。缺点：增强了耦合程度（控制耦合）不易修改，效率低。第34页，共84页。(3)(3)时间内聚时间内聚模块完成
18、的功能必须在同一时间内执行，这些功能只模块完成的功能必须在同一时间内执行，这些功能只因时间因素关联在一起。因时间因素关联在一起。例如：初始化系统模块、例如：初始化系统模块、系统结束模块、系统结束模块、紧急故障处理模块等。紧急故障处理模块等。第35页，共84页。(4)(4)过程内聚过程内聚模块内各处理成分相关，且必须以特定次序执行。模块内各处理成分相关，且必须以特定次序执行。第36页，共84页。过程内聚模块过程内聚模块建立方程组系数矩阵建立方程组系数矩阵全部任务纳入一个全部任务纳入一个模块，得到一过程模块，得到一过程性模块性模块高斯消去法高斯消去法回回 代代高斯消去法解题流程高斯消去法解题流程第
19、37页，共84页。过程内聚模块过程内聚模块读入读入成绩单成绩单读入并审查读入并审查成绩单成绩单审查审查成绩单成绩单统计统计成绩成绩打印打印成绩成绩统计并打印统计并打印成绩成绩第38页，共84页。(5)(5)通信内聚通信内聚模块内各部分使用相同的输入数据，或产生模块内各部分使用相同的输入数据，或产生相同的输出结果。相同的输出结果。第39页，共84页。通信内聚模块例通信内聚模块例产生工产生工资报表资报表计算平计算平均工资均工资职工工资记录职工工资记录职工工资报表职工工资报表平均工资平均工资产生职工工资报表并计算平均工资模块产生职工工资报表并计算平均工资模块第40页，共84页。通信内聚模块例通信内聚
20、模块例开领开领书单书单登记登记售书售书发票发票领书单领书单售售 书书登记表登记表文件文件删除删除修改修改第41页，共84页。(6)(6)顺序内聚顺序内聚 一个内部成分的输出一个内部成分的输出是另一个内部成分的输是另一个内部成分的输入，将它们合起来。入，将它们合起来。建立方程组系数矩阵建立方程组系数矩阵高斯消去法高斯消去法回回 代代高斯消去法解题流程高斯消去法解题流程第42页，共84页。(7)(7)功能内聚功能内聚 模块仅包括为完成某个功能所必须的所有成分。模块仅包括为完成某个功能所必须的所有成分。(模模块所有成分共同完成一个功能，缺一不可块所有成分共同完成一个功能，缺一不可 )内聚性最强内聚性
21、最强第43页，共84页。模块独立性的度量之二模块独立性的度量之二 耦合性是模块间相互依赖程度的度量，耦合的强弱取决于模耦合性是模块间相互依赖程度的度量，耦合的强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。的数据。耦合性越高，模块独立性越弱耦合性越高，模块独立性越弱第44页，共84页。软件设计的概念和原理-耦合非直接耦合数据耦合特征耦合控制耦合外部耦合公共耦合内容耦合弱耦合中耦合较强耦合强耦合模块1模块2模块3模块4数据耦合通过简单变量交换数据特征耦合通过数据结构交换数据非直接耦合模块之间没有信息传递模块A模块
22、B模块C模块D模块L模块N全局性数据结构公共耦合Flag=1?S1S2模块1控制耦合模块之间传递的是控制信息TF全 局 性简单变量外部耦合模块A 模块B内容耦合 访问其它模块的内部数据 直接跳到其他模块内部执行第45页，共84页。无耦合没有依赖关系无耦合没有依赖关系松散耦合有松散耦合有少量依赖关系少量依赖关系紧密耦合有紧密耦合有很多依赖关系很多依赖关系第46页，共84页。耦合强度依赖的因素耦合强度依赖的因素 一模块对另一模块的引用一模块对另一模块的引用 一模块向另一模块传递的数据量一模块向另一模块传递的数据量 一模块施加到另一模块的控制的数量一模块施加到另一模块的控制的数量 模块间接口的复杂程
23、度模块间接口的复杂程度第47页，共84页。(1)(1)非直接耦合非直接耦合 两个模块没有直接关系两个模块没有直接关系(模快模快1 1和模快和模快2)2)，模块独立性最强。，模块独立性最强。模块模块1 1模块模块2 2模块模块3 3模块模块4 4第48页，共84页。(2)(2)数据耦合数据耦合 一模块调用另一一模块调用另一模块时，被调用模块模块时，被调用模块的输入、输出都是简的输入、输出都是简单的数据，属单的数据，属松散耦合松散耦合。开发票开发票计算水费计算水费单价单价数量数量金额金额第49页，共84页。数据耦合举例数据耦合举例计算水电费计算水电费计算水费计算水费计算电费计算电费用水量用水量用电
24、量用电量水费水费电费电费第50页，共84页。(3)(3)标记耦合标记耦合(特征耦合特征耦合)如两个模块通过传递数据结构如两个模块通过传递数据结构(不是简单数据，不是简单数据，而是记录、数组等而是记录、数组等)加以联系，或都与一个数据加以联系，或都与一个数据结构有关系结构有关系,则称这两个模块间存在标记偶合。则称这两个模块间存在标记偶合。第51页，共84页。标记耦合举例标记耦合举例计算水电费计算水电费计算水费计算水费计算电费计算电费住户情况住户情况水费水费电费电费住户情况住户情况“住户情况住户情况”是一个数据结构，图中模块都与此数据结构有关。是一个数据结构，图中模块都与此数据结构有关。“计算水费
25、计算水费”和和“计算电费计算电费”本无关，由于引用了此数据结构产生依赖关系，本无关，由于引用了此数据结构产生依赖关系，它们之间也是标记偶合。它们之间也是标记偶合。第52页，共84页。将标记耦合修改为数据耦合举例将标记耦合修改为数据耦合举例计算水电费计算水电费计算水费计算水费计算电费计算电费本月本月用水量用水量本月本月用电量用电量水费水费电费电费第53页，共84页。(4)(4)控制耦合控制耦合 一模块通过开关量、标志、名字等控制信息，明一模块通过开关量、标志、名字等控制信息，明显地控制另一模块的功能。显地控制另一模块的功能。A A计算平均分或最高分计算平均分或最高分B B平均/最高成绩第54页，
26、共84页。控制耦合举例控制耦合举例 读入分数读入分数 输出结果输出结果计算平均分计算平均分计算最高分计算最高分平均平均/最高最高?调用逻辑性模块调用逻辑性模块 B B时，须先传递时，须先传递控制信号控制信号(平均分平均分 /最高分最高分)，以选，以选择所需的操作。择所需的操作。控制模块必须知控制模块必须知道被控模块的内道被控模块的内部逻辑，增强了部逻辑，增强了相互依赖。相互依赖。B B第55页，共84页。控制耦合增加了理解和编程的复杂性，调用模块控制耦合增加了理解和编程的复杂性，调用模块必须知道被调模块的内部逻辑，增加了相互依赖。必须知道被调模块的内部逻辑，增加了相互依赖。去除模块间控制耦合的
27、方法：去除模块间控制耦合的方法：(1)(1)将被调用模块内的判定上移到调用模块中进行；将被调用模块内的判定上移到调用模块中进行；(2)(2)被调用模块分解成若干单一功能模块。被调用模块分解成若干单一功能模块。第56页，共84页。改控制耦合为数据耦合举例改控制耦合为数据耦合举例A A计算平均分计算平均分B1B1平均成绩最高成绩计算最高分计算最高分B2B2第57页，共84页。控制耦合举例控制耦合举例A A发奖牌发奖牌 名次名次(开关量开关量)奖牌奖牌控制耦合控制耦合被调用模块内被调用模块内处理逻辑模式处理逻辑模式功能功能A A功能功能B B判别判别第58页，共84页。改控制耦合为数据耦合举例改控制
28、耦合为数据耦合举例A发金牌发金牌发银牌发银牌发铜牌发铜牌第59页，共84页。(5)(5)外部耦合外部耦合一组模块均与同一外部环境关联一组模块均与同一外部环境关联(例如，例如，I/OI/O模块模块与特定的设备、格式和通信协议相关联与特定的设备、格式和通信协议相关联)，它们之，它们之间便存在外部耦合。间便存在外部耦合。外部偶合必不可少，但这种模块数目应尽量少。外部偶合必不可少，但这种模块数目应尽量少。第60页，共84页。(6)(6)公共耦合公共耦合(公共数据区耦合公共数据区耦合)一组模块引用同一个公用数据区一组模块引用同一个公用数据区(也称全局数据区、也称全局数据区、公共数据环境公共数据环境)。公
29、共数据区公共数据区指：指：全局数据结构全局数据结构 共享通讯区共享通讯区 内存公共覆盖区等内存公共覆盖区等第61页，共84页。公共耦合举例公共耦合举例公共数据区公共数据区松散的公共耦合松散的公共耦合 公共数据区公共数据区紧密的公共耦合紧密的公共耦合第62页，共84页。公共耦合举例公共耦合举例 公共数据区公共数据区C CB B模块模块A A、B B、C C间存在错综复杂的联系间存在错综复杂的联系第63页，共84页。公共耦合举例公共耦合举例所有的公共耦合关系所有的公共耦合关系A AE EB BC CD D6 6个模块共享一个模块共享一个个公共数据区公共数据区F第64页，共84页。(1)(1)软件可
30、理解性降低软件可理解性降低 (模块间存在错综复杂的连系模块间存在错综复杂的连系)(2)(2)软件可维护性差软件可维护性差 (修改变量名或属性困难修改变量名或属性困难)(3)(3)软件可靠性差软件可靠性差(公共数据区及全程变量无保护措施公共数据区及全程变量无保护措施)慎用公共数据区和全程变量慎用公共数据区和全程变量!公共耦合存在的问题：公共耦合存在的问题：第65页，共84页。(7)(7)内容耦合内容耦合一模块直接访问另一模块的内部信息一模块直接访问另一模块的内部信息(程序代码或数据程序代码或数据)。最不好内容耦合形式最不好内容耦合形式 !第66页，共84页。发生内容耦合的情形发生内容耦合的情形(
31、1)(1)一模块直接访问另一模块的内部数据一模块直接访问另一模块的内部数据(2)(2)一模块不通过正常入口转到另一模块内一模块不通过正常入口转到另一模块内(3)(3)两模块有一部分代码重叠两模块有一部分代码重叠(4)(4)一模块有多个入口一模块有多个入口第67页，共84页。模块化设计的原则和目标模块化设计的原则和目标耦合是影响软件复杂程度和设计质量的重要因素耦合是影响软件复杂程度和设计质量的重要因素目标目标：建立模块间耦合度尽可能松散的系统。：建立模块间耦合度尽可能松散的系统。第68页，共84页。如何降低模块间耦合度？如何降低模块间耦合度？(1)(1)如模块必须存在耦合，选择适当的耦合类型如模
32、块必须存在耦合，选择适当的耦合类型原则原则：尽量使用数据耦合：尽量使用数据耦合少用控制耦合少用控制耦合限制公共耦合的范围限制公共耦合的范围坚决避免使用内容耦合坚决避免使用内容耦合(2)(2)降低模块间接口的复杂性降低模块间接口的复杂性第69页，共84页。接口复杂性与耦合类型的关系接口复杂性与耦合类型的关系接接口口复复杂杂性性接口方式接口方式接口数据接口数据的复杂性的复杂性无接口关系无接口关系直接引用直接引用过程调用语句过程调用语句数据项作参数数据项作参数数据结构，变数据结构，变量名作参数量名作参数内容耦合内容耦合其它耦合其它耦合开关量，起开关量，起控制变量作用控制变量作用公用数据区公用数据区全
33、程变量全程变量数据耦合数据耦合标记耦合标记耦合控制耦合控制耦合外部耦合外部耦合公共耦合公共耦合非直接耦合非直接耦合第70页，共84页。内聚与耦合密切相关，同其它模块强耦合的模块内聚与耦合密切相关，同其它模块强耦合的模块意味着弱内聚，强内聚模块意味着与其它模块间意味着弱内聚，强内聚模块意味着与其它模块间松散耦合。松散耦合。设计目标：设计目标：力争力争强内聚强内聚、弱耦合。弱耦合。第71页，共84页。耦合、内聚与模块独立性关系耦合、内聚与模块独立性关系耦合与内聚都是模块独立性的定性标准，都反映耦合与内聚都是模块独立性的定性标准，都反映模块独立性的良好程度。但耦合是直接的主导因模块独立性的良好程度。
34、但耦合是直接的主导因素，内聚则辅助耦合共同对模块独立性进行衡量。素，内聚则辅助耦合共同对模块独立性进行衡量。第72页，共84页。3.自顶向下与自底向上设计自顶向下与自底向上设计（1）自底向上设计（）自底向上设计（Bottom-Up Design)从一个局部开始，逐渐扩展到整个系统的设计方法。从一个局部开始，逐渐扩展到整个系统的设计方法。（2）自顶向下设计（）自顶向下设计（Up-Bottom Design）首先对所设计的系统要有一个全面的理解。然后从顶层开始，首先对所设计的系统要有一个全面的理解。然后从顶层开始，连续地逐层向下分解，直至系统的所有模块都小到便于掌握为止。连续地逐层向下分解，直至系
35、统的所有模块都小到便于掌握为止。（3）两种设计的比较（）两种设计的比较（Page79）第73页，共84页。4.4 4.4 其他设计问题其他设计问题 协同设计协同设计 用户界面设计用户界面设计 并发系统设计并发系统设计第74页，共84页。协同设计必须处理好的问题：必须处理好的问题：1 1）谁最合适设计系统的某一方面？）谁最合适设计系统的某一方面？2 2）如何编写文档使组内人员相互了解别人的设计？）如何编写文档使组内人员相互了解别人的设计？3 3）如何协调设计组件使整个系统统一？）如何协调设计组件使整个系统统一？注意：在实施协同设计中，需要注意的一个主要问题是设计者的个人注意：在实施协同设计中，需
36、要注意的一个主要问题是设计者的个人经验、理解和偏爱的不同。经验、理解和偏爱的不同。第75页，共84页。用户界面设计 三条黄金指导规则（课本79页）第76页，共84页。并发系统设计 什么是并发？允许多个活动同时发生而不互相干扰 如何确保同时执行的组件间对共享数据的一致性？第77页，共84页。4.5 4.5 设计文档及其复审（设计文档及其复审（P81P81）软件设计说明书软件设计说明书 设计复审设计复审第78页，共84页。讨论：编程时是否应该多使用技巧？本人观点：就软件开发而言，技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不为人熟知。若在程序中用太多的技巧，可能会留下隐患，别人也难以理解程
37、序。鉴于一个局部的优点对整个系统而言是微不足道的，而一个错误则可能是致命的。作者建议用自然的方式编程，少用技巧。狼三则的故事告诉我们“失败的技巧通常是技俩”。当我们在编程时无法判断是用了技巧还是用了技俩，那就少用。卖油翁的故事又告诉我们“熟能生巧”，表明技巧是自然而然产生的，而不是卖弄出来的。卖油翁的绝技是可到中央电视台表演的，而他老人家却谦虚地说：“没啥没啥，用熟了而已”。第79页，共84页。聪明人一定反应敏捷，善于接受新事物。他能迅速进入一个新领域，给你一个头头是道的解释。他提出的问题往往一针见血、击中要害。他能及时掌握所学知识，并且博闻强记，他能把本来认为互不相干的领域联系在一起使问题得
38、到解决。他富有创新精神与合作精神 比尔比尔盖茨曾这样描述聪明盖茨曾这样描述聪明Cusumano1996：第80页，共84页。好的程序经理应该具备以下几个条件：好的程序经理应该具备以下几个条件：一、技术水平是程序员队伍中的最高级别一、技术水平是程序员队伍中的最高级别 每个程序员骨子里头都有一股傲气，如果你不能技压群雄，他们就不会听你指挥。一个技术水平较差的人被任命为程序经理真是个悲剧，就象一个略有权势的太监，表面上有人对他点头哈腰，背后却被人鄙视。二、能做最多且最难的工作二、能做最多且最难的工作 程序经理编程要快且好。别人要干一天的活，他半天就能做完，这样才会有精力去搞管理。程序经理应负责系统分
39、析、系统设计这类最难的开发工作，并指导不同水平的程序员把各自的工作做好。如果人手不够，程序经理要能同时干几个人的活。第81页，共84页。三、有人格魅力三、有人格魅力 软件开发是智力创作过程，你不能指望仅通过执行规章制度来产生好的作品。很多软件公司的程序经理都不是管理专业出身的，他们也不可能为了搞好管理而成天玩弄心机。技术出色的程序经理一般少有心术不正的，所以管理的重点应是“以身作则”、“公正待人”。如果程序经理在上班时趴在桌上睡觉，其他程序员也会这样干。如果程序经理发现有两个程序员趴在机器旁睡觉，不能只对其中一个大声吼叫：“你一编程就想睡觉，看看人家，在睡觉时都想着编程。”如果管理者没有人格魅
40、力，就没有人信服你，团队就不会有凝聚力，乌合之众不可能开发出优秀的软件。结论：一个有活力的软件公司的各级经理都不会这样感叹，结论：一个有活力的软件公司的各级经理都不会这样感叹，“因为我啥也不会干，所以只好当领导。因为我啥也不会干，所以只好当领导。”第82页，共84页。程序员升为经理后是否还要编程程序员升为经理后是否还要编程？让我们先看看Microsoft公司的系统软件部门与应用软件部门的领导是怎样看待这个问题的Cusumano1996。Windows NT 3.0项目的软件经理娄帕雷罗里让他手下的经理们像他一样每天花一半的时间编写代码：我在组内制定了许多规则，其中最重要的一条是每个人都得编程，
41、谁也别想坐在那儿发号施令我发现管理者很容易失去目标，他们总是无法认识到问题的本质并且反应迟缓。如果你始终不放弃编写代码，你就能对项目的进展情况了如指掌，及时发现并解决问题我大概每天花一半的时间编写代码并寻找项目的缺陷。第83页，共84页。作为应用软件领域的经理，克里斯彼得斯也持同样的看法。在他任Word项目总经理时就认为：在一些大公司内部，各部门经理把具体操作的层次向下移。你一旦当上开发部门经理，很快就会以自己身居高位、日理万机为由放弃编程；同样地，开发小组的组长会以自己重任在肩而不愿编程；至于程序员也会觉得自己十分繁忙、分身无术而不再多编写程序。虽然我是270名员工的领导，似乎不再需要做什么具体的工作了，但我还是为Word新版本编写了一个特性程序员升为经理后一定要编程，这个道理已经说得很清楚了。程序员升为经理后一定要编程，这个道理已经说得很清楚了。最怕的是最怕的是“虚心接受，坚决不做虚心接受，坚决不做”；或者仅是做个样子，每天；或者仅是做个样子，每天花一分钟时间编程，编译器还没运行完就关掉了。花一分钟时间编程，编译器还没运行完就关掉了。第84页，共84页。
