(天津機(jī)電工藝學(xué)院，天津 300350)

假如你的項(xiàng)目組負(fù)責(zé)開發(fā)某款應(yīng)用軟件，事先將相關(guān)資料、程序員、工具配備齊全，隨后你就開始緊鑼密鼓的工作，表面看上去這符合一般事務(wù)的發(fā)展規(guī)律，實(shí)際上這是非常錯(cuò)誤的行為。比如：在你制作的過程中甚至制作完畢，客戶提出了新的改進(jìn)意見，會(huì)不會(huì)導(dǎo)致你整個(gè)工程的作廢？在這期間，你的項(xiàng)目所付出的代價(jià)太高了，時(shí)間最后沒有轉(zhuǎn)化成利益，這樣的結(jié)果使我們不愿意看到的。如果我們預(yù)估了風(fēng)險(xiǎn)，在正式施工之前做了各種模型和預(yù)案，即使出現(xiàn)了意外情況，我們也能將風(fēng)險(xiǎn)降到最低。

如今在開發(fā)軟件過程中，正式進(jìn)入“實(shí)施”階段前，廣泛采用的方式就是系統(tǒng)分析技術(shù)。我們需經(jīng)歷需求分析、業(yè)務(wù)流程分析、架構(gòu)設(shè)計(jì)、系統(tǒng)總體設(shè)計(jì)、詳細(xì)設(shè)計(jì)等階段，在每個(gè)階段都會(huì)產(chǎn)生文檔。而期間產(chǎn)生的文檔，便成了日后編寫程序的依據(jù)，我們依照文檔中的軟件設(shè)計(jì)“模型”，用一種我們所熟知的程序設(shè)計(jì)語言實(shí)現(xiàn)即可?！敖！笔窃S多工程領(lǐng)域廣泛采用的技術(shù)，我們建造房屋，生產(chǎn)汽車都能借助模型讓用戶得到未來實(shí)際物體的印象。在系統(tǒng)開發(fā)領(lǐng)域中，建模的過程實(shí)際上就是制作系統(tǒng)藍(lán)圖的過程。

UML(統(tǒng)一建模語言)就是一種滿足上述要求的工具，由它便可輕松的描繪出系統(tǒng)的藍(lán)圖。它將一個(gè)復(fù)雜的問題簡(jiǎn)單化，可實(shí)現(xiàn)大型復(fù)雜系統(tǒng)各種軟件成分描述的可視化，清晰的說明系統(tǒng)的結(jié)構(gòu)和行為，指導(dǎo)我們描繪出系統(tǒng)的模型，并產(chǎn)生用于日后決策的文檔。

使用UML來繪制模型，需要先從系統(tǒng)中分析出兩個(gè)問題，它們分別是：事物以及事物之間的關(guān)系，然后根據(jù)規(guī)則導(dǎo)出圖形，這三個(gè)內(nèi)容具體劃分如圖1所示：

圖1 UML的內(nèi)容結(jié)構(gòu)圖

例如，在學(xué)生選課系統(tǒng)當(dāng)中學(xué)生選課行為的Use Case模型如圖2所示，該圖只包含了最上層的Use Case模型，是系統(tǒng)某功能模塊的高層抽象，在今后的開發(fā)實(shí)踐中，我們會(huì)對(duì)問題進(jìn)一步的進(jìn)行分解，隨之Use Case模型便會(huì)自上而下進(jìn)行細(xì)化，描繪出更詳細(xì)的Use Case模型。

圖2 學(xué)生選課的模型圖

使用UML作為工具，采用面向?qū)ο蟮姆椒▽?duì)學(xué)生選課系統(tǒng)進(jìn)行分析，從系統(tǒng)的主要功能為出發(fā)點(diǎn)，而后逐步進(jìn)行細(xì)化設(shè)計(jì)。處理好一組類、接口和協(xié)作及它們之間的關(guān)系，隨之建立類圖。狀態(tài)圖用來描述一個(gè)指定對(duì)象的狀態(tài)、事件和事件之間的活動(dòng)。它用來描述系統(tǒng)的動(dòng)態(tài)行為，大多數(shù)面向?qū)ο蠹夹g(shù)都用狀態(tài)圖表示單個(gè)對(duì)象在其生命周期中的行為。一個(gè)狀態(tài)圖包括一系列的狀態(tài)以及狀態(tài)之間的轉(zhuǎn)移。將已有的狀態(tài)圖特殊化，便形成了活動(dòng)圖。活動(dòng)圖在系統(tǒng)分析和設(shè)計(jì)的過程中使用比較頻繁,它既可用來描述類的動(dòng)態(tài)行為,也可以描述事件內(nèi)部的工作過程。雖然活動(dòng)圖是由狀態(tài)圖演變而來，但是它們分別表示了不同的意義。

