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

はじめに​

ソフトウェア開発において、「設計書の改訂」は日常的な作業です。
しかし、そのたびに「どこが変わったのか」「なぜ変わったのか」を把握するのに、知らず知らずのうちに多くの時間を費やしていませんか？

たとえばこんな経験はないでしょうか？

• 設計レビュー前に「前回からどこを直したのか」を確認するのに手間がかかる
• 修正済みのはずの内容が、レビューで「見落とし」として指摘される
• 手動で差分一覧をまとめたけれど、変更漏れや記載ミスがあって手戻る

これらは一見、小さな「手間」に思えますが、積み重なればチームの開発速度や品質に大きく影響する“見えないコスト”です。

差分管理は「仕方がないもの」ではない​

多くの開発現場では、WordやExcel、モデリングツールを使って設計書を作成しています。
そして、改訂時には前回版との比較を手作業で行い、変更箇所に色を付けたり、一覧を別途作成したりと、設計本来の業務とは少し離れた“管理作業”に時間が割かれています。
このようなプロセスは、「そういうものだ」と思われがちですが、果たして本当にそうでしょうか？

設計書の改訂差分が「見える化」されたら​

もし、文書や図、表といった設計情報の変更点が、自動的に分かりやすく可視化され、追加／変更／削除といった内容が、ツール上ですぐに確認できたら以下のような嬉しさがあります。

• レビューにかかる時間が短縮されます
• 差分の見落としによる手戻りもなくなります
• 差分一覧をつくるといった作業も不要になります

そんな環境があれば、設計者が本来注力すべき「設計そのもの」にもっと時間を使えるはずです。

Next Designが実現する、差分の「見える化」​

Next Designは、設計情報を単なる文書ではなく「モデル」として扱うことにより、改訂時の差分をツールが自動的に抽出・表示できます。

文書ベースにおける差分との決定的な違いとは​

「差分を表示するだけなら、Wordにも比較機能があるのでは？」 そんな疑問を持たれた方もいるかもしれません。

確かに、Wordには変更履歴の記録や比較機能があり、差分を可視化することは可能です。ですが、Wordの差分比較はあくまで 「文字列」ベース のものです。

設計書には、単なる文章だけでなく、「クラス」 「項目」 「構成」 「関係性」 など 意味を持った情報（モデル） が数多く含まれています。 Next Designでは、こうした情報を「モデル」として扱っているため、構造化された意味単位で差分を把握することができます。

Word文書との比較：何が違うのか？​

モデルだからこそ、意味が伝わる​

たとえば、クラス図に新しいクラスを追加した場合を考えましょう。

• Wordで図を貼り付けていた場合、その画像は「どこが変わったか」を目視で判断するしかありません。
• 一方、Next Designであればクラス単位で追加・変更・削除が明示的に表示されます。

また、ツリー構造のように階層を持つ情報でも、どのノードが追加されたのか、どの枝が変更されたのかが視覚的に明確になります。 これにより、レビュー時には「どこが変わったか」だけでなく、「どういう意図で何が変わったか」まで、少ない手間で理解できるのです。

この仕組みにより、これまで時間を取られていた「変更箇所の確認・整理」といった工程が不要になります。

Next Design の表示例​

以下のようにドキュメントはもちろん、クラス図、シーケンス図も左右に変更前後を表示し、一目で差分が分かります。

• ツリーグリッド

  

• クラス図

  

• シーケンス図

  

「設計変更の管理」は、次のレベルへ​

設計の現場では「差分管理」は不可欠なプロセスです。 しかし、それが今も“手間のかかる作業”になっているなら、改善の余地は十分にあります。 Next Designは、こうした課題を根本から見直し、「見えないムダ」を削減することで、設計者の時間と集中力を設計業務に取り戻す手助けをします。 差分管理に費やしている時間とコストはどれくらいかかっていますか？
一度、振り返ってみませんか？

詳細は「変更前後の差分をマルチビューで確認」を参照ください。

次回予告​

次回は「設計レビュー支援機能」についてご紹介する予定です。レビューでの見逃しをなくしたい方、確認ポイントを明確にしたい方に役立つ内容となっております。ぜひご覧ください。

はじめに​

