JP2019192158A - ビジュアルプログラミングツールを用いてフローを作成することを支援する装置および方法 - Google Patents

Abstract

【課題】ビジュアルプログラミングツールを用いたアプリケーション開発環境において、テンプレートに制約条件の事前定義が必要となると、事前定義の手間がかかり、また、当該テンプレートを利用する他の開発者の知見を反映することができない。【解決手段】フロー作成支援装置は、１以上のフローデータセットとそれの基とされたテンプレートフローデータセットとの差分を算出し、当該算出された差分から、当該テンプレートフローデータセットが示すテンプレートフローについてのノード属性間の依存関係を算出する。フロー作成支援装置は、算出された依存関係に従う通知を発行する。【選択図】図１

Description

本発明は、概して、情報通信技術およびソフトウェア開発技術、特に、ビジュアルプログラミングツールを用いてフローを作成することを支援ための技術に関する。

プログラミングツールとして、ソースコードを記述することなく、モデル図を記述することにより動作するアプリケーションソフトウェア（以下、アプリケーション）を開発できるビジュアルプログラミングツールが存在する。その一例は、オープンソースソフトウェア（ＯＳＳ）としては、Ｎｏｄｅ−ＲＥＤ（https://nodered.org/）である。ビジュアルプログラミングツールを用いたソフトウェア開発では、各種処理が表現されたノードに対して必要に応じて用途や環境その他状況に対応した値としての属性値を設定し、ノード間の関係（例えば処理の流れ）を示す結線からなるフローを作成する。属性値の例は、情報の取得先などであり、ノード間の関係の例は、データの流れ、である。開発者は、こうしたビジュアルプログラミングツールを用いることで、ソフトウェア開発の知識が十分になくとも直感的に意図した処理を行うアプリケーションを開発することができる。なお、ビジュアルプログラミングツールは、「モデル開発環境」と呼ばれてもよい。ソフトウェアの構成要素や処理単位がノードであり、ノード同士の結線は「エッジ」と呼ばれても良い。ノードとエッジは有向グラフにおける用語であり、Ｎｏｄｅ−ＲＥＤにおけるフローダイアグラムも有向グラフとして捉えることができる。本明細書において、フローダイアグラムとブロックダイアグラムと有向グラフは同義とし、フローダイアグラムは単に「フロー」と呼ぶことができ、「フロー」と「グラフ」は同義とできる。

また、ソフトウェア開発の分野では、しばしば事前に用意されたアプリケーションの雛形（以下、テンプレートと呼ぶ。カタログと呼ばれることもある）を利用することで開発期間の短縮することが行われる。ここでのテンプレートとは、アプリケーションを構成する要素間の関係や設定情報がソフトウェア的に記述されているものを指すことができる。アプリケーションの開発者はテンプレートの一覧（マーケットプレイス等とも呼ばれる）から、目的に近いテンプレートを取得し、必要な部分のみを変更することによって開発期間を短縮し、効率的にアプリケーションを開発することができる。

同様の考えをビジュアルプログラミングツールに適用することにより、アプリケーション開発者はフローのテンプレートを取得し、変更を加えることで、効率的にアプリケーション開発を行うことが期待できる。

特許文献１には、オブジェクト（ノード）同士が連携して処理を行う場合に、各オブジェクトの内部処理に用いた設定情報の制約条件を事前定義しておくことで、設定の不具合を解消する技術が開示されている。

特開２０１０−０７２８８０号公報

開発者はテンプレートを用いることによって、ビジュアルプログラミングツールを用いたアプリケーション開発において、ノードの配置やノード間の配線をゼロから行う必要はなく、アプリケーションを効率的に開発することが期待できる。しかし、開発者は、テンプレートの中身を十分に理解しているとは限らず、テンプレート理解に時間を要することがしばしばある。特に、ビジュアルプログラミングツールによる開発では、前述の通りソフトウェア開発の知識が十分になくとも直感的に開発できることがメリットであるため、この課題は、そのメリットを損なう。結果、ビジュアルプログラミングツールとテンプレート利用による効果を両立できない。例えば、あるノードに付随した属性値を変更するとき、連携した別のノードの属性値も変えなければならないケースが存在するが、テンプレートを理解していなければ気づくことは困難であり、効率的な開発ができない。

特許文献１の技術を用い、テンプレートに対応して制約条件を事前定義しておくことで、あるノードを変更したときに別のノードの変更を行うことが考えられる。

しかし、特許文献１に開示の技術では、この制約条件を事前定義しておくことが必要となる。このため、当該テンプレートを他の開発者も利用していた場合に、当該他の開発者の知見を反映することはできない。また、テンプレート個々に制約条件を事前定義するといった手間も必要となる。

フロー作成支援装置は、１以上のフローデータセットとそれの基とされたテンプレートフローデータセットとの差分を算出し、当該算出された差分から、当該テンプレートフローデータセットが示すテンプレートフローについての属性値間の依存関係を算出する。フロー作成支援装置は、算出された依存関係に関する情報の通知を発行する。

本発明によれば、テンプレートフローデータセット個々に制約条件を事前定義する必要無しに、テンプレートフローデータセットについての属性値間の依存関係を算出し、当該依存関係に関する情報の通知を発行できる。また、ビジュアルプログラミングツールでアプリケーションを開発する開発者が複数存在する場合に、あるアプリケーションの開発者は他の開発者の知見を活用することができる。

図１は、本発明の実施例１の概要を示す模式図である。 図２は、実施例１に係るシステムの構成図である。 図３は、フローデータセットの一例を示す。 図４は、テンプレート管理情報の一例を示す。 図５は、プロジェクト管理情報の一例を示す。 図６は、変更管理情報の一例を示す。 図７は、依存関係管理情報の一例を示す。 図８は、実施例１における変更分析プログラムが行う処理を示す。 図９は、実施例１における変更通知プログラムが行う処理を示す。 図１０は、実施例２におけるノード管理情報の一例を示す。 図１１は、実施例２におけるルール管理情報の一例を示す。 図１２は、実施例２におけるフロー対応情報の一例を示す。 図１３は、実施例２の概要を示す模式図である。 図１４は、実施例２における変更分析プログラムが行う処理を示す。 図１５は、実施例２における変更通知プログラムが行う処理を示す。 図１６は、実施例３におけるプロジェクト管理情報の一例を示す。 図１７は、実施例４における変更管理情報の一部の一例を示す。

以降に本発明の実施に関する例を示す。以降はいずれも本発明の特徴を説明するための例であり、本発明の実施形態を限定するものではない。

以降の説明では、「インターフェース部」は、１以上のインターフェースでよい。当該１以上のインターフェースは、ユーザインターフェース部と、通信インターフェース部とのうちの少なくとも通信インターフェース部を含んでよい。ユーザインターフェース部は、１以上のＩ／Ｏデバイス（例えば入力デバイス（例えばキーボードおよびポインティングデバイス）と出力デバイス（例えば表示デバイス））と表示用計算機とのうちの少なくとも１つのＩ／Ｏデバイスでもよいし、それに代えてまたは加えて、当該少なくとも１つのＩ／Ｏデバイスに対するインターフェースデバイスでもよい。通信インターフェース部は、１以上の通信インターフェースデバイスでよい。１以上の通信インターフェースデバイスは、１以上の同種の通信インターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以降の説明では、「メモリ部」は、１以上のメモリであり、典型的には主記憶デバイスでよい。メモリ部における少なくとも１つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。

また、以降の説明では、「ＰＤＥＶ部」は、１以上のＰＤＥＶであり、典型的には補助記憶デバイスでよい。「ＰＤＥＶ」は、物理的な記憶デバイス（Physical storage DEVice）を意味し、典型的には、不揮発性の記憶デバイス、例えばＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）である。

また、以降の説明では、「記憶部」は、メモリ部およびＰＤＥＶ部のうちの少なくとも１つ（典型的には少なくともメモリ部）である。

また、以降の説明では、「プロセッサ部」は、１以上のプロセッサである。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサであるが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサでもよい。少なくとも１つのプロセッサは、シングルコアでもよいしマルチコアでもよい。少なくとも１つのプロセッサは、処理の一部または全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）またはＡＳＩＣ（Application Specific Integrated Circuit））といった広義のプロセッサでもよい。

また、以降の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ部によって実行されることで、定められた処理を、適宜に記憶部及び／又はインターフェース部等を用いながら行うため、処理の主語が、プロセッサ部（或いは、そのプロセッサ部を有する装置）とされてもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は計算機が読み取り可能な（例えば非一時的な）記録媒体であってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

また、以降の説明では、テンプレート管理情報、変更管理情報、依存関係情報、プロジェクト管理情報、ノード管理情報、ルール管理情報及びフロー対応情報といった情報があるが、当該情報は、入力に対して出力が得られる情報である。当該情報は、どのような構造の情報でもよいし、入力に対する出力を発生するニューラルネットワークのような学習モデルでもよい。

また、以降の説明では、「データセット」とは、アプリケーションプログラムのようなプログラムから見た１つの論理的な電子データの塊であり、例えば、レコード、ファイル、キーバリューペアおよびタプルのうちのいずれでもよい。

図１は、本発明の実施例１の概要を示す模式図である。図１を用いて本発明の実施例１の概要を説明する。

テンプレートフローを示すテンプレートフローデータセットＦ１１０に関する情報を含んだテンプレート管理情報Ｔ１００を管理するテンプレート管理サーバ１００がある。また、テンプレート管理サーバ１００からダウンロードされたテンプレートフローデータセットＦ１１０（テンプレートフローデータセットＦ１１０の複製）が示すテンプレートフローを表示するビジュアルプログラミングツール４００がある。また、ビジュアルプログラミングツール４００によって作成（開発）されたフローを示すフローデータセットＦ３１０に関する情報を含んだプロジェクト管理情報Ｔ２００を管理し、ビジュアルプログラミングツール４００へのロードやビジュアルプログラミングツール４００からのセーブを可能とするレポジトリ管理サーバ３００がある。また、テンプレート管理サーバ１００やレポジトリ管理サーバ３００の情報をもとにフローの変更を分析しビジュアルプログラミングツール４００によるフロー作成を支援する変更候補管理サーバ２００（フロー作成支援装置の一例）がある。

レポジトリ管理サーバ３００は、一般的なアプリケーション開発で用いられるソースコード（今回の場合はビジュアルプログラミングツールで開発されたアプリケーションのフローデータ）を管理するためのサーバでよく、一例としてはＧｉｔＨｕｂ（https://github.com/）（登録商標）やＧｉｔＬａｂ（https://about.gitlab.com/）（登録商標）などでよい。

ビジュアルプログラミングツール４００は、クライアント端末で実行されてもよいし、クライアント端末と通信可能なサーバで実行されてもよい。ビジュアルプログラミングツール４００が提供する画面は、例えば、利用可能なノードの一覧表示用の第１のペインＦ４１０と、配置されたノードを含むフローの編集用の第２のペインＦ４２０と、フローから選択されたノードの属性値の変更用の第３のペインＦ４３０といった３つのペインを有する。

第１のペインＦ４１０では、各ノードＦ４１２が、当該ノードＦ４１２が該当する特性（Ｃａｔｅｇｏｒｙ）Ｆ４１１に分類されている。開発者は、第２のペインＦ４２０に、第１のペインＦ４１０におけるノードＦ４１２をドラッグアンドドロップなどによりノードＦ４２１として配置し、ノードＦ４２１間を結線Ｆ４２２で接続することにより関係（処理の流れ）を定義する。例えば、ノードの右側がデータの入力、ノードの左側が出力を表現している場合には、あるノードＡの右側と別のノードＢの左側をつなぐことでノードＡから得た出力をノードＢに入力することを表現できる。なお、第２のペインＦ４２０には、ダウンロードされたテンプレートフローデータセットＦ１１０が示すテンプレートフローが表示されてもよい。

また、開発者により第１のペインＦ４１０または第２のペインＦ４２０から特定のノードＦ４２１が選択されると、第３のペインＦ４３０に、選択されたノードＦ４２１のプロパティを構成するノード属性（ここではラベル（Ｋｅｙ）Ｆ４３１と属性値Ｆ４３２との組）の一覧が表示される。開発者は、第３のペインＦ４３０に表示されている属性値一覧のうち所望の属性値を変更することができる。

そして、ビジュアルプログラミングツール４００は、こうして表現されるフローに含まれるノードの処理をビジュアルプログラミングツール内で実行、または外部の処理サーバにデプロイしフローによって表現される処理を実行するアプリケーションを実行可能とする。または、ビジュアルプログラミングツール４００は、フローをもとに計算機上で実行可能なバイナリオブジェクトを生成してもよい。こうした機能を提供するためビジュアルプログラミングツール４００は、これら処理を実行する実行ボタンやデプロイボタン、またはバイナリ作成ボタンを有していてもよい。

