第12章 使用者介面塑模

本章大綱 學習目標 12.1 導論 12.2 使用者介面靜態結構塑模工作與工具 12.3 使用者介面靜態結構塑模與案例 12.4 狀態圖 12.5 使用者介面狀態塑模與案例 12.6 結構化使用者介面塑模案例 12.7 結論

學習目標 詳讀本章，你至少能瞭解： 使用者介面靜態結構塑模之重要工作與工具。 使用者介面靜態結構塑模之建構步驟與準則。 以Net-PAC 模式、介面藍圖和介面詞彙進行使用者介面靜態結構塑模實例。 何謂狀態圖及其用途。 使用者介面狀態塑模之步驟與準則。

12.1 導論(1/2) 商業資訊系統包括：使用者介面、應用程式與資料庫，而使用者介面是資訊系統與使用者間的溝通橋樑。 與使用者介面相關的塑模工作包含 「使用者介面動態行為塑模」 「使用者介面靜態結構塑模」

12.1 導論(2/2) 圖形化的使用者介面(GUI)是目前資訊系統的主流，許多使用者介面開發工具皆提供多種元件與功能，以滿足使用者對使用者介面之不同需求。 本章將介紹使用者介面的靜態結構與狀態圖塑模工具和方法，說明如何以PAC 模式、介面藍圖、介面詞彙設計出介面架構與介面中細部的元件規格，再配合UI 循序圖建構出狀態圖，以表達一介面內元件與另一介面內元件間之互動行為。

12.2 使用者介面靜態結構塑模工作 與工具 使用者介面靜態結構塑模工作包括使用者介面架構與介面元件的設計，此部分主要處理介面元件之選擇、設計、配置及每個元件的輸出入資訊等。 首先，系統分析師與使用者討論、安排整個畫面的配置，具體描述使用者的操作情形，並由需求塑模結果之活動圖建構「介面架構圖」。 接著，應用「介面藍圖」將使用者需要的系統功能以圖形化的介面元件，如選單、表格、按鈕、訊息視窗、影像、聲音或其他方式表現出來，再以「介面詞彙」決定每個處理中，資訊的輸出入方式和規格。

12.2.1 介面架構圖(1/4) 介面架構圖主要用於描述使用者介面之結構關係，以及介面間運作的控制流程。 PAC(Presentation-Abstraction-Control)模式是常見的介面架構表達工具。其將使用者介面細分成許多子介面，每個子介面可視為一個介面物件，每個物件主要由三個部分所組成：表達(Presentation)、摘述(Abstraction)及控制(Control)。 「表達」定義物件的外觀，並處理訊息的輸出入；「摘述」定義物件的功能及概念；「控制」則是表達與摘述間的溝通橋樑，也是與其他物件相互連繫的管道(Hussey and Carrington, 1997)。

12.2.1 介面架構圖(2/4) 圖12-2 PAC 架構圖範例

12.2.1 介面架構圖(3/4) 傳統的PAC 模式無法表達Web-based 系統中網狀的使用者介面架構，例如超連結(Hyperlink)型態等。 因此，需將PAC 模式擴充成網狀式的Net-PAC 模式，表達Web-based 系統與傳統系統介面。 Net-PAC 模式中之表達、摘述、控制可分別藉由介面藍圖、介面詞彙、循序圖與狀態圖來描述。

12.2.1 介面架構圖(4/4) 圖12-3 Net-PAC 架構圖範例

12.2.2 介面元件(1/2) 介面元件為存在介面中的基本單元物件，包含名稱及屬性，並有固定的操作方式。 其為使用者與系統應用程式間相互溝通的元件，系統中的每個工作處理，不論是資料的輸入、指令的操作或處理訊息的輸出，都需透過介面元件來完成。

12.2.2 介面元件(2/2) 表12-1 介面元件範例

12.2.3 介面藍圖及介面詞彙(1/4) 在介面架構中的每個介面（或子介面），都需以一個介面藍圖(Interface Drawing)和介面詞彙(Interface Glossary)來明確地定義及規範其設計。 介面藍圖可視為Net-PAC 之「表達」，主要應用在幫助設計師視覺化的表達介面所用的元件與元件的配置；而介面詞彙可視為Net-PAC 之「摘述」，主要應用在描述每個介面中元件之細部規格。

12.2.3 介面藍圖及介面詞彙(2/4) 圖12-4 介面藍圖範例

