JP7129578B1 - ソフトウェアのソースコード生成を支援するための装置、方法及びそのためのプログラム - Google Patents

Abstract

【課題】ソフトウェアのソースコード生成を支援するための方法であって、当該ソースコードのプログラミング工程の少なくとも一部を自動化する。【解決手段】装置１００は、企業端末１１０に、テーブル定義入力画面表示情報を送信し（Ｓ３０１）、入力されたテーブル定義は装置１００に対して送信される（Ｓ３０２乃至Ｓ３０５）。次いで、装置１００は、企業端末１１０に、各テーブルについて１又は複数のAPIを定義するためのAPI定義入力画面表示情報を送信し（Ｓ３０６）、入力されたAPI定義は装置１００に対して送信される（Ｓ３０７）。装置１００は、ソースコード生成の要求を受信したことに応じて（Ｓ３０８）、予め作成された１又は複数のテンプレートを取得して、当該テーブル定義及びAPI定義に従ったソースコードを生成する（Ｓ３０９）。生成されたソースコードは、装置１００から企業端末１１０に送信される（Ｓ３１０）。【選択図】図３

Description

本発明は、ソフトウェアのソースコード生成を支援するための装置、方法及びそのためのプログラムに関する。

ソフトウェア開発は、要件定義、設計、プログラミング、テスト等の工程に分けられる。開発したソフトウェアを使用する事業会社がソフトウェアエンジニアを社内に抱えることももちろんある一方、社外の開発会社に開発工程の全部又は一部が委託されることも少なくない。たとえば、要件定義及び設計を上流工程として自社で担い、プログラミング及びテストを下流工程として社外に委託するような例が挙げられる。

プログラミングが社外に委託される場合、プロジェクトの規模、委託先の稼働状況等に応じて、さらに再委託されることがある。また、比較的に安価な人件費で委託可能な海外企業に委託されることもあり、オフショア開発と呼ばれる。

いずれのかたちにしても、プログラミングの外部委託は、自社が有するソフトウェア開発のリソースを割くコストよりも外部委託に伴い発生するコストの方が小さい場合に広く採用されているところ、ソフトウェア開発のコストをさらに下げることのできる手法があれば、より望ましい。

本発明は、このような点に鑑みてなされたものであり、その目的は、ソフトウェアのソースコード生成を支援するための装置、方法及びそのためのプログラムであって、当該ソースコードのプログラミング工程の少なくとも一部を自動化することにある。

このような目的を達成するために、本発明の第１の態様は、ソフトウェアのソースコード生成を支援するための方法であって、装置が、端末から、複数のテーブルについてのテーブル定義及びAPI定義を受信するステップと、前記装置が、前記端末から、ソースコード生成の要求を受信するステップと、前記装置が、前記要求の受信に応じて、予め作成されたソースコードの１又は複数のテンプレートを取得して、前記テーブル定義及び前記API定義に従ったソースコードを前記１又は複数のテンプレートを用いて生成するステップとを含む。

また、本発明の第２の態様は、第１の態様の方法であって、前記テーブル定義は、前記ソフトウェアのユーザーの基本情報に関するユーザーテーブルの各レコードに含まれるユーザー識別子により識別されるユーザーに対してユーザー認証を行うことの指定を含む。

また、本発明の第３の態様は、第２の態様の方法であって、前記１又は複数のテンプレートは、ユーザー認証のための第１のテンプレートを含む。

また、本発明の第４の態様は、第２又は第３の態様の方法であって、前記テーブル定義は、前記ユーザーテーブルが有する複数のカラムのうちの前記ユーザー認証に用いるカラムの特定を含む。

また、本発明の第５の態様は、第４の態様の方法であって、前記特定されたカラムの値は、電話番号である。

また、本発明の第６の態様は、第１から第５のいずれかの態様の方法であって、前記API定義は、各テーブルについて、レコードの表示、生成、更新及び削除のうちの少なくとも一部を実行するための１又は複数のAPIの作成の指定を含む。

また、本発明の第７の態様は、第６の態様の方法であって、前記API定義は、いずれかのAPIについて、前記ユーザー認証に成功していることを実行の認可の条件とする指定を含む。

また、本発明の第８の態様は、第７の態様の方法であって、前記１又は複数のテンプレートは、前記認可のための第２のテンプレートを含む。

