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