4+1-视图模型概念

案例教学1：4+1视图方法进行软件体系结构设计要开发出用户满意的软件并不是件容易的事，软件体系结构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。

本文从理解需求种类的复杂性谈起，通过具体案例的分析，展示了如何通过RUP的4+1视图方法，针对不同需求进行体系结构设计，从而确保重要的需求一一被满足。

1、呼唤体系结构设计的多重视图方法灵感一闪，就想出了把大象放进冰箱的办法，这自然好。

但希望每个体系结构设计策略都依靠灵感是不现实的--我们需要系统方法的指导。

需要体系结构设计的多重视图方法，从根本上来说是因为需求种类的复杂性所致。

以工程领域的例子开道吧。

比如设计一座跨江大桥：我们会考虑"连接南北的公路交通"这个"功能需求"，从而初步设计出理想化的桥墩支撑的公路桥方案；然后还要考虑造桥要面临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及"大桥的使用期质量属性"，比如为了"能在湍急的江流中保持稳固"，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，"建造期间的质量属性"也很值得考虑，比如在大桥的设计过程中考虑"施工方便性"的一些措施。

和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所示。

图1 软件需求分类的复杂性2、超市系统案例：理解需求种类的复杂性例子是最好的老师。

为了更好地理解软件需求种类的复杂性，我们来分析一个实际的例子。

在表1中，我们列举了一个典型的超市系统的需求子集，从这个例子中可以清晰地看到需求可以分为两大类：功能需求和非功能需求。

表1 超市系统案例：理解需求种类的复杂性简单而言，功能需求就是"软件有什么用，软件需要做什么"。

基于UML4+1视图和概念模型的建模⽅法RUP的4+1视图包括： 逻辑视图：关注功能性的、整个系统的抽象结构，不涉及具体的编译即输出和部署。

开发视图：是逻辑视图的实现，描述程序⽣成多少个exe、dll、jar、配置⽂件等。

⼜叫实现视图。

运⾏视图：关注程序运⾏时各个⼦系统、组件之间的交互策略。

如多进程、多线程，⽣产者-消费者模式。

运⾏视图⼜称过程视图。

部署视图：关注软件交付以后在机器上的部署形态，以及和上下⽂的关系。

⼜称物理视图。

⽤例视图：关注需求，⼜叫场景视图。

RUP 4+1视图相对完整的描述了从需求分析到系统设计的过程，但没有专门针对数据持久层的描述。

温li在软件架构设计中⽤数据视图替换了⽤例视图，应该说他相对重视架构设计，对需求关注的少⼀些。

关于需求的描述⽅法，应当清醒的看到，仅仅通过⽤例视图是不够的，⽤例技术涉及、但⽆法全⾯涵盖⾮功能需求。

需求 = 功能 + 质量+ 约束。

⼤量的信息还是要通过详细的⽂字描述才能够讲清楚。

⽤例视图只不过提供了描述了⼀个软件的需求概貌。

除了⽤例视图以外，还应该关注软件的概念模型（⼜称领域模型、信息模型）。

如果说⽤例着重于描述⼀个个具体的需求，概念模型则从业务的⾓度描述了整个软件系统所要完成的功能中涉及的所有概念以及彼此之间的关系。

例如对于⼀个⽹管系统，核⼼的两个概念是设备和端⼝，端⼝从属于设备，他们之间是多对⼀的关系。

分别详述4+1视图：逻辑视图关注的静态元素是：层、⼦系统、类、接⼝，⽤类图来描述。

关注的动态因素是协作关系，⽤时序图、协作图、状态图等来描述。

是否需要在架构设计中体现类和类之间的关系？这取决于设计的层级。

开发视图关注的元素是程序包（SDK、解析器、中间件）、⽂件组织结构、编译依赖关系、⽬标单元（jar、exe、dll等）。

它和逻辑视图的静态元素通常有映射关系。

运⾏视图关注进程、线程、对象等运⾏时概念，以及相关的并发、同步、通信等问题。

运⾏架构和开发架构的关系：开发架构⼀般偏重程序包在编译时期的静态依赖关系，⽽这些程序运⾏起来之后会表现为对象、线程、进程，运⾏架构⽐较关注的是这些运⾏时单元的交互问题。

第七部分设备管理1.功能描述：设备管理功能主要包括设备信息的编辑（增加、删除、修改）。

1.1.设备信息包括设备的位置信息、名称、状态。

1.2.设备信息的编辑：支持对设备信息的编辑（增加、删除、修改）。

2.内容概述：运用4+1视图模型，从5种视图角度，进行分析设计。

2.1场景视图（Use case）使用user case图设计系统的各个场景。

2.2逻辑（功能）视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。

2.3开发（模块）视图（Development View），描述了在开发环境中软件的静态组织结构。

2.4物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。

2.5过程视图（Process View），捕捉设计的并发和同步特征。

4+1视图综述：3.设计详情：3.1场景视图(Scenarios)：参与者与用例构成场景视图，对设备的设置从修改，删除，增加三方面驱动。