また、本発明の第９の態様は、第１から第８のいずれかの態様の方法であって、前記装置が受信した前記テーブル定義の第２の部分は、前記端末から受信した前記テーブル定義の第１の部分に応じて、前記装置が生成して、前記端末に送信したものである。

また、本発明の第１０の態様は、第９の態様の方法であって、前記第１の部分は、前記ソフトウェアの利用料金の支払いを可能とする指定を含み、前記第２の部分は、前記利用料金の支払いに関するペイメントテーブルが有する複数のカラムの定義、及び、前記ユーザーテーブルが有する前記ペイメントテーブルとのリレーションの定義を含む。

また、本発明の第１１の態様は、第９の態様の方法であって、前記第１の部分は、前記ユーザーテーブル以外の他のテーブルが有する前記ユーザーテーブルとのリレーションの定義を含み、前記第２の部分は、前記他のテーブルが有する前記ユーザーテーブルに関連づけられたカラムの定義を含む。

また、本発明の第１２の態様は、第１から第１１のいずれかの態様の方法であって、前記装置は、インターネット上のサーバである。

また、本発明の第１３の態様は、装置に、ソフトウェアのソースコード生成を支援するための方法を実行させるためのプログラムであって、前記方法は、前記装置が、端末から、複数のテーブルについてのテーブル定義及びAPI定義を受信するステップと、前記装置が、前記端末から、ソースコード生成の要求を受信するステップと、前記装置が、前記要求の受信に応じて、予め作成されたソースコードの１又は複数のテンプレートを取得して、前記テーブル定義及び前記API定義に従ったソースコードを前記１又は複数のテンプレートを用いて生成するステップとを含む。

また、本発明の第１４の態様は、ソフトウェアのソースコード生成を支援するための装置であって、端末から、複数のテーブルについてのテーブル定義及びAPI定義並びにソースコード生成の要求を受信し、前記要求の受信に応じて、予め作成されたソースコードの１又は複数のテンプレートを取得して、前記テーブル定義及び前記API定義に従ったソースコードを前記１又は複数のテンプレートを用いて生成する。

本発明の一態様によれば、複数のテーブルについてのテーブル定義及びAPI定義を受信して、予め作成された１又は複数のテンプレートを取得し、当該テーブル定義及び当該API定義に従ったソースコードを当該１又は複数のテンプレートを用いて生成することによって、ソフトウェアのソースコード生成を支援することが可能となる。

本発明の一実施形態にかかるソフトウェアのソースコード生成を支援するための装置を示す図である。 本発明の一実施形態にかかるデータベース設計の一例を示す図である。 本発明の一実施形態にかかるソフトウェアのソースコード生成を支援するための方法を示す図である。 本発明の一実施形態にかかるテーブル定義入力画面の一部を示す図である。 本発明の一実施形態にかかるテーブル定義入力画面の一部を示す図である。 本発明の一実施形態にかかるライクテーブルのリレーション定義入力領域の一例を示す図である。 本発明の一実施形態にかかるAPI定義入力画面の一部を示す図である。 本発明の一実施形態にかかるソースコード生成の流れを示す図である。

以下、本発明の実施形態を詳細に説明する。

図１に、本発明の一実施形態にかかる装置を示す。装置１００は、装置１００により提供されるサービスのユーザーである企業が用いる企業端末１１０とインターネット等のIPネットワークを介して通信して、データベース設計に関する入力を受信し、当該入力に基づいて、ソフトウェアのためのソースコードを生成する。主に、装置１００はインターネット上のサーバであることを考えるが、社内ネットワーク上のサーバとし、当該社内ネットワーク上の端末からアクセスするものとすることも考えられる。

装置１００は、通信インターフェースなどの通信部１０１と、プロセッサ、ＣＰＵ等の処理部１０２と、メモリ、ハードディスク等の記憶装置又は記憶媒体を含む記憶部１０３とを備え、各処理を行うためのプログラムを実行することによって構成することができる。装置１００は、１又は複数の装置、コンピュータないしサーバを含むことがある。また、当該プログラムは、１又は複数のプログラムを含むことがあり、また、コンピュータ読み取り可能な記憶媒体に記録して非一過性のプログラムプロダクトとすることができる。当該プログラムは、記憶部１０３又は装置１００からIPネットワークを介してアクセス可能な記憶装置１０４に記憶しておき、処理部１０２において実行することができる。以下で記憶部１０３に記憶されるものとして記述されるデータは記憶装置１０４に記憶してもよく、またその逆も同様である。