12.2.3 介面藍圖及介面詞彙(3/4) 每個介面藍圖會搭配一個介面詞彙以表達該介面之代號、名稱、說明、介面中各元件的名稱、類型與功能及概念說明。 若該元件可用於顯示或儲存資料庫中的資料，須說明其代表的資料表欄位、資料型態和長度。

12.2.3 介面藍圖及介面詞彙(4/4) 表12-3 介面詞彙樣板

12.3 使用者介面靜態結構塑模與案例(1/8) 使用者介面靜態節構塑模 使用者介面塑模包含了動態行為塑模與靜態結構塑模，兩者皆始於需求塑模。 需求塑模之活動圖中每一個表達輸入與輸出的註記(Note)都可被設計成一個介面。 因此，一系統的每個使用個案活動圖，其輸入與輸出註記之整合為一個階層架構，可被轉換成使用者介面的架構。 進行介面架構圖塑模時，可檢視需求塑模之活動圖上各活動之輸入與輸出註記，及使用者行為是否需要元件的驅動執行等資訊來設計介面，依活動執行順序建構出該系統的介面架構圖。

12.3 使用者介面靜態結構塑模與案例(2/8) 由於UI 循序圖有助於釐清介面架構圖中之控制部分，因此若可在需求塑模完成後先進行UI 循序圖塑模，再進行介面架構圖、介面藍圖和介面詞彙的塑模，將會是一個較佳的做法。 進行使用者介面靜態結構塑模時，可以Net-PAC 模式來建構使用者介面架構圖，每一個介面需表達其「表達」、「摘述」和「控制」(P、A、C)，且給予一個唯一的介面編號與名稱。 接著，可根據Net-PAC 介面架構圖，與使用者討論圖中的每一個介面藍圖，並完成介面詞彙的描述。

12.3 使用者介面靜態結構塑模與案例(3/8) 介面架構圖塑模案例 首先將需求塑模完成的五個使用個案（新增訂購項目、修改訂購數量、刪除訂購項目、取消採購訂單與確認採購訂單）分別編號為1~5。 接著將每個使用個案活動圖之註記都設計成一個介面，依活動的順序決定介面的操作流程，便可完成西子灣線上訂購系統之介面架構圖。 完成之西子灣線上訂購系統介面架構圖，如圖12-5所示；而其部分PAC 表可表達如表12-4 。

12.3 使用者介面靜態結構塑模與案例(4/8) 圖12-5 西子灣線上訂購系統介面架構圖

12.3 使用者介面靜態結構塑模與案例(5/8) 表12-4 PAC 表範例（新增訂購項目使用個案）

12.3 使用者介面靜態結構塑模與案例(6/8) 介面藍圖與介面詞彙塑模案例 完成西子灣線上訂購系統之Net-PAC介面架構圖後，便可詳細描繪每個介面的表達與摘述，其中前者以介面藍圖表達，而後者以介面詞彙表達。 使用者介面之設計可參考需求塑模之活動圖中，有關進行活動時所須顯示之輸入與輸出內容。 「購物車UI」之完整介面藍圖如圖12-6，介面詞彙如表 12-5，其餘介面之介面藍圖與詞彙之塑模方式以此類推。

12.3 使用者介面靜態結構塑模與案例(7/8) 圖12-6 購物車UI 之介面藍圖

12.3 使用者介面靜態結構塑模與案例(8/8) 表12-5 購物車UI 之介面詞彙（部分）

12.4 狀態圖 狀態圖用於表達一個物件、一個使用個案、多個使用個案間或一個系統在其生命週期中之行為，且強調表達狀態及其轉換關係。 一個狀態是一個物件（或系統）在其生命週期中某一時點之一個條件(Condition)或情況(Situation)，在此狀態中，它滿足某條件，執行某活動或等待某事件。

12.4.1 狀態圖之元件(1/7)

12.4.1 狀態圖之元件(2/7)

12.4.1 狀態圖之元件(3/7) 開始狀態(Initial State) 開始狀態是一種狀態，它表達物件生命週期之起點。 一般狀態是一種簡單的狀態，它表達一個物件生命週期中滿足某些條件、執行某些活動或等待某些事件發生的一種情況。 歷史狀態(History State) 歷史狀態是一種虛擬狀態，其為儲存在組合狀態中上一次活動的狀態，使用歷史狀態的機制，可以決定由一個狀態返回另一個狀態時，應回到哪一個先前的狀態。

