使用開放原始碼工具實作軟體產品線方法

國 立 交 通 大 學

管理學院（資訊管理學程）碩士班

碩 士 論 文

使用開放原始碼工具實作軟體產品線方法

Implementing the Software Product Lines with

Open Source Solutions

研究生 繆維武

指導教授 楊千 博士

使用開放原始碼工具實作軟體產品線方法

Implementing the Software Product Lines with

Open Source Solutions

研 究 生： 繆維武 Student: Wei-Wu, Miao

指導教授： 楊 千 博士 Advisor: Dr. Chyan Yang

國 立 交 通 大 學

管理學院（資訊管理學程）碩士班

碩 士 論 文

A Thesis

Submitted to Institute of Information Management College of Management

National Chiao Tung University in Partial Fulfillment of the Requirements

for the Degree of Master of Science

in

Information Management June 2011

Hsinchu, Taiwan, the Republic of China

使用開放原始碼工具實作軟體產品線方法

研究生：繆維武 指導教授：楊 千 博士

國立交通大學管理學院（資訊管理學程）碩士班

摘 要

軟體產品線方法是由軟體工程機構(Software Engineering Institute)提出之軟體開發概念性架構，

經SEI 研究證實，使用此方法可以幫助組織以更快的效率、更高的生產力與品質、以及更少 的成本建置資訊系統；本論文的目標有二，其一，嘗試提出軟體產品線方法之技術架構；其 二，整合JavaEE 平台和開放原始碼工具來實作此技術架構，以期能提供標準化、開放式架 構、低成本並且穩定度高之解決方案；最後會量測本論文實作其之重用程度、節省成本和投 資報酬作為驗證，並將其驗證成果就實務上提出導入原則與建議。 關鍵字：軟體產品線、開放原始碼、領域模型、軟體開發、統一塑模語言、軟體專案管理 I

Implementing the Software Product Lines with

Open Source Solutions

Student：Wei-Wu, Miao Advisor：Dr. Chyan Yang

Institue of Information Management

National Chiao Tung University

Hsinchu, Taiwan, Republic of China

Abstract

The Software Productline method is a conceptual architecture provided by SEI (Software Engineering Institute). As confirmed by SEI researches, this method can help organizations increase efficiency, productivity and quality, and also decrease cost of implementing enterprise information system. There are two objectives for this thesis. Firstly, the thesis provides a technical architecture for Software Productline method. Secondly, it provides a standardized, open architecture, low cost and stable solution by implementing the provided technical architecture which is integrated with JavaEE platform and Open Source tools. Lastly, the implementation will be verified by measuring it's software reuse percentage, Reuse Cost Avoidance, and Return On Investment; then the verified results will be used to provide practices for organizations to build their own Software Productline implementations.

Keyword: Software Productline, Open Source, Domain Model, Software Development, UML,

Software Project Management

致 謝

在交大修習研究所的這兩年，一邊兼顧事業、一邊兼顧課業，學生不得不說

真的是很辛苦，但同時也很慶幸自己可以成為這大家族中的一份子，在修習課

業的過程中，教授們的悉心指導，開拓了學生在資訊領域的廣度和深度，所辦

助理們快速、主動地服務也有如及時雨一般，經常幫學生處理學校行政程序的

各項疑難雜症。學生也結識了許多可愛、真誠的同窗好友們，他們有些是如睿

智的長者、有些是如靈巧的頑皮小孩，他們的見聞也經常刺激學生去思考新的

事物，幸好有這些同窗好友的相互支持，學生才能順利地繼續走下去。

在準備論文的過程中，楊老師經常切中要點的指導和言簡意深的舉例，再加

上意鈞學長經常施展的溫柔壓力，帶領著研究室的同袍們，有如指導牙牙學語

的小

baby 們學走路一般，一點一點地，從一開始的跌跌撞撞，到現在總算是有

個可以拿出來的成果！學生在這個過程中學到很多，也因此跟研究室的同袍們

有著堅深的革命情感，令學生非常感動與珍惜。

最後，也要謝謝一路支持學生的父母親、老婆和公司的長官與同事們，沒有

你們的諒解與支持，相信我也無法撐過這一段難熬又彌足珍貴的時期，真的非

常感謝大家！總而言之，能夠來交大作學問真的太好了！

繆維武 謹誌於

2011 年 6 月國立交通大學管理學院（資訊管理學程）碩士班

III

目錄

摘要...I Abstract...II 致謝...III 目錄...IV 表目錄...VII 圖目錄...VIII 第1 章緒論...1 1.1 研究動機與目的...1 1.2 論文架構與研究流程...3 第2 章相關背景介紹...5 2.1 軟體抽象化層次之演進...5 2.2 物件導向系統的設計風格...6 2.2.1Transaction Script 設計風格...7 2.2.2Domain Model 設計風格...7 2.3Domain-Driven Design...9 2.3.1Domain Model 的精確定義...9 2.3.2Ubiquitous Language...10

2.4Unified Modeling Language(UML)...10

2.5Software Product Line Engineering...11

2.5.1 軟體產品線之必要管理活動...11

2.5.2 核心資產開發活動(Core Asset Development)...12

2.5.3 產品開發活動(Product Development)...14

2.5.4 管理活動(Management)...16

2.6 軟體工廠與軟體產品線...16

2.7 測試驅動開發...16

2.8 量測軟體重用程度...17

2.8.1Reuse Software Instruction (RSI)...18

2.8.2Reuse Metrics Starter Set...19

2.8.3 重用率效益分析案例...20 第3 章軟體產品線設計與開放原始碼工具之整合...22 3.1 軟體產品線架構設計...22 3.2 開放原始碼工具介紹...27 3.2.1OpenOffice.org...27 3.2.2Eclipse IDE...27 3.2.3Jude UML...28 3.2.4Apache Subversion...29 3.2.5Open Foundry...29 3.2.6Apache Maven...29 3.2.7Apache Tomcat...30 3.2.8 H2 DB...31 3.2.9JUunit...31 3.2.10Spring Framework...31 3.2.11Hibernate Framework...32 3.2.12 使用工具與軟體產品線開發活動之關係...32 第4 章軟體產品線之設計與實作...34 4.1 背景描述...34 4.2 軟體產品線之需求...34 4.2.1 角色清單...34 4.2.2 使用案例...35 4.2.3 非功能性需求...37 4.3 核心資產之設計...37 4.3.1Bookstore-project-template-spring 專案...38 4.3.2Bookstore-domain-model 專案...39 4.3.3Bookstore-domain-model-persistence-jpa 專案...44 4.3.4Bookstore-application-service 專案...45 4.3.5Bookstore-utilities 專案...45 4.3.6 系統自動化測試之管理...45 4.3.7 系統元件相依性之管理...49 4.3.8 系統元件版本之管理...53 V

4.4 產品開發之設計...55 4.5 系統實作...58 第5 章結論與建議...61 5.1 結論...61 5.1.1 量化角度...61 5.1.2 質化角度...63 5.2 建議...63 英文參考文獻...65 中文參考文獻...66 參考網頁...67 附錄1 實作系統之重用率量測報告細節...69 附錄2 實作系統之測試量測報告細節...81 VI

表目錄

表 1: 軟體可重用和不可重用元件之定義...18 表 2: 核心資產互動角色清單...34 表 3: 核心資產利害關係人清單...35 表 4: 核心資產使用案例清單...36 表 5: 核心資產非功能性需求清單...37 表 6: Maven 預設生命週期、階段和目標的關係整理...46 表 7: 各專案之程式碼統計...61 表 8: 各產品 RSI 統計...62 表 9: 重用率、重用節省成本和投資報酬計算結果...62 表 10: 實作之軟體元件測試結果和測試涵蓋率...63 VII

圖目錄

圖 1: Software Product Line 之概念簡圖...2

圖 2: 論文研究流程...4

圖 3: Transaction Script 系統設計風格...7

圖 4: Domain Model 系統設計風格...8

圖 5: A sense of the relationships between complexity and effort for different domain logic styles..8

圖 6: UML2.3 版分類簡圖...11 圖 7: 軟體產品線的必要活動...12 圖 8: 核心資產開發...13 圖 9: 產品開發...15 圖 10: 軟體產品線架構設計...26 圖 11: 使用工具與本論文軟體開發活動之關係...33 圖 12: 核心資產使用案例圖...37 圖 13: 核心資產之專案配置...38 圖 14: 專案範本整合之技術...38 圖 15: 核心資產之領域塑模...40 圖 16: 使用 Composite Pattern 設計書籍分類...42 圖 17: 使用 State Pattern 來設計訂單狀態變更邏輯...42 圖 18: 訂單領域物件的狀態圖...43 圖 19: 基於領域物件自動化產生之關連式模型...44 圖 20: 應用邏輯服務...45 圖 21: Surefire-Report 測試報表...47 圖 22: Cobertura 測試報表─全部套件...48 圖 23: Cobertura 測試報表─單一套件...48 圖 24: Cobertura 測試報表─單一類別...49 圖 25: Maven 建置專案時對於相依元件的處理順序...51 圖 26: 由 Maven 整理系統元件的相依性關係...52 圖 27: 核心資產版本控管情境...53 圖 28: 核心資產版本控管機制...54 VIII

