一．前言

　　在最近的高階軟體工程課程中，學習到了一種敏捷統一過程的基本建模方法，從需求分析到軟體設計的基本方法。為什麼如此注重需求分析和用例建模呢？正所謂“不重視需求過程的專案團隊將自食其果”。需求分析是產品研發前期的鋪墊工作，也是重要的基礎工作之一。需求工作中的缺陷將給專案成果帶來極大風險，在推出產品時，體現在質量、功能、場景等情境下影響著使用者的滿意度和期望值。那麼我們又為何要進行用例建模呢？因為用例建模很容易成為開發人員之間交流和溝通的媒介，用例模型可以精確地定義軟體需求，出現歧義的可能性很小，這可以保證使用者和開發人員對需求理解的一致性，並且用例模型可以成為我們評估壓法工作量的一個標準，特別是對於迭代式開發言。迭代式開發模型裡，通常依據用例模型來劃分軟體的開發週期：優先級別高的用例會在早期的迭代週期中實現，而優先級別低的用例則被安排在後續的迭代週期中完成。可以通過限制每個迭代週期中的用例個數來保證迭代週期長度的合理性。其次用例模型在整個開發過程中都扮演著非常重要的角色，它可以驅動軟體的分析和設計逐步細化。最重要的是測試過程中使用的測試用例，特別是那些關注軟體功能的測試用例，也是根據用例模型來確定的。

　　本文將結合我的工程實踐專案，進行用例建模和業務領域建模，以及資料建模，最終形成概念原型。將所學知識運用到實踐中，更好的理解這種軟體開發過程。我的工程實踐專案是基於物理模擬的遊戲實踐。物理模擬是指用遊戲中的一些技術實現現實生活中的一些效果，比如：流體模擬，非四輪載具模擬，如摩托車、坦克、直升機，物理破壞，如地形／建築爆破、剛體破碎、衣服／防具破裂，物體燃燒傳播、撲熄，異常時間玩法， 異常空間玩法等使用UE4 遊戲引擎作為工具；使用物理模擬的方法來實現遊戲中的特殊效果；並且結合技術和創意遊戲玩法；實現物理模擬技術專案。下面就讓我們開始吧！

參考文獻：https://gitee.com/mengning997/se/blob/master/README.md

二．需求分析

2.1 什麼是需求分析

　　在進行需求分析之前我們應該瞭解什麼是需求分析。需求分析指的是在建立一個新的或改變一個現存的系統或產品時，確定新系統的目的、範圍、定義和功能時所要做的所有工作，其中包括考慮來自不同利益相關者的需求，確認是否衝突，在衝突的需求之間進行取捨，並針對軟體需求及系統需求進行分析、記錄、確認以及管理。需求分析是軟體專案或系統專案中的關鍵過程，關係專案的成敗。理想的需求要整理成檔案、可以執行、可以量測、可以測試、可以追蹤、和識別到的商業的需求或機會有關，而且要有系統設計的相關設計細節。

　　簡單的來說需求就是對使用者期望的軟體行為的表述；獲取需求就是需求分析師通過關注使用者的期望和需要，從而獲得使用者期望的軟體行為，然後對其進行表述的工作；需求分析是在獲取需求的基礎上進一步對軟體涉及的物件或實體的狀態、特徵和行為進行準確描述或建模的工作。

2.2 需求分析的必要性

　　為什麼在軟體開發中大家總是如此的強調需求分析呢？在軟體工程中，需求分析指的是在建立一個新的或改變一個現存的電腦系統時描寫新系統的目的、範圍、定義和功能時所要做的所有的工作。需求分析是軟體工程中的一個關鍵過程。在這個過程中，系統分析員和軟體工程師確定顧客的需要。只有在確定了這些需要後他們才能夠分析和尋求新系統的解決方法。在軟體工程的歷史中，很長時間裡人們一直認為需求分析是整個軟體工程中最簡單的一個步驟，但在過去十年中越來越多的人認識到它是整個過程中最關鍵的一個過程。假如在需求分析時分析者們未能正確地認識到顧客的需要的話，那麼最後的軟體實際上不可能達到顧客的需要，或者軟體無法在規定的時間裡完工。