ソフトウェア現場改善エバンジェリスト＆デザインDXエバンジェリストの山路です。

第1回「なぜ、メタモデルなのか？」では、デジタルペーパーを用いた文書記述に内在する問題構造をご説明しました。 「何を」を定めるのに「どうやって」という特定の見た目を使って定義していることに気づき、ここに問題の本質があることをお伝えしました。 第2回では、エンジアリングプロセス（本ブログでは、「対象製品を設計する技術的なプロセス」の意味で使用する）の共通化と上記の気づきの関係性を論ずることで、共通化を進める１つの方法論をご紹介します。

なぜ、同じ内容を定義するのに見た目が異なるのか​

第1回で述べた気づきが示唆することは、「同じ内容を定義するのに、異なる見た目を使ってしまう」ということです。 人によって、チームによって、組織文化によって、慣習によって、あるいは、その時々の関心事によって、別々の見た目を使ってしまうのです。 そして、この現象の大半は、エンジニアの頑張りによって引き起こされています。
例えば、設計した内容を上手く伝えたいというエンジニアの思いにより、知恵を出して文書記述を工夫することがあると思います。 各エンジニアのそれぞれの工夫が見た目のバリエーションを増やします。 また、文書記述の標準化や共通化などのプロセス改善を行うこともよくあることでしょう。 活動を推進するチームの関心事や価値観に合わせた見た目を採用するので、他製品や他の組織とは異なる記述形式となりやすいのです。

異なる見た目が、共通化を阻む​

エンジニアリングプロセスのバリエーションが増えてくると、全社レベルや大きな組織レベルで「共通化したい」、「共通化すべき」と、上層部や改善部門から要望されることがあります。 良いプロセスは組織で共有したい、共通化することで開発の効率や品質を向上させたい、あるいは、配置転換をしやすくしたい、等々の理由によりプロセスの共通化が求められます。 よくある話で、皆さんも一度や二度のご経験があるのではないでしょうか。
そこで、多くの組織では、プロセスの共通化を推し進めるために、各チームの代表が集まってワーキング活動が立ち上がります。プロセス共通化ワーキングです。 しかしながら、ワーキング活動の進みが遅い、時には、頓挫して自然消滅する、なんて状況を度々見かけます。それは、なぜでしょうか？

“なぜ”を考えるヒントとして、前述した以下の気づきを思い出してください。

• 「何を設計するか」を「どのように設計するか」という特定の見た目で定義する
• 同じ内容を定義するのに、異なる見た目を使ってしまう

このため、共通化の議論も、それぞれのプロセスの特定の見た目を比較して行うことになります。 つまり、見た目の影響を受けた議論になってしまうのです。 見た目の違いから、「共通化が難しい」という結論になることもあるでしょう。 また、「何を」を議論しているつもりが、「どのように」の議論にすり替わることもあるでしょう。

人は、見た目に惑わされやすいのです。 もしかしたら、自分のプロセスを変えたくないとか、共通化ワーキングのマウントをとりたいとか、そのような思いが無意識に働いているのかもしれません。 「見た目に影響される」という方法が、ワーキング活動を進みにくくさせている１つの要因になっているのではないでしょうか。

メタモデルを使って解決に導く​

Next Designでは、「何を設計するか」をメタモデル言語で定義します。 見た目と分離する方式なので、見た目の影響を最小限に抑えることが可能です。 そこで、共通化を進めるには、以下のStepを踏む方法が良さそうです。

要するに、各チームが使っているエンジニアリングプロセスをNext Design上に搭載し、その後、メタモデルをもとに共通化を検討する方式です。 見た目を分離し、「何を設計するか」をメタモデルにより整理します。ここが重要なポイントです。 当初はメタモデルに慣れていないので少し戸惑うかもしれませんが、「何を設計するか」をエンジニアが自ら問うことで、対象製品の設計の理解が深まっていくはずです。 その後で、メタモデルをベースに共通化の検討を行います。 メタモデルという共通言語で検討することで、「何を設計するか」を概念的に捉えられることが期待できます。 その結果、共通な点が自然に見つかり、活動が進みやすくなるのではないでしょうか。

まとめ​

このコラムでは、エンジニアリングプロセスの共通化活動を阻む要因をお伝えしました。

