系统架构师考试知识点总结

J2EE应用系统

J2EE应用系统支持五种不同类型的构件模型, 包括:

Applet, Java Bean, Enterprise JavaBean, Servlet和应用程序客户端构件(Application Client).

逻辑地址和物理地址

逻辑地址=页号+页内地址

物理地址=物理块号+页内地址

页号与物理块号的对应关系由页面变化表查询决定

逻辑地址的页内地址和物理地址的页内地址是相等的

如果页面大小为4k, 因此需要12位地址空间(4 * 1024 = 2^12), 因此页号占16-12=4 高4位.

如果逻辑地址是3C28H, 可看出高4位的页号为3, 通过查表可得知物理块号(假如为6), 则物理地址为6C28H.

闪存和内存

闪存(Flash Memory)是一种长寿非易失性(在断电情况下仍能保持所存储的数据信息)存储器, 采用随机访问方式, 常用来代替ROM, 而不是RAM(内存). 由于内存的删除以块为单位, 而RAM的删除需以字节为单位, 因此闪存无法替代RAM.

页面淘汰策略

淘汰页面首先考虑不在内存的页面(状态位), 如果都在内存则再看访问位为0的页面, 根据局部性原理选择不经常访问的页面, 如果所有页面都会被访问到, 最后再看修改位为0的页面, 选择没有被修改过的页面淘汰, 避免数据不一致问题.

CISC和RISC

CISC(复杂指令集): 基本思想是增强原有指令的功能, 用更为复杂的指令取代原先由软件子程序完成的功能, 导致指令系统越来越复杂. 缺点如下:

1. 微程序技术是CISC的重要支柱, 每条复杂指令都要通过执行一段解释性微程序才能完成, 这就需要多个CPU周期, 从而降低了机器的处理速度.
2. 指令系统过分庞大, 从而使高级语言编译程序选择目标指令的范围很大, 并使编译程序本身冗长而复杂, 从而难以优化编译使之生成真正高校的目标代码.
3. CISC强调完善的中断控制, 势必导致动作繁多, 设计复杂, 研制周期长.
4. CISC给芯片设计带来很多困难, 出错几率增大, 成本提高而成品率降低.

RISC(精简指令集): 基本思想是通过减少指令总数和简化指令功能, 降低硬件设计的复杂度, 使指令能单周期执行, 并通过优化编译, 提高指令的执行速度, 采用硬线控制逻辑, 优化编译程序. 关键技术有:

1. 重叠寄存器窗口技术
2. 优化编译技术, 使用了大量的寄存器
3. 超流水及超标量技术, 为进一步提高流水线速度而采用的新技术
4. 硬线逻辑与微程序相结合

并发线程资源数量

如果每个并发程序所需要的资源相同, 则保证不会死锁的最小资源数=并发进程数*(所需资源数-1) + 1.

原理是: 给每个进程都分配所需资源数减1, 那么如果再有1个资源, 则其中必然有一个进程可以完成, 释放更多资源完成其余进程.

文件系统索引节点

文件系统采用索引节点管理, 索引节点有8个地址项iaddr[0]~iaddr[7], 每个地址大小为4B, 其中iaddr[0]~iaddr[4]采用直接地址索引, iaddr[5]~iaddr[6]使用一级间接地址索引, iaddr[7]采用二级间接地址索引.

如果磁盘索引块的磁盘数据块大小均为1KB, 因此每个磁盘索引块可存放 1KB=1024B / 4B(地址大小) = 256个地址项.

直接地址索引的每个地址项中, 直接保存了物理块的块号, 对应的逻辑块号为0~4.

一级间接地址索引中的每个地址项中保存的是1个物理块号, 但该物理块号中保存的内容是256个直接地址索引项, 因此对应256个物理块, 对应的逻辑块号为5~260.

二级间接地址索引中的每个地址项保存的是一级间接地址索引的地址项, 因此对应256*256个物理块, 对应的逻辑块号为261~65796.

数据库需求分析阶段

数据库需求分析阶段应完成的文档有: 数据字典(描述数据的元数据)和数据流图(数据的处理流程).

数据库完整性约束

数据库完整性约束分为三种:

1. 实体完整性, 主键不能取空值且唯一
2. 参照完整性, 外键取值或者为空, 或者在被引用的表中不会空
3. 用户定义完整性, 具体应用数据必须满足的语义要求(如取值不为空, 数据类型等)

数据库设计

E-R图合并时冲突

E-R图进行合并时, 它们之间存在的冲突主要有:

1. 属性冲突: 同一属性可能会存在于不同的分E-R图中, 由于设计人员不同或是出发点不同, 对属性的类型, 取值范围, 数据单位等可能会不一致, 这些属性数据将来只能以一种形式在计算机中存储, 这就需要在设计阶段进行统一.
2. 命名冲突: 相同意义的属性, 在不同的分E-R图上有着不同的命名, 或是名称相同的属性在不同的分E-R图中代表着不同的意义, 这也需要统一.
3. 结构冲突: 同一实体在不同的分E-R图中有不同的属性, 同一对象在某一分E-R图中被抽象为实体而在另一分E-R图中又被抽象为属性, 对于这种结构冲突问题需要统一.

反规范技术

常见的反规范技术有: 增加冗余列, 增加派生列, 重新组表, 分割表.

1. 增加冗余列: 指在多个表中增加相同的常用列, 可用来在查询时避免连接操作.

2. 增加派生列: 把可由通过表中其他数据计算生成的列作为固定的列插入到表中, 作用是在查询时减少计算量, 从而加快查询速度.

3. 重新组表: 指如果许多用户需要查看两个表连接出来的结果数据, 则把者两个表重新组成一个表来减少连接从而提高性能.

4. 分割表: 有水平分割和垂直分割两种. 水平分割是把表记录按行分割, 把数据放到多个独立的表中, 主要用于表数据规模很大, 表中数据相对独立或数据需要存放到多个介质上使用.

   垂直分割是把表按列进行分割, 通常将主键与部分列放到一个表中, 主键和其他列放到另一个表中, 在查询时减少IO次数.

数据不一致问题

解决数据不一致问题的三种常见方法有:

1. 批处理维护: 指通过定期运行批处理作业或存储过程对数据库进行修改, 适用于对实时性要求不高的情况.
2. 应用逻辑: 指在同一事务中对所有设计的表进行增删改操作, 同一逻辑必须在所有的应用中使用和维护, 缺点是容易遗漏, 特别在需求变化时, 不易于维护.
3. 触发器: 指对数据的任何修改立即触发对数据库某些列的相应修改, 实时性好, 也易于维护.

Redis和MySQL实时同步方案

Redis和MySQL数据实时同步方案有以下三种:

1. 使用MySQL的事务, 因为事务具有一致性保证, 事务提交成功后再更新缓存.
2. 在缓存里引用一些访问控制位, 数据库数据变化后, 同步变更对应的访问控制位, 然后从缓存查询时, 率先判断该访问控制位, 有变化从数据库查, 无变化直接从缓存中返回数据.
3. 通过数据库中间件产品保证缓存和数据库数据的实时同步.

逻辑数据模型设计

逻辑模型设计也称为逻辑结构设计, 其任务是将概念模型转化为某个特定的DBMS上的逻辑模型.

设计逻辑结构时, 首先为概念模型选定一个合适的逻辑模型(如关系模型, 网状模型, 层次模型), 然后将其转化为由特定DBMS支持的逻辑模型, 最后对逻辑模型进行优化.

逻辑设计的目的是将概念设计阶段设计好的E-R图转换为与选用的具体机器上的DBMS所支持的数据模型相符合的逻辑结构.

超实体

某个实体类型中所有实体同时也是另一个实体类型中的实体, 此时称前一个实体为子类实体, 后一个实体为超实体.

派生属性

实体的某个属性可以从其他属性或其他数据推导出来, 那么这个属性就是派生属性.

存储过程的安全性

存储过程是一组完成特定功能的SQL语句集, 存储在数据库中, 一次编译后永久有效, 通过指定存储过程的名字并给出参数来执行.

存储过程从安全性的角度考虑, 更新数据时, 通过提供存储过程让第三方调用, 将需要更新的数据传入存储过程, 而在存储过程内部用代码分布对需要的多个表进行更新, 从而避免了向第三方提供系统的表结构, 保证了系统的数据安全.

分布式数据库

分布式数据库中, 局部DBMS中的内模式与概念模式中与集中数据库是完全一致的, 不同之处在于新增的全局DBMS, 而整个全局DBMS可以看作相对于局部概念模式的外模式.

由于外模式部分有一系列的分布模式, 分片模式, 全局概念模式, 全局外模式以及多级映射, 使得用户在使用分布式数据库时, 可以使用集中式数据库同样的方式.

1. 全局外模式: 是全局应用的用户视图, 是全局概念模式的子集, 该层直接与用户(或应用程序)交互.
2. 全局概念模式: 定义分布式数据库中数据的整体逻辑结构, 数据如同没有分布一样, 可用传统的集中式数据库中所采用的方法进行定义.
3. 分片模式: 在某些情况下, 需要将一个关系模式分解为几个数据片.
4. 分布模式: 分布式数据库的本质特性就是数据分布在不同的物理为主, 分布模式的主要职责是定义数据片段(即分片模式的处理结果)的存放节点.
5. 局部概念模式: 是局部数据库的概念模式.
6. 局部内模式: 是局部数据库的内模式.

报文加密

IPSec主要对网络层的数据单元(IP数据报)进行加密

PPTP对链路层的数据单元(帧)进行加密

HTTPS是由HTTP加TLS/SSL协议组成的协议, 可对应用层数据单元(消息/报文)进行加密

网桥和交换机

网桥和交换机都是第二层转发设备, 都是根据数据链路层地址转发(包括广播)数据.

网桥是较老的设备, 端口数较少, 可连接不同类型的二层网络.

交换机端口数较多, 是一种多端口的网桥, 采用了专用的交换芯片, 转发速度更快. 一个网段为一个冲突域, 因此冲突域的大小不取决于端口数量的多少, 而是取决于位于同一个网段内端口数量的多少, 通过vlan技术可使不同的端口位于不同的网段(冲突域).

以太网交换机转发表

以太网交换机的功能是负责以太网内的数据交换, 属于二层交换.

交换机的MAC地址表中保存的核心信息是目标主机的MAC地址与交换机转发端口的对应关系.

交换机的初始MAC地址表为空, 交换机接收到数据帧后, 如果在地址表中没有找到与该帧中携带的目标MAC地址一致的表项, 则在该交换机范围内进行泛洪转发, 也就是把该帧转发给该交换机的所有端口. 如果某个端口的主机回复了该泛洪数据帧, 表明该主机的MAC地址和数据帧中的目标MAC地址相同, 则交换机就会把该主机的MAC地址及对应的端口添加到地址表中.

数据帧是数据链路层中传输的基本数据单元, 数据帧中有目标主机的MAC地址.

MAC地址表的条目分动态条目--交换机通过自己添加得到, 静态条目--手动配置的.

动态条目有生存时间, 如果超过一定时间未使用可能会被新添加的条目替换掉.

MAC地址表步不是静态增长的, 因为交换机的存储空间是有限的.

动态条目在交换机重启后会清空, 静态条目在交换机重启后不会清空.

TCP和UDP

TCP是面向连接的传输层协议.

UDP是无连接的传输层协议, 没有连接管理和流量控制的功能, 也不负责重写发送丢失或出错的数据消息.

均使用16位端口号以区别与其他应用程序的端口号, 均具有端口寻址能力, 即通信双方仅关心对方的端口号, 而不关心对方的IP地址(逻辑地址)和MAC地址(物理地址).

TCP在IP协议提供的不可靠数据服务的基础上, 采用了重发技术, 为应用程序提供了一个可靠的, 面向连接的, 全双工的数据传输服务. TCP协议一般用于传输数据量比较少, 且对可靠性要求高的场合.

UDP是一种不可靠的, 无连接的协议, 可以保证应用程序进程间的通信, 与TCP相比, UDP是一种无连接的协议, 它的错误检测功能较弱.

Internet网络核心

Internet网络核心采取的交换方式是分组交换, 因其核心协议是TCP/IP协议, 而TCP/IP协议是一种分组交换的协议, 分组交换也叫包交换, 它将所接收的分组先进行存储再进行转发.

SYN Flooding攻击

SYN Flooding攻击利用了TCP协议实现上的一个缺陷, 通过向网络服务所在端口发送大量的伪造源地址的攻击报文, 可能造成目标服务器中的半连接队列被占满, 从而阻止其他合法用户进行合法访问.

TCP端口号的作用

TCP端口号用来区分相同计算机上的不同服务, 起到应用层经常的寻址的作用.

Web页面访问过程

1. 浏览器首先查询本机的系统, 获取主机名对应的IP地址.
2. 若本机查询不到相应的IP地址, 则会发起DNS请求, 获取主机名对应的IP地址.
3. 使用查询到的IP地址, 直接访问目标服务器.
4. 浏览器发送HTTP请求
5. 服务器从请求信息中获得客户机向访问的主机名, Web应用, Web资源.
6. 服务器读取相应的主机下的Web应用, Web资源, 并用读取到的Web资源数据创建并回送一个HTTP响应.
7. 客户机浏览器解析回送的资源, 并显示结果.

DNS和PTR

DNS是域名到IP地址的映射, PTR是IP地址到域名的反向映射.

在客户机上运行nslookup查询某服务器名称时能解析出IP地址, 查询IP地址却不能解析出服务器名称, 解决这一问题的方法是为该服务器创建PTR记录.

DHCP服务器

动态主机配置协议(DHCP)通常被用在大型的局域网络环境中, 主要作用是集中地管理, 分配IP地址, 使网络环境中的主机动态地获得IP地址, 网关地址, DNS服务器地址等信息, 并能够提升地址的使用率.

DHCP协议采用UDP作为传输协议, 客户端发送广播消息到服务器的68端口, 服务器回应广播消息给客户端的67端口.

DHCP客户端从DHCP服务器获取IP地址, 主要通过发现, 提供, 选择, 确认四个阶段进行.

如果网络中有多个DHCP服务器发送OFFER报文, 客户端只根据第一个收到的OFFER报文, 返回REQUEST报文.

在网络范围内可能存在多个DHCP服务器, 各自负责不同的网段, 也可能由同一个DHCP服务器负责多个不同网段的地址分配.

交互流程

DHCP服务器向客户端发送Dhcp Offer

DHCP客户端接收到服务器的Dhcp Offer后, 需要请求地址时给服务器发送Dhcp Request报文.

服务器同意则发送Dhcp Ack, 否则发送Dhcp Nack.

客户端接收到服务器的Dhcp Ack报文后, 发现提供的地址有问题时发送Dhcp Decline拒绝该地址.

SDN网络架构

SDN本质上是将物理网络软件化, 这样就可以像升级, 安装软件一样对网络进行管理, 方便更多的应用程序能快速部署到网络上.