このような構成において、アプリケーション開発者は、テンプレート管理サーバ１００に定義されたテンプレートフローデータセットＦ１１０を取得し、テンプレートフローデータセットＦ１１０が示すテンプレートフローを、ビジュアルプログラミングツール４００を用いて編集し、意図したアプリケーションのフローを作成（開発）することができる。このために、開発者は、例えばノードＢの属性値を変更する。この場合、ノードＢの属性値が変更されたことが、例えば参照符号Ｆ４２３が示すように、ノードＢのステータス「Ｃｈａｎｇｅｄ」として表示される。

ここで、開発者は、テンプレートフローを理解していない（またはテンプレートフローの理解が浅い）ため、ノードＢの属性値の変更に依存した他ノードの属性値の変更の必要性（例えば、ノードＣの属性値やノードＤの属性値の変更の必要性）が分からない。例えば、ノードＢの属性値とノードＣの属性値が同種のノード属性に属しているような場合には（例えば、ＮｏｄｅＴｙｐｅおよびＣａｔｅｇｏｒｙの少なくとも１つが同じである場合には）、ノードＢの属性値を変更したらノードＣの属性値も同様に変更することが必要となるが、開発者はこれに気づけないといった状況が生じ得る。予め依存関係が明確である属性値同士に関しては、当該依存関係を事前に定義することはできると考えられる。しかし、依存関係の事前定義は手間であり、また、必ずしも全ての属性値同士の依存関係が明確ではない。例えば、ノードＤが可視化（グラフ表示）するノードでありノードＢやノードＣの結果を表示するような場合においては、ノードＢやノードＣの属性の参照先を変更した場合、この結果が間接的にノードＤに影響する場合がある。具体的にはノードＢの属性値やノードＣの属性値が変更により大きくなったため、可視化するノードＤの属性値のレンジ（例えば棒グラフの縦軸）を合わせて変更する場合がある。実施例１に係る変更候補管理サーバ２００は、こうした間接的な属性値同士の依存関係も算出し、当該依存関係に関する情報の通知である依存関係通知を開発者に発行できる。依存関係通知の一例として、ノードＢの変更された属性値と直接的に依存関係にある属性値（ノードＣの属性値）の変更提示Ｆ４２４や、ノードＢの変更された属性値と間接的に依存関係にある属性値（ノードＤの属性値）の変更提示Ｆ４２５がある。また、依存関係通知の一例として、更に、ノードＤ（変更提示がされたノードの一例）が選択された場合、ノードＤの２以上の属性値のうち、ノードＢの変更された属性値と依存関係にある属性値（Ｖａｌ３）の強調表示Ｆ４３２がある。このように、本実施例では、或るノードの変更された属性値と依存関係にある属性値を、当該或るノードの属性値の変更に関連して変更することが望ましい属性値として、属性値同士の依存関係の事前定義無しに提示できる。なお、「依存関係にある」とは、「依存関係の強さが一定値以上である」と読み替えることもできる。

図２は、実施例１に係るシステムの構成図である。

テンプレート管理サーバ１００と、変更候補管理サーバ２００と、レポジトリ管理サーバ３００と、１または複数のビジュアルプログラミングツール４００がネットワーク５２２を介して通信する。これらサーバおよびツールは、それぞれがＣＰＵやメモリ、ハードディスクなどからなる計算機で動作する。その動作形態は、それぞれ物理的に異なる計算機上で動作していてもよいし、仮想サーバと呼ばれる物理的な計算機を論理的に分割された計算機の単位で動作していてもよい。もしくは１台の計算機または複数の計算機クラスタ上で実行されるタスク（プロセスやコンテナとも呼ばれる）単位であってもよい。本実施例では、サーバ１００、２００及び３００は、それぞれ１以上の物理計算機で構成された計算機システムであるとする。なお、サーバ１００、２００及び３００のいずれも、所定のソフトウェアがインストールされ実行されることで実現されるソフトウェアディファインドのサーバでもよい。

テンプレート管理サーバ１００は、インターフェース部２１、記憶部２２及びそれらに接続されたプロセッサ部２３を有する。インターフェース部２１によりネットワーク５２２を介した通信が可能である。記憶部２２は、テンプレート管理プログラム１１０とテンプレート管理情報Ｔ１００を格納する。テンプレート管理プログラム１１０は、プロセッサ部２３に実行される。テンプレート管理プログラム１１０は、テンプレートフローデータセットの登録、参照（外部へのテンプレートフローデータセットの提供）、検索などを行う。また、テンプレート管理プログラム１１０は、テンプレートフローデータセットを参照するためのＧＵＩ（Graphical User Interface）などを提供していてもよい。テンプレート管理情報Ｔ１００は、テンプレートフローデータセットを管理するための情報であり、詳細は図４で説明する。

ビジュアルプログラミングツール４００は、フロー編集のためのＧＵＩ（例えば、上述したペインＦ４１０、Ｆ４２０及びＦ４３０を含んだＧＵＩ）を表示するための描画プログラム４１０、フローの構成に関する情報を含んだフローデータセット５００、そのほかフロー実行プログラム４２０やフロー管理プログラム４３０、などを含む。これらのプログラムは、プロセッサ部により実行される。フロー実行プログラム４２０は、フローデータセットに記述された処理を実行するものである。実行方法は、例えば、同プログラム４２０自身が同ツール内で個々のノードに対応する処理を行いノード間の情報を中継するようなものであってもよいし、各ノードの処理をツール外部に構築しそれを呼び出すことで実現するようなものであってもよい。もしくは同プログラム４２０の代わりに、計算機上で実行可能なバイナリを生成するようなものであってもよい。フローデータセット５００の例は図３を用いて説明する。フロー管理プログラム４３０は、ビジュアルプログラミングツール４００のフロー管理を行うプログラムであり、テンプレート管理サーバ１００からテンプレートのフローデータを送受信するためのインターフェースや、レポジトリ管理サーバ３００とフローデータの送受信を行うためのインターフェース等を提供するプログラムである。

加えて、ビジュアルプログラミングツール４００またはこれを構成する各プログラムのうちいずれかが、レポジトリ管理サーバ３００からのフローデータ取得や、同サーバ３００へのフローデータ格納を実行するボタンを備えていてもよい。

また、ビジュアルプログラミングツール４００は、複数の開発者が並行して利用されてもよい。その利用形態は開発者ごとに個々のツールが提供される形であってもよいし、１つのツールの中に、個々の開発者用の描画プログラム、フローデータセット、フロー実行プログラムほかが実行されるような形であってもよい。

レポジトリ管理サーバ３００は、インターフェース部４１、記憶部４２及びそれらに接続されたプロセッサ部４３を有する。インターフェース部４１によりネットワーク５２２を介した通信が可能である。記憶部４２は、開発者により作成されたフローデータセットに関する情報を含んだプロジェクト管理情報Ｔ２００と、これを管理するためのレポジトリ管理プログラム３１０とを格納する。レポジトリ管理プログラム３１０は、プロセッサ部４３により実行される。レポジトリ管理プログラム３１０は、前述の一般的なレポジトリ管理ソフトウェアが提供する機能を有するものであり、例えば開発したアプリケーションのソースコード（フローデータセット）の管理（登録、変更及び削除等）や、同レポジトリを利用する開発者の管理、またはプロジェクト管理情報Ｔ２００の変更時の外部への通知を行うための機能が含まれる。プロジェクト管理情報Ｔ２００の詳細は図５で説明する。

変更候補管理サーバ２００は、インターフェース部３１、記憶部３２及びそれらに接続されたプロセッサ部３３を有する。インターフェース部３１によりネットワーク５２２を介した通信が可能である。記憶部３２は、テンプレート管理サーバ１００やレポジトリ管理サーバ３００から収集した情報をもとにノードやその属性値の依存関係を分析する変更分析プログラム２１０と、その結果をもとにビジュアルプログラミングツールに変更候補を通知する変更通知プログラム２２０と、そのための情報として変更管理情報Ｔ３００と依存関係情報Ｔ４００とを格納する。変更分析プログラム２１０及び変更通知プログラム２２０は、プロセッサ部３３により実行される。レポジトリ管理サーバ３００が、依存関係を算出したり算出した依存関係に従う通知を発行したりすることは、変更分析プログラム２１０や変更通知プログラム２２０のようなプログラムがプロセッサ部３３に実行されることで実現されてよい。各プログラムの処理および情報の詳細については後述する。

なお、各プログラムや情報は動作するサーバを限定するものではなく、別のサーバで動作していてもよい。例えば、変更候補管理サーバ２００に含まれる変更通知プログラム２２０は、ビジュアルプログラミングツール４００に含まれていてもよい。

図３は、フローデータセット５００の一例を示す。

フローデータセットの表現の一例としては、ＪＳＯＮと呼ばれるデータ形式である。このほかＸＭＬやＹＡＭＬなど他のデータ構造が採用されてもよい。

フローデータセット５００は、ノードごとに、ノードをフロー上で一意に識別するためのＮｏｄｅＩＤ５１０、ノードの種別（例えば、オブジェクト指向でのクラスに相当）であるＮｏｄｅＴｙｐｅ５２０、ノードの分類を示すＣａｔｅｇｏｒｙ５３０、ノードの表示名であるＮｏｄｅＮａｍｅ５４０、ノードの１以上のノード属性であるＰｒｏｐｅｒｔｙ５５０、フロー編集用のペイン（第２のペイン）Ｆ４２０での表示位置情報である座標５６０、及び、ノード間の接続関係を示すｗｉｒｅｓ５７０などを含む。

なお、座標５６０は、３次元以上であってもよい。すなわち、座標５６０は、高さや、ＵＩがタブ分けされている場合はタブのＩｎｄｅｘ情報を含んでいてもよい。また、便宜上、Ｐｒｏｐｅｔｙ５５０という構造体の中にノード属性（例えば、キー（図中ｋｅｙ１やｋｅｙ２）と属性値（図中ｋｅｙ１に対応した０）との組）を保持する形式となっているが、Ｐｒｏｐｅｒｔｙというカテゴリは存在しなくてもよい。すなわちＮｏｄｅＩＤ５１０などと並列の位置に各ノード属性の記述があってもよい。このほか、フローデータセット５００は、当該フローデータセットの基になったテンプレートフローデータセットの識別子などを含んでいてもよい。

図４は、テンプレート管理情報Ｔ１００の一例を示す。

テンプレート管理情報Ｔ１００は、テンプレートフローデータセット毎にエントリを有する。各エントリは、テンプレートフローデータセットの一意な識別子を示すＴｅｍｐｌａｔｅＩＤ Ｔ１１０と、テンプレートフローデータセットを基に生成されたフローデータセットを示すＴｅｍｐｌａｔｅＦｌｏｗＤａｔａ Ｔ１２０といった情報を格納する。ＴｅｍｐｌａｔｅＦｌｏｗＤａｔａ Ｔ１２０は、対応するフローデータセット５００（図３参照）に示すようなＪＳＯＮデータが直接格納されていてもよいし、当該フローデータセット５００の格納場所を示すポインタのようなものであってもよい。以降は便宜上、ＴｅｍｐｌａｔｅＦｌｏｗＤａｔａ Ｔ１２０の値をもってフローデータセット自体が表現されているものとして扱う。

図５は、プロジェクト管理情報Ｔ２００の一例を示す。

プロジェクト管理情報Ｔ２００は、フローデータセット毎にエントリを有する。各エントリは、ＧｒｏｕｐＮａｍｅ Ｔ２１０、ＰｒｏｊｅｃｔＮａｍｅ Ｔ２２０、ＴｅｍｐｌａｔｅＩＤ Ｔ２３０、及び、ＣｈａｎｇｅｄＦｌｏｗＤａｔａ（例えば、ソースコード）Ｔ２４０といった情報を格納する。ここでは便宜上、ソースコードとしてフローデータセットしか含んでいないが、それ以外の情報を含んでいてもよい。またＴｅｍｐｌａｔｅＩＤ Ｔ２３０は便宜上入れているが、これ以外の形態としてＣｈａｎｇｅｄＦｌｏｗＤａｔａ Ｔ２４０に含まれていてもよいし、テンプレート管理サーバ１００やレポジトリ管理サーバ３００のログからグループまたはプロジェクトとテンプレートフローデータセットとの関係を特定してもよい。