　　需求分析是產品研發前期的鋪墊工作，也是重要的基礎工作之一。需求工作中的缺陷將給專案成果帶來極大風險，在推出產品時，體現在質量、功能、場景等情境下影響著使用者的滿意度和期望值。前期沒有任何一項站得住腳的使用者需求分析，領導經常不明白為什麼收集和確保需求質量需要花費那麼多時間。開發人員可能也不重視使用者的參與。大部分情況下，開發人員感覺與使用者接觸不如埋頭寫程式碼、推出新功能代替不足來得效率。某些情況下是因為條件和環境因素而無法獲取來自終端使用者、典型使用者的需求分析，以至於無法預計產品最終上線時的應用情景，方向容易走偏，習慣上線後才根據真實使用者的主動反饋進行被動變更，似是減輕前期成本投入，其實隱形成本已盡透支，這時除了不斷的用更多的成本填補之前的漏缺也別無他法。應儘早讓具有代表性的使用者在專案早起使用者的期望值也在逐步減少。

　　產品和開發人員在實踐過程中也能感覺到，在前期若無足夠的使用者參與，產品人員獲得的需求是片面的，不完整的。而開發人員意識到這樣的程式在開發之初就埋下了風險，因為隨著市場和使用者的需求不斷增加，在開發中若不斷補充需求，專案就越變越龐大以致超過其預算範圍。計劃就不足以對專案的規模和複雜性、風險、開發週期及需求變更進行合理預估，這使得問題更難解決。產品開發中不斷延續的變更會使其結構日見紊亂，補丁程式碼也使得整個程式難以理解和維護。如果你儘早地區別這些可能帶來變更的特性，你就能開發一個更為健壯的結構，並能更好地適應它。

2.3 獲取需求的方法

　　既然需求分析如此重要，那麼我們該通過什麼方法來獲取專案的需求呢？下面將列舉幾個獲取需求的主要方法：

• 與客戶積極主動的溝通與交流

• 檢視可用的文件

• 檢視市面上有相似的系統，進行吸收和改變

• 與使用者一起學習以更詳細地瞭解使用者的任務

• 分別與客戶和使用者進行交流

• 使用特定於領域的策略，例如聯合應用程式設計

• 與現有和潛在使用者進行頭腦風暴

2.4 遊戲專案中的需求分析

　　一款遊戲專案的確立是建立在各種各樣的需求上面的，這種需求往往來自於玩家的實際需求，玩家的實際需求也就是說市場需求最為重要。面對對遊戲擁有不同知識和理解層面的玩家，專案的負責人(或者遊戲製作人)對玩家需求的理解程度，在很大程度上決定了此類遊戲開發專案的成敗。因此如何更好地的瞭解、分析、明確玩家需求，並且能夠準確、清晰以文件的形式表達給參與專案開發的每個成員，保證開發過程按照滿足玩家需求為目的正確專案開發方向進行，是每個遊戲開發專案管理者需要面對的問題。考慮到效能要求，不使用傳統的基於力的物理模擬技術，而是直接計算位置（PBD，物理模擬精度會有一定程度下降，但表現效果不會差太多）。預計上述技術可用於模擬蛇和水人（考慮到水具有張力，或許模擬水人的效果比沙人更好）

　　那麼我們應該完成一款什麼樣的遊戲呢？遊戲功能描述主要包括以下內容：

• 遊戲背景，型別，基本功能 ：以蛇或者沙人的物理模擬為主，遊戲性可以在完成主要的物理模擬之後再完成。
• 遊戲玩家主介面（初步） ：實現3D蛇的爬行以及物理場景（如森林）的模擬。
• 遊戲執行的軟硬件環境 ：通過Unreal4遊戲引擎進行開發，可以實現電腦與手機的同時開發。
• 遊戲系統機制的定義 ：以物理模擬技術為主，最大程度上覆現真實世界上的蛇類爬行。
  
• 遊戲系統的創新特性 ：市面上比較少有真實的蛇類模擬遊戲，可以在物理模擬的基礎上，最大限度實現真實的蛇類模擬。
• 確定遊戲運營維護的要求：隨著專案的進展，不斷完善遊戲的功能。完成蛇的物理模擬之後，可以加入沙人或水人等其他遊戲線。
• 確定遊戲伺服器架設和頻寬要求 ：使用physx物理引擎，和Ue4進行遊戲開發。
• 遊戲總體風格及美術效果標準：偏向真實世界模擬。
• 遊戲等級及技能，物品，任務，場景等的大概數量：可以實現3D的貪吃蛇遊戲，玩家通過移動角色到指定位置來不斷提高等級。
• 開發管理及任務分配：目前準備物理模擬方面每個人都能參加，其他場景的渲染可以分類分工合作。
• 各種遊戲特殊效果及其數量：關鍵點在於實現遊戲中的物理模擬，瞭解物理模擬技術復現現實生活中的場景。
  

