软考系统架构师——背诵版

软件工程

  • 🌟软件需求开发的最终文档,通过评审后定义了开发工作的需求基线,它在客户和开发者之间构筑了产品功能需求和非功能需求的一个需求约定,是需求开发和需求管理之间的桥梁。
    • 软件评审是软件质量保证的主要活动之一。
  • 🌟🌟在企业内部的信息集成中,应用系统集成实现了不同系统之间的互操作,业务过程集成实现了不同应用系统之间的连接、协作和信息共享。
  • 🌟软件活动主要包括软件描述、软件开发、软件有效性验证和软件进化
  • 🌟面向对象的模型
    • 分析模型 = 顶层架构图+用例与用例图+领域概念模型
    • 设计模型 = 以包图表示的软件体系结构图、以交互图表示的用例实现图+类图+描述复杂对象的状态图+用于描述流程化处理过程的活动图
  • CORBA:Common Object Request Broker Architecture,公共对象请求代理架构
    • 真正实现:🌟Servant 伺服对象
  • UML 的 “4+1”视图
    • 🌟实现视图/开发视图:开发者,查看配置,物理代码的文件和构件,静态组织结构
      • 包图、组件图
    • 🌟进程视图/过程视图:集成者,查看性能,逻辑视图的一次执行实例,描述了并发与同步结构
      • 活动图
    • 部署视图/物理视图:系统工程师,查看拓扑,软件到硬件的映射和分布结构
      • 部署图
    • 逻辑视图:最终用户,查看功能,描述涉及的对象模型和对象间的关系
      • 类图、对象图、状态图、协作图
    • 用例视图/场景视图:测试者,查看行为,需求分析模型
  • 🌟ERP:Enterprise Resource Planning,企业资源规划。包括三大流:物流、资金流、信息流。(没有工作流)
    • 生产计划大纲:根据经营计划的生产目标制定,对企业经营计划的细化。
    • 主生产计划:说明了在一定时期内生产什么、生产多少、交货时间
    • 能力需求计划:能够帮助企业尽早发现企业生产能力的瓶颈
  • 🌟G2G:人口信息采集处理和利用业务
  • 🌟螺旋模型:循环+里程碑,在原型模型的基础上结合瀑布模型扩展而成,每个阶段包含 4 部分:目标设定、风险分析、开发、有效性验证评审,强调其他模型忽视的风险分析。但是执行风险分析将会影响项目的利润。
  • 敏捷模型(Agile):敏捷开发以人为本,而非以过程为本。
    • XP:Extreme Programming,极限编程。高效、低风险、测试先行。
    • 水晶系列方法:不同项目,不同策略
    • Scrum:并列争球法,侧重于项目管理
    • 🌟FDD:Feature Driven Development,特征驱动开发方法,将开发人员分为首席程序员(项目的协调者、设计者和指导者)、类程序员(源码编写)
  • 🌟开放式源码开发方法适用于程序员在地域上分布很广的开发团队。
  • ASD:Adaptive Software Development,自适应软件开发,核心是三个非线性的、重叠的开发阶段:猜测、合作、学习
  • 🌟ABSD:Architecture Based Software Development,基于架构的软件开发
    • 🌟采用视角与类图来描述软件架构
    • 🌟采用用例来描述功能需求,采用质量场景来描述质量需求
    • 三个基础:功能分解、选择架构风格实现质量及商业需求、软件模板的使用。
    • 🌟包含六个子过程:需求、设计、文档化、复审、实现和演化。
      • 🌟文档化:不要求随时保证文档是最新的,最终输出结果是架构规格说明书和架构质量说明书
  • RUP:Rational Unified Process,统一软件开发过程。3 个核心特点
    • 以架构为中心
    • 用例驱动
    • 增量与迭代:在软件开发的早期就可以对关键的、影响大的风险进行处理
  • RE:Requirement Engineering,需求工程,包含需求获取、需求分析、形成需求规格(需求文档化)、需求确认与验证、需求管理 5 个阶段
  • 测试阶段可以分为单元测试、集成测试、系统测试(是否满足 SRS)、验收测试
    • 在单元测试中,驱动模块用来调用被测模块,桩模块用来模拟被测模块所调用的模块。
  • 动态测试:通过运行程序发现错误
    • 黑盒测试:等价类划分、边界值分析法、错误推测法
      • 无效等价类:用来测试非正常输入的数据,也需要设计测试用例。
    • 白盒测试:各种类型的覆盖测试
  • 静态测试:人工测试,包括桌前(桌面)检查、代码走查、代码审查
  • 🌟CSE:Cleanroom Software Engineering,净室软件工程,是一种形式化方法,理论基础主要是函数理论和抽象理论,使用盒子结构规约进行分析和设计建模,并将正确性验证作为发现和排除错误的主要机制,缺点是太理论化、忽视测试、带有传统软件工程的弊端。
  • 🌟形式化开发方法是建立在严格的数学基础上的软件开发方法。
  • CBSE:Component-Based Software Engineering,基于构件的软件工程,模型要素为接口、使用信息、部署信息
  • 需求分析阶段:数据流图
  • 🌟概要设计阶段:模块结构图、层次图、HIPO 图
  • 详细设计阶段:程序流程图、伪代码、盒图
  • 🌟检错设计技术的 4 个考虑要素:检测对象、检测延时、实现方法、处理方式。

