系统架构设计师 - 知识分类汇总

0. 重点

  • 选择题涉及的知识点,有印象、注意关键字就行。
  • !!!应用题和论文有一些经常考到的点,可以一起准备!!!可以都列一下知识点提示,便于记忆!!!
    • 架构
      • 架构评估
        • 质量属性、质量效用树
          • 性能
          • 安全
          • 可用性
          • 可扩展性
          • 可测试性?
          • 易用性?
          • 业务需求?
        • 架构风险、敏感点和权衡点
          • 系统架构风险
            • 架构设计中潜在的、存在问题的架构决策所带来的隐患
          • 敏感点
            • 为了实现某种特定的质量属性,一个或多个系统组件所具有的特性
          • 权衡点
            • 影响多个质量属性,并对多个质量属性来说都是敏感点的系统属性
      • 具体架构风格
        • 面向服务架构(SOA)
        • 面向构件的编程
        • MVC
        • Web系统架构设计?
        • 微服务?
    • 系统建模
      • 结构化方法
        • 数据流图(Data Flow Diagram)
          • 基本元素类型及其作用
          • 判断元素
          • 错误类型
        • CRUD矩阵
        • 信息工程方法中的“实体(entity)” 与面向对象方法中的“类(class)”之间有哪些不同之处?
          • 实体用于数据建模,而类用于面向对象建模。
          • 实体只有属性,类有属性和方法。
      • 面向对象方法
        • 用例
          • Essential Use Cases和Real Use Cases的区别
            • 基础用例是通过调研用户需求或得到的,与用户需求有对应关系的用例。
            • 抽象用例是当能够从两个或两个以上的基础用例中提取公共行为时,把这个提取出来的公共用例成为抽象用例。
          • 参与者
          • 用例之间的关系的类型
        • 类图
          • 类之间的关系的类型
        • 状态图和活动图
          • 含义及其区别
    • 数据库
      • 不同数据库类型
        • 文件系统与关系型数据库的特点对比
          • 设计难度
          • 数据冗余程度
          • 数据架构(以什么为中心)
          • 应用扩展性
        • 关系型数据库与内存数据库型数据库的特点对比
          • 主要数据类型
          • 读写性能
          • 存储容量
          • 可靠性(数据恢复要求)
        • 分布式数据库缓存/内存数据库型数据库
          • 引入Memcached后系统访问数据库的基本过程
          • 使用Memcached代替数据库查询缓存的原因:
            • (1) 缓存架构(存储容量)
            • (2) 缓存有效性
            • (3) 缓存数据类型
        • 混合存储架构
      • 数据库访问及持久层
        • 数据持久层
          • 是根据分层思想,通过建立逻辑数据操作接口,采取一定的对象/关系映射策略,隐藏数据库访问代码细节,向业务开发人员提供透明的对象持久化操作机制。
          • 能够为项目开发带来的好处:
            • (1)分离业务逻辑层和数据层,降低两者之间的耦合,解耦两者之间的直接关联;
            • (2) 通过对象/关系映射向业务逻辑提供面向对象的数据访问,将面向业务逻辑的数据处埋全部以对象形式暴露,将对对象的操作自动转换为基于关系模式的数据库访问操作;
            • (3) 简化数据层访问,隐藏数据库链接、数据读写命令和事务管理细节,有效提升系统开发效率。
            • 另一种表述
              • 由于可能涉及到多种异构数据库平台,数据访问复杂性增加,不宜与业务逻辑混合在一起
              • 数据管理变复杂之后,需要使用的代码量增加,分单独层次有利于让逻辑更清晰
              • 业务逻辑应以相同的方式对应异构的数据库,此时需要单独的数据访问层屏蔽差异性
        • 主流的数据持久层技术按照其实现思路可以分为4类技术方案,包括:
          • 基于数据库连接UDBC封装
          • 命令转换(SQL Mapping)
          • 对象关系映射(O/R Mapping)
          • 数据持久化对象(Entity Bean)
        • Hibernate和iBatis
          • 共同点
            • 轻量级JavaEE,优秀的开源项目
          • 不同点
            • 不同类型数据库
            • 难易程度
            • 开发工作量
            • 生成的PO情况

1. 计算机组成与体系结构

  • 流水线
    • 吞吐率是指单位时间里流水线处理机流出的结果数。对指令而言即为单位时间里执行的指令数。
      • =指令条数/ 流水线执行时间
      • 精确值、近似值(n 趋向于无穷大的结果)都可以,看选项里有哪一个
    • 加速比
      • =不用流水线的执行时间/使用流水线的执行时间
  • 校验与纠错
    • CRC码计算及校验原理的最通俗诠释
    • 步骤
      • 选择多项式(可以随便选,也可以按标准选,国际上有通行的标准选择,但最高位和最低位必须均为“1”)
      • 根据多项式的二进制位数,往信息码后面补相应个数的0
      • 然后用补充后的信息码除以多项式的二进制码,主要每次相减用的是异或操作
      • 除到最后一步后的余数,就是想要的校验码
        • 余数的位数一定要是比除数位数只能少一位,哪怕前面位是0,甚至是全为0(附带好整除时)也都不能省略。
      • 在信息传输过程中,这个余数要放到原信息码后面用于校验,然后发送出去
      • 接收方再把这个新帧以“模2除法”方式除以前面选择的除数,如果没有余数,则表明该帧在传输过程中没出错,否则出现了差错。
  • CPU
    • DSP采用的哈佛结构是程序和数据空间分开的。
    • CPU的主频=外频*倍频
  • 总线
  • 存储
    • 存储体系结构包括不同层次上的存储器,通过适当的硬件、软件有机地组合在一起形成计算机的存储体系结构。例如,由髙速缓存(Cache)、主存储器(MM)和辅助存储器构成的3层存储器层次结构存如下图所示。
    • 接近CPU的存储器容量更小、速度更快、成本更高,辅存容量大、速度慢,价格低。采用分级存储体系的目的是解决存储的容量、价格和速度之间的矛盾。
    • 磁盘
      • 磁盘调度管理
        • 最短移臂调度算法指距离现在移动臂位置最近的柱面号请求将优先得到响应(移动臂移动距离最短),而对于同样柱面号不同扇区号的请求,将按磁头旋转时的划过顺序,可以简单理解为扇区号小的优先响应。
        • 处理记录的时间
          • 磁盘旋转期间,可以在经过记录时,顺便取出来记录
          • 磁盘旋转期间,可以同时处理记录,因此优化记录存储后,可以让记录之间的旋转时间正好等于处理时间,那么就可以不间断的进行并行处理了
          • 如果完全没优化,按照题目给定的记录存储位置,最差的情况下可以使每次处理刚读上来的记录处理后,正好错过了下一个记录,那么就只能再转一整圈回来读这个下一条记录了
      • RAID
        • RAID是英文Redundant Arrayof Independent Disks的缩写,中文简称为独立冗余磁盘阵列。简单地说,RAID是一种把多块独立的硬盘(物理硬盘)按不同的方式组合起来形成一个硬盘组(逻辑硬盘),从而提供比单个硬盘更高的存储性能和提供数据备份技术。组成磁盘阵列的不同方式称为RAID级别(RAID Levels)。在用户看起来,组成的磁盘组就像是一个硬盘,用户可以对它进行分区,格式化等。总之,对磁盘阵列的操作与单个硬盘一模一样。不同的是,磁盘阵列的存储速度要比单个硬盘高很多,而且可以提供自动数据备份。数据备份的功能是在用户数据一旦发生损坏后,利用备份信息可以使损坏数据得以恢复,从而保障了用户数据的安全性。RAID技术分为几种不同的等级,分别可以提供不同的速度,安全性和性价比。根据实际情况选择适当的RAID级别可以满足用户对存储系统可用性、性能和容量的要求。常用的RAID级别有以下几种:NRAID,JBOD,RAIDO,RAID1,RAID1+0,RAID3,RAID5等。目前经常使用的是RAID5和RAID(1+0)。如果使用物理硬盘容量不相等的硬盘做RAID,那么创建的RAID阵列的总容量为较小的硬盘的计算方式。
        • RAID5的存储机制是两块存数据,一块存另外两块硬盘的交易校验结果。RAID5的建立后,坏掉一块硬盘,可以通过另外两块硬盘的数据算出第三块的,所以至少要3块。RAID5是一种旋转奇偶校验独立存取的阵列方式,它与RAID3,RAID4不同的是没有固定的校验盘,而是按某种规则把奇偶校验信息均匀地分布在阵列所属的硬盘上, 所以在每块硬盘上,既有数据信息也有校验信息。这一改变解决了争用校验盘的问题,使得在同一组内并发进行多个写操作。所以RAID5既适用于大数据量的操作,也适用于各种事务处理,它是一种快速、大容量和容错分布合理的磁盘阵列。当有N块阵列盘时,用户空间为N-1块盘容量。
    • 双缓冲与单缓冲
      • 在存储系统写数据的过程中,出于性能上的考虑,新写的数据并不是每次都flush到目标存储中的,而是先放入到一个buffer空间里,等到buffer空间满了,再做一次flush出去的动作。
      • 这种单缓冲设计模式还是存有一个主要弊端的,当缓冲数据满后将会阻塞住后面的数据操作直到缓冲数据完全flush出去。更简单的来说,这里会有个throughput的问题。那么有什么改进办法呢,答案是利用另外一个缓冲构成双缓冲模式。
      • 双缓冲设计将缓冲区分为2份,1份为当前缓冲区buf current,另外1份为预写入分区buf ready,两个缓冲区空间大小一致。current区负责当前的写操作存放,当我们达到缓冲处罚条件时,执行一次双缓冲的调换操作。然后由另外的程序执行ready区的flush操作。被交换变为空缓冲区的current区重新用于这的数据写入。
    • 文件系统
      • 采用文件索引节点法存储的文件系统可表示的单个文件最大长度是:(直接地址索引可存地址+一级间接地址索引可存地址+二级间接地址索引可存地址+...)*磁盘数据块大小
        • 不管直接地址索引可存地址、一级间接地址索引可存地址还是二级间接地址索引可存地址,地址也是存储在物理块中的,所以首先要算出一个物理块可以存多少个地址,其实这也就是直接地址索引可存地址数量,等于磁盘索引块大小/地指项大小
        • 二级间接地址可以存储的物理块数量是一级间接地址的平方,以此类推
  • DMA(直接存储器访问)
    • 直接主存存取( Direct Memory Access,DMA)是指数据在主存与I/O 设备间的直接成块传送, 即在主存与I/O 设备间传送数据块的过程中, 不需要CPU作任何干涉,只需在过程开始启动(即向设备发出“传送一块数据”的命令)与过程结束(CPU通过轮询或中断得知过程是否结束和下次操作是否准备就绪)时由CPU进行处理,实际操作由DMA 硬件直接完成, CPU在传送过程中可做其它事情。
  • RISC(精简指令系统计算机)与CISC(复杂指令系统计算机)
    • 特点
      • 指令长度固定,指令种类尽量少
      • 增加寄存器数目,以减少访存次数
      • 用硬布线电路实现指令解码,以尽快完成指令译码
  • 嵌入式系统
    • 嵌入式处理器是嵌入式系统的核心部件,一般可分为嵌入式微处理器(MPU) 、微控制器(MCU) 、数字信号处理器(DSP)和片上系统(SOC)。
      • MPU并没有提升性能,故不适用于运算量较大的智能系统。
      • MCU 典型代表是单片机,体积小从而使功耗和成本下降
      • DSP 处理器对系统结构和指令进行了特殊设计,适合数字信号处理
      • SOC 是一个有专用目标的集成电路, 其中包括完整系统并有嵌入式软件的全部内容
    • 嵌入式操作系统是应用于嵌入式系统,实现软硬件资源的分配,任务调度,控制、协调并发活动等的操作系统软件。它除了具有一般操作系统最基本的功能如多任务调度、同步机制等之外,通常还会具备以下适用于嵌入式系统的特性:面向应用,可以进行检查和移植,以支持开放性和可伸缩性的体系结构;强实时性,以适应各种控制设备及系统;硬件适用性,对于不同硬件平台提供有效的支持并实现统一的设备驱动接高可靠性,运行时无须用户过多干预,并处理各类事件和故障;编码体积小,通常会固化在嵌入式系统有限的存储单元中。
    • MMU
      • MMU是存储器管理单元的缩写,是用来管理虚拟内存系统的器件。MMU通常是CPU的一部分,本身有少量存储空间存放从虚拟地址到物理地址的匹配表。此表称作TLB(转换旁置缓冲区)。所有数据请求都送往MMU,由MMU决定数据是在RAM内还是在大容量存储器设备内。如果数据不在存储空间内,MMU将产生页面错误中断。
      • MMU的两个主要功能是将虚地址转换成物理地址,控制存储器存取允许。MMU关掉时,虚地址直接输出到物理地址总线。
      • Cortex-M3处理器采用ARMv7-M架构,它包括所有的16位Thumb指令集和基本的32位Thumb-2指令集架构。Cortex-M3支持线程模式和处理模式。在复位时处理器进入“线程模式”,异常返冋时也会进入该模式,特权和用户(非特权)模式代码能够在“线程模式”下运行。出现异常模式时处理器进入“处理模式”,在处理模式下,所有代码都是特权访问的。μC/OS-II可以运行在Cortex-M3处理器上。
    • 存储部件
      • 高速缓冲存储器(Cache)其原始意义是指存取速度比一般随机存取记忆体(RAM)来得快的一种RAM寄存器快,寄存器是CPU里的,当然是最快的。
      • 存取速度:寄存器>Cache>RAM>Flash?
    • 软件设计层面的功耗控制可以从以下方面展开:
      • 软硬件协同设计,即软件设计要与硬件的匹配,考虑硬件因素。
      • 编译优化,采用低功耗优化的编译技术。
      • 减少系统的持续执行时间,从算法角度进行优化。
      • 用“中断”代替“查询”。
      • 进行电源的有效管理。
    • 嵌入式数据库管理系统
      • 嵌入式系统的数据库系统称为嵌入式数据库系统或嵌入式实时数据库系统。嵌入式系统必须能够在没有人工干预的情况下,长时间不间断地运行,因此要求高的可靠性。同时要求数据库操作具备可预知性,而且系统的大小和性能也都必须是可预知的,以保证系统的性能。嵌入式系统需要与底层硬件打交道,因此在数据管理时,也要有底层控制的能力,如什么时候会发生磁盘操作,磁盘操作的次数,如何控制等。底层控制的能力是决定数据库管理操作的关键。
      • 嵌入式数据库管理系统一般只提供本机服务接口,为前端应用提供基本的数据支持。