圖 29: 線上書店前台系統之穩健分析圖...56 圖 30: 線上書店後台系統之穩健分析圖...57 圖 31: 線上書店系統之佈署圖...58 圖 32: 線上書店前台系統畫面...59 圖 33: 線上書店後台系統畫面...60 IX

第

1章 緒論

1.1 研究動機與目的

近年來，世界全球化的影響日趨明顯，各國之間政治、文化、經濟、貿易、人與人之間 的關係等，互動愈來越頻繁，相互依存性越來越高，各國之間不斷簽訂 FTA(Free Trade Agreement) 、跨國界的電子商務通行無阻，也因此商業組織之間的競爭程度也越趨激烈；商 業組織要提高其競爭力，被動的來說，必須更快速地、更精準地對內、外部事件的做出適當 反應，維持市場地位，主動的來說，可以提出創新的產品、服務，甚至是新的商業模型，為 企業創造新的利潤和市場！而其中資訊科技占有相當重要的地位，作為一個現代化的企業， 除了在生產、 銷售 、人 資、研發、財 務等 各個功能性部門導入 ERP(Enterprise Resource

Planing) ， 加 以 整 合 企 業 的 整 體 資 源 ， 更 有 甚 者 ， 還 會 建 置 供 應 鏈 管 理 (Supply Chain Management)相關之資訊系統，加強從全球供應商開始一直到全球終端客戶手上為止的整體 流程，讓企業的競爭力更上層樓！ 資訊科技對企業各式管理活動的重要性與影響甚廣，同時要開發一個彈性高、穩定性高、 擴充彈性佳和符合顧客期待的資訊系統是相當困難的；舉個例子，當組織的業務隨著時間成 長，關鍵集成系統越來越多、實作技術差異越來越大、修補程式上再上修補程式，系統擴張 再擴張，最後系統成為了無法移動的大象，以至於無法再繼續提供價值，導致組織不得不考 慮使用新技術來替換掉既有的老舊資訊系統，但老舊系統的商業邏輯和相關文件早已散布各 地且技術異質性大，取得難度高，所以組織仍然無法徹底遷移至新系統，因為風險實在太高 最後組織的彈性反過來受到老舊系統的影響而越來越僵化，進而影響到組織對內、外部環境 的反應能力，導致錯過新的商機，抑或是走入衰退(ThoughtWorks 公司，2009)！ 在軟體工程領域裡，對於上述的問題，早已有許多優秀的工程師花了幾十年的研究、實

作 和 經 驗 總 結 ， 提 出 了 合 理 的 解 決 方 案 ─Software Product Lines(SEI ， 2010) ； 由

SEI(Software Engineering Institute)主導，一種從大量客製化生產製造方法所衍生出來的軟體 開發方法，例如筆記型電腦生產製造，由於產品設計的先期投入，使得工廠生產線可針對同 一產品線的產品，大量生產統一的機體，等到接到客戶訂單時，依據客戶的實際需求，在機 體的統一介面上搭配不同的模組，如顯示卡模組、記憶體模組等，因而產生不同的類型但是 相似的產品；此概念如今被拿來在軟體開發上使用，將欲解決相似問題之系統歸納在同一產 品線下，當它們在被開發時就可共用統一的核心資產(core assets) ，如系統架構、可重用軟 １

體元件(Reusable Software Components)、領域模型(Domain Model)、需求文件、測試程式碼... 等，每一個系統(產品)就可採用組裝式軟體開發 (Development by assembly)方式(吳信輝， 2006)，以期達到以更快的效率、更高的生產力與品質和更少的成本來建造資訊系統，讓組 織更為敏捷(agility)。 圖1.1 為軟體產品線之概念簡圖，假設一組織有生產、行銷、人事、研發和財務部門等， 給予每一部門一條軟體產品線，而旗下的每一個產品即是欲解決相同領域問題之不同面向的 資訊系統，因問題領域同質性高，故每一產品使用核心資產的機會則大大提升， 採用組裝式 軟體開發的程度提高，最終可以用較少的資源、更快的速度、更好的品質來建造資訊系統。

資料來源：[本研究整理]

依照SEI 的網站的公布，採用 Software Product Line 的組織所獲得的績效(SEI，2010)，簡列

如下 • 生產力改善將近10 倍 • 品質增加將近10 倍 • 成本減少將近60% • 人力資源減少將近87% • Time to market(組織內部部門、外部使用)時間減少將近 98% ２

• 進入新市場的時間，從原本幾年減少到幾個月 以類似概念執行的軟體專案在台灣還不普遍，故在此論文中欲驗證觀點有二，(1)以實作 觀點切入，提出軟體產品線方法之技術架構，(2)基於論文提出之技術架構，嘗試使用開放 原始碼工具，欲提供標準化、開放式架構、低成本並且穩定度高的解決方案。此論文最後將 實作一個包含線上書店前台和後台管理的網站系統模組並對其結果作分析與探討，希望能藉 由此論文的產出，能對於實務上提出欲導入之原則與建議。

1.2 論文架構與研究流程

本論文架構分為五個章節，敘述如下： 第一章：詳細介紹研究動機及目的、論文架構、研究流程。 第二章：研究方法的相關背景與概念介紹。 第三章：軟體產品線方法之技術架構與開放原始碼工具的整合與對映關係。 第四章：使用軟體產品線與開放原始碼工具設計與實作。 第五章：對本研究產出結果說明，並提出對於實務需求之導入原則與建議。 論文研究流程如圖1.2： ３

４

第

2章 相關背景介紹

2.1 軟體抽象化層次之演進

從程式語言開始發展的1950 年早期，到目前為止，軟體系統的開發方向是往越來越高階

的 抽 象 化 層 次 (higher level of abstraction) 發 展

(Balasubramanian、Gokhale、Karsai、Sztipanovits、Neema，2006；吳信輝，2005) ，依抽象 化層次條列如下。 • 機器語言(Machine Language) 電腦問世後的第一個程式語言，直接使用二進位表示，可由機器CPU 直接讀取的語 言，執行速度非常快，因為是由機器直接讀取，所以可讀性(human readability)低，故 學習曲線相當高，且在不同的機器上，程式就得改寫，(不同的 CPU 吃的指令集不同)， 完全無可攜性(portability)可言。 • 組合語言(Assembly Language) 為提高機器語言可讀性，一種便於記憶和理解的符號表示式，由組譯器(Assembler)轉 譯成特定CPU 的機器語言，然後再給其 CPU 執行，可攜性部分，是針對一種家族的 CPU，如果是其它廠牌的 CPU，轉譯出來的機器語言可能無法執行，目前在底層硬 體操作或是驅動程式仍然可見到它的蹤跡。

• 高階程式語言(High Level Programming Language)

為了提高程式設計師的生產力，故開發了可讀性更高的程式語言種類，由人類容易閱 讀的英文單字組成，不同的機器有提供不同版本的編譯器(compiler)，將撰寫好的高 階語言吃進其編譯器，編譯成相對可執行之機器語言。 • 結構式語言(Structured Programming) 高階程式語言的一種，具有三種特性，為依序執行(Sequence)、條件判斷(Selection)和 反覆執行(Repetition)，結構式語言通常是以演算法的資料結構和執行的流程與順序來 解決問題領域的問題，故系統開發人員是從電腦運算平台的角度來看待問題領域。

• 物件導向語言(Object-Oriented Programming) (Eckel，2002)

高階程式語言的一種，除了包含結構式語言的特性之外，還另外具有三種特性，封裝 ５

(Encapsulation)、繼承(Inheritance)和多型(Polymorphism)，物件導向語言可將問題領 域之重要概念的相關資料與處理行為加以封裝，形成類別(Class)，將概念相關之類別 作一般化/特殊化(Generalization/Specialization)繼承處理，抽取出共用與非共用的程式 碼區塊，最後也可藉由多型去改變類別行為的變異點，達到程式演算法共用的效果。 故物件導向語言可將問題領域加以抽象化，將程式演算法從問題領域概念中抽離出來， 系統開發人員便有機會從問題領域本身的角度來看待問題，接著才去思考運算平台的 實作。

