软件需求工程

软件需求工程

文章目录

第一章 软件过程

软件开发的本质

软件开发的不变事实

​ 一致性:应用软件必须与所基于的特定硬件/软件相符合,也必须与现有的信息系统相符合,并继承在一起

​ 可变性:业务过程和需求会不断地变化

​ 不可见性:负责输出的代码通常深深地隐藏在“不可见”的程序语句,二进制代码库,以及周边的系统软件中

软件开发的意外事件

1.利益相关者

  • 客户
    • 客户的需求被误解或者没有被完全捕获
    • 客户的需求改变过于频繁
    • 客户没有准备为项目提供足够的资源
    • 客户不想与开发者合作
    • 客户怀有不切实际的期望
    • 软件不再对客户有利
  • 开发者(分析员,设计员,程序员等)
    • 开发者不能胜任

2.过程

  • 声明了所执行活动的次序
  • 详细说明要交付哪些开发的人工制品,以及什么时候交付
  • 将活动和人工制品分配给开发者
  • 提供用来监控项目进展,评估结果和规划未来项目的标准

3.建模

UML:Unified Modeling Language 统一建模语言

  • 状态模型:描述静态数据结构
  • 行为模型:描述对象协作
  • 状态变化模型:描述随着时间的推移,系统所允许的状态

软件生命周期的5个阶段

  • 业务分析

    确定和详细说明需求,开发和集成系统的功能和数据模型,并捕获非功能 性需求和其他系统约束

  • 系统设计

    包括体系结构设计和详细设计。对涉及客户端的用户界面和服务器端的数据库对象的程序设计进行解释。提出影响系统可理解性,可维护性和可扩展性的各种设计问题,并对其文档化

  • 实现

    对客户端应用程序和服务器数据库进行编码、测试等,保证系统实现复合系统设计

  • 集成和部署

    将系统的组成构建组装在一起,以及与外部系统的对接

  • 运行和维护(从上到下)

    使用新系统替换老系统,保障新系统的正常运行,并承接对新系统的修正和扩展工作

软件生命周期个阶段输入输出

软件需求工程

主要的开发模型与方法

  • 瀑布模型
  • 螺旋模型
  • 敏捷开发
  • 面向方面开发

瀑布模型

要求每一个阶段都有明确的文档产出,对于严格的瀑布模型每一个阶段都不应该重叠,而应该在评审通过、相关的产出物都已经基线后才能进入到下一个阶段。就是说瀑布模型一般是按顺序执行的
软件需求工程

螺旋模型

螺旋模型并不是一个完全独立的模型,而是与瀑布模型有着内在联系。它遵从瀑布模型“需求->架构->设计->编码->测试”的路线。其最大的特点是整个开发过程是迭代的和风险驱动的。就是通过将瀑布模型的多个阶段转化到多个迭代过程中,以减少项目的风险
软件需求工程

敏捷开发

定义:敏捷开发是一种价值观与原则,指导我们更加高效的开发。以用户需求为核心,采用迭代(时间周期)、增量(循序渐进,功能模块)的方式开发软件,目的在于快速覆盖,响应市场需求

特点:

  1. 迭代开发
  2. 增量交付
  3. 开发团队和用户反馈推动产品开发
  4. 持续集成
  5. 开发团队自我管理

敏捷开发流程
软件需求工程

面向方面开发(AOP)

AOP的主要目标是通过识别所谓的横切关注点,以及为这些关注点生产独立的软件模块来生产出更加模块化的系统。这些模块称为方面,利用方面编排的过程将方面集成起来

AOP的几个概念:

  • 方面:功能模块,AOP将系统分解成许多方面,这些方面构成了核心功能构建,称为基础代码
  • 连接点:软件组成的预定义的点,例如对方法的调用,对属性的访问,对象的实例化和抛出异常等
  • 通知:需要为连接点采取的特定动作称为通知(例如,检查用户的安全性权限,或开始一个新的业务事实)。通知可以在连接点执行之前运行(前置通知),也可以在连接点完成之后运行(后置通知),或者可以取代连接点的执行(环绕通知)
  • 方面编排:方面构成了单独的方面的代码,为了这样的系统能够运行,软件构件必须由方面组成,必须将方面编排到程序的逻辑流中,这样的一个软件组成过程称为方面编排
  • 切入点:同一个通知可以应用到程序的许多连接点,与单个通知相关的一组链接称为切入点

