Software Cinema

Wayne Fenton, Director of Architecture at eBay Inc., 在 JAOO 2007 上給了一個 Talk : Operational Scalability in the Next Generation Web World (連結內有側錄影片 + Slides), 雖然影片長達 48 分鐘, 不過內容其實很簡短, 雖然提到很多次 eBay, 但是其實內容是獨立的, 有認真上 Fault Tolerance 的人應該都很容易聽懂內容, 因為都是基本的概念.

事實上我沒有真的找到對於 Operational Scalability 較為嚴格的定義, 看看幾個從不同網頁 Copy 下來的 :

From SOA Magazine [1] :

Operational scalability is the ability of a service-oriented solution architecture to establish and maintain highly efficient and adaptive, cost effective day-to-day operations as the solution grows and scales with time. It is also represents the ability of the architecture itself to be efficiently re-factored to accommodate change and dynamic business requirements.

From Rajith’s Column [2] :

Operational scalability is a software problem and you need to think about operational concerns right from the beginning. Pay attention to,

• Logging metrics, Monitoring.
  
• Controlling/updating/tuning live apps without disrupting traffic.

與 Rajith 類似的說法在 CoverPages 的一篇 Sybase 新聞中也可以看到, 不過搞不太清楚算是甚麼, 比較像是文宣, 就不納入參考.

Leticia Duboc 的 PhD Work [3][4] 認為 Scalability 基本上不容易也不適合有一個通用的定義, 需要視乎不同的系統以及面對不同的 Stakeholder 而異. 因此他們也建立了一個 Scalability Framework, 在不同的情況下去 Initiate 此 Framework, 定義不同的 Scaling Dimensions, Independent Variable, Dependent Variable, 以及 Evaluation Standard ( Scalability Claim ).

We define scalability as a quality of software systems characterized by the causal impact that scaling aspects of the system environment and design have on certain measured system qualities as these aspects are varied over expected operational ranges.

(以下圖片引用自 [4])

這樣我差不多可以稍稍做出結論. 基本上可以說有 Operational Scalability 這東西, 也可以說沒有. 在 [1][2] 中基本上是在特定的觀點下, 面對特定的 Stakeholder 去定義 Operational Scalability, 而其中 [1] 又更偏向一般性的 Scalability 敘述. 而在 Wayne Fenton 的 Talk 中事實上提到了許多不同的 Stakeholders, 不僅僅是一般的 Customers 而已. 因此他的 Operational Scalability 與其說是以 Stakeholders 作區分, 不如說是以 Operational Reliable Service 為中心思想, 並且放在Community 多變的 Web Service Context 下作說明.

Operational 指的是 Service 本身是必須持續運作的, 你幾乎不能考慮停止這項 Service, 必須隨時 Ready for Use, 概念同於古老的 Non-Stop System 概念. 而 Reliable 指的是 Service 可能會更新 Features, 但是不能夠因為新的 Features 而造成不可逆的改變. 這兩項在新時代的 Web Service 上更顯關鍵. 我們很容易有了想法, 很快的成立網站提供服務, 但是隨之而來的使用者人潮跟對於新功能的需求非常難以預料, 這跟過去 Software 面對的情況有顯著不同, Community 的形成之快是超乎預料的, 但是 Community 的衰落之快也同樣難以預期.

而 Operational Scalability 在此情況下, 我認為其實就是針對 Community Change 的 System Scalability.


References

[1] Ted Barbusinski, "SOA Engineering Focal Points," The SOA Magazine, Issue XIX, June 2008
[2] Rajith Attapattu, "Scaling your system - What I learnt from Dan Pritchett’s (eBay) talk"
[3] Leticia Duboc, David S. Rosenblum, and Tony Wicks, "A Framework for Modelling and Analysis of Software Systems Scalability," Proceedings of the 28th international conference on Software engineering, pp. 949 - 952, 2006 ( Syposium Presentation )
[4] Leticia Duboc, David S. Rosenblum, and Tony Wicks, "A Framework for Characterization and Analysis of Software Systems Scalability," in Proceeding of the The 6th joint meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering, ESEC/FSE '07

記得大約是兩年前作 OSS Quality Measurement Project 時看到 SQO-OSS 這個計畫網站的, 當時裡面還甚麼都沒有, 但是畫了很多 Vision 的大餅. 同時間注意到的還有 Ohloh.net ( 之前文章 Assessing Open Source : Ohloh.net ). 後來 Ohloh.net 陸續公佈了許多新的功能以及介面調整, 而 SQO-OSS 不愧是學術計畫, 一直停留在只聞樓梯響的階段.

而現在, Finally, SQO-OSS 也進入 alpha-testing 的階段了, 公佈了一個 Quality Checking Tool, 名為 Alitheis Core. 不過 Demo 網站好像掛點了, 真是不太捧場阿 :p

雖然 Demo 掛點, 不過需要的話可以下載 0.8 或是 0.8.1 的版本, 在這裡可以找到. ( 主要開發語言是 Java, 大心 ^_^ )

Alitheia Core 的 Architectural Overview 可見下圖 (引用自 SQO-OSS 網站 ). 其實並沒有甚麼特別的地方. 值得注意的是此頁的 Title 是寫 Alitheia Core and Metrics, 但是圖中沒有出現 Metrics, 因此也不確定是用在 Information Extraction 或是 Data Mining 的部份. 不管怎樣, 整個系統的運作其實不難理解.


在 Source 裡面的 Metrics Package 含有很多 Sub Packages, 甚至包含 Productivity Metrics. 不過細看很多內容都是空的 ( 這是怎樣 = = ), 也許正在實做中吧.

既然玩不到 Demo, 改來看看公開的 ScreenShots ( Alitheia Core 0.8.x ) 也好. 但其實從 ScreenShot 看來也蠻讓人失望的.


