編輯導讀：介面作為系統的門面，它的設計直接影響到使用者的體驗。一個完整的介面設計需要有兩個層面：業務功能、應用功能。本文作者從應用功能的層面，說明軟體介面的構成，包括概念、作用以及設計方法，希望對你有幫助。
一個完整的介面設計需要有兩個層面：業務功能、應用功能。系列“面設計方法（一）”已經從業務功能（活動、字典、看板和表單）層面介紹了4種功能的設計方法，它們的重點是如何完成不同型別的業務處理設計。
本系列“介面設計方法（二）”，從應用功能層面說明軟體介面的構成，包括概念、作用以及設計方法。“業務功能”相當於功能的邏輯中核，提供了欄位、資料來源、計算邏輯、規則等；“應用功能”相當於功能的可外殼（面板），提供了可以操作選單、工具條、按鈕、欄位框等。前者偏業務、後者偏系統，兩者的結合構成了一個可執行的業務功能。
再回顧一下從需求～設計各階段的工作目的和內容，如圖1所示。
圖1 各階段的介面設計成果示意
1）需求調研階段，圖1（a、b）
將收集到的原始客戶需求（a）透過梳理、歸類、分析和確認工作，完成了功能需求一覽（b），這個一覽的內容就是系統要實現的功能物件，一覽資料中就包括了“業務原型”，這個業務原型可能是使用者提供的一張參考用實體表單（紙質版、或電子表格版），它是後續設計、開發介面的依據。
2）業務設計階段，圖1（c）
針對功能需求的內容，業務處理的目的、業務處理的規律等，將業務功能進行歸集、抽提，劃分出了4種業務功能（活動、字典、看板和表單），這一步從設計角度上將無限多的功能需求種類歸集到了有限的4種，這為業務功能的建模提供了依據，同時也為找到介面設計規律提供了幫助，提升了設計工作的效率、設計成果的複用性，減少了設計難度。
3）應用設計階段，圖1（d）
最後一個階段，再從軟體實現的視角，將前述的4個業務功能進一步拆分、歸集，形成了所示的內容（控制元件），此時這些介面用的控制元件已經與業務沒有直接關係了。
可以得出如下的規律：不論設計什麼業務功能，也不論它們採用了何種介面形式，介面都是由下述控制元件構成的：工具欄、捲軸、按鈕（新增、查詢、儲存……）、欄位框（文字、下來、選擇……）等。因為這些控制元件中不含有業務含義，所以它們就具有了更加廣泛的通用性。
“介面設計方法（2）”系列博文將重點介紹介面的應用設計部分，圖1（d）。完成了從a、b、c、d的工作，就完成了一個業務功能的介面設計全過程。
一、元件的概念實際上一個業務功能並不是僅對應一個介面，而是用一組介面完成的，這一組介面的集合體稱之為“元件”，在介紹介面的設計前先要引入“元件”的概念。
定義：業務元件，是由控制元件構成的可以獨立地執行一個業務功能的系統模組。（對應業務功能的元件，稱之為：業務元件，或簡稱為：元件）
1個業務元件對應1個業務功能（活動、字典、看板、表單）。介面，是元件的重要構成部分，下面對元件的構成進行詳細的介紹。
1. 元件的構成元件是由一組“窗體”構成的，下面以圖2中的“本元件”為主體，說明元件和窗體之間的關係：
圖2 元件概念的示意圖
1 ) 本元件 – 主窗體①
原則上當1個元件內有幾個窗體時，其中只有1個是主窗體。主窗體顯示的是該元件的主要資訊，是一個獨立元件的“臉面”，原則上開啟這個元件時第一個彈出來的窗體應該是主窗體，通常將元件的業務編號、各類操作按鈕等都置於主窗體上。
2 ) 本元件 – 子窗體②③
一個主窗體可以有多個子窗體，根據作用的不同子窗體還可以再分為兩類。
- 查詢用子窗體②：用於查詢透過這個主窗體輸入的歷史資料。
- 輔助用子窗體③：用於顯示主窗體的下級資料、或是分擔主窗體的資料處理工作等。
3 ) 公用元件④
本元件內部的處理常常會需要一些外部元件的資訊作為參考，比如：編制合同時可能需要參考預算的內容，則可以透過連線外部的預算元件；編制預算時可能需要參考企業的規章制度，則此時可以連線企業知識庫元件等，這些外部元件只用來做參考所以稱之為公用元件。
4 ) 上、下游元件⑤⑥
另外，與本元件有資料關聯的外部元件之間在位置關係上做如下定義：
- 上游元件⑤：向本元件輸入資料的元件稱之為上游元件，上游元件所包含的資料、格式、規則等會影響到本元件；
- 下游元件⑥：接受本元件輸出資料的元件稱之為下游元件，本元件的資料、規格、規則等會影響到下游元件；
理解了元件的概念和構成後，開啟元件，進入到元件的內部介紹“窗體”的概念。
1 ) 窗體
窗體：主要由下述4類要素構成：視窗、介面、控制元件、介面。
如何理解窗體的概念呢？下面用一個儀器箱做個比喻，參見圖3（a），窗體就如同安置在這個儀器箱前面的“儀表盤”，使用者透過操作儀表盤上的控制元件發出指令，指令經過箱子中的邏輯層處理然後將要求傳遞到後面的資料層，資料層在按照邏輯層的要求將相應的資料提出來經過邏輯處理後再呈現到前面的“儀表盤”上，這就是窗體的概念和作用。
圖3 窗體與視窗的示意圖
2 ) 視窗
視窗是電腦螢幕上的一個矩形區域（窗體的外邊框）。
關於窗體/視窗的劃分方法，應用設計與技術設計是有所不同的，參見圖3，按照技術設計的定義在這個窗體上顯示了4個視窗（每個視窗對應1個應用程式），但是這種劃分對應用設計來說沒有意義，因為應用設計按照是1個業務元件對應1個業務功能的單位進行設計的，分成若干個視窗後在理解業務和設計時其含義就不完整了。因此，為保持應用設計與業務設計的一致性，將圖3的整體稱之為“1個窗體，且只有1個視窗”，這樣的約定對後續技術設計承接應用設計的成果時不會產生任何影響。
3 ) 介面
窗體清楚之後，下面介紹窗體中的“介面”的概念。
用視窗框圍起來的中間部分稱之為介面，介面上佈置有各類的控制元件，包括：選單、導航欄、工具條、捲軸、按鈕控制元件、欄位控制元件等。可以看出，所有設計的成果最終都要集中到介面的上，介面上佈置內容的多少、佈局的合理性等都直接地影響著使用者的滿意度，因為使用者只能從介面上佈置的要素來體驗“人-機-人”環境設計的優劣。
所謂的“介面設計”指的就是對視窗中這個範圍內佈置控制元件的設計工作。
4 ) 控制元件
理解了介面的概念後，最後再介紹構成介面的最小單位“控制元件”。
控制元件是指佈置在介面上的各類要素，包括：
- 用於其它作用的操控控制元件，如：門戶上的選單樹、導航欄、捲軸等。
- 用於資料操作的按鈕控制元件，如：新增、刪除、儲存、查詢、提交等。
- 用於資料輸入的欄位控制元件，如：列表框、輸入框（文字、下拉、選擇…）。
窗體/視窗、介面和控制元件三者的關係如圖4所示。
圖4 窗體/視窗、介面和控制元件三者的關係示意
3. 業務元件與業務功能的異同前面已經介紹了業務功能和業務元件的概念，這兩者的關係就相當於是在“業務功能”上包裝了一個具有操作功能和介面的 “業務元件”外殼。
1個業務功能對應1個元件，業務功能具有的能力最終是需要由業務元件來落實的。業務功能與業務元件對比有如下特點
- 業務功能：是業務設計中可以獨立完成1個業務目標的最小單元；
- 業務元件：是應用設計中可以獨立支援1個業務功能的最小單元；
前面介紹了元件內部的構成，下面介紹元件對外部的介面。元件的介面繪製在元件主窗體外框上，下面以窗體為物件建立一個窗體模型，透過這個模型理解元件與外部的介面和資訊的交流，此時關注點不在介面上，而在窗體上。如圖5所示，這是一個處理“工程預算”的業務功能。
圖5 元件的介面示意圖
1. 介面的分類將設定在”工程預算”窗體上具有的功能按照使用目的分成三種類型，稱之為IPO，各個字母代表分別代表的含義是
- I：Input，資料的輸入
- P：Process，資料的處理
- O：Output，資料的輸出
1 ) 資料的輸入(I) / 輸出(O)
- 輸入：從上游匯入資料，包括從上游元件選取、接受上游推送的資料、及從資料庫選取資料；
- 輸出：向下遊推送資料，包括向下遊元件或向公用資料庫的推送；
2 ) 資料的處理（P）
用介面的方式將各類操作介面資料的功能與窗體進行關聯，關聯後這些功能可以支援處理窗體內部的資料，從功能的作用上可以將它們分為三個型別：
- 操作功能：這類功能包括了所有對該窗體內資料進行操作的按鈕，比如新增、儲存、提交…等，這些介面的後面可以連線各種不同的管控檢查。
- 連結元件：這類功能可以連結支援主窗體處理的公用元件、資料庫等。可以透過主窗體上的業務編碼、或是其他屬性，直接將相關的資料呈現在本元件的介面上。
- 連結裝置：這類功能可以連線移動裝置、印表機等。
有了上述的“工程預算”視窗功能模型，下面將視窗上的功能透過介面與外部系統關聯起來形成了一個完整的窗體介面模型，參見圖6。
圖6 元件介面模型示意圖
透過這個示意模型，從應用設計的視角上對一個元件的窗體與外部都有哪些關聯有了一個基本的認知，有了這個模型作參考，需要哪些功能就接入相關的控制元件和支援資料/規則，不需要時就可以從介面上分離。由此也可以理解了按照工程化的方法進行軟體設計的方式：先設計小零件 → 由小零件組裝成1個功能控制元件 → 連線到介面上，以此類推地，逐步地完成整個資訊系統的設計。
3. 介面與外部資料的關係下面再將“工程預算”引用的外部資料來源進行關聯，參見圖7，它是一個“工程預算”窗體實際的資料規劃設計圖，可以看出這個編制預算的功能是需要連線很多的資料（包括基礎資料）、操作功能（控制元件）做支援才能完成。
圖7 元件介面規劃（預算編制）
這個示意圖就顯示了一個完整的業務處理功能，其在應用設計時不是被做成了一個固化的整體功能模組，而是用介面連線完成這個業務處理所需要的控制元件和資料，這樣的設計方式可以保證該元件在實際的執行過程中不論發生什麼樣的變化，都可以透過介面的連線與分離快速地響應需求，這就是通常所說的模組化設計和模組化運用的效果。
小結：
介面設計，是元件設計的核心部分，這個設計是透過在介面上表達業務功能、應用功能，並透過這兩者的完美結合給使用者帶來資訊化價值。
擴充套件說明：
為什麼要將介面設計拆分、組合呢？因為透過將調研的功能需求進行拆分，形成4個標準業務功能，再將功能拆分為不同的控制元件，讓控制元件的組合形成窗體、窗體的組合形成元件等一系列的標準化作業，這就為採用“少程式碼、無程式碼”的配置開發方式奠定了基礎。
可以看出，這樣的工作不是一般的需求工程師可以完成的，也不是純粹的程式設計師可以做到的，一定是具有一定的業務知識、抽提建模能力的、同時具有技術開發背景的工程師才能完成的。
詳細的窗體設計說明，請參見《大話軟體工程—需求分析與軟體設計》一書。
本文由 @李鴻君 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議