Thinking in uml 03 uml核心元素(四)
六．分析类
在大多数项目中，分析类是被忽视的一种非常有用的元素。
两个重要性质：
（1）分析类代表系统中主要的“职责簇”，这意味着分析类是从功能性需求向计算机实现转化过程中的“第一个关口”；
（2）分析类可以产生系统的设计类和子系统，这意味着计算机实现是可以通过某种途径产生出来的，而不是拍脑袋拍出来的。
在实际经验中，分析类往往成为工作的重心，它不仅仅被当作过渡类型看待，相反，在有了基本需求后，分析类在整个生命周期中都一直进行着维护。由于分析类正好处于需求和实现的中间地带，要维护一个软件对于需求的可追溯要求、要维护软件架构的稳定演进、要维护一个高扩展性的架构，甚至要维护设计与实际代码的一致性，分析类都是不可或缺的。
1．边界类
在从需求向实现的转换的过程中，任何两个有交互的关键对象之间都应该考虑建立边界类。
一些常见场景：
（1）参与者与用例之间应当建立边界类
用例可以提供给参与者完成业务目标的操作只能通过边界类暴露出来。例如，参与者通过一组网页、一组windows窗口、一个字符终端或是一个鼠标来使用用例的功能，上述的东西都可以称为用例的边界类。
（2）用例与用例之间如果有交互，应当为其建立边界类
一个用例如果要访问另一个用例，直接访问用例内部对象是不好的结构，这样讲导致紧耦合。而边界类可以隔离这种直接访问，其作用相当于一个门面模式。在最终实现时，用例之间的边界类可以演化为一组API、一组JMS消息或是一组代理类。
（3）如果用例与系统边界外的非人对象有交互，例如第三方系统，应当为其建立边界类。
这通常是因为异构系统、异构数据、访问权限、安全通道等原因。在具体实现时，边界类可以演化为中介和通信协议，中介的例子如网关、通信中间件、代理服务器、安全认证服务器、WebAService、SOA组件等；通信的协议的例子如HTTP、FTP、SSL、RMI、SOAP等。
（4）在相关联的业务对象有明显的独立性要求，即它们可能在各自的领域内发展和变化，但又希望互不影响时，也应当建立边界类。在实现时，边界类可以转化为一组接口来对这些对象解耦。
从框架角度来看，边界类主要位于展现层。边界类的获取对架构设计中的展现层有着重要的指导意义。一个好的边界类应该具有以下特点：
（1）边界类应该有助于提高系统的可用性；
（2）边界类应该尽可能地保持在较高的层次上，如概念层次；
（3）边界类应该合理封装介于系统与主角之间的交互；
（4）如果主角改变他们为系统提供输入的方式，边界类就应该是唯一需要改变的对象；
（5）如果系统改变为主角提供输出的方式，边界类就应该是唯一需要改变的对象；
（6）边界类必须知道其他对象类型的需求，以便它们能够得以实施，并相对于系统内部对象保持其可用性和有效性。
2．控制类
控制类用于对一个或几个用例所特有的控制行为进行建模。控制类将用例的特有行为进行封装。
控制类来源于对用例场景中行为的定义，即控制类来源于对用例场景当中动词的分析和定义，包括限制动词的描述。在提取控制类时，要认真考察用例场景中的行为，如果这些行为在执行步骤、执行要求或执行结果上具有类似的特征，应当考虑进行适当地抽象，例如合并或抽取超类。同时，也要考察这些行为是否对要建设的系统产生的影响而进行一些取舍。
应当养成习惯：在边界类和边界类、边界类和实体类、实体类和实体类之间都默认加入控制类，将相关的处理逻辑放到控制类中，哪怕该控制类只有一个操作。在设计阶段，控制类可以被设计为SessionBean、COM+、Serverlet、Java类、C++类等设计类。
从构架角度上来说，控制类主要位于业务逻辑层，控制类的获取对构架设计中的业务逻辑层有着重要的指导意义。
3．实体类
实体类是用于对必须存储的信息和相关行为建模的类。实体对象用于保存和更新一些现象的有关信息，例如事件、人员或者一些现实生活中的对象。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。
实体类源于业务模型中的业务实体，很多时候可以直接把业务实体转化为实体类，例如寄信人到邮局寄信业务模型中的业务实体就可以直接转化为信、信封、邮票、信件、回执这些实体类。但是由于系统结构优化的需要，一些业务实体可以在后续的过程中被拆分、合并。
例如在业务实体中，地址是信封的一个属性，出于单独处理地址，比如需要打印地址清单、按地址分发信件等，由于信封->信件是一对一的关系，可以将地址单独拉出来成为地址实体类，并重新建立这样的关系：地址->信封，地址->信件。
在设计阶段，实体类可以被设计为EntityBean、POJO、SDO、XMLBean等设计类甚至一条SQL语句。
从架构角度来说，实体类主要位于数据持久层，实体类的获取对架构设计中的数据持久层有着重要的指导意义。
4．分析类的三高
分析类的抽象层次有三高，正是因为这些特点，使得分析类成为比设计类更好用的元素：
（1）高于设计实现
高于设计实现意味着，在为需求考虑系统实现的时候，可以不理会复杂的设计要求，比如设计模式的应用、框架规范的要求等，而专心地为从需求到实现搭建一座桥梁。如实体类既可以被设计成EntityBean，也可以被设计成POJO，不论是哪种设计实现都要遵循相关的规范，实现特定的接口等。这些复杂的要求在为需求考虑系统实现的时候就成为一些杂音，要处理的信息越多，越容易分散注意力。
（2）高于语言实现
对于分析类，只需要表示出类的职责即可，不必理会实现语言的约束。
（3）高于实现方式
高于实现方式意味着，在为需求考虑系统实现的时候，可以不考虑采用哪一种具体的实现方式。
例如安全认证，可能的实现方式有LDAP、CA认证、JAAC等，如果用对分析类，只需要一个认证控制类代表系统需要这样一个程序逻辑来完成需求即可，至于实现方式则可以先放下不谈。
总的来说，分析类可以让我们更关注于实现需求上，而且由于分析类的抽象层次高，维护分析类更容易获得一个稳定架构来指导整个软件的开发。