12.4.1 狀態圖之元件(4/7) 同步組合狀態(Concurrent Composite State) 同步組合狀態是一種狀態，它被分成兩個或更多個同步的子狀態，且當組合狀態被啟動時，所有的子狀態同步被啟動。 循序組合狀態(Sequential Composite State) 循序組合狀態是一種狀態，它包含一個或一個以上的子狀態，且當組合狀態被啟動時，同一時間僅有一個子狀態被啟動。 狀態具深度(States with Depth) 在狀態圖中，常存在不同階層之狀態，也就是說在狀態中還有其他的狀態（稱為子狀態），此情況在狀態圖中通常以階層架構的方式來表示。

12.4.1 狀態圖之元件(5/7) 轉換(Transition) 轉換是指狀態間之結合關係，是觸發物件從一狀態進入另一狀態的事件、成立條件或動作，以一「箭頭」旁註明「事件〔成立條件〕／動作」來表示。 事件(Event)是物件生命週期中一種刺激的發生，它有時間與空間之位置，且能引發狀態轉換。 成立條件(Guard)是事件發生時的判斷條件，只具有真或假的邏輯狀況；若為真則轉換開始執行(Fire)，若為假則轉換不可執行。 動作(Action)與狀態中之活動均屬於處理，但動作是不能分割的，所需處理時間較短（相對於活動），處理過程中不可被事件中斷或暫停。

12.4.1 狀態圖之元件(6/7) 結束狀態(Final State) 結束狀態是物件生命週期之終點。 決策(Decision) 決策同活動圖之決策，為用於表達當轉換發生後，有多個選擇路徑，但僅能依條件選擇其中一個路徑執行之 進入點(Entry Point)、離開點(Exit Point)與終止節點(Terminate Node) 進入點、離開點與終止節點皆為用來連接多個複雜的狀態轉換路徑。

12.4.1 狀態圖之元件(7/7) 轉變(Transition) 轉變可分為接收訊號與發送訊號，為描述兩複合狀態之間的關係，用以表達狀態對於特殊事件之回應。

吳仁和、林信惠(2010) 狀態圖範例

超狀態圖範例

12.4.2 狀態圖之建構步驟與準則(1/3) 找出狀態與狀態間之轉換 狀態是物件（或系統）在其生命週期中某一時間點的一個條件或情況，此狀態可能滿足某條件，執行某活動或等待某事件。 轉換是觸發物件（或系統）從一狀態進入另一狀態的事件、成立條件或動作。 狀態與轉換可從循序圖中物件之操作描述或使用個案描述逐一找出物件（或系統）在某時點之情況、可能發生之條件或事件，執行之動作或動作完成後的情況等。

12.4.2 狀態圖之建構步驟與準則(2/3) 繪製狀態圖 當依上述原則找出所有狀態及相對應的轉換後，就可以繪製初步的狀態圖，繪製狀態圖時可依狀態與轉換間之關係來連接相關狀態。 精煉狀態圖 完成初步地狀態圖繪製後，即可以此狀態圖進行狀態與轉換之改良、找出超狀態或細分出子狀態等。

12.4.2 狀態圖之建構步驟與準則(3/3) 建構狀態圖可參考下列原則︰ 狀態轉換的描述：「事件（成立條件）／動作」三個部分是可選擇性的，不一定要同時具備。 建構狀態圖時，由狀態圖之上方或左上方以「開始」狀態畫起，從系統的觀點依物件行為，將物件生命週期的活動狀態及轉換順序逐一繪出。 自身轉換的表示法是，箭頭由該狀態伸出，繞一圓弧後指向該狀態，並在適當位置說明「事件[成立條件]／動作」。 繪製狀態圖時，其轉換符號應盡量避免交叉。

12.5 使用者介面狀態塑模與案例 在進行使用者介面狀態塑模時，建議先完成UI 循序圖和使用者介面靜態結構塑模，才可瞭解哪些介面進行互動行為，並根據介面藍圖中每個介面使用的元件與配置方式，分析一介面的何種元件啟動了另一介面而完成介面之轉換。 以下將以西子灣線上訂購系統為例，依狀態圖之建構步驟，進行使用者介面互動行為中之狀態塑模。

