先週、Obeoは同社の製品であるObeo Designerのメージャーアップデートをリリースした。この製品の大きな目的のひとつは、GMF (またはEMF、Eclipse Modeling Framework)の知識が無くても、Eclipse GMF (Graphical Modeling Framework)を使って、ドメイン特化モデリングツールを作成することができる環境を提供することだ。この製品は"ビューポイント"というコンセプトに基づいている。
ビューポイントとは、システムの仕様を提供する抽象的な概念であり、特定の問題群だけを表します。ビューポイントはIEEE 1471で定義されました。私たちの文脈で言えば、ユーザが特定の関心事を視覚的に表現できるようにするために利用します。
書くビューポイントには、表示やグラフィックの特徴、ツールパレット、関連する振る舞いを定義できる。表示は振る舞いとは関連しない。Obeo Designersはビューポイント同士の統合もサポートする。UMLとの統合もサポートする。UMLモデリングツールも数ヶ月後にリリースする予定だ。
InfoQは同社のJerome Benois氏とFreddy Allilaire氏に新しいリリースについて話を聞いた。
InfoQ: 企業はモデリング能力を高める必要があると考えているのはなぜですか。
Obeo: モデリングの狙いは技術を“人間が理解できる”水準まで抽象化することです。ツールは技術的な制約だけでなくビジネスの問題に焦点を当てます。Obeo Designerを使えば、ビジネスの管理者とソフトウエアアーキテクトは共通の言葉を定義し共有することができます。モデリングはコミュニケーションの一貫性に一定の形を与えます。企業のそれぞれの役割は自身の用語と関心事を基にして、一般的なのモデルを作成できます。
Obeoのモデリング手法では抽象レベルを上げるためにDSLとビューポイントを使います。システムが満たさなければならない要件と制約を分析することで、そのシステムを表すモデルを作成する手助けするのが私たちの目的です。初期のモデリングツールはMDAやUMLのような標準に対して“教条的”でした。情報技術を使ってビジネスの要求を整理するということを上手く支援できていませんでした。それぞれの場合でそれぞれのツールに合う独自の意味を適用しなければなりませんでした。妥協が必要だったのです。ツールの提供側は包括的な言語を定義する難しさに直面したのでした。
DSLは必要最小限の意味と概念を使ってドメイン毎に専用の形式を提供します。その結果、ビジネスをしっかり整理してモデリングを単純にしてくれます。しかし、すべてをDSLに頼ってしまうと、互いに分かれている複数のビジネスユニットをまたいだ大きなグループで開発を行う場合に支障が出ます。各ビジネスユニット毎にそれぞれの形式が出現してしまうかもしれないからです。それよりも、すべての利害関係者で共有できる共通の言葉、ユビキタス言語が定義できる方が役に立ちます。すべての利害関係者にとって効率的に利用できるようにするには射影的な方法が必要です。IIEEE 1471/D4.1はビューポイントという概念を使ってこの手法を構造的に定義しています。各ビューポイントは与えられた課題に焦点を当てます。この構造は明確に定義された複数の関心事に分析プロセスを分割することで、このプロセス自体を単純にします。各ビューポイントを利用することで"ビュー"を利用する分析者に必要なプロファイルを作成するための問題設定ができます。これによって異なる視点からアーキテクチャの整合性を検証できます。この方法は関心事の分離の原則に基づいています。反復的に情報を精錬しますが、主に利用するのは同じモデルの特定の用途に特化した表現です。モデルエンジニアリングとMDAはこの種の方法と最も整合性がとれます。というのは、正確に曖昧さを残さず概念を定義し、その概念に対応する統一したモデルを操作できるからです。
InfoQ: あなたの顧客がObeo Designerをつかってどのような問題に取り組んでいるのか教えてください。
Obeo: 通常、顧客はたくさんの制約がある複雑なプロジェクトの設計に共同して取り組むためにObeo Designerを使います。Obeo Designerを使うと異なる視点(論理、物理、安全性など)を分離することでたくさんのツールを開発することができます。この方法はとても包括的です。最近になってロボット工学に私たちの方法を取り入れている事例を知りとても驚きました。
ビジネスのモデリングについて言えば、例えば、私たちの製品は保険サービスや製品カタログ作成のような分野で利用されています。また、金融だと、金融アナリストが包括的な言葉でビジネスルールを定義し価格を設定するために使っています。
エンタープライズアーキテクチャに関わる分野では全社的な業務改革に使われています。この製品、戦略、ビジネス、データ、アプリケーション、技術という主要なビューポイントを使うことでTOGAFをサポートします。このモジュールはOpen Groupの仕様で定められた主要なダイアグラムとメトリクスをサポートします。
システムエンジニアリングでは、機能分析やハードウエア/ソフトウエアの一貫性に基づく検証と妥当性確認で利用されます。
非機能要求分析では、Obeo Designerは、タイミング制約解析やリスク分析の役に立ちます。
間もなくウェブサイトに事例紹介を追加する予定です。
InfoQ: グラフィカルなデザイナとテキストベースのエディタはそれぞれどんな場合に勧めますか。
Obeo: 技術的なことを好む人はテキストベースの表現の方が相性が良いでしょう。文法を基にしている私たちのほとんどにとって、計算言語は自然で効率的です。一方、図はより高度な抽象的表現を実現できます。一般的にはビジネスでは図による表現が好まれます。法則をツリー構造で表したり、箱を矢印でつなぐことでシーケンスを表現したりするのは人間にとって自然なことです。ワークフローを表現したり、飛行機を設計したりするのに図を使うのは自然です。Obeo Designerを使えば図による表現が簡単にできます。これはこの製品の重要な点です。また、テーブルやマトリクスでの表現も作成できます。図による表現とテキストによるモデリングを同じエディタ内で一緒に作成することで両方の良いところを使えます。Xtext(ドメインモデルのテキストによる表現を作成できるツール)とEEF(ドメインモデルの形式的表現を作成できるツール)との完全な互換性があります。
InfoQ: コード生成をソフトウエアの構築プロセスに導入するのは難点がありました。この点はどのような変わります。
Obeo: 初期のコードジェネレータはほとんどがブラックボックスアプローチを採用していました。この方法では特定のユーザの必要性を満たせませんでした。コードのスケルトンを生成するだけが精一杯だったのです。もちろん、エントリポイントと対応する生成されたコードの同期はすぐに失敗します。コード生成という視点からはめぼしい成果をあがらなかったのです。
コード生成は既に存在するという人もいます。コンパイラとは何なのでしょう。幸運にもアセンブリのコードを書かなければならない人は今やほとんどいません。この種のコード生成は私たちは日常的に使っています。
コード生成ツール(とりわけモデリングに基づく)は本当に進歩しました。シンプルな文法、効率的なコード生成、現代的なIDEと同じような先進的な機能を提供します。Obeo Designerではコード生成はAcceleoを使います。AcceleoはMDAの実践的な考え方から生まれたオープンソースのコード生成環境であり、Eclipse Foundationが管理しています。これはOMG標準、MOF Model to Text Languageを実装しています。自動的なアプリケーション(またはその一部)の生成を実現しますし、アジャイル開発の環境にも相性が良いです。アプリケーションの構造を変更するのに、手動で実施するよりも遥かに素早くできます。Acceleoは具体的なニーズと相性が良い、すぐに使えるソリューションを提供します。Acceleoに加えて、Obeo DesignerにはObeo Traceabilityがあります。これを使えばコードとモデルの間にある矛盾や同期の問題を検出し解決することができます。
しかし、コード生成はすべてを解決するわけではありません。開発中は、ソフトウエアアーキテクトはフレームワークを利用するかコード生成を利用するか注意深く決定しなければなりません。これには普遍的な解決策はありません。個々の場合に依存します。