JP2016024794A - プログラム作成装置 - Google Patents

Abstract

【課題】 データフローの経験が乏しいオブジェクト指向経験者のデータフローでのプログラム開発効率が落ちないようにする装置を提供する。【解決手段】 データフロープログラムを作成するプログラム作成装置であって、データフロープログラムを構成する処理部品がいずれの記憶手段に対してデータの読み書きをするかを定める特定手段を備える。【選択図】 図１

Description

本発明はプログラム作成装置に関し、特にデータフロープログラムの作成装置に関する。

種々のアルゴリズムを実現するプログラムの開発手法のひとつとして、データフロープログラミングが知られている。データフロープログラミングはデータの流れ（データフロー）に注目したプログラム開発手法であって、データフロー図（ＤＦＤ；ＤａｔａＦｌｏｗ Ｄｉａｇｒａｍ）を用いてグラフィカルにプログラミングすることが多い。
ＤＦＤ等で表されたデータフロープログラムは本質的に並列処理である。このため、マルチコアシステムやメニーコアシステムに適しており、さらにはプロセッサを持たないＦＰＧＡ(field programmable gate array)やＡＳＩＣ(application specific integrated circuit)といったハードウェアシステムに対しても適している。

しかしながらデータフロープログラミングは大規模プログラム開発においては、複雑になりがちであり、開発効率や保守性に問題があると指摘する声もある。
一方、オブジェクト指向プログラミングは大規模プログラム開発に向いているとされ、現在のプログラム開発手法の主流である。そのためよく知られたアルゴリズムやロジックに関しては、ソースコードやライブラリといった形で入手可能であり、最新のアルゴリズムに関しても論文発表と同時に入手可能となることが多い。
しかしオブジェクト指向によって効率的な並列処理を実現するためには、プログラム開発者に高いプログラム設計スキルが必要とされる。

現在、組込機器からスーパーコンピュータまで、幅広い分野でプロセッサのマルチコア／マルチプロセッサ化が進行しており、並列処理に適したデータフロープログラミングの重要性がますます高まってきている。
このような状況において、新規に開発するアルゴリズムの並列処理検討を早期に行うには、プログラム開発手法としてデータフローを基本とした上で、既存資産や最新アルゴリズムの流用、オブジェクト指向での設計経験・スキルの活用を行うことが重要となる。
特に開発者の多くがデータフローの考え方に馴染めていない現状では、複雑な部分は慣れているオブジェクト指向で設計・作成し、それらをオブジェクト指向の考えでもってデータフロープログラム構成部品として利用できる仕組みが必要である。

オブジェクト指向を構成する概念にはいくつかあるが、以下ではカプセル化、特にデータ隠蔽化についてのみ考える。具体的には、以下の性質である。
オブジェクトは状態を持ち、その状態が意味するところはオブジェクト外部からは知りえない。
オブジェクトの状態の一部または全部を取得・変更する場合は原則としてメソッド（メンバ関数）を通して行う。

データフローとオブジェクト指向に関連した特許文献として、特許文献１および特許文献２があるが、いずれもＤＦＤからオブジェクトの抽出を行うものであり、オブジェクト指向の資産や考え方をデータフロープログラミングの下で扱うものではない。また、ＤＦＤ記述に関してもオブジェクト指向との親和性のために拡張された部分はない。
データフローにオブジェクト指向の考え方を導入した実例としては、ＬａｂＶＩＥＷ（National Instruments社製のシステム開発ソフトウェア）がある。ＬａｂＶＩＥＷではメンバーＶＩと呼ぶ、Ｃ＋＋のメンバー関数に相当する処理部品があり、メンバーＶＩには処理データの入力・出力の他にメンバーＶＩが所属するオブジェクトデータの入力および出力が１つずつ設けられている。
これはオブジェクトそのものもデータの１つと考え、メンバーＶＩの処理によってオブジェクトの状態の一部または全部が変更され、変更された状態を持つ新たなオブジェクトが出力される、という考え方である。

特許２８６８１８６号公報 特開平８−１８５４２４号公報

特許文献１および特許文献２は、いずれもＤＦＤからオブジェクトの抽出を行うものであり、プログラム開発手法としてデータフローを基本とした上で、オブジェクト指向の資産の流用やオブジェクト指向での設計経験の活用を促進するものではない。
また非特許文献１では“オブジェクトそのものをデータの１つとして捉える”という考え方が開示されている。しかし、この考え方は、“メンバー関数（メソッド）にはオブジェクトをデータとして与えない”というＣ＋＋やＪａｖａ（登録商標）を始めとする多くのオブジェクト指向言語やＵＭＬ(Unified Modeling Language)による表記と一致しない。

そのため、データフローの経験が乏しいオブジェクト指向経験者にとっては、考えたことがそのまま記述できないため、プログラム開発効率が落ちてしまう、という課題があった。
さらに作成されたデータフロープログラムには、入出力データとしてのオブジェクトが多く含まれる。それがデータフローの経験が乏しいオブジェクト指向経験者による、プログラムからアルゴリズムを理解する際の妨げとなり、プログラムの再利用性が上がらなかった、という課題があった。

さらに非特許文献１の“オブジェクトそのものをデータの１つとして捉える”という考え方は、作成されたデータフロープログラムには、入出力データとしてのオブジェクトが多く含まれるため、プログラムの可読性が低かった、という課題があった。

以上の課題を解決するため、本発明のプログラム作成装置は、
データフロープログラムを作成するプログラム作成装置であって、
前記データフロープログラムを構成する処理部品がいずれの記憶手段に対してデータの読み書きをするかを定める特定手段を備えることを特徴とする。

また本発明のプログラム作成装置は、
処理部品と、複合部品と、前記複合部品がデータの読み書きをする記憶手段とを含むデータフロープログラムを作成し、表示手段に表示するプログラム作成装置であって、
前記複合部品がいずれの記憶手段に対してデータの読み書きをするかを定める特定手段を備え、
前記複合部品は、データフロープログラムを内包し、内包したデータフロープログラムを処理内容として処理を行う部品であって、
前記処理部品が前記複合部品に直接的に内包されており、前記特定手段により該複合部品が記憶手段を特定している場合に、
前記複合部品に直接的に内包されている前記処理部品は、前記複合部品が特定する記憶手段に対してデータの読み書きをする
ことを特徴とする。

上記構成によれば、本発明のプログラム作成装置は、データフローの経験が乏しいオブジェクト指向経験者にとって、プログラム開発効率の低下を低減させる、という効果がある。
さらに、プログラムの再利用性を向上させる、という効果がある。
さらに、プログラムの可読性を向上させる、という効果がある。

実施例１のプログラム作成装置で扱うプログラムの例を示す図である。 コード表記されたデータフロープログラムの例を示す図である。 実施例１を説明する、クラス構造を示した図である。 実施例１を説明する、処理部品のインスタンス仕様の構造を示す図である。 実施例１を説明するプログラム例に対応したインスタンス仕様の構造を示す図である。 実施例１のプログラム作成装置の構成例を示す図である。 実施例１の動作を説明する図である。 実施例１の動作を説明する図である。 実施例２のプログラム作成装置で扱うプログラムの例を示す図である。 実施例２を説明する、複合部品に関するクラス図である。 実施例２を説明するプログラム例に対応したインスタンス仕様の構造を示す図である。 実施例２のプログラム作成装置がプログラムを管理している様子を示す図である。 実施例２の動作を説明する図である。 実施例２の動作を説明する図である。 実施例１のプログラム作成装置がプログラムを管理している様子を示す図である。 実施例２の動作を説明する図である。 実施例３のプログラム作成装置で扱う別のプログラムの例を示す図である。 実施例３を説明するプログラム例に対応したインスタンス仕様の構造を示す図である。 実施例３の動作を説明する図である。 実施例３の動作を説明する図である。

以下、添付の図面を参照して本発明の好適な実施形態について説明する。
ＤＦＤの表記法には種々のものがあるが、本実施例ではデマルコ式を基本とし、異なる箇所および拡張する箇所については都度説明を行う。
なお以下では“プロセス”が行う内容を“処理”、“処理”を行う実体を“処理部品”として区別するが、明確に区別する必要のない個所ではいずれも同義とする。

またプロセスに流入するデータフローを「入力データフロー」、プロセスから流出するデータフローを「出力データフロー」と、区別して呼ぶことがある。
また、各処理部品は処理内容により、予めどのような型のデータがいくつ入出力されるかが定められている。処理部品において、入力データフローが接続される点を“入力ポート”、出力データフローが接続される点を“出力ポート”と呼ぶことにする。

［実施例１］
図１は本実施例のプログラム作成装置で扱うプログラムの例である。図１（ａ）および図１（ｂ）はＣ＋＋で書かれたプログラムの抜粋であり、図１（ａ）はクラスＡのクラス定義の例であり、図１（ｂ）はクラスＡのインスタンスへのポインタであるｏｂｊＡを用いたプログラムの例である。

なお、簡単のため、クラスＡ以外の変数やメンバー関数の戻り値の型はｉｎｔ型を想定しているが、本発明はｉｎｔ型に限定されるものではなく、いかなる型を用いても構わない。
ｏｂｊＡは必ずしもこのような定義である必要はなく、ｏｂｊＡの型がわかればよい（たとえば関数の引数でもよい）。
ｉｎ１，ｉｎ２は入力変数であるので、どこかで値がアサインされているものとする。
ｓ３，ｓ４は出力変数である。
またここではポインタ変数を用いているが、ポインタ変数が指す実体はどこかでアサインされるものとする。
また、本実施例ではＣ＋＋をオブジェクト指向の実装言語としているが、本発明はＣ＋＋に限ったものではなく、Ｊａｖａ（登録商標）でもＣ＃でもよく、前記説明を行ったカプセル化の要件を備えていればどのような言語でもよい。