• 應用虛擬機器(Application Virtual Machine)

一種在作業系統運行的軟體，當特定程序(Process)被執行起來時，AVM 便先會被執

行，並且包含此特定程序，提供所需資源，當此特定程序執行結束時，AVM 也會執

行結束並從記憶體中移除；主要功能是提供此特定程序一個完全獨立於底層作業系統 與硬體的執行環境，藉以讓此類型的程序在不同的運算平台上都可以使用相同方式運

行，而不需考慮運算平台的異質性。近代的物件導向語言如Java、.NET 等，都包含

此一技術，方便系統開發人員WORA(Write once run any where)。

• 中介軟體(Middleware) (Sun Microsystems，2008)

也稱為應用伺服器(Application Server)，介於系統程式與應用程式之間的軟體，便於 應用系統之軟體元件間的連線與資源控管，中介軟體基於應用虛擬機器的實作，可使 應用系統具有更高的可攜性，而且中介軟體通常會提供應用系統常使用的服務，如資 料庫連線、交易控管機制、外部系統溝通、電子郵件設定和安全性設定等，減輕系統 開發人員考慮這些服務的負擔，而把心力花在問題領域本身。 雖 然 軟 體 產 品 線 的 類 似 概 念 早 在 1985 年 就 有 成 功 的 案 例 (Clements、Northrop，2002)，CelsiusTech 為當時瑞典的大型軟體公司，可投入的資源和技 術環境就比大部分小型軟體公司或是非軟體產業的公司要來的優渥，但在上述提及的相關技 術環境成熟的前提之下，如今要實作軟體產品線實為管理階層和相關執行人員的思維轉換 (paradigm shift)，相較之下，技術上的限制已大幅降低。

2.2 物件導向系統的設計風格

近十幾年軟體系統開發的主流是使用OOAD(Object-Oriented Analysis and Design)，現今經

常聽到的產品與平台有Sun Microsystems Java 和 Microsoft .NET 等，除了要使用相關平台與

技術之外，系統設計的風格也是影響到軟體系統後續的彈性、穩定性和可維護性，目前物件 導向系統設計風格的主流分為兩大類(1)Transaction Script 和(2)Domain Model，分別描述如下。

2.2.1 Transaction Script 設計風格

何謂Transaction Script 的設計風格，依 Martin Fowler 的定義如下

Organize business logic by procedures where each procedure handles a single request from presentation.(Fowler，2002)

資料來源：[本研究整理]

簡言之，就是系統設計師依照SA 開出的需求規格，重頭到尾地把相關設計與開發實作出

來，然而這樣的設計風格，會不自覺地使得系統的架構與 商業邏輯之程式碼綁在一個或多個

需求上，如圖2.1 所示，系統的每一個 tier 都綁在由需求延伸出來的紅線上，然而 end user 的

需求是一天到晚都在變動的(I know it when I see it)，所以 Transaction Script 設計風格的系統 架構很容易就會因需求變動發生大範圍的影響，使得接受需求變動的彈性較低。

2.2.2 Domain Model 設計風格

何謂Domain Model 的設計風格，依 Martin Fowler 的定義如下

An object model of the domain that incorporates both behavior and data. (Fowler，2002)

此設計風格主要是強調在開發系統時，除了user 的需求之外，其實我們還要更關注 user

所在的商業環境！因為user 會提出需求，其背後是因為商業環境的驅動使然，所以系統除了

７

要提供滿足user 需求的服務之外，其核心應該建立在 user 背後的商業環境上，因為其和需求 本身相較，是本質上穩定不變的部分。如此，即使user 的需求天天在變，系統受到影響的部 分將會有效減少，因為user 的商業環境並不是天天在變動的。然而此種設計風格是需要 SA 大力支持的，因為需要有人作商業塑模，所以SA 對於軟體工程的認知和系統抽象化思考是 此設計風格事觀重要的一環。

資料來源：[本研究整理]

Martin Fowler 是 美 國 的 軟 體 架 構 研 究 者 ， 他 在 『 Patterns of enterprise application architecture』一書中，提到他以自己三十幾年來軟體開發的經驗，總結以下圖表 (質化，非 量化方法)

資料來源：[Fowler，2002]

８

圖 4: Domain Model 系統設計風格

圖 5: A sense of the relationships between complexity and effort for different domain

logic styles

在圖2.3 中的三條線各自代表不同的設計風格，其中 Table Model 為.NET 相關技術，故不 在此討論範圍內，X 軸代表系統的複雜程度，Y 軸代表系統的維護心力，由此可看出 Transaction Script 的設計風格是適合較小型、邏輯簡單的系統，而 Domain Model 的是適合較 大型、邏輯複雜的系統。

2.3 Domain-Driven Design

由Eric Evans 提出的 Domain-Driven Design，可說是 Domain Model 設計風格的進階版，其

主要中心思想有兩點 (1)在大部分的軟體專案中，設計主要是聚焦在問題領域和商業邏輯， (2)要解決複雜問題領域，須基於模型做設計。它系統化地提供了專有術語(Terminology)和最 佳實務(Best Practices)，來幫助開發團隊如何做出更好的設計抉擇，可以更快速地開發欲解 決複雜問題領域的軟體系統(D.-D. D. Community，2009)。

2.3.1 Domain Model 的精確定義

D.D.D 對於 Domain Model 有著更精確的定義，描述如下(Richardson，2006)：

1. Entity：一個物件不是被它所擁有的屬性(property)定義，而是被一個識別子(Identity) 所定義 2. Value Object：一個物件是被它所擁有的屬性所定義，沒有識別子，且一旦實例化 (instantiate)後就無法變更(immutable)。 3. Aggregate：一個根物件指向一個或多個物件集合，由根物件負責維護物件集合的一 致 性 ， 故 物 件 集 合 不 會 被 其 他 外 部 物 件 直 接 呼 叫 ， 而 是 透 過 根 物 件 間 接 呼 叫 (delegate)；根物件也被稱為 Aggregate Root。

4. Service：當系統的某個程序在邏輯上並不屬於特定領域物件(Domain Object)所擁有，

或是該程序需要多個Domain Model 互動來完成，就需要 Service 物件來擔負這些責任。

5. Repository：負責跟永久層(Persistence Tier)請求領域物件的 CRUD(Create, Retrieve, Update and Delete)操作，基本上 Domain Model 必須不能知道跟永久層互動的細節， 因為永久層包含了跟特定資料庫連結或是其他種類的檔案格式的細節，所以需要 Repository 以 介 面 (interface) 的 方 式 存 在 於 Domain Model 中 ， 而 相 對 應 之 實 作 (implementation)則由永久層提供。

6. Factory：當要實例化一個領域物件時，建議使用 Factory 物件，所有的領域物件都由 ９

相對的Factory 物件來實例化，如此一來，當更換領域物件的實作時，只需更改 Factory 物件裡的程式碼，而不須更動客戶端(Client-side)的程式碼。

2.3.2 Ubiquitous Language

DDD 也明確提出當軟體專案溝通協調的語言不一致時，會帶來相當大的風險；例如在系 統開發階段的討論時，領域專家(Domain Experts)使用他們的專業術語(jargon)，然而技術團 隊成員使用他們自己的術語，再加上這些討論結果無法直接對應於系統的實作上(中間還會 歷經系統設計師和不同開發人員的設計)，以至於同一件重要概念會有不同的名詞描述，被 使用在不同的角色中(領域專家對系統分析師、系統分析師對系統設計師、系統設計師對系 統開發人員，同一角色的不同人員等)；最後不同名詞的翻譯妨礙了專案溝通，而導致無法 找到問題領域的特性(insights)，並且沒有一個成員使用的名詞可以有效地在不同專案參與人 達成充分理解；到最後專案團隊整體溝通和錯誤理解(misunderstanding)的成本是相當高的 (Evans，2003)。

針對上述問題DDD 提出了 Ubiquitous Language 作為解決方案，Ubiquitous Language 是一

種基於模型(Model-based)的語言，為整個系統開發生命週期(SDLC, System Development Life Cycle)之溝通協調的基本語言；專案團隊必須承諾 Ubiquitous Language 被嚴格使用在所有的

溝通上，包含口頭、文件、UML 圖，甚至是實作程式碼等；專案參與人之間必須不斷地精

煉(refine)此語言，領域專家必須要提出任何對於問題領域造成誤解或是不佳的設計與架構， 系統開發人員必須找出不一致或是不精確的部分，直到所有人對於此語言沒有任何誤解與疑

義為止；在這期間，所有相關的口頭、文件、UML 圖和實作程式碼也必須要不斷地跟

