• 1. 專案介紹
• 2. 用例建模
  • 2.1 用例
  • 2.2 用例建模
    • 2.2.1 用例建模基本方法
    • 2.2.2 工程實踐專案用例建模
• 3. 業務領域建模
  • 3.1 業務領域建模基本步驟
  • 3.2 工程實踐專案業務領域建模
• 4.資料模型
• 5.概念原型
• 參考文章

1. 專案介紹

  網路教學平臺突破了傳統教學中時間空間的限制，使學習可以隨時隨地，讓學生可以更好地利用碎片化時間，因此網路共享平臺地搭建成為一個富有意義的專案。

  本專案主要是實現網路共享平臺的網上教學資源共享，以及教學資源的上傳和下載，老師上傳、下載、瀏覽和管理資源，而學生能夠瀏覽和下載教學資源，以及上傳作業等。

2. 用例建模

2.1 用例

  用例的本質就是通過分析使用者的需求，從中邏輯抽象出要完成這一特定需求所需的一系列活動，即業務過程。

  從使用者的角度來看，他們並不想了解系統的內部結構和設計，他們所關心的是系統所能提供的服務，也即被開發出來的系統將是如何被使用的，這就是用例方法的基本思想。

2.2 用例建模

2.2.1 用例建模基本方法

  用例建模的步驟就是通過分析使用者的需求，得到用例模型的開發過程。主要包括如下步驟：從需求中識別抽象用例\(\Rightarrow\)用TUCBW和TUCEW表示的高層用例\(\Rightarrow\)畫出用例圖\(\Rightarrow\)逐一分析擴充套件用例，將使用者與系統的互動過程用兩列表格列舉出來。

2.2.2 工程實踐專案用例建模

  根據上述的用例建模步驟，我們開始對本工程專案實踐進行用例建模

• 需求分析：實現網路共享平臺的網上教學資源共享，實現教學資源的上傳和下載，老師上傳、下載、瀏覽和管理資源，而學生能夠瀏覽和下載教學資源，以及上傳作業等。
• 抽象用例：
  • 參與者：學生
    • 登入
    • 註冊
    • 上傳檔案
    • 下載檔案
    • 查詢檔案
  • 參與者：教師
    • 登入
    • 註冊
    • 上傳檔案
    • 下載檔案
    • 查詢檔案
    • 管理檔案
• 高層用例：通過標註高層用例能夠明確地告訴系統的設計者用例的起始地方和結束地方，程式設計人員在對用例進行模組化程式設計時，可以根據用例的起始狀態和結束狀態，以及中間需要做哪些事情，完整地在模組裡實現相應的需求，而不是模糊地或者跨模組程式設計，這樣會增加系統模組的耦合程度。
  

  • 參與者：學生

    	TUCBW	TUCEW
    登入	學生點選登入按鈕	使用者收到登入成功或失敗通知
    註冊	學生點選註冊按鈕	使用者收到註冊成功或失敗通知
    上傳檔案	學生點選上傳按鈕	使用者收到上傳成功或失敗通知
    下載檔案	學生點選下載按鈕	使用者收到下載開始或下載失敗通知
    查詢檔案	學生點選查詢按鈕	使用者收到相應的檔案資訊或查詢失敗、未找到通知

  • 參與者：教師

    	TUCBW	TUCEW
    登入	教師點選登入按鈕	使用者收到登入成功或失敗
    註冊	教師點選註冊按鈕	使用者收到註冊成功或失敗
    上傳檔案	教師點選上傳按鈕	使用者收到上傳成功或失敗通知
    下載檔案	教師點選下載按鈕	使用者收到下載開始或下載失敗通知
    查詢檔案	教師點選查詢按鈕	使用者收到相應的檔案資訊或查詢失敗、未找到通知
    管理檔案	點選管理檔案	使用者看到對應的管理介面

• 用例圖：
  
  
  
