一：基本概念
---->在那大数项目中，分析类是被忽视的一种非常有用的元素。
---->分析类用于获取系统中主要的“职责簇”，他们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。如果期望获得系统的“高级”概念性简述，则可对分析类本身进行维护，分析类还可产生系统设计的主要抽象——系统的设计类和子系统。
二：分析类的性质
----->分析类代表系中主要的“职责簇”，这以为着分析类是从功能性需求向计算机实现转化过程中的“第一个关口”
----->分析类可以产生系统的设计类和子系统，这代表着计算机实现是可以通过某中途径产生出来，而不是拍脑袋拍出来的。
三：分析类的版型，是类（class）的版型
【1】边界类
---->边界类是一种用于对系统外部环境与内部运作之间的交互进行建模的类。
--->参与者与用例之间应当建立边界类
--->用例与用例之间如果有交互，应当为其建立边界类。
（1）一个用例如果要访问另一个用例，直接访问用例内部对象是不好的结构，这样将导致紧耦合的发生，而边界类可以格力这种直接访问，其作用相当于门面模式。在最终实现时用例之间的边界类可以演化成一组API，一组JMS消息或是一组代理类。
--->如果用例与系统边界之外的非人对象交互，例如第三方系统，应当为其建立边界类。
（1）这通常是因为异构系统，异构数据，访问权限，安全通道等原因。在具体实现时，边界类可以演化为中介和通信协议。中介的例子如网关，通信中间件，代理服务器，安全认证服务器，webservice,SOA组件。通信协议的例子如HTTP，FTP，SSL，RMI，SOAP等
---->在相关联的业务对象有明显的独立性要求，则他们可能在各自的领域内发展和变化，但又希望互不影响时，也应当为它们建立边界类。
---->从架构角度上来说，边界类主要位于展现层。边界类的获取对架构设计中展现层有着重要的指导意义。
一个好的边界类应该有以下特点：
（1）边界类应该有主语提高系统的可用性
（2）边界类应该尽可能地保持在较高的层次（如概念层次）上
（3）边界类应该合理封装介于系统与主角之间的交互。
（4）如果主角改变他们为系统提供输入的方式，边界类就应该是唯一需要改变的对象。
（5）如果系统改变为主角提供输出的方式，边界类就应该是唯一需要改变的对象。
（6）边界类必须“知道”其他对象类型（例如控制对象和实体对象）的需求，以便他们能够得以实施，并且对于“系统内部元素”报纸其可用性和有效性
【2】控制类
----->控制类对于一个或几个用例所特有的控制行为进行建模。控制对象（控制类的实例）通常控制其他对象。因为他们的行为具有协调性质。控制类将用例的特有行为进行封装
----->控制类来源于对用例场景中行为的定义，换句话说，控制类来源于对用例场景当中动词的分析和定义，包括限制动词的描述。
--->例如我们曾经提到过的寄信人到邮局寄信的用例场景。该场景描述为：寄信人到达邮局，购买信封，经信装入信封，写上地址，称重，计算邮资，购买邮票，贴上邮票，邮寄信件，拿走回执。在这个场景中，购买，装入，写上，计算，购买，贴上，邮寄的行为都可以成为控制类的来源。
---->在提取控制类时，要认真考察用例场景中的行为，如果这些行为在执行步骤，执行要求，或者执行结果上具有类似的特征，应当考虑进行适当的抽象。例如合并或者抽取超类。同时，也要考察这些行为是否对要建设的系统产生影响进而进行一些取舍。例如上面的场景，装入，写上，贴上的行为是寄信人的人工行为，不会对寄信系统产生影响，因而可以舍去。
---->在UML的定义中，认为控制类主要起到协调对象的作用。例如从边界类通过控制类访问实体类。或者实体类通过控制类访问另一个实体类。但是UML的定义也认为不必强制使用控制类，例如边界类也可以直接访问实体类。
【3】实体类
---->实体类是用于对必须存储的信息和相关行为建模的类。实体对象（实体类的实例）用于保存和更新一些现象的有关信息。例如，事件，人员或者一些现实生活中的对象。实体类通常都是永久性的。他们所具有的属性和关系是长期需要的。有时甚至在系统的整个生存期都需要。
---->实体类源于业务模型中的业务实体。
四：分析类的三高
---->分析类是从业务需求向系统设计转化过程中最为主要的元素。他们在高层次抽象出系统的实现业务需求的原型。业务需求通过分析类被逻辑化，成为可以被计算机理解的语意。分析类的抽象层次有三高的特点，正是因为这些特点，让分析类成为比设计类“更好用”的元素，也是作者喜欢使用分析类的最重要的原因。分析类的三高分别是：