SDN网络架构有三层: 应用层, 控制层, 转发层.

应用层对应用户不同的业务和应用. 控制层主要负责处理数据平面资源的编排, 维护网络拓扑, 状态信息等.

转发层负责用户数据的转发.

网络结构与拓扑构型设计方法

核心层网络的功能主要是实现骨干网络之间的优化传输, 是所有流量的最终承受者和汇聚者, 其设计任务的重点通常是冗余能力, 可靠性和高速的传输.

汇聚层网络用于将分布在不同位置的子网连接到核心层网络, 实现路由汇聚的功能.

接入层网络用于将终端用户计算机接入到网络中.

嵌入式系统开发

在嵌入式系统开发中, 由于嵌入式设备不具备足够的处理能力和存储空间, 所以程序开发一般使用PC(宿主机)来完成, 然后将可执行文件下载到嵌入式系统(目标机)中运行.

当宿主机与目标机的指令不同时, 就需要在宿主机上用交叉编译器来生成目标机的可执行代码.

宿主机与目标及机之间可不建立连接, 也可建立逻辑或物理连接, 两者通信可通过串口, 也可通过并口.

调试器与被调试程序不一定在同一台机器(如远程调试).

实时操作系统

实时操作系统主要用于有实时要求的过程控制等领域, 因此在实时操作系统中, 对于来自外部的事件必须在被控对象允许的时间范围内进行处理.

实时操作系统是指当外接事件或数据产生时, 能够接受并足够快的速度予以处理, 其处理的结果给又能在规定的时间之内来控制生产过程或对处理系统做出快速响应, 调度一切可利用的资源完成实时任务, 并控制所有实时任务协调一致运行的操作系统, 提供及时响应和高可靠性是其主要特点.

信息物理系统CPS

信息物理系统CPS作为计算进程和物理进程的统一体, 是集计算, 通信与控制于一体的下一代智能系统.

信息物理系统通过人机交互接口实现和物理进程的交互, 使用网络化空间以远程的, 可靠的, 实时的, 安全的, 协作的方式操控一个物理实体.

信息物理系统主要分为3个部分:

1. 感知层: 主要是由传感器, 控制器和采集器等设备组成, 主要采集的是环境中的具体信息, 并定时地发送给服务器. 服务器接收到数据进行相应的处理, 再返还给物理末端设备, 物理末端设备进行相应的变化.
2. 网络层: 主要是连接信息世界和物理世界的桥梁, 主要实现的是数据传输, 为系统提供实时的网络服务, 保证网络分组的实时可靠.
3. 控制层: 主要是根据认知层的认知结果, 根据物理设备传回来的数据进行相应的分析, 将相应的结果返回给客户端以可视化的界面呈现给客户.

安全威胁

感知层威胁

信息窃听: 通过搭线或电磁泄漏造成数据隐私泄露.

感知破坏: 未经授权对感知层信息篡改, 增删或破坏.

网络层威胁

拒绝服务: 发送大量请求迫使服务器停止接受新请求.

选择性转发: 恶意节点接收数据后有选择性地转发, 破坏数据完整性.

控制层威胁

非授权访问: 未经授权情况下不合理地进入系统执行恶意操作.

恶意代码: 注入对系统造成不良影响的恶意代码, 对系统造成破坏.

基本消息通信

基本消息通信(BMTS)是从一个计算组件传输消息到另外一个或多个接收组件, 这样的传输具有高可靠, 低延迟和微小抖动等特点.

1. 事件触发消息: 此类消息是在发送端有某重要事件发生时产生的偶发消息, 建立消息间不存在最小时间.

   此类消息从发送到接收之间的延迟是不能确定的, 在发送产生时, BMTS可能要处理许多消息, 要么在发送者或消息被丢失时做相应处理.

2. 速率约束消息: 此类消息是偶发性产生的, 而不考虑发送者承诺消息不超出最大消息速率. 在给定的故障假设条件内, BMTS承诺不超过最大的传输延时. 抖动依赖于网络负载或最坏情况下的传输时延和最小传输时延的范围.

3. 时间触发消息: 此类消息是指发送者和接收者遵循一个精确的时间片周期完成消息的发送和接收. 在给定的故障假设条件内, BMTS承诺消息将在指定的时间片, 确定的抖动条件下被发送或接收.

具有时间触发消息能力的网络总线包括: TTE总线, FC总线, AFDX总线.

嵌入式数据库管理系统

嵌入式数据库管理系统必须能够在没有人工干预的情况下长时间运行, 因此要求具有高可靠性.

嵌入式设备一般用于处理实时数据, 因此要求嵌入式数据库管理系统支持实时数据管理.

嵌入式系统一般支持多线程并发操作, 因此嵌入式数据库管理系统一般应支持多线程并发操作.

嵌入式设备存储空间和计算能力有限, 因此嵌入式数据库管理系统一般只提供本机服务接口, 只为前端应用提供基本的数据支持.

计算机性能评价

计算机性能评价的主要指标有时钟频率(主频), 运算速度, 运算精度, 内存的存储容量, 存储器的存取周期, 数据处理速度(PDR), 吞吐率, 各种响应时间, 各种利用率, RASIS特性(Reliability Availability Serviceability Integrity Security).

优化系统性能

为了优化系统的性能, 有时需要对系统进行调整, 对于不同类型的系统, 其调整参数也不尽相同.

对于数据库系统, 主要包括CPU/内存使用状况, SQL查询语句性能, 进程/线程使用状态, 日志文件大小等.

对于一般的应用系统, 主要关注系统的可用性, 响应时间, 系统吞吐量等指标, 具体包括应用系统的可用性, 响应时间, 并发用户数, 特定应用资源占用等.

系统工程

系统工程利用计算机作为工具, 对系统的结构, 元素, 信息和反馈等进行分析, 以达到最优规划, 最优设计, 最优管理, 最优控制的目的.

霍尔提出了系统的三维结构体系, 是系统工程方法论的基础.

霍尔三维结构是由逻辑维度, 时间维度, 知识维度组成的立体空间结构.

逻辑维度

运用系统工程方法解决某一大型工程项目时, 一般可分为七个步骤:

1. 明确问题
2. 确定目标
3. 系统分析
4. 系统综合
5. 优化
6. 决策
7. 实施

时间维度

对于一个具体的工程项目, 从制定规划起一直到更新为止, 全部过程可分为七个阶段:

1. 规划阶段: 调研, 程序设计阶段, 目的在于谋求活动的规划和战略
2. 拟定方案: 提出具体的计划方案
3. 研制阶段: 做出研制方案及生产计划
4. 生产阶段: 生产出系统的零部件及整个系统, 并提出安装计划
5. 安装阶段: 将系统安装完毕, 并完成系统的运行计划
6. 运行阶段: 系统安装预期的用途开展服务
7. 更新阶段: 为提高系统功能, 取消旧系统而代之以新系统, 或改进原有系统使之更加有效地工作.

知识维度

在系统工程中, 除了为完成上述步骤, 各阶段所需的某些共性知识外, 还需要其他学科的知识和各种专业技术, 霍尔把这些知识分为工程, 医药, 建筑, 商业, 法律, 管理, 社会科学和艺术等.

各类系统工程, 如军事系统工程, 经济系统工程, 信息系统工程等都需要使用其他相应的专业基础知识.

系统评价

通常用户采用评价程序来评价系统的性能.

评价程序一般有专门的测量程序, 仿真程序等, 而评测准确度最高的评价程序是真实程序.

在计算机性能评估中, 通常将评价程序中用得最多, 最频繁的那部分核心程序作为评价计算机性能的标准程序, 称其为基准测试程序.

数据库管理系统性能指标

数据库管理系统性能评价的主要指标包括数据库所允许的索引数量, 最大并发事务处理能力以及最大连接数等.

管理信息系统规范的方法

管理信息系统规范的方法主要有:

1. 关键成功因素法: 以关键因素为依据来确定系统信息需求的一种MIS总体规划的方法. 在现行系统中，总存在着多个变量影响系统目标的实现, 其中若干个因素是关键的和主要的(即成功变量). 通过对关键成功因素的识别, 找出实现目标所需的关键信息集合, 从而确定系统开发的优先次序. 关键成功因素来源于组织的目标, 通过组织的目标分解和关键成功因素识别, 性能指标识别, 一直到产生数据字典.
2. 战略目标集转化法: 把整个战略目标看成一个信息集合, 并把组织的战略目标转变成管理信息系统的战略目标.
3. 企业系统规划法: 通过自上而下地识别系统目标, 企业过程和数据, 然后对数据进行分析, 自下而上地设计管理信息系统.

集成平台的基本功能

集成平台是支持企业信息集成的支撑环境, 包括硬件, 软件, 软件工具和系统.

集成平台的基本功能有:

1. 通信服务: 提供分布式环境下透明的同步/异步通信服务功能.
2. 信息集成服务: 为应用提供透明的信息访问服务, 实现异种数据库系统之间数据的交换, 互操作, 分布数据管理和共享信息模型定义.
3. 应用集成服务: 通过高层应用编程接口来实现对相应应用程序的访问, 能够为应用提供数据交换和访问操作, 使各种不同的系统能够相互协作.
4. 二次开发工具: 集成平台提供的一组帮助用户开发特定应用程序的支持工具.
5. 平台运行管理工具: 企业集成平台的运行管理和控制模块.

系统应用集成

应用集成说指两个或多个应用系统根据业务逻辑的需要而进行的功能之间的互相调用和互操作.

应用集成需要在数据集成的基础上完成, 应用集成在底层的网络集成和数据集成的基础上实现异构应用系统之间语用层次上的互操作, 它们共同构成了实现企业集成化运行最顶层会聚集成所需要的, 技术层次上的基础支持.

系统应用集成构建统一标准的基础平台, 在各个应用系统的接口之间共享数据和功能, 基本原则是保证应用程序的独立性. 系统应用集成提供了四个不同层次的服务, 最上层服务是流程控制服务.

快速应用开发

快速应用开发(RAD)是一种比传统生存周期法快得多的开发方法, 强调极短的开发周期.

RAD方法是瀑布模型的一个高速变种, 通过使用基于构件的开发方法获得快速开发. 由于构件本身的模拟化, 使得RAD方法很适合于模块化程度较高的系统开发.

需求变更管理

需求变更管理的基本过程:

1. 问题分析与变更描述
2. 变更分析与成本计算
3. 变更实现

自动化工具能够帮助变更控制过程更有效地运作, 一般具有以下特性:

1. 可以定义变更请求中的数据项
2. 可以定义变更请求生命周期的状态转换模型
3. 可以强制实施状态转换模型, 以便只有授权用户可以做出允许的状态变更
4. 可以记录每一个状态变更的日期和做出这一变更的人
5. 可以定义当提议者提交新请求或请求状态被更新时, 哪些人可以自动接收到电子邮件通知
6. 可以生成标准的和定制的报告和图表

螺旋模型

螺旋模型将瀑布模型和演化模型结合起来, 不仅体现了两个模型的优点, 而且还强调了其他模型均忽略的风险分析.

螺旋模型把整个软件开发流程分成多个阶段, 螺旋模型的每一个周期都包括需求定义(目标设定), 风险分析, 工程实现(开发和有效性验证), 评审四个阶段.

原型模型

原型模型又称为快速原型模型, 主要由原型开发阶段和目标软件开发阶段构成. 指的是在执行实际软件的开发之前, 应当建立系统的一个工作原型.

一个原型是系统的一个模拟执行, 和实际的软件相比, 通常功能有限, 可靠性较低及性能不充分. 一个原型通常是实际系统的一个比较粗糙的版本.

敏捷方法

敏捷方法的核心思想:

1. 敏捷方法是适应性而非预设性的
2. 敏捷方法以人为本, 而不是以过程为本
3. 敏捷方法以原型开发思想为基础, 采用迭代增量式开发, 发行版本小型化

敏捷方法适合的场景:

1. 项目团队人数不太多, 规模较小的项目
2. 项目经常发生变更, 系统的关联性, 可靠性, 安全性方面的要求不高
3. 高风险项目的实施

自顶向下和自底向上

自底向上过程可更快的发现系统性能方面的问题.

设计过程中的错误各种各样, 一般与采用自顶向下还是自底向上的过程关系不大.

软件方法学

软件方法学上软件开发全过程的指导原则与方法体系, 另一种含义是以软件方法为研究对象的学科.

从开发风范上看, 软件方法有自顶向下的开发方法, 自底向上的开发方法.

自顶向下是将一个大问题分化成多个可以解决的小问题, 然后逐一进行解决, 每个问题都会有一个模块去解决它, 且每个问题包括抽象步骤和具体步骤.

形式化方法是采用严格的数学方法, 使用形式化规约语言来精确定义软件系统. 基于数学的方式描述, 开发和验证系统.

非形式化方法是通过自然语言, 图形或表格描述软件系统的行为和特性, 然后基于这些描述进行设计和开发.

结构化分析方法

结构化分析方法的基本思想是自顶向下, 逐层分解. 经过逐层分解, 每个最底层的问题都是足够简单, 容易解决的.

结构化方法分析模型的核心是数据字典, 围绕这个核心有三个层次的模型: 数据模型, 功能模型和行为模型.

使用E-R图表示数据模型, 使用DFD(数据流图)表示功能模型, 使用状态转换图表示行为模型.

用例图, 对象图, 通信图, 顺序图, 活动图都是面向对象分析设计中所使用的工具.

数据流图和数据字典

在需求分析阶段, 数据流图通过数据的输入, 流向, 处理过程, 输出, 可清晰地反映出系统必须完成的逻辑功能, 从而可尽早发现是否有需要输入或输出的信息被遗漏, 以及系统各部分的逻辑是否存在错误.

数据字典是描述数据的信息集合, 通过数据字典可使参与人员对模型中的元素有共同的理解.

在设计阶段, 根据数据流图, 通过变换分析和事务分析的方法, 可设计出系统的模块结构(系统结构图).

根据数据字典中的数据存储描述可建立数据库存储设计.

可行性分析

可行性分析是所有项目投资在开始阶段必须进行的一项工作, 是对多因素, 多目标系统进行的分析, 评价和决策的过程, 通常包括经济可行性, 技术可行性, 法律可行性和用户使用可行性.

项目时间管理

项目时间管理的过程包括: 活动定义, 活动排序, 活动的资源估算, 活动历时估算, 制定计划和进度控制.

项目配置管理

项目配置管理有两大类产品配置项:

1. 属于产品组成部分的工作成果的配置项: 需求文档, 设计文档, 源代码和测试用例等.
2. 属于项目管理和机构支撑过程域产生的文档: 工作计划, 项目质量报告, 项目跟踪报告等. 这些文档虽然不是产品的组成部分, 但是值得保持.

产品配置

产品配置是指一个产品在其生命周期各个阶段所产生的各种形式和各种版本的文档, 计算机程序, 部件及数据的集合.

