软件架构知识点

1.绪论

常用软件架构模型分类（5种）

软件架构建模方法（模型4种）

架构师分类（微软4种）

系统架构设计师的角色特质（6种）

2.计算机系统基础

计算机系统组成图谱

嵌入式操作系统的特点（5个）

中间件的定义

中间件的分类（8种）

嵌入式系统软件的组成架构（5层）

7层网络协议：开发系统互联/参考模型 OSI/RM

UML中的4种关系

3.信息系统基础

信息系统：
信息系统的组成

信息系统的定义

信息系统的分类（5种）

信息系统常用开发方法（4种）

4.信息安全技术基础

信息系统加解密技术：
对称密钥 DES/IDEA/AES

非对称加密 RSA

5.软件工程基础

软件过程模型

• 瀑布
• 原型
• 螺旋

敏捷模型

• 极限编程（轻量级、小周期）
• 水晶
• scrum（侧重项目管理，sprint backlog）
• FDD（特征列表）

统一过程模型RUP

• 特点：用力驱动、体系结构、迭代
• 4+1视图

软件能力成熟度模型CMM：5个等级

系统分析与设计：

• 结构化方法：
  • SA：数据流图DF D、数据字典
  • SD
  • SP
• 面向对象方法：
  • OOA
  • OOD
  • OOP

软件设计考题（案例分析试题二）

2022 结构化（煤炭生产安全预警系统）
结构化分析和设计阶段中，数据流图和数据字典的作用

• 需求分析：数据流图（数据输入、流向、处理过程、输出），清晰反映系统的功能，检查信息遗漏或逻辑错误。数据字典（描述数据的信息集合），让参与人员对数据有统一的认知。
• 设计阶段：数据流图，变换分析和事务分析，设计出系统的模块结构（系统结构图）。数据字典，根据数据储存描述建立数据库存储设计。

DFD在分层细化过程中的数据平衡原则：

• 层间平衡：不同层次间，相同数据流的个数和方向一致
• 图内平衡：避免黑洞、奇迹、灰洞

2021 面向对象（医院预约挂号管理系统）
面向对象开发，通常需要建立对象模型、动态模型和功能模型。介绍三种模型、及关联关系、哪些可用于需求分析

• 对象模型：描述了系统中对象的静态结构、对象之间的关系、属性和操作（偏向于描述“发生的客体”），用对象图来实现
• 动态模型：描述与实践和操作顺序有关的系统特征（偏向于描述“什么时候发生的”），用顺序图、状态图、活动图等来实现
• 功能模型：侧重于描述系统的功能（从输入怎样得到输出，偏向于描述“发生了什么”），不考虑具体实现过程，用DFD来实现
  这些模型均可用于需求分析

2020 未考此知识点（关系型数据库）

2019 数据流图（在线订餐管理系统）
数据流图与系统流程图的区别

• 展现内容：数据流图，展现了系统的数据流。系统流程图，展现系统的控制流
• 是否可并行：数据流图，处理过程可并行。系统流程图，某个时间点只能处于一个处理过程
• 计时标准：数据流图，展现全局的处理过程，过程之间遵循不同的计时标准。系统流程图，处理过程遵循一致的计时标准。

2018 软件系统建模（房屋租赁服务系统）

• 信息工程中的“实体”与面向对象方法中的“类”的区别
  • 实体用于数据建模，而类用于面向对象建模。实体只有属性，而类有属性和操作。
• 面向对象方法中采用的Essential Use Cases和Real Use Cases区别
  • Real Use Cases基础用例是实实在在与用户需求有对应关系的用例，是从用户需求获取的渠道得到的
  • Essential Use Case抽象用例，抽象用例是从基础用例中抽取的用例的公共部分，是为了避免重复工作，优化结构而提出的用例。

2016 用例建模

• 面向对象的系统建模，用例之间的关系：

  • 泛化 generalization
  • 包含 include
  • 拓展 extend
    用例“登录系统”与用例“注册课程”之间的关系是包含(Include)关系；用例“参加考试”与用例“参加补考”之间的关系是扩展(Extend)关系

