JP4667386B2 - 業務モデル図作成支援プログラム、業務モデル図作成支援方法、および業務モデル図作成支援装置 - Google Patents

Description

本発明は業務モデルを図で表現する時に、作成した図の妥当性を検証する業務モデル図作成支援プログラム、業務モデル図作成支援方法、および業務モデル図作成支援装置に関し、特に検証結果をユーザに分かり易く表示するための業務モデル図作成支援プログラム、業務モデル図作成支援方法、および業務モデル図作成支援装置に関する。

ソフトウェア開発の初期段階では、顧客からの要件をモデル化するため業務モデル図が作成される。業務モデル図は、業務フロー図やデータ構造図で構成される。業務フロー図は、発生する作業の手順や、作業間で受け渡すべき情報等を、図形と文字で表現したものである。データ構造図は、データ間の関係を示す図である。業務モデル図を予め作成することで、ユーザとシステム開発担当者との間の意思の疎通を的確に図ることができる。

業務モデル図の作成は、汎用の描画ソフトウェアを利用する場合と、業務モデル図などの特別な図を描くための専用ソフトウェアを利用する場合とがある。以下、汎用の描画ソフトウェアと専用ソフトウェアとの違いを、業務フロー図を作成する場合に着目して説明する。

汎用の描画ソフトウェアを利用する場合、以下のような長所がある。
・モデル作成者がこれまで利用していたソフトウェア、あるいは安価に購入できるソフトウェアが利用可能である。
・専用ソフトウェアを利用する場合のように、ソフトウェアの操作手順等を新たに修得する必要がない。

その反面、汎用の描画ソフトウェアでは、以下のような問題が生じていた。
・業務フロー図において業務プロセスの遷移を表す線が、業務プロセスを表す図形に正しく接続されていない場合があった。
・業務フロー内の条件分岐を表す図があるにもかかわらず、分岐条件が記入されていない場合がある。
・業務フロー図として誤った描き方をしていても、誤りをチェックする機能がない。そのため、たとえば、業務フロー図においては接続できない図形どうしが、遷移を表す線で結ばれても、その間違いを検出できない。
・パーティション（図中では長方形）の中に描くべき業務プロセスがはみ出して書かれていても、検出できない。

一方、専用ソフトウェアは、モデリングエディタと呼ばれ、業務モデル図等のモデル作成用の専用エディタである。そのため、専用ソフトウェアは、業務フロー図やデータ構造図などの形式を利用した編集機能だけでなく、モデルの構造情報をソフトウェアの内部に保持する機能、モデルの構造をツリー構造で表しツリー構造内で編集機能を有する。

モデリングエディタでは、モデルの構造をツリー構造で表すために、作成された業務モデル図の解析を行っている。そのとき、遷移が業務プロセスに正しく接続されていない等の誤りが存在すると、業務モデルを解析ができないなどの不都合が生じる。そこで、モデリングエディタの中には、モデルの正しさを検証する機能を有するものがある。

たとえば、従来の検証機能では、業務モデル図中に間違いを検出すると、モデル作成者にモデル中の要素のＩＤとエラーの内容を示し、業務モデル作成者の修正を支援していた(たとえば、特許文献１参照)。
特開２００２−１３３０５１号公報（図８）

しかし、従来の専用ソフトウェアでは検証エラーの発生が表示されるのみであり、エラーの発生個所が分かりづらいという問題点がある。
たとえば、モデル構造情報の中には、ユーザが名前をつけないものもある。具体的には、業務フロー図に現れるモデルの構成要素では、遷移、判断、並列分岐などには名前を付けない。遷移や判断条件分岐は、１つの業務フローの中に多数現れる場合が多い。そのため、遷移や判断条件分岐に関わる検証エラーが発生した場合、多数あるうちのどれに検証エラーが発生したのかをユーザが目視により探すのは困難である。なお、特許文献１では、検証エラーの発生したモデル要素や図の要素の識別子をユーザに示しているが、その識別子に対応する図形等を業務フロー図内から特定することは困難である。

しかも、複雑な業務に関する業務モデルは、業務フロー図の規模も大きくなる。すると、エラーが検出されたときに、修正箇所を発見するのが非常に困難となる。
また、通常、業務モデル作成者は、業務については熟知しているがツール利用については不慣れな場合が多い。そのため、エラーメッセージだけではどのように修正してよいかが分からない。そこで、業務モデル作成者が日常的に使用しているソフトウェアに組み込まれた描画機能を用いて、業務フロー図を作成することが望まれる。

しかしながら、汎用的な描画ソフトウェアでは、業務フロー図を構成する図形に対して業務フロー上での意味づけが成されていない。そのため、汎用的な描画ソフトウェアで作成した業務フロー図が、業務モデルを表す上で適切かどうかを検証するのは困難であった。

本発明はこのような点に鑑みてなされたものであり、汎用の描画ソフトウェアで作成された業務モデルを検証し、欠陥の発生個所を業務モデル作成者に通知できる業務モデル図作成支援プログラム、業務モデル図作成支援方法、および業務モデル図作成支援装置を提供することを目的とする。

本発明では上記課題を解決するために、業務モデル図作成支援プログラムが提供される。この業務モデル図作成支援プログラムは、利用者の業務モデルの構造を表す業務モデル図の作成を支援するためのものであり、以下の機能が実現される。

モデル構造生成手段は、業務モデル図に含まれる図形を構成要素として、図形の種類に応じて異なる構成要素の種別が定義された対応定義情報に従い構成要素の種別を判別し、複数の構成要素の種別間の接続関係の定義情報に従い構成要素の種別および構成要素間の接続関係の情報を含むモデル構造情報を生成する。検証手段は、モデル構造情報に含まれる構成要素の少なくとも一部を検証対象要素として選択し、当該検証対象要素が、モデル構造情報の構成要素の種別について満たすべき条件が予め設定された検証ルールのうち、検証対象要素の種別に対応する検証ルールに適合しているか否かを検証する。検証結果表示手段は、検証手段による検証結果を示す情報を、コンピュータに接続されたモニタに表示する。

このような業務モデル図作成支援プログラムをコンピュータに実行させれば、まず、モデル構造生成手段により、業務モデル図に含まれる図形を構成要素として、図形の種類に応じて異なる構成要素の種別が定義された対応定義情報に従い構成要素の種別が判別され、構成要素の種別および構成要素間の接続関係の情報を含むモデル構造情報が生成される。次に、検証手段により、モデル構造情報に含まれる構成要素の少なくとも一部が検証対象要素として選択され、当該検証対象要素が、モデル構造情報の構成要素の種別について満たすべき条件が予め設定された検証ルールのうち、検証対象要素の種別に対応する検証ルールに適合しているか否かが検証される。そして、検証結果表示手段により、検証手段による検証結果を示す情報が、コンピュータに接続されたモニタに表示される。

本発明では業務モデル図に含まれる図形を構成要素として、構成要素の種別を判別してモデル構造情報を生成し、モデル構造情報に含まれる構成要素の種別に応じた検証ルールにより検証を行い検証結果を示す情報を表示するようにした。これにより、ユーザは、汎用的な描画ソフトウェアで作成した業務モデルの欠陥を、容易に修正することができるようになる。

本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。

実施の形態に適用される発明の概念図である。 本実施の形態に用いるコンピュータのハードウェア構成例を示す図である。 第１の実施の形態の機能ブロック図である。 業務フロー図である。 データ構造図である。 構造定義情報の例を示す図である。 端子を用いた業務フロー図の例を示す図である。 モデル構造表示画面の例を示す図である。 モデル構造定義の一部を示すＵＭＬのクラス図である。 モデル構造情報の例を示す図である。 検証ルール・対処法情報の例を示す図である。 第１の実施の形態に係る業務モデル検証処理の手順を示すシーケンス図である。 検証結果リストの例を示す図である。 モデル構造表示画面への検証エラー個所の表示手順を示すシーケンス図である。 第１の実施の形態の検証結果を示す画面の例を示す図である。 第２の実施の形態の機能ブロック図である。 第２の実施の形態に係る検証ルール・対処法情報の例を示す図である。 業務フロー表示部への検証エラー個所の表示手順を示すシーケンス図である。 第２の実施の形態の検証結果を示す画面の例を示す図である。 第３の実施の形態の機能ブロック図である。 第３の実施の形態に係る業務モデル検証処理の手順を示すシーケンス図である。 第４の実施の形態の機能ブロック図である。 図情報の例を示す図である。 第４の実施の形態に係る業務モデル検証処理の手順を示すシーケンス図である。 第５の実施の形態の機能ブロック図である。 検証ルール・対処法情報のデータ構造例を示す図である。 タイムスタンプが付与された検証結果リストの例を示す図である。 進捗状況表示画面の第１の例を示す図である。 進捗状況表示画面の第２の例を示す図である。 進捗状況表示画面の第３の例を示す図である。 第６の実施の形態の機能ブロック図である。 検証タイミングが設定された検証ルール・対処法情報の例を示す図である。 任意に設定する検証ルールの例を示す図である。 対処前後のモデルパターンを登録した検証ルール・対処法情報の例を示す図である。

