Comments
Description
Transcript
Simulink モデルの保守性向上に向けた クラスタリングおよび UML
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
2012 年度
卒業論文
Simulink モデルの保守性向上に向けた
クラスタリングおよび UML モデルとの
双方向変換に関する研究
2013 年 2 月 1 日(金)提出
指導：鷲崎 弘宜 准教授
早稲田大学
基幹理工学研究科
情報理工学専攻
鷲崎研究室
学籍番号：5111B022-4
小澤
貴之
1
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
目次
第 1 章 はじめに .............................................................................................................. 3
第 2 章 モデルベース開発の背景と問題点........................................................................ 4
2.1. 組込みソフトウェア開発に用いられる Simulink モデル .......................................... 4
2.2 ソフトウェア開発に用いられる UML モデル ............................................................ 5
2.3 組込みソフトウェア開発におけるモデルベース開発の問題点 ..................................... 6
第 3 章 Simulink と UML の対応関係..............................................................................10
3.1. モデル変換の必要性 ..................................................................................................10
3.2. Simulink の構造側面から抽象度を考慮したクラスの抽出 ......................................... 11
第 4 章 サブシステムのルール化 ......................................................................................16
4.1. K-means 法................................................................................................................16
4.2. K-means 法を用いたサブシステム化 .........................................................................16
第 5 章 モデルの双方向変換の自動化 ...............................................................................20
5.1. モデル変換における問題点........................................................................................20
5.2. GroudTram ...............................................................................................................21
5.3.モデル変換の過程 .......................................................................................................24
第 6 章 適用実験 ...............................................................................................................29
6.1. nxtOSEK/JSP の倒立振子モデル ..............................................................................29
6.2. 順方向変換 ................................................................................................................29
6.3. 逆方向変換の評価......................................................................................................33
第 7 章 評価 ......................................................................................................................36
第 8 章 関連研究 ...............................................................................................................37
第 9 章 おわりに ...............................................................................................................39
9.1 まとめ ........................................................................................................................39
9.2 今後の展望 .................................................................................................................39
謝辞 ..................................................................................................................................41
参考文献 ...........................................................................................................................42
2
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
第1章
はじめに
ソフトウェア開発においてモデルベース開発という考え方が多く用いられて
いる。モデルベース開発とは、開発の早い段階で要求仕様をモデル化し、シミ
ュレーションを可能にする。各工程で、モデルのシミュレーションによる検証
と修正を繰り返すことで、開発効率の向上やコストの削減が可能となる。組込
みソフトウェア開発では Simulink モデルが主に用いられる。Simulink モデル
は、ダイナミックシステムのモデル化・時間軸シミュレーションを行える制御
モデルを表現するモデルである。しかし、再利用性が低いという欠点をもつ。
それに対して、ソフトウェア開発のモデリング記法として最も広く用いられ
ている UML はソフトウェア内部の振る舞いと構造を表現することができ、オブ
ジェクト指向に基づいて、再利用性の高いモデルを作成することができる。
近年では組込みソフトウェアの大規模化・複雑化が進んでおり、モデルも大
規模なものとなってしまう。そこで、煩雑になりがちな Simulink モデルを UML
モデルを用いて、整理・管理することでモデルの理解性を向上させ、さらに UML
モデルと対応させ、Simulink モデルの再利用性を向上させて資産価値を高める
ことで、大規模になるソフトウェア開発の開発期間を短縮させることができる。
本研究では Simulink モデルと UML モデルの双方向変換の手法について提案
する。また、片方向の変換のみではなく、一方のモデルで起きた変更点を常に
残りのモデルに反映させトレーサビリティを保つために、双方向の変換を行い、
さらに人手による誤差が出ないようその自動化の手法を提案する。
3
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
第2章
2.1.
モデルベース開発の背景と問題点
組込みソフトウェア開発に用いられる Simulink モデル
近年ソフトウェア開発において、モデルベース開発が主流になってきた。モ
デルベース開発とは、開発の早い段階で要求仕様をモデル化し、各工程でモデ
ルの検証と修正を繰り返すことで、開発効率の向上や、コストの削減が可能と
なる開発方法である。
組み込みソフトウェア開発において用いられるモデルの１つに
MATLAB[1]/Simulink[2] が 挙 げ ら れ る 。 MATLAB/Simulink と は The
MathWorks 社[1]によって開発されたモデリング、シミュレーション、解析のた
めのマルチドメインシミュレーションである。Simulink を含む MATLAB は
2011 年 1 月現在の R2010b が最新版である。MATLAB はシミュレートをコマ
ンドで入力するのに対して、Simulink はシステムをグラフィカルに表現するた
めに、ダイナミックシステムの GUI（Graphical User Interface）ベースのシミ
ュレーションツールとして開発された MATLAB の Add-on ソフトウェアの１つ
である。離散系・連続系、その混在系のダイナミックシミュレーションモデル
の構築からシミュレーションの実行まで行うことができる。
Simulink は図 2.1.のようなブロック線図を作成し、シミュレーションを行う
ことができる。Simulink には積分器などのブロック要素があらかじめ用意され
ており、その各種ブロック要素を揃えたライブラリを「ブロックライブラリ」
という。
図 2.1.
Simulink モデルの一例
4
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
また Simulink は規定のブロック以外にも開発者がブロックを容易にカスタ
マイズできるという大きな特徴をもつ。Simulink で作成したモデルのブロック
群を、図 2.2.のように１つのブロックにまとめてカスタマイズし、自分用のライ
ブラリに登録しておくことができる。その複数ブロックをまとめて１つにした
ブロックを「サブシステム」という。このサブシステム化によって大規模なシ
ステムをモデル化するとき、ブロック数を減らすことが出来、モデルを見やす
いものにすることができるという利点がある。
サブシステム内
図 2.2 サブシステム化のイメージ
また Real-Time Workshop[3]を利用することで、Simulink 上で作成したブロ
ック線図を C 言語のコードへと自動生成する機能をもつ。このため、開発工程
中にモデルを記述したら、すぐにコード生成が可能となり、そのコードを実装
置にダウンロードして実行することができる。そのため、迅速に実装置を用い
た検証と修正を行うことができることから、組込みシステム開発の制御システ
ムを扱うことに長けており、注目を集めている。さらに、プログラミングを行
わなくても、GUI ベース開発すればコードを自動生成できることから、プログ
ラムレスプログラミング言語として注目を集めている。
2.2
ソフトウェア開発に用いられる UML モデル
UML（Unified Modeling Language：UML、統一モデリング言語）[4]とは、
現在ソフトウェア開発において最も普及しているモデリング言語である。以前、
オブジェクト指向システムのモデル化に関しては、多くの表記法が存在した。
しかしそのような状況では、記法の決まっているプロジェクト内でしか、情報
5
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
の共有ができないという問題があった。
そのような多くの表記法が存在するという問題を解決するために 1996 年に
UML が提案された。UML2.0 以降では 13 種類のダイアグラムを必要に応じて
書き分ける。
UML モデル大きく以下の２種類に分けることができる
静的な構造を示す構造図
クラス図・複合構造図・コンポーネント図・配置図・オブジェクト図・パッケ
ージ図
動的な振る舞いを示す振る舞い図
アクティビティ図・ユースケース図・相互作用図・状態機械図（状態遷移図・
ステートチャート図）
相互作用図は振る舞い図のサブセットであり、システムにおける制御の流れと
データ（オブジェクト）の受け渡しを表現する。相互作用図はシーケンス図・
コミュニケーション図（コラボレーション図）
・相互概要図・タイミング図の計
４種を含む。構造図は時間の流れを任意の時点で止めて、その時点のシステム
で使われる概念同士のかかわり方を設計する。振る舞い図は時間の経過に沿っ
て、概念のインスタンスがどのように状態を変化させていくかを設計する。
多くのソフトウェア開発工程では、まず要求をユースケース図で分析し、ク
ラス図でシステムの構造を定め、構造にしたがってシステムの振る舞いをシー
ケンス図や状態遷移図で表現するという手順をとる。
システムを静的な構造と動的な振る舞いの面から見ることで、システムの理
解性が高まり、管理しやすいものとなる。また、言語肥大による、学習の時間
コスト的コストが批判されるが、UML を学習した者同士なら情報共有が容易で
あるという利点がある。また、UML はオブジェクト指向に基づくため、再利用
性の高いモデルを作成できるという利点がある。
2.3 組込みソフトウェア開発におけるモデルベース開発の問題点
組込みソフトウェア開発においては MATLAB/Simulink の Simulink モデル
がよく使われる[5]。シミュレーションモデルを作成、すぐにコードへ変換する
ことによって、迅速に実機を用いた検証と修正を行えるからである。
しかし、Simulink モデルは組込みソフトウェア開発において有用であるが、
6
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
モデルが大規模化・複雑化しやすく保守性が低いという問題がある[6]。実際の
開発現場では数億を超えるブロックで構成される[7]。開発後期になると、開発
者自身にもモデルの全体像の理解が困難なモデルになってしまう。さらに、モ
デルの意味に関する定義が明確でなく、また開発者の側で意味を付加できるよ
うな記法も存在していない。そのため開発者と第三者との意思疎通を容易にす
るというモデル本来の役割を果たしていない。そして、開発資産としての価値
が低く、保守性が低いモデルになりがちである。
次に、Simulink モデルの抽象化が属人的であるという問題が挙げられる。例
として、nxtOSEK/JSP[5]で公開されている倒立振子のコントロールモデルを挙
げる。nxt/OSEK とはオープンソースの LEGO MINDSTORMS-NXT 用開発/実行環境で
ある。この環境は教育用レゴ マインドストーム NXT[8]の開発を行うことができ
る。倒立振子のコントロールモデルの一部を図 2.3.に示す。
図 2.3.
倒立振子のコントローラモデルの一部
このコントロールモデルをサブシステム化を用いて抽象化する。サブシステム
化とは複数のブロックを１つのブロックとしてまとめる機能である。サブシス
テム化よって大規模な Simulink モデルを抽象化して見やすいモデルにすること
ができる。図 2.1.を抽象化しようとすると，図 2.4.のようにサブシステムの作
成候補が複数存在し、サブシステムをどのように作成するかは開発者によって
大きく異なってしまう。理解がかえって困難になることも考えられる。
7
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
図 2.4. サブシステム化の候補
これらのことから、Simulink モデルの抽象化・モジュール化は属人的・非体
系的であり、第三者の理解を妨げているといえる。この問題を解決するために、
我々は Simulink モデルを理解性の高いモデルである、UML モデルに変換する。
最後にモデル変換では図 2.5.に示すように、UML モデルで検討・修正を行っ
た結果を常に Simulink モデルに反映し、複数モデル間のトレーサビリティを保
つことが課題となる[9]。
8
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
図 2.5. 双方向変換の自動化
また、人手によるモデル変換では誤りが生じてしまう可能性がある。以上のこ
とから、モデル変換はモデルの信頼性が保つのが難しい。つまり、問題は
P1：Simulink モデルの責務が把握困難
P2：抽象化・モジュール化が属人的・非体系的
P3：モデル変換後のモデル間の不整合
が挙げられる.
これらの問題に対して、図 2.6.に示すように Simulink モデルの保守性が向上す
る解決手法を提案する。
図 2.6. 問題と解決の全体像
9
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
第 3 章 Simulink と UML の対応関係
3.1. モデル変換の必要性
Simulink モデルの理解性と再利用性の向上のために、Simulink モデルと
UML モデル間のモデル変換を提案する。
UML には静的な構造と動的な振る舞いを示す多くの種類のモデルがある。多
くのモデルを用いて様々な側面からシステムを記述する UML のモデルは情報
共有が容易で、理解性が高いモデルである。
それに対して、Simulink モデルはシミュレーションを行う関係上、静的な構
造と動的な振舞いが混在したモデルである。しかし、UML との対応関係をとっ
て変換することによって、その構造と振舞いが混在したモデルを図 3.1.のように
別個のモデルに変換することができる。
図 3.1.
モデル変換の必要性（卒論のパワポに本体あり）
これによって、異なる観点でのモデル評価が可能となり、Simulink モデルだ
けでは明らかでなかった Simulink モデル内のブロックがどのような責務を負
っているのか、ブロック間でどのような関係を持っているのかが明らかになり
モデルに理解性向上につながると考えられる。このことから、Simulink と UML
のモデル変換は必要なものである。
また、Simulink と UML のモデル変換は Simulink モデルの再利用性を高
10
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
めることにもつながる。UML はオブジェクト指向に基づき、再利用性の高いモ
デルをつくることができる。そのため、Simulink モデルと UML モデルの関連
性を明確にし、その対応関係をはっきりさせ、両モデル間の変換を可能にする
ことで、両モデルの特性を活かし、モデルの資産価値を高め、Simulink モデル
の再利用性向上につながると考えられる。
これまでに述べたようにモデル変換は必要なものだと考えられるが、今まで
Simulink モデルと UML モデルはお互い独自に発展してきたため、モデル間の
対応関係が取られることはなかった。だが、開発するシステムの大規模化に伴
って、Simulink モデルの理解性と再利用性を向上させるために、UML とのモ
デル変換が必要である。そして、モデル変換を行うために、まずモデル間の対
応関係を探る必要がある。
3.2. Simulink の構造側面から抽象度を考慮したクラスの抽出
まず、Simulink と UML の静的な構造の対応関係について考えていく。この
場合の静的な構造を示す UML のモデルはクラス図を用いることとする。
クラス図は概念の型の関係を表すことができるモデルである。クラス図は図
3.2.のような長方形のクラスシンボルと関連線との組み合わせからなる[6]。クラ
スシンボルは上から下に三つの部屋に区切ることができ、上から順にクラス名、
属性（プロパティ）、操作（メソッド）を記述する。型名は、その概念を的確に
表した名詞である。属性は、そのクラスを特徴付ける特性またはクラスの知っ
ている情報である。操作とは、そのクラスに持たせる仕事または責務の名前で
ある。
クラス名
属性
操作
図 3.2. クラスの例
前述したように、静的な構造を示すクラス図はクラスと関連線からなり、クラ
スはクラス名、属性、操作という情報を持っており、これらに対応していくも
11
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
のを Simulink のブロック線図から探っていく。
Simulink モデルのブロック線図はブロックとブロック間をつなぐ関連線から
なる。ブロックは既に用意されているブロックライブラリに登録されたブロッ
クと、複数のブロックを１つのブロックにまとめたサブシステムに分類できる。
ここでは Simulink モデルの各ブロックがクラス図のクラスの候補となる。しか
し、ブロック全てをクラスとした場合、それは Simulink モデルをクラス図に書
き換えたにすぎない。それでは開発者が得られる情報はモデル変換を行っても
変わらないため、モデル変換の意義がない。
そこで、モデルの抽象度について考えてみる。Simulink モデルはシミュレー
ションまで行うことができるモデルである。よって、モデルの抽象度は低い。
一方、UML のモデルは実装で使用するモデルは少なく、また構造面と振る舞い
面からとらえるため、モデル１つでシミュレーションができることはないため、
抽象度の高いモデル。クラスは何を知っていて、どんな責務を負っているのが
重要である。例えば、Simulink の積分器のブロックは積分を行うが、UML モ
デルを用いる開発者が知りたいことは「積分を行う」という機能的なことでな
く、積分器が開発システムに対して「どんな責務」を負っているかを求めてい
る。よって Simulink モデルは数学的なブロックが数多く用いられるが、全てを
クラスとして捉えるのではなく、開発システムに対して「責務」を負っている
ブロックのみをクラスとして捉えることとする。そうすることで、図 3.3.のよう
に Simulink モデルの低い抽象度を高め UML モデルに近づけることができ、変
換される UML モデルは見やすく、開発者の求める責務を負ったクラスのみが記
述された理解性の高いモデルが抽出できる。
12
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
等しい抽象度
得られる情
報が同じ
高い抽象度で抽出
必 要 な 情報 だけ
抽出しており、わ
かりやすい
図 3.3. 抽象度の変化
では責務を負ったブロックを抽出する規則を考える。まず、ブロックライブ
ラリに登録されているブロックについて考える。Simulink モデルは入出力が必
ずあり、データの流れが追えるようなモデルになっている。よって入出力装置
は重要な情報を持っていることがわかり、クラスとして抽出する。その他のブ
ロックは数学的な計算のみを行うため、システムに対する重要な責務は負って
いないと判断し、クラスとして抽出はしない。
次にサブシステムについて考える。サブシステムも複数のブロックの集まり
に過ぎないが、いくつかのブロックをデータが経過し、計算され続けることで、
ある責務を果たしていると考える。例えば、倒立振子のバランス制御を考える
場合、一回積分しただけでは何が起きたか分からないが、いくつかのブロック
の計算を経て、最終的にバランスの制御につながっていくのであれば、その一
連の流れが含まれているサブシステムは責務を負っていると考えられる。
では責務負っているサブシステムを抽出する規則を考える。先ほど Simulink
モデルはデータの入出力が追えるモデルと述べた。ここでは、データの流れ上
にあり、入力デバイスから値を読み書きしているサブシステムを「責務を負っ
たクラス」として抽出することとする。こうすることによって、Simulink モデ
ルとクラス図から得られる情報が異なり、変換が意義あるものになる。また、
Simulink モデルのブロックを一部のみ抽出することで、抽象度が高くなり、抽
出後のクラス図で分析が行い易く、理解性の高いモデルが作成できる。
13
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
Simulink モデル
UML クラス図
入出力ブロック
クラス
入出力以外のデフォルトブロック
対応しない
サブシステム（責務あり）
クラス
サブシステム（責務なし）
対応しない
データリンク
関連
表 3.1. Simulink のブロック線図とクラス図のクラスの対応
また、Simulink モデルをクラス図にすることの利点として、システムの全体
像の把握ができる点が挙げられる。Simulink の特徴の１つであるサブシステム
は複数のブロックをひとまとめにしたブロックである。つまり、サブシステム
をさらに大きなサブシステムの一部にすることもでき、サブシステムは階層的
に見ていくことができる。そのため、Simulink モデルの全体像を把握するには
ブロックを階層的に何度も見ていくこととなり、時間がかかってしまうという
問題点がある。しかし、このように重要なブロックのみをクラスとして抽出し
クラス図にすることで、全体像の把握も容易にできる。
今度は抽出したクラスがもつクラス名・属性・操作について考える。Simulink
モデルのブロックは最初のみデフォルトのブロック名が自動で記述されるが、
ブロック名は自由に開発者が変えることができる。よって、クラス名は抽出さ
れたブロックの名前をそのまま用いるべきである。次に属性について考える。
入出力のブロック（Input ブロック、Output ブロック、Scope ブロック等）は
必ず値を持っているため、その値を属性として抽出する。また、サブシステム
の属性はサブシステム内のブロックが持っている値の全てを属性として抽出す
る。
最後に操作について考える。まず、入出力ブロックの場合は、ブロックライ
ブラリに登録されているデフォルトのブロックである。これらははじめから機
能が定義されており、その機能をクラスの操作する。しかし、モデルを見ただ
けでは機能は明記されていないため、入出力のブロックを抽出したとき、機能
に則したメソッドを付け足すこととする。サブシステムの場合は、そのサブシ
ステムがどのような目的で複数のブロックがひとまとまりになっているのか明
記されていないため、モデルからどんな機能を有しているのかが判別できない。
そのため、ここではサブシステムが外部から入力された値を抽出して「process
＋値」を操作名とする。そして開発者の方で、操作名を任意に変えるという方
14
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
針を取ることとする。
Simulink モデル
UML クラス図
ブロック名
クラス名
入出力ブロックの持っている値
属性
サブシステム内のブロックが
持っている値
属性
ブロックライブラリに定義されて
いる入出力ブロックの機能
操作
サブシステムに入力される値
（process という単語をつけてサ
ブシステムの機能とする）
操作
表 3.2. 抽出した Simulink のブロックとクラスの対応
15
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
第 4 章 サブシステムのルール化
4.1. K-means 法
Simulink モデルの抽象化から、属人性を排除するために我々は K-means 法と
いうクラスタリング手法を用いる。K-means 法とは非階層型クラスタリング手法
の一つである。まず、あらかじめ指定した数のクラスタにデータを分割し、そ
の重心を計算する。そして重心に近いものを一つのクラスタとしてまとめる。
これを繰り返し続けるクラスタリング手法である。具体的には以下のような手
順でクラスタリングを行なっていく。
1. 各点にランダムにクラスタを割り当てる
2. クラスタの重心を計算する。
3. 点のクラスタを、一番近い重心のクラスタに変更する
4. 変化がなければ終了。変化がある限りは 2. に戻る。
結果は、最初のクラスタのランダムな割り振りに大きく依存することが知られ
ており、1 回の結果で最良のものが得られるとは限らない。
4.2. K-means 法を用いたサブシステム化
我々は K-means 法を Simulink モデルに対応するための手順を以下に示す。
（１）重心となるブロックの候補を開発者に示し，優先順位を決める。
（２）開発者の決めた最も優先順位の高い重心から距離の近いブロックをまと
めていく。
（３）終了後、次に優先順位の高い重心から再びクラスタリングを行い、一番
優先順位の低い重心まで（２）を繰り返す。
重心とするブロックとして以下の四つを挙げる。
・Sinks block
・Signal routing block
・四則演算ブロック
・クローンブロック
16
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
Sinks block（信号を観測するためのブロック群）は開発者が観測したいと考
える重要な信号の近くに配置されるため、重要度が高いブロックと考える。
図 4.1. Sinksblock の例
Signal routing block（信号を合成するブロック群）は複数のセンサー等の入
力から演算を経て、最終的に一つの信号を合成している。そのため重要度が高
いと考えられる。
図 4.2. Sigbal routing block の例
17
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
四則演算のブロックは Sigbal routing block と同様の理由から重要度が高い
とし、代表点とする。
図 4.3. 四則演算ブロックの例
最後にクローン構造を代表点とする。クローン構造が複数モデルの中に見受
けられるということは、ソフトウェアにとってクローン構造が重要な部位であ
るといえ、クラスタリングの代表点として扱う事にする。
図 4.4. クローン構造の例
これら代表点の優先順位は開発するドメインよって異なると考えられる。その
ことから、優先順位は開発する対象のドメイン等によって開発者が設定する。
その手順は以下のようになる。
① 重心となるブロックを代表点とする
② 各代表点から信号線に沿って入力側にたどる
③ 一定数のブロックをひとまとまりとする
④ ①～③を繰り返す
開発者の望む複数のビューを提案して、開発者により有益なビューを今後用
いてもらう
18
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
クラスタリングの結果、まとまった一定数以上のブロックの集合をサブシステ
ムとする。適切なサブシステム化のルールを定めることで、サブシステムが機
能を持つ。抽象化における Simulink モデルからクラスとなる責務を持つブロッ
クとしてサブシステムを抽出するとしたが、このクラスタリングを行うことで，
抽象化の有効性が高まる。
19
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
第 5 章 モデルの双方向変換の自動化
5.1. モデル変換における問題点
ここで、実際に Simulink と UML モデルをモデル変換しながらソフトウェア
を開発する開発工程を考えてみる。複数のモデルを扱うときにトレーサビリテ
ィ（一貫性）の維持が重要な課題となる。
Simulink モデルを作成してから UML モデルを作成するという流れが決まっ
ているのならば、変換は一方向で問題ない。しかし、実際の開発現場では一方
のモデルを作成してからもう一方のモデルを作成するという決まった流れが存
在することはあり得ない。開発プロセス中、両モデルは並行しながら開発され
る。このことからモデル変換は片方向の変換だけにとどまらずに、双方向の変
換が必要であるとわかる。
また、両モデルが並行しながら開発されるとき、一方のモデルで生じた変更
を迅速にもう一方のモデルに伝えなければモデル間のトレーサビリティを保つ
ことが出来ずに、信頼性の低いモデルとなってしまう。この変更を伝える操作
を人手で行うと誤りが生じてしまう可能性があり、さらに人手によるコストも
かかってしまう。そこで、図 5.1.のように開発サイクル内で生じた一方のモデル
の変更を自動的にもう一方のモデルに伝えることができれば、コストもかから
ず、トレーサビリティも維持できると考える。そこで、ここでは双方向変換の
自動化を提案する。
20
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
図 5.1. 双方向変換の自動化
5.2. GroudTram
双方向変換の自動化を実現させるために GroudTram[10]というツールを用い
る。GroundTram とは双方向のモデル変換のシステム開発を支持するために、
NII（National Institute if Informatics）の Hu 先生の BiG（Bidrectionalizing
Graph Transformations）チームによって開発された双方向変換言語 UnQL+を
提案・実装したツールである。モデルの変換は UnQL+言語で記述される。
UnQL+は機能的であって、再利用と保守のための高いモジュール方式で組成さ
れている。モデル変換は図 5.2.のようにグラフの作成部位と、変更に従ってグラ
フを操作するための構造的な再帰部位で構成されるグラフ代数を中心的にして
行われる。このグラフ代数は明確な双方向の意味論を持って、双方向に効率的
にグラフの評価を行うことができる。
21
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
図 5.2. 双方向変換のフレームワークのための構造フレームワーク
まずモデル変換を行うためにはソースモデルとなるグラフを作成する必要が
ある。GroudTram で扱うグラフは UnCAL ファイルで作成される。
GroudTram ではこの UnCAL ファイルを UnQL+で記述した変換の規則に従
って変換させることができる。つまり、ソースモデルから変換の規則に従って
必要箇所を抽出し、最適化させてターゲットモデルを作成することができる。
ここで変換の際にターゲットモデルだけではなく、同時に両モデル間のトレ
ース情報を記述したファイルを作成する。ターゲットモデルに変更が生じた際、
ターゲットモデルとトレース情報を比べることによって、その変更をソースモ
デルに伝える逆方向の変換が可能になる。こうして、図 5.3.のようにモデルのよ
うにモデルの双方向変換が可能となる。
22
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
変換規則：
select letrec
sfun a2d_xc({$l : $g}) =
if $l = a then {d : (a2d_xc($g))}//a のラベルがあるとき d に変換
else if $l = c then
a2d_xc($g)//c のラベルは削除
else
{$l : (a2d_xc($g))}//他のラベルはそのまま変換
in a2d_xc($db)
図 5.3. GroudTram でのモデル双方向変換の一例
23
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
5.3.モデル変換の過程
前述したとおり、GroudTram で双方向変換を行うためにはグラフは UnCAL
ファイルでなければならない。よって、Simulink モデルと UML のクラス図を
GroudTram で扱えるように UnCAL ファイルで定義する。
本手法ではクラス図におけるクラスのクラス名・プロパティ名・メソッド名
を扱うものとする。よってクラス図を UnCAL ファイルにおいて図 5.4.のよう
に定義する。
図 5.4. クラスの UnCAL ファイル
図 5.4 はあるクラスシンボルが名前とプロパティとメソッドを持っており、名
前は「Input」、プロパティは「sampletime」、メソッドは「read」を持つこと
を示している。そのため、左のクラス図と同じ情報を持っていることから両者
は同等であるとする。
同様に Simulink モデルを UnCAL ファイルにおいて定義する。まず、ブロッ
クライブラリに含まれているデフォルトのブロックを考える。例として Input
ブロックをあげる。Input ブロックを UnCAL ファイルで表したものを図 4.5.
に示す。
24
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
図 5.5. Input ブロックの UnCAL ファイル
図 5.5.は Simulink の Input ブロックが名前と値と他のブロックへ値を伝える
ポートを持っており、名前は「In1」、値は「sampletime」であることを示して
いる。そのため、左の Input ブロックと同じ情報を持っていることから両者は
同等であるとする。
最後に Simulink モデルのサブシステムを UnCAL ファイルにおいて定義する。
サブシステムを UnCAL ファイルで表したものを図 5.6.に示す。
図 4.6. Control サブシステムの UnCAL ファイル
25
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
図 5.6.は Simulink のサブシステムが名前と値と内部にまたサブシステムを持
っており、名前は「Control」、値は「Gain（Gain ブロックは乗算を行うため値
を持っている）」、内部にあるサブシステムはまた名前を持っており、名前は
「Cal_control」であることを示している。このように Simulink モデルのサブ
システムの内部にまたサブシステムが存在するような階層的なモデルでも、
UnCAL ファイルで表すことができる。よって、左の Control サブシステムと
UnCAL ファイルは同じ情報を持っていることから両者は同等であるとする。
上記のように Simulink モデルと UML モデルを UnCAL ファイルで表現でき
た。変換の手順を図 4.7.に示す。
図 5.7. 双方向変換の手順
まず MATLAB/Simulink を用いて Simulink モデルを作成する。次に作成し
た Simulink モデルを UnCAL ファイルに書き直す。そして UnCAL ファイルに
表 5.2.で示した変換規則を双方向変換言語 UnQL+に則って記述したマッピング
ルールを当てはめる。すると、Simulink の UnCAL ファイルからマッピングル
ールに基づいてラベルの抽出、追加を行いグラフを最適化した UnCAL ファイ
ルを自動生成する。これが、UML の UnCAL ファイルに相当する。この UnCAL
ファイルを UML のクラス図として書き直すことによって順方向の変換が完了
する。
クラス図で設計の見直し等を行って変更が起きた場合、即座にソースモデル
の Simulink モデルへ伝えなければならない。逆変換の際には、マッピングルー
ルではなくトレース情報を用いる。はじめにマッピングルールに基づいて
26
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
Simulink モデルから UML の UnCAL ファイルを出力する際に、同時に変換の
トレース情報を含んだファイルが生成される。変更が起きて UML の UnCAL
ファイルが書き換えられたとする。すると、変更前の UML の UnCAL ファイ
ルと変更後の UML の UnCAL ファイルを比べて、ラベルの生成、削除、名前
の変更などの情報を得る。その変更の情報をトレース情報に基づいてソースモ
デルである Simulink の UnCAL ファイルの対応する部分にマッピングすること
によって逆変換を行うことができる。ルールを変えて多段階の変換を行ったと
しても、トレース情報に基づいて対応するラベルに処理を加えていくだけなの
で、変換は容易である。これによって Simulink と UML のクラス図の双方向変
換の自動化が実現できる。
ここで、実際にケーススタディに当てはめた例を図 5.8.に示す。
図 5.8. 双方向変換の全体像
（１）Simulink モデルに対して K-means 法を用いる。その結果を示す。
（２）サブシステムの作成後、UnCAL ファイルに変換する。その結果を示す。
（３）UnCAL ファイルを GroundTram に入力し、マッピンルールに従って自動
変換した UnCAL ファイルとトレース情報を出力する。
（４）出力された UnCAL ファイルを UML モデルに変換を示す。構造の面から検
討することで明らかになった情報を元に修正を行う。
（５）修正結果を UnCAL ファイルに反映させ、逆変換を行い、変更が反映され
た Simulink モデルを出力する。
本手法を適用することにより，Simulink モデルに新たなビューを提供でき，
Simulink モデルだけでは不明瞭だった責務が明らかになり，検討・修正が可能
27
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
になった．また，自動双方向変換により，モデル間のトレーサビリティの維持
も確認され，保守性が向上した．
28
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
第 6 章 適用実験
6.1. nxtOSEK/JSP の倒立振子モデル
今までに述べてきた変換規則を双方向変換言語 UnQL＋で記述したので、実
際のモデルを入力して適用実験を行う。今回は nxtOSEK/JSP[11]で公開されて
いる倒立振子のコントロールモデルを評価に用いる。
nxt/OSEK とはオープンソースの LEGO MINDSTORMSNXT 用開発/実行環
境である。nxtOSEK/JSP は leJOS NXJ という NXT 用 Java 言語開発環境に含
まれている C 言語/アセンブリで記述された I/O ドライバおよび、TOPPERS プ
ロジェクトの成果物の１つである TOPPERS/ATK および、TOPPERS/JSP を
NXT 内蔵の ATMELAT91SAM7S256 に独自移植した RTOS 等から構成されている。
この環境は教育用レゴ マインドストーム NXT[12]の開発を行うことができる。
教育用レゴ マインドストーム NXT とはレゴ社とマサチューセッツ工科大学の
研究成果を基にしたロボット製作キットである。教育用に開発されたプログラ
ミングや機械機構を学習するためのもので、Atmel 社の 32 ビット ARM7 を内
蔵した本体（NXT）とプラスチック製のブロックやギア、シャフトといった各
種部品を利用して、自由にロボットを製作することができる。この教育用レゴ
マインドストーム NXT を用いて組み立てられた２輪自律型倒立振子ロボット
のコントローラモデルが公開されているので、このモデルを用いて Simulink モ
デルと UML モデルの双方向変換を行う。
6.2. 順方向変換
Simulink モデルから UML のクラス図へ自動変換する順方向変換を行う。
倒立振子制御のコントローラモデルである Simulink モデルを示す[13]。まず、
図 6.1.は Simulink モデルの最上位階層で、倒立振子制御における実行関数の引
数/戻り値に対応した信号線が確認できるモデルである。
29
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
図 6.1. 倒立振子制御 Simulink モデルの最上位階層モデル
次に図 5.1. の中核となっている Control サブシステムの内部を図 5.2.に示す。
図 6.2. Control サブシステムの内部
Control サブシステムは大きく三つのサブシステムを含むことがわかる。左上
の Cal_Reference サブシステムは倒立振子制御の目標値の演算部となる。
Cal_x1 サブシステムは倒立振子制御の状態量の演算部となる。また、Cal_PWM
サブシステムは左右のモータ駆動 PWM 出力の演算部となる。今回は Control
サブシステムとその内部にある Cal_Reference サブシステムを対象として、
30
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
UML に変換する。Cal_Reference サブシステムが持つ情報として、内部のブロ
ックが挙げられる。Cal_Reference サブシステムの内部構造を図 5.3.に示す。
図 6.3. Cal_Reference サブシステムの内部
明示した対応関係に基づき双方向変換言語 UnQL+で記述したマッピングル
ールで Simulink モデルから UML のクラス図へ自動で変換していく。
自動変換するにあたって、まず GroundTram で自動変換が行えるように
Simulink モデルを UnCAL グラフに変換しなければならない。図 6.3.で示した
Simulink モデルを図 6.4.のような UnCAL グラフに書きなおす。
図 6.4. 倒立振子制御 Simulink モデルの UnCAL グラフ
31
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
図 6.4.を入力し、マッピングルールによって変換された UnCAL モデルを図
6.5.に示す。
図 6.5. クラス図の UnCAL グラフ
図 6.5.を図 5.4.で定義したようにクラス図に変換する。変換したクラス図を図
6.6.に示す。
図 6.6. 自動変換で出力されたクラス図
今回クラス図を作成するのに当たって、Apache Software Foundation の
astah-professional[14]を用いた。出力されたクラス図を見ると抽象度が上がり、
Simulink モデルでは分からなかった全体の構造や、責務を明確に出来たため、
モデルの理解性が向上したと考えられる。
32
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
6.3. 逆方向変換の評価
次に出力されたクラス図の見直しを行う。見直しの際起きたモデルの変更を
正しくソースモデルである Simulink モデルに逆変換で伝えることができるか
実験する。図 6.6.の Cal_Reference クラスは目標値と現在量を出力している。
目標値は倒立振子モデルのサーボモータをどのように動かすかという値である。
それに対し、現在量は現在倒立振子モデルがどのような状態（平均回転角度状
態値）であるかを示す値である。このことから、Cal_Reference クラスから出力
される値は目的が大きく違う値であるとわかる。よって、このクラスを目標値
を出力するクラスと状態量を出力するクラスに分けることにする。この設計を
見直したあとのクラス図を図 5.7.に示す。
図 6.7. 設計見直し後のクラス図
この変更したクラス図をトレース情報に従って、逆変換する。まず、そのた
めに UnCAL グラフに変更を伝える。変更を施した UnCAL グラフを図 6.8.に
示す。
33
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
図 6.8. 変更を施したクラス図の UnCAL グラフ
図 6.8.の変更をトレース情報に基づき、逆変換した結果を図 6.9.に示す。
図 6.9. 逆変換により変更が伝えられた Simulink モデルの UnCAL グラフ
図 6.9.を図 5.5.、図 5.6.で定義した Simulink モデルと UnCAL グラフの対応
に基づいて Simulink モデルを記述した結果を図 6.10.に示す。
34
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
図 6.10. 逆変換により出力された Simulink モデル
図 6.10.をみると、クラス図の変更が Simulink に反映されているため、逆方
向変換も有用である。
35
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
第 7 章 評価
評価のために被験者実験を行った。被験者には、倒立振子のコントローラモ
デルに機能拡張を行ってもらう。コントローラモデルはリモコンから、前後進
命令・旋回命令を受け取り、サーボモータの PWM 値の目標値を出力するとい
うものである。しかし、目標値のみでは倒立振子モデルはバランスを保てず、
すぐに倒れてしまう。そのため、被験者にはジャイロセンサなどの入力デバイ
ス、ロータリエンコーダから値を読み取り、倒立振子モデルの現在量（車体傾
斜角度、車輪平均回転角度、車輪平均回転角速度、車体傾斜角速度）を演算す
る機能を拡張してもらう。ただし、被験者はいずれも組み込みには詳しくない
ため、細かい演算の部分は作成せず、現在量を演算する機能を持ったサブシス
テムを作成し、他のブロックとつなげるという作業をとらせる。
被験者は２パターンに分けられ、コントローラモデルの Simulink モデルのみ
を与えられる被験者と、Simulink モデルと自動変換で出力されたクラス図を与
えられる被験者とする。
まず Simulink モデルのみ与えられたパターンでは、被験者は Simulink モデ
ルに慣れておらず、機能などモデルの説明がないため、どの部分に拡張を施せ
ばいいか分からなかった。また、サブシステムを作成しても、関連があるはず
のクラスと関連線が結べず、正しい拡張を行うことができなかった。
次に Simulink モデルとクラス図が与えられたパターンでは、被験者はクラス
図に新しいクラスを付け加える形で拡張を行った。そしてクラス図を Simulink
に逆変換することで、正しい拡張に近い Simulink モデルを作成することができ
た。
また、所要時間も Simulink モデルのみの場合と比べて、Simulink モデルと
クラス図の場合ははるかに短くすることができた。このことから、UML と対応
付けることによって、Simulink モデルの理解性向上につながったと評価するこ
とができる。
36
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
第 8 章 関連研究
・Using UML as a front-end for an efficient Simulink-based multithread code
generation targeting MPSoCs
・[L.B. Brisolara ら,07][15]
著者は Simulink モデルを構造面と振る舞い面から捉えて、これらを分けるこ
との重要性を述べている。そこでモデル変換としては、クラス図とアクティビ
ティ図への変換を行なっている。しかし、サブシステム以外のブロックの扱い
は記述されておらず、変換も Simulink から UML の片方向の提案のみとなって
いる。本研究では全てのブロックを変換の対象として扱い、また双方向変換の
自動化を行っている点が異なる。
・UML と Simulink のモデル変換手法の提案
・[吉田 聡、上田 賀一、中島 震 09][16]
著者は Simulink モデルの再利用性を高めることを目的として、Simulink と
UML 間のモデル変換手法を提案している。UML のクラス図、ステートマシン
図、シーケンス図への変換を検討している。まず Simulink モデルから UML モ
デルへの変換の場合、Simulink の各ブロック要素を UML のクラスとして抽出
している。そして UML モデルに変更を施したあと UML モデルから Simulink
モデルへの変換の場合、UML に Simulink の細かな実装の情報がないため、
UML モデル要素に Simulink モデル要素をマッピングさせながら、手動で逆変
換していく。元の Simulink から変換した UML と変更を加えた UML との差分
を取り出し、変更のない Simulink モデルをそのまま Simulink モデルとして取
り出す。新たに追加・変更がされた部分をステレオタイプに対応するブロック
の雛形を取り出した Simulink モデルに作成し、中身を手動で実装する。
本研究では変換する UML の対象を構造面のクラス図のみとしているが、モデ
ル間の双方向変換を手動ではなく自動で行い、人手によるミスをなくした。ま
た、モデル間のトレーサビリティについて言及されていないが、本研究では双
方向で自動化しているため、モデル間のトレーサビリティを保ち、両モデルの
開発を同時進行で行える。
37
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
・mtrip[17]
株式会社エ クスモーシ ョンが影 響する UML モデリン グツールで ある
Enterprise Architect のプラグインである。Enterprise Architect で作成した分
析モデル（クラス図、パッケージ図）の構造を Simulink のサブシステムの構造
として変換する。このモデル変換ツールは UML から Simulink への片方向の変
換のみを実現する。本研究は基本的に Simulink モデルの保守性向上のため
Simulink から UML への変換を想定しているため、変換の目的が異なる。加え
て、本研究では双方向変換を行っている。
・Mapping Simulink to UML in the design of embedded systems
:Investigating scenarios and transformations
・[Carl-Johan ら,08][18]
著者は Simulink モデルと UML の複合構造図、及びシーケンス図との変換手
法を提案している。こちらの手法では Simulink から UML モデルへの片方向変
換しか提案していない。また、サブシステム以外のブロックを変換で扱ってい
ない。それに対し、本研究ではサブシステム以外のブロックも変換の対象とし
て扱い、さらに双方向変換と変換の自動化を加えて行っている。
38
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
第 9 章 おわりに
9.1 まとめ
我々は Simulink モデルの保守性を向上させることを目的として，Simulink モ
デルにクラスタリング手法を適用し，属人性を排した抽象化を行った上で，UML
モデルとの自動双方向変換を提案した．
今回は UML の構造と振る舞いの側面のうち、構造の側面から Simulink モデ
ルと UML のクラス図との対応関係を洗い出した。また、モデル間のトレーサビ
リティを保つために、双方向変換ツール GroundTram を用いた。モデル間の変
換規則を UnQL+言語で記述することで、両モデル間での双方向変換の自動化を
行った。
Simulink モデルを クラス図へ変換することによって 抽象度が上がり、
Simulink モデルでは不明瞭だった「どのブロックに責務があり、ブロック間に
どのような関係があるか」を明らかにすることができ、Simulink モデルの理解
性向上につながった。また、サブシステムを階層的に見ていかなくては全体の
構造の確認ができなかった Simulink モデルはクラス図に変換されることで、全
体を把握しやすくすることが出来た。よって Simulink モデルから UML のクラ
ス図への変換は有用である。
また GroundTram を用いた双方向変換の自動化においても、手動の変更によ
るミスも減らすことが出来、トレーサビリティも保てたため、これも有用であ
ると考えられる。
9.2 今後の展望
今回は UML モデルの中でも構造図に着目して変換を行ったが，振る舞い図へ
の変換も検討する必要がある．また，UML モデルに留まらず，組み込み開発の現
場で用いられ始めている SysML への変換も検討し，開発者に対して Simulink モ
デルをより多くの観点でモデル評価を行えるようより有益なモデルビューを提
案し，Simulink モデルの保守性向上につなげるよう，今後も取り組んでいく．
また本手法は静的な構造と動的な振る舞いの混在する Simulink モデルから
構造の面のみを洗い出した。今後は UML の他のモデルとの変換手法を検討した
39
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
いと考えている。特に今回は静的な構造の観点のみから捉えたため、Simulink
モデルを動的な振る舞いの観点から捉えて、UML の動的な振る舞いを示すシー
ケンス図、アクティビティ図等との対応関係を明らかにしたいと考えている。
そして、Simulink モデルを構造の観点と振舞いの観点でモデル評価を行い、
Simulink モデルの理解性向上につなげたいと考える。
他の UML モデルへの変換の際にも、変換の自動化を実現したいと考える。
本手法ではモデル変換を自動で行う際に用いた GroundTram は UnCAL ファ
イルでないと変換が行えなかった。今回は Simulink モデルから UnCAL ファイ
ルへの変換と UML モデルと UnCAL ファイルのへの変換は手動で行った。し
かし、これでは人手によるミスが起きる可能性がある。そのため、Simulink モ
デル、UML モデルから UnCAL ファイルへの自動双方向変換を検討する。これ
により、各モデルを GroundTram に入力するのみの作業となり、シームレスに
トレーサビリティを保った双方向変換の自動化を実現したいと考える。
また、サブシステムのルール化も今回はクラスタリングの手法を適用したが、
より良いクラスタリング手法やソフトウェアの技術をこれからも適用して、よ
り開発者の求めるようなビューを提案できるよう努力して行きたい。
40
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
謝辞
本研究を進めるにあたり、数々のご指導を頂いた早稲田大学理工学部の鷲崎
弘宜准教授に深く感謝いたします。
また、共に研究に励み、様々な面でご協力いただいた鷲崎研究室の皆さまに
深く感謝致します。
41
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
参考文献
[1]The MathWorks: MATLAB,
http://www.mathworks.com/products/matlab
[2]The MathWorks: Simulink,
http://www.mathworks.com/products/Simulink
[3] The MathWorks: Real-Time Workshop,
http://www.mathworks.com/products/rtw/
[4]UML,
http://www.uml.org/
[5]D.N.Ramos-Hernandez,P.J.Fleming,J.M.Bass,”A novel objectedenvironment for distributed process control system,Control Engineering
Practice 13,pp213-230,2005
[6]Farkas,T.Meiseki,E.,Neumann,C.,Okano,K.,Hinnerichs,A.,Kamiya,S.,"In
tegration of UML with Simulink into embedded software
engineering",ICCAS-SICE,no10982288,pp474-479,Fukuoka,Japan,Aug200
[7] Brisolara,L.,Becker,L.,Carro,L.,Wagner,F.,Pereira,C.E.,Reis,R.,
"Comparing High-level Modeling Approaches for Embedded System
Design",ASPDAC,no8471640,pp986-989,jan2005
[8]児玉 公信,”UML モデリング入門 本質をとらえるシステム思考とモデリン
グ心理学”,日経 BP 社,2008
[9] Keith Cassell, Peter Andreae, Lindsay Groves,” A Dual Clustering
Approach to the Extract Class Refactoring”, Proceedings of the 23rd
International Conference on Software Engineering and Knowledge
Engineering, SEKE 2011
42
早稲田大学理工学研究科
平成 24 年度卒業論文
情報理工学専攻 鷲崎研究室
――――――――――――――――――――――――――――――――――――――――
[10]GroundTram,
http://www.biglab.org/
[11]nxtOSEK,
http://lejos-osek.sourceforge.net/jp/index.htm
[12]教育用レゴマインドストーム NXT,
http://www.legoeducation.jp/mindstorms/
[13]NXTway-GS 倒立振子制御 C API 解説書
http://lejos-osek.sourceforge.net/jp/NXTway_GS_C_API.pdf
[14] astah,
http://astah.change-vision.com/ja/
[15] L.B. Brisolara, M. F. S Oliveira, F. A. Nascimento, L.Carro, F. R. Wagner,
“Using UML as a front-end for an efficient Simulink-based multithread code
generation targeting MPSoCs”, 4th International UML DAC Workshop:
UML for SoC Design (UML -SoC‘07), 2007.
[16]吉田聡,上田賀一,中島震,”UML と Simulink のモデル変換手法の提案”,電子情報
通信学会技術研究報告,ソフトウェアサイエンス 109,2009
[17]mtrip,
http://www.exmotion.co.jp/service/tool-mtrip.html
[18]Carl-Johan Sjostedt,Jianlin Shi,Martin Torngren,David Servat,Dejiu
Chen,Viltor Ahlsten,Henrik Lonn,”Mapping Simulink to UML in the design
of embedded systems:Investigating scenarios and transformations”,OMER 4
Post Workshop Proceedings,2008
43