用例視圖:用例視圖是系統功能的模型圖，可以被稱為參與者的外部用戶觀察到。用例是系統中的壹個功能單元，它可以被描述為參與者和系統之間的交互。
類圖:類圖是UML靜態機制中的壹個關鍵點，既是設計者關註的核心，也是實現人員關註的核心。
協作圖/用例模型:作為客戶和開發者之間的契約。用例是貫穿整個系統開發的壹條主線。同壹個用例模型是需求工作流的結果，可以作為分析設計工作流和測試工作流的輸入。
系統模型:面向計算機世界，描述如何用系統解決問題。
首先，從對應的閱讀對象來說:
開發者關心的:用例視圖，類圖，協作圖/用例模型，系統模型。
產品經理關心的:協作圖/用例模型，系統模型，用例視圖。
客戶關心的:系統模型，協作圖/用例模型。
所以在大小方面(我想描述壹下整個人體和最小細胞的對比程度):
系統模型>；協作圖/用例模型>；用例圖>類圖
類圖，或者說生產過程，在大多數實際過程中都是按照這個順序出現的。
用普通的白話文說:
系統模型就像:客戶的壹個想法，然後被產品經理擴散到相應的需求文檔中。(其實中小公司在現階段其實就是壹句話甚至壹個想法，系統模型只是我們大致如何實現這個內容。比如我們用OA處理貴公司的XXXX，用CRM+OA的基礎數據+XXXX實現貴公司的YYYY。)
協作圖/用例模型:有了這個思路，產品經理通過自己對產品的熟悉程度，畫出相應的操作界面，展示給客戶。軟件會是什麽樣子？(大部分中小公司都會在這個階段出UI設計的初稿。)
用例視圖:可以被稱為參與者的外部用戶觀察到的系統功能的模型圖。用例是系統中的壹個功能單元，它可以被描述為參與者和系統之間的交互。用於拆分協作圖的某個特定功能(在大多數中小企業的實際流程中，這是由項目所經歷的“概要設計”所涵蓋的。)
類圖:這裏很明顯。以上內容我需要實現。我需要什麽？
總而言之:
倒過來看-& gt；
類圖構成或實現了壹個用例。
不同的交互用例，相互溝通調用後，形成用例模型/協作。
不同的協作(就像壹個公司的不同部分)運營後形成壹個系統模型(壹個公司)。
壹個完整的系統模型，處理壹件具體的事情(比如壹個公司生產壹種產品)。
按正確的順序來見他-& gt；
妳是老板，需要開廠，然後策劃公司開始準備需要的內容。首先，妳列出了壹個清單-& gt；必須有倉庫、機床和工人。
開始具體步驟，采購和招聘-& gt；協作圖:大家租房子，買機床，招工人。
那麽如何購房/招聘/租房呢？-& gt；用例圖:怎麽租房子，怎麽買機床，怎麽招工人。
采取行動-& gt；類圖:具體功能出來了。對應的類有對應的方法，對應的功能只有通過調用才能實現。
總的來說-& gt；實現了該系統模型。