(57)【要約】【課題】チェック対象となる動的文書生成システムのソース構成が追加・変更されても追加・変更後のシステムに対するチェックを効率的に行うことを可能とさせることを目的としている。【解決手段】動的文書生成ソースファイルをチェックするためのルールデータを、全グループ共通に適用できるのものと、目的別グループ毎に適用できるものとに分けて記憶装置に記録させ、目的別グループ毎に前記ルールデータから対応するルールを割り当て、チェックの対象となる動的文書生成ソースファイルを前記動的文書生成ソースファイルの目的別グループ毎に割り当てられたルールデータに基づいてチェックする。【選択図】図１
2005122398.tif 000002
【特許請求の範囲】
【請求項１】
動的文書生成ソースファイルをチェックするためのルールデータを、動的文書生成ソースの目的別グループ毎に適用するものと、全グループ共通に適用できるのものと、に分けて記憶装置に記録させるルール登録手段と、
目的別グループ毎に前記ルールデータから対応するルールを割り当てるルール割当手段と、
チェックの対象となる動的文書生成ソースファイルを前記動的文書生成ソースファイルの目的別グループ毎に割り当てられたルールデータに基づいてチェックするソースチェック手段として
コンピュータを機能させる動的文書生成ソースファイルチェックプログラム。
【請求項２】
前記ソースチェック手段は、動的文書生成ソースファイルのチェック結果を分析し、品質情報として記憶装置に記録させることを特徴とする請求項１記載の動的文書生成ソースファイルチェックプログラム。
【請求項３】
前記グループは、文書の用途、または表示装置の種類を元にグループ分けされていることを特徴とする請求項１記載の動的文書生成ソースファイルチェックプログラム。
【請求項４】
動的文書生成ソースファイルをチェックするためのルールデータを、動的文書生成ソースの目的別グループ毎に適用するものと、全グループ共通に適用できるのものと、に分けて記憶装置に記録させるルール登録手段と、
目的別グループ毎に前記ルールデータから対応するルールを割り当てるルール割当手段と、
チェックの対象となる動的文書生成ソースファイルを前記動的文書生成ソースファイルの目的別グループ毎に割り当てられたルールデータに基づいてチェックするソースチェック手段と
を有することを特徴とする動的文書生成ソースファイルチェック装置。
【請求項５】
動的文書生成ソースファイルをチェックするためのルールデータを、動的文書生成ソースの目的別グループ毎に適用するものと、全グループ共通に適用できるのものと、に分けて記憶装置に記録させるステップと、
目的別グループ毎に前記ルールデータから対応するルールを割り当てるステップと、
チェックの対象となる動的文書生成ソースファイルを前記動的文書生成ソースファイルの目的別グループ毎に割り当てられたルールデータに基づいてチェックするステップと
を有することを特徴とする動的文書生成ソースファイルチェック方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動的文書生成に関し、特に、利用者がWebブラウザから出す要求に応じて、動的にHTML文書やXML文書を生成し、利用者のWebブラウザに送り返すシステムにおいて、動的にHTML文書やXML文書を生成する元となるソースファイルをシステム開発・保守フェーズで検査する技術に関したものである。
【背景技術】
【０００２】
Webサーバを用いた企業間商取引システムや電子カタログシステム、情報発信システムなどでは、利用者がWebブラウザから出す要求に応じて動的にHTMLを生成して利用者に提示するのが一般的である。その場合、動的文書生成ソースファイル作成用の言語としてはJava Server Pages(JSP)、eXtensible Markup Language(XML)、ColdFusion Markup Language(CFML)などがある。（Javaは、米国 Sun Microsystems, Inc.の登録商標、ColdFusionは米国Macromedia, Inc.の登録商標です。）
従来、上記のような動的文書生成システムでは、動的文書生成ソースファイル、及び動的生成された文書を目視によるチェックで対処していた。しかしながら、目視によるチェックだけではチェック項目に漏れが生じることが多いためＷebFile社が提供しているWeblintと呼ばれるHTML文法チェッカなどを使って、実際にWebブラウザから操作したときの応答として帰ってくるHTMLの文法チェックを行うことで動的文書生成されたＨＴＭＬのチェックを自動化することも行われるようになってきた。
【０００３】
しかしながら、従来の動的文書生成システムでは、動的HTMLソースを実行した結果としてのHTMLにおける文法エラーしか分からなかった。そのため、結果としてのHTMLにおける構文エラー(たとえば、記述しなければならないタグが存在しないとか、タグの記述順序が正しくないなど)から、元ソースの記述のどこに問題があるのかを判断するには、各ソース記述言語(例えばJSP、CFML)に関する文法やHTMLへの変換手順に関する知識が必要になる。更に、動的文書生成システムが動作する全ての条件についてチェックしたかどうか、すなわち網羅性についてはチェック担当者が保証しなければならなかった。
【０００４】
一方、プログラムファイルの検査の場合でも、例えば構文チェックでは引っ掛からないような論理的エラーなどは、マシンデバッグの後工程にならないと満足なプログラムチェックができなかった。そのため、コンパイラにおいては外部から入力されるルールに従ってプログラムチェックを行うことができるようにすることにより、構文チェックおよび形式チェック以外の論理チェックを行えるとともに、利用者の指定する付加的なルールでもプログラムチェックが行えるようにしたプログラムチェック方式（例えば特許文献１参照）が開示されている。
【０００５】
また、ソースプログラムを効率よくチェックすることができる汎用性に優れたソースプログラムの汎用チェックシステムとして、必要な制約条件をルール化して格納したルールファイルと、このルールファイルから入力された制約条件を解析してルールテーブルに展開する手段と、前期ルールテーブルに展開された制約条件に基づいてチェックの対象のソースプログラムをチェックし、制約条件を満足しない部分についてエラーメッセージを出力する手段を備えたソースプログラムの汎用チェックシステムに関する技術が開示されている（例えば特許文献２参照）。
【０００６】
そこで、従来の動的文書生成システムに特許文献１や特許文献２で開示されているコンパイラの技術を適用すると、いくつかのテストパターンを用意して、各テストパターンで生成された文書をチェックするのではなく、文書を生成するソースをチェックすることにより、チェック結果から文書生成ソースにおける不具合個所を直接発見できるようにはなる。また、チェックルールとして全ての想定ケースをチェックできるルールを用意することで網羅性に関する問題点も改善される。
【特許文献１】特開昭６３−２６３５４５号公報
【特許文献２】特開平８−１０１７８７１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１や特許文献２で開示されている技術を、従来の動的文書生成システムに適用しただけでは、まだ以下の問題が発生する。
（１）全てのソースファイルに同じルールを適用するため、ルール適用作業の効率が悪い。
【０００８】
動的HTMLのソースに関するチェックルールとしては、例えば以下のものが挙げられる。
【０００９】
（ａ）ソース中に必要となる記述があるかどうか
（ｂ）ソース中に、出現してはならない記述があるかどうか
（ｃ）ソース中に、ある表現Aが出現した場合、それに伴って必要となる記述があるかどうか
（ｄ）ソース中に、ある表現Aが出現した場合、それによって記述してはいけない記述があるかどうか
現状のWebブラウザでもベンダやバージョン／レベル毎による非互換があり、さらにWeb端末の多様化(たとえば携帯電話や情報家電など)やWeb技術の進歩に伴い、これらのルールの数は今後更に増えていくはずである。このため、全てのソースファイルに対し、膨大な数のルールで構成されるチェックルール集合を適用する場合、チェックに要する時間の増大をどう抑えるかが課題となってくる。
（２）特定用途のシステム向きにチェックルールを追加すると、他の用途のシステムに適用するのが困難になる。すなわち、カストマイズ性が悪くなる
例えば、商取引システムで特定のWebブラウザを対象として設計したシステムに対するチェック方法を実現したとする。そこで、この商取引システムの対象とするWebブラウザの版を変えると、従来の技術では元々対象としていたWebブラウザに関するルールを膨大なルール集合の中から探し出し、新しく対象とするWebブラウザに関するルールに置き換えるという作業をしなければならない。同じような問題は商取引システムで採用している、動的にHTMLを生成する仕掛けを一部変更した場合とか、商取引システムで提供するサービス内容を一部追加または変更した場合にも生じる。
【００１０】
本発明は、チェック対象となる動的文書生成システムのソース構成が追加・変更されても追加・変更後のシステムに対するチェックを効率的に行うことを可能とさせることを目的としている。
【課題を解決するための手段】
【００１１】
図１は、本発明の実施例の全体構成図を示すものである。本発明の動的文書生成プログラム１０は動的文書生成装置１として振る舞うコンピュータ上で実行され、動的文書生成ソースファイルをチェックするためのルールデータを、目的別グループ毎に適用するものと、全グループ共通に適用できるのものと、に分けて記憶装置に記録させるルール登録手段１２１と、目的別グループ毎に前記ルールデータから対応するルールを割り当てるルール割当手段１２２と、チェックの対象となる動的文書生成ソースファイルを前記動的文書生成ソースファイルの目的別グループ毎に割り当てられたルールデータに基づいてチェックするソースチェック手段１２３としてコンピュータを機能させるものであり、チェック対象となる動的文書生成システムのソース構成が追加・変更されても追加・変更後のシステムに対するチェックを効率的に行うことを可能となる。
【００１２】
また、ソースチェック手段１２３は、動的文書生成ソースファイルのチェック結果を分析し、品質情報として外部記憶装置２上の品質情報ファイル２４に記憶させることにより、例えばグループ毎にソースファイル単位行あたりのNGの件数を原因別に集計した品質情報の表示が可能となる。この情報を分析することでグループごとにどのルールに対する違反が多いかを割り出すことができ、割り出した情報を元に、グループごとのルールの適用優先順位をつけることなどが可能となる。
【発明の効果】
【００１３】
チェック対象となる動的文書生成システムのソース構成が追加・変更されても追加・変更後のシステムに対するチェックを効率的に行うことを可能となる。
【発明を実施するための最良の形態】
【００１４】
既存の動的文書生成プログラムに対して、ソースチェック拡張機能として機能追加できるように構成しているため、新規にソースチェックプログラムを開発した場合にも、既存の動的文書生成プログラムに対する機能追加も可能となる。
【実施例１】
【００１５】
図１は、本発明の実施例の全体構成図を示すものである。本発明の動的文書生成プログラム１０は動的文書生成装置１として振る舞うコンピュータ上で実行され、従来の動的文書生成プログラム本体１１にソースチェック拡張機能部１２を追加して、ルール登録手段１２１は動的文書生成ソースファイルをチェックするためのルールデータを、全グループ共通に適用できるものと、目的別グループ毎に適用できるものとに分けて外部記憶装置２上の共通ルールファイル２２と個別ルールファイル２３に記録させる。
【００１６】
そして、ルール割当手段１２２は、ソースファイル２１に格納されている動的文書生成ソースファイルに対して、ルール登録手段１２１が外部記憶装置２上に記憶させた共通ルールファイル２２、及び個別ルールファイル群２３の中から前記動的文書生成ソースファイルの目的別グループに応じた個別ルールファイルを選択して割り当てる。
【００１７】
更に、ソースチェック手段１２３は、チェックの対象となる動的文書生成ソースファイルを前記動的文書生成ソースファイルの目的別グループ毎に割り当てられたルールデータに基づいてチェックすることにより、チェック対象となる動的文書生成システムのソース構成が追加・変更されても追加・変更後のシステムに対するチェックを効率的に行うことを可能となる。
【００１８】
また、ソースチェック手段１２３は、動的文書生成ソースファイルのチェック結果を分析し、品質情報として外部記憶装置２上の品質情報ファイル２４に記憶させることにより、例えばグループ毎にソースファイル単位行あたりのNGの件数を原因別に集計した品質情報の表示が可能となる。この情報を分析することでグループごとにどのルールに対する違反が多いかを割り出すことができ、割り出した情報を元に、グループごとのルールの適用優先順位をつけることなどが可能となる。
【００１９】
外部装置２には、グループ化した動的文書生成ソースファイルを格納したソースファイル２１、全グループ共通に適用できるルールを記憶した共通ルールファイル２２、目的別グループ毎に適用できるルールを記憶した個別ルールファイル群２３、品質情報を記憶した品質情報ファイル２４が格納されている。本実施例では、品質情報ファイルは共通ルールファイル及び個別ルールファイルが兼用している。それぞれのファイルのデータ構造については後述する。
【００２０】
グループ分けについては、例えば電子商取引システムを構成する文書(画面)生成ソース(JSP)の場合、文書(画面)の用途により、センタ管理者用、購買管理および販売管理用、購買申請および販売担当用、認証なしで文書(画面)を閲覧できる認証なしユーザ用の４つのグループ分けが可能である。センタ管理者用の文書(画面)の例としてはログインメッセージの編集、情報の有効期限の設定、利用者の登録などがある。購買管理および販売管理用の文書(画面)の例としては伝票や伝票への回答に対する承認、伝票照会や伝票の回答照会などがある。購買申請および販売担当用の文書としては、伝票の発行、伝票に対する回答操作などがある。認証なしユーザ用の文書(画面)としては商品情報の検索などがある。
【００２１】
文書(画面)のグループ分けとしては、このような分け方以外にも、画面の外枠/画面の中身に分ける方法や、文書を表示する装置(Webブラウザなど)による分け方がある。
【００２２】
図２は、動的文書生成ソースファイル作成用の言語としてＸＭＬを使用した場合のルールの記述例が示してある。<ruleset>から</ruleset>までがルールの定義であり、<group>から</group>までがグループの定義を表している。<group-name>Container</group-name>はグループContainerのルールの定義であることを表している。<rule>から</rule>までが一つのルールの定義を表している。
【００２３】
<type>must-exist</type>と<expression>”<uji:dispatch/>”</expression>で記述されたルールでは<uji:dispatch/>が必須であることを表している。
【００２４】
<type>mustnot-exist</type>と<expression>”<uji:bean>”</expression>で記述されたルールでは、<uji:bean>があってはならないことを表している。
【００２５】
<type>must-coexist</type>と<expression>”<html>”</expression>と
<related>”</html”></related>で記述されたルールでは<html>という記述がある場合には、</html>も存在することが必須であることを表している。
【００２６】
<rule>mustnot-coexist</type>と<custamizable/>と<expression>”exp1”</expression>と<related>”<tag1 val=1>”</related>と
<related>”<tag2 attr1=val1 attr2=val2>”</related>で記述されたルールでは、exp1という記述がある場合、<tag1 val=1>および<tag2 attr1=val1 attr2=val2>があってはならないことを表している。なお、このルールはカストマイズで追加した例である。
【００２７】
図３は、本発明におけるルールの内部表現の例が示してある。まず本発明のルールについて説明する。本発明においてルールと呼ぶものには、以下のものがある。
[1] 文書生成ソースに特定の表現が記述されていること。
[2] 文書生成ソースに特定の表現が記述されていないこと。
[3] 文書生成ソースに表現Aが記述されている場合、関連する表現としてBが記述されていること。
[4] 文書生成ソースに表現Aが記述されている場合、表現Bが記述されていないこと。
[5] 表現Aと表現Bが現れている場合、表現Aは表現Bの内部に存在すること。
【００２８】
[3]、[4]において表現Bは１つの表現の場合、複数の表現の場合がある。
[1]の例としては以下がある。
【００２９】
エラーメッセージ以外のJSPソースには、<@ page errorPage=  >の記述が存在しなければならない。
[2]の例としては例えば以下の規約がある。
【００３０】
HTML文書の中身の部分を生成するソースには、<html>、</html>、<head>、</head>、<body>、<body>の記述があってはならない。
[3]の例としては例えば以下の規約がある。
【００３１】
JavaScript関数呼び出し記述がある場合、JavaScript関数の定義またはJavaScriptファイルの宣言がなければならない。
[4]の例としては例えば以下の規約がある。
【００３２】
各タグは<html>、</html>のように対で記述しなければならない。
[5]の例としては例えば以下の規約がある。
【００３３】
<input>タグは<form>〜</form>の内部に記述しなければならない。
【００３４】
次にルールに関するデータ構造について説明する。本発明においては、ルールは全ソースグループ共通のものと特定のソースグループに共通のものがある。このため、本発明におけるソースチェック拡張機能部１２ではソースグループとソースグループに適用されるルールのリストの対応表を持つ。各ルールは以下の情報を持つ。
−記述木は、ルールによりチェックされる表現を木構造で表現した情報。
−規約型は、ルールが前述の[1]〜[5]のうちどの型のものかを表す。
−チェックフラグは、チェックを実施するかしないかを指定するフラグ。
−チェック対象表現の有無は、チェックを行う対象となる表現があったかどうか表す。
−結果は、このルールによるチェックがOKかNGかを表す。
−関連記述木は、規約が前述の[3]〜[5]の場合、記述木で表される表現と関連付けられる表現を表す。
【００３５】
関連記述木の先には、チェックされる表現と関連付けられる表現の木構造表現情報と、その表現が出現したかどうかを表す出現フラグの対のリストがリンクされる。また、チェックの対象となるソースファイルが画像ファイルなどの他ファイル(資源)を参照する場合、ソースファイルの所属するグループ、そのグループが参照する資源のタイプ(画像、スクリプトファイル、スタイルシートなど)、資源に対応するファイルの格納場所（ソースファイルを格納するディレクトリからの相対位置）の情報を持つ。
【００３６】
図４は、ルールでチェックされるソースファイルに対する記述木の表現例が示してある。図４ではHTMLのイメージタグの例を示してある。木構造の末端ノードには、イメージタグの開始を示す”img”や、イメージタグ中に出現する属性とその値(例:src、width、height、alt属性とその値)が設定される。末端ノードが属性名の場合、制約情報として、その属性が必須かどうかの情報が付与される。末端ノードが属性値の場合、制約情報はルールでチェックするのか、特定の制約条件（たとえば、widthやheightの場合値が0より大きいという固定の制約条件）でチェックするかを指示する情報が付与される。固定の制約条件でチェックする場合はチェックに用いる制約条件を情報として持つ。
【００３７】
図５は、図３のルールと図４の木構造表現を使った、ソースファイルに出現する表現のチェック方法が示してある。ソースファイルに出現する表現を木構造展開して生成された木構造(図５の左側の木構造)と、ルールに関連付けられた木構造(図５の右側の木構造)を照合して、木構造として一致する場合はソースファイルに出現する木構造が、そのルールによるチェックの対象とみなす。チェックの対象とみなされた表現に対し、ルールを適用するまえに木構造の各末端ノードに関連付けられた制約条件を順次チェックしていき、ソースファイルに出現した表現が単独でルールを満足するかどうかチェックする。
【００３８】
図６は、例えばソースファイル単位行あたりのNGの件数を原因別に集計したような品質情報の例が示してある。ここではソースファイルを外枠、センタ管理、会員専用、公開の４つのグループに分け、各グループに対し各ルールのNGの件数を表示している。この情報を分析することでグループごとにどのルールに対する違反が多いかを割り出すことができる。割り出した情報を元に、グループごとのルールの適用優先順位をつけることができる。優先順位のつけ方としては例えば、違反数が多かったルールを優先的に適用するといった付け方が考えられる。
【００３９】
図７は品質情報を採取するために、図３で示したルールに関するデータ構造に品質情報を追加した例が示してある。図７では出現行情報として、ルールの対象となる表現が出現した行と、各行に対するルール適用の結果(OKまたはNG)の情報を蓄積し、あとでNGの数を集計して、図７の下側にあるような集計情報を出力する。
【００４０】
図８は、本発明に係る動的文書生成ソースファイルチェック拡張機能部の処理の流れを示すフローチャートである。先ず、該当するソースファイルのグループがチェック対象がどうかを判定する（Ｓ８０１）。判定の方法は、例えばソースファイルをグループ識別情報を表すフォルダーに格納しておくか、ソースファイルの制御情報にグループを識別する情報を格納しておくなどして、チェックの対象となるソースファイルがどのグループに属しているか調べ、そのグループが図３で示したようなルールに関したデータに対応するグループ識別子があるかどうかを判定する。
【００４１】
チェックの対象となる場合には、対象となるグループ固有のルールを個別ルールファイル群２３から読み込む（Ｓ８０２）。次に共通ルールファイル２２に記憶させてある全グループ共通のルールを読み出し、Ｓ８０２で読み込んだ規約を追加し、チェックリストを生成する（Ｓ８０３）。次にチェックの対象となるソースファイルに対し、チェック結果出力ファイルをOPENし（Ｓ８０４）、ソースファイルの読み込みとチェックを実行する（Ｓ８０５）。本処理の詳細については、図９を参照されたい。チェックが終了すると、チェック結果出力ファイルに結果を出力し（Ｓ８０６）、チェック結果出力ファイルをCLOSE（Ｓ８０７）して動的文書生成ソースファイルチェック拡張機能部の処理は終了する。
【００４２】
図９は、本発明に係る動的文書生成ソースファイルチェック拡張機能部のソースファイル読み込み処理、及びチェック処理の流れを示すフローチャートである。ソースファイルをOPENし（Ｓ９０１）、ソースファイルが終了するまで以下を繰り返す。
【００４３】
ソースファイルの1つの記述単位を読み込んで（Ｓ９０２）、読み込んだ記述単位を図４で示したような木構造に展開する（Ｓ９０３）。次に図５で示すようにＳ８０３で作成したルールリスト上の展開パターンとソースファイル上の一致する木構造表現を検索する（Ｓ９０４）。次に、展開パターンが一致する木構造の各末端ノードが持つ制約条件を、ソースから展開した木構造の対応する末端ノードが満たしているかどうかチェックする（Ｓ９０５）。チェックの結果制約を満たしていない場合はチェックNGとするためにcheck欄をfalseとする（Ｓ９０６）。ソースファイルが終了かどうか判定し（Ｓ９０７）、終了の場合は処理を終わる。終了出ない場合にはＳ９０２に戻る。
【００４４】
制約条件を満たしている場合には、木構造に対応するチェックルールのタイプを規約型で判定し(Ｓ９０８)、以下の処理を行う。記述が必須［１］というルールで、かつそのルールを適用する場合は、ルールの「記述存在フラグ」である有無欄をtrueにし、ルールのチェック結果をOKにするために結果欄をtrueとする（Ｓ９０９）。記述禁止［２］というルールでかつそのルールを適用する場合は、ルールの「記述存在フラグ」である有無欄をtrueにし、ルールのチェック結果をNGとするために結果欄をfalseにする（Ｓ９１０）。この記述に関連して別の記述が存在しなければならない型［３］のルールを適用する場合は木構造の存在フラグである有無欄をtrueとし、この記述に対し1つ以上の関連記述木の出現フラグがfalseならこの記述に対するチェック結果をfalseにする（Ｓ９１１）。
【００４５】
また、この記述に関連して別の記述が存在してはならない型［４］のルールを適用する場合は、木構造の存在フラグである有無欄をtrueとし、この記述に対し1つ以上の関連記述木の出現フラグがtrueならこの記述に対するチェック結果をfalseにする（Ｓ９１２）。
【００４６】
この記述が別の記述Bの中に存在しなければならない型［５］のルールを適用する場合は、記述Bの開始表現が出てきた時点でフラグを設定し、記述Bの終了が出てきたらフラグをリセットするようにする。フラグがリセットされないうちにファイルが終了した場合は、記述に対するチェック結果はNGとするために結果欄をfalseとする（Ｓ９１３）。
【００４７】
図１０は、品質情報を採取する場合の本発明に係る動的文書生成ソースファイルチェック拡張機能部の処理の流れを示すフローチャートである。図８と同様な処理については、詳細な説明は省略する。先ず、該当するグループがチェック対象かどうか判定し(Ｓ１００１)、該当するグループがチェック対象の場合、品質情報ファイルをOPENした（Ｓ１００２）後、グループ固有のルールを読み込み（Ｓ１００３）、全グループ共通のルールに、Ｓ１００３で読み込んだルールを追加してチェックリストを生成する（Ｓ１００４）。
【００４８】
次に、チェック結果出力ファイルをOPEN（Ｓ１００５）し、ソースファイルの読み込みとチェックを実行（Ｓ１００６）し、チェック結果出力ファイルに結果を出力（Ｓ１００７）し、チェック結果出力ファイルをCLOSE（Ｓ１００８）し、品質情報ファイルをCLOSE（Ｓ１００９）して処理を終了する。
【００４９】
図１１は、品質情報を採取する場合の本発明に係る動的文書生成ソースファイルチェック拡張機能部のソースファイル読み込み処理、及びチェック処理の流れを示すフローチャートである。図９と同様な処理については、詳細な説明は省略する。ソースファイルをOPENし（Ｓ１１０１）、ソースファイルが終了するまで以下を繰り返す。
【００５０】
先ず、ソースファイルの1つの記述単位を読み込み（Ｓ１１０２）、読み込んだ記述単位を木構造に展開し、記述の出現行をワーク領域に記録する（Ｓ１１０３）。次に、展開パターンが一致する木構造表現を検索（Ｓ１１０４）し、展開パターンが一致する木構造の各末端ノードが持つ制約条件を、ソースから展開した木構造の対応する末端ノードが満たしているかどうかチェックする（Ｓ１１０５）。チェックの結果制約を満たしていない場合はチェックNGとし（Ｓ１１０６）、ソースファイルの終了かどうかを判定する（Ｓ１１０７）。
【００５１】
木構造に対応するチェックルールのタイプを判定し（Ｓ１１０８）、タイプに応じて以下の処理を実行する。記述が必須［１］というルールで、かつそのルールを適用する場合は、ルールの「記述存在フラグ」をtrueにし、ルールのチェック結果をOKにし、OKの記録を品質情報データに追加する（Ｓ１１０９）。記述禁止［２］というルールでかつそのルールを適用する場合は、ルールの「記述存在フラグ」をtrueにし、ルールのチェック結果をNGにし、NGの記録を品質情報データに追加する（Ｓ１１１０）。
【００５２】
この記述に関連して別の記述が存在しなければならない型［３］のルールを適用する場合は木構造の存在フラグをtrueとし、この記述に対し1つ以上の関連記述木の出現フラグがfalseならこの記述に対するチェック結果をfalseにし、チェック結果を品質情報データに追加する（Ｓ１１１１）。
【００５３】
この記述に関連して別の記述が存在してはならない型［４］のルールを適用する場合は、木構造の存在フラグをtrueとし、この記述に対し1つ以上の関連記述子の存在フラグがtrueならこの記述に対するチェック結果をfalseにし、チェック結果を品質情報データに追加する（Ｓ１１１２）。
【００５４】
この記述が別の記述Bの中に存在しなければならない型［５］のルールを適用する場合は、記述Bの開始表現が出てきた時点でフラグを設定し、記述Bの終了が出てきたらフラグをリセットするようにする。フラグがリセットされないうちにファイルが終了した場合は、記述に対するチェック結果はNGとし、チェック結果を品質情報データに追加する（Ｓ１１１３）。以上の結果の集計を行い、品質情報ファイルに集計結果を追記する（Ｓ１１１４）。
【図面の簡単な説明】
【００５５】
【図１】実施例の全体構成図
【図２】ルールの記述例
【図３】ルールに関するデータ構造
【図４】ソーソファイルの内部表現
【図５】ソースファイルに対するチェック
【図６】品質情報の例
【図７】品質情報に関するデータ構造
【図８】動的文書生成ソースファイルチェック拡張機能部の処理の流れ
【図９】ソースファイル読み込み処理、及びチェック処理の流れ
【図１０】品質情報を採取する場合の動的文書生成ソースファイルチェック拡張機能部の処理の流れ
【図１１】品質情報を採取する場合のソースファイル読み込み処理、及びチェック処理の流れ
【符号の説明】
【００５６】
１      動的文書生成装置
２      外部記憶装置
３      入出力装置
１０    動的文書生成プログラム
１１    動的文書生成プログラム本体
１２    ソーソチェック拡張機能部
２１    ソースファイル
２２    共通ルールファイル
２３    個別ルールファイル
２４    品質情報ファイル
１２１  ルール登録手段
１２２  ルール割当手段
１２３  ソースチェック手段
【図１】
2005122398.tif 000003
【図２】
2005122398.tif 000004
【図３】
2005122398.tif 000005
【図４】
2005122398.tif 000006
【図５】
2005122398.tif 000007
【図６】
2005122398.tif 000008
【図７】
2005122398.tif 000009
【図８】
2005122398.tif 000010
【図９】
2005122398.tif 000011
【図１０】
2005122398.tif 000012
【図１１】
2005122398.tif 000013