??? 用例建模時總是把握不住宏觀與細節程度，并且對于一些用例本身不能很好描述的需求進行建模。幾乎每次分析都是步履艱難。最近找了些資料看，才發現犯忌諱。。。赫赫。。
??? 吸取了之前教訓，現在個人吧用例建模分為兩大步驟。首先是宏觀的完全出自用戶的功能事例。當上一部基本完成后，就需要需求分析人員作進一步細化，并最終通過用戶審核的。之前一步可以稱為基礎需求用例，后者就是次用例了。。：）
??? 基礎用例建模可以遵照經典用例分析的一些步驟。有一點區別，對于本系統完全被動的參與者也可以作為首選分析對象。因為有時候用戶雖然不知道要對系統干啥，但是卻非常關注自己得到系統的服務。一個用例建立可以有如下步驟:
??? 1。選擇外部系統的參與者，包括對于本系統完全被動的參與者。
??? 2。從參與者角度出發, 對參與者交互的每件事列出步驟。
??? 3。不作任何多余的分析。。記住了，這要用戶給出就寫下來。。
??? 這樣只要用戶可以給出的都要記錄下來,其他都不作。那還有很多參與者并不是人，怎么辦？？。。。很遺憾只能靠分析人員自己站在這些參與者角度假設了。同樣不要做過多分析，只要假設這些參與者只了解系統的邊界部分即可。
??? 一般對于快速開發的項目基礎用例建立完成就可以直接進行設計甚至編碼工作了，因為之后的分析可能會消耗大量時間。把這些事留給重構，或下一個迭代版本吧。。。咔咔咔。。。只要你不擔心這些的后果。。。
??? 次用例建模完全建立在基礎用例上。這是為了分析出進一步需求或者說對于基礎需求中不明確的部分作出描述。該步驟分析人員可以完全先自己分析，但必須得到用戶審核。
??? 步驟如下：??
??? 1。考慮一些可變情況，把他們創建為擴展用例。
??? 2。復審不同用例的描述，找出其中的相同點，抽出相同點作為共同的用例。
??? 3。分析之前沒有主動參與者的用例，使其必須由參與者。（還記得基礎用例可以有對于本系統完全被動的參與者么？？ ：）
??? 注意點：雖然一般用例在建模時有很多限制，但是個人覺得在作次用例建模時，應該放開自由發揮只要能說明問題即可。include extends use ... 隨便,不用太擔心這些東西的定義。

??? 對于有經驗的領域可以多次進行次用例迭代，從而減少系統整體開發的迭代次數。只要做得好完全可以做到只用瀑布式方式開發。（當然個人覺得不太可能做到赫赫，用戶是善變的。）

??? 參考：
???詠武的“用例建模”
???