系统分析与建模6
业务实体
业务实体是类（class）一种版型，特别用于在业务建模阶段建立领域模型。如果说参与者和用例描述了我们在这个问题领域中达到什么样的目标，那么业务实体就描述了我们使用什么来达到业务目标以及通过什么来记录这个业务目标。业务实体代表业务角色执行业务用例时所处理或使用的“事物”。
首先，业务实体是来自现实世界的，在建模的问题领域里一定能够找到与它相对应的事物，并且这个事物是参与者在完成其业务目标的过程中使用到的或创建出来的。其次，业务实体一定是在分析业务流程的过程中发现的，而业务流程实际上就是业务用例场景。最后，业务实体作为类的一个版型，具有对象的所有性质，包括属性和方法，同时也具有对象的独立性。
业务实体的属性：用来保存业务实体特征的一个记录，业务实体的属性集合决定了它的唯一性。
业务实体的方法：是访问一个业务实体的句柄，规定了外部可以怎样来使用它。方法就是外部能够使用这个业务实体的全部信息。一个业务实体有很多种可能的使用方法，只需要关心那些与这个场景有直接关系的那些方法。
获取业务实体：首先要建立业务用例场景，然后从业务用例场景中逐个分析动词后面的名词，最后分析这些业务实体之间的关系。
业务实体是定义和理解业务的重要元素，代表了业务的实质。如果说参与者代表人，用例代表事，则业务实体就是物。人不论做什么事，最终结果还是要落在物上的。
包
包是一种容器，将某些信息分类，形成逻辑单元。目的是为了整合复杂的信息，某些语义上相关或者某方面具有共同点的信息都可以分包。好的分包具有高内聚、低耦合的性质。
常用的包的版型：
- 领域包：用于分类业务领域内的业务单元，每个包代表业务的一个领域，领域包视图可用于展示这些业务领域的高层次关系。
- 子系统包：用于分类系统内的逻辑对象并形成子系统。子系统包视图可用于展示系统的高层次逻辑结构关系。
- 组织结构：用于分类业务领域中的组织结构，可以直接用来表述企业的组织结构。
- 层包：分类软件中层次，层可以用于展示软件的架构信息。
包是UML元素中随意性最大的，但用好包将帮助更好地组织元素。就如同写文章要有好的提纲一样，包结构就是文章的提纲。
分析类
分析类就是跨域需求到设计实现的桥梁，是从业务需求向系统设计转化过程中最为主要的元素，它们在高层次抽象出系统实现业务需求的原型，业务需求通过分析类罗计划，被计算机所理解。
分析类总共只有三个：边界类（boundary）、控制类（control）和实体类（entity），这些分析类都是类（class）的版型。
1、边界类
边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。
对现实世界来说，边界类的实例可以是窗口、通信协议、打印机接口、传感器、终端等，在计算机世界里，边界类也可以是一个消息中间件、一个驱动程序、一组对象接口甚至任意一个类。总之，不论是现实世界还是计算机世界里，当打算对A对象和B对象之间的交互进行建模时，边界类都可以充当这一载体。
边界类常用的场景：
- 参与者与用例之间应当建立边界类
- 用例与用例之间如果有交互，应当为其建立边界类
- 如果用例与系统边界之外的非人对象有交互，例如第三方系统，应当为其建立边界类
- 在相关联的业务对象有明显的独立性要求，即它们可能在各自的领域内发展和变化，但有希望互不影响时，也应当为它们建立边界类
从架构角度上来说，边界类主要位于展现层。边界类的获取对架构设计中的展现层有着重要的指导意义。一个好的边界类应该具有以下特点：
- 边界类应该有助于提高系统的可用性。
- 边界类应该尽可能地保持在较高的层次（如概念层次）上。
- 边界类应该合理封装介于系统与主角之间的交互。
- 如果主角改变他们为系统提供输入的方式，边界类就应该是唯一需要改变的对象。
- 边界类必须“知道”其他对象类型（例如控制对象和实体对象）的需求，以便它们能够得以实施，并相对于“系统内部元素”保持其可用性和有效性。
2、控制类
控制类用于对一个或几个用例所特有的控制行为进行建模。控制类将用例的特有行为进行封装。控制对象通常控制其他对象，因此它们的行为具有协调性质。
在提取控制类时，要认真考察用例场景中的行为，如果这些行为在执行步骤、执行要求或者执行结果上具有类似的特征，应当考虑进行适当的抽象，例如合并或者抽取超类。同时，也要考察这些行为是否对要建设的系统产生影响而进行一些取舍。
3、实体类
实体类时用于对必须存储的信息和相关行为建模的类。实体类源于业务模型中的业务实体。很多时候可以直接把业务实体转化为实体类。但是出于系统结构优化的需要，一些业务实体可以在后续的过程中被分拆、合并。
设计类
设计类是系统实施中一个或多个对象的抽象；设计类所对应的对象取决于实施语言。设计类用于设计模型中，它直接使用与编程语言相同的语言来描述。
设计类来源于前期的系统分析，它们可以一一映射到前期系统分析的成果物上。分析类为设计类中所需要的界面、逻辑和数据提供了非常好的抽象基础，设计类可以非常容易和自然地从分析类中演化出来。设计类由类型、属性和方法构成。
实际上现在的软件项目不使用软件框架的已经少之又少了，因此，设计类还会受到软件框架的约束。