本実施例のプログラム作成装置を用いて、図１（ｂ）のプログラムをＤＦＤで記述したものが図１（ｃ）である。
図１（ｂ）の５行目に注目すると、以下のことを表している。
・オブジェクトｏｂｊＡの ・・・（項目１）
・メンバー関数Ａ１に、 ・・・（項目２）
・入力引数ｉｎ１を与え、 ・・・（項目３）
・得られた結果（戻り値）を変数ｓ１に代入する ・・・（項目４）

これに対応する部分が図１（ｃ）の処理Ａ１およびその周辺の記述である。
記憶部品ｏｂｊＡ（１１）は、オブジェクトｏｂｊＡの、メンバー変数ｄａｔａＡを始めとする全データを保持している。すなわち記憶部品ｏｂｊＡ（１１）がｏｂｊＡ（のデータ）そのものを表す記憶部である（項目１）。
処理部品Ａ１（１２１）はメンバー関数Ａ１の処理を実行する。ここで、処理部品Ａ１（１２１）は記憶部品ｏｂｊＡ（１１）を特定可能であり、特定された記憶部品ｏｂｊＡ（１１）内のデータに対し、自由に読み書きを行い、処理Ａ１を実行することが可能である。
これは、メンバー関数Ａ１は、オブジェクトｏｂｊＡのメンバー変数すべてに対してアクセスできることと対応している（項目２）。

図１（ｃ）において、処理部品Ａ１（１２１）と、それが特定する記憶部品ｏｂｊＡ（１１）とは点線で結ばれているが、これについては後述する。
処理部品Ａ１（１２１）には、変数ｉｎ１に相当する記憶部品ｉｎ１（１４１）から、データフロー１３１によって、データｉｎ１が入力されているが、これはメンバー関数Ａ１に入力引数ｉｎ１が与えられていることと対応している（項目３）。

処理部品Ａ１（１２１）は、処理を行ったあと、結果としてデータｓ１をデータフロー１３３およびデータフロー１３４によって出力しているが、これはメンバー関数Ａ１が処理結果を変数ｓ１に代入することと対応している（項目４）。
図１（ｃ）において、データフロー１３３およびデータフロー１３４は、処理部品Ａ１（１２１）から出た一本のデータフローを途中で分岐させて表しているが、これは処理部品Ａ１の出力が１つだけであることをわかりやすく表すためである。本発明はこのような表記法に限定されるものではなく、出力データフローを途中で分岐させずに処理部品Ａ１（１２１）から二つの出力データフロー（１３３および１３４）を直接出しても構わない。

同様に、図１（ｂ）の６行目、７行目、８行目も、図１（ｃ）に表されている。
なお、メンバー関数Ａ４には２つの入力引数ｓ１とｓ２が与えられているが、これは処理部品Ａ４（１２４）にｓ１をデータとするデータフロー１３４と、ｓ２をデータとするデータフロー１３５が入力されることで表されている。
以上、メンバー関数に相当する処理部品から、オブジェクトを表す記憶部品を特定し、特定された記憶部品内のオブジェクトデータを自由に読み書きする仕組みを説明した。
この仕組みにより、オブジェクト指向によって開発されたプログラムを、データフロープログラムで用いることが可能となる。またオブジェクト指向の考え方によって、データフロープログラムを作成することが可能になる。

次に、図１（ｂ）に示すＣ＋＋のソースコードから図１（ｃ）に示すデータフロープログラムを生成する処理について説明する。
手順
１）オブジェクト変数、入力変数および出力変数を記憶部品として配置・表示する。
２）図１（ｂ）の上の行から順に、以下の処理を行う。結果は表形式で上の行から記入していく。
I)メソッドおよび関数を特定する（図１（ｂ）の例ではすべてメソッドである）。
II)なお、メソッドは同一メソッドであっても個別に特定する（図１（ｂ）の例ではそのようなものはない）。各メソッドがどのオブジェクトインスタンスのメソッドであるかを特定する。
III)各メソッドの入力（変数）を特定する。
IV)各メソッドの出力（変数）を特定する。ここで出力変数が手順１）の出力変数のいずれとも異なり、かつ既に表に記入済の入力変数、あるいは出力変数であった場合、記入済の該変数名を他の名前に書き換える。
３）以上の結果をまとめると表１のようになる。なおこれらの特定処理は通常のコンパイラ技術を用いることで可能である。

４）表１の上から順に１行ずつ取り出し、以下の処理を行う。
I)メソッドをひとつの処理部品（円形のシンボル）として配置・表示する。
II)オブジェクトに注目し、同じ名前のオブジェクト変数に対応する記憶部品を特定する。
III)後述する記憶部特定部が前記Iの処理部品と前記IIの記憶部品とを点線で結ぶ。

・処理部品から、処理部品に向けて、矢印（データフロー）
５）表から１行ずつ順に出力欄を見ていき、表内で入力欄に同じ名前がある行を特定する。
前記特定された入力と同一行のメソッドに対応する処理部品から、前記特定された出力と同一行のメソッドに対応する処理部品に向けて、矢印（データフロー）を配置・表示する。なお、同じ名前のある入力が複数ある場合、これらすべての入力に対応する行についてこの処理を行う。

・記憶部品から、処理部品に向けて、矢印（データフロー）
６）表から1行ずつ順に入力欄を見ていき、１）で配置・表示を行った記憶部品（入力変数）と同じ名前であるものを順に抽出し、該記憶部品から該入力欄の行のメソッドに対応する処理部品に向けて、矢印（データフロー）を配置・表示する。
・処理部品から、記憶部品に向けて、矢印（データフロー）
７）表から１行ずつ順に入力欄を見ていき、１）で配置・表示を行った記憶部品（出力変数）と同じ名前であるものを順に抽出し、該入力欄の行のメソッドに対応する処理部品から該記憶部品に向けて、矢印（データフロー）を配置・表示する。
８）以上で配置・表示の処理は終了である。なお、プログラム開発を画面上で行うためには、画面上で各部品を見やすく配置する必要があるが、これは本発明の範囲外であるので説明を割愛する。

なお、図１（ｂ）ではメンバー関数の実行順序がＡ１，Ａ２，Ａ３，Ａ４となる。しかし、図１（ｃ）では「Ａ１（１２１）の後にＡ３（１２３）」「Ａ１（１２１）の後にＡ４（１２４）」「Ａ２（１２２）の後にＡ４（１２４）」という、処理部品の実行順序しか定められていない。また、たとえばＡ１（１２１）とＡ２（１２２）の処理部品の処理は同時に実行されるかもしれない。

これらは、データフロープログラミングが本質的にタスク並列処理であることの利点であるが、従来のオブジェクト指向（手続き型）プログラムからの移植においては問題となることがある。
処理部品の実行順序制御や、同時実行の回避（排他実行処理）は、本発明の範囲外であり、詳細は割愛するが、従来技術によって容易に問題を回避できる。

たとえば、前述のＬａｂＶＩＥＷにおいては、シーケンスストラクチャやエラークラスタを利用することにより、処理部品の実行順序制御が行える。また処理部品の排他実行処理は、セマフォやクリティカルセクションといった一般的なプログラミング手法で対応できる。
なお、図１（ｃ）において、処理部品Ａ１（１２１）と、それが特定する記憶部品ｏｂｊＡ（１１）とは点線で結ばれている。本発明は、この“特定”関係を“点線”に限定するものではないが、データフローの表記のような、“データの流れ”を想起させるものではないことに特徴がある。
ＤＦＤにおいて、データフローは矢印によって、データの流れを表している。
そのため処理に対する入力を入力データフローで、処理の結果である出力を出力データフローで表記することにより、オブジェクト指向プログラムにおけるメンバー関数（メソッド）の入力引数と、出力引数や戻り値の対応付けが容易に行える。

しかしメンバー関数（メソッド）が“オブジェクトデータを自由に読み書きできる”という関係は、読み書きできるという“権利”であり、入力や出力、あるいは入出力といったアクセスの方向やデータの流れを表すものではない。これはメンバー関数（メソッド）と、入力引数や出力引数、戻り値との関係とは異なるものである。
“特定”関係が、入力データフローや出力データフローと同じ表記、あるいはデータの流れを想起させる表記であった場合、作成されたデータフロープログラムから、元のオブジェクト指向におけるアルゴリズムを理解することが困難になってしまう。
これはＤＦＤのような図を用いた表記はもちろんであるが、コード表記されたデータフロープログラムでも同様である。

図２はコード表記されたデータフロープログラムの例である。いずれも図１（ｂ）のプログラムを表したものである。
図２（ａ）では一行に２つある“->”の真ん中にオブジェクト（ｏｂｊＡ）とメンバー関数（メソッド）（Ａ１、Ａ２、Ａ３、Ａ４）が書かれ、左側に入力変数、右側に出力変数が書かれている。

それに対し図２（ｂ）ではオブジェクト（ｏｂｊＡ）が入力変数や出力変数と同様に書かれている。
本実施例では図２（ｂ）ではなく、図２（ａ）のような表記（視覚形態）を用いることを特徴とする。
なお、本発明におけるデータフロープログラムのコード表記は、図２（ａ）で示した表記法に限定するものではなく、入力データフローまたは出力データフローと異なり、さらにデータの流れを想起させるものではない視覚形態であればよい。
以下では、これまで説明してきた仕組みを実現する、具体的な構成および動作に関して説明する。