以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。

図１は、実施の形態に適用される発明の概念図である。本発明は、利用者の業務モデルの構造を表す業務モデル図１の作成を支援するために、対処法情報２、モデル構造解析手段３、検証手段４、および検証結果表示手段５を有している。

対処法情報２には、業務モデル図１に、検証ルールに適合しない構成要素がある場合の、エラーメッセージと対処法とが、検証ルールに対応づけて予め登録されている。
モデル構造解析手段３は、図形と線とを構成要素とする業務モデル図１を解析する。そして、モデル構造解析手段３は、業務モデル図１を構成する各構成要素の種別を判別し、構成要素間の関係を示すモデル構造を生成する。たとえば、業務モデル図１を構成する図形と、モデル構造中の要素の種別との対応関係を予め定義しておく。そして、モデル構造解析手段３は、定義された対応関係に基づいて、業務モデル図１内の各構成要素の種別を判断する。

検証手段４は、構成要素の少なくとも一部を検証対象要素１ａとして選択する。たとえば、検証手段４は、ユーザから任意に指定された構成要素を、検証対象要素１ａとする。次に、検証手段４は、業務モデル図１の構成要素が満たすべき条件が予め設定された検証ルールの中から、選択した検証対象要素１ａの種別に対応する検証ルールを抽出する。たとえば、検証対象要素１ａの種別が「開始」であれば、開始に関する検証ルールが抽出される。そして、検証手段４は、選択した検証対象要素１ａが、抽出した検証ルールに適合しているか否かを検証する。

検証結果表示手段５は、検証手段４において不適合（検証エラー）と判定された場合、検証対象要素１ａの検証ルールへの不適合を解消するために操作すべき位置を表示する。たとえば、業務モデル図１上のエラー発生個所に欠陥位置を示す図形６を表示する。このとき、エラー発生個所は、検証対象要素の識別子によって特定することができる。また、検証結果表示手段５は、対処法情報２を参照し、不適合と判定された検証ルールに対応するエラーメッセージ７と対処法８とを表示する。

このような業務モデル図作成支援プログラムをコンピュータに実行させれば、まず、モデル構造解析手段３により、業務モデル図１を解析され、業務モデル図１を構成する各構成要素の種別を判別され、構成要素間の関係を示すモデル構造が生成される。

次に、検証手段４により、構成要素の少なくとも一部が検証対象要素１ａとして選択される。すると、検証手段４により、業務モデル図１の構成要素が満たすべき条件が予め設定された検証ルールの中から、選択した検証対象要素１ａの種別に対応する検証ルールが抽出される。そして、検証手段４により、選択した検証対象要素１ａが、抽出した検証ルールに適合しているか否かが検証される。

そして、検証手段４において不適合と判定された場合、検証結果表示手段５により、検証対象要素１ａの検証ルールへの不適合を解消するために操作すべき位置（エラー発生個所）を示す図形６、エラーメッセージ７、および対処法８が表示される。

たとえば、図１の例では、検証対象要素１ａは、モデル構造上で「開始」を意味する。すると、「開始から１つ以上の遷移があること」という検証ルールが適用される。業務モデル図１では、検証対象要素１ａの遷移を表す線が、検証対象要素１ａに接続されていない。そのため、適用された検証ルールに基づいて検証エラーが検出される。その結果、検証対象要素１ａの上にばつ印の図形６が表示されると共に、エラーメッセージ７や対処法８が表示される。

このように、検証エラーが発生したモデル要素や図要素のＩＤ（識別子）から、その表示位置をモデル構造編集部や図編集部から取得する技術を利用し、検証エラーの起きた図と図中の位置まで特定することが可能になった。その位置に図形６で印をつけることで、検証エラー発生位置が利用者に分かりやすく表示される。

しかも、これまで利用者が検証エラーに遭遇した時に、１）どのような修正を行ったのか、２）どのような場合にその検証エラーが発生するのかのノウハウを集め、エラーメッセージと共に対処法として利用者に提示している。これにより、利用者の修正の負担を軽減し、使いやすさが向上する。

さらに、エラーメッセージ７と共に対処法８を表示したことで、ユーザは、業務モデル図１の修正を容易に行うことができる。
なお、エラー発生個所は、業務モデル図１上に表示することもできるし、モデル構造を示すツリー構造上に表示することもできる。また、どちらの図に表示するのかを、検証ルール毎に予め指定しておくこともできる。モデル構造を示すツリー構造上にエラー発生個所を表示すれば、業務フロー図の遷移やデータ構造図の関連を示す情報のように、業務モデル図１上に現れない要素がエラー発生個所であっても、修正すべき要素を分かり易く表示できる。

また、検証処理を、予め設定されたタイミングで自動的に実行することもできる。たとえば、業務モデルを格納しているファイルの保存時やファイルを閉じる時などに、検証を実行することができる。たとえば、業務モデル図１の編集中であっても、重要な検証ルールについては逐次処理を行うことができる。これにより、非常に重要なエラーが発生したときは、編集中であっても即座に修正することができる。また、編集途中では抵触する場面がしばしば発生するような検証ルールについては、ファイルを閉じるときに検証処理を行うことで、エラーメッセージが過度に表示されるのを防止できる。その結果、業務モデル作成者の編集効率を向上させることができる。

また、業務モデル図１内のデータに直接適用する検証ルールを実行することもできる。これにより、業務モデル図１からしかわからないエラーも検出できる。
また、検証ルール毎にエラーの重要度を設定しておき、検証エラー発生には、エラーメッセージと共に、重要度を表示することもできる。例えば、発生した検証エラーの重要度の違いにより、ユーザは、重大で修正が必須なのが、確認を要する程度なのかを知ることができる。

また、業務モデル作成の進捗等を示す統計情報を表示することもできる。これにより、ユーザは、業務モデル図１の作成作業の進捗状況を把握しやすくなる。
また、ユーザからの操作入力により検証ルールを登録できるようにすることができる。あるいは、複数の検証ルールを予め登録しておき、ユーザによって選択された検証ルールのみを検証処理の際に利用することもできる。これにより、たとえば、プロジェクトごとに検証ルールを動的にかつ、容易に組み換えることができる。

さらに、業務モデル図１の修正案を画面に提示し、ユーザが確認した際には、修正案にもとづいて、業務モデル図１を修正することもできる。このように、業務モデルの修正案を示し、修正案を受け入れるとそれを実際に修正することで、ユーザの修正負担が軽減される。

以下に本実施の形態について具体的に説明する。
図２は、本実施の形態に用いるコンピュータのハードウェア構成例を示す図である。コンピュータ１００は、ＣＰＵ(Central Processing Unit)１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ(Random Access Memory)１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、および通信インタフェース１０６が接続されている。

ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。

グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。

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

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。以下、図２に示したコンピュータ上で実現される業務フロー図作成支援装置の実施の形態を詳細に説明する。

［第１の実施の形態］
図３は、第１の実施の形態の機能ブロック図である。業務フロー図作成支援装置は、モデル構造情報１１１、検証ルール適用部１１２、検証ルール・対処法情報１１３、モデル構造編集部１１４、検証制御部１１５、検証実行部１１６、検証結果リスト１１７、および検証結果表示制御部１１８を有している。

モデル構造情報１１１は、利用者が描いた業務モデル図２００の構造情報を保持する。モデル構造情報１１１は、業務モデル図２００の構造をツリー構造で表したものである。なお、業務モデル図２００は、業務フロー図とデータ構造図とを含んでいる。