UML图

  • 结构行为图
    • 类图:描述类的静态结构
    • 对象图:描述多个对象在某一时刻的状态
    • 组件图:描述系统的静态实现视图
    • 部署图:定义软硬件的物理结构
    • 用例图:从用户角度描述系统功能
  • 动态行为图
    • 序列图:强调对象发送消息的顺序,显示对象之间的交互
    • 协作图:描述对象之间的协作关系
    • 状态图:描述状态之间控制流,常用语动态特性建模
    • 活动图:描述业务实现用例的工作流程

架构模型和方法

  • DSSA:Domain Specific Software Architecture,特定领域软件架构。
    • 🌟领域设计活动主要目的是为了获得 DSSA(特定领域软件架构)
    • 🌟领域分析的主要目的是获得领域模型
    • 🌟领域实现是为了开发和组织可重用信息,对基础软件架构进行实现
    • 该活动参加人员中,领域专家的主要任务是提供关于领域中系统的需求规约和实现的知识。
    • 🌟垂直域关注行业特性,水平域关注行业共性
    • DSSA 通常有三个层次的系统模型
      • 领域开发环境
      • 领域特定应用开发环境 —— 应用工程师
      • 应用执行环境
  • ATAM:Architecture Tradeoff Analysis Method,架构权衡分析法,强调以属性作为架构评估的核心概念。
    • 是在基于场景的架构分析基础上发展起来的,该方法要求在系统开发之前,首先对这些质量属性进行评价和折中。🌟主要包括4个阶段:
      • 场景和需求收集
      • 架构视图和场景实现
      • 属性模型构造和分析
      • 属性模型折中
    • 可用性:Ping/Echo、心跳、主动冗余、被动冗余、选举
    • 性能:队列调度、资源调度资源仲裁、引入并发机制
      • 🌟性能评估的目的是找出系统可能存在的性能瓶颈。(而不是性价比)
    • 可修改性:信息隐藏、可维护性、可扩展性、结构重构、可移植性
    • 安全性:入侵检测、认证授权、追踪审计
  • SAAM:Software Architecture Analysis Method,软件架构分析方法,主要分析可修改性,应用于空中交通管制系统、嵌入式音频系统、修正控制系统。
  • 🌟CSF:Critical Success Factors,关键成功因素法。通过对关键成功因素的识别,确定系统开发的优先次序,通过对组织的目标分解和关键成功因素识别、🌟性能指标识别,一直到产生数据字典。
  • 🌟📖云原生原则
    • 服务化:面向接口编程,增强复用和水平扩展能力。
    • 弹性:自动扩缩容
    • 可观测:通过日志、链路跟踪、度量等手段,让一次App点击所产生的多次服务调用耗时、返回值、参数都可见
    • 韧性:核心设计理念是面向失败设计,指抵御异常的能力
    • 自动化:CI/CD,在标准化的基础上实现自动化。
    • 零信任:认为防火墙内的一切都是安全的,依赖认证和授权。
    • 架构持续演进:通过可拓展和松耦合设计,让后续可能发生的变更更容易。
  • SOA 的设计原则:无状态、单一实例、明确定义的接口、自包含和模块化、粗粒度、松耦合、重用能力、互操作性
  • ESB :企业服务总线,是由中间件技术实现并支持 SOA 的一组基础架构,它提供了一种基础设施,其优势在于消除了服务请求者与服务提供者之间的直接链接。
  • SOA 架构构建时需要考虑的问题
    • 服务粒度:粗粒度用于暴露在系统外部的服务,细粒度用于企业系统架构的内部
    • 无状态服务:每个请求独立、自包含,不应该依赖于其他服务的上下文和状态
  • SDN:Software Defined Network,软件定义网络,核心思想是控制与转发分离,架构包含:控制层、转发层和应用层。
  • Lambda 架构:存量数据和增量数据分别经过批处理层和加速层,在服务层汇总,产生查询视图
    • 批处理层:存储主数据集(周期性)
      • e.g. 每天凌晨将 Kafka 中浏览、下单等消息同步到 HDFS 中,将 HDFS 中数据解析为 Hive 表,然后使用 HQL 或 Spark SQL 计算分区统计结果,将 Hive 表转储到 MySQL 中作为批视图
    • 加速层:处理增量实时数据(持续)
      • e.g. 使用 Spark Streaming 实时监听 Kafka 中的消息,将实时结果存储在 Redis 中作为实时视图
    • 服务层:响应用户请求
      • e.g. 采用 Java Web 服务,对外提供 HTTP 接口
    • 适合预算充足的情况,海量历史数据
  • Kappa 架构:删除了批处理层,将数据通道以消息队列进行替代,本质上是改进 Lambda 架构中的加速层
    • 实时层:处理输入数据,生成实时视图
      • e.g. Flink
    • 服务层:响应用户请求
    • 适合预算有限的情况,小规模数据集