我們利用UML，舉了簡(jiǎn)單的實(shí)例，對(duì)用于分析的圖形工具做了簡(jiǎn)單地介紹。實(shí)際上我們?cè)诋媹D的同時(shí)就是逐步深入了解系統(tǒng)的過程，是對(duì)系統(tǒng)建模的過程。在UML中，圖形工具有很多，但它們各自的出發(fā)點(diǎn)不同，也將服務(wù)于我們不同的分析目的。從應(yīng)用的角度看,當(dāng)采用面向?qū)ο蠹夹g(shù)設(shè)計(jì)系統(tǒng)時(shí)，首先是系統(tǒng)進(jìn)行需求分，而后根據(jù)需求分析的結(jié)果導(dǎo)出系統(tǒng)的用例圖、類圖、配置圖等靜態(tài)模型，其目的是構(gòu)造系統(tǒng)的結(jié)構(gòu)。而后下一步我們要做的是導(dǎo)出系統(tǒng)的動(dòng)態(tài)模型，其中包括狀態(tài)圖、活動(dòng)圖等。

實(shí)際上，從上面的分析我們可以看出，在一個(gè)軟件項(xiàng)目的開發(fā)過程中，僅僅利用一種視圖描述模型是不夠充分的，應(yīng)該采取多視角的方式逐步求精。例如：如果我們正在裝修我們的新房，我們?cè)谡窖b修前為這個(gè)新房繪制了一系列裝修圖紙，但是單一拿出任何一張圖紙，完全不能說明新房的裝修過程或者細(xì)節(jié)規(guī)劃。如果我們要向深入了解，必須準(zhǔn)備好它的平面房型圖、立體成型圖、電氣規(guī)劃圖、水路改造圖等等。然而，我們?cè)讵?dú)立繪制了裝修所需要的各種圖紙之后，還需要充分考慮施工時(shí)它們之間會(huì)產(chǎn)生的聯(lián)系。比如:我們所繪制的電氣規(guī)劃圖，完全要和新房的平面圖相聯(lián)系，合理布局；并且要保證不與新房的水路改造圖相沖突。在系統(tǒng)分析與設(shè)計(jì)的過程中也是如此，為了清晰的描述系統(tǒng)的某個(gè)局部問題的結(jié)構(gòu)，需要將各種視圖有機(jī)的結(jié)合起來。利用系統(tǒng)架構(gòu)圖展示系統(tǒng)的整體結(jié)構(gòu)、用例圖展示系統(tǒng)當(dāng)中操作者或其它模塊與事件之間的聯(lián)系、交互視圖展示系統(tǒng)各部分之間以及系統(tǒng)與環(huán)境之間的聯(lián)系、實(shí)體聯(lián)系圖展示了系統(tǒng)數(shù)據(jù)庫的細(xì)節(jié)等等。一個(gè)大型的系統(tǒng)必定是復(fù)雜的，它不僅僅由各種功能模塊或者各種部件組合而成的，它是在已經(jīng)建立的各個(gè)部件基礎(chǔ)上，根據(jù)一定的規(guī)則串聯(lián)起來的，彼此相互依賴的構(gòu)成一個(gè)整體。

在所有的軟件項(xiàng)目開發(fā)過程中，都應(yīng)該將建模工作放在首要位置。經(jīng)統(tǒng)計(jì)表明，很多軟件在開發(fā)過程中都很少采用系統(tǒng)的建模方式，甚至根本沒有采用；而隨著軟件開發(fā)規(guī)模的減少，建模的方式也顯得非正式起來。他們經(jīng)常在紙張上勾勒一些草圖或者用電腦記錄一些過程，實(shí)際上，這種方式也是很正確的。他們認(rèn)為，凡是有助于系統(tǒng)開發(fā)的行為都可以采用。即使非正規(guī)的模型不能精細(xì)的描述出系統(tǒng)的細(xì)節(jié)，但我們?nèi)匀豢梢詮睦锩嬲业揭恍┯袃r(jià)值的東西，也可以得到一些藍(lán)圖。然而，這些舉動(dòng)是十分不正式的，它沒有一種標(biāo)準(zhǔn)的語言來描述、沒有統(tǒng)一的格式，沒有統(tǒng)一的規(guī)則。如果我們采用標(biāo)準(zhǔn)化的形式來說明，那么每個(gè)開發(fā)項(xiàng)目都能從中得到益處。建?？梢詭椭覀?cè)谙到y(tǒng)開發(fā)的過程中，隨時(shí)發(fā)現(xiàn)不合適的構(gòu)造，項(xiàng)目規(guī)模越大，則產(chǎn)生這種情況的可能性就越大。

如今，建模這種技術(shù)已經(jīng)深入到各個(gè)學(xué)科領(lǐng)域中了，如果我們脫離了建模技術(shù)，直接就裝修了新房、制造了飛機(jī)和汽車，那么結(jié)果是很難預(yù)料的。在新房正式裝修前，我們需要一定程度的建模，以便日后能夠更好的施工；在正式拍攝電影前，我們寫了劇本，劇本本身就可以理解為模型。在軟件開發(fā)過程中，不成功的案例舉不勝數(shù)，原因各不相同；但成功的案例是有著很多相似之處的，其中最關(guān)鍵的技術(shù)是采用了建模。

參考文獻(xiàn)：

[1]吳建等.UML基礎(chǔ)與ROSE建模案例[M].北京：人民郵電出版社，2004.

[2]陳承歡.管理信息系統(tǒng)基礎(chǔ)與開發(fā)技術(shù)[M].北京：人民郵電出版社，2005.