検証ルール適用部１１２は、業務モデル図２００を構成する要素（業務プロセスや条件分岐を表すオブジェクト等）に関する複数の検証ルールを保持する。検証ルールでは、たとえば、「条件分岐には、分岐先毎に分岐条件（その分岐先に遷移するための条件）が設定されていなければならない」ことなどが定義されている。

検証ルール・対処法情報１１３は、検証時にエラーが発生した場合に利用者に表示するためのエラーメッセージとエラーを修正するために有効な情報（対処法）を、検証ルールに関連付けて保持する。

モデル構造編集部１１４は、利用者が描いた業務モデル図２００からモデル構造を編集する。モデル構造の構成要素（ノード等）には、その構成要素に対応する業務モデル図２００内の要素の識別番号が関連付けられる。

また、モデル構造編集部１１４は、ユーザからの操作入力により、モデル構造のうち検証対象となる部分（検証部分）の指定を受け付ける。そして、モデル構造編集部１１４は、ユーザから検証指示を受け取ると、検証部分の指定と検証要求とを、検証制御部１１５に渡す。なお、検証部分は、たとえば、業務モデル図２００内で各要素に設定された識別番号で指定される。さらに、モデル構造編集部１１４は、検証結果表示制御部１１８から検証エラー発生場所の情報を受け取ると、その場所に検証エラーを表す図形等を表示する。

検証制御部１１５は、検証要求を受け取ると、モデル構造編集部１１４で指定された検証部分を示す情報を検証実行部１１６に渡し、検証対象の検証処理を指示する。また、検証制御部１１５は、検証実行部１１６から検証処理終了の通知を受け取ると、検証結果表示制御部１１８に対して、検証結果の表示を指示する。

検証実行部１１６は、検証制御部１１５から渡された検証部分を示す情報に基づいて、モデル構造情報１１１から検証対象を取得する。そして、検証実行部１１６は、検証ルール適用部１１２に対して検証ルールの適用指示を出すことで、取得した検証対象が検証ルールに適合しているかどうかを検証する。さらに、検証実行部１１６は、検証結果を検証結果リスト１１７に登録する。検証実行部１１６は、検証対象に対する検証処理が終了した場合、その旨を検証制御部１１５に通知する。

検証結果リスト１１７は、検証実行部１１６から出力された検証結果が格納される。
検証結果表示制御部１１８は、検証制御部１１５から検証結果の表示指示を受け取ると、検証結果リスト１１７から検証結果を取得し、検証処理によってエラーとされた検証結果を抽出する。さらに、検証結果表示制御部１１８は、検証ルール・対処法情報１１３を参照し、検証エラーの発生場所、エラーメッセージ、および検証エラーに対する対処法を判定する。そして、検証結果表示制御部１１８は、エラーメッセージと検証エラーに対する対処法とを検証結果として表示すると共に、検証エラーの発生場所をモデル構造編集部１１４に通知する。検証エラーの発生場所は、たとえば、検証された要素の識別番号によって特定される。

次に、業務モデル図２００の内容について説明する。業務モデル図２００は、業務フロー図とデータ構造図とで構成される。
図４は、業務フロー図である。業務フロー図２１０には、開始２１１から終了２１２までの業務プロセス２１３ａ，２１３ｂ，２１３ｃ，２１３ｄ、分岐２１４ａ，２１４ｂ、および帳票２２２が設けられている。開始２１１、終了２１２、業務プロセス２１３ａ，２１３ｂ，２１３ｃ，２１３ｄ、および分岐２１４ａ，２１４ｂは、遷移線２１５ａ〜２１５ｈで接続されている。帳票２２２は、入出力線２１７ａ，２１７ｂによって、業務プロセス２１３ａ，２１３ｂに接続されている。

開始２１１は、業務フローの開始位置を示している。終了２１２は、業務フローの終了位置を示している。業務プロセス２１３ａ，２１３ｂ，２１３ｃ，２１３ｄは、業務フローにおいて実行する作業を示している。分岐２１４ａ，２１４ｂは、条件分岐による作業手順の分岐を示している。

遷移線２１５ａ〜２１５ｈは、業務プロセス間の遷移関係を示している。遷移線２１５ａ〜２１５ｈは矢印によって遷移元と遷移先とを示している。なお、分岐２１４を遷移元とする遷移線２１５ｄ，２１５ｅには、対応する遷移が発生する条件が設定されている。

入出力線２１７ａ，２１７ｂは、矢印によって、業務プロセスからのデータ出力、および業務プロセスへのデータ入力を示している。具体的には、入出力線２１７ａは、業務プロセス２１３ａで示される業務が行われることで、帳票２２２で示される帳票が出力されることを示している。また、入出力線２１７ｂは、帳票２２２で示される帳票が、業務プロセス２１３ｂで示される業務プロセスに入力されることを示している。

図５は、データ構造図である。データ構造図２２０では、書類２２１、帳票２２２、２２３、画面２２５が、それぞれ業務モデルに含まれるデータを表している。そして、書類２２１、帳票２２２、２２３間の関係が、線２２４によって示されている。

図４に示した業務フロー図２１０や図５に示したデータ構造図２２０を含む業務モデル図２００は、モデル構造編集部１１４で編集することができる。モデル構造編集部１１４は、モデル構造をツリー構造で画面表示する。

図４、図５に示したような内容の業務モデル図２００がモデル構造編集部１１４に入力されると、モデル構造編集部１１４によって、モデル構造が解析される。具体的には、モデル構造編集部１１４内に、予め業務フロー図２１０やデータ構造図２２０を構成する図形と、モデル構造を構成する要素との対応関係を定義した構造定義情報を有している。モデル構造編集部１１４は、その構造定義情報に基づいて、入力された業務モデル図２００の構造を解析する。

図６は、構造定義情報の例を示す図である。構造定義情報２０には、業務モデル内の図形とモデル構造の中の要素種別との対応関係が示されている。
先頭の対応関係２１は、業務モデル内の黒丸が、モデル構造の開始に対応することを示している。対応関係２２は、業務モデル内の２重丸（内部が黒丸）が、モデル構造の終了に対応することを示している。対応関係２３は、業務モデル内の黒で塗りつぶされた菱形が、モデル構造の判断に対応することを示している。

対応関係２４は、業務モデル内の実線の矢印が、モデル構造の遷移（コントロールフロー）に対応することを示している。対応関係２５は、業務モデル内の点線の矢印が、モデル構造のオブジェクトフローに対応することを示している。

対応関係２６は、業務モデル内の「業務プロセス」と記述された環状の図形が、モデル構造の業務プロセスに対応することを示している。対応関係２７は、業務モデル内の二重線の四角が、モデル構造のオブジェクトに対応することを示している。

対応関係２８は、業務モデル内の「端子」を表す２種類の図形は、モデル構造の要素種別に対応しないことを示している。対応関係２９は、業務モデル内の「画面」と記述された図形と、「帳票」と記述された図形とが、モデル構造のデータに対応することを示している。

対応関係２０ａは、モデル構造のモデルに対応する業務モデル内の図形が存在しないことを示している。対応関係２０ｂは、モデル構造のパッケージに対応する業務モデル内の図形が存在しないことを示している。

対応関係２０ｃは、業務モデルを構成する１つのページが、モデル構造の業務フロー図に対応することを示している。対応関係２０ｄは、モデル構造の業務フローに対応する業務モデル内の図形が存在しないことを示している。対応関係２０ｅは、業務モデルを構成する１つのページが、モデル構造の業務データ図に対応することを示している。

このように業務モデルを構成する図形には、モデル構造情報に反映されるものとされないものがある。業務フロー図に含まれる、開始、終了、業務プロセスなどは、業務フローの構造に関わるものであり、モデル構造情報にも反映される。それに対して、１つの業務フローを複数の図面ページに描く場合に、ページ間の繋がりを表す「端子」は、モデルの構造には無関係であるので、モデル構造情報には反映されない。

図７は、端子を用いた業務フロー図の例を示す図である。図７に示すように、１つの業務フロー図が複数のページ４１，４２にまたがって作成される場合がある。このとき、ページ４１の端子４１ａは、ページ４２の端子４２ａに遷移することを示している。

このような業務フロー図における端子４１ａ，４２ａは、ページ４１，４２の繋がりを示すのみであり、業務モデルの構造を示すものではない。そのため、端子４１ａ，４２ａに対応する業務モデル内の構成要素は必要とされない。

