組込みソフトウェアを対象としたコード自動生成に関する研究−意味制約を用いたコード生成ツールの高機能化−
2010SE037 羽根あずさ

2010SE158 野々村友花

指導教員： 沢田篤史のテンプレートを作成した．提案したパターンを用いてア

1

はじめに
近年，ハードウェアの高性能化に伴い，組込みソフトウェアの構造は複雑化し，その規模は拡大している．その一方で，開発工程の短縮や生産性の向上が課題となっている．組込みソフトウェアにおいて，並行に動作するハードウェアを状態遷移機械でモデル化することが一般的に行なクションにおける例外処理のコード生成が可能であるかを，自律走行ロボットの制御ソフトウェアの開発を通して検証した．成果として，アクションの例外処理コードのパターンを定義することで，例外処理関連コードの自動生成の可能性を確認することができた．

2

背景技術

2.1

モデル駆動型アーキテクチャ (MDA)

われており，本研究室ではその考え方に基づき，組込みシステムのためのアスペクト指向ソフトウェアアーキテクチャスタイル（以下，E-AoSAS++）を提案している [1]．

MDA はモデルを中心としたソフトウェア開発の手法でE-AoSAS++ では，組込みソフトウェアを並行に動作するあり，プラットフォームに依存しないソフトウェア開発をミーリ型の状態遷移機械の集合と規定している．ミーリ型目的とする．MDA ではプラットフォームに独立モデルでは，イベント入力部分に動作（アクション）を記述する型

ある PIM の設計を行い，プラットフォームに依存したモデであり，イベントが入力されるとアクションを実行し，状ルである PSM への変換を行なう．複数のプラットフォー態が遷移する．E-AoSAS++ を用いた開発において，コームに対応したプログラムコードの自動生成が可能となる．

ド生成を行なうためにモデル駆動型アーキテクチャ（以下，MDA）[2] の概念を用いたコード生成ツールが実現されている．アクションのプログラムコードの自動生成においては，イベントの発生列に関するメッセージ送信コードの自2.2
2.2.1

E-AoSAS++概要

動生成しか行なわれていない．アプリケーションごとに異E-AoSAS++ は，本研究室で提案されている組込みシスなる要求が存在するので，イベントの発生に関連するプロテムのためのアスペクト指向ソフトウェアアーキテクチャ

グラムコード以外を完全に自動生成することは難しい問題スタイルである．E-AoSAS++ は，組込みシステムのソである．

フトウェアアーキテクチャを構築するためのコンポーネン

本研究の目的は，アクションの例外処理コードのパター

ト・コネクタスタイルに基づく枠組みである．アプリケーンを定義することで，例外処理関連コードを自動生成するション論理を実装するオブジェクトと，その状態遷移アス可能性を確認することである．例外処理を記述する上で必ペクトを実現する並行状態遷移機械（以下，CSTM）を基要不可欠である記述を意味制約とし，例外処理の意味制約本的な構成要素とする．CSTM は受理したイベントに応のパターン化を行なった．一般に組込みシステムのソフトじて状態を遷移し，状態遷移時に他の CSTM にイベントウェアで例外処理は重要な要素であり，アクションコードを通知する．この各 CSTM の協調動作によって，組込み内に多数存在する．例外処理関連コードは定型的に記述さシステムの機能を実現する．E-AoSAS++ に基づくアーれることが多いので，我々はパターンを考えることによっ

キテクチャ記述は UML を用いる．て自動生成可能になると考えた．
我々は，例外処理のパターン定義を行なうために，Javaの例外処理構文に着目した．構文上の例外発生部，受取る

2.2.2

コード生成ツール

ボットの制御ソフトウェアと Java で記述された Apache

E-AoSAS++ に基づく開発支援環境の一つに，MDAの概念を用いたコード生成ツールがある [4]．コード生成
ツールでは，UML を拡張した E-AoSAS++ のアーキテ
クチャ記述を入力とする．PIM，PSM の 2 段階のモデルの前文検索用オープンソースコードを調査した．その結変換を行なうことで，各プラットフォームに対応したプロ

