「技術コラム」タグの記事が3件あります

はじめに​

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

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

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

アンチパターン​

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

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

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

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

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

問題点​

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

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

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

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

解決策​

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

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

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

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

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

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

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

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

まとめ​

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

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

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

• ユーザーズマニュアル > How To > プロファイル定義

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

はじめに​

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

Next Desgin に興味を持たれた方々の中には、「設計情報をデジタル化する嬉しさはわかった。けれど、それを活用するための手段となるエクステンション開発は難しそう。」と尻込みしている方も多いのではないでしょう。今回はそんな方に向けて、エクステンション開発が意外と簡単にできてしまうことを、具体例を交えてご紹介しようと思います。

よくある作業​

テスト設計の場面で仕様通りに動作することを確認するような定型的なテストケースを作成することはよくあると思います。一例としてGUIアプリケーション開発の場合を考えてみましょう。

次のようにアプリケーションのUI仕様としてボタン操作に対する動作が定義されています。

画面イメージ

操作仕様

これに対するテスト設計では、ボタン操作による動作結果が仕様通りかを確認するために、テストケースを機械的に作成することがあるでしょう。 Next Design では、テスト設計の入力であるUI仕様がモデル化されておりAPIで操作できます。そのため定型的なテストケースを機械的に作成する作業は簡単に自動化できます。 そのようなエクステンションの具体例をメタモデルと対応づけて紹介します。

メタモデル​

次の図は先のUI仕様とテスト仕様を表すメタモデルの例です。

画面要素を操作時の動作を表す [操作仕様] と、その仕様を確認するための [テストテストケース] があり、それらが導出関連で結ばれています。

エクステンション​

実装方法​

エクステンションの処理は Next Design 標準搭載のスクリプトエディタで作成・実行しながら実装できます。 拡張コンテンツとしてプレビュー公開している ”ScriptEditor”（標準搭載のスクリプトエディタの機能強化版）を利用すれば、強力なインテリセンス機能でAPIも簡単に見つけられます。

処理の流れ​

次の流れで操作仕様からテストケースを自動作成します。

1. UI仕様からUI部品の操作仕様を抽出します。
2. 操作仕様に基づいてテストケースを作成します。
3. 操作仕様とテストケース間にトレース関連を結びます。

実装コード​

ここでは API の使い方を掴んでもらえるよう、実装コードの一部をピックアップして説明します。
実装コードの全体は こちら からご参照ください。

操作仕様の抽出

まずは、UI画面モデルの中からテストケース作成の入力となる操作仕様モデルを特定します。それには、操作仕様モデルを表すモデルのクラス名： OperationSpec を条件に、API : IModel.FindChildrenByClass() メソッドを使用して該当モデルを抽出します。

// UI画面の中からUI部品の操作仕様を抽出します。
var operationModels = uiWindow.FindChildrenByClass("OperationSpec", recursive: true);
...

テストケースの作成

次に、抽出した操作仕様モデルに対するテストケースモデルを新規追加します。それには、API : IModel.AddNewModel() メソッドを使用します。AddNewModel() メソッドの第1引数にはテストケースモデルを保持する「テストケース」フィールドのフィールド名：TestCases を、第2引数にはテストケースモデルのクラス名：TestCase を指定します。

新規追加されたモデルは名前も未設定の初期状態のため、API : IModel.SetField() メソッドを使用して名前を設定します。SetField() メソッドの第1引数には「名前」フィールドのフィールド名：Name を、第2引数にはそのフィールドに設定する値を指定します。
同様に、テストケースの期待値も SetField() メソッドを使用して設定します。

// 操作仕様に対応したテストケースを作成します。
var testCaseModel = testGroupModel.AddNewModel("TestCases", "TestCase");
...
testCaseModel.SetField("Name", testCaseLabel);
testCaseModel.SetField("ExpectedValue", expectedValue);

操作仕様とテストケースの関連付け

そして、操作仕様モデルとテストケースモデル間のトレーサビリティを確保するために、入力となっている操作仕様モデルと自動作成したテストケースモデルを関連付けます。前述のメタモデルを見てみると、操作仕様クラスとテストケースクラスの間には導出関連が定義されています。テストケースクラス側からは「操作仕様」フィールドのフィールド名：input_OperationSpec でその関連を辿ることができます。

メタモデルのクラス間で関連性が定義済みのモデルを互いに関連付けるには、API : IModel.Relate() メソッドを使用します。Relate() メソッドの第1引数にはテストケースクラスの「操作仕様」フィールドのフィールド名：input_OperationSpec を、第2引数には関連付ける相手先の操作仕様モデルを指定します。

// 操作仕様とテストケース間にトレース関連（導出関連）を結びます。
testCaseModel.Relate("input_OperationSpec", operationModel);

実行結果​

