《软件工程——理论、方法与实践》课件第6章.ppt

1、1 1第6章 软 件 设 计第6章 软 件 设 计6.1 软件设计过程6.2 软件设计原则6.3 体系结构设计6.4 控制模型6.5 模块分解6.6 体系结构设计案例本章小结习题2 2第6章 软 件 设 计6.1 软件设计过程软件设计活动主要涉及体系结构设计、数据设计、接口设计和组件(过程)设计等内容，是将需求分析模型转换为设计模型的过程，如图6.1所示。3 3第6章 软 件 设 计图6.1 软件设计过程的主要活动4 4第6章 软 件 设 计6.2 软件设计原则软件设计活动应遵循一定的原则以提高软件实现的质量。软件设计应使软件实体有明显的层次结构，以利于软件元素间的控制；软件应是模块化的且模块

2、具有独立性；软件实体边界要清晰，具有良好的接口；设计规格说明也要清晰、简洁、完整、无二义性。5 5第6章 软 件 设 计6.2.1 模块化和信息隐蔽一个软件系统通常是一个能完成多种需求的复杂系统，例如一个图书管理系统，需要能处理图书的分类登记、定购、借阅等多种服务，而仅用一个模块来实现复杂系统是不现实的。经验表明人类求解问题过程的复杂性和工作量与单个问题的规模密切相关。6 6第6章 软 件 设 计设待求解的问题为X，则C(X)和E(X)分别为X相应的复杂性和解决问题所需要的工作量。设对于问题P1、P2，若有C(P1)C(P2)，则有E(P1)E(P2)。而另一方面，人类实践表明：C(P1+P2

3、)C(P1)+C(P2)因此E(P1+P2)E(P1)+E(P2)7 7第6章 软 件 设 计这说明将一个复杂的大系统分解成若干个相对简单的子系统(Subsystem)称为大系统模块化，使得求解问题的复杂性和工作量比一个大系统要小，求解更为容易。但模块的分解并非越多越好，模块之间存在着交互接口，当模块过多时，将会增加接口的代价，图6.2说明了这样的问题。从图中可以看出，对于给定的问题，分解的粒度有一个最小成本区M，模块分解得过多或过少均会带来较大的成本开销。8 8第6章 软 件 设 计图6.2 模块与软件消耗9 9第6章 软 件 设 计一个复杂的系统可以按层次分解为子系统(Subsystem)

4、，组件/服务(Components/Services)，类(Class)和函数(function)，它们构成了不同层次的系统模块，如图6.3所示。1010第6章 软 件 设 计图6.3 复杂系统的构成1111第6章 软 件 设 计6.2.2 内聚和耦合内聚(Cohesion)是子系统内部的相关程度。当子系统中彼此相关的多个对象执行类似的任务时，则认为该子系统是高内聚的；反之，当子系统内的多个对象彼此不相关时，则认为系统是低内聚的。高内聚的方法完成且仅完成一个功能，这使得子系统易于理解和维护。例如方法changeItem()要完成书目的读取、增加、修改和删除等若干方法的功能，则需具有较多的代码行

5、和较复杂的控制逻辑以便完成多个功能，这会为程序的可理解性带来影响，并且由于功能较多将会有较多的其他模块与之发生关联，给后期的维护带来困难。1212第6章 软 件 设 计偶然内聚是指一个模块内容为了节约空间，将并无多少逻辑关联的代码和数据组合在一起，常见的偶然内聚发生是当程序员写完一个程序后发现有一组语句多处出现，于是为节省内存便将这组语句单独组成一个模块；逻辑内聚是指一个模块完成的多个任务逻辑上相关。1313第6章 软 件 设 计例如，一个模块完成所有类型的数据输出，这类模块调用时需要传送控制信息，以便控制不同任务的处理；如果一个模块包含的多个任务必须在同一时间段内执行，则称之为时间内聚，例如

6、一个系统的初始化模块；过程内聚则是指模块内成分彼此逻辑相关，并且必须按特定的次序执行；模块中各成分引用共同的输入数据或产生相同的输出数据则称为通信内聚，这意味着一个模块可能包含多个功能，但却是对相同的数据进行操作，见图6.4；如果一个模块内的各处理成分均与同一功能相关，且这些处理必须顺序执行，即模块中某个成分的输出是另一成分的输入则称顺序内聚，见图6.5；如果模块完成单个功能且不易再分解，则称功能内聚，如求平方根、计算利息等。1414第6章 软 件 设 计图6.4 通信内聚1515第6章 软 件 设 计图6.5 顺序内聚1616第6章 软 件 设 计偶然内聚、逻辑内聚、时间内聚被认为是低级内聚