図３は処理部品Ａ１（１２１）、処理部品Ａ２（１２２）、処理部品Ａ３（１２３）、処理部品Ａ４（１２４）の構造を表したクラス図の例である。
図３はさらに記憶部品ｉｎ１（１４１）、記憶部品ｉｎ２（１４２）、記憶部品ｓ３（１４３）、記憶部品ｓ４（１４４）、および記憶部品ｏｂｊＡ（１１）の構造を表したクラス図の例である。
処理部３１２は全処理部品に共通の処理を行うクラスであり、後に詳しく説明するように、主に処理部品内の実行制御を行う。
処理部３１２には記憶部特定部（特定手段）３１１がひとつ関連付けられており、記憶部特定部３１１は記憶部３２を高々ひとつ特定する。記憶部３２が“部品”として具現化したものが記憶部品であり、記憶部品の実体は記憶部そのものである。

なお、本発明において処理部品が特定する記憶部３２は必ずしもひとつに限るものではなく、複数の記憶部３２を特定することによってオブジェクト指向における多重継承を表すことができる。しかし最近では、多重継承は継承元オブジェクトの判別が困難になるため、好ましくないという意見が一般的である。そこで以下では、処理部品が特定する記憶部３２は高々ひとつであるとして、説明する。

また、以下の説明では、記憶部特定部３１１は、個々の処理部品が備え、該処理部品が特定する記憶部３２を定めるものとしているが、本発明はそのような構成に限定するものではない。たとえば、プログラム作成装置が記憶部特定部をひとつ備え、該記憶部特定部が、個々の処理部品がどの記憶部３２を特定するのかを定めても構わない。

図１の例では、オブジェクトｏｂｊＡそのものを表すデータを保持する、記憶部３２を継承したクラスＡ記憶部３２１が、記憶部品ｏｂｊＡ（１１）に対応するクラスである。
各処理部品に特有の処理は処理部３１２を継承するクラスで実装する。図３では処理部品Ａ１〜処理部品Ａ４の４つの処理部品について示しており、処理部Ａ１（３３１）、処理部Ａ２（３３２）、処理部Ａ３（３３３）、処理部Ａ４（３３４）が対応する。

処理部品共通部３１は、処理部３１２および記憶部特定部３１１を含んだサブシステムであり、全処理部品に共通する部分である。
後に説明するように、本実施例のプログラム作成装置では、データフロープログラムを、プログラムを構成する処理部品の集合として管理する。より具体的には各処理部品の継承元クラスである処理部品共通部３１の集合として管理する。

各処理部品にはあらかじめ、どのような型のデータがいくつ入出力されるかが定められており、各処理部品に特有の処理部から関連付けられた入力ポートや出力ポートとして実装される。
処理部品Ａ１（１２１）は、ｉｎｔ型の入力ポート、ｉｎｔ型の出力ポートをそれぞれひとつずつ備える。これは処理部Ａ１（３３１）から、入力ポートｉｎｔ部３５１、出力ポートｉｎｔ部３５２へひとつずつ関連を持つことで表される。

同様に処理部品Ａ２（１２２）もｉｎｔ型の入力ポート、ｉｎｔ型の出力ポートをひとつずつ備えるが、これは処理部Ａ２（３３２）から、各々入力ポートｉｎｔ部３５１、出力ポートｉｎｔ部３５２にひとつずつ関連を持つことで表される。
同様に処理部品Ａ３（１２３）もｉｎｔ型の入力ポート、ｉｎｔ型の出力ポートをひとつずつ備えるが、これは処理部Ａ３（３３３）から、各々入力ポートｉｎｔ部３５１、出力ポートｉｎｔ部３５２にひとつずつ関連を持つことで表される。
処理部品Ａ４（１２４）はｉｎｔ型の入力ポートをふたつ、ｉｎｔ型の出力ポートをひとつ備えるが、これは処理部Ａ４（３３４）から入力ポートｉｎｔ部３５１へふたつ、出力ポートｉｎｔ部３５２へひとつの関連を持つことで表される。

この様子をわかりやすく示すために、処理部品１２１〜１２４、および記憶部品ｏｂｊＡ（１１）のインスタンス仕様の構造を図４に示す。
図４（ａ）は処理部品Ａ１（１２１）と記憶部品ｏｂｊＡ（１１）、図４（ｂ）は処理部品Ａ２（１２２）と記憶部品ｏｂｊＡ（１１）のインスタンス仕様の構造を示す。図４（ｃ）は処理部品Ａ３（１２３）と記憶部品ｏｂｊＡ（１１）、図４（ｄ）は処理部品Ａ４（１２４）と記憶部品ｏｂｊＡ（１１）のインスタンス仕様の構造を示す。

処理部品Ａ１（１２１）では処理部Ａ１（４１１）から記憶部特定部（特定手段）４１２がひとつ、そして入力ポートｉｎｔ部４１３１がひとつ、出力ポートｉｎｔ部４１３２がひとつ接続されている。
処理部品Ａ２（１２２）でも同様に処理部Ａ２（４２１）から記憶部特定部（特定手段）４２２がひとつ、そして入力ポートｉｎｔ部４２３１がひとつ、出力ポートｉｎｔ部４２３２がひとつ接続されている。

処理部品Ａ３（１２３）でも同様に処理部Ａ３（４３１）から記憶部特定部（特定手段）４３２がひとつ、そして入力ポートｉｎｔ部４３３１がひとつ、出力ポートｉｎｔ部４３３２がひとつ接続されている。
処理部品Ａ４（１２４）では、処理部Ａ４（４４１）から記憶部特定部（特定手段）４４２がひとつ、そして入力ポートｉｎｔ部は４４３１、４４３３のふたつ、出力ポートｉｎｔ部４４３２がひとつ接続されている。

処理部品Ａ１（１２１）〜処理部品Ａ４（１２４）では、入力ポート、出力ポートともにｉｎｔ型のデータを入出力するものである。このため、入力ポートに対応するクラスとして入力ポートｉｎｔ部３５１を、出力ポートに対応するクラスとして出力ポートｉｎｔ部３５２を共通に用いた。もしｉｎｔ型以外の入出力を持つ処理部品の場合はそれぞれ対応するクラス（不図示）を用いればよい。
なお入力ポートを実装するクラスは入力ポートＩＦ３４１を、出力ポートを実装するクラスは出力ポートＩＦ３４２を実現している。

処理部３１２は、各処理部品が持つ全ての入力ポートを入力ポートＩＦ３４１で、全ての出力ポートを出力ポートＩＦ３４２で管理する。
また出力ポートを実装するクラスは、接続先の処理部品の入力ポートに対してデータを投入するために、入力ポートＩＦ３４１を要求インターフェースとして使用依存している。

なお、記憶部３２も、処理部品と同様に入力や出力を持ち、データフローを用いて処理部品と接続を行う。そこで本実施例では記憶部３２を処理部品の一形態として考え、処理部３１２を継承させている。こうすることで処理部品と記憶部３２を同じように管理することができる。ただし、本発明はこのような構成を強制するものではなく、処理部品と記憶部３２を、独立して管理してもよい。
記憶部品ｉｎ１（１４１）、記憶部品ｉｎ２（１４２）、記憶部品ｓ３（１４３）、記憶部品ｓ４（１４４）はｉｎｔ型のデータを入出力し、保持する。対応するクラスは記憶部３２を継承したｉｎｔ記憶部３２２である。ｉｎｔ記憶部３２２はｉｎｔ型の入出力を行うため、入力ポートｉｎｔ部３５１、出力ポートｉｎｔ部３５２をそれぞれひとつずつ持つ。

図５に、図１に対応するインスタンス仕様の構造を示す。出力ポートと入力ポートをつなぐリンク（１３１〜１３７）は入力ポートＩＦ３４１を介して接続される。
なお出力ポートｉｎｔ部４１３２からは２本のリンク（１３３、１３４）によって入力ポートｉｎｔ部（４３３１、４４３１）と接続されている。
記憶部品ｉｎ１（１４１）と記憶部品ｉｎ２（１４２）は出力ポートのみの接続であるため、入力ポートｉｎｔ部（５１３１、５２３１）は他の出力ポートｉｎｔ部には未接続である。

記憶部品ｓ３（１４３）と記憶部品ｓ４（１４４）は入力ポートのみの接続であるため、出力ポートｉｎｔ部（５３３２、５４３２）は他の入力ポートｉｎｔ部には未接続である。
また記憶部品ｉｎ１（１４１）、記憶部品ｉｎ２（１４２）、記憶部品ｓ３（１４３）、記憶部品ｓ４（１４４）には記憶部特定部３１１はない。
さらに各処理部品の記憶部特定部（４１２、４２２、４３２、４４２）からｏｂｊＡを保持しているクラスＡ記憶部１１１への接続がある。

＜プログラム作成装置の構成例＞
図６に本実施例のプログラム作成装置の構成例を示す。
プログラム作成装置６は、ＵＩ部６１を備える。ＵＩ部６１は、入力・指示部（指定手段）６１１と表示部６１２を備える。入力・指示部６１１は、ユーザーからキーボードやマウス、タッチパネル等の入力装置を通して入力・指示を受け付ける。また表示部６１２は、ユーザーに対して作成・編集中のデータフロープログラム（ＤＦＤやテキスト形式）やプログラム作成装置６の状態を液晶ディスプレイ等の表示装置に表示する。