2. 操作系统

  • 进程管理
    • PCB(进程控制块)
    • 三种方式
      • 线性(顺序)
        • 所有的PCB都组织在一张线性表中,该表的首地址放在内存的一个专用区域,每次使用都遍历整张表,适合进程数目较少的操作系统。
      • 链接
        • 将具有相同状态进程的PCB分别通过PCB中的链接字链接成一个队列,这样可以形成就绪队列、阻塞队列和空白队列等。
      • 索引
        • 即系统根据进程状态不同,建立几张索引表。
        • 三态模型
    • 进程前趋图
      • 从第一个节点开始,按层次,先是第一层的,再是第二层的......
    • PV操作
      • 如果公共数据单元是一个临界资源,最多允许1个终端进程使用,因此需要设置一个互斥信号量S,初值等于1
      • 进入临界区时执行P操作,退出临界区时执行V操作
  • 死锁与活锁
    • 与操作系统一样,封锁的方法可能引起活锁和死锁。
      • 例如事务T1封锁了数据R,事务了T2请求封锁R,于是T2等待。T3也请求封锁R,当T1释放了R上的封锁之后系统首先批准了T3的请求,T2仍然等待。然后T4又请求封锁R,当:T3释放R上的封锁后系统又批准了T4的请求,……T2有可能长期等待,这就是活锁(申请同一资源)。避免活锁的简单方法是采用先来先服务的策略。即让封锁子系统按请求封锁的先后次序对事务排队。数据R上的锁一旦释放就批准申请队列中的第一个事务获得锁。
      • 又如事务T1封锁了数据R1,T2封锁了数据R2,T3封锁了数据R3。然后T1又请求封锁R2,T2请求封锁R3,T3请求封锁R1。于是出现T1等待T2释放R2上的封锁,T2等待T3释放R3上的封锁,T3等待T1释放R1上的封锁。这就使得三个事务永远不能结束。即多个事务都请求封锁别的事务已封锁的数据,导致无法运行下去的现象称为死锁(循环申请不同资源)
  • 实时操作系统(RTOS)
    • 实时系统的正确性依赖于运行结果的逻辑正确性和运行结果产生的时间正确性,即实时系统必须在规定的时间范围内正确地响应外部物理过程的变化。
    • RTOS 实质上就是一个计算机资源管理程序,需要及时响应实时事件和中断
    • 实时多任务操作系统是根据操作系统的工作特性而言的。实时是指物理进程的真实时间。
    • 实时操作系统是指具有实时性,能支持实时控制系统工作的操作系统。首要任务是调度一切可利用的资源来完成实时控制任务, 其次才着眼于提高计算机系统的使用效率,重要特点是要满足对时间的限制和要求。
    • 一个实时操作系统可以在不破坏规定的时间限制的情况下完成所有任务的执行。任务执行的时间可以根据系统的软硬件的信息而进行确定性的预测。也就是说,如果硬件可以做这件工作,那么实时操作系统的软件将可以确定性的做这件工作。
    • 实时操作系统可根据实际应用环境的要求对内核进行裁剪和重新配置, 根据不同的应用,其组成有所不同。

3. 数据库系统

  • 关系模式及关系运算(演算)
    • 自然连接会自动去除列名相同的重复列
    • 投影运算:只保留指定列
    • 注意关系运算表达式中,投影和自然连接使用的列序号,是去重之后的,比如ABC和CDE关联,那么1是A,2是B,3是C,4就是D了,5是E,4不是第二个表中的C!
    • 为了提高查询效率,先做选择,再做关联;指定用什么列进行关联要比自然连接快
  • 码、函数依赖与范式
    • 就是用来区分实体集中不同实体的属性集合。
    • 超码是一个或多个属性的集合,这些属性的组合可以使我们在一个实体集中惟一地标识一个实体。
    • 通常只关心这样的超码: 它们的任意真子集都不能成为超码,这样的最小超码称为候选码
  • sql语句
    • SQL语句设计时,影响查询效率的设计原则是:
      • 查询时尽量不要返回不需要的行、列;
      • 需要进行多表连接査询时,尽量使用连接查询,避免使用子查询结构;
      • 尽量避免采用NOTIN、NOTEXIST、LIKE等使用全表查询的操作;
      • 尽量避免使用DISTINCT关键字。
  • 分布式数据库
    • 二阶段提交(Two-phaseCommit)是指,在计算机网络以及数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常,二阶段提交也被称为是一种协议(Protocol))。在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败, 却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时, 为了保持事务的ACID特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此,二阶段提交的算法思路可以概括为:参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
      • 所谓的两个阶段是指: 第一阶段:准备阶段(表决阶段)和第二阶段: 提交阶段(执行阶段)。
      • 准备阶段:事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare 消息,每个参与者要么直接返回失败(如权限验证失败),要么在本地执行事务,写本地的redo 和undo 日志,但不提交,到达一种万事俱备,只欠东风的状态。提交阶段: 如果协调者收到了参与者的失败消息或者超时, 直接给每个参与者发送回滚(Rollback)消息;否则,发送提交(Commit)消息;参与者根据协调者的指令执行提交或者回滚操作,释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
    • 分片透明是指用户或应用程序不需要知道逻辑上访问的表具体是怎么分块存储的。复制透明是指采用复制技术的分布方法,用户不需要知道数据是复制到哪些节点,如何复制的。位置透明是指用户无须知道数据存放的物理位置,逻辑透明,即局部数据模型透明,是指用户或应用程序无须知道局部场地使用的是哪种数据模型。
  • 数据库分区、分库、分表
    • 分库(级别最高,成了不同的数据库,然后每个数据库自身还可能再分区分表)
      • 其主要目的是为突破单节点数据库服务器的 I/O 能力限制,解决数据库扩展性问题。
      • 垂直拆分
        • 将系统中不存在关联关系或者需要join的表可以放在不同的数据库不同的服务器中。
        • 按照业务垂直划分。比如:可以按照业务分为资金、会员、订单三个数据库。
        • 与分区分表相比,不会拆表,级别更高,整表划分到不同库
        • 需要解决的问题:跨数据库的事务、jion查询等问题。
      • 水平拆分
        • 例如,大部分的站点。数据都是和用户有关,那么可以根据用户,将数据按照用户水平拆分。
        • 按照规则划分,一般水平分库是在垂直分库之后的。比如每天处理的订单数量是海量的,可以按照一定的规则水平划分。
        • 和分区分表相比,逻辑上类似,但会划分到不同库,而不简简单单的是同表的不同存储位置或者不同表
        • 需要解决的问题:数据路由、组装。
      • 读写分离
        • 类似于主从复制
        • 对于时效性不高的数据,可以通过读写分离缓解数据库压力。需要解决的问题:在业务上区分哪些业务上是允许一定时间延迟的,以及数据同步问题。
    • 分表与分区
      • 分表(级别适中,表在逻辑上成了不同的多张表)
        • 就是把一张表按一定的规则分解成N个具有独立存储空间的实体表。系统读写时需要根据定义好的规则得到对应的字表明,然后操作它。
      • 分区(级别最低,表在逻辑上还是一张表,只是物理上到了不同位置)
        • 把一张表的数据分成N个区块,在逻辑上看最终只是一张表,但底层是由N个物理区块组成的
        • 数据分区是一种物理数据库的设计技术
        • 分区可以做到将表的数据均衡到不同的地方,它的目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间,提高数据检索的效率,降低数据库的频繁IO压力值。
        • 分区并不是生成新的数据表,而是将表的数据均衡分摊到不同的硬盘,系统或是不同服务器存储介子中,实际上还是一张表。
        • 主要可以提升查询效率
        • 实现
          • 一般是数据库层面的实现,所以对使用者来说比较简单
        • 数据库分区可采用水平分区和垂直分区两种方式
          • 水平分区
            • 这种形式分区是对表的行进行分区,通过这样的方式不同分组里面的物理列分割的数据集得以组合,从而进行个体分割(单分区)或集体分割(1个或多个分区)。所有在表中定义的列在每个数据集中都能找到,所以表的特性依然得以保持。
            • 也就是说整行整行的按行分区,一些行在这个地方,一些行在另一个地方(磁盘等)
            • 常用于将一些不常用的历史整行数据单独存储;或者单纯为了提高性能,类似于多了一级索引,类似于分库分表
            • 举个简单例子:一个包含十年发票记录的表可以被分区为十个不同的分区,每个分区包含的是其中一年的记录。(这里具体使用的分区方式我们后面再说,可以先说一点,一定要通过某个属性列来分割,譬如这里使用的列就是年份)
            • 本系统中应主要使用水平分区机制。根据已知信息,系统数据库中存储的主要数据为以用户标识为索引的社交网络数据,采用水平分区机制可根据用户标识将用户数据进行水平分割,用户操作时先将请求分发到不同数据库分区,再进行具体数据库操作,以提高数据库访问效率。
          • 垂直分区
            • 这种分区方式一般来说是通过对表的垂直划分来减少目标表的宽度,使某些特定的列被划分到特定的分区,每个分区都包含了其中的列所对应的行。
            • 也就是说按列分区,一些列在这个地方,一些列在另一个地方(磁盘等)
            • 常用于一些列很大或者不常用的情况
            • 举个简单例子:一个包含了大text和BLOB列的表,这些text和BLOB列又不经常被访问,这时候就要把这些不经常使用的text和BLOB了划分到另一个分区,在保证它们数据相关性的同时还能提高访问速度。
      • 常见分区分表的规则策略(类似)
        • Range(范围)
        • Hash(哈希)
        • 按照时间拆分
        • Hash之后按照分表个数取模
        • 在认证库中保存数据库配置,就是建立一个DB,这个DB单独保存user_id到DB的映射关系
  • 主从复制
    • 引入主从复制机制所带来的好处:
      • ①避免数据库单点故障:主服务器实时、异步复制数据到从服务器,当主数据库宕机时,可在从数据库中选择一个升级为主服务器,从而防止数据库单点故障。
      • ②提高査询效率:根据系统数据库访问特点,可以使用主数据库进行数据的插入、删除及更新等写操作,而从数据库则专门用来进行数据査询操作,从而将査询操作分担到不同的从服务器以提高数据库访问效率。
  • 不同的数据库类型
    • 分布式数据库缓存/内存数据库型数据库
      • 将数据放在内存中直接操作的数据库,使用内存型数据库将极大地提高应用的性能,同时通过数据缓存、快速算法、并行操作等的改进,使内存型数据库相对于传统的关系型数据库数据处理性能提高10倍以上,同时内存型数据库的应用受到内存大小,数据恢复要求的限制。
      • 引入Memcached后系统访问数据库的基本过程为:系统需要读取后台数据时,先检査数据是否存在于Memcached中,若存在则直接从Memcached中读取,或不存在则从数据库中读取并保存在Memcached中;当系统数据库中数据发生更新时,需要将更新后的内容同步到Memcached缓存实例中。
      • 使用Memcached代替数据库查询缓存(如sql server自身的查询缓存)的原因:
        • (1) 缓存架构(容量):数据库查询缓存通常每个数据库只有一个实例,因此存储内容受数据库服务器可用内存限制,可缓存数据有限。而Memcached可采用高速分布式缓存服务器结构,不受数据库服务器约束,可扩展性更好。
        • (2) 缓存有效性:数据库查询缓存只要在发生写操作时就会失效,即使更新的是数据库中的其他行。而Memcached可通过键值将数据进行散列缓存,有效降低缓存的更新频率,从而提髙缓存的有效性。
        • (3) 缓存数据类型:数据库查询缓存只能缓存数据库行,对社交网站好友动态显示等典型业务所需要的组合数据缓存缺乏有效支持,而Memcached理论上可缓存任何内容。因此可以将分散在数据库中的关系或者列表组合后进行缓存,以提高缓存数据的针对性和效率。
    • 文件系统与关系型数据库的特点对比
      • 文件系统具有以下特点:
        • 设计难度:针对特定应用系统设计,难度较小;
        • 数据冗余程度:数据冗余较大,可能在多个文件中复制相同的数据属性;
        • 数据架构:以应用系统为中心组织、管理数据;
        • 应用扩展性:符合特定应用系统要求的文件数据很难在不同的应用系统之间共享。
      • 关系型数据库具有以下特点。
        • 设计难度:数据结构需要符合关系模式,设计难度较大;
        • 数据冗余程度:遵守数据库范式,数据冗余较少;
        • 数据架构:以数据库为中心组织、管理数据;
        • 应用扩展性:数据独立于应用系统,很容易在不同的应用系统之间共享数据。
    • 关系型数据库与内存数据库型数据库的特点对比
      • 混合存储架构中,将客户电子邮件、客户联系电话、商品库存信息、商品价格信息等数据存入内存数据库:客户基本信息,商品基本信息相对稳定、访问频率较低,存入关系型数据库。
      • 关系型数据库特点
        • 主要数据类型:关系模式
        • 读写性能:外存读写,性能相对较低
        • 存储容量:基于磁盘存储,存储容量大
        • 可靠性:内建恢复机制,可靠性较高
      • 内存型数据库特点
        • 主要数据类型:Key-Value模式(键-值对模式)
        • 读写性能:内存直接读写,性能相对较高
        • 存储容量:基于内存存储, 存储容量受限(分布式会好得多?)
        • 可靠性:恢复机制复杂, 可靠性较低
  • 数据库访问
    • 数据持久层
      • 是根据分层思想,通过建立逻辑数据操作接口,采取一定的对象/关系映射策略,隐藏数据库访问代码细节,向业务开发人员提供透明的对象持久化操作机制。能够为项目开发带来的好处:
        • (1)分离业务逻辑层和数据层,降低两者之间的耦合,解耦两者之间的直接关联;
        • (2) 通过对象/关系映射向业务逻辑提供面向对象的数据访问,将面向业务逻辑的数据处埋全部以对象形式暴露,将对对象的操作自动转换为基于关系模式的数据库访问操作;
        • (3) 简化数据层访问,隐藏数据库链接、数据读写命令和事务管理细节,有效提升系统开发效率。
        • 另一种表述
          • 由于可能涉及到多种异构数据库平台,数据访问复杂性增加,不宜与业务逻辑混合在一起
          • 数据管理变复杂之后,需要使用的代码量增加,分单独层次有利于让逻辑更清晰
          • 业务逻辑应以相同的方式对应异构的数据库,此时需要单独的数据访问层屏蔽差异性
      • 主流的数据持久层技术按照其实现思路可以分为4类技术方案,包括:
        • 基于数据库连接UDBC封装(JDBC封装)
          • 如SpringJdbcTemplate,通过封装JDBC操作接口实现数据库访问操作
        • 命令转换(SQL Mapping)
          • 如iBatis/MyBatis,fflatis/MyBatis是通过SQL映射将数据操作请求转换为数据库的SQL操作
        • 对象关系映射(O/R Mapping)
          • 如TopLink,JDO,Hibernate,都采用了对象关系映射的思想
        • 数据持久化对象(Entity Bean)
          • 如BMP, CMP,j2EE中的BMP和CMP及EJB3.0都是利用实体Bean对象完成数据访问操作
      • Hibernate和iBatis
        • Hibernate和iBatis是轻量级hvaEE框架中两种数据持久层技术,两者都是优秀的开源项目。
        • iBatis相对简单易学而且更灵活,但开发工作量较大,数据之间是关联关系;
        • Hibernate框架相对复杂,所生成的持久化对象能够表达面向对象中的继承和聚合等关系,开发工作量较小,Hibernate使用更广泛更成熟,能够适应目前所有主流的关系型数据库。
        • (1) Hibernate支持多种不同类型数据库,满足项目组数据库移植需求;(而用IBatis的话,sql会有些许不同)
        • (2) Hibernate相对于iBatis减少了SQL语句开发的工作量;
        • (3) iBatis生成的P0是扁平化的,无法像Hibernate—样支持对象的继承和聚合等立体化关系。
    • 数据库程序在线访问方式和ORM方式的优缺点
      • 数据库程序在线方式
        • 优点
          • 性能比直接SQL好
          • 可以处理复杂查询语句
        • 缺点
          • 要求程序员懂SQL语句
          • 修改与维护相对困难
      • ORM
        • 优点
          • 使用ORM可以大大降低学习和开发成本
          • 程序员不用再写SQL来进行数据库操作
          • 减少程序的代码量
          • 降低由于SQL代码质量差而带来的影响
        • 缺点
          • 不太容易处理复杂查询语句
          • 性能较直接用SQL差
  • 数据仓库
  • 静态转储与动态转储
    • 静态转储是转储期间不允许对数据库进行任何存取、修改活动。动态转储是转储期间允许对数据进行存取或修改。本题要求转存全部数据。