该集合中的每一个元素都称为该产品配置中的一个配置项, 每个配置项的主要属性有: 名称, 标识符, 文件状态, 版本, 作者, 日期等.

所有配置项都被保存在配置库里, 确保不会混肴, 丢失. 配置项及其历史记录反映了项目产品的演化过程.

软件设计

版本一

软件设计包括四个既独立又相互联系的活动:

1. 数据设计: 将模型转换成数据结构的定义, 好的数据设计将改善程序结构和模块划分, 降低过程复杂度.
2. 软件结构设计: 定义软件系统各主要部件之间的关系.
3. 人机界面设计: 定义软件内部, 软件和操作系统间以及软件和人之间如何通信.
4. 过程设计: 系统结构部件转换成软件的过程描述.

版本二

软件设计包括4个独立又相互联系的过程, 包括体系结构设计, 接口设计, 数据设计, 过程设计.

体系结构设计定义软件系统各主要部件之间的关系.

接口设计指软件内部, 软件和操作系统之间, 以及软件和人之间如何通信(人机界面设计).

数据设计将模型转换成数据结构的定义, 好的数据设计将改善程序结构和模块划分, 降低过程复杂性.

过程设计是系统结构部件转换成软件的过程描述.

高内聚, 低耦合是软件设计的基本原则.

设计

软件概要设计(也称为高层设计或总体设计)将软件需求转化为数据结构和软件的系统结构.

软件详细设计(也称为底层设计)即对结构图进行细化, 得到详细的数据结构和算法.

高内聚

模块的内聚类型分为七种, 根据内聚度从高到低的顺序为:

功能内聚, 顺序内聚, 通信内聚, 过程内聚, 时间内聚, 逻辑内聚, 偶然内聚.

内聚类型	描述
功能内聚	完成一个单一功能, 各个部分协同工作, 缺一不可
顺序内聚	处理元素相关, 而且必须顺序执行
通信内聚	所有处理元素集中在一个数据结构的区域上
过程内聚	处理元素相关, 而且必须按特定次序执行
时间内聚	所包含的任务必须在同一时间间隔内执行
逻辑内聚	完成逻辑上相关的一组任务
偶然内聚	完成一组没有关系或松散关系的任务

低耦合

模块的耦合类型分为七种, 根据耦合度从高到低的顺序为:

内容耦合, 公共耦合, 通信耦合, 控制耦合, 特征/标记耦合, 数据耦合, 非直接耦合.

其中内容耦合的耦合性最强, 独立性最弱, 因此不应该使用, 数据耦合的耦合性最弱, 因此尽量使用.

耦合类型	描述
内容耦合	一个模块直接访问另一个模块的内部数据; 一个模块不通过正常入库转到另一个模块的内部; 两个模块有一部分程序代码重叠; 一个模块有多个入口等.
公共耦合	多个模块都访问同一个公共数据环境, 公共的数据环境可以是全局数据结构, 共享的通信区, 内存的公共覆盖区等.
通信耦合	一组模块共用了一组输入信息, 或者它们的输出需要整合以形成完整数据, 即共享了输入或输出.
控制耦合	模块间传递的信息包含用于控制模块内部逻辑的信息
标记耦合	一组模块通过参数表传递记录等复杂信息(数据结构)
数据耦合	一组模块借助参数表传递简单数据
非直接耦合	两个模块之间没有直接关系, 它们之间的联系完全是通过上级模块的控制和调用来实现的

信息隐蔽

信息隐蔽是开发整体程序结构时使用的法则, 即将每个程序的成分隐蔽或封装在一个单一的设计模块中, 定义每一个模块时尽可能少地显露其内部的处理.

在设计时首先列出一些可能发生变化的因素, 在划分模块时将一个可能发生变化的因素隐蔽在某个模块内部, 使其他模块与这个因素无关. 在这个因素发生变化时, 只需修改含有这个因素的模块.

信息隐蔽的原则对提高软件的可修改性, 可测试性和可移植性都有重要的作用.

紧耦合和封装

在可移植性上, 紧耦合主要表现为: 一个模块高度依赖另一个模块, 当修改前者时, 必须同时修改后者. 解决方案为: 避免紧耦合, 而应采用松耦合方式.

在可移植性上, 封装主要表现为: 把业务逻辑封装在本模块中, 不允许外部模块之间访问本模块的内部信息. 解决方案为: 模块设计尽量采用封装, 外部模块只能通过该模块提供的接口予以调用.

模块化设计

模块化设计上将一个待开发的软件分解成若干小的简单部分--模块.

模块是执行某一特定任务的数据结构和程序代码.

通常将模块的结构和功能定义为外部特性, 将模块的局部数据和实现该模块的程序代码称为内部特性.

模块独立是指每个模块完成相对独立的特定子功能, 与其他模块之间的关系最简单. 通常用内聚和耦合两个标准来衡量模块的独立性, 其设计原则是高内聚, 低耦合.

结构化程序设计

结构化程序设计采用自顶向下, 逐步求精及模块化的程序设计方法, 通过顺序, 分支, 循环三种基本的控制结构可以构造任何单入口单出口的程序.

结构化设计是一种面向数据流的设计方法, 顺序图是一种UML图, 主要在面向对象设计中用于描述对象间消息及动作的时序关系, 是面向对象设计使用的工具.

应用系统构建技术

应用系统构建可以采用多种不同的技术, 有逆向工程, 重构, 设计恢复, 再工程.

一般认为, 凡是在软件生命周期内将软件某种形式的描述转换成更为抽象形式的活动都可称为逆向工程.

重构(重组)是指在同一抽象级别上转换系统描述形式.

设计恢复是指借助工具从已有程序中抽象出相关数据设计, 总体结构设计和过程设计的信息(不一定是原设计).

再工程是指在逆向工程所获信息的基础上修改或重构已有的系统, 产生系统的一个新版本.

逆向工程

逆向工程过程能够导出过程的设计模型(实现级), 程序和数据结构信息(结构级), 对象模型, 数据和控制流模型(功能级), UML状态图和部署图(领域级).

结构级包括反映程序各部分之间相互依赖关系的信息; 功能级包括反映程序段功能及程序段之间关系的信息.

软件测试

软件测试一般分为两大类, 即动态测试和静态测试.

动态测试通过运行程序发现错误, 包括黑盒测试(等价类划分, 边界值分析法和错误推测法) 与白盒测试(各种类型的覆盖测试, 路径覆盖, 逻辑覆盖等).

白盒测试中, 测试强度最高的是路径覆盖, 因为路径覆盖实际上考虑了各种判定结果的所有可能组合.

黑盒测试中的判定表方法最适合描述在多个逻辑条件取值组合所构成的复杂情况下, 分别要执行哪些不同的动作. 判定表是一种表达逻辑判断的工具, 它以所有条件为列, 以所有条件的各种可能的取值组合为行, 可全面直观地把复杂条件组合表达出来.

黑盒测试也称为功能测试, 主要用于集成测试, 确认测试和系统测试阶段, 不考虑程序的内部结构和处理算法, 只检查软件功能是否能按照要求正常使用.

静态测试用人工和计算机辅助静态分析的手段对程序进行检测, 包括桌前检查(桌面检查), 代码走查和代码审查等方法.

回归测试的目的是测试软件变更之后, 变更部分的正确性和对变更需求的符合性, 并且不能损害软件原有的, 正确的功能, 性能和其他规定的要素.

Alpha测试是一种验收测试, 在识别典型用户可能执行的任务并对其进行测试之前, 执行该测试是为了识别所有可能的问题和错误. Alpha测试的主要焦点是使用黑盒和白盒技术模拟真实用户.

Beta测试是由软件应用程序的真实用户在真实环境中执行的, 可以被视为外部用户验收测试的一种形式. 这是将产品发布之前的最终测试, 此测试有助于在用户的环境中测试产品. 软件的Beta版发布给有限数量的产品最终用户, 以获取对产品质量的反馈. Beta测试降低了产品故障风险, 并通过客户验证提高了产品质量.

Alpha测试	Beta测试
测试人员执行, 测试人员通常是内部人员	由非组织员工的客户或最终用户执行
开发人员站点执行的测试	在产品的客户端位置或最终用户执行
不进行深入的可靠性和安全性测试	检查可靠性, 安全性和健壮性
同时涉及白盒和黑盒测试	通常使用黑盒测试
需要实验环境或测试环境	不需要实验环境或测试环境, 向公众开放, 是生产环境
可能需要较长的执行周期	只需要几周的执行时间
开发人员在测试中立即解决关键问题或修复	收集问题和反馈, 并在产品的未来版本中修复或实现
为了在进入Beta测试之前确保产品质量	Beta测试也集中在产品质量上, 但会收集用户对产品的输入, 并确保产品可供实时用户使用

自动化测试工具

当前流行的自动化测试工具主要使用脚本技术来生成测试用例.

脚本是一组测试工具执行的指令集合, 其作用是通过回放的方式来模拟手工测试所执行的操作, 生成的脚本必须是可读的, 可编辑的, 并且应提供控制指令的支持, 使工具能够复用所编写的脚本.

好的脚本应该编写注释, 功能独立, 结构清晰可读, 文档完整.

脚本的基本结构有5种:

1. 线性脚本: 是采用录制工具记录测试人员手动执行测试用例的操作得到的脚本, 这些脚本是未做修改的.
2. 结构化脚本: 具有各种逻辑结构, 包括选择型结构, 分支结构, 循环迭代结构, 而且具有函数调用功能. 结构化脚本具有很好的可用性和灵活性, 易于维护.
3. 共享脚本: 是一个脚本可以被多个测试用例使用, 即脚本语言允许一个脚本调用另一个脚本.
4. 数据驱动脚本: 是将测试输入存储在独立的数据文件中, 而不是脚本中, 这样脚本可以针对不同的数据输入实现多个测试用例.
5. 关键字驱动脚本: 是数据驱动脚本的逻辑扩展, 用测试文件描述测试用例, 说明测试用例做什么, 而不是如何做. 关键字驱动脚本允许使用描述性的方法, 只需要提供测试用例的描述, 即可生成测试用例.

软件性能测试

软件性能测试类型包括:

1. 负载测试: 用于测试超负荷环境中程序是否能够承担
2. 强度测试: 是在系统资源特别低的情况下考查软件系统极限运行情况
3. 容量测试: 用于测试系统同时处理的在线最大用户数量

软件文档

软件系统的文档可以分为用户文档和系统文档两类.

用户文档主要描述系统功能和使用方法, 并不关心这些功能是如何实现的.

系统文档描述系统设计, 实现和测试等各方面的需求.

软件需求

软件需求开发的最终文档通过评审批准后, 就定义了开发工作的需求基线, 这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定, 需求约定是需求开发和需求管理之间的桥梁.

软件过程

软件过程是制作软件产品的一组活动及其结果, 这些活动主要由软件人员来完成, 软件活动主要包括:

1. 软件描述: 定义软件功能以及使用的限制
2. 软件开发: 软件的设计和实现, 软件工程人员制作出能满足描述的软件
3. 软件有效性验证: 软件必须经过严格的验证, 以保证能够满足客户的需求
4. 软件演化: 软件随着客户需求的变化不断改进

软件复用

软件复用的形式可分为垂直式复用和水平式复用.

水平式复用是复用不同应用领域中的软件元素, 如数据结构, 排序算法, 人机界面构件等, 标准函数库是一种典型的原始的水平式复用机制.

垂直式复用是在一类具有较多公共性的应用领域之间复用软件构件. 由于在两个截然不同的应用领域之间进行软件复用(水平式复用)的潜力不大, 所以垂直式复用受到广泛关注.

软件工具

对应软件开发过程的各种活动, 软件开发工具有:

1. 需求分析工具
2. 设计工具
3. 编码和排错工具
4. 测试工具

等.

按描述需求定义的方法可将需求分析工具分为基于自然语言或图形描述的工具和基于形式化需求定义语言的工具.

软件建模工具是辅助建立软件系统的抽象模型的, 常见的软件建模工具有:

Rational Rose, Together, WinA&D, QuickUML, EclipseUML等.

软件开发环境

软件开发环境(SDE)是指支持软件的工程化开发和维护而使用的一组软件, 由软件工具集和环境集成机制构成.

软件开发环境应支持多种集成机制, 如平台集成, 数据集成, 界面集成, 控制集成, 过程集成等; 软件开发环境应支持小组工作方式, 并为其提供配置管理. 环境的服务可用于支持各种软件开发活动, 包括分析, 设计, 编程, 调试和文档等.

较完善的软件开发环境通常具有多种功能, 如软件开发的一致性与完整性维护, 配置管理及版本控制, 数据的多种表示形式及其在不同形式之间的自动转换, 信息的自动检索与更新, 项目控制和管理, 以及对开发方法学的支持. 软件开发环境有集成性, 开放性, 可裁剪性, 数据一致性, 风格统一的用户界面等特性, 因而能大幅度提高软件生产率.

集成机制根据功能的不同, 可划分为环境信息库, 过程控制与消息服务器, 环境用户界面三个部分:

1. 环境信息库: 软件开发环境的核心, 用于存储与系统开发相关的信息, 并支持信息的交流与共享. 主要存储两类信息: 一类是开发过程中产生的有关被开发系统的信息, 如分析文档, 设计文档和测试报告等; 另一类是环境提供的支持信息, 如文档模块, 系统配置, 过程模型和可复用构件等.
2. 过程控制与消息服务器: 实现过程集成和控制集成的基础, 过程基础是按照具体软件开发过程的要求进行工具的选择与组合; 控制集成使各工具之间进行并行通信和协同工作.
3. 环境用户界面: 包括环境总界面和由它实行统一控制的各环境部件及工具的界面, 统一并具有一致性的用户界面是软件开发环境的重要特征, 是充分发挥环境的优越性, 高效地使用工具并减轻用户学习负担的保证.

遗留系统的评价框架

遗留系统的评价结果分别列在坐标的四个象限内, 横轴是业务价值, 纵轴是技术水平.

第一象限是: 高水平, 高价值区, 演化策略为改造.

第二象限是: 高水平, 低价值区, 演化策略为集成.

第三象限是: 低水平, 低价值区, 演化策略为淘汰.

第四象限是: 低水平, 高价值区, 演化策略为继承.

EJB构件

EJB是企业级Java构件, 用于开发和部署多层结构, 分布式和面向对象的Java应用程序.

EJB构件分为会话构件, 实体构件和消息驱动构件.

会话构件: 用于实现业务逻辑, 可以有状态的, 也可以无状态的, 负责完成服务端与客户端的交互.

实体构件: 用于实现O/R映射, 负责将数据库中的表记录映射为内存中的实体对象. 用于数据持久化来简化数据库开发工作.

消息驱动构件: 基于JMS消息, 只能接收客户端发送的JMS消息后处理, 是一个异步的无状态会话构件. 消息驱动构件将异步处理客户请求, 用来处理并发和异步访问操作.

