論UML在程序開發(fā)中的重要作用

1、-. z.經(jīng)典的軟件工程思想將軟件開發(fā)分成5個階段:需求分析系統(tǒng)分析與設(shè)計;系統(tǒng)實現(xiàn)測試及維護五個階段。序言如果想搭一個狗窩，備好木料、釘子和一些根本工具如錘子、鋸和卷尺之后，就可以開場工作了。從制定一點初步方案到完成一個滿足適當功能的狗窩，可能不用別人幫助，在幾個小時內(nèi)就能夠?qū)崿F(xiàn)。只要狗窩夠大且不太漏水，狗就可以安居。如果未能到達希望的效果，返工總是可以的，無非是讓狗受點委屈。如果你要建造一座高層辦公大廈，假設(shè)還是先備好木料、釘子和一些根本工具就開場工作，那將是非常愚蠢的。因為你所使用的資金可能是別人的，他們會對建筑物的規(guī)模、形狀和風(fēng)格做出要求。同時，他們經(jīng)常會改變想法，甚至是在工程已經(jīng)開工

2、之后。由于失敗的代價太高了，因此必須要做詳盡的方案。負責建筑物設(shè)計和施工的是一個龐大的組織機構(gòu)，你只是其中的一局部。這個組織將需要各種各樣的設(shè)計圖和模型，以供各方相互溝通。只要得到了適宜的人員和工具，并對把建筑概念轉(zhuǎn)換為實際建筑的過程進展積極的管理，將會建成這座滿足使用要求的大廈。如果想繼續(xù)從事建筑工作，則一定要在使用要求和實際的建筑技術(shù)之間做好平衡，并且處理好建筑團隊成員們的休息問題，既不能把他們置于風(fēng)險之中，也不能驅(qū)使他們過分辛苦地工作以至于精疲力盡。奇怪的是，很多軟件開發(fā)組織開場想建造一座大廈式的軟件，而在動手處理時卻好似他們正在倉促地造一個狗窩。有時你是幸運的。如果在恰當?shù)臅r間有足夠的

3、適宜人員，并且其他一切事情都很如意，你的團隊有可能僅是可能推出一個令用戶眼花繚亂的軟件產(chǎn)品。然而，一般的情況下，不可能所有人員都適宜適宜的人員經(jīng)常供不應(yīng)求，時間并不總是恰當?shù)淖蛱炜偸歉?，其他的事情也并不盡如人意常常由不得自己。現(xiàn)在對軟件開發(fā)的要求正在日益增加，而開發(fā)團隊卻還是經(jīng)常單純地依靠他們唯一真正知道如何做好的一件事編寫程序代碼。英雄式的編程工作成為這一行業(yè)的傳奇，人們似乎經(jīng)常認為更努力地工作是面對開發(fā)中出現(xiàn)的各種危機的正常反響。然而，這未必能產(chǎn)生正確的程序代碼，而且一些工程是非常巨大的，無論怎樣延長工作時間，也缺乏以完成所需的工作。如果真正想建造一個相當于房子或大廈類的軟件系統(tǒng)，問題可

4、不是僅僅編寫許多軟件。事實上，關(guān)鍵是要編出正確的軟件，并考慮如何少寫軟件。要生產(chǎn)合格的軟件就要有一套關(guān)于體系構(gòu)造、過程和工具的規(guī)*。即使如此，很多工程開場看起來像狗窩，但隨后開展得像大廈，原因很簡單，它們是自己成就的犧牲品。如果對體系構(gòu)造、過程或工具的規(guī)*沒有作任何考慮，總有一天狗窩會膨脹成大廈，并會由于其自身的重量而倒塌。狗窩的倒塌可能使你的狗惱怒；同理，不成功的大廈則將對大廈的租戶造成嚴重的影響。不成功的軟件工程失敗的原因各不一樣，而所有成功的工程在很多方面都是相似的。成功的軟件組織有很多成功的因素，其中共同的一點就是對建模的采用。工程開發(fā)中模型是什么以及建模的重要性。則，模型是什么？簡單

5、地說：模型是對現(xiàn)實的簡化。模型提供了系統(tǒng)的藍圖。模型既可以包括詳細的方案，也可以包括從很高的層次考慮系統(tǒng)的總體方案。一個好的模型包括那些有廣泛影響的主要元素，而忽略那些與給定的抽象水平不相關(guān)的次要元素。每個系統(tǒng)都可以從不同的方面用不同的模型來描述，因而每個模型都是一個在語義上閉合的系統(tǒng)抽象。模型可以是構(gòu)造性的，強調(diào)系統(tǒng)的組織。它也可以是行為性的，強調(diào)系統(tǒng)的動態(tài)方面。為什么要建模？一個根本理由是：建模是為了能夠更好地理解正在開發(fā)的系統(tǒng)。通過建模，要到達4個目的：1模型有助于按照實際情況或按照所需要的樣式對系統(tǒng)進展可視化。2模型能夠規(guī)約系統(tǒng)的構(gòu)造或行為。3模型給出了指導(dǎo)構(gòu)造系統(tǒng)的模板。4模型對做出

