The State Machine CompilerとUMLの関係

The State Machine CompilerとUMLの関係

当り前ですが、UMLの図の中でThe State Machine Compiler(以下SMCと表記します)で表現するFSMに最も近いのはBehavioral State Machineだと思います。

Behavioral State MachineとSMCで表現できる図要素の違いについて考えてみます。

まずは、お互いの図要素を列挙して、特に何も考えずにマッピングできるもの、できないものに分類してみます。
以下で、「素直には表現できない」と表現したものの中でも、ちょっと表記を工夫すれば簡単に実現できるものや、概念が異なるので表現するに当って制約が存在するもの、まったく表現できないものがあります。
それらについては次回以降で考えていきます。

Behavioral State Machineで素直に表現できるSMCの要素

• Simple Transition
• External Loopback Transition
• Internal Loopback Transition
• Transition Actions
• Transition Guards
• Transition Arguments
• Entry and Exit Actions

Behavioral State Machineで素直には表現できないSMCの要素

• Jump Transition
• Push Transition
• Pop Transition
• Default Transitions

SMCで素直に表現できるBehavioral State Machineの要素

• simple state
• submachine state

SMCで素直には表現できないBehavioral State Machineの要素

• composite state
• Region
• initial pseudostate
• terminate pseudostate
• entry point
• exit point
• choice
• join
• fork
• junction
• shallow history pseudostate
• deep history pseudostate 

つづく?

PIC開発環境雑感

PICについてはやねうらお氏の有名ないますぐPICをやめてAVRに移行すべき10の理由他、いろんなところでdisられています。僕もそのことは知っていたのでPICを使おうと思ったときにちょっと腰が引けていたのですが、食わず嫌いは良くないので使ってみることにしました。

PICという名前が付いているコントローラには、CPUのコアアーキテクチャとして8ビット系と16ビット系と32ビット系があります。これらの間にはバイナリ互換性はありません。ペリフェラルが似ているだけです。そもそもPIC32になるとMIPSだし。

Microchip社からはMPLAB^® XC: Compiler Solutionsというコンパイラが提供されていて、それぞれのアーキテクチャ向けにxc8、xc16、xc32が提供されています。有償版はけっこうお高くて1000ドル前後しますが、無償でも最適化オプションとして-O0、-O1だけしか使えない以外は別に制限はないようです。

それらのコンパイラを統合して、エディタ、デバッガまで含めた統合開発環境として、MPLAB® X Integrated Development Environment (IDE)が提供されています。こっちは無償。他のコンパイラと組み合わせても使えるようです。

xcコンパイラはgccベース、MPLAB XはNetbeansベースで作られていて、特にへんなカスタマイズはしていなくてわりと使いやすい印象を受けました。

コンパイラ、MPLAB XともにWindows、Linux、OSX版が提供されているのもよいです。

僕はOSXで使っているのですが、特に悩むこともなく、スムーズにインストールできました。

コマンドライン環境との相性もまあまあで、MPLAB Xで一度プロジェクトを設定すると、Makefileが作成されるので、コマンドラインからコンパイルすることができます。

僕の場合の開発フローは

• MPLAB Xでプロジェクト作成および編集(ファイルの追加/削除など)
• emacsで編集 → emacs上でコンパイル
• MPLAB XでPICに書き込みおよびデバッガ起動

という感じになっています。なかなか幸せ。

ステートマシンについて

The State Machine CompilerとUMLの関係

バグが少ない実装を行うための方法論はいろいろとありますが、組み込みソフトへの数理的アプローチなどにも書かれているように、形式的な記述からコードを生成するというのも一つの有効な方法だと思います。

以前から、SMCというステートマシンコンパイラを使ってみたりしていたのですが、このテの奴はどうしても独自の記法でステートマシンを記述するのがめんどうでなかなか実装に手がつかなかったりします。

ということで、Astahのステートマシン図からSMCのコードを吐きだすプラグインを作成していたのですが、実装を進めていくうちに、ネストした状態や、疑似状態を素直に取り扱えないという壁につきあたりました。

そんなバカな、と思ってFAQを見たところ、

SMC is not and will never will be a Statechart implementation. The SMC and Statechart philosophies are too different to be reconciled.

という衝撃の一文がありました。SMC使いはじめてから何年も経つというのに・・・

といいつつ、良く考えてみるとUMLの仕様ってあまり真面目に見たことがなく、 UML2.0クイックリファレンスくらいしか読んでないので、この機会に少し真面目に仕様を見てみようと思いました。

UMLの仕様

UMLについて解説しているサイトはたくさんありますが、意外と一次資料へのリンクをちゃんと紹介しているサイトは少ないですね。まあ、Googleに聞けばすぐ見つかるのですが、少しだけわかりにくいので紹介しておきます。

UMLの総本山は http://www.uml.org/ です。
最新のドキュメントは http://www.omg.org/spec/UML/2.4.1/にまとめられています。

この中で、人間が読める仕様書は

• Infrastructure specification
• UMLの下部構造。OMGが定義する他の仕様との関係や、上部構造で定義してある要素間の関連、図の要素の定義などについて書かれています。
• Superstructure specification
• 上部構造。各種の図の定義が書かれています。

の2つとなります。他にもXMI形式で書かれた機械親和性が高い仕様書もあります。

今回のように「ステートマシンとはなんぞや」という姿勢で読む場合には、Superstructureから読んでいけばよさそうです。

UMLそのものの仕様書なのにUMLをがっつり使って書かれているのはなかなかロックな感じです。例えば、振舞いステートマシンのAbstruct Syntaxはこんな感じ。

非常に明快なのですが、すでにUMLに慣れていないと読めなさそうです。

ということで、しばらく、UMLの仕様を参照しながら状態遷移機械の実装について考えていきたいと思います。

つづく