12.5.1 使用個案之狀態塑模(1/5) 在狀態圖中，可將介面物件內元件分為「資料欄位」與「功能元件」： 資料欄位是顯示資料內容或是等待使用者輸入之格式 功能元件是讓使用者與系統溝通，命令系統執行某項功能之元件。例如使用者以介面內之超連結元件驅動系統執行超連結功能。 以「新增訂購項目」使用個案為例，該個案中有「書籍型錄UI」、「細部說明UI」與「購物車UI」三個介面物件。

12.5.1 使用個案之狀態塑模(2/5) 其中書籍型錄UI 找尋介面物件內元件之方式如下1.所述，其餘介面物件以此類推： 找出狀態 「書籍型錄UI」介面物件中有「書名」、「ISBN」、「細部說明」等屬性，並有一「顯示細部說明」操作。「細部說明」屬性為「顯示細部說明」操作之功能元件，其他屬性則是資料欄位。

12.5.1 使用個案之狀態塑模(3/5) 找出狀態間之轉換 於「書籍型錄UI」中，若客戶想查看某書籍之細部說明，可按下該書籍之「細部說明」功能元件，系統會由「書籍型錄UI」轉移至「細部說明UI」。 於「細部說明UI」，若客戶想回到「書籍型錄UI」，可按下「瀏覽書籍型錄」功能元件，系統會由「細部說明UI」轉移至「書籍型錄UI」。 回到「書籍型錄UI」後，若客戶有意購買任一書籍，可按下「新增訂購項目」功能元件，系統會由「書籍型錄UI」轉移至「購物車UI」。 於「購物車UI」，客戶可設定各書籍之欲訂購數量。

12.5.1 使用個案之狀態塑模(4/5) 繪製狀態圖 其餘介面物件內元件依上述步驟找出後，新增訂購項目使用個案之狀態圖可表達如圖12-10所示。

12.5.1 使用個案之狀態塑模(5/5) 圖12-10 新增訂購項目使用個案之狀態圖

12.5.2 系統狀態塑模案例(1/3) 狀態圖除了可用在使用者介面內各元件間之操作與狀態轉移的塑模外，也可用在系統之行為塑模。 也就是說，狀態圖可用於表達系統之作業處理程序與狀態改變。 西子灣線上訂購系統之塑模結果之狀態圖如圖12-11所示，而該狀態圖之部分狀態轉換表可表達如表12-7所示。

12.5.2 系統狀態塑模案例(2/3) 圖12-11 西子灣線上訂購系統之狀態圖

12.5.2 系統狀態塑模案例(3/3) 表12-7 西子灣線上訂購系統之部分狀態轉移表

12.6 結構化使用者介面塑模案例(1/12) 本節以夢幻系統之送貨處理為例（請參考第6章），配合使用者介面塑模方法論，以描述送貨處理子系統之使用者介面塑模。 使用者介面塑模之過程與結果展示如下。

12.6 結構化使用者介面塑模案例(2/12) 使用者介面需求塑模 夢幻系統之需求塑模請參考第3章，本節僅將送貨處理之描述，摘述於表12-8。

12.6 結構化使用者介面塑模案例(3/12) 由處理描述可進一步分析事件列如下： 業務部進行送貨資料處理，如送貨基本資料的登錄（包括客戶的資料及訂單的資料）、稅率處理、送貨單成品明細處理、送貨金額處理、送貨單資料偵錯處理、送貨單資料儲存處理等。 業務部進行送貨，包括送貨單查詢、送貨單列印，然後將送貨單連同成品運送給客戶，以送貨單與客戶進行確認。

12.6 結構化使用者介面塑模案例(4/12) 使用者介面靜態結構塑模 由夢幻系統的DFD（包含第零階、第一階、第二階與第三階），配合詳細的處理描述，可找出與外部實體有互動之處理，並將之塑模為一個介面。若一處理會使用到多個資料儲存，則可將之拆解成多個介面以便操作，此時便可架構出整個系統的使用者介面架構圖。 以第零階的DFD為例，系統的主介面下包含有五個子介面（也就是第一階的DFD），分別是銷售管理介面、採購管理介面、生產管理介面、基礎項目管理介面及綜合報表管理介面。

12.6 結構化使用者介面塑模案例(5/12) 上述案例可建構出一個階層式介面架構圖，如圖12-12a 。但如果該系統是Web-based系統，則其架構的呈現方式需轉變成階層式與網狀式共存的方式，如圖12-12b。 一個Net-PAC介面架構圖需有一個PAC表以記錄每個介面之表達、摘述與控制，以便於查詢與文件之關聯。圖12-12a之部分PAC表可表達如表12-9。

