軟體開發方法述評

NO IMAGE

60年代中期開始爆發了眾所周知的軟體危機。為了克服這一危機,在1968、1969年連續召開的兩次著名的NATO會議上提出了軟體工程這一術語,並在以後不斷髮展、完善。與此同時,軟體研究人員也在不斷探索新的軟體開發方法。至今已形成八類軟體開發方法。

一、Parnas方法
  最早的軟體開發方法是由D. Parnas在1972年提出的。由於當時軟體在可維護性和可靠性方面存在著嚴重問題,因此Par-nas提出的方法是針對這兩個問題的。首先,Parnas提出了資訊隱蔽原則:在概要設計時列出將來可能發生變化的因素,並在模組劃分時將這些因素放到個別模組的內部。這樣,在將來由於這些因素變化而需修改軟體時,只需修改這些個別的模組,其它模組不受影響。資訊隱蔽技術不僅提高了軟體的可維護性,而且也避免了錯誤的蔓延,改善了軟體的可靠性。現在資訊隱蔽原則已成為軟體工程學中的一條重要原則。

  Parnas提出的第二條原則是在軟體設計時應對可能發生的種種意外故障採取措施。軟體是很脆弱的,很可能因為一個微小的錯誤而引發嚴重的事故,所以必須加強防範。如在分配使用裝置前,應該取裝置狀態字,檢查裝置是否正常。此外,模組之間也要加強檢查,防止錯誤蔓延。

  Parnas對軟體開發提出了深刻的見解。遺憾的是,他沒有給出明確的工作流程。所以這一方法不能獨立使用,只能作為其它方法的補充。

二、Yourdon方法
  1978年,E.Yourdon和L.L.Constan-tine提出了結構化方法,即SASD方法,也可稱為面向功能的軟體開發方法或面向資料流的軟體開發方法。1979年Tom DeMarco對此方法作了進一步的完善。

  Yourdon方法是80年代使用最廣泛的軟體開發方法。它首先用結構化分析(SA)對軟體進行需求分析,然後用結構化設計(SD)方法進行總體設計,最後是結構化程式設計(SP)。這一方法不僅開發步驟明確,SA、SD、SP相輔相成,一氣呵成,而且給出了兩類典型的軟體結構(變換型和事務型),便於參照,使軟體開發的成功率大大提高,從而深受軟體開發人員的青睞。

三、面向資料結構的軟體開發方法
1.Jackson方法

  1975年,M.A.Jackson提出了一類至今仍廣泛使用的軟體開發方法。這一方法從目標系統的輸入、輸出資料結構入手,匯出程式框架結構,再補充其它細節,就可得到完整的程式結構圖。這一方法對輸入、輸出資料結構明確的中小型系統特別有效,如商業應用中的檔案表格處理。該方法也可與其它方法結合,用於模組的詳細設計。

  Jackson方法有時也稱為面向資料結構的軟體設計方法。

2.Warnier方法

  1974年,J.D.Warnier提出的軟體開發方法與Jackson方法類似。差別有三點:一是它們使用的圖形工具不同,分別使用Warnier圖和Jackson圖;另一個差別是使用的偽碼不同;最主要的差別是在構造程式框架時,Warnier方法僅考慮輸入資料結構,而Jackson方法不僅考慮輸入資料結構,而且還考慮輸出資料結構。

四、問題分析法PAM
  問題分析法PAM(Problem Analysis Method)是80年代末由日立公司提出的一種軟體開發方法。

  PAM方法希望能兼顧Yourdon方法、Jackson方法和自底向上的軟體開發方法的優點,而避免它們的缺陷。它的基本思想是:考慮到輸入、輸出資料結構,指導系統的分解,在系統分析指導下逐步綜合。這一方法的具體步驟是:從輸入、輸出資料結構匯出基本處理框;分析這些處理框之間的先後關係;按先後關係逐步綜合處理框,直到畫出整個系統的PAD圖。從上述步驟中可以看出,這一方法本質上是綜合的自底向上的方法,但在逐步綜合之前已進行了有目的的分解,這個目的就是充分考慮系統的輸入、輸出資料結構。

  PAM方法的另一個優點是使用PAD圖。這是一種二維樹形結構圖,是到目前為止最好的詳細設計表示方法之一,遠遠優於N-S圖和PDL語言。

  這一方法在日本較為流行,軟體開發的成功率也很高。由於在輸入、輸出資料結構與整個系統之間同樣存在著鴻溝,這一方法仍只適用於中小型問題。

