目录
- 环路复杂度McCabe
- 软件工具分类
- 需求分类
- 软件测试
- 中间件分类
- 等保(信息安全等级保护)
- 数据流图DFD
- 微内核架构
- 信息系统生命周期
- 区块链
- MDA模型驱动架构
- EJB
- SOA
- 微服务
- REST五大原则
- 管道过滤器 VS 仓库风格
- 虚拟机风格
- 质量属性 & 非功能性需求
- 敏感点、权衡点、风险点、非风险点
- 云原生设计原则
- OOA & OOD
- 需求分析
- 安全模型分类
- 国密算法
- WPDRRC
- PGP
- 4+1视图
- ATAM
- RUP
- 霍尔
- 大数据 Lambda vs Kappa
- 网络设计
- 网络基础知识
- 反规范化
- 质量属性效用树
- UML建模
- 重构、设计恢复、【正向|逆向|再】工程
- 高内聚 vs 低耦合
- 设计模式
- 电子商务、电子政务
- 加密算法
- 安全性
- NoSQL
- 一、计算机组成与结构
- 六、数据库
- 七、网络
- 十、信息化
- 架构
环路复杂度McCabe
https://cloud.tencent.com/developer/article/2028443
软件工具分类
需求分类
QFD:常规、期望、兴奋
需求层次:业务、用户、系统(功能、非功能、设计约束)
软件测试
- 桌面检查:由程序员自己检查自己编写的程序。
- 代码审查:由程序员逐句讲解程序的逻辑。在此过程中,程序员或其他小组成员可以提出问题,展开讨论,审查错误是否存在。
- 代码走查:让与会者“充当”计算机。由测试组成员为被测程序准备一批有代表性的测试用例,提交给走查小组。走查小组开会,集体扮演计算机角色,让测试用例沿程序的逻辑运行一遍。
- 白盒测试 - 控制流 - 逻辑覆盖:语句、判定、条件、路径
- 测试的阶段:单元、集成、系统、性能、验收
中间件分类
束缚同事、拳跨专网
数据、Web服务器、通信、分布式事务、安全、跨平台和架构、专用平台(电商等特定领域)、网络
中间件的2种不同类型支持:
数据支持、提供公共服务
等保(信息安全等级保护)
https://zhuanlan.zhihu.com/p/614825376?utm_id=0
数据流图DFD
数据流: 用一个箭头描述数据的流向,箭头标注的内容可以是信息说明或数据项。
处理(或加工): 对数据进行的加工或转换,在图中圆角矩形表示。
数据存储: 表示用数据库(或者文件形式)存储的数据,对其进行的存取分别以指向或离开数据存储的箭头表示。
外部实体: 也成为数据源或数据终点。描述系统数据的提供者或者数据的使用者,存在于系统外部的人或组织,在图中用矩形框表示。
分层细化的 数据平衡原则 :
- 1、子图与父图之间的平衡:
- (1)父图与子图之间平衡是指任何一张DFD子图边界上的输入/输出数据流必须与其父图对应加工的输入/输出数据流保持一致。
- (2)如果父图中某个加工的一条数据流对应于子图中的几条数据流,而子图中组成这些数据流的数据项全体正好等于父图中的这条数据流,那么它们仍然是平衡的。
- 2、子图内部:加工的输入和输出需要平衡。
微内核架构
微内核架构(Microkernel Architecture),有时也被称为插件化架构(Plug-in Architecture),是一种面向功能进行拆分的可扩展性架构,通常用于实现基于产品的应用。微内核架构模式允许你将其他应用程序功能作为 插件添加到 核心应用程序,从而提供可扩展性以及功能分离和隔离。
核心系统 的功能相对稳定,不会因为业务功能扩展而不断修改,
而 插件模块 是可以根据实际业务功能的需要不断地调整或扩展。
微内核架构的本质就是将可能需要不断变化的部分封装在插件中,从而达到快速灵活扩展的目的,而又不影响整体系统的稳定。
所以,模块加载 和 模块通信 是 核心系统提供的功能。而控制条的音量控制、播放器画中画、播放器贴图等功能是插件模块的功能。
微内核架构设计有以下 三个关键点: 插件管理、插件连接 和 插件通信
(1)插件管理: 插件管理需要知道当前系统中有多少个插件,哪些插件处于可用状态,何时加载一个插件,以及
如何加载一个插件。
(2)插件连接: 插件连接制定了一个插件与核心系统的通信方式,也就是连接规范。
(3)插件通信: 插件模块的设计要实现低耦合,但一个业务请求往往需要几个插件模块共同协作来实现,这就需
要插件之间实现相互通信。
微内核架构的优缺点包括:
(1) 灵活性高, 能够快速响应不断变化的环境。通过插件模块的松散帮合实现,可以隔离变更,并且快速满足需
求。
(2) 易于部署, 因为功能之间是隔离的,插件之间可以独立的加载和卸载。
(3) 可测试性高, 插件模块可以单独测试,能够非常简单地被核心系统模拟出来进行演示,或者在对核心系统很
小影响甚至没有影响的情况下对一个特定的特性进行原型展示。
(4) 通信效率低,插件通过内核实现间接通信,需要更多开销。
(5) 开发难度高,微内核架构需要设计,因此实现起来比较复杂。
信息系统生命周期
规分设实运维:
- 系统规划
- 系统分析
- 系统设计
- 系统实施
- 系统运行与维护
区块链
区块链技术的特点包括了:
- 去中心化:由于使用分布式核算和存储,不存在中心化的硬件或管理机构,任意节点的权利和义务都是均等的,系统中的数据块由整个系统中具有维护功能的节点来共同维护。
- 自治性:区块链采用基于协商一致的规范和协议(比如一套公开透明的算法),使得整个系统中的所有节点能够在信任的环境自由安全的交换数据,使得对“人”的信任改成了对机器的信任,任何人为的干预不起作用。
- 匿名性(去信任):由于节点之间的交换遵循固定的算法,其数据交互是无需信任的(区块链中的程序规则会自行判断活动是否有效),因此交易对手无须通过公开身份的方式让对方对自己产生信任,对信用的累积非常有帮助。
- 安全性(信息不可篡改):数据在多个结点存储了多份,篡改数据得改掉51%结点的数据,这太难。同时,还有其它安全机制,如:比特币的每笔交易,都由付款人用私钥签名,证明确实是他同意向某人付款,其它人无法伪造。
- 开放性:系统是开放的,如:区块链上的【交易信息是公开的】,不过【账户身份信息是高度加密的】。
去中心化:没有中心化的支付或管理机构,任意节点对等,数据由所有具有维护功能的节点共同维护(采用分布式记账策略),
自治性:基于协商一致的协议(比如公开透明的算法),可信环境下交互数据,对人信任改成对机器信任。
匿名性:遵循固定算法,数据交互无需信任,无需通过公开身份让对方产生信任,积累信用。
安全性:数据存储多份,篡改得改51%数据,难。其他:交易付款人用私钥签名,证明身份,无法伪造。
开放性:系统是开放的,如交易都是公开的,但账户身份信息是高度加密的。
MDA模型驱动架构
优势:
- 可移植性:在MDA中,先会建立 平台无关模型(PIM),然后转换为 平台相关模型(PSM),1个PIM可转换成多个PSM,所以要把一个软件移植到另一个平台时,只需要将平台无关模型转换成另一个平台的相关模型即可。所以可移植性很强。
- 平台互操作性:在MDA中,整个开发过程都是模型驱动的,所以标准化程度很高,这样为平台的互操作带来了非常大的帮助。
- 文档和代码的一致性:在MDA中,代码是由模型生成的,所以具有天然的一致性。这一点其他方法无法比拟。
EJB
Session Bean:业务逻辑,又分为Stateful、Stateless
Entity Bean: 数据实体,会被持久化,与底层DB进行ORM映射,
Message Driven Bean:消息驱动,收发异步JMS消息
SOA
SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
ESB作用与特点:
1、SOA的一种实现方式,ESB在面向服务的架构中起到的是总线作用,将各种服务进行连接与整合;
2、描述服务的元数据和服务注册管理;
3、在服务请求者和提供者之间传递数据,以及对这些数据进行转换的能力,并支持由实践中总结出来的一些模式如同步模式、异步模式等;
4、发现、路由、匹配和选择的能力,以支持服务之间的动态交互,解耦服务请求者和服务提供者。高级一些的能力,包括对安全的支持、服务质量保证、可管理性和负载平衡等。
微服务
优点:
标准答案:
小服务(且专注于一件事情)
化整为零,易于小团队开发,
独立性强:独立开发、独立测试、独立部署、独立运行
支持异构(每个服务使用不同数据库)
容错能力强:故障被隔离在单个服务中,通过重试、平稳退化等机制实现应用层容错,
松耦合易扩展:可根据需求独立扩展
补充:
服务粒度小,可按照业务、组织等仅业务系统进行拆分,每个服务专注于一件事情,
服务间按照约定好的接口进行通信,接口不变则服务间交互无需改变,
多服务并行开发,可独立技术选型(异构),效率更高,
多服务独立部署,可持续演进,
缺点:
标准答案:
【分布式数据一致性】更复杂
【测试复杂性】服务间的依赖测试
【运维复杂性】服务持续集成、部署有一定难度,需要CI/CD/Devops相关技术支持,
补充:
服务拆分粒度无法确定,存在服务拆分粒度不适宜的情况,
服务间通过rest、rpc进行通信,存在一定性能损耗,
服务间分布式可观测性实现有一定难度,如日志、追踪、指标等,踪需借助Tracing等相关工具,
服务间调用降级,可通过降级、熔断等避免服务集群雪崩。
REST五大原则
资源、标识、接口、不变、态
- 所有事务抽象为资源
- 资源唯一标识
- 通过接口操作资源
- 操作不改变标识
- 操作无状态
管道过滤器 VS 仓库风格
架构风格 | 数据处理方式 | 系统拓展方式 | 处理性能 |
---|---|---|---|
管道-过滤器 | 数据驱动机制,处理流程事先确定,交互性差 | 数据与处理紧密关联,调整处理流程需系统重新启动 | 劣势:需要数据格式转换,性能降低 优势:支持过滤器并发调用,性能提高 |
仓库 | 数据存储在中心仓库,处理流程独立,支持交互式处理 | 数据与处理解耦合,可动态添加、删除处理组件 | 劣势:数据与处理分离,需要加载数据,性能降低 优势:数据与处理组件之间一般无依赖关系,可并发调用,提高性能 |
比较因素 | 管道-过滤器风格 | 数据仓库风格 |
---|---|---|
交互方式 | 顺序结构或有限的循环结构 | 星形(工具之间通过中心节点进行交互) |
数据结构 | 数据流(或流式结构) | 文件或模型 |
控制结构 | 数据驱动 | 业务功能驱动 |
扩展方法 | 接口适配 | 模型适配(与数据仓库进行数据适配) |
虚拟机风格
质量属性 & 非功能性需求
- 性能
性能(performance)是指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统
所能处理的事件的个数。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定
量的表示。性能测试经常要使用基准测试程序(用以测量性生能指标的特定事务集或工作量环境)。 - 可用性
可用性(availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够
恢复正常的速度来表示。 - 可修改性
可修改性(modifiability)是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为
基准,通过考察这些变更的代价衡量可修改性。 - 安全性
安全性(security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安
全性是根据系统可能受到的安全威胁的类型来分类的。安全性又可「划分为机密性、完整性、不可否认性及可控性等
特性。 - 可靠性
可靠性(reliability)是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基
本能力。可靠性通常用平均失效等待时间(MeanTimeToFailure,简称MTTF)和平均失效间隔时间(Mean
Time Between Failure,简称MTBF)来衡量。在失效率为常数和修复时间很短的情况下,MTTF和MTBF几乎相
等。 - 功能性
功能性(functionality)是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相
互协作。 - 可变性
可变性(changeability)是指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义
的规则,在某些具体方面不同于原有的体系结构。当要将某其个体系结构作为一系列相关产品(例如,软件产品线)
的基础时,可变性是很重要的。 - 互操作性
作为系统组成部分的软件不是独立存在的,经常与其他系统或自身环境相互作用。为了支持互操作性
(interoperation),软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其
他编程语言编写的软件系统的交互作用就是互操作性的问题,这种互操作性也影响应用的软件体系结构。
敏感点、权衡点、风险点、非风险点
敏感点,一个或多个构件(和/或构件之间的关系)的特性,影响系统的某个质量属性。
权衡点,是影响多个质量属性的特性,是多个质量属性的敏感点。
风险点,是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
非风险点,是指不会带来隐患的分析与描述。
云原生设计原则
服 持 弹 韧 零 自 测
服 务化原则:使用微服务
架构 持 续演进原则:业务高速迭代情况下的架构与业务平衡
弹 性原则:可根据业务变化自动伸缩
韧 性原则:面对异常的抵御能力
零 信任原则:默认不信任网络内部和外部的任何人/设备/系统
所有过程 自 动化原则:自动化交付工具
可观 测 原则:通过日志、链路跟踪和度量
服务化、架构持续演进、弹性、韧性、零信任、过程自动化、可观测
关于云原生的定义有众多版本,云原生架构的理解也不尽相同,根据云原生技术、产品和上云实践,从技术的角度云原生架构是基于云原生技术的一组 (架构原则) 和 (设计模式) 的集合,旨在将云应用中的非业务代码部分进行最大化的剥离,从而让云设施接管应用中原有的大量非功能特性,使业务不再有非功能性业务中断困扰的同时,具备 (轻量)、(敏捷)、(高度自动化) 的特点。由于云原生是面向“云”而设计的应用,因此,技术部分依赖于传统云计算的3层概念,即 (基础设施即服务(IaaS))、(平台即服务(PaaS))、(软件即服务(SaaS))。
OOA & OOD
OOA建模主要建立两大模型:用例建模、分析建模
OOA大致上遵循如下5个基本步骤:
助记:类构题属方(累够了,才提起淑芳)
- 确定对象和类
- 这里所说的对象是对数据及其处理方式的抽象,它反映了系统保存和 处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述,它包括 如何在一个类中建立一个新对象的描述。
- 确定结构
- 结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系, 整体-部分结构反映整体和局部之间的关系。
- 确定主题
- 主题是指事物的总体概貌和总体分析模型。
- 确定属性
- 属性就是数据元素,可用来描述对象或分类结构的实例,可在图中给出, 并在对象的存储中指定。
- 确定方法
- 方法是在收到消息后必须进行的一些处理方法:方法要在图中定义,并在对象的存储中指定。对于每个对象和结构来说,那些用来增加、修改、删除和选择的方法本身 都是隐含的(虽然它们是要在对象的存储中定义的,但并不在图上给出),而有些则是显示的。
在OOD中,类可以分为3种类型:实体类、控制类 和 边界类
需求分析
需求分析它的主要任务就是要提炼、分析、认真审查已经获取到的需求,确保所有的项目干系人都要明白其中的含义,要找出其中的错误、遗漏或者其它不足的地方,所以需求分析通常来讲,它的工作就包括了7个方面:
- 第1要绘制系统的上下文的 范 围关系图;
- 第2要创建用户界面的 原 型;
- 第3要分析需求的可 行 性;
- 第4要确定需求的 优 先级;
- 第5要为需求建立 模 型;
- 第6要创建 数 据字典;
- 最后要使用 Q FD。
分析、确保干系人明白含义,找出错误、遗漏、不足的地方
范原行优模数质
安全模型分类
国密算法
对称:SM1 电子政、商务、SM4 无线局域网产品
非对称:SM2
杂凑(散列哈希):SM3
标识密码:SM9 无cert、互联网新兴
WPDRRC
ISO/OSI安全体系为信息安全问题的解决提供了一种可行的方法,但其可操作性差。在信息安全工作中,一般采用:
- PDR(保护、检测和响应)
- PPDR(安全策略、保护、检测和响应)
- PDRR(保护、检测、响应和恢复)
- MPDRR(管理、保护、检测、响应和恢复)
- WPDRRC(预警、保护、检测、响应、恢复和反击)
等动态可适应安全模型,指导信息安全实践活动。
Protection保护、Detection检测、React响应、Recovery恢复、Policy策略、Waring(预警)、Counterattack(反击)
WPDRRC六大环节:预警、保护、检测、响应、恢复、反击
WPDRRC三大要素:人、技术、策略
PGP
https://blog.csdn.net/weixin_42369053/article/details/119036995
4+1视图
ATAM
RUP
9个核心流工作流:
模需分实测部配项环
- 默许分 - 实测 - 不配 - 项上光环
霍尔
三维:时间维、逻辑维、知识维度
大数据 Lambda vs Kappa
大数据的架构包括了Lambda架构和Kappa架构,
- Lambda架构分解为三层:批处理层、加速层、服务层;
- Lambda同时计算 流计算 和 批计算 并合并视图
- Kappa只会通过 流计算 一条的数据链路计算并产生视图。
网络设计
网络基础知识
磁盘冗余阵列:
RAID0(条带化), RAID1(镜像), RAID5(奇偶校验), RAID1+0(2个RAID1), RAID0 + 1(2个RAID0)
网络存储:
DAS(直接附加存储):堆叠磁盘通过SCSI直连服务器
NAS(网络附加存储):通过网络接口访问,独立的存储系统,将存储设备与服务器分离
SAN(存储区域网络):通过专用交换机将磁盘阵列组成高速专用子网,将存储设备从传统的以太网中分离出来,成为独立的SAN系统结构(光纤通道 - FC SAN,IP网络 - IP SAN, 无线带宽 - IB SAN)。
反规范化
质量属性效用树
UML建模
重构、设计恢复、【正向|逆向|再】工程
高内聚 vs 低耦合
耦合:非 鼠(数)标 控制 外公内容
内聚:功顺通过瞬逻然
设计模式
电子商务、电子政务
加密算法
安全性
NoSQL
一、计算机组成与结构
六、数据库
笛卡尔积×
投影π、选择σ
自然连接∣×∣(笛卡尔积与自然连接的转换)
三范式(分部传)
BC范式(针对任一候选键,所有依赖都左边都应该包含主属性)
保持函数依赖分解(充分条件)
无损分解( R1∩R2 -> R1-R2 或者 R1∩R2-> R2-R1)
SQL语句(DDL、DML)
数据仓库
大数据
七、网络
局域网、城域网、广域网
结构化布线SCS可以划分为以下6个子系统。
- 工作区子系统 Work Location
- 工作区子系统是由终端 到 信息插座的整个区域。一个独立的需要安装终端设备的区域划分成一个工作区。工作区应支持电话、数据终端、计算机、电视机、监视器以及传感器等多种终端设备。
- 水平布线子系统(Horizontal)
- 各个楼层接线间的配线架到工作区信息插座之间所安装的线缆属于水平子系统。水平子系统的作用是将干线子系统线路延伸到用户工作区。
- 管理子系统(Administration)
- 管理子系统设置在楼层的接线间内,由各种交连设备(双绞线跳线架、光线跳线架)以及集线器和交换机等交换设备组成,交连方式取决与网络拓扑结构和工作区设备的要求。交连设备通过水平布线子系统连接到各个工作区的信息插座,集线器或交换机与交连设备之间通过短线缆互连,这些短线被成为跳线。通过跳线的调整,可以在工作区的信息插座和交换机端口之间进行连接切换。
- 干线子(垂直)系统(Backbone)
- 干线子系统是建筑物的主干线缆,实现各楼层设备间子系统之间的互连。干线子系统通常由垂直的大对数铜缆或光缆组成,一头端接于设备间的主配线架上,另一头端接于楼层接线间的管理配线加上。
- 设备间子系统(Equipment)
- 建筑物的设备间是网络管理人员值班的场所,设备间子系统由建筑物的进户线、交换设备、电话、计算机、适配器以及保安设施组成,实现 中央主配线架与 各种不同设备(如PBX、网路设备和监控设备等) 之间的连接。
- 建筑群子系统(Campus)
- 建筑群子系统也叫园区子系统,它是连接各个建筑物的通信系统。大楼之间的布线方法有三种:
- 地下管道敷设:管道内敷设的铜缆或光缆应遵循电话管道和入孔的各种规定,安装时至少应预留1~2个备用管孔,以备扩充之用。
- 直埋法:需要在统一个沟内埋入通信和监控电缆,并应设立明显的地面标志。
- 架空明线:这种方法需要经常维护。
- 建筑群子系统也叫园区子系统,它是连接各个建筑物的通信系统。大楼之间的布线方法有三种:
OSI七层
TCP/IP四层
IP地址分类
ipv6
网络物理规划3层模型
建筑物综合布线系统PDS(结构化布线系统)
十、信息化
企业集成平台-基本功能如下: