JP2007226685A - アプリケーションメンテナンス支援装置、アプリケーション生成装置、アプリケーションメンテナンス支援方法、およびコンピュータプログラム - Google Patents

Abstract

【課題】カスタムメードのアプリケーションのメンテナンスの手間を軽減する。
【解決手段】アプリケーション生成装置１に、アプリケーションのプロジェクトファイルＰＦＬごとにそのアプリケーションによって実現される機能を示す定義情報７３を記憶する定義情報格納部ＤＢ３と、いずれかの機能に係るプログラムが更新された場合に、各アプリケーションのプロジェクトファイルＰＦＬの中から生成し直すべきプロジェクトファイルＰＦＬを、各定義情報７３に基づいて判別する、類似ファイル判別部１２３と、を設ける。
【選択図】図２

Description

本発明は、カスタムメードのアプリケーションを取り扱う装置および方法などに関する。

特定の業務のために使用するアプリケーションの従来の製品形態として、量販店などで販売される既製品（いわゆる「パッケージソフト」）および顧客ごとにカスタマイズした特注品（カスタムメードのアプリケーション）が挙げられる。

パッケージソフトは、同一品を多数の顧客に販売することができるので、販売価格を低く抑えることができる。しかし、その反面、様々な顧客に使用されることを想定して作成されているので、顧客にとって不要な機能が含まれており、使い勝手がよくない。特に、コンピュータまたは業務に不慣れな操作者は、必要な機能と不要な機能とが混在していると、操作方法がなかなか覚えられず、精神的および肉体的に負担が強いられる。

これに対し、カスタムメードのアプリケーションは、顧客の要望に応じて必要な機能が選定されるので、操作者にとって使い勝手がよい。

ところで、アプリケーションを開発する開発者を支援するための方法として、特許文献１−３に記載されるような方法が提案されている。

特許文献１に記載される方法によると、コンパイルシステムにおいて、プリプロセッサはソースプログラム１−１を入力としてマクロを展開し、ソースプログラム１−２を出力する。コンパイラはテスト命令を含むソースプログラム１−２を入力とし、共通オブジェクトファイル１−３を生成する。この共通オブジェクトファイル１−３はテスト命令で境界された再配置可能なオブジェクトの集合である。リンクエディタは共通オブジェクトファイル１−３を入力としテスト命令の実行結果にしたがって再配置するオブジェクトを選択し、統合した結果のオブジェクトモジュールを出力する。このような構成により、同一のソースプログラムから用途の異なる複数のオブジェクトモジュールを生成する際の、所要時間を短縮し、統合ミスを低減し、かつ必要とする記憶容量を小さくすることができる。

特許文献２に記載される方法によると、第１のシステムで作成されるプログラム中に、第１のシステム固有のロジック部分とこの第１のシステムとは異なる第２のシステム固有のロジック部分とを示す所定のコンパイル記述子を記述してプログラムを作成する工程と、前記第１のシステムで作成されたプログラムを前記第２のシステム用に変換する場合、前記第１のシステムと前記第２のシステムとの共通ロジック部分は飛び越し前記コンパイル記述子によって指示された前記第２のシステム固有のロジック部分を抽出する工程と、抽出された前記第２のシステム固有のロジック部分を前記第２のシステム用に変換する工程とを有する。このような構成により、異なるシステムで開発された同じ言語のプログラムを利用することができる。

特許文献３に記載される発明によると、ＯＳ上から不要になったソフトウェアをインストール順序に依存することなく適宜取り除くことができる。
特開平５−６１６５３号公報 特開平９−１９０３５５号公報 特開平９−１４６７６４号公報

前述の通り、カスタムメードのアプリケーションのほうがパッケージソフトよりも使い勝手がよい。

ところが、カスタムメードのアプリケーションは、メンテナンスの作業によって開発者に対して掛かる手間がパッケージソフトの場合よりも大きい。なぜなら、例えば導入後に製品に障害が見つかった場合において、パッケージソフトであれば修正版を１つまたは幾つか作成しそれをユーザに配布するだけで対応することができるが、カスタムメードのアプリケーションについては、個別に障害が発生するか否かの検証を行い、障害が発生するのであればさらに個別にその原因を調査し修正版を作成しなければならないからである。しかし、特許文献１〜３に記載されるような従来の方法では、開発者の手間を省くことはできない。

本発明は、このような問題点に鑑み、カスタムメードのアプリケーションのメンテナンスの手間を従来よりも軽減することを目的とする。

本発明に係るアプリケーションメンテナンス支援装置は、要求者からの要求に応じて生成されたカスタムメードのアプリケーションのメンテナンスを支援するアプリケーションメンテナンス支援装置であって、前記アプリケーションごとに、当該アプリケーションによって実現される機能を示す機能構成情報を記憶する、機能構成情報記憶手段と、いずれかの機能に係るプログラムが更新された場合に、前記各アプリケーションの中から生成し直すべきものを前記各機能構成情報に基づいて判別する、要再生成アプリケーション判別手段と、を有することを特徴とする。

本発明に係るアプリケーション生成装置は、要求者からの要求に応じてカスタムメードのアプリケーションを生成するアプリケーション生成装置であって、所定の機能ごとに、当該所定の機能を実現するためのプログラムを記憶するプログラム記憶手段と、前記アプリケーションを、当該アプリケーションを要求した要求者にとって必要な前記所定の機能の前記プログラムを使用して生成する、アプリケーション生成手段と、前記所定の機能の前記プログラムが更新された場合に、当該所定の機能を有する前記アプリケーションを生成し直すべきであると判別する、要再生成アプリケーション判別手段と、を有することを特徴とする。

