この記事の目的
- LabVIEWによるソフトウェア開発において、推奨される開発手法の一例を知ることができる。
- 推奨の開発手法を知ることで、規模の大きなプログラムでもLabVIEWが優れた開発環境であることを理解する。
- 同記事の内容の実施有無を問い合わせることで、開発委託先の開発力を判断できる
「LabVIEWのワナ」とは
NI社のLabVIEWは、視覚的・直観的にプログラミングを行う事ができます。そのため、小規模なプログラム(単純な実験系で使用される様なもの)であれば、短期間でプログラミングを習得・開発が可能な素晴らしい開発環境です。
一方、中規模以降のプログラムの場合、直観的にプログラミングを続けると、以下の様なプログラムになってしまうことが多いです。
この様なプログラムになってしまうと、素晴らしい開発環境であるLabVIEWといえど、様々なデメリットが発生します。以下はそのようなデメリットのほんの一例です。
- 理解が難しい
- どの機能が、どこにプログラムされているのか判りづらい
- 視覚的・直観的に理解できる範囲を超えてしまい、プログラム作成者しか分からない
- 機能拡張・保守が大変
- 部分的に変更・追加しづらい
- プログラムの一部分のみを解析・テストしづらい
- 意図していない部分に影響を及ぼしてしまう
- 信頼性が低い
- 問題が発生した場合、原因を特定するのに時間がかかる、もしくは特定が困難になる
- 問題が頻発して、何度もゼロから開発し直すことになる (プログラムが成熟せず資産にならない)
「LabVIEWのワナ」に陥らないために
ここで、「とすると、LabVIEWって開発環境として良くないの？」と思ってしまいそうです。ですが、そうではありません。
「いくらLabVIEWといえども、きちんとしたプログラムを作るなら最低限のお作法を守りましょう」ということです。「LabVIEWのワナ」とは、「直感的にプログラミングできてしまうため、最低限のお作法を守らぬまま規模の大きなソフトウェア開発に挑戦し、結果的に失敗してしまう」という意味です。言い換えると、最低限のお作法を守れば、LabVIEWは規模の大きなプログラムに対しても素晴らしい開発環境です。
では、最低限のお作法とはなんでしょうか。それは、次の二点です。
- 直感的にプログラミングをせず、作りたいソフトウェアについて事前に分析、検討、設計する。
- その際、モジュール性を意識する。
この二点を押さえた開発になっているかどうかで、理解し易く、変更し易く、信頼性が高く、長く資産として残るソフトウェアになるかが決まります。
では、順を追って見ていきます。
作りたいプログラムについて、モジュール性を意識して分析・設計する
- そのプログラムが実現する内容は、どの様なものかを言葉・文章で表現してください。
- 表現した内容から、プログラムがどの様な要素(モジュール)で構成されるか分析してください。
- プログラムを構成する要素(モジュール)ごとに、どの様な内部パラメータを持ち、どの様な動作を行うか、分析します。
- プログラムの内容を実行するために、複数の要素(モジュール)がどの様に連動するか分析します。
下図は、縦に時系列、横に要素間の要求/応答を示して、複数の要素が連動する様子を図示する方法の例です。
分析したモジュール単位で開発・テストする
分析した各モジュールに対して、LabVIEW クラスライブラリを作成します。
- クラスライブラリは、分析したモジュールの「内部パラメータ」と「動作」をセットにして管理できるライブラリです。
- 次図の左上の様に、「.ctl」の項目に内部パラメータが格納され、その下に一つの動作につき一つのサブVIが管理されます。
- 次図の下半分の様に、そのモジュール単体でテスト可能なプログラムを作成して、いつでもモジュール単位での動作確認をできる様にします。
- 各動作に対応するサブVIは、内部パラメータを格納するワイヤ配線で接続されます。
モジュール単位で開発できている様に見せかけて…
一見、前述のようにモジュール単位で開発できている様に見える場合があります。しかし、上記の形をミヨウミマネで実装しているだけで、きちんと開発ができていないケースがほとんどです。
それを見抜くためにいくつかの確認ポイントがあります。
- 同じ要素(モジュール)を1つだけでなく2つ以上プログラム上に生成したい場合、そのモジュールのライブラリは対応しているか
- モジュールの動作をつなぐワイヤ配線は、そのモジュールの動作を実行するサブVIのみがアクセス可能か
- モジュールのワイヤ配線に、クラスライブラリ内のサブVI以外がアクセス可能になっていないか
- もしアクセス可能な場合、そのモジュールのみがアクセスすべき内部パラメータが改ざんされてしまう
- オブジェクト指向的な拡張が可能か
複数のモジュールを管理する
各要素をクラスライブラリによって個別に開発すると、複数のクラスライブラリを管理する必要があります。複数のクラスライブラリが、LabVIEWプロジェクトエクスプローラ、及び、保存先ディレクトリの両方で管理します。
下図は、プログラムを構成する5つの要素に対して、A~Eの5つのクラスライブラリが存在するケースです。左側はLabVIEWプロジェクトエクスプローラ上、右側は保存先ディレクトリ上で、それぞれ5つのクラスライブラリが管理されています。
モジュールを組み合わせてプログラムを作る
各モジュールのクラスライブラリを作成・管理できたら、いよいよ各モジュールの動作を連動させてプログラムを作成します。
下図は3つの要素(モジュール) A/B/C が連動する形で実現されるプログラムの例です。各要素の内部パラメータはワイヤ、動作はサブVIで実行されます。各要素のサブVI(動作)の入出力を連動させる形で、プログラムを開発します。
あらためて、最初のプログラムと比較してみます。下図のプログラムはモジュールが意識されておらず、直観的にプログラミングが行われた結果です。一方、上図のプログラムはプログラミング開始前にモジュール毎の検討、開発、テストを実施したことによって、同じ内容を実現しているにもかかわらず見やすく、変更・追加、問題の究明を行いやすいです。
「LabVIEWのワナ」から脱し、モジュール性を意識した開発をしよう！
プログラムを直観的に作れるのがLabVIEWの最大の特徴です。しかし、いくらLabVIEWと言えども、無計画なまま大規模なプログラムを開発することはできません。
建築に例えるのは賛否ありますが、住居を無計画に建造するのと、各お部屋、浴室、化粧室、等、住居の構成要素それぞれをしっかり検討してから建造するのでは、最終的な建造物の出来が全く異なります。
今回の記事を一例として、LabVIEWで計画的かつモジュール性を意識したプログラム開発を行っていただくことをお薦めします。
モジュール性を意識した開発ができているかのおさらいポイント
- プログラムを構成する要素をきちんと把握し、各要素の内部パラメータ・動作を文章や図で検討できているか
- 複数の要素がどの様に連動し、プログラムの機能を実現するか検討できているか
- 検討した各要素(モジュール)に対して、クラスライブラリで開発し、各モジュールの単位で動作確認できているか
- 開発した複数の要素をLabVIEWプロジェクトエクスプローラや、保存先ディレクトリきちんと管理できているか
トリオニクスの開発
トリオニクスでは、本記事の様な内容を一例として、お客様の御要望を最良の形で実現したプログラム・システムをご提供できる様努めています。すでに開発されたプログラムに対するセカンドオピニオンとしてのお問合せもいただいております。新規開発、既存システムの改修、どうぞお気軽にご相談ください。