五、物件導向的軟體開發方法
  物件導向技術是軟體技術的一次革命,在軟體開發史上具有里程碑的意義。

  隨著OOP(物件導向程式設計)向OOD(物件導向設計)和OOA(物件導向分析)的發展,最終形成物件導向的軟體開發方法OMT(Object Modelling Technique)。這是一種自底向上和自頂向下相結合的方法,而且它以物件建模為基礎,從而不僅考慮了輸入、輸出資料結構,實際上也包含了所有物件的資料結構。所以OMT徹底實現了PAM沒有完全實現的目標。不僅如此,OO技術在需求分析、可維護性和可靠性這三個軟體開發的關鍵環節和質量指標上有了實質性的突破 ,徹底地解決了在這些方面存在的嚴重問題,從而宣告了軟體危機末日的來臨。

1.自底向上的歸納

  OMT的第一步是從問題的陳述入手,構造系統模型。從真實系統匯出類的體系,即物件模型包括類的屬性,與子類、父類的繼承關係,以及類之間的關聯。類是具有相似屬性和行為的一組具體例項(客觀物件)的抽象,父類是若干子類的歸納。因此這是一種自底向上的歸納過程。在自底向上的歸納過程中,為使子類能更合理地繼承父類的屬性和行為,可能需要自頂向下的修改,從而使整個類體系更加合理。由於這種類體系的構造是從具體到抽象,再從抽象到具體,符合人類的思維規律,因此能更快、更方便地完成任務。這與自頂向下的Yourdon方法構成鮮明的對照。在Yourdon方法中構造系統模型是最困難的一步,因為自頂向下的”頂”是一個空中樓閣,缺乏堅實的基礎,而且功能分解有相當大的任意性,因此需要開發人員有豐富的軟體開發經驗。而在OMT中這一工作可由一般開發人員較快地完成。在物件模型建立後,很容易在這一基礎上再匯出動態模型和功能模型。這三個模型一起構成要求解的系統模型。

2.自頂向下的分解

  系統模型建立後的工作就是分解。與Yourdon方法按功能分解不同,在OMT中通常按服務 (Service)來分解。服務是具有共同目標的相關功能的集合,如I/O處理、圖形處理等。這一步的分解通常很明確,而這些子系統的進一步分解因有較具體的系統模型為依據,也相對容易。所以OMT也具有自頂向下方法的優點,即能有效地控制模組的複雜性,同時避免了Yourdon方法中功能分解的困難和不確定性。

3.OMT的基礎是物件模型

  每個物件類由資料結構(屬性)和操作(行為)組成,有關的所有資料結構(包括輸入、輸出資料結構)都成了軟體開發的依據。因此Jackson方法和PAM中輸入、輸出資料結構與整個系統之間的鴻溝在OMT中不再存在。OMT不僅具有Jackson方法和PAM的優點,而且可以應用於大型系統。更重要的是,在Jackson方法和PAM方法中,當它們的出發點———輸入、輸出資料結構(即系統的邊界)發生變化時,整個軟體必須推倒重來。但在OMT中系統邊界的改變只是增加或減少一些物件而已,整個系統改動極小。

4.需求分析徹底

  需求分析不徹底是軟體失敗的主要原因之一。即使在目前,這一危險依然存在。傳統的軟體開發方法不允許在開發過程中使用者的需求發生變化,從而導致種種問題。正是由於這一原因,人們提出了原型化方法,推出探索原型、實驗原型和進化原型,積極鼓勵使用者改進需求。在每次改進需求後又形成新的進化原型供使用者試用,直到使用者基本滿意,大大提高了軟體的成功率。但是它要求軟體開發人員能迅速生成這些原型,這就要求有自動生成程式碼的工具的支援。

  OMT徹底解決了這一問題。因為需求分析過程已與系統模型的形成過程一致,開發人員與使用者的討論是從使用者熟悉的具體例項(實體)開始的。開發人員必須搞清現實系統才能匯出系統模型,這就使使用者與開發人員之間有了共同的語言,避免了傳統需求分析中可能產生的種種問題。

5.可維護性大大改善

  在OMT之前的軟體開發方法都是基於功能分解的。儘管軟體工程學在可維護方面作出了極大的努力,使軟體的可維護性有較大的改進。但從本質上講,基於功能分解的軟體是不易維護的。因為功能一旦有變化都會使開發的軟體系統產生較大的變化,甚至推倒重來。更嚴重的是,在這種軟體系統中,修改是困難的。由於種種原因,即使是微小的修改也可能引入新的錯誤。所以傳統開發方法很可能會引起軟體成本增長失控、軟體質量得不到保證等一系列嚴重問題。正是OMT才使軟體的可維護性有了質的改善。

  OMT的基礎是目標系統的物件模型,而不是功能的分解。功能是物件的使用,它依賴於應用的細節,並在開發過程中不斷變化。由於物件是客觀存在的,因此當需求變化時物件的性質要比物件的使用更為穩定,從而使建立在物件結構上的軟體系統也更為穩定。

  更重要的是OMT徹底解決了軟體的可維護性。在OO語言中,子類不僅可以繼承父類的屬性和行為,而且也可以過載父類的某個行為(虛擬函式)。利用這一特點,我們可以方便地進行功能修改:引入某類的一個子類,對要修改的一些行為(即虛擬函式或虛方法)進行過載,也就是對它們重新定義。由於不再在原來的程式模組中引入修改,所以徹底解決了軟體的可修改性,從而也徹底解決了軟體的可維護性。OO技術還提高了軟體的可靠性和健壯性。

