狠狠撸

モデル駆動開発を実践する
～BridgePointは再び脚光を浴びるのか？～
土樋祐希（xtUML.jp）
1

本日の内容
? 自己紹介
? xtUML.jpについて
? BridgePointの概要
? BridgePoint(xtUML)のモデリング
? BridgePointを現場に導入するには？
2

名前：土樋祐希（つちといゆうき）
某複合機メーカー勤務
ETロボットデザインコンテスト(ETロボコン)本部審査員
経歴
● 97年入社
● 主に複合機のコントローラソフトウェア開発に従事
● 入社２年目位からシュレアーメラー法（現xtUML)研究会に参加
その影響を受けて自モジュールにBridgePointを適用したいと提案し、その立ち上げに
携わる（主に当時の先輩のフォロー）。2000年におそらく日本で初めてBridgePointを使った
製品を市場導入
● 以後自モジュールのモデリングや、変換ルールの改善を行うとともに社内で
モデリング勉強会なども行う
● BridgePointがOSSとなったため、xtUML/BridgePointの利用拡大を目指し、2015年に
xtUML.jpを立ち上げ、現在に至る
● その他の活動として、若手教育のため社内でETロボコン活動を推進（2010年から）
2015年度から本部審査委員として活動を開始
自己紹介
3

xtUML.jpとは
? xtUMLはeXecutable Translatable UML（実行可能で変換可
能なUML)のこと
? 以前はシュレアーメラー法と呼ばれていた
? BridgePointはxtUMLの方法論に従ったツール
? アメリカではxtUML.orgというコミュニティが
存在し、xtUMLやBridgePointの議論をしている
? xtUML.jpは日本でのxtUML/BridgePointの習得?普及を
目指し2015年に設立されたコミュニティ
? Facebookのグループとして活動し、
現在48名のメンバーが在籍
? 最近はチュートリアルを作成中
? 随時メンバー募集中！
https://facebook.com/groups/xtuml.jp
メラー氏を囲んで
4

モデリングの課題
? UMLモデルは書いてレビューはするが、あいまいな部分が残り、
後工程で検討漏れが起きてしまう
? 実際に動かすわけではないので、何となく大丈夫そうだろうと
いうことで、そのまま進めてしまう
? APIやインターフェースといった要素のみに着目しそのドメインが
持つ特性についての分析が不足する
? 分析モデルを作っても、それがどう実装までつながるかが分か
らず、実装に直結する要素を中心にモデリングしてしまう
? 実装工程に入るとモデルとコードが乖離する
? 不具合が発生した場合コードのみ直して、モデルを直さない
モデルを作っても、結局コード依存の開発になってしまう
保守性も上がらず、モデルを作る意義が低下する
5

BridgePointを使うと、、、
? UMLモデルは書いてレビューはするが、あいまいな部分が残り、
後工程で検討漏れが起きてしまう
?モデルの段階で動作を行わせることができるため、早期に
抜け漏れを検出することができる
? APIやインターフェースといった要素のみに着目しそのドメインが
持つ特性についての分析が不足する
?実装の細かい部分は変換ルールで補完されるため、抽象度の
高い分析モデルに注力しやすい
? 実装工程に入るとモデルとコードが乖離する
?モデルから変換によってコードを生成するため、常にモデルと
コードが一致する
BridgePointを使うことで、モデルに注力した開発がしやすくなる
6

BridgePointの概要
BridgePointはどういうものか？
7

BridgePointとは
? BridgePointはxtUMLの方法論を取り入れたツール
? xtUMLはモデルを実行したり変換するためのUMLプロファイ
ルの一つ
? モデルを記述し、モデルのまま動作させ、最終的には
モデルをソースコードに変換する
? もともとはMentorGraphics社の製品だったが、2014年から
オープンソースとなり、誰でも使える環境となった
? xtuml.orgにて各種の情報を得ることができる
? Eclipse上で動作する
? モデルを記述するModel Builder、
モデルを実行するVerifier、
モデルを変換するModelCompilerからなる
8

BridgePointで記述するモデル要素
クラス図
ステートマシン図
クラス図で状態を持つものは
ステートマシン図を記述
xtUMLに
基づいた記述
ステートの中のアクションを
専用のアクション言語で記述
アクション記述
9

BridgePointのモデルはそのまま動作する①
（イベントとステートマシン）
? xtUMLではプロファイルとして実行のためのセマンティ
クスが決まっている
例）
- イベントは非同期に送信される（キューが存在する)
- 各ステートのアクションは、そのステートに遷移した
場合に実行される（Entryアクション)
- ステート内のアクションの実行が終わるまで、その
オブジェクトに送信されたイベントはキューに保留
される
通常のUMLでは遷移を起こす
のが非同期であるか、同期で
あるかはモデルだけではわか
らない（実装時の判断）
他にもガード条件による遷移
などもある
xtUMLではモデルのプロ
ファイルとして左の遷移
は非同期なイベントに
よって引き起こされるこ
とが決まっている
10

