[转] RUP4+1架构方法

转自：http://www.cnblogs.com/Roping/archive/2010/12/08/1900251.html

RUP4+1架构方法

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年提出后在业界获得广泛应用，并得以发展完善,在具体应用的时候结合公司环境和项目实际进行适当裁剪。

微软VSTS2010 UML增强

Visual Studio 2010绝对不是单一的一个IDE环境, 将应用程序开发生命周期的方方面面与 Team Foundation Server 集成, VS2010提供了相对完备的UML开发软件设计模型功能。目前VS2010支持新建UML模型如下包：  

UML关系图	主要作用
活动图	业务流程中的操作和参与者之间的工作流
组件图	系统的组件、组件的接口、端口和关系
类图	用于在系统中存储和交换数据的类型及其关系
序列图	对象、组件、系统或参与者之间的交互序列
用例图	系统支持的用户目标和任务

而且微软提供了VS2010旗舰版的可视化建模功能包，加强UML建模能力和便捷性。

实现RUP4+1架构

案例背景说明

IDM是一家家电制造商,目前企业已经有ERP系统,外部系统可以通过JDBC访问该系统授权的数据,同时该公司的有电子邮件系统也提供SMTP方式让外部程序调用。该公司计划开发一个电子化采购系统(EPS),基本需求如下：

l IDM生产计划在ERP设定后，会自动产生原料请购记录到EPS，EPS自动产生采购要求(Request For Purchase;RFP),并利用短信系统已经电子邮件通知注册的供应商。

l 供应商收到通知后必须先到IDM的EPS中在采购要求规定的时间内提供报价单

l IDM的采购人员(Buyer)通过EPS比价策略进行供应商选择产两家供应商并生采购单,同时通过短信和邮件通知该两家供应商。

l 供应商收到短信后,若要确认供货，到EPS中确认采购单,EPS通过电子邮件通知该采购负责人(Buyer)

l 采购人员在EPS中确认该采购后，EPS回传该订单到IDM的ERP系统中和该两家供应商。

用例视图

根据需求初步描述，抽象出该采购系统涉及的角色有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

下面我们把用例规约文档集成到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进行管理。

 

UML模型资源管理器

随着我们项目越来越大,项目的Item越来越多，从可读性和可维护性的角度，我们要整理下我们项目了。

 UML资源管理器方便我们对UML资源进行管理，既然我们是基于Rup4+1模型进行架构，那么我们可以UML资源管理器的设置如下：

1.   打开UML资源管理器，右击添加包，并从新命名为Scenarios

 

2.   依次添加如下包，结构如下：

 

3.   在UML资源浏览器中以此把Actor和用例拖入相应的包。

4.   打开解决方案浏览器窗口，整理我们解决方案文件夹。

 

逻辑视图

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

《待续...》

 

小技巧

微软支持项目模板重用功能，你可以参考：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 团队开发实用手册》