本発明によると、カスタムメードのアプリケーションのメンテナンスの手間を従来よりも軽減することができる。

図１はアプリケーション生成装置１の外観の例およびハードウェア構成の例を示す図、図２はアプリケーション生成装置１の機能的構成の例を示す図である。

本発明に係るアプリケーション生成装置１は、図１（ａ）に示すようなパーソナルコンピュータまたはワークステーションであって、図１（ｂ）に示すようにＣＰＵ１０ａ、ＲＡＭ１０ｂ、ＲＯＭ１０ｃ、ハードディスク１０ｄ、ディスプレイ１０ｅ、入力装置１０ｆ、入出力インタフェース１０ｇ、およびネットワークカード１０ｈなどによって構成される。

このアプリケーション生成装置１は、量販店などで一般のユーザ向けに販売されるようなアプリケーション（いわゆるパッケージソフト）のほか、顧客から個々に注文を受けて顧客の要望に応じたカスタムメードのアプリケーション（つまり、特注品）を、生成するための処理を行う。以下、ある特定の業務（例えば、製薬業または医療業など）を行う会社を顧客とするソフトウェア開発会社において各顧客の業務用のアプリケーションを生成するためにアプリケーション生成装置１が使用される場合を例に、説明する。なお、これらのアプリケーションを作成するためのプログラム言語として、例えばマイクロソフト社のＶｉｓｕａｌ Ｂａｓｉｃなどが用いられる。

アプリケーション生成装置１のハードディスク１０ｄには、図２に示すような新規提供先選択部１０１、提供機能特定部１０２、特定機能コード抽出部１０３、ソース編集処理部１０４、コンパイル処理部１０５、実行ファイル登録部１０６、定義情報等編集部１２１、アプリ再生成指令部１２２、類似ファイル判別部１２３、定義情報更新部１２４、類似ファイル再生成指令部１２５、提供状況閲覧処理部１２６、プロジェクトファイル格納部ＤＢ０、モジュールファイル等格納部ＤＢ１、対応情報格納部ＤＢ２、定義情報格納部ＤＢ３、およびアプリケーション格納部ＤＢ４などを実現するためのコンピュータプログラムおよびデータが格納されている。これらのコンピュータプログラムおよびデータは必要に応じてＲＡＭ１０ｂにロードされ、ＣＰＵ１０ａによってコンピュータプログラムが実行される。

アプリケーション生成装置１によって生成されるカスタムメードのアプリケーションには、１つまたは複数の機能を顧客の要求に応じて選択的に搭載することができる。例えば、ディスプレイに表示した画面を印刷する機能、操作方法の解説文を表示しユーザに参照させる機能、またはデータベースを外部から得られた最新情報に基づいて更新する機能などの種々の機能の中から顧客の要求に応じて搭載することができる。以下、前記の特定の業務のために使用され得る機能として、機能Ｆａ、Ｆｂ、Ｆｃ、…が用意されているものとして説明する。

機能Ｆａ、Ｆｂ、Ｆｃ、…は、後に説明する構成用ファイルＫＦＬによって実現される。また、構成用ファイルＫＦＬが障害の除去または性能の向上のためにバージョンアップ（更新）されるごとに、その構成用ファイルＫＦＬを必要とする機能の版（バージョン）も「版１」から「版２」、「版３」、「版４」、…も上がっていく。

次に、図２に示すアプリケーション生成装置１の各部の処理内容などについて詳細に説明する。

〔情報等の管理〕
図３は対応情報格納部ＤＢ２の例を示す図、図４は定義情報格納部ＤＢ３の例を示す図である。

プロジェクトファイル格納部ＤＢ０には、前記の特定の業務を行う複数の顧客が使用することができる汎用的なアプリケーションのプロジェクトファイルＰＦＬが格納されている。本実施形態では、このプロジェクトファイルＰＦＬを顧客に応じてカスタマイズすることによってカスタムメードのアプリケーションを生成する。

モジュールファイル等格納部ＤＢ１には、そのプロジェクトファイルＰＦＬ（アプリケーション）を構成するオブジェクトのデータがファイル単位で格納されている。例えば、標準モジュール、フォームモジュール、またはＡｃｔｉｖｅＸコントロールなどのファイルが格納されている。以下、これらのファイルを「構成用ファイルＫＦＬ」と記載する。プロジェクトファイルＰＦＬおよび構成用ファイルＫＦＬは、従来通り、ソフトウェア開発会社の担当者によって作成される。

対応情報格納部ＤＢ２には、図３に示すように、機能Ｆａ、Ｆｂ、Ｆｃ、…ごとの機能対応情報７２（７２ａ、７２ｂ、７２ｃ…）が格納されている。機能対応情報７２には、それに対応する機能の機能名およびその機能を識別するための識別コードなどの情報が示されている。さらに、その機能の版（バージョン）ごとに、版名、その機能に必要な構成用ファイルＫＦＬのファイル名（対象ファイル名）、および版２以降の場合はバージョンアップした理由（更新理由）が示されている。