図２に、データベース設計の一例を示す。本明細書では、図２に示すマッチングサービスのためのデータベース設計を例にソースコードの少なくとも一部を自動的に生成することを説明するが、図２に示すようなリレーショナルデータベースのほかに、階層型データベース、ネットワーク型データベースなどのさまざまなデータベース設計に対して本発明は適用可能である。

図２に示すデータベース設計は、好みの人と出会うためのマッチングサービスに必要な複数のテーブルの少なくとも一部を含み、各テーブルは、少なくとも１つの他のテーブルと関連づけられている。本明細書では「テーブル」という用語を用いるが、これは、データベースに含まれる、１又は複数のカラム及び１又は複数のレコードを有するデータ単位であって、少なくとも１つの他のデータ単位と関連づけられるデータ単位を包含する。

具体的には、図２には、マッチングサービスの各ユーザーの基本情報に関するユーザーテーブル「Users」、各ユーザーが他のどのユーザーが好みで、他のどのユーザーから好まれているかに関するライクテーブル「Likes」、ユーザー間で互いの好みが合致した一組のユーザーに関するマッチテーブル「Matches」、及び、好みが合致した一組のユーザー間のメッセージに関するメッセージテーブル「Messages」が含まれる。

また、図２には、各ユーザーの支払履歴に関するペイメントテーブル「Payments」が含まれ、必要に応じてさらに、各ユーザーの加入状況に関するサブスクリプションテーブル「Subscriptions」及び各プランに関するプランテーブル「Plans」を含んでもよい。

図３に、本発明の一実施形態にかかるソフトウェアのソースコード生成を支援するための方法を示す。まず、装置１００は、企業端末１１０に、テーブル定義入力画面表示情報を送信する（Ｓ３０１）。企業端末１１０の表示画面に、当該テーブル定義入力画面表示情報に基づくテーブル定義入力画面が表示され、企業端末１１０を用いる入力者による入力が行われる。

入力者による入力は、テーブル定義入力画面表示情報を、たとえばＨＴＭＬ形式のファイルとして送信して、企業端末１１０の表示画面にウェブブラウザ上で表示される入力画面から行ったり、企業端末１１０にインストールされたアプリケーション（以下「アプリ」とも呼ぶ。）を動作させ、当該アプリケーション上で表示される入力画面から行ったりすることができる。なお、「テーブル定義入力画面」とは、ウェブブラウザ上で表示される場合にはウェブページ、モーダルウィンドウ、ポップアップウィンドウ等のさまざまな形式を採用することができ、アプリ上で表示される場合にはアプリの一画面とすることができる。いずれにおいても、テーブル定義を入力するための入力欄を有する領域を含む画面であれば、テーブル定義入力画面に該当する。

図４Ａに、本発明の一実施形態にかかるテーブル定義入力画面の一部を示す。テーブル定義入力画面４００は、テーブル追加ボタン４０１を有し、これをクリック又はタップにより選択することで、テーブルを追加することができる。各テーブルについて、テーブル定義入力画面４００は、テーブル名入力領域４１０、リレーション定義入力領域４２０及びカラム定義入力領域４３０を有し、さらに追加機能指定領域４４０を有することができる。

図４Ａは、マッチングサービスのユーザーの基本情報に関するユーザーテーブル「Users」のための入力を行う例であるが、ユーザーテーブル「Users」に限らず、リレーション定義入力領域４２０において、表示されているテーブルと他のテーブルとの間のリレーション（relation）を指定することができる。たとえば、ライクテーブル「Likes」を追加して、ライクテーブル「Likes」に対して、ユーザーテーブル「Users」との間のリレーションを指定することが考えられる。

図４Ｂに、本発明の一実施形態にかかるテーブル定義入力画面の一部を示す。これは、図４Ａに示したテーブル定義入力画面４００を下にスクロールして、カラム定義領域４３０を表示した状態である。カラム定義入力領域４３０は、カラム追加ボタン４３１を有し、これをクリック又はタップにより選択することで、テーブルを追加することができる。企業端末１１０を用いる入力者は、図２に示したデータベース設計に従って、各テーブルに対して、必要なカラムを定義していけばよい。

