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