工程實踐項目中的需求分析建模—問答系統后端

1. 前言及項目背景介紹

最近在高級軟件工程課上學習了對項目中的需求進行分析和建模的基本方法，本文針對最近在做的工程實踐項目，運用所學方法進行用例建模和業務領域建模，以及數據建模，最終形成概念原型，以驗證所學知識。

工程實踐項目是實現一個類似知乎的問答社區系統（后端），因為有成熟的產品，所以整體來說需求還是挺明確的，本文以自己的角度對系統進行一系列建模分析，以加深對項目的理解。

2. 用例建模

2.1 什么是用例

用例（Use Case）的核心概念中首先它是一個業務過程（business process），經過邏輯整理抽象出來的一個業務過程，這是用例的實質。什么是業務過程？在待開發軟件所處的業務領域內完成特定業務任務（business task）的一系列活動就是業務過程。

用例的幾個基本要素：

• 一個用例應該由業務領域內的某個參與者（Actor）所觸發。

• 用例必須能為特定的參與者完成一個特定的業務任務。

• 一個用例必須終止於某個特定參與者，也就是特定參與者明確地或者隱含地得到了業務任務完成的結果。

2.2 用例建模的基本步驟

1. 從需求表述中找出用例，往往是動名詞短語表示的抽象用例；

2. 描述用例開始和結束的狀態，用TUCBW和TUCEW表示的高層用例；

3. 對用例按照子系統或不同的方面進行分類，描述用例與用例、用例與參與者之間的上下文關系，並畫出用例圖；

4. 進一步逐一分析用例與參與者的詳細交互過程，完成一個兩列的表格將參與者和待開發軟件系統之間從用例開始到用例結束的所有交互步驟都列舉出來擴展用例。

其中第一步到第三步是計划階段，第四步是增量實現階段。

2.3 准確提取用例的基本方法

為了准確地提取用例，我們必須遵循一些原則和方法：

1. 從需求中尋找業務領域相關的動名詞和動名詞短語，比如做什么事、什么事情必須被完成,或者執行某任務等;
2. 驗證這些業務領域相關的動名詞和動名詞短語到底是不是用例。驗證業務領域相關的動名詞或動名詞短語是不是用例的標准是滿足四個必要條件:
   • 它是不是一個業務過程?
   • 它是不是由某個參與者觸發開始?
   • 它是不是顯式地或隱式地終止於某個參與者?
   • 它是不是為某個參與者完成了有用的業務工作?
3. 在需求中識別出參與者、系統或子系統。參與者會觸發某個用例開始，用例也會顯式地或隱式地終止於某個參與者，用例屬於系統或子系統。

其中第二點中的四個必要條件尤為重要，是我們能否准確識別用例的關鍵所在。

2.4 工程實踐中的用例建模

類似知乎的問答社區需求比較明確，整個系統也只有一個參與角色（用戶），用戶主要有如下功能：

• 注冊登錄
• \(\underline{瀏覽問題}\)
• \(\underline{發布問題}\)
• \(\underline{修改}\)和\(\underline{刪除問題}\)
• \(\underline{回答問題}\)
• \(\underline{修改}\)和\(\underline{刪除回答}\)
• 在個人中心\(\underline{查看}\)自己的\(\underline{活動歷史}\)

根據上述需求，我們可以找出相應的動名詞，結合是否滿足用例的四個必要條件來提取出用例，用例用下划線標出，基於此，我們可以畫出用戶的用例圖：

3. 業務領域建模

3.1 什么是業務領域建模

• 業務領域建模是開發團隊用於獲取業務領域知識的過程。因為軟件工程師往往需要工作在不同的業務領域或者不同項目中，他們需要業務領域知識來開發軟件系統。軟件工程師往往來自不同的專業背景，這可能會影響他們對業務領域的認知。因此業務領域建模有助於開發團隊獲取業務領域知識形成統一的業務認知。

• 開發團隊獲取業務領域知識的過程一般包括收集業務領域相關信息、執行團隊頭腦風暴、對業務領域相關的知識概念進行分類，最后用UML類圖將業務領域知識圖形化展示。

3.2 業務領域建模的基本步驟

1. 收集應用業務領域的信息。聚焦在功能需求層面，也考慮其他類型的需求和資料；

2. 頭腦風暴。列出重要的應用業務領域概念，給出這些概念的屬性，以及這些概念之間的關系；

