Anroid控制核心與整合核心.ppt

Layered/Tiered 軟件最基本分為： 應用程序(applications)層 操作系統(operating system)層 分層之後，可設計標準接口，創造(下層組件)抽換性。 多層級架構 層級多執行效率會下降，彈性會提升。 例如，在Application與File System 之間常加上DBMS層級。 DBMS提供其接口給Applications。 以DBMS層級為例 從Oracle DBMS的崛起可以看得更清楚，Oracle 一方面服務客戶，另一方面抓住ER-Model和SQL標準接口(interface)，有意無意逼迫各種應用軟件符合ER和SQL接口標準。 虛實相依的實踐 從實的Application切出DBMS，則剩餘的Application和DBMS都是實的。 ER-Model和SQL接口協定(protocol)是虛的。 標準化+抽換性 = 強盛 Oracle只要專心支持ER和SQL標準接口，其DBMS軟件就非常容易地賣進去全球各地的企業裡。 因為虛的造就了DBMS 無限的Reuse和 PnP機會。 MVC (model-view-control) MVC是歷久不衰的架構模式 View與Model是兩個Layers。 然後將控制邏輯(control logic)獨立出來。 MVC的啟示(一) 資淺的架構師常犯的毛病是： 將一個大系統分為多個小系統或模組，愈分愈細(小)，模組愈簡單。 然後將簡單的小模組交給資淺的開發者，資深開發者則負責較高層的整合模組。 MVC的啟示(二) MVC告訴我們：軟件模組應該愈分愈細(小)，愈小愈難做。 原來，資淺的架構師在切分時，並沒有逐步將control logic集中到特定小模組裡，而是將 control logic 留在上層模組裡，甚至分散到各View裡。 MVC的啟示(三) MVC告訴我們：一個有機系統(organic system)的控制核心是非常明顯的。 例如人的頭腦、電腦系統的CPU等。 Software Motherboard 這是MVC 的擴充 MVC其控制(或決策)核心Controller是很清晰的。 如果也有清晰的整合核心將更好。 例如人的脊椎、電腦系統的主機板等。 模組間之接口分散了 把接口集中，形成MB 有機體：擁有明確決策和整合核心 架構設計(Architecture Design) Part 6 擅用架构模式(Architecture Patterns) Framework層級 框架(Framework) 這是MVC 的應用 針對特定領域(domain) ，預先將共同C部分(也可含M和V)寫好。 同時藉由面向對象語言(OOPL)的類繼承(class inheritance)機制提供接口，可整合非共同的C, M和V組件(子類)。 設計Framework的要點(一) 框架如同花盆，application如同花。 框架(花盆)提供它與花間的接口。 花盆的developer只要program to the interface。 花的developer也是program to Interface就行了。 設計Framework的要點(二) 設計步驟: Step 1： 構思花的architecture (即final product之代表物)。 Step 2： 構思花盆的architecture。 Step 3： 兩個architecture磨合即得Interface，它是「種花者」與「做花盆者」雙方的agreement。 設計Framework的要點(三) 設計Framework的要點(四) 設計Framework時常犯的毛病: 沒有構思花的architecture。 由花盆architecture單方面提供服 務。 則此服務並非「種花者」與「做花盆者」雙方的agreement，違背Interface設計原理。 IoC (Inversion of Control) 隨著Sprint Framework的普及，其背後的IoC觀念和機制也流行起來。 像Sprint這種幕後含有IoC機制的框架，通稱為IoC 框架。 這種框架能大幅降低系統組件之間的相依性；大幅提升系統整合的彈性和自由度。 IoC機制 + Fa?ade 模式 透過接口進一步降低相依性 存在”人為相依性” 消除”人為相依性” 接口設計 兩個相關system經常需要異地分工及並行開發，開發過程各改變在所難免。 兩個system需要不斷配合對方改變，導致溝通成本提高，難以並行開發。 雙方都Program to an interface，依據接口而分工，施工細節不互相干涉，有效並行開發，進而time-to-market