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

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