Web服务器指标

Web服务器的主要性能指标有: 最大并发连接数, 响应延迟, 吞吐量, QPS, TPS, RPS等.

Web服务器的性能评测方法有: 基准性能测试, 压力测试和可靠性测试.

软件体系结构

多视图

在软件体系结构的建模与描述中, 多视图是一种描述软件体系结构的重要途径, 其体现了关注点分离的思想.

4+1模型是描述软件体系结构的常用模型, 其中4是指四个视图: 逻辑视图, 开发视图, 进程视图, 物理视图. 1是指统一场景.

逻辑视图也称为设计视图, 它描述了建模系统的组成部分以及各组成部分之间的交互方式, 通常包括类图, 对象图, 状态图, 协作图.

过程视图是以可执行线程和进程作为活动类的建模, 是逻辑视图的一次执行实例, 描述了并发与同步特征.

实现(开发)视图是对组成系统的物理代码的文件和构建进行建模, 描述系统的各部分如何被组织为模块和组件, 也就是开发环境中软件的静态组织结构, 该视图通常包含包图和组件图.

ABSD

基于体系结构的软件设计(ABSD)方法是由体系结构驱动的, 即是由体系结构的商业, 质量和功能需求的组合驱动的. ABSD方法是一个自顶向下, 递归细化的方法, 软件系统的体系结构通过该方法得到细化, 直到能产生软件构件和类(或模块).

视角和视图

考虑体系结构时, 重要的是从不同的视角来检查. 展示功能组织的静态视角能判断质量特性, 展示并发行为的动态视角能判断系统的行为特性.

特定的视角或视图: 逻辑视图, 开发视图, 实现视图, 配置视图.

使用逻辑视图来记录设计元素的功能和概念接口, 设计元素的功能定义了它本身在系统中的角色, 这些角色包括功能, 性能等.

体系结构文档化

体系结构文档化有助于辅助系统分析人员和程序员实现体系结构, 主要输出包括体系结构规格说明, 测试体系结构需求的质量设计说明书.

文档的完整性和质量是软件体系结构成功的关键因素, 文档要从使用者的角度进行编写, 必须分发给所有与系统有关的开发人员, 且必须保证开发者手中的文档是最新的.

权衡分析方法

体系结构权衡分析方法(ATAM)包含四个主要的活动领域, 分别是:

1. 场景和需求收集
2. 体系结构视图和场景实现
3. 属性模型构造和分析
4. 折中

基于场景的架构分析方法(SAAM)的主要输入是:

1. 问题描述
2. 需求声明
3. 体系结构描述

SAAM分析评估体系结构的过程包括:

1. 场景开发
2. 体系结构描述
3. 单个场景评估
4. 场景交互
5. 总体评估

SAAM考查的是软件体系结构单独的质量属性; 而ATAM提供从多个竞争的质量属性方面来理解软件体系结构的方法, 使用ATAM不仅能看到体系结构对于特定质量目标的满足情况, 还能认识到在多个质量目标间权衡的必要性.

特定领域软件架构(DSSA)

特定领域软件架构(DSSA)以一个特定领域为对象, 形成由领域参考模型, 参考需求, 参考架构等组成的开发基础架构, 其目标是支持一个特定领域中多个应用的生成.

DSSA的基本活动包括: 领域分析, 领域设计, 领域实现.

领域分析的主要目的是获得领域模型--描述领域中系统之间的共同需求, 即领域需求.

领域设计的主要目标是获得DSSA--DSSA描述领域需求的解决方案.

领域实现的主要目标是依据领域模型和DSSA开发和组成可重用信息, 并实现基础软件架构.

从功能覆盖范围的角度, Domain包含两层含义:

1. 垂直域: 定义了一个特定的, 包含多个系统的系统族
2. 水平域: 定义了多个系统族之间功能区域的共有部分

架构设计

软件需求到架构映射

软件需求到架构的映射存在的难点:

1. 描述语言方面: 需求由于更加切近用户, 所用的描述语言可能会不够正规和标准, 可能存在语义含糊不清, 甚至歧义等情况; 而软件架构所用的描述语言需要正规和标准, 不允许存在含糊, 歧义等情况.
2. 非功能性需求方面: 需求阶段可能不太关注, 或者描述的比较笼统; 而架构阶段, 则需要明确量化.
3. 需求和架构的一致性方面: 需求与架构无法做到完全一致和一一映射, 例如某个需求在架构上需要通过多种技术啊来实现, 简言之, 架构提供的能力是大于需求的.

软件架构风格

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式, 架构风格反映领域中众多系统共有的结构和语义特征, 并指导如何将各个模块和子系统有效地组织成一个完整的系统, 强调对架构设计的重用.

某公司开发一个新闻系统, 该系统可根据用户注册时选择的兴趣方向向用户推送其感兴趣的新闻内容, 该系统采用事件驱动架构风格最为合适. 因为系统会把新闻按兴趣分类, 如果某个新闻事件发生, 可以通过事件来触发推送动作, 将新闻推送给对该类新闻感兴趣的用户, 是典型的事件驱动系统应用场景.

批处理风格软件体系结构中, 每个处理步骤是一个单独的程序, 每一步必须在前一步结束后才能开始, 并且数据必须是完整的, 以整体的方式传递.

基于规则的系统包括规则集, 规则解释器, 规则/数据选择器以及工作内存, 一般用在人工智能领域和决策支持系统(DSS)中. 基于规则的系统中的规则引擎负责对规则进行解释实现, 能够将业务规化与应用程序分离开来, 在个人社保管理系统中, 社保金的计算方式发生变化, 仅需改变规则而无需改变应用程序本身.

层次型

物联网系统属于层次型软件架构风格, 分为感知层, 网络层, 应用层.

感知层负责信息采集和物物之间的信息传输, 网络层负责利用网络对采集的数据进行编码, 认证和传输, 应用层负责各种应用的实现.

三层C/S架构将应用系统分成表示层, 功能层(业务逻辑层)和数据层三个层次. 表示层是系统的用户接口部分, 担负着用户与系统之间的对话功能; 功能层负责具体的业务逻辑的处理; 数据层负责数据的存储和管理.

面向对象风格

面向对象风格通过编写新的规则实现代码, 并通过应用重启或热加载添加规则, 可修改性较差; 解释器风格通过编写新的规则文件, 并通过导入资源文件或外部配置添加规则, 可修改性较好.

面向对象风格通过策略模式定义规则对象, 以程序逻辑实现规则, 灵活性较差; 解释器风格可灵活定义规则计算表达式, 灵活性更好.

面向对象风格通常将规则以源代码描述, 并以编译后的代码运行, 性能好; 解释器风格需要加载规则, 解析规则, 规则运算, 再得出结果, 性能较差.

解释器风格

面向对象风格效率高, 质量高, 易维护, 可修改性稍差, 灵活性稍差, 性能高; 解释器风格可修改性高, 个性化和灵活性强, 性能较差.

解释器风格针对不同的语法规则, 只需对解释器进行扩展即可, 因此可应对语法规则的不断改变及扩展, 缺点是如果语法规则数量太多, 会增加系统复杂度, 性能下降.

管道过滤器风格

管道过滤器风格具备高内聚, 低耦合, 支持软件重用, 扩展性好, 支持并发等优点, 但有编写复杂, 不适合处理交互应用等缺点.

管道过滤器架构风格是由一系列处理单元(过滤器)组成, 每个单元的输出是一个单元的输入. 过滤器负责处理数据, 管道负责数据传输.

优点:

1. 高内聚: 过滤器是执行特定功能的处理服务, 具有较强的内聚性.
2. 低耦合: 过滤器之间仅通过管道通信.
3. 可重用: 支持过滤器的重用
4. 能简单地实现并发或顺序系统
5. 可扩展性: 容易添加新的过滤器
6. 灵活性: 过滤器功能可重新定义, 管道线路可改变

缺点:

1. 管道中数据传输需要通用的标准
2. 难以支持基于事件的交互

隐式调用(事件触发)

隐式调用基于事件触发的思想, 具备支持软件重用, 改进系统方便等优点, 但有构件放弃了对系统计算的控制, 事件传递中的数据交换存在问题, 语义依赖于被触发事件的上下文约束等缺点.

仓库风格

仓库风格是一种数据共享风格, 主要有两类: 一类是传统的数据库, 一类是黑板.

数据库是由输入流中的事件来驱动信息处理, 把执行结构存储到中央数据单元.

黑板则由中央数据单元的当前状态来驱动系统运行, 用来解决状态冲突并处理可能存在的不确定性知识源.

黑板常用信号处理, 如语音识别, 模式识别, 机器翻译, 句法分析等. 优点有:

1. 便于多客户共享大量数据, 不必关系数据的产生, 由谁提供, 如何提供等.
2. 便于将构件作为知识源添加到系统中来
3. 解决问题的多方法性
4. 具有可修改性和可维护性
5. 有可重用的知识源
6. 支持容错性和健壮性

缺点:

1. 对共享数据结构, 不同的知识源要达成一致
2. 需要同步机制, 加锁机制来保障数据的完整性和一致性, 增大了系统设计的复杂度
3. 测试困难
4. 缺少对并行机的支持, 效率低
5. 开发成本高

仓库风格有两种不同的构件: 中央数据结构说明当前状态, 独立构件在中央数据存储上执行.

按控制策略的选取分类, 可以产生两个主要的子类:

1. 若输入流中某类事件触发进程执行的选择, 则仓库是传统型数据库.
2. 若中央数据结构的当前状态触发进程执行的选择, 则仓库是黑板系统.

体系风格

数据流体系结构风格包括: 批处理体系结构风格, 管道-过滤器体系结构风格.

虚拟机体系结构风格包括: 解释器体系结构风格, 规则系统体系结构风格.

层次型体系结构风格: C2

软件架构复用

在软件架构复用中, 资产复用是指在开发过程中, 只要发现有可复用的子串, 就对其进行复用.

计划复用是指在开发之前, 就要进行规划, 以决定哪些需要复用.

软件复用过程的四个阶段:

1. 创建: 主要是构造或获取可复用资产, 以满足复用者的需要.
2. 复用: 主要是使用可复用资产来生产应用软件产品.
3. 支持: 主要是全面支持可复用资产的获取, 管理和维护工作.
4. 管理: 主要是对可复用资产进行管理.

其中创建, 复用, 管理是主要阶段.

质量属性和实现策略

可用性质量属性, 实现策略有: 心跳, Ping/Echo, 主动冗余, 被动冗余, 选举, 检查点等架构策略.

性能质量属性, 实现策略有: 增加计算资源, 减少计算开销, 引入并发机制, 采用资源调度, 负载均衡, 资源仲裁, 资源管理, 资源需求等架构策略.

安全性质量属性, 实现策略有: 加密, 入侵检测, 用户认证, 用户授权, 追踪审计等架构策略.

常见的六个质量属性有: 可用性, 可修改性, 性能, 安全性, 可测试性, 易用性.

质量属性场景是一种面向特定质量属性的需求, 由六部分组成: 刺激源, 刺激, 环境, 制品, 响应, 响应度量.

安全性是系统向合法用户提供服务并阻止非法用户的能力.

性能是指系统的响应能力, 即要经过多长时间才能对某个事件做出响应, 或者在某段时间内系统所能处理的事件的个数.

可用性是指系统能够正常运行的时间比例, 经常用两次故障之间的时间长度或在出现故障时系统恢复正常的速度来表示.

可靠性是软件系统在意外或错误使用的情况下维持软件系统功能特性的能力.

可靠性

可靠性(Reliability)是指产品在规定的条件下和规定的时间内完成规定功能的能力.

常用的度量指标主要有: 故障率(失效率), 平均失效等待时间, 平均失效间隔时间和可靠度.

可靠度是软件系统在规定的条件下, 规定的时间内不发生失效的概率.

平均失效等待时间(MTTF): 指本次修复好后开始到下一次失效的平均时间

平均失效间隔时间(MTBF): 两次失效间隔的平均时间

假设总的时间为T, 共失效n次, 每次失效时间为t, 则MTTF = T / n; MTBF = (T - n*t) / n = T / n - t

当失效率(失效次数)为常数, 修复时间很短(失效时间)的情况下, MTTF和MTBF几乎相等.

MTBF, MTTR, MTTF三个指标的区别 1、MTBF, 全称是Mean Time Between Failure, 即平均无故障工作时间. 就是从新的产品在规定的工作环境条件下开始工作到出现第一个故障的时间的平均值. MTBF越长表示可靠性越高正确工作能力越强. 2、MTTR, 全称是Mean Time To Repair, 即平均修复时间. 是指可修复产品的平均修复时间, 就是从出现故障到修复中间的这段时间. MTTR越短表示易恢复性越好. 3、MTTF, 全称是Mean Time To Failure, 即平均失效时间. 系统平均能够正常运行多长时间, 才发生一次故障. 系统的可靠性越高, 平均无故障时间越长.

可靠性是最初是确定一个系统在一个特定的运行时间内有效运行的概率的一个标淮. 可靠性的衡量需要系统在某段时间内保持正常的运行.

易用性

想要学习系统特性, 有效使用系统, 使错误的影响最低, 适配系统, 对系统满意属于易用性质量属性的要求, 也是质量属性场景的刺激.

软件系统质量属性

软件系统质量属性是一个系统的可测量或者可测试的属性, 被用来描述系统满足利益相关者需求的程度.

其中包含开发期质量属性和运行期质量属性.

开发期质量属性包括: 可理解性, 可扩展性, 可重用性, 可测试性, 可维护性, 可移植性.

其中可维护性关注的是当需要修改缺陷, 增加功能, 提供质量属性时, 定位修改点并实施修改的难易程度.

运行期质量属性包括: 性能, 安全性, 可靠性, 易用性, 可伸缩性, 持续可用性, 健壮性.

可伸缩性关注的是当用户数和数据量增加时, 软件系统维持高服务质量的能力.

软件著作权

计算机软件保护条例第11条规定: 接受他人委托开发的软件, 其著作权的归属由委托人与受托人签订书面合同约定; 无书面合同或者合同未作明确约定的, 其著作权由受托人享有.

委托开发时, 著作权属于委托人或委托公司, 即软件著作权人. 受托人(开发人员)没有著作权, 如果将开发软件修改并售卖给其他人员, 则构成侵权行为.

盗版软件持有者判断是否侵权, 以软件复制品持有人主观上知道(或者应当知道)所持软件是否为侵权复制品依据. 盗版软件持有者不知道软件是盗版的, 因此不必承担侵权责任.

著作权法规定: 作品原件所有权的转移, 不改变作品著作权的归属, 但美术, 摄影作品原件的展览权由原件所有人享有.

软件的著作权自软件开发完成之日起产生.

M公司在软件开发完成时就自动享有该软件的著作权. 如果进行了商标注册, 则享有商标权. 对员工签了保密协议就享有了商业秘密权, 只有根据软件或软件的某功能成功申请专利后, 才可享有专利权.

