JP2008287642A - ソフトウェアの入出力情報及び保持情報の検証システム - Google Patents
ソフトウェアの入出力情報及び保持情報の検証システム Download PDFInfo
- Publication number
- JP2008287642A JP2008287642A JP2007134015A JP2007134015A JP2008287642A JP 2008287642 A JP2008287642 A JP 2008287642A JP 2007134015 A JP2007134015 A JP 2007134015A JP 2007134015 A JP2007134015 A JP 2007134015A JP 2008287642 A JP2008287642 A JP 2008287642A
- Authority
- JP
- Japan
- Prior art keywords
- information
- input
- component
- processing
- software
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
Abstract
【課題】 １つ以上の業務処理を行うコンポーネントで入力情報や出力情報や保持情報の過不足を容易に検証すること。
【解決手段】 開発されたソフトウェアのソースコード及び画面遷移情報を記憶手段から取得し、取得したソースコードからエンドユーザが入力すべき入力情報を解析すると共に、前記画面遷移情報から画面遷移を解析し、さらに前記入力情報に対して業務処理を行う複数のコンポーネントが入出力する入出力情報及び内部記憶手段の保持情報を画面遷移に従って解析する第１の手段と、前記第１の手段による解析結果の情報に基づき、各コンポーネントの処理タイミングにおいて各コンポーネントが必要とする入出力情報及び内部の保持情報に過不足がないかどうかを画面遷移に従って検証し、その検証結果を出力する第２の手段とを備える。
【選択図】 図１
【解決手段】 開発されたソフトウェアのソースコード及び画面遷移情報を記憶手段から取得し、取得したソースコードからエンドユーザが入力すべき入力情報を解析すると共に、前記画面遷移情報から画面遷移を解析し、さらに前記入力情報に対して業務処理を行う複数のコンポーネントが入出力する入出力情報及び内部記憶手段の保持情報を画面遷移に従って解析する第１の手段と、前記第１の手段による解析結果の情報に基づき、各コンポーネントの処理タイミングにおいて各コンポーネントが必要とする入出力情報及び内部の保持情報に過不足がないかどうかを画面遷移に従って検証し、その検証結果を出力する第２の手段とを備える。
【選択図】 図１
Description
本発明は、ソフトウェア開発において、開発したソフトウェアを使用するエンドユーザが入力する情報、当該ソフトウェアの処理結果である出力情報と、ソフトウェアがシステム的に保持する保持情報について、業務処理を行う1つ以上のコンポーネントの入力情報や出力情報の連携を加味した上で、過不足があるかどうかを検証するシステムに関する。
ソフトウェア開発を行う企業は、開発費用を抑えるために、日本国内の企業に限らず、人件費の安価な外国企業へ開発を委託すること(オフショア開発)も一般的に行っている。当然のことながら、外国企業には、日本国内で開発するソフトウェアの一部分を切り出して委託する。
外国企業に委託するソフトウェアは、開発が容易である、ソフトウェアの他の部分と情報連携が少ないユーティリティ的、または単機能な部分も委託発注するが、委託する量が増えるにつれて、利用時に当該ソフトウェアを使用するエンドユーザがおり、エンドユーザがソフトウェアに対して情報を入力する、というソフトウェアも発注することある。
外国企業に委託するソフトウェアは、開発が容易である、ソフトウェアの他の部分と情報連携が少ないユーティリティ的、または単機能な部分も委託発注するが、委託する量が増えるにつれて、利用時に当該ソフトウェアを使用するエンドユーザがおり、エンドユーザがソフトウェアに対して情報を入力する、というソフトウェアも発注することある。
後者のソフトウェアは、エンドユーザが入力した情報をもとに、処理を行って出力結果とする。また、このソフトウェアは、エンドユーザの入力作業の省略を目的としたり、ソフトウェアの内部的な処理で必要な情報を保持情報とすることも多い。
例えば、クライアント/サーバ形式のシステムでは、この保持情報をサーバで保持する作り方がある。ソフトウェアが正常に動作するためには、これらの情報が業務処理を行うプログラムに達する前に用意されていることや、業務処理時に正しく取得できる状態になっている必要があり、それらを検証する作業が必要である。そのための技術として、例えば特許文献１のような方法が提案されている。
例えば、クライアント/サーバ形式のシステムでは、この保持情報をサーバで保持する作り方がある。ソフトウェアが正常に動作するためには、これらの情報が業務処理を行うプログラムに達する前に用意されていることや、業務処理時に正しく取得できる状態になっている必要があり、それらを検証する作業が必要である。そのための技術として、例えば特許文献１のような方法が提案されている。
しかしながら、特許文献１に開示された方法にあっては、ソフトウェアがサーバで処理に使用する情報の検証はできるが、エンドユーザ(クライアント)からの入力と関連性については考えられていない。そのため、サーバにある情報検証には有効であるが、ソフトウェアとしての正常に動作するための情報を管理するという点では不十分である。このため、顧客要求に応じた業務処理を実現するための必須な条件の一つである、業務処理で使用する情報の入力や出力について過不足の無いソフトウェアを提供することができないという問題がある。
加えて、一般的なソフトウェア開発では、品質向上、生産性向上、可読性向上、後のエンハンス時の開発効率向上などのために、設計やコーディングには、各コンポーネントの役割や、名前の付け方などの開発ルールを定めて行う。
開発ルールに従い、顧客要求に応じた業務処理を実現するプログラムを開発者が行うということは、フレームワークを適用する/しないに関わらず、重要なことである。
そのとき、同様のソフトウェアの開発するたびにルールを定めることは無駄なことや、開発ルールを習得する時間がかかるため、既存のフレームワークを適用して、そのフレームワークの設計方針やコーディング、名前付けルールなどに従うという開発ルールを作成することもある。
開発ルールに従い、顧客要求に応じた業務処理を実現するプログラムを開発者が行うということは、フレームワークを適用する/しないに関わらず、重要なことである。
そのとき、同様のソフトウェアの開発するたびにルールを定めることは無駄なことや、開発ルールを習得する時間がかかるため、既存のフレームワークを適用して、そのフレームワークの設計方針やコーディング、名前付けルールなどに従うという開発ルールを作成することもある。
また一般的に、大規模システムでは、当該システムの一部分を開発ルールとともに他社へ委託開発を発注する。そして、納品物であるソフトウェアの検収を行うのは発注者の責務である。検収内容としてはソフトウェアが正常に動作することはもちろんであるが、ソースコードが開発ルールに従って記述されていることも確認する必要がある。
また一般的に、ソフトウェア開発では、仕様を作成する人間と、ソフトウェアを作成する人間とが異なることが多い。先に説明したオフショア開発もその一例である。また、開発の最中に仕様の変更が行われることもよくある。そのため、発注者は、委託先が納品したソフトウェアが、顧客が要求する仕様通りに動作することを確認しなければならない。
また一般的に、ソフトウェア開発では、仕様を作成する人間と、ソフトウェアを作成する人間とが異なることが多い。先に説明したオフショア開発もその一例である。また、開発の最中に仕様の変更が行われることもよくある。そのため、発注者は、委託先が納品したソフトウェアが、顧客が要求する仕様通りに動作することを確認しなければならない。
しかしながら、委託開発、とりわけ、オフショア開発は、言語の違いや文化の違い、遠距離等のコミュニケーションの失敗要因が多く、仕様変更の内容が伝わらず、納品物としてのソフトウェアが、顧客が要求する仕様通りに動作しないという問題が発生し易い開発形態であるという問題がある。
そこで、納品物としてのソフトウェアが、顧客が要求する仕様通りに動作するかを検証する(テストする)方法の一つとして、ソフトウェアを動作させる方法がある。
しかし、この方法では、テストのための準備として、ハードウェアやソフトウェアの手配、ソフトウェアのインストールや設定などの工数や、テストのマシンや、最終的なテストをするために、発注企業の担当者が使用する開発マシンなどの準備費用や、さらには、ハードウェアやそれらマシンにインストールするソフトウェアをレンタル会社等から借りるときは、リース代金などの費用がテストをする期間中ずっと必要である。
また、テストを行い正常動作しないときは、プログラムの修正をして、またテストを行うということを繰り返す必要がある。テスト時の確認は顧客の仕様を基にするため、何度も顧客の仕様との比較する作業をしていることになり、多くの時間と費用が必要なことは明白である。
そこで、納品物としてのソフトウェアが、顧客が要求する仕様通りに動作するかを検証する(テストする)方法の一つとして、ソフトウェアを動作させる方法がある。
しかし、この方法では、テストのための準備として、ハードウェアやソフトウェアの手配、ソフトウェアのインストールや設定などの工数や、テストのマシンや、最終的なテストをするために、発注企業の担当者が使用する開発マシンなどの準備費用や、さらには、ハードウェアやそれらマシンにインストールするソフトウェアをレンタル会社等から借りるときは、リース代金などの費用がテストをする期間中ずっと必要である。
また、テストを行い正常動作しないときは、プログラムの修正をして、またテストを行うということを繰り返す必要がある。テスト時の確認は顧客の仕様を基にするため、何度も顧客の仕様との比較する作業をしていることになり、多くの時間と費用が必要なことは明白である。
本発明は以上のような事情に鑑みなされたものであり、その目的は、開発ルールに従って開発されたソフトウェアを対象に、業務処理をするためのエンドユーザの入力情報、処理結果である出力情報、サーバなどで保持する保持情報を調べ、複数の業務処理の連携を加味した上で、１つ以上の業務処理を行うコンポーネントで入力情報や出力情報や保持情報の過不足を容易に検証することを可能にする入出力情報及び保持情報の検証システムを提供することにある。
上記課題を解決するため、本発明に係る検証システムは、開発されたソフトウェアで使用する入力情報、出力情報及び内部の保持情報の過不足を検証する入出力情報及び保持情報の検証システムであって、
開発されたソフトウェアのソースコード及び画面遷移情報を記憶手段から取得し、取得したソースコードからエンドユーザが入力すべき入力情報を解析すると共に、前記画面遷移情報から画面遷移を解析し、さらに前記入力情報に対して業務処理を行う複数のコンポーネントが入出力する入出力情報及び内部記憶手段の保持情報を画面遷移に従って解析する第１の手段と、前記第１の手段による解析結果の情報に基づき、各コンポーネントの処理タイミングにおいて各コンポーネントが必要とする入出力情報及び内部の保持情報に過不足がないかどうかを画面遷移に従って検証し、その検証結果を出力する第２の手段とを備えることを特徴とする。
また、前記第１の手段は、ソースコード中に記述されている入力情報の取得元や取得方法により、各コンポーネントが入力する情報が、エンドユーザによって入力される情報であるか、内部記憶手段の保持情報であるかを解析することを特徴とする。
また、前記第１の手段は、ソースコード中に記述されている各コンポーネントの出力情報の設定先や設定方法により、各コンポーネントの出力情報が内部記憶手段の保持情報になるか否かを解析することを特徴とする。
開発されたソフトウェアのソースコード及び画面遷移情報を記憶手段から取得し、取得したソースコードからエンドユーザが入力すべき入力情報を解析すると共に、前記画面遷移情報から画面遷移を解析し、さらに前記入力情報に対して業務処理を行う複数のコンポーネントが入出力する入出力情報及び内部記憶手段の保持情報を画面遷移に従って解析する第１の手段と、前記第１の手段による解析結果の情報に基づき、各コンポーネントの処理タイミングにおいて各コンポーネントが必要とする入出力情報及び内部の保持情報に過不足がないかどうかを画面遷移に従って検証し、その検証結果を出力する第２の手段とを備えることを特徴とする。
また、前記第１の手段は、ソースコード中に記述されている入力情報の取得元や取得方法により、各コンポーネントが入力する情報が、エンドユーザによって入力される情報であるか、内部記憶手段の保持情報であるかを解析することを特徴とする。
また、前記第１の手段は、ソースコード中に記述されている各コンポーネントの出力情報の設定先や設定方法により、各コンポーネントの出力情報が内部記憶手段の保持情報になるか否かを解析することを特徴とする。
本発明によれば、エンドユーザが入力する入力情報と、業務処理の結果である出力情報と、業務処理に使用するがエンドユーザに入力を求めない保持情報が過不足なく、正確なタイミングに実装されているかどうかを検証し易くできる。
また、ソフトウェアが動作する根本を成すソースコードを直接入力にしていることで、実際のソフトウェアの挙動を、実際に動作させることなく確認することができる。そのため、プログラム的な間違い、また仕様的な間違いを早期に見つけることができ、ソフトウェアの品質が向上する。
また、何度も同じ確認作業をするという検証作業にかかる工数を削減することができるため、生産性の向上を期待できる。
また、仕様の変更やエンハンス時に使用することで、ソフトウェア全体での情報がどのように利用されるのか、業務的な処理を容易に把握することができ、ソフトウェア解析をする工数を削減することができる。
また、納入されたソフトウェアが仮に顧客要求通りに動作するとしても、そのソースコードが開発ルールに従っていないときは、本発明は情報を取得しないので、開発ルール違反を速やかに見つけることができ、納品物のソースコード品質を維持することもできる。
また、ソフトウェアが動作する根本を成すソースコードを直接入力にしていることで、実際のソフトウェアの挙動を、実際に動作させることなく確認することができる。そのため、プログラム的な間違い、また仕様的な間違いを早期に見つけることができ、ソフトウェアの品質が向上する。
また、何度も同じ確認作業をするという検証作業にかかる工数を削減することができるため、生産性の向上を期待できる。
また、仕様の変更やエンハンス時に使用することで、ソフトウェア全体での情報がどのように利用されるのか、業務的な処理を容易に把握することができ、ソフトウェア解析をする工数を削減することができる。
また、納入されたソフトウェアが仮に顧客要求通りに動作するとしても、そのソースコードが開発ルールに従っていないときは、本発明は情報を取得しないので、開発ルール違反を速やかに見つけることができ、納品物のソースコード品質を維持することもできる。
まず、本発明が解決したい事柄を具体例で説明した後、本発明の具体的な実施の形態を図面を参照して説明する。
まず、図１を用いて、本発明が対象とするソフトウェアの構成の説明をする。
本発明が対象とするソフトウェア１０１は、エンドユーザ１０２が操作する部分(例えば、クライアント)１０３と、処理を行う部分(例えば、サーバ)１０４がある。上記の役割が分かれていれば、同一のソフトウェアになっていてもよいし、ネットワークを介するような構成でもよい。
例えば、エンドユーザ１０２は、クライアント１０３を構成するログイン画面１０５に対して、ユーザIDやパスワード１０６の情報を入力する。すると、処理を行う部分１０４は認証処理部分１０７で具体的な処理を行う。この例では、ログイン画面１０５が、エンドユーザ１０２が操作する部分(クライアント)であり、認証処理部分１０７が処理を行う部分(サーバ)である。
まず、図１を用いて、本発明が対象とするソフトウェアの構成の説明をする。
本発明が対象とするソフトウェア１０１は、エンドユーザ１０２が操作する部分(例えば、クライアント)１０３と、処理を行う部分(例えば、サーバ)１０４がある。上記の役割が分かれていれば、同一のソフトウェアになっていてもよいし、ネットワークを介するような構成でもよい。
例えば、エンドユーザ１０２は、クライアント１０３を構成するログイン画面１０５に対して、ユーザIDやパスワード１０６の情報を入力する。すると、処理を行う部分１０４は認証処理部分１０７で具体的な処理を行う。この例では、ログイン画面１０５が、エンドユーザ１０２が操作する部分(クライアント)であり、認証処理部分１０７が処理を行う部分(サーバ)である。
次に、図１のソフトウェア１０１の動作を説明し、本発明が解決する事柄を説明する。
まず、当該ソフトウェア１０１には、ログイン画面１０５、検索条件入力画面１０８、検索結果表示画面１０９がある。
第１に、エンドユーザ１０２は、ログイン画面１０５で、ユーザIDとパスワード１０６の情報を入力する。
すると、ソフトウェアの処理としては、ユーザIDとパスワード１０６を入力として、認証処理部分１０７が認証処理を行う。また、認証結果１１０を他の処理でも使用することを想定して、例えば、複数の業務処理で共通に使用する情報を保持する領域１１１に保存する。その後、ソフトウェア１０１は、検索条件入力画面１０８を表示する。
第２に、エンドユーザ１０２は、検索条件入力画面１０８に対して検索条件１１２を入力する。
すると、ソフトウェア１０１は、検索処理部分１１３で検索処理を行う。このとき、認証されているエンドユーザであれば、検索を行うという仕様と想定すると、検証条件ともに、先の認証結果を使用する必要がある。検索処理が終了したならば、処理の結果として検索結果１１４を検索結果出力画面１０９に表示する動作を行う。
まず、当該ソフトウェア１０１には、ログイン画面１０５、検索条件入力画面１０８、検索結果表示画面１０９がある。
第１に、エンドユーザ１０２は、ログイン画面１０５で、ユーザIDとパスワード１０６の情報を入力する。
すると、ソフトウェアの処理としては、ユーザIDとパスワード１０６を入力として、認証処理部分１０７が認証処理を行う。また、認証結果１１０を他の処理でも使用することを想定して、例えば、複数の業務処理で共通に使用する情報を保持する領域１１１に保存する。その後、ソフトウェア１０１は、検索条件入力画面１０８を表示する。
第２に、エンドユーザ１０２は、検索条件入力画面１０８に対して検索条件１１２を入力する。
すると、ソフトウェア１０１は、検索処理部分１１３で検索処理を行う。このとき、認証されているエンドユーザであれば、検索を行うという仕様と想定すると、検証条件ともに、先の認証結果を使用する必要がある。検索処理が終了したならば、処理の結果として検索結果１１４を検索結果出力画面１０９に表示する動作を行う。
上記のようなソフトウェア１０１では、サーバの処理(図１では、認証処理部分１０７や検索処理部分１１３には、（１）クライアントから送られてくる情報(図１では、ユーザID)を必要なときに取得するプログラムがなされていることや、（２）サーバに保持されている情報(図１では、例えば認証結果１１０)を必要なときに取得するプログラムが正確に書かれていることや、（３）処理結果をクライアントに返す処理(図１では、例えば検索結果１１４)が必要なだけ正確にプログラムされていることや、（４）サーバで保持しておく情報(図１では、認証結果１１０)が、必要なときに正確にサーバに保持するようにプログラムされている必要があることは明白である。
また、複数の画面を使用するソフトウェアのときは、複数の業務処理で使用する情報は、その情報を使用するタイミングで正確に取得する必要があるため、処理の流れ(図１では、ログイン処理→検索条件入力→検索結果表示)も十分加味しなければならない。
本発明は、このサーバで行われる処理で上記（１）、（２）、（３）、（４）と、処理の流れと同様の意味を持つ画面遷移にも着目して、入力情報と出力情報と業務処理がプログラムとして過不足なく実装されていることを、容易に確認するための手段を提供することである。
また、複数の画面を使用するソフトウェアのときは、複数の業務処理で使用する情報は、その情報を使用するタイミングで正確に取得する必要があるため、処理の流れ(図１では、ログイン処理→検索条件入力→検索結果表示)も十分加味しなければならない。
本発明は、このサーバで行われる処理で上記（１）、（２）、（３）、（４）と、処理の流れと同様の意味を持つ画面遷移にも着目して、入力情報と出力情報と業務処理がプログラムとして過不足なく実装されていることを、容易に確認するための手段を提供することである。
以下、本発明の一実施の形態で情報の検証システムを図面に基づき説明する。
図２は、本発明の実施の形態を示すシステム構成図である。
本発明に係る入出力情報及び保持情報の検証システム２０１は、ソース情報取得手段２０２、遷移情報取得手段２０３、検証処理実行手段２０４、結果表示手段２０５から構成されている。
さらに、当該ソフトウェアを構成するソースコードと当該ソフトウェアの画面遷移情報の定義を格納する開発対象格納手段２０６を備え、ソースファイル２０７と遷移情報２０８を保存する。
また、本発明の処理に必要な情報を保持するため、開発対象格納手段２０６に保存されているソースファイル２０７と遷移情報２０８を解析した結果を保持する領域として、エンドユーザ入力情報テーブル２０９と、業務処理情報テーブル２１０と、遷移情報テーブル２１１を備える。
図２は、本発明の実施の形態を示すシステム構成図である。
本発明に係る入出力情報及び保持情報の検証システム２０１は、ソース情報取得手段２０２、遷移情報取得手段２０３、検証処理実行手段２０４、結果表示手段２０５から構成されている。
さらに、当該ソフトウェアを構成するソースコードと当該ソフトウェアの画面遷移情報の定義を格納する開発対象格納手段２０６を備え、ソースファイル２０７と遷移情報２０８を保存する。
また、本発明の処理に必要な情報を保持するため、開発対象格納手段２０６に保存されているソースファイル２０７と遷移情報２０８を解析した結果を保持する領域として、エンドユーザ入力情報テーブル２０９と、業務処理情報テーブル２１０と、遷移情報テーブル２１１を備える。
ソース情報取得手段２０２は、当該ソフトウェアを構成するソースコードを入力として、解析し、本発明に必要なエンドユーザ情報テーブル２０９と、業務処理情報テーブル２１０を生成する役割を持つ。
遷移情報取得手段２０３は、当該ソフトウェアの画面遷移情報を入力として、解析し、本発明に必要な遷移情報テーブル２１１を生成する役割を持つ。
検証処理実行手段２０４は、上記ソース情報取得手段２０２が生成したエンドユーザ情報テーブル２０９と、業務処理情報テーブル２１０と、上記遷移情報取得手段２０３が生成した遷移情報テーブル２１１を入力として、業務処理で使用する入力情報や業務処理の結果である出力情報、また保持情報が、プログラム中で適切なタイミングで取得されたり設定されたりしているかの検証を行い、検証結果を生成する役割を持つ。
結果表示手段２０５は、上記検証処理実行手段２０４による検証結果２１２を表示する役割を持つ。
なお、図２に示す検証システム２０１は、ＣＰＵ、メモリ、キーボードなどの入力装置、ディスプレイ等の出力装置、ハードディスクで構成される外部記憶装置などで構成されるコンピュータシステムを用いて実現されるものである。ソース情報取得手段２０２、遷移情報取得手段２０３、検証処理実行手段２０４、結果表示手段２０５は、メモリに格納されたプログラムによって実現されるものである。
遷移情報取得手段２０３は、当該ソフトウェアの画面遷移情報を入力として、解析し、本発明に必要な遷移情報テーブル２１１を生成する役割を持つ。
検証処理実行手段２０４は、上記ソース情報取得手段２０２が生成したエンドユーザ情報テーブル２０９と、業務処理情報テーブル２１０と、上記遷移情報取得手段２０３が生成した遷移情報テーブル２１１を入力として、業務処理で使用する入力情報や業務処理の結果である出力情報、また保持情報が、プログラム中で適切なタイミングで取得されたり設定されたりしているかの検証を行い、検証結果を生成する役割を持つ。
結果表示手段２０５は、上記検証処理実行手段２０４による検証結果２１２を表示する役割を持つ。
なお、図２に示す検証システム２０１は、ＣＰＵ、メモリ、キーボードなどの入力装置、ディスプレイ等の出力装置、ハードディスクで構成される外部記憶装置などで構成されるコンピュータシステムを用いて実現されるものである。ソース情報取得手段２０２、遷移情報取得手段２０３、検証処理実行手段２０４、結果表示手段２０５は、メモリに格納されたプログラムによって実現されるものである。
以下、この構成の情報の検証システムが行う処理について説明する。
図３は、本発明が対象とするソフトウェアの一例を示す図である。本説明では、JavaでWebシステムを開発の例とする。
本実施形態では、開発ルールを決めるフレームワークとして、Strutsを適用する。Strutsとは、Java（登録商標）でWebシステム開発の際、サーバのソフトウェアを作成ためのデファクトスタンダードなフレームワークである。
Webシステムは、クライアント３０１とサーバ３０２に分けられる。
クライアント３０１には、エンドユーザが情報を入力したり、処理結果を確認したりするソフトウェアを配置する。
Webシステムでは、クライアント３０１には通常ブラウザと呼ばれるソフトウェアを使用する。ブラウザは、HTML(HyperText Markup Language)というタグ形式の言語を解釈し表示するソフトウェアである。
また、HTMLには、サーバに情報を送信する仕様がある。HTMLのタグの場合、formというタグが、サーバに情報を送る領域の印となる。ブラウザは、formというタグの中の規格で決められた幾つかのタグの規約で決められた属性の値を情報としてサーバに送信する。
ブラウザは、HTTP(HyperText Transfer Protocol)という規格に基づきサーバと情報通信を行う。
図３は、本発明が対象とするソフトウェアの一例を示す図である。本説明では、JavaでWebシステムを開発の例とする。
本実施形態では、開発ルールを決めるフレームワークとして、Strutsを適用する。Strutsとは、Java（登録商標）でWebシステム開発の際、サーバのソフトウェアを作成ためのデファクトスタンダードなフレームワークである。
Webシステムは、クライアント３０１とサーバ３０２に分けられる。
クライアント３０１には、エンドユーザが情報を入力したり、処理結果を確認したりするソフトウェアを配置する。
Webシステムでは、クライアント３０１には通常ブラウザと呼ばれるソフトウェアを使用する。ブラウザは、HTML(HyperText Markup Language)というタグ形式の言語を解釈し表示するソフトウェアである。
また、HTMLには、サーバに情報を送信する仕様がある。HTMLのタグの場合、formというタグが、サーバに情報を送る領域の印となる。ブラウザは、formというタグの中の規格で決められた幾つかのタグの規約で決められた属性の値を情報としてサーバに送信する。
ブラウザは、HTTP(HyperText Transfer Protocol)という規格に基づきサーバと情報通信を行う。
以下、Strutsの場合のサーバでの動作の説明をする。
サーバでは、RequestProcessor３０３が、通信窓口の役割を持つ。RequestProcessor３０３は、Strutsフレームワークの決まりに従い、業務コンポーネントを制御する役割を持つコンポーネントである。以下、その処理の説明である。
RequestProcessor３０３は、業務コンポーネントの制御として、クライアント３０１から送られてきた情報を、ActionForm３０４というコンポーネントに保持する。ActionFormコンポーネント３０４は、クライアント３０１とサーバのアプリケーション間での情報をやり取りする役割を持つコンポーネントである。
加えて、クライアント３０１が送った情報以外に、サーバで保持する機能があり、一般的にWebシステムでは、それをSession３０５というコンポーネントに保存する。
その次に、RequestProcessor３０３は、業務コンポーネントの制御の一環として、Action３０６というコンポーネントの業務処理を実行するための処理を呼び出し、サーバ３０２の処理を行う。なお、Actionコンポーネント３０６で業務処理を行う処理は、Strutsフレームワークの決まりでexecuteと決まっており、RequestProcessor３０３はexecuteを実行するという処理を行う。
サーバでは、RequestProcessor３０３が、通信窓口の役割を持つ。RequestProcessor３０３は、Strutsフレームワークの決まりに従い、業務コンポーネントを制御する役割を持つコンポーネントである。以下、その処理の説明である。
RequestProcessor３０３は、業務コンポーネントの制御として、クライアント３０１から送られてきた情報を、ActionForm３０４というコンポーネントに保持する。ActionFormコンポーネント３０４は、クライアント３０１とサーバのアプリケーション間での情報をやり取りする役割を持つコンポーネントである。
加えて、クライアント３０１が送った情報以外に、サーバで保持する機能があり、一般的にWebシステムでは、それをSession３０５というコンポーネントに保存する。
その次に、RequestProcessor３０３は、業務コンポーネントの制御の一環として、Action３０６というコンポーネントの業務処理を実行するための処理を呼び出し、サーバ３０２の処理を行う。なお、Actionコンポーネント３０６で業務処理を行う処理は、Strutsフレームワークの決まりでexecuteと決まっており、RequestProcessor３０３はexecuteを実行するという処理を行う。
Action３０６は、クライアント３０１から送られてきた情報と、Session３０５の情報を使用して、業務を行う。この業務処理の詳細はプログラマが実装する。業務処理は、Action３０６に多く記述してもよいし、再利用や部品化を使用してJavaBeansテクノロジーで作成されたコンポーネントを使用してよい。図３は、JavaBeans３０７というコンポーネントを使用する例である。
また、一般的にエンタープライズシステムは、情報を永続的に保存したり、取得したりする必要があるためDB３０８とやり取りを行う。図３では、DB３０８から取得した情報を使用して、JavaBeans３０７が業務処理をしている。この業務処理は顧客要求によって千差万別である。
Action３０６は、上記に示すような挙動で業務処理を行い、終了するとActionFormコンポーネント３０４や、Sessionコンポーネント３０５に情報を保持する処理を行う。
上記の処理が終了すると、Actionコンポーネント３０６の処理シーケンスは終了し、制御がRequestProcessor３０３に戻る。
RequestProcessor３０３は、業務処理結果を、クライアント３０１に返すために、HTMLに変換する処理を行う。そのために、JSP(JavaServer Pages)３０９を使用する。JSP３０９は、動的にHTMLを生成するためのテクノロジーである。JSP３０９は、ActionForm３０４やSession３０５などの情報を使って、HTMLを生成する。
RequestProcessor３０３は、JSP３０９の処理が終了したら、生成されたHTML３１０をクライアント３０１に送り出し、サーバ３０２での処理を終了する。
クライアント３０１は、サーバ３０２の処理結果であるHTML３１０を受け取り、ブラウザがHTML３１０を解釈して表示する。
この一連の処理は、２つの画面があり、クライアント(１つ目の画面)からサーバ３０２へ処理要求を送り、サーバ３０２が業務的な処理を行い、クライアントに２つ目の画面を表示するという、Webシステムの説明である。
Webシステムは、今説明した処理を繰り返し行って、顧客要求を満足する業務処理を実現している。
また、一般的にエンタープライズシステムは、情報を永続的に保存したり、取得したりする必要があるためDB３０８とやり取りを行う。図３では、DB３０８から取得した情報を使用して、JavaBeans３０７が業務処理をしている。この業務処理は顧客要求によって千差万別である。
Action３０６は、上記に示すような挙動で業務処理を行い、終了するとActionFormコンポーネント３０４や、Sessionコンポーネント３０５に情報を保持する処理を行う。
上記の処理が終了すると、Actionコンポーネント３０６の処理シーケンスは終了し、制御がRequestProcessor３０３に戻る。
RequestProcessor３０３は、業務処理結果を、クライアント３０１に返すために、HTMLに変換する処理を行う。そのために、JSP(JavaServer Pages)３０９を使用する。JSP３０９は、動的にHTMLを生成するためのテクノロジーである。JSP３０９は、ActionForm３０４やSession３０５などの情報を使って、HTMLを生成する。
RequestProcessor３０３は、JSP３０９の処理が終了したら、生成されたHTML３１０をクライアント３０１に送り出し、サーバ３０２での処理を終了する。
クライアント３０１は、サーバ３０２の処理結果であるHTML３１０を受け取り、ブラウザがHTML３１０を解釈して表示する。
この一連の処理は、２つの画面があり、クライアント(１つ目の画面)からサーバ３０２へ処理要求を送り、サーバ３０２が業務的な処理を行い、クライアントに２つ目の画面を表示するという、Webシステムの説明である。
Webシステムは、今説明した処理を繰り返し行って、顧客要求を満足する業務処理を実現している。
ここで、HTMLの説明をする。
図４は、本発明で必要な部分を抜粋したHTMLの例である。
HTMLのファイル名称として、index.html４０１がある。通常、HTML形式のファイルは拡張子として、html、htmのどちらかが使われる。
HTMLの内容はタグで機能を指定することができる。ブラウザはタグを認識して、レイアウトを生成したり、情報をサーバに送信したりする。
サーバに情報を送信する機能を指定するタグは、＜form ..(略)..＞402である。ブラウザは、＜form ..(略)..＞で始まり＜/form＞403の間のある、HTML仕様で定められたタグの情報をサーバに送信する。
図４は、本発明で必要な部分を抜粋したHTMLの例である。
HTMLのファイル名称として、index.html４０１がある。通常、HTML形式のファイルは拡張子として、html、htmのどちらかが使われる。
HTMLの内容はタグで機能を指定することができる。ブラウザはタグを認識して、レイアウトを生成したり、情報をサーバに送信したりする。
サーバに情報を送信する機能を指定するタグは、＜form ..(略)..＞402である。ブラウザは、＜form ..(略)..＞で始まり＜/form＞403の間のある、HTML仕様で定められたタグの情報をサーバに送信する。
例えば、エンドユーザに検索条件の入力を求めるタグとして、＜input type=“text” name=”condition” value=””/＞４０４がサーバに送られる情報である。また、エンドユーザがブラウザに、情報をサーバに送る命令を出すためのタグは、＜input type=”submit” value=”検索実行”/＞４０５である。
また、HTMLファイル中に複数のformを記述できるため、＜form..(略)..＞には、名前を付けるための属性がある。それが、name=”indexForm”４０６の部分である。
同様に、情報をサーバに送ることができるタグにも名前をつけることができ、図４の場合は、属性名name４０７で、属性値が”condition”４０８である。また、情報をサーバに送ることができるタグは、送るための情報を設定する属性もあり、図４の場合は、value４０９がその属性名であり、”で囲まれた部分４１０がサーバに送られる情報である。
また、HTMLファイル中に複数のformを記述できるため、＜form..(略)..＞には、名前を付けるための属性がある。それが、name=”indexForm”４０６の部分である。
同様に、情報をサーバに送ることができるタグにも名前をつけることができ、図４の場合は、属性名name４０７で、属性値が”condition”４０８である。また、情報をサーバに送ることができるタグは、送るための情報を設定する属性もあり、図４の場合は、value４０９がその属性名であり、”で囲まれた部分４１０がサーバに送られる情報である。
図５は、本実施形態の検証システムの処理の概要を表すフローチャートである。
本実施形態の検証システムでは、検索条件入力→検索結果一覧表示→詳細表示と画面遷移を行うWebシステムを対象として詳細説明を行う。
ソース情報取得手段２０２は、システムを起動したとき、開発対象格納手段２０６からソースファイル２０７を取得する(ステップ５０１)。
ソースファイル２０７としては、エンドユーザが情報を入力するためのHTMLや、業務処理を行うコンポーネントや、業務処理を行うコンポーネントが使用するJavaBeansコンポーネントなどがある。
ソース情報取得手段２０２は、HTMLを解析してエンドユーザが入力すべき情報を取得する。
本実施形態の検証システムでは、検索条件入力→検索結果一覧表示→詳細表示と画面遷移を行うWebシステムを対象として詳細説明を行う。
ソース情報取得手段２０２は、システムを起動したとき、開発対象格納手段２０６からソースファイル２０７を取得する(ステップ５０１)。
ソースファイル２０７としては、エンドユーザが情報を入力するためのHTMLや、業務処理を行うコンポーネントや、業務処理を行うコンポーネントが使用するJavaBeansコンポーネントなどがある。
ソース情報取得手段２０２は、HTMLを解析してエンドユーザが入力すべき情報を取得する。
図６は、ソース情報取得手段が、HTMLから情報を取得する処理のフローである。
まず、対象となるHTMLの一覧を取得する(ステップ６０１)。
ステップ６０１の一覧から解析していないHTMLを選出してファイルを取得する。(ステップ６０２)。すべて解析が済んでいるときは、図６の処理を終了する。
すべてのファイルの解析が終っていないときは、ステップ６０３へ進む。
以下、図４のindex.htm１４０１を処理対象例として説明を行う。
HTMLのファイルの最後まで解析したかどうかを調べる。最後まで読んでいたらステップ６０２に戻る(ステップ６０３ Y)。そうでないときはステップ６０４へ進む。
HTMLの内容を順番に読み込んで、＜form＞を見つけるまで読み込む(ステップ６０４ Y)。
本例では、＜form name=”inexForm” action=”result.html”＞を見つけることができる。
＜form＞が見つからないときは、ステップ６０２へ戻る(ステップ６０４ N)。
HTMLでは、複数の＜form＞を記述できるため、＜form＞をみつけたときには、formタグのname属性を識別子として取得する(ステップ６０５)。本例では、indexFormを取得する。
＜form＞を見つけたときは、その中にあるサーバへ情報を送信するタグを探す(ステップ６０６)。サーバに情報を送信することができるタグとして、＜input＞や＜select＞などがHTML仕様で定義されおり、このステップではそれらのタグを探す処理を行う。本例では、＜input type=”text” name=”condition” value=””/＞を見つける。
サーバに情報を送信するタグを見つけたら、サーバで情報を取得するために使用する文字列を取得する(ステップ６０７)。HTTPの仕様では、情報を取得する文字列と値をペアで送信する。HTMLのサーバに情報を送信するタグの記述では、name属性の値にその文字列を記述する。本例では、＜input type=”text” name=”condition” value=””/＞を見つけているから、そのname属性値は、conditionであるので、取得する文字列は、conditionである。
ステップ６０５からステップ６０７の処理を＜/form＞のタグを見つけるまで続ける(ステップ６０８)。
＜/form＞を見つけた後、HTMLファイルの終了でないなら、ステップ６０３へ戻り処理を進める。
まず、対象となるHTMLの一覧を取得する(ステップ６０１)。
ステップ６０１の一覧から解析していないHTMLを選出してファイルを取得する。(ステップ６０２)。すべて解析が済んでいるときは、図６の処理を終了する。
すべてのファイルの解析が終っていないときは、ステップ６０３へ進む。
以下、図４のindex.htm１４０１を処理対象例として説明を行う。
HTMLのファイルの最後まで解析したかどうかを調べる。最後まで読んでいたらステップ６０２に戻る(ステップ６０３ Y)。そうでないときはステップ６０４へ進む。
HTMLの内容を順番に読み込んで、＜form＞を見つけるまで読み込む(ステップ６０４ Y)。
本例では、＜form name=”inexForm” action=”result.html”＞を見つけることができる。
＜form＞が見つからないときは、ステップ６０２へ戻る(ステップ６０４ N)。
HTMLでは、複数の＜form＞を記述できるため、＜form＞をみつけたときには、formタグのname属性を識別子として取得する(ステップ６０５)。本例では、indexFormを取得する。
＜form＞を見つけたときは、その中にあるサーバへ情報を送信するタグを探す(ステップ６０６)。サーバに情報を送信することができるタグとして、＜input＞や＜select＞などがHTML仕様で定義されおり、このステップではそれらのタグを探す処理を行う。本例では、＜input type=”text” name=”condition” value=””/＞を見つける。
サーバに情報を送信するタグを見つけたら、サーバで情報を取得するために使用する文字列を取得する(ステップ６０７)。HTTPの仕様では、情報を取得する文字列と値をペアで送信する。HTMLのサーバに情報を送信するタグの記述では、name属性の値にその文字列を記述する。本例では、＜input type=”text” name=”condition” value=””/＞を見つけているから、そのname属性値は、conditionであるので、取得する文字列は、conditionである。
ステップ６０５からステップ６０７の処理を＜/form＞のタグを見つけるまで続ける(ステップ６０８)。
＜/form＞を見つけた後、HTMLファイルの終了でないなら、ステップ６０３へ戻り処理を進める。
図７は、図６のソース情報取得機能で生成されるエンドユーザ入力情報テーブル２０９の一例である。
エンドユーザ入力情報テーブル７０１のForm名７０２は、＜form＞タグのname属性に定義された文字列である。本例では、indexForm７０３となる。入力項目７０４は、エンドユーザが画面で入力することができ、ブラウザの機能によりサーバに送信される情報である。本例では、condition７０５である。
HTMLをすべて解析したら、図５に戻りステップ５０２へ進む。
エンドユーザ入力情報テーブル７０１のForm名７０２は、＜form＞タグのname属性に定義された文字列である。本例では、indexForm７０３となる。入力項目７０４は、エンドユーザが画面で入力することができ、ブラウザの機能によりサーバに送信される情報である。本例では、condition７０５である。
HTMLをすべて解析したら、図５に戻りステップ５０２へ進む。
処理の説明の前に、図８を使って業務処理を行うコンポーネントの一例の説明を行う。
図８に示すListAction８０１は検索条件を使い、検索結果の一覧を取得する業務コンポーネントの例であり、ListAction８０１という名称である。
クライアントでエンドユーザが入力した検索条件は、前述の通り、対応するActionFormコンポーネントに保存される。本例では、indexForm８０２が該当する。
次に、Strutsフレームワークのルールでは、クライアントから送られた情報を、getXxx()という形式で取得する。ここで、Xxxはクライアントからサーバに対して送られた文字列の先頭の英大文字が使用される。本例では、検索条件をサーバが取得ときは、conditionという文字列を使用する。そのため、getCondition()８０３という処理で、クライアントが送り出した情報を、サーバでは取得する。
また図８の例の場合、取得した情報を、condition８０４という変数名に入れる処理を記述している。
図８に示すListAction８０１は検索条件を使い、検索結果の一覧を取得する業務コンポーネントの例であり、ListAction８０１という名称である。
クライアントでエンドユーザが入力した検索条件は、前述の通り、対応するActionFormコンポーネントに保存される。本例では、indexForm８０２が該当する。
次に、Strutsフレームワークのルールでは、クライアントから送られた情報を、getXxx()という形式で取得する。ここで、Xxxはクライアントからサーバに対して送られた文字列の先頭の英大文字が使用される。本例では、検索条件をサーバが取得ときは、conditionという文字列を使用する。そのため、getCondition()８０３という処理で、クライアントが送り出した情報を、サーバでは取得する。
また図８の例の場合、取得した情報を、condition８０４という変数名に入れる処理を記述している。
次は、sessionコンポーネントを取得する行である。JavaのWebシステムの場合、request.getSession(false);８０５の処理で取得する。
行８０５で取得したsessionコンポーネントから情報を取得するのは、getAttribute(キーワード);８０６である。図８の場合、取得した情報を変数名username８０７に入れる処理を記述している。
行８０５で取得したsessionコンポーネントから情報を取得するのは、getAttribute(キーワード);８０６である。図８の場合、取得した情報を変数名username８０７に入れる処理を記述している。
次の行は、業務処理を行うためのコンポーネントの一つとして、JavaBeansテクノロジーも用いて、別途作成されたSearchコンポーネントを使用する例８０８である。このコンポーネントは、検索条件を受け取り、検索結果を返すためにDBに直接アクセスする機能を持つとする。これらの処理は、Searchコンポーネントを使用するための変数search８０９を介して行う。
次の行８１０は、検索結果をした処理結果を取得して、ブラウザに表示するために設定する処理である。業務処理結果は、JavaBeansの決まりに従い、searchを介してgetXxx()で取得する。検索結果と検索結果の状態を取得できるとする。
取得した結果をJSPで取得するために、requestコンポーネントに設定する処理である。requestコンポーネントへ情報を設定するのは、setAttribute(“キーワード”,情報);である。本例は、result８１１というキーワードで、検索結果であるsearch.getResult()８１２を設定している例である。また、検索結果の状態も同様にSTATUS_CODE813というキーワードに、search.getResult()814で検索結果の状態を取得して、requestコンポーネントに設定している。
検索条件を詳細表示画面でも使用することがあるとするならば、Session領域に設定することで、エンドユーザが改めて入力をする必要なく、Webシステムで使用できるようになる。
行８１５は、sessionコンポーネントに情報を設定する処理である。sessionコンポーネントへ情報を設定するのは、setAttribute(“キーワード”,情報);である。本例は、condition８１６と言うキーワードで、検索条件であるcondition８１７を設定している例である。
行８１８は、Actionコンポーネントの処理結果の後に表示する画面をRequestProcessor に返却する処理である。
行８１５は、sessionコンポーネントに情報を設定する処理である。sessionコンポーネントへ情報を設定するのは、setAttribute(“キーワード”,情報);である。本例は、condition８１６と言うキーワードで、検索条件であるcondition８１７を設定している例である。
行８１８は、Actionコンポーネントの処理結果の後に表示する画面をRequestProcessor に返却する処理である。
上記の説明からわかるように、Strutsフレームワークのルールに従うと、（１）ActionFormコンポーネントから取得すると、エンドユーザが入力した情報だとわかる。また、（２）sessionから取得していると、エンドユーザが入力した情報ではないが、業務処理で使用する情報だとわかる。また、（３）requestやsessionに設定している情報は、業務処理の結果であることがわかる。そのうちsessionに設定している情報は、エンドユーザによる入力なしでもサーバで使用できる情報である。本例では、上記のルールを基に、業務コンポーネントのソースコードを解析する。
図９は、業務処理を行うコンポーネントのソースコードを解析する処理を示すフローチャートである。
まず、業務処理を行うコンポーネントの一覧を取得する(ステップ９０１)。
本例では、Strutsを適用したソフトウェア開発であるので、本発明を説明するために必要な一例として、慣例に従ったXxxAction(Xxxは任意の文字列)というルールで名づけられたコンポーネントが業務処理を行うものとする。既に述べているように業務処理を行うコンポーネントは、JavaBeansでもよいため、予め業務処理を行うコンポーネントの一覧を定義しておき、定義に従って解析対象を取得してもよく、XxxActionでない他のルールでもよい。
まず、業務処理を行うコンポーネントの一覧を取得する(ステップ９０１)。
本例では、Strutsを適用したソフトウェア開発であるので、本発明を説明するために必要な一例として、慣例に従ったXxxAction(Xxxは任意の文字列)というルールで名づけられたコンポーネントが業務処理を行うものとする。既に述べているように業務処理を行うコンポーネントは、JavaBeansでもよいため、予め業務処理を行うコンポーネントの一覧を定義しておき、定義に従って解析対象を取得してもよく、XxxActionでない他のルールでもよい。
次に、業務処理を行うコンポーネントの一覧に基づき、全ての業務処理コンポーネントを解析をしたかどうかを判定する(ステップ９０２)。全ての業務処理コンポーネントを解析していたら終了する(ステップ９０２ Y)。
解析すべき業務処理コンポーネントがあれば(ステップ９０２ N)、その業務コンポーネントの名前を取得する(ステップ903)。本例では、ListActionとなる。
解析すべき業務処理コンポーネントがあれば(ステップ９０２ N)、その業務コンポーネントの名前を取得する(ステップ903)。本例では、ListActionとなる。
次に、業務処理を実行する処理の解析を行う(ステップ９０４)。詳細をステップ９０５以降で説明する。
ステップ９０５では、ファイルの解析が終了したかどうかを判断する。ファイルの終了まで解析処理が済んでいたら、ステップ９０４へ戻る。そうでないときは、ステップ９０６へ進む。
Strutsフレームワークでは、executeメソッドが、業務処理を記述する箇所と決められているため、executeメソッドが見つかるまで読み込む(ステップ９０５、ステップ９０６、ステップ９０７)。
続いてexecuteメソッドが終了するまで、内容を解析するために１行読み込む(ステップ９０８)。
本例の場合、１行読み込むと、IndexForm indexForm = (IndexForm) form;となる。
ステップ９０５では、ファイルの解析が終了したかどうかを判断する。ファイルの終了まで解析処理が済んでいたら、ステップ９０４へ戻る。そうでないときは、ステップ９０６へ進む。
Strutsフレームワークでは、executeメソッドが、業務処理を記述する箇所と決められているため、executeメソッドが見つかるまで読み込む(ステップ９０５、ステップ９０６、ステップ９０７)。
続いてexecuteメソッドが終了するまで、内容を解析するために１行読み込む(ステップ９０８)。
本例の場合、１行読み込むと、IndexForm indexForm = (IndexForm) form;となる。
ステップ９０８で取得した行が、エンドユーザが入力した情報を保持するコンポーネント用なのか(ステップ９０９)、エンドユーザの入力情報を取得している処理か(ステップ９１０)、ソフトウェアが保持していた情報を取得している処理か(ステップ９１１)、業務処理の結果を設定している処理か(ステップ９１２)、入力情報を保持するコンポーネントに関わる処理か(ステップ９１３)なのかを判定する。
本例では、ステップ９０８で取得した行は、エンドユーザが入力した情報を保持するコンポーネントであり、indexFormがエンドユーザの情報を保持する(ステップ９０９ Y)であるので、エンドユーザが入力した入力情報のコンポーネントに関わる処理を行う。
ここで、入力情報を保持するコンポーネントは、ActionFormを継承しているため、ソースコードを全て読み込んで判断していくこともできるが、本例では、簡単のため、Strutsを適用したときの慣例的な命名規則に従い、XxxForm(Xxxは任意文字列)を入力情報を保持するコンポーネントであると判断する。
よって、この行の場合、本例では、indexForm８０２を取得して保持する(ステップ９１５)。
ここで、入力情報を保持するコンポーネントは、ActionFormを継承しているため、ソースコードを全て読み込んで判断していくこともできるが、本例では、簡単のため、Strutsを適用したときの慣例的な命名規則に従い、XxxForm(Xxxは任意文字列)を入力情報を保持するコンポーネントであると判断する。
よって、この行の場合、本例では、indexForm８０２を取得して保持する(ステップ９１５)。
次に、executeメソッドの終了かどうかを判定する(ステップ９１４)。executeメソッドの終了でないときは、ステップ９０８へ戻り次の１行を取得する(ステップ９１４ N)。
executeメソッドの終了のときはステップ９０５へ戻る(ステップ９１４ Y)。
本例の現時点では、executeメソッドの終了ではないため、次の１行、String condition = indexForm.getCondition();を取得する。
上記の説明のように、本例では、同様にして、解析を進めていく。以下、発明に関わる行を読み込んだときの処理について説明する。
executeメソッドの終了のときはステップ９０５へ戻る(ステップ９１４ Y)。
本例の現時点では、executeメソッドの終了ではないため、次の１行、String condition = indexForm.getCondition();を取得する。
上記の説明のように、本例では、同様にして、解析を進めていく。以下、発明に関わる行を読み込んだときの処理について説明する。
ステップ９１６では、エンドユーザが入力した情報を保持するコンポーネントから情報を取得している処理を解析してから、業務処理で使用する情報を取得する。既に述べているルールに従うと、String condition = indexForm.getCondition();は、エンドユーザの入力情報から情報を取得していることがわかるので、エンドユーザが入力した情報として保持する。
本例では、取得した値を表す変数のconditionを入力情報として取得する。
本例では、取得した値を表す変数のconditionを入力情報として取得する。
ステップ９１７では、保持情報コンポーネントから情報を取得している処理から、業務処理で使用する情報を取得する。HttpSession session = request.getSession(false);は、サーバに保存している情報を取得するsessionコンポーネントを取得する処理である。そして、String username = session.getAttribute(“USER_NAME”);は、sessionコンポーネントから情報を取得する処理である。本例では、取得した値を表す変数usernameを取得する。
次に取得する行は、Search search = new Search();である。この行は、業務コンポーネントを用意する処理であるが、本発明においては、重要な意味を持たないため、情報の取得はしない。
次に取得する行は、search.do(username, condition);である。この行は、実際に業務処理を行うコンポーネントを使用している行であるが、本発明においては、情報の取得はしない。
ステップ９１８では、業務処理結果の中で、出力情報を設定する処理を解析し、出力情報を取得する。request.setAttribute("results", search.getResults());である。Strutsフレームワークでは、requestは、サーバで保持しない処理結果を保持するコンポーネントであるというルールがあるため、この行は、処理結果を設定している行であることがわかる。よって、本例では、保持先であるrequestと処理結果を表すresultsを取得する。
次に取得する行は、search.do(username, condition);である。この行は、実際に業務処理を行うコンポーネントを使用している行であるが、本発明においては、情報の取得はしない。
ステップ９１８では、業務処理結果の中で、出力情報を設定する処理を解析し、出力情報を取得する。request.setAttribute("results", search.getResults());である。Strutsフレームワークでは、requestは、サーバで保持しない処理結果を保持するコンポーネントであるというルールがあるため、この行は、処理結果を設定している行であることがわかる。よって、本例では、保持先であるrequestと処理結果を表すresultsを取得する。
ステップ９１９では、業務処理の中で、保持情報に保持する出力情報を設定する処理から、出力としての保持情報を取得する。session.setAttribute("condition", condition);である。先に述べたように、sessionはサーバで再び使用する情報を保持するコンポーネントであり、そのコンポーネントに設定している処理であるので、業務処理結果を設定していることがわかる。本例では、保存先である、sessionと処理結果を表す変数conditionを取得する。
次に取得する行は、return "LIST";である。Strutsフレームワークのルールに従い、業務処理結果の後に表示する画面を指示する処理である。本発明においては、その他の処理として情報の取得はしない。
次の行は「}」であり,executeメソッドの終了であるので、ステップ９０５に戻る。
これらの説明した通りに、当該すべてのファイルに対して処理を行う。
次の行は「}」であり,executeメソッドの終了であるので、ステップ９０５に戻る。
これらの説明した通りに、当該すべてのファイルに対して処理を行う。
図１０は、図９のソース情報取得手段２０２の処理の結果、生成されるソース情報の一例であり、業務処理コンポーネントを解析した結果のエンドユーザが入力する情報と、業務処理で使用する情報と、業務処理の結果の情報とを一覧するための業務処理情報テーブル（図２の２１０）の記憶情報例である。
業務コンポーネント名１００１は、業務処理を行うコンポーネントの情報である。本例の場合、ListAction１００２である。
業務処理で使用する情報１００３は、ListActionの中で業務処理を行う情報であり、取得元１００４は、その取得元である。本例では、業務処理で使用する情報condition１００５は、indexForm１００６から取得することがわかる。また、username１００７は、session１００８から取得することがわかる。
業務処理結果１００９は、業務処理の結果の情報であり、設定先１０１０が、業務処理の結果を設定するコンポーネントを表す。本例では、results１０１１は、request１０１２に設定することがわかり、condition１０１３は、session１０１４コンポーネントへ保存することがわかる。
業務コンポーネント名１００１は、業務処理を行うコンポーネントの情報である。本例の場合、ListAction１００２である。
業務処理で使用する情報１００３は、ListActionの中で業務処理を行う情報であり、取得元１００４は、その取得元である。本例では、業務処理で使用する情報condition１００５は、indexForm１００６から取得することがわかる。また、username１００７は、session１００８から取得することがわかる。
業務処理結果１００９は、業務処理の結果の情報であり、設定先１０１０が、業務処理の結果を設定するコンポーネントを表す。本例では、results１０１１は、request１０１２に設定することがわかり、condition１０１３は、session１０１４コンポーネントへ保存することがわかる。
図１０では、本発明の説明に必要な最小限にしているが、業務コンポーネント(本例では、Search)など別情報を持たせてもよい。また本例では、「-」１０１５は情報を持たないことを意味する特別な値とする。
ソース情報取得手段２０２の処理が終了すると、ステップ５０２に進む。ステップ５０２の遷移情報を取する処理の詳細を図１１に例示する遷移情報と図１２の遷移情報取得処理のフローチャートを参照して説明する。
図１１は、開発対象格納手段２０６に保存されている遷移情報２０８の一例である。
遷移情報は、画面の流れを定義した設計情報である。
表示画面名１１０１は、サーバでの処理結果表示される画面を定義する列である。
検索条件入力１１０２が画面名である。本例の場合、簡単のため、上から順番に遷移するものとする。よって、図１１から、検索条件入力→検索結果一覧表示→詳細表示と遷移を行うことがわかる。
業務処理コンポーネント名１１０３は、サーバでの処理を行うためのコンポーネントを定義する列である。本例では、検索条件入力を表示するためのサーバの処理をIndexAction１１０４であることを表している。
図１１の例に加えて、処理の順序を定義する列や、Webシステムの画面遷移を幾つかに分割してそれぞれにIDを割り当てたときのIDなど、付加的情報を設けてもよいが、本発明を的確に説明するためには不要であるので省略する。
遷移情報は、画面の流れを定義した設計情報である。
表示画面名１１０１は、サーバでの処理結果表示される画面を定義する列である。
検索条件入力１１０２が画面名である。本例の場合、簡単のため、上から順番に遷移するものとする。よって、図１１から、検索条件入力→検索結果一覧表示→詳細表示と遷移を行うことがわかる。
業務処理コンポーネント名１１０３は、サーバでの処理を行うためのコンポーネントを定義する列である。本例では、検索条件入力を表示するためのサーバの処理をIndexAction１１０４であることを表している。
図１１の例に加えて、処理の順序を定義する列や、Webシステムの画面遷移を幾つかに分割してそれぞれにIDを割り当てたときのIDなど、付加的情報を設けてもよいが、本発明を的確に説明するためには不要であるので省略する。
遷移情報取得手段２０３は、まず、図１１に保存されている遷移情報を取得する(ステップ１２０１)。
次に、図１１の表示画面名１１０１から表示する画面名を取得する(ステップ１２０２)。本例では、“検索条件入力”を取得する。
情報を取得していない(ステップ１２０２ N)とき、業務処理コンポーネント名１１０３を取得する(ステッ１２０３3)。本例では、まずIndexAction１１０４を取得する。すべての情報を取得したら(ステップ１２０２ Y)、遷移情報取得手段２０３の処理を終了する。
図１２の処理の結果の一例が図１３である。
業務コンポーネント名１３０１は、業務処理を実行するコンポーネントを表す列である。本例では、業務処理を行うコンポーネントは、IndexAction１３０２、ListAction１３０３、DetailAction１３０４であることがわかる。
図１１と同様に簡単のため、上から順番に遷移するものとする。IndexAction → ListAction → DetailActionの順序で実行されることがわかる。
次に、図１１の表示画面名１１０１から表示する画面名を取得する(ステップ１２０２)。本例では、“検索条件入力”を取得する。
情報を取得していない(ステップ１２０２ N)とき、業務処理コンポーネント名１１０３を取得する(ステッ１２０３3)。本例では、まずIndexAction１１０４を取得する。すべての情報を取得したら(ステップ１２０２ Y)、遷移情報取得手段２０３の処理を終了する。
図１２の処理の結果の一例が図１３である。
業務コンポーネント名１３０１は、業務処理を実行するコンポーネントを表す列である。本例では、業務処理を行うコンポーネントは、IndexAction１３０２、ListAction１３０３、DetailAction１３０４であることがわかる。
図１１と同様に簡単のため、上から順番に遷移するものとする。IndexAction → ListAction → DetailActionの順序で実行されることがわかる。
ステップ５０２が終了すると、ステップ５０３へ進む。ステップ５０３は、これまでに取得した情報を使って業務処理で使用する情報に過不足があるかどうかを検証する処理である。
ステップ５０３の詳細を図１４のフローチャートを使って説明する。
まず、これまでの処理で作成したエンドユーザ入力情報テーブル２０９、業務処理情報テーブル２１０、遷移情報テーブル２１１を読み込む(ステップ１４０１)。
図１３の遷移情報テーブルから、Webシステムが最初に処理をする業務処理コンポーネントを取得する(ステップ１４０２)。本例では、テーブルでの記載順序と遷移の順序が対応しているため、遷移情報テーブルの業務処理コンポーネント名の先頭のIndexActionとなる。
まず、これまでの処理で作成したエンドユーザ入力情報テーブル２０９、業務処理情報テーブル２１０、遷移情報テーブル２１１を読み込む(ステップ１４０１)。
図１３の遷移情報テーブルから、Webシステムが最初に処理をする業務処理コンポーネントを取得する(ステップ１４０２)。本例では、テーブルでの記載順序と遷移の順序が対応しているため、遷移情報テーブルの業務処理コンポーネント名の先頭のIndexActionとなる。
次に、図１０に例示した業務処理情報テーブルから、ステップ１４０２で取得した業務処理コンポーネントに対応する入力情報と取得元と業務処理結果と設定先を取得する(ステップ１４０３)。本例では、IndexAction、―、―、―、―を取得する。
次に、業務処理で使用する情報があるかどうかを検証する(ステップ１４０４)。本例でのIndexActionでは、情報がないため(ステップ１４０４ N)、ステップ１４０５へ進む。
次に、業務処理結果があるかどうかを検証する(ステップ１４０５ N)。本例でのIndexActionでは、情報がないため、ステップ１４０２へ戻り、次の行に対して処理をする。
次に、業務処理で使用する情報があるかどうかを検証する(ステップ１４０４)。本例でのIndexActionでは、情報がないため(ステップ１４０４ N)、ステップ１４０５へ進む。
次に、業務処理結果があるかどうかを検証する(ステップ１４０５ N)。本例でのIndexActionでは、情報がないため、ステップ１４０２へ戻り、次の行に対して処理をする。
次の行を読み込んだとき、本例では、ListAction、condition、indexForm、―、―を取得する。
次に、業務処理で使用する情報があるかどうかを検証する(ステップ１４０４ Y)。本例でListActionでは、conditionがあるのでステップ１４０６へ進む。
次に、業務処理で使用する情報と取得元を取得する(ステップ１４０６)。本例では、conditionとindexFormを取得する。
次に、業務処理で使用する情報があるかどうかを検証する(ステップ１４０４ Y)。本例でListActionでは、conditionがあるのでステップ１４０６へ進む。
次に、業務処理で使用する情報と取得元を取得する(ステップ１４０６)。本例では、conditionとindexFormを取得する。
次に、取得元が、エンドユーザの入力なのか、サーバで保持している情報なのかを判断する(ステップ１４０７)。本例では、既に説明しているようにXxxFormはエンドユーザの情報を保持しているコンポーネントであるので、文字列で判断することができる。本例では、indexFormであるのでエンドユーザが入力した情報だとわかる。
次に、エンドユーザ入力情報テーブル２０９のForm名と入力項目をペアで検索する(ステップ１４０８)。本例では、ステップ１４０６で取得したindexFormとconditionが、エンドユーザ入力情報にあることがわかる。本例の現時点では、エンドユーザ入力情報が存在するので、例えば、内部的にフラグを「○」にする（ステップ１４０９）。
次に、ステップ１４２に戻って次の行を読み込むと、本例では、ListAction、username、session、―、―となる。説明した処理を行うと、取得元がエンドユーザ入力情報ではないので、ステップ１４１０へ進む。
次に、ステップ１４２に戻って次の行を読み込むと、本例では、ListAction、username、session、―、―となる。説明した処理を行うと、取得元がエンドユーザ入力情報ではないので、ステップ１４１０へ進む。
ステップ１４１０は、使用される前にsessionコンポーネントに情報を設定されているかどうかを検証する。一般的にsessionコンポーネントの情報を業務処理の入力にしても良い条件は、当該業務コンポーネントより前の業務処理の結果としてのsessionコンポーネントに設定されていることである。本例では、業務処理情報テーブル２１０の業務処理コンポーネントを上から実行するので、業務コンポーネント名が、ListActionになるまで、業務処理結果と設定先をペアで検証する。
本例では、まずIndexActionの行の業務処理結果と設定先を取得する。すると、―、―であるので、usernameがないため、次の行を取得する。
本例では、まずIndexActionの行の業務処理結果と設定先を取得する。すると、―、―であるので、usernameがないため、次の行を取得する。
次に、業務処理の実行前に設定されていない例の説明をする。
次の行を取得すると、業務コンポーネント名が、ListActionであるので終了する。
usernameは、ListActionの処理より前に業務処理の結果として用意されなかったことが分かる。そこで、例えば本例では内部的にフラグを「△」とする（ステップ１４１１）。
次の行を取得すると、業務コンポーネント名が、ListActionであるので終了する。
usernameは、ListActionの処理より前に業務処理の結果として用意されなかったことが分かる。そこで、例えば本例では内部的にフラグを「△」とする（ステップ１４１１）。
次に、業務処理の実行前に設定されているときの例の説明をする。
既に説明している処理を行い、DetailActionの２行目を読み込むと、DetailAction、condition、session、STATUS_CODE、requestである。
業務処理で使用する情報のconditionの取得元はsessionであるので、業務処理結果と設定先を検索する。本例では、ListActionの６行目まで処理を進めると、condition、sessionであるので、DetailActionの処理の前に業務処理の結果としてsessionコンポーネントに設定されていることが分かる。そこで本例では、例えば、内部的にフラグを「○」として、ステップ１４０２に戻って次の行を読み込む。
既に説明している処理を行い、DetailActionの２行目を読み込むと、DetailAction、condition、session、STATUS_CODE、requestである。
業務処理で使用する情報のconditionの取得元はsessionであるので、業務処理結果と設定先を検索する。本例では、ListActionの６行目まで処理を進めると、condition、sessionであるので、DetailActionの処理の前に業務処理の結果としてsessionコンポーネントに設定されていることが分かる。そこで本例では、例えば、内部的にフラグを「○」として、ステップ１４０２に戻って次の行を読み込む。
次の行を読み込むと、ListAction、usercode、indexForm、―、―となる。これまでの処理を行い、既に説明したように、usercodeとindexFormとをペアで検索する。本例では、検索した結果、このペアは存在しないので、例えば、内部的に「×」とする(ステップ１４１２)。
次に、ステップ１４０２に戻って、次の行を読み込むと、ListAction、―、―、result、requestとなる。これまでの処理と同様に、ステップ１４０５まで行うと、業務処理結果がある(ステップ１４０５ Y)ため、ステップ１４１３へ進む。本例では、resultを取得して、ステップ１４０２へ戻る。
上記の処理によりすべて検証を終わったら、ステップ５０４に進む。
次に、ステップ１４０２に戻って、次の行を読み込むと、ListAction、―、―、result、requestとなる。これまでの処理と同様に、ステップ１４０５まで行うと、業務処理結果がある(ステップ１４０５ Y)ため、ステップ１４１３へ進む。本例では、resultを取得して、ステップ１４０２へ戻る。
上記の処理によりすべて検証を終わったら、ステップ５０４に進む。
図１５は、図１４の処理結果を格納した過不足検証保持テーブルの例である。このテーブルに保持される情報は、これまでの処理で作成された情報からいつでも作ることができるので、本発明では、内部的に保持することとする。
業務コンポーネント１５０１は、業務コンポーネントの情報を保持する。
入力情報１５０２は、当該の業務処理コンポーネントが使用する情報である。
出力情報１５０３は、業務処理コンポーネントの結果の情報である。
検証結果１５０４は、本発明により入力情報の検証を行った結果である。
業務コンポーネント１５０１は、業務コンポーネントの情報を保持する。
入力情報１５０２は、当該の業務処理コンポーネントが使用する情報である。
出力情報１５０３は、業務処理コンポーネントの結果の情報である。
検証結果１５０４は、本発明により入力情報の検証を行った結果である。
本例で説明すると、condition１５０５の検証結果は、「○」１５０６であるので、エンドユーザが情報を入力して、ListAction１５０７で情報を取得することができ、業務処理に使用できることが分かる。
また、username１５０８の検証結果は、「△」１５０９であるので、ListActionでは、サーバに保存している情報を取得するようにプログラムに記述されているにも関わらず、ListActionの業務処理の開始時にはsessionコンポーネントに設定されていないため、業務処理が正常に行われない可能性が高いことが分かる。
Usercode１５１０の検証結果は、「×」１５１１であるので、ListActionでは、エンドユーザが入力した情報をListActionが取得して業務処理に使用する仕様であっても、実際のプログラムでは、取得できないことがわかる。
また、username１５０８の検証結果は、「△」１５０９であるので、ListActionでは、サーバに保存している情報を取得するようにプログラムに記述されているにも関わらず、ListActionの業務処理の開始時にはsessionコンポーネントに設定されていないため、業務処理が正常に行われない可能性が高いことが分かる。
Usercode１５１０の検証結果は、「×」１５１１であるので、ListActionでは、エンドユーザが入力した情報をListActionが取得して業務処理に使用する仕様であっても、実際のプログラムでは、取得できないことがわかる。
ステップ５０４の詳細について図１６を使って説明する。
図１６は、開発者に対し、情報の過不足検証結果を表示する処理のフローチャートである。
まず、図１５に例示した情報の過不足検証結果保持テーブルの全ての行を処理したかどうか調べる(ステップ１６０１)。最初は、すべて検証していない(ステップ１６０１ N)ので、ステップ１６０２へ進む。
ステップ１６０２では、図１５に例示した検証結果保持テーブルから１行取得する。本例では、まず、IndexAction、‐、‐、‐の行を取得する。
次に、直前まで、同じ業務コンポーネントの情報に対して処理をしていたかどうかを検証する(ステップ１６０３)。本例では、現段階では、まだ処理している業務処理コンポーネントはないため、ステップ１６０４へ進む。
ステップ１６０４では、検証結果として開発者に表示する情報があるかどうかを調べる。本例では、この段階では表示する情報はない(ステップ１６０４ N)ため、ステップ１６０５へ進む。
次に、入力情報と検証結果があるかどうかを調べる(ステップ１６０５)。本例のIndexActionの行では、入力情報と検証情報はない(ステップ１６０５ N)ため、ステップ１６０６へ進む。
ステップ１６０６では、出力情報を取得する。本例のIndexActionの行では、出力情報はない(ステップ１６０６ N)ため、ステップ１６０１へ戻る。
図１６は、開発者に対し、情報の過不足検証結果を表示する処理のフローチャートである。
まず、図１５に例示した情報の過不足検証結果保持テーブルの全ての行を処理したかどうか調べる(ステップ１６０１)。最初は、すべて検証していない(ステップ１６０１ N)ので、ステップ１６０２へ進む。
ステップ１６０２では、図１５に例示した検証結果保持テーブルから１行取得する。本例では、まず、IndexAction、‐、‐、‐の行を取得する。
次に、直前まで、同じ業務コンポーネントの情報に対して処理をしていたかどうかを検証する(ステップ１６０３)。本例では、現段階では、まだ処理している業務処理コンポーネントはないため、ステップ１６０４へ進む。
ステップ１６０４では、検証結果として開発者に表示する情報があるかどうかを調べる。本例では、この段階では表示する情報はない(ステップ１６０４ N)ため、ステップ１６０５へ進む。
次に、入力情報と検証結果があるかどうかを調べる(ステップ１６０５)。本例のIndexActionの行では、入力情報と検証情報はない(ステップ１６０５ N)ため、ステップ１６０６へ進む。
ステップ１６０６では、出力情報を取得する。本例のIndexActionの行では、出力情報はない(ステップ１６０６ N)ため、ステップ１６０１へ戻る。
ステップ１６０１へ戻ると、まだ検証保持テーブルには、処理をしていない行があるため、ステップ１６０２進む。
次に、１行読み込んだListAction、condition、○、‐に対して処理をする。
まず、ステップ１６０３で業務処理コンポーネントを調べると、直前まで処理をしていた業務処理コンポーネントと違う(ステップ１６０３ Y)ため、ステップ１６０４へ進む。ステップ１６０４では、先に検証を行った行IndexAction、‐、‐、‐の情報があるので、ステップ１６０７へ進み、IndexActionの行の情報を表示する。この段階で、先に取得した行(IndexAction、‐、‐、‐)への処理が終了する。
IndexActionの行の情報を表示した後、ステップ１６０５へ進み、ListActionの行の処理を進める。
まず、ステップ１６０５で入力情報と検証結果を調べると、conditionと「○」があるため、ステップ１６０８へ進む。
ステップ１６０８では、検証結果の値を調べて、「○」のときは、ステップ１６０９へ進む。
ステップ１６０９では、表示時に行を同じにするために、すでに表示済みの入力情報、検証結果の表示位置調査を行う。本例では、IndexActionが処理済であるが、この行は、入力情報、出力情報がともに存在しない。そのため、ListActionの最上位置にcondition、○を仮に位置付けて、ステップ１６０６へ進む。
次に、ステップ１６０６では、出力情報があるかどうかを調べる。ListAction、condition、○、‐には出力情報がないため、ステップ１６０１へ戻る。
次に、１行読み込んだListAction、condition、○、‐に対して処理をする。
まず、ステップ１６０３で業務処理コンポーネントを調べると、直前まで処理をしていた業務処理コンポーネントと違う(ステップ１６０３ Y)ため、ステップ１６０４へ進む。ステップ１６０４では、先に検証を行った行IndexAction、‐、‐、‐の情報があるので、ステップ１６０７へ進み、IndexActionの行の情報を表示する。この段階で、先に取得した行(IndexAction、‐、‐、‐)への処理が終了する。
IndexActionの行の情報を表示した後、ステップ１６０５へ進み、ListActionの行の処理を進める。
まず、ステップ１６０５で入力情報と検証結果を調べると、conditionと「○」があるため、ステップ１６０８へ進む。
ステップ１６０８では、検証結果の値を調べて、「○」のときは、ステップ１６０９へ進む。
ステップ１６０９では、表示時に行を同じにするために、すでに表示済みの入力情報、検証結果の表示位置調査を行う。本例では、IndexActionが処理済であるが、この行は、入力情報、出力情報がともに存在しない。そのため、ListActionの最上位置にcondition、○を仮に位置付けて、ステップ１６０６へ進む。
次に、ステップ１６０６では、出力情報があるかどうかを調べる。ListAction、condition、○、‐には出力情報がないため、ステップ１６０１へ戻る。
ステップ１６０１へ戻り、次の行を取得すると、ListAction、username、△、‐を取得する。その後、既に説明したように、ステップ１６０３へ進み、直前に処理をしていた業務処理コンポーネントと同じ業務処理コンポーネントかどうかを調べる。本例では、ListActionで同じ(ステップ１６０３ Y)であるので、ステップ１６０５へ進む。
ステップ１６０５では、既に説明したように入力情報と検証結果を取得する。本例では、usernameと「△」を取得する。入力情報と検証結果があるので、ステップ１６０８へ進む。
ステップ１６０８では検証結果が「○」かどうかを判断するが、本実施例は「△」であるので、ステップ１６０８ではNoとなり、ステップ１６１０へ進む。
ステップ１６１０では、入力情報の表示位置の仮特定を行う。既に述べているように、検証結果が「△」の場合、保持情報から情報を取得して業務処理コンポーネントが使用するプログラムがかかれているが、情報の過不足検証の結果、保持情報から取得できないことを表す。そのため、表示位置として、他の行と関連することはない。本例では、上方から順次表示するもとのとして表示位置を決定する。
表示位置を特定したら、ステップ１６０６へ進み、出力情報を取得する。本例のこの段階でのListAction行は、出力情報はない(ステップ１６０６ N)ため、ステップ１６０１へ戻り、次の行を取得する。
ステップ１６０５では、既に説明したように入力情報と検証結果を取得する。本例では、usernameと「△」を取得する。入力情報と検証結果があるので、ステップ１６０８へ進む。
ステップ１６０８では検証結果が「○」かどうかを判断するが、本実施例は「△」であるので、ステップ１６０８ではNoとなり、ステップ１６１０へ進む。
ステップ１６１０では、入力情報の表示位置の仮特定を行う。既に述べているように、検証結果が「△」の場合、保持情報から情報を取得して業務処理コンポーネントが使用するプログラムがかかれているが、情報の過不足検証の結果、保持情報から取得できないことを表す。そのため、表示位置として、他の行と関連することはない。本例では、上方から順次表示するもとのとして表示位置を決定する。
表示位置を特定したら、ステップ１６０６へ進み、出力情報を取得する。本例のこの段階でのListAction行は、出力情報はない(ステップ１６０６ N)ため、ステップ１６０１へ戻り、次の行を取得する。
ステップ１６０１へ戻り、次の行を取得すると、ListAction、usercode、×、‐となる。ステップ１６１０まで、これまでと同じ処理を行う。ステップ１６１０により検証結果が「×」の処理を行う。既に述べているように、検証結果が「×」の場合、エンドユーザ入力情報を保存するコンポーネントから情報を取得して業務処理コンポーネントはするプログラムがかかれているが、情報の過不足検証の結果、取得できないことを表す。そのため、表示位置として、他の行と関連することはない。本例では、上方から順次表示するもとのとして表示位置を決定する。
表示位置を特定したら、ステップ１６０６へ進み、出力情報を取得する。本例のこの段階でのListAction行は、出力情報はない(ステップ１６０６ N)ため、ステップ１６０１へ戻り、次の行を取得する。
表示位置を特定したら、ステップ１６０６へ進み、出力情報を取得する。本例のこの段階でのListAction行は、出力情報はない(ステップ１６０６ N)ため、ステップ１６０１へ戻り、次の行を取得する。
次の行は、ListAction、-、-、resultである。ステップ１６０６まで同様の処理を行う。本例のこの段階では、resultという出力情報があるため(ステップ１６０６ Y)、ステップステップ１６１１へ進む。
ステップ１６１１では、同じ業務処理コンポーネントで、入力情報と出力情報の表示位置を合わせる処理を行う。
まず、ステップ１６１１では、図１５の過不足検証結果の保持テーブルを検索し、業務コンポーネントの入力情報になっているかどうか調べる。本例のこの段階のresultは、LitActionの入力情報ではない(ステップ１６１１ N)ため、出力情報の最上位に仮決めとして配置する(ステップ１６１２)。
次に、ステップ１６０１へ戻って次の行に対して処理を行う。ここで、次に取得する行は、ListAction、-、-、STATUS_CODEであるが、ListAction、-、-、resultと同じため、説明は省略して次の行を取得したところから説明をする。
ステップ１６１１では、同じ業務処理コンポーネントで、入力情報と出力情報の表示位置を合わせる処理を行う。
まず、ステップ１６１１では、図１５の過不足検証結果の保持テーブルを検索し、業務コンポーネントの入力情報になっているかどうか調べる。本例のこの段階のresultは、LitActionの入力情報ではない(ステップ１６１１ N)ため、出力情報の最上位に仮決めとして配置する(ステップ１６１２)。
次に、ステップ１６０１へ戻って次の行に対して処理を行う。ここで、次に取得する行は、ListAction、-、-、STATUS_CODEであるが、ListAction、-、-、resultと同じため、説明は省略して次の行を取得したところから説明をする。
次にListAction、-、-、conditonの行に対する処理の説明を行う。これまでの処理と同様にして、ステップ１６１１まで進む。ステップ１６１１の処理により、conditionが、ListActionの入力情報になっていることが、図１５の過不足検証結果の保持テーブルを、業務コンポーネントと入力情報のペアで検索することでわかる(ステップ１６１１ Y)ので、ステップ１６１３へ進み、ステップ１６１０またはステップ１６０９で設定された表示位置と同じ行に配置する。このとき、その箇所にすでに出力情報があるときは、既にある行より下の行を、下方向に移動させて、行挿入を行う。
繰り返しになるが、同様の処理をして、DetailAction、condition、○、-の行の入力情報は、condition、○が、ListActionの入力情報にあるため、DetailActionの入力情報の位置として同じ位置に仮決めする(ステップ１６０９)。
図１５の過不足検証結果の保持テーブルのすべての行に対し処理をしたならば、処理を終了する。
図１５の過不足検証結果の保持テーブルのすべての行に対し処理をしたならば、処理を終了する。
図１７は、過不足検証結果のテーブルの情報を表示した例を示すものである。本例では、業務処理コンポーネントが実行される順序で左から右へ横に表示する。
１７０１の領域に業務処理コンポーネントを表示する。入力情報１７０２には、当該業務処理コンポーネントが業務処理を行うために必要な情報を表示する。検証結果１７０３には本発明の検証結果を表示する。出力情報１７０４には、当該業務処理コンポーネントが業務処理をした結果である出力情報を表示する。
例えば、図１７では、ListActionという業務処理コンポーネントは、入力情報としてcondition１７０５があり、その検証結果が「○」１７０６であるので、情報は業務処理で取得するようにプログラムされていることがわかる。また本例では、ListActionの業務処理の結果としての出力結果にcondition１７０７があることがわかる。図１６の処理により保持情報は、１７０８の領域に表示され、入力情報は１７０９の領域に表示され、出力情報は１７１０の領域に表示される。
１７０１の領域に業務処理コンポーネントを表示する。入力情報１７０２には、当該業務処理コンポーネントが業務処理を行うために必要な情報を表示する。検証結果１７０３には本発明の検証結果を表示する。出力情報１７０４には、当該業務処理コンポーネントが業務処理をした結果である出力情報を表示する。
例えば、図１７では、ListActionという業務処理コンポーネントは、入力情報としてcondition１７０５があり、その検証結果が「○」１７０６であるので、情報は業務処理で取得するようにプログラムされていることがわかる。また本例では、ListActionの業務処理の結果としての出力結果にcondition１７０７があることがわかる。図１６の処理により保持情報は、１７０８の領域に表示され、入力情報は１７０９の領域に表示され、出力情報は１７１０の領域に表示される。
２０１ 検証システム
２０２ ソース情報取得手段
２０３ 遷移情報取得手段
２０４ 検証処理実行手段
２０５ 結果表示手段
２０６ 開発対象格納手段
２０７ ソースファイル
２０８ 遷移情報
２０９ エンドユーザ入力情報テーブル
２１０ 業務処理情報テーブル
２１１ 遷移情報テーブル
２０２ ソース情報取得手段
２０３ 遷移情報取得手段
２０４ 検証処理実行手段
２０５ 結果表示手段
２０６ 開発対象格納手段
２０７ ソースファイル
２０８ 遷移情報
２０９ エンドユーザ入力情報テーブル
２１０ 業務処理情報テーブル
２１１ 遷移情報テーブル
Claims (3)
- 開発されたソフトウェアで使用する入力情報、出力情報及び内部の保持情報の過不足を検証する入出力情報及び保持情報の検証システムであって、
開発されたソフトウェアのソースコード及び画面遷移情報を記憶手段から取得し、取得したソースコードからエンドユーザが入力すべき入力情報を解析すると共に、前記画面遷移情報から画面遷移を解析し、さらに前記入力情報に対して業務処理を行う複数のコンポーネントが入出力する入出力情報及び内部記憶手段の保持情報を画面遷移に従って解析する第１の手段と、
前記第１の手段による解析結果の情報に基づき、各コンポーネントの処理タイミングにおいて各コンポーネントが必要とする入出力情報及び内部の保持情報に過不足がないかどうかを画面遷移に従って検証し、その検証結果を出力する第２の手段と
を備えることを特徴とするソフトウェアの入出力情報及び保持情報の検証システム。 - 前記第１の手段は、ソースコード中に記述されている入力情報の取得元や取得方法により、各コンポーネントが入力する情報が、エンドユーザによって入力される情報であるか、内部記憶手段の保持情報であるかを解析することを特徴とする請求項１に記載のソフトウェアの入出力情報及び保持情報の検証システム。
- 前記第１の手段は、ソースコード中に記述されている各コンポーネントの出力情報の設定先や設定方法により、各コンポーネントの出力情報が内部記憶手段の保持情報になるか否かを解析することを特徴とする請求項１または２に記載のソフトウェアの入出力情報及び保持情報の検証システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007134015A JP2008287642A (ja) | 2007-05-21 | 2007-05-21 | ソフトウェアの入出力情報及び保持情報の検証システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007134015A JP2008287642A (ja) | 2007-05-21 | 2007-05-21 | ソフトウェアの入出力情報及び保持情報の検証システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2008287642A true JP2008287642A (ja) | 2008-11-27 |
Family
ID=40147284
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007134015A Pending JP2008287642A (ja) | 2007-05-21 | 2007-05-21 | ソフトウェアの入出力情報及び保持情報の検証システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2008287642A (ja) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05181655A (ja) * | 1991-12-27 | 1993-07-23 | Nissan Motor Co Ltd | 仕様表示装置 |
| JP2002014846A (ja) * | 2000-06-28 | 2002-01-18 | Ntt Comware Corp | ジョブ検査装置、ジョブ検査方法、及びジョブ検査プログラムを記録した記録媒体 |
| JP2004272303A (ja) * | 2003-03-04 | 2004-09-30 | Hitachi Software Eng Co Ltd | アクセス処理手段開発支援装置及びアクセス処理プログラム |
| JP2005339268A (ja) * | 2004-05-27 | 2005-12-08 | Nomura Research Institute Ltd | 整合性チェックプログラム及び方法 |
| JP2006260498A (ja) * | 2005-03-15 | 2006-09-28 | Inos:Kk | Ｈｔｍｌ全自動プログラム解析動作方法 |
-
2007
- 2007-05-21 JP JP2007134015A patent/JP2008287642A/ja active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05181655A (ja) * | 1991-12-27 | 1993-07-23 | Nissan Motor Co Ltd | 仕様表示装置 |
| JP2002014846A (ja) * | 2000-06-28 | 2002-01-18 | Ntt Comware Corp | ジョブ検査装置、ジョブ検査方法、及びジョブ検査プログラムを記録した記録媒体 |
| JP2004272303A (ja) * | 2003-03-04 | 2004-09-30 | Hitachi Software Eng Co Ltd | アクセス処理手段開発支援装置及びアクセス処理プログラム |
| JP2005339268A (ja) * | 2004-05-27 | 2005-12-08 | Nomura Research Institute Ltd | 整合性チェックプログラム及び方法 |
| JP2006260498A (ja) * | 2005-03-15 | 2006-09-28 | Inos:Kk | Ｈｔｍｌ全自動プログラム解析動作方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7877732B2 (en) | Efficient stress testing of a service oriented architecture based application | |
| US11449348B2 (en) | Pre/post deployment customization | |
| US20050229043A1 (en) | System and method for software testing | |
| US11775262B2 (en) | Multi-technology visual integrated data management and analytics development and deployment environment | |
| US20030115572A1 (en) | System, method and computer program product for application development using a visual paradigm to combine existing data and applications | |
| US20100281467A1 (en) | Method and apparatus for automatic software testing | |
| US8661416B2 (en) | Method and apparatus for defining and instrumenting reusable Java server page code snippets for website testing and production | |
| US20070073724A1 (en) | System and method for automatic or semi-automatic software integration | |
| US11615018B2 (en) | Automation testing tool framework | |
| CN112540924A (zh) | 接口自动化测试方法、装置、设备及存储介质 | |
| CN113704110A (zh) | 用户界面的自动化测试方法及装置 | |
| CN116719735A (zh) | 一种测试用例生成方法及装置 | |
| US7882205B2 (en) | Device setting apparatus, device setting method, information acquiring apparatus, information acquiring method, storage medium, and program | |
| US10545729B2 (en) | Computer program interface | |
| US20190286453A1 (en) | System construction assisting apparatus, method, and program | |
| JP2005128658A (ja) | 業務／生産プロセス構築・実行支援装置、業務／生産プロセス支援方法、プログラム | |
| US11216347B1 (en) | Automatically locating resources using alternative locator expressions during heterogeneous component-based testing in a portable automation framework | |
| JP6436704B2 (ja) | テスト実行装置、テスト実行方法およびコンピュータプログラム | |
| JP2008287642A (ja) | ソフトウェアの入出力情報及び保持情報の検証システム | |
| JP4630572B2 (ja) | 整合性チェックプログラム及び整合性チェック装置 | |
| JP2015148925A (ja) | プログラム生成装置および方法 | |
| JP6353759B2 (ja) | テスト実行装置、テスト実行方法およびコンピュータプログラム | |
| JP5097070B2 (ja) | プロパティファイル読み込みシステムと方法およびプログラム | |
| Kubala | Progressive web app with Angular 2 and ASP. NET | |
| JP2007304778A (ja) | プログラムのテスト方法、プログラム、テスト装置、及びアプリケーション開発システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100115 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20120214 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120222 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20120618 |