結構化方法與面向對象方法之應用比較

時間 2019-11-10

原文原文鏈接

1 引言

20世紀60年代中期，大容量、高速度計算機的出現，使得計算機的應用範圍迅速擴大，軟件開發急劇增加。高級語言開始出現；操做系統的發展引發了計算機應用方式的變化；大量數據處理致使第一代數據庫管理系統的誕生。軟件系統的規模愈來愈大，複雜成都愈來愈高，軟件可靠性問題也愈來愈突出。原來的我的設計、我的使用的方式再也不能知足現實需求，迫切須要改變軟件生產方式，提升軟件生產率，「軟件危機」開始爆發。數據庫

爲了提升軟件質量和軟件開發的效率，人們提出了各類各樣的軟件開發方法，結構化方法和麪向對象方法應運而生。結構化方法最爲成熟，影響最大。直到如今，仍有60%~70%的系統是用結構化方法開發的。面向對象方法近十年來發展迅速，大有取代結構化方法的趨勢。本文將就兩者在軟件開發中的優點、特色、差別進行對比與分析。編程

2 結構化方法

結構化方法出現於20世紀70年代，是一種早期的傳統的軟件開發方法。它基於功能分解設計系統結構，經過不斷把複雜的處理逐層分解來簡化問題，它從內部功能上模擬客觀世界。用結構化開發的軟件運行效率較高，且可以增長軟件系統的可靠性。數據庫設計

結構化方法由結構化分析（SA）、結構化設計（SD）、結構化程序設計（SP）三部分組成。它的基本思想是自頂向下、逐步求精，把一個複雜的系統分解成容易求解的各個模塊，進而把複雜的問題簡單化、模塊化，利於工程化地實現與解決。模塊化

2.1 結構化分析（SA）

結構化分析是面向數據流進行需求分析的方法，在該階段力求尋找功能及功能之間的說明。它主要採用的工具是數據流圖DFD(Data Flow Diagram)，利用DFD描述邊界和數據處理過程的關係。工具

進行結構化分析的主要工具還有數據詞典、結構化英語、斷定表、斷定樹、實體關係圖等，其中數據流圖和實體關係圖應用最爲普遍。優化

一般有以下步驟：spa

（a）分析當前的狀況，作出當前物理模型的DFD；操作系統

（b）推導出等價的邏輯模型的DFD；設計

（c）設計新的邏輯系統，生成數據字典和基元描述；對象

（d）創建人機接口，肯定目標系統物理模型的DFD。

2.1.1 數據流圖

數據流圖有四個基本要素：數據流、實體、數據加工和數據存儲。

數據流圖是一種分層的思想，逐漸地體現系統的邏輯功能。整體思想是：首先肯定系統和系統涉及到的外部實體之間的數據量，畫出頂層圖；而後在頂層圖的基礎上，對系統的主要功能進行分析，抽象出各個功能，做爲系統的加工，所以頂層圖的系統加工模塊就細化爲下一層的加工模塊，肯定實體和加工之間的數據量，畫出下一次數據流圖；而後再在此基礎上，對其全部加工進行進一步的分析說明，逐一細化，以此類推，細化到加工不能再細化爲止。數據流圖越詳細，系統的功能就越明確。

下面經過一張經典的圖來形象化地說明數據流圖的分層結構：

2.2 結構化設計（SD）

在結構化分析的基礎上，映射分析模型到設計模型，獲得系統的模塊結構、數據庫結構等，其中數據庫結構主要從分析階段的ER（實體關係）模型獲得，數據庫設計至少要知足第三範式的要求，在設計過程當中的數據庫設計在此不做過多說明。而系統的模塊結構是在數據流圖的基礎上，進行相應的變換分析和事務分析獲得，從結構化分析階段的數據流圖映射到系統的模塊結構圖，設計出知足高內聚低耦合的模塊，即模塊要知足獨立性要求。

一般有以下步驟：

（a）評審和細化數據流圖；

（b）肯定數據流圖的類型；

（c）把設局劉圖映射到軟件模塊結構，設計出上層結構；

（d）基於數據流圖逐步分解高層模塊，設計中下層模塊；

（e）對模塊結構進行優化，獲得更爲合理的軟件結構；

（f）描述模塊接口。

2.3 結構化方法的特色與侷限

結構化方法從內部功能上模擬客觀世界，用結構化方法開發的軟件運行效率高，且可以增長軟件規格說明的可讀性及系統的可靠性，由於數據流圖容易理解，有利於開發人員與客戶的交流。但其缺點在於軟件系統結構對功能的變化十分敏感，功能變化每每意味着難以重用。

2.3.1 對問題域的認識

結構化方法在需求分析中對問題域的認識和描述不是以問題域中固有事物——對象做爲基本單位，而是打破了各項事物之間的界限，在全局範圍內以數據量爲中心進行分析的，因此分析結果不能直接反映問題域。同時，當系統較複雜時，很難檢驗分析的正確性。所以結構化分析方法容易隱蔽一些對問題域的理解誤差，與後續開發階段的銜接也比較困難。

2.3.2 分析與設計差別

結構化方法中設計文檔很難與分析文檔對應，由於兩者的表示體系不一致。結構化分析的結果數據流圖（DFD）和結構化設計結果模塊結構圖（MSD）是兩種不一樣的表示體系，從分析到設計的「轉換」不存在可靠的轉換規則，而更多的是帶有我的理解的隨意性，容易因理解上的誤差產生錯誤而爲之後的開發埋下隱患。

