面向积木（BO）的方法论与分形架构
面向对象的方法学所存在的问题

面向对象方法目前是软件工程学中的主流方法论之一，但在实际运用中，存在如下问题：
1）对象在描述业务模型时的能力欠缺；

业务模型往往重点关注（功能）边界、（与其他模型的）关系等，对象分析方法往往表述较泛，类似于UML与面向对象在描述问题时的差别一样，在描述业务模型这一更高的层次，对象的能力并不好，容易陷入细节，相对而言，用组件来表达业务模型会更理想，再打个比方，面向对象很多的时候是让你在DIY计算机的时候想的是电路板甚至是电子元件，但是组件却是CPU、内存、扩展卡这些偏重业务的概念。

2）对象分析方法没有站在不同尺度分析问题；

例如，一个员工管理系统，在确定了其构成的各个对象之后，如果把这个粒度级别称之为“功能”级别，那么在更大的“模块”级别或者“子系统”级别如何分析？你能够称一个“模块”也是一个对象吗？虽然直觉上两者没有本质的不同。作为这一点，您可能认为“对象组合不也是对象吗”，这一点确实如此，但是概念上出现了问题，其实我们需要的是“简单特定的语义、可递归”的模型，简单特定的语义模型使得方法论可解决某类特定而非全部的问题，可递归保证了模型可以跨越各个尺度统一分析；

3）对象分析的产出物在实现时与编程模型的差异；

“设计即实现”是业界一直所追求的建模目标，在分析文档中表现的类似于“节点互联”（或者形象的称之为搭积木）的风格往往在实现时荡然无存，最终 交付使用的软件内部的各个单元边界不清、关系混乱、紧紧的耦合在一起，所谓的“节点互联”只是形式或逻辑上的，例如，在分析文档中的一个“数据表格”对象 在实现是可能对应着一组JSP?Tag以及几个JavaBean，而且这些代码可能分散在项目的不同位置。

?

以“员工管理系统”为例，其“员工档案管理”的用例简述如下：

?

显然，该用例可以简单描述为“对员工资料”的CRUD（增删改查）操作，接下来分析构成该应用程序的各个组成部分，我们会需要：
1）数据表格（展现数据、查询、编辑数据）；
2）DAO—ata Access Object，作为存取数据的中间方）；
3）DataSource数据源（连接、存取数据库）；
另外，数据表格不能满足我们的要求，我们在保存数据同时会向另外一张表中存取数据。DAO在运行过程中会记录操作日志，而且日志的格式是可定制的。

?

?

?

?

积木块关系图

?

?

面向积木体系的视角下，上述应用程序在实现阶段为如下结构

?

?

面向积木方法在此解决了上面所提及的问题：
1）

?

系统建设成本正比于系统在某一尺度空间（例如，在功能级别）上的全部功能数= ∑ f(i)=∑ f(s(i)+r(i))
上式中，s(i)为节点i特定（独有）的功能数，r(i)为该节点在其他节点(m)中s(m)的子集。显然，一旦需求确定，i与f(s)为常量，系统建设成本正比于r(i)，即直观理解为系统建设成本正比于重复功能数。
在考虑如何降低成本，即考虑如何是的r(i)减小的视角下分析组成系统各个单元之间的关系，首先，功能需要与其他功能具备明确的边界，我们称该特性为“封装”；降低r(i)的 一个重要手段是提高复用性，复用中最重要的两种：重复应用与泛化，泛化的机制我们称之为“继承”；在继承的基础上的变化（覆盖或重载），我们称之为“多态”，到此为止，OO的理念 就确立了。
接下来思考更高（或更低）尺度（如模块级别）上系统的单元结构，你会发现如果使得r(i)趋于最小，上述的方法同样成立。
所以，得出当构成系统的组成单元在不同尺度空间中体现OO特性的前提下，系统建设成本是相对较低的，这种架构称之为分形架构。

事实上，分形架构（模式）体现在很多具体的实现中，例如，JavaBean就是其中的一种。

?

?

?

?

?