モデル検討に専念できる!! 「BridgePoint」によるアプローチ：3つの設計アプローチで見るETロボコン参戦記録（5）（1/3 ページ）

　皆さん、こんにちは。これまでの各回で私たち富士ゼロックスから「ETソフトウェアデザインロボットコンテスト（以下、ETロボコン）」に出場した3チームのうち、2チームの取り組みについて紹介してきました。

　連載5回目となる今回は、いよいよ最後のチーム「みんなとみらい2」の取り組みと、技術的チャレンジについて、チームリーダーの田村純一が紹介します。

「みんなとみらい2」チーム紹介

　私たちのチームは、複合機のコントローラ開発に携わる5人で構成されていました（表1）。具体的には、ソフトウェア関連部門で3人、ハードウェア関連部門で1人、画質設計関連部門で1人の計5人です。ちなみに、画質設計部門の1人は、入社2年目でプロジェクト初体験でした。また、同じ部門内といっても仕事上では直接のかかわりも少なかったため、最初のミーティングで初めてお互いの仕事内容を知るというような状態からのスタートとなりました。

「BridgePoint」による開発方法について

　私たちのチームでは、「BridgePoint」というMDD（Model Driven Development：モデル駆動開発）ツールを使用した開発にチャレンジしました。BridgePointは、メンター・グラフィックス社のMDDツールです。具体的なチーム活動の紹介の前に、BridgePointによる開発方法について紹介したいと思います。

　BridgePointは、「Executable UML」というオブジェクト指向方法論に基づいたツールです。Executable UMLは、“UMLのサブセット”という位置付けになります。BridgePointによる開発の大きな特徴は、作る対象の“モデル”とそれを実現するための“メカニズム（アーキテクチャ）”をそれぞれ独立して開発し、それらをソースコードにする最終段階で組み合わせる点にあります（図1）。

図1　BridgePointでソフトウェアが生成されるまで

　一般的に、UMLを使用した多くの開発では、分析モデルとは別にソースコードに落とし込むための設計モデルを作成し、スケルトンコードなどをツールから生成させて、プラットフォームに依存したソースコード（C++やJavaなど）を手書きでスケルトンコード内に実装します。設計モデルにどうやって落としこむかは、基本的にはモデル作成者の判断で決定します。

　一方、今回私たちのチームが使用したBridgePointの場合、モデルをどのようにプラットフォームに適合させるか（どう実装するか、どのようなリソースを用いるか、など）をモデル作成者は意識する必要がありません。そのため、作ろうとする対象（ドメイン）にフォーカスした、より抽象的なモデルに注力することができます。

　なぜ、モデルを書くだけでソフトウェアを作ることができるのでしょうか？ それはExecutable UMLのモデルがモデルのまま動作可能であるということと、そのモデルをコードに変換する仕組みをBridgePointが持っているからです。

　Executable UMLでは“クラス図”、“ステートマシン図”、そしてプラットフォームに依存しない“アクション言語”をモデルとして記述します（図2）。これらのモデルは相互に関連して動作するよう定義されています。モデルをモデルのまま実行できるため、Executable UML（“実行可能”なUML）という名前が付いているのです。

図2　BridgePointで記述するExecutable UMLモデル

　BridgePointでは、「BridgePoint Model Verifier（以下、Verifier）」というシミュレータを使用して、作成したモデルをモデルのまま実行させることができます（図3）。

図3　Verifierによるモデルの確認

　Verifierでは、存在するインスタンスの一覧やその属性値の参照、ステートマシン図上でどの状態にいるかのハイライト、アクション言語へのブレーク設定などが可能です。テスト用のモデルなどと組み合わせることで、モデルの動的な動作確認を行うことができます。このように、動的な動作確認などを行いながらモデルを作成していく作業をBridgePointにおける“ドメインモデルの構築”と呼びます。モデル作成者は、モデルがどのように実装されるかを意識することなく、完成度の高いモデルを作り上げることができます。

　こうして作成されたモデルは、モデルコンパイラを通じてソースコードに変換されます。

