• 质量属性效用树
  • 性能：系统响应能力，如响应时间、吞吐量。设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度
  • 可靠性：在意外或错误使用的情况下维持软件系统的功能特性。如 MTTF、MTBF。设计策略：心跳、Ping/Echo、冗余、选举
  • 可用性：系统能够正常运行的时间的比例。如故障间隔时间。设计策略：心跳、Ping/Echo、冗余、选举
  • 安全性： 系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。设计策略：入侵检测、用户认证、用户授权、追踪审计
  • 可修改性：能够快速的以较高的性能价格比对系统进行变更的能力。。设计策略：接口-实现分类、抽象、信息隐藏
  • 功能性：系统所能完成所期望的工作的能力
  • 可变性：体系结构经扩充或变更而成为新体系结构的能力
  • 互操作性：与其他系统或者自身环境相互作用
• 必备概念
  • 软件架构风格：描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式反映众多系统共有的结构和语义
  • 架构风险：架构设计中潜在的、存在问题的结构决策所带来的隐患
  • 风险点与非风险点：可能引起风险的因素；某件事是可行的、可接受的，则为非风险点
  • 敏感点：为了实现某种特定的质量属性，一个或者多个构件所具有的特性；只影响一种质量属性
  • 权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。影响多种质量属性
• 架构风格对比
  • 数据流：每个阶段产生的结果作为下个阶段的输入
    • 批处理：以整体为单位，前后无关联
    • 管道-过滤器：前一个输出作为后一个输入，过滤器相对独立。优点：功能模块复用、可维护性和可扩展性强、具有并发性、模块独立性高；缺点：不适合交互性强的应用、对于存在关系的数据流必须进行协调；适合领域：可划分清晰的模块、模块相对独立、有清晰的模块接口
  • 调用/返回
    • 主程序/子程序：显式调用
    • 面向对象：对象是构件。力争实现问题空间和软件系统空间结构的一致性。优点：高度模块性、实现封装、代码共享灵活、易维护、可扩充性好；缺点：增加了对象间的依赖关系
    • 层次结构：分层。各个层次的组件形成不同功能级别的虚拟机；多层相互协同工作且实现透明；优点：支持系统设计过程中的逐级抽象、可扩展性好、支持软件复用；缺点：不同层次之间耦合度高的系统很难实现；适合领域：适合功能层次的抽象和相互之间低耦合的系统
  • 独立构件
    • 进程通信：同步异步
    • 事件驱动：事件触发，如语法高亮、语法错误。系统由若干子系统构成一个整体，子系统有主从之分，每个子系统有自己的事件收集和处理机制；优点：适合描写系统组、容易实现并发处理和多任务、可扩展性好、具有类层次结构、简化代码；缺点：削弱了对系统计算的控制能力、各个对象的逻辑关系复杂；适合领域：系统对外部的表现可以从它对事件的处理表征出来
  • 虚拟机：自定义流程，业务灵活组合
    • 解释器：解释自定义规则。核心是虚拟机；优点：多种操作来解释一个句子、灵活应对自定义场景；缺点：仅适合特定领域；适合领域：模式匹配系统和语言编译器
    • 规则系统：多用于 DSS、人工智能和专家系统
  • 仓库：以数据为中心，如 IDE
    • 数据库：中央共享数据源，独立数据单元；采用两个常用构件中央数据单元和一些相对独立的组件集合；优点：实现了数据的集中、以数据为中心；缺点：仅适合特定领域；适合领域：专家系统等人工智能领域问题的求解
    • 超文本：网状
    • 黑板
  • 闭环-过程控制：汽车巡航定速、空调温度调节；通过不断测量被控对象、认识和掌握被控对象，将控制理论引入体系结构；优点：将控制理论引入体系结构；缺点：仅适合特定领域；适合领域：存在有目标的作用、信息处理闭环控制过程
  • C2 风格：构件和连接件、顶部和底部
