高级软件工程软件设计.ppt

《高级软件工程软件设计.ppt》由会员分享，可在线阅读，更多相关《高级软件工程软件设计.ppt（70页珍藏版）》请在三一办公上搜索。

1、高级软件工程,软件设计,4.1软件设计的目标和任务,软件设计的基本目的就是回答“系统应该如何实现？”。软件设计的任务，就是把分析阶段产生的软件需求说明转换为用适当手段表示的软件设计文档。,1软件设计的目标,不管采用何种软件设计方法，软件设计一般都包括数据设计、体系结构设计、接口设计和过程设计(或称构件级设计)等设计活动。软件设计的过程和目标：根据用信息域表示的软件需求，以及功能和性能需求，进行数据设计、系统结构设计、过程设计。在每个设计活动中，软件开发者产生软件的数据设计模型、体系结构设计模型、接口设计模型和过程设计模型。软件设计过程最终目标是产生一个设计规约，该规约包括描述数据、体系结构、接

2、口和构件的设计模型。,体系结构设计,定义软件主要结构性元素之间的关系。体系结构设计表示（即基于计算机的系统的框架）可以从系统规约、分析模型以及分析模型中所定义子系统的交互导出。,数据设计,将分析阶段创建的信息模型转变成实现软件所需的数据结构。部分数据设计可能和软件体系结构的设计同时发生，但更详细的数据设计活动则会发生在每个具体软件构件（或模块）设计的时候。,接口设计,描述软件内部模块之间以及软件与人之间是如何通信的（包括数据流和控制流）。一个接口意味着特定信息流（如数据流和/或控制流）以及行为类型，因此，数据和控制流图提供了接口设计所需的信息。,构件级设计,将软件体系结构的结构性元素转变成对软

3、件构件的过程性描述，即描述软件构件的详细内部设计细节。,软件设计非常重要，它将最终影响软件构造是否成功、最终软件的质量以及软件维护的难易程度。软件设计为我们提供了可以用于质量评估的软件表示，设计是我们能将用户需求准确地转化为完整的软件产品或系统的唯一方法。软件设计是所有软件维护步骤的基础。,2软件设计的任务,从工程管理的角度来看，传统的软件设计任务通常分两个阶段完成：第一个阶段是概要设计（总体设计或初步设计），将软件需求转化为数据结构和软件的系统结构,包括结构设计和接口设计，并编写概要设计文档。第二阶段是详细设计阶段（过程设计），其任务是通过对结构表示进行细化，确定各个软件构件的详细数据结构和

4、算法，产生描述各软件构件的详细设计文档。,概要设计主要确定实现目标系统的总体思想和设计框架。系统分析员使用系统流程图或其他工具，描述每种可能的系统，推荐一个较好的系统方案（最佳方案），并且制定实现所推荐系统的详细计划。在用户确认后，系统分析员就要设计软件的整体结构和框架，确定程序有哪些某块组成，以及模块与模块之间的关系，最后提出总体设计说明书；详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统。面向对象开发方法中，概要设计的部分内容，例如类及对象的设计将提前到OOA阶段开始，而在OOD阶段，概要设计将更多地关心对象之间的协作与交互。,4.2软件设计基本概念,在过去四十年中发展起来一套基

5、本的软件设计概念，每一种概念都为设计者提供了应用更加复杂设计方法的基础。,4.2.1 构件与构件化,1构件在软件系统设计中，构件是指这样一组程序语句，它包括输入、输出和逻辑处理功能、内部信息及其运行计划。构件指可单独命名且可通过名字访问的过程函数、子程序或宏调用。模块就是构件的一种具体形式。模块是一个拥有明确定义的输入、输出和特性的程序实体。,一般构件/模块具有以下几种特征：（1）接口，模块的输入输出；（2）功能，指模块实现什么功能，有什么作用；（3）逻辑，描述模块内部如何实现需求及所需数据；（4）状态，该模块的运行环境，模块间调用与被调用关系。,2构件化,构件化就是将程序划分成若干个独立的模

6、块，每个模块完成一个特定子功能，每个模块既是相对独立的，又是相互联系的，它们共同完成系统指定的各项功能。构件化的目的：降低软件的复杂性。对软件进行适当的分解，不但可以降低复杂性，而且可减少开发工作量，从而降低软件开发成本。我们常说的模块化就是构件化的一种具体形式。,4.2.2 抽象与逐步求精,1抽象 抽象是指从一些事物中抽取其本质的共同的特性，而忽略其非本质细节的差异。当我们考虑对求解问题的模块化时，可以进行多层次抽象。在抽象的最高层次使用问题环境的语言，以概括的方式叙述问题的解法，在较低层次上使用更过程化的方法，把面向问题的术语和面向实现的术语结合起来描述问题的解法。软件工程中的每个步骤都是