Ubiquitous Language 的最新版本保持一致。最後 Ubiquitous Language 不只是系統開發生命週 期的一部分產出，而是所有專案參與人溝通的基本語言，從需求收集到後續系統維護階段， 使得溝通協調和錯誤理解的成本降至最低。

2.4 Unified Modeling Language(UML)

UML 是圖形化的塑模語言(Graphical Modeling Language)，在 1980 年代末期到 1990 年代

初期由OMG 組織發展出來，是一種圖形表示方法的集合，被用來視覺化、詳述、建構和紀

錄軟體密集系統(Software-Intensive System)的各種面向 。之所以要使用圖形化塑模語言的主 要原因是，光從程式語言本身來看，無法提供更高的抽象化層次來幫助我們建立更複雜、更 龐大的軟體系統；雖然圖形化塑模語言在軟體業發展已久，但是百家爭鳴，每家的語言表達

的含意都有差距，以至於軟體從業人員無法真正達到有效溝通，而UML 的出現，有如救世 主一般，結束了圖形化塑模語言的戰國時代(Fowler，2005)。目前通行的 UML 版本為 2.x 版，

以下是2.3 版的 UML 圖分類簡圖。

資料來源：[Group，2010]

2.5 Software Product Line Engineering

在第一章時稍微描述過其概念和效益，此軟體開發方法為此論文欲驗證之重點，其正式 定義為「一個軟體集成系統的集合，集合中的系統彼此分享一套共通和管理的功能集合，此 功能集合是為了滿足某一特定市場區隔或是任務之需求，而基於事先規劃好的共享核心資產 所開發出來的」(A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.) (Clements、Northrop，2002)。

2.5.1 軟體產品線之必要管理活動

實作軟體產品線的主要活動為(1)在有效的技術和組織管理(Management)支援之下(2)開發

核 心 資 產(Core Asset Development) ，接著 (3)基於已開發之 核心資產來開發產品 (Product

Development)，核心資產開發通常被稱為領域工程(Domain Engineering)，而產品開發通常被 １１

稱為應用工程(Application Engineering)。 如下圖2.7 所示，有三個順向旋轉的圈圈，每一個圈圈代表著一個必要的活動，這三個圈 圈彼此連結且永不間斷地運行著，可以從任何圈圈起始並且高速運轉(Highly iterative)。這三 個圈圈是相互平等的，依使用者環境的需求，可以從管理活動、從核心資產開發活動亦或是 從現有的產品(個別系統)抽取出核心資產開始推動整個軟體產品線的運行。從個別圈圈的箭 頭方向，也可看出它們之間互有回饋機制，核心資產會因為新產品開發的需求而被要求更新 核心資產的更新需要被追蹤，並藉由產品開發時的使用結果來當作核心資產的回饋，如此核 心資產才會產生實際價值；而產品開發也要盡量使用核心資產的元件，盡量反映需求給核心 資產開發活動，避免自己閉門造車。然而這一切都需要強力的、有遠見的管理活動之領導才 能發揮效益。

資料來源：[Clements、Northrop，2002]

以下再就此三項必要之管理活動加以描述。

2.5.2 核心資產開發活動(Core Asset Development)

核心資產開發活動的目標就是建立產品需要的生產要素。圖2.8 表明了核心資產開發活動

需要的輸入和輸出，順時針運轉的箭頭也表明了輸入和輸出之間並沒有明確的因果關係，輸 出和輸入是會相互影響的；例如增加了生產線範疇的廣度(其中一項輸出)，就必須考慮是否

１２

要增加新的元件輸入至核心資產開發的活動之中。

資料來源：[Clements、Northrop，2002]

核心資產開發活動會使用各種資源當作輸入，分類如下。 1. 產品限制(Product Constraints) 生產線旗下產品的共通與相異點、生產線的功能性需求、系統效能需求、使用何種技 術標準、與哪些外部系統溝通等。

2. 風格、樣式和框架(Styles, Patterns and Frameworks)

現今軟體開發大部分都是採用既有的程式，例如使用Domain-Driven Design、J2EE 的

架構建議、四人幫的設計樣式(GOF Design Patterns)或者是採用開放原始碼社群的框

架等，這些解決方案也提供使用者以客製化方法(介面、繼承、多型等)實作系統相異 點，作為軟體產品線的輸入是很自然的。 3. 生產限制(Production Constraint) 生產線是否要遵守任何商業、軍事或是組織的特定標準？旗下產品一定要使用的設施？ 進入市場的時間限制？套裝軟體的整合方式？是否要既有元件和如何使用？ １３

圖 8: 核心資產開發

4. 生產策略(Production Strategy)

使用Top-Down(從核心資產到旗下各個產品)或是 Bottom-Up 生產策略(從既有產品萃

取出核心資產)？自己內部製作或是從外部購買核心資產？如何管理核心資產生產流 程？

5. 既有核心資產的管理(Inventory of Preexisting Assets)

既有系統(Legacy System)包含了組織的領域知識甚或是決定市場形象，軟體產品線通 常都會借用這些已驗證的系統和元件作為核心資產的一部分。詳加分析和使用這些既 有系統是重要的。

核心資產開發活動會產生三個輸出，之後作為產品開發活動的輸入使用，以下描述其輸出。 1. 生產線範疇(Product Line Scope)

描述此軟體產品線是由哪些產品所組成。最簡單的方式是列出此生產線所包含的產品 清單；更正統的做法是列出包含產品之間的共同點和相異點，例如產品之間功能性需 求之相同與相異處、非功能性需求之相同與相異處、產品運行之平台與使用技術等。 2. 核心資產(Core Assets) 軟體產品線製造旗下產品的重複使用之基本要素。包含系統架構、軟體元件和領域物 件、系統效能分析、商業邏輯、軟體開發工具和流程、測試計畫和程式、熟悉此生產 線的人力資源(熟悉一個產品 100%等同於熟悉其他產品的 60~70%)。 3. 生產計劃(Production Plan) 描述如何使用核心資產生產產品。每一個核心資產都應該要有相對應的生產計劃，來 指導使用者如何在產品開發活動使用此核心資產。核心資產通常會定義相異點 (Variation Points)讓不同的產品使用，使用生產計畫描述如何使用這些相異點(剪裁、 重新組合等)是尤其重要的。

2.5.3 產品開發活動(Product Development)

成熟的軟體產品線組織重視軟體產品線的健康程度勝於個別產品，但軟體產品線的最終 目標還是要產生出個別產品。產品開發活動除了基於核心資產開發活動的三項輸出，生產線 範疇、核心資產和生產計畫之外，再加上個別產品的需求文件。圖2.9 所示，逆時針方向運 １４

行的箭頭代表著一個產品的輸出會成為回饋和影響到下一個產品的生產；例如當產品A 在製 作時，發現有個功能可以整合到核心資產共用，而下一個產品B 需要同樣功能時，就直接使 用核心資產的元件，而不需再重新發明輪胎。

資料來源：[Clements、Northrop，2002]

產品開發活動的四項輸入，描述如下。 1. 需求文件(Requirements) 特定產品的需求文件就如同是生產線範疇文件的變異點描述。 2. 生產線範疇(Product Line Scope)

定義特定產品的變異點是否包含在軟體產品線中。 3. 核心資產(Core Assets) 產品的大部分功能將由核心資產組成。 4. 生產計劃(Production Plan) 指導產品製作者如何使用核心資產來實作產品特定功能。 １５

圖 9: 產品開發

2.5.4 管理活動(Management)

管理活動是軟體產品線成功的因素，技術和組織的管理階層必須對軟體產品線建置許下 承諾，給予適當的資源、協調和管理。技術管理階層必須確保核心資產和產品開發活動必須 是在軟體產品線的定義下進行、所有必要的活動都有被執行、並且收集資料和追蹤兩者的健 康狀態。組織管理階層則須採取一切必要的管理活動，來確保組織的架構和資源都適當地分 配給軟體產品線運作。

2.6 軟體工廠與軟體產品線

在中研院的期刊『資訊話題』中也有軟體產品線的相關討論，吳信輝先生在「細說軟體 工廠概念(十一)」文中提及：「有關於軟體工廠的內容，可以區分為兩個部份：第一部份是 軟體產品線的發展，第二部份是產品的發展。在第一部份，軟體產品線的發展又可以區分為 三個階段，分別為軟體產品線分析，進行的工作內容包括：產品線的定義、問題領域確定以 及解決方案領域確定；第二為產品線設計，進行的工作內容包括：軟體架構的發展、客戶需 求的映對以及產品發展流程；第三為產品線的實作，進行的工作內容包括：軟體資產的供應 以及軟體資產的包裝。經過產品線的發展之後，產生出軟體工廠綱要與可變動的軟體資產。 在第二部份產品的發展中，首先會利用產品的規格與產品線發展的軟體工廠概要兩個結合利 用工具產生產品的基本架構；接下來再利用客製化工具將變動軟體資產依其所需取出會利用 到的地方，再進行產品的實作。如果我們結合第一部份的經濟學的觀點，我們會發現軟體工 廠的架構就是要同時處理軟體的規模經濟問題與範疇經濟問題，產品線發展就是要發展出可 重複利用的軟體元件，以達到規模經濟的目標；而產品發展則是以客製化為目標，以達到範 疇經濟的目標。」(吳信輝，2006)

