Bits&Chips Software Engineeringカンファレンスにて"MDSE in the real world"と題したセッションで何人かの発表者がモデル駆動ソフトウェアエンジニアリングについて発表した。InfoQは以前、Wayne Lobb氏に公式的な手法を使って明確に正しいソフトウェアを開発することについてインタビューした。また、Hans van Weezep氏には、Philipsがどのようにしてモデルベースマイグレーションアプローチをレガシーソフトウェアのメンテナンスに使っているのかについて話を聞いた。
InfoQはこのカンファレンスのでMDSEのセッションのホストを勤めた、VerumのCEOであるRob Howe氏にインタビューをし、モデル駆動ソフトウェア開発の現在の状況やこの開発手法の使われ方について話を聞いた。また、モデル駆動ソフトウェアエンジニアリングが成熟した技術になるかどうかについての氏の考えやこの開発手法が将来もたらしてくれるものについても話を聞いた。
InfoQ: モデル駆動ソフトウェア開発に馴染みのない読者に説明をしていただけますか。
Howe: 一貫した名前はないというのが事実です。"モデルベースソフトウェア開発"、"モデル駆動ソフトウェアエンジニアリング(MDSE)"、"モデル駆動開発"などと呼ばれますが、さまざまな呼び名があるということは、この言葉が何を意味しているのか明確になっていないということを表しています。私自身はMDSEとは、ソフトウェア開発者が要件やアーキテクチャ、設計情報が(情報の"エントロピー"という観点で)で最大限秩序づけられており、保持されるような抽象的なレベルで開発ができるということです。さらにMDSEは開発者に"設計作業の成果物"の観点で調査、検証をする方法を提供します。
別の言い方をすれば、モデリング言語と支援ツールが精確かつ明確にソフトウェアシステムの設計に関連する重要な情報をすべて捉えるということです。モデリング言語と支援ツールを使えば、エンジニアは自分たちが作った"設計の成果物"に基づいて、ソフトウェアの設計と実装を推理し、検証し、コードを生成することができます。
私の考えはモデル駆動の手法を規約に従ったプログラミングによる開発の代替として用いることにあります。しかし、Bits&Chips Software Engineeringカンファレンスでのさまざまなプレゼンが明らかにしたように、実際にはふたつの関連した関心事があります。1) モデル駆動ソフトウェアエンジニアリングと2) モデルベースシステムエンジニアリングです。ひとつ目はモデリング手法をプログラミングの代替として使うことに注力しています。ふたつ目はモデリング手法を(ソフトウェア)システムの属性を定義し検証するために使います。このふたつには明らかに関連があります。しかし、大きな違いもあります。Angelo Hulshout氏がこの違いについてBits & ChipsでModel-driven - van navelstaren naar toekomst voorspellen (ドイツ語、無料の登録が必要)と題した記事で書いています。
InfoQ: モデル駆動ソフトウェアエンジニアリングの世界の最新情報を教えてください。
Howe: Prof Jan Friso Groote氏(アイントホーフェン工科大学)は、モデリング手法を適用するのに技術はもはや制限要素にはならない、と言っています。私は彼に賛成です。近年、私たちの地域でも、MDSEのさまざまな側面に対応するツールが現れています。CIF(アイントホーフェン工科大学)、POOSL(ESI/ASML)、CARM (ASML)、ASD:Suite/Dezyne (Verum)などです。さらに広く見ると、多くの企業で、Mathworksのツールが使われています。直面している課題は次の2つです。
1) 市場にこのようなツールを幅広く投入する方法。商業ベースなので、ツールはサービス品質保証とさらなる開発をして顧客に提供する。
2) 断片的になってしまっているさまざまなツール群を統合すること。
InfoQ: どのような製品の開発に使われているのでしょうか。
Howe: 大まかに言うと、ソフトウェアがする仕事は3つのタイプがあります。a) データ処理 b) 計算 c) 離散制御の3つです。Mathworksは多かれ少なかれ、計算のためのモデルベースソフトウェア設計の市場を持っています。また、アルゴリズム設計にMatlabを使っている企業も多いです。
離散制御というのはあまり明確ではありません。組み込みの市場では、離散制御が流行っています。私がコンタクトをとった企業のうち30%だけがこの種のソフトウェアの設計にツールを使っていました。大半の企業は複雑な振る舞いをする製品を設計しています。アイントホーフェンでは、ウェハステッパや医療機器、プリンタなどのハイテク装置などが議論の的です。しかし、多くの企業が次第に複雑になるソフトウェアの振る舞いには新しいエンジニアリングの手法を導入するべきだと考えている企業は多くありますので、チャンスは大きいです。
現時点ではデータモデリング手法を使っている企業は少ないです。この分野はツールの提供が少なく、小さな価値しか提供していないからです。
InfoQ: モデル駆動ソフトウェアエンジニアリングは証明された、成熟した技術だと思いますか。
Howe: MDSEはまだ、ソフトウェアエンジニアリングに対して包括的なソリューションを提供できていません。これから10年以上経っても変わらないでしょう。しかし、MDSEを実践したいという企業に対しては巨大な価値を提供できるソリューションにはなっています。また、MDSEがソリューションを提供し、MDSEを導入するべきビジネス上の理由がたくさんある領域では、MDSEを実践しない技術的な理由はありません。エンジニアが信頼できる強固なシステムを現実的な時間内で提供しようとすれば、モデル駆動のツールや手法なしでは対処できない複雑さもあるのです。
特に、私はアルゴリズム設計(例えばMatlab)や離散制御(例えばASD:Suite/Dezyne)に大半の側面に対しては、MDSEが明確な価値のあるソリューションを提供すると思います。
InfoQ: モデル駆動ソフトウェアエンジニアリングは将来、私たちに何をもたらしてくれるでしょうか。
Howe: 今はMDSEの黎明期だと思います。次の5年から10年で私たちはMDSEへの大きなシフトを経験すると思います。2010年代の終わりには、60%から80%のソフトウェアがモデルベースの手法を使って設計されているのではないでしょうか。MDSEそのものはより同じようなものになり、異なるベンダが開発するツールを一緒に使うこともできるでしょう。ひとつのツールや言語はトータルなソリューションを提供しません。ソフトウェアエンジニアリングの世界には"エスペラント"はないのです。設計の検証はルーチン作業になり、スコープも広がるでしょう。要件やユースケースの検証は次第に自動化されます。市場に出回るツールが増えれば、MDSEのスコープ全体も広がるでしょう。
しかし、これらのことが既存のレガシーコードに対してどのような影響を与えるのかが大きな疑問です。近い将来にレガシーコードを自動でモデルに変換するツールが現れるとは思いません。理由はシンプルで、レガシーコードはその本性からして混乱したシステムであり、モデルが表現するのはしっかりとした秩序があるシステムだからです。熱力学では仕事をしなければ、無秩序なシステムをより秩序があるシステムにすることはできません。それゆえ、コードをモデルへ変換するのは手動で干渉し注釈をつける必要があります。可能な限り、手動の仕事を減らし、単純にするツールを提供するのが鍵になるでしょう。
最終的には、私は賠償や立法もMDSEの導入に影響されると思います。トヨタのケースでは、ソフトウェアの欠陥に対する賠償請求に対する防御は現在の最良のソフトウェアエンジニアリングを使っているという判例になりました。フォーマルなMDSEの設計の検証は最良の方法であり、市場がMDSEを受け入れるために必要でしょう。