软件测试再探结构化设计和面向对象设计方法

软件测试再探结构化设计和面向对象设计方法  软件测试工具

结构化设计历来备受责备的就是需求和设计之间的鸿沟，以前不是很理解这个鸿沟的原因。现在再看，在结构化设计中模块和模块之间的关系，被紧紧局限于信息流，这限制了对模块之间众多关系的表达，也无法体现模块和模块之间其他的众多关系，包含各种各样的结构、行为、依赖、包含（在结构化设计中这种关系隐含在分层中）、继承、关联关系等等。它仅仅解决了模块在封装和信息隐藏方面的问题。

　　再看面向对象设计方法，充分挖掘了“关系”的表达方式，可以尽可能的将事物之间复杂的关系予以体现，而这些关系是实现设计的关键。可以这样比喻目前为什么面向对象方法如此流行，记得小时候经常在各种杂志上看到许多这样的图画“一个钢球，从高处落下，击中某个翘起的装置，装置受到钢球的冲击，另一端抬起后，原来被截断的水流开始流通，并引发另一个设备开始工作……，最终在另一端的某个蜡烛被点燃”。这就是在工业时代，众多人被机械设计的灵巧和创意所深深吸引的其中一份图画。姑且不论这样的装置是否有实用价值，但它肯定带给构思者无限的快乐和想象力，以至于当时经常可以看到各种各样这样的图画。而面向对象的方法正是因使用对象的概念让设计更接近于上面的各种设备，而让机械设计时代的疯狂和无尽的创造力进入了软件工程师的视野。由于能够充分表达事物之间各种各样的关系（更接近于结构和行为方面），面对对象设计方法在今天创造了一个奇迹，各式各样巧妙的设计实现、设计模式的流行，几乎在永无止境的激发着爱好设计的人们的想象力和创造力。再看最流行的类比：建筑和软件。建筑最主要的特征是什么——结构。这也是为什么建筑能够和软件设计（最终设计都要体现在模块上）进行类比的潜在原因。相比之下，我更倾向于拿机械设计来和软件设计进行类比。

　　回到结构设计化方法上来，虽然很多人都说结构化设计和面向对象设计没有本质上的区别，那是因为某些关系依然可以通过转换映射到信息流上，但这毕竟绕了一个大弯，而且由于缺乏足够的表达各种关系的能力，极大的限制了软件设计者的想象力和创造力。结构化设计方法使用自顶向下的手段，通过Process的逐层分解来理解和构建系统，然后把Process分配给模块，这里的“分配”这几乎让每一个初次接触结构化设计方法的人大惑不解，似乎模块是Process分解的结果，甚至在如果已知了某些模块时又直接将模块映射成一个黑盒的Process，Process和模块究竟是什么关系？沿着这个思路，很容易陷进“鸡生蛋，蛋生鸡”的困境。而事实是，模块和Process的诞生，两者之间根本没有任何关联，都是独自根据经验所产生的。为什么会产生这样的问题？究其原因，结构化设计方法和我们自出生以来认识事物的方式有着很大的不同。因为打我们一出生，眼里落入的就是各式各样的实体，而我们区分它们主要依靠就是事物各式各样的特征，包括事物不同的结构和特定的行为，而结构化设计方法试图通过信息流及其转换来认识系统，这天生造成了某种障碍。相比之下，面向对象方法则和我们所熟悉的认识世界的方式相吻合，更加的自然。

　　那么结构化设计的优点到底是什么呢？考虑警察破案时，需要根据证人不断的描述犯罪嫌疑人特征对犯罪嫌疑人进行画像的场景，就可以理解结构化设计方法优点在于：当我们面对一个只知道存在各式各样需求，而对系统其它方面一无所知的时候，它可以通过“功能”帮助我们逐步理清需求之间复杂的关系，它天生就有对需求之间重复功能进行汇聚的能力，通过对系统的需求的整体理解，让我们知道系统到底需要做些什么，从而对系统有更清楚的认识，对“需求”的理解和澄清是结构化方法的核心。这样也可以理解为什么结构化设计方法比面向对象设计方法更早的诞生。因为在软件工业的早期，软件系统彼此独立，数量稀少，可以利用的经验非常缺乏，而结构化设计方法则在这种一开始就缺乏经验的时候有着极大的帮助，帮助人们从需求、功能的角度分析和理解系统。

　　那么，在我们理解结构化设计和面向对象设计的背后，到底隐藏了什么样的秘密，又如何理解其他各式各样的设计方法呢？其实，这个秘密躲藏在我们经常谈起的“差异性”的背后。我们经常谈起差异性，但却很容易忽视和差异性相伴相生的另一面——“共同性”。共同性促使我们对事物进行分类和总结，而差异性则让世界充满了变化，并让这个世界变得更加的复杂而朴素迷离。每一种“共同性”凝聚成一个轴，构成了我们观察世界的“维度”。各种“维度”交织在一起，让整个世界系统变成了一个复杂的“立方体”，这个立方体既不是平面的，也不是三维的，而是一个多维交织的复杂事物。结构化设计方法，抓住了“信息流”和“信息流转换”两个维度，并试图沿着这两个维度理解和认识系统；而面向对象设计方法则采用了“结构、行为”这两个主要的维度（还有其他），引领我们看清世界。每一种方法都试图通过某一个维度或者某几个维度的组合，去帮助我们认识和理解世界，比如面向方面的设计方法、面向服务的设计方法等等。这样再去理解表达方式，当某种表达方式能够表达的维度越多，它所能适应的范围就越广，这样也可以理解为什么目前很多的设计方法，都依靠的是UML，导致大家看不清其和面向对象方法存在的本质区别，也解释了为什么结构化设计方法的表达方式其实限制了我们的想象力和创造力。其实面向对象方法也有其局限性，简单的举例，比如模板编程就抓住了算法结构的纬度。

　　沿着维度的概念，我们也可以看清楚Java和C＃以及C++本身的区别，也可以想象如果Java始终局限于纯面向对象语言的偏执中，很有可能在通用语言的竞赛中落后。再看动态语言Python，抛弃“类型”的维度，只抓住“名字”的维度，带来的极大灵活性，它不需要判断对象的其他维度的特征，只需要有一个相同的名字，程序就可以执行，当然也带来了隐患，但如果认识不到这个维度的差别，很可能将会将这种语言特性，和面向对象语言中的“接口”（专注结构和行为）概念相混淆。其实，“共同性”所

原文转自：http://www.ltesting.net