定義情報格納部ＤＢ３には、図４に示すように、顧客ごとの定義情報７３（７３ａ、７３ｂ、…）が格納されている。定義情報７３は、それに係る顧客が前記の特定の業務の際に各機能Ｆａ、Ｆｂ、Ｆｃ、…を必要とするか否かを定義している。具体的には、必要な機能には「○」が付され、不要な機能には「×」が付されている。ただし、その必要な機能の版が複数ある場合は、現在その顧客の最新版のアプリケーションに適用されている版の版名に「○」が付され、残りの版の版名には「−」が付される。

ソフトウェア開発会社の担当者は、顧客から要望を聞いてその顧客にとって必要な機能および不要な機能を決定する。そして、決定した内容をアプリケーション生成装置１の入力装置１０ｆを操作するなどして入力し、その顧客の定義情報７３を定義情報格納部ＤＢ３に登録させる。ただし、必要な機能の版が複数ある場合は、特別な事情がない限り、最新の版を採用するのが望ましい。なお、担当者が機能の要不要を選択しやすくするために、アプリケーション生成装置１のディスプレイ１０ｅに機能の一覧表が表示されるように構成してもよい。

なお、本実施形態では、１つの顧客に対して１つのアプリケーション（実行ファイルＪＦＬ）を提供する。よって、定義情報７３は、アプリケーションごとに定義されているとも言える。

アプリケーション格納部ＤＢ４には、後に説明するコンパイル処理部１０５によって生成された実行ファイルＪＦＬが格納される。そのほか、アプリケーション格納部ＤＢ４には、実行ファイルＪＦＬごとにファイル属性情報７４（７４ａ、７４ｂ、…）が格納される。

〔顧客向けのアプリケーションの生成の処理〕
図５はソース編集処理の流れの例を説明するフローチャート、図６は編集前後のソースの例を示す図、図７はアプリケーション格納部ＤＢ４の例を示す図である。

新規提供先選択部１０１は、どの顧客に提供するアプリケーションを生成するのかを選
択する。すなわち、これから生成するアプリケーションに係る顧客を担当者が指定すると、新規提供先選択部１０１は、その顧客を提供先として選択する。

提供機能特定部１０２は、選択された提供先の顧客にとって必要な機能およびその版を特定する。すなわち、まず、その顧客の定義情報７３を定義情報格納部ＤＢ３から呼び出す。そして、その定義情報７３において「○」が付されている機能および版を必要なものであると特定する。

特定機能コード抽出部１０３は、提供機能特定部１０２によって特定された版の機能を実現するための構成用ファイルＫＦＬをモジュールファイル等格納部ＤＢ１から抽出する。すなわち、まず、特定された機能の機能対応情報７２を対応情報格納部ＤＢ２から呼び出す。そして、その機能対応情報７２に示される対象ファイル名のうちの特定された版に対応する対象ファイル名を有する構成用ファイルＫＦＬを、モジュールファイル等格納部ＤＢ１から抽出する。

ソース編集処理部１０４は、選択された顧客に提供するためのアプリケーションのソースを生成する処理を、プロジェクトファイルＰＦＬのソースを編集することによって行う。係る処理は、例えば図５のフローチャートのような手順で行われる。

プロジェクトファイルＰＦＬをプロジェクトファイル格納部ＤＢ０から抽出する（図５の＃２０１）。そのプロジェクトファイルＰＦＬに示されるソースの中から、機能の識別コードを検索する（＃２０２）。識別コードが見つかったら（＃２０３でＹｅｓ）、その識別コードを残しておくか削除するかのどちらかを選択することによってそのソースを編集する（＃２０５または＃２０６）。

すなわち、その識別コードに係る構成用ファイルＫＦＬが特定機能コード抽出部１０３によって抽出された場合は、その機能は顧客にとって必要なので（＃２０４でＹｅｓ）、その識別コードを残しておく（＃２０５）。一方、その識別コードに係る構成用ファイルＫＦＬが抽出されなかった場合は、その機能は顧客にとって不要なので（＃２０４でＮｏ）、その識別コードおよびその引数をソースから削除する（＃２０６）。その識別コードが式に含まれている場合は、その式ごと削除する。

ソースに複数の識別コードが含まれている場合は、各識別コードに対してステップ＃２０５または＃２０６のうちのいずれか一方の処理を行う。このような編集処理によって、不要な機能に係るコードを除去したソースが得られる。

例えば、実行ファイルＪＦＬに記載される元のソースが図６（ａ）に示すような内容であって、提供機能特定部１０２が図４に示す定義情報７３ａに基づいて必要な機能を特定した場合は、そのソースは図６（ｂ）に示すように編集される。

図２に戻って、コンパイル処理部１０５は、ソース編集処理部１０４によって得られたソースを、特定機能コード抽出部１０３によって抽出された構成用ファイルＫＦＬに記載されるコードを用いて従来通りにコンパイルし、実行ファイルＪＦＬ（いわゆる「ＥＸＥファイル」）を生成する。この実行ファイルＪＦＬが目的のカスタムメードのアプリケーションである。

生成された実行ファイルＪＦＬは、実行ファイル登録部１０６によって所定の規則に基づいてファイル名が付されてアプリケーション格納部ＤＢ４に格納される。さらに、図７に示すように、その実行ファイルＪＦＬのファイル属性情報７４が生成され格納される。なお、図７では、紙面の都合上、ファイル属性情報７４を２段に分割して記載している。

そのファイル属性情報７４には、その実行ファイルＪＦＬの識別子、作成日（生成日）、提供先である顧客の顧客名、ファイル名、顧客の業務用システムに適用する予定の日（適用予定日）、適用する作業を担当する担当者、どれくらい緊急に適用すべきかの度合い（緊急度）、および各機能Ｆａ、Ｆｂ、Ｆｃ…の各版ごとの適用の有無およびその機能に関連する他の実行ファイルＪＦＬの識別子（関連識別子）などが示される。

