|
从实现角度看，软件架构可以分为逻辑架构与物理架构两个紧密相关的视图。软件的逻辑架构规定了软件系统由哪些逻辑元素组成、以及这些逻辑元素之间的关系。软件的物理架构则关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。以一个网络管理系统(NMS)为例，在设计其架构时，我们通常会首先想到将NMS在逻辑上分为5个功能模块:故障管理、记账管理、配置与命名管理、性能管理、安全管理。然后，可能会考虑采用Manager-Agent管理模型，以SNMP作为基本的通讯协议，以运行在局端的数据库集中存储MIB。Agent会用C语言实现，Manager采用C或者C++、Java实现，数据库采用Oracle或者MySQL之类。应该说这样的考虑在技术上未必有什么大的漏洞，但从架构设计的角度来说，显得过于简单含混，没有包含逻辑架构与物理架构的必要元素。如果将这样的论述交给marketing对客户做宣传的话，也许是可以的，但还不足以在此基础上进行深一步的开发，这也就是所谓的“高来高去”的系统架构吧。 那么软件的系统架构设计应该达到怎样的深度？ 所谓架构，终究是技术的概念。对于成熟的客户而言，他们不会关心系统在技术上如何实现，而只注重系统能否满足他们的需求。架构本质上只是实现需求的一个台阶。这个台阶能否跨越过去呢？老一辈计算机专家认为“程序=算法+数据结构”，现代的专家们则认为只有算法和数据结构还不够，还需要设计方法、系统架构、设计模式、环境和工具等等。思维与系统于是同时变得复杂起来，而复杂性通常导致更多问题的出现。就系统架构而言，保持其简单性是至关重要的。 系统架构中包含了关于各元素应如何彼此相关的信息，架构必须省略各元素中与交互无关的某些信息。因此，架构首先是对系统的抽象，该抽象去除了不影响它们如何使用、其他元素如何使用以及如何与其他元素关联或交互的细节。在几乎所有的现代系统中，各元素都是通过接口实现交互的，而这些接口又将各元素的细节划分为公有和私有两大类。根据这种划分，架构属于公有部分，而私有部分——即仅与内部具体实现有关的细节——是不属于架构的。就此而言，架构设计存在于各级系统、子系统的开发过程，无论系统的粒度多小。 逻辑架构设计需要考虑职责划分，体现为层、子系统、模块等的划分决定。从软件开发生命周期看，软件架构设计属于design范畴，逻辑架构从静态视角为详细设计和编程实现提供切实的指导；有了分解就必然产生协作，逻辑架构还需要定义不同逻辑单元之间的交互接口和交互机制，而编程工作必须实现这些接口和机制。物理架构可以反映出软件系统动态运行时的组织情况，并以进程、线程、以及作为类的运行时实例的对象等方式体现出来，而进程调度、线程同步、进程或线程通信等则进一步反映物理架构的动态行为，数据的持久化、共享、传输则是反映了物理架构的运作状态。 由于用户需求是复杂多样的，软件架构也是一系列有层次性的决策是伴随着对软件系统的层层分解依次展开的。伴随着对软件系统的依次分解，软件架构师应当不断做出决策，例如需要划分成哪些模块、每个模块的职责为何、每个模块的接口如何定义、模块间采用何种交互机制、如何满足约束和质量属性需求、如何适应可能发生的变化等等。 之后，软件架构师必须规划整个系统的具体组成。通常，对于一个独立的软件系统而言，它常常被划分为不同的子系统或分系统，每个部分承担相对独立的功能，各部分之间通过特定的交互机制进行协作。软件架构师决策制定的顺序往往是先制定技术无关的决策、后制定技术相关的决策，后者在前者的指导下进行。 一项需求可能有多种方式实现，架构设计师必须与系统分析员确定该需求将采用何种方式实现，将达到何种效果，以消除将需求映射为设计的歧义；讨论过程中还可能会发现需求有不完备甚至错误的地方，在需求重新确定后设计者需修正设计。设计文档必须写清楚各个模块/接口/公共对象的定义，列明程序的各种执行条件与期望的运行效果，还要正确处理各种可能的异常。此外设计文档应该遵循一定的写作模式与版面风格，使用统一的术语或惯用语，使得开发团队成员很容易理解其内涵。当系统架构设计不可能穷尽每一个细节，只要分析与即将开发的模块相关的内容即可。一项设计任务可能需要多个程序员完成。比如用户界面一组程序员负责，而业务逻辑组件则由另一组负责，数据库部分则又由其他开发人员负责。架构设计师必须考虑他们的立场，以各方面都相对容易理解的方式写清楚主要的模块/接口/对象定义，明确相应的调用规则与主要逻辑处理。如果某项设计任务所涉及的内容太专业化，架构设计师并不熟悉相关的内容，他也可以用描述性的文字说明该部分的设计要求，并与其他成员协作补充。 软件架构设计是一个动态的过程，但无论怎样变化，需要时刻牢记架构设计的目标:
|
|
|