図４Ａに戻ると、この例では、追加機能指定領域４４０において、ユーザーテーブル「Users」の各レコードに含まれるユーザー識別子により識別されるユーザーに対してユーザー認証（user authentication）を行うことを指定した場合、後述するソースコード生成時に、ユーザー認証を行うためのテンプレートを用いて、ユーザー認証のためのソースコードが生成されることとなる。ユーザー認証が行われる場合には、ユーザーテーブル「Users」のカラム定義において、複数のカラムのうちのユーザー認証に用いるカラムの特定をテーブル定義に含んでもよい。図４Ｂでは、電話番号を値として保持することになるカラムの型が認証用のキーを表す「auth_key」となっている。各カラムは、名称及び型を含み、オプション及びデフォルト値の少なくとも一方をさらに含んでもよい。支払い（payment）を許可することを指定した場合については、追って説明する。

この例では、ユーザーテーブル「Users」のためのテーブル定義入力画面４００に追加機能指定領域４４０を含んでいるものの、他のテーブルのためのテーブル定義入力画面４００に含んでもよい。たとえば、病院向けのソフトウェアである場合、医師ユーザー及び患者ユーザーが使用し、共にユーザー認証を行う必要があれば、例として、各医師の基本情報に関するドクターテーブル「Doctors」及び各患者の基本情報に関するペイシェントテーブル「Patients」を追加し、これらのテーブルに対してそれぞれ、ユーザー認証を行う指定がなされることになる。本明細書では「ユーザー」という用語を用いるが、自然人に限らず、法人も含み、たとえば、ユーザー企業を包含するものとして用いる。

企業端末１１０を用いる入力者による入力されたテーブル定義は、定期的又は断続的に装置１００に対して送信される（Ｓ３０２）。そして、装置１００では、受信したテーブル定義を記憶部１０３に記憶し、当該テーブル定義（「第１の部分」に相当。）が所定の内容を含む場合に、当該所定の内容に応じて変更（「第２の部分」に相当。）を加えた変更テーブル定義を含む新たなテーブル定義入力画面表示情報を生成し（Ｓ３０３）、企業端末１１０に送信する（Ｓ３０４）。

一例として、図５に示すように、企業端末１１０にて、ライクテーブル「Likes」に対して、ユーザーテーブル「Users」との間の第１のリレーション及び第２のリレーションを指定することができる。このようなリレーション定義が入力されたことに応じて、装置１００が、ライクテーブル「Likes」に対して、第１のリレーション及び第２のリレーションによってユーザーテーブル「Users」に関連づけられた第１及び第２のカラムの定義をテーブル定義に加えることができる。

図４Ａ及び図５に示すリレーション定義入力領域４２０には、リレーションの種類として、「has many」、「has one」、「belongs to」及び「has many through」がある。本実施形態にかかるデータベースにおいて、一方のテーブルの各レコードを識別するidが他方のテーブルにカラムとして格納される場合に、前者を親、後者を子と呼ぶことがある。リレーション「has many」は、親のテーブルのレコードからみて他のテーブルの複数のレコードとの間に関連づけがなされ得て、リレーション「has one」は、親のテーブルのレコードからみて他のテーブルの単一のレコードとの間に関連づけがなされ得ることを意味する。リレーション「belongs to」は、子のテーブルのレコードからみて他のテーブルのレコードと１又は複数の関連づけがなされ得ることを意味し、図５では、ライクテーブル「Likes」の１つのレコードに対して、ユーザーテーブル「Users」の各レコードを識別するidを「liking_user_id」として格納させる第１のリレーション、及び、当該idを「liked_user_id」として格納させる第２のリレーションが指定されている。リレーション「has many through」は、第１のテーブルのレコードからみて第３のテーブルの複数のレコードと、第１のテーブルの子であり、第３のテーブルの親である第２のテーブルを介して、関連づけがなされ得ることを意味する。

また、別の例として、ユーザーテーブル「Users」に対して、利用料金の支払いを可能とする指定がなされたことに応じて、装置１００が、利用料金の支払履歴を関するペイメントテーブル「Payments」が有する複数のカラムの定義をテーブル定義に加えることができる。装置１００は、さらに、利用料金の支払いを可能とする指定がなされたことに応じて、ユーザーテーブル「Users」のリレーション定義に、ペイメントテーブル「Payments」とのリレーション「has many」を加えることができ、ペイメントテーブル「Payments」のリレーション定義に、ユーザーテーブル「Users」とのリレーション「belongs to」を加えることができる。

