JP2014186508A - プログラミング装置、プログラミング支援方法及びプログラム - Google Patents

Abstract

【課題】ユーザが新規処理モジュールを定義しようとする際に、最小限の情報に基づいて、流用可能な既存処理モジュールを提示できるようにする。
【解決手段】ユーザは、ユーザインタフェース１０２を介して、処理モジュールによる処理結果として得ようとしている出力に関する情報、例えば出力ポート名称や出力データ型を設定する。処理モジュール検索部１０５は、既存処理モジュールが登録された処理モジュール・データベース１０６から、前記設定された出力に関する情報に合致する出力を持つ既存処理モジュールを検索し、検索された既存処理モジュールを選択可能に提示する。
【選択図】図１

Description

本発明は、処理モジュールを組み合わせてプログラムを作成するプログラミング手法に利用して好適なプログラミング装置、プログラミング支援方法及びプログラムに関する。

従来、定義済みの複数の処理モジュールを組み合わせて目的とする処理を実行可能なプログラムを作成するプログラミング手法が広く一般的に用いられている。
例えば一般的な手続き型言語におけるライブラリは、過去に作成された関数或いはメソッドを定義するサブプログラムを蓄積したものである。プログラムを作成するユーザは、関数・メソッドの呼び出しを記述することで、動的或いは静的にライブラリをリンクして既存処理を再利用する。
また、既存処理モジュールを視覚的に組み合わせて効率的なプログラミングを可能とする、ビジュアル・プログラミングと呼ばれる手法も種々提案されている。
これらのプログラミング手法においては、同一処理を目的とする処理モジュールの重複定義を省き、既存処理モジュールの再利用性を向上させることで、開発効率を向上させている。従って、ユーザに定義済の既存処理モジュールの存在を効率良く知らしめる必要がある。

特許文献１では、入出力データとなるデータの意味に応じて固有番号を与えて管理し、入出力データの固有番号の組に基づき処理要素の名称を検索する技術が開示されている。
特許文献２では、部品入出力定義で検索したソフトウェア部品を候補として、順次評価動作させ、ユーザが与えた評価結果条件に合致する部品を選択する技術が開示されている。
特許文献３では、指定プログラム部品の入出力型に基づいて、入力或いは出力に接続可能な他のソフトウェア部品を検索する技術が開示されている。

特開２００４−２８０７１４号公報 特開２００７−１６４２４１号公報 特開２０００−２７６３３８号公報

しかしながら、特許文献１に開示されている技術では、処理要素の検索のため入力データと出力データの固有番号の組み合わせが必要である。また、データを固有番号で意味の重複が起こらないようい管理する必要がある。
特許文献２に開示されている技術でも同様に、ソフトウェア部品の検索のため入力と出力の定義を組み合わせて与える必要がある。
特許文献３に開示されている技術は、指定した部品に接続する接続相手の部品を検索する技術であり、ユーザが新たな処理部品を定義しようとするときに再利用可能な既存部品を提示するものではない。

本発明は上記のような点に鑑みてなされたものであり、ユーザが新規処理モジュールを定義しようとする際に、最小限の情報に基づいて、流用可能な既存処理モジュールを提示できるようにすることを目的とする。

本発明のプログラミング装置は、ユーザが処理モジュールによる処理結果として得ようとしている出力に関する情報を設定する出力情報設定手段と、既存処理モジュールが登録された処理モジュール・データベースから、前記出力情報設定手段で設定される出力に関する情報に合致する出力を持つ既存処理モジュールを検索する既存処理モジュール検索手段と、前記既存処理モジュール検索手段で検索された既存処理モジュールを選択可能に提示する既存処理モジュール提示手段とを備えたことを特徴とする。

本発明によれば、ユーザが新規処理モジュールを定義しようとする際に、処理結果として得ようとしている出力に関する情報を設定するだけで、当該出力を得るために必要な入力情報を知らなくとも、流用可能な既存処理モジュールの候補を知ることが可能となる。

第１の実施形態に係るプログラミング装置の構成を示すブロック図である。 ビジュアル・プログラミング手法を説明する図である。 第１の実施形態における新規処理モジュール定義時のユーザインタフェース画面の例を示す図である。 第１の実施形態において処理モジュール作成時に流用可能な既存処理モジュールを提示するための処理を示すフローチャートである。 処理モジュール検索を高速化するための出力情報検索辞書の例を示す図である。 第２の実施形態における出力データ型を変換するコンバータの例を示す図である。 型変換可能性を調べるための型変換辞書の例を示す図である。 第２の実施形態においてコンバータによるデータ型変換を考慮した既存処理モジュールの検索処理を示すフローチャートである。 第２の実施形態においてデータ型コンバータが挿入された処理モジュールの定義の例を示す図である。 接続実績辞書の例を示す図である。 第４の実施形態において処理モジュール作成時に流用可能な既存処理モジュールを複数マージして流用可能とするための処理を示すフローチャートである。 第４の実施形態において未対応出力情報の出力ポートに複数の既存処理モジュールを選択して割り付ける操作を説明するためのユーザインタフェース画面の例を示す図である。 第４の実施形態において複数の入力ポートが統合された後の処理モジュール定義の例を示す図である。

以下、添付図面を参照して、本発明の好適な実施形態について説明する。
＜第１の実施形態＞
第１の実施形態では、出力ポート名称と出力データ型による一致検索を説明する。
（システム構成）
図１は、本発明の実施形態に係るプログラミング装置の構成を示すブロック図である。本実施形態に係るプログラミング装置では、処理モジュールの入力ポートと出力ポートとを視覚的に接続してゆくことによりプログラミングを行う図形プログラム、すなわちビジュアル・プログラミング手法を採っている。

１０１は図形プログラム作成部であり、図形プログラム環境をユーザに提供するための各種制御を行う。
１０２はユーザインタフェースであり、不図示の表示装置と入力装置を用いて、図形プログラム作成部１０１からの情報に基づき、ユーザに各種情報を提示するとともに、ユーザからの入力を受け付けて、図形プログラム作成部１０１に伝える。

１０３はデータ型一覧記憶部であり、処理モジュールの入出力データのデータ型として利用可能なデータ型一覧を保持する。データ型には、各ビット幅の符号付或いは符号なしの整数型、浮動小数点型、固定小数点型、これらをメンバ・要素として組み合わせた構造体型やベクトル、行列型、画像型等が存在する。ユーザがユーザインタフェース１０２及び図形プログラム作成部１０１を介して新たなデータ型を定義し、登録することもできる。

１０４はデータ型コンバータ・データベースであり、データ型の組を相互に変換する各種コンバータを登録管理する。あるデータ型から他のデータ型へのコンバータが登録されていれば、これらのデータ型の組はこの方向には変換可能であるが、必ずしも逆方向のコンバータが登録されているとは限らない。ユーザが新たな型の組み合わせのコンバータを定義し、追加登録することも可能である。また、データ型コンバータ・データベース１０４には、どのデータ型の組が変換可能であるかを容易に検索可能とするための検索用情報も格納する。これについては後述する。尚、コンバータは処理モジュールの一種であるものとみなすこともできるので、コンバータ本体は処理モジュール・データベース１０６に登録し、データ型コンバータ・データベース１０４には検索用情報のみを格納する構成としても良い。