面向方面开发(AOP)流程

软件需求工程

第二章 需求确定

从业务过程到解决方案构想

主要内容

  • 过程层次建模
  • 业务过程建模
    • 流对象
      • 事件
      • 活动
      • 路由
    • 连接对象
    • 泳池
    • 人工制品
  • 解决方案构想

过程层次建模

  • 业务过程模型

    可以通过多个不同大小的过程来定义,从全业务范围内的过程到单独一个人完成的过程

  • 过程和过程分解

    一个过程至少有一个输入流和一个输出流。过程获得控制,主要通过将输入流转变为输出流来完成响应的活动。过程可以是原子过程或者复合过程,原子过程不包含任何子过程。复合过程通过子过程来描述它的行为

  • 过程层次图

    对过程模型的图形化展示

业务过程建模

业务过程建模的基本元素

  1. 流对象
    • 时间:某些“发生”的事物,通常由一个原因(触发器)或者产生一个影响
    • 活动:某些必须进行的工作,可能是一项任务或者一个子过程
    • 路由:用来控制多个序列流的分支和聚合
  2. 连接对象:用来连接流对象
    • 序列流:用来表示一个过程中活动完成的序列
    • 消息流:用来表示准备发送和接收消息的两个业务实体(过程参与者)之间的消息(数据)
    • 关联:用来关联两个流对象,或者关联一个人工制品与一个流对象
  3. 泳池:表示一个过程中的业务实体(参与者)
  4. 人工制品:提供附加的建模灵活性,允许我们扩展基本表示法来应对特殊的建模环境。可以预定义3中类型的人工制品:数据对象,组合注释
    • 数据对象:表示活动需要的数据或者活动产生的数据
    • 组:是不影响过程序列流的一组活动
    • 注释:为业务过程图的读者提供附加的文本信息

解决方案构想

  • 常规开发

    手工的,单机的,从零开始的软件开发覆盖了软件开发过程的所有阶段(生命周期)

  • 基于包开发

    通过定制先前存在的软件包来得到解决方案

  • 基于构件开发

    通过集成来自多家销售商或者商业伙伴的软件来构建解决方案

需求引导

系统需求

  • 功能性需求

    定义系统期望的服务(服务陈述)和系统必须遵守的约束(约束陈述)

    包括:系统的范围,必要的业务功能和所需的数据结构

  • 非功能性需求

    非功能性需求本质上不是行为的,而是系统开发和实现过程中的约束

    1. 可用性:定义使用系统的容易程度。当一个系统更容易使用的时候 ,它就具有更强的可用性。文档和帮助实施,为高效使用提供必要的培训,用户界面的美观和一致性,错误处理等,这些都决定了可用性
    2. 可复用性:定义在新系统的开发中,重复使用之前已实现的软件构件的容易程度。可复用性反映了软件开发团队和作为工业领域的软件工程的成熟度
    3. 可靠性:与系统失效的频率和严重性以及系统从失效中恢复的程度相关。可靠性由系统运行时间内所要求的系统有效性,可接受的失效之间的平均时间,产生结果的正确性等因素决定。一个可靠的系统是可信任,用户能够信任并依赖它的
    4. 性能:通过系统响应时间,事务处理时间,资源开销,可能的并发用户数量等的期望来确定
    5. 效率
    6. 适应性

需求引导的传统方法

与客户和领域专家面谈

3中问题避免:

  1. 固执己见的问题
  2. 带偏见的问题
  3. 强加的问题

5W原则:

  • what:何事
  • who:何人
  • when:何时
  • where:何地
  • why:为什么

调查表:

​ 作为面谈的补充形式

文档和软件系统的研究:

​ 文档和软件系统的研究是发现用例需求和领域知识需求的宝贵技术。用例需求通过研究已有的企业文档和系统表格/报告来发现。对用例需求最有价值的了解方式之一是缺陷的记录和现有系统的变更请求

需求引导的现代方法

原型法:

​ 概念:是最常用的需求引导方法

​ 通常,当使用其他方法很难从客户那里获得需求时,系统原型是一种非常有效的需求引导方法。给客户演示一个系统,使整个系统或者系统的一部分对用户可视化,以便获得他们的反馈

  • 丢弃原型
  • 进化原型

头脑风暴

  • 通过放下公正、社会禁忌和规则来产生新思想或者发现专业问题解决方案的一种会议技术
  • 通常,头脑风暴不是为了分析问题或者作出决定,而是产生新思想或者可能的解决方案
  • 头脑风暴的特点
    1. 会议主持:界定问题/机会领域
    2. 会议的范围:议题
    3. 限制会议人数12-20人
    4. 记录问题的答案
    5. 投票表决想法的优先顺序

需求协商与确认

为什么需要进行需求协商与确认?

  1. 来自客户的需求也许是重叠的或者矛盾的
  2. 有些需求可能是模棱两可或者不可实现的
  3. 有一些需求可能还没有发现

需求协商

​ 通常以文档的草稿为基础,如果有必要,要对文档草稿中列出的需求进行协商和修正,删除错误的需求,增加新发现的需求

需求确认

​ 需要完整的需求文档,所有的需求都要被清楚地标识和分类

需求协商和需求确认需要解决下面3个问题

  1. 超出范围的需求:超出体系设计范围得到需求。设定设计范围是需求分析阶段的重要课题
  2. 需求依赖矩阵:梳理标识需求之间的依赖关系
  3. 需求风险和优先级:对需求进行风险分析和排列优先级

需求管理

需求标识和分类

​ 按某种标识方案对需求进行编号,这个方案可能包含将需求划分为更多的可管理组的需求分类

​ 分类方案

  • 唯一标识符
  • 在文档层次内的顺序编号
  • 在需求分类中的顺序编号

需求层次

​ 需求可以按父子关系建立层次结构

需求变更

​ 在开发生命周期的任何阶段,需求都可能变更,可能删除已有需求或者增加新的需求

需求文档

需求文档的主要内容

  • 项目准备
  • 系统服务
  • 系统约束
  • 项目其他问题
  • 附录
    软件需求工程

第三章 可视化建模基础 - 时序图

一、概念

  • 显示对象之间交互的图

  • 对象按时间顺序排列

  • 显示参与对象之间消息交互的顺序

    示例:
    软件需求工程

二、包含的元素

  1. 角色(Actor)

    用以表示和系统进行交互的参与者角色,不一定是人也可以是物或者系统。UML时序图中用一个小人来表示角色

  2. 对象(Object)

    对象就是类的实例。UML时序图中用矩形框来表示对象

  3. 控制焦点(Focus of Control) / **(Activation)

    控制焦点代表对象在某一用例过程中执行某一操作的时间。UML时序图中用方块来表示控制焦点

  4. 消息(Message)

    消息是角色和对象或者对象与对象之间的信息传递。消息分为四种:同步消息、异步消息、返回消息和自关联消息

    • 同步消息(Synchronous Message)

      把信息传递给接受者后,停止活动,等待返回结果

    • 异步消息(Asynchronous Message)

      把信息传递给接受者后,不用等待返回结果。可以直接开始下一个活动

    • 返回消息(Return Message)

      代表从过程调用返回

    • 自关联消息(Self-Message)

      自关联消息表示方法的自身调用或者一个对象内的一个方法调用另外一个方法
      软件需求工程

第三章 可视化建模基础 - 状态图

一、概念

  • 主要用于描述一个对象在其生存期间的动态行为,表现为一个对象所经历的状态序列,引起状态转移的事件(Event),以及因状态转移而伴随的动作(Action)
  • 从对象的初始状态起,开始响应事件并执行某些动作,这些事件引起状态的转移;对象在新状态下又开始响应事件和执行动作,如此连续进行直到终结状态
  • 状态图(State Diagram) = 状态(State) + 迁移(Transition)

