JP7148804B2 - ソースファイル生成プログラム、ソースファイル生成方法、および情報処理装置 - Google Patents

Description

本発明は、ソースファイル生成プログラム、ソースファイル生成方法、および情報処理装置に関する。

コンピュータシステムでは、ある言語で作成されたプログラムを、別の言語で作り直す場合がある。例えばサーバクライアントシステムで実行されていたプログラムを、Ｗｅｂベースのシステムにマイグレーションする場合、開発者が、そのプログラムをＷｅｂ開発用の言語で書き換える。

プログラムを書き換える場合、開発者は、例えばテキストエディタを用いて、移行先の言語によってプログラムをコーディングする。また開発者は、オーサリングツールを用いて、移行先の言語によるプログラムを生成することもできる。

プログラムを変換する技術としては、例えば非Ｗｅｂシステム用のプログラムを、Ｗｅｂシステム用のプログラムに自動的に変換する装置が提案されている。また、１以上のマークアップ言語により記述された文書を、生成、編集、表示、または保存のうち少なくとも１つのために適切に処理するデータ処理装置も提案されている。また、表形式のデータとマークアップ言語形式のデータとの間、あるいは、異なるマークアップ言語形式間でのデータ変換を容易に行うことを可能とする情報処理装置も提案されている。さらにレガシーアプリケーションからルールコンポーネントを取得し、次に、ルールコンポーネントのレガシールールから中間状態式を生成するための装置も提案されている。

国際公開第２００９／１５７０８２号 特表２００７－５３２９８７号公報 特開２００５－３５２７７４号公報 特表２０１０－５３０５７５号公報

移行前のプログラムを実行した際に表示される画面は、ユーザが操作しやすいように画面フォームが工夫されていることがある。しかし従来のプログラムの自動変換技術では、元の画面フォームを崩さずにプログラムを変換することができない。

１つの側面では、本発明は、画面フォームを崩さずにプログラムを変換することを目的とする。

１つの案では、以下の処理をコンピュータに実行させるソースファイル生成プログラムが提供される。
コンピュータは、画面フォームを構成する要素の表示態様を第１プログラミング言語で規定する第１コードを含む第１ソースファイルに基づいて、第１コードから、要素の表示態様に関する項目の項目値を抽出する。次にコンピュータは、要素の表示態様を第２プログラミング言語で規定するコードの記述のうちの項目の項目値の設定領域に、項目に対応する変数名が設定された変換用コードに基づいて、変換用コードの変数名を第１ソースファイルから抽出された項目値に変換することで、要素の表示態様を第２プログラミング言語で規定した第２コードを生成する。そしてコンピュータは、生成した第２コードを第２ソースファイルに対して書き込む。

１態様によれば、画面フォームを崩さずにプログラムを変換することができる。

第１の実施の形態に係る情報処理装置の一例を示す図である。 ソースファイル生成方法の一例を示す図である。 第２の実施の形態に係るシステムの一例を示す図である。 本実施の形態に用いる端末装置のハードウェアの一構成例を示す図である。 端末装置のプログラム変換支援機能を示すブロック図である。 変換前のソースファイル群の一例を示す図である。 画面フォーム定義が記述されたソースファイルの一例を示す図である。 コントロール一覧の一例を示す図である。 スケルトンファイル群の一例を示す図である。 ＣＳＳのスケルトンファイルの一例を示す図である。 コンバートテーブルの一例を示す図である。 基礎情報を用いたソースコード追加のためのソースコード定義情報の一例を示す図である。 設計値を用いたソースコード追加のためのソースコード定義情報の一例を示す図である。 カラーテーブルの一例を示す図である。 基礎情報が設定された画面項目定義書の一例を示す図である。 設計値が設定された画面項目定義書の一例を示す図である。 変換後のソースファイル群の一例を示す図である。 ＣＳＳのソースファイルの一例を示す図である。 マイグレーション処理の手順の一例を示すフローチャートである。 基礎情報自動展開処理の手順の一例を示すフローチャートである。 基礎情報の自動展開の一例を示す図である。 画面フォームについてのソースファイルの生成例を示す図である。 ソースファイル自動生成処理の手順の一例を示すフローチャートである。 項目定義ソースコード生成処理の手順の詳細を示すフローチャートである。 スケルトンファイルへのソースコードの挿入位置とコンバートテーブルの処理名との対応関係を示す図である。 基礎情報が設定された画面項目定義書に基づくソースコードの自動編集例を示す図である。 設計値が設定された画面項目定義書に基づくソースコードの自動編集例を示す図である。 スケルトンファイルへのソースコードの挿入例を示す図である。 Ｗｅｂアプリの実装例を示す図である。 Ｗｅｂアプリ操作画面の一例を示す図である。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず第１の実施の形態について説明する。なお、以下の説明では、プログラミング言語による処理を記述したソースコードを、単にコードと呼ぶ場合がある。

図１は、第１の実施の形態に係る情報処理装置の一例を示す図である。図１には、ソースファイル生成方法を実施する情報処理装置１０の例を示している。情報処理装置１０は、例えばソースファイル生成方法の処理手順が記述されたソースファイル生成プログラムを実行することにより、ソースファイル生成方法を実施することができる。

情報処理装置１０は、ソースファイル生成方法を実施するために、記憶部１１と処理部１２とを有する。記憶部１１は、例えば情報処理装置１０が有するメモリ、またはストレージ装置である。処理部１２は、例えば情報処理装置１０が有するプロセッサ、または演算回路である。

記憶部１１には、第１ソースファイル１、第２ソースファイル２、および変換用コード３を記憶する。第１ソースファイル１は、画面フォームを構成する要素の表示態様を第１プログラミング言語で規定する第１コードを含むファイルである。画面フォームを構成する要素は、フレーム、ボタン、テキストボックスなどである。

第２ソースファイル２は、画面フォームを構成する要素の表示態様を第２プログラミング言語で規定するコードを記述するためのファイルである。例えば第２ソースファイル２は、第２プログラミング言語で記述されたプログラムに共通に記載するコードが予め書き込まれたスケルトンファイルである。

変換用コード３には、画面フォームを構成する要素の表示態様を第２プログラミング言語で規定するコードが記述されており、そのコードにおける項目の項目値の設定領域に、項目に対応する変数の変数名が設定されている。図１の例では、星印に囲まれた文字列が変数名である。例えば項目「背景色」の変数名は「ＢａｃｋＣｏｌｏｒ」であり、項目「説明文の表示位置」の変数名は「Ａｌｉｇｎｍｅｎｔ」である。なお変換用コード３に示されている変数名「ＩｔｅｍＮａｍｅ」は、変換用コード３を適用する要素の要素名を示す変数の変数名である。

処理部１２は、記憶部１１に格納された情報に基づいて、第１ソースファイル１と同様の処理を第２プログラミング言語で記述したソースファイルを生成する。
図２は、ソースファイル生成方法の一例を示す図である。処理部１２は、まず第１ソースファイル１に基づいて、第１コードから、画面フォームを構成する要素の表示態様に関する項目の項目値を抽出する。表示態様に関する項目は、背景色、説明文、説明文のフォント、説明文のフォントサイズ、前景色（説明文の色）、説明文の表示位置（左寄せ、中央寄せなど）、ボタンなどのオブジェクトのサイズ、オブジェクトの表示位置などである。

処理部１２は、抽出した項目値を、例えば画面項目定義情報４に設定する。処理部１２は、抽出した項目値を、第１プログラミング言語の定義に従った表記形式から第２プログラミング言語の定義に従った表記形式に変換することもできる。例えば背景色などの色の表記形式として、第１プログラミング言語では色の名前を文字列で指定し、第２プログラミング言語では、色に対応する数値で指定する場合がある。このような場合、処理部１２は、第１ソースファイル１における色を示す名前（例えば「Ｓｉｌｖｅｒ」）を、該当する色に対応する数値（例えば「＃Ｃ０Ｃ０Ｃ０」）に変換して、画面項目定義情報４に設定する。