2.7 測試驅動開發

1999 年由 eXtreme Programing 提出 test -first programing 概念，和其後於 2002 年由 Kent Beck 所撰寫的 Test Driven Development 一書和其相關開源專案 jUnit 而加以發揚光大的開發 模式，Kent Beck 強調開發軟體專案時先撰寫自動化的測試程式，隨後再撰寫實作，會帶來 簡單乾淨的設計，並且有效提高系統的品質和增加產值。以下條列出此開發模式之步驟 (Beck，2003；Wells，2009) 。 1. 思考你要測什麼？ 幫助開發人員深度思考是否真的了解需求，如不了解可快速跟SA 反映。 １６

2. 思考你要怎麼測？ 思考程式的介面該如何設計，以確保每個程式的最小單位都具有高度可測性。 3. 寫出測試程式碼並執行，確認他們全都是有問題的(failed) 先確認它們都是有問題，免得測試程試結果有誤。 4. 開始實作一段、測試一段，直到全部測試程式都通過測試(pass) 實作程式碼的每一個區塊目標都很明確，就是要通過測試程式，幫助開發人員思緒集 中。 5. 移除實作中重複的程式碼，或是加上設計樣式(也就是作重構)，接著再確認測試程式 是否全部通過 在不影響實作程式功能性需求的情況下重構程式，讓程式的品質提昇。 6. 持續使用以上步驟開發系統新功能 漸漸擴大測試程式涵蓋率，直到整個系統。 要特別注意的是，以上的步驟都是以自動化可回歸測試為前提，如此一來，每當一段新 的功能被加在系統時，就可立刻執行整個系統的測試程式，以期達到每次系統的新發佈都是 在品質良好的狀態；未來系統正式上線後，欲增加新需求時，如果測試程式的涵蓋率夠高的 話，就能提昇開發人員對於系統作重構時的勇氣(如果重構造成問題，可藉由測試程式立即 發現)，最後即使在後續系統進入維護的生命週期，仍然可以保持良好的可維護性。 本論文在系統實作結束後，會執行jUnit 製作測試報告，包含測試執行結果報告和測試涵 蓋率報告，作為論文結論中的一部分；測試執行結果一定要100%通過測試，系統才能進入 建置階段；目標測試涵蓋率為80%以上，測試的系統層級包含持久層、商業邏輯層和服務層， 但不包含使用者介面層級(Controller、jsp、js 和 html 等)。

2.8 量測軟體重用程度

既然軟體產品線的目標是製作可重複利用的核心資產，所以個別產品生產之後的量化量 測方式也是相當重要的；在管理方面，量測軟體重用程度可讓管理階層更了解軟體產品線的 健康程度和為接下來的管理活動提供方向；在效益方面，量測軟體重用程度可幫助管理階層 量化軟體產品線的投資報酬，了解資源投資的程度和實際的效益，更有甚者，可以拿來作為 １７

在組織中推廣軟體產品線的利器！

本 論 文 在 系 統 實 作 結 束 之 後 ， 將 會 採 用 Jeffrey S. Poulin 所撰寫『 Measuring Software

Reuse』一書所提供的量測模型(Poulin，1997)，來量化本論文軟體產品線實作之效益，量測 模型簡述如下。

2.8.1 Reuse Software Instruction (RSI)

由於軟體本身就具有高度複雜性的天性，在計算軟體重用性時，各別組織亦或是個別開 發團隊對於軟體重用性的定義都不同，以至於各家的重用性量測報告都沒有基於同一基準上

作量測而無法比較，所以Poulin 提出了一系列定義，符合定義才被歸納為重用或是不重用軟

體元件，最後被歸納為重用軟體元件之集合，被稱之為RSI。

表 1: 軟體可重用和不可重用元件之定義

Type of reuse Measured?

Maintenance No

Operating System No

High-level language No

Tools No

Multiple uses One time

Commercial off the shelf(COTS) software No

Porting Separately

Application generators Separately

Utility libraries No

Local utility libraries Maybe

Project/domain-specific libraries Yes

Subclassing, with polymorphism No

Subclassing, without polymorphism Yes

Object composition Yes

Parameterized types Yes

Black-box Yes White-box No

資料來源：[ Poulin，1997]

除了表2.1 所列出之基本定義之外，本論文基於軟體產品線實作之特性，另外再加了三條 定義如下。 １８

1. 組態設定檔 本論文實作在佈署、持久層控制和安全性控制等，有一些組態設定檔，它們雖然不是程 式碼，但仍然或多或少都有被拿來重用，但百分比占整個實作來說是非常些微，故為降 低計算複雜度，本論文不把它們列入LOC(Line of codes)計算。 2. 測試程式 本論文實作採用測試驅動開發，故在商業邏輯方面的程式，幾乎都有相對應的測試程式 碼，所以當產品重用核心資產的軟體元件時，其實同時也省去了開發測試程式碼的資源 ， 故本論文把測試程式碼列為重用軟體元件。 3. 系統架構範本 本論文在核心資產中，有一項是系統架構範本，此範本將會被旗下產品直接複製並修改 ， 是採取白箱重用(White-box reuse)，在表 2.1 中，白箱重用被歸納為不重用軟體元件。

2.8.2 Reuse Metrics Starter Set

Poulin 提供了一個易於使用、了解的量測模型，來讓有興趣的組織來快速使用，稱為 Reuse Metrics Starter Set，包含以下三個部分。

1. 計算重用率(Reuse %)

2. 計算重用節省之成本(Reuse Cost Avoidance)

以上公式包含了一些預設變數，是Poulin 分析各家相關論文和報告歸納出來的數值，組

織可以依自身的實際狀況加以修改，本論文則是採取變數預設值作計算，變數和預設值簡述 如下。

• RCR(Relative Cost of Reuse)

使用重用軟體元件所花掉的資源是重新開發軟體元件的20%，所以預設值是 0.2。

• RCWR(Relative Cost of Writing for Reuse)

開發可重用軟體元件所花掉的資源是開發一般軟體元件的1.5 倍。

• New code cost = $100/LOC

• Error rate = 1 error/KLOC

• Error cost = $10K/error

3. 計算投資報酬(Return On Investment)

先計算開發重用軟體元件所花費的額外成本(Additional Development Cost)。

接下來再計算投資報酬如下。

2.8.3 重用率效益分析案例

Poulin 也收集不同公司的重用率效益分析案例，條列如下。

• Nippon Electric Company(NEC)

達到17%之重用率，產生 6.7 倍的生產力和 2.8 倍的品質提昇。 • GTE Corporation 達到14%之重用率，在軟體開發方面，節省一千四百萬元美金。 • Toshiba 達到60%之重用率，每一行程式碼減少 20~30%缺陷發生率。 • Hewlett-Packard(HP) 針對兩個旗下專案作品質改善，使其達到70%之重用率，分別減少 76%和 24%缺陷發生， 增加50%和 40%的生產力，和同樣減少 43%產品進入市場時間。 ２０

• Raytheon

使用COBOL 語言達到 60%之重用率，增加 50%的生產力。

第

3章 軟體產品線設計與開放原始碼工具之整合

本論文在此章節提出相對應之軟體產品線架構設計與使用之開放原始碼工具，在之後章 節將基於此架構與工具著手系統實作的部分。

3.1 軟體產品線架構設計

基於2.5 節對於軟體產品線的概念描述，提出圖 3.1 相對應之軟體產品線設計架構，就圖 中編號一一描述概念、設計與相關角色之間的關係和將會使用之開放原始碼工具，而開放原 始碼工具之介紹將會在下個小節。 I. Management 標明出管理活動的範圍，涵蓋整個軟體產品線之活動，各項活動運行是否良好端看管理 活動的支援是否充足。

II. Core Asset Development

標明出核心資產開發活動的範圍，涵蓋軟體產品線之(1) ~ (9)活動，通常由核心資產開發 團隊負責維護。

III. Product Development

標明出產品開發活動的範圍，涵蓋軟體產品線之(10) ~ (11)活動，通常由各別產品開發團 隊負責維護。