果，それぞれの要素についていくつかのパターンができるグラムコードを自動生成することが可能である．コード生ことを確認し，定義した．例外処理の自動生成に必要な情成ツールは開発期間の短縮化を実現している．コード生成

報を付加するために，コード生成ツールの入力となるアーツールによって生成されるコードは，CSTM の並行処理，キテクチャ記述の拡張を行なった．定義したパターンの情状態遷移，CSTM のインスタンス処理について実現する報を記述するために，アーキテクチャに記述するさいのパコードと，CSTM の状態遷移に伴うアクションを記述するターンの構文定義を行なった．必要な情報を記述するためためのテンプレートコードである．

例外，例外処理部の三つの要素に着目し，それぞれについて整理した．整理するために，我々が開発した自律走行ロ例外処理パターンの定義

3

あらゆる例外処理記述は，三つの要素と各要素におけるアクションのプログラムコードを完全に自動生成する記述内容の組合せで記述することができる．

ことは，アプリケーションごとに異なる要求が存在することから不可能である．特定の目的のために書かれるプログ

3.2

例外処理のパターンの定義

ラムコードの書き方には，一定の規則性が存在する場合がパターンは着目する要素ごとに存在する．例外発生部にある．一定の規則性をパターンとして定義することができは三つのパターン，受取る例外には二つのパターン，例外れば，それに基づきコードを生成することが可能になる． 処理部には二つのパターンを定義することができる．各要
我々の組込みシステムに関する開発経験から，例外処理は 素のパターンの種類は，表 1 の記述内容である．
定型的に行なわれることが多く，例外処理をパターン化すこれらの各パターンを組合わせることで，try-catch 構ることで自動生成による省力化が望めることに着目した．

文で記述された全ての例外処理記述を記述することができ

3.1

る．我々が調査したプログラムコードにおいては，提案し例外処理の整理例外処理関連コードを自動生成する可能性を確認するた
めに，例外処理のコードを定義する．Java の例外処理構文を調査し，いくかのパターンに定型化した．一般的に例外処理記述は例外発生部分と発生した例外を処理する部分に分かれている．発生した例外を処理する部分は，受取る例
外を列挙した部分と例外に対する処理内容の部分に分かれたパターンで全ての例外処理記述を記述することができた．パターンの中には，組合わせても意味のないものも存在する．例外発生部のその他のパターンは，事前事後条件検査，例外解釈のパターンと組合わせても生成されるソースコードが事前事後条件検査，例外解釈だけのパターンと同一であり，意味のない組合わせとなる．

る．我々は，この構文に注目して，構文上の例外発生部， 3.2.1 例外発生部のパターンの分類
受取る例外，例外処理部の三つの要素に着目する．三つの例外発生部は三つのパターンを定義することができる．
要素についていくつかのパターンができることを確認でき三つのパターンを次に示す．
た．三つの要素から分類することで全ての例外処理記述をtry-catch 文の形で記述できることがわかった．それらは我々の組込みシステムに関する開発経験と，Java で記述されたオープンソースコードの Apache の前文検索用ソースコードを調査した結果得られた．三つの要素の関係を図 1


例外発生部のパターン

パターン 1 事前・事後条件検査

try{if (条件) throw new Exception 名 ();}に示す．

パターン 2 例外解釈

try{try{} catch(Exception 名 e) {}}図 1 三つの要素の関係パターン 3 その他
例外発生部は try 節の中に発生させたい例外を記述する

try{

要素である．受取る例外は発生しうる例外を受取る例外名を記入する要素である．例外処理部は発生した例外に対する処理を記述する要素である．各要素における記述内容を}パターンとし，そのパターンに対してコード片を適切に対応付けることができれば，例外処理関連コードを自動生成

パターン 1 の事前・事後条件検査とは，事前条件や事後できると考える．各要素の記述内容を表 1 にまとめる．

条件を if 文記述し，事前条件や事後条件に対応させる例
外を発生させるものである．パターン 2 の例外解釈とは，

