3.実装仕様の検討
実装仕様では実際に実装可能な方法を選びそれらの組み立て方を検討しまとめる。
とくにアプリケーション固有機能の実装可能性について注意を払うべきである。
描画ソフトウエアの場合、ユーザインタフェース部分が問題になる場合が多い。ここでは入力部分としてマウスインタフェース、出力部分として高速描画という二つの仕様に注目してその実装方法を検討する。
以下でマウス入力、ドラッグ中の高速描画の二つについて、要求された機能の実装方法を検討する。
将来的な改変の可能性のある部分をあらかじめ別実装(ライブラリ)にしておく方法もよくとられる。本実験では
点探索アルゴリズムについての改良を後期実験(ソフトウエアII)で予定していることを考慮して、
この部分を別実装にする。
マウス入力
ユーザがマウスでおこなった入力情報はプログラミング言語の中から取得できる。どのような形式で表現されるかはプログラミング言語に依存する。たとえば、「左ボタンが押された」「動いた」「左ボタンが開放された」という3つの事象情報(イベント)だけを通知するものもあれば、「ドラッグされた」という高レベルのイベントを通知するものもある。このような情報の表現方法をイベントモデルと呼んでいる。
通常のGUIプログラミングではシステムからのイベント通知をうけてどのように動作するかを記述することでマウスインタフェースを記述する。実際のコーディングに入る前にこのマウスインタフェースを決定性有限オートマトン(Deterministic
Finite State Automata, FSA)で記述することは有効である。各イベント通知を入力記号とし、使用する変数の値(の組み合わせ)によって状態を定義する。
VC++で使うライブラリ(MFC)でどのようなイベントがサポートされているか調査し、可能な実装を検討する。
実験: 「仕様」で決定したマウスの振る舞いを記述する決定性有限オートマトンを設計せよ。
ラスタオペレーション
線分の消去など、描画状態を更新するばあい、単純に線分部分だけを背景色で上書きすると背景図形を壊してします。いっぽう全体の再描画はドラッグ中のインタフェースなど動きが速い場合には速度の点で不向きである。通常このような場合、単純な上書きのかわりに画素情報(ビットマップ)の論理演算(ラスタオペレーションとよぶ)で描画する。
とくにXOR(排他的論理和)をつかう方法は上のような部分的に高速な追従をひつようとする場合に有効である。
排他的論理和では同じ値を2度足しこむと元に戻ることに注意。XORで描いた図形はXOR演算で同じものを上書きすることで背景図形を復元できる。
今回の設計ではマウス入力にたいする描画応答としてこ高速な描画が要求される。このような場合マウスインタフェースの設計時に状態遷移をあらわすエッジに副作用として描画操作を指定すると見通しがよくなる。
VC++でつかうライブラリでラスタオペレーションを行うコマンドを調査し、可能性を確認せよ。
実験: 上で設計した決定性有限オートマトンの状態遷移の各ステップに必要な描画操作を書き込め。