实体类、边界类和控制类

实体类：

     实体类是用于对必须存储的信息和相关行为建模的类。实体对象（实体类的实例）用于保存和更新一些现象的有关信息，例如：事件、人员或者一些现实生活中的对象。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。

     实体类的找寻相对简单点，这里就不再做具体的叙述了。

 

边界类：

    边界类是系统内部与系统外部的业务主角之间进行交互建模的类。边界类依赖于系统外部的环境，比如业务主角的操作习惯、外部的条件的限制等。它或者是系统为业务主角操作提供的一个GUI，或者系统与其他的系统之间进行一个交互的接口，所以当外部的GUI变化时，或者是通信协议有变化时，只需要修改边界类就可以了，不用再去修改控制类和实体类。业务主角通过它来与控制对象交互，实现用例的任务。

    边界类调用用例内的控制类对象，进行相关的操作。

  

一个系统可能会有多种边界类：

• 用户界面类 - 帮助与系统用户进行通信的类
• 系统接口类 - 帮助与其他系统进行通信的类
• 设备接口类 - 为用来监测外部事件的设备（如传感器）提供接口的类

 

控制类：

    控制类用于对一个或几个用例所特有的控制行为进行建模，它描述的用例的业务逻辑的实现，控制类的设计与用例实现有着很大的关系。在有些情况下，一个用例可能对应多个控制类对象，或在一个控制类对象中对应着对个用例。它们之间没有固定的对应关系，而是根据具体情况进行分析判断，控制类有效将业务逻辑独立于实体数据和边界控制，专注于处理业务逻辑，控制类会将特有的操作和实体类分离，者有利于实体类的统一化和提高复用性。

    当业务主角通过边界类来执行用例的时候，产生一个控制类对象，在用例被执行完后，控制类对象会被销毁。

  

   控制类的特点：

     独立于环境

     和用例的实现关联

     使用关联实体类，操作实体类对象

     专注于业务逻辑的实现

 

    当然如果用例的逻辑较为简单，可以直接利用边界类来操作实体类，而不必再使用控制类。或者用例的逻辑较为固定，业务逻辑固定不会改变。也可以直接在边界类实现该逻辑。

http://blog.csdn.net/bestrem_9/article/details/6200548

---------------------------------------------------------------分割线------------------------------------------------------------------------------------------------------------

在ROSE建模里有一种划分类的方式“边界类”“实体类”“控制类”。

边界类：

边界对象的抽象，通常是用来完成参与者（用户、外部系统）与系统之间交互的对象，例如：From、对话框、菜单、接口等。

控制类：

控制对象的抽象，主要用来体现应用程序的执行逻辑，将其抽象出来，可以使变化不影响用户界面和数据库中的表。

实体类： 

实体对象的抽象，通常来自域模型（现实世界），用来描述具体的实体，通常映射到数据库表格与文件中。

分析模型实例：

类型：

边界类：

CommandWindow  负责接受用户输入的命令并向用户显示命令结果

控制类：

LightInductorControl  负责与“航标灯器”感应器通讯，获取航标灯器当前数据

RadarResponderInductorControl  负责与“雷达应答器”感应器通讯，获取雷达应答器当前数据

GPSDeviceControl  负责与“GPS定位设备”感应器通讯，获取当前位置

实体类：

LightState  负责存储航标灯器状态数据

RadarResponderState  负责存储雷达应答器状态数据

GPSState  负责GPS定位数据

 

设计模型实例：

将不同的Control抽象成一个工厂类，这样就可以根据用户输入的命令来创建相应的Control，同时有良好的扩展性，用JDBC来实现命令执行结果的存储。

用处：在RUP中，这三个版型用户帮助分析需求，起到帮助分析人员思考的作用，通过明确区分这三种分析类，有助于清楚地在分析模型中准确地描述需求。

我个人认为这种分法和我们之前了解的MVC相对应，MVC是一种架构模式，而这些类是这种架构的具体体现。

http://blog.csdn.net/wulingmin21/article/details/6840819