(软件工程理论、方法与实践)第6章软件设计.ppt

　　　　　　6.1 软件设计过程　　软件设计活动主要涉及体系结构设计、数据设计、接口设计和组件(过程)设计等内容，是将需求分析模型转换为设计模型的过程，如图6.1所示。 图6.1 软件设计过程的主要活动 　　　　　6.2 软件设计原则　　软件设计活动应遵循一定的原则以提高软件实现的质量。软件设计应使软件实体有明显的层次结构，以利于软件元素间的控制；软件应是模块化的且模块具有独立性；软件实体边界要清晰，具有良好的接口；设计规格说明也要清晰、简洁、完整、无二义性。 6.2.1 模块化和信息隐蔽　　一个软件系统通常是一个能完成多种需求的复杂系统，例如一个图书管理系统，需要能处理图书的分类登记、定购、借阅等多种服务，而仅用一个模块来实现复杂系统是不现实的。经验表明人类求解问题过程的复杂性和工作量与单个问题的规模密切相关。 　　设待求解的问题为X，则C(X)?和E(X)?分别为X相应的复杂性和解决问题所需要的工作量。　　设对于问题P1、P2，若有C(P1)??C(P2)，则有E(P1)? E(P2)。而另一方面，人类实践表明：　　　　　C(P1?+?P2)??C(P1)?+?C(P2)因此　　　　　E(P1?+?P2)??E(P1)?+?E(P2) 　　这说明将一个复杂的大系统分解成若干个相对简单的子系统(Subsystem)称为大系统模块化，使得求解问题的复杂性和工作量比一个大系统要小，求解更为容易。但模块的分解并非越多越好，模块之间存在着交互接口，当模块过多时，将会增加接口的代价，图6.2说明了这样的问题。从图中可以看出，对于给定的问题，分解的粒度有一个最小成本区M，模块分解得过多或过少均会带来较大的成本开销。 图6.2 模块与软件消耗 　　一个复杂的系统可以按层次分解为子系统(Subsystem)，组件/服务(Components/Services)，类(Class)和函数(function)，它们构成了不同层次的系统模块，如图6.3所示。 图6.3 复杂系统的构成 6.2.2 内聚和耦合　　内聚(Cohesion)是子系统内部的相关程度。当子系统中彼此相关的多个对象执行类似的任务时，则认为该子系统是高内聚的；反之，当子系统内的多个对象彼此不相关时，则认为系统是低内聚的。高内聚的方法完成且仅完成一个功能，这使得子系统易于理解和维护。例如方法changeItem()要完成书目的读取、增加、修改和删除等若干方法的功能，则需具有较多的代码行和较复杂的控制逻辑以便完成多个功能，这会为程序的可理解性带来影响，并且由于功能较多将会有较多的其他模块与之发生关联，给后期的维护带来困难。 　　偶然内聚是指一个模块内容为了节约空间，将并无多少逻辑关联的代码和数据组合在一起，常见的偶然内聚发生是当程序员写完一个程序后发现有一组语句多处出现，于是为节省内存便将这组语句单独组成一个模块；逻辑内聚是指一个模块完成的多个任务逻辑上相关。 　　例如，一个模块完成所有类型的数据输出，这类模块调用时需要传送控制信息，以便控制不同任务的处理；如果一个模块包含的多个任务必须在同一时间段内执行，则称之为时间内聚，例如一个系统的初始化模块；过程内聚则是指模块内成分彼此逻辑相关，并且必须按特定的次序执行；模块中各成分引用共同的输入数据或产生相同的输出数据则称为通信内聚，这意味着一个模块可能包含多个功能，但却是对相同的数据进行操作，见图6.4；如果一个模块内的各处理成分均与同一功能相关，且这些处理必须顺序执行，即模块中某个成分的输出是另一成分的输入则称顺序内聚，见图6.5；如果模块完成单个功能且不易再分解，则称功能内聚，如求平方根、计算利息等。 图6.4 通信内聚 图6.5 顺序内聚 　　偶然内聚、逻辑内聚、时间内聚被认为是低级内聚，设计时应尽量避免。过程内聚、通信内聚是中级内聚，而顺序内聚和功能内聚则是高级内聚。设计时应提高内聚度从而获得较好的模块独立性。如高内聚的类表示且仅表示一种类型的对象，例如在一个大学人事管理系统中使用Professor类则比用Employee类更好，因为Employee类涵盖的范围更大。 　　耦合(Coupling)表示两个子系统(或类)之间的关联程度，当一个子系统(或类)发生变化时对另一个子系统(或类)的影响很小，则称它们是松散耦合的；反之，如果变化的影响很大时，则称它们是紧密耦合的。耦合的强弱取决于模块间接口的复杂性、引用模块的位置和数据的传送方式等。设计时应尽量使模块间的耦合度小，模块间的耦合度直接影响系统的可理解性、可测试性、可靠性和可维护性。 　　耦合也可分为七级，从低至高为：非直接耦合(Nondirect coupling)、数据耦合(Data coupling)、标记耦合(Stamp couplin