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

4+1视图方法的3大特点——4+1视图剖析系列1995年，Philippe Kruchten在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注。 后来，Philippe Kruchten加入Rational，他的4+1视图方法演变为著名的、为许多架构师所熟知的“RUP 4+1视图方法”（如下图所示）。 概括而言： 逻辑视图（Logical View），设计的对象模型。 进程视图（Process View），捕捉设计的并发和同步特征。 部署视图（Deployment View），描述了软件到硬件的映射，反映了分布式特性。 实现视图（Implementation View），描述了在开发环境中软件的静态组织结构。 用例视图（Use-Case View），该视图是其他视图的冗余（因此＋1）。 其实，就算不专门对比业界不同的多视图方法（本系列文章后续将谈及“业界种类繁多的多视图方法”），有经验的软件从业者也会感觉到4+1视图方法的3大特点扑面而来。 特点一，倚重OO 80年代到90年代OO技术是大有作为，例如许多人都知道C++是1985年横空出世的。4+1视图方法根植于Philippe Kruchten的一线架构设计实践，所以4+1视图方法倚重OO并不令人奇怪。 另一方面，几个问题很有价值： 4+1视图方法，是OO方法的分支吗？ OO高手，就想当然的是架构师了吗？ 难道大量采用C语言编程的嵌入式领域不需要多视图？ …… 于是，在每个人的心里留下了一个大大的问号：OO方法 与 多视图的架构设计方法到底什么关系？ 特点二，倚重用例 耐人寻味的“+1”。 Philippe Kruchten 4+1视图最初的“+1”，指场景视图（如下图）。RUP 4+1视图的“+1”，指用例视图（参考上图）。 用例技术不会和场景技术划等号吧？ 4+1视图前后的“变迁”，为什么呢？（小沈阳味儿） “逻辑视图”也叫“逻辑架构视图”也简称“逻辑架构”，但“用例架构”怎么这么别扭呢？ 逻辑视图架构师负责设计，用例视图呢？ 颇有影响的“用例驱动架构设计”的说法，如何评价？ 一个个颇有价值的大问号不断出现，请朋友们先自己分析分析。分析时别忘了三把有用的钥匙： 需求 = 功能 + 质量 + 约束 用例是功能需求实际上的标准 用例涉及、但不涵盖非功能需求 特点三，倚重建模 建模，很有用的能力。 但是，建模在架构设计中，到底占什么地位？凡事都需建模？ 总结与展望 作为“4+1视图剖析系列”的开篇之作，本文提炼出4+1视图方法的3大特点。一则，对新手来说，便于建立总体印象，为理解后续内容做一下铺垫。二则，为后续的“剖析”埋下伏笔。 本质而言，先有实践，后有理论。再之后，就是“理论指导实践”、“实践促进理论”的绵绵无止的相互作用（多少有些类似“鸡和蛋”、“蛋和鸡”的绕绕关系）。 作为软件行业的从业者，若【不能从实践理解理论、不能将理论与实践融合】，会极大地限制个人发展。 《实践中的4+1视图方法》，上篇将较多关注“从实践理解理论”，下篇较多关注“将理论与实践融合”。 因为实践需要，所以多视图必要 架构设计就是对系统“切、切、切”，有人这么认为。 但是，和任何复杂的事物一样，随着了解慢慢加深，我们会发现一些比较深入的问题浮现出来。 我们虽已明了“架构设计应将系统切成不同部分”，但一旦开始深入实践，就会产生不少疑问： 从用户角度而言，组成系统的是各种功能的模块，这属于架构设计的范围吗？（属于） 对开发人员来说，他们认为系统是由不同的程序包组成的，架构设计师应不应该把这些统统丢给程序员决定呢？（不应该） 更进一步而言，运行时系统又是由进程、线程等组成的，这属不属于架构设计的范围呢？（当然属于） 同样，我们虽已明了“架构设计应规定系统各部分之间如何交互”，但一旦开始深入实践，又困惑于： 在用户看来，抽象的功能模块之间可以相互（直接或间接）调用功能服务，只有这样才能完成最终系统需要的业务功能，这是否属于架构设计的决策范围呢？（属于） 程序类组成程序包，程序包组成程序系统，这些程序代码之间的调用等交互关系既有局部于包内的，也有跨包进行的，那么哪些属于架构师应该考虑的呢？（一般而言，某种级别的程序包之间的交互属于架构设计范围，这通常会采用定义接口的方式进行。不过，对于习惯把“接口属于客户”原则贯彻到代码结构设计中去的架构师而言，以及在进行框架开发的情况下，有可能出现接口定义在特定包比较密集的情况。） 架构可以不关心进程或线程间的通讯和并发等问题吗？毕竟软件系统的性能和可伸缩性等问题于此息息相关啊。（应关心） 由此看来，由于软件架构概念是高度抽象的，所以在软件架构概念与实践之间，似乎存在某种“鸿沟”—