逻辑视图
通过用例图和用例规约说明书,基本上我们已经明确了用户的需求和系统的开发范围,下面我们开始系统的逻辑视图建模,逻辑视图主要关注整个系统的抽象结构,我们在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保存,下面我们开始序列图分析。