運作機制與操作邏輯分析

本節先藉由業務流程建模標記法(BPMN, Business Process Model and Notation) (White, 2008)來解釋欲開發系統之運作機制和操作邏輯，接著再針對流程中的任務 (task)、事件(event)和閘道(gateway)逐個分析其背後的設計原理或考量，由於本研 究實際應用到的 BPMN 標記種類並不多，故將有用到的 BPMN 標記符號以表列方 式呈現如表 1。

由 buildingSMART 所主導的 National BIM Standard 採用 BPMN 來作為流程建 模 (process modeling) 的 主 要 表 達 方 式 ， 在 其 資 訊 交 付 手 冊 (IDM, Information Delivery Manual)中的流程圖(process map)亦建議以 BPMN 來表達整個流程進行和 資訊交換之機制，目前亦有不少學術研究將 BIM 的協同作業流程以 BPMN 來表達 (Eastman et al., 2009; 蔡孟君, 2013)，惟 BIM 作業流程有時其實用不到那麼多標記 符號，甚至有些標記方式太過複雜(Park et al., 2011)，故本研究欲開發系統之運作

43

流程僅依照 BPMN 的大原則來繪製，而不包含 IDM 中流程圖所規範的諸多細節，

本研究欲開發之系統名稱為「BIM 模型修改之可互操作物件式資訊回饋系統」(以 下簡稱本系統)，其 BPMN 運作流程圖如圖 4 所示。

表 1：本研究使用之 BPMN 標記符號說明 泳道(swimlane)：對活動加以組織或分類的機制。

池(pool)：

單一流程(process)的容 器(container)。

道(lane)：

排他(exclusive)閘道：

分流時，僅有一個順序流分支會被 執行；合併時，等待僅有一個順序 流分支完成。

內含(inclusive)閘道：

分流時，至少會有一個順序流分 支被啟動；合併時，等待所有已 生效的(active)順序流分支完成。

器物(artifacts)：提供流程之外的額外資訊。

資料庫(data store)：

表示流程內、外所存取的資訊。

資料物件(data object)：

表示流程中的檔案或資料。

連線物件(connecting object)：連接流程的物件。

順序流(sequence flow)：

表示活動進行的順序。

關聯(association)：

建立器物或文字至流程 物件的關係。

44

45

在圖 4 之運作流程中，泳道中共有一個池和五個道，代表本系統有五個不同 的角色或系統，其中資訊請求端和資訊回饋端為操作本系統之兩方使用者，建模 工具外掛程式、資訊回饋資料庫管理系統和網頁伺服器則皆為本系統之構成要素，

接著以條列式說明各個任務、事件、閘道所代表的步驟：

(1) 開始事件：即本系統之運作流程由此事件觸發。

(2) 選取部分模型元件：資訊請求端使用者在建模工具選擇至少一個模型 元件，這些模型元件是需要被修改或更新的。

(3) 執行建模工具外掛程式：資訊請求端使用者在建模工具之使用者介面 中執行本系統之建模工具外掛程式。

(4) 模型展示區域截圖：建模工具外掛程式透過模型端應用程式介面將目 前模型展示區域之螢幕畫面截圖。

(5) 產生使用者介面：建模工具外掛程式透過模型端應用程式介面產生資 訊請求之使用者介面。

(6) 輸入請求資訊並送出：資訊請求端使用者輸入請求資訊並點選送出，

請求資訊應包含：所選取模型元件之物件識別碼、所選取之參數化屬性 識別碼、參數化屬性之數值單位及專案或模型元件基本資訊等等。

(7) 資料結構封裝：建模工具外掛程式透過模型端應用程式介面將請求資 訊封裝為符合資訊回饋資料庫系統資料綱要之資料結構。

(8) 內含閘道：表示接下來至少一個任務會被啟動。

(9) 透過 web 服務上傳請求資訊：建模工具外掛程式透過資訊回饋資料庫 系統之 web 服務將資訊請求端使用者之請求資訊傳回資訊回饋資料庫。

46

(10) 部分模型輸出為 IFC 格式：有關基於 IFC 之網頁伺服器部分，由於本 系統在本研究中只設計一個原型系統，故若未來此功能已趨完善時，建 模工具外掛程式可透過模型端應用程式介面將資訊請求端使用者所選取 之模型元件輸出為 IFC 格式。

(11) 內含閘道：表示目前進展中的任務皆完成後將合而為一。

(12) 上傳至網頁伺服器：建模工具外掛程式透過模型端應用程式介面將模

型展示區域截圖和部分模型之 IFC 檔案上傳至網頁伺服器，由於圖片和 IFC 之檔案大小相對於請求資訊來說大很多，為避免影響資訊回饋資料 庫系統之資訊處理效率，故將其直接上傳至網頁伺服器。

(13) 部分模型之幾何資訊：即已上傳之 IFC 格式模型檔案。

(14) 請求資訊之資料結構：即由資訊回饋資料庫系統所儲存和管理之請求

資訊，其資料結構符合資訊回饋資料庫系統之資料綱要。

