Software Cinema

在 The Computer Language Benchmarks Game ( http://shootout.alioth.debian.org/ ) 網站上提供了由大約 18 個 benchmarks, 由對於大約 34 種 programming languages 的 implementation 作 benchmarking 的結果. 並提供方便的統計或比較觀點查看結果. 他們的計畫網頁可以在 Alioth GForge 找到 : Shootout@Alioth-GForge

例如 Java 6 -server 對 Python 的比較結果 : ( 這兩者在 CPU Time 跟 Memory Usage 上的差異還真是明顯 )

或是可以對於不同的 benchmarks 給予不同的 weights, 進而調整 benchmarking 的結果.


不過當然, 這些 benchmarking 只能反應這些 programming languages 之間比較的小部份面向而已, 就軟體工程的角度而言, 選擇 programming languages 時要考慮的 factors 比這裡所能呈現的多太多了.

但是從這點出發, 是否未來有一天, 我們也可以靠著在這樣的網頁上, 選取跟目前進行中的 project 相關的 benchmarks, 以及要衡量的 factors, 就決定要利用哪種 programming language 進行開發呢 ? 例如上面的 benchmark 中, 包含了許多基本的 data structure 以及 algorithms 作為 benchmarks, 如果這些 benchmarks 可以組合起來, 提供更為 high-level 的 evaluation benchmark, 同時加上不同的 programming languages 在 architectural components 上得 benchmarks, 那麼我們可能就可以找到更多在軟體工程中可以被利用的 benchmarks, 進而更容易決定 programming languages 的選擇.

之前在對於某個 software measurement 想法進行 prototyping 時, 因為短時間內需要建立數個不同 programming languages 的 parsers, 同時還要能容易取得 parsing results, 因此很傷腦筋. 雖然已經有類似 ANTLR 的 parser generator, 但是寫 grammar file 還是很麻煩的一件事, 而別人已經寫好的 grammar file 能支援的 programming languages 也有限, 有些是尚沒有最新版本的 grammar files, 有些則是要自己寫. 而就算寫出來, 通常 parser generator 也不會特別幫你設計 parsing information 存取的 interface, 還是需要手動去 parser 裡面作一些修改, 一整個麻煩.

因為想偷懶, 結果就把腦筋動到支援較多 programming language 的 source code document generator 上, 例如 Doxygen.

Source code document generator 本身就一定會有 parsing 的功能, 但是要把這塊 component 挖出來也不容易, 畢竟人家本來就不是 design for reuse. 所以就採取折衷的辦法, 利用 document generator 能夠產生 HTML 或是 XML 等 formatted document 的特性, 再寫一個 XML parser 去讀取需要的 parsing information 就好. 寫 XML parsing 就簡單多了, 基本上就是在樹上繞來繞去而已. 整個流程像這樣 :


這樣在 Fact Collection 的 phase 幾乎不用作什麼事情了, 而同時 Doxygen 對於不同 programming language 的 parsing results, 用 XML 存的話, naming 都還蠻一致的, 所以所建立的 Doxygen XML Extractor 幾乎不用作太多的修改就可以不斷地 adapt 到不同的 programming languages 身上.

剩下的是在 Metrics Measurement phase, 把從 Doxygen 得到的 parsing information 塞到自訂的 program model 上, 然後利用特定的 software metrics 進行 measurement 就得到 program quality report 了.

在 development effort 上大大地省下許多功夫, 也能滿足 prototyping 的目的. 不過相對來說, 付出的 performance 代價是十分地恐怖, 恐怖到我一點也不想去比較真正的 parser 跟這個作法的 performance, 至少差了幾千倍吧. Performance 的 bottleneck 在於兩個地方, 一個是 Doxygen 要建立 document, 因此需要不斷地 cross-reference code entities, 另外一個則是 Doxygen 與 Doxygen XML Extractor 對於 document file 的 I/O. 對於程式碼很大且複雜的 software 來說, 例如 GCC, 可能要跑個幾天才會出來結果 (我用還蠻不錯的 PC machine 是跑了兩天多才出來).

所以基本上呢, 這種做法就只適合 prototyping 用吧, 另外就是需要不計較執行時花的時間, 唯一省下的好處是要寫 parser 或是 grammar file 的時間 :p

在 wikipedia 上有其他 source code document generator 的比較列表, 其他 document generator 應該也是可以取代 Doxygen 位置, 只要輸出的格式是 formatted document 就沒問題.

我大約在一年前第一次到 Ohloh.net 一逛, 那時整個網站公開還不久, 大約幾個月而已. 一切都還很陽春, 只有大約 3000 多個 projects (其中有些是空號, 因為我那時閒閒沒事寫個 crawler 把人家資料整個抓下來分析 XD), 其中有很多還是空號. 那時的 project assessment 頁面長的像這樣 (幸好有舊資料留著), 以下是舊畫面歐 :


而資料方面只有針對 project 的 contributors 以及 code base 作分析. code base 只有 language 比例分析, license 分析, 以及 code base 大小增長曲線分析. 其中比較有趣的是右方的 project cost estimation, 用來推測此 OSS project 在業界的 cost 會是多少. 當初已經有 community 功能, 但是參與的人還很少. 現在已不可同日而語了, 除了 project 本身的 statistics 統計有更好的分類以及更詳細的內容, 結合 project 相關 news 也使得我們一次可以接收到該 project 進行的最重要發展訊息, 以及 community 內的相關 comments.

一樣是 MediaWiki, 現在比較漂亮, 資訊也比較多了.



當初會找到 Ohlon.net 的原因之一是因為, 當時我正在參與實驗室的一個 OSS software measurement 相關計畫, 也作了一個簡單的 tool 分析 SourceForge.net 上的 OSS software 其 source code 相關資訊, 包含 programming language 組成, package 組成, quality evaluation 等等. 當時就想到, 雖然 software measurement 的 tools 已經有很多, 但是似乎沒有看到過有作成網站提供服務給 software project 的. 加上當時已經是 open source portal 龍頭的 S.F.net 也沒有類似的功能 ( 直到現在 S.F.net 還是只有基本的 project statistics 統計功能 ), 就想說把做好的 tool 延伸作成 web application, 然後作成一個提供此種服務的網站應該會是很有趣的事情, 比起 OpenFoundry 要學 S.F.net 又學的不好來的有市場機會多了.

沒想到 domain analysis 作著作著就發現 Ohloh.net 早已經開始作一樣的事情了.

Ohloh.net 創始者只有兩個人, Jason Allen 以及 Scott Collison, 有趣的是兩個人都是從 Microsfot 出身的. 在離開 Microsoft 之後, 有感於當時的 Open Source community 缺少統一的 software evaluation 服務, 無法讓其他開發者或是使用者對於有興趣的 OSS project 在 management 以及 quality 上有更深入的了解, 因此創立了 Ohloh.net, 希望不只幫助有興趣的人了解, 也讓 OSS project manager 可以從 engineering 觀點提升自己的 project efficiency 以及 product quality.

一年來 Ohloh.net 穩健地成長, 不僅網站提供的 evaluation angles 越來越多, community 也有逐漸茁壯的感覺. 但我覺得在 Ohloh.net 提供的 services 到 project manager 如何利用這些 services 以改善 projects 還有一些 gap 存在. 或許 Ohloh.net 應該針對他們的服務是否有達到預期的效果作 validity 檢測, 或是以問卷詢問 services 使用者的 satisfaction, 作為未來要增加的新服務之基礎.

Anyway, 這是一個值得時常造訪, 長期觀察的網站 :)

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