【建模】分析类

作用：需求到设计实现的桥梁

• 用于获取系统中主要的“职责簇”。功能性需求向计算机实现转化过程的第一步
• 可以产生系统的设计类和子系统，计算机实现时通过某途径产生出来，而不是拍脑袋出来的。

---

构成：边界类，实体类，控制类

边界类：对象A和对象B对象之间进行建模时，充当两者交互的载体 （架构角度，主要位于展现层）

边界类常见场景：

• 参与者与用例之间
• 用例与用例之间
• 用例与系统边界之外的非人对象交互
• 相关联业务对象有明显的独立性要求

特点：

• 提供系统的可用性
• 保持在较高的层次上（概念层次）
• 合理封装介于系统与主角之间的交互
• 主角改变它们为系统提供的输入的方式，边界类就应该是唯一需要改变的对象
• 系统改变主角提供的输出方式，边界类就应该是唯一需要改变的对象
• 边界类必须知道其他对象类型的需求，以便它们能够得以实施，并相对于系统内部元素保持其可用性和有效性

---

控制类：来源对于用例场景中动词对的分析和定义，包括限制动词的描述。具有协调性质，将用例的特有的行为进行封装。

（架构角度，主要位于业务逻辑）

在设计阶段被设计为：Session Bean，COM+,Server Let, JAVA类，C++类等设计类

---

实体类：业务模型中实体 （架构角度，主要位于数据持久层）

在设计阶段被设计为：Entity Bean, POJO，SDO, XML Bean等设计类，甚至是一条sql语句

---

分析类三高： 高于设计实现，高于语言实现，高于实现方式   （基本停留在 "概念" 阶段），专注分析实现需求上，抽象层次较高，比设计和实现更稳定，在一个演进式得软件生命周期里，维护稳定的分析类比维护易变得设计类花费更少的精力，相对容易获得一个稳定架构来指导整个软件的开发。