本文内容均整理自西安交通大学软件学院饶元老师的ppt中，仅供学习使用，请勿转载或他用

考试重点知识

十个选择:基本概念（20分）

综合题（80分）：给一个场景，需要把一个案例从头到尾设计出来就ok了

• 数据库设计40
  • 1,2,3范式
  • RBAC
  • 完整性约束
  • sql
• 面向对象设计40
  • 整个系统DFD建模
  • 用例角度,用例描述
  • 事件流刻画角度
  • activity图
  • 时序图
  • 类图
  • 状态图
  • 以及一些基本原则（7个，类图中的5+2?）对类图做一些优化

如何复习

• 看书，形成知识框架，对于所有知识形成脑图，如何与业务场景衔接，如何建立一个实际开发需要的东西
• 将开发好的系统重新设计出来
• 将上课设计的案例看老师如何设计，能不能找到更好的方法
• 图书馆找教材，UNL实训教材，数据库设计教材

假设有一个信息管理系统，不管什么端，

• 先将用户找出来
• 确认需求

下面是从ppt上整理的一些基础知识，虽然我整理的时候记得挺多的，把觉得重点知识都整理出来了，但是考试证明整理的都没有用，主要还是去真正的设计一个系统，所以对于下面的概念可以选择性阅读，不要求背过，但是一定要理解，后面与UML相关的东西一定需要牢牢掌握，尤其是上面写到的那些UML图，必须必须必须得会！！！是在不会的话可以去图书馆借一些UML的书，然后对照着里面的例子去设计
我最后的总评成绩由于平时作业的加分获得了大学中的第一个满分，对于这门科目的考试我的感觉就是考试时间非常的紧，看上面的考试重点就知道我们需要从头去设计一个系统，包括功能模型，动态模型，静态模型，而设计一个系统肯定不是一天两天就能设计好的，因此需要在考试两个半小时设计一个系统的难度可想而知了，这就要求如果想获得一个比较好的成绩就必须要能够熟练的设计一个系统，包括数据库，数据库的优化，用例图，活动图，时序图，类图以及类图的优化，这些东西必须必须必须掌握！！！不然考完试就等着郁闷吧
这门课程相对来说背诵的知识还是比较少的，大部分都是需要自己动手实践的，这从平时作业也可以看的出来，饶老师非常鼓励我们自己去动手完成一些东西，也非常强调coding的重要性，所以哪怕下面的东西都不会，也需要把上面的那些东西掌握了！！！

系统+设计

什么是系统

定义

系统是相互联系，相互作用的诸元素的综合体

最佳定义

• 系统是指由相互联系、相互作用的若干组成部分构成的有机整体，整个整体具有其各个组成部分所没有的新性质和功能，并和一定的换将发生交互作用
• 系统各要素之间、要素与整体之间，以及整体与环境之间，存在着一定的有机联系，从而在系统的内部和外部形成一定的结构和秩序
  • 要素是指组成系统的基本成分，是系统形成的基础。要素和系统的关系，是部分与整体的关系，他们相互联系，相互作用
  • 功能是指系统与外部环境在相互联系和作用的过程中产生的效能
  • 活动是系统形成、发展、变化的动态过程，这个过程通过系统内部诸要素之间、要素与系统之间以及系统与环境之间相互影响、相互作用而完成的。
  • 信息时值事务存在的方式或运动状态以及这些方式、状态的直接或简介的传播与表述
  • 环境是指出于系统边界之外并和系统进行着物质、能量和信息交换的所有事务

系统的特征

三个特性

• 多元性
  • 系统是多样性的统一，差异性的统一
• 相关性
  • 系统不存在孤立元素组分，所有元素或组分间相互依存、相互作用、相互制约
• 整体性
  • 系统是所有元素构成的复合统一整体

软件系统核心要素

软件系统：指在一定的软件开发与应用环境下，为了达到某一目的而相互联系、相互作用的若干个软件要素所组成的有机整体

软件系统的要素

涌现

1+1大于2

群体的需求是一种涌现现象，即整体大于部分之和，这种高层次具有的属性、特征、行为和功能还原到低层级就不复存在

分析之责

• 客户需求
  • 在需求分析阶段，需要挖掘出客户真正在乎的需求，最好对需求进行分优先级
  • 而且需求并不是一成不变，项目过程中增减需求是平常的事，但是由此造成的影响要评估并更新文档
• 假设的条件
  • 有时项目执行中会因为某些需要客户或第三方完成的事情不具备，而造成项目延迟
  • 这就需要在合同中对这些结社特别说明，以避免后面的责任不清
• 环境的限制
  • 这点尤其重要，常常在分析阶段被忽略
  • 尽可能挖掘限制条件，会避免后面阶段很多的问题
• 风险
  • 风险分析对于软件项目管理是决定性的
  • 风险分析实际上就是贯穿在软件过程中的一系列风险管理步骤，其中包括：风险识别、风险估计、风险管理策略、风险解决和风险监督等

设计之要

模型驱动->灵活且可扩展

设计原则

软件系统分析与设计的主要方法

系统开发生命周期

功能分解法

• 以系统需要提供的功能为中心组织系统
• 首先定义各种功能，然后把功能分解为子功能
• 对较大的子功能进一步分解，直到可给出明确的定义
• 设计功能、子功能所需要的数据结构
• 定义功能、子功能之间的接口
• 作为一种早期的建模方法，没有明确地区分分析与设计

结构化方法

• 结构化分析（structured analysis，SA）
• 结构化设计（structure design，SD）

结构化分析又称为数据流法，其基本策略是跟踪数据流，即研究问题域中的数据如何流动，以及在各个环节上进行何种你那个处理，从而发现数据流和加工。得到的分析模型是数据流图（DFD），主要的模型元素是数据流，加工，外部实体及存储，外加处理说明和数据字典

结构化设与功能分解法基本相同，基于模块的概念建立设计模型，分为概要设计和详细设计

• 概要设计：确定系统中包含哪些模块以及模块之间的调用关系，得到模块结构图（MSD）
• 详细设计：描述每个模块内部的数据结构和操作流程

结构化方法的优缺点

• 优点
  • 强调研究问题域，并由严格的法则
• 缺点
  • 仍然是间接映射问题域
  • 分析与设计的概念不一致，从分析到设计的过渡比较困难
  • 数据流和加工的数量太多，引起分析文档的膨胀

信息建模法