7、，设计时应尽量避免。过程内聚、通信内聚是中级内聚，而顺序内聚和功能内聚则是高级内聚。设计时应提高内聚度从而获得较好的模块独立性。如高内聚的类表示且仅表示一种类型的对象，例如在一个大学人事管理系统中使用Professor类则比用Employee类更好，因为Employee类涵盖的范围更大。1717第6章 软 件 设 计耦合(Coupling)表示两个子系统(或类)之间的关联程度，当一个子系统(或类)发生变化时对另一个子系统(或类)的影响很小，则称它们是松散耦合的；反之，如果变化的影响很大时，则称它们是紧密耦合的。耦合的强弱取决于模块间接口的复杂性、引用模块的位置和数据的传送方式等。设计时应尽量使

8、模块间的耦合度小，模块间的耦合度直接影响系统的可理解性、可测试性、可靠性和可维护性。1818第6章 软 件 设 计耦合也可分为七级，从低至高为：非直接耦合(Nondirect coupling)、数据耦合(Data coupling)、标记耦合(Stamp coupling)、控制耦合(Control coupling)、外部耦合(External coupling)、公共耦合(Common coupling)、内容耦合(Content coupling)。耦合度应越低越好。1919第6章 软 件 设 计若两模块间彼此无任何交互，则称之为非直接耦合；若两模块间仅通过参数交换信息则称为数据耦合，

9、一般系统中均需要存在这类耦合；如果模块间传送的参数包含着复合数据结构，则为标记耦合，例如含有若干数据项的数据记录；若传递的参数中含有控制信息则上升为控制耦合，如一个标志信息用于控制模块内部逻辑(见图6.6)；当若干模块与同一个外部环境关联，则模块间存在着外部耦合。如I/O处理使所有I/O模块与特定的设备、格式和通信协议相关联；公共耦合则是指模块间存在着全局变量、公共数据区或可共享的文件等；而内容耦合是指模块间存在着一个模块直接转入另一模块的内部或一个模块直接使用另一模块的数据或控制信息，见图6.7。2020第6章 软 件 设 计图6.6 控制耦合2121第6章 软 件 设 计图6.7 内容耦合

10、2222第6章 软 件 设 计6.2.3 抽象和求精“抽象(Abstract)是人类处理复杂问题的基本方法之一”(Booch)。抽象是对问题的简化和概括，它忽略了问题的某些细节，有助于把握问题的本质。抽象是分层次的，在软件系统中，高层次的抽象是概念性的，例如用例模型。较低层次的抽象则是具体解决方案和细节，例如类的定义。抽象是自底向上的，是从细节到概要的过程。求精(Refine)是抽象的逆过程，是对问题自顶向下逐步分解、细化至细节的过程。抽象和细化不仅是软件设计反复运用的原则，也贯穿于软件过程活动中。图6.8示意了对同一问题的两个不同抽象级别的描述，可以看出算法2是算法1的细化，而算法1是算法2

11、的抽象。2323第6章 软 件 设 计图6.8 对同一问题的两个不同抽象级别的描述2424第6章 软 件 设 计6.2.4 复用所谓复用(Reuse)就是利用某些已开发的、对建立新系统有用的软件元素来生成新的软件系统。复用的好处在于提高生产效率，提高软件质量，改善软件系统的可维护性。目前软件技术的发展和软件机构项目经验的积累，已具有大量商品化或非商品化的成熟软件组件，因此一个新的系统的构成，可以充分复用现成的软件组件，仅需部分编码。成熟的组件具有较小的风险，且可以加速开发工作和降低开发成本及维护代价。2525第6章 软 件 设 计6.3 体系结构设计6.3.1 什么是体系结构软件体系结构的概念

12、早在20世纪80年代就已经提出。真正引起关注和重视是在90年代，有效的软件体系结构及明确的描述和设计，已经成为软件工程领域中重要的主题。许多研究人员基于自己的经验从不同角度、不同侧面对体系结构进行了刻画。2626第6章 软 件 设 计软件体系结构涉及多方面的内容：软件的组成组件及系统构架；软件各组件的选择，各组件之间的相互作用，软件组件的进一步分解以及指导软件分解过程的总体模式；系统的功能、性能、设计以及从多种方案中进行选样的决策。软件体系结构关注的是系统结构及其组成组件，软件体系结构设计开始于系统的早期设计阶段。体系结构模型主要描述以下属性：系统的组件，包括功能组件和数据组件；系统组件间的连