このように、装置１００において、入力者が入力したテーブル定義に応じて、適宜自動的に必要な定義が追加され、入力者は、その他の個別に必要な入力を行う（Ｓ３０５）。ここまでの処理で、データベース設計に対応するテーブル定義に関するデータが記憶部１０３に記憶される。

次いで、装置１００は、企業端末１１０に、各テーブルについて、レコードの操作を実行するための１又は複数のAPIを定義するためのAPI定義入力画面表示情報を送信する（Ｓ３０６）。企業端末１１０の表示画面に、当該API定義入力画面表示情報に基づくAPI定義入力画面が表示され、企業端末１１０を用いる入力者による入力が行われる。API定義入力画面表示情報の実装には、テーブル定義入力画面表示情報と同様の手法を採用すればよい。

図６に、本発明の一実施形態にかかるAPI定義入力画面の一部を示す。API定義入力画面６００では、テーブル定義に含まれる複数のテーブルのうちの少なくとも一部のテーブルについて、レコードの操作を実行するための１又は複数のAPIの作成を指定することができる。図６では、ライクテーブル「Likes」について、レコードの一覧表示（list）、詳細表示（detail）、生成（create）、更新（update）及び削除（delete）のうちの少なくとも一部を実行するための１又は複数のAPIの作成をONにすることができる。それぞれの操作に対応する第１のAPI定義入力領域６１１から第５のAPI定義入力領域６１５が与えられている。

レコードの生成に関する第３のAPI定義入力領域６１３は、APIの作成を指定するための第１の入力欄６１３－１がONにされており、さらに、当該APIについて、ユーザー認証に成功していることを当該APIの実行の認可（authorization）の条件として指定するための第２の入力欄６１３－２、及び、当該APIの実行対象のレコードを当該APIを実行するユーザー自身に関連するレコードに限定した認可を指定するための第３の入力欄６１３－３がONにされている。また、APIを呼び出すときに入力すべきパラメータを指定するための第４の入力欄６１３－４にライクテーブル「Likes」のカラム「liked_user_id」が指定されている。ここで、パラメータは、プルダウンメニューからテーブル名及びカラム名を選択可能としてもよい。

マッチングサービスを例に考えると、たとえば、一覧表示に関する第１のAPI定義入力領域６１１において、第２の入力欄６１３－２に対応する入力欄がONとされることで、生成されたソースコードを用いて動作するソフトウェアでは、サインイン等によってユーザー認証に成功しているユーザーのみが、マッチングサービスを利用する他のユーザーの一覧表示が可能となる。また、更新に関する第４のAPI定義入力領域６１４において、第３の入力欄６１３－３に対応する入力欄がONとされることで、生成されたソースコードを用いて動作するソフトウェアでは、サインイン等によってユーザー認証に成功しているユーザー自身が行った好みの意思表示を表すレコードを更新可能となる。

企業端末１１０を用いる入力者による入力されたAPI定義は、定期的又は断続的に装置１００に対して送信される（Ｓ３０７）。そして、テーブル定義及びAPI定義の入力後、装置１００は、企業端末１１０から、ソースコード生成の要求を受信したことに応じて（Ｓ３０８）、記憶部１０３に記憶された、予め作成されたソースコードの１又は複数のテンプレートを取得して、当該テーブル定義及びAPI定義に従ったソースコードを当該１又は複数のテンプレートを用いて生成する（Ｓ３０９）。生成されたソースコードは、装置１００から企業端末１１０に自動的に送信されるか、必要に応じて企業端末１１０からの取得要求を受けて送信される（Ｓ３１０）。

ソースコード生成の詳細
図７に、本発明の一実施形態にかかるソースコード生成の流れを示す。まず、装置１００は、テーブル定義を取得する（Ｓ７０１）。当該テーブル定義にユーザー認証を行うことの指定が含まれていれば（Ｓ７０２）、装置１００は、予め作成されたソースコードの１又は複数のテンプレートのうちのユーザー認証のための第１のテンプレートを取得して、ユーザー認証のためのコードを生成する（Ｓ７０３）。

ユーザー認証のためのコードの生成後、又は、テーブル定義にユーザー認証を行うことの指定が含まれない場合、装置１００は、API定義を取得する（Ｓ７０４）。当該API定義に、いずれかのAPIについて、ユーザー認証に成功していることを実行の認可の条件とする指定が含まれていれば（Ｓ７０５）、装置１００は、当該認可のための追加コードを生成する（Ｓ７０６）。

