標籤: 暫無標籤

統一建模語言(UML是 Unified Modeling Language的縮寫)是用來對軟體密集系統進行可視化建模的一種語言。UML為面向對象開發系統的產品進行說明、可視化、和編製文檔的一種標準語言。

統一建模語言 (UML)是非專利的第三代建模和規約語言。 UML是在開發階段,說明,可視化,構建和書寫一個面向對象軟體密集系統的製品的開放方法。UML展現了一系列最佳工程實踐,這些最佳實踐在對大規模,複雜系統進行建模方面,特別是在軟體架構層次已經被驗證有效

UMLUML

UML可以貫穿軟體開發周期中的每一個階段。被OMG採納作為業界的標準。UML最適於數據建模,業務建模,對象建模,組件建模。

UML作為一種模型語言,它使開發人員專註於建立產品的模型和結構,而不是選用什麼程序語言和演算法實現。當模型建立之後,模型可以被UML工具轉化成指定的程序語言代碼。


1 UML -簡要介紹


回顧20世紀晚期--準確地說是1997年,OMG組織(Object Management Group對象管理組織)發布了統一建模語言(Unified Modeling Language,UML)。UML的目標之一就是為開發團隊提供標準通用的設計語言來開發和構建計算機應用。UML提出了一套IT專業人員期待多年的統一的標準建模符號。通過使用UML,這些人員能夠閱讀和交流系統架構和設計規劃--就像建築工人多年來所使用的建築設計圖一樣。

到了21世紀--準確地說是2003年,UML已經獲得了業界的認同。在所見過的專業人員的簡歷中,75%都聲稱具備UML的知識。然而,在同絕大多數求職人員面談之後,可以明顯地看出他們並不真正了解UML。通常地,他們將UML用作一個術語,或對UML一知半解。大家對UML缺乏理解的這種狀況,促進我撰寫這篇關於UML 1.4的快速入門文章。當閱讀完本文時,您還不具備足夠的知識可以在簡歷上聲稱自己掌握了UML,但是您已具有了進一步鑽研該語言的良好起點。

一些背景知識

正如前面曾提到過的,UML的本意是要成為一種標準的統一語言,使得IT專業人員能夠進行計算機應用程序的建模。UML的主要創始人是Jim Rumbaugh、Ivar Jacobson和Grady Booch,他們最初都有自己的建模方法(OMT、OOSE和Booch),彼此之間存在著競爭。最終,他們聯合起來創造了一種開放的標準。(聽起來是不是很熟悉?這個現象類似J2EE、SOAP和Linux的誕生。)UML成為"標準"建模語言的原因之一在於,它與程序設計語言無關。(IBM Rational的UML建模工具被廣泛應用於J2EE和.NET開發。)而且,UML符號集只是一種語言而不是一種方法學。這點很重要,因為語言與方法學不同,它可以在不做任何更改的情況下很容易地適應任何公司的業務運作方式。

既然UML不是一種方法學,它就不需要任何正式的工作產品(即IBM Rational Unified Process?術語中所定義的"工件")。而且它還提供了多種類型的模型描述圖(diagram),當在某種給定的方法學中使用這些圖時,它使得開發中的應用程序的更易理解。UML的內涵遠不只是這些模型描述圖,但是對於入門來說,這些圖對這門語言及其用法背後的基本原理提供了很好的介紹。通過把標準的UML圖放進您的工作產品中,精通UML的人員就更加容易加入您的項目並迅速進入角色。最常用的UML圖包括:用例圖、類圖、序列圖、狀態圖、活動圖、組件圖和部署圖。

用例圖

用例圖描述了系統提供的一個功能單元。用例圖的主要目的是幫助開發團隊以一種可視化的方式理解系統的功能需求,包括基於基本流程的"角色"(actors,也就是與系統交互的其他實體)關係,以及系統內用例之間的關係。用例圖一般表示出用例的組織關係--要麼是整個系統的全部用例,要麼是完成具有功能(例如,所有安全管理相關的用例)的一組用例。要在用例圖上顯示某個用例,可繪製一個橢圓,然後將用例的名稱放在橢圓的中心或橢圓下面的中間位置。要在用例圖上繪製一個角色(表示一個系統用戶),可繪製一個人形符號。角色和用例之間的關係使用簡單的線段來描述,如圖1所示。

