软考-高级架构师Keywords（下半部分）

软件工程

软件工程基础

软件工程生命周期：定义-开发-运维

软件工程过程：规格说明-开发-确认-演进

软件系统工具

软件设计，包括：数据，架构，人机接口，过程四个方面设计

软件过程模型

瀑布、原型、螺旋、增量、喷泉

基于构建的开发模型（CBSD）: 感觉就是指开发时形成CBB，增强复用性

形式化方法模型

敏捷模型：“敏捷宣言”则被展示在一个网站上（ Manifesto for Agile Software Development ）

敏捷开发与其他结构化方法区别特点：面向人的、适应性。以人为本，发挥人的特性

统一过程模型（RUP）：一种重量级过程，描述了多个工作流模板，是一个时间-工作流的二维模型

特点：用例驱动、以体系结构为中心（会建立多个维度的视图）、迭代与增量

Loop { 初始，精化，构造，移交 }

能力成熟度模型CMM

初始级，可重复级（可复制的流程），已定义级（有文档了），已管理级（主要是质量管理），优化级（定量分析）。

逆向工程：设计的恢复过程

软件需求：两个过程-需求开发和需求管理

需求分析的任务：1）绘制系统上下文范围关系图 2) 用户界面原型 3）可行性、优先级、模型、数据字典、QFD；

QFD(质量功能部署)：用户需求到生产要求的映射，确保开发的每个阶段能满足用户的要求。

结构化需求分析：数据流图、数据字典

需求定义：预定义（描述最终系统）、原型法

需求验证：对技术规格书进行评审

需求管理：Loop { 建议-批准-实现-验证 }  & 需求变更 & 需求追踪

系统设计

业务处理流程设计

业务流程重组BPR：对业务流程的根本思考和彻底再造

业务流程管理BPM：规范化设计，而非重组再造工作

系统设计基本原理和设计原则：高内聚，低耦合，多扇入，少扇出。等等。

内聚和耦合的从高到低：最低就是偶然或者无耦合/内聚，最高级别是内容/功能级别的耦合/内聚。

控制耦合：一个模块调用另一个模块，传递的是控制变量（）

内容耦合：指一个模块直接使用另外一个模块的数据。这是7/7级别耦合等级

人机界面设计

测试：动态测试；静态测试

测试阶段：

单元测试（模块测试），

集成测试（测接口之间的调用关系，一般依据概要设计），

确认测试（主要验证功能是否与需求一致，确认之后才能交付，分α和β测试）

系统测试

配置项测试

回归测试：变更之后，针对变更正确性的测试，以及对原系统的无损害。

测试模型：W模型-用来和V模型保持如影随形（看起来像个W）；H模型：更灵活，只要满足测试准备要求即测试

黑盒测试 白盒测试

调试（找出错误的代码和原因）

调试方法：穷举、回溯试探、演绎法、归纳法。这部分有的靠喜好和主观直觉，没有确定的套路

软件度量：McCabe度量法：又称为环路复杂度，假设有向图中有向边数为m，节点数为n，则此有向图的环路复杂度为 m-n+2.

系统维护

系统转换（遗留系统不再能满足新需求，新系统取代的过程）

三种转换策略：直接转换（风险很大）、并行转换（新老共同工作一段时间）、分段转换（子系统的逐步替换）

数据迁移：数据从旧数据库转移到新的数据库。

系统维护：正确性、适应性、完善性、预防性

净室软件工程：一种数学+统计学理论指导的软件开发，争取零缺陷。不是先制作再解bug，而是在规约中消除错误，达到“净”的开发。

技术手段：统计增量，函数式编程，正确性验证（核心）；缺点：太理论化，需要数学门槛，耗时，不鼓励单元测试带来了弊端。

基于构件的软件工程（CBSE）：将软件开发的重点 从程序编写转移到基于已有构件的组装。“用胶水拼接”