なお第１ソースファイル１に示されている項目の項目名と該当項目に対応する変数名との対応関係は、予め処理部１２に設定されている。例えば第１ソースファイル１に記載されている「ＴｅｘｔＡｌｉｇｎ」が説明文の表示位置を規定する項目であり、対応する変数名が「Ａｌｉｇｎｍｅｎｔ」であることは、予め処理部１２に設定されている。

画面項目定義情報４には、例えば画面フォームを構成する要素の要素名ごとに、該当要素の表示形態に関する項目の項目値が、該当項目の変数名に対応付けて設定される。例えば画面項目定義情報４には、要素名「ＢＴ＿Ｂｔｎ０１」の要素に対応づけて、項目「背景色」（変数名「ＢａｃｋＣｏｌｏｒ」）の項目値「＃Ｃ０Ｃ０Ｃ０」が設定されている。

処理部１２は、変換用コード３に基づいて、変換用コードの変数名を、第１ソースファイル１から抽出された要素名または項目値に変換することで、要素の表示態様を第２プログラミング言語で規定した第２コード５を生成する。例えば変数名「ＩｔｅｍＮａｍｅ」は要素に対応し、変換用コード３内の変数名「ＩｔｅｍＮａｍｅ」と変数名の前後の星印が、画面項目定義情報４に示される要素の要素名「ＢＴ＿Ｂｔｎ０１」に変換される。また変数名「ＢａｃｋＣｏｌｏｒ」は項目「ＢａｃｋＣｏｌｏｒ」に対応し、その変数名「ＢａｃｋＣｏｌｏｒ」と変数名の前後の星印が、第１ソースファイル１に示された項目の項目値「＃Ｃ０Ｃ０Ｃ０」に変換される。変数名「Ａｌｉｇｎｍｅｎｔ」は項目「Ａｌｉｇｎｍｅｎｔ」に対応し、変換用コード３内の変数名「Ａｌｉｇｎｍｅｎｔ」と変数名の前後の星印が、第１ソースファイル１に示された項目の項目値「Ｃｅｎｔｅｒ」に変換される。

そして処理部１２は、生成した第２コード５を第２ソースファイル２に対して書き込む。これにより、第１ソースファイル１と同様の処理を第２プログラミング言語で記述した第２ソースファイル６が生成される。生成された第２ソースファイル６に基づいてプログラムを実行すると、第１ソースファイル１に基づいてプログラムを実行した場合と同様の画面フォームによって画面が表示される。

このように情報処理装置１０は、第１ソースファイル１に基づいて、画面フォームを崩さずに第２ソースファイル６を生成することができる。その結果、例えば第１ソースファイルに基づくソフトウェアを、ソースコードを変換してマイグレーションによって他のサーバへ移動させる場合であっても、ユーザの端末装置に対して表示される画面フォームが変わらずにすむ。その結果、元のソフトウェアにおいてユーザが操作しやすいように考えて設計された画面フォームを維持でき、マイグレーションを行った後もユーザによるソフトウェアの使いやすさを維持できる。

なお、変換用コード３には、変換用コード３内に記述されたコードの、第２ソースファイル２への適用条件を定義しておくことができる。例えばコードごとに、そのコードの適用対象となる要素の種類（ボタン、テキストボックスなど）が、適用条件として変換用コード３に設定される。また変換用コード３内に、特定の要素に関する複数の項目それぞれの項目値を定義するためのコードがまとめて記載されている場合、そのコードの集合全体に対する適用条件を、変換用コード３に定義しておくこともできる。例えば変換用コード３に記述されたボタンの表示態様を定義するコードには、そのコードの適用条件として、要素の種類がボタンであることが設定される。

変換用コード３内にコードの適用条件が定義されている場合、処理部１２は、各コードについて、適用条件を満たす場合に、そのコードの変数名の項目値への変換、および変換によって生成された第２コードの第２ソースファイル２への書き込みを実行する。このように、適用条件を設定しておくことで、第１ソースファイルにおける画面フォームを構成するさまざまな要素に対して、容易に対応可能となる。

処理部１２は、項目値の抽出の際には、例えば画面フォームを構成する要素に対する命名規約に従った要素名を含む行を、第１ソースファイル１から検索する。例えば命名規約において、ボタンの要素には、「ＢＴ＿」をプレフィックスとして付けた名前とすることが決まっているものとする。この場合、処理部１２は、第１ソースファイル１から「ＢＴ＿」と前方一致する文字列を検索する。そして処理部１２は、要素名を含む行に続けて記述されている、表示態様を規定するコードを、要素の表示態様を規定する第１コードとして特定する。図２の例であれば、「ＢＴ＿Ｂｔｎ０１」の行に続けて記載されている「ＢａｃｋＣｏｌｏｒ＝Ｓｉｌｖｅｒ」や「ＴｅｘｔＡｌｉｇｎ＝Ｃｅｎｔｅｒ」などのコードが、要素名「ＢＴ＿Ｂｔｎ０１」の要素の表示態様を規定する第１コードとして特定される。このように、第１ソースファイル１の要素に、命名規約に従った要素名を付けておくことで、第１ソースファイルからの要素の表示態様を規定する第１コードの特定が容易となる。その結果、第１ソースファイル１に定義されている画面フォームを構成する要素を、変換後の第２ソースファイル６に漏れなく反映させることができる。

〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、クライアントサーバシステムで稼働しているソフトウェアを、Ｗｅｂアプリケーションソフトウェア（以下、Ｗｅｂアプリと呼ぶ）に変換するものである。

例えば、現在稼働しているＶＢ．ＮＥＴ（商標）言語で構築されたソフトウェアを用いて運用されているクライアントサーバシステムを、Ｗｅｂシステムに移行する場合がある。この場合、Ｗｅｂ開発用の言語を用いてソフトウェアを新規開発することとなる。

Ｗｅｂ開発の言語としては、例えばＨＴＭＬ（HyperText Markup Language）を中心とする複数の言語を利用することができる。例えば開発者は、ＨＴＭＬに、ＪａｖａＳｃｒｉｐｔ（登録商標）やＣＳＳ（Cascading Style Sheets）を組み合わせて、Ｗｅｂアプリを生成する。一般的には、開発者は、テキストエディタでタグやスタイルを直接コーディングする。また開発者は、ｗｅｂオーサリングツール（Ｗｅｂを構成するＨＴＭＬ、ＣＳＳなどのファイルを編集するデザインツール）を利用して、コーディングの効率化を図ることもできる。

ただし開発者がコーディングを行う場合、開発者にＷｅｂアプリ開発スキルが要求される。また開発者の開発スキルの違いにより、開発されたＷｅｂアプリの品質のばらつきが発生し、画面開発品質を均一化できない。これによって、当初の見込み通りの効率化が図れない可能性がある。

そこで第２の実施の形態では、クライアントサーバシステムで稼働しているソフトウェアのＷｅｂアプリへの変換の自動化を支援する。
図３は、第２の実施の形態に係るシステムの一例を示す図である。ソフトウェアの移行元のサーバ３１、ソフトウェアの移行先のサーバ３２、および端末装置１００が、ネットワーク２０を介して接続されている。サーバ３１は、クライアントサーバシステム用に開発されたソフトウェアによりサービスを提供しているコンピュータである。サーバ３２は、Ｗｅｂシステムの運用に利用するコンピュータである。

端末装置１００は、サーバ３１に実装されているソフトウェアのソースファイルに基づいて、Ｗｅｂアプリ用のソースファイルを生成するコンピュータである。例えば端末装置１００は、サーバ３１からソースファイルを取得し、取得したソースファイルをＷｅｂアプリ用のソースファイルに変換する。そして端末装置１００は、変換後のソースファイルをサーバ３２に実装する。

図４は、本実施の形態に用いる端末装置のハードウェアの一構成例を示す図である。端末装置１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、端末装置１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。

グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬ（Electro Luminescence）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ－ＲＡＭ、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ－Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、端末装置１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