六、視覺化開發方法
  視覺化開發是90年代軟體界最大的兩個熱點之一。隨著圖形使用者介面的興起,使用者介面在軟體系統中所佔的比例也越來越大,有的甚至高達60~70%。產生這一問題的原因是圖形介面元素的生成很不方便。為此Windows提供了應用程式設計介面API(Application Programm ing Inter-face),它包含了600多個函式,極大地方便了圖形使用者介面的開發。但是在這批函式中,大量的函式引數和使用數量更多的有關常量,使基於Windows API的開發變得相當困難。為此Borland C 推出了Object Windows程式設計。它將API的各部分用物件類進行封裝,提供了大量預定義的類,併為這些定義了許多成員函式。利用子類對父類的繼承性,以及例項對類的函式的引用,應用程式的開發可以省卻大量類的定義,省卻大量成員函式的定義或只需作少量修改以定義子類。Object Win-dows還提供了許多標準的預設處理,大大減少了應用程式開發的工作量。但要掌握它們,對非專業人員來說仍是一個沉重的負擔。為此人們利用Window s API或Borland C 的Object Windows開發了一批可視開發工具。

  視覺化開發就是在可視開發工具提供的圖形使用者介面上,通過操作介面元素,諸如選單、按鈕、對話方塊、編輯框、單選框、核取方塊、列表框和滾動條等,由可視開發工具自動生成應用軟體。

  這類應用軟體的工作方式是事件驅動。對每一事件,由系統產生相應的訊息,再傳遞給相應的訊息響應函式。這些訊息響應函式是由可視開發工具在生成軟體時自動裝入的。

  可視開發工具應提供兩大類服務。一類是生成圖形使用者介面及相關的訊息響應函式。通常的方法是先生成基本視窗,並在它的外面以圖示形式列出所有其它的介面元素,讓開發人員挑選後放入視窗指定位置。在逐一安排介面元素的同時,還可以用滑鼠拖動,以使視窗的佈局更趨合理。

  另一類服務是為各種具體的子應用的各個常規執行步驟提供規範視窗,它包括對話方塊、選單、列表框、組合框、按鈕和編輯框等,以供使用者挑選。開發工具還應為所有的選擇(事件)提供訊息響應函式。

  由於要生成與各種應用相關的訊息響應函式,因此,視覺化開發只能用於相當成熟的應用領域,如目前流行的視覺化開發工具基本上用於關聯式資料庫的開發。對一般的應用,目前的視覺化開發工具只能提供使用者介面的視覺化開發。至於訊息響應函式(或稱指令碼),則仍需用通常的高階語言(3GL)編寫。只有在資料庫領域才提供4GL,使訊息響應函式的開發大大簡化。

  從原理上講,與圖形有關的所有應用都可採用視覺化開發方式,如活塞表面設計中的熱應力計算。使用者只需在介面上用滑鼠修改活塞表面的曲線,應用軟體就自動進行有限元劃分、溫度場計算、熱應力計算,並將熱應力的等值曲線圖顯示在螢幕上。最後幾次生成的結果還可並列顯示在各視窗上,供使用者比較,其中的一個主視窗還可讓使用者進一步修改活塞表面曲線。

  許多工程科學計算都與圖形有關,從而都可以開發相應的視覺化計算的應用軟體。

  視覺化開發是軟體開發方式上的一場革命,它使軟體開發從專業人員的手中解放出來,對緩解80年代中後期爆發的應用軟體危機有重大作用。