追加コードの生成後、又は、API定義に認可を行うことの指定が含まれない場合、装置１００は、予め作成されたソースコードの１又は複数のテンプレートのうちの当該認可のための第２のテンプレートを取得して、各APIのためのコードを生成する（Ｓ７０７）。API定義の取得をテーブル定義におけるユーザー認証指定の有無の判定後に行うものとして、記述したが、API定義を先に取得してもよい。

このように、ユーザー認証及び当該ユーザー認証を用いた認可を、入力者にチェックボックスのクリック又はタップによる選択によって指定されることで、各APIについて、適宜必要な権限設定がなされたソースコードを簡便に生成することが可能になる。

認可のための追加コードは、第２の入力欄６１３－２がONに指定されている場合と、第３の入力欄６１３－３がONに指定されている場合とで異なる。

第２の入力欄６１３－２がONの場合、装置１００は、第２のテンプレートに含まれる以下のようなコードから、
<%- if @table_definition.apis.auth_actions.present? -%>
before_action :authenticate_identical!, only: %w[<%= @table_definition.apis.auth_actions.join(' ') %>]
<%- end -%>
次のようなAPI定義に従ったソースコードを生成する。
before_action :authenticate_identical!, only: %w[index create]
ライクテーブル「Likes」に対して、第１のAPI定義入力領域６１１及び第３のAPI定義入力領域６１３において「Auth」がONにされている場合に、第１のAPI定義入力領域６１１に関連づけられた一覧表示の操作及び第３のAPI定義入力領域６１３に関連づけられた生成の操作を実行する前にユーザー認証に成功しているか否かを判定する。ここで、図６において「list」と表示されている操作はソースコードにおいては「index」と呼称している。

第３の入力欄６１３－３がONの場合、装置１００は、第２のテンプレートに含まれる以下のようなコードから、
<%- if @table_definition.apis.index_api.present? -%>
def index
<%- if @table_definition.apis.index_api.use_authed_record -%>
@<%= @table_definition.name %> = @current_user.<%= @table_definition.name %>
<%- else -%>
@<%= @table_definition.name %> = <%= @table_definition.klass %>
<%- end -%>
render json: {
<%= @table_definition.name %>: serialize(@<%= @table_definition.name %>),
success: true
}
end
<%- end -%>
次のようなAPI定義に従ったソースコードを生成する。
def index
@likes = @current_user.likes
render json: {
likes: serialize(@likes),
success: true
}
end
「@current_user」が、当該APIの実行対象のレコードを当該APIを実行するユーザー自身に関連するレコードに限定することを表している。

なお、上述の実施形態において、「××のみに基づいて」、「××のみに応じて」、「××のみの場合」というように「のみ」との記載がなければ、本明細書においては、付加的な情報も考慮し得ることが想定されていることに留意されたい。また、一例として、「ａの場合にｂする」という記載は、明示した場合を除き、「ａの場合に常にｂする」こと、「ａの直後にｂする」ことを必ずしも意味しないことに留意されたい。また、「Ａを構成する各ａ」という記載は、必ずしもＡが複数の構成要素によって構成されることを意味するものではなく、構成要素が単数であることを含む。

また、念のため、なんらかの方法、プログラム、端末、装置、サーバ又はシステム（以下「方法等」）において、本明細書で記述された動作と異なる動作を行う側面があるとしても、本発明の各態様は、本明細書で記述された動作のいずれかと同一の動作を対象とするものであり、本明細書で記述された動作と異なる動作が存在することは、当該方法等を本発明の各態様の範囲外とするものではないことを付言する。

また、図７において示される「開始」及び「終了」は、一例を示すものに過ぎず、本実施形態にかかる方法がＳ７０１によって必ず開始され、Ｓ７０７によって必ず終了することを意味するものではない。

また、装置１００がソースコード生成の要求を受信した以降の処理の少なくとも一について、テーブル定義及びAPI定義の受信までの処理を行うサーバとは別のサーバに担わせることで、負荷を分散するようにしてもよい。

