Use Case正解（答olive, knight, builder, 3nt和think關于Use Case的討論)

大家好，下面是我的觀點，望能拋磚引玉： 

1、好像不少人對Use Case存在誤解，或者片面的認識。其實作為原愛立信公司的軟件總設計師，Ivar Jacobson對軟件界最重要的貢獻之一就在Use Case上（另一個重大發明是被電信界廣范采用的SDL），所以要真正理解Use Case，推薦大家有機會讀一下Jacobson的經典名著“OOSE”(即Object-oriented Software Engineering - A Use Case Driven Approach)。
不能茍同olive的觀點。
Use Case絕不是錦上添花的東西，一方面它可以促進與用戶溝通，理解正確的需求，另一方面它可以劃分系統與外部實體的界限，是系統設計的起點，而最終應該落實到類和實現代碼上。
Use Case View與Logical View應該由明確的相關性。UML中從Use Case到類包的關聯可以用依賴（或實現）關系描述，好像Rose 2000已經可以支持該功能了。
Actor不是指人，而是指代表某一種特定功能的角色，因此同一個人可能對應很多個Actor。Actor是虛擬的概念，甚至可以指像外部系統和設備。
理論上我們可以把一個軟件系統的所有Use Case畫出來，但實際運用時只需把重要的、交互過程復雜的那些畫出來。
Use Case是對系統行為的動態描述，它是OO設計的起點，是類、對象、操作的來源，而通過邏輯視圖的設計，我們可以獲得軟件的靜態結構。
Use Case是Jacobson在設計世界上最大、最成功的OO產品——愛立信著名的AXE系列程控交換機過程中發明的，可見Use Case的重要性和實踐意義。 

2、OOAD大部分情況下比結構化設計好。 

我認為結構化設計是過時的東西，它強調軟件的結構按照功能來組織，一旦功能改變，軟件的結構就會不穩定。
而OO設計把數據流和功能統一起來，因此我估計，IT行業絕大部分（70-80%）的軟件設計（包括數據庫設計）可以采用OO方法，目前國外流行的趨勢也是這樣，剩下的少部分有特定需求的可能還會用傳統方法。
另外在電信界，用有限自動狀態機的SDL方法仍占絕大數，但現在UML和SDL出現了融合的趨勢，而Jacobson則是幕后戲劇性的重量級人物。 

3、Use Case是可以分解的
最近Jacobson出了一本新書: Software Reuse - Architecture, Process and Organization for Business Success. （世界圖書出版公司影印版，88元）。很巧，去年底我在南京成賢街的小書店買到的，感覺如或至寶。該書通過一個網上銀行的例子，對UML建模作了精辟的分析，大家可以從中了解到Use Case的正確用法。
書中在針對軟件的分層結構，用了超系統和超用例（Superordinate Use Case）的概念。
分解一般在功能細化的時候進行，相當于子系統的功能分析。分解后當然還是Use Case圖。
Use Case驅動很好理解，因為Use Case分析總是迭代遞增開發過程中每次循環的起點。 

4、光有思想和方法論是不夠的，最后還要落實到系統的實現上，即代碼，這樣才能前后貫通，從而對OOA、OOD、OOP方法有深刻的認識。這方面Rose的集成功能做的較為完善。 

5、Rose僅僅是UML設計的一種工具，事實上還有很多其他類似工具，包括嵌入式實時系統的UML設計。個人感覺Rose的可視化作的不錯，使用較方便，就是耗內存，有點慢。據說國外有人用一個ROSE模型就有上千個類。大家可以參加Rational公司的Rose論壇，里面非常熱鬧，往往有問必答，包括FAQ和菜鳥級問題，最大的好處是可以了解世界先進水平的專業級用法。 

6、最后，我不是Rational公司的。 

#:--)


一些補充

--------------------------------------------------------------------------------


Actor是指系統以外的，需要使用系統或與系統交互的東西。包括人，設備和
其它系統。
UseCase應該覆蓋系統的所有功能性需求，即使是簡單的UseCase，只要它確實
描述了這類需求，就應該在UseCase圖上畫出來，并用UseCase specification
加以詳細描述。UseCase還是做開發計劃，測試計劃，設計測試用例的依據，
所以UseCase一定要識別得充分而完整。
UseCase與最后設計出來的類的關系是通過Use Case Realization來表現的。
一般不畫它與類包的依賴關系，畫出來一定很復雜，且意義不大。Use Case
Realization可以描述清楚類與類之間是如何協作來perform一個Use Case的。



USE CASE多少的問題?

--------------------------------------------------------------------------------


好象在北航的那本書中提到了USE CASE多少的問題,有人用20-30個左右,有人用100多個,FRANCK的看法大概是100多個的那種.從需求定義,系統邊界的角度,似乎應該是這樣,那么為什么會有少定義USE CASE的情況吶? 

是否應該定義主要的,用戶最關心的,對系統結構有重大影響的,而對于簡單的如代碼維護等就不必劃USE CASE圖了.
或者,都劃,但簡單不用Use Case Realization來詳細描述.



Re: USE CASE多少的問題?

--------------------------------------------------------------------------------

系統的規模不一樣，Use Case的數目當然就不一樣，怎么能硬性規定呢？
小的系統，可能7，8個就可以了，一個大系統，比如一個ERP系統，恐怕
100多個都不止吧？Use Case的數目還和Use Case的粒度有關。粒度大了
數目自然就少了。
我還是認為Use Case應該找全，簡單的也要找出來。當然可以不用詳細的
事件流來描述，只寫出簡單的步驟。Use Case Realization也應該做，
否則怎么保證類找得全呢？類的屬性和方法都找全呢？


很好，但是...

--------------------------------------------------------------------------------

回復給: Use Case正解（答olive, knight, builder, 3nt和think關于Use Case的討論) posted by Dr.OO on July 17, 19100 at 14:44:13: 

www.umlchina.com中UML評論欄中有一篇轉載的"use case miss the boat"中的觀點怎么反駁呢？
當然我并不贊同olive的觀點。

我記錯了，應該是UML misses the boat

--------------------------------------------------------------------------------