13、接，包括数据流和控制流；组件和连接的约束，包括组件间的通信协议，组件间的同步等；以及用组件和连接表示的系统整体结构的拓扑关系。因而组件和连接器是软件体系结构的两大构成部分。2727第6章 软 件 设 计最简单的连接器可表现为组件之间的直接连接，如功能调用。当情况复杂时，则有专门的连接器，正如连接硬件设备的特定连接装置，软部件之间也需要连接器，如进程间通信所构成的连接器。连接器的通用表示如图6.9所示。2828第6章 软 件 设 计图6.9 连接器的通用表示2929第6章 软 件 设 计6.3.2 体系结构设计策略一个子系统的识别和设计过程实际是将一个系统分解为大粒度组件的过程，通常可以用块图来

14、描述，也可用UML的包图表示。图6.10构成了一个层次结构的体系结构。3030第6章 软 件 设 计图6.10 OSI体系结构3131第6章 软 件 设 计基于已有的知识和经验，体系结构的设计决策主要应考虑以下一些问题：(1)对于被设计的系统来说，是否存在通用的体系结构模板？(2)所设计的系统是否要分布在不同的处理器上？(3)对于系统来说什么是适合的体系结构风格？(4)建立系统结构的基本方法是什么？(5)系统的结构部件如何进一步被分解成模块？(6)使用何种策略控制系统组件的操作？(7)如何评价体系结构设计？(8)系统的体系结构如何被文档化？3232第6章 软 件 设 计使用软件体系结构的风格和

15、模式对软件开发具有重要的应用价值和经济效益：(1)它可以便于设计开发者之间相互交流和理解。只要系统是使用某种风格或模式的规范方法来组织，则别的设计者就很容易理解系统的体系结构。譬如某人把系统描述为“管道-过滤器”模式，则他不必给出细节，人们立刻就明白系统是如何组织起来的，并在脑海中清晰地得到此系统的图像。(2)使用软件体系结构的风格或模式促进了设计的复用。许多经过实践证明的软件结构可以用来解决许多相似类型的新问题。这给新软件的开发带来了便利和质量保证。3333第6章 软 件 设 计(3)使用软件体系结构的风格和模式也促进了代码复用。对于体系结构风格中的不变部分，不同的系统可以共同应用同一段实现

16、代码，从而提高了该段代码的应用价值。(4)使用软件体系结构的标准风格和模式有利于支持互操作性，例如像CORBA这种面向对象的结构和基于事件机制的集成模式。3434第6章 软 件 设 计6.3.3 管道-过滤器结构从整个系统的输入和输出关系看，各过滤器通过对其输入进行局部的独立处理变换，就可以产生部分的计算结果。过滤器的活动可以通过以下方法激活：(1)后续的部件从过滤器中取出数据。(2)前续的部件向过滤器推入新输入数据。(3)过滤器处于活跃状态，不断地从前续的部件取出并向后续的部件推入数据。3535第6章 软 件 设 计在UNIX中，用户可以定义和启动多个任务进程来充当过滤器，它们在操作系统的控

17、制下并行地工作，等待输入数据的到来，并启动工作，经过一步步过滤器的计算，最终得到处理结果。管道-过滤器结构在信号处理、分布式计算等处理中获得了广泛使用。图6.11是管道-过滤器的一个示例。3636第6章 软 件 设 计图6.11 管道-过滤器示例3737第6章 软 件 设 计管道-过滤器具有如下一些特性：(1)过滤器是独立运行的部件。也就是说，除了输入和输出外，各过滤器不受任何其他过滤器运行的影响。在设计实现上，非邻近的过滤器之间不共享任何状态，甚至对于多次加工而言，过滤器自身也是无状态的。换言之，每次加工之后，过滤器都会回到统一的原始等待状态。(2)过滤器的独立性还在于它对其处理的上游和下游

18、连接的过滤器的“无知”。它的设计和使用不对与其相连的任何过滤器施加限制，唯一关心的是其输入的形式、加工处理的逻辑、产生输出的形式。3838第6章 软 件 设 计(3)过滤器的独立性，还表现在整个结果的正确性不依赖于各个过滤器运行的先后次序。尽管其最终输出形式的获得需要经过特定的加工，并符合加工的顺序要求，但在系统工作时，各过滤器只在具备输入数据后独立地完成自己的计算。3939第6章 软 件 设 计6.3.4 分层体系结构一个分层系统采用层次化的组织方式构建，系统中的每一层都要承担两个角色。首先，它为结构中的上层提供服务；其次，它作为结构中下层的客户，调用下层提供的功能函数。一个概念上的分层模型