端末装置１００は、以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。サーバ３１，３２も、図４に示した端末装置１００と同様のハードウェアにより実現することができる。また第１の実施の形態に示した情報処理装置１０も、図４に示した端末装置１００と同様のハードウェアにより実現することができる。

端末装置１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。端末装置１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、端末装置１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。また端末装置１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

次に、端末装置１００におけるプログラム変換支援機能について具体的に説明する。
図５は、端末装置のプログラム変換支援機能を示すブロック図である。端末装置１００は、記憶部１１０、ソースファイル取得部１２０、コントロール名リネイム部１３０、フォーム情報展開部１４０、設計値設定部１５０、ソースコード変換部１６０、およびデプロイ部１７０を有する。

記憶部１１０は、プログラムの変換に使用する情報を記憶する。例えば端末装置１００のメモリ１０２またはストレージ装置１０３の記憶領域の一部が、記憶部１１０として使用される。例えば記憶部１１０は、変換前のソースファイル群１１１、コントロール一覧１１２、スケルトンファイル群１１３、コンバートテーブル１１４、カラーテーブル１１５、画面フォームの基礎情報が設定された画面項目定義書１１６、画面フォームの詳細設計値が設定された画面項目定義書１１７、および変換後のソースファイル群１１８を記憶する。

変換前のソースファイル群１１１は、移行対象のソフトウェアの生成元となったソースファイルの集合である。これらのソースファイルは、例えばＨＴＭＬなどのＷｅｂ用の言語とは異なる言語で記述されている。

コントロール一覧１１２は、移行対象のソフトウェアにおいて表示する画面のフォームやコントロールの定義情報の一覧である。コントロールとは、画面に配置され、何らかの機能と関連付けられたオブジェクトである。コントロールには、ボタン、テキストボックス、リストボックスなどがある。ボタンであれば、そのボタンが押されたときに実行する処理機能と関連付けられている。テキストボックスであれば、テキストボックスに入力された文字列を、所定の変数として記憶する機能と関連づけられている。

スケルトンファイル群１１３は、Ｗｅｂアプリを作成するためのプログラムの雛形（スケルトンファイル）の集合である。例えばスケルトンファイル群１１３には、ＣＳＳ、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ（登録商標）それぞれのスケルトンファイルが含まれる。

コンバートテーブル１１４は、スケルトンファイルに追加するソースコードの雛形である。コンバートテーブル１１４には、画面のフォームやコントロールそれぞれについての、変換先の言語によるソースコードの雛形が含まれる。なおコンバートテーブル１１４は、第１の実施の形態に示した変換用コード３の一例である。

カラーテーブル１１５は、変換元のソースコードにおける色の識別子と、変換先のソースコードにおける同じ色の識別子との対応関係を示すデータテーブルである。
画面項目定義書１１６は、変換前のソースファイルから抽出できる画面項目の基礎情報を示すデータテーブルである。画面項目の基礎情報は、表示位置、色、フォント、フォントサイズなどである。画面項目定義書１１６には、例えばボタンやテキストボックスなどのコントロールの画面内での位置を示す情報などが含まれる。

画面項目定義書１１７は、変換前のソースファイルから抽出困難な画面項目の設計値を示すデータテーブルである。画面項目定義書１１７には、例えば画面内に配置されるコントロールのタブ順、桁数、文字種などの設定値が含まれる。

変換後のソースファイル群１１８は、ｗｅｂアプリ用のソースファイルの集合である。これらのソースファイルは、例えばＣＳＳ、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ（登録商標）などの言語で記述されている。

ソースファイル取得部１２０は、サーバ３１から、移行対象のソフトウェアのソースファイルを取得する。なおソースファイル取得部１２０は、移行対象のソフトウェアが複数のソースファイルに基づいて生成されている場合、複数のソースファイルを取得する。ソースファイル取得部１２０は、取得したソースファイルを記憶部１１０に格納する。

コントロール名リネイム部１３０は、ソースファイルに含まれるコントロール名を、そのコントロール名に対応するコントロールの種別に応じた名前にリネイムする。例えばコントロール名リネイム部１３０は、ソースファイルの記述言語における統合開発環境を提供するソフトウェアである。コントロール名リネイム部１３０は、ソースファイルの構造を解析し、ソースファイル内に定義されているコントロールの種別を判別し、該当コントロールのコントロール名を表示する。開発者は、表示されたコントロール名に対して、所定の命名規約に従って、例えば対応するコントロールの種別に応じたプレフィックスを付加したコントロール名を入力する。コントロール名リネイム部１３０は、ソースファイル内の該当コントロールのコントロール名を、入力されたコントロール名にリネイムする。なおコントロール名リネイム部１３０は、コントロールの種別を判別したとき、所定の命名規約に従って、そのコントロールの名前を自動でリネイムしてもよい。

フォーム情報展開部１４０は、取得したソースファイルから画面フォームの基礎情報を抽出し、画面項目定義書１１６に出力する。例えばフォーム情報展開部１４０は、リネイムされたコントロール名に基づいて、ソースファイル内のコントロールに関するソースコードを判断し、該当ソースコードの定義内容を画面項目定義書１１６に出力する。

設計値設定部１５０は、例えば開発者からの入力に基づいて、画面内に配置されるコントロールのタブ順、桁数、文字種などの設定値を、画面項目定義書１１７に出力する。
ソースコード変換部１６０は、変換前のソースファイルのソースコードを、別の言語によるソースコードに変換し、変換後のソースファイルを生成する。例えばソースコード変換部１６０は、画面項目定義書１１６，１１７に基づいてコンバートテーブル１１４に示されるソースコードを変換し、変換したソースコードをスケルトンファイルのキーワードと置き換える。ソースコード変換部１６０は、ソースコードを変換することで生成されたソースファイルを、記憶部１１０に格納する。

デプロイ部１７０は、変換後のソースファイル群１１８に基づいてＷｅｂアプリを生成し、そのＷｅｂアプリをサーバ３２に実装する。例えばデプロイ部１７０は、コンパイル可能なソースファイルをコンパイルして実行形式のファイルに変換後、ソースファイルまたは実行形式のファイルを含むＷｅｂアプリのファイル群を、サーバ３２に送信する。

なお、図５に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図５に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。

次に図６～図１８を参照して、記憶部１１０に格納される情報について詳細に説明する。
図６は、変換前のソースファイル群の一例を示す図である。変換前のソースファイル群１１１には、複数のソースファイル１１１ａ，１１１ｂ，・・・が含まれる。複数のソースファイル１１１ａ，１１１ｂ，・・・のうちの１つには、例えば画面フォーム定義が記述されている。

図７は、画面フォーム定義が記述されたソースファイルの一例を示す図である。図７には、ＶＢ．ＮＥＴ（商標）によって画面フォーム定義を記述したソースファイル１１１ａの例が示されている。図７に示したソースファイル１１１ａは、コントロール名をリネイム後のものである。例えばソースファイル１１１ａでは、元のコントロール名「Ｂｔｎ０１」が「ＢＴ＿Ｂｔｎ０１」にリネイムされている。「ＢＴ＿Ｂｔｎ０１」のうちの「ＢＴ＿」が追加されたプレフィックスである。

各コントロールにどのようなプレフィックスを追加するのかは、コントロール一覧１１２に定義されている。
図８は、コントロール一覧の一例を示す図である。コントロール一覧１１２には、変換元コントロール種別、プレフィックス、変換先コントロール種別、および配置制限の欄が設けられている。変換元コントロール種別の欄には、変換元のソースコードに設定可能なコントロールの種別が示されている。プレフィックスの欄には、変換先のコントロール種別に応じたプレフィックスの文字列が示されている。変換先コントロール種別の欄には、変換元コントロール種別に対応する変換先のソースコードにおけるコントロール種別が設定されている。配置制限の欄には、画面内でのコントロールの配置についての制限事項が定義されている。