UML圖1:示例用例圖



















圖字(從上到下):CD銷售系統;查看樂隊CD的銷售統計;樂隊經理;查看Billboard 200排行榜報告;唱片經理;查看特定CD的銷售統計;檢索最新的Billboard 200排行榜報告;排行榜報告服務

用例圖通常用於表達系統或者系統範疇的高級功能。如圖1所示,可以很容易看出該系統所提供的功能。這個系統允許樂隊經理查看樂隊CD的銷售統計報告以及Billboard 200排行榜報告。它也允許唱片經理查看特定CD的銷售統計報告和這些CD在Billboard 200排行榜的報告。這個圖還告訴我們,系統將通過一個名為"排行榜報告服務"的外部系統提供Billboard排行榜報告。

此外,在用例圖中,沒有列出的用例表明了該系統尚未完成的功能。例如,它不能提供給樂隊經理收聽Billboard 200上不同專輯歌曲的途徑 -- 也就是說,系統沒有引用一個叫做"收聽Billboard 200上的歌曲"的用例。在用例圖中提供清晰、簡要的用例描述,項目贊助商或是需求者就很容易看出系統是否提供了必須的功能。

類圖

類圖表示不同的實體(人、事物和數據)如何彼此相關;換句話說,它顯示了系統的靜態結構。類圖可用於表示邏輯類,邏輯類通常就是業務人員所談及的事物種類--搖滾樂隊、CD、廣播劇;或者貸款、住房抵押、汽車信貸以及利率。類圖還可用於表示實現類,實現類就是程序員處理的實體。實現類圖或許會與邏輯類圖顯示一些相同的類。然而,實現類圖不會使用相同的屬性來描述,因為它很可能具有對諸如Vector和HashMap這種事物的引用。

類在類圖上使用包含三個部分的矩形來描述,如圖2所示。最上面的部分顯示類的名稱,中間部分包含類的屬性,最下面的部分包含類的操作(或者說"方法")。

UMLUML





圖2:類圖中的示例類對象

根據經驗,幾乎每個開發人員都知道這個類圖是什麼,但是我發現大多數程序員都不能正確地描述類的關係。對於像圖3這樣的類圖,您應該使用帶有頂點指向父類的箭頭的線段來繪製繼承關係1,並且箭頭應該是一個完全的三角形。如果兩個類都彼此知道對方,則應該使用實線來表示關聯關係;如果只有其中一個類知道該關聯關係,則使用開箭頭表示。

UMLUML







圖3:一個完整的類圖,包括了圖2所示的類對象

在圖3中,我們同時看到了繼承關係和兩個關聯關係。CDSalesReport類繼承自Report類。一個CDSalesReport類與一個CD類關聯,但是CD類並不知道關於CDSalesReport類的任何信息。CD類和Band類都彼此知道對方,兩個類彼此都可以與一個或者多個對方類相關聯。

序列圖

序列圖顯示具體用例(或者是用例的一部分)的詳細流程。它幾乎是自描述的,並且顯示了流程中不同對象之間的調用關係,同時還可以很詳細地顯示對不同對象的不同調用。

序列圖有兩個維度:垂直維度以發生的時間順序顯示消息/調用的序列;水平維度顯示消息被發送到的對象實例。

序列圖的繪製非常簡單。橫跨圖的頂部,每個框(參見圖4)表示每個類的實例(對象)。在框中,類實例名稱和類名稱之間用空格/冒號/空格來分隔,例如,myReportGenerator : ReportGenerator。如果某個類實例向另一個類實例發送一條消息,則繪製一條具有指向接收類實例的開箭頭的連線,並把消息/方法的名稱放在連線上面。對於某些特別重要的消息,您可以繪製一條具有指向發起類實例的開箭頭的虛線,將返回值標註在虛線上。就我而言,我總喜歡繪製出包括返回值的虛線,這些額外的信息可以使得序列圖更易於閱讀。

閱讀序列圖也非常簡單。從左上角啟動序列的"驅動"類實例開始,然後順著每條消息往下閱讀。記住:雖然圖4所示的例子序列圖顯示了每條被發送消息的返回消息,但這只是可選的。

