0.前言
本文基于在《進階軟體工程》課程中所學的軟體工程模組化方法，對工程實踐項目--校園二手交易論壇微信小程式開發進行用例模組化，繪制業務類圖，資料模組化，最終形成概念原型，一方面是對課程中所學知識的進一步掌握吸收，另一方面也為工程實踐之後的項目完成打下基礎。
1.項目簡述
此次項目是基于微信小程式的校園二手交易論壇項目，用于校園範圍内的二手商品交易和論壇交流，主要功能包括：商品交易，商品交易，論壇釋出等功能。
2.用例模組化
用例（Use Case）的核心概念中首先它是一個業務過程（business process），經過邏輯整理抽象出來的一個業務過程，這是用例的實質。在待開發軟體所處的業務領域内完成特定業務任務（business task）的一系列活動就是業務過程。
用例有以下幾個基本要素：
1.一個用例應該由業務領域内的某個參與者（Actor）所觸發。
2.用例必須能為特定的參與者完成一個特定的業務任務。
3.一個用例必須終止于某個特定參與者，也就是特定參與者明确地或者隐含地得到了業務任務完成的結果。
2.1用例模組化的基本步驟
第一步，從需求表述中找出用例，往往是動名詞短語表示的抽象用例；
第二步，描述用例開始和結束的狀态，用TUCBW和TUCEW表示的高層用例；
第三步，對用例按照子系統或不同的方面進行分類，描述用例與用例、用例與參與者之間的上下文關系，并畫出用例圖；
第四步，進一步逐一分析用例與參與者的詳細互動過程，完成一個兩列的表格将參與者和待開發軟體系統之間從用例開始到用例結束的所有互動步驟都列舉出來擴充用例。
其中第一步到第三步是計劃階段，第四步是增量實作階段。
2.2對項目進行用例模組化，繪制用例圖
本項目的參與者（actor）可以分為普通使用者和管理者兩種類型，是以分别對這兩種參與者進行用例模組化：
1.普通使用者的用例模組化如下圖所示：
2.管理者的用例模組化如下圖所示：
3.業務領域模組化
3.1業務領域模組化概念
業務領域模組化是開發團隊用于擷取業務領域知識的過程。因為軟體工程師往往需要工作在不同的業務領域或者不同項目中，他們需要業務領域知識來開發軟體系統。軟體工程師往往來自不同的專業背景，這可能會影響他們對業務領域的認知。是以業務領域模組化有助于開發團隊擷取業務領域知識形成統一的業務認知。
開發團隊擷取業務領域知識的過程一般包括收集業務領域相關資訊、執行團隊頭腦風暴、對業務領域相關的知識概念進行分類，最後用UML類圖将業務領域知識圖形化展示。
3.2類和對象UML圖以及常見關系
需求中業務領域内的名詞或名詞短語可能是一個類（Class）或者屬性（Attribute）。是以在進行業務領域模組化時，區分出類和屬性是非常重要的一步。
一個對象作為某個類的執行個體，在業務領域内是能夠獨立存在的，屬性往往不能獨立存在。
類和對象的UML的基本畫法表示如下：
業務領域中兩個概念之間的關系可以分為三類，分别是：繼承關系，聚合關系和關聯關系
1.繼承關系：繼承關系表達着兩個概念之間具有概括化/具體化（generalization/specialization）的關系。一個概念比另一個概念更加概括/具體。比如車輛是是小汽車的概括，小汽車是一種具體的車輛類型。是以繼承關系也被稱為“是一種”（IS-A）關系；
2.聚合關系:聚合關系表示一個對象是另一個對象的一部分的情況。比如發動機引擎是小汽車的一部分。也被稱為“部分與整體”（part-of）的關系；
3.關聯關系：關聯關系表示繼承和聚合以外的一般關系，是業務領域内特定的兩個概念之間的關系，既不是繼承關系也不是聚合關系。
3.3業務領域模組化基本步驟
第一步，收集應用業務領域的資訊。聚焦在功能需求層面，也考慮其他類型的需求和資料；
第二步，頭腦風暴。列出重要的應用業務領域概念，給出這些概念的屬性，以及這些概念之間的關系；
第三步，給這些應用業務領域概念分類。分别列出哪些是類、哪些屬性和屬性值、以及列出類之間的繼承關系、聚合關系和關聯關系。
第四步，将結果用 UML 類圖畫出來。
3.4項目的業務領域模組化
根據分析，目前所需的類有普通使用者類，管理者類，商品類，文章類，評論類；分别分析其屬性和方法及類之間的關系，繪制UML圖如下所示：
4.資料模型設計
4.1MongoDB簡介
MongoDB是一個通用的、基于文檔的、分布式的資料庫，為雲計算時代的現代應用程式開發者而生，沒有資料庫比MongoDB在應用開發效率上更加高效。
MongoDB是一種文檔資料庫，也就是說MongoDB用類似JSON格式的文檔來存儲資料。目前普遍認為JSON格式是了解和存儲資料最自然的方式，JSON格式比傳統的關系資料模型有更強大的資料表達能力。
4.2項目的資料模型
使用者表：
| 字段名 | 類型 | 注釋 |
|---|---|---|
| id | int | 使用者id |
| name | string | 使用者昵稱 |
| phone_number | string | 使用者手機号 |
| email_address | string | 郵箱位址 |
| wx_id | string | 使用者微信賬号 |
| student_number | string | 使用者學号 |
| school_name | string | 學校名稱 |
| 管理者表： | ||
| 字段名 | 類型 | 注釋 |
| ---- | ---- | ---- |
| id | int | 管理者id |
| name | string | 管理者昵稱 |
| phone_number | string | 管理者手機号 |
| email_address | string | 郵箱位址 |
| wx_id | string | 管理者微信賬号 |
| student_number | string | 使用者學号 |
| 商品表： | ||
| 字段名 | 類型 | 注釋 |
| ---- | ---- | ---- |
| goods_id | int | 商品id |
| user_id | int | 釋出商品的使用者id |
| name | string | 商品名稱 |
| price | int | 商品價格 |
| image | string | 商品圖檔位址 |
| publish_time | string | 釋出時間 |
| type | string | 商品類型 |
| information | string | 商品資訊描述 |
| reply_number | int | 評論數量 |
| 論壇表： | ||
| 字段名 | 類型 | 注釋 |
| ---- | ---- | ---- |
| post_id | int | 論壇id |
| user_id | int | 釋出論壇的使用者id |
| name | string | 論壇名稱 |
| image | string | 論壇圖檔位址 |
| publish_time | string | 釋出時間 |
| type | string | 論壇類型 |
| information | string | 論壇内容 |
| reply_number | int | 評論數量 |
| 回複表： | ||
| 字段名 | 類型 | 注釋 |
| ---- | ---- | ---- |
| reply_id | int | 回複id |
| item_id | int | 所屬商品或論壇的id |
| user_id | int | 發表評論使用者的id |
| publish_time | string | 評論時間 |
| information | string | 評論内容 |
5.概念原型總結
概念是人對能代表某種事物或發展過程的特點及意義所形成的思維結論,而概念原型是一種虛拟的、理想化的軟體産品形式。
如下是概念原型的具體定義：
概念原型=用例+資料模型，即上文中我們所分析的部分，是以也可以總結出該項目的概念原型工作過程：
項目參與者主要分為普通使用者和管理者，普通使用者首先進行注冊，在管理者稽核通過之後可以順利進行登入，可以從商品頁面浏覽商品，根據分類選擇自己感興趣的商品，并在感興趣的商品下評論；也可以在論壇頁面浏覽論壇并發表評論；同時使用者也可以釋出自己的文章和商品，在管理者稽核通過之後成功釋出。管理者由可以做到和普通使用者同樣的事情，除此之外，管理者可以稽核進行注冊的普通使用者，通過驗證其學校和學号等資訊使普通使用者使用小程式，并在使用者釋出其商品或者文章後進行稽核，稽核通過之後，該商品或文章可以在商品頁面和論壇頁面公開顯示。
6.小結
此次部落格通過對工程實踐項目進行需求分析，不僅加深了對上課所講内容的了解，同時也對工程實踐項目之後的開發有了更加明确的方向。希望可以借助這次機會培養自己的軟體工程思維，使自己之後的項目開發更加規範。同時本文章由于自己也并未對知識内容完全了解掌握，錯誤之處還望老師和和同學們指正。