對(duì)于 HallButtonControl，我們有二個(gè)狀態(tài):

"門廳燈開 " 和 " 門廳燈關(guān)"。
從給出的初始信息，初始的狀態(tài)應(yīng)該是"門廳燈關(guān)"。行為定義： " 當(dāng) HallCall[f，d]是真，則指令
HallLight[f，d] 為 On "，這是第一個(gè)狀態(tài)變化從on 到off；同樣地，"如果DesiredFloor.d 是Stop，則命令兩個(gè) HallLight 切換到off"，改變狀態(tài)從on 到off。在此，狀態(tài)機(jī)停下來等一個(gè)新的門廳呼叫。

第 4 步:
我們決定增加每個(gè)狀態(tài)機(jī)的前置條件、 后置條件、行動(dòng)、入口碼和退出碼，這些狀態(tài)機(jī)是從約束和行為相關(guān)的需求文檔得到。
第 5 步:
檢查事件的組合是否覆蓋所有狀態(tài)。
第 6 步:
檢查是否有死狀態(tài)，沒有 ( 組合) 事件可以使?fàn)顟B(tài)機(jī)從該狀態(tài)變換到其他狀態(tài)。
第 7 步:
一項(xiàng)項(xiàng)地按照行為運(yùn)行狀態(tài)機(jī)，確定所有的需求條件被覆蓋，而且狀態(tài)機(jī)改變狀態(tài)，采取行動(dòng)，正確地修改變量。確定沒有遺漏和冗余。第 8 步:
正確地畫出每一個(gè)對(duì)象的狀態(tài)圖、標(biāo)示狀態(tài)、守衛(wèi)條件、進(jìn)出碼和過渡，記錄用于跟蹤的相應(yīng)需求。

6 結(jié)論

在這份報(bào)告中，給出了一個(gè)模擬電梯控制系統(tǒng)詳細(xì)的 UML 文檔。這個(gè)文檔中用到的 UML 圖包括用例圖、類圖表、順序圖和狀態(tài)圖。在課程項(xiàng)目設(shè)計(jì)過程中，實(shí)時(shí)系統(tǒng)中如何使用UML 圖得到了大量的關(guān)注，我們項(xiàng)目的成功對(duì)這個(gè)問題給出了一個(gè)很好的答案。由于當(dāng)前UML 版本的流行和廣泛的符號(hào)化，OO 技術(shù)可以在實(shí)時(shí)系統(tǒng)開發(fā)中得到適度的發(fā)展。

目前面向?qū)ο蠓治龊驮O(shè)計(jì)方法重心只是在系統(tǒng)的軟件。對(duì)于實(shí)時(shí)系統(tǒng)不是完全合適，實(shí)時(shí)系統(tǒng)需要對(duì)系統(tǒng)開發(fā)作出整體苛刻的要求而不僅僅是軟件。

實(shí)時(shí)系統(tǒng)的一些方面：
·硬件元件的定義和他們的特性·任務(wù)的定義和任務(wù)的通信·時(shí)間限制·網(wǎng)絡(luò)的建模。

如果適當(dāng)?shù)刈⒁庀到y(tǒng)的實(shí)時(shí)特征和不同點(diǎn)的組合，對(duì)實(shí)時(shí)系統(tǒng)的設(shè)計(jì)和分析有很大的幫助。
為了描述硬件元素和對(duì)網(wǎng)絡(luò)建模，我們用三種不同的視圖對(duì)系統(tǒng)結(jié)構(gòu)建模。對(duì)象構(gòu)造和軟件結(jié)構(gòu)都將重點(diǎn)放在系統(tǒng)的軟件結(jié)構(gòu)上，而從系統(tǒng)結(jié)構(gòu)角度給出了一個(gè)系統(tǒng)硬件的略圖和系統(tǒng)組件間的通信方法。為了描述時(shí)間約束給出了順序圖和協(xié)作圖，通過消息和對(duì)象的名稱標(biāo)識(shí)時(shí)間約束標(biāo)識(shí)系統(tǒng)的實(shí)時(shí)特征。每個(gè)圖表僅僅是系統(tǒng)的一些方面的一個(gè)圖形表示。沒有單個(gè)圖表可以覆蓋一個(gè)系統(tǒng)設(shè)計(jì)的所有東西。圖表結(jié)合起來表達(dá)實(shí)時(shí)系統(tǒng)的完全描述。系統(tǒng)類圖的三個(gè)不同的視圖有助于了解系統(tǒng)的結(jié)構(gòu)。

本文給出的一些我的項(xiàng)目經(jīng)驗(yàn)實(shí)用方法，可能有助于填補(bǔ)需求和設(shè)計(jì)之間的間隙。當(dāng)建立系統(tǒng)的圖表的時(shí)，已經(jīng)存在一些組件，如系統(tǒng)結(jié)構(gòu)和狀態(tài)圖。不清楚上面總結(jié)的方法在一般系統(tǒng)的分析和設(shè)計(jì)過程中是否仍會(huì)有效。

舉例來說，系統(tǒng)架構(gòu) -類圖是以Phil Koopman的電梯架構(gòu)為基礎(chǔ)的 (這個(gè)報(bào)告的附件)，它使用非標(biāo)準(zhǔn)的UML語言。

這里的問題是:UML語言有沒有好到，在沒有架構(gòu)圖時(shí)仍然可以設(shè)計(jì)系統(tǒng)架構(gòu) ？
本文中電梯系統(tǒng)的功能描述仍然限制在課程項(xiàng)目。而在真實(shí)世界中更可能需要一些其他特征，例如一個(gè)火警按鈕、或一個(gè)風(fēng)扇鎖。然而，給出了系統(tǒng)的框架，這些附加的功能可以被毫不費(fèi)力的增加到系統(tǒng)的靜態(tài)和動(dòng)態(tài)的描述中。

7 參考文獻(xiàn)
[1] Hermann Kopetz. Real-Time Systems，Design Principles for Distributed Embedded Applications.
[2] Grady Booch，James Rumbaugh and Ivar Jacobson. The Unified Modeling Language User Guide.
[3] Perdita Stevens and Rob Pooley. Using UML，Software Engineering with Objects and Components.
[4] Martin Fowler and Kendall Scott. UML Distilled，A Brief Guide to the Standard Object Modeling Language.
[5] Bruce Powel Douglass. Doing Hard Time: Developing Real-time Ssystems with UML，Objects，Frameworks，and Patterns.
[6] Desmond F. D’Souza and Ala n Cameron Wills. Objects，Components，and Frameworks with UML.
[7] Alan Moore and Niall Cooling. Developing Real-Time Systems using Object Technology，A white paper from Artisan Software Tools.