図８の例では、変換元のコントロール種別に対応する変換先のコントロール種別が複数存在することがある。例えば変換元コントロール種別「Ｐａｎｅｌ」に対応する変換先コントロール種別には「ＦＲＡＭＥ」、「ＤＩＶ」、「ボタングループ」などがある。

配置制限としては、例えば他のコントロールとの相対的位置関係が定義される。配置先コントロール種別「ＦＲＡＭＥ」のコントロールであれば、「Ｆｏｒｍ」の一階層上にのみ配置可能であることが定義されている。

図９は、スケルトンファイル群の一例を示す図である。スケルトンファイル群１１３には、Ｗｅｂアプリを作成するのに使用する言語ごとのスケルトンファイル１１３ａ，１１３ｂ，１１３ｃを記憶する。

図１０は、ＣＳＳのスケルトンファイルの一例を示す図である。スケルトンファイル１１３ａには、例えば、「ＣＳＳ＿０１」と「＄ＣＳＳ＿０１」との間に処理の記述領域が設けられている。スケルトンファイル１１３ａ内において、所定の記号（二重鉤括弧、隅付き括弧など）で囲まれた部分に記載されているのは変数名である。生成されるスケルトンファイルでは、変数名は、対応する変数の値に置き換えられる。

例えばスケルトンファイル１１３ａには、スケルトンファイル１１３ａに基づいて生成するソースファイルのファイル名「ＷＤ『ＪＡＶＡＡＰＬＩＤ＿Ｓｋｅｌｅｔｏｎ』．ｃｓｓ」が設定されている。またスケルトンファイル１１３ａにおける処理の記述領域内に、ＣＳＳのソースコード４０が記述されている。ソースコード４０内の隅付き括弧で囲まれた部分は、隅付き括弧内に示す項目定義名に対応するソースコードに置き換えられる。

図１１は、コンバートテーブルの一例を示す図である。コンバートテーブル１１４には、項目定義の識別番号（Ｎｏ．）に対応付けて、項目定義を適用するスケルトンファイル内の処理、設定値の取得先、ソースコード、編集条件、およびソースコードの１行ごとの条件が設定されている。項目定義を適用するスケルトンファイル内の処理は、スケルトンファイル内の隅付き括弧内に示された変数名によって特定されている。設定値の取得先は、変換前のソースファイル群１１１のうちのどのソースファイルから設定値を取得するのかを示している。例えば取得先が「ＦｒｍＩｎｆｏ」であれば、基礎情報が設定された画面項目定義書１１６が、設定値の取得先となる。取得先が「ＰｓｉＩｎｆｏ」であれば、設計値が設定された画面項目定義書１１７が、設定値の取得先となる。

なお、ソースコード、編集条件、およびソースコードの１行ごとの条件が、スケルトンファイルに追加するソースコードの具体的な内容を定義したソースコード定義情報１１４ａ，１１４ｂである。

図１２は、基礎情報を用いたソースコード追加のためのソースコード定義情報の一例を示す図である。図１２には、処理「項目定義２０」に対応するソースコード定義情報１１４ａを示している。ソースコード定義情報１１４ａ内のソースコードには、星印で囲まれた部分に、該当箇所に設定する値の変数名が設定されている。またソースコード定義情報１１４ａの先頭の行には、該当ソースコード定義情報１１４ａの編集条件が設定されている。ソースコード定義情報１１４ａを用いたスケルトンファイルへのソースコードの追加は、編集条件を満たすコントロールに対して適用される。またソースコードの各行には、対応する行のソースコードをスケルトンファイルに追加する条件が設定されている。

編集条件および行ごとの条件において、「＝」は値が等しいこと（イコール）を示し、「＜＞」は値が異なること（ノットイコール）を示す。
例えば図１２の例では、編集条件が「ｔｙｐｅ；＝；Ｌａｂｅｌ＆＆ＩｔｅｍＴｙｐｅ；＝；ＢＴ，ＢＬ」である。これはｔｙｐｅが「Ｌａｂｅｌ」であり、かつＩｔｅｍＴｙｐｅが「ＢＴ」または「ＢＬ」のコントロールに対して、ソースコード定義情報１１４ａに応じたソースコードの追加を行うことを示している。またソースコードの２行目の条件は、「Ｖｉｓｉｂｌｅ；＜＞；－」である。これはＶｉｓｉｂｌｅが「－」（値なし）以外の場合に、対応する行のソースコードを、スケルトンファイルに追加することを示している。

図１３は、設計値を用いたソースコード追加のためのソースコード定義情報の一例を示す図である。図１３には、処理「項目定義６」に対応するソースコード定義情報１１４ｂを示している。ソースコード定義情報１１４ｂのデータ構造は、図１２に示したソースコード定義情報１１４ａと同様である。

画面項目定義書１１６，１１７に設定された値を用いて、ソースコード定義情報１１４ａ，１１４ｂに示されるソースコードを修正し、スケルトンファイルに挿入することで、変換後のソースファイルを生成することができる。基礎情報が設定された画面項目定義書１１６は、ソースファイルから自動生成することができる。その際、色の指定方法などの属性値の指定方法が、変換前の言語に従った指定方法から変換後の言語に従った指定方法に変更される。変換前後の属性値の対応関係は、予めデータテーブルに設定されている。例えば色の対応関係は、カラーテーブル１１５に設定される。

図１４は、カラーテーブルの一例を示す図である。カラーテーブル１１５には、色の設定対象を示す属性ごとに、変換前の言語による色の表記方法に対応する、変換後の色の表記方法が設定されている。属性としては、背景「ＢａｃｋＣｏｌｏｒ」と前景「ＦｏｒｅＣｏｌｏｒ」とがある。図１４の例では、変換前の言語では、表示色が、その色の名称の文字列（「Ｓｉｌｖｅｒ」など）で指定される。それに対して、変換後の言語では、表示色が、その色を表す１６進数の数値（「＃Ｃ０Ｃ０Ｃ０」など）で指定される。

フォーム情報展開部１４０は、ソースファイルから画面項目定義書を自動展開する際に、カラーテーブル１１５を参照して、表示色の指定方法を変換する。
図１５は、基礎情報が設定された画面項目定義書の一例を示す図である。基礎情報が設定された画面項目定義書１１６には、名称「ＦｒｍＩｎｆｏ」が付与されている。画面項目定義書１１６には、コントロールの名称（ＩｔｅｍＮａｍｅ）に対応付けて、そのコントロールについての表示形態の基礎情報が、表示形態を規定する項目の変数名に対応付けて設定されている。表示形態の基礎情報としては、変換元コントロール種別（変数名：ｔｙｐｅ）、背景色（変数名：ＢａｃｋＣｏｌｏｒ）、説明文（変数名：Ｃａｐｔｉｏｎ）、説明文の表示位置（変数名：Ａｌｉｇｎｍｅｎｔ）、コントロールを使用可能か否かの情報（変数名：Ｅｎａｂｌｅｄ）、説明文のフォント名（変数名：ＦｏｎｔＮａｍｅ）、説明文のフォントサイズ（変数名：ＦｏｎｔＳｉｚｅ）、前景色（変数名：ＦｏｒｅＣｏｌｏｒ）、ボックスの重なり順（変数名：ｚＩｎｄｅｘ）などがある。なお説明文は、例えばコントロールがボタンであれば、そのボタンに表示される文字列である。前景色は、説明文の色である。各コントロールの項目ごとに変数名に対応付けて設定された値が、該当コントロールに関するコードを生成する際の、該当変数名に対応する変数値となる。

図１６は、設計値が設定された画面項目定義書の一例を示す図である。設計値が設定された画面項目定義書１１７には、名称「ＰｓｉＩｎｆｏ」が付与されている。画面項目定義書１１７には、操作順を示す番号（ＢｒａｎｃｈＮｕｍｂｅｒ）の順番で、コントロールの名称（ＩｔｅｍＮａｍｅ）に対応付けて、そのコントロールについての設計値が設定されている。設計値としては、入力を受け付けるか否を示す情報（ＩｎｐｕｔＴｙｐｅ）、文字か数値かを示すデータタイプ（ＤａｔａＴｙｐｅ）、表示領域の幅（ＤｉｓｐｌａｙＬｅｎｇｔｈ）、データの文字数（ＤａｔａＬｅｎｇｔｈ）などがある。