6、的決策進展文檔化。 建模并不只是針對大的系統(tǒng)。甚至像狗窩那樣的軟件也能從一些建模中受益。然而，可以明確地講，系統(tǒng)越大、越復(fù)雜，建模的重要性就越大，一個很簡單的原因是：因為不能完整地理解一個復(fù)雜的系統(tǒng)，所以要對它建模。人對復(fù)雜問題的理解能力是有限的。通過建模，縮小所研究問題的*圍，一次只著重研究它的一個方面，即把一個困難問題劃分成一系列能夠解決的小問題；解決了這些小問題也就解決了這個難題。此外，通過建?？梢栽鰪娙说闹橇?。一個適中選擇的模型可以使建模人員在較高的抽象層次上工作。每個工程都能從一些建模中受益。即使在一次性的軟件開發(fā)中由于可視化編程語言的支持，可以輕而易舉地扔掉不適合的軟件。建模也能幫

7、助開發(fā)組更好地對系統(tǒng)方案進展可視化，并幫助他們正確地進展構(gòu)造，使開發(fā)工作進展得更快。如果根本不建模，工程越復(fù)雜，就越有可能失敗或者構(gòu)造出錯誤的東西。所有實用系統(tǒng)都有一個自然趨勢：隨著時間的推移變得越來越復(fù)雜。雖然今天可能認為不需要建模，但隨著系統(tǒng)的演化，終將會對這個決定感到懊悔，但那時為時已晚。在工程開發(fā)中如何建模，接下來我將詳細講解一下建模工具UML。UML介紹UML( Unified Modeling Language )又稱統(tǒng)一建模語言或標準建模語言，是始于1997年一個OMG標準，它是一個支持模型化和軟件系統(tǒng)開發(fā)的圖形化語言，為軟件開發(fā)的所有階段提供模型化和可視化支持，包括由需求分析到

8、規(guī)格，到構(gòu)造和配置。UML是一種功能強大的,面向?qū)ο蟮目梢暬到y(tǒng)分析的建模語言,它的各個模型可以幫助開發(fā)人員更好地理解業(yè)務(wù)流程,建立更可靠,更完善的系統(tǒng)模型.從而使用戶和開發(fā)人員對問題的描述到達一樣的理解,以減少語義差異,保障分析的正確性。UML建模分為需求建模和設(shè)計建模，需求建模的目的是確定系統(tǒng)邊界并明確系統(tǒng)需要實現(xiàn)的功能。而設(shè)計建模主要目的是用于開發(fā)團隊中的設(shè)計思想交流；以及后續(xù)程序設(shè)計的依據(jù)；后續(xù)測試和驗收程序的依據(jù)。UML應(yīng)用領(lǐng)域UML的目標是以面向?qū)ο髨D的方式來描述任何類型的系統(tǒng)，具有很寬的應(yīng)用領(lǐng)域。其中最常用的是建立軟件系統(tǒng)的模型，但它同樣可以用于描述非軟件領(lǐng)域的系統(tǒng)，如機械系統(tǒng)、

9、企業(yè)機構(gòu)或業(yè)務(wù)過程，以及處理復(fù)雜數(shù)據(jù)的信息系統(tǒng)、具有實時要求的工業(yè)系統(tǒng)或工業(yè)過程等?？傊?，UML是一個通用的標準建模語言，可以對任何具有靜態(tài)構(gòu)造和動態(tài)行為的系統(tǒng)進展建模。此外，UML適用于系統(tǒng)開發(fā)過程中從需求規(guī)格描述到系統(tǒng)完成后測試的不同階段。在需求分析階段，可以用用例來捕獲用戶需求。通過用例建模，描述對系統(tǒng)感興趣的外部角色及其對系統(tǒng)用例的功能要求。分析階段主要關(guān)心問題域中的主要概念如抽象、類和對象等和機制，需要識別這些類以及它們相互間的關(guān)系，并用UML類圖來描述。為實現(xiàn)用例，類之間需要協(xié)作，這可以用UML動態(tài)模型來描述。在分析階段，只對問題域的對象現(xiàn)實世界的概念建模，而不考慮定義軟件系統(tǒng)中技

