如何設計平臺框架的<未來性>

前言：

過去19年來，我(高煥堂)個人在海峽兩岸、日本、美國和西班牙等國擔任大型框架系統設計的實務經驗中，發現到許多框架開發者擺脫不了「AP開發者」的觀點：把買主和用戶視為「大員外」，而開發者變成員外的「長工」，一切設計就以員外的「需求」(Requirements)為依歸。一旦員外需求成維框架設計師心中的圣旨，就很可能會失去本書不斷強調的框架API的「主控權」了。由于AP本來就該緊密跟隨員外的需求，而本來意圖去「框住」AP行為的框架卻也跟隨著員外需求而跑，那框架就沒有存在的意義和價值了。

1. 如何繪制平臺框架的設計圖：使用UML工具

2. 平臺框架(Framework)開發的雕龍之技6招

如何設計平臺框架的<未來性>

1. 未來性：框架設計的本意

----過去19年來，我(高煥堂)個人在海峽兩岸、日本、美國和西班牙等國擔任大型框架系統設計的實務經驗中，發現到許多框架開發者擺脫不了「AP開發者」的觀點：把買主和用戶視為「大員外」，而開發者變成員外的「長工」，一切設計就以員外的「需求」(Requirements)為依歸。一旦員外需求成維框架設計師心中的圣旨，就很可能會失去本書不斷強調的框架API的「主控權」了。由于AP本來就該緊密跟隨員外的需求，而本來意圖去「框住」AP行為的框架卻也跟隨著員外需求而跑，那框架就沒有存在的意義和價值了。

   跟隨著買主和用戶需求跑，并不是貼近其需求的最佳途徑。譬如說，一位完全聽從小孩為所欲為的母親，很可能會寵壞了小孩，所給予的并非小孩的真正需求，因為小孩對「未來的」環境和技術變化的知識并不充足，其明示的需求常常偏于眼前視野。無論是一般的系統架構設計，或者是軟件框架設計，都是關注于：目前決策的未來性。例如：

• 小孩目前就想去買糖果吃(這是目前決策)。

• 媽媽正苦惱著要不要答應小孩(這是目前決策)。

----如果媽媽唯小孩的「需求」是從，每次都答應小孩買糖吃，逐漸地媽媽就失控了(框不住了)，再也沒有替小孩思考未來的空間，導致目前決策偏于眼前短利，目前決策就失去它的未來性了。框架基類就像媽媽，AP子類就像小孩。媽媽有責任要確保整體家庭(或軟件系統)的目前決策具有未來性，以保護小孩未來的健康、安全和成長。

2. 目前決策的未來性

  一般的AP開發，是等買主出現了，買主需求明確了，清晰細述的系統執行的未來情境，然后才開始進行各項目前決策。由于未來已經被買主和開發者所預測好了。目前決策只基于「現實的目前」需求，或基于「預測的未來」需求，就沒有未來性的問題了。一般AP開發者，并不需要、也不習慣于關注未來性。

   然而，框架設計或開發工作，是在「買主來到」之前就開工了。完全依據開發者所擁有的現實需求，以及所預測的未來需求，并無法確保會滿足未來多種買主的心意，以及其心意的轉變。因此，框架設計和開發者，非常需要、也習慣于關注未來性。愈能包容未來變化的決策，就愈有它的未來性。因此，在「分析現實需求」、「預測未來需求」之外，框架設計多了一項關鍵職責：「包容未來變化」。這項決策知識，如下圖所示：

圖1、架構師提供關于未來性的知識

3. 具有未來性的API設計

  試想餐廳食譜的比喻，點菜單里的選項是餐廳設計師所決定的，就如同SurfaceView的SurfaceHolder.Callback接口是由框架設計師所決定的。此外，SurfaceHolder本身的接口(如SurfaceHolder.lockCanvas()函數)也是由框架設計師所決定的。由于買主還沒來，架構師只能預測買主的需求知識，可以透過客戶調查而得知這些預測性的需求項目，但并不能得到真正的需求內涵。就像點菜單上只能憑預測而規劃出一些選項，至于明確的勾選還是要等到買主出現才能定案。這也就是點菜單存在的理由了。

   框架設計師就依據上一小節所述的「包容未來性」知識，加上剛才所說的「預測需求性」知識，來得出接口設計。如下圖：

圖2、框架API設計的主要影響因素

 這個接口(API)設計本身就是一項關鍵性的目前決策，當架構師愈能關注它的未來性，該接口就能包容形形×××的買主，也能包容買主的形形×××需求了。能有效實現上述的未來性效益者，就稱為有效架構師。

