馮富霞,李森貴
(安徽工程科技學院,安徽蕪湖 241000)
UML科學建模系統研究
馮富霞,李森貴
(安徽工程科技學院,安徽蕪湖 241000)
本文對實際使用UML的誤區進行了深入分析,針對問題給出了以可伸縮迭代—遞增模型和階段類驅動可操作任務為中心的實用RUP方法,并結合MDA指出了科學選擇UML建模工具的指導思想。
UML;可伸縮迭代—遞增模型;RUP;實用方法
1997年推出的UML為面向對象軟件開發技術提供了形式化建模語言,UML提供了建模的圖符及其語義等相關內容的詳細規定,但是,它僅是語言,而不是方法[1],它們像漢語詞匯與文章寫作的關系。實際中如何高效地使用UML,仍存在一些模糊認識。所以,為了全面地認識、正確地應用UML,需要深入探討與分析建模過程。
傳統軟件工程中結構化設計的思想對于軟件開發人員的影響比較深刻,軟件開發思路大多還是遵循結構化分析、設計與結構化編程(SA|SD|SP)的思想。盡管面向對象分析、設計、編程(OOA|OOD|OOP)的思想早已深入人心,但是,實際應用還不盡然。UML作為面向對象軟件開發的標準建模語言也遭遇了同樣的情況,易出現新工具老用的現象,進而不能發揮應有的作用。
1.1 以結構化范型應用UML
結構化范型以數據詞典為驅動[2],具有清晰的軟件生命周期階段劃分,即需求、分析、設計、實現、維護、退役6個階段[3]。瀑布模型為典型生命周期模型,實際中很可能以此為指導思想使用UML,表現如下:
(1)分析階段解決做什么的問題,主要分析系統工作流程以及涉及的數據,產生相關文字資料及代表性的數據流圖(DFD)和實體關系圖(ER);套用UML,僅使用用例圖(對SA的應數據流圖)。
(2)設計階段分為概要、詳細設計,解決怎么做的問題。重點在于規劃軟件的具體實現,除了文字說明資料外,最富代表性的圖為功能模塊圖、流程圖;套用UML,常照搬功能圖,附加上用活動圖(等價于SD的流程圖)。
(3)后兩個階段為具體的實現階段,沒有太正規的文檔資料。80年代由于大量面向對象可視化編程工具的使用(如C ++,JAVA,DELPHI等),OOP隨即被人們所熟知、推崇[4]。但是,因為習慣于結構化編程思路,人們至今常常還在被動使用類、對象的概念,并沒有或很少去主動地構建系統本身的類,只是在語言工具提供的組件對象中添加事件,更改其屬性從而實現系統功能。
至于UML其他圖由于沒有設立類而無法使用。在實現階段,UML的出現并沒有改變以上現狀。用這種方式使用UML是牽強的。
1.2 以面向對象的思想應用UML,但不遵循規范的過程方法
面向對象開發以用例圖為驅動,已被證明是當前最有效的開發方式[5]。使用面向對象的思想肯定要建立類,因此,能充分使用UML靜態、動態圖,以各種視角完善建模系統。
但是,面向對象較傳統軟件開發是復雜的,UML內容是龐大的,如果沒有規范的過程方法指導,可能UML圖會隨心所欲使用,缺乏條理性、邏輯理性、目的性,達不到準確、全面描述系統的目的,人為增加開發復雜性。許多介紹UML使用的案例也存在不明確過程方法、階段性任務和最終目的不明確等問題,不能正確引導使用。此種使用雖較前者有很大進步,但仍不夠科學,沒有發揮UML的利用率。
2.1 全面認識面向對象范型
首先,必須對采納UML的軟件開發范型有全面、深入地認識,明確使用UML的指導思想和價值。當前最先進的軟件開發技術與傳統范型的系統對比見表1。
2.2 使用UML要遵循科學、規范的軟件開發過程
2.2.1 UML與RUP統一過程相結合
軟件工程的目的是高效率、高效益生產正確、可靠并滿足用戶要求的軟件。軟件過程是軟件工程的重心。當今,流行的面向對象軟件過程是1999年 Rational公司的統一過程(RUP),由前Rational公司三位著名的高級管理人員Jacobson、Booch、Rumbaught提出,其集成了其他面向對象方法的優點,并經過實踐證明,對于不同過程具有自適應性。包括開始、細化、構建、移交四個階段,采用最符合人類解決問題方式的迭代——遞增周期模型,每階段都有明確的階段性任務,要建立翔實的文檔、UML模型[6]。

