概要

以下は、LabVIEWオブジェクト指向プログラミングについてのよくあるご質問をまとめたものです。

LabVIEWオブジェクト指向プログラミングの利点

1.  一般的に、オブジェクト指向プログラミングとは何ですか? また、なぜ使用するのですか?

オブジェクト指向プログラミングは、さまざまなプログラミング言語において手続き型プログラミングよりも優れたアーキテクチャであることが示されてきました。コード内の複数箇所間でのわかりやすいインタフェースを可能にし、デバッグが容易で、大規模なプログラミングへの拡張が容易です。

出典 ウィキペディア：
オブジェクト指向プログラミングは、「コンピュータプログラムは相互に働きかける個々の単位（オブジェクト）の集合体で形成されていると見なすことができる」という概念に基づいている。これは、プログラムを「関数の集合体あるいは単にコンピュータに対する指示のリスト」と見なす従来の見方とは対照的である。各オブジェクトはそれぞれメッセージを受信し、データを処理し、メッセージを他のオブジェクトに送信することができる。各オブジェクトは、明確な役割や責任を持つ独立した小さな機械または実行者と見なすことができる。

オブジェクト指向プログラミングは、プログラミングにおける柔軟性と保守性の向上を促進するとされており、大規模ソフトウェアエンジニアリングにおいて一般的に使用されています。またオブジェクト指向プログラミングの提唱者は、オブジェクト指向プログラミングはコンピュータプログラミング学習者にとって従来のアプローチよりも学習しやすく、オブジェクト指向プログラミングのアプローチは開発と保守がよりシンプルであることが多く、複雑な状況や手続きを他のプログラミング手法よりも直接的に分析/コード実装/理解できるとしています。

2. C++のオブジェクト指向プログラミングとLabVIEWのオブジェクト指向プログラミングの違いは何ですか?

C++はテキストベースの関数型言語で、LabVIEWはグラフィカルなデータフロー言語です。この違いにより、オブジェクト指向機能の表現方法に違いが生じます。

• LabVIEWにはすべてのオブジェクトに根本的な先祖クラスがあります。C++にはありません。
• C++にはコンストラクタがありますが、LabVIEWには不要です。
• C++にはデストラクタがありますが、LabVIEWには不要です。
• C++にはオブジェクトをパラメータとして渡すための、リファレンスによる構文と値による構文の両方があります。LabVIEWには値による構文しかありません。リファレンスは他の機能により作成されます。
• LabVIEWは自動的にデータ変異を行うため、クラスが編集されていてもユーザは古いデータを読み出すことができます。C++では自動的にデータ変異が行われないため、ユーザはバージョンの変更を追跡しデータの変異コードを書く必要があります。
• C++にはテンプレートがありますが、LabVIEW 8.2以降にはありません。
• C++には純粋仮想関数がありますが、LabVIEW 8.2以降にはありません。
• C++には複数の継承がありますが、LabVIEWにはありません。

これらの相違点に関する詳細は、Developer Zoneチュートリアル『LabVIEW オブジェクト指向プログラミング：設計における判断』を参照してください。

3. LabVIEWオブジェクト指向プログラミングの主な利点は何ですか?

A. LabVIEWの新規ユーザにとっての利点は何ですか?
1. LabVIEWの強みは、コンピュータサイエンスの技術をプログラマ以外の人にも利用可能にすることです。LabVIEWオブジェクト指向プログラミングは最も先進的なプログラミング技術を新規ユーザに提供します。オブジェクト指向では計画段階においてより多くのコミットメントが必要であるため、一般的に、大規模ソフトウェアの開発に採用される場合が多いです。
2. オブジェクト指向は、機能仕様で使用されている用語を使用してソフトウェア計画を行います。機能の説明には、スクリーン上に表示する項目や機能が操作を行うデータが記載されます。オブジェクト指向では、データベースオブジェクト、ボタンオブジェクト、電子メールオブジェクトといった用語ごとに関連コードを書くことができます。

B. 経験のあるグラフィック言語プログラマにとっての利点は何ですか?
1. デバッグが容易 ― コードがモジュール化されているため、バグが存在するかもしれないVIを絞ることができます。
2. 保守が容易 ― オブジェクト指向により、時間の経過とともに開発者の生産性が上がってゆきます。開発者は機能を追加したい分野を容易に識別することができ、関係のないコード箇所でエラーを招く可能性が少なくなります。