【阻む要因】

• 「何を」を異なる見た目で定義している
• 異なる見た目に議論が影響を受けてしまう

この要因は、デジタルペーパーが抱える問題構造が引き起こしてしまう現象です。

この問題に対し、メタモデルを用いた解決方法をご紹介しました。 「何を設計するか」をメタモデルで定義することで、見た目の影響を受けにくい検討ができそうです。 また、エンジニアの概念化能力の向上にも効果がありそうです。 プロセスの共通化を着実に進める方法としても、Next Designを使ってみてはいかがでしょうか。

はじめに​

ソフトウェア現場改善エバンジェリスト＆デザインDXエバンジェリストの山路です。

これまで本ブログでは、Next Designの機能やTIPSなどをご紹介してきましたが、 今回は趣向を変えて、Next Designのコンセプトである設計情報のDX化をテーマに全2回のコラムをお届けします。 以下の内容を予定しておりますのでご期待ください。

• 第1回：なぜメタモデルなのか？
• 第2回：プロセスの共通化を阻む要因は？

それでは早速「なぜメタモデルなのか？」をテーマに記事を始めます。 Next Designでは、メタモデル言語を使用して設計情報を定義します。 そして、「メタモデルを使って設計情報を定義することが難しい」というお話をよく耳にします。 そもそも、なぜ、メタモデルなのでしょうか？ 「メタモデル方式は、きっと良いのだろう」と直感的に捉えていましたが、説明が上手くできませんでした。 デジタルペーパー中心の開発方式が抱える問題に取り組む中で、「なぜ、メタモデルなのか？」につながる知見を得られたのでご紹介します。

デジタルペーパー中心の開発の何が問題か​

大規模開発​

クラウドやIoT技術の普及により、ソフトウェア開発の大規模化が急激に進み、従来のデジタルペーパー中心の開発方式では対応できずに大炎上・大混乱に陥るプロジェクトが多くなっています。 また、開発規模が大きくなればなるほど、人やチーム間の役割を明確にし、情報の共有をはかる必要性が高まり、ますます開発文書の重要度が高まっています。

つまらない問題​

しかしながら、文書の不備に起因する“つまらない問題”が開発現場では多発しています。 “つまらない問題”とは、記述の不整合や記述不足などによる「エンジニア間の認識違い」が引き起こす問題です。 複雑なアルゴリズムが潜んでいるような技術難易度が高い問題ではなく、思い込みや勘違いによるちょっとした認識のずれから発生する問題です。 これらの問題に対し、私達は長年にわたり改善を行ってきました。 いわゆる、プロセス改善です。ルールや規定を作り、チェック作業やチェックツールを投入するなどの改善を実施してきました。 しかし、改善はされるものの新たな文書記述の問題が発生する、または、同じような問題が再発することもあります。 そもそも、本質的とは思えない問題に、工数やお金を投入していることに「何かがおかしいのでは。。。」という違和感を抱いていました。

記述が重複する​

つまらない問題は、様々な要因によって引き起こされます。ここでは、文書記述の“重複”によって引き起こされる問題に着目して問題の本質を掘り下げます。多くの開発現場で起きている、身近な問題です。 開発文書間や開発文書内で、重複する記述は多々あります。重複する記述の例として、記述する設計情報の名称をイメージすると、ピンとくると思います。 記述の重複が出現する主な場面は、以下の通りです。

• 設計のブレイクダウン

設計は段階的に詳細化します（ブレイクダウン）。 設計内容をブレイクダウンする際、上位設計書で使用した記述を下位設計書で使用します。 「概要」から「詳細」のように設計をブレイクダウンする際に、同じ名称を使って記述します。 このようなブレイクダウンは、文書間や文書内で何度も繰り返すので、重複はどんどん増えていきます。

• 多様な関心事

説明の目的や関心事に合わせて、様々な見た目で設計情報を記述します。 他の箇所で記述した設計情報を使って、目的に合うように記述します。 年々、機能安全など新たな説明要求が加わり、重複する設計情報の記述が増加しています。

重複が起点となり不整合を引き起こす​

