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 做了进一步修改：软件架构＝{元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。

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

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

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

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

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

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

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

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

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

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

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

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

实验2用“4+1”视图描述体系结构
一、实验目的：
理解“4+1视图”建模思想，熟悉体系结构生命周期模型，掌握基于软件体系结构建模方法。

二、实验学时：2
三、实验内容及操作步骤：
（一）实验内容
根据“4+1”视图对KWIC（关键词索引系统）系统建模，完成KWIC系统的逻辑视图、过程视图、物理视图、开发视图和场景视图。

（二）操作步骤
基于“4+1”视图，对KWIC（关键词索引系统）系统进行视图建模：
1．建立KWIC的逻辑视图
采用面向对象的设计方法时，逻辑视图即是对象模型。

2．建立KWIC的过程视图
描述系统的并发和同步方面的设计。

3．建立KWIC的物理视图
描述软件到硬件之间的映射关系，反映系统在分布方面的设计。

4．建立KWIC的开发视图
描述软件在开发环境下的静态组织。

5．建立KWIC的场景视图描述软件体系结构的用例。

四、实验要求：
实验课前完成实验报告的实验目的、实验环境、实验内容、实验操作过程等内容；
实验课中独立/团队操作完成实验报告的实验操作、实验结果及结论等内容；每人一台PC机，所需软件Win2003/XP、UML工具（EclipseUML/ Rose/Visio/StartUML/）、Eclipse/MyEclipse、JDK6.0等。

实验课后完成实验报告的心得体会内容，并及时提交实验报告。

五、实验报告要求：
1．独立完成。

2．按时保质保量提交电子版和纸质版作业。

3．纸质版以班为单位上交，由班长负责收发；电子版作业文档以班为单位打包交给班长。

基于SA基本特性与核心属性的UML4+1模型分析报告摘要：由于软件体系结构的描述方法多种多样．各种工具不仅涉及不同领域，而且描进方法不尽相同。

给系统选择一种合适工具描述体系站构带来了难度。

统一建模语言UML是一种被广泛采纳的可视化建模语言。

它将系统结构的共同特征用相关语义、符号、图形加以描述。

Kruchten 提出了一个"4+1"视图模型，从5个不同的视角包括包括逻辑试图、进程视图、部署视图、开发视图、用例视图来描述软件体系结构。

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

关键字：软件架构，UML，4+1模型，建模1、引言软件体系结构建模是工业化生产软件开发的基本工作。

复杂的系统难以被人们完全理解，通过建立良好的模型，帮助我们掌握复杂的体系结构也为开发成功的软件系统打下基础。

随着复杂系统的日益增加，好的建模技术也日益其重要性。

在UML统一建模语言出现以前．没有一种占统治地位的建模语言。

各种语言各有特色，用户必须选择几种类似的建模语言，以完成复杂的体系结构描述。

大部分建模语言都有一些主要的、共同的概念，而在描述和表达方面却又有所不同．缺乏一种强大的具有扩展能力的建模语言，给使用者带来许多麻烦，不利于软件的推广和重用。

”4+1’模型采用UML作为各视图的表达和解释环境，统一各部分的建模描述语言，有利于合作开发以及各层次、各环节开发人员之间的沟通，建立切合实际的模型，平衡软件质量与开发周期间的矛盾，加速软件开发和推广。

2、UML 4+1模型概述UML的“4+1视图”是指从某个角度观察系统构成的4+1个视图，每个视图都是系统描述的一个投影，说明了系统某个侧面的特征。

其包含如下的几个视图：（1）用例视图（场景视图）（2）逻辑视图（3）开发视图（4）进程视图（5）部署视图（物理视图）对体系结构进行的描述是围绕着以上4个视图展开的。

然后，通过选择出的一些用例对体系结构加以说明。

简述视图的概念视图的概念视图，就是在三维世界里，将立体表面向两个方向翻转180度，在投影面上得到的正投影图。

视图的作用主要有： 1）物体上任意两个面或者三个面的相对位置，均可以用两个互相垂直的投影面来确定。

2）确定物体的大小，长短和形状。

（ 1）几何意义：用来表示空间物体与投影面之间相对位置的图形。

（ 2）投影原理：假设投影面是平行光线组成的平面，由于光线遵守光的反射定律，那么，被投影的物体反射面与投影面的夹角等于光线与镜面的夹角。

投影面是一个与物体表面互相垂直的平面，这样，物体上所有表面相对于投影面都会有一个唯一的投影。

当然，每个人都知道物体上的每一个表面都能在投影面上得到唯一的一个正投影，但我们常常用正投影来描述物体的大小，例如，我们把铅垂线投影到水平面上，把它叫做“水平投影”，而把铅垂面投影到水平面上，我们称它为“正面投影”。

任何物体都可以通过两个互相垂直的投影面的组合而在投影面上得到视图。

投影面组合的原则是：要从投影面上获得的物体上的所有线、面、点，必须有两个互相垂直的投影面来确定。

这两个投影面必须分别是物体的水平面和正面。

因此，物体上的任何一个表面都能在投影面上得到惟一的一个正投影，即该投影面上只有一个视图。

（ 3）特殊物体的视图，往往不止一个，对于同一个物体来说，由于观察方向的不同，有时会出现不止一个视图。

例如，上下楼梯，对于从上层楼梯看下去的情况，我们把它的正投影叫做上视图；而从下层楼梯看上去的情况，我们称它的正投影为下视图。

从某一个观察方向来看，如果想看到另外一个方向的图形，则需把两个图形分别旋转90度或270度，把另一个视图投影到两个互相垂直的投影面上，使之成为互相垂直的正投影图。

（ 4）选择方法视图一般采用“一个面、一个线、两个基本点”的原则。

凡是符合这个条件的都可以看成是物体的视图。

例如，墙上的门，我们用一个面去表示它，用一根线表示门框，用两个基本点表示开关和插销。

因为门是凹进去的，所以我们用一个面表示凹口，再用一个线表示门边。

架构设计：4+1视图概念“4+1”视图，是指从5个不同视⾓来描述软件体系结构。

“4+1”分别指：1. 逻辑视图2. 过程视图3. 物理视图4. 开发视图5. 场景/⽤例视图逻辑架构的描述可以围绕前四个视图进⾏组织，然后结合⽤例或场景进⾏说明，形成第五个视图。

每个视图只关⼼系统的⼀个侧⾯，5个视图结合起来，才能反映系统的全部内容。

关于视图软件设计可以从不同的概念⾓度进⾏描述和记录，这些⾓度通常被称为视图。

“视图表⽰软件体系结构的⼀部分，它显⽰软件系统的特定属性”不同的视图涉及与软件相关的不同问题。

总之，软件设计是由设计过程产⽣的多⽅⾯的产物，通常由相对独⽴的正交视图组成，可以结合建筑视图理解。

逻辑视图当使⽤⾯向对象的设计⽅法时，逻辑视图对应设计的对象模型，常⽤描述⽅法有UML类图、E-R图。

逻辑架构主要⽀持功能需求，即系统应该为⽤户提供什么样的服务。

系统被分解成⼀组关键抽象，以对象或对象类的形式从问题中表述。

类的设计遵循抽象、封装和继承的原则，这种分解不仅是为了进⾏功能分析，也是为了理清系统各个部分的通⽤机制和设计元素。

过程视图过程架构关注设计的并发和同步⽅⾯，考虑了⼀些⾮功能性需求，⽐如性能和可⽤性。

过程视图可以在⼏个抽象层次上进⾏描述，每个抽象层次处理不同的关注点：在最⾼层次上关注进程，进程分布在由LAN或WAN连接的⼀组硬件资源上，作为⼀组独⽴执⾏的通信程序逻辑⽹络。

多个逻辑⽹络可以同时存在，共享相同的物理资源。

主要任务是通过⼀组定义良好的任务间通信机制进⾏通信：基于同步和异步消息的通信服务、远程过程调⽤、事件⼴播等。

次要任务是可以通过集合或共享内存进⾏通信，避免重⼤任务在同⼀过程或处理节点上进⾏配置假设。

物理视图物理视图描述软件到硬件的映射，主要反映在分布式⽅⾯。

物理架构主要考虑系统的⾮功能性需求，如可⽤性、可靠性（容错性）、性能（吞吐量）和可扩展性。

常见物理配置：测试为不同站点或不同客户部署系统开发视图开发视图描述软件在其开发环境中的静态组织。