7、对软件解决方案抽象化程度的一次细化（即求精）。,2逐步求精,逐步求精是一种先总体、后局部的思维原则，也就是一种逐层分解、分而治之的方法。在面对一个复杂的大问题时，它采用自顶向下、逐步细化的方法，将一个大问题逐层分解成许多小问题，然后每个小系统再分解成若干个更小的问题，经过多次逐层分解，每个最低层问题都足够简单，最后再逐个解决。,逐步求精是与抽象相反但又互补的一个概念。抽象使得设计者能够刻画过程和数据的同时，忽略低层细节，求精有助于设计者在数据过程中揭示低层的细节，两者均能帮助设计者在设计演化中，构造出完整的设计模型。,4.2.3 信息隐藏,信息隐蔽是在设计和确定模块时，使得一个模块内包含的信息

8、（过程和数据）对于不需要这些信息的模块来说是不能访问的。它通过定义一组独立的模块来实现有效的模块化。信息隐蔽作为一种设计准则用于模块化系统，在测试与维护期间对软件修改会带来极大的好处。信息隐蔽的目的，是为了提高模块的独立性，当修改或维护模块时减少把一个模块的错误扩散到其他模块中去的机会。,4.2.4 构件独立性,构件独立性（Module Independence）概括了把软件划分为构件时要遵守的准则，也是判断构件构造是不是合理的标准。模块独立性是构件独立性的一种具体表现形式。独立的模块指具有独立功能而且和其他模块之间没有过多的相互作用的模块。模块独立性是通过判定系统中划分的模块是否是独立的模块

9、来实现的，即使每个模块只完成系统要求的一个相对独立的特定子功能，而且与软件结构的其他部分的接口是简单的。,模块独立的重要性,第一，具有独立模块的软件比较容易开发出来。这是由于能够分割功能而且接口可以简化，当许多人分工合作开发同一个软件时，这个优点尤其重要；第二，独立模块比较容易测试和维护。总之，模块独立是好设计的关键，而设计又是决定软件质量的关键环节。,独立性可以从两个方面来度量，即模块本身的内聚（Cohesion）和模块之间的耦合（Coupling）。内聚指模块内部各个成分之间的联系，所以也称为块内联系或模块强度；耦合指一个模块与其他模块之间的联系，所以又称为块间联系。模块的独立性愈高，则模

10、块内联系越强，模块间联系越弱。C、Myers把耦合和内聚各划分为7类，现分别介绍如下。,这是从功能角度对模块内部聚合能力的量度。按照由弱到强的顺序，Myers把模块内部聚合能力分为7类，如图4.3所示。在图中，从左到右内聚强度逐步增强。,1内聚,偶然性内聚 Coincidental Cohesion逻辑性内聚 Logical Cohesion时间性内聚 Temporal Cohesion过程性内聚 Procedural Cohesion通信性内聚 Communicational Cohesion顺序性内聚 Sequential Cohesion功能性内聚 Functional Cohesion

11、,图4.3 内聚强度的划分,低内聚,偶然性内聚块内各组成成分在功能上是互不相关的。例如，如图4.4所示，如果有模块X，Y，Z调用模块W，模块W中的这几条语句是为了节省空间把它们放在一个模块之中，而这几条语句之间没有任何联系，我们称模块W的块内联系为偶然性内聚。,偶然性内聚模块的各成分之间没有联系，此模块很难理解、测试和维护；另一方面不易修改。只要有足够的空间，就应尽量避免因节省空间而产生的模块偶然性内聚。,逻辑性内聚,这种模块把几种相关、相似功能组合在一起，每次被调用时，由传递给模块的参数来确定该模块应完成哪一种功能。,时间性内聚,如果一个模块所包含的任务必须在同一“时间”内完成，则这个模块的

12、块内联系称为时间性内聚。例如，一个处理意外故障模块中，“关闭文件”、“报警”、“保留现场”等任务必须无中断地同时处理。由于要求它们在同一段时间内执行相关功能，故称为时间性内聚。如图4.7所示。,中内聚,过程性内聚 当一个模块中包含的一组任务必需按照某一特定的次序执行时，就称为过程性内聚模块。,通信性内聚,通信性内聚型模块除了具有过程内聚的特点外，还有另外一种关系，即它的所有功能都通过使用公用数据而发生关系，即模块内部的各个成分都使用同一种输入数据，或者产生同一个输出数据。,图4.9 通信性内聚两例,高内聚模块,顺序性内聚 如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行，

