JP2007226358A - アプリケーション生成装置、アプリケーション生成方法、およびアプリケーション生成プログラム - Google Patents

Abstract

【課題】カスタムメードのアプリケーションを低コストで提供する。
【解決手段】アプリケーション生成装置１に、機能Ｆａ、Ｆｂ、Ｆｃ、…ごとに、それを実現するためのモジュールなどである構成用ファイルＫＦＬを記憶するモジュールファイル等格納部ＤＢ１と、顧客にとって必要な機能の構成用ファイルＫＦＬをモジュールファイル等格納部ＤＢ１から抽出する特定機能コード抽出部１０３と、抽出した構成用ファイルＫＦＬを使用して実行ファイルＪＦＬを生成するためのコンパイルを行うコンパイル処理部１０５と、を設ける。
【選択図】図２

Description

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

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

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

これに対し、特注品は、顧客の要望に応じて必要な機能が選定されるので、操作者にとって使い勝手がよい。

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

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

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

前述の通り、顧客の要望に応じてカスタマイズされた特注品のほうがパッケージソフトよりも使い勝手がよい。しかし、特注品は、開発に要する費用がパッケージソフトに比べて膨大である。メンテナンスに要する費用も同様である。よって、顧客には、費用の面で大きな負担が掛かる。したがって、顧客は、自らに応じてカスタマイズされたアプリケーションが低コストで提供されることを望んでいる。しかし、従来の方法では、このような顧客の要望に応えることができない。

本発明は、このような問題点に鑑み、従来よりも低コストでカスタムメードのアプリケーションを提供できるようにすることを目的とする。

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

または、所定の機能ごとに、当該所定の機能を実現するためのモジュールを記憶するモジュール記憶手段と、前記所定の機能がすべて実現可能となるように前記モジュールが実行されるようにコーディングされた、汎用的なアプリケーションである汎用アプリケーションのソースを記憶する、ソース記憶手段と、前記汎用アプリケーションの前記ソースから、前記所定の機能のうちの前記要求者にとって不要な機能に係る前記モジュールを実行させるためのコードを削除する、ソース編集手段と、編集された前記ソースを、前記モジュールを使用してコンパイルすることによって、カスタムメードのアプリケーションを生成する、カスタムメードアプリケーション生成手段と、を有することを特徴とする。好ましくは、前記ソース編集手段は、前記要求者にとって不要な機能に係る前記モジュールを実行させるためのコードが条件文に関連付けられている場合は、当該モジュールを実行させるためのコードとともに当該条件文のコードをも削除する。

本発明によると、従来よりも低コストでカスタムメードのアプリケーションを生成し提供することができる。

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

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

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

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

図３は対応情報格納部ＤＢ２の例を示す図、図４は定義情報格納部ＤＢ３の例を示す図、図５はソース編集処理の流れの例を説明するフローチャート、図６は編集前後のソースの例を示す図、図７はアプリケーション格納部ＤＢ４の例を示す図である。次に、図２に示すアプリケーション生成装置１の各部の処理内容などについて説明する。

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

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

対応情報格納部ＤＢ２には、図３に示すように、前記の特定の業務のために使用され得る機能Ｆａ、Ｆｂ、Ｆｃ、…ごとの機能対応情報７２（７２ａ、７２ｂ、７２ｃ…）が格納されている。例えば、ユーザが入力した郵便番号から行政区分および町名を特定する機能、操作方法の解説文を表示する機能、または期限を計算するための機能など種々の機能ごとの機能対応情報７２が格納されている。機能対応情報７２には、それに対応する機能を実現するための構成用ファイルＫＦＬのファイル名（対象ファイル名）およびその機能を識別するための識別コードなどが含まれている。