１０５は処理モジュール検索部であり、図形プログラム作成部１０１により指定された条件に基づき、既存処理モジュールが多数登録された処理モジュール・データベース１０６を検索し、候補となる処理モジュールを抽出する。
１０６は処理モジュール・データベースであり、既存処理モジュール毎に管理ＩＤを振って、既存処理モジュールを登録管理する。ユーザが定義した新たな処理モジュールを追加登録することもできる。尚、管理ＩＤは、処理を効率化するため、処理モジュール・データベース１０６に処理モジュールを登録する際に自動的に振られる番号であり、通常ユーザが意識する必要はない。

１０７はポート情報データベースであって、既存処理モジュールを構成する入力ポート及び出力ポートに関するポート情報を格納する。各ポート情報には、入出力するデータの型とポート（若しくはデータ）の名称文字列を含む。どちらか一方のみとしても構わないが、本実施形態では両方含むものとする。また、ポート情報データベース１０７は、ポート情報毎に当該ポートを出力として持つ処理モジュールの情報も保持する。さらに、後述するように過去に接続されたポートの組を示す情報も保持する。尚、本実施形態では、処理モジュール・データベース１０６とポート情報データベース１０７とを別のブロックとして記述しているが、一体化したデータベース構成としてもかまわない。
１０８は類似名称辞書であり、あいまい検索を行うときに用いられる。
尚、図１の各部は、パーソナルコンピュータやクライアント・サーバシステム等のコンピュータシステム上で動作するソフトウェアプログラムとして実現される。

（ビジュアル・プログラミング手法）
次に、図２を参照して、ビジュアル・プログラミング手法について説明する。本手法においては、作成するプログラム全体が一つの処理モジュールとなり、その内部の処理は複数のより粒度の細かい処理モジュール（サブモジュール）を組み合わせることにより階層的に定義される。作成したプログラムは、所望の入力を与えて単独で動作させることもできるし、他のプログラムのサブモジュールとして流用することもできる。

２０１はプログラム全体を表す処理モジュールの例である。この処理モジュールは、処理対象のデータを入力する入力ポート２０２、処理結果のデータを出力する出力ポート２０３、２０４、処理を実行する際に用いるパラメータを設定するパラメータポート２０５〜２０７を備える。このように、ビジュアル・プログラミング手法における処理モジュールは、それぞれ任意の数の入力ポート、出力ポート、パラメータポートを備えたブロックモジュールとして視覚的に表される。これらのポートは、処理モジュール作成時に、ユーザよりユーザインタフェース１０２からの入力によって追加される。

処理モジュール２０１により実行される処理は、内部にサブモジュールを配置し、それらの入出力ポートを接続することにより階層的に定義される。２０８〜２１２は処理モジュール２０１を構成する各種サブモジュールの例である。処理モジュール２０８は、その内部処理がさらにサブモジュールで定義された処理モジュールである。処理モジュール２０９は、内部処理がＣ言語等の高級言語、或いはプログラム実行環境に対応する実行バイナリコード等のコードにより定義された処理モジュールである。処理モジュール２１０は、プログラミングシステムが予め用意している基本演算器の一例であり、畳み込み演算を行う処理モジュールである。処理モジュール２１１は、プログラムの外部環境からデータをインポートして処理対象データとして使用可能にする処理モジュールであり、パラメータとしてファイル名を与えることにより、システムの記憶装置上に存在するファイルをオープンして読み込むロードモジュールである。処理モジュール２１２は、プログラムの外部環境へデータをエクスポートする処理モジュールであり、パラメータで与えられたファイル名に基づき、システムの記憶装置上にファイル出力するセーブモジュールである。尚、処理モジュール２１２のパラメータ２１５は、処理モジュール２０１外部から設定するのではなく、固定値を設定した例を示している。このように、プログラムの使用者から変更させる必要のないパラメータは、固定値設定することも可能である。

これらの様々なタイプの処理モジュールは、通常ユーザはその内部構成を意識して区別する必要は無く、入出力の意味だけを知れば利用することができる。これらの処理モジュールは、処理モジュール・データベース１０６に登録されている。ユーザは所望の処理モジュールを特定して選択するために、様々な検索方法を利用可能である。例えば処理モジュールは処理のカテゴリに基づき分類されているので、カテゴリを特定して所望の処理モジュールを選択することができる。或いは処理モジュールに合わせて登録されている処理内容の説明文に対し、ユーザが入力した単語に基づく検索を掛けることもできる。

処理モジュールの内部処理の定義のためのサブモジュールの選択、配置、パラメータポートを含む入出力の結線は、ユーザがユーザインタフェース１０２を操作し、図形プログラム作成部１０１に指令を与えることにより実行される。また、新たに内部処理を定義して作成した処理モジュールそれ自身も、その処理内容の説明文とともに、処理モジュール・データベース１０６に登録され、再利用可能となる。
プログラミングを行うユーザは、処理モジュールの各部の定義をいずれの部分から始めても良いが、本発明の考え方を適用する際には、後述するように出力ポートの定義から始めるようにすると良い。

（ユーザインタフェース画面例）
図３は、本実施形態における新規処理モジュール定義時のユーザインタフェース（ＵＩ）画面の例を示す。
モジュール定義フィールド３０１は、新規処理モジュールを定義したり、既存モジュールの定義内容を表示したりするための作業領域となる。本ＵＩではタブ化されており、複数の処理モジュールを切り替えて表示できるようになっている。図３では、名前のまだ付けられていない（ｎｏｎａｍｅ）新規処理モジュールの定義画面が表示されている。
プロパティ・フィールド３０２は、処理モジュールの選択された部位、或いは全体に関する各種属性情報を表示・変更可能とする領域である。図３では、出力ポート３０５が選択（或いは新規追加）された状態を示している。出力ポート３０５の属性値としては、ポートのタイプ（変更不可）、ポート名称、データ型がある。
データベース・フィールド３０３は、各種データベースから検索した情報を表示する領域である。図３では、プロパティ・フィールド３０２で設定した出力ポートの属性値に合致する既存処理モジュールを候補モジュール一覧として表示している。これらの候補モジュールのいずれかをマウスやキーにより選択（反転表示）すると、当該モジュールの説明が領域３０６に表示され、この候補モジュールの出力ポート属性が領域３０７に表示される。
メッセージ・フィールド３０４は、ユーザに対するメッセージを表示する領域である。メッセージ・フィールド３０４は、タブにより、エラーや動作状況を示すＬＯＧ表示と切り替えることができる。
候補モジュールのＳｅｌｅｃｔボタン（選択確定ボタン）３０８をマウス等により押下すると、反転表示されていた処理モジュールの選択が確定し、その定義内容が領域３０９に示すように表示される。ユーザはこの定義内容をそのまま利用することも可能であるし、これをベースとして所望の改造を加えることもできる。
ＵＩ画面には、この他、定義の各部を選択・入力可能とする不図示のポップアップ・ウィンドウやツールボックス・ウィンドウを備えるが、本発明には直接関わらないため省略する。