4. 计算机网络

  • 分层
  • DiffServ
    • 区分服务( DiffServ )是一种保证QoS的网络技术。用户( 或网络边界节点) 通过设置每个数据包的DS 字段(IPV4 首标中的服务类型(ToS) 字段或IPV6 首标中的通信类(Traffic Class) 字段) 的值要求特定的服务等级。
    • IETF集成服务(IntServ)工作组根据服务质量的不同,把Internet服务分成了三种类型:
      • 保证质量的服务(Guranteed Services):对带宽、时延、抖动和丢包率提供定量的保证;
      • 负载受控的服务(Comrolled-load Services):提供一种类似于网络欠载情况下的服务,这是一种定性的指标;
      • 尽力而为的服务(Best-Effort):这是Internet提供的一般服务,基本上无任何质量保证。
  • IPv6
    • IPv6地址增加到128位,并且能够支持多级地址层次;地址自动配置功能简化了网络地址的管理;在组播地址中增加了范围字段,改进了组播路由的可伸缩性;增加的任意播地址比IPv4中的广播地址更加实用。
    • 每个主机拥有不止一个的IPv6地址
    • IPv6地址是一个或一组接口的标识符。IPv6地址被分配到接口,而不是分配给结点。IPv6地址有三种类型:单播(Unicast)地址、任意播(AnyCast)地址、组播(Multicast)地址
    • 状态自动配置与无状态自动配置
      • 除了状态自动配置, IPv6 还采用了一种被称为无状态自动配置( Stateless Auto Configuration )的自动配置服务。具体地说,在无状态自动配置过程中,主机首先通过将它的网卡MAC地址附加在链接本地地址前缀1111111010 之后,产生一个链接本地单播地址。
  • 管理距离
    • 管理距离AD是指一种路由协议的路由可信度。每一种路由协议按可靠性从高到低,依次分配一个信任等级,这个信任等级就叫管理距离。
    • AD值越低, 则它的优先级越高。一个管理距离是一个从0—— 255 的整数值, 0 是最可信赖的,而255 则意味着不会有业务量通过这个路由。静态路由一般默认AD为1。
  • DNS
    • A记录代表“主机名称”与“IP”地址的对应关系,作用是把名称转换成IP地址。
    • PTR记录代表“IP地址”与“主机名”的对应关系,作用刚好与A记录相反。
  • DHCP
  • 协议
    • IPSec是IETF制定的IP层加密协议,PKI技术为其提供了加密和认证过程的密钥管理功能。IPSec主要用于开发新一代的VPN。
    • L2TP是一种二层协议主要是对传统拨号协议PPP的扩展,通过定义多协议跨越第二层点对点链接的一个封装机制,来整合多协议拨号服务至现有的因特网服务提供商点,保证分散的远程客户端通过隧道方式经由Internet等网络访问企业内部网络。
    • PAP协议是二层协议PPP协议的一种握手协议,以保证PPP链接安全性。
    • HTTPS是一个安全通信通道,用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换,所有的数据在传输过程中都是加密的。
    • MIME与S/MIME
      • MIME(Multipurpose Internet Mail Extensions)中文名为:多用途互联网邮件扩展类型。Internet 电子邮件由一个邮件头部和一个可选的邮件主体组成,其中邮件头部含有邮件的发送方和接收方的有关信息。而MIME 是针对邮件主体的一种扩展描述机制。它设定某种扩展名的文件用一种应用程序来打开的方式类型, 当该扩展名文件被访问的时候, 浏览器会自动使用指定应用程序来打开。多用于指定一些客户端自定义的文件名, 以及一些媒体文件打开方式。所以这是与邮件内容直接相关的一个协议。
      • 而S/MIME (Secure Multipurpose Internet Mail Extensions)是对MIME 在安全方面的扩展。它可以把MIME 实体(比如数字签名和加密信息等)封装成安全对象。增强安全服务, 例如具有接收方确认签收的功能, 这样就可以确保接收者不能否认已经收到过的邮件。还可以用于提供数据保密、完整性保护、认证和鉴定服务等功能。
      • S/MIME 只保护邮件的邮件主体,对头部信息则不进行加密,以便让邮件成功地在发送者和接收者的网关之间传递。
  • 网络规划/设计
    • 利用需求分析和现有网络体系分析的结果来设计逻辑网络结构,最后得到一份逻辑网络设计文档,输出内容包括以下几点:
      • 1、逻辑网络设计图
      • 2、IP 地址方案
      • 3、安全方案
      • 4、招聘和培训网络员工的具体说明
      • 5、对软硬件、服务、员工和培训的费用初步估计
    • 物理网络设计是对逻辑网络设计的物理实现, 通过对设备的具体物理分布、运行环境等确定,确保网络的物理连接符合逻辑连接的要求。输出如下内容:
      • 1、网络物理结构图和布线方案
      • 2、设备和部件的详细列表清单
      • 3、软硬件和安装费用的估算
      • 4、安装日程表,详细说明服务的时间以及期限
      • 5、安装后的测试计划
      • 6、用户的培训计划
    • 层次化路由的含义是指对网络拓扑结构和配置的了解是局部的, 一台路由器不需要知道所有的路由信息, 只需要了解其管辖的路由信息, 层次化路由选择需要配合层次化的地址编码。而子网或超网就属于层次化地址编码行为。
    • 网闸
      • 双主机系统,即使外网被黑客攻击瘫痪也无法影响到内网
      • 可以防止外部主动攻击
      • 设备对外网的任何响应都是对内网用户请求的应答
    • 大型局域网三层模型
      • 三层模型将大型局域网划分为核心层、汇聚层和接入层,每一层都有特定的作用。
        • 核心层是因特网络的高速骨干网,由于其重要性,因此在设计中应该采用冗余组件设计。在设计核心层设备的功能时,应尽量避免使用数据包过滤和策略路由等降低数据包转发速率的功能。如果需要连接因特网和外部网络,核心层还应包括一条或多条连接到外部网络的连接。
        • 汇聚层是核心层和接入层之间的分界点,应尽量将资源汸问控制、流量的控制等在汇聚层实现。为保证层次化的特性,汇聚层应该向核心层隐藏接入层的细节,例如不管接入层划分了多少个子网,汇聚层向核心层路由器进行路由宣告时,仅宣告由多个子网地址汇聚而成的网络。为保证核心层能够连接运行不同协议的区域网络,各种协议的转换都应在汇聚层完成。
        • 接入层为用户提供在本地网段i方问应用系统的能力,也要为相邻用户之间的互访需求提供足够的带宽。接入层还应该负责一些用户管理功能,以及户信息的收集工作。
    • 结构化布线系统
      • 分为6个子系统:工作区子系统、水平子系统、管理子系统、干线(或垂直)子系统、设备间子系统和建筑群7系统。其中水平子系统是指各个楼层接线间的配线架到工作区信息插座之间所安装的线缆系统,其作用是将干线子系统与用户工作区连接起来。

