软件设计-复杂问题解决方案的思考

     过去，曾学过系统工程的原理，对于复杂工程，都建议采用系统工程的方法。然而在现实世界中具体项目，我自己感觉这些原则远远不够 。不是原理不够，而是具体的方法和典型的案例缺乏，在系统的设计与实施方面大都走入前车之辙中。

     回想我做的许多工作或项目，都是吃力不讨好的活。也就是说项目完成了，但是整个项目组的成员，都几乎陷入苦战，最后得以完成。孙子兵法曰：“上兵伐谋，其次伐交，其次伐兵，其下攻城。” 我的70%的项目的完成，几乎都是在攻城!


    为什么？

    反思问题出在于没有正确理解和掌握软件设的核心的基本的原则-- 模块独立性。不论是结构化设计还是面向对象的设计，对于独立性的理解大部分时间只停留在字面上，可以说在实践中缺少这方面的意识，同时也少见这方面的典型的案例可供参考。大多项目的设计停止于可行方案之前，继而受到项目时限的压力，过早进入细节。设计方案缺少应有的适应性，导致过程中需要局部修改设计，甚至系统重构。问题一般出现在几个核心和模块，特别是界面与功能高度偶合的模块，最甚在于系统总成之时。

    一般来说，教科书给出独立性由耦合性与内聚性度量。耦合性包括非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合，但任何耦合都缺少定量指标; 同样，内聚也分巧合内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、信息内聚，所有内聚缺少量化度量指标。在工程中，即使我们知道存在某种耦合，因没有测度，无法评估设计优劣，导致设计停止在可行方案之前。

     比如，结构设计中，系统的结构，往往指的系统的模块图。在一个相同的数据流图的基础上可以导出多个可行系统结构，但几个结构评估其设计优劣是一件困难的事性。事实上主要评估指标[可维护性、可测性、灵活性]在设计时几乎没有考虑。可以说这样设计就不具备可维护性、可测性和灵活性，仅仅满足了软件的功能性。