软件体系结构打印

1、软件体系结构定义： 软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组组合连接起来。组成部分：体系结构=构件+连接件+拓扑结构+约束+质量。软件体系结构它关注的是软件大粒度的重用、质量和维护模块设计原则高内聚，低耦合在软件体系结构中，充当“连接件”角色的有：动态链接、文件、系统注册表 软件系统的非功能需求就是指：有关能够以用户要求的性能标准，合理、高效地实现各类功能性需求的需求耦合是一个软件体系结构（SA）内各模块互连程度的度量SOA是一种特殊的SA。面向服务的体系

2、结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。软件体系结构(SA)： 提供了一个结构、行为和属性的高级抽象 从一个较高的层次来考虑组成系统的构件、构件之间的连接，以及由构件与构件交互形成的拓扑结构 这些要素应该满足一定的限制，遵循一定的设计规则，能够在一定的环境下进行演化。 反映系统开发中具有重要影响的设计决策，便于各种人员的交流，反映多种关注，据此开发的系统能完成系统既定的功能和性能需求。  体系

3、结构 = 构件 + 连接件 + 拓扑结构 + 约束 + 质量 Architecture = Components + Connectors +  Topology + Constraints + Performance11. 比较以下体系结构风格的特点：（1）管道-过滤器风格 （2）隐式事件调用 （3）基于规则的系统层次结构 （2）隐式事件调用&#

4、160;（3）面向象风格12.系统的质量属性：n 可用性 可修改性 性能 安全性 可测试性 易用性13. 体系结构风格的分类：（1）数据流风格：批处理序列；管道/过滤器（2）调用/返回风格：主程序/子程序；面向对象风格；层次结构（3）独立构件风格：进程通讯；事件系统（4）虚拟机风格：解释器；基于规则的系统（5）仓库风格：数据库系统；超文本系统；黑板系统管道/过滤器l 含义：每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产

5、生了。这里的构件被称为过滤器，这种风格的连接件就象是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。l 组成：构件（过滤器）和连接件（管道）15. 优点： Ø 使得软构件具有良好的隐蔽性和高内聚、低耦合的特点； Ø 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成； Ø 支持软件重用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来； Ø 系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉； Ø 允许对一些如吞吐量、死锁等属性的分析； Ø 支持并

6、行执行。每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。 l 缺点： Ø 通常导致进程成为批处理的结构。 Ø 不适合处理交互的应用。 Ø 因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。 l 例子：Unix，DOS 中的重定向： dir | sort（perl 脚本语言）编译器 数据抽象和面向对象组织 l 含义：这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种

7、被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。 优点： Ø 因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象； Ø 设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。 缺点： Ø 为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象； Ø 必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。例如，如果A 使用了对象B，C 也使用了对象B，那么，C 对B 的使用所造成的对A 的影响可能是料

8、想不到的。 基于事件的隐式调用 l 含义：构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。这种风格的构件是一些模块，模块既可以是一些过程，又可以是一些事件的集合。过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。这种风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。

9、l 组成：构件（一些模块，模块既可以是一些过程，又可以是一些事件的集合） l 优点： Ø 为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。 Ø 为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口。 l 缺点： Ø 构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被调用的顺序。 Ø 数据交换效率的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情

10、况下，全局性能和资源管理便成了问题。 Ø 既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。 分层系统 l 含义：层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的）。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。这种风格支持基于可增加抽象层的设计。允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现

11、， 同样为软件重用提供了强大的支持。 l 组优点： Ø 支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解； Ø 支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层； Ø 支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。 l 缺点： Ø 并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来； Ø 很难找到一个合

12、适的、正确的层次抽象方法。 成：构件，连接件 7. C/S l 含义：C/S 软件体系结构是基于资源不对等，且为实现共享而提出来的，是20 世纪90 年代成熟起来的技术， C/S 体系结构定义了工作站如何与服务器相连，以实现数据和应用分布到多个处理机上。 C/S 体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。组合模式(Composite Pattern)： l 意图：将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。 基于场景的评估方法：为该类方法具有以下重要的特征:(1) 场景是这类评估方法中不可缺少

13、的输入信息,场景的设计和选择是评估成功与否的关键因素;(2) 这类评估是人工智力密集型劳动,评估质量在很大程度上取决于人的经验和技术.基于场景的评估方法是研究最广泛,应用最成熟,数量最多的一类软件体系结构评估方法16.场景：刺激，环境，响应。Atam步骤：陈述 质量属性分析 测试， 形成评价质量属性：可修改性 可用性 性能 易用性 安全性 * 刺激是场景中解释或描述风险承担者怎样引发与系统的交互部分。例如，用户可能会激发某个功能，维护人员可能会做某个更改，测试人员可能会执行某种测试等，这些都属于对场景的刺激。* 环境描述的是刺激发生时的情况。例如，当前系统处于什么状态？有什么特殊的约

14、束条件？系统的负载是否很大？某个网络通道是否出现了阻塞等。* 响应是指系统是如何通过体系结构对刺激作出反应的。例如，用户所要求的功能是否得到满足？维护人员的修改是否成功？测试人员的测试是否成功等。* 质量属性：* 1、可修改性* 度量软件系统变化的成本。变化包括功能扩展、容量扩展、结构更新等。* 2、可用性* 是指软件在发生错误、异常、或者失败时如何反应。* 可用性=平均工作时间/(平均工作时间+平均修复时间)* 3、性能* 性能表征软件系统的响应速度或者由相应速度决定的其它度量。* 、可测试性* 可测试性表明软件系统在多大程度上容易被测试检查出缺陷。* 5、易用性* 易用性表明软件系统完成后