5. 软件架构(体系结构)设计

  • 概念
    • 一个体系结构定义一个词汇表一组约束。词汇表中包含一些构件连接件类型, 而这组约束指出系统是如何将这些构件和连接件组合起来的。
    • 根据基于软件架构的设计的定义,基于软件架构的设计( Architecture BasedSoftware Development,ABSD)强调由商业、质量和功能需求的组合驱动软件架构设计。它强调采用视角和视图来描述软件架构, 采用用例和质量属性场景来描述需求。进一步来说, 用例描述的是功能需求, 质量属性场景描述的是质量需求(或侧重于非功能需求)。
  • 演化
    • 系统演化的6个步骤
  • 系统需求、非功能性需求
    • 非功能性需求
      • 操作性需求:指用户对系统操作与使用方面的相关需求,如操作的便利性等。
      • 性能需求:指用户对系统响应时间、吞吐量、并发用户数等方面的要求,以达到系统的及时响应和资源的有效利用。
      • 安全性需求:系统为合法用户提供服务并阻止非授权用户使用服务的能力需求。
      • 文化需求:为满足不同人群或种族(文化背景差异)使用系统而形成的系统服务方面的要求。
  • 架构评估
    • 评估方法
    • 质量属性
      • 是软件系统架构评估中所普遍关注的
      • 是架构设计过程中识别出的
      • 质量属性效用树(utility tree)
        • !!!简答题、选择题都是重点!!!
        • 在架构评估过程中,质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。
        • 质量属性效用树是对质量属性进行分类、权衡、分析的架构分析工具,主要关注系统的性能、可用性、可修改性和安全性四个方面。
        • 其实就是把质量属性分配到这四个方面上,画成树
        • 题目中给的不一定都是质量属性,有的是需求!!!
        • 性能
          • 正常负载情况下,系统必须在0.5秒内对用户的车辆查询请求进行响应
          • 查询过程中涉及到的车辆实时视频传输必须保证画面具有600×480的分辨率,20帧/秒的速率
        • 可用性
          • 网络失效后,系统需要在2分钟内发现错误并启用备用系统
          • 系统主站点断电后,需要在3秒内将请求重定向到备用站点
          • 能够连续运行的时间不小于240小时,意外退出后能够在10秒之内自动重启。
        • 可修改性(好改)
          • 在系统升级时,需要保证在20人月内添加一个新的消息处理中间件
          • 更改系统的Web界面接口必须在4人周内完成
          • 集成开发环境具有模块化结构,支持以模块为单位进行调试、测试与发布。
        • 安全性
          • 车辆信息查询功能必须保证99.999%的安全性
          • 用户信息数据库授权必须保证99.999%可用
          • 用户的信用卡支付必须保证99.999%的安全性
          • 支持相关开发数据在云端存储,需要保证在云端存储数据的机密性和完整性。
        • 可测试性
          • 系统需要为后端工程师提供远程调试接口,并支持远程调试
          • 支持应用开发过程中的代码调试功能:开发人员可以设置断点,启动调试,编辑器可以自动卷屏并命中断点,能通过变量监视器查看当前变量取值。
        • 易用性?
          • 经过调研,手机应用开发人员更倾向于使用Windows系统,因此集成开发环境的界面需要与Windows平台上的主流开发工具的界面风格保持一致。
        • 业务需求?
          • 系统升级后用户名要求至少包含8个字符
    • 系统的架构风险、敏感点和权衡点
      • !!!既要记住概念,又要会填空!!!
      • 在架构评估过程中;需要正确识别系统的架构风险、敏感点和权衡点,并进行合理的架构决策。
      • 系统的架构风险、敏感点和权衡点是对质量属性效用树进行分析的主要依据。
      • 系统架构风险
        • 是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
        • 现有架构设计中的支付部分与第三方支付平台紧耦合,当系统需要支持新的支付平台时,这种设计会导致支付部分代码的修改,影响系统的可修改性
      • 敏感点
        • 是指为了实现某种特定的质量属性,一个或多个系统组件所具有的特性。
        • 对交易请求处理时间的要求将影响系统数据传输协议和交易处理过程的设计
      • 权衡点
        • 是指影响多个质量属性,并对多个质量属性来说都是敏感点的系统属性。
        • 系统拟采用新的加密算法,这会提高系统安全性,但同时会降低系统的性能
  • 风格
    • 体系结构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。
    • 软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。
    • 具体分类
      • !!!简答题和论文都会考!!!
      • https://www.cnblogs.com/wintersun/p/4869344.html
      • 面向服务架构(SOA)
        • 主要技术和标准
        • 业务流程执行语言( Business Process Execution Language, BPEL ),也叫业务过程执行语言, 是一种基于XML的,用来描写业务流程的编程语言, 被描写的业务流程的每个单一步骤则由Web服务来实现。BPEL的目标是要实现业务流程定义格式的标准化,使得公司之间可以通过Web服务无缝的进行交互。
        • 是指那些利用契约和消息将功能暴露为服务、消费功能服务的应用。
      • 面向构件的编程
        • 面向构件的编程(Component Oriented Programming ,COP)
          • 需要的基本支持包括多态性(可替代性),模块封装性(高层次信息的隐藏),后期绑定和装载(部署独立性)、安全性(类型和模块安全性)。
          • 概念
            • 构件是一组通常需要同时部署的原子构件。构件和原子构件之间的区别在于, 大多数原子构件永远都不会被单独部署, 尽管它们可以被单独部署。相反, 大多数原子构件都属于一个构件家族,一次部署往往涉及整个家族。
            • 构件(component)也称为组件,是一个功能相对独立的具有可复用价值的软硬件单元。
            • 从传统意义上来讲,构件就是一种可独立开发、具备独立功能的一类软件。它具备有独立性、可重用性、可组装性、可配置性等特点,构件没有大小之分,可通过将几个构件组装成一个新构件。
            • 一个原子构件是一个模块和一组资源。一个模块是不带单独资源的原子构件。
            • 构件是系统中的一个封装了设计与实现,而只披露接口的可更换的部分
          • 构件的特性是:
            • (1)独立部署单元;
            • (2)作为第三方的组装单元;
            • (3)没有(外部的)可见状态。
          • 一个构件可以包含多个类元素, 但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。
          • 构件是解决软件复用的基础,复用的形式可分为垂直式复用和水平式复用。垂直式复用是与领域特性相关的,而水平式复用是一种公用的服务,不予某个特殊领域相关。
          • 对象的特性是:
            • (1)一个实例单元,具有唯一的标志。
            • (2)可能具有状态,此状态外部可见。
            • (3)封装了自己的状态和行为。
          • 基于构件的软件开发中,可以通过不同的途径来获取构件,主要包括以下4种方法:
            • (1) 从现有构件中获得符合要求的构件,直接使用或做适应性修改,得到可复用的构件;
            • (2) 通过遗留工程(Legacy Engineering),将具有潜在复用价值的软件提取出来,得到可复用的构件;
            • (3) 从市场上购买现成的商业构件,BPCOTS(Commercial Off-The-Shell)构件;
            • (4) 开发新的符合要求的构件。
          • 开发构件通常采取3种策略:
            • (1) 分区(partitioning):指的是将问题情景的空间分割成几乎可以独立研究的部分;
            • (2) 抽象(abstraction):是对在给定实践内执行指定计算的软/硬件申.元的一种抽象;
            • (3) 分割(segmentation):是将结构引入构件的行为,支持对行为性质进行时序推理。
          • 当前主流构件标准有:
            • (1) CORBA:由OMG(对象管理集团)制定;
            • (2) COM/DCOM:由Microsoft制定;
            • (3) EJB:由SUN的Java企业Bean制定。
        • CORBA
          • 可移植对象适配器POA的主要作用是在底层传输平台与接收调用并返回结果的对象实现之间进行协调。
          • POA规范引入了伺服对象Servant的概念,使抽象的CORBA对象能和实现该对象功能的具体编程语言实体彻底分离。CORBA对象是作为伺服对象Servant 实现的。
        • Java
          • EJB
          • J2EE 连接器架构Java Connector Architecture JCA 是对J2EE标准集的重要补充。因为它注重的是将Java 程序连接到非Java 程序和软件包中间件的开发。
          • Java 消息服务JMS用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。Java 消息服务是一个与具体平台无关的API。
          • Java 接口描述语言JavaIDL 是Java 2 开发平台中的CORBA功能扩展。JavaIDL 使得利用 OMGID L 能够定义服务对象的基本功能, 并且将 IDL 根据 CORBA规范的要求, 映射到 Java语言,并以此开发出标准的具有互操作性和可连接性的分布式应用。
      • MVC与EJB构件
        • MVC架构风格最初是Smalltalk-80中用来构建用户界面时采用的架构设计风格。其中M代表模型(Model),V代表视图(View),C代表控制器(Controller)。在该风格中,模型表示待展示的对象,视图表示模型的展示,控制器负责把用户的动作转成针对模型的操作。模型通过更新视图的数据来反映自身的变化。
        • 在本系统中,模型(M)代表监控组件、视图(V)代表控制终端、控制器(C)代表管理模块。
      • 扩展接口模式结构
        • 扩展接口模式结构通常包含四个角色:基础接口、组件、扩展接口和客户端。其中每个扩展接口需要通过扩展基础接口获得基本操作能力,然后加入自己特有的操作接口,并通过设置全局唯一接口ID对自身接口进行标识;每个具体的组件需要实现扩展接口完成实际操作;客户端不与组件直接交互,而需要通过与扩展接口交互提出调用请求,扩展接口根据请求查找并选择合适的实现组件响应客户端请求。
      • Web系统架构设计
        • 负载均衡
          • 负载均衡机制是大型Web应用解决高负荷访问和大量并发请求时常用的有效解决方法,典型的负载均衡机制包括基于DNS的负载均衡、基于反向代理的负载均衡等。
          • 基于DNS的负载均衡机制与反向代理负载均衡两种机制的基本原理:
            • 基于DNS的负载均衡机制通过DNS服务器实现,通常通过循环复用具有同一域名的多个主机地址的服务器实现负载均衡,可以看出,该机制具有实现简单、容易实施及低成本的特性。
            • 反向代理负载均衡则是将来自Internet的连接请求以反向代理的方式动态转发给内部网络上的多台服务器进行处理,从而达到负载均衡的目的。
          • 从系统执行效率方面讲,基于DNS的负载均衡机制实现简单,但其通常不能区分服务器的差异,也不能反映服务器的当前运行状态。基于反向代理的则可以根据内部服务器的性能差异及实时负载情况进行动态负载均衡,当系统多个Web服务器性能存在明显差异或内部Web服务器出现故障时,负载均衡器可以更快做出响应,从而保证客户端的访问效率。采用基于反向代理的负载均衡机制,可在代理服务器中引入调速缓存机制,对Web服务器返回的静态页面或图片等静态资源进行缓存,由代理服务器承担对原始服务器的静态资源访问请求,从而进一步降低原始Web服务器的负载。
          • 从安全性方面讲,采用基于反向代理的负载均衡机制,代理服务器屏蔽了客户端对真实Web服务器的直接访问,恶意用户无法对真实Web服务器进行攻击,且可以通过代理服务器为原本不安全的客户端与Web服务器之间的连接建立安全通道。因此采用基于反向代理的负载均衡机制可为系统提供更好的安全性保障。
      • 微服务架构
        *** 数据抽象和面向对象风格**
        • 是将应用或系统任务分割成单独、可重用、可自给的对象, 每个对象包含数据,以及与对象相关的行为。
        • 抽象数据类型概念对软件系统有着重要作用,目前软件界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的基础上,数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象,或者说是抽象数据类型的实例。对象是一种被称作管理者的构件,因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。
        • 该架构风格是将应用或系统任务分割成单独、可重用、可自给的对象,每个对象包含数据,以及与对象相关的行为。
      • C2架构/体系结构风格
        • C2 体系结构风格可以概括为:通过连接件绑定在一起按照一组规则运作的并行构件网络。
        • C2风格中的系统组织规则如下。
          • ①系统中的构件和连接件都有一个顶部和一个底部。
          • ②构件的顶部应连接到某连接件的底部,构件的底部则应连接到某连接件的顶部。而构件与构件之间的直接连接是不允许的。
          • ③一个连接件可以和任意数目的其他构件和连接件连接。
          • ④当两个连接件进行直接连接时,必须由其中一个的底部到另一个的顶部。
      • 管道-过滤器
        • 交互方式:顺序结构或有限的循环结构
        • 数据结构:数据流
        • 控制结构:数据流驱动
        • 扩展方法:接口适配
        • 输入某个构件,经过内部处理,产生数据输出的系统,正是管道-过滤器中过滤器的职能,把多个过滤器使用管道相联的风格为管道-过滤器风格。
        • 在管道/过滤器风格的软件体系结构中,每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成,所以在输入被完全消费之前,输出便产生了。因此,这里的构件被称为过滤器,这种风格的连接件就像是数据流传输的管道,将一个过滤器的输出传到另一过滤器的输入。此风格特别重要的过滤器必须是独立的实体,它不能与其他的过滤器共享数据,而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。
        • 例子
          • 一个典型的管道/过滤器体系结构的例子是以Unix shell编写的程序。Unix既提供一种符号,以连接各组成部分(Unix的进程),又提供某种进程运行时机制以实现管道。
          • 另一个著名的例子是传统的编 译器。传统的编译器一直被认为是一种管道系统,在该系统中,一个阶段(包括词法分析、语法分析、语义分析和代码生成)的输出是另一个阶段的输入。
      • 仓库风格/数据仓储
        • 交互方式:星型
        • 数据结构:文件或模型
        • 控制结构:业务功能驱动
        • 扩展方法:模型适配
        • 在仓库风格中,有两种不同的构件:中央数据结构说明当前状态,独立构件在中央数据存储上执行,仓库与构件间的相互作用在系统中会有大的变化。
        • 控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择,则仓库是一传统型数据库;另一方面,若中央数据结构的当前状态触发进程执行的选择,则仓库是一黑板系统。
        • 例子
          • 黑板系统
            • 传统应用是信号处理领域,如语音和模式识别。
            • 语音识别系统是一个十分典型的专家系统,其特点是求解的正确结果不止一个,求解过程比较复杂,需要通过专家知识和反馈逐步得到正确结果。黑板结构特别适合求解这类问题。
            • 黑板架构包括知识源、黑板和控制3个部分。知识源包括若干独立计算的不同单元,提供解决问题的知识,知识源响应黑板上的变化,也只修改黑板。黑板是一个全局数据库,包含解域的全部状态,是知识源互相作用的唯一媒介。知识源响应是通过黑板状态的变化来控制。
            • 黑板通常应用在对于解决问题没有确定性算法的系统中,例如信号处理、问题规划及编译器优化等软件系统的设计中。
          • 松耦合代理数据共享存取
      • 基于事件的隐式调用风格
        • 基于事件的隐式调用风格的思想是构件不直接调用一个过程,而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册,当一个事件被触发,系统自动调用在这个事件中注册的所有过程,这样,一个事件的触发就导致了另一模块中的过程的调用。基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序,甚至不知道哪些过程会被调用,因此,许多隐式调用的系统也包含显式调用作为构件交互的补充形式。
        • 例子
          • 在编程环境中用于集成各种工具
            • 例如在某系 统中,编辑器和变量监视器可以登记相应Debugger的断点事件。当Debugger在断点处停下时,它声明该事件,由系统自动调用处理程序,如编辑程 序可以卷屏到断点,变量监视器刷新变量数值。而Debugger本身只声明事件,并不关心哪些过程会启动,也不关心这些过程做什么处理。
          • 在数据库管理系统中确保数据的一致性约束
          • 在用户界面系统中管理数据
          • 在编辑器中支持语法检查
      • 层次系统风格
        • 层次系统组织成一个层次结构,每一层为上层服务,并作为下层客户。在一些层次系统中,除了一些精心挑选的输出函数外,内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机(在另一些层次系统中层是部分不透明的)。连接件通过决定层间如何交互的协议来定义,拓扑约束包括对相邻层间交互的约束。
        • 这种风格支持基于可增加抽象层的设计。这样,允许将一个复杂问题分解成一个增量步骤序列的实现t由于每一层最多只影响两层,同时只要给相邻层提供相同的接口,允许每层用不同的方法实现,同样为软件重用提供了强大的支持。
        • 例子
          • 层次系统最广泛的应用是分层通信协议。在这一应用领域中,每一层提供一个抽象的功能,作为上层通信的基础。较低的层次定义低层的交互,最低层通常只定义硬件物理连接。
      • 过程控制
        • 其特点是不断采集系统当前状态,与系统中的设定状态进行对比,并通过将当前状态与设定状态进行对比从而进行控制。
      • 规则系统
        • 规则系统比较适合根据外邹事件,以自身状态为基础自动进行处理和动作的场景。
      • 解释器
        • 该软件系统特别强调用户定义系统中对象的关系和行为这一特性,这需要在软件架构层面提供一种运行时的系统行为定义与改变的能力
      • 无服务器架构
      • 事件驱动系统
  • 体系结构文档化过程
    • 体系结构文档化过程的主要输出结果是体系结构规格说明和测试体系结构需求的质量设计说明书这两个文档。软件体系结构的文档要求与软件开发项目中的其他文档是类似的。文档的完整性和质量是软件体系结构成功的关键因素。文档要从使用者的角度进行编写, 必须分发给所有与系统有关的开发人员, 且必须保证开发者手上的文档是最新的。
  • 特定领域软件架构(Domain Specific Software Architecture, DSSA)
    • 参与 DSSA 的人员分为4 种角色:领域专家、领域分析师、领域设计人员、领域实现人员。其基本活动包括领域分析、领域设计和领域实现。
    • 特定领域软件架构(Domain Specific Software Architecture,DSSA)以一个特定问题领域为对象,形成由领域参考模型、参考需求、参考架构等组成的开发基础架构,其n标是支持一个特定领域中多个应用的生成。DSSA的基本活动包括领域分析、领域设计和领域实现。其中领域分析的主要目的是获得领域模型,领域模型描述领域中系统之间共同的需求,即领域需求;领域设计的主要目标是获得DSSA,DSSA描述领域模璀中表示需求的解决方案;领域实现的主要目标是依据领域模型和DSSA开发和组织可重用信息,并对基础软件架构进行实现。参加DSSA的人员可以划分为多种角色,其中领域分析者的任务是控制整个领域分析过程,进行知识获取,将获取的知识组织到领域模型中;领域设计者的任务是根据领域模型和现有系统开发出DSSA,并对DSSA的准确性和一致性进行验证。
  • 架构权衡分析方法(Architecture Tradeoff Analysis Method, ATAM)
    • 架构权衡分析方法是一种系统架构评估方法,主要在系统开发之前,针对性能、可用性、安全性和可修改性等质量属性进行评价和折中。ATAM可以分为4个主要的活动阶段,包括需求收集、架构视图描述、属性模型构造和分析、架构决策与折中,整个评估过程强调以属性作为架构评估的核心概念。
  • 其他