ＧｒｏｕｐＮａｍｅ Ｔ２１０に表されるグループ、およびＰｒｏｊｅｃｔＮａｍｅ Ｔ２２０に表されるプロジェクトとは、１つの形態としてはある開発者集団からなる組織（グループ）と、当該組織が開発するあるアプリケーション（プロジェクト）のソースコードと見なすことができる。以下の説明では、“ｘｘ”は、値としてのｘｘであり、“”という記号無しに表記されたｘｘは、値ｘｘから同定される要素を意味する。例えば、“ＧＲＰ１”は、値としてのＧＲＰ１であり、“”という記号無しに表記されたＧＰＲ１は、ＧＲＰ１というグループを意味する。図５の例では、ＧＲＰ１とＧＲＰ２のグループがあり、ＧＲＰ１は、ｔｅｍｐｌａｔｅ１を編集したフローデータセット（ｆｌｏｗ１−１．ｊｓｏｎ）によるアプリケーションを管理するＰＪ１と、ｔｅｍｐｌａｔｅ２を編集したアプリケーションであるＰＪ２とを開発している。なお、グループとプロジェクトの関係は１：ｎが一般的であるが、１：１の場合は、これら２つは同じであってもよい。

このほか、プロジェクト管理情報Ｔ２００は、グループまたはプロジェクト毎に、ＧｉｔＨｕｂフローやＧｉｔフロー（Ｇｉｔは登録商標）に代表される開発で用いられる、ブランチと呼ばれるソースコードのスナップショットを持っていてもよい。ブランチにはｍａｓｔｅｒブランチと呼ばれる最新の実行可能なソースコードと、現在または過去のｍａｓｔｅｒから分岐したソースコードからなる。一例としては、ｍａｓｔｅｒブランチが最新のアプリケーションのソースコードであり、次バージョンのソースコードや最新のアプリケーションのバグ修正が別ブランチとして扱われる。このような複数のブランチからなる場合においては、以降、特に指定しない場合はｍａｓｔｅｒブランチを用いることとする。これはｍａｓｔｅｒブランチが、リリースしている最新のソースコードが格納することが一般的であるためである。この代わりに対象とするソースコードのブランチとして、更新日時が最新のブランチを用いるなどのルールを設けてもよい。

また、グループ単位またはプロジェクト単位にアクセス権が管理されており、ＧＲＰ１に所属するがＧＲＰ２に所属しない開発者は、ＧＲＰ２の情報を参照できないことが一般的である。本実施例では、直接、他のグループやプロジェクトのフローデータを参照することなく、複数の開発者の知見を依存関係情報Ｔ４００（図７参照）に反映することができる。

図６は、変更管理情報Ｔ３００の一例を示す。

変更管理情報Ｔ３００は、テンプレートフローに含まれるノードの属性値が、各グループまたはプロジェクトで変更されているか否かを表現するものである。

変更管理情報Ｔ３００は、ノード属性毎にエントリを有する。１つのノード属性を例に取り（図６の説明において「対象ノード属性」）、そのノード属性に対応したエントリに格納される情報を説明する。

エントリは、対象ノード属性を含んだテンプレートフローのデータセットの識別子を示すＴｅｍｐｌａｔｅＩＤ Ｔ３１０と、対象ノード属性が関連付いたノード（テンプレートフローに含まれるノード）の識別子を示すＮｏｄｅＩＤ Ｔ３２０と、対象ノード属性に含まれるキー（属性値の識別子）を示すＮｏｄｅＫｅｙ Ｔ３３０と、対象ノード属性に含まれる属性値を示すＴｅｍｐｌａｔｅＶａｌ Ｔ３４０と、対象ノード属性又はその編集後のノード属性を含むフロー（アプリケーション）を開発しているグループおよびプロジェクトの名称であるＧｒｏｕｐＮａｍｅ Ｔ３５０およびＰｒｏｊｅｃｔＮａｍｅ Ｔ３６０と、当該フローにおける属性値（対象ノード属性中の属性値に対応する値）を示すＰｊＶａｌ Ｔ３７０と、当該フローにおける属性値（対象ノード属性中の属性値に対応する値）が対象ノード属性中の属性値が変更されたかを示すＣｈａｎｇｅｄＦｌａｇ Ｔ３８０（“ｔｒｕｅ”は変更されたことを意味）とを格納する。具体的な生成の過程および利用方法は、後述する。

図７は、依存関係情報Ｔ４００の一例を示す。

依存関係情報Ｔ４００は、テンプレートフローに含まれるノードおよびそのノード属性間の依存関係を管理する情報である。依存関係情報Ｔ４００は、テンプレートフローデータセット毎に存在する。図７の説明では、１つのテンプレートフローデータセットを例に取る。

依存関係情報Ｔ４００は、テンプレートフローにおけるノードのノード属性毎に、当該ノード属性（ＣｈａｎｇｅｄＮｏｄｅ）と、当該ノード属性以外の各ノード属性（ＲｅｌａｔｅｄＮｏｄｅ）との依存関係の強さを表す数値である依存関係値を有する。或るノード属性間について、依存関係値は、一方のノード属性（ＣｈａｎｇｅｄＮｏｄｅ）の属性値を変更したときに他方のノード属性（ＲｅｌａｔｅｄＮｏｄｅ）の属性値が変更される度合い（変更される可能性）を示す。当該度合いの一例が、条件付確率である。図の例では、ｎｏｄｅ１のｋｅｙ１に対応した属性値を変更したとき、合わせてｎｏｄｅ２のｋｅｙ３に対応した属性値が変更される条件付確率が０．８（８０％）である。本実施例では、条件付確率が扱われるが、依存関係値は、このほかに、例えば、テンプレート管理情報Ｔ１００やプロジェクト管理情報Ｔ２００から導かれたノードおよび属性によって事前定義される関数（ｆ（ＮｏｄｅＩＤ，ＮｏｄｅＫｅｙ））から得られた値であってもよい。

依存関係情報Ｔ４００の具体的な算出方法および利用方法は、後述する。

図８は、変更分析プログラム２１０が行う処理を示す。

変更分析プログラム２１０は、テンプレート管理情報Ｔ１００と、各テンプレートを利用して開発者によって開発された様々なアプリケーションの情報であるプロジェクト管理情報Ｔ２００から、変更管理情報Ｔ３００と依存関係情報Ｔ４００を生成し、属性値同士の依存関係（すなわち、あるノードの属性値が変更されたときに別のノードの属性値の変更されやすさ）を算出するプログラムである。

また、実施例１ではテンプレートフローの複製（例えば、ダウンロードされたテンプレートフローデータセットが示すテンプレートフロー）をもとにフローを作成する場合、オリジナルのテンプレートフローに含まれるノードのＮｏｄｅＩＤと、グループまたはプロジェクトにダウンロードされた当該テンプレートフロー（テンプレートフローの複製の一例）に含まれるノードのＮｏｄｅＩＤは変わらないという前提を置いている。すなわち、オリジナルのテンプレートフローとダウンロードされたテンプレートフロー（グループまたはプロジェクトにおけるテンプレートフロー）間で、同じ位置づけのノードはＮｏｄｅＩＤも同じ、という前提を置いている。仮にテンプレートフローをもとにグループおよびプロジェクトのフローを生成した際に、ＮｏｄｅＩＤが変更となるようなシステムに適用する場合は、テンプレートフローに含まれるノードのＮｏｄｅＩＤと、グループおよびプロジェクトのフローに含まれるノードのＮｏｄｅＩＤとの対応関係を別途持つなどの対応することで適用可能である。

変更分析プログラム２１０は、処理を開始し（Ｓ１００）、レポジトリ管理サーバ３００へのフローデータセットの登録を監視し、開発者による同サーバ３００へのフローデータセットの登録（フローデータセットの変更）イベントを検出する（Ｓ１１０）。

この処理の開始（Ｓ１００）とは、本システム起動時に立ち上がるような形であってもよいし、レポジトリ管理サーバ３００へのフローデータセットの登録イベントを契機として起動するような形態であってもよい。またフローデータセットの登録イベントの検出は、変更分析プログラム２１０がレポジトリ管理サーバ３００のプロジェクト管理情報Ｔ２００の変更を監視し検出するような形態であってもよい。または事前にレポジトリ管理サーバ３００に変更が発生した場合はレポジトリ管理サーバ３００が変更分析プログラム２１０に通知する設定を行っておき、レポジトリ管理サーバ３００が変更を通知するような形態（一例としてはＷｅｂＨｏｏｋという仕組み）であってもよい。

次に、変更分析プログラム２１０は、変更管理情報Ｔ３００を参照し、プロジェクト管理情報Ｔ２００の変更が新規プロジェクトの登録なのか、既存プロジェクトの変更なのか判定を行う（Ｓ１２０）。具体的には、変更管理情報Ｔ３００のＧｒｏｕｐＮａｍｅ Ｔ３５０とＰｒｏｊｅｃｔＮａｍｅ Ｔ３６０にプロジェクト管理情報Ｔ２００で今回変更が発生したフローデータセットに対応する（今回の登録イベントに対応する）ＧｒｏｕｐＮａｍｅ Ｔ２１０とＰｒｏｊｅｃｔＮａｍｅ Ｔ２２０が存在しなければ（Ｓ１２０：Ｙｅｓ）、処理がＳ１３０（新規登録）へ進み、そうでなければ（Ｓ１２０：Ｎｏ）、処理がＳ１４０（更新登録）へ進む。

新規登録の場合、変更分析プログラム２１０は、新規に登録されたグループおよびプロジェクトのフローデータセットを変更管理情報Ｔ３００に登録する（Ｓ１３０）。具体的には、変更分析プログラム２１０は、今回の登録イベントに対応するＧｒｏｕｐＮａｍｅ Ｔ２１０とＰｒｏｊｅｃｔＮａｍｅ Ｔ２２０に関連付いているＴｅｍｐｌａｔｅＩＤ Ｔ２３０を参照し、基となったテンプレートフローデータセット（参照したＴｅｍｐｌａｔｅＩＤ Ｔ２３０に対応するテンプレートフローデータセット）を特定する。そして、変更分析プログラム２１０は、当該ＴｅｍｐｌａｔｅＩＤ Ｔ２３０に対応したＣｈａｎｇｅｄＦｌｏｗＤａｔａ Ｔ２４０が示すフローデータセットに含まれるノードのＮｏｄｅＩＤおよびＮｏｄｅＫｅｙごとに、変更管理情報Ｔ３００にデータを追加する（以下、ＮｏｄｅＩＤおよびＮｏｄｅＫｅｙの組を「ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙ」と表記する）。すなわち、対象となるグループおよびプロジェクト（以下、「グループ／プロジェクト」と表記）のＣｈａｎｇｅｄＦｌｏｗＤａｔａ Ｔ２４０が示すフローデータセットに含まれる各ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙについて、変更管理情報Ｔ３００の対応するＴｅｍｐｌａｔｅＩＤ Ｔ３１０／ＮｏｄｅＩＤ Ｔ３２０／ＮｏｄｅＫｅｙ Ｔ３３０が一致する部分に、ＧｒｏｕｐＮａｍｅ Ｔ３５０（ＧｒｏｕｐＮａｍｅ Ｔ２１０に一致する値）、ＰｒｏｊｅｃｔＮａｍｅ Ｔ３６０（ＰｒｏｊｅｃｔＮａｍｅ Ｔ２２０に一致する値）、および、ＰｊＶａｌ Ｔ３７０（ＣｈａｎｇｅｄＦｌｏｗＤａｔａ Ｔ２４０に含まれる対応したＮｏｄｅＩＤ Ｔ３２０およびＮｏｄｅＫｅｙ Ｔ３３０を基に特定される値）を登録する。その上で、変更分析プログラム２１０は、ＴｅｍｐｌａｔｅＶａｌ Ｔ３４０とＰｊＶａｌ Ｔ３７０の間に変更があればＣｈａｎｇｅｄＦｌａｇ Ｔ３８０を“ｔｒｕｅ”に、なければ“ｆａｌｓｅ”を設定する。