二、包含的元素

状态

  • 指在对象的生命周期中的某个条件或者状况,在此期间对象将满足某些条件、执行某些活动等。所有对象都有状态,状态是对象执行了一系列活动的结果,当某个事件发生后,对象的状态将发生变化

状态组成:

  • 状态 = 状态名 + 动作(可选)
    • entry:入口动作,当进入一个状态的时候执行
    • do:内部活动,当状态处于**时执行
    • exit出口动作,当离开一个状态的时候执行

状态分类:

  • 简单状态:没有子结构的状态
  • 复合状态/组合状态:被分成两个或者多个并发子状态,当复合状态被**时,所有的子状态均被**
  • 初始状态:表示状态机状态的起点
  • 终止状态:表示完成了状态机的状态转换历程中的所有活动

转移

  • 转移是两个状态之间的一种关系,表示对象将在源状态中执行一定的动作,并在某个特定事件发生而且某个特定的警界条件满足时进入目标状态

转移的组成:

  • 事件标记(Trigger):是转移的诱因,可以是一个信号,事件,条件变化和时间表达式
  • 警界条件(Guard Condition):当警界条件满足时,事件才会引发转移
  • 结果(Effect):对象状态转移后的结果

线程状态图

  1. 新建:初始化对象,new Thread()
  2. 就绪:调用start()
  3. 运行:执行run()方法
  4. 阻塞:
    • 等待阻塞:运行(running)的线程执行o.wait()方法,JVM会把该线程放入等待队列(waitting queue)中
    • 同步阻塞:n运行(running)的线程在获取对象的同步锁时,若该同步锁被别的线程占用,则JVM会把该线程放入锁池(lock pool)中
    • 其他阻塞:n运行(running)的线程执行Thread.sleep(long ms)或t.join()方法,或者发出了I/O请求时,JVM会把该线程置为阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时,线程重新转入可运行(runnable)状态
  5. 销毁:run()方法执行完成

第三章 可视化建模基础 - 类图

一、概念

​ 类视图 = 类(类的内部结构)+ 关系

软件需求工程

二、包含的元素

  1. 属性
  2. 方法

三、关系

  1. 泛化

    • 是一种继承关系,表示一般与特殊的关系,它指定了子类如何特化父类的所有非private修饰的特征和行为
    • 带三角箭头的实现,箭头指向父类
    • 表示的类和类之间,以及接口与接口之间的关系。类是单继承,接口时多继承

    软件需求工程

  2. 实现

    • 实现和java中的实现是一个意思,是一种类与接口的关系,表示类是接口特征和行为的实现
    • 带三角箭头的虚线,箭头指向接口

    软件需求工程

  3. 关联

    • 是一种拥有(has a)的关系,它使一个类知道另一个类的属性和方法,即:一个对象A中持有对象B的引用,对象A就可以使用对象B的方法和属性。在实际的代码中提现在一个类上声明一个成员变量

    • 带普通箭头的实现,箭头指向被拥有者
      软件需求工程

    • 双向关联

      默认情况下,关联是双向的。例如顾客与商品之间
      软件需求工程

    • 单向关联

      类的关联关系也可以是单向的,单向管理有带箭头的实现表示

    软件需求工程

    • 自关联

      在系统中可能会存在一些类的属性对象类型为该类本身,这种特殊的关联关系称为自关联
      软件需求工程

    • 多重性关联

      多重性关联关系又称为重数性(Multiplicity)关联关系,表示两个关联对象在数量上的对应关系。在UML中,对象之间的多重性可以直接在关联直线上用一个数字或一个数字范围表示。

      对象之间可以存在多种多重性关联关系,常见的多重性表示方式如下所示:

    软件需求工程

  4. 聚合

    • 是整体与部分的关系,且部分可以离开整体而单独存在
    • 聚合关系是关联关系的一种,是强的关联关系;关联和聚合在语法上无法区分,必须考察具体的逻辑关系
    • 在代码实现聚合关系时,成员对象通常作为构造方法、Setter方法或业务方法的参数注入到整体对象中
    • 带空心菱形的实线,菱形指向整体,箭头指向部分
      软件需求工程
  5. 组合

    • 是整体与部分的关系,但部分不能离开整体而单独存在
    • 组合关系时关联关系的一种,是比聚合关系还要强的关系,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期
    • 在代码实现组合关系时,通常在整体类的构造方法中直接实例化成员类
    • 带实心菱形的实现,菱形指向整体,箭头指向部分
      软件需求工程
  6. 依赖

    • 是一种使用的关系,即一个类的实现需要对另一个类的协助,所以要尽量不使用双向的互相依赖
    • 代码实现:局部变量、方法的参数或者对静态方法的调用
    • 带箭头的虚线,箭头指向被使用者,虚线出发表示使用者

    软件需求工程

    各种关系的强弱顺序:

    泛化>实现>组合>聚合>关联>依赖

    总结:

    1. 依赖关系:关系对象出现在局部变量或者方法的参数里,或者关系类的静态方法被调用
    2. 关联关系:关系对象出现在实例变量中
    3. 聚合关系:关系对象出现在实例变量中,成员对象通常作为构造方法、Setter方法或业务方法的参数注入到整体对象中
    4. 组合关系:关系对象出现在实例变量中,通常在整体类的构造方法中直接实例化成员类
    5. 泛化关系:extends
    6. 实现关系:implements

