软件系统分析与设计考试重点、复习指导及复习笔记汇总

本文内容均整理自西安交通大学软件学院饶元老师的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;
    }
}