なお、「作成日」は、その実行ファイルＪＦＬの版（バージョン）を表わすためにも用いられる。また、「識別子」は、ファイルの種類またはフォーマットを意味するものではなく、他の実行ファイルＪＦＬと区別するための情報であって、所定の規則に基づいて付される。ファイル名のみで実行ファイルＪＦＬを識別できるのであれば、ファイル名を識別子として用いてもよい。

さらに、ファイル属性情報７４には、その実行ファイルＪＦＬに搭載される機能のうち前版よりも新しくなった機能（つまり、更新された機能）の機能名（更新機能名）が示される。ただし、その実行ファイルＪＦＬが初版である場合は、空欄にしておく。

これらのうち、識別子、作成日、顧客名、ファイル名、各機能Ｆａ、Ｆｂ、Ｆｃ…の各版ごとの適用の有無、および更新機能名は、上述の処理の過程で決定する。他の情報は、ファイル属性情報７４が生成された時点では決定しておらず、後に示す処理の過程で順次決定する。

そして、その後、アプリケーション格納部ＤＢ４に格納された実行ファイルＪＦＬは、担当者などの作業によって顧客の業務用システムに導入され使用される。

〔顧客向けのアプリケーションの再生成の処理〕
顧客の業務用システムにカスタムメードのアプリケーションつまり実行ファイルＪＦＬを導入した後、実行ファイルＪＦＬから障害が発見されることがある。また、顧客からの要望に応じるために機能を向上させる必要が生じることがある。これらの場合は、担当者は、障害または要望に係る機能をバージョンアップさせた実行ファイルＪＦＬを生成するための作業を、例えば次のように行う。

各機能の構成用ファイルＫＦＬのソースを参照しながら、どの機能の構成用ファイルＫＦＬに障害の原因があるのかを調査する。または、どのように構成用ファイルＫＦＬのソースを修正すべきかを検討する。そして、これらの調査結果または検討結果などに基づいて新たな構成用ファイルＫＦＬを作成し、モジュールファイル等格納部ＤＢ１に格納させる。

さらに、担当者は、その機能の機能名、その新たな構成用ファイルＫＦＬのファイル名（対象ファイル名）、バージョンアップの理由（更新理由）、およびその実行ファイルＪＦＬの導入先である顧客の顧客名を、入力装置１０ｆを操作するなどしてアプリケーション生成装置１に対して指定する。

すると、図２の定義情報等編集部１２１は、定義情報格納部ＤＢ３の中からその顧客の定義情報７３を検索し、その定義情報７３を次のように更新する。その定義情報７３の中の、今回バージョンアップの対象となった機能のフィールドに新たな版名の欄を追加する。そして、「○」の印を、従来の版名の欄からその新たな版名の欄に移動させる。例えば、従来、その機能の最新版が「版２」であったならば、「版３」の欄を追加し、「○」の印を版２の欄から版３の欄に移動させる。

さらに、定義情報等編集部１２１は、その機能の機能対応情報７２を対応情報格納部ＤＢ２の中から検索し、その機能対応情報７２を、新たな版の版名、今回新たに生成された構成用ファイルＫＦＬのファイル名（対象ファイル名）、および更新理由の情報を書き加えることによって、編集（更新）する。

アプリ再生成指令部１２２は、提供機能特定部１０２などに対して、目的の実行ファイルＪＦＬを生成し直すように指令を与える。すると、提供機能特定部１０２ないしコンパイル処理部１０５は、定義情報等編集部１２１によって更新された機能対応情報７２および定義情報７３に基づいて、目的の実行ファイルＪＦＬを上述の方法によって再生成する。実行ファイル登録部１０６は、再生成された実行ファイルＪＦＬにファイル名を付け、その実行ファイルＪＦＬおよびファイル属性情報７４をアプリケーション格納部ＤＢ４に格納させる。

ところで、ある顧客の実行ファイルＪＦＬで発見された障害は、他の顧客の実行ファイルＪＦＬでも同様に発生するおそれがある。また、ある顧客の要望に応じてバージョンアップさせた機能は他の顧客のアプリケーションにも適用されるのが望ましい。そこで、類似ファイル判別部１２３ないし類似ファイル再生成指令部１２５などは、今回生成し直した実行ファイルＪＦＬに類似する他の実行ファイルＪＦＬ（以下、「類似ファイル」と記載することがある。）を見つけ出し、それらを生成し直すための処理を、例えば次のように実行する。

類似ファイル判別部１２３は、アプリケーション格納部ＤＢ４に格納されている実行ファイルＪＦＬの中から類似ファイルを次のように判別する。

今回バージョンアップされた機能を搭載している実行ファイルＪＦＬを使用する顧客を、定義情報７３（図４参照）に基づいて検索する。すなわち、顧客の定義情報７３の中のその機能のいずれかの版名の欄に「○」が付されていれば、その顧客がそのような実行ファイルＪＦＬを使用していることが分かる。そして、その検索された顧客の実行ファイルＪＦＬを類似ファイルであると判別する。

定義情報更新部１２４は、類似ファイル判別部１２３によって類似ファイルであると判別された実行ファイルＪＦＬに係る顧客の定義情報７３を次のように更新する。その定義情報７３の中の、今回バージョンアップされた機能のフィールドに注目する。そして、「○」の印を、従来「○」が付されていた欄から新たな版の版名の欄に移動させる。

