軟件測試面向對象方法和結構化方法[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.kjueaiud.com/