|
[2005 年 12 月号] |
［技術講座］
組み込み分野でのオブジェクト指向開発は， eUML（組み込みUML）などの開発プロセスの登場によって，以前と比較するとかなり敷居が低くなってきています．また，実際の開発に適用された事例も増えてきていますが，その内容が詳細に公開されることは少ないのが現状です．
今回ご紹介するのは，弊社メンタリングサービスの教材として開発した，学習リモコンです．開発にあたって，eUMLを適用しましたので，事例として紹介します．
メンタリングサービスとは，メンター（メンタリングサービスの講師）のサポートを受けながら，メンティー（メンタリングサービス受講者）自ら，具体的な組み込み機器のソフトウェアを全工程を通して開発することで，実践的な開発プロセスやオブジェクト指向技術を身につけることができるというサービスです．
前編では，要求分析から分析（ドメインユースケース分析）までの範囲を紹介します． なお，eUMLのプロセス概要に関しては，
https://www.ogis-ri.co.jp/otc/hiroba/technical/JavaWorld/index.html
を参照してください．本記事が，組み込みシステム開発を行っている皆様の参考になれば幸いです．
まず，開発対象である「学習リモコン」とは，どんなものか説明します．
学習リモコンは，家庭に溢れる多くのリモコンをひとまとめにするための機器です．商品としても何種類か販売されており，見た目はテレビなどのリモコンとほぼ同じです．しかし，通常のリモコンと違って，学習リモコンは，リモコン信号を受信することが可能です．
学習リモコンを使うためには，ひとまとめにしたいリモコンの信号を，学習リモコンに登録する必要があります．利用者は，学習リモコンを学習状態にした後，テレビやオーディオ機器などのリモコンを，学習リモコンに向けて操作することで，信号を記憶させます．
信号を記憶させたら，学習リモコンを信号の送信が可能な状態にします．これで準備は完了となります．以後は，機器の操作を行いたいとき，今までのリモコンの代わりに学習リモコンを利用することが可能となります．こうしておけば，今まで使っていた多くのリモコンを片付けて，机の上などを広く使うことができるというわけです．
＜図2.1.学習リモコンのモデル＞
（本記事のUMLダイアグラムは，全てUML1.5に準拠しています．）
図2.1は，学習リモコンとはどんなものかという，概念を表現したモデルです．
学習リモコンと，登録元としてのリモコン，操作対象としての機器に着目してモデリングしています．このようなモデルを作成して，開発対象の理解を深めておけば，要求分析をスムーズに行うことができます．
今回，学習リモコンの開発プラットフォームとして選んだのは，T-Engine/SH7727開発キットです（図3.1.参照）．
＜図3.1.T-Engine/SH7727開発キット＞
T-Engine/SH7727開発キットには，タッチパネル付きLCDが付属しており，学習リモコンでは，これをユーザインターフェースとして利用します．
また，学習リモコンには必須の，赤外線リモコン信号の送信/受信デバイスも搭載しています．
赤外線リモコン信号には，いくつかフォーマットがありますが，T-Engine/SH7727開発キットは，NECフォーマットと家製協フォーマットに対応しています．
今回は，NECフォーマット固定で開発を行います（フォーマットの詳細は，後ほど説明します）．システムの起動は，T-Engine/SH7727開発キットの，PCMCIAカードスロットに挿入したメモリーカードから行います．メモリーカード上にはファイルシステムが構築され，ここに，記憶したリモコン信号を格納します．
なお，T-Engineの詳細は，T-Engineフォーラムにて，詳しく紹介されています．
4．1．ユースケースの抽出
要求分析では，ユーザ視点で，学習リモコンがユーザに提供する機能を分析します．
「2. 学習リモコンとは？」で示したように，学習リモコンには，「リモコン信号を登録する」と「リモコン信号を発信する」という2つの大きな機能があることが分かります．
また，LCDをユーザインターフェースとして利用しますので，起動時，LCD上にボタン状のグラフィックス表示を行う必要があります．
＜図4.1.学習リモコンの画面イメージ＞
学習リモコンのユーザインターフェースは，図4.1に示すように，モード切替ボタン，操作ボタン，およびステータス表示の3つの領域から構成されます．
これらを踏まえ，ユースケース図を書いてみます．
＜図4.2.学習リモコンのユースケース図＞
アクタ”ユーザ”は，学習リモコンに電池を入れることで起動します（ただし，今回の開発では，開発の都合上T-Engineのシリアルコンソールからプログラムを実行します）．
次に，学習リモコンにリモコン信号を登録します．このときユーザは，学習対象リモコンを学習リモコンに向けて操作します．
学習リモコンを使って，テレビなどの制御対象機器を操作したいときは，リモコン信号を発信します．学習リモコンを使って操作するのは，テレビなどの機器ですが，ユースケース図上にアクタとして表現する場合は，具体的な機器の名前を使わずに，学習リモコンとの対応関係に着目した名前を付けます．ここでは，制御対象機器という名前にしました．ユースケース図を書き終えて，各ユースケースを確認したところ，「起動する」はユースケースとして適切なのか？ という疑問が生じました．
ユースケースを抽出するときには，「アクターに対して何らかの価値を提供する」のがひとつのポイントといわれていますが，学習リモコンに電池を入れて起動するだけでは，価値を提供しているとはいえません．
一方，ユースケースは，利用者のためのマニュアルやシステムテストの入力情報として利用することもできます．
学習リモコンに電池を入れたときにどんな画面が表示されるのか，といった内容は，マニュアルに記載すべきですし，システムテストのテストケースとしても必要です．
今回は，このような目的にもユースケースを利用することを前提として，「起動する」ユースケースを抽出しました．ユースケースの抽出では，抽出結果をどのような目的で利用するのかを明確にしておくことが重要です．
4．2．ユースケース記述
ユースケースを抽出したら，各ユースケースの詳細をユースケース記述として表現します．
ユースケース記述は，システムがアクターとどのようなやりとりを行うのかに着目して記述します．
ユースケース記述には，自然言語やアクティビティ図，ステートチャート図（UML2.0では，ステートマシン図）などを用いることが多いようですが，特に表記手段に決まりがあるわけではありません．
学習リモコンはいくつかの状態を持ち，同じ操作を行っても，現在の状態によって振る舞いが異なります．このような場合，ステートチャート図を利用すると，ユースケースの内容がうまく表現できます．
＜図4.3.”起動する”ユースケース記述＞
図4.3は，ユースケース”起動する”のユースケース記述です．学習リモコンのソフトウェアは，ユーザが電池を入れることで，動作を開始します．起動時に，LCDにボタン状のグラフィックス表示を行った後，発信モードになります．
※クリックすると拡大します．
＜図4.4.”リモコン信号を登録する”ユースケース記述＞
図4.4は，ユースケース”リモコン信号を登録する”のユースケース記述です．赤い枠で示すように，登録に関係のある部分にフォーカスして記述しています．
比較のため，”リモコン信号を登録する”ユースケース記述を，自然言語でのステップによる記述を用いて行ってみましょう．
基本フロー
Step1.ユーザは，登録モードボタンを押下する．
Step2.システムは，登録モード表示を行う．
Step3.システムは，操作ボタン決定待ち状態になる．
Step4.ユーザは，操作ボタンを押下する．
Step5.システムは，操作ボタンを選択表示する
Step6.システムは，リモコン信号受信待ち状態になる．
Step7.ユーザは，学習対象リモコンを操作して，リモコン信号を発信する．
Step8.システムは，リモコン信号を受信する．
Step9.システムは，受信したリモコン信号が正しいことを確認する．
Step10.システムは，リモコン信号を保存する．
Step11.システムは，保存が成功したことを確認する．
Step12.システムは，登録成功表示を行う．
Step13.Step6に戻る．
代替フロー
基本フローのStep7を行う代わりに，
Step1.ユーザは，新たな操作ボタンを押下する．
Step2.システムは，新たな操作ボタンを選択表示する．
Step3.基本フローのStep6に戻る．
例外フロー1
基本フローのStep4〜Step7において，
Step1.ユーザは，発信モードボタンを押下する．
Step2.システムは，発信モード表示を行う．
Step3.本ユースケースを終了する．
例外フロー2
基本フローのStep9において，リモコン信号が正しくない場合
Step1.システムは，登録失敗表示を行う．
Step2.基本フローのStep6に戻る．
例外フロー3
基本フローのStep11において，リモコン信号の保存に失敗した場合
Step1.システムは，登録失敗表示を行う．
Step2.基本フローのStep6に戻る．
比較した結果，ステートチャート図は，自然言語によるステップ記述に比べ， 以下のような長所，および短所を持つと考えられます．
長所
- システムの状態が視覚的に理解しやすい．
- ステップでの記述の例外フロー1のような，複数の状態から一度に抜けるケースの表現がしやすい．
短所
- アクターとシステムの関わりを直接的に表現する手段が無いため工夫が必要（今回はノートで記載しています．）
- 基本フロー，例外フローなどの区別を行うために工夫が必要（今回は区別する必要がなかったため，区別していません）．
学習リモコンのユースケース記述では，状態に関わる振る舞いが多いため，ステートチャート図による記述を行いました．
図4.5は，ユースケース”リモコン信号を発信する”のユースケース記述です．
※クリックすると拡大します．
＜図4.5.”リモコン信号を発信する”ユースケース記述＞
これで，学習リモコンのユースケースを一通り示しました．
4．3．アーキテクチャ要求分析
アーキテクチャ要求分析では，システムの非機能的な要件をまとめます．拡張性や，移植性を考慮して，以下のアーキテクチャ要求を抽出しました．
- 学習リモコンは，ユーザインターフェースに変更があったとしても，対応が容易であることとします．
- 学習リモコンは，リモコン信号の送受信方法や，保存方法に変更があったとしても，対応が容易であることとします．
- 学習リモコンは，3．開発プラットフォームで説明した，T-Engine/SH7727開発キットを利用します．
- 開発プラットフォームが変わったとしても，移植が容易であることとします．
続いて，分析フェーズに進みます．
5．1．ドメイン定義
図5.1に学習リモコンのドメイン定義のパッケージ図を示します．
＜図5.1.学習リモコンのドメイン定義＞
ドメイン分割は，eUMLで推奨されている分割法を参考にながら，アーキテクチャ要求分析でまとめた，非機能要件を考慮して行いました．
なお，図5.1ではドメインが相互に依存関係を持っています．ドメイン間に相互依存の関係があると，一方のドメイン内の修正や変更が，他方のドメインに影響することがあります．
非機能要件を満たすためにも，ドメインの相互依存は避けるべきですが，後工程で解消するため，現段階ではそのままにしておきます（相互依存の解消に関しては，後編で触れます）．それぞれのドメインの役割を，以下に示します．
学習リモコンドメイン
学習リモコンのアプリケーション機能を実現する責務を持つドメインです．「リモコン信号を受信して格納する」，「リモコン信号を取り出して送信する」という2つのアプリケーション機能を持ちます．
eUMLにおける，アプリケーションドメインに対応します．ユーザインターフェースドメイン
ユーザインターフェースを管理する責務を持つドメインです．タッチパネルの操作を受け付け，その意味を判断して，学習リモコンドメインに対して登録や，発信の要求を行います．
信号送受ドメイン
リモコン信号の送受信を行う責務を持つドメインです．このドメインで，リモコン信号受信時に信号の内容にエラーがないかチェックします．また，リモコン信号送信時に送信信号の内容にフォーマット情報を付加します．
eUMLにおける，メカニズムドメインに対応します．記憶領域管理ドメイン
リモコン信号を記憶する，記憶領域を管理する責務を持つドメインです．記憶媒体や方式の違いを，このドメインで吸収します．
eUMLにおける，メカニズムドメインに対応します．デバイスドメイン
デバイスへのアクセスを管理する責務を持つドメインです．レジスタや，割り込み制御，ファイルシステムへのアクセスを包み込みます．このドメインでは上位のドメインと異なり，リモコン信号の内容など，扱う情報の中身は関知しません．
5．2．副アクタの抽出
まず，主アクタ，副アクタに関して簡単に説明します．
主アクタは，要求分析のユースケース図，およびユースケース記述に現れる，システム外部の相手です．学習リモコンでは，ユーザ，学習対象リモコン，および制御対象機器が主アクタです．副アクタとは，主アクタがシステムと行うやりとりを，最終的にソフトウェアが扱える対象まで掘り下げていく段階で抽出されるアクタです．
例えば，ユーザが学習リモコンに信号を登録する場合，まずタッチパネルを操作することになります．
タッチパネルは，タッチパネルステータスレジスタ，OSの割り込み制御部など，ソフトウェアが理解できるレベルの要素から構成されています．
このようにして，段階的に副アクタを抽出していきます（図5.2.参照）．なお，この作業は，ドメイン定義と並行して行います．各ドメインが，どの副アクタに対応するか考えながらドメイン定義を確認し，必要な場合は修正します．
※クリックすると拡大します．
＜図5.2.主アクタと副アクタの関係＞
5．3．ドメインユースケース分析
5．3．1．ドメインユースケースの抽出
ドメインユースケース分析では，要求分析で抽出したユースケースを，各ドメイン毎のドメインユースケースに分割していきます．
分割する際は，ドメイン定義で定めたドメインの責務を逸脱しないように注意する必要があります．
また，ドメインユースケースの粒度は，そのドメインに対応する副アクタとのやりとりを考慮しながら決めていきます．図5.3は，各ドメインのドメインユースケースを抽出した結果です．
※クリックすると拡大します．
＜図5.3.ドメインユースケース概要＞
5．3．2．ドメインユースケース記述
ドメインユースケースを抽出したら，その内容を詳細に記述していきます．ここで，全てのドメインユースケースを取り上げることはできませんので，リモコン信号の発信に関連するドメインユースケース記述を処理の流れに沿いながら抜粋して紹介します．
デバイスドメイン タッチパネルイベントの取得
リモコン信号の発信は，タッチパネルを押下することで行われます．
タッチパネルの押下を一番最初に検知するのは，デバイスドメインです．
OSからの割り込みで，本ドメインユースケースは起動され，座標情報を取得して， ユーザインターフェースドメインに通知します．この一連の振る舞いを，図5.4に示すようにアクティビティ図を用いて記述しました．
※クリックすると拡大します．
＜図5.4.タッチパネルイベントを取得して通知する-ユースケース記述＞
スイムレーンには，副アクタ，およびドメインを割り当てています．
自ドメインの振る舞いは，「何をどのような順に実行するのか，どのような判断を行うのか」まで詳細に記述しています．
ただし，ドメインユースケース間でやりとりする情報の型の決定や，集合を表現する配列やリストといったコンテナの決定などは，設計工程で行うためこの段階では記述しません．一方，副アクタや他ドメインは，「何をするのか」だけを簡単に記述しています．他ドメインの詳細な振る舞いは，そのドメインのドメインユースケースとして記述します．
例えば，ユーザインターフェースドメインのスイムレーンには「通知を受ける」とだけ記述していますが，この詳細は，図5.5に示すユーザインターフェースドメインの「タッチパネル押下通知を受け取る」ドメインユースケースに記述されています．また，ドメインユースケースの呼び出しにおいては，ドメインユースケース間で受け渡される情報を記述すると，わかりやすくなる場合があります．今回，ドメインユースケース間でやりとりされる情報を明確に表現したい箇所では，図5.4の「座標情報」の受け渡しのように，オブジェクトフローを用いて記述しました．
ユーザインターフェースドメイン 操作ボタンの選択
※クリックすると拡大します．
＜図5.5.タッチパネル押下通知を受け取る-ユースケース記述＞ここでは，既に発信モードになっており，その後，ある操作ボタンが押下された状況を想定して話を進めます．
ユーザインターフェースドメインでは，デバイスドメインから通知された座標情報が，操作ボタンの範囲内であることを確かめて，「操作ボタンを選択する」ドメインユースケースを呼び出しています．
＜図5.6.ドメインユースケースのinclude関係（図5.3の抜粋）＞同一ドメインのドメインユースケースを呼び出す場合，図5.6に示すようにドメインユースケース図上でinclude関係が結ばれているか確認する必要があります．
※クリックすると拡大します．
＜図5.7.操作ボタンを選択する-ユースケース記述＞図5.7に示す，「操作ボタンを選択する」ドメインユースケースでは，どの操作ボタンが押下されたか識別し，識別情報を学習リモコンドメインの「機器制御情報を発信する」ドメインユースケースに渡します．
その後，「機器制御情報を発信する」ドメインユースケースの実行結果を確認し，失敗した場合はその旨を表示します．なお，機器制御情報は，リモコン信号のうち機器制御に必要な情報のみを表す言葉として定義しました．具体的には，メーカコードと制御コマンドから構成される情報です．一方，これらから導出可能なエラーチェックコードなどは，含まれません．
学習リモコンドメイン 機器制御情報の送信
※クリックすると拡大します．
＜図5.8.機器制御情報を送信する-ユースケース記述＞図5.8に示す，学習リモコンドメインの「機器制御情報を発信する」ドメインユースケースでは，記憶領域管理ドメインから，機器制御情報を取得し，信号送受ドメインに送信を依頼します．
多くの場合，学習リモコンドメインのようなアプリケーションドメインは，他のドメインに処理を依頼しながら，そのアプリケーションの本質的な処理を行います．学習リモコンドメインに必要以上の処理を割り当ててしまいがちですが，ドメイン分割での学習リモコンドメインの責務，さらに依存するドメインの責務を確認することで，これを防ぐことが可能です．
信号送受ドメイン リモコン信号の送信
図5.9に示すように，送信の依頼を受けた信号送受ドメインは，機器制御情報から，リモコン送信レジスタに書き込むために必要な情報を取り出し，作成します．
リモコン信号データを作成したら，リモコン送信レジスタへの書き込みをデバイスドメインに依頼します．
※クリックすると拡大します．
＜図5.9.リモコン信号を送信する-ユースケース記述＞前述の通り信号送受ドメインは，リモコン信号送受信におけるフォーマットを適切に処理する責務を持ちます．信号送受ドメインで，機器制御情報は，リモコン信号として送信できる形式に変換されます．
赤外線リモコンのNECフォーマットは，1バイトの信号長に続いて2バイトのメーカコード，さらに1バイトの制御コマンドとそのビット反転情報という構成になっています（図5.10参照）．
＜図5.10.NECフォーマット＞デバイスドメイン リモコン送信レジスタへの書き込み
図5.11に示すようにデバイスドメインでは，送信データをレジスタに書き込んだのち，送信が完了するまで待ちます．リモコン信号の送信は，極めて短時間で行われるため，ここでは単にポーリングして完了待ちを行っています．
なお，T-Engine/SH7727開発キットでは，送信完了に伴う割り込みを発生させることも可能なので，割り込みをハンドルする形で処理することも可能です．
※クリックすると拡大します．
＜図5.11.リモコン送信レジスタに書き込む-ユースケース記述＞
今回は，要求分析からドメインユースケース分析までの流れをご紹介しました．
最後に，今回の各作業でのポイントをまとめておきたいと思います．
- 要求分析では，ユースケースの利用目的を明確にしてから作業を始めます．
- ユースケース記述では，ユースケースを表現しやすい表記法を選択します．
- ドメイン定義，副アクタの抽出は対応関係を考えながら並行して行います．
- ドメインユースケース分析では，ドメインの責務を逸脱しないようにドメインユースケースを定義します．
- ドメインユースケース分析では，ドメインユースケース間でやりとりする情報を明確にします．
これらの点に注意しながら，要求分析および分析作業を進めました．
次回はオブジェクト構造分析から実装までの流れをご紹介したいと思います．
- 渡辺博之｜渡辺政彦｜堀松和人｜渡守武和記 著，『組み込みUML ― eUMLによるオブジェクト指向組み込みシステム開発』，翔泳社 ，ISBN：4798102148
| © 2005 OGIS-RI Co., Ltd. |
|
