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

简介:   RUP4+1架构方法  RUP4+1架构方法采用用例驱动,在软件生命周期的各个阶段对软件进行建模,从不同视角对系统进行解读,从而形成统一软件过程架构描述.                 图 1. RUP4+1架构图  用例视图(Use Cases View),最初称为场景视图,关注最终用户需求,为整个技术架构的上线文环境.通常用UML用例图和活动图描述。

  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大象》

目录
相关文章
|
20天前
|
设计模式 安全 Java
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
23 0
|
9天前
|
Kubernetes 安全 Java
构建高效微服务架构:从理论到实践
【4月更文挑战第9天】 在当今快速迭代与竞争激烈的软件市场中,微服务架构以其灵活性、可扩展性及容错性,成为众多企业转型的首选。本文将深入探讨如何从零开始构建一个高效的微服务系统,覆盖从概念理解、设计原则、技术选型到部署维护的各个阶段。通过实际案例分析与最佳实践分享,旨在为后端工程师提供一套全面的微服务构建指南,帮助读者在面对复杂系统设计时能够做出明智的决策,并提升系统的可靠性与维护效率。
|
1天前
|
消息中间件 运维 监控
现代化软件开发中的微服务架构设计与实践
本文将深入探讨现代化软件开发中微服务架构的设计原则和实践经验。通过分析微服务架构的优势、挑战以及常见的设计模式,结合实际案例,帮助开发者更好地理解如何构建可靠、可扩展、高效的微服务系统。
|
1天前
|
负载均衡 Java 开发者
细解微服务架构实践:如何使用Spring Cloud进行Java微服务治理
【4月更文挑战第17天】Spring Cloud是Java微服务治理的首选框架,整合了Eureka(服务发现)、Ribbon(客户端负载均衡)、Hystrix(熔断器)、Zuul(API网关)和Config Server(配置中心)。通过Eureka实现服务注册与发现,Ribbon提供负载均衡,Hystrix实现熔断保护,Zuul作为API网关,Config Server集中管理配置。理解并运用Spring Cloud进行微服务治理是现代Java开发者的关键技能。
|
5天前
|
Linux 数据安全/隐私保护
Linux基础与服务器架构综合小实践
【4月更文挑战第9天】Linux基础与服务器架构综合小实践
1053 6
|
17天前
|
消息中间件 安全 API
构建高效微服务架构:策略与实践
【4月更文挑战第1天】在数字化转型的浪潮中,微服务架构已成为企业追求敏捷、可扩展和灵活部署的重要技术手段。本文将深入探讨如何通过合理的设计原则和先进的技术栈,构建一个高效的微服务系统。我们将剖析微服务设计的核心要点,包括服务的划分、通信机制、数据一致性以及安全性问题,并结合案例分析,展示如何在现实世界中应用这些策略以提升系统的可靠性和性能。
|
18天前
|
设计模式 API 持续交付
构建高效微服务架构:从理论到实践
在当今快速迭代和部署的软件开发环境中,微服务架构已成为一种流行的设计模式,它允许开发团队以模块化的方式构建、维护和扩展应用程序。本文将深入探讨微服务的核心概念,包括其定义、优势、挑战以及如何在实际项目中实施。我们将通过一个实际案例来展示如何将传统的单体应用拆分成一系列独立、松耦合的服务,并通过容器化、服务发现、API网关和持续集成/持续部署(CI/CD)等技术手段来管理这些服务。
|
20天前
|
存储 监控 安全
金石推荐 | 【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下Saml协议的运作机制和流程模式
金石推荐 | 【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下Saml协议的运作机制和流程模式
18 0
|
20天前
|
存储 Java 应用服务中间件
【分布式技术专题】「架构实践于案例分析」盘点互联网应用服务中常用分布式事务(刚性事务和柔性事务)的原理和方案
【分布式技术专题】「架构实践于案例分析」盘点互联网应用服务中常用分布式事务(刚性事务和柔性事务)的原理和方案
42 0