このような構造定義情報２０に基づいて、モデル構造編集部１１４が業務モデル図２００のモデル構造を解析する。解析されたモデル構造は、ツリー構造で画面に表示される。
なお、業務プロセスやデータのプロパティ（業務プロセスやデータが保持する情報）を表示させるために、図面ページ上に図形を描く場合がある。この場合、その図形に対応するのは、モデル構造情報の中のオブジェクトのプロパティであり、オブジェクトではない。そのためモデル構造情報１１１をツリー形式で表示した場合、データのプロパティに対応するノード（アイコン）は存在しない。

図８は、モデル構造表示画面の例を示す図である。モデル構造表示画面３００には、業務モデル図２００のデータ構造がツリー構造で表示されている。ユーザは、このモデル構造表示画面３００において、検証対象位置を指定することができる。たとえば、検証対象位置として指定する要素をマウスカーソル等で指定し、メニュー画面（コンテキストメニュー、プルダウンメニュー等）を表示させる。そして、メニュー画面内に設けられた検証実行コマンドを選択することで、検証対象位置に対する検証実行を指示することができる。

なお、検証対象位置として指定されたデータに下位構造が存在する場合、その下位構造も含めて検証対象となる。
業務モデル図２００から作成されたモデル構造情報は、一定のモデル構造定義に従って作成される。モデル構造定義では、どのような種別の要素に、どのような種別の要素が接続可能かを定義している。モデル構造定義は、たとえば、ＵＭＬのクラス図で表現することができる。

図９は、モデル構造定義の一部を示すＵＭＬのクラス図である。図９に示すように、クラス図を用いて、モデル構造定義３１を表現することができる。モデル構造定義３１では、種別３１ａ〜３１ｌと、種別３１ａ〜３１ｌ間の接続関係が示されている。このようなモデル構造定義３１に従って、モデル構造情報が作成される。

図１０は、モデル構造情報の例を示す図である。モデル構造情報３２は、モデル構成要素３２ａ〜３２ｕ間の接続関係がツリー構造で示されている。
図１１は、検証ルール・対処法情報の例を示す図である。検証ルール・対処法情報１１３には、検証ＩＤ、検証ルール、エラーメッセージ、および対処法の欄が設けられており、各欄の横方向に並べられた情報同士が互いに関連付けられている。

検証ＩＤの欄には、検証ルール、エラーメッセージ、および対処法の組に設定された識別番号が設定される。検証ルールの欄には、検証ルール適用部１１２に定義されている検証ルールの内容が設定される。エラーメッセージの欄には、対応する検証ルールを適用した結果、エラーとなったときのメッセージが設定される。対処法の欄には、対応する検証ルールを適用した結果、エラーとなったときの対処法が設定される。

たとえば、「開始があること」という検証ルールを、業務モデル全体に適用した結果、開始に対応する図形が見るから無い場合、エラーメッセージは「開始が一つもありません」であり、対処法は「開始を作ってください」である。

次に、第１の実施の形態に係る業務フロー図作成支援装置による処理を具体的に説明する。
図１２は、第１の実施の形態に係る業務モデル検証処理の手順を示すシーケンス図である。モデル構造編集部１１４は、モデル構造情報１１１から、検査すべきモデル構造の部分（検証対象位置）を指定して、検証対象取得処理を行う（ステップＳ１１）。なお、検査対象位置は、たとえば、画面に表示されたモデル構造に対する、ユーザの操作入力に応じて決定される。モデル構造情報１１１から検証対象のモデル構造が取り出され、モデル構造編集部１１４に渡される（ステップＳ１２）。

次に、モデル構造編集部１１４は、検証制御部１１５に対して、検証対象に対する検証の実行を指示する（ステップＳ１３）。検証実行の指示を受けた検証制御部１１５は、検証対象を検証実行部１１６に渡し、検証処理を実行させる（ステップＳ１４）。

検証実行部１１６は、内容が空の検証結果リスト１１７の作成処理を行う（ステップＳ１５）。すると、検証実行部１１６が利用するメモリ空間上に、検証結果リスト１１７が作成される（ステップＳ１６）。移行の検証結果リスト１１７に対するデータ追加等の処理は、検証実行部１１６が利用しているメモリ空間上で行われる。

次に、検証実行部１１６は、検証ルール適用部１１２を参照し、検証対象に対して適用すべき検証ルールを取得する（ステップＳ１７）。そして、検証実行部１１６は、検証ルール適用部１１２に対して、検証対象と検証結果リストとを渡し、検証対象に対する検証ルールの適用を指示する（ステップＳ１８）。

なお、検証実行部１１６は、複数の検証ルールを取得した場合、全ての検証ルールに関して、検証ルール適用部１１２への検証ルール適用指示を出す。また、検証実行部１１６は、取得した検証対象が、下位の構造を持っている場合、下位の構造も検証対象として、全ての検証ルールの適用指示を出力する。

検証ルール適用部１１２は、検証実行部１１６から検証ルールの適用指示を受け取る毎に、検証対象に対して検証ルールを適用し、検証結果１１６ａを作成する（ステップＳ１９）。検証ルール適用部１１２は、検証結果１１６ａを取得し（ステップＳ２０）、検証結果リスト１１７に対して、検証ルールの適用結果を追加する（ステップＳ２１）。追加される適用結果には、検証対象、検証ルール、検証結果が含まれる。

検証実行部１１６は、全ての検証対象に対する全ての検証ルールの適用が完了したら、適用結果追加後の検証結果リスト１１７を、検証制御部１１５に渡す（ステップＳ２２）。検証制御部１１５は、検証結果リストを検証結果表示制御部１１８に渡し、表示を指示する（ステップＳ２３）。

検証結果表示制御部１１８は、検証結果の一覧のダイアログを表示する。そして、検証結果表示制御部１１８は、検証ルール・対処法情報１１３を参照し、検証結果リストに格納されている検証結果毎に、検証ルールと対処法とを取得し、ダイアログに表示する（ステップＳ２４）。

さらに、検証結果表示制御部１１８は、モデル構造編集部１１４に対して、エラーが発生した検証対象のＩＤを指定して、エラー個所の表示指示を送信する（ステップＳ２５）。すると、モデル構造編集部１１４は、検証ルールの適用によりエラーと判定された検証対象を指し示す画面表示を行う。たとえば、モデル構造編集部１１４は、エラー個所に重ねて、ばつ印を表示する。

図１３は、検証結果リストの例を示す図である。検証結果リスト１１７には、検証結果が登録されている。検証結果は、対象要素ＩＤ、検証ルール、および結果の組で構成されている。

対象要素ＩＤは、業務モデル内の検証対象となった図形（検証対象）を一意に識別するための識別情報である。検証ルールは、検証対象に対して適用した検証ルールの識別情報である。結果は、検証対象が、適用した検証ルールを満たしているか否かを示す情報である。図中、検証ルールに適合した場合、結果に「○」が設定され、検証ルールに不適合（検証エラー）の場合、結果に「×」が設定される。

このようにして、モデル構造の検証が行われ、検証結果リストにエラーがあれば、そのエラーに対する対処法と共に、エラーの発生個所がモニタの画面に表示される。
図１４は、モデル構造表示画面への検証エラー個所の表示手順を示すシーケンス図である。

まず、検証結果表示制御部１１８からモデル構造編集部１１４に対して、検証エラーが検出された要素のＩＤを指定した表示要求が出力される（ステップＳ４１）。モデル構造編集部１１４は、親のモデル構造情報１１１ａに対し、そのモデルのＩＤを取得するためにアクセスする（ステップＳ４２）。これにより、モデル構造編集部１１４は、モデル構造情報１１１ａからモデルのＩＤを取得する（ステップＳ４３）。そして、モデル構造編集部１１４は、表示要求で渡されたＩＤとモデルのＩＤとを比較する。この例では、ＩＤが一致していないものとする。

次に、モデル構造編集部１１４は、親のモデル構造情報１１１ａを参照し、子（下位構造）のモデル情報を取得するためのアクセスを行う（ステップＳ４４）。これにより、モデル構造編集部１１４は、モデル構造情報１１１ａから子モデル情報リストを取得する（ステップＳ４５）。