著作权归属

改编, 翻译, 注释, 整理已有作品而产生的作品, 其著作权由改编, 翻译, 注释, 整理人享有, 但行驶著作权时不得侵犯原作品的著作权.

一般职务作品, 作者享有著作权, 单位享有优先使用作品的权利.

特殊职务作品的著作权归单位, 作者享有署名权.

委托作品的著作权根据合同约定, 合同未明确或未签订合同的著作权属于受托人.

合作作品的著作权归属于所有参与人(不含组织创作人).

权利期限

发表权也称公开作品权, 指作者对尚未发表的作品享有决定是否公之于众的权利, 只能行使一次, 只能为作者享有.

著作权的发行权时是指著作权人许可他人向公众提供作品原件或者复制件, 可行使多次, 并且不仅仅为作者享有.

传播权是指著作权人享有向公众传播其作品的权利, 传播权包括表演权, 播放权, 发行权, 出租权, 展览权等内容.

署名权是作者表明其身份, 在作品上署名的权利, 是作者最基本的人身权利.

作者的署名权, 修改权, 保护作品完整权的保护期不受限制.

软件著作权受法律保护的期限是50年. 一旦保护期满, 权利将自行终止, 称为社会公众可以自由使用的知识.

无软件盗版者定义

软件盗版者在法律条文中并无定义, 有定义的是侵权行为.

未经软件著作权人许可, 修改, 翻译, 复制, 发行著作人的软件的, 属于侵权行为, 应承担相应的民事, 行政和刑事责任.

为了学习和研究软件内含的设计思想和原理, 通过安装, 显示, 传输或者存储软件等方式使用软件的, 可以不经软件著作人许可, 不向其支付报酬.

仅对源程序的标识符进行修改, 程序其他部分不变属于侵犯软件著作权的行为.

软件产品管理办法

软件产品管理办法规定: 任何单位和个人不得开发, 生产, 销售, 进出口含有以下内容的软件产品: 侵犯他人知识产权的, 含有计算机病毒的, 可能危害计算机系统安全的, 含有国家规定禁止传播的, 不符合我国软件标准规范的.

质量属性效用树

质量属性效用树是对质量属性进行分类, 权衡, 分析的架构分析工具, 主要关注系统的性能, 可用性, 可修改性和安全性四个方面的质量属性.

质量属性效用树是采用架构权衡分析方法(ATAM)进行架构评估的工具之一, 其树型结构从根部到叶子节点依次为树根-质量属性-属性分类(细化/求精)-质量属性场景.

系统架构风险

系统架构风险是指架构设计中潜在的, 存在问题的架构决策所带来的隐患.

敏感点是指为了实现某种特定的质量属性, 一个或多个系统组件所具有的特性.

权衡点是指影响多个质量属性, 并对多个质量属性来说都是敏感点的系统属性.

架构评估

在进行架构评估时, 首先要明确具体的质量目标, 并以之作为判定该架构优劣的标准. 为得出这些目标而采用的机制叫做场景, 场景是从利益相关者(Stakeholder-风险承担者)的角度简短描述他与系统的交互.

在进行架构评估时, 一般首先要精确地得出具体的质量目标, 并以之作为判定该体系结构优劣的标准, 常采用场景的方法来比较精确地得到这些目标.

场景是从利益相关者的角度对系统交互的简短描述, 在体系结构评估中, 一般采用刺激, 环境, 响应三方面来对场景进行描述.

刺激用于描述利益相关者如何引发与系统的交互; 环境用于描述刺激发生时的系统情况; 响应用于描述系统是如何对刺激做出反应的.

云原生架构的原则

服务化原则, 弹性原则, 可观测原则, 韧性原则, 所有过程自动化原则, 零信任原则, 架构持续演进原则

微服务拆分要适度

微服务的拆分要适度, 过分服务化的拆分反而会导致新架构与组织能力的不匹配, 让架构升级得不到技术红利, 过分服务化的拆分会导致的问题:

1. 发布与维护问题: 软件规模不大, 团队人数也少, 但是为了微服务化, 强行把耦合度高, 代码量少的模块进行服务化拆分, 一次性的发布需要拆分为多个模块分开发布和维护.
2. 数据依赖问题: 服务虽然拆分为多个, 但是这些服务的数据是紧密耦合的, 于是让这些服务共享数据库, 导致数据的变化往往被扇出到多个服务中, 造成服务间数据依赖.
3. 性能问题: 当耦合性很强的模块被拆分为多个微服务后, 原来的本地调用变成了分布式调用, 从而让响应时间变长, 导致整个服务链路性能下降.
4. 维护问题: 过小的拆分粒度会导致过多的微服务数量, 过多的微服务数量会导致微服务之间的关系变得更为复杂而庞大, 从而使得关系的维护变得复杂.

嵌入式系统的开放式架构

开放式架构的四个基本特点:

1. 可移植性: 应用系统可在具有开放式架构特性的各种计算机系统间进行移植, 不论这些计算机是否同种型号, 同种机型.
2. 可互操作性: 如网络中的各节点机都具有开放式架构的特性, 则该网上各个节点机间可相互操作和资源共享.
3. 可剪裁性: 如某个计算机系统具有开放式架构特性, 则在该系统的低档机上运行的应用系统应能在高档机上运行, 原在高档机上运行的应用系统经剪裁后也可在低档机上运行.
4. 易获得性: 在具有开放式架构特性的机器上所运行的软件环境易于从多方获得, 不受某个来源所控制.

嵌入式实时操作系统的特点

1. 可剪裁性
2. 可移植性
3. 强实时性
4. 强紧凑性
5. 高质量代码
6. 强定制性
7. 标准接口
8. 强稳定性, 弱交互性
9. 强确定性
10. 操作简洁, 方便
11. 较强的硬件适应性
12. 可固化性

嵌入式实时操作系统

调度算法

1. 优先级调度算法: 系统为每个任务分配一个相对固定的优先顺序, 调度程序根据任务优先级的高低程度, 按时间顺序进行高优先级任务优先被调度.
2. 抢占式优先级调度算法: 在优先级调度算法的基础上, 允许高优先级任务抢占低优先级任务而运行.
3. 最晚截止期调度算法: 是指系统按每个任务的最接近其截止期末端的时间进行调度, 系统根据当前任务截止期的情况, 选取最接近截止期的任务运行.
4. 最早截止期调度算法: 是指系统按每个任务的截止期时间, 选取最早到截止期的头端时间的任务进行调度.

混成系统

混成系统一般由离散分离组件和连续组件并行或串行组成, 组件之间的行为由计算模型进行控制.

软件层面的功耗控制

嵌入式系统设计一般要考虑低功耗, 软件设计也要考虑低功耗设计, 可从下面几个方面展开:

1. 软硬件协同设计: 软件的设计要与硬件的匹配, 考虑硬件因素
2. 编译优化: 采用低功耗优化的编译技术
3. 算法优化: 从算法角度进行优化
4. 采用中断驱动技术和延时程序
5. 进行电源的有效管理

分层架构的脆弱性

分层架构的缺点(脆弱性)主要有:

1. 级联修改问题: 当业务流程发生变化时, 所有层都需要修改.
2. 性能问题: 整个系统中层层传递, 势必造成性能下降, 同时也加大了开发的复杂度.
3. 层层依赖问题: 基础层(底层)被其他层依赖, 处于最核心位置, 一旦出错, 必然影响上层的调用, 从而可能导致系统异常, 严重的甚至崩溃.

NDB基于网络的数据库系统

基于网络的数据库系统(NDB)是基于4G/5G的移动通信上, 在逻辑上可以把嵌入式设备看作远程服务器的一个客户端.

NDB主要由客户端, 通信协议, 远程服务器等三部分组成.

NDB的客户端主要负责提供接口给嵌入式程序, 通信协议负责规范客户端与远程服务器之间的通信, 远程服务器负责维护服务器上的数据库数据.

如果一个NDB可不加裁剪地支持任何类型的嵌入式设备, 那这个NDB不会太小, 而嵌入式设备的存储及性能相对来说都是有限的, 因此NDB需要可裁剪, 当然也需要代码重用.

NDB是以文件方式存储数据库数据, 即数据按照一定格式存储在磁盘中, 使用时由应用程序通过相应的驱动程序或直接对数据文件进行读写.

云计算服务体系结构

PaaS(Platform as a Service): 平台即服务

SaaS(Software as a Service): 软件(应用)即服务

IaaS(Infrastructure as a Service): 基础设施即服务

计算机基础知识

题目: 若系统正在将系统目录文件修改的结果写回磁盘时发生掉电, 则对系统影响较大.

解释: 用户程序, 用户数据异常一般不会对系统本身造成较大的影响, 但系统对系统本身的系统文件(如系统目录等)回写异常可能导致较大影响, 严重时会导致系统崩溃.

段页式存储管理

段页式存储管理的基本思想是将段式存储管理与分页存储管理结合起来, 段页式存储管理将作业分为若干段, 每个段分成若干页, 每段赋予一个段名, 为了实现地址转换, 必须为每个作业配置一张段表和若干张页表.

内存分配与回收以页为单位进行, 作业的逻辑是二维的, 包括段号和段内地址, 其中段内地址包含页号和页内地址两部分.

域名解析配置文件

/etc/resolv.conf是多种操作系统(Linux, UNIX, Mac等)的域名系统解析器(DNS)的配置文件.

网络延迟

造成网络延迟的因素很多, 比如物理线路的带宽, 网络之间的跳数, 排队时延, 服务器的处理性能(队列, 数据的读写, 磁盘IO等), 如果不考虑网络因素, 服务器的延迟的主要因素是队列延迟和磁盘IO延迟.

对等网络(p2p)中, 每一个节点的地位都是对等的, 即当服务器, 同时也享有其他节点提供的服务, 因此p2p网络的延迟与终端数量是有关的.

二层交换机按MAC地址寻址, 比三层路由器寻址少一层, 因此同样速率的交换机比路由器速度更快.

系统监视

进行系统监视通常有三种方式:

1. 通过系统命令, 如果Linux/UNIX系统中的ps, last等
2. 通过系统记录文件查阅系统在特定时间内的运行状态
3. 集成命令, 文件记录和可视化技术的监控工具, 如Windows的PerfMon

串行总线

串行总线是计算机外部接口中常用的一种数据传输接口, 适应于长距离数据传输使用.

一般串行总线是按位(bit)传输数据的, 采用校验码进行数据校验; 串行总线的工作方式, 传输位数, 波特率等属性是通过程序可随时配置和更改的.

串行总线的工作方式可分为全双工和半双工两种, 数据状态一般分为满状态, 空状态, 就绪状态等; 常用的全双工串行总线有RS-232等, 半双工串行总线有RS-422等.

串行总线的数据发送和接收可以使用查询和中断两种方式.

磁盘调度管理

在磁盘调用管理中, 应先进行移臂调度, 再进行旋转调度. 如果采用最短移臂调度算法, 那么移臂是找柱面, 按照最近原则调度; 旋转则是找扇区, 按单向最近原则调度(扇区号从小到大).

数据库三级模式

数据库三级模式: 外模式, 模式, 内模式.

外模式也称用户模式, 是用户看到的数据视图.

模式又称逻辑模式, 是指全体数据间的各种关系.

内模式也称存储模式, 定义的是存储记录的类型, 存储域的表示, 存储记录的物理顺序以及索引和存储路径等数据的存储组织方式.

如果对一个表创建聚簇索引, 那么改变的是数据库的内模式.

数据库的动态备份是指备份期间允许对数据库进行存取或修改, 即备份和用户事务可以并发执行.

数据库函数依赖的公里体系

Armstrong 公理系统: 设关系模型R<U, F> 其中U为属性集, F是U上的一组函数依赖, 那么有如下推理规则:

1. 自反律: 若Y⊆X⊆U, 则X->Y为F所蕴含
2. 增广律: 若X->Y为F所蕴含, 且Z⊆U, 则XZ->YZ为F所蕴含
3. 传递律: 若X->Y, Y->Z为F所蕴含, 则X->YZ为F所蕴含

上面三条推理规则, 可继续推出下面三条推理规则:

1. 合并规则: 若X->Y, X->Z, 则X->YZ为F所蕴含
2. 伪传递规则: 若X->Y, WY->Z, 则XW->Z为F所蕴含
3. 分解规则: 若X->Y, Z⊆Y, 则X->Z为F所蕴含

函数依赖闭包

设X是函数依赖集, 被X逻辑蕴含的函数依赖全体构成的集合, 称为函数依赖集X的闭包. 闭包本质上是这些属性能直接或间接推出的属性集的集合.

鸿蒙操作系统

HarmonyOS是基于微内核的全场景分布式OS. 宏内核用一个内核统管全局, 微内核使用不同的内核管理不同的场景或设备.

鸿蒙操作系统整体架构采用分层的层次设计, 从下到上依次为: 内核层, 系统服务层, 框架层, 应用层.

鸿蒙操作系统架构采用了分布式设计理念, 实现了分布式软总线, 分布式设备虚拟化, 分布式数据管理和分布式任务调度四种分布式能力.

鸿蒙操作系统架构的安全性主要体现在搭载HarmonyOS的分布式终端上, 可以保证正确的人, 通过正确的设备, 正确地使用数据.

微内核

从操作系统中去掉尽可能多的东西, 而只留下一个最小的核心, 称之为微内核.

微内核技术的主要优点如下:

1. 统一的接口, 在用户态和核心态直接无需进程识别
2. 可伸缩性好, 能适应硬件更新和应用变化
3. 可移植性好, 所有与具体机器特征相关的代码, 全部隔离在微内核中, 如果操作系统要移植到不同的硬件平台上, 只需修改微内核中的极少代码即可.
4. 实时性好, 微内核可以方便地支持实时处理
5. 安全可靠性高, 微内核将安全性作为系统内部特性来进行设计, 对外仅使用少量应用编程接口.
6. 支持分布式系统, 支持多处理器的体系结构和高度并行的应用程序

微内核技术的缺点:

1. 难以进行良好的整体优化
2. 进程间通信的开销大, 内核功能代码不能被相互调用, 从而服务的效率低

但总体而言微内核在效率上的损失小于在其结构上获得的收益.

DSP

目前处理器市场中存在CPU和DSP两种类型的处理器, 分别用于不同场景.

常见的计算机体系结构采用的是冯诺依曼结构, 由于该结构没有区分程序存储器和数据存储器, 因此导致了总线拥堵. DSP需要的高度并行处理技术, 在总线宽度的限制下必然会降低并行处理能力.

哈佛结构是专门为数字信号处理(DSP)设计的一种体系架构, 其结构的基本特征是用多个内部数据地址, 以提高数据吞吐量.

GPU结构一般采用的是CPU+FPGA结构, 其核心还是冯诺依曼结构.

GPU

