【正文】 執(zhí)行步驟。其模型如圖37：圖37 動(dòng)態(tài)資源使用模型[27] 資源管理包(ResourceManagement)定義了如何建模資源管理服務(wù)。資源代理(resource broker)按訪問(wèn)控制策略分配和回收資源實(shí)例（或服務(wù)）給客戶。資源管理器(resource manager)按資源控制策略創(chuàng)建和維護(hù)資源。如緩沖池管理器從堆中創(chuàng)建緩沖集合，一旦創(chuàng)建并初始化，這些資源交給資源代理，資源代理可以資源其分配給客戶和從客戶回收。其模型如圖38:圖38 資源管理模型[27] 資源類型包(ResourceTypes)對(duì)實(shí)時(shí)系統(tǒng)建模重要的資源分類，并說(shuō)明了資源的類型。如圖39:圖39：資源類型模型[27] 實(shí)現(xiàn)模型包(RealizationModel)說(shuō)明了細(xì)化分層(refinement layering)和實(shí)現(xiàn)分層(realization layering)。細(xì)化分層中每層都定義了一個(gè)系統(tǒng)的完整模型，只是抽象級(jí)別不同。實(shí)現(xiàn)分層每層都包含系統(tǒng)的不同信息，上層需要下層的支持，而下層可以獨(dú)立于上層，全部層的聚集才能表示一個(gè)系統(tǒng)。 通用時(shí)間建模 本節(jié)描述了實(shí)時(shí)軟件系統(tǒng)中時(shí)間和與時(shí)間有關(guān)的機(jī)制的框架。與上節(jié)一樣，本節(jié)只介紹領(lǐng)域視角，時(shí)間領(lǐng)域模型的模塊如圖310：圖310 時(shí)間領(lǐng)域模型的模塊[27]時(shí)間模型(TimeModel)表達(dá)了時(shí)間和時(shí)間值的概念，如圖311圖311 基本時(shí)間模型[27] 物理時(shí)間是單調(diào)增加的，物理時(shí)間實(shí)例是全序和緊密相連的（在任意兩個(gè)實(shí)例間至少有一個(gè)實(shí)例）。物理時(shí)間用一個(gè)引用時(shí)鐘測(cè)量，測(cè)量值用TimeValue表示。持續(xù)時(shí)間是兩個(gè)時(shí)間點(diǎn)的間隔，用TimeInterval表示測(cè)量值。 時(shí)間機(jī)制(TimingMechanisms)測(cè)量時(shí)間的前進(jìn)和由此產(chǎn)生的事件，它包括定時(shí)器和時(shí)鐘。到達(dá)指定時(shí)間時(shí)，定時(shí)器可以產(chǎn)生超時(shí)事件。時(shí)鐘周期性的產(chǎn)生時(shí)鐘滴答事件，這可以產(chǎn)生時(shí)鐘中斷。圖212顯示了時(shí)間機(jī)制和相關(guān)概念：圖212 時(shí)間機(jī)制概念[27] 時(shí)間事件模型(TimedEvents)描述了事件發(fā)生與時(shí)間的關(guān)聯(lián)，事件發(fā)生時(shí)會(huì)產(chǎn)生一個(gè)激勵(lì)，模型引入了帶時(shí)間的激勵(lì)(TimedStimulus)，這個(gè)激勵(lì)至少與一個(gè)時(shí)間戳相連。如圖213:圖213 時(shí)間激勵(lì)概念[27] 時(shí)間服務(wù)模型(TimingServices)用來(lái)建模時(shí)間服務(wù)。時(shí)間服務(wù)可以是操作系統(tǒng)接口的一部分。時(shí)間服務(wù)是時(shí)鐘和定時(shí)器的工廠，它根據(jù)請(qǐng)求創(chuàng)建并提供這些時(shí)間機(jī)制。如圖214:圖214 時(shí)間服務(wù)概念[27] 實(shí)時(shí)系統(tǒng)建模工具 軟件開(kāi)發(fā)過(guò)程如果有工具支持，會(huì)提高軟件開(kāi)發(fā)效率和提高軟件的質(zhì)量。實(shí)時(shí)系統(tǒng)UML建模工具主要有：ARTiSAN的RealTime Studio，IBM的Rational Rose RealTime，ILogix的Rhapsody，Telelogic的Tau toolsuit。第四章 面向方面建模如果僅在程序代碼上分離關(guān)注點(diǎn)，分析與設(shè)計(jì)等階段仍采用傳統(tǒng)的建模方法，會(huì)降低整個(gè)開(kāi)發(fā)過(guò)程的可追蹤性，即分析設(shè)計(jì)的單元并不能很好對(duì)應(yīng)到實(shí)現(xiàn)單元上。所以面向社區(qū)開(kāi)始研究如何在軟件開(kāi)發(fā)的整個(gè)階段引入面向方面技術(shù)，在整個(gè)過(guò)程中分離關(guān)注點(diǎn)。統(tǒng)一建模語(yǔ)言(Unified Modeling Language,UML)是一種對(duì)軟件系統(tǒng)制品(artifact)進(jìn)行詳述、可視化、構(gòu)造和文檔化的圖形語(yǔ)言。UML廣泛用于面向?qū)ο笙到y(tǒng)的建模。UML由對(duì)象管理組織(Object Management Group,OMG)管理。,[30]，[31,32]正等待被通過(guò)。UML是可擴(kuò)展的，這樣可以將其用于不同領(lǐng)域的建模。對(duì)面向方面建模的研究主要集中在如何擴(kuò)展使其支持面向方面領(lǐng)域。 UML的擴(kuò)展機(jī)制 UML的擴(kuò)展機(jī)制包括構(gòu)造型(stereotype) 、標(biāo)記值(tagged value) 和約束(constraint)。 UML允許繼承原有構(gòu)造塊來(lái)生成新的構(gòu)造塊，這些新的構(gòu)造快就是構(gòu)造型。新的構(gòu)造塊與基構(gòu)造塊有同樣的結(jié)構(gòu)，但是可以有不同的語(yǔ)義、不同的約束、不同的標(biāo)記值。每個(gè)構(gòu)造型對(duì)應(yīng)UML元模型中的一個(gè)元類。在圖形上，構(gòu)造型可以表示為用書名號(hào)括起來(lái)的名稱，如aspect，也可以為構(gòu)造型定義一個(gè)新的圖標(biāo)。 標(biāo)記值可以為模型元素添加新的特征，如軟件的版本信息。標(biāo)記值可以表示為{名稱＝值}。 約束擴(kuò)展了建模元素的語(yǔ)義，可以增加新的規(guī)則或修改語(yǔ)義。約束用“{…}”括起來(lái)的串表示。 表示連接點(diǎn) 連接點(diǎn)是面向方面中重要的概念，它定義了關(guān)注點(diǎn)可以橫切的點(diǎn)，設(shè)計(jì)者的一個(gè)重要任務(wù)就是明確關(guān)注點(diǎn)在哪些連接點(diǎn)橫切。面向方面建模語(yǔ)言的主要任務(wù)之一就是提供合適的方式來(lái)表達(dá)連接點(diǎn)。但是不同的面向方面編程技術(shù)采用了不同的連接點(diǎn)模型。[33]試圖用統(tǒng)一的方式表達(dá)這些不同的連接點(diǎn)模型。 結(jié)構(gòu)橫切影響給定模型的類型結(jié)構(gòu)，如AspectJ的類型間聲明（引入）。行為橫切影響類元已存在的行為，如AspectJ的通知。[33]在UML的元層次(metalevel)上，用元類表示結(jié)構(gòu)橫切的連接點(diǎn)，用鏈接(link)代表行為橫切的連接點(diǎn)。用這種方法，AspectJ有結(jié)構(gòu)橫切和行為橫切；組合過(guò)濾器只有行為橫切，因?yàn)樗倪B接點(diǎn)是出入的消息；Hyper/J有結(jié)構(gòu)橫切和行為橫切，因?yàn)樗倪B接點(diǎn)包括類、接口、方法和成員變量，它們由組合規(guī)則聯(lián)系在一起；自適應(yīng)編程只有結(jié)構(gòu)橫切，因?yàn)樗倪B接點(diǎn)為遍歷策略，訪問(wèn)函數(shù)沿著遍歷策略僅改變類元的接口和不改變類元已存在的行為。在模型層次上(modellevel)上，連接點(diǎn)指示圖(Join Point Designation Diagram)指示方面模型中用到的連接點(diǎn)，連接點(diǎn)表示圖(Join Point Indication Diagram)表明基模型中被橫切的連接點(diǎn)。 用況（use case）是對(duì)一組動(dòng)作序列的描述，系統(tǒng)執(zhí)行這些動(dòng)作將產(chǎn)生對(duì)特定的參與者有價(jià)值而且可觀察的結(jié)果[3]。用況有效地描述了系統(tǒng)的需求。在用況驅(qū)動(dòng)開(kāi)發(fā)中，分析、設(shè)計(jì)和測(cè)試中用況具有模塊化，但是用況的實(shí)現(xiàn)就不具有模塊化。某個(gè)用況可能由多個(gè)組件實(shí)現(xiàn)，某個(gè)組件也可能實(shí)現(xiàn)多個(gè)用況，造成了代碼的分散和糾纏。這是由于組件描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)，但并沒(méi)有描述這些結(jié)構(gòu)協(xié)作所產(chǎn)生的行為(由用況描述),即組件的模塊化并不代表用況的模塊化。這樣降低了用況的可追蹤性，當(dāng)需求變化時(shí)，易產(chǎn)生需求與實(shí)現(xiàn)的不一致，并降低了系統(tǒng)的可演進(jìn)性和可維護(hù)性等一系列問(wèn)題。但是如果將用況實(shí)現(xiàn)為一個(gè)模塊，就可以解決這些問(wèn)題，這樣在整個(gè)用況驅(qū)動(dòng)開(kāi)發(fā)過(guò)程中，從需求到代碼，用況都保持模塊化。 用況的延伸(extend)關(guān)系說(shuō)明了基本用況的行為可被延伸用況的行為延伸，但是傳統(tǒng)的編程語(yǔ)言并不支持這種延伸關(guān)系，所以延伸用況不能與基本用況分離，造成了用況的實(shí)現(xiàn)不具有模塊化。而AOP可以解決這個(gè)問(wèn)題。在AOP中，將基本用況里的延伸點(diǎn)(extension point)看作連接點(diǎn)(join point)，將延伸用況的行為當(dāng)作通知(advice)，延伸用況可實(shí)現(xiàn)為一個(gè)方面[35]。這樣分離了延伸用況與基本用況，延伸用況可以在連接點(diǎn)插入到基本用況中而改變基本用況的行為。[36]中用兩個(gè)例子詳細(xì)描述了這種實(shí)現(xiàn)方法。 還有一些用況并不具有延伸關(guān)系，它們是對(duì)等的，這些對(duì)等用況(peer use cases)可能有重疊的行為，并不能用解決延伸用況的方法組合這些用況，多維關(guān)注點(diǎn)分離和HyperJ允許對(duì)等用況的分離。 由于面向方面是一個(gè)新的編程典范，而UML主要應(yīng)用于面向?qū)ο笙到y(tǒng)的建模，用UML進(jìn)行面向方面的建模就要使用合適的圖符來(lái)表達(dá)方面概念，也要給這些圖符賦予正確的語(yǔ)義。這不但需要正確表示面向方面中的元素，而且還要能用清晰的方式表達(dá)方面與基本類（核心類）之間的關(guān)系。 由于面向方面建模是一個(gè)比較新的領(lǐng)域，實(shí)際上面向方面編程的方法也還在發(fā)展中，所以并沒(méi)有形成統(tǒng)一的建模方法。為了能從整體上了解面向方面社區(qū)在建模領(lǐng)域的研究，本節(jié)比較全面的介紹了各種建模方法，可以根據(jù)參考文獻(xiàn)找到這些方法的詳細(xì)資料。 [37]較早提出了擴(kuò)展UML支持面向方面設(shè)計(jì)，它新加入了繼承自類元的元素“aspect”，用來(lái)表示方面，并用UML已有的realize關(guān)系來(lái)表示方面與基本類間的關(guān)系，也提出了基于XML的方面描述語(yǔ)言UML/a,這樣允許開(kāi)發(fā)工具與方面編織器交換方面模型信息。這個(gè)方法僅表達(dá)了引入的概念，并沒(méi)有表達(dá)通知的能力。 組合模式(position pattern)可以分離和設(shè)計(jì)可重用的橫切行為，它基于面向主題設(shè)計(jì)模型(subjectoriented design model)和UML的模板(template)。[38]中介紹了組合模式可以設(shè)計(jì)AspectJ的程序。 [39]從用AspectJ寫的代碼開(kāi)始，試圖用標(biāo)準(zhǔn)UML元素建模，然后分析其不足，最后提出擴(kuò)展UML來(lái)克服這些不足。 [40]擴(kuò)展UML表示AspectJ中所有的概念，將連接點(diǎn)建模為鏈接，將切入點(diǎn)和通知建模為某個(gè)類元的特征(feature),將引入建模為協(xié)作模板，將方面建模為某個(gè)類元。它用用況和協(xié)作來(lái)建?？椚霗C(jī)制。[41]提出了一個(gè)使用UML表示的面向方面開(kāi)發(fā)的方法學(xué)，也提出了一個(gè)方面約束語(yǔ)言ACL(Aspect Constraint Language)來(lái)約束方面的使用，這樣允許控制開(kāi)發(fā)來(lái)避免出現(xiàn)不希望的后果。[42]中提出在UML中加入兩個(gè)新的元素，一個(gè)代表連接點(diǎn)（join point）的概念，方面在連接點(diǎn)橫切功能組件，一個(gè)代表方面，并建議把方面的功能封裝在一個(gè)UML包中來(lái)維護(hù)關(guān)注點(diǎn)分離。 [43]提出了AspectJ的完整元模型，并提出了三個(gè)視圖：方面視圖表示方面的設(shè)計(jì)和重構(gòu)，橫切視圖表示關(guān)注點(diǎn)分離和方面分析，目標(biāo)視圖表示方面的測(cè)試和整合。 [44]中研究了如何將行為方面加入到活動(dòng)圖中。 [45]中研究了如何用方面來(lái)模塊化Statecharts。 [46]討論了應(yīng)增加建模面向方面的UML框架集。 面向方面軟件協(xié)會(huì)(AspectOriented Software Association)是面向方面軟件開(kāi)發(fā)會(huì)議的主要發(fā)起者，它的網(wǎng)站[47]提供了大量面向方面軟件開(kāi)發(fā)的資源。第五章 實(shí)時(shí)方面建模 本章提出了一個(gè)新的擴(kuò)展UML支持面向方面建模的方法，這個(gè)方法完全支持AspectJ和AspectC++元素的表達(dá)。并結(jié)合UML圖分析這種方法如何用在實(shí)時(shí)系統(tǒng)開(kāi)發(fā)中。 AOP元素表示 本節(jié)中AOP的概念可以參考第二章。 AspectC++有兩種切入點(diǎn)：名字切入點(diǎn)和代碼切入點(diǎn)。名字切入點(diǎn)是類型、屬性、函數(shù)、變量和名字空間的名字，其中類和名字空間可用于引入，即結(jié)構(gòu)橫切。代碼切入點(diǎn)調(diào)用AspectC++定義的函數(shù)且以名字切入點(diǎn)為參數(shù)來(lái)形成，與AspectJ中的切入點(diǎn)一樣，用于行為橫切。而在AspectJ中，類型間聲明并沒(méi)有用到名字切入點(diǎn)概念，雖然這時(shí)用到的也是類型名。 在UML建模時(shí)，將切入點(diǎn)作為特征的子類，因?yàn)樵赨ML規(guī)范中，特征的語(yǔ)義是作為類元的一部分[34]，本文將方面建模為類元的子類，這樣切入點(diǎn)就是方面的一部分。切入點(diǎn)的語(yǔ)義是組件里方面可以干涉的一系列點(diǎn)，它包括了AspectC++中的名字切入點(diǎn)和代碼切入點(diǎn)，也包括了AspectJ中的切入點(diǎn)和類型間聲明時(shí)的類型名，即它用于所有結(jié)構(gòu)橫切和行為橫切中。 切入點(diǎn)的組成部分為：名稱；參數(shù)列表；可見(jiàn)性；多態(tài)性；切入點(diǎn)表達(dá)式。其中切入點(diǎn)表達(dá)式用標(biāo)記值pce(pointcut expression)表示。切入點(diǎn)用構(gòu)造型pointcut表示，其語(yǔ)法為：pointcut[可見(jiàn)性]名字（參數(shù)列表）{pce=切入點(diǎn)表達(dá)式}。用斜體來(lái)表明這個(gè)切入點(diǎn)是抽象的。切入點(diǎn)的構(gòu)造型圖符為圖51：圖51 切入點(diǎn)圖符 切入點(diǎn)圖符顯示了一個(gè)切入點(diǎn)由多個(gè)子集構(gòu)成。這主要是為了清晰描述多個(gè)方面在相同的連接點(diǎn)橫切組件。下面會(huì)有例子詳述其用法。 在AspectC++中，同一個(gè)advice關(guān)鍵字既用于結(jié)構(gòu)橫切（即引入）也用于行為橫切，而在AspectJ中通知的概念僅與行為橫切相關(guān)，結(jié)構(gòu)橫切用了類型間聲明。 在用UML建模時(shí)，將它們相同對(duì)待，因?yàn)樗鼈兌急硎緳M切了組件，統(tǒng)一用通知表示。由于通知是方面的一部分，所以將通知作為特征的子類。并用構(gòu)造型advice表示。在AspectJ或AspectC++中，沒(méi)有給通知命名，但在順序圖等行為圖中，消息傳遞要用到消息名，所以在用advice建模行為橫切時(shí)，給通知加了一個(gè)偽名。用標(biāo)記值pce表示通知要橫切的點(diǎn)。通知的語(yǔ)法為：advice[可見(jiàn)性]通知規(guī)范集合{pce=切入點(diǎn)表達(dá)式}。其中通知規(guī)范集合為:(1) 對(duì)于行為橫切：“偽名 通知行為說(shuō)明”。其中通知行為說(shuō)明為before、after、after returning、after throwing、around。(2) 對(duì)于引入成員變量：[可見(jiàn)性]名字[多重性]：[類型][＝初始值]。與UML中屬性的定義一樣。(3) 對(duì)于引入操作：[可見(jiàn)性]名字（參數(shù)）:[返回值]。與UML中操作的定義一樣。(4) 對(duì)于引入要繼承的基類：[可見(jiàn)性]extends:基類名。(5) 對(duì)于引入要實(shí)現(xiàn)的接口：implements:接口名。(6) 對(duì)于說(shuō)明在切入點(diǎn)各個(gè)方面的橫切順序:precedence:方面列表。對(duì)于成員引入，如果寫在受影響的組件里，則在引入成員的下面用標(biāo)記值{introducedBy=方面名}說(shuō)明這個(gè)成員的是由指定方面引入的。對(duì)于引入的基類和接口，如果要在類系上顯示時(shí)，要在繼承和實(shí)現(xiàn)關(guān)系上用標(biāo)記值{introducedBy=方面名}說(shuō)明這個(gè)關(guān)系是由指定方面引入的。 表示方面 AspectJ與AspectC++中方面的語(yǔ)義基本相同，不同點(diǎn)來(lái)自于Java于C++之間固有的不同。 在用UML建模時(shí)，統(tǒng)一用方面表示，并且它是類的子類，因?yàn)榉矫媾c類的結(jié)構(gòu)很相似，它封裝了類里所有的成員，還模塊化了橫切關(guān)注點(diǎn)。方面用構(gòu)造型aspect表示，圖符采用類的圖符。方面除擁有類的元素、切入點(diǎn)和通知外，還包括：B