場所
記述
内容

表 1 三つの要素と例外処理記述の関係

try-catch 文で記述し，例外処理をよみかえて新たな例外例外発生部を発生させるものである．

try 節
例外を発生させる
例外処理記述
その他

受取る例外

例外処理部

catch 節
例外が一つ

再通知

例外が複数

その他

3.2.2

受取る例外のパターンの分類

受取る例外は二つのパターンを定義することができる．
二つのパターンを次に示す．


受取る例外のパターン
パターン 1



受取る例外のパターンを式 (2) に示す．

単一例外

単一例外 ::= Exception 名catch(Exception 名 e)パターン 2

複数例外 ::= merge複数例外,

catch(Exception 名 1 | Exception 名 2 e)

…

;

Exception 名;

例外処理部のパターンを式 (3) に示す．

例外統合 ::= throw
Exception 名パターン 1 の単一例外とは，例外が発生する箇所で発生した一つの例外を受取るものである．パターン 2 の複数例外とは，例外が発生する箇所で発生した例外を同じ例外ハンその他 ::= ;

4.2

(2);

(3)

アーキテクチャ記述の拡張方法

E-AoSAS++ の開発体系に提供されているコード生成ドラで複数受取るものである．

ツールのアクション部分は，シーケンス図を基に自動生成されている．我々はシーケンス図に 4.1 節で定義した構文

例外処理部のパターンの分類

3.2.3を付加する．シーケンス図に例外処理に関する情報を記述
例外処理部は二つのパターンを定義することができる． するためのテンプレートを作成する．
二つのパターンを次に示す．


例外処理部のパターン
パターン 1

例外統合{
throw new Exception 名 ();}
パターン 2その他{

図 2 テンプレート}

図 2 は我々が用意したテンプレートである．式 (1)(2)(3)
を用いて生成させたい例外処理記述を図 2 のテンプレートに記述する．テンプレートの < 例外発生部 > に式 (1)，<パターン 1 の例外統合とは，複数の例外を一つにし，メッ受取る例外 > には式 (2)，< 例外処理部 > には式 (3) を記セージ送信元にプロパゲートするものである．

述をする．複数の記述が必要な場合は続けて記述する．

4

例えば IOException を受取るか，ArgumentNullExcep-アーキテクチャ記述法の拡張

tion と ArgumentExcepton を同じハンドラで受取り Runシーケンス図に 3.2 節で定義したパターンを付加するこ timeExcepton を再通知する．try 節の中の例外処理記述とができれば，コードの一部が自動生成可能になると考え では IOException を受取る例外処理記述を記述したい場
た．例外処理の自動生成に必要な情報を付加するために， 合は図 3 のように記述する．
コード生成ツールの入力となるアーキテクチャ記述の拡張を行なった．

4.1

パターンの構文定義

3.2 節で定義したパターンをアーキテクチャに記述する規則として，バッカス・ナウア記法 (以下，BNF) を用いてパターンの記述規則の定義を行なった．各パターンの記述方法を BNF で表現する．

図 3 記述方法の例

例外発生部のパターンを式 (1) に示す．
シーケンス図のノートにテンプレートを付加すること
事前・事後条件検査 ::= if
例外解釈 ::= tryで，例外処理関連コードを自動生成することが可能になる．

(条件)

Exception 名;

Exception 名;

その他 ::= ;

5
(1)

事例検証
本章では，第 3 章で定義した例外処理パターンの事例検証を行なう．

5.1

事例の概要

したように，パターンを定義し対応するアーキテクチャ記述を作成することで，パターン定義した部分のアクション

ESS ロボットチャレンジ 2013 の仕様 [3] に基づいた自律走行ロボット（以下，Kobuki）の制御ソフトウェアを事コードが自動生成可能になると考える．

例とし，定義した例外処理パターンの妥当性を示す．

6.2

5.2

パターンが適用可能かどうかの確認

アーキテクチャ記述の拡張方法の妥当性

本研究では，定義したパターンを用いて自動生成可能にするためにアーキテクチャ記述を拡張した．我々は，既存