三. 用例建模

3.1 用例的概念

　　我們在完成了需求分析之後就可以進行用例建模了。要進行用例建模我們首先需要了解什麼是用例。用例（Use Case）的核心概念中首先它是一個業務過程（business process），經過邏輯整理抽象出來的一個業務過程，這是用例的實質。什麼是業務過程？在待開發軟體所處的業務領域內完成特定業務任務（business task）的一系列活動就是業務過程。用例的資訊流特徵：從待開發軟體外部到待開發軟體內部，然後又到待開發軟體外部，這從最高層級抽象地為我們提供一個資訊流特徵的視角，用來從整體上把握待開發軟體的內外關係。

用例模型主要由以下模型組成：

• 參與者(Actor)：參與者是指存在於被定義系統外部並與該系統發生互動的人或其他系統，他們代表的是系統的使用者或使用環境。
• 用例(Use Case)：用例用於表示系統所提供的服務，它定義了系統是如何被參與者所使用的，它描述的是參與者為了使用系統所提供的某一完整功能而與系統之間發生的一段對話。
• 通訊關聯(Communication Association)：通訊關聯用於表示參與者和用例之間的對應關係，它表示參與者使用了系統中的哪些服務（用例），或者說系統所提供的服務（用例）是被哪些參與者所使用的。
• 系統邊界(System Boundary)：為了使得各個用例與子系統之間的關係更加明確，通常會使用一個系統邊界來表達一個子系統所包圍的用例範圍。

在準確理解用例概念的基礎上，我們可以進一步將用例劃分為三個抽象層級：

• 抽象用例（Abstract use case）。只要用一個幹什麼、做什麼或完成什麼業務任務的動名詞短語，就可以非常精簡地指明一個用例；
• 高層用例（High level use case）。需要給用例的範圍劃定一個邊界，也就是用例在什麼時候什麼地方開始，以及在什麼時候什麼地方結束；
• 擴充套件用例（Expanded use case）。需要將參與者和待開發軟體系統為了完成用例所規定的業務任務的互動過程一步一步詳細地描述出來，一般我們使用一個兩列的表格將參與者和待開發軟體系統之間從用例開始到用例結束的所有互動步驟都列舉出來。

3.2 如何進行用例建模

　　瞭解了什麼是用例模型之後，我們就可以進一步學習如何進行用例建模了：

• 第一步，從需求表述中找出用例，往往是動名詞短語表示的抽象用例；
• 第二步，描述用例開始和結束的狀態，用TUCBW和TUCEW表示的高層用例；
• 第三步，對用例按照子系統或不同的方面進行分類，描述用例與用例、用例與參與者之間的上下文關係，並畫出用例圖；
• 第四步，進一步逐一分析用例與參與者的詳細互動過程，完成一個兩列的表格將參與者和待開發軟體系統之間從用例開始到用例結束的所有互動步驟都列舉出來擴充套件用例。
• 其中第一步到第三步是計劃階段，第四步是增量實現階段。

　　我們如何準確的提取用例呢？

• 第一步，從需求中尋找業務領域相關的動名詞和動名詞短語，比如做什麼事、什麼事情必須被完成，或者執行某任務等；
• 第二步，驗證這些業務領域相關的動名詞和動名詞短語到底是不是用例。驗證業務領域相關的動名詞或動名詞短語是不是用例的標準是滿足四個必要條件：
• • 必要條件一：它是不是一個業務過程？
• • 必要條件二：它是不是由某個參與者觸發開始？
• • 必要條件三：它是不是顯式地或隱式地終止於某個參與者？
• • 必要條件四：它是不是為某個參與者完成了有用的業務工作？
• 如果以上四個必要條件都滿足的話，那麼該業務領域相關的動名詞或動名詞短語就是一個用例。
• 第三步：在需求中識別出參與者、系統或子系統。
• • 參與者會觸發某個用例開始，用例也會顯式地或隱式地終止於某個參與者；
• • 用例會屬於系統或子系統。

3.3 遊戲開發中的用例建模

