王智超 肖玉 周燕

（湖北開放大學(xué) 湖北省武漢市 430073）

隨著軟件工程技術(shù)的發(fā)展，許多新技術(shù)新方法不斷涌現(xiàn)。但是很多軟件設(shè)計(jì)與開發(fā)工作人員并不了解這些新技術(shù)新方法。而這些技術(shù)的采用，可以很大程度的提高軟件設(shè)計(jì)和開發(fā)的工作效率，加強(qiáng)軟件工程師和客戶之間的交流，使得軟件的質(zhì)量得以進(jìn)一步提高，同時(shí)降低開發(fā)成本[1]。本文主要針對(duì)軟件工程領(lǐng)域需求分析階段所使用的技術(shù)和方法進(jìn)行討論。

1 傳統(tǒng)軟件需求分析技術(shù)

傳統(tǒng)的需求表述方式是“軟件需求規(guī)格說明書（Software Requirement Specification）”。這種方式通過功能分解來描述系統(tǒng)功能，每個(gè)功能模塊表示一個(gè)系統(tǒng)提供的服務(wù)。采用這種方法描述軟件需求，使得系統(tǒng)功能和具體的設(shè)計(jì)交叉在一起，也就是軟件開發(fā)中兩個(gè)不同階段（需求分析和詳細(xì)設(shè)計(jì)）的工作分不清楚界限。

這種需求分析方法往往缺乏描述各個(gè)功能模塊之間的相互聯(lián)系，因?yàn)楹芏嗟南到y(tǒng)服務(wù)都是由多個(gè)模塊相互協(xié)同工作來提供的。因此，也會(huì)導(dǎo)致后期的軟件實(shí)現(xiàn)過程質(zhì)量不高，效率降低。為了解決傳統(tǒng)軟件需求分析技術(shù)在軟件開發(fā)過程中出現(xiàn)的問題，接下來介紹可視化軟件需求分析技術(shù)。

2 可視化軟件需求分析技術(shù)

為了解決傳統(tǒng)軟件需求分析技術(shù)的不足，軟件行業(yè)中的許多公司或組織提出了可視化軟件需求分析技術(shù)。這種技術(shù)通過各種模型來對(duì)軟件系統(tǒng)進(jìn)行分析和設(shè)計(jì)，以一種簡單明了的直接方式來描述系統(tǒng)的各個(gè)方面，包括需求分析，總體設(shè)計(jì)，詳細(xì)設(shè)計(jì)，物理架構(gòu)實(shí)現(xiàn)及軟件系統(tǒng)的配置與部署等。這種技術(shù)大大提高了用戶與開發(fā)人員之間的溝通效率，進(jìn)一步完善了需求分析階段的主要工作內(nèi)容，即“確定系統(tǒng)到底做什么，而不是怎么做”的問題?？梢暬能浖枨蠓治黾夹g(shù)， 以UML 統(tǒng)一建模語言最具代表性，該技術(shù)標(biāo)準(zhǔn)由擁有800 多名成員公司的國際標(biāo)準(zhǔn)化組織OMG（Object Management Group，即對(duì)象管理組）所發(fā)布，目前已成為主流的系統(tǒng)分析和設(shè)計(jì)技術(shù)。下面先對(duì)UML技術(shù)進(jìn)行描述，然后結(jié)合具體的案例，對(duì)這一可視化分析工具在完成軟件系統(tǒng)的需求分析任務(wù)過程中的應(yīng)用方法進(jìn)行闡述。

3 UML可視化技術(shù)