七、ICASE
  提高人類的勞動生產率,提高生產的自動化程度,一直是人類堅持不懈的追求目標。軟體開發也不例外。早在1982年美國國防部就提出了STARS工程,希望建立一個”用以支援需求定義、程式生成以及軟體維護等軟體生存期全部活動的,並把它們整合在一起的整個體系”。但早期的軟體開發環境工具較少,且不配套,支援需求分析等高層次生存期階段的工具更少,因此要求支援某類軟體開發方法的全過程已很不容易了。如Your-don公司的Cradle軟體開發環境支援Yourdon結構化開發方法,Jackson工具集支援Jackson開發方法。

  隨著軟體開發工具的積累,自動化工具的增多,軟體開發環境進入了第三代ICASE(Integrated Computer-Aided Software Engineering)。系統整合方式經歷了從資料交換(早期CA SE採用的整合方式:點到點的資料轉換),到公共使用者介面(第二代CASE:在一致的介面下呼叫眾多不同的工具),再到目前的資訊中心庫方式。這是ICASE的主要整合方式。它不僅提供資料整合(1991年IEEE為工具互連提出了標準P1175)和控制整合(實現工具間的呼叫),還提供了一組使用者介面管理設施和一大批工具,如垂直工具集(支援軟體生存期各階段,保證生成資訊的完備性和一致性)、水平工具集(用於不同的軟體開發方法)以及開放工具槽。

  ICASE的進一步發展則是與其它軟體開發方法的結合,如與物件導向技術、軟體重用技術結合,以及智慧化的I-CASE。近幾年已出現了能實現全自動軟體開發的ICASE。

  ICASE的最終目標是實現應用軟體的全自動開發,即開發人員只要寫好軟體的需求規格說明書,軟體開發環境就自動完成從需求分析開始的所有的軟體開發工作,自動生成供使用者直接使用的軟體及有關文件。

  在應用最成熟的資料庫領域,目前已有能實現全部自動生成的應用軟體,如MSE公司的Magic系統。它只要求軟體開發人員填寫一系列表格(相當於要求軟體實現的各種功能),系統就會自動生成應用軟體。它不僅能節省90%以上的軟體開發和維護的工作量,而且還能將應用軟體的開發工作轉交給熟練的使用者。

八、軟體重用和元件連線
  軟體重用(Reuse)又稱軟體複用或軟體再用。早在1968年的NATO軟體工程會議上就已提出可複用庫的思想。1983年,Freeman對軟體重用給出了詳細的定義:”在構造新的軟體系統的過程中,對已存在的軟體人工製品的使用技術。”軟體人工製品可以是原始碼片斷、子系統的設計結構、模組的詳細設計、文件和某一方面的規範說明等。所以軟體重用是利用已有的軟體成份來構造新的軟體。它可以大大減少軟體開發所需的費用和時間,且有利於提高軟體的可維護性和可靠性。目前軟體重用沿著下面三個方向發展:

1.基於軟體複用庫的軟體重用

  它是一種傳統的軟體重用技術。這類軟體開發方法要求提供軟體可重用成份的模式分類和檢索,且要解決如何有效地組織、標識、描述和引用這些軟體成份。通常採用兩種方式進行軟體重用:

(1)生成技術 這是對模式的重用。由軟體生成器通過替換特定引數,生成抽象軟體成份的具體例項。

(2)組裝方式 常用的組裝方式有:子程式庫技術、共享介面設計和巢狀函式呼叫等。組裝方式對軟體重用成份通常不作修改,或僅作很少的修改。

2.與物件導向技術結合

  OO技術中類的聚集、例項對類的成員函式或操作的引用、子類對父類的繼承等使軟體的可重用性有了較大的提高。而且這種型別的重用容易實現。所以這種方式的軟體重用發展較快。

3.元件連線

  這是目前發展最快的軟體重用方式。最早的元件連線技術OLE 1.0(Object Linking an d Embedding)是Microsoft公司於1990年11月在COMDEX展覽會上推出的。OLE 1.0的規範發表於1990年12月,1991年2月推出了第一批支援OLE 1.0規範的應用程式。1993年5月發表了OLE 2.0。幾個月後,第一批支援OLE 2.0的應用程式問世。

  OLE給出了軟體元件(Component Object)的介面標準。這樣任何人都可以按此標準獨立地開發元件和增值元件(元件上新增一些功能構成新的元件),或由若干元件組建整合軟體。在這種軟體開發方法中,應用系統的開發人員可以把主要精力放在應用系統本身的研究上,因為他們可在元件市場上購買所需的大部分元件。

  軟體元件市場/元件整合方式是一種社會化的軟體開發方式,因此也是軟體開發方式上的一次革命,必將極大地提高軟體開發的勞動生產率,而且應用軟體開發週期將大大縮短,軟體質量將更好,所需開發費用會進一步降低,軟體維護也更容易。

  軟體元件連線的另一個標準是1995年3月推出的OpenDoc。這是IBM、Apple等公司組成的 CI Labs集團使用的標準。由於OpenDoc的程式設計介面比OLE小,因此OpenDoc的應用程式能與OL E相容。

  第三個元件連線標準是物件管理集團OMG於1991年發表的CORBA(Common Object Reques t Broker Architecture),1994年OMG又發表了CORBA 2.0。

  由於OLE 1.0、OLE 2.0的部分功能已放入Windows 3.1(在推出OLE 2.0的同時,推出Win dows 3.1的OLE 2.0),因此目前使用的元件連線開發技術大多基於OLE 2.0。

  綜上所述,今後的軟體開發將是以OO技術為基礎(指用它開發系統軟體和軟體開發環境) ,視覺化開發、ICASE和軟體元件連線三種方式並駕齊驅。它們四個將一起形成軟體界新一輪的熱點技術。