是的, 看起來有很多 Metrics 可以安裝來用, 但是從 Source Code 以外的 Project Artifacts 進行分析的部份看起來還是缺乏. 而即便是已經有的 Metrics, 在能夠連結到更 High Level 的意義之前, 我想對於 OSS Community 的吸引力也不是很大.

不過不管怎麼說, 人家也是有 Product 了, 我們實驗室的還在難產中. 加油吧~~

Borland 今天正式公佈了三個預計於秋季釋出( release ? 販售吧 :p )的新工具. 詳細情況可以參考 Computer World 的這篇新聞 : Borland adds tools aimed at making application development more transparent.

三個 Tools 分別為 :

• TeamDemand : 這個是三個 Tools 裡我覺得最沒想到的. 企圖把 User Requirements 連結到 Development Tasks 以及 Development Process, 想要提供 Business Users ( Customers ) 一個可以即時 ( Real-time ) 獲知目前進度的溝通管道. 我認為這要做得到其實不難, 但要做的好不容易. 簡單的來說, 能夠讓 User 根據 Requirement 隨時輸入 Test Cases 其實就成功一半了, 接下來只要自動找到相對的進度作 Testing 就是另一半, 不過這之間都還隱藏許多問題.
  

• TeamFocus : 看來應該是用來連結 Developers 使用的 Tools, 彙整相關的 Information, 產生開發過程中的相關 Reports. 預計可以大幅降低 Developers 需要花時間在整理 Intermediate Report 的時間.

• TeamAnalytics : 根據 Project 內部可以獲得的各種 Information, 結合在特定 Domain 下適用的不同 Metrics 組合, 量測出 Project 目前的狀態, 對於不佳的情況可以事先給予 Warning. 尚不知內部怎樣管理 Metrics,不過如果是用類似 GQM 方法的話, 應該可以想像 Goal 沒有達到預期就是一種 Warning 了.

現在我在做的其中一個 Project 其實就是 Team Focus + TeamAnalytics, 另外其實再結合另外一個小 Project 也可以朝 TeamDemand 去作, 只是之前沒想到. 不知道該向 Borland 投以敵視的眼神還是感激的眼神 XD

Borland 真是 IDE 界的巨人阿~~

V. R. Basili 在 1984 開始逐步提出 Goal-Question-Metrics 方法 [1] (後有人稱整個相關概念成為一個 paradigm), 而常見的引用以及較為完整的說明可以在 [2] 找到. 關於 GQM 的內涵, 目的以及用處在 [2] 中已有說明, 在此不贅述.

單看字面以及 [2] 的說明, 容易陷入錯誤的迷思, 認為 GQM 的流程在於推導出適合使用的 software metrics 而已. 這顯然是錯誤的認知. 在 Wikipedia 上對於 GQM 列出六個 steps [3], 而關於 software metrics 的推導僅佔了前三個 steps. 以下六個 steps 引用自 Wikipedia:GQM,

1. Develop a set of corporate, division and project business goals and associated measurement goals for productivity and quality
2. Generate questions (based on models) that define those goals as completely as possible in a quantifiable way
3. Specify the measures needed to be collected to answer those questions and track process and product conformance to the goals
4. Develop mechanisms for data collection
5. Collect, validate and analyze the data in real time to provide feedback to projects for corrective action
6. Analyze the data in a postmortem fashion to assess conformance to the goals and to make recommendations for future improvements

然而從這六個 steps 卻很難直覺看出在 GQM process 中, 自 conceptual level, operational level, 到 quantitative level 的 hierarchical relation, 更別說當 software metrics 完成後, 持續對於 product 進行 measurement 時的 goal-satisfaction 是如何藉由 question 被 answer 而達成. 因此我在理解 GQM 時, 是選擇以 GQM 本身的 architecture 為角度去詮釋 GQM 與 software measurement (product measurement) 的關係. 可以用下圖表示 :


我認為 GQM process 應該可以被清楚地分為兩個 phases. 在 Definition Phase 目的是推導或是組合適當的 metrics. 而在 Utilization Phase 則是利用推導的過程得到的產品, 包含 metrics, question 與 metrics 之間的 associations, goal 與 questions 之間的 associations, 自 bottom-up 去檢驗是否 goal 有被滿足, 從而出發 refinement actions. 而在這之中, 實際對於 data 進行 measurement 就發生在 utilization phase 的第一步. 同時這張圖也說明了 GQM 與 software measurement 之間的關聯.

在 GQM 身上事實上還留有許多相當模糊的空間. V. R. Basili 在 [2] 中事實上也是透過 examples 來說明 GQM 的使用而已. 然而這就留下許多問號, 例如究竟我應該選擇哪些 objects 設立 goals ? 怎樣的敘述較像是一個 goal ? 怎樣自 goal 推導出 questions ? 怎樣的敘述比較像是一個 question ? 怎樣為 question 定出合理的 metrics ? 這之中最大的問題可能還是在於 questions 身上, 也就是 operational level 的決定. 在我看過的書以及 papers 中, 對於怎樣使用 GQM 似乎還沒有一個比較明確的 rules 出現. 先階段似乎只能夠根據一些 examples, 或是看看別人的 papers 怎樣利用 GQM 進行說明, 來仿效使用.


References

[1] V. Basili, Barry T. Perricone, "Software Errors and Complexity: An Empirical Investigation," Communications of the ACM, vol.27, no. 1, pp.42-52, January 1984
[2] V. Basili, G. Caldiera, and H.D. Rombach, The Goal Question Metric Approach, Encyclopedia of Software Engineering, pp. 528-532, John Wiley & Sons, 1994.
[3] Wikipedia:GQM, URL : http://en.wikipedia.org/wiki/GQM