図１７は、変換後のソースファイル群の一例を示す図である。変換後のソースファイル群１１８には、複数のソースファイル１１８ａ，１１８ｂ，１１８ｃが含まれる。ソースファイル１１８ａには、例えばＣＳＳによって画面フォーム定義が記述されている。ソースファイル１１８ｂには、例えばＨＴＭＬによってＷｅｂアプリ全体の構造が定義されている。ソースファイル１１８ｃには、例えばＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプト言語によって、Ｗｅｂアプリにおいて実行する処理内容が記述されている。

図１８は、ＣＳＳのソースファイルの一例を示す図である。ＣＳＳのソースファイル１１８ａは、ＣＳＳのスケルトンファイル１１３ａを、コンバートテーブル１１４、画面項目定義書１１６，１１７に基づいて自動編集することで生成される。

なお、画面フォームのコントロールの種類が増えた場合は、開発者は、コントロール一覧１１２、スケルトンファイル１１３ａ、コンバートテーブル１１４に、新たなコントロールに応じた情報を追記する。

端末装置１００は、図６～図１８に示した情報を利用して、ソフトウェアのマイグレーションを実施する。以下、ソフトウェアのマイグレーション処理について詳細に説明する。

図１９は、マイグレーション処理の手順の一例を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］ソースファイル取得部１２０は、ソフトウェアの移行元のサーバ３１から、該当ソフトウェアの１以上のソースファイルを取得する。ソースファイル取得部１２０は、取得したソースファイルを記憶部１１０に格納する。

［ステップＳ１０２］コントロ－ル名リネイム部１３０は、画面フォーム定義が記述されたソースファイル１１１ａに示されるコントロール名を、対応するコントロールの種別に応じてリネイムする。例えばコントロ－ル名リネイム部１３０は、ソースファイル１１１ａの構造を解析してコントロール名を抽出し、そのコントロール名を表示する。そしてコントロール名リネイム部１３０は、表示したコントロール名の変更入力を受け付ける。例えば開発者は、コントロールの種別に応じてプレフィックスをコントロール名の先頭に追加したコントロール名を入力する。コントロール名リネイム部１３０は、コントロール名をリネイムしたソースファイル１１１ａを記憶部１１０に格納する。

その後、開発者は、端末装置１００にソフトウェアの自動変換の実行を指示する入力を行う。すると端末装置１００において、ステップＳ１０３の処理が行われる。
［ステップＳ１０３］フォーム情報展開部１４０は、開発環境を生成する。例えばフォーム情報展開部１４０は、ソースファイル変換用のフォルダを作成し、作成したフォルダにスケルトンファイル群１１３のコピーを格納する。

［ステップＳ１０４］フォーム情報展開部１４０は、ソースファイル群１１１に基づいて、画面フォームの基礎情報を、画面項目定義書１１６に自動展開する。基礎情報の自動展開処理の詳細は後述する（図２０参照）。

［ステップＳ１０５］設計値設定部１５０は、開発者からの入力に基づいて、設計値が設定された画面項目定義書１１７を生成する。設計値設定部１５０は、生成した画面項目定義書を記憶部１１０に格納する。

［ステップＳ１０６］ソースコード変換部１６０は、スケルトンファイル群１１３を用いて、Ｗｅｂアプリ用のソースファイル群１１８を自動生成する。例えばソースコード変換部１６０は、コンバートテーブル１１４と画面項目定義書１１６，１１７とに示された情報に従ってスケルトンファイルを編集することで、ＣＳＳによるソースファイル１１８ａを生成する。またソースコード変換部１６０は、ソフトウェアの全体の構造が定義されたソースファイルを、例えばＨＴＭＬによるソースファイル１１８ｂに変換する。さらにソースコード変換部１６０は、演算処理などの処理が定義されたソースファイルを、ＨＴＭＬから呼び出し可能なスクリプト言語によるソースファイル１１８ｃに変換する。ソースファイル自動生成処理の詳細は後述する（図２３参照）。

［ステップＳ１０７］デプロイ部１７０は、変換後のソースファイル群１１８を移行先のサーバ３２にデプロイする。例えばデプロイ部１７０は、コンパイル可能な言語で作成されたソースファイルをコンパイルし、ソースコードまたはコンパイル後の実行形式のファイルをサーバ３２に送信する。そしてデプロイ部１７０は、サーバ３２に対して送信したファイルを用いたＷｅｂアプリの実行環境の構築操作を実施する。

このような手順でソフトウェアのマイグレーションが行われる。
次に基礎情報自動展開処理の手順について詳細に説明する。
図２０は、基礎情報自動展開処理の手順の一例を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。

［ステップＳ１１１］フォーム情報展開部１４０は、基礎情報を設定する画面項目定義書１１６を初期化する。例えばフォーム情報展開部１４０は、基礎情報の設定項目を各行のラベルに設定した表を作成する。

［ステップＳ１１２］フォーム情報展開部１４０は、画面フォーム定義が記述されたソースファイル１１１ａから画面フォーム定義を１行分読み込む。
［ステップＳ１１３］フォーム情報展開部１４０は、読み込んだ画面フォーム定義が定義の終了を示すコード（ＥＯＦ：End Of File）か否かを判断する。フォーム情報展開部１４０は、定義の終了を示すコードであれば、処理をステップＳ１１７に進める。またフォーム情報展開部１４０は、定義の終了を示すコードでなければ、処理をステップＳ１１４に進める。

［ステップＳ１１４］フォーム情報展開部１４０は、読み込んだ画面フォーム定義に示されるコメントが、プレフィックス付きのコントロール名か否かを判断する。例えばフォーム情報展開部１４０は、コメント内のコントロール名の先頭の文字列が、コントロール一覧１１２のプレフィックスに示される文字列のいずれかに該当する場合、該当コメントは、プレフィックス付きのコントロール名であると判断する。フォーム情報展開部１４０は、プレフィックス付きのコントロール名であれば、処理をステップＳ１１５に進める。またフォーム情報展開部１４０は、プレフィックス付きのコントロール名でなければ、処理をステップＳ１１２に進める。

［ステップＳ１１５］フォーム情報展開部１４０は、プレフィックス付きのコントロール名のコメント行に続けて記載されている、コントロールについての画面フォーム定義から、基礎情報を抽出する。

［ステップＳ１１６］フォーム情報展開部１４０は、抽出した基礎情報を画面項目定義書１１６に書き込む。その後、フォーム情報展開部１４０は処理をステップＳ１１２に進める。

［ステップＳ１１７］フォーム情報展開部１４０は、定義終了のコードを検出すると、生成した画面項目定義書１１６を、例えばメモリ１０２またはストレージ装置１０３に保存する。

図２１は、基礎情報の自動展開の一例を示す図である。例えばフォーム情報展開部１４０は、ソースファイル１１１ａの先頭の行から順番に読み込んでいきコメント「’ＢＴ＿Ｂｔｎ０１」に達したものとする。フォーム情報展開部１４０は、読み込んだコメントの先頭も文字列「ＢＴ＿」を、コントロール一覧１１２のプレフィックスの欄から検索する。フォーム情報展開部１４０は、コントロール一覧１１２に対応するプレフィックスが登録されていることから、コメント「’ＢＴ＿Ｂｔｎ０１」がプレフィックス付きのコントロール名であると判断する。そこでフォーム情報展開部１４０は、画面項目定義書１１６に「ＩｔｅｍＮａｍｅ」が「ＢＴ＿Ｂｔｎ０１」のレコードを追加する。

