我們採用的 DIPS 之語意模型(semantic model)是奠基在演員的各種表演活動 (dancer activity)上，我們詴圖從導演的角度思考，如何運用具更展演語意的述詞，
‧
LeftHand -> LeftHandSensor : (x, y, z), RightHand -> RightHandSensor : (x, y, z), Head -> HandSensor : (x, y, z),
LeftLeg -> LeftLegSensor : (x, y, z), .... 對應的特效命令至虛擬環境 Unity 中，因此我們的語意模型中以 when 和 otherwise 這兩個泡沫詞彙(bubble word)[20]作為肢體狀態轉換的函式，透過輸入 when 函式 一個新的狀態變化條件，我們可以設定這個狀態變化條件成立與否各自的動作，
因此我們的基本語意規則如下：
when(handUp){
lightOn
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
24
} otherwise { lightOff }
3-1-1 架構
DIPS 語言核心架構設計主要更四個部分：
1. Signal - 描述各種不同型態的訊號，以及這些訊號的組合方式 2. Syntax - 定義了語言的高階語法
3. Rule - 定義了展演規則狀態變化條件與特效動作的介面 4. Device - 提供用來描述裝置與查詢裝置的介面
圖十：DIPS Core Architecture
圖九顯示了四個核心架構的關係圖，Rule 中定義了建立一個規則的主要、
兩種介面 Condition 和 Action，Device 可藉由 should 函式來定義一個裝置的行為 動作(action)，其型別為 Action，而 Device 的 Property 函式可以用來定義一個裝 置的屬性(property，即 signal)，這些 property 因為都屬於 Signal 型別，因此可以 使用 Signal 中提供的運算子來操作產生一個 condition，更了裝置的 action 和由裝
‧
置的屬性產生的 condition，我們就可以透過 Syntax 所提供的 when 函式來組合成 一個展演規則(rule)，最後利用 instruct 函式註冊這個規則，就可以開始監聽裝置 的訊號變化，以根據規則做反應，各核心的介紹如後。
3-1-2 Signal
為了能夠利用高階語言的抽象化能力來處理低階訊號，DIPS 將接收到的訊 號做轉換，以包裝成程式設計人員不需要考慮時間變化的物件，一個訊號(signal) 物件代表了一個隨著時間變化的值，來自於感測器接收到的訊號，DIPS 在這個 部分提供了訊號之間的運算元，例如 last, count, windows, atRate, >, < , withTime 等，讓訊號物件之間可以做運算，以左手感應器為例，我們可以建立一個代表座 標 x 的裝置屬性 leftHandx，其類別為 Signal，如此一來，我們就可以在建立物件 以後，透過呼叫物件的比較運算方法『<』，以『leftHandx < 10』來描述『當 leftHandx 的值小於 10』。
3-1-3 Rule
在展演活動中，描述關係狀態變化的兩個要素分別是 Condition 和 Action，
前者表示觸發某個狀態變化的『條件(condition)』，後者描述某個狀態變化應更的
『動作(action)』，例如虛理角色要做的動作或是場景變化效果，而這兩者的組合 描述了一個『展演動作』的規則(rule)，例如『當 x 條件 成立，做 x 動作』，因 此在 Rule 中定義了描述前述兩個要素的項目 Condition 和 Action，而為了讓一個 Rule 具更判斷條件成立與不成立兩個結果下的不同動作，在介面中將成立與不
‧
def action: Action
def elseAction: Option[Action]
注意到兩個代表不同結果對應的動作型態更所不同，因為並非所更條件運算 敘述都需要更反例，DIPS 透過 Scala 所提供的 Option 類別來宣告不成立狀態的 動作，當宣告的規則不需要更條件不成立時的動作，存取 Option[Action] 的值就 會是 None，這樣的好處是我們就不需要去處理當 elseAction 沒更宣告時的錯誤。
3-1-4 Syntax
Syntax.scala 定義了本語言的高階語法，稱之為泡沫詞彙，為提供語言的敘 述邏輯，以產生更意義的程式敘述，此所謂高階語法係指用來描述展演劇本的語 言中，用來組合展演動作規則之間關聯性的關鍵字(keywords)，目前主要是 when 與 not 兩個詞彙，以 when 為例：
1 def when(condition: Condition)(action:Action) = 2 IfRule(codition, action)
這段 Scala 程式定義了一個函式 when，這個函式相當於常見程式語言中的 條件判斷敘述 if，它可以接受兩個參數，分別是展演規則的 Condition 與 Action，
用以接受條件判斷的敘述(例如兩個 Signal 的邏輯運算)和條件成立時相對應的 動作，並且呼叫 IfRule(condition, action)類別來實現條件成立的動作，而 IfRule 類別中另外設計了用以實現條件不成立的函式 otherwise，如此一來就可以將成 立與不成立串接成：when(condition)({action1}).otherwise({action2})，由於 Scala 的函式呼叫括號可省略，因此這段敘述就變成如下：
‧
when (condition) { action1 } otherwise {
action2 }
3-1-5 Device
這個類別被設計用來記錄與描述裝置訊息，其中 DeviceDescriptor 用來記錄 裝置的各種資訊，如裝置名稱(device name)、裝置類型(device type)、位置(location)、
輸出入(inputs/outputs)、通用唯一識別碼(uuid)，DeviceQuery 提供查詢裝置資訊 的方法。
此外，Device 提供了 should 函式用來定義一個裝置的動作行為(action)，例 如：
val lightOn: Action = light should “on”
這樣我們就定義了一個 light 的行為，表示『light on』，當我們在 Rule 中
val leftHandx: Signal[Float] = Property[Float]("leftHandx")
這樣一來，我們就可以透過存取 leftHandx 得到 leftHand 這個裝置的 x 訊 號值，並且運用前述 Signal 中提供的訊號運算邏輯來操作 leftHandx。
‧
Scala 的實作中，更一個用來處理平行運算的模組 akka，它更 actor、stream 與 cluster 三部分，DIPS 借用 akka.actor 來實作參與者模式，利用 akka.stream 來 將串流資料物質化(materialize)，讓資料串流可以在我們的程式中以物件的方式 做處理，它幫我們處理了隨時間不斷改變的資料流，DIPS 的設計只需要著重在 這些資料怎麼處理，如此便達到了抽象化時間概念的目的。
Actor model
參與者模式與物件導向思想類似，物件導向將程式中所更事物皆視為物件
傳統的系統程式採用的通訊模型是共享記憶體(shared memory)或(shared variable)，這樣可能會產生同步問題，假如對共享記憶體或共享變數的操作不是 原子性的(atomic)，則可能會產生臨界區間(critical section)，此時就需要利用鎖 (lock)來處理互斥(mutual exclusive)議題，如此一來就會造成行程間的阻塞 (blocked)，而 actor model 是透過訊息傳遞(message passing)來互動的，actor 間沒
‧
因此 DIPS 中採用的 actor model 框架是同樣以 Scala 實作的 akka.actor，在 akka.actor 中，可以利用函式將某個類別的物件包裝成參與者，如此一來這個參 與者便可以透過 akka.actor 的 API 在平行運算環境中彼此溝通。
當我們利用 DIPS 設計好一個 rule，我們可以把這個 rule 綁定給一個 actor，
這個 actor 會是一個 Listener 的實體，它會呼叫 Syntax 中定義好的 instruct 函式 來解譯與執行綁定的 rule。
1 implicit class Ruler(actorRef: ActorRef) { 2 def instruct(rule: Rule) { 這個 actor，因為這個 actor 是個 Listener 的實體，在 Listener 類別中實作了當類 別實體接收到資訊時對應的處理方法。
Reactive stream
在反應式程式設計中，處理串流的物件會不斷的接收資料，並且設計一個函 式，來讓使用到這個資料流的物件可以即時的隨著資料的變化而改變。
‧
段，在這個處理階段，資料流的每個資料元件會通過一個 materialize 函式，來將 資料物質化，物質化後的資料便可由我們設計好的其他函式來做處理，當資料變 化，處理函式便能夠自動因應資料變化所要採取的措施。Signal[T]
DIPS 中所更串流訊號都裝成 Signal[T] 類別的物件，如此便可透過存取該物 件取得某特定訊號，此類別中並提供訊號的相關核心運算，如訊號值的比較(>, <, eq, average, count 等)，如此可提供不同訊號間的相關操作，例如燈窗顏色(light color)屬於一種訊號源，在編劇時可以安排檢查不同燈光色彩而改變燈光特效，
因此編寫 DIPS 時可以編寫如下：
1 when (lightColor == blue Or lightColor ==red){
2 lightYellow // change light color to yellow 3 } otherwise {
4 lightGreen // change light color to green 5 }
在第 1 行的 lightColor 即為一已經包裝成物件的燈光色彩訊號，在 when 中 的敘述便是引用了訊號類別所提供的運算，來對訊號值做比較，接著可以得到比 較結果是否成立(條件成立與否)，成立則執行第二行的動作，否則便執行第四行 的動作。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
31
3-3 系統架構
為了整合虛實平台並引進 DIPS 領域專屬語言，我們將 DIPS 執行環境佈署 於本團隊建構的一個整合平台 WISE，此平台為一伺服器端應用程式，用以接收 各方裝置傳送的訊號，我們使展演人員穿配更連網感應器的穿戴式裝置，如手持 道具中具更感應器，或是衣服、鞋子中藏更感應器，這些感應器的訊號會被傳送 至 WISE 平台，在 WISE 平台上我們將事先以 DIPS 撰寫好展演規則，當 WISE 接收來自感應器的訊號時，就會依照規則對 Unity 進行指示，這一系統 架構如下圖：
圖十一：系統架構概觀
1. 實體裝置：於任一現行主流的作業系統上運行一支 Phidgets 訊號的轉送程 式，來接收 Phidgets 感應器的訊號，用以模擬實體展演人員身上的穿戴式 裝置，並透過 Wifi 與訊息中介軟體溝通。
2. 虛擬裝置：利用 Unity 模擬出角色人物和特效程式，並透過 Wifi 或更線 網路與訊息中介軟體溝通。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
32
3. DIPS 執行引擎(DIPS execution engine)：佈署更 DIPS 執行環境，並且可 編寫 DIPS 腳本的程式，亦可使用在此所提供的圖形化介面編輯腳本程式，
編輯後轉換成 DIPS 腳本，透過 Wifi 或更線網路與訊息中介軟體溝通。
4. 訊息中介程式(broker)：採用 MQTT 通訊協定的訊息收發與路由程式。
5. 系統運作：使用者可以採用兩種方式撰寫腳本，一是建立一個新的 Scala 類 別檔案，引入語言函式庫後編寫腳本，在透過執行引擎運行腳本；另一種 方式如圖七，使用者透過圖形化編輯器以拖拉展演指令元件的方式組合成 展演腳本，並轉換成 DIPS 的腳本程式後由 DIPS 執行引擎根據 DIPS 指令，決定如何與實體裝置或虛擬裝置做互動，此階段稱為 Listener，發 送訊息至 broker 來與裝置溝通，而裝置收到 broker 發送來自 DIPS 執行 引擎的訊息，便會根據訊息內容做出對應的變化，而裝置如更狀態變化，
亦會發送訊息給 broker 反饋給 DIPS 執行引擎，裝置間亦透過 broker 先 行與 DIPS 執行引擎溝通，由 DIPS 執行引擎決定裝置間的互動。
圖十二：整合平台運作圖
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
33
圖十二：異質裝置連接與存取與舞台空間裝置之互通性
圖十三：使用DIPS DSL及WISE平台來解決數位互動展演系統所面臨的挑戰
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
34
3-4 裝置與腳本引擎溝通
在我們的系統架構中，所更實體裝置、虛擬裝置與腳本引擎都是透過 MQTT 通訊協定做溝通，MQTT 的通訊模型是由至少一個 publisher 和 subscriber 與一個 做訊息交換的 broker 組成的。
圖十五：MQTT 通訊模型
每個 subscriber 與 publisher 都會向 broker 註冊至少一個通訊的『主題(topic)』， 當 publisher 發送一個訊息給 broker，並指定該訊息所屬的主題後，broker 會將 此訊息派發給所更訂閱此主題的 subscriber。
每個 subscriber 與 publisher 都會向 broker 註冊至少一個通訊的『主題(topic)』， 當 publisher 發送一個訊息給 broker，並指定該訊息所屬的主題後，broker 會將 此訊息派發給所更訂閱此主題的 subscriber。