　モデルコンパイラは生成する言語にかかわらず、Executable UMLで定義された振る舞いをするようにコードを生成します。そのため、生成されたコードはVerifierで確認した通りに動作します。こうして、モデルを書くだけで、それがどのようにコードとして実現されるかを意識することなく、同じ振る舞いをするコードを得ることができるというわけです。

　BridgePointには、C／C++言語に変換するモデルコンパイラが用意されており、変換作業自体はそれほど手間ではありません。しかし、特に組み込みソフトウェアでは使用しているハードウェアやOSなどが標準的なもの（POSIXなど）でないことが多いと思います。そのため、生成されたソースコードを自分たちの環境に合わせるための各種ライブラリなどを作成する必要があります。これは、ドメインのモデルに依存するものではなく、環境に依存するものなのでドメインモデルの構築とは独立して作業することができます。このようにモデルをどのように動作させるかを設計、実装していく作業をBridgePointにおける“アーキテクチャの構築”と呼びます。

　このように、BridgePointではドメインモデルの構築とアーキテクチャの構築の大きく2つの開発プロセスが存在しています（図4）。

図4　BridgePointの開発プロセスの図

　ドメインモデルの構築にかかわる開発者の人数は、アプリケーションの規模によって増減しますが、アーキテクチャの構築にかかわる開発者の人数はアプリケーション規模にかかわらず少人数（1つのプラットフォームであれば1〜2人程度）で対応することができます。対象となる環境が変われば、アーキテクチャも変更する必要がありますが、モデルをそのまま再利用できますので、少ない労力で環境の変化に対応できます。

　また、図1、図4に「Marking」という用語が出てきています。これは、出力されるソースコードをカスタマイズするために使用するもので、モデルコンパイラに対して渡す一種の“コンパイルスイッチ”のようなものです。例えば、あるクラスのインスタンスの最大値を指定すると、出力されたソースコードはその最大値分の領域を静的に確保します。また、使用メモリを削減するため、内部的に使用するリストをダブルリンクリストではなく、シングルリンクリストにするといった指定なども行えます。他にもさまざまな指定がありますが、こうしたMarkingはモデルと独立したファイルとして記述しますので、モデルそのものに手を加えることなく、出力されるソースコードをカスタマイズできます。

　以上がBridgePointによる開発スタイルとなります。

チーム目標

　それでは、ここからは私たちのチーム活動を紹介したいと思います。他の2チームと同様、チームで活動していくに当たって、最初に目標を決めました。私たちのチームでは、目標を“実績目標”と“プロセス目標”とに分けて、以下のように策定しました。

• 実績目標：チャンピオンシップ大会出場　
  −（モデル部門）エクセレントモデル　
  −（競技部門）インコース、アウトコースともに完走する
• プロセス目標：基礎スキル向上（開発手法、設計スキルなど）、トレンドや標準を知る

　基本的には、メンバー全員が「スキルアップ」を目的に本活動に参加しました。

チームの活動スケジュール

　続いて、私たちの活動実績を図5に示します。メンバーが5人とそれほど多いわけではなかったので、モデルの作成と要素技術開発で完全にメンバーを分けるのではなく、全員が両方の作業に携わりました。

図5　みんなとみらい2の活動スケジュール

　連載第3回で紹介した「Fusion＆Futures」チームと同じように、全員が開発できる環境を構築するために、序盤は週末にロボット（LEGO Mindstorms NXT：NXT）を持ち帰り、大会事務局から提供されるサンプルソースコードを使ってライントレースを試しました。6月からは、3チーム合同のモデリング勉強会が実施され、並行してチーム内でモデル作成と要素技術開発を進めていきました。この段階では、まだデモ版のBridgePointが参加者向けに提供されていなかったため、机上でExecutable UMLのモデルを作り上げていきました。

　南関東大会にモデルを提出した後、提出したモデルを参加者向けに提供されたBridgePointに入力し、モデルでの動作確認や生成されたソースコードの確認を進めていきました。