信息建模法（information modeling）

• 核心概念是实体和关系。实体描述问题域中的事务，关系描述事务之间在数据方面的联系，都可以带有属性
• 发展之后的方法也把实体称为对象，并使用了类型和子类型的概念，作为实体（对象）的抽象描述

信息建模法已经很接近面向对象方法，因此有的文献也把它称为一种面向对象方法，但是有以下差别：

• 强调的重点是信息建模和状态建模，而不是对象建模
• 实体中只有属性没有操作
• 只有属性的继承，不支持操作的继承
• 没有采用消息通讯

面向对象方法

• 面向对象的分析（object oriented analysis，OOA）
• 面向对象的设计（object oriented design，OOD）

运用对象、类、继承、封装、聚合、关联、消息、多态等概念来构造系统

• 把问题域中的事务抽象为对象，作为系统的基本构成单位，其属性和操作刻画了事务的静态特征和动态特征----完整地刻画了问题域中的事务
• 用类作为对象的抽象描述，建立他们之间的继承、聚合、关联、消息等关系----如实地表达了问题域中事务之间的各种关系

不同建模方法的比较

需求工程

需求语义断连现象的分析

软件分析本质：识别并解决问题

• 语义断连是需求分析中常见的现象
  • 需求分析中所有的涉及物需要明确定义，避免不一致或二义性的发生
  • 划清角色与系统的边界，形成完整的业务关联场景至关重要
• 需求目标的缺失是需求分析中常见的现象
  • 需求中边界的确实，往往会造成全局性的失败
  • 需求分析中必须避免目标确实问题的发生
  • 建立起所涉及物之间的关系，形成完整的业务关联场景至关重要

语义断连错误的原因

形式化需求分析方法

• 一个软件包含了所有功能的集合，同时包含了实现所有功能的所有方法和算法描述。
• 需求分析师依据于用户需求，经过需求问题识别，进行分析、消化与综合，指定规格说明，评审，分为四个阶段，形成用户需求与设计同步，设计满足用户的需求目标

需求的重要性

• 开发软件系统最困难的部分就是准确说明开发什么。
• 最困难的概念性工作是编写出详细的需求，包括面向用户，面向机器和其他软件系统的接口。

需求关键特征属性

软件需求特征属性

• 层次化
• 过程（评审vs版本）
• 追踪vs状态
• 客户角色

层次化

需求又分为业务需求，用户需求，功能需求以及系统需求，此外还包括一些非功能需求

• 业务需求
  • 表示组织或客户高层次的目标，业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标
• 用户需求
  • 描述的是用户的目标，或用户要求系统必须能完成的任务
• 功能需求
  • 规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求
• 系统需求
  • 用于描述包含有多个子系统的产品（即系统）的顶级需求

过程

需求的开发是一个不断反复的过程，主要是企业向开发商提交初步的需求，开发商针对已提出的需求编写需求规约并交付企业，企业经过评审后提出意见，开发商对于需求规约进行一次次的修改，往复提交，直到双方达成一致

追踪vs状态

需求跟踪是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求，体系结构，其他设计部件，源代码模块，测试，帮助文件等。需求跟踪为我们提供了由需求到产品实现整个过程范围的明确查阅的能力。在跟踪的过程中最重要的一个属性便是需求的状态，这个用来标识需求当前情况的一个属性，可以帮助我们更好了解需求变更的过程以及当前情况

客户角色

• 用户：可以细分为三种
  • 客户（customer）
  • 最终用户（the end user）
  • 间接用户（或称关系人）
• 掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人
• 简介用户：既不掏钱买该软件，也不适用该软件，但是他可能对软件产品有很大的影响
• 利益攸关人：如果项目规模比较大，那么项目所涉及到的软件开发放与最终用户放一些人员的工作与利益，这些人称为利益相关人

与客户打交道的主要目的

• 一是获取明确需求（业务功能需求分析+心理需求分析）
• 二是签合同
• 三是顺利验收
• 四是为未来的项目留下余地

需求职责

需求工程

什么是需求工程

• 把所有与需求直接相关的活动统称为需求工程
• 需求工程中的活动可以分为两大类
  • 一类属于需求开发
    • 需求调查
    • 需求分析
    • 需求定义
  • 一类属于需求管理
    • 需求确认
    • 需求跟踪
    • 需求变更控制

需求开发过程域

• 需求开发的目的是通过调查与分析，获取用户需求并定义产品需求
• 需求调查的目的是通过各种途径获得用户的需求信息（原始材料），产生《用户需求说明书》
• 需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类
• 需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作

需求管理过程域

• 需求管理的目的是在客户和开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更
• 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果
• 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发
• 需求变更控制是指依据“变更申请–审批–更改–重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱

需求开发方法

需求服务质量差距模型

需求获取的方法

• 对现有的文档，表单和数据库进行抽样

• 研究和现场访问

• 对工作环境的观察

• 调查问卷

• 采访

• 原型设计（ProtoTyping）

  • 原型设计是交互设计师与PD、PM、网站开发工程师沟通的最好工具。而该块的设计在原则上必须是交互设计师的产物，交互设计以用户为中心的理念会贯穿整个产品。利用交互设计师专业的眼光与经验直接导致该产品的可用性。

  • 应该是按照已经有了的模板进行设计？

• 联合需求规划（Joint requirements planning，JRP）

如何开展需求调查

1. 准备需求
   1. 首先，需求分析员应当起草需求调查问题表，将调查重点锁在该问题表内
      • 问题表可以有多份，随着调查的深入，问题表将不断被细化
      • 问题选择表应当以选择题和是非题为主
   2. 其次，需求分析员应当确定需求调查的方式
      • 与用户交谈，向用户提问题
      • 向用户群体发放调查问卷
      • 参观用户的工作流程，观察用户的操作
      • 与同行、专家交谈，听取他们的意见
      • 撰写《需求调查计划》
      • 特别留意：不要漏掉典型的用户
2. 执行调查
   1. 需求分析员与用户，面谈时应当注意一下事项
      • 应该事先了解用户的身份、背景，以便随机应变
      • 需求调查应该先了解宏观问题，再了解细节问题
   2. 根据调查记录完成《用户需求说明书》

需求获取的重要工具----上下文图（DFD）

角色->需求->功能->系统边界

如何进行需求分析

需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排出错误和弥补不足，确保需求文档正确地反映用户的真实意图

撰写《产品需求规格说明书》