4.  Steve Jobs的名言：從未來回顧現在

----為了讓其目前決策能具有好的未來性，有效架構師都很習慣于「從未來回顧現在」(Mapping from vision to reality)。蘋果董事長賈伯斯(Steve Jobs)說過：“你不可能在眺望未來時把生活中的每個點連接起來，只有回顧時能才連點成線”。雖然這聽起來，令人感到有點玄或有些抽象，其實處處皆能看到實例。例如，未來目標是：C家送水到S家。目前決策是：如何把水管從S家拉到C家。為了讓未來目標更穩當可靠(確保未來S家有水喝)，目前決策必須更能包容未來的變化(例如C家沒水了)，提高手段的彈性空間(未來能調整拉水管的方式，能將水管拉到B家等)。

4.1  SurfaceView框架為例

   Camera照相機(C家)能透過鏡頭去取得視像(水)，然后將視像傳遞到SurfaceView窗口(S家)里呈現出來。為了有效的未來，目前透過比較彈性的途徑去將水管拉到對方。請留意，這里是指拉水管的過程，不是水實際流動的路徑。愈具有彈性的「拉水管」途徑，愈能在眼前找到最有效的「送水」(即水管)路徑，也愈能在未來調整送水的路徑。例如下圖的系統架構設計，就是缺乏未來性的：

圖3、少了未來性的決策：只有食譜而沒有點菜單

   架構師(即框架開發者)做了決策：SurfaceView搭配Camera。當業主于稍后出現時，業主沒有選擇的余地，常常不能滿足各業主的特殊需求，而不想要這個產品或系統。這表示這個系統架構的設計是沒有未來性的，沒有辦法適應未來各種不可預期的環境變化(如業主的不同需求)。

  于是，架構師將SurfaceView與Camera兩者的相依性(Dependency)降低，成為疏結合(Loosely Coupled)，預留了彈性，讓業主在稍后出現時，能有決策的空間，并委托AP開發者把其決策寫在AP子類別里。如下圖所示：

圖4、為了創造彈性的決策空間，于是點菜單出現了

----一旦SurfaceView與Camera兩者變成為疏結合(Loosely Coupled)關系了，當業主在稍后出現時，就能做彈性的組合了。例如，委托AP開發者把 SurfaceView聯接到醫院加護病房的儀器設備上。如下圖所示：

圖5、彈性的決策空間，創造了系統的未來性

----所以，在Android框架的支持下，我們將醫院加護病房的儀器聯結到護士站的Android TV(電視機)，讓患者的病情及時傳送到TV上。同時，TV也主動再將訊息及時傳送到醫生的手機或Pad上，讓醫生能進行實時性的決策，提供更高質量的服務。如下圖所示：

圖6、醫院ICU的實時訊息傳遞系統架構

4.2  以「拉霸游戲機」為例

----拉霸機(Slot Machine，簡稱SM)是大家常玩的游戲機，其造型有許多種，例如Android水果盤拉霸機，其畫面如下圖：

圖7、Android拉霸機游戲畫面

----其玩法是先輸入投注金額(Bet)，然后拉動點擊把手或點擊<SPIN>鈕來轉動滾動條，滾動條會各自轉動，然后隨機出現不同圖案，如果停定時，有出現符合相同或特定相同圖案聯機者，即依其賠率而勝出。同一家游戲場里的拉霸機通常會聯網，以投注額厘定累積大獎(Jackpot)金額，并隨時更新累績大獎金額，以便增加吸引性。這游戲軟件可分為兩部分：

• 游戲(Game)端部分，也就是Android手機端的應用對象。

• 柜臺(Console)端部分，也就是GAE云層Servlet對象。

   當玩家押注后，按下<SPIN> 按鈕(開始加速滾動)，游戲端就將「目前余額」和「押注金額」傳送給GAE的柜臺端對象。等待柜臺端對象計算出中獎金額后，將「新余額」和「獎項級別」回傳給Android游戲端(滾動開始減速)，并更新游戲端的畫面。其中，Android游戲端對象(ac01.java)發送HTTP來呼叫GAE云層的Servlet接口，如下圖所示：

圖8  拉霸機游戲的系統架構圖

Android游戲端透過HTTP和Servlet接口來傳送三種訊息給GAE 云層。這三種訊息為：