UML圖4:一個示例序列圖














通過閱讀圖4中的示例序列圖,您可以明白如何創建一個CD銷售報告(CD Sales Report)。其中的aServlet對象表示驅動類實例。aServlet向名為gen的ReportGenerator類實例發送一條消息。該消息被標為generateCDSalesReport,表示ReportGenerator對象實現了這個消息處理程序。進一步理解可發現,generateCDSalesReport消息標籤在括弧中包括了一個cdId,表明aServlet隨該消息傳遞一個名為cdId的參數。當gen實例接收到一條generateCDSalesReport消息時,它會接著調用CDSalesReport類,並返回一個aCDReport的實例。然後gen實例對返回的aCDReport實例進行調用,在每次消息調用時向它傳遞參數。在該序列的結尾,gen實例向它的調用者aServlet返回一個aCDReport。

請注意:圖4中的序列圖相對於典型的序列圖來說太詳細了。然而,我認為它才是足夠易於理解的,並且它顯示了如何表示嵌套的調用。對於初級開發人員來說,有時把一個序列分解到這種詳細程度是很有必要的,這有助於他們理解相關的內容。

狀態圖
狀態圖表示某個類所處的不同狀態和該類的狀態轉換信息。有人可能會爭論說每個類都有狀態,但不是每個類都應該有一個狀態圖。只對"感興趣的"狀態的類(也就是說,在系統活動期間具有三個或更多潛在狀態的類)才進行狀態圖描述。

如圖5所示,狀態圖的符號集包括5個基本元素:初始起點,它使用實心圓來繪製;狀態之間的轉換,它使用具有開箭頭的線段來繪製;狀態,它使用圓角矩形來繪製;判斷點,它使用空心圓來繪製;以及一個或者多個終止點,它們使用內部包含實心圓的圓來繪製。要繪製狀態圖,首先繪製起點和一條指向該類的初始狀態的轉換線段。狀態本身可以在圖上的任意位置繪製,然後只需使用狀態轉換線條將它們連接起來。

UMLUML










圖5:顯示類通過某個功能系統的各種狀態的狀態圖

圖5中的狀態圖顯示了它們可以表達的一些潛在信息。例如,從中可以看出貸款處理系統最初處於Loan Application狀態。當批准前(pre-approval)過程完成時,根據該過程的結果,或者轉到Loan Pre-approved狀態,或者轉到Loan Rejected狀態。這個判斷(它是在轉換過程期間做出的)使用一個判斷點來表示--即轉換線條間的空心圓。通過該狀態圖可知,如果沒有經過Loan Closing狀態,貸款不可能從Loan Pre-Approved狀態進入Loan in Maintenance狀態。而且,所有貸款都將結束於Loan Rejected或者Loan in Maintenance狀態。

活動圖

活動圖表示在處理某個活動時,兩個或者更多類對象之間的過程式控制制流。活動圖可用於在業務單元的級別上對更高級別的業務過程進行建模,或者對低級別的內部類操作進行建模。根據我的經驗,活動圖最適合用於對較高級別的過程建模,比如公司當前在如何運作業務,或者業務如何運作等。這是因為與序列圖相比,活動圖在表示上"不夠技術性的",但有業務頭腦的人們往往能夠更快速地理解它們。

活動圖的符號集與狀態圖中使用的符號集類似。像狀態圖一樣,活動圖也從一個連接到初始活動的實心圓開始。活動是通過一個圓角矩形(活動的名稱包含在其內)來表示的。活動可以通過轉換線段連接到其他活動,或者連接到判斷點,這些判斷點連接到由判斷點的條件所保護的不同活動。結束過程的活動連接到一個終止點(就像在狀態圖中一樣)。作為一種選擇,活動可以分組為泳道(swimlane),泳道用於表示實際執行活動的對象,如圖6所示。

UMLUML























圖6:活動圖,具有兩個泳道,表示兩個對象的活動控制:樂隊經理,以及報告工具