ユーザーがデータフロープログラムを作成・編集する際には、適時ＵＩ部６１を通してユーザーと対話をしつつ、プログラム作成・編集部６２がプログラム管理部６４によって管理されるプログラムの作成・編集を行う。
作成したデータフロープログラムを実行する際は、ＵＩ部６１から処理制御部６３にプログラムの実行を指示し、処理制御部６３はプログラム管理部６４からプログラムの情報を得てプログラムの実行制御を行う。

プログラム管理部６４はプログラムを構成する処理部品を、処理部品共通部３１として扱い、これらの集合としてプログラムを管理する。
なお、プログラム管理部６４の集約元の多重度が０．．１となっている。これはプログラム管理部６４をプログラムの一部を管理する部として、処理制御部６３およびプログラム作成・編集部６２とは切り離した形でも用いるためである。本実施例では多重度１である。多重度０の場合については、他の実施例として後に述べる。
プログラムは、図５で示したような接続関係を持つインスタンス仕様の集合で表され、処理部品共通部３１のインスタンス仕様の集合として管理している。

図１４に実施例１のプログラム管理部がプログラムを管理している様子を示す。
プログラム作成装置２０１内のプログラム管理部２０１１は、記憶部品ｏｂｊＡ（１１）、記憶部品ｉｎ１（１４１）、記憶部品ｉｎ２（１４２）、記憶部品ｓ３（１４３）、記憶部品ｓ４（１４４）を管理している。
プログラム作成装置２０１内のプログラム管理部２０１１は、さらに処理部品Ａ１（１２１）、処理部品Ａ２（１２２）、処理部品Ａ３（１２３）、処理部品Ａ４（１２４）を管理している。
なお、図１４ではプログラム管理部２０１１が管理する処理部品共通部３１のインスタンス仕様として表している。具体的には、処理部３１２を継承したクラス（クラスＡ記憶部３２１、ｉｎｔ記憶部３２２、処理部Ａ１〜処理部Ａ４（３３１〜３３４））のインスタンス仕様として表している。

＜プログラム作成・編集の流れ＞
以上のように構成されるプログラム作成装置２０１による、図１（ｃ）のプログラム作成・編集の流れについて説明する。
プログラムを新規に作成する際は、処理部品がひとつもないため、プログラム管理部２０１１が管理する処理部品共通部３１はひとつもない。
ここで入力・指示部６１１により、処理部品Ａ１（１２１）を表示部６１２上に配置する指示を行う。

プログラム作成・編集部６２はこの指示を受けて、処理部品Ａ１（１２１）を生成し、配置情報を付与してプログラム管理部２０１１に管理を依頼する。
そして表示部６１２に処理部品Ａ１（１２１）を配置・表示する。
同様に処理部品Ａ２（１２２）、処理部品Ａ３（１２３）、処理部品Ａ４（１２４）、記憶部品ｏｂｊＡ（１１）、記憶部品ｉｎ１（１４１）、記憶部品ｉｎ２（１４２）、記憶部品ｓ３（１４３）、記憶部品ｓ４（１４４）を表示部６１２に配置・表示する。

＜処理部品間の接続＞
処理部品間のデータフローによる接続関係の確立も同様である。入力・指示部６１１により、処理部品Ａ１（１２１）から処理部品Ａ３（１２３）へのデータフローの生成を、プログラム作成・編集部６２に依頼する。するとプログラム作成・編集部６２はプログラム管理部２０１１を通して処理部品Ａ１（１２１）および処理部品Ａ３（１２３）のインスタンス仕様を得る。そして処理部品Ａ１（１２１）の出力ポートを表す出力ポートｉｎｔ部４１３２と、処理部品Ａ３（１２３）の入力ポートである入力ポートｉｎｔ部４３３１をリンク１３３で接続する。

具体的には出力ポートｉｎｔ部４１３２の入力ポートＩＦ３４１への要求インターフェースと、入力ポートｉｎｔ部４３３１の提供インターフェースである入力ポートＩＦ３４１とを結びつける。
そして表示部６１２にデータフロー１３３を表示する。この際、データフローは、一般に矢印のようなデータの流れを想起させる図形要素によって表示する。
以上のようにして処理部品間のデータフローの作成・編集が可能となる。
なお、記憶部品と処理部品間のデータフローの作成・編集も同様である。

＜処理部品と記憶部品との接続＞
次に処理部品と記憶部品との“特定”の関係を作成する。
入力・指示部６１１により、処理部品Ａ１（１２１）から記憶部品ｏｂｊＡ（１１）を特定する関係の生成をプログラム作成・編集部６２に依頼する。するとプログラム作成・編集部６２はプログラム管理部２０１１を通して処理部品Ａ１（１２１）および記憶部品ｏｂｊＡ（１１）のインスタンス仕様を得る。そして処理部品Ａ１（１２１）の記憶部特定部３１１が記憶部品ｏｂｊＡ（１１）を指定するよう、関連付ける。

そして表示部６１２に“特定”関係を表示する。この“特定”関係は、データフローで用いた図形要素とは異なり、なおかつデータの流れを想起させない図形要素によって表示する。このような図形要素の例としては、図１（ｃ）で用いているような点線があるが、本発明は点線に限定するものではない。
以上の手順を繰り返すことにより、プログラムを表示し、作成・編集することができる。
なお、処理部品や記憶部品の生成、データフローの生成、“特定”関係の生成の順序は問わない。
なお、以上はプログラム作成方法の一例であり、他の方法を用いても構わない。また、より具体的な作成方法は本発明の範囲外であるため、詳細は省略する。

＜プログラムの実行＞
次にプログラムの実行について説明する。
データフロープログラムの実行は入力・指示部６１１から処理制御部６３に伝えられる。
図７に処理制御部６３がデータフロープログラムを実行する処理の流れを示す。
まずステップＳ７１で、全処理部品および全記憶部品の取得を行う。これはプログラム管理部６４が管理している処理部品共通部３１を全て取得することによって行う。
次にステップＳ７２で、取得した各々の処理部品共通部３１の処理部３１２に対して同時に実行を指示する。この時点で、指示を受けた処理部は各々が独立して実行を始める。

＜処理部３１２での処理の流れ＞
図８に処理部３１２での処理の流れを示す。
なお、前述のとおり本実施例では記憶部品も処理部品の一形態であるため、以下では特に断りのない限り、“処理部品”と言った場合には“記憶部品”も含むものとする。
各処理部品の処理は、全ての処理部品に共通な、処理の実行を制御する処理部３１２と、各処理部品に特有な処理を行う処理部（３３１〜３３４）および記憶部（３２）で行う。
たとえば、処理部品Ａ１（１２１）の処理は処理部３１２および処理部Ａ１（３３１）で行い、処理部品Ａ２（１２２）の処理は処理部３１２および処理部Ａ２（３３２）で行う。処理部品Ａ３（１２３）の処理は処理部３１２および処理部Ａ３（３３３）で行い、処理部品Ａ４（１２４）の処理は処理部３１２および処理部Ａ４（３３４）で行う。

また、記憶部品ｏｂｊＡ（１１）の処理は処理部３１２および記憶部３２で行う。
各処理部品に特有の処理は、処理部３１２の実行制御によって呼び出される。
処理部３１２では、まず、ステップＳ８１で入力ポートのデータチェックを行う。
データフローの考え方に則り、処理部品に特有の処理は、該処理部品の全ての入力ポートに入力データフローからデータが到着してから行われる。そこで処理部３１２は、全ての入力ポートに対応する入力ポートＩＦ３４１にデータが到着するまで待つ。

入力ポートは、入力されるデータの種類（型）に応じて、その実装が定められている。処理部品Ａ１（１２１）の場合、ｉｎｔ型データがひとつ入力されるので、入力ポートｉｎｔ部３５１がひとつ（４１３１）、処理部Ａ１（４１１）に接続される。
なお、ｉｎｔ型以外の入力ポートであれば、対応する不図示の入力ポート部を用いる。
また入力ポートが複数ある場合は該個数の入力ポート部が、処理部品に特有の処理を行う処理部に接続される。たとえば処理部品Ａ４（１２４）はｉｎｔ型データの入力ポートがふたつあるため、処理部Ａ４（４４１）には入力ポートｉｎｔ部がふたつ（４４３１、４４３３）接続される。

記憶部品に関しても同様で、たとえば記憶部品ｓ３（１４３）は、ｉｎｔ型データをひとつ入力可能であるので、ｉｎｔ記憶部５３１には、入力ポートｉｎｔ部３５１がひとつ（５３３１）接続される。なお記憶部品ｉｎ１（１４１）および記憶部品ｉｎ２（１４２）は入力ポートにデータフローは接続されていないが、入力ポートｉｎｔ部３５１は備える（５１３１、５２３１）。また記憶部品ｏｂｊＡ（１１）はｏｂｊＡ型のデータを入力できる不図示の入力ポートがひとつ、クラスＡ記憶部１１１に接続される。

これらの入力ポートの実装では、次に述べるように処理部３１２で入力ポートを管理するため、あらゆる型の入力ポートに共通するインターフェースである入力ポートＩＦ３４１を実現している。
処理部３１２は、処理部品の全ての入力ポートに対応する入力ポートＩＦ３４１を管理しており、ステップＳ８１ではこれら全ての入力ポートＩＦ３４１に対して、データが到着しているか否かのチェックを行う。

