基于業(yè)務建模的軟件產品系統(tǒng)分析過程與特點分析

李明亮

（遠光軟件股份有限公司，廣東 珠海 519085）

1 引言

軟件系統(tǒng)分析是一個產品實現(xiàn)的開端，也是產品實現(xiàn)最重要的關鍵點，其主要任務是將所有的需求文檔匯總到一起,從業(yè)務全過程的角度，對組織內部整體管理狀況和信息處理過程進行分析。

本文完整的描述基于業(yè)務建模的系統(tǒng)分析過程，并分析其在可操作性、擴展性、穩(wěn)定性、系統(tǒng)性等方面的特點。在本文的最后對其使用的效果進行描述。

2 相關定義

業(yè)務建模：以軟件模型方式描述業(yè)務所涉及的對象和要素、以及它們的屬性、行為和彼此關系，業(yè)務建模強調以體系的方式來理解、設計和構架軟件系統(tǒng)。業(yè)務用例模型：描述一個業(yè)務的流程以及它們與外部各方之間的交互。

業(yè)務實體：在業(yè)務用例中所使用與處理的任何事物。

業(yè)務行為：對業(yè)務實體所進行的操作的抽象。

實體狀態(tài)：業(yè)務實體在系統(tǒng)各用例中屬性的值。

領域模型：描述業(yè)務用例實現(xiàn)的對象模型。它是對業(yè)務角色和業(yè)務實體之間應該如何聯(lián)系和協(xié)作以執(zhí)行業(yè)務的一種抽象。本文中的領域模型將對象模型分成實體與行為兩部分來進行描述。