さらに、モデル構造編集部１１４は、子のモデル構造情報１１１ｂを参照し、そのモデルのＩＤを取得する（ステップＳ４６）。これにより、モデル構造編集部１１４は、モデル構造情報１１１ａからモデルのＩＤを取得する（ステップＳ４７）。そして、モデル構造編集部１１４は、表示要求で渡されたＩＤとモデルのＩＤとを比較する。この例では。ＩＤが一致したものとする。

ＩＤが一致すると、モデル構造編集部１１４は、子のモデル構造情報１１１ｂに対して、強調表示のための表示色を設定する。その後、モデル構造編集部１１４は、モデル構造表示画面３００に表示される親のモデル構造情報１１１ａに関するモデル構造表示情報３１０の再描画を行う（ステップＳ４９）。この例では、親の下位構造のモデル構造に強調表示色が設定されているため、検証エラーの発生したノードの色が強調表示色に変わる。

図１５は、第１の実施の形態の検証結果を示す画面の例を示す図である。検証処理が終了すると、モデル構造表示画面３００の脇に検証結果画面４１０が表示される。
検証結果画面４１０には、検証結果表示部４１１、対処法表示部４１２、表示ボタン４１３、および終了ボタン４１４が設けられている。検証結果表示部４１１には、エラーとなった検証処理の、エラーメッセージが表示される。対処法表示部４１２には、検証結果表示部４１１内で選択された検証処理の対処法が表示される。表示ボタン４１３は、検証結果から選択されたエラーメッセージの対処法を表示させるためのボタンである。終了ボタン４１４は、検証結果画面４１０を閉じるためのボタンである。

検証結果としてエラーが検出されると、モデル構造表示画面３００内のモデル構造において、エラーの発生したノードの強調表示が行われる。図１５の例では、エラーが検出されたノード３１１にチェックマークが表示されている。

このように、モデル構造の検証エラーに対する対処法と、エラー発生個所とが画面表示されることで、ユーザは、業務モデル図２００の間違いを容易に修正できる。
［第２の実施の形態］
次に、本発明の第２の実施の形態について説明する。第２の実施の形態は、第１の実施の形態に対し、業務モデル図２００の編集機能を追加したものである。

図１６は、第２の実施の形態の機能ブロック図である。第２の実施の形態の多くの機能が第１の実施の形態と同様であるため、図３に示した第１の実施の形態の構成要素と同じ機能の構成要素には同じ番号を付し、説明を省略する。

第１の実施の形態との相違点は、図編集部１２１が追加されたこと、および検証ルール・対処法情報１１３ａと検証結果表示制御部１１８ａとの機能が変更されたことである。
図編集部１２１は、ユーザからの操作入力に応じて、業務フロー図やデータ構造図を作成する。作成された図が、業務モデルとしてモデル構造編集部１１４に入力される。

図編集部１２１には、汎用的な描画ソフトウェアを利用することができる。ただし、検証エラーの発生箇所を表示するため、図編集部１２１の表示用のＡＰＩ（Application Program Interface）が公開されている必要がある。

検証ルール・対処法情報１１３ａは、検証ルールに対するエラーメッセージや対処法に加え、表示場所の情報を有している。表示場所は、エラー個所を表示する図を指定する情報である。モデル構造編集部１１４が表示個所であれば、モデル構造を示す図上で、エラー個所が表示される。また、図編集部１２１が表示個所であれば、業務モデルを示す図上で、エラー個所が表示される。

検証結果表示制御部１１８ａは、第１の実施の形態に係る検証結果表示制御部１１８が有する機能に加え、検証ルール・対処法情報１１３ａに設定された表示個所の情報に応じて、エラー個所の表示指示を行う相手を判断する機能を有する。すなわち、表示個所がモデル構造編集部１１４であれば、エラー個所の表示指示をモデル構造編集部１１４に対して出力する。また、表示個所が図編集部１２１であれば、エラー個所の表示指示を図編集部１２１に対して出力する。

図１７は、第２の実施の形態に係る検証ルール・対処法情報の例を示す図である。第２の実施の形態の検証ルール・対処法情報１１３ａには、検証ＩＤ、検証ルール、エラーメッセージ、対処法、および表示場所の欄が設けられている。表示場所の欄には、対応付けられた検証ルールに基づく検証処理よりエラーが発生したときのエラー表示場所（表示機能）が設定される。

図１８は、業務フロー表示部への検証エラー個所の表示手順を示すシーケンス図である。
まず、検証結果表示制御部１１８ａから図編集部１２１に対して、検証エラーが検出された要素のＩＤを指定した表示要求が出力される（ステップＳ５１）。図編集部１２１は、図情報１２１ａに対し、その図のＩＤを取得するためにアクセスする（ステップＳ５２）。これにより、図編集部１２１は、図情報１２１ａから図のＩＤを取得する（ステップＳ５３）。そして、図編集部１２１は、表示要求で渡されたＩＤとモデルのＩＤとを比較する。図編集部１２１は、ＩＤが一致していなければ、一致するまでステップＳ５２，５３の処理を繰り返す。

ＩＤが一致すると、図編集部１２１は、図情報１２１ａに対して、一致したＩＤに対応する図形の表示位置取得のためにアクセスする（ステップＳ５５）。これにより、図編集部１２１は、図情報１２１ａから、エラーが発生した図形の位置（ｘ座標とｙ座標）を取得する（ステップＳ５５）。

次に、図編集部１２１は、図情報１２１ａの編集操作を行い、ステップＳ５５で取得した位置に、エラー個所表示用図形（たとえば、ばつ印）を配置する（ステップＳ５６）。
このように、エラーの表示個所を指定することで、視覚的に分かり易いエラー表示が可能とある。たとえば、図編集部１２１で編集中の業務フロー図にエラー発生個所を表示すれば、ユーザは、エラーを解消するために編集すべきデータを即座に認識することができる。

図１９は、第２の実施の形態の検証結果を示す画面の例を示す図である。図１９の例は、「開始から１つ以上の遷移があること」という検証ルールでエラーが検出された場合の表示画面を示している。図１７に示した検証ルール・対処法情報１１３ａを参照すると、この検証ルールのエラーの表示場所は、図編集部１２１である。そこで、図編集部１２１によって表示される業務フロー図２１０の開始の位置に、エラーの発生を示す図形２１６が表示されている。

このように、図編集部１２１の機能と連携して検証処理を行うことで、作成中の業務フロー図２１０上にエラー発生個所の表示を行うことができる。しかも、図編集部１２１としては、汎用の描画ソフトウェアを使用することが可能であり、ユーザが使い慣れているソフトウェアを用いて業務モデル図を作成できる。

［第３の実施の形態］
次に、第３の実施の形態について説明する。第３の実施の形態は、複数の検証ルールを選択的に適用できるようにしたものである。

図２０は、第３の実施の形態の機能ブロック図である。第３の実施の形態の多くの機能が第２の実施の形態と同様であるため、図１６に示した第２の実施の形態の構成要素と同じ機能の構成要素には同じ番号を付し、説明を省略する。

第２の実施の形態との相違点は、検証ルール保持部１２２が追加されたこと、および検証ルール適用部１１２ａの機能が変更されたことである。
検証ルール保持部１２２には、複数の検証ルール１２２ａが格納されている。また、検証ルール適用部１１２ａは、ユーザの操作入力等により、適用可能な検証ルールが予め指定されている。そして、検証ルール適用部１１２ａは、検証対象に対して、適用可能な検証ルールのみを適用し、検証処理を行う。

なお、検証ルール１２２ａは、たとえば、オブジェクト指向プログラミング言語で実装できる。この場合、検証ルール１２２ａ適用のためのインタフェースをスーパークラスで定義し、そのサブクラスとして検証ルールを作成する。このように実装すれば、検証ルール適用部１１２ａからは、どの検証ルールもイテレータを利用して同じインタフェースで呼び出すことができる。そのため、検証ルール適用部１１２ａの実装、検証ルール１２２ａの追加，削除が容易となる。

なお、プログラミングにおいてイテレータ(Iterator)とは、リストや、それに類似するデータ構造の、各々の要素に対して繰り返し処理の抽象化である。実際のプログラミング言語では、オブジェクトまたは文法などとして現れる。反復するためのものの意味で反復子と訳される。

