【软考高项】十三、信息系统工程之软件工程

1、架构设计

核心问题：能否达到架构级的软件复用

架构风格：

数据流风格：批处理序列架构风格和管道/过滤器两种风格【批管】

调用/返回风格：主程序/子程序、数据抽象和面向对象，以及层次结构【主子抽象层面】

独立构件风格：进程通信和事件驱动的系统【进程办事】

虚拟机风格：解释器和基于规则的系统【解释规则】

仓库风格：数据库系统、黑板系统、超文本系统【库超黑】

评估人员关注重点：质量属性

敏感点：一个或多个构件的特性

权衡点：影响多个质量属性的特性

评估方式：调查问卷（或检查表）方式、基于场景的方式、基于度量的方式

其中基于场景的方式最为常用

分类：架构权衡分析法（ATAM）、软件架构分析法（SAAM）、成本效益分析法（CBAM）

描述对象：刺激、环境、响应

作用：分析软件架构对场景的支持程度，从而判断该架构对这—场景所代表的质量需求的满足程度

2、需求分析

2.1基础知识点

软件需求：系统必须完成的事以及必须具备的品质，包含业务需求、用户需求、系统需求

质量功能部署（QFD）：—种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度，包括常规需求、期望需求、意外需求

需求的过程：

需求获取：方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划

需求分析：对已经获取到的需求进行提炼、分析和审查，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方

面向对象的分析OOA模型包括用例模型和分析模型

结构化方法，核心是数据字典，模型包括：

数据模型---实体联系图（E-R图）

功能模型---数据流图（DFD）

行为模型（状态模型）---状态转换图（STD）

需求规格说明书编制:是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解

需求验证与确认:

需求评审：对SRS进行技术评审:二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法

需求测试：及早发现问题，从而在需求开发阶段以较低的代价解决这些问题

2.2 UML知识点

UML结构：构造块、规则和公共机制

UML中的事务：结构事物、行为事物（也称动作事物）、分组事物和注释事物（也称注解事物）

UML中关系：

依赖:是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义

关联:描述一组对象之间连接的结构关系。分为组合和聚合，都是部分和整体的关系，其中组合事物之间关:系更强，部分和整体之间有共同的生命周期。

泛化:一般/特殊的关系，子类和父类之间的关系。继承关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是子类的泛化

实现:是类之间的语义关系，一个类元指定了另一个类元保证执行的契约

UML6个依赖关系：关联、依赖、泛化、共享聚焦、组合聚焦、实现关系；关系的强弱顺序：泛化=实现>租合>聚合>关联>依赖

UML14种图：类图、对象图、构件图、组合结构图、用例图、顺序（序列）图、通信图、定时（计时）图、状态图、活动图、部署图、制品图、包图、交互概览图

UML5个系统视图：逻辑视图、进程视图、实现视图、部署视图、用例视图（裸线不用进）

2.3 其他知识点

面向对象分析阶段的核心工作是建立系统的用例模型与分析模型

OOA四个阶段：识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必须的。

用例之间关系：

包含关系:当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们

扩展关系:是如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰

泛化关系:当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。父子关系、一般和特殊关系。

3、软件设计

结构化设计SD：是一种面向数据流的方法，它以SRS和SA阶段所产生的DFD和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程；分为概要设计和详细设计两个阶段；

遵循一个基本的原则:高内聚，低耦合

内聚表示模块内部各成分之间的联系程度

耦合表示模块之间联系的程度

面向对象设计OOD：是OOA方法的延续，其基本思想包括抽象、封装和可扩展性（通过继承和多态来实现），原则包括：

设计模式：是前人经验的总结，它使人们可以方便地复用成功的软件设计

包含模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等基本要素

根据处理范围不同划分：

类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，属于静态关系

对象模式处理对象之间的关系，这些关系在运行时刻变化，更具动态性

根据目的和用途划分：

创建型模式：用于创建对象，包括工厂方法/抽象工厂/原型/单例/建造者模式

结构型模式：用于处理类或对象的组合包括适配器/桥接/组合/装饰/外观/享元/代理模式

行为型模式：用于描述类或对象的交互以及职责的分配包括职责链/命令/解释器/迭代器/中介者/备忘录/观察者/状态/策略/模板方法/访问者模式

4、软件实现

软件配置管理活动：

包括软件配置管理计划、软件配置标识、软件配置控制、软件配置状态记录、软件配置审计、软件发布管理与交付等活动【口诀：计时制，状态审计不符】

软件编码：把软件设计的结果翻译成计算机可以“理解和识别”的形式—用某种程序设计语言书写的程序

软件测试：目的是验证软件是否满足软件开发合同或项目开发计划、系统/子系统设计文档、SRS、软件设计说明和软件产品说明等规定的软件质量要求。通过测试发现软件缺陷，为软件产品的质量测量和评价提供依据

测试分类：静态、动态

静态测试：被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测

文档：检查单

代码：桌前检查、代码走查和代码审查

动态测试：

白盒：用于结构测试、单元测试；考虑程序内部结构和处理算法；测试方法有控制流测试、数据流测试和程序变异测试；最常用的技术是逻辑覆盖，主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖

黑盒：用于功能测试、集成测试、确认测试和系统测试；完全不考虑（或不了解）程序的内部结构和处理算法；测试方法：等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法

5、部署交付

部署活动（持续不断）：包括软件打包、安装、配置、测试、集成和更新

持续部署：属于软件开发的后期活动，即通过配置、安装和激活等活动来保障软件制品的后续运行。

持续交付：完全自动化过程，一键部署；体现在需求、开发测试、运维阶段

持续部署方案：容器技术目前是部署中最流行的技术，常用持续部署方案Kubernetes+Docker和Matrix系统两种

部署原则：

部署层次：

不可变服务器：是一种部署模式，是指除了更新和安装补丁程序以外，不对服务器进行任何更改

蓝绿部署和金丝雀部署：

蓝绿：在部署的时候准备新旧两个部署版本，通过域名解析切换的方式将用户使用环境切换到新版本中，当出现问题的时候，可以快速地将用户环境切回旧版本，并对新版本进行修复和调整【双卡双待，备胎】

金丝雀：当有新版本发布的时候，先让少量用户使用新版本，并且观察新版本是否存在问题。如果出现问题，就及时处理并重新发布;如果一切正常，就稳步地将新版本适配给所有的用户【试错】

部署与交付的新趋势：