もし、データが到着していない入力ポートがあった場合、ステップＳ８１１でいずれかの入力ポートにデータが到着するまで待つ。いずれかの入力ポートにデータが到着すると、再度ステップＳ８１にて、全入力ポートのデータが到着しているか否かをチェックする。
全入力ポートにデータが到着している場合、ステップＳ８２で全ての出力ポートに空きがあるか否かをチェックする。
処理部品は処理結果を、出力ポートを通じて出力する。もし出力ポートに後続する処理部品が接続されており、後続処理部品がまだ古いデータを読み出していない場合、処理部品はその結果を出力ポートに対して出力することができない。そこで全ての出力ポートに空きができるまで、処理の継続実行を抑制する。

出力ポートは、出力されるデータの種類（型）に応じて、その実装が定められている。処理部品Ａ１（１２１）の場合、ｉｎｔ型データがひとつ出力されるので、出力ポートｉｎｔ部３５２がひとつ（４１３２）、処理部Ａ１（４１１）に接続される。
なお、ｉｎｔ型以外の出力ポートであれば対応する不図示の出力ポート部を用いることや、出力ポートが複数ある場合は該個数の出力ポート部が処理部品に特有の処理を行う処理部に接続されることは、入力ポートの場合と同様である。
これらの出力ポートの実装では、入力ポートのときと同様に処理部３１２で出力ポートを管理するため、あらゆる型の出力ポートに共通するインターフェースである出力ポートＩＦ３４２を実現している。

処理部３１２は、処理部品の全ての出力ポートに対応する出力ポートＩＦ３４２を管理しており、ステップＳ８２ではこれら全ての出力ポートＩＦ３４２に対して、出力済みの古いデータが残っていないかどうかのチェックを行う。
もし、古いデータが残っている出力ポートがあった場合、ステップＳ８２１でいずれかの出力ポートに空きができるまで待つ。いずれかの出力ポートに空きができると、再度ステップＳ８２にて、全出力ポートに古いデータが残っていないかどうかをチェックする。

全出力ポートに古いデータが残っていなかった場合、ステップＳ８３で記憶部の特定を行う。
なお、処理部品Ａ１（１２１）のように、出力ポートに他の処理部品の複数の入力ポートが接続されている場合、それらの入力ポートの全てがデータを読み込んだ時点で出力ポートが空いている、と判断する。
処理部３１２には記憶部特定部３１１がひとつ関連しており、さらに記憶部特定部３１１は高々ひとつの記憶部３２と関連付けられている。

図４（ａ）の例では、処理部Ａ１（４１１）に記憶部特定部４１２が接続されており、さらに記憶部特定部４１２とｏｂｊＡのデータを保持している記憶部品ｏｂｊＡ（１１）が接続されている。
処理部３１２は記憶部特定部３１１に対して、特定している記憶部の取得を依頼する。図４（ａ）の場合、クラスＡ記憶部１１１（記憶部品ｏｂｊＡ（１１））が返されることになる。

なお特定している記憶部がない場合はその旨が返される。また、処理部品が記憶部品である場合は、記憶部特定部３１１そのものが存在しないが、この際にも特定している記憶部がないものとして扱う。
ここまでで、処理部品に特有の処理を実行する条件が整ったので、ステップＳ８４で全ての入力ポートから入力データを読み込み、ステップＳ８５で処理部品に特有の処理を行い、ステップＳ８６で処理結果を出力データとして全ての出力ポートに書き出す。

処理部品Ａ１（１２１）の場合、ステップＳ８４で入力ポートｉｎｔ部４１３１から入力データを読み込み、ステップＳ８５で処理部Ａ１（４１１）の処理を行い、ステップＳ８６で処理結果を出力データとして出力ポートｉｎｔ部４１３２に出力する。
なお、処理Ｓ８５内では入力データの他に、必要に応じて、記憶部品ｏｂｊＡ（１１）に保持されているｏｂｊＡのデータの一部または全部を参照する（Ｓ８５１）ことができる。またｏｂｊＡのデータを更新する（Ｓ８５２）こともできる。

なお、記憶部品ｉｎ１（１４１）や記憶部品ｉｎ２（１４２）のように入力ポートに繋がるデータフローがない場合には、その入力ポートは存在しないものとして扱う。入力ポートがひとつもない場合には、ステップＳ８４での入力データ読込は行わない。
また、記憶部品ｓ３（１４３）や記憶部品ｓ４（１４４）のように出力ポートに繋がるデータフローがない場合には、その出力ポートは存在しないものとして扱う。出力ポートがひとつもない場合には、ステップＳ８６での出力データ書出は行わない。

次にステップＳ８７で入出力ポート数のチェックを行う。入力ポート、出力ポートのどちらも１つもない処理部品の場合、処理を継続する状況にはならないため、ここで処理を終了する。
入力ポートまたは出力ポートのいずれかがある場合には、再度ステップＳ８１に戻る。
なお、本実施例では記憶部３２も処理部３１２を継承しているが、記憶部品ｏｂｊＡ（１１）は他の処理部品と接続していないため、入力ポートや出力ポートはない。

それゆえ、ステップＳ８１、ステップＳ８２のチェックによってステップＳ８１１やステップＳ８２１に移行することはなく、ステップＳ８３に移行する。またステップＳ８４やステップＳ８６は何もすることがない。
さらにステップＳ８３では特定する記憶部がなく、ステップＳ８５においては記憶部品ｏｂｊＡ（１１）に特有の処理はないため、何もしない。すなわち、記憶部品ｏｂｊＡ（１１）における処理部３１２の処理は、実質何もしない。さらにステップＳ８７で入出力ポートが１つもないため、ここで処理を終了する。

記憶部品ｉｎ１（１４１）や記憶部品ｉｎ２（１４２）の場合は、入力ポートがないため、ステップＳ８１のチェックにより即座にステップＳ８２に移行する。また、ステップＳ８３では特定する記憶部はないものとし、ステップＳ８４では何もしない。さらにステップＳ８５では入力がないため、何も行わない。ステップＳ８６では、ｉｎｔ記憶部３２２内の不図示のｉｎｔ型データ記憶域にあるデータを出力ポートに書き出す。

同様に記憶部品ｓ３（１４３）や記憶部品ｓ４（１４４）の場合は、出力ポートがないため、ステップＳ８２のチェックにより即座にステップＳ８３に移行する。また、ステップＳ８３では特定する記憶部はないものとする。ステップＳ８４で入力ポートからデータを読み込んだ後、ステップＳ８５では、ｉｎｔ記憶部３２２内の不図示のｉｎｔ型データ記憶域にデータを保管する。この際、特定する記憶部がないため、ステップＳ８５１、ステップＳ８５２には移行しない。ステップＳ８６では出力ポートがないため、何もしない。
以上が各処理部品における処理部３１２の処理の流れである。

さて、処理制御部６３は、ステップＳ７２で全処理部を実行する。各処理部品は独立して動作するため、全ての処理部品の処理動作が終了するまでプログラムの動作は継続する。
ステップＳ７３で、プログラムの終了検知を行う。これには、全処理部品が処理動作を行っていない状態を確認すればよい。

まず、各々の処理部３１２に対して、現在の状態を問い合わせる。
問い合わせ結果は各処理部３１２がステップＳ８１１またはステップＳ８２１において、ポート待ち状態（入力ポートにデータが来るのを待っているか、あるいは出力ポートに空きができるのを待っている状態）であるか否かである。
全ての処理部３１２がポート待ち状態である場合、ステップＳ７４にて、全処理部に対して終了指示を出す。

終了指示が出されると、各処理部３１２はステップＳ８１１またはステップＳ８２１の状態から抜け、終了する。また処理制御部６３もデータフロープログラムの実行を終了する。いずれかの処理部３１２がポート待ち状態ではない場合、再度ポート待ち状態をチェックし、全ての処理部３１２がポート待ち状態になるまで待つ。
なお、前述の記憶部品ｏｂｊＡ（１１）のように、既に処理を終了している処理部品の場合、問い合わせを受けた処理部品は「ポート待ち状態」であると返答する。
以上で、データフロープログラムの実行を説明した。

なお、ここで示したデータフロープログラムの実行制御方法は、全処理部が独立して同時に実行を開始しているが、これはひとつの例であり、他の制御手法を用いても構わない。
たとえば一時期には高々ひとつの処理部しか実行しないようなシリアル実行制御手法を用いてもよい。この場合、入力ポートからデータが入ってくることを契機に処理を実行してもよいし、プログラム全体の最終出力ポートから処理を逆順に追っていって、必要な処理を実行させるようにしてもよい。これらはＰｕｓｈ型、Ｐｕｌｌ型と呼ばれるデータフロープログラムの実行制御手法であり、一般に知られたものであるため、詳細は省略する。

また、本実施例では、記憶部３２は処理部３１２を継承しているが、継承しない実装も可能である。その場合、プログラム管理部６４は、データフロープログラム全体を管理するために、処理部品共通部３１に加えて記憶部３２も管理するようにすればよい。
さらに、本実施例で示した構成は本発明を実施する際の例であり、他の構成でも構わない。本実施例は、ステップＳ８３、ならびにステップＳ８５から呼び出されるステップＳ８５１およびステップＳ８５２に特徴があり、他のステップに関しては他の制御手法を用いても構わない。
また、本実施例では図１（ｃ）で示すように図形要素を用いてＤＦＤでプログラムを記述することを念頭に置いて説明を行ったが、図２（ａ）のようなコードでのプログラム記述を行うプログラム作成装置においても、処理の流れは同様である。

