《大象 Thinking in UML》学习笔记（四）——UML核心元素之边界类、实体类

一、边界

边界在UML图符里定义只是一个简单的矩形框，矩形框的四个边决定了边界的内外。

边界本质上是面向对象方法的一个很重要的概念，与封装的概念相似。在面向对象里，任何一个对象都有一个边界，外界只能通过这个边界来认识对象，与对象打交道。

边界决定视界；
边界决定抽象层次。

边界是无形的，但是在面向对象的方法里，从业务建模到接口设计边界都可以发挥重要的作用。

二、业务实体

业务实体是类的一种版型，特别用于在业务建模阶段建立领域模型，代表业务角色执行业务用例时所处理或使用的“事物”。

业务实体是来自现实世界的，所有业务实体在现实世界里都有与之对应的事物；
业务实体一定是在分析业务流程的过程当中发现的，与业务用例场景无法的事物，即使存在，也不会为它建模；
业务实体具有对象的所有性质，包括属性、方法和对象的独立性。

属性是用来保存业务实体特征的一个记录，业务实体的属性集合决定了它的唯一性；
方法是访问一个业务实例的句柄，它规定了外部可以怎样来使用它。

获取业务实体：

1. 建立业务用例场景；
2. 从业务用例场景中逐个分析动词后面的名次，它们就是业务实体的备选对象；
3. 分析这些业务实体之间的关系，并决定哪些应当单独建模，哪些应当作为属性。

三、包

包是一种容器，就如文件夹一样。

包可以容纳任何UML元素，也包括子包。包之间的关系定义只有依赖关系，好的分包具有高内聚，低耦合的性质。

• 领域包（Domain Package）用于分类业务领域内的业务单元，每个包代表业务的一个领域，领域包视图可用于展示这些业务领域的高层次关系；
• 子系统（Subsystem）用于分类系统内的逻辑对象并形成子系统，子系统包视图可用于展示系统的高层次逻辑结构关系；
• 组织结构包（Organization unit）用于分类业务领域中的组织结构，它可以直接用来表述企业的资质结构；
• 层包（Layer）用于分类软件中的层次，层可以用于展示软件的架构信息。

四、分析类

分析类用于获取系统中主要的“职责簇”，代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。

分析类可以产生系统的的设计类和子系统。

分析类是从业务需求向系统设计转化过程中最为主要的元素，它们在高层次抽象出系统实现业务需求的原型，业务需求通过分析类逻辑化，被计算机所理解。

分析类包含三种，分别是边界类（boundary）、控制类（control）和实体类（entity）。

边界类

边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。

• 参与者与用例之间应当建立边界类；
• 用例与用例之间如果有交互，应当为其建立边界类；
• 如果用例与系统边界之外的非人对象有交互，比如第三方系统，应当为其建立边界类；
• 在相关联的业务对象有明显的独立性要求，也应当为它们建立边界类。

从架构角度上来说，边界类主要位于展现层。

控制类

控制类用于对一个或几个用例所特有的控制行为进行建模。
控制类来源于对用例场景当中动词的分析和定义，包括限制动词的描述。
从架构角度上来说，控制类主要位于业务逻辑层。

实体类

实体类是用于对必须存储的信息和相关行为建模的类。
实体类源于业务建模中的业务实体。
从架构角度上来说，实体类主要位于数据持久层。

分析类的三高

分析类是从业务需求向系统设计转化过程中最为主要的元素，它们在高层次抽象出系统实现业务需求的原型，业务需求通过分析类被逻辑化，成为可以被计算机理解的语义。

• 高于设计实现
• 高于语言实现
• 高于实现方式

分析类的抽象层次较高，只需要专注在实现需求上，也因此比设计和实现更加稳定。

五、设计类

设计类是系统实施中一个或多个对象的抽象，设计类所对应的对象取决于实施语言。设计类用于设计模型中，它直接使用与编程语言相同的语言来描述。

设计类由类型、属性和方法构成，设计类的名称、属性和方法也直接映射到编码中相应的class、property和method。

类
类对对象进行定义，而对象又实现用例。
类是对对象某一方面特征的归纳和抽象，而对象则是类实例化的结果。

属性
属性是对象特征，属性同时表明了对象的唯一性。

方法
方法是访问对象或影响其他对象的属性或关系的唯一途径，由类进行定义。

可见性
类的属性和方法都有可见性的定义，常见的有：

• 公有：除了类本身以外，属性和方法对其他模型元素也是可视的。
• 保护：属性和方法只对类本身、它的子类或友元是可视的。
• 私有：属性和方法只对类本身和类的友元是可视的。
• 实施：属性和方法只在类本身的内部是可视的。