6. 系统建模

  • 结构化程序设计
    • 结构化分析方法的基本思想是自顶向下,逐层分解,把一个大问题分解成若干个小问题,每个小问题再分解成若干个更小的问题。经过逐层分解,每个最低层的问题都是足够简单、容易解决的。
    • 结构化程序设计采用自顶向下、逐步求精及模块化的程序设计方法, 通过顺序、分支和循环三种基本的控制结构可以构造出任何单入口单出口的程序
    • 结构化方法分析模型的核心是数据字典,围绕这个核心,有三个层次的模型,分别是数据模型、功能模型和行为模型(也称为状态模型)。在实际工作中,一般使用E-R图表示数据模型,用DFD表示功能模型,用状态转换图表示行为模型。这三个模型有着密切的关系,它们的建立不具有严格的时序性,而是一个迭代的过程。
    • 数据流图(DFD,Data Flow Diagram)
      • 数据流图(Data Flow Diagram)从数据传递和加工角度,以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程,是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
      • 为了表达数据处理过程的数据加工情况,用一个数据流图往往是不够的。层次结构的数据流图按照系统的层次结构进行逐步分解,并以分层的数据流图反映这种结构关系,能清楚地表达和容易理解整个系统。
      • 顶层DFD、0层、1层
      • 基本元素及作用
        • 数据流图通过外部代理(实体)描述系统与外界之间的数据交互关系,内部的活动通过处理(加工)表示,用数据流描述系统中不同活动之间的数据传输内容和方向,需要持久化存储的数据用数据存储表示,一般用文件系统或者数据库表存储数据
        • (1) External Agent(实体/外部代理):定义位于项目范围之外,但与正在被研发的系统有交互关系的人、部门、外部系统或组织。
        • (2) Process(加工/处理):在输入数据流或条件上执行,或者对输入数据流或条件做出响应的工作。
        • (3) Data Store(数据存储):静止的数据,表示系统中需要保存的数据。
        • (4) Data Flow(数据流):运动中的数据,表示到一个过程的数据输入,或者来自一个过程的数据输出。
      • 数据流图中的(语法)错误包括两类及位置
        • 第一类是逻辑错误,加工节点输入输出不平衡,包括黑洞、灰洞和无输入三种类型
        • 第二类是语法错误,比如数据存储不完整、在数据存储与外部代理之间或者各自之间没有经过加工之间发生数据流等。
      • CRUD(Create\Read\Update\Delete)矩阵
        • 系统建模过程中为了保证数据模型和过程模型的一致性,需要通过数据-过程-CRUD矩阵来实现数据模型和过程模型的同步
        • CRUD(Create\Read\Update\Delete)矩阵用于检查系统建模过程中数据模型和过程模型的一致性,分别表示了加工对于数据的新增、读取、修改和删除四种操作。
  • 面向对象分析与设计
    • 软件架构建模技术
      • UML对系统架构的定义是系统的组织结构,包括系统分解的组成部分,以及它们的关联性、交互机制和指导原则等提供系统设计的信息。具体来说,就是指以下5个系统视图:
        • 逻辑视图。逻辑视图也称为设计视图,它表示了设计模型中在架构方面具有重要意义的部分,即类、子系统、包和用例实现的子集。
        • 进程视图。进程视图是可执行线程和进程作为活动类的建模,它是逻辑视图的一次执行实例,描述了并发与同步结构。
        • 实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。
        • 部署视图。部署视图把构件部署到一组物理节点上,表示软件到硬件的映射和分布结构。
        • 用例视图。用例视图是最基本的需求分析模型。
      • 类似概念的"4+1"视图模型
        • “4+1”视图主要用于描述系统逻辑架构,最早由Philippe Kruchten于1995年提出。
        • 逻辑视图。逻辑视图用于描述设计的对象模型(使用面向对象的设计方法时),并说明系统应该为用户提供哪些服务。
        • 开发视图,描述了在开发环境中软件的静态组织结构。
        • 过/进程视图,捕捉设计的并发和同步特征。
        • 物理视图,描述了软件到硬件的映射,反映了分布式特性。
        • 统一的场景,架构的描述,即所做的各种决定,可以围绕着这四个视图来组织,然后由一些用例(Use Cases)或场景(Scenarios)来说明,从而形成了第五个视图。
          • 静态视图
          • 动态视图
    • 面向对象的分析模型
      • 主要由顶层架构图、用例与用例图、领域概念模型构成。
      • 用例图
        • 用例(use case)
          • 用来描述系统对事件做出响应时所采取的行动。
          • 用例获取是需求分析阶段的主要任务之一
        • 参与者
          • 参与者是指系统以外的,需要使用系统或与系统交互的事物,包括:人或组织、设备、外部系统等。
        • 用例之间是具有相关性的。
          • 包含关系(无条件发生,子用例不独立存在,组合)。当可以从两个或两个以上的用例中提取公共行为时,应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例,而把原始用例称为基本用例或基础用例。
          • 扩展关系(有条件发生,子用例独立存在,分支)。如果一个用例明显地混合了两种或两种以上的不同场景,即根据情况可能发生多种分支,则可以将这个用例分为一个基本用例和一个或多个扩展用例,这样使描述可能更加清晰。
          • 泛化关系(无条件发生,子用例独立存在,继承)。当多个用例共同拥有一种类似的结构和行为的时候,可以将它们的共性抽象成为父用例,其他的用例作为泛化关系中的子用例。在用例的泛化关系中,子用例是父用例的一种特殊形式,子用例继承了父用例所有的结构、行为和关系。
    • 面向对象的设计模型
      • 包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。
      • 类图
        • 使用类图表达类的内部属性和行为,以及类集合之间的交互关系
        • 类之间的关系
          • 关联、聚合(整体与部分的关系,整体与部分可以分开)、组合(也是整体与部分的关系,但是整体与部分不可以分开)、依赖、泛化、实现(可写可不写,因为实现是接口与类之间的关系,而接口是一种特殊的类)。
          • 依赖关系:一个事物发生变化影响另一个事物。
          • 泛化关系:特殊/一般关系。
          • 关联关系:描述了一组链,链是对象之间的连接。
          • 聚合关系:整体与部分生命周期不同。
          • 组合关系:整体与部分生命周期相同。
          • 实现关系:接口与类之间的关系。
      • 状态图与活动图
        • 两者最大的区别是:状态图侧重于描述行为的结果,而活动图侧重描述行为的动作。其次活动图可描述并发行为,而状态图不能。
        • 状态图
          • 针对复杂对象
          • 采用状态图定义对象的内部行为。
          • 状态图主要用于描述一个对象在其生存期间的动态行为,表现一个对象所经历的状态序列,引起状态转移的事件(event),以及因状态转移而伴随的动作(action)。
          • 注意系统控制中的所有状态以及状态间的转换条件
        • 活动图
          • 用以描述流程化处理过程
          • 活动图可以用于描述系统的工作流程和并发行为。活动图其实可看作状态图的特殊形式,活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的转移可能需要事件的触发)。
          • 泳道活动图,是将一个活动图中的活动状态进行分组,每一组表示一个特定的类或者对象,它们负责完成组内的活动。每个活动都明确属于一个泳道,不可以跨越泳道,而转移则可以跨越泳道。
  • 软件/信息系统建模方法

7. 软件工程

  • 软件设计
    • 软件设计活动包括4个活动:数据设计,软件结构设计,人机界面设计,过程设计
      • 软件设计包括了四个既独立又相互联系的活动:高质量的(数据设计?)将改善程序结构和模块划分,降低过程复杂性;(软件结构设计)的主要目标是开发一个模块化的程序结构,并表示出模块间的控制关系;(人机界面设计)描述了软件与用户之间的交互关系。
    • 软件设计分为概要设计和详细设计两个阶段。
    • 软件概要设计
      • 包括设计软件的结构、确定系统功能模块及其相互关系,主要采用(模块结构图、层次图和HIPO图)描述程序的结构。
  • 软件重用
    • 软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。
    • 软件元素
      • 软件元素包括需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识等。对于新的软件开发项目而言,它们或者是构成整个目标软件系统的部件,或者在软件开发过程中发挥某种作用。通常将这些软件元素称为软部件。
      • 可重用的软件元素包括程序代码、测试用例、设计文档、设计过程、需球分析文档甚至领域知识。通常,可重用的元素也称作软构件,可重用的软构件越大,重用的粒度越大。
  • 可修改性(Modifiability)
    • 是指能够快速地以较高的行价比对系统变更的能力。可修改性包含可维护性、可扩展性、结构重组、可移植性4个方面。
  • 软件维护
    • 在系统运行过程中,软件需要维护的原因是多样的。根据维护的原因不同,可以将软件维护分为以下4种:
      • 改正性维护。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用,应当进行的诊断和改正错误的过程称为改正性维护。
      • 适应性维护。在使用过程中,外部环境(新的硬、软件配置)、数据环境(数据库、数据格式、数据输入/输出方法、数据存储介质)可能发生变化。为使软件适应这种变化而修改软件的过程称为适用性维护。
      • 完善性维护。在软件的使用过程中,用户往往会对软件提出新的功能与性能要求。为了满足这些要求,需要修改或再开发软件,以扩充软件功能、增强软件性能、改进加工效率、提髙软件的可维护性。这种情况下进行的维护活动成为完善性维护。
      • 预防性维护。指预先提髙软件的可维护性、可靠性等,为以后进一步改进软件打下良好基础。采用先进的软件工程方法对需要维护的软件或软件中的某一部分(重新)进行设计、编码和测试。
  • 设计模式
    • 设计模式描述了一个出现在特定设计语境中的设计再现问题,并为它的解决方案提供了一个经过充分验证的通用方案,不同的设计模式关注解决不同的问题。
    • 设计模式基于面向对象技术,是人们在长期的开发实践中良好经验的结晶,提供了一个简单、统一的描述方法, 使得人们可以复用这些软件设计办法、过程管理经验。
    • 按设计模式的目的,可划分为创建型、结构型、行为型;
      • 创建型
        • 通过采用抽象类所定义的接口,封装了系统中对象如何创建、组合等信息
        • 模式五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式;
        • Singleton
      • 结构型模式
        • 用于如何组合已有的类和对象以获得更大的结构
        • 七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式;
        • Bridge
          • 它的特点是实现接口与实现分离
          • 将抽象部分与它的实现部分分离,使它们都可以独立地变化。
          • 它是一种对象结构型模式,又称为柄体(Handle and Body)模式或接口(Interface)模式。
          • 桥接模式类似于多重继承方案,但是多重继承方案往往违背了类的单一职责原则,其复用性比较差,桥接模式是比多重继承方案更好的解决方法。
          • 适用场景
            • 不希望在抽象以及抽象的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为,在程序运行时刻可以选择或切换实现部分;
            • 类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充,使用Bridge模式可以对不同的抽象接口和实现部分进行组合,并分别对它们进行扩充。
            • 对一个抽象的实现部分的修改应该对用户不产生影响,即客户的代码不必重新编译。
          • 组成
            • Abstraction定义抽象类的接口;维护一个指向Implementor类型对象的指针。
            • RefinedAbstraction扩充由Abstraction定义的接口。
            • Implementor定义实现类的接口,该接口不一定要与Abstraction的接口完全一致; 事实上这两个接口可以完全不同。一般来说,Implementor接口仅提供基本操作,而Abstraction则定义了基于这些基本操作的较高层次的操作。
            • Concretelmplementor实现Implementor接口并定义它的具体实现。
      • 行为型模式
        • 用于对象之间的职责及其提供服务的分配方式
        • 十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
        • Memento
        • 解释器
          • 属于类的行为模式,描述了如何为语言定义一个文法,如何在该语言中表示一个句子,以及如何解释这些句子,这里的“语言”是使用规定格式和语法的代码。
        • 策略模式
          • 是一种对象的行为型模式,定义一系列算法,并将每个算法封装起来,并让它们可以相互替换。
          • 策略模式让算法独立于使用它的客户而变化,其目的是将行为和环境分隔,当出现新的行为时,只需要实现新的策略类。
        • 中介者(Mediator)
          • 适用场景:一组对象以定义良好但是复杂的方式进行通信,产生的相互依赖关系结构混乱且难以理解。
          • 中介者模式是一种对象的行为行模式,通过一个中介对象来封装一系列的对象交互。
          • 中介者使得各对象不需要现实地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。
          • 中介者对象的存在保证了对象结构上的稳定,也就说说系统的结构不会因为新对象的引入带来人量的修改工作。
        • 迭代器
          • 是一种对象的行为型模式,提供了一种方法来访问聚合对象,而不用暴露这个对象的内部表示。
          • 迭代器模式支持以不同的方式遍历一个聚合对象。
    • 面向对象设计的原则
      • 依赖倒置原则
        • 是指抽象不应该依赖予细节,细节应该依赖于抽象,即应针对接口编程,而不是针对实现编程
  • 系统工程
    • 系统工程利用计算机作为工具,对系统的结构、元素、(信息)和反馈等进行分析,以达到最优规划、最优设计、最优管理和最优控制的目的。
    • 霍尔(A.D. Hall)于1969年提出了系统方法的三维结构体系,通常称为霍尔三维结构,这是系统工程方法论的基础。霍尔三维结构以时间维、逻辑维、知识维组成的立体结构概括性地表示出系统工程的各阶段、各步骤以及所涉及的知识范围。
      • 其中时间维是系统的工作进程,对于一个具体的工程项目,可以分为7个阶段,在研制阶段会做出研制方案及生产计划。
  • 系统构建
    • 系统移植
      • 系统移植也是系统构建的一种实现方法,在移植工作中,计划阶段需要最终确定移植方法。
      • 移植工作大体上分为计划阶段、准备阶段、转换阶段、测试阶段、验证阶段。
        • 1、计划阶段,在计划阶段,要进行现有系统的调查整理,从移植技术、系统内容(是否进行系统提炼等)、系统运行三个方面,探讨如何转换成新系统,决定移植方法,确立移植工作体制及移植日程。
        • 2、准备阶段,在准备阶段要进行移植方面的研究,准备转换所需的资料。该阶段的作业质量将对以后的生产效率产生很大的影响。
        • 3、转换阶段,这一阶段是将程序设计和数据转换成新机器能根据需要工作的阶段。提高转换工作的精度, 减轻下一阶段的测试负担是提高移植工作效率的基本内容。
        • 4、测试阶段,这一阶段是进行程序单元、工作单元测试的阶段。在本阶段要核实程序能否在新系统中准确地工作。所以,当有不能准确工作的程序时, 就要回到转换阶段重新工作。
        • 5、验证阶段,这是测试完的程序使新系统工作,最后核实系统,准备正式运行的阶段。
  • 逆向工程、再工程、设计恢复等
    • 所谓软件的逆向工程就是分析已有的程序,寻求比源代码更高级的抽象表现形式。一般认为,凡是在软件生命周期内将软件某种形式的描述转换成更为抽象形式的活动都可称为逆向工程。
    • 重构( restructuring),指在同一抽象级别上转换系统描述形式;
    • 设计恢复( design recovery),指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计的信息(不一定是原设计);
    • 再工程( re-engineering),也称修复和改造工程,它是在逆向工程所获信息的基础上修改或重构已有的系统,产生系统的一个新版本。
  • 界面设计
    • 用户界面设计的基本原则是从实践中总结出来的一些设计规则。Theo Maiidel在他的界面设计著作中提出3条“黄金规则”:
      • 让用户拥有控制权。用户希望控制计算机,而不是被计算机控制,因此在设计人机界面时应遵循以下原则:交互模式的定义不能强迫用户进入不必要的或不希望的动作的方式;提供灵活的交互;允许用户交互可以被中断和撤销;当技能级別增长时可以使交互流水化并允许定制交互;使用户隔离内部技术细节。
      • 减少用户的记忆负担。要求用户记住的东西越多,与系统交互时出错的可能也越大,因此好的用户界面设计不应加重用户的记忆负担。减少用户记忆负担的设计原则为:减少对短期记忆的要求;建立有意义的默认值;定义直觉性的捷径;界面的视觉布局应该基于真实世界的隐喻;以不断进展的方式祸示信息。
      • 保持界面一致。用户应该以一致的方式展示和获取信息,这意味着:所有可视信息的组织遵循统一的设计标准,所有屏幕显示都遵守该标准。输入机制被约束到有限的集合内,在整个软件系统中被一致地使用,同时从任务到任务的导航机制也被一致地定义和实现。保持界面一致性的设计原则包括以下内容:允许用户将当前任务放在有意义的语境中;在应用系列内保持一致性;不要改变用户己经熟悉的用户交互模型。
  • 测试
    • 动态测试和静态测试
      • 动态测试(也可分为边界值分析、逻辑覆盖、基本路径)
        • 通过运行程序发现错误,包括(边界值分析、逻辑覆盖、基本路径)等方法
        • 黑盒测试法
        • 白盒测试法
        • 灰盒测试法
      • 静态测试
        • 采用人工和计算机辅助静态分析的手段对程序进行检测,包括桌面检查、代码审查、代码走查等方法。
          • 桌面检查(Desk Checking)
          • 代码审查
          • 代码走查
        • 静态测试是指被测试程序不在机器上运行,而采用人工检测和计算机辅助静态分析的手段对程序进行检测。
        • 静态测试包括对文档的静态测试和对代码的静态测试。
        • 对代码的静态测试包括控制流分析、数据流分析、接口分析和表达式分析。
          • 控制流分析。控制流分析是指使用控制流程图检査被测程序控制结构的过程。例如,可检查被测程序是否存在没有使用的语句或子程序、是否调用并不存在的子程序,以及是否存在无法达到的语句等。
          • 数据流分析。数据流分析是指使用控制流程图分析数据各种异常情况的过程,包括数据初始化、賦值或引用过程中的异常。例如,引用未定义的变量、对以前未使用的变量再次陚值等程序差错或异常情况。
          • 接口分析。接口分析主要包括模块之间接口的一致性分析、模块与外部数据库及其他软件配置项之间的一致性分析、子程序和函数之间的接口一致性分析等。例如可以检查函数形参与实现的数量、顺序、类型和使用的一致性。
          • 表达式分析。表达式分析用于检查程序代码中的表达式错误。例如,括号不配对、数组引用越界、除数为零,以及浮点数变量比较时的误差等错误。
    • 根据国家标准GB/T15532-2008,软件测试可分为单元测试、集成测试、配置项测试、系统测试、验收测试和回归测试等类别。
      • 单元测试
        • 单元测试也称为模块测试,测试的对象是可独立编译或汇编的程序模块、软件构件或面向对象软件中的类(统称为模块),其目的是检查每个模块能否正确地实现设计说明中的功能、性能、接口和其他设计约束等条件,发现模块内可能存在的各种差错。
        • 单元测试的技术依据是软件详细设计说明书。
        • 测试一个模块时,可能需要为该模块编写一个驱动模块和若干个桩模块。驱动模块用来凋用被测模块,它接收测试者提供的测试数据,并把这些数据传送给被测模块,然后从被测模块接收测试结果,并以某种可见的方式将测试结果返回给测试人员;桩模块用來模拟被测模块所调用的子模块,它接受被测模块的调用,检验调用参数,并以尽町能简单的操作模拟被调用的子程序模块功能,把结果送回被测模块。顶层模块测试时不需要驱动模块,底层模块测试时不要桩模块。
        • 单元测试策略主要包括自顶向下的单元测试、自底向上的单元测试、孤立测试和综合测试策略。
          • 自顶向下的单元测试先测试上层模块,再测试下层模块。测试下层模块时由于它的上层模块已测试过,所以不必另外编写驱动模块。
          • 自底向上的单元测试。自底向上的单元测试先测试下层模块,再测试上层模块。测试上层模块由于它的下层模块己经测试过,所以不必另外编写桩模块。
          • 孤立测试不需要考虑每个模块与其他模块之间的关系,逐一完成所有模块的测试。由于各模块之间不存在依赖性,单元测试可以并行进行,但因为需要为每个模块单独设计驱动模块和桩模块,增加了额外的测试成本。
          • 综合测试。上述三种单元测试策略各有利弊,实际测试时可以根据软件特点和进度安排情况,将几种测试方法混合使用。
      • 集成测试
        • 也称为组装测试、联合测试。它将已通过单元测试的模块集成在一起, 主要测试模块之间的协作性。
        • 集成测试的目的是检查模块之间,以及模块和己集成的软件之间的接口关系,并验证已集成的软件是否符合设计要求。
        • 从组装策略而言, 可以分为一次性组装和增量式组装。
        • 集成测试计划通常是在软件概要设计阶段完成,集成测试一般采用黑盒测试方法。
    • 系统测试
      • 对象是完整的、集成的计算机系统,系统测试的目的是在真实系统工作环境下,验证完整的软件配置项能否和系统正确连接,并满足系统/子系统设计文档和软件开发合同规定的要求。
      • 系统测试的技术依据是用户需求或开发合同
    • 配置项测试
      • 对象是软件配置项,配置项测试的目的是检验软件配置项与软件需求规格说明的一致性。
    • 确认测试
      • 软件确认测试也称为有效性测试,一种针对需求的测试,是用户参与的测试。
      • 它主要验证软件功能、性能及其它特性是否与用户需求一致。
      • 确认测试计划通常是在需求分析阶段完成的。
      • 根据用户的参与程度不同,软件确认测试包括:内部确认测试、Alpha、Beta和验收测试
    • 验收测试
      • 指针对软件需求规格说明,在交付前以用户为主进行的测试。
    • 回归测试
      • 目的是测试软件变更之后,变更部分的正确性和对变更需求的复合型,以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。
  • 软件调试与软件测试
    • 软件测试在将软件交付给客户之前所必须完成的重要步骤。
    • 软件调试(排错)与成功的测试形影相随。
    • 测试成功的标志是发现了错误,根据错误迹象确定错误的原因和准确位置,并加以改正,主要依靠软件调试技术。
    • 软件调试与软件测试区别主要体现在以下几个方面:
      • ①测试的目的是找出存在的错误,而调试的目的是定位错误并修改程序以修正错误;
      • ②调试是测试之后的活动,测试和调试在目标、方法和思路上都有所不同;
      • ③测试从一个已知的条件开始,使用预先定义的过程,有预知的结果;调试从一个未知的条件开始,结束的过程不可预计;
      • ④测试过程可以实现设计,进度可以实现确定;而调试不能描述过程或持续时间。

