氣象監(jiān)測站題庫

數(shù)據(jù)采集一一氣象監(jiān)測站11.1初始我們的氣象監(jiān)測系統(tǒng)是一個簡單得多應(yīng)用，僅僅包含少數(shù)的類。咋一看，面向?qū)ο蟮男率謧兛赡芎芟氩捎靡环N本質(zhì)上非面向?qū)ο蟮姆绞絹斫鉀Q這個問題，即考慮數(shù)據(jù)流和不同的輸入/輸出之間的映射。然而，正如我們將要看到的那樣，即使是像這樣小的一個系統(tǒng)，也可以很好地借鑒面向?qū)ο蠹軜?gòu)，并在開發(fā)過程中展示出一些面向?qū)ο箝_發(fā)過程的基本原則。11.1.1氣象監(jiān)測站需求本系統(tǒng)應(yīng)提供各種氣象條件的自動檢測。具體地說，它必須測量：a、風(fēng)速b、溫度c、氣壓d、濕度系統(tǒng)也應(yīng)提供一下導(dǎo)出的測量數(shù)據(jù)：a、風(fēng)濕度b、露點溫度c、溫度趨勢d、氣壓趨勢系統(tǒng)應(yīng)有一個決定當前時間和日期的方法，以便它能夠報告過去24小時內(nèi)4種主要測量數(shù)據(jù)的最高值和最低值。系統(tǒng)應(yīng)有一個顯示屏，不斷顯示所有8個主要數(shù)據(jù)和導(dǎo)出數(shù)據(jù)，同時顯示出當前的時間和日期。用戶可以通過小鍵盤來指揮系統(tǒng)，讓它顯示任意一個主要測量數(shù)據(jù)在24小時內(nèi)的最高值和最低值，以及出現(xiàn)這些值的時間。系統(tǒng)應(yīng)該允許用戶根據(jù)已知的值來校正傳感器，并允許設(shè)置當前的時間和日期。11.1.2定義問題的邊界分析時首先要考慮的是軟件運行的硬件平臺，這是系統(tǒng)分析的因有問題，涉及到制造能力和成本問題，這些問題遠遠超出本書的討論范圍。為了限定問題邊界，以便展示軟件分析設(shè)計問題，我們做以下戰(zhàn)略性的假定：a、處理器（即CPU采用PC或手持式備式的。b、時間和日期由一個時鐘提供。c、通過遠程的傳感器來測量溫度、氣壓和濕度。d、用一個帶有風(fēng)向標（能感知16個方向中任一方向的風(fēng)）和一些風(fēng)杯（推動計數(shù)器對回轉(zhuǎn)進行計數(shù)）的標注來測量風(fēng)速和風(fēng)向。e、通過小鍵盤提供用戶輸入。f、顯木器是一一個現(xiàn)貨LCD圖形設(shè)備。g、計算機每1/60秒有一次定時器中斷。圖11-1提供一個部署圖來說明這個硬件平臺在這個問題上，我們已經(jīng)選擇放棄一些俄硬件，這樣就可以更好的聚焦在系統(tǒng)軟件上。顯然，去掉一些硬件（如去掉一些用戶輸入和圖形設(shè)備的硬件）就可能需要更多的軟件，但在這個特定的應(yīng)用中，改變硬件/軟件的界限對我們的面向?qū)ο蠹軜?gòu)來說，在很大的是無足輕重的。確實，面向?qū)ο笙到y(tǒng)的特征之一就是傾向于用問題的詞匯說話，從而描繪出一個與問題的關(guān)鍵實體的抽象相并行的虛擬機。改變系統(tǒng)硬件得到細節(jié)僅僅影響對系統(tǒng)底層的抽象。通過圍繞每一個這樣的接口包裝一個類，硬件接口的細節(jié)很容易從軟件抽象隔離。例如，可以設(shè)計出一個簡單的類來訪問當前的日期。首先對這個隔離類進行分析，考慮這個抽象應(yīng)當扮演的角色和承擔(dān)的職責(zé)。這樣，我們就可以決定，這個類負責(zé)追蹤當前的日期和時間，包括時、分秒、月、日和年。我們的分析可能會決定將這些職責(zé)轉(zhuǎn)變?yōu)檫B個服務(wù)，分別表示為操作currentTime和currentDate。操作currentTime返回以下格式的字符串：13:56:42表示當前的時、分和秒操作currentDate返回以下格式的字符串：6-10-93表示當前的月、日和年。進一步分析可以得出一個更加完善的抽象，允許客戶選擇12小時制或24小時制的時間格式，我們可以為這種抽象提供一個另外的更改操作setFormat。通過從公開客戶的視角來指定這個抽象行為，我們將接口和實現(xiàn)做了清晰的分離?；镜乃枷胧菍γ恳粋€類建立外部視圖，就好像已經(jīng)完全控制了它下面的平臺，然后將類的實現(xiàn)作為通向它內(nèi)部視圖的橋梁。這樣，在系統(tǒng)硬件/軟件邊界處的類的實現(xiàn)就將抽象的外部視圖同它下面的平臺銜接在一起，下面的平臺是受系統(tǒng)決策約束的，而系統(tǒng)的決策并不掌握在軟件工程師的手中。當然，抽象的內(nèi)外視圖之間的鴻溝并非大的需要一個厚重而低效的實現(xiàn)來粘合它們。因此，時間和日期類的職責(zé)必須包括設(shè)定時間和日期。完成這個職責(zé)需要新的服務(wù)集來進行，我們通過以下操作提供：setHour、setMinute、setSecond、setDay、setMonth和setYear。下面總結(jié)以下時間/日期類的抽象。類名：TimeDate職責(zé)：跟蹤當前的時間和日期。操作：currentTimecurrentDatesetFormatsetHoursetMinutesetSecondsetMonth

