软考-系统架构设计师

软考高级准备了两个月时间，工作日白天上班，晚上学习，顺利通过。 经验就是一定要把学习的内容整理成知识体系，不然看过就忘，给你半年准备你也考不过。 我自己是看了一遍文老师的视频同时结合自己的理解将内容整理成脑图，结合脑图梳理复习后通过，脑图中每项都加了详细备注，可以帮助你们减少弯路，快速通过。

软考-系统架构设计

• 经验思路
  • 报考流程
    •  注意考前一周打印准考证 每年3月 https://www.ruankao.org.cn/exam/plan 报名入口： https://bm.ruankao.org.cn/sign/welcome 密码Ss93
  • 备考经验
    • 1. 真题为王，每道真题都研究透
  • 考试规则
    • 
  • 备考资料
    • 1.历年真题以及带详细解析的答案 2.西赛教学视频 3.
  • 备考计划
    • 总共两个半月的时间
    • 8月W4
      • 熟悉考试流程和他人经验
      • 先做一套真题
        • 熟悉领悟考试的内容 根据心得修正后续备考思路
      • 完成软件工程视频课
    • 9月
      • 视频看一遍 案例题熟悉 论文题熟悉 碎片时间刷题
      • W1
        • 完成架构设计视频课
      • W2
        • 其他重点视频课
      • W3
        • 刷综合题
      • W4
        • 案例&论文视频教程
    • 10月
      • 刷完所有真题
      • 主攻案例和论文
    • 11月W1
      • 重点知识及论文背诵
  • 科目分析
    • 三科均达到45分为通过
    • 综合
      • 8:30 --11:00
      • 考点分布
        • 
      • 学习策略
        • 真题为主，课程和官方教材为铺 把官方教材当字典，遇到不懂的去翻阅。
    • 案例
      • 主观题:5道大题(只做3道)90分钟 第1道必答,后4道选答2道 案例+论文总时长210分钟(14:30-18:00）
      • 学习策略
    • 论文
      • 论文题:4道题选做1道120分钟 3000字 机考敲字的方式考试 
      • 学习策略
  • 历年真题及模拟考试
    • 23年11月回忆版知识点
      • 选择题
        •    
        • 考点分析
          • 1.计算机硬件 没考 2.操作系统要听 3分 3.数据库必听 3分 4.嵌入式 建议听一听 2分 5.计算机网络 2~3分 7.系统性能 连续两年未考到 8.信息系统基础知识 新版教材新增 重点看下生命周期和开发方法 老师认为还会考其他知识点 9.信息安全 比较重要 3分 10软件工程 很重要 11.面向对象 设计模式不用看了 其他UML，面向对象分析要看 12 项目管理 1~2分 13 系统架构设计 重中之重 14 软件可靠性 1分 15 软件架构和演化和维护 没考到 第二版新增 考到概率不算大 16 未来信息综合技术 3分 要掌握 17.数学与经济管理 时间不够可以不关注 耗费时间大 18法律法规专利 建议看一下
      • 案例题
        • 案例1.大数据架构特点,lamda与kappa分层(文老师考前押题预测中的题目 案例2.SysML需求图和用例图、需求图七类关系等 案例3.读写分离架构、redis缓存、主从复制 案例4.Hibernat架构、数据持久层、jwt(JSONWebToken) 案例5.数字孪生概念、技术选择、架构图填空
        • 考点分析
          • 1.可以看到，23年改版后第一题不再是送分题，考到了具体的大数据架构 所以后面需要重点研究八大架构。 2.软件工程的题出现了超纲，考到了Sysml需求图 后面可能还会考到Sysml图 3.数据库中规中矩，没有超纲，但22年之前经常会出现超纲。redis经常考 4.嵌入式不建议选，几乎每年超纲 5.web 应用，会考些新技术 
      • 论文
        • 论文试题一:可靠性分析与评价方法 论文试题二:面向对象分析(文老师考前押题预测中的题目) 论文试题三:多数据源集成 论文试题四:边云协同
        • 考点分析
          • 1.从23年看，倾向于出新技术及下篇的八大架构 2.传统架构评估和架构方法，近几年考的概率不大，19年之前是重点考点
    • 24年5月
      • 架构：  软件工程： 
      • 选择题
        • 23.以下关于敏捷开发方法的叙述中,不正确的是 C A.敏捷方法是以人为本,而非以过程为本 B.迭代增量式的开发过程 C.敏捷开发模型能够在开始确定开发阶段,对后续过程具有预测性 D.强调个体和交互胜过过程和工具 解析：敏捷开发强调变化性
      • 案例题
      • 论文
• 综合
  • 1计算机组成及体系结构
    • 不重要 近几年考过磁盘 、cache
    • 计算机结构
      • 
      • 控制器
        • 控制器是分析和执行指令的部件，也是统一指挥并控制计算机各部件协 调工作的中心部件，所依据的是机器指令。控制器的组成包含如下。 ① 程序计数器 PC：存储下一条要执行指令的地址； ② 指令寄存器 IR：存储即将执行的指令； ③ 指令译码器 ID：对指令中的操作码字段进行分析解释； ④ 时序部件：提供时序控制信号。
      • 运算器
        • 运算器也称为算术逻辑单元（ArithmeticandLogicUnit，ALU），其主要功 能是在控制器的控制下完成各种算术运算和逻辑运算。运算器的组成包含如下。 ① 算术逻辑单元 ALU：数据的算术运算和逻辑运算； ② 累加寄存器 AC：通用寄存器，为 ALU 提供一个工作区，用在暂存数据； ③ 数据缓冲寄存器 DR：写内存时，暂存指令或数据； ④ 状态条件寄存器 PSW：存状态标志与控制标志（争议点：也有将其归为控制器的）
      • 总线
        • 按总线功能来划分，又可分为地址总线、数据总线、控制总线三类，人们通常所说的总线都包括这三个组成部分。 地址总线用来传送地址信息，数据总线用来传送数据信息，控制总线用来传送各种控制信号。 从数据传输方式划分,可以分为:并行总线和串行总线。
        • 信息码
          •  信息码后面追加最大幂指数个0 作为被除数 除数是幂指数有无 ，5有则为1 ，4没有则为0 ， 所以为101011 除的时候不借位运算 除到最后为校验码，校验码必须是最高幂指数位，即5位。
    • 存储系统
      • 层次化存储系统  计算机采用多级存储器体系，确保能够获得尽可能高的存取速率，同时保持较低的成本。 计算机采用分级存储体系的主要目的是为了解决存储容量、成本和速度之间的矛盾问题。 两级存储:Cache-主存、主存-辅存(虚拟存储体系)。 局部性原理:总的来说,在CPU运行时,所访问的数据会趋向于一个较小的局部空间地址内,包括下面两个方面: 时间局部性原理:如果一个数据项正在被访问,那么在近期它很可能会 被再次访问,即在相邻的时间里会访问同一个数据项。 空间局部性原理:在最近的将来会用到的数据的地址和现在正在访问的 数据地址很可能是相近的,即相邻的空间地址会被连续访问。
      • 存取方式
        • 存储器中数据常用的存取方式有顺序存取、直接存取、随机存取和相联存取四种。 （1）顺序存取：存储器的数据以记录的形式进行组织。对数据的访问必须按特定的线 性顺序进行。磁带存储器采用顺序存取的方式。 （2）直接存取：与顺序存取相似，直接存取也使用一个共享的读写装置对所有的数据 进行访问。但是，每个数据块都拥有唯一的地址标识，读写装置可以直接移动到目的数据块 所在位置进行访问。存取时间也是可变的。磁盘存储器采用直接存取的方式。 （3）随机存取：存储器的每一个可寻址单元都具有自己唯一的地址和读写装置，系统 可以在相同的时间内对任意一个存储单元的数据进行访问，而与先前的访问序列无关。主存 储器采用随机存取的方式。 （4）相联存取：相联存取也是一种随机存取的形式，但是选择某一单元进行读写是取 决于其内容而不是其地址。与普通的随机存取方式一样，每个单元都有自己的读写装置，读 写时间也是一个常数。使用相联存取方式，可以对所有的存储单元的特定位进行比较，选择 符合条件的单元进行访问。为了提高地址映射的速度，Cache 采取相联存取的方式。
      • 主存储器
        • 主存可分为随机存取存储器（Random Access Memory，RAM）和只读存储器ROM（Read Only Memory，ROM）可。
        • 直接存储器访问DMA
          • 直接存储器访问(Direct Memory Access,DMA)是指数据在主存与I/0设备间的直接成块传送,即在主存与I/0设备间传送数据块的过程中,不需要CPU作任何干涉,只需在过程开始启动(即向设备发出"传送一块数据"的命令) 与过程结束(CPU通过轮询或中断得知过程是否结束和下次操作是否准备就绪)时由CPU进行处理,实际操作由DMA硬件直接完成,CPU在传送过程中可做其他事情。
      • Cache 存储器
        • Cache的设计思想是在合理的成本下提高命中率 Cache的命中率必须很高,一般要达到90%以上 Cache 的功能是提高 CPU 数据输入输出的速率，突破所谓的“冯•诺依曼瓶颈”，即 CPU与存储系统间数据传送带宽限制。 通常在CPU 和内存之间设置小容量的 Cache Cache 通常采用相联存储器（ContentAddressable Memory，CAM）。CAM 是一种基于数 据内容进行访问的存储设备。当对其写入数据时，CAM 能够自动选择一个未用的空单元进 行存储；当要读出数据时，不是给出其存储单元的地址，而是直接给出该数据或者该数据的 一部分内容，CAM 对所有存储单元中的数据同时进行比较，并标记符合条件的所有数据以 供读取。由于比较是同时、并行进行的，所以，这种基于数据内容进行读写的机制，其速度 比基于地址进行读写的方式要快很多 使用Cache改善系统性能的依据是程序的局部性原理。 时间局部性 空间局部性 Cache存储器存放正在处理的部分指令和数据
      • 流水线技术
        • 流水线时间计算 流水线周期:指令分成不同执行段,其中执行时间最长的段为流水线周期。 流水线执行时间:1条指令总执行时间+(总指令条数-1)*流水线周期 流水线吞吐率计算:吞吐率即单位时间内执行的指令条数。 公式:指令条数/流水线执行时间。 流水线的加速比计算:加速比即使用流水线后的效率提升度,即比不使用流水线快了多少倍,越高 表明流水线效率越高, 公式:不使用流水线执行时间/使用流水线执行时间。 
      • 主存编址
      • 磁盘
        • 外存分联机磁盘和脱机磁盘 磁盘有正反两个盘面,每个盘面有多个同心圆,每个同心圆是一个磁道（也叫柱面）,每个同心圆又被划 分为多个扇区,数据就被存放在一个个扇区中。扇区是数据读取的最小单位 磁头首先要寻找到对应的磁道,然后等待磁盘进行周期旋转,旋转到指定的扇区,才能读取 到对应的数据,因此,会产生寻道时间和等待时间。 磁道对应移臂调度，扇区对应旋转调度。 公式为: 存取时间=寻道时间+等待时间(平均定位时间+转动延迟)。 磁盘调度算法： 先来先服务FCFS:根据进程请求访问磁盘的先后顺序进行调度。 最短寻道时间优先SSTF:请求访问的磁道与当前磁道最近的进程优先调度, 时间最短。会产生"饥饿"现象,即远处进程可能永远无法访问。 使得每次的寻道 扫描算法SCAN:又称"电梯算法",磁头在磁盘上双向移动,其会选择离磁头当前所在磁道 最近的请求访问的磁道,并且与磁头移动方向一致,磁头永远都是从里里向外或者从外向里一 移动完才掉头,与电梯类似。 单向扫描调度算法CSCAN:与SCAN不同的是,其只做单向移动,即只能从里向外或者从外向里
  • 2操作系统
    • 进程管理
      • (1)进程管理。实质上是对处理机的执行"时间"进行管理,采用多道程序等 技术将CPU的时间合理地分配给每个任务,主要包括进程控制、进程同步、进理 通信和进程调度。
      • 操作系统概述
        • 4个特性
          • 并发性、共享性、虚拟性和不确定性
        • 三个重要作用
          • 第一,管理计算机中运行的程序和分配各种软硬件资源; 第二,为用户提供友善的人机界面。 第三,为应用程序的开发和运行提供一个高效率的平台。
        • 操作系统分类
          • 批处理操作系统:单道批处理和多道批处理(主机与外设可并行)。 分时操作系统:一个计算机系统与多个终端设备连接。将CPU的工作日时间划 分为许多很短的时间片,轮流为各个终端的用户服务。 实时操作系统:实时是指计算机对于外来信息能够以足够快的速度进行处理, 并在被控对象允许的时间范围内做出快速反应。实时系统对交互能力要求不高, 但要求可靠性有保障。 网络操作系统:是使联网计算机能方便而有效地共享网络资源,为网络角户 提供各种服务的软件和有关协议的集合。三种模式:集中模式、客户端服务器 模式、对等模式。 分布式操作系统:分布式计算机系统是由多个分散的计算机经连招接而成的计 算机系统,系统中的计算机无主、次之分,任意两台计算机可以通过通信交换 信息。 微型计算机操作系统:简称微机操作系统,常用的有Windows、Mac OS Linux。
          • 嵌入式操作系统
            • 嵌入式操作系统主要特点: (1)微型化。从性能和成本角度考虑,希望占用的资源和系统代码量少,如内 存少、字长短、运行速度有限、能源少(用微小型电池)。 (2)可定制。从减少成本和缩短研发周期考虑,要求嵌入式操作系统能运行在 不同的微处理器平台上,能针对硬件变化进行结构与功能上的配置,以满足不 同应用需要。 (3)实时性。嵌入式操作系统主要应用于过程控制、数据采集、传输通信、多 媒体信息及关键要害领域需要迅速响应的场合,所以对实时性要求较高。 (4)可靠性。系统构件、模块和体系结构必须达到应有的可靠性,对关键要害 应用还要提供容错和防故障措施。 (5)易移植性。为了提高系统的易移植性,通常采用硬件抽象层和板级支撑包 的底层设计技术。 嵌入式系统初始化过程按照自底向上、从硬件到软件的次序依次为:片级初 始化→板级初始化→系统初始化。
      • 进程组成和状态
        • 进程的组成:进程控制块PCB(唯一标志)、程序(描述进程要做什么)、数 据(存放进程执行时所需要的数据） 进程基础的状态是下左图中的三态图。需要熟练掌握左下图中的进程三态之 间的转换。  就绪态是其他条件都已满足，只差CPU 阻塞态是等待某个事件的触发，或条件的满足
      • 前趋图
        • 用来表示哪些任务可以并行执行,哪些任务之间有顺序关系,具体如下图: 可知,ABC可以并行执行,但是必须ABC都执行完后,才能执行D,这就就确定了 两点:任务间的并行、任务间的先后顺序。   有P1至P2的箭线,则说明P1执行完,才能执行P2 ,此时约束关系记为:(P1,P2)。 依据此原理,题目中前趋图的正确描述为: {(P1,P2),(P1,P3),(P2,P3),(P2,P5 ),(P3,P4),(P3、P5),(P4,P6),(P5 ,P6),(P5,P7),(P5,P8),(P6,P8 ),(P7,P8)}
      • 进程同步与互斥
        • 临界资源:各进程间需要以互斥方式对其进行访问的资源。 临界区:指进程中对临界资源实施操作的那段程序。本质是一段程序代码。 互斥:某资源(即临界资源)在同一时间内只能由一个任务单独使用,使用 时需要加锁,使用完后解锁才能被其他任务使用;如打印机。 同步:多个任务可以并发执行,只不过有速度上的差异,在一定清况下停下 等待,不存在资源是否单独或共享的问题;如自行车和汽车。 互斥信号量:对临界资源采用互斥访问,使用互斥信号量后其他进程无法访 问,初值为1。 同步信号量:对共享资源的访问控制,初值一般是共享资源的数量量。
        • P操作与V操作
          • PV 操作 P操作:申请资源,S=S-1,若s>=0,则执行P操作的进程继续执行;若s<0,则 置该进程为阻塞状态(因为无可用资源),并将其插入阻塞队列。 V操作:释放资源,S=S+1,若S>0,则执行V操作的进程继续执行;若s<=0, 则从阻塞状态唤醒一个进程,并将其插入就绪队列(此时因为缺少资源被P操作 阻塞的进程可以继续执行),然后执行V操作的进程继续。  经典问题： 生产者和消费者的问题 三个信号量:互斥信号量50(仓库独立使用权),同步信号量S1(仓库空闲个数),同步信号量S2(仓库商品个数)。 
      • 进程调度
        • 进程调度方式是指当有更高优先级的进程到来时如何分配CPU。分为可剥夺和 不可剥夺两种,可剥夺指当有更高优先级进程到来时,强行将正在运行进程的 CPU分配给高优先级进程;不可剥夺是指高优先级进程必须等待当前进程自动释 放CPU。
        • 调度算法
          • 先来先服务FCFS：先到达的进程优先分配CPU。用于宏观调度。 时间片轮转:分配给每个进程CPU时间片,轮流使用CPU,每个进程时间片大 小相同,很公平,用于微观调度。 优先级调度:每个进程都拥有一个优先级,优先级大的先分配CPU。 多级反馈调度:时间片轮转和优先级调度结合而成,设置多个就绪队歹e 1,2,3...n,每个队列分别赋予不同的优先级,分配不同的时间片长度;新进程先 进入队列1的末尾,按FCFS原则,执行队列1的时间片;若未能执行行完进程,则 转入队列2的末尾,如此重复。
      • 死锁
        • 当一个进程在等待永远不可能发生的事件时,就会产生死锁,若系统中有多 进程处于死锁状态,就会造成系统死锁。
        • 四个必要条件
          • 死锁产生的四个必要条件:资源互斥、每个进程占有资源并等待其他资源、系统不能剥夺进程资源、进程资源图是一个环路。
        • 解决死锁
          • 死锁产生后,解决措施是打破四大条件,有下列方法: 死锁预防:采用某种策略限制并发进程对于资源的请求,破坏死锁产生的晒 个条件之一,使系统任何时刻都不满足死锁的条件。 死锁避免:一般采用银行家算法来避免,银行家算法,就是提前计算出一条 不会死锁的资源分配方法,才分配资源,否则不分配资源,相当于借贷,考虑 对方还得起才借钱,提前考虑好以后,就可以避免死锁。 死锁检测:允许死锁产生,但系统定时运行一个检测死锁的程序,若检测到 系统中发生死锁,则设法加以解除。 死锁解除:即死锁发生后的解除方法,如强制剥夺资源,撤销进程等。 死锁资源计算:系统内有n个进程,每个进程都需要R个资源,那么其发生死 锁的最大资源数为n*(R-1)。其不发生死锁的最小资源数为Jn*(R-1)+1.
      • 线程
        • 传统的进程有两个属性:可拥有资源的独立单位;可独立调度和分配的基本 单位。 引入线程的原因是进程在创建、撤销和切换中,系统必须为之付出较大的时 空开销,故在系统中设置的进程数目不宜过多,进程切换的频率不宜太高,这 就限制了并发程度的提高。引入线程后,将传统进程的两个基本属性分开,线 程作为调度和分配的基本单位,进程作为独立分配资源的单位。用户可以通过 创建线程来完成任务,以减少程序并发执行时付出的时空开销。 线程是进程中的一个实体,是被系统独立分配和调度的基本单位。线程基本 上不拥有资源,只拥有一点运行中必不可少的资源(如程序计数器、一组寄存 器和栈),它可与同属一个进程的其他线程共享进程所拥有的全全部资源,例如 进程的公共数据、全局变量、代码、文件等资源,但不能共享线程独有的的资源 如线程的栈指针等标识数据。
    • 存储管理
      • (3)存储管理。存储管理是对主存储器"空间"进行管理,主要包括存储分分配 与回收、存储保护、地址映射(变换)和主存扩充。
      • 分区存储管理
        • 所谓分区存储组织,就是整存，将某进程运行所需的内存整体一起分配给它, 然后再执行。有三种分区方式: 固定分区:静态分区方法,将主存分为若干个固定的分区,将要运行的作业 装配进去,由于分区固定,大小和作业需要的大小不同,会产生内部碎片:: 可变分区:动态分区方法,主存空间的分区是在作业转入时划分分,正好划分 为作业需要的大小,这样就不存在内部碎片,但容易将整片主存空间切割成许 多块,会产生外部碎片。可变分区的算法如下: 可重定位分区:可以解决碎片问题,移动所有已经分配好的区或,使其成为 一个连续的区域,这样其他外部细小的分区碎片可以合并为大的分区,满足作 业要求。只在外部作业请求空间得不到满足时进行。
      • 分页存储管理
        • 逻辑页分为页号和页内地址,页内地址就是物理偏移地址,而页号与与物理块号 并非按序对应的,需要查询页表,才能得知页号对应的物理块号,再用物理块 号加上偏移地址才得出了真正运行时的物理地址。 优点:利用率高,碎片小,分配及管理简单。 缺点:增加了系统开销,可能产生抖动现象 逻辑页： 
        • 逻辑地址到物理地址转换
          •  转换过程中页内地址是不变的
        • 页面置换算法
          • 最优算法:OPT,理论上的算法,无法实现,是在进程执行完后进行的最佳效 率计算,用来让其他算法比较差距。原理是选择未来最长时间内不被访问的页 面置换,这样可以保证未来执行的都是马上要访问的。 先进先出算法:FIFO,先调入内存的页先被置换淘汰,会产生抖动现象,即分 配的页数越多,缺页率可能越多(即效率越低). 最近最少使用:LRU,在最近的过去,进程执行过程中,过去最少使用的萌 被置换淘汰,根据局部性原理,这种方式效率高,且不会产生抖动现象,使用 大量计数器,但是没有LFU多。 淘汰原则:优先淘汰最近未访问的,而后淘汰最近未被修改的页面。
          • 缺页中断
            • 对于访问顺序为(0,0,1,1,3,1,2)的序列,有2个可用页,其调用产生缺页中断的过程如下 需要0号页不在内存,缺页中断1次,此时已有页面为【0】; 需要0号页已在内存,不中断,此时已有页面为【0】; 需要1号页不在内存,缺页中断1次,此时已有页面为【0,1】; 需要1号页已在内存,不中断,此时已有页面为【0,1】; 需要3号页不在内存,缺页中断1次,根据先进先出算法,淘汰0号号页,此时已有页面为【1,3】; 需要1号页已在内存,不中断,此时已有页面为【1,3】; 需要2号页不在内存,缺页中断1次,根据先进先出算法,淘汰1号页,此时已有页面为【3,2】。 共产生4次缺页中断。
        • 快表（快速页表）
          • 是一块小容量的相联存储器,由快速存储器组成,按内容访问,速度快,并 且可以从硬件上保证按内容并行查找,一般用来存放当前访问最频繁的少数活 动页面的页号。 快表是将页表存于Cache中;慢表是将页表存于内存上。慢表需要访问两次内 存才能取出页,而快表是访问一次Cache和一次内存,因此更快。
      • 分段存储管理
        • 将进程空间分为一个个段,每段也有段号和段内地址（段长）,与页式存储不同的是 每段物理大小不同,分段是根据逻辑整体分段的,因此,段表也与页表的内容 不同,页表中直接是逻辑页号对应物理块号,而下图所示,段表有段长和基址 两个属性,才能确定一个逻辑段在物理段中的位置。  如下了解 不考 
      • 段页式存储管理
    • 设备管理
      • (4)设备管理。实质是对硬件设备的管理,包括对输入/输出设备的分配、启 动、完成和回收。
      • 设备管理概述
        • 设备是计算机系统与外界交互的工具,具体负责计算机与外部的输入/输出工作, 所以常称为外部设备(简称外设)。 在计算机系统中,将负责管理设备和输入/输出的机构称为1/0系统。因此,1/0系统由设备、控制器、通道(具有通道的计算机系统)、总线和I/0软件组成。
        • 设备分类
          • 按数据组织分类:块设备、字符设备。 按照设备功能分类:输入设备、输出设备、存储设备、网络联网设备、供电设备 资源分配角度分类:独占设备、共享设备和虚拟设备。 数据传输速率分类:低速设备、中速设备、高速设备。
      • I/0软件
        • I/0设备管理软件的所有层次及每一层功能如下图: 实例:当用户程序试图读一个硬盘文件时,需要通过操作系统实现这一操作。 与设备无关软件检查高速缓存中有无要读的数据块,若没有,则调用设备驱动 程序,向1/0硬件发出一个请求。然后,用户进程阻塞并等待磁盘操作的完成。 当磁盘操作完成时,硬件产生一个中断,转入中断处理程序。中断处理程序检 查中断的原因,认识到这时磁盘读取操作已经完成,于是唤醒用户进程取回从 磁盘读取的信息,从而结束此次1/0请求。用户进程在得到了所需的硬盘文件辆 容之,后继续运行。 
      • 设备管理技术
    • 文件管理
      • (2)文件管理。主要包括文件存储空间管理、目录管理、文件的读/写管理和 存取控制。
      • 文件管理概述
        • 不怎么考
        • 文件逻辑结构
          • 文件的逻辑结构可分为两大类:有结构的记录式文件;无结构的流式文件
        • 文件物理结构
          • 文件的物理结构是指文件在物理存储设备上的存放方法,包括: (1)连续结构。连续结构也称顺序结构,它将逻辑上连续的文件信息(如记录 依次存放在连续编号的物理块上。 (2)链接结构。链接结构也称串联结构,它是将逻辑上连续的文件信息(如记3 录)存放在不连续的物理块上,每个物理块没有一个指针指向下一个物理块。 (3)索引结构（考点）。将逻辑上连续的文件信息(如记录)存放在不连续的物理块中, 系统为每个文件建立一张索引表。索引表记录了文件信息所在的逻辑号对应 的物理块号,并将索引表的起始地址放在与文件对应的文件目录项中 (4)多个物理块的索引表。索引表是在文件创建时由系统自动建立的并与文 件一起存放在同一文件卷上。根据一个文件大小的不同,其索引表占用物理块 的个数不等,一般占一个或几个物理块。
      • 索引文件结构
        •  如图所示,系统中有13个索引节点,0-9为直接索引,即每 个索引节点存放的是内容,假设每个物理盘块大小为4KB,共可 存4KB*10=40KB数据; 10号索引节点为一级间接索引节点,大小为4KB,存放的 并非直接数据,而是链接到直接物理盘块的地址,假设每个 地址占4B,则共有1024个地址,对应1024个物理盘,可存 1024*4KB=4096KB数据。 二级索引节点类似,直接盘存放一级地址,一级地址再存 放物理盘快地址,而后链接到存放数据的物理盘块,容量又 扩大了一个数量级,为1024*1024*4KB数据。
      • 文件目录
        •  文件控制块的有序集合称为文件目录 相对路径:是从当前路径开始的路径。 绝对路径:是从根目录开始的路径。 全文件名=绝对路径+文件名。要注意,绝对路径和相对路 径是不加最后的文件名的,只是单纯的路径序列。
      • 文件存储空间管理
        • 位示图
          • 位示图 这种方法是在外存上建立一张位示图(Bitmap),记录文件存储器的使用情况。 每一位对应文件存储器上的一个物理块,取值0和1分别表示空闲和占用 
    • 作业管理
      • 作业管理。包括任务、界面管理、人机交互、图形界面、语音控制和虚拟现实等。 基本不考
  • 3数据库系统
    •  考点汇总： 基本概念:三级模式-两级映像、数据库设计 数据库模型:E-R模型、关系模型、关系代数(结合SQL语言) 规范化:函数依赖、键与约束、范式、模式分解 事务并发:并发三种问题、三级封锁协议 数据库新技术:数据库安全与备份、反规范化、分布式数据库、缓存数据库、数 据库集群,NoSql 案例考点:ER图+关系模式设计、反规范化技术、缓存数据库等新技术。 202311选择题考察约4-5分:范式(传递依赖和2NF,多值依赖和4NF)、数据库 语句(having+groupby)、三级模式、 202311案例考察:读写分离、主从复制、redis缓存数据库
    • 数据库基本概念
      • 数据库系统
        • 这部分有个了解即可 数据:是数据库中存储的基本对象,是描述事物的符号记录。 数据的种类:文本、图形、图像、音频、视频、学生的档案记录、货物的二输 情况等。 数据库DB:是长期存储在计算机内、有组织的、可共享的大量数据的集合。 数据库的基本特征: 数据按一定的数据模型组织、描述和存储; 可为各种用户共享; 冗余度较小; 数据独立性较高; 易扩展。 数据库系统DBS:是一个采用了数据库技术,有组织地、动态地存储大量相关 数据,方便多用户访问的计算机系统。其由下面四个部分组成: 数据库(统一管理、长期存储在计算机内的,有组织的相关数据的集合) 硬件(构成计算机系统包括存储数据所需的外部设备) 软件(操作系统、数据库管理系统及应用程序) 人员(系统分析和数据库设计人员、应用程序员、最终用户、数据库管理员 DBA)。 数据库管理系统DBMS的功能 实现对共享数据有效的组织、管理和存取。 包括数据定义、数据库操作、数据库运行管理、数据的存储管理、数据库的建 立和维护等。
      • 数据库模式
        • 三级模式两级映射 (1)三级模式: 外模式对应数据库中的视图这个级别,将表进行一定的处理后再提供给用户使用。 模式(也称为概念模式)对应数据库表,根据应用、需求将物理数据划分成一张张表。 内模式对应物理文件，管理如何存储物理的数据,对应具体物理存储文件。 (2)两层映像: 外模式-模式映像:是表和视图之间的映射,存在于概念 级和外部级之间,若表中数据发生了修改,只需要修改此映 射,而无需修改应用程序。 模式-内模式映像， 两层映像可以保证数据库中的数据具有较高的逻辑独立性和物理独立性。 (3)物理独立性:即数据库的内模式发生改变时,应用程序不不需要改变。 (4)逻辑独立性:即逻辑结构发生改变时,用户程序不需要改变。(逻辑独立性比物 理独立性更难实现) 
        • 关系表类型
          • 关系的3种类型 基本关系(通常又称为基本表或基表):实际存在的表,实际存储数据的逻辑表示。 查询表:查询结果对应的表。 视图表:由基表或其他视图表导出的表,本身不独立存储,数据库只存放它的定义,常称为虚表。
        • 数据库视图
          • 数据库视图:它一个虚拟表(逻辑上的表),其内容由查询定义(仅(保存SQL查询语句)。 同真实的表一样,视图包含一系列带有名称的列和行数据。但是是,视图并没有真正存储这 些数据,而是通过查询原始表动态生成所需要的数据。 视图的优点: 1、视图能简化用户操作 2、视图使用户能以多种角度看待同一数据 3、视图对重构数据库提供了一定程度的逻辑独立性 4、视图可以对机密数据提供安全保护 物化视图:它不是传统意义上虚拟视图,是实体化视图,其本身会存储数据。同时当原始 表中的数据更新时,物化视图也会更新。
      • 数据库设计过程
        •  需求分析:即分析数据存储的要求,产出物有数据流图、 数据字典、需求说明书。 概念结构设计:就是设计E-R图,也即实体-联系图,与物理 实现无关,说明有哪些实体,实体有哪些属性。 分E-R图进行合并时,它们之间存在的冲突主要有以下3类。 属性冲突。同一属性可能会存在于不同的分E-R图中。 命名冲突。相同意义的属性,在不同的分E-R图上有着不同的命名 或是名称相同的属性在不同的分E-R图中代表着不同的意义。 结构冲突。同一实体在不同的分E-R图中有不同的属性,同一对象 在某一分E-R图中被抽象为实体而在另一分E-R图中又被抽象为属性 逻辑结构设计:将E-R图,转换成关系模式,也即转换成实 际的表和表中的列属性,这里要考虑很多规范化的东西。 物理设计:根据生成的表等概念,生成物理数据库。 数据库实施阶段：根据逻辑设计和物理设计阶段的结果建立数 据库,编制与调试应用程序,组织数据入库,并进行试运行。 数据库运行和维护阶段：数据库应用系统经过试运行即可投入 运行,但该阶段需要不断地对系统进行评价、调整与修改。
        • 概念结构设计-ER模型
          • 实体-联系图 ER图  
        • 逻辑结构设计-关系模式
          •  E-R图向关系模式的转换 实体向关系模式的转换 联系向关系模式的转换 关系模式的规范化 确定完整性约束(保证数据的正确性) 用户视图的确定(提高数据的安全性和独立性) 根据数据流图确定处理过程使用的视图 根据用户类别确定不同用户使用的视图 应用程序设计
          • 联系转关系模式
            • 一个实体型必须转换为一个关系模式 联系转关系模式:  (1)一对一联系的转换有两种方式。 独立的关系模式:并入两端主键及联系自身属性。(主键:任一端主键) 归并(任意一端):并入另一端主键及联系自身属性。(主键:保持不变) (2)一对多联系的转换有两种方式。 独立的关系模式:并入两端主键及联系自身属性。(主键:多端主键) 归并(多端):并入另一端主键及联系自身属性。(主键:保持不变) (3)多对多联系的转换只有一种方式 独立的关系模式:并入两端主键及联系自身属性。(主键:两端主键的组合键) 举例：  这是一个多对多的三元关系，ABC三个实体各转换为一个关系模式，中间的联系不能并入实体，所以也是一个关系模式，所以这个ER图至少转换为4个关系模式
            • 1对1转换
              • 
            • 1对n转换
              • 两种方式： 独立的关系模式:并入两端主键及联系自身属性。(主键:多端主键) 归并(多端):并入另一端主键及联系自身属性。(主键:保持不变) 
            • n对n 转换
              • 对于联系需要并入两端主键及联系自身属性，形成独立关系模式 
          • 属性及属性类型
            • 属性:实体所具有的特性。 属性分类:简单属性和复合属性;单值属性和多值属性;NULL属性:派生属性。
            • 简单属性和复合属性
              • 简单属性是不可再分割的属性。譬如,性别和年龄都是简单属性 复合属性是可再分解为其他属性的属性(即属性可嵌套)。警如,地址属性可分解为:邮 政编码、省(市)名、区名、街道四个子属性,街道又可分解为路名、门牌号码两个子属 性。
            • 单值属性和多值属性
              • 单值属性是指一个实体只有一个值的属性。例如，一个实体的图书价格只有一个（例如，38．5元人民币） 多值属性，对于一个实体可以有多个值。例如：学生信息表有一个关于兴趣的属性。一个学生可能有几个兴趣，如体育、电影、旅游、学习等
            • Null 属性
              • 允许为空值的属性
            • 派生属性
              • 派生属性是指某个实体的非主键属性由该实体其他非主键属性决定 包裹单中的总计金额是由资费、挂号费、保价费、回执费计算得出,所以是派生属性。
        • 数据模型
          • 关系模型是二维表的形式表示的实体-联系模型,是将实体-联系模型转换而来 的,经过开发人员设计的; 概念模型是从用户的角度进行建模的,是现实世界到信息世界的第一抽象, 是真正的实体-联系模型。 网状模型表示实体类型及其实体之间的联系,一个事物和另外几个都有联系, 形成一张网。 面向对象模型是采用面向对象的方法设计数据库,以对象为单位,每个对象 包括属性和方法,具有类和继承等特点。 数据模型三要素:数据结构(所研究的对象类型的集合)、数据操作(对数 据库中各种对象的实例允许执行的操作的集合)、数据的约束条件(一组完整 性规则的集合)。 用E-R图来描述概念数据模型,世界是由一组称作实体的基本对象和这些对象 之间的联系构成的。 在E-R模型中,使用椭圆表示属性(一般没有)、长方形表示实体、菱表示 联系,联系的两端要填写联系类型,示例如下图:  实体:客观在在并可相互区别的事物。可以是具体的人、事、物或抽象概念。 如人、汽车、图书、账户、贷款。 弱实体和强实体:弱实体依赖于强实体的存在而存在。 实体集:具有相同类型和共享相同属性的实体的集合,如学生主、课程。 属性:实体所具有的特性。 属性分类:简单属性和复合属性;单值属性和多值属性;NULL属性:派生属性。 域:属性的取值范围称为该属性的域。 码(key):唯一标识实体的属性集。 联系:现实世界中事物内部以及事物之间的联系,在E-R图中反映为实体内部 的联系和实体之间的联系。 联系类型:一对一1:1、一对多1:N、多对多M:N。 两个以上实体型的联系： 
          • 关系模型
            • 关系模型中数据的逻辑结构是一张二维表,由行列组成。用表格结构表达实 体集,用外键标识实体间的联系。如下图:  优点:建立在严格的数学概念基础上;概念单一、结构简单、清晰用户易 懂易用;存取路径对用户透明,从而数据独立性、安全性好,简化数据库开发 工作。 缺点:由于存取路径透明,查询效率往往不如非关系数据模型。 目或度：关系模式中属性的个数 候选键：唯一标识元组 主键：候选键中任选一个为主键 主属性与非主属性:组成候选码的属性就是主属性,其它的就是是非主属性 全码(ALL-Key):关系模式的所有属性组是这个关系的候选码。
          • 层次模型
          • 网状模型
          • 面向对象模型
        • 完整性约束
          • 事务的执行应该保证数据库的一致性。数据库系统通常采用完整性约束检查机制保证单个事务的一 致性。
          • 实体完整性约束
            • 规定基本关系的主属性不能取空值(唯一且非空)。
          • 参照完整性约束
            • 关系与关系间的引用,其他关系的主键或空值。
          • 用户自定义完整性约束
            • 用户环境决定
      • 关系代数
        • 以S1和S2为例： 
        • 并交差
          •  对于关系S1和S2 并交差后结果如下： 
        • 笛卡尔积
          • 
        • 投影
          •  如上表示对S1 垂直方向投影，投影列为sno 和sname
        • 选择
          •  如上表示对S1水平方向选择，选择的行为sno= No0003这一行
        • 连接
          •  列：二者之和减去重复列 行：重复列相等的行
        • SQL与关系代数
          • Select对应 投影 from 对应 笛卡尔积 where 对应 选择 分组查询groupby,分组时要注意select后的列名要适应分组,having为分组查询附加条件 select sno,avg(score)from student group by sno havingavg (score) >60) 更名运算as select sno as "学号" from t1 数据库插入insert into...values(): insert into t1 values('a',66) 数据库删除delete from...where:delete t1 where sno=44 数据库修改update...set...where:updatet1 set sname='aa' where sno=3 排序order by,默认为升序,降序要加关键字DESC:select*from t1 order by sno desc
      • 元组演算
        • 按照谓词变量的不同，可分为关系元组演算，关系域演算。 关系元组演算公式的基本形式： { t | P（t）} 上式表示：所有使谓词P为真的元组t的集合。 t是元组变量。 t∈r 表示元组t在关系r中。 t[A] 表示元组t的分量，即t在属性A上的值。 P是与谓语逻辑相似的公式，P（t）表示以元组t为变量的公式。
        • 存在量词和全称量词
          •  
      • 数据库索引
        • 数据库索引:提升查询效率,降低添加、修改、删除效率。采用B树,B+树等。 无索引数据表 只能顺序查找数据  索引数据表： 比如查找时可以通过2分法快速查找记录 虽然提升了查询效率，但是增删改时需要同时更新索引表，降低增删改的效率 
        • B+树
          • 2分法不是最优的查找方法 推荐的是B树，B+树，它们是从2分法演变过来的 
      • 数据库视图
        • 视图(View)并不在数据库中实际存在,而是一种虚拟表。 视图和应用程序打交道，通过SQL 语句查询拼合起来的表 
        • 视图优点
          • 视图的优点: 1、视图能简化用户的操作 2、视图机制可以使用户以不同的方式查询同一数据 3、视图对数据库重构提供了一定程度的逻辑独立性 4、视图可以对机密的数据提供安全保护 物化视图:将视图的内容物理存储起来,其数据随原始表变化,同步更新
      • 分区分表分库
        • 比较容易考到的是分区  
        • 分区
          •  分区的优点： 1、相对于单个文件系统或是硬盘,分区可以存储更多的数据（分区后可以把不同区分布在不同物理设备上）。 2、数据管理比较方便,比如要清理或废弃某年的数据,就可以直接删除该日期的分区数据即可。 3、精准定位分区查询数据,不需要全表扫描查询,大大提高救据检索效率。 4、可跨多个分区磁盘查询,来提高查询的吞吐量。 5、在涉及聚合函数查询时,可以很容易进行数据的合并。
          • 范围分区
            • 
          • 哈希分区
            •  比如哈希值对3求余，根据余数来分到3个表 哈希分区相比其他分区方式，能更均匀的分配
          • 列表分区
            • 要分的东西本来就是个列表，比如城市 
    • 规范化和并发控制
      • 规范化理论
        • 函数依赖
          • 设R(U,F)是属性U上的一个关系模式,X和Y是U的子集,r为R的任一关系,如果 对于r中的任意两个元组u,v,只要有u[X]=v[X],就有u[Y]=v[Y],则称X函数决定Y, 或称Y函数依赖于X,记为X→Y。
          • 部分函数依赖
            •  如上图候选键为AB， C依赖于A， 所以依赖于候选键的一部分就成为部分函数依赖
          • 传递函数依赖
            • 
        • 键与约束
          • 候选键/候选码
            • 候选键：唯一标识元组 假设我们有一个名为"员工"的表,包含以下属性:员工号、姓名、身份证号、部门号。在这个表中, 有可能存在多个员工具有相同的姓名或部门号,但每个员工的员工工号和身份证号都是唯一的。 (员工号)是一个候选键,因为它能够唯一地标识每一条员工记录录。 (身份证号)也是一个候选键,因为它同样具有唯一性。
            • 求候选键
              • 将关系模式的函数依赖关系用"有向图"的方式表示 找入度为0的属性,并以该属性集合为起点,尝试遍历有向图,若能正常遍历图 中所有结点,则该属性集即为关系模式的候选键。 箭头-> 左侧为出度，右侧为入度，如果一个属性只出现在左侧，我们称它入度为0.。 若入度为0的属性集不能遍历图中所有结点,则需要尝试性的将一些中间结点 (既有入度,也有出度的结点)并入入度为0的属性集中,直直至该集合能遍历所 有结点,集合为候选键 例1:  A1入度为0，且以它为起点，可以找到任何一个点，所以A1为 候选键。 例2：  A、B、D、C 只出现在左侧，入度为0。 另外比如ABD能决定E，即ABD->E, 所有推导下来，发现候选码应该为ABCD 例3：  入度为0 的没有， 出度为0 的是C，所以C肯定不是候选键。 从A为起点，可以遍历到任何一个点 从B为起点，也可以遍历到任何一个点 所以候选键为A和B
          • 主键
            • 主键：候选键中任选一个为主键 如有A、B、C三个候选码,主码可以是(A)(B)(C) (A,B) (AC) (B, C) (A, B, C)
          • 外键
            • 其他关系的主键
          • 主属性与非主属性
            • 主属性与非主属性:组成候选码的属性就是主属性,其它的就是非主属性。
        • 函数依赖Armstrong公理
          • 关系模式R<U,F>来说有以下的推理规则: A1.自反律(Reflexivity):若,则X→Y成立。 A2.增广律(Augmentation):若且X→Y,则XZ→YZ成立。 A3.传递律(Transitivity):若X→Y且Y→Z,则X→Z成立。 根据A1,A2,A3这三条推理规则可以得到下面三条推理规厕: 合并规则:由X→Y,X→Z,有X→YZ。(A2,A3) 伪传递规则:由X→Y,WY→Z,有XW→Z。(A2,A3) 分解规则:由X→Y及ZY,有X→Z。(A1,A3)
        • 范式判断
          • 范式
            • 四类范式 
            • 第一范式（1NF）
              • 第一范式(1NF):在关系模式R中,当且仅当所有域只包含原子值,即每个 属性都是不可再分的数据项,则称关系模式R是第一范式。 简单属性及复合属性： 像地址这种可以拆成省市区的为复合属性，不可拆分的为简单属性。 单值属性和多值属性： 取值唯一为单值属性，多值属性比如电话号码可以有多个。 NULL属性： 属性没有值或者暂时未知 派生属性： 计算得来的属性，比如通过出生年月计算出年龄 举例： 关系模式R(系名称,高级职称人数)是否满足1NF？  因为高级职称人数还可以细分，所以它不符合第一范式。没达到第一范式是无法成功建表的。
            • 第二范式（2NF）
              • 第二范式(2NF):当且仅当实体E是第一范式(1NF),且每一个非主属性 完全依赖主键(不存在部分依赖)时,则称实体E是第二范式. 思考题:请思考该关系模式会存在哪些问题(从数据冗余、更新异常、插入 异常、删除异常这几个方面来考虑),解决方案是什么?  主属性为学号、课程号，非主属性为成绩、学分 从上图可以看到，主键为（学号，课程号），但学分只依赖于课程号，为部分依赖，所以不满足第二范式 解决方案，拆成两个表，表1（学号，课程号，成绩），表2（课程号，学分）
            • 第三范式（3NF）
              • 第三范式(3NF):当且仅当实体E是第二范式(2NF),且E中没有非主属 性传递依赖于候选键时,则称实体E是第三范式。 思考题:请思考该关系模式会存在哪些问题(从数据冗余、更新异常、插入 异常、删除异常这几个方面来考虑),解决方案是什么?  存在的问题是系号为非主属性，系名系位置通过系号来传递函数依赖，所以不满足第三范式 解决方案是拆表，将系相关信息单独拆出表 表2（系号，系名，系位置） 表1为（学号，姓名，系号）
            • BC范式(BCNF)
              • BC范式(BCNF): 消除主属性之间的传递依赖和部分函数依赖 设R是一个关系模式,F是它的依赖集,R属于BCNF当且 仅当其F中每个依赖的决定因素必定包含R的某个候选码。 例:关系模式STJ(S,T,J)中,S表示学生,T表示老师,J表示课程。每 一老师只教一门课程。每门课程有若干老师,某一学生选定某门课,就对应一个 固定老师。  先写出其函数依赖集合F = {T->J，SJ->T} 1.属性不可拆分，所以满足1NF 2.候选键是 SJ和ST, 因为S,J，T都出现在候选键中，所以大家都是主属性,不存在非主属性 所以不存在非主属性部分依赖的情况，满足2NF 3.因为不存在非主属性，所以不存在非主属性对候选键的传递依赖，满足3NF 4.因为F = {T->J，SJ->T}， 所以每个依赖的决定因素为T和SJ，但候选键为SJ和ST，所以T不包含任一个候选码，不满足BCNF.
            • 第四范式
              • 4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖 注意:如果只考虑函数依赖,关系模式最高的规范化程度是BCNF;如果考虑多值依赖, 关系模式最高的规范化程度是4NF。
        • 模式分解
          • 保持函数依赖分解
            • 例1: 有关系模式R (A,B,C),F={A→B,B→C},将其拆分为:R1(A,B),R2(B,C) 是否保持函数依赖。 是的，因为拆解前后是等价的 例2: 有关系模式R(A,B,C),F={A→B,B→C,A→C},将其拆分为: R1(A,B),R2(B,C),是否保持函数依赖。 不是，拆分后不等价，A->C的依赖拆没了 例3: 有关系模式R(A,B,C),F={A→B,B→C,A->C},将其拆分为:R1(A,B), R2(A,C),是否保持函数依赖。 不是，拆分后不等价，B->C的依赖拆没了 例4: 有关系模式R(A,B,C,D,E),F={A→B,D→E},将其拆分为:R1(A,B C),R2(D,E),是否保持函数依赖。 是的
          • 无损分解
            • 什么是有损,什么又是无损? 有损:不能还原。 无损:可以还原。 无损联接分解:指将一个关系模式分解成若干个关系模式后,通过自然联接 和投影等运算仍能还原到原来的关系模式 例子： 有关系模式:成绩(学号,姓名,课程号,课程名,分数) 函数依赖:学号→姓名,课程号→课程名,(学号,课程号)→分数 若将其分解为: 成绩(学号,课程号,分数) 学生(学号,姓名) 课程(课程号,课程名) 请思考该分解是否为无损分解? 成绩和学生做自然连接，为{学号，课程号，分数，姓名} 由于有:课程号->课程名,所以: 成绩(学号,课程号,分数,姓名,课程名) 为无损分解
            • 表格法还原
              • 将一个具有函数依赖:学号→姓名,课程号→课程名,(学号,课程号)→分 数的关系模式:成绩(学号,姓名,课程号,课程名,分数),分解为:成绩(学号, 课程号,分数);学生(学号,姓名);课程(课程号,课程名)。 初始表如下:  先画一个初始表，所有属性写为列名，分级后的关系模式作为行名，对包含关系进行画√。 以学号为例，同一列出现多个√的为同名属性列， 以学号为决定因素的函数依赖为学号→姓名，可以看到它在学生表中保留下来了，所以成绩表中的姓名可以还原画√。  从上图中可以看出,第1行已全部为√,因此本次R分解是无损分解
            • 公式法还原
              • 格式法只适用于分解为两个关系模式的情况  如上分析看P1为无损，P2为有损
      • 并发控制
        • 事务的ACID特性
          • 原子性
            • 原子性(Atomicity)是指事务包含的所有操作要么全部成功,要 么全部失败回滚。这些操作是一个整体,不能部分地完成。
          • 一致性
            • 一致性(Consistency)是指事务必须使数据库从一个一致性状态 变换到另一个一致性状态,也就是说一个事务执行之前和执行之后 都必须处于一致性状态。 比如转账操作，A转出500给B
          • 隔离性
            • 隔离性(Isolation)是指一个事务的执行不能被其他事务干扰,即 个事务内部的操作及使用的数据对并发的其他事务是隔离的。 A给B转了500， A也给D转了500,这两个事务互相不能被影响
          • 持续性
            • 持久性(Durability,永久性)是指一个事务一旦被提交了,那么 对数据库中的数据的改变就是永久性的,无论发送何种故障,都不 应对其有任何影响。
        • 并发产生的问题
          • 丢失更新
            • 两个事务操作同一个数据进行修改写入， T2对T1会进行覆盖，这时会发生T1丢失更新 
          • "脏"数据的读出
            •  T1 改数据后回滚，导致T2读出脏数据
          • 不可重复读问题
            •  T1连续读两次，结果不同
        • 封锁协议
          • 
          • 一级封锁协议
            • 一级封锁协议。事务T在修改数据R之前必须先对其加X锁（写锁）,直到事事务结束才释 放。可防止丢失修改 
          • 二级封锁协议
            • 二级封锁协议。一级封锁协议加上事务T在读取数据R（读取）之前先对其加S锁（读锁）,读完 后即可释放S锁。可防止丢失修改,还可防止读"脏"数据 
          • 三级封锁协议
            • 三级封锁协议。一级封锁协议加上事务T在读取数据R之前先对其加S锁,直到 事务结束才释放。可防止丢失修改、防止读"脏"数据与防止数据(不可)重复读 
          • 两段锁协议
            • 两段锁协议。可串行化的。可能发生死锁 两阶段锁协议是实现事务隔离性的常 见方案,该协议通过定义锁的增长和收缩两个 阶段约束事务的加锁和解锁过程,能够保证事 务的串行化执行,但由于事务不能一次得到所 有需要的锁,因此该协议会可能会导致死锁。
        • 日志
          • 日志用于数据库恢复机制 基于日志的延迟修改技术(deferred-modification technique)的设计 与恢复过程。 该技术通过在日志中记录所有对数据库的修改操作,将一个事务的所有写操作 延迟到事务提交后才执行,日志中需要记录"事务开始"和"事务提交"时间, 还需要记录数据项被事务修改后的新值,无需记录数据项被事务修改前的原始值。 当系统发生故障时,如果某个事务已经开始,但没有提交,则该事务对数据项的修改尚未体现在数据 库中,因此无需做任何恢复动作。
    • 数据库新技术
      • 主要是用来考察案例
      • 数据库的安全性
        • 用户标识和鉴定
          • 最外层的安全保护措施,可以使用用户帐户、口令及随机数检验等方式
        • 存取控制
          • 对用户进行授权,包括操作类型(如查找、插入、删除、修改等动 作)和数据对象(主要是数据范围)的权限。(Grant和Revoke)
        • 密码存储和传输
          • 对远程终端信息用密码传输
        • 视图的保护
          • 对视图进行授权
        • 审计
          • 使用一个专用文件或数据库,自动将用户对数据库的所有操作记录下来
      • 分布式数据库
        • 
        • 特点
          • 数据独立性。除了数据的逻辑独立性与物理独立性外,还有数据分布独立性(分布透明性)。 集中与自治共享结合的控制结构。各局部的DBMS可以独立地管 理局部数据库,具有自治的功能。同时,系统又设有集中控制机 制,协调各局部DBMS的工作,执行全局应用。 适当增加数据冗余度。在不同的场地存储同一数据的多个副本, 可以提高系统的可靠性和可用性,同时也能提高系统性能。 (提高系统的可用性,即当系统中某个节点发生故障时,因为数据 有其他副本在非故障场地上,对其他所有场地来说,数据仍然是可 用的,从而保证数据的完备性。 全局的一致性、可串行性和可恢复性。
        • 两阶段提交协议
          • 表决阶段和执行阶段是分布式数据库的两阶段提交协议。 区别如下概念： 加锁阶段和解锁阶段也称为扩展阶段和收缩阶段,是传统集中式数据库的两阶段提交协议。 获取阶段和运行阶段是与开发数据库应用过程相关的阶段。
        • 分布模式
          • 分布透明性
            • 分片透明性: 分不分片,用户感受不到 分片透明是指用户或应用程序不需要知道逻辑 上访问的表具体是怎么分块存储的。 位置透明性: 数据存放在哪里,用户不用管 局部数据模型透明性(逻辑透明): 用户不用关心局部数据模型 用户或应用程序无须知道局部场地使用的是哪种数据模型。 复制透明： 复制透明是指采用复制技术的分布方法,用户不需要知 道数据是复制到哪些节点,如何复制的
          • 分布式数据库管理系统-组成
            • LDBMS GDBMS 全局数据字典 通信管理(CM)
          • 分布式数据库管理系统-结构
            • 全局控制集中的DDBMS 全局控制分散的DDBMS 全局控制部分分散的DDBMS
        • 分片模式
          • 分片
            • 
            • 水平分片
            • 垂直分片
            • 混合分片
      • 数据库备份与恢复技术
        • 数据备份
          • 
          • 冷备份
            • 冷备份也称为静态备份,是将数据库正常关闭,在停止状态下,将数据库的文件 全部备份(复制)下来。
          • 热备份
            • 热备份也称为动态备份,是利用备份软件,在数据库正常运行的状态下,将数据 库中的数据文件备份出来。
          • 备份量维度划分
            • 完全备份
              • 备份所有数据
            • 差量备份
              • 仅备份上一次完全备份之后变化的数据
            • 增量备份
              • 备份上一次备份之后变化的数据
        • 故障与恢复
          •  撤销事务(UNDO):故障发生时未完成的事务,放入Undo撤销。 重做事务(REDO):故障发生前已提交的事务,放入Redo重做。
      • 反规范化技术
        •  逆规范化是把拆分的表重新合并起来 
        • 反规范化优缺点
          • 反规范化的优点: 连接操作少,检索快、统计快;需要查的表减少,检索容易,并易出错 缺点： 
      • NoSQL
        • NoSQL(Not-onlySQL):不仅仅只是SQL,泛指非关系型的数据库。 
        • 各种类型的NoSQL数据库
          • 有可能考简单选择题 
      • 数据库性能优化
        • 
      • 联邦数据库系统
        • 联邦数据库系统(FDBS)是一个彼此协作却又相互独立的成员数 据库(CDBS)的集合,它将成员数据库系统按不同程度进行集成, 对该系统整体提供控制和协同操作的软件叫做联邦数据库管理系统 (FDBMS) 
      • 数据仓库
        • 数据仓库是一个面向主题的、集成的、非易失的、且随时间变化的数据集合,用于支 持管理决策。
        • 体系结构
          •  1.数据源:是数据仓库系统的基础,是整个系 统的数据源泉。 2.数据的存储与管理:是整个数据仓库系统的 核心。 3.OLAP(联机分析处理)服务器:对分析需 要的数据进行有效集成,按多维模型组织,以 便进行多角度、多层次的分析,并发现趋势。 4.前端工具:主要包括各种报表工具、查询工 具、数据分析工具、数据挖掘工具以及各种基 于数据仓库或数据集市的应用开发工具。
      • 大数据
        • 特点:大量化、多样化、价值密度低、快速化。 大数据和传统数据的比较如下:  要处理大数据,一般使用集群平台,称为大数据处理系统,其特证为: 高度可扩展性、高性能、高度容错、支持异构环境、较短的分析延迟、易用且 开放的接口、较低成本、向下兼容性。
      • SQL语言
        • 创建表create table; 指定主键primarykey(); 指定外键foreignkey(); 修改表alter table; 删除表drop table; 索引index,视图view; 数据库查询select...from...where; 分组查询groupby,分组时要注意select后的列名要适应分组,having为分组查询附加条件:select sno,avg(score)from student groupby sno having(avg(score)>60) 更名运算as:selectsnoas"学号"from t1 字符串匹配like,%匹配多个字符串,匹配任意一个字符串:select * from t1 where sname like 'a_' 数据库插入insert into...values(): insert into t1 values('a',66) 数据库删除delete from...where:deletet1 wheresno=4 数据库修改update...set...where: update t1 set sname='aa' wheresno=3 排序order by,默认为升序,降序要加关键字DESC:select*from t1 order by sno desc SELECT [ALL|DISTINCT]<目标列表达式>[,<目标列表达式>]... FROM<表名或视图名>[,表名或视图名>] [WHERE<条件表达式>] [GROUPBY<列名1>[HAVING<条件表达式>]] [ORDER BY<列名2>[ASC|DESC]...]
      • 数据挖掘
        • 数据挖掘是从数据库的大量数据中揭示出隐含的、先前未知的并有潜在价值的信息的非平凡过程,数据挖掘的任务有关联分析、聚类分析、分类分析、异常分析、特异群组分析和演变分析等等。 并非所有的信息发现任务都被视为数据挖掘。 例如,使用数据库管理系统查找个别的记录,或通过因特网的搜索引擎查找特 定的Web页面,则是信息检索领域的任务。 虽然这些任务是重要的,可能涉及使用复杂的算 法和数据结构,但是它们主要依赖传统的计算 机科学技术和数据的明显特征来创建索引结 构,从而有效地组织和检索信息。
  • 4计算机网络
    • 历年真题考情:本章节每年考3-5分左右。 第二版更新:但本章节超纲率也有50%,在 第二版教材改版后的2.5节,同样没有增加 以往真题超纲的内容,比较坑人了,还是一 些简单的介绍性内容,可能这个编写架构的 人默认大家既然考高级,都具备基本的计算 机知识能力吧。没有体系化的内容,也只能 通过我们每年直播讲题来补充了。主要改变 在于网络概述和协议。 
    • OSI七层模型
      • 
    • TCP/IP协议族
      • 网络协议三要素:语法、语义、时序。其中语法部分规定传输数据的格式,语义部分规定所要完 成的功能,时序部分规定执行各种操作的条件、顺序关系等。 TCP 4层，OSI 7层模型 
      • DHCP与DNS
      • TCP与UDP
        • 
      • 协议端口号对照表
        •  HTTP协议默认服务端口是80 HTTPS协议默认服务端口号是443
      • 域名服务器DNS
        • 可提供域名服务的包括本地缓存、本地域名服务器、权限域名服务器、顶级域名服务器以及根域名服务器。 主机名解析的查找顺序是,先查找客户端本地缓存,如果没有成功边,则向DNS服务器发出解析请求。 根域名服务器是最高层次的域名服务器。每一个根域名服务器都要存有所有顶级域名服务器的IP地址和域名。
    • IP地址
      • 地址表示
      • 子网划分
    • 网络规划与设计
      • 
      • 逻辑网络设计
        • 利用需求分析和现有网络体系分析的结果来设计逻辑网络结构,量最后得到一份逻辑网络设计文档,输出内容包括以下几点: 逻辑网络设计图 IP地址方案 安全方案 招聘和培训网络员工的具体说明 软硬件、服务、员工和培训的费用初步估计
      • 物理网络设计
        • 物理网络设计是对逻辑网络设计的物理实现,通过对设备的具体物理分布、运行 环境等确定,确保网络的物理连接符合逻辑连接的要求。输出如下内容: 网络物理结构图和布线方案 设备和部件的详细列表清单 软硬件和安装费用的估算 安装日程表,详细说明服务的时间以及期限 安装后的测试计划 用户的培训计划
      • 局域网层次结构
        • 大型局域网通常划分为核心层、汇聚层和接入层,其中 核心层在逻辑上只有一个,它连接多个分布层交换机,通常是一个园区中连接多个建筑物的总交换机的核心网络设备; 汇聚层定义的网络的访问策略; 接入层提供局域网络接入功能,可以使用集线器代替交换机。
    • 网络接入
      • 3G与4G标准
    • 网络存储技术
      • 开放系统的直连式存储(Direct-Attached Storage,DAS)在服务器上外挂了一组大容量硬盘,存储设备与服务器主机之间采用SCSI通道连接,带宽为10MB/s、20MB/s、40MB/s和80MB/s等。直连式存储直接将存储设备连接到服务器上,这种方法难以扩展存储容量,而且不支持数据容错借功能,当服务器出现异常时会造成数据丢失。 网络接入存储(Network Attached Storage,NAS)是将存储设备连接到现有的网络上,提供数据存储和文件访问服务的设备。NAS服务器是在专用主机上安装简化了的瘦操作系统(只具有访问权限控制、数据保护和恢复等功能)的文件服务器。NAS服务器内置了与网络连接所需要的协议,可以直接联网,具有权限的用户都可以通过网络访问NAS服务器中的文件。 存储区域网络(Storage Area Network,SAN)是一种连接存储设备和存储管理子系统的专用网络,专门提供数据存储和管理功能。SAN可以被看作是负责数据传输的后端网约,而前端网络(或称为数据网络)则负责正常的TCP/IP传输。也可以把SAN看作是通过特定的互连方式连接的若干台存储服务器组成的单独的数据网络,提供企业级的数据存储服务。
      • RAID 5
        • RAID5是一种存储性能、数据安全和存储成本兼顾的存储解决方案。这种方案中数据信息与校验信息的配比是N+1方案,即N份数据,1份校验信息,所以用3块容量为80G的硬盘实际数据容量为160G。 当用3盘不同容量的盘做RAID5时,会以最小容量的盘为准,所以2块80G和1块40G的盘视为3块40G的盘,所以容量为80G。
    • 网络需求分析
      • 网络需求分析包括网络总体需求分析、综合布线需求分析、网络可用性与可靠性分析、网络安全性需求分析,此外还需要进行工程造价估算。
  • 5数字与经济管理
  • 6系统配置与性能评价
  • 7知识产权与标准化
  • 8企业信息化战略与实施
    •  信息化战略:信息化战略体系、信息系统战略规划 企业信息化:企业资源计划ERP、客户关系管理CRM、供应链管理SOM、决策支持系统DSS、知识管理、 企业门户、企业应用集成、电子商务 选择题考3-4分 案例不考 论文考到过,主要其中在企业集成方面,包括四个点:企业应用集成、应用集成数据交换、企业集 成平台、企业信息集成。常考的是1和3. 本章节内容全都是纯理论记忆的,都是考书上原话,没有什么好讲的,因此把解析补充详细直接放 出来,带大家一起分析记忆一下。
    • 信息系统概述
      • 信息系统是由计算机硬件、网络和通信设备、计算机软件、信息资源、信息用户和规章制度组成 的以处理信息流为目的的人机一体化系统。 信息系统的5个基本功能:输入、存储、处理、输出和控制。 信息系统的性质影响着系统开发者和系统用户的知识需求。"以计算机为基础"要求系统设计者 必须具备计算机及其在信息处理中的应用知识。"人机交互"要求系统设计者还需要了解人作为系 统组成部分的能力以及人作为信息使用者的各种行为。 诺兰模型:信息系统进化的阶段模型。将计算机信息系统的发展道路划分为6个阶段: 1.初始阶段:计算机刚进入企业时只作为办公设备使用,应用非常少。一般仅用于财务部门 2.传播阶段:企业对计算机有了一定了解,想利用计算机解决工作中的问题,比如进行更多的数据 处理,给管理工作和业务带来便利。会大幅度增加软件投入,盲目投入产生问题,效率低 3.控制阶段:从整体上控制计算机信息系统的发展,在客观上要求组织协调、解决数据共享问题。 信息系统呈现单点、分散的特点,系统和资源利用率不高。是计算机管理变为数据管理的关键。 4.集成阶段:在控制的基础上,企业开始重新进行规划设计,建立基础数据库,并建成统一的信息 管理系统。使人、财、物等资源信息能够在企业集成共享,更有效地地利用现有的IT系统和资源。 5.数据管理阶段:企业高层意识到信息战略的重要,信息成为企业的重要资源,企业的信息化建设 也真正进入到数据处理阶段。使用统一平台,各部门、各系统基基本实现资源整合和信息共享。 6.成熟阶段:信息系统已经可以满足企业各个层次的需求,从简单的事务处理到支持高效管理的决 策。企业真正把IT与管理过程结合起来,将组织内部、外部的资源充分整合和利用
      • 信息系统分类
        • 信息系统的分类(低级到高级) 1.业务(数据)处理系统(TPS/DPS):随着企业业务需求的增长和技术条件的发展,人们逐步将计 算机应用于企业局部业务(数据)的管理,如财会管理、销售管理、物资管理和生产管理等,即计 算机应用发展到对企业的局部事务的管理。 2.管理信息系统(MIS):由人和计算机等组成的,能进行管理信息的收集、传输、存储、加工、维 护和使用的系统。形成了对企业全局性的、整体性的计算机应用。能提供企业各级领导从事管理需 要的信息,但其收集信息的范围还更多地侧重于企业内部。 3.决策支持系统(DSS):帮助决策者利用数据和模型去解决半结构化决策问题和非结构化决策问题 的交互式系统。服务于高层决策的管理信息系统,按功能可分为为专用DSS、DSS工具和DSS生成器。 4.专家系统(ES):一个智能计算机程序系统,其内部含有某个领域我具有专家水平的大量知识与经 验,能够利用人类专家的知识和解决问题的方法来处理该领域的问题烦。 5.办公自动化系统(OAS):人机结合的综合性的办公事务管理系统,或称办公事务处理系统。该 系统将当代各种先进技术和设备应用于办公室的办公活动中,使办公活动动实现科学化、自动化,以 达到改善工作环境、最大限度地提高办公事务工作质量和工作效率。
        • 专家系统
          • 基于知识的专家系统简称为专家系统,是人工智能的一个重要分支。专家系统的能力来自于它所 拥有的专家知识,知识的表示及推理的方法则提供了应用的机理。 专家系统不同于传统的应用程序和其他类型的人工智能问题求解程序。 主要表现在以下5个方面。 (1)专家系统属于人工智能范畴,其求解的问题是半结构化或非结构化问题 (2)专家系统模拟的是人类专家在问题领域的推理,而不是模拟问题领域本身。 (3)专家系统由3个要素组成:描述问题状态的综合数据库、存放启发式经验知识的知识库和对知识库的知识进行推理的推理机。三要素分别对应数据级,知识库级和控制级三级知识,而传统应用程序只有数据和程序两级结构。 (4)专家系统处理的问题是实际的问题,而不是纯学术的问题。李铁城 (5)从求解手段来看,专家系统专用性强,通用性差。 人工智能(AI)旨在利用机械、电子、光电或生物器件等制造的装置或或机器模仿人类的智能。 AI研究的重点放在开发具有智能行为的计算机系统上,智能行为表现出以下5个特点。 (1)从过去的事件或情形中汲取经验,并将从经验中得到的知识应用于新的环境和场景。 (2)具有在缺乏重要信息时解决问题的能力。 (3)具有处理和操纵各种符号、理解形象化图片(图像)的能力。 (4)想象力和创造力。 (5)善于启发。 人工智能是一个极为广泛的领域, AI的主要分支有专家系统,机器人技术视觉系统、自然语言 处理、学习系统和神经网络等 专家系统的组成： 1.知识库。用来存放系统求解实际问题的领域知识。知识库中的的知识可分成两类:一类为事实性知 识:另一类是启发性知识。 2.综合数据库。是专家系统在执行与推理过程中用以存放所需要和产生的各种种信息的工作存储器, 因此,综合数据库又叫动态知识库,其内容在系统运行过程中是不断变化的。相应地把专家系统的 知识库称为静态知识库。二者一起构成完整知识库。 3.推理机。推理机和知识库一起构成专家系统的核心。推理机也被称为控制吉构或规则解释器,通 常包括推理机制和控制策略,是一组用来控制系统的运行、执行各种任务、根据知识库进行各种搜 索和推理的程序模块。 4.知识获取。主要有两方面功能:一是知识的编辑和求精;二是知识自学习。 5.解释程序。是面向用户服务的,负责解答用户提出的各种问题。 6.人机接口。通常包括两部分:一部分是专家系统与用户的接口;另一部分是专家系统与领域专家 和知识工程师的接口 
      • 信息化需求
        • 一般说来,信息化需求包含三个层次,即战略需求、运作需求和技术需求。 (1)战略需求。组织信息化的目标是提升组织的竞争能力。为组织的可持续发展提供一个支持环境。 从某种意义上来说,信息化对组织不仅仅是服务的手段和实现现有战略的辅助工具;信息化可以把组 织战略提升到一个新的水平,为组织带来新的发展契机。特别:是对于企业,信息化战略是企业竞争的 基础。 (2)运作需求。组织信息化的运作需求是组织信息化需求非常重要且关键的一环,它包含三方面的 内容:一是实现信息化战略目标的需要;二是运作策略的需要三是人才培养的需要。 (3)技术需求。由于系统开发时间过长等问题在信息技术层面上对系统的完善、升级、集成和整合 提出了需求。也有的组织,原来基本上没有大型的信息系统项目,有的也只是一些单机应用,这样的 组织的信息化需求,一般是从头开发新的系统。
    • 信息系统生命周期
      • 信息系统的生命周期(产生、开发、运行、消亡) 1.信息系统的产生阶段,也是信息系统的概念阶段或者是信息系统的的需求分析阶段。这一阶段又分 为两个过程,一是概念的产生过程,即根据企业经营管理的需要,提出建设信息系统的初步想法; 二是需求分析过程,即对企业信息系统的需求进行深入地调研和和分析,并形成需求分析报告。 2.信息系统的开发阶段:最重要、关键的阶段。包括总体规划、系统分析、系统设计、系统实施和 系统验收这5个阶段。 (1)总体规划阶段。信息系统总体规划是系统开发的起始阶段,它的基础是需求分析。作用主要 有:指明信息系统在企业经营战略中的作用和地位;指导信息系统的开发;优化配置和利用各种资 源,包括内部资源和外部资源。总体规划产出包括信息系统的开发目标、信息系统的总体架构、信 息系统的组织结构和管理流程、信息系统的实施计划、信息系统的技术规范等。 (2)系统分析阶段。目标是为系统设计阶段提供系统的逻辑模型。以企业的业务流程分析为基础, 规划即将建设的信息系统的基本架构,它是企业的管理流程和信息流程的交汇点。内容主要包括组 织结构及功能分析、业务流程分析、数据和数据流程分析、系统初步方案等 (3)系统设计阶段。根据系统分析的结果,设计出信息系统的实施方案。主要内容包括系统架构 设计、数据库设计、处理流程设计、功能模块设计、安全控制方案设计、系统组织和队伍设计、系 统管理流程设计等。 (4)系统实施阶段。将设计阶段的结果在计算机和网络上具体实现,也就是将设计文本变成能在 计算机上运行的软件系统。由于系统实施阶段是对以前的全部工作的检验,因此,系统实施阶段用 户的参与特别重要。系统实施阶段以后,用户逐步变为系统的主导:地位 (5)系统验收阶段。信息系统实施阶段结束以后,系统就要进入试运行。通过试运行,系统性能 的优劣以及是否做到了用户友好等问题都会暴露在用户面前,这时就进入了系统验收阶段 3.信息系统的运行阶段:当信息系统通过验收,正式移交给用户以后,系统就进入了运行阶段。系 统维护包括即排错性维护、适应性维护、完善性维护和预防性维护。 4.信息系统的消亡阶段:在信息系统建设的初期企业就应当注意系统的消亡条件和时机,以及由此 而花费的成本。 信息系统建设的原则:高层管理人员介入原则、用户参与开发原则、自顶向下规划原则、工程化 原则、其他原则(创新性,整体性,发展性,经济性等)。
    • 信息系统的开发方法
      • 结构化方法
        • 1.结构化方法。结构是指系统内各个组成要素之间的相互联系、相互作用用的框架。结构化方法是一 种传统的信息系统开发方法,由结构化分析(SA)、结构化设计(SD)和结构化程序设计(SP) 部分有机组合而成,其精髓是自顶向下、逐步求精和模块化设计。 结构化方法的主要特点： (1)开发目标清晰化。结构化方法的系统开发遵循"用户第一"的原则。 (2)开发工作阶段化。每个阶段工作完成后,要根据阶段工作目标和要求进行审查,这使各阶段 工作有条不紊地进行,便于项目管理与控制。 (3)开发文档规范化。结构化方法每个阶段工作完成后,要按照要求完成相应的文档,以保证各 个工作阶段的衔接与系统维护工作的遍历。 (4)设计方法结构化。在系统分析与设计时,从整体和全局考虑,自顶向下地分解;在系统实现 时,根据设计的要求,先编写各个具体的功能模块,然后自底向上逐步实现整个系统。 结构化方法的不足和局限： (1)开发周期长:按顺序经历各个阶段,直到实施阶段结束后,用户才能使用系统。 (2)难以适应需求变化:不适用于需求不明确或经常变更的项目。 (3)很少考虑数据结构:结构化方法是一种面向数据流的开发方法,很少考虑数据结构。 结构化方法一般利用图形表达用户需求, 常用工具有数据流图、数据字典、结构化语言、判定表以及判定树等。
      • 原型法
        • 原型化方法。 也称为快速原型法,或者简称为原型法。它是一种根据用户初步需求,利用系统开发工具,快速地建立一个系统模型展示给用户,在此基础上与用户交流,最终实现用户需求的信息系统快速开发的方法。 按是否实现功能分类:分为水平原型(行为原型,功能的导航)、垂直原型(结构化原型,实现 了部分功能)。 按最终结果分类:分为抛弃式原型、演化式原型。 原型法可以使系统开发的周期缩短、成本和风险降低、速度加快,获得较高的综合开发效益。 原型法是以用户为中心来开发系统的,用户参与的程度大大提高,开发的系统符合用户的需求, 因而增加了用户的满意度,提高了系统开发的成功率。 由于用户参与了系统开发的全过程,对系统的功能和结构容易理解和接受,有利于系统的移交, 有利于系统的运行与维护。 原型法的不足之处:开发的环境要求高。管理水平要求高。 由以上的分析可以看出,原型法的优点主要在于能更有效地确认用户需求。从直观上来看,原型 法适用于那些需求不明确的系统开发。事实上,对于分析层面难度大、技术层面难度不大的系统适合于原型开发。
      • 面向对象的开发方法
        • 3.面向对象方法。 面向对象(OO)方法认为,客观世界是由各种对象组成的,任何事物都是对象 每一个对象都有自己的运动规律和内部状态,都属于某个对象类,是该对象类的一个元素。复杂的 对象可由相对简单的各种对象以某种方式而构成,不同对象的组合合及相互作用就构成了系统 使用00方法构造的系统具有更好的复用性,其关键在于建立一个全面、合理、统一的模型 00方法也划分阶段,但其中的系统分析、系统设计和系统实现三个阶段之间已经没有"缝隙"。 也就是说,这三个阶段的界限变得不明确,某项工作既可以在前一个阶段完成,也可以在后一个阶 段完成;前一个阶段工作做得不够细,在后一个阶段可以补充。 面向对象方法可以普遍适用于各类信息系统的开发。 面向对象方法的不足之处:必须依靠一定的面向对象技术支持,在大型项目的开发上具有一定的 局限性,不能涉足系统分析以前的开发环节。 当前,一些大型信息系统的开发,通常是将结构化方法和00方法结合起来。首先,使用结构化方 法进行自顶向下的整体划分;然后,自底向上地采用00方法进行开发。因此,结构化方法和00方 法仍是两种在系统开发领域中相互依存的、不可替代的方法。
      • 面向服务的方法
        • 面向服务的方法。面向服务(Service-Oriented,SO）的方法:进一步将接口的定义与实现进行解 耦,则催生了服务和面向服务(Service-Oriented,SO)的开发方法。 从应用的角度来看,组织内部、组织之间各种应用系统的互相通信和互操作性直接影响着组织对 信息的掌握程度和处理速度。如何使信息系统快速响应需求与环境变化,提高系统可复用性、信息 资源共享和系统之间的互操作性,成为影响信息化建设效率的关健问题,而so的思维方式恰好满足 了这种需求。
    • 信息系统战略规划
      • 管理科学的核心就是应用科学的方法实施管理,按照市场发展的的要求,对企业现有的管理流程重新整合,从作为管理核心的财务、资金管理,向技术、物资、人力资源的管理,并并延伸到企业技术创新、工艺设计、产品设计、生产制造过程的管理,进而扩展到客户关系管理、供应链的管理乃至发展到电子商务,形成企业内部向外部扩散的全方位管理。 企业信息化注重企业经营管理方面的信息分析和研究,信息系统所蕴含的管理思想也可帮助企业建立更为科学规范的管理运作体系,提供准确及时的管理决策信息。 信息化战略从企业战略出发,服务于企业战略,同时又影响和促进企业战略。企业战略与信息化战略集成的主要方法有BITA(Business-ITAlignment,业务与IT整合)和EITA(EEnterprise IT Architecture,企业IT架构)。 (1)业务与IT整合。BITA是一种以业务为导向的、全面的IT管理里咨询实施方法论。从制订企业战略、建立(或改进)企业组织结构和业务流程,到进行IT管理和制订过渡计划(transsition plan),使IT能够更好地为企业战略和目标服务。BITA适用于信息系统不能满足当前管理中的业务需要,业务和IT之间总是有不一致的地方。BITA的主要步骤是:评估和分析企业当前业务和IT不一致的领域,整理出企业的业务远景和未来战略,建立业务模型,提出达到未来目标的转变过程建议和初步计划,以及执行计划。 (2)企业IT架构。EITA分析企业战略,帮助企业制订IT战略,并对其投资决策进行指导。在技术、信息系统、信息、IT组织和IT流程方面,帮助企业建立IT的原则规范、模式和标准,指出IT需要改进的方面并帮助制订行动计划。EITA适用于现有信息系统和IT基础架构不一致、不兼容和缺乏统一的整体管理的企业。
      • 战略规划三个阶段
        • 考点在三方面： 1.分哪第三个阶段，每个阶段是干嘛的 2.每个阶段有哪些方法 3.每个方法的关键内容 一个企业信息系统的战略规划可分为下面三个阶段:  第一阶段:以数据处理为核心,围绕职能部门需求 企业系统规划法BSP:自上而下地识别企业目标、企业过程和数据,然后对数据进行分析,自下而上地设计信息系统。重视数据的创建和使用,以数据的创建和使用归类,提供一个信息系统规划,建立CU矩阵(创建使用矩阵)。 关键成功因素法CSF:重视关键因素,每个企业在某阶段都有关键因素,抓住关键信息。 战略集合转化法SST:将企业的战略信息(环境、目标等)收集起来,当成一个信息集合",并且转换为信息系统的战略信息,全方位的注重企业的战略信息。 第二阶段:以企业内部MIS(管理信息系统)为核心,围绕企业整体需求 战略数据规划法SDP:强调建立企业模型和主题数据库(重点和关键,是面向业务主题,整个企业的),数据类基本上是稳定的,而业务和流程是多变的。 信息工程法IE:第一次提出以工程的方法来建立信息系统,信息工程是面向企业计算机信息系统建设,以数据为中心的开发方法。信息工程方法认为,与企业的信息系统密切相关的三要素是:企业的各种信息、企业的业务过程和企业采用的信息技术。信息工程自上而下地将整个信息系统的开发过程划分为四个实施阶段,分别是信息规划阶段、业务领域分析阶段、系统设计阶段和系统构建阶段。 战略栅格法SG:建立一个2*2的矩阵,每个矩阵元素代表过程对数据类的创建和使用等。栅格即划分矩阵。 第三阶段:综合考虑企业内外环境,以集成为核心,围绕企业战略需求 价值链分析法VCA:将所有对企业有影响的信息作为一个个活动,其都有可能对企业造成增值,分析其中对企业增值最大的信息。 战略一致性模型SAM:保证企业战略和信息系统战略要一致。
      • 信息资源管理
        • 信息资源与人力、物力、财力和自然资源一样,都是企业的重要资源,因此,应该像管理其他资源那样管理信息资源;做好信息资源管理(Information Resource Management, IFRM)的目的是通过企业内外信息流的畅通和信息资源的有效利用,来提高企业的效益和竞争力。 IRM包括数据资源管理和信息处理管理,前者强调对数据的控制(维护和安全),后者则关心企业管理人员如何获取和处理信息(流程和方法)且强调企业中信息资源的重要性。 信息资源分类的主要功能是用于IRM,而IRM的起点和基础是是建立信息资源目录。信息资源只有科学地建立了目录,才能使信息资源得到快速、及时的存储、处理、检索和使用。信息资源分类是IRM中最为复杂的工作之一,应当遵循简洁、独立和可操作的原则。 对信息资源的分类一般从以了下三个维度来展开: (1)从管理维度分类。 (2)从信息来源维度分类。 (3)从应用主题维度分类。
      • DSS
        • 决策支持系统 DSS是一个由语言系统、知识系统和问题处理系统3个互相关联的部分组成的,基于计算机的系统。 DSS应具有的特征是: 数据和模型是DSS的主要资源。 DSS用来支援用户做决策而不是代替用户做决策。 DSS主要用于解决半结构化及非结构化问题。 DSS的作用在于提高决策的有效性而不是提高决策的效率。
    • 企业资源规划 ERP
      • ERP系统:主要管理公司的各种资源,负责处理进销存、供应链、生产计划MPS、MRP计算、生产订单、管理会计,是财务数据的强力支撑。 企业资源规划是指建立在信息技术基础上,以系统化的管理思想,为企业提供决策和运营手段的 管理平台。ERP系统是将企业所有资源进行集成整合,并进行全面、一体化管理的信息系统 企业有三大资源:物流(物流管理)、资金流(财务管理)、信息流(生产控制管理)、现在一般 认为人力资源(人力资源管理)是企业第四大资源。 ERP功能: 财会管理:会计核算、财务管理。 生产控制管理:主生产计划、物料需求计划、能力需求计划、车间控制、制造标准。 物流管理:销售管理、库存控制、采购管理。 人力资源管理:人力资源规划的辅助决策、招聘管理、工资核算、工二时管理、差旅核算。 ERP的五个层次 生产计划大纲是根据经营计划的生产自标制定的,是对企业经营计划的细化,用以描述企业在可用 资源的条件下,在一定时期中的产量计划。 主生产计划是对企业生产计划大纲的细化,说明在一定时期内的如下下计划:生产什么,生产多少和 什么时候交货。 物料需求计划是对主生产计划的各个项目所需的全部制造件和全部采购件的网络支持计划和时间进 度计划。 能力需求计划是对物料需求计划所需能力进行核算的一种计划管理方法。旨在通过分析比较MRP的 需求和企业现有生产能力,及早发现能力的瓶颈所在。 车间作业计划是在MRP所产生的加工制造订单(即自制零部件生产计划)的基础上,按照交货期的 前后和生产优先级选择原则以及车间的生产资源情况(如设备、人员、物粉斗的可用性、加工能力的大 小等),将零部件的生产计划以订单的形式下达给适当的车间1،
      • ERP结构
        • ERP的结构 1)生产预测。市场需求是企业生存的基础,在ERP中首先需要对市场进行较准确的预测。预测主要 用于计划,在ERP的5个层次的计划中,前3个层次计划,即经营计划、生产计划大纲和主生产计划 的编制都离不开预测。 2)销售管理(计划)。销售管理主要是针对企业的销售部门的相关业务进行管理 
    • 客户关系管理CRM
      • 客户关系管理CRM 以客户为中心,提高客户满意度、增加客户的忠诚度。 CRM是一个集成化的信息管理系统,它存储了企业现有和潜在客户的信息,并且对这些信息进行自动的处理从而产生更人性化的市场管理策略。 CRM涵盖的要素主要有: 第一,CRM以信息技术为手段,但是CRM绝不仅仅是某种信息技术的应用,它更是一种以客户为中心的商业策略,CRM注重的是与客户的交流,企业的经营是以客户为中心,而不是传统的以产品或以市场为中心。 第二,CRM在注重提高客户的满意度的同时,一定要把帮助企业提高获取利润的能力作为重要指标。 第三,CRM的实施要求企业对其业务功能进行重新设计,并对工作流程进行重组(BPR),将业务的中心转移到客户,同时要针对不同的客户群体有重点地采取不同的策略。 CRM系统的主要模块包括销售自动化、营销自动化、客户服务与支持、商业智能。 一个有效的CRM解决方案应该具备以下要素: 畅通有效的客户交流渠道(触发中心)。 对所获信息进行有效分析(挖掘中心) CRM必须能与ERP很好地集成。
      • CRM的功能
        • CRM的功能 客户服务:是CRM的关键内容,对客户提供的服务,可以提高客户忠诚度。 市场营销:包括商机产生、商机获取和管理、商业活动管理和电话营销等;销售人员与潜在客户的互动行为、将潜在客户发展为真正客户并保持其忠诚度是使企业赢利的核心因素。 共享的客户资料库:是企业的一种重要信息资源,将市场营销和客户服务连接起来。也是CRM的基础和依托。 分析能力:CRM的一个重要方面在于它具有使客户价值最大化的分析所能力。对上述获取的资料库进行分析。 市场营销和客户服务是CRM的支柱性功能。
    • 供应链管理SCM
    • 典型信息系统架构模型
      • 政府信息化与电子政务
        • 电子政务实质上是对现有的、工业时代形成的政府形态的一种改造,即利用信息技术和其他相关 技术,将其管理和服务职能进行集成,在网络上实现政府组织结构口工作流程优化重组,超越时间、 空间与部门分隔的制约,实现公务、政务、商务、事务的一体化管理与运行。电子政务主要包括 个组成部分: (1)政府部门内部的电子化和网络化办公。 (2)政府部门之间通过计算机网络进行的信息共享和实时通信。 (3)政府部门通过网络与居民之间进行的双向信息交流。 电子政务的内容:G2G、G2B、G2C、B2G、C2G。 电子政务在世界范围内的发展有2个主要的特征:第1个特征是以互联网为基础设施,构造和发展 电子政务。第2个特征是,就电子政务的内涵而言,更强调政府服务功能的发挥和完善,包括政府 对企业、对居民的服务以及政府各部门之间的相互服务。 电子政务的发展大致经历了4个阶段:起步阶段、政府与用户单向互动、政府与用户双向互动、 网上事务处理。 电子政务的应用领域:面向社会、政府部门之间、政府部门内部的各类应用系统、涉及政府部门 内部的各类核心数据的应用系统、政府电子化采购、电子社区。
      • 企业信息化与电子商务
        • 企业信息化和电子商务 企业信息化就是企业利用现代信息技术,通过信息资源的深入开发和广泛利用,实现企业生产过 程的自动化、管理方式的网络化、决策支持的智能化和商务运营的电子化,不断提高生产、经营、 管理、决策的效率和水平,进而提高企业经济效益和企业竞争力的过程。 企业信息化的具体目标是优化企业业务活动,使之更加有效,它的根本目的在于提高企业竞争能 力,使得企业具有平稳和有效的运作能力,对紧急情况和机会做出快速反应,为企业内外部用户提 供有价值的信息。包括技术创新、管理创新和制度创新。 企业信息化一定要建立在企业战略规划基础之上,以企业战略规划为基础建立的的企业管理模式是 建立企业战略数据模型的依据。 企业信息化就是技术和业务的融合。需要从3个层面来实现。 (1)企业战略的层面。必须对企业目前的业务策略和未来的发展方向作入分析。达到战略上的 融合。 (2)业务运作层面。针对企业所确定的业务战略,通过分析获得实现这些目标的关键驱动力和实 现这些目标的关键流程。 (3)管理运作层面。虽然这一层面从价值链的角度上来说,是属于辅助流程,但它对企业日常管 理的科学性、高效性是非常重要的。除了提出应用功能的需求外,还必须给出泪应的信息技术体系, 这些将确保管理模式和组织架构适应信息化的需要。
        • 企业数字化转型
          • 业数字化转型的五个发展阶段依次是： 1.初始级发展阶段:处于该发展阶段的组织,在单一职能范围内初步开展了信息(数字)技术应用, 但尚未有效发挥信息(数字)技术对主营业务的支持作用。 2.单元级发展阶段:处于该阶段的组织,在主要或若干主营业务单一职能范围内开展了(新一代) 信息技术应用,提升相关单项业务的运行规范性和效率。 3.流程级发展阶段:处于该阶段的组织,在业务线范围内,通过流程级数字化和传感网级网络化, 以流程为驱动,实现主营业务关键业务流程及关键业务与设备设施、软硬件、行为活动等要素间的集 成优化。 4.网络级发展阶段:处于该阶段的组织,在全组织(企业)范围内,通过组织(企业)级数字化和产 业互联网级网络化,推动组织(企业)内全要素、全过程互联互通和动态优化,实现以数据为驱动的 业务模式创新。 5.生态级发展阶段:处于该阶段的组织,在生态组织范围内,通过生态级数字化和泛在物联网级网络 化,推动与生态合作伙伴间资源、业务、能力等要素的开放共享和协同合作,共同培育智能驱动型的 数字新业务。
        • 电子商务系统模式
          • 电子商务系统主要包括三种模式,其中企业对消费者(B2C)模式是指消费者直接和组织进行交易;企业对企业(B2B)模式是指交易的参与者都是组织;消费者对消费者(C2C)模式是指消费者直接向其他消费者销售。除此之外,也可以把企业对政府的一些商务活动简称为B2G(Business to Government,企业对政府),例如,政府采购企业的产品等;把个人对企业的一些商务活动简称为C2B(CustomertoBusiness,消费者对企业),例如,IT行业中的独立咨询师为企业提供咨询和顾问服务。由此,还可以衍生出C2G(Customer to Government,消费者对政府)等,只不过这些都是非主流的模式。
        • 企业信息化方法
          • (1)业务流程重构方法。对企业的组织结构和工作方法进进行"彻底的、根本性的"重新设计。 (2)核心业务应用方法。任何一家企业,要想在市场竞争的环境中生存发展,都必须有自己的核 心业务。围绕核心业务应用计算机技术和网络技术是很多企业信息化成功的秘诀 (3)信息系统建设方法。对大多数企业来说,建设信息系统是企业信息化的重点和关键。因此 信息系统建设成了最具普遍意义的企业信息化方法。 (4)主题数据库方法。主题数据库就是面向企业业务主题的数据库,也就是面向企业的核心业务 的数据库。 (5)资源管理方法。目前,流行的企业信息化的资源管理方法有很多,最常见的有企业资源计划 (ERP)、供应链管理(SCM)等。 (6)人力资本投资方法。人力资本与人力资源的主要区别是人力资本理论把一部分企业的优秀员 工看作是一种资本,能够取得投资收益。人力资本投资方法特别适用于那些依靠智力和知识而生存 的企业。
    • 企业门户
    • 企业集成
      • 在论文中考过多次。
      • 企业应用集成
        • 企业应用集成EAI,可以适用于大多数要实施电子商务的企业,以及企业之间的应用集成。 解决信息孤岛问题，比如一个公司内有财务系统，采购系统等，每个系统不互通，账号也独立。所以需要引入企业应用集成。 有以下几种类型： (1)表示集成:即界面集成,是最原始的集成,黑盒集成。:将多个信息系统的 界面集成在一起,统一入口,为用户提供一个看上去统一,但是由多个系统组 成的应用系统的集成,例如桌面。  (2)数据集成:白盒集成,把不同来源、格式、特点性质的数据在逻辑上或者 物理上有机的集中,从而为企业提供全面的数据共享。如数据仓库。 (3)控制集成(功能集成、应用集成):黑盒集成,业务逻辑层次的集成,可 以借助于远程过程调用或远程方法调用、面向消息的中间件等技术,将多个应 用系统功能进行绑定,使之像一个实时运行的系统一样接受信息输入和产生数 据输出,实现多个系统功能的叠加。如钉钉。  (4)业务流程集成:即过程集成，最彻底的、综合的集成,这种集成超越了数据和系统,由一系列基于标准的、统一数据格式的工作流组成。当进行业务流程集成时,企业必须对各种业务信息的交换进行定义、授权和管管理,以便于改进操作、减少成本、提高响应速度。 它包括应用集成、B2B集成、自动化业务流程管理、人工流程管理、企业门户,以及对所有应用系统和流程的管理和监控等。 如电子购物网站-第三方支付平台-银行-物流等流程集成。
        • 应用集成数据交换方式
          • 应用集成数据交换方式 共享数据库:在应用集成时,让多个应用系统通过直接共享数据库的方式,来进行数据交换,实时性强,可以频繁交互,属于同步方式;但是安全性、并发控制、死锁等问题突出。 消息传递:消息是软件对象之间进行交互和通信时所使用的一种数据结构,可以独立于软件平台而存在,适用于数据量小、但要求频繁、立即、可靠、异步地数据交换场合。 文件传输:是指在进行数据交换时,直接将数据文件传送到相应位置,让目标系统直接读取数据,可以一次性传送大量信息,但不适合频繁进行数据传送。适用于数据量大、交换频度小、即时性要求低的情况。
      • 企业集成平台
        • 企业集成平台是支持企业集成的支撑环境,包括硬件、软件、软件工具和系统,通过集成各种企业应用软 件形成企业集成系统。由于硬件环境和应用软件的多样性,1企业信息系统的功能和环境都非常复杂, 因此,为了能够较好地满足企业的应用需求,作为企业集成系统支持环境的集成平台,其基本功能主 要有: (1)通信服务 它提供分布环境下透明的同步/异步通信服务功能,使用户和应用程序无需关心具体 的操作系统和应用程序所处的网络物理位置,而以透明的函数调用或对象服务方式完成它们所需的通 信服务要求。 (2)信息集成服务 它为应用提供透明的信息访问服务,通过实现异种数据库系统之间数据的交换、 互操作、分布数据管理和共享信息模型定义(或共享信息数据库的建立),使集成平台上运行的应用、 服务或用户端能够以一致的语义和接口实现对数据(数据库、数据文件、应用交互信息)的访问与控 制。 (3)应用集成服务 它通过高层应用编程接口来实现对相应应用程序的访问,这些高层应用编程接口 包含在不同的适配器或代理中,它们被用来连接不同的应应用程序 (4)二次开发工具是集成平台提供的一组帮助用户开发特定应用程序(如实现数据转换的适配器或 应用封装服务等)的支持工具,其目的是简化用户在企业集成平台实施过程中(特定应用程序接口) 的开发工作。 (5)平台运行管理工具它是企业集成平台的运行管理和控制模块,负责企业集成平台系统的静态和 动态配置、集成平台应用运行管理和维护、事件管理和出错管管理等。
      • 企业信息集成
        • 企业信息集成分为企业内部的信息集成和外部的信息集成两个方瑞 1.按集成内容,企业内部的信息集成一般可分为以下四个方面: (1)技术平台的集成 系统底层的体系结构、软件、硬件以及异构网络的特殊需 求首先必须得到集成。 (2)数据的集成 为了完成应用集成和业务流程集成,需要解决数据和数据库的 集成问题。数据集成的目的是实现不同系统的数据交流与共享,是进行其他更 进一步集成的基础。 (3)应用系统的集成 是实现不同系统之间的互操作,使得不同应用系统之可能 够实现数据和方法的共享。它为进一步的过程集成打下了基础。 (4)业务过程的集成 使得在不同应用系统中的流程能够无缝连接,实现流程的 协调运作和流程信息的充分共享。 2.企业外部的信息集成主要包括以下两个部分: (1)通过门户网站和互联网实现公众、社会团体、社会和客户的互动,实现企 业内外部信息资源的有效交流和集成; (2)通过与合作伙伴信息系统的对接,建立动态的企业联盟,发展基于竞争合 作机制的虚拟企业,重塑企业的战略模式和竞争优势。
    • 业务流程分析
      • 业务流程重组最早由美国的Michael Hammer和Jame Champy提出,在20世纪90年代达到了全盛的一种管理思想。强调以业务流程为改造对象和中心、以关心客户的需求和满意度为目标、对现有的业务流程进行根本的再思考和彻底的再设计,利用先进的制造技术、信息技术以及现代的管理手段、最大限度地实现技术上的功能集成和管理上的职能重建,以打破传统的职能型组织结构,建立全新的过程型组织结构,从而实现企业经营在成本、质量、服务和速度等方面的巨大改善。
    • 系统工程与信息系统
      • 系统工程是在上个世纪中后期发展起来的一门新兴学科。它最早的产生于20世纪40年代的美国,时至今日,系统工程已经成为现代社会高速发展不可或缺的一部分。系统工程的诞证生让自然科学和社会科学中有关的思想、理论和方法根据总体协调的需要联系起来,综合应用,并利用现代电子计算机,对系统的结构、要素、信息和反馈等进行分析,以达到最优规划、最优设计、最优管理和最优控制等目的。 霍尔三维结构是由逻辑维、时间维和知识维组成的立体空间结构。
  • 9软件工程
    • 软件工程考点汇总： 软件工程基础:生命周期,能力成熟度模型,开发模型,开发方法,软件产品线,逆向工程 系统分析和需求工程:需求分类、需求获取、分析、定义、验证、管理。 系统设计:处理流程设计、系统设计、人机界面设计。 测试基础:测试原则、测试阶段、测试用例设计、调试、软件度量。 系统运行和维护:系统转换、系统维护、系统评价 202311选择题考察: 范围内:mccabe度量法、灰盒测试、喷泉模型、敏捷开发、需求分析工具(petri网)、PDCA、 自动化测试适用类型、变更管理顺序、单元测试 要补充:web新型测试(A/B测试、链接测试)、sysml需求图、W模型、M2M(智能化机器+硬件 +网络+中间件+应用)、D0178(指导、目标、活动、证居)、NPU 2024年05月考察:敏捷开发、RUP4+1视图、可靠性生建模不属于需求分析、净室软件工程、静态 测试、灰盒测试、系统测试依据、软件测试判断 202311案例考察:UML用例图、SysML需求图等。 202405案例考察:序列图的三种消息,序列图填空,序列图和协作图对比,序列图条件分支
    • 软件开发生命周期
      • 软件定义时期:包括可行性研究和详细需求分析过程,任务是确定软件开发工程必须完成的总目标,具体可分成问题定义、可行性研究、需求分析等。 软件开发时期:就是软件的设计与实现,可分成概要设计、详细设计、编码、测试等 软件运行和维护:就是把软件产品移交给用户使用。 软件系统工具通常可以按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。 软件开发工具:需求分析工具、设计工具、编码与排错工具、测试工具等。 软件维护工具:版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。 软件管理和软件支持工具:项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。
    • 软件开发方法
      • 
      • 原型法
        • 只用于需求阶段 根据用户和需求描述构建一个原型
        • 分类
          • 按功能分: 水平原型(界面)、垂直原型(复杂算法) 按最终结果分: 抛弃式原型、演化式原型
      • 结构化法
        • 自顶向下,逐步分解求严格分阶段,阶段产出标准化应变能力差 结构化分析与设计方法是一种面向数据流的传统软件开发方法,它以数据流为中心构建软件的分析 模型和设计模型。结构化分析(Structured Analysis,SA)、结构化设计(Structured Design,SD)和 结构化程序设计(Structured Programming Design,SPD)构成了完整的结构化方法 结构化方法的分析结果由以下几部分组成:一套分层的数据流图、一本数据词典、一组小说明(也称 加工逻辑说明)、补充材料。 结构化分析的步骤： 1分析业务情况,做出反映当前物理模型的数据流图; 2推导出等价的逻辑模型的DFD; 3设计新的逻辑系统,生成数据字典和基元描述; 4建立人机接口,提出可供选择的目标系统物理模型的DFD 5确定各种方案的成本和风险等级,据此对各种方案进行分析; 6选择一种方案; 7建立完整的需求规约。
      • 面向对象方法
        • 自底向上 阶段界限不明 更好应变、更好复用 符合人们的思维习惯
      • 面向服务的方法
        • 粗粒度、松耦合 标准化和构件化 抽象级别: 操作【低】->服务【中】->业务流程【高】
      • 形式化方法
        • 净室软件工程【受控污染级别的环境】 数学模型化 建好模型转成代码 所有东西均可证明/验证,而不是测试
      • 统一过程方法UP
      • 敏捷方法
    • 软件开发模型
      • 开发方法是一种理论化的开发方法，解决实际的开发问题 开发模型是采用了对应的开发方法所开发出来的一种通用的模型或模板，描述了软件开发的整体流程和策略，
      • 原型模型
        • 也称为快速原型模型 原型模型主要由原型开发阶段和目标软件开发阶段构成。 原型模型先是使用原型获取需求,需求获取到之后有可能抛弃掉原型,然后根据原型获得的需求进行目标软件的 开发。 原型是预期系统的一个可执行版本反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束,其目的是能快速、低成本地构建原型。 原型模型适合原型化的开发。
      • 瀑布模型SDLC
        • 瀑布模型可以说是最早使用的软件生存周期模型之一。 由于这个模型描述了软件生存的一些基本过程活动,所以它被称为软件生存周期模型。 这些活动从一个阶段到另一个阶段逐次下降,形式上很像瀑布。 瀑布模型的特点是因果关系紧密相连,前一个阶段工作的结果是后一 个阶段工作的输入。 适用于需求明确的场景 适合结构化开发 需求一旦搞错，后面全错 
      • 螺旋模型
        • 以原型为基础+瀑布模型 考虑了风险问题 特点是引入了风险分析  这个模型把整个软件开发流程分成多个阶段,每个阶段都由4部分组成,它们是: 1目标设定/指定计划。为该项目进行需求分析,定义和确定这一 个阶段的专门目标,指定对过程和产品的约 束,并且制订详细的管理计划。 2风险分析。 对可选方案进行风险识别和详细分析,制订解 决办法,采取有效的措施避免这些风险。 3开发和有效性验证。风险评估后,可以为系统选 择开发模型,并且进行原型开发,即开发软件 产品。 4评审。对项目进行评审,以确定是否 需要进入螺旋线的下一次回路,如果决定继 续,就要制订下一阶段计划。第一题答案为B
      • V模型
        • 
      • W模型
        • W模型： W模型是对V模型的一个重要改进,充分体现了尽早开展测试的原则,并将V模型中 以发现缺陷为目标上升为保证软件质量为目标。W模型和图所示 W模型实际上是两个V的叠加,一个V描述开发过程,另外一个V描述测试过程。但测试的起 始时机不再是编码结束之后,而是从需求分析时开始,且与两开发的每一个阶段活动同步进行。 
      • H模型
        • H模型:改进了W和V模型高度依赖于开发的瀑布模型的缺陷,其特征如图所示: 模型把测试活动从软件开发过程中独立出来,在软件过程的任何一个时间点上,只要测试 条件满足即开展测试。测试的流程与其他流程是并行的。H模型比W模型更好的地方是能够兼顾 测试的效率和灵活性,适合于各种规模及类型的软件项目。 
      • 喷泉模型
        • 面向对象的模型，适合于面向对象的开发
      • 快速应用开发模型RAD
        •  快速应用开发利用了基本构件开发方法的思 想,大量采用现成的构件进行系统的开发,所 以速度很快。但这种开发,要求系统模块化程 度高,因为只有这样,才能更好利用现有的构 件。
      • 统一过程RUP
        • RUP(Rational Unified Process) 属于迭代增量开发 一个开发周期包括初始、细化、构建和交付四个阶段,每次通过这四个阶段就会产生一代软件。 RUP的三个核心特点是: 以架构为中心,用例驱动,增量与迭代。 我们在规划迭代的时候,一般将关键业务需求、风险比较大的需求优先安排开发实现。  9个核心工作流(按照软件开发时间过程去记)： 1、商业建模(Business Modeling):商业建模工作流描述了如何为新的目标组织开发一个构想,并基于这个构想在商业用例模型和商业对象模型中定义组织的过程、角色和责任。 2、需求(Requirements):需求工作流的目标是描述系统应该做什么,并使开发人员和用户就这一描述达成共识。为了达到该目标,要对需要的功能和约束进行提取、组织、文档化;最重要的是理解系统所解决问题的定义和范围。 3、分析和设计(Analysis&Design):分析和设计工作流将需求转化成未来系统的设计,为系统开发一个健壮的结构并调整设计使其与实现环境相匹配,优化其性能。 4、实现(Implementation):实现工作流的目的包括以层次化的子系统形式定义代码的组织结构;以组件的形式(源文件、二进制文件、可执行文件)实现类和对象;将开发出的组件作为单元进行测试以及集成由单个开发者(或小组)所产生的结果,使其成为可执行的系统。 5、测试(Test):测试工作流要验证对象间的交互作用,验证软件中所有组件的正确集成,检验所有的需求已被正确的实现,识别并确认缺陷在软件部署之前被提出并处理。 6、部署(Deployment):部署工作流的目的是成功的生成版本并将软件分发给最终用户。 7、配置和变更管理(Configuration&Change Management):配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。 8、项目管理(ProjectManagement):软件项目管理平衡各种可能产生冲突的目标、管理风险,克服各种约束并成功交付使用户满意的产品。其目标包括:为项目的管理提供框架,为计划、人员配备、执行和监控项目提供实用的准则,为管理风险提供框架等。 9、环境(Environment):环境工作流的目的是向软件开发组织提供软件开发环境,包括过程和工具。
      • 敏捷方法
        • 发展历程 
        • 四大价值观
          • 沟通 【加强面对面沟通】 简单 【不过度设计】 反馈 【及时反馈】 勇气 【接受变更的勇气】
        • 12条过程实践规则(最佳实践)
          • 简单设计 测试驱动 代码重构 结对编程 持续集成 现场客户 发行版本小型化 系统隐喻 代码集体所有制 规划策略 规范代码 40小时工作机制
        • 细分的模型
          • 极限编程(XP):一些对费用控制严格的公司中的使用,非常有效。 水晶方法:探索了用最少纪律约束而仍能成功的方法,从而在产出效率与易于运作上达到一种平衡。 开放式源码:程序开发人员在地域上分布很广【其他方法强调集中办公】。 SCRUM:明确定义了的可重复的方法过程。 功用驱动开发方法(FDD):编程开发人员分成两类:首席程序员和"类"程序员。 ASD方法:其核心是三个非线性的、重叠的开发阶段:猜测、合作与学习。
          • Scrum开发模型
            •  完整产品列表中挑选本轮需要迭代开发的内容。
          • 极限编程
            • XP(极限编程)的思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化,XP无需开开发人员在软件开始初期做出很多的文档。 XP提倡测试先行,为了将以后出现bug的几率降到最低。极限编程是一种重要要的敏捷开发方法,包含策划、设计、编码和测试4个框架活动的规则和实践。 极限编程中使用的重要技术是重构,既包括设计技术的重构,也包括构建技术的重构; 极限编程提倡在基本设计完成后,团队不应该直接开始编码而是开发一系列用于检测本次发布的包括所有故事(story)的单元测试; 极限编程活动中的关键概念之一是"结对编程",推荐两个人面对同一台计算机共同开发代码; 极限编程过程中建立的单元测试应当使用一个可以自动实施的框架,支持代码修改后即时的回归测试策略。
      • 基于构件的开发模型
        • 构件组装模型CBSD
          • 基于构件的开发模型利用模块化方法将整个系统模块化,并在一定构件模型的支持下复用构 件库中的一个或多个软件构件,通过组合手段高效率、高质量地构造应用软件系统的过程。 基于构件的开发模型由软件的需求分析定义、体系结构设计、构件库建立、应用软件构建以及测试和发布5个阶段组成。  构件组装模型通过重用来提高软件的可靠性和易维护性,程序在进行修改时产生较少的副作用。 构件组装模型的优点如下: (1)构件的自包容性让系统的扩展变得更加容易。 (2)设计良好的构件更容易被重用,降低软件开发成本。 (3)构件的粒度较整个系统更小,因此安排开发任 务更加灵活,可以将开发团队分成若干组,并 行地独立开发构件。
        • 逻辑构件模型
          • 逻辑构件模型用功能包描述系统的抽象设计,用接口描述每个服务集合,以及功能之间如何交互以满足用户需求,它作为系统的设计蓝图以保证系统提供适当的功能。
        • 物理构件模型
          • 物理构件模型用技术设施产品、硬件分布和拓扑结构、以及用于 绑定的网络和通信协议描述系统的物理设计,这种架构用于了解系统的性 能、吞吐率等许多非功能性属性。
    • 逆向工程
      •  逆向工程是设计的恢复过程。 与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。 (1)重构(restructuring)。重构是指在同一抽象级别上转换系统描述形式。 (2)设计恢复(design recovery)。设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。 (3)再工程(re-engineering)。再工程是指在逆向工程所获得信息的基础上,修改或重构已有的系统,产生系统的一个新版本。再工程是对现有系统的重新开发过程,包括逆向工程、新需求的考虑过程和正向工程三个步骤。 它不仅能从已存在的程序中重新获得设计信息,而且还能使用用这些信息来重构现有系统,以改进它的综合质量。在利用再工程重构现有系统的同时,一般会增加新的需求,包括增增加新的功能和改善系统的性能。 (4)正向工程(forwardengineering)。正向工程是指不仅从现有系统中恢复设计信息,而且使用该信息去改变或重构现有系统,以改善其整体质量。
    • 需求工程
      •  软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。 
      • 需求开发
        • 需求开发的结果应该有项目视图和范围文档、 用例文档和SRS,以及相关的分析模型。经评 审批准,这些文档就定义了开发工作的需求基 线。本题第一空描述的是需求基线,选择A选 项。 这个基线在用户和开发人员之间就构成了软件 需求的一个约定,它是需求开发和需求管理之 间的桥梁。第二空选择C选项。
        • 需求获取
          • 
          • JPR
            • JRP联合需求计划(JointRequiremen t Planning,JRP) 是一种相对来说成本较高的需求获取方法 (而非需求分析与验证的方法),但也是十分 有效的一种。它通过联合各个关键用户代表、 系统分析师、开发团队代表一起,通过有组织 的会议来讨论需求。通常该会议的参与人数为 6~18人,召开时间为1~5小时。 JRP的主要意图是收集需求,而不是对需求进 行分析和验证。实施JRP时应把握以下主要原则: (1)在JRP实施之前,应制订详细的议程,并严格遵照议程进行。 (2)按照既定的时间安排进行。 (3)尽量完整地记录会议期间的内容。 (4)在讨论期间尽量避免使用专业术语。 (5)充分运用解决冲突的技能。 (6)会议期间应设置充分的间歇时间。 (7)鼓励团队取得一致意见。 (8)保证参加JRP的所有人员能够遵守事先约定的规则。
        • 需求分析
          •  数据流图也叫DFD 在结构化分析方法中,用(数据流图)表示功能模型,用(状态转换图)表示行为模型，用E-R图表示数据模型。 另外需求分析还会用到petri网图
        • 需求定义
          • 严格定义法和原型法最大的区别是前者认为所有需求都需要预先搞清楚 
        • 需求验证
          • 
      • 需求管理
        • 版本控制
        • 需求跟踪
          • 需求跟踪是将单个需求和其他系统元素之间的 依赖关系和逻辑联系建立跟踪,这些元素包括 各种类型的需求、业务规则、系统架构和构 件、源代码、测试用例,以及帮助文件等。 需求跟踪一般采用需求跟踪矩阵做跟进工作, 跟踪矩阵将从需求源头一直跟进到最终的软件 产品。 
        • 状态跟踪
          • 需求状态
            • 
        • 变更管理
          •  变更分析阶段需要CCB 会议决策是否进行变更
          • 工具
            • 自动化工具能够帮助变更控制过程更 有效地运作,这类工具应具有的特征： 1可以定义变更请求中的数据项; 2可以定义变更请求生命周期的状态转换模型; 3可以强制实施状态转换模型,以便只有授权用户可以做出允许的状态变更; 4可以记录每一个状态变更的日期和做出这一变更的人; 5可以定义当提议者提交新请求或请求状态被更新时,哪些人可以自动接收电子邮件通知; 6可以生成标准的和定制的报告和图表。
      • 面向对象OOA
        • 对象 类(实体类、边界类、控制类) 抽象 封装 继承与泛化 多态 接口 消息 组件 模式和复用
        • 类
          • 实体类映射需求中的每个实体,实体类保存需要存储在永久 存储体中的信息,例如,在线教育平台系统可以提取出学员 类和课程类,它们都属于实体类。 控制类是用于控制用例工作的类,一般是由动宾结构的短语 ("动词+名词"或"名词+动词")转化来的名词,例如, 用例"身份验证"可以对应于一个控制类"身份验证器", 它提供了与身份验证相关的所有操作。 边界类用于封装在用例内、外流动的信息或数据流。边界类 位于系统与外界的交接处,包括所有窗体、报表、打印机和 扫描仪等硬件的接口,以及与其他系统的接口。
        • UML
          • UML(统一建模语言):是一种可视化的建模语言,而非程序设计语言,支 持从需求分析开始的软件开发的全过程。 与UML1.x不同,为了更清楚地表达UML的结构,从UML2开始,整个UML规范被划分为基础结构和上层结构两个 相对独立的部分,基础结构是UML的元模型,它定义了构造UMI模型的各种基本元素;而上层结构则定义了面向 建模用户的各种UML模型的语法、语义和表示。 重点在构造块  事物： 
          • UML4+1视图
            • 视图是图的抽象，视图提出的一些概念由图来实现 
            • 逻辑视图
              • (1)逻辑视图。逻辑视图也称为设计视图,它表示了设 计模型中在架构方面具有重要意义的部分,即类、子系 统、包和用例实现的子集。
            • 进程视图
              • (2)进程视图。进程视图是可执行线程和进程作为活动 类的建模,它是逻辑视图的一次执行实例,描述了并发 与同步结构。
            • 实现视图
              • (3)实现视图。实现视图对组成基于系统的物理代码的 文件和构件进行建模。
            • 部署视图
              • (4)部署视图。部署视图把构件部署到一组物理节点上, 表示软件到硬件的映射和分布结构。
            • 用例视图
              • (5)用例视图。用例视图是最基本的需求分析模型。
          • UML图
            • 
            • 静态图
              • 类图
                • 类图(class diagram):类图描述一组类、接口、协作和它们之间的关系。 元素包括： 类名，属性名，方法名
                • 多重度
                  • 1:表示一个集合中的一个对象对应另一个集合中一个对象。 0..*:表示一个集合中的一个对象对应另一个集合中的0个或多个对象。(可以不对应) 1..*:表示一个集合中的一个对象对应另一个集合中的一个或多个对象。(至少对应一个) *:表示一个集合中的一个对象对应另一个集合中的多个的对象。
                • 关系
                  •  区分聚合和组合： 聚合，比如汽车和轮子，汽车报废，轮子还可以用在其他车上。 组合，比如公司和部门，公司倒闭，部门也不存在了。
                • 类的三种类型
                  • 1.实体类。实体类映射需求中的每个实体,保存需要存储在永久存储体中的信息,例如,用户、商品等。 2.控制类。控制类是用于控制用例工作的类,用于对一个或几个个用例所特有的控制行为进行建模。例如,结算、备货等。 3.边界类。边界类用于封装在用例内、外流动的信息或数数据流。例如,浏览器、购物车等。
              • 对象图
                • 对象图和类图表现形式基本一样，只是它是对对象的描述， 对象图(object diagram):对象图描 述一组对象及它们之间的关系。对象图描述 了在类图中所建立的事物实例的静态快照。 
              • 构件图
                • 构件图(component diagram)。构件图描述一个封装的类和它的接口、端口,以及由内 嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部 件构建大的系统来说,构件图是很重要的。构件图是类图的变体，一个构件可能包含多个类。 
              • 包图
                • 包图,包的图标像是一个带标签的文件夹,包的基本思想是把把共同工作的元素放到一个文件 夹中。例:多个类或构件组成了一个子系统,就可以将它们放到一个包中。
              • 部署图
                • 部署图(deployment diagram)。部署图描述对运行时的处理节点及在其中生存的构件 的配置。部署图给出了架构的静态部署视图,通常一个节点包含一个或多个部署图。 
              • 制品图
              • 组合结构图
              • 用例图
                • 用例图描述一组用例、参与者及它们之间的关系。 用户角度描述系统功能; 参与者是外部触发因素; (包括用户、组织、外部系统,时间) 用例是功能单元。  关系包括: 包含关系、扩展关系、泛化关系
                • 用例建模流程
                  • 识别参与者(必须) 合并需求获得用例(必须) 细化用例描述(必须) 调整用例模型(可选)
                  • 细化用例描述示例(用例规约)
                    • 
                  • 参与者
                    • 真实的人
                      • 即用户，这一类是最常用的参与者
                    • 其他系统
                      • 在有的系统中，还需要建立与其他系统的接口。例如，汽车租赁系统可能需要与外部信用卡应用程序建立联系，这时外部信用卡应用系统就是一个参与者。
                    • 可运行的进程
                      • 例如时间，当经过一定时间触发系统中的某个事件时，时间就成了参与者。 或者温度也属于这个。
                    • 设备
                      • 如打印机
                  • 用例
                    • 用例是参与者完成的一系列操作
                • 关系
                  • 用例图有自己特有的三种关系 
                  • 包含关系
                    • 包含关系:其中这个提取出来的公共用例称为抽象用例,而把原始用例称为基本用例或基础用 例。当可以从两个或两个以上的用例中提取公共行为时,应该使用包含关系来表示它们。 
                  • 扩展关系
                    • 扩展关系:如果一个用例明显地混合了两种或两种以上的不同场景,即根据情况可能发生多种 分支（可做可不做的事情）,则可以将这个用例分为一个基本用例和一个或多个扩展用例,这样使描述可能更加清晰。
                  • 泛化关系
                    • 泛化关系:当多个用例共同拥有一种类似的结构和行为的时候,可以将它们的共性抽象成为父 用例,其他的用例作为泛化关系中的子用例。在用例的泛化关系系中,子用例是父用例的一种特殊形 式,子用例继承了父用例所有的结构、行为和关系。 
            • 动态图
              • 顺序图/时序图
                • 顺序图(sequence diagram,序列图)。顺序图是一种交互图(interaaction diagram),它强调对象之间消息发送的顺序,同时显示对象之间的交互。  三种消息类型： 同步 异步 返回
              • 通信图/协作图
                • 通信图(communication diagram)。通信图也是一种交互图,它强调对象之间存在的消息收发关系,而不专门突出这些消息发送的时间顺序。 
              • 状态图
                • 状态图(statediagram)是对类描述的补充。用于展现此类对象所具有的可能 状态,以及某些事件发生时其状态转移情况。 
              • 活动图
                • 活动图(activity diagram)是一种特殊的状态图。 活动图描述一个操作中要进行的各项活动的执行流程。 同时,也常被用来描述一个用例的处理流程或者某种交互流程。 活动图将进程或其他计算结构展示为计算内部一步步的控 制流和数据流。它强调对象间的控制流程。 活动图与状态图最大的区别在于里面是动作还是状态。 活动图与流程图的区别： 1.流程图是结构化里面的，活动图是面向对象的 2.活动图是可以表示并行执行的，如下两个粗横线之间的内容  泳道式活动图： 
              • 定时图
                • 定时图也叫计时图,也是一种交互图,用于展示交互过程中的真实时间信息,具 体描述对象状态变化的时间点以及维持特定状态的时间段。 
              • 交互概览图
          • UML关系
            • 依赖
              • 依赖:一个事物的语义依赖于另一个事物的语义的变化而变化 
            • 关联
              • 关联:是一种结构关系,描述了一组链,链是对象之间的连接。分为组合和 聚合,都是部分和整体的关系,其中组合事物之间关系更强。 
              • 聚合
                • 整体与部分生命周期不同。 
              • 组合
                • 整体与部分生命周期相同。 
            • 泛化
              • 泛化:一般与特殊的关系,子类和父类之间的关系 
            • 实现
              • 实现:一个类元指定了另一个类元保证执行的契约。 
      • SysML
        •  SysML是一种通用图形建模语言,用于指定,分析,设计和验证可能包括硬件,软件,信息,人员, 程序和设施的复杂系统。特别是,该语言提供了图形表示,其具有用于建模系统需求,行为,结构和 参数的语义基础,用于与其他工程分析模型集成。 系统建模语言(SysML)已成为基于模型的系统工程(MBSE)应用程序的事实上的标准系统架构建 模语言。SysML是UML2的一种方言,它扩展了软件密集型应用程序的统一建模语言(UML)标准,使 其可以成功应用于系统工程应用程序。 与UML相比,SysML为系统工程师提供了以下优于指定系统的优势: SysML比UML更好地表达系统工程语义(符号解释)。它减少了UML的软件偏差,并为需求管理和性 能分析添加了两种新的图表类型:需求图和参数图。 SysML比UML更小,更容易学习。由于SysML删除了许多以软件为中心和无偿的构造,因此在图表类 型(9对13)和总结构中测量的整体语言较小。 SysML模型管理构造支持模型,视图和视点的规范,这些规范在架构上与IEEE-Std-1471-2000 (IEEE推荐的软件密集型系统架构描述实践)保持一致。 SysML和UML间存在交集,即SysML语言中的部分图是和UML中的相应图是一致的,例如用例图。同 时,SysML也有基于UML扩展而来的图,例如活动图。另外,还有一部分图是SysML所特有的,这些图 与UML间没有关系,例如需求图。 需求图和参数图是SysML中新增的，其他都是从UML衍生过来或一样的。
        • 与UML对比
          • Sysml 描述的是模块之间的关联，UML 是面向对象的，它是对象之间的关联  
        • SysML规定了七个需求关系
          • 口诀 复复派细满验追
          • 复合关系
            • 复合需求可以包含需求层次结构中的子需求。复合需求可以声明系统应执行A和B,可以将其分解为系统应执行A和系统应进行B的子需求 
          • 复制关系
            • 6)复制关系:真正需要跨产品系列和项目重用需求。典型的方案是适用于产品和/或产品系列中重复使 用的项目和要求的法定法规或合同要求。 
          • 派生关系
            • 2)派生关系:派生的需求通常对应于系统层次结构下一级的需求。一个简单的例子是车辆加速需求, 该需求被分析以导出发动机动力等方面的需求  如上Engine Power就是派生出的需求
          • 细化关系
            • 3)细化关系:细化关系可用于描述如何使用模型元素或元素集进一步细化需求。例如,可以使用用例或活动图来细化基于文本的功能需求 
          • 满足关系
            • 4)满足关系:满足关系描述了设计或实现模型如何满足一个或多个需求。然后,系统建模者可以指定 旨在满足要求的系统设计元素 
          • 验证关系
            • 5)验证关系:验证关系定义了测试用例或其他模型元素如何验证需求。在SysML中,测试用例或其他元 素可以用作表示任何标准检验方法的通用机制,分析,演示或测试 
          • 追溯关系
            • 7)追溯关系:追溯关系提供了需求和任何其他模型元素之间的通用关系。追溯关系对于将需求与源文 档相关联或在规范树中的规范之间建立关系可能很有用。 
        • 需求图
          • 需求图:标准SysML需求包括用于指定其唯一性的标识符和需求文本两个属性,如图所示。其他属性 (例如,验证状态,优先级等)也可以由用户指定。 
        • 参数图
          • SysML参数图是一种特殊的内部块图。和 IBD一样,参数图会显示模块的内部结构, 但是其关注点在于值属性和约束参数之间 的绑定关系。因此,可以说,参数图和块 定义图提供了模块的互补视图。 
        • 模块定义图BDD
          • 
        • 内部模块图IBD
          • 
      • 软件能力成熟度模型CMM
        • 软件能力成熟度模型(CMM)在软件开发机 构中被广泛用来指导软件过程改进。该模型描 述了软件处理能力的5个成熟级别。为了达到 过程能力成熟度模型的第二级,组织机构必须 具有6个关键过程域KPA(Key Process Areas)。
      • CMMI
    • 软件系统需求建模
      •  过程有点像逆向工程
      • 结构化建模方法
        • 1、结构化建模方法 结构化建模方法是以过程为中心的技术,可用于分析一个现有的系统以及定义新系统的业务需求。结 构化建模方法所绘制的模型称为数据流图(DFD)。对于流程较为稳定的系统可考虑结构化建模方法。 功能建模一般采用DFD （数据流图） 行为建模一般采用状态转换图 数据建模一般采用ER图（实体关系图）
        • 功能建模
          • 功能建模是描述系统能做什么,即对 系统的功能、性能、接口和界面进行 定义。
        • 行为建模
          • 行为建模是描述系统在何时、何地、 由何角色、按什么业务规则去做,以 及做的步骤或流程,即对系统的操作 流程进行定义(怎么做)。
        • 数据建模
          • 实体-关系图（Entity-Relationship Diagram, ERD）是数据库建模和系统分析中广泛使用的图形化工具，它用于描述系统中实体（或对象）之间的关系。
      • 信息工程建模方法
        • 2、信息工程建模方法(或数据库建模方法) 信息工程建模方法是一种以数据为中心,但过程敏感的技术,它强调在分析和研究过程需求之前,首 先研究和分析数据需求。信息工程建模方法所创建的模型被科你为实体联系图(ERD)。主要用于数据 建模。
      • 面向对象建模方法
        • 3、面向对象建模方法 面向对象建模方法将"数据"和"过程"集成到被称为"对象"的结构中,消除了数据和过程的人为 分离现象。面向对象建模方法所创建的模型被称为对象模型。随着面向对象技术的不断发展和应用, 形成了面向对象的建模标准,即UML(统一建模语言)。UML定义了几种不同类型的模型图,这些 模型图以对象的形式共建一个信息系统或应用系统,是目目前比较常用的建模方法。
    • 系统设计
      • 
      • 人机界面设计
        • 黄金三法则
          • 
      • 软件设计
        • 软件设计包括体系结构设计、接口设计、数据设计和过程设计。 结构设计:定义软件系统各主要部件之间的关系。 数据设计:将模型转换成数据结构的定义。好的数据设计将已改善程序结构和模块划分,降低过程复杂性。 接口设计(人机界面设计):软件内部,软件和操作系统间以以及软件和人之间如何通信。 过程设计:系统结构部件转换成软件的过程描述。
        • 体系结构设计
        • 接口设计
        • 数据设计
        • 过程设计
      • 结构化设计
        • 概要设计
          • 概要设计【也叫外部设计】:功能需求分配给软件模块,确定每个模块的功能和调用关系,形成模块结构图
        • 详细设计
          • 详细设计【内部设计】:为每个具体任务选择适当的技术手段和处理方法
        • 结构化设计原则
          • 结构化设计原则: 模块独立(高内聚、低耦合) 保持模块的大小适中 多扇入,少扇出 深度和宽度均不宜过高
          • 内聚
            • 
          • 耦合
            •  软件设计过程中,可以用耦合和内聚两个定性标准来衡量模块的独立程度,耦合衡量不同模块 彼此间互相依赖的紧密程度,应采用以下设计原则： 尽量使用数据耦合、少用控制耦合和特征耦合（也叫标记耦合）、限制公共环境耦合的范围、完全不用内容耦合
        • 模块的四个要素
          • 模块的四个要素 (1)输入和输出。模块的输入来源和输出去向都是同一个调用者, 即一个模块从调用者那儿取得输入,进行加工后再把输出返回调 用者。 (2)处理功能。指模块把输入转换成输出所做的工作。 (3)内部数据。指仅供该模块本身引用的数据。 (4)程序代码。指用来实现模块功能的程序。
      • 面向对象设计
        • 基本过程
          • 
        • 设计原则
          • 单一职责原则
            • 设计目的单一的类
          • 开放-封闭原则
            • 对扩展开放,对修改封闭
          • 李氏(Liskov)替换原则
            • 子类可以替换父类
          • 依赖倒置原则
            • 要依赖于抽象,而不是具体实现;针对接口编程,不要针对实实现编程 依赖关系倒置： 高层提供接口，底层实现接口
          • 接口隔离原则
            • 使用多个专门的接口比使用单一的总接口要好 看做是单一原则的接口版本，这里主要是对接口而言的
          • 组合重用原则
            • 要尽量使用组合,而不是继承关系达到重用目的 因为继承是紧耦合，父类变子类要跟着变
          • 迪米特(Demeter)原则(最少知识原则)
            • :一个对象应当对其他对象有尽可能少的了解
        • 模式
          • 架构模式
            • 架构模式: 软件设计中的高层决策,例如C/S结构就属于架构模式,架构模式反映了 开发软件系统过程中所作的基本设计决策
          • 设计模式
            • 设计模式:主要关注软件系统的设计,与具体的实现语言无关  有下划线模式的表示既可以是类模式,也可以是对象模式;无下划线的表示只是对象模式。
            • 创建型模式:创建对象
              • 
              • 工厂方法(FactoryMethod)模式
                •  
              • 抽象工厂(Abstract Factory)模式
                •  
              • 原型(Prototype)模式
                • Prototype(原型模式):用原型实例指定创 建对象的类型,并且通过拷贝这个原型来创建 新的对象。允许对象在不了解创建对象的确切 类以及如何创建细节的情况下创建自定义对 象。 关键字： 克隆对象
              • 单例(Singleton)模式
                • Singleton(单例模式):保证一个类只有一 个实例,并提供一个访问它的全局访问点。
              • 构建器(Builder)模式
                •  
            • 结构型模式:更大的结构
              • 
              • 适配器(Adapter)模式
                • 
              • 桥接(Bridge)模式
                •  其中Web应用对应的是Abstraction角色， 主题样式对应的是Implementor角色 
              • 组合(Composite)模式
                •  
              • 装饰(Decorator)模式
                • 动态地给一个对象添加一些额外的职责。它提供了用子类 扩展功能的一个灵活的替代,比派生一个子类更加灵活。
              • 外观(Facade)模式
                • 解决操控便利性问题 比如智能家居，回家指令，会触发开灯，开窗帘，开空调等一系列指令 "包装器外观"架构模式解决操作系统的差异问 题。具体来说,服务端程序应该在包装器外观 的实例上调用需要的方法,然后将请求和请求 的参数发送给操作系统API函数,调用成功后 将结果返回。使用该模式提高了底层代码访问 的一致性,但降低了服务端程序的调用性能。
              • 享元(Flyweight)模式
              • 代理(Proxy)模式
                •  代理和中介的区别： 中介是将买方和卖方建立起联系，代理是代表买方和卖方进行全权谈判和交易。
            • 行为型模式:交互及职责分配
              •  
              • 职责链(Chain of Responsibility)模式
                •  请假1天找主管
              • 命令(Command)模式
              • 解释器(Interpreter)模式
                • 可以解析自定义的内容，如输入的自定义迷宫地图
              • 迭代器(Iterator)模式
                • 典型的如数据库操作
              • 中介者(Mediator)模式
                •  中介是中心节点
              • 备忘录(Memento)模式
              • 观察者(Observer)模式
                • 这个模式中有观察者有被观察者 被观察者发生变化，观察者立即发生变化。
              • 状态(State)模式
              • 策略(Strategy)模式
                • 
              • 模板方法(TemplateMethod)模式
              • 访问者(Visitor)模式
          • 惯用法
            • 惯用法: 是最低层的模式,关注软件系统的设计与实现,实现过过某种特定的程序 设计语言来描述构件与构件之间的关系。每种编程语言都有它自自己特定的模式,即语 言的惯用法。例如引用-计数就是C++语言中的一种惯用法
    • 测试与评审
      • 3~4分
      • 测试原则
        • 尽早、不断的进行测试 程序员避免测试自己设计的程序 既要选择有效、合理的数据,也要选择无效、不合理的数据 修改后应进行回归测试 尚未发现的错误数量与该程序已发现错误数成正比
      • 测试类型
        • 测试过程中程序执行状态为依据可分为静态测试 (Static Testing,ST) 和动态测试 (Dynamic Testing,DT); 以具体实现算法细节和系统内部结构的相 关情况为根据可分黑盒测试、白盒测试和灰盒测试3类； 从程序执行的方式来分类，可分为人 工测试 (Manual Testing,MT) 和自动化测试 (Automatic Testing,AT)。
        • 按测试阶段分
          • 
          • 单元测试
            • (1)单元测试:也称为模块测试,测试的对象是可独立编译或汇编的程序模块 软件构件或OO软件中的类(统称为模块),测试依据是软件详细设计说明书 模块测试：模块功能、性能、接口等
          • 集成测试
            • (2)集成测试:目的是检查模块之间,以及模块和已集成的软件之间的接口关 系,并验证已集成的软件是否符合设计要求。测试依据是软件概要设计文档 
            • 驱动模块和桩模块
              • 驱动模块是用来模拟被测试模块的上一级模块,相当于被测模块的主程序。它接收数据,将相关数据传送给被测模块,启用被测模块,并打印出相应的结果。 桩模块(Stub)是指模拟被测试的模块所调用的模块,而不是软件产品的组成的部分。 在集成测试前要为被测模块编制一些模拟其下级模块功能的"替身"模块,以代替被测模块的接口,接收或传递被测模块的数据,这些专供测试用的"假"模块称为被测模块的桩模块。 驱动模块用来调用被测模块,自顶向下的单元测试中不需要另外编写驱动模块 因为自顶向下，意味者把下层模块一个个拼进去，进行测试，驱动模块不变，桩模块需要修改增加。
          • 系统测试
            • 真实环境下,验证完整的软件配置项能否和系统正确连接 
            • 性能测试
              • 根据测试目的不同,性能测试主要包括压力测试、负载测试、并发测试和可靠性测试等。
              • 负载测试
              • 压力测试
              • 容量测试[并发测试]
              • 强度测试
          • 确认测试
            • 验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试、验收测试 内部测试,即软件开发组织内部按软件需求说明书进行测试。 Alpha测试,即用户在开发环境下进行测试。 Beta测试,即用户在实际使用环境下进行测试。 验收测试,针对软件需求说明书,在交付前以用户为主进行的测试。
          • 回归测试
            • 测试软件变更之后,变更部分的正确性对变更需求的符合性生
          • 其他测试
            • web测试
              • 对web 界面进行测试 (1) AB测试是为Web或App界面或流程制作两个(A/B)或多个(A/B/n)版本,在同一时间维度,分别让 组成成分相同(相似)的访客群组(目标人群)随机的访问这些版本,收集各群组的用户体验数据和业务 数据,最后分析、评估出最好版本,正式采用。 (2)Web测试是软件测试的一部分,是针对Web应用的一类测试。由于Web应用与用户直接相关,又通常 需要承受长时间的大量操作,因此Web项目的功能和性能都必必须经过可靠的验证。通过测试可以尽可 能地多发现浏览器端和服务器端程序中的错误并及时加以修正,以保证应用的质量。由于Web具有分 布、异构、并发和平台无关的特性,因而它的测试要比普通程序复杂得多,包含的测试种类也非常多。 (3链接测试。链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些未知地址 页面的主要手段。链接测试可分为3个方面。 首先,测试所有链接是否按指示的那样确实链接到了该链接的的页面; 其次,测试所链接的页面是否存在; 最后,保证Web应用系统上没有孤立的页面。 (4)表单测试。当用户通过表单提交信息的时候,都希望表单能正常工作。如果使用表单来进行在线 注册,要确保提交按钮能正常工作,当注册完成后应返回注册成功的消息。如果使用表单收集配送信 息,应确保程序能够正确处理这些数据,最后能让用户收到信息。要测试这些程序,需要验证服务器 是否能正确保存这些数据,而且后台运行的程序能否正确解释和使用这些信息。当用户使用表单进行 用户注册、登录、信息提交等操作时,必须测试提交操作的完整性,从而校验提交给服务器的信息的 正确性。如果使用默认值,还要检验默认值的正确性。 如果表单只能接受指定的某些值,则也要进行测试。
        • 按照测试中程序执行状态
          • 动态测试[计算机运行]
            • 动态测试:指在计算机上实际运行程序进行软件测试,一般采用白盒测试和 黑盒测试方法。 黑盒测试法:功能性测试,不了解软件代码结构,根据功能设计十用例,测试软 件功能。 白盒测试法:结构性测试,明确代码流程,根据代码逻辑设计用例,进行用例 覆盖。
          • 静态测试[纯人工]
            • 静态测试是指被测试程序不在机器上运行,而 采用人工检测和计算机辅助静态分析的手段对 程序进行检测。静态测试包括对文档的静态测 试和对代码的静态测试。对文档的静态测试主 要以检查单的形式进行,而对代码的静态测试 一般采用桌前检查(DeskChecking)、代码 审查和代码走查
            • 桌前检查
            • 代码审查
            • 代码走查
            • 静态分析
              • 静态分析(staticanalysis)是一种对代码的机 械性的、程式化的特性分析方法。静态分析一 般常用软件工具进行 静态分析包括五个阶段: 控制流分析阶段找出并突出显示那些带有多重出口或入口的循 环以及不可达到的代码段; 数据使用分析阶段突出程序中变量的使用情况; 接口分析阶段检查子程序和过程说明及它们使用的一致性; 信息流分析阶段找出输入变量和输出变量之间的 依赖关系; 路径分析阶段找出程序中所有可能的路径并画在此路径中执行的语句。
        • 按具体实现算法细节和系统内部结构
          • 黑盒测试法
            •  黑盒测试也称为功能测试
            • 黑盒测试用例的设计
              • 黑盒测试用例:将程序看做一个黑盒子,只知道输入输出,不知道内部代码" . 由此设计出测试用例,分为下面几类（前两种容易考）: 等价类划分:把所有的数据按照某种特性进行归类,而后在每类的数据里选 取一个即可。等价类测试用例的设计原则:设计一个新的测试用例,使其尽可 能多地覆盖尚未被覆盖的有效等价类,重复这一步,直到所有的有效等价类都 被覆盖为止;设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价 类,重复这一步,直到所有的无效等价类都被覆盖为止。 边界值划分:将每类的边界值作为测试用例,边界值一般为范围的两端值以 及在此范围之外的与此范围间隔最小的两个值,如年龄范围为0-150,边界值为 0,150, -1,151四个。 错误推测:没有固定的方法,凭经验而言,来推测有可能产生问题的地方, 作为测试用例进行测试。 因果图:由一个结果来反推原因的方法,具体结果具体分析,没有固定方法。
          • 白盒测试法
            •  白盒测试中测试强度最高的是路径覆盖
            • 白盒测试用例的设计
              • 白盒测试用例:知道程序的代码逻辑,按照程序的代码语句,来设计覆盖代码分 支的测试用例,覆盖级别从低至高分为下面几种: (1)语句覆盖SC:逻辑代码中的所有语句都要被执行一遍,覆盖层级最低,因 为执行了所有的语句,不代表执行了所有的条件判断。 (2)判定覆盖DC:逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次  (3)条件覆盖CC:针对每一个判断条件内的每一个独立条件都那要执行一遍真 和假。 (4)条件判定组合覆盖CDC:同时满足判定覆盖和条件覆盖。  (5)路径覆盖:逻辑代码中的所有可行路径都覆盖了,覆盖层级最高 
          • 灰盒测试法
            • 灰盒测试既考虑功能需求，又考虑了内部结构。
        • 按程序执行方式
          • 人工测试
          • 自动化测试
            • 自动化测试工具主要使用脚本技术来生成测试用例,测试脚本不仅可以在功能测试上模拟用户的操作, 比较分析,而且可以用在性能测试、负载测试上。虚拟用户可以同时进行相同的、不同的操作,给被 测软件施加足够的数据和操作,检查系统的响应速度和数据吞吐能力。 【线性脚本】是录制手工执行的测试用例得到的脚本,这种脚本包含所有的击键、移动、输入数据等, 所有录制的测试用例都可以得到完整的回放。 【结构化脚本】类似于结构化程序设计,具有各种逻辑结构、函数调用功能。 【共享脚本】共享脚本是指可以被多个测试用例使用的脚本,也允许其他脚本调用。共享脚本可以在 不同主机、不同系统之间共享,也可以在同一主机、同一系统之间共享 【数据驱动脚本】将测试输入存储在独立的(数据)文件中,而不是存储在脚本中。可以针对不同数 据输入实现多个测试用例。 【关键字驱动脚本】关键字驱动脚本是数据驱动脚本的逻辑广展。它将数据文件变成测试用例的描述, 用一些关键字指定要执行的任务。 需求频繁变更的项目不适合用自动化测试，因为脚本要频繁变更
      • 面向对象的测试
        • 算法层(单元测试):包括等价类划分测试、组合功能测试(基于判定表的测试)、递归函数测试和多态消息测试 类层(模块测试):包括不变式边界测试、模态类测试和非模莫态类测试 模板层/类树层(集成测试):包括多态服务测试和展平测试 系统层(系统测试)
      • 软件测试与软件调试
        • 
        • 软件调试
          • 对测试出的bug进行调试解决 软件调试方法： 蛮力法:主要思想是"通过计算机找错",低效,耗时 回溯法:从出错处人工沿控制流程往回追踪,直至发现出错的相限源。复杂程序由于回溯路径多,难以实施 原因排除法:主要思想是演绎和归纳,用二分法实现
      • McCabe软件度量
        • 每年都考 软件的两种属性:外部属性指面向管理者和用户的属性,可直接测量,一般 为性能指标。内部属性指软件产品本身的的属性,如可靠性等,只能间接测量 McCabe度量法:又称为环路复杂度,假设有向图中有向边数为m,节点数为n, 有三种计算方式： 则此有向图的环路复杂度为m-n+2. 另一种计算方式，菱形判断节点数+1 第三种是封闭区域个数+1 如下图 1. 找出图中有多少条路径？ 找开始到结束的路径多少条，数一下，4条 2.McCabe度量计算环路复杂度： m 为13， n为11， 套用公式结果为4  圈复杂度一般不能大于10
    • 系统运行与软件维护
      • 遗留系统演化策略
        • 
      • 新旧系统的转换策略
        • 
      • 数据转换与迁移
        • 
      • 系统运行维护
        • 
    • 净室软件工程
      • 净室软件工程是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。 注重事前 可以降低软件开发中的风险,以合理的成本开发!出高质量的软件 通过在第1次正确地书写代码增量,并在测试前验证它们的正确性，来避免对成本很高的错误消除过程的依赖 提倡开发者不需要进行单元测试,而是进行正确性验证和统计质量控制
  • 12软件架构设计
    •  架构有时也称为体系结构 软件架构概述:构件技术、架构建模 软件架构风格:数据流、调用返回、独立构件、虚拟机、仓库风格、闭环控制、C2风格、 C/S、B/S、MVC/MVP/MVVM、SOA。 特定领域架构:特定领域软件架构DSSA、基于架构的软件开发ABSD、软件架构评估。 中间件、典型应用架构。 202311选择题考察:机会复用和系统复用、静态架构评估、质量属性(性能+可移植性) 架构是(词汇表+约束)、质量属性效用树结构、DSSA(领域分析和领域设计输出)、ABSD (定义和步骤)、质量属性场景刺激和度量、SAAM输入、批处理管理过滤器风格对比、构件 接口、构件没有外部可见状态、适应性和装配性构件、构件检索、构件管理步骤、构件可组 装性和可部署性、层次式架构。 202311案例考察:大数据架构,以后会更侧重下篇八大架构,而非质量属性+架构风格固定 题型。
    • 基本概念
      • 本质&定义
        • 1、软件架构为软件系统提供了一个结构、行为（交互作用）和属性的高级抽象。 由构件的描述、构件的相互作用(连接件)、指导构件集成的模式以及这些模式的约束组成。 2、软件架构风格是特定应用领域的惯用模式, 架构风格定义一个系统家族，即一个架构定义、一个词汇表和一组约束。 词汇表中含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。 软件架构不仅指定了系统的组织结构和拓扑结构,并且显示了系统需求和构件之间的对应关系, 提供了一些设计决策的基本原理。 软件架构设计包括提出架构模型,产生架构设计和进行设计评审等等活动,是一个迭代的过程。架 构设计主要关注软件组件的结构、属性和交互作用,并通过多种视图全面描述特定系统的架构。 架构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效 地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用,一些经过实践证实的 解决方案也可以可靠地用于解决新的问题。 架构设计的一个核心问题是能否达到架构级的软件复用。 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则
      • 作用
        • 架构的作用 1、软件架构是项目干系人进行交流的手段。 2、软件架构是可传递和可复用的模型,通过研究软件架构可能预测软件的质量。 3、软件架构使推理和控制的更改更加简单,有助于循序渐进的原型设计,可以作为培训的基础。 软件架构=软件体系结构  架构设计就是需求分配,即将满足需求的职责分配到组件上。
      • 发展历程
        • 
      • 架构4+1视图
        • 不重要，新版教材已删除  与UML 4+1 视图有一一对应的关系、 
      • 软件架构风格ADL
        • ADL（架构描述语言）是这样一种形式化语言,它在底层语义模型的支持下,为软件系统的概念体系 结构建模提供了具体语法和概念框架。 ADL的三个基本元素： 构件:计算或数据存储单元。 连接件:用于构件之间交互建模的体系结构构造块及其支配这些交互的规则 架构配置:描述体系结构的构件与连接件的连接图。
      • 特定领域软件架构（DSSA）
        • DSSA: Domain-Specific Software Architecture 定义:特定领域软件架构以一个特定问题领域为对象,形成由领域参考模型、参考需求、参 考架构等组成的开发基础架构,支持在一个特定领域中多个应用的生成。 DSSA 类型： 垂直域:相同领域,深入。在一个特定领域中的通用的软件架构,是一个完整的架构。 水平域:不同领域,平移。在多个不同的特定领域之间的相同的部分的小工具（比如购物和教育都有的收费系统）
        • 三个基本活动及产出物
          •  领域分析:这个阶段的主要目标是获得领域模型(领域需求)。识别信息源,即整个领域工程过程中信 息的来源,可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等,在此基础上就可以分析领域中系统的需求,确定哪些需求是领域中的系统广泛共享的,从而建立领域模型。 领域设计:这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案,它不是单个系统的表示,而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后,就可以派生出满足这些被建模的领域需求DSSA。 领域实现:这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到,也可能需要通过新的开发得到。
        • 参与DSSA的角色
          • 参与DSSA 的人员： 1、领域专家:有经验的用户、从事该领域中系统 的需求分析、设计、实现以及项目管理的有经验的 软件工程师等。 领域专家的主要任务包括提供关于领域中系统的需 求规约和实现的知识。 2、领域分析人员:领域分析人员应由具有知识工 程背景的有经验的系统分析员来担任。 3、领域设计人员:领域设计人员应由有经验的软 件设计人员来担任。 4、领域实现人员:领域实现人员应由有经验的程 序设计人员来担任。
        • 建立过程
          • 
        • 三层次模型
          • 
      • 基于架构的开发方法【ABSD】
        • ABSD : Architecture-Based Software Design ABSD方法是架构驱动,即强调由业务、质量和功能需求的组合驱动架构设计。 ABSD方法有三个基础。 第一个基础是功能的分解。在功能分解中,ABSD方法使用已有的基于模块的内聚和耦合技术; 第二个基础是通过选择架构风格来实现质量和业务需求; 第三个基础是软件模板的使用。 视角与视图:从不同的视角来检查,所以会有不同的视图。 用例用来捕获功能需求、特定场景用来捕获质量需求。 在基于体系结构的软件设计方法中,采用(视角与视图)来描述软件架构，采用（质量场景）来描述质量需求。 采用(用例)来描述功能需求 ABSD方法是递归的,且迭代的每一个步骤都是清晰定义的。因此,不管设计是否完成,架构总是清 晰的,有助于降低架构设计的随意性。 ABSD方法是一个自顶向下,递归细化的方法,ABSD方法在最顶层系统被分解为若干概念子系统和一个 或者多个软件模板, 架构需求一般来自三个方面,分别是系统的质量目标、系统的业务目标和系统开发人员的业务目标。
        • 开发过程
          • 
          • 架构需求
            • 
          • 架构设计
            • 
          • 架构文档化
          • 架构复审
          • 架构实现
            • 
          • 架构演化
            • 
      • 软件产品线
        • 
        • 双生命周期模型
          • 分成两部分，领域工程和应用工程。 领域工程部分称为核心组，应用工程部分称为应用组 核心组做共性部分的维护 应用组完成个性化的新需求 
        • 建立方式
          •  将现有产品演化为产品线 用软件产品线替代现有产品集 全新软件产品线的演化 全新软件产品线的开发
        • 组织结构
          • 组织结构类型 设立独立的核心资源小组 不设立独立的核心资源小组 动态的组织结构 要成功实施产品线,主要取决于以下因素 对该领域具备长期和深厚的经验 一个用于构建产品的好的核心资源库 好的产品线架构 好的管理(软件资源、人员组织、过程)支持
      • 面向对象，构件，服务
        • 面向对象， 面向构件，面向服务 一个构件可以包含多个对象类，一个服务可以包含多个构件 粒度越来越粗，复用性越来越强
    • 软件质量属性
      • 往年案例只考可修改性，性能，安全性和可用性
      • 开发期质量属性
        • 可修改性
          • 可修改性(modifiability)是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以 某些具体的变更为基准,通过考察这些变更的代价衡量可修改性。 例如: (1)更改系统报表模块,必须在2人周内完成; (2)对Web界面风格进行修改,修改必须在4人月内完成;  主要策略:信息隐藏(二义性:良好的封装能够做到信息隐藏,一般归于可修改性策略; 信息隐藏也能够体现在安全性当中) 可修改性包含四个方面。
          • 可维护性
            • (1)可维护性(maintainability)。这主要体 现在问题的修复上:在错误发生后"修复"软件 系统。为可维护性做好准备的软件体系结构往 往能做局部性的修改并能使对其他构件的负面 影响最小化。
          • 可扩展性
            • (2)可扩展性(extendibility)。这一点关注 的是使用新特性来扩展软件系统,以及使用改 进版本来替换构件并删除不需要或不必要的特 性和构件。为了实现可扩展性,软件系统需要 松散耦合的构件。其目标是实现一种体系结 构,它能使开发人员在不影响构件客户的情况 下替换构件。支持把新构件集成到现有的体系 结构中也是必要的。
          • 结构重组
            • (3)结构重构(reassemble)。这一点处理 的是重新组织软件系统的构件及构件间的关 系,例如通过将构件移动到一个不同的子系统 而改变它的位置。为了支持结构重组,软件系 统需要精心设计构件之间的关系。理想情况 下,它们允许开发人员在不影响实现的主体部 分的情况下灵活地配置构件。
          • 可移植性
            • (4)可移植性(portability)。可移植性使软 件系统适用于多种硬件平台、用户界面、操作 系统、编程语言或编译器。为了实现可移植, 需要按照硬件无关的方式组织软件系统,其他 软件系统和环境被提取出。可移植性是系统能 够在不同计算环境下运行的能力。这些环境可 能是硬件、软件,也可能是两者的结合。在关 于某个特定计算环境的所有假设都集中在一个 构件中时,系统是可移植的。如果移植到新 的系统需要做些更改,则可移植性就是一种特 殊的可修改性。
        • 可测试性
          • 软件可测试性是指通过测试揭示软件缺陷的容易程度。 例如: (1)提供远程调试接口,支持远程调试。
        • 易用性
          • 易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。 例如: 界面友好; 新用户学习使用系统时间不超过2小时。
        • 可变性
          • 可变性(changeability)是指体系结构经扩充或变更而成为新体系结构的能力。这种 新体系结构应该符合预先定义的规则,在某些具体方面不同于原有的体系结构。当要将某个 体系结构作为一系列相关产品(例如,软件产品线)的基础时,可变性是很重要的。
        • 功能性
          • 功能性(functionality)是系统所能完成所期望的工作的能力。一项任务的完成需要 系统中许多或大多数构件的相互协作。
      • 运行期质量属性
        • 性能
          • 性能(performance)是指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理的事件的个数。 例如: (1)同时支持1000并发; (2)响应时间小于1s; (3)显示分辨率达到4K。 要达到性能要求，需要用什么性能战术: 
        • 安全性
          • 安全性(security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或 拒绝服务的能力。安全性又可划分为机密性【信息不泄露给未授权的用户】、完整性【防止信息被 篡改】、不可否认性【不可抵赖】及可控性【对信息的传播及内容具有控制的能力】等特性。 例如: (1)可抵御SQL注入攻击; (2)对计算机的操作都有完整记录; (3)用户信息数据库授权必须保证99.9%可用 
        • 可用性
          • 可用性(availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出 现故障时系统能够恢复正常的速度来表示。 例如: (1)主服务器故障,1分钟内切换至备用服务器; (2)系统故障,1小时内修复; (3)系统支持7×24小时工作。  (可靠性与可用性意义相近,一般选择优先选择可用性。可靠性要求比可用性更高。可 靠则必可用,而可用不一定可靠。可用性是可靠性的一个指标。可参照概念整理《第5章 系统可靠性分析与设计》理解。) 代表参数:故障间隔时间 设计策略:冗余、心跳线
        • 可靠性
          • (2)可靠性 可靠性(reliability)是软件系统在应用或系统错误面前,在意外或错误使用的情况下 维持软件系统的功能特性的基本能力。 代表参数:MTTF、MTBF 设计策略:冗余、心跳线
          • 容错
          • 健壮性
        • 互操作性
          • 作为系统组成部分的软件不是独立存在的,经常与其他系统或自身环境相互作用。为了 支持互操作性(interoperation),软件体系结构必须为外部可视的功能特性和数据结构 提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性 的问题,这种互操作性也影响应用的软件体系结构。
      • 质量属性场景
        • 22,23 连考两年 质量属性场景是一种面向特定质量属性的需求。它由6部分组成: 刺激源(Source):这是某个生成该刺激的实体(人、计算机系统统或者任何其他刺激器)。 刺激(Stimulus):该刺激是当刺激到达系统时需要考虑的条件。 环境(Environment):该刺激在某些条件内发生。当激励发生时,系统可能处于过载、运行或者其 他情况。 制品(Artifact):某个制品被激励。制品可能是整个系统,也可能是系统的一部分。 响应(Response):该响应是在激励到达后所采取的行动。 响应度量(Measurement):当响应发生时,应当能够以某种方式对其进行度量,以对需求进行测试。 可修改性质量属性场景描述实例: 
      • 相关知识点
        • 信息隐藏
          • 通过信息隐蔽可以提高软件的可修改性、可测试性和可移植性。
    • 质量效用树
      • 案例题考察较多 效用树是采用架构权衡分析方法(Architecture Tradeoff Analysis Method,ATAM)进行架构 评估的工具之一,其树形结构从根部到叶子节点依次为树根、质量属性、属性分类、质量属性场景  效用树会把场景列出后进行分级，M 中级，L低级， H 高级
    • 架构评估
      •  -表示负相关， 比如安全性越高性能会相应降低 +表示正相关，比如可维护性高时，可测试性往往比较高
      • 过程
        • 识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程。
        • 敏感点
          • 敏感点是一个或多个构件 (和/或构件之间的关系)的特性。
        • 权衡点
          • 权衡点是影响多个质量属性的特性,是多个质量属性的敏感点。 
        • 风险点
          • 风险点是指架构设计中潜在的、存在问题的架构决策所带来的急患。
        • 非风险点
          • 非风险点是指不会带来隐患,一般以"XXX要求是可以实现 (或接受)的"方式表达。
      • 架构评估方法
        • 架构评估方法不会考虑需求是否正确或准确，只会考虑如何设计架构满足需求。 
        • 基于调查问卷(检查表)的方式
        • 基于度量的方式
        • 基于场景的方式
          • 【场景】是从风险承担者的角度与系统交互的简短描述。 场景可从六个方面进行描述:刺激源、刺激、制品、环境、响应、响应度量 
          • 软件架构分析法(SAAM)
            • SAAM是一种非功能质量属性的架构分析方法,是最早形成义档并得到广泛应用的软件架构分析方法。 最初关注可修改性,后扩充到可移植性、可扩充性等。  基于场景的架构分析方法(Scenarios-based Architecture Analysis Method,SAAM的主要输入是问题描述、需求声明和架构描述。 特定目标。SAAM的目标是对描述应用程序属性的文档,验证基本的架构假设和原则。 质量属性。这一方法的基本特点是把任何形式的质量属性都具体化为场景,但可修改性是SAAM分析 的主要质量属性。 架构描述。SAAM用于架构的最后版本,但早于详细设计。架构的描述形式应当被所有参与者理解。 功能、结构和分配被定义为描述架构的3个主要方面。 输入及评估过程。包括5个步骤,即场景开发、架构描述、单个场景评估、场景交互和总体评估。
          • 架构权衡分析法(ATAM)
            • 架构权衡分析法ATAM,让架构师明确如何权衡多个质量目标,参与者有评估小组、项目决策者和其他 项目相关人。 ATAM:在SAAM的基础上发展起来的,主要针对性能、可用性、安全性和 可修改性,在系统开发之前,对这些质量属性进行评价和折中。 整个评估过程强调以属性作为架构评估的核心概念。主要针对性能、可用性、安全性和可修改性,在系统开发之前,对这些质量属性进行评价和折中。 
          • 成本效益分析法(CBAM)
            • 在ATAM基础上建立的,软件的"经济"模型。
          • SACMM方法
            • SACMM方法。是一种软件架构修改的度量方法。 SASAM方法。通过对预期架构(架构设计阶段的相关描述材料)和实际架构(源代码中执行的架构) 进行映射和比较来静态地评估软件架构。
          • ALRRA方法
            • 是一种软件架构可靠性风险评估方法,
          • AHP(层次分析法)方法
            • AHP(层次分析法)方法。是对定性问题进行定量分析的一种简便、灵活而又实用的多准则决策方法
    • 架构设计风格
      • 很重要，三科都很容易考到 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。 设计风格分为5大类风格，每一类又有多种子风格。 体系结构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成 一个完整的系统。 对软件架构风格的研究和实践促进了对设计的复用。 管道过滤器风格中,过滤器是构件,管道是连接件，管道节点之间是串行连接 管道过滤器和批处理风格的区别在于批处理前后构件不一定有关联 仓库风格又叫数据共享风格。
      • 架构风格对比
        • 
      • 数据流风格[Data Flow]
        • 传统编译器,每个阶段产生的结果作为下一个阶段的输入。 一个接一个,以整体为单位。  
        • 批处理【Batch Sequential】
          • 批处理序列:大量整体数据、无需用户交互
        • 管道-过滤器【Pipes and Filters】
          • 管道-过滤器:流式数据、弱用户交互
      • 调用/返回风格[Call/Return]
        • 
        • 主程序/子程序【Main Program and Subroutine】
        • 面向对象【Object-oriented】
          • 对象是构件,通过对象调用封装的方法和属性。
        • 分层架构【Layered System】
          •  层次结构优点: 1、支持基于可增加抽象层的设计,允许将一个复杂问题分解成一一个增量步骤序列的实现。 2、不同的层次处于不同的抽象级别,越靠近底层,抽象级别越高高。 3、由于每一层最多只影响两层,同时只要给相邻层提供相同的接口,允许每层用不同的 方法实现,同样为软件复用提供了强大的支持。 缺点: 1、并不是每个系统都可以很容易的划分为分层的模式。 2、很难找到一个合适的、正确的层次抽象方法。
          • 两层C/S架构
            • 两层C/S架构:客户端和服务器都有处理功能,现在已经不常用,原因有:开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一软件移植困难、软件维护和升级困难、新技术不能轻易应用、安全性问题、服务器端压力大难以复用。 两层C/S架构三个组成部分： 客户端，服务器，网络 服务器(后台)负责数据管理,客户机(前台)完成与用户的交互任务,网络是实现客户端和服务器之间的通信和数据传输 
          • 三层C/S架构
            • 三层C/S架构:将处理功能独立出来,表示层和数据层都 变得简单。表示层在客户机上,功能层在应用服务器上,数 据层在数据库服务器上。即将两层C/S架构中的数据从服务 器中独立出来了。其优点下面四点: 1.各层在逻辑上保持相对独立,整个系统的逻辑结构更为清 晰,能提高系统和软件的可维护性和可扩展性; 2.允许灵活有效的选用相应的平台和硬件系统,具有良好的 可升级性和开放性; 3.各层可以并行开发,各层也可以选择各自最适合的开发语 言; 4.功能层有效的隔离表示层与数据层,为严格的安全管理奠 定了坚实的基础,整个系统的管理层次也更加合理和可控制。 三层C/S架构设计的关键在于各层之间的通信效率,要慎 重考虑三层间的通信方法、通信频度和数据量,否则即使分 配给各层的硬件能力很强,性能也不高。 如下，新增了一个功能层： 
          • 三层B/S架构
            • 浏览器/服务器(Browser/Server,B/S)架构是三层C/S架构的一种实现方式 是三层C/S架构的变种,将客户端变为用户客户端上的浏览器,将应用服务器变 为网络上的WEB服务器,又称为0客户端架构,虽然不用开发客户端,且有很多 缺点: B/S架构缺乏对动态页面的支持能力,没有集成有效的数据库处理功能; 安全性难以控制; 在数据查询等响应速度上,要远远低于C/S架构; 数据提交一般以页面为单位,数据的动态交互性不强,不利于OLTP应用月。 基于B/S架构的软件,系统安装、修改和维护全在服务器端解决。用户在使用系统时,仅仅需要一个浏览器就可运行全部的模块,真正达到了"零客户端"的功能,很容易在运行时自动升级。 混合架构风格 内外有别模型:企业内部使用C/S,外部人员访问使用B/S。 查改有别模型:采用B/S查询,采用C/S修改。 混合架构实现困难,且成本高。
          • 富互联网应用
            • 弥补三层B/S架构存在的问题,RIA是一种用户接口,比用HTML实现的接口 更加健壮,且有可视化内容,本质还是网站模式,其优点如下: RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容 易传播的特性; RIA简化并改进了B/S架构的用户交互; 数据能够被缓存在客户端,从而可以实现一个比基于HTML的响应速度更快且 数据往返于服务器的次数更少的用户界面。 本质还是0客户端,借助于高速网速实现必要插件在本地的快速缓存,增强页 面对动态页面的支持能力,典型的如小程序。
          • MVC架构
            • (1)控制器(Controller):是应用程序中处理用户交互的部分。通常控制器负责 从视图读取数据,控制用户输入,并向模型发送数据。 (2)模型(Model):是应用程序中用于处理应用程序数据逻辑的部分。通常模 型对象负责在数据库中存取数据。模型表示业务数据和业务逻辑。 (3)视图(View):是应用程序中处理数据显示的部分。通常视图是依据模型数 据创建的。是用户看到并与之交互的界面。视图向用户显示相关的数据,并能 接收用户的输入数据,但是它并不进行任何实际的业务处理: 
          • MVP架构
            • MVP:MVP是把MVC中的Controller换成了Presenter(呈现),目的就 是为了完全切断View跟Model之间的联系,由Presenter充当桥梁,做到 View-Model之间通信的完全隔离。 MVP特点: 1、M、V、P之间双向通信。 2、View与Model不通信,都通过Presenter传递。Presenter完全爸爸 Model和View进行了分离,主要的程序逻辑在Presenter里实现。 3、View非常薄,不部署任何业务逻辑,称为"被动视图"(Passive View),即没有任何主动性,而Presenter非常厚,所有逻辑都部署在E 那里。 4、Presenter与具体的View是没有直接关联的,而是通过定义好的的接口 进行交互,从而使得在变更View时候可以保持Presenter的不变,这样 就可以重用。 
          • MVVM
            • MVVM:MVVM模式和MVC模式类似,主要目的是分离视图 (View)和模型(Model),有几大优点: 1、低耦合,视图(View)可以独立于Model变化和修改,一个 ViewModel可以绑定到不同的"View"上,当View变化的时候 Model可以不变,当Model变化的时候View也可以不变。 2、可重用性,可以把一些视图逻辑放在一个ViewModel里面, 让很多view重用这段视图逻辑。 3、独立开发,开发人员可以专注于业务逻辑和数据的开发 (ViewModel),设计人员可以专注于页面设计。 4、可测试,界面向来是比较难于测试的,而现在测试可以针 对ViewModel来写。 
        • 面向服务的架构风格SOA
          • SOA是一种粗粒度、松耦合服务架构,服务之间通过简单、精确确定义接口进 行通信,不涉及底层编程接口和通信模型。 在SOA中,服务是一种为了满足某项业务需求的操作、规则等的逻辑组合, 它包含一系列有序活动的交互,为实现用户目标提供支持。 SOA并不仅仅是一种开发方法,还具有管理上的优点,管理员可直接管理开 发人员所构建的相同服务。多个服务通过企业服务总线提出服务务请求,由应用 管理来进行处理,如下:  实施SOA的关键目标是实现企业IT资产重用的最大化,在实施SOA过程中要 牢记以下特征:可从企业外部访问、随时可用(服务请求能被及时响应)、粗 粒度接口(粗粒度提供一项特定的业务功能,而细粒度服务代表了技术构件方 法)、服务分级、松散耦合(服务提供者和服务使用者分离)、可重用的服务 及服务接口设计管理、标准化的接口(WSDL、SOAP、XML是核心)、支持各 种消息模式、精确定义的服务接口。 从基于对象到基于构件再到基于服务,架构越来越松散耦合,粒度越来越粗, 接口越来越标准。
          • SOA关键技术
            •  UDDI:是一套基于WEB的、分布式的、为WebService提供的、信息注册中心的实现标准 规范,同时也包含一组使企业能将自身提供的WebService注册,以使别的企业能够发现的 访问协议的实现标准,用于WEB服务注册统一描述、发现及集成。 WSDL (Web Service描述语言):将Web服务描述定义为一组服务访问点,客户端可姒 通过这些服务访问点对包含面向文档信息或面向过程调用的服务进行访问(类似远程调 用),用于描述服务。 SOAP(Simple Object Access Protocol简单对象访问协议):是用于交换XML编码信息的轻量级协议,用于传递信息。 XML(可扩展标记语言):是WebService平台中表示数据的基本格式,用于数据交换。
          • 三种实现方式
            • WebService
              • WEB Service 服务提供者、服务注册中心(中介,提供交易平台,可有可无). 服务请求者。服务提供者将服务描述发布到服务注册中心,供服 务请求者查找,查找到后,服务请求者将绑定查找结果。如图 
            • 服务注册表
              • 服务注册表 (1)服务注册:应用开发者(服务提供者)在注册表中公布服务 的功能。 (2)服务位置:服务使用者(服务应用开发者),帮助他们查询 注册服务,寻找符合自身要求的服务。 (3)服务绑定:服务使用者利用检索到的服务接口来编写代码, 所编写的代码将与注册的服务绑定,调用注册的服务,以及与它 们实现互动。
            • ESB
              • 企业服务总线ESB:简单来说是一根管道,用来连接各个服务节点。ESB的存 在是为了集成基于不同协议的不同服务,ESB做了消息的转化、解释以及路由 的工作,以此来让不同的服务互联互通。 包括:客户端(服务请求者)、基础架构服务(中间件)、核心集成服务 (提供服务)。 ESB特点: 1、SOA的一种实现方式,ESB在面向服务的架构中起到的是总线作用,将各种 服务进行连接与整合 2、描述服务的元数据和服务注册管理; 3、在服务请求者和提供者之间传递数据,以及对这些数据进行转换的能力,# 支持由实践中总结出来的一些模式如同步模式、异步模式等; 4、发现、路由、匹配和选择的能力,以支持服务之间的动态交互互,解耦服务请 求者和服务提供者。高级一些的能力,包括对安全的支持、服务质量保证、可 管理性和负载平衡等。 
      • 独立构件风格[Independent Components]
        •   构成： 
        • 进程通信【Communicating Processes]
        • 事件驱动系统(隐式调用)【Eventsystem】
      • 虚拟机风格[Virtual Machine]
        •  虚拟机的作用是解释并执行特定的代码. 
        • 解释器【interpreter】
          • 
        • 规则系统【Rule-based System】
          • 基于规则的系统构成:规则集、规则解释器、规则/数据选择及工作内存,一般用在 人工智能领域和DSS(决策支持系统)中。 
      • 以数据为中心[Data-centered]/仓库风格
        •   在仓库风格中,有两种不同的构件:中央数据结构说明当前状态,独立构件在中央数据存储上执行。
        • 数据库系统【Database System】
        • 黑板系统【Blackboard System】
          •  黑板用于记录数据，并共享数据 黑板系统包括知识源、黑板和控制三部分 相比数据库系统多了触发机制
        • 超文本系统【Hypertext System】
      • 闭环控制风格（过程控制）
        •  适合于嵌入式系统,用于解决简单闭环控制问题。 经典应用:空调温控,定速巡航。
      • C2风格
        •  C2架构的基本规则: 构件和连接件都有一个顶部和一个底部。 构件的顶部要连接到连接件的底部,构件的底部要连接到连接件的顶部,构件之间不允许直连。 一个连接件可以和任意数目的其他构件和连接件连接。 当两个连接件进行直接连接时,必须由其中一个的底部到另一个的顶部。
      • 模型驱动架构MDA
        • -MDA的主要目标: Portability(可移植性),interoperability(互通性),Reusability(可重用性) MDA的3种核心模型: 平台独立模型(PIM):具有高抽象层次、独立于任何实现技术的模型。 平台相关模型(PSM):为某种特定实现技术量身定做,让你用这种技术中可用的实现 构造来描述系统的模型。PIM会被变换成一个或多个PSM。 代码Code:用源代码对系统的描述(规约)。每个PSM者都将被变换成代码。 
    • 软件架构复用
      • 这部分不太重要 软件复用【重用】是多次不同的软件开发过程中重复使用相同或相似【软件元素】的过程。 软件元素有： 需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识 复用的历史发展路线：  软件架构复用的类型包括机会复用和系统复用。
      • 复用的维度
        • 水平复用:不分行业领域,通用 垂直复用:分行业领域,专用
      • 机会复用和系统复用
        • 软件架构复用的类型包括机会复用和系统复用。 机会复用是指开发过程中,只要发现有可复用的资产,就对其进行复用。 系统复用是指在开发之前,就要进行规划,以决定哪些需要复用。
      • 可复用资产
        • 可复用的资产包括: 需求、架构设计、元素、建模与分析、测试、项目规划、过程方法和工具、人员、样本系统、缺陷消除。
      • 复用的基本过程
        • 复用的基本过程主要包括3个阶段: 首先构造/获取可复用的软件资产,其次管理这些资产(构件库),最后针对特定的需求,从这些资产中选择可复用的部分,以开发满足需求的应用系统。
    • 构件与中间件技术
      • 每年5到6分
      • 构件的定义
        • 定义1:软件构件是一种组装单元,它具有规范的接口规约和显式的语境依赖。软件 构件可以被独立地部署并由第三方任意地组装。 定义2:构件是某系统中有价值的、几乎独立的并可替换的一个部分,它在良好定义 的体系结构语境内满足某清晰的功能。 定义3:构件是一个独立发布的功能单元,可以通过其接口访问它的服务。  构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子构件 是部署、版本控制和替换的基本单位。原子构件通常成组地部都署,但是它也能够被单独部署。 构件和原子构件之间的区别在于,大多数原子构件永远都不会被单独部署,尽管它们可以被单独 部署。相反,大多数原子构件都属于一个构件家族,一次部署往往涉及整个家族。 在构件的定义中,接口是一个已命名的一组操作的集合。 构件通常以二进制形式发布,无需编译:如果没有公开接口,则需要适配器
        • 构件的特征
          • 构件的特性是: (1)独立部署单元; (2)作为第三方的组装单元; (3)没有(外部的)可见状态 一个构件可以包含多个类元素,但是一个类元素只能属于一个构件
        • 五类构件
          • 独立而成熟的构件 ： 独立的，成熟的，可以单独运行的。 适应性构件 ： 具有高度的适应性和灵活性,能够根据不同的需求和环境进行调整和适应。 装配的构件：是通过多个独立模块或子系统的组合构成的。每个模块可能独立开发,但最终通过装配形成一个完整的系统。 可修改的构件 ：构件易于修改，易于扩展。 有限制的构件 ： 构件有限制，依赖于特定的环境或平台才能运行
      • 面向构件的编程COP
        • 面向构件的编程(Component Oriented Programming,COP) 面向构件的编程(COP)关注于如何支持建立面向构件的解决方案。一个基于一般OOP风格的COP定义如下 面向构件的编程需要下列基本的支持: 多态性(可替代性); 模块封装性(高层次信息的隐藏); 后期的绑定和装载(部署独立性); 安全性(类型和模块安全性)
      • 构件的复用
        • 
        • 检索与提取构件
          • 基于关键字的检索
            • 
          • 刻面检索法
            • 刻面--某个维度的切面 
          • 超文本检索法
          • 构件检索需求列表
            • 62.构件检索就是用户从目标构件库中检索出满足需求或接近需求的构件。构件检索一直被认为是 构件库系统管理的核心技术问题,构件的检索方法依赖于构件的分类描述方法。 构件检索的需求列表包含如下几个： A.为检索构件建立分类模式 C.提供可视化的检索工具 B.能较准确的检索所需构件
        • 理解与评价构件
          • 1、要复用构件,准确地理解构件至关重要。特别是对构件修改使用时。 2、为达到目的,必须要求构件的开发过程遵循公共标准。 3、一般构件库的文档中全面而准确地说明以下内容: 构件的功能与行为、相关的领域知识、可适应性约束条件与例刚外情形、可以预见的 修改部分及修改方法。
        • 修改构件
          • 1、理想状态是直接复用构件库中现成的构件,但大多数情况下,必须对构件进行或 多或少的修改,以应对新需求。 2、为了减少构件修改的工作量,要求开发人员尽量使构件的功能、行为和接口设计 更为抽象化、通用化和参数化。这样,复用者即可通过对实参的选取来调整构件的功 能或行为。如果这种调整仍不足以使构件适用于新系统,复用者就必须借助设计信息 和文档来修改构件。 3、构件库中若无可修改使用的构件,则按新需求开发构件,并存入构件库。
        • 组装构件
          • 组装的三种方式 1、基于功能的组装:采用子程序调用和参数传递的方式将构件组装起来。 2、基于数据的组装:仍然是传统的子程序调用与参数传递。但它所依赖的软件设计方法不再是功 能分解,而是面向数据的设计方法,例如,Jackson系统开发方法。 3、面向对象的组装:如果从类库中检索出来的基类能够完全满足新系统的需求,则可以直接应用。 否则,必须以基类为父类,生成相应的子类,以满足新系统的需求 构件组装是指构件相互直接集成或是用"胶水代码"将其整合不在一起来创造一个系统或另一个构件的过程。常见的方式包括:顺序组装、层次组装、叠加组装。同时,构件组装中经常会面临接口不兼容的问题,如果一个构件的提供接口是另一个构件请求接口的一个子集,则属于操作不完备的情况。 构件组装失配问题 1、由构件引起的失配,包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设 存在冲突引起的失配; 2、由连接子引起的失配,包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引 起的失配; 3、由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题,首先需要 检测出失配问题,并在此基础上通过适当的手段消除检测出的失夫配问题。 构件组装会存在参数不兼容、操作不兼容及操作不完备这三种兼容性问题
      • 构件系统架构特征
        • 构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成。 构件框架是一种专用的体系结构(通常围绕一些关键的机制),同时,也是一组固定地 作用于构件层次机制的策略。 概念框架的互操作设计包括系统体系结构连接的所有框架间的互操作的规则。 构件是一组通常需要同时部署的原子构件。构件和原子构件之间的区别在于,大多数原 子构件永远都不会被单独部署,尽管它们可以被单独部署。 一个原子构件是一个模块和一组资源。 模块是一组类和可能的非面向对象的结构体,比如过程或者函数 资源是一个类型化的项的固定集合。 资源这个概念可以包含代码资源,进而包含模块。问题在于除了编译器编译一个模块或 包生成的资源外,还可能存在其他的资源。在"纯对象"的方法中,资源是外部化的不 可改变的对象一一不可改变是因为构件没有持久化的标志,而且复制不能被区分。
      • 构件标准
        • CORBA
          •  伺服对象(Servant):CORBA对象的真正实现,负责完成客户端请求 对象适配器(Object Adapter):用于屏蔽ORB内核的实现细节,为服务器对象的实现者提供 抽象接口,以便他们使用ORB内部的某些功能。 对象请求代理(Object Request Broker):解释调用并负责查找实现该请求的对象,将参数传 给找到的对象,并调用方法返回结果。客户方不需要了解服务务对象的位置、通信方式、实现、激 活或存储机制。 可移植对象适配器POA:作用是在底层传输平台与接收调用并返回结果的对象实现之间进行协调。
        • J2EE
          • 会话Bean
            • 会话Bean:用于实现业务逻辑,负责完成服务端与客户端的交互。它可以是有状态的,也可以是无状态的。每当客户端请求时,容器就会选择一个会话Bean来为客户端服务。会话Bean可以直接访问数据库,但更多时候,它会通过实体Bean实现数据访问。
          • 实体Bean
            • 实体Bean:用于实现O/R映射,简化数据库开发工作。负责将数据库中的表记录映射为内存中的实体对象,事实上,创建一个实体Bean对象相当于新建一条记录,删除一个实体Bean会同时从数据库中删除对应记录,修改一个实体Bean时,容器会自动将实体Bean的状态和数据库同步。
          • 消息驱动Bean
            • 消息驱动Bean:处理并发与异常访问 消息驱动Bean:是EJB3.0中引入的新的企业Bean,它基于JMS消息,只能接收客户端发送的JMS消息然后处 理。MDB实际上是一个异步的无状态会话Bean,客户端调用MDIB后无需等待,立刻返回,MDB将异步处理客户 请求。这适合于需要异步处理请求的场合,比如订单处理,这样就能避免客户端长时间的等待一个方法调用直到返回结果。
        • DNA 2000
      • 中间件
        • 中间件是一类构件 中间件是一类系统软件  简化结构、屏蔽差异、利于复用 在分布式系统中,中间件通常提供两种不同类型的支持,即交互支持和提供公共服务
        • 采用中间件技术的优点
          • (1)面向需求。即设计师集中精力于业务逻辑本身。 (2)业务的分隔和包容性。应用开发人员可以按照不同的业务进行功能的划分,体现为不同 的接口或交互模式。 (3)设计与实现隔离。构件对外发生作用或构件间的交互,都是通过接口进行的,构件使用 者只需要知道构件的接口,而不必关心其内部实现,这是设计与实现分离的关键。 (4)隔离复杂的系统资源。架构很重要的一个功能就是将系统资源与应用构件隔离,这是保 证构件可复用甚至"即插即用"的基础,与中间件的意图也是一致的。 (5)符合标准的交互模型。中间件则实现了架构的模型,实现了标准的协议。 软件复用。中间件提供了构件封装、交互规则、与环境的隔离离等机制,这些都为软件复 用提供了方便的解决方案。 (8)提供对应用构件的管理。基于中间件的软件可以方便地进行管理,因为构件总可以通过 标识机制进行划分。
        • 中间件分类
          • 
  • 15安全架构设计理论与实践
  • 15信息安全技术基础知识
    • 信息安全属性:保密性、可用性、完整性、不可抵赖性等 安全需求:物理安全、网络安全、系统安全、应用安全 安全技术:加密技术、信息摘要、数字签名、数字证书、PKI 网络安全技术:防火墙、入侵检测、入侵防御 网络攻击和威胁、计算机病毒和木马 安全协议:SSL、SET、Kerberos、PGP
    • 信息安全属性机密性
    • 网络攻击
      • 非法使用(非授权访问):某一资源被某个非授权的人,或以非授权的方式使用。 破坏信息的完整性:数据被非授权地进行增删、修改或破坏而受到损失。 授权侵犯(内部攻击):被授权以某一目的使用某一系统或资源原的某个人,却将此权限用于其他非授权的目的。 计算机病毒:一种在计算机系统运行过程中能够实现传染和侵害害功能的程序 拒绝服务:对信息或其他资源的合法访问被无条件地阻止。 陷阱门:在某个系统或某个部件中设置的"机关",使得在特定的数据输入时,允许违反安全策略。 旁路控制:攻击者利用系统的安全缺陷或安全性上的脆弱之处获得非授权的权利或特权。 业务欺骗:某一系统或系统部件欺骗合法的用户或系统自愿地放弃敏感信息等。 特洛伊木马:软件中含有一个觉察不出的有害的程序段,当它被执行时,会破坏用户的安全,这种应用程序称为特 洛伊木马。 物理侵入:侵入者绕过物理控制而获得对系统的访问。 业务流分析:通过对系统进行长期监听,利用统计分析方法对诸如通信频度、通信的信息流向、通信总量的变化等 参数进行研究,从中发现有价值的信息和规律。
      • 重放攻击
        • 重放攻击(ReplayAttacks)又称重播攻击、回放攻击或新鲜性攻击(FreshnessAttacks),是指攻击者发送一个目的主机已接收过的包,来达到欺骗系统的目的,主要用于身份认证过程,破坏认证的正确性。 Kerberos系统采用的是时间戳方案来防止重放攻击,这种方案中,发送的数据包是带时间戳的,服务器可以根据时间戳来判断是否为重放包,以此防止重放攻击。
      • 拒绝服务
        • 拒绝服务攻击是一种典型的破坏服务可用性的攻击方式。它不以获得系统权限为目的。 拒绝服务是一种通过耗尽CPU、内存、带宽或磁盘空间等系统资源,来阻止或削弱对网络系统或者应用程序的授权使用的行为。 典型的拒绝服务攻击包括:同步包风暴(SYN Flood)、UDP Flood (UDP洪水)、Ping of Death（死亡之 Ping)、Teardrop Attack(泪滴攻击)、Smurf攻击、垃圾邮件等。
  • 16软件可靠性分析与设计
    • 本章节应该考察2分左右,从2022年开始才考 察选择题,之前是偶尔会出现在案例分析中, 整体考的比较少。 第二版更新: 对应第二版教材第9章,教材内容整体比较空 泛,以介绍普及为主,没有太多技术参考价 值,因此本章节应该也是非重点,大家还是 重点掌握一下容错技术基本就可以,其他的 基本概念普及听听视频即可。
    • 可靠性基本概念
      • 软件可靠性是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。 软件可靠性和硬件可靠性区别: (1)复杂性:软件复杂性比硬件高,大部分失效来自于软件失效。 (2)物理退化:硬件失效主要是物理退化所致,软件不存在物理退化。 (3)唯一性:软件是唯一的,每个COPY版本都一样,而两个硬件不可能完全一样羊。 (4)版本更新周期:硬件较慢,软件较快。 软件可靠性的定量描述 1.规定时间:自然时间、运行时间、执行时间(占用CPU)。 2.失效概率:软件运行初始时为0,随着时间增加单调递增,不新趋向于1 3.可靠度:软件系统在规定的条件下、规定的时间内不发生失效的概率。等于1-失效概率。 4.失效强度:单位时间软件系统出现失效的概率。 5.平均失效前时间(MTTF):平均无故障时间,发生故障前正常运行的时间。 6.平均恢复前时间(MTTR):平均故障修复时间,发生故障后的修复夏时间 7.平均故障间隔时间(MTBF):失效或维护中所需的平均时间,包括故障时间以及检测和维护设备 的时间。MTBF=MTTF+MTTR。 系统可用性=MTTF/(MTTF+MTTR)*100%。
    • 软件可靠性设计
      • 提高系统可靠性的技术可以分为避错 (排错)技术和容错技术. 避错是通过技术评审、系统测试和正确性证明等技术,在系统正式运行之前避免、发现和改正错误 容错是指系统在运行过程中发生一定的硬件故障或软件错误时,仍能保持正常工作而不影响正确 结果的一种性能或措施。容错技术主要是采用冗余方法来消除故障的影响
      • 容错
        • 容错是指系统在运行过程中发生一定的硬件故障或软件错误时,仍能保持正常上作而不影响正确 结果的一种性能或措施。 容错技术主要是采用冗余方法来消除故障的影响。 冗余是指在正常系统运行所需的基础上加上一定数量的资源,包括信息、时间、硬件和软件。 冗余是容错技术的基础,通过冗余资源的加入,可以使系统的可靠性得到较大的的提高。 主要的冗余技术有结构冗余(静态、动态、混合)、信息冗余、时间冗余利口冗余附加4种 软件容错的主要方法是提供足够的冗余信息和算法程序,使系统在实际示运行时能够及时发现程序 设计错误,采取补救措施,以提高系统可靠性,保证整个系统的正常运行。 软件容错技术主要有N版本程序设计、恢复块方法和防卫式程序设计等 
        • N版本程序设计
          • N版本程序设计（是一种静态冗余）:其设计思想是用N个具有相同功能的程序同时执行一项计算,结果通过多数表 决来选择。其中N个版本的程序必须由不同的人独立设计,使用不同的方法、设计语言、开发环 境和工具来实现,目的是减少N个版本的程序在表决点上相关错误的概率。 
        • 恢复块设计
          • 恢复块设计(动态冗余):动态冗余又称为主动冗余,它是通过故故障检测、故障定位及故障恢 复等手段达到容错的目的。其主要方式是多重模块待机储备,当系统检测到某工作模块出现错误 时,就用一个备用的模块来替代它并重新运行。各备用模块在其待机时,可与主模块一样工作, 也可以不工作。前者叫热备份系统(双重系统),后者叫冷备份系统(双工系统、双份系统)。 
        • 防卫式程序设计
          • 防卫式程序设计:是一种不采用任何传统的容错技术就能实现软件容错的方法,对于程序中存 在的错误和不一致性,防卫式程序设计的基本思想是通过在程序中包含错误检查代码和错误恢复 代码,使得一旦发生错误,程序就能撤销错误状态,恢复到一个已知的正确状态中去。其实现策 略包括错误检测、破坏估计和错误恢复三个方面。
        • 双机容错
          • 双机容错技术:是一种软硬件结合的容错应用方案。该方案是由两台服多器和一个外接共享磁 盘阵列及相应的双机软件组成。 双机容错系统采用"心跳"方法保证主系统与备用系统的联系。所谓心跳,是指主从系统之间 相互按照一定的时间间隔发送通信信号,表明各自系统当前的运行伏态。一旦心跳信号表明主机 系统发生故障,或者备用系统无法收到主系统的心跳信号,则系统的高可用性管理软件认为主系 统发生故障,立即将系统资源转移到备用系统上,备用系统替代主系统工作,以保证系统正常运 行和网络服务不间断。 工作模式:双机热备模式;双机互备模式;双机双工模式。
  • 17项目管理
    • 18年后考的较少，只需了解下进度管理
    • 进度管理
      • 进度管理(也称项目时间管理)就是采用科学的方法,确定进度目标,编制进度计划和资源供应计+ 划,进行进度控制,在与质量、成本目标协调的基础上,实现工期目标。 具体来说,包括以下过程: (1)活动定义:确定完成项目各项可交付成果而需要开展的具体活动。 (2)活动排序:识别和记录各项活动之间的先后关系和逻辑关系 (3)活动资源估算:估算完成各项活动所需要的资源类型和效益。 (4)活动历时估算:估算完成各项活动所需要的具体时间。 (5)进度计划编制:分析活动顺序、活动持续时间、资源要求和进度制的因素 制订项目进度计划。 (6)进度控制:根据进度计划开展项目活动,如果发现偏差,则分析原因或进 行调整。
      • 关键路径法
        • 关键路径:是项目的最短工期,但却是从开始到结束时间最长的路径。进度网 络图中可能有多条关键路径,因为活动会变化,因此关键路径也在不断变化中。 关键活动:关键路径上的活动,最早开始时间=最晚开始时间。 通常,每个节点的活动会有如下几个时间: (1)最早开始时间(ES),某项活动能够开始的最早时间。 (2)最早结束时间(EF),某项活动能够完成的最早时间。EF=ES+工期 (3)最迟结束时间(LF)。为了使项目按时完成,某项活动必须完成的最近时 间。 (4)最迟开始时间(LS)。为了使项目按时完成,某项活动必须开始的最迟时 间。LS=LF-工期 这几个时间通常作为每个节点的组成部分 如图所示: 顺推:最早开始ES=所有前置活动最早完成EF的最大值;最早完成EF=最早开始ES+持续时间 逆推:最晚完成LF=所有后续活动最晚开始LS的最小值;最晚开始LS=最晚完成LF持续事件。 七格图：  总浮动时间:在不延误项目完工时间且不违反进度制约因素的前提下,活动 可以从最早开始时间推迟或拖延的时间量,就是该活动的进度灵活性。正常官情 况下,关键活动的总浮动时间为零。 总浮动时间=最迟开始LS-最早开始ES或最迟完成LF-最早完成EF或关键建路径 非关键路径时长。  可以用顺推或逆推两种方法求关键路径： ABFGH
    • 软件配置管理
      • 软件开发过程中会设置多个阶段,每个阶段结束之后会有产出物,那么阶段结束之后的产出物经 过评审之后会变为软件配置项
      • 软件系统工具
        • 软件系统工具的种类繁多,很难有统一的分类方法。通常可以按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。 软件开发工具:需求分析工具、设计工具、编码与排错工具。 软件维护工具:版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。 软件管理和软件支持工具:项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。
    • 质量管理
    • 风险管理
    • 范围管理
      • 范围定义的输入包括: 范围管理计划:范围管理计划是项目管理计划的组成部分,确定定了制定、监督和控制项目范围的各种活动。 项目章程:项目章程中包含对项目和产品特征的概括性描述,以从及项目审批要求。如果执行组织不使用项目章程, 则应取得或编制类似的信息,并用作制定详细范围说明书的基础出。 需求文件:使用需求文件来选择哪些需求将包含在项目中。 批准的变更申请。 组织过程资产:可能影响定义范围过程的组织过程资产包括(位旦不限于) 1、用于制定项目范围说明书的政策、程序和模板; 2、以往项目的项目档案; 3、以往阶段或项目的经验教训。
  • 软件架构的演化和维护
    • 历年真题考情: 本章节可能会考2分。 第二版更新; 第二版教材纯新增章节,历年尚未考过,无 习题。对应第二版教材第10章,新增的内容 是关于架构的演化和维护阶段,偏理论多, 而且不像架构风格、质量属性那块容易出题, 文老师认为以扩展了解为主,大家听听视频 课程掌握即可。
  • 未来信息综合技术
    • 历年真题考情: 本章节可能会考2-3分。 第二版更新: 本章节是第二版教材完全新增的章节,第二 版教材里对应第11章,但实际还没有完全覆 盖到架构考的超纲新技术知识点,比如本章 节下的课后习题,有不少都是教材里没有的, 大家可以重点掌握教材内容。
    • 信息物理系统 CPS
      • 是一种把信息技术应用于物理世界的技术。 信息物理系统(CPS)是控制系统、嵌入式系统的扩展与延伸,其涉及的相关底层理论技术源于对 嵌入式技术的应用与提升。 CPS通过集成先进的感知、计算、通信、控制等信息技术和自动控制技术,构建了物理空间与信 息空间中人、机、物、环境、信息等要素相互映射、适时交互、高效协同的复杂系统,实现系统内 资源配置和运行的按需响应、快速迭代、动态优化。 CPS的本质就是构建一套信息空间与物理空间之间基于数据自动流动的状态感知、实时分析、科 学决策、精准执行的闭环赋能体系)解决生产制造、应用服务过程中的复杂性和不确定性问题,提 高资源配置效率,实现资源优化 CPS 体系结构： (1)单元级CPS,是具有不可分割性的CPS最小单元,是具备可感知、可计算、可交互、可延展、自 决策功能的CPS最小单元,一个智能部件、一个工业机器人或一个智能机床都可能是一个CPS最小 单元。 (2)系统级CPS。多个最小单元(单元级)通过工业网络(如工业现场总线、工业以太网等),实 现更大范围、更宽领域的数据自动流动,实现了多个单元级CPS的互联、互通和互操作,进一步提 高制造资源优化配置的广度、深度和精度。包含互联互通、即插即用、边缘网关、数据互操作、协 同控制、监视与诊断等功能。其中互连互通、边缘网关和数据互换操作主要实现单元级CPS的异构集 成;即插即用主要在系统级CPS实现组件管理,包括组(单元级CPS)的识别,配置,更新和删除等 功能:协同控制是指对多个单元级CPS的联动和协同控制等;监视与诊断主要是对单元级CPS的状态 实时监控和诊断其是否具备应有的能力。 (3)SoS级。多个系统级CPS的有机组合构成SOS级CPS。例如,多个(工序 (系统的CPS)形成一 个车间级的CPS或者形成整个工厂的CPS。王要实现数据的汇聚,从而对内进行资产的优化和对外 形成运营优化服务。其主要功能包括:数据存储、数据融合、分布式计算、大数据分析、数据服 务,并在数据服务的基础上形成了资产性能管理和运营优化服务。 道法外对
      • CPS的技术体系
        • CPS技术体系主要分为CPS总体技术、CPS支撑技术、CPS核心技术。 CPS总体技术主要包括系统架构、异构系统集成、安全技术、试验验证技术等,是CPS的顶层 设计技术; CPS支撑技术主要包括智能感知、嵌入式软件、数据库、人机交互、中间件、SDN 、物联网、大数据等,是基于CPS应用的支撑; CPS核心技术主要包括虚实融合控制、智能装备、MBD、数字李生技术、现场总线、工业以太 网、CAX/MES/ERP/PLM/CRM/SCM等,是CPS的基础技术。
    • 人工智能
      • 人工智能(AI)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能,感知 环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。 人工智能的目标是了解智能的实质,并生产出一种新的能以人类智能相似的方式做出反应的智能 机器。该领域的研究包括机器人、自然语言处理、计算机视觉和专家系统等。 根据人工智能是否能真正实现推理、思考和解决问题,可以将人工智能分为弱人工智能和强人工智能。
      • 人工智能关键技术
        • 人工智能关键技术 1.自然语言处理(NLP)。研究实现人与计算机之间用自然语言进行有效通信的各种理论和方法。 主要包括机器翻译(从一种自然语言到另外一种自然语言的翻译)、语义理解(利用计算机理解文 本篇章内容,并回答相关问题)和问答系统(让计算机像人类一样用自然语言与人交流)等。 2.计算机视觉。是使用计算机模仿人类视觉系统的科学,让计算机拥有有类似人类提取、处理、理解 和分析图像以及图像序列的能力,将图像分析任务分解为便于管理的小块任务 3.知识图谱。就是把所有不同种类的信息连接在一起而得到的一个关系网络,提供了从"关系"的 角度去分析问题的能力。一般用于反欺诈、不一致性验证等问题。 4.人机交互(HCI)。主要研究人和计算机之间的信息交换。 5.虚拟现实或增强现实(VR/AR)。以计算机为核心的新型视听技术。洁合相关科学技术,在一定 范围内生成与真实环境在视觉、听觉等方面高度近似的数字化环境 6.机器学习(ML)。是以数据为基础,通过研究样本数据寻找规律,并根据所所得规律对未来数据进 行预测。目前,机器学习广泛应用于数据挖掘、计算机视觉、自然语言处理、生物特征识别等领域
      • AI芯片
        • 超纲题。AI芯片主要有三种技术架构 第一种是GPU,可以高效支持Al应用的通用芯片,但是相对于PPGA和ASIC来说,价格和功耗过高; 第二种是FPGA(现场可编程门阵列),可对芯片硬件层进行编程和配置,实现半定制化,相对于 GPU有更低的功耗; 第三种是ASIC(专用集成电路),专门为特定的AI产品或者服务而设计,主要是侧重加速机器学习 (尤其是神经网络、深度学习),它针对特定的计算网络结构采用了硬件电路实现的方式,能够在 很低的功耗下实现非常高的能效比,这也是目前AI芯片中最多的形式。
        • AI芯片的关键特征
          • 1、新型的计算范式 Al计算既不脱离传统计算,也具有新的计算特质,如处理的内容主往是非结构化数据(视频、图片等)。处理的过程通常需要很大的计算量,基本的计算主要是线性代数运算,而而控制流程则相对简单。处理的过程参数量大。 2、训练和推断 AI芯片通常涉及训练和推断过程。简单来说,训练过程是指在已有数据中学习,获得某些能力的过程;而推断过程则是指对新的数据,使用这些能力完成特定任务(比如分类、识制等) 3、大数据处理能力 人工智能的发展高度依赖海量的数据。满足高效能机器学习的数据男处理要求是AI芯片需要考虑的最重要因素。 4、数据精度 低精度设计是AI芯片的一个趋势,在针对推断的芯片中更加明显。对一些应用来说,降低精度的设计不仅加速了机器学习算法的推断(也可能是训练),甚至可能更符合神经形态计算的特征 5、可重构的能力 针对特定领域而不针对特定应用的设计,将是AI芯片设计的一个旨导原则,具有可重构能力的AI芯片可以在更多应用中大显身手,并且可以通过重新配置,适应新的AI算法、架构和任务。 6、开发工具 就像传统的CPU需要编译工具的支持,AI芯片也需要软件工具链的支持,才能将不同的机器学习任务和神经网络转换为可以在AI芯片上高效执行的指令代码。
    • 机器人
    • 边缘计算
    • 数字孪生
    • 云计算和大数据
      • 按照云计算服务提供的资源层次,可以分为Iaas、PaaS、SaaS三种服务类型: (1)Iaas(基础设施级服务),向用户提供计算机能力、存储空间等基础设施方面的服务。这种服 务模式需要较大的基础设施投入和长期运营管理经验。 (2)PaaS(平台级服务),向用户提供虚拟的操作系统、数据库管理系统、Web应用等平台化的 服务。PaaS服务的重点不在于直接的经济效益,而更注重构建和形成紧密的产业生态。 (3)SaaS(软件级服务)向用户提供应用软件(如CRM、办公软件等)、组件、工作流等虚拟化软 件的服务。
    • 区块链
    • 鸿蒙操作系统
      • 鸿蒙操作系统架构具有4个技术特性: 1)分布式架构首次用于终端OS,实现跨终端无缝协同体验。 2)确定时延引擎和高性能IPC技术实现系统天生流畅。 3)基于微内核架构重塑终端设备可信安全。 4)通过统一IDE支撑一次开发,多端部署,实现跨终端生态共享
  • 专业英语
    • 每年固定5分 系统架构设计师考试英文试题的出题范围基本局限于系统架构设计方面基础性的、概念性的知识，大多属于名词解释范畴。如果考生具有一定的英文水平，同时对于基本概念掌握得比较牢固，这部分分值不难拿到. 参考： 32小时通关第25小时
    • 生词
      • in terms of 就。。。而言，在。。。方面 vocabulary 词汇表 connector 连接器 semantic models 语义模型 architectural styles 架构风格 system constraint(系统约束) Maintainability requirements 维护性需求 be employed to 被用于
    • 架构风格
      • An architectural style defines as a family of such systems in terms of a pattern of structural organization. More specifically, an architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined. For many styles there may also exist one or more semantic models that specify how to determine a system's overall properties from the properties of its parts. Many of architectural styles have been developed over the years. The best-known examples of pipe-and-filter architectures are programs written in the UNIX shell. 一种架构风格以一种结构化组织模式定义一组这样的系统。具体来说，一种架构风格定义了一个构件及连接器类型的词汇表，以及一组关于它们如何能够被关联的约束。对于许多风格来说，可能也存在一个或多个语义模型，从系统部件的特性来确定系统的整体特性。许多架构风格已经发展了很多年，众所周知的管道-过滤器架构就是用 UNIX shell 编写的程序
    • 非功能需求
      • The architecture design specifies the overall architecture and the placement of software and hardware that will be used. Architecture design is a very complex process that is often left to experienced architecture designers and consultants. The first step is to refine the (nonfunctional requirements) into more detailed requirements that are then employed to help select the architecture to be used and the software components to be placed on each device. In a (client-based architecture), one also has to decide whether to use a two-tier, three-tier, or n-tier architecture. Then the requirements and the architecture design are used to develop the hardware and software specification. There are four primary types of nonfunctional requirements that can be important in designing the architecture. A (operational requirements) specify the operating environment(s) in which the system must perform and how those may change over time. (Performance requirements) focus on the nonfunctional requirements issues such as response time, capacity,and reliability. (Security requirements) are the abilities to protect the information system from disruption and data loss, whether caused by an intentional act. Cultural and political requirements are specific to the countries in which the system will be used. 架构设计指定了将要使用的软件和硬件的总体架构和布局。架构设计是一个非常复杂的过程，往往留给经验丰富的架构设计师和顾问。第一步是将非功能需求细化为更详细的要求，然后用于帮助选择要使用的体系结构以及要放置在每个设备上的软件组件。在基于客户端的架构中，还必须决定是使用两层、三层还是 n 层架构。然后使用需求和体系结构设计来开发硬件和软件规 范。有 4 种主要的非功能需求类型可能在设计架构时非常重要。操作要求指定系统必须执行的操作环境以及这些操作环境如何随时间变化。性能要求侧重于非功能性需求问题，如响应时间、容量和可靠性。安全要求是指是否有能力保护信息系统免受故意行为造成的破坏和数据丢失。文化和政治要求明确了特定系统将被使用的国家。
    • 数据库
      • During the systems analysis phase, you must decide how data will be organized, stored, and managed. A (data structure ) is a framework for organizing, storing, and managing data. Each file or table contains data about people, places, things, or events. One of the potential problems existing in a file processing environment is(data redundancy),which means that data common to two or more information systems is stored in several places. In a DBMS, the linked tables form a unified data structure that greatly improves data quality and access. A(n) (entity-relationship diagram) is a model that shows the logical relationships and interaction among system entities. It provides an overall view of the system and a blueprint for creating the physical data structures. (Normalization) is the process of creating table designs by assigning specific fields or attributes to each table in the database. A table design specifies the fields and icdentifies the primary key in a particular table or file. The three normal forms constitute a progression in which (third normal form)represents the best design. Most business-related databases must be designed in that form. 在系统分析阶段,需要确定数据如何组织、存储和管理。数据结构是用于组织、存储和管理数据的一个框架。每个文件或表包含了关于人物、地点、事物和事件的数据。文件处理场景中存在的潜在问题之一是数据冗余,意味着两个或多个信息系统中相同数据存储在多个不同位置。 在关系数据库管理系统(DBMS)中,相互链接的表格形成了一个统一的数据结构,可以大大提升数据质量和访问。实体联系图是一个模型,显示了系统实体之间的逻辑关系和交互。它提供了一个系统的全局视图和用于创建物理数据结构的蓝图。规范化是通过为数据库中的每个表分配特定的字段或属性来创建表设计的过程。表设计是在特定表或文件中确定字段并标识主键。三种范式构成了一个序列,其中第三范式代表了最好的设计,大部分与业务相关的数据库必须设计成这种形式。 data integrity(数据完整性) data dictionary(数据字典) database schema(数据库架构) Replication(复制) Partitioning(分区)
    • 架构设计
      • The objective of (architecture design) is to determine what parts of the application software will be assigned to what hardware. The major software components of the system being developed have to be identified and then allocated to the various hardware components on which the system will operate. All software systems can be divided into four basic functions. The first is (data storage).Most information systems require data to be stored and retrieved, wihether a small file,such as a memo produced by a word processor, or a large database, such as one that stores an organization's accounting records. The second function is the (data access logic). the processing required to access data, which often means database queries in Structured Query Language. The third function is the (application logic ) , which is the logic documented in the DFDs, use casses,and functional requirements. The fourth function is the presentation logic, the display of information to the user and the acceptance of the user's commands. The three primary hardware components of a system are (clients,servers,and network). 架构设计的目标是确定应用软件的哪些部分将分配到何种硬件。识别出正在开发系统的主要软件构件并分配到系统将要运行的硬件构件。所有软件系统可分为四项基本功能。第一项是数据存储。大多数信息系统需要数据进行存储并检索,不论是一个小文件,比如一个字处理器产生的一个备忘录,还是一个大型数据库,比如存储一个企业会计记录的数据库。第二项功能是数据访问逻辑,处理过程需要访问数据,这通常是指用SQL进行数据库查询。第三项功能是应用程序逻辑,这些逻辑通过数据流图,用例和功能需求来记录。第四项功能是表示逻辑,给用户显示信息并接收用户命令。一个系统的三类主要硬件构件是客户机、服务器和网络
  • 必记点
    • 1. 1K = 2^10 , 4K = 2^12
• 案例
  •  左边5个是23之前每年轮流考的考点，右边是23年改版后新增的8大架构 案例题基本就在这些里面出。
  • 考纲分析
    • 2022年发布新版大纲  设计模式新大纲出来前后几点都没有再考过 嵌入式的题不建议选择做答，因为它涉及嵌入式的方方面面，有时考察非常细节 重点： 架构设计： 架构评估基本每隔一年或连续考试； 架构风格，质量属性都是经常会考到的内容 数据建模：大数据结合数据库，考的概率非常高 Web系统架构设计： 融合分层架构、面向服务架构综合进行考量，也可能引入安全维度的内容考察 文老师： 根据历年真题考点分析,我们将架构案例分析真题分为如下几个大类: 1、软件架构设计:每年会必考1-2题,并且是第1题必选题,必须掌握,主要涉及到质量 属性、软件架构风格、软件架构评估、MVC架构、面向服务的架构SOA、ESB、J2EE架构等。 对于其他未考察的架构领域重点知识如DSSA、ABSD等,也必须重点掌握 2、系统开发基础:几乎每年必考1题,主要涉及到UML的图、关系的识别,尤其是类图、 用例图、活动图、状态图;设计模式识别;数据流图、E-R图等简单识别;信息安全相关 技术;项目管理-进度管理·关键路径。 3、数据库系统:偶尔会考察一题,主要考察的是数据库的一些新技术的比较交,如关系型 数据库、内存数据库及NosQL等,还会包括反规范化技术、主从复制、负载均衡等。 4、嵌入式系统:几乎每年必考一题,选做题,考察比较的多的是嵌入式系统的实时性和 可靠性以及容错等概念。大概率会考到一些嵌入式领域陌生技术,如果是完全没见过的技 术,不选即可。 5、Web应用开发:主要考察Web相关技术,一般结合架构进行考察。偶尔会考考到新技术, 遇到完全没听说过的技术,就不选。 此外,早年的考试中,偶尔考到一些完全陌生的架构和技术,没有看的必要,可忽略, 因为陌生技术不会再考第二次,无法去归纳总结,也没有了解的必要。
    • 重点1 八大架构
      • 信息系统架构、 层次式架构、 云原生架构、 面向服务架构、 嵌入式架构、 通信系统架构、 安全架构、 大数据架构
    • 考点分析
      • 1.可以看到，23年改版后第一题不再是送分题，考到了具体的大数据架构 所以后面需要重点研究八大架构。 2.软件工程的题出现了超纲，考到了Sysml需求图 后面可能还会考到Sysml图 3.数据库中规中矩，没有超纲，但22年之前经常会出现超纲。redis经常考 4.嵌入式不建议选，几乎每年超纲 5.web 应用，会考些新技术 
      • 考点分类
        • 根据历年真题考点分析,我们将架构案例分析真题分为如下几个大类: 1、软件架构设计:每年会必考1-2题,并且是第1题必选题,必须掌握,主要涉及到质量属性、软件架构风格、软件架构评估、MVC架构、面向服务的架构SOA、ESB、J2EE架构等。 对于其他未考察的架构领域重点知识如DSSA、ABSD等,也必须重点掌握 2、系统开发基础:几乎每年必考1题,主要涉及到UML的图、关系的识别,尤其是类图、用例图、活动图、状态图;设计模式识别;数据流图、E-R图等简单识别;信息安全相关技术;项目管理-进度管理-关键路径。 3、数据库系统:偶尔会考察一题,主要考察的是数据库的一些新技技术的比较,如关系型数据库、内存数据库及NoSQL等,还会包括反规范化技术、主从复制、负载均衡等。 4、嵌入式系统:几乎每年必考一题,选做题,考察比较的多的是嵌入式系统的实时性和可靠性以及容错等概念。大概率会考到一些嵌入式领域陌生技术术,如果是完全没见过的技术,不选即可。 5、Web应用开发:主要考察Web相关技术,一般结合架构进行考察。偶尔会考到新技术,遇到完全没听说过的技术,就不选。
      • 超级重点
        • 1.架构风格（各种风格需要了然于心） 2.质量属性（八个质量属性，质量效用树） 3.结构化需求分析和面向对象需求分析（数据流图，ER图，用例图） 4.数据库 redis
  • 学习建议
    • (十分重要)案例分析学习建议: 1、先完整的听一遍文老师视频课程案例分析专题课程,里面详细讲解了 大量典型案例真题以及解题技巧,该如何去分析题目,是非常重要的。 2、然后看本复习资料第二章案例精华考点内容,将相关考点都理里解记忆, 不理解的再去看视频对应部分知识点。 3、最后开始做本资料第三章历年案例真题,请一定按年份做题,并抱猪 练习,即每次抽90分钟出来,模拟真实考试,浏览五个题目,从中选出 三个来做,90分钟后停笔对答案,看看能得多少分。 这种做题方式非常有必要,切忌用零碎时间一题一题去做,没有意义, 架构案例考试更多的是考察学员临场应变能力,如何选题,选自己能拿 分的题才是最重要的。 第二版-系统架构设计师-案例分析总复习资料.pdf 
  • 如何解答试题
    • 解题技巧
      • 第一题必做,不用犹豫,先做完第一题。 后面四选二,快速浏览所有题目的问题,看看问题描述是否能看懂,再选择。 问题与题目描述相结合,尤其是遇到系统分析和设计问题,以及新技术问题,答案一般都在题目描述里,从题目描述抽象总结出问题答案。 以最简练的语言写出答案,一般题目会有最大字数要求,不能超过t。 遇到新的知识点,不要慌,稳住心态。 列条目回答问题,把自己认为对的,都写上,多写不会扣分,少写一定会扣分。 分析题目问题的倾向性,顺势答题。
    • 试题对考生的要求
      • 具有一定的系统架构设计实践经验,有较好的分析问题和解决问题的能力 对于有关系统架构设计方面,有广博而坚实的知识或见解 对应用的背景、事实和因果关系等有较强的理解能力和归纳能力 对于一些可以简单定量分析的问题已有类似经验并能进行估算,对于只能定性分 析的问题能用简练的语言抓住要点加以表达 善于从一段书面叙述中提取出最必要的信息,有时还需要舍舍弃一些无用的叙述或似是而非的内容
    • 试题解答步骤
      • 标出问题要点,以此作为主要线索进行分析和思考 对照问题要点仔细阅读正文 通过定性分析或者定量估算,构思答案的要点 以最简练的语言写出答案
    • 试题解答注意事项
      • 遇到新的知识点,不要慌,稳住心态 列条目回答问题,把自己认为对的都写上 分析题目问题的倾向性,顺势答题
  • 软件工程专题
    • 需求分析 **** 面向对象设计 ** 通常每年必考一题 结构化分析和UML图轮着考 11月考数据流图和ER图的概率很大
    • 结构化需求分析（SA）需求分析
      •  功能模型为主，数据模型为辅，行为模型很少考察 结构化特点:自顶向下,逐步分解,面向数据。 三大模型:功能模型(数据流图)、行为模型(状态转换图)、数据模型(E-R图)以及数据字典。
      • 数据流图DFD
        • 数据流图作用： 数据流图分析阶段:建立系统的功能模型,从而完成需求分析。 数据流图设计阶段:为模块划分与模块之间接口设计提供依据。 数据流图属于面向数据流分析法，不属于UML图，UML图属于面向对象  数据流图结构  典型数据流图实例： 
        • 数据流图平衡原则
          • 父图与子图之间的平衡 顶层图相对0层图就是父图，父图和子图输入输出的一致，就是平衡 子图内平衡 这一原则涉及到加工的输入与输出，加工需要有输入和输出。 以下三种是不满足平衡原则的现象 
        • 设计原则
          • 复杂性最小化原则 接口最小化原则 数据流一致性原则
        • 答题技巧
          • 详细分析试题说明 利用数据平衡原则
          • 利用平衡原则纠错
          • 补充实体
            • 实体可能是: (1)人物角色:如客户、管理员、主管、经理、老师、学生 (2)组织机构:如银行、供应商、募捐机构 (3)外部系统:如银行系统、工资系统、后台数据库(当要开发的是中间件时)
          • 补充存储
            • 存储的文字方面特征: **文件" "**表""**库" "**清单" *档案"
          • 补充数据流
            • 1、数据平衡原则 顶层图与0层图对比,是否有顶层图有,但0层图无的数据流,或返之。 (2)检查图中每个加工,是否存在只有入没有出,或只有出没有入,或根据输入的数据无法产生对应的输出的情况。 2、按题目说明与图进行匹配 说明中的每一句话,都能与图中有对应关系,当把说明中的实体与数据流标识出来之后,容易缩小对应范围,找出纸漏。
          • 补充加工名
            • 加工是用于处理数据流的,所以要补充加工名,请可以把该加工涉及到的数据流,在说明中标识出来,再在数据流名称所在的句子中,找"动词+名词"的结构,分析是否可作为加工。 "动词+名词"如:生成报告、发出通知、批改作业、记录分数,当然这只是普遍情况,也有例外, 如物流跟踪、用户管理。
      • 数据字典
        • 数据字典:数据字典是在DFD的基础上,对DFD中出现的所有命名元素都加以定义,使得每个图形元素的名字都有一个确切的解释。DFD和数据字典等工具相配合,就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。 数据字典中一般有6类条目,分别是数据元素、数据结构、数据流、数据存储、加工逻辑和外部实体。不同类型的条目有不同的属性需要描述。 数据字典在分析与设计阶段的作用为: 是所有人员工作的依据,统一的标准。它可以确保数据在系统中的完整性和一致性。 具体作用包括:按各种要求列表、相互参照、由描述内容格检索名称、一致性检验和完整性检验
      • ER图
        • 组成元素  关系： 1.1对1 一对一关系是指对于实体集A与实体集B，A中的每一个实体至多与B中一个实体有关系；反之，在实体集B中的每个实体至多与实体集A中一个实体有关系。  2.1对多 一对多关系是指实体集A与实体集B中至少有N(N>0)个实体有关系；并且实体集B中每一个实体至多与实体集A中一个实体有关系。  3.多对多 多对多关系是指实体集A中的每一个实体与实体集B中至少有M(M>0)个实体有关系，并且实体集B中的每一个实体与实体集A中的至少N（N>0）个实体有关系 
      • 题1数据流图&ER图
        • 2022年11月试题二 阅读以下关于软件系统设计与建模的叙述,在答题纸上回答问题1至问题3。 【说明】 煤炭生产是国民经济发展的主要领域之一,其煤矿的安全非常重要。某能源企业拟开发一套煤矿 建设项目安全预警系统,以保护煤矿建设项目从业人员生命安全。本系统的主要功能包括如下 (a)~(h)所述。 (a)项目信息维护 (b)影响因素录入 (c)关联事故录入 (d)安全评价得分 (e)项目指标预警分析 (f)项目指标填报 (g)项目指标审核 (h)项目指标确认 【问题1】(9分) 王工根据煤矿建设项目安全预警系统的功能要求,设计完成了系统的数据流图,如图2-1所示。请使 用题干中描述的功能(a)~(h),补充完善空(1)~(6)处的内容,并简要介绍数据流图在分层细化过程 中遵循的数据平衡原则。  答： 1.项目指标填报 2.项目指标审核 3.项目指标确认 4.安全评价得分 5.影响因素录入 6.项目指标预警分析 父图与子图的平衡：被细化后的子图，其输入和输出必须与父图保持一致。 子图内的平衡：加工需要有输入和输出 【问题2】(9分) 请根据【问题1】中数据流图表示的相关信息,补充完善煤矿建设项目安全预警系统总体E-R图(见图 2-2)中实体(1)~(6)的具体内容.将正确答案填在答题纸上。  答： 1.项目管理员 2.项目经理 3.项目指标数据表 4.项目信息表 5.项目预警分析表 6.事故及影响因素参数表 【问题3】(7分) 在结构化分析和设计过程中,数据流图和数据字典是常用的技术手段,请用200字以内的文字简要说 明它们在软件需求分析和设计阶段的作用。 答： 数据流图分析阶段:建立系统的功能模型,从而完成需求分析。 数据流图设计阶段:为模块划分与模块之间接口设计提供依据。 数据字典在分析与设计阶段的作用为: 是所有人员工作的依据,统一的标准。它可以确保数据在系统中的完整性和一致性 具体作用包括:按各种要求列表、相互参照、由描述内容检索名称、一致性检验和完整性检验
      • 题2 数据流图
        • 阅读以下关于软件系统建模的叙述,在答题纸上回答问题1至问题3。 【说明】 某公司欲建设一个房屋租赁服务系统,统一管理房主和租赁者的的信息,提供快捷的租赁服务。本 系统的主要功能描述如下: 1.登记房主信息。记录房主的姓名、住址、身份证号和联系电话等作信息,并写入房主信息文件。 2.登记房屋信息。记录房屋的地址、房屋类型(如平房、带阳台台的楼房、独立式住宅等)、楼层、 租金及房屋状态(待租赁、已出租)等信息,并写入房屋信息文件。一名房主可以在系统中登记 多套待租赁的房屋。 3.登记租赁者信息。记录租赁者的个人信息,包括:姓名、性别别、住址、身份证号和电话号码等, 并写入租赁者信息文件。 4.安排看房。已经登记在系统中的租赁者,可以从待租赁房屋列列表中查询待租赁房屋信息。租赁 者可以提出看房请求,系统安排租赁者看房。对于每次看房,系统会生成一条看房记录并将其写 入看房记录文件中。 5.收取手续费。房主登记完房屋后,系统会生成一份费用单,房主根据费用单交纳相应的费用。 6.变更房屋状态。当租赁者与房主达成租房或退房协议后,房主向系统提交变更房屋状态的请求。 系统将根据房主的请求,修改房屋信息文件。 【问题1】(12分) 若采用结构化方法对房屋租赁服务系统进行分析, 得到如图2-1所示的顶层DFD 使用题干中给出的 词语,给出图2-1中外部实体E1~E2、加工P1~P6 以及数据存储D1~D4的名称。  答: E1：房主 E2：租赁者 D1：房主信息文件 D2：租赁者信息文件 D3；房屋信息文件 D4：看房记录文件 P1：登记房主信息 P2：登记房屋信息 P3：登记租赁者信息 P4：查询房屋信息 P5：安排看房 P6：变更房屋状态 【问题2】(5分) 若采用信息工程(InformationEngineering)方法 对房屋租赁服务系统进行分析,得到如图2-2所示 的ERD。请给出图2-2中实体(1)~(5)的名称。  1. 房主 2.房屋 3.房主 4.租赁者 5.看房记录 【问题3】 (8分) (1)信息工程方法中的"实体(entity)"与面向对象方法中的"类(class)"之间有哪些不同之处? 答： 实体用于数据建模（面向过程）,而类用于面向对象建模。实体只有属性,而类有属性和操作。 (2)在面向对象方法中通常采用用例(Use Case)来捕获系统的功能需求。用例可以按照不同的层次来进行划分,其中的Essential Use Cases和Real Use Cases有哪些区别? 答： Essential Use Cases可翻译为抽象用例,而Real Use Cases可翻译为基础用例。他们是区别在于: 基础用例是实实在在与用户需求有对应关系的用例,是从用户需求多获取的渠道得到的,而抽象用例是从基础用例中抽取的用例的公共部分,是为了避免重复工作,优化结构而提出的用例。
      • 2019题3 数据流图
        • 某软件企业为快餐店开发一套在线订餐管理系统,主要功能包括: (1)在线订餐:己注册客户通过网络在线选择快餐店所提供的餐占品种类和数量后提交订单,系统显示订单费用供客户确认,客户确认后支付订单所列各项费用。 (2)厨房备餐:厨房接收到客户已付款订单后按照订单餐品列表选择各类食材进行餐品加工 (3)食材采购:当快餐店某类食材低于特定数量时自动向供)应商发起采购信息,包括食材类型和数量,供应商接收到采购信息后按照要求将食材送至快餐店并提交己采买购的食材信息,系统自动更新食材库存。 (4)生成报表:每个周末和月末,快餐店经理会自动收到系统先生成的统计报表,报表中详细列出了本周或本月订单的统计信息以及库存食材的统计信息。 现采用数据流图对上述订餐管理系统进行分析与设计,系统流未完成的0层数据流图如图2-1所示  问题1(8分) 根据订餐管理系统功能说明,请在图2-1所示数据流图中给出外部实体E1~E4和加工P1~P4的具体名称。 答：见图 问题2(8分) 根据数据流图规范和订餐管理系统功能说明,请说明在图2-1中需要补充哪些数据流可以构造出完整的0层数据流图。 答：见图 (1)增加El到P1数据流"餐品订单"; (2)增加P1到P2数据流"餐品订单"; (3)增加D1到的数据流"订单汇总"; (4)增加P3到E3数据流"统计报表"。 问题3(9分) 根据数据流图的含义,请说明数据流图和系统流程图之间有哪些方面的区别。 (1)数据流图中的处理过程可并行:系统流程图在某个时间点只能处于一个处理过程。 (2)数据流图展现系统的数据流:系统流程图展现系统的控制流。 (3)数据流图展现全局的处理过程,过程之间遵循不同的计时标准;系统流程图中处理过程遵循一致的计时标准。
    • 面向对象需求分析--UML图UML图
      •  这块重点关注标红和标蓝的图，容易考到 UML关系容易考到:依赖、关联、泛化、实现、组合、聚合。
      • 面向对象分析模型
        • 包含用例模型和分析模型  用例模型使用用例图 分析模型对应的图比较多，包括动态图和静态图，具体会包括类图、时序图等 需要牢记用例的三种关系 和分析模型的六种关系 用例规约也考过 用例建模的主要工作是书写用例规约。用例规约通常包括哪几部分内容? 答：用例名称、用例ID、角色、用例说明、前置条件、事件流、后置条件、扩展点、非功能需求
      • 题1 状态图
        • 根据题目填写S1~S5 
      • 题2 用例图建模
        • 某软件公司拟为物流企业开发一套库存管理系统,该系统的部分需求陈述如下: (1)库存管理系统主要包括货物入库管理、货物出库管理、仓库管理、统计报表和系统管理等功能。 (2)库存管理系统的用户包括仓库管理员、仓库经理和系统管理员,用户必须在注册后才能使用系统功能;用户可以选择使用邮件注册或电话注册。 (3)仓库管理员在进行出入库操作前必须先登录;仓库经理可以通过系统查看统计报表,如果前一个月的报表未生成,则系统自动生成统计报表,否则直接显示。 (4)系统管理员可以在系统中设置仓库温度范围,当仓库内温度超过最高值或者低于最低值时,系统自动调用温控管理操作,连接温度调节系统进行制冷或加热。 (5)仓库管理功能要求每个月1日零点对前一个月货物入库和出库记录进行数据汇总操作。 项目组决定构造用例模型以描述系统需求。 【问题1】(6分) 用例建模的首要任务是识别系统中的参与者。请根据题目中所描述的需求,识别出系统中有哪些参与者? 答： 仓库管理员 仓库经理 系统管理员 每个月1日零点 温度 温度调节系统 【问题2】(7分) 用例建模的主要工作是书写用例规约。用例规约通常包括哪几部分内容? 答：用例名称、用例ID、角色、用例说明、前置条件、事件流、后置条件、扩展点、非功能需求 【问题3】(12分) 建立了用例模型后,可以利用用例之间的关系调整用例模型,用例之间的关系包括哪几种?对于每种关系,请根据题目中所描述的需求分别给出一组用例。 答： 用例之间的关系包括扩展关系，包含关系和泛化关系。 扩展关系：查看统计报表和生成统计报表是扩展关系 包含关系：入库管理和登录之间为包含关系，入库管理包含登录 泛化关系：注册和邮件注册之间是泛化关系，邮件注册继承注册 最终图画出来为 
      • 题3 活动图
        • 某软件公司为电子商务企业开发一套网上交易订单管理系统,以提升服务的质量和效率。在项目之初,项目组决定采用面向对象的开发方法进行系统开发,并对系统的核心业务功能进行了分析,具体本描述如下: 注册用户通过商品信息页面在线浏览商品,将需要购买的商品添加进购物车内,点击"结算"按钮后开始录入订单信息。 用户在订单信息录入页面上选择支付方式,填写并确认收货人、收文货地址和联系方式等信息。点击"提交订单"按钮后产生订单,并开始进行订单结算。 订单需要在30分钟内进行支付,否则会自动取消,用户也可以手工取消订单。 用户支付完成,经确认后,系统开始备货,扣除该商品可接单数量,并移除用户购物车中的所有商品资料。 生成订单表单,出货完毕,订单生效。为用户快递商品,等待用户接收。 用户签收商品,交易完成。 【问题1】(12分) 识别设计类是面向对象设计过程中的重要工作,设计类表达了类的职责,即该类所担任的任务。请用300字以内的文字说明设计类通常分为哪三种类型,每种类型的主要职责,并针对题干描述案例涉及的具体类为每种类类型的设计类举出2个实例。 答： 1.实体类。实体类映射需求中的每个实体,保存需要存储在永久存储体中的信息,例如,用户、商品等。 2.控制类。控制类是用于控制用例工作的类,用于对一个或几个用例所特有的控制行为进行建模。例如,结算、备货等。 3.边界类。用于对系统外部环境与其内部运作之间的交互进行建模的类。例如,浏览器、购物车等。 【问题2】(3分) 在面向对象的设计过程中,活动图(activity diagram)阐明了业务用例实现的工作流程。请用300字以内的文字给出活动图与流程图(flow chart)的三个主要区别。 答： 1.活动图描述的是对象活动的顺序关系所遵循的规则,它着重表现系统的行为,而非处理过程;而流程图着重描述处理过程。 2.流程图一般都限于顺序进程,而活动图则可以支持并发进程。 3.活动图是面向对象的,而流程图是面向过程的。 【问题3】(10分) 在面向对象的设计过程中,状态图(statechart diagram)描述了一个实体基于事件反应的动态行为。请根据题干描述,填写下图中的(a)~(e)空白,完成订单处理的状态图。  a 取消订单 b 提交订单 标准答案是待结算 c 超过30分钟未支付 d 订单生效 e 签收商品
      • 题5时序图24年5月
        • 1.序列图的哪三种消息和概念。 答:序列图的三种消息和概念 同步消息 异步消息 返回消息 2.序列图补全填空 序列图的补全很简单,就是做阅读理解,因为机试无法还原题目背景,所以没法做,以往年考的一个序列图为例来看: 预约人员(患者)登录系统后发起预约挂号请求,进入预约界面。进行预约挂号时使用数据库访问类获取医生的相关信息,在数据库中调用医生列表,并调取医生出诊时段表,将医生出诊时段反馈到预的界面,并显示给预约人员:预约人员选择医生及就诊时间后确认预的,系统返回网预约结果,并向用户显示是否预约成功。 采用面向对象方法对预约挂号过程进行分析,得到如图2-2所示的顺序图,使用题干中给出的描述,完善图2-2中对象(1),及消息(2)~(4)的名称,将正确答案填在普题纸上 简要说明在描述对象之间的动态交互关系时,协作图与顺序图存在哪些区别，及选取原则。  答： 解析:在UML中,交互图(InteractionDiagrams)主要用于描述在特定语境中对象之间的交互,它 们可以在分析和设计阶段使用。交互图主要包括两种类型:序列图(SequenceDiagrams)和协作图 (Collaboration Diagrams)。 序列图:强调消息的时间顺序,展示对象之间的动态合作关系,常用于分析阶段。 协作图:强调参与交互的对象以及它们如何相互关联,常用于设计阶段 在分析阶段,你可能想要创建序列图来捕捉对象之间的动态合作,并且能够清晰地展示时序和并发。 在设计阶段,你可能想要创建协作图来定义交互模式,并且能够清晰地展示对象之间的静态关系和 它们之间的关联。 3.顺序图表示条件分支序列片段有哪些。 答:顺序图表示条件分支序列片段包括: Alt:用于条件分支,有多个互斥的条件。 0pt:用于可选行为,只有一个条件。 Loop:用于循环操作,根据条件重复执行。 Break:用于中断行为,根据条件跳出当前片段。 Par:用于并行操作,多个消息序列同时执行。 Critical:用于临界区,确保操作的原子性。 Neg:用于不应发生的行为,表示错误情况。 Ref:用于引用其他序列图,实现模块化和重用。
      • 题4SysUML-23年11月
        • 23年考题 阅读以下关于软件系统设计与建模的叙述,在答题纸上回答问题1至问题3 【说明】 背景不详,应该是某个信息系统说明,然后会有两种获取需求的方案,一种是使用UML里的用例 图,另一种是使用SysML里的需求图。 根据学员回忆,文老师预测,背景与问题无关,不影响作答。 【问题1】 请分别给出SysML建模的需求图与UML建模的用例图的定义,并说明二者的区别。 答： 用例图描述了系统中参与者与用例之间的关系，描述了系统的功能，用于用例建模。 需求图描述了系统中用文字表示的需求，展现了需求之间的关系。 区别在于： 1.对于需求的描述方式不同，需求图用文字的方式描述需求，用例图用图形的方式描述需求 2.对于需求的描述角度不同，需求图是反应系统内部的功能和流程，用例图是从用户的角度去描述需求 【问题2】(非原题原图,文老师自己出的) 请给出需求图的七种关系及其定义。某车企的混合动力SUV系统需求图如下图所示,请将选项中 的内容填到图中(1)-(5)处。 A:质量需求 B:功能需求 C:性能要求:环保 D:性能要求:表现 E:性能要求:排放 F:性能要求:燃油经济  答： 复合、复制、派生、细化、满足、验证、追溯 口诀：复复派细满验追 填空： 【问题3】据反馈是用例图填空,很简单,历年考题多,就不自己出了,拿之前考题一个问来看看: 某医院拟委托软件公司开发一套预约挂号管理系统,以便为患者提供更好的就医体验,为医院提供 更加科学的预约管理。本系统的主要功能描述如下: (a)注册登录,(b)信息浏览,(c)账号管理,(d)预约挂号,(e)查询与取清预约,(F)号源管理,(g 报告查询,(h)预约管理,(i)报表管理和(j)信用管理等。 若采用面向对象方法对预约挂号管理系统进行分析,得到如口图2-1所示的用例图。请将合适的参与 者名称填入图2-1中的(1)和(2)处,使用题干给出的功能描述(a)~(j),完善用例(3)~(12)的名称, 将正确答案填在答题纸上。 
      • 历年考题问题
        • 协作图与顺序图
          • 1. 简要说明在描述对象之间的动态交互关系时,协作图与顺序图存在哪些区别。 答： 顺序图是显示对象之间交互的图,其着重描述对象按时间顺序的消息交换。 协作图用于表示发送和接收消息的对象之间的组织结构，强调对象之间的消息收发关系。
        • 对象模型、动态模型和功能模型
          • 采用面向对象方法开发软件,通常需要建立对象模型、动态模型和功能模型,请分别介绍这3种模型,并详细说明它们之间的关联关系,针对上述模型,说明哪些模型可用于软件的需求分析? 答： 对象模型用于描述系统中对象的静态结构，主要用对象图来实现 动态模型用于描述系统控制结构，主要用状态图来实现 功能模型用于描述系统功能，主要用DFD来实现。 这3种模型都涉及数据、控制和操作等共同的概念,但侧重点不同,从不同侧面反映了系统的实质性内容,综合起来全面地反映了对目标系统的需求。 功能模型指明了系统应该"做什么"; 动态模型明确规定了什么时候做; 对象模型则定义了做事情的实体。 对象模型、动态模型和功能模型均可用于软件的需求分析。
    • 设计模式
      • 多年未考，已从教材移除
      • 题1
        • 某软件企业为影音产品销售公司W开发一套在线销售系统,以提升服务的质量和效率。项目组经过讨论 后决定采用面向对象方法开发该系统。在设计建模阶段需要满足以下设计要求。 (1)W公司经常进行促销活动。根据不同的条件(如订单总额、商品数量、产品种类等),公司可以提供百分比折扣或现金减免等多种促销方式供提交订单的用户选择。实现每种促销活动的代码量很大,且会随促销策略的不同经常修改。系统设计中需要考虑现有的促到和新的促销,而不用经常地重写控制器类代码。 (2)该在线销售系统需要计算每个订单的税率,不同商品的税率及计算方式会有所区别。所以W公司决定在系统中直接调用不同商品供应商提供的税率计算类,但每个供应商的类提供了不同的调用方法。系统设计中需要考虑如果公司更换了供应商,应该尽可能少地在在系统中修改或创建新类。 项目组架构师决定采用设计模式来满足上述设计要求,并确定从当前已经熟练掌握的设计模式中进行选择,这些设计模式包括:适配器模式(Adapter)、构造器模式(Builder)、命令模式(Command)、外观模式(Facade)、中介模式(Mediator)、原型模式(Prototype)、代理模式(Proxy)、状态模式(State)和策略模式(Strategy)等。 【问题1】 设计模式按照其应用模式可以分为三类:创建型、结构型和行为型,请用200字以内文字说明三者的作用。 答： 创建型模式主要用于创建对象,为设计类实例化新对象提供指南 结构型模式主要用于处理类或对象的组合,对类如何设计以形成更大的结构提供指南。 行为型模式主要用于描述类或对象的交互以及职责的分配,对类之间交互以及分配责任的方式提供指南。 【问题2】 请将项目组已经掌握的设计模式按照其作用分别归类到创建型、结构型和行为型模式中。 答： 创建型：构造器模式(Builder)，原型模式(Prototype) 结构型：适配器模式(Adapter)，代理模式(Proxy)，外观模式(Facade) 行为型：命令模式(Command)，中介模式(Mediator)，状态模式(State)，策略模式(Strategy) 【问题3】 针对题目中所提出的设计要求(1)和(2),项目组应该分别选择何种设计模式?请分别用200字以 内文字说明具体的解决方案。 1.策略模式 解决方案:在具有公共接口的独立类中定义每个计算。可以利用该模式创建各种促销类,它们从同一个超类继承。每个类都有相同名称的标准接口方法,用于根据订单编号计算将要折扣的金额总数。计算每个促销的内部代码对促销类来说完全不同。 2.适配器模式 解决方案:增加一个类作为适配器,转换类的接口到客户端类期用望的另一个接口。实现一个适配器类,这个类为系统的其他部分分提供了一个不变的方法供调用,为了集成不同商品供应商提供的税率计算类,编写一个适配器类的子类,包含调用购买类所需的代码。该子类将系统的调用映射到某个供应商的税率计算类。如果要更更换供应商,那么只需要写一个新的适配器子类,其他保持不变。
    • 项目管理
      • PERT图
        • PERT(项目评估与评审技术)图是一种图形化的网络 模型,描述一个项目中任务和任务之间的关系,每个节 点表示一个任务,通常包括任务编号、名称、开始和结 束时间、持续时间和松弛时间。  可能会考到求关键路径之类的题 也可能考总浮动时间： 总浮动时间(总时差、松弛时差）:在不延误项目完工时间且不违反进度制约因素的前提下, 活动可以从最早开始时间推迟或拖延的时间量,就是该活动的进度灵活性。正常情况下,关键活 动的总浮动时间为零。 总浮动时间=最迟来始LS-最早开始ES或最迟完成LF-最单完成EF或关键路径-非关键路径时长 顺推 逆推 PERT图主要描述不同任务之间的依赖关系;Gantt图主要描述不同任务之间的重叠关系。
      • 题1
        • 阅读以下关于某项目开发计划的说明,在答题纸上回答问题1至问题[4。 【说明】某软件公司拟开发一套电子商务系统,王工作为项目组负责责人负责编制项目计划。由于 该企业业务发展需要,CEO急于启动电子商务系统,要求王工尽快准备一份拟开发系统的时间和 成本估算报告。 项目组经过讨论后,确定出与项目相关的任务如表2-1所示。其中,根据项目组开发经验,分别给 出了正常工作及加班赶工两种情况下所需的时间和费用。  【问题1】(7分) 请用400字以内文字说明王工拟编制的项目计划中应包括哪些内容。 答： (1)项目背景 (2)项目经理、项目经理的主管领导、客户方联系人、客户方的的主管领导,项目领导小组(项目 管理团队)和项目实施小组人员 (3)项目的总体技术解决方案 (4)所选择的项目管理过程及执行水平 (5)对这些过程的工具、技术和输入输出的描述 (6)选择的项目的生命周期和相关的项目阶段 (7)项目最终目标和阶段性目标 (8)进度计划 (9)项目预算 (10)变更流程和变更控制委员会 (11)对于内容、范围和时间的关键管理评审,以便于确定悬留问题和未决决策 【问题2】(8分) 请根据表2-1,分别给出正常工作和最短工期两种情况下完成此项目所需的时间和费用。 答： 正常工作成本=74200元。正常工作工期=41天。加班最短工期成本=91600元。最短工期=27 天。 注意：费用是把是所有花费都加起来，而不是只加关键路径上的。 【问题3】(4分)如果项目在系统调研阶段用了7天时间才完成,公司要求尽量控制成本,王工 可在后续任务中采取什么措施来保证项目能按照正常工作进度完成? 答： 在"B提交项目计划"和"I安装部署"任务中采用加班工作措施,以使得能够按照正常 工作进度完成。 注意： 需要算出压缩一天所增加的费用 【问题4】(6分) 如果企业CEO想在34天后系统上线,王工应该采取什么措施来满足这一要求?这种情况下完成项 目所需的费用是多少? 答： 标准时长41天的任务,要34天完成,应赶工7天。具体赶工的任务包括:将A、B、H、I 四个任务加班完成,这样正好弥补之前延误的7天工期,最终以79700元完成项目  注意：压缩关键路径上的时间
    • 信息安全
      • 信息安全:各种加密技术的应用,包括对称加密、非对称加密、信息摘要、数字签名、数字证书 等。 对称加密性能好，适合加密大数据 非对称加密适合加密小数据
    • 其他考题
      • 2022软件需求到架构的映射
        • 王工指出,软件开发中需求分析是根本,架构设计是核心,不考虑软件需求便进行软件架构设计很可能导致架构设计的失败,因此,如何把软件需求映射到软件架构至关重要。请从描述语言、非功能性需求描述、需求和架构的一致性等三个方面,用300字以内的文字说明软件需求到架构的映射存在哪些难点。 答： 软件需求通常以非正规的自然语言形式频繁获取。而软件架构则则更倾向于使用一种更为正式、结构化的语言来描述系统的组件,接口、通信和交互方式。 非功能属性(如性能、安全性、可用性等)在软件需求中通常被描述为系统属性,但在架构模型中形成规约却较为困难。这是因为非功能属性往往涉及多个系统组件和交互,需要综合考虑多个方面,而架构模型则可能更侧重于描述系统的结构和功能。 从软件需求映射到软件架构的过程中,保持一致性和可追溯性也是一个复杂的任务。由于单一的软件需求可能涉及多个软件架构的关注点,而一个架构元素也可能对应多个软件需求,因此确保保它们之间的映射关系是准确且可追溯的非常重要。
  • 数据库专题
    •  数据库设计关注的问题： 性能 数据一致性 安全
    • ORM
      • ORM,即Object-Relationl Mapping,它在关系型数据库和对象之之间作一个映射,这样,我们在具体 的操作数据库的时候,就不需要再去和复杂的SQL语句打交道,只要像平时操作对象一样操作即可。 面向对象编程把所有实体看成对象(object),关系型数据库则是采用实体之间的关系(relation) 连接数据。很早就有人提出,关系也可以用对象表达,这样的话,就能使用面向对象编程来操作 关系型数据库。 ORM把数据库映射成对象。如: 数据库的表(table)-->类(class) 记录(record,行数据)-->对象(object) 字段(field)-->对象的属性(attribute) ORM优点: 1、使用ORM可以大大降低学习和开发成本。 2、程序员不用再写SQL来进行数据库操作。 3、减少程序的代码量。 4、降低由于SQL代码质量差而带来的影响。 ORM缺点 1、不太容易处理复杂查询语句。 2、性能较直接用SQL差。
    • 数据库分类比较
      • 关系型数据库:关系数据库,是建立在关系模型基础上的数据库,借助集合代数等数学概念和 方法来处理数据库中的数据。现实世界中的各种实体以及实体又之间的各种联系均用关系模型来表 示。简单说,关系型数据库是由多张能互相联接的二维行列表林各组成的数据库。 NoSQL: 泛指非关系型的数据库。随着互联网的兴起,传统的关系数据库在应付超大规模和高 并发的纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于 其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数 据种类带来的挑战,尤其是大数据应用难题,包括超大规模数居的存储。 内存数据库:将数据库整体存储在内存中,提高性能。
      • 详细对比
        •   
        • 比较关系型数据库和NoSQL数据库
          •  
      • 内存数据库-缓存技术
        • 缓存技术： 1.MemCache:Memcache是一个高性能的分布式的内存对象缓存系统,用于动态Web应用以 减轻数据库负载。Memcache通过在内存里维护一个统一的巨大的hash表,它能够用来存储各种 格式的数据,包括图像、规频、文件以及数据库检索的结果等。 2.Redis:Redis是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、 Key-Value数据库,并提供多种语言的API。 Redis与Memcache的差异 1、Redis和Memcache都是将数据存放在内存中,都是内存数据库。他们 。同时Memcache还可用于缓存其他东西,例如图片、视频等等,Redis还支持list、set、hash等数据结构的存储。 2、在Redis中,并不是所有的数据都一直存储在内存中的。这是和Memcache相比一个最大的区 别。当物理内存用完时,Redis可以将一些很久没用到的value交换到磁盘。 5、Redis在很多方面支持数据库的特性,可以这样说他就是一个数据库系统,而Memcache只是 简单地K/V缓存。
      • 题1
        • 阅读以下关于分布式数据库缓存设计的叙述,在答题纸上回答问题1至问题3 【说明】 某企业是为城市高端用户提供高品质蔬菜生鲜服务的初创企业,创业初期为快速开展业 务,该企业采用轻量型的开发架构(脚本语言+关系型数据库)研制了一套业务系统。业务开展后 受到用户普遍欢迎,用户数和业务数量迅速增长,原有的数据库服务务器已不能满足高度并发的业 务要求。为此,该企业成立了专门的研发团队来解决该问题。 张工建议重新开发整个系统,采用新的服务器和数据架构,解决当前问题的同时为日后 的扩展提供支持。但是,李工认为张工的方案开发周期过长,投入过大,当前应该在改动尽量小 的前提下解决该问题。李工认为访问量很大的只是部分数据,建议用缓存工具MemCache来减 轻数据库服务器的压力,这样开发量小,开发周期短,比较适合合初创公司,同时将来也可以通过 集群进行扩展。然而,刘工又认为李工的方案中存在数据可靠生和一致性问题,在宕机时容易丢 失交易数据,建议采用Redis来解决问题。在经过充分讨论,该公司最终决定采用刘工的方案。 在李工和刘工的方案中,均采用分布式数据库缓存技术来解决问题。请说明分布式教报属库缓存的 基本概念。 表4-1中对MemCache和Redis两种工具的优缺点进行了比较,请补充完善表4-1中的空(1) (6)。  答： (1) key/value,list,set, hash,sorted (2)不支持(3)不支持(4)不支持(5)有(6)不支持 【问题2】(8分) 刘工认为李工的方案存在数据可靠性和一致性的问题,请说明原因1. 为避免数据可靠性和一致性的问题,刘工的方案采用Redis作为数据库缓存,请说明基本的Redis 与原有关系数据库的数据同步方案。 答： (1)Memcache没有持久化功能,数据全在内存中，所以掉电数据会全部丢失,而且无法直接恢复,这存在可靠性问题。 (2)Memcache不支持事务,所以操作过程中可能产生数据的不一致性。 同步方案:读取数据时,先读取Redis中的数据,如果Redis没有,则从原数据库中读取,并同步更 新Redis中的数据,写回时,写入到原数据库中,并同步更新至Redis中 【问题3】 (8分) 请给出Redis分布式存储的2种常见方案和Redis集群切片的几种常见方式。 答： Redis分布式存储的2种常见方案: 1.主从 2.Cluster Redis集群切片的常见方式: 1.客户端切片,即在客户端就通过key的hash值对应到不同的服务子器 2.对数据根据key散列到不同的slot上,不同的slot对应到不同服务器。
    • 并发控制
      • 事务对数据是否要修改，要修改加写锁，不要修改加读锁。
    • 规范化与反规范化
      • 一般会考规范化有什么问题，不规范化有什么问题 不规范化带来的四大问题 没有一个关系模式R(SNAME,CNAME,TNAME,TADDRESS),其属生分别表示学生姓名、选修 的课程名、任课教师姓名和任课教师地址。仔细分析一下,就会发现这个模式存在下列存储异常 的问题:】. (1)数据冗余:数据被重复存储,如某门课程有100个学生选修,那么在R的关系中就要出现100 个元组,这门课程的任课教师姓名和地址也随之重复出现100次。 (2)修改异常:修改导致数据不一致,如由于上述冗余问题,当需要修改这个教师的地址时,就 要修改100个元组中的地址值,否则就会出现地址值不一致的现象。 (3)插入异常:插入时异常,如不知道听课学生名单,这个教师的任课清况和家庭地址就无法进 入数据库。 (4)删除异常:删除了不该删除的数据,如当只有一条记录时,要删除这个学生选课信息,会将 课程名、教师名和教师地址都给删除了。 反规范化技术: 规范化设计后,数据库设计者希望牺牲部分规范化来提高性能 采用反规范化技术的益处: 降低连接操作的需求、降低外码和家索引的数目,还可能减少表的数目,能够提高查询效率。 可能带来的问题: 数据的重复存储,浪费了磁盘空间;可能出现数据的完整性问题,为了保障数 据的一致性,增加了数据维护的复杂性,会降低修改速度。 具体方法: (1)增加冗余列:在多个表中保留相同的列,通过增加数据冗余减少少或避免查询时的连接操作。 (2)增加派生列:在表中增加可以由本表或其它表中数据计算生成的列,减少查询时的连接操作 并避免计算或使用集合函数。 (3)重新组表:如果许多用户需要查看两个表连接出来的结果数据,则把这两个表重新组成一个 表来减少连接而提高性能。 (4)水平分割表:根据一列或多列数据的值,把数据放到多个独立的表中,主要用于表数据规模 很大、表中数据相对独立或数据需要存放到多个介质上时使用。 (5)垂直分割表:对表进行分割,将主键与部分列放到一个表中,主键与其它列放到另一个表中, 在查询时减少1/0次数。
    • 分布式数据库
      • 考试可能让你答分布式数据库的特点和优点
      • 优点
        • (1)分布式数据库可以解决企业部门分散而数据需要相互联系的问题。 (2)如果企业需要增加新的相对自主的部门来扩充机构,则分布式数据后库系统可以在对当前机构 影响最小的情况下进行扩充。 (3)分布式数据库可以满足均衡负载的需要。 (4)当企业已存在几个数据库系统,而且实现全局应用的必要性增加时,就可以由这些数据库自 下而上构成分布式数据库系统。 (5)相等规模的分布式数据库系统在出现故障的概率上不会比集中式数据库系统低,但由于其故 障的影响仅限于局部数据应用,因此,就整个系统来说,它的可靠性是比较高的。
      • 2019题1
        • 阅读以下关于分布式数据库缓存设计的叙述,回答问题1至问题3。 【说明】 某初创企业的主营业务是为用户提供高度个性化的商品订购业务,其业务系统支持PC端、手机App等多种访问方式。系统上线后受到用户普遍欢迎,在线用户数和订单数量迅速增长,原有的关系数据库服务器不能满足高速并发的业务要求。 为了减轻数据库服务器的压力,该企业采用了分布式缓存系统,》将应用系统经常使用的数据放置在内存,降低对数据库服务器的查询请求,提高了系统性能。在使用缓存系统的过程中,企业碰到了一系列技术问题 【问题1】(11分) 该系统使用过程中,由于同样的数据分别存在于数据库和缓存系统中,必然会造成数据同步或数据不一致性的问题。该企业团队为解决这个问题,提出了如下解决思路: 应用程序读数据时,首先读缓存,当该数据不在缓存时,再读取数据库;应用程序写数据时,先写缓存,成功后再写数据库;或者先写数据库,再写缓存。 王工认为该解决思路并未解决数据同步或数据不一致性的问题,请用100字以内的文字解释其原因。 王工给出了一种可以解决该问题的数据读写步骤如下: 读数据操作的基本步骤: 1.根据key读缓存; 2.读取成功则直接返回; 3.若key不在缓存中时,根据key(a); 4.读取成功后,(b); 5.成功返回。 写数据操作的基本步骤: 1.根据key值写(c); 2.成功后(d); 3.成功返回。 请填写完善上述步骤中(a)~(d)处的空白内容。 答： 关于数据同步的潜在问题,当执行写入操作时,存在一种称为双写不一致的隐患。具体而言,有时我们可能遇到缓存写入成功但数据库写入失败,或者数据库写入成功而缓存更新失败的情况,这会导致数据在两个存储系统之间出现不一致。此外,当多个请求发生时,也可能产生读写冲突的并发问题。 (a)从数据库中读取数据或读数据库 (b)更新缓存中key值或更新缓存 (c)数据库 (d)删除缓存key或使缓存key失效或更新缓存(key值) 【问题2】(8分) 缓存系统一般以key/value形式存储数据,在系统运维中发现,部分针对缓存的查询,未在缓存系统中找到对应的key,从而引发了大量对数据库服务器的查询请求,最严重时甚至导致了数据居库服务器的宕机 经过运维人员的深入分析,发现存在两种情况: (1)用户请求的key值在系统中不存在时,会查询数据库系统,加大了数据库服务器的压力; (2)系统运行期间,发生了黑客攻击,以大量系统不存在的随机key发起了查询请求,从而导致了数据库服务器的宕机。 经过研究,研发团队决定,当在数据库中也未查找到该key时,在缓存系统中为key设置空值,防止对数据库服务器发起重复查询。 请用100字以内文字说明该设置空值方案存在的问题,并给出解决思路。 答： 存在问题:不在系统中的key值是无限的,如果均设置key值为空,会造成内存资源的极大浪费,引起性能急剧下降。 解决思路:查询缓存之前,对key值进行过滤,只允许系统中存在的key进行后续操作(例如采用key的bitmap进行过滤)。 【问题3】(6分) 缓存系统中的key一般会存在有效期,超过有效期则key失效;有时也会根据LRU算法将某些key移出内存。当应用软件查询key时,如key失效或不在内存,会重新读取数据库,并更新缓存中的key。 运维团队发现在某些情况下,若大量的key设置了相同的失效时间,导致缓存在同一时刻众多key同时失效,或者瞬间产生对缓存系统不存在key的大量访问,或者缓存系统重启等原因,都都会造成数据库服务器请求瞬时爆量,引起大量缓存更新操作,导致整个系统性能急剧下降,进而造成整个系统崩溃。 请用100字以内文字,给出解决该问题的两种不同思路。 答： 缓存key值同时失效导致系统性能急剧下降甚至崩溃的问题,可能的解决方案包括: (1)缓存失效后,通过加排它锁或者队列方式控制数据库写缓存的线程数量,使得缓存更新串行化; (2)给不同key设置随机或不同的失效时间,使失效时间的分布尽量均匀; (3)设置两级或多级缓存,避免访问数据库服务器。
    • 数据仓库
      • 有可能考到回答数据仓库的四个特点： (1)集成的数据。(2)面向主题。(3)数据相对稳定。(4)包含历史信息。
    • 历年考试问题汇总
      • 1. 在系统初步运行后,发现系统数据访问性能较差。经过分析,刘工认为原来数据库规范化设计后,关系表过于细分,造成了大量的多表关联查询,影响了性能。例如当用户查询商品信息时,需要要同时显示该药品的信息、供应商的信息、当前库存等信息。 为此,刘工认为可以采用反规范化设计来改造药品关系的结构,以提高查询性能。修改后的药品关系结构为:药品(药品ID,药品名称,药品型号,药品价格,供应商ID,供应商名称,当前库存数量); 请用200字以内的文字说明常见的反规范化设计方法,并说明用户查询商品信息应该采用哪种反规范化设计方法。 答： 反规范化的目的就是提高查询性能,是在规范化之后单纯为了提高查询效率,而特意降低规范化要求的一种设计方法。核心思想是增加数据冗余,常见的方法有: (1)增加冗余列:指在多个表中具有相同的属性列,常用来在查询的避免连接操作。 (2)增加派生列:指增加的列可以通过表中其他属性列加工计算生成,作用是查询时减少计算量。 (3)重新组表:如果需要经常查询两个表连接之后的数据,则把这两两个表重新组成一个表来减少连接而提高性能。 (4)表分割:通过将较大的表分割为多个较小的表来提高查询性能,包括水平分割和垂直分割。 根据题干中描述的修改后的关系模式,该系统适合采用增加1冗余列/冗余列方法。 2.王工认为,反规范化设计可提高查询的性能,但必然会带来数据的不一致性问题。请用200字以内的文字说明在反规范化设计中,解决数据不一致性问题的三种常见方法,并说明该系统应该采用哪种方法。 答：常见的解决反规范化设计数据不一致问题的方法有三种: (1)应用程序同步:指的是通过应用程序在更新数据的同时,同步更更新对应的冗余数据,这两个操作会放到同一个事务中,从而保证两个操作的原子性。 (2)触发器同步:触发器是与表事件相关的特殊存储过程,它由执行事件来触发,由数据库管理系统在后台自动执行。常见的方法是在更新数据的表上增加相应事件的触发器,在触发器内容同步更新冗余数据。 (3)批处理同步:这种方法一般应用在对数据一致性要求不高的场景下。当更新数据操作执行了一段时间后,根据更新数据进行批量的同步操作,使得冗余数据和更新数据保持一致。 该系统适合采用触发器同步,因为该方法在解决查询性能的同时一致性最高。
      • SQL注入攻击
        • 该物流车辆管理系统需抵御常见的SQL注入攻击,请用200字以内的文字说明什么是SQL注入攻击,并列举出两种抵御SQL注入攻击的方式。 答： SQL注入攻击,就是通过在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句,最终达到欺骗服务器执行恶意的SQL命令。 可以通过以下方式抵御SQL注入攻击: 使用正则表达式; 使用参数化的过滤性语句; 检查用户输入的合法性; 用户相关数据加密处理; 存储过程来执行所有的查询; 使用专业的漏洞扫描工具。
      • 题1 规范化与反规范化
        • 某集团公司在各省均设有分公司,现欲建立全国统一的销售管理信息系统,以便 总公司及时掌握各分公司的销售情况。公司成立专门的项目组进行该系统的研发工作, 其中张工负责其中的数据库设计工作。 张工和需求分析小组紧密合作,在设计出数据流图和数据字典的基础上,给出了 数据库关系模式和相应的索引设计。同时考虑到未规范化关系模式可能引起的各类数 据错误,对关系模式进行了全面的规范化处理,使所有关系模式均达到了3NF或 BCNF 在项目实施过程中,应用开发小组认为该设计方案未考虑应用功能的实际需求。 如果严格按照设计方案实施,会对应用系统中整体性能产生较大影响。主要的原因在 于进行数据查询时,会产生大量的多表连接操作,影响性能。而设计方案中的索引设 计,并不能完全满足数据查询的性能要求。 应用开发小组还认为,该设计方案未考虑到信息系统中核心销售数据处理的特点: 各分公司在使用该信息系统时只能操作自己分公司的销售数据,无权操作其它分公司 的销售数据;只有总公司有权利操作所有销售数据,以便进行统计分析 应用开发小组要求,在数据库设计方案中,必须针对实际应用功能的实现来考虑 关系模式的规范化,必要时需要采用逆规范化或解除规范化的方法来保证性能要求。 【问题1】(8分) 系统需要管理供应商和货物等信息,具体包括供应商姓名、地址以及货物名称、价格 等,供应商可以提供0~n种货物,其公司地址也可能发生变化。请以供应商关系模式 supplier(name,address,product,price)为例,解释不规范的关系模式存在哪些问题。 分析： 画出关系图如上 答： 数据冗余:关系模式中多次重复记录了同一供应商的地址。 插入异常:如果还未确定一个供应商有哪些货物,只是想添加一个供应商的地址信息,则会产生产品与 价格均为空的记录。 修改异常:当修改一个供应商的地址时,需要将多条记录同时更新,若未同时时更新,则数据产生不一致。 删除异常:当删除一个供应商的产品时,其地址信息被一并删除。 【问题2】(6分) 应用开发小组认为张工的规范化设计虽然解决了未规范化关系模式带来的问题,但实 际实现功能时会造成系统性能的下降,请解释其原因。 答：数据库规范化的过程,实际是对数据表的不断拆分,以达到更高的规范程度。这样处理,带来的问题是:系 统中大量查询不能通过单表完成,而需要将多表进行连接查询,所以表拆分得越多,查询性能也就越差。 【问题3】(5分) 请解释逆规范化方法,说明其优缺点。 答： 规范化设计后,数据库设计者希望牺牲部分规范化来提高性能,这种从规范化设计的回退方法称为反规范化 技术。 逆规范化方法优点:提高统计、查询效率。 逆规范化方法缺点:增加了数据冗余,浪费存储空间,增、删、改操作的效率降低,可能导致数据不一致, 可能产生添加、修改、删除异常。 【问题4】(6分) 针对该信息系统中核心销售数据处理的特点,如采用关系表水平分割的逆规范化方法, 请给出具体的解决方案,并说明该方案存在的问题。 答： 解决方案:将各省的数据存放于各省分公司。 该方案主要问题: (1)在于总公司进行全国数据统计时,需要从各省服务器调取数据,效率较低。 (2)执行应用功能时需要动态选择分公司的数据库表,增加了应用程序的复杂度。
      • 题2 视图
        • 【说明】 某软件企业开发一套类似于淘宝网上商城业务的电子商务网站。该系统涉及多种用户角 色,包括购物用户、商铺管理员,系统管理员等。 在数据库设计中,该系统数据库的核心关系包括: 产品(产品编码,产品名称,产品价格,库存数量,商铺编码) 商铺(商铺编码,商铺名称,商铺地址,商铺邮箱,服务电话) 用户(用户编码,用户名称,用户地址,联系电话) 订单(订单编码,订单日期,用户编码,商铺编码,产品编码,产品数量,订单总价) 不同用户角色有不同的数据需求,为此该软件企业在基本数据库关系模式的基础上,定 制了许多视图。其中,有很多视图涉及到多表关联和聚集函数运算。 【问题1】(8分) 商铺用户需要实时统计本商铺的货物数量和销售情况,以便及时补货,或者为商铺调整 销售策略。为此专门设计了可实时查看当天商铺中货物销售情况和存货情况的视图,商铺产 品销售情况日报表(商铺编码,产品编码,日销售产品数量,库存数量,日期)。 数据库运行测试过程中,发现针对该视图查询性能比较差,不满足用户需求。 请说明数据库视图的基本概念及其优点,并说明本视图设计导致查询性能较差的原因。 答： 视图是虚表,是从一个或几个基本表(或视图)中导出的表,在系统的数据字典中仅存放了视图的定义,不存放视图对应的数据。 视图的优点: 1、视图能简化用户的操作 2、视图机制可以使用户以不同的方式查询同一数据 3、视图对数据库重构提供了一定程度的逻辑独立性 4、视图可以对机密的数据提供安全保护 查询性能较差的原因是视图中"日销售产品数量"需要针对订单表做统计分析,订单表中有数量庞大的历史销售记录,所以这种操作极为耗时。 【问题2】(8分) 为解决该视图查询性能比较差的问题,张工建议为该数据建立单独的商品当天货物销售、 存货情况的关系表。但李工认为张工的方案造成了数据不一致的问题,必须采用一定的手段 来解决。 1)说明张工方案是否能够对该视图查询性能有所提升,并解释释原因 2)解释说明李工指出的数据不一致问题产生的原因。 答： 张工方案能够对该视图查询性能有所提升,因为这样做能极大的减少统计分析的数据量,对小数据量进行统计,性能是能得以保障的。 2)由于当日订单数据既存储在订单表中,又存储在单独的当天货勿销售、存货情况表中。同一数据存储了两份,一旦出现修改,未同步修改,则会造成数据不一致。 【问题3】(9分) 针对李工提出的问题,常见的解决手段有应用程序实现,触发器实现和物化视图实现等, 请用300字以内的文字解释说明这三种方案。 答： 应用程序实现:在进行订单的添加、修改、删除操作时,从应用程序中,控制对两个数据表都进行相关操作,以保障数据的一致性。 触发器实现:在应用程序中,只对订单表进行操作。但写触发器,当订单表发生变化时,把当日订单内容同步更新到当天货物销售、存货情况表中。 物化视图实现:建立"当天货物销售、存货情况"的物化视图,物化视图会把相应的数据物理存储起来,而且在订单表发生变化时,会自动更新。
      • 2020题3关系型数据库
        • 阅读下列说明,回答问题1至问题3,将解答填入对应栏内。 【说明】 某企业委托软件公司开发一套包裹信息管理系统,以便于对该企业通过快递收发的包裹信息进行统一管理。在系统设计阶段需 要对不同快递信息的包裹单信息进行建模,其中,邮政包裹单如图2-1所示:  【问题1】(14分) 请说明关系型数据库开发中,逻辑数据模型设计过程包含哪些任务?该包裹单的逻辑数据模型中应该包含哪些实体?并指出每个关系模式的主键属性。 答： 1.将实体-联系模型转换为关系模型 2.利用规范化技术对建立的逻辑数据模型进行优化，满足范式要求。 包含的实体： 收件人，主键为电话 寄件人，主键为电话 包裹单，主键为运单号 【问题2】(6分) 请说明什么是超类实体?结合图中包裹单信息,试设计一种超类实体,给出完整的属性列表。 答： 超类实体是将多个实体中相同的属性组合起来构造出的新实体 用户(姓名、电话、单位名称、详细地址) 【问题3】(5分) 请说明什么是派生属性?结合图2-1中包裹单信息说明哪个属性是是派生属性。 答： 派生属性是指某个实体的非主键属性由该实体其他非主键属性决定。 简言之，可以从其它属性得来的属性就叫派生属性。 包裹单中的总计是由资费、挂号费、保价费、回执费计算算得出,所以是派生属性
      • 2021题4规范化反规范化&redis
        • 阅读以下关于数据库设计的叙述,回答问题1至问题3。 【说明】 某医药销售企业因业务发展,需要建立线上药品销售系统,为用户提供便捷建的互联网药品销售服务。该系统除了常规药品展示订单、用户交流与反馈功能外,还需要提供当前热销产品排名、评价分类管理等功能。通过对需求的分析,在数据管理上初步决定采用关系数据库(MySQL)和数据库缓存(Redis)的混合架构实现经过规范化设计之后,该系统的部分数据库表结构如下所示。 供应商(供应商ID,供应商名称,联系方式,供应商地址): 药品(药品ID,药品名称,药品型号,药品价格,供应商ID); 药品库存(药品ID,当前库存数量); 订单(订单号码,药品ID,供应商ID,药品数量,订单金额)。 [问题1](9分) 在系统初步运行后,发现系统数据访问性能较差。经过分析,刘工认为原来数据库规范化设计后,关系表过于细分,造成了大量的多表关联查询,影响了性能。例如当用户查询商品信息时,需要同时显示该药品的信息、供应商的信息、当前库存等信息。 为此,刘工认为可以采用反规范化设计来改造药品关系的结构,以提高查询性能。 修改后的药品关系结构为:药品(药品ID, 药品名称, 药品型号 ,药品价格, 供应商ID, 供应商名称, 当前库存数量); 请用200字以内的文字说明常见的反规范化设计方法,并说明用户查询商品信息应该采用哪种反规范化设计方法 答： 常见的反规范化技术包括: (1)增加冗余列:增加冗余列是指在多个表中具有相同的列,它常用来在查询时避免连接操作。 (2)增加派生列:增加派生列指增加的列可以通过表中其他数据计算生成。它的作用是在查询时减少计算量,从而加快查询速度。 (3)重新组表:重新组表指如果许多用户需要查看两个表连接出来的结果数据,则把这两个表重新组成一个表来减少连接而提高性能。 (4)分割表:有时对表做分割可以提高性能。 用户查询商品信息应该采用:增加冗余列。 用户查询商品信息时,需要显示药品信息(药品表中),供应商信息(供应商表,库存信息(库存表中),此时查询的是药品表但表中缺了供应商的信息和库存信息,可以通过增加冗余列的方式把这些信息并过来。以避免连接操作带来的查询性能下降 [问题2](9分) 王工认为,反规范化设计可提高查询的性能,但必然会带来数据的不一致性问题。请用200字以内的文字说明在反规范化设计中,解决数据不一致性问题的三种常见方法,并说明该系统应该采用哪种方法。 答： 针对反规范化数据不一致问题,可采用的解决方案包括: 1、触发器数据同步：对数据的任何修改立即触发对复制列或派生列的相应修改。 2、应用程序数据同步：要求必须在同一事务中对所有涉及的表进行增、删、改操作。 3、批处理同步 : 对复制列或派生列的修改积累一定的时间后,运行一批处理作业或存储过程对复制或派生列进行修改,这只能在对实时性要求不高的情况下使用。 本系统应该采用触发器数据同步方式。 【问题3】(7分) 该系统采用了Redis来实现某些特定功能(如当前热销药品排名等),同时将药品关系数据放到内存以提高商品查询的性能,但必然会造成Redis和MySQL的数据实时同步问题。 (1) Redis的数据类型包括String、Hash、List、Set和ZSet等,请说明实现当前热销药品排名的功能应该选择使用哪种数据类型。 答： 热销药品排名适合用:ZSet,即有序集合类型。因为排行榜既要去重,也要排序,用这种结构最为合适。 (2)请用200字以内的文字解释说明解决Redis和MySQL数据实时同步问题的常见方案。 答： 1、实时同步方案,先查缓存,查不到再从DB查询,并保存到缓存;更新缓存时先更新数据库,再将缓存设置过期。 2、异步队列方式同步,可采用消息中间件处理。 3、通过数据库插件完成数据同步。 4、利用触发器进行缓存同步。
      • 2022 缓存与数据库一致性
        • 设计团队在讨论缓存和数据库的数据一致性问题时,李工建议义采取数据实时同步更新方案,而张工则建议采用数据异步准实时更新方案。 请用200字以内的文字,简要介绍两种方案的基本思路,说明全全国仓储货物管理系统应该来用哪种方案,并说明采取该方案的的原因。 答： 李工同步方案思路: 当数据库数据更新时,同时更新内存的缓存数据。 张工异步准实时方案思路: 当数据库数据更新时,不立即更新缓存数据,而是将需要更新的操作记录成日志,再逐步排队完成更新。 项目数据量极大,且性能要求高,较适合采用张工提出的异步准实时方案较好。
      • 23年Lambda 架构和 Kappa 架构
        •  大数据的架构包括了Lambda架构和Kappa架构,Lambda架构分解 为三层:即批处理层、加速层、服务层。
        • 大数据架构图
          • 
    • Redis
      • Redis数据库缓存基本数据类型及常见应用
        • (1)STRING类型:常规的key/value缓存应用,常规计数如粉丝数等; (2)LIST类型:各类列表应用,如关注列表、好友列表、订阅列表等; (3)SET类型:与LIST类似,但提供去重操作,也提供集合操作,可实现共同关注、共同喜好、共同好友等功能; (4)HASH类型:存储部分变更数据,如用户数据等; (5)ZSET类型:类似SET但提供自动排序,也可实现带权重的队列,如各类排行榜等。 
      • 持久化存储
        • Redis提供了两种持久化存储的机制,分别是RDB(RedisDataBase)持久化方式和AOF(Append OnlyFile)持久化方式。RDB持久化方式是指在指定的时间间隔内将内存中的数据集快照写入磁盘,是Redis默认的持久化方式。AOF方式是指redis会将每一个收到的写命令都通过write函数追加到日志文件中。 两种方式各有优缺点,大致的比较如下: (1)磁盘更新频率:AOF比RDB文件更新频率高。 (2)数据安全:AOF比RDB更安全。 (3)数据一致性:RDB间隔一段时间存储,可能发生数据丢失和不一致;A0F通过append模式写文件,即使发生服务器宕机,也可通过redis-check-aof工具解决数据一致性问题。 (4)重启性能:RDB性能比AOF好。 (5)数据文件大小:AOF文件比RDB文件大。
      • 内存淘汰机制
        • 内存淘汰机制: (1)从已设置过期时间的数据集最近最少使用的数据淘汰。 (2)从已设置过期时·间的数据集将要过期的数据淘汰。 (3)从已设置过期时间的数据集任意选择数据淘汰。 (4)从数据集最近最少使用的数据淘汰。 (5)从数据集任意选择数据淘汰。
  • 架构设计
    • 案例试题一必做题，必然是架构设计题
    • 架构风格对比对比
      • 所有架构风格汇总如下,要能够看表理清楚每个架构风格的含义,有生疏 的再去看上午精华知识点部分详细介绍。 五大风格：数据流、调用返回、独立构件、虚拟机、仓库：  常考的架构风格对比：  `
      • 管道过滤器对比数据仓库
        • 通过交互方式、数据结构、控制结构和扩展方法分别对仓库风格和管道过滤器风格进行对比,如下所示: 交互方式:管道-过滤器很明显是顺序结构或循环结构,数据在管道中进行传递。而仓库结构是数据在中心位置,所有的处理均是中心节点与周边节点之间的交互,从形态来看,是星型的。 数据结构:从数据结构来看,仓库风格会使用一个文件将数据保存起来,所有的操作围绕这个文件进行。而管道过滤器则是在过滤器之间传递数据流。 控制结构:从控制结构来说仓库风格是业务功能驱动,而管道-过滤器是由数据流驱动的。 扩展方法:从扩展方法来讲,管道-过滤器是通过过滤器提供标准接口与其它过滤器对接,而数据仓库风格,要共享数据,扩展功能,只要功能的操作与数据模型本身是匹配的就行了,就像我们要共享一个数据库做系统集成,此时共享同一数据库的多个应用系统所用的数据模型一定会是一致的,否则无法去共享。  1. 星型结构 2.数据流 3.数据驱动 4.模型适配  表(1)-(4)空的空白处分别为: (1)数据存储在中心仓库,处理流程独立,支持交互式处理 (2)数据与处理紧密关联,调整处理流程需要系统重新启动 (3)数据与处理分离,需要加载数据,性能降低 (4)数据处理组件之间一般无依赖关系,可并发调用,提高性能
      • 面向对象对比基于规则
        •  (1)将用户级别、折扣规则等描述为可动态改变的规则数据; (2)加入新的用户级别和折扣规则时需要重新定义新的对象,并需要重启系统; (3)用户级别和折扣规则已经在系统内编码,可直接运行性能较好。
      • 解释器、管道过滤器、隐式调用
        • 针对该系统的功能,赵工建议采用解释器(interpreter)架构风格,李工建议采用管道过滤器(pipe-and-filter)的架构风格,王工则建议采用隐式调用(implicit invocation)架构风格。请针对平台的核心应用场景,从机器学习流程定义的灵活性和学习算法的可扩展性两个方面对三种架构风格进行对比与分析,并指出该平台更适合采用哪种架构风格。 答： 本题系统中有多个应用场景提到了系统分角色有不同的操作流程与界面,以及在修改扩充系统时,需要能够在限定时间内快速完成任务。基于这样的情况,我们从两方面进行分析: 解释器:机器学习流程定义的灵活性高,学习算法的可扩展性强。因为解释器风格可以以通过自定义流程规则及配套流程解释引擎开发,做到用户层面的流程完全定义,而不需要修改代码,所以无论是修改已有的业务流程,还是要扩展不同的角色,创建新角色的流程都非常便利。解释器按照输入输出格式将学习算法封装为组件,通过解释器机制动态增加或删除算法组件,并支持动态调用,学习算法的可扩展性强。 管道过滤器:机器学习流程定义的灵活性低,学习算法的可扩展性弱。因为管道过滤器是把数据处理职能做成过滤器,把数据传递做成管道,此时如果流程不发生变化,是可以通过这种方式实现的,但一且流程变化或是扩展功能,需要对过滤器进行修改调整,或是流程在程序层面重建,此时必须修改代码完成任务。管道过滤器按照输入输出格式将学习算法封装为组件,如果需要增加或删除组件,需要停止平台并进行重新部署,学习算法的可扩展性弱。 隐式调用:机器学习流程定义的灵活性一般,学习算法的可扩展性一般。隐式调用强调的是通过间接方式进行调用,如采用事件机制,要完成某个动作时先触发事件,事件与相关动作关联,以提升灵活度,本题中可把角色执行业务的流程用事件触发。这种做法比管道过滤器强,但弱于完全自定义的解释器。隐式调用按照输入输出国式将学习算法封装为处理函数,支持动态增加和删除函数,学习算法的可扩展性一般。 经过综合比较与分析,可以看出该系统更适合使用解释器风格。
      • 面向对象对比解释器
        • 应该选择解释器架构风格。 折扣规则的可修改性:解释器风格比面向对象方式实现强。因为解解释器风格折扣规则是 独立的语法规则,由解释器可对变化的规则进行解析,修改更容易。而面向对象相对固定, 有变化需要修改具体的类。 个性化折扣定义灵活性:解释器强于面向对象,解释器可以根据用户灵活解释执行规则, 做到千人千面。 系统性能:面向对象优于解释器。面向对象的实现相对固定,而解释器是运行期动态绑 定执行。
    • 质量属性
      • 1.对于质量属性需要做到： 记住其定义 如何去优化 （增加计算机资源等） 典型代表参数（比如性能的时间）
      • 性能
        • 指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处 理的事件的个数。如响应时间、吞吐量。设计策略:优先级队列、增加计算资源、减少计算开销、 引入并发机制、采用资源调度等。
      • 可用性
        • 是系统能够正常运行的时间比例,经常用两次故障之间的时间长度度或在出现故障时系统能够恢复 正常的速度来表示。如故障间隔时间。设计策略:心跳、Ping/tEcho、冗余、选举。
      • 可靠性
        • 是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本 能力。如MTTF、MTBF。设计策略:心跳、Ping/Echo、冗余、选举。 可靠性定义与可用性非常类似，同时出现的话优先选择可用性
      • 安全性
        • 是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保 密性、完整性、不可抵赖性、可控性。设计策略:入侵检测、用户认证、用户授权、追踪审计。
      • 可修改性
        • 指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准,通过 考察这些变更的代价衡量。设计策略:接口-实现分类、抽象、信息隐藏。
      • 功能性
        • 是系统所能完成所期望的工作的能力。一项任务的完成需要系统中中许多或大多数构件的相互协作。
      • 可变性
        • 指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则, 在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时,可 变性是很重要的。
      • 互操作性
        • 作为系统组成部分的软件不是独立存在的,经常与其他系统或自身环境境相互作用。为了支持互操 作性,软件体系结构必须为外部可视的功能特性和数据结构提供精心心设计的软件入口。程序和用 其他编程语言编写的软件系统的交互作用就是互操作性的问题,也影响应用的软件体系结构。
    • 必背概念
      • 这部分考试时可能会要求默写
      • 软件架构风格
        • 是指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式,惯用模式则反映众多系统共有的结构和语义。
      • 架构风险
        • 是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
      • 风险点与非风险点
        • 不是以标准专业术语形式出现的,只是一个常规概念,即可能引起风险的因素,可称为风险点。 某个做法如果有隐患,有可能导致一些问题,则为风险点;而如果某件事是可行的可接受的,则为非风险点。
      • 敏感点
        • 是指为了实现某种特定的质量属性,一个或多个构件所具有的特性。
      • 权衡点
        • 是影响多个质量属性的特性,是多个质量属性的敏感点
    • 常考的架构
      • MVC架构
        • MVC强制性地把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离, 形成了三个核心模块:控制器、模型、视图。 (1)控制器(Controller) 是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据,控制用户输入,并 向模型发送数据。 (2)模型(Model) 是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据 模型表示业务数据和业务逻辑。 (3)视图(View) 是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是用户看到并与之 交互的界面。视图向用户显示相关的数据,并能接收用户的输入数据,但是它并不进行任 何实际的业务处理 MVC分层有助于管理复杂的应用程序,因为您可以在一个时间内专门关注一个方面。例如, 您可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。 MVC分层同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。 
      • J2EE四层结构
        • J2EE核心组成: 容器:Applet Container、Application Container、Web Contaiiner、EJB Container 组件:Applet、Application、JSP/Servlet、EJB。  客户层组件:J2EE应用程序可以是基于web方式的,也可以是基于传统方式的静态的 HTML(标准通用标记语言下的一个应用)页面和Applets是客户层组件 web层组件:J2EE web层组件可以是JSP页面或Servlet。 业务层组件:业务层代码的逻辑用来满足特定领域的业务逻辑处理，JAVA Bean。 信息系统层:企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资 源计划(ERP),大型机事务处理,数据库系统,和其它的遗留言息系统.例如,J2EE应用 组件可能为了数据库连接需要访问企业信息系统。 JSP+Servlet+JavaBean+DAO JSP:用于显示、收集数据的部分。作为MVC中的视图V。 Servlet:作为业务逻辑层,用于处理复杂的业务逻辑,如验证数据、实例化JavaBean、 调用DAO连接数据库等。作为MVC中的控制器C。在其中会调用Service方法处理服务。 JavaBean:用于数据的封装,方便将查询结果在servlet与jsp页面之间进行传递等。 DAO:用于连接数据库及进行数据库的操作如:查询、删除、更改等。 DAO与JavaBean合在一起为MVC中的模型M。 基本流程:JSP发一个数据到servlet,servlet收到后做下解析再根据数救据调用相应的 service去服务,service如果有要调用数据库就通过DAO跟数据居库交互,使用javaBean完成封 装,返回结果给servlet,servlet再返回给JSP。
        • 题1
          • 11年考题，不是重点，J2EE这个知识点应该不会再考了 阅读以下关于软件系统设计的叙述,在答题纸上回答问题1至问题3 【说明】某软件企业受该省教育部门委托建设高校数字化教育教学资源共享平台,实现以众筹众 创的方式组织省内普通高校联合开展教育教学资源内容建设,实实现全省优质教学资源整合和共享。 该资源共享平台的主要功能模块包括: (1)统一身份认证模块:提供统一的认证入口,为平台其他核心业务模块提供用户管理、身份认证、 权限分级和单点登录等功能; (2)共享资源管理模块:提供教学资源申报流程服务,包括了资源申报、分类定制、资料上传、资 源审核和资源发布等功能; (3)共享资源展示模块:提供教育教学共享资源的展示服务,包括资源与导航、视频点播、资源检索、 分类展示、资源评价和推荐等功能; (4)资源元模型管理模块:依据资源类型提供共享资源的描述属性、内容属性和展示属性,包括共 享资源统一标准和规范、资源加工和在线编辑工具、数字水印和模板定制等功能 (5)系统综合管理模块:提供系统管理和维护服务,包括系统配置、数据备份恢复、资源导入导出 和统计分析等功能。 【问题1】(9分) MVC架构中包含哪三种元素,它们的作用分别是什么?请根据图2-1所示架构将JavaEE中JSP、 Servlet、Service、JavaBean、DAO五种构件分别填入空(1)~(5)所示位置。  答： MVC架构包含:视图、控制器、模型 视图(View):视图是用户看到并与之交互的界面。视图向用户显示相关的数据,并能接收用户 的输入数据,但是它并不进行任何实际的业务处理。 控制器(Controller):控制器接受用户的输入并调用模型和视图去完成用户的需求。该部分是用 户界面与Model的接口。一方面它解释来自于视图的输入,将其解释成为系统能够理解的对象, 同时它也识别用户动作,并将其解释为对模型特定方法的调用;另一方面,它处理来自于模型的 事件和模型逻辑执行的结果,调用适当的视图为用户提供反馈。 模型(Model):模型是应用程序的主体部分。模型表示业务务数据和业务逻辑。一个模型能为多 个视图提供数据。 (1) JSP (2) Servlet (3)Service (4)JavaBean (5)DAO 【问题2】(6分) 项目组架构师主工提出在图2-1所示架构设计中加入EJB构件,采用企业级JavaEE架构开发资源共 享平台。请说明EJB构件中的Bean(构件)分为哪三种类型,每种类型Bean的职责是什么。 答： EJB中的Bean分三种类型:Session Bean、Entity Beans和Message-Driven Bean Session Bean的职责是:维护一个短暂的会话 Entity Beans的职责是:维护一行持久稳固的数据 Message-Driven Bean的职责是:异步接受消息 【问题3】(10分) 如果采用王工提出的企业级JavaEE架构,请说明下列(a)-(e)所给出的的业务功能构件中,有状态和 无状态构件分别包括哪些。 (a)Identification Bean(身份认证构件) (b) ResPublish Bean(资源发布构件) (c) ResRetrieval Bean(资源检索构件) (d) OnlineEdit Bean(在线编辑构件) (e)Statistics Bean(统计分析构件) 答 有状态: a b d 无状态: (c) (e)
      • 面向服务的架构SOA
        • 面向服务的架构SOA:SOA是一种设计理念,其中包含多个服务,服务之间通过相互依 赖最终提供一系列完整的功能。各个服务通常以独立的形式部不署运行,服务之间通过网络 进行调用。 
        • 企业服务总线ESB
          • 企业服务总线ESB:简单来说是一根管道,用来连接各个服务节点。ESB的存在是为了集 成基于不同协议的不同服务,ESB做了消息的转化、解释以及路由的工作,以此来让不同 的服务互联互通。  ESB特点： 1、SOA的一种实现方式,ESB在面向服务的架构中起到的是总线作用,将各种服务进行连接与 整合; 2、描述服务的元数据和服务注册管理; 3、在服务请求者和提供者之间传递数据,以及对这些数据进行转换的能力,并支持由实践中 总结出来的一些模式如同步模式、异步模式等; 4、发现、路由、匹配和选择的能力,以支持服务之间的动态交互,解耦服务请求者和服务提 供者。高级一些的能力,包括对安全的支持、服务质量保证、可管理性和负载平衡等。 ESB的主要功能: (1)服务位置透明性; (2)传输协议转换; (3)消息格式转换; (4)消息路由; (5)消息增强; (6)安全性; (7)监控与管理。
    • 八大架构
      • 案例第一题可能在这出 第一问是给个架构图填空 剩下两问解答和应用
      • 信息系统架构
        • 信息系统架构基本概念 信息系统架构 信息系统架构设计方法 信息系统架构案例分析 考试可能把图中圈的四个挖掉填空： 
        • 基本概念
          • 信息系统架构（ISA）是指对某一特定内容里的信息进行统筹、规划、设计、安排等一系列有机处 理的活动。为了更好地理解信息系统架构的定义,特作如下说明: (1)架构是对系统的抽象,它通过描述元素、元素的外部可见属性及元素之间的关系来反映这种抽 象。因此,仅与内部具体实现有关的细节是不属于架构的,即定义强调元素的"外部可见"属性。 (2)架构由多个结构组成,结构是从功能角度来描述元素之间的关系的,具体的结构传达了架构某 方面的信息,但是个别结构一般不能代表大型信息系统架构。 (3)任何软件都存在架构,但不一定有对该架构的具体表述文档。即架构可以独立于架构的描述而 存在。如文档己过时,则该文档不能反映架构。 (4)元素及其行为的集合构成架构的内容。体现系统由哪些元素经且成,这些元素各有哪些功能(外 部可见),以及这些元素间如何连接与互动。即在两个方面进行油象:在静态方面,关注系统的大 粒度(宏观)总体结构(如分层);在动态方面,关注系统内关健行为的共同特征 (5)架构具有"基础"性:它通常涉及解决各类关键重复问题的通用方案(复用性),以及系统设 计中影响深远(架构敏感)的各项重要决策(一旦贯彻,更改的代价昂贵) (6)架构隐含有"决策",即架构是由架构设计师根据关键的功能和非功能性需求(质量属性及项 目相关的约束)进行设计与决策的结果。 信息系统架构可分为物理结构与逻辑结构两种,物理结构是指不考虑系统各部分的实际工作与功能 结构,只抽象地考察其硬件系统的空间分布情况。逻辑结构是指信息系统各种功能子系统的综合体。 物理结构一般分为集中式与分布式两大类。 在信息系统开发中,强调对各种子系统进行统一规划,并对各子系统进行综合。 1)横向综合:将同一管理层次的各种职能综合在一起,例如,将运行控制层的人事和工资子系统综 合在一起,使基层业务处理一体化。 2)纵向综合:把某种职能的各个管理层次的业务组织在一起,这种综合沟通了上下级之间的联系, 如工厂的会计系统和公司的会计系统综合在一起,它们都有共同之处,能形成一体化的处理过程。 3)纵横综合:主要是从信息模型和处理模型两个方面来进行综合,做到信息集中共享,程序尽量模 块化,注意提取通用部分,建立系统公用数据库和统一的信息处理系统 信息系统常用四种架构模型 1.单机应用模式:是最简单的软件结构,是指运行在一台物理机器上的独立应用程序。单机系统本身 也可以很复杂。 2.客户机/服务器模式:即两层、三层C/S、B/S模式、MVC模式等。 3.面向服务架构(SOA)模式。 4.企业数据交换总线:不同的企业应用之间进行信息交换的公共通道
        • 企业信息系统总体框架
          • 要在企业中建立一个有效集成的ISA,必须考虑企业中的四个方面:战略系统、业务系统、应用系统 和信息基础设施。 1.战略系统是指企业中与战略制定、高层决策有关的管理活动和计算机辅助系统 在ISA中战略系统由两个部分组成,其一是为以计算机为基础的高层决策支持系统,其二是企业 的战略规划体系。 在ISA中设立战略系统有两重含义:一是它表示信息系统对企业高层管理者的决策支持能力; 其二是它表示企业战略规划对信息系统建设的影响和要求。 2.业务系统是指企业中完成一定业务功能的各部分(物质、能量、信息和人)组成的系统。 作用:对企业现有业务系统、业务过程和业务活动进行建模,并并在企业战略的指导下,采用业务流 程重组(BPR)的原理和方法进行业务过程优化重组。  3.应用系统即应用软件系统,指信息系统中的应用软件部分。如TPS、MIS、DSS等。 包含两个基本组成部分:内部功能实现部分和外部界面部分。 4.企业信息基础设施(EII)是指根据企业当前业务和可预见的发展趋势,及对信息采集、处理、存 储和流通的要求,构筑由信息设备、通信网络、数据库、系统饮件和支持性软件等组成的环境。这 里可以将企业信息基础设施分成三部分:技术基础设施、信息资源设施和管理基础设施 ·技术基础设施由计算机、网络、系统软件、支持性软件、数据交换协议等组成; ·信息资源设施由数据与信息本身、数据交换的形式与标准住、信息处理方法等组成: ·管理基础设施指企业中信息系统部门的组织结构、信息资源设施管理人员的分工、企业信息基础设施的管理方法与规章制度等。
        • 架构设计方法
          • 了解即可，考的可能不大 TOGAF是一种开放式企业架构框架标准,它为标准、方法论和企业架构专业人人员之间的沟通提供一致性保障 该框架旨在通过以下四个目标帮助企业组织和解决所有关键业务务需求:确保从关键利益相关方到团队成员的所有用户都使用相同的语言、避免被"锁定"到企业架构的专有解决方案、节省时间和金钱更有效地利用资源、实现可观的投资回报。 TOGAF框架核心思想:模块化架构、内容框架、扩展指南、架林构风格 TOGAF的关键是架构开发方法(ADM),为开发企业架构所需要执行各个步骤以及它们之间的关系 进行详细的定义。 ADM方法是由一组按照架构领域的架构开发顺序而排列成一一个环的多个阶段所构成。 ADM三个级别的迭代:基于ADM整体的选代、多个开发阶段间的迭代、在一个阶段内部的迭代。 将ADM全生命周期十个阶段主要活动:  
        • 信息化总体架构方法
          • 考到的可能性也不大 实现信息化就要构筑和完善6个要素(开发利用信息资源,建设国家信息网络,推进信息技术应用, (发展信息技术和产业,培育信息化大才,制定和完善信息化政策)的国家信息化体系。 完整的信息化内涵包括四方面内容:信息网络体系、信息产亚基础、社会运行环境、效用积累过程。 信息化建设指品牌利用现代信息技术来支撑品牌管理的手段我和过程。信息化建设包括了企业规模,企业在电话通信、网站、电子商务方面的投入情况,在客户资源管理、质量管理体系方面的建设成就等。 信息化主要体现以下6种特征:易用性;健壮性;平台化、灵活活性、扩展性;安全性;门户化、整合 性;移动性。 下面需要掌握： 信息化架构一般有两种模式,一种是数据导向架构,一种是流程导向架构。对于数据导向架构重点是 在数据中心,BI商业智能等建设中使用较多,关注数据模型和数据质量;对于流程导向架构,SOA本 身就是关键方法和技术,关注端到端流程整合,以及架构对流程变化的适应度。两种架构并没有严格的边界,而是相互配合和补充。 数据导向架构研究的是数据对象和数据对象之间的关系,这个是首要的内容。在这个完成后仍然要开 始考虑数据的产生、变更、废弃等数据生命周期,这些自然涉及的的数据管理的相关流程 流程导向架构关注的是流程,架构本身的目的是为了端到端流程整合服务。因此研究切入点会是价值 链分析,流程分析和分解,业务组件划分。
        • 信息系统的生命周期
          • 信息系统的生命周期可以分为下面五个阶段: 1.系统规划阶段:任务是对组织的环境、目标及现行系统的状况进行初步调查,根据组织目标和发展战略确定信息系统的发展战略,对建设新系统的需求做出分析和预测,同时考虑建设新系统所受的各种约束,研究建设新系统的必要性和可能性。根据需要与可能,给出制建系统的备选方案。 输出:可行性研究报告、系统设计任务书。 2.系统分析阶段:任务是根据系统设计任务书所确定的范围,对现行系统进行详细调查,描述现行系统的业务流程,指出现行系统的局限性和不足之处,确定新系统的基本目标和逻辑功能要求,即提出新系统的逻辑模型。系统分析阶段又称为逻辑设计阶段。这个阶段是整个系统建设的关键阶段,也是信息系统建设与一般工程项目的重要区别所在。 输出:系统说明书。 3.系统设计阶段:系统分析阶段的任务是回答系统"做什么"的问题,而系统设计阶段要回答的问题是"怎么做"。 该阶段的任务是根据系统说明书中规定的功能要求,具体设计实现逻辑模型的技术方案,也就是设计新系统的物理模型。这个阶段又称为物理设计阶段,可分为总体设计(概要设计)和详细设计两个子阶段。 输出:系统设计说明书(概要设计、详细设计说明书)。 4.系统实施阶段:是将设计的系统付诸实施的阶段。这一阶段的任务包括计算机等设备的购置、安装和调试、程序的编写和调试、人员培训、数据文件转换、系统调试与转换等。这个阶段的特点是几个互相联系、互相制约的任务同时展开,必须精心安排、合理组织。系统实施是按实施计划分阶段完成的,每个阶段应写出实施进展报告。系统测试之后写出系统测试分析报告。 输出:实施进展报告、系统测试分析报告。 5.系统运行和维护阶段:系统投入运行后,需要经常进行维护和评价,记录系统运行的情况,根据一定的规则对系统进行必要的修改,评价系统的工作质量和经济效益。
        • 信息系统架构案例分析
          • Web服务在HL7上的应用
            • 对于一个给定的卫生保健领域,HL73.0 版本说明书是基于参考信息模型的(RIM)。 这是一种公共的模型框架,包括病例模 型、信息模型、交互模型、消息模型和 实现信息说明书。 HL7应用参考体系结构:  能够抽象出HL7发送者/接收者内部的这两组功能:商业逻辑和Web服务适配器 商业逻辑的任务如下。 (1)发送端:创建一种具体HL7消息类型的XML描述。将消息传送到Web服务适配器,适配器负责传送 到接收应用端。 (2)接收端:"找回"由Web服务适配器接收的HL7消息,同时从接收到的XML消息那里打开消息;验 证HL7消息是否满足用来交互的商业规则和约束;核实发送应用端是否需要一个应用层的确认信息 (HL7消息类型MC1)--如果是那样的话,发送那个消息。 Web服务适配器的功能主要是用来处理消息的分发和确认信息。因此,主要包括如下内容。 1)发送端 (1)读取接收到的HL7消息的Transmission Wrapper,以便决定如如何到达Web服务基层结构上的发送容器(例如接收应用软件),从而配置SOAP。 (2)基于HL7消息类型、应用配置和规则(如安全性)来准备一个SOAP消息,包括作为一个SOAP消息 体部分的HL7XML消息,这个消息被发送到Web服务基层组织。 (3)把SOAP消息传递到Web服务代理,通过网络进行传输。 (4)无论发送端什么时候请求,都准备接收并存储来自接收端的相应信息或是应用层的确认消息。 2)接收端 (1)从Web服务站处接收SOAP消息。 (2)验证接收到的SOAP消息满足应用配置和一些约束条件(如安全性)。 (3)或者将这些接收到的消息在内存中以永久的形式保留。 (4)有选择性地从SOAP消息里打开HL7XML消息,同时核对接收到到的HL7消息是否与期望的HL7消息 类型相符合。 (5)验证是否任意通信层的确认信息都需要被执行,在哪种情况下需要返回一个合适的消息发送到源 消息发送端。 (6)传递HL7消息给接收应用端。
          • 以服务为中心的企业整合
            • 某航空公司已经在几个主要的核心系统之间构建了用于信息集成的信Hub,其他应用间也有不少点到点的集成。然而还存在如下困难: (1)因为大部分核心应用构建在主机之上,所以InformationHub是基于主机技术开发,很难被开放系统使用。 (2)InformationHub对Event支持不强,被集成的系统间的的事件以点到点流转为主,被集成系统间耦合性强。 (3)牵扯到多个系统间的业务协作以硬编码为主,将业务活动自动化的成本高,周期长,被开发的业务活动模块重用性差。 为了解决这些企业集成中的问题,该公司决定以Ramp Control系统为例探索一条以服务为中心的企业集成道路。 在航空业中,Ramp Coordination是指飞机从降落到起飞过程中所需要进行的各种业务活动的协调过程。需要协调的业务活动有:检查机位环境是否安全,以及卸货、装货和补充燃料是否方便和安全等。 三种类型航班:short turnaround航班是降落后不久就起飞的航班、Arrival Only航班指降落后需要隔夜才起飞的,Departure Only航班是指每天一早第一班飞机。 每种细分的航班类型的Ramp Coordination 的流程都是略有有不同。如此多的流程之间共享着一个业务活动的集合,如此多种类型的流程都是这些业务活动的不同组接方式。以服务为中心的企业集成中流程服务就是通过将这些流程间共享的业务活动抽象为可重用的服务,并通过流程服务提供的流程编排的能力将它们组成各种大同小异的流程类型,来降低流程集成成本,加快流程集成开发效率的。以服务为中心的企业集成,通过服务建模过程发现这些可重用的服务,并通过流程模型将这些服务组装在一起。 Ramp Coordination相关的服务模型和Ramp Coordination流程相关的有两个业务组件: 1 Ramp Control负责Ramp Control相关各种业务活动的组件; 2 Flight Management负责航班相关信息的管理,包括航班日程,乘客信息等。 这两个业务组件分别输出如下服务。 (1)Retrieve Flight BO（检索航班）:由Flight Management输出,主要用于提取和航班相关的数据信息。 (2)Ramp Coordination（飞机起飞降落协调）:由Ramp Control输出,主要用于Ramp Coordination 流程的编排。 (3)Check Spot（检查机位环境安全）:由Ramp Control输出,用于检测机位安全信息。 (4)Check Unloading:由Ramp Control输出,用于检查卸货状况。 (5)Check Loading:由Ramp Control输出,用于检查装货状况。 (6)Check PusBack:中Ramp Control输出,用于检查关门动作 目前,Ramp Coordination流程需要4种类型的外围应用交互。 (1)从乘务人员管理系统提取航班乘务员的信息。 (2)从订票系统中提取乘客信息。 (3)从机务人员管理系统中提取机务人员信息。 (4)接收来自航班调度系统的航班到达事件。  这个是面向服务的架构，里面主要有四个服务，已经用红框标出。 Imtemation Service 用于提取和航班相关的数据信息 1.Federetion Service（联合服务） 航班信息服务 2.Event Detect事件检测服务检测到事件会触发事件服务Event Service 3.Process Service 流程服务， 用于流程的编排。 4.Ramp Coordination Function 与RCMS对应关系硬记一下。 整个中间一层是ESB
      • 层次式架构
        • 表现层框架设计 中间层架构设计 数据访问层设计 数据架构规划设计 物联网层次架构设计 层次式架构案例分析 有可能把四层组成一个大图来考察
        • 基本概念
          • 软件层次式体系结构是最通用的架构,也被叫作N层架构模式。大部分的应用会分成表现层(或称)为展示层)、中间层(或称为业务层)、数据访问层(或称为持久层)和数据层 
        • 表现层框架设计
          • 使用XML设计表现层。 UIP提供了一个扩展的框架,用于简化用户界面与商业逻辑代码的分离的方法,可以用它来写复 杂的用户界面导航和工作流处理,并且它能够复用在不同的场景、并可以随着应用的增加而进行扩展 使用UIP框架的应用程序把表现层分为了以下几层。 User Interface Components:这个组件就是原来的表现层,用户看到的和进行交互都是这个组件, 它负责获取用户的数据并且返回结果。 User Interface Process Components:这个组件用于协调用户界面的各部分,使其配合后台的活 动,例如导航和工作流控制,以及状态和视图的管理。用户看不到这一组件,但是这些组件为User Interface Components提供了重要的支持功能。 表现层动态生成设计:基于XML的界面管理技术可实现灵活的界面配置(静态)、界面动态生成和界面定制(动态)。其思路是用XML生成配置文件及界面所需的元数据,按不同需求生成界面元素及软件界面。 如下这个图考过填空： 界面定制模块 为静态定制，作用于可执行文件 界面动态生成模块 运行过程中动态生成 
        • 中间层架构设计
          • 组件设计:业务逻辑组件分为接口和实现类两个部分。接口用于定义业务逻辑组件,定义业务逻 辑组件必须实现的方法是整个系统运行的核心。增加业务逻辑组件的接口,是为了提供更好的解耦, 控制器无须与具体的业务逻辑组件耦合,而是面向接口编程。 工作流设计:工作流定义为:业务流程的全部或部分自动化,在此过程中,文档、信息或任务按 照一定的过程规则流转,实现组织成员间的协调工作以达到业务的整体目标。工作流参考模型见图: 其包含6个基本模块,分别是工作流执行服务、工作流引擎、流程定义工具、客户端应用、调用应 用和管理监控工具。  (1)interface 1:过程定义导入/导出接口。这个接口的特点是:转换格式和API调用,从而支持 过程定义信息间的互相转换。 (2)interface2:客户端应用程序接口。通过这个接口工作流村几可以与任务表处理器交互,代表用 户资源来组织任务。然后由任务表处理器负责,从任务表中选择、推进任务项。由任务表处理器或 者终端用户来控制应用工具的活动。 (3)interface3:应用程序调用接口。允许工作流机直接激敢活一个应用工具,来执行一个活动。典 型的是调用以后台服务为主的应用程序,没有用户接口。当执行行活动要用到的工具,需要与终端用 户交互,通常是使用客户端应用程序接口来调用那个工具,这样样可以为用户安排任务时间表提供更 多的灵活性。 (4)interface4:工作流协作接口。其目标是定义相关标准,以使不同开发商的工作流系统产品 相互间能够进行无缝的任务项传递。 (5)interface5:管理和监视接口。提供的功能包括用户管理、、角色管理、审查管理、资源控制、 过程管理和过程状态处理器等。
          • 实体设计
            • 实体设计:业务逻辑层实体提供对业务数据及相手关功能(在某些设计中)的状态编程访问。业务逻 辑层实体可以使用具有复杂架构的数据来构建,这种数据通通常来自数据库中的多个相关表。 在应用程序中表示业务逻辑层实体的方法有很多(从以数据为中心的模型到更加面向对象的表示 法),如XML 通用DataSet、有类型的DataSet等。 如下左图是业务实体用XML表示,右图所示为用于0rder业务逻辑层实体的通用DataSet对象。此 DataSet对象具有两个Data Table对象,分别保存订单信息和订单详细信息。每个DataTable具有 一个对应的UniqueConstraint对象,用于标识表中的主键。此外,该DataSet还有一个Relation 对象,用于将订单详细信息与订单相关联。 
          • 业务框架
            • 业务框架位于系统架构的中间层,是实现系统功能的核心组件。采用容器的形式,便于系统功能的 开发、代码重用和管理。下图便是在吸收了SOA思想之后的一个三层体系结构的简图。 业务层采用业务容器的方式存在于整个系统当中,采用此方式可以大大降低业务层和相邻各层的耦合,表示层代码只需要将业务参数传递给业务容器,而不需要业务层多余的干预。如此一来,可以有效地防止业务层代码渗透到表示层。 在业务容器中,业务逻辑是按照Domain Model-Service-Control思想来实现的。 (1)DomainModel是领域层业务对象,它仅仅包含业务相关的属性。 (2)Service是业务过程实现的组成部分,是应用程序的不同功能单元,通过在这些服务之间定义良好的接口和契约联系起来。 (3)Control服务控制器,是服务之间的纽带,不同服务之间的切换就是通过它来实现的。 
            • DAO
              • DAO就是DatabaseAccess Objects，数据访问对象 它对访问存储在不同数据库管理系统(DBMS)中的数据提供了一个通用的API
        • 数据访问层设计
          • 数据访问层是为了屏蔽底层数据库的细节,在需要对接多种不同的数据库时需要这一层，它帮助我们使用统一的接口访问数据库 5种数据访问模式 1.在线访问：会占用一个数据库连接,读取数据,每个数据库操作都都会通过这个连接不断地与后台 的数据源进行交互。 2.DataAccess Object:是标准J2EE设计模式之一,开发人员常常用这种模式将底层数据访问操作 与高层业务逻辑分离开。 3.Data Transfer Object:是经典EJB设计模式之一。DTO本身是这样一组对象或是数据的容器,它 需要跨不同的进程或是网络的边界来传输数据。这类对象本身足应该不包含具体的业务逻辑,并且通 常这些对象内部只能进行一些诸如内部一致性检查和基本验证之类的方法,而且这些方法最好不要 再调用其他的对象行为。 4.离线数据模式是以数据为中心,数据从数据源获取之后,将按照某种预定义的结构存放在系统中, 成为应用的中心。离线,对数据的各种操作独立于各种与后台数女据源之间的连接或是事务。 5.对象/关系映射(Object/Relation Mapping,O/R Mapping):大多数应用中的数据都是依据关系模 型存储在关系型数据库中;而很多应用程序中的数据在开发或是是运行时则是以对象的形式组织起来 的。那么,对象/关系映射就提供了这样一种工具或是平台,能够帮助将应用程序中的数据转换成关 系型数据库中的记录:或是将关系数据库中的记录转换成应用移呈序中代码便于操作的对象。 工厂模式在数据库访问层的应用 首先定义一个操纵数据库的接口DataAccess,然后根据数据库的不同,由类工厂决定实例化哪个类。 
        • 数据架构规划与设计
          • 数据库设计与XML设计融合~ XML文档分为两类:一类是以数据为中心的文档,这种文档在结构上是规则的,在内容上是同构 的,具有较少的混合内容和嵌套层次,人们只关心文档中的敢据而并不关心数据元素的存放顺序, 这种文档简称为数据文档,它常用来存储和传输Web数据。另一类是以文档为中心的文档,这种文 档的结构不规则,内容比较零散,具有较多的混合内容,并且元素之间的顺序是有关的,这种文档 常用来在网页上发布描述性信息、产品性能介绍和E-mail信息息等。 经提出的XML文档的存储方式有两种:基于文件的存储方式和数据库存储方式。 (1)基于文件的存储方式。基于文件的存储方式是指将XML文档按其原始文本形式存储,主要存储技 术包括操作系统文件库、通用文档管理系统和传统数据库的列。这种存储方式需维护某种类型的附 加索引,以建立文件之间的层次结构。基于文件的存储方式的特点:无法获取XML文档中的结构化数 据;通过附加索引可以定位具有某些关键字的XML文档,一旦关键字不确定,将很难定位;查询时, 只能以原始文档的形式返回,即不能获取文档内部信息;文件管理不存在容量大、管理难的缺点 (2)数据库存储方式。数据库在数据管理方面具有管理方便、存储占用空间小、检索速度快、修改效 率高和安全性好等优点。一种比较自然的想法是采用数据库对XML文档进行存取和操作,这样可以利 用相对成熟的数据库技术处理XML文档内部的数据。数据库存储方式的特点:能够管理结构化和半结 构化数据;具有管理和控制整个文档集合本身的能力;可以对文档内部的数据进行操作;具有数据 库技术的特性,如多用户、并发控制和一致性约束等;管理方方便,易于操作
        • 物联网层次架构设计
          • 物联网可以分为三个层次,底层是用来感知数据的感知层,即利利用传感器、二维码、RFID等设备 随时随地获取物体的信息。第二层是数据传输处理的网络层,即通过各种传感网络与互联网的融合, 将对象当前的信息实时准确地传递出去。第三层则是与行业需求结合的应用层,即通过智能计算、 云计算等将对象进行智能化控制。 1.感知层用于识别物体、采集信息。感知层包括二维码标签和识读器、RFID标签和读写器、摄像头、 GPS、传感器、M2M终端、传感器网关等,主要功能是识别对象、采集信息,与人体结构中皮肤和 五官的作用类似。感知层解决的是人类世界和物理世界的数收据获取问题。 2. 网络层用于传递信息和处理信息。网络层包括通信网与互联网的融合网络、网络管理中心、信息 中心和智能处理中心等。网络层将感知层获取的信息进行传递和处理,类似于人体结构中的神经中 枢和大脑。网络层解决的是传输和预处理感知层所获得数据的问题。 3. 应用层实现广泛智能化。应用层是物联网与行业专业技术的深度融合合,结合行业需求实现行业智 能化,这类似于人们的社会分工。 物联网应用层利用经过分析处理的感知数据,为用户提供丰富的特定服务。应用层解决的是信息处 理和人机交互的问题。
        • 层次式架构案例分析
          • 电子商务网站(网上商店PetShop) 下面图太简单，不会考，了解一下，如下13-19考的概率大一些  从图13-16中可以看到,并没有明显的数据访问层设计。这样的设计虽然提高了数据访问的性能, 但也同时导致了业务逻辑层与数据访问的职责混乱。 PetShop3.0纠正了此前层次不明的问题,将数据访问逻辑缉作为单独的一层独立出来。 PetShop 4.0基本上延续了3.0的结构,但在性能上作了一一定的改进,引入了缓存和异步处理机制,同时又充分利用了ASP.Net 2.0的新功能MemberShip。 可以看到,在数据访问层中,完全采用了"面向接口编程"思想。抽象出来的IDAL模块,脱离了与具体数据库的依赖,从而使得整个数据访问层有利于数据库迁移。DALFactory模块专门管理DAL对象的创建,便于业务逻辑层访问。SQLServerDAL和OradcleDAL模块均实现IDAL模块的接口,其中包含的逻辑就是对数据库的Select、Insert、Update和Delete操作。因为数据库类型的不同,对数据库的操作也有所不同,代码也会因此有所区别。  此外,抽象出来的IDAL模块,除了解除了向下的依赖之外,对于其上的业务逻辑层同样仅存在弱依赖关系,如图13-20所示。 图13-20中,BLL是业务逻辑层的核心模块,它包含了整个系系统的核心业务。在业务逻辑层中,不能直接访问数据库,而必须通过数据访问层。注意,图133-20中对数据访问业务的调用,是通过接口模块IDAL来完成的。既然与具体的数据访问逻辑无关,,则层与层之间的关系就是松散耦合的。 如果此时需要修改数据访问层的具体实现,只要不涉及IDAL的接口定义,那么业务逻辑层就不会受到任何影响。毕竟,具体实现的SQLServerDAL和OracalDAL根本就与业务逻辑层没有半点关系。 
      • 云原生架构
        • 云原生架构内涵 云原生架构相关技术 云原生架构案例分析 云原生是热点，考察概率比较大
        • 云原生架构内涵
          • 云原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中的非业务代码部分进行最大化的剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等),使业务不再有非功能性业务中断困扰的同时,具备备轻量、敏捷、高度自动化的特点。 云原生的代码通常包括三部分:业务代码、三方软件、处理非功能特性的代码。从业务代码中剥离大量非功能性特性(不会是所有,比如易用性还不能剥离)到IaaS和PaaS中。 具备云原生架构的应用可以最大程度利用云服务和提升软件交付能力,进一步加快软件开发。其特点包括:代码结构发生巨大变化、非功能性特性大量委托、高度自动化的软件交付
          • IAAS、PAAS、SAAS
            • 
        • 云原生架构原则
          • 云原生架构原则： 服务化原则:拆分为微服务架构、小服务架构,分别迭代。 弹性原则:系统的部署规模可以随着业务量的变化而自动伸绍宿。 可观测原则:通过日志、链路跟踪和度量等手段。 韧性原则:当软件所依赖的软硬件组件出现各种异常时,软件表现现出来的抵御能力。 所有过程自动化原则:一方面标准化企业内部的软件交付过程,另一方面在标准化的基础上进行自动化,通过配置数据自描述和面向终态的交付过程。 零信任原则:默认情况下不应该信任网络内部和外部的任何人/设备/系统,需要基于认证和授权重构访问控制的信任基础,以身份为中心。 架构持续演进原则:云原生架构本身也必须是一个具备持续演进能力的架构。
          • 服务化原则
            • 服务化原则。 当代码规模超出小团队的合作范围时,就有必要进行服务化拆分,包括拆分为微服务架构、小服务(miniservice)架构,通过服务化架构把不同生命周期的模块分离出来,分别进行业务迭代,避免迭代频繁模块被慢速模块拖慢,从而加快整体的进度和稳定性。 同时服务化架构以面向接口编程,服务内部的功能高度内聚,模块间通过公共功能模块的提取增加软件的复用程度。
          • 弹性原则
            • (2)弹性原则。 大部分系统部署上线需要根据业务量的估算,准备一定规模的机器,传统上线过程中需要经历采购申请、供应商治谈、机器部署上电、软件部署、性能压测等阶段,周期很长,重新调整也非常困难。 针对这种情况,弹性原则是指系统的部署规模可以以随着业务量的变化自动伸缩,无须根据事先的容量规划准备固定的硬件和软件资源,从而提高资源利用用率,降低成本。
          • 可观测原则
            • (3)可观测原则。 可观测性原则是指主动通过日志、链路跟踪和度量等手段,每次业务请求背后的 多次服务调用的耗时、返回值和参数都清晰可见,甚至可以下下钻到三方软件调用、SQL请求、节点拓扑、网络响应等。具备可观测能力可以使运维、开发和业务人员实时时掌握软件运行情况,并结合多个维度的数据指标,获得前所未有的关联分析能力,不断对业务健康度和用户体验进行数字化衡量和持续优化。
          • 韧性原则
            • (4)韧性原则。 韧性原则是指当软件所依赖的软硬件组件出现各种种异常时,软件需要表现出抵御能力, 这些异常通常包括硬件故障、硬件资源瓶颈、业务流量超出软件设计能力、故障和灾难、软件bug、黑客攻击等对业务可用性带来致命影响的因素。韧性从多个维度诠释了软件持续提供业务服务的能力,核心目标是提升软件的MTBF(Mean Time BetweenFailure,平均无故障时间)。
          • 自动化原则
            • 自动化原则。 自动化原则是指通过多种技术手段和自动化交付工具,一方面标准化企业内部的 软件交付过程,另一方面在标准化的基础上进行自动化,通过配置数据自描述和面向终态的交付过程,让 自动化工具理解交付目标和环境差异,实现整个软件交付和运维的自动化。
        • 主要架构模式
          • 考试有可能会问，云原生常见的架构模式有哪些种。 1.服务化架构模式:典型模式是微服务和小服务模式。通过服务价化架构,把代码模块关系和部署关系进行分离,每个接口可以部署不同数量的实例,单独扩缩容,从而使得整体的部署更经济。 2.Mesh化架构模式:把中间件框架(如RPC、缓存、异步消息等)从业务进程中分离,让中间件SDK与业 务代码进一步解耦,从而使得中间件升级对业务进程没有影响。分离后后在业务进程中只保留很"薄 的Client部分。 3.Serverless模式（无服务化架构）:将"部署"这个动作从运维中"收走",使开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等,也就是把应用的整个运行都委托给云。 4.存储计算分离模式:在云环境中,推荐把各类暂态数据(如session)、结构化和非结构化持久数据 都采用云服务来保存,从而实现存储计算分离。 5.分布式事务模式:大颗粒度的业务需要访问多个微服务,必然带来分布式事务问题,否则数据就会 出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。 6.可观测架构:可观测架构包括Logging、Tracing、Metrics三个方面,其中Logging提供多个级别 的详细信息跟踪,由应用开发者主动提供;Tracing提供一个请求从前端到后端的完整调用链路跟踪, 对于分布式场景尤其有用;Metrics则提供对系统量化的多维度度量。 7.事件驱动架构:本质上是一种应用/组件间的集成架构模式,可用于服务解耦、增强服务韧性、数 据变化通知等场景中。
        • 云原生架构相关技术
          • 微服务是考试热点 容器技术:容器作为标准化软件单元,它将应用及其所有衣赖项打包,使应用不再受环境限制,不同计算环境间快速、可靠地运行。通过容器技术,企业可以充分发挥云计算弹性优势,降低运维成本。 Kubernetes已经成为容器编排的事实标准,被广泛用于自动部署,扩展和管理容器化应用。 Kubernetes提供了分布式应用管理的核心能力,包括:资源调度、应用部署与管理、自动修复、服务发现与负载均衡、弹性伸缩、声明式API、可扩展性架构、可移植性。 云原生微服务:微服务模式将后端单体应用拆分为松耦合的多个子应用,每个子应用负责一组子功能。这些子应用称为"微服务",多个"微服务"共同形成了一个"物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立,通过解耦研发、测试与部署流和程,提高整体迭代效率。 微服务设计约束:微服务个体约束:功能在业务域划分上应是相互独立的,低耦合、单一职责。 2)微服务与微服务之间的横向关系:主要从微服务的可发现性利可交互性处理服务间的横向关系,一般需要服务注册中心。 3)微服务与数据层之间的纵向约束:在微服务领域,提供数女据存储隔离原则,即数据是微服务的私有资产,对于该数据的访问都必须通过当前微服务提供的API来访问。 4)全局视角下的微服务分布式约束:故障发现时效性和根因精确悄性始终是开发运维人员的核心诉求。 无服务器技术(Serverless)因为屏蔽了服务器的各种运维复杂度,让开发人员可以将更多精力用 于业务逻辑设计与实现,而逐渐成为云原生主流技术之一。Serverless计算包含以下特征: (1)全托管的计算服务,客户只需要编写代码构建应用,无需关注同质化的、负担繁重的基于服务器 等基础设施的开发、运维、安全、高可用等工作; (2)通用性,结合云BaaSAPI的能力,能够支撑云上所有重要类型的应用 (3)自动弹性伸缩,让用户无需为资源使用提前进行容量规划 (4)按量计费,让企业使用成本得有效降低,无需为闲置资源付费。 函数计算(FaaS)是Serverless中最具代表性的产品形态。通过把应用逻辑拆分多个函数,每个 函数都通过事件驱动的方式触发执行。 无服务器技术关注点:计算资源弹性调度、负载均衡和流控、安全性。 服务网格)ServiceMesh)是分布式应用在微服务软件架构之上发展起来的新技术,旨在将那些微 服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施,实现应用与平台基础设 施的解耦。这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身,提升应用 开发效率并加速业务探索和创新。
        • 云原生架构案例分析1
          • 某旅行公司云原生改造 面临两个问题:公司主体由两个公司合并,技术体系不同,需要整合为一体;节假日高并发流量。 改造第一阶段,某旅行技术团队为了提升集群资源利用率,降低资源使用成本。利用云原生思维重构部分技术体系,将多套旧有系统合并、收拢到一套以云原生应用为核心的私有云平台上,同时将IDC、物理网络、虚拟网络、计算资源、存储资源等通过laaS、PaaS等,实现虚拟化封装、切割、再投产的自动化流程。 随着服务器集群规模的扩大,部分机器开始频繁出现故障。此时,保障服务稳定性成了第二阶段改造的首要任务。 第二阶段基于公有云、私有云和离线专属云集群等新型动态计算环境,某旅行公司的技术团队帮助业务构建和运行具有弹性的云原生应用,促进业务团队开始使用声明式API,同时通过不可变基础设施、服务网格和容器服务,来构建容错性好、易于管理和观察的应用系统,并结合平台可靠的自动化恢复、弹性计算来完成整个服务稳定性的提升。 第三阶段通过基础组件、服务的云原生改造、服务依赖梳理和定义等方式,使应用不再需要考虑底层资源、机房、运行时间和供应商等因素。此外,还利用标谁的云原生应用模型,实现了服务的跨地域、跨云自动化灾备、自动部署,并向云原生场景下的Dev0ps演进。架构图如下: 
        • 云原生架构案例分析2
          • 了解： 云原生技术助力某汽车公司数字化转型实践 战略性构建容器云平台。通过平台实现对某云行App、二手车、在线支付、优惠券等核心互联网应用承载。以多租户的形式提供弹性计算、数据持久化、应用发布等面向敏捷业务服务,并实现高水平资源隔离。标准化交付部署,快速实现业务扩展,满足弹性要求。 数字混合云交付。采用私有云+公有云的混合交付模式,按照服务的敏态/稳态特性和管控要求划分部署,灵活调度公有云资源来满足临时突发或短期高TPS业业务支撑的需求。 深度融合微服务治理体系,实现架构的革新和能力的沉淀,逐步形成支撑数字化应用的业务中台。 
        • 云原生架构案例分析3
          • 某电商业务云原生改造 通过容器化部署,利用阿里云容器服务的快速弹性应对大促甲时的资源快速扩容。 提前接入链路追踪产品,用于对分布式环境下复杂的服务调用进行跟踪,对异常服务进行定位, 帮助客户在测试和生产中快速定位问题并修复,降低对业务的的影响。 使用阿里云性能测试服务(PTS)进行压测,利用秒级流量拉起、真实地理位置流量等功能,以最 真实的互联网流量进行压测,确保业务上线后的稳定运营。 采集压测数据,解析系统强弱依赖关系、关键瓶颈点,对关建业务接口、关键第三方调用、数据 库慢调用、系统整体负载等进行限流保护。 配合阿里云服务团队,在大促前进行ECS/RDS/安全等产品扩容、链路梳理、缓存/连接池预热、 监控大屏制作、后端资源保障演练等,帮助大促平稳进行。 
      • 面向服务架构
        • SOA概述和发展 SUA的参考架构 SOA主要协议和规范 SOA设计标准和原则 SOA的设计模式 SOA构建和实施
        • 概述和发展
          • 在面向服务的体系结构(SOA)中,服务的概念有了延伸,泛指系统对外提供的功能集。 从应用的角度定义,可以认为SOA是一种应用框架,它着眼于日常的业务应用,并将它们划分为单 独的业务功能和流程,即所谓的服务。SOA使用户可以构建、部署和整合这些服务,且无需依赖应用 程序及其运行平台,从而提高业务流程的灵活性。 从软件的基本原理定义,可以认为SOA是一个组件模型,它将应用程序的不同功能单元(称为服务) 通过这些服务之间定义良好的接口和契约联系起来。接口是:采用中立的方式进行定义的,它应该独 立于实现服务的硬件平台、操作系统和编程语言。 业务流程是指为了实现某种业务目的行为所进行的流程或或一系列动作。 BPEL:面向Web服务的业务流程执行语言,是一种使用Web服多定义和执行业务流程的语言。使 用BPEL,用户可以通过组合、编排和协调Web服务自上而下地实现现面向服务的体系结构。BPEL目前用 于整合现有的Web Services,将现有的Web Services按照要求的业务流程整理成为一个新的Web Services,在这个基础上,形成一个从外界看来和单个Service一样的Service。
          • 微服务化发展
            • SOA架构向更细粒度、更通用化程度发展,就成了所谓的微服务了。SOA与微服务的区别在于如下 几个方面: (1)微服务相比于SOA更加精细,微服务更多地以独立的进程的方式存在,互相之间并无影响; (2)微服务提供的接口方式更加通用化,例如HTTP RESTful方式,,各种终端都可以调用,无关语言、 平台限制; (3)微服务更倾向于分布式去中心化的部署方式,在互联网Y业务场景下更适合。 SOA架构是一个面向服务的架构,可将其视为组件模型,其将系统整体拆分为多个独立的功能模 块,模块之间通过调用接口进行交互,有效整合了应用系统统的各项业务功能,系统各个模块之间是 松耦合的。SOA架构以企业服务总线链接各个子系统,是集中式的技术架构,应用服务间相互依赖导 致部署复杂,应用间交互使用远程通信,降低了响应速度。 微服务架构是SOA架构的进一步优化,去除了ESB企业服务总线,是一个真正意义上去中心化的分 布式架构。其降低了微服务之间的耦合程度,不同的微服务采用不同的数据库技术,服务独立,数 据源唯一,应用极易扩展和维护,同时降低了系统复杂性。
        • SOA参考架构
          • 这里考到的概率比较大，是面向服务架构的一个整体的图，每个空都要记住 典型的以服务为中心的企业集成架构如下图所示,采用"关注点分离"的方法规划企业集成中的 各种架构元素,同时从服务视角规划每种架构元素提供的服务,以以及服务如何被组合在一起完成某 种类型的集成。可划分为六大类: (1)业务逻辑服务:包括用于实现业务逻辑的服务和执行业务务逻辑的能力。 (2)控制服务:包括实现人、流程和信息集成的服务,以及执行这些集成逻辑的能力。 (3)连接服务:通过提供企业服务总线提供分布在各种架构元素中服务间的连接性 (4)业务创新和优化服务:用于监控业务系统运行时服务的业务性能,采取措施适应变化的市场。 (5)开发服务:贯彻整个软件开发生命周期的开发平台。 (6)IT服务管理:支持业务系统运行的各种基础设施管理能力或服务 
          • 连接服务--企业服务总线ESB
            • 1.连接服务--企业服务总线：ESB的基本特征和能力包括: 描述服务的元数据和服务注册管理; 在服务请求者和提供者之间传递数据,以及对这些数据进行转换的能力,开支持由实践中总结出 来的一些模式如同步模式、异模式等; 发现、路由、匹配和选择的能力,以支持服务之间的动态交互,解耦服务请求者和服务提供者。 高级一些的能力,包括对安全的支持、服务质量保证、可管理里性和负载平衡等。
          • 业务逻辑服务
            • 2.业务逻辑服务 1)整合已有应用--应用和信息访问服务:实现对已有应用和信息的集成,主要有两类访问服务 可接入服务、事件发现服务。 2)整合新开发的应用--业务应用服务:实现新应用集成,主要有三类业务应用服务:组件服务 (可重用)、核心服务(运行时)、接口服务。 3)整合客户和业务伙伴(B2C/B2B)--伙伴服务:提供与企业下部的B2B的集成能力,包括:社区 服务、文档服务、协议服务。
          • 控制服务
            • 3.控制服务 1)数据整合 -- 信息服务:提供集成数据的能力,目前主要包括如下集中信息息服务:联邦服务(不 同类型数据聚合)、复制服务(远程数据本地访问)、转换服务(格式转换)、搜索服务。 2)流程整合 -- 流程服务:完成业务流程集成,包括:编排服务(预定义流程顺序)、事务服务 (保证ACID)、人工服务(人工活动集成到流程中)。 3)用户访问整合 -- 交互服务:实现用户访问集成,包括:交付服务(运行时交)互框架)、体验服 务、资源服务(运行时交互组件的管理)。
          • 开发服务
            • 4.开发服务:开发环境和工具中为不同开发者的角色提供的功能被称为开发服务。根据开发过程中 开发者角色和职责的不同,有如下4类服务:建模服务、设计服务、实现服务、测试服务。
          • 业务创新和优化
            • 5.业务创新和优化:以业务性能管理(BPM)技术为核心提供业务事件发布、收集和关键业务指标监控 能力。包括以下服务: (1)公共事件框架服务:通过一个公共事件框架提供IT和业务事事件的激发、存储和分类等。 (2)采集服务通过基于策略的过滤和相关性分析检测感兴趣的服务 (3)监控服务:通过事件与监控上下文间的映射,计算和管理业业务流程的关键性能指标。
          • IT服务管理
            • 6.IT服务管理:为业务流程和服务提供安全、高效和健康的运行环境,包括:安全和目录服务、系 统管理和虚拟化服务。
        • SOA 主要协议和规范
          • Web服务最基本的协议包括UDDI、WSDL和SOAP,通过它们,可以提供直接而又简单的Web Service支持,如图所示。 UDDI(统一描述、发现和集成协议)计划是一个广泛的、开放的行业计划,它使得商业实体能够彼此发现;定义它们怎样在Internet上互相作用,并在一个全球球的注册体系架构中共享信息。 WSDL (Web服务描述语言),是一个用来描述Web服务和说明如问何与Web服务通信的XML语言。可描述三个基本属性:服务做些什么、如何访问服务、服务位于何可处。 SOAP是在分散或分布式的环境中交换信息的简单的协议,是是一个基于XML的协议。它包括4个部分SOAP封装,定义了一个描述消息中的内容是什么,是谁发送的的,谁应当接收并处理它以及如何处理它们的框架;SOAP编码规则,用于表示应用程序需要使用的数据类型的实例;SOAPRPC表示是远程过程调用和应答的协定;SOAP绑定是使用底层协议交换信息。 
        • SOA的设计原则
          • (1)无状态。以避免服务请求者依赖于服务提供者的状态。 (2)单一实例。避免功能冗余。 (3)明确定义的接口。使用者依赖服务规约调用服务,所以服务)定义必须长时间稳定,一旦公布,不 能随意更改;服务的定义应尽可能明确,减少使用者的不适当使用;不要让使用者看到服务内部的 私有数据。 (4)自包含和模块化。服务封装了那些在业务上稳定、重复出出现的活动和组件,实现服务的功能实体 是完全独立自主的,独立进行部署、版本控制、自我管理和恢复。 (5)粗粒度。服务数量不应该太大,依靠消息交互而不是远程过程调用(RPC),通常消息量比较大, 但是服务之间的交互频度较低。 (6)服务之间的松耦合性。服务使用者看到的是服务的接口,其位置、实现技术和当前状态等对使用 者是不可见的,服务私有数据对服务使用者是不可见的。 (7)重用能力。服务应该是可以重用的。 (8)互操作性、兼容和策略声明。为了确保服务规约的全面和明确,策略成为一个越来越重要的方面。 这可以是技术相关的内容,例如一个服务对安全性方面的要求;也可以是跟业务有关的语义方面的 内容,例如需要满足的费用或者服务级别方面的要求,这些策路对于服务在交互时是非常重要的。
        • SOA的设计模式
          • 企业服务总线模式
            • 另一个可能考的是企业服务总线,有可能让默写。 企业服务总线模式,由中间件技术实现的支持面向服务架构的基础软件平台,支持异构环境中的服 务以基于消息和事件驱动模式的交互,并且具有适当的服务质量和可可管理性。 一个典型的在ESB环境中组件之间的交互过程是:首先由服务请求者触发一次交互过程,产生一个服 务请求消息,并将该消息按照ESB的要求标准化,然后标准化的的消息被发送给服务总线。ESB根据请 求消息中的服务名或者接口名进行目的组件查找,将消息转发至目的约组件,并最终将处理结果逆向返 回给服务请求者。这种交互过程不再是点对点的直接交互相模式,而是由事件驱动的消息交互模式。 如下功能需要背下 ESB的核心功能如下。 (1)提供位置透明性的消息路由和寻址服务。 (2)提供服务注册和命名的管理功能。 (3)支持多种消息传递范型(如请求/响应、发布/订阅等)。 (4)支持多种可以广泛使用的传输协议。 (5)支持多种数据格式及其相互转换。 (6)提供日志和监控功能。
          • 微服务模式
            • 微服务模式,不再强调传统SOA架构里面比较重的ESB企业报务总线,同时SOA的思想进入到单个 业务系统内部实现真正的组件化。 微服务模式特点:复杂应用解耦、独立、技术选型灵活、容错、松耦合易扩展。 微服务架构的问题与挑战:微服务架构分布式特点带来的复杂性;微服务架构的分区数据库体系, 不同服务拥有不同数据库;增加了测试的复杂性;在大规模应用部署中,在监控、管理、分发及扩容 等方面,微服务也存在着巨大挑战。
        • 微服务架构案例分析1-24年5月
          • 1.简述微服务架构对比单体架构和微服务架构微服务架构的优缺点。(7分) 答:微服务架构是一种分布式系统架构,将一个应用程序拆分为一组小型、独立的服务,每个服务都围绕特定的业务功能构建,并通过轻量级通信机制进行通信。相比之下,单体架构将整个应用程序作为一个单一的单元构建和部署。 微服务架构的优点: 灵活性和可扩展性:每个微服务都是独立的,可以独立部署和扩展,使系统更具弹性。 技术多样性:每个微服务可以使用不同的技术栈,使开发团队可以选择最适合其需求的技术。 易于理解和维护:微服务的小型化和聚焦性使得代码更易于理里解、开发和维护。 微服务架构的缺点: 复杂性:微服务架构涉及到分布式系统,需要处理分布式事务、服务发现、服务治理等复杂问题。 部署和测试:由于微服务的数量增加,部署和测试变得更加复杂。 运维成本:微服务架构需要更多的运维工作,包括监控、日志志收集、故障排查等。 2. 质量属性及其场景(质量效用树),填空6个。(6分) 就是一个质量效用树,忘了把哪几个空挖了,反正考察,安全性,可用性,性能,可修改性 3.3.用质量属性6要素描述e)和h)两条可用性的场景描述。(12分 答:质量属性6要素描述: e)可连续运行时间不少于240h,断电或故障后10s内应重启 刺激源:断电或故障（一般和刺激不一样，但题目没给出刺激源，一般是人或某种错误） 刺激:系统故障或断电 制品:系统 环境:运行环境 响应:重启 响应度量:10秒内 h)网络失效后,10s内应发起重新连接 刺激源:网络失效 刺激:网络失效 制品:系统 环境:网络环境 响应:重新连接 响应度量:10秒内
      • 嵌入式系统架构
        • 鸿蒙操作系统架构案例分析
          • 这部分非常重要，最可能考的 这里考的话 题一考下面选词填空 题二考四个技术特性 题三考鸿蒙分布式架构的优势 鸿蒙(HarmonyOS)整体采用分层的层次化设计,从下向上依次为:内核层、系统服务层、框架层 和应用层。系统功能按照"系统"→"子系统"→"功能/模快"逐级展开,在多设备部署场景下, 支持根据实际需求裁剪某些非必要的子系统或功能/模块,  四层挖掉，四个子系统挖掉，内核层两个挖掉
          • 内核层
            • 1)内核层:主要由内核子系统和驱动子系统组成。 内核子系统:HarmonyOS采用多内核设计,支持针对不同资源受限设备选用适合的0S内核。内核抽 象层通过屏蔽多内核差异,对上层提供基础的内核能力。 驱动子系统:提供统一外设访问能力和驱动开发、管理框架。
          • 系统服务层
            • 2)系统服务层:是HarmonyOS的核心能力集合,通过框架层对应用程序提供服务。该层包含4个部分: 系统基本能力子系统集:为分布式应用在Harmony0S多设备上的运行、调度、迁移等操作提供了基 础能力。 基础软件服务子系统集:为Harmony0S提供公共的、通用的软件服务。 增强软件服务子系统集:为Harmony0S提供针对不同设备的、差异化的能力增强型软件服务。 硬件服务子系统集:为Harmony0S提供硬件服务。
          • 框架层
            • 3)框架层:为HarmonyOS的应用程序提供了Java/C/C++/JS等多语言的用户程序框架和Ability框架, 以及各种软硬件服务对外开放的多语言框架API:同时为采用HarmonyOS的设备提供了C/C++/JS等 多语言的框架API,不同设备支持的API与系统的组件化裁剪程度相关
          • 应用层
            • 4)应用层:包括系统应用和第三方非系统应用。Harmony0S的应用由一个或多个FA(Feature Ability)或PA(Particle Ability)组成。其中,FA有UI界面,提供与用户交互的能力;而PA 无UI界面,提供后台运行任务的能力以及统一的数据访问抽象。
          • 鸿蒙四个技术特性
            • 鸿蒙操作系统架构具有4个技术特性: 1)分布式架构首次用于终端0S,实现跨终端无缝协同体验。 2)确定时延引擎和高性能IPC技术实现系统天生流畅。 3)基于微内核架构重塑终端设备可信安全。 4)通过统一IDE支撑一次开发,多端部署,实现跨终端生态共享。
          • 分布式架构的优势
            • 在HarmonyOS架构中,重点关注于分布式架构所带来的优势,主要体现在下面四个方面: 分布式软总线是多种终端设备的统一基座,为设备之间的互联互通提供了统一的分布式通信能力; 分布式设备虚拟化平台可以实现不同设备的资源融合、设备管理、数据处理,多种设备共同形成 个超级虚拟终端。针对不同类型的任务,为用户匹配并选择能力合适的执行硬件; 分布式数据管理基于分布式软总线的能力,实现应用程序数据和用户数据的分布式管理。用户数 据不再与单一物理设备绑定,业务逻辑与数据存储分离,应用跨设备运行时数据无缝衔接; 分布式任务调度构建统一的分布式服务管理(发现、同步、注册、调用)机制,支持对跨设备的应 用进行远程启动、远程调用、远程连接以及迁移等操作,选择合适的设备运行分布式任务。
          • 24年11月预测题
            • 鸿蒙操作系统(Harmony0S)是一款"面向未来"、面向全场景(移动办公、运动健康、社交通信、媒体娱乐等)的分布式操作系统。在传统的单设备系统能力的基础上,Harmony0S提出了基于同一套系统能力、适配多种终端形态的分布式理念,能够支持多种终端设备的能力。 鸿蒙(Harmony0S)整体采用分层的层次化设计,其架构图如下所示:  【问题1】 请补充架构图中(1)-(6)空。 【问题2】 请列举出鸿蒙操作系统的四个技术特性。 【问题3】 在HarmonyOS架构中,重点关注于分布式架构所带来的优势,主要体现在哪四个方面,以及其分别含义是什么?
      • 安全架构
        • 在八大架构中优先级偏低
        • 安全威胁分类
          • 具体来讲,常见的安全威胁有以下几种。 (1)信息泄露:信息被泄露或透露给某个非授权的实体。 (2)破坏信息的完整性:数据被非授权地进行增删、修改或破坏而受到损失。 (3)拒绝服务:对信息或其他资源的合法访问被无条件地阻正。 (4)非法使用(非授权访问):某一资源被某个非授权的人或以非授权的方式使用。 (5)窃听:用各种可能的合法或非法的手段窃取系统中的信息资源和敏感信息。 (6)业务流分析:通过对系统进行长期监听,利用统计分析方法对诸如通信频度、通信的信息流向、 通信总量的变化等态势进行研究,从而发现有价值的信息和规律。 (7)假冒:通过欺骗通信系统(或用户)达到非法用户冒充成为合法用户,或者特权/小的用户冒充成 为特权大的用户的目的。黑客大多是采用假冒进行攻击。 (8)旁路控制:攻击者利用系统的安全缺陷或安全性上的脆弱之处获得非授权的权利或特权 (9)授权侵犯:被授权以某一目的使用某一系统或资源的某个人,去将此权限用于其他非授权的目的, 也称作"内部攻击"。 (10)特洛伊木马:软件中含有一个察觉不出的或者无害的程序段,当它被执行时,会破坏用户的安全。 (11)陷阱门:在某个系统或某个部件中设置了"机关",使得当提供特定的输入数据时,允许违反安 全策略。 (12)抵赖:这是一种来自用户的攻击,例如,否认自己曾经发布过的某条消息、伪造一份对方来信等。 (13)重放:所截获的某次合法的通信数据备份,出于非法的目的而被重新发送。 (14)计算机病毒:所谓计算机病毒,是一种在计算机系统运行过程中能够实现传染和侵害的功能程序。 一种病毒通常含有两个功能:一种功能是对其他程序产生"感染":另外一种或者是引发损坏功能或 者是一种植入攻击的能力。 (15)人员渎职：一个授权的人为了钱或利益、或由于粗心,将信息泄露给一个非找爱权的人 (16)媒体废弃：信息被从废弃的磁盘或打印过的存储介质中获得。 (17)物理侵入:侵入者通过绕过物理控制而获得对系统的访问。 (18)窃取:重要的安全物品,如令牌或身份卡被盗。 (19)业务欺骗:某一伪系统或系统部件欺骗合法的用户或系统自愿地放弃敏感信息。
        • 安全架构
          • 安全架构是架构面向安全性方向上的一种细分,通常的产品安全架构、安全技术体系架构和审计架构可组成三道安全防线。 (1)产品安全架构:构建产品安全质量属性的主要组成部分以及它们之间的关系。产品安全架构的目 标是如何在不依赖外部防御系统的情况下,从源头打造自身安全的产品 (2)安全技术体系架构:构建安全技术体系的主要组成部分以及它们之间的关系。安全技术体系架构的任务是构建通用的安全技术基础设施,包括安全基础设施、安全工具和技术、安全组件与支持系统等,系统性地增强各产品的安全防御能力。 (3)审计架构:独立的审计部门或其所能提供的风险发现能力,审计的范围主要包括安全风险在内的 所有风险。
        • 基于混合云的工业安全架构设计
          • 基于混合云的工业安全架构设计 下图给出了大型企业采用混合云技术的安全生产管理系统的架构,企业由多个跨区域的智能工厂和公 司总部组成,公司总部负责相关业务的管理、协调和统计分析,而每个智能工厂负责智能产品的设计 与生产制造。智能工厂内部采用私有云实现产品设计、数据共享和生产集成等,公司总部与智能工厂 间采用公有云实现智能工厂间、智能工厂与公司总部间的业务管理、协调和统计分析等。 整个安全生产管理系统架构由四层组成: 设备层主要是指用于智能工厂生产产品所需的相关设备; 控制层主要是指智能工厂生产产品所需要建立的套自动控制系统,控制智能设备完成生产工作; 设计/管理层是指智能工厂各种开发、业务控制和数据管理功能的集合,实现数据集成与应用; 应用层主要是指在云计算平台上进行信息处理,有两个核心功能,一是"数据",二是"应用"。 
        • 面向企业的安全控制系统架构
          • 
        • 电子商务系统的安全性设计
          • 认证、授权和审计(AAA)是运行于宽带网络接入服务器上的客户端程序。AAA提供了一个用来对认证、授权和审计三种安全功能进行配置的一致的框架,实际上是对网络安全的一种管理。 RADIUS服务器负责接收用户的连接请求,完成验证并把用户所需的配置信息返回给BAS建立连接,从而可以获得访问其他网络的权限时,BAS就起到了认证用户的作用。BAS负责把用户之间的验证信息传递通过密钥的参与来完成。用户的密码加密以后才能在网上传递,以避免用户的密码在不安全的网络上被窃取。 高性能的RADIUS软件架构核心如图所示。 
        • 信息安全包括哪5个常用的基本要素?
          • 机密性,完整性,可用性,抗抵赖性,可控性。 机密性:机密性是指网络信息不泄露给非授权的用户、实体或程序,能够防止非授权者获取信息。 完整性:完整性是指网络信息或系统未经授权不能进行更改的特性。 可用性:可用性是指合法许可的用户能够及时获取网络信息或服务的特性。 抗抵赖性:抗抵赖性是指防止网络信息系统相关用户否认其活动行为的特性。 可控性:可控性是指网络信息系统责任主体对其具有管理、支配能力的属性。
      • 通信系统架构
        • 考到概率最小
      • 大数据架构
        • 去年刚考过案例，今年5月考了论文，今年再考概率很低
        • Lambda架构
          • Lambda架构设计目的在于提供一个能满足大数据系统关键特性的架构,包括高容错、低延迟、可 扩展等。其整合离线计算与实时计算,融合不可变性、读写分离和复杂性隔离等原则。Lambda是用 于同时处理离线和实时数据的,可容错的,可扩展的分布式系统。它具备强鲁棒性,提供低延迟和 持续更新。 Lambda架构应用场景:机器学习、物联网、流处理。 如图所示,Lambda架构可分解为三层,即批处理层、加速层和服务层  (1)批处理层(Batch Layer):存储数据集,Batch Layer在数据集上预先计算查询函数,并构建查询 所对应的View。Batch Layer可以很好地处理离线数据,但有很多场景数据不断实时生成,并且需要 实时查询处理。Speed Layer正是用来处理增量的实时数据。 (2)加速层(Speed Layer):Batch Layer处理的是全体数据集,而Speed Layer处理的是最近的增量数据流。Speed Layer为了效率,在接收到新的数据后会不断更新Real-timeView,而BatchLayer 是根据全体离线数据集直接得到BatchView。 (3)服务层(Serving Layer):Serving Layer用于合并Batch View 和Real-time View中的结果数据 集到最终数据集。用于响应用户的查询请求。 如图所示,在这种Lambda架构实现中,Hadoop(HDFS)用于存储主数据集,Spark(或Storm)可构成速度层(Speed Layer),HBase(或Cassandra)作为服务层,由Hive创建可查询的视图。 
        • Kappa架构
          • Kappa架构的原理就是:在Lambda的基础上进行了优化,删除了Batch Layer的架构,将数据通道以消息队列进行替代。因此对于Kappa架构来说,依旧以流处理为主,但是数据却在数据湖层面进行了存储,当需要进行离线分析或者再次计算的时候,则将数敢据湖的数据再次经过消息队列重播一次则可。 如图所示,输入数据直接由实时层的实时数据处理引擎对源源原不断的源数据进行处理,再由服务层的服务后端进一步处理以提供上层的业务查询。而中间结果是的数据都是需要存储的,这些数据包括历史数据与结果数据,统一存储在存储介质中。 
        • Lambda架构与Kappa架构的对比和设计选择
          • 根据两种架构对比分析,将业务需求、技术要求、系统复杂度、开发维护成本和历史数据处理能 力作为选择考虑因素。而计算开销虽然存在一定差别,但是相差不是很大,所以不作为考虑因素。 1.业务需求与技术要求:如果业务对于Hadoop、Spark、Strom等关键技术有强制性依赖,选择 Lambda架构可能较为合适;如果处理数据偏好于流式计算,又依赖Flink计算引擎,那么选择 Kappa架构可能更为合适。 2.复杂度:如果项目中需要频繁地对算法模型参数进行修改,Lambda 架构需要反复修改两套代码, 则显然不如Kappa架构简单方便。同时,如果算法模型支持同时执行批处理和流式计算,或者希望用 一份代码进行数据处理,那么可以选择Kappa架构。 3.开发维护成本:Lambda架构需要有一定程度的开发维护成本,包括两套系统的开发、部署、测试、 维护,适合有足够经济、技术和人力资源的开发者。而Kappa架构只需要维护一套系统。 4.历史数据处理能力:有些情况下,项目会频繁接触海量数据集进行分析,应该选择Lambda架构。 如果始终使用小规模数据集,流处理系统完全可以使用,则应该选择Kappa架构 
        • 大数据架构设计案例分析
          • Lambda架构在某网奥运中的大数据应用 Lambda架构实时处理层采用增量计算实时数据的方式,可以在集群规模不变的前提下,秒级 分析出当日概览所需要的信息。赛事回顾模块需要展现自定义时间段内的历史最高在线人数、逐 日播放走势、直播最高在线人数和点播视频排行等海量数据的统计信息,由于奥运期间产生的数 据通常不需要被经常索引、更新,因此要求采用不可变方式存储所有的历史数据,以保证历史数 据的准确性。 Lambda架构的批处理层采用不可变存储模型,不断地往主数据集后追加新的数据,恰好可以满 足对奥运数据的大规模统计分析要求。具体架构如下图: 
        • 23年11月考题
          • 某网作为某电视台在互联网上的大型门户入口,某一年成为某奥运会中国大陆地区的特权转播商, 独家全程直播了某奥运会全部的赛事,积累了庞大稳定的用户群,这些用户在使用各类服务过程 中产生了大量数据,对这些海量数据进行分析与挖掘,将会对节目的传播及商业模式变现起到重 要的作用。 该奥运期间需要对增量数据在当日概览和赛事回顾两个层面上进行分析。 其中,当日概览模块需要秒级刷新直播在线人数、B网站的综合浏览量、页面停留时间、视频的 播放次数和平均播放时间等干万级数据量的实时信息,而传统的分布式架构采用重新计算的方式分 析实时数据,在不扩充以往集群规模的情况下,无法在几秒内分析出重要的信息。 赛事回顾模块需要展现自定义时间段内的历史最高在线人数、逐日播放走势、直播最高在线人数 和点播视频排行等海量数据的统计信息,由于该奥运期间产生的数据通常不需要被经常索引、更 新,因此要求采用不可变方式存储所有的历史数据,以保证历历史数据的准确性。 【问题1】 (8分) 请根据Lambda架构和Kappa架构特点,填写以下表格。  1. 两 2.一 3. 高 高 4. 低 低 5. 计算开销小 6. 满足实时性 7. 高 8. 弱 【问题2】(9分> 下图1给出了某网奥运的大数据架构图,请根据下面的(a)~(n)的相关技术;判断这此技术属于架构图的哪个部分,补充完善下图1的(1)-(9)的空白处。 (a)Nginx;(b)Hbase;(c)SparkStreaming;(d)Spark;(e) MapReduce; (f)ETL;(g)MemSQL;(h)HDFS;(i)Sqoop;(j)Flume;(k)数据存储层; (1)kafka (m)数据采集层 (n)业务逻辑层  (1)d (2) e (3) k (4)g (5) h (6) l (7) j (8) f (9)n 【问题3】(8分,每空2分> 大数据的架构包括了Lambda架构和Kappa架构,Lambda 架构分解为三层:即(1)、(2)和(3);Kappa架构 不同于Lambda同时计算流计算和批计算并合并视图, Kappa只会通过流计算一条的数据链路计算并产生视图。 请问该系统的大数据架构是基于哪种架构搭建的大数据 平台处理奥运会大规模视频网络观看数据。 答： (1)批处理层(2)加速层(3)服务层 该系统的大数据架构是基于Lambda架构搭建的大数据平台处理奥运会大规模视频网络观看观看数据。
        • 某证券公司大数据系统
          • 实时日志分析平台基于Kappa架构,使用统一的数据处理引擎Flink可实时处理全部数据,并将其存储到Elastic-Search与OpenTSDB中。实时处理过程如下: 
    • 质量属性+架构风格
      • 题1
        • 22年11月 某电子商务公司拟升级其会员与促销管理系统,向用户提供个性化服务,提高用户的粘性。在项目立项之初,公司领导层一致认为本次升级的主要目标是提升会员管理方式的灵活性,由于当前用户规模不大,业务也相对简单,系统性能方面不做过多考虑。新系统除了保持现有的四级固定会员制度外,还需要根据用户的消费金额、偏好、重复性等相关特征动态调整商品的折扣力度并支持在特定的活动周期内主动筛选与活动主题高度相关的用户集合,提供个性化的打折促销活动。 在需求分析与架构设计阶段,公司提出的需求和质量属性描述如下: (a)管理员能够在页面上灵活设置折扣力度规则和促销活动逻辑,设置后即可生效 (b)系统应该具备完整的安全防护措施,支持对恶意攻击行为进行检测与报警 (c)在正常负载情况下,系统应在0.3秒内对用户的界面操作请求进行响应 (d)用户名是系统唯一标识,要求以字母开头,由数字和字母组合而成,长度不少于6个字符; (e)在正常负载情况下,用户支付商品费用后在3秒内确认订单支付信息; (f)系统主站点电力中断后,应在5秒内将请求重定向到备用站点; (g)系统支持横向存储扩展,要求在2人天内完成所有的扩展与测试工作; (h)系统宕机后,需要在10秒内感知错误,并自动启动热备份系统; (i)系统需要内置接口函数,支持开发团队进行功能调试与系统诊断; (j)系统需要为所有的用户操作行为进行详细记录,便于后期查阅与审计: (k)支持对系统的外观进行调整和配置,调整工作需要在4人天内完成。 在对系统需求、质量属性描述和架构特性进行分析的基础上,系统架构师给出了两种候选的架构设计方案, 公司目前正在组织相关专家对系统架构进行评估。 【问题1】(12分) 在架构评估过程中,质量属性效用树(utility tree)是对系 统质量属性进行识别和优先级排序的重要工具。请将合适的质 量属性名称填入图1-1中(1)、(2)空白处,并选择题干描述的 (a)~(k)填入(3)~(6)空白处,完成该系统的效用树。  1.安全性 2.可修改性 3.e 4.j 5.h 6.k 【问题2】(13分) 针对该系统的功能,李工建议采用面向对象的架构风格,将折 扣力度计算和用户筛选分别封装为独立对象,通过对象调用实 现对应的功能;王工则建议采用解释器(interpreters)架构 风格,将折扣力度计算和用户筛选条件封装为独立的规则,通 过解释规则实现对应的功能。请针对系统的主要功能,从折扣 规则的可修改性、个性化折扣定义灵活性和系统性能三个方面 对这两种架构风格进行比较与分析,并指出该系统更适合采用 哪种架构风格。 答： 应该选择解释器架构风格。 折扣规则的可修改性:解释器风格比面向对象方式实现强。因为解释器风格折扣规则是独立的语法规 则,由解释器可对变化的规则进行解析,修改更容易。而面向对象相对固定,有变化需要修改具体的 类。 个性化折扣定义灵活性:解释器强于面向对象,解释器可以根据用户灵活解释执行规则,做到千人千 面。 系统性能:面向对象优于解释器。面向对象的实现相对固定,而解释器是运行期动态绑定执行。
        • 架构风格选择对比-优缺点
          • 某公司拟开发一套机器学习应用开发平台,支持用户使用浏览器居在线进行基于机器学习的智能应用开发活动。 该平台的核心应用场景是用户通过拖拽算法组件灵活定义机器学习流程,采用自助方式进行智能应用设计、实现与部署,并可以 开发新算法组件加入平台中。在需求分析与架构设计阶段,公司别提出的需求和质量属性描述如下 。。。。 【问题2】(16分) 针对该系统的功能,赵工建议采用解释器(interpreter)架构风格,李工建议采用管道过滤器(pipe-and-filter)的架构风格,王工则建议采用隐式调用(implicit invocation)架构风格。请针对平台的核心应用场景,从机器学习流程定义的灵活性和学习算法的可扩展性两个方面对三种架构风格进行对比与分析,并指出该平台更适合采用哪种架构风格。 答： 1.管道-过滤器风格具备高内聚低耦合、支持软件重用、扩展性好、支持并发等优点,但它有编写复杂、不适合处理交互应用等缺点; 2.隐式调用基于事件触发思想,具备支持软件重用、改进系统方便等优点,但它有构件放弃了对系统计算的控制、事件传递中的数据交换存在问题、语义依赖于被触发事件的上下文约束等缺点。 3.解释器通常包括解释引擎、代码存储区、记录解释引擎当前工作状态的数据结构、记录源代码被解释执行进度的数据结构。它含有一个虚拟机,可以仿真硬件的执行过程和一些关键应用,其缺点是执行效率比较低。优点:语法由很多类(每个规则对应一个类)表示,容易改变及扩展;缺点:如果语法规则数量太多,会增加系统复杂度,性能下降。 本题中,由于需要交互操作,显然管道-过滤器风格不合适;基于事件触发的隐式调用风格也不合适;只有解释器风格通过灵活自定义规则,具备较强的灵活性和可扩展性,适合本题中的机器学习应用。
      • 题2
        • 【说明】某电子商务公司拟升级目前正在使用的在线交易系统,以提高客户网上购物时在线支付环节 的效率和安全性。公司研发部门在需求分析的基础上,给出了在线交易系统的架构设计。公司组织相 关人员召开了针对架构设计的评估会议,会上用户提出的需求、架构师识别的关键质量属性场景和评 估专家的意见等内容部分列举如下: (a)在正常负载情况下,系统必须在0.5秒内响应用户的交易请求; (b)用户的信用卡支付必须保证99.999%的安全性; (c)系统升级后用户名要求至少包含8个字符; (d)网络失效后,系统需要在2分钟内发现错误并启用备用系统; (e)在高峰负载情况下,用户发起支付请求后系统必须在10秒内完成支付功能; (f)系统拟采用新的加密算法,这会提高系统安全性,但同时会降低低系统的性能; (g)对交易请求处理时间的要求将影响系统数据传输协议和交易处理过程的设计 (h)需要在30人月内为系统添加公司新购买的事务处理中间件; (i)现有架构设计中的支付部分与第三方支付平台紧耦合,当系统需要支持新的支付平台时,这种 设计会导致支付部分代码的修改,影响系统的可修改性; (j)主站点断电后,需要在3秒内将访问请求重定向到备用站点; (k)用户信息数据库授权必须保证99.999%可用; (1)系统需要对Web界面风格进行修改,修改工作必须在4人月内完成; (m)系统需要为后端工程师提供远程调试接口,并支持远程调试。 【问题1】(12分) 在架构评估过程中,质量属性效用树(utility tree)是对 系统质量属性进行识别和优先级排序的重要工具。请 给出合适的质量属性,填入图4-1中(1)、(2)空白 处;并选择题干描述的(a)~(m),填入(3) (6)空白处,完成该系统的效用树。  (1)性能 (2)可修改性 (3)(e) (4)(j) (5)(1) (6)(k) 【问题2】(13分)在架构评估过程中,需要正确识别 系统的架构风险、敏感点和权衡点,并进行合理的架 构决策。请用300字以内的文字给出系统架构风险、敏 感点和权衡点的定义,并从题干(a)~(m)中各选 出1个对系统架构风险、敏感点和权衡点最为恰当的描 述。 答： 系统架构风险是指架构设计中潜在的、存在问题题的架构决策所带来 的隐患。 敏感点是指为了实现某种特定的质量属性,一个或多个构件所具有的特性 权衡点是影响多个质量属性的特性,是多个质量属性的敏感点。 风险点:(g);敏感点:(i);权衡点:(f)。
      • 题3-架构风格
        • 阅读以下关于软件架构风格的说明,在答题纸上回答问题1和问题2。 【说明】某软件公司为其新推出的字处理软件设计了一种脚本语言,专门用于开发该字处理软件 的附加功能插件。为了提高该语言的编程效率,公司组织软件工具开发部门为脚本语言研制一套 集成开发环境。软件工具开发部门根据字处理软件的特点,对集成开发环境进行了需求分析,总 结出以下3项核心需求: (1)集成开发环境需要提供对脚本语言的编辑、语法检查、解释、执行和调试等功能的支持,并 要实现各种功能的灵活组合、配置与替换。 (2)集成开发环境需要提供一组可视化的编程界面,用户通过又对界面元素拖拽和代码填充的方式 就可以完成功能插件核心业务流程的编写与组织。 (3)在代码调试功能方面,集成开发环境需要实现在脚本语言编辑界面中的代码自动定位功能。 具体来说,在调试过程中,编辑界面需要响应调试断点命中事件,并自动跳转到当前断点处所对 应的代码。 针对上述需求,软件工具开发部门对集成开发环境的架构进行分析与与设计,王工认为该集成开发 环境应该采用管道-过滤器的架构风格实现,李工则认为该集成开发环境应该采用以数据存储为中 心的架构风格来实现。公司组织专家对王工和李工的方案进行了了评审,最终采用了李工的方案。 【问题1】(12分)请用200字以内的文字解释什么是软件架构风格,并从集成开发环境与用户的 交互方式、集成开发环境的扩展性、集成开发环境的数据管理三个方面说明为什么最终采用了李 工的设计方案。 【问题2】(13分)在对软件系统架构进行设计时,要对架构需求进行分析,针对特定需求选择 最为合适的架构风格,因此实际的软件系统通常会混合多种软件架构风路。请对核心需求进行分 析,说明为了满足需求(2)和(3),分别应采用何种架构风格,并并概要说明采用相应架构风格 后的架构设计过程。
    • 系统需求
      • 题1
        • 阅读以下关于软件系统设计的叙述,在答题纸上回答问题1至问题3。 【说明】 某文化产业集团委托软件公司开发一套文化用品商城系统,业务涉及文化用品销售、定制、竞拍 和点评等板块,以提升商城的信息化建设水平。该软件公司组织只项目组完成了需求调研,现已进 入到系统架构设计阶段。考虑到系统需求对架构设计决策的影响,I项目组先列出了可能影响系统 架构设计的部分需求如下: (a)用户界面支持用户的个性化定制; (b)系统需要支持当前主流的标准和服务,特别是通信协议和平台接口; (c)用户操作的响应时间应不大于3秒,竞拍板块不大于1秒; (d)系统具有故障诊断和快速恢复能力; (e)用户密码需要加密传输; (f)系统需要支持不低于2G的数据缓存; (g)用户操作停滞时间超过一定时限需要重新登录验证; (h)系统支持用户选择汉语、英语或法语三种语言之一进行操作。 项目组提出了两种系统架构设计方案:瘦客户端C/S架构和胖客户端C/S架构,经过对上述需求 逐条分析和讨论,最终决定采用瘦客户端C/S架构进行设计。 【问题1】(8分) 在系统架构设计中,决定系统架构设计的非功能性需求主要有四类:操作性需求、性能需求、安 全性需求和文化需求。请简要说明四类需求的含义。 答： 系统性能需求:指响应时间、吞吐量、准确性、有效性、资源利用月率等与系统完成任务效率相关的 指标。可靠性、可用性等指标归为此类。 安全性需求:系统向合法用户提供服务并阻止非授权用户使用服务方面的系统需求。 操作性需求:与用户操作使用系统相关的一些需求。 文化需求:带有文化背景因素的系统需求。 【问题2】 (8分) 性能需求 根据表1-1的分类,将题干所给出的系统需求(a)~(h)分别填入(1)~(4)。 表1-1需求分类  答： (1)(a)(b) (2)(c)(d)(f) (3)(e)(g) (4)(h) 【问题3】 (9分) 请说明瘦客户端C/S架构能够满足题干中给出的哪些系统需求(只需要回答出三个系统需求）。 (a)瘦客户端，把业务逻辑从客户端放到了服务上。 (b)胖和瘦无明显差异 (c)胖客户端,在客户端的运算能力强一些。瘦客户端可以在服务站端面用集群做支持 (d)瘦客户端将业务逻辑迁移到应用服务器上,所以故障只要修复报务器上的内容,而胖客户端要 更新所有客户端,工作量大,所以此情况下瘦客户端有优势。 (e)胖客户端的后端是数据库,没有业务逻辑,此时要做加密传专输没有基础,但瘦客户端可以做到。 (f)胖客户端做到2G数据缓存很容易,而瘦客户端不现实。 (g)瘦客户端与胖客户端均可做到。 (h)瘦客户端与胖客户端均可做到。
    • 其他考题
      • 分布式架构设计
        • 题1
          • 补全架构图 
      • 紧耦合和封装
        • FACE架构的核心能力是可支持应用程序的跨平台执行和可移植性,要达到可移植能力,必须解决应用程序的紧耦合和封装的障碍。请用200字以内的文字简要说明在可移植性上,应用程序的紧耦合和封装问题的主要表现分别是什么,并给出解决方案。 答： 紧耦合问题通常指的是系统中不同部分之间的高度依赖关系。主要要变现在:I/0问题、业务逻辑问题、表现问题。 为了解决紧耦合问题,可以采用分离原则。这意味着将系统的不同部分(如l/0、业务逻辑、表现层等)进行隔离,使得它们之间的的依赖关系尽可能少。 (2)封装通过将对象的属性和方法隐藏起来,只提供必要的接口共外部调用,主要表现在:ICD硬编码问题、组件的紧耦合问题、直接调用问题 为了解决封装问题,可以采用提供数据源或槽的软件服务的方法。将紧耦合组件分解出应用程序,并将平台相关部分加入计算环境钟,在计算平台内提供数据源或槽的软件服务,并实现接口标准化。
      • 构件
        • 基于构件的软件开发中,可以通过不同的途径来获取构件,主要包括以下4种方法: 从现有构件中获得符合要求的构件,直接使用或做适应性修改收,得到可复用的构件; 通过遗留工程(LegacyEngineering),将具有潜在复用价值的软件提取出来,得到可复用的构件; 从市场上购买现成的商业构件,即COTS (Commercial Off-The-SShell)构件; 开发新的符合要求的构件。 开发构件通常采取3种策略: 分区(partitioning):指的是将问题情景的空间分割成几乎可以独立研究的部分; 抽象(abstraction):是对在给定实践内执行指定计算的软/硬件单元的一种抽象; 分割(segmentation);是将结构引入构件的行为,支持对行为性质进行时序推理。 当前主流构件标准有: CORBA:由OMG(对象管理集团)制定; COM/DCOM:由Microsoft制定; EJB:由SUN的Java企业Bean制定。 构件组装技术： 构件构建在平台之上,平台提供核心平台服务,是构件实现与构件组装的基础。构件组装通常采用基于功能的组装技术、基于数据的组装技术和面向对象的组装技术等三种技术"。
  • 嵌入式专题
    • 几乎每年必考一题,选做题,考察比较的多的是嵌入式系统的实时性和可靠性以及容错等概念。 大概率会考到一些嵌入式领域陌生技术,如果是完全没见过的技术,不选即可。 相关概念 系统可靠性是系统在规定的时间内及规定的环境条件下,完成规定功能的能力,也就是系统无 故障运行的概率。 系统可用性是指在某个给定时间点上系统能够按照需求执行的概率。 可靠度就是系统在规定的条件下、规定的时间内不发生失效的概率。 失效率又称风险函数,也可以称为条件失效强度,是指运行至此刻系统未出现失效的情况下, 单位时间系统出现失效的概率。 软件可靠性和硬件可靠性区别 复杂性:软件复杂性比硬件高,大部分失效来自于软件失效。 物理退化:硬件失效主要是物理退化所致,软件不存在物理退化。 唯一性:软件是唯一的,每个COPY版本都一样,而两个硬件不可能完全一样 版本更新周期:硬件较慢,软件较快。 提高系统可靠性的技术可以分为避错(排错)技术和容错技术。避错是通过技术评审、系统测试 和正确性证明等技术,在系统正式运行之前避免、发现和改正错误。 容错是指系统在运行过程中发生一定的硬件故障或软件错误时,仍能保持正常工作而不影响正确 结果的一种性能或措施。容错技术主要是采用冗余方法来消除故障的影响。 冗余是指在正常系统运行所需的基础上加上一定数量的资源,包活信息、时间、硬件和软件。冗 余是容错技术的基础,通过冗余资源的加入,可以使系统的可靠性得到较大的提高。主要的冗余 技术有结构冗余(静态、动态、混合)、信息冗余、时间冗余和冗余附加4种。 软件容错的主要方法是提供足够的冗余信息和算法程序,使系统在实际运行时能够及时发现程序 设计错误,采取补救措施,以提高系统可靠性,保证整个系统的正常运行。 软件容错技术主要有N版本程序设计、恢复块方法和防卫式程星序设计等
    • 容错
    • 负载均衡
      • 负载均衡是集群系统中的一项重要技术，可以提高集群系统的整体处理能力,也提高了系统的可靠 性,最终目的是加快集群系统的响应速度,提高客户端访问的成功概率。集群的最大特征是多个节点 的并行和共同工作,如何让所有节点承受的负荷平均,不出现局部过大负载或过轻负载的情况,是负 载均衡的重要目的。 比较常用的负载均衡实现技术主要有以下几种: (1)基于特定软件的负载均衡(应用层)。很多网络协议都支持重定向功能,例如,基于HTTP重定 向服务,其主要原理是服务器使用HTTP重定向指令,将一个客户端重新定位到另一个位置。服务器返 回一个重定向响应,而不是返回请求的对象。客户端确认新地址然后重发请求,从而达到负载均衡的 目的。 (2)基于DNS的负载均衡属于传输层负载均衡技术,其主要原理是在DNS服务器中为同一个主机名配 置多个地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主几记录的IP地址按顺序返回 不同的解析结果,将客户端的访问引导到不同的节点上去,使得不同的客户端访问不同的节点,从而 达到负载均衡的目的。 (3)基于NAT的负载均衡。将一个外部IP地址映射为多个内部IP地址,对每次连接需求动态地转换为 一个内部节点的地址,将外部连接请求引到转换得到地址的那个节点,上从而达到负载均衡的目的目的。 (4)反向代理负载均衡。将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的 多个节点进行处理,从而达到负载均衡的目的。 (5)混合型负载均衡。
    • 题1
      • 阅读以下信息系统可靠性的问题,在答题纸上回答问题1至问题3。 某软件公司开发一项基于数据流的软件,其系统的主要功能是对输入的数据进进行多次分 析、处理和加工,生成需要的输出数据。需求方对该系统的软件可靠性要求很高,要求系统能够 长时间无故障运行。该公司将该系统设计交给王工负责。王工给出该系统的模块示意图如图5-1所 示。王工解释:只要各个模块的可靠度足够高,失效率足够低,则整个软件系统的可靠性是有保 证的。  李工对王工的方案提出了异议。李工认为王工的说法有两个问题:第一,即使每个模块 的可靠度足够高,假设各个模块的可靠度均为0.99,但是整个软件系统统模块之间全部采用串联 则整个软件系统的可靠度为0.994=0.96,即整个软件系统的可靠度下降明显;第二,软件系统模 块全部采用串联结构,一旦某个模块失效,则意味着整个软件系统统失效。 李文认为,应该在软件系统中采用冗余技术中的动态冗余或者软件:容错的N版本程序设 计技术,对容易失效或者非常重要的模块进行冗余设计,将模块之间的串联结构部分变为并联结 构,来提高整个软件系统的可靠性。同时,李工给出了采用动态冗余技术后的软件系统模块示意 图,如图5-2所示。  刘工建议,李工方案中M1和M4模块没有采用容错设计,但M1和M4发生故障有可能导致 严重后果。因此,可以在M1和M4模块设计上采用检错技术在软件出现故障后能及时发现并报 警,提醒维护人员进行处理。 注:假设各个模块的可靠度均为0.99 【问题1】(4分) 在系统可靠性中,可靠度和失效率是两个非常关键的指标,请分别解释其含义。 答： 可靠度就是系统在规定的条件下、规定的时间内不发生失效的的概率。 失效率又称风险函数,也可以称为条件失效强度,是指运行至亚刻系统未出现失效的情况下,单 位时间系统出现失效的概率。 【问题2】(13分) 请解释李工提出的动态冗余和N版本程序设计技术,给出图5-1中模块M2采用图5-2动态冗余技术 后的可靠度。请给出采用李工设计方案后整个系统可靠度的计算方法,并计算结果。 答： 动态冗余又称为主动冗余,它是通过故障检测、故障定位及故障恢复等手段达到容错 的目的。其主要方式是多重模块待机储备,当系统检测到某工作摸块出现错误时,就用一个备用 的模块来替代它并重新运行。各备用模块在其待机时,可与主模块一样工作,也可以不工作。前 者叫热备份系统(双重系统),后者叫冷备份系统(双工系统、双份系统) N版本程序设计是一种静态的故障屏蔽技术,其设计思想是用N个,具有相同功能的程序同时执行一 项计算,结果通过多数表决来选择。其中N个版本的程序必须由不不同的人独立设计,使用不同的 方法、设计语言、开发环境和工具来实现,目的是减少N个版本的程序在表决点上相关错误的概 率。M2采用动态冗余后的可靠度为: R = 1 - (1-0.99) 3 =0.99999 李工给出的方案同时采用了串联和并联方式,其计算方法为首先计算出中间M2和M3两个并联系 统的可靠度,再按照串联系统的计算方法计算出整个系统的可靠度。 R = 0.99 * 0.999999999999999999 * 0.99 = 0.98 【问题3】(8分) 请给出检错技术的优缺点,并说明检测技术常见的实现方式和处理方式。 答： 检错技术实现的代价一般低于容错技术和冗余技术,但有一个明显的缺点,就是不能 自动解决故障,出现故障后如果不进行人工干预,将最终导致软件系统不能正常运行。 检错技术常见的实现方式:最直接的一种实现方式是判断返回结果如果返回结果超出正常范围, 则进行异常处理;计算运行时间也是一种常用技术,如果某个模块或函数运行时间超过预期时间, 可以判断出现故障;还有置状态标志位等多种方法,自检的实现方式需要根据实际情况来选用。 检错技术的处理方式,大多数都采用"查处故障-停止软件运行-报警"的处理方式。但根据故障的 不同情况,也有采用不停止或部分停止软件系统运行的情况,这一般由故障是否需要实时处理来 决定。
  • web应用开发
    • Web应用技术分类 从架构来看:MVC,MVP,MWM,REST, Webservice,微服务。 从缓存来看:MemCache,Redis,Squid。 从并发分流来看:集群(负载均衡)、CDN。 从数据库来看:主从库(主从复制),内存数据库,反规范化技术,NoSQL 分区(分表)技术,视图。 从持久化来看:Hibernate,Mybatis。 从分布存储来看:Hadoop,FastDFS,区块链。 从数据编码看:XML,JSON。 从Web应用服务器来看:Apache,WebSphere,Weblogic, Tonncat, JBOSS, IIS。 其它:有状态与无状态,响应式Web设计。
    • Web技术演变
      • Web技术演变 单台机器到数据库与Web服务器分离  应用服务器集群,存在问题:用户的请求由谁来转发到具体的应用服务器（负载均衡问题）; 用户如果每次访问到的服务器不一样,那么如何维护session的一致性。  解决问题： 1.采用负载均衡技术 
    • CDN
      • CDN的全称是Content Delivery Network,即内容分发网络。 CDN是构建在网络之上的内容分发网络,依靠部署在各地的边缘朋务器,通 过中心平台的负载均衡、内容分发、调度等功能模块,使用户就近获取所需内 容,降低网络拥塞,提高用户访问响应速度和命中率。CDN的关键技术主要有 内容存储和分发技术。 CDN的基本原理是广泛采用各种缓存服务器,将这些缓存服务器分布到用户 访问相对集中的地区或网络中,在用户访问网站时,利用全局负载技术将用户 的访问指向距离最近的工作正常的缓存服务器上,由缓存服务器直接响应用户 请求。
    • REST
      • 再考可能性较小 REST(表述性状态传递) REST(Representational State Transfer,一表述性状态转移)是一种只使用HTTP和XML进行基于Web通信的技术,可以降低开发的复杂性,提高系统的可伸缩性。 REST是一种设计风格而不是一个架构。 REST是以资源为中心构建的。 REST的状态转移是借助HTTP方法来实现。 REST的5个原则 (1)网络上的所有事物都被抽象为资源。 (2)每个资源对应一个唯一的资源标识。 (3)通过通用的连接件接口对资源进行操作。 (4)对资源的各种操作不会改变资源标识。 (5)所有的操作都是无状态的。
    • 微服务架构
      • 17年考过，之后再考可能性较小 24年案例第一题考到了 微服务架构建议将大型复杂的单体架构应用划分为一组微小的朋务,每个微 服务根据其负责的具体业务职责提炼为单一的业务功能;每个朋虽好可以很容易 地部署并发布到生产环境里隔离和独立的进程内部,它可以很容易地扩展和变 更;对于一个具体的服务来说可以采用任何适用的语言和工具来快速实现;服 务之间基于基础设施互相协同工作。 微服务的优势: (1)解决了复杂性问题。它把庞大的单一模块应用分解为一系列的服务,同时 保持总体功能不变。 (2)让每个服务能够独立开发,开发者能够自由选择可行的技术,让服务来决 定API约定。 (3)每个微服务都能独立配置,开发者不必协调对于本地服务配置上的变化 这种变化一旦测试完成就被配置了。 (4)让每个服务都可以独立调整,你可以给每个服务配置正好满足容量和可用 性限制的实例数。 微服务架构带来的挑战 (1)并非所有的系统都能转成微服务，例如一些数据库层的底层操作是不推不荐 服务化的。 (2)部署较以往架构更加复杂: 系统由众多微服务搭建,每个微服务需要单独 部署,从而增加部署的复杂度,容器技术能够解决这一问题。 (3)性能问题:由于微服务注重独立性,互相通信时只能通过标准维接口,可能 产生延迟或调用出错。例如一个服务需要访问另一个服务的数据,只能通过服 务间接口来进行数据传输,如果是频繁访问,则可能带来较大的延运。 (4)数据一致性问题:作为分布式部署的微服务,在保持数据一致性方面需要 比传统架构更加困难。
    • XML
      • 扩展标记语言(Extensible Markup Language,XML),用于标记电子文件 使其具有结构性的标记语言,可以用来标记数据、定义数据类型,是一种允许 用户对自己的标记语言进行定义的源语言。 XML的优点 格式统一,符合标准; 容易与其他系统选行远程交互,数据共享比较方便。 XML的缺点 XML文件庞大,文件格式复杂,传输占带宽; 服务器端和客户端都需要花费大量代码来解析XML,导致服务器端和客端代 码变得异常复杂且不易维护; 客户端不同浏览器之间解析XML的方式不一致,需要重复编偏写很多代码;
    • JSON
      • JSON(JavaScript Object Notation)一种轻量级的数据交换格式,具有良 好的可读和便于快速编写的特性。可在不同平台之间进行数据交换。 JSON的优点 数据格式比较简单,易于读写,格式都是压缩的,占用带宽小; 易于解析,客户端JavaScript可以简单的通过eval()进行JSON数据的读取; 支持多种语言,包括ActionScript,C,C#,ColdFusion,Java,JavaScript, Perl, PHP,Python,Ruby等服务器端语言,便于服务器端的解析; 因为JSON格式能直接为服务器端代码使用,大大简化了服务器端和客户端的代 码开发量,旦完成任务不变,并且易于维护。 JSON的缺点 没有XML格式这么推广的深入人心和使用广泛,没有XML那么通用性。
    • MQTT
      • MQTT(消息队列遥测传输)是一个基于发布/订阅模式的消息协议。它工作在TCP/IP协议族上,是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布/订阅型消息协议。MQTT协议是轻量、简单、开放和易于实现的。
    • 区块链
      • 区块链的特点： 1.去中心化:区块链是由多个节点组成的分布式网络,没有中央控制机构,所有参与者共同验证和维护交易的准确性和完整性 2.开放性:区块链的参与者可以自由加入和退出网络,任何人都可以查看和验证链上的数据和交易,实现了公开透明的特性。 3.自治性:区块链采用基于协商一致的规范和协议使得整个系统中的所有结点能够在去信任的环境自由安全的交换数据,使得对"人"的信任改成了对机器的信任,任何人为的干预不起作用。 4.安全性:通过使用密码学技术和一致性协议,区块链保护了数据的安全性和防簒改性,使得交易记录和数据具有高度的可信性。 5.匿名性:由于节点间的数据交互遵循固定的算法,交易对手无需公开身份即可产生信任,这有助于信用的累积。
    • 题1
      • 阅读以下关于Web系统设计的叙述,在答题纸上回答问题1至问题3。 【说明】 某银行拟将以分行为主体的银行信息系统,全面整合为由总行统一管理维护的银行信息系统,实现统一的用户账户管理、转账汇款、自助缴费、理财投资、货款管理、网上支付、财务报表分析等业务功能。但是,由于原有以分行为主体的银行信息系统中中,多个业务系统采用异构平台、数据库和中间件,使用的报文交换标准和通信协议也不尽相同,使用传统的EAI解决方案根本无法实现新的业务模式下异构系统间灵活的交互和集成。 因此,为了以最小的系统改进整合现有的基于不同技术实现的银行业务系统,该银行拟采用基于ESB的面向服务架构(SOA)集成方案实现业务整合。 【问题1】 (7分) 请说明什么是面向服务架构(SOA)以及ESB在SOA中的作用与特点。 答： SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用方式进行交互。 ESB作用于特点: 1、SOA的一种实现方式,ESB在面向服务的架构中起到的是总线作用,将各种服务进行连接与整合 2、描述服务的元数据和服务注册管理; 3、在服务请求者和提供者之间传递数据,以及对这些数据进行转换的能力力,并支持由实践中总结出来的一些模式如同步模式、异步模式等; 4、发现、路由、匹配和选择的能力,以支持服务之间的动态交互,解耦服务请求者和服务提供者高级一些的能力,包括对安全的支持、服务质量保证、可管理性和负载平衡等。 【问题2】(12分) 基于该信息系统整合的实际需求,项目组完成了基于SOA的银行信息系统架构设计方案。该系统架构图如图5-1所示:  请从(a)~(i) 中选择相应内容填入图5-1的(1)~(6),补充完善架构设计图。 (a)数据层 (b)界面层 (c)业务层 (d)bind (e)企业服务总线ESB (f) XML (g)安全验证和质量管理 (h)publish (i) UDDI (j)组件层 (k)BPEL 答： 1.业务层 2.UDDI（发现服务） 3.publish 4.企业服务总线ESB 5.安全验证和质量管理 6.组件层 【问题3】(6分) 针对银行信息系统的数据交互安全性需求,列举3种可实现信息系统安全保障的措施。 答： 1、引入https协议或采用加密技术对数据先加密再传输 2、采用信息摘要技术对重要信息进行完整性验证 3、交易类敏感信息采用数字签名机制（用于不可抵赖性）
    • 2016题2应用服务器&J2EE
      • 阅读以下关于应用服务器的叙述,回答问题1至问题3。 【说明】 某电子产品制造公司,几年前开发建设了企业网站系统,实现见了企业宣传、产品介绍、客服以及售后服务等基本功能。该网站技术上采用了Web服务器、动态脚本语言PHP。随着市场销售渠道变化。以及企业业务的急剧拓展,该公司急需建立完善的电子商务平台。 公司张工建议对原有网站系统进行扩展,增加新的功能(包括订单系统统、支付系统、库存管理等),这样有利于降低成本、快速上线;而王工则认为原有网站系统在技术上存在先天不足,不能满足企业业务的快速发展,尤其是企业业务将服务全球,需要提供24小时不间断服务,系统在大负荷和长时间运行下的稳定性至关重要。建议采用应用服务器的Web开发方法,例如J2EE,为该企业重新开发新的电子商务平台。 【问题1】(7分) 王工认为原有网站在技术上存在先天不足,不能满足企业业务的快速发展,根据你的理解,请用300字以内的文字说明原系统存在哪几个方面的不足。 答： 1、PHP 只能实现简单的分布式两层或三层的架构，而 JAVA 在这方面就比较强大，可以实现多层的网络架构。数据库层(持久化层)、应用(业务)逻辑层、表示逻辑层彼此分开，而且现在不同的层都已经有一些成熟的开发框架的支持。 2、PHP 是面向过程的语言，Java 是面向对象的，面向过程语言开发的程序只要业务流程发生变化，修改工作量很大，所以可修改性差，同时可复用性也差。 3、PHP 语言在可靠性方面比 J2EE 平台差，J2EE 平台有大量增强可靠性的成熟解决案，而 PHP 只是一种简单的脚本语言，在可靠性方面缺乏成熟解决方案。 4、PHP 对于不同的数据库采用不同的数据库访问接口，而 Java 通过 JDBC 来访问数据库，通过不同的数据库厂商提供的数据库驱动方便地访问数据库，访问数据库的接口比较统一。所以原架构在数据库连接方面修改起来工作量也是很大的。 5、PHP 适合于小型项目，所以本项目中以前采用 PHP 是合适的，但目前大量功能需要增加，PHP 在稳定性方面也达不到要求。 6、PHP 比 Java 的可维护性差。 7、PHP 比 Java 的扩展性差。 8、PHP 比 Java 的安全性差 【问题2】(8分) 请简要说明应用服务器的概念,并重点说明应用服务器如何来保障系统在大负荷和长时间运行下的稳定性以及可扩展性。 答： 应用服务器是指通过各种协议把商业逻辑暴露给客户端的程序。 1、若系统负荷很大,可以部署多台应用服务器,多台应用服务器分担任务,以达到性能要求。 2、应用服务器可以通过灵活地增加服务器完成扩展,所以可扩展性很好。 3、应用服务器可长时间稳定运行。因为当一台应用服务器出现故障时,可以将当前运行的事务转移至正常应用服务器上完成执行,不影响业务正常执行,从而保障高可靠性与稳定性。 【问题3】(10分) J2EE平台采用了多层分布式应用程序模型,实现不同逻辑功能的应用程序被封装到不同的构件中,处于不同层次的构件可被分别部署到不同的机器中。请填写图4-1中(1)~(5)处的空白,完成J2EE的N层体系结构。  Applet Servlet EJB容器 Session Bean Entity Bean
    • SSM框架挖词填空
      • SSM(spring+spring MVC+Mybatis)框架 工作流程图 
    • 2021web 系统架构设计(智能家居)
      • 请用400字以内的文字简要描述基于家庭网关的传统智能家居管理系统和基于云平台的智能家居管理系统在网关管理、数据处理和系统性能等方面的特点,以说明项目组选择李工设计思路的原因。 答： 网关管理:云平台更强,可以实现远程网关管理,可以对不同地点的多种设备进行统一管理,管理能力更强, 数据处理:云平台的海量存储空间、高计算性能和灵活的拓展功能,为基于用户数居的智能预测决策方法提供了更好的支持。而家庭网关将数据的存储及处理交付网关,由于网关硬件性能的限制,可能存在家居设备海量数据存储及智能应用需求得不到有效的支持等问题 系统性能:数据存在云上数据库中,通信效率更高,同时云也有更强的数据处理能力,所以会更高效,家庭网关的独立管理,一旦网关被售出,后期便难以进行系统的升级和拓展。 挖词填空： 
      • TCP 与UDP协议对比
        • 该系统需实现用户终端与服务端的双向可靠通信,请用300字以内的文字从数据传输可靠性的角度对比分析TCP和UDP通信协议的不同,并说明该系统应采用哪种通信协议。 答： 该系统应采用TCP协议,这样才能保障用户终端和服务端之间的双向可靠通信 TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP之所以可靠,是因为建立连接时有3次握手,通信时有回应机制,所以丢了包,能重传以保障通信可靠性。 UDP是一种面向无连接的传输层通信协议,丢了包不会重传,所以不能保障通信可靠性。
    • 医疗数据共享平台
      • 
  • 其他
    • 心跳和探测技术
      • 心跳是一种用于故障检测的手段。分布式系统中,各种异常,如:宕机、磁盘损坏、网络故障等,时有发生,通过心跳可以快速有效的定位集群中的错误结点,并做及时的处理保证集群正常服务 通常探针会不断发送健康检查来检查服务是否健康。当远程节点没有响应时,我们只能猜测数据包在过程中的某个地方丢失了。下一个操作将是重试或等等待一段时间,直到超时
• 论文
  • 考试大纲
    • 系统建模 软件架构设计 系统设计 分布式系统设计 系统可靠性分析与设计 系统安全性和保密性设计
  • 历年考试情况
    • 题目类型 1、软件架构,自从2020年以来,更偏向于去考察具体的架构,而不是之前的宏观上的架构风格、 架构评估等内容。尤其喜欢考察改版后的八大架构,如云原生、微服务、安全架构、企业集成架构等。 2、系统开发,这块也是每年必考,软件工程全生命周期都有可能考察,而且也是更具体,比如 具体的开发方法、开发模型,以及需求分析、设计、测试、运维等全过程 3、系统可靠性、安全性、容错技术等。 4、企业应用集成、企业集成平台等。 5、其他:项目管理、数据库等。    
  • 论文学习计划
    • 前提是完成第一轮复习,也即确保已经完成了下面视频资料的学习 1、所有上午综合知识视频课程的学习; 2、一本通精华知识点的学习; 3、一本通课后习题的练习。 然后,可以开始论文复习,和案例分析一起并行,确保完成以下任务: 1、论文写作专题视频讲解课程的学习; 2、确定好自己要写的项目,并确定论文模板; 3、依据确定的项目和模板,至少手写练习6篇左右的论文。 可以根据时间安排一周一篇,持续到考试,锻炼手感。
  • 注意事项
    •  切记:不要猜题 原则:要复用构件(摘要+项目背景+结尾),不要整篇复用 不要抄范文,不要用网上的项目背景 原则:宁可杜撰项目,也不用网上范文中的项目，可以选择适合自己的范文进行修改,改成自己的论文。 练习时写文章前,提前准备好自己要写的项目,必须是近三年内的中大型商业项目。 练习时写文章前,一定做好功课 原则:理论重于实践 做好准备工作之后,要勇于迈出第一步 原则:万事开头难,迈出第一步,就不难了，第一篇论文不限时间 做好准备工作,练习论文主题时发现有不会的知识点,一定要全部背会。 从系统架构设计师的角度看项目,技术细节要少且精,书本理论要与实际的项目联系起来。 不要全局都列举一二三到123,可以局部段落列举123,论点分开论述,没必要都写编号。 论述要求:不能口语化、文档段落不宜太长。 换个视角看论文 原则:以论文写作技巧视频为依据,对自己的论文进行自评 如何记住论文 答:一定要自己改写,即使参考了别人的范文,也不能直直接copy,自己动手写过的东西才能记住。文 章采用统一的模板和结构,搭建好自己的模板之后不要改动,正文部分按论文题目要求去写,一定要 回应子题目。另外,一定要自己多默写,在两个小时内默写完,直接在电脑打开一个word文档默写即 可。
  • 评分标准
    • 下述情况的论文,需要适当扣5分到10分: 没有写论文摘要、摘要过于简略、或者摘要中没有实质性内容的论文。 字迹比较潦草、其中有不少字难以辨认的论文 确实属于过分自我吹嘘或自我标榜、夸大其词的论文 内容有明显错误漏洞的,按同一类错误每一类扣一次分 内容仅属于大学生或研究生实习性质的项目、并且其实际应用水平相对较低的论文 下述情况,可考虑适当加分(可考虑加5分到10分) 有独特的见解或者有着很深入的体会、相对非常突出的论文 起点很高,确实符合当今信息系统发展的新趋势与新动向向,并能加以应用的论文 内容详实、体会中肯、思路清晰、非常切合实际的很优秀的论文 项目难度很高,或者项目完成的质量优异,或者项目涉及国家重大信息系统工程且作者本 人参加并发挥重要作用、并且能正确按照试题要求论述的论文 下述情况之一的论文,不能给予及格分数: 虚构情节、文章中有较严重的不真实的或者不可信的内容出现的论文 没有项目开发的实际经验、通篇都是浅层次纯理论的论文 所讨论的内容与方法过于陈旧、或者项目的水准非常低下的论文 内容不切题意,或者内容相对很空洞、基本上是泛泛而谈且没有较深入体会的论文 正文与摘要的篇幅过于短小的论文(如正文少于1200字) 文理很不通顺、错别字很多、条理与思路不清晰、字迹过于潦草等情况相对严重的论文
  • 项目选择标准
    • 选择中大型商业项目,一般金额在200W以上,研发周期在十月以上的项目。 推荐项目 政府或大型信息系统项目:各国企、事业单位、军方、医院、银行、股没份公司大企业的ERP OA等;云计算、大数据等各种软件及信息系统。一 不能选项目 小型企业项目:如进销存系统、图书管理系统、单机版系统. 尚未完成的项目:一定要已经完成并上线运行,并最好在三年内 纯建网站项目:如建设企业或政府门户网站,只有静态网页链接介绍,没有后台大型应用 的。 硬件项目:如综合布线、安防、视频会议等。 纯技术项目:如数据升级迁移、内部技术研究等。
  • 考场答题步骤
    • 1、选题（四选一） 2、分析问题,找准核心论点 3、搭建论文框架(列出答题要点和大纲) 4、开始写作。
  • 论文写作四部曲
    • 4选一一定要选自己绝对掌握的领域，因为要扩展2600字，不熟悉的是写不出的
    • 找准核心论点(5分钟)
    • 搭建论文框架(10分钟)
    • 撰写摘要(15分钟)
    • 正文写作(90分钟)
  • 论文框架
    • 
    • 摘要
      • 项目相关背景及主要功能 你的岗位及主要职责 论文主体内容的总概 项目最终的实施效果或你的总结和感悟等 300~~320字 摘要一般要写300字左右,十分重要,是正文的总结和归纳,要能够反映正文的核心内容, 包括项目背景、简单功能介绍、实现技术、方法、工具、措施、手段、全文论点、作者担 任的工作。
      • 模板
        • 参考模板1: 本文讨论......系统的......(论文主题)。该系统......(系统背景、简单功能介绍)。在本文中 首先讨论了......(过程、方法、措施),最后.......(不足之处/如何改进、特色之处)。在本 系统的开发过程中,我担任......(作者的工作角色)。 参考模板2: 根据......需求(项目背景),我所在的....组织了......系统的开发。该系统......(系统背景、简 单功能介绍)。在该系统的开发中,我担任了......(作者I的工作角色)。我通过采取.....(过 程、方法、措施),使该系统开发工作圆满完成,得到了了用户们的一致好评。但现在看 来,.....(不足之处/如何改进、特色之处)。 参考模板3: ...年...月,我参加了.....系统的开发,担任.....(作者的工作角色)。该系统......(系统背景、 简单功能介绍)。本文结合作者的实践,以......系统为例,讨论......(论文主题),包括.... (过程、方法、措施)。
      • 实例
        • 摘要: 本人于2016年1月参与浙江省某市公交集团"公交车联网一体化"项目,该系统为新能 源营运车辆补贴监管、安全监控等方面提供全方位的软件支撑,在该项目组中我担任系统架构师岗位, 主要负责整体架构设计与中间件选型。 本文以该车联网项目为例,主要讨论了软件架构风格在该项目中的具体应用。底层架构风格我们 采用了虚拟机风格中的解释器,因该公交共有几十种不同的数据协议,使用解释器风格可以满足整车 数据协议兼容性需求:中间层关于应用层的数据流转我们采用了独立构件风格中的隐式调用,这种风 格主要用于减低系统间耦合度、简化软件架构,提高可修改性方面的架构属性;应用系统层我们采用 了B/S的架构风格,统一解决公交行业性难题"实施推广难、维护难"问题。最终项目成功上线,获 得用户一致好评。。 注意： 逻辑上是两段式，但实际写时写成一段即可，不然有可能导致后面空格不够写。 第一段是固定的，打磨好后背过即可。 第二段很重要的一部分是它是对正文的总结，需要与正文有对应性。
    • 正文
      • (1)项目背景介绍
        • 项目背景的详细介绍: 项目开发的原因 项目开始时间、实施周期 你的主要岗位职责等 400字左右 项目背景及过渡部分不能超过500字,需要提前准备好,尽量通用化,不要和论文主题相关, 这样考试时候无论什么论文主题都可以直接默写,只需要在最后写一段过渡语句,过渡到 下一个论点。 包括内容:项目开发的原因、你的岗位职责、项目开发周期及规模、项目功能组成介绍。 结构可以定为： 为什么要做这个项目+项目功能和技术介绍+回应子题目并过渡到主体 在航天卫星的研制过程中,一颗航天卫星只有一套配套的硬件设备,无法满足一个开发团队的测 试需求,同时因为航天卫星硬件设备造价十分昂贵,测试人员也无法进行一些非常规的极限测试,以 防止损坏硬件设备,以上种种,将会造成对航天卫星软件的测试不不充分和不彻底,有可能导致卫星研 制失败。为了防止这种情况的发生,针对某重要型号的航天卫星的研制,该航天研究所领导决定使用 技改经费投资建设一套全数字仿真验证平台,以纯软件的方式模拟卫星在太空中运行所需的全部硬件 及外部力学环境,在虚拟平台中运行卫星软件和动力学模型关牛进行详细彻底的测试。
        • 实例
          • 随着国家十三五计划中-能源战略的深入和推广,该市公交集团自2016年1月起全面停止采购燃油机公交车,规划到2020年纯电公交车采购占比必须在70%以上,同时配套将车联网方面的系统建设被列为工作重点。不管从新能源营运车辆补贴监管、安全监控或者公交公司自身的营运和机护需求,都要求有新的车联网系统对他们进行全方位的支持,而我司是该公交的主要仪表与can模块产品的主要供应商,全市4000多台车中有3000多辆是我司的产品,我司不仅掌握熟悉该公交整车数据而且在车联网底层can数据有非常明显的领域知识优势,因此2016年1月我司被该市公交集团委托建设公交集团车联网一体化项目。本项目组全体成员共有27人(不含)业主方),我在项目中为担任系统架构师职务,架构小组共4人,我主要职责负责整体架构设计与中间同件选型,4月份完成架构工作,整个项目共耗时了7个月,2016年8月顺利通过验收。 上面实例只用了一段，且没有描述功能组成，不算一个太好的实例。 注意： 项目背景这块可以写成真正的两段式。 第一段写项目开发的原因、你的岗位职责、项目开发周期及规模 第二段写项目功能组成。比如项目主要由。。。子系统和。。。子系统组成，第一个子系统干嘛的，第二个子系统干嘛的。。
      • (2)相关问题回应
        • 非核心论点问题的回应 引出主体内容(核心论点) 300~400字 这部分要求介绍题目描述的某项技术原理,考察理论知识,需要大家记忆背诵一些高频考点。 300-400字左右,也是无需动脑。
        • 实例
          • 在架构工作开始阶段,我们便意识到,架构风格是一组设计原则,是能够提供抽象框架模式,可 以为我们的项目提供通用解决方案的,这种能够极大提高软件设计的重用的方法加快我们的建设进程, 因此在我司总工程师的建议下,我们使用了虚拟机风格、独立构件风格以及B/S架构风格这三种较常 用风格。虚拟机风格中的解释器架构风格能够提供灵活的解析引擎,这类风格非常适用于复杂流程的处理。独立构件风格包括进程通讯风格与隐式调用风格,我们为了简化架构复杂度采用了隐式调用风格,通过消息订阅和发布控制系统间信息交互,不仅能减低系统耦合度,而且还提高架构的可修改性。B/S架构风格是基于浏览器和服务器的软件架构,它主要使用http协议进行通信和交互,简化客户 端的工作,最终减低了系统推广和维护的难度,以下正文将重点描述架构风格的实施过程和效果。 注意： 不要直接生硬的回应问题，需要先写一段话进行过渡。 结尾也过渡一下。
      • (3)主体内容
        • 采用总分式描述: "一总"加"三分" "一对三"模式 可分4个段落 1000~1500字 论文中最重要的部分,要求结合实际项目实施情况,说明理论如何在实 践中应用,考察真实的项目经验。1200字左右,真正需要写的,大家需要多加练习,掌握 规律。
        • 实例
          • 底层架构我们使用解释器风格来满足整车数据协议兼容性需求。解释器风格是虚拟机风格中的一种,具备良好的灵活性,在本项目中我们的架构设计需要兼容好86种不同can数据协议,一般来说这种软件编写难度非常高,代码维护难度压力也很大,因此这个解释器的设计任务便很明确了,软件设计需要高度抽象、协议的适配由配置文件来承担。具体的做法如下,我们对各个车厂的can数据结构进行了高度抽象,由于can数据由很多数据顿组成,每个数据帧容量固定并且标识和数据有明确规定,因此我们将can协议中的ID和数据进行关系建模,将整体协议标识做为一个根节点,以canid作为根节点下的叶子节点,使用XML的数据结构映射成了有整车协议链-数据帧-数据字节-数据位这4层的数据结构,核心的代码采用jdom.jar与java的反射机制动态生成java对象,搭建一套可以基于可变模板的解释器,协议模板的产生可以由公交公司提供的excel协议文档进行转换得到,解释器支持协议模板热部署,这种可以将透传二进制数据直接映射成java的可序列化对象,将数据协议的复杂度简化,后期数据协议更改不会对软件产生影响,仅仅更改协议模板文件即可,最终我们使用 了86个协议描述文件便兼容了这些复杂的can数据协议,规避了ca数据巨大差异带来的技术风险。 中间层我们使用独立构件风格中的隐式调用来简化构件间的交互复杂度,降低系统耦合度。主要 的实现手段是,我们采用了一个开源的消息中间件作为连接构件,这个构件是apache基金会下的核 心开源项目activemg,它是一款消息服务器,其性能和稳定性久经考验。由上文提到的解释器解析 出对象化数据经过activemg分发到各个订阅此消息的应用系统,这些应用系统包括运营指挥调度、 自动化机护、新能源电池安全监控等,这种多web应用的情况非常适合采用消息发布与消息订阅的机 制,能够有效解决耦合问题,我们在编码的过程中发现只要采用这种风格的web应用,整个迭代过程 效率极高,错误率降低,而且我们使用的spring框架,消息队列的管理完全基于配置,清晰简单, 维护性良好,例如整车安全主题、运营调度主题、机护维修主题等消息队列分类清晰,可以随时修改 其结构也能够随时增其他主题的消息队列,不同的web系统监听的队列也可以随时变换组合,基于消 息中间件的架构设计能够让系统的构件化思路得到良好实施,总体来说这种架构风格带来了非常清晰 的数据流转架构,简化了编码难度,减低本项目的二次开发的难度。 应用系统层我们主要采用B/S的架构风格,主要用于解决公交推广难、维护难得问题。公交行业 有一个明显的特点,公交子公司分布在全市各个地区,路途很远,且都是内网通讯,车联网络也是走 的APN专网,一般是无法远程支持的,这给我们的系统推广以及后期维护带来了很大难题,我们可以 想象如果使用C/S架构,更新客户端一旦遇到问题很可能需要全市各个站点跑一遍。这让我们在系统 推广和维护方面面临较大压力。我们采用的B/S架构风格能够解决这个难题,并充分考量可现在的相 关技术成熟度,例如现在的html5完全能够实现以前客户端的功能项目中我们使用了大量的前端缓 存技术与websocket技术,能够满足公交用户实时性交互等需求。这种风格中页面和逻辑处理存储在 web服务器上,维护和软件升级只要更新服务器端即可,及时生效用户体验较好,例如界面上需要 优化,改一下Javascript脚本或者CSS文件就可以马上看到到效果了。 注意：
      • (4)论文结论
        • 结构上可分三步走: 先分析项目运行效果 再总结项目不足 最后提解决思路 结尾可以写400-600字左右,是对整体论文的总概。 包括内容:项目上线及运行效果、客户评价、项目收获、I项目不足和解决思路 注意：提出不足之处必须要提出解决思路。 经过近15个月的项目开发,该型号航天卫星的全数字仿真整证系统顺利投入使用,协助客户对 卫星软件进行全面的功能和性能上的测试,运行至今客户反馈良好。该系统由于保密性高,性能要求高,技术实现难度高,项目建设周期长等原因,建设过程困难重重。但由于笔者及项目团队成员十分重视项目的......(回应具体论文题目),最终保证了该项目按质按量顺利交付。 当然,在本项目中,还有一些不足之处,比如;.......(自己去想一些小问题,切忌,别出现什么大问题),不过,经过我后期的纠偏,并没有对项目产生什么影响。在后续的学习和工作中,我将不断的充电学习,和同行进行交流,提升自己的专业技术水平,更好的完成系统架构设计的工作。
        • 实例
          • 项目于2016年8月完成验收,这1年内共经历了2次大批量新购公交车辆接入,这几次接入过程平稳顺利,其中协议解释器软件性能没有出现过问题,消息中间件的性能经过多次调优吞吐量也接近了硬盘I0极限,满足当前的消息交互总量,另外由于我们的项目多次紧急状态下能够快速适应can协议变动,得到过业主的邮件表扬。除了业主机房几次突发性的网络故障外,项目至今还未有重大的生产事故,项目组现在留1个开发人员和1个售后在维护,系统的维护量是可控的,系统运行也比较稳定。不足之处有两个方面,第一在架构设计的过程中我们忽略PC配置,个别PC因为需要兼容老的应用软件不允许系统升级,这些电脑系统老旧,其浏览器不支持html5,导致了系统推广障碍。第二在系统容灾方面还有待改善。针对第一种问题,我们通过技术研讨会说服可业主新购PC,采用两台机器同时使用方式解决。针对第二种问题我方采用了服务器冗余和心跳监测等策略,在一台服务暂停的情况下,另外一台服务接管,以增加可用性。 注意： 第一段总结下项目总体的结果是好的 第二段写下项目的不足和收获，1~2个不足的方面，无关轻重的问题点。 对于结尾部分，对不同的论题来说都是固定的，打磨好背过即可。
    • 实例分析
      • 论软件系统架构风格
        • 论软件系统架构风格 系统架构风格(SystemArchitecture Style)是描述某一特定应用领域中系统组织方式的惯用 模式.架构风格定义了一个词汇表和一组约束,词汇表中包含一些构件和连接件类型,而这 组约束指出系统是如何将这些构件和连接件组合起来的软件系统架构风格反映了领域中 众多软件系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一 个完整的系统。软件系统架构风格的共有部分可以使得不同系统共享同一个实现代码,系 统能够按照常用的、规范化的方式来组织,便于不同设计者很容易地理解系统架构。 请以"软件系统架构风格"论题,依次从以下三个方面送进行论述 1.概要叙述你参与分析和开发的软件系统开发项目以及你所担任的主要工作。 2.分析软件系统开发中常用的软件系统架构风格有哪些?详维细阐述每种风格的具体含义。 3.详细说明在你所参与的软件系统开发项目中,采用了哪种软件系统架构风格,具体实施 效果如何。
        • 找出三问核心论点
          • 问题1要点： 软件系统的概要:系统的背景、发起单位、目的、开发周期、交付的产品等。 "我"的角色和担任的主要工作。 问题2要点： ·常用的软件系统架构风格。 ·每种风格的具体含义。 问题3要点： ·采用的哪种软件系统架构风格。 ·具体实施效果如何。
        • 搭建论文框架
          • 
        • 理论素材准备
          • 架构设计的一个核心问题是能否达到架构级的软件复用 架构风格反映了领域中众多系统所共有的结构和语义特性生,并指导如何将各个构件有效地 组织成一个完整的系统 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则 数据流风格:批处理序列、管道-过滤器 调用/返回风格:主程序/子程序、面向对象、层次结构 独立构件风格:进程通信、事件驱动系统(隐式调用) 虚拟机风格:解释器、基于规则的系统 仓库风格:数据库系统、超文本系统、黑板系统
  • 精华主题范文
    • 论软件系统架构风格
    • 论面向服务架构设计及其应用
      • 企业应用集成(Enterpise Application Integration,EAI)是每个企业部必须要面对的实际问题。 面向服务的企业应用集成是一种基于面向服务体系结构(Service-Oriented Architecture, SOA) 的新型企业应用集成技术,强调将企业和组织内部的资源原和业务功能暴露为服务,实现资 源共享和系统之间的互操作性,并支持快速地将新的应用以服务的形式加入到已有的集成 环境中,增强企业IT环境的灵活性。 请围绕"SOA在企业集成架构设计中的应用"论题,依次从以下下3个方面进行论述。 1、概要叙述你参与管理和实施的企业应用集成项目及你在其中所担任的主要工作。 2、具体论述SOA架构的内容、特点,以及你熟悉的工具和环境对SOA的支持,在应用中重 点解决了哪些问题。 3、通过你的切身实践详细论述SOA在企业应用集成中发挥的作用和优势。
      • 找出三问核心论点
        • 找准核心论点 问题l要点: 软件系统的概要:系统的背景、发起单位、目的、开发周期、交付的产品等。 "我"的角色和担任的主要工作。 问题2要点: SOA架构的内容、特点,以及你熟悉的工具和环境对SOA的支支持 在应用中重点解决了哪些问题。 问题3要点: SOA在企业应用集成中发挥的作用和优势。
      • 搭建论文框架
        • 
      • 理论素材准备
        • SOA是一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通信,不涉及 底层编程接口和通信模型。 在SOA中,服务是一种为了满足某项业务需求的操作、规则等等的逻辑组合,它包含一系列有 序活动的交互,为实现用户目标提供支持。 SOA并不仅仅是一种开发方法,还具有管理上的优点,管理员可直接管理开发人员所构建的 相同服务。多个服务通过企业服务总线提出服务请求,由由应用管理来进行处理,如下:  实施SOA的关键目标是实现企业IT资产重用的最大化,在实施SOA过程中要牢记以下特征:可 从企业外部访问、随时可用(服务请求能被及时响应)、粗粒)度接口(粗粒度提供一项特定的业务功 能,而细粒度服务代表了技术构件方法)、服务分级、松散女耦合(服务提供者和服务使用者分离)、可重用的服务及服务接口设计管理、标准化的接口(WSDL、SOAP、)XML是核心)、支持各种消息模式、精确定义的服务接口。 从基于对象到基于构件再到基于服务,架构越来越松散耦合,粒度越来越粗,接口越来越标准。 基于服务的构件与传统构件的区别有四点: 服务构件粗粒度,传统构件细粒度居多; 服务构件的接口时标准的,主要是WSDL接口,而传统构件常常以具体API形式出现; 服务构件的实现与语言是无关的,而传统构件常绑定某种特定定的语言; 服务构件可以通过构件容器提供QoS的服务,而传统构牛完全由程序代码直接控制。 SOA的实现方式 WEB Service 服务提供者、服务注册中心(中介,提供交易平台,可有可无)、服务请求者。服务提供 者将服务描述发布到服务注册中心,供服务请求者查找,查找到后,服务请求者将绑定查 找结果。如下图: 
      • 合格范文
        • 摘要: 2016年8月,我参与了胶凝砂砾石坝施工质量监控系统的开发工作,该系统旨在帮助水利工程建设法人单位、施工企业、监理机构及相关政府部门解决水利工程建设施工质量监控和工程项目管理等问题。我在该项目中担任系统分析师,主要负责该系统的系统分析及设计工作。本文以胶凝砂砾石坝施工质量监控系统为例,主要论述了SOA在企业集成架构设计中的具体应用。服务提供者主要完成服务的设计、描述、定义和发布等相关工作;服务注册中心保证该系统各个模块、服务的相互独立性与松耦合;服务请求者通过Webservice技术调用服务。实践证明,通过以上技术的应用有效实现了资源共享和系统间的互操作性,提高了系统的灵活性,最终系统顺利上线,获得用户一致好评。 项目背景部分： 胶凝砂砾石坝是在面板坝和碾压混凝土重力坝基础上发展起来的一种中新坝型,其特点是采用胶凝砂砾石材料筑坝,使用高效率的土石方运输机械和压实机械施工。与常规坝型相比,胶凝砂砾石坝在适用性和经济性方面具有独特的优势,可以就地、就近取材,不需设置集料筛分,施工进度快,施工工序简单高效,因而要求施工过程紧凑,高峰期筑坝效率要求高,这给施工质量控制带来了一定的困难和风险,需要综合考虑影响施工质量的各方面因素,尽量采用自动化监控手段,加强实时质量监控力度,这使胶凝砂砾石坝施工质量监盐控系统应运而生。 2016年8月,我参与了胶凝砂砾石坝施工质量监控系统的开发工作,,担任该系统的系统分析师,主要负责该系统的系统分析及设计工作。该系统的主要功能模块包括采料监控、运精监控、拌合监控、碾压监控和温湿度监控等。旨在帮助水利工程建设法人单位、施工企业、监理机构及相关政府部门,解决水利工程建设施工质量监控和工程项目管理等问题,通过信息技术和施工信息现场采集、实时传输、统一存储、科学分析和在线处理,及时生成质量监控报表和发布质量预警信息,提高水利工程建设管理和科学化、、现代化和信息化,落实法人负责、监理控制、施工保证、政府监督等各项职能。因此,要满足该系统的需求,选择一种合适的架构技术至关重要。 正文部分： SOA是一种应用程序架构,在这种架构中,所有功能都定义为独立的服务,服务之间通过交互和协调完成业务的整体逻辑。SOA指定了一组实体,包括服务提供者、服务消费者、服务注册表、服务条款、服务代理和服务契约,这些实体详细说明了如何提供和消费服务。服务提供者提供符合契约的服务,并将他们发布到服务代理。这些服务是自我包含的、无状态的实体,可以由多个组件组成。服务代理者作为存储库、目录库或票据交换所,产生由服务提供者发布的事先定义的标准化接口,使得服务可以提供给在任何异构平台和和任何用户接口使用。这种松散耦合和跨技术实现,使各服务在交互过程中无需考虑双方的内部实现细节、实现技术、以及部署在什么平台上,服务消费者只需要提出服务请求,就可以发现并调用其他的软件服务得到答案。SOA作为一种粗粒度、松耦合的架构,具有松散耦合、粗粒度服务、标准化的接口、位置和传输协议透明、服务的封装和重用服务的互操作等几个特点。 该系统要求开发周期短,系统灵活性高等,结合SOA的特点,我们终采用了面向服务的、基于SOA的企业应用集成。下面具体论述其应用过程。 1、服务提供者 服务提供者主要完成服务的设计、描述、定义和发布等相关工作。经过对水利行业施工工程及施工工艺的深入研究,通过查阅《胶凝砂砾石坝施工指南》等相关资料,根据企业应用集成的要求,对胶凝砂砾石坝施工质量监控系统的业务流程进行梳理;综合考虑服务粗粒度、松耦合、自包含和模块化等特点进行服务的设计。为了避免服务通信期间,信息量过大,服务之间交互过于频繁,尽量的减少了服务的数量。同时,为了保证服务自身功能的完整性,尽可能的减少服务与系统之间的通信,在胶凝砂砾石坝施工质量监控系统的分析与开发过程中,先行设计,提取出了两个必要,急需的服务便于日后集成使用,其中包括拌合监控中标准拌合比对比服务和碾压监控中的碾压轨迹生成服务。 。。。 2、服务注册中心和服务请求者 在胶凝砂砾石坝施工质量监控系统采用了服务注册中心。服务注册中心不是一个必选角色,但是为了保证该系统各个模块、服务的相互独立性与松耦合,在该系统中依然保留了服务注册中心。同时,服务注册中心的存在也使得服务请求者与服务提供者之间进一步解耦。在服务注册中心包含有已发布的标准拌合比对比服务与碾压监控中的碾压轨迹生成服务的描述信息,其描述信息主要包括服务功能描述、参数描述、接口定义、信息传递等相关信息。 服务请求者通过WebService技术调用服务。当服务完成发布,在服务请求者要使用已发布的服 务。利用Web Service技术在拌合监控阶段,通过服务注册中心获取拌合监控中标准拌合比对比服务的相关功能,接口,参数及其返回值等相关服务信息;之后使用Web Service技术传递服务所需的标准拌合比等相关参数,进而调用该服务相关的运算、处理和分析。利用WebService技术在拌合监控阶段,通过服务注册中心获取实时施工数据采集处理服务的服务定义和功能,接口,参数及其返回值等相关服务信息;之后根据施工工地的具体情况选择不同的定位方式,传递服务所需相关参数,最后实时施工数据采集处理服务运行结束返回的绘制碾压轨迹坐标点同样是利用Web Service技术传递至 论文结论： 整个项目历时10个月开发,于2017年6月完成交付,到目前运行稳定。通过在水利施工工地等恶略环境下的一段时间的使用,用户普遍反馈良好。总体来讲,选用SOA有如下优势:1、系统更易维护。当需求发生变化时,不需要修改提供业务服务接口,只只需要调整业务服务流程或者修改操作即可。2、更高的可用性。该特点是在于服务提供者和服务请求老的松散耦合关系上得以发挥与体现。这种没有绑定在特定实现上、具有中立的接口定义的特征称为服务之间的松耦合。松耦合有两个明显的优势,一是它的灵活性,其独立于实现服务的硬件平台、接候作系统和编程语言;二是当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,它能够继续存在。3、更好的伸缩性,依靠业务服务设计、开发和部署等所采用的架构模型实现伸缩性。使得服务提供者可以互相彼此独立地进行调整,以满足新的服务需求。 实践证明,SOA技术的使用大大提高了系统开发效率,节省了开发和维护成本,使得系统具有更好的开放性、易扩展性和可维护性,从项目完工后的使用效果来看,达到了预期目的。
  • 押题
    • AI? 八种架构？ 鸿蒙？
    • 5月押题
      • 1.层次式架构、大数据架构 2.软件设计的过程.可能涉及到面向对象的设计(如设计原则和设计模式)、软件设计四个过程(架构设计、接口设计、过程设计、数据设计)、业务流程设计等。 3.关于架构集成的内容,可能涉及的有企业的应用集成、企业集成平台、企业集成架构等 4.系统架构风格 5.可靠性设计 6.面向服务的架构设计 八大架构中，云原生架构，面向服务架构，安全架构，大数据架构是近几年考过的，今年再考概率变小。 通信系统架构和嵌入式架构不太可能考。
    • 11月押题
      • 在2024年05月,文老师成功预测中了大数据架构,精准命中lambda架构,这也说明,架构论文的侧重 点确实会倾向于改版后的八大架构了。 让我们来看看第二版下篇内容,分别是:信息系统架构、层次式架构、云原生架构、面向服务架构、 嵌入式系统架构、通信系统架构、安全架构、大数据架构。 一共八章,结合架构本身科目特性以及历年真题考察情况,文老师预测2024年11月论文考试,很有可 能考到的具体架构是:层次式架构、云原生架构。
    • 层次式架构***
      • 论题 论软件多层架构的设计 论题介绍 目前,三层架构或多层架构已经成为软件开发的主流,采用多层架架构有很多好处,例如,能有效降低建设和维护成本,简化管理,适应大规模和复杂的应用需求,可适应不断的变化和新的业务需求等。在多层架构的开发中,中间件的设计占重要地位。 请围绕"软件多层架构的设计"论题,依次对以下三个方面进行论述" 概要叙述你参与设计和开发的软件项目，以及你所担任的主要工作。 具体讨论你是如何设计多层架构的，详细描述其设计过程，遇到过的问题，以及解决的办法。 分析你采用多层架构所带来的效果如何，以及有哪些还需要进一步改进的地方，如何进行改进？ 问题1要点： 软件系统的概要：系统的背景、发起单位、目的、开发周期、交付的产品等。 “我”的角色和担任的主要工作。 问题2要点： 如何设计多层架构的，详细描述其设计过程，遇到过的问题，以及解决的办法 问题3要点： 采用多层架构所带来的效果如何 有哪些还需要进一步改进的地方 如何进行改进
      • 参考范文
        • 范文1
        • 范文2
      • 模拟题
    • 云原生架构***
      • 云原生在工作中如果没有用到是很难编的，这个要考虑是是否选，选的化如何准备范文 云原生和微服务可以只准备一篇范文 都按服务化去划分 但是写的时候要有侧重，比如在摘要里体现云原生的归纳总结，子题目2里要回答云原生的一些特点 在正文里要强调是因为云原生的服务化规则才划分为这些微服务
      • 知识点
        • 1.云原生架构原则（根据下面原则来构建一些实例来写） 服务化原则:拆分为微服务架构、小服务架构,分别迭代。 弹性原则:系统的部署规模可以随着业务量的变化而自动伸缩,无须林根据事先的容量规划准备固定的 硬件和软件资源。 可观测原则:通过日志、链路跟踪和度量等手段,使得一次点击背后的多次服务调用的耗时、返回值 和参数都清晰可见。 韧性原则:当软件所依赖的软硬件组件出现各种异常时,软件表现出来的抵御能力。 所有过程自动化原则:一方面标准化企业内部的软件交付过程,另一方面在标准化的基础上进行自动 化,通过配置数据自描述和面向终态的交付过程,让自动化工具理解交付目标和环境差异,实现整个 软件交付和运维的自动化。 零信任原则:默认情况下不应该信任网络内部和外部的任何人/设备/系统,需要基于认证和授权重构 访问控制的信任基础,以身份为中心。 架构持续演进原则:云原生架构本身也必须是一个具备持续演进能力的架构 2. 主要架构模式 1.服务化架构模式:典型模式是微服务和小服务模式。通过服务化架构,把代码模块关系和部署关系 进行分离,每个接口可以部署不同数量的实例,单独扩缩容,从人而使得整体的部署更经济。 2.Mesh化架构模式:把中间件框架(如RPC、缓存、异步消息等)从业务进程中分离,让中间件SDK与业 务代码进一步解耦,从而使得中间件升级对业务进程没有影响,甚至迁移到另外一个平台的中间件也 对业务透明。分离后在业务进程中只保留很"薄"的Client部分,Client通常很少变化,只负责与Mesh 进程通信,原来需要在SDK中处理的流量控制、安全等逻辑由Mesh进程完成。 3.Serverless模式:将"部署"这个动作从运维中"收走",使开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等,从架构抽象上看,当业务流量到来/业务事件发生时,云会启动或调度一个已启动的业务进程进行处理,处理完成后云自动会关闭/调度业务进程,等待了一次触发,也就是把应用的整个运行都委托给云。 4.存储计算分离模式:。在云环境中,推荐把各类暂态数据(如session)、结构化和非结构化持久数据都采用云服务来保存,从而实现存储计算分离。 5.分布式事务模式:大颗粒度的业务需要访问多个微服务,必然带来分布式事务问题,否则数据就会 出现不一致。架构师需要根据不同的场景选择合适的分布式事务务模式 6.可观测架构:可观测架构包括Logging、Tracing、Metrics三个方面,其中Logging提供多个级别的详细信息跟踪,由应用开发者主动提供;Tracing提供一个请求从前端到后端的完整调用链路跟踪,对于分布式场景尤其有用;Metrics则提供对系统量化的多维度度量。 7.事件驱动架构:本质上是一种应用/组件间的集成架构模式。可用于服务解耦、增强服务韧性、数据变化通知等场景中。
      • 范文
        • 云原生架构范文 2019年3月,我单位联合某高校研发了《程序在线评测比赛考试系统》。系统以程序代码在线提 交自动评测功能为核心,分为题库模块、评测机模块、实验作业模块、考试模块、比赛模块、抄袭判 定模块、用户管理模块等,支持对接教务平台。在项目中我担任系统架构师,负责架构设计工作。 本文以该系统为例,主要论述了云原生架构在项目中的具体应用。系统以SpringCloud微服务 框架开发,分为前端Web服务、平台保障服务、业务服务三部分。前端Web服务由负载均衡与服务器 集群结合,实现高并发的前台界面;平台保障服务以Eureka为中心,由API网关、服务注册中心、 监控平台等构成,实现基础服务框架;业务服务划分为多个个微服务,基于Docker容器,协同工作实 现具体业务功能。最终系统顺利上线,获得用户一致好评。 笔者在一个专为高校建设计算机专业智能教学一体化平台的的单位任职,过往成果有《计算机组成 原理仿真实验系统》等。2019年3月,我单位联合某大学研发了《程序在线评测比赛考试系统》项 目(以下简称为"0J系统"),以取代原有传统的编程上机考试平台。 系统以程序代码的在线提交自动评测功能为核心,主要分为题库模块、评测机模块、实验作业模 块、考试模块、比赛模块、抄袭判定模块、用户管理模块等。题库模块主要负责试题和测试用例的管理,用户根据试题要求编写程序代码提交到系统,系统将测试用例与程序代码发送给评测机模块,由 评测机自动编译、执行、判分,并将结果发送给其他相关模块进行统计:实验作业模块用于在线布置 作业,从题库中选取试题,设置截止日期等要求;考试模块用于学生在线考试,按教师预先设置的参 数自动从题库随机抽题生成试卷,以及向教务平台上传考试成绩:比赛模块主要用于ACM竞赛的培训: 抄袭判定模块用于鉴定代码与他人代码雷同率;用户管理模块负责用户信息的管理。在这个项目中, 我担任了系统架构师的职务,主要负责系统的架构设计相关工作。 。。
      • 写作要点
    • 微服务架构***
      • 可以从系统划分为哪几个子系统，子系统划分那几个微服务的，功能是什么 这个角度来写一段 之后再基于微服务的特点来写（分布式），结合项目说下分布式如何进行服务的调用和管理的。 比如我们调用了哪些微服务，这些不同的微服务分别位于不同的进程或计算机上，通过远程调用的方式来调用。调用不同的微服务一起协同完成一个业务功能。 也可以围绕去中心化角度 第二问可能考微服务的原则，优缺点，特点等 例（服务原则）： 微服务架构体系作为目前IT领域主流的技术,有服务化、强韧性、可观测性和自动化四类设计原则。 通过服务化的设计原则,应用被分解为多个服务,可分别选择不同的技术,单个服务模块很容易开发、理解和维护,无需协调其他服务对本服务的影响:通过强韧性的设计原则,微服务可以分布式云化部署,负载均衡管理请求的分发,避免单机失败对整体服务的影响,以及弹性调整资源容量: 通过可观测性的设计原则,能够对系统进行健康检查、指标监控、日志管理和链路追踪,提高系统运维、管理和排错能力:通过自动化的设计原则,可实现系统的自动化部署、自动化扩展伸缩、自动化运维、持续交付和集成,有效减少人工操作的工作量。
      • 21年考题
        • 微服务架构(Microservices Architecture)是一种架构区格,它将一个复杂的应用拆分成多个独立自治的服务,服务与服务间通过松耦合的形式交互,在微服务架构中,服务是细粒度的,协议是轻量级的。这些服务通常按业务能力组织,有自身的技术维栈。 请围绕"微服务架构及其应用"论题,依次从以下三个方正面进行论述。 1.概要叙述你参与管理和开发的、采用微服务架构的软件项目以及你在其中所承担的主要工作。 2.请简要描述微服务架构的优点。 3.具体阐述你参与管理和开发的项目是如何基于微服务架构进行件设计实现的。
      • SpringCloud
      • SOA
        • SOA架构也可能考，也需要了解相关知识点 可以从服务划分及ESB作用的角度去写。 面向服务的架构，子题目2一般考SOA架构对技术和定义的描述，UDDI, SOAP, WSDL之类。 题目： 请围绕“论面向服务架构设计及其应用”论题，依次从以下三个方面进行论述。 概要叙述你参与分析和开发的软件系统开发项目以及你所担任的主要工作。 说明面向服务架构的主要技术和标准，详细阐述每种技术和标准的具体内容。 详细说明你所参与的软件系统开发项目中，构建SOA架构时遇到了哪些问题，具体实施效果如何。
      • 正文写作思路SOA&微服务
        • 1. 如下这种写法最好写，但是不一定得好的分数，因为太简单 （适用于SOA和微服务） 服务提供者：如何利用需求合并得到服务，需求提炼的过程 服务注册中心：将服务注册到服务注册中心，列举出一个具体的服务，对其进行描述：服务的名字，服务提供的功能 描述信息主要包括：服务功能、参数描述、接口定义、信息传递等相关信息。 服务请求者：服务消费者最后写，描述它根据什么需求在服务注册中心中申请到什么服务，如何利用这个服务完成本身的业务流程和本身的需求 微服务也可以按照这种结构去写，只不过提炼出的是各种微服务，微服务要写多个，体现出细粒度 2.第2种写法，从服务的角度（不适用于微服务） 服务的划分和ESB的作用的角度来写 第一段描述下对功能的提炼，形成了哪些服务 ESB角度描述服务之间交互的实例，比如它具有服务查找和发现的功能。写一个服务查找发现和调用的流程。 ESB本身的协议转换的功能。某两个服务的调用过程中发现它们的数据接口有差异，如何通过ESB总线去解决这个差异的。 3.从微服务本身的特点来写 第一段还是写系统划分成哪些子系统的，子系统是划分为哪些微服务的。 后面基于微服务本身的特点来写，选三个特点。 比如微服务具有分布式的特点，描述一下分布式的调用里面是如何进行微服务的调用和管理的，也是先去描述一个当前的业务场流程（功能的执行流程），基于这个业务流程我们调用了哪些微服务。这些微服务分别位于不同的进程或不同的计算机中，通过远程的调用方式来调用的。然后描述调用地理位置不同的微服务协同完成一个业务功能 还可以写去中心化特点，描述微服务之间如何进行通信，通信方式，异步通信，消息队列
      • 知识点
        • 微服务好处及优点
          • 微服务好处: 高异构性,高性能,高弹性,高扩展,易部署,可组合性,可替代性 微服务优点: 通过应用"分而治之"的原则,持续交付和部署大型,复杂的应用程序 通过更易于理解,开发和测试系统来提高模块化 通过每个微服务具有较小的代码库来降低复杂性 允许更新功能,而对系统的其余部分没有影响或影响极小 使架构变得高度可扩展 大大减少了破坏系统无关部分的机会 可以独立交付和部署服务,而不必等待整个系统发布 允许部署到多个云和本地基础设施环境 在持续发展现有系统的同时持续融入和利用最新的技术 使同一时间在同一系统上工作的一组开发人员间的协作更可打控 允许新的团队成员更快地提高生产力,他们可以开发新功能而不必学习整个系统 基于微服务的系统设计实现:
        • 设计原则
          • 围绕业务概念建模 实现自动化 隐藏内部实现细节 一切去中心化 独立部署 隔离失败 高度可观察
        • 设计实现
          •   微服务RESTful API: 业务服务及通用服务 服务网关APIGateway: 客户端到微服务通信 服务注册ServiceRegistry: 微服务注册,发现中心 事件总线EventBus:微服务到微服务通信 安全保护AuthProvider:认证授权提供服务
      • 50分范文
        • 摘要 2020年6月,我单位联合xxxxxx有限公司开发了省xxxx综合应用管理平台,作为公司核心技术骨干,我担任了系统架构师的职务,主要负责xxxx应用系统架构体系设计及核心组件的开发工作。该系统按照省机关业务类型划分,依次包含基础功能支撑板块、平台资源管理板块、煤炭能源板块、油气板块、新能源能源板块、电力板块、安全监管板块、经济运行板块、智能数据分析业务以及数据可视化板块,业务范围依次涵盖省煤炭、电力、油气、新能源等能源领域。 本文首先介绍构建xxxx应用系统的项目背景,然后分析了微服务技术架构对于该项目的必要性,并以能源云应用系统作为例,结合微服务架构的特性与实际清况,分别讨论了微服务技术架构的应用情况,实践证明,在大型的应用系统构建过程中,他用微服务技术架构,能够实现各应用分区自治、庞大业务的有效管理及业务功能灵活拓展的优势。 背景 xxx综合应用管理平台,是机关响应国家"十四五"规划所采!取的数字信息化措施的开创性项目旨在深化运用国家以及省市政务信息资源,加强政务信息共享,实现数据编目、数据整合、能源应用服务,规范政务信息资源社会化增值开发利用工作,合理规划政务信自息的采集(煤炭、油气、新能源、电力等领域),加强政务信息资源管理。项目的总体目标为:理清能源数据家底,形成能源数据资源目录:实现省能源数据的统一综合管控:基于能源大数据,了支撑能源全产业的决策与分析:通过省级数据共享与开放平台向兄弟单位共享能源数据、向社会企业与公众开放脱敏数据。 在项目早期,我们组织了相关承建企业及核心用户,一起进行了项目雷求的评审,拟在确定项目的研发计划、细化项目需求,从而进一步确定采取的系统软件牛架构。项目整体涉及了能源领域的众多业务,体系繁荣且比较庞大,部分业务有着相似的数据支撑组件而你分业务之间又不存在过多的信息交互,基于此,我提出了项目整体采取微服务架构体系构建的方案,并陈述了按照业务板块划分、基础业务拆分方式规划微服务的必要性。在专家评审过程中,通过以往采用微服务架构体系规划项目的经验,最终确定了该系统架构设计方案。 正文（回应子题目2） 微服务架构体系作为目前IT领域主流的技术,有服务化、强韧性、可观测性和自动化四类设计 原则。通过服务化的设计原则,应用被分解为多个服务,可分别选择不同的技术,单个服务模块很容 易开发、理解和维护,无需协调其他服务对本服务的影响;通过强例性的设计原则,微服务可以分布 式云化部署,负载均衡管理请求的分发,避免单机失败对整体服务的影响,以及弹性调整资源容量: 通过可观测性的设计原则,能够对系统进行健康检查、指标监控、日志管理和链路追踪,提高系统运 维、管理和排错能力:通过自动化的设计原则,可实现系统的自动化部署、自动化扩展伸缩、自动化 运维、持续交付和集成,有效减少人工操作的工作量。 正文（一总三分）这里是典型的按照微服务的特点来写的。 系统开发过程中,主要采取SpringCloudAlibaba技术架构作为微服报务架构的实现方案,系统采取jenkins+docker一体化部署方式实现微服务的部署,前端采用Vue3.0开发架构,通过nginx实现HTTP请求的动态负载及业务服务的调用层次抽象管理。采用该体系具备众多优势,下面就其特点、开发过程及系统上线后的实际情况进行结合,从而说明本项目采取出比方案的好处、遇到的问题及其解决方案。 1、以微服务独立部署,实现各应用的独自管理,却又可以简便的进行交互。 每个服务都是一个独立的项目,可以独立部署,不依赖于其他服务,橘合性低,在系统构建过程中,我结合项目整体需求将应用系统拆分为了众多微服务,按照业务领域、使用用户类型对象进行划分,包含以提供基础数据支撑的平台服务,主要提供用户管理、能源企业管理、企业部门管理及业务数据字典管理等服务:以提供能源领域服务的四大板块服务,包括煤炭、油气、新能源、电力:以提供综合数据应用管理的上层众多汇总型服务。按照这种方式划分,由三个承建企业依次划分职责,同步开发,大大的提高了项目整体完成的效率。若服务之间需要进行通信,只需基于微服务体系的消息交互标准,以Rest标准化接口通过FeignAPI组件实现远程服务调用,通过nacos构建的统一网关,实现方便快捷的交互。 2、服务的快速启动（问题点，2,3点写的内容太少了） 合理拆分之后服务由于依赖的库及代码量的减少,能够极大的提高服务的启动速度。虽然合理拆分能够提高系统启动速度,但也增加了系统服务的数量。基于此我通过采取构建统一的打包平台方案,选取了jenkinstdocker镜像结合的解决方案,通过docker将每一个微服务打包为至少一个能独立运行的容器,并通过docker-compose描述这些镜像服务的关系,使用ienkins进行脚本的统一集成,所有服务均以可视化方式展现在jenkins平台,很好的解决了服务数量增多之后的管理问题。 3、职责专一,由专门的承建企业负责专门的工作职能 本项目涉及领域众多、周期长,服务的拆分有利于团队之间的分工。在项目开发计划中,我们将服务划分过后,由不同的企业负责不同的服务,例如我司承建园大能源领域板块的构建等,在项目开发过程中,除了特殊的业务流程需要服务之间进行信息交互外大部分情况下均无需在意其他团队的开发进度。 4、服务可以动态按需扩容 （即弹性化，云原生中通用） 当某个服务的访问量较大时,我们只需要简单的增加服务的申请资源或者增加服务实例数量,即可0成本的实现服务扩容。在应用部署的早期,我们将所有的服务实例均部署为3个,通过nginx实现一级均衡的同时,也采取了微服务的Ribbon负载体系,例如对于煤炭服务的访问,可动态负载到该3个不同的煤炭服务实例,该3个部署实例位于不同的服务器上,动态负载的同时也保障了服务不会出现单点故障问题。但随着系统用户(各省市机关、各企业用户)的加入及业务数据日益累计,整个系统出现了一定的性能问题。经过排查分析,发现煤炭企业用户会在每天下午2点左右集中上报生产数据,导致同一时刻大量的报表填报请求,导致出现了性能瓶颈,需要进行扩容,通过修改jenkins配置文件,增加打包镜像数量将原有的3个报表服务实例扩容一倍解决了问题。 5、服务的复用 每个服务都提供RESTAPI,所有的基础服务都按照尽可能高的内聚度进行抽取。类似于组件开发方法,可将一些底层的服务进行归纳总结,方便应用到以后的项目中,提高企业的生产效率。在本项目中,众多基础服务大部分均复用可以往团队开发的组件。譬如报表动态生成服务,该服务是以往能源产业几乎一致的需求服务,可通过该服务动态配置填报表对象、填报周期、时间截止等。 经过我和团队的不懈努力,历时一年,项目终于于王XXXX年XX 年 XX月通过顺利通过了验收,并得到了一致好评,运行至今,用户反馈良好,通过此类较大应用的开发使得公司的应用规划能力得以提升。但是,在实施过程中,也暴露了一些具体问题,例如微服务之间接口交互时,由于业务复杂,简单的消息调用无法满足繁忙场景,当交互频率增大到一个数量级时需要建立具有动态优先级调整机制的处理队列等等,这些问题通过引入消息队列组件Kafka得以妥善解决,没有影响到项目的运行情况。 我们自己写特点时还可以写自动化部署。
      • 前台，中台，后台
        •  后台是指传统企业在做数字化转型前，特别是“互联网+”之前，企业通过信息化建设积累下来的一些基础的信息系统，如管进销存的ERP、管客户的CRM、管供应商的SRM等，是企业运营依赖的重要应用，受制于技术能力和系统稳定性，这时前端的新业务需求一般不会得到系统及时响应与支撑。 前台则是互联网大潮来临之际，传统企业纷纷转型，开始做前端触达用户和客户的应用，如微信生态的应用、官网商城、电商应用、在第三方电商平台开店等，这时会出现系统建设如何快速响应业务需求、系统重复建设、系统数据割裂、与后台系统拉通成本高等一系列问题。困境之下，如何应对？
      • 微服务与中台
        • 从微服务到中台 说到微服务，就不得不提中台这个概念。 中台可以理解为企业级的能力共享平台，它把一些通用的业务能力沉淀下来，供各个业务线复用，避免重复造轮子。这样可以大大提高开发效率，降低成本。 还是以 58 同城为例。 1.技术中台：58 同城内部有公司层面的技术中台，负责通用技术能力的建设，例如运维、存储、中间件、云平台、搜索、数据平台、AI 平台、移动组件、即时通讯、安全、商业等。 2.业务中台：公司内部还会建设业务中台，比如在房产业务线，有：房源库、楼盘字典、房产开放平台、经纪人服务等，都是统一建设，新房、二手房、租房、商业地产等业务线可直接复用。 当然，中台是一个更具包容性的概念，微服务并非中台的全部，它整合多种能力与资源。除微服务外，还包括数据治理、业务流程优化等多个方面。
    • 系统测试**
      • 2024年05月架构考到了单元测试,有可能意味着测试被纳入了考量,而且测试本身在系分里是个重要 的考点,不知道架构是不是也会重视这个,因此2024年11月的论文,文老师大胆预测考到测试相关内 容,那测试里可考的东西较多,系统测试、静态测试、动态测试等,都要知晓知识点。 11月有较大概率考系统测试 论软件的系统测试及其应用 软件测试是软件交付客户前必须要完成的重要步骤之一,目前仍是发现软件错误(缺陷)的主要手段。 系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起,针对整个系统进行 的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不符或与之矛盾的地方,从而 提出更加完善的方案。系统测试的主要内容包括功能性测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等。 请围绕"软件的系统测试及其应用"论题,依次从以下三个方面进行论述。 1.概要叙述你参与管理和开发的软件项目以及你在其中所担任任的主要工作。 2.详细论述软件的系统测试的主要活动及其所包含的主要内容容,并说明功能性测试和性能测试的主要的目的。 3.结合你具体参与管理和开发的实际项目,概要叙述如何采用软件的系统测试方法进行系统测试,说 明具体实施过程以及应用效果。
    • 软件设计**
      • 在2023年架构论文考试里文老师预测中了面向对象分析,而在之前的论文考试里,软件维护等也都考 察过,虽然在2024年05月没考到生命周期阶段,但意味着在2024年11月的论文里有更大概率考到,文 老师觉得可能会考到的是软件设计这个过程,可能涉及到面向对象的设计(如设计原则和设计模式)、 软件设计四个过程(架构设计、接口设计、过程设计、数据设计)、业务流程设计等 目前也没有软件设计的范文,提供一个性能设计的范文供参考。,包含了业务流程优化,具体直播我会 讲解其他设计如何写。 注意：不要把面向对象的设计和面向对象的分析(用例模型，数据流图)搞混了 可以把架构设计作为一段来写 描述下系统用的什么架构，分为哪些部分/层，每个部分结合项目怎么怎么样。 接口设计： 模块和模块，子系统和子系统及系统和外部的接口 过程设计就是业务流程，参考活动图 数据设计就是数据库的设计，数据实体、实体之间的联系、关系表
      • 面向对象的设计
        • 从设计原则的角度去写，挑3个设计原则 也可以软件设计四个过程写（架构设计（采用BS三层架构、微服务架构。。）、接口设计、过程设计（业务流程，算法）、数据设计（数据实体及关系，关系表）） 题目：论面向对象设计方法及其应用 请围绕“论面向对象设计方法及其应用”论题，依次从以下三个方面进行论述。 1. 概要叙述你参与管理和开发的软件项目以及你在其中所担任的主要工作。 2. 面向对象设计方法中包含多种设计原则，请简要描述其中的三种设计原则。 3. 具体阐述你参与管理和开发的项目是如何遵循这三种设计原则进行信息系统设计的。
        • 范文
          • https://www.yunkt.top/article/10748
    • 开发方法和开发模型
      • 文老师预测一个关于开发方法或者开发模型的主题,2024年111月可能考到的是统一过程,学员可以重 点写这个,直播会进一步讲解,明确统一过程的九大工作流、四个阶段、三大特点。 最通用的是围绕四个阶段来写，可以选择其中三段写。、 也可以九大工作流选三来写 试题:论软件开发模型及应用 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件 开发过程包括需求、设计、编码和测试等阶段,有时也包括维护阶段。软件开发模型能清晰、直观地 表达软件开发全过程,明确规定了要完成的主要任务和活动,用来作为软件项目工作的基础。对于不 同的软件项目,针对应用需求、项目复杂程度、规模等不同要求,可以采用不同的开发模型,并采用 相应的人员组织策略、管理方法、工具和环境。 请围绕"软件开发模型及应用"论题,依次从以下三个方面进行论述。 1.简要叙述你参与的软件开发项目以及你所承担的主要工作。 2.列举出几种典型的软件开发模型,并概要论述每种软件开发模型的主要思想和技术特点 3.根据你所参与的项目中使用的软件开发模型,具体阐述使用用方法和实施效果
  • 我的论文
    • 固定模板素材
      • 项目选定: 车载相关，电子电气架构
    • 城市级智慧停车综合管理系统
      • 解决交通拥堵、基础设施不足、资源紧缺、信息孤岛等交通难点、痛点 平台采用微服务架构，稳定性更高，支持100万级车位同时在线。 业务服务部分通过Docker容器高效协同，不仅提升了系统的灵活扩展性，更显著增强了整体性能。
      • 需求与痛点
        • 车主需求 车主希望获得更加便捷、高效、安全的停车服务,包括车位预约、自动计费、无人值守等。 停车场运营方需求 停车场运营方希望通过智慧化改造,提高停车场的运营效率和管理水平,降低人力成本,增加收益。 政府需求 政府希望通过智慧停车场的建设,缓解城市停车难问题,改善城市交通状况提高城市管理水平。
      • 项目素材1
        •     智慧停车平台建设 道路停车设施建设 停车场管理系统建设 立体车库建设 充电桩建设 1.运营级智慧停车平台:"河南易泊车" 2.城市核心区1200个道路停车泊位,使用视频和地磁检测 3.扩展停车场收费管理和车位信息发布 50多个停车场接入。 
        • 停车诱导系统
          • 
      • 项目素材2
        •   
        • 静态交通管理平台
          •   接入停车场： ·商业场所下辖停车场 ·景区停车场 ·医院停车场 ·车站附属停车场 ·政府机关对外开放停车场
        • 大数据分析及运用
          • 
        • 价值与意义
          •     
      • 项目素材3
        •     
      • 参考范文
      • 云平台技术方案1
        • 一、项目背景 在数字经济时代背景下,企业面临着日益复杂化的业务流程,传统的企业管理方式已经不能适应市场变化和发展需求。为此,建立一套智慧企业云平台,将企业的商业应用整合在一起,通过云计算、大数据技术等手段,实现信息化、数字化升级,为企业提供更高效便捷的管理服务。本文将就该项目的建设方案进行详细介绍。 二、平台架构设计 智慧企业云平台作为企业信息化改造的核心,应该对企业内部的各种业务流程进行整合和优化。因此,我们考虑采用微服务架构来实现平台的搭建。 1.微服务架构特点 微服务架构是一种以服务为核心的软件架构风格。它将应用程序拆分成一组小型的、独立的、可独立部署和升级的服务,并通过轻量级通信机制实现服务之间的协同工作。微服务架构 具有以下优点: (1)易于扩展和部署:微服务可以独立部署和升级,因此可以根据业务的变化灵活地进行服务的扩展。 (2)更好的可维护性:由于微服务的拆分,每个服务都变得更加容易维护、测试和调试。 (3)更好的容错性:由于微服务以分布式系统为基础,因此 可以实现高可用性,减少系统的故障和停机时间。 (4)更好的团队协作:微服务可以被不同的团队并行开发和 维护,因此能够提高开发效率和质量。 2.平台架构设计 如图所示,智慧企业云平台的架构采用微服务架构,包括用户服务、物流服务、财务服务等多个子系统。其中,用户服务包括用户管理、权限管理等功能;物流服务包括物流运输,仓储物流等功能;财务服务包括财务核算、报表查询等功能。 每个子系统都独立运行,通过服务之间的调用实现协作,从人而实现整个平台的功能。 三、平台技术选型 为了实现上述架构,需要选取一些适用于微服务架构的技 术来实现各个子系统的开发。 1.后端技术 后端技术主要包括开发语言、框架、数据库等。 (1)开发语言:考虑到高效、强类型等因素,Java是较好 的选择。 (2)框架:Spring Cloud是一套开源的微服务框架,用于 构建分布式系统的应用程序。它提供了服务发现、服务治理、 负载均衡、分布式配置等功能,非常适合构建微服务应用。 (3)数据库:MySQL是目前使用最广泛的关系型数据库之 一,它具有开源、稳定、高性能等特点。 2.前端技术三、平台技术选型 为了实现上述架构,需要选取一些适用于微服务架构的技 术来实现各个子系统的开发。 1.后端技术 后端技术主要包括开发语言、框架、数据库等。 (1)开发语言:考虑到高效、强类型等因素,Java是较好的选择。 (2)框架:Spring Cloud是一套开源的微服务框架,用于构建分布式系统的应用程序。它提供了服务发现、服务治理、负载均衡、分布式配置等功能,非常适合构建微服务应用。 (3)数据库:MySQL是目前使用最广泛的关系型数据库之一,它具有开源、稳定、高性能等特点。 2.前端技术 前端技术包括Web开发语言、框架、模板引擎、UI组件 等。 (1)Web开发语言:前端开发主要依赖于三种Web开发语言:HTML、CSS和JavaScript。HTML负责页面的结构,CSS负责样式的设计,JavaScript负责交互。 (2)框架:Vue是一套开发Web界面的渐进式框架,它的核心库只关注视图层,易于上手,灵活性强。 (3)模板引擎:Thymeleaf是一款服务器端Java模板引擎,它与Spring框架紧密集成,适用于开发Web应用程序。 (4)UI组件:Element是一套基于Vue.js的桌面端组件库,具有易用、美观等特点,适合企业级的应用程序。 五、平台实施计划 系统的建设应该按照如下步骤进行: 1.需求分析:根据企业内部业务的需要,确定平台的功能需求和实际使用场景,包括子系统的划分、功能设计等。 2.技术选型:根据需求分析结果,选取适合的技术实现平台架构和功能。 3.整合开发:根据各个子系统的需求,进行整合、开发和测试。 4.部署上线:对开发完成的平台进行上线测试和部署。 5.维护优化:根据企业的实际需求和用户反馈,对平台进行维护和优化。 六、项目总结 智慧企业云平台的建设对企业信息化改造有重要的作用。 本文基于微服务架构,选取了Spring Cloud、Vue等技术,设计了用户管理、仓储物流管理、财务管理、业务分析等核心功能。对于企业要求提高工作效率、优化数据管理的需求,具有非常实用的参考价值。
      • 分层视图
        • 
      • 架构图
        •  
      • spring cloud
        • 微服务架构的技术栈选择则是在实际开发前的重点。微服务常见的开发框架是SpringBoot、SpringClound,这里由于SpringBoot和SpringClound是java语言的主流框架, 在部署方面主要采用了Docker容器化部署和Kubernetes作为主要微服务部署和管理技术。 八个技术点 Eureka-服务的注册与发现 Robbin-服务之间的负载均衡 Feign-服务之间的通讯 Hystrix-服务的线程隔离以及断路器 Zuul-服务网关 Stream-实现MQ的使用 Config-动态配置 Sleuth-服务追踪  
        • 服务注册中心eureka
          •  服务注册中心：把所有服务的信息都告诉服务注册中心，Eureka就是帮助我们维护所有服务的信息，以便服务之间的相互调用。 通过注册中心，各个微服务可以动态地注册和发现其他微服务，实现了微服务之间的通信和协作。
        • Ribbon
          • Robbin是帮助我们实现服务和服务负载均衡 在微服务架构中，负载均衡是非常重要的一环。通过负载均衡可以将请求均匀地分发到不同的微服务实例上，提高系统的稳定性和性能。SpringCloud提供了Ribbon等负载均衡组件，可以轻松实现负载均衡功能。 
        • 服务间的调用-Feign
          • Feign可以帮助我们实现面向接口编程，就直接调用其他的服务，简化开发。 优秀的HTTP client需要具备的特性： 连接池 超时间的设置（连接超时、读取超时等） 是否支持异步 请求和响应的编解码 可扩展性 使用Spring Cloud开发微服务时，在服务消费者调用服务提供者时，底层通过HTTP Client 的方式访问。但实际上在服务调用时，有主要以下来实现： 使用JDK原生的URLConnection； Apache提供的HTTP Client； Netty提供的异步HTTP Client； Spring提供的RestTemplate。 Spring Cloud的Spring Cloud Open Feign相对是最方便与最优雅的，使Feign支持Spring MVC注解的同时并整合了Ribbon。 在springCloud微服务架构下，各个业务会被拆分为独立的微服务。那么我们如何解决服务间调用的问题，springCloud默认提供了两种方式：restTemplate和feignClient。
        • API网关ZUUL
          • 统一的把安全性校验都放在Zuul中 
        • Kubernetes
          • kubernetes，简称K8s, Kubernetes 是一个开源的容器编排引擎,用来对容器化应用进行自动部署、 扩缩和管理。
        • Config
          • 通过Config 实现动态配置
        • 服务的追踪-Sleuth
          • 在整个微服务架构中，微服务很多，一个请求可能需要调用很多很多的服务，最终才能完成一个功能，如果说，整个功能出现了问题，在这么多的服务中，如何去定位到问题的所在点，出现问题的原因是什么。 Sleuth可以获得到整个服务链路的信息。 Zipkin通过图形化界面去看到信息。 Sleuth将日志信息存储到数据库中。
        • Docker
          • Docker不依赖任何语言和框架,原生可支持多种技术栈 Docker不依赖于基础架构平台,一次打包,可以在任意Linux平台上运行,所以可以适配不同的底层基 础架构平台 依赖于Docker镜像的统一格式,可进行标准化的快速部署,秒级启停,充分支持容错、修复,灰度发布和弹性伸缩 依赖于容器的封装特性和Docker的镜像打包模式,在DevOps的不同阶段可便捷地"ship",为自动化提供可行途径,大幅度降低CI/CD的复杂度,
        • 熔断与降级
          • 为了防止某个微服务出现故障导致整个系统崩溃，需要引入熔断和降级机制。Hystrix是SpringCloud提供的熔断器组件，可以在微服务之间进行熔断和降级处理，保证系统在异常情况下依然能够正常运行。
        • 为何使用微服务架构额不是SOA
          • 1、服务粒度 SOA：SOA更倾向于粗粒度的服务，这意味着每个服务通常包含较广泛的业务功能，在一个电商系统中，商品管理可能被设计为一个独立的服务，该服务涵盖了商品基本信息管理、供应商管理和入库管理等多个子功能。 微服务：微服务架构则强调细粒度的服务划分，它将复杂的业务系统拆分成更小、更专注单一功能的服务单元，同样以电商平台为例，商品基本信息管理、供应商管理和入库管理可能会被拆分为独立的服务，这种细粒度的服务可以更灵活地组合和扩展。 2、通信方式 SOA：SOA使用ESB（Enterprise Service Bus，企业服务总线）作为服务之间通信的中心枢纽，ESB负责消息转换、路由和传递，支持多种通信协议如SOAP、XML等，使得异构系统间能够互联互通。 微服务：微服务架构采用轻量级的通信方式，通常基于HTTP RESTful协议或TCP RPC协议，微服务之间的通信不需要重量级的ESB，而是通过统一的协议和数据格式直接进行交互。 3、交付速度 SOA：SOA对服务的交付没有特定要求，更多地考虑与现有系统的兼容性，SOA项目可能需要更多的时间来集成和测试新服务。 微服务：微服务强调快速交付和持续部署，每个微服务都是独立开发、测试和部署的单元，天然支持自动化测试、持续集成和自动化部署的最佳实践。  SOA：SOA更适合复杂、异构的企业级系统，这类系统通常包括多年积累下来的不同技术栈和业务模块，需要一种兼容并蓄的集成方式，由于改动成本高，无法完全重构，因此ESB成为连接各服务的重要桥梁。 微服务：微服务架构适合快速变化、基于Web的轻量级系统，这些系统通常需要快速试错、快速迭代，并且大部分基于类似的Web技术，容易通过微服务方式独立开发和部署。 总体来看，SOA和微服务架构各有优劣，选择哪一种架构取决于具体的业务需求和技术背景，SOA以其强大的集成能力和对企业级系统的支持，适用于大型、复杂的系统集成项目；而微服务则以其灵活性和快速交付能力，在新兴的互联网应用和创业项目中展现出巨大的优势，无论选择哪种架构，关键是要确保架构设计与业务需求相契合，从而提升整体系统的效率和效果。 松耦合性：微服务架构更强调松耦合性。每个微服务都是自治的，可以独立开发、部署和扩展。SOA框架中的服务可能更紧密地集成在一起，具有较高的依赖性。 容错性和弹性：微服务架构鼓励设计容错性和弹性，通过每个微服务的自治性和隔离性来减少故障的影响。SOA框架可能更多依赖于中央组件和集中式的错误处理机制。
        • 服务拆分原则
          • 1、粒度微小:根据业务功能划分服务粒度,总的原则是服务内部高内聚,服务之间低耦合。 2、责任单一:每个服务只做一件事,即单一职责原则。 3、隔离性原则:每个服务相互隔离,且不互相影响 4、业务无关优先原则: 基础服务,是一些基础组件,与具体的业务无关。比如:短信服务、邮件服务。这里的服务最容易划分 出来做微服务,也是我们第一优先级分离出来的服务。
        • 数据库挑战与策略
          • 每个微服务都有自己独立的数据库，那么后台管理的联合查询怎么处理？ 将业务高度相关的表放到一个库中,将业务关系不是很紧密的表严格按照微服务模式来拆分,这样既可以 使用微服务,也避免了数据库分散导致后台系统统计功能难以实现。
        • 后期发现的问题
          • 1. Eureka的高可用 太low 如果程序的正在运行，突然Eureka宕机了。 如果调用方访问过一次被调用方了，Eureka的宕机不会影响到功能。 如果调用方没有访问过被调用方，Eureka的宕机就会造成当前功能不可用。 解决方案： 准备多台Eureka，让服务注册到多台Eureka，让多台Eureka之间相互通讯 2.性能优化的角度
          • 性能优化
            • 1. 数据库优化 数据库是系统性能的关键瓶颈之一。通过合理设计数据库表结构、建立索引、使用缓存等方式可以提高数据库查询效率。此外，采用数据库读写分离、分库分表等策略也可以有效减轻数据库压力。 2. 缓存优化 在微服务架构中，缓存起着至关重要的作用。通过使用Redis、Memcached等缓存组件，可以将热点数据缓存起来，减少对数据库的频繁访问，提高系统响应速度。 3. 微服务调优 对于每个微服务单元，都需要进行性能调优。可以通过监控工具对各个微服务进行监控和调优，及时发现并解决潜在性能问题。 4. 网络通信优化 在微服务架构中，各个微服务之间通过网络进行通信。因此，网络通信的效率直接影响系统整体性能。合理配置网络参数、使用高效的通信协议等方式可以提高网络通信效率。
    • 思路
      • 以多系统间通信交互为切入点 fdbus 微服务架构： 以UU 模块的开发为例？ 车规级
    • 基于云原生的集装箱码头操作系统架构设计与应用
  • 待学习知识点
    • 企业应用集成