李明亮

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

1 引言

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

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

2 相關(guān)定義

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

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

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

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

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

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

3 概述

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

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

基于業(yè)務(wù)建模的系統(tǒng)分析方法，是以面向?qū)ο蟮姆治龇椒橹笇?dǎo)思想，并規(guī)范化過程及輸入輸出、以UML圖為表現(xiàn)形式建立業(yè)務(wù)模型，逐步全面的完成系統(tǒng)分析。其分析過程如圖1

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

4.1 輸入文檔

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

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

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

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

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

3 非功能需求描述

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

4.2 模塊級需求分析

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

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

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

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

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

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

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

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

4 模塊需求分析評審

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

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

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

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

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

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

3匯總生成詞匯表

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

4領(lǐng)域間接口的設(shè)計

結(jié)合匯合后的領(lǐng)域模型，利用用例分析時產(chǎn)生的跨領(lǐng)域?qū)嶓w訪問，抽象出領(lǐng)域間的訪問接口（行為名稱、所需參數(shù)、返回值）用UML的類圖表現(xiàn)出來。

4.4 主要輸出文檔

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

需求分析的輸出成果是以對以下文檔評審?fù)ㄟ^為結(jié)束標志。

①領(lǐng)域詞匯表（實體詞匯表、行為詞匯表）

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

③領(lǐng)域模型（用UML類圖表示）

④領(lǐng)域間接口（用UML類圖表示）

5 特點分析

5.1 可操作性

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

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

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

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

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

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

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

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

5.4 階段獨立的分析方法

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

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

(1)可視化，表示能力強。通過UML的模型圖能清晰地表示系統(tǒng)的邏輯模型和實現(xiàn)模型?？捎糜诟鞣N復(fù)雜系統(tǒng)的建模。

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

(3)獨立于程序設(shè)計。用UML建立的軟件系統(tǒng)模型可以用 Java、VC++、SmalltaIk等任何一種面向?qū)ο蟮某绦蛟O(shè)計來實現(xiàn)。

2.獨立于其他階段

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

6 使用效果

在一個研發(fā)周期10個月總工作量120個人月的基于信息資源管理的內(nèi)容管理產(chǎn)品當(dāng)中使用了基于業(yè)務(wù)建模的軟件產(chǎn)品系統(tǒng)分析過程，投入到系統(tǒng)分析時間為3個月24個人月工作量。產(chǎn)品從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)分析結(jié)果的修改。

2適應(yīng)變化能力強

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

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

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

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

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

結(jié)語

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

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

[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)分新設(shè)計 [M]，人民郵電出版社，2001，p2-10.