8. 项目管理

  • 项目范围管理
    • 项目范围是为了达到项目目标,为了交付具有某种特制的产品和服务,项目所规定要做的。
    • 在信息系统项目中,产品范围是指信息系统产品或者服务所应该包含的功能,项目范围是指为了能够交付信息系统项目所必须做的工作。
    • 产品范围是项目范围的基础,产品的范围定义是信息系统要求的度量,而项目范围的定义是生产项目计划的基础。
    • 项目范围说明书
      • 在初步项目范围说明书中已文档化的主要的可交付物、假设和约束条件的基础上准备详细的项目范围说明书, 是项目成功的关键。
      • 产品范围描述是项目范围说明书的重要组成部分。
    • 范围定义的输入包括以下内容:
      • 项目章程。如果项目章程或初始的范围说明书没有在项目执行组织中使用,同样的信息需要进一步收集和开发,以产生详细的项目范围说明书。
      • 项目范围管理计划。
      • 组织过程资产。
      • 批准的变更申请。
  • 项目成本管理
    • 项目成本管理的几个主要过程是:
      • 成本估算:编制一个为完成项目各活动所需要的资源成本的近似估算。
      • 成本预算:将总的成本估算分配到各项活动或工作包上,来建立一个成本的基线。
      • 成本控制:控制项目预算的变更。
  • 需求管理
    • 理想情况下,每一项用户、业务需求和功能需求都应具备下列性质。
      • 完整性。每一项需求都必须完整地、准确地描述即将交付使用的功能(要开发的功能)。它必须包含开发人员设计和实现这项功能需要的所有信息。
      • 正确性。每一项需求都必须准确地描述将要开发的功能。判断正确性的参考是需求来源,如实际用户和高级的系统需求。如果一项软件需求与其相对应的系统需求发生冲突,这是不正确的。
      • 可行性。需求必须能够在系统及其运行环境的已知能力和约束条件内实现。
      • 必要性。每一项需求记录的功能都必须是用户的真正需要,或者是为符合外部系统需求或标准而必须具备的功能。每项需求都必须来源于有权定义需求的一方。对每项需求都必须追溯至特定的客户需求的来源,例如用例、业务规则或者其他来源。
      • 有优先次序。为每一项功能需求、特性或用例指定一个实现优先级,以表明它在产品的某一版本中的重要程度。如果所有需求都被视为同等重要,项目经理就很难采取措施应对预算削减、进度拖后、人员流失或开发过程中需求增加等情况。
      • 无歧义。一项需求声明对所有读者应该只有一种一致的解释,编写需求时应该使用用户所在领域的、简洁明了的语言。应该在词汇表中列出所有专用的和可能让用户感到迷惑的术语。
      • 可验证性。如果某项需求不可验证,那么判定其实现的正确与否就成了主观臆断,而不是客观分析。不完备、不一致、不可行或有歧义的需求也是不可验证的。
    • 需求变更
      • 需求变更的管理过程一般经过变更申请、变更评估、决策、回复这四大步骤。广义上,变更控制委员会对项目中任何基线工作产品的变更都可做出决定。
      • 在需求管理过程中需求的变更是受严格管控的,其流程为:
        • 1、问题分析和变更描述。这是识别和分析需求问题或者一份明确的变更提议,以检查它的有效性,从而产生一个更明确的需求变更提议。
        • 2、变更分析和成本计算。使用可追溯性信息和系统需求的一般知识,对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且确认, 应该进行是否执行这一变更的决策。
        • 3、变更实现。这要求需求文档和系统设计以及实现都要同时修改。如果先对系统的程序做变更, 然后再修改需求文档, 这几乎不可避免地会出现需求文档和程序的不一致。
  • 项目时间管理
    • 过程包括活动定义、活动排序、活动的资源估算、活动历时估算、制定进度计划以及进度控制
  • 项目开发管理
    • 文档
      • 软件文档可归入三种类别:开发文档(描述开发过程本身)、产品文档(描述开发过程的产物)、管理文档(记录项目管理的信息)
      • 需求文档、设计文档、源代码、测试用例属于产品组成部分的工作成果,工作计划、项目质量报告、项目跟踪报告属于项目管理和机构支撑过程域产生的文档。
      • 用户文档主要描述系统功能和使用方法。
        • 操作员指南属于用户文档。
      • 系统文档描述系统设计、实现、测试等各方面内容。
    • 开发模型、方法
      • 软件过程模型
        • 软件过程模型的基本概念: 软件过程是制作软件产品的一组活动以及结果, 这些活动主要由软件人员来完成,软件活动主要有:
          • (1) 软件描述。必须定义软件功能以及使用的限制。
          • (2) 软件开发。也就是软件的设计和实现,软件工程人员制作出能满足描述的软件。
          • (3) 软件有效性验证。软件必须经过严格的验证,以保证能够满足客户的需求。
          • (4) 软件进化。软件随着客户需求的变化不断地改进。
      • 瀑布模型
        • 特点是因果关系紧密相连, 前一个阶段工作的结果是后一个阶段工作的输入。或者说, 每一个阶段都是建筑在前一个阶段正确结果之上, 前一个阶段的错漏会隐蔽地带到后一个阶段。这种错误有时甚至可能是灾难性的。因此每一个阶段工作完成后,都要进行审查和确认,这是非常重要的。历史上,瀑布模型起到了重要作用, 它的出现有利于人员的组织管理, 有利于软件开发方法和工具的研究。
      • 螺旋模型
        • 将瀑布模型和变换(原型?)模型相结合, 综合两者的有点, 并增加了风险分析。它以原型模型为基础,沿着螺线自内向外旋转,每旋转一圈都要经过制定计划、风险分析、实施工程及客户评价等活动。
        • (螺旋模型)把整个软件开发流程分成多个阶段, 每一个阶段都由目标设定、风险分析、开发和有效性验证以及评审构成。
      • 原型模型
        • 软件开发过程模型中,(原型模型)主要由原型开发阶段和目标软件开发阶段构成。
      • 快速应用开发(RAD)
        • 系统模块化程度较高时,更适合于采用(快速应用开发)方法,该方法通过使用基于构件的开发方法获得快速开发。
      • RUP
        • RUP将项目管理、业务建模、分析与设计等统一起来,贯穿整个开发过程。
        • RUP中的软件过程在时间上被分解为4个顺序的阶段,分别是初始阶段、细化阶段、构建阶段和移交阶段。每个阶段结束时都要安排一次技术评审,以确定这个阶段的目标是否已经满足。如果评审结果令人满意,就可以允许项目进入下一个阶段。
        • 可以看出,基于RUP的软件过程是一个迭代和增量的过程。通过初始、细化、构建和移交4个阶段就是一个开发周期,每次经过这4个阶段就会产生一代软件。除非产品退役,否则通过重复同样的4个阶段,产品将演化为下一代产品,但每一次的侧重点都将放在不同的阶段上。
        • 这样做的好处是在软件开发的早期就可以对关键的、影响大的风险进行处理。
      • 敏捷方法
        • 极限编程是著名的敏捷开发方法
        • 与RUP相比,敏捷方法的周期可能更短。敏捷方法在几周或者几个月的时间内完成相对较小的功能,强调的是能尽早将尽量小的可用的功能交付使用,并在整个项目周期中持续改善和增强,并且更加强调团队中的高度写作。
        • 敏捷方法的核心思想主要有以下三点。
          • 敏捷型方法是"适应性"而非"预设性"。传统方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划,然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷方法则欢迎变化,其实它的目的就是成为适应变化的过程,甚至能允许改变自身来适应变化。
          • 敏捷方法是以人为本,而不是以过程为本。传统方法以过程为本,强调充分发挥人的特性,不去限制它,并且软件开发在无过程控制和过于严格繁琐的过程控制中取得一种平衡,以保证软件的质量。
          • 迭代增量式的幵发过程。敏捷方法以原型开发思想为基础,采用迭代增最式开发,发行版本小型化。
        • 敏捷方法主要适合于以下场合:
          • 项目团队的人数不能太多,适合于规模较小的项目。
          • 项目经常发生变更。敏捷方法适用于需求萌动并且快速改变的情况,如果系统有比较高的关键性、可靠性、安全性方面的要求,则可能不完全适合。
          • 高风险项目的实施。
          • 从组织结构的角度看,组织结构的文化、人员、沟通性决定了敏捷方法是否使用。
      • 水晶系列( Crystal )开发方法
        • 适用于程序开发人员在地域上分布很广的开发团队。
      • 功用驱动开发方法( FDD)
        • 在FDD中,编程开发人员分成两类:首席程序员和类程序员(class owner)。首席程序员是最富有经验的开发人员,他们是项目的协调者、设计者和指导者,而“类”程序员则主要做源码编写。
  • 项目配置管理
    • 配置管理SCM是一种标识、组织和控制修改的技术, 目的是使错误降为最小并最有效地提高生产效率。
      • 并不简简单单的是一个产品在其生命周期各个阶段所产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合
    • 配置项是构成产品配置的主要元素,配置项主要有以下两大类:
      • (1)属于产品组成部分的工作成果:如需求文档、设计文档、源代码和测试用例等;
      • (2)属于项目管理和机构支撑过程域产生的文档:如工作计划、项目质量报告和项目跟踪报告等。这些文档虽然不是产品的组成部分, 但是值得保存。所以设备清单不属于配置项。所以选项C的工作计划虽可充当配置项, 但不属于产品组成部分工作成果的配置项。
    • 在配置管理中,所有的配置项都应列入版本控制的范畴。配置项的状态通常有3种,分别是草稿、正式发布和正在修改
    • 版本控制软件提供完备的版本管理功能,用于存储、追踪目录(文件夹)和文件的修改历史, 是软件开发者的必备工具, 是软件公司的基础设施。版本控制软件的最高目标,是支持软件公司的配置管理活动, 追踪多个版本的开发和维护活动,及时发布软件。SCCS是元老级的版本控制软件,也叫配置管理软件。
  • 软件系统工具
    • 软件系统工具的种类繁多, 很难有统一的分类方法。通常可以按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。
      • 软件开发工具:需求分析工具、设计工具、编码与排错工具。
      • 软件维护工具版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
      • 软件管理和软件支持工具:项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。
  • CMM
    • 能力成熟度模型( Capacity Maturity Model )在软件开发机构中被广泛用来指导软件过程改进。
    • CMM/CMMI将软件过程的成熟度分为5个等级(还有一个0级其实就是未实施CMM时的)
      • CL0:未完成的
      • CL1:已执行的
      • CL2:已管理的
      • CL3:已定义(级)的
      • CL4:定量管理的
      • CL5:优化的
  • 集成机制
    • 对工具的集成及用户软件的开发、维护及管理提供统一的支持。按功能可以划分为三个部分:
      • 环境信息库
      • 过程控制和消息服务器
      • 环境用户界面

