需求模型

事件

分类

• 外部事件
  • 发生在系统之外
  • 由外部的代理人或参与者所启动
• 临时事件（定时事件）
  • 在到达某个时间点之后，自动发生的事件
  • 根据系统的截止日期
• 状态事件
  • 系统内部发生的某件事触发处理的需要

事件列表

• 事件：造成系统去完成某事的事件。
• 触发：定义系统处理程序的时间点。
• 来源：发起事件的某一个实体。
• 用例：事件发生时，系统会做什么。
• 回应：输出事件处理的结果，由系统产生。
• 目的地：获得回应信息的实体。

事物

分类

• 有形的事物：飞机、车辆、书籍、文件
• 扮演的角色：顾客、学生、系统管理员
• 相关的单位：科室、部门、特别小组
• 装置：提示器、键盘、控制器、感应器
• 场所位置：仓库、工厂、零售店、桌面
• 偶发意外、事件或互动：飞行、服务电话、登入、登出、付款

特征

关系

• 特定事物间自然发生的关联性（可发生在两个方向）
• 关联数目是 基数 或 多重性
  • 二元关系、一元关系、三元关系、n元关系

关系会自然发生在两个事物之间：

• Smith 所下 订单
• Smith 工作于 会计部门

属性

关于事务的特殊属性

实体关系图（ERD）建模

数据实体

• 在传统开发方法中，系统需要储存相关信息的事物。
• 用来产生数据库的设计模型，通常是关系型数据库。

对象

• 在面向对象方法中，对象会在系统中从事工作并储存信息。
• 对象同时具有行为和属性：
  • 类别：事物的类型
  • 对象：特殊的事物
  • 方法：类别中所有对象都能执行的行为
• 每个对象都包含属性值，以及在这些属性上运作的方法。
• 对象的封装：自给自足的单位。

实体关系图(ERD)

步骤

首先，在事件列表中找名词，其次绘制概念图（鸡爪图），然后在物理层整理组件，最后检查是否有传递依赖（合并重复的冗余表/数据）

一对多

实体连接逻辑

连接线的端点属性

多对多

当两个实体之间的关系为多对多时，需要在二者之间插入一个储存两者相关信息的关联实体。

工具选择

• 简单工具(viso、draw.io)。
• 正向工程：通过逻辑表建立实表。(powerDesign)
• 逆向工程：通过已存在的数据库建立E-R图。

类别图（UML）

组成

类与类之间的关系

在某种程度上类图（与存储相关的类）可以表示数据库中的表间关系。

泛化(一般化与特殊化)关系(继承)

继承关系会将子类的信息填入父类，同时在父类加入类型属性

整体与部分(对象与其零件)

电脑（整体）–处理器、键盘、。。。（部分）

设计需求模型

传统设计方法设计需求模型：

环境图

概述

• 抽象系统 或子系统内 所有处理活动 的DFD(数据流图)
• 最抽象的观点来描述系统
• 显示系统边界
• 系统范围的定义方式，是借着单个处理程序，外部代理人，以及进出系统的所有数据流

步骤

首先找到中心系统，其次找到系统的主要实体，然后理清 主逻辑 ，最后通过箭头将中心点与主要实体相连

实体+箭头逻辑 = 事件

所有事件= 事件列表

数据流图(DFD)

概述

数据流图（Data Flow Diagram）：简称DFD，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。

组成

DFD的分段

• 为事件表格中的每个使用案例所建立
• 表示系统响应单一事件，会在单一处理程序符号中呈现
• 自给自足的模型
• 专注于系统的单一部份
• 只显示该使用案例中必要的资料储存（来源于ER图）

事件分割系统模型

• 在系统与子系统中，使用各个事件的单一处理程序建模系统需求的 DFD
• 合并所有的 DFD 分段可以显示内容层次的分割模型，有时候称为 “图 0”
• 主要当做简报工具使用
• 分解为更详细的 DFD 分段

分解DFD分段

• 大部份 DFD 分段都可以使用结构化英文描述
• 有时候 DFD 分段需要以更详细的图表显示
• 分解为详细 DFD 中的子处理程序
• DFD 编号架构
  • 阶层式分解
    • DFD分段1分解为图1
    • 图1中的处理程序为1.1，1.2，1.3

抽象的层级

DFD 可以分解为其它的图表 , 以提供多种层次的详细程度

较高层级的图表提供一般化的系统检视

较低层级的图表提供更详尽的系统检视

对于系统的不同视角就称为抽象的层级

实体与逻辑DFD

• 逻辑模型
  • 假定系统是在完美科技的环境下实际操作。
  • 无法说出系统的工作方式实际操作。
• 实体模型
  • 描述关于实际操作技术的假设。
  • 在分析阶段的最后，或是设计阶段的初期开发。

评估DFD的质量

• 可读性
• 内部一致性与平衡感
• 精确地表达系统需求
• 减少信息超载地现象 —— 7±2规则
  • 单一的DFD应该不要超过7±2个处理程序
  • 在单一的DFD上，应该不要有超过7±2个数据流进入或离开处理程序、数据存储或是数据元素
• 将必要的界面数量最小化

资料流一致性的问题

处理程序与分解它的处理程序间数据流内容的差异，数据流出却没有对应的流入、或数据流入却没有对应的数据流出，结果就是不平衡的DFD。

一致性规则

• 全部流入处理程序的数据都必须
  • 流出该处理程序
  • 被用来产生 流出该处理程序 的数据
• 全部流出处理程序的数据都必须：
  • 已流入该处理程序
  • 从流入这个处理程序的数据所产生

DFD组件的说明文件

• 每个最低层级的处理程序都需要详细描述
• 需要描述数据流的内容
• 需要以数据元素来定义数据储存
• 必须定义每个数据元素
• 处理程序的定义存有多种选项

面向对象的设计方法：

用例图：

图形化的UML模型，摘要关于参与者与使用案例的信息

显示功能醒需求概要的 简图

可以有多个使用案例图

• 根据子系统或者参与者

组成

参与者： 用火柴人图标表示

用例：椭圆

边界：矩形框

关系

辨识/确认使用案例的CRUD分析

• CRUD-建立，读取/报表，更新，删除
• 资讯工程 (IE) 技术可辨识事件表格或直接开发使用案例图
• 将已辨识的使用案例与领域模型类别图进行比较
• 类别图中的每个类别都必须有使用案例, 支持建立, 读取/报表, 更新, 删除对象的实例
• 确认系统整合的需求

用例的说明

• 使用案例说明提供前置条件,后续条件, 活动顺序, 与例外状况的细节
• 描述参与者与计算机系统间的互动, 逐步实现企业的活动
• 可能有多个情节, 每个情节都是特定的使用案例实例
• 使用案例的说明可分为三个详细的等级：简短的说明、中等程度的说明、以及完整的说明
• 许多分析师喜欢以文字内容来描述使用案例，而不是绘制活动图

简短说明

中等程度说明

完整说明