VS2010实践RUP4+1架构模型(3)

上文链接

VS2010实践RUP4+1架构模型(1)

VS2010实践RUP4+1架构模型(2)

如需要解决方案源文件,请回复留下你的Email,我会及时回复.

逻辑视图

通过用例图和用例规约说明书,基本上我们已经明确了用户的需求和系统的开发范围,下面我们开始系统的逻辑视图建模,逻辑视图主要关注整个系统的抽象结构，我们在VSTS中主要采用类图和序列图进行表述。

业务领域对象分析

在业务领域对象分析工作中,区分不同类型对象以达成对于模型中不同的工作的理清非常重要。按照业界流行做法，我们可以分类出实体类,控制类,边界类。

• 实体对保存信息和资源的对象的建模，属于系统本质的面的概念性，一般不会随着用例的增多而有所变动。
• 控制类属于功能行为的抽象建模，而且这个功能和用例有相当密切关系，建议对每一个用例提供一个控制对象。
• 一般系统边界类一般是与外包桥接使用,用来隔离系统功能,尽可能减少外部环境变化对于系统的影响,一般包含用户界面类，系统接口类，设备接口类。

首先分析系统业务实体对象并抽象建模。

1. 打开VS项目,选择"业务领域模型"添加新项目，选择添加新UML类图项目,并命名为EPSEntity。
2. 在EPSEntity工作区域，右击设置其属性中的Linked Package为 EPS::Logical View::Class，这样我们新加的类自动会在UML资源管理器中这个包出现。
3. 根据前面分析,采购有两种角色（采购经理和采购职员)，三个类到EPSEntity工作区域,并分别命名为采购人员,采购经理，采购职员，在采购人员类的属性窗口中设置 is abstract 项为 True,完成后如下：
4. 根据业务用例规约描述所涉及的业务实体,完成如下图
5. Ctrl+S，上图中，我们省略了采购计划单和采购请求单的明细，对于类似与这类管理信息系统，在进行业务流域建模的时候，十分准确的抽象出业务实体对象不是那么容易的事情,这个要对行业业务知识深刻理解,同时有具有高度的UML抽象能力，我们可以借助与领域分析中常用的模式 交易模式（Transaction Pattern）去分析。
   典型的交易模式图
6. 分别给各个实体参照用例实现规约设计的业务实体描述，添加相应的属性。

参照用例分析,控制类建模步骤如下，基本上我们对每一个用例提供一个控制类。

1. 打开VS项目,选择"业务领域模型"添加新项目，选择添加新UML类图项目,并命名为EPSBusinessProcess。
2. 在EPSEntity工作区域，右击设置其属性中的Linked Package为 EPS::Logical View::Class，这样我们新加的类自动会在UML资源管理器中这个包出现。
3. 从工具箱中拖入类图，并分别命名如下图：
4. 控制类我们主要关注操作,对于每个控制要有包含什么操作,我们先期可以结合我们业务分析进行抽象合适的操作，随着我们序列图进一步分析，我们要保护的操作也进一步明确精细， 对于我们控制类的粒度,避免过于庞大，操作选择一个逻辑主线,这个也符合我们类的功能单一原则。以产生"请购需求类"为实例,根据前面业务用例规约描述我们需要添加 "转化物料求购计划到物料请购单"和"推荐厂商"及"通知发送功能"。
5. 分别给请购需求类添加上述操作，如下图。
   

对与系统边界类，涉及的到用户界面我们一般选择按照用户操作习惯进行划分,对于每一个用例我们一般提供一个用户界面。 注意本系统中，有两个明显的外部系统：ERP和通知系统,为了避免过度耦合，凡是系统需要和他们交互的操作，尽量设计接口类。：

1. 打开VS项目,选择"业务领域模型"添加新项目，选择添加新UML类图项目,并命名为EPSBoundary。
2. EPSBoundary工作区域，右击设置其属性中的Linked Package为 EPS::Logical View::Class，这样我们新加的类自动会在UML资源管理器中这个包出现。
3. 从工具箱中拖入接口，并分别命名如下图：

回头分析刚才我们的"请购需求"控制类,设计到和ERP和通知平台交互,那么"请购需求"和边界类必然发生关系，调整"请购需求"如下

1. 打开EPSBusinessProcess的工作区域。
2. 打开UML模型资源管理器,在Class包中选中"EPSForERP"和"通知发送Proxy"接口拖入EPSBusinessProcess的工作区域。
3. 分别建立"请购需求"和他们关联关系：
4. Ctrl+S保存,下面我们开始序列图分析。

《待续...》