JP2008171391A - 組み込みシステムのための要求記述を生成する方法 - Google Patents

組み込みシステムのための要求記述を生成する方法 Download PDF

Info

Publication number
JP2008171391A
JP2008171391A JP2007277493A JP2007277493A JP2008171391A JP 2008171391 A JP2008171391 A JP 2008171391A JP 2007277493 A JP2007277493 A JP 2007277493A JP 2007277493 A JP2007277493 A JP 2007277493A JP 2008171391 A JP2008171391 A JP 2008171391A
Authority
JP
Japan
Prior art keywords
test
request
metamodel
time
instance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2007277493A
Other languages
English (en)
Inventor
Sven Burmester
ブルメスター スヴェン
Klaus Lamberg
ランベルク クラウス
Christian Wewetzer
ヴェーヴェッツァー クリスティアン
Christine Thiessen
ティーセン クリスティーネ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dspace Digital Signal Processing and Control Engineering GmbH
Original Assignee
Dspace Digital Signal Processing and Control Engineering GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dspace Digital Signal Processing and Control Engineering GmbH filed Critical Dspace Digital Signal Processing and Control Engineering GmbH
Publication of JP2008171391A publication Critical patent/JP2008171391A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/14—Tree-structured documents
    • G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/151—Transformation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/30—Semantic analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Artificial Intelligence (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

【課題】本発明の課題は、組み込みシステムの要求記述を作成する次のような方法、すなわち、要求記述によってどのユーザでも、処理されている具体的な要求が何であるかを一義的に認識することができ、かつ、記述された要求から、組み込みシステムをテストするための一義的なテストを自動生成するのに適した要求記述を作成する方法を提供することである。
【解決手段】この課題は、データ処理システムにおいて、選択可能な自然言語テキストセグメントから成る語彙を記憶し、該自然言語テキストセグメントは組み合わされることによって、英語を含む自然言語の少なくとも１つの文を構成し、機械読み出し可能な要求記述を作成することによって解決される。前記少なくとも１つの文の自然言語は、英語のみに限定されない。
【選択図】図１

Description

本発明は、要求記述を生成する方法に関する。この要求記述はテスト仕様の生成だけでなく、組み込みシステムにも使用される。
組み込みシステムは通常、センサおよび／またはアクチュエータおよび／またはインタフェースを介して周辺システムまたはシステム全体に接続されたソフトウェアユニット／ハードウェアユニットである。たとえば組み込みシステムは、監視タスク、開ループ制御タスクまたは閉ループ制御タスクを実施することができる。たとえば、自動車においてどのようなタスクを制御するのにも使用される電子制御ユニットは、組み込みシステムとして構築することができる。したがって、組み込みシステムは本発明では、とりわけ有利な実施形態において、自動車用の電子制御ユニットを指す。
ここでは組み込みシステムは、組み込みシステムの具体的なハードウェア実装のみを指すのではなく、ハードウェア実装される組み込みシステムの開発での先行段階、すなわちたとえば、このような組み込みシステムをシミュレートするためのソフトウェアモデルも指す。
高品質の水準を実現するためには、広範囲には電子制御ユニット等の組み込みシステムを製造に導入する前に組み込みシステムをテストして、組み込みシステムが仕様化された要求を遵守しているか否かを検査するのが慣例である。したがって、組み込みシステムに適用すべき要求はこのようなテストで既知でなければならず、このようなテストの開発だけではないが、この開発でも既知でなければならない。
要求は通常、このような組み込みシステムの製造者のカスタマによって仕様化され、通常は自然言語の要求の形態をとり、たとえば要求を仕様化する人によって書かれたテキストの形態をとる。
ここで、自然言語はどの言語であれ、通常は一義的ではないため、記述された要求が不明瞭になることがあるという問題が生じる。
さらに、たとえば組み込みシステムの属性または作業を表すこのようなシステムをテストしなければならない。こうするためには、組み込みシステムのハードウェア実装後に該組み込みシステムをテストするのに適切なテストプログラムを書くか、または、組み込みシステムが基礎とするそれ以前のソフトウェアモデルをテストするのに適切なプログラムを書くのが慣用的である。
このようにしてプログラマは、それ自体ではとりわけ経験不足な観察者には理解不能なソフトウェアルーティンを書くので、このソフトウェアルーティンを見て、ソフトウェアルーティンによって何がテストされ結果が何を表すのかに関して直接的な結論を導き出すことはできない。
したがって本発明の課題は、組み込みシステムの要求記述を作成する次のような方法、すなわち、要求記述によってどのユーザでも、処理されている具体的な要求が何であるかを一義的に認識することができ、かつ、記述された要求から、組み込みシステムをテストするための一義的なテストを自動生成するのに適した要求記述を作成する方法を提供することである。
この課題は、データ処理システムにおいて、選択可能な自然言語テキストセグメントから成る語彙を記憶し、該自然言語テキストセグメントは組み合わされることによって、英語を含む自然言語の少なくとも１つの文を構成し、機械読み出し可能な要求記述を作成することによって解決される。前記少なくとも１つの文の自然言語は、英語のみに限定されない。
選択可能な自然言語テキストセグメントの制限された語彙をこのように記憶することにより、制限された該テキストセグメントから、対象となる自然言語を読んで話すことができる人なら誰でも一義的に理解できる自然言語文を構成することができる。
語彙を制限して特定のテキストセグメントのみを提供することにより、自然言語文の表現が多義的になるのが回避され、これによって要求が一義的かつ明瞭に形成されるのが保証される。このことと関連して、本発明の重要な側面に、データ処理システムに記憶された制限的な語彙によって提供される選択可能なテキストセグメントは任意のシーケンスに組み合わせることができない側面があるが、本発明の別の重要な側面では、前記制限的な語彙から選択されるテキストセグメントはすべて、該テキストセグメントと組み合わせ可能な別のテキストセグメントの特定のセットまたは指定可能なセットと連結することができるように構成される。このことによって本発明では、選択されたテキストセグメントに関してデータ処理システムは別の組み合わせ可能なテキストセグメントを選択のためにディスプレイ上に自動的に表示するように構成される。
したがって、テキストセグメントが選択されるたびに、データ処理システムは、予め選択された該テキストセグメントと組み合わせることができる別のテキストセグメントを自動的に提示する。このことと関連して、オプションとして追加可能なテキストセグメントと、意味論的および構文論的に正確な要求記述を作成するために少なくとも１つは選択しなければならないテキストセグメントとを区別することができる。
このことによって本発明では、自由に選択するユーザの通常の能力が制限され、ユーザによって選択されたか否かにかかわらずテキストセグメントが選択された後は、決定論的に選択された制限的なテキストセグメントのみが後続の使用のために提示されるように構成することができる。テキストセグメントのこのような提示および選択は、任意に実施することができる。たとえば、テキストセグメントを選択可能なメニュー項目として表現することができ、このメニュー項目はコンピュータマウスによってユーザによって選択可能にすることができるが、このことは必須ではない。
本発明の有利な実施形態では、テキストセグメントは記憶された要求メタモデルのクラスに割り当てられるように構成される。このようなクラスには、たとえば社内アプリケーションシステム等の項目をモデリングするためにしばしば使用されるＵＭＬクラスすなわち統一モデリング言語クラスが含まれるが、このクラスに限定されない。これは、たとえば異なるコンピュータシステムによってプラットフォームに依存せずに直接理解される標準的な言語であるか、または、データ処理システムの読み出しが、機械読み出し可能にするための特別なソフトウェアルーティンによって実行されるように構成することができる。
このようにして本発明では、提示されたテキストセグメントから自然言語文を作成するのと並行して、要求メタモデルによって定義された形式的な観点に従う要求記述を作成することができるので、データ処理システムは並行して、該データ処理システムによって理解できる要求記述を表す要求メタモデルのインスタンスを作成する。このようにして本発明の方法により、どのユーザでも一義的に理解できる自然言語文として要求記述が形成され、かつ同時に有利には、基礎となる要求メタモデルのインスタンスが形成され、たとえば、コンピュータによって具体的に理解および実行することが可能なＵＭＬクラスで記述される。
したがって本発明では、選択された各テキストセグメントごとに、要求メタモデルのインスタンスが、該テキストセグメントに結合された要求メタモデルクラスのインスタンスによって補完されるように構成することができる。
テキストセグメントに結合されたクラスのインスタンスとはここでは、対象となるクラスの具体的な要素を指す。
本発明ではさらに有利には、各テキストセグメントが要求メタモデルのクラスに割り当てられ、各クラスごとに少なくとも１つの別のクラスとの少なくとも１つの関連性と関連性の方向とに関する情報が記憶されることにより、単方向の関係が、クラスに割り当てられたテキストセグメントの文法的に正確な配置を定義するクラスシーケンスを構成するように構成される。
このようにしてこの有利な側面では、制限された語彙に記憶されたテキストセグメントが任意に相互に組み合わされることなく、クラスへの割り当てと、テキストセグメント間に適用される関連性または対応関係とによって、そのつどテキストセグメントの可能な組み合わせから得られる文は特定の１つのみになることが保証される。
このようにして、本発明の方法が実施されるデータ処理システムのユーザは、任意のテキストセグメントの組み合わせを行うことがなくなり、選択のために提示されるテキストセグメントのみを使用することにより、決定論的に規定された要求記述が作成され、この要求記述の表現の多様性は、各クラスにおいてそのつど対象とされるクラスの範囲によってのみ決定され、ひいては、表示される組み合わせ可能なテキストセグメントの数またはセットサイズによってのみ決定される。択一的に、決定論的に規定された要求記述が選択後に得られる場合、その後にテキストセグメントを記憶されたテキストセグメントに追加するためのオプションがユーザに対して表示されるように構成することもできる。
選択されたテキストセグメントと組み合わせ可能なテキストセグメントのセットとの結合および表現は有利には、データ処理システムがまず、選択されたテキストセグメントに対して、該選択されたテキストセグメントに割り当てられた要求メタモデルのクラスを決定するように行われる。こうすることにより、要求メタモデルに記憶され異なる可能なクラス間に存在する単方向の関連性にしたがって少なくとも１つの後続のクラスを見つけることができ、その後、見つけられた少なくとも１つの後続のクラスの要素または具体的なインスタンスが収集されて次のようなセット、すなわち、要素がそのつど割り当てられたテキストセグメントによって表され、その後に選択のためにデータ処理ユニットの表示ユニット上で表示されるセットを構成する。このような表示は、たとえばコンピュータマウスによるクリックによって選択可能なテキストセグメントの形態をとることができ、たとえばメニュー項目の形態をとることができる。また、本発明では別の任意の手段によって表示および選択を行うこともできる。
テキストセグメントの異なる２つのセットを基本的に区別するために規定を形成することができる。たとえば、構文論的に正確な要求を形成するためにそのつどテキストセグメントを選択しなければならない必須のテキストセグメントのセットが存在し、さらに、テキストセグメントを選択しなくてもよいが所望の場合には選択することができる可能なテキストセグメントを含むセットも存在するように構成することができる。
たとえば、可能なテキストセグメントのこのようなセットは、時間仕様に関するテキストセグメントとするか、または、たとえば時間条件等の任意の時間的観点に関するテキストセグメントとすることができる。たとえば、特定の時間または時間満了時にのみ発生する特定の条件、または何らかの別の時間的観点に関する条件を要求によって設けることができる。したがって、このような時間仕様は要求記述では必須ではないが、有利に使用することができる。
それゆえ本発明の方法では、このような非必須であるオプションのテキストセグメントのこのようなセットを選択時にスキップすることができる。たとえばこのようなスキップは、まず最初に表示される可能なテキストセグメントのこのようなセットによって、かつ、ユーザがコンピュータシステムに対してたとえば適切なメニュー項目をクリックすることにより、該ユーザがこれらのテキストセグメントから選択を行いたくないことを知らせることによって行われる。このコンピュータシステムはその後、この特定のセットの表示をクリアし、可能なテキストセグメントの別のセットを表示するか、または、ユーザがその時点で少なくとも１つのテキストセグメントを選択しなければならない必須のテキストセグメントの表示に進む。
本発明の有利な実施形態では、すでに選択されて完成済みの要求記述に組み込まれたテキストセグメントを択一的なテキストセグメントに置換できるように構成することもできる。このような構成により、置換のためにテキストセグメントが選択された後、データ処理システムは自動的に、選択のために可能である択一的なテキストセグメントのセットを表示するように構成することができる。
このような択一的なテキストセグメントを表示中のセットから選択することにより、置換すべきテキストセグメントを自動的にデータ処理システムによって置換することができる。可能である択一的なテキストセグメントは、データ処理システムがまず、置換のために選択されたテキストセグメントが所属するクラスを決定し、これに基づいて、該クラスに所属するすべてのテキストセグメントのセットが形成され、その後に該セットが表示されることによって見つけることができる。このセットは基本的に、決定されたクラスの内容にすべて相応し、ここから、置換のために選択されたテキストセグメントを除外することができるが、必須ではない。
本発明による方法によって、まず、ユーザによって一義的に理解して読み取ることができる自然言語の要求記述を作成できることと、第２に、基礎となる要求メタモデルに結合することにより、コンピュータが理解できる要求メタモデルの具体的なインスタンスを並行して作成することが可能であることとを明白に理解することができる。
したがって本発明の別の有利な側面では、自然言語の要求記述の作成後にデータ処理システムは要求記述を、プラットフォームに依存しない自然言語テスト仕様に変換する変換を行うように構成することもできる。このテスト仕様は、変換によって形成されたテストメタモデルのインスタンスから得ることもできる。それゆえ、実行すべき変換はマッピング規則に基づいており、要求メタモデルのどのインスタンスがテストメタモデルのインスタンスに変換されるかに準ずる。このことと関連して、部分的に、クラスおよび該クラスに含まれる具体的なインスタンスにしたがって２つのメタモデル間に対応関係が得られ、これらの間に相違が得られる。この相違には、一方から他方に変換プロセスによってマッピングされる相違も含まれるが、これだけに限定されない。
したがって有利な実施形態では、変換を実行するために自然言語要求と並行して形成された要求メタモデルのインスタンスはモデル変換によってテストメタモデルのインスタンスに変換され、このテストメタモデルのインスタンスでは上記のように、要求メタモデルのインスタンスの要素のうち少なくとも幾つかは、テストメタモデルのインスタンスの要素に変換されるように構成することができる。本発明では、これによって得られたテストモデルのインスタンスの方はデータ処理システムによって表示ユニット上で、ユーザによって読み取れて明確に理解できる自然言語のテスト仕様として表現されるように構成することができる。このことによって本発明では、自然言語のテキストセグメントが要求メタモデルと同様にテストメタモデルのインスタンスの要素に割り当てられるようにも構成することができる。したがって、これらの割り当てられたテキストセグメントはデータ処理システムによってディスプレイ上で、テストメタモデルの基礎となる構文によって得られたシーケンスで表示することができ、自然言語文をこのディスプレイでも形成される。
変換中には、１つの実施形態では、条件を記述する要求メタモデルのインスタンスの要素がテストメタモデルのインスタンスの要素に変換され、これによって、組み込みシステムの入力における値割り当てが影響されるように構成することができる。たとえば、自動車のリモートコントロールのボタンが押されるという条件が満たされた場合に自動車のドアが開けられるように構成することができる。この条件は要求記述で表現され、変換プロセスによって、リモートコントロールのボタンが押された状態を表す値が組み込みシステム上のボタンまたは該ボタンに対して設けられた入力に割り当てられるように、値割り当てに変化される。さらに変換では、条件に対する応答を記述する要求メタモデルのインスタンスの要素がテストメタモデルのインスタンスの要素に変換され、これによって、組み込みシステムの出力の値がテストされるように構成することができる。同じ例を参照すると、この要求は、上記の条件が適用される場合にボタンが押された場合、自動車のドアを開かねばならないということを示す。したがって、この条件に対する応答はドアを開くことである。すなわち、テストメタモデルのインスタンスでは、ドアが割り当てられている組み込みシステムの出力の値、すなわちたとえば自動車電子制御ユニットの出力の値は、読み出された値を参照することによって検査され、ドアを開けることを表す値が記憶されているか否かがテストされる。
本発明による方法によって要求記述が形成される際には、使用されるテキストセグメントが時間的観点も考慮するように構成することもできる。たとえば、特定の時間後または特定の時点での条件、ならびに関連の応答を記述することができる。また、不精確な時間的観点が要求に表現されるように構成し、たとえば、規定された最小期間の満了前には応答を行ってはならないことが表現されるように構成することもできる。本発明では、要求記述におけるこのような不精確な時間仕様は、時間に関して具体化される自由度を有するテストメタモデルのインスタンスの要素に変換される。
換言すると、テストメタモデルの関連のインスタンスは、要求記述に記載された時間的観点に関しては未だ具体化されておらず、テストを実行したいユーザが最初にこの自由度を具体化しなければならない。それゆえ、異なる時間的観点でテストを実行したい異なるユーザが、提供されたこの自由度を個別に具体化できるという特定の利点が得られる。
本発明の別の側面では、テストメタモデルのプラットフォーム非依存性のインスタンスからプラットフォーム依存性のテストプログラムが生成されるように構成することができる。しかしこのことの前提条件は、時間に関して未だ具体化しなければならない提供されているどのような自由度でもまずは、テストメタモデルのインスタンスにおいて具体化が行われることである。その後に形成されたプラットフォーム依存性のテストプログラムは、このために設けられたテストコンピュータ上で、該テストコンピュータ上でシミュレートされる電子制御ユニットをテストするか、または、テストコンピュータに接続された具体的な制御ユニットをテストするために実行することができる。このことと関連して、電子制御ユニットの固有の環境が付加的にシミュレートされ、該電子制御ユニットが実際の条件下でテストされ、かつ、テスト段階で通常は回避しなければならない実際の環境ではテストされないように構成することができる。
添付図面に、本発明に関する情報が示されている。
図１に、必須の実施形態およびオプションの実施形態による本発明の方法の概観が示されている。
これはたとえば、ユーザに対してデータ処理システムによって表示ユニット上にテキストセグメントを供給することによって作成されるユーザビューを示す。ユーザは、制限されたセットで提供されたテキストセグメントを選択し、これを使用して、これをまとめて自然言語要求テキストを、たとえば英語で構成することができる。ユーザ概観の左側には、テキストで作成された要求が、基礎となる形式的な要求メタモデルによって形式化されているのが示されている。それゆえここでは、要求の自然言語テキスト作成と並行して、要求メタモデルのインスタンス、たとえばＵＭＬモデルのインスタンスが作成され、データ処理システムによって形式化されるのが理解できる。
ここでさらに記載されるモデル変換によって、要求メタモデルのインスタンスはテストメタモデルのインスタンスに変換され、これは、コンピュータによって読み出し可能である形式的なインスタンスとしてテスト仕様を記述する。この形式的なテスト仕様、すなわちテストメタモデルのインスタンスは、テスト仕様書の自然言語のテキスト表現で表される。これは、ユーザによって自然言語でデータ処理システムのディスプレイ上で読み取ることができ、ユーザによって完全かつ一義的に理解することができる。
さらに、形式的に作成されたテストメタモデルのインスタンスに基づいて、テストプログラムのプラットフォーム依存性の生成を行うことができる。これは、要求の作成のために設けられたデータ処理システム上で実行可能であるか、別のデータ処理システム上で実行可能である。付加的に、たとえばライブラリの内容を結合することによって、変数または値またはプラットフォームまたは別の項目に関する別の情報を、このプラットフォーム依存性のテストプログラムに追加することができるように構成することもできる。また本発明では、ユーザがテキストセグメントを追加でき、該テキストセグメントは要求メタモデルにおけるインスタンスに割り当てることができるように構成することもできる。このようにして、基礎となる要求メタモデルに及ぶ拡張をユーザによって行うこともできる。
以下で、本発明による方法の別の具体的な実施形態を、まず幾つかの基本的な情報を与えてから、詳細に説明する。
ここではまず、上記および下記に挙げられる実施形態すべてに関して、実施形態と関連して挙げられる技術的特徴は特定の実施形態でのみ使用されるのではなく、別の実施形態でも使用できることを述べておかなければならない。したがって、開示された本発明の明細書全体の技術的特徴はすべて、本発明に重要であると見なすべきであり、任意の組み合わせでも独立しても使用することができる。
組み込みシステムはますます普及されてきている。現在、たとえば車両、現金自動預入支払機および洗濯機において組み込みシステムを見ることができる。自動車は５０個以上のネットワーク化された電子制御ユニットを有し、これらによって、たとえばウィンドウコントロールやアンチブレーキロックシステム等の機能がインプリメントされる。体系的な開発プロセスがなければ、複雑なシステムのこのようなネットワークを許容可能な品質で合理的な時間枠で形成することはできない。体系的な品質保証は、このようなシステムではどの開発プロセスでも固定化された構成要素である。
実際に、最も広まっている品質基準の１つにテストがある。組み込みシステムのソフトウェア部分が常に拡大するにつれて、ソフトウェアをテストするための作業負荷も増大する [BN03]。開発コストは作業負荷の増大とともに上昇するので、テストの自動化手法はこの作業負荷を低減することが望まれている。自動的なテスト実行がすでに標準的な技術となっているのに対し、テスト開発の自動化の大部分は、未だ研究段階のままである。
一般的な手法は、形式化された要求記述を使用し、たとえば状態マシンを使用する [CTF01]。しかし、形式的に仕様化された挙動記述から作成されたテストはどちらかというと、この形式的な仕様に対して作成されたソフトウェアの正確さに関する検査のみをカバーする傾向にある。システムが実際に、カスタマによって要望された要求によって開発されたか否かは、該システムと、カスタマによって本来定義された要求とを比較することによって確認することができる。図２に一例が示されている。ここでは、要求を作成する対象である電子制御ユニット（ＥＣＵ）が示されている。この要求からテストを生成して、ＥＣＵに適用しなければならない。
本発明は、自然言語の要求に基づく自動的なテスト生成方法を開示する。しかし、自然言語は一義的ではなく、また、要求は自然言語によって記載されてもいない。このことにより、まず最初に一義的な意味をテキスト形式の要求記述に割り当てる必要が生じる。
本発明の枠内では、要求の構文と要求記述のための語彙とを定義する要求メタモデルが作成されている。この語彙にはセマンティックが割り当てられている。メタモデルに基づいて要求を作成することにより、形式的な要求が形成される。これは、定義された要求をシステムが満たすか否かを検査するテストを生成する基礎を成す。
形式的なテストステップが要求から導出され、テストインプリメンテーションはこの形式的なテストステップから作成することができる。このテストステップはユーザによって自然言語の形式で提示されるので、テストシーケンスはユーザによって理解することができ、ユーザは、作成された実行可能なテストのテスト結果を理解することができる。本発明は、テストステップを記述するためのメタモデルの構想と、要求メタモデルのインスタンスからメタモデルのインスタンスを導出するモデル変換とを含む。その後、組み込みシステムの機能をテストするテストインプリメンテーションの生成が行われる。この機能は、要求で定義されている。
プロトタイプが、作成されたコンセプトが実際にどのように適用されるかを示す。このプロトタイプによって、自然言語の要求を簡便に作成し、テストステップのシーケンスを自動的に生成することができる。実行可能なテストは、この定義されたテストステップから作成することができる。
まず、本発明を理解および分類するのに必要な基礎を説明する。これには、組み込みシステムのための開発プロセスの説明と、要求の記述と、ソフトウェアのテストとが含まれる。最後に、関連する刊行物の既存のコンセプトを説明する。以下の本発明の開示の部分には、自然言語の要求の形式化のコンセプトと、該要求からの自動的なテスト生成の構成とが記載されている。さらに、具体的なテストとのマッピングをどのように行うかを示す。その後に、このコンセプトのプロトタイプインプリメンテーションを説明する。最後に適用例を挙げて、プロトタイプを評価し、自動的なテスト生成の可能な用例を挙げる。最後に、本発明の開示を要約および概要によって締めくくる。
基礎的事項の説明を始めるにあたり、まず、組み込みシステムのための開発プロセスの説明と、これらの特徴の議論を行う。その後に要求作成およびテストを詳述する。というのも、これら２つの開発段階は、自然言語の要求からの自動的なテスト生成に関して決定的に重要であるからだ。
このセクションは組み込みシステムを定義し、組み込みシステムの開発プロセスを説明する。組み込みシステムの開発と単なるソフトウェア開発とは区別される。
組み込みシステムは、センサおよびアクチュエータを介してシステム全体に接続され該システム全体における監視タスクおよび制御タスクを実行するソフトウェアユニット／ハードウェアユニットである [BvdBK98]。センサおよびアクチュエータは、組み込みシステムと周辺との間のインタフェースを成す。センサは、メカトロニックな動きを情報技術信号に変換する。アクチュエータは、情報技術信号をメカトロニックな動きに変換する [Gmb99]。
このようなシステムは典型的には人間のユーザから隠される。というのも、これらはシステム全体の不可欠部分として機能するからである。このようにしてユーザは、意識せずに組み込みシステムとインタラクションを行う。このようなインタラクションはたとえば、車両、現金自動預入払込機および洗濯機で行われる。[LR05] に、組み込みシステムの以下の定義が記載されている。
「組み込みシステムは第１に、物理的周辺に直接影響するという点で、別のコンピュータアプリケーションと区別される。このようなコンピュータは、周辺の物理的プロセスを制御する電子的マシンとして使用される。周辺の物理的プロセスを監視および制御するためにセンサおよびアクチュエータが使用され、これらは、物理的プロセスとコンピュータシステムとの間の通信環境を構成する。」
図３に、センサを介して物理的プロセスを監視しかつアクチュエータを介して該物理的プロセスを制御する組み込みシステムが示されている。物理的な観点で見ると、センサおよびアクチュエータは組み込みシステムの一部でもある。組み込みシステムの例に、とりわけ自動車技術において、組み込みシステムの物理的なインプリメンテーションであるＥＣＵがある [BvdBK98]。通常は、ＥＣＵはプロセッサとＲＡＭと別の電子的コンポーネントとから成る。これは、システム全体において技術的プロセスに対して制御タスクを実行する。[Gmb99] では、ＤＩＮ１９２２６による制御が以下のように定義されている。
「制御‐制御すること‐は、１つまたは複数の変数が入力変数として、システム内在的な規則に基づいて、出力変数である別の変数に影響するシステムにおけるプロセスである。」
組み込みシステムは、応答システムのクラスに分類することができる [LR05]。応答システムは常に周辺とインタラクションする。これは、発生時点が大抵は予測できない入力されたイベントを出力イベントに変換する。これはしばしば、時間仕様に準じて行われることが多い [BvdBK98]。車両のドアＥＣＵは、応答システムの１つの典型例である。ドアＥＣＵはたとえば、使用されているリモートコントロールによって生成された信号等の特定の入力変数にしたがって、ドアロックをロックまたはロック解除することによって応答する。
組み込みシステムが実行する監視タスクおよび制御タスクの正確さは大抵、機能の正確さにのみ依存するのではなく、タスクが実行される時点にも依存する。エアバッグの機能は、事故に応答するものの応答時間が１０分になる場合、正確であると見なすことはできない。したがって通例は、組み込みシステムはリアルタイムシステムである。リアルタイムシステムは、時間的条件に関連する機能を実行するので、機能の実行終了が予測できる [LR05]。
組み込みシステムは典型的には、（アナログ）信号を連続的にサンプリングして離散的（デジタル）信号に変換するデジタルシステムである。厳密に言うと、デジタルシステムは常に離散的に動作する。というのも、実際の世界からのアナログ信号をサンプリングするからである。アナログ信号のサンプリングはソフトウェアによって実行される。２つのソフトウェアサイクルの間で計算のために時間が必然的に経過するので、実行は時間連続的になることはできず、時間離散的になってしまう。したがって「離散度」は、アナログ信号のクロック周波数またはサンプリングレートに起因し、有限のサイズのみを有する。
例
「中央ロックシステムは、複数のＥＣＵによってインプリメントされる機能である。中央ロック機能の挙動をここで説明する。これは、本発明の開示全体における適用シナリオ例として使用される。
中央ロックシステムは現在、多くの車両の標準的な特徴の１つとなっている。これは、ドライバおよび乗員に対して、利便性を増大して安全性を改善するものである。すべてのドアの集中的なロックおよびロック解除の他に付加的に、中央ロックシステムのタスクにはたとえば、ドアがロックされた場合にすべてのウィンドウを閉める機能や、事故時にすべてのドアをロック解除する機能等の機能を含むことができる。もちろん、中央ロックシステムはテストしなければならない。というのも、中央ロックシステムの機能は部分的に、セーフティ上重要な側面を有するからである。事故発生時にドアのロック解除が行われない場合、人がこの誤りによって負傷することがある。中央ロック機能のテストは、ネットワークでこの機能を実施するＥＣＵの挙動をテストする。
通常は中央ロック機能をインプリメントするために、各ドアごとに１つのＥＣＵと、１つのリモートコントロールと、各ドアごとに１つのロックとが必要とされる。ＥＣＵ間の通信はバスシステムを介して行われる。ドアＥＣＵはセンサを監視して、たとえば、ドアボタンによってドアがロック解除されているのを検出し、個別のアクチュエータを制御する。中央ロックに関しては、すべてのドアボタンがアクチュエータによって下位置にされる。
このセクションではまず、[Bal98] に記載されているソフトウェア開発プロセスで使用されるアプローチが説明され、その後、組み込みシステムに特有の特徴の説明に続く。
ソフトウェア開発のプロセスは、別の製品の作成と格段に異なる。ソフトウェアは実体を持たず、ソフトウェアの開発の進度を評価するのは非常に困難である。その理由は、開発プロセス中に得られた新たな知識が別の開発に影響を及ぼし、また、先行の結果にも影響を及ぼすこともあるからだ。このことは、すでに完了された観点の拡張および修正に繋がるので、特定の製品部分は条件付きでのみ完了される [Bal98]。ソフトウェア開発プロセスの上記の特性は、所要時間の推定ひいてはコストの予算が極度に困難であるため、非常に多くのプロジェクトが失敗して損失を引き起こすことを意味する。
まさにこの点では、ソフトウェア管理が種々の手法を使用して、可能な限りプランニングおよび予測できる開発プロセスを作成する役割を果たす。開発のプロセスシーケンスを記述するためのモデルは、手順を構造化するのに重要な手助けとなる。プロセスモデルを使用することにより、開発がプランニング可能になり、予測を行うことができる。ソフトウェア開発が成功するか否かは、早期の誤り解消に依存する。行わなければならない必要な修正が遅くなるほど、再作業プロセスはより高コストになる。というのも、再作業プロセスは複数の開発段階をカバーするからである。
図４に、プロセスモデルにおける基本的な開発段階が示されている。まず、開発すべきシステムに関するカスタマの期待および要望が、要求の形態で定義される。ソフトウェア要求は、この要求から導出される。既存のシステムおよび環境を考慮するために、一般的な条件の分析が行われる。というのも、このような一般的な条件は新たなシステムに影響するからである。その次に、ソフトウェア設計の作成が行われる。これは、インプリメンテーション段階でインプリメントされる。開発されたソフトウェアは、運営開始される前に、数多くのテストを受ける。多くのプロセスモデルでは、この設計段階はさらに、予備設計と詳細設計とに細分化される。前者では、システム全体のシステムコンセプトが形成されるのに対し、後者では、個別のコンポーネントの機能に焦点が当てられる。
図４に示されたモデルは、ウォーターフォールモデルと称される。これは、ソフトウェア工学において最初の巧妙なプロセスであり、後に開発された数多くのモデルの基礎となった。ウォーターフォールモデルの基本は、先行の段階が完了されるまで次の段階は決して開始されず、段階は相互に依存している [Bal98]。各段階は、該段階で作業を実行するための方向を提供する目標が定義されることによって開始される。各作業の終了時に、ドキュメントが形成される。_これは、段階前に定義された目標がすべて満たされたか否かを検査するために使用される。否である場合、修正ドキュメントが作成され、プロセスは先行の段階の開始まで戻る。このようなフィードバックにより、目標の定義から実行まで、そこから個別の段階のドキュメント作成まで、複数回の繰り返しを行うことができる。このことは、各段階ごとに集中的な検査が行われ、可能な限り早期に誤りを発見できることを意味する。
Ｖサイクルは、ウォーターフォールモデルの拡張である。これは、各段階と並行してテストを置くことにより、品質保証を完全にする。図５に示されているように、個別に実装されたモジュールをモジュールテストでテストする。その後にインテグレーションテストが行われる。これは、複数のモジュールの組み合わせで挙動テストを行うことを特徴とする。システム全体のテストはシステムテストで行われ、その後に承認テストが行われる。ここでは、カスタマ要求がインプリメンテーションされているか否かが検査される [Bal98]。
Ｖサイクルは本来は組み込みシステムのために開発されたものであるから [Bal98]、ソフトウェアは常に、情報技術システムのコンポーネントと見なされる。このようなシステムの開発プランには、ソフトウェア開発およびハードウェア開発の双方が含まれるので、電子的部分とすることができる。ここでの最大の課題は、個別のコンポーネントの開発プロセスを相互にコーディネートすることである。ソフトウェアは別個のものとして見なすことはもはやできないので、組み込みシステムとしてのソフトウェアの開発は、単なるソフトウェア開発とは異なる。ソフトウェアをハードウェアシステムに統合するためには、ハードウェアを正確に理解する必要がある。
さらに、ソフトウェアと物理的周辺との間には強いインタラクションが存在する。これによって、すべての段階において開発プロセス相互間を注意深くコーディネートする必要が生じる。動的なインタラクションを仕様化する作業、モデリングする作業およびテストする作業が、より重要になる。プロセス後期で検出される誤り、たとえば仕様エラーまたはコーディネートエラーは、ハードウェア修正を高コストにする可能性がある [LR05]。
組み込みシステムの開発プロセスでは、Ｖサイクルによって、開発全体が複数の作業パケットに区分化される。図６にこのような区分化が示されている。システム全体に対して要求定義が形成された後、開発プラン全体がセグメントに下位分割される。これらはさらに、ハードウェアユニットおよびソフトウェアユニットに細分化される。ソフトウェアユニットは最終的には、複数のソフトウェアモジュールから成る。このように記述された区分化は主に設計段階で行われ、その後、個別のモジュールの開発が行われる。これは、インテグレーションテスト中に再びまとめられる [Bal98]。
Ｖサイクルでの作業は連続的に、Ｖで現れる順序で行われる。このことから、すべてのテスト作業はインプリメンテーションが終了するまで行われないことが理解できる。しかし、インプリメンテーション段階より随分前から、エラーがしばしば発生する。設計段階では要求を誤解釈する可能性があるので、システムの設計自体がエラーとなり、カスタマの観点から見て正確なシステムが得られない。早期の段階で生じたが後にならないと発見および補正されないエラーによって別のエラーが発生し、このようなことが開発段階全体において全面的に生じてしまう。これによって、エラーの可能性が増大する。[Bal98] によれば、開発プロセス全体で生じるすべてのエラーのうち５０％以上が、要求段階および設計段階で生じる。これらの大部分は、承認テストおよび運営段階まで発見されない。
ソフトウェアプロジェクトは時間の経過とともにますます複雑になり、エンジニアを支援したとえばＶサイクル等のプロセスモデルを補完する技術が必要となる。自動車電子回路では、すべてのソフトウェアエラーのうち１５％〜４０％の原因が、不完全かつ多義的な仕様書であった。すべての問題のうち４０％〜６０％がインプリメンテーション段階中に生じ、これらのエラーのうち半分は、後続の修正から発生する [ONS06]。モデルベースのソフトウェア開発は、複雑なシステムの設計を明瞭かつ構造的に編成し、実行すべきテストを早期の段階で行えるようにする標準的な手法にまで発展した。さらに、多義的および不完全な仕様によって引き起こされる多数の問題は、モデルを使用して解決することができる。モデルドリブンエンジニアリング（ＭＤＥ）[Ken02] およびモデルドリブンアーキテクチャ（ＭＤＡ）[MDA02] が、モデルベースのソフトウェア開発のアプローチを記述する。
ＭＤＥはとりわけ、異なる抽象化レベルでの開発と、テスト作業の編成および自動化とを提案する。作成すべきシステムのアーキテクチャおよび挙動はモデルの形態で、たとえば統一モデリング言語（ＵＭＬ）からの標準的な表記法を使用して設計される [Obj05]。モデルは、実際の世界からのオブジェクトの抽象化されたものである [Bal98]。
このようなモデルは機械読み取り可能であり、人間が理解することもできる。機械読み取り可能であることにより、ツール支援でモデルを詳細化することができ、開発プロセスを自動化して、抽象モデルからさらに具体的なモデルまで繰り返し実行することができる。このアプローチは開発プロセスを構造化して明瞭に編成するので、複雑さが低減される。モデルの正確さを有効性確認するためには、形式的な技術が使用される。その目的は、比較的具体的なモデルが、比較的高い抽象化レベルで形成されたモデルの仕様に一致するか否かをテストすることである。さらにモデルを使用して、システムが完全に開発完了される前に機能をテストすることができる。このようにして、開発プロセスの早期の段階でエラーを見つけることができる。
ＭＤＡは、仕様化されたモデルからインプリメンテーションを導き出す手法を含む。このモデルに修正を施す場合、プログラムコードを再生成することによって、モデルとコードとの間の不一致が回避される。このようなアプローチによって、手動のプログラミング中に発生するエラーが回避される。
現在、モデルベース開発自体は数多くの実際の分野で確立されている。自動車産業では、組み込みシステムの開発分野を例とすると、記述の数学的モデルおよび高レベルの形態を設計段階で使用して、実行可能なモデルの形態で仕様書が形成される。制御アルゴリズムを記述するためのモデルは典型的には、グラフィックのブロック図の形態で設計される。モデルとして設計されたこのような仕様書は、たとえばＭＡＴＬＡＢ（登録商標）／Ｓｉｍｕｌｉｎｋ（登録商標）のような適切なモデリングシミュレーション環境でシミュレートして、ソフトウェアの挙動を設計段階と同じ早期の時点で、調査および評価することができる。このことにより、テストを設計段階から行い、この早期の段階でエラーを見つけて消去することができる。モデルは、ソフトウェア設計のすべてのレベルで使用することができる [ONS06]。
このセクションは、ソフトウェア開発プロセスで使用されるウォーターフォールモデルおよびＶサイクルプロセスモデルに即して、ソフトウェア開発プロセスを紹介している。その後に、モデルベースソフトウェア開発の説明が続いている。これは、プロセスモデルの使用を補完するものである。どのプロセスモデルが使用されるかに関係なく、必ず、要求が定義される開発段階とテスト段階とが存在する。要求記述方法およびテスト技術を、以下でより詳細に説明する。
上記で紹介されたウォーターフォールモデルやＶサイクルモデル等のプロセスモデルは、要求定義段階から開始する。要求を開発プロセスの開始時に定義するためには、カスタマと請負人との間の意思疎通が必要である。カスタマは、開発すべき製品に関する考えおよび要望を説明する。これによって、要求が形成される。請負人の役割には、所望されている製品の製造目標がカスタマの完全な満足に可能な限り近づくように、カスタマの要求を分析することが含まれる。たとえば自動車産業等の多くの産業では、製品のカスタマは要求定義に関与しないが、カスタマ‐請負人のシナリオは多くの製造プロセスに存在する。製造のために必要な部品がサプライヤから得られる場合、サプライヤが請負人であり、製造者自体はカスタマとなる。製造者はサプライヤに要求を伝えなくてはならない。
「要求」のコンセプトは、電気電子学会（ＩＥＥＥ）によって [IEE90] において次のように定義されている：
1. 問題を解決するかまたは目標を達成するためにユーザによって必要とされている条件または能力。
2. 契約、水準レベル、仕様、または別の正式に依頼されたドキュメントを満たすために、システムまたはシステムコンポーネントが満たすかまたは有しなければならない条件または能力。
3. （１）または（２）の条件または品質を表現する記録。
SOPHIST GROUP によって [Rup04] において、実際的に容易に理解できる要求の簡略的な定義が記載されている：
「要求とは、製品、プロセス、プロセスに関与する人の特性または動作のステートメントである。」
カスタマの説明を、カスタマが意図している通りに理解するのは困難である。意思疎通する人の技術的語彙および知識の相互間の差異が大きいほど、このプロセスはエラーを含みやすくなる。さらに、思考の相違、社会的背景および経験も、意思疎通に影響する。このような問題は、要求が自然言語で表現される場合に行われる表現プロセスに起因する。
この問題は製造者‐サプライヤの関係では、それほどにはならない。このようなケースでは、両当事者は通常は専門家であるから、同レベルで意思疎通を行うことができる。しかし、異なる分野の人間が同一の会社で一緒に働くことが多い。このような学際的な構造は、各分野の特殊な知識が得られるので、非常に異なる観点を開発プロセスにおいて考慮できるという利点を有する。たとえば組み込みシステムの開発では、エンジニアおよび情報工学従事者が一緒に働くことが多く、その理由は、双方の知識が必要とされるからである。しかし、異なる分野に属する専門家間での意思疎通でさえ、上記の問題を引き起こし、もっぱら専門家のみが関与する場合には、要求記述の困難さが解消されないことがある。
[Rup04] に記載された要求記述の問題を、以下で説明する。現実の知覚の仕方は、各人で個別である。個人的に重要な観点に目がいくので、知覚には一部の現実しか含まれない。知覚変換という用語は、このような無意識のプロセスを意味する。他の情報は、言語的表現で失われる。自然言語での知識の表現は、両人の各個人の知覚が同じであったとしても、人によって異なる。このマッピングプロセスは、表現変換と称される。
既述のようなプロセス全体は現実の錯誤を含んでいるため、不完全または多義的な要求で表されている所望のシステム機能の表現誤りも含んでいる [Rup04]。
要求を完全かつ一義的に記述するのが目標である。言語的表現で失われた情報を回復しなければならない。こうするためには、変換を逆にする必要がある。
人の個人的な知覚によって、現実は特定の異なる観点にまで縮小される。情報内容は、複数の人に質問することによって増加することができる。というのも、各人は別の詳細を知覚しており、異なる人のステートメントが相互に補完し合うからである。知覚変換で失われた観点を回復する別の手段はない。というのも、人の感覚に問題なく影響を与えることはできないからである。表現変換は、失われた情報を発見することによって解決することができる。しかしこうするためには、問題の原因となっている変換の種類の正確な知識を分析者が有することが前提条件である。失われた情報を言語的作用によって検出できる場合には、この情報を得るための質問によって、要求の不完全性が解消される [Rup04]。
カスタマに特定の質問を行うことによって、低品質の要求に反復的な改善を施すことは、時間がかかる手法である。より効率的な手順を実現するためには、高品質の要求を直接作成する。典型的な表現誤りは、構文規則にしたがって逐次的に文の構造を調査して最適な要求を形成することによって回避することができる [Rup04]。
組み込みシステムの要求は、システムが有さなければならない機能を定義する。上記のように組み込みシステムは、センサおよびアクチュエータとして構成されたインタフェースを介して物理的周辺と相互作用する。入力および出力という用語は、以下ではこのようなインタフェースに対して使用される。組み込みシステムの各入力側は、物理的周辺の特定の要素または特性を観察する。自動車の要素および特性の例は、リモートコントロールのボタン、ドアボタンおよび現在の速度である。物理的要素は、それぞれ特定の状態を有する。リモートコントロールのボタンは押された状態を有するかまたは押されていない状態を有し、ドアボタンは上か下かであり、速度は常に何らかの値を有する。物理的要素の各状態に対応する適切な値が組み込みシステムの入力側に供給され、その値は該システムによって処理さえる。物理的要素の制御は、組み込みシステムの出力側に値を出力し、物理的要素を特定の状態にすることによって行われる。典型的にはユーザは、該ユーザが行った入力に対して組み込みシステムが応答することを要求する。
図７および８に、実際にこのような形態で見られる要求が示されている。
このような機能を要求で表すためには、以下の情報を要求に記述しなければならない：どの入力側においてどのような入力値に対し、どの出力側においてどのような出力値が期待されるか？この結論は、まず値と出力との割り当てが前提条件として必要であり、値と特定の出力との割り当てを、期待される応答として記述しなければならないことである。
[Hu00] によれば、ソフトウェアの要求は大抵、「前提条件が生じた場合には、期待される応答が行われなければならない」という形のステートメントによって表現される。このようなステートメントは、組み込みシステムの要求でも行うことができる。このセクションで挙げられた実際の要求は双方とも、この形で表すことができる。システムが入力側で前提条件として値を受け取った場合、この前提条件に対する応答として、出力側に特定の値が存在しなければならない。したがって、システムは前提条件を、期待される応答が結果として生じるように処理しなければならない。
図９に、この一般的なプロセスと中央ロック機能とが一例として示されている。リモートコントロールの「ロック解除」ボタンが押された場合、このことは、値が割り当てられた入力となる。その結果として、ドアＥＣＵは車両のドアをロック解除しなければならない。このことは、このシステムの機能である。車両のドアのロック解除が出力であり、‘unlocked’ （ロック解除）が出力の値である。
組み込みシステムはますます普及されてきており、組み込みシステムのソフトウェアは個別のソフトウェアコンポーネントのネットワーク化によってますます複雑になってきているので、品質保証がますます重要になってきている。満足のいくソフトウェア品質が確実に保証されるようにするためには、品質要求を定義してこれを遵守しなければならない。ソフトウェアの品質特性は、予め仕様化された特性に対するソフトウェアの正確さである。ソフトウェア開発プロセスの開始時に要求定義が行われた後、製造すべきソフトウェアの特性を形式的に定義する仕様の作成が行われる。このような形式的に仕様化された特性に関してソフトウェアをテストすることを、検証（verification）と称する。要求から仕様を作成する際にエラーが生じるというイベント時には、検証では、仕様に対してソフトウェアの挙動が正確であることのみが保証される。しかし、カスタマによって所望されているタスクを満たすためのシステムの適性は、この手法ではテストされない。要求に関するソフトウェアの有効性のテストは、有効性確認（validation）と称される [Tha00, Pel]。
品質保証の手法の分類は、文献で異なっており、たとえば [Bal98] および [Lig02] で異なっている。図１０に、以下で挙げられる手法の概観が示されている。エラーを検出する手法と、エラーが存在しないことを証明する方法とに分類する幅広く使用されている基本的な下位分類が、テストという用語を分類するのに適している。テストは、エラーを見つけるための作業である。エラーが存在しないことを示すことは、テストに含まれない [Dij70]。
エラーを見つける手法は、静的な手法と動的な手法とに分類される。この分類の基礎となる基準は、エラーを検出するためにソフトウェアを実行するか否かである。静的な手法では、ソフトウェアを実行させることなくソフトウェアを調査する。インスペクション、レビューおよびウォークスルー [Bal98] がこのカテゴリに属し、ソフトウェアをチームで手動検査することに基づいている。動的な手法は、選択された入力データによるプログラム実行を使用する。
別の分類は、ソフトウェアの観察深さに基づいて行われる [Pel]。ブラックボックステストは、テスト対象のインタフェースのみを観察する。ソフトウェアが、選択された入力によって実行完了した後、出力を評価する。実際の出力が正確であることを検査するためには、この出力と、予め定義された期待される出力とを比較する。ホワイトボックステストは、テスト対象のすべてのコンポーネントを使用する。この場合、この構造全体がオープンになっている。したがって、テスト対象の制御フローを追跡して、その論理を理解することができる [Tha00]。この手法によって、インタフェースに影響しないエラーを見つけることができる。
さらに、エラーを検出する手法は機能テストと構造テストとに分類することができる。テスト対象の機能的特性は、要求で定義された機能であり、その正確さを仕様に基づいてテストする。このテストはブラックボックステストであることが多い。というのも、重要なのはテスト対象の内部ではなく、可視の挙動であるからだ。この種類のテスト手法はしばしば、テスト対象のプログラム構造全体に完全に到達しないことが多い。というのも、特定の入力データの場合にしか実行されないプログラム部分があるからだ。構造テストの目的は、テスト対象の構造を完全にカバーすることである。テスト対象のプログラム部分はすべて目を通さなければならない。というのも、到達できない部分は不必要であるからだ。プログラムコードはこのテストでは可視でなければならないので、この手法は常にホワイトボックステストである [Lig02]。その目的は、テスト対象のすべての部分が完全に実行されるように、入力データを選択することである。不必要な部分は無駄コードと称され、理論的には削除することができる。しかし、テスト実行は常にサンプルでしかないので、この手法では未だ、コードに到達できないという証明にはならない。可能性のあるすべての入力データを組み合わせる完全な検査は、実際には過度に高コストである。
エラーが存在しないことを証明する手法に、定理証明 [Lov78, CLL97] およびモデル検査 [CGP00] がある。モデル検査の目的は、モデルが所与の形式的な要求仕様を満たすか否かを確認することである。要求された特性の自動的なテストは、システムのすべての可能な状態でアルゴリズムによって実行される。
組み込みシステムの有効性確認を行うためには、このテストは、カスタマによって定義されたすべての機能をシステムが有するか否かをカバーする。システムの周辺におけるシステム全体に焦点が当てられる。このテストでは、システムが特定のユーザインタラクションのイベントでどのように挙動するかを検証しなければならない。対象となる焦点は、タスクを果たすためのシステムの適性のみであり、システム内部のプロセスではない。したがって本発明は、ブラックボックステストに集中する。現在、テストの大部分は未だ手動で作成される。ブラックボックステストを実行するためのテストケースを手動で作成する手法は、以下に記載された分類ツリー法である。
１つのテスト対象に対し、非常に数多くの入力値が存在し、入力空間を構成する組み合わせが非常に数多く存在することがある。並大抵の努力では、可能性のあるすべての入力によってテスト対象をテストすることはできない。したがって、入力空間は特定の観点にしたがって分割され、分割された各部分は等価クラスに下位分類される。このようなクラスは、１つのクラスにおいて、テスト対象がすべての入力値に対して正確に挙動するかまたは誤って挙動するように選択しなければならない [GG93]。等価クラスは、付加的な基準にしたがってさらに下位分類に分割することができる。その結果として得られるのが、分類ツリーである。テストシーケンスは、入力空間の区分化を基礎として作成することができる [Lam06]。このことは、特定のクラスと、各クラスからテストのために選択された１つの値とを組み合わせることによって行われる。
「テスト」という用語の分類の後は、ブラックボックステストを実施するのに必要なテストの要素をここで紹介する。テストすべき対象はたとえば、モデル、プログラムコード、または実際のシステムのプロトタイプであり、テスト対象と称される [Bal98]。テスト対象の挙動をテストするためには、テストを実行するために入力データが必要とされる。入力データは、スティミュラスデータとも称される。
組み込みシステムは、単純なアプリケーションプログラム、すなわち、各入力側ごとに値を受け取り、この入力値によって実行され、実行後に出力を返した後に終了する単純なアプリケーションプログラムのようには挙動しない。しばしば、異なる入力値が入力側に時系列で到達する場合が多い。テスト対象をこのような入力によって実行することにより、テスト対象の挙動を表す出力が得られる。しかし、この出力だけでは、エラーが存在するか否かを示唆しない。この出力を、テスト者の期待に一致する値と比較しなければならない。期待される出力は基準データと称され、テスト実行前に定義しなければならない。テストの入力データのセットは、関連の基準データとともにテストケースを構成する。
組み込みシステムの機能の正確さの情報を供給するテストを作成するためには、テスト目標を表現しなければならない。これによって、テスト対象のどの特性をテストすべきかを定義しなければならない。その基礎は、テスト中に必要とされるオブジェクトの特性を含むドキュメントによって、たとえば仕様書またはカスタマ要求等によって提供される。入力データは、定義された目標にしたがって選択され、テスト対象に時系列で適用される。また、基準データはテスト目標にしたがって決定される。図１１に、個別のコンポーネントを有するテストシーケンスを示す。
組み込みシステムはシステム全体で使用されるように開発され、インタフェースを介して該システムと相互作用するので、組み込みシステムが使用される環境で組み込みシステムをテストしなければならない。組み込みシステムを実際の環境でテストするのは非常に高コストになることが多く、セーフティ上危険であることもある。たとえば、車両内のＥＣＵの機能をテストするためには、複数のテストドライブを実行しなければならない。数多くのＥＣＵが、それ無しでは車両での使用のセーフティが保証されない機能を実行するので、予めテストされていないＥＣＵを有するテストドライブは危険性をはらんでいる。
また、組み込みシステムが後で組み込まれるシステム全体が完全に製造完了される前に、組み込みシステムを開発することがある。しばしば、システムのコンポーネントの開発作業は、開発時間を短く抑えながら行われることが多い。この場合、組み込みシステムを実際の環境でテストすることはできない。
しかし上記では、組み込みシステムのテストは開発の早期の段階でも必要であることを紹介した。どのようなエラーであれ、早期の段階で検出されるのが遅いほど、エラーを補正するのに必要な変更はより高コストになる。というのも、このような変更は複数の開発段階をカバーするからである。それゆえ、組み込みシステムの実際の環境の挙動を模擬する手法が必要である。上記のように、現在使用されるモデルベースの開発手法によって、シミュレーションによって開発の早期段階でシステムをテストすることができる。種々の開発段階で使用可能なシミュレーションオプションを使用することにより、開発作業と並行して、検査すべき結果が得られる。このようにして、組み込みシステムのモデル、プログラムコードおよびプロトタイプを、完全にシミュレートされた環境でテスト対象と同様にテストすることができる。たとえば、ソフトウェアモデルの形態で、ＭＡＴＬＡＢ（登録商標）／Ｓｉｍｕｌｉｎｋ（登録商標）によって、周辺を表すことができる。
図１２に、インタフェースを介してテストプラットフォームに接続されたテスト対象が示されている。シミュレートされた環境がテストプラットフォーム上で実行される。テストは、テストプラットフォームにアクセスするテストツールで実行される。テストは初期には、使用されるテストプラットフォームに依存せずに作成されているので、テストで使用される指定子がプラットフォーム固有の変数および値にマッピングされる。これらの変数がテスト対象のインタフェースをなす。
モデルベース開発では、組み込みシステムのモデルを設計段階で、ソフトウェアツールの支援で開発する。このモデルをシミュレートすることができる。組み込みシステムのモデルは、システム全体のコンテキストでのみテストすることができるので、テスト環境が必要である。組み込みシステムの周辺自体も、このためにモデルとしても表現され、以下では周辺モデルと称される。組み込みシステムのモデルは初期は、該組み込みシステムの周辺に依存せずに、該組み込みシステムを入力によって実行して得られた出力を分析することによってテストすることができる。次のステップで、組み込みシステムと周辺モデルとの間の相互作用をテストする。周辺モデルはモデルに対して入力を供給し、モデルの出力を受け取り、この出力に対して応答する。これが、今度は新規の入力を成す。テストプラットフォームは、モデルのパラメータを変更し、テスト対象の出力を読み出して記録する機能を提供せねばならない。これらのタスクはテストによって実行される。組み込みシステムのモデルをシミュレーションによってテストすることは、モデルインザループと称される（ＭＩＬ）。図１３にこのシナリオが示されている [BN03]。
モデルインザループによるテストが完了した後、組み込みシステムのプログラムコードがモデルから自動生成されるか、または手動で開発される。このプログラムコードは、モデルと同様にテストすることができる。テストプラットフォームおよび周辺モデルは再使用することができる。ここで、テスト対象のみが、モデルではなくプログラムコードとなる。このテストプロセスはソフトウェアインザループ（ＳＩＬ）と称される（BN03）。プログラムコードは初めに、シミュレーションコンピュータのためにコンパイルして該シミュレーションコンピュータ上で実行することができる。次に、ターゲットプロセッサのエミュレータをテストのために使用して、プログラムコードをそのために、このステップでコンパイルする。この手順の目標は、ターゲットプロセッサ上のコードの挙動をテストすることである。
組み込みシステムの開発が進行するにつれ、組み込みシステムのプロトタイプが形成され、テストされるプログラムコードがこのプロトタイプにロードされる。組み込みソフトウェアが実際のハードウェア上で正確に実行されるかをテストするためには、ハードウェアインザループシミュレーション（HIL simulation）によってこのプロトタイプをテストする。たとえばプロトタイプは、完成されたソフトウェアを有する車両用のＥＣＵとすることができる。プロトタイプと周辺モデルとを一緒にテストするためには、テストプラットフォームは、ＥＣＵのプロトタイプを接続できる実際のインタフェースを提供しなければならない。というのも、これは実際のシステム全体内になるからだ。このときに、リアルタイムシミュレーションを実行することができる。こうするためには周辺モデルは、ＰＣ上で実行されるのではなく、リアルタイム可能なシミュレータ上で実行される。図１４に、ハードウェアインザループシミュレーションが示されている。
ハードウェアインザループ技術は、実際の開発中にＥＣＵプロトタイプをテストするための確立された実用的技術となってきている。テストドライブで発生するすべての誤りのうち最大９０％は、ＨＩＬシミュレーションによって再構築することができる [ONS06]。
ブラックボックステストの領域では、テストという用語はしばしば、テスト対象を特定の入力データによって実行することのみを意味することが多い。しかし、テストには、テスト実行だけ以上のものをカバーする。まず、テストを開発しなければならない。これには、目標の定義とテストケースの準備とが含まれる。正確には、適正な入力および基準データを選択して、特定のテストケースによってテストを実行することにより、テスト目標に達するようにしなければならない。実行可能なテストを作成するためには、個別のテストステップをまず定義してから、テスト仕様に記述することが多い。テスト仕様書は、実行可能なテストをインプリメンテーションする基礎となる。
テスト実行の後に、結果が評価される。このときに、出力と基準データとを比較して、何らかのエラーの情報を得る。結果とそれに関連するテストケースを、ドキュメンテーションで記録しなければならない。この手順は、長期的に見て利益をテストから得るための非常に重要なタスクである。図１５にテストプロセスフローが示されている。この文献は、個別のプロセス段階に分割する際に僅かな差異を有する。ソフトウェアコンポーネントをテストするための BS 7925−2 標準規格 [iST01] では、テストを次のステップに分割する：テストプランニング、テスト仕様化、テスト実行、テスト評価、およびテスト記録。
テストプロセスをより容易に、高速に、かつ確実にするために、自動化技術がますます開発されてきている。テスト実行は現在、すでに自動化されている。多くの企業では、テストを効率的に行うために、テストを週末にわたって、または夜間に自動的に実行する。研究努力の中には、評価 [CSW06] およびドキュメンテーションを自動化することを対象とするものがある。テストケースは、テスト生成の一部としてすでに生成することもできる [CTF01, Hu00]。さらに、定義された仕様に対してシステムの機能をテストする手法が数多く存在し、たとえばモデル検査が存在する [CGP00]。
以上のセクションでは、組み込みシステムを定義し、組み込みシステムの開発プロセスを説明し、この要求定義およびテスト段階を、詳細に説明した。要求が、前提条件と、システムが該前提条件から作成しなければならない期待される応答とを仕様化することを説明した。テストでも同様の要素が見られる。上記のように、テスト中にシステムに入力データが与えられる。基準データと称される特定の出力データが、このデータに対する応答で期待される。
開発コストは増大し、それゆえテストコストも増大するので、テスト生成の自動化が望まれている。すでに、定義された挙動仕様に対してシステムの機能をテストする手法が数多く存在する。しかし、ソフトウェアの仕様化された機能すべてが正確に挙動しても、このことが、要求された機能をソフトウェアが有することを意味するわけでない。このような正確な機能に到達するためには、ソフトウェアに対して定義された要求を満たさなければならない。それゆえ、ソフトウェアの挙動が正確であるか否かを、要求に関してテストしなければならない。要求は初期には、通常はもっぱら、テキスト形式で表現されているので、このテキストが有効性確認のベースとなる。本発明の目的は、テキスト形式で表された要求からテストを自動生成する課題を解決することである。
関連事項に対する既存のアプローチを以下で紹介および評価する。
要求テキストからテストを自動生成することと共通する種々の側面を有する既存のコンセプトを紹介する。
SOPHIST GROUP は、自然言語の要件の分析とオブジェクト指向の手法とに関する。これは、企業に対して知識を提供して、企業が該企業のシステムおよび／またはソフトウェアの開発プロセスを、可能な限りエラーなしで効率的に実施できるようにする。この枠組みでは、SOPHIST GROUP はカスタマを助言、訓練およびツール開発によってサポートする。SOPHIST GROUP から２つのコンセプトを以下で説明する。
既述のように、要求が完全であるか否かを検査し、必要である場合には、カスタマからの情報によって拡張しなければならない。カスタマは、とりわけこのことに関して質問される。SOPHIST GROUP は、要求を反復的に作成するための規則のセットを定義する。このようにして、情報のギャップを回避することができる。このような規則の１つに、暗黙的に定義された前提の探索がある [Rup04]。しかし、反復的な改善は要求作成を行う効率的な手法ではないので、SOPHIST GROUP は、高品質の要求定義を６つのステップで作成するためのコンセプトを [Rup04] で開発した。このコンセプトは、[Rup04] によって以下のように定義された構文論的な要求テンプレートに基づいている：
「要求テンプレートは、１つの要求の構文構造を定義する組立プランである。」
以下の例が、どのようにテンプレートを使用するかを示している。
例：
「中央ロックシステムは、車両のすべてのドアが車両ユーザによってロック解除できる機能を有さねばならない。この事実を記述する人が異なれば、この記述は異なる可能性がある。「中央ロックシステムは、車両のドアすべてをロック解除できなければならない」または「車両のタスクはすべてのドアをロックすることである」。これらのステートメントは、以下の質問を生じさせる可能性がある：中央ロックシステムは、このロック解除自体を行うのか否か？中央ロックシステムはいつこのタスクを行うのか？これは、この表現が不完全であることを示す。」
所望の機能は、要求テンプレートにしたがって表現しなければならない。その開始点は常に、要求を適用しなければならないシステムである。この場合、中央ロックシステムがそのシステムである。
ステップ１：要求の中心的なステートメントは、システム挙動を定義する機能に含まれる。これをまず識別して、動詞として表現しなければならない。この例での決定的な動詞は「ロック解除」であり、これは以下でプロセスワードと称される。
ステップ２：この時点で、３つの別形が選択肢として存在する。システムは、初めに独立して定義されたプロセスを実行するか、または機能をユーザに提供する。最後の選択肢は、システムはこのプロセスを第３者にしたがって実行することなので、システム自体は受動的な役割のみを有し、外部の結果を待つ。これら３つの可能性は、以下の言葉で要約される：
・システムアクティビティが独立していること。
・ユーザインタラクションが行われること。
・インタフェースが要求されること。
この時点での要求のコアは、システムの役割を果たす中央ロックシステムと、プロセスワードである「ロック解除」と、このロック解除をトリガする車両ユーザである。この例はユーザインタラクションに関し、このことは図１６に示されている。
ステップ３：正当な義務の程度を表すためには、「しなければならない（must）」、「すべきである（should）」および「するであろう（will）」のキーワードのうち１つを使用する。選択されたこの用語は、要求が正当に結びつけであるか、緊急に勧告されているものか、または未来であるかを示す。この例では、「しなければならない（must）」という用語を使用して、これが正当な結びつけであることを表現しなければならない。
ステップ４：失われたオブジェクトおよび追加をここで組み込まなければならない。このような質問をすることができる：中央ロックシステムがロック解除すべきものは何であるか？その答えは車両のすべてのドアであり、この例ではこれが要求のオブジェクトである。図１７に、このことがグラフィック形式で示されている。（注：このテンプレートはドイツ語をサポートするので、図面および実施例の説明はドイツ語構文を示している。このことにより、ここで挙げられた例では英語文が不的確になっている。）パターンの構造は図１６と比較して僅かに変化している。オブジェクトおよびオブジェクト拡張部はプロセスワードの前に挿入しなければならないので、プロセスワードは中央のブロックの外に取り出されており、テンプレートの終わりに別個の要素として配置されている。このことによって、空の要素が得られる。これは、オブジェクトをシステムおよび正当な義務を表す用語の後に配置し、プロセスワードはオブジェクトの後に続くことを意味する。
ステップ５：システムの機能はしばしば、時間的条件または論理条件に対する主体であることが多い。ドイツ語では、条件を付加することによって、語順を再配置しなければならない。図１８の例は、条件 "If the vehicle is locked"（車両がロックされた場合）が付加された完全な要求パターンを示す。これによって語順が変化する。
ステップ６：最後に、作成された要求を検査する。最初に記述された分析アプローチの規則は未だ不完全な情報を含んでおり、この規則がこの検査のために使用される。
テンプレートを埋めるために実施されるステップにより、セマンティクスを有さない文構造が得られる。使用される各コンセプトは、要求のセマンティクスを形成するために割り当てられた意味を必要とする [Rup04]。コンセプトの意味は、自然言語文のセットの形態のコンセプト説明によって定義しなければならない。このようなセマンティック定義の目標は、同一の事実を表現する場合には異なる著作者が同一のコンセプトを選択し、関与する者すべてがこのコンセプトを同一に理解することである。
このようなセマンティクスは人によって理解することができるが、自動的に処理することはできない。その理由は、コンセプト説明は形式的ではないので、機械読み取り可能ではないからだ。その結果、前記のようにして定義された要求からテストを自動生成することはできない。
ＲＥ‐ＫＩＴ手法の開発の一部として、フラウンホーファー実験ソフトウェア工学研究所（Fraunhofer Institute Experimentelles Software Engineering, IESE）が [KBP01] において異なるアプローチを提供している。このアプローチの主な焦点は、多義的に表現された要求である。ソフトウェア開発プロセスでは、テキスト形式の要求を形式的なモデルにマッピングすることにより、開発者は、製造すべき製品を一義的に理解することができ、開発すべき機能をこのモデルから導出することができる。
これは非一貫性および不完全な表現を示すことがあるが、非形式的な要求で解釈が複数になる可能性はすべて、形式化プロセスにおける誤解に繋がる可能性がある。[KBP01] で紹介されている技術は、非形式的な要求がエラーを含む形式的な仕様化に繋がる前に、この要求を検査することに集中的に取り組む。すべての多義性を消去するためには、検査リストおよびシナリオベースの読み取りが使用される。このような手順はすでに知られていて産業界で受け入れられており、実用的にとりわけ適している。
このアプローチの目的は、形式的要求が非形式的要求から作成される前に、非形式的な要求において多義性および不完全な表現を検出することである。テストを生成するために使用することができる自然言語表現の形式化は行われない。
１つのコンセプトに、[SAC03] において紹介されているＰＲＯＰＥＬツールによって提供されるコンセプトがある。特性は自然言語要求から形式的に仕様化しなければならない。というのもテキスト形式の用語と対照的に、形式化された表現によって解釈の余地が少なくなり、誤解および非一貫性が大幅に回避されるからである。これを行うためには、正確な表現を形成するための機会を開発者に与え、それと同時に、要求の簡単かつ理解しやすい表現を示す。
ＰＲＯＰＥＬツールは、通常発生する特性パターンをテンプレートとして提供し、このテンプレートをユーザによって埋めなければならない。特性パターンの例に、要求で発生するイベントの数と、イベントが発生するべきか発生するべきでないかの定義がある。要求および要求に関連する質問を表現するためには、３つの表記法が使用できる。決定ツリーテンプレート、自然言語、および有限状態マシン。決定ツリーテンプレートは、要求の基本的構造を定義する特性パターンを選択するのを可能にする。ユーザに対して提供される第２の表記法は、自然言語のサブセットである。これと並行して、要求は有限状態マシンの形態で提示される。最後の２つの表現法は、要求を仕様化するための同一の機能をユーザに与える。これらは相互間で変換することができる。有限状態マシンを使用することにより、要求は形式的かつ正確に表現され、自然言語ビューは、ユーザが簡単に理解できるようにする。
ＰＲＯＰＥＬツールのコンセプトは、要求表現のためのターゲットグループである有限状態マシンの知識を有する開発者を対象とする。自然言語の形態で要求を表現する手法は、このツールにおいて独立するようには意図されていない。要求を自然言語で表現することにより、ユーザが理解できるビューがユーザに対して提供されるが、この有限状態マシンからだけでは、正確な意味論的解釈を得ることはできない。もっぱら自然言語のみを使用すると、誤解を生む可能性がある。たとえばこのアプローチのように有限状態マシンの形態の表記等、一義的な形式的表記法を使用することにより、コンピュータによって分析可能な要求を作成することができる。しかし、形式的な表記法を習熟している要求作成者は僅かしかいないので、要求の形式的記述は求められている解決手段ではない。
ＰＲＯＰＥＬツールは、正確な形式的要求を表現するのをサポートするが、このような要求からテストを導き出すためのコンセプトは提供しない。それゆえＰＲＯＰＥＬツールは、自然言語で表現された要求からテストを自動生成するのに十分ではない。
さらに、要求において時間的条件を仕様化することもできない。組み込みシステムの挙動の正確さは論理的な正確さにのみ依存するのではなく、機能が実行される時点も重要な役割を果たすので、組み込みシステムに対する要求では時間的観点も表現できるようにしなければならない。しかし、ＰＲＯＰＥＬツールで使用されるような有限状態マシンは、時間的条件の取り扱いをサポートしない。このためには、時間的条件によって拡張された有限状態マシンの形態を使用しなければならない。
[FMR00] に、自然言語から正確な形式的表現を作成する手法が示されている。使用される表記法は構造化された英語であるから、ユーザにとって理解しやすい。文を構築するためには、所与の状態を有するリストを選択のために使用することができ、また、自然言語のフラグメントのセットも使用することができる。要素および構文が文法的に定義された仕様化済みの文の基本的構造は非常に簡単である。このような文を時間論理ＣＣＴＬの形式的表現に翻訳することにより、文にセマンティックが割り当てられる。
文法によって構文を定義することは、新たな言語フラグメントを有する拡張によって幾つかの文法的部分が変化するという欠点を有する。したがって時間論理とのマッピングは、修正されたすべての部分で更新しなければならない。このことにより、拡張の実施が複雑になる。
[FMR00] に記載されたアプローチは自然言語表現の形式化に集中的に取り組んでいるので、モデル検査に使用することができる特性を形式的に記述するために自然言語表現を使用することができる。このアプローチは、形式化された表現に基づいてテストを自動生成するためのコンセプトを提供しない。
ツールに依存しない要求交換のフォーマットである要件相互交換フォーマット（ＲＩＦ）[WHH05] も述べておかねばならない。このために開発された幅広く異なるプログラムが要求管理の一部としてサポートすることによって要求を処理する企業の数は増加している。（「要求管理には、要求分析およびその後の要求の使用をサポートする規準も含まれる 。」[Rup04]）
要求管理も自動車産業において使用される。しかし、製造者とサプライヤとの間での協力およびタスクの分担の程度が強いことが、要求管理を企業の境界線で止めてはならないことを示している。製造者とサプライヤとの間で要求を交換するためには、要求のための共通のフォーマットが必要とされる。したがって自動車製造者およびサプライヤは、異なる企業間での要求管理のギャップを埋めるために、要求相互交換フォーマットを共同で定義した。ＲＩＦの仕様は、各企業ごとに、以前から使用されていて親しみのある要求管理プログラムの使用を続けて、この要求管理プログラムで作成された要求を共用のＲＩＦ要求交換フォーマットに移すことを可能にする。こうするためには、要求管理プログラムをインポート機能およびエクスポート機能によって拡張しなければならない。
ＲＩＦの詳細な調査により、もっぱらこのフォーマットのみを要求管理のために使用することは有利ではないことが明らかになっている。というのも、要求の内容は簡単なデータ形式（int, ストリング、．．．）、列挙法および複雑なデータ形式で表現され、この複雑なデータ形式はアプリケーション固有であるからだ。その結果、すべてのアプリケーションは複雑なデータを処理できるようになるためには、この複雑なデータが定義されているフォーマットを必要とする。ＲＩＦは言語の構文を形式化しないが、ドキュメント全体を別のフォーマットに変換する。セマンティックを各言語要素に割り当てることはできないので、テストを生成する元になる自然言語要求を形式化するためにＲＩＦを使用することはできない。ＲＩＦは、異なるフォーマットで形成された要求を相互交換するのを可能にすることを目標に開発された。このフォーマットは、テストの自動生成のために自然言語要求を形式化するためには設計されていない。
要求を一義的に記述する目的の他に別の重要なタスクとして、自動テスト生成プロセスですべての関連するテストケースを作成するタスクがある。テストケースを自動生成する異なるコンセプトが、[CTF01] および [Hu00] に見られる。
たとえば [Hu00] は、多値ロジックを使用してソフトウェアに対する要求を表現する手法を記載している。多値ロジックによって、変数は真または偽の値のみをとるだけでなく、任意の数の値をとることができる。たとえば、Ｘ１は車両の車内照明であり、３つの状態０，１および２を有することができると仮定すると、車内照明は、スイッチオフするか（０）、減光するか（１）、または完全出力で点灯（２）することができる。要求が、車内照明を減光すべきであることを記述するためのものである場合、このことは以下の式によって表される：
Ｙ＝Ｘ１（１）
要求から形成されるこのような多値表現から、多値デジタル回路に対してテスト生成を行うための既存のアルゴリズムを使用してテストケースを作成することができる。
[CTF01] に「統計的機能テスト」手法が記載されている。この手法では、テストケースを自動生成するために確率理論が使用される。ＵＭＬ状態チャートを使用して、テストを受けるシステムの動的挙動を表す。テストケースはこの状態チャートから導き出される。すべての状態遷移のカバー範囲を、テスト基準と見なすことができる。このコンセプトは、自然言語をベースとして使用しない。
これら２つのアプローチはテストケースの生成を扱うが、これは、テストがすでに存在することを前提とする。テストケースは、選択された入力データと、該選択された入力データによるシステムの実行後に期待される出力データとから成る。したがって、このテストケースは単に、テストを実行するためのパラメータでしかない。個別のテストステップを実行するテストインプリメンテーションはたとえば、値をテスト対象における変数に割り当て、値を読み出すことを含む。テストを異なるケースで実行できるようにするように、実行可能なテストを形成しなければならない。ここで紹介されたアプローチは、自動的なテスト生成のためのコンセプトを提供しない。
フラウンホーファーコンピュータアーキテクチャソフトウェア技術研究所（The Fraunhofer Institut Rechnerarchitektur und Softwaretechnik、ＦＩＲＳＴ）は [Fri04, FS05, FP05] において、使用例からテストケースを導出する手順を記載している。紹介されているアプローチは、使用例の記述から自動的なテストケースが生成されるように使用例の記述を扱うインタラクティブな手法に基づいている。テキスト形式の要求をユーザインタフェースにロードし、制御フロー要素によって結合したり拡張して、設計からの情報と結びつけることができる [FP05]。要求はこれによってインタラクティブに形式化される。
このアプローチにおいてテキスト形式の要求記述は、該要求記述から自動的なテストを生成するのに十分ではない。設計情報は手動で追加するか作成しなければならない。さらに、組み込みシステムに対する要件を表現するのに必要な時間的条件を扱うためのコンセプトは存在しない。上記のアプローチのように、このアプローチは実行可能なテストを生成するための手段を提供しない。これは単に、テストケースを作成するためのだけのものである。
このセクションでは、自然言語表現の形式化と、自動処理されるテキスト形式の要求の記述とに関するアプローチが紹介された。また、種々の形態で提供される情報からテストケースを自動生成するためのコンセプトも検証した。これらのアプローチの中で、自然言語の要求に基づいて自動的なテスト生成を行うことを可能にするアプローチは存在しない。
既存のアプローチは部分的に、理解しやすいように要求を作成するためのベースとして自然言語を使用して機能しないか、または、作成された要求は機械読み取り可能でないためにテストに自動的に処理できない。時間的条件を扱うためのコンセプトが欠けているアプローチもある。要求ベースのテスト生成を自動化し、それによってテストプロセスのコストを低減するために、本発明では次のような新たなコンセプト、すなわち、自然言語の要求の形式化を含んでおり、これらの要求からテストステップを生成してこれらのテストステップから実行可能なテストを作成する方法を提供するコンセプトを開示する。
第１のステップでは、要求は常に非形式的なテキストで記述される。このようなテキスト形式の要求からテストを自動的に導出するためには、このテキスト形式の要求を、一義的かつ機械によって解釈しなければならない。こうするためには、要求ドキュメントにおける各用語１つ１つの意味に関する情報が必要である。しかし、自然言語のすべての用語および用語のすべての組み合わせを理解できるシステムを作成するのは実用的に実現可能ではない。存在する単語すべてを含むのは不可能である。というのも、用語の数はあまりにも過度に多く、かつ、自然言語は新たな単語の形成を許容するからである。さらに、自然言語は多義性に起因する誤解の危険をはらんでいるので、一義的な表現を実現することはできない。したがって、コンピュータによって処理可能な一義的な構文および一義的なセマンティックを定義する必要がある。
本発明は、自然言語の表現の予め定義されたサブセットを開始点とし、このサブセットではセマンティックが各表現に割り当てられていることにより、自動的な処理を可能にする。要求を表現するために、語彙および固定的な文構造が存在する。全く可能である場合には、要件作成者は、所望された要求すべてを表現できるようにしなければならない。
図１は、コンセプト全体の概観を示す。本発明では、要求の一義的な構文を定義するメタモデルを開示する。このメタモデルによって、ユーザによって自然言語形式で提示される形式的要求を作成することができる。ユーザには、要件を作成するための語彙が与えられ、この語彙は、たとえば "If ... then", "and", "or" 等の基本的なテキストフラグメントを有する。要求メタモデルの特定の要素のインスタンスを表す別のテキストフラグメントも、ユーザによって定義することができる。
テストが形式的要求から生成される前に、ユーザには、テストシーケンスのテキスト形式の記述が与えられる。このステップでは、ユーザの要求から生成されたテストによって何がテストされるかがユーザに対して示される。テストシーケンスの記述はテスト仕様と称される。構文は別のメタモデルによって記述される。モデル変換によって形式的要求は形式的なテスト仕様書に変換され、これはユーザに対してテキスト形式で、ひいては理解しやすい形式で提示される。モデル変換は、マッピング規則の適用である。マッピング規則には、要求のどのテストフラグメントがテスト仕様書中の特定のテストフラグメントにマッピングされるかを定義するセマンティック情報が含まれる。形式的なテスト仕様から実行可能なテストプログラムを生成するためには、テストプラットフォームおよび該テストプラットフォームの固有の変数および値に関する情報が必要である。
直観的に理解できる用語でユーザが要求を記述し、テスト仕様のテストステップも理解できるようにするためには、テスト対象のインタフェースは変数名によって記述されず、ユーザ定義されたインタフェースオブジェクトによって記述される。ユーザは、テスト対象のインタフェースに割り当てられた値を、自己定義された状態の形態で定義することができる。図１９は、インタフェースオブジェクトと変数と値と状態との間の関係を示す。たとえばユーザは、インタフェースオブジェクトとして「リモートコントロールの「ロック解除」ボタン」を定義し、これを要求で使用することができる。このインタフェースオブジェクトは、テスト対象の変数 "button_remote_unlock" を記述する。この「リモートコントロールの「ロック解除」ボタン」を押さねばならないことを記述するためには、ユーザは状態として「押された状態」を定義し、これをインタフェースオブジェクトに割り当てることができる。「押された」状態は、値 "1" を記述する。このようにして、インタフェースオブジェクトを変数にマッピングし、状態を値にマッピングすることにより、値と、自然言語表現によって記述された変数との割り当てが可能になる。たとえば、「リモートコントロールの「ロック解除」ボタンが押される」というテキストは、 "button_remote_unlock = 1" の変数割り当てを表す。自然言語で定義されたインタフェースオブジェクトおよび状態はユーザにとって理解しやすく、かつ、変数および値を、要求作成の時点でユーザに既知でなくてもよい。
要求のメタモデルを以下で詳細に説明する。この後に、テスト仕様のメタモデルの説明が続く。その次に、モデル変換のコンセプトを紹介した後、テスト仕様と実行可能なテストプログラムとをマッピングするための基本的手順を説明する。
モデルはコンピュータサイエンスにおいて、複雑なシチュエーションを、対象となる目的に関連する基本的な要素にまで縮小するために使用される。これによって、包括的な情報の抽象的なビューが提供され、重要な観点が把握しやすくなる。メタモデルは、要素間に存在する関係に沿って、モデルで発生することができる要素および発生しなければならない要素を定義する。たとえば文を記述するためには、メタモデルは、主語および述語がすべての文に存在しなければならないことを定義し、目的語は存在することができることを定義する。メタモデル要素のインスタンスから成るモデルは、メタモデルのインスタンスである。
本発明の枠内で開発されたメタモデルは、自然言語のサブセットの構文を定義する。これは、要求を記述するために使用される語彙を記述する。要求のモデルは、この語彙から用語を選択して組み合わせることから得られる。これはメタモデルのインスタンスである。
文を作成するための語彙を使用することは、単語を選択して組み合わせ、文を形成することである。別の単語と組み合わせてのみ使用される単語もある。したがって複数の単語が、原始的なオブジェクトとしてモデリングされた固定的な表現にまとめられる。独立して使用できる単語は、単独の原始的なオブジェクトを構成する。このようなオブジェクトは、本発明の他の部分で、テキスト構文またはテキストセグメントとも称される。
要求メタモデルひいては語彙は、テスト生成に必要な情報に直接適合されている。ユーザが一貫しない不完全な要求を定義しないようにするため、メタモデルは固定的な要求構造を規定する。
要求メタモデルは、ＵＭＬクラスダイヤグラムを使用してモデリングされている。この表記法は、[Obj05] に記載されている。テキストセグメントはクラスによって表現される。クラス間の関連づけによってテキストセグメント間の関係が定義され、構文論的に正確な文が作成されるのが保証される。抽象クラスは具体的なテキストセグメントを表さないが、特定のテキストセグメント種類を定義する。具体的なテキストセグメントは、特性と関連づけとをこれらのテキストセグメント種類から引き継ぐ。抽象クラスはメタモデルを構造化するために使用される。テキストセグメントは共通の関連づけまたは特性にしたがってグループ化され、クラスとしてモデリングされる。このクラスはすべて、同一の抽象クラスから引き継がれる。たとえば、バイナリ演算子 "AND" および "OR" は単語の１つのグループを成す。これらは、１つの要求において同じ場所で発生し、同一のクラスとの関連性を有する。
共同で要件記述の構文を定義するメタモデルの個別の要素を以下で定義する。図２０に、基本的な要素を有するメタモデルからの抜粋が示されている。
上記では、ソフトウェアの要件は大抵、「前提条件が生じた場合には、期待される応答が行われなければならない」という形のステートメントによって表現されることを説明した。"If ... then" 等の表現が、要件の構造全体を決定する。このような基本的な表現を指定するための抽象的な要素である "BaseExpression" が存在する。これは図２０に示されている。これは、要求の構造を表す。"BaseExpression" の具体的なインスタンスは "Iff" 要素によって提供される。これは、 "If and only if ... then"（・・・の場合に限り、・・・）というテキスト表現を意味する。"Implies"（暗黙的定義）要素は、"If ... then" 構文を作成するのに使用できる別のインスタンスである。これら２つの要素は、テストでは異なる意味を有する。"If ... then" は、前提条件が発生した場合に、期待される応答が発生しなければならないことを意味し、そうでなければテストは失敗に終わる。"If and only if ... then" 表現を使用することにより、２つのケースをテストできる。前提条件が発生した場合、期待される応答は発生しなければならず、前提条件が発生しない場合には、期待される応答は発生してはならない。これら２つの規則のうちいずれかに違反すると、テストは失敗に終わる。
"BaseExpression" には、"BaseExpressionElement" 種類の２つの要素が含まれ、それらのうち第１の要素は前提条件を表し、第２の要素は期待される応答を表す。最も簡略的なケースでは、BaseExpressionElement は "InterfaceElement" である。これは、テストを受けるシステムの入力および出力を表すインタフェースオブジェクトを表す。状態をインタフェースオブジェクトに割り当てることにより、値をシステムの変数に割り当てられるようにしなければならない。図１９は、インタフェースオブジェクトの変数と値と状態との間の関係を示す。たとえばリモートコントロールの「ロック解除」キーは、状態が押されている状態かまたは押されていない状態になることができるインタフェースオブジェクトを記述する。
"ValueElement" 要素は、このような状態をモデリングする。要求記述が作成される時点では、状態によって記述される正確な値が全く未知であってもよいが、この値を特定の範囲によって制限しなければならない場合がある。こうするためには、抽象的要素である "ValueCondition" を使用することができる。これは、４つの異なる要素を具体的なインスタンスとして有する。第１に、 値の上限を定義する "AtMostforValue" 要素がある。また、下限を仕様化するために "AtLeastforValue" 要素を使用することができる。"Within" 要素によって間隔を定義することができ、"ExactlyValue" 要素によって具体的な値が正確に仕様化される。
図２１に、メタモデルの具体的なインスタンスと、ここで挙げられた要素を使用して作成することができる要求とが示されている。線は要素間の関連づけを表す。点線の矢印は、ユーザからの観察がどのように見えるかの例のように、それぞれメタモデルインスタンスの要素とテキストとを結びつけている。ユーザ読み取り可能なビューをメタモデルインスタンスから形成するためには、自然言語表現とのマッピングが必要である。このマッピングプロセスは、後で説明する。
上記のように定義された要素では、要求を受動態で表現することができる。システムの動作は入力に依存するのであり、入力を行う人間には依存しない。したがって、入力元である人間またはシステムを記述するテキスト構文は必要ない。
図２１の例で示されているように、インタフェースオブジェクトおよび状態は常に、単語 "is" によって相互に割り当てられる。カスタマは、"then the vehicle is unlocked"（車両はロック解除される）という文を、"then the vehicle must be unlocked"（車両をロック解除しなければならない）という形で表現したり、"must"（しなければならない）を使用する代わりに、"may"（してもよい）または "should"（すべきである）または "will"（するであろう）という用語を使用したいと思う可能性もある。しかし、テストによって有効性検査しなければならない機能は、特定の結果を戻さなければならない機能のみである。特定の結果を引き起こす機能を検査するためのテストの開発と、期待された結果に結果が一致しない場合は問題ない所に、エネルギーを投資するのは意味がない。
"If...then", "at most", "at least" 等のテキスト構文は一般的な語彙の一部であるのに対し、インタフェースオブジェクトを記述するためのテキスト構文（InterfaceElement）および状態を記述するためのテキスト構文（ValueElement）はシステムに依存する。したがってユーザは、インタフェースオブジェクトおよび状態自体に対してテキスト構文を定義し、語彙を拡張できなければならない。
ユーザに対して表現の種々の手段を提供するためには、InterfaceElement に対してシノニムを割り当てることができるようにしなければならない。たとえば、要求において "unlock all doors"（すべてのドアをロック解除する）という表現と "unlock the vehicle"（車両をロック解除する）という表現とは、同一の基礎となる事実を記述することができる。任意の数のシノニムを各 InterfaceElement に割り当て、InterfaceElement 要素の属性としてモデリングすることができる。シノニムはまた、ValueElement 要素の形態である状態に対して定義することもできる。
上記で挙げられた要素によって記述できない要求は数多く存在し、複数の入力に対して所定の値を与えることができ、複数の出力がこれに対して応答することができる。こうするためには、ＡＮＤ演算子を必要とする。前提条件および期待される応答は、ＯＲ結合された命令から構成することもできる。また、上記で挙げられたメタモデルの抜粋では、ステートメントの否定形を記述することができない。このことは、メタモデルで演算子が必要であることを示す。図２３に、前提条件に単純なＡＮＤ結合を有する要求が示されている。
これは、２つの InterfaceElement 要素がＡＮＤ演算子に割り当てられることを意味する。したがってこのメタモデルは、演算子が BaseExpression と InterfaceElement との間に配置されることを必要とする。さらに、演算子なしで要求を表現できなければならない。それゆえ、BaseExpression の後に演算子が続くことができるが、図２４に示されているように InterfaceElement が直接続くこともできる。
要求において２つ以上の要素を結合することができ、かつ、ＡＮＤ演算子およびＯＲ演算子も組み合わせられるようにするためには、演算子をネスト化する手法が必要とされる（図２５）。合計すると、演算子によってメタモデルを拡張するための基準は３つに区別することができる。
1. 演算子は要求に、 InterfaceElement の前に挿入しなければならない。というのも、InterfaceElement 種類の要素は演算子に対して子供のように割り当てなければならないからである。
2. さらに、演算子なしで要求を表現できるようにもしなければならない。
3. 演算子のネスト化によって複数の観点の結合をインプリメンテーションできなければならない。
このことによって、複合的な設計パターンによる演算子のモデリングが実現される [GHJV04]。図２６に、要求メタモデルの拡張された一部が示されている。"BinaryOperator" と称される抽象的要素が存在しており、これは、BaseExpressionElement 要素から引き継ぐ。したがって、これは BaseExpression の子供とすることができる。たとえばＡＮＤ要素、ＯＲ要素およびＸＯＲ要素等の具体的な要素は、この要素から引き継ぐ。BinaryOperator は、結合しなければならない子供を２つ有する。子供は BaseExpressionElement 種類であるから、InterfaceElement 種類の具体的要素および別の演算子は子供として可能である。したがって BinaryOperator は、子供として BaseExpressionElement 種類の要素を２つ有し、BinaryOperator 自体は BaseExpressionElement である。"Unary−Operator" もこれと同様にモデリングすることができる。これは１つの子供のみを有し、たとえば、ステートメントを否定するためのＮＯＴ演算子で使用される。
このような演算子モデリングは、たとえば図２３，２４および２５に示されたようなインスタンスを作成するのに使用することができる。その結果は、結合が演算子ネスト化によって一義的にされたツリー構造となる。自然言語では、複数の演算子を１つの文で使用することにより、多義性が生じることがある。「The ignition is on and the interior lighting of the vehicle is on or the interior lighting is out.（イグニッションがオンされ、かつ車内照明がオンされるか、または車内照明がオフされる）」という要求は２つの意味を有する。これは、文の異なる部分を大括弧に入れることによって明瞭化される："(The ignition is on and the interior lighting of the vehicle is on) or the interior lighting is out."（「（イグニッションがオンされ、かつ車内照明がオンされるか）または車内照明がオフされる」）、または、"The ignition is on and (the interior lighting of the vehicle is on or the interior lighting is out.)"（「イグニッションがオンされ、かつ（車内照明がオンされるか、または車内照明がオフされる）」）このような構造はツリー構造によって定義される。演算子を有する要求をユーザに対して一義的に提示するためには、文の一部を括弧でくくるかまたは強調する等の手段を使用することができる。このようにすれば、複数の演算子を使用することによって多義性が生じることはない。
しかし、上記のように定義された要素を使用することによって要求が含むことができる情報は、組み込みシステムのソフトウェアを開発するのに十分ではない。入力と出力との割り当てを表現することはできるが、これらのインタフェースのうち１つに値をいつ適用してどれくらいの時間にわたって適用すべきかの質問は、未回答のままである。しばしば、期待されるが伝達されない詳細が存在する。不完全に仕様化された要求によって、機能が所望の要求を満たさないシステムが形成されてしまう。
例：
「リモートコントロールの「ロック解除」ボタンが押された場合、車両はロック解除される。」ボタンはいつ作動されるか？車両をロック解除するためには、どれくらいの時間にわたってボタンを押さねばならないか？ロック解除はどれくらいの時間にわたって継続されるか？
この問題によって、メタモデルに対して時間的条件を仕様化するための要素を追加する必要が生じる。インタフェース割り当ての時点をモデリングするために、"PointOfTime" と称される要素が存在する。これは、InterfaceElement に割り当てられる。その理由は、各 InterfaceElement は ValueCondition と割り当て関係を有し、これは "ValueElement" に結びつけられているからである。インタフェースの変数は、これによる特定の値割り当てによって表現される。時間的条件が、定義される要求に重要である場合、この割り当て状態では時点および期間が定義されることが必要とされる。したがって InterfaceElement は、期間を定義するための "LengthOfTime" 要素との割り当て関係も有する。
PointOfTime 要素および LengthOfTime 要素はオプション要素としてモデリングされる。というのも、時間的条件を定義する意味がない要件も存在することがあるからだ。さらに、時間仕様を正確に与えなくてもよいが上限または下限に関して記載しなければならないシナリオも幾つか存在する。
例：
「リモートコントロールの「ロック解除」ボタンが少なくとも０秒の後に４秒にわたって押された場合、車両は最大６秒後に、少なくとも２４０秒にわたってロック解除される。」
このことは、異なる時点要素および期間要素が必要であることを示している。これらの要素は、図２７のメタモデルに示されている。時点を記述するためには４つの異なる要素がモデリングされ、これは PointOfTime から引き継ぐ。
ExactlyTime（正確な時点）
NotLaterThan（〜より遅い時点ではない）
Soonest（最も早くても）
BetweenTime（時点間で）
"ExactlyTime" 要素は、正確な時間仕様を作動することにより、ケースを処理するための要素である。上限を記述するためには "NotLaterThan" 要素が存在する。これは、インタフェースの変数を、定義された時点より遅い時点でない時点で、指定された値に割り当てるための要素である。"Soonest" 要素は、時間仕様より早い時点で変数に値を与えてはならないことを定義する。上限および下限を定義するためには、"BetweenTime" 要素が使用される。これらの要素はすべて、時間条件が関係する具体的な時間値を含む "Time" 要素との割り当て関係を有している。図２８に、要素と要求のテキストとの関係が示されている。
それと同等のものとして、期間仕様を記述するために４つの要素が存在し、これは LengthOfTime（時間の長さ）要素から引き継ぐ。
ExactlyDuration（正確な期間）
AtMost（最大で）
AtLeast（最小で）
BetweenDuration（期間の間に）
期間を正確な長さで定義するために、"ExactlyDuration" 要素が設けられている。時間的期間仕様の上限および下限は、"AtMost" および "AtLeast" によって定義される。"BetweenDuration" 要素は、期間が位置すべきインターバルを定義するための要素である。ここに挙げられた要素は、時間的期間仕様を含む "Duration" 要素（期間要素）を有する。
時間的条件を記述するためのすべての要素のセマンティックを形式的に定義する形式的定義は、時間論理ＲＴＣＴＬとのマッピングの形をとる。時間仕様を使用することから得られる観点を、ここに記載する。
１．期待される応答の基準時点
２．条件間での時間依存性
３．期待される応答での Soonest 要素
前提条件におけるすべての時点仕様は共通のゼロ点に基づくので、並列的なプロセスを記述することもできる。条件の順序は、異なる時点仕様および時間的期間仕様を含むことによって仕様化することができる。前提条件が満たされると、応答がその後に発生することが期待される。したがって、すべての前提条件が満たされる最も早い時点を、期待される応答で定義された時間仕様のゼロ点と見なすことができる。状態がインタフェースオブジェクトに割り当てられ、かつ状態が、仕様化された期間にわたって維持される場合に、前提条件は満たされるかまたは完了される。図２９では、すべての前提条件が完了した後に１時間単位が経過してから、期待される応答が行われる。このシーケンスは次のような要求で、すなわち、期待される応答が正確に１時間単位後の時点仕様を有し、かつ、期待される応答に対する基準時点が要求観察のゼロ点ではないが、すべての前提条件の完了である要求で仕様化することができる。
しかしこのような仮定は、具体的な信号挙動の入力が別の信号挙動の出力を必要とし、かつ、これら２つの信号は時間的に連続して発生しないケースをカバーしない。図３０にこのようなケースが示されている。このケースを扱うためには、要求メタモデルを次のような別の要素によって、すなわち、期待される応答の要求部分における時間仕様も前提条件と同じゼロ点に基づくことを定義する別の要素によって拡張することができる。
ここで、時間仕様の基準点を以下のようにまとめる。
・前提条件では、時点はすべて要求全体のゼロ点に基づく。
・期待される応答の規則は、すべての前提条件が満たされる最も早い時点がすべての時点の基準点である。
・メタモデルの拡張部として、期待される応答の時点を要求全体のゼロ点に関連づけするための要素を追加することができる。
しかしこの基準点の定義は、前提条件内の条件が相互に依存するケースを表現することができない。NotLaterThan, Soonest, AtLeast 等の要素は正確な時点を仕様化しないので、条件の終了を予め決定することはできない。条件Ｂが条件Ａの完了時に真でなければならない場合、条件Ｂの単純な時間仕様化によってこのことを実施することはできない。というのも、条件Ａの終了は、正確に定義された時間仕様によって正確に決定することができないからである。また、期待される応答の条件間における依存性を記述することもできない。このことを実施するためには、以下で紹介される新たな要素が必要である。
例：
「車両がロックされている場合、リモートコントロールの「ロック解除」ボタンが押されてから３秒後に、該車両は少なくとも２４０秒にわたってロック解除される。」
この例では車両のロック解除は、リモートコントロールのボタンが押されるという条件に時間依存する。このような要求を構築するためには、"RelativeTime"（相対的時点）と称される新たな要素をメタモデルに挿入しなければならない。これは PointOfTime 要素の具体的なインスタンスである。というのもこれは、条件が発生しなければならない時点を定義するからである。
図３１に要求が、メタモデルの関連づけされたインスタンスと組み合わされたテキストとして示されている。RelativeTime 要素は Time 要素を子供として有し、また、依存性の基準になる BaseExpressionElement と称される子供も有する。相対的な依存関係をモデリングすることにより、状態とインタフェースオブジェクトとの時間的に連続する割り当て関係を、条件と期待される応答とで表現することができる。これによって応答挙動が得られる。応答挙動は、特定のイベントまで待機するプロセスを記述し後でどのアクティビティが行われるかを記述する。この例ではプロセスは、リモートコントロールの「ロック解除」ボタンが押されるまで待機する。それから３秒後に車両はロック解除される。
まとめると以下のようになる：
・RelativeTime 要素によって、応答挙動を記述することができる。絶対的な時点が既知でなくても依存関係を定義することができる。というのも、イベントが発生するまで待機するからである。
・絶対的な時間仕様が未知であっても、前提条件と期待される応答とで、イベントを時間的に連続して記述することができる。
考慮すべき第３の観点は、期待される応答における Soonest 要素の有無である。
例：
「車両は開いているが始動されず、４秒経過後に再び閉鎖もされなかった後は、部外者が車両に立ち入ることができないように、中央ロックシステムはドアを自動的にロックしなければならない。ロック解除は不注意であった可能性がある。または、車両のロックが忘れられた。しかし、車両を直ちに再ロックしてはならない。というのも、人が乗車したり降車したりするための時間が必要であるからだ。自動ロックは、４秒経過終了時点より早期に行ってはならない。この機能をテストするためには、車両は０〜４秒にわたってロック解除状態に維持されることを検査しなければならない。さらに、車両は４秒経過後のいずれかの時点でロックされるか否かも検査しなければならない。
このことによって、以下の質問が生じる：この状態が発生するまでシステムが待機しなければならない時間はどれくらいか？不定の期間にわたってテストすることはできない。図３２に、０〜７秒の期間での車両のロック状態を示す。いつテストを終了できるか？５，６，１０，６０秒後か？テストを時点５で終了した場合、テストが失敗したか否か、または、テストを続行した場合に車両のロックが実行完了するか否かを判定することはできない。
テストに時間枠を与えるためには、ユーザは要件生成時にタイムアウトを定義しなければならない。
このセクションおよび上記のセクションで、要件メタモデルの要素を定義した。これの要素には、インタフェースオブジェクト、状態、演算子および時間的条件の記述が含まれている。インタフェースオブジェクトおよび状態は、テスト対象に固有の要素である。各テスト対象は、特定の値をとることができるインタフェースの特別な変数を有する。このような変数および値は、使用されるテストプラットフォームに依存するが、まず最初にテストの一般的な記述を形成しなければならず、要求はこのプラットフォームに依存せずに記述される。次のセクションで、プラットフォーム非依存性を説明する。
ソフトウェアのテストを効率的にするためには、テストが再利用可能であることが望まれる。開発が完了した後に限らず、テストはソフトウェア開発の異なる段階で最適に実行される。上記のように現在は、設計段階で実行可能なモデルが存在する。たとえば、シミュレーション環境で実行できるブロック図または状態マシンが存在する（たとえばＭＡＴＬＡＢ（登録商標）／Ｓｉｍｕｌｉｎｋ（登録商標））。これによって、テストをモデル段階と同じ早期の段階で実施することができる。さらに、モデルから開発されたプログラムコードをテストし、その後、組み込みシステムの場合にはハードウェア環境で動作するプロトタイプもテストしなければならない。テスト対象をテストするためには、該テスト対象が実行されるテストプラットフォームが必要である。図１２に、テストプラットフォームに接続されたテスト対象が示されている。モデル、プラグラムコード、および組み込みシステムのプロトタイプが異なるプラットフォームで実行されることは、すでに示した。たとえば、モデルはシミュレーション環境で実行されるのに対し、完了されたプロトタイプはハードウェア環境内にある。各プラットフォームは、入力および出力をアドレシングするための固有の変数を有し、これらのインタフェースに対して固有の値領域を有する。
必要とされるプラットフォームが何であるかにかかわらず、テストをどの開発段階でも適用できるようにするためには、テストをプラットフォーム非依存性の形態で記述しなければならない。プラットフォーム非依存性のテスト記述は、実際のテストプラットフォームが理解する変数にマッピングすべきインタフェースの指定子を使用する。図３３に、ＥＣＵの開発中に発生するテスト対象が表されている。これらのテスト対象はそれぞれ、モデルであるかプログラムコードであるか組み込みシステムのプロトタイプであるかにかかわらず、値を適用するための入力側を有する。車両をロック解除するためのリモートコントロールのボタンが押されると、１つの入力側がこの情報を受け取る。マッピングされる入力は、同じ情報を異なる表現で表現する。モデルでは、入力は信号によってモデリングされる。プログラムコードがこのモデルから作成される場合、この入力はパラメータによる関数呼び出しによって表される。ＥＣＵにおけるこの入力は、電圧がピンに印加されることによって具現化される。テスト対象におけるインタフェースのこのような異なる表現は、テストプラットフォームからエンキャプシュレーションされる。しかし、テストプラットフォームのインプリメンテーションが異なれば、テストプラットフォームがテストツールに対するインタフェースをインプリメントする手法は異なる。１つのテストツールにおいて１つの入力によって表される情報は、別のテストツールでは複数の入力によってモデリングされることがある。したがって、このような入力を要求においてプラットフォームに非依存的に記述し、実際の入力の指定子とのマッピングを行うことにより、再利用性を実現しなければならない。
プラットフォーム非依存性のテスト記述言語は現在、共同で１つのプロジェクトに関与する異なる部署間および異なる企業間でテストを交換するのに使用されることが多い。その例に、ＴｅｘｔＭＬ [GCF+06]、ＴＴＣＮ‐３[Gra00]、ＡＴＭＬおよびＵＭＬテストプロファイルがある。
しかし実際には、プラットフォーム非依存性のテスト記述のコンセプトの具現化で問題が生じる。異なる開発段階にわたってテストの再利用性を保証するためには、テストで使用されるインタフェースのみが、すべてのテスト対象（モデル、コードおよびプロトタイプ）においてアクセス可能なインタフェースであることを保証しなければならない。テストが、モデルレベルで相互に依存せずに３つの連続的な機能をテストするために開発されている場合、プロトタイプにおいて外部からアクセス可能な機能は１つだけであるという事態が発生する可能性がある。図３４に、組み込みシステムのソフトウェアにおけるこのような３つの機能が示されている。機能Ａは外部から呼び出せるが、機能ＢおよびＣはそれぞれ上流の機能によって起動され、インタフェースを介してアクセスすることはできない。このような連続的な機能のテストは、再利用性を有していない。したがって、開発されるソフトウェアのインタフェースのアクセス性をまず十分に考慮して、このような側面をテスト基準に組み込めるようにしなければならない。
プラットフォーム非依存性のテストの自動生成に使用できる要求を記述するためのメタモデルでは、メタモデルの要素自体をプラットフォーム非依存性にしなければならない。このことは、テストをすべてのプラットフォームに対して作成できるという利点を有する。要求モデルでは、インタフェースオブジェクトはテスト対象におけるインタフェースの変数を表す。各インタフェースオブジェクトは一義的であるから、各インタフェースオブジェクトをテスト対象の相応の変数にマッピングすることができる。このマッピングプロセスのために、プラットフォーム固有の情報、たとえば入力、出力、および値領域等の情報を供給しなければならない。
図３５に、プラットフォーム非依存性のテスト仕様書に変換されたプラットフォーム非依存性の要求記述が示されている。テスト仕様書は、上記のようにテストの個別のステップを記述する。以下で、このようなテスト仕様書を詳細に説明する。具体的なテストインプリメンテーションは、各テスト対象ごとにテスト仕様書から生成される。このステップでは、プラットフォーム非依存性のインタフェースオブジェクトおよびその状態を、テスト対象のプラットフォーム固有の変数と該変数の値とにマッピングする。こうするためには、プラットフォーム情報が使用可能である必要がある。要求に記述されたインタフェースオブジェクトが実際に複数の入力または出力によってインプリメンテーションされる場合には、このインタフェースオブジェクトを複数の固有の変数にマッピングすることができる。本発明で挙げられた多くの例では、「車両はロック解除される」という文は、車両のすべてのドアがロック解除されることを表現するために使用された。プラットフォームが各ドアごとに変数を有する場合、インタフェースオブジェクトである「車両」はすべてのドアの変数にマッピングしなければならない。図３６にこのことが示されている。プラットフォーム固有の変数は、値領域を暗黙的に定義する特定の値をとることができる。
メタモデルは、ユーザが要求を表現するために使用できる自然言語のサブセットを使用する。言語的手段には制限があるので、表現できない要求が常に出てくる。したがって、このメタモデルは拡張可能に構成されている。仮想的にすべてのシチュエーションを表現できるメタモデルの要素のセットを見つける研究は本発明の枠組みを越えるものであり、将来の課題にしておく。メタモデルで使用可能な要素は、ここで紹介されたコンセプトに基づいて構築された要求例と、実際の例とに基づいて選択された。メタモデルをその後の命題で拡張できるようにするためには、拡張性が重要な特性になる。
ＵＭＬを使用してメタモデルをモデリングすることは、新規の要素を付加的なクラスとして容易に追加できることを意味する。また新規の要素は、既存のクラスの特化子として定義することができるので、このようなクラスの特性を引き継ぐことができる。新規のバイナリ演算子を、抽象的な BinaryOperator の別のインプリメンテーションとすることができる。ＵＭＬメタモデルを拡張する際には、割り当てによって拡張される要素のみが、新規の要素と直接的な関係を有する要素となる。他の要素はすべて、拡張によって影響されない。このことは、メタモデルの拡張が非常にシンプルであることを示している。
ユーザは、左側から開始して単語を繋げることによって要求を表現できるようにしなければならないので、プロセスおよび単語の配置は、通常の文構築に相応する。ユーザにとって表現を可能な限り容易にするためには、直観的に読み取れることが要求の非常に重要な特性になる。ここでは、メタモデル要素と文フラグメントとの誘導的に定義されたマッピングが行われる。Iff（前提条件、expectedReaction（期待された応答））表記は、前提条件と expectedReaction との割り当て関係によって到達されるメタモデルの Iff 要素のインスタンスが次の文フラグメントにマッピングされることを意味する。割り当てによって到達された要素は文フラグメントにマッピングされることにより、最終的には完全に自然言語の文が得られる。
BaseExpression（基本表現）
− Iff(precondition（前提条件）, expectedReaction（期待される応答）) →
"If and only if ＜precondition＞, then ＜expectedReacton＞."（＜前提条件＞が発生した場合に限り、＜期待される応答＞が生じる）
− Implies (precondition（前提条件）, expectedReaction（期待される応答）) →
"If ＜precondition＞, then ＜expectedReaction＞."（＜前提条件＞が発生した場合、＜期待される応答＞が生じる）
BinaryOperator（バイナリ演算子）
− XOR(childOne, childTwo) → "either ＜childOne＞ or ＜childTwo＞"（＜子供１＞か＜子供２＞のいずれか）
− OR(childOne, childTwo) → "＜childOne＞ or ＜childTwo＞"（＜子供１＞か＜子供２＞のいずれか）
− AND(childOne, childTwo) → "＜childOne＞ and ＜childTwo＞（＜子供１＞かつ＜子供２＞"
UnaryOperator（単独演算子）
− NOT(baseExpressionElement) → "not ＜baseExpressionElement＞"（＜基本表現要素＞ではない）
PointOfTime（時点）
− ExactTime(time) → "after exact ＜time.valueString＞ time units"（ちょうど＜時間値ストリング＞時間単位の後に）
− Soonest(time) → "after not less than ＜time.valueString＞ time units（＜時間値ストリング＞より小さくない時間単位後に）
− NotLaterThan(time) → "after no more than ＜time.valueString＞ time units"（＜時間値ストリング＞より大きくない時間単位後に）
− BetweenTime(lowerTime, upperTime) → "after between ＜lowerTime.valueString＞and ＜upperTime.valueString＞ time units"（＜小さい時間値ストリング＞と＜大きい時間値ストリング＞との間の時間単位後に）
LengthOfTime（時間の長さ）
− ExactDuration(duration) → "for exact ＜duration.valueString＞ time units"（ちょうど＜期間値ストリング＞時間単位にわたって＞
− AtLeast(duration) → "for at least ＜duration.valueString＞ time units"（少なくとも＜期間値ストリング＞時間単位にわたって）
− AtMost(duration) → "for at most ＜duration.valueString＞ time units"（多くとも＜期間値ストリング＞時間単位にわたって）
− BetweenDuration(lowerDuration, upperDuration) → "for between ＜lowerDuration.valueString＞ and ＜upperDuration.valueString＞ time units"（＜小さい期間値ストリング＞と＜大きい期間値ストリング＞との間の時間単位にわたって）
ValueCondition（値条件）
− ExactlyValue(interfaceElement, valueElement) → "＜interfaceElement.name＞ is ＜valueElement.name＞"（＜インタフェース要素名＞は＜値要素名＞である）
− AtMostforValue(interfaceElement, valueElement) → "＜interfaceElement.name＞ is at most ＜valueElement.name＞"（＜インタフェース要素名＞は多くとも＜値要素名＞である）
− AtLeastforValue(interfaceElement, valueElement) → "＜interfaceElement.name＞ is at least ＜valueElement.name＞"（＜インタフェース要素名＞は少なくとも＜値要素名＞である）
− WithinValue(interfaceElement, lowerValue, upperValue) → "＜interfaceElement.name＞ is between ＜lowerValue.name＞ and ＜upperValue.name＞"（＜インタフェース要素名＞は＜小さい値名＞と＜大きい値名＞との間である）
・InterfaceElement → "＜InterfaceElement.Name＞"（インタフェース要素名） 抽象的な時間単位である "time units" は、ユーザが選択した時間単位に置換される。
要求を自然言語によって表現することは、ステートメントを一義的に理解できることを保証しない。というのも、複数の意味を有する個別の単語が数多く存在するからである。多義的な単語が組み合わされると、多義性が倍増され、理解するのが非常に困難になってしまう。正確なステートメントを形成してセマンティクスを定義するために、数学およびコンピュータサイエンスはロジックを使用する。これらは形式的な言語である。一般的なロジックには、命題論理および述語論理があり、これによって静的なステートメントを表現することができる。しかし、組み込みシステムはタイムクリティカルな機能を有し、たとえば事故後の車両のロック解除等の機能を有する。時間的観点は、このようなロジックでは表現できない。時間的な言及を伴う論理的ステートメントを記述するために、時間論理が存在する。これはたとえば、モデル検査と称されるエラーの有無の証明手順で使用される。最もよく使用されるのは、計算木論理（ＣＴＬ）[CES86] および線形時間論理である [Pnu77]。しかし、これらは時間的観点を定性的に表現できるだけである。たとえばイベント発生までの時間単位の数等の定量的なステートメントを形成することはできない。しかし、この種類の条件が、組み込みシステムで定義すべき条件である。
このような条件の一例に、エアバッグが応答しなければならない事故後の時間単位の数がある。定量的な時間的ステートメントも形成できるようにするために、付加的な時間論理が開発されている。
[EMSS91] に記載されたリアルタイム計算木論理（ＲＴＣＴＬ）がその１つである。これはＣＴＬ論理から発展したものであり、定量的な構文によって拡張されている。 ＲＴＣＴＬは原子的なステートメントのアルファベットΣによって、次の文によって定義される：
1. 各原子的ステートメントＰ∈ΣはＲＴＣＴＬ式である。
2. ｐおよびｑがＲＴＣＴＬ式である場合、
Figure 2008171391
3. pおよびｑがＲＴＣＴＬ式である場合、Ａ（ｐ∪ｑ）、Ｅ（ｑ∪ｐ）およびＥＸ ｐもまたＲＴＣＴＬ式である。
4. pおよびｑがＲＴＣＴＬ式であり、かつｋ∈Ｎである場合、Ａ（ｐＵ≦ｋｑ）およびＥ（ｐＵ≦ｋｑ）もまたＲＴＣＴＬ式である。
最初の２つの文のセマンティクスは、命題論理から得られる。Ａ（ｐＵｑ），Ｅ（ｐＵｑ）およびＥＸ ｐの定義は、ＣＴＬおよび状態に拠り、以下のようになる。上記のように、組み込みシステムは離散的な時間的挙動で動作する。したがって、組み込みシステムは常に、離散的な特定の状態にある。このことによって組み込みシステムを、遷移の実行時間が１時間単位に相応する状態マシンとしてモデリングすることができる。入力値に依存して、各状態ごとに複数の後継者状態が存在することがあるので、状態遷移の可能な結果すべてを表すツリーが得られる。連続的に発生する状態は、ツリーのパスによって定義される。式ｐＵｑは、ｑが最初に発生するまでＲＴＣＴＬ式ｐが適用されることを意味する。ＡおよびＥは周知の"all"（すべて）および "existential quantors"（存在量化子）であり、これは、これらの後に続く式をツリーのすべてのパスまたは少なくとも１つのパスに適用しなければならないことを定義する。ＣＴＬの定義によれば、ＥＸ ｐは、ｐが後継者状態のうち少なくとも１つにおいて真であることを示す。
４番目の文はＲＴＣＴＬで定義されている。
これらは、式Ａ（ｐＵｑ）およびＥ（ｐＵｑ）を時間的構成要素 ≦ｋによって拡張し、Ａ（ｐＵ≦ｋｑ）およびＥ（ｐＵ≦ｋｑ）を形成する。これらの式は、ｋ個の状態遷移でｑがｐに取って代わることを意味する。したがって、ｑは遅くてもｋ個の遷移後に適用され、その前にｐはすべての状態で適用される。このような表現は、ｋ個の遷移後またはそれより早期に発生した挙動に関するステートメントを形成するために使用することができる。しかし要求メタモデルは、たとえば「ｋの後またはそれより遅い時点」遷移または「ａとｂとの間」遷移を表現するための時間的条件も有する。上記の定義は、このためには十分でない。要件メタモデル中の時間的条件すべてを表現できるようにするためには、定義を演算子Ａ（ｐＵ〜ｋｑ）およびＥ（ｐＵ〜ｋｑ）によって拡張しなければならない。ここでは、〜∈｛＜，≦，＝，≠，＞，≧｝であり、Ａ（ｐＵ［ａ，ｂ］ｑ）およびＥ（ｐＵ［ａ，ｂ］ｑ）であり、ａ，ｂ∈Ｎ，ａ≦ｂである。このことは、[EMSS91] に拠る。制約ｋ∈Ｎは、時間がＲＴＣＴＬにおいて離散的であると見なされることを示す。言及すべき別の定量的な時間論理に、ＴＣＴＬ [ACD93] がある。これは、ステートメントを時間オートマトンによって形成するために使用することができる。時間オートマトンは、時間的観点を考慮するためにクロックによって拡張された有限オートマトンである。ＲＴＣＴＬとは対照的に、ＴＣＴＬは連続的な時間コンセプトを有する。これによって、時間論理に高いフレキシビリティが与えられる。しかし、連続時間コンセプトを使用することにより、充足可能性を決定することができなくなるので [ACD93]、矛盾した要求を検出することができなくなる。しかし、表現された要求においてユーザが矛盾を検出するためには、非常に有用である。本発明の１つの先見的な継続は、充足可能性が決定可能でなければならない要求の分析になるかもしれない。
上記のように組み込みソフトウェアは、該組み込みソフトウェアが実行される固定的な時間的サイクルを有する。したがって、離散的な時間コンセプトによる時間論理を使用することは制限にならない。そのためＲＴＣＴＬは、要求構文のマッピング先である時間論理として選択される。ＲＴＣＴＬでは、[EMSS91] で証明されたように、充足可能性が決定可能である。
ＲＴＣＴＬ表現に対するマッピングは誘導的に実施される。Iff（前提条件、expectedReaction（期待された応答））表記は、前提条件と expectedReaction との割り当て関係によって到達されるメタモデルの Iff 要素のインスタンスが、以下のセマンティックに割り当てられることを意味する。このような割り当てによって到達する要素も、セマンティック定義を有する。たとえば、前提条件と expectedReaction との割り当てを使用して、BaseExpressionElement 種類の要素に到達する。この要素の具体的なインスタンスは、セマンティクスが定義されたＡＮＤ，ＯＲ，ＸＯＲ，ＮＯＴおよび InterfaceElement である。ＲＴＣＴＬ式は最終的に、すべての定義から得られる。
BaseExpression（基本表現）
− Iff(precondition, expectedReaction) → precondition⇔expectedReaction（前提条件⇔期待される応答）
− Implies(precondition, expectedReaction) → precondition ⇒ expectedReaction（前提条件⇒期待される応答）
Figure 2008171391
UnaryOperator（単独演算子）
Figure 2008171391
InterfaceElement 要素を PointOfTime と LengthOfTime とに相互に独立してマッピングすることはできない。というのも、共通の時間基準が必要とされるからである。したがって InterfaceElement のマッピングは、そのコンテキスト内で行われる（InterfaceElement(pointOfTime, lengthOfTime, valueCondition) )。
ｔをｋ∈Ｎであると仮定し、Ｖが、ＲＴＣＴＬにおいて関連する ValueCondition であると仮定する。このことは以下のように形成される。
ValueCondition（値条件）
− AtMostforValue(interfaceElement, valueElement) →interfaceElement ≦ valueElement（インタフェース要素≦値要素）
− AtLeastforValue(interfaceElement, valueElement) → interfaceElement ≧ valueElement（インタフェース要素≧値要素）
− ExactlyValue(interfaceElement, valueElement) → interfaceElement ＝ valueElement（インタフェース要素＝値要素）
− WithinValue(interfaceElement, lowerValue, upperValue) → lowerValue ≦ interfaceElement ≦ upperValue（小さい値≦インタフェース要素≦大きい値）
V is true at the point in time ExactTime(time) for duration ExactDuration(duration)（Ｖが時点 ExactTime(time) で期間 ExactDuration(duration) にわたって真である）→
Figure 2008171391
このような表現は、対応する ValueConditionＶが常に "time" 時間単位後に発生することを定義する。時点と時点＋期間との間に、ValueCondition が満たされない時点がないようにしなければならない。さらに、ValueCondition が時点＋期間後に真であることを終了するようにしなければならない。
Ｖは時点 ExactTime(time) で期間 AtLeast(duration) にわたって真である→
Figure 2008171391
この式は、最後の制約が存在しない先行の式と異なる。これは、ValueCondition が最小期間時間単位にわたって満たされなければならないことを示すAtLeast 要素を使用する。したがって、上限は存在しない。
付録Ａに、PointOfTime 要素および LengthOfTime 要素の他のすべての組み合わせのセマンティクスの定義が記載されている。
ユーザに、該ユーザが作成した要求から生成された実行可能なプログラムが与えられる前に、該ユーザに対して、何のテストステップを行うかを伝えることが重要である。そうでなければ、何をテストするかをユーザが正確に知らずに、該ユーザは要件を仕様化して生成されたテストプログラムを実行してしまうというシチュエーションが生じてしまう。この場合、テスト結果を理解するのは困難である。
要求「リモートコントロールの「ロック解除」ボタンが押された場合、車両は２秒後にロック解除される」は、次のテストステップを成す：
・リモートコントロールの「ロック解除」ボタンを押された状態にセットする。
・２秒待機する。
・車両がロック解除されたか否かをテストする。
テストステップを記述するための要素を含むテスト仕様書メタモデルを、以下で紹介する。このメタモデルの１つのインスタンスは具体的なテストシーケンスを表し、要求メタモデルのインスタンスから自動的に導出されることにより、テスト仕様書は具体的な要求から得られる。テスト仕様書メタモデルが要求ベースのテスト生成のコンセプト全体のコンテキストにどのように適合するかを示すため、図３２において、要求およびテスト仕様書のメタモデルが追加された図３５の概略を繰り返す。
図３８は、テスト仕様書メタモデルからの抜粋を示す。テスト仕様書メタモデルの基本的要素は、"Test" 要素である。１つのテストは１つまたは複数のテストケースから成り、これらのテストケースは "TestCase" 要素によってモデリングされる。たとえば、複数のテストケースを要求メタモデルの "Iff" 要素によって呼び出すことができる。上記のように、この要素を使用することは、言語的表現 "If and only if ... then" が要求において使用されることを意味する。このような要求を満たすためには、以下のステートメントが真でなければならない：前提条件が発生した場合には、期待される応答は発生しなければならず、前提条件が発生しない場合には、期待される応答は発生してはならない。これら２つのステートメントをテスト仕様でテストしなければならない。これらは、１つのテストに所属する２つのテストケースを表す。TestCase は要素 "StimulusData"（スティミュラスデータ）および "ReferenceData"（基準データ）を有し、これらは前提条件と期待される応答とを表す。したがってテスト仕様に関しては、前提条件および期待される応答の代わりに、スティミュラス部分と基準部分という用語を使用する。
各スティミュラス部分は、実行すべき複数のテストステップから成る。基準部分も、複数のテストステップをテストする。１つのテストステップは、抽象的要素 "TestStep" によって表現される。StimulusData および ReferenceData は双方とも、スティミュラス部分および基準部分において第１のテストステップを表現する TestStep 要素と割り当て関係を有する。各 TestStep 要素の方は、後継者として TestStep を有することができ、それによってテストステップのシーケンスが得られる。これを具現化するためには、TestStep 要素をそれ自体に関連づけする。このことは図３８に示されている。
抽象的な TestStep 要素は、"ParStep" 要素および "SeqStep" 要素によって具体化される。ParStep は、２つのテストステップを並列実行するために使用される。というのも、これは２つの TestStep 要素を有するからである。テストシーケンス全体を並列的にモデリングすることもできる。このケースは、ParStep 要素の TestStep 要素が別の TestStep 要素を後継者として有するときには常に発生する。このようにして、図３９に示されたようなテストシーケンスを作成することができる。
SeqStep 要素は１つのテストステップのみを表す。これは、要求メタモデルの InterfaceElement と異なるセマンティックを有するちょうど１つの InterfaceElement との割り当て関係を有する。テスト仕様の InterfaceElement は、テストステップにおいてちょうど１つの入力または出力がアドレシングされるという事実をモデリングするために使用される。各テストステップごとに、値が入力または出力に割り当てられる。要求メタモデルのように、InterfaceElement は ValueElement 要素および PointOfTime 要素および LengthOfTime 要素を有する。要求メタモデルの InterfaceElement は、入力または出力と値との割り当て関係を仕様化する。前提条件では、このような割り当て関係は "If input = = value, then"（入力〜が値〜である場合、〜）を意味するので、この割り当て関係が真であるか否かを問い合わせる問い合わせの一種であった。テスト仕様のスティミュラス部分では、割り当て関係は "input = value" をセットするための命令を定義する。これによって、システムの応答をテストすることがことができる。これが割り当てである。テスト仕様書メタモデルの時間的条件は、要求メタモデルの時間的条件と同等である。
テスト仕様のセマンティクスは、これをテストインプリメンテーションにマッピングすることによって定義される。というのも、テストインプリメンテーション自体がセマンティクスを有するからである。たとえば、AutomationDesk テスト自動化ツールで実行可能なテストのテストシーケンスのセマンティクスは、該テスト自動化ツールのインプリメンテーションによって暗黙的に定義される。
これらのテストステップは、ユーザに対して自然言語の形態で提示しなければならない。テスト仕様のメタモデルの要素のうち幾つかは要求メタモデルの要素と同一であるが、要素のマッピング先である文フラグメントは異なる。というのも、これらの要素のセマンティクスが異なるからである。このセクションでは、テスト仕様のメタモデル要素がどのように文フラグメントにマッピングされるかを扱う。
スティミュラス部分では、入力および出力に値が割り当てられ、基準部分では、入力および出力が特定の値を有するか否かを検査しなければならない。これら２つのプロセスは異なるので、InterfaceElement 要素が StimulusData 要素に所属するかまたは ReferenceData 要素に所属するかに依存して、該 InterfaceElement 要素は２つの異なる手法で自然言語にマッピングされる。InterfaceElement(ExactlyValue, valueElement) 表記は、ValueCondition ExactlyValue（値状態 正確な値）が割り当てられた InterfaceElement および関連づけされた ValueElement valueElement が後続の文フラグメントにマッピングされることを意味する。<InterfaceElement.name>（インタフェース要素名）表現は、ユーザによって指定された InterfaceElement 要素の名前を示す。
StimulusData: InterfaceElement（インタフェース要素）
− InterfaceElement(ExactlyValue, valueElement) → "Set ＜InterfaceElement.name＞ to ＜valueElement.name＞"（＜インタフェース要素名＞を＜値要素名＞にセットする）
− InterfaceElement(atMostforValue, valueElement) → "Set ＜InterfaceElement.name＞ to at most ＜valueElement.name＞"（＜インタフェース要素名＞を最大でも＜値要素名＞にセットする）
− InterfaceElement(atLeastforValue, valueElement) → "Set ＜InterfaceElement.name＞ to at least ＜valueElement.name＞"（＜インタフェース要素名＞を最小でも＜値要素名＞にセットする）
− InterfaceElement(withinValue, lowerValue, upperValue) → "Set ＜InterfaceElement.name＞ to between ＜lowerValue.name＞ and ＜upperValue.name＞"（＜インタフェース要素名＞を＜小さい値名＞と＜大きい値名＞との間にセットする）
ReferenceData: InterfaceElement（インタフェース要素）
− InterfaceElement(ExactlyValue, valueElement) → "Check if ＜InterfaceElement.name＞ is ＜valueElement.name＞"（＜インタフェース要素名＞が＜値要素名＞であるか否かを検査する）
− InterfaceElement(atMostforValue, valueElement) → "Check if ＜InterfaceElement.name＞ is at most ＜valueElement.name＞"（＜インタフェース要素名＞が最大でも＜値要素名＞であるか否かを検査する）
− InterfaceElement(atLeastforValue, valueElement) → "Check if ＜InterfaceElement.name＞ is as least ＜valueElement.name＞"（＜インタフェース要素名＞が最小でも＜値要素名＞であるか否かを検査する）
− InterfaceElement(withinValue, lowerValue, upperValue) → "Check if ＜InterfaceElement.name＞ is between ＜lowerValue.name＞ and ＜upperValue.name＞"（＜インタフェース要素名＞が＜小さい値名＞と＜大きい値名＞との間であるか否かを検査する＞
PointOfTime の時間的条件は、次のように文フラグメントにマッピングされる：
PointOfTime（時点）
− ExactTime(time) → "Wait exact ＜time.valueString＞ time units"（ちょうど＜時間値ストリング＞時間単位だけ待つ）
− Soonest(time) → "Wait not less than ＜time.valueString＞ time units"（＜時間値ストリング＞より小さくない時間単位だけ待つ）
− NotLaterThan(time) → "Wait no more than ＜time.valueString＞ time units"（＜時間値ストリング＞より大きくない時間単位だけ待つ）
− BetweenTime(lowerTime, upperTime) → "Wait between ＜lowerTime.valueString＞ and ＜upperTime.valueString＞ time units"（＜小さい時間値ストリング＞と＜大きい時間値ストリング＞との間の時間単位だけ待つ）
テスト仕様では時間的条件 LengthOfTime には、スティミュラス部分と基準部分とで異なる意味が与えられる。スティミュラス部分における期間仕様は、状態とインタフェースオブジェクトとの割り当てが、この期間によって定義された期間にわたって与えられなければならないことを示す。基準部分は、該基準部分において記述された状態とインタフェースオブジェクトとの割り当て関係が、仕様化された期間にわたって真であるか否かを検査しなければならない。期間を含むこれら２つのシチュエーションは、テスト仕様において２つの異なる手順を表す。したがって、これら２つの手順をユーザに対して、異なる手法で自然言語で提示するのが合理的である。図４０に、前提条件で期間 "for at least 2 seconds"（少なくとも２秒にわたって）と、期待される応答で期間 "for at least 3 seconds"（少なくとも３秒にわたって）とを有する要求が示されている。これら２つの期間仕様は、要求では同じ言語的表現を有する。テスト仕様では、これらの期間仕様は異なる文フラグメントによって表現される。スティミュラス部分では、期間は文 "wait 2 seconds"（２秒待機する）によって表現されており、基準部分では表現 "for 3 seconds"（３秒にわたって）によって表現される。というのも、次の検査命令は３秒にわたって実施しなければならないからである。
スティミュラス部分では、状態がインタフェースオブジェクトに割り当てられた後にプロセスは指定された期間にわたって待機することを、ユーザに対して示さなければならない。このことによって、割り当て関係がこの指定された期間にわたって真であることが保証される。
StimulusData（スティミュラスデータ）: LengthOfTime（時間の長さ）
− ExactlyDuration(duration) → "Wait for exact ＜duration.valueString＞ time units"（正確に＜期間値ストリング＞時間単位にわたって待機する）
− AtLeast(duration) → "Wait for at least ＜duration.valueString＞ time units"（少なくとも＜期間値ストリング＞時間単位にわたって待機する）
− AtMost(duration) → "Wait for at most ＜duration.valueString＞ time units"（最大でも＜期間値ストリング＞単位時間にわたって待機する）
− BetweenDuration(lowerDuration, upperDuration) → "Wait for between ＜lowerDuration.valueString＞ and ＜upperDuration.valueString＞ time units"（＜小さい期間値ストリング＞と＜大きい期間値ストリング＞との間の時間単位にわたって待機する）
基準部分では、仕様化された期間が、状態とインタフェースオブジェクトとの間の定義された割り当てに関する検査をどの程度の期間にわたって実施しなければならないかを決定する。したがって期間には、この場合には文順序において異なった位置が与えられる。期間は、状態とインタフェースオブジェクトとの間の割り当て前に配置される。
ReferenceData（基準データ）: LengthOfTime（時間の長さ）
− ExactlyDuration(duration) → "For exact ＜duration.valueString＞ time units"（正確に＜期間値ストリング＞時間単位にわたって）
− AtLeast(duration) → "For at least ＜duration.valueString＞ time units"（少なくとも＜期間値ストリング＞時間単位にわたって）
− AtMost(duration) → "For at most ＜duration.valueString＞ time units"（多くても＜期間値ストリング＞時間単位にわたって）
− BetweenDuration(lowerDuration, upperDuration) → "For between ＜lowerDuration.valueString＞ and ＜upperDuration.valueString＞ time units"（＜小さい期間値ストリング＞と＜大きい期間値ストリング＞との間の時間単位にわたって）
関連する時間的条件を有する InterfaceElement 要素と ValueElement 要素とのこのような割り当て関係をテストステップに割り当て、テストステップを構造化してテスト全体のテストシーケンスを形成するためには、以下のマッピングが適用される：
・ Test(testCase1,...., testCaseN) → TestCase: "＜testCase1＞ ... TestCase: ＜testCaseN＞"（テストケース：＜テストケース１＞・・・テストケース：＜テストケースＮ＞）
・ TestCase(stimulusData, referenceData)（テストケース（スティミュラスデータ、基準データ）） → "＜stimulusData＞ ＜referenceData＞"（＜スティミュラスデータ＞＜基準データ＞）
・ StimulusData(testStep) → "＜testStep＞"（＜テストステップ＞）
・ ReferenceData(testStep) → "＜testStep＞"（＜テストステップ＞）
・ TestStep（テストステップ）
− SeqStep(interfaceElement)（連続ステップ（インタフェース要素）） → "＜interfaceElement＞"（＜インタフェース要素＞）
− ParStep(nextStepOne, nextStepTwo)（並列ステップ（次のステップ１，次のステップ２）） → "parallel: first parallel step: ＜nextStepOne＞ ＜parStep.operator＞ second parallel step: ＜nextStepTwo＞"（並列：第１の並列ステップ：＜次のステップ１＞＜並列ステップ演算子＞第２の並列ステップ：＜次のステップ２＞）
要求を表現するために要件メタモデルを介して提供される要素は、すでに説明した。テスト仕様書メタモデルは、テストシーケンスにおける個別のテストステップを記述するための要素を含む。ここで、要求メタモデルのインスタンスの形態の具体的な要求を、テスト仕様書メタモデルに基づいて具体的なテスト仕様書に変換しなければならない。こうするためには、要求メタモデルの各要素に対して、テスト仕様書メタモデルの１つまたは複数の要素にどのようにマッピングするかを管理するために規則を定義しなければならない。したがって変換規則は、テストシーケンスの要求要素の意味を決定するために何のテストステップが具体的な要求の要素によって呼び出されるかを記述する。変換は、抽象クラスのインスタンスが発生する可能性がない要求メタモデルのインスタンスで実行されるので、抽象的要素に対してはマッピング規則は必要ない。
図４１に示されているように、Implies 要求要素（暗黙的定義）はテスト仕様において次の要素構造にマッピングされる。テスト要素は、正確に１つの TestCase 要素（テストケース要素）との間に関連性を有する。TestCase 要素は StimulusData 要素および ReferenceData 要素を有する。
Iff 要素はほとんど同じ構造にマッピングされる。しかし、上記のようにこの要素から２つのテストケースが導出されるので、テスト要素は２つの TestCase 要素を有し、各 TestCase 要素は１つの StimulusData 要素および１つの ReferenceData 要素を有する。テストケースのうち１つは、各１つの InterfaceElement 要素の属性を介して否定の割り当てを行うことにより、否定的なテストになる。図４２にこのような変換ステップが示されている。
要求の InterfaceElement は、SeqStep 要素と、該 SeqStep 要素に結びつけられているテスト仕様の InterfaceElement とにマッピングされる。InterfaceElement は、要求の InterfaceElement とちょうど同じ要素を有する。これらにはたとえば ValueCondition（値条件）が含まれる。図４３は、InterfaceElement 要素のマッピングを示す。演算子の変換規則を以下で説明する。
ＮＯＴ演算子は、インタフェースオブジェクトに割り当てられた状態を否定する。さらにこの演算子は、バイナリ演算子によって結合された表現全体を否定することもできる。状態とインタフェースオブジェクトとの割り当てはすべて、テスト仕様書では別個のテストステップを成すので、変換前には、別個に否定されたテストステップに変換される別個に否定された条件を形成するために、要求全体における表現の否定を解決しなければならない。各 InterfaceElement ごとにＮＯＴ演算子を使用して、InterfaceElement に所属する状態を否定すべきか否かを決定する。図４４は、否定された全体表現が別個に否定された表現に変換される変換を示す。こうするためには命題論理の法則 [Sch00] が使用され、たとえばド・モルガンの法則が使用され、論理積および論理和の否定が以下のように定義される：
not (a and b) = (not a) or (not b)
not (a or b) = (not a) and (not b)
図４４の例では、否定された全体の表現が個別に否定された表現に変換されることによって、"and" が "or" に変換される。
要求においてバイナリ演算子が発生することにより、ParStep 要素がテスト仕様において作成され、これはバイナリ演算子の種類を属性に記憶する。これは、バイナリ演算子によって結合されたテスト仕様ステートメントを、並列実行しなければならないテストステップまたはテストステップシーケンスに変換する。図４５に、要求メタモデルのＡＮＤ要素のインスタンスの変換が示されている。その結果は、テスト仕様書のメタモデルの ParStep 要素のインスタンスであり、これは属性として演算子の種類を記憶する。すべてのバイナリ演算子が ParStep 要素にマッピングされても、演算子の種類を忘れてはならない。というのも、すべての演算子は異なるセマンティックを有するので、演算子によって実行可能なテストにおいて呼び出されるプロセスが異なるからである。
命題論理の法則によれば、ＸＯＲ演算子（EITHER OR）は演算子ＡＮＤ、ＯＲおよびＮＯＴによって表現することができ、ＸＯＲ要素自体は変換されない。
要求メタモデルは、たとえば "AtMost" および "AtLeast" 等の要素を介して、時間的観点の非常にフレキシブルな記述を可能にする。たとえば AtMost 要素は、時間的期間の上限のみを記述するので、具体的な期間はこの仕様からは未だ知らされない。これは、複数の値によってテストを実行する自由度を提供する。しかし、このような時間仕様は具体的なテストを行うのには十分でない。テストを実行するためには、いつ入力または出力に値を与えなければならないかを正確に定義する必要がある。というのも、スティミュラス部分での割り当ては、テスト対象の応答をテストするためには、具体的な時間的条件で確立されるからである。したがって、時間的条件の正確な仕様を、要求作成と具体的なテスト実行との間のシーケンス全体のどこかで設ける必要がある。それゆえ、時間的仕様をいつ具体化すべきかの質問が生じる。具体的なテストを実行するための情報の失われた項目は、自由度と称される。
時間的条件を具体化する１つの手法に、次のような手法、すなわち、正確に仕様化された時間仕様でユーザがテスト仕様の時間的条件を完全にして自由度を解決するために使用することができる機能を有するテスト仕様書をユーザに対して提供する手法がある。
しかしこのアプローチでは、要求とテストとの間のシーケンスの早期の段階でフレキシビリティが失われてしまう。テストを実行する人は、要求を作成してテスト仕様書を与えられる人と同一でない場合がある。フレキシブルな情報はこのことによって失われるので、実行できるテストは１つだけになる。一例を以下に示す。
図４６に１つの要求が示されている。この要求から導出されたテストケースは、自由度が解決されるまで実行することができない。前提条件をテスト中はセットするためには、リモートコントロールの「ロック解除」ボタンを２秒にわたって押さねばならないかまたは３秒にわたって押さねばならないかまたはもしかしたらそれ以上長い時間にわたって押さねばならないかを示す定義が必要である。図４６に示されたテストステップは、より詳細に仕様化することができる自由度を示すために、"2 + how many seconds"（２秒＋何秒）および "3 − how many seconds"（３秒−何秒）という表現を使用している。テストはしばしば、異なる値で実行されることが多い。時間的条件が過度に早期に具体的な値に固定されている場合、この固定された値しかテストに使用することができない。
さらに、正確な時間仕様がテスト仕様書の作成時点ではユーザに対して知らされていないために、ユーザは自由度を解決することができない場合がある。
これらのことに基づいて、正確な時間的条件の仕様化は、要求からテストまでに至るプロセスでさらに後ろの方に移動され、このことによってフレキシビリティはより長時間にわたって確保される。それゆえテスト仕様書メタモデルは、時点および期間を定義するために、要求メタモデルと同じ要素を有する。
ユーザは要求において、InterfaceElement に ValueElement 種類の異なる要素を異なる時点で割り当てて、該 InterfaceElement を任意の回数で使用することができるので、ユーザが一貫しない要求を定義する事態が生じる可能性がある。図４７に示された要求は、速度 InterfaceElement が値 "20 km/h" および "30 km/h" を異なる時点でとらなければならない前提条件を含む。２つの状態割り当てに対する時間仕様は、オーバーラップするインターバルとして定義されている。InterfaceElement に異なる値を割り当てるために仕様化された時間インターバルのオーバーラップによって、一貫しない要求が形成されてしまう。
具体的なテストが生成される前に要求が非一貫的にならないことを保証するためには、非一貫性をテストするためにアルゴリズムを使用することができる。一例にバックトラッキングアルゴリズム [CLRS01] がある。これはステップごとに、得られた部分的な解から完全な解を形成しようとするものである。解が存在する場合にはこのアルゴリズムは解を見つけるか、またはこの問題に対して解が存在しない。バックトラッキングアルゴリズムを使用して要求に非一貫性テストを行うことは、厳密に試験された。バックトラッキングアルゴリズムが解を見つけなかった場合、要求は非一貫性である。このようなバックトラッキングアルゴリズムは単純な例でしかない。というのも、このアルゴリズムの実行時間は指数関数的であるからだ。ユーザのために非一貫性テストをプロトタイプで実行しなければならない場合、より効率的なアルゴリズムを開発しなければならないであろう。
しかし、このようにして非一貫性の検出を計算するためには、幾つかの基本的な仮定を行わなければならない。たとえば、"at most 2 seconds"（最大で２秒）が要求における期間として仕様化された場合、計算で挿入すべき具体的な期間を定義しなければならない。したがって、自由度を予め解かなければならない。さらに、ValueElement と InterfaceElement とのすべての割り当てに対する時間的条件も定義しなければならない。しかし、時間的条件を仕様化するための要素は上記のようにオプション要素としてモデリングされたので、時間仕様は必ず存在するとは限らない。たとえば、応答テストはまずイベント発生まで待機し、その後、このイベントに応答して別のイベントが発生したか否かをテストする。テストが待っている対象であるイベントがいつ発生するかは既知ではないから、このことは、要求の非一貫性のテストに含めることができない。このことは次のことを示している。すなわち、非一貫性のこのようなテストはこの時点では有用でなく、これは自由度の解決のように、要求から具体的テストまでに至る連鎖の中でさらに後ろの方にシフトされる。
このテストは、このテスト命令を並列実行することによって楽観的にしか実行することができない。テストステップは、テスト対象の変数に対するアクセスを呼び出す。並列実行されている複数のテストステップが変数に同時アクセスしようとする場合、テストツールはこのテストを中止する。それゆえ、非一貫的な命令は実行時間中に検出される。
テスト対象をテストするためには、実行可能なテストプログラムが必要である。これは以下では、テストインプリメンテーションと称される。図４８に、本発明の全体コンセプトのコンテキストにおけるテストインプリメンテーションが示されている。
要求は初期は、どのような状態がどのインタフェースオブジェクトに割り当てられているかを記述する。テスト仕様書は、テストの個別のステップにおけるインタフェースオブジェクトと状態との割り当て関係を記述する。
上記のように、テストの実行はテスト対象の入力側に値を与え、該テスト対象の出力側で値を読み出すことである。読み出されたこれらの値は、期待される値と比較される。実行可能なテストを生成するためには、インタフェースオブジェクトをテスト対象の変数にマッピングしなければならない。状態と具体的な値とのマッピングも必要である。図１９に、インタフェースオブジェクトと変数と状態と値との関係が示されている。各テストプラットフォームは、テスト対象の変数およびその値を異なって記述することがある。テスト仕様で使用されるインタフェースオブジェクトは、テストプラットフォームにおけるちょうど１つの変数にマッピングすることができる。しかし、インタフェースオブジェクトが、テストプラットフォームにおいて複数の変数としてインプリメントされるシチュエーションを表現することもできる。このことは、複数の変数にマッピングされるインタフェースを１つにする。図３６にこのようなケースが示されている。
使用されるテストツールは、ユーザがインタフェースオブジェクトおよび状態をテストプラットフォームの変数および値にマッピングするための機能を提供する。マッピングを行うためには、どのインタフェースオブジェクトおよびどのような状態をテスト対象におけるどの変数およびどの値に割り当てなければならないかが既知でなければならない。
テスト仕様の他のすべての要素、たとえば時間的条件、またはテストステップの並列実行のための ParStep 要素等は、テストツールによって供給された要素にマッピングしなければならない。このようにして、テストツールにおいて実行可能なテストシーケンスが作成される。通常はテストツールは、とりわけ時間的条件および並列性をモデリングするための要素を有する。
上記のように時間的条件は、たとえば "at least 500 milliseconds"（少なくとも５００ｍｓ）等の仕様から生じる自由度を有することができる。しかし、テストインプリメンテーションでは正確な時間仕様を定義して、具体的な命令を実行できるようにしなければならない。したがって、自由度を解かなければならない。上記のように、フレキシビリティを確保するためには、要求からテストインプリメンテーションまでに至る連鎖において可能な限り遅い時点で、時間的条件のこのような具体化を行わなければならない。それゆえ、自由度はテスト仕様書では未だ維持され、この自由度はテストインプリメンテーションステップでは解かなければならない。テストインプリメンテーションにおいてパラメータを使用して、自由度を有する時間的条件を表現することにより、可能なフレキシビリティを最大にすることができる。テストを実行する人は、このようなパラメータの値をセットできなければならない。このことによって、異なるパラメータ入力ひいては異なる具体的時間条件でテストを実行し、複数のテストケースでテストを実行することができる。
図４９に、実行可能なテストシーケンスが示されている。最初の２つのテストステップは、右側に示されたテスト仕様のインスタンスから得られる。ExactlyValue（正確な値）、ValueCondition（値条件）および ValueElement（値要素）を有する割り当て関係は InterfaceElement から作成され、待機命令は期間から生成される。このようなマッピングプロセスは、テスト仕様要素をツール固有のテスト要素にマッピングするマッピングを実施するインポート機能によってテストツールを拡張することにより自動化される。テスト仕様書の形式を標準化することが重要なステップになる。ここでは、すべてのテストツールを標準的形式のためのインポート機能によって拡張することができ、すべてのテストツールは、標準化されたテスト仕様要素とツール固有の要素とのマッピングは１回だけ行えばよくなる。このような標準化がない場合には、テスト仕様書を出力としてテストするすべてのツールは異なるフォーマットを使用することになる。テストツールは、各フォーマットに対して別個のインポート機能を必要とする。テストツールによってサポートされないすべてのフォーマットはインポートすることができず、その結果として処理は手動になってしまう。テスト仕様書の標準化された形式は、将来の目論みである。図５０に、要求からテストインプリメンテーションまでの連鎖全体が示されており、これはほぼ完全に、標準化されたテスト仕様書によって自動化することができる。どのインタフェースオブジェクトがどの変数にマッピングされるかに関する情報と、どのような情報がどの値を表すべきかの情報は、なお手動で追加しなければならない。この情報は、たとえば図５１に示されているようにテーブルに記憶することができる。
以下に、AutomationDesk テストツールを例に、テスト仕様書とテストインプリメンテーションとのマッピングを行うための構成を示す。
このセクションでは、テスト仕様書を要求から生成するために使用できる変換規則に沿って、要求のメタモデルおよびテスト仕様の構想化を紹介した。テスト仕様書とテストインプリメンテーションとのマッピングも紹介した。ソフトウェア品質を評価するための最も重要な基準はカスタマ要求の充足数であるから、このアプローチによって作成された要求ベースのテストが品質保証において重要な役割を果たす。テスト作成のコストは自動化によって削減される。
本発明で提供される要求ベースのテスト生成のアプローチは自然言語を基礎としている。これによって、ユーザが要求を直観的に作成することができる。それと同時に、要求メタモデルによって定義された語彙を使用することにより、要求を機械処理可能にすることができる。このようにして、テストをこのような要求から作成することができる。要求メタモデルによって、要求において時間的条件を仕様化することができるので、組み込みシステムの特性を非常に詳細に記述することができる。組み込みシステムの正確な挙動はしばしば時間的条件に依存することが多いので、完全な要求を作成するためには、時間的観点をモデリングする必要がある。現在既存のアプローチはすべて、ここに記載された特性のうち少なくとも１つが欠けていることを説明した。
要求からテストステップを生成することにより、その際に作成された実行可能なテストをユーザが理解することができる。このようなテストステップを含むテスト仕様は編集不可能に構成されているので、情報を変化または詳細化することができない。その理由は、編集可能なテスト仕様によって、要求とテスト仕様との間に非一貫性が生じる可能性があるからだ。テスト仕様は、該テスト仕様が生成される元である要求をテストするのに必要なテストステップを記述しなければならない。おそらくは、付加的なテストを要求とは独立して実行できるように、テストを修正しなければならない場合、別のテスト仕様を直接作成してこの別のテスト仕様から実行可能なテストプログラムを作成するのが有利である。テスト仕様を要求から独立して作成するのを可能にする別のコンセプトが、将来のプロジェクトで開発できるようになるだろう。
ここに紹介されたコンセプトをインプリメントし実用化の潜在可能性を呈するプロトタイプを以下で説明する。
本発明での作業の一部として、要求からテストを自動生成するために使用され上記のコンセプトをインプリメントするプロトタイプを開発した。このプロトタイプは、上記で挙げられた語彙から要求を表現するためのグラフィカルユーザインタフェースを提供する。この要求は自然言語の形態でユーザに対して提示され、この要求を定義するためのメタモデルのインスタンスが背景で実行されている。ユーザの要求にしたがって何をテストすべきかをユーザに示すために、要求モデルがテスト仕様書メタモデルのインスタンスにマッピングされる。このテスト仕様書はユーザインタフェース上で示され、しかも自然言語の形式で示される。要求から具体的なテストまでに至る連鎖を完成するためには、テストツールで実行可能なテストをテスト仕様書から生成する。AutomationDesk テストツールを例として示し、これにしたがって、テスト仕様書からテストシーケンスまでに至る AutomationDesk におけるプロセスを説明した。
プロトタイプは、エクリプス開発環境においてＪａｖａアプリケーションとして作成された。Ｊａｖａプログラミング言語はプラットフォームに依存しないので、それを選択した。このことは、開発されたＪａｖａアプリケーションの実行が特定のオペレーティングシステムに関連づけされていないという利点を有する。エクリプス開発環境は、便利なインプリメンテーション環境として使用できるだけではない。多くのエクリプスプラグインはオープンソースプロジェクトの一部として開発されており、これらのプラグインによって、幅広い種類のプログラミング課題のためのプログラムをサポートすることができる。エクリプスプラグインであるＯＭＯＮＤＯは、ＵＭＬダイヤグラムをグラフィック形式でモデリングし、このＵＭＬダイヤグラムからコードを自動生成するためのものである。本発明の開発では、既述のメタモデルをモデリングするためにＯＭＯＮＤＯを使用した。
グラフィックエディタの開発には、アプリケーション固有の関数と、save, load, undo, および redo 等の標準的な演算とが含まれており、このような開発は非常に複雑である。このような標準的な演算が各エディタごとにスクラッチから開発されてグラフィックエディタの開発全体をサポートする必要を無くすために、エクリプスモデリングフレームワーク（ＥＭＦ）およびグラフィカルエディタフレームワーク（ＧＥＦ）が作成された。これらのフレームワークによって、形式的モデルに基づいてグラフィカルエディタを作成する手法がより便利になる。これらは、モデルビューコントローラ（ＭＶＣ）アーキテクチャを基礎としている [GHJV04]。形式的モデルの要素はグラフィカル要素（ビュー）としてユーザに対して提示される。このグラフィックスは修正することができる。このコントローラは、グラフィクスの修正をモデルに引き渡し、それによって、グラフィカル構成要素を表示する手法を変化するタスクを有する。
ＥＭＦはモデルを作成する手法を提供する。このようなモデルからＥＭＦは、任意のＪａｖａアプリケーションのベースとして使用できるＪａｖａコードを自動生成することができる [MDG+04]。ＥＭＦによって作成されたモデルは、ＭＶＣアーキテクチャにおけるモデルを表現する。
ＧＥＦは、グラフィカルエディタを作成するためのフレームワークである。これは、エディタを開発する人が、たとえばグラフィカルモデルの保存等のアクションのための機能を作成する必要がないように、標準的な演算を提供する。ＥＭＦによって作成されたモデルコードはＧＥＦエディタに組み込まれ、該エディタをインプリメントする基礎を成す。しかし完全なエディタを構成するためには、ＥＭＦモデルのＪａｖａコードをなお完全にする必要がある。使用可能なモデルの部分をユーザに対して表示するためには、適切なグラフィカル要素を形成しなければならない。このようなグラフィカル要素がビューを構成する。さらに、ユーザがグラフィックを操作するための機能をインプリメントしなければならない。たとえば、ユーザがテキスト形式の指定子をグラフィカル要素に割り当てるためには、ユーザがテキストに入力するためのダイアログを構成しなければならない。
ビューとモデルとを結びつけるためには、どのグラフィカル要素によってモデルの各要素が表現されているかの定義（コントローラ）を各要素が有さねばならない。このようにしてユーザは、モデル要素で演算を実行するためにグラフィカル要素の機能を使用することができる。
したがって、モデルをエディタに使用しなければならない場合、大きいモデルによってインプリメンテーションの作業量が大きくなる。ＥＭＦとＧＥＦとのこのようなギャップを埋めるために、マーリンジェネレータ（Merlin Generator）はＥＭＦベースのモデルからＧＥＦエディタを生成するための機能を提供する [Ani05]。このエディタは、要求にしたがって拡張および適合することができる。これは、モデル内の各クラスに対してグラフィカルオブジェクトを有し、２つのクラス間の各割り当てごとに、これらクラスの２つのオブジェクトを結合するための結合子を有する。このようなオブジェクトおよび割り当てをメニューからエリアへドラッグアンドドロップして、使用可能な演算を適用することができる。
本発明の枠組みでは、グラフィカルエディタを異なる構成で構成しなければならない。要求メタモデルの要素は、テキストセグメントとしてユーザに対して提示しなければならない。しかし、テキストセグメントを自由に選択して結合するこの能力は、ユーザに対して、このケースで要求を表現するにあたり、十分なサポートを提供しない。このようなコンセプトは、正確な文構造が得られるようにテキストセグメントを配置することができる文を仕様化しない。ユーザは、モデルで定義されたテキストセグメントすべてを結合するオプションを有することができ、このようにしてツリー構造が形成される。ユーザはこのことを、使用可能なテキストセグメントのうち任意のテキストセグメントによって開始することができる。要求メタモデルは、１つのクラスと別のクラスとの割り当て関係を部分‐全体関係によって定義する。したがって、このような割り当て関係は単方向であり、これによってクラスは順序付けされる。メタモデルではクラスは、テキストセグメントがどのように繋げられて文法的に正確な文を構成するかが順序によって定義されるように配置される。この情報を補助としてユーザに与えなければならない。このことを可能にするためには、文に追加される場合に文法的な正しさを確保する文セグメントのみを選択のために提示するメニューを使用する。さらにその目的は、メタモデルに現在存在するクラスを処理する一般的なエディタを構成して、メタモデルの修正または拡張が該エディタに自動的に含まれるようにすることである。マーリンジェネレータを使用して作成されたＧＥＭエディタは本発明の要件を満たさないので、このフレームワークを使用せずに特別なエディタを作成した。しかし、ＥＭＦは要求メタモデルをモデリングするために必要である。このメタモデルからＥＭＦは、プロトタイプで使用されるＸＭＬドキュメントを生成する。
以下の基本的な要件を、本発明の枠組みで作成されたプロトタイプエディタに適用した。要求メタモデルによって定義された語彙は、テキストセグメントとしてユーザに提供しなければならない。テキストセグメントを選択する目的は、ユーザが表現を形成するのをより容易にすることである。１つの有利な目標は、新たなテキストセグメントの自動的な組み込みである。これによって、要求メタモデルが拡張される際にエディタに手動の修正を行う必要を無くす。
上記の要件は、エディタが一般的な構成を有する必要があることを意味する。換言すると、選択のために使用可能なテキストセグメントはエディタに固定的に組み込まれず、その代わりに、エディタはメタモデルに存在するすべての要素を動的に処理してメニュー要素を形成する。
ユーザが要求作成時に実施するステップを以下で説明する。プロトタイプにおいてユーザインタラクションによってトリガされる処理も概説する。
第１のステップは、要求を表現するために供給しなければならないユーザ固有のテキスト構文を定義することである。ユーザは、要件を適用する先であるシステムのインタフェースを表現するために、自然言語の形式でインタフェースオブジェクトを必要とする。インタフェースオブジェクトを要求において使用することにより、ユーザはインタフェースの変数を参照して値をこの変数に割り当てることができる。さらに、変数の入力値および出力値を記述する状態も定義しなければならない。このことを図解するため、以下で要求の形態の簡略的な例を挙げる。明瞭化するために、この例は時間的条件を有さない。
例：
「リモートコントロールの「ロック解除」ボタンが押されたら車はロック解除される」という、中央ロック機能に適用すべき要求では、「リモートコントロールの「ロック解除」ボタン」という表示を有するリモートコントロールボタンは、中央ロックの機能のインプリメントに関与するＥＣＵのインタフェースオブジェクトを記述する。ユーザがボタンを押すと、インタフェースオブジェクトは「押された」状態に割り当てられる。ユーザはその応答として、車両のロック解除を期待する。インタフェースオブジェクトである「車両」には、「ロック解除」状態を与えなければならない。このような要求を記述できるようにするためには、テキスト構文「リモートコントロールの「ロック解除」ボタン」および「車両」がインタフェースオブジェクトとして必要とされる。「押された」状態および「ロック解除」状態も必要である。したがって、要求の記述が形成される前に、このようなテキスト構文をユーザによって定義しなければならない。図５２に、このことがグラフィック形式で示されている。」
図５３のスクリーンイメージは左側に、インタフェースオブジェクトに対してすでに作成されたテキスト構文のリストを有する。下方のボックス内にテキストを入力して「追加」ボタンを押すことにより、別のテキスト構文を追加することができる。「消去」ボタンは、対象となっているリストから、強調された要素を消去する。右側に、インタフェースオブジェクトに割り当てることができる状態を定義するための同様の機能を有するリストがある。作成されたこれらのテキスト構文は、要求を表現するための基本的要素を成す。これらは、上記で挙げられた InterfaceElement クラスおよび ValueElement クラスのインスタンスとして保存されている。
定義されたメタモデルと、ユーザ入力によって完成された語彙は、ユーザが要求を作成するために使用できるテキストセグメントの形式でユーザに対して提供しなければならない。これらのテキストセグメントは、要求メタモデルの要素から動的に生成される。これらは、すべての要求に使用される一般的な要素、たとえば演算子および時間的条件等であるか、または、ユーザ定義されたインタフェースオブジェクトおよび状態である。要求を形成するためには、語彙からテキスト構文を選択する。メタモデルのインスタンスは、ステップごとに背景で構築される。
語彙と同様に、メタモデルは要求の構造に関する情報も含む。クラス間の関連づけによって、どの要素が使用可能でなければならず、どの要素が１つの別の要素と関係を有することができるかを定義する。したがって、ユーザはメタモデル語彙の単語のセット全体を一度も見ることはない。ユーザが常に、すべての用語から選択することができる場合、メタモデルに準じない構造を有する要求を定義するおそれがある。プロトタイプによって、このような構造を有する要件のみを作成することができる。これと同様に、プロトタイプはこのような構造を有する要求のみを処理してテスト仕様を形成することができる。
要求作成を可能な限り直観的に行えるようにするために、文構築中の典型的な人間の振る舞いを考慮した。文は、単語を繋げることによって形成される。各文は特定の文構造を有する。英語では文はしばしば、主語、述語および目的語から成ることが多い。これらの要素はまた、この順序で配置される。したがって、プロトタイプはテキストセグメントを、要求表現に必要とされる順序で提示する。メタモデルは、要求を作成するための個別の要素と、要素相互間の関係とを含むが、要素がユーザに対して提示される文の仕様を有さない。したがって、語順に関する情報はＸＭＬドキュメントによってプロトタイプに追加される。メタモデルに存在する各要素ごとに、これは文中の位置の定義と、すでに定義された要素と自然言語との間のマッピングとを有する。図５４に、このＸＭＬドキュメントからの抜粋が示されている。これは、ＡＮＤ要素が発生するごとに "and" テキストがユーザに対して表示されることを定義する。この演算子によって結合された２つの BaseExpressionElement 要素はテキストの左側と右側とに示さなければならない。図５５に示されたＸＭＬ要素である "displayOrder"（表示順）は、第１の BaseExpressionElement を最初にユーザに対して表示しなければならないことを定義する。ＸＭＬ要素 classInstance（クラスインスタンス）は、次にこの要素自体すなわちＡＮＤ要素を表示しなければならないことを示す。第２の BaseExpressionElement は最後に配置される。
メタモデルは次のように、すなわち、要求に必要なすべての要素がメタモデルのインスタンスに存在することによって、要求が不完全な構文で仕様化されるのが阻止されるように構成される。すべての要求は、前提条件と期待される応答とを有さねばならない。これらは少なくとも１つの InterfaceElement と ValueElement とから成るので、インタフェースオブジェクトと該インタフェースオブジェクトに割り当てられた状態とがそのつど記述される。これらの基本的な要素がなければ、要求は意味を成さない。したがって、要求に必須のこれらの要素はユーザに対して提示しなければならない。
時間的条件はユーザに対して提供される。というのもこれらは多くの要求で必要であるからだ。しかし、ユーザはしばしばそのことに気づかないことが多い。たとえば、「リモートコントロールの「ロック解除」ボタンが押されたら車両はロック解除される」という要求は、この要求でＥＣＵをテストするための時間的条件を欠いている。たとえば、車両をロック解除するためにはどの程度の時間にわたってボタンは押されなければならないかの定義が必要である。しかし、時間的条件を定義することは必須ではない。というのも、時間的条件はすべての要求で意味を成すとは限らないからである。
プロトタイプは、メタモデルを作成するために作成しなければならない次の要素からのみユーザが選択できるようにすることで、要求を作成するためのガイドをユーザに対して提供する。ユーザが該ユーザの要求のためにテキストセグメントを選択すると、テキストセグメントの新規のセットが表示される。これらは、メタモデルにおいて選択されたテキストセグメントに対する後継者であるテキスト構文である。これらの後継者は、以下に挙げられるアルゴリズムによって決定される。
テキストセグメントが選択されるとユーザに対して、すでに作成された要求の部分においてどの場所に該テキストセグメントを挿入するかが示される。この場所は、図５５に示されているように矢印によってマーキングされている。このようなプレビュー機能はユーザオリエンテーションのために使用され、選択されたテキストセグメントを要求に追加するべきか否かを決定するプロセスを支援することができる。ユーザはこの時点では未だ、選択されたテキストセグメントを要求中に配置しないことにより、該テキストセグメントの追加をキャンセルすることができる。プレビュー機能は起動および作動不能にすることができる。
図５５では、要求の作成を示す一例を使用する。左側に、ユーザによってすでに選択され繋げられたテキストセグメントがある。この例ではテキストセグメントは、文部分「リモートコントロールの「ロック解除」ボタンが押された場合に車両が・・・」を構成する。このメニューは右側に示されている。これは、既存の文フラグメントにドラッグアンドドロップによって付加することができる要素を含む。背景ではメタモデルのインスタンスが、選択された要素から形成される。新規の要素をこのインスタンスに付加するためにはプログラムは、該インスタンスを結びつけなければならない対象である要素を見つけなければならない。
時間的条件を仕様化することは必須ではないので、時間的観点を有するテキストセグメントの選択をスキップすることができる。こうするためには、図５６に示されたメニューコマンド "skip" を使用することができる。
選択された要素をユーザが別の要素に置換したい場合にスクラッチから要求を作成する必要を無くすためには、この目的を満たす機能を提供するのが有利である。このような一般的なエディタにおいてユーザは、予め選択された要素の代わりになることができる要素のリストを表示するために、テキスト構文を選択することができる。図５７に、このような要素リストが示されている。たとえば「ロックされる」というテキストを「ロック解除される」に置き換えることができる。
本発明における演算子の必要性および演算子の構想は、すでに説明した。演算子はインプリメンテーション時に特別な処理を必要とする。というのも演算子は、要求に付加的な文部分を挿入するからである。要求作成中に、ユーザは演算子を介して付加するために、文中の特定の位置に特別な文部分を挿入しようとする場合がある。
演算子を使用することはオプションである。別の特別な特徴は、演算子を複数の場所で使用できることである。それゆえ、演算子を追加する手法は、別の要素を仕様化する手法と異なる。演算子を使用するためには、ユーザはまず、演算子を付加する文フラグメントを選択しなければならない。このことは、対象となる文部分を強調することによって行われる。演算子は任意の要素に付加することができないので、演算子を付加できる文部分に所属する要素のみが灰色に着色される。このような強調アクションによって右下に、可能な演算子のリストを含む付加的なメニューが表示される。図５８に、完全に作成された要求が含まれる。ここでは、この要求を付加的な文部分によって拡張しなければならない。灰色のテキストセグメントは、新規のテキストセグメントを演算子によって付加すべき文部分を形成する。この演算子メニューは右下に示されている。演算子テキストセグメントが選択されると、システムはこの演算子テキストセグメントを、強調されている文部分に付加する。
しかし、内部では演算子は、強調されている要素のうち幾つかによって表現される InterfaceElement には付加されず、要求モデルの構造に起因してこの InterfaceElement の前に付加されるので、この関連づけを更新しなければならない。図５９に、演算子が付加される文部分と、メタモデルの相応のインスタンスとが示されている。Implies 要素と InterfaceElement 要素との間の関連性はここで解消され、これら２つの要素と関連性を有する演算子がその間に付加される。これがバイナリ演算子である場合、ユーザが次に何を選択するかに依存して、バイナリ演算子は InterfaceElement と別の InterfaceElement とを連結するか、または別の演算子と結合しなければならない。
上記のように自然言語文は、複数の演算子が使用される場合に多義性を含むことがある。要求にはメタモデルによって一義的な構造が与えられるので、要求をユーザに対して一義的に提示することができる。このことはたとえば、括弧を表示することによって行うことができる。プロトタイプでは一義的な構造は、相互に所属する文部分を強調することによって表現される。
演算子の位置は、どの演算子が選択されたかに依存する。ＡＮＤ演算子、ＯＲ演算子およびＸＯＲ演算子は、強調された文部分の最後に来る。それに対してＮＯＴ演算子は、強調されている要素の初めに配置される。それゆえ、語順を可能な限り正確に構築することができ、要求を通常の文のように読むことができる。図６０では、要求がＮＯＴ演算子によって拡張されている。
要求が演算子によって拡張された後、この演算子がバイナリ演算子である場合、付加的な文部分を作成しなければならない。メタモデルで演算子に対する後継者として定義された要素が、右下のメニューで選択のために設けられている。要求の別の場所で未だテキスト要素が存在しない場合、右上のメニューに表示されている要素によってこの要求は完成される。
要求を作成するためには、ユーザにまず、要求が開始できるテキストセグメントが与えられる。上記のように、BaseExpression の特化子となる Iff 要素および Implies 要素が存在する。これらのテキストセグメントのうち１つが選択されると、メタモデルが使用されて、選択されたこの要素にどのテキストセグメントを付加できるかが決定される。次の可能なテキスト構文はアルゴリズムによって決定される。このアルゴリズムは、次の可能な要素を見つけるために、要求モデルにおいて現在選択されている要素から開始する。
要求メタモデルは、ＥＦＭフレームワークにおいてＵＭＬダイアグラムによってモデリングされた。ＥＭＦは、このダイアグラムの内容を表現するＸＭＬドキュメントを、ＵＭＬダイアグラムから作成する。このＸＭＬドキュメントは、アルゴリズムが動作する基礎を成す。このアルゴリズムは、クラスに対するＸＭＬドキュメントを探索する。図５１に擬似コードの形態で示されたアルゴリズムを、ここで説明する。
アルゴリズムの基本的機能は、要求メタモデルにざっと目を通し、ユーザに対して、該ユーザが要求の次の要素を選択しなければならない要素のセットを見つけることである。その開始点は、最後に選択された要素であり、これは図６１では "chosenElement" と称されている。要求定義の開始時には、アルゴリズムは BaseExpression 要素の具体的なインプリメンテーションを開始点として実行される。というのも、この時点では選択された要素が存在しないからである。BaseExpression 種類の要素は要求の基本的構造を定義し、文の初めを成す。以下の形式的記述がこのアルゴリズムを定義する：
Ｖがメタモデルのすべてのクラスのセットであり、Ｅ⊆Ｖ×Ｖが、すべての関連性のセットであると仮定する。２つのクラスａ，ｂが（ａ，ｂ）∈Ｅである場合、これらのクラスａ，ｂ∈Ｖは関連性を有する。この場合、ａは関連づけのソースクラスを表し、ｂは関連づけのターゲットクラスを表す。したがって、このような関連づけは単方向である。
Figure 2008171391
ここではａ，ｂ∈Ｖは、抽象クラスａの具体的なインプリメンテーションが、この場合には種類ｂであることを意味する。したがって、ａはより一般的なクラスｂの特化子であり、特性および関連性を引き継ぐ。引継ぎの遷移性に起因して、この演算は遷移的である。ｖ，ｕ，ｋ，ｓ，ｘ∈Ｖであり、最後にユーザ選択されたメタモデルのクラスｖが、該クラスｖのインスタンスを要求に追加するためのクラスであると仮定する。インスタンスはユーザに対して、テキストセグメントの形態で提示される。その次に、メタモデルにおいてｖの後に来ることができるすべてのクラスを見つける。Ｕ＝｛ｕ｜（ｖ，ｕ）∈Ｅ∨（ｋ，ｕ）∈Ｅ｝であると仮定する。ここではｋとｖは、上記のａとｂとの関係に相応し、ｖは、文表現のための選択を行うためにユーザに対して次に提示されるすべての要素のセットである。ｖの次のクラスは、ｖ自体のターゲットクラスでなければならないか、または、ｖから引き継ぎかつその関連性も引き継ぐ抽象クラスのターゲットクラスとすることができる。図６２に、これら２つのケースが示されている。次の要素の探索は、図６３では "getNextElements"（次の要素を得る）機能によって行われる。
見つけらる後継者は抽象クラスであってもよい。メタモデルでは、要求において構文として現れる要素は、抽象的でないクラスとしてモデリングされる。抽象クラスは、複数のクラスが共有する特性および関連性の束を表し、それ自体では構文を表現しない。したがって、ユーザに対しては要求作成のための抽象クラスの特化子のみを提供すればよい。Ａ⊂Ｖはすべての抽象クラスのセットであると仮定する。見つけられた後継者が抽象クラスである場合、すべての特化子のセットの探索が実行される。
Figure 2008171391
ｕが見つけられた後継者であってかつ抽象クラスであり、Ｓはｕの抽象的でないすべての特化子のセットであると仮定する。
図６１に示された擬似コードでは、"getSpecialisations"（特化子を得る）機能は抽象的要素のすべての特化子を返す。特化子ｓはｕから直接引き継ぐか、または、ｓがｋから引き継ぎｋがｕから引き継ぐ場合に間接的に引き継ぐ。このことは遷移演算である。このステップにおいてアルゴリズムは、複合体としてモデリングされなかったクラスのみを探索する。見つけられた特化子は、該特化子が引き継ぐ元であるクラスとの間に関連性を有してはならない。図６３に、複合体から形成された構造が示されている。すでに述べたように演算子は、メタモデルにおいて複合設計パターンを使用してモデリングされた。これを要求で使用することは必須ではないので、これらはユーザに対して異なる手法で提供しなければならない。
"getSpecialisations" 機能によって見つけられた要素はユーザに対してメニューで提供されることにより、ユーザは１つの要素を要求のために選択できるようにする。図６１において、"addToUserMenu"（ユーザメニューに追加する）機能は、要素をメニューに追加するための機能である。見つけられた後継者が抽象クラスでない場合、これをメニューに直接追加することができる。
そのアルゴリズムをここで、該アルゴリズムによる具体的な繰り返しを一例として使用して説明する。図６４は要求メタモデルを示している。この図は、記述を追跡してより理解しやすいようにされている。要求作成の開始時には、ユーザは BaseExpression 要素の種類の構文を必要とする。アルゴリズムにはこの要素が開始要素として与えられる。BaseExpression は抽象的な形でモデリングされているので、第１の繰り返しは具体的なインスタンスの探索で開始する。見つけられた要素のセットは、１つの Iff と１つの Implies とから成る。
これらの構文は自然言語表現にマッピングされるので、ユーザには、要求を開始するために２つの理解しやすい択一的選択肢が与えられる。ユーザが Implies 要素を使用することを決定したと仮定すると、これはアルゴリズムの入力を成す。まず、メタモデルにおいて Implies に対する後継者となることができる要素が探索される。複合的関連づけ形式によって、クラス間の関係は方向を有し、それゆえソース‐ターゲット関係が存在する。この複合的関連づけ形式は、部分‐全体関係をモデリングするために使用される。１つのクラスは別のクラスの一部であるから、この別のクラスが所属するクラスが無ければ存在することはできない。全体をモデリングするクラスはソースクラスであり、部分クラスはターゲットクラスである。Implies のターゲットクラスはその後継者であり、また、Implies が引き継ぐ元であるすべてのクラスのすべてのターゲットクラスでもある。この繰り返しでは、BaseExpressionElement 種類の２つの後継者要素が見つかる。Implies 自体はターゲットクラスを有さないが、BaseExpression から２つの関連づけである precondition と expectedReaction とを引き継ぐ。２つの後継者は抽象クラスであるから、次にその具体的なインスタンスが探索される。この探索はすべての後継者で行われる。BaseExpressionElement 種類の要素の特化子のセットは、InterfaceElement に限定される。
この時点で、複合体によってモデリングされた要素を除外する必要があることが明らかになる。ユーザは、演算子を介して別の文部分を付加する先である文部分を作成する前に、演算子を選択することが可能であってはならない。この規則は、人は通常は１つの事実をまず先に記述してからその後に別の事実を記述しようとする事実に拠る。コンピュータサイエンスでは、ツリー構造において演算子によって結合された２つの要素を表現するのが通常である。というのも、演算子がネスト化される場合には、ツリー構造によって非多義性が保証されるからである。ツリー構造を介して結合を作成するためには、まず演算子を選択して、その後に、結合すべき２つの要素を該演算子に付加しなければならない。しかし、人間はツリー構造で思考しない。自然言語では、繋げられた事実のシーケンスによって列挙が行われる。この観点を、ここでアルゴリズムにおいて考慮する。
この繰り返しの結果は、２つの InterfaceElement 要素になる。ユーザ定義されたインスタンスはこの種類の要素に対して作成されたのに対し、ユーザは、インタフェースオブジェクトに対するテキスト構文を作成した。これらのインスタンスは、このステップにおいてユーザに対して選択のために提示される。この繰り返しで見つけられた２つの要素は InterfaceElement 要素であるから、ユーザには、これらの要素のうち１つを選択するオプションが２回与えられる。最初に選択された要素に前提条件の役割が与えられ、第２の要素は、期待される応答を表す。ユーザ選択の後、アルゴリズムはクラス名 InterfaceElement を入力として続行する。
上記のように要求メタモデルは、単純に別のクラスを追加することによってのみ拡張することができる。一般的なエディタはユーザに対して、このメタモデルを基礎として選択するための要素を与えるので、メタモデルの新規の要素は、要求表現のためのエディタにおいて自動的に使用可能になる。たとえば、Iff 要素および Implies 要素の他に付加的に、種類 "While the precondition is valid, the expected reaction must occur"（前提条件が有効である場合には、期待される応答が発生しなければならない）の新規の具体的な要素も存在する場合には、"While" と称される要素を追加することができる。この要素は BaseExpression 要素から引き継ぐことができるので、この要素は前提条件と期待される応答とを有する。
新規の要素を要求記述のためのＵＭＬメタモデルに追加することは、この新規のクラスに対してプログラムコードが自動作成されることを意味する。これは２つの手法によって拡張しなければならず、既存のクラスの手法をコピーおよび修正することによって簡単に行われる。BaseExpression から引き継ぐ While クラスに関しては、テスト仕様書メタモデルの要素に対するマッピングを定義する「変換」手法を作成するだけでよい。これは、BaseExpression クラスから別の手法を引き継ぐ。
ＵＭＬメタモデルからＸＭＬドキュメントが生成され、アルゴリズムは上記のように、クラスに対するドキュメントを探索する。ＵＭＬメタモデルが拡張された場合、ＸＭＬドキュメントを再生成することができる。その際にはアルゴリズムは、プロトタイプが要求記述のための付加的なテキストセグメントとしてユーザに対して提供する新たなクラスも見つける。
テスト仕様書は、予め作成された要求から作成することができる。
こうするためには、ユーザはメニューシーケンス "Requirement"（要求）→"load all"（すべてをロードする）によってすべての要求のリストを得ることにより、作成された要求をプロトタイプにロードすることができる。ユーザはこのリストから、自然言語で提示される１つの要求を選択しなければならない。
メニューシーケンス "Testspecification"（テスト仕様書）→"create"（作成）を実行することにより、選択された要求を上記のようにテスト仕様書に変換する変換がトリガされる。
テスト仕様書メタモデルの要素のインスタンスが作成されて関連づけによって結合されることにより、テスト仕様書のメタモデル全体のインスタンスが得られる。この変換は、記述された変換規則に準ずる。テスト仕様書は自然言語でも表示される。テスト仕様書によって記述されたテストステップは連続的に実行されるので、これらは相互に上下に連続して挙げられている。並行して実行すべきステップは、"parallel:" という表現によって示され、インデントによって示される。図６５に、すべての要求のリストと、自然言語で表現される選択された要求と、生成されたテスト仕様書とが示されている。
生成されたテスト仕様書はＸＭＬ形式で保存することができる。ＸＭＬが記憶フォーマットとして選択された理由は、ＸＭＬの構造と、ＸＭＬ要素の綿密なネーミングとによって、ＸＭＬドキュメントが人間にとって理解しやすくなっているからである。ＸＭＬでは構文解析系が使用可能であるから、テスト仕様書をＸＭＬ形式で読み出して別の処理を行うことができる。
実行可能なテストを要求から作成するためには、まず要求をテスト仕様書にマッピングし、その後にこれをテストインプリメンテーションに変換しなければならない。このセクションでは、ＴｅｘｔＭＬテスト記述言語と AutomationDesk テスト自動化ツールとを紹介する。その後に、テスト仕様書の個別の要素とテストインプリメンテーションの要素とのマッピングを、具体的な AutomationDesk テストに沿って説明する。
TestML テスト記述言語は、ＩＭＭＯＳプロジェクトの一部として開発された。自動車産業においてますます開発プロセスの自動化が行われるようになると、サポートのために使用される様々なテストツールが存在するようになる。企業と該企業のサプライヤとの間の集中的な協力により、異なるテストツールを使用する複数の企業にわたってＥＣＵ開発およびテストは広まっていく。このことが、企業間のテスト開発の統合およびテストシナリオの交換の阻害要因となる。というのも、これらすべてのツールは異なるファイル形式をサポートする場合があるからだ。それゆえ、ＩＭＭＯＳプロジェクトの目標の一部に、異なるテストツール間のギャップを埋める目標がある。
ＴｅｓｔＭＬは、ＸＭＬをベースとするツール独立性の交換フォーマットであり、形成されるテスト記述を交換するための交換フォーマットである。これは、異種のツールワールドから生じる技術的な障害を克服することを目的とする。テストツールは、テストツール固有の表記とＴｅｓｔＭＬとのマッピングを実行するインポート機能とエクスポート機能とによって拡張することができる。このような解決手段によって、将来において、テストを交換するための付加的な機能によって既存のツールの使用を継続すると同時に、これらを再利用することを継続することができる。
AutomationDesk ツールは、ＥＣＵソフトウェアのモデルベースの自動的なテストを簡略化する。グラフィカルユーザインタフェースによって、ユーザは直観的に処理することができる。ＵＭＬアクティビティダイヤグラムと構造的に類似するテストシーケンスを、AutomationDesk によって仕様化することができる。このツールが提供するアイテムの中にライブラリがある。これによって、ハードウェアベースのテストプラットフォームへのアクセスが可能になる。こうするために、テスト記述に必要な要素を表現する "Read"（読み出し）および "Write"（書き込み）ブロックがグラフィカル形式で提供される。たとえば、テスト対象のプラットフォーム固有の変数に値を割り当てることはテスト内の作業である。"Write" 種類のブロックがこの機能を実行する。たとえばテスト対象の変数を読み出すためには、"Read" ブロックが提供される。ドラッグアンドドロップを使用してこれらのブロックをまとめて、テストシーケンスを形成することができる。このテストはテスト対象において、ブロックを該テスト対象の変数に割り当てることによって自動的に実行することができる。
実行可能なテストを得るためには、要求から生成されたテスト仕様書を具体的なテストインプリメンテーションに変換しなければならない。AutomationDesk テスト自動化ツールは、テスト仕様書からテストインプリメンテーションを作成するインポート機能によって拡張することができる。TestML 形式に対応するインポート機能が AutomationDesk において実験的に作成された。これによって、AutomationDesk において TestML からテストインプリメンテーションへのマッピングを自動的に実行することができる。
しかし、本発明で記述されたテスト仕様書は、TestML によって表現できない要素を含む。その一例に、並列性が存在することがある。テスト仕様書とテストインプリメンテーションとの間の架け橋を形成するためには、TestML を拡張しなければならない。本発明のプロトタイプにより、テスト仕様書をＸＭＬ形式で記憶するための機能が提供される。
図６６に、テスト仕様書をＸＭＬ形式で出力として返すプロトタイプと、TestML に対するインポート機能を有する AutomationDesk テストツールとが示されている。要求からテストインプリメンテーションまでの連鎖を完全にするためには、テスト仕様書のＸＭＬ形式と TestML との間を手動でマッピングする必要がなお存在する。このシーケンスの完全な自動化を実現するためには、テスト仕様書の標準フォーマットを開発し、すべてのテストツールを該標準フォーマットのインポート機能によって拡張するのが非常に有利であろう。別の手段は TestML を拡張して、テスト仕様書のすべての要素を TestML で表現できるようにする。この場合、プロトタイプを修正することにより、該プロトタイプはテスト仕様書を TestML に変換するように構成できる。
上記ですでに述べたように、AutomationDesk ではテストはテストステップによって、テストシーケンスを構成するブロックの形態で記述される。図６７に、テスト仕様書および相応のテストインプリメンテーションをテストシーケンスの形態で示す。これは、TestML で要素が存在しないので手動で作成された。テストシーケンスはテスト対象に関する情報をロードすることによって、たとえば変数をロードすることによって開始する。それと同時に、テストプラットフォームに関する情報もロードされる。その後、テストプラットフォームをアドレシングするブロックが初期化される。図６７に示されたテスト仕様書は、AutomationDesk におけるブロックにマッピングされる。テスト仕様書のスティミュラス部分におけるインタフェースオブジェクトに対する状態の割り当ては、Write ブロックにマッピングされる。インタフェースオブジェクト "the button ‘unlock’ on the remote control"（リモートコントロールの「ロック解除」ボタン）は変数 "remote_unlock" にマッピングされ、「押された」状態は値 "1" によって表現される。テスト仕様書の基準部分におけるインタフェースオブジェクトに状態を割り当てることにより、テスト対象の適切な変数が読み出され、読み出された値は、状態によって表現される期待値と比較される。
テスト仕様書におけるＡＮＤ演算子およびＯＲ演算子は、テスト挙動の異なるインプリメンテーションを形成する。図６７中の例では、基準部分にはＡＮＤ結合が存在する。これによって、結合された表現が双方とも真であるか否かを検査するテストが得られる。これら２つの表現が満たされた場合のみ、テストは成功で完了される。それとは対照的に、ＯＲ演算子がテスト仕様書で使用される場合、１つの表現が満たされただけで、テストインプリメンテーションでテストが成功したことを返さなければならない。
このセクションでは、ユーザがプロトタイプによって要求を作成して該要求からテスト仕様書を生成するために使用できる手順を挙げた。基本的なインプリメンテーションの側面も紹介した。ここで、具体的なテストに対するテスト仕様書のマッピングを、AutomationDesk テスト自動化ツールを例に使用して紹介し、適用例を以下に挙げる。
このセクションでは、自動テスト生成を行うための可能なアプリケーションを示す数例が含まれている。各例は、プロトタイプによってテスト仕様書を生成する対象である要求で始まる。その後、テスト仕様書を AutomationDesk テストツールにおいてテストステップにマッピングする。それと一緒に、テストステップはテストシーケンスを構成する。テストシーケンスは、実行可能なテストを表現する。
このような要求は、すでに使用された例に関連しているので、中央ロックシステムの機能を記述する。各要求は、プロトタイプにおける特定の要素の使用を示すことを目的とする。第１の要求は必須の要素とインタフェースオブジェクトと状態とのみを含む。時間的条件、演算子および相対的な依存関係は、次の例で追加される。
「車両はロックされている」という表現は、「すべてのドアはロックされている」と同義で使用される。すべてのドアがロックされている場合には常に、１つのドアがロックされていることは真である。
第１の適用例では、要求の最も単純なケースを示す。要求において必須であるインタフェースオブジェクトおよび状態のみが使用される。この要求は、リモートコントロールで「ロック解除」ボタンがすでに押されている場合は車両をロックしなければならないことを記述する。
要求：
「リモートコントロールの「ロック解除」ボタンが押された場合、車両はロック解除される。」
このテスト仕様書は、要求を検査するテストのテストステップを示す。リモートコントロールの「ロック解除」ボタンは、前提条件である押された状態にされる。ここで期待されるのは、車両がその後にロック解除されることである。このことをテストしなければならない。
テスト仕様書
「リモートコントロールの「ロック解除」ボタンを押された状態にセットする。車両がロック解除されたか否かをテストする。」
図６８に、テスト仕様書のテストステップを含む AutomationDesk におけるテストシーケンスが示されている。テキスト記述されたインタフェースオブジェクトである「リモートコントロールの「ロック解除」ボタン」および「車両」は、プラットフォーム固有の変数である "remote_unlock" および "door_status" にマッピングされる。状態「押された」および「ロック解除された」も、値 "２" および "０" にマッピングされる。テストシーケンスの開始時には、変数と、たとえばＭＡＴＬＡＢ（登録商標）／Ｓｉｍｕｌｉｎｋ（登録商標）またはプロセッサボード等のプラットフォームとが初期化される。テストステップ「リモートコントロールの「ロック」ボタンを押された状態にセットする」を実行するためには、Write ブロックを使用して "remote_unlock = 2" をセットする。"door_status" 変数は Read ブロックによって読み出され、その後にその値が検査される。値が "０" である場合には、これは期待されている値なので、テストは成功である。
この例では時間的条件が追加される。リモートコントロールの「ロック解除」ボタンを少なくとも５００ミリ秒（期間）にわたって押さねばならない。期待される応答は、自動車の車内照明が１００ミリ秒後に、少なくとも１００００ミリ秒（期間）にわたって点灯される。
要求：
「リモートコントロールの「ロック解除」ボタンが、少なくとも５００ミリ秒（期間）にわたって押された場合
車内照明は１００ミリ秒後に、少なくとも１００００ミリ秒にわたってオンされる。」
このテスト仕様書は、リモートコントロールの「ロック解除」ボタンが「押された」状態に割り当てられるという要求をテストするために必要な次のステップを示す。それによれば、待機時間は少なくとも５００ミリ秒である。というのも、この前提条件はその時間にわたって真でなければならないからである。期待される応答は１００ミリ秒後に発生しなければならないという事実から、さらなる待機時間はその１００ミリ秒ということになる。車内照明が少なくとも１００００ミリ秒にわたって点灯されるか否かに関して検査を実行する。
テスト仕様書
「リモートコントロールの「ロック解除」ボタンを押された状態にセットする。
少なくとも５００ミリ秒待機する。
・１００ミリ秒待機する。
少なくとも１００００ミリ秒にわたって、車内照明がオンであるか否かを検査する。」
図６９に示された AutomationDesk におけるテストシーケンスは、第１の例と同様に、プラットフォームおよび変数の初期化で開始される。前提条件 "remote_unlock = 2" が Write ブロックを介してセットされる。Sleep（スリープ）ブロックによって、AutomationDesk において待機プロセスが提供される。テストインプリメンテーションは、待機命令に対して正確に１つの時間仕様を有さなければならない。したがって、「少なくとも５００ミリ秒」等の時間的条件から生じるような自由度を解かなければならない。上記のように、時間的条件は、テスト実行のために具体的に仕様化しなければならない値を有するパラメータによって表される。
車内照明が少なくとも１００００ミリ秒にわたって点灯されるか否かを検査するためには、テストのために "light_inside" 変数を１００００ミリ秒以内に何回読み出さねばならないかの定義が必要である。こうするためには、名前「回数」を有する変数を定義する。ユーザは、この回数を自身で指定できるようにしなければならない。"light_inside" 変数が読み出された後は、待機時間は１００００／回数でなければならない。これは１００００ミリ秒を、回数によって定義されたステップに分割する。
この例では演算子が使用される。ここで前提条件は、リモートコントロールの「ロック解除」ボタンが押されることのみでなく、さらに、１００００ミリ秒後にドライバドアの外側のドアノブが引っ張られなければならないことも含む。ここで期待されるのは、車両がその後に開けられることである。
要求：
「リモートコントロールの「ロック解除」ボタンが少なくとも５００ミリ秒にわたって押され、かつ、外側のドライバドアノブが１００００ミリ秒後に引っ張られた場合、ドライバドアは開けられる。」
このテスト仕様書は、テストステップを並列実行するための命令を含む。上記の前提条件の２つの部分は並列実行され、ＡＮＤ演算子によって結合される。最後に、ドライバドアが開けられているか否かの検査が行われる。
テスト仕様書
「並列：
リモートコントロールの「ロック解除」ボタンを押された状態にセットする。少なくとも５００ミリ秒待機する。
かつ
１００００ミリ秒待機する。
外側のドライバドアノブが引っ張られる状態にセットする。
ドライバドアが開かれたか否かを検査する。」
AutomationDesk では、テストシーケンスはプラットフォームおよび変数の初期化で開始する。このことは図７０に示されている。並列命令は Parallel ブロック（並列ブロック）によってインプリメントされ、このブロックは２つの Serial（直列）ブロックを並列実行する。Serial ブロックは前提条件の２つの命令を含む。"remote_unlock" 変数に、Write ブロックによって値 "１" が割り当てられる。まず、時間仕様「少なくとも５００ミリ秒」を具体化しなければならない。上記のように、パラメータが、テストの実行のために具体的に仕様化しなければならない値を有する時間的条件を表現することができる。このパラメータの値をデフォルトとして "500" にセットすることができる。Sleep ブロックが、５００ミリ秒の待機時間をインプリメントする。それと並行して、まず１００００ミリ秒の待機時間を Sleep ブロックによって実行し、その後、Write ブロックを実行して、値 "１" を変数 "driver_door_handle" に割り当てる。変数 "driver_door_status" が読み出され、該変数が値 "1" を含むか否かが検査される。
この例では、インタフェースオブジェクトと状態との２つの割り当て関係の間に相対的な時間的関係が存在する。リモートコントロールで「ロック」ボタンが押された後に期待されるのは、１つのドアのドアボタンが押されて下方の位置に下げられることである。しかし、この期待される応答のタイミングはリモートコントロールの作動に依存してはならず、車両が実際にロックされる時点に依存しなくてはならない。ドアがロックされた１秒後に、該ドアのドアボタンを押して下方の位置にまで下げなくてはならない。
要求：
「リモートコントロールの「ロック」ボタンが押された場合
ドアがロックされて１秒後にドアボタンは下げられる。」
テスト仕様書ではこの応答挙動は、「ドアがロックされるまで待機せよ」という命令によって表される。
テスト仕様書
「リモートコントロールの「ロック」ボタンを押された状態にセットする。
ドアがロックされるまで待機する。
１秒待機する。
ドアボタンが下げられたか否かを検査する。」
図７１に、AutomationDesk におけるテストステップのシーケンスが示されている。車両の実際のロックまでの待機は、While ブロックによってモデリングされる。これは、待たれているイベントが発生するまで繰り返し実行される。"door_lock_status" が While ブロックで読み出される。値＜２である限り、このアクションは繰り返される。この変数が２の値になったら、車両のロックは完了されており、ドアボタンの状態を検査することができる。
このセクションでは、本発明の枠組みで作成されたコンセプトの異なる適用例を挙げた。４つの異なる要求を作成することにより、インタフェースオブジェクト、状態、時間的条件、演算子の使用および相対的な依存関係を示した。以下のセクションでは、開発されたプロトタイプの評価が含まれる。これによって、ここに記載されたコンセプトを評価することができる。こうするためには、実際的な適用シナリオを使用する。
本発明の評価の結果を以下で紹介する。所与の要求シナリオからのテスト仕様書の手動作成とテスト仕様書の自動生成のためのプロトタイプの使用との比較によって、自動生成によって提供されるコスト削減を示す。その後に、評価のために人間によって実行されるタスクを説明する。その次のセクションでは、評価の結果を紹介および説明する。
プロトタイプによる自動テスト生成と要求からの手動のテスト開発とを比較することにより、本発明で開発されたコンセプトが自然言語要求からのテスト作成で所望のコスト削減をもたらすことができるか否かを確認することができる。このような調査のために、車両のＥＣＵに関する要求を記述する４つの現実的なシナリオを選択した。これらのシナリオは、ユーザがプロトタイプによって得られるような補助なしで完全なテスト仕様書を設計するか否かをテストするために、完全な要求を表していない。図７２，７３，７４および７５がこれらのシナリオを示している。
この「指示灯」シナリオは、車両の後部霧灯の指示灯を点灯しなければならないか否かに関する条件を記述する。この指示灯がスイッチオフされるのを引き起こさねばならないイベントは、「指示灯オフ」シナリオに挙げられている。事故時のエアバッグに対する要求は、「エアバッグ」シナリオで定義されている。最後のシナリオは、車両の車内照明がスイッチオンされるのを引き起こすべきイベントを示している。
本発明を評価する課題での最初のステップは、これらのシナリオで記述された機能をテストするのに必要な個別のテストステップを手動作成することである。これらのシナリオは完全な要求を表さず、機能の所望の挙動をテストするために別のファクタを考慮してもよいことを特記しておく。
この評価の第２パートでは、プロトタイプを使用した。これらのシナリオを、プロトタイプによって要求として表現する。自動的なテスト仕様書生成がユーザに対して、これらのシナリオの機能を検査するための個別のテストステップを示した。この課題の両パートを実施するのに必要な時間を観察した。
この評価のために、本方法のコンセプトを予め知らされていない４人のテスト人員に依頼した。選択されたテスト人員は、１人は８年の専門的経験を有する学士の電気エンジニアであり、優秀な大学生レベルの機械工学専攻の学生と、優秀な大学生レベルのコンピュータサイエンス専攻の学生と、入学初期の大学生レベルの産業工学専攻の学生である。
本発明で開発された自然言語要求からテストを自動的に生成するためのコンセプトおよびプロトタイプを評価するために、以下の基準を定義した：
１．テスト仕様書を手動作成するための処理時間および自動作成するための処理時間を比較する
２．手動作成されたテスト仕様書および自動作成されたテスト仕様書の完全さを比較する
３．テスト人員の満足度を評価する
テスト人員は、この独特なプロトタイプに関して予め何の知識も有していないが、簡単な説明の後にはこのプロトタイプを補助なしで使用できるようになり、タスクを作業する間にこの有用な機能に慣れてきたのが観察された。要求からのテスト仕様書作成を行ったケースのうち７６％で、プロトタイプを使用することによって時間が削減された。５６％のケースで、手動実行とは対照的にプロトタイプによって著しい時間削減が実現され、平均して約４４％の時間削減が実現された。１つのケースでは、最大で８０％の時間削減が達成された。この評価は単に、要求からのテスト仕様書の作成にのみ関することに留意されたい。手動で実施する場合、テスト仕様書からテストインプリメンテーションを開発するためにかかる時間はおそらく、テスト仕様書をテストツールにインポートしてインタフェースオブジェクトおよび状態をテスト対象の変数および値に結合するより長くなるであろうから、ここでさらに時間削減が実現される可能性がある。
テスト人員の誰も、テスト仕様書を手動作成する際に、シナリオを時間的条件によって拡張しなかった。しかし、図７４のシナリオは、エアバッグの有用な機能を記述するために時間仕様を必要とする。対照的に、テスト人員たちはプロトタイプにおいて要求に時間的条件を追加するオプションを使用した。このことは、プロトタイプを使用する場合には要求はより完全に記述されることを示している。その理由は、時間的条件が忘れられるのをプロトタイプが阻止するからである。
テスト人員たちは、要求からのテストの自動生成が便利であると述べていた。とりわけ、プロトタイプが提供するガイダンスによって、たとえばシーケンスおよび時間的条件によって、エラー確率が低減されることを強調していた。上記のように、シノニムを定義できることが非常に肯定的に判定された。というのも、これは自然言語のステートメントをより読みやすくするのに非常に役立つからである。テスト構文を選択することによって要求を記述することは「直観的」であると称された。上記の赤色の矢印の形態のプレビュー機能は有利であると証明された。要求された１つの改善点は、テキストセグメントをアルファベット順にソートすることであった。括弧での表現は、択一的な表示オプションとして役立つであろう。
テスト人員の異なる所属分野に起因する有意に異なる結果は見られなかった。テスト仕様書の自動生成による最大の時間削減は、産業工学専攻の学生で見られた。
この評価の結果により、自然言語の形式で要求を直観的に記述することができ、また、大部分のケースでかかる時間が、テスト仕様書の自動生成によって削減されることが示された。さらに、要求をより完全に仕様化することができる。というのも、ツールのサポートが無ければ、時間的条件を忘れてしまう可能性があるからだ。プロトタイプの直観的な処理は、改善の可能性を有する。
作成されたコンセプトを以下で、可能な適用例によってまとめ、将来に対する見通しも挙げる。
本発明の枠内では、自然言語の要求の形式的な仕様化と、該要求に基づく自動的なテスト生成とを可能にするコンセプトを創作した。ユーザが自然言語の形式で要求を作成できるようにし、それと同時に機械読み取り可能な要求も得るためには、語彙および構文をメタモデルによって表現した。このメタモデルに基づいてユーザは、かつ自然言語の形式でユーザに提示される形式的な要求を作成することができる。インタフェースオブジェクトおよび状態の指示子を定義し、テストを受けるシステムに固有の用語によって語彙を拡張することができる。このようなメタモデルによって、時間的条件を仕様化することができる。時間的条件を有する要求をモデリングすることにより、組み込みシステムをテストするのに必要なより高い精度が要求に与えられる。
要求メタモデルのコンセプトは、上記のように拡張可能にモデリングされるので、語彙を完全にするために要素を追加することができる。たとえば、異なる文構造を形成するための要素を追加したり、"If...then" 構文をネスト化するための要素を追加することができる。さらに、期待される応答に関して異なる時間的基準を有する時間的条件を仕様化するために要素を追加することができることも紹介した。このことにより、期待される応答が前提条件の次に実行されるのではなく前提条件に対して時間的に並行して実行される要求を表現することができる。このような要求は、自動的なテスト生成のために使用される。実行可能なテストが作成される前にユーザに対して個別のテストステップを示すために、テスト仕様書が生成される。テスト仕様書で定義されたテストステップは、要求が適用されるシステムをどのようにしてテストするかを示す。テスト仕様書は、本発明に記載されたモデル変換の規則によって要求から生成される。
組み込みシステムをテストするために実行可能なテストをテスト仕様書から作成するためには、テストプラットフォーム非依存性のインタフェースオブジェクトおよび状態をテスト対象のプラットフォーム固有の変数および値にマッピングする必要がある。このような実行可能なテストは、テストツールでインプリメントすることができる。不精確な時間仕様から生じテスト仕様書になお残ってしまった自由度は、テストが実行されるように解くことにより、具体的な命令をテストで実行できるようにしなければならない。したがって、時間仕様をテスト実行前に具体化しなければならない。
要求から実行可能なテストまでのシーケンスを自動化することにより、テストを作成するのにかかる時間を削減し、要求とテスト仕様書との一貫性を維持することができる。自然言語を使用することにより、ユーザは形式的な手法の知識なしで、機械読み取り可能でありさらに処理可能な要求を作成することができる。時間的条件を要求作成中に追加できる機能が、手動での要求表現で忘れられてしまう時間的観点の仕様化をサポートすることができる。時間的条件の自由度が最後まで維持される場合、この自由度の範囲内で具体的な時間値を変化することにより複数のテストケースでテストを実行することができる。
本発明で記載されたコンセプトは、要求に基づいている。要求の充足度は高品質のソフトウェアの重要な基準であるから、要求ベースのテストは品質保証で重要な役割を果たす。実行可能なテストを要求から自動生成するためのこのようなコンセプトにより、ますます自動化されているテストプロセスにおけるギャップが埋められる。このことは大きな付加価値を提供する。というのも、テスト作成のコストを自動化によって格段に削減できるからである。このコンセプトの実際に可能な適用例を、プロトタイプによって示した。評価の結果、自然言語の要求からのテストの生成を自動化することにより、テストプロセスにおいて時間が削減されることが示される。テストは開発コストの膨大な比率となっているので、組み込みシステムの開発のコストが低減されることにより、開発プロセスはより効率的にされる。
要求からテストインプリメンテーションまでシームレスであるにもかかわらず、本発明で記載されたコンセプトは拡張可能である。要求から自動的に生成されたテスト仕様書は、本発明で想定されるテスト仕様書に適合された形式で使用することができる。テスト仕様書から実行可能なテストを自動的に作成できるようにするためには、テストを実行すべきテストツールはインポート機能を必要とする。テスト仕様書のフォーマットを標準化するのが良好な解決手段になるであろうことを示した。テスト記述言語である TestML は種々の要素によって拡張することができ、このような標準化にすることができるかもしれない。
将来の別の方向の研究が、異なるテストケースを作成するためのコンセプトとなり、実行可能なテストが実行される際に、このコンセプトがユーザに対して選択のために提示されるかもしれない。時間的条件の自由度のために、テストを異なる具体的な時間値で実行することができる。要求が期間条件「少なくとも４秒」を前提条件に含む場合、テストは次の点を検査することができる：
１．前提条件が正確に４秒にわたって満たされた場合、期待される応答が発生するか否か。
2. または、前提条件が５秒以上にわたって満たされる場合にも、期待される応答が発生するか否か。
異なる入力値の異なる条件によって、複数のテストケースも得られる。すでに、可能なテストケースを作成するための種々のアプローチが存在し、たとえば、[CTF01, Hu00] に挙げられたようなアプローチが存在する。本発明に組み込むための適切なコンセプトを提供するアプローチが存在するか否かを調査することができる。
しばしば、要求は初期には、自然言語の形式で形成されていることが多い。人の言語的表現力は通常、母語の場合が最も確実であり最大であるから、母語で表現される要求のエラー可能性が最も低い。したがって、自然言語要求を異なる言語で作成するためのコンセプトは、本発明を拡張する将来の可能性のある研究方向である。しかし、多くの言語は構文および文法に関して、本発明で調査された英語と完全に異なる特徴を有する。本発明のコンセプトを異なる特徴の言語に転用する可能性は、大きな研究可能性を有する。
要求は排他的に自然言語によってのみ記述されることはなく、別の形態の表現によって完成されることも多い。しばしばグラフィックスを形成することが多く、テーブルビューを使用することも多い。さらに、状態マシン等の形式的表記によって、テキスト形式の要求がより詳細になる。自然言語形式の要求の記述と種々の別の表記とを組み合わせることは、表現のより数多くの選択肢を提供するのに役立つ。自動的なテスト生成のために組み合わされた表記から要求を形式化することに関しては、研究の可能性が残っている。
文献
[ACD93] Rajeev Alur, Costas Courcoubetis, and David L. Dill. Model−Checking in Dense Real−time. Information and Computation, 104(1):2−34, 1993.
[Ani05] Chris Aniszczyk. Using GEF with EMF. Eclipse Corner Articles, January 2005.
[Bal98] Helmut Balzert. Lehrbuch der Softwaretechnik. Spektrum Akademischer Verlag, 1998.
[BN03] Bart Broekman and Edwin Notenboom. Testing Embedded Software. AddisonWesley, 2003.
[BvdBK98] Manfred Broy, Michael von der Beeck, and Ingolf Krueger. SOFTBED: Problemanalyse fuer das Grossverbundprojekt "Systemtechnik Automobil − Software fuer eingebettete Systeme". In Ausarbeitung fuer das BMBF, 1998.
[CES86] Edmund M. Clarke, E. Allen Emerson, and A. Prasad Sistla. Automatic Verification of Finite−State Concurrent Systems Using Temporal Logic Specifications. ACM Trans. Program. Lang. Syst., 8(2):244−263, 1986.
[CGP00] Edmund M. Clarke, Orna Grumberg, and Doron A. Peled. Model Checking. MIT Press, Cambridge, MA, 2000.
[CLL97] Chin−Liang Chang, Richard C. Lee, and Richard Char−Tung Lee. Symbolic Logic and Mechanical Theorem Proving. Academic Press, Inc., Orlando, FL, USA, 1997.
[CLRS01] Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein. Introduction to Algorithms. The MIT Press, September 2001.
[CSW06] Mirko Conrad, Sadegh Sadeghipour, and Hans−Werner Wiesbrock. Automatic Evaluation of ECU Software Tests. In Proceedings of the SAE 2005 World Congress, page 583, Detroit, USA, April 2006. Software Quality Research Lab, McMaster Univeristy, Hamilton, Canada. SAE Techn. Paper No. 2005−01−1659.
[CTF01] Philippe Chevalley and Pascale Th´evenod−Fosse. Automated Generation of Statistical Test Cases from UML State Diagrams. compsac, 00:205, 2001.
[Dij70] Edsger W. Dijkstra. Notes on Structured Programming. Forschungsbericht EWD249, April 1970.
[EMSS91] E. Allen Emerson, Aloysius K. Mok, A. Prasad Sistla, and Jai Srinivasan. Quantitative Temporal Reasoning (Extended Abstract). In E. M. Clarke and R. P. Kurshan, editors, Computer−Aided Verification: Proc. of the 2nd International ConferenceCAV’90, pages 136−145. Springer, Berlin, Heidelberg, 1991.
[FMR00] Stephan Flake, Wolfgang Mueller, and Juergen Ruf. Structured English for Model Checking specification. In GI−Workshop Methoden und Beschreibungssprachen zur Modellierung und Verifikation von Schaltungen und Systemen in Frankfurt, Berlin, 2000. VDE Verlag.
[FP05] Mario Friske and Holger Pirk. Werkzeuggestuetzte interaktive Formalisierung textueller Anwendungsfallbeschreibungen fuer den Systemtest. In A. B. Cremers, P. Manthey, P. Martini, and V. Steinhage, editors, Beitraege der 35. Jahrestagung der Gesellschaft fuer Informatik e.V. (Band2), Bonn, 19. bis 22. September 2005., volume 68 of LNI, September 2005.
[Fri04] Mario Friske. Testfallerzeugung aus Use−Case−Beschreibungen. SoftwaretechnikTrends, 24(3), August 2004. 21. Treffen der Fachgruppe 2.1.7 Test, Analyse und Verifikation von Software (TAV) der Gesellschaft fuer Informatik (GI).
[FS05] Mario Friske and Holger Schlingloff. Von Use Cases zu Test Cases: Eine systematische Vorgehensweise. In T. Klein, B. Rumpe, and B. Schaetz, editors, Tagungsband Dagstuhl−Workshop MBEES: Model Based Engineering of Embedded Systems, number 2005−01 in Informatik−Bericht. TU Braunschweig, January 2005.
[GCF+06] Juergen Grossmann, Mirko Conrad, Ines Fey, Alexander Krupp, Klaus Lamberg, and Christian Wewetzer. TestML − A Test Exchange Language for Modelbased Testing of Embedded Software. In Proceedings of Automotive Software Workshop, March 2006.
[GG93] Matthias Grochtmann and Klaus Grimm. Classification Trees for Partition Testing. volume 3 of Software Testing, Verification and Reliability, pages 63−82. 1993.
[GHJV04] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Entwurfsmuster. Addison−Wesley, July 2004.
[Gmb99] Robert Bosch GmbH. Kraftfahrtechnisches Taschenbuch. Springer Verlag, 1999.
[Gra00] Jens Grabowski. TTCN−3 − A new Test Specification Language for BlackBox Testing of Distributed Systems. In Proceedings of the 17th International Conference and Exposition on Testing Computer Software (TCS’2000), Theme: Testing Technology vs.Testers’ Requirements, Washington D.C., June 2000, June 2000.
[Hu00] Mou Hu. A New Test Design Method for Requirement−Based Software Testing. Beijing, China, August 2000.
[IEE90] IEEE. IEEE Standard Glossary of Software Engineering Terminology, December 1990.
[iST01] British Computer Society Specialist Interest Group in Software Testing. Standard for software component testing (draft 3.4), April 2001.
[KBP01] Erik Kamsties, Daniel M. Berry, and Barbara Paech. Detecting Ambiguities in Requirements Documents Using Inspections. In Mark Lawford and David L. Parnas, editors, Proceedings of the First Workshop on Inspection in Software Engineering (WISE’01), pages 68−80, Paris, France, July 2001. Software Quality Research Lab, McMaster Univeristy, Hamilton, Canada.
[Ken02] Stuart Kent. Model Driven Engineering. In M. Butler, L. Petre, and K. Sere, editors, Proceedings of the Third International Conference on Integrated Formal Methods (IFM 2002), volume 2335 of Lecture Notes in Computer Science, page 286−298, Turku, Finland, May 2002. Springer Verlag.
[Lam06] Klaus Lamberg. Software−Entwicklung: Software−Testen. In H. Wallentowitz and K. Reif, editors, Handbuch Kraftfahrzeugelektronik Grundlagen − Komponenten − Systeme − Anwendungen. Vieweg Verlag, Wiesbaden, 2006.
[Lig02] Peter Liggesmeyer. Software−Qualitaet. Spektrum Akademischer Verlag, 2002.
[Lov78] Donald W. Loveland. Automated theorem proving: A logical basis. In Fundamental studies in computer science, volume 6, Amsterdam, New York, 1978. North−Holland Publishing Co.
[LR05] Peter Liggesmeyer and Dieter Rombach. Software Engineering eingebetteter Systeme. Spektrum Verlag, 2005.
[MDA02] The OMG’s Model Driven Architecture, January 2002.
[MDG+04] Bill Moore, David Dean, Anna Gerber, Gunnar Wagenknecht, and Philippe Vanderheyden. Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework. January 2004.
[Obj05] Object Management Group. UML 2.0 Superstructure Specification, August 2005. Document ptc/05−07−04.
[ONS06] Rainer Otterbach, Oliver Niggemann, and Joachim Stroop. SoftwareEntwicklung: Entwicklungsprozesse, Methoden und Werkzeuge. In H. Wallentowitz and K. Reif, editors, Handbuch Kraftfahrzeugelektronik Grundlagen − Komponenten − Systeme − Anwendungen. Vieweg Verlag, Wiesbaden, 2006.
[Pel] Jan Peleska. Verbesserte Softwarequalitaet durch effiziente Testprozesse. Technologie−Zentrum Informatik und Verified Systems International GmbH. Revision: 1.5.
[Pnu77] Amir Pnueli. The Temporal Logic of Programs. In Proceedings of the 18th IEEE Symposium on the Foundations of Computer Science, pages 46−57. IEEE, 1977.
[Rup04] Chris Rupp. Requirements−Engineering und −Management. Hanser Verlag, 2004.
[SAC03] Rachel L. Smith, George S. Avrunin, and Lori A. Clarke. From Natural Language Requirements to Rigorous Property Specification. In Workshop on Software Engineering for Embedded Systems (SEES 2003): From Requirements to Implementation, pages 40−46, September 2003.
[Sch00] Uwe Schoening. Logik fuer Informatiker. Spektrum−Akademischer Verlag, January 2000.
[Tha00] Georg E. Thaller. Software−Test: Verifikation und Validation. Verlag Heinz Heise, 2000.
[WHH05] Rupert Wiebel, Steffen Hoeh, and Stefan Hendrata. Specifiaction Requirements Interchange Format (RIF), 2005.
付録Ａ
時間論理ＲＴＣＴＬに対する要求メタモデルの要素のマッピング
ＲＴＣＴＬ表現に対するマッピングは誘導的に実施される。Iff（前提条件、expectedReaction（期待された応答））表記は、"precondition"（前提条件）と "expectedReaction"（期待される応答）との割り当て関係によって要素のインスタンスに到達することによって、メタモデルの Iff 要素のインスタンスが、以下のセマンティックに割り当てられることを意味する。このような割り当てによって到達する要素も、セマンティック定義を有する。たとえば、前提条件と expectedReaction との割り当てを使用して、BaseExpressionElement 種類の要素に到達する。この要素の具体的なインスタンスは、セマンティクスが定義されたＡＮＤ，ＯＲ，ＸＯＲ，ＮＯＴおよび InterfaceElement である。ＲＴＣＴＬ式は最終的に、すべての定義から得られる。
・BaseExpression（基本表現）
− Iff(precondition, expectedReaction) → precondition⇔expectedReaction（前提条件⇒期待される応答）
− Implies(precondition, expectedReaction) → precondition ⇒ expectedReaction（前提条件⇒期待される応答）
・BinaryOperator（バイナリ演算子）
Figure 2008171391
− OR(childOne, childTwo) → childOne∨childTwo（子供１∨子供２）
− AND(childOne, childTwo) → childOne∧childTwo（子供１∧子供２）
UnaryOperator（単独演算子）
− NOT(baseExpressionElement)→baseExpressionElement（基本表現要素ではない）
PointOfTime および LengthOfTime の InterfaceElement 要素に所属するマッピングを相互に独立して行うことはできない。というのも、共通の時間基準が必要とされるからである。したがって InterfaceElement のマッピングは、そのコンテキスト内で行われる（InterfaceElement(pointOfTime, lengthOfTime, valueCondition) )。
ｔをｋ∈Ｎであると仮定し、Ｖが、ＲＴＣＴＬにおいて関連する ValueCondition であると仮定する。このことは以下のように形成される。
・ ValueCondition（値条件）
− AtMostforValue(interfaceElement, valueElement) → interfaceElement ≦ valueElement（インタフェース要素≦値要素）
− AtLeastforValue(interfaceElement, valueElement) → interfaceElement ≧ valueElement（インタフェース要素≧値要素）
− ExactlyValue(interfaceElement, valueElement) → interfaceElement ＝ valueElement（インタフェース要素＝値要素）
− WithinValue(interfaceElement, lowerValue, upperValue) → lowerValue ≦ interfaceElement ≦ upperValue（低い値≦インタフェース要素≦高い値）
期待される応答の時間的条件は、前提条件で仕様化された時間的条件に対して異なる基準を有するので、時間的条件のセマンティックは前提条件と期待される応答とで異なって定義される。まず以下では、前提条件における時間的条件のセマンティックの定義を挙げる。
・ V is true at the point in time ExactTime(time) for duration ExactDuration(duration)（時点 ExactTime(time)において期間 ExactDuration(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time ExactTime(time) for duration AtLeast(duration)（時点 ExactTime(time)（時点）において少なくとも期間 AtLeast(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time ExactTime(time) for duration AtMost(duration)（時点 ExactTime(time)（時点）において最大でも期間 AtMost(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time ExactTime(time) for duration BetweenDuration(lowerDuration, upperDuration)（時点 ExactTime(time)（時点）において期間（小さい期間と大きい期間との間の期間）にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time Soonest(time) for duration ExactDuration(duration)（早くても時点 Soonest(time) において期間 ExactDuration(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time Soonest(time) for duration AtLeast(duration)（早くても時点 Soonest(time)（時点）において少なくとも期間 AtLeast(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time Soonest(time) for duration AtMost(duration)（早くても時点 Soonest(time)において最大でも期間 AtMost(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time Soonest(time) fuer for the duration BetweenDuration(lowerDuration, upperDuration)（早くても時点 Soonest(time) において期間（小さい期間と大きい期間との間の期間）にわたってＶは真である →
Figure 2008171391
・ V is true at the point in time NotLaterThan(time) for duration ExactDuration(duration)（遅くても時点 NotLaterThan(time) より遅くない時点で期間 ExactDuration(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at point in time NotLaterThan(time) for duration AtLeast(duration)（遅くても時点 NotLaterThan(time) より遅くない時点で少なくとも期間 AtLeast(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time NotLaterThan(time) for duration AtMost(duration)（遅くても時点 NotLaterThan(time) より遅くない時点で最大でも期間 AtLeast(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time NotLaterThan(time) for the duration BetweenDuration(lowerDuration, upperDuration)（遅くても時点 NotLaterThan(time) より遅くない時点で期間（小さい期間と大きい期間との間の期間）にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time BetweenTime(lowerTime,upperTime) for the duration ExactDuration(duration)（時点（小さい時点と大きい時点との間の時点）において期間 ExactDuration(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time BetweenTime(lowerTime,upperTime) for the duration AtLeast(duration)（時点（小さい時点と大きい時点との間の時点）において少なくとも期間 AtLeast(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time BetweenTime(lowerTime,upperTime) for the duration AtMost(duration)（時点（小さい時点と大きい時点との間の時点）において最大でも期間 AtMost(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time BetweenTime(lowerTime,upperTime) for the duration BetweenDuration(lowerDuration, upperDuration)（時点（小さい時点と大きい時点との間の時点）において期間（小さい期間と大きい期間との間の期間）にわたってＶは真である）→
Figure 2008171391
期待される応答における時間的条件は以下のように定義される。ｍは、前提条件のすべての条件が完了された最も早い時点であると仮定する。したがって時点ｍは、期待される応答の時間的条件の基準点である。
・ V is true at the point in time ExactTime(m+time) for duration ExactDuration(duration)（時点 ExactTime(m+time) において期間 ExactDuration(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time ExactTime(m+time) for duration AtLeast(duration) （時点 ExactTime(m+time) において少なくとも期間 AtLeast(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time ExactTime(m+time) for duration AtMost(duration)（時点 ExactTime(m+time) において最大でも期間 AtMost(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time ExactTime(m+time) for the duration BetweenDuration(lowerDuration, upperDuration)（時点 ExactTime(m+time) において期間（小さい期間と大きい期間との間の期間）にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time Soonest(m+time) for duration ExactDuration(duration)（早くても時点 Soonest(m+time) において期間 ExactDuration(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time Soonest(m+time) for duration AtLeast(duration)（早くても時点 Soonest(m+time) において少なくとも期間 AtLeast(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time Soonest(m+time) for duration AtMost(duration)（早くても時点 Soonest(m+time) において最大でも期間 AtMost(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time Soonest(m+time) for the duration BetweenDuration(lowerDuration, upperDuration)（早くても時点 Soonest(m+time) において期間（小さい期間と大きい期間との間の期間）にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time NotLaterThan(m+time) for duration ExactDuration(duration)（時点 NotLaterThan(m+time) より遅くない時点で期間 ExactDuration(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time NotLaterThan(m+time) for duration AtLeast(duration)（時点 NotLaterThan(m+time) より遅くない時点で少なくとも期間 AtLeast(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time NotLaterThan(m+time) for duration AtMost(duration)（時点 NotLaterThan(m+time) より遅くない時点で最大でも期間 AtMost(duration) にわたってＶは真である）→
Figure 2008171391
・ V is true at the point in time NotLaterThan(m+time) for the duration BetweenDuration(lowerDuration, upperDuration)（時点 NotLaterThan(m+time) より遅くない時点で期間（小さい期間と大きい期間との間の期間）にわたってＶは真である）→
Figure 2008171391
・Ｖは時点 BetweenTime(m+lowerTimeとm+upperTimeとの間の時点) において期間 ExactDuration(duration) にわたって真である→
Figure 2008171391
・ V is true at the point in time BetweenTime(m+lowerTime, m+upperTime) for the duration AtLeast(duration)（Ｖは時点 BetweenTime(m+lowerTimeとm+upperTimeとの間の時点) において少なくとも期間 AtLeast(duration) にわたって真である）→
Figure 2008171391
・ V is true at the point in time BetweenTime(m+lowerTime, m+upperTime) for the duration AtMost(duration)（Ｖは時点 BetweenTime(m+lowerTimeとm+upperTimeとの間の時点) において最大でも AtMost(duration) にわたって真である）→
Figure 2008171391
・ V is true at the point in time BetweenTime(m+lowerTime, m+upperTime) for the duration BetweenDuration(lowerDuration, upperDuration)（Ｖは時点 BetweenTime(m+lowerTimeとm+upperTimeとの間の時点) において期間（小さい期間と大きい期間との間の期間）にわたって真である）→
Figure 2008171391
全体のコンセプトを示す。 要求に基づくテスト生成を示す。 （［LR05］による）組み込みシステムを示す。 （［Bal98］に基づく）ウォーターフォールモデルを示す。 （［Bal98］による）Ｖサイクルを示す。 （［Bal98］に基づく）区分化を示す。 後部霧灯指示器を示す。 要求：車内照明を示す。 前提条件から期待される応答が行われるシステムの機能を示す。 品質保証の方法を示す。 テストのコンポーネントを示す。 組み込みシステムをテストするのに必要なコンポーネントの構造を示す。 モデルインザループおよびソフトウェアインザループを示す。 ハードウェアインザループを示す。 テストプロセスを示す。 ステップ２：（［Rup04］による）要求のコアを示す。 （［Rup04］による）ステップ４を示す。 （［Rup04］による）ステップ５を示す。 インタフェースオブジェクトとテストオブジェクトの変数と値と状態との間の関係を示す。 要求メタモデルのＵＭＬクラスダイヤグラムを示す。 メタモデルのインスタンスを示す。 シノニムを示す。 演算子を有する要求を示す。 演算子を有さない要求を示す。 複数の演算子を有する要求を示す。 演算子モデリングによるメタモデルからの抜粋を示す。 時間的条件を有するメタモデルからの抜粋を示す。 時間的条件を有する要求を示す。 すべての前提条件の完了後に期待される応答を示す。 前提条件に並行する期待される応答を示す。 時間依存性を示す。 期待される応答における Soonest（最も早くても）要素を示す。 異なるソフトウェア開発段階でのテストオブジェクト上の異なる種類のインタフェースを示す。 インタフェースのアクセス性を示す。 プラットフォーム独立性の要求からプラットフォーム固有のテストまでを示す。 プラットフォーム独立性のインタフェースオブジェクトと複数のプラットフォーム固有の変数とのマッピングを示す。 コンセプト全体のコンテクストにおけるテスト仕様書メタモデルを示す。 テスト仕様書メタモデルからの抜粋を示す。 並行してモデリングされる幾つかのテストシーケンスを含むテストシーケンスを示す。 異なる言語構文に対する期間のマッピングを示す。 Implies（暗黙的定義）要素の変換を示す。 Iff 要素の変換を示す。 InterfaceElement（インタフェース要素）要素の変換を示す。 全体的に否定された表現が、別個に否定される表現に変換される変換を示す。 バイナリ演算子の変換を示す。 時間記述において自由度を有する要求を示す。 オーバーラップする時間インターバルを示す。 本コンセプトのコンテクストにおけるテストインプリメンテーションを示す。 テスト仕様書のインスタンスと実行可能なテストのテストステップとのマッピングを示す。 テスト仕様書からテストインプリメンテーションまでを示す。 テストプラットフォームにおける変数および値に対する、テスト仕様書に由来するインタフェースオブジェクトおよび状態のマッピングを示す。 要求を示す。 テキスト構文を作成するためのグラフィカルユーザインタフェースを示す。 文構造に関する情報を有するＸＭＬドキュメントからの抜粋を示す。 要求の作成を示す。 時間的条件の仕様をスキップするためのスキップコマンドを示す。 テキスト構文の置換を示す。 演算子によって結合された付加的な文部分による要求の拡張を示す。 演算子の追加を示す。 ＮＯＴ演算子が追加されている。 擬似コードで表現されるアルゴリズムを示す。 ｖの後継者を示す。 複合体を示す。 要求記述のメタモデルを示す。 テスト仕様書の生成のスクリーン写真を示す。 テストツールにおけるテスト仕様書からテストインプリメンテーションまでを示す。 AutomationDesk におけるテスト仕様書からテストインプリメンテーションまでを示す。 AutomationDesk におけるテストシーケンス：基本要素を示す。 AutomationDesk におけるテストシーケンス：時間的観点を示す。 AutomationDesk におけるテストシーケンス：演算子を示す。 AutomationDesk におけるテストシーケンス：相対的依存性を示す。 「指示灯オン」のシナリオを示す。 「指示灯オフ」のシナリオを示す。 「エアバッグ」のシナリオを示す。 「車内照明」のシナリオを示す。

Claims (14)

  1. 組み込みシステムに対する要求記述を作成する方法であって、
    自動車電子制御ユニットを含むが、該自動車電子制御ユニットに制限されない形式の方法において、
    自然言語の語彙である選択可能なテキストセグメントがデータ処理システムに記憶されており、
    該テキストセグメントを相互に結合して、機械読み取り可能な要求記述を形成するための少なくとも１つの自然言語文を形成することができ、
    該自然言語文は英語で形成することができるが、英語で形成することは必須ではなく、
    各テキストセグメントを、該テキストセグメントと組み合わせることができる別のテキストセグメントのセットと結合することにより、選択されたテキストセグメントに関して該データ処理システムは、該組み合わせることができる別のテキストセグメントを、選択可能な形態で表示ユニット上に自動的に表現することを特徴とする方法。
  2. 前記テキストセグメントを、記憶された要求メタモデルのクラスに割り当て、
    該クラスにはＵＭＬクラスも含まれているが、ＵＭＬクラスに制限されない、請求項１記載の方法。
  3. 選択された各テキストセグメントごとに、要求メタモデルのインスタンスを、該テキストセグメントに結合された要求メタモデルのインスタンスクラスによって完成する、請求項２記載の方法。
  4. 各テキストセグメントを前記要求メタモデルのクラスに割り当て、
    各クラスごとに、少なくとも１つの別のクラスとの少なくとも１つの関連性と関連性の方向とに関する情報を記憶することにより、単方向の関係によって、該クラスに割り当てられたテキストセグメントの文法的に適正な配置を定義するクラスシーケンスを形成する、請求項１から３までのいずれか１項記載の方法。
  5. 選択されたテキストセグメントと、組み合わせ可能なテキストセグメントのセットとの結合および表現を行うために、前記要求メタモデルにおける該選択されたテキストセグメントに割り当てられたクラスを決定し、その後、単方向の関係にしたがってこの特定のクラスに続く少なくとも１つのクラスを見つけ、その後、見つけられた後継者クラスのうち少なくとも１つの後継者クラスの要素をまとめて、そのつど割り当てられるテキストセグメントによって要素が表現されるセットを構成し、その後、該テキストセグメントを前記表示ユニット上で、場合によっては選択可能なメニュー項目として表示するが、該選択可能なメニュー項目に制限されない、請求項１から４までのいずれか１項記載の方法。
  6. 必須のテキストセグメントのセットと可能なテキストセグメントのセットとを表示し、該可能なテキストセグメントのセットを選択しないでスキップすることができ、
    該可能なテキストセグメントのセットには、時間仕様に関するテキストセグメントを含むが、該時間仕様に関するテキストセグメントに制限されない、請求項１から５までのいずれか１項記載の方法。
  7. 形成された要求記述において、すでに選択されたテキストセグメントを択一的なテキストセグメントに置換することができ、そのためには、置換すべきテキストセグメントの選択で可能な択一的なテキストセグメントのセットを自動的に選択可能な形態で表示し、該置換すべきテキストセグメントを自動的に、表示された該セットからの択一的なテキストセグメントの選択に基づいて置換する、請求項１から６までのいずれか１項記載の方法。
  8. 自然言語の要求記述の作成後に前記データ処理システムは、プラットフォームに依存しない自然言語のテスト仕様書に該要求記述を変換するための変換を行う、請求項１から７までのいずれか１項記載の方法。
  9. 前記変換を実行するために、並行して形成された前記要求メタモデルのインスタンスをモデル変換によってテストモデルのインスタンスに変換し、
    該テストモデルのインスタンスへの変換を行うために、該要求メタモデルのインスタンスの要素のうち少なくとも幾つかをテストメタモデルのインスタンスの要素に変換することにより、得られた該テストメタモデルのインスタンスを前記データ処理システムの表示ユニット上に自然言語のテスト仕様書として表示し、こうするために、自然言語のテキストセグメントを該テストメタモデルのインスタンスの要素に割り当てる、請求項８記載の方法。
  10. 条件を記述する要求メタモデルのインスタンスの要素を、前記組み込みシステムの入力側の値割り当てに影響するテストメタモデルのインスタンスの要素に変換し、
    条件に対する応答を記述する要求メタモデルのインスタンスの要素を、出力における値を検査するテストメタモデルのインスタンスの要素に変換する、請求項８または９記載の方法。
  11. 不精確な時間的観点を記述する要求メタモデルのインスタンスの要素を、時間の点で具体化することができる自由度を含むテストメタモデルのインスタンスの要素に変換する、請求項８から１０までのいずれか１項記載の方法。
  12. テストメタモデルのプラットフォーム非依存性のインスタンスからプラットフォーム依存性のテストプログラムを生成する、請求項８から１１までのいずれか１項記載の方法。
  13. 時間的な自由度を生成前に具体化する、請求項１２記載の方法。
  14. データ媒体に記憶されたコンピュータプログラム製品において、
    データ処理システム上で実行され、請求項１から１３までのいずれか１項記載の方法を実行することを特徴とする、コンピュータプログラム製品。
JP2007277493A 2006-10-25 2007-10-25 組み込みシステムのための要求記述を生成する方法 Withdrawn JP2008171391A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102006050112A DE102006050112A1 (de) 2006-10-25 2006-10-25 Verfahren zur Erstellung einer Anforderungsbeschreibung für ein eingebettetes System

Publications (1)

Publication Number Publication Date
JP2008171391A true JP2008171391A (ja) 2008-07-24

Family

ID=39244244

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007277493A Withdrawn JP2008171391A (ja) 2006-10-25 2007-10-25 組み込みシステムのための要求記述を生成する方法

Country Status (4)

Country Link
US (1) US7970601B2 (ja)
JP (1) JP2008171391A (ja)
DE (1) DE102006050112A1 (ja)
FR (1) FR2907933B1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012513050A (ja) * 2008-12-19 2012-06-07 インターナショナル・ビジネス・マシーンズ・コーポレーション データ・メタモデルから音声ユーザ・インタフェース・コードを生成するための方法およびシステム
US10732938B2 (en) 2015-10-30 2020-08-04 Kabushiki Kaisha Toshiba System design apparatus and method

Families Citing this family (80)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4941040B2 (ja) * 2007-03-26 2012-05-30 富士通株式会社 テスト仕様書生成プログラム、およびテスト仕様書生成装置
US9454738B1 (en) 2007-06-25 2016-09-27 The Boeing Company Methods and systems for correspondence pattern automation of scalable feed forward processes
US7899768B2 (en) * 2007-06-29 2011-03-01 The Boeing Company Methods and systems for constructing a scalable hierarchical feed-forward model for fabricating a product
US8581904B2 (en) 2010-08-31 2013-11-12 The Boeing Company Three-dimensional display of specifications in a scalable feed forward network
US20100058198A1 (en) * 2008-04-16 2010-03-04 Modria, Inc. Collaborative realtime planning using a model driven architecture and iterative planning tools
US20100030546A1 (en) * 2008-07-29 2010-02-04 Freescale Semiconductor, Inc. Gui-facilitated simulation and verification for vehicle electrical/electronic architecture design
US8359576B2 (en) * 2008-11-14 2013-01-22 Fujitsu Limited Using symbolic execution to check global temporal requirements in an application
US8631046B2 (en) 2009-01-07 2014-01-14 Oracle International Corporation Generic ontology based semantic business policy engine
EP2221697B1 (de) * 2009-02-20 2020-01-15 dSPACE digital signal processing and control engineering GmbH Verfahren zum Test eines Steuergeräts und Testvorrichtung
US9672478B2 (en) 2009-02-26 2017-06-06 Oracle International Corporation Techniques for semantic business policy composition
DE102009011724A1 (de) * 2009-03-04 2010-09-09 Siemens Aktiengesellschaft Verfahren zum Erstellen von Anforderungsspezifikationen für Prozessleitsysteme der Kraftwerksleittechnik
US20100235807A1 (en) * 2009-03-16 2010-09-16 Hitachi Data Systems Corporation Method and system for feature automation
JP5536518B2 (ja) * 2009-04-23 2014-07-02 インターナショナル・ビジネス・マシーンズ・コーポレーション システムの自然言語仕様から当該システム用のシステム・モデル化メタモデル言語モデルを自動的に抽出するための方法、装置及びコンピュータ・
US8862457B2 (en) * 2009-07-02 2014-10-14 International Business Machines Corporation Method and system for smart mark-up of natural language business rules
US8381178B2 (en) * 2009-07-02 2013-02-19 International Business Machines Corporation Intuitive visualization of Boolean expressions using flows
US8713012B2 (en) * 2009-07-02 2014-04-29 International Business Machines Corporation Modular authoring and visualization of rules using trees
US20110041116A1 (en) * 2009-08-14 2011-02-17 Gm Global Technology Operations, Inc. Formal analysis driven based evolution of requirements specifications
WO2011031328A2 (en) * 2009-09-14 2011-03-17 Ldra Technology, Inc. Systems and methods for management of projects for development of embedded systems
US8365059B2 (en) * 2009-11-03 2013-01-29 Oto Technologies, Llc E-reader semantic text manipulation
US8949236B2 (en) 2010-02-26 2015-02-03 Oracle International Corporation Techniques for analyzing data from multiple sources
GB201008332D0 (en) * 2010-05-19 2010-07-07 Bae Systems Plc System validation
US9069559B2 (en) * 2010-06-30 2015-06-30 International Business Machines Corporation Modularizing steps within a UML user model interaction pattern
US9400958B2 (en) 2010-06-30 2016-07-26 Oracle International Corporation Techniques for display of information related to policies
AU2014201250B2 (en) * 2011-04-21 2015-01-15 Accenture Global Services Limited Analysis system for test artifact generation
US8935654B2 (en) * 2011-04-21 2015-01-13 Accenture Global Services Limited Analysis system for test artifact generation
US9378120B2 (en) * 2011-11-09 2016-06-28 Tata Consultancy Services Limited Automated test execution plan derivation system and method
US9262404B2 (en) * 2012-01-12 2016-02-16 Accenture Global Services Limited System for generating test scenarios and test conditions and expected results
EP2642434A1 (en) * 2012-03-23 2013-09-25 Tata Consultancy Services Limited Project delivery system
EP2662780A1 (de) 2012-05-11 2013-11-13 Orange Moon Produktions GmbH & Ko KG Verfahren zur programmgestützten Erzeugung einer korrekten und kompletten technischen Spezifikation
US8762134B2 (en) 2012-08-30 2014-06-24 Arria Data2Text Limited Method and apparatus for situational analysis text generation
US9336193B2 (en) 2012-08-30 2016-05-10 Arria Data2Text Limited Method and apparatus for updating a previously generated text
US9405448B2 (en) 2012-08-30 2016-08-02 Arria Data2Text Limited Method and apparatus for annotating a graphical output
US8762133B2 (en) 2012-08-30 2014-06-24 Arria Data2Text Limited Method and apparatus for alert validation
US9135244B2 (en) 2012-08-30 2015-09-15 Arria Data2Text Limited Method and apparatus for configurable microplanning
US9355093B2 (en) 2012-08-30 2016-05-31 Arria Data2Text Limited Method and apparatus for referring expression generation
US8949670B1 (en) * 2012-09-26 2015-02-03 Emc Corporation Method and system for translating mind maps to test management utility test cases
US9600471B2 (en) 2012-11-02 2017-03-21 Arria Data2Text Limited Method and apparatus for aggregating with information generalization
WO2014076524A1 (en) 2012-11-16 2014-05-22 Data2Text Limited Method and apparatus for spatial descriptions in an output text
WO2014076525A1 (en) 2012-11-16 2014-05-22 Data2Text Limited Method and apparatus for expressing time in an output text
US10115202B2 (en) 2012-12-27 2018-10-30 Arria Data2Text Limited Method and apparatus for motion detection
WO2014102569A1 (en) 2012-12-27 2014-07-03 Arria Data2Text Limited Method and apparatus for motion description
US9501390B1 (en) * 2013-01-02 2016-11-22 Amazon Technologies, Inc. Enhancing automated mobile application testing
US20140195208A1 (en) * 2013-01-09 2014-07-10 GM Global Technology Operations LLC Efficient partition refinement based reachability checking for simulinks/stateflow models
US10776561B2 (en) 2013-01-15 2020-09-15 Arria Data2Text Limited Method and apparatus for generating a linguistic representation of raw input data
US20140214396A1 (en) * 2013-01-28 2014-07-31 International Business Machines Corporation Specification properties creation for a visual model of a system
EP2800013B1 (en) * 2013-04-30 2015-09-09 Systemite AB Integration database framework
US9727619B1 (en) 2013-05-02 2017-08-08 Intelligent Language, LLC Automated search
US9946711B2 (en) 2013-08-29 2018-04-17 Arria Data2Text Limited Text generation from correlated alerts
US9244894B1 (en) 2013-09-16 2016-01-26 Arria Data2Text Limited Method and apparatus for interactive reports
US9396181B1 (en) 2013-09-16 2016-07-19 Arria Data2Text Limited Method, apparatus, and computer program product for user-directed reporting
US9286195B2 (en) * 2013-09-23 2016-03-15 Globalfoundries Inc. Derivation of generalized test cases
FR3017474A1 (fr) * 2014-02-10 2015-08-14 Commissariat Energie Atomique Saisie assistee de regles dans une base de connaissance
US9940679B2 (en) * 2014-02-14 2018-04-10 Google Llc Systems, methods, and computer-readable media for event creation and notification
FR3018118B1 (fr) * 2014-02-28 2016-04-29 Airbus Helicopters Procede de test d'un systeme electronique
US9424290B2 (en) * 2014-03-11 2016-08-23 Wipro Limited System and method for data validation
US10664558B2 (en) 2014-04-18 2020-05-26 Arria Data2Text Limited Method and apparatus for document planning
US10503480B2 (en) * 2014-04-30 2019-12-10 Ent. Services Development Corporation Lp Correlation based instruments discovery
US9665454B2 (en) * 2014-05-14 2017-05-30 International Business Machines Corporation Extracting test model from textual test suite
US10108536B2 (en) * 2014-12-10 2018-10-23 General Electric Company Integrated automated test case generation for safety-critical software
US9639450B2 (en) 2015-06-17 2017-05-02 General Electric Company Scalable methods for analyzing formalized requirements and localizing errors
US9940222B2 (en) 2015-11-20 2018-04-10 General Electric Company System and method for safety-critical software automated requirements-based test case generation
KR101653797B1 (ko) 2016-04-15 2016-09-09 스튜디오씨드코리아 주식회사 프로토타입 제작 방법 및 그 장치
US10445432B1 (en) 2016-08-31 2019-10-15 Arria Data2Text Limited Method and apparatus for lightweight multilingual natural language realizer
US10467347B1 (en) 2016-10-31 2019-11-05 Arria Data2Text Limited Method and apparatus for natural language document orchestrator
US10810111B2 (en) 2016-11-02 2020-10-20 Hitachi Automotive Systems, Ltd. Computer system, test method, and recording medium
US10460044B2 (en) * 2017-05-26 2019-10-29 General Electric Company Methods and systems for translating natural language requirements to a semantic modeling language statement
EP3493051A1 (en) * 2017-11-30 2019-06-05 The MathWorks, Inc. System and methods for evaluating compliance of implementation code with a software architecture specification
US10636419B2 (en) * 2017-12-06 2020-04-28 Sony Interactive Entertainment Inc. Automatic dialogue design
DE102018003142A1 (de) 2017-12-13 2019-06-13 The Mathworks, Inc. Automatische Einstellung von Multitasking-Konfigurationen für ein Codeprüfsystem
US10073763B1 (en) * 2017-12-27 2018-09-11 Accenture Global Solutions Limited Touchless testing platform
US10909013B2 (en) * 2018-10-16 2021-02-02 Rohde & Schwarz Gmbh & Co. Kg TTCN-based test system and method for testing test-cases, non-transitory computer-readable recording medium
CN110738185B (zh) * 2019-10-23 2023-07-07 腾讯科技（深圳）有限公司 表单对象的识别方法、装置及存储介质
WO2021219838A1 (en) * 2020-04-30 2021-11-04 Koninklijke Philips N.V. Methods and systems for user data processing
US20220206929A1 (en) * 2020-12-31 2022-06-30 Sauce Labs Inc. Managing a global network of virtual testers
DE102021201658A1 (de) 2021-02-18 2022-08-18 Continental Automotive Gmbh Testausführungssystem, Testspezifikationsvorrichtung und Verfahren zum Betreiben eines Testausführungssystems
US20220309411A1 (en) * 2021-03-26 2022-09-29 Microsoft Technology Licensing, Llc Business process analysis
DE102021208759A1 (de) 2021-08-11 2023-02-16 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Trainieren eines Algorithmus des maschinellen Lernens zum Erzeugen von Testspezifikationen zum Testen eines auf Software basierenden Systems
DE102022000208A1 (de) * 2022-01-20 2023-07-20 GS Licence Pool UG (haftungsbeschränkt) Verfahren zur Computer gestützten Prüfung einer Anforderungsspezifikation eines technischen Prozesses
US12045602B2 (en) * 2022-03-25 2024-07-23 Woven By Toyota, Inc. Correctness verification system, method, device, and program
GB2624866A (en) * 2022-11-29 2024-06-05 Jaguar Land Rover Ltd Apparatus and method for use with a test asset

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2143509T3 (es) * 1992-09-04 2000-05-16 Caterpillar Inc Sistema integrado de edicion y traduccion.
US6144938A (en) * 1998-05-01 2000-11-07 Sun Microsystems, Inc. Voice user interface with personality
US6275789B1 (en) * 1998-12-18 2001-08-14 Leo Moser Method and apparatus for performing full bidirectional translation between a source language and a linked alternative language
WO2001067232A2 (en) * 2000-03-09 2001-09-13 Koninklijke Philips Electronics N.V. Method for developing complex systems
US7085708B2 (en) * 2000-09-23 2006-08-01 Ravenflow, Inc. Computer system with natural language to machine language translator

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012513050A (ja) * 2008-12-19 2012-06-07 インターナショナル・ビジネス・マシーンズ・コーポレーション データ・メタモデルから音声ユーザ・インタフェース・コードを生成するための方法およびシステム
US10732938B2 (en) 2015-10-30 2020-08-04 Kabushiki Kaisha Toshiba System design apparatus and method

Also Published As

Publication number Publication date
US7970601B2 (en) 2011-06-28
FR2907933B1 (fr) 2017-07-21
FR2907933A1 (fr) 2008-05-02
DE102006050112A1 (de) 2008-04-30
US20080109475A1 (en) 2008-05-08

Similar Documents

Publication Publication Date Title
US7970601B2 (en) Method of creating a requirement description for testing an embedded system
Ab. Rahim et al. A survey of approaches for verifying model transformations
Denney et al. Tool support for assurance case development
Naujokat et al. CINCO: a simplicity-driven approach to full generation of domain-specific graphical modeling tools
Lúcio et al. Model transformation intents and their properties
Friedenthal et al. A practical guide to SysML: the systems modeling language
Broy et al. Seamless model-based development: From isolated tools to integrated model engineering environments
Hou et al. Using SCL to specify and check design intent in source code
Drave et al. SMArDT modeling for automotive software testing
CN101689111A (zh) 软件需求验证的自动化管理
Casse SysML in action with Cameo systems modeler
Rocha Silva et al. Ensuring the consistency between user requirements and task models: A behavior-based automated approach
Song Systematic integration of design methods
Elekes et al. Assessing the specification of modelling language semantics: a study on UML PSSM
Ruppel System behavior models: a survey of approaches
Lin A model transformation approach to automated model evolution
Khwaja et al. A property based specification formalism classification
Sobral et al. Assessing situation models with a lightweight formal method
Justice Natural language specifications for safety-critical systems
Kallel et al. Generating reusable, searchable and executable “architecture constraints as services”
Kutty et al. Visual tools for temporal reasoning
Clark et al. Response to UML 2.0 request for information
Dascalu Combining semi-formal and formal notations in software specification: An approach to modelling time-constrained systems.
Luo et al. Incremental Witness Generation for Branching-Time Logic CTL
Snook et al. Rigorous engineering of product-line requirements: a case study in failure management

Legal Events

Date Code Title Description
A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20090925