さらにフォーム情報展開部１４０は、プレフィックス付きのコントロール名のコメント「’ＢＴ＿Ｂｔｎ０１」以降に記載された画面フォームを定義する行を１行ずつ解析する。そしてフォーム情報展開部１４０は、各行に定義されいる項目についての値を、画面項目定義書１１６に設定する。その際、フォーム情報展開部１４０は、色に関する値は、カラーテーブル１１５に基づいて、ＣＳＳにおける色の値に変換する。

例えばフォーム情報展開部１４０は、「Me.BT_Btn01.BackColor=System.Drawing.Color.Silver」の行を解析し、背景色（ＢａｃｋＣｏｌｏｒ）に「Ｓｉｌｖｅｒ」を設定する行であることを認識する。そこでフォーム情報展開部１４０は、画面項目定義書１１６の「ＢＴ＿Ｂｔｎ０１」のレコードの背景色（ＢａｃｋＣｏｌｏｒ）の項目に「Ｓｉｌｖｅｒ」に対応する１６進数の値を設定する。図１４を参照すると「Ｓｉｌｖｅｒ」に対応する値は「＃Ｃ０Ｃ０Ｃ０」である。そのためフォーム情報展開部１４０は、背景色（ＢａｃｋＣｏｌｏｒ）の項目に「＃Ｃ０Ｃ０Ｃ０」を設定する。同様にフォーム情報展開部１４０は、フォント名（ＦｏｎｔＮａｍｅ）、フォントサイズ（ＦｏｎｔＳｉｚｅ）、前景色（ＦｏｒｅＣｏｌｏｒ）、説明文（Ｃａｐｔｉｏｎ）、説明文の表示位置（Ａｌｉｇｎｍｅｎｔ）などを該当レコードに設定する。

なお画面フォームの基礎情報は、テキストボックスやボタンの配置など、コントロールの表示上の体裁に関する情報である。開発者は、ソフトウェアのマイグレーション後にコントロールを正しく動作させるために、設計値設定部１５０を用いて、設計値を画面項目定義書１１７に設定する。例えば開発者は、設計値設定部１５０に対して、入力値のデータ型（date、time、numberなど）や表示桁数などを、設計値として入力する。設計値設定部１５０は、入力された設計値を、画面項目定義書１１７に設定する。

２つの画面項目定義書１１６，１１７が用意できると、ソースコード変換部１６０が、スケルトンファイル群１１３を用いて、変換前のソースファイル群１１１と同じ処理を行うことができるＷｅｂアプリ用のソースファイル群１１８を生成する。例えばソースコード変換部１６０は、コンバートテーブル１１４に基づいて、変換前のソースファイル内の各コードをＷｅｂアプリ用のコードに変換する。そしてソースコード変換部１６０は、変換後のコードをスケルトンファイルに挿入することで、変換後のソースファイルを生成する。

なお、変換元のソースファイルにおける画面フォームに関する情報は、すでに画面項目定義書１１６，１１７に登録されている。そこで、ソースコード変換部１６０は、画面フォームについてのソースファイルの生成の際には、２つの画面項目定義書１１６，１１７を利用してソースファイルを生成する。

図２２は、画面フォームについてのソースファイルの生成例を示す図である。例えばソースコード変換部１６０は、ＣＳＳ用のスケルトンファイル１１３ａを、コンバートテーブル１１４、画面項目定義書１１６，１１７を用いて自動編集し、ＣＳＳで記述されたソースファイル１１８ａを生成する。

次に、ソースファイル自動生成処理の手順について、フローチャートを参照して詳細に説明する。
図２３は、ソースファイル自動生成処理の手順の一例を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。

［ステップＳ１２１］ソースコード変換部１６０は、画面項目定義書１１６，１１７の整合性をチェックする。例えばソースコード変換部１６０は、コントロールの説明文に数値以外の文字が設定されているにもかかわらず、そのコントロールのデータ型が数値の場合、整合性のチェックでエラーと判定する。

［ステップＳ１２２］ソースコード変換部１６０は、整合性のチェックにおいてエラーがあった否かを判断する。ソースコード変換部１６０は、エラーがあった場合、処理をステップＳ１２３に進める。またソースコード変換部１６０は、エラーがなければ、処理をステップＳ１２４に進める。

［ステップＳ１２３］ソースコード変換部１６０は、整合性のチェックで検出されたエラーの内容を出力し、処理を終了する。
［ステップＳ１２４］ソースコード変換部１６０は、未処理のスケルトンファイルを一つ読み込む。

［ステップＳ１２５］ソースコード変換部１６０は、読み込んだソースファイルに記述されたコードを上から順に１行ずつ選択する。
［ステップＳ１２６］ソースコード変換部１６０は、選択した行がスケルトンファイルの終了を示す文字列（星印に囲まれた「ＥＮＤ」の文字列）か否かを判断する。ソースコード変換部１６０は、終了を示す文字列の場合、処理をステップＳ１３１に進める。またソースコード変換部１６０は、終了を示す文字列でなければ、処理をステップＳ１２７に進める。

［ステップＳ１２７］ソースコード変換部１６０は、選択した行に、置換対象位置を示す所定記号で囲まれた文字列があるか否かを判断する。所定記号は、例えば二重鉤括弧、隅付き括弧などである。ソースコード変換部１６０は、所定記号で囲まれた文字列がある場合、処理をステップＳ１２８に進める。またソースコード変換部１６０は、所定記号で囲まれた文字列がない場合、処理をステップＳ１２９に進める。

［ステップＳ１２８］ソースコード変換部１６０は、項目定義ソースコード生成処理を行う。この処理の詳細は後述する（図２４参照）。その後、ソースコード変換部１６０は、処理をステップＳ１２５に進める。

［ステップＳ１２９］ソースコード変換部１６０は、所定記号で囲まれた文字列がない場合、選択した行が、変換後のソースファイルへの展開対象のコードか否かを判断する。例えば「＄ＣＳＳ＿０１」のような、ソースファイル自動生成処理の終了を示す制御コードは、ソースファイルの展開対象外となる。ソースコード変換部１６０は、展開対象コードであれば、処理をステップＳ１３０に進める。またソースコード変換部１６０は、展開対象コードでなければ、処理をステップＳ１２５に進める。

［ステップＳ１３０］ソースコード変換部１６０は、選択した行に示されるコードを、変換後のソースファイルに書き込む。その後、ソースコード変換部１６０は、処理をステップＳ１２５に進める。

［ステップＳ１３１］ソースコード変換部１６０は、未処理のスケルトンファイルがあるか否かを判断する。ソースコード変換部１６０は、未処理のスケルトンファイルがあれば、処理をステップＳ１２４に進める。またソースコード変換部１６０は、未処理のスケルトンファイルがなければ、処理をステップＳ１３２に進める。

［ステップＳ１３２］ソースコード変換部１６０は、スケルトンファイルに基づいて生成されたソースファイルを、記憶部１１０に保存する。その後、ソースコード変換部１６０はソースファイル自動生成処理を終了する。

次に、項目定義ソースコード生成処理の手順の詳細について説明する。
図２４は、項目定義ソースコード生成処理の手順の詳細を示すフローチャートである。以下、図２４に示す処理をステップ番号に沿って説明する。

［ステップＳ１４１］ソースコード変換部１６０は、コンバートテーブル１１４を読み込む。
［ステップＳ１４２］ソースコード変換部１６０は、コンバートテーブル１１４から、所定記号で囲まれた文字列に一致する処理名を検索する。

［ステップＳ１４３］ソースコード変換部１６０は、検索で一致した処理名に続くソースコードを、１行ずつ選択する。
［ステップＳ１４４］ソースコード変換部１６０は、選択した行が該当処理の記述の終了を示すコード「＄（処理名）」か否かを判断する。ソースコード変換部１６０は、該当処理の記述の終了を示すコードであれば、項目定義ソースコード生成処理を終了する。またソースコード変換部１６０は、該当処理の記述の終了を示すコードでなければ、処理をステップＳ１４５に進める。