（設計処理フロー）
次に、図４を参照して、新規処理モジュール設計時に図形プログラム作成部１０１が行う処理を説明する。図４は、第１の実施形態において処理モジュール作成時に流用可能な既存処理モジュールを提示するための処理を示フローチャートである。
ステップＳ４０１で、図３に示したようなＵＩ画面を表示した上で、ユーザからの入力操作を待つ。図形プログラム作成部１０１は、基本的にユーザからの入力イベントを待ち入力に応じた処理を実行する、イベント駆動型プログラムとして実装されている。

この入力操作待ち状態において、ユーザはＵＩ画面のモジュール定義フィールド３０１で、作成しようとしている処理モジュールに対し、新規の出力ポート３０５の追加操作を行うことができる。出力ポート３０５の追加操作は、Ｅｄｉｔメニューを押すことによって現れるプルダウン・メニューやモジュール定義フィールド３０１上にマウスカーソルを持っていき右クリックすることにより現れるポップダウンメニュー等によって行う。或いは、ショートカットキー入力で対応することも可能である。追加操作を行った直後の状態は、追加した出力ポート３０５が選択されている状態（図３では太枠線表示）となっており、プロパティ・フィールド３０２で属性設定することができる。ここで設定できる属性は、出力ポート名称及び出力データ型である。
出力ポート名称の設定は、プロパティ・フィールド３０２のＮａｍｅ欄への文字列入力により行う。尚、設定する名称は出力ポート名称ではなく、出力するデータ名称であるものとしても、以下同様に取り扱うことができる。
出力データ型の設定は、プロパティ・フィールド３０２のＤａｔａ Ｔｙｐｅ欄のプルダウン・メニューの中からデータ型を選択することにより行う。このプルダウン・メニューで表示されるデータ型は、データ型一覧記憶部１０３にて保持されているものである。
ポート情報データベース１０７に格納されているポート情報に基づき、既存処理モジュールで使用実績のある出力ポート名称と出力データ型の組を選んで設定することも可能である。この場合、データベース・フィールド３０３でＰｏｒｔ Ｌｉｓｔタブを選択すると、ポート情報データベース１０７に格納されているポート情報の一覧が表示される。ユーザがこの中から所望のものを選択すれば、プロパティ・フィールド３０２のＮａｍｅ欄及びＤａｔａ Ｔｙｐｅ欄が設定される。
これら出力ポート名称や出力データ型といった出力情報の設定は、必ずしも出力ポートを追加した直後に続けて行う必要はない。例えば複数の出力ポートを追加した後にそれぞれの出力情報を設定したり、名称とデータ型のどちらか一方のみを設定しておいて、他方は後に設定したりするということも可能である。もちろん、以上説明した出力情報の設定方法はあくまで一例であり、ここに示した以外の操作方法を採っても本発明を適用可能であることは言うまでもない。

次に、ステップＳ４０２で、ユーザからの入力操作が出力情報の設定操作であったかどうかを判定する。
ステップＳ４０２においてＹｅｓであった場合、ステップＳ４０３に進み、出力ポート名称、すなわちＮａｍｅ欄の文字列が設定されたかどうかを判定する。
出力ポート名称が設定された場合、ステップＳ４０４で、設定された名称と合致する名称の出力ポートを持つ既存処理モジュールを、処理モジュール・データベース１０６より検索して絞り込む。そして、絞り込まれた処理モジュールの管理ＩＤをリストにして、候補一覧として生成する。ここで、本実施形態において、出力ポート名称が「合致する」とは、名称の文字列が完全に一致することを指すものとする。尚、それまでの操作により既に候補一覧が絞り込まれていた場合、処理モジュール・データベース１０６全体を検索するのではなく、一覧中の管理ＩＤに限定して、その中から設定された出力情報に合致する出力ポートを持つ処理モジュールを検索して絞り込む。
今回の入力操作が出力情報の設定操作でなかった場合、ステップＳ４０４の処理はスキップされる。

次に、ステップＳ４０５で、ユーザからの入力操作が出力データ型、すなわちＤａｔａ Ｔｙｐｅ欄が設定されたのかどうかを判定する。
出力データ型が設定された場合、ステップＳ４０６で、データ型が合致する出力ポートを持つ既存処理モジュールを、処理モジュール・データベース１０６より検索して絞り込む。そして、絞り込まれた処理モジュールの管理ＩＤをリストにして、候補一覧として生成する。ここで、本実施形態において、データ型が「合致する」とは、データ型が同一であることを指すものとする。ステップＳ４０４と同様に、それまでの操作により既に候補一覧が絞り込まれていた場合、一覧中の管理ＩＤに対応する処理モジュールの中から絞り込むが、そうでない場合、処理モジュール・データベース１０６全体を検索して一覧作成する。

尚、ステップＳ４０３〜Ｓ４０６に示したような出力情報による候補モジュールの絞り込み処理を、本明細書ではまとめて「既存処理モジュール検索」処理（ステップＳ４１１）と呼ぶことにする。
この出力情報による既存処理モジュール検索処理（ステップＳ４１１）は、処理モジュール・データベース１０６を直接検索するのではなく、ポート情報データベース１０７に予め出力情報検索辞書を作成しておいて効率良く高速に行うようにすることもできる。この辞書は、図５に示すように、出力ポート名称と出力データ型のそれぞれ或いは組合せの出力情報について、それを出力ポートの属性値として使用している処理モジュールの管理ＩＤをリストにして、予め保持しておくものである。新規処理モジュールが作成され、処理モジュール・データベース１０６に登録される際には、同時に各出力ポートの属性を抽出して当該辞書に管理ＩＤを追加格納する。このようにすると、検索用辞書を調べて得た出力情報に対応する管理ＩＤの一覧を用いて処理モジュール・データベース１０６を参照することにより、速やかに対象の処理モジュールに関する情報取得することが可能になる。

ステップＳ４０７は、既存処理モジュール提示ステップである。ここでは、絞り込んだ候補一覧の管理ＩＤを用いて処理モジュール・データベース１０６を参照し、候補処理モジュールのモジュール名称一覧を作成する。このとき、各モジュール名称に対応付けて管理ＩＤも記憶しておく。そして、ＵＩのデータベース・フィールド３０３のＣａｎｄｉｄａｔｅ Ｍｏｄｕｌｅｓタブに一覧を表示し、マウスやカーソル操作によってユーザが候補処理モジュールのいずれかを選択できる状態として、ステップＳ４０１に戻る。
ここで、Ｃａｎｄｉｄａｔｅ Ｍｏｄｕｌｅｓタブに表示されているモジュール一覧は、ユーザがいずれかを一次選択すると、そのモジュール名称が反転表示され、かつ当該モジュールの処理内容に関する説明文が領域３０６に表示される。さらに、選択を確定するためのＳｅｌｅｃｔボタン３０８が表示される。