UML（Unified Modeling Language，即統(tǒng)一建模語言）是一種基于面向?qū)ο蠹夹g(shù)的可視化分析與設(shè)計(jì)語言，它并不是一種編程語言，而是一種標(biāo)準(zhǔn)化的圖形符號(hào)語言，這也正是可視化特點(diǎn)的由來。UML 目前已成功應(yīng)用于電信、金融、政府、電子、國防、航天航空、制造與工業(yè)自動(dòng)化、醫(yī)療、交通、電子商務(wù)等領(lǐng)域中。許多著名的計(jì)算機(jī)公司如Microsoft、HP、IBM 和Oracle 等都在使用并不斷進(jìn)行改進(jìn)和完善，使其更加適合項(xiàng)目實(shí)踐。截止到2020年，UML 最新版本為UML2.5。UML 是軟件行業(yè)的建模規(guī)范，可以對(duì)軟件項(xiàng)目建立需求模型、設(shè)計(jì)模型、實(shí)現(xiàn)模型、測(cè)試模型，因?yàn)閁ML 有精確的建模語義，各個(gè)模型之間還能有效集成，所以可以基于模型進(jìn)行仿真驗(yàn)證，使得設(shè)計(jì)具有完整的前瞻能力。UML技術(shù)包含13 種圖，分為兩個(gè)大類：靜態(tài)結(jié)構(gòu)圖和動(dòng)態(tài)行為圖，通俗講也稱為靜態(tài)建模和動(dòng)態(tài)建模[2]。這種建模技術(shù)，以可視化和立體化的方式把軟件項(xiàng)目的分析和設(shè)計(jì)過程展現(xiàn)給開發(fā)者及用戶，大大降低了項(xiàng)目參與人對(duì)項(xiàng)目的理解難度，避免了理解上的不一致性，提高了項(xiàng)目的開發(fā)效率。

在完成軟件項(xiàng)目需求分析階段的工作中，傳統(tǒng)的方式是使用軟件需求規(guī)格說明書來描述軟件項(xiàng)目的用戶需求，文檔中經(jīng)常出現(xiàn)系統(tǒng)功能說明和具體的設(shè)計(jì)描述交叉在一起的情況，也就是軟件開發(fā)中兩個(gè)不同階段（需求分析和詳細(xì)設(shè)計(jì)）的工作分不清楚界限，增加了該文檔使用者的理解難度，導(dǎo)致在內(nèi)容理解上容易產(chǎn)生不一致性。而使用UML 以可視化的方式建立項(xiàng)目系統(tǒng)的需求模型，可以有效解決傳統(tǒng)需求分析中產(chǎn)生的上述問題。

4 可視化技術(shù)在需求分析中的應(yīng)用

軟件項(xiàng)目需求分析任務(wù)通常關(guān)注系統(tǒng)的功能需求，數(shù)據(jù)對(duì)象需求，性能需求，安全性需求等方面，本文主要對(duì)功能需求和數(shù)據(jù)對(duì)象需求使用可視化技術(shù)進(jìn)行需求分析。

功能需求（Functional requirement）規(guī)定開發(fā)人員必須在產(chǎn)品中實(shí)現(xiàn)的軟件功能，用戶利用這些功能來完成任務(wù)，滿足業(yè)務(wù)需要。功能需求有時(shí)也被稱作行為需求，因?yàn)榱?xí)慣上常常使用“應(yīng)該”對(duì)其進(jìn)行描述：“系統(tǒng)應(yīng)該發(fā)送電子郵件來通知用戶已接受其預(yù)定”。功能需求描述的是開發(fā)人員需要實(shí)現(xiàn)什么。

數(shù)據(jù)對(duì)象需求（Data requirement）描述軟件產(chǎn)品中出現(xiàn)的業(yè)務(wù)對(duì)象及其之間的相互關(guān)系。這些對(duì)象往往具有很多不同的屬性，哪些屬性是系統(tǒng)業(yè)務(wù)處理過程中需要的，哪些是不需要的，都要通過數(shù)據(jù)分析來進(jìn)行準(zhǔn)確的描述。數(shù)據(jù)對(duì)象分析的結(jié)果對(duì)數(shù)據(jù)庫的邏輯模式設(shè)計(jì)有重要的指導(dǎo)作用。