• 分析擴充套件用例：由於本博文主要目的是為了理解並掌握建模方法，若要對每個用例進行擴充套件用例分析會顯得博文十分臃腫，故只列舉登入、檔案下載以及教師檔案管理這三個用例的擴充套件用例分析。

  • Use Case Index：登入系統

    參與者：學生/教師	系統：登入系統
    1.TUCBW 使用者輸入使用者名稱和密碼後點擊登入按鈕	2.系統收到使用者名稱和密碼，對登入進行請求驗證後，向用戶展示登入結果頁面
    3.TUCEW 使用者跳轉到登入結果介面

  • Use Case Index：檔案下載系統

    參與者：學生/教師	系統：檔案下載系統
    1.TUCBW 使用者選擇對應檔案，點選下載按鈕	2.系統收到使用者下載請求，對下載資格進行驗證後，向用戶返回下載成功或失敗結果
    3.TUCEW 使用者接收到下載成功或失敗通知

  • Use Case Index：檔案管理系統

    參與者：教師	系統：檔案管理系統
    1.TUCBW 使用者點選檔案管理按鈕	2.系統收到使用者請求，對資格進行驗證後，向用戶返回檔案管理介面或拒絕訪問通知
    3.TUCEW 使用者跳轉至檔案管理介面或接收到拒絕訪問警告

3. 業務領域建模

  業務領域建模是一個開發團隊獲取業務領域知識，並形成統一的業務認知的有效方法。

3.1 業務領域建模基本步驟

  在業務領域建模的過程一定要謹記：物件獨立存在，而屬性不能獨立存在。

1. 收集業務領域相關資訊
2. 執行團隊頭腦風暴，列出重要的應用業務領域概念，給出這些概念的屬性，以及這些概念之間的關係
3. 對業務領域相關的知識概念進行分類，分別列出類、其屬性和屬性值、以及列出類之間的繼承關係、聚合關係和關聯關係
4. 用UML類圖將業務領域知識圖形化展示

3.2 工程實踐專案業務領域建模

• 收集業務領域相關資訊：

  • 使用者擁有不同的許可權
  • 老師的許可權是上傳、下載、查詢、刪除、移動檔案、建立刪除課程資料夾
  • 學生的許可權是上傳作業和下載、查詢檔案
  • 老師有對應的管理介面，對教學資源進行管理
  • 學生包含學號，姓名，所學課程等
  • 檔案包含檔案型別，名稱，編號，所屬課程，大小，修改時間等資訊
  • 教師包含工號，姓名，所教課程等資訊
  • 許可權包含課程許可權和資源管理許可權
  • 每個課程有對應資料夾

• 頭腦風暴列出各概念分類：

  名詞	使用者、老師、學生、許可權、檔案、資料夾、課程、學號、姓名、檔案型別、名稱、編號、所屬課程、大小、修改時間、工號、所教課程、課程許可權、資源管理許可權
  及物動詞	上傳、下載、查詢、刪除
  所有關係	使用者擁有許可權
  包含關係	學生包含……、老師包含……、許可權包含……、檔案包含……
  X is a Y	老師、學生是使用者

• 根據上述表格畫出UML圖：
  

4.資料模型

資料模型如下

• 學生表

  sid	name	priority	password	phone_number	email

• 教師表

  tid	name	priority	password	phone_number	email

• 課程表

  cid	course_name	folder_id	tid

• 學生選課表

  sid	cid

• 資料夾表

  fid	folder_name	folder_path	course_id

• 檔案表

  fid	file_name	file_path	last_modified_time	size	folder_id

5.概念原型

  概念是人對能代表某種事物或發展過程的特點及意義所形成的思維結論，概念原型是一種虛擬化的、理想化的軟體產品形式。

  概念原型 = 用例 + 資料模型

  概念原型的工作過程大致如下：

• 學生：學生註冊、登入系統後，根據課程名稱以及課程對應資料夾或檔名進行資源查詢，搜尋到具體檔案後可以選擇瀏覽以及下載，使用完成後退出系統。
• 教師：老師登入系統後，可以選擇上傳資源或者對自己上傳的資源進行管理。也可以進行和學生使用者相同的操作，在此不再贅述

參考文章

[1] 面向物件分析與設計之用例建模

[2] 從需求分析到軟體設計.pptx