2.4分析模型

如果说用例实现描绘了软件世界的蓝图，软件架构和框架搭建了软件世界的骨架，那么分析模型的工作就是在骨架中注入血肉。
分析模型在前面已多次出现。领域模型的时候，我们采用分析类来建立模型；在建立概念模型的时候，我们采用分析类来建立模型；在建立用例实现模型的收，我们也采用分析类来建立模型。概念模型，领域模型这些都是项目的不同阶段，那么分析类该在哪个阶段使用呢？
其实分析模型只是分析阶段所使用的工具，即，凡是在项目过程中，需要对需求进行分析，得到系统视觉的理解时，都可以使用分析模型。
本节我们将使用分析模型来获得系统需求在软件架构各层次上的系统视觉理解。

2.4.1建立分析模型

我们在系统用例实现的时候获得了下达入库指令的分析类。而要将分析类与软件架构结合起来，首先要确定这些类在软件架构的哪个层次。而在架构的时候我们已经确认了有Web, BusinessControl，Entity，DBControl和DB这五个层次。现在我们逐个分析这些分析类所在的层次，以及软件架构引入后分析模型的变化情况。例如：
 Bun_批量下达入库指令和bun_下达入库指令无疑是位于web层的。
 Con_下达入库指令控制用于处理业务逻辑也应该位于BusinessControl层
 工作流引擎是软件建构组成部分，与工作流引擎剿劣的类是con_下达入库指令控制，因此，工作流引擎也应该位于BusinessControl层
 rule接口也同工作流引擎一样，也应该位于BusinessControl层
 ent_入库指令单就有些特殊，在软件架构中，数据在不同层次有不同表现形式。有在web和businessControl层用于显示数据的VO，也有用于持久化的PO形式，位于不同软件层次，被不同层次使用，并经有Entity层进行转换。

将分析类各个层次分析清楚后，根据用例实现原图，我们需要再次绘制出用例实现的场景图。由于有了软件架构，我们就需要在每个层次上在软件框架的规范内来实现用例场景。

在框架下，原来的下达入库指令边界被实现成如下图所示结构。

web层分析类图
上面只是web层的例子。同理我们还需要在BusinessControl层，Entity层来实现它。

BusinessControl层分析类

Entity层分析类

最后我们将这些进行合并，形成一个整理的分析类图。

下达入库指令分析类