软考架构师知识点

1. 架构部分

1.1 架构设计

1.1.1 基于体系结构的软件设计 ABSD(Archiecture-Based Software Design)

架构驱动的方法，自顶向下，软件系统的架构通过该方法得到细化，直到能产生软件构件或模块

1.1.2 4+1视图

1. 逻辑视图：设计视图（类，对象，状态，协作图）
2. 过程视图：线程或进程活动类建模，并发与同步结构（状态图）
3. 开发视图：模块和组件代码静态组织结构（包、组件）
4. 部署视图：软件到硬件映射和分步结构（网络部署图）
5. 用例视图：需求分析模型（用例图）

1.1.3 架构风格

• 层次性架构
  描述软件层级关系，又称分层架构，（物联网，七层网络模型）
  • C/S
    一层：（用户接口、业务逻辑、数据管理）
    二层：（用户接口、业务逻辑）、分离数据
    三层 C/S 架构将应用系统分成表示层（用户和系统接口部分）、功能层（业务逻辑）、数据层（数据管理和控制）
• 规则系统 Rule-based system
  基于规则的系统中的规则引擎负责对规则进行解释实现，能讲业务规则跟应用程序分离，减少运维工作

1.1.4 特定应用领域架构 DSSA(Domain Specifie Sottware Architecture)

特定应用领域中为一组应用提供组织结构参考的标准软件架构。从功能范围角度，垂直域定义了一个特定的系统族，包含整个系统族内的多个系统，可作为该领域系统的可行解决方案的一个通用软件架构；水平域顶一个在多个系统和多个系统族中功能区域的共有部分，再子系统级上涵盖多个系统族的特定部分功能。

1.2 架构评估

在进行架构评估时，一般未收先要精确得出具体的质量目标，并用其自以为判定该体系结构优劣的标准。把得出这些质量目标而采用的机制叫做场景，场景是从风险承担者的角度对与系统进行的交互的简短描述。再体系结构评估中一般采用刺激、环境、响应三个方面来对场景进行描述。刺激是指场景中解释或描述风险承担着怎样引发与系统的交互。如：用户会激发某个功能（新增需求），维护中可能会做某个更改，测试人员可能会执行某种测试这些都是对于场景的刺激。环境描述是刺激发生时的情况，如：当前系统处于何种状态？有如何的约束条件？是否存在系统负载很大？网络是否存在阻塞等。响应是指系统是如何通过体系结构对刺激做出的反应，如：用户所要求的功能是否得到满足？维护人员的修改是否成功？测试人员的测试是否成功等

在架构评估中，敏感点是一个或(和)多个构件之间的特性（关系）。改变加密级别的设计决策属于权衡点，因为他可能会安全性和性能产生非常重要的影响。

1.2.1 架构质量

• 开发期质量属性
  • 开发人员：易理解性、可扩展性、可重用性、可维护性、可移植性
    • 易理解性： 设计被开发人员理解的难易程度，Max: 简单框架、避免前置条件的嵌套
    • 可扩展性（灵活性）：软件因适应新需求活需求变化而增加新功能的能力。Max：通过框架可快速搭建模块等
    • 可重用性：重用软件系统或某一部分的难易程度。Max：模块复用
    • 可维护性：当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度：Max：Bug定位
    • 可移植性：讲软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。Max：跨平台跨语言集成管理工具
  • 测试人员：可测试性
    • 可测试性：对软件测试以证明器满足需求规范的难易程度。
• 运行期质量属性
  • 客户与管理员：易用性、性能、安全、互操作性
    • 易用性：软件系统易于使用的程度。Max：极简化、扁平化、无串行流程理解等
    • 性能：软件系统及时提供相应服务能力。Max：用户行为的快速相应
    • 安全：软件系统同时兼向合法用户提供服务，阻止非授权行为使用的能力。Max：非授权用户行为杜绝，如反爬虫等
    • 互操作性：软件系统与其他系统交换数据和相互调用服务的难易程度。Max：通常表征为数据兼容性，即数据导入和导出
  • 运维人员：可伸缩性、可靠性、鲁棒性（健壮性、容错性）
    • 可伸缩性（可修改性）：当用户数量增加时，软件系统自动（手动）维持高服务质量的能力。Max：负载均衡、弹性节点
    • 可靠性：软件系统在一定时间内无故障运行的能力。Max：时间检测
    • 鲁棒性: 软件系统在一些非正常情况下仍然能够正常运行。
      • 健壮性：即规定流程执行前后系统是否一致。
      • 容错性：即具体行为中意外出现时，系统是否正常运行。