需求分析方法有两类

• 文档分析法
• 建模分析法

问答分析法

• 问答分析最重要的问题是是什么和为什么
  • 每个需求都应当用陈述句说明"是什么"，如果“是什么”的内涵不够清晰，则应该补充说明“不是什么”
  • 追究“是什么”和“为什么”的目的是获得正确、清晰的需求

建模分析法

• 需求建模就是指用图形符号来表示，刻画需求
• 建模分析方法主要有两大类
  • 结构化分析法
  • 面向对象分析法
• 在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用

需求分析工具

• 业务流程图、泳道图：反映业务信息处理的具体过程

  

• 数据流图

  

• WBS

  

• E-R图，数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系。在需求分析阶段进行数据库逻辑设计过程中，使用E-R图，可以定义一个实体模型

  

• 用例驱动的分析

  

关于Use-Case的描述方法

用户动作与系统响应反映了Use-Case的实现策略的核心机制

候选流程反映了系统的健壮性，是区分系统设计好坏的一个前提，需要体现在活动图中

需求的好坏直接决定了设计的好坏

管理关键问题分析

需求管理控制过程

• 版本控制
  • 确定需求文档版本
  • 确定单个需求文档版本
• 变更控制
  • 建议变更
  • 分析影响
  • 做出决策
  • 交流
  • 合并
  • 测量需求的稳定性
• 需求跟踪
  • 定义对其他需求的阶段链
  • 定义对其他系统元素阶段
  • 注意此处跟踪的状态表示阶段
• 需求状态跟踪
  • 定义需求状态
  • 跟踪需求每一个状态
  • 注意此处状态是审核状态

需求确认

• 需求确认：是指开发方和客户方共同对《产品需求规格说明书》及进行评审，双方对需求达成共识后做出承诺
• 需求承诺具有商业合同的效果

需求跟踪

• 建立“需求–设计–编程–测试”之间的一致性，确保所有的工作成果符合用户需求

• 需求跟踪有三种方式：

  • 正向跟踪，检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点

  • 逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处

  • 建立与维护需求跟踪矩阵：需求跟踪矩阵保存了需求与后继成果的对应关系

    

小结

软件开发影响因素

软件失败的原因与好设计的原则

IT系统不成功的六大类型

• 已经开始的项目，在未结束之前便放弃；
• 项目已经开发完成，但从未使用；
• 项目已经开发完成并投入使用，但是在很短的时间内就放弃使用；
• 所开发的项目并未达到预期的目标，无法完全提供设计的功能；
• 项目开发时间比预计延长较多；
• 项目开发经费不断增加。

产生问题的主要原因

好设计的十项原则

软件系统开发的十大原则

项目管理的”三五九“

• 三个约束条件
  • 是范围、时间及成本
• 五个过程组
  • 启动、计划、控制、实施、收尾
• 九大知识领域
  • 整体管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理

软件可行性研究

概念

可行性研究是指系统建设项目确立之前对系统建设的必要性和可能性以及可能的候选方案从整个系统周期的角度进行分析和评价，为企业信息化决策提供科学的依据，并据此由系统开发人员形成书面的可行性研究报告

任务

是根据确定的问题，通过分析新系统需要的信息技术、可能发生的投资和费用、产生的效益，确定将开发的软件系统成功的可能性

目的

降低风险，用最小的代价在最小的时间内确定问题是否能够解决

前提

明确的要求、目标、假定、限制

数据库设计

问题引入基本概念

• 数据：是客观事物的符号表示。在计算机科学中指的是所有能输入到计算机中被计算机程序处理的符号的总称

• 数据元素：是数据的基本单位，在程序中通常作为一个整体来进行考虑和处理

• 一个数据元素可以由若干个数据项组成。

  • 数据项是数据的不可分割的最小单位。
  • 数据项是对客观事务某一方面特性的数据描述

• 数据对象：是性质相同的数据元素的集合，是数据的一个子集

• 数据结构：是指相互之间具有一定联系的数据元素的集合。

  • 元素之间的相互联系称为逻辑结构

  • 数据元素之间的逻辑结构有四种基本类型

    

• 数据类型：指的是一个值的集合和定义在该值集上的一组操作的总称

• 抽象数据类型（ADT）：是指一个数学模型以及定义在该模型上的一组操作

数据建模的基本概念

• 数据建模：是一组组织和记录系统数据的技术，即数据库建模
• 实体关系图（ERD）：是一种利用符号标记实体与关系，实现对数据刻画的一种数据模型
• 实体：是我们需要收集数据与存储数据的人，地点，对象，事件或概念的类
• 属性：是实体的描述性的性质或特征，同义词包括要素，性质或域
• 组合属性：由其他属性组成的属性，它在不同的数据建模中有不同的名称：串联属性，合成属性，数据结构

属性的特征

• 数据类型：是属性的一个参数，定义了这个属性中可以存储什么类型的数据
• 域：是属性的一个参数，定义了这个属性可以取的合法数据值
• 默认值：如果用户没有指定值的话，将被记录的值
• 键：是一个属性（或一组属性），他们对每个实体实例具有唯一的值，也称为标识符
• 候选键：是一组可以作为一个实体主键的键，也称为候选标识符
• 主键：是最终用来唯一表示或者确定一个实体实例的候选键
• 替代键：是没有被选中作为主键的其他候选键

关系的特征

• 关系：是存在于一个或多个实体之间的业务联系
• 聚数：定义了一个实体相对于另一个关联实体的某个具体指的最大或最小具体值的数量
• 度数：是参与某一个关系的实体数量
  • 二维关系：两个实体之间的关系
  • 单一实体之间的关系，即递归关系
  • 页存在多个实体之间，即多维关系

外键的特征

• 外键，是一个实体的主键，但被复制到另一个实体以确定一个关系实例
  • 外键总是与另一个实体的主键匹配
  • 获得外键的实体为子实体
  • 提供外键的实体为父实体
• 非确定性关系：是每个参与关系的实体都有各自的独立主键关系
  • 不共享主键属性
  • 实体被称为独立实体（强实体）
• 确定性关系：是父实体提供其转称为子实体的主键的一部分的关系
  • 不共享主键属性
  • 子实体被称为关联实体（弱实体）
• 非特定关系：是一个实体的多个实例同另一个实体的多个实例相关联的关系，即多对多的关系

实体的泛化

