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