創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設(shè)計、做網(wǎng)站、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)羅田,十載網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18982081108

前言：

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

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

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

如何設(shè)計平臺框架的<未來性>

1. 未來性：框架設(shè)計的本意

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

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

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

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

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

2. 目前決策的未來性

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

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

圖1、架構(gòu)師提供關(guān)于未來性的知識

3. 具有未來性的API設(shè)計

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

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

圖2、框架API設(shè)計的主要影響因素

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

4.  Steve Jobs的名言：從未來回顧現(xiàn)在

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

4.1  SurfaceView框架為例

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

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

   架構(gòu)師(即框架開發(fā)者)做了決策：SurfaceView搭配Camera。當(dāng)業(yè)主于稍后出現(xiàn)時，業(yè)主沒有選擇的余地，常常不能滿足各業(yè)主的特殊需求，而不想要這個產(chǎn)品或系統(tǒng)。這表示這個系統(tǒng)架構(gòu)的設(shè)計是沒有未來性的，沒有辦法適應(yīng)未來各種不可預(yù)期的環(huán)境變化(如業(yè)主的不同需求)。

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

圖4、為了創(chuàng)造彈性的決策空間，于是點菜單出現(xiàn)了

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

圖5、彈性的決策空間，創(chuàng)造了系統(tǒng)的未來性

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

圖6、醫(yī)院ICU的實時訊息傳遞系統(tǒng)架構(gòu)

4.2  以「拉霸游戲機」為例

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

圖7、Android拉霸機游戲畫面

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

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

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

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

圖8  拉霸機游戲的系統(tǒng)架構(gòu)圖

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

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

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

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

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

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

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

圖10  游戲機框架就成型了

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

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

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

預(yù)留空間給業(yè)主做決策是架構(gòu)師的職責(zé)，而應(yīng)該預(yù)留多大的空間，則是架構(gòu)師對于未來性的洞悉力和技能了。例如，架構(gòu)師可以決定預(yù)留更大空間，如下圖：

圖11 預(yù)留更大空間，設(shè)計出新點菜單

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

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

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

圖13  架構(gòu)師改變了預(yù)留空間

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

圖14  架構(gòu)師的設(shè)計反映與API上

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

5. 具有未來性的API設(shè)計

 架構(gòu)師的職責(zé)不是對業(yè)主(或用戶)的未來行為，進行明確的預(yù)測。架構(gòu)師專注于未來環(huán)境的變化，創(chuàng)造更好架構(gòu)來包容未來環(huán)境的變化。架構(gòu)師要處理的是業(yè)主的未來行為的「變化」，而不是行為本身。所以架構(gòu)師與開發(fā)者的職責(zé)常常是互補的。

   框架是軟件架構(gòu)師用來包容未來變化的尚方寶劍。架構(gòu)師的洞悉力愈好，規(guī)劃出來的框架就愈能給業(yè)主高度的決策空間?；谶@種優(yōu)越的框架的軟硬件相關(guān)產(chǎn)品，會具備良好的未來性，更能掌握美好的商機?！?/p>

EE                                                                  EE

新聞名稱：如何設(shè)計平臺框架的<未來性>
本文來源：http://chinadenli.net/article40/pihgeo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、用戶體驗、網(wǎng)站營銷、網(wǎng)站收錄、外貿(mào)網(wǎng)站建設(shè)、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)