第 3 章で提案したパターンを適用することで，アクショのコード生成ツールのアクション部分がシーケンス図を基ンのプログラムコードの例外処理が記述可能であるかを， に生成されていることから，シーケンス図のノートに必要事例検証を行ない確認する．パターンを適用せずに記述 な情報を付加した．ノートにはテンプレートを作成し，生されたプログラムコードと，適用して記述したプログラム成したいパターンと必要な情報を書き込むだけでよい．見コードを比較することで検証を行なう．Kobuki の制御ソやすさ，分かりやすさの観点から拡張方法は妥当であった

フトウェアには六つの例外処理記述が存在し，それぞれのと考える．また，既存のコード生成ツールの入力にはノー例外処理記述に対してパターンを適用した．結果として， トを用いておらず，シーケンス図の構文に影響を与えない．
提案したパターンを用いてパターンを適用しない場合と 既存の自動生成に支障がなく，UML 本来の意味を保つこ同様のプログラムコードが記述可能であることを確認でとが出来ている．このことからも，拡張方法は妥当であっきた．

たと考える．
例外処理以外の項目でパターン化が可能な場合には，同考察

6

本章では，次の二つの視点から例外処理関連コードの自動生成の可能性に関する考察を行なう．

6.1

パターン定義による自動生成の妥当性

本研究では，アクションの例外処理関連コードを自動生成するために，パターン定義を行なった．パターンを定義することによって，アーキテクチャに例外処理の情報を付加することができ，アーキテクチャとプログラムコードを対応付けることができた．
第 5 章で示した通り，定義したパターンを用いて自律走行ロボットの制御ソフトウェアにおける例外処理記述を全て記述できることを確認した．自律走行ロボッ
トの制御ソフトウェアにログの機能を付け加えた場合，ArrayIndexOutOfBoundsException が発生すると考えられる．この例外は，4.1 節で定義した構文を用いて図 4 のように記述することができる．

様にアーキテクチャに記述することで自動生成が可能になると考える．例として，判定条件とそれに対応する実行動作の自動生成が挙げられる．

7

おわりに
本研究では，アクションの例外処理関連コードを自動生成可能にするために例外処理コードのパターンを定義し，アーキテクチャの記述方法を提案した．例外処理の調査，整理を行ない，パターン定義を行なった．抽象化したパターンを用いてアーキテクチャ記述を変更した．
今後の課題として，本研究で提案したアーキテクチャ記述を用いるために，E-AoSAS++ の開発体系に提供されているコード生成ツールの拡張を行なう必要がある．また，例外処理以外の項目についてもパターン定義が行なえるかの考察を行なう必要がある．

参考文献[1] M. Noro, A. Sawada, Y. Hachisu, and M. Banno, EAoSAS++ and its Software Development Environment, Proceedings of the 14th Asia-Pacific Software
Engineering Conference(APSEC2007), pp. 206-213,2007.

図 4 想定される例外のノート記述[2] Object Management Group, Model Driven Architecture, http://www.omg.org/mda/, 2001.

[3] ESS ロボットチャレンジ実行委員会， ESS ロボット
チャレンジ 2013 競技ルール Ver.1，これらは一対一に対応している．このことから，我々が提http://www.qito.kyushu案したパターンのパターン分けは独立に分類できており，
u.ac.jp/ess/2013/rule2013_Ver.1.pdf，2013．
生成されるコードとパターンとの関係を示したさいに，パターン分けは妥当であったと言える．上記より，パターン定義による自動生成は妥当であると考える．
今回は例外処理に着目しパターン定義を行なったが，例外処理以外の項目についても規則的な記述をパターン定義することでコード生成が可能になると考える．本研究で示[4] 長大介，加藤大地，蜂巣吉成，沢田篤史，野呂昌満，
E-AoSAS++ に基づく開発支援環境コード生成ツー
ルの提案， 情報処理学会研究報告. ソフトウェア工学
研究会報告，vol.2009，no.31，pp.113-120，2009．