• 泛化（Generalization）：是指将几类实体公共的属性组合成独立的实体
• 超类（SuperType）：是一个实体，其实例存储了一个或多个实体子类的公共属性
• 子类（SubType）：是一个实体，其实例从一个实体超类中继承了一些公共属性

信息工程设计核心视角

在软件系统中需要处理的数据是系那是世界中存在的事物及其联系的反映

人们通常将于数据处理有关的领域分为三个世界

• 现实世界
• 信息世界
• 数据世界

现实世界

现实世界是存在于人们头脑之外的客观世界，现实世界中的事务可分成对象和性质两大类

• 对象可以是人、是物，还可以是实际的东西或者概念
• 对象还可以指事务与事务之间的联系
• 性质则是指事务的性质或特征

信息世界

信息世界也叫做观念世界，是现实世界在人们头脑中的反映

• 客观世界中的事务在信息世界中叫做实体，反映事务之间联系的叫做实体模型
• 实体是由若干属性的属性值组成
• 属性是实体某一方面的特征，相应于事务的性质

数据世界

数据世界则是信息世界中信息的数据化，显示世界中的事务及其联系在数据世界中用数据模型描述

• 描述每一实体的数据称为记录，描述属性的数据叫做数据项或字段
• 与实体集相对的称为文件

信息工程设计的方法和原则

数据库设计的基本步骤

数据库设计分成6个阶段

• 需求分析
• 概念结构设计
• 逻辑结构设计
• 物理结构设计
• 数据库实施
• 数据库运行和维护

需求分析和概念设计独立于任何数据库管理系统

E-R方法和实体模型

规范化的目的

• 消除数据冗余：即消除表格中的数据重复
• 消除多义性：使关系中的属性含义清楚、单一
• 使关系单纯化：让每个数据项只是简答的数或字符串，而不是组项或重复组
• 方便操作：是数据的插入、删除与修改操作可行并方便
• 使关系模式更灵活：易于实现接近自然语言的查询方式

规范化的三个条件

• 表格中每个信息项必须是一个不可分割的数据项
• 表格中每一列中所有信息项必须是同一类型，各列的名字（属性名）互异，列的次序任意
• 表格中各行互不相同，行的次序任意

第一范式

定义：数据库中的所有字段都是单一属性，不可再分的，这一个单一属性是由基本的数据类型所构成的

关系中所有的属性都是单纯域，即不出现“表中套表”

第二范式

定义：数据库的表中不存在非关键字段对任一候选关键字段的部分函数依赖

部分函数依赖是指存在着组合关键字段中的某一个关键字段决定其他非关键字段的情况

第三范式

定义：实体的非主属性的值不依赖于任何其他非主键属性

注：所有非主属性对任何候选管关键字都不存在传递依赖

好的数据模型评价标准

简单高效，无冗余或少冗余，灵活且可扩展

数据库的完整性设计

• 为了防止不符合规范的数据进入数据库，在用户对数据进行插入、修改、删除等操作时，DBMS自动按照一定的约束条件对数据进行监测，使不符合规范的数据不能进入数据库，以确保数据库中存储的数据正确性、有效性、相容性
• DBMS提供一种机制来检查DB中的数据，看其是否满足语义规定的条件。这些加在DB数据之上的语义约****束条件称为DB完整性约束条件，它们作为模式的一部分存入DB中。有一些需要在应用程序中来限制。
• 而DBMS中检查数据是否满足完整性条件的机制称为完整性检查。

非空约束

Unique约束

主键约束

primary约束与unique约束

• 在一个表中，只能定义一个primary key约束，但可以定义多个unique约束
• 对于指定为primary的一个列或者多个列的组合，其中任何一个列都不能出现空值，而对于unique所约束的唯一键，则允许为null，只是null值最多有一个

外键约束

check（校验）约束：

• 用来检查字段值所允许的范围。
• DBMS每当执行delete, insert或update语句时，都对这个约束过滤。如果为true，则执行。否则，取消执行并提示错误。

完整性的分类

• 实体完整性：规定表中的每一行在表中是唯一的实体
• 域完整性：是指表中的列必须满足某种特定的数据类型约束，其中约束又包括取值范围、精度等规定
• 参照完整性：是指两个表的主键和外键的数据应一致，保证了表之间的数据的一致性。防止了数据丢失或无意义的数据在数据库中扩散
• 用户定义的完整性：不同的关系数据库系统根据应用环境的不同，往往还需要一些特殊的约束条件。用户定义的完整性即是针对某个特定关系数据库的约束条件，它反映某一具体应用必须满足的语义要求

完整性约束条件包括

• 静态完整性约束和动态完整性约束
  • 静态约束是指对DB每一确定状态的数据所应满足的约束条件。值的约束和结构约束均属静态约束。
  • 动态约束是指DB从一种状态转变为另一种状态时,新、旧值之间所应满足的约束条件，它是反映DB状态变迁的约束。例如，当更新职工工资时，要求新工资值不低于旧工资值，并且当旧工资值超过2500元时，保持不动
• 立即执行完整性约束和延迟执行完整性约束
  • 立即执行约束（Immediate Constraints）是在执行用户事务处理程序时，某一更新语句执行完后马上对此数据所应满足的约束条件进行完整性检查。
  • 延迟执行约束(Deferred Constraints)是指在整个事务处理程序执行完毕后，再对约束条件进行检查，结果正确才能提交出来。

数据库安全性设计

用户标识与鉴别

它是系统提供的最外层安全保护措施。其方法是由系统提供一定的方式让用户标识自己的名字或身份。每次用户要求进入系统时，由系统进行核对，通过鉴定后才提供机器使用。为了进一步核实用户，系统常常要求用户输入口令（Password）。

数据加密

数据加密是防止DB中数据在存储和传输中失密的有效手段。

加密方法主要有两种：

• 一种是替换方法，该方法使用密匙(Encryption Key)将明文中的每一个字符转换为密文中的一个字符；
• 另一种是置换方法，该方法仅将明文的字符按不同的顺序重新排列。单独使用这两种方法的任意一种都是不够安全的。

但是将这两种方法结合起来就能提供足够好的安全程度。

存取控制

• 定义用户权限：用户权限是指不同的用户对于不同的数据对象允许执行的操作权限。系统必须提供适当的语言定义用户权限，这些定义经过编译后存放在数据字典中，被称作安全规则或授权规则
• 合法权限检查：每当用户发出存取DB的操作请求后（请求一般应包括操作类型、操作对象和操作用户等信息），DBMS查找数据字典，根据安全规则进行合法权限检查，若用户的操作请求超出了定义的权限，系统将拒绝执行上述操作。

