[转] RUP4+1架构方法
?????????????????
?图?1. RUP4+1架构图
用例视图(Use Cases View),最初称为场景视图,关注最终用户需求,为整个技术架构的上线文环境.通常用UML用例图和活动图描述。
逻辑视图(Logical view),主要是整个系统的抽象结构表述,关注系统提供最终用户的功能,不涉及具体的编译即输出和部署,通常在UML中用类图,交互图,时序图来表述,类似与我们采用OOA的对象模型。
开发视图(Development View),?描述软件在开发环境下的静态组织,从程序实现人员的角度透视系统,也叫做实现视图(implementation view).开发视图关注程序包,不仅包括要编写的源程序,还包括可以直接使用的第三方SDK和现成框架、类库,以及开发的系统将运行于其上的系统软件或中间件,?在UML中用组件图,包图来表述.?开发视图和逻辑视图之间可能存在一定的映射关系:比如逻辑层一般会映射到多个程序包等。
处理视图(Process view)处理视图关注系统动态运行时,主要是进程以及相关的并发、同步、通信等问题。处理视图和开发视图的关系:开发视图一般偏重程序包在编译时期的静态依赖关系,而这些程序运行起来之后会表现为对象、线程、进程,处理视图比较关注的正是这些运行时单元的交互问题,在UML中通常用活动图表述。
物理视图(Physical view?)物理视图通常也叫做部署视图(deployment view),是从系统工程师解读系统,关注软件的物流拓扑结,以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系:处理视图特别关注目标程序的动态执行情况,而物理视图重视目标程序的静态位置问题;物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。
RUP4+1架构方法从1995年提出后在业界获得广泛应用,并得以发展完善,在具体应用的时候结合公司环境和项目实际进行适当裁剪。
UML关系图
主要作用
活动图
业务流程中的操作和参与者之间的工作流
组件图
系统的组件、组件的接口、端口和关系
类图
用于在系统中存储和交换数据的类型及其关系
序列图
对象、组件、系统或参与者之间的交互序列
用例图
系统支持的用户目标和任务
而且微软提供了VS2010旗舰版的可视化建模功能包,加强UML建模能力和便捷性。
根据需求初步描述,抽象出该采购系统涉及的角色有IDM的EPR系统,采购人员(Buyer),供应商涉及用例有产生采购需求,确定供应商,报价等。步骤如下:
1.打开VS2010,新建项目,选择建模项目,并合理命名和解决方案位置,点击确定。
?
?
?
2.添加新项,选择添加新项目,选择UML用例图并命名,点击确定下一步
?
3.从工具箱中拖入如图各个用例和角色,并命名
?
4.按Crtl+S保存,在迭代开发过程中做到这一步和用户进一步沟通,发现IDM公司已经有通知系统平台可以调用发送短信和邮件通知,同时,采购人员分为采购经理和普通职员,采购确认由采购经理完成。用例图进一步调整如下:
?
?
5.图例说明:在系统中,用例送货位于系统边界外,不作为系统开发范围,其存在为了更好的解释系统的流程的完整行,?参与者不一定是人,ERP和通知系统作为参与者存在,另外比价作为单独用例存在意义不大,细心的读者可能会问?“产生原料请购记录”怎么没有作为系统用例存在?分析下可知,“产生原料请购记录“是ERP功能,EPS承担转化?“请购记录”到“采购请求”功能,因此没有作为EPS用例出现。?更多的关于用例分析请参考《Think in UML大象》
根据需求初步描述,我们给出来EPS的系统用例图.如果业务流程过于复杂,并且涉及不同的角色,可以采用带有泳道的活动图去表达.
??
?
目前VS2010还不支持带有泳道的活动图,如何要展示更精确的用例细节,必须使用用例规约来进行描述。基本上用例图+用例规约足够用了。
一般用例规约叙述要包含以简要说明,用例的正常流,替代事件流,业务规则,涉及实体等,用户在使用的时候可以参考RUP文档模型模板,请切记,您的目的是要阐明问题,而不是混淆问题。
用例名称
产生采购请求
用例描述
系统根据ERP原材料请求记录产生请购单
执行者
ERP
前置条件
1.ERP系统被EPS授权访问
后置条件
1.????创建新的采购请求单并生成唯一编号
2.????触发通知系统给合格供应商发送采购需求
正常流
1.????ERP提供[物料采购计划]给系统
2.????系统根据业务规则1?生成[采购请求单]
3.????系统根据业务规则?2?产生[推荐询价厂商名单]
4.????系统触发通知系统按照[推荐询价厂商名单]发送[物料请购需求]
替代流以及异常处理
2a.系统找不到该物料的[询价厂商]
?1.系统标示该物料为[缺料]
业务规则
1.????对于每个物料找出所有该物料的供应商并且其交易评级为”A”,如果符合条件的供应商小于<2,找出所有交易评级为”B”且供应该物料的供应商。
2.????编号规则?以?“RPF”开头加上年月日+递增序号:RPF2010120900000002
涉及实体
1.????物料采购计划
物料编号,期望采购月份,数量,底标价格
2.????采购请求单
采购请求单号,物流采购计划单号
3.????物流请购需求单
物料编号,厂商物料编号,预计采购月份,预计采购数量
4.????推荐询价厂商
物料编号,厂商,联系人,电话
?
表1产生采购请求用例实现规约
注意:我们在一直强调迭代开发,在用例规约描述中,?替代事件流以及异常处理远远多于正常事件流,因此我们这个规约是个逐步完善的过程,早期千万不要穷尽分析他们而忽视了正常流这一系统主要因素。
下面我们把用例规约文档集成到VS2010,并建立和相应的用例联系。
1.???????????用Word用例规约描述,可以把所有的用例规约放在一个Word文档,也可以分类别各自描述,这样在我们实施Scrum开发时候方便任务分配。参考表1.
2.???????????打开我们上一节保存的项目方案,选择添加现有项目,把你的用例规约Word文档添加到项目中来。
3.???????????选择添加新建用例图项目命名为EPSUsecaseDescribe,这个图我们主要是描述用例和用例实现规约对应关系
?
4.???????????从项目解决方案中拖入word文档到EPSUsecaseDescribe工作区。
5.???????????打开UML资源管理器,拖入相关用例并建立联系。
?
6.???????????Ctrl+S保存。
我们说过,RUP4+1是基于用例驱动实现架构视图,而VSTS2010实现了软件全生命周期管理,如果我们基于Scrum开发,我们的用例可以方便转化为我们Product Backlog,我们这里做的用例规约很容易转化为我们的测试Task,而且他们的关系可以方便通过VSTS进行管理。
?
随着我们项目越来越大,项目的Item越来越多,从可读性和可维护性的角度,我们要整理下我们项目了。
?UML资源管理器方便我们对UML资源进行管理,既然我们是基于Rup4+1模型进行架构,那么我们可以UML资源管理器的设置如下:
1.???打开UML资源管理器,右击添加包,并从新命名为Scenarios
?
2.???依次添加如下包,结构如下:
?
3.???在UML资源浏览器中以此把Actor和用例拖入相应的包。
4.???打开解决方案浏览器窗口,整理我们解决方案文件夹。
?
逻辑视图通过用例图和用例规约说明书,基本上我们已经明确了用户的需求和系统的开发范围,下面我们开始系统的逻辑视图建模,逻辑视图主要关注整个系统的抽象结构,我们在VSTS中主要采用类图和序列图进行表述。业务领域对象分析在业务领域对象分析工作中,区分不同类型对象以达成对于模型中不同的工作的理清非常重要。按照业界流行做法,我们可以分类出实体类,控制类,边界类。实体对保存信息和资源的对象的建模,属于系统本质的面的概念性,一般不会随着用例的增多而有所变动。控制类属于功能行为的抽象建模,而且这个功能和用例有相当密切关系,建议对每一个用例提供一个控制对象。一般系统边界类一般是与外包桥接使用,用来隔离系统功能,尽可能减少外部环境变化对于系统的影响,一般包含用户界面类,系统接口类,设备接口类。首先分析系统业务实体对象并抽象建模。?
微软支持项目模板重用功能,你可以参考:http://msdn.microsoft.com/zh-cn/library/dd393742(en-us).aspx
《待续》
?Kruchten, Philippe (1995, November).?Architectural Blueprints — The “4+1” View Model of Software Architecture.?IEEE Software 12 (6), pp. 42-50.
《UML与Enterprise Architect 团队开发实用手册》
?