setYear屬性:timedate這個類的實例有動態(tài)的生命周期，這一點可以從如圖11-2所示的狀態(tài)轉(zhuǎn)換圖中看出?？梢钥吹?，初始化之后，類的實例重新設(shè)置它的time和date屬性，然后無條件地進入Running狀態(tài)，運行24-hourmode狀態(tài)下。一旦在Running狀態(tài)，setFormat操作可以將對象的運行模式在12-hourmod褥口24-hourmode之間切換。無論對象處于哪種嵌套狀態(tài)，設(shè)置時間內(nèi)和日期都會引起對象重新規(guī)范化它的屬性。同樣地，請求時間或日期也會引起對象計算一個新的字符串值。圖對上面4個具體類(TemperatureSensor、PressureSensorHumiditySensor和WindspeesdSensor)進行快速的領(lǐng)域分析，可以揭示另一個共同的行為：這些類都可以根據(jù)兩個已知的數(shù)據(jù)點，用線性內(nèi)插法來校正自己。我們不是將這個行為復(fù)制到4個類中，而是創(chuàng)建一個更高一級的超類CalibratingSensor來負責(zé)這個行為，它的規(guī)格說明如下。類名:類名:CalibratingSensor職責(zé)：給定兩個已知數(shù)據(jù)點，提供線性插值的值。操作：currentvalueseHighValuesetLowValueCalibratingSensor是HistoricalSensor的直接超類。最后一個具體傳感器一風(fēng)向傳感器有點不同，它既不需要校正也不需要報告歷史趨勢，這個實體的抽象可以表示為下面的規(guī)格說明。類名:windDirectionSensor職責(zé)：跟蹤當前風(fēng)向，表示為羅盤圖上的點。操作：currenDirection屬性:direction為了統(tǒng)一傳感器抽象，我們創(chuàng)建抽象基類Sendor,它是類windDirectionSensor和類Calibratingsensor的直接超類。圖11-4說明了這個完整的層次結(jié)構(gòu)。雖然用于用戶輸入的小鍵盤抽象不是傳感器類層的一部分，但是它有一個簡單的規(guī)格說明。圖類名:Keypad職責(zé)：跟蹤最近一次用戶輸入。操作:lastKeyPress屬性:key值得注意的是，這個類對任何特定鍵的含義一無所知，它的實例僅僅知道幾個鍵申的一個被按下。我們將解釋這些鍵的含義的職責(zé)委托給不同的類，我們將確定什么時候把這些具體的邊界類應(yīng)用到場景中。LCDDevice類的抽象可以將軟件與可能使用的特定硬件隔離。為了解除軟件與可能使用的特定圖形硬件之間的藕合，分析促使我們?nèi)プ鰵庀蟊O(jiān)測系統(tǒng)的一些常用顯示畫面的原型，然后確定界面需求。圖11-5提供了這樣一個原型。在這個原型中，我們省略了風(fēng)冷度和露點的顯示需求，也省略一些細、么例如，如何顯示主要測量數(shù)據(jù)在過去24小時內(nèi)的最高值或最低值。但是，出現(xiàn)了某些模式：我們只需要顯示文本（以兩種不同的大小和兩種不同的風(fēng)格）、圓和線（粗細不同）。此外，我們還注意到，顯示的一些元素是靜態(tài)的（如TEMP標簽），另外一些元素是動態(tài)的（如風(fēng)向）。我們選擇通過軟件來顯示這些靜態(tài)和動態(tài)元素。這樣，LCD自身就不需要特別的標簽，從而減輕硬件的負擔(dān)，但同時也會稍微增加軟件的工作量。圖可以將這些需求轉(zhuǎn)換成以下的類規(guī)格說明。類名:LCDDevice職責(zé)：管理LC陽備，為顯示某些圖形元素提供服務(wù)。操作：drawTeXtdrawLlnedrawClrclesetTeXtSIzesetTeXtStylesePenSIze正像類Keypad一樣，類LcDDevice并不知道它所操縱的元素的含義。該類的實例僅僅知道怎樣顯示文字和直線，而不知道這些圖形代表什么。這種關(guān)注分離留給我們松藕合的抽象（這正是我們想要的），但是這需要我們找到一個代理，負責(zé)協(xié)調(diào)原始的傳感器和顯示器。我們推遲創(chuàng)建這個新的抽象，直到研究這個系統(tǒng)的一些應(yīng)用場景之后。最后一個需要考慮的邊界類是關(guān)于定時器的。我們將做出一個簡化的假定，每個系統(tǒng)中有且只有一個定時器，它每間隔1160秒向計算機發(fā)出中斷，調(diào)用一個中斷服務(wù)例程。這個細節(jié)特別鱉腳，如果能夠?qū)ζ渌能浖橄箅[藏這個實現(xiàn)細節(jié)，那是最好的。我們可以設(shè)計一個類，它使用回調(diào)函數(shù)，并且僅僅提供靜態(tài)成員（這樣就限制了系統(tǒng)中只有一個定時器）。圖11-6提供了一個序列圖來說明這個抽象的一個用例。從圖中可以看出定時器如何與他的客戶合作：首先，客戶提供一個回調(diào)函數(shù)，然后每隔1/60秒定時器調(diào)用這個函數(shù)。在這種方式中?？蛻舨槐浦涝趺慈ソ厝《〞r事件，定時器也不必要知道當這樣一個定時事件出現(xiàn)時該怎么做。這個協(xié)議對客戶要求的主要職責(zé)比較簡單，客戶必須在1/60秒之內(nèi)執(zhí)行完其回調(diào)函數(shù)，否則定時器將錯過一個事件由于要截取定時事件，Timer類應(yīng)當是一個主動的抽象，，這就意味著它處于控制線程的根部。下面是這個類抽象的規(guī)格說明。類名:Tinier職責(zé)：截取定時事件，并相應(yīng)地調(diào)用一個回調(diào)函數(shù)。操作:setCallback11.1.3場景我們已經(jīng)在系統(tǒng)邊界處建立了抽象，現(xiàn)在通過研究幾個使用場景來繼續(xù)分析。首先列出一些主要用例（參見圖11-7）,這些用例是從系統(tǒng)客戶的觀點來看的。監(jiān)測基本的氣象測量數(shù)據(jù)，包括風(fēng)速、風(fēng)向、溫度、氣壓和濕度。.監(jiān)測導(dǎo)出的測量數(shù)據(jù)，包括風(fēng)冷度、露點、溫度趨勢和氣壓趨勢。顯示選定測量數(shù)據(jù)的最高值和最低值。、設(shè)置時間和日期。校正選定的傳感器啟動系統(tǒng)。在增加兩個次要用例：電源故障傳感器故障11.2細化為了闡明系統(tǒng)的行為（但不是設(shè)計），讓我們考察以下這些場景。氣象監(jiān)測系統(tǒng)用例監(jiān)測基本的氣象測量數(shù)據(jù)是氣象監(jiān)測系統(tǒng)的首要功能點。其中一個系統(tǒng)約束是：不可能在1秒內(nèi)測量60次以上。幸運的是，大多數(shù)感興趣的氣象條件的改變要慢得多。通過分析，我們提出了以下采樣速率，這些速率能夠充分地捕獲氣象狀況的改變?！鲲L(fēng)向：每0.1秒。.風(fēng)速：每0.5秒?！鰷囟?、氣壓和濕度：每五分鐘。早先我們已經(jīng)決定，表示每個主要傳感器的類不負擔(dān)處理定時事件的職責(zé)。因此我們的分析需要設(shè)計一個外部代理來協(xié)助這些傳感器完成這個場景。我們暫時推遲對代理的行為進行規(guī)格說明（它如何知道什么時候去初始化一個采樣屬于設(shè)計問題而不是分析問題）。如圖11-8所示的交互圖闡述了這個場景。從圖中可以看出，當代理開始采樣時，它依次查詢每一個傳感器，但為了降低采樣速率，故意跳過了一些傳感器。我們輪詢傳感器而不是讓傳感器作為一個控制線程，這樣系統(tǒng)的執(zhí)行就是可預(yù)測的，因為代理可以控制事件流。這個名字也反映了它在系統(tǒng)行為中的位置，所以我們讓這個代理成為類Sampler的一個實例。要繼續(xù)這個場景，我們必須詢問交互圖的對象中哪一個對象負責(zé)將采樣值顯示在類LCDDevice的一個實例上。最終，我們有兩個選擇：要么讓每一個傳感器孕責(zé)顯示它自己（類MV歐構(gòu)中常用的模式），要么創(chuàng)建一個分離的對象負責(zé)這個行為。對這個特定的問題，我們選擇后者，因為它將所有關(guān)于顯示布局的設(shè)計決策封裝到一個類中。4這樣，就可把下面的類規(guī)格說明加入分析產(chǎn)物中。類名：DisplayManager職責(zé)：管理LCD設(shè)備上顯示項的布局。操作：drawStaticItemsdisplayTimedisplayDatedisplayTemperaturedisplayHumiditydisplayPressuredisplayWindChilldisplayDewPoint4這里的主要問題是我們在什么地方顯示每一項，而不是每一項看起來怎么樣。因為這是一個可能改變的決策，所以最好把在LCD設(shè)備何處顯示每一項的所有知識封裝在一個類中。因此，改變我們關(guān)于前端面板布局的假設(shè)，只需要修改一個類而不是多個類。displayWindSpeeddisplayWindDirectiondisplayHighLow操作drawStaticItems用來繪制顯示的不變部分，比如用來顯示風(fēng)向的羅盤。我們也假定操作displaykmperature.和操作displayPressure負責(zé)顯示它們相應(yīng)的趨勢（因此，當我們轉(zhuǎn)到實現(xiàn)時，必須為這些操作提供一個合適的簽名）。圖11-9提供了一個類圖，展示了協(xié)作完成這個場景所必需的抽象。同時，圖中也顯示了每一個抽象在與其他類關(guān)聯(lián)時所扮演的角色。決定在系統(tǒng)中包含一個DisplayManager類，有一個重要的附帶作用。5具體來說，就是使軟件國際化（也就是使軟件適用于不同的國家和語言）容易得多，因為怎樣命名元素和顯示元素的知識（如TEMP和WIND是這個類的秘密的一部分。國際化要求我們考慮隱含的需求：系統(tǒng)應(yīng)當以攝氏還是華氏顯示溫度？類似地，系統(tǒng)應(yīng)當以公里每小時（k/h）還是英里每小時（m/h）顯示風(fēng)速？最終，我們的軟件不5這是一個分析決策還是設(shè)計決策？兩種答案都有其道理，雖然在不得不交付的產(chǎn)品軟件面前，這樣的討論主要是學(xué)術(shù)上的。如果一個決策能夠提升我們對系統(tǒng)所需行為的理解，另外還引導(dǎo)我們得到一個優(yōu)雅的架構(gòu)，我們實際上并不介意它叫什么。應(yīng)受到限制。因為要為最終用戶提供靈活性，所以必須在TemperatureSensor和WindSpeedSensor類中增加一個操作setMode。也必須給這些類增加一個新的職責(zé)，使它們的實例在一個已知的穩(wěn)定狀態(tài)構(gòu)造自己。最后，必須相應(yīng)地修改操作DisplayManager::drawStaticItems的簽名，以便在改變測量數(shù)據(jù)的單位時，顯示管理器能夠在需要時更新前端面面板。這個發(fā)現(xiàn)促使我們?yōu)榉治鲋械目紤]增加一個場景，即：.設(shè)置溫度和風(fēng)速的測量單位。我們將推遲考慮這個場景，直到研究處理用戶交互的其他用例之后。我們可以通過已經(jīng)建立的TemperatureSensor和PressureSensor類的協(xié)議！來監(jiān)測導(dǎo)出的溫度和壓力趨勢的測量數(shù)據(jù)。但是，為了完成所有的導(dǎo)出測量數(shù)據(jù)場景，需要創(chuàng)建兩個新類，即WindChill和DewPoint,負責(zé)計算它們各自的值。這兩個抽象都不代表傳感器，不指代系統(tǒng)中的任何有形設(shè)備。它們各自作為代理與其他兩個類協(xié)作完成各自的職責(zé)。具體地說，WindChill與TemperatureSensor和WindSpeedSensor協(xié)作，DewPoint與TemperatureSensor和HumiditySensor協(xié)作。而WindChill和DewPoim與，Samoler協(xié)作，所使用的機制與Samp1er用來監(jiān)測所有主要氣象測量數(shù)據(jù)的機制相同。圖11-10說明了這個場景中涉及的類?；旧?，這個類圖與圖11-9展示的系統(tǒng)視圖略有不同。為什么將WindChill和DewPoint定義為類，而不是通過一個簡單的非成員函數(shù)來完成它們的計算？答案是這種情況通過了我們的面向?qū)ο蟪橄蟮呐袛鄿y試：WindChill和DewPoint的實例提供某種行為（即計算它們各自的值），并分裝一些狀態(tài)（每一個必須維持與兩個不同具體傳感器中的一個特定實例之間的聯(lián)系），它們各自都有唯一的標識（每一個特定的風(fēng)速傳感器/溫度傳感器關(guān)聯(lián)必須有它自己的WindChill對象。通過“對象化”這些貌似算法的抽象，可以得出一個更加重要的架構(gòu)：WindChill和DewPoint可以從這個特定應(yīng)用中提取出來，因為對于客戶它們呈現(xiàn)出清晰的契約，相對于其他抽象，它們各自提供清晰的分離關(guān)注。下一步要考慮的是涉及客戶與氣象監(jiān)控系統(tǒng)交互的不同場景。設(shè)計一個圖形用戶界面一樣，決定用戶與這樣的嵌入式控制器進行交互的恰當動作，也是一門藝術(shù)。全面描述如何設(shè)計這樣的用戶界面超出了文本的范圍，但這是提供給軟件分析人員的基本信息是原型有效，并且從根本上有助于緩解用戶界面的風(fēng)險。而且，根據(jù)面向?qū)ο罂蚣軄韺崿F(xiàn)我們的決策，使得改變這些用戶界面決策要相對容易一些，不必破壞設(shè)計的框架。請考慮一些可能的用戶交互用例場景。用例名：DisplayMaxandMinValueofMeasurements描述：這個用例顯示所選測量數(shù)據(jù)的最高值和最低值基本步驟:(1)用戶按下SELECT1時，用例開始。(2)系統(tǒng)顯示SELECTING.(3)用戶按下WIND,TEMP,PRESSUREHUMIDITY鍵中的任何一個，其他按鍵(除RUN被忽略。(4)系統(tǒng)顯示相應(yīng)的標簽。(5)用戶按下UP或DOWN用例分別選擇顯示24小時中的最高值和最低值。(6)系統(tǒng)顯示所有值，同時顯示該值出現(xiàn)的時間。(7)控制返回步驟3或5。注意：用戶可以按下RUN8來提交或放棄操作，此時，正在閃爍的信息，選擇這樣的值和SELECTING!息將消失。這個場景引導(dǎo)我們在DisplayManager類中增加兩個操作flashLable(它根據(jù)適當?shù)牟僮髯兞縼碜R別標簽或停止閃爍)和displayMode(它們LC陽備上顯示一條文本信息)。設(shè)置時間和日期的場景與上面的場景相似。用例名：SetDateandTime描述：這個用例設(shè)置日期和時間?；静襟E：(1)當用戶按下SELECT1時，用例開始。(2)系統(tǒng)顯示SELCTING(3)用戶按下TIME或DATE鍵中任一個，其他按鍵(處％RUN和上面場景的步驟3所列出的鍵外)被忽略(4)系統(tǒng)閃爍相應(yīng)的標簽，同時閃爍選擇項的第一個字段(即時間的小時字段和日期的月份字段)。(5)用戶按下LEFT或RIGHT鍵來選擇另外的字段(選擇考研來回移動一)，用戶按下UP或DOWN來升高或降低被選中的字段的值。(6)控制返回步驟3或5。注意：用戶可以按下RUN1來提交或放棄操作，此時正在閃爍的信息和SELECTIN鶴息消失，時間和日期被重置。使用以下用戶動作的相關(guān)模式來校正特定的傳感器。用例名:CalibrateSensor描述：這個用例用于校正傳感器?；静襟E：(1)當用戶按下CALIBRATE1時，用例開始(2)系統(tǒng)顯示CALIBRATE(3)用戶按下WINDTEMPPRESSUREHUMIDITY?中的任何一個，其他按鍵(除RUN7卜)被忽略。(4)系統(tǒng)閃爍相應(yīng)的標簽。(5)用戶按下UP或DOWN來選擇高校正點或低校正點。(6)顯示器閃爍相應(yīng)值。(7)用戶按下UP或DOWN未調(diào)整選中的值。⑹控制返回步驟3或5。注意：用戶可以按下RUN?來提交或放棄操作，此時正在閃爍的信息和CALIBRATIN嘴息消失，校正功能被重置。校正時，類Sampler的實例必須被告知停止采樣所選項，否則錯誤的信息將被顯示給用戶。因此，這個場景需要我們在類Sampler中引入兩個新的操作inhibitSample和resumeSample,它們都有一個指定特定測量的簽名。最后一個涉及用戶界面的主要場景是關(guān)于設(shè)置測量單位的。用例名：SetUnitofMeasurement描述：這個用例用于設(shè)置溫度和風(fēng)速的測量單位?；静襟E：(1)當用戶按下MODE1時，用例開始。⑵系統(tǒng)顯示MODE.(3)用戶按下WIND,TEMP^中任何一個，其他按鍵(除RUN外)，被忽略。(4)系統(tǒng)閃爍相應(yīng)的標簽。(5)用戶按下UP和DOWN按來切換當前的測量單位。(6)系統(tǒng)更新選擇項的測量單位。⑺控制返回步驟3或5。此時正在閃注意：用戶可以按下RUN鍵來提交或放棄操作，此時正在閃爍的信息和MODE消息消失，測量項的當前單位被設(shè)置用過研究這些場景，可以確定小鍵盤上按鍵的排列（這是一個系統(tǒng)決策），如圖11—11所示。這些用戶界面的每一個都涉及某些形式的模態(tài)或有序事件的行為，很適合用狀態(tài)轉(zhuǎn)換圖來表達。因為這些場景耦合的如此緊密，所以我們設(shè)計一個新類，InputManager來負責(zé)完成下面的契約行的規(guī)格。類名：InputManager職責(zé)：管理和分派用戶輸入。操作：proecssKeyPress唯一的操作proecssKeyPress激活存活于這個實例之后的狀態(tài)機。如圖11—12所示，這個類的最外層狀態(tài)機圖包括4個狀態(tài)：Running,Calibrating,Selecting和Mode。這些狀態(tài)直接對應(yīng)于前述的場景，根據(jù)Running狀態(tài)時截獲的第一個按鍵來轉(zhuǎn)換各自的狀態(tài)，當最后的按鍵是Run時返回Running狀態(tài)。每進入running時，顯示板上的消息被清除我們展開了mode狀態(tài)，以展示如何更正規(guī)的表達場景的動態(tài)語義。當進入這個狀態(tài)時，進入動作時顯示板上顯示適當?shù)南?。首先是在waiting狀態(tài)，此時如果截獲用戶的temp或wind按鍵事件，則轉(zhuǎn)出waiting狀態(tài)進入一個嵌套的狀態(tài)。每次進入processing,如果截獲的是run鍵，則轉(zhuǎn)回最外層的runnjing狀態(tài)。每次進入processing狀態(tài)時，閃爍適當?shù)捻?，隨后進入這個狀態(tài)時，進入以前進入過的嵌套狀態(tài)temp或wind。在temp或wind狀態(tài)，我們可以截獲五個按鍵中的任何一個：up或downtemp或wind或者run。類似地，selecting和calibrating狀態(tài)也可以展開，以揭示更多的嵌套狀態(tài)。這里不給出展開的狀態(tài)圖，因為對于目前的問題，不會揭示出特別有用的信息。最后一個主要的涉及系統(tǒng)啟動，它要求我們以一個有序的方式來激活所有的對象，而且要確保每個對象從一個穩(wěn)定的初始狀態(tài)開始。下面針對這個場景作出分析后編寫的腳本。用例名：poweron描述：啟動系統(tǒng)?；静襟E：1、當電源接通時，用例開始。2、構(gòu)造每一個傳感器。有歷史數(shù)據(jù)的傳感器清除其歷史數(shù)據(jù)，趨勢傳感器準備好它們的斜率計算算法。3、初始化用戶輸入緩沖區(qū)，無用按鍵被拋棄。