圖12-12a 夢幻系統階層式介面架構圖

圖12-12b 夢幻系統網狀式介面架構圖

表12-9 PAC表範例

12.6 結構化使用者介面塑模案例(6/12) 完成介面架構圖後，系統分析師需進一步與使用者互動，以共同決定出送貨處理之介面藍圖與介面詞彙。 送貨處理之部分介面藍圖（介面1.2.1.2與介面1.2.1.2.1）範例如圖12-13與圖12-14所示，其介面詞彙可分別表達如表12-10及表12-11所示。

12.6 結構化使用者介面塑模案例(7/12) 圖12-13 介面藍圖（介面1.2.1.2）

表 12-10 圖12-13的介面詞彙 12.6 結構化使用者介面塑模案例 (c.11)

12.6 結構化使用者介面塑模案例(8/12) 圖12-13 2-14 介面藍圖（介面1.2.1.2.1）

表 12-11 圖12-14的介面詞彙 12.6 結構化使用者介面塑模案例 (c.13)

12.6 結構化使用者介面塑模案例(9/12) 使用者介面動態行為塑模 由需求塑模之結果，配合介面藍圖與介面詞彙，我們可分析出使用者介面及其元件間之互動行為。 首先，每一個介面可視為是一個狀態，如介面1.2.1.2及介面1.2.1.2.1可分別形成狀態1.2.1.2及狀態1.2.1.2.1。由介面架構圖中可知這兩狀態間是有關聯，例如可由狀態1.2.1.2進入狀態1.2.1.2.1；反之亦然。 再查看該介面藍圖及其介面詞彙，可發現介面1.2.1.2中的元件「查詢原物料」搭配「按下按鍵」的發生，會離開狀態1.2.1.2然後進入狀態1.2.1.2.1。

12.6 結構化使用者介面塑模案例(10/12) 對每一個狀態，可由介面功能的複雜度來評估是否需進行狀態之細化及群集，例如狀態1.2.1.2.1只是單純地提供原物料明細資料的選單，因此不需要進行狀態的細化。但狀態1.2.1.2中提供的功能包含編修、儲存、存檔後繼續新增、金額的運算與取消，因此可將這些功能細化成五個子狀態：編修、儲存、存檔後繼續新增、金額處理與無明細資料之訊息提示，分別表示成狀態1.2.1.2.A、1.2.1.2.B、1.2.1.2.C、1.2.1.2.D與1.2.1.2.E。 然後再由介面藍圖及介面詞彙中找出這些狀態之狀態轉換（包含事件[成立條件]及動作），最後將狀態圖中的來源狀態、目的狀態及狀態轉換等整理成轉換表，並分別表達如圖12-15與表12-12。

12.6 結構化使用者介面塑模案例(11/12) 圖12-15 介面1.2.1.2之介面狀態圖範例

12.6 結構化使用者介面塑模案例(12/12) 表12-12 介面1.2.1.2之介面狀態圖轉換表

12.7 結論(1/2) 本書提供一套完整的使用者介面塑模方法論，其中包括使用者介面動態行為的UI循序圖塑模、使用者介面的靜態結構塑模以及使用者介面動態行為的狀態圖塑模。 其中介面間之轉換是以UI循序圖表達，而各介面應呈現的架構、藍圖、元件功能與細部資訊是分別以Net-PAC介面架構圖、介面藍圖和介面詞彙表達，而介面內元件運作的邏輯與狀態轉移則是以狀態圖及狀態轉換表等工具表達。 因此，使用者介面塑模需完成之文件包含UI循序圖、Net-PAC 介面架構圖、介面藍圖、介面詞彙、狀態圖和狀態轉換表。

12.7 結論(2/2) 使用者介面塑模方法能讓分析師明確且清楚地根據使用者需求，定義出系統介面，程式設計師也能根據使用者介面塑模結果的文件，完成系統使用者介面的開發，並可與系統程式互相整合。 如透過同一個使用個案的UI循序圖可與表達系統程式的AC循序圖整合。這意謂著使用者介面與程式雖被分開建構，但兩者仍能整合成一個完整的系統。 在使用者介面塑模方法論的研究上，若能運用CASE Tool 讓使用者介面自動產生，將更能提高使用者介面塑模的效率。因此，CASE Tool之研發與應用，將成為使用者介面日後的重要研究方向。