モデル駆動開発プロセス審査 初審査を終えて - 九州

九州特別プロジェクト:
モデル駆動開発プロセス審査
初審査を終えて
久住 憲嗣
ETロボコン九州地区 審査委員
モデル駆動開発プロセス審査 審査委員長
九州大学 システムLSI研究センター
審査委員
赤山聖子 九州技術教育専門学校
甘田 哲久 （株）コア 九州カンパニー
小田原 諭 （株）福岡CSK
塚田 雄一 キャッツ（株）
審査の背景
!   大きな目的
!   モデル駆動開発を導入し，利用できる技術者の育成
!   なぜ？
!   開発コスト，納期，品質への激しいプレッシャー
!   自動化技術を利用して開発しない限り，日本のソフト産業に未来はない
!   具体的な目的
!   ETロボコンを通して，自動化技術の導入や利用のセンスをみがく
!   どのように働き方を変えたら良いのか？を体感する
!   自動化技術が実用的であることを実感する
2
設計モデル
ソースコード
モデルを動作させて
テストできないの？
（半分でもいいから）
自動化できないの？
モデル駆動開発 (Model Driven Development; MDD)
モデルを使って開発を楽にする方法です
3
モデル？？？開発
モデル駆動開発
モデルベース開発
概 ソフトウェア工学が基礎
要 UML等を利用
制御工学が基礎
ブロック線図を利用
得 システムの全体構造を整理する
手 離散的な振る舞い
連続的な振る舞い
不
連続的な振る舞い
得
手
システムの全体構造を整理する
離散的な振る舞い
排他的なものではなく、組み合わせて利用することが重要
4
モデルの様々な利用方法
! スケッチとしてのUML
!   コミュニケーションの道具
!   設計図としてのUML
!   設計 → スケルトン生成、コードの可視化
!   シミュレーションによる設計検証
!   プログラミング言語としてのUML
!   コード生成
!   シミュレーションによる検証
詳細度
5
様々なモデルの利用
リバース
モデリング
ラウンド
トリップ
コンパイル
モデル
モデル
モデル
モデル
コード
コード
コード
コード
コード
製品
製品
製品
製品
製品
コードのみ
モデルが乖離
6
従来型開発とモデル駆動開発の比較
!   従来型開発 (aka ソースコード中心の開発)
!   要求仕様書、設計文書をもとにソースコードを開発
!   上流での要求仕様書や設計文書の正しさを担保するのはレビュー
!   実際の製品の品質保証をするのは「テスト」
!   開発の半分以上がテスト・・・
!   要求仕様書・設計文書とソースコードの一貫性を保つのは困難
!   開発者にはドメイン知識と実装知識の両者が必要
!   モデル駆動開発
!   要求レベル、設計レベルのモデルを作成
!   モデルから（ある程度は）自動的にソースコードを生成
!   上流での検証が比較的容易
!   機械可読なモデルがあるのでシミュレーションが可能
!   自動的にソースコードを生成するので、モデルとコードの一貫性保持が容易
!   ドメイン知識を持つ人、実装知識を持つ人とで、分業が容易
7
審査基準 〜その思い〜
!   導入プロセス
!   どうやって，どこにMDDを使ったら良いか，難しくないですか？
!   既存資産をどのようにとらえたら良いか，難しくないですか？
!   どのようなチームを作って役割分担をしたら効率的だと思いますか？
砂場としてのETロボコンを最大限活用して，
!   開発プロセス・成果物
これらの課題に挑戦してほしいと考えました．
!   MDDに適したソフトウェアアーキテクチャってありますよね？
!   自動生成や上流でのシミュレーション検証などはうまく使えましたか？
さらに，情報共有して地域のレベルアップにつ
!   効果を証明しろ!
と良くいわれますよね．
なげたい．
!   加点評価
!   ひとつでもやっていることがあれば，加点する．
8
審査対象
!   申請 3チーム + 2チーム
!   なるべくひろって審査しました
!   傾向
!   ラウンドトリップ型のMDD × 1チーム
!   コンパイル型のMDD × 2チーム
!   非自動化型のMDD × 1チーム
9
傾向
詳細度が足りない・・・
なんとなくは目的は書
けているが・・・
導入・設計指針
3
2.5
2
オリジナリティ
既存資産活用
1.5
定性的評価も書けて
いないところが多い
・・・がリファクタリング
に活用できていると
ころも
既存資産の活用も十
分ではない
1
0.5
0
適用効果
設計内容
設計内容が十分に示
されていない
上流での検証にはうま
く活用できていない
検証手法
一貫性
自動生成ができている
10
ところはできている
MDDの目標
その効果
11
KFKF
!
1.#
#
#
#
MDD
!
1.#
Bridge#Point
Bridge#Point
MDD(
!
#
)
#
#
MDD
○
#
#
Bridge#Point
#
○
#
#
#
MDD
#
#
#
2.#
○
#
12
#
#Bluetooth
PC
#
#
KTEC(1)
13
計算は『仮想計器』に任せる！
計算に関する部分は、手書きのソースコードの方が長けている
ので、その手書きのソースコードの関数群をブリッジ ( 外部実体 ) に
alt 特殊走行分岐
登録することで、BridgePoint の中の世界で使用可能に。
KTEC(2)
opt チェックポイント到達
また、NXTOSEK の API の関数群もブリッジに登録した。
外部実体として登録したものを大きく分けると、
「仮想計器」「制御」「走行関連」「通信関連」の４つに分けられる。
「仮想計器」と「制御」に関してはオリジナルで、
『仮想計器」』に距離計、速度計、座標計算に関する関数群を登録、
Point!
『制御』に関しては「P 制御」「PD 制御」「PID 制御」などの制御に関する関数群が登録されている。
Point!
走行ラインをトレースする、基本走行についての振る舞い。
通常走行から特殊走行への移行についての振る舞いです。
制御量・路面情報のオブジェクトを介して、走行に必要な旋回量を随時算出。
ナビゲーターのオブジェクトから取得した戦略ＩＤに応じて、
特殊走行の振る舞いを切り替え可能です。
クラス図
走行タスク
特殊走行
衝立検知タスク
通信タスク
4 ページ（要素技術）
ポイントチェッカーの詳細は、
「自己位置推定と座標補正方法」にて
Attention!
Executable UML で記述されています
段差検出・障害物検出の詳細は、３ページ（振る舞い）
通信部の詳細は
5 ページ（並行性設計・オリジナリティ）
「NXT ロギングソフトウェア」にて
「シーソー・階段」「ルックアップゲート・ＥＴ相撲」にて
5 ページ（並行性設計・オリジナリティ）
実験の詳細は、
・クラス図の関連名は関連番号で記載されています。
・クラス図の関連端名は動詞句で記述してあります。
「超音波センサ性能分析」にて
14
○MDDによるタスク割り当て
×目的，効果が示されていない
×設計過程，周期などが示されていない
ちーくま
○上流での検証に利用
○プロセスを提示
× 効果
15
まとめ: 書き方について
!   書き方のヒント
!   なぜ適用したのか？
!   技術適用の目的を明らかにしないと，その後のすべての活動の位置づけが曖昧
になる
!   どのように適用したのか？
!   結論に至った過程をモデルに書かないと，正しいかどうかが評価できない
!   その効果はどうだったのか？
!   定性的にでも良いので，結果を示さないと，ただの空論になる
!   目的と結果はバランスとれてますか？
!   ノウハウを共有できる詳細度で記述してますか？
16
まとめ: 導入について
!   取り組みの仕方
!   1年目はとんとん or 導入分だけ時間がかかります
!   情報共有，検証などがそうとう楽に，すばやくできるようになります
!   2年目には楽になっているはずです
!   まずはラウンドトリップ型で，既存資産を見える化するところから
!   ソースコードをクラス図にするところから始めましょう
!   チームで働きやすくなります
!   再利用しやすくなり，差分開発がしやすくなります
!   リファクタリングも進みます
!   次は良く変更するクラスの振る舞いを自動生成しましょう
!   走行戦略をステートマシンで記述できると，少し楽になりませんか？
17
敢闘賞
SOROT☆FCSK
18