　　既然知道了什麼是用例模型，以及如果進行用例建模。那麼我們就能夠將所學知識運用到實踐中了。下面是用例圖展示：

圖1 主選單用例圖

圖2 遊戲內用例設計

圖3 遊戲場景渲染與角色控制

四. 業務領域建模

4.1 業務領域建模的概念

　　什麼是業務領域建模呢？這是我在高階軟體工程課程上學習到的新知識。業務領域建模是開發團隊用於獲取業務領域知識的過程。因為軟體工程師往往需要工作在不同的業務領域或者不同專案中，他們需要業務領域知識來開發軟體系統。軟體工程師往往來自不同的專業背景，這可能會影響他們對業務領域的認知。

　　因此業務領域建模有助於開發團隊獲取業務領域知識形成統一的業務認知。 開發團隊獲取業務領域知識的過程一般包括收集業務領域相關資訊、執行團隊頭腦風暴、對業務領域相關的知識概念進行分類，最後用UML類圖將業務領域知識圖形化展示。

　　經過頭腦風暴按照識別規則將業務領域內的資訊提取出來之後，我們需要進一步對這些資訊進行面向物件分析，將其歸類為類、屬性，以及類之間的關係。業務領域概念分類的方法如下：

• 名詞和名詞短語（nouns / noun phrases）可能是類或者屬性；
• Y 的 X（X of Y）表達方法，可能X是Y的屬性，也可能X是關聯關係中的一個參與者，比如中國科學技術大學的小王同學；
• 及物動詞（transitive verbs）往往意味著關聯關係；
• 形容詞（adjectives）一般是屬性值；
• 數量詞（numeric）往往意味著屬性或者屬性值； •
• 所有關係的表達方法（possession expressions）很可能是聚合關係，也可能是屬性；
• 構成關係的表達方法（constituents / “part of" expressions）一般是聚合關係；
• 包含關係的表達方法（containment / containing expressions）一般表示關聯關係或者聚合關係；
• •”X 是一種/類 Y“（X is a Y）表達方法一般是繼承關係；

4.2 如何進行業務領域建模

進行業務領域建模的步驟通常如下：

• 第一步，收集應用業務領域的資訊。聚焦在功能需求層面，也考慮其他型別的需求和資料；
• 第二步，頭腦風暴。列出重要的應用業務領域概念，給出這些概念的屬性，以及這些概念之間的關係；
• 第三步，給這些應用業務領域概念分類。分別列出哪些是類、哪些屬性和屬性值、以及列出類之間的繼承關係、聚合關係和關聯關係。
• 第四步，將結果用 UML 類圖畫出來。 第一步更多地在獲取需求的階段已經完成，這裡不做贅述；

　　在第二步中我們提到了頭腦風暴，那麼我們如何在頭腦風暴中提取業務領域相關的概念呢？團隊成員聚在一起執行頭腦風暴從收集的應用業務領域的資訊中按規則識別業務領域相關的概念，並分別列出。需要識別的規則如下：

• 名詞和名詞短語（nouns / noun phrases）；
• “Y 的 X”（X of Y）表達方法，比如汽車的顏色；
• 及物動詞（transitive verbs）；
• 形容詞（adjectives）；
• 數量詞（numeric）；
• 所有關係的表達方法（possession expressions），比如具有、擁有等；
• 構成關係的表達方法（constituents / “part of" expressions）；
• 包含關係的表達方法（containment / containing expressions）；
• ”X 是一種/類 Y“（X is a Y）表達方法，比如汽車是一種車輛；

4.3 遊戲專案中的UML類圖

　　在完成業務領域建模之後，我們就可以進行UML類圖的繪製了。下面是基於物理引擎為基礎的遊戲專案類圖：

圖4 UML類圖

每個類的含義如下：

• Collisiondetection：碰撞檢測介面類。碰撞檢測技術以及碰撞檢測的處理方式是物理遊戲模擬中最關鍵的技術。

• SnakeCollision：用於檢測蛇與環境的監測，通過時間和蛇的物件來實現isCrash方法，返回是否發生了碰撞。
• CircumstancesCollision：用於檢測環境與其他物體是否發生了檢測，其中包含時間屬性，並實現了Collisiondetection的方法。
• Snake：蛇的物件，包含蛇的基本屬性等。
• Circumstances：環境物件，包含環境的大小，影象，樣式，燈光，位置等屬性。
• Light：光線屬性，用於描述環境。
• Positon：座標類。
• Muscle：肌肉類，用於模擬蛇的肌肉實現。

