Thinking in UML 读书笔记（二：基本概念）

 

一、UML核心模型

 

1.1 用例模型

官方文档中用例模型定义为系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。

用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。

 

 

 

1.2 分析模型

• 分析类用于获取系统中主要的“职责簇”。它们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。
• 分析模型则使用分析类来建立系统原型，获得系统实现需求的第一手方案。
• 由于分析类忽略了实现细节，从而可以只关心系统如何使用对象来实现需求。采用分析类来维护系统实现与需求的同步能非常大的节省工作量。

 

分析模型应当成为面向对象设计的核心，因为:

• 分析模型是采用分析类在软件架构和框架的约束下来实现用例场景的产物。
• 分析模型是高层次的系统视图，在语义上，分析类不代表最终的实现。它是计算机系统元素的高层抽象。
• 设计模型只是分析模型的一种实现手段，分析类具化以后才产生真正的实现类。
• 分析模型是MVC模式的经典应用。从分析类的名称就可以看出来。读者应当还记得

“商业系统无论多复杂，无论什么行业，其本质无非是人、事、物、规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。分析类在对象世界和现实世界中精妙的对应关系: 人、事、物、规则——参与者、 边界类、实体类、控制类。

 

如何使用分析模型

1. 先采用时序图（用以获取分析类），在用例场景中的参与者与系统之间加入一个边界类代表操作界面
2. 在边界类与实体交互之间加入一个控制类代表业务逻辑
3. 然后对照用例场景，一步一 步把用例场景过程用分析类实现出来。

 

定义分析类之间关系的时候应该注意以下几个原则：

• 边界类不应当与实体类之间有依赖关系。边界类只能通过控制类与实体类交互。
• 实体类和实体类之间可以有聚合或组合关系，但不应当有依赖关系。它们不应当直接交互，而只能通过控制类间接交互。
• 控制类和控制类之间不应当有聚合或组合关系，如果可能，应当尽量减少依赖关系。
• 正确的依赖关系应当是边界类依赖于控制类，控制类依赖于实体类