UML 模型：用 UML(TheOMG'sUnifiedModelingLanguageTM(UMLR)描述系統(tǒng)的模型。本文的業(yè)務建模采用UML1.4的標準對業(yè)務用例（用例圖），領域模型（類圖），業(yè)務流程（狀態(tài)圖）進行描述。

3 概述

當前常用的系統(tǒng)分析方法有：面向過程的方法 (主要從系統(tǒng)如何將輸入轉換為輸出的角度來分析系統(tǒng))、面向數(shù)據(jù)的方法(強調用數(shù)據(jù)結構表示系統(tǒng)狀態(tài))、面向控制的方法(強調同步、死鎖、排斥、并發(fā)及過程的激活和去活)、面向對象的方法(基于系統(tǒng)的對象類及類之間的交互來進行分析)，這些分析方法各有特色，在特定的場景下，能表現(xiàn)出各自的優(yōu)勢。但對于產品的研發(fā)，它的不足就暴露了出來，面向過程的方法，往往只見樹木不見森林在需求的相關性、擴展性的表現(xiàn)不足，面向數(shù)據(jù)的方法忽略了業(yè)務過程，面向控制的方法對控制對象的描述不夠詳細，面向對象的方法同樣的需求不同的分析過程對分析結果差異大，分析質量得不到保證。

對于模塊多、業(yè)務過程復雜的產品系統(tǒng)分析我們需要一個可規(guī)范化、考慮全面、相對穩(wěn)定性，階段獨立的分析方法。

基于業(yè)務建模的系統(tǒng)分析方法，是以面向對象的分析方法為指導思想，并規(guī)范化過程及輸入輸出、以UML圖為表現(xiàn)形式建立業(yè)務模型，逐步全面的完成系統(tǒng)分析。其分析過程如圖1

4 系統(tǒng)分析過程

4.1 輸入文檔

對業(yè)務需求文檔的規(guī)范性要求，是一個很好的開始。按照分析設計人員的要求，結合對市場的分析，需求人員給出了功能規(guī)劃及業(yè)務需求。

1產品功能規(guī)劃及主體功能及優(yōu)先級列表經(jīng)過對市場的分析及競爭產品的分析，初步做出了產品功能的規(guī)劃，并給出來產品主要的模塊及模塊間的關系。

2系統(tǒng)主要業(yè)務需求及初步界面

業(yè)務需求文檔一定要體現(xiàn)以下幾方面的內容：

業(yè)務模塊中英文、功能名稱中英文、優(yōu)先級、編號、業(yè)務描述、參與角色中英文、前置條件、基本事件流（區(qū)分用戶及系統(tǒng)）、異常事件流、業(yè)務規(guī)則、后置需求、特殊需求、擴展點、補充說明（對操作對象的屬性、規(guī)則說明）等信息。

3 非功能需求描述

本文著重進行業(yè)務建模，對非功能需求只做為輔助驗證，本處不進行描述。

4.2 模塊級需求分析

1找名詞，抽象業(yè)務實體

將前面一節(jié)提供的一個用例的業(yè)務需求文檔進行梳理，將實體從業(yè)務需求文檔中找出來，一邊找一邊填寫表一，直至寫完所有的名詞，并做初步判斷是否由本模塊處理，如下表一是在用戶管理的用戶新增用例中名詞分析得到用戶實體。

2找動詞，分析業(yè)務行為

將前面一節(jié)提供的一個用例的業(yè)務需求文檔與初步分析出來的實體共同梳理，將實體被如何操作（行為）從業(yè)務需求文檔中找出來，一邊找一邊填寫表二，直至寫完所有的名詞及該名詞被怎么樣操作（行為），如下表，將與實體有關的動詞進行分析，抽象為業(yè)務行為

3完善模塊業(yè)務用例并進行合并這一步驟的核心內容是依托實體分析表及實體行為分析表，用UML的類圖完成模塊內實體間及實體自身的關系，以實體為核心完成對實體操作的方法類，原則上一個實體對應一個實體行為類。

模塊分析人員將所負責的模塊經(jīng)過分析，補充完整用例，并把業(yè)務實體在整個模塊中的屬性變化用業(yè)務流程圖描繪出來。將業(yè)務實體、業(yè)務行為進行合并，生成本模塊的需求分析詞匯表（用例詞匯表、實體詞匯表）、業(yè)務用例模型、業(yè)務流程圖。

在對模塊的分析過程中，會發(fā)現(xiàn)一些需求未明確或沒有考慮到的用例，在合并的時候將他們補充完整，并把各分散的用例集中起來。

實體間的關系及實體能提供的操作共同形成一個完整的領域模型。對模塊分析匯總還需要將實體的屬性在模塊中變化的過程用狀態(tài)圖表現(xiàn)出來，以分析實體的數(shù)據(jù)流向。

4 模塊需求分析評審

通過以界面為主線，業(yè)務實體與行為的結合，一方面驗證業(yè)務用例的是否都得到實現(xiàn)，另一方面核對與其他模塊的實體、行為是否完整。

4.3 對業(yè)務需求的總體分析

1匯總各模塊的實體、行為更新業(yè)務實體模型及實體狀態(tài)圖。

系統(tǒng)中的實體往往會在多個模型中被操作，通過匯總，補充了實體的行為、完善領域模型，實體在系統(tǒng)中各屬性狀態(tài)也被完整的用狀態(tài)圖表現(xiàn)出來。

2匯總業(yè)務用例重新劃分模塊邊界及模塊間的關系

通過對用例模型的匯總劃分出系統(tǒng)的一級子系統(tǒng)（領域），明確各子系統(tǒng)的調用關系，將它們完整的用UML的包圖表現(xiàn)出來。領域的劃分原則是劃出來的領域可以獨立完成業(yè)務，與其他領域的交互以接口服務調用的方式進行。如圖二為組織管理實體模型。

3匯總生成詞匯表

把分析過程中實體、行為進行匯總，明確各詞匯所表示的意思，并給出相應的中英文描述。

4領域間接口的設計

結合匯合后的領域模型，利用用例分析時產生的跨領域實體訪問，抽象出領域間的訪問接口（行為名稱、所需參數(shù)、返回值）用UML的類圖表現(xiàn)出來。

4.4 主要輸出文檔

經(jīng)過對單個用例的分析，對模塊需求的分析，對系統(tǒng)匯總后的需求分析，我們抽象出系統(tǒng)級子系統(tǒng)，并對子系統(tǒng)進行抽象實現(xiàn)了業(yè)務實體的模型化，結合實體的行為，完成了領域模型的構建。

需求分析的輸出成果是以對以下文檔評審通過為結束標志。

①領域詞匯表（實體詞匯表、行為詞匯表）

②業(yè)務用例模型（用UML用例圖表示）、業(yè)務實體流程圖（用UML狀態(tài)圖表示）

③領域模型（用UML類圖表示）

④領域間接口（用UML類圖表示）

5 特點分析

5.1 可操作性

對于復雜的產品系統(tǒng)分析往往不是由一兩個人完成的，每個人的分析方式不同必然會造成系統(tǒng)分析質量的不穩(wěn)定，基于業(yè)務建模的軟件產品系統(tǒng)分析過程，從最初的類分析用最簡單的表格方式做為輸出，在分析的過程中，采用最基礎的名詞、動詞的分析方式，大大減少了因為人員的水平參差不平，人員心情起伏等人為因素帶來的偏差。對每一個所負責的任務清晰定義，以明確的文檔為輸入，以評審通過為邊界，使系統(tǒng)分析結果有負責人，可追溯來源。

可見從操作人員過程規(guī)范方面，從管理人員對質量的管理方面，基于業(yè)務建模的軟件產品系統(tǒng)分析過程都具備較強的操作性。

5.2 穩(wěn)定性及可擴展性

穩(wěn)定性與擴展性好象是魚與熊掌很難得以兼顧，但基于業(yè)務建模的軟件產品系統(tǒng)分析過程并將這兩者統(tǒng)一起來。

對于產品需要業(yè)務穩(wěn)定而對產品所支持的項目又希望能提供更多的定制，于是穩(wěn)定及擴展兩者剪不斷理還亂，基于實體與行為分離的業(yè)務模型的建立讓核心的業(yè)務得到了穩(wěn)定，而擴展的功能在需求分析的時候就與核心用松耦合的方式獨立出行為與屬性，兼顧了項目又保障了產品，時機成熟項目的內容可以納入到產品中來，這樣項目與產品進入了良性的循環(huán)。

5.3 系統(tǒng)全面的分析

系統(tǒng)的分析是一種根據(jù)客觀事物所具有的系統(tǒng)特征，從事物的整體出發(fā)，著眼于整體與部分，整體與結構及層次，結構與功能、系統(tǒng)與環(huán)境等的相互聯(lián)系和相互作用，求得優(yōu)化的整體目標的現(xiàn)代科學方法。

基于業(yè)務建模的軟件產品系統(tǒng)分析過程從進入分析過程開始就是從整體規(guī)劃到單個用例，從單個用例分析到整個系統(tǒng)分析匯總，無論是實體還是行為還是實體的變化都是著眼于整個系統(tǒng)，整個領域，在輸出的文檔中，可以看到基于業(yè)務建模的軟件產品系統(tǒng)分析過程統(tǒng)一的對待系統(tǒng)的詞匯表、領域的接口等內容，這些都是常用的系統(tǒng)分析方法容易忽略的地方。

5.4 階段獨立的分析方法

其獨立性表現(xiàn)在兩個地方：

1.充分利用UML帶來的獨立性優(yōu)勢：

(1)可視化，表示能力強。通過UML的模型圖能清晰地表示系統(tǒng)的邏輯模型和實現(xiàn)模型。可用于各種復雜系統(tǒng)的建模。

(2)獨立于過程。UML是系統(tǒng)建模語言，獨立于開發(fā)過程。

(3)獨立于程序設計。用UML建立的軟件系統(tǒng)模型可以用 Java、VC++、SmalltaIk等任何一種面向對象的程序設計來實現(xiàn)。

2.獨立于其他階段

基于業(yè)務建模的軟件產品系統(tǒng)分析過程是一個建模的過程，與之前的需求分析、之后的系統(tǒng)設計有著明確的界線，系統(tǒng)分析評審完成后，系統(tǒng)分析的成果就可作為系統(tǒng)設計的輸入進入下一階段，如果需要系統(tǒng)分析修改的時候就要遵循系統(tǒng)分析變更流程，重新經(jīng)過系統(tǒng)分析的過程；系統(tǒng)分析結果是與系統(tǒng)設計、系統(tǒng)開發(fā)等過程無關的內容，以就意味著系統(tǒng)分析的結果不會因后面的軟件過程使用何種方式而改變系統(tǒng)分析的結果。

6 使用效果

在一個研發(fā)周期10個月總工作量120個人月的基于信息資源管理的內容管理產品當中使用了基于業(yè)務建模的軟件產品系統(tǒng)分析過程，投入到系統(tǒng)分析時間為3個月24個人月工作量。產品從2009年投入使用以來，在系統(tǒng)分析方面成效是非常顯著的，主要表現(xiàn)在下面幾點：

1獨立的特性

系統(tǒng)分析完成后，系統(tǒng)的功能模塊有的是使用java語言進行c/s模式的實現(xiàn)，有的是采用java與HTML一起的BS模式的實現(xiàn)，有的采用C語言來實現(xiàn)但這些都沒有引起系統(tǒng)分析結果的修改。

2適應變化能力強

產品開始用來做項目后，無論是實體的屬性有增加的，有減少的，對其的操作有意義發(fā)生變化的，有增加減少的，在實體與行為分離的大框架下，這些變化不僅沒有讓產品變得不穩(wěn)定，反而逐步完善了產品的領域模型讓產品的系統(tǒng)分析成果能夠支撐更多的項目。

3UML模型表現(xiàn)力強

UML圖形結構清晰，建模簡潔明了，容易掌握理解。使用UML進行系統(tǒng)分析加速開發(fā)進程，提高代碼質量。用UML來描述業(yè)務過程方便清晰，在業(yè)務傳承、交接的時候表現(xiàn)出其優(yōu)越的特性，不用跑系統(tǒng)跟代碼就能完成對系統(tǒng)邏輯的理解。

4系統(tǒng)元素得到了統(tǒng)一

從系統(tǒng)分析時就開始將系統(tǒng)詞匯、實體、行為進行統(tǒng)一管理，對后期專有名詞語意的理解、數(shù)據(jù)庫邏輯模型的生成、國際化的處理、接口查找復用等都顯得方便、可控。

結語

經(jīng)過以上對基于業(yè)務建模的軟件產品系統(tǒng)分析過程的分析，我們可以看到基于業(yè)務建模的軟件產品系統(tǒng)分析過程其突出的可操作性、獨立性、全面性、穩(wěn)定性非常適合于階段明確軟件產品研發(fā)過程，隨著該方法的推廣，產品的核心業(yè)務得到不斷完善與傳承，產品的優(yōu)勢將會越來越得到發(fā)揮。

[1]來自 ir.hit.edu.cn,2009-07-23:業(yè)務用例模型.

[2] 來 自 IBM 網(wǎng) 站 ，Nandi等 ，2010-04：Introducing Business Entities and the Business Entity Definition Language(BEDL)-A firstclassrepresentationof dataforBPMapplications.

[3]來自www.omg.org網(wǎng)站，Introductionto OMG's Unified Modeling LanguageTM(UMLR).

[4]張龍詳，UML與系統(tǒng)分新設計 [M]，人民郵電出版社，2001，p2-10.