软件体系结构4+1模型(尚未完成,例子还没有写)

第一节:视图间的关联

              è½¯ä»¶ä½ç³»ç»æââ4+1è§å¾ï¼æ´çèµæï¼

                                                                      图1 整体结构

用例视图(Use Cases Vie:最初称为场景视图(Scenarios),关注最终用户需求,为整个技术架构的上线文环境.通常用UML用例图活动图描述。

逻辑视图(Logical view):主要是整个系统的抽象结构表述,关注系统提供最终用户的功能,不涉及具体的编译即输出和部署,通常在UML中用类图,交互图,时序图来表述,类似与我们采用OOA的对象模型。

开发视图(Development View): 描述软件在开发环境下的静态组织,从程序实现人员的角度透视系统,也叫做实现视图(implementation view).开发视图关注程序包,不仅包括要编写的源程序,还包括可以直接使用的第三方SDK和现成框架、类库,以及开发的系统将运行于其上的系统软件或中间件, 在UML中用组件图,包图来表述. 开发视图和逻辑视图之间可能存在一定的映射关系:比如逻辑层一般会映射到多个程序包等。

进程视图 (Process view):关注系统动态运行时,主要是进程以及相关的并发、同步、通信等问题。进程视图 和开发视图的关系:开发视图一般偏重程序包在编译时期的静态依赖关系,而这些程序运行起来之后会表现为对象、线程、进程,处理视图比较关注的正是这些运行时单元的交互问题,在UML中通常用活动图表述。

物理视图(Physical view ):通常也叫做部署视图(deployment view),是从系统工程师解读系统,关注软件的物流拓扑结,以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系:处理视图特别关注目标程序的动态执行情况,而物理视图重视目标程序的静态位置问题;物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。

逻辑视图和开发视图描述系统的静态结构,而进程视图和物理视图描述系统的动态结构。 

 

第二节 详细介绍各个部分如何应用及例子                                  

1 逻辑架构:
视 角:最终用户
关注点:功能性需求,即在为用户提供服务方面系统所应该提供的功能。
表示法:Booch标记法,UML(类图、交互图、顺序图、状态图),E-R图。
系统分解为一系列的关键抽象,表现为对象或对象类的形式。它们采用抽象、封装和继承的原理。
分解并不仅仅是为了功能分析,而且用来识别遍布系统各个部分的通用机制和设计元素。

                                             图2:逻辑架构的图例1 

2 处理架构
进程是构成可执行单元任务的分组。
视 角:系统集成者
关注点:非功能性需求,如并发性、分布性、系统完整性、容错性。
表示法:Booch标记法,UML(活动图、交互图、状态图)。
进程架构可以在多层次的抽象上进行描述,每个层次针对不同的问题。在最高的层次上,进程架构可以视为一组独立执行的通信程序的逻辑网络,它们分布在整个一组硬件资源上,这些资源通过LAN或者WAN连接起来。多个逻辑网络可能同时并存,共享相同的物理资源。

软件被划分为一系列单独的任务。任务是独立的控制线程,可以在处理节点上单独地被调度。
区别主要任务、次要任务。

                                             图3:逻辑架构的图例2

3 开发架构
视 角:程序员、软件项目经理
关注点:软件开发环境下实际模块的组织(受开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制)。
表示法:Booch标记法,UML(包图)。
产品线的基础。
软件打包成小的程序块(程序库或子系统),它们可以由一位或几位开发人员来开发。
子系统可以组织成分层结构,每个层为上一层提供良好定义的接口。

                                              图4:逻辑架构的图例3

4 物理架构
视 角:系统工程师
关注点:依赖于硬件的非功能性需求,如可用性、可靠性、性能吞吐量和可伸缩性等。
表示法:UML(部署图)。
分别用于开发和测试、部署的物理配置。
软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。

                                               图5:逻辑架构的图例4

5 场景
视 角:所有视图的用户、评估人
关注点:系统一致性、验收。
表示法:用例文本,UML(用例图)。
在某种意义上场景是最重要的需求抽象。
该视图是其他视图的冗余(因此“+1”)。
场景视图的两个作用:
作为一项驱动因素来发现架构设计过程中的架构元素。
作为架构设计结束后的一项验证和说明功能。

                                               图6:逻辑架构的图例5

 

参考:

https://blog.csdn.net/zhangjinyi/article/details/46010895RUP4+1架构方法(画图)

https://blog.csdn.net/apanious/article/details/51011946运用RUP 4+1视图方法进行软件架构设计(例子不错)

https://blog.csdn.net/ananhao/article/details/78938960软件体系结构4+1视图模型(非常好,详细)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值