第三章 系統架構
3.3 系統主要元件介紹
國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 3.2，為本論文系統的整體架構圖，分成三個主要部分前端、後端主程式 以及資料庫，以及兩個連接介面，前端與後端主程式的應用程式介面 API 是採用 REST 的設計風格，後端主程式與資料庫的溝通是採用 ORM 的方式。
3.3 系統主要元件介紹
圖 3.3，為本論文的系統主要架構流程，由前端、主程式、資料庫組成，前端分 成 Web Site 和手機 APP 兩個部分，Web Site 負責系統的管理維護，手機 APP 是 主要的遊戲操作，主程式是由 Controller、Service、Dao、Model 四個元件組成。
整個系統流程，是由前端發出請求經由 Controller 轉到對應的 Service，經過 Dao 向資料庫取得所需要的資料，在依序將結果返回前端。
Figure 3.3:系統元件流程圖。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
以下對主程式的四個元件作介紹。
Controller:負責前端與後端的溝通，實作應用程式介面(API)的部分，所有前端 與後端的資料傳遞都需要透過這個元件做處理，同時也包含著大多數的程式運算 邏輯。
Model:定義系統所需要的物件，即資料庫所對應的 TABLE。
Service:是程式的主邏輯，根據需求設計對應的服務。
Dao:主要負責跟資料庫的操作，將和資料庫操作有關的都撰寫在這個元件上，未 來資料庫有更換的話，只要對這一層作修改。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
第四章 系統實作方法
此章節主要在描述本論文系統架構時做的細節，重點會從資料庫設計出發，藉由 Data Modeling 的方式，解釋如何從和使用者討論的抽象概念一步一步轉化成本 論文的程式系統，負責前後端溝通的 REST API 的設計方式，再帶入實作 MVC 架 構的程式的實作細節。
4.1 資料庫設計
從 USER STORY 討論開始，將預計 APP 的使用情境按照流程繪製出來，以確認想 法，然後按照 Data Modeling 的流程先從 USER STORY 中去提取實體，繪製 conceptual data model，如圖 4.1~4.3 所示，這個 APP 運作的主要流程有三項，
第一項是 USER 根據地點打卡，並且將打卡紀錄存入資料庫中，第二項是根據第 一項產生的打卡紀錄去計算出這個時間下的 KEEPER，並將每一期的 KEEPER 存入 資料庫中以供查詢使用，第三項是根據上述兩項 USER 產生的打卡紀錄、KEEPER 紀錄，根據設定好的徽章條件，去計算 USER 是否取得這些徽章。
藉由上述三項流程，可以歸納成三類，如圖 4.4，最基本的實體資料 USER、
PLACE、BADGE，屬於程式邏輯的動作狀態打卡、計算 KEEPER、計算徽章，以及根 據動作衍生出來的資料打卡紀錄、獲得徽章、KEEPER 紀錄，再來將上述實體結合 USER STORY 中的程式流程繪製 logical data model，將資料的細節表達出來，
包括所有實體的關係跟程式邏輯。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
Figure 4.1:APP 流程圖(打卡)。
Figure 4.2:APP 流程圖(獲得徽章)。
Figure 4.3:APP 流程圖(計算 Keeper)。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
Figure 4.4:流程分類。
Figure 4.5:Logical data model。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
圖 4.5，是本論文系統程式的 logical data model，這個 Pervasive game APP 的主要核心是 USER 的打卡紀錄，像是 KEEPER 以及 USER 獲得的徽章都是經 由打卡紀錄所產生出來的，而為了提高程式效能在設計上，會把原本動態產生的 資料，實體化成資料庫中的 TABLE，像是 KEEPER 是由特定期間內的打卡紀錄產 生，產生這一期的 KEEPER 後，就存入另一個 TABLE，這樣要查詢過去歷史的 KEEPER 時就不需要再從打卡紀錄中提取出來，而另一個提升效能的例子是 USER 的徽章 紀錄，從流程上出發，徽章是由 USER 的打卡紀錄中去尋找是否符合獲得徽章的 條件，符合才授予 USER 徽章，這其中需要跨越多個 TABLE，像是打卡、USER、
PLACE、KEEPER、BADGE…等，由此可知計算 USER 是否取的該徽章是件需要大量 效能以及對資料庫存取的工作，因此將 USER 已經獲得的徽章額外建立 TABLE 做 存取，不做重複的計算工作已減輕後端 Server 的負擔。
而在 physical data model 的部分，由於採用了 Object Relational Mapping 的架構，TABLE 的建立是在透過程式中 MODEL 的部分去操作，且為了增加彈性以 及維護性不實際賦予 Table 與 Table 間的主從鍵值關係，即每張 Table 在資料庫 的層級都是各自獨立的，而圖 15 中的關係，則是藉由程式邏輯層再賦予 Table 間的關係，以 USER、PLACE、CHECKIN 這三張 TABLE 為例，在資料庫的層級，都 是互相獨立的，刪除任一筆資料皆不會對另外三張表有所影響，而要在 CHECKIN 建立打卡紀錄資料，是從 USER 以及 PLACE 取得相關欄位值，結合時間資訊存入 CHECKIN，如圖 4.6，也由於這個設計方式，在程式邏輯上要考量到表之間不會有 相依的關係，表與表的關係僅是查詢作用，即刪除一筆 USER 資料，必須不會對 程式造成錯誤。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
，
Figure 4.6:Check in 流程圖。
而在設計上第一層的實體，USER、PLACE、BADGE 是不被刪除的，而是採用狀 態管理的方式決定是否停用，並不實際刪除該筆資料，其他的動態資料以及歷史 紀錄，都是向第一層的實體進行查詢。
4.2 REST API 設計
這個章節是說明前端與後端溝通的應用程式介面 API 的設計，說明為何採用 REST 風格設計，以及實際設計的想法跟概念。
4.2.1 REST API 設計理念
應用程式介面（Application Programming Interface），是為了在系統不同組成 部分相互溝通時的接口，由於現今軟體系統規模越趨複雜，需要把複雜的系統依 照需求規劃分割成各個部分，為了降低系統各個部分的相依性，API 的設計就越 趨重要，好的 API 設計可以提高各模組的內聚性，降低彼此的耦合程度，用以提 高系統的維護跟擴充。
為了降低 API 的獨立性，以及避免網路所造成的錯誤，前端所設計的每個 動作，都只會對應的一個 URL，而不會是一組 URL 來完成動作。
‧
POST /app/user/{userid} 更新個人資料在傳遞資料上，傳統的 URL 會直接把變數名稱放在 URL 上，而採用 REST 設 計的 URL，不會直接看到變數名稱，隱藏了所傳遞資訊的意義，如表 4.2 所示。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
Table 4.2:REST 風格 URL 與傳統 URL 的差異。
傳統 URL /app/place?placeid=01 REST API /app/place/01
以本系統中對於據點進行攻擊防禦的例子，表 4.3。attack 為 1 代表攻擊 0 代表防禦，另外兩個變數代表要攻擊的地點，以及是誰進行攻擊防禦的，可以看 到前者很明確的就能讓別人知道這個 URL 所代表的意義，而後者則可以把傳遞的 資訊隱藏起來，且也更為簡單易用。
Table 4.3:REST 風格 URL 與傳統 URL 差異(本論文例子)。
傳統 URL /app/attack?attack=1&placeid=2&userid=3 REST API /app/attack/1/2/3
4.3 MVC 實作
MVC 程式實作是採用 Spring Framework 撰寫 JAVA 程式，會由 View、Controller，
Model 三個面向來說明。
4.3.1 View
View 分成網頁端以及手機端兩個部分，網頁端是內鑲在 Spring 主程式中，透過 Controller 將對應的 URL 轉到相應的網頁，圖 47，瀏覽器對/user 作出請求，
後端 Controller 返回 USER 的頁面資料到前端瀏覽器顯示，圖 4.8。
Figure 4.7:Controller 程式示意圖。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
Figure 4.8:USER 資料管理頁面。
考量到手機端程式維護不易，在設計手機 APP 時，配合後端傳遞的資料，手 機頁面採用程式自動更新的方式呈現，如圖 4.9 的據點是根據後端回傳的 JSON 資料所自動標記產生，根據後端回傳的頁簽數量自動產生對應的 TAB，再根據傳 回的資料比數建立 listview 頁面，圖 4.10、圖 4.11。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
Figure 4.9:APP 地點頁面。
Figure 4.10:APP 徽章畫面。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
Figure 4.11:API 回傳 JSON 資料(徽章頁面資訊)。
4.3.2 Controller
Controller 是實作 API 地方，根據 URL 具執行所對應的工作，並將結果返回給 前端，如下圖 4.12，是本系統中前端向後端請求某位 USER 現在擔任哪些地方 的 KEEPER，整個程式分成三個部分，前面是設定對應的 URL，後面是採用的 HTTP 方法，中間是邏輯運算的主體，而最後是將結果返回給前端。為了系統的 維護以及 API 的管理，把對資料的運算放在各個 API 之中，優點是當有新的需 求或是有功能要修改時只要重新設計一個新的 URL 即可，不會影響到舊版的手 機 APP 使用。
4.3.3 Model
Model 是由 Model、Service、Dao 三個部分組成，主要負責的是對資料庫的處理，
Model 對應的是資料庫上的表，如圖 4.13，Service 是根據系統所設計的對資料 庫的服務，而 Dao(Data Access Object)是面對資料庫的接口，會直接對資料庫
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
的操作撰寫在這個部分，為了效能的優化，也會讓部分的功能直接撰寫 HQL 去做 資料庫的查詢運算，而非讀取整個資料後在程式中運算，圖 4.14。
4.4 獎勵制度設計
由於另類實境遊戲(ARG)結合定位(Location based service)兩種特性，考量到 進行遊戲時玩家不像是傳統遊戲在固定地點遊玩，因此在每個據點進行遊戲時的 行為本身是必須是相對簡單的，而遊戲的複雜不是建立據點上產生，而是藉由多 個據點的組合或是操作，來進行遊戲。
在本論文設計遊戲的複雜度是利用徽章來達成，圖 4.12，徽章的設計主要 分成三類一個是單一據點的造訪次數，一個是特定幾個地點的組合，另一個是時 間與地點的關係。單一據點的造訪次數，即在某地點累積的造訪次數，如在政大 大仁樓進行指定的操作 10 次即可獲的徽章。特定地點的組合，將附有意義的據 點組合在一起，來讓玩家探索發現，如造訪過全校的圖書館就能獲得徽章。時間 與地點的關係，將特定節日或者時段賦予意義，如在考前一周半夜待在圖書館。
Figure 4.12:APP 徽章設計。
‧
由於本論文開發的Pervasive game app，隨者時間的進展，有進行遊戲機制的變 更，打卡機制變更為巡邏機制，原本的玩家與玩家間的對立關係，即玩家對現
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
本使用的API，只要後端程式進行邏輯修改即可，如據點的佔領機制改變，但 傳遞到手機端的資料一樣是據點、擁有者的相關資訊，就可以在不更動URL 和 前端程式的情況下，進行遊戲機制的改變。手機前端，針對新的遊戲機制，進 行畫面的改動，如原本沒有分陣營，現在玩家分成兩個陣營，一同對抗黑暗勢 力(電腦)。
針對遊戲機制改變所做的變更，在本論文設計的系統架構下前端變動的幅
針對遊戲機制改變所做的變更，在本論文設計的系統架構下前端變動的幅