建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
本節(jié)向大家描述一下UML用例模型，主要包括UML用例模型與需求分析，如何建立UML用例模型，用例圖等內(nèi)容，希望本節(jié)的介紹對(duì)你的學(xué)習(xí)有所幫助。下面就是具體介紹。
創(chuàng)新互聯(lián)專(zhuān)注于企業(yè)營(yíng)銷(xiāo)型網(wǎng)站、網(wǎng)站重做改版、大城網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5響應(yīng)式網(wǎng)站、商城網(wǎng)站定制開(kāi)發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性?xún)r(jià)比高，為大城等各大城市提供網(wǎng)站開(kāi)發(fā)制作服務(wù)。
對(duì)UML用例模型及其應(yīng)用的一次有益的探討
前言：這是一次對(duì)用例模型的探討。怎樣建立用例模型，怎樣編寫(xiě)用例說(shuō)明，它與需求規(guī)格說(shuō)明書(shū)有什么區(qū)別，它能替代需求規(guī)格說(shuō)明書(shū)嗎？也許在這里可以找到你要的答案。
進(jìn)入軟件業(yè)稍微久一點(diǎn)兒的人恐怕都不會(huì)陌生，軟件開(kāi)發(fā)的最初階段都是談需求、寫(xiě)需求規(guī)格說(shuō)明書(shū)。需求規(guī)格說(shuō)明書(shū)是與客戶(hù)最終確認(rèn)到紙上的，非常正式的公文。軟件開(kāi)發(fā)應(yīng)當(dāng)做什么，做成什么樣子，什么東西不做，項(xiàng)目范圍有多寬，需求規(guī)格說(shuō)明書(shū)都是白紙黑字寫(xiě)得清清楚楚，誰(shuí)都無(wú)法抵賴(lài)。所以，需求規(guī)格說(shuō)明書(shū)一直都是軟件項(xiàng)目開(kāi)發(fā)合同的重要附件，地位相當(dāng)重要。
但是，隨著RUP的引入，人們開(kāi)始困惑了。在RUP中沒(méi)有需求規(guī)格說(shuō)明書(shū)，而是為用例模型所替代?，F(xiàn)在，一些信息化走在比較前列的公司，都紛紛要求按照RUP統(tǒng)一過(guò)程進(jìn)行開(kāi)發(fā)，我們也開(kāi)始嘗試使用用例模型來(lái)替代需求規(guī)格說(shuō)明書(shū)。然而，相信一些關(guān)于用例模型的幾個(gè)重要問(wèn)題一直困惑著不少人（當(dāng)然也包括我）：用例模型與需求規(guī)格說(shuō)明書(shū)的區(qū)別在哪里？用例模型的優(yōu)勢(shì)在哪里？用例模型能替代需求規(guī)格說(shuō)明書(shū)嗎？圍繞著這幾個(gè)問(wèn)題我們進(jìn)行一次用例模型的探討之旅吧。
在開(kāi)始我的探討之旅之前，我們***能帶上一個(gè)問(wèn)題去探討：
UML用例模型與需求規(guī)格說(shuō)明書(shū)的區(qū)別在哪里？
看到這個(gè)問(wèn)題，你也許會(huì)非常不屑一顧，認(rèn)為這個(gè)問(wèn)題不值一提。確實(shí)，在編寫(xiě)格式上，用例模型與需求規(guī)格說(shuō)明書(shū)的差別顯而易見(jiàn)。但是，從更深層次來(lái)討論，你會(huì)發(fā)現(xiàn)，這個(gè)問(wèn)題并不是那么簡(jiǎn)單。有些人由于對(duì)用例模型的膚淺認(rèn)識(shí)，將用例模型當(dāng)成需求規(guī)格說(shuō)明書(shū)來(lái)寫(xiě)，格式雖說(shuō)是用例模型的格式，內(nèi)容卻不是用例模型的內(nèi)容，換湯不換藥，反倒弄巧成拙，讓人困惑。需求規(guī)格說(shuō)明書(shū)是面向過(guò)程時(shí)代的產(chǎn)物，因此它的核心就是按照面向過(guò)程的設(shè)計(jì)思想編寫(xiě)需求；用例模型是面向?qū)ο蠓治?設(shè)計(jì)的產(chǎn)物，因此它的核心思想就是OOA/D（面向?qū)ο蠓治?設(shè)計(jì)）。我認(rèn)為，把握這一點(diǎn)實(shí)在太重要了。明白了它，才能明白用例模型應(yīng)當(dāng)怎樣設(shè)計(jì)，才能明白它與需求規(guī)格說(shuō)明書(shū)的區(qū)別，才能明白其作用和優(yōu)勢(shì)在何處。下面，我們看看用例模型應(yīng)當(dāng)怎么設(shè)計(jì)。
如何建立UML用例模型
一些初學(xué)者認(rèn)為，用例模型就是畫(huà)張用例圖。其實(shí)這是錯(cuò)誤的，用例模型包括用例圖、用例說(shuō)明，有時(shí)還要輔之一些簡(jiǎn)單的行動(dòng)圖、狀態(tài)圖和序列圖。用例圖采用圖形的方式，形象生動(dòng)地展現(xiàn)了用例、參與者和系統(tǒng)邊界之間的關(guān)系。而用例說(shuō)明，是對(duì)用例、參與者和系統(tǒng)邊界進(jìn)行的詳細(xì)描述。在描述過(guò)程中，還可以對(duì)一些關(guān)鍵的流程，以及這些流程中關(guān)鍵類(lèi)的狀態(tài)變化，使用行動(dòng)圖、狀態(tài)圖和序列圖進(jìn)行圖形化地展現(xiàn)。
UML用例圖
用例圖是建立UML用例模型的開(kāi)始。用例模型的建立過(guò)程通常都是：先畫(huà)用例圖，然后對(duì)用例圖編寫(xiě)用例說(shuō)明。在編寫(xiě)用例說(shuō)明的時(shí)候，對(duì)一些復(fù)雜的、認(rèn)為有必要的地方，繪制行動(dòng)圖、狀態(tài)圖和序列圖，方便閱讀者理解。用例圖關(guān)注的是三部分內(nèi)容：用例、參與者和系統(tǒng)邊界。
1.用例
用例就是一個(gè)用來(lái)描述參與者如何使用系統(tǒng)來(lái)實(shí)現(xiàn)其目標(biāo)的一組場(chǎng)景的集合。這句話(huà)聽(tīng)起來(lái)比較抽象，但我通常都把它暫時(shí)理解為功能中的模塊（雖然這并不嚴(yán)密，但更加實(shí)用）。用例強(qiáng)調(diào)的是一組場(chǎng)景，在這組場(chǎng)景不多但相互之間存在功能上的共性，就像一個(gè)大功能模塊下的多個(gè)子模塊。這組場(chǎng)景中的每一個(gè)，又分別形成一個(gè)個(gè)子用例。子用例再細(xì)分，又可以再形成各自的子用例。用例分析就是這樣由粗到細(xì)的逐步細(xì)分，從而形成一系統(tǒng)的用例圖。用例圖分析到多細(xì)，應(yīng)當(dāng)由業(yè)務(wù)需求的情況決定。分得過(guò)粗，就不足以說(shuō)清楚業(yè)務(wù)的相關(guān)細(xì)節(jié)，或者使一張用例圖信息過(guò)多，影響人們的理解；分得過(guò)細(xì)，不僅會(huì)增加工作量，還會(huì)丟失許多用例間的相互關(guān)系，得不償失?？傊^為復(fù)雜的部分細(xì)一些，簡(jiǎn)單的部分粗一些，保證每個(gè)用例圖都保持強(qiáng)烈的相關(guān)性，指導(dǎo)日后的功能劃分。
同時(shí)，用例強(qiáng)調(diào)的是參與者與系統(tǒng)功能的交互，用例就是系統(tǒng)的功能，而參與者可以暫時(shí)理解為使用系統(tǒng)的人。因此，大多數(shù)用例都對(duì)應(yīng)著一個(gè)或數(shù)個(gè)參與者（但部分從用例中包含著的子用例，或擴(kuò)展出來(lái)的擴(kuò)展用例沒(méi)有參與者）。
用例與用例之間通常有兩種關(guān)系：包含與擴(kuò)展。包含關(guān)系表示一種從屬關(guān)系，即子用例是主用例中相對(duì)獨(dú)立的、必須調(diào)用的一部分功能。在用例分析中，我們應(yīng)當(dāng)將多個(gè)用例都共有的、相對(duì)獨(dú)立的功能提取出來(lái)形成一個(gè)子用例，為日后代碼復(fù)用提供有力保障。擴(kuò)展關(guān)系表示一個(gè)功能是對(duì)另一個(gè)功能的擴(kuò)展，即被擴(kuò)展功能不一定調(diào)用擴(kuò)展功能，但擴(kuò)展功能是對(duì)被擴(kuò)展功能的加強(qiáng)與延伸。在繪制用例關(guān)系時(shí)，包含關(guān)系應(yīng)繪制成從主用例指向子用例的虛線(xiàn)箭頭，并標(biāo)注為“include”，表示主用例包含子用例；擴(kuò)展關(guān)系應(yīng)繪制成從擴(kuò)展用例指向被擴(kuò)展用例的虛線(xiàn)箭頭，并標(biāo)注為“extend”，表示擴(kuò)展用例是對(duì)被擴(kuò)展用例的擴(kuò)展。虛線(xiàn)箭頭在UML中代表的是一種依賴(lài)關(guān)系，即客戶(hù)元素了解供應(yīng)者，并且供應(yīng)者的變化會(huì)影響到客戶(hù)元素（依賴(lài)是從客戶(hù)元素指向供應(yīng)者的）。
封裝性是面向?qū)ο笤O(shè)計(jì)的重要思想之一。而實(shí)現(xiàn)封裝的前提之一，就是要對(duì)需求進(jìn)行整理的基礎(chǔ)上加以功能劃分，使具有強(qiáng)烈相關(guān)性的功能劃分在一起，只有少量接口與外界交互。用例分析，從一開(kāi)始就對(duì)原始需求進(jìn)行了功能劃分，將相關(guān)功能劃分到一起，將共有功能提取出來(lái)，標(biāo)志出功能間的依賴(lài)與非依賴(lài)關(guān)系（包含表示的是一種依賴(lài)關(guān)系，而擴(kuò)展表示的是一種非依賴(lài)關(guān)系）。這是一種OOA/D，它為日后的OO設(shè)計(jì)提供了強(qiáng)有力地支持。而這些都是需求規(guī)格說(shuō)明書(shū)所不具有，或者不完全具體的功能。
2.參與者
現(xiàn)在再來(lái)說(shuō)說(shuō)UML用例模型中的參與者。參與者給大家最直觀的認(rèn)識(shí)就是操作系統(tǒng)的那些人，但更準(zhǔn)確的說(shuō)應(yīng)當(dāng)是操作系統(tǒng)的那些角色。用例模型要求我們描述清楚系統(tǒng)中的每一個(gè)場(chǎng)景的每一步操作，操作者是誰(shuí)。同時(shí)，我們關(guān)注的這個(gè)操作者并不是某個(gè)具體的人，而是一群有著相同職責(zé)的人，即角色。用例模型中對(duì)參與者的分析，為我們之后在開(kāi)發(fā)過(guò)程中，進(jìn)行功能、角色、用戶(hù)的劃分提供了依據(jù)。
用例模型中的參與者，除了表示操作系統(tǒng)的人，還表示處于系統(tǒng)邊界之外，與系統(tǒng)邊界內(nèi)的用例有關(guān)聯(lián)的其它系統(tǒng)。因此，只有定義好一個(gè)系統(tǒng)的邊界，才能定義哪些是這個(gè)系統(tǒng)內(nèi)的用例，哪些是這個(gè)系統(tǒng)內(nèi)外的參與者。用例模型對(duì)本系統(tǒng)與其它系統(tǒng)相互關(guān)聯(lián)的分析，為我們?nèi)蘸箝_(kāi)發(fā)過(guò)程中，為其它系統(tǒng)提供接口，或與其它系統(tǒng)進(jìn)行接口，提供了依據(jù)。
參與者之間的關(guān)系只有一種——繼承關(guān)系，表示功能職責(zé)上的繼承。譬如，通常軟件系統(tǒng)中都有“普通操作者”，代表的是進(jìn)入系統(tǒng)的所有用戶(hù)都應(yīng)當(dāng)具有的功能。而軟件系統(tǒng)又有很多“特殊職能者”，他們除了具有普通操作者的功能外，還有自己獨(dú)特的功能。在這里，“特殊職能者”是對(duì)“普通操作者”的繼承，繼承了“普通操作者”的所有功能。然而，“特殊職能者”又有“普通操作者”不具備的，自己獨(dú)特的功能。
參與者與用例之間是一種關(guān)聯(lián)關(guān)系，即實(shí)線(xiàn)表示。通常，參與者與用例之間的關(guān)系不用定義導(dǎo)航關(guān)系（即畫(huà)出箭頭），但部分UML的書(shū)籍也定義了這種導(dǎo)航關(guān)系。如果參與者要使用用例，則箭頭從參與者指向用例；如果參與者要接受用例提供的數(shù)據(jù)或查詢(xún)結(jié)果，則箭頭從用例指向參與者。
用例分析將參與者放到了一個(gè)十分顯著的位置，同時(shí)還關(guān)注的參與者的期望（即“涉眾利益”，在后面詳細(xì)描述），這也是需求規(guī)格說(shuō)明書(shū)所不具有的。
3.系統(tǒng)邊界
UML用例模型中系統(tǒng)邊界是一個(gè)軟件系統(tǒng)需要處理的整個(gè)問(wèn)題空間的范圍。一個(gè)軟件系統(tǒng)不可能處理所有問(wèn)題，我們必須得給它定義這個(gè)問(wèn)題空間的范圍。哪些是我們這個(gè)軟件可以處理的，哪些則是我們這個(gè)軟件不能處理的，也就是項(xiàng)目管理中所說(shuō)的項(xiàng)目范圍。與需求規(guī)格說(shuō)明書(shū)相比，用例分析通過(guò)圖形的方式，更加明確地定義出了項(xiàng)目范圍，以及與其它系統(tǒng)之間的關(guān)系，使其更加清楚明了。
網(wǎng)頁(yè)名稱(chēng)：UML用例模型及其應(yīng)用解析
文章來(lái)源：http://www.5511xx.com/article/cdcjdpd.html