4. LabVIEWオブジェクト指向プログラミングを使用すべきなのはどのような場合ですか?

• 長期間にわたって保守されるVI
• 大規模アプリケーション
• 複数の開発者が同一のVIを作業

5. LabVIEWオブジェクト指向プログラミングを使用すべきでないのはどのような場合ですか?

どのようにウイルスが分類されています

• 開発期間の短いユーザ
• 計測を目的とした単一VIを素早く開発するような場合、LabVIEWクラスは過度の作業

6. LabVIEWオブジェクト指向プログラミングの使用例を教えてください?

タスクベースのアプローチとオブジェクト指向のアプローチを比較しているテストおよび計測の例は、LabVIEW 8.2以降に含まれる「Board Testing」サンプルプロジェクトを参照してください。

labview\examples\lvoop\BoardTesting\Board Testing.lvproj

LabVIEWオブジェクト指向プログラミングの使用法

1. LabVIEWオブジェクト指向の使用法についてさらに学習したいのですが、トレーニング教材、アプリケーションノート、チュートリアル、デモスクリプト、サンプルなどはありますか?

LabVIEW 8.2以降には、LabVIEWオブジェクト指向プログラミングのサンプルが含まれています。このドキュメントの追加情報セクションも参照してください。

2. 既存のプロジェクトをLabVIEWオブジェクト指向プログラミングに移行するにはどうしたらよいですか?

既存のタイプ定義をLabVIEWクラスに変換するところから開始します。プロジェクトエクスプローラウィンドウでタイプ定義を右クリックし、ショートカットメニューから制御器の中身をクラスに変換を選択します。LabVIEWクラスの作成に関する詳細は『LabVIEWヘルプ』を参照してください。

メモ：制御器のデフォルト値と定数は変換時に保持されません。タイプ定義の詳細にアクセスするには、そのタイプ定義にアクセスする必要のあるクラスにVIを追加してください。オブジェクト指向プログラミングの基本は、操作するデータに基づいてVIをグループ化することです。オブジェクト指向設計に関する詳細は、追加情報セクションにあるNI Week 2006の2つのプレゼンテーション（英語）を参照してください。

3. LabVIEWオブジェクト指向プログラミングで「リファレンス」を実装するにはどうすればよいですか。

LabVIEW 8.2以降で含まれる「ReferenceObject」サンプルプロジェクトを参照してください。

labview\examples\lvoop\ReferenceObject\ReferenceObject.lvproj

基本的には、クラスのプライベートデータをリファレンスにします。このサンプルでは、単一要素のキューリファレンスを使用してそれを実装する方法を示しています。GOOPツールキットを使用することもできます（以下のLabVIEWオブジェクト指向プログラミングとGOOPツールキットセクションを参照してください）。

4. LabVIEWクラスはLabVIEW Real-Timeやその他の非デスクトップターゲットでも動作しますか?

LabVIEW 8.2以降では、LabVIEWクラスはLabVIEW Real-Timeやその他の非デスクトップターゲットでは動作しません。

5. VIを閉じると、なぜVI用の「変更を保存」ダイアログボックスと、LabVIEWクラス用の「変更を保存」ダイアログボックスが表示されるのですか?なぜ、すべてを保存するダイアログボックスが1つ表示されないのですか?

VIを閉じる際、LabVIEWはそのVIが閉じられることにより使用されなくなるサブVIをすべて把握しているため、それらを保存するかどうかを尋ねるダイアログボックスを表示します。一方、クラスはすべてのデータインスタンスがメモリからなくなるまでメモリに保持されるため、任意のVIが閉じられることでデータの最後のインスタンスが閉じられるかどうかについてはLabVIEWは把握できません。VIのコード内にクラスへのリファレンスがない場合でも、どこかのバリアント内にクラスのインスタンスが含まれる可能性が� ��ります。

