知財求人 - 知財ポータルサイト「IP Force」
特開2024-13293フォーカス対象決定装置、フォーカス対象決定方法およびフォーカス対象決定プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024013293
(43)【公開日】2024-02-01
(54)【発明の名称】フォーカス対象決定装置、フォーカス対象決定方法およびフォーカス対象決定プログラム
(51)【国際特許分類】
G06F 3/04812 20220101AFI20240125BHJP
G06F 3/14 20060101ALI20240125BHJP
G06F 9/445 20180101ALI20240125BHJP
【ＦＩ】
G06F3/04812
G06F3/14 310C
G06F9/445 130
【審査請求】未請求
【請求項の数】6
【出願形態】ＯＬ
(21)【出願番号】P 2022115256
(22)【出願日】2022-07-20
(71)【出願人】
【識別番号】398040527
【氏名又は名称】株式会社オービック
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】山下 紘平
(72)【発明者】
【氏名】馬場 健人
(72)【発明者】
【氏名】上野 剛光
【テーマコード（参考）】
5B069
5B376
5E555
【Ｆターム（参考）】
5B069AA01
5B069GA03
5B376AC01
5E555AA06
5E555AA09
5E555AA76
5E555AA79
5E555BA02
5E555BB02
5E555BC17
5E555DB07
5E555DC19
5E555DC75
5E555DD06
5E555EA07
5E555EA14
5E555FA00
(57)【要約】
【課題】画面上のどの項目をフォーカスの対象とするかを自動で決定することができるフォーカス対象決定装置、フォーカス対象決定方法およびフォーカス対象決定プログラムの提供を課題とする。
【解決手段】本実施形態では、（１）画面上の指定されたコントロールから順に判定対象として取得し、（２）前記取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定し、（３）フォーカスの設定が可能なコントロールの種類に該当すると判定した場合、当該判定の対象としたコントロールと紐付く定義管理テーブル中の「フォーカスセット可能か」の情報を取得し、当該取得した情報が「ＴＲＵＥ」に該当するか該当しないかを判定し、（４）「ＴＲＵＥ」に該当すると判定した場合、当該判定の対象としたコントロールをフォーカスの対象として決定する。
【選択図】図５８
【解決手段】本実施形態では、（１）画面上の指定されたコントロールから順に判定対象として取得し、（２）前記取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定し、（３）フォーカスの設定が可能なコントロールの種類に該当すると判定した場合、当該判定の対象としたコントロールと紐付く定義管理テーブル中の「フォーカスセット可能か」の情報を取得し、当該取得した情報が「ＴＲＵＥ」に該当するか該当しないかを判定し、（４）「ＴＲＵＥ」に該当すると判定した場合、当該判定の対象としたコントロールをフォーカスの対象として決定する。
【選択図】図５８
【特許請求の範囲】
【請求項1】
制御部および記憶部を備えるフォーカス対象決定装置であって、
前記記憶部には、
画面を構成する要素であるコントロールを識別するためのコントロール識別データと、当該コントロールに対するフォーカスの設定が可能であるか否かを識別するための情報であるフォーカス可否識別情報と、を含むテーブルが格納されており、
前記制御部は、
画面上の指定されたコントロールから順に判定対象として取得する判定対象取得手段と、
前記判定対象取得手段で取得したコントロールについての前記コントロール識別データに基づいて、前記判定対象取得手段で取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定するコントロール種類判定手段と、
前記コントロール種類判定手段で前記該当すると判定した場合、当該判定の対象としたコントロールについての前記コントロール識別データと紐付く前記テーブル中の前記フォーカス可否識別情報を取得し、当該取得したフォーカス可否識別情報が、コントロールに対するフォーカスの設定が可能であることを示すものに該当するか該当しないかを判定するフォーカス可否判定手段と、
前記フォーカス可否判定手段で前記該当すると判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定するフォーカス対象決定手段と、
を備え、
前記判定対象取得手段は、前記コントロール種類判定手段または前記フォーカス可否判定手段で前記該当しないと判定した場合、判定対象としたコントロールの次のコントロールを新たな判定対象として取得すること、
を特徴とするフォーカス対象決定装置。
前記記憶部には、
画面を構成する要素であるコントロールを識別するためのコントロール識別データと、当該コントロールに対するフォーカスの設定が可能であるか否かを識別するための情報であるフォーカス可否識別情報と、を含むテーブルが格納されており、
前記制御部は、
画面上の指定されたコントロールから順に判定対象として取得する判定対象取得手段と、
前記判定対象取得手段で取得したコントロールについての前記コントロール識別データに基づいて、前記判定対象取得手段で取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定するコントロール種類判定手段と、
前記コントロール種類判定手段で前記該当すると判定した場合、当該判定の対象としたコントロールについての前記コントロール識別データと紐付く前記テーブル中の前記フォーカス可否識別情報を取得し、当該取得したフォーカス可否識別情報が、コントロールに対するフォーカスの設定が可能であることを示すものに該当するか該当しないかを判定するフォーカス可否判定手段と、
前記フォーカス可否判定手段で前記該当すると判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定するフォーカス対象決定手段と、
を備え、
前記判定対象取得手段は、前記コントロール種類判定手段または前記フォーカス可否判定手段で前記該当しないと判定した場合、判定対象としたコントロールの次のコントロールを新たな判定対象として取得すること、
を特徴とするフォーカス対象決定装置。
【請求項2】
前記判定対象取得手段が判定対象を取得する順序が、
画面上のコントロールに対して採番された行番号および列番号に基づいて決定されたものであること、
を特徴とする請求項１に記載のフォーカス対象決定装置。
画面上のコントロールに対して採番された行番号および列番号に基づいて決定されたものであること、
を特徴とする請求項１に記載のフォーカス対象決定装置。
【請求項3】
前記制御部は、
前記フォーカス可否判定手段で前記該当すると判定した場合、当該判定の対象としたコントロールが、当該コントロール単体でみるとフォーカスの対象とすること自体は可能なコントロールであるが、他のコントロールとの関係でフォーカスの対象とすることが不可能な状態になっているかいないかを判定するフォーカス不可状態判定手段
を更に備え、
前記フォーカス対象決定手段は、前記フォーカス不可状態判定手段で前記不可能な状態にはなっていないと判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定し、
前記判定対象取得手段は、前記コントロール種類判定手段もしくは前記フォーカス可否判定手段で前記該当しないと判定した場合、または、前記フォーカス不可状態判定手段で前記不可能な状態になっていると判定した場合、判定対象としたコントロールの次のコントロールを新たな判定対象として取得すること、
を特徴とする請求項１または２に記載のフォーカス対象決定装置。
前記フォーカス可否判定手段で前記該当すると判定した場合、当該判定の対象としたコントロールが、当該コントロール単体でみるとフォーカスの対象とすること自体は可能なコントロールであるが、他のコントロールとの関係でフォーカスの対象とすることが不可能な状態になっているかいないかを判定するフォーカス不可状態判定手段
を更に備え、
前記フォーカス対象決定手段は、前記フォーカス不可状態判定手段で前記不可能な状態にはなっていないと判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定し、
前記判定対象取得手段は、前記コントロール種類判定手段もしくは前記フォーカス可否判定手段で前記該当しないと判定した場合、または、前記フォーカス不可状態判定手段で前記不可能な状態になっていると判定した場合、判定対象としたコントロールの次のコントロールを新たな判定対象として取得すること、
を特徴とする請求項１または２に記載のフォーカス対象決定装置。
【請求項4】
前記不可能な状態のコントロールが、ロック状態または非表示状態のコントロールであること、
を特徴とする請求項３に記載のフォーカス対象決定装置。
を特徴とする請求項３に記載のフォーカス対象決定装置。
【請求項5】
制御部および記憶部を備える情報処理装置で実行されるフォーカス対象決定方法であって、
前記記憶部には、
画面を構成する要素であるコントロールを識別するためのコントロール識別データと、当該コントロールに対するフォーカスの設定が可能であるか否かを識別するための情報であるフォーカス可否識別情報と、を含むテーブルが格納されており、
前記制御部で実行される、
画面上の指定されたコントロールから順に判定対象として取得する判定対象取得ステップと、
前記判定対象取得ステップで取得したコントロールについての前記コントロール識別データに基づいて、前記判定対象取得ステップで取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定するコントロール種類判定ステップと、
前記コントロール種類判定ステップで前記該当すると判定した場合、当該判定の対象としたコントロールについての前記コントロール識別データと紐付く前記テーブル中の前記フォーカス可否識別情報を取得し、当該取得したフォーカス可否識別情報が、コントロールに対するフォーカスの設定が可能であることを示すものに該当するか該当しないかを判定するフォーカス可否判定ステップと、
前記フォーカス可否判定ステップで前記該当すると判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定するフォーカス対象決定ステップと、
を含み、
前記判定対象取得ステップにおいては、前記コントロール種類判定ステップまたは前記フォーカス可否判定ステップで前記該当しないと判定した場合、判定対象としたコントロールの次のコントロールを新たな判定対象として取得すること、
を特徴とするフォーカス対象決定方法。
前記記憶部には、
画面を構成する要素であるコントロールを識別するためのコントロール識別データと、当該コントロールに対するフォーカスの設定が可能であるか否かを識別するための情報であるフォーカス可否識別情報と、を含むテーブルが格納されており、
前記制御部で実行される、
画面上の指定されたコントロールから順に判定対象として取得する判定対象取得ステップと、
前記判定対象取得ステップで取得したコントロールについての前記コントロール識別データに基づいて、前記判定対象取得ステップで取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定するコントロール種類判定ステップと、
前記コントロール種類判定ステップで前記該当すると判定した場合、当該判定の対象としたコントロールについての前記コントロール識別データと紐付く前記テーブル中の前記フォーカス可否識別情報を取得し、当該取得したフォーカス可否識別情報が、コントロールに対するフォーカスの設定が可能であることを示すものに該当するか該当しないかを判定するフォーカス可否判定ステップと、
前記フォーカス可否判定ステップで前記該当すると判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定するフォーカス対象決定ステップと、
を含み、
前記判定対象取得ステップにおいては、前記コントロール種類判定ステップまたは前記フォーカス可否判定ステップで前記該当しないと判定した場合、判定対象としたコントロールの次のコントロールを新たな判定対象として取得すること、
を特徴とするフォーカス対象決定方法。
【請求項6】
制御部および記憶部を備える情報処理装置に実行させるためのフォーカス対象決定プログラムであって、
前記記憶部には、
画面を構成する要素であるコントロールを識別するためのコントロール識別データと、当該コントロールに対するフォーカスの設定が可能であるか否かを識別するための情報であるフォーカス可否識別情報と、を含むテーブルが格納されており、
前記制御部に実行させるための、
画面上の指定されたコントロールから順に判定対象として取得する判定対象取得ステップと、
前記判定対象取得ステップで取得したコントロールについての前記コントロール識別データに基づいて、前記判定対象取得ステップで取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定するコントロール種類判定ステップと、
前記コントロール種類判定ステップで前記該当すると判定した場合、当該判定の対象としたコントロールについての前記コントロール識別データと紐付く前記テーブル中の前記フォーカス可否識別情報を取得し、当該取得したフォーカス可否識別情報が、コントロールに対するフォーカスの設定が可能であることを示すものに該当するか該当しないかを判定するフォーカス可否判定ステップと、
前記フォーカス可否判定ステップで前記該当すると判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定するフォーカス対象決定ステップと、
を含み、
前記判定対象取得ステップにおいては、前記コントロール種類判定ステップまたは前記フォーカス可否判定ステップで前記該当しないと判定した場合、判定対象としたコントロールの次のコントロールを新たな判定対象として取得すること、
を特徴とするフォーカス対象決定プログラム。
前記記憶部には、
画面を構成する要素であるコントロールを識別するためのコントロール識別データと、当該コントロールに対するフォーカスの設定が可能であるか否かを識別するための情報であるフォーカス可否識別情報と、を含むテーブルが格納されており、
前記制御部に実行させるための、
画面上の指定されたコントロールから順に判定対象として取得する判定対象取得ステップと、
前記判定対象取得ステップで取得したコントロールについての前記コントロール識別データに基づいて、前記判定対象取得ステップで取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定するコントロール種類判定ステップと、
前記コントロール種類判定ステップで前記該当すると判定した場合、当該判定の対象としたコントロールについての前記コントロール識別データと紐付く前記テーブル中の前記フォーカス可否識別情報を取得し、当該取得したフォーカス可否識別情報が、コントロールに対するフォーカスの設定が可能であることを示すものに該当するか該当しないかを判定するフォーカス可否判定ステップと、
前記フォーカス可否判定ステップで前記該当すると判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定するフォーカス対象決定ステップと、
を含み、
前記判定対象取得ステップにおいては、前記コントロール種類判定ステップまたは前記フォーカス可否判定ステップで前記該当しないと判定した場合、判定対象としたコントロールの次のコントロールを新たな判定対象として取得すること、
を特徴とするフォーカス対象決定プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、フォーカス対象決定装置、フォーカス対象決定方法およびフォーカス対象決定プログラムに関する。
【背景技術】
【0002】
特許文献１には、アプリケーション画面の項目に対し、入力、或いは、選択を行う項目に対して、フォーカスの移動をし易くすることで、ユーザの操作負荷を軽減することを目的とする情報処理装置が開示されている（特許文献１の００１１段落参照）。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１５－６９５９０号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
このように画面操作を行う分野においては、ユーザの視認性を高めること等を目的として、画面においてフォーカス表示の設定がされていることが多い。フォーカスとは、画面上で、ウインドウ、入力ボックス、アイコン、ボタンおよび画像といった対象物が、操作を受けられるアクティブな（選択された）状態となっていることを指す。フォーカスされた項目は、例えば、図４７に示すようにカーソルが点滅している状態となる。
【0005】
しかしながら、従来においては、例えば画面起動時において画面上のどの項目をフォーカスの対象とするかの設定を、担当者がプログラミングにより手動で行っていたため、時間および労力がかかるという問題があった。例えば図５０に四角点線枠で囲んで示すように、画面上の「基準日テキスト」の項目を画面起動時におけるフォーカスの対象とするためには、担当者がその旨をプログラミングしなければならなかった。
【0006】
本発明は、上記問題点に鑑みてなされたものであって、画面上のどの項目をフォーカスの対象とするかを自動で決定することができるフォーカス対象決定装置、フォーカス対象決定方法およびフォーカス対象決定プログラムを提供することを目的とする。
【課題を解決するための手段】
【0007】
上述した課題を解決し、目的を達成するために、本発明に係るフォーカス対象決定装置においては、制御部および記憶部を備えるフォーカス対象決定装置であって、前記記憶部には、画面を構成する要素であるコントロールを識別するためのコントロール識別データと、当該コントロールに対するフォーカスの設定が可能であるか否かを識別するための情報であるフォーカス可否識別情報と、を含むテーブルが格納されており、前記制御部は、画面上の指定されたコントロールから順に判定対象として取得する判定対象取得手段と、前記判定対象取得手段で取得したコントロールについての前記コントロール識別データに基づいて、前記判定対象取得手段で取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定するコントロール種類判定手段と、前記コントロール種類判定手段で前記該当すると判定した場合、当該判定の対象としたコントロールについての前記コントロール識別データと紐付く前記テーブル中の前記フォーカス可否識別情報を取得し、当該取得したフォーカス可否識別情報が、コントロールに対するフォーカスの設定が可能であることを示すものに該当するか該当しないかを判定するフォーカス可否判定手段と、前記フォーカス可否判定手段で前記該当すると判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定するフォーカス対象決定手段と、を備え、前記判定対象取得手段は、前記コントロール種類判定手段または前記フォーカス可否判定手段で前記該当しないと判定した場合、判定対象としたコントロールの次のコントロールを新たな判定対象として取得すること、を特徴とする。
【0008】
また、本発明に係るフォーカス対象決定装置においては、前記判定対象取得手段が判定対象を取得する順序が、画面上のコントロールに対して採番された行番号および列番号に基づいて決定されたものであること、を特徴とする。
【0009】
また、本発明に係るフォーカス対象決定装置においては、前記制御部は、前記フォーカス可否判定手段で前記該当すると判定した場合、当該判定の対象としたコントロールが、当該コントロール単体でみるとフォーカスの対象とすること自体は可能なコントロールであるが、他のコントロールとの関係でフォーカスの対象とすることが不可能な状態になっているかいないかを判定するフォーカス不可状態判定手段を更に備え、前記フォーカス対象決定手段は、前記フォーカス不可状態判定手段で前記不可能な状態にはなっていないと判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定し、前記判定対象取得手段は、前記コントロール種類判定手段もしくは前記フォーカス可否判定手段で前記該当しないと判定した場合、または、前記フォーカス不可状態判定手段で前記不可能な状態になっていると判定した場合、判定対象としたコントロールの次のコントロールを新たな判定対象として取得すること、を特徴とする。
【0010】
また、本発明に係るフォーカス対象決定装置においては、前記不可能な状態のコントロールが、ロック状態または非表示状態のコントロールであること、を特徴とする。
【0011】
また、本発明に係るフォーカス対象決定方法においては、制御部および記憶部を備える情報処理装置で実行されるフォーカス対象決定方法であって、前記記憶部には、画面を構成する要素であるコントロールを識別するためのコントロール識別データと、当該コントロールに対するフォーカスの設定が可能であるか否かを識別するための情報であるフォーカス可否識別情報と、を含むテーブルが格納されており、前記制御部で実行される、画面上の指定されたコントロールから順に判定対象として取得する判定対象取得ステップと、前記判定対象取得ステップで取得したコントロールについての前記コントロール識別データに基づいて、前記判定対象取得ステップで取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定するコントロール種類判定ステップと、前記コントロール種類判定ステップで前記該当すると判定した場合、当該判定の対象としたコントロールについての前記コントロール識別データと紐付く前記テーブル中の前記フォーカス可否識別情報を取得し、当該取得したフォーカス可否識別情報が、コントロールに対するフォーカスの設定が可能であることを示すものに該当するか該当しないかを判定するフォーカス可否判定ステップと、前記フォーカス可否判定ステップで前記該当すると判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定するフォーカス対象決定ステップと、を含み、前記判定対象取得ステップにおいては、前記コントロール種類判定ステップまたは前記フォーカス可否判定ステップで前記該当しないと判定した場合、判定対象としたコントロールの次のコントロールを新たな判定対象として取得すること、を特徴とする。
【0012】
また、本発明に係るフォーカス対象決定プログラムにおいては、制御部および記憶部を備える情報処理装置に実行させるためのフォーカス対象決定プログラムであって、前記記憶部には、画面を構成する要素であるコントロールを識別するためのコントロール識別データと、当該コントロールに対するフォーカスの設定が可能であるか否かを識別するための情報であるフォーカス可否識別情報と、を含むテーブルが格納されており、前記制御部に実行させるための、画面上の指定されたコントロールから順に判定対象として取得する判定対象取得ステップと、前記判定対象取得ステップで取得したコントロールについての前記コントロール識別データに基づいて、前記判定対象取得ステップで取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定するコントロール種類判定ステップと、前記コントロール種類判定ステップで前記該当すると判定した場合、当該判定の対象としたコントロールについての前記コントロール識別データと紐付く前記テーブル中の前記フォーカス可否識別情報を取得し、当該取得したフォーカス可否識別情報が、コントロールに対するフォーカスの設定が可能であることを示すものに該当するか該当しないかを判定するフォーカス可否判定ステップと、前記フォーカス可否判定ステップで前記該当すると判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定するフォーカス対象決定ステップと、を含み、前記判定対象取得ステップにおいては、前記コントロール種類判定ステップまたは前記フォーカス可否判定ステップで前記該当しないと判定した場合、判定対象としたコントロールの次のコントロールを新たな判定対象として取得すること、を特徴とする。
【発明の効果】
【0013】
本発明によれば、画面上のどの項目をフォーカスの対象とするかを自動で決定することができるという効果を奏する。
【図面の簡単な説明】
【0014】
【発明を実施するための形態】
【0015】
以下に、本発明に係るフォーカス対象決定装置、フォーカス対象決定方法およびフォーカス対象決定プログラムの実施形態を、図面に基づいて詳細に説明する。なお、本実施形態により本発明が限定されるものではない。
【0016】
［１．概要］
（１）背景
一般的な業務アプリケーションでは、業務オペレータによる操作を補助するため、フォーカスの移動を伴う処理をシステムに組み込む場合が多い。例えば、初期起動時には、入力可能な先頭項目にフォーカスを初期セットし、入力完了後は次の項目にフォーカスをセットする、といったケースが考えられる。このようなフォーカスセットを行わなければ、業務オペレータ自らが次の項目に対してフォーカスを移動させる必要があり、ユーザビリティが低下する。
（１）背景
一般的な業務アプリケーションでは、業務オペレータによる操作を補助するため、フォーカスの移動を伴う処理をシステムに組み込む場合が多い。例えば、初期起動時には、入力可能な先頭項目にフォーカスを初期セットし、入力完了後は次の項目にフォーカスをセットする、といったケースが考えられる。このようなフォーカスセットを行わなければ、業務オペレータ自らが次の項目に対してフォーカスを移動させる必要があり、ユーザビリティが低下する。
【0017】
ここで、業務アプリケーションの画面が複雑になる場合、これに伴うフォーカス制御も複雑化する。特に、ユーザに設定させたい項目が、状況に応じて動的に変化するようなケースでは、設定パターンも複雑化する。従来の開発では、開発者の手作業によるプログラミングを行うことで、複雑なフォーカス制御を実現することが一般的であった。
【0018】
（２）問題点
しかしながら、設定が複雑なフォーカス制御の場合には、プログラミングの難易度が上がり、システムの完成までにかかる工数が増加するという問題があった。また、急な項目の変更等があった場合に、再設定が難しくなるという問題もあった。
しかしながら、設定が複雑なフォーカス制御の場合には、プログラミングの難易度が上がり、システムの完成までにかかる工数が増加するという問題があった。また、急な項目の変更等があった場合に、再設定が難しくなるという問題もあった。
【0019】
（３）解決策
ここで、ローコード開発基盤では、フォーカス制御をアクション処理（以下、このアクションを「フォーカスセットアクション」という）によって実現しているが、ローコード開発基盤で開発されたシステムでは、画面全体のコントロールをＤＢ上に一元管理しているため、フォーカスセットアクション内では、画面全体のコントロールにアクセスすることが容易である。このため、フォーカスセットアクション内では、画面上のコントロールを階層化して把握しやすいという利点がある。
ここで、ローコード開発基盤では、フォーカス制御をアクション処理（以下、このアクションを「フォーカスセットアクション」という）によって実現しているが、ローコード開発基盤で開発されたシステムでは、画面全体のコントロールをＤＢ上に一元管理しているため、フォーカスセットアクション内では、画面全体のコントロールにアクセスすることが容易である。このため、フォーカスセットアクション内では、画面上のコントロールを階層化して把握しやすいという利点がある。
【0020】
この利点を生かし、本実施形態においては、例えば、以下の２つのアクションを実現した。
【0021】
一つ目は、フォーカス可能な先頭項目にフォーカスをセットするアクションである。具体的には、画面上のフォーカス可能な先頭のコントロールを自動で判定し、判定結果のコントロールに対してフォーカスをセットするアクションである。
【0022】
二つ目は、指定したコントロールより後ろのフォーカス可能な先頭項目にフォーカスをセットするアクションである。具体的には、アクション設定でコントロールを指定し、指定したコントロールより後ろのフォーカス可能な先頭のコントロールを自動で判定し、判定結果のコントロールに対してフォーカスをセットするアクションである。
【0023】
（４）効果
このように、本実施形態においては、画面上のコントロールを一元管理していることで、アクション処理において、フォーカス先をアクションが自動的に判定することができるため、開発者が個別でフォーカス制御を行う必要がなくなった。
このように、本実施形態においては、画面上のコントロールを一元管理していることで、アクション処理において、フォーカス先をアクションが自動的に判定することができるため、開発者が個別でフォーカス制御を行う必要がなくなった。
【0024】
以上を一言でまとめると、本実施形態においては、システム構築時におけるフォーカス設定のコストが高いという従来の問題を、ローコード開発基盤を用いることで解決した。以下、具体的な構成および動作について説明する。
【0025】
【0026】
フォーカス対象決定装置１００は、市販のデスクトップ型パーソナルコンピュータである。なお、フォーカス対象決定装置１００は、デスクトップ型パーソナルコンピュータのような据置型情報処理装置に限らず、市販されているノート型パーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、スマートフォン、タブレット型パーソナルコンピュータなどの携帯型情報処理装置であってもよい。
【0027】
フォーカス対象決定装置１００は、制御部１０２と通信インターフェース部１０４と記憶部１０６と入出力インターフェース部１０８と、を備えている。フォーカス対象決定装置１００が備えている各部は、任意の通信路を介して通信可能に接続されている。
【0028】
通信インターフェース部１０４は、ルータ等の通信装置および専用線等の有線または無線の通信回線を介して、フォーカス対象決定装置１００をネットワーク３００に通信可能に接続する。通信インターフェース部１０４は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク３００は、フォーカス対象決定装置１００とサーバ２００とを相互に通信可能に接続する機能を有し、例えばインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。なお、後述する各種マスタ等のデータは、例えばサーバ２００に格納されてもよい。
【0029】
入出力インターフェース部１０８には、入力装置１１２および出力装置１１４が接続されている。出力装置１１４には、モニタ（家庭用テレビを含む）の他、スピーカやプリンタを用いることができる。入力装置１１２には、キーボード、マウス、及びマイクの他、マウスと協働してポインティングデバイス機能を実現するモニタを用いることができる。なお、以下では、出力装置１１４をモニタ１１４とし、入力装置１１２をキーボード１１２またはマウス１１２として記載する場合がある。
【0030】
記憶部１０６には、各種のデータベース、テーブルおよびファイルなどが格納される。記憶部１０６には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）と協働してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）に命令を与えて各種処理を行うためのコンピュータプログラムが記録される。記憶部１０６として、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）・ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等のメモリ装置、ハードディスクのような固定ディスク装置、フレキシブルディスク、および光ディスク等を用いることができる。
【0031】
記憶部１０６は、例えば、テーブルとしての定義管理テーブル１０６ａを備えている。
【0032】
定義管理テーブル１０６ａは、図４９に示すように、例えば、定義識別データ（定義ＩＤおよび定義名）と、画面を構成する要素であるコントロールについての情報であるコントロール情報と、を含む。
【0033】
前記コントロール情報は、図４９に示すように、例えば、前記コントロールを識別するためのコントロール識別データ（ＩＤおよび名称）と、前記コントロールへの入力が必須か否かを識別するための情報である入力要否識別情報（必須）と、コントロールに対するフォーカスの設定が可能であるか否かを識別するための情報であるフォーカス可否識別情報（フォーカスセット可能か）と、からなる。
【0034】
前記コントロール識別データ（ＩＤおよび名称）は、前記コントロールの種類の情報も内包する。例えば、図４９の例では、コントロール要素１の名称「基準日ラベル」は、コントロール要素１が「ラベル」というコントロールの種類に該当するという情報を内包し、一方で、コントロール要素２の名称「基準日テキスト」は、コントロール要素２が「テキスト」というコントロールの種類に該当するという情報を内包している。
【0035】
制御部１０２は、フォーカス対象決定装置１００を統括的に制御するＣＰＵ等である。制御部１０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。
【0036】
制御部１０２は、機能概念的に、例えば、（１）画面上の指定されたコントロールから順に判定対象として取得する判定対象取得手段としての判定対象取得部１０２ａと、（２）前記判定対象取得手段で取得したコントロールについての前記コントロール識別データに基づいて、前記判定対象取得手段で取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定するコントロール種類判定手段としてのコントロール種類判定部１０２ｂと、（３）前記コントロール種類判定手段で前記該当すると判定した場合、当該判定の対象としたコントロールについての前記コントロール識別データと紐付く前記テーブル中の前記フォーカス可否識別情報を取得し、当該取得したフォーカス可否識別情報が、コントロールに対するフォーカスの設定が可能であることを示すものに該当するか該当しないかを判定するフォーカス可否判定手段としてのフォーカス可否判定部１０２ｃと、（４）前記フォーカス可否判定手段で前記該当すると判定した場合、当該判定の対象としたコントロールが、当該コントロール単体でみるとフォーカスの対象とすること自体は可能なコントロールであるが、他のコントロールとの関係でフォーカスの対象とすることが不可能な状態になっているかいないかを判定するフォーカス不可状態判定手段としてのフォーカス不可状態判定部１０２ｄと、（５）前記フォーカス可否判定手段で前記該当すると判定した場合、当該判定の対象としたコントロールを、フォーカスの対象として決定するフォーカス対象決定手段としてのフォーカス対象決定部１０２ｅと、を備えている。
【0037】
判定対象取得部１０２ａは、画面上の指定されたコントロールから順に判定対象として取得する。当該取得の順序は、例えば、画面上のコントロールに対して採番された行番号および列番号に基づいて決定される。具体的には、判定対象取得部１０２ａは、行番号がより若いコントロールから順に、行番号が同じ場合には列番号がより若いコントロールから順に取得する。当該取得の詳細は、以下の［５－２］で説明する。
【0038】
コントロール種類判定部１０２ｂは、判定対象取得部１０２ａで取得したコントロールについての前記コントロール識別データ（ＩＤおよび名称）に基づいて、判定対象取得部１０２ａで取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定する。
【0039】
フォーカス可否判定部１０２ｃは、コントロール種類判定部１０２ｂで前記該当すると判定した場合、当該判定の対象としたコントロールについての前記コントロール識別データ（ＩＤおよび名称）と紐付く定義管理テーブル１０６ａ（図４９参照）中の前記フォーカス可否識別情報（フォーカスセット可能か）を取得し、当該取得したフォーカス可否識別情報（フォーカスセット可能か）が、コントロールに対するフォーカスの設定が可能であることを示すもの（ＴＲＵＥ）に該当するか該当しないかを判定する。
【0040】
フォーカス不可状態判定部１０２ｄは、フォーカス可否判定部１０２ｃで前記該当すると判定した場合、当該判定の対象としたコントロールが、当該コントロール単体でみるとフォーカスの対象とすること自体は可能なコントロールであるが、他のコントロールとの関係で（＝以下の［３－３］で説明するビジネスルールにより）フォーカスの対象とすることが不可能な状態になっているかいないかを判定する。前記不可能な状態のコントロールは、例えば、ロック状態または非表示状態のコントロールである。
【0041】
フォーカス対象決定部１０２ｅは、フォーカス対象を決定するが、この際、フォーカス不可状態判定部１０２ｄでの判定結果（＝ビジネスルール）を考慮してもよいし、しなくてもよい。
【0042】
フォーカス不可状態判定部１０２ｄでの判定結果（＝ビジネスルール）を考慮しない場合、フォーカス対象決定部１０２ｅは、フォーカス可否判定部１０２ｃで前記該当すると判定した場合に、当該判定の対象としたコントロールを、フォーカスの対象として決定する。
【0043】
フォーカス不可状態判定部１０２ｄでの判定結果（＝ビジネスルール）を考慮する場合、フォーカス対象決定部１０２ｅは、フォーカス不可状態判定部１０２ｄで前記不可能な状態にはなっていないと判定した場合に、当該判定の対象としたコントロールを、フォーカスの対象として決定する。
【0044】
ここまでは、判定対象としたコントロールをフォーカスの対象として決定できる場合について説明したが、以下で説明するように判定対象とするコントロールをフォーカスの対象として決定できない場合、判定対象取得部１０２ａは、判定対象としたコントロールの次のコントロールを新たな判定対象として取得する。
【0045】
フォーカス不可状態判定部１０２ｄでの判定結果（＝ビジネスルール）を考慮しない場合、判定対象取得部１０２ａは、コントロール種類判定部１０２ｂまたはフォーカス可否判定部１０２ｃで前記該当しないと判定した場合に、判定対象としたコントロールの次のコントロールを新たな判定対象として取得する。
【0046】
フォーカス不可状態判定部１０２ｄでの判定結果（＝ビジネスルール）を考慮する場合、判定対象取得部１０２ａは、コントロール種類判定部１０２ｂもしくはフォーカス可否判定部１０２ｃで前記該当しないと判定した場合に、または、フォーカス不可状態判定部１０２ｄで前記不可能な状態になっていると判定した場合に、判定対象としたコントロールの次のコントロールを新たな判定対象として取得する。
【0047】
［３．前提事項］
本項目では、本実施形態における処理を説明するための前提事項について説明する。
本項目では、本実施形態における処理を説明するための前提事項について説明する。
【0048】
［３－１．ローコード開発ツールの概要］
（１）ローコード開発とは
ローコード開発とは、システム構築における開発手法の一つである。本明細書で指すシステムとは、企業が業務に利用するための一般的なＥＲＰシステム等を指すものとし、以下、「業務アプリケーション」という。
（１）ローコード開発とは
ローコード開発とは、システム構築における開発手法の一つである。本明細書で指すシステムとは、企業が業務に利用するための一般的なＥＲＰシステム等を指すものとし、以下、「業務アプリケーション」という。
【0049】
従来の開発においては、開発者自らがプログラミングよりソースコードを記述し、ＵＩから処理に必要な業務ロジックに至るまで、業務アプリケーション全体の構築を行っていた。一方で、ローコード開発では、一般的にローコード開発ツールを用いて開発を行う。ローコード開発ツールは、設定に基づき、主に業務アプリケーションのＵＩ部分を生成する機能を持つ。
【0050】
つまり、開発者は、自身がプログラミングを行わなくても、ローコード開発ツールを設定することで業務アプリケーションのＵＩ部分を構築することが可能となる。結果として、開発者自身の作業量を削減し、効率的にシステム開発を行うことができるというメリットがある。
【0051】
（２）業務アプリケーションの効率的な開発およびローコード開発を行うメリットについて
ハードウェアの多様化に伴い、業務アプリケーションも複数のハードウェア上で動作することが求められるようになった。例えば、クライアント、サーバ間で動作するクライアントサーバ型業務アプリケーション、インターネット接続を前提とするＷｅｂ型業務アプリケーションおよび携帯端末での使用を前提とするモバイル型業務アプリケーション等が挙げられる。
ハードウェアの多様化に伴い、業務アプリケーションも複数のハードウェア上で動作することが求められるようになった。例えば、クライアント、サーバ間で動作するクライアントサーバ型業務アプリケーション、インターネット接続を前提とするＷｅｂ型業務アプリケーションおよび携帯端末での使用を前提とするモバイル型業務アプリケーション等が挙げられる。
【0052】
このようにハードウェアが多様化する一方、業務アプリケーションに求められる処理自体は、大きく変化しない場合が多い。業務アプリケーションにおける処理とは、ある特定の業務(例:勤怠システムおよび販売システム等)に特化した処理のことを指す場合が多いので、このような処理を実現するロジック部分を総称して、以下、「業務ロジック」という。
【0053】
例えば、勤怠業務アプリケーションに見られる打刻処理(ユーザの出勤、退勤時刻をデータベースに保存するような処理)を考えると、異なるハードウェア上で動作する業務アプリケーションであったとしても、打刻処理の業務ロジック自体が大きく変化するわけではない。つまり、図２に示すように、ハードウェアに依存するＵＩ部分を個別に作成するだけで、呼び出す業務ロジックは共通化することが可能だと考えられる。
【0054】
このように、業務アプリケーション開発における理想としては、ハードウェアに関わらず同一の処理では共通の業務ロジックを使用できることが望ましい。なぜなら、業務ロジックの重複箇所が増えることで、開発、テストおよび修正にかかるコストが増加するためである。
【0055】
しかしながら、従来のプログラミングによって開発された業務アプリケーションでは、共通で使用したい業務ロジックをハードウェア間で再利用できないケースが多い。例えば、クライアントサーバ型の業務アプリケーションを開発後に、Ｗｅｂ型システムの開発がスタートする場合を考える。この時、クライアントサーバ型の業務アプリケーションを開発している段階で、Ｗｅｂ型システムでも再利用可能な形で業務ロジックを切り出しておく必要がある。開発済のクライアントサーバ型の業務アプリケーションの業務ロジックを、再利用可能な構成に変更するケースも考えられるが、修正により不具合を生むリスクを考えると、図３に示すように、追加の開発コストをかけてでも、Ｗｅｂ型システム用に新たに業務ロジックを作る場合が多い。このように、従来型の開発手法を用いた場合、業務ロジックを共通化して効率的な開発を行うためには、将来の変更を見据えた業務アプリケーション設計を行う必要があるため、設計者のスキルに左右される部分が大きく、難易度が高い。
【0056】
一方で、ローコード開発によって開発されたアプリケーションでは、後述するローコード開発ツールによって、業務アプリケーションのＵＩ部分が構成される。開発者は、図４に示すように、業務ロジック部分のみ作成するため、必然的にＵＩ部分と業務ロジック部分が分離することになる。この結果、従来のプログラミングによる開発で発生していた業務ロジックの重複がなくなり、設計者のスキルに頼ることなく効率の良い開発を行うことが可能となる。以下で説明するローコード開発ツールでは、主に業務アプリケーションのＵＩ部分の生成と、独立した業務ロジックをアプリケーション上で使用するための紐づけ処理を行う。
【0057】
（３）ローコード開発ツールとは
以下の説明では、開発者側および顧客となる企業の業務オペレータ側という２種類の利用者を想定している。開発者がローコード開発ツールを用いた業務アプリケーションのＵＩ設定および業務ロジックの作成を行う段階（開発段階）と、業務オペレータが実際にアプリケーションとして利用する段階（利用段階）と、の２つの段階に分けて説明を行う。
以下の説明では、開発者側および顧客となる企業の業務オペレータ側という２種類の利用者を想定している。開発者がローコード開発ツールを用いた業務アプリケーションのＵＩ設定および業務ロジックの作成を行う段階（開発段階）と、業務オペレータが実際にアプリケーションとして利用する段階（利用段階）と、の２つの段階に分けて説明を行う。
【0058】
開発段階とは、開発者がローコード開発基盤を用いて、業務アプリケーションの設定情報をデータベースに登録する段階である。利用段階とは、ローコード実行基盤が、開発段階で登録された設定情報を解析し、実際の業務アプリケーションへ変換することで、業務オペレータが業務を実行する段階である。本明細書では、ローコード開発基盤およびローコード実行基盤を合わせて、「ローコード開発ツール」と総称する。
【0059】
ここで、各段階で生成されるデータ管理方法について説明する。統制上の観点から、開発者が開発時にアプリケーション設定を管理するデータベースと、業務オペレータが業務利用時に参照するアプリケーション設定を管理するデータベースとは、明確に分ける必要がある。これは、開発者が、業務用データベースを直接操作することがないようにするためである。以下の説明では、開発者が利用するアプリケーション設定管理用のデータベースを「開発用アプリケーションＤＢ」といい、業務オペレータが利用するアプリケーション設定管理用のデータベースを「業務用アプリケーションＤＢ」という。
【0060】
（３－１）開発段階
開発段階は、図５の上半分に示すように、開発者がローコード開発ツール（ローコード開発基盤側）を用いて業務アプリケーションの開発を行う段階である。ローコード開発では、主にアプリケーション画面のレイアウトと、レイアウトを操作した時に行われる一連のイベント処理(アクション、ロジックフロー)の開発の設定を行う。最終的にレイアウトとロジックフローを紐づけることで、業務アプリケーションのＵＩ部分を生成できる。開発段階での主な設定内容は、以下の（Ａ）～（Ｄ）のとおりである。
開発段階は、図５の上半分に示すように、開発者がローコード開発ツール（ローコード開発基盤側）を用いて業務アプリケーションの開発を行う段階である。ローコード開発では、主にアプリケーション画面のレイアウトと、レイアウトを操作した時に行われる一連のイベント処理(アクション、ロジックフロー)の開発の設定を行う。最終的にレイアウトとロジックフローを紐づけることで、業務アプリケーションのＵＩ部分を生成できる。開発段階での主な設定内容は、以下の（Ａ）～（Ｄ）のとおりである。
【0061】
（Ａ）レイアウト開発
業務アプリケーションの画面レイアウト部分の設定を行う。
業務アプリケーションの画面レイアウト部分の設定を行う。
【0062】
（Ｂ）ロジックフロー開発およびアクション開発
業務アプリケーションの処理部分の設定を行う。ローコード開発ツールでは、業務アプリケーションにおける処理を、アクションという単位で設定できる（先述のＵＩ部分と業務ロジックの紐づけも、このアクションを通して行われる）。更に、アクション同士をフローでつなぐことで、一連アクションを処理する順序を設定できる。このアクションの処理順序の設定を「ロジックフロー」という。
業務アプリケーションの処理部分の設定を行う。ローコード開発ツールでは、業務アプリケーションにおける処理を、アクションという単位で設定できる（先述のＵＩ部分と業務ロジックの紐づけも、このアクションを通して行われる）。更に、アクション同士をフローでつなぐことで、一連アクションを処理する順序を設定できる。このアクションの処理順序の設定を「ロジックフロー」という。
【0063】
業務ロジックを呼びだすための特殊なアクション設定について説明する。ローコード開発において、開発者が個別のプログラミング作業等によって作成するのは業務ロジック部分のみであり、ＵＩ部分はローコード開発ツールの操作によって生成される。このため、ＵＩ側から業務ロジックを呼び出すために、開発者は作成した業務ロジックをＡＰＩ化してＡＰＩマスタに登録しておく必要がある。ＡＰＩマスタに登録したＡＰＩを、ＡＰＩ呼出アクションから呼び出すことで、業務ロジックを実行することができる。
【0064】
（Ｃ）レイアウトとロジックフローの結合
（Ａ）で設定したレイアウトに対して、（Ｂ）のロジックフローを割り付ける設定を行う。
（Ａ）で設定したレイアウトに対して、（Ｂ）のロジックフローを割り付ける設定を行う。
【0065】
（Ｄ）ビジネスルール開発
複雑なアプリケーションになると、画面の状態によってコントロールの入力を必須（任意）にしたり、ロックしたりといった、動的な制御を行いたいというニーズが存在する。このため、上記の（Ａ）～（Ｃ）の設定に加えて、特定の状態の場合には、コントロールを切り替える、といった動的な制御が必要になる。このように、画面上のコントロールに対して一定のルール（「コンディション」という）を設け、そのルールを満たす場合にコントロールを制御する仕組みを「ビジネスルール」という。
複雑なアプリケーションになると、画面の状態によってコントロールの入力を必須（任意）にしたり、ロックしたりといった、動的な制御を行いたいというニーズが存在する。このため、上記の（Ａ）～（Ｃ）の設定に加えて、特定の状態の場合には、コントロールを切り替える、といった動的な制御が必要になる。このように、画面上のコントロールに対して一定のルール（「コンディション」という）を設け、そのルールを満たす場合にコントロールを制御する仕組みを「ビジネスルール」という。
【0066】
上記のようなアプリケーションの設定情報は、複数のアプリケーション画面間で共有することが可能である。具体的には、アプリケーション画面に共通する箇所を抜き出したテンプレート画面(以下、「マスタページ」という)を作成し、そのマスタページを複数の子画面から継承することで、子画面ではマスタページの設定情報を利用することができる。このような仕組みを「マスタページの継承」という。
【0067】
（３－２）利用段階
利用段階は、図５の下半分に示すように、ローコード開発ツール（ローコード実行基盤側）が登録されている業務アプリケーション設定を解析し、業務アプリケーションへの変換を行うことで、業務オペレータが業務アプリケーションを操作する段階である。納品前に行われる動作テストも、作成された業務アプリケーションに対して行われる。
利用段階は、図５の下半分に示すように、ローコード開発ツール（ローコード実行基盤側）が登録されている業務アプリケーション設定を解析し、業務アプリケーションへの変換を行うことで、業務オペレータが業務アプリケーションを操作する段階である。納品前に行われる動作テストも、作成された業務アプリケーションに対して行われる。
【0068】
［３－２．レイアウト、ロジックフローおよびアクションについて］
本項目では、開発者によるローコード開発ツールの基本操作について、説明を行う。［３－１］で説明したように、ローコード開発では、業務アプリケーション内のＵＩと業務ロジックが強制的に分離される。ローコード開発ツールを設定することで、開発者は自らプログラミングを行うことなく、業務ロジック以外の部分を生成することができる。ローコード開発ツールによるアプリケーション設定のことを、以降の説明では「ＵＩ定義」という。
本項目では、開発者によるローコード開発ツールの基本操作について、説明を行う。［３－１］で説明したように、ローコード開発では、業務アプリケーション内のＵＩと業務ロジックが強制的に分離される。ローコード開発ツールを設定することで、開発者は自らプログラミングを行うことなく、業務ロジック以外の部分を生成することができる。ローコード開発ツールによるアプリケーション設定のことを、以降の説明では「ＵＩ定義」という。
【0069】
登録されたＵＩ定義は、アプリケーションＤＢの定義管理テーブル（図６参照）に保存される。定義管理テーブルでは、定義内のコントロール情報、ロジック情報、および、レイアウトとロジックの紐づけ情報等を管理している。定義管理テーブル内の用語の意味は、以下のとおりである。
・定義ＩＤ・・・ＵＩ定義作成時に、自動で採番されるGuid文字列。
・定義名・・・ＵＩ定義作成時に、開発者が命名。
・コントロール情報・・・以下の「（１）レイアウト開発」を参照。
・アクション情報・・・以下の「（２）ロジックフローおよびアクション開発」を参照。
・ロジックフロー情報・・・以下の「（２）ロジックフローおよびアクション開発」を参照。
・紐づけ情報・・・以下の「（３）レイアウトとロジックの結合」を参照。
・定義ＩＤ・・・ＵＩ定義作成時に、自動で採番されるGuid文字列。
・定義名・・・ＵＩ定義作成時に、開発者が命名。
・コントロール情報・・・以下の「（１）レイアウト開発」を参照。
・アクション情報・・・以下の「（２）ロジックフローおよびアクション開発」を参照。
・ロジックフロー情報・・・以下の「（２）ロジックフローおよびアクション開発」を参照。
・紐づけ情報・・・以下の「（３）レイアウトとロジックの結合」を参照。
【0070】
（１）レイアウト開発
開発段階では、開発者がレイアウト開発画面を操作することで、開発用アプリケーションＤＢにコントロール情報を登録する（図７参照）。例えば、図８の画面例では、基準日を入力するテキストボックスを日付テキストから選択して配置している。配置したコントロールをクリックすると、クリックしたコントロールの種類に応じたプロパティの設定を行うことができる。例えば、日付テキストは、その入力がアプリケーション上必須のものかどうかを示す必須プロパティが用意されている。図８の画面例では必須プロパティがＯＮになっているので、基準日テキストはアプリケーション上、入力必須のコントロールとなる。
開発段階では、開発者がレイアウト開発画面を操作することで、開発用アプリケーションＤＢにコントロール情報を登録する（図７参照）。例えば、図８の画面例では、基準日を入力するテキストボックスを日付テキストから選択して配置している。配置したコントロールをクリックすると、クリックしたコントロールの種類に応じたプロパティの設定を行うことができる。例えば、日付テキストは、その入力がアプリケーション上必須のものかどうかを示す必須プロパティが用意されている。図８の画面例では必須プロパティがＯＮになっているので、基準日テキストはアプリケーション上、入力必須のコントロールとなる。
【0071】
利用段階では、設定に基づいてアプリケーションが生成される。前段落で説明した図８の例では、基準日が必須となるので、業務オペレータが基準日を入力せずに処理を進めようとした場合に、図９に示すようにエラーが表示される。
【0072】
ここで、補足として、ローコード開発ツールにおける各コントロールの位置情報について説明する。ローコード開発ツールでは、開発者が配置したコントロールに対して、内部的に行と列の情報を付与することで、各コントロールの位置関係を明確化する。例えば、図１０の画面例では、カードパネル内に、基準日(ラベル＋テキストボックス)、取引先ＣＤ(ラベル＋テキストボックス)および表示ボタンという情報が表示されている。配置されたコントロールに対して、ローコード開発ツールは、図１０に示すように、自動的に行と列のプロパティ情報をセットする。ローコード開発基盤上で設定されたレイアウト情報を業務アプリケーションに変換する際には、この行列のプロパティ情報を利用して、コントロールの位置関係を特定できる。
【0073】
（２）ロジックフローおよびアクション開発
（２－１）アクション設定について
開発段階では、開発者がロジックフローおよびアクション開発画面を操作することで、開発用アプリケーションＤＢにロジックフロー情報およびアクション情報を登録する（図１１参照）。ローコード開発ツールにおけるロジックフロー設定は、図１２に示すように、処理が開始するための開始アクションと処理が終了するための終了アクションの間でフローがつながっている状態が初期状態となる。この２つのアクションの間に、必要なアクションを図１３に示すように組み込むことで、設定を行う。
（２－１）アクション設定について
開発段階では、開発者がロジックフローおよびアクション開発画面を操作することで、開発用アプリケーションＤＢにロジックフロー情報およびアクション情報を登録する（図１１参照）。ローコード開発ツールにおけるロジックフロー設定は、図１２に示すように、処理が開始するための開始アクションと処理が終了するための終了アクションの間でフローがつながっている状態が初期状態となる。この２つのアクションの間に、必要なアクションを図１３に示すように組み込むことで、設定を行う。
【0074】
アクションをクリックして編集することで、各アクションに詳細な設定を行うことができる。アクションごとに、設定できる内容は異なる。例えば、メッセージ表示アクションでは、メッセージの種類や、メッセージの内容を設定できる。図１４に示すメッセージアクション設定例では、Ｙｅｓ、Ｎｏ型のメッセージボックスに、「取引先を表示します、よろしいですか？」というメッセージを表示する設定を行っている。
【0075】
アクション設定で、Ｙｅｓ、Ｎｏ型のメッセージボックスが選択された場合は、ロジックフロー上処理を、Ｙｅｓ選択時、Ｎｏ選択時で分岐させることができるようになる。図１５に示す例では、メッセージ(取引先を表示します、よろしいですか？)に対して、Ｙｅｓが選択された場合は、ＡＰＩ呼出アクションで取引先を取得するような処理を行い、これに対して、Ｎｏが選択された場合は、処理が終了する。
【0076】
（２－２）業務ロジックを紐づけるための特殊なアクション設定について
図１６に示す例では、メッセージでＹｅｓを選択後、ＡＰＩ呼出アクションが実行される。先述のように、ローコード開発ツールでは、業務アプリケーションのＵＩ部分のみ生成することができ、業務データの取得および更新といった業務ロジックについては、開発者がプログラミング作業によって開発する必要がある。つまり、業務ロジック自体は、ローコード開発ツールから独立した外部のロジックとなる。ＡＰＩ呼出アクションとは、ローコード開発ツールで作成したＵＩ情報と、開発者が作成した業務ロジックと、をそれぞれ紐づけて実行することができる特殊なアクションのことである。準備として、開発者は、ローコード開発ツールで生成したＵＩ側から呼び出したい業務ロジックをＡＰＩ化し(図１７参照)、ＡＰＩマスタに登録しておく（図１８参照）。
図１６に示す例では、メッセージでＹｅｓを選択後、ＡＰＩ呼出アクションが実行される。先述のように、ローコード開発ツールでは、業務アプリケーションのＵＩ部分のみ生成することができ、業務データの取得および更新といった業務ロジックについては、開発者がプログラミング作業によって開発する必要がある。つまり、業務ロジック自体は、ローコード開発ツールから独立した外部のロジックとなる。ＡＰＩ呼出アクションとは、ローコード開発ツールで作成したＵＩ情報と、開発者が作成した業務ロジックと、をそれぞれ紐づけて実行することができる特殊なアクションのことである。準備として、開発者は、ローコード開発ツールで生成したＵＩ側から呼び出したい業務ロジックをＡＰＩ化し(図１７参照)、ＡＰＩマスタに登録しておく（図１８参照）。
【0077】
業務ロジックのＡＰＩ化について説明する。図１７に示すように、業務アプリケーション実行時に読み込まれるモジュールに、あらかじめＡＰＩを作成しておく。つまり、実行したい業務ロジックの実処理、後からＡＰＩ呼出時に必要となるキー情報などを管理しておく。図１７の例では、引数に基準日(日付)を指定した場合に、その日付時点で登録されている取引先情報(取引先ＣＤおよび取引先名等)の一覧を返すようなＡＰＩを登録している。
【0078】
ＡＰＩマスタに登録への登録について説明する。作成したＡＰＩ情報を、図１８に示すように、ＡＰＩ管理テーブルに登録する。
【0079】
その後、ＡＰＩ呼出アクションの編集画面では、図１９に示すように、開発者があらかじめ登録したＡＰＩを格納したＡＰＩマスタの中から、必要なＡＰＩを選択し、そのＡＰＩの引数や戻り値の設定を行う。
【0080】
アクション情報について説明する。定義管理テーブルのアクション情報には、図２０に示すように、アクションごとに設定された情報(ＩＤ、名前、アクションタイプおよび各設定等)がセットされる。メッセージ表示アクションの例では、メッセージ種類が３(Ｙｅｓ、Ｎｏ)、メッセージ内容が「取引先を表示します、よろしいですか？」という情報が登録される。ＡＰＩ呼出アクションの例では、ＡＰＩに渡す引数(基準日)の値に、画面上の基準日テキストの値をセットし、結果返ってきた戻り値(取引先ＣＤおよび取引先名等)の値を、画面上の取引先ＣＤテキストセル、取引先名テキストセルにセットしている情報が登録される。
【0081】
ロジックフロー情報について説明する。定義管理テーブルのロジックフロー情報には、図２１に示すように、ロジックフローごとに設定された情報(ＩＤ、名前およびアクション同士を繋ぐフロー群等)がセットされる。前アクションＩＤは、先に処理されるアクションのＩＤであり、後アクションＩＤは、前アクションが実行された後に実行されるアクションのＩＤである。コールバックキーは、アクション実行時にユーザが何か行為を選択した場合に、その選択結果を判別するためのキーである。図２１の例では、ユーザがメッセージボックスでＹｅｓを選択した場合はコールバックキーがＹｅｓのフローを特定し、後アクションＩＤにセットされたアクションが実行される。
【0082】
（３）レイアウトとロジックの結合
開発段階では、開発者がレイアウト開発画面で各コントロールにロジックフローの割り付けを行うことで、開発用アプリケーションＤＢに紐づけ情報を登録する（図２２参照）。「（１）レイアウト開発」と「（２）ロジックフローおよびアクション開発」でそれぞれ作成したコントロールとフローの割り付けを行う。図２３に示すように、コントロールのプロパティに、イベント項目(ボタンコントロールの場合には、クリックイベント)があり、ここに先ほど登録したフローがプルダウン形式で一覧で表示される。
開発段階では、開発者がレイアウト開発画面で各コントロールにロジックフローの割り付けを行うことで、開発用アプリケーションＤＢに紐づけ情報を登録する（図２２参照）。「（１）レイアウト開発」と「（２）ロジックフローおよびアクション開発」でそれぞれ作成したコントロールとフローの割り付けを行う。図２３に示すように、コントロールのプロパティに、イベント項目(ボタンコントロールの場合には、クリックイベント)があり、ここに先ほど登録したフローがプルダウン形式で一覧で表示される。
【0083】
紐づけ情報について説明する。定義管理テーブルのロジックフロー情報には、図２４に示すように、コントロール(表示ボタン)のＩＤ、イベントタイプおよびロジックフロー(ロジックフロー１)のＩＤという３つの情報が紐づけて登録される。一つのコントロールに対して、複数のイベントに割り付けられるようなコントロールでは、コントロールのＩＤだけでは紐づけが特定できないため、イベントタイプを紐づけ情報に含める必要がある(テキストボックスの検証時処理および脱出時処理等)。
【0084】
利用段階では、業務オペレータが表示ボタンを押下した場合に、ローコード実行基盤が表示ボタンに割りついたロジックフローを実行する（図２５参照）。図２５の例では、Ｙｅｓ選択時には、ＡＰＩ呼出アクションに紐づけられたＡＰＩ（取引先取得処理）が実行され、取引先を取得して処理が終了し、これに対して、ＮＯ選択時には、終了アクションに飛びそのまま処理が終了する。
【0085】
［３－３．ビジネスルールについて］
本項目では、開発者によるビジネスルールの設定について、説明を行う。一般的な業務アプリケーションでは、同じ項目であっても、状況によって業務オペレータに入力させたい項目、あるいは、入力させたくない項目が動的に切り替わる場合が存在する。例えば、取引先マスタメンテ画面で、個人の取引先と、法人の取引先と両方と取引がある場合に、登録されている取引先が個人なのか法人なのか管理する必要がある。一般的に、法人である取引先には、法人番号を情報として管理するケースが多い。このため、取引先が法人の場合には法人番号を入力させ、個人の場合には入力させたくない(法人番号の入力欄をロックもしくは非表示にしたい)といった、項目の入力制御を動的に行いたいといったニーズが存在する。
本項目では、開発者によるビジネスルールの設定について、説明を行う。一般的な業務アプリケーションでは、同じ項目であっても、状況によって業務オペレータに入力させたい項目、あるいは、入力させたくない項目が動的に切り替わる場合が存在する。例えば、取引先マスタメンテ画面で、個人の取引先と、法人の取引先と両方と取引がある場合に、登録されている取引先が個人なのか法人なのか管理する必要がある。一般的に、法人である取引先には、法人番号を情報として管理するケースが多い。このため、取引先が法人の場合には法人番号を入力させ、個人の場合には入力させたくない(法人番号の入力欄をロックもしくは非表示にしたい)といった、項目の入力制御を動的に行いたいといったニーズが存在する。
【0086】
このような動的な画面制御を実現するために、まずは画面制御に必要な条件(以下、「コンディション」という)が何かを設定する必要がある。前段落で述べた例では、法人区分が１(個人)の場合には、図２６に示すように、法人番号をロックする必要がある。
【0087】
定義管理テーブルには、先述のアクション情報等に加えて、図２７に示すように、コンディション情報およびビジネスルール情報が格納される。コンディション情報およびビジネスルール情報の詳細については、以下の（１）および（２）を参照されたい。
【0088】
（１）コンディション情報（コンディション設定）
コンディション設定は、画面上の要素を左辺と右辺に値として設定し、比較のための等号(or不等号)を組み合わせることで、一つの式として構成される。式に設定する値の例としては、数値や文字列のような定数情報の他に、画面上のコントロールの値を設定することができる(どのような値を設定するかは、式ごとにタイプを指定できる)。式の左辺と右辺を比較し、比較結果が真(true)であれば、後述するビジネスルールに基づいて画面情報が更新される。コンディション開発画面例を図２８に示し、コンディション設定をする場合の定義管理テーブル例を図２９に示す。
コンディション設定は、画面上の要素を左辺と右辺に値として設定し、比較のための等号(or不等号)を組み合わせることで、一つの式として構成される。式に設定する値の例としては、数値や文字列のような定数情報の他に、画面上のコントロールの値を設定することができる(どのような値を設定するかは、式ごとにタイプを指定できる)。式の左辺と右辺を比較し、比較結果が真(true)であれば、後述するビジネスルールに基づいて画面情報が更新される。コンディション開発画面例を図２８に示し、コンディション設定をする場合の定義管理テーブル例を図２９に示す。
【0089】
また、一つのコンディション内には式やコンディションを複数含めることができ、それぞれの条件をＡＮＤ、ＯＲで結びつけることで、より複雑な条件指定を行うことが可能となる。式、コンディションを追加するためのボタンが用意されている。コンディション開発画面例を図３０に示し、コンディション情報の例を図３１に示し、コンディションが真となる場合の例を図３２に示す。
【0090】
（２）ビジネスルール情報（ビジネスルール設定）
ビジネスルールとは、設定されたコンディションが真である場合に、設定されたコントロールに対してどのような更新を動的に行うか、ルールを定めたものである。ビジネスルールのタイプとして、「ロック」、「非表示」または「必須」の３種類を選択でき、コンディションが真である場合に、設定されたコントロールがロック、非表示または必須状態になる。ビジネスルールの設定画面上では、縦軸にコントロール一覧、横軸にコンディション一覧をとるマトリクス表が表示され、セル上にチェックをつけることができる。開発者が、ビジネスルールのタイプ(コンディションを満たした際の処理)を指定し、マトリクス表にチェックをつけることで、設定が完了する。
ビジネスルールとは、設定されたコンディションが真である場合に、設定されたコントロールに対してどのような更新を動的に行うか、ルールを定めたものである。ビジネスルールのタイプとして、「ロック」、「非表示」または「必須」の３種類を選択でき、コンディションが真である場合に、設定されたコントロールがロック、非表示または必須状態になる。ビジネスルールの設定画面上では、縦軸にコントロール一覧、横軸にコンディション一覧をとるマトリクス表が表示され、セル上にチェックをつけることができる。開発者が、ビジネスルールのタイプ(コンディションを満たした際の処理)を指定し、マトリクス表にチェックをつけることで、設定が完了する。
【0091】
このようにローコード開発基盤では、複雑になりがちな動的な画面更新を、プログラミングなしで容易に設定できるため、設定の負荷や意図しないバグの発生を最小限に抑えることができる。ローコード開発基盤によるビジネスルール設定の特徴は、例えば、以下の４つである。
【0092】
特徴の１つ目として、値によって判定可能な動的な画面更新を、コンディションおよびビジネスルールの設定だけで完結させることができる。ロジックフローの設定で制御を実現しようとすると、設定が煩雑、かつ判定後に値を書き換えられてしまうとアクションの処理順によっては不具合を生む場合がある。
【0093】
特徴の２つ目として、コンディションとビジネスルールの分離により、複雑になりがちな設定をシンプルにすることができる。これは、条件と状態を定義内の別項目としてＤＢ上管理しているためである。
【0094】
特徴の３つ目として、ビジネスルールをマトリクス形式で設定できる。複雑なビジネスルール設定を一つの画面で行うことができる。
【0095】
特徴の４つ目として、マトリクス形式での設定に加えて、設定に必要な情報を以下の１～３に示すように確認しやすくすることで、大規模アプリケーションの開発においても、設定コストを最小限に抑えることができる。
１．コンディション(横軸)をクリックすることで、該当のコンディション設定画面に遷移することができる。
２．コントロール(縦軸)をクリックすることで、表示されているレイアウト画面がハイライト表示される。
３．レイアウト画面上のコントロールをクリックすることで、マトリクスの行が選択状態(フォーカス状態)となる。
１．コンディション(横軸)をクリックすることで、該当のコンディション設定画面に遷移することができる。
２．コントロール(縦軸)をクリックすることで、表示されているレイアウト画面がハイライト表示される。
３．レイアウト画面上のコントロールをクリックすることで、マトリクスの行が選択状態(フォーカス状態)となる。
【0096】
従来の大規模なアプリケーション画面では、コンディション、コントロールの数が膨大になり、設定作業の負荷がかかるという課題があったが、上記特徴１～４によりコンディションやレイアウトを確認しやすくすることで、その負荷を下げることができる。
【0097】
【0098】
このような設定の元、業務オペレータが、法人区分の値を１(個人)に変更すると、図３６に示すように、法人番号(テキスト)がロックされる。
【0099】
［３－４．継承について］
本項目では、開発者によるマスタページの継承に関する設定について、説明を行う。業務アプリケーションにおける各画面のテンプレートの役割を果たす画面を「マスタページ」という。登録処理および帳票の出力処理等、各画面の特性に合うマスタページを継承して利用することで、各画面での開発コストを下げることができる。例えば、［３－１］では、取引先を登録するための業務アプリケーションである取引先マスタメンテを例に、開発者が行う設定内容について説明した。一方で、それ以外のマスタメンテにおいても、取引先マスタメンテと同様に、業務オペレータが必要なマスタ情報を表示、追加、修正および削除するといった業務アプリケーションの用途は共通していると考えられる。このため、マスタメンテ画面に共通した機能(データの表示、追加、修正および削除)をまとめたマスタページを作成し、各マスタメンテではマスタメンテ画面用のマスタページを継承することで、各マスタメンテでの設定にかかるコストを下げることができる。
本項目では、開発者によるマスタページの継承に関する設定について、説明を行う。業務アプリケーションにおける各画面のテンプレートの役割を果たす画面を「マスタページ」という。登録処理および帳票の出力処理等、各画面の特性に合うマスタページを継承して利用することで、各画面での開発コストを下げることができる。例えば、［３－１］では、取引先を登録するための業務アプリケーションである取引先マスタメンテを例に、開発者が行う設定内容について説明した。一方で、それ以外のマスタメンテにおいても、取引先マスタメンテと同様に、業務オペレータが必要なマスタ情報を表示、追加、修正および削除するといった業務アプリケーションの用途は共通していると考えられる。このため、マスタメンテ画面に共通した機能(データの表示、追加、修正および削除)をまとめたマスタページを作成し、各マスタメンテではマスタメンテ画面用のマスタページを継承することで、各マスタメンテでの設定にかかるコストを下げることができる。
【0100】
マスタページでは、プレースホルダという、子画面側で設定を追加できる領域を設定することができる。マスタページ側で設定したプレースホルダに対して、マスタページを継承した子画面側で設定を追加していくことで、個別の設定を最小限にして、業務アプリケーションの開発を行うことができる。また、プレースホルダの設定されていない箇所に関しては、子画面側では変更ができないため、同一マスタページを継承している限りにおいて、各画面間で動作が統一される。結果として、品質を担保した開発を行うことができる。プレースホルダには、「１．レイアウト開発時に設定可能なプレースホルダ(コントロール)」と「２．ロジックフロー、アクション開発時に設定可能なプレースホルダ(アクション)」の２種類が存在する。
【0101】
まず、「１．レイアウト開発時に設定可能なプレースホルダ(コントロール)」について説明する。図３７は、マスタメンテ画面用のマスタページについてレイアウト設定を行った場合の画面例である。マスタページのレイアウト設定画面では、プレースホルダという特殊なコントロールを使用することができる。そして、図３８に示すように、マスタページを継承した子画面側では、継承するマスタページの指定を行う。指定したマスタページでプレースホルダが設定されている場合には、該当箇所に対して子画面側でコントロールを配置できる。コントロールの配置については、［３－２］を参照されたい。登録されるデータ上は、図３９に示すように、プレースホルダ上に配置した子画面のコントロールが、プレースホルダの子要素として登録される。
【0102】
次に、「２．ロジックフロー、アクション開発時に設定可能なプレースホルダ(アクション)」について説明する。図４０は、マスタメンテ画面用のマスタページについてロジックフロー、アクション設定を行った場合の画面例である。マスタページのロジックフロー設定画面では、プレースホルダという特殊なアクションを使用することができる。マスタページで設定されたロジックフローは、マスタページのフローとして一覧で表示される（編集不可)。マスタページで設定されたロジックフローにプレースホルダーアクションが含まれていれば、子画面側では自動的にプレースホルダーアクションに紐づくロジックフローが生成され、(子画面名)のフローとして一覧で表示される（編集可)。プレースホルダーアクションが実行されると、紐づけられた子画面側のロジックフローが再帰的に実行されるため、結果的に子画面側で必要な処理を設定できる。図４１～図４３を参照されたい。
【0103】
なお、図４２および図４３において点線の四角枠で囲んだ部分に関しては、以下の事項に留意されたい。すなわち、プレースホルダアクションが設定されたタイミングで、マスタページ側でロジックフローＩＤが採番される。子画面側ではこのロジックフローＩＤを使用してロジックフロー情報の登録を行う(継承先の子画面が複数あっても、共通してこのロジックフローＩＤが使用される)。
【0104】
［３－５．フローチャート］
［３－１］～［３－４］で説明した処理のフローチャートを、図４４～図４６に示す。図４４は、クライアントによるアプリケーション操作～該当アクションの終了アクション完了までのフローチャートである。図４５は、図４４のフローチャートで実行されるロジックフローに、プレースホルダーアクションが使用されていた場合のフローチャートである。図４６は、ビジネスルールの判定が完了するまでのフローチャートである。
［３－１］～［３－４］で説明した処理のフローチャートを、図４４～図４６に示す。図４４は、クライアントによるアプリケーション操作～該当アクションの終了アクション完了までのフローチャートである。図４５は、図４４のフローチャートで実行されるロジックフローに、プレースホルダーアクションが使用されていた場合のフローチャートである。図４６は、ビジネスルールの判定が完了するまでのフローチャートである。
【0105】
［４．事前設定］
本項目では、本実施形態に係る処理を行うために必要な事前設定について説明する。
本項目では、本実施形態に係る処理を行うために必要な事前設定について説明する。
【0106】
フォーカスセットアクションには、以下の２種類が存在する。
１．一つ目は、フォーカス可能な先頭項目にフォーカスをセットするアクション（先頭にフォーカスするアクション）である。
２．二つ目は、指定したコントロールより後ろのフォーカス可能な先頭項目にフォーカスをセットするアクション（次項目にフォーカスするアクション）である。
１．一つ目は、フォーカス可能な先頭項目にフォーカスをセットするアクション（先頭にフォーカスするアクション）である。
２．二つ目は、指定したコントロールより後ろのフォーカス可能な先頭項目にフォーカスをセットするアクション（次項目にフォーカスするアクション）である。
【0107】
以下、［４－１］において、先頭にフォーカスするアクションを行うために必要な事前設定について説明し、［４－２］において、次項目にフォーカスするアクションを行うために必要な事前設定について説明する。
【0108】
［４－１．先頭にフォーカスするアクションを行うために必要な事前設定］
図４８は、開始アクションと終了アクションの間に、「先頭にフォーカスアクション」を配置したロジックフローの例である。このロジックフローを実行すると、「先頭にフォーカスアクション」が実行される。
図４８は、開始アクションと終了アクションの間に、「先頭にフォーカスアクション」を配置したロジックフローの例である。このロジックフローを実行すると、「先頭にフォーカスアクション」が実行される。
【0109】
ローコード開発基盤で登録したコントロール情報は、図４９に示すように、定義管理テーブル内に先頭から順に登録される。そして、図５０に示すように、レイアウト開発画面内で、各コントロールに対して、識別名、必須か否か、および、フォーカスセット可能か否かの設定が行われる。
【0110】
このフォーカスセットの仕組みと継承を組み合わせることで、設定負荷を更に下げることができる。具体的には、図５１に示すように、マスタページ画面で、先頭にフォーカスアクションを使用したロジックフローを作成しておき、画面の起動イベントに割り付けておくことで、図５２に示すように、マスタページを継承する子画面側では、フォーカスセットの処理を書く必要がなく、汎用的なフォーカスセットを実現することができる。
【0111】
［４－２．次項目にフォーカスするアクションを行うために必要な事前設定］
図５３は、開始アクションと終了アクションの間に、「次項目にフォーカスアクション」を配置したロジックフローの例である。このロジックフローを実行すると、「次項目にフォーカスアクション」が実行される。「次項目にフォーカスアクション」では、編集画面で、基準となるコントロール（図５３では、「基準日テキスト」）を選択する。
図５３は、開始アクションと終了アクションの間に、「次項目にフォーカスアクション」を配置したロジックフローの例である。このロジックフローを実行すると、「次項目にフォーカスアクション」が実行される。「次項目にフォーカスアクション」では、編集画面で、基準となるコントロール（図５３では、「基準日テキスト」）を選択する。
【0112】
基準となるコントロールとして「基準日テキスト」が選択された場合、図５４に四角点線枠で囲んで示すように、「基準日テキスト」の次にフォーカスセット可能なコントロールである「取引先コードＦｒｏｍのテキスト」にフォーカスが当たることとなる。
【0113】
このフォーカスセットの仕組みと継承を組み合わせることで、設定負荷を更に下げることができる。図５５に示すように、マスタページ画面では、次項目にフォーカスアクションを使用したロジックフローを作成しておき、設定したコントロールの検証イベント等に割り付けておく。これにより、図５６および図５７に示すように、マスタページを継承する子画面側では、独自の実装が不要で、マスタページの基準日テキスト、および、基準日テキストの検証イベントに割りついたロジックフローをそのまま利用できる。この結果、子画面側では、プレースホルダにコントロールを配置するだけで、子画面側で設定を行うことなく汎用的なフォーカスセットを実現することができる。
【0114】
以上、［４－１］および［４－２］では、フォーカスセット可能なコントロールとセット不可のコントロールが混雑する状況下においてもフォーカスセット可能なコントロールを自動で判定するために必要な事前設定について説明した。また、継承の仕組みを併せて用いることで、フォーカスセットに必要な事前設定を大きく減らし、アプリケーションの利用者の利便性が高い仕組みを容易に開発することができる。
【0115】
［５．処理の具体例］
本項目では、本実施形態における処理の具体例を説明する。
本項目では、本実施形態における処理の具体例を説明する。
【0116】
以下、［５－１］において、本実施形態における処理のフローチャートを説明し、［５－２］において、コントロールの並び替え等について説明し、［５－３］において、ビジネスルールを考慮したフォーカス対象の決定について説明する。
【0117】
［５－１．本実施形態における処理のフローチャート］
本項目では、フォーカス対象を決定する流れを、図５８のフローチャートに沿って説明する。本フローにおけるポイントとしては、それぞれのコントロールがフォーカスセット可能かどうかは、以下のステップＳ９で説明するコントロールの種類による判定と、以下のステップＳ１０で説明するプロパティによる判定と、により主に決定される。
本項目では、フォーカス対象を決定する流れを、図５８のフローチャートに沿って説明する。本フローにおけるポイントとしては、それぞれのコントロールがフォーカスセット可能かどうかは、以下のステップＳ９で説明するコントロールの種類による判定と、以下のステップＳ１０で説明するプロパティによる判定と、により主に決定される。
【0118】
処理が開示されると（図５８のスタート）、まず、ロジックフローが実行される（図５８のステップＳ１）。ロジックフロー実行の処理の詳細は、［３－５］において図４４および図４５を用いて説明したとおりである。この時、フォーカスセットアクション実行時に、フラグを立てておく。１つのロジックフローに対して、複数のフラグを立てた場合は、後のアクションのフラグが優先される。
【0119】
次に、ビジネスルールによる更新が行われる（図５８のステップＳ２）。ビジネスルールによる更新の処理の詳細は、［３－５］において図４６を用いて説明したとおりである。ビジネスルールによる更新によって、コントロールのロック制御および表示制御等が反映された状態になる。
【0120】
次に、フォーカスアクションのフラグが立っているか否かが判定される（図５８のステップＳ３）。フォーカスアクションのフラグが立っていない場合（図５８のステップＳ３：Ｎｏ）、処理は終了する（図５８のエンド）。
【0121】
これに対して、フォーカスアクションのフラグが立っている場合（図５８のステップＳ３：Ｙｅｓ）、画面上のコントロールが、行プロパティ順および列プロパティ順に並び替えられる（図５８のステップＳ４）。なお、並び替えの詳細は、以下の［５－２］で説明する。
【0122】
次に、先頭にフォーカスセットするフラグと、次項目にフォーカスセットするフラグと、のどちらが設定されているかが判定される（図５８のステップＳ５）。先頭にフォーカスセットするフラグが設定されている場合（図５８のステップＳ５：先頭にフォーカスフラグの場合）、判定対象取得部１０２ａは、先頭のコントロールを取得し（図５８のステップＳ６）、次のステップＳ８に進む。これに対して、次項目にフォーカスセットするフラグが設定されている場合（図５８のステップＳ５：次項目にフォーカスフラグの場合）、判定対象取得部１０２ａは、基準コントロールとして設定されたコントロールの次のコントロールを取得し（図５８のステップＳ７）、次のステップＳ８に進む。
【0123】
そして、判定対象取得部１０２ａが取得したコントロールがフォーカス可能なコントロールであるか否かが、以下で説明するように、ループ処理により順に判定される（図５８のステップＳ８）。
【0124】
まず、コントロール種類判定部１０２ｂは、前述のステップＳ６またはステップＳ７で取得したコントロールが、フォーカスの設定が可能なコントロールの種類に該当するか該当しないかを判定する（図５８のステップＳ９）。
【0125】
具体的には、コントロール種類判定部１０２ｂは、定義管理テーブル１０６ａを参照して、判定中のコントロールが例えばテキストボックスである場合には、当該判定中のコントロールをフォーカスの設定が可能なコントロールの種類であると判定する（図５８のステップＳ９：Ｙｅｓ）。Ｙｅｓと判定された場合、次のステップＳ１０に進む。
【0126】
これに対して、コントロール種類判定部１０２ｂは、定義管理テーブル１０６ａを参照して、判定中のコントロールが例えばラベル等である場合には、当該判定中のコントロールをフォーカスの設定が不可能なコントロールの種類であると判定する（図５８のステップＳ９：Ｎｏ）。Ｎｏと判定された場合、ステップＳ８に戻り、判定対象取得部１０２ａは、定義管理テーブル１０６ａ中の次のコントロールを判定対象として取得する。
【0127】
次に、フォーカス可否判定部１０２ｃは、判定中のコントロールがフォーカスの設定が可能なコントロールに該当するか該当しないか、言い換えると、判定中のコントロールについての「フォーカスセット可能か」のプロパティが「ＴＲＵＥ」であるか否かを判定する（図５８のステップＳ１０）。
【0128】
具体的には、フォーカス可否判定部１０２ｃは、定義管理テーブル１０６ａを参照して、判定中のコントロールについての「フォーカスセット可能か」のプロパティが「ＴＲＵＥ」である場合には、当該判定中のコントロールをフォーカスの設定が可能なコントロールであると判定する（図５８のステップＳ１０：Ｙｅｓ）。Ｙｅｓと判定された場合、次のステップＳ１１に進む。
【0129】
これに対して、フォーカス可否判定部１０２ｃは、定義管理テーブル１０６ａを参照して、判定中のコントロールについての「フォーカスセット可能か」のプロパティが「ＦＡＬＳＥ」である場合には、当該判定中のコントロールをフォーカスの設定が不可能なコントロールであると判定する（図５８のステップＳ１０：Ｎｏ）。Ｎｏと判定された場合、ステップＳ８に戻り、判定対象取得部１０２ａは、定義管理テーブル１０６ａ中の次のコントロールを判定対象として取得する。
【0130】
次に、フォーカス不可状態判定部１０２ｄは、判定中のコントロールが、フォーカスの設定が不可能な状態（ロック状態または非表示状態）になっていないかを判定する（図５８のステップＳ１１）。
【0131】
具体的には、フォーカス不可状態判定部１０２ｄは、定義管理テーブル１０６ａを参照して、判定中のコントロールがロック状態または非表示状態ではない場合には、当該判定中のコントロールをフォーカスの設定が不可能な状態ではないと判定する（図５８のステップＳ１１：Ｙｅｓ）。Ｙｅｓと判定された場合、次のステップＳ１２に進む。
【0132】
これに対して、フォーカス不可状態判定部１０２ｄは、定義管理テーブル１０６ａを参照して、判定中のコントロールがロック状態または非表示状態である場合には、当該判定中のコントロールをフォーカスの設定が不可能な状態であると判定する（図５８のステップＳ１１：Ｎｏ）。Ｎｏと判定された場合、ステップＳ８に戻り、判定対象取得部１０２ａは、定義管理テーブル１０６ａ中の次のコントロールを判定対象として取得する。
【0133】
なお、ステップＳ１１で説明したようなビジネスルールを考慮したフォーカス対象の決定の詳細については、以下の［５－３］で説明する。
【0134】
最後に、フォーカス対象決定部１０２ｅは、フォーカス不可状態判定部１０２ｄでフォーカスの設定が不可能な状態ではないと判定（図５８のステップＳ１１：Ｙｅｓ）したコントロールを、フォーカスの対象として決定する（図５８のステップＳ１２）。
【0135】
以上により、フォーカス対象決定の処理が終了する（図５８のエンド）。
【0136】
［５－２．コントロールの並び替え等について］
本項目では、［５－１］のステップＳ４で述べたコントロールの並び替えについての詳細を説明する。また、並び替えたコントロールに基づくフォーカス対象の決定の仕方についても説明する。
本項目では、［５－１］のステップＳ４で述べたコントロールの並び替えについての詳細を説明する。また、並び替えたコントロールに基づくフォーカス対象の決定の仕方についても説明する。
【0137】
（１）コントロールの並び替えについて
図５９に示すように、一つの画面上にコントロールが複数存在する場合、各コントロールの前後関係を明確にしなければ、フォーカスセットの判定ができない。ローコード開発基盤では、コントロールを配置した場合に、それぞれのコントロールに対して、行と列のプロパティ情報が付与されているため、この情報を利用して、コントロールの並び替えを行う。
図５９に示すように、一つの画面上にコントロールが複数存在する場合、各コントロールの前後関係を明確にしなければ、フォーカスセットの判定ができない。ローコード開発基盤では、コントロールを配置した場合に、それぞれのコントロールに対して、行と列のプロパティ情報が付与されているため、この情報を利用して、コントロールの並び替えを行う。
【0138】
【0139】
そして、行番号がより若いコントロールから順に、行番号が同じ場合には列番号がより若いコントロールから順に、定義管理テーブル１０６ａにコントロールが登録される。図５９～図６１の画面例のコントロールでいえば、項目Ａのラベル、項目Ａのテキストボックス、項目Ｂのラベル、項目Ｂのテキストボックス、項目Ｃのラベルおよび項目Ｃのテキストボックスという順序で、定義管理テーブル１０６ａにコントロールが登録される。
【0140】
ここで、「先頭にフォーカスアクション」の場合、図５９～図６１の画面例において、どの項目がフォーカス対象となるかを説明する。（行番号：０、列番号：０）のコントロールはラベル（項目Ａのラベル）なので、フォーカス不可である。これに対して、（行番号：０、列番号：１）のコントロールはテキストボックス（項目Ａのテキストボックス）なので、フォーカス可能(フォーカス対象)である。
【0141】
また、「（行番号：０、列番号：３）のコントロール（項目Ｂのテキストボックス）の次項目にフォーカスアクション」の場合、図５９～図６１の画面例において、どの項目がフォーカス対象となるかを説明する。次項目である（行番号：１、列番号：０）のコントロールはラベル（項目Ｃのラベル）なので、フォーカス不可である。これに対して、（行番号：１、列番号：１）のコントロールはテキストボックス（項目Ｃのテキストボックス）なので、フォーカス可能(フォーカス対象)である。
【0142】
［５－３．ビジネスルールを考慮したフォーカス対象の決定について］
本項目では、［５－１］のステップＳ１１で述べたビジネスルールを考慮したフォーカス対象の決定についての詳細を説明する。
本項目では、［５－１］のステップＳ１１で述べたビジネスルールを考慮したフォーカス対象の決定についての詳細を説明する。
【0143】
［３－３］で説明したビジネスルールの仕組みを用いることで、画面上のコントロールに対して、ロック、非表示および必須状態を動的に切り替えることが可能となる。ビジネスルールによる更新の結果、ロジックフローの実行前にはフォーカスセットが可能であった項目が、ロックまたは非表示状態になり、フォーカスセットができない可能性がある。このため、本実施形態においては、フォーカスアクション実行時にフォーカス先を即時反映するのではなく、［５－１］で説明したように、ビジネスルールの反映後にフォーカス対象の決定を行うようにしている。
【0144】
一例として、図６２に示すように、項目Ａがビジネスルールでロック状態であり、かつ、「先頭にフォーカスアクション」の設定の場合、先頭の項目である項目Ａがロック状態でありフォーカスセットできないため、項目Ｂにフォーカスがセットされる。
【0145】
別の例として、図６３に示すように、項目Ｂがビジネスルールでロック状態であり、かつ、「項目Ａの次項目にフォーカスアクション」の設定の場合、項目Ａの次項目である項目Ｂがロック状態でありフォーカスセットできないため、項目Ｃにフォーカスがセットされる。
【0146】
このようなビジネスルールの判定を考慮した制御を行うために、フォーカスアクション実行時には、［５－１］で説明したように、フラグのみを立てておき、実際のフォーカスセットの処理自体はビジネスルールの更新後に行う。このフラグによる仕組みによって、開発者は、ロジックフロー内のどの部分に「先頭にフォーカスアクション」をセットしたとしても、最終的なビジネスルールの更新結果を考慮した先頭項目にフォーカスをセットすることができる。言い換えると、先頭にフォーカスアクションを実行後に、画面上の値を変更しても、結果が変わらないので自由度の高いロジックフロー設定が可能である。
【0147】
［６．本実施形態のまとめ］
以上説明してきたように、本実施形態に係るフォーカス対象決定装置１００によれば、画面上のどの項目（コントロール）をフォーカスの対象とするかを自動で決定することができる。これにより、開発者が複雑なフォーカス制御を手動で行わずに済むようになる。
以上説明してきたように、本実施形態に係るフォーカス対象決定装置１００によれば、画面上のどの項目（コントロール）をフォーカスの対象とするかを自動で決定することができる。これにより、開発者が複雑なフォーカス制御を手動で行わずに済むようになる。
【0148】
また、本実施形態に係るフォーカス対象決定装置１００によれば、ビジネスルールによりコントロールの状態が動的に変化する場合においても、当該変化後のコントロールの状態を考慮した上で、画面上のどの項目（コントロール）をフォーカスの対象とするかを自動で決定することができる。
【0149】
ここで、従来においては、フォーカスの制御をプログラミングにより行っており、開発者がパターンごとにフォーカス先の画面項目を正確に把握していなければ、システム構築を行うことが難しかった。この結果、複雑なフォーカス制御の場合は、設定やテストにかかるコストが増加するという問題があった。また、複雑なプログラミングを行う場合、不具合を生む可能性が増加するため、ユーザの満足度が低下してしまうというリスクが高まるという問題もあった。
【0150】
そこで、本実施形態においては、例えば、画面上のコントロールの中から、フォーカス可能なコントロールを自動判定できるようにした。
【0151】
これにより、複雑化しがちなフォーカス制御の設定が簡単になった。また、フォーカス制御は、ほぼ全てのシステム画面で必要な設定であるため、フォーカス設定を簡素化することができる本実施形態の仕組みは、設定やテストにかかる工数を低下させ、システムの早期稼働に貢献することができる。そして、フォーカス制御の設定が簡単になったことで、システムの不具合を最小限に抑えることができるため、ユーザの満足度を高める効果も期待できる。
【0152】
［７．国連が主導する持続可能な開発目標（ＳＤＧｓ）への貢献］
本実施形態により、業務効率化や企業の適切な経営判断を推進することに寄与することができるので、ＳＤＧｓの目標８及び９に貢献することが可能となる。
本実施形態により、業務効率化や企業の適切な経営判断を推進することに寄与することができるので、ＳＤＧｓの目標８及び９に貢献することが可能となる。
【0153】
また、本実施形態により、廃棄ロス削減や、ペーパレス・電子化を推進することに寄与することができるので、ＳＤＧｓの目標１２、１３及び１５に貢献することが可能となる。
【0154】
また、本実施形態により、統制、ガバナンス強化に寄与することができるので、ＳＤＧｓの目標１６に貢献することが可能となる。
【0155】
［８．他の実施形態］
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。
【0156】
例えば、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。
【0157】
また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。
【0158】
また、フォーカス対象決定装置１００に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。
【0159】
例えば、フォーカス対象決定装置１００が備える処理機能、特に制御部にて行われる各処理機能については、その全部または任意の一部を、ＣＰＵおよび当該ＣＰＵにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。尚、プログラムは、本実施形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じてフォーカス対象決定装置１００に機械的に読み取られる。すなわち、ＲＯＭまたはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶部などには、ＯＳと協働してＣＰＵに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、ＲＡＭにロードされることによって実行され、ＣＰＵと協働して制御部を構成する。
【0160】
また、このコンピュータプログラムは、フォーカス対象決定装置１００に対して任意のネットワークを介して接続されたアプリケーションプログラムサーバに記憶されていてもよく、必要に応じてその全部または一部をダウンロードすることも可能である。
【0161】
また、本実施形態で説明した処理を実行するためのプログラムを、一時的でないコンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カード、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（登録商標）（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔｏ－Ｏｐｔｉｃａｌ ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、および、Ｂｌｕ－ｒａｙ（登録商標） Ｄｉｓｃ等の任意の「可搬用の物理媒体」を含むものとする。
【0162】
また、「プログラム」とは、任意の言語または記述方法にて記述されたデータ処理方法であり、ソースコードまたはバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、ＯＳに代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施形態に示した各装置において記録媒体を読み取るための具体的な構成および読み取り手順ならびに読み取り後のインストール手順等については、周知の構成や手順を用いることができる。
【0163】
記憶部に格納される各種のデータベース等は、ＲＡＭ、ＲＯＭ等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、および、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、および、ウェブページ用ファイル等を格納する。
【0164】
また、フォーカス対象決定装置１００は、既知のパーソナルコンピュータまたはワークステーション等の情報処理装置として構成してもよく、また、任意の周辺装置が接続された当該情報処理装置として構成してもよい。また、フォーカス対象決定装置１００は、当該装置に本実施形態で説明した処理を実現させるソフトウェア（プログラムまたはデータ等を含む）を実装することにより実現してもよい。
【0165】
更に、装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じてまたは機能負荷に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。
【産業上の利用可能性】
【0166】
本発明は、例えば、画面の開発を行う分野において有用である。
【符号の説明】
【0167】
１００ フォーカス対象決定装置
１０２ 制御部
１０２ａ 判定対象取得部
１０２ｂ コントロール種類判定部
１０２ｃ フォーカス可否判定部
１０２ｄ フォーカス不可状態判定部
１０２ｅ フォーカス対象決定部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ 定義管理テーブル
１０８ 入出力インターフェース部
１１２ 入力装置
１１４ 出力装置
２００ サーバ
３００ ネットワーク
１０２ 制御部
１０２ａ 判定対象取得部
１０２ｂ コントロール種類判定部
１０２ｃ フォーカス可否判定部
１０２ｄ フォーカス不可状態判定部
１０２ｅ フォーカス対象決定部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ 定義管理テーブル
１０８ 入出力インターフェース部
１１２ 入力装置
１１４ 出力装置
２００ サーバ
３００ ネットワーク
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図40】
【図41】
【図42】
【図43】
【図44】
【図45】
【図46】
【図47】
【図48】
【図49】
【図50】
【図51】
【図52】
【図53】
【図54】
【図55】
【図56】
【図57】
【図58】
【図59】
【図60】
【図61】
【図62】
【図63】