|
模型是現實系統的簡化。建模是對現實系統進行適當的過濾，用適當的表現規則描繪出簡潔的模型。通過模型，人們可以瞭解到所研究事物的本質，而且在形式上便於人們對之進行分析和處理。UML（統一建模語言）是一種通用的建模語言，它獲得了工業界和學術界的廣泛支持，目前已經成爲建模語言的標準。
1.1那麼什麼是模型呢？
模型是現實系統的簡化，它是抓住現實系統的主要方面而忽略次要方面的一種抽象。因此，模型即反映了現實系統，又不等同於該現實系統。模型是理解、分析、開發或改造現實系統的常用手段。模型和現實系統之間的關係如下：
![]()
由於人們對複雜性的東西認識有限，因此系統設計者在系統設計之初往往無法完全理解整個系統。此時人們就需要將系統建模。現實生活中也是如此，再建造一個大樓的時候往往要先畫設計圖紙。建模可以使設計者能夠從全局把握系統及內部的聯繫，而不至於陷入每個模塊的細節之中。模型可使具有複雜關係的信息簡單易懂，使人們容易洞察複雜堆砌而成的原始數據背後的規律，並能夠有效的人們將系統需求映射到軟件結構上。具體而言，模型的作用如下：
（1）模型可以促進項目有關人員對系統的理解和交流。模型對於問題的理、項目有關人員（客戶、領域專家、分析人員和設計人員等）之間的交流、文檔的準備以及程序和數據庫的設計等都非常有益。模型可使得人們直接研究一個大型的複雜軟件系統。建模促使人們對需求的理解，從而可得到更清楚的設計，進而得到更容易維護的系統。
（2）模型有助於挑選出代價較小的解決方案。再研究一個大型系統的軟件模型時，人們可以提出多個實際方案並對它們進行比較，然後挑選一個最好的解決方案。
（3）模型可以縮短開發週期。模型實際上是通過過濾掉一些不必要的細節而刻畫複雜問題或者結構的必要特效的抽象，它使得問題更容易理解。有了模型之後，軟件系統的開發就會變的較快，同時也降低了系統的開發成本。
爲了建立複雜的系統，開發人員必須先抽象出不同的視圖，並用精確的表示法來建立模型，最後在模型轉換爲實現中逐漸添加細節。如右圖所示，表示法、過程和工具是成功建模的3要素，三者缺一不可。如果建模人員瞭解表示法的含義，但不知道如何使用這些表示法（過程），那麼最終有可能會失敗；如果建模人員知道建模的過程，但不知道各個表示法的含義，那麼最終也可能會失敗；如果建模人員不能借助工具記錄下建模過程所得的各製品，那麼最後還是有可能會失敗。
![]()
1.2面向對象的軟件開發
在面向對象的程序設計方法出來之前，傳統的設計方法大都是面向過程的（少數是面向數據結構的）。面向過程的程序設計結構清晰，它是歷史上爲緩解軟件危機做出了貢獻。面向過程的程序設計方法是以功能分析爲基礎的，它強調自頂向下的功能分解，並或多或少的對功能進行分離。換言之，在採用這種方法開發系統時，不管是在模型設計中還是在現實系統實現中，數據和操作都是分開的。對用這種設計方法設計出的系統而言，模塊獨立性較差，模塊之間的耦合度較高，對一個模塊的修改可能會造成很多其它模塊功能上的改變。因此，系統的理解和維護都存在一定的難度。具體而言，面向過程的程序設計方法存在如下問題：
（1）操作和數據分離的軟件設計結構和人類（所認識）的現實環境很不一樣，和人的思維方式不相一致。因此，人們對現實世界的認識與程序之間設計之間存在一道理解上的鴻溝。
（2）系統是圍繞着如何實現一定行爲來進行的，當系統行爲易變，需要常常修改時，修改工作頗爲困難。因爲這類系統的結構是基於上層模塊必須掌控和控制下層模塊工作的前提的，因此在底層模塊變動時，常常會迫不得已改一些上層模塊，而這種一系列的上層模塊的修改不是當時變動底層模塊的目的。同樣，在需要修改上層模塊時，新的上層模塊也需要了解它的所有下層，編寫這樣的上層模塊當然頗爲困難。所以，這種結構無法適應迅猛變化的技術發展。
（3）在系統中模塊之間的控制作用有重要的影響時(亦即在實際的控制發生的根源來自分散的各個模塊之中時)，由於在“良好的模塊結構”中的模塊間的控制作用只能通過上下之間的關係調用關係來執行，這樣會造成信息路徑過長，效率低，易受干擾甚至出現錯誤。如果允許模塊間爲進行控制而直接進行通信，那麼結果是系統總體結構混亂，從而難於維護。所以，這種結構是無法適應以控制關係爲重要特性的系統要求的。
（4）用這種方法開發出來的系統往往難於維護，主要原因是所有的函數都必須知道數據結構。許多不同的數據類型的數據結構之間只有細微的差別。在這種情況下，函數中常常充滿了條件判斷，它們與函數的功能毫無關係，只是因爲數據結構的不同而不得不使用他們，結果使得程序變的非常難讀。
（5）自頂向下功能分解的分析方法大大的限制和降低了軟件的易用性，導致對同樣對象的大量重複性操作，從而降低了開發人員的生成率。
面向對象設計方法是對面向過程設計方法強有力的補充。面向對象的設計的方法是一種新型、實用的程序設計方法，它強調數據的抽象、易擴展性和代碼複用等軟件工程原則，特別有利於大型、複雜軟件系統的生成，因而被稱爲20世紀90年代的“結構化程序設計方法”。該方法的主要特徵在於支持數據抽象、封裝、繼承等概念。藉助數據抽象和封裝，可以抽象的定義對象的外部行爲而隱藏其實現細節，從而達到規約和實現的分離，有利於程序的理解、修改和維護。對系統原型速成和有效實現大有幫助；支持繼承則可以在原有的代碼上構建新的軟件模塊，從而有利於軟件的複用。在採用面向對象的程序設計方法開發系統時，系統實際上是由許多對象構成的集合。圖1-3形象的描繪了結構化程序的和麪向對象程序之間的主要差別。
![]()
面向對象程序設計語言可以直接、充分的支持面向對象程序設計方法，從而稱爲軟件開發的有力工具。在面向對象程序語言設計當中，對象由屬性和方法封裝而成。對象的行爲通過操作展示，外界不可以直接訪問其內部屬性，操作的實現對用戶透明。消息的傳遞是對象間唯一的交互方式，對象的創建和對象中操作的調用通過消息傳遞來完成。類是對具有相同內部狀態和外部行爲對象結構的描述，它定義了表示對象狀態的實例變量集和表示對象變量的方法集。類是待創建對象的模板，而對象則是類的實例。子類可以繼承父類的的實例變量和方法，同時還可以定義新的變量和方法。對象的分裝性降低了對象間的耦合度，從而使得程序的理解和修改變的容易。類之間的繼承機制使得易於在現有代碼基礎上爲系統增加新的功能。總之，可以把面向對象模型看作是一個由如下主要元素構成的概念框架：
- 抽象
- 封裝性
- 模塊化
- 層次性
- 併發性
- 類型化
- 持久化
- 易複用性
- 易擴展性
- 動態綁定
面向對象的軟件開發方法涉及從面向對象分析（OOA）-->面向對象設計(OOD)-->面向對象程序設計和編碼(OOP)-->面向對象測試(OOT)等一系列特定階段。面向對象設計方法期望獲得一種獨立於語言的設計和描述，以求達到從客觀世界中的事物原型到軟件系統間的的儘可能的平滑過渡。
面向對象的方法把功能和數據看作是高度統一的，其優點主要有：
（1）它能較好的處理軟件規模和複雜性不斷增加所帶來的問題。
（2）它更適合於控制關係複雜的系統。
（3）面向對象系統通過對象間的協作來完成任務，因而更容易管理。
（4）它使用各種直接模仿應用域中實體的抽象和對象，從而使得規約和設計更加完整。
（5）它圍繞對象和類進行局部化，從而提高規約、設計和代碼的易擴展性、易維護性和易複用性。
（6）簡化了開發者的工作，提高的軟件和文檔的質量。
當開發人員正確的使用了面向對象開發方法時，就能夠有效的降低軟件開發的成本，提高系統的易複用性、易擴展性、易維護性和易理解性。
1.3 面向對象的軟件建模
面向對象建模語言起始於20實際70年代中期。從1989年到1994年，其數量從不到10種迅速增加到50多種。各種建模語言的設計者都努力推崇自己的語言產品，並在實踐中不斷完善。然而，OO（面向對象）方法的用戶並不瞭解不同建模語言的優缺點以及相互之間的差異，因而很難根據應用 的特點選擇合適的建模語言。於是，爆發了一場“方法大戰”。
Booch是面向對象方法最早的倡導者之一，它提出了面向對象軟件工程的概念。1991年，它將以前所進行的面向Ada的工作擴展到整個面向對象設計領域。1993年，Booch對其之前的方法做了一些改進，使之適合系統的設計和構造。Booch在其OOAda中提出了面向對象的4個模型：邏輯視圖，物理視圖以及其相應的靜態和動態語義。對邏輯結構的靜態視圖，OOAda提供提供對象圖和類圖；對邏輯結構的動態視圖，OOAda提供的狀態變遷圖和交互圖；對於物理結構的靜態視圖，OOAda提供了模塊圖和進程圖。
Jacobson於1994年提出了面向對象的軟件工程（OOSE）方法，該方法的最大特點就是面向用案（User Case）。OOSE是由用案模型、域對象模型、分析模型、設計模型、實現模型和測試模型組成的。其中用案模型貫穿於整個開發過程，它驅動所有其它模型的開發。
Rumbaugh等人提出了OMT方法。在OMT方法中，系統是通過對象模型、動態模型和功能模型來描述的。其中，對象模型用來描述系統中各對象的靜態結構以及它們之間的關係；功能模型描述系統實現什麼功能（即捕獲系統所執行的計算），它通過數據流圖來描述如何由系統的輸入值得到輸出值。功能模型只能夠指出可能的功能計算路徑，而不能確定哪一條路線會實際發生。動態模型則描述系統在何時實現其它功能（控制流），每個類的動態部分都是由狀態圖來描繪的。
Coad和Yourdon提出了OOA/OOD方法。一個OOA模型由主題層、類及對象層、結構層、屬性層和服務層組成。其中，主題層描繪系統的劃分。類和對象層描述系統中的類和對象，結構層捕獲類和對象之間的繼承關係及整體-部分的關係，屬性層描述對象的屬性屬性和類及對象之間的關聯關係，服務層描述對象所提供的服務（即方法）和對象的消息鏈接。OOD模型由人機交互（界面）構件，問題域構件，任務管理構件和數據管理構件組成。
Fusion自認爲是“第二代”開發方法。它是在OMT方法、Objectory方法、形式話方法、CRC方法和Booch方法的基礎上開發的。面向複用/再工程以及基於複用/再工程的需求開發是Fusion的一大特點。Fusion方法中用於描述系統設計和分析的圖形雖然不多，但較全面。Fusion方法將開發過程劃分爲分析、設計和實現3個階段，每個階段由若干步驟組成，每一步驟的輸出都是下一步驟的輸入。
OL是Shlaer/Mellor重新修訂其先前開發的面向對象系統分析方法（OOSA）後所得到的一種建模方法。OL方法中的OOA使用了信息建模，狀態建模和進程建模技術。OOD中使用類圖、類結構圖、依賴圖和繼承圖對系統進行描述。
Martin與Odell提出的OOAD方法的理論基礎是邏輯和集合論。儘管面向對象的分析通常被劃分成結構（靜態）和行爲(動態)兩部分，但Martin與Odell的OOAD卻試圖將它們集成在一起。它們認爲面向對象分析的基礎應該是系統的行爲，系統的結構通過對系統行爲的分析而得到的。
1.4 統一的建模語言（UML）
UML是一種定義良好的、易於表達的、功能較強的且普遍適用的建模語言。它吸收了軟件工程領域的新思想，新方法和新技術。UML的應用領域相當廣泛，它不僅可以用於建立軟件系統的模型，同樣也可以描繪非軟件領域內的系統模型以及處理複雜數據的信息相同、具有實時要求的工業系統或工業過程等。
作爲一種通用的建模語言，UML適用於系統開發過程中從需求規約描述到系統完成後測試的不同階段。目前，UML已經成爲建模語言上的工業標準。
1.4.1 發展歷程
在UML問世之前，已經有不少人試圖將各種建模方法中的不同概念進行統一。其中Coleman和他的同事們曾努力統一OMT、Booch、CRC方法中的概念。但由於這些方法的原作者沒有參與到這項工作，其最後的結果是得到了一種新的建模方法，如圖1-4所示。UML語言開發始於1994年8月，當時Rational軟件公司的Booch和Rumbaugh着手進行統一的Booch方法和OMT方法，以便以後得到一種統一的建模語言。1995年10月，他們發佈了統一方法（UM）的初級版本。同年秋天，Jacobson加盟聯合開發小組，併力圖把OOSE方法也統一進來。
![]()
做爲Booch、OMT（對象建模技術）和OOSE方法的創始人，Booch、Rumbaugh和Jacobson決定開發UML有3個原因：首先，這些方法有很多相似之處，消除它們給使用者造成的混淆是非常有意義的；其次，語義和表示法的統一可穩定面向對象技術的市場，使得開發工程能採用一種成熟的建模語言；再次，統一工作可吸收先前各種建模方法中的優秀成果，以便解決以前沒有解決好的問題。
Booch、Rumbaugh和jacobson在着手統一工作時，制定瞭如下4個目標：
（1）使用面向對象的概念來構造系統的模型。
（2）建立設計框架和代碼直接的明確關係。
（3）解決複雜的、以任務爲中心的系統內在的規模問題。
（4）開發人與機器的通用的建模語言。
開發應用於面向對象的分析和設計的表示法並不像設計一種程序設計語言那麼簡單。首先，設計者要考慮表示法是不是應該能夠表達系統的開發需求，是不是要把表示法設計成形象化的語言。其次，設計者需要在表達能力和簡潔程度之間做出權衡，即過於簡單的表示法會限制應用的範圍，而過於複雜的表示法又會嚇到剛入門的使用者。如果設計者是在統一已有的一些方法，那麼還要照顧到過去的基礎，即改變過多會使原來的使用者感覺到混亂，不作改進，又難以吸引更多的使用者。UML的定義力圖在這幾個方面權衡利弊。
經過Booch、Rumbaugh和Jacobson的不懈努力，UML0.9和0.91版終於在1996年的6月和10月出版。1996年間，UML開發者們向各界虛心求教並收到來自社會各界的反饋。他們據此做了相應的改進，但顯然還有許多工作需要完成。同年，OMG（對象管理組）發佈了向外界徵集關於面向對象建模標準方法的消息。UML的3位創始人開始與來自其它公司的軟件工程方法專家和開發人員一道制定了一套OMG感興趣的方法，並設計了一種被軟件開發工具提供者、軟件開發方法學家和開發人員這些最終用戶接受的建模語言。於此同時，其它一些相關人員也在做這項富有競爭性的工作。1997年9月1日產生了UML1.1，並提交到OMG進行討論。
OMG於1997年11月正式接納了UML1.1，然後成立任務組不斷的修訂，併產生了UML1.2、1.3和1.4版本，其中UML1.3是較爲重要的修訂版本。目前，該組織正在對UML進行重大修訂，其目標是推出UML2.0，做爲向ISO提交的標準方案。許多軟件開發工具供應商聲稱他們的產品支持或計劃支持UML，軟件工程方法學家們也宣佈他們將使用UML的表示法進行以後的研究工作。UML的出現深受計算機界的歡迎，因爲它是由官方出面集中了許多專家的經驗而形成的，減少了各種軟件開發工具之間無謂的分歧。建模語言的標準化既能促進軟件開發人員廣泛使用面向對象的建模技術，同時也能帶來UML支持工具的培訓市場的繁榮，因爲不論是用戶還是供應商都不用再考慮到底應該採用哪一種開發方法。
總之，UML作爲一種建模語言，它具有一下幾個特點：
（1）UML統一了各種方法對不同類型的系統、不同開發階段以及不同內部概念的不同觀點，從而有效的消除了各種建模語言之間不必要的差異。它實際上是一種通用的建模語言，可以爲許多面向對象建模方法的用戶廣泛使用。
（2）UML建模能力比其它面向對象建模方法更強。它不僅適合於一般系統的開發，而且對並行、分佈式系統的建模尤爲適宜。
（3）UML是一種建模語言，而不是一個開發過程。
1.4.2 基本組成
UML是在Booch、OMT、OOSE等面向對象的方法極其它許多方法與資料的基礎上發展起來的。UML不僅包含了許多人員的不同觀點，而且也受到了非面向對象的影響。UML表示法集中了不同的圖形表示方法，剔除了其中容易引起的混淆、冗餘或者很少使用的符號，同時添加了一些新的符號。其中的概念來自於面向對象技術領域中衆多專家的思想。其中的大部分觀點並不是其開發者自己提出來的，他們的工作在很大程度上只是將優秀的面向對象建模方法加以選擇和綜合。
UML從考慮系統的不同角度出發，定義了用案圖、類圖、對象圖、狀態圖、活動圖、序列圖、協作圖、構件圖、部署圖等9種圖。這些圖從不同的側面對系統進行描述。系統模型將這些不同的側面綜合成一致的整體，便於系統的分析和構造。儘管UML和其它開發工具還會設計出許多派生的視圖，但上訴這些圖和其它輔助性的文檔是軟件開發人員所見的最基本的構造。其中：
- UML用案圖與OOSE中的用案圖類似。
- UML的類圖綜合了OMT、Booch等面向對象方法中的類圖。
- UML狀態圖是對David Harel所提出狀態圖的改進。
- UML活動圖的基本語義和狀態圖大致相同，它類似於許多方法（包括面向對象技術之前的一些方法）中的工作流圖，
- UML的協作圖是通過對Booch方法的對象圖、Fusion方法的對象交互圖以及其它一些方法中的相關圖表改造而成的。
- UML的構建圖和部署圖是在Booch方法中的模塊和進程圖（處理關係圖、處理器圖）的基礎上發展起來的。
UML簡化了建模方法，它揚棄了Booch、OMT或OOSE等方法中的糟粕，而代之以其它方法中的精華。UML一般不引入新的概念和符號，只有在沒有現有的解決方法可以借鑑時，UML的開發者們才考慮加入新的概念。UML的開發者們是在設計一種語言（儘管只是一種圖形化語言），因此必須在簡明（所有元素一律用方框和文字表示）和繁瑣（爲每個元素設計單獨的符號）之間權衡。儘管如此，UML中還是增添了衍型和擴展機制等一些新的元素，因爲這些元素在其它建模語言的實踐中已經證明是非常有用的。
1.4.3 建模能力的比較
UML並沒有從根本上脫離Booch、OMT、OOSE等方法，而是對這些方法有批判的繼承。這就意味着，如果目前的讀者是一位Booch、OMT或OOSE的使用者，那麼你所接受的培訓、工作經驗和所偏好的開發工具都可以繼承與保留下來，因爲UML是對這些方法的延續。對於其它方法的使用者來說，UML同樣也很容易被接受。與Booch、OMT、OOSE等其它方法相比，UML具有表達能力更強、更清晰和一致的優點。因爲UML消除了各種方法在表示法和術語上不必要的差異，而正是這些差異隱蔽了不同方法之間的相似之處。
Booch等著的UML USER Guide一書從結構建模、行爲建模和體系結構建模3個方面給用戶提供的具體的指南。爲了突出UML與其它建模方法在建模能力上的差異，下面用3個表從結構建模，行爲建模，體系結構建模3個方面對它們進行詳細的比較。表格中使用的各種符號含義如下：
√----該概念存在於所指定的方法中。如果概念名字不一樣，就在括號中註明。
×----所指定的方法中不存在該概念。
~----有一些相似之處。
?----不清楚所指定的方法中是否存在該概念。
表1-1爲結構建模表，其中設計到的概念有類、屬性、操作、關係、依賴、泛化、關聯、角色、多重性、聚合、註釋、約束和類圖。圖1-2爲行爲建模表，其中涉及的概念有消息、鏈接、順序、創建、修改和撤銷、序列圖、協作圖、用案圖和活動圖等等。表1-3爲體系結構建模表，其中主要涉及的概念主要有構建和部署圖。
![]()
![]()
![]()
![]()
從表1-1可以看出，各種建模方法都支持類，類圖和關係等概念，其差別只在於表示符號不一樣，這樣可以用UML提供的標準符號來解決。從表1-2可以看出，各建模方法對動態建模的支持程度不經相同，但它們之間的差別是無關緊要的，因爲UML提供的動態建模設施非常的豐富，足矣解決此問題。從1-3表中可以看出，各建模方法中並沒有UML中的許多體系結構概念，其原因是這個概念比較新，因此，UML考慮了先前許多建模方法中都沒有考慮的問題。
總結：
本節主要介紹了面向對象軟件建模的方法。UML是一種良好定義的、易於表達的且功能頗強的建模語言，它吸收了軟件工程領域內的新思想、新方法和新技術。UML的出現結束了“方法之戰”，消除了面向對象技術早期時代中所面臨的符號、術語以及語義上的混亂，UML已經被對象管理組織（OMG）採納爲面向對象建模標準。
UML很適合用於以體系結構中心的、用案驅動的、迭代式和漸增式的軟件開發過程，目前已經在各個領域內得到廣泛應用。
|