既存データセットの更新登録の場合、変更分析プログラム２１０は、Ｓ１４０を行う。すなわち、変更分析プログラム２１０は、変更が発生したフローデータセット（ＣｈａｎｇｅｄＦｌｏｗＤａｔａ Ｔ２４０が示すフローデータセット）に含まれるＮｏｄｅＩＤ／ＮｏｄｅＫｅｙごとに、変更管理情報Ｔ３００のＴｅｍｐｌａｔｅＩＤ Ｔ３１０、ＮｏｄｅＩＤ Ｔ３２０、ＮｏｄｅＫｅｙ Ｔ３３０、ＧｒｏｕｐＮａｍｅ Ｔ３５０、ＰｒｏｊｅｃｔＮａｍｅ Ｔ３６０が一致するＰｊＮａｍｅ Ｔ３７０を、更新後のＣｈａｎｇｅｄＦｌｏｗＤａｔａ Ｔ２４０が示すフローデータセットのＮｏｄｅＩＤおよびＮｏｄｅＫｅｙで特定される値に書き換える。さらに、変更分析プログラム２１０は、書き換え後の値で、ＴｅｍｐｌａｔｅＶａｌ Ｔ３４０とＰｊＶａｌ Ｔ３７０の間に変更があれば、ＣｈａｎｇｅｄＦｌａｇ Ｔ３８０を“ｔｒｕｅ”に、なければ“ｆａｌｓｅ”を設定する。

以上の処理において、フロー開発中にノードが新規登録されたことによりテンプレートフローデータセットまたはその複製には存在しないＮｏｄｅＩＤが存在する場合がある。このような場合は、当該ＮｏｄｅＩＤを無視（対象としない）といった処理をすればよい。逆にテンプレートフローデータセットまたはその複製からフロー開発中にノードが削除された場合も、同様に当該ノードは無視（対象としない）といった処理をすればよい。

また、Ｓ１３０およびＳ１４０の変更管理情報Ｔ３００の生成および変更において、ノード属性のうち特定の情報は除外する、などの対応をしてもよい。一例としては、ノードの座標５６０やノードの表示名（ラベル）であるＮｏｄｅＮａｍｅ ５４０である。これは座標やラベルがビジュアルプログラミングツールにおいて、表示にかかわるものであって、開発されるアプリケーションの処理（機能）に寄与するものではないためである。

このように更新された変更管理情報Ｔ３００を用いて、変更分析プログラム２１０は、ノード間の依存関係を計算する処理を行い（Ｓ１５０）、処理を終了する（Ｓ１６０）。このため、テンプレートフローデータセットに基づいて開発されているグループおよびプロジェクトのフローデータセットの情報（すなわち変更管理情報Ｔ３００）に基づいて、変更分析プログラム２１０は、あるノードの属性が変更されたときに別のノードの属性が変更される可能性（条件付確率）を算出する。

一例としては、ＮｏｄｅＩＤとＮｏｄｅＫｅｙで特定されるノードの属性値ＡとＢについて、属性値Ａが変更されたときの属性値Ｂが変更される確率Ｐ（Ａ→Ｂ）は、以下数１のように計算し、依存関係（依存関係の強さ）を算出できる。

例えば、変更管理情報Ｔ３００の一例を示す図６において、ｎｏｄｅ１のｋｅｙ１の属性値が変更されたとき、変更分析プログラム２１０は、同じくｎｏｄｅ１のｋｅｙ２が変更される確率Ｐ（ｋｅｙ１→ｋｅｙ２）を計算する。数１の分母は、ＣｈａｎｇｅｄＦｌａｇ Ｔ３８０が“ｔｒｕｅ”のものがグループ／プロジェクトでＧＲＰ１／ＰＪ１の１つのため、“１”となる。一方で、数１の分子は、ｋｅｙ１のＣｈａｎｇｅｄＦｌａｇ Ｔ３８０が“ｔｒｕｅ”かつｋｅｙ２のＣｈａｎｇｅｄＦｌａｇ Ｔ３８０が“ｔｒｕｅ”のグループ／プロジェクトは存在しない（ｋｅｙ２についてＧＲＰ１／ＰＪ１はＣｈａｎｇｅｄＦｌａｇ Ｔ３８０が“ｆａｌｓｅ”のため対象にならず、ＧＲＰ３／ＰＪ４はｋｅｙ２のＣｈａｎｇｅｄＦｌａｇ Ｔ３８０は“ｔｒｕｅ”であるが前提のｋｅｙ１のＣｈａｎｇｅｄＦｌａｇ Ｔ３８０が“ｆａｌｓｅ”であるため対象とならない）ため、“０”となる。よって、変更分析プログラム２１０は、Ｐ（ｋｅｙ１→ｋｅｙ２）＝０／１＝０、といったように計算できる。

以上のように、変更分析プログラム２１０は、計算される条件付確率Ｐ（Ａ→Ｂ）を、全ＴｅｍｐｌａｔｅＩＤ Ｔ３１０、ＮｏｄｅＩＤ Ｔ３２０およびＮｏｄｅＫｅｙ Ｔ３３０の組み合わせについて計算し、テンプレート毎の依存関係情報Ｔ４００を更新する。例えば、前述の例では、ｔｅｍｐｌａｔｅ１において、Ｐ（ｎｏｄｅ１／ｋｅｙ１→ｎｏｄｅ１／ｋｅｙ２）＝０であるため、変更分析プログラム２１０は、ｔｅｍｐｌａｔｅ１に対応した依存関係情報Ｔ４００において、ＣｈａｎｇｅｄＮｏｄｅのうちの“ｎｏｄｅ１”／“ｋｅｙ１”と、ＲｅｌａｔｅｄＮｏｄｅのうちの“ｎｏｄｅ１”／“ｋｅｙ２”に対応したセルの値を更新する（０とする）こととなる。

なお、数１について、ＣｈａｎｇｅｄＦｌａｇ Ｔ３８０が“ｔｒｕｅ”であるプロジェクト数のほか、変更分析プログラム２１０は、フローの接続関係を考慮してもよい。すなわち、変更分析プログラム２１０は、フローデータセット５００の接続情報５７０などから、ノードＡとノードＢが、直接的にまたは間接的に（複数のノードを中継して）接続しているかを判定し、接続している場合にのみ分子または分母のプロジェクト数としてカウントするとしてもよい。これは、テンプレートフローには、機能または役割などの違いから互いに接続関係のない複数のフローが含まれる場合（例えば、ノードＡがノードＢに直接的にまたは間接的に接続された第１のフローと、ノードＣがノードＤに直接的にまたは間接的に接続された第２のフローがあり、第１のフローと第２のフローに接続関係がない場合）があるため、それらを独立として扱ってもよいことを意味する。

図９は、変更通知プログラム２２０が行う処理を示す。

変更通知プログラム２２０は、ビジュアルプログラミングツール４００で開発者がフローを開発する際に、依存関係情報Ｔ４００をもとに他に変更が必要なノード属性があれば、それを開発者に通知するための処理を行うものである。

変更通知プログラム２２０は、処理を開始し（Ｓ２００）、ビジュアルプログラミングツール４００を監視し、開発者による同ツール４００へのフロー変更イベントを検出する（Ｓ２１０）。

この処理の開始（Ｓ２００）とは、本システム起動時に立ち上がるような形であってもよいし、別の形態としてはビジュアルプログラミングツール４００のフロー変更イベントを契機として起動するような形態であってもよい。

またフロー変更イベントの検出方法として、変更通知プログラム２２０がビジュアルプログラミングツール４００上の変更を監視し変更を検出するような形態であってもよいし、前述のＷｅｂｈｏｏｋのようにビジュアルプログラミングツール４００にイベント通知先として変更通知プログラム２２０を登録しておきビジュアルプログラミングツール４００が同プログラム２２０に変更を検出（通知）するような形態であってもよい。または、ビジュアルプログラミングツール４００からの変更イベント検出の代替として、レポジトリ管理サーバ３００のプロジェクト管理情報Ｔ２００へのフローデータ登録が採用されてもよい。

変更通知プログラム２２０は、ビジュアルプログラミングツール４００の開発者が編集中のフローデータセット５００と、当該フローデータセット５００の基であるテンプレートフローデータセットのＴｅｍｐｌａｔｅＩＤと、当該ＴｅｍｐｌａｔｅＩＤに対応するテンプレートフローデータセットとを取得し、テンプレートフローデータセットからフローデータセット５００への編集における変更点を抽出する（Ｓ２２０）。ＴｅｍｐｌａｔｅＩＤは、プロジェクト管理情報Ｔ２００から取得され、テンプレートフローデータセットは、テンプレート管理情報Ｔ１００から取得される。また、ここでの「変更点」とは、フローデータセットとテンプレートフローデータセットとの差分の一例である。具体的には、「変更点」とは、取得されたフローデータセット５００とテンプレートフローデータセットに含まれるＮｏｄｅＩＤとＮｏｄｅＫｅｙが同じであって、これらＮｏｄｅＩＤ／ＮｏｄｅＫｅｙで特定される属性の値（属性値）が異なるものを指す。このとき、フローデータセット５００を、変更通知プログラム２２０は、ビジュアルプログラミングツール４００のＩ／Ｆ（ＡＰＩ（Application Programming Interface））を直接呼び出すことによって取得してもよいし、変更イベントの構成要素としてフローデータセット５００が含まれるようなケースでは変更イベントを参照するような形態であってもよい。また、フローデータセット５００の代わりに、変更通知プログラム２２０は、プロジェクト管理情報Ｔ２００から対応するフローデータセットを取得してもよい。

次に、変更通知プログラム２２０は、テンプレートフローデータと編集中のフローデータセット５００間でＮｏｄｅＩＤとＮｏｄｅＫｅｙが同じであって属性値が異なるＮｏｄｅＩＤとＮｏｄｅＫｅｙの組み合わせ（以下、変更対象ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループと呼ぶ）について、依存関係があるが未変更のＮｏｄｅＩＤ／ＮｏｄｅＫｅｙを抽出する（Ｓ２３０）。

具体的には、例えば、変更通知プログラム２２０は、変更対象ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループに含まれる各ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙ（以下、Ｃ）について、対応したＴｅｍｐｌａｔｅＩＤの依存関係情報Ｔ４００を参照し、数２を満たすような、ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙの組み合わせ（以下、変更候補ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループ）を抽出する。

すなわち、変更通知プログラム２２０は、Ｃが変更されたときに合わせて変更されることが多い（＝条件付き確率がθ以上である）ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙの組み合わせを抽出する。このとき、θは、事前に定義された閾値であり、ＴｅｍｐｌａｔｅＩＤごとに異なってもよいし、全体で共通であってもよい。一例としては、θは、パレート法則で用いられる０．８（８０％以上が変更していたら変更の可能性が高いとみなす）である。図７に示す依存関係情報Ｔ４００の例では、ｔｅｍｐｌａｔｅ１のｎｏｄｅ１／ｋｅｙ１をＣと見なした場合、ｎｏｄｅ２／ｋｅｙ３などが変更候補ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループに属するＮｏｄｅＩＤ／ＮｏｄｅＫｅｙとして抽出される。

そして、変更通知プログラム２２０は、未変更のＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループ（以下、未変更ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループ）を定義する。例えば、未変更ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループは、集合論的には数３のように定義される。

すなわち、変更通知プログラム２２０は、ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙが変更候補ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループに含まれていて、変更対象ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループに含まれていないＮｏｄｅＩＤ／ＮｏｄｅＫｅｙの集合、を抽出する。

次に、変更通知プログラム２２０は、依存関係にある属性値同士の全ての属性値（ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙに対応した値）が変更済みかを判定する（Ｓ２４０）。具体的には、変更通知プログラム２２０は、未変更ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループが空であるか否かを判定する。

未変更ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループが空である（すなわち全て変更済み）ならば（Ｓ２４０：Ｙｅｓ）、処理が終了する（Ｓ２６０へ進む）。

逆に、未変更ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループが空でない、すなわちあるＮｏｄｅＩＤ／ＮｏｄｅＫｅｙに合わせて変更される可能性が高いＮｏｄｅＩＤ／ＮｏｄｅＫｅｙのうち未変更のものが存在ならば（Ｓ２４０：Ｎｏ）、処理がＳ２５０へ進む。

変更通知プログラム２２０は、Ｓ２３０で未変更と判定したＮｏｄｅＩＤ／ＮｏｄｅＫｅｙの組み合わせを、Ｓ２１０で変更イベントを受領した対象のフローデータセット５００を編集中の開発者に通知する（Ｓ２５０）。具体的には、変更通知プログラム２２０は、未変更ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループに含まれるＮｏｄｅＩＤ／ＮｏｄｅＫｅｙの一覧を開発者に通知する。

通知方法としては、一例としては、図１のビジュアルプログラミングツール４００で示すように、ＵＩ（User Interface））上に表示する方法がある。この場合、変更通知プログラム２２０は、描画プログラム４１０に未変更ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループの情報を通知することで、未変更ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループに含まれるＮｏｄｅＩＤ／ＮｏｄｅＫｅｙの属性値Ｆ４３２を第３のペインＦ４３０で強調表示するほか、第２のペインＦ４２０上に、未変更ノードを意味するステータス“Ｔｏ Ｃｈａｎｇｅ”（Ｆ４２４およびＦ４２５）などを表示することができる。

