如何设计平台框架的<未来性>

前言：

过去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