• 类之间的关系

  • 依赖
  • 关联
  • 泛化
  • 组合
    类University与类Student之间的关系是整体与部分关系，而且具有不同的生存周期，所以是聚集(Aggregation)关系。类University和类Department之间的关系是整体与部分的关系，两者具有相同的生存周期，所以是组合(Composition)关系。类Student和类Course之间为连接关系，所以属于关联(Association)关系

2015 系统设计建模
状态图和活动图
状态图：一个对象经历的状态序列，引起状态转移的event，状态转移伴随的action。侧重于描述行为的结果，不可并发
活动图：系统的工作流程和并发行为。侧重于描述行为的动作，可描述并发

6.数据库设计基础

数据库缓存（案例分析题4）

2022 大型电商平台的数据库缓存问题

• 1.对于缓存与数据库的一致性问题，对比数据实时同步更新方案和异步准实时更新方案

  • 实时同步更新方案：把订单反馈作为事务，只有缓存和数据库中的数据都完成更新，才算提交成功。
  • 异步准实时：数据库采用同步更新，缓存通过订阅消息队列进行异步更新。
  • 推荐采用异步准实时：因为本项目数据量大，且性能要求高。

• 2.对于缓存分片方法，对比哈希算法和一致性哈希算法

  • 哈希算法：把任意长的输入通过哈希算法变换成固定长度的哈希值。对于缓存分片，可以把每个部分（分片）的缓存内容进行哈希算法，得到一个固定长度的简短信息。但是不同的输入，可能会哈希出相同的结果。
  • 一致性哈希：一种特殊的哈希算法，将整个哈希值空间映射成一个按顺时针方向组织的虚拟圆环，使用哈希算法计算出的哈希值，沿圆环顺时针查找，将数据分配到第一个遇到的集群节点进行缓存。优点是：可扩展，更好适应数据的快速增长。
  • 推荐采用一致性哈希

• 3.对于黑客造成的缓存击穿，解释布隆过滤器的工作原理和优缺点

  • 布隆过滤器：当一个元素加入集合时，通过K个散列函数将这个元素映射成一个位数组中的K个点，把他们置为1。检索时，只要看这K个时不时都是1，就能知道集合中有没有它。有一个不为1，肯定不在。如果都是1，就很可能在。
  • 优点：

2.某医药销售平台的数据库设计

• 对于数据库性能较差，说明常见的反规范化设计方法
  • 重复列、冗余列、重组表
• 对于反规范化设计带来的数据不一致问题，说明3中常见的解决方法
  • 触发器、批处理维护、应用逻辑
  • 定时同步（非实时）：定时将MySQL数据同步到redis，实现简单，可能导致数据不一致。
• 采用Redis来实现某些特定功能，说明解决Redis和My SQL数据实时同步问题的常见解决方案
  • 实时同步（准实时）：通过消息队列或触发器，当MySQL数据更新时，消息队列或触发器立即通知redis进行更新。优点是实时性高，缺点是实现复杂。
  • 双写模式（真实时）：MySQL和redis同时写入，确保数据一致。优点是实现简单，缺点是影响性能。

3.某网上社区平台

• 采用Redis+数据库的方案，采用哪些数据类型
• 为了防止数据丢失，存到磁盘，使用Redis持久化支持。从磁盘更新效率、数据安全、数据一致性、重启性能和数据文件大小五个方面比较RDB（redis data base）持久化和AOF（append only file）持久化
  • RDB：把内存数据以快照的形式保存在磁盘，redis重启的时候通过加载数据集快照来恢复数据。
    • 优点：文件小，性能高，数据恢复快。适合大规模的数据恢复场景。缺点：没办法做到实时/秒级的数据持久化。
  • AOF：采用日志的形式记录每个写操作，追加到文件中，重启的时候重新执行AOF文件中的命令来恢复数据。
    • 优点：数据的一致性好，更新频率高，数据完整性更高更安全。缺点：AOF记录的内容越多，文件越大，数据恢复慢，性能低。