视图机制

进行存取权限控制时可以为不同的用户定义不同的视图（View），把数据对象限制在一定的范围内，即通过视图机制把要保密的数据对无权存取的用户隐藏起来，从而自动地对数据提供一定程度的安全保护。一般设计阶段中有用户视图设计。

审计

审计功能把用户对DB的所有操作自动记录下来放入审计日志(Audit Log)中。DBA可以利用审计跟踪的信息，重现导致DB现有状况的一系列事件，找出非法存取数据的人、时间和内容等

面向对象设计

UML的图模型

用例图

• 用例图是被称为参与者的外部用户所能观察到的系统功能的模型图
• 用例图列出系统中的用例和系统外的参与者，并显示哪个参与者参与了哪个用例的执行

活动者(角色,Actor)：系统外部的参与者，可以是人、外部硬件、其他系统，甚至时间

关系

• 包含：基用例可以看到包含用例，并需要依赖于包含用例的执行结果
  • 当某个都会做片段在多个用例中都出现了的时候，可以将其分离出来从而形成一个单独的用例
• 扩展：使用扩展用例，可以在不改变基用例的同时，根据需要自由地向用例中添加行为

用例描述

类图

类图以反映类的结构(属性、操作)以及类之间的关系为主要目的，描述了软件系统的结构，是一种静态建模方法

类图中的事物及解释

从上到下分为三部分，分别是类名、属性和操作。类名是必须有的

类的关系描述

类之间主要存在的关系：依赖、关联、聚合、组合、实现和泛化。

活动图

描述系统的动态行为。包含活动状态(ActionState)，活动状态是指业务用例的一个执行步骤或一个操作，不是普通对象的状态。

时序图

顺序图用来表示用例中的行为顺序。当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或状态机中引起转换的事件。

顺序图展示对象之间的交互，这些交互是指在场景或用例的事件流中发生的。顺序图属于动态建模。

时序图的组成

状态机图

• 状态机：
  • 用于描述一个对象在其生存期间的动态行为，表现对象响应事件所经历的状态序列以及伴随动作
• 状态机图
  • 用来显示状态机，一个状态机可用多张状态图描述
  • 状态图说明对象在它的生命期中响应事件所经历的状态序列

事务及解释

面向对象的设计目标与原则

设计的总体目标

面向对象设计基本原则

• 单一职责原则
• 开放封闭原则
• 接口隔离原则
• 依赖倒置原则
• 李氏替换原则
• 合成/聚合复用原则
• 迪米特原则

单一职责原则

一个类，最好只做一件事，只有一个引起它变化的原因

单一职责，强调的是职责的分离，在某种程度上对职责的理解，构成了不同类之间耦合关系的设计关键，因此单一职责原则或多或少成为设计过程中一个必须考虑的基础性原则

如果一个类中包含多个职责不同的方法，则把这个类拆分成多个类，保证每个类中只包含有一个职责的方法

开闭原则

• 考虑设计中什么可能会发生变化，将其封装起来，考虑允许什么发生而不让这一变化导致重新设计
• 声明的变量的类型、函数的参数类型、函数的返回类型等要尽量使用抽象类和接口

接口分离原则

设计时采用多个与特定客户类有关的接口比采用一个通用的接口好

一个类对另外一个类的依赖应建立在最小的接口上

将一个复杂的接口拆分成很多小接口

依赖倒置原则

• 高层模块不应该依赖于低层模块，二者都应该依赖于抽象
• 抽象不应该依赖于细节，细节应该依赖于抽象

某种意义上，依赖倒转原则是达到“开–闭原则”的途径

依赖关系应尽可能依赖接口（或抽象类），而不是某个具体的类

里氏替换原则

子类可以扩展父类的功能，但不能改变父类原有的功能

在软件中将一个基类替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象

里氏替换原则是继承复用的基石：只有当衍生类可以替换掉基类，软件单元的功能不受影响时，基类才能真正被复用

子类中对于一个方法的访问优先级应该不小于父类中的访问优先级

应注意的问题

• 子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。根据里氏替换原则，为了保证系统的扩展性，在程序中通常使用父类来进行定义，如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法。
• 我们在运用里氏替换原则时，**尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，**运行时，子类实例替换父类实例，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。
• 在系统设计时，遵循里氏替换原则，尽量避免子类重写父类的方法，可以有效降低代码出错的可能性。

迪米特法则

迪米特法则也称为最少知识原则，一个对象应对其他对象有最少的了解

由右侧改进为左侧

合成/聚合复用原则

要尽量使用合成/聚合，尽量不要使用继承。

合成/聚合复用原则就是在一个新的对象里面使用一些已有的老对象，使之成为新对象的一部分；新的对象通过向这些老对象的委派，达到复用已有功能的目的。

监听器

main(){
联想 联想1 = new 联想()
惠普 惠普2 = new 惠普()
	if(lian) lian.print()
        else if (hui) hui.print
}

interface dayinji{
    print()
}

class lianxiang implements dayinji{
    print(){
        lainxinagprint
    }
}

class huipu implements dayinji{
    print(){
        lainxinagprint
    }
}

main(){
    联想 联想1 = new 联想();
    惠普 惠普2 = new 惠普();

	print(Lianxiang);
}

print(dayiji dd){
    dd.print();
}
    
parent aa = new children();
aa.eat()
    
class parent{
    eat(){
        sout(parent)
            return a+b;
    }
}

class children extends parent{
    eat(){
        sout(children);
        
            return a-b;
    }
}

1.可行性分析

主要是对一个项目是否进行做出决定，一般由公司高层来决定，这种决策对公司尤其是创业公司至关重要。方向搞错了，执行力再强也没用。想创业的同学，这个问题定要多多思考哦。
可行性分析可能包括但不限于以下几个步骤：市场调研、技术难度、盈利能力等诸多方面。
a. 市场调研：对市场做一些具体的调查，主要对一些问题做出回答，比如市场是否有对项目的切实需求、市场中是否已经有公司或组织在做、是否符合法律法规。
b. 技术难度：公司是否有技术实现这个项目，其中技术人才是一个重要因素。

c. 盈利能力：能给公司或者组织带来多大的收入。