(15) 丟擲訊息事件：在請求資訊上傳完畢後，可向資訊回饋端發送一訊息

通知，告知其可經由本系統之網頁伺服器查看請求資訊之內容。

(16) 捕獲訊息事件：資訊回饋端使用者接收到訊息之趨動事件。

(17) 連結網頁伺服器：資訊回饋端使用者經由執行網頁瀏覽器程式(無論使

用何種裝置和平台)以連結本系統之網頁伺服器。

(18) 透過 web 服務取得請求資訊：網頁伺服器透過資訊回饋資料庫系統之 web 服務取得請求資訊。

(19) 傳送請求資訊之內容：資訊回饋資料庫系統透過 web 服務向網頁伺服 器傳送請求資訊。

47

(20) 讀取部分模型之幾何資訊：網頁伺服器將部分模型之幾何資訊(可能為

截圖或 IFC 檔案)解析為瀏覽器程式可讀取之資料格式。

(21) 產生響應式使用者介面：響應式(responsive)使用者介面之概念為根據 不同裝置(如：電腦、平板、手機等)之螢幕解析度而產生不同的使用者介 面。網頁伺服器整合請求資訊和部分模型之幾何資訊，透過模型端應用 程式介面(即其中之網頁操作模組)產生一響應式使用者介面予資訊回饋 端使用者，以讓其進行資訊回饋。

(22) 輸入回饋資訊並送出：資訊回饋端使用者直接經由網頁伺服器所產生

之響應式使用者介面來輸入欲回饋之資訊，例如：參考目前模型元件之 參數化屬性值和其數值單位，輸入新的參數化屬性值，並執行送出指令。

(23) 透過 web 服務上傳回饋資訊：網頁伺服器透過資訊回饋資料庫系統之 web 服務將資訊回饋端使用者輸入之回饋資訊回傳至資訊回饋資料庫。

(24) 回饋資訊之資料結構：即由資訊回饋資料庫系統所儲存和管理之回饋

資訊，其資料結構符合資訊回饋資料庫系統之資料綱要。

(25) 丟擲訊息事件：在回饋資訊上傳完畢後，可向資訊請求端發送一訊息

通知，告知其可由本系統之建模工具外掛程式查看回饋資訊之內容。

(26) 捕獲訊息事件：資訊請求端使用者接收到訊息之趨動事件。

(27) 執行建模工具外掛程式：資訊請求端使用者在建模工具之使用者介面

中執行本系統之建模工具外掛程式。

(28) 透過 web 服務取得回饋資訊：建模工具外掛程式透過資訊回饋資料庫 系統之 web 服務取得資訊回饋端使用者提供之回饋資訊。

48

(29) 傳送回饋資訊之內容：資訊回饋資料庫系統透過 web 服務向建模工具 外掛程式傳送回饋資訊。

(30) 產生使用者介面：建模工具外掛程式透過模型端應用程式介面產生檢

視回饋資訊之使用者介面。

(31) 回饋資訊判定：資訊請求端使用者在檢視回饋資訊後可進行判定。

(32) 排他閘道：代表接下來將只有一個順序流(sequence flow)會被執行。資 訊請求端使用者可告知本系統回饋資訊之判定結果。若回饋資訊被接受，

則與請求資訊相關聯的模型元件會自動被修改或更新；若回饋資訊被取 消，則模型部分不採取任何動作。

(33) 修改並更新模型：若回饋資訊被資訊請求端使用者接受，則與請求資

訊相關聯的模型元件會自動被修改或更新，即建模工具外掛程式會透過 模型端應用程式介面將模型元件之參數化屬性進行修改或更新。

(34) 透過 web 服務上傳判定結果：建模工具外掛程式透過資訊回饋資料庫 系統之 web 服務回傳資訊請求端使用者之判定結果，以作為記錄。

(35) 判定結果：即由資訊回饋資料庫系統所儲存和管理之判定結果，其資

料結構符合資訊回饋資料庫系統之資料綱要。

(36) 結束事件：即本系統之運作流程在此事件結束。

雖然工程專案在生命週期中經常變動，但並非每次變動均牽涉整個 BIM 模型 中的所有物件，故釐清模型元件之間的相關性有其必要，由於參數化的模型元件 同時具備幾何和非幾何屬性資料，有助於掌控模型元件之間的連動性(Sawhney and Maheswari, 2013)。有鑑於此，本研究在規劃整體運作機制時，除了前提是已經具 備一個建置得差不多的 BIM 模型(2.1 節所述)，此模型中的資訊應以 useful minimum

49

 相容性(compatibility)：主要考量不同的 BIM 協同作業者，其使用的硬體 裝置、作業系統、BIM 軟體或工具等，所挑選的技術或工具應力求異質 系統之間的相容性。

 延伸性(extensibility)：主要考量系統開發的生命週期中，若需要將功能性 (functionality)延伸或增加新功能，能否有其彈性和更多的發展空間。

 可擴展性(scalability)：主要考量系統運行階段的可擴充性，當使用者人 數達到預先規畫之上限時，能否將軟、硬體重新配置以容納更多使用者。