13、通常一个处理元素的输出数据作为下一个处理元素的输入数据，则成为顺序性内聚。,功能性内聚,如果一个模块包括并仅为完成某一具体任务所必需的所有成分，或者说模块中所有成分结合起来是为了完成一个具体的任务，此模块则为功能性内聚模块。例如对一个数开平方，求一组数中的最大值，从键盘上读入一行等。功能性内聚模块具有内聚强，与其他模块的联系少等优点。,“一个模块，一个功能”，已成为模块化设计的一条准则，也是设计人员争取的目标。当然，其他的高内聚和中内聚模块也是允许使用的，低内聚模块因块内各成分的联系松散，可维护性和可重用性都比较差，在设计中应尽可能避免使用。,2耦合,耦合是对软件内部模块之间相互联系的度量。按

14、照Myers的划分，也归纳为7类:,图4.11 耦合强度的等级,弱耦合,非直接耦合 若两个模块没有直接关系，它们之间的联系完全是通过主程序的控制和调用来实现的，便称这两个模块为非直接耦合，这样独立性最强。,数据耦合,若一个模块访问另一个模块，且被访问模块的输入和输出都是数据项参数，则称这两个模块之间的联系为数据耦合。,模块B从属于模块A，A对B的访问是通过一个约定的变元表或者模块接口界面进行数据传递的，这里只传递数据，所以称A和B之间的联系为数据耦合。,图4.13 数据耦合一例,特征耦合,若两个以上的模块都需要其余某一数据结构的子结构时，不使用全局变量的方式而是用记录传递的方式，这样的耦合称为

15、特征耦合。,弱耦合示例,模块1与模块2为同级模块，相互之间没有信息传递，属于非直接耦合。模块3、4都是模块1的下属模块。模块1调用它们时，可通过参数表与它们交换数据。如果交换的都是简单变量，便构成数据耦合（如模块1、3之间）；如果交换的是数据结构，便构成特征耦合（如模块1与模块4之间）。,控制耦合,控制耦合是中等强度的耦合。此时在模块间传递的信息不是一般的数据，而是用作控制信号的开关值或标志量（Flag）。逻辑性内聚模块为例，当调用这一模块时，调用模块必须先把一个控制信号（平均分/最高分）传递给它，以便选择所需的操作。因此，控制模块必须知道被控模块的内部逻辑，从而增强了模块间的相互依赖。,较强

16、耦合,外部耦合 若允许一组模块访问同一个全局变量，可称它们为外部耦合。模块A和B都访问同一个有名公共区，就是其中的一种，再如固定格式的通讯约定，输入输出把模块连接到指定的设备上。外部耦合是必须的，但是在一个结构内，应该限制在少数模块内。,图4.17 外部耦合一例,公共耦合,若允许一级模块访问同一个全局性数据结构，则称之为公共耦合。如图4.18中，假定模块A、B、C均可访问公用区中的某一数据结构。模块A首先从中读出数据，然后模块C，对该数据进行更新。如果模块C在更新数据时出错，则当模块B在以后某个时候读取上述数据并作处理时，就会得出错误的结果。虽然问题是在B调用公共区域时暴露的，但根源在于C，这

17、就增加了调试和排错的困难。,内容耦合,最强的一类耦合称为内容耦合。如果一个模块可以直接调用另一模块中的数据，或者允许一个模块直接转移到另一模块中去，就称它们间的耦合为内容耦合。图4.19 内容耦合一例 图4.19中，假定在修改模块N时将一条指令从标号为A的指令前面移到它的后面，就须特别细心，检查会不会因此影响到模块M的执行结果。,4.2.5 软件体系结构,软件体系结构(Software Architecture)，即软件的架构。从最简单的形式来看，体系结构是程序构件（模块）的层次结构、构件间交互的方式以及构件中使用数据的结构。在更广泛的意义上，构件可以被推广为系统元素和它们的交互。,软件体系结

18、构研究的主要内容涉及软件体系结构的描述、软件体系结构风格、软件体系结构的设计、软件体系结构模式、软件体系结构的评估和软件体系结构的重用等。解决好软件的重用、质量、可维护性和易扩展性等问题，是研究软件体系结构的根本目的和主要内容。,4.2.6 程序结构,程序结构也称作控制层次或调用层次，它代表了程序构件（模块）的组织（常常是结构化的）并暗示了控制（调用）的层次结构，它并不表示软件的过程性侧面。为了有助于后面有关结构的讨论，我们定义一些简单的测度和术语。,模块的深度和宽度,模块的宽度和深度分别提供了对调用级别的数量和整体调用跨度的指示。模块的深度表示系统结构中的模块调用层数，宽度则表示调用的总分布

