はじめに
Next Design カスタマーサクセスチームの田島です。
Next Design を使い始めるには、対象プロジェクトに合わせたメタモデル(設計情報の構造)を定義する必要があります。 その際、開発現場のやり方を踏襲しようと、既存の設計書を参考にメタモデルを定義することも多いのではないでしょうか。 しかし、既存設計書の「見た目」(見出し構成や記載内容)に囚われてメタモデルに落とし込んでしまうと失敗することがあります。
今回はメタモデルを定義する際にやってしまいがちなアンチパターンの1つについて、具体例を交えてご紹介しようと思います。
- 既存の設計書等を参考にメタモデル定義をはじめようとする方
- プロファイル(メタモデルとビュー) の定義や改変を行う方
アンチパターン
- 既存設計書の「見た目」をそのままメタモデルに落とし込む
Next Design のコンセプトの一つとして、開発現場の設計対象や表現方法に合わせた専用の設計ツールにカスタマイズできるという特長があります(リンク:製品コンセプト)。そのアプローチとして、既存設計書の「見た目」=見出し構成や記載内容に倣ってメタモデルを定義すれば、Next Design 上でも既存の設計書と同様の「見た目」で設計できるようになります。
次の例を見てみましょう。 左側が既存設計書の見出し構成です。右側が Next Design でそれ同等の構造をメタモデルで定義してモデル化した例です。 既存設計書の見出し構成と同じモデルの階層構造になっており、見た目は期待通りの結果になっています。
既存設計書の見出し構成とメタモデルの該当箇所を突き合せて見てみましょう。
既存設計書の見出しに出ている「SW構成図」や「コンポーネント一覧」も設計情報の一部として捉え、メタモデルにも定義されています。もちろん、これらの「図」や「一覧」も設計書に記載すべき情報であることは間違いありません。 ですが、これらの「図」や「一覧」は本来設計すべき情報なのでしょうか。このアンチパターンによる問題点を見ていきましょう。
問題点
- 本来1つであるべき設計情報が複数存在しており、設計情報として一元化されていない。
Next Design 導入のメリットの一つとして、設計情報の一元化が挙げられます。ですが、それもメタモデル次第です。適切なメタモデルでなければ一元化されません。
先の例では、既存設計書の見出し構成と同等の構造を Next Design でモデル化できていますが、本来1つであるべき「車速偏差」モデルが3つ存在しています。 これはその設計情報を入れる箱である「コンポーネント」クラスがメタモデル中に3つ存在しているためです。
この状態では、「SW構成図」のビュー上で「車速偏差」モデルの名前(設計情報の一部)を変更しても、「コンポーネント一覧」の配下にある「車速偏差」モデルの名前と「コンポーネント仕様」の配下にある「車速偏差」モデルの名前は変更されません。結果として、同じ名前であるべき3つの箇所で名前が整合していない状態となってしまいます。これこそが、設計情報が一元化されていない状態です。