BridgePointのモデルはそのまま動作する②
（アクション言語）
? xtUMLではロジックをアクション言語で記述する
? アクション記述は一見プログラミング言語と同様に感じる
部分もあるが、以下のような抽象度の高い記述ができる
項目構文例意味
インスタンスの作成 create object instance aFoo of
FOO;
FOOクラスのインスタンスを作成
し、そのハンドルをaFooとする
インスタンスの検索
（複数）
select many foos from instances of
FOO where selected.value > 5;
FOOクラスの集合から属性value
が５より大きいものを選択する
イベントの送信 generate FOO1:start to aFoo; aFooというインスタンスにstartと
いうイベントを非同期に送信する
（FOO1はイベントラベル）
インスタンスの関連付け
（リンクの作成）
relate aFoo to aSome across R1; aFooというインスタンスとaSome
というインスタンスの間にR1の関
連を張る（リンクを作る）
インスタンスのリンクに
よる取得
select any aFoo related by
aSome->FOO[R1];
aSomeとR1の関連にあるFOOイ
ンスタンスを取得し、aFooとする
11

BridgePointのモデルはそのまま動作する③
（Verifier）
? BridgePointにはモデルを実行するVerifierというツールがある
? VerifierはxtUMLのセマンティクスに従ってモデルを解釈し
実行する（アクション言語もコンパイルは行わず、直接解釈し
実行される）
? 実行により作成されたインスタンスやその属性、状態、関連
などをチェックできる
? モデルを作って、すぐに確認というプロセスを素早く回せる
現在いる状態がハ
イライトされる
作られているイン
スタンス/リンクの
一覧が見える
12