9. 系统配置与性能评价

  • 基准测试是指通过设计科学的测试方法、测试工具和测试系统, 实现对一类测试对象的某项性能指标进行定量的和可对比的测试。
    • 在大多数情况下,为测试新系统的性能,用户必须依靠评价程序来评价机器的性能。对于真实程序、核心程序、小型基准程序和合成基准程序来说,其评测程度依次递减。
    • 把应用程序中用的最多、最频繁的那部分核心程序作为评价计算机性能的标准程序,称为基准测试程序(Benchmark)
    • 事务处理性能委员会(Transaction Processing Performance Council,TPC)是制定商务应用基准程序(Benchmark)标准规范、性能和价格度量,并管理测试结果发布的非营利组织,其发布的TPC-C是在线事务处理的基准程序,TPC-D是决策支持的基准程序。
  • 性能指标,是软、硬件的性能指标的集成。在硬件中,包括计算机、各种通信交换设备、各类网络设备等;在软件中,包括:操作系统、协议以及应用程序等。
    • 1、计算机
      • 对计算机评价的主要性能指标有:时钟频率(主频);运算速度;运算精度;内存的存储容量;存储器的存取周期;数据处理速率PDR(processingdatarate);吞吐率;各种响应时间;各种利用率; RASIS特性(即:可靠性Reliability、可用性Availability、可维护性Sericeability、完整性和安全性Integraity and Security);平均故障响应时间;兼容性;可扩充性;性能价格比。
      • 对计算机评价的主要性能指标有时钟频率、(数据处理速率)、运算精度和内存容量等。
    • 2、路由器
      • 对路由器评价的主要性能指标有: 设备吞吐量、端口吞吐量、全双工线速转发能力、背靠背帧数、路由表能力、背板能力、丢包率、时延、时延抖动、VPN支持能力、内部时钟精度、队列管理机制、端口硬件队列数、分类业务带宽保证、RSVP、IP Diff Serv、CAR支持、冗余、热插拔组件、路由器冗余协议、网管、基于Web的管理、网管类型、带外网管支持、网管粒度、计费能力/协议、分组语音支持方式、协议支持、语音压缩能力、端口密度、信令支持。
    • 3、交换机
      • 对交换机评价的主要性能指标有:交换机类型、配置、支持的网络类型、最大ATM端口数、最大SONET端口数、最大FDDI端口数、背板吞吐量、缓冲区大小、最大MAC地址表大小、最大电源数、支持协议和标准、路由信息协议RIP、RIP2、开放式最短路径优先第2 版、边界网关协议BGP、无类域间路由CIDR、互联网成组管理协议IGMP、距离矢量多播路由协议DVMRP、开放式最短路径优先多播路由协议MOSPF、协议无关的多播协议PIM、资源预留协议RSVP、802.1p 优先级标记,多队列、路由、支持第3 层交换、支持多层( 4 到7 层交换、支持多协议路由、支持路由缓存、可支持最大路由表数、VLAN、最大VLAN数量、网管、支持网管类型、支持端口镜像、QoS、支持基于策略的第2 层交换、每端口最大优先级队列数、支持基于策略的第3 层交换、支持基于策略的应用级QoS、支持最小/最大带宽分配、冗余、热交换组件(管理卡, 交换结构, 接口模块, 电源,冷却系统、支持端口链路聚集协议、负载均衡。
    • 4、网络
      • 评价网络的性能指标有:设备级性能指标;网络级性能指标;应用级性能指标;用户级性能指标;吞吐量。
    • 5、操作系统
      • 评价操作系统的性能指标有:系统的可靠性、系统的吞吐率(量)、系统响应时间、系统资源利用率、可移植性。
    • 6、数据库管理系统
      • 衡量数据库管理系统的主要性能指标包括数据库本身和管理系统两部分, 有:数据库的大小、数据库中表的数量、单个表的大小、表中允许的记录(行)数量、单个记录(行)的大小、表上所允许的索引数量、数据库所允许的索引数量、最大并发事务处理能力、负载均衡能力、最大连接数等等。
      • 对于数据库系统,主要包括CPU/内存使用状况、(查询语句性能)、进程/线程使用状态、日志文件大小等。
      • 对数据库管理系统评价的主要性能指标有(最大连接数)、数据库所允许的索引数量和最大并发实物处理能力等。
    • 7、WEB服务器
      • 评价Web 服务器的主要性能指标有:最大并发连接数、响应延迟、吞吐量。
      • 作为承载Web应用的Web服务器, 对其进行性能评估时, 主要关注最大并发连接数、响应延迟、吞吐量等指标。相对来说,对个别数据的丢包率并不是很关心。
      • 对于应用系统,主要包括应用系统的可用性、响应时间、(并发用户数)、特定应用资源占用等。

10. 系统可靠性分析与设计

  • 定义
    • 系统在规定的时间内及规定的环境条件下,完成规定功能的能力,就是系统无故障运行的概率。
  • 系统可靠性的4个子特性
    • 根据国家标准《软件工程产品质量第1部分:质量模型》(GB/T16260.1—2006)的规定,系统可靠性包括:成熟性、容错性、易恢复性和可靠性的依从性4个子特性。
      • 成熟性(不挂):成熟性是指系统避免因错误的发生而导致失效的能力;
      • 容错性(看起来正常):容错性是指在系统发生故障或违反指定接口的情况下,系统维持规定的性能级别的能力;
      • 易恢复性:易恢复性是指系统发生失效的情况下,重建规定的性能级别并恢复受直接影响的数据的能力;
      • 依从性:可靠性的依从性是指系统依附于与可靠性相关的标准、约定或规定的能力。
  • 软件的错误(Error)、缺陷(Defect)、故障(Fault)和失效(Failure)
  • 出现阶段
  • 表现形式
  • 硬件可靠性特征与其对应的软件可靠性特征之间的差异或相似之处
    • (1) 从硬件角度分析,由于硬件一旦生产完成,其可靠性指标将会随着使用时间延长而逐步老化,从而带来可靠性降低,即呈现失效率服从浴缸曲线;而软件不存在随时间延长而老化的现象,因此,在不考虑软件演化的情况下,失效率在统计上是非增的。
    • (2) 由于硬件是由多种电子器件组成,即使不使用,材料劣化也会导致失效;而软件就不同了,软件一旦调试完成,固化到设备中,在不考虑存储介质的老化因素的前提下,即使不使用该软件,软件也永远不会发生失效。
    • (3) 由于硬件存在可更换性,其硬件通过维修,可恢复原始状态;而对于软件而言,一旦需要维护,必然是存在需求更改、程序存在bug等现象,其维护必然会创建新的软件代码。
    • (4) 一般而言,硬件失效存在一个发展过程,在发生故障之前必然会有报警现象出现,而软件失效之前很少会有警告。
  • 目前比较主流的可靠性设计技术
    • 提高系统可靠性一般采用以下4类技术:
      • (1) 冗余技术;
      • (2) 软件容错技术;
      • (3) 双机容错技术;
      • (4) 集群技术。
    • 软件的可靠性设计主要包括了恢复块和N版本程序设计两种方法
      • 恢复块方法是一种反向恢复的方法,其核心原理是:对于可靠性要求高的软件,在程序运行的某时刻,将数据或程序进行备份,一旦发现主程序块有异常发生时,可将已备份的数据或程序进行恢复,保证程序的正确性。
        • 反向恢复
        • 验证测试程序
        • 单机
        • 组成
          • 主块
          • 后备块
          • 验证测试
          • 输出正确结果
          • 异常处理(最后还不合格的话)
      • N版本的工作原理是向前恢复
        • 向前恢复
        • 表决
        • 多机
        • 组成
      • 比较
        • 硬件运行环境:恢复块方法的使用必然是单机环境,而N版本方法必然要使用多机环境
        • 恢复策略:N版本的工作原理是向前恢复,恢复快则是反向恢复((6)空);
        • 错误检测方法:恢复块方法的错误检测方法是验证测试程序,而N版本方法的错误检测方法是表决
        • 实时性:由于恢复快方法是反复寻找正确的备份块,而N版本方法则是多个机器同时计算同样内容,表决完后即可给出正确结果,这样,恢复快方法相比N版本方法显然实时性差((7)空),而N版本方法显然好((8)空)于恢复快方法。
  • 软件可靠性评价
  • 影响软件可靠性的主要因素
  • 基本原则
  • 可靠性分析方法
  • 软件可靠性模型的选择

11. 系统安全性与保密性设计

  • 分类
    • 被动攻击
      • 被动攻击主要是收集信息而不是进行访问, 数据的合法用户对这种活动一点也不会觉察到。
      • 在被动攻击(passive attack)中,攻击者的目的只是获取信息,这就意味着攻击者不会篡改信息或危害系统。系统可以不中断其正常运行。
      • 被动攻击包括嗅探、信息收集等攻击方法
      • 被动攻击包括传输报文内容的泄露和通信流量分析
      • 常见的被动攻击包括:窃听和流量分析
    • 主动攻击
      • 主动攻击(active attack)可能改变信息或危害系统。
      • 威胁信息完整性和有效性的攻击就是主动攻击。
      • 主动攻击通常易于探测但却难于防范,因为攻击者可以通过多种方法发起攻击。常见的主动攻击包括:篡改、伪装、重放、拒绝服务攻击
  • 加解密
    • 由于DES 密钥只有56bit ,易于遭受穷举时攻击。三重DES 作为一种替代加密方案,在1985 年成为美国的一个商用加密标准。该方法使用两个密钥,执行三次DES 算法。故两个密钥合起来有效密钥长度有112bit 。
  • 常见攻击
    • SQL注入攻击是指用户通过提交一段数据库查询代码,根据程序返回的结果,获得攻击者想要的数据,这就是所谓的SQL Injection,即SQL注入攻击。这种攻击方式是通过对数据库查询代码和返回结果的分析而实现的。
    • Land攻击是指攻击者将一个包的源地址和目的地址都设置为目标主机的地址,然后将该包通过IP欺骗的方式发送给被攻击主机,这种包可以造成被攻击主机因试图与自己建立连接而陷入死循环,从而很大程度地降低了系统性能。
    • Ping of Death攻击是攻击者向被攻击者发送一个超过65536字节的数据包ping包,由于接收者无法处理这么大的ping包而造成被攻击者系统崩溃、挂机或重启。
    • Teardrop攻击就是利用IP包的分段/重组技术在系统实现中的一个错误,即在组装IP包时只检查了每段数据是否过长,而没有检查包中有效数据的长度是否过小,当数据包中有效数据长度为负值时,系统会分配一个巨大的存储空间,这样的分配会导致系统资源大量消耗,直至重新启动。

12. 数学与经济管理

  • 图论
    • 网络与最大流量
    • 关键路径/路线规划(最好的畅通率/最小的拥堵率)?
      • 先把拥堵率转换成畅通率
      • 原则:每一条路线上的畅通率等于所有各段畅通率之乘积。两点之间的畅通率等于两点之间所有可能路线畅通率的最大值。以下用T(ijk...)表示从点i出发,经过点j、k...等的路线的畅通率。
      • 据此原则, 可以从①开始逐步计算到达各点的最优路线。
  • 线性规划
  • 决策论
    • 不确定型决策 - 最大投资收益/指派问题
      • 先求得投资各公司的收益增加矩阵,再分别求几种分配情况最大收益进行比较。
      • 任一行(或列)各元素都减(或加)一常数后,并不会影响最优解的位置,只是目标值(指派方案的各项总和)也减(或加)了这一常数。我们可以利用这一性质使矩阵更多的元素变成0,其他元素保持正,以利于求解。得到最多的0元素解。
    • 确定型决策/风险决策 - 决策树等
      • 决策树
        • 先画决策树,从左至右逐步画出各个决策分支,并在各分支上标出概率值,再在最右端分别标出年获利值。然后,从右至左,计算并填写各节点处的期望收益。
        • 在右面四个节点处依次按下列算式计算5年的期望值,并将结果分别写在节点处。
        • 再在②、③节点处按如下算式计算2年的期望值(扣除投资额),并将结果(7年总收益)写在节点处。
  • 数学模型
    • 是关于部分现实世界为一定目的而作的抽象的,简化的数学结构。
    • 数学建模是需要在简单性和准确性之间求得平衡
    • 数学模型应该用统一的、普适的标准对其进行评价

13. 法律法规与标准化

  • 在先权利包括著作权、外观设计专利权、商号权、地理标志权、姓名权等。
  • 著作权
    • “自动保护”原则
      • 在我国,著作权采用“自动保护”原则,即软件著作权是自动获得的。
    • 著作权的存在,不以作品原件物质载体的存在为前提,而是依据法定的保护期。
    • 计算机软件著作权
      • 保护的对象是计算机软件, 即计算机程序及其有关文档
        • 同一计算机程序的源程序和目标程序为同一作品。
        • 文档是指用来描述程序的内容、组成、设计、功能规格、开发情况、测试结果及使用方法的文字资料和图表等,如程序说明、流程图、用户手册等。
        • 软件著作权中规定:开发软件所用的思想、处理过程、操作方法或者数学概念不受保护。
      • 《计算机软件保护条例》第十四条规定:“软件著作权自软件开发完成之日起产生。”,即软件著作权自软件开发完成之日起自动产生,不论整体还是局部,只要具备了软件的属性即产生软件著作权,既不要求娌行任何形式的登记或注册手续,也无须加注著作权标记,且不论其是否已经发表都依法享有软件著作权。幵发完成是指以计算机能够识别并进行处理以实现一定功能的语句或指令的形式,并存储在一定的有形介质中,如内存、硬盘、光盘等。
      • 我国实施了计算机软件登记制度,于1992年颁布了《计算机软件著作权登记办法》。实施计算机软件登记制度的目的是为促进我国软件产业发展,增强我国软件产业的创新能力和竞争能力。国家鼓励计算机软件著作权登记并对登记的软件予以重点保护的办法,而不是强制软件登记。计算机软件著作权登记可以分为软件著作权登记、软件著作权专有许可合同和转让合同的登记。计算机软件著作权登记只是证明登记主体享有软件著作权以及订立许可合同、转让合同的重要的书面证据,并不是软件著作权产生的依据。因为软件著作权是自软件开发完成之日起产生的,未经登记的软件著作权或软件著作权专有许可合同和转让合同仍受法律保护。
  • 商标权
    • 在我国,商标权的取得实行的是注册原则,即商标所有人只有依法将自己的商标注册后,商标注册人才能取得商标权,其商标才能得到法律的保护。
      • M画家并未将其美术作品实施商标注册,不享有其美术作品的商标权。
    • 软件商标权是软件商标所有人依法对其商标(软件产品专用标识)所享有的专有使用权。
      • 未注册商标
        • 对其软件产品已经冠以商品专用标识,但未进行商标注册,没有取得商标专用权,此时该软件产品专用标识就不能得到商标法的保护,即不属于软件商标权的保护对象。
        • 可以自行在商业经营活动中使用,但不受法律保护。未注册商标不受法律保护,不等于对使用未注册商标行为放任自流。为了更好地保护注册商标的专用权和维护商标使用的秩序,需要对未注册商标的使用加以规范。所以《商标法》第四十八条专门对使用未注册商标行为做/规定。未注册商标使用人不能违反此条规定,否则商标行政主管机关将依法予以查处。
  • 知识产权
    • 计算机软件知识产权
      • 职务作品
        • 《计算机软件保护条例》第13条规定“自然人在法人或者其他组织中任职期间所开发的软件有下列情形之一的,该软件著作权由该法人或者其他组织享有,该法人或者其他组织可以对开发软件的自然人进行奖励
        • (一)针对本职工作中明确指定的开发目标所开发的软件;
        • (二)开发的软件是从事本职工作活动所预见的结果或者自然的结果;
        • (三)主要使用了法人或者其他组织的资金、专用设备、未公开的专门信息等物质技术条件所开发并由法人或者其他组织承担责任的软件。
        • 根据《计算机软件保护条例》规定,可以得出这样的结论,当公民作为某单位的职工时,如果其开发的软件属于执行本职工作的结果,该软件著作权应当归单位享有。而单位可以给予开发软件的职工奖励。需要注意的是,奖励软件开发者并不是单位的一种法定义务,软件开发者不可援引《计算机软件保护条例》强迫单位对自己进行奖励。
        • 公司对该软件享有除署名权外的软件著作权的其他权利,而王某只享有署名权。
  • 委托开发
    • 委托开发软件著作权关系的建立,通常由委托方与受委托方订立合同而成立。
    • 委托开发软件关系中
      • 委托方的责任主要是提供资金、设备等物质条件,并不直接参与开发软件的创作开发活动。
      • 受托方的主要责任是根据委托合同规定的目标开发出符合条件的软件。
    • 关于委托开发软件著作权的归属,《计算机软件保护条例》第十二条规定:“受他人委托开发的软件,其著作权的归属由委托者与受委托者签定书面协议约定,如无书面协议或者在协议中未作明确约定,其著作权属于受委托者。”
      • 和职务作品相反,默认归属创作者。
      • 根据该条的规定,确定委托幵发的软件著作权的归厲应当掌握两条标准:
        • ①委托开发软件系根据委托方的要求,由委托方与受托方以合同确定的权利和义务的关系而进行开发的软件,因此软件著作权归属应当作为合同的重要条款予以明确约定。对于当事人已经在合同中约定软件著作权归属关系的,如事后发生纠纷,软件著作权的归属仍应当根据委托开发软件的合同来确定。
        • ②对于在委托幵发软件活动中,委托者与受委托者没有签定书面协议,或者在协议中未对软件著作权归属作出明确的约定,其软件著作权属于受委托者,即属于实际完成软件的开发者。
  • 专利
  • 其他

14. 企业信息化战略与实施

  • 管理信息系统规划的方法
    • 用于管理信息系统规划的方法很多,主要是关键成功因素法( Critical Success Factors,CSF)、战略目标集转化法( Strategy Set Transformation, SST )和企业系统规划法( Business System Planning, BSP )。其它还有企业信息分析与集成技术(BIAIT)、产出/方法分析(E/MA)、投资回收法(ROI)、征费法(chargout)、零线预算法、阶石法等。用得最多的是前面三种。
      1. 关键成功因素法( CSF)
      • 在现行系统中, 总存在着多个变量影响系统目标的实现, 其中若干个因素是关键的和主要的(即关键成功因素)。通过对关键成功因素的识别,找出实现目标所需的关键信息集合,从而确定系统开发的优先次序。关键成功因素来自于组织的目标, 通过组织的目标分解和关键成功因素识别、性能指标识别,一直到产生数据字典。
      • 识别关键成功因素, 就是要识别联系于组织目标的主要数据类型及其关系。不同的组织的关键成功因素不同, 不同时期关键成功因素也不相同。当在一个时期内的关键成功因素解决后,新的识别关键成功因素又开始。
      • 关键成功因素法能抓住主要矛盾, 使目标的识别突出重点。由于经理们比较熟悉这种方法, 使用这种方法所确定的目标, 因而经理们乐于努力去实现。该方法最有利于确定企业的管理目标。
    • 2.战略目标集转化法( SST)
      • 把整个战略目标看成是一个“信息集合”,由使命、目标、战略等组成,管理信息系统的规划过程即是把组织的战略目标转变成为管理信息系统的战略目标的过程。
      • 战略目标集转化法从另一个角度识别管理目标, 它反映了各种人的要求, 而且给出了按这种要求的分层, 然后转化为信息系统目标的结构化方法。它能保证目标比较全面,疏漏较少,但它在突出重点方面不如关键成功因素法。
      1. 企业系统规划法( BSP)
      • 信息支持企业运行。通过自上而下地识别系统目标、企业过程和数据, 然后对数据进行分析,自下而上地设信息系统。该管理信息系统支持企业目标的实现,表达所有管理层次的要求, 向企业提供一致性信息, 对组织机构的变动具有适应性。
      • 企业系统规划法虽然也首先强调目标, 但它没有明显的目标导引过程。它通过识别企业“过程”引出了系统目标,企业目标到系统目标的转化是通过企业过程/数据类等矩阵的分析得到的。
  • 组织信息化需求
    • 一般说来,信息化需求包含3 个层次,即战略需求、运作需求和技术需求。
      • 一是战略需求。组织信息化的目标是提升组织的竞争能力、为组织的可持续发展提供一个支持环境。从某种意义上来说, 信息化对组织不仅仅是服务的手段和实现现有战略的辅助工具; 信息化可以把组织战略提升到一个新的水平, 为组织带来新的发展契机。特别是对于企业,信息化战略是企业竞争的基础。
      • 二是运作需求。组织信息化的运作需求是组织信息化需求非常重要且关键的一环,它包含三方面的内容: 一是实现信息化战略目标的需要; 二是运作策略的需要。三是人才培养的需要。
      • 三是技术需求。由于系统开发时间过长等问题在信息技术层面上对系统的完善、升级、集成和整合提出了需求。也有的组织, 原来基本上没有大型的信息系统项目,有的也只是一些单机应用, 这样的组织的信息化需求, 一般是从头开发新的系统。
  • ERP
    • ERP是对企业物流、资金流和信息流资源进行全面集成管理的管理信息系统。
    • ERP(Enterprise Resource Planning )是建立在信息技术的基础上,利用现代企业的先进管理思想,对企业的物流、资金流和(信息)流进行全面集成管理的管理信息系统, 为企业提供决策、计划、控制与经营业绩评估的全方位和系统化的管理平台。
    • 在ERP五个层次的计划中
      • 生产预测计划是对市场需求进行比较准确的预测,是经营计划、生产计划大纲和主生产计划编制的基础;
      • 销售管理计划是针对企业的销售部门的相关业务进行管理,属于最高层计划的范畴,是企业最重要的决策层计划之一;
      • 生产计划大纲根据经营计划的生产目标制定,是对企业经营计划的细化;
        • 主生产计划说明了在一定时期内生产什么,生产多少和什么时候交货,它的编制是ERP的主要工作内容;
      • 物料需求计划是对主生产计划的各个项0所需的全部制造件和全部采购件的网络支持计划和时间进度计划;
      • 能力需求计划是对物料需求计划所需能力进行核算的一种计划管理方法,能够帮助企业尽早发现企业生产能力的瓶颈,为实现企业的生产任务提供能力帮面的保障。
    • 在ERP系统中,(库存)管理模块主要是对企业物料的进、出、存进行管理。
    • 供应链
      • 供应链中的信息流覆盖了从供应商、制造商到分销商,再到零售商等供应链中的所有环节。
      • 其信息流分为需求信息流和供应信息流,这是两个不同流向的信息流。
        • 当需求信息(如客户订单、生产计划和采购合同等)从需方向供方流动时,便引发物流。
        • 同时,供应信息(如入库单、完工报告单、库存记录、可供销售量和提货发运单等)又同物料一起沿着供应链从供方向需方流动。
  • 电子政务
    • 电子政务是政府机构应用现代信息和通信技术,将管理和服务通过网络技术进行集成,在因特网上实现政府组织结构和工作流程的优化重组,超越时间和空间及部门之间的分隔限制,向社会提供优质和全方位的、规范而透明的、符合国际水准K管理与服务。
    • 电子政务是对现有的政府形态的一种改造,利用信息技术和其他相关技术,将其管理和服务职能进行集成,在网络上实现政府组织结构和工作流程优化重组。
    • 与电子政务相关的行为主体有三个,即政府、企(事)业单位及居民
    • 电子政务的主要模式有4种:
      • (1)政府对政府(Government To Government);
      • (2)政府对公务员(Government To Employee)
      • (3)政府对企业(Government To Business);
      • (4)政府对公民(Government To Citizen)
  • 电子商务
    • 电子商务分五个方面,即电子商情广告、电子选购与交易、电子交易凭证的交换、电子支付与结算,以及网上售后服务等。
    • 电子商务系统中参与电子商务活动的实体有4类:客户(个人消费者或集团购买)、商户(包括销售商、制造商和储运商)、银行(包括发行和收单行)及认证中心
  • BI(商业智能系统)
    • 商业智能通常被理解为将组织中现有的数据转化为知识,帮助组织做出明智的业务经营决策。
    • 商业智能的实现涉及到软件、硬件、咨询服务及应用,是对商业信息的搜集、管理和分析的系统过程,目的是使企业的各级决策者获得知识或洞察力,促使他们做出对企业更有利的决策。
    • 商业智能(主要技术)一般由数据仓库、联机分析处理、数据挖掘、数据备份和恢复等部分组成。
    • 商业智能系统的处理过程包括数据预处理、建立数据仓库、数据分析及数据展现4个主要阶段。
      • 数据预处理是整合企业原始数据的第一步,包括数据的抽取、转换和装载三个过程。
      • 建立数据仓库则是处理海量数据的基础。
      • 数据分析是体现系统智能的关键,一般采用联机分析处理(OLAP)和数据挖掘技术。
        • 联机分析处理不仅进行数据汇总/聚集,同时还提供切片、切块、下钻、上卷和旋转等数据分析功能,用户可以方便地对海量数据进行多维分析。
        • 数据挖掘的目标则是挖掘数据背后隐藏的知识,通过关联分析、聚类和分类等方法建立分析模型,预测企业未来发展趋势和将要面临的问题。
      • 数据展现。在海量数据和分析手段增多的情况下,数据展现则主要保障系统分析结果的可视化。

posted on 2019-10-30 13:57  碎羽love星谊  阅读(613)  评论(0编辑  收藏  举报

导航