ステップＳ４０２においてＮｏであった場合、ステップＳ４０８に進み、候補モジュールが選択されたかどうかを判定する。ステップＳ４０１の入力操作待ち状態において、ユーザがＳｅｌｅｃｔボタン３０８を押下して、表示されている候補処理モジュールの選択を確定した場合、ステップＳ４０２はＮｏであり、ステップＳ４０８の判定がＹｅｓとなる。
そして、ステップＳ４０９で、選択された処理モジュールのモジュール名称に対応付けて記憶されている管理ＩＤに基づき、処理モジュール・データベース１０６を参照して当該処理モジュールの構成情報を取得する。取得した構成情報に基づき、モジュール定義フィールド３０１で、図３に例示するように、入力ポートや処理内容等の情報を補間表示する。ここで、補間表示とは、モジュール定義フィールド３０１で、ユーザが入力した出力ポートに加えて、不足する構成要件を追加して配置し表示することを示す。
ユーザは以降、表示されている構成をベースとして、改造して新たなモジュールを定義することもできるし、表示された処理内容がそのまま利用可能なものであったなら、新規作成を打ち切って既存モジュールの使用に切り替えることもできる。

もちろん、図形プログラム作成部１０１は、ステップＳ４０１の入力待ち状態においてユーザからの他の入力操作があった場合、それぞれ対応した動作を行う。その動作は本発明には直接関係しないので、図４ではこれらをステップＳ４１０としてまとめて記述しており、詳細内容は割愛する。

以上説明したように、ユーザが新規処理モジュールを定義しようとする際に、得ようとしている出力に関する情報を設定するだけで、流用可能な既存処理モジュールの一覧が提示される。このようなプログラミング支援により、蓄積した処理モジュールの再利用性を向上させることができる。同様の処理を行う処理モジュールを重複定義することも避けられるようになり、設計効率が向上する効果が見込まれる。
尚、本実施形態では、出力ポート名称及び出力データ型の２つを検索キーとして用いるものとしたが、もちろんどちらか一方のみ、或いはこれらを他の検索キーと合わせて使用する形態であっても本発明を適用可能であることは言うまでもない。

＜第２の実施形態＞
第２の実施形態では、データ型コンバータ・データベース１０４を利用するデータ型コンバート可能検索を説明する。
図４のステップＳ４０６において、出力データ型が指定された出力情報と同一でなくとも、データ型コンバータ・データベース１０４に登録されているコンバータを用いることにより、変換可能である場合に「合致する」ものと判定するようにすることも可能である。

図６（ａ）〜（ｆ）は、データ型コンバータ・データベース１０４に登録されている各種データ型コンバータの例を示す。もちろん、ここに示した以外のコンバータも登録されているが、説明には不要のため省略する。

図６（ａ）は整数型から浮動小数点型へのコンバータであり、ＩＤはＣ００１である。本コンバータは、入力ポート６０１より整数型の値を受け、出力ポート６０２より浮動小数点型の値を出力する。出力される値は、元の整数を例えばＩＥＥＥ７５４形式の浮動小数点値に変換したものである。

図６（ｂ）は浮動小数点型から固定小数点型へのコンバータであり、ＩＤはＣ００２である。６０４、６０５は変換のためのパラメータ設定ポートであり、本コンバータは、パラメータ設定ポート６０４に整数値を格納する変数のビット幅と、パラメータ設定ポート６０５に２進数で何桁目を小数点位置とするかを示す値とを設定するようになっている。これらのパラメータには、固定値を設定することもできるし、外部から与えた値を設定することもできる。入力ポート６０３より入力された浮動小数点値は、パラメータ設定に従って固定小数点値に変換され、出力ポート６０６より出力される。

図６（ｃ）は浮動小数点型から整数型へのコンバータであり、ＩＤはＣ００３である。通常、浮動小数点数から整数へのコンバートは、小数点以下の数値は切り捨てられるか四捨五入されることが多いが、本コンバータでは、パラメータとして小数点位置を右にシフトする量を設定できるようになっている。この小数点シフト量はデフォルト値０である。例えば入力された浮動小数点値が０．５である場合、二進数では０．１ｂとなるので、小数点シフト量を０とすると出力される値は０になるが、シフト量を１に設定すると出力される値は１になって情報量が失われない。小数点シフトに負の値を設定すれば、逆方向のシフトも可能である。また、本コンバータは、変換した整数値を出力するメインの出力ポート６０８と、失われた仮数部の桁数を出力する出力ポート６０９とを備える。入力浮動小数点数０．５のときシフト量０でコンバートした場合は、出力される整数値は０で、失われた桁数が１となる。この失われた桁数情報は、例えば、図６（ｂ）のコンバータで固定小数点に変換する際の小数点位置を決定する際に利用することもできる。

図６（ｄ）は要素の値が整数型であるベクトルを、要素の値が浮動小数点型であるベクトルに変換するコンバータであり、ＩＤはＣ０２１である。本実施形態においてベクトルとは所望の長さの値の配列であり、ベクトル型の値からは、要素の数と各要素の値を取得することができる。本コンバータでは、ベクトルの要素各々の値について、図６（ａ）のコンバータによる変換を行ったのと同等の結果が得られる。

同様に図６（ｅ）は浮動小数点ベクトル型から固定小数点ベクトル型への変換を行うコンバータであり、ＩＤはＣ０２２である。本コンバータに設定する必要のあるパラメータは、図６（ｂ）のコンバータと同様ビット幅と小数点位置である。全ての要素について、同じビット幅と小数点位置が適用され変換される。

図６（ｆ）は各ビンの値が固定小数点型である一次元ヒストグラムを、固定小数点ベクトル型に変換するコンバータであり、ＩＤはＣ０２３である。本実施形態において、ヒストグラム型には最小値・最大値によるレンジ情報と、ビンの数、各ビンの値を含む。ヒストグラム型をベクトル型に変換する際には、各ビンの値が最小値から最大値に向かって順にベクトルの要素として代入される。すなわち、変換前のビンの数と変換後の要素の数は等しくなる。ここで、最大値・最小値のレンジ情報は失われる。本コンバータでは、メインの出力ポート６１０からは変換されたベクトルが出力され、出力ポート６１１からはレンジ情報が出力されるようになっている。

図６（ｇ）は同様にビンの値が整数型である一次元ヒストグラムを、整数ベクトル型に変換するコンバータであり、ＩＤはＣ０２４である。各出力ポートから出力される値も同様に、それぞれ変換したベクトルとレンジ情報である。

以上のように、各コンバータには、変換前の値を入力する入力ポート、変換に必要なパラメータ設定ポート、変換後の値や付随する情報を出力する出力ポートを備える。すなわち、通常の処理モジュールと同等に取り扱うことも可能である。したがって、本実施形態では、データ型コンバータは、データ型コンバータ・データベース１０４で登録管理するものとしているが、他の処理モジュールと同様、処理モジュール・データベース１０６で登録管理するものとしてももちろん構わない。