以上により、オブジェクトと入出力データを容易に区別することが可能になるため、プログラムの可読性が向上する、という効果がある。
さらに、同様の理由により、データフローの経験が乏しいオブジェクト指向経験者にとって、プログラム開発効率の低下を低減させる、という効果がある。
さらに、オブジェクト指向で開発した処理アルゴリズムやプログラムを、データフロープログラムの部品として使うことが容易になり、プログラムの再利用性を向上させる、という効果がある。

［実施例２］
図９は本実施例のプログラム作成装置で扱うプログラムの別の例である。
図９（ａ）は図１（ｂ）に相当する図であり、コンパイラに特定の情報を渡すために使用するプラグマを用いた例である。本実施例のプログラム作成装置を用いて、図９（ａ）のプログラムをＤＦＤで記述したものが図９（ｂ）である。基本的には図１（ｃ）のプログラムを生成する場合と同様の手順で、図９（ｂ）のプログラムが生成される。

＜プログラムを生成する処理の手順＞
１）まず、メイン部分に着目する。
２）オブジェクト変数ｏｂｊＡと、入力変数ｉｎ１，ｉｎ２とを記憶部品として配置・表示する。
３）関数ｆｕｎｃに注目する。関数ｆｕｎｃに相当する複合処理部品９１を配置・表示する。
４）ｏｂｊＡはオブジェクトであるから、複合処理部品９１とｏｂｊＡに対応する記憶部品との間を点線で結ぶ。
５）関数ｆｕｎｃの中身に対する処理は、図１（ｃ）を生成する処理と同様である。

図９（ａ）において、関数ｆｕｎｃの第一引数がオブジェクトであることは、ｆｕｎｃの定義の上の行の＃ｐｒａｇｍａ ｄａｔａｆｌｏｗ（）ディレクティブでｏｂｊｅｃｔと宣言されていることからわかる。ここでは、引数が１なので、１番目の引数がオブジェクトである、ということを示す。
なお、ｐｒａｇｍａディレクティブは、本変換（図９（ａ）から図９（ｂ）の生成）を実施する実体（コンパイラ）が理解するものである。一般のＣ＋＋コンパイラは理解できないため、無視する。

図１とほぼ同様であるが、処理部品（１２１〜１２４）、記憶部品（１４３、１４４）およびそれらの間を結ぶデータフローが、データフロープログラムとして複合部品９１に内包されている。さらにこれらの処理部品（１２１〜１２４）は、記憶部品ｏｂｊＡ（１１）を“特定”せずに、複合部品９１が記憶部品ｏｂｊＡ（１１）を“特定”している。
複合部品とはデータフロープログラムを内包することができる処理部品であり、複合部品の“処理”とは内包するデータフロープログラムの実行を指す。

なお図９に示す例では複合部品９１の外部からの入力データフロー（１３１、１３２）が、内包するデータフロープログラムを構成する処理部品Ａ１（１２１）、処理部品Ａ２（１２２）に直接入力されている。複合部品を用いたデータフロー記述では、このように記述する場合と、複合部品の内外の界面に位置するポートを用いる場合がある。このポートは複合部品外部から見ると入力ポートとして、内部から見ると出力ポートとして見えるものである。

また、複合部品内部の処理部品から外部の処理部品へのデータフローがある場合にも同様のポートを用いることができる。この場合、内部から見ると入力ポートとして、外部から見ると出力ポートとして見える。
本発明はいずれかの場合に限定するものではないが、本実施例では図９に示すように前者の場合（複合部品の内外の界面に位置するポートを用いない場合）について説明する。

図１では処理部品Ａ１（１２１）〜処理部品Ａ４（１２４）は、記憶部品ｏｂｊＡ（１１）をオブジェクトｏｂｊＡそのものとして“特定”していた。しかし図９では処理部品Ａ１（１２１）〜処理部品Ａ４（１２４）を含む複合部品９１が記憶部品ｏｂｊＡ（１１）を“特定”している。
このように、個々の処理部品が記憶部を特定せず、その処理部品を含む複合部品が記憶部を特定する場合には、処理部品は所定の処理を実行する際に、前記記憶部に対して、記憶部が保持する一部または全部のデータを任意のタイミングで読み書きできる。

このような記述方法を用いることにより、プログラム開発者はメソッド（メンバ関数）を表す処理部品の各々が、対応するオブジェクトである記憶部を特定する記述を行わなくて済む。
以下では、これまで説明してきた仕組みを実現する、具体的な構成および動作に関して説明する。

図１０は複合部品に関するクラス図である。
複合部品は既に説明を行った、複合部品ではない処理部品と同様に、処理部３１２を継承した部品複合部１０１を持ち、記憶部特定部３１１により記憶部３２を特定する。
また部品複合部１０１は、内包するデータフロープログラムを、処理部品共通部３１の集合として、プログラム管理部６４が保持する。
複合部品はデータフロープログラムの階層化を支援する。すなわち、各処理部品は直接的に内包される複合部品のプログラム管理部６４によって保持され、最上位の処理部品のみが図６で示したプログラム作成装置６のプログラム管理部６４によって保持される。

図１１に図９のＤＦＤに対応するインスタンス仕様の構造を示す。図１１Ａは処理部品間の関係を表したもので図５に対応する。図１１Ｂはプログラムを管理している様子を表したもので図１４に対応する。
図５と図１１Ａを比較すると、新たに加わった処理部品として、複合部品９１が増えている。また各処理部品内の記憶部特定部（４１２、４２２、４３２、４４２）からｏｂｊＡを保持しているクラスＡ記憶部１１１への接続がなくなっている。その代わりに複合部品９１内の記憶部特定部９１３からクラスＡ記憶部（１１１）への接続がある。
複合部品９１と処理部品Ａ１（１２１）〜処理部品Ａ４（１２４）、記憶部品ｓ３（１４３）、記憶部品ｓ４（１４４）との内包関係は、図１１Ｂに表されている。

実施例１では図１４に示すように、記憶部品を含むすべての処理部品がプログラム管理部２０１１によって直接管理されていた。しかし、実施例２では図１１Ｂに示すように複合部品９１に内包される処理部品は、複合部品９１内のプログラム管理部９１２によって管理される。
プログラム作成装置２０１のプログラム管理部２０１１が最上位の処理部品として、以下の４つの部品を管理する。
・複合部品９１（部品複合部９１１）
・記憶部品ｏｂｊＡ（１１）（クラスＡ記憶部１１１）
・記憶部品ｉｎ１（１４１）（ｉｎｔ記憶部５１１）
・記憶部品ｉｎ２（１４２）（ｉｎｔ記憶部５２１）
そして複合部品９１内のプログラム管理部９１２が、内包する以下の６つの部品を管理する。
・処理部品Ａ１（１２１）〜処理部品Ａ４（１２４）内の処理部Ａ１、Ａ２、Ａ３、Ａ４（４１１、４２１、４３１、４４１）
・記憶部品ｓ３（１４３）のｉｎｔ記憶部（５３１）
・記憶部品ｓ４（１４４）のｉｎｔ記憶部（５４１）

次にこの構成において、プログラムの実行について説明する。
実施例１と同様に、プログラム作成装置２０１（プログラム作成装置６のインスタンス仕様）内の処理制御部６３は、図７の通りに処理を行う。
ステップＳ７１で、プログラム管理部２０１１が管理している以下の処理部品を得る。複合部品９１、ｏｂｊＡを保持している記憶部品ｏｂｊＡ（１１）、記憶部品ｉｎ１（１４１）および記憶部品ｉｎ２（１４２）

ステップＳ７２ではこれら全ての処理部品の処理部３１２に対して実行を指示する。
各々の処理部３１２の処理は図８に従って、既に説明したように実行される。
記憶部品ｏｂｊＡ（１１）においては、実施例１と同様、結果的に何も処理を行わない。
記憶部品ｉｎ１（１４１）においては、実施例１と同様、ｉｎｔ記憶部５１１内の不図示のｉｎｔ型データ記憶域にあるデータを、出力ポートｉｎｔ部５１３２を通して出力ポートに書き出す。

記憶部品ｉｎ２（１４２）においても、実施例１と同様である。
複合部品９１においては、入力ポート、出力ポートともに存在しないので、ステップＳ８１、ステップＳ８２を素通りし、ステップＳ８３にて記憶部の特定を行う。記憶部特定部９１３に問い合わせ、記憶部品ｏｂｊＡ（１１）を特定する。
ステップＳ８４は、入力ポートが存在しないために何もしない。
ステップＳ８５では、部品複合部９１１に対して、複合部品特有の処理の実行を指示する。

図１２に部品複合部９１１の、複合部品特有の処理（部品複合部１０１特有の処理）の流れを示す。“複合部品特有の処理”とは、複合部品が内包するデータフロープログラムの実行制御処理である。
なお以下の説明では、複合部品から見た場合、該複合部品に内包される処理部品を“子処理部品”と呼び、子処理部品から見た前記複合部品を“親複合部品”と呼ぶ。また複合部品から見た該複合部品自身を“自複合部品”と呼ぶ。
さらに子処理部品の処理部を“子処理部”と呼び、子処理部品の記憶部特定部を“子記憶部特定部”と呼び、親複合部品の処理部を“親処理部”と呼ぶ。また、自複合部品の処理部を“自処理部”と呼び、自複合部品の記憶部特定部を“自記憶部特定部”と呼ぶ。

まずステップＳ１２１で、複合部品の全ての子処理部品を取得する。これは該複合部品のプログラム管理部９１２が管理している処理部品共通部３１を全て取得することによって行う。
次にステップＳ１２２で、取得した各々の子処理部品（処理部品共通部３１）の子処理部３１２を通して、子記憶部特定部３１１が特定する記憶部３２を更新する。
この際、自複合部品の自処理部は子処理部に対して、自記憶部特定部が特定する記憶部を既定の記憶部として、更新処理を指示する。

