つながるワイヤレス通信機器の開発手法（15）　――プロトタイプを開発する

●○●　Column　●○●
◆組み込みソフトウェアのおさらい◆
組み込みゆえの設計上の注意点

　ここでは，組み込みソフトウェアに特有の設計上の注意点をいくつか紹介する．

1） グローバル変数を適切に使う

　グローバル変数を使用することによって，メモリを節約でき，かつ，処理速度を向上できる場合が少なくない．特に，メモリや消費電力に制約が多い組み込みソフトウェアでは，この方法が有効である．しかし，グローバル変数を多用すると，どのルーチンが変数を変更したかわかりづらくなり，デバッグ効率が落ちる．このような事態を避けるために，グループ・リーダが定めたもの以外のグローバル変数は使わないようなしくみを作るとよい．

2） 性能よりも保守性

　ソフトウェアの場合，ライブラリ化して既存の関数を再利用することが多い．ソフトウェアの開発では，性能よりも保守性や柔軟性を第1に考え，機能分割やコーディングを行う．また，開発したソースを開発者以外の人間が解析し，保守するケースもあるため，仕様書やコメント類も詳細に管理する．

3） 仕様書，コメント，ソース・コードの整備

　ファームウェアの保守性を高める有効な方法の一つはドキュメントの整備である．ソフトウェア設計時のドキュメントとしては仕様書とソース・コードがある．ソース・コードは，実際に正常に動作してしまえば，これ以上，正確なドキュメントはない．しかし，ソース・コードはあくまでもコンピュータがわかりやすいように記述されており，人間が理解することが困難な場合がある．その理解を助けるのが，コメントであり仕様書である．

　では，仕様書やコメント，ソース・コードはどのような関係であれば有用なドキュメントになるのだろうか．

　よく聞くのは，まずソース・コードを記述して動作させ，デバッグを行い，ソースが正常に動くものになってからコメントを追加し，仕様書をしあげるという方法である（図Aのいちばん上）．この方法を用いると，デバッグの途中で気づいた重要な設計ノウハウがコメントや仕様書に反映されないという問題がよく起こる．なぜなら，デバッグしている時期と，コメントや仕様書を書いている時期が離れているためである．設計者がどうしてそのようなソース・コードを書いたのかを忘れている場合もある．

　適切な方法（図Aのいちばん下）では，最初に仕様書を作成し，次にコメントを書く．このとき書くコメントについては，以下のことに気をつけるとよい．

• ソフトウェアの流れが理解できるように書く
• その行で何を行うのかを書く

　最後にソース・コードを書く．ソース・コードを書いたあと，デバッグの途中でコメントを修正する必要がある場合，ソース・コードを修正すると同時にコメントも変更する．コメントが正確に残っていれば，修正を仕様書へ反映させる作業は楽になる．

図A　正しい仕様書，コメント，ソース・コードの書きかた