圖字(沿箭頭方向):樂隊經理;報告工具;選擇"查看樂隊的銷售報告";檢索該樂隊經理所管理的樂隊;顯示報告條件選擇屏幕;選擇要查看其銷售報告的樂隊;從銷售資料庫檢索銷售數據;顯示銷售報告。

該活動圖中有兩個泳道,因為有兩個對象控制著各自的活動:樂隊經理和報告工具。整個過程首先從樂隊經理選擇查看他的樂隊銷售報告開始。然後報告工具檢索並顯示他管理的所有樂隊,並要求他從中選擇一個樂隊。在樂隊經理選擇一個樂隊之後,報告工具就檢索銷售信息並顯示銷售報告。該活動圖表明,顯示報告是整個過程中的最後一步。

組件圖
組件圖提供系統的物理視圖。它的用途是顯示系統中的軟體對其他軟體組件(例如,庫函數)的依賴關係。組件圖可以在一個非常高的層次上顯示,從而僅顯示粗粒度的組件,也可以在組件包層次2上顯示。

組件圖的建模最適合通過例子來描述。圖7顯示了4個組件:Reporting Tool、Billboard Service、Servlet 2.2 API和JDBC API。從Reporting Tool組件指向Billboard Service、Servlet 2.2 API和JDBC API組件的帶箭頭的線段,表示Reporting Tool依賴於那三個組件。

UMLUML



圖7:組件圖顯示了系統中各種軟體組件的依賴關係


部署圖

部署圖表示該軟體系統如何部署到硬體環境中。它的用途是顯示該系統不同的組件將在何處物理地運行,以及它們將如何彼此通信。因為部署圖是對物理運行情況進行建模,系統的生產人員就可以很好地利用這種圖。

部署圖中的符號包括組件圖中所使用的符號元素,另外還增加了幾個符號,包括節點的概念。一個節點可以代表一台物理機器,或代表一個虛擬機器節點(例如,一個大型機節點)。要對節點進行建模,只需繪製一個三維立方體,節點的名稱位於立方體的頂部。所使用的命名約定與序列圖中相同:[實例名稱] : [實例類型](例如,"w3reporting.myco.com : Application Server")。

UMLUML
 







圖8:部署圖。由於Reporting Tool組件繪製在IBM WebSphere內部,後者又繪製在節點w3.reporting.myco.com內部,因而我們知道,用戶將通過運行在本地機器上的瀏覽器來訪問Reporting Tool,瀏覽器通過公司intranet上的HTTP協議與Reporting Tool建立連接。

圖8中的部署圖表明,用戶使用運行在本地機器上的瀏覽器訪問Reporting Tool,並通過公司intranet上的HTTP協議連接到Reporting Tool組件。這個工具實際運行在名為w3reporting.myco.com的Application Server上。這個圖還表明Reporting Tool組件繪製在IBM WebSphere內部,後者又繪製在w3.reporting.myco.com節點內部。Reporting Tool使用Java語言通過IBM DB2資料庫的JDBC介面連接到它的報告資料庫上,然後該介面又使用本地DB2通信方式,與運行在名為db1.myco.com的伺服器上實際的DB2資料庫通信。除了與報告資料庫通信外,Report Tool組件還通過HTTPS上的SOAP與Billboard Service進行通信。

2 UML -語言出現


公認的面向對象建模語言出現於70年代中期。從1989年到1994年,其數量從不到十種增加到了五十多種。在眾多的建模語言中,語言的創造者努力推崇自己的產品,並在實踐中不斷完善。但是,OO方法的用戶並不了解不同建模語言的優缺點及相互之間的差異,因而很難根據應用特點選擇合適的建模語言,於是爆發了一場「方法大戰」。90年代中,一批新方法出現了,其中最引人注目的是Booch 1993、OOSE和OMT-2等。  

Booch是面向對象方法最早的倡導者之一,他提出了面向對象軟體工程的概念。1991年,他將以前面向Ada的工作擴展到整個面向對象設計領域。Booch 1993比較適合於系統的設計和構造。   

Rumbaugh等人提出了面向對象的建模技術(OMT)方法,採用了面向對象的概念,並引入各種獨立於語言的表示符。這種方法用對象模型、動態模型、功能模型和用例模型,共同完成對整個系統的建模,所定義的概念和符號可用於軟體開發的分析、設計和實現的全過程,軟體開發人員不必在開發過程的不同階段進行概念和符號的轉換。OMT-2特別適用於分析和描述以數據為中心的信息系統。  

