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.小結
此次博客通過對工程實踐項目進行需求分析,不僅加深了對上課所講內容的理解,同時也對工程實踐項目之后的開發有了更加明確的方向。希望可以借助這次機會培養自己的軟件工程思維,使自己之后的項目開發更加規范。同時本文章由於自己也並未對知識內容完全理解掌握,錯誤之處還望老師和和同學們指正。