重複した記述が多ければ多いほど、設計情報の不整合が起こりやすくなります。 特に、変化が激しい開発や大規模開発では、記述内容のメンテナンスが追いつかず、発生頻度が高まります。 その結果、エンジニア間の認識がずれる原因となり、“つまらない問題”が多発するのではないでしょうか。 また、重複する構造は、設計情報間のつながりが不明確となりやすく、エンジニアの理解の障壁となります。 さらに、つながりの分かりにくさは、情報の欠落の原因にもなります。 これらのことが重なって、“つまらない問題”を引き起こすのです。

デジタルペーパー方式の表現の限界​

それでは、なぜ、重複となるのでしょうか。 設計には、様々な関心事があり、設計情報間の関係も多岐に渡ります。 そして、関心事ごとに合った表現方法がそれぞれにあります。 それぞれの表現（以降、“特定の見た目”と記載する）によって、個別に記述するため、同じ設計情報を何度も使用することになります。 ここに、デジタルペーパー方式の表現の限界があります。 なぜなら、デジタルペーパーは２次元空間を扱う方式であり、かつ、空間にも限度があるため、一度に表現できることが限られます。 関心事に合った説明を行うには、特定の見た目を使って個々に記述せざるを得ず、どうしても設計情報が重複してしまいます。

設計書の記述方式に対する気づき​

「何を」を、特定の見た目「どうやって」で定義している​

デジタルペーパー方式の問題点について考える過程で以下の点に気づきました。 設計では、「何をするか」を定めて文書として記述します。 そして、文書の記述は、関心事に合った特定の見た目を用いて、個別に行います。言い換えれば、「何を」を特定の見た目、つまり、「どうやってするか」を使って定義することになります。 ここに違和感があり、問題の本質があると考えています（内在する問題構造）。 「何を」を定義するのに、特定の見た目の影響を受けてしまう方式、これがデジタルペーパーによる従来の記述方式です。

特定の見た目には、それぞれの制約があり同時に定義できることが限られます。 つまり、見た目で表現できることしか定義できないのです。 それゆえに、関心事に合わせた見た目を別々に作成することになり、その結果、記述が重複してしまいます。

この問題を解決するには、見た目に影響を受けない記述方式が必要となります。

どんな記述方式がいいのか​

見た目の影響を受けない方式 “セマンティック技術”​

セマンティック技術とは、「情報の意味をコンピュータが理解できる形に表現し、コンピュータに処理を行わせる技術」です。 つまり、人間が理解するために必要となる見た目を持たずに、設計情報をコンピュータが理解できる形で表現する技術です。 意味的に表現することで、複数の関係性や関心事を同時に扱うことが可能となります。 加えて、コンピュータが解釈できるので、デジタル検証に代表されるデジタル化の恩恵が得られます。 そして、実現にはメタモデル言語を使用します。

メタモデルによるデータとビューの分離​

Next Designでは、「何を」という設計情報の定義と「どうやってするか」という見た目（ビュー）の定義を分離する方式を採用しています。 そして、「何を」を定義するためにメタモデル言語を使用します。

見た目を分離して定義するため、見た目の影響を受けない設計情報の定義が可能となりました。 見た目の解釈はコンピュータが担当し、エンジニアは「何をするか」という本質的な設計課題に取り組みます。 今まで特定の見た目という個別の断面で定義していた設計情報を、全体の関心事を俯瞰して定義することになります。 同時に扱う関係性が増えるので慣れるまでは戸惑いますが、「何を設計するのか」という設計の本質に立ち戻ることになり、エンジニアとしての設計の理解が深まることが期待できそうです。

まとめ​

従来のデジタルペーパー中心の開発方式には、内在する問題構造があることに気づきました。

メタモデルは、上記の問題構造を解決する方式を提供しています。 具体的には、「何を」という設計情報の定義をメタモデルで行うことで、設計情報の定義と「どうやってするか」という見た目（ビュー）の定義を分離する方式です。 分離することで十分な設計情報の定義が可能となります。メタモデルを使って、設計する内容を熟考し定義しましょう。

さて、「なぜ、メタモデルなのか？」の答えに近づけたでしょうか。

はじめに​

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日間無料でお試しいただける評価版もご用意しております。ぜひこちらからお申し込みください。