2.3.3 難以適應需求變化

結構化方法對需求變化的適應能力較弱，軟件系統結構對功能的變化十分敏感，功能的變化會引發許多數據流的修改，同時設計出的軟件難以重用，延緩了開發的過程。

3 面向對象方法

面向對象思想最先起源於Simula計算機仿真語言，隨着20世紀80年代面嚮對象語言的普遍出現，逐漸成爲主流。面向對象方法的基本思想，就是要創建出問題域模型，開發出可以直觀表現求解方法的軟件系統，在這個過程當中，問題域模型必須給予人們習慣的思惟方式。

與結構化方法相似，面向對象方法也包含三個部分：面向對象分析（OOA ）、面向對象設計（OOD）、面向對象程序設計（OOP）。對象、類、封裝性、繼承性、多態性的引入使用，另面向對象方法具備必定的優點，能爲生成可重用的軟件構件和解決軟件的複雜性問題提供一條有效的途徑。如今比較流行的面向對象方法是基於統一建模語言（UML），經過創建系統的各類模型來分析設計系統。同時UML支持系統構建，可以進行正向工程和反向工程，即可以將各類UML模型自動映射爲源程序代碼，也能夠從源程序代碼映射爲各類模型，這體現了必定的靈活性。在面向對象方法中，分析與設計再也不有明顯的界限，能夠把面向對象分析做爲面向對象設計的一部分，面向對象方法中系統功能的實現是經過對象的交互來進行的。

3.1 統一建模語言（UML）

UML主要內容包括：基本構造塊、規則和公共機制，其中基本構造塊包括事物、關係、圖，基本構造塊是UML建模的靈魂。UML中涉及到的事物主要有結構事物、行爲事物、分組事物和註釋事物。

UML的組成如圖所示：

3.2 面向對象設計

OOA和OOD採用一致的概念、原則和表示方法，兩者之間不存在鴻溝，不須要從分析文檔到設計文檔的轉換，兩者之間也不強調嚴格的階段劃分。能體現兩者之間關係的是近幾年提出的一種新的軟件生命週期模型——噴泉模型，其中分析與設計這兩個水泡表面OOA與OOD沒有嚴格的邊界，它們是連續的、無縫的、容許有必定的相交。

面向對象設計的具體過程：

（1）對象行爲和對象間交互做用的進一步細化；

（2）用例的設計和實現。用例的分析工做從系統的外部角度展現系統的功能，系統內部的對象爲實現這些外部功能而要發生的相互做用的行爲是由用例的設計和實現工做來肯定的；

（3）精化分析階段的交互圖、狀態圖、活動圖；

（4）肯定系統可重用的類或部件；

（5）用構件圖（Component Diagram）描述代碼部件的物理結構及相互之間的依賴關係；

（6）用配置圖（Deployment Diagram）描述軟硬件的物理體系結構。

3.3 面向對象方法的特色與侷限

面向對象方法從內部結構上模擬客觀世界，對象是客觀世界對象的直接映象，符合人們的思惟方式。在面向對象的開發模型中，分析、設計和編程階段是重疊的，核心概念「對象」在開發的各個階段均被使用，相對結構化方法來講能夠減小工做量和映射偏差。面向對象方法中對象不只包括數據，還包括對數據的操做方法；對象之間的通信是經過發送消息來完成的，因爲採用了繼承的概念，有利於軟件重用；所建模型的穩定性比結構化方法高；它更接近人們的思惟習慣，因此容易讓人們接受。

3.3.1 對客觀事物判斷的不肯定性

面向對象方法中對象的肯定有時會因客觀邊界模糊而難以肯定，即便肯定下來也將會帶有不少人爲的因素，這樣就很難保證軟件描述的正確性。

3.3.2 認識差別

在問題域模型中，面向對象方法把具體或抽象的問題域或現象直接表述爲對象，同時把現象類型直接表述爲類。大多數面向對象分析方法支持多視角模型，即對同一問題域現象，不一樣的主體能夠將它表述爲同一對象或類型，但系統的描述者在應用面向對象方法進行建模時常遇到這樣的困惑，描述者力圖經過面向對象的表述對存在的問題域現象達成一致，然而，結果獲得的對象或類並不很適合於某個描述者對對象的獨自觀察而獲得的表述。也就是說，在面向對象模型中，不一樣的系統描述者在觀察描述同一個問題域現象時，均可以把該現象表述爲對象或類，但卻不能表述各自之間存在的對問題域現象的不一樣認識。

4 總結

從上面的分析設計過程能夠看出，結構化方法是對系統功能建模，基於功能分解設計系統結構，從內部功能上模擬客觀世界。面向對象方法則是從行爲的角度進行建模，基於行爲分析法認定對象及它們之間的關係，從內部結構上模擬客觀世界，它採用了新概念、新方法、新的表示形式，有助於軟件開發人員加深對系統的理解，給軟件開發帶來很大益處。但在實際應用中，開發的大型軟件系統一般是混合型系統，即須要處理實時信息、又須要數據庫的支持，同時還涉及大量的事務性操做請求，在這種狀況下，在選用面向對象方法的同時在局部處理上能夠結合使用結構化方法。