有的时候，是不需要考虑盈利能力的，比如第一次给其它公司做项目，只要成功了，今后自然还有项目再做。或者，这是一个公司内部的项目，主要是为了减少成本的。（我们也可称之为盈利的）
思考：很多时候，探讨一个项目是否值得做，价值不大。因为你只有去做了，可能是做了3年，
才发现这个项目有前景或者不值得做。不过Fans同学仍然认为，思考是有必要的。

2.需求分析

可行性分析中探讨市场需求时，这时的需求很可能是一个比较大而抽象的需求，需要在需求分析阶段细化需求。需求往往是很多的，而不是一个原子需求。

需求分类：功能需求、界面需求、性能需求。
a.功能需求：描述系统的功能，一般来说会细化成一个个的小功能，小到开发人员能够实现。
每一个小功能通常都有一个编号，比如F000001.
b.界面需求：打个比喻，系统的功能好比人的内涵，需要一些时间才能理解。
系统的界面好比人的外貌，长得美帅很可能立即吸引一批人。
举几个界面需求的小例子，整体界面布局，色彩，字体大小。
这类需求往往会有一个解决方案：系统皮肤。
c.性能需求：描述系统的性能，比如页面的响应时间，同时响应的请求数等。
d.稳定性需求：724365不停运作，商业重要项目中会有此要求；
每个月有一次或几次维护，在网游行业非常常见。
e.安全性需求: 保护系统内部数据不外泄等安全方面的需求，比如用户的帐号和密码，个人其它隐私信息。
f.其它需求：…
思考：时间或者进度是需求么？

3.架构设计

架构设计是从技术角度对系统进行一个全方位的规划，通常着眼于全局，而非局部细节。
没有最好的架构，架构都是根据需求来做的。架构通常都会有架构师参与。

包括但不限于以下几种事项：
a.选择项目开发所使用的技术，可能包括编程语言，数据库，框架或类库或平台。
b.定义系统技术基础，比如分布式平台的规划和部署、数据的流转等。
c.将系统划分为不同的模块，定义模块与系统技术基础之间的关系。
d.定义模块之间的接口或通信或者交互。一个系统通常会包含很多个模块，分模块开发体现了一种
分而治之的思想方法。定义模块之间的接口方便后期不同模块的整合。

4.详细设计

详细设计是将架构设计进一步细化，通常会比较细致，一方面方便开发人员具体开发，
另一方便于项目经理跟踪项目进度。

详细设计通常由开发人员来制定，可能会有以下任务：
a.模块内部的设计，大概怎么做得有个全局的思考，可能会书写详细设计文档。
b.完成自己的模块功能，通常会严格参照需求文档或者功能列表文档。

c.与其它模块的交互。

5.编码实现

一般来说，初级程序员编程时，对需求、架构、设计没有深入的考虑，也不是很有必要。老师布置了
一个任务，或者自己想要做个小项目，通常在内心都有一些考虑，然后就开始敲代码了。
生产环境下开发，急于编码是个大忌，有经验的人通常会认可此种观点。
原因分析：
a.需求变化的概率是非常大的，根据确定的需求编码往往不能适应变化。
b.即使需求不变，急于编码很容易考虑不周，结果往往是只实现了功能，却导致了性能差、逻辑不清、冗余代码多等种种问题。
比如，同一个功能，为了用户的方便，可能会有好几种操作界面，后台的功能实现既相似又有不同，急于编码非常容易导致代码冗余和混乱，维护起来非常费劲。尤其是在这次实习做项目中。o(︶︿︶)o
c.一旦编码有了一定的进展，对大多数人来说，就失去了重新开始的勇气。
有的时候，重新开始写优于重构，尤其是在需求或者设计发生变化时。

6.测试

根据需求和功能列表，写测试用例，然后测试系统。
根据Fans现在的经验来看，人工测试占了很大一部分。比如为了测试用户名和密码，手动输入 用户名和密码，且考虑到正确性和合法性等诸多情况，这样为了测试一个功能，往往会有很多个测试用例。时间久了，会让人感到厌烦和疲惫。

对于想在测试道路走下去的人，做个测试开发工程师、测试经理还是有挑战的。

7.验收

根据当初的项目计划或者产品计划，也可能是结合需求文档，来检查当前项目是否完全完成了当初的计划。
验收过程可能会和前面几个流程有些重复的地方，我的理解是9个流程之间存在一条主线：项目开发和维护。
验收的过程会涉及到很多事项，具体有哪些事项，可以"身临其境"来想。

8.部署

项目计划是振奋人心的，
需求分析是细致入微的，
架构设计是运筹帷幄的，
详细设计是指导方针的，
编码过程是艰苦卓绝的，
测试过程是精挑细选的，
验收过程是中规中矩的，
部署过程是春种秋收的，
维护过程是精心呵护的。

9.维护

a.保证现有软件持续正常运行
常见例子：
①服务器由于负荷太大，挂掉了，需要立即重启；
②网游为了保证系统稳定运行，每过一段有几个小时的维护时间。
③系统越来越慢，需要诊断原因，网络带宽问题还是内存泄漏还是CPU不够用。
b.二次开发
常见例子：
①百度有海量的搜索请求，分析下搜索请求，挖掘一些信息，比如浏览器的市场份额情况、统计热搜词。
（侧重于数据）
②使用系统API，做一些其它方面的功能。（侧重于功能）
c.系统升级
常见例子：
①QQ空间由5.0升级到6.0，公司内部做好开发，普通用户没有多大的影响。
如果想升级，点击一下按钮-升级到6.0，就可以了。
②天龙八部由2.0升级到3.0，客户端需要下载很多新的组件，然后更新，最后重新启动。
以上介绍的只是一些概念上的流程，很多地方都是自己的个人揣摩和猜测。
实际过程中的开发流程，各式各样，按照自己所在公司的流程来开发才是最合适的。

背景

20天的时间准备软件设计师，期间还要完善一些项目，时间比较仓促，特此总结一下软件设计师常用的考点，以便快速掌握。

本片博客对应于哔哩哔哩视频：软件设计师考试教程，可对应视频，参考学习，感谢UP主分享的视频。

看《软件设计师教程》的感悟：
《软件设计师教程》涵盖的知识面太宽泛了，看完了一遍书只能说大致理了以便思路，但是基本上什么也没记住，刷题的时候该不会还是不会。推荐将《软件设计师教程》作为目录/字典一样，刷题遇到不会的知识点，可以对应深入了解。

