设计-中国科学技术大学

《设计-中国科学技术大学》由会员分享，可在线阅读，更多相关《设计-中国科学技术大学（109页珍藏版）》请在金锄头文库上搜索。

1、第五章 设计体系结构,中国科学技术大学 田野,内容,5.1 设计过程 5.2 体系结构建模 5.3 分解和视图 5.4 体系结构风格和策略 5.5 满足质量属性 5.6 协作设计 5.7 体系结构的评估和改进 5.8 文档化软件体系结构 5.9 体系结构设计评审 5.10 软件生产线 5.11 信息系统的例子 5.12 实时系统的例子 5.13 本章的意义,2,Objectives,软件体系结构视图； 常用体系结构模式； 可选设计方案的评价和比较的标准； 文档化软件体系结构,3,5.1 设计过程,设计(design)是一种创造性的过程，它考虑如何实现所有的客户需求。设计所产生的计划也称为设计。

2、 前期的设计决策专注于系统的体系结构 系统如何分解为单元 单元如何互联 单元外部可见特性 后期的设计决策专注于如何实现每一个结构和功能单元,4,5.1 设计过程 设计是一种创造性过程,设计软件是一种具有智力挑战性的任务 要搞清楚软件系统可能遇到的所有可能情况 系统还具有要完成的非功能目标（例如，易于使用，易于维护） 外部任务可能使设计任务更加复杂（例如， 标准数据结构，政府法规） 通过学习优秀的设计例子，我们可以改进我们的设计技巧 大部分设计工作是例程设计，针对一个问题，我们可以通过对与其相似问题的解决方案进行复用和调整来予以解决,5,5.1 设计过程 设计是一种创造性过程 (continue

3、d),开发人员在设计新系统时可从多方面汲取各种指导， 克隆：借鉴现有的整个设计，甚至包括它的代码，对它做少许调整来解决特定问题 参考模型：用于特定领域中的标准的、一般性的体系结构,6,5.1 设计过程 设计是一种创造性过程 (continued),编译器的参考模型,7,5.1 设计过程 设计是一种创造性过程 (continued),更加典型的情况是，我们需要解决的问题并没有一个参考模型 软件体系结构也有一般性的解决方来，称为体系结构风格 有时，改进系统的一个部分却会对其他部分造成负面影响 好的软件体系结构设计应当是从多方面进行选择、改造以及集成多种体系结构风格，以产生符合期望的产品,8,5.1

4、 设计过程 设计是一种创造性过程 (continued),用于理解决策以及评估选择的工具很多： 设计模式：针对单个软件模块或少量模块而给出的-般性解决方案， 它提供相对较低层次的设计决策。 设计公约：是一系列设计决策和建议的集合，采用这些设计决策和建议，能够提高系统某方面的设计质量。 创新设计：创新设计过程是被我们头脑中间现的灵感所推进的，这种无规律的突发式进展是创新设计过程的特征。 设计原则：报述的是些良好设计的特征，而不是如何进行设计的说明性建议。,9,5.1 设计过程 设计过程模型,设计过程是一个迭代过程 最终结果是软件体系结构设计文档(SAD),10,5.1设计过程 敏捷体系结构,需求

5、有大量不确定因素的情况下，采用敏捷过程是有利于开发的 敏捷体系结构是以敏捷方法的4个前提为基础的（敏捷宣言）： 相比于过程和工具，个体和迭代更有价值 相比于完整的文档，可用的软件更有价值 相比于合同谈判，客户协作更有价值 相比于遵循计划，对变化的快速响应更有价值 使用敏捷方法来产生体系结构是特别困难的： 必须同时格外小心地处理复杂度和可能发生的变化 它鼓励程序员在建模的同时开始编写代码，而这对于敏捷体系结构来说却是-个很大的问题 敏捷方法的一个更大的问题在于不断地重构,11,5.2 体系结构建模,模型可以帮助我们推断所提出的体系结构是否能够满足特定的需求 6种方式使用体系结构： 理解系统 确定

6、该系统的哪部分将复用前面已经构建的系统中的元素，以及系统哪些部分将会被复用 展示构建系统的蓝图，包括系统中可能的“承重”部分 推测系统将会如何演变，包括性能、成本以及原型开发的问题 分析依赖关系、选择最合适的设计、实现和测试技术 为管理决策提供支持，了解实现和维护时系统固有的风险,12,5.3 分解和视图,把一个大的系统分解成更小的部分来使问题变得更易于处理 从对系统关键元素的高层描述开始， 然后将系统的关键元素分解成若干部分且描述其各自的接口,13,5.3 分解和视图 普遍的设计方法,一些设计问题没有现有的解决方案 设计人员必须将问题分解为小的关键问题 几个较普遍的设计方法： 功能性分解：把

