淺論架構的 POC (Proof of Concepts)

POC, Proof of Concepts, 從字面的意義來解釋的話,即為 “概念性的驗證”。

既然是需要驗證(Proof),所以 POC 是一種 “解決方案(Solution)”,是針對 “概念” 所提出的解決方案,而架構的 POC,目的即在於擷取出最精要、核心的解決方案(Solution),以作為解釋架構的概念依據。

我與 Ringle 聊到 POC,他原來對 POC 的認知是對客戶所提出的一種解決方案,所以主要滿足對象是 “客戶”。不過,對於架構的 POC,我不太認同對象是客戶,我會以為,會希望能透過某種概念性的解決方案,而對架構有整體、全貌性的認知者,那才會是架構 POC 的對象。

所以,誰負責撰寫架構 POC? 我認為是 “架構師(Architect)”,誰想瞭解及驗證架構 POC?我以為是開發團隊所有成員與利益關係人(Stakeholder)。

架構 POC 的對象釐清後,再來是瞭解其呈現的具體樣貌是什麼樣子呢?底下是架構 POC 具化的幾個可能樣貌。

  • 解決方案所需運用的相關技術(Framework, Pattern …)。
  • 利用 UML 語法建構概念模型草圖(Sketch),以表達某一解決方案。
  • 利用模擬(Simulation)的方式提出解決方案。
  • 可以被執行的原型 (Prototype)。

我個人傾向利用可以執行的原型(Prototype)來作為架構 POC 的具體樣貌,因為:

  • 架構師以 “原型” 做為與開發團隊與利益關係人的溝通、達成共識的橋樑,然後才著手執行。透過原型,大家比較容易對概念(Concept)產生共鳴,並致力改變尚未成形的東西。
  • 原型協助架構(Architecture)的建立,讓大家能容易看到整體、更具宏觀的角度來看待複雜系統。並因此而避免一頭就栽進種種的細節(Detail)。
  • 原型可把目標清晰地描繪出來,並且讓每個利益關係人(Stakeholder)都更容易提供意見,進行改革。

而且,架構原型可以:

  • 在架構落實以前,讓團隊成員能自由表達看法,並進行討論、提出建議。
  • 讓團隊成員隨時表達意見,有機會影響你正著手進行的方案。
  • 不斷加快前述兩個步驟(一般稱之為「快速建構原型」)。

對了,架構原型除了比較容易協助團隊成員一窺系統的整體全貌外,對系統內部的結構(Structure)分析與設計的呈現,也能有一番基本的認知。

所以,架構原型的內容,我會擺上表達整體系統的使用案例模型;實做兩、三個具代表性的使用案例,並畫上概念性的類別圖與循序圖;同時,我還會加上與 .NET or J2EE 等平台相依的細部類別與循序圖;實做面,確實可以產出可以執行的程式碼與測試碼;最後,我會利用簡單的 UI(User Interface) 作為執行畫面的呈現與說明。

原型,並非是 “粗糙”,或是 “應付性” 的,它是一個框,是可以被驗證的,但並非僅利用外表美美的圖形使用者介面來對系統作概念性的驗證。架構原型,反而不是重視圖形介面,它要強調的是一種對系統的整體觀與結構觀。至於圖形介面與企業流程的功能,反而不是那麼重視。精密與細節、正確性的工作,是對系統的整體有了正知與正覺,往正確的大方向走後,才確定要做的細節性工作,可以把它作對。人們,尤其是組織性的團隊,最常犯的錯誤是:「把不必要的事情作太好」。

從觀點來解釋架構 — Kenming 看架構 <1>

前言:

架構(Architecture)一詞,非常之難解釋。

若真要一言以蔽之,那麼,可以說,”架構” 是一種整體觀,需要保持從各角度看待架構時,仍有一致性與調和的觀點。

對 ”架構” 要能有充分的理解與認識,至少要能確實瞭解與體會下列幾個與架構至為關鍵的意涵與術語,包括了:整體、觀點(View),包括巨(Macro)觀與微(Micro)觀、焦點(Focus)、層次(Layer)、廣度(Boundary)。

擔任軟體架構師(Software Architect)必備的素養,即在於:觀照整體的能力。

經常我在輔導許多軟體公司的專案開發與教育訓練時,發現到與開發團隊對 “架構” 一詞的認知與定義大不相同。我發現到,大部分的 IT 技術開發人員,所表達出來的架構,是比較偏向於實體層次如 .NET, J2EE 的 IT 技術層次。不是不對,而是 IT 實體層次僅是架構的觀點之一,並不足以代表整體的架構觀。

我想試著利用以上述幾個術語來解釋 “架構”。畢竟,架構的設計,牽涉到相關於設計中系統的議題與範圍太廣了,包括:團隊開發的共識、開發流程(Development Process)的制訂,分工與外包(Outsourcing)控管、系統的彈性、延展(Scalibility)與維護性等。

金剛經有云:「凡所有相,皆屬虛妄,見諸相非相,即見如來」。

