41视图方法的3大特点——41视图剖析系列

《41视图方法的3大特点——41视图剖析系列》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、4+1视图方法的3大特点——4+1视图剖析系列1995年，PhilippeKruchten在《IEEESoftware》上发表了题为《The4+1ViewModelofArchitecture》的论文，引起了业界的极大关注。后来，PhilippeKruchten加入Rational，他的4+1视图方法演变为著名的、为许多架构师所熟知的“RUP4+1视图方法”（如下图所示）。概括而言：·逻辑视图（LogicalView），设计的对象模型。·进程视图（ProcessView），捕捉设计的并发和同步特征。·部署视图（Deploym

2、entView），描述了软件到硬件的映射，反映了分布式特性。·实现视图（ImplementationView），描述了在开发环境中软件的静态组织结构。·用例视图（Use-CaseView），该视图是其他视图的冗余（因此"＋1"）。其实，就算不专门对比业界不同的多视图方法（本系列文章后续将谈及“业界种类繁多的多视图方法”），有经验的软件从业者也会感觉到4+1视图方法的3大特点扑面而来。特点一，倚重OO80年代到90年代OO技术是大有作为，例如许多人都知道C++是1985年横空出世的。4+1视图方法根植于PhilippeKruc

3、hten的一线架构设计实践，所以4+1视图方法倚重OO并不令人奇怪。另一方面，几个问题很有价值：·4+1视图方法，是OO方法的分支吗？·OO高手，就想当然的是架构师了吗？·难道大量采用C语言编程的嵌入式领域不需要多视图？·……于是，在每个人的心里留下了一个大大的问号：OO方法与多视图的架构设计方法到底什么关系？特点二，倚重用例耐人寻味的“+1”。PhilippeKruchten4+1视图最初的“+1”，指场景视图（如下图）。RUP4+1视图的“+1”，指用例视图（参考上图）。用例技术不会和场景技术划等号吧？4+1视图前后的“

4、变迁”，为什么呢？（小沈阳味儿）“逻辑视图”也叫“逻辑架构视图”也简称“逻辑架构”，但“用例架构”怎么这么别扭呢？逻辑视图架构师负责设计，用例视图呢？颇有影响的“用例驱动架构设计”的说法，如何评价？一个个颇有价值的大问号不断出现，请朋友们先自己分析分析。分析时别忘了三把有用的钥匙：·需求=功能+质量+约束·用例是功能需求实际上的标准·用例涉及、但不涵盖非功能需求特点三，倚重建模建模，很有用的能力。但是，建模在架构设计中，到底占什么地位？凡事都需建模？总结与展望作为“4+1视图剖析系列”的开篇之作，本文提炼出4+1视图方法的3

5、大特点。一则，对新手来说，便于建立总体印象，为理解后续内容做一下铺垫。二则，为后续的“剖析”埋下伏笔。本质而言，先有实践，后有理论。再之后，就是“理论指导实践”、“实践促进理论”的绵绵无止的相互作用（多少有些类似“鸡和蛋”、“蛋和鸡”的绕绕关系）。作为软件行业的从业者，若【不能从实践理解理论、不能将理论与实践融合】，会极大地限制个人发展。《实践中的4+1视图方法》，上篇将较多关注“从实践理解理论”，下篇较多关注“将理论与实践融合”。因为实践需要，所以多视图必要架构设计就是对系统“切、切、切”，有人这么认为。但是，和任何复杂的

6、事物一样，随着了解慢慢加深，我们会发现一些比较深入的问题浮现出来。我们虽已明了“架构设计应将系统切成不同部分”，但一旦开始深入实践，就会产生不少疑问：·从用户角度而言，组成系统的是各种功能的模块，这属于架构设计的范围吗？（属于）·对开发人员来说，他们认为系统是由不同的程序包组成的，架构设计师应不应该把这些统统丢给程序员决定呢？（不应该）·更进一步而言，运行时系统又是由进程、线程等组成的，这属不属于架构设计的范围呢？（当然属于）同样，我们虽已明了“架构设计应规定系统各部分之间如何交互”，但一旦开始深入实践，又困惑于：·在用户看

7、来，抽象的功能模块之间可以相互（直接或间接）调用功能服务，只有这样才能完成最终系统需要的业务功能，这是否属于架构设计的决策范围呢？（属于）·程序类组成程序包，程序包组成程序系统，这些程序代码之间的调用等交互关系既有局部于包内的，也有跨包进行的，那么哪些属于架构师应该考虑的呢？（一般而言，某种级别的程序包之间的交互属于架构设计范围，这通常会采用定义接口的方式进行。不过，对于习惯把“接口属于客户”原则贯彻到代码结构设计中去的架构师而言，以及在进行框架开发的情况下，有可能出现接口定义在特定包比较密集的情况。）·架构可以不关心进程或

8、线程间的通讯和并发等问题吗？毕竟软件系统的性能和可伸缩性等问题于此息息相关啊。（应关心）由此看来，由于软件架构概念是高度抽象的，所以在软件架构概念与实践之间，似乎存在某种“鸿沟”——即缺失某种概念，而这种概念可以连接软件架构的概念和实际的开发实践需要，为不同涉众理解和交流架构提供更专一的视