傳統(tǒng)需求分析過程，需要建立在開發(fā)者對(duì)系統(tǒng)的業(yè)務(wù)處理流程比較熟悉的基礎(chǔ)之上，否則很難把系統(tǒng)的功能需求和數(shù)據(jù)對(duì)象需求描述準(zhǔn)確，對(duì)經(jīng)驗(yàn)要求較高。使用UML 可視化技術(shù)建立項(xiàng)目系統(tǒng)的需求模型，來描述該系統(tǒng)的主要用戶，以及用戶使用該系統(tǒng)能夠做什么，可以不用考慮具體的業(yè)務(wù)處理邏輯，能很好的把功能分析與設(shè)計(jì)工作分離開來。通過這種技術(shù)也能讓系統(tǒng)需求分析員更好的關(guān)注用戶的需求，提高軟件產(chǎn)品的質(zhì)量，因?yàn)橛脩魸M意度直接決定著軟件項(xiàng)目的成敗。UML 可視化需求分析技術(shù)，通過對(duì)軟件項(xiàng)目建立需求模型來實(shí)現(xiàn)，其需求模型主要使用用例模型和類圖模型進(jìn)行描述。用例模型可以對(duì)系統(tǒng)用戶及用戶能做什么進(jìn)行描述，即功能需求建模；類圖模型是用面向?qū)ο蠹夹g(shù)對(duì)系統(tǒng)中的數(shù)據(jù)對(duì)象及其之間的相互關(guān)系進(jìn)行分析，即數(shù)據(jù)對(duì)象需求建模。

例如，下面是對(duì)“網(wǎng)上訂單處理系統(tǒng)”軟件需求規(guī)格說明書的內(nèi)容進(jìn)行精簡之后的需求描述內(nèi)容：

（1）客戶在企業(yè)網(wǎng)站中選擇需要的產(chǎn)品并放入購物車，進(jìn)行訂購。

（2）客戶輸入購買細(xì)節(jié)，提交訂單，系統(tǒng)自動(dòng)將訂單信息保存到數(shù)據(jù)庫。

（3）客戶能夠要求企業(yè)營銷人員與自己聯(lián)系，進(jìn)一步了解產(chǎn)品、協(xié)商價(jià)格，確認(rèn)訂單的細(xì)節(jié)。

（4）企業(yè)營銷人員在收到客戶的聯(lián)系要求后，及時(shí)與客戶聯(lián)系，為客戶提供咨詢服務(wù)，確認(rèn)訂單的細(xì)節(jié)。如果需要修改原訂單，將修改后的訂單信息更新到數(shù)據(jù)庫并向客戶發(fā)出訂單確認(rèn)信息。

（5）客戶收到訂單確認(rèn)信息后，匯款或網(wǎng)上支付產(chǎn)品款項(xiàng)至企業(yè)銀行賬戶。

（6）訂單處理系統(tǒng)檢查用戶賬號(hào)及付款金額，若金額無誤，修改訂單狀態(tài)，將付款成功信息通知營銷人員。

（7）訂單處理系統(tǒng)從數(shù)據(jù)庫中獲取訂購信息和收到的付款信息生成發(fā)票后將該發(fā)票提供給營銷人員。營銷人員發(fā)E-mail 通知客戶已發(fā)貨，并將發(fā)票提供給倉庫管理員。

（8）系統(tǒng)從數(shù)據(jù)庫中獲得該客戶的訂單信息和個(gè)人資料，生成訂購信息列表，將該列表提供給倉庫管理員。由倉管員根據(jù)訂購信息列表配貨后，向客戶發(fā)貨并附上發(fā)票；最后修改訂單的狀態(tài)。

針對(duì)上述傳統(tǒng)需求分析方式描述的需求內(nèi)容，下面使用UML中的用例模型和類圖模型以可視化的方式描述功能需求和數(shù)據(jù)對(duì)象需求。

4.1 功能需求分析