2020.11.7开始考试，不充分的准备，希望可以一次就过…，后续会更新考试情况和软考总结。

2021.03.05更新（软考结果）

2020下半年的软件设计师的考试成绩，早在2021年1月份的时候已经出来了，一直没来得及更新，这次考试上午场的选择题考了45分，下午场大题考了57分。按照近三年的分数线都是45分来算的话，推测应该刚好压线可以过。

在2月底的时候就已经可以查询证书，经过查询确实证书已经有效了，但是分数线还没有公布…

只准备了20天，算是比较仓促的吧，但还是可以压线过，一方面是运气，另一方面还是努力和技巧的结果吧，希望这篇博客对正在准备软件设计师的你，有所帮助。

分值分布

考点总结

计算机组成与体系结构

数据表示

进制转换

编码

正数的原码、反码、补码都相同

反码：原码除了符号位，取反

补码：在反码基础上+1

移码：补码基础上首位取反（一般用来做浮点运算的接码）

​

n=8

原码、反码：-127~127 补码：-128~127

因为补码正0和负0一样，少占一位；原码和反码不同。

浮点数运算

CPU结构

运算器

①算术逻辑单元ALU：数据的算术运算和逻辑运算

②累加寄存器AC：通用寄存器，为ALU提供一个工作区，用在暂存数据

③数据缓冲寄存器DR：写内存时，暂存指令或数据

④状态条件寄存器PSW：存状态标志与控制标志（争议：也有将其归为控制器的）

控制器

①程序计数器PC：存储下一条要执行指令的地址

②指令寄存器IR：存储即将执行的指令

③指令译码器ID：对指令中的操作码字段进行分析解释

④时序部件：提供时序控制信号

Flynn分类法

指令对应控制部分，数据对应处理器，主存模块只有单指令单数据的时候是一个。

CISC：复杂指令集；RISC：精简指令集

流水线

流水线相关概念

（1）流水线是指在程序执行时多条指令重叠进行操作的一种准并行处理实现技术。各种部件同时处理是针对不同指令而言的，它们可同时为多条指令的不同部分进行工作，以提高各部件的利用率和指令的平均执行速度。

（2）流水线建立时间：1条指令执行时间。

（3）流水线周期：执行时间最长的一段。

存储系统

Cache

Cache的相关概念：理论依据（局部性原理），大小、速度、成本等对比。

Cache映射方式：全相联、组相联、直接相联映像的对比（冲突率依次增高，电路复杂度依次降低）。

主存

内存

1、内存单元数计算：最大地址+1-最小地址

2、内存总容量：按字节编址，内存单元数 * 8bit；按字编址，内存单元数 * 机器字长。

3、已知芯片单位容量，求所用芯片的片数，总容量/单位容量；

4、已知所用芯片的片数，求取芯片单位容量，总容量/芯片片数。

磁盘

磁盘调度管理中，先进行移臂调度寻找磁道，再进行旋转调度寻找扇区。

最短移臂调度算法，即优先响应距离较近磁道的申请。

例：

读取一个记录3ms，处理一个记录3ms。读取完R0之后不能直接处理R1，因为需要处理R0，磁盘会继续转动。处理完R0后，磁头在R2不能直接处理R1，需要等到磁头再次转到R1时进行处理。

除了最后一个记录，其余处理为：（33+3）x10

最后一个记录：3+3（读取时间+处理时间）

最长时间：（33+3）x10+（3+3）

最短时间：进行信息优化，R0处理完，磁头指向R1（空间处理），依次读取，每有时间浪费。即（3+3）x11

总线系统

1、数据总线（Data Bus）：在CPU与RAM之间来回传送需要处理或是需要储存的数据。

2、地址总线（Address Bus）：用来指定在RAM（Random Access Memory）之中储存的数据的地址。

3、控制总线（Control Bus）：将微处理器控制单元（Control Unit）的信号，传送到周边设备，一般常见的为 USB Bus和1394 Bus。

可靠性

1、串联系统计算：R总=R1 * R2;

2、并联系统计算：R总=1-（1-R）^ n；

3、N模混联系统：先将整个系统划分为多个部分串联R1、R2…等，再计算R1、R2内部的并联可靠性，带入原公式。

差错控制-校验码

1、奇偶校验：掌握校验原则等相关概念，只检奇数位错，不能纠错。

2、循环校验码CRC：可查错，不可纠错，运用模二除法计算校验码。

3、海明校验：要求掌握相关概念，可查错，可纠错；要求掌握海明校验码校验位计算：2 ^ r>=r+m-1。

校验位放在2 ^ r，信息位放在其余位置上。

校验位计算方法：二进制计算位号，位号有的数字进行异或操作。

取反纠错

操作系统

进程管理

互斥的反义词为共享，同步的反义词为异步。

P：申请一个资源

V：释放一个资源

死锁及银行家算法

1、了解死锁的条件和预防概念；

2、根据题干给出的进程和资源分配，判断形成死锁的最小资源数或其他参数：对于这种情况，分配资源时每个进程得到可以完成进程的资源数减一，此时是形成死锁的最差情况，在此情况下多1个资源即可解决死锁问题，即不可能形成死锁。

3、银行家算法：当一个进程对资源的最大需求量不超过系统中的资源数时可以接纳该进程。

• 进程可以分期请求资源，但请求的总数不能超过最大需求量。

• 当系统现有的资源不能满足进程尚需资源数时，对进程的请求可以推迟分配，但总能使进程在有限的时间里得到资源。

• 根据银行家算法判断相关进程序列是否会形成死锁，是则为不安全序列。

存储管理

页面置换算法

1、页面淘汰时，主要依据原则：先淘汰最近未被访问的（访问位为0），其次淘汰但未被修改的（即修改位为0，因为修改后的页面）。

2、页面淘汰算法有多种，常用的是LRU即最近最少使用原则，依据的是局部性原理。

3、对于多种淘汰算法：最优算法OPT（理想型），随机算法RAND（随机性），先进先出FIFO（可能产生“抖动”），最近最少使用LRU（依据局部性原理）。

文件管理

索引文件

1、索引结点对应的索引方式一般题干会给出，没有给出的默认按照如图所示方式理解，下面的文件大小依图给出计算过程。

2、根据物理块大小（假设1KB）和地址项长度（假设4B），可以计算存放间接索引的物理块可以存放的地址项个数：物理块大小/地址项长度，向下取整（1KB/3B=256，注意单位和进制转换）。