データ型コンバータ・データベース１０４には、図７に一部を示すような、ある型から他の型への変換可否を調べるための、型変換グラフが辞書として保持されている。このグラフ構造において、各ノードはデータ型であり、データ型一覧記憶部１０３に保持されているデータ型に一致する。各ノードからは、変換可能な型へ方向が分かるようにリンクが張られており、かつリンクの示す型変換を行う際に利用するコンバータのＩＤが各リンクに保持されている。
尚、リンクは接続されているどちらのノードからも参照可能で、変換可能方向とコンバータＩＤが取得できる。図７において、（ａ）のグラフはスカラ値を示す型の変換可能関係を示し、（ｂ）のグラフはベクトル型及びヒストグラム型の変換可能関係を示す。
データ型コンバータ・データベース１０４に新たな型変換コンバータが登録された場合には、変換元の型を示すノードから変換先の型を示すノードに新たなリンクが張られ、追加されたコンバータの管理ＩＤが付加される。

本実施形態において、図４のステップＳ４０６に対応するデータ型の合致判定及び絞り込み検索は図８に示す処理フローとなり、図７の型変換グラフを用いて、以下に説明するように行われる。尚、本実施形態において、ステップＳ４０６以外の処理は図４と同様であるので説明を省略する。
ステップＳ８０１で、新規処理モジュールの出力情報として設定された出力データ型に基づき、ステップＳ４０６と同様にデータ型が同一の出力を持つ既存処理モジュールを検索して抽出した管理ＩＤのリストを候補一覧に追加する。ここでは、例として、ユーザにより固定小数点ベクトル型が出力データ型として設定されたものとして説明する。初回に抽出された候補の処理モジュールは、コンバータ無しに指定された型のデータを出力する処理モジュールであるので、優先度は最も高い。本実施形態では、管理ＩＤが候補一覧に追加された順に優先度が高いものとしている。尚、後述するように、コンバータによるデータ型変換を行うことにより合致するものとして抽出された処理モジュールの管理ＩＤは、コンバータＩＤと合わせて候補一覧に記憶される。

ステップＳ８０２で、図７の型変換グラフにおいて、指定された出力データ型に対応するノードを参照する。初回の探索時には図７（ｂ）のノード７０１が対応するノードとなる。そして、当該ノードを変換先とするリンクがあれば、それらを全てリンク一覧キューに追加する。リンク一覧キューはＦＩＦＯであり、各リンクを参照するための情報が追加された順に格納され、後述のステップで古い順に取り出される。ここで、逆方向すなわち当該ノードを変換元とするリンクは辿る必要がないのでキューに積まない。例えばノード７０５からリンク７１０は逆方向であるので辿らない。また、起点ノードを含めて既に辿ったノードへのリンクも辿る必要がないのでキューには積まない。これにより、図７（ａ）に示すように双方向に変換可能なコンバータが登録されていたり、ループ状に他の型を経由して元の型へと変換可能となったりしていたとしても、既に辿ったノードを２回辿ることは無くなる。例えば図７（ｂ）のノード７０７に対する処理を行っているとき、ノード７０５へは、リンク７１０が示すようにノード７０７が変換先ノードとなっているが、ノード７０５は既に辿られたノードであるので戻ることはない。

ステップＳ８０３で、リンク一覧キューにリンク情報が入っているかどうかを確認する。入っていなければ、全てのリンクに対応する処理は完了しており、これ以上コンバート可能なデータ型は存在しないことになるので、処理終了となる。リンク情報が残っていれば、ステップＳ８０４に進みリンク情報を一つキューから取り出す。そして、リンクに接続されているノードを参照し、次の指定のデータ型として設定して、ステップＳ８０１に戻る。結局ノードの辿り方は、ツリーの幅優先探索と同等になる。すなわち図７（ｂ）において辿るノードの順は、ノード７０１からノード７０４、７０５、７０７というようになる。

図７（ｂ）の例では、ノード７０１を起点として、ノード７０１の次に辿られるノードはリンク７０２に接続されたノード７０４である。つまり、２回目のステップＳ８０１で、このノードに対応するデータ型浮動小数点ベクトル型を出力データ型に持つ既存処理モジュールが検索され、その処理モジュール管理ＩＤが候補一覧に追加される。このときリンク７０２が持つ変換に使用するコンバータＩＤ：Ｃ０２２も、検索された各候補の管理ＩＤに対応付けて候補一覧に記憶しておく。次に辿るノードはノード７０５で、同様に一次元固定小数点ヒストグラム型を出力データ型に持つ既存処理モジュールを検索し、その管理ＩＤを候補一覧にコンバータＩＤ：Ｃ０２３と共に記憶する。続いてノード７０７に対応する整数ベクトルを出力型に持つ既存処理モジュールが検索される。ここで絞り込まれた候補は、コンバータＩＤ：Ｃ０２２、Ｃ０２１のコンバータを２つ経由して変換される値であるので、これらのコンバータＩＤと共に管理ＩＤが候補一覧に記憶される。同様にノード７０９に対応する一次元整数ヒストグラムを出力型として持つ既存処理モジュールが検索され、その管理ＩＤがコンバータＩＤ：Ｃ０２２、Ｃ０２１、Ｃ０２４と共に候補一覧に記憶される。

このようにコンバータを複数個用いて変換可能なデータ型を出力として持つ処理モジュールも合致するものとして抽出される。
絞り込まれた各候補の優先度は、経由するコンバータの数が少ない程高くなる。上述の例では、ノード７０１に対応する出力型を持つモジュールの優先度が最も高く、ノード７０９に対応する出力型を持つモジュールの優先度が最も低くなる。図３のＵＩ画面のデータベース・フィールド３０３に表示する候補モジュールの名称一覧は、この優先順位に従った順序、すなわち候補一覧への格納順となるようにしている。
また、絞り込む候補モジュールの数に上限値を設けても良い。この場合、ステップＳ８０１の直後で、候補一覧に格納された処理モジュールの数をチェックするようにし、上限数に達したところで探索を打ち切る。
このようにして絞り込まれた候補一覧の中から、ユーザは第１の実施形態と同様に、所望の処理モジュールを選択することができる。そして、選択された処理モジュールの構成に基づき入力ポートや処理内容等の情報が、モジュール定義フィールド３０１に補間表示される。このとき選択された候補モジュールが、データ型変換により合致する処理モジュールであれば、内部処理の出力と出力ポートとの間に、さらに対応付けて記憶してあるＩＤのコンバータを順に繋げて挿入した状態で補間表示される。

図９は、コンバータが挿入されて補間表示された例である。図９（ａ）の場合は、選択された既存処理モジュールの構成９０３に加えて、出力ポート９０１の前にコンバータ９０２が一つ挿入されて表示されている。このコンバータ９０２は、パラメータ設定ポートを一つ持っており、モジュールの外から設定可能なように追加されたパラメータポート９０４に接続される。図９（ｂ）は、コンバータを２つ必要とする処理モジュールが選択された例である。同様に選択されたモジュールの構成９０８と出力９０５の間に、コンバータ９０６と９０７が挿入されて表示される。コンバータ９０６はパラメータポートを２つ持つが、この例ではこれらにそれぞれ固定値を設定した場合を示している。この場合はモジュール外部から追加のパラメータを設定する必要がなくなるので、外部にパラメータポートは追加されない。
このようなコンバータの備えるパラメータポートの扱いをどうするかは、ユーザ操作により切り替えることが可能である。