第三章 可视化建模基础 - 用例图

一、概念

​ 用例图(Use Case Diagram):主要用于描述系统的行为及各种功能之间的关系,是描述参与者(Actor)与用例以及用例与用例之间关系的图

​ 用例图 = 参与者 + 用例 + 关系

二、用途

  • 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务
  • 通俗的说:描述参与者与用例之间的关系,帮助开发人员可视化的了解系统功能

三、包含的元素

  1. 参与者(Actor)

    • 参与者可以是人或其他外界系统
    • 参与者是用例的启动者,参与者处于用例的外部并且能够初始化一个用例并参与用例的执行过程,但它并不是系统的一部分
    • 每个参与者可以参与一个或多个用例
  2. 用例(Use Case)

    • 用例是一组动作序列(业务工作流程)的描述,系统执行该动作序列为系统的参与者产生一个可观察的结果
    • 用例反映用户的需求
    • 用例是系统的使用过程,是对系统的用户功能需求的描述,用例表达了系统的功能和所提供的服务
  3. 关系

    • 关联关系:参与者与用例之间进行关联。表示参与者可以启动(使用)该用例

    • 包含关系:用例与用例之间的关系
      把几个用例的公共步骤分离成一个单独被包含用例;包含用例称为客户用例,被包含用例称为提供者用例。用例A包含用例B,将A称为基用例,B称为被包含用例

      包含关系表示基用例一定会用到被包含用例。被包含用例的事件流在基用例的某个点处插入到基用例的事件流中

    • 扩展关系:用例与用例之间的关系

      扩展使得每个用例可以通过扩展用例向基用例中添加额外的行为来扩展基用例的功能。用例A扩展了用例B,那么A称为扩展用例或子用例,B表示为基用例
      扩展用例A的事件流在一定的条件下按照相应的扩展点插入到基用例中,这就需要在基用例中定义一至多个已命名的扩展点

    • 泛化关系:继承,泛化关系是两个用例或两个参与者之间的关系。
      泛化关系其实可以通俗理解为面向对象关系中的继承。将拥有一种类似的结构和行为的多个用例中的共性抽象为父用例,子用例继承父用例中的所有

    • 扩展关系和包含关系的区别?

      • 相同点:
        都是两个用例之间的关系。(只有泛化关系不仅可以表示两个用例,还可以是两个参与者之间)
      • 不同点:
        • 条件性:
          包含关系是无条件的
          扩展关系是有条件的
        • 插入原则:
          包含关系中被包含用例的事件流一定插入到基用例中去。
          扩展关系可以根据一定条件来决定是否将扩展用例的事件流插入到基用例事件流
        • 插入点:
          包含关系中插入点只有一个
          扩展关系的插入点可以有多个
  4. 系统边界

    界定系统的范围,在UML用例视图中使用system元素表示软件系统的范围。System可以包含一些用例,并界定系统的边界,边界之内的属于系统的功能和行为,边界之外的则不是系统所关心的内容

