UML 核心元素之用例

乙個系統就是由各種各樣的願望組成的。

乙個用例就是與參與者actor互動的，並且給參與者提供可觀測的有意義的結果的一系列活動的集合。

例如你想做一頓飯吃，你需要完成煮飯和炒菜兩件事情，這兩件事情就是兩個用例。

乙個完整的用例是有參與者、前置條件、場景、後置條件構成的。

公尺---前置條件

電飯煲---場景一

蒸籠---場景二

公尺飯---後置條件

這就是乙個用例的構成。

用例本質體現了參與者的願望，不能完整達到參與者願望的不能稱為用例。如果目的是取到錢，那麼取錢是乙個有效的用例，填寫取款單卻不是。

用例必須有參與者發起。

用例必然是動賓短語形式出現的。比如喝水是乙個有效的用例。而「喝」卻不是。

用例是乙個需求單元。

用例的粒度。

比如atm取錢的場景，取錢、讀卡、驗證賬號、列印回執單都是可能的用例，顯然，取錢包含了後續動作。取錢的粒度要大些。

讓業務代表從他自己的本職工作出發來談談他的期望，

可以問：

1.您對系統有什麼期望？

我們期望，系統可以對老師資訊進行管理，包括基本資訊，工資資訊等等。

我們期望，系統可以對學生資訊進行管理，包括基本資訊，健康資訊，聽力資訊等等。

我們期望，系統可以對教務資訊進行管理，包括教學計畫、學生學籍、課表編排、學生成績、教學考評、畢業處理、教材管理等方面。

2.您打算在這個系統裡做些什麼事情？

管理老師資訊。

管理學生資訊。

管理教務資訊。

管理學校資訊等。

3.您做這件事的目的是什麼？

更好的管理學校的資訊。

4.您做完這件事希望有乙個什麼樣的結果？

希望可以實現這些資訊管理，給學校、老師和同學們帶來方便。

簡單地用紙和筆記錄下業務代表的訪談結果，從結果中找出用例。

經常地，頭一兩次的訪談可能沒有那麼順利。基於客戶不熟悉這種訪談形式以及需求採集人員不熟悉客戶業務的原因，開始時採集到的資訊可能不足以得出用例。

這樣，可以考慮重新進行訪談。

功能和用例的區別：

舉個例子。從功能的角度出發，對電視的描述是能開關，能顯示。可以調頻道。可以調聲音。

讀者可以細細品味一下這其中的區別。

業務用例

myself：一切圍繞公司專案來學習，來進行認識，相應的技能的學習等等。做好自己的工作，才有資格加薪。

業務用例是用於描述客戶現有業務的，它的參與者是業務主角。如果說用例是用來獲取功能性需求的，那麼可以說業務用例就是用來獲取功能性業務的。業務用例不將計算機包括進來。

業務範圍不等於系統範圍，不是所有的業務都能夠用計算機來實現的。不在計算機中實現的業務就可以不進入系統範圍。

虛線的內容就是業務用例的實現。

UML核心元素之用例

是一種把現實世界的需求捕獲下來的方法。用例定義了一組用例例項，其中每個例項都是系統所執行的一系列操作。簡而言之就是對系統功能的描述。舉例 做飯這個用例。要有材料，啟動用例的前提 用例執行完了就會有乙個結果，變成公尺飯。a.獨立性。b.用例的執行結果對參與者來說是可觀測的和有意義的。c.這件事必須由乙...

三 UML核心元素

對uml元素基礎定義的擴充套件。在系統之外與系統互動的某人或某事物,參與者包括業務主角和業務工人。可以通過一下三個問題區分業務主角和業 務工人 用例 use case 用例定義了一組用例例項，其中每個例項都是系統所執行的一系列操作，這些操作生成特定主角可以觀測的值。一 個完整的用例由參與者 前置條件...

UML 核心元素之包

包是一種容器，如同資料夾一樣。包是uml非常常用的乙個元素，它最主要的作用就是容納並為其他元素分類。包可以容納用例 業務實體 類圖等，也包含子包。分包的原則 1.如果將元素分為三個包a b c，那麼被分入同乙個包中的那些元素應當是相互聯絡緊密，甚至不可分割的。2.包的理想情況是修改a b c三個包中...