尚、本実施形態では、所望の出力データ型を得るための変換に必要なコンバータの数に基づき候補モジュールとしての優先度を決定するようにしたが、コンバータ毎に定めた重みに基づき優先度を決定することもできる。例えば、コンバータの処理負荷が多い程、或いは変換精度が悪い程、重みが大きくなるように事前に定めておき、上記と同様に変換に必要なコンバータを特定して、その重みの合計が小さい程高優先となるようにする。

以上、本実施形態によれば、出力データ型が完全一致しなくとも流用できる可能性のある既存処理モジュールが提示されるので、より一層再利用性が高くなり開発効率の向上に寄与する。

＜第３の実施形態＞
第３の実施形態では、名称あいまい検索を説明する。
図４のステップＳ４０４における出力ポート名称の合致判定は、第１の実施形態で説明したような名称文字列の完全一致の場合に限らず、所謂あいまい検索の考え方を導入して類似する名称であるかどうかを判定するようにしても良い。本実施形態では、過去のポートの接続実績に基づき、ポート名称が類似するかどうかを判定する辞書を作成している。
本実施形態のプログラミング手法では、上述した図２で説明したように、複数の処理モジュールを配置して、それらの入出力を接続することによりプログラムを作成している。新規に作成されたプログラムが、処理モジュールとして処理モジュール・データベース１０６に登録される際には、同時にその内部の処理モジュールの出力ポートから入力ポートへの接続を全て抽出する。そして、互いに接続されているポートの名称のペアを、接続実績があるものとして、ポート情報データベース１０７に辞書登録する。

図１０は、接続実績辞書の一実装例のデータ構造をグラフィカルに示したものである。図１０において、各ノードは、それぞれ異なったポート名称に対応する。処理モジュールを登録する際その内部のサブモジュールのある出力ポートからある入力ポートへの接続が存在した場合、それぞれのポート名称に対応するノード間にリンクが引かれる。すなわちリンクが存在する名称間が、接続実績があるものとして表されている。このリンクは、方向を管理する必要はない。また、ポート名称間で接続された回数をリンクに保持するようにしても良い。ユーザが新規処理モジュールを作成する際には、処理モジュール・データベース１０６内の既存処理モジュールに基づいて作成された、図１０に示すような接続実績辞書が使用可能な状態となっている。尚、接続実績辞書は、接続回数を含めて表形式で記録されたものとしても良い。

本実施形態において、図４のステップＳ４０４に対応するポート名称の合致判定及び絞り込み検索は、図１０の接続実績辞書を用いて、以下に説明するように行われる。
まず、新規処理モジュールの出力情報として設定された出力ポート名称に基づき、第１の実施形態で説明したのと同様に、ポート名称が同一の出力を持つ既存処理モジュールを検索して候補一覧を作成する。ここでは例としてポート名称がＧｒａｙＥｄｇｅＩｍａｇｅであったものとする。ここで抽出された候補一覧の処理モジュールは、ポート名称の文字列が完全一致する処理モジュールであり、候補としての優先度は最も高いものとする。

次に、接続実績辞書内において、ユーザにより設定された出力情報の出力ポート名称に対応するノードを特定する。本実施形態では図１０のノード１００１が対応ノードとなる。そして、当該ノードとリンクされたノードを順に辿る。このときの辿り方は、第２の実施形態で説明したのと同様の幅優先探索である。また、起点ノードを含めて既に辿ったノードへは戻らない。従って、図１０においては、ノード１００１、１００２、１００３、１００４、１００５、１００６、１００７、１００８が辿るノード順となる。

そして、各ノードを順に辿りながら、それぞれのノードに対応するポート名称と一致する出力をもつ既存処理モジュールを検索して候補一覧に加えてゆく。絞り込まれた各候補の優先度は、第２の実施形態と同様、経由するリンクの数が少ない程高くなるものとする。そして同様に、データベース・フィールド３０３に表示する候補モジュールの名称一覧がこの優先順位に従った順序となる。

尚、上述したように接続された回数をリンク毎に保持して管理する場合、接続実績の多いリンクで接続されたノードに対応するポート名称程、優先度を高く設定するようにしても良い。また、第２の実施形態と同様、検索する候補モジュール数に上限を設けて打ち切るようにすることももちろん可能である。
本実施形態では、過去の接続実績に基づき類似名称を表す辞書を作成し、出力ポート名称が異なった処理モジュールであっても検索可能とする方法を説明したが、あいまい検索の方法はこれに限らない。様々なあいまい検索方法を用いて、所定の条件を満たした場合に合致するものと見なしても良いことは言うまでもない。例えば、本実施形態においては、ポート名称には所謂キャメル記法を用いているので、小文字と大文字の境目が単語の切れ目となる。従って、複数の英単語により定義されたポート名称を単語に分解することは用意であるので、分解した上で例えば含まれている語順や一致する数等を利用したあいまい検索を行うことももちろん可能である。

本実施形態で説明した方法と、その他のあいまい検索手法を組み合わせてももちろん良く、第２の実施形態で説明したコンバート可能検索を組み合わせても良いことは自明である。完全一致でない出力ポート名称を用いても絞り込み検索が行えることにより、より一層の既存処理モジュールの選択効率向上が期待できる。

＜第４の実施形態＞
第４の実施形態では、処理モジュールの複数マージを説明する。
新規に定義する処理モジュールによって得ようとする出力が複数ある場合、複数の出力ポートを持つ一つの既存処理モジュールでは、設定された出力を全て得ることができない場合もあり得る。このような場合、既存の処理モジュールを複数組み合わせて、内部処理を定義できると良い。

図１１は、このような複数の既存処理モジュールのマージに対応した、図形プログラム作成部１０１の処理フローチャートの例である。
ステップＳ１１０１のユーザからの入力待ち状態は、上述した図４のステップＳ４０１と同様で、図３に示すようなＵＩを表示した上でユーザからの入力操作を待つ。この状態に置いてユーザからの様々な入力操作が可能であるのは第１の実施形態と同様である。
ステップＳ１１０２も第１の実施形態と同様に、ユーザからの入力操作が、上述の出力情報の設定操作であったかどうかを判定する。この時点で、処理が対応付けられていない出力ポートの出力情報が、少なくとも１つ以上設定されている状態となる。この処理が対応付けられていない出力情報のことを、処理未対応出力情報と呼ぶ。以前の操作により他の出力情報が設定されており、かつそれらの他の出力情報の出力ポートに処理が対応付けられていない場合もあり得るので、処理未対応出力情報は複数同時に存在することもあり得る。
また、本判定処理では、ユーザにより後述する候補モジュールの選択がなされ一部の出力ポートに処理の定義が対応付けられた直後の時点で、残りの処理未対応出力情報が存在する場合には、ユーザからの追加の出力情報設定が無くとも、Ｙｅｓと判定する。