10、術(shù)細節(jié)的類如處理用戶接口、數(shù)據(jù)庫、通訊和并行性等問題的類。這些技術(shù)細節(jié)將在設(shè)計階段引入，因此設(shè)計階段為構(gòu)造階段提供更詳細的規(guī)格說明。編程構(gòu)造是一個獨立的階段，其任務(wù)是用面向?qū)ο缶幊陶Z言將來自設(shè)計階段的類轉(zhuǎn)換成實際的代碼。在用UML建立分析和設(shè)計模型時，應(yīng)盡量防止考慮把模型轉(zhuǎn)換成*種特定的編程語言。因為在早期階段，模型僅僅是理解和分析系統(tǒng)構(gòu)造的工具，過早考慮編碼問題十分不利于建立簡單正確的模型。UML模型還可作為測試階段的依據(jù)。系統(tǒng)通常需要經(jīng)過單元測試、集成測試、系統(tǒng)測試和驗收測試。不同的測試小組使用不同的UML圖作為測試依據(jù)：單元測試使用類圖和類規(guī)格說明；集成測試使用部件圖和合作圖；系統(tǒng)測試使

11、用用例圖來驗證系統(tǒng)的行為；驗收測試由用戶進展，以驗證系統(tǒng)測試的結(jié)果是否滿足在分析階段確定的需求?？傊瑯藴式ＵZ言UML適用于以面向?qū)ο蠹夹g(shù)來描述任何類型的系統(tǒng)，而且適用于系統(tǒng)開發(fā)的不同階段，從需求規(guī)格描述直至系統(tǒng)完成后的測試和維護。UML圖形種類介紹UML從考慮系統(tǒng)的不同角度出發(fā)，定義了用例圖、類圖、對象圖、狀態(tài)圖、活動圖、序列圖、協(xié)作圖、構(gòu)件圖、部署圖等9種圖，按其特點可分成五大類，1.用例圖；2.靜態(tài)圖：類圖、對象圖；3.行為圖：活動圖、狀態(tài)圖；4.交互圖：順序圖、協(xié)作圖；5.實現(xiàn)圖：構(gòu)件圖、部署圖。這些圖從不同的側(cè)面對系統(tǒng)進展描述。系統(tǒng)模型將這些不同的側(cè)面綜合成一致的整體，便于系統(tǒng)的分

12、析和構(gòu)造。1、用例圖描述角色以及角色與用例之間的連接關(guān)系。說明的是誰要使用系統(tǒng)，以及他們使用該系統(tǒng)可以做些什么。一個用例圖包含了多個模型元素，如系統(tǒng)、參與者和用例，并且顯示了這些元素之間的各種關(guān)系，如泛化、關(guān)聯(lián)和依賴。2、類圖類圖是描述系統(tǒng)中的類，以及各個類之間的關(guān)系的靜態(tài)視圖。能夠讓我們在正確編寫代碼以前對系統(tǒng)有一個全面的認識。類圖是一種模型類型，確切的說，是一種靜態(tài)模型類型。3、對象圖與類圖極為相似，它是類圖的實例，對象圖顯示類的多個對象實例，而不是實際的類。它描述的不是類之間的關(guān)系，而是對象之間的關(guān)系。4、活動圖描述用例要求所要進展的活動，以及活動間的約束關(guān)系，有利于識別并行活動。能夠演

13、示出系統(tǒng)中哪些地方存在功能，以及這些功能和系統(tǒng)中其他組件的功能如何共同滿足前面使用用例圖建模的商務(wù)需求。5、狀態(tài)圖描述類的對象所有可能的狀態(tài)，以及事件發(fā)生時狀態(tài)的轉(zhuǎn)移條件?？梢圆东@對象、子系統(tǒng)和系統(tǒng)的生命周期。他們可以告知一個對象可以擁有的狀態(tài)，并且事件(如消息的接收、時間的流逝、錯誤、條件變?yōu)檎娴?會怎么隨著時間的推移來影響這些狀態(tài)。一個狀態(tài)圖應(yīng)該連接到所有具有清晰的可標識狀態(tài)和復(fù)雜行為的類；該圖可以確定類的行為，以及該行為如何根據(jù)當前的狀態(tài)變化，也可以展示哪些事件將會改變類的對象的狀態(tài)。狀態(tài)圖是對類圖的補充。6、序列圖順序圖序列圖是用來顯示你的參與者如何以一系列順序的步驟與系統(tǒng)的對象交互的