• redis “定期删除+惰性删除”的失效场景，给出3种内存淘汰机制
  • 删除策略：
    • 定时删除：每个key设置一个过期时间，过期则清除。对内存友好，但是会占用大量的CPU，影响缓存的响应时间。
    • 惰性删除：每个key访问时才判断是否过期，过期则清除。对CPU友好，对内存不友好，可能有大量key没有被再次访问，占用内存。
    • 定期删除：每隔一段时间扫描一定数量的key，清除已过期的key，达到CPU与内存平衡。
  • redis同时使用定期删除和惰性删除，失效场景是：大量过期的key没有在定期删除中清除，也没有被访问。导致内存被大量占用。
  • 内存淘汰策略
    • volatile-lru：当内存不足以容纳新写入数据时，从设置了过期时间的key中使用LRU“最近最少使用”算法进行淘汰（least recently used）
    • allkeys-lru：当内存不足以容纳新写入数据时，从所有key中使用LRU算法进行淘汰
    • volatile-lfu：当……，从设置了过期时间的key中，使用LFU“使用次数最少”算法进行淘汰（least frequently used）
    • allkeys-lfu

2015
文件系统 vs 关系数据库
文件系统具有以下特点：
•针对特定应用系统设计，难度较小；
•数据冗余较大，可能在多个文件中复制相同的数据属性；
•以应用系统为中心组织、管理数据；
•符合特定应用系统要求的文件数据很难在不同的应用系统之间共享。

关系型数据库具有以下特点。
•数据结构需要符合关系模式，设计难度较大；
•遵守数据库范式，数据冗余较少；
•以数据库为中心组织、管理数据；
•数据独立于应用系统，很容易在不同的应用系统之间共享数据。

7.系统架构设计基础

基于架构的软件设计AB SD：自顶向下、递归细化

软件架构风格：
数据流
调用/返回体
数据为中心
虚拟机
独立构件

架构风格对比（案例分析试题一）

2022 面向对象 vs 解释器 （电商平台会员促销管理系统）

• 可修改性：面向对象，编写新的规则实现代码，应用重启或热加载添加规则，可修改性稍差。解释器，编写新的规则文件，导入或配置添加规则，可修改性好
• 灵活性：面向对象，以程序逻辑实现规则，灵活性较差。解释器，可灵活定义规则计算表达式，灵活性更好
• 系统性能：面向对象，源代码编译后运行，性能好。解释器，加载、解析规则、规则运算，性能较差。
  推荐使用解释器

2021 解释器 vs 管道过滤器 vs 隐式调用 （机器学习应用在线开发平台）

• 灵活性、可扩展性
• 管道-过滤器风格：高内低耦，扩展性好，支持重用和并发，但不适合交互。
• 隐式调用：基于事件触发的思想，支持重用，改进系统方便。但是放弃了对系统计算的控制、事件传递中的数据交换存在问题等缺点。
• 解释器：针对不同的语法规则，只需对解释器进行拓展，灵活性和扩展性较好
  推荐使用解释器

2020 管道-过滤器 vs 仓库 （在线软件开发系统）

• 数据处理和交互性：管道过滤器，数据驱动，处理流程事先确定，交互性差。仓库，数据统一保存在中央仓库，流程独立，支持交互
• 可扩展性：管道-过滤器，易添加新的过滤器，扩展性好。仓库，数据与处理解耦，可动态添加处理组件
• 处理性能：管道-过滤器，支持过滤器并发（优势），但是需要数据格式转换（劣势）。仓库，不支持并发（劣势），但是容错健壮性好（优势）
  采用仓库架构风格更合适 （各功能相对独立、代码通过中央数据单元存储）

2019 面向对象 vs 基于规则（电商平台用户管理系统）