加えて、ＧｒｏｕｐＮａｍｅ Ｔ２１０で特定されるグループまたはＰｒｏｊｅｃｔＮａｍｅ Ｔ２２０で特定されるプロジェクトに所属する複数の開発者がそれぞれ異なるビジュアルプログラミングツールを用いて１つのフローデータセットを編集するような場合がある（すなわち１つのフローデータセットを複数のビジュアルプログラミングツールが編集する場合がある）。このような場合には、各フローとこれを編集しているビジュアルプログラミングツール（例えばそれの識別子や通知先）の関係をレポジトリ管理サーバ３００（または、他のサーバ１００または２００）で管理しておき、この情報を元に、同一フローデータセットを編集する複数のビジュアルプログラミングツールに変更を通知するような形態であってもよい。

または別の形態として、これら変更すべきだが現時点で未変更ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙの一覧をビジュアルプログラミングツール上または別のＵＩ上で表示するような形態であってもよい。またはメールやチャットなどのコミュニケーションツールを備える開発環境では、こうした別のコミュニケーションツールを用いて前述の一覧を通知するような形態であってもよい。

表示のタイミングは、上述したように、変更イベントの検出（Ｓ２１０）に依存する。すなわち、フロー変更の都度にフローの変更イベントが検出できる場合には、ノード変更のたびに未変更ノード（ノード属性の変更が推奨されるノード）の通知をすることができる。また、ビジュアルプログラミングツール４００がレポジトリ管理サーバ３００への登録またはフロー実行プログラム４２０への実行指示ボタンを備え、これの押下を契機に変更イベントが検出できる場合には、この押下のタイミングで未変更ノードの通知をすることができる。

実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略または簡略する。

実施例１では、テンプレートフローからノード自体を変えない、すなわちノードのＮｏｄｅＩＤ、ＮｏｄｅＴｙｐｅおよびＣａｔｅｇｏｒｙといったノード実体要素（ノード実体を定義する複数のノード関連要素）が変わらないことを前提に、同時に変更されうるノードの属性値を開発者に提示する方法を示した。しかし、用途によっては、ノード実体を変更したい、すなわち、ＮｏｄｅＩＤ、ＮｏｄｅＴｙｐｅおよびＣａｔｅｇｏｒｙの少なくとも１つが変更となる場合がある。例えば、データを入力するノードについてＨＴＴＰリクエストを受け付けるノードから別のプロトコルを受け取るノードに変更する場合や、グラフで可視化するノードについて時系列で折れ線グラフ表示するノードを別の可視化方法（例えば、ある一時点のデータを可視化するゲージ表示）のノードに変更するような場合である。

実施例２は、事前にノード間の互換性の定義がされる。これにより、あるノードが別のノードに置き換わっても（ノード実体が変わっても）、フロー全体として同時に変更されうるノードの属性を開発者に提示することが可能となる。

これを実現するため、実施例２における変更候補管理サーバ２００は、実施例１で示した各情報に加え、後述のノード管理情報Ｔ５００およびルール管理情報Ｔ６００を保持し、変更管理情報Ｔ３００の代わりにフロー対応情報Ｔ７００を保持する。また、変更分析プログラム２１０は図８の処理の代わりに図１４の処理、変更通知プログラム２２０は図９の処理の変わりに図１５の処理をそれぞれ行う。

図１０は、ノード管理情報Ｔ５００の一例を示す。

ノード管理情報Ｔ５００は、ノードに関する情報を持っており、例えば、同情報Ｔ５００を基に、ビジュアルプログラミングツール４００の画面の第１のペインＦ４１０にノード一覧が表示される。同情報Ｔ５００は、ノード毎にエントリを有する。各エントリが、ＮｏｄｅＴｙｐｅ Ｔ５１０（図３に示すＮｏｄｅＴｙｐｅ５２０に対応）、Ｃａｔｅｇｏｒｙ Ｔ５２０（図３に示すＣａｔｅｇｏｒｙ５３０に対応）、ＮｏｄｅＫｅｙ Ｔ５３０（図３に示すＰｒｏｐｅｒｔｙ５５０中のｋｅｙ１、ｋｅｙ２等に対応する属性値を特定するためのラベル）およびこれらの組み合わせの特徴を表すＴａｇ Ｔ５４０を格納する。Ｔａｇ Ｔ５４０は、事前にノードやその属性値の意味や使われ方等を考慮して付与されるメタ情報である。Ｔａｇの一例としては、ＮｏｄｅＫｅｙで特定される属性値に入る値が「文字列」や「ネットワーク上の識別子（ＩＰまたはホスト名）」、等である（図１０のｔａｇの具体例ではｔａｇ４が「文字列」、ｔａｇ２が「ネットワーク識別子」が該当するとする）。

図１１は、ルール管理情報Ｔ６００の一例を示す。

ルール管理情報Ｔ６００は、ノードまたはノード属性の互換性に関するルール（具体的には、実施例２において、ビジュアルプログラミングツール４００の画面の第１のペインＦ４１０に表示されるノードまたはそれのノード属性のどれとどれを同じとして扱うかというルール）を定義する情報である。

ルール管理情報Ｔ６００は、ルール毎にエントリを有する。各エントリは、ルールの識別子であるＲｕｌｅＩＤ Ｔ６１０と、具体的なルールの記述であるＲｕｌｅｓ Ｔ６２０と、当該ルールが利用されるか否かを示すＳｅｌｅｃｔｅｄＦｌａｇ Ｔ６３０とを格納する。

Ｒｕｌｅｓ Ｔ６２０の例としては、次のようなものがある。すなわち、Ｒｕｌｅ０によれば、ノードのＮｏｄｅＩＤ／ＮｏｄｅＫｅｙが同じものは、テンプレートフローとプロジェクトによって開発されたフロー間の当該ＮｏｄｅＫｅｙで特定される属性値は同じとして扱われる。Ｒｕｌｅ１によれば、ノードの種類（ＮｏｄｅＴｙｐｅおよびＣａｔｅｇｏｒｙ）に限らずノードのＮｏｄｅＫｅｙが同じ値（同じラベル）のものは、テンプレートフローに含まれるノードが別のノードに変わったとしても（ＮｏｄｅＩＤが異なったとしても）当該ＮｏｄｅＫｅｙで特定される属性値は同じとして扱われる。Ｒｕｌｅ２によれば、ノード管理情報Ｔ５００においてノードのＣａｔｅｇｏｒｙおよび同Ｃａｔｅｇｏｒｙに含まれるＮｏｄｅＫｅｙが同じ属性値は、テンプレートフローに含まれるノードが別のノードに変わったとしても当該ＮｏｄｅＫｅｙで特定される属性値は同じとして扱われる。Ｒｕｌｅ３によれば、ｔａｇ Ｔ５４０がすべて同じであるＮｏｄｅＴｙｐｅ Ｔ５１０、Ｃａｔｅｇｏｒｙ Ｔ５２０、ＮｏｄｅＫｅｙ Ｔ５３０の組み合わせによって特定される属性値は、テンプレートフローデータに含まれるノードが別のノードに変わったとしても同じとして扱われる。このほか、例えばｔａｇが１つ以上同じ、といったルールが含まれていてもよい。

このように定義されるルールのうち、ＳｅｌｅｃｔｅｄＦｌａｇ Ｔ６３０が“ｔｒｕｅ”のルールが、後述する実施例２の変更分析プログラム２１０および変更通知プログラム２２０で考慮される。ＳｅｌｅｃｔｅｄＦｌａｇ Ｔ６３０は、環境全体を提供する管理者などによって事前に定義されている（ＳｅｌｅｃｔｅｄＦｌａｇ Ｔ６３０が“ｔｒｕｅ”のものが選択されている）ことを想定するものである。またＳｅｌｅｃｔｅｄＦｌａｇ Ｔ６３０が“ｔｒｕｅ”のものは複数選択されていてもよい。以降ではＳｅｌｅｃｔｅｄＦｌａｇ Ｔ６３０が“ｔｒｕｅ”のものが複数ある場合は論理和（すなわち、いずれか１つのルールに該当していればよい）条件として説明を進めるが、このほか論理積（全てのルールに該当していることが必要）とした処理であってもよい。

なお、図１１に示すルール管理情報Ｔ６００の例に示すルールのうち、Ｒｕｌｅ０のみを適用したものが、実施例１に相当すると見なすことができる。

図１２は、フロー対応情報Ｔ７００の一例を示す。

同情報Ｔ７００は、ルール管理情報Ｔ６００で選択されたルールに基づいて、テンプレートフローデータセットと、あるグループおよびプロジェクトによって開発されたフローデータセット（フローデータセット５００またはＣｈａｎｇｅｄＦｌｏｗＤａｔａ Ｔ２４０）とのＮｏｄｅＩＤおよびＮｏｄｅＫｅｙの対応関係を保持する情報である。

具体的には、同情報Ｔ７００は、テンプレートフローデータセットに含まれるノード属性ごとにエントリを有する。各エントリは、テンプレートフローデータセットに含まれる情報Ｔ７１０（Ｔ７１１、Ｔ７１２、Ｔ７１３、Ｔ７１４）と、グループおよびプロジェクトによって開発されたフローデータセットに含まれる情報Ｔ７２０（Ｔ７２１、Ｔ７２２、Ｔ７２３、Ｔ７２４、Ｔ７２５）と、これら２つのノード属性間で属性値が変更されているかどうかを示すＣｈａｎｇｅｄＦｌａｇ Ｔ７３０（変更管理情報のＣｈａｎｇｅｄＦｌａｇ Ｔ３８０と同種のもの）とを格納する。この情報Ｔ７１０とＴ７２０の対応は、ルール管理情報Ｔ６００を適用することで対応関係が決まるものである。

情報Ｔ７１０は、テンプレートフローデータセットの識別子であるＴｅｍｐｌａｔｅＩＤ Ｔ７１１と、当該テンプレートフローデータセットに含まれるＮｏｄｅＩＤ Ｔ７１２、ＮｏｄｅＫｅｙ Ｔ７１３、およびこれらで特定される値Ｔ７１３とを含む。情報Ｔ７２０は、開発するグループおよびプロジェクトの識別子であるＧｒｏｕｐＮａｍｅ Ｔ７２１とＰｒｏｊｅｃｔＮａｍｅ Ｔ７２２と、開発されるフローデータセットに含まれるＮｏｄｅＩＤ Ｔ７２３、ＮｏｄｅＫｅｙ Ｔ７２４、およびこれらで特定される値Ｔ７２５とを含む。

同情報Ｔ７００の読み方としては、例えば次の通りである。すなわち、１行目のエントリによれば、ｔｅｍｐｌａｔｅ１に関し、ｎｏｄｅ１／ｋｅｙ１で特定される属性値Ｘは、ＧＲＰ１／ＰＪ１によって開発されたフローデータセットのうちのｎｏｄｅ４／ｋｅｙ４１の属性値Ｙと対応しており、属性値Ｙは、属性値Ｘの変更後の値（ＣｈａｎｇｅｄＦｌａｇ Ｔ７７０が“ｔｒｕｅ”）である。

この情報Ｔ７００の生成方法については、後述する。

以上図１０〜図１２に示す情報を用いることによって、ビジュアルプログラミングツール４００の画面に表示のノードまたはそのノード属性を特定のルールに基づいてグループ化し、同一のグループ内では、仮にテンプレートフローデータセットからノード実体およびキーの少なくとも１つが変更となっても、同じとして扱うことが実現できる。その処理の概略を、図１３を用いて説明する。また具体的な処理フローについては、図１４および図１５を用いて説明する。

以降、図１３を用いて実施例２の処理、特に変更分析プログラム２１０で行う処理について概要を説明する。

まずＳｔｅｐ１として、変更分析プログラム２１０は、グループ／プロジェクトで開発されたビジュアルプログラミングツール４００のフローデータセット５００（またはレポジトリ管理サーバ３００に格納されたＣｈａｎｇｅｄＦｌｏｗＤａｔａ Ｆ３１０）と、その元となったテンプレートフローデータセットＦ１１０とに対して、（必要に応じノード管理情報Ｔ５００を用いつつ）ルール管理情報Ｔ６００で選択されたルールを適用する。これによって、テンプレートフローのＮｏｄｅＩＤ／ＮｏｄｅＫｅｙと、これと同等として扱えるＮｏｄｅＩＤ／ＮｏｄｅＫｅｙとの組み合わせを示すフロー対応情報Ｔ７００が生成される。