UI画面中の操作仕様に対して定型的なテストケースが漏れなく自動作成されます。
操作仕様とテストケース間の関連（トレース情報）もエクステンションで追加されます。

＜実行前＞

＜実行後＞

まとめ​

今回はエクステンション開発のイメージを掴んでもらうために、具体例としてテストケースの自動作成を取り上げてご紹介しました。 Next Design で提供されている豊富なAPIを利用すれば、エクステンションによる既存資産のインポートや現場固有のルールに沿った整合チェックなども実現できます。

エクステンション開発のチュートリアルやAPI利用の How To などを掲載したエクステンション開発マニュアルも公開しております。エクステンション開発の詳細についてはそれらをご参照ください。
Next Design を90日間無料でお試しいただける評価版もご用意しております。ぜひこちらからお申し込みください。

はじめに​

Next Design サポートチームの平田です。

さて、突然ですが、トレーサビリティ情報って効果的に使えていますか自信を持って使えていると言える方は、なかなか多くないのではないでしょうか。

ここでは、Next Design のトレーサビリティに対する考え方を、主な効果の1つであるトレーサビリティ情報を利用した設計変更点の影響範囲の特定について、例を交えてご紹介します。

トレーサビリティについての現状​

ソフトウェア開発におけるトレーサビリティは、システムやソフトウェアの設計・開発過程を可視化し、品質を保証するためのものです。 ソフトウェアが大規模・複雑化している昨今、品質確保のためにトレーサビリティの重要性はより大きくなっています。

トレーサビリティの主な効果として次の3つが挙げられます。

1. 設計・検証の抜け漏れ確認による不具合予防
2. 設計変更や不具合改修時の影響範囲特定
3. 安全に対する説明責任履行

いずれも開発者にメリットがある効果ばかりですが、実際の開発現場では次のようなアンチパターンが起こっていることがしばしばあります。

• トレースのために設計 +α の工数を要するため、トレース自体がされていない(後回しになっている)
• 多数の成果物を跨いでトレース情報を集める必要があり、影響範囲が見える化できずに利用が上手くできない

アンチパターン解消へのアプローチ​

Next Design では、ツールの持つ特性や、開発した機能から、前述のアンチパターンを解消するために次のようにアプローチしています。

• トレースのために設計 +α の工数を要するため、トレース自体がされていない(後回しになっている)

Next Design のコンセプトの一つに、設計のデジタル化とデータの一元管理があります。 そこで、一元化した設計データ間で簡単に関連を結べるようにすることで、1つ目のアンチパターンの解消を試みています。

• 多数の成果物を跨いでトレース情報を集める必要があり、影響範囲が見える化されず、利用が上手くできない

Next Design のコンセプトの一つに、1つの設計情報に対して複数のビューを切り替えて設定でき、用途に応じて表示できるというものがあります。 そこで、関連を一覧視可能なビューを提供することで、2つ目のアンチパターンの解消を試みています。

以降、解決方法を Next Design の実際の操作を交えて、紹介していきます。

一元化した設計データ間で簡単に関連を結べるようにする​

Next Design では、設計情報のデジタル化のために、設計データの構造をメタモデリングします。 設計要素に対して関連を引けるようにメタモデリングすることで、設計要素間にトレース関係を結べるようになります。

まず、メタモデルとして設計要素を定義して要素間に関連(トレース関係)を定義します。
実際の操作は、次の通りです。

次に、このメタモデルを基にインスタンスとなるモデルを作成してトレース関係を追加します。
実際の操作では、トレース元とトレース先のモデルを、それぞれビューに表示して、トレース元からトレース先へドラッグ＆ドロップすることで、モデルの作成とともにトレースが取れます。

ご覧いただいたように設計とトレース設定の操作が一体となっているので、コストを理由としたトレースの不足(後回し)というアンチパターンは解消できます。

関連を一覧視可能なビューを提供する​

上記で設定したトレース関係の見える化のために、専用のトレースビューを提供しています。 次のように、ツリー形式やマトリクス形式での表示ができます。

また、ツリー形式ではトレース関係のある要素を複数並べることで、要求とテストなど設計を介して間接的にトレースされている要素まで見れるようになっています。

こちらについても、ご覧いただいたようなトレースが見える化され、影響範囲の特定が容易なため、利用が上手くできないといった2つ目のアンチパターンも解消できます。

まとめ​

Next Design のトレーサビリティに対する考え方を、「設計変更点の影響範囲の特定」というユースケースを交えてご紹介させていただきました。 開発チームでもご紹介の方法でトレースを取ることで、設計変更の影響範囲だけでなく入出力情報の確認などに利用しています。

既にご利用の方は、本機能についても是非お試しください。
また、本内容についてより詳細なセミナーなども開催しております。ご要望の際は お問い合わせフォーム からご連絡ください。

未利用の方でご興味を持たれた方は、こちら から評価版ソフトのお申し込みもできますので、お気軽にお問い合わせください。