4、繪制靜態(tài)的顯示元素。5、初始化采樣過程。后置條件：每一個主要測量數(shù)據(jù)的過去高低值被設(shè)置成首次采樣的值和時間。溫度和氣壓趨勢斜率為0。inputmanager處于runnging狀態(tài)。注意，上面腳本中使用后知條件來說明這個場景完成后期望的系統(tǒng)狀態(tài)。我們將會看到，系統(tǒng)中沒有代理來完成這個場景。這個行為是由許多對象協(xié)作產(chǎn)生的，每一個對象都被賦予職責(zé)，將自己帶到一個穩(wěn)定的初始狀態(tài)。這樣就完成了對氣象監(jiān)測系統(tǒng)主要場景的研究。為了徹底的完成分析，需要進入不同的次要場景。然而，此時已經(jīng)發(fā)現(xiàn)了足夠多的系統(tǒng)功能點，我們想繼續(xù)進行構(gòu)架設(shè)計，這樣就可以開始驗證我們的戰(zhàn)略決策。每一個軟件系統(tǒng)都需要有一種簡單而強有力的組織哲學(xué)，氣象監(jiān)測系統(tǒng)也不例外。開發(fā)過程的下一步是清楚地表達這個構(gòu)架框架，這樣就可以有一個穩(wěn)定的基礎(chǔ)來演化系統(tǒng)的功能點。11.2.2構(gòu)架框架在數(shù)據(jù)采集的過程控制領(lǐng)域，有許多可以遵循的構(gòu)架模式，其中兩個最普通的模式是自動執(zhí)行者同步和基于時間幀的處理。在第一種模式中，我們的構(gòu)架也包括許多相對獨立的對象，它們中的每一個都充當一個控制線程例如，可以創(chuàng)建若干個新的基于原中的每一個都充當一個控制線程例如，可以創(chuàng)建若干個新的基于原始硬件/軟件抽象的傳感器對象，每個對象負責(zé)自己的采樣，然后向處理這些采樣的某個中央代理報告。這個構(gòu)架有它的優(yōu)點；如果有一個分布式系統(tǒng)，必須從許多遠端收集樣本，那么這是唯一有意義的框架。這種構(gòu)架也允許進行更多的局部采樣過程優(yōu)化。然而，這個構(gòu)架模式總體上不怎么適合于硬實時系統(tǒng)。在硬實時系統(tǒng)中，必須可以完全預(yù)測事件發(fā)生的時間。雖然氣象監(jiān)測系統(tǒng)不是硬實時系統(tǒng)，但它確實需要少量可預(yù)測和有序的行為。出于這個原因，我們轉(zhuǎn)向另一種基于實時幀的處理模式。如圖11-13所示，這個模型是基于時間的，它將時間分成若干幀，幀又可以更進一步的被分成子幀。每個子幀包括一些功能行為。從一個幀到另一個幀的活動可能不同。例如，可以每隔10幀進行一次風(fēng)向采樣。這種構(gòu)架模式的主要優(yōu)點就是能夠嚴格的的控制事件的順序。圖11-14提供了一張類圖，表達了氣象監(jiān)測系統(tǒng)的構(gòu)架。從圖中我們在早期分析時發(fā)現(xiàn)的大多數(shù)類，主要的不同點是，現(xiàn)在是展現(xiàn)所有的關(guān)鍵抽象之間是怎么協(xié)作的。如不同的產(chǎn)品系統(tǒng)中常見的，我們不展示每個類和每個關(guān)系。例如，忽略關(guān)于所有傳感器的類層次關(guān)系。在這個構(gòu)架中，我們創(chuàng)建了一個名叫sensors的新類，他的職責(zé)是作為系統(tǒng)中所有物理傳感器的集合。由于在系統(tǒng)中至少有兩個其他代理必須與整個傳感器集合關(guān)聯(lián)，把傳感器塞進一個容器類中可以讓我們將系統(tǒng)中的傳感器作為一個邏輯整體來對待。構(gòu)造Samplersampler;Samplersampler;這個架構(gòu)的主要行為是由Sampler和Timer類協(xié)作完成的，因此子啊架構(gòu)設(shè)計期間，具體化這些類的原型是明智的做法，這樣就可以驗證我們的設(shè)想。幀機制我們從細化類Timer的接口開始介紹，該類調(diào)用回調(diào)函數(shù)。圖11-15展示了類設(shè)計。Timer是一個與眾不同的類，但要記住，它擁有一些不尋常的秘密。我們用第一個操作setCallback來為定時器加上一個回調(diào)函數(shù)。通過調(diào)用startTiming來啟動定時器的行為，此后Timer實體每隔1/60秒調(diào)用該回函數(shù)。注意，這里引入一個顯示的啟動操作，因為在聲明的細化過程中，我們不能依靠任何特定的“依賴于實現(xiàn)”的次序。在轉(zhuǎn)到Sampler類之前，先引入一個新的聲明，用來命名這個特定系統(tǒng)中的不同傳感器。枚舉類SensorNam也含了系統(tǒng)里的所有傳感器的名稱列舉，圖11-16展示了Sampler類的接口。在引入修改器setSamplingRate及其選擇器samplingRate后，用戶就可以動態(tài)改變采樣對象的行為。為了將Timer和Sampler類黏在一起，我們需要少許的C++粘合代碼。首先聲明一個Sampler類的實例和一個非成員函數(shù)，代碼如下Voidacquire(Tickt){Samlper.sampler(t);}現(xiàn)在我們可以寫一個主函數(shù)片段，它僅僅將回調(diào)函數(shù)加到定時器并啟動采樣過程，代碼如下：Main(){Timer::setCallback(acquire);Timer::startTiming();While(1){；}Return0;}這是一個相當電信的面相對象系統(tǒng)的主程序。它比較短(因為實際的工作被委托給系統(tǒng)中的關(guān)鍵對象)，包括一個分派循環(huán)(在這里,循環(huán)沒有做任何事情，因為沒有后臺處理需要完成)。繼續(xù)討論系統(tǒng)架構(gòu)，下一步為Sensors類提供一個接口(見圖11-17)。我們假定存在不同的具體傳感器器類。從根本上說，這是一個集合類型的類，因此，我們使類Sensors成為基礎(chǔ)類Collection的一個子類。我們將Collection定義為一個受保護的超類，因為不想將它的大部分操作暴露給Sensorsa的客戶。Sensors的聲明僅提供少量的操作，因為我們的問題受到嚴格限制，傳感器只能增加而不能從集合中刪除。我們已經(jīng)創(chuàng)建了一個泛化的傳感器集合類，它能夠容納同一種傳感器的多個實例，每一個實例可以用唯一的ID來區(qū)分一一這些ID從0開始。在Sampler類里指定與Sensors和DisplayManager類的關(guān)聯(lián)，并修改Sampler類的一個實例的聲明，如圖11-18所示。這個類的協(xié)議是從前面的分析得來的。我們增加了操作inputPending,這樣，當存在尚未被處理的用戶時，客戶就可以查詢。類InputManager有一個類似的簡單接口，如圖11-28所示。正如我們將看到的，這個類大多數(shù)有趣的工作是在它的有限狀態(tài)機的實現(xiàn)中完成的。正如圖11-14中所說的那樣，Sampler、InputManager和Keypad類的實例作響應(yīng)