最新的GPU(RTX 4090)峰值性能可高达100TFlops(每秒执行100万亿次浮点运算次数)以上.

CPU

CPU的工作频率 (主频) = 外频 X 倍频

外频是外部频率, 是系统总线频率

倍频全称是倍频系数, 指CPU主频与外频之间的相对比例关系.

AI芯片

AI芯片的技术架构包括: 图形处理单元(GPU), 现场可编程门阵列(FPGA), 专用集成电路(ASIC), 张量处理单元(TPU).

AI芯片的四种关键特征: 新的计算范式, 训练和推理, 大数据处理能力, 可重构的能力.

SoC

一般说来, SoC称为系统级芯片, 也有称片上系统, 意指它是一个产品, 是一个有专用目标的集成电路, 其中包含完整系统并有嵌入软件的全部内容. 同时它又是一种技术, 用以实现从确定系统功能开始, 到软/硬件划分, 并完成设计的整个过程.

从狭义角度讲, 它是信息系统核心的芯片集成, 是将系统关键部件集成在一块芯片上.

从广义角度讲, SoC是一个微小型系统, 如果说中央处理器(CPU)是大脑, 那么SoC就是包括大脑, 心脏, 眼睛和手的系统. 国内外学术界一般倾向将SoC定义为将微处理器, 模拟IP(Intellectual Property)核, 数字IP核和存储器(或片外存储控制接口)集成在单一芯片上, 它通常是客户定制的, 或是面向特定用途的标准产品.

中间件

消息中间件

消息中间件用在两个应用程序之间或分布式系统中发送消息, 进行异步通信. 消息中间件支持点对点模式, 发布订阅模式, 推拉模式.

消息队列是在消息的传输过程中保存消息的容器.

消息队列负责在两个系统之间传递消息, 这两个系统可以是异构的, 位于不同硬件, 不同操作系统, 用不同语言编写的两个应用程序之间, 只需调用MQ的API就可以相互通信, 不必考虑底层系统和网络的复杂性, MQ能够应付多种异常情况.

中间件(简单)

在分布式系统中, 中间件通常提供两种不同类型的支持, 即交互支持和提供公共服务.

中间件是独立的系统级软件, 连接操作系统层和应用程序层. 中间件将不同操作系统和应用提供的接口标准化, 协议统一化, 屏蔽了具体操作的细节.

中间件一般提供如下功能:

1. 通信支持: 即交互支持, 屏蔽底层通信之间的接口差异, 实现互操作.
2. 应用支持: 为应用层不同服务之间提供互操作机制.
3. 公共服务: 将应用软件中共性功能或约束提取出来, 形成公共服务.

中间件(详细)

中间件是一种独立的系统软件或服务程序, 中间件位于操作系统之上, 管理计算资源和网络通信, 实现应用之间的操作, 中间件的基本功能有以下六个方面:

1. 负责客户端与服务器之间的连接和通信, 客户机与应用层之间的高效率通信机制.
2. 提供应用层不同服务之间的互操作机制, 应用层与数据库之间的连接和控制机制.
3. 提供一个多层架构的应用开发和运行的平台, 一个应用开发框架, 支持模块化的应用开发.
4. 屏蔽硬件, 操作系统, 网络和数据库的差异.
5. 提供应用的负载均衡和高可用性, 安全机制与管理功能, 以及交易管理机制, 保证交易的一致性.
6. 提供一组通用的服务去执行不同的功能, 避免重复的工作和使应用之间可以协作.

电子邮件协议

POP3为邮件接收协议, 缺省端口为110

SMTP为邮件发送协议, 缺省端口为25

IMAP为交互式邮件存取协议, 缺省端口为143

数据资产的特征

数据资产的特征有: 可增值或贬值, 可共享, 可控制, 可量化, 可变现等.

DCMM数据管理能力成熟度评估模型

数据管理能力成熟度评估模型(DCMM)是我国首个数据管理领域的国家标准, 提出了符合我国企业的数据管理框架, 该框架将组织数据管理能力划分为8个能力域:

数据战略, 数据治理, 数据架构, 数据应用, 数据安全, 数据质量, 数据标准, 数据生存周期.

安全攸关系统

安全攸关系统在软件需求分析阶段, 应提出安全性需求. 软件安全性需求是指通过约束软件的行为, 使其不会出现不可接受的违反系统安全的行为.

软件安全需求的获取是根据已知的系统信息, 如软件危害条件以及其他一些类似的系统数据和通用惯例, 完成通用软件安全性需求的裁剪和特定软件安全性需求的获取工作.

信息安全系统

一个完整的信息安全系统至少包含三类措施:

1. 技术方面的安全措施
2. 管理方面的安全措施
3. 相应的政策法律

信息安全的技术措施主要有: 信息加密, 数据签名, 数据完整性保护, 身份鉴别, 访问控制, 数据备份和灾难恢复, 网络控制技术, 反病毒技术, 安全审计等.

信息安全要素

信息安全包括的要素:

1. 机密性: 确保信息不泄露给未授权的实体或进程
2. 完整性: 只有得到允许的人才能修改数据, 并且能够判别出数据是否已被篡改
3. 可用性: 得到授权的实体在需要时可以访问数据, 即攻击者不能占用所有的资源而阻碍授权者的访问
4. 可控制: 可以控制授权范围内的信息流向及行为方式
5. 可审查性: 可为网络完全问题提供调查的依据和手段

信息安全的网络安全威胁

信息系统面临多种类型的网络完全威胁, 其中

信息泄露是指信息被泄露或透露给某个非授权的实体.

破坏信息的完整性是指数据被非授权地进行增删修改或破坏而受到损失.

拒绝服务是指对信息或其他资源的合法访问被无条件地阻止, 是由攻击者向服务器发送大量垃圾信息或干扰信息的方式, 导致服务器无法向正常用户提供服务.

业务流分析是通过对系统进行长期监听, 利用统计分析方法对诸如通信频度, 通信的信息流向, 通信总量的变化等参数进行研究, 从而发现有价值的信息和规律.

信息工程

实体和对象

信息工程方法中的实体描述的是数据以及该数据的相关属性.

面向对象方法中的类是数据和行为的封装体.

用户用例

Essential Use Cases和Real Use Cases是按照开发阶段来进行划分的.

Essential Use Cases是在面向对象分析阶段使用的; 而Real Use Cases是在面向对象设计阶段实现的.

Essential Use Cases描述的是用例的本质属性, 它与如何实现这个用例无关, 独立于实现该用例的软硬件技术; 而Real Use Cases描述的是用例的实现方式, 表达了设计和实现该用例是所采用的方法和技术.

增量式开发

增量式开发相比于瀑布模型, 降低了适应用户需求变更的成本, 重新分析和修改文档的工作量要少很多, 在开发过程中更容易得到用户对于已做的开发工作的反馈意见, 用户可以更早地使用软件并创造商业价值.

CMMI能力成熟度模型集成

建立基于CMMI的软件质量管理体系文件, 体系文件的层次结构一般分为四层, 按照自顶向下的塔型排列:

顶层方针, 过程文件, 规程文件, 模板类文件.

CMMI评估

CMMI评估分为五个等级, 自低向高分别为:

1. 初始级: 软件过程是无序的, 有时甚至是混乱的, 对过程几乎没有定义, 成功取决于个人努力, 管理是反应式的.
2. 已管理级: 建立了基本的项目管理过程来跟踪费用, 进度和功能特性, 制定了必要的过程纪律, 能重复早先类似应用项目取得的成功经验.
3. 已定义级: 已将软件管理和工程两方面的过程文档化, 标准化, 并综合成该组织的标准, 软件过程, 所有项目均使用经批准, 剪裁的标准软件过程来开发和维护软件, 软件产品的生成在整个软件过程中是可见的.
4. 定量管理级: 分析对软件过程和产品质量的详细度量数据, 对软件过程和产品都有定量的理解和控制.
5. 优化级: 过程的量化反馈和先进的新思想, 新技术促使过程持续不断改进.

企业数据化转型的发展阶段

企业数字化转型的五个发展阶段是:

1. 初始级: 主要特征是数码化
2. 单元级: 主要特征是数据化
3. 流程级: 主要特征是数字化
4. 网络级: 主要特征是数模化
5. 生态级: 主要特征为数用化

组织信息化需求

组织信息化需求通常包含三个层次: 战略需求, 运作需求, 技术需求.

组织信息化的目标是提升组织的竞争能力, 为组织的可持续发展提供一个支持环境, 因此组织信息化也是组织的战略需求.

组织战略是通过组织的运作来完成的, 因此组织信息化也是组织运作的需求.

组织运作需要技术的支持, 而信息化技术在管理中处于核心地位, 因此组织信息化也是组织的技术需求.

各种图的功能

业务流程图(TFD)是分析和描述现有系统的传统工具, 是业务流程调查结果的图形化表示.

实体联系图(E-R图)是信息建模的工具.

数据流图(DFD)是表达系统内数据的流动并通过数据流描述系统功能的一种方法.

数据字典(DD)是在DFD的基础上, 对DFD中出现的所有命名元素都加以定义, 使得每个图形元素的名字都有一个确切的解释.

活动图用于描述系统的工作流程和并发行为, 可看作状态图的特殊形式.

BPMN(Business Process Modeling Notation)是BPM及Work Flow的建模语言标准之一, 主要目标是提供一套可被所有业务用户理解的标记语言.

Petri-Net是对离散并行系统的数学表示, 是所有流程定义语言的基础.

用例图是静态图的一种, 主要用于表示用户及用户相关的用例之间的关系.

PAD图即问题分析图, 用二维树型结构来表示程序的控制流, 将这种图翻译成程序代码比较容易, 常用作面向过程的软件开发中详细设计的工具.

数据流图和系统流程图

数据流图和系统流程图的区别:

1. 数据流图中的处理过程可并行; 系统流程图在某个时间点只能处于一个处理过程.
2. 数据流图展现系统的数据流; 系统流程图展现系统的控制流.
3. 数据流图展现全局的处理过程, 过程之间遵循不同的计时标准; 系统流程图中处理过程遵循一致的计时标准.

开发阶段和图

需求分析阶段: 数据流图

概要设计阶段: 模块结构图, 层次图和HIPO图

详细设计阶段: 程序流程图, PAD图, 伪代码和盒图

面向对象

开发模型

使用面向对象开发软件, 通常需要建立对象模型, 动态模型和功能模型.

对象模型描述系统中对象的静态结构, 对象之间的关系, 属性和操作, 主要用对象图来实现.

动态模型描述与时间和操作顺序相关的系统特征, 主要用顺序图, 状态图, 活动图, 通信图来实现.

功能模型侧重于描述系统的功能, 即系统如何从输入得到输出, 不考虑具体的实现, 主要用DFD来实现.

对象模型是动态模型和功能模型的基础, 功能模型偏向于描述发生了什么, 动态模型偏向于描述什么时候发生的, 对象模型偏向于描述发生的客体.

三个模型均可用于需求分析.

对象重用

为实现对象重用, COM支持两种形式的对象组装: 包含和聚集.

包含是一种简单的对象组装技术, 含义是一个对象拥有指向另一个对象的唯一引用, 当客户发起调用内部对象的请求时, 需通过外部对象把该请求转发给内部对象.

聚集则是把内部对象接口的引用传递给外部对象并由外部对象把这些接口暴露给客户, 当客户需要调用内部对象时, 直接调用外部对象暴露出来的那些属于内部对象的接口即可, 从而无须外部对象转发该调用请求.

需求

需求抽取(获取)通常为一个迭代过程, 其中的活动包括: 需求发现, 需求分类和组织, 需求协商, 需求文档化.

需求管理

需求管理的主要活动有: 变更控制, 版本控制, 需求跟踪, 需求状态跟踪.

需求跟踪的目的是建立与维护需求-设计-编程-测试之间的一致性, 以确保所有的工作成功符合用户需求.

因此需求跟踪应编制每个需求与系统元素之间的联系文档, 这些元素包括其他需求, 体系结构, 设计部件, 源代码模块, 测试, 帮助文件和文档等.

文档管理不属于需求管理的主要活动.

变更控制

变更控制委员会可以由一个小组担任, 也可以由多个不同的小组担任.

控制需求变更与项目的其他配置管理决策有着密切的联系.

变更控制过程中可以使用相应的自动辅助工具.

变更的过程中, 允许拒绝变更.

软件建模

按抽象层次的不同, 软件建模由高到低分为三个层次: 1. 计算无关模型(CIM) 2.平台无关模型(PIM) 3.平台相关模型(PSM). 其中平台无关模型(PIM)在不涉及实现的情况下对软件系统进行建模.

使用模型驱动的软件开发方法, 软件系统被表示为一组可以被自动转换为可执行代码的模型. 其中平台无关模型在不涉及实现的情况下对软件系统进行建模.

软件配置管理工具

软件配置管理工具是指支持完成配置项标识, 版本控制, 变更控制, 访问控制, 安全控制等任务的工具.

在软件开发和维护过程中, 一个软件会有多个版本, 版本控制工具用来存储, 更新, 恢复, 和管理一个软件的多个版本.

传统的软件生命周期方法学

传统的软件生命周期方法学把软件生命周期划分为: 软件定义, 软件开发, 软件运行, 软件维护四个阶段.

传统的软件生命周期是指软件产品从形成概念(构思)开始, 经过定义, 开发, 使用和维护, 直到最后被废弃(不能再使用)为止的全过程.

可行性研究属于软件定义阶段的主要任务.

RUP软件开发生命周期

RUP(Rational Unified Process)软件开发生命周期是一个二维的软件开发模型, 在横向上把软件开发划分为四个阶段: 初始, 精化, 构建, 移交. 在纵向上把软件开发划分为九个核心工作流: 业务建模, 需求, 分析与设计, 实现, 测试, 部署, 配置与变更管理, 项目管理, 环境.

UML

从UML2.0开始, 整个UML规范被划分为基础结构和上层结构两个相对独立的部分. 基础结构是UML的元模型, 定义了构造UML模型的各种基本元素. 上层结构则定义了面向建模用户的各种UML模型的语法, 语义和表示.

UML2.0四部分需求: 基础结构, 上层结构, 对象约束语言, 图交换.

基础结构的设计目标是定义一个元语言的核心, 通过对此核心的复用, 可以定义一个自展的UML元模型以及其他元模型, 包括元对象设施和公共仓库模型.

上层结构的设计目标是严格地复用基础结构中的构造物, 提高对基于构件开发和模型驱动体系结构的支持, 优化架构规约的能力, 增强行为图的可伸缩性, 精确性, 集成性等.

UML2.0中, 顺序图用来描述对象之间的消息交互, 其中循环, 选择等复杂交互使用序列片段表示. 对象之间的消息类型包括: 简单消息, 同步消息, 异步消息, 参与者创建消息, 参与者销毁消息, 无触发对象和无接收对象的消息.

UML的模型图

UML图分为两大类: 结构行为图和动态行为图.

