翻译：架构蓝图—软件架构的4+1视图模型（中英文对照） - 知乎
英文原文链接：http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf
原文发表于1995年的《IEEE Software》
翻译 by 大白白
本人水平有限，有些地方实在无法确定原文的意思，只能勉强按字面意思翻译。为了避免误导，所以把原文和译文对照着放在一起以便对照理解。
Architectural Blueprints -- The "4+1" View Model of Software Architecture
Philippe Kruchten
Rational Software
Abstract
摘要
This article presents a model for describing the architecture of software-intensive system, based on the use of multiple, concurrent views. This use of multiple views allows to address separately the concerns of the various 'stakeholders' of the architecture: end-user, developers, systems engineers, project managers, etc., and to handle separately the functional and non functional requirements. Each of the five views is described, together with a notation to capture it. The views are designed using an architecture-centered, scenario-driven, iterative development process.
本文提出了一种模型，该模型使用多个、并行的视图来描述软件密集型系统的架构。多个视图分别解决不同利益相关人关注的问题：最终用户、开发人员、系统工程师、项目经理、等等，并分别处理功能和非功能需求。五个视图被逐一描述，并同时描述了用于记录视图的表示法。使用以架构为中心、场景驱动、迭代开发流程来设计这些视图。
Keywords: software architecture, view, object-oriented design, software development process
关键词：软件架构、视图、面向对象设计、软件开发流程
Introduction
介绍
We all have seen many books and articles in which a single diagram attempts to capture the gist of a system architecture. But looking carefully at the set of boxes and arrows shown on these diagrams, it becomes clear that their authors have struggled hard to represent more on one blueprint than it can actually express. Are the boxes representing running programs? Or chunks of source code? Or physical computers? Or merely logical groupings of functionality? Are the arrows representing compilation dependencies? Or control flows? Or dataflows? Usually it is a bit of everything. Does an architecture need a single architectural style? Sometimes the architecture of the software suffers scars from a system design that went too far into prematurely partitioning the software, or from an over-emphasis on one aspect of software development: data engineering, or run-time efficiency, or development strategy and team organization. Often also the architecture does not address the concerns of all its "customers" (or "stakeholders" as they are called at USC). This problem has been noted by several authors: Garlan & Shaw1, Abowd & Allen at CMU, Clements at the SEI. As a remedy, we propose to organize the description of a software architecture using several concurrent views, each one addressing one specific set of concerns.
我们都看过很多企图用单个图来表述系统架构设计要点的书籍和文章。但是，当你仔细查看图中的方框和箭头时，你就会发现，作者挣扎着想表达的内容明显比实际图上能表达出来的要多。方框表达的是正在运行的程序吗？或是源代码块吗？或是物理计算机吗？或是功能的逻辑分组？箭头表达的是编译依赖关系吗？或是控制流吗？或是数据流吗？通常是什么都用同样的符号在表达。架构需要的是单一的风格吗？有时软件架构会受到系统设计者过设计的负面影响，这些过设计包括：过早的划分软件，或者过分强调开发的某个方面（像数据工程、或者运行时的效率、或者开发策略和团队组织）。通常软件架构没有考虑到所有“客户”的关注点（在 USC 中，此处的“客户”被称为“利益相关人”）。这个问题已经被一些作者提及，他们是：Garlan & Shaw1、CMU的Abowd & Allen、SEI的Clements。我们建议的解决方法是使用多个并行的_视图_来组织软件架构的描述，每个视图解决一组特定的问题。
An Architectural Model
架构模型
Software architecture deals with the design and implementation of the high-level structure of the software. It is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy the major functionality and performance requirements of the system, as well as some other, non-functional requirements such as reliability, scalability, portability, and availability. Perry and Wolfe put it very nicely in this formula2, modified by Boehm:
_Software architecture _= {Elements, Forms, Rationale/Constraints}
软件架构用来处理软件高层次结构的设计和实现。它以精心选择的形式来组合若干架构元素，从而满足系统主要的功能和性能需求，以及其他非功能需求，比如可靠性、可扩展性、可移植性和可用性。Perry 和 Wolfe 运用一个公式对此进行了很恰当地表达，Boehn又对公式进行了优化。该公式如下：
软件架构 = {元素、形式、逻辑依据/约束}
Software architecture deals with abstraction, with decomposition and composition, with style and esthetics. To describe a software architecture, we use a model composed of multiple views or perspectives. In order to eventually address large and challenging architectures, the model we propose is made up of five main views (cf. fig. 1):
软件架构处理抽象，处理分解与组合，处理风格和美学。我们使用一种多个_视图_或视角的模型来描述软件架构。为了最终解决大型的、具有挑战性的架构，我们提出的模型由5个主要的视图组成（参见图1）：
- The logical view, which is object model of design (when an object-oriented design method is used),
- 逻辑视图，描述设计的对象模型（当使用面向对象设计方法时），
- The process view, which captures the concurrency and synchronization aspects of design.
- _过程_视图，捕捉设计的并发和同步特性。
- The physical view, which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect.
- _物理_视图，描述软件部署到硬件的映射关系，同时反应了分布式部署的情况。
- The development view, which describes the static organization of the software in its development environment.
- _开发_视图，描述软件在其开发环境中的静态组织结构。
The description of an architecture -- the decisions made -- can be organized around these four views, and then illustrated by a few selected use cases, or scenarios which become a fifth view. The architecture is in fact partially evolved from these scenarios as we will see later.
架构的描述，即已做出的架构决策，可以围绕这四个视图来组织，然后用一些选定的_用例_或_场景_来证实，这些用例或场景构成了第五个视图。正如我们后面将看到的，实际上该架构是从这些场景中部分演化而来的。
Figure 1 -- The "4+1" view model 图1 “4+1”视图模型
We apply Perry & Wolf's equation independently on each view, i.e., for each view we define the set of elements to use (components, containers, and connectors), we capture the forms and patterns that work, and we capture the rationale and constraints, connecting the architecture to some of the requirements.
我们把 Perry 和 Wolf 的公式独立地运用在每种视图上，即，我们为每种视图定义了一组要使用的元素（组件、容器、和连接器），我们捕捉有效的形式和模式，同时我们也捕捉逻辑依据和约束，将架构和某些需求联系起来。
Each view is described by a blueprint using its own particular notation. For each view also, the architects can pick a certain architectural style, hence allowing the coexistence of multiple styles in one system.
每种视图都用一个_蓝图_来描述，每个蓝图使用它自己特定的表示法。架构师也可以为每种视图选择某种架构风格，因此允许多种风格在一个系统中共存。
We will now look in turn at each of the five views, giving for each its purpose: which concerns is addresses, a notation for the corresponding architectural blueprint, the tools we have used to describe and manage it. Small examples are drawn from the design of a PABX, derived from our work at Alcatel Business System and an Air Traffic Control system3, but in very simplified form -- the intent here is just to give a flavor of the views and their notation and not to define the architecture of those systems.
我们将依次观察五个视图，并展示每个视图的目的，这些目的包括：每个视图要解决哪方面的问题、对应的架构蓝图的表示法是怎样的、哪些工具可以用来描述和管理对应的视图。以PABX设计作为小例子，PABX来源于我们在阿尔卡特商业系统（Alcatel Business System）和空中交通控制系统（Air Traffic Control system）3 的工作。
The "4+1" view model is rather "generic": other notations and tools can be used, other design methods can be used, especially for the and the logical and process decompositions, but we have indicated the ones we have used with succcess.
“4+1”视图非常的“通用”：可以使用其它的表示法和工具，可以使用其它设计方法，特别是在进行逻辑和过程分解的时候，但是我们给出的方法是我们已经成功使用过的。
The Logical Architecture
逻辑架构
The Object-Oriented Decomposition
面向对象的分解
The logical architecture primarily supports the functional requirements -- what the system should provide in terms of services to its users. The system is decomposed into a set of key abstractions, taken (mostly) from the problem domain, in the form of objects or object classes. They exploit the principles of abstraction, encapsulation, and inheritance. This decomposition is not only for the sake of functional analysis, but also serves to identify common mechanisms and design elements across the various parts of the system. We use the Rational/Booch approacch for representing the logical architecture, by means of class diagrams and class templates.4 A class diagram shows a set of classes and their logical relationships: association, usage, composition, inheritance, and so forth. Sets of related classes can be grouped into class categories. Class templates focus on each individual class; they emphasize the main class operations, and identify key object characteristics. If it is important to define the internal behavior of an object, this is done with state transition diagrams, or state charts. Common mechanisms or services are defined in class utilities.
逻辑视图主要用于功能需求 —— 系统应该向用户提供什么服务。系统被分解为一组主要来自问题领域的关键抽象，这些抽象的形式是_对象_或者_对象类别_。它们利用抽象、封装和继承的原则。这种分解不仅仅是为了功能分析，也是为了识别跨系统不同部件的通用机制和设计元素。我们使用 Rational/Booch 方法通过类图和模板来表示逻辑架构。类图展示了一组类和它们之间的逻辑关系：关联、使用、组合、继承、等等。一组相关的类可以被归入一个类组中。类模板聚焦于每个独立的类；它们强调主要的类操作，并识别关键的对象特征。如果定义对象的内部行为很重要，可以用状态转换图或状态图来完成。可以使用_类实用程序_来定义通用机制或服务。
Alternatively to an OO approach, an application that is very data-driven may use some other form of logical view, such as E-R diagrams.
除了OO方法，以数据驱动为主的应用程序可以使用其它形式的逻辑视图，如E-R图。
Notation for the logical view
逻辑视图的表示法
The notation for the logical view is derived from the Booch notation4. It is considerably simplified to take into account only the items that are architecturally significant. In particular, the numerous adornments are not very useful at this level of design. We use Rational Rose® to support the logical architecture design.
逻辑视图的表示法是从 Booch 表示法4衍生而来的。当只考虑在架构上有重大意义的条目时，这种表示法是非常简单的。特别是，在这个层次的设计上，大量的修饰并没什么作用。我们使用 Rational Rose（Rational Rose 是 Rational 公司出品的一种面向对象的统一建模语言的可视化建模工具）支撑逻辑架构的设计。
Figure 2 Notation for the logical blueprint 图2 逻辑蓝图的表示法
Style for the logical view
逻辑视图的风格
The style we use for the logical view is an object-oriented style. The main guideline for the design of the logical view is to try to keep a single, coherent object model across the whole system, to avoid premature specialization of classes and mechanisms per site or per proccessor.
对于逻辑视图，我们使用面向对象的风格。我们遵循的主要设计准则是在整个系统中尽量保持单一的、条理清晰的对象模型，避免过早地具体化每个站点和每个处理器的类和机制。
Example of Logical bluprints
逻辑蓝图的例子
Figure 3a shows the main classes involved in the Telic PABX architecture.
图3a 显示了 Telic PABX 架构涉及的主要类。
Figure3 a.Logical blueprint for the Telic PABX. b.Blueprint for an Air Traffic Control System 图3a.Telic PABX的逻辑蓝图，b.空中交通控制系统的蓝图
A PABX establishes communications between terminals. A terminal may be a telephone set, a trunk line (i.e., line to certral-office), a tie line (i.e., private PABX to PABX line), a feature phone line, a data line, an ISDN line, etc. Different lines are supported by different line interface cards. The responsibility of a line controller object to decode and inject all the signals on the line interface card, translating card-specific signals to and from a small, uniform set of events: start, stop, digit, etc. The controller also bears all the hard real-time constraints. This class has many subclasses to cater for different kinds of interfaces. The responsibility of the terminal object is to maintain the state of a terminal, and negotiate services on behalf of that line. For example, it uses the services of the numbering plan to interpret the dialing in the selection phase. The conversation represents a set of terminals engaged in a conversation. The conversation uses the translation service (directory, logical to physical address mapping, routes), and connection services to establish a voice path between the terminals.
PABX建立终端之间的通信。终端可能是电话、中继线(即：到中央办公室的线路)、连接线(即：专用的PABX到PABX的线路)、功能电话线路、数据线路、ISDN线路、等等。不同的线路接口卡支持不同的线路。线路的_控制器_（controller）对象的职责是将所有信号解码并注入到线路接口卡上，将特定于卡的信号转换成一组小的、统一的事件：开始、停止、数字等。控制器也承担了所有的硬实时约束。这个类有很多满足不同接口的子类。终端（terminal）对象的职责是维护终端的状态，并代表线路协商终端需提供的服务。例如：在选择阶段，终端使用_编号方案_（numbering plan）对象来解析拨号信息。会话（conversation）代表一组参与会话的终端。它使用_传输服务_（translation service）（访问目录、映射逻辑地址到到物理地址、路由）和_连接_（connection）服务建立多个终端之间的语音通路。
For a much bigger system, which contains a few dozen classes of architectural significance, figure 3b show the top level class diagram of an air traffic control system, containing 8 class categories(i.e., groups of classes).
对于一个更大的、包含几十个架构级重要类的系统，图3b显示了空中交通控制系统的顶级类图，它包含8个类别的类（即：8组类）。
The Process Architecture
过程架构
The Process Decomposition
进程分解
The process architecture takes into account some non-functional requirements, such as performance and availability. It addresses issues of concurrency and distribution, of system's integrity, of fault-tolerance, and how the main abstractions from the logical view fit within the process architecture -- on which thread of control is an operation for an object actually executed.
过程架构考虑一些非功能需求，比如性能和可用性。它解决并发性、分布式、系统完整性、容错问题，以及逻辑视图中的主要抽象如何对应到过程架构中，即：对象操作实际在哪个控制任务上执行。
The process architecture can be described at several levels of abstraction, each level addressing different concerns. At the highest level, the process architecture can be viewed as a set of independently executing logical networks of communicating programs (called "processes"), distributed across a set of hardware resources connected by a LAN or a WAN. Multiple logical networks may exist simultaneously, sharing the same physical resources. For example, independent logical networks may be used to support separation of the on-line operational system from the off-line system, as well as supporting the coexistence of simulation or test versions of the software.
过程架构可以在几个抽象层次上描述，每个层次解决一个不同的关注点。在最高层次上，处理架构可以被看做是一组独立执行的通信程序（被之称为“进程”）的逻辑_网络_，它们分布在一组硬件资源上，这组硬件资源通过本地网络或者广域网连接起来。多个逻辑网络可以同时存在，它们可以共享相同的物理资源。例如，独立的逻辑网络可以被用于支持分离连机和脱机操作系统，也可以被用于支持软件仿真和测试版本的共存。
A process is a group of tasks that form an executable unit. Processes represent the level at which the process architecture can be tactically controlled (i.e., started, recovered, reconfigured, and shut down). In addition, processes can be replicated for increased distribution of processing load, or for improved availability.
进程_是构成一个可执行单元的一组任务。进程表示过程架构可以被有策略地控制的层次（即：启动、恢复、重新配置、和关闭）。此外，可以通过复制进程来增加负载处理的分布性，或者提升可用性。
The software is partitioned into a set of independent tasks. A task is a separate thread of control, that can be scheduled individually on one processing node.
软件可以被划分成一组独立的_任务。 一个任务是一个单独的、可以在一个处理节点上被独立调用控制线程。
We can distinguish then: major tasks, are the architectural elements that can be uniquely addressed and minor task, that are additional tasks introduced locally for implementation reasons (cyclical activities, buffering, time-outs, etc.). They can be implemented as Ada tasks for example, or light-weight threads. Major tasks communicate via a set of well-defined inter-task communication mechanisms: synchronous and asynchronous message-based communication services, remote procedure calls, event broadcasts, etc. Minor tasks may communicate by rendezvous or shared memory. Major tasks should not make assumptions about their collocation in the same process or processing node.
然后，我们可以区分主要_任务_和次要_任务_。主要任务是可以被唯一指定的架构元素，而次要任务是因为某些实施原因（循环活动、缓冲、超时、等等）而在本地引入的额外的任务。它们可以被作为 Ada 任务或者轻量级线程来执行。主要任务通信是通过一组事先定义好的任务间通信机制：同步和异步的基于消息的通信服务、远程处理调用、事件广播、等等。次要任务通过集合和共享内存来通信。主要任务在同一流程和处理节点中的配置不应该被假设。
Flow of messages, process loads can be estimated based on the process blueprint. It is also possible to implement a "hollow" process architecture with dummy loads for the processes, and measure its performance on the target system, as described by Filarey et al. in their Eurocontrol experiment.
可以基于过程蓝图来评估消息流和过程负载。也可以像 Filarey 等人在他们的 Eurocontrol 实验中描述的那样，实现一个带有虚拟过程负载的“空的”过程架构，并在目标系统上测量其性能。
Notation for the Process view
过程视图的表示法
The notation we use for the process view is expanded from the notation originally proposed by Booch for Ada tasking. Again the notation used focuses on the elements that are architecturally significant. (Fig. 4)
我们使用的过程视图的表示法是从 Booch 为 Ada 任务提出的原始符号中扩展而来的。同样地，表示法聚焦于在架构上有重大意义的元素。（图4）
Figure 4 -- Notation for the Process blueprint 图4 过程蓝图的表示法
We have used the Universal Network Architecture Services (UNAS) product from TRW to architect and implement the set of processes and tasks (and their redundancies) into networks of processes. UNAS contains a tool -- the Software Architects Lifecycle Environment (SALE) -- which supports such a notation. SALE allows for the graphical depiction of the process architecture, including specifications of the possible inter-task communication paths, from which the corresponding Ada or C++ source code is automatically generated. The benefit of this approach to specifying and implementing the process architecture is that changes can be incorporated easily without much impact on the application software.
我们已经使用TRW的全球网络架构服务（Universal Network Architecture Services，缩写为UNAS）来构建一组进程和任务（以及它们的冗余）到进程网络中。UNAS包含一个工具--软件架构生命周期环境（Software Architects Lifecycle Environment，缩写为SALE），SALE 支持这种表示法。SALE 允许图形化地描绘过程架构，包括可能的任务间通信路径的规格说明。SALE能自动地生成相应的 Ada 和 C++ 源代码。这种指定和实施过程架构的方法的优点就是：可以在不太影响应用软件的情况下，较容易地合入变更。
Style for the process view
过程视图的风格
Several styles would fit the process view. For example, picking from Garlan and Shaw's taxonomy1 we can have: pipes and filters, or client/server, with variants of multiple client/single server and multiple clients/multiple servers. For more complex systems, one could use a style similar to the process groups approach of the ISIS system as described by K.Birman with another notation and toolset.
有多种风格都适合于过程视图。比如：使用 Garlan 和 Shaw 的分类法，我们可以得到：管道、过滤器、客户端/服务器、以及多客户端/单服务器和多客户端/多服务器的变体。对于更复杂的系统，可以使用类似 K.Birman 所描述的 ISIS 系统的进程组方法中的另一种表示法和工具集。
Example of a Process blueprint
过程蓝图的例子
Figure 5 -- Process blueprint for the Telic PABX (partial) 图5 Telic PABX 的过程蓝图（一部分）
All terminals are handled by a single terminal process, which is driven by messages in its input queues. The controller objects are executed on one of three tasks that composes the controller process: a low cycle rate task scans all inactive terminial (200 ms), puts any terminal becoming active in the scan list of the high cycle rate task (10 ms), which detects any significant change of state, and passes them to the main controller task which interprets the changes and communicates them by message to the corresponding terminial. Here message passing within the controller process is done via shared memory.
所有终端都被一个_终端进程_（terminal process）控制，这个终端进程受其输入队列中的消息驱动。控制器对象在组成控制器进程（controller process）的三个任务中的一个上执行，这三个任务分别是：一个是_低速循环任务_（low cycle rate task），它以200ms为周期扫描所有非活动状态的终端，并将其中变为活动状态的终端放入高速循环任务扫描的列表中；另一个就是_高速循环任务_（high cycle rate task），它以10ms为周期捕获终端的状态是否有显著的变化，一旦发现就将该终端传递给主控制器任务；最后一个就是_主控制器任务_（main controller task），它解析状态变化并通过消息和相应的终端通信。控制器进程中的消息传递是通过共享内存实现的。
The Development Architecture
开发架构
Subsystem decomposition
子系统分解
The development architecture focuses on the actual software module organization on the software development environment. The software is packaged in small chunks -- program libraries, or subsystems -- that can be developed by one or a small number of developers. The subsystems are organized in a hierarchy of layers, each layer providing a narrow and well-defined interface to the layers above it.
开发架构聚焦于软件模块在实际的开发环境中如何组织。软件被分割成程序库或者_子系统_这样的小块，使得程序库或者_子系统_可以分给一个或少数几个开发者来开发。子系统分_层_（layers）进行组织，每一层都为它的上层提供一个小范围的、定义好的接口。
The development architecture of the system is represented by module and subsystem diagrams, showing the 'export' and 'import' relationships. The complete development architecture can only be described when all the elements of the software have been identified. It is, however, possible to list the rules that govern the development architecture: partitioning, grouping, visibility.
系统的开发架构由表示系统‘导出’和‘导入’关系的模块和子系统图表示。只有当所有的软件元素都被确定好后，才能描述出完整的开发架构。当然，可以先列出影响开发架构的规则，比如：分区、分组、和可视化。
For the most part, the development architecture takes into account internal requirements related to the ease of development, software management, reuse or commonality, and to the constraints imposed by the toolset, or the programming language. The development view serves as the basis for requirement allocation, for allocation of work to teams (or even for team organization), for cost evaluation and planning, for monitoring the progress of the project, for reasoning about softare reuse, portability and security. It is the basis for establishing a line-of-product.
对于大多数情况，开发架构考虑了开发的简易性、软件管理、可复用性或通用性相关的内部需求，以及工具集或编程语言所带来的约束。开发视图是需求分配的基础，它可以支撑将工作分配到某个团队（甚至团队组织），也可以支撑成本评估、计划、项目进度监控，还可以支撑软件可复用性、可移植性、以及安全性分析。它是打造产品线的基础。
Notation for the Development Blueprint
开发蓝图的表示法
Again, a variation of the Booch notation, limiting it to the items that are architecturally significant.
我们又一次使用 Booch 表示法的变体，仅限于使用在架构上有重大意义的条目。
Figure 5 -- Notation for the Development blueprint 图5 开发蓝图的表示法
The Apex Development Environment from Ratinal supports the definition and the implementation of the development architcture, the layering strategy described above, and the enforcement of the design rules. Rational Rose can draw the development blueprints at the module and subsystem level, in forward engineering and by reverse engineering from the development sourcce code, for Ada and C++.
Rational 的 Apex 开发环境（Apex Development Enviroment）支持开发架构的定义和实现、支持上述分层策略、支持设计规则的实施。Rational Rose 可以为 Ada 和 C++ 绘制模块和子系统层次的开发蓝图，也可以通过逆向工程通过源代码反推开发蓝图。
Style for the Development View
开发视图的风格
We recommend adopting a layered style for the development view, defining some 4 to 6 layers of subsytems. Each layer has a well-defined responsibility. The design rule is that a subsystem in a certain can only depend on subsystem that are in the same layer or in layers below, in order to minimize the development of very complex networks of denpendencies between modules and allow simple release strategies layer by layer.
我们建议开发视图采用_分层的风格_，定义4到6层子系统。每层都有预先定义好的职责。设计规则是：子系统只能依赖与它相同层或更低层的子系统，目的是化了模块之间非常复杂的依赖网络的开发，且允许一种更简单、逐层发布的策略。
Figure 6 -- The 5 layers of Hughes Air Traffic System 图6 Hughes Air Traffic System的5层
Example of Development architecture
开发架构的例子
Figure 6 represents the development organization in five layers of a line-of-product of Air Traffic Control systems developed by Hughes Aircraft of Canada3. This is the development architecture corresponding to the logical architecture shown in fig.3b.
图6代表了加拿大 Hughes 飞机3（Hughes Aircraft of Canada）公司开发的空中交通控制系统（Air Traffic Control system，缩写为 ATC）产品线的5层开发组织。这个开发架构相应的逻辑架构如图3b所示。
Layer 1 and 2 constitute a domain-independent distributed infrastructure that is common across the line of products and shields it from variations in hardware platform, operating system, or off-the-shelf products such as database management system. To this infrastructure, layer 3 adds an ATC framework to form a domain-specific software architecture. Using this framework a palette of functionality is build in layer 4. Layer 5 is very constomer- and product-dependent, and contains most of the user-interface and interfaces with the external systems. Some 72 subsystems are spread across of the 5 layers, containing each from 10 to 50 modules, and can be represented on additional blueprints.
第1层和第2层构成了一个独立于领域的、分布式基础设施。这个基础设施是跨产品线通用的，并且可以保护应用程序免受硬件平台、操作系统、或者数据管理系统这样的现成产品变化的影响。在这个基础设施之上，第3层添加了一个 ATC 框架，从而形成了一个_特定领域的软件架构_。第4层在 ATC 框架上添加了一个选项功能。第5层强依赖于客户和产品，它包含了大部分用户接口和外部系统扩展接口。横跨这5层的是72个子系统，每个子系统包含10到50个模块。我们用另外的蓝图来表述这些子系统。
The Physical Architecture
物理架构
Mapping the software to the hardware
建立软件和硬件的映射关系
The physical architecture takes into account primarily the non-functional requirements of the system such as availability, reliability (fault-tolerance), performance (throughput), and scalability. The software executes on a network of computers, or processing nodes (or just nodes for short). The various elements identified -- networks, processes, tasks, and objects -- need to be mapped onto the various nodes. We expect that several different physical configurations will be used: some for development and testing, others for the deployment of the system for various sites or for different customers. The mapping of the software to the nodes therefore needs to be highly flexible and have a minimal impact on the source code itself.
物理架构考虑系统的非功能需求，比如：系统可用性、可靠性（容错）、性能、和可扩展性。软件在一个计算网络上或处理节点上（简称为节点）执行。各种已定义的元素（网络、进程、任务、对象）必须被映射到不同的节点上。我们希望使用几种不同的物理配置：一些用于开发和测试，另一些用于不站点或者不同客户的系统部署。因此，软件到节点的映射需要高度灵活，并且对源代码本身的影响最小。
Notation for the Physical Blueprint
物理蓝图的表示法
Physical blueprints can become very messy in large systems, so they take several forms, with or without the mapping from the process view.
大型系统的物理蓝图可能会变得非常凌乱，所以物理蓝图有一些不同的形式，包括：从或者不从过程视图映射而来的物理视图。
Figure 7 -- Notation for the Physical blueprint图7 物理蓝图的表示法
UNAS from TRW provide us here with data-driven means of mapping the process architecture onto the physical architecture allowing a large class of changes in the mapping without source code modifications.
TRW 的 UNAS 为我们提供了一种数据驱动的方法来将过程架构映射到物理架构上，这种方法允许在不修改源代码的情况下对映射做大量的改动。
Example of Physical blueprint
物理蓝图的例子
Figure 7 -- Notation for the Physical blueprint 图7 物理蓝图的表示法
Figure 8 shows one possible hardware configuration for a large PABX, whereas figures 9 and 10 show mappings of the process architecture on two different physical architectures, corresponding to a small and a large PABX. C, F and K are three types of computers of differents capacity, supporting three different executables.
图8展示了大型PABX的一种可能的硬件配置，图9和10是过程视图跟小型PABX和大型PABX两种不同的物理视图的映射关系。C、F、K 是三种不同能力的计算机，支持三种不同的可执行文件。
Figure 9 -- A small PABX physical architecture with process allocation 图9 带有进程分配的小型 PABX 的物理架构
Figure 9 -- A small PABX physical architecture with process allocation 图9 带有进程分配的小型 PABX 的物理架构
Scenarios
场景
Putting it all together
综合所有的视图
The elements in the four views are shown to work together seamlessly by the use of a small set of important scenarios -- instances of more general use case -- for which we describe the corresponding scripts (sequences of interactions betwenen objects, and between processes) as described by Rubin and Goldberg6. The scenarios are in some sense an abstraction of the most important requirements. Their design is expressed using object scenario diagrams and object interaction diagrams4.
四个视图中的元素通过一小组重要_场景_无缝地协同工作（场景_是更通用的_用例（use case）的实例）。如 Rubin 和 Goldberg6 所描述的那样，用对应的脚本来描述场景（脚本是指对象之间、进程之间的交互序列）。从某种意义上讲，场景是最重要的需求的抽象。我们用对象场景图或者对象交互图来描述场景的设计。
This view is redundant with the other ones (hence the "+1"), but it serves two main purposes:
这个视图相对其它几个视图来说是冗余的（因此，作为“+1”的视图），但是它扮演了两个重要角色：
- as a driver to discover the architectural elements during the architecture design as we will describe later
- 驱动我们在架构设计中去发现架构元素，我们将在后面对此进行描述
- as a validation and illustration role after this architecture design is complete, both on paper and as the starting point for the tests of an architectural prototype.
- 当架构设计完成后，验证和证实已完成的架构设计，这既是一个纸面上的工作，也是架构原型测试的起点。
Notation for the Scenarios
场景的表示法
The notation is very similar to the Logical view for the components (cf. fig. 2), but uses the connectors of the Process view for interactions between object (cf. fig. 4). Note that object instances are denoted with solid lines. As for the logical blueprint, we capture and manage object scenario diagrams using Rational Rose.
场景的表示法和逻辑视图的表示法非常相似（参见图2），但是场景使用过程视图中的连接器来描述对象间的交互（参见图4）。请注意，对象实例用实线表示。至于逻辑蓝图，我们使用 Rational Rose 捕获和管理对象场景图。
Example of a Scenario
场景的例子
Fig.11 shows a fragment of a scenario for the small PABX. The corresponding script reads:
图11为小型PABX的一个场景片段。相应的脚本内容如下：
1.The controller of Joe's phone detects and validate the transition from on-hook to off-hook and sends a message to wake up the corresponding terminal object.
2.The terminal allocates some resources, and tells the controller to emit some dial-tone.
3.The controller receives digits and transmits them to the terminal.
4.The terminal uses the numbering plan to analyze the digit flow.
5.When a valid sequence of digits has been entered, the terminal opens a conversation.
1.控制器检测并验证到Joe的电话从挂机状态变为摘机状态，发送消息唤醒相应的终端对象。
2.终端分配资源，并告诉控制器发送拨号音。
3.控制器接收拨号数字，并将数字发送给终端。
4.终端根据编号方案分析数字流。
5.当输入了有效的数字序列后，终端打开一个会话。
Figure 11 -- Embryo of a scenario for a local call -- selection phase 图11 本地呼叫的一个场景雏形 -- 选择阶段
Correspondence Between the Views
视图之间的关联
The various views are not fully orthogonal or independent. Elements of one view are connceted to elements in other views, following certain design rules and heuristics.
各个视图之间不是完全正交的，也不是完全独立的。一个视图中的元素可根据确定的设计规则和启发式与其它视图中的元素相连。
From the logical to the process view
从逻辑视图到过程视图
We identify several important characteristics of the classes of the logical architecture:
我们为逻辑架构的类定义了一些重要特征：
- Autonomy: are the objects active, passive, protected?
-an active object takes the initiative of invoking other objects' operations or its own operations, and has full control over the invocation of its own operations by other objects
-a passive object never invokes spontaneously any operations and has no control over the invocation of its own operations by other objects
-a protected object never invokes spontaneously any operations but performs some arbitration on the invocation of its operations. - 自主性：对象是主动的、被动的，还是受保护的？
-_主动_对象可以主动调用其它对象的操作，也可以主动调用该对象自己的操作，而且它对其它对象调用它的操作有完全的控制权
-_被动_对象不能自主地调用任何操作，而且它对其它对象调用它的操作没有控制权
-_受保护_对象不能自主地调用任何操作，但它可以对其它对象调用它的操作做仲裁 - Persistence: are the object transient, permanent? Do they the failure of a process or processor?
- 持久性：对象是短暂存在的，还是持久存在的？它们处理进程或处理器的故障吗？
- Subordination: are the existence or persistence of an object depending on anoter object?
- 从属关系：对象的存在或者持久性是否依赖另一个对象？
- Distribution: are the state or the operations of an object accessible from many nodes in the physical architecture, from several processes in the process architecture?
- 分布性：对象的状态或操作是否可以从物理架构上的很多节点去访问？是否可以从过程架构中的不同进程去访问？
In the logical view of the architecture we consider each object as active, and potentially "concurrent," i.e., behaving "in parallel" with other objects, and we pay no more attention to the exact degree of concurrency we need to achieve this effect. Hence the logical architecture takes into account only the functional aspect of the requirements.
在架构的逻辑视图中，我们认为每个对象都是主动的，而且是可能“并发的”，比如：与其它对象的行为是“并行”，但我们并不关心实现这种效果所需的准确的并发程度。因此逻辑架构考虑的仅仅是功能方面的需求。
However when we come to defining the process architecture, implementing each object with its own thread of control (e.g., its own Unix process or Ada task) is not quite practical in the current state of technology, because of the huge overhead this imposes. Moreover, if objects are concurrent, there must be some form of arbitration for invoking their operations.
然而，当我们定义过程架构时，凭当前技术难以实现每个对象都用自己的线程（比如：它自己的Unix进程或者Ada任务）来控制，因为这会带来巨大的开销。此外，如果对象是并发的，那么必须有某种形式的仲裁来调用它们的操作。
On another hand, multiple threads of control are needed for several reasons:
另一方面，需要多线程控制有几个原因： - To react rapidly to certain classes of external stimuli, including time-related events
- To take advantage of multiple CPUs in a node, or multiple nodes in a distributed system
- To increase the CPU utilization, by allocating the CPU to other activities while some thread of control is suspended waiting for some other activity to complete (e.g., access to some external device, or access to some other active object)
- To prioritize activities (and potentially improve responsiveness)
- To support system scalability (with additional processes sharing the load)
- To separate concerns between different areas of the software
- To achieve a higher system availability (with backup processes)
- 对某些类型的外部刺激作出快速响应，包括时间相关的事件
- 发挥一个节点中多CPU，或者一个分布式系统中多节点的优势
- 当一些控制线程因等待其它活动（比如：访问一些外设，或是访问其它某些主动对象）的完成而被挂起时，将CPU分别给其它活动，以此提高CPU使用率
- 对活动进行优先级排序（潜在地提升响应能力）
- 支持系统可扩展性（使用额外的进程分摊负载）
- 将不同的关注点划分到不同软件区域上
- 实现更高的系统可用性（使用备份进程）
We use concurrently two strategies to determine the 'right' amount of concurrency and define the set of processes that are needed. Keeping in mind the set of potential physical target architectures, we can proceed either:
我们同时使用两种策略来决定“正确的”并发数量，并定义所需的进程组。牢记可能的物理目标架构，我们可以继续处理： - Inside-out:
- 由内向外
Staring from the logical architecture: define agent tasks which multiplex a single thread of control across multiple active objects of a class; objects whose persistency or life is subordinate to an active object are also executed on that same agent; several classes that need to be executed in mutual exclusion, or that require only small amount of processing share a single agent. This clustering proceeds until we have reduced the processes to a reasonably small number that still allows distribution and use of the physical resources.
从逻辑架构开始：定义代理任务，该代理任务可以让一个类的多个活动对象复用单个控制线程；持久性和生命周期从属于其它主动对象的对象也在同一个代理上执行；需要互斥或者仅需要少量处理能力的类共享一个代理。这种集群一直进行下去，直到将进程降低到合理的数量。合理的数量是指可以继续分配和使用物理资源的数量。 - Outside-in:
- 由外向内
Starting with the physical architecture: identify external stimuli (requests) to the system, define client processes to handle the stimuli and servers processes that only provide services and do not initiate them; use the data integrity and serialization constraints of the problem to define the right set of servers, and allocate objects to the client and servers agents; identify which objects must be distributed.
从物理架构开始：识别系统的外部激励（响应），定义处理激励的客户端进程以及仅提供服务但不启动服务的服务端进程；使用问题的数据完整性和序列化约束来定义一组服务；并且为客户端和服务端代理分配对象；识别必须分配哪些对象。
The result is a mapping of classes (and their objects) onto a set of tasks and processes of the process architecture. Typically, there is an agent task for an active class, with some variations: several agents for a given class to increase throughput, or several classes mapped onto a single agent because their operations are infrequently invoked or to guarantee sequential execution.
其结果是将类（及其对象）映射到过程视图的一组任务和进程上。通常，一个主动类有一个“代理”任务，但有一些差异：有时一个类有多个代理以增加其吞吐量，有时多个类只有一个代理因为它们的操作调用频率较低或者它们必须按顺序执行的。
Note that this is not a linear, deterministic process leading to an optimal process architecture; its requires a few iterations to get an acceptable compromise. There are numerous other ways to proceed, as shown by Birman et al. or Witt et al. for example. The precise method used to construct the mapping is outside of the scope of this article, but we can illustrate it on a small example.
请注意：推导最佳过程架构不是一个线性的、确定性的流程；它需要多次迭代来获得一个可接受的“妥协”。还有很多其它的方法来推导，这些方法包括Birman等人提出的方法、Witt等人提出的方法。构造映射关系的详细方法超出了本文的范围，但是我们可以用一个小例子来说明。
Fig.12 shows how a small set of classes from some hypothetical air-traffic control system maybe mapped onto processes.
图12显示如何将一些假设的空中交通控制系统中的一小组类是映射到进程。
Figure 12: Mapping from Logical to Process view 图12 逻辑视图到过程视图的映射
The flight class is mapped onto a set of flight agents: there are many flights to process, a high rate of external stimuli, response time is critical, the load must be spread across multiple CPUs. Moreover the persistency and distribution aspects of the flight processing are deferred to a flight server, which is duplicated for availability reasons.
_flight_类被映射到一组_flight agents_上：因为需要处理的飞机很多，所以外部激励的频率很高，响应时间非常关键，因此必须把负载分配到多个CPU上。此外，飞机的持久性和分布式方面的处理被推到_flight server_上，还有可用性方面的处理也是一样的。
A flight profile or a clearance are always subordinate to a flight, and although there are complex classes, they share the processes of the flight class. Flights are distributed to several other processes, notably for to display and external interfaces.
飞机的_profile_或_clearance_总是从属于飞机，虽然它们是很复杂的类，但它们于飞机类共享处理进程。飞机被分配到很多不同的进程上，特别是为了显示和外部接口。
A sectorization class, which established a partitioning of airspace for the assignment of jurisdiction of controllers over flights, because of its integrity constraints, can be handled only by a single agent, but can share the server process with the flight: updates are infrequent.
_sectorization_类为飞机的管辖控制而建立了空域的划分，因为完整性约束，_sectorization_类只能被单个代理处理，但是因为它不需要频繁更新，所以可以与飞机共享服务进程。
Locations and airspace and other static aeronautical information are protected objects, shared among several classes, rarely updated; they are mapped on their own server, and distributed to other processes.
Locations_和_airspace 以及其它静态的航空信息是受保护对象，在几个类之间共享，很少更新；它们被映射到它们自己的服务上，并且被分配到其它进程。
From logical to development
从逻辑视图到开发视图
A class is usually implemented as a module, for example a type in the visible part of an Ada package. Large classes are decomposed into multiple packages. Collections of closely related classes -- class categories -- are grouped into subsystems. Additional constraints must be considered for the definition of subsystems, such as team organization, expected magnitude of code (typically 5K to 20K SLOC per subsystem), degree of expected reuse and commonality, and strict layering principles (visibility issues), release policy and configuration management. Therefore we usually end up with a view that does not have a one to one correspondence with the logic view.
一个类通常被实现为一个模块，比如 Ada _package_的可见部分的一个类型。大的类被分解为多个包。密切相关的类的集合（同一类别的类）被分组为子系统。对于子系统的定义，还需要考虑一些额外的约束，比如：团队组织、预期的代码规模（一个子系统的典型代码行数为5K到20K）、预期的可复用性和通用性的程度、以及严格的分层原则（可见性问题）、发布策略和配置管理。因此我们得到的结果常常与逻辑视图没有一一对应的关系。
The logical and development views are very close, but address very different concern. We have found that the larger the project, the greater the distance between these views. Similarly for the process and physical views: the larger the project, the greater the distance between the views. For example, if we compare fig.3b and fig.6, there is no one mapping of the class categories to the layers. If we take the 'External interfaces -- Gateway' category, its implementation is spread across several layers: communications protocols are in subsystems in or below layer 1, general gateway mechanisms are in subsytems in layer 2, and the actual specific gateways in layer 5 subsystems.
逻辑视图和开发视图是很相似的，但是它们解决的是完全不同的问题。我们发现项目规模越大，这两个视图的差距也就越大。过程视图和物理视图也是类似的：项目规模越大，这两个视图的差距也就越大。例如：如果我们比较图3b和图6，我们会发现并没有一个从类到层的映射关系。如果我们观察‘外部接口--Gateway’，我们会发现它的实现垮了好几层：通信协议在第1层或更低层的子系统中，通用的网关机制在第2层子系统中，而实际的特定的网关在第5层子系统中。
From process to physical
从过程视图到物理视图
Processes and process groups are mapped onto available physical hardware, in various configurations for testing or deployment. Birman describes some very elaborate schemes for this mapping in the Isis project.
根据测试或部署的各种配置，进程和进程组被映射到可用的物理硬件上。Birman 在 Isis 项目中描述了一些非常复杂的映射方案。
The scenarios relate mostly to the logical view, in terms of which classes are used, and to the process view when the interactions between objects involve more than one thread of control.
在哪些类被使用这一方面，场景视图与逻辑视图关联比较多。在对象间的交互涉及不止一个控制线程时，场景视图与过程视图的关联比较多。
Tailoring the Model
裁剪模型
Not all software architecture need the full "4+1" views. Views that are useless can be omitted from the architecture description, such as the physical view, if there is only one processor, and the process view if there is only process or program. For very small system, it is even possible that the logical view and the development view are so similar that they do not require separate descriptions. The scenarios are useful in all circumstances.
不是所有的软件架构都需要完整的“4+1”视图。架构描述时可以将没什么用的视图省略掉，比如：如果只有一个处理器而且只有一个进程或程序时，可以省略过程视图。对于非常小的系统，逻辑视图和开发视图可能几乎是一样的，那就没必要分开来描述。但场景视图在任何情况下都是有用的。
Iterative proccess
迭代过程
Witt et al. indicate 4 phases for the design or an architecture: sketching, organizing, specifying and optimizing, subdivided into some 12 steps. They indicate that some backtracking may be needed. We think that this approach is too "linear" for an ambitious and rather unprecedented project. Too little is known at the end of the 4 phases to validate the architecture. We advocate a more iterative development, were the architecture is actually prototyped, tested, measured, analyzed, and then refined in subsequent iterations. Besides allowing to mitigate the risks associated with the architecture, such an approach has other side benefits for the project: team building, training, acquaintance with the architecture, acquisition of tools, run-in of procedures and tools, etc. (We are speaking here of an evolutionary prototype, that slowly grows into becoming the system, and not of throw-away, exploratory prototypes.) This iterative approach also allows the requirements to be refined, matured, better understood.
Witt等人提出了架构设计的4个阶段：草图、组织、细化、优化，再细分为12个步骤。它们指出设计过程可能需要一些回溯机制。我们认为这种方法对于一个艰巨的，且没有先例的项目来说，太过于“线性”。在4个阶段结束时，我们仍然对如何证明架构的有效性知之甚少。我们更提倡迭代的开发，架构被原型化、测试、测量、分析，然后在下一个迭代中持续改进。除了可以减少架构相关的风险，这个方法对项目来说还有其它的优点：团队建设、培训、熟悉架构、获取工具、运行流程和工具，等等。（我们这里说是的是用于进化的原型，它慢慢地长成最终的系统，而不是会被抛弃的探索性原型。）这种迭代方法也使得需求可以被优化、逐步成熟，且更易于理解。
（译者备注：本段第一句，原文中 "the design or an architecture" 中的 or 疑为 of 的笔误，本译文按 of 翻译）
A scenario-driven approach
场景驱动的方法
The most critical functionality of the system is captured in the form of scenarios (or use cases). By critical we mean: functions that are the most important, the raison d'etre of the system, or that have the highest frequency of use, or that present some significant technical risk that must be mitigated.
系统最关键的功能是以场景（或者用例）的形式被捕获的。所谓的关键的功能是指：最重要的功能、作为系统存在理由的功能、或者使用频率最高的功能，或者存在必须被消减的重大技术风险的功能。
Start:
- A small number of the scenarios are chosen for an iteration based on risk and criticality. Scenarios may be synthesized to abstract a number of user requirements.
- A strawman architecture is put in place. The scenarios are then "scripted" in order to identify major abstraction (classes, mechanisms, processes, subsytems) as indicated by Rubin and Goldberg6 -- deccomposed in sequences of pairs (object, operation).
- The architectural elements discovered are laid out on the 4 blueprints: logical, process, development, and physical.
- This architecture is then implemented, tested, measured, and this analysis may detect some flaws or potential enhancement.
- Lessons learned are captured.
开始： - 根据风险和关键程度选择少量场景进行迭代。可以对场景进行综合，以抽象出一些用户需求。
- 架构草图已经到位。然后将这些场景脚本化，以定义 Rubin 和 Goldberg6所指出的主要抽象（类、机制、进程、子系统）-- 分解成对象以及对应操作的序列。
- 所发现的架构元素排列在逻辑、过程、开发和物理4个蓝图上。
- 实现、测试、测量这个架构，这个分析过程可能会发现一些错误或者潜在的改善。
- 吸取经验教训。
Loop:
The next iteration can then start by:
- reassessing the risks,
- extending the palette of scenarios to consider
- selecting a few additional scenarios that will allow risk mitigation or greater architecture coverage
Then:
- Try to script those scenarios in the preliminary architecture
- discover additional architectural elements, or sometimes significant architectural changes that need to occur to accommodate these scenarios
- update the 4 main blueprints: logical, process, development, physical
- revise the existing scenarios based on the changes
- upgrade the implementation (the architectural prototype) to support the new extended set of scenario.
- Test, Measure under load, in real target environment if possible.
- All five blueprints are then reviewed to detect potential for simplification, reuse, commonality.
- Design guidelines and rationale are updated.
- Capture the lessons learned.
End loop
循环
下一个迭代可以这样开始： - 再次评估风险
- 扩大要考虑的场景选项
- 选择一些额外的场景，以降低风险或者扩大架构覆盖范围
- 然后：
- 尝试在初步的架构中编写这些场景的脚本
- 发现额外的架构元素，或者有时需要进行重大的架构调整以适应这些场景
- 更新4个主要的蓝图：逻辑、过程、开发、物理
- 基于改变修订现有的场景
- 升级实现（架构原型）以支持新的扩展场景集
- 如果条件允许，在真实的目标环境下，进行带负载的测试、测量。
- 检视所有五个蓝图，以发现简化、提升可复用性、通用性的可能。
- 更新设计指南和逻辑依据。
- 吸取经验教训。
结束循环
The initial architectural prototype evolves to become the real system. Hopefully after 2 or 3 iterations, the architecture itself become stable: no new major abstractions are found, no new subsystems or processes, no new interfaces. The rest of the story is in the realm of software design, where, by the way, development may continue using very similar methods and process.
最初的体系结构原型逐渐发展成为真正的系统。希望在2到3次迭代之后，架构本身变得稳固：没有再发现新的主要抽象，没有新的子系统或者进程，没有新的接口。接下来的事情属于软件设计领域，顺便说一句，软件开发也可以使用相似的方法和过程。
The duration of these iterations varies considerably: with the size of the project to put in place, with the number of people involved and their familiarity with the domain and with the method, and with the degree of unprecedentedness of the system w.r.t this developement organization. Hence the duration of an iteration may be 2-3 weeks for a small project (e.g., 10 KSLOC), or up to 6-9 months for a large command and control system (e.g., 700 KSLOC).
不同项目迭代的周期差别很大：要实施的项目规模、涉及的人员数量、人员对领域和方法的熟悉程度、
因此，对于小型项目（比如：规模为10千行代码），迭代周期可能是2到3周，对于大型命令和控制系统（比如：规模为700千行代码），迭代周期最长可能是6到9个月。
Documenting the architecture
架构的文档化
The documentation produced during the architectural design is captured in two documents:
架构设计期间产生的资料包含在两个文档中：
- A Software Architecture Document, whose organization follows closely the "4+1" views (cf. fig. 13 for a typical outline)
软件架构文档，它的组织结构紧密遵循“4+1”视图（典型大纲参见图13） - A Software Design Guidelines, which captures (among other things) the most important design decisions that must be respected to maintain the architectural integrity of the system.
软件设计指南，它包含了(在其他事情中)最重要的设计决策，必须遵守这些决策来维护系统架构的完整性。
| Title Page
Change History
Table of Contents
List of Figures
- Scope
- References
- Software Architecture
- Architectural Goals & Constraints
- Logical Architecture
- Process Architecture
- Development Architecture
- Physical Architecture
- Scenarios
- Size and Performance
- Quality
Appendices
A. Acronyms and Abbreviations
B. Definitions
C. Design Principles |
| --- |
Figure 13 -- Outline of a Software Architecture Document
| 标题页
变更记录
目录
图表列表
- 范围
- 参考文献
- 软件架构
- 架构目标和约束
- 逻辑架构
- 过程架构
- 开发架构
- 物理架构
- 场景
- 规模和性能
- 质量
附录
A. 缩略语
B. 定义
C. 设计原则 |
| --- |
图13 软件架构文档大纲
Conclusion
结论
This "4+1" view model has been used with success on several large projects with or without some local customization and adjustment in terminology4. It acctually allowed the various stakeholders to find what they want to know about the software architecture. Systems engineers approach it from the Physical view, then the Process view. End-user, customers, data specialists from the Logical view. Project managers, software configuration staff see it from the Development view.
“4+1”视图模型已经成功使用在几个大型项目中，无论是否在术语4中有一些本地定制和调整。它的确能使不同利益相关者找到他们想了解的软件架构信息。系统工程师使用物理视图，再到过程视图。最终用户、客户、数据专家使用逻辑视图。项目经理、软件配置人员使用开发视图。
Other sets of views have been proposed and discussed, within Rational and elsewhere, for instance by Meszaros (BNR), Hofmeister, Nord and Soni (Siemens), Emery and Hilliard (Mitre)8, but we have found that often these other views proposed could usually be folded into one of the 4 we described. For example a Cost & Schedule view folds into the Development view, a Data view into the Logical view, an Execution view into a combination of the Process and Physical view.
在 Rational 和其它一些地方，比如：Meszaros (BNR)、Hofmeister、Nord and Soni (Siemens)、Emery 和 Hilliard (Mitre)8，有一些其它视图集已经被提出并经过讨论。但是，我们已经发现这些其它的视图集通常可以用我们所表述的4个视图中的一个来描述。比如：成本和计划视图可以用开发视图来描述，数据视图可以用逻辑视图来描述，执行视图可以用过程视图和物理视图共同描述。
| View | Logical | Process | Development | Physical | Scenarios |
|---|---|---|---|---|---|
| Components | Class | Task | Module, | ||
| Subsystem | Node | Step, | |||
| Scripts | |||||
| Connectors | association, | ||||
| inheritance, | |||||
| containment | Rendez-vous, | ||||
| Message, | |||||
| broadcast, | |||||
| RPC, etc. | compilation dependency, | ||||
| "with" clause, | |||||
| "include" | Communication medium, | ||||
| LAN, WAN, | |||||
| bus, etc. | |||||
| Containers | Class category | Process | Subsystem(library) | Physical subsystem | Web |
| Stakeholders | End-user | System designer, | |||
| integrator | Developer, | ||||
| manager | System designer | End-user, | |||
| developer | |||||
| Concerns | Functionality | Performance, | |||
| availability, | |||||
| S/W fault-tolerance, | |||||
| integrity | Organization, | ||||
| reuse, | |||||
| portability, | |||||
| line-of-product | Scalability, | ||||
| performance, | |||||
| availability | Understandability | ||||
| Tool Support | Rose | UNAS/SALE | |||
| DADS | Apex, SoDA | UNAS, | |||
| Openview DADS | Rose |
Table 1 -- Summary of the "4+1" view model
| 视图 | 逻辑 | 过程 | 开发 | 物理 | 场景 |
|---|---|---|---|---|---|
| 组件 | 类 | 任务 | 模块， | ||
| 子系统 | 节点 | 步骤， | |||
| 脚本 | |||||
| 连接器 | 关联， | ||||
| 继承， | |||||
| 包含 | Rendez-vous， | ||||
| 消息， | |||||
| 广播， | |||||
| RPC，等等 | 编译依赖, | ||||
| "with" 子句， | |||||
| "include" | 通信介质， | ||||
| 局域网，广域网， | |||||
| 总线，等等 | |||||
| 容器 | 类的类别 | 进程 | 子系统（库） | 物理子系统 | Web |
| 利益相关人 | 最终用户 | 系统设计人员， | |||
| 集成人员 | 开发人员， | ||||
| 项目经理 | 系统设计人员 | 最终用户 | |||
| 开发人员 | |||||
| 关注点 | 功能 | 性能， | |||
| 可用性， | |||||
| 软件容错， | |||||
| 完整性 | 组织， | ||||
| 可复用性， | |||||
| 可移植性， | |||||
| 产品线 | 可扩展性 | ||||
| 性能， | |||||
| 可用性 | 可理解性 | ||||
| 工具支持 | Rose | UNAS/SALE | |||
| DADS | Apex, SoDA | UNAS, | |||
| Openview DADS | Rose |
表1 “4+1”视图模式总结
（译者备注：不能理解为什么逻辑视图的利息相关人没有开发人员？但原文中确实没有）
Acknowledgments
致谢
The "4+1" view model owes its existence to many colleagues at Rational, at Hughes Aircraft of Canada, at Alcatel, and elsewhere. In particular I would like to thank for their contributions Ch. Thomopson, A. Bell, M. Devlin, G. Booch, W. Royce, J. Marasco, R. Reitman, V. Ohnjec, and E. Schonberg.
“4+1”视图模型的存在归功于 Rational、加拿大Hughes Aircraft公司、阿尔卡特和其它地方的很多同事。我要特别感谢以下同事的贡献 Ch. Thomopson、A. Bell、M. Devlin、G. Booch、W. Royce、J. Marasco、R. Reitman、V. Ohnjec 和 E. Schonberg。
References
参考文献
译者备注：
process view 翻译为 过程视图
process 翻译为 进程
reuse 翻译为 可复用性
concurrent view 翻译为 并行的视图
scalability 先是翻译为可伸缩性，经过斟酌修改为可扩展性
use case 先是翻译为用例，后改为用况，因为机械工业出版社2004年10月出版的《RUP导论（原书第三版）》中翻译为“用况”。但考虑到很多文献上都是用例，最后又改回到用例
notation 翻译为 表示法