06体系结构设计

软件工程导论软件工程导论—第六章体系结构设计软件工程12软件工程目标介绍体系结构设计并讨论其重要性阐述体系结构中如何决策介绍软件体系结构的模式思想介绍在不同应用系统类型中使用的体系结构模式3软件工程内容体系结构设计决策体系结构视图模块化分解风格体系结构模式分层体系结构容器体系结构客户机-服务器体系结构管道和过滤器体系结构应用体系结构事物处理系统信息系统语言处理系统4软件工程5软件工程软件体系结构软件体系结构（softwarearchitecture）的体系结构一词在英文里就是‘建筑’的意思。把软件比作一座楼房，基础就是操作系统之上的基础设施软件；主体就是实现计算逻辑的应用程序；装饰就是方便用户使用的界面程序。其实每个程序也是有结构，结构化程序就是以语句组成模块，模块的聚集和嵌套形成层层调用的程序结构，也就是体系结构。研究内容涉及软件体系结构的描述、风格、评估和形式化方法等。根本目的是解决好软件的重用、质量和维护问题。6软件工程软件体系结构识别组成系统的子系统，并建立子系统的控制和通信框架称为体系结构设计。上述设计过程的产品就是软件体系结构的描述。7软件工程体系结构设计这是系统设计过程的早期阶段.是软件描述（需求工程过程）和设计过程之间的桥梁。包括识别主要的系统组件以及组件之间的通信和交互。打包机器人控制系统的体系结构8软件工程视觉系统对象识别系统打包选择系统打包系统手臂控制器机械爪控制器传送带控制器体系结构抽象小规模体系结构与单个程序的体系结构相关，它关注将单个程序分解成许多组成部分的方法。大规模体系结构与复杂企业系统的体系结构相关，包括其他系统、程序和程序组件。9软件工程10软件工程清晰体系结构的好处利益相关者之间的沟通体系结构是系统的一个高层表示，可以作为不同的项目相关人员之间讨论的焦点。系统分析分析系统是否能满足非功能性需求。大规模复用体系结构能在具有相似需求的系统之间互用，由此来支持大规模的软件复用。体系结构表示常用非形式化的方块图来描述体系结构。非形式化的方块图即没有给出系统组件之间的关系类型，也没有显示出组件可见的外部特性。11软件工程体系结构模型的使用作为一种加快系统设计商讨的方法。辅助信息持有者之间的沟通及项目规划。能识别出每个将要开发的关键组件。作为一种对已设计好的体系结构文档化的方法。使得对系统的理解和进化变得容易。12软件工程6.1体系结构设计决策体系结构设计是一个创造性的过程，工程中的活动很大程度上依赖所要开发的系统类型、系统架构师背景和经验以及系统的特殊需求。系统架构师必须做出很多结构上的决定，这些决定将极大地影响系统的本身及其开发过程。13软件工程14软件工程体系结构设计决策是否有通用的应用框架可以利用?系统（组件）如何分布?什么样的体系结构类型是适合的?用什么方法导出系统的结构?系统怎么分解成模块?采用什么样的控制策略?如何评估体系结构设计?体系结构如何文档化（如何描述体系结构）?15软件工程体系结构重用同一个领域的系统通常会有类似的体系结构，因为它们反映的都是同一领域的概念。应用产品线是围绕一个核心体系结构建立的一些应用，并可根据客户的需求对某些部分进行一定的调整。系统体系结构被设计围绕一个或几个体系结构模式或“风格”。16软件工程体系结构与系统特性(1)性能如果性能是关键性需求，那么体系结构的设计就要定位在少数几个子系统的一些关键性操作上，要在最大限度内使这些子系统与其他子系统减少通信。这可能意味着系统使用较大粒度的组件。信息安全如果信息安全性是一个关键性需求，那么体系结构的设计就要采用分层结构，把重要资源放在内层，并且在每层中采用更加严格的信息安全性验证。17软件工程体系结构与系统特性(2)安全如果安全是一个关键性需求，那么系统体系结构的设计就要将与安全相关的操作集中在一个或少数几个子系统中。这样做会降低成本并减少安全性方面的问题，而且有可能为之提供相应的保护系统。可用性如果可用性是一个关键性需求，那么系统体系结构设计就要采用冗余性组件，以便能在无需系统停止运行的情况下更新和替换组件。可维护性如果可维护性是一个关键性需求，那么系统体系结构设计就要使用小粒度的自包含组件以便于更换。6.2体系结构视图当设计和文档化一个系统的体系结构时，什么样的视图或角度是有效的？应该使用什么样的符号系统描述体系结构模型？每一种模型只能显示系统的一种角度和视图。18软件工程需要什么样的视图是有很多选择的，Kruchten在1995年提出了“4+1”的视图模型。“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。‘4+1’体系结构视图模型逻辑视图进程视图开发视图物理视图最终用户：功能需求场景编程人员：软件管理系统集成人员：性能可扩充性、吞吐量等系统工程人员：系统拓扑、安装、通信等‘4+1’视图模型‘4+1’体系结构视图模型‘4+1’体系结构视图模型逻辑视图显示系统中对象和对象类的一些主要抽象进程视图显示在运行时系统是如何组织为一组交互进程开发视图显示软件是如何为了开发而被分解的物理视图显示系统硬件和系统中软件是如何分布在处理器上的相关的用例和场景21软件工程（1）逻辑视图逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。（1）逻辑视图可以从Booch标记法中导出逻辑视图的标记法，只是从体系结构级的范畴来考虑这些符号，用RationalRose进行体系结构设计。构件实例继承使用包含，聚集关联类层次参数化类类服务类连接件逻辑视图中使用的标记符号◇逻辑视图逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。会话终端控制器转换服务连接服务编号计划通讯系统体系结构逻辑视图◇逻辑视图2.2“4+1”视图模型对于规模更大的系统来说，体系结构级中包含数十甚至数百个类。显示及用户接口机械服务基本元素航空信息空中交通管理飞行管理外部接口网关仿真和培训空中交通管制系统的顶级类图（2）开发视图开发视图也称模块视图，主要侧重于软件模块的组织和管理。开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述。◇开发视图与逻辑视图一样，可以使用Booch标记法中某些符号来表示开发视图。构件参照相关性模块连接件子系统层开发视图中使用的标记符号◇开发视图2.2“4+1”视图模型在开发视图中，最好采用4-6层子系统，而且每个子系统仅仅能与同层或更低层的子系统通讯，这样可以使每个层次的接口既完备又精练，避免了各个模块之间很复杂的依赖关系。设计时要充分考虑，对于各个层次，层次越低，通用性越强，这样，可以保证应用程序的需求发生改变时，所做的改动最小。开发视图所用的风格通常是层次结构风格。◇开发视图公用构件1低层服务支撑机制：通信、时间、储存、资源管理等2航空类、空中交通管制类3空中交通管制功能区：飞行管理、雷达管理等4人机接口外部系统5离线工具测试工具各种各样的空中交通管制系统特定的空中交通管制系统构件空中交通管制系统框架分布式虚拟机基本元素硬件、操作系统、数据库领域特定领域无关通用空中交通管制代码客户定制空中交通管制系统的5层结构（3）进程视图2.2“4+1”视图模型进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。进程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。在最高层抽象中，进程结构可以看作是构成一个执行单元的一组任务。它可看成一系列独立的，通过逻辑网络相互通信的程序。它们是分布的，通过总线或局域网、广域网等硬件资源连接起来。◇进程视图通过扩展Booch对Ada任务的表示法，来表示进程视图。构件事件广播双向消息远程过程调用消息未指定连接件循环进程简化进程进程进程视图中使用的标记符号◇进程视图控制器进程慢周期控制器任务快周期控制器任务主控制器任务终端进程ACS系统的局部进程视图（4）物理视图物理视图主要考虑如何把软件映射到硬件上，它通常要考虑到系统性能、规模、可靠性等。解决系统拓扑结构、系统安装、通讯等问题。当软件运行于不同的节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。◇物理视图大型系统的物理视图可能会变得十分混乱，因此可以与进程视图的映射一道，以多种形式出现，也可单独出现。构件宽带或总线双向通信单向通信临时通信通信其他设备处理器连接件物理视图中使用的标记符号◇物理视图ACS系统的物理视图C主KKKKKKKKF备份F主F备份F主C备份◇物理视图具有进程分配的小型ACS系统的物理视图K会话进程F终端进程控制器进程◇物理视图具有进程分配的大型ACS系统的物理视图C中心进程备份节点伪中心进程F会话进程终端进程伪中心进程F会话进程终端进程K控制器进程K控制器进程K控制器进程更多的K类处理器线路接口卡线路接口卡线路接口卡（5）场景场景可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。在开发体系结构时，它可以帮助设计者找到体系结构的构件和它们之间的作用关系。也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。◇场景本地呼叫场景的一个原型（1）摘机小王:控制器编号计划小王:终端小王:会话（2）拨号音（3）号码（4）号码（5）打开会话本地呼叫场景实例◇小结逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。6.3体系结构模式模式是作为一种表示、共享和复用软件系统知识的方法。体系结构模式是对好的实践所做的格式化的抽象描述。模式使用时机和优缺点。模式可以用图、表等方式描述。41软件工程TheModel-View-Controller(MVC)模式名字MVC(模型-视图-控制器)描述将表示和交互从系统数据中分离出来。系统被设计成由3个彼此交互的逻辑组件组成：模型组件管理系统数据和在数据上的操作；视图组件定义和管理如何显示数据给用户；控制器组件管理用户的交互（如键按下、鼠标点击等），并传递这些交互给视图和模型。如下页图。实例图6.4说明了采用MVC模式的基于WEB的应用系统的体系结构。使用时机在数据有多个显示和交互方式的时候使用，也可在对未来数据的交互和表示需求不明朗的时候使用。优点允许数据独立地改变，不影响表示，反之亦然。支持对相同数据的多种不同方式的表达，对某种表示的变更会传递到所有其它的表示。缺点可能需要额外的代码，当数据模型和交互很简单时，代码的复杂度相对较高。42MVC模式的组成43软件工程控制器映射用户的动作到模型更新操作选择视图视图绘制模型请求模型更新发送用户事件给控制器模型封装应用状态通知视图状态已变更视图选择用户事件变更通知状态查询状态变更采用MVC模式的Web应用体系结构44软件工程