Jacobson於1994年提出了OOSE方法,其最大特點是面向用例(Use-Case),並在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器,但用例貫穿於整個開發過程,包括對系統的測試和驗證。OOSE比較適合支持商業工程和需求分析。  

此外,還有Coad/Yourdon方法,即著名的OOA/OOD,它是最早的面向對象的分析和設計方法之一。該方法簡單、易學,適合於面向對象技術的初學者使用,但由於該方法在處理能力方面的局限,目前已很少使用。 

概括起來,首先,面對眾多的建模語言,用戶由於沒有能力區別不同語言之間的差別,因此很難找到一種比較適合其應用特點的語言;其次,眾多的建模語言實際上各有千秋;第三,雖然不同的建模語言大多雷同,但仍存在某些細微的差別,極大地妨礙了用戶之間的交流。因此在客觀上,極有必要在精心比較不同的建模語言優缺點及總結面向對象技術應用實踐的基礎上,組織聯合設計小組,根據應用需求,取其精華,去其糟粕,求同存異,統一建模語言。  

1994年10月,Grady Booch和Jim Rumbaugh開始致力於這一工作。他們首先將Booch 93和OMT-2 統一起來,並於1995年10月發布了第一個公開版本,稱之為統一方法UM 0.8(Unitied Method)。1995年秋,OOSE 的創始人Ivar Jacobson加盟到這一工作。經過Booch、Rumbaugh和Jacobson三人的共同努力,於1996年6月和10月分別發布了兩個新的版本,即UML 0.9和UML 0.91,並將UM重新命名為UML(Unified Modeling Language)。
  
1996年,一些機構將UML作為其商業策略已日趨明顯。UML的開發者得到了來自公眾的正面反應,並倡議成立了UML成員協會,以完善、加強和促進UML的定義工作。當時的成員有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI以及Unisys。這一機構對UML 1.0(1997年1月)及UML 1.1(1997年11月17日)的定義和發布起了重要的促進作用。  

UML是一種定義良好、易於表達、功能強大且普遍適用的建模語言。它溶入了軟體工程領域的新思想、新方法和新技術。它的作用域不限於支持面向對象的分析與設計,還支持從需求分析開始的軟體開發的全過程。  

面向對象技術和UML的發展過程可用圖形來表示,標準建模語言的出現是其重要成果。在美國,截止1996年10月,UML獲得了工業界、科技界和應用界的廣泛支持,已有700多個公司表示支持採用UML作為建模語言。1996年底,UML已穩佔面向對象技術市場的85%,成為可視化建模語言事實上的工業標準。1997年11月17日,OMG採納UML 1.1作為基於面向對象技術的標準建模語言。UML代表了面向對象方法的軟體開發技術的發展方向,具有巨大的市場前景,也具有重大的經濟價值和國防價值。 

UML是一個標準的圖形表示法,它不是面向對象的分析和設計,也不是一種方法,它僅僅是一組符號而已。

UML是一種定義良好、易於表達、功能強大且普遍適用的建模語言。它溶入了軟體工程領域的新思想、新方法和新技術。它的作用域不限於支持面向對象的分析與設計,還支持從需求分析開始的軟體開發的全過程。  

面向對象技術和UML的發展過程可用上圖來表示,標準建模語言的出現是其重要成果。在美國,截止1996年10月,UML獲得了工業界、科技界和應用界的廣泛支持,已有700多個公司表示支持採用UML作為建模語言。1996年底,UML已穩佔面向對象技術市場的85%,成為可視化建模語言事實上的工業標準。1997年11月17日,OMG採納UML 1.1作為基於面向對象技術的標準建模語言。UML代表了面向對象方法的軟體開發技術的發展方向,具有巨大的市場前景,也具有重大的經濟價值和國防價值。


3 UML -語言內容