類似ファイル再生成指令部１２５は、提供機能特定部１０２などに対して、類似ファイルを生成し直すように指令を与える。すると、提供機能特定部１０２ないしコンパイル処理部１０５は、定義情報更新部１２４によって更新された定義情報７３に基づいて、それらを上述の方法で再生成する。

そして、実行ファイル登録部１０６は、再生成された実行ファイルＪＦＬ（類似ファイル）にファイル名を付け、その実行ファイルＪＦＬおよびファイル属性情報７４をアプリケーション格納部ＤＢ４に格納させる。

上述の２つの方法のうちのいずれかの方法によって再生成された実行ファイルＪＦＬは、担当者などの作業によって、既に導入されている古い実行ファイルＪＦＬと置き換えられて使用される。

さらに、実行ファイル登録部１０６は、上述の２つの方法のうちのいずれかの方法によって今回再生成された各実行ファイルＪＦＬのファイル属性情報７４を、次のように更新する。ファイル属性情報７４の中の今回バージョンアップされた機能の関連識別子の欄に、その機能に関して同様にバージョンアップされた他の実行ファイルＪＦＬの識別子を書き込む。

〔アプリケーションの提供状況を確認させるための処理〕
図８はアプリケーション提供状況画面ＨＧ１の例を示す図、図９は機能更新履歴一覧画面ＨＧ２の例を示す図である。

図２の提供状況閲覧処理部１２６は、担当者などがアプリケーションの保守のための情報を閲覧することができるように、図８のようなアプリケーション提供状況画面ＨＧ１および図９のような機能更新履歴一覧画面ＨＧ２をディスプレイ１０ｅに表示させる処理を行う。

提供状況閲覧処理部１２６は、アプリケーション提供状況画面ＨＧ１を次のように生成しディスプレイ１０ｅに表示させる。

担当者が入力装置１０ｆを操作して所定のコマンドを入力すると、提供状況閲覧処理部１２６は、次のような情報を取得する。アプリケーション格納部ＤＢ４の中から顧客ごとの最新版の実行ファイルＪＦＬのファイル属性情報７４を検索し、これらのファイル属性情報７４の中から各顧客の実行ファイルＪＦＬの版名つまり最新バージョン名、緊急度、適用予定日、および担当者に関する情報を取得する。各顧客の業務用システムに通信回線を介してアクセスし、現在使用されている実行ファイルＪＦＬのバージョンつまり現行バージョン名の情報を取得する。各顧客の最新バージョンと現行バージョンとのバージョンの差（以下、「蓄積数」と記載する。）の情報を取得する。蓄積数は、現行バージョンと最新バージョンとの間にその顧客の実行ファイルＪＦＬのバージョンアップが何回行われたかをチェックすることによって求められる。例えば、両者の間に１回もバージョンアップが行われていない場合は「１」である。２回行われている場合は「３」である。または、両者が同一のバージョンである場合は「０」である。

そして、取得したこれらの情報を顧客ごとに纏めることによってアプリケーション提供状況画面ＨＧ１を生成し、ディスプレイ１０ｅに表示させる。

緊急度、適用予定日、および担当者は、空欄の場合がある。担当者は、アプリケーション提供状況画面ＨＧ１が表示されている状態で、入力装置１０ｆを操作することによってこれらの情報を入力することができる。入力された情報は、その顧客の最新版の実行ファイルＪＦＬのファイル属性情報７４に書き込まれる。例えば、会社甲に対応する行に入力された場合は、その情報が会社甲の最新版の実行ファイルＪＦＬのファイル属性情報７４に書き込まれる。なお、既に入力されている情報を修正することもできる。

また、提供状況閲覧処理部１２６は、機能更新履歴一覧画面ＨＧ２を次のように生成しディスプレイ１０ｅに表示させる。担当者は、アプリケーション提供状況画面ＨＧ１に示される顧客の中から詳細を知りたい顧客を、その顧客名の上をダブルクリックするなどして選択する。

すると、提供状況閲覧処理部１２６は、その顧客のすべての版の実行ファイルＪＦＬのファイル属性情報７４をアプリケーション格納部ＤＢ４から呼び出し、これらのファイル属性情報７４から、各版の実行ファイルＪＦＬの識別子、版名（バージョン名）、関連識別子、更新機能名、および緊急度の情報を取得する。さらに、その更新機能名に係る機能がどのような理由でバージョンアップされたのか、すなわち、更新理由を、その機能の機能対応情報７２を対応情報格納部ＤＢ２（図３参照）より検索して取得する。

そして、これらの取得した情報を版ごとに纏めることによって機能更新履歴一覧画面ＨＧ２を生成し、ディスプレイ１０ｅに表示させる。

そのほか、提供状況閲覧処理部１２６は、機能更新履歴一覧画面ＨＧ２の中からいずれかの識別子または関連識別子がダブルクリックされるなどして選択されると、それを「識別子」フィールドに示すファイル属性情報７４をアプリケーション格納部ＤＢ４（図７参照）の中から呼び出し、そのファイル属性情報７４の内容を示すファイル属性画面を生成し、ディスプレイ１０ｅに表示させる。

図１０はカスタムメードのアプリケーションを生成する際のアプリケーション生成装置１の処理の流れの例を説明するフローチャート、図１１は生成済のアプリケーションをバージョンアップする際の処理の流れの例を説明するフローチャートである。