• 灵活性：面向对象，将用户级别和折扣规则封装为对象，启动时加载。基于规则，建立用户级别-折扣规则矩阵，启动时加载，支持运行时动态更新，灵活性好。
• 可扩展性：面向对象，需要增加相应的类来拓展，应用重启或热加载来添加，扩展性稍差。基于规则，定义新的规则，解释规则即可拓展，扩展性好。
• 性能：面向对象，源代码编译后运行，性能较好。基于规则，需要对规则进行实时解释，性能较差。
  采用基于规则的虚拟机架构风格

2017 管道-过滤器 vs 仓库
仓库：交互方式-通过数据仓库间接交互。扩展方法-与数据仓库进行数据适配
管道-过滤器：数据结构-流式数据。控制结构：数据驱动

特定领域软件体系结构DSS A：

• 领域分析
• 领域设计
• 领域实现

8.系统质量属性与架构评估

面向架构评估的质量属性：
性能
可靠性：容错、健壮
可用性：正常运行时间比例
安全性：组织非法、机密
可修改性：高性价比变更
功能性
可变性
互操作性

系统架构评估方法：
SAAM（架构分析）
ATAM（架构权衡）效用树
CBAM（成本效益）

9 软件可靠性基础

软件可靠性：
定义：
定量描述：F(t), R(t), f(t), MTTF, MTTR, MTBF
可靠性设计技术（4种）

10.软件架构演化和维护

软件架构演化：
静态演化
动态演化
演化原则（18种）
大型网站系统架构演化实例： 单体 - 垂直 - 缓存 - 服务集群 - 读写分离 - 反响代理/CDN - 分布式文件/数据库 - NoSQL和搜索引擎 - 业务拆分 - 分布式服务
架构维护：度量指标（6个）

11.未来信息综合技术

• 信息物理 CPS
  定义
  典型应用场景（4个）

• 人工智能AI

  • 定义
  • 关键技术：NLP/CV/knowledge graph/H-CI/VR/AR/ML
  • ML分类：
    • 学习模式分类
    • 学习方法分类
    • 典型算法
      • 传统机器学习算法
      • 深度学习算法

• 机器人技术

  • 机器人4.0核心技术：云边端的协同计算，持续学习与协同学习、知识图谱、场景自适应、数据安全

• 边缘计算

  • 定义
  • 应用场景

• 数字孪生体

  • 定义
  • 关键技术
  • 应用场景

• 云计算和大数据

  • 云计算服务方法：SaaS/PaaS/IaaS
  • 云计算部署模式
  • 大数据分析的5个阶段

WEB系统架构设计
案例分析试题5
2022

1. 基于边缘计算的智能门禁系统（根据业务需求，结合边缘计算的思想，从技术层面提出该系统可以Flask框架与SSM框架为基础来开发后台服务器，通过Docker部署，使用MQTT协议对Docker进行管理）

   • MQTT协议在工业物联网广泛应用，说明MQTT协议（并简要对比HTTP）

     • Message Queuing Telemetry Transport，即消息队列遥测传输协议，是一个基于pub/sub（发布/订阅）的轻量级的即时通信传输协议
     • 可以用极少的代码和有限的带宽，为连接的远程设备提供实时可靠的消息服务
     • 为不稳定的网络环境中低算能、低带宽的边缘物联网设备提供可靠的网络服务

   • 基于边缘计算的智能门禁系统架构图

     • 前端 - 边缘设备 - 云平台 - 数据库

   • 从数据通信、数据安全和系统性能等方面简要分析在传统云计算模型中引入边缘计算模型的优势

     • 数据通信：很多计算在边缘设备或边缘数据中心处理，数据无需回传中央服务器，极大地降低了网络负载，同时降低时延
     • 数据安全：边缘计算在不同的数据中心和设备之间分配数据处理工作，黑客无法通过攻击一台设备来影响整个网络
     • 系统性能：很多计算功能在边缘设备完成，不依赖中央服务器，系统性能更高

