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

逻辑架构和物理架构在架构设计中的应用 ???2007-5-10 15:09:26???中程在线???浏览数： 252 关键字：逻辑架构和物理架构 　　在不同的架构设计方法中出现的软件架构视图种类很多，本文介绍最常用的两种架构视图——逻辑架构视图和物理架构视图，并通过具体案例的分析说明如何运用它们进行架构设计。 　　当观察和描述事物大局的时候，逻辑架构和物理架构是最常用的角度。比如，以我们办公室里的局域网为例：从物理角度看，所有计算机“毫无区别”地连接到路由器上；而从逻辑角度看呢，就发现这些计算机是有区别的——一台计算机充当文件服务器，而其它计算机是可以访问服务器的客户机。如图1所示。 ? 　　　　　　图1??? 区分物理视角与逻辑视角 　　同样，在软件架构设计过程中，也可以通过区分软件的逻辑架构和物理架构，分别从不同的角度设计和描述软件架构。 　　所谓软件架构视图，是指设计和看待整个软件系统的特定视角。每个软件架构视图关注系统架构的不同方面，针对不同的目标和用途。也就是说，架构要涵盖的内容和决策太多了，超过了人脑“一蹴而就”的能力范围，因此采用“分而治之”的办法从不同视角分别设计；同时，也为软件架构的理解、交流和归档提供了方便。 　　逻辑架构 　　软件的逻辑架构规定了软件系统由哪些逻辑元素组成、以及这些逻辑元素之间的关系。 　　软件的逻辑元素一般指某种级别的功能模块，大到我们熟悉的逻辑层（Layer），以及子系统、模块，小到一个个的类。至于具体要分解到何种大小的功能模块才可结束软件架构设计，并不存在一个“一刀切”的标准——只要足够明确简单，能够分头开发就可以了。于是，在实践中我们往往将关键机制相关的架构设计部分明确到类，而一般功能则到模块甚至子系统的接口定义即可。 　　值得说明的是，功能模块有时容易识别，有时却比较隐含。而比较全面地识别功能块、规划功能块的接口、明确功能块之间的使用关系和使用机制，正是软件逻辑架构设计的核心任务所在。对此，Ivar Jacobson曾有过极为形象的说法，“软件系统的架构涵盖了整个系统，尽管架构的有些部分可能只有‘一寸深’”。 　　图2展示了一个网络设备管理系统逻辑架构设计的一部分，我们借此来举例说明软件逻辑架构设计的3大核心任务：　　识别功能块　　规划功能块的接口　　明确功能块之间的使用关系和使用机制　　　　? 　　　　图2??? 软件逻辑架构设计的核心任务 　　软件的逻辑架构是架构设计思维的重要方法。在用例技术已经成为捕获功能需求的事实标准的今天，逻辑架构的设计往往是从用例分析开始的。基于用例的分析方法使逻辑架构的设计变得比较有序——通过对每个关键用例的分析，从逻辑上将用例实现为一组功能块的特定组合，最后综合这些用例分析成果，将一个个独立的协作归纳合并成整个软件系统的逻辑架构。而在用例分析方法产生之前，功能模块的确定多多少少带有些“硬”想出来的味道，特别是并不直接承载业务功能的模块有时比较容易遗漏，直到大规模编程实现阶段才发现。 　　物理架构 　　软件的物理架构规定了组成软件系统的物理元素、这些物理元素之间的关系、以及它们部署到硬件上的策略。 　　物理架构可以反映出软件系统动态运行时的组织情况。此时，上述物理架构定义中所提及的“物理元素”就是进程、线程、以及作为类的运行时实例的对象等，而进程调度、线程同步、进程或线程通信等则进一步反映物理架构的动态行为。 　　随着分布式系统的流行，“物理层（Tier）”的概念大家早已耳熟能详。物理层和分布有关，通过将一个整体的软件系统划分为不同的物理层，可以把它部署到分布在不同位置的多台计算机上，从而为远程访问和负载均衡等问题提供了手段。当然，物理层是大粒度的物理单元，它最终是由粒度更小的组件、模块、进程等单元组成的。 　　物理架构的应用很广泛。例如，架构设计中可能需要专门说明数据是如何产生、存储、共享和复制的，这时可以利于物理架构，展示软件系统在运行期间数据是由哪些运行时单元如何产生的，数据又如何被使用、如何被存储，哪些数据需要跨网络复制和共享等方面的设计决策。 　　由于人们对组成软件系统的“物理元素”存在不同看法（如图3所示），所以在实践中物理架构的用法比较宽泛，不同的人认为的物理架构也可能不尽相同。因此，我们在交流和实践的过程中，应注意区分物理架构所指为何。（也正是因为这个原因，实践中所采用的基于多视图的架构设计方法往往包含更多的视图，从而使每个架构视图的职责更加明确。） 　　? 　　　　　　　　　　　　　图3??? 对“物理元素”的不同看法 　　从逻辑架构和物理架构到设计实现 　　逻辑架构和物理架构是软件架构设计的重要方面。逻辑架构致力于将软件系统分解成不同的逻辑单元，并规定这些逻辑单元之间的交互接口和交互机制。物理架构则更重视软件系统运