组装方式：顺序组装（构件1+构件2+...）；层次组装（构件1调用构件2）；叠加组装（构件以服务的形态工作）

UML

SysML：基于模型的模型的系统工程（MBSE）的标准建模语言，减少了UML的软件偏差，增加了需求图和参数图

面向对象技术

概念：对象，类，封装，继承，多态，重载...

面向对象的需求建模

用例模型：描述功能和用户如何与系统交互的模型。

分析模型：详细说明系统如何工作的模型，包括数据流、对象间的关系和系统的行为。

用例模型 + 分析模型 = 设计模型，设计模型：架构图、类图、用例图等。

面向对象设计五大原则

单一职责原则（Single Responsibility Principle）：一个类应该只有一个引起它变化的原因。

eg：A设计：class User{登录，注册}；B设计：User登录{ }，User注册{ }；B设计更符合SRP单一职责原则

开放-封闭原则（Open-Closed Principle）：软件实体应对扩展开放，对修改封闭。

理解：对扩展开放：软件实体应该能够轻松地添加新功能，而不需要对现有代码进行大量修改。

对修改封闭：现有代码应该足够稳定，不需要因为添加新功能而频繁修改。

举例：一个在线商店APP，如果每次添加新策略都需要修改现有代码，这就违反了OCP

里氏替换原则（Liskov Substitution Principle）：子类对象应该能够替换其父类对象被使用。

接口隔离原则（Interface Segregation Principle）：客户端不应该依赖它不使用的接口。

强调不应该强迫客户端依赖于它们不使用的接口，

依赖倒置原则：高层模块不应依赖于低层模块，两者都应该依赖于抽象。抽象不应依赖于细节，细节应依赖于抽象。

强调上层调用下层，强调使用接口而不是具体实现类。

项目管理

进度管理：WBS分解

进度安排：Gannt图、PERT图（PERT图就是类似关键路径图那样）

软件配置管理：版本号：0.xx为草稿版本，1.xx为正式版本。1.0是第一个正式版

质量管理：软件质量保证（SQA），主要关注点在：一开始就避免缺陷的产生

影响软件质量的环节：产品运行，产品修改，产品转移。

风险管理：

系统架构设计

软件架构的定义 包含组件、连接件、约束三大要素

软件架构生命周期：需求分析、设计 ~ 部署、后开发阶段

构件：构件是一个独立可交付的功能单元，外界通过接口访问其提供的服务。

构件接口：接口标准化是对接口中消息的格式、模式和协议的标准化。

面向构件的编程（COP）：多态性(可替代性);  模块封装性(高层次信息的隐藏);  后期的绑定和装载(部署独立性);  安全性(类型和模块安全性)。”

基于架构的软件开发方法（ABSD）

概念：架构驱动，强调由业务、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构

基础：功能的分解+选择架构风格+软件模版的使用

清晰性：迭代的每一个步骤都是清晰定义的

位于开发阶段：在需求分析之后，概要设计之前，是为了解决需求分析和软件设计之间的鸿沟问题。

架构需求与架构设计

架构设计所产生的文档：《架构规格说明》《架构质量设计说明书》

架构实现：分析与设计，构件实现，构件组装，系统测试。

架构演化：演化计划，构件变动，更新构件的相互作用，构件组装与测试，技术评审

软件架构风格

数据流风格：批处理架构，pipe架构

调用/返回风格：构件之间采用显式调用，代表有：主程序&子程序架构，面向对象，层次架构（含C/S架构,MVC / MVP / MVVM）

独立构件风格：构件之间相互独立，通过事件触发，异步方式执行。代表：进程通信，事件驱动架构。

虚拟机风格：解释器，一般ai领域和DSS用的较多

仓库风格：以数据为中心，如数据库系统

闭环控制架构：软硬件粗略地表示为一个循环。如嵌入式系统

C2架构风格：构件通过连接件组成到一起，可以形成链条或mesh结构。构件之间不可以直接相连

层次架构结构

        MVP算是对MVC的改进，MVVM则是颠覆性改动