• 當玩家啟動Android游戲端時，發送"Init:"訊息給GAE云層對象。GAE就從DB里讀取玩家的余額(即上回的余額)，并回傳給游戲端。

• 當玩家按下<SPIN>按鈕時，發送"Bett:amount,bet" 訊息給GAE云對象。此訊息附有余額(amount)和押注金額(bet)，要求GAE對象決定「獎項級別(Rank)」，計算獎金和新余額，然后回傳給游戲端。

• 當玩家欲結束時，按下<Exit>按鈕發送"Fini:amount"訊息給GAE云層。此訊息附有目前余額(amount)，GAE接到訊息，就依據將余額存入DB，完成時立即回復給游戲端，關閉游戲端畫面。

----基于上一小節所提到的未來性概念，我們必須將其<游戲機>端與<云端>兩者的相依性降低，讓兩者之間成為疏結合(Loosely Coupled)關系。這樣可以讓業主有決策的空間：業主可已決定采用那一種云端服務。于是，可以畫出框架需求圖如下：

圖9  設計出點菜單，表達買主(業主)知識

----于是，架構師將游戲機端與與云端兩者的相依性降低，成為疏結合，預留了彈性，讓業主在稍后出現時，能有決策的空間，并委托AP開發者把其決策寫在AP子類別里。如下圖所示：

圖10  游戲機框架就成型了

   這個myGame子類別的用途只是將GameEngine(或GameView)的接口傳遞給云端的Game云服務而已。傳過去之后，Game云服務會主動與gameEngine(或GameView) 溝通，取得對方接口；雙方就相互銜接了。于是，在游戲進行期間，GameEngine與Game云服務之間，是直接互傳訊息(如下注金額和獎項)，并不透過AP來傳遞。

     為了實現上述目標，就必須讓業主(委托 AP開發者)把其決策寫在AP子類別里，然后設計框架接口(如IGame)來與框架基類(如GameView)相銜接。當這個拉霸機游戲軟件框架與云端服務軟件分離了之后，就能將此框架(軟件)與拉霸游戲機(硬件)兩者整合在一起，成為一項軟硬整合產品了，軟硬件可以一起銷售了。

     如果有些業主(如×××)早已經有了云層服務端了，上述的軟硬整合產品就很容易賣進去。因此EIT框架開發思維，非常有益于軟硬整合產品開發，也非常有助于銷售、開拓市場。

預留空間給業主做決策是架構師的職責，而應該預留多大的空間，則是架構師對于未來性的洞悉力和技能了。例如，架構師可以決定預留更大空間，如下圖：

圖11 預留更大空間，設計出新點菜單

----因為要讓業主挑選或自行設計UI，框架就必須將SurfaceView的畫布(Canvas or Surface)傳遞給AP子類別，所以必須修改IGame接口，增添一個函數(如setHolder()函數)。如下圖所示：

圖12 設計出新的框架API(如IGame接口)

  剛才說過了，架構師必須憑借他對于未來性的洞悉力和技能，來決定應該如何預留彈性空間。架構師將其所洞悉而得的，簡明表達于下<框架需求時間圖>里。例如，當架構師洞悉到該替業主預留「調整獎項」的空間時，就會畫出需求圖，如下圖所示：

圖13  架構師改變了預留空間

----對于獎項金額，不同業主可能有不同的調整方法或不一樣的計算公式。也可能同一位業主，但不同×××需要不同的獎項調整公式。此時，這些不一樣的公式就應該撰寫在AP子類別里。而且，框架就必須將云服務所傳來的獎項金額，傳遞給AP子類別，依據調整公式計算之后，在回傳給框架基類別。這時必須修改IGame接口，增添一個函數(如prizeNotify()函數)。如下圖所示：

圖14  架構師的設計反映與API上

Game云服務先把獎項傳給GameEngine，此時GameEngine還不會立即把獎項顯示于UI上；而是呼叫IGame接口的prizeNotify()而傳遞給myGaming。

5. 具有未來性的API設計

 架構師的職責不是對業主(或用戶)的未來行為，進行明確的預測。架構師專注于未來環境的變化，創造更好架構來包容未來環境的變化。架構師要處理的是業主的未來行為的「變化」，而不是行為本身。所以架構師與開發者的職責常常是互補的。

   框架是軟件架構師用來包容未來變化的尚方寶劍。架構師的洞悉力愈好，規劃出來的框架就愈能給業主高度的決策空間。基于這種優越的框架的軟硬件相關產品，會具備良好的未來性，更能掌握美好的商機。◆

EE                                                                  EE