7、功能或需求分解为模块 面向特征的设计：为各个模块指定了各自的特征 面向数据的分解：关注如何将数据分解为模块 面向进程的分解：将系统分解为一系列并发的进程 面向事件的分解：关注系统必须处理的事件 面向对象的设计：将对象分配给模块,14,5.3 分解和视图 普遍的设计方法（continued）,功能性分解 把功能或需求分解成模块 首先从需求规格说明书中所列出的功能开始 更低层次的设计将这些功能分解成子功能，它们随后将被指派给更小的模块 描述模块（子功能）间相互调用的情形,15,5.3 分解和视图 普遍的设计方法（continued）,面向特征的设计 为各个模块指定了各自的特征 高层设计描述了具有某

8、个服务和特征集的系统 而低层设计则描述了各个特征如何将服务进行扩展，以及确定特征之间如何进行交互,16,5.3 分解和视图 普遍的设计方法（continued）,面向数据的设计 关注如何将数据分解成模块 高层设计描述了概念上的数据结构 低层设计提供了它们的细节，包括数据如何在模块中分配，以及分配好的数据如何实现概念上的模型,17,5.3 分解和视图 普遍的设计方法（continued）,面向进程的设计 将系统分解成一系列并发的进程 确定系统的主要任务 为执行边程指派任务 解释任务之间是如何协调工作的 低层设计描述了这些进程的细节,18,5.3 分解和视图 普遍的设计方法（continued）,

9、面向事件的设计 关注系统必须处理的事件，并将事件的责任分配给不同的模块 高层设计将系统预期的输入事件编成目录 低层设计将系统分解为状态，并描述事件是如何触发状态转移的,19,5.3 分解和视图 普遍的设计方法（continued）,面向对象的设计 将对象分配给模块 高层设计定义了系统对象的类型，解释了对象之间是如何关联的 低层设计细化了对象的属性和操作,20,5.3 分解和视图 普遍的设计方法（continued）,只有当系统的每个活动都仅由对应的软件单元实现，并且每个软件单元的输入和输出部已经明确地被定义时我们才可以说这个设计是模块化的 一个定义明确的软件单元的接口必须能够准确无误地指定该单

10、元的外部可见行为：每个指定的输入对于单元的功能来说都是很重要的，且一个指定的输出很可能就是这个单元动作的结果,21,5.3 分解和视图 普遍的设计方法（continued）,设计结果可能涉及若干种软件单元 构件 子系统 运行时进程 模块 类 包 库 过程 软件单元 模块化 定义明确,22,5.3 分解和视图 基于构件的软件工程,基于构件的软件工程(CBSE)是一种将观存的构件组合成系统的软件开发方法 构件是“有着定义明确的接口的、自包含的软件部分”，是可以单独开发、购买和销售的实体。 CBSE的目标是通过把开发过程简化成“构件集成”过程来支持新系统的快速发展，以及通过把维护过程简化成“构件替换

11、”过程来使维护变得是加容易 CBSE与其说是一个事实，还不如说只是一个目标，需进一步探明： 为构件做详细说明 保证构件的性能和它所声明的没有差别 从构件的性质方面来阐述一个系统的性质,23,5.3 分解和视图 体系结构视图,体系结构视图一般包括以下儿种: 分解视图：将系统描述为若干个可编程的单元。 依赖视图：展示软件单元之间的依赖关系。 泛化视图：展示一个软件单元是否是另一个单元的泛化或特化 执行视图：传统的方框-箭头图，展示系统运行时的结构 实现视图：在代码单元和源文件之间建立映射。 部署视图：在运行时实体和计算资源之间建立映射。 工作分配视图：将系统分解为可以分配给各项目团队的工作任务。,

12、24,5.3 分解和视图 分解视图,将系统描述为若干个可编程的单元 这种视图可能是层次化的 并且使用了多种模型,25,5.3 分解和视图 依赖视图,展示了软件单元之间的依赖关系 这种视图在做项目计划的时候很有用，确定软件单元之间有没有依赖 对某个软件单元做设计调整的时候，它可以有效地帮助我们看清该改变带来的影响,26,5.3 分解和视图 泛化视图,这种视图向我们展示了一个软件单元是否是另一个单元的泛化或者特化 这种视图在设计抽象或可扩展的软件单元时是非常有用,27,5.3 分解和视图 执行视图,这种视图是设计人员所绘制的传统的方框-箭头图，在考虑到构件和连接器的情况下， 展示了系统运行时的结构

