網路應用程式設計

當資訊請求端使用者建立任務之後，BIMFeeD 會發出 email 通知給在任務中 被指定的資訊回饋端使用者，接收到通知的使用者可透過 email 中的超連結連至 模式來進行開發，Play Framework 也不例外。

MVC 模式(Model-View-Controller)最早是由 Reenskaug (1979)提出，是一種軟 體架構的設計模式，其將軟體系統分為模型(model)、檢視(view)和控制器(controller)

Yang and Zhang (2006)在設計基於 IFC 的建築物件資訊系統時，同樣採用 MVC 模式來設計其網頁伺服器系統，其中網頁伺服器會先辨別 HTTP request，並轉送至 該 URI 路徑所對應的控制器，控制器負責處理對於物件資訊的請求(request)，並操 控模型以取得相關資料，最後則產生相應的檢視，即呈現具備物件資訊的使用者 介面於網頁瀏覽器。

76

圖 14：MVC 模式的運作方式

BIMFeeD 的網頁伺服器和上述研究的運作流程相似，因此接著以路由(routing)、

控制器、模型和檢視的順序分別說明：

 路由

早期的網頁伺服器大多直接對應檔案的目錄結構，然而大部分採用 MVC 模 式的 web 應用程式框架皆具備自有的路由功能，且幾乎都採用 RESTful 設 計架構，即開發者可指定任意的 URL 位址與任意的控制器對應，而檢視則 主要透過樣板系統來產生，如此可獲得極高的設計彈性。因此，當資訊回 饋端使用者連接 BIMFeeD 網頁伺服器時，Play Framework 會先辨別 HTTP request 之 HTTP 方法和 URL 位址，並呼叫對應的控制器動作(action)或方法 (method)。BIMFeeD 的路由設計如表 4 所示。

表 4：BIMFeeD 路由設計 HTTP

方法 URL 位址 控制器方法

GET / controllers.Application.index()

GET /lite/images/tasks/:file_name controllers.Application.getImage(file_name: String) GET /lite/:taskID controllers.Application.getTaskLite(taskID: String) POST /lite/:taskID controllers.Application.setTaskLite(taskID: String,

recipients: String, modelManagerEmail: String)

77

 控制器

Play Framework 的 控 制 器 必 須 是 一 個 命 名 空 間 為 controllers 、 繼 承 自 Controller 類別的 Java 子類別，根據表 4 的設計，當資訊回饋端使用者在瀏 覽器網址列鍵入/lite/images/tasks/:file_name 的 URL 位址時，表示 HTTP request 為 GET 方法，故路由系統會將此 HTTP request 對應到控制器的靜態 (static)方法，即 Application 類別的 getImage 方法，其中:file_name 代表一個 型別為 String 的控制器方法引數，此控制器主要負責呈現模型的截圖。

 模型

Play Framework 的模型必須是一個命名空間為 models 的 Java 類別，此類別 負責處理控制器所轉發的資料處理要求，例如：當 URL 位址為/lite/:taskID 的 GET 方法被執行時，Application 控制器會將 taskID 這個變數傳送給 getTaskLite 靜態方法，而在此靜態方法中必須呼叫對應的模型類別，透過 該模型類別的方法來取得所需的資料(即請求資訊)，因此模型類別的方法主 要負責向 Redis 資料庫進行 CRUD 操作，並將資料處理結果回傳至控制器，

再由控制器產生(render)一個 HTML 頁面的檢視，此頁面包含任務資訊、模 型截圖、網頁操作模組等，以傳送至瀏覽器供資訊回饋端使用者觀看或操 作，此時 HTTP 狀態代碼也一同被回傳至客戶端。

 檢視

Play Framework 的檢視是一個基於 HTML 的樣板系統，當控制器透過模型 取得所需資料後，將所取得的資料或整個模型類別傳送至樣板系統，則樣 板系統會產生相應的 HTML 頁面，伺服器再將此頁面傳送至客戶端瀏覽器 呈現，例如：當資訊回饋端使用者在網頁操作模組提供模型修改建議時，

其會送出一個 HTML 的表單(form)，此時 URL 位址為/lite/:taskID 的 POST 方法會被執行，故 Application 控制器的 setTaskLite 靜態方法會被呼叫，在

78 在全生命週期的應用本來就有需要整合不同的領域知識(domain knowledge)、使用 工具和工作流程(workflow)，以下用條列的方式來補充十個可讓 BIMFeeD 更加健 全的專業版功能需求：

 專案管理系統之整合

因為在生命週期中會使用許多 BIM 工具，包含設計工具、分析工具、規範 檢核工具等，Singh et al. (2011)提出以模型庫(BIM server)作為多領域 (multidisciplinary)協同作業平台的理論架構，從模型管理、設計審查、資料 安全、模型庫建置環境等不同層面來分析協同作業平台的技術需求。由此 可見，專案管理系統對於 BIM 協同作業而言是基本而必要的(essential)，但 專案管理系統涉及的技術層面和研究議題太廣泛，上述研究也僅是以需求 分析的觀點來提出理論架構，因此 BIMFeeD 若能站在巨人的肩膀上，以現 有的商用軟體或學術研究進行整合，或許也是可行的出路。商用軟體如 Bentley 的 ProjectWise，其自稱為「工程資訊管理和專案合作軟體」；學術 研究如郭榮欽 et al. (2013)的「BIM 工程實作雲端服務平台」，其利用 VDI 技術將協同作業平台在雲端環境佈署，將是未來的趨勢。以下九個功能需 求亦必須以專案管理系統為基礎，始能達到較佳的協同作業效率。