软件体系结构总结

1、第一章：1、软件体系结构的定义国内普遍看法：体系结构 =构件 +连接件 +约束2、软件体系结构涉及哪几种结构：1、模块结构（ module）系统如何被构造为一组代码或数据单元的决策2、构件和连接件结构（ component-and-connector ， c&c）系统如何被设计为一组具有运行时行为（构件）和交互（连接件）的元素3、分配结构（ allocation）展示如何将来自于模块结构或 c&c结构的单元映射到非软件结构（硬件、开发组和文件系统）3、视图视点模型视点（viewpoint ）iso/iec 42010:2007 (ieee-std-1471-2000) 中规定：

2、视点是一个有关单个视图的规格说明。视图是基于某一视点对整个系统的一种表达。一个视图可由一个或多个架构模型组成架构模型架构意义上的图及其文字描述（如软件架构结构图）视图模型一个视图是关于整个系统某一方面的表达，一个视图模型则是指一组用来构建4、软件体系结构核心原模型1、构件是具有某种功能的可复用的软件结构单元，表示了系统中主要的计算元素和数据存储。2. 连接件 (connector) ：表示构件之间的交互并实现构件之间的连接特性： 1) 方向性 2) 角色 3) 激发性 4) 响应特征第二章1、软件功能需求、质量属性需求、约束分别对软件架构产生的影响功能性需求 ：系统必须实现的功能，以及系统在运

3、行时接收外部激励时所做出的行为或响应。质量属性需求 ：这些需求对功能或整个产品的质量描述。约束：一种零度自由的设计决策，如使用特定的编程语言。质量原意是指好的程度，与目标吻合的程度，在软件工程领域，目标自然就是需求。对任何系统而言，能按照功能需求正确执行应是对其最基本的要求。正确性是指软件按照需求正确执行任务的能力，这无疑是第一重要的软件质量属性。量属性的优劣程度反映了设计是否成功以及软件系统的整体质量。质系统或软件架构的相关视图的集合，这样一组从不同视角表达系统的视图组合在一起构成对系统比较完整的表达2、质量属性3、系统非功能性需求？包括哪些质量属性非功能性需求 ：用户对软件质量属性、运行环

4、境、资源约束、外部接口等方面的要求或期望，包括：(1) 性能需求 ：用户在软件响应速度、结果精度、运行时资源消耗量等方面的要求。(2) 可靠性需求 ：用户在软件失效的频率、严重程度、易恢复性，以及故障可预测性等方面的要求。(3) 易用性需求 ：用户在界面的易用性、美观性，以及对面向用户的文档和培训资料等方面的要求。(4) 安全性需求 ：用户在身份认证、授权控制、私密性等方面的要求( 5)外部接口 ：用户对待开发软件系统与其他软件系统或硬件设备之间的接口的要求。(6) 可保障性 （supportable ）需求：用户在软件可配置性、可扩展性、可维护性、可移植性等方面的要求。4. 可靠性可用性区别

5、可靠性通常低于可用性 ，因为可靠性要求系统在 0,t 的整个时间段内需正常 （注意是“连续” ! ）运行；可用性大于或等于可靠性 ，对于可用性，要求就没有那么高，系统可以发生故障，然后在时间段 0,t 内修复。修复以后，只要系统能够正常运行，它仍然计入系统的可用性。计算：第三章1、软件架构风格(是一个面向一类给定环境的架构设计决策的集合，这些通用的设计决策形成了一种特定的模式，为一族系统提供粗粒度的抽象框架。每一个软件系统都有其占主导地位的软件架构风格。“从软件中来，到软件中去”架构风格通过为常见的问题提供解决方案，增强了对问题的分解能力、提升了设计重用的水平。)1）独立构建风格： （ 这种风

6、格的主要特点是：事件的触发者并不知道哪些构件会被这些事件影响，相互保持独立。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用；各个构件之间彼此无直接的连接关系，各自独立存在，通过对事件的发布和注册实现关联。）进程通信体系结构风格 ：构件是独立的进程，连接件是消息传递。消息传递通常用来实现进程之间的同步和对共享资源的互斥操作典型例子：客户 - 服务器架构，其中服务器通常用来为一个或多个客户端提供数据服务，客户端则用来向服务器发出请求，针对这些请求服务器通过同步或异步方式进行请求响应。基于事件的隐式调用风格：构件不直接调用一个过程，而是触发或广播一个或多个事件。? 系统中的其它构件中的过程在

7、一个或多个事件中注册。? 当一个事件被触发 / 发布，系统自动调用在这个事件中注册的所有过程。? 这样，一个事件的触发就导致了另一模块中的过程的调用。?这种系统，称为基于事件的系统(event-basedsystem) ，采用隐式调用(implicitinvocation)的方式。2）层次风格优点 ：通过把逻辑层分布到多个物理层中，可以提高 可伸缩性、容错性（ fault tolerance ）和性能。可重用性 。每一层提供的功能都是独立的和定义良好的。不同层之间有明确的接口，在解决一个新的问题时，使开发人员更容易地重用一个已有的层。可测试性 。由于有了明确定义的接口，以及可以在层接口的不同实

8、现之间实现按需切换，可测试性明显增强了。标准化。清晰定义并且广泛接受的抽象层次能够促进实现标准化的任务和接口开发，同样接口的不同实现能够互换使用。缺点：1) 并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；2) 效率的降低：由分层风格构成的系统，运行效率往往低于整体结构。在上层中的服务如果有很多依赖于最底层，则相关的数据必须通过一些中间层的若干次转化，才能传到；3) 很难找到合适的、正确的层次抽象方法： 数太少，分 不能完全 种 格的可复用性、可修改性和可移植性上的潜力。 数 多， 引入不