13、 每个构件都是不同于其他构件的执行实体，而且它还可能会拥有自己的程序栈 连接器是一种构件之间的通信机制，譬如信道、共享数据存储库、或者远程过程调用,28,5.3 分解和视图 实现视图,这种视图在代码单元（如，模块、对象和过程）和源文件之间建立映射 有助于程序员在一片源代码文件的迷宫中找到某个软件单元的实现。,29,5.3 分解和视图 部署视图,这种视图在运行时实体(如，构件和连接器）和计算机资源（如，处理器、数据存储器和通信网络）之间建立起映射 有助于设计人员分析一个设计的质量属性如性能、可靠性和安全性,30,5.3 分解和视图 工作分配视图,这种视图将系统分解成可以分配给各项目团队的工作任务

14、 有助于项目管理人员跟踪各个团队的工作进度，而且对于计划和分配工程资源也大有益处,31,5.4 体系结构风格和策略,类似于建筑风格 主要有： 管道和过滤器 客户-服务器 对等网络（P2P） 发布-订阅 信息库 分层,32,5.4 体系结构风格和策略 管道和过滤器,系统包含 数据输入流和输出流，管道是简单地将数据从一个过滤器传输到下个过滤器的连接器，不对数据做任何改变 将数据输入到称作过滤器的数据转换构件中将得到输出数据,33,5.4 体系结构风格和策略 管道和过滤器（continued）,重要的特性 设计人员能够理解整个系统对输入和输出的影响 当输入输出数据拥有相同的格式时，可以很容易地将管道

15、和过滤器风格的程序复用到其他系统中 系统的演化比较简单 由于过滤器的独立性，设计人员可以进行某些类型的分析，例如吞吐量分析 过滤器可以并行地执行 缺点 不适用于包含较多用户交互的软件 重复的解析与反解析阻碍了系统的性能,34,5.4 体系结构风格和策略 客户端-服务器,两种系统构件： 服务器提供服务 客户通过请求/应答协议访问服务 服务器也会代表客户发起一系列动作，比如，客户向服务器发送一个可执行的函数，称为回调 随后在特定情况下服务器调用这些回调函数,35,5.4 体系结构风格和策略 世界杯的客户端-服务器系统,美国世界杯（1994年），系统需求： 有24支球队总共进行52场比赛 比赛分布在

16、4个时区的9个城市， 要记录每场比赛的结果并且向媒体和球迷发布 该系统对中心控制和分布功能两方面同时提出了要求，一个客户-服务器的体系结构看上去是很合适的 系统包括一个中央数据库，它设立在德克萨斯州，用于支持票务管理、完全保障、新闻服务和网络链接等工作。这个服务器还能够计算比赛数据以及提供历史信息、保密影像和视频剪辑 客户端运行于160台Sun的工作站上，这些工作站分别和对应的比赛处在同-个城市之中，它们为管理人员以及媒体提供支持,36,5.4 体系结构风格和策略 对等网络,每一个构件都只执行它自己的进程，并且对于其他同级构件，每个构件本身既是客户端又是服务器 P2P中任意一个构件都可以向其他

17、同级构件发送请求 特点 规模很易于扩展 增加一个构件都要以请求的形式增加对系统的要求， 但是它同时也增加了系统的容量 例子：Napster和Freenet,37,5.4 体系结构风格和策略 Napster的P2P体系结构,系统中的客户端是各用户的桌面计算机系统，它们执行着多方面的应用 很多用户的客户端并没有固定的网络协议(IP) 地址 不可以随时访问网络中的其他部分 绝大部分用户并不是精通网络，他们更关注的是网络中的内容 从较慢的拨号线路到较快的宽带连接，用户访问网络的方式千差万别 Napster用服务器来组织请求和管理内容，而实际上的内容是由用户以文件的形式提供的，这些文件在端与端之间共享，这些共享内容直接传送始其他（匿名的）用户，而不是传送给一个中央文件服务器。 如果文件内容经常变化、共享速度和文件的质量有着重要影响，或者如果一个端必须信任另一个端，那么P2P的体系始构则非最佳选择,