我發現，在OO和UML幾乎一統天下的今天，仍有很多系統分析員對OO和UML一知半解，甚至包括很多已經使用了很久UML的系統分析員。
於是打算寫一個系列文章，將多年來的工作經驗做一個總結。對初學者起個啓蒙作用，也希望拋磚引喻，與各路大蝦共同探討，共同提高。
這個系列文章將以我對OO和系統分析的理解爲主，從UML基礎開始，闡述面向對象的需求分析方法，過程，並以RUP爲例，闡述如何將OO過程與軟件過程有機結合在一起，做一個真正OO應用。
好了，今天是第一篇。想得很遠，真希望我能堅持下去，呵呵
用例是什麼？其原始英文是usecase，直譯過來就成了用例。這也是一個比較貼切的叫法了，從字面的直接理解就是使用的例子。另一種比較流行的定義是用例就是與使用者(actor)交互的，並且給使用者提供可觀測的有意義的結果的一系列活動的集合。
這個定義還是比較費解的，筆者在衆多應聘者中發現很多使用用例來做需求的系統分析員，有的已經使用了兩年以上，但仍不能把握用例的本質，雖然他們號稱精通UML。
最具普遍意義的理解錯誤是認爲用例就是功能的劃分和描述，認爲一個用例就是一個功能點。在這種理解下，用例變成了僅僅是較早前需求中功能框圖的翻版，很多人用用例來劃分子系統，功能模塊和功能點。如果這樣，用例根本沒有存在的必要。有意思的是，造成這種理解錯誤的相當一部分原因卻是因爲對OO思想的理解不夠深入，本質上說，把用例當成功能點的系統分析員腦子裏還是面向過程的那一套思想，雖然他們在使用OO的工具，OO的語言，號稱在做面向對象的開發，但過程的影子還沒有從他們腦子裏徹底抹去。
如果用例不是功能的話，它是什麼呢？從定義上說，能給使用者提供一個執行結果的活動，不就是功能嗎？我的回答是：錯！功能是計算機術語，它是用來描述計算機的，而非定義需求的術語。功能實際描述的是輸入-->計算-->輸出。這讓你想到了什麼？DFD圖？這可是典型的面向過程分析模式。因此我說把用例當做功能點的分析員實際在做面向過程的分析。
而用例則不是計算機術語，UML除了在計算機行業中應用，它也經常被應用在其它行業中。用例是一種需求方法學，雖然軟件危機和OO的發展促成了它的誕生並被完美的融合進了OO體系，形成了UML，但它實際上並不是軟件行業的專用品。如果非要從功能的角度解釋，那麼用例可以解釋爲一系列完成一個特定目標的“功能”的組合，針對不同的應用場景，這些“功能”體現不同的組合方式。實際上，把用例解釋爲某個參與者(actor)要做的一件事可能更爲合適。這樣的一件事有以下幾個特徵：
一、這件事是相對獨立的。這意味着它不需要與其它用例交互而獨自完成參與者的目的。也就是說這件事從“功能”上說是完備的。讀者可能會想到，用例之間不是也有關聯關係嗎？比如擴展，比如實現，比如繼承，它看上去並不是獨立的嘛。關於這個問題，筆者會在後續的文章裏詳細說明。這裏稍微解釋一下，用例之間的關係是分析過程的產物，而且這種關係一般的產生在概念層用例階段和系統層用例階段。對於業務用例，這個特徵是很明顯的。
二、這件事的執行結果對參與者來說是可觀測的和有意義的。例如，系統會監控參與者在系統裏的操作，並在參與者刪除數據之前備份。雖然它是系統的一個必需組成部分，但它在需求階段卻不應該作爲用例出現。因爲這是一個後臺進程，對參與者來說是不可觀測的，它應該在系統用例分析階段定義。又比如說，登錄系統是一個有效的用例，但輸入密碼卻不是。這是因爲登錄系統對參與者是有意義的，這樣他可以獲得身份認證和授權，但輸入密碼卻是沒有意義的，輸入完了呢？有什麼結果嗎？
三、這件事必須由一個參與者發起。不存在沒有參與者的用例，用例不應該自動啓動，也不應該主動啓動另一個用例。用例總是由一個參與者發起，並且滿足特徵二。例如從ATM取錢是一個有效的用例，ATM吐鈔卻不是。因爲ATM是不會無緣無故吐鈔的，否則，我從此天天守在ATM旁，生活無憂矣。
四、這件事必然是以動賓短語形式出現的。即，這件事必須有一個動作和動作的受體。例如，喝水是一個有效的用例，而“喝”和“水”卻不是。雖然生活常識告訴我們，在沒有水的情況下人是不會做出喝這個動作的，水也必然是喝進去的，而不是滑進去的，但是筆者所見的很多用例中類似“計算”，“統計”，“報表”，“輸出”，“錄入”之類的並不在少數。
除去以上的特徵，筆者覺得用例的含義還要更深些。首先，用例的背後是一種需求方法論。其核心是以參與者爲中心（區別於以計算機系統爲中心），從參與者的角度來描述他要做的日常工作（區別於以業務流程描述的方式），並分析這些日常工作之間是如何交互的（區別於數據流的描述方式）。換句話說，用例分析的首要目標不是要弄清楚某項業務是如何一步一步完成的，而是要弄清楚有多少參與者？每個參與者都做什麼？業務流程分析則是後續的工作了。其次，用例簡直就是爲OO而生的，其思想完美的符合OO。用例分析方法試圖找到問題領域內所有相對獨立的參與者和事件，並把業務流程當成是這些參與者和事件之間的交互結果（在UML用活動圖或序列圖來描述）。因此，用例方法被吸納到OO之後，UML得以以完備的形式出現，用例成爲了真正的OO核心。在RUP裏，這種核心作用被發揮到極致，產生了用例驅動（usecase driven）的軟件過程方法，在RUP裏，軟件生產的所有過程和產物都是圍繞着用例形成的。
可以說，用例分析是OO的第一步。如果用例分析本身出了問題，對業務架構，軟件架構的影響是很大的，將大大削弱OO的優勢--複用、擴展。筆者認爲軟件複用可以分爲三個層次，最低層次的複用是代碼級複用，這是由OO語言特性提供支持的，例如繼承，聚合，多態；較高層次的複用是組件級複用，這是由設計模式提供支持的，例如Factory模式,Builder模式；最高層次的複用則是服務級複用，這在很大程度上是由應用服務器和通訊協議來提供支持的，例如最近炒得火熱的SOA（面向服務的應用）架構。用例分析的好壞也許對代碼級和組件級的複用影響不太大，但對服務級的複用影響卻是巨大的。筆者認爲服務級複用是OO的最高境界，而結構良好的用例分析則是達到這一境界的基礎。
閒話：
今天你OO了嗎？
如果你的分析習慣是在調研需求時最先弄清楚有多少業務流程，先畫出業務流程圖，然後順藤摸瓜，找出業務流程中每一步驟的參與部門或崗位，弄清楚在這一步參與者所做的事情和填寫表單的結果，並關心用戶是如何把這份表單傳給到下一個環節的。那麼很不幸，你還在做面向過程的事情。
如果你的分析習慣是在調研需求時最先弄清楚有多少部門，多少崗位，然後找到每一個崗位的業務代表，問他們類似的問題：你平時都做什麼？這件事是誰交辦的？做完了你需要通知或傳達給誰嗎？做這件事情你都需要填寫些什麼表格嗎？....那麼恭喜你，你已經OO啦！
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/cxzhq2002/archive/2010/05/12/5579838.aspx
