加速度的に生産性が向上!? 「DSL」によるアプローチ：3つの設計アプローチで見るETロボコン参戦記録（4）（1/2 ページ）
富士ゼロックスのETロボコン参戦記録。今回は出場3チームの1つ「みんなとみらい1」の取り組みと技術的なチャレンジについて紹介する。
皆さん、こんにちは。前回「実録、MDDツールを“使わない”アプローチ」では、私たち富士ゼロックスから「ETソフトウェアデザインロボットコンテスト（以下、ETロボコン）」に出場した3チームのうちの1つ「Fusion＆Futures」チームのMDDツールを“使わない”取り組みについて紹介しました。
連載4回目となる今回は「みんなとみらい1」チームの取り組みと、技術的チャレンジについて、チームリーダーの上江洲吉美が紹介します。
DSL（Domain Specific Language）とは？
私たちのチームでは、今回技術的チャレンジとして「DSL」を用いた開発を行いました。チーム活動の詳細を紹介する前に、DSLとはどのようなものかについて説明したいと思います。
DSLとは“Domain Specific Language”の略で、日本語では「ドメイン特化言語」または「ドメイン固有言語」と呼ばれています。ある特定の問題領域（ドメイン）に特化した言語（テキスト形式や図を使うビジュアルなものがあります）を使用することで、作ろうとする対象を簡単に、分かりやすい形で表現する手法です。例えば、回路図や路線図などはビジュアルなDSLの一例といえます（図1）。
どちらも表記方法さえ知っていれば、対象ドメインを正確に、かつ簡単に理解することができるようになります。これに対し、UMLやC／C++言語、Javaなどの汎用言語で同様の内容を記述しようとすると、分かりづらいものになってしまいます。
DSLを使ったソフトウェア開発では、DSLで対象を記述することで開発を行います。分かりやすい表記を使うことで、ソフトウェアの知見がない人でも作業を行うことができますし、記述した内容（DSLによるモデル）からソースコードを自動生成するため、生産性を飛躍的に高めることが可能です。
DSLを使った開発プロセス
DSLを使った開発プロセスは、大きく分けて2段階あります。1つは「対象ドメインに併せてDSLを定義するプロセス」、もう1つは「定義したDSLを使って必要なDSLモデルを作成するプロセス」です。
図2に、今回用いたビジュアルなDSLによる開発プロセスを示します。
DSLを定義するプロセスでは、DSL作成ツールを使用して、作成するDSLの「意味的な構造（どんな要素があるか）」と「制約（要素間にはどのような関係があるかなど）」をモデルとして定義します。こうした言語の構造を表したモデルは、そのDSLの「メタモデル」と呼ばれます。
ビジュアルDSLの場合には、メタモデルの各要素について図的な表現との対応付けを定義します。DSLとして表現される各要素は、その言語のメタモデルの「インスタンス」になります（図3）。メタモデルとそのインスタンスの関係は、データベースのスキーマとそのデータの関係に似ています。データベース内のデータからデータの一覧表を出力するといったようなことはよく行われており、こうした処理は、PHPやRubyなどを使ってデータにアクセスし、そのデータをテンプレートに流し込むことで実現していることが多いと思います。同様に、DSLを扱うツールでは、通常DSLで記述されたインスタンスデータにアクセスして、その情報を基にテンプレートに流し込む仕組み（テンプレートエンジン）が存在します。この仕組みによって所望のコードを生成できます。なお、このテンプレートを定義するのもDSLを定義するプロセスで行います。こうした一連の定義を行うことで、ツールから定義した言語専用のDSLエディタを生成します。
図3 メタモデルとDSLの要素の関係
DSLはメタモデルの要素のインスタンスを表現している。情報的にはオブジェクト図で示しているものと変わらない。上記の例ではオブジェクト図とDSLでそれほど変わりがないように見えるが、一目で人を表していることが分かるなど、理解性が良くなっている
DSLモデル作成プロセスでは、DSL定義プロセスで作成されたDSLエディタを用いて、DSLでモデリングを行います。これは、作成するシステムのバリエーションごとに作成します。
今回のETロボコンでの開発の例では、突破したい難所や走行方法などの組み合わせで1レース分の走行戦略を作成し、この走行戦略をバリエーションの1つと考え、複数種類のDSLモデル（走行戦略）を作成しました。こうして作成したDSLモデルから、テンプレートとテンプレートエンジンを使用してソースコードを作成します。ここで生成するソースコードはシステム全体を表現するものではなく、DSLによって変更される部分（可変部）となります。このソースコードと、全体の共通した振る舞いが実装されたフレームワーク部分との組み合わせでシステムが構成されます。
通常の開発と比べると“DSLを定義する”という手間が掛かります。しかし、一度DSLの環境ができてしまうと、その後のDSLモデルの作成は非常に簡単になります。今回の活動でも、そのことがよく実感できました（詳しくは後で紹介します）。
「みんなとみらい1」チームの紹介
それでは、私たちのチーム活動について紹介したいと思います。私たちのチームは、入社2〜11年目のメンバー7名で構成されていました（表1）。UMLやMDDを業務で使用しているメンバーもいましたが、多くのメンバーがモデルによる分析やMDDは未経験でした。また、ETロボコンも私以外は初めての参加でした。このように未経験・初参加のメンバーが多いみんなとみらい1でしたが、「新しい技術を学び、一からの開発経験を!!」というモチベーションで一致団結し、ETロボコンに臨みました。
| 社歴 | 業務内容 | モデリング経験 | 今回の活動での主な役割 |
|---|---|---|---|
| 2年目 | ソフトウェア開発 | なし | 初期動作検証・足回り・戦略パラメータ |
| 4年目 | 画質設計 | なし | 足回り・戦略パラメータ |
| 4年目 | ソフトウェア開発 | 業務でMDD経験あり | 足回り・戦略パラメータ |
| 5年目 | ソフトウェア開発 | 業務でUML使用経験あり | 開発環境・戦略パラメータ |
| 6年目 | ソフトウェア開発 | ETロボコン参加経験あり | チームリーダー・フレームワーク実装 |
| 9年目 | ソフトウェア開発 | 業務でUML使用経験あり | 足回り・戦略パラメータ |
| 11年目 | ソフトウェア開発 | なし | 開発環境・フレームワーク実装 |
| 表1 みんなとみらい1のメンバー | |||
チーム目標
私たちは、
一から開発を行いたい！
新しい開発技術を体験したい！
というメンバーの思いから、「DSLを使ってMDD開発を体験する」という目標を立てました。
チーム活動のスケジュール
図4は、私たちの活動スケジュールです。前回のFusion＆Futuresチーム同様、サンプルコードを修正しながら、ロボット（LEGO Mindstorms NXT）の動作を理解することから始めました。分析モデルを作ったことのないメンバーが大半でしたので、3チーム合同のモデル勉強会にも参加し、分析モデリングを学びました。その後、6月くらいから、自分たちがどういうものを作りたいのかを検討し始めました。DSLに関しては、6月中旬からDSL環境のセットアップやDSLについての学習を開始しました。
Copyright © ITmedia, Inc. All Rights Reserved.