用例模型是UML 中用來對(duì)系統(tǒng)功能需求進(jìn)行建模的工具。用戶并不想知道軟件系統(tǒng)內(nèi)部是如何設(shè)計(jì)與實(shí)現(xiàn)的，他們只關(guān)心系統(tǒng)到底能為用戶提供什么服務(wù)，這就是用例模型的精髓所在，把系統(tǒng)的功能分析和設(shè)計(jì)分離開來，只描述系統(tǒng)的需求而不考慮如何實(shí)現(xiàn)的問題。用例模型主要包含三個(gè)要素：參與者（Actor），用例（Use Case）和關(guān)系（Relationship）。由這三個(gè)要素構(gòu)成用例模型示例，如圖1所示。

圖1：用例模型示例

圖1 中參與者用一個(gè)人形符號(hào)表示，不是特指人，是指在使用系統(tǒng)或與系統(tǒng)交互中所扮演的角色。因此參與者可以是人，可以是事物，也可以是時(shí)間或其他系統(tǒng)等等。但需要強(qiáng)調(diào)的是，參與者不是指人或事物本身，而是表示人或事物當(dāng)時(shí)所扮演的角色[3]。例如“網(wǎng)上訂單處理系統(tǒng)”中的用戶和營銷人員，他們并不指某個(gè)人（小李和小張），二是這兩個(gè)人在系統(tǒng)中所扮演的用戶和營銷人員這兩個(gè)特殊的角色。

用例表示系統(tǒng)提供的服務(wù)或功能，是參與者想要系統(tǒng)做的事情。對(duì)于用例的命名，可以給用例取一個(gè)簡單、描述性的名稱，一般為帶有動(dòng)作性的詞或短語。用例在畫圖中用橢圓來表示，橢圓下面附上用例的名稱。例如系統(tǒng)需求規(guī)格說明書中描述的“訂購產(chǎn)品”的功能，該功能名稱即為一個(gè)動(dòng)詞短語，可用橢圓用例符號(hào)表示這個(gè)系統(tǒng)功能需求點(diǎn)，如果有多個(gè)功能需求點(diǎn)，則采用多個(gè)用例表示即可，非常直觀和清晰。

箭頭用來表示參與者和系統(tǒng)通過相互發(fā)送信號(hào)或消息進(jìn)行交互的關(guān)聯(lián)關(guān)系。箭頭尾部用來表示啟動(dòng)交互的一方，箭頭頭部用來表示被啟動(dòng)的一方，其中用例總是要由參與者來啟動(dòng)。該模型并沒有描述用例代表的系統(tǒng)服務(wù)或功能是如何設(shè)計(jì)并實(shí)現(xiàn)的，把功能和設(shè)計(jì)很好區(qū)分開來，避免不同階段的工作任務(wù)出現(xiàn)界限不清楚的問題，為軟件開發(fā)人員和用戶之間的溝通架起了一座很好的橋梁。

通過 “網(wǎng)上訂單處理系統(tǒng)” 需求描述的分析，可以識(shí)別出兩個(gè)主要參與者角色，客戶（Customer）和營銷人員（Salesman）。使用可視化的用例模型來描述該系統(tǒng)的功能需求，其功能需求模型如圖2所示。

圖2：功能需求模型

4.2 數(shù)據(jù)對(duì)象需求

類圖模型主要用在面向?qū)ο筌浖_發(fā)的分析階段，描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，本文中的“網(wǎng)上訂單處理系統(tǒng)”可以使用類圖來進(jìn)行數(shù)據(jù)對(duì)象需求的描述。在對(duì)系統(tǒng)進(jìn)行數(shù)據(jù)對(duì)象需求分析時(shí)，通?？紤]兩種類型的數(shù)據(jù)對(duì)象，一種是用戶角色對(duì)象，另一種是系統(tǒng)業(yè)務(wù)處理對(duì)象[4]。在面向?qū)ο蟮能浖_發(fā)中，需要把系統(tǒng)中的數(shù)據(jù)對(duì)象抽象成類的概念進(jìn)行描述，類圖模型的可視化表達(dá)恰好滿足這一需求。類圖模型用于描述系統(tǒng)中所包含的類以及它們之間的相互關(guān)系，幫助開發(fā)者和用戶簡化對(duì)系統(tǒng)的理解，它是系統(tǒng)需求分析和設(shè)計(jì)階段的重要產(chǎn)物。