定義情報格納部ＤＢ３には、図４に示すように、顧客ごとの定義情報７３（７３ａ、７３ｂ、…）が格納されている。定義情報７３は、それに対応する顧客が前記の特定の業務の際に各機能Ｆａ、Ｆｂ、Ｆｃ、…を必要とするか否かを定義している。具体的には、必要な機能には「○」が付けられ、不要な機能には「×」が付けられている。

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

アプリケーション格納部ＤＢ４には、後に説明するコンパイル処理部１０５によって生成された実行ファイルＪＦＬが格納される。

提供先選択部１０１ないしコンパイル処理部１０５は、顧客の要望に応じたカスタムメードのアプリケーションを生成するための処理を、例えば次のように行う。

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

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

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

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

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

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

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

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

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

生成された実行ファイルＪＦＬは、図７に示すように、所定の規則に基づいてファイル名が付けられ作成日（生成日）、提供先、および各機能Ｆａ、Ｆｂ、Ｆｃ…の適用の有無などを示す情報と対応付けられて、アプリケーション格納部ＤＢ４に格納される。

図８はアプリケーション生成装置１の全体的な処理の流れの例を説明するフローチャートである。

次に、ある顧客のためのカスタムメードのアプリケーションを生成する際のアプリケーション生成装置１の処理の流れを、フローチャートを参照して説明する。

図８において、アプリケーション生成装置１は、アプリケーションの提供先の顧客を選択し（＃１）、その顧客にとって必要な機能をその顧客の定義情報７３（図４参照）に基づいて特定する（＃２）。

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

編集したソースを、抽出した構成用ファイルＫＦＬなどを用いてコンパイルすることによって、目的のアプリケーションである実行ファイルＪＦＬを生成する（＃５）。

そして、生成したアプリケーションすなわち実行ファイルＪＦＬをアプリケーション格納部ＤＢ４に格納する（＃６）。この際に、その実行ファイルＪＦＬにはファイル名、作成日、提供先、および各機能Ｆａ、Ｆｂ、Ｆｃ…の適用の有無などを示す情報を対応付けておく。

アプリケーション格納部ＤＢ４に格納された実行ファイルＪＦＬは、フィールドエンジニアなどの作業によって顧客の業務用システムにインストールされ使用される。

実行ファイルＪＦＬは、後日、顧客からの新たな要望に応じて生成し直す必要が生じ得る。その場合は、その新たな要望に応じて定義情報７３を登録し直し、図８で説明した処理をやり直せばよい。

本実施形態によると、特定の業務に使用され得る機能を搭載した汎用的なアプリケーションのソースから、顧客にとって不要な機能のためのモジュールのコードを簡単に削除することができる。そして、不要な機能のためのモジュールのコードが削除されたソースを従来通りコンパイルすることによって、顧客の要望に応じたカスタムメードのアプリケーションを生成する。したがって、アプリケーションを一から設計を行って生成する場合と比較して、設計に要する工数を減らし、完成したアプリケーションの品質などのテストの効率を向上させ、かつメンテナンスの効率を向上させることができる。よって、従来よりも低コストでカスタムメードのアプリケーションを顧客に提供することができる。

しかも、アプリケーション生成装置１によって生成されたカスタムメードのアプリケーションは、不要な機能のためのモジュールが含まれていないので、そのサイズを小さく抑えることができる。つまり、従来、「機能限定版」などと呼ばれるアプリケーションが存在する。機能限定版は、パッケージソフトのような汎用的なアプリケーションに搭載される機能ごとにフラグを設け、フラグの値を調整し一部の機能を使用できないように制限を掛けることによって、生成される。このような従来の機能限定版の生成方法をカスタムメードのアプリケーションの生成のために適用したとしても、そのサイズは汎用的なアプリケーションのサイズと何ら変わりない。これに対して、本実施形態によると、不要な機能のためのモジュールを含まないようにアプリケーションを生成するので、機能限定版に比べて、そのサイズを小さくすることができる。

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

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

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

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

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

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

