面向对象需求分析方法-知识点总结

UML统一建模语言

主要特点

标准的图形化建模语言，是面向对象分析与设计的一种标准表示。
不是可视化的程序设计语言、不是工具或知识库的规格说明、不是过程、不是方法

基本结构

• 基本构造块：事物/关系/图
• 语义规则：name、scope、visibility、integrity、execution
• 通用机制：specification、adornment、common division、extensibility mechanism
• 事物及关系：Structural thing、Behavior thing、Group thing、Annotation thing

UML视图

用模型来描述系统结构（静态特征）和行为（动态特征），从不同的视角为系统架构进行建模，从而形成不同的视图。

• 逻辑视图/结构模型视图、静态视图：展现系统的静态或结构组成及特征，
• 构建视图/实现模型视图/开发视图：关注软件代码的静态组织与管理
• 进程视图/行为模型视图/过程视图/协作视图/动态视图：描述设计的并发和同步等特性，关注系统非功能性需求
• 部署视图/环境模型视图/物理视图：：描述硬件的拓扑结构以及软件和硬件的映射问题，关注系统非功能性需求（性能、可靠性等）
• 用例视图/用户模型视图/场景试图：强调从用户的角度看到的或需要的系统功能，
  

基本图

用例图/类图/对象图/顺序图/协作图/状态图/活动图/构件图/部署图

图和视图的关系

• 逻辑视图：用例图和活动图
• 逻辑视图：类图、对象图、顺序图/协作图
• 进程视图：状态图、活动图
• 构件视图：构件图
• 部署视图：部署图

UML类图

UML类图用于描述类以及类之间的关系，主要包括三部分：

• 类名
• 属性（可见性 属性名：类型名= 初始值 {性质串}）
• 操作（可见性 操作名（参数表）：返回值类型 {性质串} ）

类的关系分类：

• 关联【普通关联、导航关联、递归关联】、组合和聚合、依赖和继承
• 另一种分类：依赖关系、关联关系、聚合关系、组合关系、继承关系

注意：组合和聚合的关系

• 聚合关系（Aggregation）：
  体现的是A对象可以包含B对象，但B对象不是A对象的组成部分。具体表现为，如果A由B聚合成，表现为A包含有B的全局对象，但是B对象可以不在A创建的时刻创建。
• 组合关系(Composition)：
  如果A由B组成，表现为A包含有B的全局对象，并且B对象在A创建的时刻创建。

二、面向对象需求分析

模型组成

领域建模

• 在需求分析阶段，表示“当前系统”逻辑模型的静态结构及业务流程，针对特定领域内概念类或者对象的抽象可视化表示，对业务背景和业务流程进行概括性描述。
• 不适用于领域模型的元素：软件制品(窗口、界面、数据库)、软件模型中具有职责或方法的对象。

用例建模

定义了“目标系统”做什么的需求。由以下四个部分组成：

• 用例图（基础）：角色、用例、联系
• 用例说明（基础）
• 系统顺序图（附加说明）
• 操作契约（附加说明）

领域模型的建模

• 识别概念类：
  找出当前需求中的候选概念类->通过对用例描述中的名词或名词短语寻找和识别概念类。
  识别技巧：属性一般是可以赋值的，比如数字或者文本。如果该名词不能被赋值，那么就“有可能”是一个概念类。如果对一个名词是概念类还是属性举棋不定的时候，最好将其作为概念类处理。
• 描述概念类：
  在领域模型中描述这些概念类。用问题域中的词汇对概念类进行命名，将与当前需求无关的概念类排除在外。
• 添加关联：在概念类之间添加必要的关联来记录那些需要保存记忆的关系，概念之间的关系用关联、继承、组合/聚合来表示。
• 添加属性
  在概念类中添加用来实现需求的必要属性。

用例模型的建模

以用例为核心从使用者的角度描述和解释待构建系统的功能需求

• 确定问题域的分析范围;
• 确定该范围内可能出现的角色；
• 根据业务背景或者领域模型，确定每个角色需要的用例，并形成用例图；
• 基于确定的用例，整理成规范的用例描述文本；
• 在可能的情况下，将多个角色的用例图整合成一个相对完整的用例图；
• 针对每个用例，结合相应的用例描述，确定系统顺序图中角色与系统之间的交互，绘制基于用例的系统顺序图；
• 基于每个系统顺序图，确定每个事件交互经过系统处理后应该返回给角色的声明性结果，即操作契约；

相关概念

关联

• 关联类型：
  须要知道型关联：将概念之间的关系信息保持一段时间的关联，需着重考虑。
  只需理解型关联：有助于增强对领域中关键概念的理解的关联。
• 找寻关联遵循的原则：
  集中查找须要知道型关联；
  识别概念类比识别关联更重要，领域模型创建应该更注重概念类的识别；
  太多的关联容易使领域模型变得混乱；
  避免显示冗余或导出关联；

用例

• 基本用例：和角色直接相关的用例，表示系统的功能需求
• 子用例：通过场景描述分析归纳出的用例，也表示了系统的功能，但这些用例与角色无直接关系，而与基本用例存在关联关系；
  ①包含子用例：多个基本用例中的某个与角色交互的场景具有相同的操作，且这些场景都是基本用例中必须执行的步骤，
  ②扩展子用例：（多个）基本用例中的某些场景存在相同的条件判断的情况，可以将其抽取出来作为基本用例的子用例；

系统顺序图

用例描述的基础上需要进一步确定角色与系统之间的交互信息，并以可编程的方式将其命名。
一般需要三个UML的符号元素：

• 角色
• 代表软件系统的对象
• 角色与system之间的交互信息，简称消息或操作

操作契约

（1） 为系统操作而定义的，参考领域模型中业务对象接收到相同的系统事件后，执行必须的业务处理时，各业务对象的状态以及系统操作执行的结果。
（2）创建操作契约的原则：

• 根据系统顺序图识别进入到系统内的所有系统事件，即操作；
• 针对每一个系统操作结合对应的用例领域模型，找到与此操作相关的概念类对象；
• 对那些相对复杂以及用例描述中不清楚的那些系统操作按照以下内容描述并确定对象的状态变化，即后置条件；