ステップＳ１１０３で、各未対応出力情報に合致する既存処理モジュールの絞り込みを行う。この処理は、図４のステップＳ４１１に示した出力情報による候補処理モジュール検索処理を、個々の未対応出力情報毎に行うものである。もちろん、ここでは、上述のように、ポート名称若しくはデータ型のいずれか一方のみによる絞り込み検索処理を行うものとしても良いし、変換可能なデータ型による合致、あいまい検索による名称の合致判定を行うようにしても良い。いずれにせよ、各々の未対応出力情報に対し、流用可能な候補となる既存処理モジュールの一覧が絞り込まれた状態となる。

ステップＳ１１０４で、これらの未対応出力情報を全て、「指定未対応出力情報」として設定する。
ステップＳ１１０５で、指定未対応出力情報に設定されている未対応出力情報全てに合致する出力を持つ既存処理モジュールを検索する。この処理は、ステップＳ１１０３において検索された指定未対応出力情報各々に対応する候補一覧の管理ＩＤをＡＮＤ処理することにより行うことができる。ＡＮＤ処理の結果、残った既存処理モジュールがあれば、そのモジュールは、指定未対応出力情報に合致する出力ポートを全て備えたモジュールである。
尚、ここで検索された結果が、必ずしもユーザが複数組み合わせたい処理モジュールの一つに該当しない場合もあるが、その場合は、後述の既存処理モジュール提示ステップで提示されたモジュールをユーザが選択しなければ良い。そして、ユーザがさらに別の出力ポートを追加すれば、別の指定未対応出力情報の出力ポートの組み合わせに合致する処理モジュールが、ここでの探索の結果として現れるようになる。或いは、ここで、ユーザが指定未対応出力情報のいくつかを指定から外せるようにすれば、よりユーザの所望する既存処理モジュールが検索される可能性が高まる。

ステップＳ１１０６で、ＡＮＤ処理で残った処理モジュールが１つ以上あったかどうかを判定する。残ったモジュールが無かった場合、設定している指定未対応出力情報から未対応出力情報を一つ削除する。削除する未対応出力情報は、例えばユーザにより設定された順が最も後のものとする。そして、ステップＳ１１０５に戻り、残っている指定未対応出力情報により同様のＡＮＤ処理を繰り返す。これにより、指定未対応出力情報は徐々に数が減っていくので、ＡＮＤ処理でいずれかの処理が残る可能性が高まる。残った処理モジュールがあった場合、これらは候補モジュールとなり、ステップＳ１１０８で一覧表示して、ユーザが選択できるようにする。この処理からは図４のステップＳ４０７で示したのと同様の既存処理モジュール提示ステップに相当する。
尚、ステップＳ１１０６において、ＡＮＤ処理で残ったモジュールがある場合でも、予め定めた上限数に達していない場合は、残った処理を一覧に記憶するとともに、ステップＳ１１０７からステップＳ１１０５に戻る処理を繰り返すようにすることもできる。この際、ＡＮＤ処理に用いた指定未対応出力情報の数が多い程、高優先の処理モジュールであるものとする。上限に達した後はステップＳ１１０８に進んで以後は同様である。

ステップＳ１１０２においてＮｏであった場合、ステップＳ１１０９に進み、候補モジュールが選択されたかどうかを判定する。ステップＳ１１０１の入力操作待ち状態において、ユーザがＳｅｌｅｃｔボタンを押下して、表示されている候補処理モジュールの選択を確定した場合、ステップＳ１１０２はＮｏであり、ステップＳ１１０９の判定がＹｅｓとなる。
ステップＳ１１１０で、選択された処理モジュールの構成を、ステップＳ１１０５においてＡＮＤ検索時に合致すると判定された出力ポートに接続するようにして、モジュール定義フィールド３０１に表示する。

図１２（ａ）は、未対応出力情報であった出力ポート１２０１に、ユーザが選択した既存処理モジュールの処理構成１２０２を対応付けて接続表示した例を示す。尚、図１２では、元の既存処理モジュールの処理内容定義の範囲を明確にするため、枠１２０３を付けて表示しているが、この枠は表示しなくとも構わない。この時点で、処理未対応の出力ポート１２０４がまだ残っている状態となっている。
上述したように残りの未対応出力情報があれば、ステップＳ１１０２においてＹｅｓと判定されるので、ステップＳ１１０３〜Ｓ１１０８の処理により、残りの出力ポート１２０４に対応する既存処理モジュールが存在すれば選択可能となる。
図１２（ｂ）は、処理未対応で残っていた出力ポート１２０４に対応する既存処理モジュールを選択した例を示し、その構成が１２０５のように表示されている。
このように複数の既存処理モジュールを出力ポートに対応させるものとして選択した場合、それぞれの元の既存処理モジュールが備えていた入力ポートで受け取るべきデータを共通のものとしてマージさせられる可能性が生ずる。例えば図１２（ｂ）において、入力ポート１２０６は、元々出力ポート１２０１に対応付けられて選択された既存処理モジュールが備えていたポートで、入力ポート１２０７は出力ポート１２０４に対応付けられた既存処理モジュールが備えていたポートである。これらの入力ポートは、どちらもＲＧＢカラー画像型を入力するデータ型としている。このような場合、システムはユーザに２つのポートをマージするかどうかを選択させる。

ステップＳ１１１１で、統合可能な入力ポートがあるかどうかを調べる。これは、別の既存処理モジュールに由来する入力ポートを一つずつ取出し、上述の出力型の合致判定と同様に、それらの型が合致するかどうかを判定する処理である。上述の実施形態の出力情報の合致判定と同じく、データ型に加えてポート名称も用いても良い。また、完全一致ではなくデータ型はコンバート可能かどうか、ポート名称はあいまい検索による合致を調べるようにすることももちろん可能である。
画して統合可能な入力ポートの組み合わせがある場合、ステップＳ１１１２の判定結果はＹｅｓとなる。
そして、ステップＳ１１１３で、ユーザに組合せ毎に統合するかどうかを選択させる。図１２（ｂ）は、矢印１２０８で示された入力ポート１２０６、１２０７が統合候補として提示されている様子を表している。このとき、これらのポートに同一のデータを入力するものとして統合することを指示するためのＩｄｅｎｔｉｃａｌボタン１２０９と、合致するデータ型ではあるが別のデータを入力することを示すＳｅｐａｒａｔｅボタン１２１０が表示される。ユーザはいずれかのボタンを押して、統合するかどうかを選択する。
その後、ステップＳ１１１２に戻り、統合可能な入力ポートの組み合わせが無くなるまでこれを繰り返す。尚、図１１のフローからは省略してあるが、パラメータポートについても同様に統合可能な場合があるので、ユーザに選択させる。

図１３に、ポート１２０６、１２０７が統合された後の処理モジュールの定義を示す。２つの既存処理モジュール由来の上下の処理定義部に対し、共通の入力ポート１３０１からの入力が接続された状態となっている。

もちろん、第１の実施形態で説明したのと同様、図形プログラム作成部１０１は、ステップＳ１１０１の入力待ち状態においてユーザからの他の入力操作があった場合、それぞれ対応した動作を行う。その動作は本発明には直接関係しないので、図１１ではこれらをステップＳ１１１４としてまとめて記述しており、詳細内容は割愛する。