［ステップＳ１４５］ソースコード変換部１６０は、選択した行のコードが、検索で一致した処理名の処理全体の編集条件、および選択した行の条件を満たすか否かを判断する。ソースコード変換部１６０は、編集条件および行の条件が共に満たされていれば、処理をステップＳ１４６に進める。またソースコード変換部１６０は、編集条件および行の条件のいずれかが満たされていなければ、処理をステップＳ１４３に進める。

［ステップＳ１４６］ソースコード変換部１６０は、選択した行に、星印で囲まれた変数名があるか否かを判断する。ソースコード変換部１６０は、該当変数がある場合、処理をステップＳ１４７に進める。またソースコード変換部１６０は、該当変数がない場合、処理をステップＳ１４９に進める。

［ステップＳ１４７］ソースコード変換部１６０は、検索で一致した処理名に続けて記載されている取得先を参照し、取得先として指定されている画面項目定義書を読み込む。例えばソースコード変換部１６０は、取得先が「ＦｒｍＩｎｆｏ」であれば、基礎情報が設定された画面項目定義書１１６を読み込む。またソースコード変換部１６０は、取得先が「ＰｓｉＩｎｆｏ」であれば、設計値が設定された画面項目定義書１１７を読み込む。

［ステップＳ１４８］ソースコード変換部１６０は、読み込んだ画面項目定義書から、検索で一致した処理名に対応するコントロール名のレコード内の、星印で囲まれた変数名に対応する項目の値を、該当変数名の変数値として取得する。そしてソースコード変換部１６０は、星印で囲まれた変数名を取得した変数値で置き換える。

［ステップＳ１４９］ソースコード変換部１６０は、選択した行のコードをスケルトンファイルに書き込む。その後、ソースコード変換部１６０は処理をステップＳ１４３に進める。

なおソースコード変換部１６０は、図１０のスケルトンファイル１１３ａの例に示すような二重鉤括弧に囲まれた文字列がある場合、該当文字列に対応付けられたシステム内の設定値を取得し、取得した文字列に変換する。例えばソースコード変換部１６０は、二重鉤括弧で囲まれた『ツールバージョン』を、ソースファイル変換処理機能を実現するためのソフトウェアモジュール群のバージョン番号に変換する。

このようにして、スケルトンファイルにＷｅｂアプリ用の言語で記述されたコードを書き込んでいくことで、変換後のソースファイルを生成することができる。以下、図２５～図２８を参照して、画面フォームを定義するソースファイル１１８ａの生成例について説明する。

図２５は、スケルトンファイルへのソースコードの挿入位置とコンバートテーブルの処理名との対応関係を示す図である。例えばスケルトンファイル１１３ａには、隅付き括弧に囲まれた「項目定義２０」という文字列がある。ソースコード変換部１６０は、スケルトンファイル１１３ａから文字列「項目定義２０」を抽出し、該当文字列を検索キーワードとしてコンバートテーブル１１４の処理名を検索する。そしてソースコード変換部１６０は、処理名「項目定義２０」以降に記載されているソースコード定義情報１１４ａ内のコードを、処理名「項目定義２０」に対応する取得先「ＦｒｍＩｎｆｏ」で指定された画面項目定義書１１６に基づいて自動編集する。

またスケルトンファイル１１３ａには、隅付き括弧に囲まれた「項目定義６」という文字列がある。ソースコード変換部１６０は、スケルトンファイル１１３ａから文字列「項目定義６」を抽出し、該当文字列を検索キーワードとしてコンバートテーブル１１４の処理名を検索する。そしてソースコード変換部１６０は、処理名「項目定義６」以降に記載されているソースコード定義情報１１４ｂ内のコードを、処理名「項目定義６」に対応する取得先「ＰｓｉＩｎｆｏ」で指定された画面項目定義書１１７に基づいて自動編集する。

図２６は、基礎情報が設定された画面項目定義書に基づくソースコードの自動編集例を示す図である。例えば処理名「ＢＴ＿Ｂｔｎ０１」のソースコード定義情報１１４ａの１行目には、星印に囲まれた文字列「ＩｔｅｍＮａｍｅ」がある。ソースコード変換部１６０は、該当文字列と星印とを、画面項目定義書１１６におけるＩｔｅｍＮａｍｅ「ＢＴ＿Ｂｔｎ０１」のレコードにおける項目「ＩｔｅｍＮａｍｅ」の値「ＢＴ＿Ｂｔｎ０１」に変換する。

ソースコード定義情報１１４ａの５行目には、星印に囲まれた文字列「ＢａｃｋＣｏｌｏｒＮｏＤｅｆａｕｌｔ」がある。ソースコード変換部１６０は、該当文字列と星印とを、画面項目定義書１１６におけるＩｔｅｍＮａｍｅ「ＢＴ＿Ｂｔｎ０１」のレコードにおける項目「ＢａｃｋＣｏｌｏｒ」の値「＃Ｃ０Ｃ０Ｃ０」に変換する。

ソースコード定義情報１１４ａの６行目には、星印に囲まれた文字列「Ａｌｉｇｎｍｅｎｔ」がある。ソースコード変換部１６０は、該当文字列と星印とを、画面項目定義書１１６におけるＩｔｅｍＮａｍｅ「ＢＴ＿Ｂｔｎ０１」のレコードにおける項目「Ａｌｉｇｎｍｅｎｔ」の値「ｃｅｎｔｅｒ」に変換する。

ソースコード定義情報１１４ａの１０行目には、星印に囲まれた文字列「ｚＩｎｄｅｘ」がある。ソースコード変換部１６０は、該当文字列と星印とを、画面項目定義書１１６におけるＩｔｅｍＮａｍｅ「ＢＴ＿Ｂｔｎ０１」のレコードにおける項目「ｚＩｎｄｅｘ」の値「８８７」に変換する。

ソースコード定義情報１１４ａのその他の行は、条件を満たしていないものとする。その結果、ソースコード変換部１６０は、ソースコード定義情報１１４ａに基づいて、変数名を変数値に置換した変換後コード５１を生成することができる。

図２７は、設計値が設定された画面項目定義書に基づくソースコードの自動編集例を示す図である。ソースコード変換部１６０は、処理名「項目定義６」に対応するソースコード定義情報１１４ｂにおける星印で囲まれた文字列を、設計値が設定された画面項目定義書１１７内の対応する値に変換し、変換後コード５２を生成する。

ソースコード変換部１６０は、図２６、図２７に示した変換後コード５１，５２をスケルトンファイルに書き込むことで、変換後のソースファイルを生成する。
図２８は、スケルトンファイルへのソースコードの挿入例を示す図である。ソースコード変換部１６０は、処理名「項目定義２０」のソースコード定義情報１１４ａを用いて生成した変換後コード５１を、スケルトンファイル１１３ａの隅付き括弧に囲まれた「項目定義２０」の記載箇所に挿入する。またソースコード変換部１６０は、処理名「項目定義６」のソースコード定義情報１１４ｂを用いて生成した変換後コード５２を、スケルトンファイル１１３ａの隅付き括弧に囲まれた「項目定義６」の記載箇所に挿入する。このように、ソースコード変換部１６０は、スケルトンファイル１１３ａの隅付き括弧に囲まれた文字列をソースコードに置き換えていくことで、ソースファイル１１８ａを生成する。

図２５～図２８にはスケルトンファイル１１３ａを用いたソースファイル１１８ａの生成例を示したが、同様の処理により、他のスケルトンファイル１１３ｂ，１１３ｃからもソースファイル１１８ｂ，１１８ｃを生成することができる。

生成されたソースファイル群１１８に基づいて、デプロイ部１７０が、Ｗｅｂアプリをサーバ３２にデプロイする。
図２９は、Ｗｅｂアプリの実装例を示す図である。例えばソースファイル群１１８に基づいてサーバ３２でデプロイされたＷｅｂアプリ６０の処理機能には、業務処理と、サーバ３２内のＤＢ３２ａにアクセスするＤＢアクセス処理とが含まれる。例えばサーバ３２は、Ｗｅｂアプリ６０に含まれる業務処理用のプログラムに従って、業務処理を実行する。業務の過程でＤＢ３２ａ内のデータを利用する場合、サーバ３２はＷｅｂアプリ６０に含まれるＤＢアクセス処理のプログラムに従ってＤＢ３２ａにアクセスする。