19、如图6.12所示。4040第6章 软 件 设 计图6.12 分层结构示例4141第6章 软 件 设 计图6.12中包含三个层次，数据访问层控制对底层数据库的访问；业务逻辑层实现系统的业务逻辑，为核心层；接口层提供与用户和其他系统的交互。这三个层次内部可以包含很多的功能组件，每一层都是一个由组件构成的虚拟机。各虚拟机之间通过系统设计的协议(可以是标准或完全私人的协议)通信，通信方式往往采用过程调用予以体现。4242第6章 软 件 设 计6.3.5 仓库系统结构一个系统通常会被分解成若干个子系统，若一个系统中存在着一个共享的数据库，所有的其他子系统基于这个数据处理子系统交换数据，这样的体系结构模型

20、称之为仓库(Repository)系统模型。仓库模型中含两类子系统，中心数据仓库和对数据进行存储、检索和更新的子系统。因此这种模型适用于由一个系统生成数据而其他子系统使用数据的场合，例如图6.13所示的编译系统。4343第6章 软 件 设 计图6.13 编译系统体系结构4444第6章 软 件 设 计6.3.6 客户/服务器模式客户、服务器体系结构是一种适用于分布式环境下的系统结构，系统中包括两类子系统：服务器子系统和客户子系统，系统将服务的集合交由服务器子系统来提供，客户子系统通过访问服务器子系统请求和使用服务，一个系统可以由一组服务器子系统和一组客户子系统组成。客户/服务器模型见图6.14。

21、4545第6章 软 件 设 计图6.14 客户/服务器模型4646第6章 软 件 设 计另一种则是瘦客户机模型，瘦客户机模型通常由服务器方承担所有的业务处理逻辑，客户机子系统仅处理与系统用户之间的交互，当业务逻辑更改，客户方无需修改。典型的瘦客户机模型为基于Internet的Web应用系统。Web应用系统本质上是一种多层的C/S体系结构，如图6.15所示4747第6章 软 件 设 计图6.15 三层B/S结构4848第6章 软 件 设 计6.3.7 MVC模式图6.16显示了MVC结构中不同子系统之间的关系，控制器收集来自用户的输入，控制用户界面的数据显示，并更新模型对象的状态；视图显示模型的

22、数据，当模型发生变化时得到通知进行更新；模型是应用程序的主体，表示业务数据或业务逻辑。4949第6章 软 件 设 计图6.16 MVC体系结构5050第6章 软 件 设 计6.4 控 制 模 型6.4.1 集中式控制在集中式控制方式下，一个子系统承担着系统控制器的角色，可以控制其他子系统的启、停。集中式控制模型也分为两类：Call-return模型和管理器(Manager)模型。Call-return模型是传统的自顶而下的结构化程序常见的模型，例如C语言、Pascal、Ada等，通过子程序调用完成相应的程序功能。这种控制模型通常用于顺序处理的系统，见图6.17。5151第6章 软 件 设 计图

23、6.17 Call-return模型5252第6章 软 件 设 计在调用层次上，控制从较高层次被传送给较低层次的子程序，子程序完成执行后，控制会返回到调用点。控制模型也可被用于模块级的函数和对象的控制逻辑。管理器模型通常应用于并发的系统。一个子系统被设计成为系统的管理者，可以控制、协调其他的子系统或进程。这些子系统或进程可以并发执行。这种模型常被用于实时系统控制。图6.18是一个实时系统控制模型。5353第6章 软 件 设 计图6.18 管理器模型5454第6章 软 件 设 计6.4.2 事件驱动的控制在事件驱动的控制模型下，控制的转移交付由外部产生的事件所触发，比如来自系统外部设备发出的请求