“相”,是被具化、可以看得到的形,如同軟體模型,是被具化的產出(Artifact),也就是 “相”。而 “如來”,是不著相的,架構即為如來,所以架構也可以說是一種空、無。

問題來了,既然不著相,你又如何知道何為正道,何為如來?
佛教禪宗有個「以指標月」的譬喻:對於一個從不來不知月亮為何物的人,在蒼茫的星空中,不知那一個叫做月亮,這時候就需要一個認識月亮的人,用手指著月亮說:「那就是月亮」。

同樣的道理,你又能如何瞭解甚至來驗證架構(如來)的正確性呢?
有經驗的架構師(Architect),以各種不同的角度(以上所涵蓋的幾個術語),建構各類型的軟體模型,來看待並解釋「架構」。如同「以指標月」一般,對架構有深一層體會的架構師,會以導師(Mentor)的角色,利用各種工具來具化產出,以引導軟體設計師認識「架構」。

所以,UML, 程式碼等只是個標示工具,真正的「架構」是要靠自己去體會的。

觀點(Viewpoint)

我想首先以 “觀點(Viewpoint)” 一詞來解釋架構。

要能具軟體架構的整體與協調性,最起碼要能有三個觀點:

ˇ 需求面的觀點
ˇ 結構面的觀點
ˇ 實做面的觀點

閱讀全文 »

{軟體架構} Tier vs. Layer Enterprise Architecture

Tier

  • 從巨觀(Macro View)角度界定每一個元件(Component)的主要責任(Responsibility)。
  • 將元件視為 “Whole”,觀察元件之間的互動。
  • ex. Enterprise Application 的三層式(3-tier)架構 – Presentation, Middleware, Database。

Layer

  • 每一個 “Tier” 元件內,由各種不同的組件(Part)組成。
  • 組件與組件間,有階層式(Hierarchy)的關係。
  • ex. Presentation 元件內有 Client/Server Page, Struts/Servlet Framework, J2EE Framework。

Tier and Layer Enterprise Application Architecture
(縮略圖,點擊圖片鏈接看原圖)

與大陸某網友討論架構設計的觀念

晚上大陸某網友 msn 與我對話,討論一些對軟體設計的看法。
他自己有個不錯的 Blog,專門在研究 Middleware and Software Architecture 設計。

網址: http://webscope.blogdriver.com/webscope/index.html

我最喜歡一開始問一個問題了:
「軟體設計的開發會是往 “Top-down” or “Bottom-up” 的模式呢?」

嘿嘿,他沒有被我給騙到,甚至,回文的內容相當地有水平,值得收錄!

“software design more likes “open a black box”,this process can help us to get more hints about the complex of this system,I think “top-down” or “bottom-up” isn’t a way.”

事實上,我回應的是,設計的開發會是 “回饋環路(Feedback Loop)”,他也非常認同,Process 最重要的即在於 “反饋” 與 “溝通”。

他又提問了一個問題,關於如何對架構作 “POC(Proof Of Concept)”。呵呵,我馬上反問:請問架構如何作測試? 他的回答是:不好意思,我常心測、目測。

所以,真正的問題是,到底架構(Architecture) 是什麼?若不清楚到底那個 “架構” 如何 “拿” 出來,又如何測試架構呢?

對 “架構” 這一詞實在非常難之解釋,若是聽到有人是以 RUP 的 4+1 View 來解釋架構,那我大概知道,那對架構的認知應該是太狹隘了。

至少,我個人認為,要能確實瞭解與體會下列幾個與架構至為關鍵的意涵與術語,包括了:
整體、觀點(View),包括巨(Macro)觀與微(Micro)觀、焦點(Focus)、層次(Layer)、廣度(Boundary),才有可能對架構有進一步的認知與體悟。

架構不會是純有形、也不會是純無形;看來很抽象,但有時卻可以很明確地具像化。

架構為 “無” 時,以觀其妙,架構為 “有” 時,以觀其徼。此兩者﹐同出而異名﹐同謂之玄。玄之又玄﹐眾妙之門。 😉

軟體設計師 的 “有所為” 與 “有所不為”

軟體設計師普遍存在著兩個很大的茫點:系統是單一、系統是自己開發的。

例如,進(訂購)、銷(銷貨、出貨)、存(庫存)系統,一般小型的套件(Package)產品都是此三者視為是單一、完整的進銷存系統。所以,當我們在世貿軟體展所看到各家軟體廠商所看的進銷存系統,業務人員所推銷給客戶、以及於其它同類型產品的比較就會偏重在系統的外觀面:系統所提供功能的多寡、完整性與使用者的圖形介面(GUI)。

又如,請假簽核系統,Designer 當一接到要開發這樣的系統時,大部分一開始會先從客戶 “要什麼” ,再據此開發出系統所該提供的功能與服務,然後,以功能需求為導向,”硬寫” 出來電子簽核的處理邏輯。卻很少去思考與分辨,到底,開發的是人事系統,還是簽核系統,又或者,就叫做請假簽核系統?

