逻辑架构和物理架构在架构设计中的应用

当观察和描述事物大局的时候，逻辑架构和物理架构是最常用的角度。比如，以我们办公室里的局域网为例：从物理角度看，所有计算机“毫无区别”地连接到路由器上；而从逻辑角度看呢，就发现这些计算机是有区别的——一台计算机充当文件服务器，而其它计算机是可以访问服务器的客户机。如图1所示。


图1  区分物理视角与逻辑视角
[img][/img]
    同样，在软件架构设计过程中，也可以通过区分软件的逻辑架构和物理架构，分别从不同的角度设计和描述软件架构。

    所谓软件架构视图，是指设计和看待整个软件系统的特定视角。每个软件架构视图关注系统架构的不同方面，针对不同的目标和用途。也就是说，架构要涵盖的内容和决策太多了，超过了人脑“一蹴而就”的能力范围，因此采用“分而治之”的办法从不同视角分别设计；同时，也为软件架构的理解、交流和归档提供了方便。

    逻辑架构

    软件的逻辑架构规定了软件系统由哪些逻辑元素组成、以及这些逻辑元素之间的关系。

    软件的逻辑元素一般指某种级别的功能模块，大到我们熟悉的逻辑层（Layer），以及子系统、模块，小到一个个的类。至于具体要分解到何种大小的功能模块才可结束软件架构设计，并不存在一个“一刀切”的标准——只要足够明确简单，能够分头开发就可以了。于是，在实践中我们往往将关键机制相关的架构设计部分明确到类，而一般功能则到模块甚至子系统的接口定义即可。

    值得说明的是，功能模块有时容易识别，有时却比较隐含。而比较全面地识别功能块、规划功能块的接口、明确功能块之间的使用关系和使用机制，正是软件逻辑架构设计的核心任务所在。对此，Ivar Jacobson曾有过极为形象的说法，“软件系统的架构涵盖了整个系统，尽管架构的有些部分可能只有‘一寸深’”。

    图2展示了一个网络设备管理系统逻辑架构设计的一部分，我们借此来举例说明软件逻辑架构设计的3大核心任务：

    识别功能块

    规划功能块的接口

    明确功能块之间的使用关系和使用机制


    软件的逻辑架构是架构设计思维的重要方法。在用例技术已经成为捕获功能需求的事实标准的今天，逻辑架构的设计往往是从用例分析开始的。基于用例的分析方法使逻辑架构的设计变得比较有序——通过对每个关键用例的分析，从逻辑上将用例实现为一组功能块的特定组合，最后综合这些用例分析成果，将一个个独立的协作归纳合并成整个软件系统的逻辑架构。而在用例分析方法产生之前，功能模块的确定多多少少带有些“硬”想出来的味道，特别是并不直接承载业务功能的模块有时比较容易遗漏，直到大规模编程实现阶段才发现。

    物理架构

    软件的物理架构规定了组成软件系统的物理元素、这些物理元素之间的关系、以及它们部署到硬件上的策略。

    物理架构可以反映出软件系统动态运行时的组织情况。此时，上述物理架构定义中所提及的“物理元素”就是进程、线程、以及作为类的运行时实例的对象等，而进程调度、线程同步、进程或线程通信等则进一步反映物理架构的动态行为。

    随着分布式系统的流行，“物理层（Tier）”的概念大家早已耳熟能详。物理层和分布有关，通过将一个整体的软件系统划分为不同的物理层，可以把它部署到分布在不同位置的多台计算机上，从而为远程访问和负载均衡等问题提供了手段。当然，物理层是大粒度的物理单元，它最终是由粒度更小的组件、模块、进程等单元组成的。

    物理架构的应用很广泛。例如，架构设计中可能需要专门说明数据是如何产生、存储、共享和复制的，这时可以利于物理架构，展示软件系统在运行期间数据是由哪些运行时单元如何产生的，数据又如何被使用、如何被存储，哪些数据需要跨网络复制和共享等方面的设计决策。

    由于人们对组成软件系统的“物理元素”存在不同看法（如图3所示），所以在实践中物理架构的用法比较宽泛，不同的人认为的物理架构也可能不尽相同。因此，我们在交流和实践的过程中，应注意区分物理架构所指为何。（也正是因为这个原因，实践中所采用的基于多视图的架构设计方法往往包含更多的视图，从而使每个架构视图的职责更加明确。）