以上説明したように、出力情報が設定された出力ポート全てに合致する既存処理モジュールが登録されていなくとも、一部の出力ポートが合致する処理モジュールが順次候補として提示される。これにより、複数の既存処理モジュールを組み合わせて使用するのが容易になるので、再利用性がさらに高くなりプログラム開発効率の向上が見込める。

以上、本発明の好ましい実施形態について詳述したが、本発明は特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
例えば、上述した実施形態では図形プログラミングを前提として説明したが、出力情報に基づき既存の処理モジュールを検索するという考え方は、例えばＣ言語等の手続き型言語における関数やメソッド等の検索にも適用可能である。
また、上述した実施形態では、出力情報のみを用いて既存処理モジュールを検索したが、ユーザが追加で、例えば明らかに必要な入力ポートの入力情報や内部処理モジュールを指定した場合は、これらを含むことを条件としてさらに絞り込みを行っても良い。通常の処理検索で用いられるような、処理モジュールのカテゴリや処理名称等が利用できる場合は、これらを組み合わせて検索すれば良いことは言うまでもない。
型変換辞書や類似名称辞書は、図７や図１０に示したようなグラフ構造とする必要はなく、他のデータ構造、例えば一覧表の形式で情報を保持するようにしても構わない。
ＵＩの構成も図３や図１２に示したもの限らず、本発明の考え方を踏襲した上で種々多彩なバリエーションが実現可能であるのは言うまでもない。

（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。すなわち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１０１：図形プログラム作成部、１０２：ユーザインタフェース、１０３：データ型一覧記憶部、１０４：データ型コンバータ・データベース、１０５：処理モジュール検索部、１０６：処理モジュール・データベース、１０７：ポート情報データベース、１０８：類似名称辞書

Claims (15)

1. ユーザが処理モジュールによる処理結果として得ようとしている出力に関する情報を設定する出力情報設定手段と、
   既存処理モジュールが登録された処理モジュール・データベースから、前記出力情報設定手段で設定された出力に関する情報に合致する出力を持つ既存処理モジュールを検索する既存処理モジュール検索手段と、
   前記既存処理モジュール検索手段で検索された既存処理モジュールを選択可能に提示する既存処理モジュール提示手段とを備えたことを特徴とするプログラミング装置。
2. 処理モジュールは、入力ポート及び出力ポートを備えたブロックモジュールとして視覚的に表され、
   ブロックモジュールの出力ポートを他のブロックモジュールの入力ポートに接続することにより、視覚的に処理モジュールを組み合わせてプログラムを作成することを特徴とする請求項１に記載のプログラミング装置。
3. 前記出力情報設定手段で設定される出力に関する情報は、出力ポート名称と出力データ型の少なくとも一方を含むことを特徴とする請求項１又は２に記載のプログラミング装置。
4. 前記既存処理モジュール検索手段は、既存処理モジュールの出力データ型が、前記出力情報設定手段で設定された出力データ型に一致しなくとも、既存処理モジュールの出力データ型を異なった出力データ型に変換するデータ型変換手段を一つ或いは複数個用いて、前記出力情報設定手段で設定された出力データ型に変換可能である場合は、合致するものと判定することを特徴とする請求項３に記載のプログラミング装置。
5. 前記既存処理モジュール提示手段は、前記データ型変換手段を一つ或いは複数個用いて変換可能であることにより合致するものと判定された処理モジュールは、前記データ型変換手段を加えて提示することを特徴とする請求項４に記載のプログラミング装置。
6. 前記既存処理モジュール提示手段は、出力データ型を合致させるために必要な前記データ型変換手段の数が多い既存処理モジュールの優先度が低くなるように提示することを特徴とする請求項４又は５に記載のプログラミング装置。
7. 前記既存処理モジュール検索手段は、出力ポート名称が文字列として完全一致していなくとも、所定の条件を満たせば合致しているものとみなすあいまい検索を行うことを特徴とする請求項３に記載のプログラミング装置。
8. 前記あいまい検索は、類似名称辞書を用いて出力ポート名称が類似しているかどうかを判定することを特徴とする請求項７に記載のプログラミング装置。
9. 前記類似名称辞書は、入力ポートと出力ポートを接続した過去の接続実績に基づき生成されることを特徴とする請求項８に記載のプログラミング装置。
10. 前記既存処理モジュール提示手段は、前記あいまい検索により出力ポート名称が類似していると判定された既存処理モジュールの中で、あいまいさが少ない名称の出力ポートを持つ既存処理モジュールの優先度が高くなるように提示することを特徴とする請求項７乃至９のいずれか１項に記載のプログラミング装置。
11. 前記出力情報設定手段は、複数の出力に対する出力情報を設定可能であって、
    前記既存処理モジュール検索手段は、全ての出力情報だけでなく、一部の出力情報に合致する出力のみを持つ処理モジュールを検索し、
    前記既存処理モジュール提示手段は、前記一部の出力情報に合致する出力のみを持つ処理モジュールを複数組み合わせることにより全ての出力を得るように選択することを可能とすることを特徴とする請求項１乃至１０のいずれか１項に記載のプログラミング装置。
12. 前記既存処理モジュール提示手段は、前記一部の出力情報に合致する出力のみを持つ処理モジュールを複数組み合わせることにより全ての出力を得るように選択した場合、同一のデータを受け取るべき入力を統合して一つの入力とする処理を行うことを特徴とする請求項１１に記載のプログラミング装置。
13. ユーザが処理モジュールによる処理結果として得ようとしている出力に関する情報を設定するのを受け付けるステップと、
    既存処理モジュール検索手段が、既存処理モジュールが登録された処理モジュール・データベースから、前記ユーザにより設定された出力に関する情報に合致する出力を持つ既存処理モジュールを検索するステップと、
    前記検索された既存処理モジュールを選択可能に提示するステップとを有することを特徴とするプログラミング支援方法。
14. 処理モジュールは、入力ポート及び出力ポートを備えたブロックモジュールとして視覚的に表され、
    ブロックモジュールの出力ポートを他のブロックモジュールの入力ポートに接続することにより、視覚的に処理モジュールを組み合わせてプログラムを作成するプログラミング手法で利用するための処理モジュールの出力に関する出力情報を抽出し、前記出力情報と前記出力情報に合致する出力情報を有する処理モジュールとを対応付けてデータベースに登録するステップを有することを特徴とする請求項１３に記載のプログラミング支援方法。
15. ユーザが処理モジュールによる処理結果として得ようとしている出力に関する情報を設定する出力情報設定手段と、
    既存処理モジュールが登録された処理モジュール・データベースから、前記出力情報設定手段で設定された出力に関する情報に合致する出力を持つ既存処理モジュールを検索する既存処理モジュール検索手段と、
    前記既存処理モジュール検索手段で検索された既存処理モジュールを選択可能に提示する既存処理モジュール提示手段としてコンピュータを機能させるためのプログラム。

Images