なお端末装置１００は、Ｗｅｂアプリ６０をサーバ３２に実装する際に、表示データとＤＢ３２ａ内のデータとの紐づけを行うことができる。例えば端末装置１００は、接続するＤＢ３２ａを指定することにより、ファサードクラス（Ｆａｃａｄｅ Ｃｌａｓｓ）のスケルトンファイルを自動生成する。そして端末装置１００は、生成したスケルトンファイルにＤＢ３２ａへのアクセスに使用する情報を設定する。例えば開発者は、端末装置１００を用いて、表示データとＤＢ３２ａ内のデータとの紐づけ用のスケルトンファイルを編集し、サーバ通信に必要なソースコードを挿入する。端末装置１００は、このようにして生成されたソースコードをデプロイすることで、表示データとＤＢ３２ａ内のデータとを関連付けたＷｅｂアプリ６０が、サーバ３２で動作する。

例えば端末装置１００によりサーバ３２にアクセスしてＷｅｂアプリ６０を使用する場合、端末装置１００の画面には、移行元のサーバ３１で業務処理が提供されていたときと同様の操作画面が表示される。

図３０は、Ｗｅｂアプリ操作画面の一例を示す図である。Ｗｅｂアプリ操作画面７０には、多数のボタン７１が表示されている。またＷｅｂアプリ操作画面７０内にフレーム７２が表示され、そのフレーム７２内にタブ７３で切替可能なウィンドウ７４が表示されている。ウィンドウ７４内には複数のテキストボックスが表示されている。

第２の実施の形態に示したマイグレーション処理でソフトウェアのマイグレーションを行うことで、図３０に示したＷｅｂアプリ操作画面７０のような複雑な構造の操作画面であっても、移行前と同じ操作画面をＷｅｂアプリ６０によって再現することができる。

すなわち、クライアントサーバシステムをＷｅｂシステムに置き換える場合、既存資産をそのまま利用するのは困難である。また新規開発としてゼロからＷｅｂアプリをプログラミングするのは、非常に手間と時間がかかる。第２の実施の形態に示す方法でソフトウェアのマイグレーションを行えば、既存資産であるソフトウェアのフォームのデザインファイルを有効に利用して、Ｗｅｂアプリ用のソースファイルを自動生成することができる。

また端末装置１００は、スケルトンファイルとコンバートテーブルの組み合わせにより、Ｗｅｂアプリ用のソースファイルを生成しているため、開発者の開発スキルの違いによる品質のバラツキが発生せず、画面開発品質の均一化が可能となる。

端末装置１００がスケルトンファイルとコンバートテーブルを用いてソースファイルを自動生成することは、ソースファイルの信頼性の向上にもつながる。生成されるソースファイルの信頼性が高いことで、テスト期間の短縮が可能となる。

〔その他の実施の形態〕
第２の実施の形態では、ＨＴＭＬ、ＣＳＳ、およびＪａｖａＳｃｒｉｐｔ（登録商標）により、Ｗｅｂアプリのソースファイルを記述しているが、他の言語への適用も可能である。

また第２の実施の形態に示した端末装置１００の機能は、既存のソフトウェアのマイグレーションではなく、Ｗｅｂアプリの開発経験が乏しい開発者によるソフトウェアの新規開発においても有効に利用できる。例えばクライアントサーバシステム用のソフトウェアの統合開発環境を用いてソースファイルを新規に記述し、端末装置１００を用いてそのソースファイルをＷｅｂアプリ用のソースファイルに変換することもできる。これにより、開発者は、使い慣れたある言語用の統合開発環境を用いて、他の言語のソースファイルを容易に作成することができる。

Ｗｅｂアプリの新規開発では、例えば基礎情報の画面項目定義書１１６を作っておけば、実際の画面のサンプルを確認することができる。その結果、開発の早い段階で画面フォームの確認が可能であり、手戻りの少ない要件定義が可能となる。

また端末装置１００は、画面フォームをＨＴＭＬとは別の言語（ＣＳＳ）で記述していることで、レスポンシブＷｅｂデザインへの対応も容易である。レスポンシブＷｅｂデザインとは、ユーザが閲覧する装置の画面サイズに応じて、画面のフォームを最適化して表示させる技術である。例えば端末装置１００は、パーソナルコンピュータでアクセスされたとき用のＣＳＳ、タブレットでアクセスされたとき用のＣＳＳ、スマートフォンでアクセスされたとき用のＣＳＳを含むソースファイルを生成する。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ 第１ソースファイル
２ 第２ソースファイル
３ 変換用コード
１０ 情報処理装置
１１ 記憶部
１２ 処理部

Claims (6)

1. 画面フォームを構成する要素の表示態様を第１プログラミング言語で規定する第１コードを含む第１ソースファイルに基づいて、前記第１コードから、前記要素の表示態様に関する項目の項目値を抽出し、
   前記要素の表示態様を第２プログラミング言語で規定するコードの記述のうちの前記項目の項目値の設定領域に、前記項目に対応する変数名が設定された変換用コードに基づいて、前記変換用コードの前記変数名を前記第１ソースファイルから抽出された前記項目値に変換することで、前記要素の表示態様を前記第２プログラミング言語で規定した第２コードを生成し、
   生成した前記第２コードを第２ソースファイルに対して書き込む、
   処理をコンピュータに実行させるソースファイル生成プログラム。
2. 前記変換用コードには、前記変換用コードの適用条件が定義されており、
   前記適用条件を満たす場合に、前記変数名の前記項目値への変換、および前記第２コードの前記第２ソースファイルへの書き込みを実行する、
   請求項１記載のソースファイル生成プログラム。
3. 前記コンピュータに、さらに、
   抽出した前記項目値を、前記第１プログラミング言語の定義に従った表記形式から前記第２プログラミング言語の定義に従った表記形式に変換する、
   処理を実行させる請求項１または２記載のソースファイル生成プログラム。
4. 前記項目値の抽出では、画面フォームを構成する前記要素に対する命名規約に従った要素名を含む行を、前記第１ソースファイルから検索し、前記要素名を含む行に続けて記述されている、表示態様を規定するコードを、前記要素の表示態様を規定する前記第１コードとして特定する、
   請求項１ないし３のいずれかに記載のソースファイル生成プログラム。
5. コンピュータが、
   画面フォームを構成する要素の表示態様を第１プログラミング言語で規定する第１コードを含む第１ソースファイルに基づいて、前記第１コードから、前記要素の表示態様に関する項目の項目値を抽出し、
   前記要素の表示態様を第２プログラミング言語で規定するコードの記述のうちの前記項目の項目値の設定領域に、前記項目に対応する変数名が設定された変換用コードに基づいて、前記変換用コードの前記変数名を前記第１ソースファイルから抽出された前記項目値に変換することで、前記要素の表示態様を前記第２プログラミング言語で規定した第２コードを生成し、
   生成した前記第２コードを第２ソースファイルに対して書き込む、
   ソースファイル生成方法。
6. 画面フォームを構成する要素の表示態様を第１プログラミング言語で規定する第１コードを含む第１ソースファイルと、前記要素の表示態様を第２プログラミング言語で規定するコードの記述のうちの、前記要素の表示態様に関する項目の項目値設定領域に、前記項目に対応する変数名が設定された変換用コードとを記憶する記憶部と、
   前記第１ソースファイルに基づいて、前記第１コードから、前記要素の表示態様に関する前記項目の項目値を抽出し、前記変換用コードに基づいて、前記変換用コードの前記変数名を前記第１ソースファイルから抽出された前記項目値に変換することで、前記要素の表示態様を前記第２プログラミング言語で規定した第２コードを生成し、生成した前記第２コードを第２ソースファイルに対して書き込む処理部と、
   を有する情報処理装置。

Images