すべてのVIがアイドル状態である場合、何個のクラスインスタンスがこれらのVIとともになくなるのか、それがメモリ内に残っているすべてのクラスインスタンスにあたるのかを、LabVIEWは把握することができます。LabVIEWは、クラスがVIとともにメモリからなくなることを把握しているため、VIやライブラリに対する変更を保存するかを尋ねる「変更を保存」ダイアログボックスにおいて、クラスに対する変更を保存するかについても一緒に尋ねることができます。ただし、いずれかのVIが実行中の場合、インスタンスの数は常に変動しています。またVIの実行中には、データがキューやノーティファイアなど検索不可能な場所に隠れてしまう可能性があります。VIがアイドル状態になった場合にのみこれらの追加スペースが空になります。ま た、LabVIEWが既にチェックし終わった場所に、実行中のVIによって新規インスタンスが作成されてしまう場合もあります。このため、VIの実行中にインスタンスを数えることは不可能です。

LabVIEWは変更を保存するかどうかを尋ねた後で実行中のVIを中断するため、その時点では、クラスがメモリからなくなるかどうかはLabVIEWには判断できません。すべてのVIがアイドル状態にありLabVIEWがデータの検索を行うことができたとしても、データの検索には非常に多くの時間がかかるため、LabVIEWは検索を試みることはありません。したがってほとんどの場合、VIを閉じるとクラスに対する変更を保存するかどうかを尋ねる「変更を保存」ダイアログボックスが別に表示されます。

どのように癌の満月はあなたに影響しません

プロジェクトを閉じる場合のみ、LabVIEWがVIやライブラリとともにクラスを閉じることができ「変更を保存」ダイアログボックスが1回のみ表示されます。この場合、プロジェクト内のすべてのVIが閉じられるため、LabVIEWはクラスのすべてのデータインスタンスを考慮することなく廃棄してよいということが判断できます。

LabVIEWオブジェクト指向プログラミングとGOOPツールキット

1. GOOPツールキットとは何ですか?

GOOPツールキット 1.0（英語）はナショナルインスツルメンツのウェブサイトから無料でダウンロードいただけます。.このツールキットの最新バージョンはEndevoのウェブサイトからご購入いただけます。

2. LabVIEW 8.2以降でもGOOPを使用できますか?

はい、使用できます。

3. Endevo社のGOOPツールキットとLabVIEWオブジェクト指向プログラミングを一緒に使用するとどのように動作しますか?それらを一緒に使用すべき時、あるいはEndevo社のGOOPツールキットではなくLabVIEWオブジェクト指向プログラミングを使用すべき時はどのような場合ですか?またその使用法について教えてください。

多くのユーザはアプリケーションにはLabVIEWクラスが最適であると答えるでしょう。LabVIEWクラスは、ユーザにとって馴染みの深い「クラスタ」のように動作します。

リファレンスは、並列に実行する複数コードセクション間の通信に使用されます。システムリソースのUMLモデリングを行っているお客様にとってリファレンスモデルは非常に有益になるため、GOOPクラスを作成したいと思われるでしょう。リファレンスは、グラフやツリーデータストラクチャを作成する際にも有益です。ただしこのような場合も、GOOPクラスの核となるデータフィールドはLabVIEWクラスでも提供されている可能性があります。並列コードセクション間の通信にリファレンスやその他の手段を使用するには、ロック、競合状態、その他の複雑な内容について知っておく必要があります。

リファレンスモデルを使用すると、メモリ内でそのクラスが確実に重複しないようにすることができます。これは、多くのメモリを必要とするクラスの場合に有益です。

4. Endevo社のGOOPツールキットを使用しているアプリケーションをLabVIEWオブジェクト指向プログラミングに移行すべきですか?GOOPツールキットを使用している顧客の既存アプリケーションをLabVIEWオブジェクト指向プログラミングで実装すべき場合はどのような時ですか?

既存のGOOPクラスをLabVIEWクラスとして書き直す必要性はありません。1つには、動作しているコードを重大な理由もなく破棄すべきでありませんし、GOOPクラスはLabVIEW 8.2以降では引き続き動作します。実際のところ、GOOPツールキットはLabVIEWで書かれているのです。さらに、リファレンスによって動作しているコードを値によって動作するコードに変更するには、極めて膨大な作業が発生します。