1. User Requirements

相當於核心資產開發活動的輸入端(2.5.2 節)，輸入類型相當多樣，輸入角色也相當多元，

如客戶、使用者、中高 階主管等 ，負責角色通常是 核心資產開發 團隊 的 SA(System

Analyst)，PM(Project Manager)從旁協助，本論文以使用案例(Use Case)作為需求文件的主 軸(Cockburn，2000)；使用 Open Office 為辦公室自動化工具。

2. Domain Model (UML)

基於使用案例使用統一塑模語言(2.4.2 節)為問題領域建造模型，使其產生 Domain-Driven Design(2.3 節)之基礎架構，負責角色仍為核心資產開發團隊的 SA；使用 Jude UML 作為 塑模工具。

3. Domain-Driven Design (UML)

基於使用案例和Domain Model 做出 Domain-Driven Design 設計，負責角色為核心資產開

發團隊的SD(System Designer)，如何設計出穩定性高、具有彈性和易於維護的模型是一

項不小的挑戰，在此階段SD 的經驗和功力相當重要；使用 Jude UML 作為塑模工具。

4. General Architecture Design

基於使用案例和Domain-Driven Design 設計出相關之系統架構和應用服務，負責角色為

核 心 資 產 開 發 團 隊 的 SD(System Designer) ； 系 統 架 構 方 面 ， 通 常 會 將 系 統 切 分 為

Presentation、Controller、Service 和 Data Integration Tier 等 ；而在應用服務方面，是指 Domain Model 沒有涉及到的應用邏輯，例如「有一個客戶想要為放在購物車的商品建立 訂單，但系統要求客戶必須先作帳號和密碼登入，才允許客戶建立訂單。」以上描述， 建立訂單是商業邏輯，而系統要求客戶登入則是為應用邏輯(Fowler，2002)；使用 Jude UML 作為塑模工具。

5. Reusable Library Design

為系統經常使用的功能製作或收集公用程式(Utilities)和函式庫(Libraries)，例如系統記錄

(logging)、字串處理、讀取檔案等功能，負責角色方面，可由 SD 挑選候選工具，再由開 發人員(Developer)繼續做驗證工作；使用網路上有名聲的開放原始碼社群的產品，如 Jakarta Commons API 等。另外要提醒的是，(3)、(4)和(5)的活動會因為設計的考量而產生 相依性(Dependency)，(4)會相依於(3)，而(4)和(3)會相依於(5)，也因此在更改其中一項的

設計時，也要同盤考量其它的兩個設計架構才是；使用Jude UML 作為塑模工具。

6. General Architecture Source Code Template

由活動(4)產生出的實作程式碼，程式介面由工具自動產出，由核心資產團隊 Developer 實

作應用邏輯，過程中會因為實作考量而回頭修改設計的情形發生；當Code Template 開發

定 版check-in 至 VCS(Version Control System) 後，其後再由產品開發團隊 Developer 於

VCS 將 Code Template 原始碼 check-out 出來重複使用；使用 Jude UML 作為塑模工具，並

使用開放原始碼Subversion 工具作為 VCS 使用。

7. Domain Model Source Code

由活動(3)產生出的實作程式碼，程式介面由工具自動產出，由 Developer 實作應用邏輯，

過程中會因為實作考量而回頭修改設計的情形發生；當DDD 開發定版並包裝成 jar 檔，

check-in 至 VCS 後，其後再由產品開發團隊 Developer 於 VCS 將 jar 檔 check-out 出來重複

使用；使用Jude UML 作為塑模工具，並使用開放原始碼 Subversion 工具作為 VCS 使用。

使用Jude UML 作為塑模工具。

8. Reusable Library Source Code

由活動(5)產生出的實作程式碼或是從網路上的開放原始碼社群搜尋可用的工具，自行實

作的部分，程式介面由工具自動產出，由Developer 實作應用邏輯，過程中會因為實作考

量而回頭修改設計的情形發生；使用開放原始碼的部分，必須將可執行程式(jar 檔)、原

始碼和說明文件一起完整下載並妥善保存；當開發定版並包裝成 jar 檔，check-in 至 VCS

後，其後再由產品開發團隊Developer 於 VCS 將 jar 檔 check-out 出來重複使用；使用 Jude

UML 作為塑模工具，並使用開放原始碼 Subversion 工具作為 VCS 使用。使用 Jude UML 作為塑模工具。

9. Test Code、Production Plan、...etc

在現代化的軟體開發架構中，系統自動化可測試性的要求越來越高，主要是為了在每次 Iteration 中，能夠給予 SD 和 Developer 能夠重構系統的勇氣並有效確保系統的整體品質， 因此在本論文的核心資產和產品開發團隊之實作階段中，同時也會開發相對應之測試程

式 碼 ， 主 要 是 做 Unit Test 和 SIT(System Integrated Test) 的 部 分 ， UAT(User Acceptance

Test)的部分需要有更多的資源投入(Test Team)才有辦法使其自動化，故不在本論文討論範

圍中；測試部分使用的工具是開放遠始碼社群的jUnit 測試框架。

當(6)、(7)和(8)的元件定版後，接著核心資產開發團隊的 SD 或是 Developer 必須就其元件

撰寫使用手冊，也就是Production Plan，便於之後產品開發團隊的 SD 和 Developer 使用；

使用的工具有Open Office 和 Sun Microsystem 的 Java Docs。

10. User Requirements For Specific Product

產品開發團隊的SA 跟產品 End User 蒐集需求後撰寫需求文件，其中最主要的文件為使 用案例，並會同SD 參考現行定版之核心資產是否能提供 End User 的需求；如可滿足， 便走到(11)，如不可滿足，便走到(12)。 11. Product 使用滿足產品需求的核心資產使用組裝式開發方法(Development by Assembly)，順利地把 產品組裝完成。 12. Feedback ２４

當在執行(3)、(4)、(5)或是(10)步驟時，經常會發現需求超出原本核心資產的需求文件或 是生產線範疇定義，可能是初步規劃時的遺漏亦或是End User 沒想到等各種原因，如此 就會起始回饋流程，此時核心資產開發團隊就必須協同產品開發團隊，去確認此需求是 否應該加入核心資產以擴充軟體產品線的範疇。如需加入，就會驅動核心資產進版，之 後再由產品開發團隊使用新版的核心資產作組裝式開發；如不加入，則由產品開發團隊 自行開發此需求；在此步驟判斷的準則就是要維持軟體產品線規劃的一致性和共用性。

使 用 的 工 具 主 要 有 ，Apache Maven 作 為 專 案 管 理 工 具 (Project Management Tool) 和

Subversion 作為版本控制系統。

資料來源：[本研究整理]

２６

3.2 開放原始碼工具介紹

以下介紹本論文使用到的開放原始碼工具，在第四章設計和實作部分將會使用它們和3.1 節的架構整合在一起。

3.2.1 OpenOffice.org

OpenOffice.org 同時是產品也是開放原始碼專案，從 2000 年 10 月 13 日 開 始 ， OpenOffice.org 1.0 在 2002 年 4 月 30 日 釋 出 。 OpenOffice.org 的服務宗旨是要建立國際化辦公室套裝軟體領導品牌的社群，並且可以在任 何主要平台運行，可以透過基於開放式元件可程式介面(Open-Component based APIs)存取該

軟體所有的功能和資料，和儲存成標準的XML 檔案格式。OpenOffice.org 專案主要由 Oracle 支持，該公司主要提供專案的程式碼。其他的 支援廠商包含 Novell、RedHat、RedFlag CH2000 和 IBM 。 此 外 還 有 超 過 450,000 來 自 世 界 各 地 的 使 用 者 來 加 入 這 個 專 案 ， 讓 OpenOffice.org 成為任何使用者都可輕易使用的辦公室套裝軟體。這就是開放遠始碼社群的 精髓所在(OpenOffice.org，2010)。 目前OpenOffice.org 的產品有

Writer ─ 文字處理軟體(Word Processor)，就像 Microsoft Office Word。 Calc ─ 電子表格軟體(SpreadSheet)，就像 Microsoft Office SpreadSheet。 Impress ─ 簡報軟體(Presentation)，就像 Microsoft Office PowerPoint。 Draw ─ 就像 Microsoft Office Visio。

Base ─ 就像 Microsoft Office Access。 Math ─ 編輯數學運算式的軟體。

在本論文的實作中，將會使用此OpenOffice.org 來撰寫相關文件，如使用案例、設計文件

和Production Plan 等。

3.2.2 Eclipse IDE

Eclipse 是開放原始碼的多語言軟體開發環境，包 含整合開發環境(Integrated Development Environment) 和可延伸外掛系統(T. E. Foundation，2011b)。它主要