五. 資料模型的建立

5.1 資料模型的概念

　　什麼是資料模型呢？資料模型是定義資料如何輸入和與輸出的一種模型。其主要作用是為資訊系統提供資料的定義和格式。資料模型是資料庫系統的核心和基礎，現有的資料庫系統都是基於某種資料模型而建立起來的。資料模型所描述的內容包括三個部分：資料結構、資料操作、資料約束。

• 資料結構：儲存在資料庫中物件型別的集合，作用是描述資料庫組成物件以及物件之間的聯絡。
• 資料操作：指對資料庫中各種物件例項允許執行的操作的集合，包括操作及其相關的操作規則。
• 資料完整性約束條件：指在給定的資料模型中，資料及其聯絡所遵守的一組通用的完整性規則，它能保證資料的正確性和一致性。

　　資料模型按不同的應用層次分成三種類型：分別是概念資料模型、邏輯資料模型、物理資料模型。

　　概念資料模型：概念資料模型（Conceptual Data Model），是一種面向使用者、面向客觀世界的模型，主要用來描述世界的概念化結構，它是資料庫的設計人員在設計的初始階段，擺脫計算機系統及DBMS的具體技術問題，集中精力分析資料以及資料之間的聯絡等，與具體的資料管理系統（Database Management System，簡稱DBMS）無關。概念資料模型必須換成邏輯資料模型，才能在DBMS中實現。

　　邏輯資料模型：邏輯資料模型（Logical Data Model），是一種面向資料庫系統的模型，是具體的DBMS所支援的資料模型，如網狀資料模型(Network Data Model)、層次資料模型(Hierarchical Data Model)等等。此模型既要面向使用者，又要面向系統，主要用於資料庫管理系統（DBMS）的實現。

　　物理資料模型：物理資料模型（Physical Data Model），是一種面向計算機物理表示的模型，描述了資料在儲存介質上的組織結構，它不但與具體的DBMS有關，而且還與作業系統和硬體有關。每一種邏輯資料模型在實現時都有其對應的物理資料模型。DBMS為了保證其獨立性與可移植性，大部分物理資料模型的實現工作由系統自動完成，而設計者只設計索引、聚集等特殊結構。

5.2 遊戲設計中的資料模型

　　瞭解了資料模型之後，我們來在實際專案中分析一下吧！在這個工程實踐專案中，資料模型該如何建立呢？

　　概念資料模型：

表1 概念資料模型

　　物理資料模型：

表2 Snake資料模型

表3 環境資料模型

表4 使用者資料模型

六. 總結

　　經過上面的學習之後，我們應該大致明白了軟體的開發過程：需求分析---用例建模---業務領域建模---資料建模---專案維護。需求分析指的是在建立一個新的或改變一個現存的系統或產品時，確定新系統的目的、範圍、定義和功能時所要做的所有工作，其中包括考慮來自不同利益相關者的需求，確認是否衝突，在衝突的需求之間進行取捨，並針對軟體需求及系統需求進行分析、記錄、確認以及管理。。用例（Use Case）的核心概念中首先它是一個業務過程（business process），經過邏輯整理抽象出來的一個業務過程，這是用例的實質。什麼是業務過程？在待開發軟體所處的業務領域內完成特定業務任務（business task）的一系列活動就是業務過程。業務領域建模是開發團隊用於獲取業務領域知識的過程。因為軟體工程師往往需要工作在不同的業務領域或者不同專案中，他們需要業務領域知識來開發軟體系統。軟體工程師往往來自不同的專業背景，這可能會影響他們對業務領域的認知。資料模型是定義資料如何輸入和與輸出的一種模型。其主要作用是為資訊系統提供資料的定義和格式。資料模型是資料庫系統的核心和基礎，現有的資料庫系統都是基於某種資料模型而建立起來的。

　　正所謂“實踐出真知”。在學習了高階軟體工程課程的從需求分析到軟體設計這一小節的課程後，雖然大致明白瞭如何進行用例建模和業務領域建模，以及資料建模，最終形成概念原型。但是還是有許多細節方面無法掌握，在對自己的工程實踐專案使用相同的方法進行分析之後，思路明確了很多。在今後的工作及學習生活中也會給我帶來很多有益的影響。

參考文獻：https://gitee.com/mengning997/se/blob/master/README.md