首先,UML融合了Booch、OMT和OOSE方法中的基本概念,而且這些基本概念與其他面向對象技術中的基本概念大多相同,因而,UML必然成為這些方法以及其他方法的使用者樂於採用的一種簡單一致的建模語言;其次,UML不僅僅是上述方法的簡單匯合,而是在這些方法的基礎上廣泛徵求意見,集眾家之長,幾經修改而完成的,UML擴展了現有方法的應用範圍;第三,UML是標準的建模語言,而不是標準的開發過程。儘管UML的應用必然以系統的開發過程為背景,但由於不同的組織和不同的應用領域,需要採取不同的開發過程。  

作為一種建模語言,UML的定義包括UML語義和UML表示法兩個部分。  
(1)UML語義描述基於UML的精確元模型定義。元模型為UML的所有元素在語法和語義上提供了簡單、一致、通用的定義性說明,使開發者能在語義上取得一致,消除了因人而異的最佳表達方法所造成的影響。此外UML還支持對元模型的擴展定義。 
(2)UML表示法定義UML符號的表示法,為開發者或開發工具使用這些圖形符號和文本語法為系統建模提供了標準。這些圖形符號和文字所表達的是應用級的模型,在語義上它是UML元模型的實例。  

標準建模語言UML的重要內容可以由下列五類圖(共9種圖形)來定義:  

第一類是用例圖,從用戶角度描述系統功能,並指出各功能的操作者。  

第二類是靜態圖 (Static diagram),包括類圖、對象圖和包圖。其中類圖描述系統中類的靜態結構。不僅定義系統中的類,表示類之間的聯繫如關聯、依賴、聚合等,也包括類的內部結構(類的屬性和操作)。類圖描述的是一種靜態關係,在系統的整個生命周期都是有效的。  

對象圖是類圖的實例,幾乎使用與類圖完全相同的標識。他們的不同點在於對象圖顯示類的多個對象實例,而不是實際的類。一個對象圖是類圖的一個實例。由於對象存在生命周期,因此對象圖只能在系統某一時間段存在。  

包由包或類組成,表示包與包之間的關係。包圖用於描述系統的分層結構。  

第三類是行為圖(Behavior diagram),描述系統的動態模型和組成對象間的交互關係。其中狀態圖描述類的

UMLUML
對象所有可能的狀態以及事件發生時狀態的轉移條件。通常,狀態圖是對類圖的補充。在實用上並不需要為所有的類畫狀態圖,僅為那些有多個狀態其行為受外界環境的影響並且發生改變的類畫狀態圖。

而活動圖描述滿足用例要求所要進行的活動以及活動間的約束關係,有利於識別并行活動。  

第四類是交互圖(Interactive diagram),描述對象間的交互關係。其中順序圖顯示對象之間的動態合作關係,它強調對象之間消息發送的順序,同時顯示對象之間的交互;合作圖描述對象間的協作關係,合作圖跟順序圖相似,顯示對象間的動態合作關係。除顯示信息交換外,合作圖還顯示對象以及它們之間的關係。如果強調時間和順序,則使用順序圖;如果強調上下級關係,則選擇合作圖。這兩種圖合稱為交互圖。  

第五類是實現圖 ( Implementation diagram )。其中構件圖描述代碼部件的物理結構及各部件之間的依賴關係。一個部件可能是一個資源代碼部件、一個二進位部件或一個可執行部件。它包含邏輯類或實現類的有關信息。部件圖有助於分析和理解部件之間的相互影響程度。  

配置圖定義系統中軟硬體的物理體系結構。它可以顯示實際的計算機和設備(用節點表示)以及它們之間的連接關係,也可顯示連接的類型及部件之間的依賴性。在節點內部,放置可執行部件和對象以顯示節點跟可執行軟體單元的對應關係。  

從應用的角度看,當採用面向對象技術設計系統時,首先是描述需求;其次根據需求建立系統的靜態模型,以構造系統的結構;第三步是描述系統的行為。其中在第一步與第二步中所建立的模型都是靜態的,包括用例圖、類圖(包含包)、對象圖、組件圖和配置圖等五個圖形,是標準建模語言UML的靜態建模機制。其中第三步中所建立的模型或者可以執行,或者表示執行時的時序狀態或交互關係。它包括狀態圖、活動圖、順序圖和合作圖等四個圖形,是標準建模語言UML的動態建模機制。因此,標準建模語言UML的主要內容也可以歸納為靜態建模機制和動態建模機制兩大類。

