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

李明亮

（遠(yuǎn)光軟件股份有限公司，廣東 珠海 519085）

1 引言

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

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

2 相關(guān)定義

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

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

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

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

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

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

3 概述

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

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

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

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

4.1 輸入文檔

對業(yè)務(wù)需求文檔的規(guī)范性要求，是一個(gè)很好的開始。按照分析設(shè)計(jì)人員的要求，結(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ī)則、后置需求、特殊需求、擴(kuò)展點(diǎn)、補(bǔ)充說明（對操作對象的屬性、規(guī)則說明）等信息。

3 非功能需求描述

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

4.2 模塊級需求分析

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

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

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

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

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

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

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

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

4 模塊需求分析評審

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

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

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

系統(tǒng)中的實(shí)體往往會(huì)在多個(gè)模型中被操作，通過匯總，補(bǔ)充了實(shí)體的行為、完善領(lǐng)域模型，實(shí)體在系統(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)域可以獨(dú)立完成業(yè)務(wù)，與其他領(lǐng)域的交互以接口服務(wù)調(diào)用的方式進(jìn)行。如圖二為組織管理實(shí)體模型。

3匯總生成詞匯表

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

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

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

4.4 主要輸出文檔

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

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

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

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

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

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

5 特點(diǎn)分析

5.1 可操作性

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

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

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

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

對于產(chǎn)品需要業(yè)務(wù)穩(wěn)定而對產(chǎn)品所支持的項(xiàng)目又希望能提供更多的定制，于是穩(wěn)定及擴(kuò)展兩者剪不斷理還亂，基于實(shí)體與行為分離的業(yè)務(wù)模型的建立讓核心的業(yè)務(wù)得到了穩(wěn)定，而擴(kuò)展的功能在需求分析的時(shí)候就與核心用松耦合的方式獨(dú)立出行為與屬性，兼顧了項(xiàng)目又保障了產(chǎn)品，時(shí)機(jī)成熟項(xiàng)目的內(nèi)容可以納入到產(chǎn)品中來，這樣項(xiàng)目與產(chǎn)品進(jì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)化的整體目標(biāo)的現(xiàn)代科學(xué)方法。

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

5.4 階段獨(dú)立的分析方法

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

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

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

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

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

2.獨(dú)立于其他階段

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

6 使用效果

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

1獨(dú)立的特性

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

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

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

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

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

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

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

結(jié)語

經(jīng)過以上對基于業(yè)務(wù)建模的軟件產(chǎn)品系統(tǒng)分析過程的分析，我們可以看到基于業(yè)務(wù)建模的軟件產(chǎn)品系統(tǒng)分析過程其突出的可操作性、獨(dú)立性、全面性、穩(wěn)定性非常適合于階段明確軟件產(chǎn)品研發(fā)過程，隨著該方法的推廣，產(chǎn)品的核心業(yè)務(wù)得到不斷完善與傳承，產(chǎn)品的優(yōu)勢將會(huì)越來越得到發(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]張龍?jiān)敚琔ML與系統(tǒng)分新設(shè)計(jì) [M]，人民郵電出版社，2001，p2-10.