软件测试面向对象方法和结构化方法[1]

软件测试面向对象方法和结构化方法[1]   软件测试工具

　　我觉得无论结构化范型或面向对象的范型，都是应用到软件工程的每一个阶段。系统的分析、设计必然要为技术管理提供方便，而且从程序的设计方法不断演化(过程式程序设计-〉模块化的程序设计-〉面向对象程序设计)的过程来看，先进的分析和设计方法为技术管理提供更大的便利。我认为反之亦然。也就是说，我们在应用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图。

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