3. 給這些應用業務領域概念分類。分別列出哪些是類、哪些屬性和屬性值、以及列出類之間的繼承關系、聚合關系和關聯關系。

4. 將結果用 UML 類圖畫出來。

3.3 工程實踐中的業務領域建模

收集業務領域信息在第一步的用例建模中已經完成，經過頭腦風暴以及分類，可以將項目的業務領域概念分為以下幾類：

• 用戶類：擁有屬性 ID，用戶名，密碼，昵稱，郵箱，頭像等屬性
• 問題類：擁有屬性 ID，所屬用戶ID，標題，內容等，一個用戶可以發布多個問題
• 回答類：擁有屬性 ID，所屬用戶ID，所屬問題ID，內容等，一個用戶可以發表多個回答，一個問題擁有多個回答
• 評論類：擁有屬性 ID，所屬用戶ID，上級ID（可以是回答或評論），內容等，一個用戶可以發表多個評論，一個回答或評論擁有多個評論

據此可以畫出項目的UML類圖：

4. 業務數據建模

根據之前的用例建模以及業務領域建模過程，我們可以大致確定項目所需要的數據模型以及關聯關系，相應的關系型表設計如下：

• User

列名	數據類型	長度	唯一	非空	注釋
id	bigint	20	是	是	用戶ID
username	varchar	255	是	是	用戶名
password	varchar	255	否	是	密碼
nickname	varchar	255	否	否	昵稱
email	varchar	255	是	否	郵箱

• Question

列名	數據類型	長度	唯一	非空	注釋
id	bigint	20	是	是	問題ID
user_id	bigint	20	否	是	所屬用戶ID
title	varchar	255	否	是	標題
content	text	1000	否	否	簡述
answer_count	int	11	否	是	回答總數
collect_count	int	11	否	是	收藏總數

• Answer

列名	數據類型	長度	唯一	非空	注釋
id	bigint	20	是	是	回答ID
question_id	bigint	20	否	是	所屬問題ID
user_id	bigint	20	否	是	所屬用戶ID
content	text	1000	否	是	內容
comment_count	int	11	否	是	評論總數
collect_count	int	11	否	是	收藏總數
view	int	11	否	是	點擊量
up_count	int	11	否	是	點贊次數
down_count	Int	11	否	是	點踩次數

• Q-A

列名	數據類型	長度	唯一	非空	注釋
id	bigint	20	是	是	主鍵
question_id	bigint	20	否	是	問題ID
answer_id	bigint	20	否	是	回答ID

• Comment

列名	數據類型	長度	唯一	非空	注釋
id	bigint	20	是	是	評論ID
parent_id	bigint	20	否	是	上級ID
user_id	bigint	20	否	是	所屬用戶ID
content	text	1000	否	是	內容
comment_count	int	11	否	是	評論總數
up_count	int	11	否	是	點贊次數

• A-C

列名	數據類型	長度	唯一	非空	注釋
id	bigint	20	是	是	主鍵
parent_id	bigint	20	否	是	上級ID
comment_id	bigint	20	否	是	評論ID

5. 概念原型及工作過程

5.1 概念原型

• 概念是人對能代表某種事物或發展過程的特點及意義所形成的思維結論。

• 概念原型是一種虛擬的、理想化的軟件產品形式。

• 概念原型 = 用例 + 數據模型

5.2 工程實踐項目的概念原型

在之前的分析中已經得出了項目的用例和數據模型，進而可以總結出項目的概念原型工作過程：

用戶登錄系統后，可以從首頁推薦瀏覽問題列表，或者從熱榜查看熱門問題，此外，也可以通過分類或者搜索查找自己感興趣的問題，點擊進入問題詳情后，可以以一定的排序方式查看該問題的回答列表，可以對回答進行點贊點踩，評論等，當然也可以自己回答問題。首頁提供了發布問題的按鈕可以發出提問尋求解答。用戶可以在在個人中心對個人信息和活動歷史進行管理，比如更新自己的聯系方式，查找自己曾經回答過的問題等等。

6. 總結

本文運用課上所學的以面向對象分析和設計為思想方法主線，從需求分析到軟件設計的基本建模方法，對目前正在實際開發的工程實踐項目進行了建模分析。在這個過程中，我不僅復習了課程內容，更對實際項目有了進一步的認識，這將幫助我更好的完成工程實踐。

工程實踐項目涉及到多人合作，還有很多更細致的方面，我很難在這有限的時間內把它完全的分析出來，僅以個人角度略作分析，難免有疏漏，還望指正。