BridgePointのモデルは変換可能①
（Metamodel）
? BridgePointのモデル要素はメタモデルをスキーマとし
たデータベースの要素として蓄積される
クラス{O_OBJ}
ID
名前
Key_Letter
属性{O_ATTR}
名前
1
* ～によって特徴づけられる
データ型{O_
名前
1
*
～を型とする
メタモデル（簡易版）
R102
R114
モデルの記述 :クラス
ID = 1
名前 = Foo
Key_Letter = FOO
:属性
名前 = 名前
:属性
名前 = 長さ
:データ型
名前 = string :データ型
名前 = integer
蓄積されるデータ
実際はSQL形式で保存されている 13

参考：実際のメタモデル
BridgePointのメタモデル自体もBridgePointのモデルとして参照できる
クラス部分のメタモデル
14

BridgePointのモデルは変換可能②
（ModelCompilerによるコード変換）
? ModelCompilerはモデルによって生成されたデータと、
変換ルール、Markingファイルをインプットとして、
コードに変換を行う
INSERT INTO SM_ISM
VALUES ("eed0171e-
e271-4f10-a6e5-
60b8dbd4ed0f",
"5d97448f-9436-4f71-
9847-53c6c18a530e");
：
Model
Compiler
.invoke
MarkClassToTask("","",“FOO",1)
.invoke
MarkClassToTask("","",“SOME",2)
変換ルール
Markingファイル
Modelコンパイラに変換
のカスタマイズを指示す
るためのファイル
モデルデータ
変換
データアクセスと
生成するコードのテンプ
レートが定義される
変換コード
（.cなど）
15

BridgePointのモデルは変換可能③
（変換ルール）
? 変換ルールはデータベースへのアクセスと、変換に
使用するテンプレートを定義したもの
? BridgePointでは変換ルール記述用の言語である
RSL(Rule Specification Language)で記述する
?アクション記述に近い構文
.select many classes from instances of O_OBJ
.for each aClass in classes
.select many attrs related by aClass->O_ATTR[R102]
.for each anAttr in attrs
${aClass.Name}.${anAttr.Name}
.end for
.end for
.emit to file "test.txt"
変換ルールの例
「.」で始まる青字がデータ
アクセス部分
赤字がテンプレート部分
ModelCompilerに
よる変換
Foo.名前
Foo.長さ
test.txt
テキストならなんにでも変換
できるので、c言語だけでなく
htmlでもjavaでも変換可能 16

BridgePointを使った開発プロセス
? BridgePointを使った開発プロセスは、大きく分けてドメインモデルを作
るプロセスと、変換ルールを構築するプロセスからなる
? これらは独立して作業することが可能
2.Verifierで
動作確認
1.分析モデル
作成?修正
Markingファイル
3.モデルから
コードに変換
4.実機での
動作確認
ドメインモデルの構築
1.実装プラット
フォームの調査
2.変換方法設計
変換コードI/F
実装設計
3.変換ルール
ライブラリコード
Marking使用方針
変換ルールの構築
モデルを作成し、すぐに動作さ
せる事で素早く品質を高める
モデルと一致する
コードが生成される
実機での確認で不具合が出た
場合はモデルを修正する
? モデルとコードが常に一致
変換ルールはドメインモデルと
は無関係に作成されるため、
他のモデルに適用可能
動作確認で変換ルール側に
変更を依頼することも有る
17

BridgePoint(xtUML)のモデリング
モデリングはどう変わるか？
18

xtUMLのモデリング
? xtUMLはUMLのサブセットであるため、記述
できる表記が少なく、自由度が低い
? ステートマシン図で状態の入れ子ができない、
仮想関数が定義できないなど
? そのため、記述が冗長になりがち
? しかし、コード変換を前提とできるため、分析モデ
ルを厳密に記述することに価値が出てくる
? どう実装するか、ではなく対象となるドメインの
要素を正しく抽出できているかが重要
? 特にクラス図で情報の構造を正しく出すことは
ソフトウェアの安定につながる
19

? 私たちは意外と理解しているようで理解していない
? 図書館における本の貸し出しについて考える
? 下記のモデルはどうだろう？
モデルによって理解を深める
このモデルで進むときっといろんな手戻りを生じる
20

? 属性が足りないため各クラスが何を示しているか曖昧
? 関連端名がなく、どのような関係を表しているか多重度が
適切なのかわからない
? 現在借りている本を示しているのか、これまで
借りたことがある本なのか？
何がいけないのか？
ある人の現在借りている本一覧取得
select many borrowingBooks related by aPerson->BOOK[R1];
ある人の借りたことがある本一覧取得
同じになるの
はおかしい
21

関連と多重度
? 関連を作る際、その意味と多重度を重視する
? 関連端を必ず付ける。その際、ロールではなく動詞句を使うことが多い
（意味を考える際、ロールだとうまく命名できないことがあるため）
? 関連には識別子を付け、意味によって関連を分ける
? メソッドを呼び出すということではなく、あくまでも意味的な関連を分析する
? レビューをする際にはこれらの要素が意味的に正しいかを検討する
? 関連端が適切か、その意味に対する多重度が適切か（0を含むかどうか
も含めて）を調べることで、概念の理解不足を抽出できることが多い
チーム
名前
地区
メンバー
名前
年齢
1 1..*
～から構成
される
～に所属する
R1
～の主将
である
R20..1
～を主将
とする
1
主将でないメンバーは
R2のリンクが作られな
いので1ではなく0..1
関連の識別子
チームには必ず主将が
いるとすれば1、決まら
ない時期を許容するな
ら0..1

ちょっと変えてみる
? 関連を分離
ある人の現在借りている本一覧取得
ある人の借りたことがある本一覧取得
なんかよさそう？
23

? クラスを書いたらそのインスタンスを考える
? インスタンスはオブジェクト図でもいいが、
分析モデルではインスタンス表を使うとよい
?xtUMLは原則属性をPrimitiveなものとして扱うため、
こうした取り扱いが可能（一応構造体も使えはする）
? 列が属性で、行がインスタンスとなる
インスタンスを考える
ID title(タイトル) borrowinState
(貸出状態)
author
(著者)
publisher
(出版社)
123001 彼の名は。貸し出し中新山誠丸川文庫
123002 彼の名は。返却済み新山誠丸川文庫
541001 夢中兄弟(29) 貸し出し中大山宙哉講炎社
541002 夢中兄弟(29) 返却済み大山宙哉講炎社
24

? インスタンス表で組み合わせを考えると、同じ表として管理しない
方がよさそうな要素が見えてくる
? データベースの正規化と同じような考え方
? xtUMLではおおよそ第三正規化を行うことで、情報を一元化する
? この作業をすることで、足りない概念などを抽出できる
何がおかしい？
ID title(タイトル) borrowinState
(貸出状態)
author
(著者)
publisher
(出版社)
123002 彼の名は。返却済み新山誠丸川文庫
541001 夢中兄弟(29) 貸し出し中大山宙哉講炎社
541002 夢中兄弟(29) 返却済み大山宙哉講炎社
これらの列は同じ組み合わせで
出てきている
これらの列は個別の本ごとに
異なる属性値を持つ
25

? 関係の意味をきちんと捉えることや、属性を正規化することによって
見つけられていなかった概念を抽出できることがある（結構ある）
? 単に「本」としていたものは、著作としての概念的なもので、
もう一つ印刷された本という概念が必要（「蔵書」とする）
? クラスを分割して、関連を整理すると以下のようになる
クラスの変更
こちらは物理的な本
を表す
こちらは概念的な本
を表す
物理的な本は１回に１人にし
か貸せない
本を借りた履歴
26

妥当性確認
? モデルができたらロジックを書き、妥当性を判断する
? テスト用のアクションを書いてVerifierで動作を確認
select any aBook from instances of BOOK where selected.ID == param.ID;
if ( empty aBook )
//指定された本のインスタンスが存在しない
return false;
end if;
// 指定された本の蔵書のうち、借りられていないものを検索
select any aBorrowBook related by aBook->RBOOK[R2]
where selected.borrowingState == 0; // 1が貸し出し中
if ( empty aBorrowBook )
// すべて貸し出し中だった
return false;
end if;
// 借りられる蔵書があったので、関連と属性を更新
// 貸出状態に変更
aBorrowBook.borrowingState = 1;
// 貸りる人と蔵書を関連付ける(aMemberはmemberIDを持つインスタンスのハンドルとする）
relate aBorrowBook to aMember across R1;
// 以前借りたことがある本か？
select any aBorrowedBook related by aMember->BOOK[R3]
where selected.ID == aBook.ID;
if ( empty aBorrowedBook )
// 借りたことがない本なので、関連を張る
relate aBook to aMember across R3;
end if;
27

BridgePointでのモデリングまとめ
? モデルそのものを動作させるため、厳密な記述が必要
? その分面倒と感じるかもしれない
? モデルを書いて、すぐにアクション記述でロジックを
書き、モデルの妥当性を確認できる
? モデルからのコードへは変換によって行われるため
どう実装しようかを考えず、モデルに時間を費やす
ことができる
? 関連などの精査を通じて、対象としているドメインの
理解が進む
? 後工程で手戻りが少なくなる
28

BridgePointを現場に導入するには？
どうしたらBridgePointを使えるようになるか？
29

BridgePointが導入されると
? 常にモデルからコードが生成されるため、モデル部分はコードを見なくて
よくなる
? レビューもモデルとアクションのみで済む
? コードと一致するモデルがあるため、引き継ぎもしやすい
? 変換ルールを変更することでエラーチェックや性能などの改善を一括し
て導入可能
? ベストプラクティスを後から適用可能
? モデルはデータとして蓄積しているため、他への再利用がしやすい
? モデル検査(spin/promela)への適用などの事例もあり
? 実機で発生したモデル部分の不具合は大抵の場合Verifierでも発生す
るので、再現や調査がしやすい
? どこまでモデリングすれば物が動くのかを理解できるようになる
? 通常のオブジェクト指向開発にも役立つ
30

BridgePointが適する分野?適さない分野
? 適すると思われる分野
? 各種のイベントが非同期に入ってきて、複雑な状態を扱うもの
? IoTデバイスや、情報処理を行うのはこれに当たるかもしれない
? クラス図で多重度が多となる関連が多いもの。複雑な情報を扱うもの
? インスタンスごとの振る舞いや、データのクエリーなどは
非常にやりやすい
? あまり適さないと思われる分野
? 単純なアルゴリズムやロジックなどのメソッドが中心のもの
? ロジック中心の場合はコードのほうが書きやすい
31

BridgePointを導入する上での課題
? モデルを厳密に書けるエンジニアの育成
? 通常のUMLとのギャップ
（記述可能範囲と仮想関数や属性のアクセス方法など）
? モデル外のソフトとの接続方法が分からない
（インターフェースやFunctionという仕組みでできる）
? ドキュメントがない（少ない）
? 自動生成への不信感（サイズ、パフォーマンス、信頼性）
? 実は各個人で書くよりも良い場合があるのだが、、、
? 変換ルールを作れるエンジニアがいない
（変換ルールを作る人はモデルと、実環境、メタモデル
変換ルールの書式、デバッグ方法）
? ドキュメントがない（少ない）
モデリングに関する課題
コード変換に関する課題
32

xtUML.jpの取り組み
? Facebookグループでのモデルディスカッション
? オフラインでの会合もあり
? ドキュメント不足に関してはxtUML/BridgePointに関する
チュートリアルを作成中（秋にリリース予定）
? 変換ルール/Model CompilerのサンプルとしてLEGO?
MINDSTORMS?EV3で動作する環境を提供
? モデルを書くだけでロボットを動かせる環境
ETロボコンで使用しているHackEV
33

最後に
? 今日はBridgePointとはどんなものか、またその
モデリングについて紹介しました
? モデル駆動開発(MDD)というと、コードの自動生成
ばかりが着目されがちです
? しかし、MDDの本質はモデルの抽象度を上げ対象となる
ドメインの分析に注力できることです
? 「自動生成なんておまけです、偉い人には
それがわからんのです」
? 導入のハードルは高いかもしれませんが、オブジェクト
指向開発の基本的な考え方を学ぶ事ができるため、
チャレンジしてみてください！
ご清聴ありがとうございました
34

狠狠撸

20170706 04 bridgepointて?モテ?ル駆動を実践する

More Related Content

20170706 04 bridgepointて?モテ?ル駆動を実践する

Editor's Notes