次にＳｔｅｐ２として、変更分析プログラム２１０は、フロー対応情報Ｔ７００をもとに、テンプレートフローに含まれるＮｏｄｅＩＤ／ＮｏｄｅＫｅｙに変換した形式で依存関係情報Ｔ４００を更新していく。すなわち、例えば、図１２に示した情報Ｔ７２０の１行目のエントリでは、ＧＲＰ１／ＰＪ１にて開発されたフローデータセットに含まれるｎｏｄｅ４／ｋｅｙ４１に対応した属性値の変更は、ｔｅｍｐｌａｔｅ１に含まれるｎｏｄｅ１／ｋｅｙ１に対応した属性値の変更と同じである、つまり、それらの属性値が対応していると見なされる。このため、それらの属性値が同じであれば、差分無しと見なされ、それらの属性値が異なっていれば、差分有りと見なされる。この結果に基づき依存関係情報Ｔ４００が更新される。

このようにテンプレートフローデータセットのＮｏｄｅＩＤ／ＮｏｄｅＫｅｙで依存関係情報Ｔ４００を定義しておくことで、開発においてノードに変更があっても、ノード属性置換の変更有無（つまりノード属性の互換性）を判定することができるようになる。

同様に、変更通知プログラム２２０の処理（詳細は図１５で示す）においても、依存関係情報Ｔ４００に対してフロー対応情報Ｔ７００を適用することで、テンプレートフローデータセットのＮｏｄｅＩＤ／ＮｏｄｅＫｅｙからフローデータセットにおけるＮｏｄｅＩＤ／ＮｏｄｅＫｅｙへ変換し、当該フローデータセットを編集するビジュアルプログラミングツール４００に、未変更のノードの属性値を通知することが可能となる。

図１４は、実施例２における変更分析プログラム２１０の処理を示す。

実施例２の変更分析プログラム２１０は、実施例１と同様の処理（Ｓ１００）を開始する（Ｓ３００）。

そして、変更分析プログラム２１０は、各ビジュアルプログラミングツール４００を監視する。変更分析プログラム２１０は、いずれかのビジュアルプログラミングツール４００にテンプレート管理サーバ１００からテンプレートフローデータセットがダウンロードされたことを検出した場合、当該テンプレートフローデータセットが新規のテンプレートフローデータセットか否かを判定する（Ｓ３１０）。この判定方法としては、変更分析プログラム２１０が個々のビジュアルプログラミングツール４００のフローデータセット５００を参照し検出するような方法であってもよいし、前述のＷｅｂＨｏｏｋのようにビジュアルプログラミングツール４００（またはそれに含まれるフロー管理プログラム４３０など）が変更分析プログラム２１０に通知するような方法であってもよい。

次に、新規テンプレートフローデータセットの取得の場合（Ｓ３１０：Ｙｅｓ）、変更分析プログラム２１０は、フロー対応情報Ｔ７００の初期設定を実施する（Ｓ３２０）。ここでの初期設定とは、フロー対応情報Ｔ７００に対して、新規テンプレートフローデータセットにおける各ノード属性について、当該ノード属性に対応したエントリを追加する。追加された各エントリでは、ＣｈａｎｇｅｄＦｌａｇ Ｔ７３０は、“ｆａｌｓｅ”である。例えば、ＧＲＰ ａ／ＰＪ ｂが用いるビジュアルプログラミングツールが、ｔｅｍｐｌａｔｅ ｎをダウンロードし、当該ｔｅｍｐｌａｔｅ ｎがｎｏｄｅ ｍ、ｋｅｙ ｌ、及び、Ｖａｌ ｖを含むときを考える。このとき、フロー対応情報Ｔ７００に、ＴｅｍｐｌａｔｅＩＤ Ｔ７１１が“ｔｅｍｐｌａｔｅ ｎ”、ＮｏｄｅＩＤ Ｔ７１２およびＴ７２３が“ｎｏｄｅ ｍ”、ＮｏｄｅＫｅｙ Ｔ７１３およびＴ７２４が“ｋｅｙ ｌ”、Ｖａｌ Ｔ７１４およびＴ７２５が“Ｖａｌ ｖ”、ＧｒｏｕｐＮａｍｅ Ｔ７２１が“ＧＲＰ ａ”、ＰｒｏｊｅｃｔＮａｍｅ Ｔ７２２が“ＰＪ ｂ”、ＣｈａｎｇｅｄＦｌａｇ Ｔ７３０が“ｆａｌｓｅ”であるようなエントリ（行）が、挿入される。

次に、変更分析プログラム２１０は、ビジュアルプログラミングツール４００上のフローデータセットに含まれるノード実体またはノード属性が変更されたか否かを判定する（Ｓ３３０）。変更がない場合は、そのまま待機する（Ｓ３１０またはＳ３３０が発生するのを待つ）。変更が発生した場合（Ｓ３３０：Ｙｅｓ）、処理がＳ３４０に進む。

Ｓ３４０（図１３のＳｔｅｐ１に対応）として、変更分析プログラム２１０は、Ｓ３３０で変更発生と判定したノードについて、ルール管理情報Ｔ６００の選択されているルール（加えて必要に応じてノード管理情報Ｔ５００）をもとに、フロー対応情報Ｔ７００を更新する（図１３の概念図のＳｔｅｐ１に対応）。

以下、Ｓ３３０の変更判定において、“ＧＲＰ ａ／ＰＪ ｂが、ビジュアルプログラミングツールを用いて開発するフロー（以下、開発フロー）の基のｔｅｍｐｌａｔｅ ｎから派生したものであり、ｔｅｍｐｌａｔｅ ｎのテンプレートフローに含まれるノードＡが開発フロー上でノードＢに変更されたとＳ３３０で判定したとして具体的に説明する。また便宜上、前述ノードＡのことを変更前ノード、ノードＢのことを変更後ノードと呼ぶこととする。

Ｓ３４０の一例では、ルールとして図１１の例に示すルールのうちＲｕｌｅ０が選択されているとする。また、変更後ノードと変更後ノードのＮｏｄｅＩＤ／ＮｏｄｅＫｅｙが同じであるとする。この場合、変更分析プログラム２１０は、変更後ノードのＮｏｄｅＩＤ／ＮｏｄｅＫｅｙで特定される属性値でＶａｌ Ｔ７２５を更新する。そして、Ｖａｌ Ｔ７１４とＴ７２５が異なる場合、変更分析プログラム２１０は、ＣｈａｎｇｅｄＦｌａｇ Ｔ７３０を“ｆａｌｓｅ”に設定する。

逆に、ＮｏｄｅＩＤが変更前ノードと変更後ノードで異なっているとする。この場合には、変更分析プログラム２１０は、そのようなノードが存在しないことを意味する空（例えば、“Ｎｏｎｅ”や“Ｎｕｌｌ”）（図１２のフロー対応情報Ｔ７００の下から２行目のエントリを参照）をＮｏｄｅＩＤ Ｔ７２３やＮｏｄｅＫｅｙ Ｔ７２４に入れる。変更分析プログラム２１０は、他にルールが選択されていなければ以上で処理を終了し、選択されていれば当該ルールに従った更新を行う。

このほかＲｕｌｅ１が選択されている場合には、変更前ノードと変更後ノードでＮｏｄｅＩＤが違っても、ＮｏｄｅＫｅｙが同じ（例えば図１０のノード管理情報Ｔ５００においてＮｏｄｅＴｙｐｅ“ｉｎｊｅｃｔ”と“ｄｅｂｕｇ”ノードはＮｏｄｅＫｅｙ Ｔ５３０“ｔｅｘｔ”が同じ）場合に、変更分析プログラム２１０は、変更前ノード（すなわちテンプレートフロー）のＮｏｄｅＩＤ／ＮｏｄｅＫｅｙと、ＧＲＰ ａ／ＰＪ ｂで特定されるエントリ（フロー対応情報Ｔ７００のエントリ（行））において、ＮｏｄｅＩＤ Ｔ７２３を変更後ノードのＮｏｄｅＩＤに変更し、Ｖａｌ Ｔ７２５を変更後ノードのＮｏｄｅＩＤ／ＮｏｄｅＫｅｙで特定される属性値に変更する。その上で、変更分析プログラム２１０は、当該エントリにおけるＣｈａｎｇｅｄＦｌａｇ Ｔ７３０を更新する。ＮｏｄｅＫｅｙが変更前ノードと変更後ノードで一致しないものについては、Ｒｕｌｅ０と同じく、変更分析プログラム２１０は、ＮｏｄｅＩＤ Ｔ７２３やＮｏｄｅＫｅｙ Ｔ７２４、Ｖａｌ Ｔ７２５に空を入れる。

このほか、例えばＲｕｌｅ２が選択されている場合には、変更分析プログラム２１０は、Ｒｕｌｅ１に加えて、ノード管理情報Ｔ５００を参照し、Ｃａｔｅｇｏｒｙ Ｔ７５２０が一致していれば、Ｖａｌ Ｔ７２５の更新処理を行い、それ以外は空を入れる。例えば図１０の例ではＮｏｄｅＴｙｐｅ“ｈｔｔｐ”と“ｍｑｔｔ”はともにＣａｔｅｇｏｒｙが“ｉｎｐｕｔ”でＮｏｄｅＫｅｙ“ａｄｒｅｓｓ”は同じと扱える。一方で、ＮｏｄｅＴｙｐｅ“ｉｎｊｅｃｔ”と“ｄｅｂｕｇ”はＮｏｄｅＫｅｙ“ｔｅｘｔ”は同じであるが、Ｃａｔｅｇｏｒｙが違うため同じと扱えない。

このほか、例えばＲｕｌｅ３が選択されている場合には、変更分析プログラム２１０は、Ｃａｔｅｇｏｒｙ同士の一致とＮｏｄｅＫｅｙ同士の一致の代わりに、ノード管理情報Ｔ５００のＴａｇ Ｔ５４０が全て一致するもの同士が同じと扱う。通常、正しくｔａｇが設定されていれば、１つのノードの中でｔａｇが全て一致するＮｏｄｅＫｅｙが複数存在することはないと考えられる。もし、ｔａｇ全て一致するＮｏｄｅＫｅｙが複数存在した場合は、それらを全て同じとして扱う、またはさらにＮｏｄｅＫｅｙや属性値が最も近いものを選択する、などの対応を、変更分析プログラム２１０は、とってもよい。

以上のようにして、変更分析プログラム２１０は、フロー対応情報Ｔ７００を更新していく。

Ｓ３５０（図１３のＳｔｅｐ２に対応）として、変更分析プログラム２１０は、このように更新されたフロー対応情報Ｔ７００から、依存関係情報Ｔ４００を更新する。計算方法は、実施例１の数１と同じでよい。すなわち、条件付確率は、テンプレートフローデータセットに含まれるＮｏｄｅＩＤ／ＮｏｄｅＫｅｙを用いて計算する。具体的には、変更分析プログラム２１０は、情報Ｔ３１０の代わりに情報Ｔ７１１を、情報Ｔ３２０の代わりに情報Ｔ７１２を、情報Ｔ３３０の代わりに情報Ｔ７１３を、情報Ｔ３５０の代わりに情報Ｔ７２１を、情報Ｔ３６０の代わりに情報Ｔ７２２を、情報Ｔ３８０の代わりに情報Ｔ７３０を用いて計算をすることとなる。また、フロー対応情報Ｔ７００においてＴｅｍｐｌａｔｅＦｌｏｗ Ｔ７１０に対応するＣｈａｎｇｅｄＦｌｏｗ Ｔ７２０が存在しないエントリがある（情報Ｔ７２３やＴ７２４に空を示す“Ｎｏｎｅ”や“Ｎｕｌｌ”が入っているエントリがある）場合、変更分析プログラム２１０は、当該エントリに関する数を、条件付き確率の計算の母数から除外するといった処理を行ってもよい。このようにテンプレートフローデータセットに含まれるＮｏｄｅＩＤ／ＮｏｄｅＫｅｙを用いることで、個々のグループおよびプロジェクトでＮｏｄｅＩＤが変更となっても、関連して変更されやすいノードおよびその属性を扱うことができるようになる。