14、模型。順序圖可以用來展示對象之間是如何進展交互的。順序圖將顯示的重點放在消息序列上，即強調(diào)消息是如何在對象之間被發(fā)送和接收的。7、協(xié)作圖和序列圖相似，顯示對象間的動態(tài)合作關(guān)系?？梢钥闯墒穷悎D和順序圖的交集，協(xié)作圖建模對象或者角色，以及它們彼此之間是如何通信的。如果強調(diào)時間和順序，則使用序列圖；如果強調(diào)上下級關(guān)系，則選擇協(xié)作圖；這兩種圖合稱為交互圖。8、構(gòu)件圖組件圖描述代碼構(gòu)件的物理構(gòu)造以及各種構(gòu)建之間的依賴關(guān)系。用來建模軟件的組件及其相互之間的關(guān)系，這些圖由構(gòu)件標記符和構(gòu)件之間的關(guān)系構(gòu)成。在組件圖中，構(gòu)件時軟件單個組成局部，它可以是一個文件，產(chǎn)品、可執(zhí)行文件和腳本等。9、部署圖配置圖是用來建模

15、系統(tǒng)的物理部署。例如計算機和設(shè)備，以及它們之間是如何連接的。部署圖的使用者是開發(fā)人員、系統(tǒng)集成人員和測試人員。以上圖形中由于類圖之間的關(guān)系相比照擬復(fù)雜，所以對于類圖之間的關(guān)系進展一個大致的講解。其關(guān)系種類有關(guān)聯(lián)、聚合、組合、泛化、依賴。1.泛化Generalization【泛化關(guān)系】：是一種繼承關(guān)系,表示一般與特殊的關(guān)系,它指定了子類如何特化父類的所有特征和行為.例如：老虎是動物的一種,即有老虎的特性也有動物的共性.【箭頭指向】：帶三角箭頭的實線，箭頭指向父類2.實現(xiàn)Realization【實現(xiàn)關(guān)系】：是一種類與接口的關(guān)系,表示類是接口所有特征和行為的實現(xiàn).【箭頭指向】：帶三角箭頭的虛線，箭頭

16、指向接口3.關(guān)聯(lián)Association)【關(guān)聯(lián)關(guān)系】：是一種擁有的關(guān)系,它使一個類知道另一個類的屬性和方法；如：教師與學(xué)生，丈夫與妻子關(guān)聯(lián)可以是雙向的，也可以是單向的。雙向的關(guān)聯(lián)可以有兩個箭頭或者沒有箭頭，單向的關(guān)聯(lián)有一個箭頭。【代碼表達】：成員變量【箭頭及指向】：帶普通箭頭或?qū)嵭娜切渭^的實心線，指向被擁有者上圖中，教師與學(xué)生是雙向關(guān)聯(lián)，教師有多名學(xué)生，學(xué)生也可能有多名教師。但學(xué)生與*課程間的關(guān)系為單向關(guān)聯(lián)，一名學(xué)生可能要上多門課程，課程是個抽象的東西他不擁有學(xué)生。4.聚合Aggregation【聚合關(guān)系】：是整體與局部的關(guān)系,且局部可以離開整體而單獨存在.如車和輪胎是整體和局部的關(guān)系,輪

17、胎離開車仍然可以存在.聚合關(guān)系是關(guān)聯(lián)關(guān)系的一種，是強的關(guān)聯(lián)關(guān)系；關(guān)聯(lián)和聚合在語法上無法區(qū)分，必須考察具體的邏輯關(guān)系?！敬a表達】：成員變量【箭頭及指向】：帶空心菱形的實心線，菱形指向整體5.組合(position)【組合關(guān)系】：是整體與局部的關(guān)系,但局部不能離開整體而單獨存在.如公司和部門是整體和局部的關(guān)系,沒有公司就不存在部門.組合關(guān)系是關(guān)聯(lián)關(guān)系的一種，是比聚合關(guān)系還要強的關(guān)系，它要求普通的聚合關(guān)系中代表整體的對象負責代表局部的對象的生命周期【代碼表達】：成員變量【箭頭及指向】：帶實心菱形的實線，菱形指向整體6.依賴(Dependency)【依賴關(guān)系】：是一種使用的關(guān)系,即一個類的實現(xiàn)需要另一個類的協(xié)助,所以要盡量不使用雙向的互相依賴.【代碼表現(xiàn)】：局部變量、方法的參數(shù)或者對靜態(tài)方法的調(diào)用【箭頭及指向】：帶箭頭的虛線，指向被使用者各種關(guān)系的強弱順序：泛化=實現(xiàn)組合聚合關(guān)聯(lián)依賴UML圖形實例由于開發(fā)的工程復(fù)雜程度不一，所以在真正的開發(fā)上以上九類圖形并不是都會用上，一般情況下使用頻率最高的就三種圖形：用例圖、類圖、時序圖。接下來實例也只列出此三種圖形實例1類圖：2.用例圖：.3.時序圖：UML建模工具Power