本節向大家介紹一下UML實踐指南，主要包括用例模型，設計方法選擇和面向對象的基本原則等內容，希望通過本節的學習你對UML實踐有一定的認識。下面就讓我們一起來看一下UML實踐指南的詳細介紹吧。
UML實踐指南
UML僅僅是一種描述語言，它的作用只在於忠實的記錄和表達程式設計師的分析結果和設計思想。它無法告訴開發人員如惡化進行面向對象分析與設計，也無法提供任何有關設計原則和設計技巧的智囊。UML只是開發人員在設計過程橫縱表達設計思想、進行交流和溝通的一種工具，使用時應該「點到為止」。只要當前的UML模型能準確反映設計者的思想，就沒必要浪費精力取開發和維護更加完整、更加細緻的版本。
在UML語言中，用例模型是從外部用戶和外圍系統的角度，分析和考察待開發系統的行為，並通過參與制與系統間的交互關係描述系統對外提供的功能特性，這種參與者與系統功能特性間的交互關係就是用例。用例分析和用例建模就是通過對軟體需求的調研，從具體的功能性需求種抽象出用例模型的工作過程。
UML語言中的用例圖只反映兩類信息：
◆哪些參與者會和我們的系統發生交互；
◆我們的系統需要實現哪些功能特性；
繪製用例圖並不是用例分析和用例建模工作的全部。用例模型是一個敘述性的文檔應使用描述性的文字或其它類型的視圖來概括最終用戶完成某個任務的具體過程，確定用戶作業系統軟體並得到預期結果是的事件發生順序。UML實踐指南中用例模型只描述了軟體的功能性需求，對於軟體的非功能性需求，必須藉助其它的表述手段。
一、用例模型
1、用例和場景的區別
場景是用例的一個執行實例，是用例執行過程中的一條實際路徑。一個用例可能包括多個場景，如成功的場景、失敗的場景等。
2、用例建模
用例建模就是通過分析用戶的功能性需求，得到用例模型的工作過程。用例建模的步驟：
◆確定系統邊界；
◆確定參與者；
◆找出所有的用例；
◆確定每個用例的級別；
◆撰寫用例的文字描述；
◆畫出整個系統為對象的順序圖；
（1）確定系統邊界和參與者
UML實踐指南中用例分析和用例建模工作通常要求在對軟體系統進行分析之前，確定系統的邊界。系統的邊界就是將系統的功能特性與系統的外部環境分離開來的邏輯分界線。一個完整的軟體系統往往包含複雜的內部結構，可由外向內分為若干層次，當考察系統的用例模型時，一般要先明確考察的是系統的哪個層次。
用例分析和用例建模的考察對象可大可小，完全取決於待考察的系統邊界是什麼，對於不同的系統邊界，將獲得完全不同的用例模型。
（2）確定用例級別
用例級別是對用例模型的抽象或細化程度。常用的用例級別包括高層用例、用戶目標級用例和子功能用例等。藉助高層用例，可考察全局問題，了解系統需要為用戶提供幾大類功能；用戶目標級用例是最重要的一個用例級別，他的作用是從用戶的觀點來觀察軟體系統，了解用戶究竟需要哪些功能特性，這個級別屏蔽了很多低級別的信息；被高層用例和用戶目標級用例屏蔽的低級信息被反映在子功能用例中。
◆高層用例
找到高層用例的方法是不斷的擴大系統邊界，直到再擴大時用例的參與者就會被包括在系統的臨界點為止。描述高層用例的目的是為了和用戶交流，讓用戶對軟體功能有一個概要性的認識。
◆子功能級用例
這些用例的作用在於：
ü進一步細化用戶目標級用例；
ü進一步細化用戶目標級用例中的每個執行步驟；
◆用戶目標級用例
不能把用戶界面和用戶目標級用例混同起來，軟體的用戶界面往往對應於具體的、細化的操作需求，過多的考慮用戶界面會分散人們的注意力，應把注意力放在對需求問題的理解上，可以簡單的認為用戶界面不在考慮範圍內。這樣做可以使系統的業務功能更適合不同的用戶界面。
對系統進行用例建模，用例模型在項目開發中發揮巨大作用。通常，在繪製用例圖的基礎上，為每個主要用例畫一張順序圖。順序圖使UML視圖中的一種，可以準確反映某一用例或某一場景的具體操作流程。在這裡，繪製順序圖的目的不是為了進行系統設計，而是要把整個系統看作一個黑盒，觀察發往系統的所有消息的順序和流程。
二、設計方法的選擇
UML實踐指南中傳統的面向過程設計方法是功能分解和逐層迭代思想的體現。要求按軟體的功能特性，在不同級別上，把系統劃分稱多個功能模塊，並確保模塊之間的耦合性最小。該軟體必須具備較強的復用性和擴展性的場合，他的功效就不行了。
一個軟體的內聚度和耦合度都符合要求，它就具備的較好的可復用性、可擴展性和可維護性。
◆內聚度：表示一個類、模塊或函數所承擔職責的自相關程度。若一個模塊只負責一件事情，則說明這個模塊有較高的內聚性；若一個模塊負責很多不相關的事情，則說明這個模塊的內聚性很低。內聚度高的模塊通常很容易理解，很容易被復用、擴展和維護。
◆耦合度：表示模塊與模塊之間、類與類之間、函數與函數之間關係的親密程度。耦合度越高，軟體單元間的依賴性越強。函數調用時，函數參數包含的信息越多，函數與函數之間的耦合度就較大。在面向對象的程序設計語言中，類與類之間的耦合度由他們為了完成自己的職責而必須相互發送的消息及消息的參數來決定。
「低耦合、高內聚」是所有優秀軟體的共同特性。
三、面向對象技術中，一個類若公開了一些方法供其它類調用，則該類就被稱為伺服器，公開的這些方法被稱為服務，而調用這些服務的類就是客戶。在理論上，客戶類調用伺服器類的服務，這一工程可看作客戶向伺服器發送一個消息。客戶和伺服器的概念揭示了面向對象技術的核心思維方式。即，每個類都是一個獨立的組件，它們有著自己的屬性，承擔必要的職責，並通過接口向其它類提供特定的服務；客戶類通過發送消息的方式請求伺服器類履行相應的職責。在這個模型中，系統中的類各司其職、相互協作、共同完成系統的業務功能。下面我們看一下UML實踐指南中面向對象的基本原則。
四、面向對象的基本原則
1、開閉原則：一個模塊對擴展應是開放的，對修改應是關閉的。
該原則要求我們的代碼模塊應能很容易的擴展，但在擴展的過程中，無需改動已有的代碼。
在面向對象語言中，利用多態性可很容易的滿足上述原則的要求。
2、完全替換原則：派生類應該能完全替換掉基類
完全替換指的是在需要一個基類指針或基類引用的地方，傳遞一個派生類的指針或引用，代碼也能正常工作。
要使派生類完全替換基類，派生類和基類就必須擁有相同的接口定義。此外，對接口中的每個方法，派生類和基類還必須擁有相同的前提條件和後置條件，因為當前提條件和後置條件不同時，若用派生類替換基類，就有可能會造成錯誤的調用。
3、依賴倒置原則：依賴於抽象，而不要依賴於具體。
4、為人寫代碼，而不是為機器寫代碼。請期待下節關於UML實踐指南介紹。
【編輯推薦】
【責任編輯：
程華權TEL：（010）68476606】