プログラムはモデルとルールで作る

クラス図を見て関数の構成を決める

　ロボットの構造と動作をモデル図で表現できることがわかったところで、次に、ルールを決めて、誰が書いても同じ構造と動作を持つプログラムになるようにプログラムの処理を作ってみましょう。今回は次のルールを使って、クラス図に出てきた関数と処理を対応づけてみます。

・ルール1：名前をC言語で使える名前に変える、単語同士はアンダーバー（_）でつなぐ
・ルール2：クラス名を小文字にして関数名の前につけ、関数名の衝突を防ぐ
・ルール3：関連でつながっているクラスの関数を使って処理を書く

　あらかじめ第2回のサンプルを元に修正した（linetrace_touch2.zip）プログラムを用意しましたので、サンプルを参照しながら読んでください。

　※サンプルコードはlinetrace_touch2.zipからダウンロードできます。

　最初に、ルール1にならって、クラス名や関数名をC言語で使える名前に変換しましょう。クラス図は図2のようになります。そして、ルール2「クラス名を小文字にして関数名の前につけ、関数名の衝突を防ぐ」を使うと、誰が作成しても次のような関数ができてきます。

・駆動部の処理関数：drive_unit_turn_left、drive_unit_turn_right、drive_unit_stop
・ライン監視部の処理関数：line_monitor_isOnline
・バンパの処理関数：bumper_isTouched
・ロボットの処理関数：robot_run、robot_check_current_state

　ルール3「関連でつながっているクラスの関数を使って処理を書く」から、robotクラスのrobot_run、robot_check_current_state関数は、関連しているdriveクラス、bumperクラス、line_monitorクラスの関数を使って作ります。

　ほかの3つのクラスの関数については、nxtJSPの提供するecrobotインターフェースを使って作ることになります。

　仮に、バンパの機構が変更になったとしましょう。「ロボット」クラスで直接ecrobotインターフェースを呼び出していた場合、「ロボット」クラス自体を修正することになりますが、ここで図2のような構造にしておけば、バンパの変更は「バンパ」クラスの中に局所化できるため、「ロボット」クラスはバンパの機構変更による影響を避けることができます。

ステートマシン図から処理を作る

　今度は、ステートマシン図に描いた動作を関数の処理に対応させてみます。今回のロボットは次のルールで変換するだけでも十分に動作すると思います。

・ルール4：ロボットの状態を保持するために、変数を用意する
・ルール5：イベントの監視は、周期タスクでポーリングする
・ルール6：イベントの発生を処理して現在の状態を更新する（遷移させる）
・ルール7：遷移が起きたときの処理は、別の周期タスクで実行する

　まず、ルール4に従い、「ロボット」クラスに状態を保持する変数current_stateを用意しました。次にルール5、ルール6から、イベントの発生と、状態の変化を処理するrobot_check_current_state関数を作成し、これを周期タスク内で呼び出すようにしました。

void robot_check_current_state(void){
　if( bumper_isTouched() ){
　　//現在の状態によって、このイベントによる次の状態へ遷移する
　　switch(current_state) {
　　　case RUNNING: current_state = STOPPED; break;
　　　case STOPED: current_state = RUNNING; break;
　　}
　}
}

　そして、ルール7から状態ごとの処理を書いたrobot_run関数を作成し、これを別の周期タスク内で呼び出すようにします。

void robot_run(void){
　switch(current_state){
　case RUNNING: //走行中、ライントレースする
　　if( !line_monitor_isOnline() ){
　　　drive_unit_turn_left();
　　}else{
　　　drive_unit_turn_right();
　　}
　　break;
　case STOPPED: //停止中
　　drive_unit_stop();
　　break;
　}
}

　この段階では、並行動作の調停など慎重な検討作業がまだ残っていると思います。それでも、ルールの適用だけで、モデル図に描いた動作をイベントの監視と各状態の処理を別のタスクに分け、これらの処理を非同期に実施できるよう変換できたことは実感できたと思います。

　いかがでしょう。ルールを決めてモデルからコードに変換するという方法によってプログラムはモデル図に依存し、その代わりにプログラマーの作り方に左右されずに済むようになる、ということが理解してもらえるのではないでしょうか。

　「プログラムの構造」「動作を表すモデル図」「変換ルール」をセットにした設計書を使って、プログラマー同士が「モデル図とコードをどんな変換ルールで対応させるか」を共有することは、コーディングスタイルの共有などよりずっと重要で効果的なのです。