2. 基于云平台的智能家居管理系统

   • 从网关管理、数据处理和系统性能等方面，对比基于家庭网关的传统智能家居管理系统和基于云平台的智能家居管理系统
     • 网关管理：基于云平台，将分散的智能家居网关数据集中起来，实现对智能家居的远程高效管理
     • 数据处理：云端服务器对智能家居数据进行备份存储，可在数据丢失时通过云端管理系统对网关数据进行恢复，提高数据容灾性
     • 系统性能：将数据存储在云端，减少了数据请求时间，提高了通信效率
   • 基于云平台的智能家居管理系统的架构图
     • 客户端 - 云平台层 - 网关层（家庭网关） - 家电设备
   • 该系统需要实现双向可靠通信，从数据传输可靠性的角度对比TCP和UDP通信协议的不同
     • TCP采用了重发技术，为应用程序提供可靠的、面向连接的、全双工的数据传输服务
     • UDP是一种不可靠的、无连接的协议

3. 基于web的工业设备检测系统（采用三层拓扑结构，即现场设备的数据采集层、web检测服务层、前端web显示层）

• 该系统拟采用SSM开发，补全其工作流程图（Spring + Spring MVC + Mybatis框架，由Spring、Spring MVC、Mybatis框架整合而成，常作为数据源较简单的web项目框架）（JSP：java sever pages， java服务器页面，替代servlet输出HTML）
  • 显示层 （JSP engine）- 控制层 （Spring MVC）- 业务层 （Spring）- 持续层 （Mybatis）- 连接池 - 数据库
• 该系统拟采用工业控制领域中统一的数据访问机制，实现与多种不同设备的数据交互，说明采用标准的数据访问机制的原因
  • 提供了不同标准之间的数据访问机制，屏蔽了不同通信协议之间的差异，为上层应用提供统一的借口
  • 容易实现应用程序对不同协议设备的互操作
  • 独立于平台，具有语言无关性、代码重用性、易于集成等优点

2017
1.响应式web设计的实现方式
1）流式布局 2）弹性布局

2.引入主从复制机制的好处
1）提升性能，一主多从，高并发
2）可扩展，增加从服务器
3）提高可用性，单机故障
4）数据安全性，冗余备份

12.信息系统架构

信息系统架构

• 分类
  • 物理结构
  • 逻辑结构
• 架构模型：Standalone C/S SOA 交换总线
• 企业信息系统框架（3层）
  • 战略 - 业务/应用 - 基础设施
• 信息系统架构设计方法
  • ADM
    • TOGAF
    • ADM阶段（全生命周期模型）
• 信息化总体架构方法
  • 信息化特征（6个）
  • 信息化工程建设方法
    • 架构模式
    • 建设生命周期
• 信息化系统架构案例分析
  • web服务
  • 以服务为中心

13.层次式架构

常见的层次式架构

表现层框架设计

• MVC
• MVP
• MVVM
• XML
• UIP组件功能

中间层架构设计

• 逻辑层组件设计
• 业务逻辑层框架

数据访问层设计

• 数据访问模式（5种）
• ORM、Hibernate
• 事务处理ACID原则

数据层设计

• 数据库设计与XML设计融合
• 物联网层次架构（3层）

层次式架构案例

• 电子商务网站
• 电子小票服务系统

14.云原生架构

Cloud Nativa特点：云的弹性和分布式
技术部分包含：IaaS、PaaS、SaaS
云原生架构原则：

• 服务化
• 弹性
• 可观测
• 韧性
• 自动化
• 零信任
• 持续演进
  云原生主要架构模式
• 服务化
• mesh化
• Serverless模式
• 存储计算分离
• 分布式事务
• 可观测架构
• 事件驱动
  相关技术
• 容器
• 微服务
• 无服务
• 服务网络
  案例
• 云原生改造
• 数字化转型

15.面向服务架构

SOA定义：应用角度、软件原理
微服务VS传统SOA：服务更精细、接口更通用、分布式中心化
SOA参考架构——6大类服务

• 业务逻辑服务
• 控制服务
• 连接服务
• 业务创新和优化服务
• 开发服务
• IT服务管理
  SOA主要协议和规范——WS-*
