我眼中的面向对象方法和结构化方法

 我眼中的面向对象方法和结构化方法
　

---

我觉得无论结构化范型或面向对象的范型，都是应用到软件工程的每一个阶段。系统的分析、设计必然要为技术管理提供方便，而且从程序的设计方法不断演化（过程式程序设计-〉模块化的程序设计-〉面向对象程序设计）的过程来看，先进的分析和设计方法为技术管理提供更大的便利。我认为反之亦然。也就是说，我们在应用UML及其背后所体现的面向对象的分析建模与设计思想时，最好能有一个比较规范的软件工程环境，并把改进软件过程也看作一个目标，这样更能推动面向对象方法的应用。
之所以有此感受，是因为我以前在一家较小的软件公司工作，参与过一个数据库管理应用的开发。该公司的软件过程并不规范。UML的使用总局限于某些局部阶段。因为如果软件过程不规范，人们的思维容易从系统功能需求直接转向编码。对于使用JAVA这样的纯面向对象语言来说，此时使用UML作类设计是很有帮助的。而用例说明，构件图等对维护人员则很有帮助。
坦白的说，我觉得我以前的项目组在得到系统功能需求的过程中，很难说是使用结构化或面向对象的方法。如果说是结构化方法，有人会赞同；如果说是面向对象的方法，也不知道为什么不是。当时我和坐我隔壁的一个资格很老的系统分析员老宋都参与了系统功能说明和系统设计的工作。老宋一直就使用结构化分析的方法。而我在开始学习系统分析和设计的方法时，就选择的是OO方法，对结构化分析了解甚少。
但在得到系统功能需求过程的讨论中，我并没有感觉到分析方法的不同在实际工作结果中造成的区别。而且由于公司对系统功能需求等文档都有模版，我只能说我当时没有看出分析方法的不同在实际工作结果中造成的区别。关于结构化方法中的功能模块的划分和面向对象中用例的说明，我个人的感觉是区别不是很大。不论哪种方法，似乎都得先划分出几个大的模块，再划分小的模块。当然，有可能是我们开发的是一个中型的数据库管理应用的原因。
当时我们开发的是数据库管理应用，使用的是J2EE技术，所以在此后的系统设计的过程中，我先找对象，映射成数据库表，再确定对象的方法。老宋是先设计表，再规定模块间的接口。由于使用的技术的原因，老宋最后得到的结果和我的结果看起来都差不多。表设计、EJB接口定义、界面设计。
这些设计结果然后分配到具体的开发人员身上。由于使用的是JAVA,所以编程时都使用的是面向对象编程。整个过程中我很难找出结构化分析方法和面向对象方法的较大的区别。
我在读《软件工程JAVA语言实现》一书时，对于第6章的练习18分别使用结构化分析方法和面向对象方法进行分析，感觉两种方法着手点虽然不同，但结果都很类似。如果规定使用纯面向对象的语言的话，我觉得按这两种分析和设计方法最后得到的代码应该极为类似以至于难以看出系统分析的风格。结构化方法分析过程如下：
1、总结出系统应有的功能，对一个功能，从功能完成的过程考虑，将各个过程（或说小的功能（难以再分解））列出，标识出过程转向和传递的数据。这样，可以将所有的过程都画出来。
2、细化数据流。确定应该记录的数据。
3、分析各过程之间的耦合关系，合理地进行模块划分以提高它们之间的内聚性。实际上，对于这个练习，可以使模块具有信息内聚性。
而面向对象方法分析过程如下：
1、总结出系统应有的功能，从功能完成的过程考虑，描述每个功能的完成过程。对应UML的USECASE和SEQUENCE。
2、开始寻找定义对象，并归纳各对象应记录的属性，对象的状态及转换关系在这里定义。这一步的对象和第一步画SEQUENCE所带入的对象有联系但更重要的是区别。
3、从功能完成的过程考虑，区分所需要的各个功能。再根据定义出的对象，将功能分配到对象上。由于第一步的关系，在这个练习中，这一步相对简单。
4、根据前3步的结果，如果需要的话，应该重新画SEQUENCE。特别是希望UML图对编程能更有帮助时。由于我只做了系统分析，没有编程，所以这一步没有做。
对于自己做的这个练习，我想比较其中体现的两种方法的异同：
1、总结系统应具备的功能的时候，都是根据题目的描述，一条一条总结归纳得到的。对结构化方法，就是画数据流图。对面向对象方法，就是USECASE和SEQUENCE。实际上，在工作中使用时，一般还需要ACTIVITY图。
2、确定应该记录的数据。对结构化方法，就是细化数据流，并整理出一个一个的表。对面向对象方法，就是寻找和定义对象，并归纳各对象应记录的属性。一般O-R关系转换都是套用流行的方法，可能有些组织对此都有规定。
3、模块的组织。如果实在是要避免歧义的话，应该说成是“将数据和功能分配到不同的文件中，用文件来合理地组织代码”。对结构化方法，就是划分模块，每个模块应该包含哪些文件以及每个文件的内容。对面向对象方法，就是在已有对象的基础上，将功能分配到对象上。相比较结构化方法，面向对象在这里强制要求：将数据和功能分配到不同的文件中时，是以数据为中心。事实上，使用结构化方法划分模块时，如果希望模块具有信息内聚性，那么，也是以数据为中心。“有信息内聚性的模块，本质上是抽象数据类型的实现”[P89,《软件工程JAVA语言实现》]。
4、接下来就应该是编程了。如果都使用JAVA的话，我很难想象出两种结果的代码能有多大的区别。
以上列出了两个例子，其意图在于说明某些情况下，我们进行系统分析时，当我们希望模块有信息内聚性时，结构化方法和面向对象的方法得到的过程和结果不会有很大差别。
需要对关于使用这两个例子作一些说明：
1、在UMLCHINA网站上经常看到一些文章特别强调面向对象方法中寻找USECASE和结构化方法中功能模块的划分不同。在所有的这些文章中，我也一直没有找到能够让我明白为什么不同的文字。当然，不排除以下原因：
1、1：我使用系统分析方法进行进行系统分析并指导编程的时间不长。
1、2：我的理解有问题的原因，比方说，可能在某个环节上钻入了牛角尖。
1、3：我涉及的行业领域的原因。我一直参与项目，开发数据库管理应用。
1、4：其他原因。
一个系统必然先得划分为不同的子系统。子系统如果仍然太大了，那么也必须划分为不同的子系统。以此类推。面向对象方法中的用例分解和结构化的功能模块的划分是对应的。如果用面向对象的观点来看，系统是由各个级别的对象装配而成。一个系统就是一个大对象，子系统也是对象。因为完全地从下至上地构造系统是难以想象的，所以需要进行用例分解。对于一个中型系统，像上述的第一个例子，我自问难以找出用例分解和模块分解的区别。尤其是应用不同方法时如果产生区别的话，应该在思路上会在某一个或多个关键点上有重大区别。《软件工程JAVA语言实现》中说：“如果采用面向对象的范型，则在分析阶段中有一个确定对象的步骤。因为对象是一种模块，所以结构化设计是在面向对象范型的分析阶段执行的”[P13]。对此我深表赞同。当用例分解得足够小时，该用例就类似于第二个例子。
在面向对象方法中，寻找用例时引入的对象和用于编程的对象是不同的，而结构化方法中一个功能模块也不必就对应一个程序模块。
事实上，老宋也用UML建模，但他坚持他使用的不是面向对象方法。因为他说自己从没用过面向对象的方法分析问题。
2、前面的论述其实说明了：在给定的限制下，面向对象方法中的对象和结构化方法中的具有信息内聚性的模块区别很小。但有些情况下则不然。
就我个人的经验来看，在项目的系统分析和产品的系统分析中，面向对象方法的应用效果很可能不同。
2、1：对于项目开发来说，一般的软件公司都会只做某一个或某几个行业的某些领域的应用。不会打一枪换一个阵地。对于有项目经验积累的行业，除了一些系统框架性的功能，如根据权限限制的菜单生成，和极为底层的与业务无关的功能，如读配置文件来连接数据库，其他功能很难重用。这使得即使采用面向对象分析方法，但面向对象的继承、多态等能够有力支持重用的特点根本就没有用上。倒是函数重载用得较多。
2、2：对于开发数据库管理应用的项目来说，我觉得在使用结构化方法时以数据为中心组织模块是很自然的想法。这时再使用JAVA编程，那么使用结构化方法定义出来的接口和使用面向对象定义出来的接口基本相同。可以参考：“notes_svr52/CDMA事业部/软件工程论坛”中的一篇文档 'CSDN：独孤木专栏:UML OOAD and RUP'。
2、3：开发产品系列时对重用的需求应该远比开发项目要强烈。这种情况下使用面向对象方法进行系统设计应该会比使用结构化方法效果要好的多。
以C和C++为例，C最多可以做到不完全的封装，继承和多态是无法做到的。假设有个系统，如果使用继承和多态能比较简洁地使它有良好的可扩展性的话，用C要达到同样的目的肯定要复杂得多。此时，面向对象方法和结构化方法比较——不仅仅是技术上的原因，我认为更是技术管理上的原因——使得面向对象方法更为优秀。任何将“分而治之”贯彻得更好的技术和方法，如果能达到同样的系统功能性能移植性等的要求，必然代替其他方法。纯技术上的优势，我觉得相对于技术管理的优势，并不是主要的：
2、3、1：“在许多情况下，从继承不会获得任何实际利益。然而，在大型项目里，‘不用继承’的政策的结果将是不易理解的不够灵活的系统”[P638，《C++程序设计语言》]。
2、3、2：“面向对象技术包含了很多方法学上的进步。……面向对象应用在整个开发周期中，但是真正的获益只有在后续开发、扩展和维护活动中才能体现出来。Coggin 说：‘面向对象技术不会加快首次或第二次的开发，产品族中第五个项目的开发才会异乎寻常的迅速。’”[P130，《人月神话》]。
2、3、3：个人认为，公司的文档中将函数定义和说明写在文档中，确实比不上JDK那种有清晰的类层次的可以单独存在的帮助系统。
3、我对软件过程和软件工程并不是很熟悉，最多只能说听说过概念，对于一个概念在实际工作中的意义，我总有一种模模糊糊、懵懵懂懂、感觉好像是但又抓不准的感觉。但在我以前的工作中，我自认还算一直努力地想改进我参与的项目的开发过程。在我的看法中，技术管理和开发过程管理是不同的。开发过程管理更多地和项目管理结合在一起，而技术管理更多地指研发流程、制度以及文档规范等。我知道有些公司的项目经理可以不懂技术，但我所知道的担任技术管理干部的人没有不懂技术的。任何一个分析方法，都是要应用到开发过程的每一个阶段，对开发过程的每一个阶段的每一个成员的思路都有影响。所以我认为一种分析方法如果相对另外一种分析方法而言更优秀的话，那么它必须改善技术管理。很多优秀技术一旦提供，就会发现它对开发过程的某些个或某一方面的技术管理的问题的改善提供了核心的作用。
4、我以前对测试不太关心，觉得测试是很简单的事情。直到我工作后发现当时所在公司的测试经理的桌面上摆了一排测试方面的书，才在大惊之余觉得有必要对测试的重要性和地位重新认识。但坦白的说，我觉得我在测试方面的了解仍仅限于运行程序。我觉得一种系统分析方法或技术如果优秀的话，应该能对测试提供更多种且更有效的测试方法和规范。