结构行为图

类图: 描述系统中类的静态结构

对象图: 系统中的多个对象在某一时刻的状态

组件图: 一种特殊的UML图来描述系统的静态实现视图

部署图: 定义系统中软硬件的物理体系结构

用例图: 从用户角度描述系统功能

动态行为图

序列图(顺序图): 对象之间的动态合作关系, 强调对象发送消息的顺序, 同时显示对象之间的交互.

协作图: 描述对象之间的协助关系

状态图: 描述状态到状态控制流, 常用于动态特性建模

活动图: 描述业务实现用例的工作流程

序列图(顺序图)强调消息交互的时间顺序, 而协作图强调接收和发送消息的对象的组织结构及通信方式.

领域驱动设计

领域驱动设计提出围绕领域模型进行软件设计和开发, 该模型是由开发人员与领域专家协作构建出的一个反映深层次领域知识的模型.

领域驱动设计分为两个阶段:

1. 以一种领域专家, 设计人员, 开发人员都能理解的通用语言作为相互交流的工具, 在交流的过程中发现领域概念, 然后将这些概念设计成一个领域模型.
2. 由领域模型驱动软件设计, 用代码来实现该领域模型.

领域驱动设计的核心是建立正确的领域模型.

面向服务架构和微服务架构

面向服务架构(SOA)是中心化的集成架构, ESB(企业服务总线)是SOA架构的中心.

企业服务总线(ESB)是构建基于SOA解决方案时说使用基础架构的关键部分, 是由中间件技术实现并支持SOA的一组基础架构功能.

在SOA分层模型中, ESB用于组件层以及服务层之间, 能够通过多种通信协议连接并集成不同平台上的组件并将其映射成服务层的服务.

微服务架构旨在通过将一个中心化的集成服务分解为相对独立的微小服务, 以实现去中心化, 快速复用等目标.

概念

面向服务的体系架构(SOA)是一种粗粒度, 松耦合的服务架构, 服务之间通过简单, 精确定义接口进行通信.

可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署, 组合和使用.

SOA能帮助企业系统架构设计者以更迅速, 更可靠, 更高重用性设计整个业务系统架构, 基于SOA的系统能够更加从容地面对业务的急剧变化.

企业服务总线(ESB)是由中间件技术实现的全面支持面向服务架构的基础软件平台, 支持异构环境中的服务以及基于消息和事件驱动模式的交互, 并且具有适当的服务质量和可管理性.

安全问题

SOA环境中, 需要解决的安全问题包括:

1. 机密性: 又称保密性, 是指非法非授权用户访问数据, 导致数据机密泄露. 在传输层和消息层对机密性的需求是不同的, 可以依靠数据加密来保证数据机密性.
2. 完整性: 指数据的正确性, 一致性和相容性. 保证数据的完整性可通数字签名来实现.
3. 可审计性: 审计是一种事后监视的措施, 跟踪系统的访问活动, 发现非法访问, 达到安全防范的目的. 不同的系统可能需要不同的审计等级.
4. 认证管理: 指的是服务器请求者和服务提供者两者在服务调用的时候互相认证对方的身份, 防止非授权非法实体来获取服务, 是系统安全的第一道安全屏障.
5. 授权管理: 授权管理的目的是阻止Web服务的未授权使用.
6. 身份管理: 在SOA架构中, 身份管理和传统系统中的身份管理比较相像. 服务请求者和服务提供者两者的身份对两者来说是至关重要的, 否则就会存在非法用户在服务请求者和服务提供者之间进行消息传递, 太容易导致数据的泄密和篡改.

为了保障系统的安全性, 开采用XML加密模块, WS-Security, 防火墙系统, 安全检测, 网络扫描等安全性策略.

构件

构件的三大特征: 独立性(可独立部署), 复用性(可作为第三方组装单元), 无外部可见的状态(确保第三方可用, 但不能知道它是如何实现的).

构件作为一个可独立部署的单元, 具有原子性, 是不可拆分的. 在UML2.0中, 构件是一种类.

构件的定义中: 接口是一个已命名的一组操作的集合, 每个操作可完成某种特定的功能, 可通过接口的名称来调用接口. 构件中的接口分为供接口和需接口两种, 构件通过供接口向服务对象提供自己的功能, 通过需接口来请求所需调用的功能.

构件本质上是软件, 因此安装, 开发, 升级时都具有一般软件的特征, 比如安装时可能与现有的系统不兼容, 也具有一般软件产品所具有的演化过程等, 安装新版本的构件不一定要终止系统中所有旧版本构件的运行. 解决遗留系统移植问题时, 还需要通过使用包裹器构件来适配旧版本软件.

构件分类

从构件的外部形态来看, 构成一个系统的构件可分为5类:

1. 独立而成熟的构件: 独立而成熟的构件得到了实际运行环境的多次检验 该类构件隐藏了所有接口, 用户只需用规定好的命令进行使用.
2. 有限制的构件: 有限制的构件提高了接口, 指出了使用的条件和前提, 这种构件装配时, 会产生资源冲突, 覆盖等影响, 在使用时需要加以测试.
3. 适应性构件: 适应性构件进行了包装或使用了接口技术, 处理了不兼容性, 资源冲突等, 可以直接使用, 这种构件可不加修改地使用在各种环境中.
4. 装配的构件: 装配的构件在安装时, 已经装配在操作系统, 数据库管理系统或信息系统不同层次上, 使用胶水代码就可以进行连接使用. 目前一些软件商提供的大多数软件都属于这一类.
5. 可修改的构件: 可修改的构件可以进行版本替换, 如果对原构件修改错误, 增加新功能, 可以利用重新包装或写接口来实现构件的替换, 这种构件在应用系统开发中使用的比较多.

构件分类方法

1. 关键字分类法: 根据领域分析的结果将应用领域的概念按照从抽象到具体的顺序逐次分解为树型或有向无回路图结构.
2. 刻面分类法: 利用Facet(刻面)描述构件执行的功能, 被操作的数据, 构件应用的语境或任意其他特征.
3. 超文本方法: 基于全文检索技术, 使得检索者在阅读文档过程中可以按照人类的联想思维方式任意跳转到包含相关概念或构件的文档.

构件组装技术

构件组装是将库中的构件经适当修改后相互连接, 或者将它们与当前开发项目中的软件元素相连接, 最终构成新的目标软件.

构件组装技术大致有:

1. 基于功能的组装技术
2. 基于数据的组装技术
3. 面向对象的组装技术

构件组装的三个层次

定制, 集成和扩展, 分别对应于构件组装过程中的不同任务.

基于构件的软件过程

基于构件的软件过程划分为结构需求, 设计, 文档化, 复审, 实现, 演化六个子过程.

结构文档化过程的主要输出结果是结构需求规格说明, 测试结构需求的质量设计说明书.

CORBA服务端构件模型

在CORBA服务端构件模型中, 伺服对象(Servant)是CORBA对象的真正实现, 负责完成客户端请求.

一个POA实例通过将收到的请求传递给一个伺服对象(Servant)来对其进行处理, 伺服对象是CORBA对象的实现, 负责完成客户端请求.

服务端构件模型的解决方案

服务端构件模型的解决方案中, 应用服务器是介入Web服务器与数据库服务器之间的服务器, 主要用于处理从Web服务器接收的请求.

EJB是企业级Java应用容器, 主要用于应用服务器.

COM+是微软公司的应用容器, 也主要用于应用服务器.

ASP, JSP, PHP, Servlet是Web服务器的技术.

软件源码复杂度

度量软件源码复杂度的方法主要有三种:

1. 代码行法: 用代码的行数来度量源码复杂性, 是最简单的度量方法.
2. Helstead法: 根据程序中可执行代码行的操作符和操作数的数量来度量复杂性.
3. McCabe法: 用代码中环路数来度量复杂性.

McCabe法

McCabe度量法是用程序图中环路的个数来度量程序复杂度, 计算图G中环形复杂度的方法有两种:

1. V(G) = m - n + 2 m是有向弧个数(有箭头的), n是节点个数(包含开始和结束)
2. 闭合区域的个数+1

5G网络

5G网络的切片技术是指将5G网络逻辑分割成多个虚拟网络, 每个虚拟网络可支持不同的应用场景, 从而可以使得5G技术可支持更多类型的应用.

每个虚拟网络之间, 包括网络内的设备, 接入, 传输和核心网, 都是逻辑独立的, 任何一个虚拟网络发送故障都不会影响到其他虚拟网络. 一个5G网络至少可以分为无线网子切片, 承载网子切片, 核心网子切片三个部分.

Wi-Fi认证方式

常见的Wi-Fi认证方式有: WEP, WPA/WPA2, WPA-PSK/WPA2-PSK, 安全性依次递增.

WEP认证可提供等同于有线局域网的保护能力, 采用RSA加密算法.

WPA认证使用TKIP加密算法, WPA2认证使用AES加密算法替代了TKIP, 安全性更高.

WPA-PSK/WPA2-PSK认证是WPA/WPA2认证+PSK认证算法.

随机数近似计算

题目一

题目: 计算机产生的随机数大体上能在(0, 1)区间上均匀分布. 假设某初等函数f(x), 当其自变量在(0, 1)区间内取值时, 其值域也在(0, 1)区间内, 由计算机产生大量的M个随机数对(r1, r2)中, 符合r2 小于等于 f(r1)条件的有N个, 那么N/M可作为?的近似计算结果.

答案: 随机数在(0, 1)区间均匀分布, 因此所有随机数对(r1, r2)的集合M可视为坐标(0, 0), (0, 1), (1, 0), (1, 1)四个坐标组成的正方形的面积.

满足r2 小于等于 f(r1)的条件的M集合中的数量为N个, 因此N可以视为正方形中位于函数f(x)下面的面积, 而这恰好是函数f(x)在区间(0, 1)上定积分的集合含义.

题目二

题目: 为近似计算XYZ三维空间内由三个圆柱$x^2+y^2 \le 1$, $y^2+z^2 \le 1$, $x^2+z^2 \le 1$相交部分V的体积, 如何最容易理解, 最容易编程实现.

答案: V位于某正方体M内, 利用M内均匀分布的随机点落在V中比例进行计算.

在计算机上利用伪随机数, 很容易取得正立方体(x, y, z)在区间[-1, 1]内均匀分布的随机点, 也很容易判断该点是否位于V内. 对于大量的随机点, 很容易统计在该正立方体中随机点位于V中的比例, 该比例指的8倍就近似 地等于V的体积.

故障检测和诊断技术

心跳检测技术是指阶段以固定频率向其他节点发送心跳信息, 表示自己是存活的, 如果在规定的时间内其他节点没有收到来自某节点的心跳, 就认定该节点已失效, 其资源和服务就会被接管. 心跳检测技术的优点是可以快速反应, 缺点是容易产生误判.

超时探测技术是节点主动向被探测节点发出ping信号, 被探测节点在收到ping信号后回复一个echo信号, 表示自己的健康状态良好, 还可以附加一些状态信息. 如果在预定的时间之后未收到echo信号, 则判断被探测节点失效. 超时探测技术的特点是可以获得更详细的探测结果, 但需主动进行探测.

数据访问

标准的数据访问机制提供了不同标准间数据访问机制, 屏蔽了不同通信协议之间的差异, 为上层应用程序提供统一的访问接口, 可以容易地实现应用程序对不同总线协议设备的互操作, 使得从底层的开发中脱离出来.

标准的数据访问机制独立于平台, 确保来自多个厂商的设备之间的信息无缝传输, 具有语言无关性, 代码重用性, 易于集成性等优点.

当硬件升级或修改时只需改动硬件接口部分即可, 不会影响上层应用程序.

数据驱动

数据驱动方法是一种问题求解方法, 它从初始的数据或观测值触发, 运用启发式规则, 寻找和建立内部特征之间的关系, 从而发现一些规律或结论.

分布式架构的故障检测和诊断需要综合多种故障信息和系统状态, 依据智能决策数据库的决策策略判定, 如果采用预先定制的解析模型, 这个模型可能会非常复杂, 而采用数据驱动方法能通过已有的数据去训练模型, 可以达到逐渐精细化, 并兼容未来的变化.

数据仓库

数据仓库的四大特点:

1. 面向主题: 数据按主题组织
2. 集成性: 消除了源数据的不一致性, 提供整个企业的一致性全局信息
3. 相对稳定性: 主要进行查询操作, 只有少量的修改和删除操作(或无删除)
4. 反映历史变化: 记录了从过去某一时刻当前各个阶段的信息, 可对发展历程和未来趋势做定量分析和预测

数据查询效率判断

给出关系运算查询表达式, 按照表达式顺序执行, 则查询效率最高的判断依据原则是:

如果存在连接操作与选择操作, 则应尽可能早地完成选择操作, 这样能降低参与连接操作地数据量, 极大地提升运算速度.

数据库和缓存更新

同步更新

只有缓存和数据库中的数据同时完成更新后事务才算提交成功.

异步更新

更新数据时, 在同一事务内通过消息队列发布待更新数据的消息, 缓存通过订阅消息队列异步更新, 但数据库采用同步更新.

缓存穿透

缓存穿透是指缓存和数据库中都没有的数据, 而用户或攻击者不断发起请求会导致缓存数据库压力过大.

常见策略:

1. 接口层增加校验, 如用户鉴权校验, 键校验.
2. 缩短无效键有效时间, 以防止攻击用户的暴力攻击.

缓存雪崩

缓存雪崩是指缓存中的数据大批量到过期时间, 而查询数量巨大, 引起数据库压力过大甚至宕机.

常见策略:

1. 缓存数据的过期时间随机设置, 防止同一时间有大量数据过期的现象发生.
2. 在分布式缓存数据库部署条件下, 将热点数据均匀分布在不同的缓存数据库中.
3. 热点数据设置为永不过期.

哈希算法和一致性哈希

哈希算法是把任意长的输入通过某种哈希算法变换成固定长度的一个哈希值, 可把该哈希值作为该片缓存的位置信息, 不同的输入可能会哈希出相同的结果, 所以不能由哈希值来确定唯一的输入值.

一致性哈希算法是一种特殊的哈希算法, 将整个哈希值空间映射成一个按顺时针方向组织的虚拟圆环. 使用哈希算法算出数据哈希值, 然后根据哈希值的位置沿着圆环顺时针查找, 将数据分配到第一个遇到的集群节点进行缓存.

一致性哈希能尽可能小地改变已存在的服务请求与处理请求服务器之间的映射关系, 解决了简单哈希算法在分布式哈希表中存在的动态伸缩问题. 有两大优点: 1.可扩展性 2.更好地适应数据的快速增长.

布隆过滤器

布隆过滤器的原理是: 当一个元素被加入集合时, 通过K个散列函数将这个元素映射成一个位数组中的K个点, 把它们置为1. 检索时, 只要看看这些点是不是都是1就大概可知道集合中有没有该数据. 如果这些点有任何一位为0, 则被检元素一定不在, 如果都是1, 则被检元素很可能存在.

