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