次に、アプリケーション生成装置１の全体的な処理の流れを、フローチャートを参照して説明する。

新規の顧客のためのアプリケーションを生成する場合は、担当者は、その顧客にとって必要な機能をその顧客の定義情報７３（図４参照）に予め設定しておく。複数の版を有する機能については、適用する版も設定しておく。

図１０のフローチャートにおいて、アプリケーション生成装置１は、目的の顧客を選択し（＃１１）、その顧客にとって必要な機能およびその版をその顧客の定義情報７３に基づいて特定する（＃１２）。

特定した版の機能のために必要な構成用ファイルＫＦＬを、その機能の機能対応情報７２（図３参照）に基づいてモジュールファイル等格納部ＤＢ１から抽出する（＃１３）。プロジェクトファイルＰＦＬをプロジェクトファイル格納部ＤＢ０から抽出し、そのソースの編集を行う（＃１４）。ソースを編集する処理の内容は、前に図５で説明した通りである。

編集したソースを、抽出した構成用ファイルＫＦＬなどを用いてコンパイルすることによって、目的の顧客のアプリケーションである実行ファイルＪＦＬを生成する（＃１５）。そして、生成した実行ファイルＪＦＬとそのファイル属性情報７４とをアプリケーション格納部ＤＢ４に格納する（＃１６）。

顧客の業務用システムに導入済のアプリケーション（実行ファイルＪＦＬ）から障害が発見された場合または顧客から性能の向上の要望があった場合は、アプリケーション生成装置１は、図１１のフローチャートのような手順で、その実行ファイルＪＦＬを生成し直す。さらに、その実行ファイルＪＦＬの類似ファイルも生成し直す。

担当者は、障害または要望に関係する機能を見つけ、その機能の構成用ファイルＫＦＬを作成し直すなどの作業を行う。

すると、アプリケーション生成装置１は、その構成用ファイルＫＦＬをモジュールファイル等格納部ＤＢ１に格納させるとともに（図１１の＃２１）、その機能の版が最新版になるようにその顧客の定義情報７３（図４参照）を編集し（＃２２）、その機能およびその構成用ファイルＫＦＬに関する情報が反映されるようにその機能の機能対応情報７２を編集する（＃２３）。

編集された機能対応情報７２および定義情報７３などに基づいて、図１０のステップ＃１２〜＃１５と同様の方法で、実行ファイルＪＦＬを生成し直す（＃２４〜＃２７）。すなわち、編集された定義情報７３に基づいてその顧客にとって必要な機能およびその版を特定し（＃２４）、その版の機能のために必要な構成用ファイルＫＦＬを、各機能の機能対応情報７２に基づいてモジュールファイル等格納部ＤＢ１から抽出する（＃２５）。プロジェクトファイルＰＦＬをプロジェクトファイル格納部ＤＢ０から抽出し、そのソースの編集を行う（＃２６）。編集したソースをコンパイルすることによって実行ファイルＪＦＬを再生成する（＃２７）。

そして、再生成した実行ファイルＪＦＬとそのファイル属性情報７４とをアプリケーション格納部ＤＢ４に格納する（＃２８）。

さらに、再生成した実行ファイルＪＦＬの類似ファイルを判別する（＃２９）。類似ファイルが存在していれば（＃３０でＹｅｓ）、類似ファイルに係る顧客の定義情報７３を、今回ステップ＃２１でバージョンアップされた機能の版が適用されるように更新（編集）する（＃３１）。

そして、その類似ファイル（実行ファイルＪＦＬ）を、ステップ＃２４〜＃２７と同様の方法で再生成し（＃３２〜＃３５）、ファイル属性情報７４とともにアプリケーション格納部ＤＢ４に格納する（＃３６）。

また、本フローチャートの処理によって再生成した実行ファイルＪＦＬ同士を互いに関連付けるために、これらの実行ファイルＪＦＬのファイル属性情報７４の関連識別子の欄に互いの識別子を書き込んでおく（＃３７）。

図７の例では、ファイル属性情報７４ｂ、７４ｄは、「会社甲」向けの「２００５年１０月１８日」版の新たなアプリケーションが作成され「機能Ｆａ」が「版２」へ変更されたことに伴って「会社乙」向けの新たなアプリケーションとして「２００５年１０月１８日」版が作成されたことを示している。より具体的には、ファイル属性情報７４ｂの関連識別子の欄には、識別子「１０１８００２」が書き込まれているが、これは、ファイル属性情報７４ｂに係るアプリケーション（つまり「会社甲」向けの新たなアプリケーション）が識別子「１０１８００２」のアプリケーション（つまり「会社乙」向けの新たなアプリケーション）に関連している、ということを意味する。同様に、ファイル属性情報７４ｄの関連識別子の欄には、識別子「１０１８００１」が書き込まれているが、これは、ファイル属性情報７４ｄに係るアプリケーション（つまり「会社乙」向けの新たなアプリケーション）が識別子「１０１８００１」のアプリケーション（つまり、「会社甲」向けの新たなアプリケーション）に関連している、ということを意味する。なお、上述の例ではファイル属性情報７４ｂ、７４ｄの双方の関連識別子の欄に互いの識別子を関連付けたが、一方の属性情報の関連識別子の欄にのみ関連する識別子を格納し、もう一方の属性情報の関連識別子の欄には何も記録しないようにしてもよい。

