第258期 / April 3, 2019 |
       以軟體產品線之概念重構專案程式作者/蕭凱文 [發表日期：2019/4/3] 作者簡介 畢業於高雄醫學大學醫務管理暨醫療資訊學系及中山大學資訊管理所，目前服務於凌群電腦醫療系統研發處。專精VB、SQL…等醫療程式開發，大學時期曾開發一套上肢輔助復健系統，並代表學校參加2014國際醫療展，目前則參與高雄市聯合醫院與部立醫院的HIS系統開發案。 前言 軟體重用是近幾年來非常熱門的話題，它能帶給軟體開發團隊相當多的效益，例如能夠提高生產效率、提升系統品質，也由於系統元件可以被不斷地重複使用與組合，故能夠提高系統整體的彈性。也因為這些軟體元件遵守一定的規範與標準，使得整合的效率提昇，避免掉傳統作法造成程式碼累贅的情形，讓系統元件功能可以在不同環境下適用，進而提升系統執行效率。在系統進行維護時，只需要將注意力集中在新增的元件上。 台灣的資訊系統承包商眾多，大多數的公司利用物件導向的軟體製程，針對每一位客戶的需求，進行系統客製化的開發。雖然這樣的開發方式可以對不同的客戶滿足在系統上不同的需求。但是在開發新專案時，往往都是將舊系統的程式碼直接修改而開發成為新一套的系統，這樣的做法很難透過一個統一的平台進行管理，且元件的重用性和維護性就會大幅的降低。但是，伴隨著醫療資訊系統需求量大幅度的提高，以及近幾年來各家區域醫院的醫療資訊系統（Healthcare Information System，以下簡稱HIS系統）除舊換新，在必須針對各家醫院高度客製化的狀況下，若是沒有一個良好的管理開發平台，或是一套有效的系統開發機制，系統在不斷地修改與調動的狀況下，會導致系統版本或是程式碼的版本過多，在一樣的系統功能情況下，若有需要進行需求調整或異動，就可能發生要修改好幾支不同版本或專案的程式系統，這在系統的維護上來說也會更來的不易與困難，故作為一個程式開發人員，除了程式語言上的開發與架構設計能力之外，應該要好好的思考這個問題，尋求一套解決辦法，以改善環境對傳統開發方式所帶來的衝擊，為公司、為團隊，在未來的系統開發、組裝、維護上來得更快更有彈性，藉此提升公司與團隊的獲利能力。 何謂軟體產品線 在2002年，卡內基美隆大學對於軟體產品線(Software Product Lines, SPL)的定義為： “A software product line is a set of software-intensive systems that share a common, managed feature set satisfying a particular market segment’s specific needs or mission and that are developed from a common set of core assets in a prescribed way.” 它認為軟體產品線應該是一個軟體密集系統(Software-Intensive System)，所謂的軟體密集系統指的是在系統中，存在著能與其他軟體、系統、裝置、感測器，甚至是可以與人互相溝通的軟體元件，這些元件的行為會被系統所控制。為了滿足特定市場需求，每一個元件之間的關係皆為低耦合。 Bakar et al. (2015)引述了Northop及Clement，在2015年於軟體產品線的定義詮釋：軟體產品線是軟體工程的方法、工具及技術，利用共通的生產方法從一系列共享的軟體資產中創造出許多相似的系統。 Gaia et al. (2014)對軟體產品線中重用的概念有了更詳細的說明：軟體產品線是ㄧ種新興的工程技術，它對於共享的模組以及共用的核心資產進行系統化的重複利用，並透過分享產生更多的軟體產品。 綜合上述三位學者的論述，軟體產品線的主要概念就是希望可以達到元件的重複利用，存在於軟體產品線中已經開發完成的軟體元件，可經由特定的方式，依據進行客戶的需要快速地進行組裝與利用，產生相似的系統，以滿足顧客的需求。 軟體產品線特性 軟體產品線(Software Product Lines, SPL)是利用軟體元件的功能、特性或者行為等方式對元件進行分類，同時運用某種模式儲存軟體元件的相同及相異部分。軟體產品線主要將元件內部分割成兩大區塊，分別為共通性(commonality)及變異性 (variability)部分。以圖1為例，共通性的部分(common)表示不需要被修改的部分，而變異部分則表示元件內部的邏輯內容可以被變動的部分，相異的部分包含多個不同的變異點(variation point)，而變體(variants)則是在變異點內部可被更改的文件，故當變更一個變體時，影響到其他變體的程度將會降低（吳國維，2010）。  《圖一》元件內部相同與相異之示意圖(資料來源：吳國維，2010) 軟體產品線發展 軟體產品線被視為一種降低開發成本以及提升軟體品質的軟體策略。使用軟體產品線開發資訊系統，可以分成兩個部份，分別是領域工程與應用工程，詳見圖二所示。（Bockle et al., 2002)  《圖二》軟體產品線工程架構(資料來源：Pohl et al., 2005) 一、領域工程(Domain Engineering) 領域工程階段的目是發展軟體的核心資產，此階段中會開發一個共用且可以重複利用的平台，這個平台會包含所有型態的軟體產物，如需求、設計、測試等。透過系統分析及設計，從相似的軟體產品功能中，定義出軟體產品線的共通性以及變異性，以作為後續提供應用工程使用。在領域工程中，可將其細分成五個子流程：
二、應用工程(Application Engineering) 應用工程又稱產品開發 (Product Development)，此階段會根據應用軟體的特定需求，將領域工程所建置好的軟體產品線，具備共通性及變異性的元件取出做結合。此階段主要關鍵目標在於：
應用工程可以分成四個子流程，其內容歸納如下：
軟體產品線活動 軟體產品線可以分成三個主要的活動，分別為核心資產開發、產品開發、科技與組織管理，圖三中每個圓圈都代表一個主要活動，每個活動彼此互相鏈結，三者之間沒有順序關係，可從任一個活動開始執行。  《圖三》軟體產品線之三大主要活動（資料來源：Software Engineering Institute of Carnegie Mellon University） 一、核心資產開發 核心資產可以被用來進行產品開發，從開發的產品中亦可提取核心資產，例如可以使用核心資產進行產品組裝；產品的需求規格、架構、或是組成元件等都可以被納入到核心資產庫中。為了能夠達成此循環機制，在產品的開發中需要盡量使用核心資產，新的產品在開發後也要不時的更新和新知產的內容。 核心資產開發活動的目標是建立生產產品所需的能力，過程需要管理性活動的支援(如圖4所示)，在分析產品的特徵、生產限制、生產策略與既有核心資產後，會有生產線範疇、核心資產、生產計畫等三個產出。  《圖四》核心資產開發活動（資料來源：Software Engineering Institute of Carnegie Mellon University） 二、產品開發 產品開發活動仰賴於核心資產開發活動的三個輸出，這三個輸出分別為生產線範疇、核心資產、生產計畫，其關係可參考下圖。  《圖五》產品開發活動（資料來源：Software Engineering Institute of Carnegie Mellon University） 從旋轉箭頭可以看出這當中的運行關係，產品開發的產出，可回饋到自身的發展上面，例如當在產品開發的過程中建構了一個先前未曾確認過的共同屬性，便可將此屬性進行核心資產的更新，而這個新確認的共同屬性將會作為未來產品開發上的基礎。在產品開發中，包含了四項輸入，詳述如下：
三、科技與組織管理 科技與組織管理在產品線的成功有著至關重要的作用，它扮演著支援上述兩個開發活動的角色。開發活動必須獲得資源，且在執行過程中不會偏離軟體產品線的定義，並不斷的進行協調和監督，並蒐集資料來追蹤進度。 組織管理編排核心資產開發與產品開發基本活動之間的技術活動；技術管理決定製作方法，並提供生產計劃的項目管理要素。有遠見的領導人可以對軟體產品線保持一個明確的目標，尤其是在早期草創的階段尤其重要，領導力是軟體產品線不可或缺的成功要素。 何謂領域模型 領域模型(Domain Model)又可稱為領域變異模型(Domain Variability Model)，Peng et al.(2006)敘述可重用元件是否能成功的應用，在領域工程的分析階段是一項重要的活動。根據領域模型及領域資產可產出領域特性軟體架構(Domain-Specific Software Architecture)及領域元件，並可根據領域工程所分析出的產物，透過調整後來建置新系統，故領域模型在領域工程及應用工程的開發過程中，擔任重要的支援角色。 領域模型提供在設計架構及元件時所需的領域知識，並提供方法制定元件特徵及組合的規則。由卡內基美隆大學的軟體工程機構(Software Engineering Institute, SEI)於Feature-orientedDomain Analysis(FODA)方法所提出的特徵模型(Feature Model)常做為領域模型，可表示元件共通及變異的特徵。 特徵模型可以將軟體產品線以視覺化的方式呈現，如父特徵可以分解成子特徵，並以樹狀圖的方式表達父特徵及子特徵的關係，以Benavides et al.(2010)所提出的特徵模型為例，父特徵與子特徵間的變異會使用不同的樹狀圖形來表示軟體元件的共通及變異特性，如下圖所示。  《圖六》特徵模型範例（資料來源：Benavides et al.,2010）
實際應用 基於上述軟體產品線的概念以及領域模型中的特徵模型視覺化表現方法，將嘗試把HIS系統中的門診藥局作業做系統模組化重構，以滿足未來能夠針對不同院區的需求功能，快速組裝各院區系統。 在過去，不同家醫院有著不同的程式碼版控，如果說同一支作業有發現Bug或是需求異動，必須同時去修改不同家醫院版控的程式碼，才能達到各家醫院系統功能的一致性和完整性。雖然這樣的方式能確保各家醫院的程式碼或是業務邏輯各自獨立不會互相干擾，但是在往後的程式碼維護和管理上就會變得非常不易且沒有效率。若遇到新的HIS系統導入專案，也必須再重新撰寫和測試一次新版控的程式系統。為了有效提升團隊程式品質、系統組裝與維護效率，團隊期望透過軟體產品線的概念將系統重新設計與重構，期望把各家醫院的程式碼開發版控整併成一個，做為團隊開發平台的基礎，在這個基礎上實施軟體產品線的理念，歸納整理出系統的核心資產有哪些，進而找出系統元件的變異點與共通性，以達到未來能夠有效的模組化組裝和開發，並在組織管理與技術管理上，編排核心資產與產品活動的開發，謹慎的制定系統的製作方法，提供生產計劃的項目管理要素。不斷地進行協調和監督來追蹤進度。 以門診藥局的補列印作業為例（詳見圖七所示），其作業目的在若線上門診藥局相關報表，如：藥袋、異動單、用藥明細等，在列印的過程中發生異常需要重新列印，則藥局的相關人員可以透過此作業進行操作。  《圖七》門診藥局的補列印作業畫面 在這個系統作業中，有些醫院對於補列印處方箋是否要在門診藥局進行有著不同的見解與需求，有的醫院是希望這項功能是在門診醫囑端操作執行。利用軟體產品線中的核心資產概念，找出這項產品的需求規格、架構、以及組成元件，故在釐清門診藥局補列印作業這項功能在各家醫院的需求之後，利用特徵模型(Feature Model)來描繪完整功能的補列印作業樹狀圖，透過特徵模型將文字描述的需求以視覺化的方式來呈現，並且標記出系統元件的共通及變異特性，如圖八所示。  《圖八》門診藥局的補列印作業特徵模型圖 從圖八可以看見，各家醫院的補列印作業必須且共同的功能就是資料的查詢以及異動單與藥袋的列印，處方箋的列印則是依照各家醫院各自的需求進行選配，故在系統程式規劃上，資料查詢和異動單、藥袋的列印是屬於共通性，處方箋補列印則屬於變異點，找出當中的差異後，即可進行程式的架構規劃以及實作。 接著即將進入到軟體產品線的產品開發活動中，在程式碼的規劃上區分為兩個部分，分別是User Interface（以下簡稱UI）以及Business Process（以下簡稱BP），如圖9所示，UI是每支程式作業的操作畫面，而BP放的則是程式作業的商業邏輯。在這兩個項目的分類裡頭又分成Base版本與院區版(如：UI_TYH)，Base版可以說是標準版或是預設版本，它提供各家醫院都會有的共同功能，而這些功能都是各自獨立可隨時被抽換的。判斷是否為共同功能的依據是只要是兩家以上的醫院對於這個作業功能有著相同的需求，則這個功能將會提升到Base的版本當中。相對的，院區版則是各家醫院各自需要的功能，系統會根據醫院或院區切換到對應的介面程式(UI)或商業邏輯(BP)。而Base版與院區版之間的切換是靠著Config院區設定檔來做區分，當HIS系統開啟子系統的功能作業時，在初始化的時候會透過Config設定檔讀取院區資料，並根據院區資料開啟所在院區對應的系統功能。  《圖九》門診藥局程式開發專案 最後進入軟體產品線中的管理階段，在每一次的需求異動後都要定期更新需求規格分析以及程式設計書，以確保這些文件資料的正確性與完整性。以利於後續接手的人或是有新案件的時候可以作到元件重用，讓開發人員能夠快速進入狀況。 參考文獻
|
|
凌群電子報/一九八四年五月二十日創刊 |