系統(tǒng)中的數(shù)據(jù)對(duì)象用類進(jìn)行表示，類一般包含3 個(gè)組成部分。第一個(gè)是類名；第二個(gè)是屬性；第三個(gè)是該類的操作，如圖3所示。

圖3：類的組成

針對(duì)“網(wǎng)上訂單處理系統(tǒng)”需求描述，要實(shí)現(xiàn)該系統(tǒng)主要功能，需要有用戶，營銷人員，產(chǎn)品，訂單等基本數(shù)據(jù)對(duì)象。這4 個(gè)對(duì)象可以分別用4 個(gè)類描述，其中包含了每個(gè)數(shù)據(jù)對(duì)象的基本屬性和方法，這些信息正是數(shù)據(jù)對(duì)象需求分析所要獲得的重要內(nèi)容。分析數(shù)據(jù)對(duì)象不僅要考慮每個(gè)數(shù)據(jù)的特點(diǎn)，同時(shí)還要考慮數(shù)據(jù)之間的關(guān)系。系統(tǒng)中的每個(gè)數(shù)據(jù)對(duì)象不是孤立的，而是有相互聯(lián)系的，例如用戶訂購產(chǎn)品，營銷人員修改訂單。這里的“訂購”和“修改”描述的就是數(shù)據(jù)對(duì)象之間的聯(lián)系，在類圖模型中最主要的就是關(guān)聯(lián)關(guān)系，表達(dá)不同對(duì)象之間聯(lián)系的多重性，比如一對(duì)一，一對(duì)多，和多對(duì)多。圖4 是使用類圖模型建立了用戶和產(chǎn)品這兩個(gè)數(shù)據(jù)對(duì)象以及之間的關(guān)系，以可視化的方式展現(xiàn)了這兩個(gè)數(shù)據(jù)對(duì)象的內(nèi)容，如圖4所示。從圖中可以看出，該系統(tǒng)業(yè)務(wù)實(shí)現(xiàn)主要需要用戶對(duì)象的姓名，聯(lián)系方式等基本屬性信息，而用戶的個(gè)人愛好屬性可暫時(shí)不予考慮，即不用出現(xiàn)在類的屬性之中。

圖4：數(shù)據(jù)對(duì)象需求模型

從上述“網(wǎng)上訂單處理系統(tǒng)”的用例模型和類圖模型可以看出，UML 可視化模型簡單、清晰的表達(dá)出了軟件系統(tǒng)的功能需求和數(shù)據(jù)對(duì)象需求，為軟件需求分析工作提供了一種可視化的、不易產(chǎn)生二義性的描述工具，能夠很好的保證軟件需求分析的質(zhì)量，大大減少了軟件開發(fā)后期因?yàn)樾枨蟛粶?zhǔn)確、不完整而導(dǎo)致的一系列增加軟件開發(fā)成本的難題。

5 小結(jié)

通過對(duì)傳統(tǒng)的和可視化的軟件需求分析技術(shù)的對(duì)比分析，后者的優(yōu)勢(shì)顯而易見?？梢暬男枨蠓治黾夹g(shù)中，以UML 最為突出，在軟件行業(yè)應(yīng)用中所占的比例也將隨著軟件的發(fā)展而逐步增大，會(huì)有更多的軟件從業(yè)人員去學(xué)習(xí)和了解，并在軟件開發(fā)中發(fā)揮出積極作用。