MVVM：视图的数据的变化会同时修改数据源，而数据源数据的变化也会立即反应到 View 上。

SOA

企业服务总线：ESB客户端(服务请求者)、基础架构服务(中间件)、核心集成服务(提供服务)

DSSA 特定领域软件架构

概念：专一用于特定领域的软件构件的集合

三个基本活动：领域分析（识别信息源的调研），领域设计（建立领域模型，派生需求），领域实现（开发和组织领域可重用信息）

角色：领域专家（领域字典和需求的规约），领域分析师（知识工程），领域设计师（实现DSSA），领域实现人员（实现构件）

系统质量与架构评估

软件系统质量属性：

开发阶段：{可理解、可扩展、可维护、可移植、可测试、可重用}；  

运行阶段：{性能，安全，可伸缩，功能，互操作，可靠，可用，鲁棒}。

质量属性场景

系统架构评估：评估架构能否通过系统设计需求

三种常用的评估方式：基于调查；基于度量（eg用多少行代码）；基于场景（分析架构对应用场景的支持程度。主流）

重要概念：敏感点（为达成质量属性，构件所应具有的特性）；权衡点：改一个会影响多个构件质量属性的点；风险点。

架构的评估方法

基于场景的评估方法 SAAM （核心是将质量属性都映射为场景。最早广泛应用）

架构权衡分析法 ATAM (核心是对4个核心质量属性建立效能树，以权衡多个质量目标)

成本效益分析法 CBAM 是对ATAM的补充，确定质量合理的情况下再进行分析。

中间件技术

概念：提供不同层的互操作。比如通信中间件、事务中间件、交易中间件、数据存取中间件等

CORBA规范（也称CORBA架构）：分为三个层次：请求代理、服务、公共设施；

软件可靠性

概念

定量描述：规定时间、失效概率、失效强度，MTTF，MTTR，MTBF（后三者是失效的一些时间指标）

可靠性模型分类：对错误产生和分布的一些建模。比如种子法（标记重捕的方法估计程序的错误数），曲线拟合，执行路径分析，马尔科夫模型等

软件可靠性设计：冗余设计，N版本设计，恢复块设计（也称动态冗余，检验和灾备兼具的系统），

防卫式程序设计（撤销错误），双机备份，集群技术，负载均衡

架构的演化和维护

架构演化：对架构的修改和完善，目的是适应变化的纠错与完善性修改。是软件演化的一种手段。

架构演化能降低软件演化的成本的原因:

1）形式化、可视化表示提高了软件的可构造性

2）软件架构设计方案涵盖的整体结构信息、配置信息、约束信息等有助于演化环境的分析。

3）架构设计时对系统组件之间的耦合描述有助于软件系统的动态调整。

OOP架构演化：

对象演化（AddObj和DeleteObj，即AO和DO）；

消息演化（AddMessage(AM)、DeleteMessage(DM)、SwapMessageOrder(SMO)、overturMessage(OM)、ChangeMessageModule(CMM)5种 ）

复合片段演化：复合片段（Fragment）是对象交互关系的控制流描述，属于连接件

约束演化：增加和删除约束

软件架构演化方式

1）是否是运行时演化：分动态演化和静态演化

2）演化粒度不同：基于过程和函数的演化，基于对象的演化，基于组件的演化，基于架构的演化

软件架构演化原则

1.演化成本控制原则

2.进度可控原则

3 风险可控原则

4主体维持原则:保证软件系统主体行为稳定:

5.系统总体结构优化原则

6.平滑演化原则：演化速率趋于稳定。

7.目标一致原则

8.模块独立演化原则

9.影响可控原则

10.复杂性可控原则

11.有利于重构原则

12.有利于重用原则

13.设计原则遵从性原则：判断架构设计原则是否被破坏。

14.适应新技术原则

15.环境适应性原则

16 标准依从性原则

17.质量向好原则

18.适应新需求原则