06 用例模型修訂

軟件工程素質(zhì)導(dǎo)論第6章用例模型第6章第頁學(xué)習(xí)目標(biāo)了解UML中的基本圖形元素了解UML中的基本圖形元素掌握用例圖的概念及基本元素學(xué)會建立用例模型掌握用例描述學(xué)會使用StarUml繪制用例圖什么是模型？模型是一組具有完整語義的信息，它是對現(xiàn)實世界的簡化，也是對認知主體的抽象，建模過程就是認識世界、捕捉認知對象本質(zhì)的過程。拓展思維：在周圍環(huán)境中，哪些地方用到了模型的思想？面向?qū)ο?ObjectOriented,OO)是當(dāng)前計算機界關(guān)心的重點。面向?qū)ο蠼Ｊ擒浖こ處煂ο到y(tǒng)相關(guān)的問題域的建模和求解域的建模。注釋：什么是問題域？什么是求解域？問題域是軟件工程師需要理解系統(tǒng)運行的環(huán)境，需要了解與系統(tǒng)相關(guān)的問題。例如：對于一個火車交通控制系統(tǒng)來說，軟件工程師需要知道火車信號化的程序；對于一個股票交易系統(tǒng)，軟件工程師需要知道交易規(guī)則，但軟件工程師不需要成為一個完全通過認證的火車調(diào)度員或股票經(jīng)紀人。他們僅僅需要的是了解與該系統(tǒng)相關(guān)的問題概念，換句話說，他們需要構(gòu)造一個問題域的模型。求解域是軟件工程師需要構(gòu)建一個求解域，以幫助理解構(gòu)建的系統(tǒng)、評估不同的解決方案并進行權(quán)衡。同時因為大多數(shù)系統(tǒng)是非常復(fù)雜的，任何個人都沒有足夠的精力能完全理解，而且這樣的系統(tǒng)構(gòu)建起來也是非常昂貴的。為了克服這些挑戰(zhàn)，軟件工程師就需要構(gòu)建求解域。問題域首先被建模為一組對象和關(guān)系，然后，系統(tǒng)用這個模型來表達它操縱現(xiàn)實世界的概念。例如一個火車交通控制系統(tǒng)包括火車對象，表示它監(jiān)視的火車。一個股票交易系統(tǒng)包括交易對象，用來表示股票的買進和賣出。然后，求解域的概念也被建模為對象。UML，稱為統(tǒng)一建模語言（UnifiedModelingLanguage），是目前面向?qū)ο髮ΜF(xiàn)實世界建模的統(tǒng)一標(biāo)準(zhǔn)之一，它提供了一種可視化的建模語言，采用一組具有明確語義的圖形符號，建立清晰的模型便于用戶和軟件開發(fā)者之間的交流。它用模型來描述軟件系統(tǒng)的靜態(tài)特征和動態(tài)特征。針對UnifiedModelingLanguage，可作如下理解：Unified：組合了當(dāng)前最好的面向?qū)ο筌浖７椒ǎ℅radyBooch的TheBoochMethod，JamesRumbaugh的OMT，IvarJacobson的OOSE等；Modeling：用于表達現(xiàn)實的簡化視圖，以便于面向?qū)ο筌浖到y(tǒng)的設(shè)計與實現(xiàn)。Language：UML主要是遵循精確語法的圖形語言。UML的目標(biāo)是用面向?qū)ο蟮姆绞矫枋鋈魏晤愋偷南到y(tǒng)，最直接的是用UML為軟件系統(tǒng)創(chuàng)建模型。用例模型是UML中從用戶的觀點對軟件系統(tǒng)行為的一個建模，定義了系統(tǒng)做什么，即以系統(tǒng)功能為目標(biāo)，從系統(tǒng)使用者的角度來描述系統(tǒng)操作的過程。6.1UML簡介UML是一種建模語言，是用來為面向?qū)ο箝_發(fā)系統(tǒng)的產(chǎn)品進行說明可視化和編制文檔的方法。它是由信息系統(tǒng)（IS，InformationSystem）和面向?qū)ο箢I(lǐng)域的三位著名的方法學(xué)家GradyBooch，JamesRumbaugh和IvarJacobson（稱為“三個好朋友”，theThreeAmigos）提出的。這種建模語言得到了UML伙伴聯(lián)盟的應(yīng)用與反饋，并得到了工業(yè)界的廣泛支持，由OMG組織（ObjectMangementGroup）采納作為業(yè)界標(biāo)準(zhǔn)。UML是一種定義良好、易于表達、功能強大的用于對軟件密集型系統(tǒng)建模的圖形語言。它支持從需求分析開始的面向?qū)ο筌浖_發(fā)的全過程。UML作為一種建模語言，它使軟件開發(fā)人員專注于建立系統(tǒng)的模型和結(jié)構(gòu)，而不是選用具體的程序設(shè)計語言和算法來實現(xiàn)。當(dāng)模型建立之后，模型可以被UML工具轉(zhuǎn)化成指定的程序設(shè)計語言代碼和數(shù)據(jù)庫結(jié)構(gòu)。拓展閱讀：1997年，作為Booch、OOSE和OMT方法的主要作者，GradyBooch、IvarJacobson和JamesRumbaugh一起工作，創(chuàng)立了UML（統(tǒng)一建模語言）0.9版本。Grady（IBMfellow）因其在軟件架構(gòu)、軟件工程和軟件建模方面的杰出貢獻而在國際上享有盛名。自Rational于1981年創(chuàng)建以來，他就一直擔(dān)任IBMRational的首席科學(xué)家。Grady于2003年3月榮獲IBM名士（IBMfellow）的稱號。IvarJacobson博士是Objectory方法的發(fā)明者，也是瑞典ObjectoryAB公司的創(chuàng)始人。Jacobson博士是兩本影響深遠的暢銷書的主要作者：《面向?qū)ο蟮能浖こ台D一種用例驅(qū)動方法》（1992年計算機語言生產(chǎn)力獎獲得者）和《對象的優(yōu)勢―采用對象技術(shù)的業(yè)務(wù)過程再工程》。Rumbaugh博士是享譽全球的軟件開發(fā)方法學(xué)家。Jim一直是引導(dǎo)UML未來開發(fā)的領(lǐng)袖，他提出了許多有關(guān)UML的概念。他與Rational的其他軟件領(lǐng)袖一起工作在各個領(lǐng)域，比如Rational統(tǒng)一過程和實時開發(fā)方法學(xué)。自從2003年IBM收購了Rational之后，Jim就一直致力于推動IBM建模工具的開發(fā)。GradyBoochIvarJacobsonRumbaugh6.1.1UML語言特點標(biāo)準(zhǔn)建模語言UML的出現(xiàn)，是面向?qū)ο筌浖こ?0世紀90年代中期所取得的最重要的成果。其主要特點可以歸結(jié)為以下三點：1．統(tǒng)一標(biāo)準(zhǔn)UML不僅統(tǒng)一了Booch、OMT和OOSE等方法中的基本概念，還吸取了面向?qū)ο蠹夹g(shù)領(lǐng)域中其他流派的長處，其中也包括非OO方法的影響。UML使用的符號考慮了各種方法的圖形表示，刪掉了大量易引起混亂的、多余的和極少使用的符號，也添加了一些新符號，提供了標(biāo)準(zhǔn)的面向?qū)ο蟮哪Ｐ驮氐亩x和表示法，并已經(jīng)成為OMG的標(biāo)準(zhǔn)。2．面向?qū)ο骍ML支持面向?qū)ο蟮闹饕拍?，包括類、對象、消息等，它提供了一批基本的表示模型元素的圖形和方法，能簡潔明了地表達面向?qū)ο蟮母鞣N概念和模型元素。3．表達能力強大、可視化UML是一種圖形化語言，用UML的模型圖形能清晰地表示系統(tǒng)的邏輯模型或?qū)崿F(xiàn)模型。它不只是一堆圖形符號，在每一個圖形表示符號后面，都有良好定義的語義；UML還提供了語言的擴展機制，用戶可以根據(jù)需要增加定義自己的構(gòu)造型、標(biāo)記值和約束等，它的強大表達能力使它可以用于各種復(fù)雜類型的軟件系統(tǒng)的建模。但是UML并不是萬能的，正如M.Fowler指出的，UML是一種建模語言而不是一種方法。它不包含任何過程指導(dǎo)。就是說，它并不講述如何運用面向?qū)ο蟮母拍钆c原則去進行建模，而只是定義了用于建模的各種元素，以及由這些元素所構(gòu)成的各種圖的構(gòu)成規(guī)則。在文學(xué)領(lǐng)域，一本詞典加一本語法手冊，并不能構(gòu)成一種文學(xué)理論或創(chuàng)作方法，也不能使學(xué)習(xí)者學(xué)會如何進行文學(xué)創(chuàng)作。同樣，在軟件領(lǐng)域，僅有一種建模語言不能算作是一種建模方法，也不能為工程技術(shù)人員提供一套可遵循的開發(fā)準(zhǔn)則。6.1.2UML中的基本圖形元素在UML中定義了兩類模型元素。一類模型元素稱為是事物，包括結(jié)構(gòu)事物、動作事物、分組事物和注釋事物，主要用于表示模型中的某個概念，如類、對象、構(gòu)件、用例、結(jié)點、接口、包和注釋等；另一類稱為是關(guān)系，用于表示模型元素之間相互連接的關(guān)系，其中主要有關(guān)聯(lián)、泛化、依賴和聚集等。這兩類模型元素均可用圖形符號來表示。1．結(jié)構(gòu)事物 結(jié)構(gòu)事物共有7種：類、接口、協(xié)作、用例、活動類、組件和節(jié)點。（1）類：是對具有相同屬性、方法、關(guān)系和語義的對象的抽象，一個類可以實現(xiàn)一個或多個接口。在UML中類用包括類名、屬性和方法的矩形表示。（2）接口：是為類或組件提供特定服務(wù)的一組操作的集合。接口描述了類或組件的對外可見的動作。在UML中接口用圓表示，在圖形旁邊還要標(biāo)注接口的名字。（3）協(xié)作：定義了交互操作。在UML中，用虛線構(gòu)成的橢圓表示，橢圓中要標(biāo)注協(xié)作的名字。（4）用例：描述系統(tǒng)對一個特定角色執(zhí)行的一系列動作。在UML中，用例用標(biāo)注了用例名稱的實線橢圓表示，如下圖所示。（5）活動類：是類對象有一個或多個進程或線程的類，在UML中，活動類和類的表示法相同，只是邊框用粗線條。（6）組件：是實現(xiàn)了一個接口集合的物理上可替換的系統(tǒng)部分。（7）節(jié)點：是在運行時存在的一個物理元素。它代表一個可計算的資源，通常占用一些內(nèi)存和具有處理能力。一個組件集合一般來說位于一個節(jié)點。動作事物動作事物是UML模型中的動態(tài)部分,代表時間和空間上的動作。交互和狀態(tài)機是UML中最基本的兩個動態(tài)事物元素。（1）交互：是一組對象在特定上下文中，為達到某種特定的目的而進行的一系列消息交換組成的動作。在UML中用帶箭頭的直線來表示。（2）狀態(tài)機：由一系列對象的狀態(tài)組成。3．分組事物分組事物是UML模型中組織的部分，分組事物只有一種，稱為包。包是一種有組織地將一系列元素分組的機制。4．注釋事物注釋事物是UML模型的解釋部分。5．以下是幾種連接關(guān)系的含義（1）關(guān)聯(lián)：連接模型元素及鏈接實例；例如教師和學(xué)生之間的關(guān)系。（2）泛化：表示一般與特殊的關(guān)系，即“一般”元素是“特殊”元素的泛化，“特殊”元素是“一般”元素的特化，例如：（3）依賴：表示一個元素以某種方式依賴于另一個元素；假設(shè)有兩個元素X，Y，如果修改元素X的定義可能會引起對另一個元素Y的定義的修改，則稱元素Y依賴于元素X。（4）聚集：表示整體與部分的關(guān)系，即“部分”元素是“整體”元素的一部分。思考：（1）在上面的圖中，“車”，“教師”，“顯示器”等事物屬于UML中的哪一個概念？（2）“人”，“男人”，“女人”之間是UML中的什么關(guān)系？（3）觀察周圍的事物，舉出“聚合”，“泛化”關(guān)系的實例。6.1.3UML組織結(jié)構(gòu)UML是用來描述模型的，它用模型來描述系統(tǒng)的結(jié)構(gòu)（靜態(tài)特征）和行為（動態(tài)特征）。它從不同的視角為系統(tǒng)建模，形成不同的視圖（View），每個視圖代表完整系統(tǒng)描述中的一個抽象，顯示這個系統(tǒng)中的一個特定的方面；每個視圖有一組圖構(gòu)成，圖中包含了強調(diào)系統(tǒng)中某一方面的信息。UML包括兩類圖和五種視圖。1．圖圖是系統(tǒng)架構(gòu)在某個側(cè)面的表示，UML提供了兩大類——靜態(tài)圖和動態(tài)圖，共計9種不同的圖。靜態(tài)圖（StaticDiagram）包括用例圖、類圖、對象圖、構(gòu)建圖、部署圖。其中用例圖描述系統(tǒng)的功能；類圖描述系統(tǒng)的靜態(tài)結(jié)構(gòu)；對象圖描述系統(tǒng)在某個時刻的靜態(tài)結(jié)構(gòu)；構(gòu)件圖描述實現(xiàn)系統(tǒng)的元素的組織；部署圖描述系統(tǒng)環(huán)境元素的配置。動態(tài)圖（DynamicDiagram）包括狀態(tài)圖、時序圖、協(xié)作圖和活動圖。其中狀態(tài)圖描述系統(tǒng)元素的狀態(tài)條件和響應(yīng)；時序圖按時間順序描述系統(tǒng)元素間的交互；協(xié)作圖按照時間和空間的順序描述系統(tǒng)元素間的交互和關(guān)系；活動圖描述系統(tǒng)元素的活動。其中活動圖是由JameOdell提出，狀態(tài)圖由DavidHarel提出。2．視圖用例視圖表達從用戶角度看到的系統(tǒng)應(yīng)有的外部功能，有時也叫用戶模型視圖；用用例圖來描述。設(shè)計視圖描述系統(tǒng)設(shè)計特征，包括結(jié)構(gòu)模型視圖和行為模型視圖，前者描述系統(tǒng)的靜態(tài)結(jié)構(gòu)(類圖、對象圖)，后者描述系統(tǒng)的動態(tài)行為(交互圖、狀態(tài)圖、活動圖)。部署視圖描述系統(tǒng)的物理配置特征，用部署圖表示。實現(xiàn)視圖表示系統(tǒng)的實現(xiàn)特征，常用構(gòu)件圖表示。進程視圖表示系統(tǒng)內(nèi)部的控制機制。常用類圖描述過程結(jié)構(gòu)，用交互圖描述過程行為。UML的五種視圖思考：不會編程可以學(xué)習(xí)UML嗎？注解：可以，為什么不可以呢？只要你清楚下面這一點，對于不懂編程的你，只要你不試圖很快地直接用UML寫出可執(zhí)行的軟件程序，你就可以立即去學(xué)習(xí)UML。據(jù)說某些高手可以通過RationalRose這樣的工具用UML建模，然后直接生成項目50%以上的程序代碼。我相信這是真的，但對于不懂編程的你，暫時是再努力也做不到這樣的。UML是一種建模語言，除了上面這個作用外，其他用處還多得很，只要你不是為了這個而學(xué)習(xí)UML，你就可以放心大膽地去學(xué)，學(xué)習(xí)UML對編程知識沒有什么依賴，相反，某些根深蒂固的編程想法，有時候倒是會誤導(dǎo)很多人做出晦澀難懂的模型。如果你的目標(biāo)是成為系統(tǒng)分析員，設(shè)計師或方案工程師、業(yè)務(wù)咨詢師、流程師、管理大師等，你渴望把你在某個業(yè)務(wù)領(lǐng)域的經(jīng)驗和知識借助模型表達出來，那么，你就是非常適合學(xué)習(xí)UML的人選，如果你的目標(biāo)就是成為程序員或成為優(yōu)秀的軟件分析師、設(shè)計師，那么，你免不了遲早要精通至少一門編程語言，而且要參與三個以上的有一定份量的軟件項目的開發(fā)工作。即使這樣，學(xué)習(xí)編程語言和學(xué)習(xí)UML也并不需要有先后之分。你仍然可以立即開始學(xué)習(xí)UML，而且，學(xué)會了UML建模，對你往后學(xué)習(xí)具體的編程語言一定會是有幫助的。6.2需求分析與用例模型在日常生活中，你可能會說“我要吃蛋炒飯！”，會想“我需要什么樣的女朋友？”等等諸如此類的問題，它們都體現(xiàn)人們對周圍環(huán)境或者對自己的需求，電影《其實你不懂他的心》也是以此為題材編寫的一部經(jīng)典影片，受到了很多人們的喜歡。電影《其實你不懂他的心》(He'sJustNotThatIntoYou)總之，需求是人們對某項事物在特定時間內(nèi)的一個想法或者一個要求。但這種需求往往是多方面的、不確定的，即需求具有多變性。1915年，Rubin展示了與左圖相似的一幅圖畫，說明了多穩(wěn)定圖像的概念。你看見了什么？兩張對看的人臉？如果你更多關(guān)注白色區(qū)域，實際上你會看到一個花瓶。一旦你能分別插接到這兩個圖像，就比較容易在花瓶和人臉之間前后切換了。如果上圖有一個系統(tǒng)需求說明，那么你會構(gòu)建哪一個模型呢？由于自然語言固有的不準(zhǔn)確性以及需求說明者自作的假設(shè)，這個系統(tǒng)需求說明就與多穩(wěn)定圖像一樣，含有二義性；即不確定。軟件系統(tǒng)的需求是指用戶對軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達到什么性能。同樣，軟件系統(tǒng)的需求也是不確定的，需要軟件分析師和用戶溝通，去分析和引導(dǎo)客戶將心里模糊的需求以精確的方式描述并展示出來。這個過程就是需求分析。需求分析就是提供一種與客戶在系統(tǒng)功能方面進行溝通并達成共識的方式，使開發(fā)者能夠更準(zhǔn)確的理解系統(tǒng)的需求；是把客戶的功能描述轉(zhuǎn)化為軟件人員所能理解的功能描述，并在客戶描述的基礎(chǔ)上去除不合理的地方，補充系統(tǒng)缺失的地方，最后為系統(tǒng)的概要設(shè)計，詳細設(shè)計提供準(zhǔn)確，有效的數(shù)據(jù)基礎(chǔ)。需求分析在軟件開發(fā)過程中是非常重要的，如果需求獲取不正確或在需求開發(fā)過程中很多功能沒有挖掘出來，那么在后期選擇彌補時，將會造成項目延期以及成本大幅度增加的嚴重后果。例1：軟件開發(fā)者沒有正確理解客戶的要求。例2：需求沒有滿足完備性和一致性，就開始了設(shè)計。需求分析是為軟件的最終用戶所看到的系統(tǒng)建立一個模型，是對需求抽象的描述。用例模型是采用面向?qū)ο蟮乃枷?，是需求分析模型的表現(xiàn)形式之一，主要用于表現(xiàn)系統(tǒng)的功能性需求；是以一種更直觀的方式來表現(xiàn)用戶對軟件系統(tǒng)的要求。即客戶通過用例模型來驗證系統(tǒng)在完成之后是否能夠滿足自己的期望，開發(fā)者通過用例模型來保證自己正在開發(fā)的系統(tǒng)是客戶所期望的，以保證用戶和軟件開發(fā)者對問題理解的完備一致。6.3用例模型用例模型使用用例描述了系統(tǒng)的功能需求，模型化表示了系統(tǒng)的功能和系統(tǒng)的環(huán)境。用例模型為客戶和開發(fā)者提供了一種契約。當(dāng)客戶同意了用例模型，客戶希望得到的系統(tǒng)功能也就確定了。在軟件開發(fā)過程中，用例模型可以作為一種方式用來與系統(tǒng)的客戶進行交流。用例模型的作用有（摘于IBM教材《使用UML進行面向?qū)ο蠓治雠c設(shè)計》）：（1）在系統(tǒng)開發(fā)的早期就可以明確最后提交的產(chǎn)品功能和特性；（2）確保雙方都對需求有了準(zhǔn)確的理解標(biāo)識（系統(tǒng)的用戶群和系統(tǒng)的功能）；（3）確定對系統(tǒng)與用戶群之間接口的需求驗證（是否客戶所有的需求都被捕獲）；（4）確保開發(fā)團隊已完全理解了客戶的需求。用例模型是使用用例的方法來描述系統(tǒng)功能需求的過程。它主要包括兩部分內(nèi)容：用例圖和用例描述。6.3.1用例圖用例圖(Usecasediagram)從用戶角度描述系統(tǒng)功能,并指出各功能的操作者。在用例圖中的核心概念有角色和用例。拓展閱讀：用例圖的多種認識用例圖用于描述系統(tǒng)應(yīng)該具有的功能集，它是從系統(tǒng)的外部用戶角度出發(fā)對系統(tǒng)的抽象表示。用例圖所描述的系統(tǒng)功能依靠于外部用戶或另一個系統(tǒng)觸發(fā)激活，為用戶或另一個系統(tǒng)提供服務(wù)，實現(xiàn)用戶或另一個系統(tǒng)與系統(tǒng)的交互，系統(tǒng)實現(xiàn)的最終目標(biāo)是提供用例視圖中描述的功能。用例圖是UML其他視圖的核心和基礎(chǔ)，其他圖的構(gòu)造和發(fā)展依賴于用例圖中所描述的內(nèi)容。因為系統(tǒng)的最終目標(biāo)是提供用例圖中描述的功能，同時附帶一些非功能性的性質(zhì)，因此用例圖影響著所有其他的圖。用例圖還可用于測試系統(tǒng)是否滿足用戶的需求和驗證系統(tǒng)的有效性。用例圖主要為用戶設(shè)計人員、開發(fā)人員和測試人員而設(shè)置，用例圖靜態(tài)地描述系統(tǒng)功能，為了動態(tài)地觀察系統(tǒng)功能偶爾也用活動圖activitydiagram描述。（1）角色（Actor），又稱為參與者，是指系統(tǒng)的用戶在與系統(tǒng)按照用例的描述進行交互時所扮演的一系列相關(guān)的角色。典型地，一個角色可以是一個人，一部硬件或者與系統(tǒng)進行交互的其他系統(tǒng)。角色是一個群體概念，代表的是一類能使用某個功能的人或事，角色不是指某個個體。比如在自動售貨系統(tǒng)中系統(tǒng)有售貨、供貨、提取銷售款等功能，啟動售貨功能的是人，那么人就是角色，如果再把人具體化，則該人可以是張三（張三買礦泉水），也可以是李四（李四買可樂），但是張三和李四這些具體的個體對象不能稱作角色。事實上，一個具體的人（比如張三）在系統(tǒng)中可以具有多種不同的角色。比如上述的自動售貨系統(tǒng)中，張三既可以為售貨機添加新物品（執(zhí)行供貨），也可以將售貨機中的錢取走（執(zhí)行提取銷售款）。通常系統(tǒng)會對角色的行為有所約束，使其不能隨便執(zhí)行某些功能。比如可以約束供貨的人不能同時又是提取銷售款的人，以免有舞弊行為。角色都有名字，它的名字反映了該角色的身份和行為（比如顧客），注意不能將角色的名字表示成角色的某個實例（比如張三），也不能表示成角色所需完成的功能（比如售貨）。例1：“我的一個朋友結(jié)婚了”，在這個事實描述里，你會想到哪些人或事呢？答案是：月老，新娘，新郎，親朋好友，玫瑰花。這些就是這個事實中的人或事，也可以稱為是這個事實描述里面存在的角色。例2：“Jack要給家里舉辦一個舞會，他會邀請哪些人呢？Jack想了一會，給他的妻子說，“我準(zhǔn)備邀請的人有：親密的同事，要好的朋友，幫忙的鄰居”。那么在這次舞會里，又會有哪些人呢？這些人對于舞會的貢獻是什么呢？在這個場景中，會有哪些角色呢？分析：參加舞會的人有：參加舞會的人對舞會的貢獻Jack舞會籌備者、舞會參加者Jack的妻子舞會籌備者、舞會參加者同事舞會參加者朋友舞會參加者鄰居舞會參加者角色應(yīng)該從與此事件交互過程中所表現(xiàn)的作用或者貢獻來確定。在這個場景中，存在的角色有:而對于Jack、某同事或者某鄰居等都只能稱為是角色的一個個體，是角色的實例化。（2）用例（UseCase）是系統(tǒng)對角色的交互進行響應(yīng)，并產(chǎn)生一個可見的結(jié)果時所進行的一系列動作。用例描述了系統(tǒng)的功能，并且不涉及到系統(tǒng)的實現(xiàn)。用例的圖型表示為：這里要特別強調(diào)的是，用例是經(jīng)過一系列的動作所產(chǎn)生的結(jié)果。拓展閱讀：用例（usecase）這個概念是IvarJacobson于20世紀60～70年代在愛立信公司開發(fā)AKE、AXE系列系統(tǒng)時發(fā)明的，并在其博士論文《Conceptsformodelinglargerealtimesystems》(1985年)和1992年出版的論著《Object-orientedsoftwareengineering:ausecasedrivenapproach》中做了詳細論述。自從Jacobson提出用例概念后，面向?qū)ο箢I(lǐng)域已經(jīng)廣泛采納了這一概念，并認為它是第二代面向?qū)ο蠹夹g(shù)的標(biāo)志。針對用例還有如下解釋：用例定義1：用例是對一個參與者（Actor）使用系統(tǒng)的某一項功能時所進行的交互過程的一個文字描述序列。用例定義2：用例是系統(tǒng)、子系統(tǒng)或類和外部的參與者（Actor）交互的動作序列的說明，包括可選的動作序列和會出現(xiàn)異常的動作序列。用例從使用系統(tǒng)的角度描述系統(tǒng)的信息，即站在系統(tǒng)外部查看系統(tǒng)功能，而不是考慮系統(tǒng)內(nèi)部對該功能的實現(xiàn)。用例可以清楚描述了用戶提出的可見需求，每個用例對應(yīng)一個具體的用戶目標(biāo)，使用用例可以促進與用戶溝通，理解正確的需求，同時可以劃分系統(tǒng)與外部對象的界限。用例是代表系統(tǒng)中各項目相關(guān)人員之間就系統(tǒng)的行為達成的契約。用例分析的結(jié)果可以為預(yù)測系統(tǒng)的開發(fā)時間和預(yù)算提供依據(jù)，保證項目的順利進行，因此用例可以驅(qū)動軟件開發(fā)過程。我們可以把所有的用戶需求都用用例來表示，因此用例可以表達用戶對產(chǎn)品功能的期望，表達客戶的需求，不僅如此，而且開發(fā)人員可以借助用例來與用戶溝通，發(fā)現(xiàn)用戶的潛在性需求。例3：在一節(jié)不和諧的課堂里，老師嘆氣道：“要是坐在后排聊天的同學(xué)能像中間打牌的同學(xué)那么安靜，就不會影響到前排睡覺的同學(xué)?！痹谶@個描述中，同學(xué)們在課堂上都做了什么呢？答案：聊天、打牌、睡覺。分析：睡覺，用到的一系列動作有趴在課桌上、打鼾、磨牙等等；產(chǎn)生的結(jié)果是睡覺后不瞌睡了。打牌，用到的一系列動作有找打牌者、找撲克牌、起牌、出牌等等；產(chǎn)生的結(jié)果是打牌者心靈上得到了娛樂。那么這些動賓詞語就是用例，它表示了“同學(xué)”這個角色所做的事情。例4：如果你去使用ATM機（自動取款機），那么你通過ATM都可以做什么呢？答案是：查詢、存款、取款、轉(zhuǎn)賬、打印等。這些都可以稱為是用例，如下表示：用例描述用戶提出的一些可見需求，對應(yīng)一個具體的用戶目標(biāo)。在例4中，不論是存款還是轉(zhuǎn)賬我們都需要進行“數(shù)據(jù)處理”，但是“數(shù)據(jù)處理”不屬于一個用例，因為它沒有直接反應(yīng)用戶的需求。（3）繪制用例圖：用例圖是用例的集合，通常由系統(tǒng)、用例、角色和關(guān)聯(lián)組成。系統(tǒng)用一個矩形框表示，上面標(biāo)注系統(tǒng)名稱，內(nèi)部可包含一個或多個用例。角色和用例之間的關(guān)聯(lián)利用直線表示，組成符號如下：但是在一般情況下，在用例圖中僅僅表示參與者和用例之間的關(guān)系，而忽略掉系統(tǒng)的描述。例如，通過例4，由每個取款者抽象出系統(tǒng)角色“客戶”，利用關(guān)聯(lián)將角色和用例連接起來，就構(gòu)成了用例圖。下面給出例3和例4的用例圖。思考：1、咖啡機有煮咖啡的功能，我們?nèi)绾伪硎具@種關(guān)系？這個描述中存在哪些角色？哪些用例？2、小王利用咖啡機煮咖啡，這種關(guān)系又如何表示？這個描述中又存在哪些角色？哪些用例？注：用例是某角色所擁有功能的直接表現(xiàn)形式。例5：某保險商務(wù)系統(tǒng)，客戶可以簽訂保險單，保險銷售員可以鑒定保險單，還可以進行銷售統(tǒng)計和客戶統(tǒng)計。這段描述的用例圖表示為：例6：用戶登錄購物網(wǎng)站，瀏覽商品，選擇商品下訂單并支付，請識別該過程中的參與者和用例，并畫出用例圖。分析參與者：用戶。分析用例：登錄，瀏覽商品，下訂單，支付。畫用例圖：拓展練習(xí)：1、教務(wù)管理系統(tǒng)中，學(xué)生轉(zhuǎn)學(xué)這個過程中牽涉到了學(xué)生記錄的增加、修改和刪除，請確定學(xué)生轉(zhuǎn)學(xué)這個過程的用例。2、某學(xué)校網(wǎng)上選課系統(tǒng)。其中管理員通過系統(tǒng)管理界面進入系統(tǒng)，建立本學(xué)期要開設(shè)的各種課程，將課程信息保存到數(shù)據(jù)庫中，并可以對課程進行改動和刪除。學(xué)生通過客戶機瀏覽器進入系統(tǒng)，可以查詢課程，選擇課程，支付課程費用。請分析此系統(tǒng)中存在的角色和用例，并畫出用例圖。6.3.2用例描述用例描述（也稱為用例規(guī)約）主要是描述用例的靜態(tài)和動態(tài)兩方面特性。包括描述用例名稱、用例目的、參與者、用例的前提條件、用例的交互過程或者事件流、用例執(zhí)行結(jié)果、用例的擴展、特殊需求等等。其中，用例的事件流（也稱為場景）是參與者和系統(tǒng)完成該功能交互過程的描述。針對每一個用例我們利用事件流來描述這一對話的細節(jié)內(nèi)容。例如人們?nèi)湲?dāng)勞餐廳買漢堡時，柜臺人員會向用戶詢問是“外帶”還是“內(nèi)用”而決定其包裝程序。因此，每個人去買漢堡時，其接受服務(wù)的途徑有些相同，有些不同。其中每一個人使用系統(tǒng)的途徑就是一個事件流。如在ATM系統(tǒng)中的“提款”用例可以用事件流表述如下：提款基本事件流（1）用戶插入信用卡。（2）輸入密碼。（3）輸入提款金額。（4）提取現(xiàn)金。（5）退出系統(tǒng)，取回信用卡。但是這只描述了提款用例中最順利的一種情況，作為一個實用的系統(tǒng)，我們還必須考慮可能發(fā)生的各種其他情況，如信用卡無效、輸入密碼錯誤、用戶賬號中的現(xiàn)金余額不夠等，所有這些可能發(fā)生的各種情況（包括正常的和異常的）被稱之為事件流。在用例的各種事件流中，最常見的事件流是用基本流(BasicFlow)來描述的，其他的事件流則是用備選流(AlternativeFlow)來描述。對于ATM系統(tǒng)中的“提款”用例，我們可以得到如下一些備選流：提款備選事件流備選流一：用戶可以在基本流中的任何一步選擇退出，轉(zhuǎn)至基本流步驟5。備選流二：在基本流步驟1中，用戶插入無效信用卡，系統(tǒng)顯示錯誤并退出信用卡，用例結(jié)束。備選流三：在基本流步驟２中，用戶輸入錯誤密碼，系統(tǒng)顯示錯誤并提示用戶重新輸入密碼，重新回到基本流步驟2；三次輸入密碼錯誤后，信用卡被系統(tǒng)沒收，用例結(jié)束?！ㄟ^基本流與備選流的組合，就可以將用例所有可能發(fā)生的各種事件流全部描述清楚。我們在描述用例的事件流的時候，就是要盡可能地將所有可能的事件流都描述出來，以保證需求的完備性。IBMRationalUnifiedProcess(RUP)給出了基本流和備選流之間的關(guān)系描述，也就是說，用例描述從基本流開始，可以執(zhí)行基本流結(jié)束用例所完成的功能，也可以通過基本流轉(zhuǎn)入備選流來結(jié)束用例所完成的功能，還可以從基本流轉(zhuǎn)為備選流，再轉(zhuǎn)入基本流結(jié)束用例的執(zhí)行。總之，通過下圖，可以得到基本流和備選流組合成的路徑有：路徑1：基本流路徑2：基本流—備選流1—基本流路徑3：基本流—備選流1—備選流2路徑4：基本流—備選流3—基本流路徑5：基本流—備選流3—備選流4路徑6：基本流—備選流3—備選流1—備選流2路徑7：基本流—備選流3—備選流1—基本流路徑8：基本流—備選流4也就是說，用例的事件流（包括基本流和備選流）通過不同的路徑描述，產(chǎn)生不同的結(jié)果。即同一個用例，通過一系列不同的動作，會產(chǎn)生不同的結(jié)果。根據(jù)用例的定義，對用例的描述應(yīng)該是規(guī)范的。用例描述的模板如下表所示：用例描述模板序號模板項目說明1用例名稱每個用例都有一個清晰、無歧義的動名詞短語作為名稱，如簽訂合同2用例目的用例是為獲取有價值的結(jié)果而對系統(tǒng)功能的執(zhí)行，因此每個用例的執(zhí)行都有最終的目的或者目標(biāo)3參與者和該用例有關(guān)的參與者，可以是多個4前提條件用例可以開始執(zhí)行的前提條件5事件流該項描述了用戶和系統(tǒng)在執(zhí)行該用例的過程中，用戶和系統(tǒng)之間的交互細節(jié)，包括：用戶做了什么，系統(tǒng)做什么，除了基本正常的事件流（基本流）之外，還應(yīng)該包括異常事件流（備選流）6后置條件該用例執(zhí)行完畢后系統(tǒng)的最終狀態(tài)7擴展點什么條件下，可以擴展為其他用例8其他用例的其他特殊要求，如性能要求、使用頻率等例7：在某論壇系統(tǒng)中，針對討論區(qū)成員，存在如下用例：下面給出“新增帖子”用例的描述過程：用例名稱：新增帖子用例目的：完成帖子的添加參與者：討論區(qū)人員前置條件：討論區(qū)成員成功地進入討論區(qū)，通過身份驗證。事件流：第1步：進入分組討論區(qū)界面討論區(qū)成員：選擇進入相應(yīng)的分組討論區(qū)系統(tǒng)：將分組討論區(qū)中信息全部顯示出來第2步：新增帖子討論區(qū)成員：要求新增一條帖子信息系統(tǒng)：進入新增帖子界面。第3步：填寫帖子討論區(qū)成員：填寫帖子中的具體信息系統(tǒng)：顯示輸入的內(nèi)容。第4步：提交討論區(qū)成員：提交填寫好的討論區(qū)系統(tǒng)：保存該討論區(qū)到內(nèi)部數(shù)據(jù)庫后置條件：完成了帖子的增加，返回討論區(qū)擴展點：修改帖子例8：某學(xué)校選課系統(tǒng)中“增加課程”的用例簡單描述。用例名稱：增加課程參與者：管理員事件流：(1)管理員選擇進入管理界面，用例開始。(2)系統(tǒng)提示輸入管理員密碼。(3)管理員輸入密碼。(4)系統(tǒng)檢驗密碼。A1：密碼出錯。(5)進入管理界面，系統(tǒng)顯示當(dāng)前所建立的全部課程信息。(6)管理選擇增加課程，管理輸入新課程信息。(7)系統(tǒng)驗證是否與已有課程沖突。A2：有沖突。(8)系統(tǒng)添加新課程，并提示添加成功。(9)系統(tǒng)回到管理主界面，顯示所有課程，用例結(jié)束。拓展練習(xí)：（1）根據(jù)“新增帖子”的用例描述，給出“查看帖子”、“回復(fù)帖子”的用例描述。（2）給出例5中“簽訂保險單”的用例描述。（3）理解下面的用例圖，并回答問題。問題1：角色“學(xué)生”執(zhí)行哪些用例？角色“教授”呢？問題2：如果李三是一個學(xué)生兼教授，哪些用例可以被執(zhí)行？問題3：對用例“學(xué)生選課”，“注冊”進行用例描述。6.4建立用例模型用例建模是根據(jù)用戶對系統(tǒng)的描述和要求，將其模型化的過程。在用例建模的過程中，我們建議的步驟是先確定系統(tǒng)邊界，然后找出系統(tǒng)參與者，再根據(jù)參與者確定每個參與者相關(guān)的用例，最后再細化每一個用例的用例規(guī)約。6.4.1確定系統(tǒng)邊界確定系統(tǒng)邊界，這是在軟件需求分析中的重要一步。這個過程就是要確定我們所開發(fā)的系統(tǒng)和外部環(huán)境之間的界限，也就是要區(qū)分系統(tǒng)本身和它的外部環(huán)境。其中外部環(huán)境可能包括用戶、其他系統(tǒng)、軟硬件條件等。舉個例子，一個銀行系統(tǒng)，它的系統(tǒng)邊界如何確定呢？首先，銀行系統(tǒng)的外部活動者有儲戶、前臺出納員、銀行管理員，這些都不屬于銀行系統(tǒng)本身，他們是此系統(tǒng)的外部環(huán)境；其次，銀行系統(tǒng)是運行在操作系統(tǒng)上的軟件，它在運行過程中可能要進行生成文件、獲取時間等操作，這涉及到操作系統(tǒng)的API，所以操作系統(tǒng)對于銀行系統(tǒng)來說是外部環(huán)境；再次，銀行系統(tǒng)要打印交易憑條，打印機對于系統(tǒng)來說是外部環(huán)境；第四，銀行系統(tǒng)可能與客戶的工作單位的工資發(fā)放系統(tǒng)有交互，那么客戶工作單位的工資發(fā)放系統(tǒng)也是外部環(huán)境。而對于銀行系統(tǒng)來說，使用此系統(tǒng)的銀行的建筑格局、人員構(gòu)成、所處地域等就不是此系統(tǒng)的外部環(huán)境。確定了系統(tǒng)的邊界有什么用呢？系統(tǒng)邊界一確定，我們就已經(jīng)知道有哪些外部對象在與系統(tǒng)進行交互，于是我們就可以在系統(tǒng)中為該對象設(shè)計相應(yīng)的接口，從而實現(xiàn)這些交互。用上面的例子說，我們應(yīng)該給儲戶、前臺出納、管理員設(shè)計不同的接口，還要給客戶工作單位的工資發(fā)放系統(tǒng)設(shè)計接口，為打印機設(shè)計接口。這些是我們需要關(guān)心的，如果這些外部環(huán)境改變了，我們可能要重新設(shè)計我們的接口。但不在系統(tǒng)邊界上的因素我們就不用考慮，比如我們不必為銀行建筑格局的改變而改變我們的系統(tǒng)接口，這是下水管道設(shè)計師應(yīng)該關(guān)心的問題。確定系統(tǒng)邊界在項目開發(fā)中是非常重要的一步，如果系統(tǒng)邊界確定得不好，會給接下來的分析設(shè)計和編碼工作帶來障礙，也會給系統(tǒng)的維護帶來麻煩。系統(tǒng)的邊界決定了系統(tǒng)的參與者，例如：我們所要定義的系統(tǒng)邊界僅限于ATM機本身，那么后臺服務(wù)器就是一個外部的系統(tǒng)，可以抽象為一個參與者。如果我們所要定義的系統(tǒng)邊界擴大至整個銀行系統(tǒng)，ATM機和后臺服務(wù)器都是整個銀行系統(tǒng)的一部分，這時候后臺服務(wù)器就不再被抽象成為一個參與者。6.4.2查找系統(tǒng)參與者參與者是在系統(tǒng)之外，通過系統(tǒng)邊界與系統(tǒng)進行有意義交互的任何事物。通俗地講，參與者就是我們所要定義系統(tǒng)的使用者。尋找參與者可以從以下問題入手：(1)系統(tǒng)開發(fā)完成之后，有哪些人會使用這個系統(tǒng)？(2)系統(tǒng)需要從哪些人或其他系統(tǒng)中獲得數(shù)據(jù)？(3)系統(tǒng)會為哪些人或其他系統(tǒng)提供數(shù)據(jù)？(4)系統(tǒng)需要與哪些其他系統(tǒng)交互？(5)系統(tǒng)是由誰來維護和管理并保持其正常運行？(6)系統(tǒng)需要應(yīng)付（處理）哪些硬設(shè)備？(7)誰（或什么）對系統(tǒng)運行產(chǎn)生的結(jié)果感興趣？(8)有沒有自動發(fā)生的事件？例9：客戶服務(wù)系統(tǒng)是對公司和客戶進行統(tǒng)一管理的系統(tǒng)，根據(jù)客戶服務(wù)系統(tǒng)案例需求說明書，具體包括以下幾個方面：(1)基礎(chǔ)資料維護。包括系統(tǒng)管理員添加、刪除、修改客戶服務(wù)系統(tǒng)賬戶信息，添加、修改、刪除公司產(chǎn)品及項目信息；客戶服務(wù)人員添加、修改、刪除客戶資料信息，添加、修改、刪除經(jīng)驗庫信息等。(2)業(yè)務(wù)處理。包括客戶服務(wù)人員新增、修改、刪除客戶咨詢信息；維護人員處理客戶問題、填寫維護報告；部門領(lǐng)導(dǎo)處理投訴，安排任務(wù)等。(3)統(tǒng)計查詢。包括客戶資料查詢、客戶來電咨詢查詢、經(jīng)驗庫查詢、客戶服務(wù)系統(tǒng)用戶信息查詢、回訪任務(wù)及維護報告查詢等。明確以上信息后，分析系統(tǒng)的參與者。分析：對于這個系統(tǒng)，通過需求陳述文檔，可以得到以下一些信息：（1）系統(tǒng)管理員維護系統(tǒng)用戶帳號和產(chǎn)品項目信息。（2）客戶服務(wù)人員維護客戶資料、客戶咨詢以及經(jīng)驗庫信息。（3）維護人員填寫維護報告。（4）部門領(lǐng)導(dǎo)處理投訴。所以創(chuàng)建以下參與者：系統(tǒng)管理員、客戶服務(wù)人員、維護人員、部門領(lǐng)導(dǎo)。值得注意的是，用例建模時不要將一些系統(tǒng)的組成結(jié)構(gòu)作為參與者來進行抽象，如在ATM機系統(tǒng)中，打印機只是系統(tǒng)的一個組成部分，不應(yīng)將它抽象成一個獨立的參與者；在一個MIS管理系統(tǒng)中，數(shù)據(jù)庫系統(tǒng)往往只作為系統(tǒng)的一個組成部分，一般不將其單獨抽象成一個參與者。有時候需要在系統(tǒng)內(nèi)部定時地執(zhí)行一些操作，如檢測系統(tǒng)資源使用情況、定期地生成系統(tǒng)報表等。從表面上看，這些操作并不是由外部的人或系統(tǒng)觸發(fā)的，應(yīng)該怎樣用用例方法來表述這一類功能需求呢？對于這種情況，可以抽象出一個系統(tǒng)時鐘或定時器參與者，利用該參與者來觸發(fā)這一類定時操作。從邏輯上看，這一參與者應(yīng)該被理解成是系統(tǒng)外部的，由它來觸發(fā)系統(tǒng)所提供的用例對話，如下圖所示：拓展練習(xí)：（1）找出與圖書館管理系統(tǒng)交互的所有參與者。（2）分析網(wǎng)上鮮花購銷系統(tǒng)中存在的所有參與者。6.4.3查找系統(tǒng)用例找到參與者之后，就可以根據(jù)參與者來確定系統(tǒng)的用例，主要是看各參與者需要系統(tǒng)提供什么樣的服務(wù)，或者說參與者是如何使用系統(tǒng)的。尋找用例可以從以下問題入手：(1)參與者為什么要使用該系統(tǒng)？(2)參與者是否會在系統(tǒng)中創(chuàng)建、修改、刪除、訪問、存儲數(shù)據(jù)？如果是的話，參與者又是如何來完成這些操作的？(3)參與者是否會將外部的某些事件通知給該系統(tǒng)？(4)系統(tǒng)是否會將內(nèi)部的某些事件通知該參與者？綜合以上所述，根據(jù)前面有關(guān)對ATM系統(tǒng)的分析，得到的用例圖可表示如下：例10：根據(jù)例9的描述，針對每一個參與者，分析其對應(yīng)的用例。分析：客戶服務(wù)人員：(1)登錄系統(tǒng)。(2)查詢客戶信息及咨詢記錄。(3)查詢經(jīng)驗庫信息。(4)查詢基礎(chǔ)資料信息。(5)補充完善經(jīng)驗庫信息。(6)維護客戶資料。(7)維護來電記錄。維護人員：(1)查詢自己的派工單及報告信息。(2)接受并處理自己的派工單。(3)填寫報告。系統(tǒng)管理員：(1)管理用戶。(2)維護基礎(chǔ)資料。(3)維護系統(tǒng)。部門領(lǐng)導(dǎo)：(1)查詢客戶資料及咨詢信息。(2)查詢項目及產(chǎn)品信息。(3)查詢維護人員派工單的執(zhí)行情況。(4)安排派工任務(wù)。對應(yīng)的用例圖描述（這里僅給出部分參與者的用例圖）為：拓展練習(xí)：（1）根據(jù)6.4.3練習(xí)（1）中找出的系統(tǒng)參與者，分析圖書管理系統(tǒng)中每個參與者所擁有的用例。（2）根據(jù)6.4.3練習(xí)（2）中找出的系統(tǒng)參與者，分析網(wǎng)上鮮花購銷系統(tǒng)中每個參與者所擁有的用例。6.4.4用例圖優(yōu)化在一般的用例圖中，只表述參與者和用例之間的關(guān)系，即它們之間的通信關(guān)聯(lián)。除此之外，還可以描述參與者與參與者之間、用例和用例之間的其他關(guān)系，主要有：包含（include）、擴展（extend）和泛化（generalization）關(guān)系。利用這些關(guān)系來調(diào)整優(yōu)化已有的用例模型，把一些公共的信息抽取出來重用，使得用例模型更易于維護。（1）參與者與參與者之間的關(guān)系參與者與參與者之間利用泛化(Generalization)關(guān)系（或稱為“繼承”關(guān)系）來表示，體現(xiàn)的是一般與特殊的關(guān)系，它的圖形表示為：例1：參與者之間的泛化關(guān)系參與者：經(jīng)理，安全主管，保安用例：管理人事，批準(zhǔn)預(yù)算，批準(zhǔn)安全證書，監(jiān)視周邊在參與者之間不存在泛化關(guān)系的情況下，各個參與者參與用例的情況分別是：經(jīng)理參與用例管理人事和批準(zhǔn)預(yù)算；安全主管參與用例批準(zhǔn)安全證書；保安參與用例監(jiān)視周邊。由于安全主管與經(jīng)理，安全主管與保安之間泛化關(guān)系的存在，意味著安全主管可以擔(dān)任經(jīng)理和保安的角色，就能夠參與經(jīng)理和保安參與的用例。這樣，安全主管就可以參與全部4個用例。但經(jīng)理或者保安卻不能擔(dān)任安全主管的角色，也就不能參與用例批準(zhǔn)安全證書。又例如參與者客戶、電話客戶、網(wǎng)上客戶之間的關(guān)系；參與者交通工具和船、車、轎車、卡車、客車之間的關(guān)系等都屬于泛化關(guān)系。例2:在需求分析中常見的權(quán)限控制問題（如下圖所示），一般的用戶只可以使用一些常規(guī)的操作，而管理員除了常規(guī)操作之外還需要進行一些系統(tǒng)管理工作，操作員既可以進行常規(guī)操作又可以進行一些配置操作。在這個例子中我們會發(fā)現(xiàn)管理員和操作員都是一種特殊的用戶，他們擁有普通用戶所擁有的全部權(quán)限，此外他們還有自己獨有的權(quán)限。這里我們可進一步把普通用戶和管理員、操作員之間的關(guān)系抽象成泛化(Generalization)關(guān)系，管理員和操作員可以繼承普通用戶的全部特性（包括權(quán)限），他們又可以有自己獨有的特性（如操作、權(quán)限等）。這樣可以顯著減少用例圖中通訊關(guān)聯(lián)的個數(shù)，簡化用例模型，使之更易于理解。例如：在某高校的教務(wù)信息管理系統(tǒng)中，大學(xué)生可以創(chuàng)建簡歷、安排日程、查詢課表，而任課教師也可以安排日程和查詢課表，還可調(diào)研新課程開設(shè)。分析：在這個系統(tǒng)中，就可以建立一個“一般用戶”的抽象角色，管理“安排日程”和“查詢課表”用例，大學(xué)生和任課教師作為具體的用例，就能繼承這兩個用例的關(guān)聯(lián)。利用圖示可表示為：（2）用例和用例之間的關(guān)系用例描述的是系統(tǒng)外部可見的行為，是系統(tǒng)為某一個或幾個參與者提供的一段完整的服務(wù)。從原則上來講，用例之間都是并列的，它們之間并不存在著包含從屬關(guān)系。但是從保證用例模型的可維護性和一致性角度來看，我們可以在用例之間抽象出包含(include)、擴展(extend)和泛化(generalization)這幾種關(guān)系。這幾種關(guān)系都是從現(xiàn)有的用例中抽取出公共的那部分信息，然后通過不同的方法來重用這部公共信息，以減少模型維護的工作量。1)包含(include)包含關(guān)系是通過在關(guān)聯(lián)關(guān)系上應(yīng)用<<include>>構(gòu)造型來表示的，如下圖所示。它所表示的語義是指基礎(chǔ)用例(Base)會用到被包含用例(Inclusion)，具體地講，就是將被包含用例的事件流插入到基礎(chǔ)用例的事件流中。具體理解為：客戶用例可以簡單地包含提供者用例具有的行為，并把它所包含的用例行為作為自身行為的一部分。在具有包含關(guān)系的兩個用例中，提供者用例不能單獨存在，它只能以實例的形式存在于客戶用例之中。包含關(guān)系使得一個用例的功能可以在另一個用例中使用。例如，在ATM機中，如果查詢、取現(xiàn)、轉(zhuǎn)賬這三個用例都需要打印一個回執(zhí)給客戶，我們就可以把打印回執(zhí)這一部分內(nèi)容提取出來，抽象成為一個單獨的用例“打印回執(zhí)”，而原有的查詢、取現(xiàn)、轉(zhuǎn)帳三個用例都會包含這個用例。每當(dāng)以后要對打印回執(zhí)部分的需求進行修改時，就只需要改動一個用例，而不用在每一個用例都作相應(yīng)修改，這樣就提高了用例模型的可維護性。在基礎(chǔ)用例的事件流中，我們只需要引用被包含用例即可。查詢-基本事件流引用被包含的用例1.用戶插入信用卡引用被包含的用例2.輸入密碼3.選擇查詢4.查看帳號余額5.包含用例“打印回執(zhí)”6.退出系統(tǒng)，取回信用卡在這個例子中，多個用例需要用到同一段行為，我們可以把這段共同的行為單獨抽象成為一個用例，然后讓其他的用例來包含這一用例。從而避免在多個用例中重復(fù)性地描述同一段行為，也可以防止該段行為在多個用例中的描述出現(xiàn)不一致性。當(dāng)需要修改這段公共的需求時，我們也只需要修改一個用例，避免同時修改多個用例而產(chǎn)生的不一致性和重復(fù)性工作。有時當(dāng)某一個用例的事件流過于復(fù)雜時，為了簡化用例的描述，我們也可以把某一段事件流抽象成為一個被包含的用例。這種情況類似于在過程設(shè)計語言中，將程序的某一段算法封裝成一個子過程，然后再從主程序中調(diào)用這一子過程。2)擴展(extend)擴展（extend）關(guān)系如下圖所示，基礎(chǔ)用例(Base)中定義有一至多個已命名的擴展點，擴展關(guān)系是指將擴展用例(Extension)的事件流在一定的條件下按照相應(yīng)的擴展點插入到基礎(chǔ)用例(Base)中。擴展與包含的區(qū)別：對于包含關(guān)系而言，子用例中的事件流是一定插入到基礎(chǔ)用例中去的，并且插入點只有一個。而擴展關(guān)系可以根據(jù)一定的條件來決定是否將擴展用例的事件流插入基礎(chǔ)用例事件流，并且插入點可以有多個。例1:在某些系統(tǒng)中允許用戶對查詢的結(jié)果進行導(dǎo)出、打印。分析：對于查詢而言，能不能導(dǎo)出、打印查詢結(jié)果都是一樣的，導(dǎo)出、打印是不可見的。導(dǎo)入、打印和查詢相對獨立，而且為查詢添加了新行為。因此可以采用擴展關(guān)系來描述：例2:對于電話業(yè)務(wù)，可以在基本通話(Call)業(yè)務(wù)上擴展出一些增值業(yè)務(wù)如：呼叫等待(CallWaiting)和呼叫轉(zhuǎn)移(CallTransfer)。我們可以用擴展關(guān)系將這些業(yè)務(wù)的用例模型描述如下。在這個例子中，呼叫等待和呼叫轉(zhuǎn)移都是對基本通話用例的擴展，但是這兩個用例只有在一定的條件下（如應(yīng)答方正忙或應(yīng)答方無應(yīng)答）才會將被擴展用例的事件流嵌入基本通話用例的擴展點，并重用基本通話用例中的事件流。值得注意的是擴展用例的事件流往往也可抽象為基礎(chǔ)用例的備選流，如上例中的呼叫等待和呼叫轉(zhuǎn)移都可以作為基本通話用例的備選流而存在。但是基本通話用例已經(jīng)是一個很復(fù)雜的用例了，選用擴展關(guān)系將增值業(yè)務(wù)抽象成為單獨的用例可以避免基礎(chǔ)用例過于復(fù)雜，并且把一些可選的操作獨立封裝在另外的用例中。3)泛化(generalization)當(dāng)多個用例共同擁有一種類似的結(jié)構(gòu)和行為的時候，我們可以將它們的共性抽象成為父用例，其他的用例作為泛化關(guān)系中的子用例。在用例的泛化關(guān)系中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結(jié)構(gòu)、行為和關(guān)系。在實際應(yīng)用中很少使用泛化關(guān)系，子用例中的特殊行為都可以作為父用例中的備選流存在。以下是一個用例泛化關(guān)系的例子，執(zhí)行交易是一種交易抽象，執(zhí)行房產(chǎn)交易和執(zhí)行證券交易都是一種特殊的交易形式。用例泛化關(guān)系中的事件流示例如下：執(zhí)行交易基本流：1.客戶登錄驗證客戶身份2.客戶選擇交易客戶選擇交易類型3.客戶選擇賬戶系統(tǒng)顯示客戶所用帳號，客戶選擇帳號4.執(zhí)行交易5.客戶開始新的交易如果客戶需要執(zhí)行其他交易，轉(zhuǎn)至步驟36.現(xiàn)實交易結(jié)束系統(tǒng)顯示交易結(jié)束執(zhí)行證卷交易該用例是執(zhí)行交易用例的一個子用例?；玖?1.客戶登錄2.客戶選擇交易3.客戶選擇帳號4.執(zhí)行交易根據(jù)客戶選擇的交易類型，系統(tǒng)分別執(zhí)行定價買入，定價賣出。5．客戶開始新的交易6．顯示交易結(jié)束除了父用例中的操作步驟之外，系統(tǒng)計算該用戶的帳號平衡情況。注意：在應(yīng)用這些關(guān)系時，要小心選用。一般來說這些關(guān)系都會增加用例和關(guān)系的個數(shù)，從而增加用例模型的復(fù)雜度。而且一般都是在用例模型完成之后對用例模型進行優(yōu)化調(diào)整，所以在用例建模的初期不必急于抽象用例之間的關(guān)系。拓展練習(xí)：1、分析用例2和用例3之間是什么關(guān)系？用例5和用例6呢？用例5缺少了用例3仍然是個完整的用例？參與者4能夠參與用例2嗎？參與者1能夠參與用例5嗎？2、假如有個人事管理系統(tǒng)，經(jīng)理可以查看員工的信息，并可以增加，修改和刪除，但每次執(zhí)行這三個操作時，都要定位到相應(yīng)的員工，即先查詢定位到要操作的員工。請分析經(jīng)理所擁有的用例，以及用例之間存在的關(guān)系。6.5用例模型復(fù)審用例模型完成之后，可以對用例模型進行檢查復(fù)審，看看是否有遺漏或錯誤之處。主要可以從以下幾個方面來進行檢查：（1）功能需求的完備性:現(xiàn)有的用例模型是否完整地描述了系統(tǒng)功能，這也是我們判斷用例建模工作是否結(jié)束的標(biāo)志。如果發(fā)現(xiàn)還有系統(tǒng)功能沒有被記錄在現(xiàn)有的用例模型中，那么我們就需要抽象一些新的用例來記錄這些需求，或是將他們歸納在一些現(xiàn)有的用例之中。（2）模型是否易于理解:用例模型最大的優(yōu)點就在于它應(yīng)該易于被不同的涉眾所理解，因而用例建模最主要的指導(dǎo)原則就是它的可理解性。用例的粒度、個數(shù)以及模型元素之間的關(guān)系復(fù)雜程度都應(yīng)該由該指導(dǎo)原則決定。（3）是否存在不一致性:系統(tǒng)的用例模型是由多個系統(tǒng)分析員協(xié)同完成的，模型本身也是由多個工件所組成的，所以我們要特別注意不同工件之前是否存在前后矛盾或沖突的地方，避免在模型內(nèi)部產(chǎn)生不一致性。不一致性會直接影響到需求定義的準(zhǔn)確性。（4）避免二義性語義:好的需求定義應(yīng)該是無二義性的，即不同的人對于同一需求的理解應(yīng)該是一致的。在用例規(guī)約的描述中，應(yīng)該避免定義含義模糊的需求，即無二義性。用例檢查點用例模型的簡介部分簡明清晰地概述此系統(tǒng)的目的和功能。所有的用例已確定，這些用例共同說明所有的必要行為。所有的功能性需求都至少映射到一個用例。該用例模型不包含多余的行為，所有的用例都可回溯到某個功能性需求來證明其合理性。角色檢查點您是否已找到所有的角色？也就是說，您是否已經(jīng)對系統(tǒng)環(huán)境中的所有角色都進行了說明和建模？每個角色是否至少涉及一個用例？您能否列出至少兩名可以作為特定角色的人員？是否有角色擔(dān)任與系統(tǒng)相關(guān)的相似角色？如果有，您應(yīng)該將他們合并到一個角色中。綜合練習(xí)1：為某企業(yè)建立一個人事管理系統(tǒng)。有以下需求：(1)經(jīng)理可創(chuàng)建部門、撤銷部門、更改部門的名稱、安排部門經(jīng)理，也能對人員指派部門；(2)人事部門的工作人員可建立員工的人事檔案，應(yīng)包括身份證號、姓名、性別、出生日期等；(3)部門經(jīng)理可為本部門添加新員工、確定員工的工資,也可解除本部門的特定員工；(4)員工可修改自己的個人信息，如聯(lián)系電話、Email等，也可查看本部門的其他員工的信息。根據(jù)以上描述，結(jié)合常識和邏輯推理，建立用例圖來表示系統(tǒng)的功能。并對所畫用例圖優(yōu)化。練習(xí)2：建立一個師生互動的網(wǎng)站，能支持多門課程的師生之間建立溝通，功能要求如下：(1)一名教師可同時承擔(dān)多門課程，與相應(yīng)的選課學(xué)生進行交流。一名學(xué)生可同時上多門課程，與相應(yīng)的代課教師進行交流。(2)答疑：學(xué)生提問，教師回答，問題及回答對同一門課程的學(xué)生是公開的，教師對學(xué)生提出的重復(fù)性問題，可引用已解決的問題。教師最后可統(tǒng)計哪些學(xué)生比較活躍。(3)作業(yè)：教師可根據(jù)某主題，編寫一組練習(xí)題，題型有選擇題(回答ABCD)、問答題(回答一個字符串)、大作業(yè)(提交一個文檔)，教師可對每個提交作業(yè)的學(xué)生給出成績，能統(tǒng)計學(xué)生成績。根據(jù)以上描述，結(jié)合常識和邏輯推理，建立用例圖來表示系統(tǒng)的功能。并對其用例圖優(yōu)化。6.6使用StarUML繪制用例圖StarUML是支持UML的建模平臺軟件。它提供了對用戶環(huán)境最大化可定制支持，通過定制所提供一些變量，可以使用用戶開發(fā)方法、項目平臺及各種編程語言。運用StarUML，頂級領(lǐng)先的軟件模型工具之一，可以保證您的軟件項目高質(zhì)量、高效率。6.6.1StarUML簡介StarUML是一款開放源碼的UML開發(fā)工具，是由韓國公司主導(dǎo)開發(fā)出來的產(chǎn)品，可以直接到StarUML網(wǎng)站(/)下載大約22MB的執(zhí)行文件。StarUML可繪制9款UML圖，包括用例圖、類圖、序列圖、狀態(tài)圖、活動圖等。StarUML的主界面如下：StarUML有高度可擴充及適應(yīng)能力。為擴充功能，該工具采用了插件（Add-In）框架。它提供訪問全部的模型/原模型的功能，通過COM自動化，菜單和選項也都是可擴充的。而且用戶還可以根據(jù)他們自己的方法論來創(chuàng)建自己的方法和框架。該工具還可以集成任何其他的外部工具。它具有以下新特征：1）準(zhǔn)確的UML標(biāo)準(zhǔn)模型：StarUML嚴格堅持OMG對軟件模型規(guī)定的UML標(biāo)準(zhǔn)規(guī)格說明。StarUML最大化遵循UML1.4標(biāo)準(zhǔn)和語義，并采用基于穩(wěn)定的元模型的UML2.0表示法。2）開放的軟件模型格式：StarUML以標(biāo)準(zhǔn)的XML格式管理所有的文件。代碼編寫的結(jié)構(gòu)易讀，便于用XML分析器改變。XML是世界標(biāo)準(zhǔn)的，這是既定的事實，肯定地說，這樣有很多的好處，也可以確保這樣的軟件模型十幾年后還仍然可以有用。3）真正的模型驅(qū)動：StarUML真實地支持UML輪廓（Profile）。這樣最大化了對UML的的擴展，可廣泛用在財務(wù)、國防、電子商務(wù)、保險和航天諸領(lǐng)域建立應(yīng)用模型?？梢詣?chuàng)建真正獨立于平臺的模型(PlatformIndependentModels，PIM)、特定平臺模型(PlatformSpecificModel，PSM)，并且能以任意方式生成可執(zhí)行代碼。4）方法學(xué)與平臺的適用性：StarUML利用方法（approach）概念，創(chuàng)建的環(huán)境可以采用任何的方法學(xué)/過程。不僅像.NET和J2EE平臺這樣的應(yīng)用框架模型，而且軟件模型的基本結(jié)構(gòu)（如4+1視圖模型等），都可輕松的定義。5）極好的可擴充性：StarUML工具的所有功能都自動支持MicrosoftCOM。支持COM的任何語言(VisualBasicScript，JavaScript，VB，Delphi，C++，C#,，VB.NET，Python等)都可以用于控制StarUML或者用于開發(fā)可集成的插件元素。6）軟件模型校驗功能：建立軟件模型過程中，用戶可能會犯很多錯誤。如果這些錯誤在編碼階段之前還沒有得到更正，那是要付出很大代價的。為了避免這樣的問題，StarUML可以自動校驗用戶開發(fā)的軟件模型，便于較早發(fā)現(xiàn)錯誤，無瑕疵地完成軟件開發(fā)。7）好用的插件Add-Ins：StarUML包含很多具備各種功能的很有用插件（Add-Ins）：生成編程語言的源代碼，把源代碼轉(zhuǎn)換成模型，導(dǎo)入RationalRose文件，與其他使用XMI的工具交換模型信息，并支持設(shè)計模式。這些插件為模型信息提供了附加的可重用性、多產(chǎn)性、靈活性及交互性。6.6.2利用StarUML繪制用例圖用例圖包含了角色、用例，以及角色和角色、用例和用例、角色和用例之間存在的關(guān)系。一個完整的系統(tǒng)是由多個用例圖構(gòu)成了，即用例模型。利用StarUML繪制用例圖的第一步驟就是運行StarUML，建立用例模型，如下圖所示。添加用例模型添加用例模型1．創(chuàng)建參與者：要創(chuàng)建參與者，點擊[工具條Toolbox]->[用例UseCase]->[參與者Actor]按鈕，然后在要放置參與者的地方單擊。參與者以人輪廓形式或帶方框的圖標(biāo)記形式顯示，那是個裝飾視圖