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

　　　　　　图1 区分物理视角与逻辑视角

字串9

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

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

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

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

字串3

　　图2展示了一个网络设备管理系统逻辑架构设计的一部分，我们借此来举例说明软件逻辑架构设计的3大核心任务：
　　识别功能块
　　规划功能块的接口
　　明确功能块之间的使用关系和使用机制
　　　　
字串6

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

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

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

字串3

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

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

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

字串8

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

字串2

　　之后，还有很多与逻辑架构设计相关的工作要做。例如，图7所示的CRC卡描述了上面的三层架构每一层的职责与协作者：
　　应用层负责设备状态的显示，并提供模拟控制台供用户发送调试命令。
　　应用层使用通讯层和设备控制层进行交互，但应用层不知道通讯的细节。
　　通讯层负责在RS232协议之上实现一套专用的“应用协议”。
　　当应用层发送来包含调试指令的协议包，由通讯层负责按RS232协议将之传递给设备控制层。
　　当设备控制层发送来原始数据，由通讯层将之解释成应用协议包发送给应用层。
　　设备控制层负责对调试设备的具体控制，以及高频度地从数据采集器读取设备状态数据。
　　设备控制指令的物理规格被封装在设备控制层内部，读取数采器的具体细节也被封装在设备控制层内部。

字串5

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

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

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

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

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

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

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

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