図２１は、第３の実施の形態に係る業務モデル検証処理の手順を示すシーケンス図である。なお、この処理は、図１２に示した第１の実施の形態の処理とほぼ同じであるため、同じ処理には同一のステップ番号を付し、説明を省略する。以下、第１の実施の形態と異なる処理について説明する。

ステップＳ１１からステップＳ１７の処理は第１の実施の形態と同じである。その後、検証実行部１１６は、検証ルール保持部１２２に対して、検証対象と検証結果リストとを渡し、検証対象に対する検証ルールの適用を指示する（ステップＳ１８ａ）。

なお、検証実行部１１６は、複数の検証ルールを取得した場合、取得した全ての検証ルールの適用指示を、検証ルール適用部１１２へ出力する。また、検証実行部１１６は、取得した検証対象が、下位の構造を持っている場合、下位の構造も検証対象として、全ての検証ルールの適用指示を出力する。

検証ルール保持部１２２は、検証実行部１１６から検証ルールの適用指示を受け取る毎に、検証対象に対して検証ルールを適用する（ステップＳ１８ｂ）。すなわち、検証ルールの適用指示に応答して、プログラムによって記述された検証ルールが起動され、検証ルールを実行するプロセスに検証対象が渡される。すると、検証ルールを実行するプロセスにより、検証対象の判定が行われる。

この際、複数の検証ルールの適用が指定されていれば、検証対象に対して、適用すべき検証ルールを順次適用される。そして、検証ルール保持部１２２に保持された検証ルール（プログラムによる処理記述）が適用されることで、その検証ルールにより、検証結果１１６ａが作成される（ステップＳ１９ａ）。

その後のステップＳ２０からステップＳ２４の処理は、第１の実施の形態と同様である。ステップＳ２４の処理後、検証結果表示制御部１１８ａは、表示対象がモデル構造編集部１１４か図編集部１２１かを判断する。表示対象がモデル構造編集部１１４であれば、検証結果表示制御部１１８ａは、モデル構造編集部１１４に対して、エラーが発生した検証対象のＩＤを指定して、エラー個所の表示指示を送信する（ステップＳ２５ａ）。この場合、モデル構造編集部１１４により、モデル構造表示画面３００にエラー発生場所が表示される。

また、表示対象が図編集部１２１であれば、検証結果表示制御部１１８ａは、図編集部１２１に対して、エラーが発生した検証対象のＩＤを指定して、エラー個所の表示指示を送信する（ステップＳ２５ｂ）。この場合、図編集部１２１により、業務フロー図２１０にエラー発生場所が表示される。

これにより、検証ルールの組み替えが容易となる。たとえば、社内利用の業務モデルについては、必要最低限の検証ルールのみを適用し、顧客に提出する業務モデルについては、最も厳しい検証ルールを適用するといった検証ルールの変更が容易となる。

［第４の実施の形態］
次に、第４の実施の形態について説明する。第４の実施の形態は、図編集部で表示するための図形状法を図情報として別で保持し、図情報から直接モデル構造の検証を行えるようにしたものである。

図２２は、第４の実施の形態の機能ブロック図である。第４の実施の形態の多くの機能が第３の実施の形態と同様であるため、図２０に示した第３の実施の形態の構成要素と同じ機能の構成要素には同じ番号を付し、説明を省略する。

第３の実施の形態との相違点は、図情報１２３が追加されたこと、および検証ルール適用部１１２ａの機能が変更されたことである。
図情報１２３には、業務モデルを表した図に含まれる図形データが格納される。モデル構造編集部１１４ａは、図情報１２３に含まれた図形データを解析し、モデル構造情報１１１を作成する。

図２３は、図情報の例を示す図である。図情報１２３には、複数の図形データ１２３ａ〜１２３ｇが含まれている。図形データ１２３ａ〜１２３ｇがツリー構造に関連付けられて、図情報１２３が構成されている。なお、図２３の例では、個々の図形がシェイプと名付けられている。たとえば、遷移の図形データ１２３ｇには、ソースの接続シェイプＩＤ、ターゲットの接続シェイプＩＤの情報が含まれている。

モデル構造編集部１１４ａは、図２３に示したような図情報１２３に基づいてモデル構造情報１１１を生成する。
検証ルール１２２ａでは、図情報１２３に含まれるデータを利用したルールを定義しておくことができる。たとえば、遷移の図形データ１２３ｇに、ソース側接続先シェイプＩＤやターゲット側接続先シェイプＩＤが設定されていない場合に、検証エラーとなるような検証ルール１２２ａを定義しておくことができる。

図２４は、第４の実施の形態に係る業務モデル検証処理の手順を示すシーケンス図である。なお、第４の実施の形態の処理は、図２１に示した第３の実施の形態の処理とほぼ同じであるため、異なる部分のみを図示している。

モデル構造編集部１１４ａは、モデル構造情報１１１から、検査すべきモデル構造の部分（検証対象位置）を指定して、検証対象取得処理を行う（ステップＳ３１）。すると、モデル構造情報１１１から検証対象の検証対象のモデル構造（検証＿モデル情報）が取り出され、モデル構造編集部１１４ａに渡される（ステップＳ３２）。

次に、モデル構造編集部１１４ａは、図情報１２３から、検査すべき図情報の部分（検証対象位置）を指定して、検証対象取得処理を行う（ステップＳ３３）。すると、図情報１２３から検証対象の検証対象の図情報（検証＿図情報）が取り出され、モデル構造編集部１１４ａに渡される（ステップＳ３４）。

そして、モデル構造編集部１１４ａは、検証制御部１１５に対して、検証対象に対する検証処理の実行を指示する（ステップＳ３５）。このとき、検証制御部１１５に対して渡される検証対象は、検証＿モデル情報と検証＿図情報とを含んでいる。以後の処理は、図２１に示したステップＳ１５以降の処理と同じである。

このように、図情報内のデータに基づいて検証を行うことができることにより、きめ細かな検証を実施することができる。たとえば、モデル構造情報１１１に反映されてないデータに基づいて、検証することができる。

［第５の実施の形態］
次に、第５の実施の形態について説明する。第５の実施の形態は、実施時間等の条件が異なる複数回の検証処理それぞれの検証結果リストを保持し、業務モデル作成の進捗度合いを測定できるようにしたものである。また、第５の実施の形態では、検証ルールに対して、重要度を設定し、検証エラーが発生した際に、エラーメッセージと共に重量度を表示するようにしている。

図２５は、第５の実施の形態の機能ブロック図である。第５の実施の形態の多くの機能が第４の実施の形態と同様であるため、図２２に示した第４の実施の形態の構成要素と同じ機能の構成要素には同じ番号を付し、説明を省略する。

第４の実施の形態との相違点は、複数の検証結果リスト１１７ａ，１１７ｂ，１１７ｃを保持できるようにしたこと、検証実行部１１６ａと検証結果表示制御部１１８ａとの機能が変更されたこと、および検証ルール・対処法情報１１３ｂの内容を変更したことである。

検証実行部１１６ａは、検証処理を実行し、検証結果リストを作成する際に、タイムスタンプ（現在の時刻を示す情報）を付与する。業務モデルを作成する過程で、業務モデルの検証処理を複数回行うと、タイムスタンプの異なる複数の検証結果リスト１１７ａ，１１７ｂ，１１７ｃが生成される。

検証結果表示制御部１１８ａは、複数の検証結果リスト１１７ａ，１１７ｂ，１１７ｃを利用して、業務モデル作成作業の進捗状況を示す統計データを作成し、画面に表示する。

図２６は、検証ルール・対処法情報のデータ構造例を示す図である。この検証ルール・対処法情報１１３ｂには、検証ＩＤ、エラー／警告、検証ルール、エラーメッセージ、対処法、および表示場所の欄が設けられている。これは、図１７に示した検証ルール・対処法情報１１３ａと比較すると、エラー／警告の欄が追加されている。

エラー／警告の欄には、検証対象の要素が検証ルールを満たしていないときのエラーの重要度を示している。図２６の例では、重要度として「エラー」と「警告」とがあり、エラーの方が重要度が高い。重要度の分け方としては、たとえば、必ず満たしていなければならない検証ルールに対して「エラー」を設定し、満たしていることが望ましい検証ルールに対して「警告」を設定する。