19、，即同一层次的模块总数的最大值。深度和宽度标志着一个系统的大小和复杂程度、它们之间应有一定的比例关系，即深度和宽度均要适当。深度过大，可能说明系统分割的过分细化；宽度过大，则有可能带来系统管理上的困难。,扇入、扇出,扇出（fan-out）是一个模块直接调用的模块数目，扇入（fan-in）表明有多少个上级模块直接调用一个给定模块。,图 4.20 调用和返回体系结构的层次控制树形图,4.2.7 数据结构,数据结构是个体数据元素之间逻辑关系的表示。对于软件体系结构的表示而言，数据结构同程序结构同样重要，因为信息结构必将会影响最终的过程设计。数据结构决定了信息的组织、访问方法、关联程度、可替换的处理方

20、法.,标量项是最简单的数据结构，就像名字的含义一样，标量项代表一个单独可以通过一个标识符来引用的信息元素；也就是说，可以通过指定一个单独的存储地址来实现对它的访问。标量项的大小和格式可以在程序设计语言规定的范围内变化。例如，一个标量项可以是一位长的逻辑实体，也可以是一个8位到64位长的整数或浮点数或成百上千字节长的字符串。,当标量被组织成列表或相邻组时，就形成了一个顺序向量，向量是所有数据结构中最常用的，并且是信息变量索引的基础。当顺序向量扩展到两维、三维、最终是任意维时，就创建了一个n维空间，最常见的n维空间是二维的矩阵，在大多数编程语言中，n维空间是用多维数组形式表现出来。,项、向量和空间

21、可以按多种格式组织，链表是将不相邻的标量项、向量或空间以某种方式（称为节点）组织起来的数据结构，这种方式使得节点可以像列表一样处理，每一个节点包含适当的数据组织（例如，一个向量）和一个或更多个指示列表中下一个节点存储位置的指针。在列表中的任意点都可以加入新节点。,数据结构的表示方法,三种基本的结构类型分别是顺序、选择和重复，他们的表示方法分别如图4.21的(a)，(b)，(c)所示。,4.3软件设计原则,软件设计的成败将直接导致软件质量的优劣，而我们的软件设计师也不能随意地设计软件，他们也必须依靠一些基本原则和设计经验，才能构造出优质的软件设计模型。Davis提出了一系列软件设计的原则，下面的

22、内容是在这些原则上的总结和扩充：,软件设计的一般原则,设计过程应该能够预测和评估。设计对于分析模型应该是可跟踪的。设计应该重视资源重用。设计应该使最终软件尽可能和现实世界中问题的“相似”，也就是说，软件设计的结构应该（尽可能）模拟问题域的结构。设计应该表现出一致性和集成性。,设计应该适应扩展和变更。设计应该考虑软件的容错性和处理错误、异常的能力。设计不是编码，编码也不是设计。在创建设计时就应该能够评估质量，而不是在事情完成之后。应该评审设计以减少概念性（语义性）错误。,4.4软件程序结构的启发式设计准则与优化,人们总结了在开发计算机软件的长期实践中积累的经验，得出了一些启发式设计准则。这些启发

23、式设计准则是优化软件结构设计的指导规则，可以帮助软件开发者改进软件设计、提高软件质量。,1改进软件结构，降低耦合并提高内聚，以提高模块独立性。设计出软件的初步结构以后，应该审查分析这个结构，通过对模块进行分割、合并和变动调用关系，力求降低耦合、提高内聚，简化模块接口，以及少用全局性数据和控制型信息等。,2模块规模应该适中。经验表明，一个模块的规模不应过大，模块的总行数应控制在10到100行的范围内，最好为30至60行，能在一张打印纸内容纳下，这样理解和阅读都较方便。但小模块太多也会使模块之间联系变得复杂，增大系统在模块调用时传递信息所花费的开销。应根据实际情况选择合适的模块大小。,3保持适当的

