メインコンテンツまでスキップ

「Architect」タグの記事が1件あります

全てのタグを見る

· 約10分
田島 慶一

はじめに

Next Design カスタマーサクセスチームの田島です。

Next Design を使い始めるには、対象プロジェクトに合わせたメタモデル(設計情報の構造)を定義する必要があります。 その際、開発現場のやり方を踏襲しようと、既存の設計書を参考にメタモデルを定義することも多いのではないでしょうか。 しかし、既存設計書の「見た目」(見出し構成や記載内容)に囚われてメタモデルに落とし込んでしまうと失敗することがあります。

今回はメタモデルを定義する際にやってしまいがちなアンチパターンの1つについて、具体例を交えてご紹介しようと思います。

想定読者
  • 既存の設計書等を参考にメタモデル定義をはじめようとする方
  • プロファイル(メタモデルとビュー)の定義や改変を行う方

アンチパターン

  • 既存設計書の「見た目」をそのままメタモデルに落とし込む

Next Design のコンセプトの一つとして、開発現場の設計対象や表現方法に合わせた専用の設計ツールにカスタマイズできるという特長があります(リンク:製品コンセプト)。そのアプローチとして、既存設計書の「見た目」=見出し構成や記載内容に倣ってメタモデルを定義すれば、Next Design 上でも既存の設計書と同様の「見た目」で設計できるようになります。

次の例を見てみましょう。 左側が既存設計書の見出し構成です。右側が Next Design でそれ同等の構造をメタモデルで定義してモデル化した例です。 既存設計書の見出し構成と同じモデルの階層構造になっており、見た目は期待通りの結果になっています。

アンチパターン

既存設計書の見出し構成とメタモデルの該当箇所を突き合せて見てみましょう。

アンチパターン

既存設計書の見出しに出ている「SW構成図」や「コンポーネント一覧」も設計情報の一部として捉え、メタモデルにも定義されています。もちろん、これらの「図」や「一覧」も設計書に記載すべき情報であることは間違いありません。 ですが、これらの「図」や「一覧」は本来設計すべき情報なのでしょうか。このアンチパターンによる問題点を見ていきましょう。

問題点

  • 本来1つであるべき設計情報が複数存在しており、設計情報として一元化されていない。

Next Design 導入のメリットの一つとして、設計情報の一元化が挙げられます。ですが、それもメタモデル次第です。適切なメタモデルでなければ一元化されません。

先の例では、既存設計書の見出し構成と同等の構造を Next Design でモデル化できていますが、本来1つであるべき「車速偏差」モデルが3つ存在しています。 これはその設計情報を入れる箱である「コンポーネント」クラスがメタモデル中に3つ存在しているためです。

問題点1

この状態では、「SW構成図」のビュー上で「車速偏差」モデルの名前(設計情報の一部)を変更しても、「コンポーネント一覧」の配下にある「車速偏差」モデルの名前と「コンポーネント仕様」の配下にある「車速偏差」モデルの名前は変更されません。結果として、同じ名前であるべき3つの箇所で名前が整合していない状態となってしまいます。これこそが、設計情報が一元化されていない状態です。

解決策

  • 「見た目」ではなく「何を設計するか」の観点でメタモデルを定義する
  • 「見た目」はメタモデルではなくビュー定義で表現する

Next Design では、まず「設計すべき情報」をメタモデルで定義してから、その「見た目」をビュー定義で定義します(リンク:メタモデルビュー定義)。 その際に、既存文書の見出し構成や記載内容を参考に「設計すべき情報」を抽出してメタモデルを定義することは間違いではありません。ですが「見た目」に囚われず「何を設計するか」という観点で「設計すべき情報」と「見た目」を区別することが必要です。 既存設計書に記載されている「図」や「一覧」は「見た目」こそ違いますが、その中身は同じ設計情報を表しています。このような「見た目」=表現方法の違いはメタモデルではなくビュー定義として定義します。

先の例をもう一度見てみましょう。 「SW構成図」と「コンポーネント一覧」、「コンポーネント仕様」には、APPなどの「レイヤ」と車速偏差などの「コンポーネント」がそれぞれ記載されていますが、いずれも同じ設計情報です。ここでの「設計すべき情報」は「レイヤ」と「コンポーネント」です。それらはメタモデルで定義します。 そして、「SW構成図」と「コンポーネント一覧」の中身は「コンポーネント仕様」と同じで「見た目」が違うだけです。そのため「SW構成図」と「コンポーネント一覧」はビュー定義として定義します。

上記アプローチで定義しなおしたメタモデルの例を以下に示します。

解決策のメタモデル例

このメタモデルでは「SW構成図」と「コンポーネント一覧」がなくなり、複数あった「レイヤ」と「コンポーネント」が「SW構造設計」の配下にそれぞれ1つだけ定義されています。

このメタモデルを用いて設計した Next Design のモデルの例を以下に示します。

解決策のモデル例

左のツリー上で「車速偏差」モデルが1つになっており、「SW構成図」と「コンポーネント一覧」の両方に「車速偏差」モデルが表示されています。この状態からいずれかのビューで「車速偏差」の名前を変更すれば「SW構成図」と「コンポーネント一覧」の両方のビューに反映されます。

このように「設計すべき情報」と「見た目」を区別してメタモデルとビュー定義を定義することで、同一であるべき設計情報が1つのモデルに一元化され、設計書内での不整合がなくなります。

まとめ

今回ご紹介したアンチパターンとその解決策を要約すると次の通りです。

  • 「見た目」に寄せてメタモデルを定義してしまうと設計情報が一元化されないことがある。
  • 「見た目」ではなく「何を設計すべきか」の観点でメタモデルを定義する。
  • 「見た目」はビュー定義で定義する。

この他にもメタモデル定義に関するHow-Toを次のページで公開しています。

Next Design を90日間無料でお試しいただける評価版もご用意しております。ぜひこちらからお申し込みください。