引言
隨著中國正式加入世界貿易組織（WTO），中國企業迫切需要盡快地實現信息化以適應即將到來的市場競爭，但是目前中國不過有1000多家大中型企業開始實施ERP（EntERPriseResourcePlan，企業資源計劃），這個數字占中國企業總數的比例還不到２.９％。由于ERP軟件功能復雜、耗資巨大、維護成本相對較高，因此，研究如何借助于軟件工程的軟件重用思想和方法，提高ERP軟件的開發效率，具有重大的意義。
軟件重用是指，使用專為重用而設計的、預先定義的軟件資產來構造組裝軟件系統的過程。軟件生產線和CBSE是當前軟件工程領域比較流行的軟件重用實踐活動，它們對工業化軟件開發和維護都具有潛在的促進作用。它們解決軟件重用問題的思路有所不同：軟件生產線強調"自頂向下的重用"，即從體系結構或領域模型出發考慮系統的重用；而CBSE強調"自底向上的重用"即從系統最基本構件塊搭建的方，式考慮系統的重用。兩者的結合是目前最理想的重用手段。
UML是當今在面向對象領域占主導地位的標準建模語言，它融合了Booch、OMT和OOSE方法中的主要概念。它不僅可以支持面向對象的分析與設計，更重要的是能夠有力的支持從需求分析開始的軟件開發全過程。UML目前已經稱為軟件開發行業的既定標準，在當前和未來開發軟件的過程中，使用UML建模已經稱為軟件成敗的關鍵所在。但是，UML作為一種通用的建模語言，不可避免地喪失了某些重要特征我們歸納為以下幾點：
UML沒有明確地提供可變點的描述方法。
一個軟件生產線是一組軟件系統，它們共享通用的、受管理的設計和標準（或資產），這些特征滿足一個特定市場范圍或任務的明確需求，而且它們按照規定的方式由公共的核心資產庫開發而成。軟件生產線通過抽取某一類應用系統的共性，建立可重用的核心資產；再通過對核心資產的定制生成多個類似應用系統的實例。因此，可變點對于軟件生產線的體系結構（模型）描述十分重要。UML作為一種通用的建模語言，并未對軟件生產線中可變點的定義提供明確的支持。
UML 語言對構件設計和描述沒有明確的支持。
采用UML中的面向對象標記只能描述方法調用的交互類型，無法描述構件之間多樣的連接類型；而且它們還不支持構件的層次結構的描述、系統族的定義等。
本文的后幾節打算按以下幾部分進行描述。第２節分析軟件生產線的可變點問題，然后提供一種可變點描述方法。第３節描述基于可重用構件的軟件生產線描述方法。第４節對本文工作進行了總結和展望。
軟件生產線的可變點
軟件生產線的體系結構
穩定而不失靈活性的體系結構是一個成功的軟件生產線的基礎。體系結構描述了軟件產品線應用領域的業務體系結構共性和個性、支持該業務體系結構的信息體系結構、應用體系結構和技術體系結構。軟件生產線為獲得體系結構的重用，必須依據"低耦合、高內聚"的原則，設計能夠適應變更的體系結構，這就要求在捕獲需求時使用域分析的方法，對歷史和前景進行分析（歷史分析用于總結該類系統需求的不變點和可變點，前景分析用來預測系統需求今后可能發生的變化），得到不變和可變的功能需求和質量場景。從體系結構的各個側面來看，變更對體系結構影響的程度從大到小依次為業務、位置、技術、組織、信息和應用。要特別注意對族體系結構可變點的實現。詳細設計的方案應使含有可變點的構件盡可能靈活地適應可變點的變化，提高構件的可重用性。
軟件生產線的可變點分析
關于軟件生產線的可變點描述，我們將以ERP軟件的"庫存子系統"為實例詳細闡述。
對于單個應用系統而言，其可變點可以通過UML建模來實現。可變點可以作為類的屬性來實現，例如：倉庫中的某項器材的庫存數量經常處于變動之中，這樣我們可以為器材類添加一個"庫存數量"的屬性。可變點還可以通過繼承的方式來實現，由同一父類派生出多個子類，每個子類完成特定的功能。這些都是標準UML語言可以支持的。
對于軟件生產線，它的可變點存在于從需求分析直到設計、實現的各個階段。例如：兩個制造企業都要完成器材的出入庫的功能，但是，某個企業在器材入合格庫之間需要首先進入待驗庫，而另一個企業則無需經過器材檢驗的步驟。這種系統層的可變點通過標準UML語言無法實現。軟件生產線的可變點描述既要實現同一產品族系統的集成，又要清晰地表現同一產品族內單個系統之間的可變性。
軟件生產線的可變點描述
為了滿足上述的可變點要求，我們提出了一種基于"選擇模型"的軟件生產線描述方法。該方法充分利用了UML語言的擴展機制，使用"Ｓｔｅｒｅｏｔｙｐｅ（范型）"描述軟件生產線的體系結構中的可變點，其優點在于保證了與標準UML語言的兼容性，適合于廣大熟悉UML語言的開發人員使用。此外，為了有效地管理整個軟件生產線的可變點，我們采用基于"選擇模型"的方式支持軟件可變點的查找和控制。
圖１是我們定義的一個庫存系統軟件生產線的用例圖。該用例圖中的可變點定義引入了"可選用例"和"可選角色"兩個范型。圖２和圖３分別是依據該庫存軟件生產線生成的兩個實例應用系統：Ａ企業的庫存系統用例圖和Ｂ企業的庫存系統用例圖。
類似的擴展還同樣可以應用于其他所需的UML圖中，包括：類圖、活動圖、協作圖等。從原則角度考慮，圖中的每個元素，如：類、關聯、繼承，實際上都是可選的或者可以使用一套元素的其他進行替換。因此，擴展機制必須保證每種元素的可變性都可以進行定義。目前，我們采用的擴展機制還不是十分完善，有待于今后進行進一步研究。
"選擇模型"的定義
為有效地控制上述UML模型的可變點將它們有效地連接在一起，定義了一個"選擇模型"，它可描述為一個四元組｛定制要求，解答，UML圖，動作｝。定制要求：依據該軟件生產線進行定制的開發人員會產生的問題，解答：開發人員做出的選擇，UML圖：列出對應該選擇應該選擇的相應的UML圖；動作：列出這種選擇相應產生的動作。具體樣例如圖４所示。
軟件生產線的構件描述
雖然當前大多數方法都表明支持基于構件的軟件工程（CBSE），但是它們的重點通常集中在實現和發布階段，而且趨向于將構件看作軟件開發的"結果"，而不是軟件開發的一個重要組成部分。
本文參考文獻中提到的KbroA方法，針對ERP軟件的特點，進行了擴充，提出以下的軟件生產線的構件描述方法(CDES)。這種方法使得在分析和設計階段就是完全面向構件的，而且將構件的實現描述與具體的構件標準COM＋／EJB／CORBA）分離。該方法中的所有構件采用一組UML圖形進行描述。
CDES方法將構件的描述分為三部分：管理層、規范層和實現層。管理層通過描述ERP軟件的管理特征，提供構件的語義描述，主要通過用例圖和活動圖描述。規范層定義了構件對外的接口特征，即對應它所能滿足的管理層功能需求，主要通過類圖和順序圖描述。實現層定義如何通過底層的實現構件和實現類完成規范層定義的功能需求，主要通過類圖、順序圖、配置圖、構件圖描述。
為了滿足軟件生產線的體系結構描述所需的的集成性和可變點特性，構件的描述應該始終與選擇模型息息相關。選擇模型指明了對于不同的應用系統應該如何進行構件的選擇。規范層的類圖描述通常十分簡單，它只描述該系統對外所暴露的屬性和特征。構件的實現層類圖通常是規范層類圖的子類，為了滿足功能需求，通常還需要加入比規范層類圖更多的新類。
結束語
本文的研究成果源自于作者在海爾工裝設備公司和沈陽飛機工業集團公司兩個企業的物資供應系統的開發經驗，本文的研究成果已經應用于某制造企業的"物資采購供應系統"，我們在另一企業的庫存子系統中應用上述的軟件生產線體系結構描述，快速、有效地生成了新的實例應用系統。同時，我們完善了最初創建的軟件生產線體系結構，使其可以面向更多領域的庫存系統。
目前，我們的研究成果還不是特別完善。下一步還需要改進軟件生產線中可變點的描述方法。"選擇模型"還需要進行準確的形式化描述，以期能夠實現一定程度的ERP軟件自動生成功能。我們還希望在軟件生產線的體系結構描述中借鑒Rational等公司正在極力推動的可重用軟件資產規范（Reusable Asset Specification），使其可以描述更加豐富的可重用軟件資產。
轉載請注明出處：拓步ERP資訊網http://m.guhuozai8.cn/
本文網址：http://m.guhuozai8.cn/html/consultation/1082065302.html
相關文章