架构经典风格:反映了共有的结构和语意特征

  • 据流:

    • 处理
    • 📖道/过滤器
      • 优点:简单、可并行、可扩展
      • 缺点:不适合用来设计交互式应用系统
      • 场景:消息封装、转发
  • 用返回:程序/程序、面向对象、层次风格

  • 立构件风格

    • 程通信风格
    • 件驱动风格:新闻系统,根据用户的注册兴趣,向用户推送其感兴趣的新闻内容。
  • 拟机风格:释器(自定义规则)、则系统(专家系统)

  • 以数据为中心风格

    • 📖黑板风格
      • 场景:语音识别、知识推理
      • 优点:针对问题复杂、解空间很大、求解过程不确定的系统,启发式解决。
      • 缺点:不能确保期望结果,效率低,不支持并行,共享空间的访问需要同步。
    • 仓库风格:中央数据结构 + 一组独立构件(操作中央数据)
  • C2 风格:构件之间无连接

    • 系统中的构件和连接件都有一个顶部和一个底部
    • 构件中的顶/底部应连接到某连接件的底/顶部,而构件之间的连接是不允许的
    • 一个连接件可以和其他任意数目的其他构件和连接件连接
    • 当两个连接件进行直接连接时,必须顶、底相接

比较SOA方案和微服务方案的不同?

  1. 设计思路:SOA通过服务总线封装,从小到大形成应用系统;微服务把应用拆分成独立自治的小服务,从大到小。
  2. 消息传输:SOA 依赖基于XML的消息格式和基于SOAP的通信协议,微服务架构依赖于REST和JSON。
  3. 是否分布式:SOA 需要存在ESB总线,负责服务之间的通信转发和接口适配;微服务架构强调轻量级、迅速、去中心化的技术。
  4. SOA设计架构强调分层(展现层、业务层、总线层、数据层),微服务架构中的服务松散,易扩展,更强调自治性

由于平台业务规模体量会比较大,而考虑到微服务架构的可扩展性、去中心化和自治性,采用微服务架构更容易提升性能,并且适应研发团队的解耦。

微服务架构的含义和关键原则?

微服务是一种软件开发技术,是SOA的变体,将应用程序构造为一组松散耦合的服务,单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。

微服务风格/RESTFul风格关键原则:

  1. 每个URI代表一种资源
  2. 客户端使用HTTPVerb表示操作方式的动词对服务端资源进行操作
  3. 通过操作资源的表现形式来操作资源(GET、POST、PUT、DELETE)
  4. 资源的表现形式是XML或HTML
  5. 客户端与服务端之间的交互是无状态的,客户端每个请求必须包含理解请求所必需的所有信息。

比较 C/S 架构和 B/S 架构

C/S 优点

  1. 客户端与服务端分离,二者可以并行开发
  2. 技术成熟,允许网络分布操作,交互性强,具有安全的存取模式
  3. 网络压力小,响应速度快,有利于处理大量数据
  4. 模型思想简单,易于人们理解

