软件架构风格知识点整理.docx

1 .软件架构的概念1.1. 架构的本质软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义个系统家族，即一个架构定义个词汇表和组约束。词汇表中包含些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题架构设计的一个核心问题是能否达到架构级的软件复用架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统架构风格定义了用于描述系统的术语表和一组指导构建系统的规则1.2. 架构的“4+1”视图2 .软件架构风格3 .1.五大架构风格1 .数据流风格：批处理：大量整体数据、无需用户交互构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递。管道过漉器：流式数据、弱用户交互每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常是通过对输入数据流的变换或计算来完成的，包括通过计算和增加信息以丰富数据、通过浓缩和删除以精简数据、通过改变记录方式以转化数据和递增地转化数据等。这里的构件称为过滤器，连接件就是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。早期编译器就是采用的这种架构。要一步一步处理的，均可考虑采用此架构风格。2 .调用/返回风格：主程序/子程序：单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，即充当连接件的角色。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性面向对象：构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的层次结构：构件组织成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务,使用下一层的服务，只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层（通常只能影响上层）3 .独立构件风格：进程通信：构件是独立的过程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程（方法）调用等事件驱动系统（隐式调用）：WindoWS图形界面、断点回调构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。4 .虚拟机风格:解释器：适用于需要“自定义规则”的场合解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。规则系统：适用于专家系统基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。5 .仓库风格：仓库风格中构件分两种:一种是中央数据结构，保存系统的当前状态;另一种是独立构件，对中央数据存储进行操作数据库系统：黑板系统：语音识别、知识推理、模式识别、知识推理包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板;黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介;知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中（信号处理、问题规划和编译器优化等）。超文本系统：构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。现代集成编译环境一般采用这种架构风格。2.2.其他风格闭环控制架构（过程控制）：适合于嵌入式系统，适用于处理简单任务。经验应用：空调控温、定速巡航当软件被用来操作一个物理系统时，软件与硬件之间可以粗略地表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态。适合于嵌入式系统，涉及连续的动作与状态。C2风格：构件和连接件都有一个顶部和一个底部C2架构的基本规则：构件和连接件都有一个顶部和一个底部。构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连一个连接件可以和任意数目的其它构件和连接件连接当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部，2 .3.层次架构风格两层C/S-三层C/S-三层B/S-混合架构MVC架构风格MVP架构风格：MVC的变种MVVMRIA架构风格3 .4.基于服务的架构SOA服务构件对象WebServiceESB：提供位置透明性的消息路由和寻址服务4 .架构描述语言ADL4.1. ADL的三个基本元素：构件：计算或数据存储单元连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则架构配置：描述体系结构的构建与连接件的连接图5 .特定领域软件架构DSSA4. 1.基本活动领域分析：建立领域模型领域设计：获得DSSA领域实现：开发和组织可复用信息5. 2.角色角色领域专家：专家只提供意见，不干活领域分析人员：有经验的系统分析员领域设计人员：有经验的软件设计人员领域实现人员：有经验的程序设计人员5.基于架构的软件开发ABSD5. 1.概念ABSD方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计ABSD有三个基础。1.功能的分解。2.通过选择架构风格来实现质量和业务需求。3.软件模板的使用。采用视角与视图来描述软件架构，采用用例来描述功能需求，采用质量场景来描述质量需求。ABSD方法是一个自顶向下，递归细化的过程，软件系统的架构通过该方法得到细化，直到能产生软件构件的类。6. 2.开发过程架构需求架构设计架构文档化：输出结果为架构规则说明和测试架构需求的质量设计说明书这两个文档。架构复审：目的是标识潜在的风险。架构实现架构演化7. 软件质量属性&软件架构评估6.1.质量属性1、性能性能(PerfOrmanCe)是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。代表参数:响应时间、吞吐量设计策略:优先级队列、资源调度2、可用性可用性(availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。代表参数:故障间隔时间设计策略:冗余、心跳线3、安全性安全性(SeCUrity)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。设计策略:追踪审计4、可修改性可修改性(modifiability)是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。主要策略:信息隐藏5、可靠性可靠性(reliability)是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。主要考虑两个方面:容错、健壮性。代表参数:MTTF、MTBF设计策略:冗余、心跳线6、功能性功能性(functionality)是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。7、可变性可变性(ChangeabiIitV)是指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结松应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品(例如，软件产品线)的基础时，可变性是很重要的。8、互操作性作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性(interoperation),软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件体系结构。6 .2.评估点风险点：系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。非风险点7 .3.基于场景的评估方法软件架构分析法SAAM架构权衡分析法ATAM：L场景和需求收集。2.架构视图和场景实现。3.属性模型构造和分析。4.折中。成本效益分析法CBAM8 .软件产品线9 .L建立产品线的方式演化方式革命方式10 构件与中间件技术10.1. 建的特性1 .独立部署单元2 .作为第三方的组装单元3 .没有（外部的）可见状态8.2.基于中间件技术的优点1.面向需求2 .业务的分隔和包容性3 .设计与实现隔离4 .隔离复杂的系统资源5 .符合标准的交互模型6 .软件复用7 .提供对应用构件的管理8 .3.构件的复用检索与提取构件理解与评论构件修改构件组装构件8. 4,构件标准COBRACOMEJB基于构件的开发模型由软件的需求分析定义、体系结构设计、构件库建立、应用软件构建以及测试和发布5个阶段组成。9. Web架构设计10. 软件架构文档软件架构文档的写作应该遵循一定的原则，这些原则包括：文档要从使用者的角度进行编写；必须分发给所有与系统有关的开发人员:应该保持架构文档的即时更新，但更新不要过于频繁：架构文档中描述应该尽量避免不必要的重复；每次架构文档修改都应该记录进行修改的原则。