图3    对“物理元素”的不同看法
    从逻辑架构和物理架构到设计实现

    逻辑架构和物理架构是软件架构设计的重要方面。逻辑架构致力于将软件系统分解成不同的逻辑单元，并规定这些逻辑单元之间的交互接口和交互机制。物理架构则更重视软件系统运行时的动态结构，以及组成软件系统的目标程序如何部署到硬件上。

    在后续的详细设计和编程实现中，将贯彻和利用逻辑架构和物理架构设计中制定的架构决策，如图4所示。


图4    逻辑架构和物理架构对后续开发的作用

    逻辑架构中关于职责划分的决策，体现为层、子系统、模块等的划分决定，从静态视角为详细设计和编程实现提供切实的指导；有了分解就必然产生协作，逻辑架构还规定了不同逻辑单元之间的交互接口和交互机制，而编程工作必须实现这些接口和机制。 所谓交互机制，是指不同软件单元之间交互的手段。交互机制的例子有：方法调用、基于RMI的远程方法调用、发送消息等。

    至于物理架构，它关注的是软件系统在计算机中运行期间的情况。物理架构设计方案中规定了软件系统如何使用进程和线程完成期望的并发处理、进程线程这些主动对象（Active Object）会调用哪些被动对象（Passive Object）参与处理、交互机制（如消息）为何等等问题，从而为详细设计和编程实现提供了工作目标的动态视图。

    设备调试系统案例简介

    下面通过一个实际案例的分析，来帮助领会逻辑架构和物理架构这两种架构视图对架构设计的指导作用。

    该案例是某型号设备调试系统。设备调试员通过使用该系统，可以察看设备状态（设备的状态信息由专用的数据采集器实时采集）、发送调试命令。该系统的用例图如图5所示。


图5    设备调试系统的用例图

    逻辑架构设计

    首先根据功能需求进行初步设计，进行大粒度的职责划分。如图6所示。


图6    设备调试系统的逻辑架构

    之后，还有很多与逻辑架构设计相关的工作要做。例如，图7所示的CRC卡描述了上面的三层架构每一层的职责与协作者：

    应用层负责设备状态的显示，并提供模拟控制台供用户发送调试命令。

    应用层使用通讯层和设备控制层进行交互，但应用层不知道通讯的细节。

    通讯层负责在RS232协议之上实现一套专用的“应用协议”。

    当应用层发送来包含调试指令的协议包，由通讯层负责按RS232协议将之传递给设备控制层。

    当设备控制层发送来原始数据，由通讯层将之解释成应用协议包发送给应用层。

    设备控制层负责对调试设备的具体控制，以及高频度地从数据采集器读取设备状态数据。

    设备控制指令的物理规格被封装在设备控制层内部，读取数采器的具体细节也被封装在设备控制层内部。


图7    用CRC卡描述每层的职责和协作者

    物理架构设计

    软件最终要驻留、安装或部署到硬件才能运行。软件的物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。

    多个逻辑层（Layer）可以映射到一个物理层（Tier），这是很多从事分布式开发的读者都了解的。在进行设备调试系统的物理架构设计之时，也体现了这一点。如图8所示，设备调试系统共包含2个物理层：桌面部分和嵌入部分。作为逻辑层的应用层和通讯层最终将成为桌面部分，而设备控制层最终成为嵌入部分。


图8    逻辑层（Layer）到物理层（Tier）的映射

    物理层作为组成软件系统的物理单元，最终又要映射到具体的硬件，这也是物理架构设计要考虑的，对于分布式软件系统的设计而言尤其不可或缺。图9展示了这一点。可以看出，设备控制部分驻留在调试机中（调试机是专用单板机），而桌面部分以常见的“Windows可执行程序”的形式运用于PC机之上。


图9    设备调试系统架构的物理架构

    我们还可能根据具体情况的需要，通过物理架构视图更明确地表达具体目标模块及其通讯结构。

    总结

    从简单系统到复杂系统的变化，对架构设计的冲击决不仅仅是量变的问题。通过引入了软件架构视图的概念，有助于软件架构师控制架构设计的复杂性。

    软件架构视图的概念和软件架构基本概念是完全相容的，后者针对软件系统的整体目标，而前者针对特定目标子集，这样一来，重点突出了，问题明确了，软件架构师的经验也就活跃了起来。

    逻辑架构和物理架构相分离的设计方法在软件实践中比较常用。逻辑架构和物理架构是软件架构设计的重要方面。逻辑架构致力于将软件系统分解成不同的逻辑单元，并规定这些逻辑单元之间的交互接口和交互机制。物理架构则更重视软件系统运行时的动态结构，以及组成软件系统的目标程序如何部署到硬件上。