アプリケーション生成装置の外観の例およびハードウェア構成の例を示す図である。 アプリケーション生成装置の機能的構成の例を示す図である 対応情報格納部の例を示す図である。 定義情報格納部の例を示す図である。 ソース編集処理の流れの例を説明するフローチャートである。 編集前後のソースの例を示す図である。 アプリケーション格納部の例を示す図である。 アプリケーション生成装置の全体的な処理の流れの例を説明するフローチャートである。 条件文を含むソースの編集前後の例を示す図である。 条件文を含むソースの編集前後の例を示す図である。 条件文を含むソースの編集前後の例を示す図である。

符号の説明

１ アプリケーション生成装置
１０３ 特定機能コード抽出部（プログラム抽出手段）
１０４ ソース編集処理部（アプリケーション生成手段、ソース編集手段）
１０５ コンパイル処理部（アプリケーション生成手段、カスタムメードアプリケー ＤＢ０ プロジェクトファイル格納部（ソース記憶手段）
ＤＢ１ モジュールファイル等格納部（プログラム記憶手段、モジュール記憶手段）
ＪＦＬ 実行ファイル（カスタムメードのアプリケーション）
ＫＦＬ 構成用ファイル（プログラム、モジュール）
ション生成手段）
ＰＦＬ プロジェクトファイル（汎用アプリケーション）

Claims (5)

1. 要求者からの要求に応じてカスタムメードのアプリケーションを生成するアプリケーション生成装置であって、
   所定の機能ごとに、当該所定の機能を実現するためのプログラムを記憶するプログラム記憶手段と、
   前記所定の機能のうちの前記要求者にとって必要な機能の前記プログラムを前記プログラム記憶手段から抽出するプログラム抽出手段と、
   抽出した前記プログラムを使用して前記アプリケーションを生成するアプリケーション生成手段と、
   を有することを特徴とするアプリケーション生成装置。
2. 要求者からの要求に応じてカスタムメードのアプリケーションを生成するアプリケーション生成装置であって、
   所定の機能ごとに、当該所定の機能を実現するためのモジュールを記憶するモジュール記憶手段と、
   前記所定の機能がすべて実現可能となるように前記モジュールが実行されるようにコーディングされた、汎用的なアプリケーションである汎用アプリケーションのソースを記憶する、ソース記憶手段と、
   前記汎用アプリケーションの前記ソースから、前記所定の機能のうちの前記要求者にとって不要な機能に係る前記モジュールを実行させるためのコードを削除する、ソース編集手段と、
   編集された前記ソースを、前記モジュールを使用してコンパイルすることによって、カスタムメードのアプリケーションを生成する、カスタムメードアプリケーション生成手段と、
   を有することを特徴とするアプリケーション生成装置。
3. 前記ソース編集手段は、前記要求者にとって不要な機能に係る前記モジュールを実行させるためのコードが条件文に関連付けられている場合は、当該モジュールを実行させるためのコードとともに当該条件文のコードをも削除する、
   請求項２記載のアプリケーション生成装置。
4. 要求者からの要求に応じてカスタムメードのアプリケーションを生成するアプリケーション生成方法であって、
   所定の機能ごとに、当該所定の機能を実現するためのプログラムをプログラム記憶手段に記憶させておき、
   前記所定の機能のうちの前記要求者にとって必要な機能の前記プログラムを前記プログラム記憶手段から抽出し、
   抽出した前記プログラムを使用して前記アプリケーションを生成する、
   ことを特徴とするアプリケーション生成方法。
5. 要求者からの要求に応じてカスタムメードのアプリケーションを生成するコンピュータに用いられるアプリケーション生成プログラムであって、
   所定の機能ごとに当該所定の機能を実現するためのプログラムを記憶するプログラム記憶手段から、前記要求者にとって必要な機能の前記プログラムを抽出する処理と、
   抽出した前記プログラムを使用して前記アプリケーションを生成する処理と、
   をコンピュータに実行させるためのアプリケーション生成プログラム。