移行する理由のひとつは、パフォーマンスです。オブジェクトに対する大量のオーバーヘッドは、各関数の呼び出しにおいてリファレンス検索、インスタンスのロック、データ抽出が行われる際に発生します。GOOPツールキットではこのオーバーヘッドを極力減らすように優れた設計が行われていますが、オーバーヘッドがあることは否めません。さらに、リファレンスを使用しなければ並列処理が可能な多くの操作が、リファレンスを使用することで並列処理できなくなります。リファレンスによって動作する必要がなくパフォーマンスを重視するクラスがある場合は、GOOPクラスからLabVIEWクラスへの移行を検討してもよいでしょう。

5. GOOPを使用しているアプリケーションをLabVIEWオブジェクト指向プログラミングに移行するにはどうすればよいですか?

この質問に対する回答は状況によって異なります。LabVIEWでは、自動変換を行う方法が提供されていません。

6. LabVIEWオブジェクト指向プログラミングとEndevo社のGOOPツールキットにパフォーマンス上の違いはありますか?

同じ状況下においては、LabVIEWクラスはGOOPクラスよりも優れたパフォーマンスを発揮します。これはLabVIEWクラスがデータフローに沿っており、ダイナミックディスパッチのネイティブコンパイラであるためです。とはいえ、同等の状況はほとんど存在しません。LabVIEWクラスはクラスタを置換えてデータフローを改善するように設計されています。GOOPクラスはLabVIEWにリファレンスを追加する手段です。2つのクラスは異なる目的を果たしています。新規クラスの作成時には、パフォーマンスではなくクラスが必要とする機能によって、GOOPクラスかLabVIEWクラスかを決定すべきです。

技術的詳細

1. タイプ定義されたクラスタの代わりにLabVIEWクラスを使用することで得られるパフォーマンス上の違いは何ですか?

さまざまな種類のコンピュータにおけるベンチマークでは、この2つのパフォーマンスはほとんど同じであることが明らかになっています。パフォーマンスに関する詳細については、下の質問を参照してください。 

2. 通常のサブVI呼び出しと比較して、サブVIの動的呼び出しを行う場合のパフォーマンス上のオーバーヘッドは何ですか?

ヘルツ（Hz ）とは何ですか

サブVIのダイナミックディスパッチを行うと、どのサブVIを呼び出すかをLabVIEWが検索するため、ある程度の小さなオーバーヘッドが発生します。オーバーヘッドの量は一定であり、より多くのクラスを追加しても、クラスにより多くの動的VIを追加しても増加しません。LabVIEWが呼び出す実際のサブVIの機能に合致させるため、サブVI呼び出しによってパラメータのコピーが余分に作成されてしまうと、パフォーマンスに影響を与える可能性があります。呼び出すことを想定していないダイナミックVIにおいてもフロントパネル上の入力端子をフロントパネル上の出力端子に配線することによって、この問題を回避することができます（たとえば、子VIによって上書きされるコネクタぺーンを定義するためだけに存在する親VIなど）。ダイナミ� ��クディスパッチにおいてオーバーヘッドパフォーマンスがどのようにして一定に抑えられているかに関する詳細は、Developer Zoneチュートリアル『LabVIEW オブジェクト指向プログラミング：設計における判断』を参照してください。

3. LabVIEWクラスライブラリとプロジェクトライブラリの相違点は何ですか?

LabVIEWクラスはプロジェクトライブラリの一種ですが、データタイプの定義に特化しています。LabVIEWクラスは、プロジェクトライブラリと同様に、メンバーVIのスコープとネームスペースを定義します。VIは1つのLabVIEWクラスにのみ所有されます。

LabVIEWクラスには、プライベートデータ制御器が含まれます。プライベートデータ制御器はクラスのデータ値を定義します。この特別な制御器は他の種類のライブラリには含まれません。この制御器はクラスファイル内に格納されます。LabVIEWクラスには、ライブラリの持つすべてのプロパティ以外に追加のプロパティもあります。追加のプロパティは、クラスプロパティダイアログボックスの継承ページ、プローブページ、ワイヤの外観ページで確認できます。

プロジェクトライブラリにはあってLabVIEWクラスにはない唯一の機能は、サブライブラリを持てるかどうかだけです。

4. LabVIEWオブジェクト指向プログラミングを使用すると、いつ何がロードされますか?