１００ 装置
１０１ 通信部
１０２ 処理部
１０３ 記憶部
１０４ 記憶装置
４００ テーブル定義入力画面
４０１ テーブル追加ボタン
４１０ テーブル名入力領域
４２０ リレーション定義入力領域
４３０ カラム定義入力領域
４３１ カラム追加ボタン
４４０ 追加機能指定領域
６００ API定義入力画面
６１１ 第１のAPI定義入力領域
６１２ 第２のAPI定義入力領域
６１３ 第３のAPI定義入力領域
６１３－１ 第１の入力欄
６１３－２ 第２の入力欄
６１３－３ 第３の入力欄
６１３－４ 第４の入力欄
６１３－５ 第５の入力欄
６１４ 第４のAPI定義入力領域
６１５ 第５のAPI定義入力領域

Claims (10)

1. ソフトウェアのソースコード生成を支援するための方法であって、
   サーバが、端末から、複数のテーブルについてのテーブル定義及びAPI定義を受信するステップと、
   前記サーバが、前記端末から、ソースコード生成の要求を受信するステップと、
   前記サーバが、前記要求の受信に応じて、予め作成されたソースコードの１又は複数のテンプレートを取得して、前記テーブル定義及び前記API定義に従ったソースコードを前記１又は複数のテンプレートを用いて生成するステップと
   を含み、
   前記テーブル定義は、前記ソフトウェアのユーザーの基本情報に関するユーザーテーブルが有する複数のカラムのうちのユーザー認証に用いるカラムの特定を含む。
2. 請求項１に記載の方法であって、
   前記１又は複数のテンプレートは、ユーザー認証のための第１のテンプレートを含む。
3. 請求項１に記載の方法であって、
   前記API定義は、前記複数のテーブルのうちの前記ユーザーテーブル以外の他のテーブルのレコードの操作を実行するためのAPIを実行する認可条件として、前記APIを実行するユーザーのユーザー認証に成功していることの指定を含む。
4. 請求項３に記載の方法であって、
   前記API定義は、前記認可条件として、さらに、前記APIの実行対象のレコードを前記APIを実行するユーザー自身に関連するレコードに限定することの指定を含む。
5. 請求項３に記載の方法であって、
   前記１又は複数のテンプレートは、前記認可のための第２のテンプレートを含む。
6. 請求項１に記載の方法であって、
   前記サーバが受信した前記テーブル定義の第２の部分は、前記端末から受信した前記テーブル定義の第１の部分に応じて、前記サーバが生成して、前記端末に送信したものである。
7. 請求項６に記載の方法であって、
   前記第１の部分は、前記ソフトウェアの利用料金の支払いを可能とする指定を含み、
   前記第２の部分は、前記利用料金の支払いに関するペイメントテーブルが有する複数のカラムの定義、及び、前記ユーザーテーブルが有する前記ペイメントテーブルとのリレーションの定義を含む。
8. 請求項６に記載の方法であって、
   前記第１の部分は、前記ユーザーテーブル以外の他のテーブルが有する前記ユーザーテーブルとのリレーションの定義を含み、
   前記第２の部分は、前記他のテーブルが有する前記ユーザーテーブルに関連づけられたカラムの定義を含む。
9. サーバに、ソフトウェアのソースコード生成を支援するための方法を実行させるためのプログラムであって、前記方法は、
   前記サーバが、端末から、複数のテーブルについてのテーブル定義及びAPI定義を受信するステップと、
   前記サーバが、前記端末から、ソースコード生成の要求を受信するステップと、
   前記サーバが、前記要求の受信に応じて、予め作成されたソースコードの１又は複数のテンプレートを取得して、前記テーブル定義及び前記API定義に従ったソースコードを前記１又は複数のテンプレートを用いて生成するステップと
   を含み、
   前記テーブル定義は、前記ソフトウェアのユーザーの基本情報に関するユーザーテーブルが有する複数のカラムのうちのユーザー認証に用いるカラムの特定を含む。
10. ソフトウェアのソースコード生成を支援するためのサーバであって、
    端末から、複数のテーブルについてのテーブル定義及びAPI定義並びにソースコード生成の要求を受信し、
    前記要求の受信に応じて、予め作成されたソースコードの１又は複数のテンプレートを取得して、前記テーブル定義及び前記API定義に従ったソースコードを前記１又は複数のテンプレートを用いて生成し、
    前記テーブル定義は、前記ソフトウェアのユーザーの基本情報に関するユーザーテーブルが有する複数のカラムのうちのユーザー認証に用いるカラムの特定を含む。

Images