用UML建模需要注意的問題

用UML：蕓模需要注意的問題用UML建模時(shí)，對(duì)軟件開發(fā)過程是有要求的，必須是用例驅(qū)動(dòng)，以架構(gòu)為中心，迭代和遞增的開發(fā)，如果軟件開發(fā)組織的軟件開發(fā)過程不能滿足這三點(diǎn)要求，那么UML的使用效果就會(huì)大打折扣，下面詳細(xì)論述：一、 用例驅(qū)動(dòng)用例驅(qū)動(dòng)意味著為系統(tǒng)定義的用例是整個(gè)開發(fā)過程的基礎(chǔ)。用例在多個(gè)核心工作流程中都發(fā)揮了作用。1、 用例的概念可用來表示業(yè)務(wù)流程，我們稱這種用例的變體為“業(yè)務(wù)用例”。2、 用例模型是需求工作流程的輸出結(jié)果。在這一早期流程中，需要通過用例來建立用戶希望系統(tǒng)完成的任務(wù)的模型。這樣，用例構(gòu)成了一個(gè)重要的基本概念，客戶和系統(tǒng)開發(fā)人員都必須認(rèn)可這個(gè)概念。3、 在分析設(shè)計(jì)中，用例是在設(shè)計(jì)模型中實(shí)現(xiàn)的。您需要生成用例實(shí)現(xiàn)來說明在設(shè)計(jì)模型中如何通過對(duì)象的交互來執(zhí)行用例。此模型根據(jù)設(shè)計(jì)對(duì)象來說明所實(shí)施系統(tǒng)的各個(gè)組成部分，以及這些部分如何通過相互作用來執(zhí)行用例。4、 在實(shí)施階段，設(shè)計(jì)模型就是實(shí)施的規(guī)約。由于用例是設(shè)計(jì)模型的基礎(chǔ)，所以用例需通過設(shè)計(jì)類來實(shí)施。5、 在測(cè)試期間，用例是確定測(cè)試用例和測(cè)試過程的基礎(chǔ)。也就是說，通過執(zhí)行每一個(gè)用例來核實(shí)系統(tǒng)。6、 在項(xiàng)目管理過程中，用例被用來作為計(jì)劃迭代式開發(fā)的基礎(chǔ)。7、 在部署工作流程中，它們構(gòu)成用戶手冊(cè)闡述內(nèi)容的基礎(chǔ)。用例也可用來確定產(chǎn)品構(gòu)件如何排列組合。例如，客戶可通過將用例進(jìn)行某種組合來配置一個(gè)系統(tǒng)。二、 以架構(gòu)為中心構(gòu)架之所以重要，原因有以下幾點(diǎn)：1、它使您可對(duì)項(xiàng)目進(jìn)行并保持理智的控制，應(yīng)付項(xiàng)目中復(fù)雜多變的情況，同時(shí)保持系統(tǒng)的完整性。一個(gè)復(fù)雜的系統(tǒng)不僅僅是其各組成部分之和，也不光是一連串沒有關(guān)聯(lián)關(guān)系的、很小的技巧決定。它必須依靠某種連貫統(tǒng)一的結(jié)構(gòu)來有條理地組織那些部分，并且提供準(zhǔn)確的規(guī)則，使系統(tǒng)發(fā)展過程中，其復(fù)雜程度不會(huì)膨脹，超越人類的理解力。通過建立用于討論設(shè)計(jì)問題的一套公共參考材料和一個(gè)公共詞匯表，構(gòu)架提供了增進(jìn)交流和理解的手段。2、 它是大規(guī)模復(fù)用的有效基礎(chǔ)。通過明確闡述它們之間的主要構(gòu)件和關(guān)鍵接口，構(gòu)架為您決定重復(fù)使用提供依據(jù)，包括內(nèi)部復(fù)用（確定公用的部分）和外部復(fù)用（并入現(xiàn)成的構(gòu)件）。它還允許更大規(guī)模上的復(fù)用：構(gòu)架本身的復(fù)用，用于處理同一領(lǐng)域中的不同功能。3、 構(gòu)架還可作為項(xiàng)目管理的基礎(chǔ)。項(xiàng)目計(jì)劃和人員配備是根據(jù)主要構(gòu)件的類別組織進(jìn)行的?；镜慕Y(jié)構(gòu)決策是由一個(gè)人員組成相對(duì)固定的構(gòu)架小組作出的，他們不是分散的。而開發(fā)活動(dòng)則被分配給若干個(gè)小組，每個(gè)小組負(fù)責(zé)開發(fā)系統(tǒng)的一個(gè)或若干個(gè)部分。三、迭代和遞增的開發(fā)迭代式方法一般要優(yōu)于線性或瀑布式方法，其原因很多。1、 允許變更需求。需求有時(shí)會(huì)變化，這常常給項(xiàng)目帶來麻煩，它們會(huì)導(dǎo)致延期交付、工期延誤、客戶不滿意、開發(fā)人員受挫。2、 逐步集成元素。在迭代式方法中，集成可以說是連續(xù)不斷的。過去在項(xiàng)目結(jié)束時(shí)要占到整個(gè)項(xiàng)目工作量的那段較長的、不確定的且棘手的時(shí)期，現(xiàn)在分散到六至九個(gè)集成部分中，每一部分要集成的元素都比過去少得多。3、 及早降低風(fēng)險(xiǎn)。因?yàn)轱L(fēng)險(xiǎn)一般只有在集成階段才能發(fā)現(xiàn)或得到處理。在初期迭代時(shí)，檢查所有的核心工作流程，對(duì)項(xiàng)目使用的工具、市售軟件及人員技能等許多方面進(jìn)行磨合。過去認(rèn)定的風(fēng)險(xiǎn)可能被證明不再是風(fēng)險(xiǎn)，而又可能出現(xiàn)一批新的未曾懷疑過的風(fēng)險(xiǎn)。4、 有助于組織學(xué)習(xí)和提高。團(tuán)隊(duì)成員有機(jī)會(huì)在整個(gè)生命周期中邊做邊學(xué)，各顯其能。測(cè)試員可以早一些開始測(cè)試，技術(shù)文檔編寫員可及早開始編寫，其他人也是如此。如果是非迭代式開發(fā)，這些人在初期只能制定計(jì)劃或培訓(xùn)技能，空等著開始他們的工作。培訓(xùn)需求等也可在評(píng)估復(fù)審中盡早提出。5、 提高復(fù)用性。因?yàn)榉植糠衷O(shè)計(jì)或?qū)嵤┍绕痤A(yù)先確定所有共性更容易確定公用部分。確定和開發(fā)可重復(fù)使用的部分并非易事。早期迭代中的設(shè)計(jì)復(fù)審可使構(gòu)架設(shè)計(jì)師確定毋庸置疑的潛在復(fù)用部分，并在以后的迭代中開發(fā)和完善這些公用代碼。6、生成性能更強(qiáng)壯的產(chǎn)品。因?yàn)樵诙啻蔚心偸遣粩嗟丶m正錯(cuò)誤。在產(chǎn)品脫離先啟階段后的初期迭代中仍然可以發(fā)現(xiàn)缺陷。性能上的瓶頸可以盡早發(fā)現(xiàn)并處理，而不象在交付前夕，此時(shí)已來不及處理。7、 容許產(chǎn)品進(jìn)行戰(zhàn)術(shù)改變。例如同現(xiàn)有的同類產(chǎn)品競(jìng)爭?？梢詻Q定采用搶先競(jìng)爭對(duì)手一步的方法，提前發(fā)布一個(gè)功能簡化的產(chǎn)品，或者采用其他廠商的已有技術(shù)。8、 迭代流程自身可在進(jìn)行過程中得到改進(jìn)和精煉。一次迭代結(jié)束時(shí)的評(píng)估不僅要從產(chǎn)品和進(jìn)度的角度來考察項(xiàng)目的情況，而且還要分析組織和流程本身有什么待改進(jìn)之處，以便在下次迭代中更好地完成任務(wù)。通常在軟件開發(fā)過程中，迭代在數(shù)量、持續(xù)時(shí)間和目標(biāo)上都是按計(jì)劃進(jìn)行的。參與者的任務(wù)和職責(zé)都已確定好。對(duì)進(jìn)度進(jìn)行的目標(biāo)評(píng)測(cè)都將記錄備查。從一次迭代到下一次迭代確實(shí)會(huì)存在返工現(xiàn)象，但返工也是嚴(yán)格按規(guī)定進(jìn)行的。四、 使用不當(dāng)?shù)膯栴}很多企業(yè)員工在使用UML的過程中，只是進(jìn)行了領(lǐng)域建模，沒有進(jìn)行用例建模，這樣是不能最大可能地發(fā)揮UML的優(yōu)勢(shì)的，因?yàn)樵摻M織的軟件開發(fā)過程不是用例驅(qū)動(dòng)的。如果軟件開發(fā)組織的軟件開發(fā)過程不能滿足上述三點(diǎn)要求，那么UML的使用效果就會(huì)大打折扣。也會(huì)產(chǎn)生一些問題，有些組織在使用UML之后，發(fā)現(xiàn)前期花很長時(shí)間設(shè)計(jì)的模型到了項(xiàng)目的中后期和真正的開發(fā)成果相去甚遠(yuǎn)，以至于全都束之高閣了，如果產(chǎn)生這樣的問題，就應(yīng)該仔細(xì)研究一下組織的軟件開發(fā)過程，是否滿足上述三點(diǎn)要求，如果軟件開發(fā)過程不滿足迭代的開發(fā)，模型沒有隨著進(jìn)度改進(jìn)，這種問題就很容易出現(xiàn)。UML2.0和MDA（模型驅(qū)動(dòng)架構(gòu)）提出了一些解決開發(fā)周期前期和后續(xù)的模型不一致問題的方法，就是通過模型的轉(zhuǎn)換來完成模型的自動(dòng)變更，而不是對(duì)各個(gè)抽象層次的模型全部進(jìn)行修改，但MDA為大部分人所接受還需要些時(shí)日。五、 總結(jié)綜上所述，UML雖然是軟件