1 前言
本篇博客基於高級軟件工程課程內容，針對自己的工程實踐內容（設計一個類似知乎問答系統）來進行用例建模和業務領域建模，以及數據建模，最終形成概念原型。使用的是敏捷統一過程的基本建模方法，從需求分析到軟件設計，自我提升碼農修養，過程相當酸爽，讓我學習到了如何准確有條理地進行需求分析。
參考文獻 > 課程ppt
2 需求分析概述---用戶是上帝
- 需求就是對用戶期望的軟件行為的表述；
- 獲取需求就是需求分析師通過關注用戶的期望和需要，從而獲得用戶期望的軟件行為，然后對其進行表述的工作；
- 需求分析是在獲取需求的基礎上進一步對軟件涉及的對象或實體的狀態、特征和行為進行准確描述或建模的工作。
通常我們進行需求分析有兩種主要的方法：原型化方法（Prototyping）和建模的方法（Modeling），下面我們采用用例建模的方法對項目進行需求分析。
3 用例建模---邏輯抽象
3.1 用例的概念
用例（Use Case）的核心概念中首先它是一個業務過程（business process），經過邏輯整理抽象出來的一個業務過程，這是用例的實質。什么是業務過程？在待開發軟件所處的業務領域內完成特定業務任務（business task）的一系列活動就是業務過程。用例模型主要由以下元素構成：
- 參與者(Actor) 參與者是指存在於被定義系統外部並與該系統發生交互的人或其他系統，他們代表的是業務領域內的參與者或者業務實體。
- 用例(Use Case) 用例必須能為特定的參與者完成一個特定的業務任務，用於表示系統所提供的服務。
- 通訊關聯(Communication Association) 通訊關聯用於表示參與者和用例之間的對應關系。
需滿足原則：A use case must end with an actor. 一個用例必須終止於某個特定參與者，也就是特定參與者明確地或者隱含地得到了業務任務完成的結果。
3.2 用例的三個抽象層級
- 抽象用例（Abstract use case）。只要用一個干什么、做什么或完成什么業務任務的動名詞短語，就可以非常精簡地指明一個用例；
- 高層用例（High level use case）。需要給用例的范圍划定一個邊界，也就是用例在什么時候什么地方開始，以及在什么時候什么地方結束；
- 擴展用例（Expanded use case）。需要將參與者和待開發軟件系統為了完成用例所規定的業務任務的交互過程一步一步詳細地描述出來，一般我們使用一個兩列的表格將參與者和待開發軟件系統之間從用例開始到用例結束的所有交互步驟都列舉出來。
3.3 用例建模的基本步驟
-
從需求表述中找出用例，往往是動名詞短語表示的抽象用例；
-
描述用例開始和結束的狀態，用TUCBW和TUCEW表示的高層用例；
-
對用例按照子系統或不同的方面進行分類，描述用例與用例、用例與參與者之間的上下文關系，並畫出用例圖；
-
進一步逐一分析用例與參與者的詳細交互過程，完成一個兩列的表格將參與者和待開發軟件系統之間從用例開始到用例結束的所有交互步驟都列舉出來擴展用例。
其中第一步到第三步是計划階段，第四步是增量實現階段。
3.4 如何准確提取用例
-
從需求中尋找業務領域相關的動名詞和動名詞短語，比如做什么事、什么事情必須被完成，或者執行某任務等；
-
驗證這些業務領域相關的動名詞和動名詞短語到底是不是用例。驗證業務領域相關的動名詞或動名詞短語是不是用例的標准是滿足四個必要條件：
-
必要條件一：它是不是一個業務過程？
-
必要條件二：它是不是由某個參與者觸發開始？
-
必要條件三：它是不是顯式地或隱式地終止於某個參與者？
-
必要條件四：它是不是為某個參與者完成了有用的業務工作？
如果以上四個必要條件都滿足的話，那么該業務領域相關的動名詞或動名詞短語就是一個用例。
-
-
在需求中識別出參與者、系統或子系統。
3.5 用例圖中的各種關系
1）參與者與用例間的關聯關系
2）用例與用例之間的關系
a. 包含關系
b. 擴展關系
c. 泛化關系
3.6 結合工程實踐項目進行用例分析
3.6.1 第一步 找出動名詞短語表示的抽象用例
類知乎問答系統的參與者主要為用戶，類比現有成熟產品可以大致分析出其用動名詞短語表示的抽象用例：
-
注冊
-
登錄
-
修改資料
-
發布問題
-
修改問題
-
瀏覽問題
-
發布回答
-
修改回答
-
查看回答
-
評論回答
-
贊同回答
-
不贊同回答
3.6.2 第二步 描述用例開始和結束的狀態
以注冊為例說明：
3.6.3 第三步 畫出用例圖
4 業務領域建模---專業的人做專業的事
4.1 概念
業務領域建模是開發團隊用於獲取業務領域知識的過程。因為軟件工程師往往需要工作在不同的業務領域或者不同項目中，他們需要業務領域知識來開發軟件系統。軟件工程師往往來自不同的專業背景，這可能會影響他們對業務領域的認知，因此需要該領域方面的人員來進行協助。
4.2 基本步驟
-
第一步，收集應用業務領域的信息。聚焦在功能需求層面，也考慮其他類型的需求和資料；
-
第二步，頭腦風暴。列出重要的應用業務領域概念，給出這些概念的屬性，以及這些概念之間的關系；
-
第三步，給這些應用業務領域概念分類。分別列出哪些是類、哪些屬性和屬性值、以及列出類之間的繼承關系、聚合關系和關聯關系。
-
第四步，將結果用 UML 類圖畫出來。
記住：我們是對業務建模，不是對系統建模，關注層面應該集中在業務上！
4.3 結合項目進行業務建模
4.3.1 收集領域信息並分類
在前面對用例進行建模的過程已經對問答系統領域方面的信息有了較為詳細的了解，根據需求對概念進行分類，並列出他們的屬性如下：
- 用戶類：id，用戶名，密碼，性別，昵稱，頭像，描述，等屬性
- 問題類：id，標題，內容，創建時間，更新時間，所屬用戶id
- 回答類： id，內容，評論數，贊同數，標簽，所屬問題id，所屬用戶id
- 評論類：id，內容，贊同數，對應評論對象id（回答id或評論id），所屬用戶ID，
4.3.2 畫出UML圖
5 關系數據建模---數據庫建表的參考
根據UML圖我們可以很容易地得出主要類的數據模型，各個表的具體內容如下所示：
- User表
| 字段 | 類型 | 非空 | 注釋 |
|---|---|---|---|
| id | bigint | 是 | 用戶id |
| name | varchar | 是 | 用戶名 |
| nickname | varchar | 是 | 昵稱 |
| password | varchar | 是 | 密碼 |
| gender | varchar | 否 | 性別 |
| avatar_url | varchar | 否 | 頭像圖片url |
| description | varchar | 否 | 描述 |
- Question表
| 列名 | 類型 | 非空 | 注釋 |
|---|---|---|---|
| id | bigint | 是 | 問題id |
| title | varchar | 是 | 題目 |
| content | varchar | 是 | 內容 |
| created_at | varchar | 是 | 創建時間 |
| update_at | varchar | 否 | 修改時間 |
| user_id | bigint | 是 | 用戶id |
- Answer表
| 列名 | 類型 | 注釋 |
|---|---|---|
| id | bigint | 回答id |
| content | varchar | 內容 |
| comment_num | bigint | 評論數 |
| agree_num | bigint | 贊同數 |
| tag | varchar | 標簽 |
| question_id | bigint | 對應問題id |
| user_id | bigint | 所屬用戶id |
- Comment表
| 列名 | 類型 | 注釋 |
|---|---|---|
| id | bigint | 評論id |
| content | varchar | 內容 |
| agree_num | bigint | 贊同數 |
| reply_id | text | 回復對應的id |
| user_id | int | 所屬用戶id |
注意各個表的外鍵依賴表現了類之間的關系！
6 概念原型出爐---虛擬的產品
6.1 概念原型的含義
-
概念是人對能代表某種事物或發展過程的特點及意義所形成的思維結論。
-
概念原型是一種虛擬的、理想化的軟件產品形式。
6.2 仿知乎問答系統項目的概念原型
用戶首先要進行賬號的注冊后方可登錄該知乎問答系統。此后用戶可以根據自己需求在系統內進行提問，並可@邀請用戶回答；用戶可以拉鏈查詢現有的問題(根據時間或者熱度等排序)或者根據指定關鍵詞or標簽進行問題的檢索，然后可以就相關問題進行回答。其他用戶可以對別人的回答進行評論，點贊，也可對別人的評論進行點贊和回復。
7 總結感悟
對工程實踐項目進行完整的需求分析和建模過程之后，深深感受到了需求分析的難處，十分燒腦，如果沒有科學的流程指導可能根本難以入手。更體會到了抓住了需求要害等於抓住了用戶這個道理，每天有無數產品誕生，也有無數產品隕落，就看誰更能對人性進行精准的把握。