第四章 需求规格说明 - MVC模型

一、概念

​ Model View Controller。用一种业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑

​ MVC分层开发= 视图层 + 控制层 + 数据模型层

二、组成结构

  • 模型(Model):负责存储系统的中心数据
  • 视图(View):将信息显示给用户(可以定义多个视图)
  • 控制(Controller):处理用户输入的信息。负责从视图读取数据,控制用户输入,并向模型发送数据,是应用程序中处理用户交互的部分。负责管理与用户交互交互控制

三、MVC模型在B/S架构中的实现

Browser/Server

软件需求工程

软件需求工程

BS架构的典型实现:

  • View:JSP动态进行页面展示;CSS 页面样式设计;JS(JQuery,Nodejs,Layui,EasyUI,BootStrap,AngularJs,Reactjs,VUE等)页面业务逻辑及页面框架设计,Ajax 异步请求
  • Controller:servlet,Structs,SpringMVC/SpringBoot
  • Model:数据模型Bean/POJO,服务层,持久化(JDBC,Hibernate,Mybatis)

第四章 需求规格说明 - 概念数据模型

一、概念

​ Conceptual Data Model(CDM):概念数据模型,它以实体-联系(Entity-RelationShip, E-R)理论为基础,并对这一理论进行了扩充。它从用户的观点出发对信息进行建模,主要用于数据库的概念级设计

​ 概念数据模型=实体+联系

二、包含的元素

  1. 实体

    • 属性(Attribute)
    • 数据类型(Data type)
    • 标识符:表示实体属性的约束
      • 常用标识符:
        • Mandatory:属性是否允许为空
        • Primary Identity:表示是否为主标识
        • Display:表示属性是否在模型图中展示
  2. 数据域(Domain)

    域是具有相同数据类型值得集合,可以被多个实体的属性以及数据项共享

    • 类似于数据字典,常用于属性的值是固定的几个的情况
    • 定义一个数据域可以应用到多个实体中
    • 域发生变化只需求修改域的定义即可,无需逐个修改实体
  3. 数据项(data item)

    即实体的属性。定义好数据项(属性),在实体中可以直接添加已经定义的数据项

    一个数据项可以在多个实体中使用

    • 对于公共的属性,无需在多个实体中重复敲入
    • 属性发生变化只需要修改域的定义即可,无需逐个修改实体的属性
  4. 联系(Relationship)

    指两个实体之间或者实体内部的连接或关系
    完成实体定义以后,应该在它们之间建立联系。实体的联系通常是依据业务规则确定的

    包括的类型:

    • 一对一:对象A只能有一个对象B
    • 一对多:对象A可以有多个对象B
    • 多对一:对象B可以有多个对象A
    • 多对多:对象A可以有多个对象B,对象B可以有多个对象A

第四章 需求规格说明 - 物理数据模型

一、概念

​ Physical Data Model(PDM):物理数据模型,是面向计算机物理表示的模型,描述了数据在储存介质上的组织结构

  • 进行数据库体系结构设计,真正实现数据在数据库中的存放
  • 与具体的DBMS 有关
  • 物理数据模型的内容包括确定所有的表和列,定义外键用于确定表之间的关系,基于用户的需求可能进行规范化等内容

