Recommended
More Related Content
What's hot
What's hot (20)
20170706 04 bridgepointでモデル駆動を実践する
- 2. 本日の内容 自己紹介 xtUML.jpについて BridgePointの概要 BridgePoint(xtUML)のモデリング BridgePointを現場に導入するには？ 2
- 3. 名前：土樋 祐希（つちとい ゆうき） 某複合機メーカー勤務 ETロボットデザインコンテスト(ETロボコン)本部審査員 経歴 ● 97年入社 ● 主に複合機のコントローラソフトウェア開発に従事 ● 入社２年目位からシュレアーメラー法（現xtUML)研究会に参加 その影響を受けて自モジュールにBridgePointを適用したいと提案し、その立ち上げに 携わる（主に当時の先輩のフォロー）。2000年におそらく日本で初めてBridgePointを使った 製品を市場導入 ● 以後自モジュールのモデリングや、変換ルールの改善を行うとともに社内で モデリング勉強会なども行う ● BridgePointがOSSとなったため、xtUML/BridgePointの利用拡大を目指し、2015年に xtUML.jpを立ち上げ、現在に至る ● その他の活動として、若手教育のため社内でETロボコン活動を推進（2010年から） 2015年度から本部審査委員として活動を開始 自己紹介 3
- 4. 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
- 5. モデリングの課題 UMLモデルは書いてレビューはするが、あいまいな部分が残り、 後工程で検討漏れが起きてしまう ⇒ 実際に動かすわけではないので、何となく大丈夫そうだろうと いうことで、そのまま進めてしまう APIやインターフェースといった要素のみに着目しそのドメインが 持つ特性についての分析が不足する ⇒ 分析モデルを作っても、それがどう実装までつながるかが分か らず、実装に直結する要素を中心にモデリングしてしまう 実装工程に入るとモデルとコードが乖離する ⇒ 不具合が発生した場合コードのみ直して、モデルを直さない モデルを作っても、結局コード依存の開発になってしまう 保守性も上がらず、モデルを作る意義が低下する 5
- 6. BridgePointを使うと、、、 UMLモデルは書いてレビューはするが、あいまいな部分が残り、 後工程で検討漏れが起きてしまう ⇒モデルの段階で動作を行わせることができるため、早期に 抜け漏れを検出することができる APIやインターフェースといった要素のみに着目しそのドメインが 持つ特性についての分析が不足する ⇒実装の細かい部分は変換ルールで補完されるため、抽象度の 高い分析モデルに注力しやすい 実装工程に入るとモデルとコードが乖離する ⇒モデルから変換によってコードを生成するため、常にモデルと コードが一致する BridgePointを使うことで、モデルに注力した開発がしやすくなる 6
- 8. BridgePointとは BridgePointはxtUMLの方法論を取り入れたツール xtUMLはモデルを実行したり変換するためのUMLプロファイ ルの一つ モデルを記述し、モデルのまま動作させ、最終的には モデルをソースコードに変換する もともとはMentorGraphics社の製品だったが、2014年から オープンソースとなり、誰でも使える環境となった xtuml.orgにて各種の情報を得ることができる Eclipse上で動作する モデルを記述するModel Builder、 モデルを実行するVerifier、 モデルを変換するModelCompilerからなる 8
- 10. BridgePointのモデルはそのまま動作する① （イベントとステートマシン） xtUMLではプロファイルとして実行のためのセマンティ クスが決まっている 例） - イベントは非同期に送信される（キューが存在する) - 各ステートのアクションは、そのステートに遷移した 場合に実行される（Entryアクション) - ステート内のアクションの実行が終わるまで、その オブジェクトに送信されたイベントはキューに保留 される 通常のUMLでは遷移を起こす のが非同期であるか、同期で あるかはモデルだけではわか らない（実装時の判断） 他にもガード条件による遷移 などもある xtUMLではモデルのプロ ファイルとして左の遷移 は非同期なイベントに よって引き起こされるこ とが決まっている 10
- 11. 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
- 12. BridgePointのモデルはそのまま動作する③ （Verifier） BridgePointにはモデルを実行するVerifierというツールがある VerifierはxtUMLのセマンティクスに従ってモデルを解釈し 実行する（アクション言語もコンパイルは行わず、直接解釈し 実行される） 実行により作成されたインスタンスやその属性、状態、関連 などをチェックできる モデルを作って、すぐに確認というプロセスを素早く回せる 現在いる状態がハ イライトされる 作られているイン スタンス/リンクの 一覧が見える 12
- 13. 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
- 15. 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
- 16. 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
- 17. BridgePointを使った開発プロセス BridgePointを使った開発プロセスは、大きく分けてドメインモデルを作 るプロセスと、変換ルールを構築するプロセスからなる これらは独立して作業することが可能 2.Verifierで 動作確認 1.分析モデル 作成・修正 Markingファイル 3.モデルから コードに変換 4.実機での 動作確認 ドメインモデルの構築 1.実装プラット フォームの調査 2.変換方法設計 変換コードI/F 実装設計 3.変換ルール ライブラリコード Marking使用方針 変換ルールの構築 モデルを作成し、すぐに動作さ せる事で素早く品質を高める モデルと一致する コードが生成される 実機での確認で不具合が出た 場合はモデルを修正する ⇒ モデルとコードが常に一致 変換ルールはドメインモデルと は無関係に作成されるため、 他のモデルに適用可能 動作確認で変換ルール側に 変更を依頼することも有る 17
- 19. xtUMLのモデリング xtUMLはUMLのサブセットであるため、記述 できる表記が少なく、自由度が低い ⇒ ステートマシン図で状態の入れ子ができない、 仮想関数が定義できないなど そのため、記述が冗長になりがち しかし、コード変換を前提とできるため、分析モデ ルを厳密に記述することに価値が出てくる ⇒ どう実装するか、ではなく対象となるドメインの 要素を正しく抽出できているかが重要 特にクラス図で情報の構造を正しく出すことは ソフトウェアの安定につながる 19
- 20. 私たちは意外と理解しているようで理解していない 図書館における本の貸し出しについて考える 下記のモデルはどうだろう？ モデルによって理解を深める このモデルで進むときっといろんな手戻りを生じる 20
- 21. 属性が足りないため各クラスが何を示しているか曖昧 関連端名がなく、どのような関係を表しているか多重度が 適切なのかわからない ⇒ 現在借りている本を示しているのか、これまで 借りたことがある本なのか？ 何がいけないのか？ ある人の現在借りている本一覧取得 select many borrowingBooks related by aPerson->BOOK[R1]; ある人の借りたことがある本一覧取得 select many borrowingBooks related by aPerson->BOOK[R1]; 同じになるの はおかしい 21
- 22. 関連と多重度 関連を作る際、その意味と多重度を重視する ⇒ 関連端を必ず付ける。その際、ロールではなく動詞句を使うことが多い （意味を考える際、ロールだとうまく命名できないことがあるため） 関連には識別子を付け、意味によって関連を分ける メソッドを呼び出すということではなく、あくまでも意味的な関連を分析する レビューをする際にはこれらの要素が意味的に正しいかを検討する ⇒ 関連端が適切か、その意味に対する多重度が適切か（0を含むかどうか も含めて）を調べることで、概念の理解不足を抽出できることが多い チーム 名前 地区 メンバー 名前 年齢 1 1..* ～から構成 される ～に所属する R1 ～の主将 である R20..1 ～を主将 とする 1 主将でないメンバーは R2のリンクが作られな いので1ではなく0..1 関連の識別子 チームには必ず主将が いるとすれば1、決まら ない時期を許容するな ら0..1
- 23. ちょっと変えてみる 関連を分離 ある人の現在借りている本一覧取得 select many borrowingBooks related by aPerson->BOOK[R1]; ある人の借りたことがある本一覧取得 select many borrowingBooks related by aPerson->BOOK[R2]; なんかよさそう？ 23
- 24. クラスを書いたらそのインスタンスを考える インスタンスはオブジェクト図でもいいが、 分析モデルではインスタンス表を使うとよい ⇒xtUMLは原則属性をPrimitiveなものとして扱うため、 こうした取り扱いが可能（一応構造体も使えはする） 列が属性で、行がインスタンスとなる インスタンスを考える ID title(タイトル) borrowinState (貸出状態) author (著者) publisher (出版社) 123001 彼の名は。 貸し出し中 新山 誠 丸川文庫 123002 彼の名は。 返却済み 新山 誠 丸川文庫 123003 彼の名は。 貸し出し中 新山 誠 丸川文庫 541001 夢中兄弟(29) 貸し出し中 大山 宙哉 講炎社 541002 夢中兄弟(29) 返却済み 大山 宙哉 講炎社 24
- 25. インスタンス表で組み合わせを考えると、同じ表として管理しない 方がよさそうな要素が見えてくる ⇒ データベースの正規化と同じような考え方 xtUMLではおおよそ第三正規化を行うことで、情報を一元化する ⇒ この作業をすることで、足りない概念などを抽出できる 何がおかしい？ ID title(タイトル) borrowinState (貸出状態) author (著者) publisher (出版社) 123001 彼の名は。 貸し出し中 新山 誠 丸川文庫 123002 彼の名は。 返却済み 新山 誠 丸川文庫 123003 彼の名は。 貸し出し中 新山 誠 丸川文庫 541001 夢中兄弟(29) 貸し出し中 大山 宙哉 講炎社 541002 夢中兄弟(29) 返却済み 大山 宙哉 講炎社 これらの列は同じ組み合わせで 出てきている これらの列は個別の本ごとに 異なる属性値を持つ 25
- 26. 関係の意味をきちんと捉えることや、属性を正規化することによって 見つけられていなかった概念を抽出できることがある（結構ある） 単に「本」としていたものは、著作としての概念的なもので、 もう一つ印刷された本という概念が必要（「蔵書」とする） クラスを分割して、関連を整理すると以下のようになる クラスの変更 こちらは物理的な本 を表す こちらは概念的な本 を表す 物理的な本は１回に１人にし か貸せない 本を借りた履歴 26
- 27. 妥当性確認 モデルができたらロジックを書き、妥当性を判断する テスト用のアクションを書いて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
- 28. BridgePointでのモデリングまとめ モデルそのものを動作させるため、厳密な記述が必要 ⇒ その分面倒と感じるかもしれない モデルを書いて、すぐにアクション記述でロジックを 書き、モデルの妥当性を確認できる ⇒ モデルからのコードへは変換によって行われるため どう実装しようかを考えず、モデルに時間を費やす ことができる 関連などの精査を通じて、対象としているドメインの 理解が進む ⇒ 後工程で手戻りが少なくなる 28
- 30. BridgePointが導入されると 常にモデルからコードが生成されるため、モデル部分はコードを見なくて よくなる ⇒ レビューもモデルとアクションのみで済む コードと一致するモデルがあるため、引き継ぎもしやすい 変換ルールを変更することでエラーチェックや性能などの改善を一括し て導入可能 ⇒ ベストプラクティスを後から適用可能 モデルはデータとして蓄積しているため、他への再利用がしやすい ⇒ モデル検査(spin/promela)への適用などの事例もあり 実機で発生したモデル部分の不具合は大抵の場合Verifierでも発生す るので、再現や調査がしやすい どこまでモデリングすれば物が動くのかを理解できるようになる ⇒ 通常のオブジェクト指向開発にも役立つ 30
- 31. BridgePointが適する分野・適さない分野 適すると思われる分野 ◦ 各種のイベントが非同期に入ってきて、複雑な状態を扱うもの ⇒ IoTデバイスや、情報処理を行うのはこれに当たるかもしれない ◦ クラス図で多重度が多となる関連が多いもの。複雑な情報を扱うもの ⇒ インスタンスごとの振る舞いや、データのクエリーなどは 非常にやりやすい あまり適さないと思われる分野 ◦ 単純なアルゴリズムやロジックなどのメソッドが中心のもの ⇒ ロジック中心の場合はコードのほうが書きやすい 31
- 32. BridgePointを導入する上での課題 モデルを厳密に書けるエンジニアの育成 通常のUMLとのギャップ （記述可能範囲と仮想関数や属性のアクセス方法など） モデル外のソフトとの接続方法が分からない （インターフェースやFunctionという仕組みでできる） ドキュメントがない（少ない） 自動生成への不信感（サイズ、パフォーマンス、信頼性） ⇒ 実は各個人で書くよりも良い場合があるのだが、、、 変換ルールを作れるエンジニアがいない （変換ルールを作る人はモデルと、実環境、メタモデル 変換ルールの書式、デバッグ方法） ドキュメントがない（少ない） モデリングに関する課題 コード変換に関する課題 32
- 33. xtUML.jpの取り組み Facebookグループでのモデルディスカッション オフラインでの会合もあり ドキュメント不足に関してはxtUML/BridgePointに関する チュートリアルを作成中（秋にリリース予定） 変換ルール/Model CompilerのサンプルとしてLEGO© MINDSTORMS©EV3で動作する環境を提供 ⇒ モデルを書くだけでロボットを動かせる環境 ETロボコンで使用しているHackEV 33
- 34. 最後に 今日はBridgePointとはどんなものか、またその モデリングについて紹介しました モデル駆動開発(MDD)というと、コードの自動生成 ばかりが着目されがちです しかし、MDDの本質はモデルの抽象度を上げ対象となる ドメインの分析に注力できることです ⇒ 「自動生成なんておまけです、偉い人には それがわからんのです」 導入のハードルは高いかもしれませんが、オブジェクト 指向開発の基本的な考え方を学ぶ事ができるため、 チャレンジしてみてください！ ご清聴ありがとうございました 34
Editor's Notes
- 必要に応じて 複数のポイントを使用する