經(jīng)驗總結(jié) UML實踐指南
本節(jié)向大家介紹一下UML實踐指南，主要包括用例模型，設(shè)計方法選擇和面向?qū)ο蟮幕驹瓌t等內(nèi)容，希望通過本節(jié)的學(xué)習(xí)你對UML實踐有一定的認(rèn)識。下面就讓我們一起來看一下UML實踐指南的詳細(xì)介紹吧。
UML實踐指南
UML僅僅是一種描述語言，它的作用只在于忠實的記錄和表達(dá)程序員的分析結(jié)果和設(shè)計思想。它無法告訴開發(fā)人員如惡化進(jìn)行面向?qū)ο蠓治雠c設(shè)計，也無法提供任何有關(guān)設(shè)計原則和設(shè)計技巧的智囊。UML只是開發(fā)人員在設(shè)計過程橫縱表達(dá)設(shè)計思想、進(jìn)行交流和溝通的一種工具，使用時應(yīng)該“點到為止”。只要當(dāng)前的UML模型能準(zhǔn)確反映設(shè)計者的思想，就沒必要浪費精力取開發(fā)和維護(hù)更加完整、更加細(xì)致的版本。
在UML語言中，用例模型是從外部用戶和外圍系統(tǒng)的角度，分析和考察待開發(fā)系統(tǒng)的行為，并通過參與制與系統(tǒng)間的交互關(guān)系描述系統(tǒng)對外提供的功能特性，這種參與者與系統(tǒng)功能特性間的交互關(guān)系就是用例。用例分析和用例建模就是通過對軟件需求的調(diào)研，從具體的功能性需求種抽象出用例模型的工作過程。
UML語言中的用例圖只反映兩類信息：
◆哪些參與者會和我們的系統(tǒng)發(fā)生交互；
◆我們的系統(tǒng)需要實現(xiàn)哪些功能特性；
繪制用例圖并不是用例分析和用例建模工作的全部。用例模型是一個敘述性的文檔應(yīng)使用描述性的文字或其它類型的視圖來概括最終用戶完成某個任務(wù)的具體過程，確定用戶操作系統(tǒng)軟件并得到預(yù)期結(jié)果是的事件發(fā)生順序。UML實踐指南中用例模型只描述了軟件的功能性需求，對于軟件的非功能性需求，必須借助其它的表述手段。
一、用例模型
1、用例和場景的區(qū)別
場景是用例的一個執(zhí)行實例，是用例執(zhí)行過程中的一條實際路徑。一個用例可能包括多個場景，如成功的場景、失敗的場景等。
2、用例建模
用例建模就是通過分析用戶的功能性需求，得到用例模型的工作過程。用例建模的步驟：
◆確定系統(tǒng)邊界；
◆確定參與者；
◆找出所有的用例；
◆確定每個用例的級別；
◆撰寫用例的文字描述；
◆畫出整個系統(tǒng)為對象的順序圖；
（1）確定系統(tǒng)邊界和參與者
UML實踐指南中用例分析和用例建模工作通常要求在對軟件系統(tǒng)進(jìn)行分析之前，確定系統(tǒng)的邊界。系統(tǒng)的邊界就是將系統(tǒng)的功能特性與系統(tǒng)的外部環(huán)境分離開來的邏輯分界線。一個完整的軟件系統(tǒng)往往包含復(fù)雜的內(nèi)部結(jié)構(gòu)，可由外向內(nèi)分為若干層次，當(dāng)考察系統(tǒng)的用例模型時，一般要先明確考察的是系統(tǒng)的哪個層次。
用例分析和用例建模的考察對象可大可小，完全取決于待考察的系統(tǒng)邊界是什么，對于不同的系統(tǒng)邊界，將獲得完全不同的用例模型。
（2）確定用例級別
用例級別是對用例模型的抽象或細(xì)化程度。常用的用例級別包括高層用例、用戶目標(biāo)級用例和子功能用例等。借助高層用例，可考察全局問題，了解系統(tǒng)需要為用戶提供幾大類功能；用戶目標(biāo)級用例是最重要的一個用例級別，他的作用是從用戶的觀點來觀察軟件系統(tǒng)，了解用戶究竟需要哪些功能特性，這個級別屏蔽了很多低級別的信息；被高層用例和用戶目標(biāo)級用例屏蔽的低級信息被反映在子功能用例中。
◆高層用例
找到高層用例的方法是不斷的擴(kuò)大系統(tǒng)邊界，直到再擴(kuò)大時用例的參與者就會被包括在系統(tǒng)的臨界點為止。描述高層用例的目的是為了和用戶交流，讓用戶對軟件功能有一個概要性的認(rèn)識。
◆子功能級用例
這些用例的作用在于：
ü進(jìn)一步細(xì)化用戶目標(biāo)級用例；
ü進(jìn)一步細(xì)化用戶目標(biāo)級用例中的每個執(zhí)行步驟；
◆用戶目標(biāo)級用例
不能把用戶界面和用戶目標(biāo)級用例混同起來，軟件的用戶界面往往對應(yīng)于具體的、細(xì)化的操作需求，過多的考慮用戶界面會分散人們的注意力，應(yīng)把注意力放在對需求問題的理解上，可以簡單的認(rèn)為用戶界面不在考慮范圍內(nèi)。這樣做可以使系統(tǒng)的業(yè)務(wù)功能更適合不同的用戶界面。
對系統(tǒng)進(jìn)行用例建模，用例模型在項目開發(fā)中發(fā)揮巨大作用。通常，在繪制用例圖的基礎(chǔ)上，為每個主要用例畫一張順序圖。順序圖使UML視圖中的一種，可以準(zhǔn)確反映某一用例或某一場景的具體操作流程。在這里，繪制順序圖的目的不是為了進(jìn)行系統(tǒng)設(shè)計，而是要把整個系統(tǒng)看作一個黑盒，觀察發(fā)往系統(tǒng)的所有消息的順序和流程。#p#
二、設(shè)計方法的選擇
UML實踐指南中傳統(tǒng)的面向過程設(shè)計方法是功能分解和逐層迭代思想的體現(xiàn)。要求按軟件的功能特性，在不同級別上，把系統(tǒng)劃分稱多個功能模塊，并確保模塊之間的耦合性最小。該軟件必須具備較強(qiáng)的復(fù)用性和擴(kuò)展性的場合，他的功效就不行了。
一個軟件的內(nèi)聚度和耦合度都符合要求，它就具備的較好的可復(fù)用性、可擴(kuò)展性和可維護(hù)性。
◆內(nèi)聚度：表示一個類、模塊或函數(shù)所承擔(dān)職責(zé)的自相關(guān)程度。若一個模塊只負(fù)責(zé)一件事情，則說明這個模塊有較高的內(nèi)聚性；若一個模塊負(fù)責(zé)很多不相關(guān)的事情，則說明這個模塊的內(nèi)聚性很低。內(nèi)聚度高的模塊通常很容易理解，很容易被復(fù)用、擴(kuò)展和維護(hù)。
◆耦合度：表示模塊與模塊之間、類與類之間、函數(shù)與函數(shù)之間關(guān)系的親密程度。耦合度越高，軟件單元間的依賴性越強(qiáng)。函數(shù)調(diào)用時，函數(shù)參數(shù)包含的信息越多，函數(shù)與函數(shù)之間的耦合度就較大。在面向?qū)ο蟮某绦蛟O(shè)計語言中，類與類之間的耦合度由他們?yōu)榱送瓿勺约旱穆氊?zé)而必須相互發(fā)送的消息及消息的參數(shù)來決定。
“低耦合、高內(nèi)聚”是所有優(yōu)秀軟件的共同特性。
三、面向?qū)ο蠹夹g(shù)中，一個類若公開了一些方法供其它類調(diào)用，則該類就被稱為服務(wù)器，公開的這些方法被稱為服務(wù)，而調(diào)用這些服務(wù)的類就是客戶。在理論上，客戶類調(diào)用服務(wù)器類的服務(wù)，這一工程可看作客戶向服務(wù)器發(fā)送一個消息?？蛻艉头?wù)器的概念揭示了面向?qū)ο蠹夹g(shù)的核心思維方式。即，每個類都是一個獨立的組件，它們有著自己的屬性，承擔(dān)必要的職責(zé)，并通過接口向其它類提供特定的服務(wù)；客戶類通過發(fā)送消息的方式請求服務(wù)器類履行相應(yīng)的職責(zé)。在這個模型中，系統(tǒng)中的類各司其職、相互協(xié)作、共同完成系統(tǒng)的業(yè)務(wù)功能。下面我們看一下UML實踐指南中面向?qū)ο蟮幕驹瓌t。
四、面向?qū)ο蟮幕驹瓌t
1、開閉原則：一個模塊對擴(kuò)展應(yīng)是開放的，對修改應(yīng)是關(guān)閉的。
該原則要求我們的代碼模塊應(yīng)能很容易的擴(kuò)展，但在擴(kuò)展的過程中，無需改動已有的代碼。
在面向?qū)ο笳Z言中，利用多態(tài)性可很容易的滿足上述原則的要求。
2、完全替換原則：派生類應(yīng)該能完全替換掉基類
完全替換指的是在需要一個基類指針或基類引用的地方，傳遞一個派生類的指針或引用，代碼也能正常工作。
要使派生類完全替換基類，派生類和基類就必須擁有相同的接口定義。此外，對接口中的每個方法，派生類和基類還必須擁有相同的前提條件和后置條件，因為當(dāng)前提條件和后置條件不同時，若用派生類替換基類，就有可能會造成錯誤的調(diào)用。
3、依賴倒置原則：依賴于抽象，而不要依賴于具體。
4、為人寫代碼，而不是為機(jī)器寫代碼。請期待下節(jié)關(guān)于UML實踐指南介紹。
【編輯推薦】