重要度は、対応する検証ルールで検証エラーが発生した際に、エラーメッセージと共に、画面に表示される。また、重要度は、進捗状況を示す統計情報の基礎データとしても領される。

図２７は、タイムスタンプが付与された検証結果リストの例を示す図である。検証結果リスト１１７ａには、タイムスタンプ１１７ａａと検証結果１１７ａｂとが登録されている。

タイムスタンプ１１７ａａは、検証結果リスト１１７ａの作成日時を示している。検証結果１１７ａｂには、対象、対象要素ＩＤ、検証ルール、および結果の組が登録されている。対象は、検証対象が、モデル構造情報１１１なのか図情報１２３（検証結果リスト１１７ａ内では、単に「図」と表されている）なのかを示している。対象要素ＩＤ、検証ルール、および結果については、図１３に示した第１の実施の形態の例と同様である。

なお、検証エラーが発生した場合（結果「×」）、重要度の情報（エラー／警告）が、結果の情報に含められる。
このようなタイムスタンプ付きの複数の検証結果リスト１１７ａ，１１７ｂ，１１７ｃに基づいて、たとえば、エラー件数や警告件数を統計情報として集計することができる。集計結果は、進捗状況として画面表示される。

図２８は、進捗状況表示画面の第１の例を示す図である。進捗状況表示画面５１には、検証日時、エラー件数、警告件数の欄が設けられ、検証結果が時系列で示されている。
このように、エラー件数や警告件数の発生数の推移を参照することで、業務モデル作成作業の進捗状況を推定することができる。たとえば、エラー件数や警告件数が減少傾向にある場合、業務モデル作成作業が最終段階（間違いの修正段階）に入り、作業が順調に進んでいると判断できる。

図２９は、進捗状況表示画面の第２の例を示す図である。この進捗状況表示画面５２には、検証日時、新規追加エラー／警告件数、前検証からの残り件数、および修正件数／発生場所の削除件数の欄が設けられ、検証結果が時系列で示されている。

新規追加エラー／警告件数は、前回の検証処理では検出されていない新たなエラーおよび警告の件数である。前検証からの残り件数は、前回の検証処理で検出されたエラーおよび警告のうち、未処理の件数である。修正件数／発生場所の削除件数は、前回の検証処理から今回の検証処理の間に修正または削除された、エラーおよび警告の件数である。

なお、前回の検証処理で検出されたエラーや警告が、今回の検証処理で検出されたか否かは、検証結果リストの、対象、対象要素ＩＤ、および検証ルールが一致するか否かを比較することで判断できる。

図３０は、進捗状況表示画面の第３の例を示す図である。この進捗状況表示画面５３には、検証結果表示部５３ａ、対処法表示部５３ｂ、表示ボタン５３ｃ、終了ボタン５３ｄが設けられている。

検証結果表示部５３ａには、これまでに検出された検証エラー（エラーと警告）をリストで表示している。ここで、最後に実施された検証処理で新たに検出された検証エラーには、新たなエラーを示すマーク（図３０の例では「Ｎｅｗ！」）が付与されている。

ユーザは、検証結果表示部５３ａ内から、詳細な内容を参照すべき検証エラーを選択できる。なお、既に修正されているエラーや警告は、たとえば、灰色で表示され、選択できない状態となっている。

対処法表示部５３ｂには、検証結果表示部５３ａで選択された検証エラーの対処法が表示される。表示ボタン５３ｃは、検証結果表示部５３ａで選択された検証エラーの発生個所等を表示させるためのボタンである。終了ボタン５３ｄは、進捗状況表示画面５３を閉じるためのボタンである。

このように、検証結果を表示する際に、前回の検証以降に生じた検証エラー（マーク「Ｎｅｗ！」を付与）、前回から今回までの間に修正された検証エラー（灰色の文字で表示）、前回の検証時に検出したが未修正の検証エラー（黒色の文字、およびマーク「Ｎｅｗ！」無しで表示）を分類して表示することができる。

［第６の実施の形態］
次に、第６の実施の形態について説明する。第６の実施の形態は、複数の検証ルールの中で、適用する検証ルールと適用しない検証ルールとを指定する情報を利用検証ルール設定ファイルに登録しておき、検証処理の際に利用検証ルール設定ファイルを選択することで、適用する検証ルールを指定するものである。

図３１は、第６の実施の形態の機能ブロック図である。第６の実施の形態の多くの機能が第５の実施の形態と同様であるため、図２５に示した第５の実施の形態の構成要素と同じ機能の構成要素には同じ番号を付し、説明を省略する。

第５の実施の形態との相違点は、利用検証ルール設定ファイル１２４が新たに設けられたこと、および検証実行部１１６ａの機能が変更されたことである。
利用検証ルール設定ファイル１２４には、業務モデル作成者が選択した検証ルールの番号が、カンマなどで区切って記述されている。検証実行部１１６ａは、検証ルール保持部１２２で保持している検証ルール１２２ａの中から、利用検証ルール設定ファイル１２４に記載された番号の検証ルールだけを利用して検証処理を実行する。

また、利用検証ルール設定ファイル１２４を複数用意しておくこともできる。この場合、検証実行部１１６ａにおいて、利用検証ルール設定ファイル１２４の名称を設定する機能を持たせる。そして、検証実行部１１６ａが、予め設定された名称に対応する利用検証ルール設定ファイル１２４に基づいて、検証処理の指示を検証ルール適用部１１２ａに対して出力する。これにより、業務モデル作成者は、複数の設定ファイルの中から、目的に応じた設定ファイルを設定して、検証を実行させることができる。

［その他の応用例］
次に、上記各実施の形態に適用可能な応用例について説明する。以下、各応用例を第６の実施の形態のシステムに適用した場合を想定し、図３１に示した構成を参照して説明する。

まず、第１の応用例について説明する。第１の応用例は、検証処理のタイミングを予め定義しておき、そのタイミングで検証処理を自動的に行うものである。その場合、たとえば、検証ルール・対処法情報１１３ｂ内に検証タイミングを設定しておき、検証制御部１１５は検証ルール・対処法情報１１３ｂを参照して、各検証ルールの検証タイミングを管理する。

図３２は、検証タイミングが設定された検証ルール・対処法情報の例を示す図である。この検証ルール・対処法情報１１３ｃには、検証ＩＤ、エラー／警告、検証ルール、エラーメッセージ、対処法、表示場所、および検証タイミングの欄が設けられている。これは、図２６に示した検証ルール・対処法情報１１３ｂと比較すると、検証タイミングの欄が追加されている。

検証タイミングは、対応する検証ルールの適用タイミングを示している。検証タイミングが「検証時」であれば、ユーザからの意図的な操作入力が行われた際に、対応する検証ルールの検証処理が実行される。

また、検証タイミングが「編集時」であれば、ユーザか業務モデルを編集している最中に、図編集部１２１において図形が入力される毎に、対応する検証ルールの検証処理が実行される。具体的には、図編集部１２１で図形が入力され、その図形の位置等の設定が確定すると、その情報がモデル構造編集部１１４ａに渡される。たとえば、他の図形の操作に移行したときに、以前に操作していた図形の設定が確定したものとする。

なお、検証タイミングとしては、たとえば、一定時間ごとに検証を行うように設定したり、ファイルの保存や閉じる時に検証を実行するように設定することもできる。
具体的には、モデル構造編集部１１４ａは、新たに図形が入力される毎にモデル構造情報１１１を更新し、更新したことを検証制御部１１５に通知する。すると、検証制御部１１５は、検証実行部１１６ａに対して、新たに入力された要素の検証指示を出力する。

検証実行部１１６ａは、検証ルール・対処法情報１１３ｃを参照し、入力された要素に対して適用可能であり、かつ検証タイミングが「編集時」である検証ルールを特定する。そして、検証実行部１１６ａは、その検証ルールの適用指示を、検証ルール適用部１１２ａに対して出力する。

このようにして、検証処理の自動実行が可能となる。これにより、ユーザは、誤った図形配置等を行ったとき、エラーの存在をすぐに知ることができる。
次に、第２の応用例について説明する。第２の応用例は、ユーザが任意の検証ルールを定義できるようにしたものである。たとえば、業務フロー図作成支援装置に、任意の場所に格納された検証ルールを読み込むための検証ルール読込部を新たに追加する。ユーザは、検証処理を実行する際に、適用する検証ルールが格納されたファイル名を、検証ルール読込部に入力する。すると、検証ルール読込部は、指定されたファイル内の検証ルールを、検証ルール保持部１２２に登録する。たとえば、ＯＣＬ(Object Constraint Language)を用いて、ユーザが検証ルールを設定できるようにする。