C/S 缺点

  1. 客户端与服务端的通信依赖于网络,服务器负荷重
  2. 开发成本高
  3. 部署、运维、升级复杂,工作量大
  4. 界面风格不一,软件移植和数据集成困难
  5. 数据库的安全性因客户机程序直接访问而降低

B/S 优点

  1. 易于部署、维护、升级
  2. 开放性和可扩充性强,可以应用在广域网上
  3. 可跨平台操作
  4. 通过接口访问数据库,提高动态交互性、服务器的通用性和可移植性

B/S缺点

  1. 不利于在线事务处理(OLTP)
  2. 数据查询响应速度慢
  3. 系统的安全性较难控制

C/S 与 B/S 混合架构

若项目资金不足,在各分支机构财务部门局域网中采用C/S架构,部署应用服务器及相关的数据库服务器,然后将集中处理的后期财务数据通过VPN技术上传至总部局域网的相应服务器中。

混合架构的优点:

  1. 冲分发挥了各自的优势,取长补短。客户请求和信息发布采用B/S架构,保持了瘦客户端的优点,客户端只利用浏览器即可完成所有的应用需求;数据库的请求和响应操作采用 C/S架构,通过MybatisPlus在Web应用程序和MySQL数据库之间建立ORM映射,完成大量数据的批量录入请求
  2. 系统的部署、维护及数据更新方便,不存在完全采用C/S架构带来的客户端工作量大等缺点。
  3. 对原基于C/S架构对应用,只需开发用于发布的Web界面,就能升级到这种混合架构系统中,从而最大限度地保护了原有投资。

数据库

  • BI:Business Intelligence,商业智能,三大组成部分是数据仓库、联机分析处理(OLAP)、数据挖掘

  • 🌟数据仓库关键特征:面向主题、集成的、非易失的(相对稳定性,指的是主要用于查询,只有少量修改)、时变的

通过binary log主从复制的过程?

  1. 主库提交,将 DDL 与 DML 数据写入 binlog;
  2. 从库上启动复制
  3. 创建IO线程连接主库
  4. 主库创建 binlog dump 线程读取数据库事件并发送给 IO线程
  5. 从库的IO线程获取到事件数据后,更新从库的中继日志 relay log
  6. 从库上的SQL线程读取中继日志 relay log中更新的数据库事件,并应用

网络安全

  • 🌟BLP 模型:为数据规划机密性,依据机密级别划分安全级别,按安全级别强制访问控制
  • Biba 模型:建立在完整性级别上。
  • PGP:Pretty Good Privacy,用来实现安全电子邮件的协议,基于RSA公钥加密体系。

知识产权

  • 🌟保护期受时间限制:发表权
  • 🌟🌟人身权的保护期不受限制,受到永久保护:署名权、修改权、保护作品完整权
  • 软件著作权
    • 保护的对象不包括:开发软件的思想、处理过程、操作方法或数学概念。
    • 自软件开发完成之日生效。
    • 更改软件不叫盗版,复制传播才是盗版。
    • 合同未作明确约定或者没有订立合同的,著作权属于受托人
    • 作品原件所有权的转移,不改变作品著作权的归属。
    • e.g. 某人购买了一款有注册商标的应用 app,擅自复制光盘出售,其行为是侵犯软件著作权的行为
  • 软件商标权的保护对象是指:软件注册商标

应用数学

  • 数学模型在求解后,还需要进行灵敏性分析,对结果进行检验,分析计算结果对参数变化的反应程度。

  • 乐观主义准则:大中取大

  • 悲观主义准则:小中取大

  • 后悔值准则:计算后悔值,在每一方案中选取最大后悔值,在各方案的最大后悔值中选取最小值作为决策依据。

嵌入式

  • 🌟DSP:Digital Signal Processor 信号处理器,专用于实时的数字信号处理,常采用哈佛体系结构
  • 🌟SoC 不是一块处理器芯片,而是芯片的集成
  • 存取速度排序(快->慢):寄存器组>Cache 缓存>内存>Flash(ROM)

英语

  • semantic models 语义模型
  • feasibility 可行性
  • interpretive, interactive and iterative process 解释性、交互式和反复迭代的过程
  • reconcile, augment, and establish connections 理顺、加强并建立连接
  • reconstruction 重构
0%