类库、子系统、框架与架构

在软件架构中经常会出现类、模块、类库、子系统、框架等名词。在基于面向对象的开发语言工具中，都提供了非常丰富的类库；随着软件系统复杂性的增长，软件系统的规模也越来越大，不得不划分为多个子系统进行开发；当前，为了提高软件开发的起点，以加快开发速度，提高产品质量，基于框架进行开发已成为一种普遍现象和时髦，堪称一种文化，如Spring、Struts等。那么，类库、子系统、框架究竟与架构有什么关系与区别呢？

类库是类的集合，这些类之间既可能是相关的，也可能是相互独立的。应用开发者希望使用任何一个类时可以直接调用它而不必再写出一个。类库大部分是通过大量的软件系统实践沉淀积累起来的具有可重用意义的类，特别是现在的软件架构有意识的进行固化核心知识、提供可重用资产。

子系统是特殊的软件系统——只不过是生存在特定的上下文环境中，作为一个更大的软件系统中的一部分出现。在具体的架构实践中，一个软件系统往往首先分解为几个子系统，子系统又继续分解。软件系统需要架构设计，软件系统中包含的子系统也应在架构时规定是如何划分为多个部分的以及各部分之间的交互机制和交互接口，从而为软件开发提供足够的指导和限制；而如果软件系统中的子系统足够复杂的话，还应该单独独立出来进行架构设计，甚至同一软件系统中的多个复杂子系统独立出来采用不同的架构模式与框架进行软件架构。特别是现在的软件架构有意识的进行固化核心知识、提供可重用资产，会有相当多的子系统通用出来成为组件、服务甚或平台来提供重用。

框架是可以通过某种回调机制进行扩展的软件系统或子系统的半成品。它并不能提供完整无缺的解决方案，而是为构建解决方案提供良好的基础；框架中的服务可以被最终应用系统直接调用，而框架中的扩展点提供应用开发人员进行定制的可变化点，应用到软件系统时还必须根据具体需求进一步定制开发。框架技术和架构技术的出现，都是为了解决软件系统日益复杂所带来的困难而采取分而治之的思维结果——先大局后局部就是架构，先通用后专用就是框架。现在的软件开发越来越倚重框架的使用，因此选择何种框架、每个框架在整个架构中处于什么位置，都成为软件架构设计的重要环节。同时现在有意识的进行固化核心知识、提供可重用资产的软件架构会将某一领域(开发技术、业务领域、特定应用)经常会使用到的解决方案通用成框架以提供重用，另一方面，为了尽早验证架构设计或出于支持产品线开发的目的，将关键的通用机制甚至整个架构以框架的方式进行实现。

好的架构设计必须把变化点错落有致地封装到软件系统的不同部分，为些必须进行关注点分离。Ivar Jacobson在《AOSD中文版》中写道：好的架构必须使每个关注点相互分离，也就是说系统中的一部分发生了改变，不会影响其他部分；即使需要改变，也能够清晰地识别出哪些部分需要改变；如果需要扩展架构，影响将会最小化，已经可以工作的每个部分都将继续工作。可以通过以下三种方式进行关注点分离：

首先，可以通过职责划分来分离关注点。面向对象设计的关键所在，就是职责的识别和分配；每个功能的完成，都是通过一系列职责组成的协作链完成的，当不同职责被合理分离之后，为了实现新的功能只需要构造新的协作链，而需求的变更也往往只会影响到少数职责的定义和实现。架构模式和设计模式为特定上下文中重复出现的问题提供了通用的职责划分方案。

其次，可以利用软件系统各部分的通用性的不同进行关注点分离。不同的通用程度意味着变化的可能性不同，将通用性不同的部分分离有利于通用部分的重用和专用部分的修改。广为人知的框架技术和元模型驱动方法可以用于分离通用部分。

最后，可以根据不同粒度级别分离关注点。在实践中，软件架构工程师常常将软件系统划分为一组子系统，并先考虑大粒度的子系统、为子系统定义明确的接口，而子系统中是如何通过更小的粒度的模块和类组成等细节将被忽略并在随后的设计工作中慢慢展开。这样做可以避免一开始时工作陷入过多细节当中造成千头万系不知如何开展。