なお、以上では、変更分析プログラム２１０がビジュアルプログラミングツール４００のフローデータセット５００を用いることでフロー対応情報Ｔ７００および依存関係情報Ｔ４００を作成および更新する例を示した。このほか、ビジュアルプログラミングツール４００のフローデータセット５００の代わりに、レポジトリ管理サーバ３００に含まれるＣｈａｎｇｅｄＦｌｏｗＤａｔａ Ｔ２４０（図１上のデータセットＦ３１０）が用いられてもよい。この場合、Ｓ３３０におけるノード変更の検出（判断）は、ビジュアルプログラミングツール上のノードの変更履歴（操作履歴）やレポジトリ管理サーバのＣｈａｎｇｅｄＦｌｏｗＤａｔａの登録履歴（変更履歴やコミット履歴とも呼ばれる）をもとに実施されればよい。もしくはＣｈａｎｇｅｄＦｌｏｗＤａｔａに含まれるノードの接続関係から、変更されたノードが判定されてもよい（例えば図１３のテンプレートフローデータセットＦ１１０が示すように、ｎｏｄｅ１がｎｏｄｅ２とｎｏｄｅ３と接続しているテンプレートが、ＣｈａｎｇｅｄＦｌｏｗＤａｔａでｎｏｄｅ４がｎｏｄｅ２とｎｏｄｅ３に接続しているフローデータとなった場合には、ｎｏｄｅ１がｎｏｄｅ４に変更された、と見なすことができる）。

図１５は、実施例２における変更通知プログラム２２０の処理を示す。

実施例２の変更通知プログラム２２０は、実施例１と同様の処理（Ｓ２００）を開始し（Ｓ４００）、同じく実施例１の処理Ｓ２１０と同様にノード変更イベントを検出する（Ｓ４１０）。

次に、変更通知プログラム２２０は、ビジュアルプログラミングツール４００で開発中のフローデータセット（もしくはレポジトリ管理サーバに登録されたフローデータセット）に含まれる各ＮｏｄｅＩＤ／ＮｏｄｅＫｅｙ（以下、対象フローＮｏｄｅＩＤ／ＮｏｄｅＫｅｙ）に対して、Ｓ４３０およびＳ４４０の処理を行う（ループ（Ａ））。以下、１つの対象フローＮｏｄｅＩＤ／ＮｏｄｅＫｅｙを例に取る。

まずＳ４３０として、変更通知プログラム２２０は、対象フローＮｏｄｅＩＤ／ＮｏｄｅＫｅｙがフロー対応情報Ｔ７００に存在し、かつ、対応するテンプレートフローデータセットのＮｏｄｅＩＤ／ＮｏｄｅＫｅｙ（以下、対応テンプレートＮｏｄｅＩＤ／ＮｏｄｅＫｅｙ）が存在するか判定する。すなわち、対象フローＮｏｄｅＩＤ／ＮｏｄｅＫｅｙがフロー対応情報Ｔ７００のＣｈａｎｇｅｄＦｌｏｗ Ｔ７２０に存在し、かつ、これに対応するＴｅｍｐｌａｔｅＦｌｏｗ Ｔ７１０のＮｏｄｅＩＤ／ＮｏｄｅＫｅｙが存在（空、Ｎｏｎｅでない値）する場合に、対応テンプレートＮｏｄｅＩＤ／ＮｏｄｅＫｅｙが存在することになる。例えば、図１２の例では、ＧＲＰ１／ＰＪ１のｎｏｄｅ４／ｋｅｙ４１が対象フローＮｏｄｅＩＤ／ＮｏｄｅＫｅｙである場合（図１２中の１行目のエントリを参照）、対応テンプレートＮｏｄｅＩＤ／ＮｏｄｅＫｅｙは存在し、ｔｅｍｐｌａｔｅ１のｎｏｄｅ１／ｋｅｙ１であると定まる。逆に、このように特定される対応テンプレートＮｏｄｅＩＤ／ＮｏｄｅＫｅｙが存在しない（空を示すＮｕｌｌやＮｏｎｅが入っている）場合には、対応テンプレートＮｏｄｅＩＤ／ＮｏｄｅＫｅｙは存在しないと定まる。

そして存在しなければ（Ｓ４３０：Ｎｏ）、次の対象フローＮｏｄｅＩＤ／ＮｏｄｅＫｅｙについて処理がＳ４３０に進む。そのような対応テンプレートＮｏｄｅＩＤ／ＮｏｄｅＫｅｙが存在する場合（Ｓ４３０：Ｙｅｓ）は、処理がＳ４４０に進む。

次にＳ４４０として、変更通知プログラム２２０は、対応テンプレートＮｏｄｅＩＤ／ＮｏｄｅＫｅｙの組み合わせに対して、依存関係情報Ｔ４００の依存関係が閾値以上と成るようなＮｏｄｅＩＤ／ＮｏｄｅＫｅｙの組み合わせ（以下、変更候補テンプレートＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループ）を抽出する（本処理の考え方はＳ２３０や数２で示すものと同じ処理）。つまり図７の例で、対応テンプレートＮｏｄｅＩＤ／ＮｏｄｅＫｅｙがｎｏｄｅ１／ｋｅｙ１であり閾値が０．８である場合、ｎｏｄｅ２／ｋｅｙ３などが変更候補テンプレートＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループに含まれることとなる。

このような変更候補テンプレートＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループに含まれるＮｏｄｅＩＤ／ＮｏｄｅＫｅｙの組み合わせに対して、変更通知プログラム２２０は、フロー対応情報Ｔ７００を用いてＳ４３０と逆の処理を行い、今回対象とするグループおよびプロジェクトのフローにおけるノードおよびその属性（変更候補フローＮｏｄｅＩＤ／ＮｏｄｅＫｅｙ）が変更済み否かを判定する。

例えば、図１２のフロー対応情報Ｔ７００において、今回判定対象とするグループ／プロジェクトが、ＧＲＰ１／ＰＪ１であり、変更候補テンプレートＮｏｄｅＩＤ／ＮｏｄｅＫｅｙが、前述のｔｅｍｐｌａｔｅ１に含まれるｎｏｄｅ２／ｋｅｙ３である例を考える。このとき、図１２のフロー対応情報Ｔ７００を用いると、今回対象となるＧＲＰ１／ＰＪ１の変更候補フローＮｏｄｅＩＤ／ＮｏｄｅＫｅｙは、ｎｏｄｅ５／ｋｅｙ６（図１２の３行目のエントリを参照）に対応すると特定できる。その上で、同行のＣｈａｎｇｅｄＦｌａｇ Ｔ７３０が“ｔｒｕｅ”となっていれば変更済み、“ｆａｌｓｅ”となっていれば未変更と判定する。なお、当該行が存在しない場合（すなわちＮｏｄｅＩＤ Ｔ７２３やＮｏｄｅＫｅｙ Ｔ７２４が空（Ｎｕｌｌ）の場合）は、変更通知プログラム２２０は、例えば対象外（通知しない）として扱う、もしくは、依存関係があるノードまたは属性が設定されていないなどと特別な通知を行うなどしてもよい。

このようにして算出される変更候補フローＮｏｄｅＩＤ／ＮｏｄｅＫｅｙの組み合わせのうち、未変更と判定された組み合わせの集合を未変更フローＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループ、と呼ぶこととする。

最後にＳ４５０として、変更通知プログラム２２０は、Ｓ４４０までで作成した未変更フローＮｏｄｅＩＤ／ＮｏｄｅＫｅｙグループに含まれるＮｏｄｅＩＤ／ＮｏｄｅＫｅｙを開発者に通知し、処理を終了する（Ｓ４６０）。なお通知の方法としては、実施例１と同様に、ビジュアルプログラミングツール４００上に表示するほか、別の方法で一覧を開発者に通知するなどとしてもよい。

実施例３を説明する。その際、実施例１および２との相違点を主に説明し、実施例１および２との共通点については説明を省略または簡略する。

これまでの実施例では、開発されるフローの前提となるテンプレートフローデータセットは１つである例を主に採用していた。しかし実際には複数のテンプレートフローデータセットを組み合わせて１つのフローを開発するといったユースケースも存在し得る。実施例３は、これを可能とした実施例である。

このように複数のテンプレートフローデータセットを基に作成された１つのフローデータセットの管理方法の一例としては、プロジェクト管理情報Ｔ２００が、図１６に示すような構成をとればよい。すなわち、ビジュアルプログラミングツール４００が持つフローデータセット５００が、どのテンプレートフローデータセットに由来するものかを分けたフローデータセット（以下、サブフローデータセット）として管理することができる。例えば、図１６において、ＧＲＰ１／ＰＪ１に対応したフローデータセットは、ｔｅｍｐｌａｔｅ１に由来するサブフローデータセットであるｆｌｏｗ１１１．ｊｓｏｎとｔｅｍｐｌａｔｅ３に由来するサブフローデータセットであるｆｌｏｗ１１３．ｊｓｏｎからなる、と管理されている。このように管理することによって、実施例１または実施例２で説明した方法を適用することができる。なおテンプレートフローデータセットに含まれない、開発者によって新規追加されたノードは、グループおよびプロジェクトのフローデータセットを構成するサブフローデータセットに含めればよい。例えば、前述の例では、そのような新規追加のノードは、ｆｌｏｗ１１１．ｊｓｏｎまたはｆｌｏｗ１１３．ｊｓｏｎのいずれかのサブフローデータセットに含めればよい。

また、これ以外の方法として、１つのフローデータセットの中に、由来するテンプレートフローデータセットの情報を持つような形態でも実現することができる。一例としては、ノードごとに、その属性値としてｔｅｍｐｌａｔｅＩＤを持つ方法である。例えば、図３に示すフローデータセットの構造体の例では、ＮｏｄｅＩＤと同じ位置づけでＴｅｍｌａｔｅＩＤを持つ、などが採用されてもよい。

実施例４を説明する。その際、実施例１〜３との相違点を主に説明し、実施例１〜３との共通点については説明を省略または簡略する。

これまでの実施例では、ノード属性の変更の順序は考慮されずに、依存関係が計算された。しかし、ビジュアルプログラミングツール４００によるフローデータセットの開発では、開発者の思考プロセスの考慮、すなわち、ノード属性の変更順序が、依存関係の計算に考慮されることが望ましい場合がある。

これを実現するため、例えばフローデータセットと合わせて、ビジュアルプログラミングツール４００、または、ビジュアルプログラミングツール４００を監視する変更候補管理サーバ２００における変更分析プログラム２１０が、ノード属性の変更順序（例えば、変更したＮｏｄｅＩＤ／ＮｏｄｅＫｅｙの順）を保持しておく。そして、開発中のフローデータセットから生成される変更管理情報Ｔ３００の各エントリにおいて、ＣｈａｎｇｅｄＦｌａｇ Ｔ３８０の代わりに、図１７に示すように、当該エントリに対応したノード属性が変更された順番（例えば最初に変更したら“１”、次は“２”、変更されていなければ“ＮＵＬＬ”など）が格納される。各ノード属性に対応した変更順番の並びが、ノード属性の変更順序である。そして、数１に代えて、属性値Ａが変更されたときの属性値Ｂが変更される確率Ｐ（Ａ→Ｂ）の計算式として、数４が採用される。

このように計算される確率で依存関係情報Ｔ４００を更新することで、ノード属性の変更順序を考慮した依存関係算出が可能となる。なお、このような理由のため依存関係情報Ｔ４００は非対称、すなわちＰ（Ａ→Ｂ）とＰ（Ｂ→Ａ）が異なる表となる（実施例１では対象、すなわちＰ（Ａ→Ｂ）とＰ（Ｂ→Ａ）が同じ表となる）。

もしくはビジュアルプログラミングツールでのノード属性変更順序の代わりに、レポジトリ管理サーバ３００へのフローデータセットの登録履歴が採用されてもよい。一般に、レポジトリ管理サーバ３００を用いた開発では、ある開発の区切り単位でソースコードをレポジトリ管理サーバ３００に登録（コミット）していく、あるいは、レポジトリ管理サーバ３００は、その登録履歴（コミット履歴などとも呼ばれる）を保持しているが、この登録履歴をノード属性の変更順序と見なして、ノード属性変更順序としての登録履歴を用いて依存関係が算出されてもよい。

以上の説明を、例えば下記のように総括することができる。なお、下記総括は、上述の説明に無い事項を含んでもよい。

変更候補管理サーバ２００（フロー作成支援装置の一例）が、変更分析部（依存関係算出部の一例）と、変更通知部（依存関係通知部の一例）とを備える。変更分析部は、変更分析プログラム２１０がプロセッサ部３３によって実行されることで実現される機能である。変更通知部は、変更通知プログラム２２０がプロセッサ部３３によって実行されることで実現される機能である。