其优点有:

1. 占用内存小
2. 增加和查找元素的时间复杂度为O(K), K为哈希函数的个数, 一般比较小, 与数据量大小无关
3. 哈希函数之间没有关系, 方便硬件并行运算
4. 布隆过滤器不需要存储元素本身, 在某些对保密要求比较严格的场合中有很大优势

其缺点有:

1. 有误判率
2. 不能获取元素本身
3. 一般情况下不能从布隆过滤器中删除元素

MQTT协议

MQTT即消息队列遥测传输协议, 是一个专门针对物联网开发的轻量级传输协议, 旨在为位于不稳定的网络环境中的低算能, 低带宽的边缘物联网设备提供可靠的网络服务.

MQTT协议针对低带宽, 低计算能力的网络设备做了比较特殊的优化, 使得其能适应物联网数据传输场景.

边缘计算模型

传统云计算模型中引入边缘计算模型的优势主要包括:

1. 数据通信方面: 很多计算在边缘数据中心或边缘设备本身进行处理, 数据无需传输回中央服务器, 可极大减小网络负载.
2. 安全方面: 边缘计算将在不同的数据中心和设备之间分配数据处理工作, 黑客无法通过攻击一台设备来影响整个网络.
3. 系统性能方面: 由于很多功能直接由边缘设备完成而不需依赖于中央服务器, 因此系统性能更高. 如人脸识别就只需要边缘设备本身进行, 不依赖于远程服务器的算力.

数字证书

数字证书可证明某网站是某网站, 但数字证书可能是家的, 可通过数字证书的颁发机构(CA)根据数字证书上的CA签名来鉴别数字证书的真伪.

某Web网站向CA申请了数字证书, 用户登录过程中可通过验证CA签名确认该数字证书的有效性, 以验证网站的真伪.

线性规划问题

非负变量x和y, 在x<=4, y<=3和x+2y<=8的约束条件下, 目标函数2x+3y的最大值为: 14.

解: 通过画坐标系, 得知约束条件下的所限定的范围.

设置2x+3y=k, 于是有y = -2x/3 + k/3则该直线过点(4,2)时, 纵截距(即x=0时y的值)最大, 即k/3最大, 也即k最大, 将(4, 2)待入2x+3y=k, 可得最大值14.

三点估算期望时间法

作业的期望时间 = (乐观时间 + 4 * 最可能时间 + 保守时间) / 6

任务安排

某企业准备将甲乙丙丁分配在ABCD四个岗位, 每个工人的技术水平不同, 在不同岗位每天完成任务所需的工时如下表:

	A	B	C	D
甲	7	5	2	3
乙	9	4	3	7
丙	5	4	7	5
丁	4	6	5	6

合理安排岗位, 可以让四个工人在最短的总工时___内完成每天的任务.

解法:

表中的数字构成一个矩阵, 分配岗位实际上就是在这个矩阵中每行每列只取一个数, 使四个数之和最小.

因此: 如果同一行或同一列上各数都加或减一个常数, 那最优解的位置不变, 最优的值也加或减这个常数.

步骤1: 将矩阵的第1, 2, 3, 4行分别减2, 3, 4, 4(每行的最小值), 得到:

	A	B	C	D
甲	5	3	0	1
乙	6	1	0	4
丙	1	0	3	1
丁	0	2	1	2

步骤2: 看到第四行(D列)还能减1, 于是得到:

	A	B	C	D
甲	5	3	0	0
乙	6	1	0	3
丙	1	0	3	0
丁	0	2	1	1

于是得到分配方案: A岗位分配给丁, B岗位分配给丙, D岗位分配给甲, C岗位分配给乙.

于是总工时为(步骤1和2减去的常数相加): 2 + 3 + 4 + 4 + 1 = 14.

区块链

挖矿

挖矿是指利用电脑硬件计算出比特币的位置并获取的过程. 简单来说, 挖矿就是一个记账的过程, 矿工是记账员, 区块链就是账本. 每隔一个时间点, 通过哈希算法, 将过去一段时间内未经比特币全网认可的交易信息收集, 整理, 对全网所有节点进行广播, 最终被所有节点承认并得到比特币的过程.

比特币系统会在系统节点上生成一个随机代码, 互联网中的所有计算机都可以去寻找此代码, 谁找到此代码. 就会产生一个区块, 随即得到一个比特币, 这个过程是人们常说的挖矿.

计算这个随机代码需要大量的GPU运算, 于是矿工们采购海量显卡用以更快速地获得比特币获利. 同时挖矿是发行新币的唯一方式, 对于发行新币, 维系比特币支付功能, 保证系统安全, 有着举足轻重地影响.

挖矿本身并不能防止双花(同一笔数字资产因不当操作被重复使用的情况)攻击.

由于挖矿越来越难, 耗电量越来越大, 我国已明文禁止.

电子政务

与电子政务相关的行为主体有三类: 政府, 企(事)业单位, 居民.

按照政府, 居民, 企业三种主体之间的相互关系, 可将电子政务分为:

1. G2G是政府与政府之间的电子政务, 即上下级政府, 不同地方政府和不同政府部门之间实现的电子政务活动.
2. G2C是政府通过电子网络系统为居民提供各种服务.
3. C2G是居民对政府的活动, 包括个人应向政府缴纳的各种税款和费用, 按政府要求填写的各种信息和表格, 缴纳罚款, 更重要的是开辟居民参政, 议政的渠道. 报警服务也属于这个范围.
4. G2B是政府与企业之间的电子政务, 也是G2G和G2C电子政务模式的集成. G2B电子政务主要是利用网络建立起有效的行政办公和企业管理体系, 以提高政府工作效率.
5. B2G是企业对政府的电子政务体系, 主要是企业从政府获得订单合同, 其实际应用为政府电子采购.

人口信息采集, 处理和利用业务是G2G领域; 营业执照的颁发业务属于G2B领域; 户籍管理业务属于G2C领域; 参加政府工程投标活动属于B2G领域.

Kerberos认证

Kerberos是一个用于鉴定身份的协议, 采取对称密钥加密, 密钥不会在网络中传输. 在Kerberos中, 未加密的密码不会在网络上传输, 因此攻击者无法通过嗅探网络来偷取用户的密码.

Kerberos协议有三种角色:

1. 客户端: 发送请求的一方
2. 服务端: 接收请求的一方
3. 密钥分发中心(KDC): 密钥分发中心分为两个部分, 分别是:
   1. 认证服务器(AS): 专门用来认证客户端的身份并发放客户端用于访问TGS的TGT(票据授予票据)
   2. 票据授予服务器(TGS): 用来发放整个认证过程以及客户端访问服务端时所需的服务授权票据.

认证流程:

1. 客户端向KDC请求获取想要访问的目标服务端的服务授予票据
2. 客户端拿着从KDC获取的服务授予票据访问相应的网络服务

Redis缓存

RDB和AOF

RDB与AOF相比, 具备以下特点:

1. 磁盘更新频率: RDB更新频率比AOF低.
2. 数据安全: AOF可以保证数据不丢失, 比RDB更安全.
3. 数据一致性: RDB隔一段时间存储, 可能发生数据丢失和不一致, AOP通过append模式写文件, 即使发生服务器宕机, 也可通过redis-check-aof工具解决数据一致性问题.
4. 重启性能: RDB比AOF高
5. 数据文件大小: RDB文件比AOF小

RDB持久化是在指定的时间间隔内将内存中的数据集快照写入磁盘, 优点如下:

1. 体积更小: RDB文件紧凑, 全量备份, 非常适合用于进行备份和灾难恢复.
2. 性能更高: 生成RDB文件的时候, Redis主进程会fork一个子进程来处理所有保存工作, 主进程不需要进行任何磁盘IO操作.
3. 恢复更快: RDB在恢复大数据集时的速度比AOF的恢复速度更快.

缺点: 1.可能丢失数据 2.耐久性差

AOF是Redis将每一个命令都通过write函数追加到文件中, 通俗理解是日志记录. 优点有:

1. AOF可以更好地保护数据不丢失, 一般AOF会每隔一秒, 通过一个后台线程执行一次fsync操作, 最多丢失1秒的数据.
2. AOF日志文件没有任何磁盘寻址的开销, 写入性能非常高, 文件不容易破损.
3. AOF日志文件即使过大的时候, 出现后台重写操作, 也不会影响客户端的读写.
4. 日志文件的命令通过非常可读的方式进行记录, 这个特性非常适合做灾难性的误删除的紧急恢复.

缺点: 1. AOF日志文件比RDB快照文件更大 2.性能上AOF比RDB低 3.数据恢复时无法一模一样地恢复出来.

内存淘汰机制

Redis的内存淘汰机制:

1. volatile-lru: 针对设置了过期时间的key, 使用lru(最近很少使用)算法进行淘汰.
2. allkeys-lru: 针对所有的key使用lru(最近很少使用)算法进行淘汰.
3. volatile-lfu: 针对设置了过期时间的key, 使用lfu(最不经常使用)算法进行淘汰.
4. allkeys-lfu: 针对所有的key使用lfu(最不经常使用)算法进行淘汰.
5. volatile-random: 针对设置了过期时间的key, 使用随机淘汰的方式
6. allkeys-random: 针对所有的key, 使用随机淘汰的方式
7. volatile-ttl: 针对设置了过期时间的key, 越早过期的越先被淘汰.
8. noeviction: 不会淘汰任何数据, 当使用的内存空间超过最大内存时, 再有写请求时返回错误.

分布式存储

Redis分布式存储的常见方案:

1. 主从模型
2. 哨兵模式
3. 集群模式

集群切片

Redis集群切片的常见方式有:

1. 客户端实现分片: 分区逻辑在客户端实现, 采用一致性哈希来决定Redis节点.
2. 中间件实现分片: 在应用软件和Redis中间, 例如TwemProxy, Codis等, 由中间件实现服务到后台Redis节点的路由分派.
3. 客户端服务端协作分片: Redis Cluster模式, 客户端可采用一致性哈希, 服务端提供错误节点的重定向服务.

电子邮箱安全

安全套接字(SSL)及其传输层安全(TLS)是为网络通信提供安全及数据完整性的一种安全协议, 在传输层对网络连接进行加密, 在设置电子邮箱时使用SSL协议, 会包装邮箱更安全.

HTTPS协议是由HTTP加上TLS/SSL协议构建的可进行加密传输, 身份认证的网络协议, 主要通过数字证书, 加密算法, 非对称密钥等技术完成互联网数据传输加密, 实现互联网传输安全保护.

MIME是设定某种扩展名的文件用一种应用程序来打开的方式类型, 当该扩展名文件被访问的时候, 浏览器会自动使用指定应用程序来打开, 是一个互联网标准, 扩展了电子邮件标准, 使其支持更丰富的类型.

PGP是一套用于消息加密, 验证的应用程序, 采用IDEA的散列算法作为加密与验证之用. PGP加密由一系列散列, 数据压缩, 对称密钥加密, 以及公钥加密的算法组合而成. 每个公钥均绑定唯一的用户名或者Email地址.

网络冗余设计

网络冗余设计的目的是避免网络组件单点失效造成应用失效.

备用路径是在主路径失效时启用, 其和主路径承担不同的网络负载.

负载分担时网络冗余设计的一种设计方式, 其通过并行链路提供流量分担来提高性能.

网络中存在备用链路时, 可以考虑加入负载分担设计来减轻主路径负担.

数学模型

数学模型常常带有多个参数, 而参数会随环境因素而变化. 根据数据模型求出最优解或者满意解后, 还需要进行灵敏性分析, 对计算结果进行检验, 分析计算结果对参数变化的反应程度.

如果对于参数的微小变化引发计算结果的很大变化, 那么这种计算结果并不可靠, 并且不可信.

SQL注入攻击

SQL注入攻击就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串, 最终达到欺骗服务器执行恶意的SQL命令.

通过以下方式抵御SQL注入攻击:

1. 使用PreparedStatement
2. 使用存储过程
3. 验证输入或过滤输入
4. 专业的安全产品

SQL注入指应用程序对用户输入数据的合法性没有判断或过滤不严, 攻击者可以在应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句, 在管理员不知情的情况下实现非法操作, 以此来实现欺骗数据库服务器执行非授权的任意查询, 从而进一步得到相应的数据信息.

SQL注入的主要防范措施有:

1. 分级管理: 对用户进行分级管理, 严格控制用户的权限.
2. 参数校验: 编写SQL时禁止直接传入SQL, 必须通过设置参数传递变量值.
3. 参数过滤: 对参数值预过滤敏感内容, 如select, and, or等.
4. 安全参数: 使用编程语言中提供的数据库操作安全参数的强制执行检查特性.
5. 漏洞扫描: 利用SQL漏洞扫描工具及时扫描系统存在的相应漏洞.
6. 多层验证: 数据输入必须经过严格的验证才能进入系统, 拒绝未通过验证的输入直接访问数据库.
7. 数据库加密: 对数据库敏感信息进行加密, 传统加密方法包括对称加密, 非对称加密和不可逆加密.

CRC校验码

CRC校验码的计算方式, 如果多项式为 $G(X) = X^5 + X^3 + X + 1$, 则多项式对应的二进制数为 101011.

因为多项式的最高系数为5, 因此对应二进制的位数为 5 + 1 = 6 位, 每一位对应一项系数, 如果存在该系数的多项式, 则标记为1, 最后一位是常数位. 如最高系数项 $X^5$的存在, 则最高位为1.

信息码为111000110, 则信息码右边补5个0, 然后和多项式的二进制数做除法, 得到二进制余数. 做除法时和算法除法类似, 但每一位除的结果不影响其他位, 即不向上借一位, 实际上就是异或. 结果为11001.

而该二进制余数即为CRC校验码.

消息摘要

消息摘要是原报文的唯一压缩表示, 代表了原来的报文特征.

消息摘要算法主要应用在数字签名领域, 作为明文的摘要算法. 著名的摘要算法有MD5, SHA-1算法及其大量变体.

消息摘要算法的特点:

1. 无论输入的消息有多长, 计算出来的消息摘要的长度总数固定的, 如MD5算法摘要的消息长度为128位; SHA-1算法摘要的消息长度位160位; SHA-1的变体可产生192位和256位的消息摘要.
2. 消息摘要算法针对不同的输入会产生不同的输出, 用相同的算法对相同的消息求两次摘要, 其结果是相同的. 因此消息摘要是一种伪随机算法.
3. 输入不同, 其摘要消息也不必相同; 但相同的输入必会产生相同的输出; 即使两条相似的消息的摘要也会大相径庭.
4. 消息摘要函数是无陷门的单向函数, 即只能进行正向的信息摘要, 无法从摘要中恢复出任何的消息.

消息摘要的目的是防止其他用户篡改原消息, 而使用发送方自己的私钥对消息摘要进行加密的作用是防止发送方抵赖.