• UDDI协议（统一描述、发现、集成协议）
• WSDL规范
• SOAP协议
• REST规范
  SOA设计原则：无状态、单一实例、明确接口、自包含和模块化、粗粒度、松耦合、重用、互操作和兼容
  SOA的设计模式：
• 服务注册表
• 企业服务总线
• 微服务

16.嵌入式系统架构

17.通信系统架构

18.安全架构

19.大数据架构

20.架构师论文

请围绕“xxx”论题，依次从以下3个方面进行论述：
1）概要叙述你参与管理和开发的软件项目，以及你在其中承担的主要工作
2）详细论述……
3）结合你具体参与管理和开发的实际项目，请说明具体实施/维护过程以及碰到的主要问题
摘要400字 + 正文 2000～3000字
论文6大方向（系统建模、系统设计、架构设计、分布式、可靠性、安全保密性）

2022

1. 基于构件的软件开发方法及应用

• CBSD:基于构件的软件开发过程主要是构建组装的过程，不再一切从头开始，优点是提高软件的开发效率，提高可维护性。
• CBSD五个阶段：
  • 需求分析和定义
  • 架构设计
  • 构建库建立（检索-复用，新建）
  • 应用软件构建（构建的组装，基于功能、基于数据、面向对象）
  • 测试和发布

2. 论软件维护方法及其应用

   • 影响软件可维护性的因素：
     • 可理解性（源码、文档）
     • 可测试性（设计简单、复杂度低）
     • 可修改性（通过修改实验来评价）
     • 可靠性（在给定的时间段内正确运行的概率）
     • 可使用性（用户首次使用并掌握常用功能的平均用时）
     • 效率（完成用户期望的功能，又不浪费机器资源的程度）

3. 论区块链技术及其应用

   • 特性：不可伪造、全程留痕、公开可追溯
   • 四大核心技术：分布式账本、非对称加密、共识机制

2021
4. 论面向方面的编程技术及其应用AOP
- AOP（aspect oriented programming）：是OOP的补充和完善，OOP可以定义从上到下的关系，但不适合定义从左到右的关系（分散的对象引入公共行为），例如日志功能。日志代码、安全性、异常处理，这种散布在各处的无关的代码成为横切Cross-Cutting代码，在OOP中会导致大量代码重复。AOP利用“横切”技术，将“横切”关注点（如日志、安全等）与业务逻辑分离，从而提供代码的模块化和可维护性。
- 三个开发步骤：
- 分解系统需求
- 单独完成各关注点的编码和实现，构建系统Aspect和系统组件
- 用联接器制定的重组规则，将系统组件代码和Aspect代码进行组合，形成最终系统

5. 论系统安全架构设计及其应用

   • 系统安全架构：系统设计和开发过程中，考虑如何保护系统免受未经授权的访问、攻击和破坏。
   • 常用安全架构设计：
     • 前后分层的安全设计：各层有自己的职责和权限
     • 按业务切割的安全设计：按业务切分为不同的单元
     • 加密：使用加密技术保护数据
     • 鉴别：防止其他实体占用和独立操作被鉴别实体的身份
     • 访问控制：身份验证和授权机制来限制对系统的访问
     • 蜜罐：包含漏洞的诱骗系统，诱导攻击者发起攻击来留下痕迹和证据
     • 防火墙：过滤网络流量，防止未经授权的访问和攻击
     • 入侵检测与防护：寻找违反安全策略的行为，并发出报警，或主动防护

6. 论企业集成平台的理解与应用

   • 集成平台：支持企业集成的支撑环境，包括硬件、软件、软件工具、系统，通过集成各种企业应用软件形成企业集成系统。
   • 集成平台基本功能：
     • 通信服务：分布环境下透明的同步/异步通信服务功能
     • 信息集成服务：透明的信息访问服务
     • 应用集成服务：通过高层应用编程接口来实现对相应应用程序的访问
     • 二次开发工具：帮助用户开发特定应用程序的支持工具
     • 平台运行管理工具：企业集成平台的运行管理和控制模块