図１３に更新処理の指示を受けた子処理部の処理の流れを示す。なお、“子”処理部は、図１３の説明においては“自”処理部となる。
まず、ステップＳ１３１で自記憶部特定部３１１が特定する記憶部３２があるかどうかを調べる。もし記憶部３２が特定されている場合、何もせずに更新処理を終了する。

記憶部３２が特定されなかった場合は、ステップＳ１３２に移る。そしてステップＳ１３２では、親記憶部特定部３１１が特定する記憶部３２（親処理部から更新処理を指示された際に、既定の記憶部として提示された記憶部）が自処理部品に対応する型か否かをチェックする。
自処理部品に対応する型とは、自処理部品の処理を実行する際に必要となる記憶部の型である。たとえば、処理部品Ａ１（１２１）は、クラスＡのオブジェクトのメソッド（メンバ関数）として実装されている。この場合、「記憶部３２が対応する型である」とは、提示された記憶部３２がクラスＡを保持するための記憶部であるクラスＡ記憶部３２１である、ということである。

型が一致しない場合、そもそも自処理部品の処理を実行できないため、チェックが必要となる。そこで、もし、型が異なれば何もせずに更新処理を終了する。
型が一致する場合は、ステップＳ１３３で、親記憶部特定部３１１が特定する記憶部３２を、自記憶部特定部３１１が特定するよう更新する。
なお、ステップＳ１３３で更新した記憶部３２と、自処理部品との間の特定関係は、表示部６１２によって表示されることはない。

図９（または図１１Ｂ）の場合、処理部品Ａ１〜処理部品Ａ４（１２１〜１２４）のいずれの記憶部特定部（４１２、４２２、４３２、４４２）も、記憶部３２を特定していない。このため、親記憶部特定部９１３が特定する記憶部品ｏｂｊＡ（１１）を、特定するように更新する。
以上でステップＳ１２２は終了である。

次にステップＳ１２３で、取得した全子処理部品の子処理部３１２に対して実行を指示する。実行を指示された子処理部はそれぞれ独立して処理を実行する。これについては、実施例１で述べたので省略する。
さて、部品複合部９１１は、ステップＳ１２３で全子処理部３１２へ実行指示を行った後、ステップＳ１２４で終了指示を待つ。
実施例１と同様に、プログラム作成装置２０１の処理制御部６３は、ステップＳ７３でポート待ち状態チェックを行い、全処理部３１２がポート待ち状態である場合、ステップＳ７４にて、全処理部に対して終了指示を出す。

部品複合部９１１はこの終了指示を受けると、ステップＳ１２５で全子処理部に対して終了指示を出す。これで複合部品特有の処理Ｓ８５（部品複合部１０１特有の処理）は終了である。
次いで、ステップＳ８６では出力データを書き出すが、複合部品９１には出力ポートがないため、何もしない。
そしてステップＳ８７において、入出力ポートをチェックし、入出力ポートが１つもないため、処理を終了する。

なおステップＳ７３における全処理部とは、プログラム作成装置２０１のプログラム管理部２０１１が管理する全処理部品共通部３１の処理部のことである。そのため、図９または図１１における処理部品Ａ１（１２１）〜処理部品Ａ４（１２４）や記憶部品ｓ３（１４３）、記憶部品ｓ４（１４４）のような、複合部品の子処理部品は含まない。

また、複合部品に対するポート待ち状態の問い合わせに対して、その複合部品は、子処理部品のポート待ち状態により返答を行う。
図１５にこの処理の流れを示す。
まず、ステップＳ１５１で全子処理部品のポート待ち状態を問い合わせる。
次に、ステップＳ１５２で、得られたポート待ち状態が全て“ポート待ち状態”であるか否かをチェックする。

全て“ポート待ち状態”であった場合は、ステップＳ１５３で、自複合部品のポート待ち状態として“ポート待ち状態”を返す。そうでなかった場合はステップＳ１５４で“非ポート待ち状態”を返す。
以上で、最上位の処理部品（親処理部品）から子処理部品へと順に、実行指示と終了指示が出され、データフロープログラムが実行される様子を説明した。

以上により、オブジェクトを表す記憶部３２と、メソッド（メンバ関数）を表す処理部品の間の特定関係が、表記上現れないため、プログラムの可読性が上がるという効果がある。
また開発者は“特定”するオブジェクトではなく、“処理”に注力することができるため、プログラム開発効率の低下を低減させる、という効果がある。

［実施例３］
次に子処理部品が複合部品であって、さらに子処理部品を持つ場合について説明する。
図１６は本実施例のプログラム作成装置で扱うプログラムの例である。
基本的には図９（ａ）のプログラムから図９（ｂ）のプログラムを生成する場合と同様の手順で、図１６（ａ）のプログラムから図１６（ｂ）のプログラムが生成される。
図１６（ｂ）に示すように、”親複合部品”に内包される”親複合部品”が存在する場合、「子処理部品から見た親複合部品」および「その親複合部品から見た親複合部品」のいずれも、子処理部品から見た”先祖複合部品”とも呼ぶ。つまり、複合部品１６３は、処理部品Ｂ１（１６３１）から見た”先祖複合部品”と呼び、また複合部品１６１も、処理部品Ｂ１（１６３１）から見た”先祖複合部品”と呼ぶ。

＜プログラムを生成する処理の手順＞
１）まず、メイン部分に着目する。
２）オブジェクト変数ｏｂｊＢ，ｏｂｊＣ１，ｏｂｊＣ２と、入力変数ｉｎＢと、出力変数ｏｕｔＣとを記憶部品として配置・表示する。
３）関数ｏｕｔｅｒに注目する。関数ｏｕｔｅｒに相当する複合部品１６１を配置・表示する。
４）＃ｐｒａｇｍａ ｄａｔａｆｌｏｗディレクティブから、ｏｂｊＢはオブジェクトであることがわかるため、複合部品１６１とｏｂｊＢに対応する記憶部品との間を点線で結ぶ。ｏｂｊＣ１，ｏｂｊＣ２は”ｐａｓｓ”となっているので、点線で結ばない。
５）関数ｏｕｔｅｒの処理に注目する。
６）最初のｉｎｎｅｒ（）呼び出しに相当する複合処理部品１６３を配置・表示する。
７）Ｉｎｎｅｒの＃ｐｒａｇｍａ ｄａｔａｆｌｏｗディレクティブで最初の２つの引数はオブジェクトであるとわかる。しかし、ｏｕｔｅｒの＃ｐｒａｇｍａ ｄａｔａｆｌｏｗディレクティブで第一引数ｂがｏｂｊｅｃｔとなっており、既にｏｂｊＢで点線が書かれているので、複合処理部品１６３との間には線を引かない。一方、ｉｎｎｅｒの第二引数であるｃはｏｕｔｅｒの＃ｐｒａｇｍａ ｄａｔａｆｌｏｗディレクティブで”ｐａｓｓ”となっているため、ｂに相当するオブジェクトｏｂｊＣ１（１６０２）の記憶部品との間に点線を引く。
８）同様に複合処理部品１６４関連の処理も行う。
９）その他は図９を生成する場合と同様である。
なお、メイン部分の入力変数ｉｎＢは記憶部品１６２として生成し、出力変数ｏｕｔＣは記憶部品１６５として生成し、ｏｕｔｅｒ内部のｓｏ１とｓｏ２、ｉｎｎｅｒ内部のｓｉ１とｓｉ２は記憶部品として生成していないが、これはコンパイラが判断できる。この技術は一般的であるため、詳細は割愛する。

記憶部品ｉｎＢ（１６２）から処理１６３、処理１６４と処理され、記憶部品ｏｕｔＣ（１６５）に結果が出力される。
処理１６３と処理１６４は、両者ともクラスＢのメソッドである処理Ｂ１とクラスＣのメソッドである処理Ｃ１を、順に適用する。
処理１６３内の処理Ｂ１も、処理１６４内の処理Ｂ１も、同一の記憶部品ｏｂｊＢ（１６０１）を特定している。
一方、処理１６３内の処理Ｃ１（１６３２）は記憶部品ｏｂｊＣ１（１６０２）を特定し、処理１６４内の処理Ｃ１（１６４２）は記憶部品ｏｂｊＣ２（１６０３）を特定している。

図１７に図１６のプログラムが管理されている様子を示す。これは図１１Ｂに対応するものである。図１１Ｂと同様に処理部品が階層的に管理されている。
処理の流れは、実施例２で説明したものとほぼ同じであるため、異なる部分のみを説明する。
実施例２と異なる部分は、複合部品の部品複合部１０１の処理の全子記憶部特定部の更新（ステップＳ１２２）である。

記憶部特定部は、複合部品がいずれの記憶部に対してデータの読み書きをするかを定める。
複合部品は、データフロープログラムを内包し、内包したデータフロープログラムを処理内容として処理を行う部品であって、
処理部品が複合部品に直接的に内包されており、記憶部特定部により複合部品が記憶部を特定している場合に、
複合部品に直接的に内包されている処理部品は、複合部品が特定する記憶部に対してデータの読み書きをする。