本実施形態によると、構成用ファイルＫＦＬが更新されることによって機能がバージョンアップされると、その機能を有する実行ファイルＪＦＬを容易に見つけ出すことができる。よって、カスタムメードのアプリケーションのメンテナンスの手間を従来よりも軽減することができる。

本実施形態では、ある機能がバージョンアップされたら、その機能を有する実行ファイルＪＦＬを再生成する処理を自動的に開始したが、それらの実行ファイルＪＦＬの一覧を担当者に対して提示し、担当者が選択した実行ファイルＪＦＬのみを再生成するようにしてもよい。

図１２ないし図１４は条件文を含むソースの編集前後の例を示す図である。本実施形態では、図６で説明したように、不要な機能のための構成用ファイルＫＦＬの識別コードおよびその引数などをプロジェクトファイルＰＦＬのソースから削除しただけであったが、その識別コードに関連付けられている他のコードも一緒に削除したほうがよい場合がある。

例えば、図１２〜図１４において、不要な機能のための構成用ファイルＫＦＬの識別コードが「ＣＣＣＣ（引数）」であったとする。このような場合において、図１２（ａ）のように「＃Ｉｆ Ｙ＝０ Ｔｈｅｎ〜Ｅｎｄｉｆ」のような条件文に関連付けられている場合は、図１２（ｂ）のように、この条件文ごと削除する。図１３（ａ）のように入れ子になっている条件文に関連付けられている場合も同様に、その識別コードをその条件文とともに削除する。その結果残った条件文に意味がなくなった場合（つまり、図１３（ａ）において「Ｘ＝０」であるか否かの判断の必要がなくなった場合は、図１３（ｂ）のように、その条件文をも削除する。

Ｓｅｌｅｃｔ文およびＦｏｒ−Ｎｅｘｔ文などの他の条件文の場合も同様である。ただし、図１４（ａ）のように、その条件文が必要な機能のための構成用ファイルＫＦＬにも関連する場合は、図１４（ｂ）のように、その条件文は残しておく。

本実施形態では、１つの実行ファイルＪＦＬを生成することによって目的のアプリケーションを生成したが、複数のファイルを生成することによって目的のアプリケーションを生成する場合もある。

本発明は、Ｖｉｓｕａｌ Ｂａｓｉｃのほか、Ｃ＋＋言語およびサンマイクロシステムズ社のＪａｖａなどの言語にも適用可能である。

その他、アプリケーション生成装置１の全体または各部の構成、処理内容、処理順序、テーブルの内容などは、本発明の趣旨に沿って適宜変更することができる。

上に述べた実施例には、以下に述べるような付記も開示されている。
（付記１）
要求者からの要求に応じて生成されたカスタムメードのアプリケーションのメンテナンスを支援するアプリケーションメンテナンス支援装置であって、
前記アプリケーションごとに、当該アプリケーションによって実現される機能を示す機能構成情報を記憶する、機能構成情報記憶手段と、
いずれかの機能に係るプログラムが更新された場合に、前記各アプリケーションの中から生成し直すべきものを前記各機能構成情報に基づいて判別する、要再生成アプリケーション判別手段と、
を有することを特徴とするアプリケーションメンテナンス支援装置。
（付記２）
要求者からの要求に応じてカスタムメードのアプリケーションを生成するアプリケーション生成装置であって、
所定の機能ごとに、当該所定の機能を実現するためのプログラムを記憶するプログラム記憶手段と、
前記アプリケーションを、当該アプリケーションを要求した要求者にとって必要な前記所定の機能の前記プログラムを使用して生成する、アプリケーション生成手段と、
前記所定の機能の前記プログラムが更新された場合に、当該所定の機能を有する前記アプリケーションを生成し直すべきであると判別する、要再生成アプリケーション判別手段と、
を有することを特徴とするアプリケーション生成装置。
（付記３）
前記アプリケーション生成手段は、生成し直すべきであると判別された前記アプリケーションを、更新された前記プログラムを使用して再生成する、
付記２記載のアプリケーション生成装置。
（付記４）
前記所定の機能がすべて実現可能となるように前記プログラムが実行されるようにコーディングされた、汎用的なアプリケーションである汎用アプリケーションのソースを記憶する、ソース記憶手段、を有し、
前記アプリケーション生成手段は、前記汎用アプリケーションのソースを、前記所定の機能のうちの要求者にとって不要な機能に係る前記プログラムを実行させるためのコードを削除することによって編集し、当該編集したソースをコンパイルすることによって、前記アプリケーションを生成する、
付記２または付記３記載のアプリケーション生成装置。
（付記５）
前記アプリケーション生成手段によって生成された前記アプリケーションを識別する識別子と当該アプリケーションを要求した要求者とを示すアプリケーション属性情報を記憶するアプリケーション属性情報記憶手段と、
要求者のシステムにおいて現在適用されている前記アプリケーションの前記識別子を示す現行アプリケーション情報を取得する現行アプリケーション情報取得手段と、
前記アプリケーション属性情報および前記現行アプリケーション情報に基づいて、特定の要求者のために生成された最新の前記アプリケーションの前記識別子および当該要求者のシステムにおいて現在適用されている前記アプリケーションの前記識別子を知らせるためのアプリケーション状況画面をディスプレイに表示させる処理を行う、アプリケーション状況画面表示処理手段と、を有する、
付記３記載のアプリケーション生成装置。
（付記６）
前記アプリケーションの前記アプリケーション属性情報には、当該アプリケーションをどれくらい緊急に当該アプリケーションの要求者のシステムに適用すべきかを表わす緊急度および当該アプリケーションを当該システムに適用させるべき担当者が示され、
前記アプリケーション状況画面表示処理手段は、前記アプリケーション状況画面として、前記特定の要求者のために生成された最新の前記アプリケーションの前記識別子とともに当該アプリケーションの前記緊急度および前記担当者を知らせるアプリケーション状況画面を表示させる、
付記４記載のアプリケーション生成装置。
（付記７）
要求者からの要求に応じて生成されたカスタムメードのアプリケーションのメンテナンスを支援するアプリケーションメンテナンス支援方法であって、
前記アプリケーションごとに当該アプリケーションによって実現される機能を示す機能構成情報を機能構成情報記憶手段に記憶させておき、
いずれかの機能に係るプログラムが更新された場合に、前記各アプリケーションの中から生成し直すべきものを前記各機能構成情報に基づいて判別する
ことを特徴とするアプリケーションメンテナンス支援方法
（付記８）
要求者からの要求に応じて生成されたカスタムメードのアプリケーションのメンテナンスを支援するコンピュータに用いられるコンピュータプログラムであって、
前記コンピュータに、
いずれかの機能に係るプログラムが更新された場合に、前記アプリケーションごとの、当該アプリケーションによって実現される機能を示す機能構成情報を、機能構成情報記憶手段から呼び出す処理を実行させ、
前記各アプリケーションの中から生成し直すべきものを、呼び出した前記各機能構成情報に基づいて判別する処理を実行させる、
ことを特徴とするコンピュータプログラム。