24、扇入和扇出。扇入数越大则共享该模块的上级模块数目越多，能够增加模块的利用率，但是，不能违背模块独立原理单纯追求高扇入数。扇出数过大意味着模块过分复杂，需要控制和协调过多的下级模块；扇出数过小(例如总是1)也不好。通常扇出数34为宜，最好不超过57。,如扇出数过大，软件结构将呈煎饼形，如图4.22（a），此时可用增加中间层的方法使扇出数减小，如图4.21（b）所显示。扇出数太小时可以把下级模块进一步分解成若干个子功能模块，或者合并到它的上级模块中去。当然分解模块或合并模块必须符合问题结构，不能违背模块独立原理。,图4.22（a）,图4.22（b）,4模块的作用域应该在控制域内 一个模块的控制域，

25、是模块本身及其所有从属以及最终的从属模块（即所有可供它调用的下级模块）。一个模块的作用域，是受这个模块中决策影响的其他模块。只要模块中含有一些依赖于这个判定的操作，这个模块就在这个判定的作用范围之内。本规则的含义是：作用域不要超出控制域的范围，即将模块的影响范围限制在模块的控制范围内；,5.降低模块接口的复杂冗余程度,并提高一致性。模块接口复杂性是软件出现错误的首要原因，接口应该设计成简单地传递信息并且应该同模块的功能保持一致，接口不一致性（看上去无关的数据通过参数表或其他技术传递）是低内聚的表现。有问题的模块应该重新设计。,4.5.1 软件设计规格说明书,在设计阶段，设计人员要完成的文档是软

26、件设计说明书，它是软件设计的最终成果，它既可作为软件设计阶段编码人员书写源程序的依据，也可作为软件测试阶段及维护阶段的一个指南。,软件设计说明书内容,（1）作用范围：描述设计工作的整体范围，其大部分内容来自软件需求说明书。（2）参考文档：包括现有的软件文档、系统的文档资料、外购产品文档，包括硬件和软件以及技术参考资料。（3）数据设计：描述数据对象和形成的数据结构、外部文件和数据库结构、内部数据结构等。（4）体系结构设计：说明从需求模型导出的软件体系结构，包括模块的层次结构。（5）接口设计：描述人机界面以及人机界面的设计规则，外部数据、系统或设备接口和内部接口及其设计规则。,（6）模块的过程设计

27、：描述每个模块的处理说明、设计语言描述、调用其他模块和内部设计结构等。（7）需求与模块的相互对照表。（8）测试准备：包括测试大纲、整体策略、专门的考虑等。（9）其他：包括设计约束和一些特殊注解等内容。,软件开发者应根据软件设计包括的实际阶段，在软件设计这个大阶段结束后，产生相应的阶段性的文档如：体系结构设计说明书、数据库设计说明书、构件详细设计（过程设计）说明书以及初步测试文档、用户手册等。,4.5.2 设计复审,设计复审（Design Review）：对设计文档的复审。复审对于研制项目的成功而言是绝对必要的。对设计进行复审是为了尽早发现软件的欠缺，尽可能把这些缺欠在进入下一阶段工作之前，予以

28、纠正，从而避免后期付出更多的代价。,1设计复审方法,目前存在着两种不同的设计复审方法：正规复审 制作好幻灯片、邀请听众按计划好的议事日程进行正式复审。这种方法是概要设计复审常用的方式。由于参加人员包括各方面的代表，正式复审通常采取正式会议的方式。非正规复审 只召集少数设计人员和有关用户参加讨论设计问题。这类复审的特点是参加人数少，且均为软件人员，带有同行讨论的性质，因而方便灵活，十分适合于详细复审。,2复审的指导原则,在传统软件设计中，概要设计复审和过程设计复审应该分开进行，不允许合并为一次复审。除软件开发人员外，概要设计复审必须有用户代表参加，必要时还可邀请有关领域的专家到会。过程设计复审一

29、般不邀请用户和其他领域的代表。参加复审的设计人员应欢迎别人提出批评和建议，不要为设计的缺陷“护短”。但复审的对象是设计文档，不是设计者本身，其他参加者也应为复审创造和谐的气氛，防止把复审变成质讯或辩论。复审中提出的问题应详细记录，但不要谋求当场解决。复审结束前，应作出本次复审能否通过的结论。,3复审的标准,复审的标准应包括：可追溯性风险实用性可维护性接口技术清晰度选择方案限制其他具体问题,4复审的内容,概要设计复审应该把重点放在系统的总体结构、模块划分、内外接口等方面。例如软件的结构能否满足需求？结构的形态是否合理？层次是否清晰？模块的划分是不是符合优化的原则？系统的人机界面、内外部接口，以及出错处理是不是合理等。过程设计复审的重点应该放在各个模块的具体设计上。例如模块的设计能否满足其功能与性能要求？选择的算法与数据结构是否合理，符不符合编码语言的特点？设计描述是否简单、清晰等。,