図１６（ｂ）を用いて説明する。
複合部品１６３は、データフロープログラムを内包し、内包したデータフロープログラムを処理内容として処理を行う部品である。
処理部品Ｂ１（１６３１）は複合部品１６３に直接的に内包されている。記憶部特定部により複合部品１６３が記憶部品ｏｂｊＣ１（１６０２）を特定している。
このような場合に、複合部品１６３に直接的に内包されている処理部品Ｂ１（１６３１）は、複合部品１６３が特定する記憶部品ｏｂｊＣ１（１６０２）に対してデータの読み書きをする。

一方、処理部品Ｂ１（１６３１）は、複合部品１６３に直接的に内包されているが、複合部品１６１に直接的に内包されてはいない。記憶部特定部により複合部品１６１は記憶部品ｏｂｊＢ（１６０１）を特定している。
このような場合、複合部品１６１に、間接的には内包されているが、直接的に内包されていない処理部品Ｂ１（１６３１）は、複合部品１６１が特定する記憶部品ｏｂｊＢ（１６０１）に対してデータの読み書きはしない。

図１８に全子記憶部特定部の更新（ステップＳ１２２）の詳細を示す。
まずステップＳ１８１で自記憶部特定部３１１によって記憶部３２が特定されているかをチェックする。
もし記憶部３２が特定されていた場合、ステップＳ１８２で全子処理部３１２に対して、前記特定された記憶部３２を既定の記憶部として、子記憶部特定部３１１の更新を指示する。
指示を受けた子処理部３１２では、既に説明した通り、図１３の処理の流れによって更新処理を行う。
最後にステップＳ１８３で、全子処理部３１２に対して、親処理部３１２から既定の記憶部として提示された記憶部３２を既定の記憶部として、子記憶部特定部３１１の更新を指示する。
こうすることで、親処理部３１２からの自記憶部特定部３１１の更新指示一回につき、各々の子記憶部特定部３１１に対して一回または二回の更新指示を行うことになる。

図１９は、以上の処理を図１６（図１７）のプログラムに対して実行した場合の、記憶部特定部３１１の更新指示および処理部品が特定する記憶部３２の状態遷移を示す。
まずステップＳ１９０１の初期状態では、処理部品Ｂ１（１６３１）、処理部品Ｃ１（１６３２）、処理部品Ｂ１（１６４１）、処理部品Ｃ１（１６４２）のいずれも記憶部を特定していない。
次にステップＳ１９０２で複合部品１６１が複合部品１６３に対し、記憶部品ｏｂｊＢ（１６０１）を既定の記憶部として、記憶部特定部３１１を更新するよう指示する。複合部品１６３の部品複合部１６３０１はステップＳ１８１、ステップＳ１８２と処理を進める。そして、まず自記憶部特定部１６３０２が特定している記憶部品ｏｂｊＣ１（１６０２）を既定の記憶部として、処理部品Ｂ１（１６３１）の記憶部特定部を更新するように指示する。
しかし、処理部品Ｂ１（１６３１）はクラスＢのオブジェクトを要求しているのに対し、クラスＣのオブジェクトが提示されたため（ステップＳ１３２）、何もしない（ステップ１９０３）。

次に複合部品１６３の部品複合部１６３０１は処理部品Ｃ１（１６３２）に対しても同様に指示を与える。その結果処理部品Ｃ１（１６３２）は、記憶部品ｏｂｊＣ１（１６０２）を特定する（ステップＳ１９０４）。
次に複合部品１６３の部品複合部１６３０１はステップＳ１８３で、複合部品１６１から既定の記憶部として提示された記憶部品ｏｂｊＢ（１６０１）を既定の記憶部として、処理部品Ｂ１（１６３１）に更新指示を出す。その結果処理部品Ｂ１（１６３１）は記憶部品ｏｂｊＢ（１６０１）を特定する（ステップＳ１９０５）。

さらに複合部品１６３の部品複合部１６３０１は、記憶部品ｏｂｊＢ（１６０１）を既定の記憶部として処理部品Ｃ１（１６３２）に更新指示を出すが、既に記憶部は特定されているため何もしない（ステップＳ１３１、ステップ１９０６）。
これで複合部品１６３の更新処理は終了し、複合部品１６１は複合部品１６４に対し、記憶部品ｏｂｊＢ（１６０１）を既定の記憶部として、更新を指示する（ステップＳ１９０７）。

以下、同様の処理を行い、ステップＳ１９０８〜ステップＳ１９１１まで処理を進めると、処理部品Ｂ１（１６３１）、処理部品Ｃ１（１６３２）、処理部品Ｂ１（１６４１）、処理部品Ｃ１（１６４２）がそれぞれ記憶部３２を特定する。
以上で、複合部品が複合部品を内包する場合の、処理部品の記憶部の特定方法を説明した。
なお、以上の説明では、複合部品から、それが内包する処理部品へと記憶部の特定を伝播させていった。しかし本発明はこのような実施方法に限定するものではない。最下層の処理部品から、親複合部品、さらにその親複合部品と、祖先複合部品を順に辿っていき、要求する型に合った記憶部で更新してもよい。

また本実施例では記憶部の更新指示を伝播させていったが、本発明における記憶部の更新指示方法はこれに限るものではない。たとえば各処理部品ごとに特定する可能性のある記憶部を順に並べて、チェックしていってもよい。
以上のように“特定”するオブジェクトを階層化することにより、開発者はさらに“処理”に注力することができるため、プログラム開発効率の低下を低減させる、という効果がある。

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

本発明はプログラム作成装置に関し、特にプログラム開発手法としてデータフローを基本とした上で、オブジェクト指向で設計された既存資産や最新アルゴリズムの流用、オブジェクト指向での設計経験・スキルの活用を促進する場合に用いて好適なものである。

１１…オブジェクトｏｂｊＡを表す記憶部品
１２１〜１２４…処理部品
１３１〜１３７…データフロー
１４１〜１４４…プログラムの入出力となるｉｎｔ型のデータを保持する記憶部品
３１…処理部品共通部のサブシステム
３２…記憶部のクラス。記憶部特有の処理部も含む。
３２１…クラスＡ型のデータを保持する記憶部のクラス
３２２…ｉｎｔ型のデータを保持する記憶部のクラス
３３１〜３３４…処理部品特有の処理を行う処理部のクラス
３４１…入力ポートのインターフェース
３４２…出力ポートのインターフェース
３５１…ｉｎｔ型の入力ポートを表すクラス
３５２…ｉｎｔ型の出力ポートを表すクラス
６…プログラム作成装置（クラスで表したパッケージ）
６４…プログラムを処理部品共通部の集合として管理するプログラム管理部のクラス
２０１…プログラム作成装置
９１…複合部品
１０１…複合部品特有の処理を行う部品複合部のクラス
１６１，１６３，１６４…複合部品
１６２、１６５…プログラムの入出力となるｉｎｔ型のデータを保持する記憶部品
１６０１〜１６０３…オブジェクトを表す記憶部品

Claims (8)

1. データフロープログラムを作成するプログラム作成装置であって、
   前記データフロープログラムを構成する処理部品がいずれの記憶手段に対してデータの読み書きをするかを定める特定手段を備える
   ことを特徴とするプログラム作成装置。
2. 前記特定手段は、複数の前記処理部品の各々が備え、各々の前記処理部品が特定する記憶手段を定める
   ことを特徴とする請求項１記載のプログラム作成装置。
3. 処理部品と、複合部品と、前記複合部品がデータの読み書きをする記憶手段とを含むデータフロープログラムを作成し、表示手段に表示するプログラム作成装置であって、
   前記複合部品がいずれの記憶手段に対してデータの読み書きをするかを定める特定手段を備え、
   前記複合部品は、データフロープログラムを内包し、内包したデータフロープログラムを処理内容として処理を行う部品であって、
   前記処理部品が前記複合部品に直接的に内包されており、前記特定手段により該複合部品が記憶手段を特定している場合に、
   前記複合部品に直接的に内包されている前記処理部品は、前記複合部品が特定する記憶手段に対してデータの読み書きをする
   ことを特徴とするプログラム作成装置。
4. 前記処理部品がデータの読み書きをする記憶手段を定める第１の特定手段と、
   前記複合部品がデータの読み書きをする記憶手段を定める第２の特定手段と
   を備えることを特徴とする請求項３記載のプログラム作成装置。
5. 前記特定手段は、
   前記処理部品がいずれの記憶手段も特定しなかった場合に、
   前記処理部品を含む親複合部品によって特定される記憶手段、前記親複合部品の親複合部品によって特定される記憶手段、さらにその親複合部品によって特定される記憶手段というように先祖複合部品によって特定される記憶手段を順に辿っていき、
   最初に特定される記憶手段を、前記処理部品がデータの読み書きをする記憶手段と定めることを特徴とする請求項３または請求項４に記載のプログラム作成装置。
6. 前記記憶手段と前記処理部品または前記複合部品とを表示する表示手段と、
   前記処理部品と、前記処理部品または前記複合部品が特定する前記記憶手段とを指定する指定手段と
   をさらに備えることを特徴とする請求項１乃至５のいずれか１項に記載のプログラム作成装置。
7. 前記表示手段は、
   前記指定手段によって指定された前記処理部品または複合部品と、前記処理部品または前記複合部品が特定する記憶手段との特定関係を表す視覚形態を表示し、
   前記視覚形態は、
   データフロープログラムによって表される、処理部品または複合部品の処理に対する、入力データフローまたは出力データフローを表す視覚形態と異なり、さらにデータの流れを表す視覚形態とも異なる
   ことを特徴とする請求項６に記載のプログラム作成装置。
8. コンピュータを、請求項１乃至７の何れか１項に記載のプログラム作成装置が有する各手段として機能させるためのコンピュータプログラム。
   
   

Images