表1 結構化和面向對象范型的對比
Gartner公司的Dugguan警告說:“要記住,UML只是一種符號,并不是什么方法論。”要發揮UML的利用率,解決以上2節中的問題,需UML與RUP統一過程相結合。它們之間關系為RUP的操作需借助于UML表達,UML科學、合理的使用必須借助RUP支撐。
2.2.2 統一過程的實用實施方法
統一過程并不是一系列具體的操作步驟,而是包括方法學(生命周期模型)、技術、工具、人的復雜綜合性學科。全面了解、應用RUP是困難的,所以,需要對其精要進行總結、提煉,實際中指導軟件開發。
統一過程實用實施方法主要包括:軟件生命周期模型的選擇和可操作性階段任務。
軟件生命周期模型的選擇,可伸縮迭代—遞增模型如圖1,瀑布模型是成功的傳統模型,它是迭代而不遞增的,迭代—遞增模型可以說是瀑布模型與遞增模型的有機融合。
可操作性階段任務,類驅動建模過程。從圖1可以看出幾乎每一遞增階段都涉及生命周期的所有階段,只是工作側重點不同。具體操作其實隱含著一條線:需求描述—分析類—設計類—實現類,其實際區別如圖2,每階段具體操作概括為:
1.以用戶角度,建立商業模型。主要反映系統實際情況與用戶溝通捕獲需求,全面建模系統,其中以用例圖為代表。
2.以開發人員角度,建立分析模型(中心分析類)。
a)用例圖內容分組(包),添加設計所需包。(可選)
b)根據前階段的系統描述,提取名詞為類,并分為邊界、控制、實體類。
c)提取類的屬性、操作的概要信息。確定分析類之間的關系,建立系統以分析類為基礎的靜態、動態描述圖(包圖注意包的內聚、耦合性)。
注:模型中多自然語言標示。

圖1 可伸縮迭代—遞增模型
3.建立系統詳細、可操作的設計模型(中心設計類)。
a)體系結構設計。規劃系統軟件制品對應的構件圖和硬件設置相關的部署圖。
b)由分析類建立設計類。模型中所有命名程序性標準化 ,屬性細化到類型、長度描述,操作具體到可程序化的要求(活動圖、狀態圖),建立系統以設計類為基礎的靜態、動態描述圖。
注:模型中多程序性語言標示。
4.把設計類轉化為具體編程語言相關的實現類,實現軟件制品。
5.構建測試模型,測試實現。

圖2 分析類—設計類—實現類
2.3 樹立MDA思想,合理選擇UML工具
很多人認為系統開發就是編碼,當前又出現極限編程新倡導。RUP要求建立詳盡的系統模型,如果這些模型只用于交流目的,就會失去建立UML模型的誘惑力,阻礙使用UML的主觀能動性。MDA模型驅動體系架構是當前軟件業的熱點之一,倡導UML模型的自動生成性。UML2支持MDA的特性,軟件架構師Shaun·Forgie認為,UML2.0版本是模型驅動開發時代到來的號角。建模文件不再是負擔,由模型自動得到執行系統,這是使用UML的真正動力。
但是,MDA還處于新生階段,實現此目標需真正支撐MDA工具的出現,目前,嚴格地說沒有此種工具,大部分是支持生成代碼框架。但是,僅此也可以減輕工作量,提高系統開發效率、效益,且長遠收益是巨大的(軟件架構師Shaun·Forgie說,“模型驅動架構已經使我節省了50%的開發工作量)。
使用UML要樹立MDA思想,有意識地選擇支持MDA的恰當工具(如:IBM等奠基的Eclipse將成為全面實現這個復雜結構的第一個開發環境),提高UML模型的最大利用價值,增強使用UML建模系統的主動性。
科學實用的UML建模過程是復雜的工程,本文側重軟件開發本身,并沒有從管理學、經濟學等角度探討,同時提出的觀點需要在實踐中進一步發展提高。
[1]Ivar Jacobson,等.統一軟件開發之路[M].北京:機械工業出版社,2002:1-10.
[2]李芷,等.軟件工程方法與實踐[M].北京:電子工業出版社,2004:20-30.
[3][5]Stephen R.Schach面向對象與傳統軟件工程:統一過程的理論與實踐[M].北京:機械工業出版社,2006:159-160.
[4]殷兆麟.UML及其建模工具的使用[M].北京:清華大學出版社,2004:1-10.
[6]Per Kroll,Philippe Kruchten.Rational統一過程:實踐者指南[M].北京:中國電力出版社,2004:1-10.20-40.
(責任編輯:潘 敏)
Research on the Scientifically Modeling System with UML
Feng Fuxia,Li Sengui
(Anhui Engineering Technological College,Wuhu Anhui 241000)
In this papaer,the practical mistake about UML usage is analyzed deeply,useful approach aiming at the mistake is given,which is the flexible iterative-increasing model and driven-class phase manipulability tasks.At last, based on MDA,the guidance about the scientific choice on UML tool is given.
UML;flexible iterative-increasing model;RUP;useful approach
2009-11-11
馮富霞(1974-),女(漢族),河北獻縣人,安徽工程科技學院計算機科學與工程系講師,碩士研究生.
TP312 文獻標識碼:A 文章編號:1009-2080(2010)02-0087-03