工程實踐項目中的需求分析建模

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 工程實踐中的業務領域建模

收集業務領域信息在第一步的用例建模中已經完成，通過頭腦風暴以及分類，能夠畫出項目的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. 總結

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

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