3、直接索引（即索引结点直接指向实际存储文件的物理块），能够表示的逻辑页号范围是0~9，能够表示的文件大小时10*1KB。

4、一级间接索引（即索引结点指向的物理块存放的是地址项，对应地址项个数256个，可以指向256个实际存储文件的物理块），能够表示的逻辑页号范围是10~265，能够表示的文件大小是256*1KB。

5、二级间接索引（即索引结点指向的物理块存放的是间接索引的地址项，共256个，可以指向256个存放地址项的物理块，每个物理块指向实际存储文件的地址项有256个，最终指向的物理块共有256*256个），能够表示的逻辑页号范围是266~65801，能够表示的文件大小是65536KB。

目录结构

位示图

1、对于位示图，每一个bit位可以表示一个磁盘的占用情况，“0”表示空闲，“1”表示占用。

2、对于字的长度与具体机器字长有关，有题目指定，假设机器字长16位，则每个字可以表示16个磁盘块的占用情况；

3、指定序号为n或第n+1个磁盘，占用情况需要用m=(n+1)/16（向上取整）个字表示，字的序号为m-1。注意其中磁盘序号、字的序号、对应位号都是从0开始，计算过程中会有加1或减1处理。

磁盘管理

本知识点的考查形式有：计算磁盘数据的读取时间；优化存储后的数据读取时间；磁盘调度算法的相关概念判断正误

1、存取时间=寻道时间+等待时间，寻道时间是指磁头移动到磁道所需的时间；等待时间为等待读写的扇区转到磁头下方所用的时间。有时还需要加上数据的传输时间。

2、在处理过程中，如果有关于缓冲区的使用，需要了解对于单缓冲区每次只能被一个进程使用，即向缓冲区传输数据的时候不能从缓冲区读取数据，反之亦然。

3、对于磁盘存储的优化，是因为磁头保持转动的状态，当读取数据传输或处理时，磁头会移动到超前的位置，需要继续旋转才能回到逻辑下一磁盘块，优化存储就是调整磁盘块的位置，让逻辑下一磁盘块放到磁头将要开始读取该逻辑块的位置。

4、磁盘调度算法：先来先服务FCFS（谁先申请先服务谁）；最短寻道时间优先SSTF（申请时判断与磁头当前位置的距离，谁短先服务谁）；扫描算法SCAN（电梯算法，双向扫描）；循环扫描CSCAN（单向扫描）。

I/O设备管理

1、对于I/O传输控制方式：

程序查询方式（CPU一直处于询问、等待的过程，占用CPU时间最长，CPU利用率最低）；

中断方式（I/O完成后向CPU发送中断请求信号，CPU和I/O可以并行）；

DMA（CPU只做初始化，不参与具体数据传输过程）；通道方式、I/O处理机，专用硬件方式。

2、对于I/O软件：

虚设备与SPOOLING技术

1、SPOOLING技术的应用场景和相应概念：SPOOLing是关于慢速字符设备如何与计算机主机交换信息的一种技术，通常称为“假脱机技术”。 SPOOLing技术通过磁盘实现。

2、对于SPOOLING技术的过程：

微内核操作系统

数据库

数据库模式

本知识点的主要考查方式是判断模式（外模式、模式、内模式）与产物（视图、库表、文件）的对应关系，或给定一些概念描述判断正误。

1、三级模式：外模式对应视图，模式（也称为概念模式）对应数据库表，内模式对应物理文件。

2、两层映像：外模式-模式映像，模式-内模式映像；两层映像可以保证数据库中的数据具有较高的逻辑独立性和物理独立性。

3、逻辑独立性：即逻辑结构发生改变时，用户程序对外模式的调用可以不做修改；物理独立性：即数据库的内模式发生改变时，数据的逻辑结构不变。

数据库设计过程

E-R模型

关系代数

• 并
• 交
• 差
• 笛卡尔积
• 投影
• 选择
• 联接

参考：https://www.cnblogs.com/buxingzhelyd/p/7842907.html

规范化理论

函数依赖

键

范式

模式分解

无损分解：

并发控制

数据库安全

备份恢复

数据仓库与数据挖掘

反规范化

计算机网络

七层模型

网络技术标准与协议

网络类型与拓扑结构

网络规化与设计

IP地址与子网划分

特殊含义IP地址

无线网

网络接入技术

IPv6

系统安全分析与设计

加密解密

网络层次安全保障

网络威胁

防火墙

数据结构与算法

矩阵

选择题，可直接使用特殊值代入法。

对比顺序存储与链式存储

广义表

表尾是除了表头的所有元素。

树与二叉树

二叉树遍历

先序遍历：根节点、左子树、右子树

中序遍历：左子树、根节点、右子树

后序遍历：左子树、右子树、根节点

反向构造二叉树

有前序、中序或者有中序后序，可以反向构造；但是只有前序、后序则不能构造。

树转二叉树

查找（排序）二叉树

最优二叉树（哈夫曼树）

主要用于哈夫曼编码，即带权路径长度最短。

最后计算所有叶子结点(圆)的权值和，不计算矩形（设想的）。

线索二叉树

为什么？空闲大量的节点。

利用没有左/右孩子节点的节点，指向特定节点。

平衡二叉树

图

图的节点为n，边最少为n-1。

图的存储

邻接矩阵大小取决于节点数量。

图的遍历

拓扑排序

图的最小生成树

不能形成环（树与图的最大区别）

普里姆算法

克鲁斯卡尔算法

程序设计语言

编译过程

有限自动机与正规式

代入法求解。

表达式

先构造二叉树，然后进行相应的遍历。

传值与传址

程序语言特点

法律法规

保护期限

知识产权人

侵权判定

标准化

多媒体

音频

媒体分类

计算

小写k1000，大写K1024，单位换算。

多媒体标准

文件压缩

软件工程

软件开发模型

信息系统开发方法

需求

结构化设计

软件测试

系统运行与维护

CMMI软件能力成熟度模型

项目管理

面向对象

设计模式

UML

数据流图（大题）

基本概念

数据字典

数据流图平衡原则

解题技巧

例题

数据库设计（大题）

UML建模（大题）

用例图

类图

顺序图

活动图

状态图

通信图

案例

数据结构与算法（大题）

分治法

回溯法

贪心法

动态规划

案例1

面向对象（大题）