4 UML -主要特點



標準建模語言UML的主要特點可以歸結為三點:  

(1) UML統一了Booch、OMT和OOSE等方法中的基本概念。
  
(2) UML還吸取了面向對象技術領域中其他流派的長處,其中也包括非OO方法的影響。UML符號表示考慮了各種方法的圖形表示,刪掉了大量易引起混亂的、多餘的和極少使用的符號,也添加了一些新符號。因此,在UML中匯入了面向對象領域中很多人的思想。這些思想並不是UML的開發者們發明的,而是開發者們依據最優秀的OO方法和豐富的計算機科學實踐經驗綜合提煉而成的。

(3)UML在演變過程中還提出了一些新的概念。在UML標準中新加了模板(Stereotypes)、職責(Responsibilities)、擴展機制(Extensibility mechanisms)、線程(Threads)、過程(Processes)、分散式(Distribution)、併發(Concurrency)、模式(Patterns)、合作(Collaborations)、活動圖(Activity diagram)等新概念,並清晰地區分類型(Type)、類(Class)和實例(Instance)、細化(Refinement)、介面(Interfaces)和組件(Components)等概念。

因此可以認為,UML是一種先進實用的標準建模語言,但其中某些概念尚待實踐來驗證,UML也必然存在一個進化過程。 

5 UML -應用領域

      
UML的目標是以面向對象圖的方式來描述任何類型的系統,具有很寬的應用領域。其中最常用的是建立軟體系統的模型,但它同樣可以用於描述非軟體領域的系統,如機械系統、企業機構或業務過程,以及處理複雜數據的信息系統、具有實時要求的工業系統或工業過程等。總之,UML是一個通用的標準建模語言,可以對任何具有靜態結構和動態行為的系統進行建模。 
      
此外,UML適用於系統開發過程中從需求規格描述到系統完成後測試的不同階段。在需求分析階段,可以用用例來捕獲用戶需求。通過用例建模,描述對系統感興趣的外部角色及其對系統(用例)的功能要求。分析階段主要關心問題域中的主要概念(如抽象、類和對象等)和機制,需要識別這些類以及它們相互間的關係,並用UML類圖來描述。為實現用例,類之間需要協作,這可以用UML動態模型來描述。在分析階段,只對問題域的對象(現實世界的概念)建模,而不考慮定義軟體系統中技術細節的類(如處理用戶介面、資料庫、通訊和并行性等問題的類)。這些技術細節將在設計階段引入,因此設計階段為構造階段提供更詳細的規格說明。  
      
編程(構造)是一個獨立的階段,其任務是用面向對象編程語言將來自設計階段的類轉換成實際的代碼。在用UML建立分析和設計模型時,應盡量避免考慮把模型轉換成某種特定的編程語言。因為在早期階段,模型僅僅是理解和分析系統結構的工具,過早考慮編碼問題十分不利於建立簡單正確的模型。
      
UML模型還可作為軟體測試階段的依據。系統通常需要經過單元測試、集成測試、系統測試和驗收測試。不同的測試小組使用不同的UML圖作為測試依據:單元測試使用類圖和類規格說明;集成測試使用部件圖和合作圖;系統測試使用用例圖來驗證系統的行為;驗收測試由用戶進行,以驗證系統測試的結果是否滿足在分析階段確定的需求。  

總之,標準建模語言UML適用於以面向對象技術來描述任何類型的系統,而且適用於系統開發的不同階段,從需求規格描述直至系統完成後的測試和維護。

6 UML -UML建模軟體

UML建模軟體是指實現UML建模語言建模功能的工具軟體。 最著名的UML建模工具是IBM Rational ROSE.另外,TeleOffice也是一款常用的建模工具. 還有很多開源的UML建模工具,如StarUML,ArgoUML,Umbrello等.對學慣用途來說,選擇開源的UML工具是合適的.對於企業應用,應該選擇商業的UML工具軟體,因為有更好的技術支持.
上一篇[勾股容方]    下一篇 [裸體話劇]

相關評論

同義詞:暫無同義詞