UML建模（七）需求启发、分析之分析类图

1.需求启发要点

• 和涉众交流的形式应该采用视图，而不是模型
• 和涉众交流的内容应该聚焦涉众利益，而不是需求
• 需求启发手段：研究资料、问卷调查、访谈、观察、研究竞争对手
• 需求人员的素质培养：好奇心、探索力、沟通力、表达力、热情

2.分析之分析类图

2.1识别类和属性

• 核心域和非核心域：一个软件系统封装了若干领域的知识，其中一个领域的知识代表了系统的核心竞争力，是系统和其他系统区分的关键所在。 这个领域称为"核心域"，其他领域称为"非核心域"。
• 基于核心域的复用：设计的目的就是复用
• 软件开发史，就是不不断复用级别的历史
• 基于核心域的复用有一定的难度：因为能带来利润的系统，被迫关注的领域比较多，负载比较高
• 要达到基于核心域的复用、有必要将核心域和非核心域分开考虑、将分析和设计分开考虑
• 同一个核心域可能要映射到多个互相竞争的非核心域
  -人脑的容量和运算速度有限，待解决问题规模变大，就必须分而治之
• 核心域知识和非核心域知识是独立的，域和域之间的映射规律，与域中的个体不直接相关

• 和只有自上而下顺序的文本相比，二维图形更容易让开发人员看出这些类之间的规律，更好地切割系统

  
  image.png
• 有利润的系统， 其内部都是复杂的
• 对象封装了数据和行为

• 对象封装了数据和行为

  
  image.png

• 三种分析类的责任、和用例的关系以及命名。

  
  image.png

• 控制类是可选的，如果在分配责任时只起到传递的作用，没有起到分解和分配的作用，可以删除调

  
  image.png
• 针对用例规约提炼类

image.png

-在分析工作流中，系统概念被打碎成各个类，所以系统这个词不需要识别成类

image.png

• 分析类虽然不包含设计工作流的知识，但是它是设计工作流的基础

2.2识别分析类和属性的要点

• 中英文命名根据场景确定

• 命名中不要到冗余信息（类、情况、信息、记录、数据、表、库、单）

  
  image.png
  image.png

• 属性名称前不要加类名

  
  image.png

• 英文用单数

• 命名要一致

• 不要类图长的象用例图

• 不要类长得像过程

• 不要类长得像报表

• 使用核心域术语（涉众关心的是涉众利益，不关注系统需求）

• 用核心域透镜的方式思考问题，从核心域视角去看所有的事情

  
  image.png

• 属性要直接描述类（任何非主属性不依赖于其他非主属性）

• 分析类中不需要主键、外键属性

  
  image.png

• 属性在本领域内不可以在分解
  1.复杂属性（分不分离的理由：是否另一个领域而不是 是否简单）
  2.多重性大于1的属性

  
  image.png

• 属性对所有对象都有意义

2.3识别类之间的关系

• 类的关系：
  1.泛化
  2.关联（普通关联、聚合、组合）

  
  image.png

3.依赖

image.png

• 泛化和关联的区别：
  1.泛化表示集合关系
  2.关联表示个体关系
  3.集合关系还是个体关系，这是泛化和关联的本质区别

  
  image.png
  image.png

• 识别泛化的思路：
  1.直接形成
  2.自下而上（从特殊到一般）

  
  image.png
  

  3.自上而下（从一般到特殊）

• 尽量不要跨领域使用泛化关系

• 引入聚合/组合，相当于把类图分区，每个区找一个区长作为责任分配的起点

  
  image.png

• 识别关联的思路：
  和泛化不同的是，关联不只是发生在不同的类之间，还可以发生在同一个类上，即自反关联。
  1.关联是系统维护的关系

  
  image.png
  

  2.关联名或角色名（聚合/组合关联经常被认为不需要关联名或角色名，其实也是需要的）

  
  image.png
  3.导航方向（关联可以是双向的，两端的对象都可以通过关联导航到另一端；关联也可以是单向的，只有其中一端能访问另一端）
  image.png
  4.多重性
  image.png
  

  5.自反关联（当关联的两端是同一个类时，这个关联就是自反关联。）

  
  image.png
  image.png