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

[size=x-large]逻辑视图 [/size]
通过用例图和用例规约说明书,基本上我们已经明确了用户的需求和系统的开发范围,下面我们开始系统的逻辑视图建模,逻辑视图主要关注整个系统的抽象结构,我们在VSTS中主要采用类图和序列图进行表述。
[size=x-large]业务领域对象分析[/size]
在业务领域对象分析工作中,区分不同类型对象以达成对于模型中不同的工作的理清非常重要。按照业界流行做法,我们可以分类出实体类,控制类,边界类。
实体对保存信息和资源的对象的建模,属于系统本质的面的概念性,一般不会随着用例的增多而有所变动。
控制类属于功能行为的抽象建模,而且这个功能和用例有相当密切关系,建议对每一个用例提供一个控制对象。
一般系统边界类一般是与外包桥接使用,用来隔离系统功能,尽可能减少外部环境变化对于系统的影响,一般包含用户界面类,系统接口类,设备接口类。
首先分析系统业务实体对象并抽象建模。
1. 打开VS项目,选择"业务领域模型"添加新项目,选择添加新UML类图项目,并命名为EPSEntity。
2. 在EPSEntity工作区域,右击设置其属性中的Linked Package为 EPS::Logical View::Class,这样我们新加的类自动会在UML资源管理器中这个包出现。
[img]http://images.cnblogs.com/cnblogs_com/roping/VSRUP20101210.001png.png[/img]
3. 根据前面分析,采购有两种角色(采购经理和采购职员),三个类到EPSEntity工作区域,并分别命名为采购人员,采购经理,采购职员,在采购人员类的属性窗口中设置 is abstract 项为 True,完成后如下:
[img]http://images.cnblogs.com/cnblogs_com/roping/VSRUP20101210.002png.png[/img]
4.根据业务用例规约描述所涉及的业务实体,完成如下图
[img]http://images.cnblogs.com/cnblogs_com/roping/VSRUP20101210.003png.png[/img]
5.Ctrl+S,上图中,我们省略了采购计划单和采购请求单的明细,对于类似与这类管理信息系统,在进行业务流域建模的时候,十分准确的抽象出业务实体对象不是那么容易的事情,这个要对行业业务知识深刻理解,同时有具有高度的UML抽象能力,我们可以借助与领域分析中常用的模式 交易模式(Transaction Pattern)去分析。
[img]http://images.cnblogs.com/cnblogs_com/roping/VSRUP20101210.004png.png[/img]
6.分别给各个实体参照用例实现规约设计的业务实体描述,添加相应的属性。

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

1. 打开VS项目,选择"业务领域模型"添加新项目,选择添加新UML类图项目,并命名为EPSBusinessProcess。
2. 在EPSEntity工作区域,右击设置其属性中的Linked Package为 EPS::Logical View::Class,这样我们新加的类自动会在UML资源管理器中这个包出现。
[img]http://images.cnblogs.com/cnblogs_com/roping/VSRUP20101210.001png.png[/img]
3. 从工具箱中拖入类图,并分别命名如下图:
[img]http://images.cnblogs.com/cnblogs_com/roping/VSRUP20101210.005png.png[/img]
4. 控制类我们主要关注操作,对于每个控制要有包含什么操作,我们先期可以结合我们业务分析进行抽象合适的操作,随着我们序列图进一步分析,我们要保护的操作也进一步明确精细, 对于我们控制类的粒度,避免过于庞大,操作选择一个逻辑主线,这个也符合我们类的功能单一原则。以产生"请购需求类"为实例,根据前面业务用例规约描述我们需要添加 "转化物料求购计划到物料请购单"和"推荐厂商"及"通知发送功能"。
5. 分别给请购需求类添加上述操作,如下图。
[img]http://images.cnblogs.com/cnblogs_com/roping/VSRUP20101210.006png.png[/img]
对与系统边界类,涉及的到用户界面我们一般选择按照用户操作习惯进行划分,对于每一个用例我们一般提供一个用户界面。 注意本系统中,有两个明显的外部系统:ERP和通知系统,为了避免过度耦合,凡是系统需要和他们交互的操作,尽量设计接口类。:
1. 打开VS项目,选择"业务领域模型"添加新项目,选择添加新UML类图项目,并命名为EPSBoundary。
2. EPSBoundary工作区域,右击设置其属性中的Linked Package为 EPS::Logical View::Class,这样我们新加的类自动会在UML资源管理器中这个包出现。
3. 从工具箱中拖入接口,并分别命名如下图:
[img]http://images.cnblogs.com/cnblogs_com/roping/VSRUP20101210.007png.png[/img]
回头分析刚才我们的"请购需求"控制类,设计到和ERP和通知平台交互,那么"请购需求"和边界类必然发生关系,调整"请购需求"如下
1. 打开EPSBusinessProcess的工作区域。
2. 打开UML模型资源管理器,在Class包中选中"EPSForERP"和"通知发送Proxy"接口拖入EPSBusinessProcess的工作区域。
3. 分别建立"请购需求"和他们关联关系:
[img]http://images.cnblogs.com/cnblogs_com/roping/VSRUP20101210.008png.png[/img]
4. Ctrl+S保存,下面我们开始序列图分析。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
TOGAF(开放式集成企业架构)和RUP(统一过程)都是软件开发领域的方法论和框架。以下是它们之间的区别: 1. 方法论:TOGAF是一种企业架构方法论,强调整体架构的规划、设计和管理。它提供一套定义、分析和实现企业架构的指南和工具。而RUP则是一种软件开发生命周期方法论,强调软件开发过程中的需求管理、分析、设计和测试。 2. 范围:TOGAF的范围更加广泛,涵盖了整个企业架构的各个方面,包括业务架构、信息架构、应用架构和技术架构。而RUP则主要关注软件开发过程中的需求管理、项目规划、软件设计和开发方法。 3. 灵活性:TOGAF比较灵活,可以根据不同的组织需求和目标进行定制。它提供了一种框架,允许组织根据自身的情况选择和定义适合自己的企业架构方法和工具。相比之下,RUP相对较为约束,更加注重标准化的软件开发过程。 4. 适用领域:TOGAF适用于各种规模的企业和组织,无论其行业或类型。它可以帮助组织规划和实施整体架构,以支持业务目标的实现。RUP主要适用于软件开发领域,特别是大型项目或具有复杂需求的软件系统。 总而言之,TOGAF和RUP都是在软件开发和企业架构领域中起指导作用的方法论和框架。它们关注的焦点和应用范围稍有不同,但都可以帮助组织有效管理和开发软件系统或整体架构

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值