9、必要的复 性和 隔离冗余以及 开 。3) 虚 机 格：不管何种 的虚 机，本 上都是在高 次抽象的用 与低 次抽象的os/硬件之 建立一道屏障。但是，如何把上 用的 求映射到下 os/硬件系 的 行？? 解 器 (interpreter)? 基于 的系 (rule-based system)解 器：是一个用来 行其他程序的程序 . 基本构件：? 解 器引擎? 存 区 接器：? 存 区的数据 基于 的系 ：核心思想：将 中可能 繁 生 化的代 从源代 中分离出来；基本 程：使用 定 言（ if then的形式，通常基于 xml或自然 言，但 不是程序 言），将 些 化部分定 “ ”；4) 客 机

10、 / 服 器： 一个 用系 被分 两个 上分离的部分，每一部分充当不同的角色、完成不同的功能，多台 算机共同完成 一的任 。1）客 机 ( 前端， front-end) ：接受用 的 入，并把 入 行适当 ， 成服 器接受的形式，通 网 服 器， 同 ， 接收服 器的回送消息， 并表 back-end)2）服 器 ：提供各种服 ，通常在高档 算机（服 器）上运行。服 器 件根据客 机的 求提供相 的服 ，如数据 服 、 件服 、 web服 等。3 ） 接件 ：建立在网 上， 留在服 器和客 机两端，提供透明的网 接和服 。5）基于 b/s 体系 构的 件 点?系 成本低：?客 端无任何 ?良好

11、的灵活性和可 展性? 好的安全性?良好的容 能力和 平衡能力。缺点?客户端浏览器一般情况下以同步的请求 / 响应模式交换数据，每请求一次服务器就要刷新一次页面；?受 http协议“基于文本的数据交换”的限制， 在数据查询等响应速度上， 要远远低于 c/s 体系结构；?提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(oltp)应用；?受限于 html的表达能力，难以支持复杂gui( 如报表等 ) 。6）soa风格定义 : 面向服务的体系结构（ service-oriented architecture 它将应用程序的不同功能单元通过定义良好的接口和契约联系起来，soa）是一个构件

12、模型，接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。服务（service ）是封装成用于业务流程的可复用构件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变用于实现特定服务的流程并不重要，只要它响应命令并为请求提供高质量的服务就可以了服务特征 :可在网际间请求调用具有良好的兼容性粗粒度的操作松散耦合的关联基于接口的设计具有透明的搜索和查询soa好处 : 利用现有的资产更快的响应和上市速度减少成本和增加复用更易于集成和管理复杂性说到做到2 web serv

13、ices 定义部署在 web上的对象从外部使用者的角度来看,web services是部署在 web上的对象 , 具备以下 特征 :完好的封装性（数据和处理）松散耦合使用协约的规范性标准化高度可集成能力3、 web service 与 soa区别web service 是技术规范，而 soa是设计原则。从本质上来说， soa是一种架构模式，而 web service 是利用一组标准实现的服务。 web service 是实现 soa的方式之一。4. 为什么 web services 是最佳解决方案 ? http+xml, 最通用的访问方式基于规范协议的访问接口 , 可支持所有平台和应用仅使用

14、web service 作为访问界面 , 使得所有接入模块的编写变得容易开发代价显著降低：程序员无需与多种平台进行交互，只需与 web service 进行交互；其调用接口使用 xml及其相关技术，在代码实现上的代价也显著降低部署和集成的费用大大降低，流程的更改也无需更改大量的代码，甚至无需更改代码只有使用 web services 架构 ,今后的大规模的面向公众的系统对接才成为可能第四章1、常用 sa描述方法线框描述法 :优点：灵活能够直观反应系统架构，同时也易于理解缺点：二义性：图形的本质所决定的模糊性，不同人有不同的理解；矛盾性：模型中可能存在相互冲突的陈述；不完备：无法描述所有的细节；

15、异构性：各个建模规范不同，模型也不同，难以支持模型在各个建模工具之交换；无法自动化：只能由人理解，靠软件工具来理解比较困难，因此无法实现自动化的验证与推理。形式化描述法 :优点：表达架构的一个正式方式可做到人机可读在一个比以前更高的水平上描述系统允许在完整性、一致性、歧义性和性能等方面分析和评估架构支持自动生成软件系统adl的缺点：使用类计算机高级语言的形式描述，表达不够直观，难以理解对于 adls应该表达什么，没有一个普遍共识，特别是关于架构的行为目前使用表达解析相对比较困难，没有很好的商业工具提供支持uml描述2、4+1 视图第五章2、属性驱动的设计方法(attribute-drivend

16、esign,add)是定义软件架构的一种方法，可根据软件质量属性需求实施架构设计过程add通过一个分解系统或者系统元素的循环过程，使用架构模式和策略来满足系统质量属性需求，以完成分解操作和模式3、质量属性设计策略4、模块设计评价标准 :可分解性可组合型可理解性可持续性（连续性）可保护性模块化五大规则 : 直接映射、少的接口、小的接口、显示接口、信息隐藏模块化设计的基本原则1. 类设计原则 : 单一责任原则开放 - 封闭原则里氏替换原则依赖倒置原则接口隔离原则2.( 包聚合设计原则 )?(rep)thereuse/releaseequivalencyprinciple复用 / 发布等价原则?(ccp)thecommon closureprinciple共同封闭原则? (crp) the common reuse principle共同复用原则3. principles of packagecoupling ( 包耦合设计原则 ):?(adp)theacyclicdependenciesprinciple无圈依赖原则?(s