解決SDL與UML在即時軟體設計上的問題

2010/01/21-周安蓮  

作者：Emmanuel Gaudin, PragmaDev

在即時軟體設計上，SDL與UML的使用分別面臨各種不同的難題。SDL-RT得利於C與SDL的完整性，另一方面又具備UML易於了解的視覺化。因此，一個以SDL-RT為基礎的工具，便可以解決SDL與UML兩者不能同時兼顧的重重限制。

SDL(規格描述語言，Specification and Description Language)為國際電信聯盟(ITU)為了描述電信協定所制定。實驗結果顯示，SDL的基本原理能夠擴展到許多各方面領域中，主要的原因是其圖形化的顯示方式，能夠清楚描述系統的行為與架構。但當涉及執行與整合到Target上時，便會因為失去對目標程式碼的控制而使得SDL的資料型態與其高階概念變成大麻煩。

此外，某些即時概念如信號(semaphore)與指標(pointer)並未包含在SDL語言中，因此，SDL發展者開始在SDL的圖表中寫入C，以填補此部分的缺點。又因當時市面上並未有任何支援SDL與C混合寫成的工具，因此使用者必須自行撰寫 C code generator，以從SDL與C混合使用的圖表中匯出程式碼。

SDL開始被廣泛運用的原因

由上述所提到的問題看來，我們不難發現SDL開始被廣泛地使用。這也就是為什麼包含UML特點的SDL-RT能夠解決SDL語言與生俱來的缺陷。

即時與嵌入式軟體以即時作業系統或排程為基礎，基本構成元素為任務(task)。同時執行好幾個任務(task)便可完成一個基本的功能用途(function)；好幾個功用同時運作便可以完成更複雜的功用(function)；直到最後完成整個應用(application)。也就是說，SDL的架構能夠在功能方塊中聚集任務(task)，接著在更高階的方塊中聚集所要執行的功用(function)，一層包一層，直到完成整個系統。這樣的圖形化顯示架構能夠完美詮釋任何即時(real-time)系統，亦可完整描述系統中不同功能間的溝通介面。

介面藉由交換訊息格式所定義，並依據構成資料與劇本來描述一連串的交換訊息。SDL信號能夠附帶輸入參數，這些參數以抽象資料型態(ADT)為基礎，可包含靜態介面的完整描述。訊息序列圖表(Message sequence charts, MSC)也是ITU的標準，其針對動態觀點，像是系統內部或外部模組(如驅動器)間的資訊交換，提供圖形化的顯示介面。即時系統仰賴眾多同時執行的獨立任務，因此當任務閒置時，如何不浪費CPU的時間是非常重要的一點。基於此，大部分的即時應用程式都是根據有限狀態機(Finite state machine, FSM)的原理而設計，只要一完成自己的工作時，便開始等候下一個RTOS物件(如訊息佇列)。

SDL的有限狀態機很適合透過圖表的方式來描述這種系統行為。從’92版開始，SDL在所有圖形化階層皆使用物件導向，所以建立軟體元件專門的函式庫是確實可行的。

理論上，SDL似乎是針對即時系統規格與設計的最佳語言，但技術上的執行卻相當困難。當涉及實務設計，因為那些操作ADT的語法是被定義用以制定協定規格，而不是設計協定，因此SDL的抽象資料型態(ADT)將變成設計者難以跨越的柵欄。此時，軟體設計者將陷入困境，他們不再擁有傳統程式語言的精確性，如C，並且市面上並沒有SDL編譯器或交叉編譯器，因此當在Target上實行SDL系統時，C或C++的程式碼產生都將會是必要的。然而，ADT的基礎概念無法直接轉譯成C或C++，某些特殊的運算子的產生，將會導致程式碼無法使用。

此外，整合前人所遺留的程式碼也是一大麻煩，因為SDL與C/C++的資料型態不同，需要重新建立兩者間的溝通橋樑，況且，當需要將SDL系統所產生的程式碼整合到RTOS上時，某些SDL的語意概念並無法直接支援。

我們可以看看下面兩個簡單例子：當將RTOS的優先權概念實施在任務(task)上時，SDL則將優先權交付給訊息(Message)。SDL語法認為無論任何時候，即使RTOS的執行被打斷，自動切換也不能被中止，尤其是在切換不同優先權的任務時發生系統呼叫。此時為了保證產生的程式碼能夠如同我們所預期地運作正常，系統會自動建立SDL虛擬機，但虛擬機使得程式碼與Target間的整合變得非常難以處理，並且根本無法存取使用某些RTOS服務。這一切災難都是由於SDL中並不存在信號(semaphore)的概念，但偏偏信號的使用在即時應用程式中是最典型的同步機制。由於SDL的起源是針對協定如何與遠端實體進行溝通，因此信號(semaphore)的概念在當時並不需要納入考量。