二、包含的元素

  1. 数据库表,表信息与数据模型的DBMS一致

  2. 视图

    • 视图是从一个或几个基本表(或视图)中导出的虚拟的表。在系统的数据字典中仅存放了视图的定义,不存放视图对应的数据
    • 视图使用查询语句创建,可以定义视图只查或者可修改模式
  3. 索引

    索引其实是一种数据结构,其功能是帮助我们快速匹配查找到需要的数据行,是数据库性能优化最常用的工具之一。其作用相当于超市里的导购员、书本里的目录

    索引类型:

    • 主键索引 PRIMARY KEY:一种特殊的唯一索引,不允许有空值。一般是在建表的时候同时创建主键索引
    • 唯一索引 UNIQUE:唯一索引列的值必须唯一,但允许有空值
    • 普通索引 INDEX:最基本的索引,它没有任何限制
    • 组合索引 INDEX:组合索引,即一个索引包含多个列
    • 全文索引 FULLTEXT:全文索引

    索引设计的原则:

    • 适合索引的列是出现在where子句中的列,或者连接子句中指定的列
    • 基数较小的类,索引效果较差,没有必要在此列建立索引
    • 使用短索引,如果对长字符串列进行索引,应该指定一个前缀长度,这样能够节省大量索引空间
    • 不要过度索引。索引需要额外的磁盘空间,并降低写操作的性能。在修改表内容的时候,索引会进行更新甚至重构,索引列越多,这个时间就会越长。所以只保持需要的索引有利于查询即可
  4. 主键

    主键约束即在表中定义一个主键来唯一确定表中每一行数据的标识符。主键可以是表中的某一列或者多列的组合,其中由多列组合的主键称为复合主键

    基本特性:非空,唯一

  5. 外键

    • 建立表与表之间的关联关系。让表与表之间的数据,更加的完整,关连性更强
    • 设置外键约束的两个表之间会具有父子关系,即子表中外键的字段的取值范围由父表所决定

第四章 需求规格说明 - 数据持久化

一、概念

  • 将内存中的数据模型转换为存储模型,以及将存储模型转换为内存中的数据模型的过程. 数据模型可以是任何数据结构或对象模型,存储模型可以是关系模型、XML、二进制流等
  • 通常指的内存数据与数据库模型的转换

二、关系型数据库模型 oracle/mysql/sql server等

  • 表的元素:

    • 列名:命名要有意义,使用驼峰格式
    • 数据类型:int、float、varchar、date等
    • 约束:非空、唯一、主键、外键、自增长等
  • 表数据操作:

    • 增:insert into table values();
    • 删:delete from table where xxx=xxx;
    • 改:update table set xxx=xxx,yyyy=yyy;
    • 查:select * from table;
  • 聚合函数:

    • Count(*):数据数量
    • Sum():求和
    • Avg():求平均数
    • max():求最大值
    • Min():求最小值
  • 子查询:

    • in/not in
      将子查询的结果作为主查询的条件
    • exists/not exists
      将主查询的数据,放到子查询中做条件验证,根据验证结果(TRUE 或 FALSE)来决定主查询的数据结果是否得以保留
  • 联合查询:

    • 全连接:取数据并集
    • 内连接:取数据交集
      select * from student a,SCORE B WHERE A.student_id=B.student_id;
    • 左连接 left join: 取左表的所有数据。
      select * from student a LEFT OUTER JOIN score b on a.student_id=b.student_id;
    • 右连接 right join:取右表的所有数据。
      select * from student a RIGHT JOIN score b on a.student_id=b.student_id;
  • 分组查询:

    • group by
    • having
  • 存储过程

    数据库编程技术,完成特定功能的sql集。包括:变量定义,变量赋值,游标,sql语句(DML),输入输出参数等

    软件需求工程

三、对象关系映射

  • 概念:

    用于实现面向对象编程语言里不同类型系统的数据之间的转换,建立对象和数据库数据表的映射,便于开发进行对象和数据库表之间的交互(持久化)

  • ORM的实现:Hibernate/Mybatis

  • Mybatis映射类型:

    • 简单映射:表字段和对象属性一对一映射
    • 级联映射:
      • 一对一关系:ResultMap>Assocation
      • 一对多关系:ResultMap>Collection
  • Mybatis对ORM的支持
    软件需求工程
    软件需求工程