統(tǒng)一建模語(yǔ)言的分類及其應(yīng)用

統(tǒng)一建模語(yǔ)言的分類及其應(yīng)用

1泛應(yīng)用的建模語(yǔ)言在系統(tǒng)管理的開發(fā)過(guò)程中，系統(tǒng)建模對(duì)于建筑來(lái)說(shuō)是一個(gè)項(xiàng)目，就像畫一樣重要。隨著面向?qū)ο蠓治雠c設(shè)計(jì)(OOA&D)技術(shù)的發(fā)展,出現(xiàn)了多種用于系統(tǒng)建模的OO建模語(yǔ)言。其中最具代表性并得到廣泛應(yīng)用的有OOSE(面向?qū)ο蟮能浖こ?、OMT和Booch。它們各自都是一套完備的方法,并且具有某方面的優(yōu)勢(shì)。OOSE是一種面向用例的方法,比較適合于商業(yè)工程和需求分析;OMT適用于描述分析與以數(shù)據(jù)為中心的信息系統(tǒng);Booch特別適用于系統(tǒng)的設(shè)計(jì)與構(gòu)造。在如此眾多的OO建模語(yǔ)言中,并沒(méi)有一種居于支配地位,且除了一些細(xì)微差別外,都共享一些公認(rèn)的概念,從而為用戶在應(yīng)用中的選擇造成了困難,在進(jìn)入OO市場(chǎng)和采用OO建模方法時(shí)產(chǎn)生了猶豫。因此,有必要在比較不同建模語(yǔ)言優(yōu)缺點(diǎn)和總結(jié)面向?qū)ο蠹夹g(shù)應(yīng)用實(shí)踐的基礎(chǔ)上,統(tǒng)一建模語(yǔ)言。UML正是在這種背景下誕生的。2可視化建模語(yǔ)言統(tǒng)一建模語(yǔ)言(UnifiedModelingLanguage,UML)試圖建立一種統(tǒng)一的、面向?qū)ο蟮慕７椒?是一種用于面向?qū)ο蠛突跇?gòu)件的、系統(tǒng)建模的、定義明確的、被廣泛接受的可視化建模語(yǔ)言。UML是由包括RationalSoftware公司在內(nèi)的聯(lián)盟開發(fā)的,它繼承了Booch,OOSE,OMT和其它方法的思想。許多公司已將UML作為一個(gè)商業(yè)策略而納入他們的開發(fā)過(guò)程和產(chǎn)品中,涵蓋許多領(lǐng)域,比如商業(yè)建模、需求管理、分析和設(shè)計(jì)、編程和測(cè)試等。2.1uml發(fā)展概況UML的發(fā)展開始于1994年10月,RationalSoftware公司的GradyBooch和JimRumbaugh開始致力于統(tǒng)一Booch和OMT方法的工作。鑒于Booch和OMT方法在發(fā)展過(guò)程中已相互借鑒,并且在世界范圍內(nèi)被共同認(rèn)定為具有代表性的面向?qū)ο蟮姆椒?Booch和Rumbaugh聯(lián)合起來(lái)致力于兩者的統(tǒng)一。1995年發(fā)布了第一個(gè)公開版本,稱為統(tǒng)一方法UM0.8(UnitiedMethod)。在1995年秋季,IvarJacobson和他的Objectory公司加盟這項(xiàng)工作,融合進(jìn)OOSE方法。Booch,Rumbaugh和Jacobson努力的結(jié)果就是1996年6月和10月UML0.9和UML0.91的推出。在同一年,許多組織開始將UML作為他們的商業(yè)策略。由ObjectManagementGroup(OMG)發(fā)起的RequestForProposal(RFP)為這些組織聯(lián)合力量創(chuàng)建一個(gè)共同RFP響應(yīng)提供了契機(jī)。Rational建立了UML成員協(xié)會(huì),由許多希望為定義UML而貢獻(xiàn)資源的組織構(gòu)成。合作者包括:DigitalEquipmentCorp.,HP,I-Logix,IntelliCorp,IBM,ICONComputing,MCISustemhouse,Microsoft,Oracle,RationalSoftware,TI和Unisys。這種聯(lián)合產(chǎn)生了UML1.0,一種定義良好、易于表達(dá)、功能強(qiáng)大、普遍適用的建模語(yǔ)言,并被作為RFP早期的響應(yīng)提交給OMG。1997年IBM,ObjectTime,PlatinumTechnology,Ptech,Taskon&ReichTechnologies和Softeam也向OMG提交了各自的RFP響應(yīng)。這些公司也成為UML的合作者,并提出了他們的意見(jiàn)和想法,并且和其他合作者一同制定了改進(jìn)的UML1.1。UML1.1主要是改進(jìn)了UML1.0語(yǔ)義的清晰度,并融合進(jìn)了新合作者的貢獻(xiàn)。UML1.1在1997年被OMG采納。隨后UML的維護(hù)由OMGRevisionTaskForce(RTF)接管。RTF在1999年推出了UML1.3,目前將要推出UML2.0。UML的發(fā)展如圖1所示。UML為使用者提供了一個(gè)便于使用、表達(dá)豐富的可視的建模語(yǔ)言,使之能夠開發(fā)和交流有意義的模型。它也提供了擴(kuò)展和特化機(jī)制來(lái)擴(kuò)展它的核心概念。UML獨(dú)立于詳細(xì)的編程語(yǔ)言和開發(fā)過(guò)程,為了解建模語(yǔ)言提供了規(guī)范化的基礎(chǔ)。它激勵(lì)了OO工具市場(chǎng)的成長(zhǎng),并且支持諸如合作(Collaborations)、架構(gòu)(Frameworks)、模板(Patterns)和構(gòu)件(Components)等高層次的開發(fā)概念。UML與Booch,OMT,OOSE等其它先進(jìn)的OO方法具有相似的語(yǔ)義和定義,并且融合了UML合作者的意見(jiàn)和公眾的反饋。UML達(dá)到了兩個(gè)方面的統(tǒng)一:第一,它有效地結(jié)束了先前方法中建模語(yǔ)言之間許多通常不必要的差異;第二,而且也許更重要的是,它統(tǒng)一了不同系統(tǒng)間的觀點(diǎn)、開發(fā)階段(需求分析、設(shè)計(jì)和實(shí)現(xiàn))和內(nèi)部概念。因此可以預(yù)見(jiàn),UML將在全世界范圍內(nèi)被普遍使用,許多組織已將UML確定為他們的組織標(biāo)準(zhǔn),因?yàn)樗墙⒃诰哂兄鲗?dǎo)性的OO方法的建模語(yǔ)言基礎(chǔ)上的。2.2booch的概念UML的發(fā)展方向是簡(jiǎn)化和鞏固大量已經(jīng)存在的面向?qū)ο?OO)的建模方法,主要是集成Booch,OOSE和OMT的概念。UML的大部分基本概念和現(xiàn)有的OO方法的概念類似。正是這些特性使UML成為最受使用者青睞的建模語(yǔ)言。UML定義了九種圖,這些圖被用來(lái)建立系統(tǒng)的靜態(tài)(結(jié)構(gòu))和動(dòng)態(tài)(行為)模型。(1)系統(tǒng)的靜態(tài)配置圖UML的結(jié)構(gòu)圖用于描述建立系統(tǒng)模型時(shí)在問(wèn)題域中遇到的主要事物?！耦悎D(ClassDiagram)它包括一組類、界面、合作以及它們之間的關(guān)系,例如聯(lián)系、依賴和繼承。它被用來(lái)建立系統(tǒng)靜態(tài)模型,并在系統(tǒng)的整個(gè)生命周期中有效?！駥?duì)象圖(ObjectDiagram)一個(gè)對(duì)象就是一個(gè)類的實(shí)例。一個(gè)對(duì)象圖表示一組對(duì)象和它們之間在某一時(shí)刻的關(guān)系。它被用來(lái)為類圖中的實(shí)例建立模型?！駱?gòu)件圖(ComponentDiagram)構(gòu)件圖描述一組構(gòu)件和它們之間的關(guān)系。它被用來(lái)展示一個(gè)系統(tǒng)實(shí)現(xiàn)的靜態(tài)視圖。一個(gè)構(gòu)件可以是一個(gè)源代碼、一個(gè)二進(jìn)制或是一個(gè)可執(zhí)行單元?！衽渲脠D(DeploymentDiagram)配置圖由一組節(jié)點(diǎn)以及它們之間的關(guān)系組成。它被用來(lái)表示一個(gè)包括軟、硬件系統(tǒng)的物理結(jié)構(gòu)的靜態(tài)配置視圖。配置圖中的一個(gè)節(jié)點(diǎn)通常包含一個(gè)或多個(gè)構(gòu)件。(2)生成的背景圖UML行為圖用于描述建立系統(tǒng)的動(dòng)態(tài)模型。●用例圖(UseCaseDiagram)一個(gè)用例描述系統(tǒng)的功能,并且從用戶的角度指出每個(gè)功能的執(zhí)行者(Actor)。一個(gè)用例圖詳細(xì)描述一個(gè)系統(tǒng)或者系統(tǒng)的一部分的行為。●狀態(tài)圖(StatechartDiagram)狀態(tài)圖表現(xiàn)一個(gè)狀態(tài)機(jī)器,包括狀態(tài)(State)、轉(zhuǎn)移(Transition)、事件(Event)和活動(dòng)(Activity)。它被用來(lái)描述一個(gè)系統(tǒng)的動(dòng)態(tài)視圖,例如,一個(gè)對(duì)象所有可能的狀態(tài)和觸發(fā)狀態(tài)轉(zhuǎn)移的條件。它們?cè)诿枋鲆粋€(gè)界面、類或者合作的行為時(shí)尤其重要。狀態(tài)圖強(qiáng)調(diào)一個(gè)對(duì)象的事序行為?！窕顒?dòng)圖(ActivityDiagram)活動(dòng)圖描述一系列活動(dòng)、活動(dòng)之間的順序流動(dòng)或分支流動(dòng),以及活動(dòng)的發(fā)出或承受對(duì)象。它們?cè)跒橐粋€(gè)系統(tǒng)的功能建模時(shí)尤其重要?；顒?dòng)圖強(qiáng)調(diào)對(duì)象之間的控制流。●順序圖(SequenceDiagram)順序圖是一個(gè)交互圖,它強(qiáng)調(diào)消息(Message)的時(shí)間順序。一個(gè)順序圖描述一組對(duì)象以及由這些對(duì)象發(fā)送和接收的消息。這些對(duì)象通常是命名或匿名的類的實(shí)例,但也可以代表其它事物的實(shí)例,比如合作、構(gòu)件和節(jié)點(diǎn)?！窈献鲌D(CollaborationDiagram)合作圖也是一個(gè)交互圖,它強(qiáng)調(diào)接收和發(fā)送消息的對(duì)象的結(jié)構(gòu)(空間)組織。一個(gè)合作圖描述一組對(duì)象、這些對(duì)象之間的連接以及這些對(duì)象發(fā)送和接收的消息。狀態(tài)圖和活動(dòng)圖在語(yǔ)義上是等價(jià)的,也就是說(shuō)一個(gè)狀態(tài)圖和一個(gè)活動(dòng)圖可以互相轉(zhuǎn)換而不丟失任何信息。順序圖和合作圖之間也存在著類似的等價(jià)關(guān)系。根據(jù)圖在系統(tǒng)開發(fā)過(guò)程中不同階段的應(yīng)用,這九種圖還可以被分為以下五類:●用例圖●靜態(tài)圖類圖和對(duì)象圖●行為圖狀態(tài)圖和活動(dòng)圖●交互圖順序圖和合作圖●實(shí)現(xiàn)圖構(gòu)件圖和配置圖2.3非軟件系統(tǒng)建模UML是軟件開發(fā)中設(shè)計(jì)系統(tǒng)藍(lán)圖使用的標(biāo)準(zhǔn)語(yǔ)言。UML用可視化方法詳細(xì)描述和構(gòu)造一個(gè)軟件系統(tǒng)。事實(shí)上,它并不只局限在軟件建模,它還可以為非軟件系統(tǒng)建模,如法律系統(tǒng)的工作流程、健康保健系統(tǒng)的結(jié)構(gòu)與行為,以及硬件設(shè)計(jì)等。UML已經(jīng)有效地應(yīng)用在以下領(lǐng)域:●企業(yè)信息系統(tǒng)●銀行和金融服務(wù)●電訊●交通●國(guó)防/太空工業(yè)●零售●醫(yī)學(xué)電子數(shù)據(jù)處理●科研●基于Web的網(wǎng)絡(luò)服務(wù)3uml的基本過(guò)程UML在很大程度上是過(guò)程無(wú)關(guān)的建模語(yǔ)言,也就是說(shuō)它沒(méi)有局限于任何特定的軟件開發(fā)周期。為最大限度地發(fā)揮UML的優(yōu)勢(shì),我們應(yīng)該考慮的過(guò)程是:●用例驅(qū)動(dòng)(UseCaseDriven)●以架構(gòu)為中心(Architecture-centric)●迭代和遞增(IterativeandIncrement)這種用例驅(qū)動(dòng)、架構(gòu)為中心、迭代和遞增的過(guò)程可以分為四個(gè)階段:●開始(Inception)●詳細(xì)描述(Elaboration)●構(gòu)建(Construction)●移交(Transition)開始和詳細(xì)描述包括開發(fā)周期的工程活動(dòng);構(gòu)建和移交組成它的產(chǎn)品。在每個(gè)階段內(nèi)都有一些迭代。一個(gè)迭代代表一個(gè)完整的開發(fā)周期,從需求分析到實(shí)現(xiàn)和測(cè)試,結(jié)果是一個(gè)可執(zhí)行項(xiàng)目的發(fā)布。每個(gè)迭代都要通過(guò)各種各樣的工作流程,雖然每個(gè)工作流程有不同的側(cè)重點(diǎn),具體情況取決于不同階段。在開始階段,焦點(diǎn)是需求的獲得;在詳細(xì)描述階段,重點(diǎn)是轉(zhuǎn)向分析和設(shè)計(jì);在構(gòu)建階段,實(shí)現(xiàn)是中心任務(wù);移交階段的重心則在于配置。通常有九種工作流:●商業(yè)建模描述組織的結(jié)構(gòu)和動(dòng)態(tài)性質(zhì)?！裥枨笸ㄟ^(guò)基于用例的方法來(lái)描述需求?！穹治龊驮O(shè)計(jì)描述多種架構(gòu)視圖?！駥?shí)現(xiàn)軟件開發(fā)、單元測(cè)試和集成?！駵y(cè)試描述測(cè)試事例、步驟和錯(cuò)誤跟蹤方案?！衽渲每梢平坏南到y(tǒng)構(gòu)型?！駱?gòu)型管理控制項(xiàng)目組件的變化,并維持其一體性?！耥?xiàng)目管理描述采用迭代方法的不同工作策略。●環(huán)境包括開發(fā)系統(tǒng)必要的各種基礎(chǔ)設(shè)施。在以上討論的內(nèi)容中,每個(gè)工作流程中最重要的是一系列應(yīng)用UML建立的模型。為了對(duì)在軟件系統(tǒng)開發(fā)中應(yīng)用UML有一個(gè)直觀而清晰的了解,我們考慮一個(gè)非常簡(jiǎn)單、理想化的軟件開發(fā)周期,包括三個(gè)階段:需求、分析和設(shè)計(jì)、實(shí)現(xiàn)。圖2表示了UML的圖和各種圖所應(yīng)用的階段之間的關(guān)系。在下面的部分中,我們將通過(guò)一個(gè)超級(jí)市場(chǎng)銷售管理系統(tǒng)來(lái)描述UML的建模過(guò)程。3.1上級(jí)系統(tǒng)功能需求的內(nèi)容我們以一個(gè)超級(jí)市場(chǎng)管理系統(tǒng)的前臺(tái)銷售分系統(tǒng)為例,這個(gè)分系統(tǒng)被簡(jiǎn)化以最基本的方式處理銷售業(yè)務(wù)。這個(gè)系統(tǒng)的功能需求如下:●為顧客選購(gòu)的商品計(jì)價(jià)、收費(fèi)、打印清單?！裼涗浢糠N商品的編號(hào)、單價(jià)和現(xiàn)有數(shù)量?！駧椭碳艺页瞿姆N商品將脫銷,從而及時(shí)補(bǔ)充貨源?！耠S時(shí)按上級(jí)系統(tǒng)的要求報(bào)告當(dāng)前的款貨數(shù)量、增減商品的種類或修改商品定價(jià)?！窠唤影鄷r(shí)結(jié)算貨款數(shù)目和商品數(shù)目。由于系統(tǒng)較小,我們省略了構(gòu)件圖和配置圖。3.2用例維護(hù)模擬系統(tǒng)的管理圖3表示用例圖,它包括一系列用例和從系統(tǒng)中抽象出的執(zhí)行者。圍繞系統(tǒng)的售貨員、采購(gòu)員、管理者是人在與系統(tǒng)交互中扮演的執(zhí)行者。用例售貨、訂貨和供貨,以及維護(hù)模擬系統(tǒng)的功能需求。用例價(jià)格更新、確定特價(jià)商品、商品種類增刪包含在用例維護(hù)里。用例和執(zhí)行者之間的聯(lián)系表示了執(zhí)行者對(duì)用例的責(zé)任。例如,執(zhí)行者售貨員負(fù)責(zé)賣出商品,這是由用例售貨所描述的功能。3.3銷售事件的記錄是進(jìn)路一圖4表示類圖,它包括一組由所討論的系統(tǒng)中抽象出的類和它們之間的聯(lián)系。從圖4左上面開始,你可以找到名為收款機(jī)、銷售事件和賬冊(cè)的類。類收款機(jī)的屬性本班收款員表示哪一個(gè)收款員在收款機(jī)上工作;開始時(shí)間和結(jié)束時(shí)間規(guī)定了收款員什么時(shí)候開始和結(jié)束工作。類收款機(jī)有三個(gè)操作:①登錄,接收收款員的登記,并且使他/她能開始工作;②售貨,計(jì)算金額并收錢;③結(jié)賬,在收款員下班或交班時(shí)結(jié)算本班的賬目。類銷售事件有三個(gè)屬性:①收款人,記錄新的銷售事件是在哪個(gè)收款機(jī)上由哪個(gè)收款員處理;②購(gòu)物清單,記錄顧客所購(gòu)商品的編號(hào)、名稱、數(shù)量和價(jià)格;③應(yīng)收款,表示發(fā)生在一次購(gòu)買事件中累加起來(lái)的總錢數(shù)。操作計(jì)價(jià)逐條記錄商品清單,并累計(jì)應(yīng)收款數(shù)。入賬將本次銷售事件的信息加入賬冊(cè)。賬冊(cè)的屬性銷售事件表和收入累計(jì)記錄所有的銷售事件和一個(gè)收款員在一天內(nèi)的銷售總量。前班節(jié)余、上交款和本班節(jié)余描述一次交接班的信息。操作接班記錄接收前一班收款員的貨款;報(bào)賬交班是向上級(jí)系統(tǒng)報(bào)賬,記錄上交的和留給下一班收款員的款數(shù)。商品的屬性包括編號(hào)、名稱、單價(jià)、數(shù)量和下限。下限描述什么時(shí)候一種商品的架上數(shù)量小于這個(gè)值,就提醒供貨員補(bǔ)充。商品有五種操作:(1)檢索。當(dāng)商品從收款機(jī)得到信息后查找將被售出的商品。(2)種類增刪。修改商品的目錄。(3)售出。從架上數(shù)量減去一種已售出商品的數(shù)量。(4)補(bǔ)充。加上被補(bǔ)充的商品的數(shù)量。(5)價(jià)格更新。改變商品的價(jià)格。供貨員的屬性缺貨登記表用來(lái)登記缺貨商品。供貨員有兩個(gè)操作:缺貨登記,輸入缺貨商品的編號(hào)和名稱到缺貨登記表;供貨,供貨員補(bǔ)充商品后向商品發(fā)送消息以更改數(shù)量,并刪除缺貨登記表中相應(yīng)的條目。類特價(jià)商品和計(jì)量商品是商品類的子類,表示兩個(gè)子類繼承了商品的所有屬性和操作,并且又有自己特殊的屬性和操作。收款機(jī)和銷售事件之間有一種聯(lián)系,描述收款機(jī)處理銷售事件。而且,每個(gè)收款機(jī)還可以處理任何數(shù)目的銷售事件,但是一個(gè)銷售事件只能由一個(gè)收款機(jī)處理。商品和供貨員之間也有聯(lián)系,描述供貨員為超級(jí)市場(chǎng)提供商品。而且一個(gè)供貨員可提供一種或多種商品,但是一種商品只能由一個(gè)供貨員來(lái)提供。在賬冊(cè)和銷售事件之間有一種組成關(guān)系,它表示賬冊(cè)由許多銷售事件組成。3.4重要屬性約束條件圖5表示對(duì)象圖,它包含一系列的對(duì)象和它們之間的聯(lián)系。圖5中只表示了每個(gè)對(duì)象的重要屬性。為了簡(jiǎn)化,雖然類銷售事件的很多對(duì)象可能和類收款機(jī)的一個(gè)對(duì)象相關(guān),但我們只畫出它們之間的一個(gè)一對(duì)二聯(lián)系,沒(méi)有給出對(duì)象圖中其它聯(lián)系的多重性。3.5收款機(jī)向供應(yīng)商發(fā)送消息請(qǐng)求售價(jià)圖6表示了一個(gè)順序圖,描述了處理一個(gè)銷售事件的控制流。流程從收款機(jī)對(duì)收款員的指令響應(yīng)開始。首先,收款機(jī)向商品發(fā)送消息請(qǐng)求檢索操作來(lái)查找將被出售的商品;然后發(fā)送消息請(qǐng)求售出操作。如果這種商品的數(shù)量少于下限,則向供貨員發(fā)送消息進(jìn)行缺貨登記。收款機(jī)的售出操作將向銷售事件發(fā)送信息請(qǐng)求銷售計(jì)價(jià)和入賬操作。最后,銷售事件發(fā)送信息給賬冊(cè)中的記賬,并且控制流程返回收款機(jī)等待下一次銷售。3.6合作協(xié)議眾所周知,合作圖在語(yǔ)義上等同于順序圖。圖7表示合作圖,它詳細(xì)描述了一個(gè)銷售時(shí)間過(guò)程中的控制流程,并強(qiáng)調(diào)這些對(duì)象之間的結(jié)構(gòu)關(guān)系。3.7收款機(jī)對(duì)象狀態(tài)圖8給出了對(duì)象收款機(jī)的狀態(tài)圖。限于