15、用户的体验和效率。* 6、安全性* 安全性代表软件对未授权和非法操作的防卫能力。* 评估的必要性：1、体系结构评估可以减少后期的测试和纠错的开销2、评估是挖掘隐性需求并将其补充到设计的最后机会3、体系结构是开发过程的中心，不良的体系结构会带来一蹋糊涂的效果* ATAM：Architecture Tradeoff Analysis Method（体系结构权衡分析方法）* 特点* 评估SA对特定质量目标的满足情况，揭示诸多质量目标之间的相互作用和权衡* 结构化的评估方法，可重复* 方法来源* 体系结构风格* 质量属性分析方法ATAM主要部分包括4组，共9个步骤：1. 陈述，包括通过它进行的信息交流

16、 ATAM方法的陈述：评估负责人 商业动机的陈述：项目经理或系统客户 SA的陈述：系统设计人员2. 调查与分析，包括对照体系结构方法评估关键质量属性需求 确定体系结构方法：系统设计人员 生成质量属性效用树（utility tree）：说明构成系统“效用” 的质量属性（性能、有效性、安全性、可修改性、可用性） ，具体到场景层次，标注刺激/反应，并区分不同的优先级 分析体系结构方法：基于步骤5识别出的高优先级的场景，说明和分析针对这些场景的体系结构方法。在这一步骤中，体系结构风险、非风险、敏感点和权衡点被识别出来3. 测试，包括对照所有相关人员的需求检验最新结果 集体讨论并确定场景优先级 分析体系

17、结构方法：针对步骤7的高等级场景4. 形成报告，包括陈述ATAM的结果 结果的表述：包括方法、场景、特定属性的问题、效用树、有风险决策、无风险决策、敏感点和权衡点* 第1步：ATAM方法的陈述 评估负责人向参加会议的相关人员介绍ATAM方法。在这一步，要对每个人解释参与的过程，并留出解答疑问的时间，明确其他工作的环境和预期* ATAM评估步骤简介* 用于获取信息和分析的技巧：效用树的生成、基于体系结构方法的获取和分析、对场景的集体讨论及优先级的划分* 评估的结果：场景及其优先级、用以理解和评估体系结构的问题、描述体系结构的动机需求并给出其优先级的效用树、所确定的一组体系结构方法、所发现的有风险

18、决策、无风险决策、敏感点和权衡点等* 第2步：商业动机的陈述 项目决策者从商业角度，向相关人员介绍系统概况和主要的商业动机* 系统最重要的功能* 技术、管理、经济、政治方面的任何相关限制* 与该项目相关的商业目标和上下文* 主要的相关人员* 体系结构的驱动因素，即促使形成该体系结构的主要质量属性目标* 第3步：体系结构陈述 在适合的细节层次上描述体系结构，体系结构信息直接影响可能的分析及分析的质量。在进行更实质的分析之前，评估小组通常需要询问更多的有关体系结构的信息* 技术约束条件，诸如要求使用的操作系统、硬件、中间件等* 该系统必须要与之交互的其他系统* 用以满足质量属性需求的体系结构方法、

19、样式、模式和采用的机制* 高层体系结构视图：功能、代码、并发、物理* 第4步：确定体系结构方法体系结构方法定义了系统的重要结构，描述了系统演化、对更改的响应、对攻击的防范以及与其他系统的集成等* 强调体系结构方法和体系结构风格的确定，代表了所评估的体系结构用以事先具有高优先级的质量属性的手段，保证关键需求按计划得以实现的手段* 体系结构风格，包括构件类型及其拓扑结构的描述，对构件间数据和控制交互模式的描述和使用该样风格的优缺点的非正式表述* 体系结构的约束条件，对构件及其交互的约束，这些约束条件限定了满足质量属性需求的设计决策* 基于属性的体系结构风格(attribute-based arch

20、itectural styles, ABASs)，一种带有解释该风格如何实现某些质量属性的体系结构风格* 第5步：生成质量属性效用树 评估小组与项目决策者合作，共同确定出该系统的最重要的质量属性目标，并设置优先级，进行进一步的细化，该步指导其他的分析 这种方式将所有风险承担者和评估小组的精力集中到对系统的成功与否具有重要意义的体系结构的方面上 效用树为我们提供了一种直接而有效地将系统的商业驱动因素转换为具体的质量属性场景的机制，该步骤的输出结果是对具体质量属性需求（以场景形式实现）的优先级的确定* 效用树中质量属性细化为场景* 确定最重要的质量属性目标，并设置优先级* 效用树设置优先级标准*

21、每个场景对系统成功与否的重要性* 体系结构设计人员所估计的实现这种场景的难度* 第6步：分析体系结构方法 针对划分了优先级的质量需求（第5步）和采用的体系结构方法（第4步），评估它们的匹配情况* 与效用树中每个高优先级的场景相关的体系结构方法或决策，评估小组应该能够期望在前面第4步中已经得出了所有体系结构方法* 与每个体系结构方法相联系的待分析问题，这些问题是与对应于场景的质量属性相匹配的。问题可以来自于对这些方法的文档编写实践、关于体系结构的书籍、参加评估的风险承担者的经验等* 体系结构设计师对问题的解答* 风险、无风险、敏感点、权衡点的确认* 第7步：集体讨论并确定场景优先级 在第7步和第8步，评估组测试所理解的体系结构，场景被用作测试的主要手段 第5步确定的场景主要是从体系结构设计人员的角度看待系统的质量属性需求，这一步是从相关人员的角度讨论场景* 需讨论的场景：用例场景、生长场景、探测场景，这些场景可能同效用树的场景保持一致，也可能发现更多的驱动场景，这也是一个重要收获* 相关