子系统、框架与架构

子系统和框架出现的动机：分离关注点，或者叫封装变化点。

如何分离关注点？

1.       可以通过职责划分来分离。

2.       可以利用软件系统各部分通用性的不同来划分。

3.       可以先考虑大粒度的子系统，而暂时忽略子系统是如何通过更小粒度的模块和类组成。

架构的分离：

1.       按照职责划分，可以分为表现层、业务层和数据层。

2.       按照通用性划分，可以分为特定应用部分、领域应用部分和技术通用部分。

3.       按照分解合成划分，可以分为子系统、模块和类。

子系统和软件架构的关系

意义：

1.       有助于避免软件架构设计不足和高来高去的问题。

2.       有助于充分利用架构设计技能。来组合各种常见的模式，提高软件质量。

软件单元不同粒度的划分

类：粒度最小的单元。

模块：几个类机密协作

子系统：完成相对独立功能的多个模块。

系统：多个子系统相互配合才能满足一个完整应用的需求。

集成系统：一个大型企业往往使用多套系统，多套系统通过交互形成集成系统。

什么是系统？

系统是指由多个元素组成的逻辑实体，它完成一组特定的目标或者担负一定的职责，系统可以包括软件，也可以包含硬件，或者两者都有。

子系统有时也是需要进行架构设计的。

同一个系统内，不同的子系统可以采用不同的架构设计。

所有的系统都有子系统，所有的系统都是更大系统中的子系统。

软件的粒度是相对的。由于实践中处在的位置不同，同一个软件单元在不同的实践者眼中的粒度可能是不一样的。

什么是框架？

框架是可以通过某种回调机制进行扩展的软件系统或子系统的半成品。

软件重用中存在的一个内在的矛盾：‘重用概率’大小和‘重用带来的价值’之间的矛盾。软件单元的粒度越大，则重用带来的价值就越大，但重用概率越小；反之，粒度小的软件单元被重用的概率越大，带来的价值越小。

框架与架构的区别：框架是软件，架构不是。

框架是一种特殊的软件，它并不能提供完整的解决方案，而是为你构建解决方案提供良好的基础。框架中的服务可以被最终应用系统直接使用，而框架中的扩展点是供开发人员定制的‘可变化点’。

软件架构不是软件，而是关于软件如何设计的重要决策。涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。

框架和架构的关系

1.       为了尽早验证架构设计，或者出于支持产品线开发的目的，可以将关键的通用机制甚至整个架构以框架的方式进行实现。

2.       业界可能存在大量可供重用的框架，这些框架或者已经实现了软件架构所需的重要架构机制，或者为未来系统的某个子系统提供了可扩展的半成品，所以最终的软件架构可以借助这些框架来扩展。

框架也有架构。相对来说。

真实的软件是由组件递归组合而成的

1.       组件的粒度可以很小，也可以很大；任何粒度的组件都可以组合成粒度更大的整体。即所谓的粒度多样性。

2.       组件粒度的界定，必须在具体的实践上下文中才有意义；你的大粒度组件，对我来说可能是原子组件，即所谓的粒度的相对性。

框架按照不同的分类标准可以分为不同的类型：

1．    应用框架、中间件框架、基础设施框架

2．    技术框架（水平框架）、业务框架（垂直框架）

3．    白盒框架、黑盒框架、灰盒框架

框架的开发过程：迭代开发方式

分析       查找目标，确定范围

设计       识别框架通用点和扩展点

构造       实现

稳定       测试、文档、培训

参考文献：

《软件架构设计》 温昱