24、或某一个进程的请求等。事件驱动的控制一般也可分为两类：广播模型和中断驱动的模型。在广播模型中，事件发生后会被广播给系统中的所有子系统，预先注册的对该事件有兴趣的子系统响应该事件，从而实现控制的转移。图6.19是一个广播模型示意。5555第6章 软 件 设 计图6.19 事件驱动的控制5656第6章 软 件 设 计中断驱动的模型通常用在实时系统中，在系统中为外部事件设置了中断处理程序，并将程序指针存放在中断向量表中，一旦中断事件发生，系统会自动转向中断向量表中指定的处理程序。5757第6章 软 件 设 计广播模型适合网络环境下子系统的集成。在广播模型下，存在一个事件(或消息)处理器(Handle

25、r)，它维护着一张注册表，以存放对事件感兴趣的子系统。事件(或消息)处理器检测事件，检查注册表并传递事件给已注册的子系统。值得注意的是，这种模型下控制策略并不嵌入在事件(或消息)处理器中。由子系统决定需要处理哪一个事件，事件(或消息)处理器只是确保把事件发送给它们。如在Windows系统中，有专门的程序来侦听鼠标、键盘等来自用户接口的事件，并将它们转换成消息传递出去。5858第6章 软 件 设 计广播模型的优点是扩展性较好，如果要增加一个响应事件的子系统，只需在注册表中注册该子系统。另外，一个子系统可以通过事件激活其他的子系统却不需要知道它们的名字和位置，因此适用于在分布式环境，如ORB(Ob

26、ject Request Brokers)。但这种模式也存在不定，即子系统无法预知事件何时发生，并且产生事件的子系统也无法知道响应该事件的是哪一个子系统。在多个响应子系统间还可能存在冲突，因此系统还需考虑如何解决响应冲突的问题。5959第6章 软 件 设 计在实时系统中通常需要对外部产生的事件有着快速的响应，例如烟雾传感器检测出的事件、雷达监测到的障碍事件等。应对这类事件，则中断驱动的控制模型较为理想。中断处理器会中断当前的进程将控制转交给系统中断向量表中所指的中断处理进程。中断处理模型的优点是对事件的响应快速及时，缺点则是系统较难验证，因为在系统测试过程中，中断环境几乎难以复制，且中断事件往

27、往取决于硬件设备，中断事件的触发较为复杂。6060第6章 软 件 设 计6.5 模 块 分 解面向对象的分解是将子系统分解成对象或类的协作，将系统职责分配给对象，涉及对象类间的关系及其属性和操作的指定，通常用类图来描述。图6.20是将一个处理客户支付的子系统分解成由四个对象类构成的对象模型。6161第6章 软 件 设 计图6.20 面向对象的分解6262第6章 软 件 设 计图6.20示意，支付子系统由存储客户信息的Customer类、存储支付信息的Payment类、存储收款信息的Receipt类和处理支付的Invoice类构成。可以看出Customer、Payment和Receipt为实体类

28、，而Invoice为一个控制类，设计将支付信息的发布、提醒付款、处理付款和开出收据等职责分配给Invoice类，分别由issue()、sendReminder()、acceptPayment()和sendReceipt()方法来完成，以完成支付的控制。6363第6章 软 件 设 计6.6 体系结构设计案例在iricher系统中，我们采用当前流行的J2EE平台进行系统开发，体系结构设计采用如图6.21所示的分层体系结构。6464第6章 软 件 设 计图6.21 iricher系统的体系结构6565第6章 软 件 设 计本 章 小 结软件设计是软件工程核心的工程活动，软件设计活动主要涉及体系结构设

29、计、数据设计、接口设计和组件(过程设计)等内容，是将需求分析模型转换为设计模型的过程。软件设计活动应遵循一定的原则以提高软件实现的质量。软件设计应使软件实体有明显的层次结构，以利于软件元素间的控制；软件应是模块化的且模块具有独立性；软件实体边界要清晰，具有良好的接口；设计规格说明也要清晰、简洁、完整、无二义性。6666第6章 软 件 设 计习 题1软件设计的原则有哪些？举例说明各种软件设计原则在软件设计中的应用。2举例说明连接协议的结构和作用。3什么是体系结构设计？什么是组件设计？4查阅文献给出更多的体系结构设计模式，并说明它们的应用价值。6767第6章 软 件 设 计5为下面的系统给出一个适当的控制模型，并给出理由：(1)一个批处理系统，根据工作小时数和每小时薪酬，打印出薪水单和银行转账信息。(2)一组由不同供货商提供的软件工具，它们必须一起工作。(3)电视控制器，必须能响应来自远处的控制单元的信号。6868第6章 软 件 设 计6为下面的系统选择适当的模型并设计出体系结构。对系统需求给出合理假设。(1)火车站自动化售票系统。(2)计算机控制视频会议系统，允许视频、音频和计算机数据同时被多个参加者共享。(3)一个机器人地板清洁工，希望它能清扫相对较干净的空间，如走廊。这个清洁机器人一定要能感知墙壁和其他障碍物。7软件设计主要包括哪些活动。