是支援基於Java 平台的軟體系統開發，同時也可以加上其它外掛來支援不同的平台和語言

的 軟 體 系 統 開 發 ， 包 括 Ada 、 C 、 C++ 、 COBOL 、 Perl 、 PHP 、 Python 、 Ruby 等 (E.

Foundation，2010a)。

在本論文的實作中，將會使用此工具來作為系統開發時的主要平台，如撰寫系統程式碼，

並使用它跟其它工具溝通，包含VCS、Maven、Middle Ware 和 Database 等。

3.2.3 Jude UML

Jude UML 是在本論文中唯一不是開放原始碼專案之工具， 它 是 由 日 本 公 司 ChangeVision 開 發 ， 本 論 文 使 用 的 是 Jude Community 5.5.2 版本，為免費版本，雖然跟 Professional 版本比起來功能較少，但已滿足本 論文設計和實作之需求，功能條列如下(Vision，2011)。 1. Support of UML 2.x

2. Class diagram (Object, Package, Subsystem and Robustness Diagrams are included.) 3. Use case diagram

4. Sequence diagram 5. Collaboration Diagram 6. State diagram 7. Activity diagram 8. Deployment diagram 9. Component diagram

10. Generate Java 1.4 sourcecode from model. 11. Import Java 1.4 source files to create model.

在 本 論 文 的 實 作 中 ， 將 會 使 用 此 工 具 來 描 述 Domain Model 、 Domain-Driven

Design、General Architecture Design 和 Reusable Library Design(圖 3.1 (2) ~ (5))，它的功能雖

然不像商業CASE 工具那樣強大(會花很多錢)，同時可做到順向工程和逆向工程，嚴格來說，

它只能提供單一順向工程或是單一逆向工程的能力，也就是無法將程式碼和既有UML 圖作

合併；在此論文中的主要使用方式是使用順向工程功能來從UML 圖產生程式碼骨架，當程

式碼實作發生不預期之變動時，再回頭手動更改UML 圖。

3.2.4 Apache Subversion

Subversion 是開放原始碼的版本控制系統，在 2000 年

由CollabNet 公司建立。在過去的十年它獲得了相當大的

成功，現在Subversion 仍然在開放原始碼和企業應用領域持續耕耘(Subversion，2011)。

3.2.5 Open Foundry

由自由軟體鑄造場(Open Source Software Foundry)開發之網路

專案管理平台，OSSF 為政府投資，旨在推廣自由軟體在台灣發展之腳步而創立之組織； Open Foundry 主要的服務如下(自由軟體鑄造場，2011)。 1. 專案開發的面向 OpenFoundry 在專案開發方面，其本身即為一個供自由軟體愛好者討論、編寫、管理 專案內容所設置的共同開發平台，自由軟體的開發人員可以透過此 OpenFoundry 所 提供的工具模組建置其自由軟體專案；一般的使用者則可以透過 OpenFoundry 下載 所需要的自由軟體，並提供下載程式的改良意見。 2. 資訊匯集的面向 OpenFoundry 在資訊匯集方面，登錄有本專案的最新動態、自由軟體社群活動、法律 授權參考資訊以及自由軟體相關研究報告與教材資源等，可供使用者自行下載參照學 習。 3. 人才媒介的面向 OpenFoundry 在人才媒介方面，收集了國內軟體社群、學界與業界自由軟體相關人才 的資訊，延伸介紹台灣自由軟體社群發展的現狀，以整合跨領域的人際網絡與人才資 源，並讓使用者可以分享自由軟體活動訊息、開發經驗及個人近況，使用者亦可以透 過此平台與國內需要自由軟體人才的廠商聯繫接洽。

3.2.6 Apache Maven

Apache Maven 是開放原始碼的軟體專案管理 (Software

Project Management)工具，以 POM(Project Object Model)為基礎，Maven 就可以支援軟體專 案的建置、報告和文件管理等功能(T. A. S. Foundation，2010c)。

Maven 的主要目標是讓剛加入專案的 Developer 可以在最短的時間內了解軟體專案的整體 ２９

狀態；為了達到這主要目標，Maven 改善以下軟體專案開發的面向 • 讓專案建置更簡單 • 提供統一的軟體專案建置系統 • 提供專案品質資訊 • 提供基於best practices 的指導原則 • 簡便的昇級和外掛系統 基於以上對Maven 的功能簡介，它為本論文的實作架構帶來的好處如下 1. 標準的專案開發架構 2. 將不同目的環境的設定資源加以區分(例如 Production 環境和 Test 環境連線的資料庫 是不同的)，並協助自動化佈署。 3. 在每次建置專案可執行程式(Build Code)時，能自動化地執行所有測試程式，並且會 自動寄發測試報告給專案相關人員，進而保證每次產生的專案可執行程式的品質是在 預期範圍。 4. 強制的版本控制，基於 Maven 的專案都被強制給予一版本編號，並且在最後產出的 專案可執行程式中，都會將此版本編號附加在其中，也因此專案相關人員都會相當清 楚自己使用的可執行程式版本為何，降低混淆不清的情況發生。 5. 解決程式相依性問題，Maven 具有中央控管的程式碼容器，在本論文的實作中，將會 有許多的程式相依性存在，例如產品的2.x 版本相依於核心資產的 1.x 版，而核心資 產的1.x 版又相依於某個框架的 3.x 版，類似的相依性會相當多，使用人為判斷很容 易出錯，而Maven 基於 POM 檔案，可以自動化地幫忙控管此相依性關係。

3.2.7 Apache Tomcat

由Apache 開放原始碼社群所開發與維護之中介軟體(Middle Ware)，

主要提供JavaEE 規格中 Servlet 和 JSP 所定義的功能，主要包含 Web

Container(T. A. S. Foundation，2011a)。本論文將使用 Tomcat 作為主要 中介軟體。

3.2.8 H2 DB

100% 基 於 Java 平 台 所 開 發 的 開 放 原 始 碼 關 聯 式 資 料 庫 (Relational Database)，為 MPL 1.1 (Mozilla Public License) 和 EPL 1.0 (Eclipse Public License)授權(Engine，2011)；本論文將 H2 DB 用在如下所述的兩個環境。 1. Production 環境，由 H2 DB 起始的一個獨立運作之網路伺服器對系統提供服務，可支 援多個連線(Session)。 2. Test 環境，由測試程式碼起始並內嵌在記憶體的一個 H2 DB 程序(Process)，專門對測 試程式碼提供服務，這樣作法的好處是(1)可讓測試程式不需依靠外部系統(一個單獨 運作的資料庫)，增加測試程式的可靠性和可攜性，(2)測試程式可自行維護測試資料， 不需擔心被任何人員修改，在每次測試程式起始時，將測試資料塞入測試資料庫中， 在測試程式結束時，就連同測試資料和資料庫程序從記憶體中一起銷毀。

3.2.9 JUunit

目前在開放原始碼社群中基於Java 平台上最出名的單元測試框架(Unit

Test Framework)(JUnit.org，2011)，且市面上，不論是商業授權或是開放原始碼版本的 IDE 都支援其框架，在現今軟體開發方法中，都相當強調自動化測試的重要性(Beck，2003； Wells，2009) ，而 JUnit 這樣的測試框架正是自動化測試基石。

在本論文中，除了前端UI(User Interface)之外，所有自行開發的程式碼都要納入 JUnit 的

測試範圍，接著使用Apache Maven 跟 JUnit 整合，如此每次專案在建置(Build)時，都會執行

測試程式並且將結果作成報表，方便開發團隊即時發覺每次專案程式修改是否合乎預期，如 有問題也能馬上修改，並且使用自動化測試即時驗證修改結果；如此便能提升專案團隊對於 專案程式碼品質提升的意願，勇於在必要時刻進行程式碼重構(code refactor)。

3.2.10Spring Framework

由SpringSource 開發之開放原始碼專案，它作為一個輕量級的框架 (SpringSource，2011)，目前在 javaEE 領域中可說是相當的熱門，在本論 文中主要使用到之功能如下。

1. Inversion of control(Dependency Injection) 2. Aspect-oriented programing

3. Data accessing framework

4. Transaction management framework 5. Model-view-controller framework

3.2.11 Hibernate Framework

Hibernate 是在 javaEE 領域相當有名的 Object-Relation Mapping 開

放原始碼框架(J. Community，2011)；在本論文中對於資料庫的存取，是透過 Java Persistence API 作為介面，底層是依靠此框架作管理。

3.2.12使用工具與軟體產品線開發活動之關係

以下駝峰圖描繪出關於各工具如何被使用在本論文軟體開發活動中的程度，圖中上半部 之X 軸是系統開發生命週期，下半部之 X 軸則是將本論文軟體產品線之開發活動，依照系 統開發生命週期作分類及歸納；Y 軸是本論文使用之主要工具；兩者交會處便代表某特定工 具在系統開發生命特定週期和本論文特定開發活動之使用狀態。 以Eclipse IDE 為例，在系統開發初期，處於需求蒐集及確認和需求分析等階段，尚不須 撰寫程式碼或建置開發環境，所以使用狀態為無；之後進入系統設計階段，SD 在設計系統 時，需考慮到系統架構和設計可行性之確認，通常會使用到IDE 去確認細部需求，所以使用 狀態漸漸提高；之後歷經實作、測試和維護階段，當然IDE 都脫不了干係。 ３２

資料來源：[本研究整理]

３３

第

4章 軟體產品線之設計與實作

4.1 背景描述

目標是實作一線上書店網站前後台模組(兩個產品)，其為網路應用程式；前台模組主要是 讓線上書店的使用者和顧客能夠方便地做查詢、瀏覽、購買書籍和維護個人資料等作業；後 台模組主要是讓線上書店的管理者和店員能夠方便地作書籍上架、促銷、接收顧客訂單和處 理顧客抱怨等；其系統實作主要是驗證軟體產品線的可用性，故背景單純設定為一家線上書 店、多家出版商和多位線上客戶的交易平台，且此線上書店有自己的書籍庫存。 而核心資產的組成是採取Top-Down 的方式進行，故將會收集兩個產品的需求並將其精練，

萃取出共用的部分(Project Template、Business Logic 和 API Library 等)，以期之後能夠使用組 裝式開發來達成的兩個產品之實作。

4.2 軟體產品線之需求

以下描述此軟體生產線欲實作之整體需求。

4.2.1 角色清單

下表列出會與系統直接有互動之角色。

表 2: 核心資產互動角色清單

角色名稱 描述 AnonymousUser 不具名使用者，通常是隨機連線至網站潛在使用者；可瀏覽、查詢 網站上架的書籍和註冊成為網站顧客等。 Customer 在網站已有註冊資料且已登入網站表明身分的使用者；可購買書籍、 維護個人資料和聯絡客戶服務等。 Clerk 線上書店的店員；線上書店的維護帳號、訂單、書籍資料、庫存等。

Administrator 線上書店的管理員，擁有包含Clerk 的權限；維護 Administrator 和

Clerk 的權限等。 Carrier 把已訂購書籍宅配到顧客家中或是便利超商的貨運商；貨運商會連 線到系統更改訂單資訊，例如顧客已簽收就進系統把訂單close 掉等。

資料來源：[本研究整理]

下表列出不會與系統有直接互動之利害關係人 ３４

表 3: 核心資產利害關係人清單

利害關係人名稱 描述 Publisher 書籍出版商；不會與系統有直接接觸，但系 統必須記錄有關他們的資訊。 IT Staff 系統的維護人員；需要系統有良好的logging 機制，幫助排解PROD 環境的系統問題。

資料來源：[本研究整理]

4.2.2 使用案例

下表是系統使用案例清單，其中先後順序為分數越大的優先性越高，另外要注意的是分 數100 並不代表比分數 20 還要重要五倍，僅僅只是表示分數 100 比分數 20 要重要(優先)。 ３５

表 4: 核心資產使用案例清單

UC 名稱 UC 描述 編號 先後順序 browseBookStore AnonymousUser 可以使用下列方法瀏覽書店 1.書籍分類 • 中、英文 • 最新書籍 • 書籍銷售排行 2.搜尋 UC-001 100 logInOutBookStore AnonymousUser 登入/註冊/登出 網路書店 前/ 後台系統 UC-002 110

maintainCustomerInfo Customer 維護個人資料 UC-003 85

queryACustomerOrder

sInfo Customer 查詢自己擁有的訂單，顧客無法自己_{更改訂單狀態，需要通知Clerk 作修改(UC-006)}

UC-004 80 maintainShoppingCart AnonymousUser 選取有興趣的書籍並加入到購 物車中 UC-011 97 placeAnOrder Customer 選取欲購買之書籍，系統自動加上運 費計算總價，並讓使用者選擇付款和配送方式， 最後產生訂單。 UC-005 95 payAnOrderByCreditC ard Customer 選擇一訂單且付款狀態為"刷卡未完_{成"，繼續付款作業。} UC-010 90 updateOrdersStatusBy Delivery Carrier 視送貨單之交貨狀態去更改訂單狀態 UC-006 75

maintainAccounts Administrator 維護所有角色之帳號 UC-007 40

maintainCustomersOrd

ersInfo Clerk 維護所有顧客的訂單 UC-008 65

queryCustomersInfo Clerk 觀看客戶資訊 UC-009 70

資料來源：[本研究整理]

以下是基於系統互動角色和使用案例清單所勾勒出的使用案例圖，依照Alistair Cockburn

的使用案例寫法，把每個使用案例區分為不同的Goal Levels(顆粒程度)，藍色為

User-Goal Level( 大 小適 中且 應該 是比 例占 最多 的使 用案 例 )， 靛藍 色為 Function( 粒度 較小 ) (Cockburn，2000)。

資料來源：[本研究整理]

4.2.3 非功能性需求

下表條列出主要非功能性需求

表 5: 核心資產非功能性需求清單

非功能性需求名稱 描述 系統回應時間 要求所有系統作業回應時間要少於5 秒；如果遇到需要較長的運算時 間之案例，需使用非同步的技術，減少使用者等待的時間。

資料來源：[本研究整理]

4.3 核心資產之設計

依照圖3.1 提出的軟體產品線高階架構設計為藍本，拆分出核心資產相關之小專案，每一 ３７

圖 12: 核心資產使用案例圖

個小專案都有自己在核心資產中需扮演的角色，配置如圖4.2，在圖 4.2 中可以跟圖 3.1 相互

比 對 ，(4)General Architecture Design 的 部 分 包 含 了 一 個 專 案

Bookstore-project-template-spring ， (3)Domain-Driven Design 則 包 含 了 三 個 專 案 Bookstore-application-service 、 Bookstore-domain-model 和 Bookstore-domain-model-persistence-jpa ， (5)Reusable Library Design 則包含了一個專案 Bookstore-utilities；每個專案都包含相對應的測試程式和文件等，

也就是圖4.2 (9)Test Code, Production Plan 的部分，專案之間的箭頭表示專案之間的相依關係；

以下小節針對每個專案作出簡述。

資料來源：[本研究整理]

4.3.1 Bookstore-project-template-spring 專案

為軟體產品線之下各個產品的專案初始範本，此專案已實作了基本系統需求與技術整合， 在此論文欲實作之線上網路書店前台與後台系統共兩個產品，這兩個產品都會使用此專案作 為初始範本，再依每個產品之不同需求再作修改；圖4.3 表示出此專案的技術整合細節。

資料來源：[本研究整理]

３８

圖 13: 核心資產之專案配置

圖 14: 專案範本整合之技術

圖 4.3 使 用 的 是 Sun Microsystem 的 Tiers and Layers Diagram ， Tiers 指 的 是 Client 、 Presentation 、 Business 、 Domain Model 和 Resource 的 欄 位 ， Layers 指 的 是 Application、Virtual Platform、Upper Platform、Lower Platform 和 Hardware Platform 的列位， Tiers 和 Layers 交集的區域標明出使用之主要技術為何；此專案相依於 Bookstore-application-service 和 Bookstore-domain-model-persistence-jpa 專案。

4.3.2 Bookstore-domain-model 專案

此專案主要用來實現Domain-Driven-Design 的概念，對於整個軟體產品線之問題領域加以 塑模並提供商業邏輯來服務客戶端程式，是整個核心資產中相當中心的部分 ，所以它不會相 依於其他專案，相反地，是其他專案相依於它；基於4.2 節軟體產品線之需求，使用 UML 設計出如圖4.4 之模型。 ３９

資料來源：[本研究整理]

就 圖 4.4 的 Class Diagram 可 看 出 ， 圖 中 包 含 了 Entity 、 Value Object 、 Aggregate 和

Aggregate Root 等(為了不要讓圖更複雜，Factory 和 Repository 類別沒有顯示出來)，正如 2.3

節之Domain-Driven Design 所提出之設計規範。從圖中左上角開始再進一步仔細觀察，可看

到系統帳號和其登入角色，Customer 角色可擁有多個訂單物件，而訂單物件則是可包含相關 之訂單項目(OrderItem)、指定之物流服務(DeliveryService)、付款方式(Payment)、欲購書籍

４０