変更分析部は、１または複数のビジュアルプログラミングツールで生成された１または複数のフローデータセットのうちの１以上のフローデータセットと、１または複数のテンプレートフローデータセットのうち前記１以上のフローデータセットの基とされたテンプレートフローデータセットである対象テンプレートフローデータセットとの差分を算出し、算出された差分から、対象テンプレートフローデータセットが示すテンプレートフローについての属性値同士の依存関係を算出する。「差分」は、ノード実体とノード属性（例えばキーと属性値との組）とのうちの少なくとも１つの差分でよい。また、ビジュアルプログラミングツール上でノード属性が変更される都度に当該変更が差分として算出されてもよいし、格納されている１以上の編集後のフローデータセットが読み出され当該読み出されたフローデータセットと当該フローデータセットの基になったテンプレートフローデータセットとの差分が算出されてもよい。また、「依存関係を算出」とは、依存関係の強さの算出でよい。「属性値同士」に含まれる属性値は、典型的に２つの属性値であるが、３以上の属性値でもよい。

変更通知部は、算出された依存関係に関する情報の通知を発行する。「通知」は、例えば、注目の属性値（例えば、変更された属性値）と当該注目の属性値以外の少なくとも１つの属性値との依存関係の強さを示す情報を含んでもよいし、注目の属性値との依存関係の強さが一定値以上の属性値を含むノード属性を示す情報を含んでもよい。

これにより、テンプレートデータセット個々に制約条件を事前定義する必要無しに、テンプレートフローについての属性値同士の依存関係を算出して当該依存関係に関する情報の通知を発行できる。また、ビジュアルプログラミングツールでアプリケーションを開発する開発者が複数存在する場合に、複数の開発者が作成した１以上のフローデータセットとの差分から依存関係が算出されるため、開発者は他の開発者の知見を活用することができる。

１または複数のテンプレートフローデータセットは、当該１または複数のテンプレートフローデータセットが格納される第１のサーバであるテンプレート管理サーバ１００により管理される。１または複数のテンプレートフローデータセットと１または複数のフローデータセットとの関係（例えばプロジェクト管理情報Ｔ２００）が、１または複数のフローデータセットが格納される第２のサーバであるレポジトリ管理サーバに３００により管理される。このように、テンプレート管理サーバ１００やレポジトリ管理サーバ３００が有する機能を有効に利用することができる。

属性値同士の依存関係は、対象テンプレートフローデータセットの複製が示すテンプレートフローにおける１以上のノードの１以上の属性値の変更が完了したときに算出され、通知は、当該１以上の属性値の変更が完了したフローデータセットに関する情報を表示しているビジュアルプログラミングツールに発行される。これにより、開発者は、ある属性値の変更が完了したときに他の属性値の変更の必要性があるか否かを、フローの編集中に知ることができる。

属性値同士の依存関係を算出するとは、各属性値同士について、当該属性値同士における２以上の属性値のうちの或る１以上の属性値が変更された場合に当該２以上の属性値のうちの別の１以上の属性値が変更されることの確率である条件付き確率を算出することである。通知は、対象テンプレートフローデータセットの複製が示すテンプレートフローに関し変更された１以上の属性値との間での条件付確率が事前定義された一定値を越える１以上の属性値に関する情報の通知である。これにより、開発者は、変更した属性値との依存関係が強い属性値（ある属性値の変更に付随して変更することが必要と推定される属性値）を知ることができる。

対象テンプレートフローデータセットの複製の編集は、当該対象テンプレートフローデータセットが示すテンプレートフローにおける少なくとも１つのノードの属性値を変更することに代えてまたは加えて、当該少なくとも１つのノードの属性値に対応したキーと当該少なくとも１つのノードのノード実体とのうち少なくとも１つの変更を含むことがある。フローデータセット間の差分の算出では、キーおよびノードＩＤ、ノードタイプおよびノードカテゴリといった複数のノード関連要素のうちの一部のノード関連要素が異なっていても当該複数のノード関連要素のうちの残りのノード関連要素が事前定義された１以上のルールに適合していれば、１以上のフローデータセットと対象テンプレートフローデータセットとの間において、当該一部のノード関連要素が異なる属性値同士は互いに対応した属性値同士とみなされる（属性値同士が同じなら差分無しとされ属性値同士が異なっていれば差分ありとされる）。これにより、算出される差分の精度の向上が期待でき、以って、算出される依存関係の精度の向上が期待できる。

なお、少なくとも１つのキーに、１以上のタグが関連付けられていてもよい。フローデータセット間の差分の算出では、複数のノード関連要素のうちの少なくとも一部のノード関連要素が異なっていても関連付いている１以上のタグが事前定義された１以上のルールに適合していれば、１以上のフローデータセットと対象テンプレートフローデータセットとの間において、当該少なくとも一部のノード関連要素が異なる属性値同士は互いに対応した属性値同士とみなされる。これにより、算出される差分の精度の向上が期待でき、以って、算出される依存関係の精度の向上が期待できる。

算出された依存関係に従う通知を発行するとは、当該算出された依存関係に関わるノードを含んだフローに関する情報を表示しているビジュアルプログラミングツールに、当該算出された依存関係を当該ビジュアルプログラミングツールにより表示させるために、当該算出された依存関係に関する情報の通知を発行することである。結果として、当該通知の内容がビジュアルプログラミングツールの画面上に表示されるので、開発者は、ビジュアルプログラミングツール経由で、属性値同士の依存関係を知ることができる。

変更分析部は、属性値同士の依存関係を、対象テンプレートフローデータセットについて上記算出された差分の他に、対象テンプレートフローデータセットが示すテンプレートフローについて属性値の変更順序を基に、算出する。これにより、算出される依存関係の精度の向上が期待できる。

以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。例えば、本発明は、情報通信技術によるＩＴシステム、特にビジュアルプログラミングツールを用いたアプリケーション開発において少なくとも利用可能である。

２００：変更候補管理サーバ

Claims (10)

1. １または複数のビジュアルプログラミングツールで生成された１または複数のフローデータセットのうちの１以上のフローデータセットと、１または複数のテンプレートフローデータセットのうち前記１以上のフローデータセットの基とされたテンプレートフローデータセットである対象テンプレートフローデータセットとの差分を算出し、
   前記１または複数のテンプレートフローデータセットの各々は、複数のノードと当該複数のノードにおける各ノード間の結線とで表現されたテンプレートフローを示すデータセットであり、
   前記１または複数のフローデータセットの各々は、複数のノードと当該複数のノードにおける各ノード間の結線とで表現されたフローを示し、いずれかのテンプレートフローデータセットの複製の編集後のデータセットであり、
   各ノードには、当該ノードのプロパティを構成する１または複数のノード属性が関連付けられており、
   各ノード属性は、キーと属性値とで定義され、
   前記算出された差分から、前記対象テンプレートフローデータセットが示すテンプレートフローについての属性値同士の依存関係を算出し、
   前記算出された依存関係に関する情報の通知を発行する、
   を計算機に実行させるコンピュータプログラム。
2. 前記１または複数のテンプレートフローデータセットは、前記１または複数のテンプレートフローデータセットが格納される第１のサーバであるテンプレート管理サーバにより管理され、
   前記１または複数のテンプレートフローデータセットと前記１または複数のフローデータセットとの関係が、前記１または複数のフローデータセットが格納される第２のサーバであるレポジトリ管理サーバにより管理される、
   請求項１に記載のコンピュータプログラム。
3. 属性値同士の依存関係は、前記対象テンプレートフローデータセットの複製が示すテンプレートフローにおける１以上のノードの１以上の属性値の変更が完了したときに算出され、
   前記通知は、当該１以上の属性値の変更が完了したフローデータセットに関する情報を表示しているビジュアルプログラミングツールに発行される、
   請求項１に記載のコンピュータプログラム。
4. 属性値同士の依存関係を算出するとは、各属性値同士について、当該属性値同士における２以上の属性値のうちの或る１以上の属性値が変更された場合に当該２以上の属性値のうちの別の１以上の属性値が変更されることの確率である条件付き確率を算出することであり、
   前記通知は、前記対象テンプレートフローデータセットの複製が示すテンプレートフローに関し変更された１以上の属性値との間での条件付確率が事前定義された一定値を越える１以上の属性値に関する情報の通知である、
   請求項１に記載のコンピュータプログラム。
5. 前記対象テンプレートフローデータセットの複製の編集は、前記対象テンプレートフローデータセットが示すテンプレートフローにおける少なくとも１つのノードの属性値を変更することに代えてまたは加えて、当該少なくとも１つのノードの属性値に対応したキーと当該少なくとも１つのノードのノード実体とのうち少なくとも１つの変更を含むことがあり、
   前記１以上のフローデータセットと前記対象テンプレートフローデータセットとの差分の算出では、キーおよびノードＩＤ、ノードタイプおよびノードカテゴリといった複数のノード関連要素のうちの一部のノード関連要素が異なっていても当該複数のノード関連要素のうちの残りのノード関連要素が事前定義された１以上のルールに適合していれば、前記１以上のフローデータセットと前記対象テンプレートフローデータセットとの間において、当該一部のノード関連要素が異なる属性値同士は互いに対応した属性値同士とみなされる、
   請求項１に記載のコンピュータプログラム。
6. 少なくとも１つのキーに、１以上のタグが関連付けられており、
   前記１以上のフローデータセットと前記対象テンプレートフローデータセットとの差分の算出では、前記複数のノード関連要素のうちの少なくとも前記一部のノード関連要素が異なっていても関連付いている１以上のタグが事前定義された１以上のルールに適合していれば、前記１以上のフローデータセットと前記対象テンプレートフローデータセットとの間において、当該少なくとも一部のノード関連要素が異なる属性値同士は互いに対応した属性値同士とみなされる、
   請求項５に記載のコンピュータプログラム。
7. 前記算出された依存関係に従う通知を発行するとは、当該算出された依存関係に関わるノードを含んだフローに関する情報を表示しているビジュアルプログラミングツールに、当該算出された依存関係を当該ビジュアルプログラミングツールにより表示させるために、当該算出された依存関係に関する情報の通知を発行することである、
   請求項１に記載のコンピュータプログラム。
8. 属性値同士の依存関係を、前記対象テンプレートフローデータセットについて前記算出された差分の他に、前記対象テンプレートフローデータセットが示すテンプレートフローについて属性値の変更順序を基に、算出する、
   請求項１に記載のコンピュータプログラム。
9. １または複数のビジュアルプログラミングツールで生成された１または複数のフローデータセットのうちの１以上のフローデータセットと、１または複数のテンプレートフローデータセットのうち前記１以上のフローデータセットの基とされたテンプレートフローデータセットである対象テンプレートフローデータセットとの差分を算出し、当該算出された差分から、前記対象テンプレートフローデータセットが示すテンプレートフローについての属性値同士の依存関係を算出する依存関係算出部と、
   前記算出された依存関係に関する情報の通知を発行する依存関係通知部と
   を有し、
   前記１または複数のテンプレートフローデータセットの各々は、複数のノードと当該複数のノードにおける各ノード間の結線とで表現されたテンプレートフローを示すデータセットであり、
   前記１または複数のフローデータセットの各々は、複数のノードと当該複数のノードにおける各ノード間の結線とで表現されたフローを示し、いずれかのテンプレートフローデータセットの複製の編集後のデータセットであり、
   各ノードには、当該ノードのプロパティを構成する１または複数のノード属性が関連付けられており、
   各ノード属性は、キーと属性値とで定義される、
   フロー作成支援装置。
10. １または複数のビジュアルプログラミングツールで生成された１または複数のフローデータセットのうちの１以上のフローデータセットと、１または複数のテンプレートフローデータセットのうち前記１以上のフローデータセットの基とされたテンプレートフローデータセットである対象テンプレートフローデータセットとの差分を算出し、
    前記１または複数のテンプレートフローデータセットの各々は、複数のノードと当該複数のノードにおける各ノード間の結線とで表現されたテンプレートフローを示すデータセットであり、
    前記１または複数のフローデータセットの各々は、複数のノードと当該複数のノードにおける各ノード間の結線とで表現されたフローを示し、いずれかのテンプレートフローデータセットの複製の編集後のデータセットであり、
    各ノードには、当該ノードのプロパティを構成する１または複数のノード属性が関連付けられており、
    各ノード属性は、キーと属性値とで定義され、
    前記算出された差分から、前記対象テンプレートフローデータセットが示すテンプレートフローについての属性値同士の依存関係を算出し、
    前記算出された依存関係に関する情報の通知を発行する、
    フロー作成支援方法。

Images