• MVC 架构
  • 强制性地将一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离，形成三个核心模块
  • 控制器 Controller：处理用户交互，从视图读取数据，控制用户输入，并向模型发送数据
  • 模型 Model：处理应用程序数据逻辑，在数据库中存取数据。表示业务数据和业务逻辑
  • 视图 View：处理数据显示。依据模型数据创建，是用户看到并与之交互的界面，向用户显示相关数据并接收用户的输入数据，但不进行任何实际业务处理
  • 有助于管理复杂的应用程序，在一个时间内专门关注一个方面
  • 简化了分组开发，不同的开发人员可同时开发视图、控制器和业务
• J2EE 四层结构
  • 客户层：HTML 或 Applets
  • web 层：JSP 或 Servlet
  • 业务层
  • 信息系统层
  • JSP 为 MVC 中的视图 V；Servlet 为控制器 C；DAO 与 JavaBean 合在一起为 MVC 中的模型 M
• 面向服务的架构 SOA
  • 设计理念，包含多个服务
  • 企业服务总线 ESB：管道/总线，用来连接各个服务节点；集成不同协议的不同服务，ESB 做消息转化、解释以及路由的工作
  • ESB 描述服务的元数据和服务注册管理
  • ESB 在服务请求者和提供者之间传递数据，并进行转换
  • 发现、路由、匹配和选择
• 真题：质量属性
  • （a）在正常负载情况下，系统必须在0.5秒内响应用户的交易请求；（性能性）
  • （b）用户的信用卡支付必须保证99.999%的安全性；（安全性）
  • （c）系统升级后用户名要求至少包含8个字符；（功能性）
  • （d）网络失效后，系统需要在2分钟内发现错误并启用备用系统；（可用性）
  • （e）在高峰负载情况下，用户发起支付请求后系统必须在10秒内完成支付功能；（性能性）
  • （f）系统拟采用新的加密算法，这会提高系统安全性，但同时会降低系统的性能；（权衡点）
  • （g）对交易请求处理时间的要求将影响系统数据传输协议和交易处理过程的设计；（风险点）
  • （h）需要在30人月内为系统添加公司新购买的事务处理中间件；（可修改性）
  • （i）现有架构设计中的支付部分与第三方支付平台紧耦合，当系统需要支持新的支付平台时，这种设计会导致支付部分代码的修改，影响系统的可修改性；（敏感点）
  • （i）主站点断电后，需要在3秒内将访问请求重定向到备用站点；（可用性）
  • （K）用户信息数据库授权必须保证99.999%可用；（安全性）
  • （I）系统需要对Web界面风格进行修改，修改工作必须在4人月内完成；（可修改性）
  • （m）系统需要为后端工程师提供远程调试接口，并支持远程调试；（可测试性）
• 真题：系统架构设计非功能性需求（操作性需求、性能需求、安全性需求、文化需求）
  • （a）用户界面支持用户的个性化定制；（操作性需求）
  • （b）系统需要支持当前主流的标准和服务，特别是通信协议和平台接口；（操作性需求）
  • （c）用户操作的响应时间应不大于3秒，竞拍板块不大于1秒：（性能需求）
  • （d）系统具有故障诊断和快速恢复能力；（性能需求）
  • （e）用户密码需要加密传输；（安全性需求）
  • （f）系统需要支持不低于2G的数据缓存；（性能需求）
  • （g）用户操作停滞时间超过一定时限需要重新登录验证；（安全性需求）
  • （h）系统支持用户选择汉语、英语或法语三种语言之一进行操作。（文化需求）
• 真题：架构风格
  • （1）集成开发环境需要提供对脚本语言的编辑、语法检查、解释、执行和调试等功能的支持，并要实现各种功能的灵活组合、配置与替换。（数据库）
  • （2）集成开发环境需要提供一组可视化的编程界面，用户通过对界面元素拖拽和代码填充的方式就 可以完成功能插件核心业务流程的编写与组织。（解释器）
  • （3）在代码调试功能方面，集成开发环境需要实现在脚本语言编辑界面中的代码自动定位功能。具体来说，在调试过程中，编辑界面需要响应调试断点命中事件，并自动跳转到当前断点处所对应的代码。（事件驱动）