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