UML軟體開發過程和支援環境研究論文
UML軟體開發過程和支援環境研究論文
國際上，軟體工程領域在近3年內取得了前所未有的發展，其成果超過軟體工程領域過去10至15年來的成就總和。其中最重要的、具有劃時代意義的成果之一就是統一建模語言UML（Uni—fiedModelingLanguage）的出現。
UML是繼80年代末和90年代初面向物件建模技術高潮後，出現方法學大戰，應市場對統一建模語言的要求，由世界著名的面向物件技術專家Booch>Jacobson和Rumbaugh發起，在著名的Booch表示法、OOSE方法和OMT方法的基礎上，廣泛徵求意見，集眾家之長，幾經修改而完成時。在美國，截至1996年10月，UML已經獲得工業界、科技界和應用界的廣泛支援，已有700多個公司表示支援採用UML語言作為建模語言。
到1997年11月17日UML被OMG（ObjectManagementGroup）米納為基於面向物件技術的建模語言標準。這標誌著面向物件技術中建模語言的爭論暫時告一段落。
作為建模語言，UML可以說是一種定義良好、易於表達、功能強大且普遍適用的建模語言，
它為使用者建模提供了完整的符號表示和不同層次的兀模型（metamodel）如用例圖（uses—casedia—gram）包圖（packagediagram）、類圖（classdiag—ram）、狀態圖（statediagram）、X寸象圖（objectdia—gram）、活動圖（activitydiagram）、順序圖（se—quencediagram）合作圖（collaborationdiagram）元件圖（componentdiagram）、配置圖（deploy—mentdiagram）等。它的作用域不僅支援面向物件的分析與設計，還支援從需求分析開始的軟體開發的全過程，但如何恰當地將這些視覺化圖形建模技術用於解決軟體開發所面臨的問題以及對建模過程的研究和支援工具的研究，仍是目前該領域的熱點問題。
目前，在基於UML的開發方法和環境方面國際上已經進行了一些研究和實際開發工作。Ra—tional公司正致力於它稱之為Objectory過程的研究，並試圖將其原有支援OMT的工具作進一步擴充，以期支援UML建模，並支援對OMT模型的升級。國內對UML的研究尚處於起步階段。
本文從當前對軟體開發過程的需求出發，提出了UML柔性軟體開發過程，並設計了相應的整合化支援環境的組成框架。
1UML柔性軟體開發過程
電子計算機技術和現代通訊技術的飛速發展正迅速改變著人們對時間和空間的概念，世界在物理上正變得越來越小，而內容卻比以前任何時候都複雜。全球經濟競爭、資訊高速公路等近代資訊科技都迫使各個企業面臨著新的挑戰。為了能在瞬息萬變的市場和激烈的競爭中保住一席之地，負責資訊科技機構的主管人員將不得不學會應變管理技術（changemanagement）。在軟體開發領域，需要改變其開發與生產的正規化，以滿足這種新的需求。
傳統的軟體開發模式越來越難以滿足當前企業和市場的需求。新的產品開發週期已不再是一次性的從需求定義、軟體設計、實現和交付，迭代式增量開發方式已得到廣泛採用。這是由於軟體系統的規模越來越大，其複雜程度不斷提高，而與此同時又不得不面臨激烈的競爭對手和瞬息萬變的市場。時間就是效益，誰先佔領市場，誰就是勝利者。但是佔領市場和擊敗對手的條件除了時間之外，更重要的是過硬的.質量和提供使用者真正需要的產品。因此將新的軟體開發模式歸結為圖1所示的迭代式開發和圖2所示的柔性軟體開發模型。
所謂柔性軟體開發是指軟體開發過程應在需求工程的牽引下，首先建立系統模型，對模型進行模擬、分析和調整，進行從需求到建模的“自頂向下建模，由底向上修改”即從需求工程出發，首先明確使用者要求，確定需求優先順序；在此基礎上為系統建立模型，該模型應是可模擬的，透過對模型的模擬執行，以分析模型是否滿足使用者需求和滿足的程度。整個建模過程是自頂向下逐層細化的，而模擬修改則由底向上地進行。
然後在保證模型正確的基礎上，進行程式碼的生成，同時還應考慮到對需求修改的靈活性和快速響應能力，因此應能進行‘閉環開發”即不僅能支援從模型到程式碼的自動生成，將新的模型轉換為程式碼，還應能支援從程式碼到模型的逆向變換，將原有的程式碼轉化成模型，進行再次分析、修改和調整，進行新一輪的開發，從而為增量式開發提供支援，能分階段提交產品，也提高了對使用者需求變化的響應速度和應變能力，滿足使用者不斷變化的需求。
2UML軟體開發支援環境
為此，新一代整合化UML軟體開發環境應是能無縫整合以上2個階段的一個柔性軟體開發環境。其組成應包括UML視覺化建模系統、UML模擬系統、UML程式碼生成系統、UML逆向變換系統及其支援環境等，且這些環境的建立均應基於UML的定義，除了語法規則外，還包括詳細的語義定義，如圖3所示。從而支援系統建模、模擬和“閉環式開發'。
1）UML視覺化建模系統UML視覺化建模系統支援從系統需求、系統分析到系統設計的整個建模過程，提供UML圖形的編輯和美化工具，保證得到語法正確、語義完整的UML圖形模型，並提供包括文件管理、圖形列印等輔助支援。可進一步分為以下幾個子系統，如圖4所示。
（）視覺化模型建造系統由於UML不僅支援對系統的物件建模，還支援對需求和系統體系結構的建模；不僅支援系統的靜態模型，還支援對系統動態模型的描述。因此模型建造系統應支援以下模型的建立和編輯：需求模型。包括靜態模型和動態模型。靜態模型即功能模型，在UML中透過用例圖描述系統功能和各功能的潛在使用者及它們之間的關係；動態模型透過活動圖支援對業務過程或事務處理過程的描述。
系統物件模型。同樣包括靜態模型和動態模型。透過包圖、類圖和物件圖定義系統物件及物件間的靜態關係。透過順序圖、合作圖和狀態圖描述物件間的互動關係和互動順序、物件的生命週期以及生命週期中物件可能存在的狀態以及狀態間的轉換約束。
系統體系結構模型。透過元件圖、配置圖支援軟體體系結構和硬體體系結構以及通訊機制的定義。進一步還應支援軟硬體系統之間的合作關係的視覺化表示。
（2）UML語法正確性檢測機制
為保證所得到的UML圖形模型符合UML的語法定義[61，應提供語法正確性檢查機制。一個較好的方法是提供語法制導的UML視覺化建模工具，從而在模型的建造過程中提供動態的語法制導和語法檢
測功能，既方便使用者學習和使用，也可保證所建造的模型在語法結構上的正確性。
（2）UML模型的一致性檢查機制
由於UML支援從需求分析到系統設計整個建模過程，並且支援使用者從不同角度描述系統，而大型軟體專案各模型間的協作和約束關係錯綜複雜，顯然不應由使用者獨自承當它們的管理和維護工作。作為建模支援系統，應提供模型間的一致性檢查機制。
首先，該機制應根據以上對基於UML軟體開發模型的討論，在軟體開發階段時間軸上確定引入模型的時間；其次，明確同一種模型的細化分層機制，以及怎樣用其它模型描述主模型的細節；第三，在軟體開發階段時間軸上，一個模型存在自頂向下分解的層次結構，各時間階段產生的層次結構中各種UML模型相互約束協作又產生複雜的網狀關係，需要建立不同階段、不同功能的同一種模型和不同種模型約束和協作的數學模型；最後，在該數學模型的基礎上，研究將約束和協作關係有機地加入軟體開發各個階段的模型一致性檢查機制。
此外，由於允許從不同的角度描述同一模型，如互動圖包括順序圖和合作圖，這兩者之間允許存在冗餘資訊，因此不僅應保證二者間資訊的一致性，作為進一步的支援，還可考慮支援模型間的一致性轉換。
（3）UML模型的完備性檢查機制
完備性檢查機制須在UML語義定義的基礎上，首先定義UML圖形模型的完備性準則，以保證UML圖形模型的完備性。對於UML圖形模型的完備性可以分3個層次來考慮：各個圖形的完備性；各個子模型的完備性，即相關圖形的組合完備性；系統模型的整體完備性。區分這3種完備性的意義在於：在不同階段可以進行語義完備性和語義正確性檢查。如在需求分析階段，可以對透過完備性檢查的活動圖進行模擬，以檢查該活動圖的正確性。而在整個系統模型透過完備性檢查之後，方可進行程式碼的自動生成。
（5）文件生成和管理工具
文件生成工具是指文件自動生成機制。作為一個建模支援系統，應支援包括需求描述、面向物件分析和設計、系統體系結構等文件資料的自動生成。文件管理工具是指文件資料的版本管理等輔助管理工作。
1）UML模擬系統
系統模擬機制支援對UML模型的功能模擬和效能模擬，它包括以下3個部分：
（1）對動態模型的模擬
主要包括對活動模型、互動模型（順序圖和互動圖）以及狀態圖的模擬。根據預先定義的語義，模擬各個模型對系統在時間特性上的描述是否真實地反映了客觀現實和使用者需求；並應提供相應的跟蹤除錯機制。
（2）對系統功能（需求）和使用者介面的模擬。
用來支援快速原型。藉助於程式碼自動生成工
具和使用者介面自動生成工具的支援，產生系統原型，並儘早提供給使用者，以確保建模的有效性。
（3）系統性能的模擬
UML支援對系統體系結構的建模，作為一個良好的建模和開發支援工具，應支援對不同系統配置和功能分配情況下對系統性能的模擬，以便得到較好的系統設計方案和合理的系統配置。
2）UML程式碼生成系統
支援視覺化物件和行為的程式碼生成，也稱之為UML支援環境的正向變換系統。
軟體開發的最終目的是產生可執行程式碼。大多數軟體開發環境中，建模和編碼過程缺少有機的統一，這是有其歷史原因的。其中最重要的原因是缺少功能強大、簡單清楚、標準統一的建模語言。UML的出現並被OMG接受為標準，為消除這個障礙提供了一個最好的起點。
UML雖然是一種視覺化建模語言，不是程式語言。但是它與大多數面嚮物件語言（例如C++、Java）存在緊密的對映關係。在UML語言的程式碼生成機制方面，國際上一些大公司有一些有益的研究和開發工作。比較有代表性的有Ra—tional公司和AdvancedSoftwareTechnologiesInc。但這些研究和實現大多限於UML語言的靜態模型中的類圖，其它模型的程式碼自動生成機制的研究資料則非常罕見。
為此程式碼自動生成機制應根據UML語言多種模型動態協作、關係複雜的特點，首先界定UML的語義和麵向物件程式語言（首先是Java）的語義，研究專用語義機制描述面向物件模型和語言中動態和靜態機制，建立兩者的語義模型；再在該語義模型下建立兩者的對映模型；並研究程式碼自動生成實現技術和獨立於UML語言本身的程式語言的特殊機制。程式碼自動生成機制的研究與實現應考慮後面的逆向轉換機制。
3）UML逆向變換系統
當用戶對生成的程式碼進行修改後，逆向轉換機制將使用者的修改轉換到模型上。否則將造成模型和程式碼間的不一致性，使得系統的擴充、增刪和維護難以進行。
逆向轉換機制一般由建模、析取和抽象3個步
驟組成。動態模型的逆向轉換機制是研究的難點。我們將在正向轉換的基礎上，建立起模型到程式碼的對映關係，嘗試建立起一套約束機制，實現自動的或人工導引的逆向轉換機制。在國際上，這方面的研究並不成熟。
3結束語
根據一年多來對UML的學習和分析以及對UML支援環境的研究和開發工作，本文從當前對軟體過程的需求出發，提出了當前軟體開發應具備的特點和開發模型，在此基礎上設計了整合化UML軟體開發環境框架，提出了需解決的問題。目前我們已經完成了UML視覺化建模系統的開發工作，並在研究生課程中由80多名學生進行了試用，反映良好。UML軟體開發支援環境的其他子系統正在研究、開發之中。