2020
7. 论企业集成架构设计及其应用
- 企业集成架构有3类：数据集成、应用集成、企业集成
- 数据集成：解决不同应用和系统间的数据共享和交换需求，包括3部分：共享信息管理、共享模型管理、数据操作管理
- 应用集成：两个或多个应用系统根据业务逻辑需要而进行的功能之间的互相调用和互操作
- 企业集成：采用3层机构，最大程度提高系统 的柔性：表示层、业务逻辑层、数据层

8. 论软件测试中缺陷管理及其应用

   • 软件缺陷：计算机软件或程序中存在的某种破坏正常运行能力的问题、错误、隐藏的功能缺陷。
   • 缺陷产生：缺陷的产生是不可避免的，主要由产品的特点或开发过程决定
     • 软件本身：需求不清晰、边界考虑不周全、技术或系统的兼容性问题
     • 团队工作：需求理解错误、理解不一致、编程技术问题
     • 技术问题：算法错误、语法错误、接口参数不匹配、计算精度问题
     • 项目管理问题：缺乏质量文化、对客户需求不清楚、开发周期太短、开发流程不完善

9. 论云原生架构及其应用

   • 云原生机构设计原则
     • 服务化原则：拆分为不同生命周期的业务单元，采用面向接口编程方式
     • 弹性原则：部署规模随着业务量的变化自动调整大小
     • 可观测原则：主动通过日志、链路跟踪、度量等手段，让系统的使用记录清晰可见
     • 韧性原则：依赖的软硬件出现异常时，软件所表现出来的抵御能力
     • 自动化原则：通过GitOps、IaC、OAM等自动化交付工具在CI/CD流水线实现软件交付和运维的自动化

2019
10. 论软件设计方法及其应用
- 系统设计的主要方法
- 净室方法：软件开发的一种形式化方法，可以生成高质量的软件。使用盒结构规约来进行分析和设计建模
- 结构化方法：
- 结构化分析：按照系统中数据处理的流程，用数据流图建立系统的功能模型，从而完成需求分析
- 结构化设计：
- 结构化编程：
- 面向对象方法：

11. 论软件架构评估及其应用
    • 架构评估中关注的质量属性包括：
      • 性能
      • 可靠性
      • 可用性
      • 安全性
      • 可修改性
      • 功能性
      • 可变性
      • 互操作性
    • 架构评估的主要方法：
      • 基于场景
        • 架构权衡分析法ATAM：在系统开发之前，对性能、可用性、安全性等质量属性进行评价和折中。包括需求收集、架构视图描述、属性模型构造和分析、架构决策和折中
        • 软件架构分析方法SAAM：场景开发、架构描述、单个场景评估、场景交互和总体评估
      • 基于调查问卷
      • 基于度量
12. 论数据湖技术及其应用
13. 论负载均衡在web系统中的应用
    • 负载均衡在高并发、高性能、高可用三高架构中的意义和作用
    • 常用的负载均衡算法和基本原理（选择3种）
      • 轮询算法
      • 随机算法
      • 比率算法
      • 优先级算法
      • 最少连接数算法
      • 最快响应时间算法
    • 在项目中实现的效果

2018
15. 论软件开发过程RUP及其应用
16. 论软件体系结构的演化
17. 论面向服务架构设计

范文大纲

软件架构风格选择

• 摘要：2021年5月，我参加了……项目的开发，担任……。该系统旨在……，最终实现……。本文以……为例，论述了……，实现了……，同时证明了……。该系统于……，得到了……。
• 正文
  • 背景：2021年初集团提出……战略，传统的……人力物力成本。组件开发团队……
  • 概述：系统经仔细研究后拆分为4个主要模块……设备接入、消息处理、规则模块、业务模块
  • 过渡：架构风格……
  • 技术介绍：常见的5大类架构风格……
  • 结合项目：设备接入-面向对象，消息处理-管道/过滤器，规则模块-基于规则，业务模块-进程通信……
  • 总结：结合本次项目整体的开发来看，良好的架构风格……同时，我在项目开发过程中也遇到了一些问题……。本次项目为我在……，同时也暴露了一些不足……