図３３は、任意に設定する検証ルールの例を示す図である。この検証ルール１２２ｂは、「context BusinessProcess inv」で示される要素から出ている線の数が、０より多く、５未満でなければならないという検証ルールを示している。

このような検証ルール１２２ｂは、たとえば、一般的に多数の線を接続可能な要素であっても、あまりに数が多すぎると業務フロー等の構造が複雑になりすぎるため、接続可能な線の数を制限する際に利用される。

次に、第３の応用例について説明する。第３の応用例は、エラーが発生したときの対処を自動的に行うものである。その場合、たとえば、検証ルール・対処法情報１１３ｂに、対処前のモデルパターンと対処後のモデルパターンとを登録しておく。

図３４は、対処前後のモデルパターンを登録した検証ルール・対処法情報の例を示す図である。この検証ルール・対処法情報１１３ｄでは、検証ルールに対応づけて、対処前業務モデルパターンと対処後業務モデルパターンとの欄が設けられている。

対処前業務モデルパターンには、エラーの発生原因となる業務モデルのパターンが設定されている。対処後業務モデルパターンには、エラーを解消させることができる業務モデルのパターンが設定されている。

このような定義を行うと、検証エラー発生箇所の構造などが、作業前のモデルのパターンと合致する場合に、作業後のモデルに変換して表示することができる。たとえば、図３４の例の検証ＩＤ「２」の検証ルールでは、判断の分岐先に対してガード条件が記載されていない場合、ガード条件付きの業務フローに変換するような対処後業務モデルパターンが設定されている。

なお、図３４の例では、ガード条件として、遷移先の業務プロセスの名前が自動的に設定される。ユーザは、別のガード条件が適切と判断した場合、図編集部１２１に対する操作入力を行い、任意のガード条件を設定できる。

検証結果表示制御部１１８ａは、検証エラーが発生した際に、検証ルール・対処法情報１１３ｄを参照し、対処前業務モデルパターンと対処後業務モデルパターンとが設定されていれば、設定内容に沿ったモデルの変更指示を図編集部１２１に対して出力する。図編集部１２１は、指示に従って業務フロー図等の図を編集する。

なお、対処前業務モデルパターンから対処後業務モデルパターンへの図の自動編集を行った場合、ユーザからの確認を示す操作入力を待って、編集後の図を確定することができる。これにより、ユーザが気づかない間に、図が変更されることを防止できる。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、業務モデル図作成支援装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。

上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。

符号の説明

１ 業務モデル図
１ａ 検証対象要素
２ 対処法情報
３ モデル構造解析手段
４ 検証手段
５ 検証結果表示手段
６ 図形
７ エラーメッセージ
８ 対処法

Claims (10)

1. 利用者の業務モデルの構造を表す業務モデル図の作成を支援する業務モデル図作成支援プログラムにおいて、
   コンピュータを、
   業務モデル図に含まれる図形を構成要素として、図形の種類に応じて異なる構成要素の種別が定義された対応定義情報に従い前記構成要素の種別を判別し、複数の構成要素の種別間の接続関係の定義情報に従い前記構成要素の種別および前記構成要素間の接続関係の情報を含むモデル構造情報を生成するモデル構造生成手段、
   前記モデル構造情報に含まれる構成要素の少なくとも一部を検証対象要素として選択し、当該検証対象要素が、前記モデル構造情報の構成要素の種別について満たすべき条件が予め設定された検証ルールのうち、前記検証対象要素の種別に対応する検証ルールに適合しているか否かを検証する検証手段、
   前記検証手段による検証結果を示す情報を、前記コンピュータに接続されたモニタに表示する検証結果表示手段、
   として機能させることを特徴とする業務モデル図作成支援プログラム。
2. 前記検証結果表示手段は、前記検証手段において不適合と判定された場合、前記検証ルールに不適合な構成要素を前記検証ルールに適合させるための対処法が登録された対処法情報を参照し、不適合と判断した際の前記検証ルールに前記検証対象要素を適合させるための対処法を表示することを特徴とする請求項１記載の業務モデル図作成支援プログラム。
3. 前記検証結果表示手段は、前記コンピュータに接続されたモニタに、前記モデル構造情報を示す図と、前記モデル構造情報を示す図上の前記検証対象要素の位置に当該検証対象要素についての前記検証手段による検証結果を示す情報と、を表示することを特徴とする請求項１記載の業務モデル図作成支援プログラム。
4. 前記検証結果表示手段は、前記コンピュータに接続されたモニタに、前記業務モデル図と、前記業務モデル図上の前記検証対象要素の位置に当該検証対象要素についての前記検証手段による検証結果を示す情報と、を表示することを特徴とする請求項１記載の業務モデル図作成支援プログラム。
5. 前記検証手段は、前記検証ルール毎に予め設定された検証タイミングになったとき、前記検証対象要素が前記検証ルールに適合しているか否かを検証することを特徴とする請求項１記載の業務モデル図作成支援プログラム。
6. 前記検証結果表示手段は、前記検証手段において前記検証対象要素が前記検証対象要素の種別に対応する検証ルールに不適合と判定された場合、検証ルール毎に予め設定された重要度のレベルに基づき、前記検証ルールに設定された重要度のレベルを、エラーメッセージと共に表示することを特徴とする請求項１記載の業務モデル図作成支援プログラム。
7. 前記検証手段は、前記検証結果にタイムスタンプを付与して、記憶手段に蓄積し、
   前記検証結果表示手段は、前記記憶手段に蓄積された検証結果に基づいて、前記検証ルールに不適合と判定された構成要素の数を所定時期毎に集計し、当該集計結果を示す情報を表示することを特徴とする請求項１記載の業務モデル図作成支援プログラム。
8. 前記検証結果表示手段は、前記検証ルールに不適合の前記検証対象要素を前記検証ルールに適合させるための変更パターンが予め設定されており、前記検証手段において不適合と判定された場合、前記変更パターンに基づいて前記検証対象要素を変更した前記業務モデル図を表示することを特徴とする請求項１記載の業務モデル図作成支援プログラム。
9. コンピュータにより、利用者の業務モデルの構造を表す業務モデル図の作成を支援するための業務モデル図作成支援方法において、
   前記コンピュータが、業務モデル図に含まれる図形を構成要素として、図形の種類に応じて異なる構成要素の種別が定義された対応定義情報に従い前記構成要素の種別を判別し、複数の構成要素の種別間の接続関係の定義情報に従い前記構成要素の種別および前記構成要素間の接続関係の情報を含むモデル構造情報を生成し、
   前記コンピュータが、前記モデル構造情報に含まれる構成要素の少なくとも一部を検証対象要素として選択し、当該検証対象要素が、前記モデル構造情報の構成要素の種別について満たすべき条件が予め設定された検証ルールのうち、前記検証対象要素の種別に対応する検証ルールに適合しているか否かを検証し、
   前記コンピュータが、前記検証ルールに適合しているか否かの検証結果を示す情報を、前記コンピュータに接続されたモニタに表示する、
   ことを特徴とする業務モデル図作成支援方法。
10. 利用者の業務モデルの構造を表す業務モデル図の作成を支援する業務モデル図作成支援装置において、
    業務モデル図に含まれる図形を構成要素として、図形の種類に応じて異なる構成要素の種別が定義された対応定義情報に従い前記構成要素の種別を判別し、複数の構成要素の種別間の接続関係の定義情報に従い前記構成要素の種別および前記構成要素間の接続関係の情報を含むモデル構造情報を生成するモデル構造生成手段と、
    前記モデル構造情報に含まれる構成要素の少なくとも一部を検証対象要素として選択し、当該検証対象要素が、前記モデル構造情報の構成要素の種別について満たすべき条件が予め設定された検証ルールのうち、前記検証対象要素の種別に対応する検証ルールに適合しているか否かを検証する検証手段と、
    前記検証手段による検証結果を示す情報を、前記業務モデル図作成支援装置に接続されたモニタに表示する検証結果表示手段と、
    を有することを特徴とする業務モデル図作成支援装置。

Images