一起谈.NET技术,VS2010实践RUP4+1架构模型

  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),基本需求如下:

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

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

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

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

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

  用例视图

  根据需求初步描述,抽象出该采购系统涉及的角色有IDM的EPR系统,采购人员(Buyer),供应商涉及用例有产生采购需求,确定供应商,报价等。步骤如下:

  1.打开VS2010,新建项目,选择建模项目,并合理命名和解决方案位置,点击确定。

  2.添加新项,选择添加新项目,选择UML用例图并命名,点击确定下一步

  3.从工具箱中拖入如图各个用例和角色,并命名

  4.按Crtl+S保存,在迭代开发过程中做到这一步和用户进一步沟通,发现IDM公司已经有通知系统平台可以调用发送短信和邮件通知,同时,采购人员分为采购经理和普通职员,采购确认由采购经理完成。用例图进一步调整如下:

  5.图例说明:在系统中,用例送货位于系统边界外,不作为系统开发范围,其存在为了更好的解释系统的流程的完整行, 参与者不一定是人,ERP和通知系统作为参与者存在,另外比价作为单独用例存在意义不大,细心的读者可能会问 “产生原料请购记录”怎么没有作为系统用例存在?分析下可知,“产生原料请购记录“是ERP功能,EPS承担转化 “请购记录”到“采购请求”功能,因此没有作为EPS用例出现。 更多的关于用例分析请参考《Think in UML大象》

时间: 2024-07-30 02:51:15

一起谈.NET技术,VS2010实践RUP4+1架构模型的相关文章

VS2010实践RUP4+1架构模型

RUP4+1架构方法 RUP4+1架构方法采用用例驱动,在软件生命周期的各个阶段对软件进行建模,从不同视角对系统进行解读,从而形成统一软件过程架构描述. 图 1. RUP4+1架构图 用例视图(Use Cases View),最初称为场景视图,关注最终用户需求,为整个技术架构的上线文环境.通常用UML用例图和活动图描述. 逻辑视图(Logical view),主要整个系统的抽象结构表述主要关注系统提供最终用户的功能,不涉及具体的编译即输出和部署,通常在UML中用类图,交互图,时序图来表述,类似与

VS201“.NET研究”0实践RUP4+1架构模型

RUP4+1架构方法 RUP4+1上海企业网站设计与制作架构方法采用用例驱动,在软件生命周期的各个阶段对软件进行建模,从不同视角对系统进行解读,从而形成统一软件过程架构描述.                   图 1. RUP4+1架构图 用例视图(Use Cases View),最初称为场景视图,关注最终用户需求,为整个技术架构的上线文环境.通常用UML用例图和活动图描述. 逻辑视图(Logical view),主要整个系统的抽象结构表述主要关注系统提供最终用户的功能,不涉及具体的编译即输出

一起谈.NET技术,走向ASP.NET架构设计——第五章:业务层模式,原则,实践(前篇)

在上一章中,我们讲述了有关业务层分层的一些知识,下面我们就来看看,在具体的业务层的设计中,我们可以采用哪些模式可以将业务层设计的更加的灵活! 架构模式 首先我们就来看看,如何更加有效的组织业务规则. Specification Pattern(需求规格模式) 这个模式的使用方法就是:把业务规则放在业务类的外面,并且封装成为一个个返回boolean值的算法.这些一个个的业务规则的算法不仅仅便于管理和维护,并且还可以被重用,而且很方便的组织成为复杂的业务逻辑. 下面我们就来看一个以在线租DVD的公司

一起谈.NET技术,走向ASP.NET架构设计——第一章:走向设计

前言:很多做开发的人都在不断的摸索着,积极的学习,试图找出一条走向架构设计的成功法则.每当有人问起我们的职业,我们也常常在说:"软件设计".有时,我就在想:"设计",这个已经被我们嚼烂了的词,到底有多少人真正懂"设计"的含义. 自动进入IT,走在开发这条路上,就一直在不断的摸索,寻找,苦思:如何能够才能成为架构师.于是在网络上不断的收集和阅读架构设计方面的书籍和资料,到处在找一些架构师的传记,文章和甚至是采访资料..... 同时一直不断的请教自己

一起谈.NET技术,走向ASP.NET架构设计——第四章:业务层分层架构(后篇)

今天的内容比较简单,也是本章的一个收尾! Anemic Domain Model 这种模式和之前讲述的Domain Model有很多的相似的地方.在之前的Domain Model中,每个业务类都包含了自己的业务逻辑和数据,以及对象之前的关系:但是在Anemic Domain Model,每个业务类仅仅只是包含了一些保存业务数据的属性,把相应的业务规则从原本的业务类中移到了另外的一个专门的业务规则类(Specification Pattern,我们后面的章节讲述),同时把相应的业务方法移到了ser

一起谈.NET技术,走向ASP.NET架构设计——第六章:服务层设计(前篇)

本篇主要是为后文做铺垫,所以理论的东西相对而言比较的多一点! 服务层的概述 首先解释一下什么是"服务Service",从广义来讲:只要是你使用了别人的东西,那么你就在使用别人提供的服务.在这里,服务就是指可能被一个或者多个系统使用的核心的业务逻辑,我们可以把服务简单的想象成为一些可供调用的API. 在之前的第四章中,我们讲述了如何组织业务逻辑,第五章讲述了在业务层的设计中可以采用的一些模式.但是还有一个问题需要大家考虑的是:如何把业务层提供给其他的层来调用? 可能认为这个问题有莫名奇妙

一起谈.NET技术,走向ASP.NET架构设计——第二章:设计/ 测试/代码

再次申明一下:本系列不是讲述TDD的,只是用TDD来建立设计的思想.即便是用DDD,有时候还是结合TDD一起使用的. 开发方式比较 我们用下面的一段分析来引出今天的内容: 想想我们平时是如何在写代码:拿来需求,分析功能,编写功能代码.这样的方式,没有问题,大家也一直沿用很多年了.为了后面描述方便,我们称这种方式为传统流程. TDD的怎么做的: 拿来需求,分析功能,写功能测试代码,编写功能代码.其实两个过程差不多的,真的差不多的. 首先来分析下两种开发流程.个人认为:因为TDD多了一个角色转换的过

一起谈.NET技术,走向ASP.NET架构设计——第三章:分层设计,初涉架构(中篇)

1.阐明示例需求 本篇还是用之前的电子商务网站中的一个简单的场景来讲述:在页面上需要显示产品的列表信息.并且根据产品的类型不同,计算出相应的折扣. 在上篇中,我们已经设计项目的逻辑分层.我们再来回顾下: 可能有的朋友认为从Smart UI立刻跳到这种分层设计,似乎快了些.其实也算是一个思想的跳跃吧.下面就来看看这种分层是如何解决之前Smart UI的问题的. 2.业务层设计 记得在之前的Smart UI的例子中,程序的业务逻辑是直接写在了ASPX页面后面的cs代码中的.现在,采用分层的方法,我们

一起谈.NET技术,走向ASP.NET架构设计——第四章—业务层分层架构(中篇)

在上一篇文章中,我们讨论了两种组织业务逻辑的模式:Transaction Script和Active Record.在本篇中开始讲述Domain Model和Anemic Model. Domain Model 在开发过程中,我们常常用Domain Model来对目标的业务领域建模.通过Domain Model建模的业务类代表了目标领域中的一些概念.而且,我们会看到通过Domain Model建模的一些对象模拟了业务活动中的数据,有的对象还反映了一些业务规则. 我们就来看看电子商务系统的开发,在