SysMLツールベンダー３社揃い踏みシステムモデリング事例＆ツールセミナーのリンク

2014/9/26に開催された「SysMLツールベンダー３社揃い踏みシステムモデリング事例＆ツール」セミナーのリンクをメモしておく。

【元ネタ】
SysMLツールベンダー３社揃い踏みシステムモデリング事例＆ツールセミナー | 株式会社オージス総研

つれづれなる技術屋日記: SysMLツールベンダー3社揃い踏みセミナー

日々精進 - スパークスシステムズ ジャパン代表のBlog:9/26 SysMLセミナー 報告&感想 - livedoor Blog（ブログ）

日々精進 - スパークスシステムズ ジャパン代表のBlog:9/26 SysMLセミナーやります！ - livedoor Blog（ブログ）

日々精進 - スパークスシステムズ ジャパン代表のBlog:SysML関連 情報2件 - livedoor Blog（ブログ）

インタビュー＆トーク - 日本でも導入が始まるSysML、モデルベース・システムズエンジニアリングの基盤に：ITpro

【感想】
僕は参加していないのでネットで感想の記事を探してみたが、有用な記事はつれづれなる技術屋日記: SysMLツールベンダー3社揃い踏みセミナーの1件だけだった。
記事を読んで興味を引いたのは以下の通り。

【1】一つは、SysMLのようなモデリングツールはいじっていて楽しいので、「モデル設計で仮想的に動くのが面白くなって設計過剰になったり、かえって時間を浪費する」リスクがあること。

特に、SysMLでは、パラメトリック図を使ってシミュレーションする機能がモデリングツールにあったりするので、本来の設計を忘れて、シミュレーションが楽しくなってしまう、というリスクもあるのだろう。

僕も経験があるが、UMLは確かに設計技法として見習うべき点は数多くある。
しかし、UMLで表現できない部分もあり、UMLだけでは設計は十分とは言えない。
特にUMLが弱い部分は、サーバーやネットワークなどの配置図を表現しにくいことや、例外処理や代替処理(例えば、拡張ユースケース(extend))をすべて表現するのが難しいことがあると思う。
他にも、性能要件や使用性、要求管理、ER図などのデータモデリング、などはUMLでカバーできない。

UMLでシステム情報をすべて表現しようとすると、各ダイアグラムを粒度に合わせて階層化する必要があり、各ダイアグラムのトレーサビリティを確保するのが難しくなる。
1つの箇所を触ると、他のダイアグラムも影響を受けて、修正部分が増えてしまうのだ。
そして、どんどん、UMLで書いた設計図が複雑になり、設計の意図の伝達よりも保守のコストの方が上回ってしまい、最終的には保守されずに使われなくなる。

最新の仕様が反映されていない設計図や設計書ほど、扱いにくいものはない。
UMLは、設計のスケッチとして使うのが用途として一番いいだろうと思う。

【2】もう一つは、ソフトウェアとハードウェアの境界があいまいになり、IoTのようなバズワードが広がる状況で、メーカーがSysMLを使って、モデリング→製品の高速化を図り、工場のIT化を目指す動きがあること。

ドイツが目指しているインダストリー4.0にも関連しているらしい。
この辺りの動きは全く知らないけれど、普通の人がスマフォを持っていて、いつでもどこでもネットでつながる環境になった状況では、メーカーは、より一層、ハードウェアよりもソフトウェアに注力して、製品開発をより高速化し、頻繁な機能改善に耐えうる製品設計が必要になってくるのだろう。

インダストリー4.0とは何か？：日経ビジネスオンライン

ドイツの「インダストリー4.0」政策に感じる既視感 - WirelessWire News（ワイヤレスワイヤーニュース）

インダストリー4.0：ドイツが描く第4次産業革命「インダストリー4.0」とは？【前編】 (1/4) - MONOist（モノイスト）

おそらく、SysMLを担いでいる人は、SysMLでモデリングできたら、プログラムを自動生成できて、製品開発をより高速化できるというイメージを持っているのだろうと思う。
それは、以前夢見ていた、「モデルからソースを自動生成すれば、プログラミング工程は不要になる」モデル駆動開発と何が違うのか？
そのモデル駆動開発の失敗経験を踏まえて、SysMLはどのように成長してきたのか。

今後も調べてみる。