面向对象需求分析

---

1、UML建模语言

1.1 模型

• 是目标事物的某种介质表达，由符号和语义组成
• 软件模型就是用建模语言对目标软件的简化或抽象
• 使用模型可以
  • 以一致的方式捕捉或表达软件需求和领域知识
  • 方便软件设计
  • 使设计与需求相分离
  • 生成可用的软件部件
  • 简化复杂系统的表达
  • 减低软件开发成本

1.2 面向对象分析模型

1、功能模型
从用户的角度对软件系统功能的模型化
主要使用用例图

2、对象模型
使用面向对象方法对软件系统静态结构的模型化
主要使用对象图、类图和包图

3、动态模型
对软件系统内部对象行为的模型化
主要使用时序图、活动图、状态图

2、面向对象需求分析

• 使用面向对象模型分析软件需求的一种方法
• 面向对象模型包含：静态结构（对象模型）、交互次序（动态模型）和系统功能（功能模型）
• 面向对象分析大体上有以下内容：
  • 寻找类与对象
  • 识别结构
  • 识别主题
  • 定义属性
  • 建立动态模型
  • 建立功能模型
  • 定义服务

2.1 对象模型（有时也称为领域模型）

• 对象模型表示静态的、结构化的系统的“数据”性质,
• 使用统一建模语言（UML）所提供的类图或对象图来建立对象模型
  步骤
  • 识别对象
  • 创建对象模型图
  • 定义对象属性
  • 定义对象行为
  • 定义对象之间的关系

2.2 动态模型

• 描述对象对内部或外部事件的响应过程
• 使用UML时序图、状态图、活动图等描述
• 步骤
  • 编写典型交互行为的脚本（包含构想用户界面）
  • 从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象
  • 排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们
  • 比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配

2.3 功能模型

• 表明了系统中数据之间的依赖关系，以及有关的数据处理功能
• 可以使用用例图、数据流图等进行描述
• 步骤
  • 识别输入、输出
  • 展示功能依赖关系
  • 描述每个功能的目标
  • 优化

2.4 定义服务对象

• 服务即对象对数据施加的操作
• 定义方法
  • 常规行为，如Setters，Getters等
    从事件导出的操作
    事件触发消息，消息接收者对该消息进行处理和响应
  • 与数据流图中处理框对应的操作
    由1个对象或多个对象的服务实现
  • 利用继承减少冗余操作
    尽量在分析时减少所需定义的服务数量，降低复杂度
    运用继承可以减少同类型服务的数量

3、用例建模

3.1 用例

• 用于描述参与者（Actor）为了完成某种业务目标（任务）与软件系统之间的一系列交互步骤
• 通过用例建模能够建立系统的功能模型

3.2 建模步骤

• 识别参与者和用例以及它们之间的关系
• 简述用例的场景（Scenario）
• 按交互顺序描述用例的事件流程
• 构建用例表
• 模型可视化

3.3 识别参与者（使用名词或名词短语的角色命名）

• 谁使用软件
• 谁从软件中获得信息
• 谁向软件提供信息
• 软件在何处使用
• 谁维护软件
• 使用该软件的第三方对象
• 参与者命名一般使用其业务角色名称，如银行客户

3.4 识别用例

• 参与者使用软件的目的是什么
  • 参与者为什么要使用软件
  • 参与者会创建、保存、修改和删除数据吗？为什么？
  • 参与者需要将外部的事件输入到软件内部吗？
    -参与者需要知道软件内部的发生的事件吗？
• 软件是否以恰当的行为提供了业务服务
• CRUD用例应当合并为一个用例，例如管理***/维护***
• 每个用例至少有一个参与者
• 一般使用动宾短语命名，如“取钱”

3.5 简述用例的场景

• 简洁描述用例的业务目标

• 包括参与者与软件的交互行为

• 和软件向参与者反馈的业务结果

• 例如，银行客户输入取款信息，ATM向客户提供指定数额现金，并显示取款结果

• 按交互顺序描述用例的事件流程

  • 描述主事件流
  • 描述分支事件流

• 构建用例表

  • 用例编号
  • 用例名称
  • 参与者
  • 用例简介
  • 前置条件
  • 事件流
  • 后置条件

3.6 模型可视化

• 绘制用例
• 绘制参与者
• 绘制参与者与用例的关系
• 绘制系统边界
• 模型优化
  • 包含子用例：多个主用例中的共享主事件流可以抽离成一个包含子用例
  • 扩展子用例：多个主用例中的共享分支事件流可以抽离成一个扩展子用例
  • 泛化

4、领域建模

• 领域模型是业务中不同领域概念（Concept）和其之间关系（Relationship）的可视化模型
• 同E-R模型比，领域模型含有数据实体和属性，但还包括其他非持久化存储的领域概念
• 同设计类模型比，领域模型仅仅针对领域概念进行建模，而不会涉及软件内部技术设计的对象类
• 建模步骤
  • 头脑风暴，识别领域概念
  • 划分概念类
  • 识别概念类之间的关联
  • 识别概念类的属性
  • 领域模型可视化与优化

3、需求说明文档的撰写与评审

3.1 需求说明文档（SRS）

• 作用
  • 团队的沟通与交流媒介
  • 软件设计的基础和依据
  • 测试与验收的依据
• 结构
  • 需求概述
  • 需求规格
  • 详细需求说明
  • 未解决的问题标注

3.2 需求评审

• 目的
  • 与用户确认需求，保证需求的一致性
  • 去除需求缺陷
• 评审点
  -完整性
  • 一致性
  • 可理解性
  • 可实现性等
• 参与人员
  • 需求分析人员，软件设计人员，领域专家，用户，软件测试人员等
• 需求评审就是技术评审，根据评审的方法划分为以下两类：
  • 非正式评审：由开发人员描述产品并征求意见，不需要记录
  • 正式评审：应该包含一组由不同背景的审查人员组成的小组