我常會在課堂上問學員,當你是主機板開發廠商時,你會不會 “打開” CPU 研究內部的結構呢?絕大部分的學員回答說不會。那麼,既然不會,從設計主機板的角度來看時,就會關注在 “如何” 與 CPU 所提供的 “接口(Interface)” 溝通;又,換一個角度,當你是設計 CPU 的開發廠商時,需不需要 “打開” CPU 呢?答案是理所當然,你必須專注在 CPU 的內部結構設計。同時,站在 CPU 設計者的角度,我只要提供 “接口” 供主機板來用,而根本不需要分析主機板的結構。事實上,CPU 設計者,並無法假設會使用 CPU 的就非得是主機板,可能是 PS2 or XBox,都有機會來使用 CPU。

這些是顯而易見的道理,從以上的例子,可以看出,兩個非常重要的設計哲理會被應用在軟體設計領域:一為介面(Interface);一為封裝(Encapsulation)。

“有所為” 即在於,知道什麼是該作的。瞭解你自己的角色,或者知道你現在是用什麼角度在看待系統的設計。當我是華碩主機板設計師時,我會研究 CPU 的規格,知道該如何與之溝通,但卻不會打開,事實上也無從知道,CPU 的內部結構。不需要打開,就會 “封裝” CPU,因為封裝,所以只能透過 “接口” 溝通 ; “有所不為” ,就表示,因為 “封裝” 了 CPU,所以,我沒有必須去分析 CPU 的內部結構,CPU 對我就是 “黑箱(Black Box)”。

回到 “請假電子簽核系統”,應用上述主機板與CPU的例子,若是看成:
請假系統 = 主機板 ; 簽核系統 = CPU

那麼,若你是開發請假系統,你又何必 “打開” 簽核系統來分析與設計內部的結構呢? 反之,若我是開發 “簽核系統”,我可不能假設只有 “請假系統” 會來使用簽核功能而與之 “綁在一起”,也有可能,公文處理、採購等系統也會使用簽核功能吧?

明確瞭解你現在的角色與看待系統設計的角度時,就可以很理性地分辨出 “有所為” 與 “有所不為”。

有所為時,我會 “打開” 有所為之處,關注的是結構分析與設計;有所不為時,我會將之視為是 “黑盒子”,只關注在如何透過該黑盒子所提供的 “接口” 與之溝通。

大格局的軟體設計架構師(Architect),會花很多的時間來觀察與分辨 “有所為” 與 “有所不為”。 “有所不為” 越多,越能顯示其本領。而不會是 “什麼都是自己來,一切都是自己做的”。

P.S.
“主機板” 與 “CPU” 是相對關係,主機板會整合許多的元件(Component,或稱之為組件),包括 CPU;那麼,當站在 CPU 設計者角度時,其實,CPU 也可以視為是 “主機板”,因為,CPU 同樣也必須整合許多組件,包括,暫存器、控制與邏輯運算單元等。

【企業軟體委外】外包程式碼的結構驗收問題

問題陳述—外包程式碼的結構驗收問題

  • 客戶(發包單位)可以透過自動化的功能測試碼來驗證系統功能的正確性,這是屬於系統外觀的驗收範疇。但是,客戶又如何來檢驗外包廠商(承包單位)有依據承包契約(Contract)內的設計藍圖來施工(Coding),確保系統內部的結構(Structure)設計,而不是以沙拉油桶混充建材,偷工減料?

從客戶端的角度來思考對策與解決方案

  • 系統內部結構設計的檢驗重點是什麼?
  • 能利用利器將程式碼反轉(Reverse)成為視覺化的模型,最好就是標準的 UML 圖,而得以方便與快速來作結構的檢驗。
  • 這個利器若能同步反應設計圖與程式碼的變更,那就更理想不過!
  • 因為設計圖與程式碼能透過該利器保持一致性,兩者成為系統的一體兩面:程式碼反應實做;設計圖反應視覺化的模型設計,更因之而能成為標準、實在、確實、非作假的設計產出(Artifacts)文件(Documents)了。

系統結構設計的檢驗核心—相依性分析

  • 兩個元素之間的關係,稱為相依性(Dependency)。
  • A 元件(Component)呼叫(call) B 元件所提供的服務(service),兩者之間構成了相依的關係 — A 相依於 B。
  • A 元件相依於 B 元件,代表當 B 元件變動時,會造成 A 元件的連帶變動。但反之則否(A 元件變動,不會影響到 B 元件)。

範例-A 元件相依於 B 元件
圖、範例-A 元件相依於 B 元件

相依性分析的目的與元素的單位

  • 讓元素之間相依性降低(低耦合性,Low Coupling),變動的影響不大。
  • 相依性分析的元素(或可稱之為元件,Component)單位
    • 類別(Class)
    • 套件(Package)
    • 模組(Module)
    • 子系統(Sub-System)
    • 單一系統
    • 系統與其它系統(如透過 Web Service 介面連接)

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal