TWI462012B - 軟體系統功能劃分及組合的方法 - Google Patents

Description

軟體系統功能劃分及組合的方法

本發明涉及軟體系統領域，尤其涉及一種企業資源規劃系統中軟體系統功能劃分及組合的方法。

軟體產品的開發目標是滿足需求，需求又分為功能性需求和非功能性需求。在軟體設計時，透過建模的方式將抽象的功能性需求轉變為實際的功能模型並進一步加以實現。

對功能性需求建模的過程實際就是一種結構化功能網路的過程。功能模型需要具有充分的描述性，可以說明某個功能是如何滿足需求的，某個功能是如何在系統中應用和工作的，以及各個功能之間是如何交互的。功能模型是否準確、可擴展，都將影響最終的軟體品質。

在一個軟體系統中通常會有許多公用功能，物件導向(object-oriented)的設計方法透過封裝、繼承和多型來建立物件(object)間的層次結構，元件導向(component-oriented)的設計方式和服務導向(service-oriented)的設計方式通常定義介面作為公用行為的契約。這三種建模的方式是需要通過介面、繼承等方式將物件或是元件耦合(coupled)在一起，以約定或定義公用功能，使得系統複雜度高，可擴展性差。

本發明的目的在於解決上述的問題，提供一種軟體系統功能劃分及組 合的方法。該方法不僅透過功能包的類別劃分及相互擴展，使系統功能的層次結構的複雜度減小，而且透過配置(configuration)的方法在功能包(function package)中增加或移除公用功能包以及增加、移除或改變功能點(function point)，使功能包具有高度的靈活性。此外，採用解譯器模式，使功能點與系統之間的耦合更加鬆散，功能點更易於管理。

為實現上述的目的，本發明採用下述技術方案：一種軟體系統功能劃分及組合的方法，所述的軟體系統具有一配置且具有至少一功能，所述的功能用以完成軟體系統的至少一需求，包括以下步驟：(a)將所述的功能定義為至少一功能點(function point)；(b)所述的配置記錄每一功能點；(c)根據所述至少一需求，將所述的功能點組合成至少一功能包(function package)；以及(d)所述的配置記錄每一功能包。

進一步，所述的功能包選自於一公用功能包和一獨立功能包中任意一種。

進一步，所述的功能點為公用功能點和獨立功能點中任意一種。

進一步，所述的公用功能包是由至少一公用的功能點所組成。進一步，所述的獨立功能包是由獨立功能點和公用功能包所組成。進一步，每一所述的功能點具有一類型。

進一步，在每一所述的功能包中允許刪除或新增或修改一功能點。

進一步，允許由一功能包繼承至另一功能包。

進一步，所述的配置是一可延伸標記語言檔(XML)。

進一步，所述的配置是可集成於所述軟體系統的程式集動態鏈接程式庫((Dynamic-link Library，簡稱DLL)中。

進一步，所述的軟體系統是一企業資源規劃系統(ERP)。

本發明的優點在於：(1)功能包的類別劃分與互相擴展(功能包承載功能包)構成的系統功能的層次結構，與傳統的通過程式碼擴展方式相比，減少了系統的複雜度；(2)高度的靈活性，在各個獨立功能包中可以將公用功能包中的功能與特有功能點進行組合，還可以通過配置的方式以移除或增加公用功能包中的功能點；(3)可擴展性強，採用組合(功能包承載功能包)而非單根繼承的方式來組織和重用業務功能，可以實現多重繼承(multiple inheritance)的效果；採用解譯器模式，使得功能點與系統之間的耦合更加鬆散，使功能點更易於管理。此外，功能點的載入邏輯被包裝在解譯器中，使得新增功能點類型更容易實現，新增一個功能點類型對原有系統基本沒有影響，功能點與系統的耦合關係被包裝在解譯器的應用邏輯中。

為讓本發明之上述內容能更明顯易懂，下文特舉較佳實施例，並配合所附圖式，作詳細說明如下：

下面結合附圖對本發明軟體系統功能劃分及組合的方法的具體實施方式做詳細說明。

第1圖是本發明所述軟體系統的結構示意圖，主要包括配置層M10、功 能層M20和框架層M30。所述配置層M10還包括配置M11和配置系統M12。所述功能層M20包括至少一功能包M22和多個解譯器M23，其中所述至少一功能包M22還包括多個功能點M21用於對應所述多個解譯器M23。所述框架層M30為底層框架層，所述底層框架層包括各型底層框架M31，例如實體框架、服務框架和其他框架等。於優選實施例中，本發明的軟體系統功能劃分及組合的方法是運行但不限定在Windows作業系統下，且本發明的軟體系統是一種企業資源規劃(ERP)系統。於其它實施例中，本發明的軟體系統功能劃分及組合的方法可以適用於其它類型的作業系統及開發環境中。

第1圖的多個功能點M21用於分別實現軟體系統中具有不同特點或不同再用程度的各類型功能，以滿足軟體系統開發的各種需求。由於功能種類不同，特性也不同，功能的應用方式和再用程度也不盡相同，通過如第1圖的其中一個功能點M21或多個功能點M21即可實現每一個功能，換句話說，每一功能點M21就是一功能的定義，且上述多個功能點M21為公用功能點和獨立功能點的任意一種。

第1圖的功能包M22是用於組合上述多個功能點M21，作為組織功能的一個容器，也就是說功能包M22劃分的最小細微性是功能點M21。雖然第1圖僅繪示了一個功能包M22，然而在應用上，可依軟體系統的實際需要，設置多個功能包M22(如第2圖)，功能包M22還分為公用功能包和獨立功能包，其中公用功能包可以由至少一公用功能點如其中一上述功能點M21組成，包含了軟體系統中一些公用功能的集合，所述公用功能包的再用級別較高，可以進行擴展，以提高軟體系統的可維護性和可擴展性。獨 立功能包可以由獨立功能點如另一上述功能點M21和公用功能包組成，用於滿足一個獨立的完整需求所定義的功能集合，每一業務所特有的獨立功能包是不會被擴展的。公用功能包和獨立功能包兩者僅在邏輯上有所區分。例如在單據處理的業務中，公用功能包可以包括保存、刪除和檢查等功能，但這些功能本身在定義之後與單據處理業務無直接關係，但可以通過創建一獨立功能包以實現單據處理業務的需求。該獨立功能包再用了該公用功能包已定義好的功能，並按需求再增加單據處理的特別功能，以實現單據處理業務的功能需求。以第2圖為例，進一步具體說明第1圖的功能包M22的定義設置過程如下：第2圖中第一功能包和第二功能包為公用功能包，第三功能包為獨立功能包。第一功能包(公用(Common)功能包)的基礎包(Base Items)中無再用功能包節點，而在代表功能點集合項(Items)的節點下，定義了各個具體的功能點節點，其中有創建(Create)、編輯(Edit)、刪除(Delete)、保存(Save)、讀取(Read)、查詢(Query)、驗證(Validate)和版本管理(Version Management)功能點。第二功能包(基本資料(BaseData)功能包)包含了一些可再用的業務需求，該功能包的基礎包(Base Items)節點下，通過再用功能包節點定義了擴展所述第一功能包(公用功能包)，所述第一功能包(公用功能包)的所有功能點會應用至所述第二功能包(基本資料功能包)中；在所述第二功能包(基本資料功能包)中代表功能點集合項(Items)的節點下，定義了審批狀態管理(Approve Status Management)新功能點。第三功能包(Unit功能包)基礎包的節點下，通過再用功能包節點定義了擴展所述第二功能包(基本資料功能包)的節點，在代表功能點集合項(Items)下，通過增加標注為Delete的版本管理 功能點節點，刪除了版本管理(Version Management)功能點，所述第一功能包(公用功能包)中除版本管理外的所有功能點以及第二功能包中定義的審批狀態管理功能點會應用至所述第三功能包(Unit功能包)中。這樣功能包完成了定義設置。

此外，在軟體系統開發的應用上，第1圖中所述功能包M22是可以擴展的，且不僅僅是擴展功能包M22中的一個單個功能，而且可以是擴展一整個功能包M22的所有功能，與傳統的通過模組的繼承方式相比，功能包M22更具靈活性，耦合性也較低。獨立功能包是不能被擴展的，而且功能包之間不能迴圈擴展，即若第二功能包擴展了第一功能包，則第一功能包不能同時擴展第二功能包。功能包M22之間相互擴展是通過配置檔(configuration file)以達到組合效果。此外，傳統技術在使用繼承時一般不允許多重繼承，而本發明所述功能包的組合卻可以繼承多個功能包M22中的所有功能。以第3圖為例，進一步說明第1圖的功能包M22的變更或擴展過程：在開發軟體過程中，會遇到需求變更或擴展，可以通過在獨立功能包或者公用功能包中添加、刪除或修改功能點以完成需求變更或擴展的動作，而不必修改原有系統的程式碼或者是重新編譯原有系統，這樣保證了系統的原有功能和系統結構的穩定，同時增強了系統的可擴展性。修改獨立功能包會改變單個應用領域中系統功能和行為，修改公用功能包會改變部分或者整個系統的功能和行為。在第3圖中，矩形表示功能包，小圓表示功能點，空心箭頭表示功能包之間的擴展關係，大圓表示獨立功能包應用的業務領域，功能包A、B、C、E為公用功能包，功能包D、F為在不同業務領域的獨立功能包。功能點帶撇號表示功能點被修改。由第3圖可 見，公用功能包是可以擴展的。例如，功能包B首先是通過在配置檔中的再用功能包節點定義了擴展功能包A，然後所述功能包B在配置檔中又定義一標注為Delete的功能點節點以刪除功能點C，再在配置檔中定義一功能點節點(功能點節點預設為Add，也可以顯式標注為Add)以添加功能點D，這樣完成了功能包B的定義。

在第1圖中，功能包M22若使用在獨立的業務領域中，功能包M22中的基礎包用於描述對公用功能包的擴展，即包含了公用功能包中所有功能點，例如在基礎包中添加了兩個公用功能包節點，即增加了兩個公用功能包所包括的所有功能點的集合。項用於描述對功能點的添加，例如在項中新增一個功能點節點，即增加了其對應的功能點。若在項中刪除一個功能點節點，即刪除了其對應的功能點。與之相比，在傳統技術中，一個個功能通過編譯原始程式碼後包裝於程式集中，若要修改某一功能，則需要將與該功能相關的原始程式碼重新編譯才完成修改動作。一般情況下，傳統技術是通過聲明一功能模組，並通過修改該功能模組的程式碼或者通過功能模組的類進行繼承，修改其行為，再重新進行編譯。而在本發明的功能包和功能點的組合中，功能點是相對獨立，在程式碼中無集合結構，只是在配置中呈現集合。

在第1圖中，所述配置層M10中的配置M11用於記錄每一功能點M21，並產生配置檔。當軟體系統執行的時候，系統讀取配置M11，也就是說，系統讀取了設置在配置M11中的功能點M21。這樣，系統可透過所述功能點M21的應用實現相應的功能。同樣，所述的配置M11也記錄每一功能包M22。功能包M22是定義於配置檔中。配置檔為可延伸標記語言檔 (XML)，由配置系統M12讀取配置檔中的內容。其中包含了功能點M21以及功能包M22定義。功能包M22的承載方式，除了可以是基於配置檔外，也可以是集成在程式集的DLL中。配置檔打包在程式集中，不易被篡改，因此一般會將重要功能的配置檔存放在程式集中，若對程式集修改需重新編譯。一般會將相對容易改變或修改的功能記錄在獨立的配置檔中，當進行二次開發的時候直接修改配置檔即可完成。例如，實現兩個不同類型的單據，一張為訂單，一張為售貨單，在訂單功能包中有審核功能。為了實現在售貨單功能中也要有審核功能，在售貨單功能包的配置檔中添加訂單功能包中的審核功能(功能點)，這樣，經過售貨單配置檔的修改及載入也可實現售貨單的審核功能。又例如：在實現訂單功能包的配置過程中，首先將保存功能(功能點)添加至該訂單功能包中，用於完成保存的需求，然後根據訂單功能包所需完成的需求，如審核需求，查詢需求，或其他需求，依照需求列表將相關功能添加至該訂單功能包中，這樣，該訂單功能包具有完整的訂單的功能，再將每一功能點記錄於配置中，此配置即為訂單功能包的配置。

在第1圖中，所述功能層M20中的解譯器M23用於解釋所述功能點M21。由於每種類型的功能點的目的、功能和應用方式都不同，因此不同類型的功能點M21需由相應的解譯器M23予以解釋。功能點的解譯器M23寫在程式碼中。一個解譯器M23對應多個同一類型的功能點M21。若要新置一種類型的功能點M21即要新定義一個解譯器M23，通過編寫程式碼來實現，在系統啟動過程中，將程式碼新定義的解譯器添加到解譯器容器中，從而實現後續新置功能點M21的應用。功能點類型，即軟體系統中有很多 不同類型的功能，不同類型的功能點的作用不同，應用到軟體系統的方式也不同，因此可通過不同的解譯器M23將不同類型的功能應用到系統中，實現功能的作用。在本發明方法中已實現的功能點類型包括：實體註冊、特性實體、切片、腳本函數導入、資料轉換、功能表資源、自動執行、校驗和快取。舉例而言，第4圖給出一個應用的例子說明功能包M22和功能點M21相關的各元件的運作過程：在實現時，首先考慮新增的功能點的功能點類別，如果屬於系統中已提供的功能點類別，則在程式碼中實現功能點時標記該新增的功能點的類別為某一系統中已提供的功能點類別。在程式碼中實現功能點對應的功能之後，在功能包配置檔中加入該新增功能點節點。在運行時，首先配置系統讀取功能包配置，根據功能包配置獲取功能點，根據功能點類型的標記，比如為實體類型，該功能點就會由實體類型的解譯器進行解釋，通過解譯器的應用方法，將功能點應用到系統中。這樣就完成了功能包及功能點的運作過程。

在第1圖中，所述框架層M30用於在解譯器M23完成解釋之後，將所述功能點M21應用至框架層M30中。例如在軟體系統中有很多類型的服務，服務一般通過服務容器進行管理。通過本發明之方法為服務定義一功能點，通過服務類型的解譯器完成服務註冊，將該服務加入到服務容器中。

本發明有益效果在於，通過定義功能包和功能點的集合，與傳統服務導向(Service-Oriented architecture，簡稱SOA)組合相比，第一，在組合結構上，本發明更靈活方便，功能包將離散的功能點組合在一起，並不在功能包中定義功能包內各個功能點之間的業務關聯，因此功能包定義便捷且易於擴展；而SOA服務組合在構建服務組合時根據業務需求將各個服務順序 連接起來，即定義了實現每個細細微性功能的服務調用順序，複雜度較高。第二，在應用方式上，本發明使用了功能包和功能點，使整個系統處於就緒狀態，根據不同的請求可作出不同的回應，執行流程不定義在功能包中，而是耦合在功能點對應的實現程式碼中(即功能點邏輯寫於程式碼中)。例如單據保存動作，在本發明中定義保存和檢查兩個動作為兩個不同的功能點，在執行保存功能點的時候會先觸發檢查功能點，所謂的流程動作記錄於功能點的定義中。而在SOA系統中，有一單據處理的流程，在定義服務組合的業務流程時定義為先調用檢查服務，如果檢查通過再調用保存服務。第三，在擴展方式中，本發明利用功能包的擴展性，且獨立功能包和公用功能包可相互擴展。而在SOA服務中，定義一服務組合在流程中完成不同的功能，流程的擴展雖然可以進行拼接，但無法實現流程的融合。第四，本專利方法將功能包區分為公用功能包和獨立功能包，公用功能包中定義了可再用的功能點，獨立功能包在擴展公用功能包的基礎上為了實現獨立的業務需求加入獨立的功能點，如此公用功能包和獨立功能包構成了系統功能的層次結構；而SOA服務組合中沒有這種功能的層次結構，也沒有類似公用的服務組合及獨立的服務組合這樣的概念。

參見第5圖和第1圖，一種軟體系統功能劃分及組合的方法，基於所述軟體系統，其具體實施步驟如下：步驟S501：將所述功能定義為功能點；步驟S502：在程式碼中設置所述功能點的類別標記；步驟S503：將功能點配置在功能包的配置檔中；步驟S504：當系統執行時，系統通過配置系統讀取配置； 步驟S505：系統根據功能包配置生成功能包物件，功能包物件中包含該功能包中的功能點的集合以及該功能包擴展的功能包物件；步驟S506：根據功能包物件獲取該功能包中的功能點集合；步驟S507：遍歷解譯器容器，依據解譯器對應的功能點類型，在該功能包的功能點集合中確認每個類型的解譯器將要應用的功能點；步驟S508：通過反射獲取每種類型的功能點解譯器的應用邏輯；步驟S509：依次使用所述功能點解譯器的應用邏輯將每一該功能點解譯器對應的功能點應用到軟體系統的底層框架中，完成了所述功能包與功能點的應用過程。

系統一般會預設置解譯器。但系統若要設置新的解譯器，也可在步驟S501前執行預設置新增的解譯器。另外，步驟S501-步驟S503屬於定義步驟，是由開發設計人員完成。而步驟S504-步驟S509屬於應用步驟，是由系統完成。

雖然本發明已用較佳實施例揭露如上，然其並非用以限定本發明，任何熟習此技藝者，在不脫離本發明之精神和範圍內，當可作各種之更動與修改，因此本發明之保護範圍當視後附之申請專利範圍所界定者為準。

M10‧‧‧配置層

M11‧‧‧配置

M12‧‧‧配置系統

M20‧‧‧功能層

M22‧‧‧功能點

M21‧‧‧功能包

M23‧‧‧解譯器

M30‧‧‧框架層

M31‧‧‧底層框架

S501~S509‧‧‧步驟

第1圖是本發明所述軟體系統的結構示意圖；第2圖是功能包定義設置的示意圖；第3圖是功能包變更或擴展的示意圖；第4圖是功能包和功能點相關的各元件的運作過程示意圖； 第5圖是本發明所述軟體系統功能劃分及組合的方法的具體實施步驟流程圖。

M10‧‧‧配置層

M11‧‧‧配置

M12‧‧‧配置系統

M20‧‧‧功能層

M22‧‧‧功能點

M21‧‧‧功能包

M23‧‧‧解譯器

M30‧‧‧框架層

M31‧‧‧底層框架

Claims (6)

1. 一種軟體系統功能劃分及組合的方法，該軟體系統具有一配置且具有至少一功能，該功能用以完成軟體系統的至少一需求，其包括以下步驟：(a)將該功能定義為至少一功能點；(b)該配置記錄每一功能點；(c)根據該至少一需求，將該功能點組合成至少一功能包，該至少一功能包包括一獨立功能包以及一公用功能包，該公用功能包包括至少一公用功能點，該至少一公用功能點表示可共用於該獨立功能包以及該公用功能包的功能，該獨立功能包包括獨立功能點以及該至少一公用功能點，且該獨立功能包的功能點不能被其它功能包所擴展；以及(d)該配置記錄每一功能包。
2. 如申請專利範圍第1項所述之軟體系統劃分及組合的方法，其中在每一該功能包中允許刪除或新增或修改一功能點。
3. 如申請專利範圍第1項所述之軟體系統劃分及組合的方法，其中允許由一功能包繼承至另一功能包。
4. 如申請專利範圍第1項所述之軟體系統劃分及組合的方法，其中該配置是一可延伸標記語言檔。
5. 如申請專利範圍第1項所述之軟體系統劃分及組合的方法，其中該配置是可集成於該軟體系統的程式集中。
6. 如申請專利範圍第1項所述之軟體系統劃分及組合的方法，其中該軟體系統是一企業資源規劃系統。