アプリケーション生成装置の外観の例およびハードウェア構成の例を示す図である。 アプリケーション生成装置の機能的構成の例を示す図である。 対応情報格納部の例を示す図である。 定義情報格納部の例を示す図である。 ソース編集処理の流れの例を説明するフローチャートである。 編集前後のソースの例を示す図である。 アプリケーション格納部の例を示す図である。 アプリケーション提供状況画面の例を示す図である。 機能更新履歴一覧画面の例を示す図である。 カスタムメードのアプリケーションを生成する際のアプリケーション生成装置の処理の流れの例を説明するフローチャートである。 生成済のアプリケーションをバージョンアップする際の処理の流れの例を説明するフローチャートである。 条件文を含むソースの編集前後の例を示す図である。 条件文を含むソースの編集前後の例を示す図である。 条件文を含むソースの編集前後の例を示す図である。

符号の説明

１ アプリケーション生成装置（アプリケーションメンテナンス支援装置）
１０５ コンパイル処理部（アプリケーション生成手段）
１２３ 類似ファイル判別部（要再生成アプリケーション判別手段）
７３ 定義情報（機能構成情報）
ＤＢ１ モジュールファイル等格納部（プログラム記憶手段）
ＤＢ３ 定義情報格納部（機能構成情報記憶手段）
ＪＦＬ 実行ファイル（カスタムメードのアプリケーション）
ＫＦＬ 構成用ファイル（プログラム）

Claims (5)

1. 要求者からの要求に応じて生成されたカスタムメードのアプリケーションのメンテナンスを支援するアプリケーションメンテナンス支援装置であって、
   前記アプリケーションごとに、当該アプリケーションによって実現される機能を示す機能構成情報を記憶する、機能構成情報記憶手段と、
   いずれかの機能に係るプログラムが更新された場合に、前記各アプリケーションの中から生成し直すべきアプリケーションを前記各機能構成情報に基づいて判別する、要再生成アプリケーション判別手段と、
   を有することを特徴とするアプリケーションメンテナンス支援装置。
2. 要求者からの要求に応じてカスタムメードのアプリケーションを生成するアプリケーション生成装置であって、
   所定の機能ごとに、当該所定の機能を実現するためのプログラムを記憶するプログラム記憶手段と、
   前記アプリケーションを、当該アプリケーションを要求した要求者にとって必要な前記所定の機能の前記プログラムを使用して生成する、アプリケーション生成手段と、
   前記所定の機能の前記プログラムが更新された場合に、当該所定の機能を有する前記アプリケーションを生成し直すべきであると判別する、要再生成アプリケーション判別手段と、
   を有することを特徴とするアプリケーション生成装置。
3. 前記アプリケーション生成手段は、生成し直すべきであると判別された前記アプリケーションを、更新された前記プログラムを使用して再生成する、
   請求項２記載のアプリケーション生成装置。
4. 要求者からの要求に応じて生成されたカスタムメードのアプリケーションのメンテナンスを支援するアプリケーションメンテナンス支援方法であって、
   前記アプリケーションごとに当該アプリケーションによって実現される機能を示す機能構成情報を機能構成情報記憶手段に記憶させておき、
   いずれかの機能に係るプログラムが更新された場合に、前記各アプリケーションの中から生成し直すべきものを前記各機能構成情報に基づいて判別する
   ことを特徴とするアプリケーションメンテナンス支援方法
5. 要求者からの要求に応じて生成されたカスタムメードのアプリケーションのメンテナンスを支援するコンピュータに用いられるメンテナンス支援プログラムであって、
   前記コンピュータに、
   いずれかの機能に係るプログラムが更新された場合に、前記アプリケーションごとの、当該アプリケーションによって実現される機能を示す機能構成情報を、機能構成情報記憶手段から呼び出す処理を実行させ、
   前記各アプリケーションの中から生成し直すべきものを、呼び出した前記各機能構成情報に基づいて判別する処理を実行させる、
   ことを特徴とするメンテナンス支援プログラム。