如图1：图1在设计场景视图时，对包含（include）和扩展(extend)的应用需要仔细琢磨，刚开始并不知道每种的应用范围，看了网上的例子，和以前软件工程的书，大概了解包含的概念是一些必然发生的用例，然而扩展是在特殊情况的时候才可能发生的非正常情况。

我觉得一个小小的箭头也许在现在的项目作业中并不重要，但是在今后的学习工作中它会从某种程度上决定项目的成败，并体现出个人对工作和生活的认真态度，所以，大学课程的好处就是允许我们在实践和失败中汲取教训，总结经验。

在这部分，有同学提出了质疑，认为需要具体细分一下，如图2：图2在这里，也是得到其他同学的启发，场景视图必须要具体细分，它注重功能的概念，细分的过程可以放在逻辑视图中，通过函数来具体实现。

在这部分，我还需要更深入的了解，在实际应用过程中不断摸索。

3.2逻辑视图（Logic View）：逻辑试图主要是用来描述系统的功能需求，即系统提供给最终用户的服务。

“4+1”模型学生信息管理系统分析与设计“4+1”模型概述Kruchten在1995年提出了“4+1”的视图模型。

“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。

每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。

1，逻辑视图逻辑视图(logic view)主要支持系统的功能需求，即系统提供给最终用户的服务。

在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。

这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。

在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图(class diagram)来描述逻辑视图。

可以从Booch标记法中导出逻辑视图的标记法，只是从体系结构级的范畴来考虑这些符号，用Rational Rose 进行体系结构设计。

类图用于表示类的存在以及类与类之间的相互关系，是从系统构成的角度来描述正在开发的系统。

一个类的存在不是孤立的，类与类之间以不同的方式互相合作，共同完成某些系统功能。

关联关系表示两个类之间存在着某种语义上的联系，其真正含义要有附加在横线之上的一个短语来予以说明。

在表示包含关系的图符中，带有实心圆的一端表示整体，相反的一端表示部分。

在表示使用关系的图符中，带有空心圆的一端连请求服务的类，相反的一端连接提供服务的类。

在表示继承关系的图符中，箭头由子类指向基类。

逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问是要保持一个单一的、内聚的对象模型贯穿整个系统。

对于规模更大的系统来说，体系结构级中包含数十甚至数百个类。

2，开发视图开发视图(development view)也称模块视图(module view)，主要侧重于软件模块的组织和管理。

软件可以通过程序库或子系统进行组织，这样，对于一个软件系统，就可以由不同的人进行开发。

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大特点扑面而来。

特点一，倚重OO80年代到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视图用例视图:对系统功能性需求对模，描述系统的行为，揭示系统“是什么”逻辑视图:描述系统设计模型，包含与系统结构最重要意义的部分，比如，系统分解成为的子系统，子系统分解成多个类，以及这些元素的职责，关系，操作和属性进程视图：描述系统分解成线程及进程的过程，描述线程（进程）通讯模试等部署视图：描述运行系统的物理硬件（包含网络）配置，说明每个节点的计算机，CPU，操作系统以及它们互联的情况，还要包括进程到节点之间的映射关系。

实施视图：描述系统在构建时的分解后的子系统（包）的情况，特别是包括哪些组成部分由哪些团队开发，以及购入，外包，开发进度等内容。

项目经理应该对这个视图最感兴趣。

4+1视图方法进行软件架构设计作者：温昱来源：UML软件工程组织时间：2008年4月21日要开发出用户满意的软件并不是件容易的事，软件架构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。

本文从理解需求种类的复杂性谈起，通过具体案例的分析，展示了如何通过RUP的4+1视图方法，针对不同需求进行架构设计，从而确保重要的需求一一被满足。

呼唤架构设计的多重视图方法灵感一闪，就想出了把大象放进冰箱的办法，这自然好。

但希望每个架构设计策略都依靠灵感是不现实的--我们需要系统方法的指导。

需要架构设计的多重视图方法，从根本上来说是因为需求种类的复杂性所致。

以工程领域的例子开道吧。

比如设计一座跨江大桥：我们会考虑"连接南北的公路交通"这个"功能需求"，从而初步设计出理想化的桥墩支撑的公路桥方案；然后还要考虑造桥要面临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及"大桥的使用期质量属性"，比如为了"能在湍急的江流中保持稳固"，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，"建造期间的质量属性"也很值得考虑，比如在大桥的设计过程中考虑"施工方便性"的一些措施。

架构蓝图--软件架构"4+1" 视图模型级别：初级2005 年1 月01 日本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。

使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。

本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。

这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。

引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。

通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。

方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。

是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。

有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。

许多作者都提及了这个问题：Garlan & Shaw 1、CMU 的Abowd & Allen、SEI 的Clements。

作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。

架构模型软件架构用来处理软件高层次结构的设计和实施。

它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。

Perry 和Wolfe 使用一个精确的公式来表达，该公式由Boehm 做了进一步修改：软件架构＝{元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。