本発明は、ドキュメントの書式変換技術に関し、特に、標準化ドキュメントからビジネスプロセス図を生成する、ビジネスプロセス図生成装置、ビジネスプロセス図生成プログラム、および、ビジネスプロセス図生成方法に関する。

現在、システム開発の様々な工程で自動化の試みが進められている。例えば、システム開発者が、MDA(Model Driven Architecture:モデル駆動型アーキテクチャ)を利用した自動化ツールを用いて、システム設計から製造までをモデル化することにより、モデル間やソースコードへの変換の自動化が行われている。その際、システム設計は、例えばUML(Unified Modeling Language)を用いて再利用可能なモデルの形で記述される。 また、ある種のシステムについては、過去の蓄積として既に規定された設計図(モデル)が存在する場合がある。例えば、ネットワークの管理システム(オペレーションシステム)の分野では、システム要件や機能仕様等がITU−T(International Telecommunication Union Telecommunication Standardization Sector:国際電気通信連合電気通信標準化部門)のM.3700シリーズ(http://www.itu.int/rec/T-REC-M/en)によって標準として規定されている。

一方、システム開発における一部工程を自動化する観点から、モデル間の変換を自動化する試みが行われている。例えば、UMLにおける、ステートマシン図とアクティビティ図間の整合性を検証する技術が開示されている(非特許文献1参照)。ここで、ステートマシン図は、システムを構成する個々のオブジェクトの振る舞いを、外部から観測可能な状態の遷移に基づいて記述したものである。また、アクティビティ図は、システムの振る舞いを、システムを構成するオブジェクトやアクターの行う動作フローとして表わしたものである。

野村将人、他1名、「UMLステートマシン−アクティビティ図間の整合性分析」、信学技報、社団法人電子情報通信学会、2011年11月、SWIM2011-29、p.65−70

しかしながら、従来のMDAツールを用いた技術では、設計図となるモデルをUML等において、設計者が予め記述しデータ化しておくことが前提となる。したがって、システムの設計図となるモデルを作成すること、つまり、モデル自体の設計・開発にコストがかかってしまう問題があった。 前述のように、オペレーションシステムの分野では標準として定められたモデルが既に存在するが、それらの標準化ドキュメントの多くは自然言語で書かれたテキスト文書であり、それらを実際に利用するためには、設計者がドキュメントを読み込んだ上で内容を理解し、UML等に変換していく必要があった。 また、非特許文献1に記載の技術のように、一部工程(ステートマシン図−アクティビティ図間)についての自動化は示唆されているものの、既に標準として規定されたシステム設計書(以下、「標準化ドキュメント」と称する。)の内容をビジネスプロセス図の形に変換できるものはなかった。

このような背景を鑑みて本発明がなされたのであり、本発明は、オペレーションシステム開発の上流工程におけるシステム設計を規定した標準化ドキュメントから、ビジネスプロセス図を生成することができる、ビジネスプロセス図生成装置、ビジネスプロセス図生成プログラム、および、ビジネスプロセス図生成方法を提供することを課題とする。

前記した課題を解決するため、請求項1に記載の発明は、ビジネスプロセスに関するユースケース表、前記ビジネスプロセスに関するデータの属性をクラスとして定義するクラス定義、および、前記ビジネスプロセスにおける個々の操作内容を記述したオペレーション表を含む標準化ドキュメントを、構造化されたフォーマットに基づく構造化データに変換するルールを示す再構築ルール情報が記憶される記憶手段と、前記標準化ドキュメントを取り込み、前記再構築ルール情報を参照して、前記構造化データに変換するデータ再構築手段と、前記ユースケース表の構造化データを自然言語処理し、前記ユースケース表で示される処理内容を状態遷移図に変換した構造化データを生成するサブプロセス解析手段と、前記ユースケース表、前記クラス定義、前記オペレーション表、前記状態遷移図の各構造化データを用いて、ビジネスプロセス図を生成するプロセス変換手段と、を備え、前記プロセス変換手段が、前記ユースケース表の構造化データを参照して、当該ユースケースにおけるユースケース名を抽出し、前記ビジネスプロセス図のアクティビティを記述し、前記ユースケース表の構造化データを参照して、当該ユースケースにおける操作を抽出し、前記抽出した操作と同じ操作を示す前記操作内容を前記オペレーション表から取得して前記ビジネスプロセス図に記述し、前記生成された状態遷移図の構造化データを参照し、当該状態遷移図に示される状態の遷移を前記ビジネスプロセス図における前記アクティビティとし、当該状態の分岐を前記ビジネスプロセス図におけるゲートウェイおよびメッセージとして、当該アクティビティ間の順序関係を記述し、前記クラス定義の構造化データを参照して当該クラスの前記データの属性を抽出し、前記抽出したデータの属性が示す操作と同じ操作内容を前記オペレーション表から取得して、当該クラスと前記取得した操作内容とを対応付けて前記ビジネスプロセス図に記述する、ことにより前記ビジネスプロセス図を生成することを特徴とするビジネスプロセス図生成装置とした。

また、請求項5に記載の発明は、ビジネスプロセスに関するユースケース表、前記ビジネスプロセスに関するデータの属性をクラスとして定義するクラス定義、および、前記ビジネスプロセスにおける個々の操作内容を記述したオペレーション表を含む標準化ドキュメントを用いて、ビジネスプロセス図を生成するビジネスプロセス図生成装置のビジネスプロセス図生成方法であって、前記ビジネスプロセス図生成装置が、前記標準化ドキュメントを、構造化されたフォーマットに基づく構造化データに変換するルールを示す再構築ルール情報が記憶される記憶手段を備えており、前記標準化ドキュメントを取り込み、前記再構築ルール情報を参照して、前記構造化データに変換するステップと、前記ユースケース表の構造化データを自然言語処理し、前記ユースケース表で示される処理内容を状態遷移図に変換した構造化データを生成するステップと、前記ユースケース表の構造化データを参照して、当該ユースケースにおけるユースケース名を抽出し、ビジネスプロセス図のアクティビティを記述し、前記ユースケース表の構造化データを参照して、当該ユースケースにおける操作を抽出し、前記抽出した操作と同じ操作を示す前記操作内容を前記オペレーション表から取得して前記ビジネスプロセス図に記述し、前記生成された状態遷移図の構造化データを参照し、当該状態遷移図に示される状態の遷移を前記ビジネスプロセス図における前記アクティビティとし、当該状態の分岐を前記ビジネスプロセス図におけるゲートウェイおよびメッセージとして、当該アクティビティ間の順序関係を記述し、前記クラス定義の構造化データを参照して当該クラスの前記データの属性を抽出し、前記抽出したデータの属性が示す操作と同じ操作内容を前記オペレーション表から取得して、当該クラスと前記取得した操作内容とを対応付けて前記ビジネスプロセス図に記述する、ことにより前記ビジネスプロセス図を生成するステップと、を実行することを特徴とするビジネスプロセス図生成方法とした。

このようにすることで、ビジネスプロセス図生成装置が、ユースケース表、クラス定義、オペレーション表を含む標準化ドキュメントを取り込み、再構築ルール情報を参照して、各標準化ドキュメントを構造化データに変換することができる。そして、ビジネスプロセス図生成装置は、ユースケース表の構造化データを自然言語処理し、ユースケース表で示される処理内容を状態遷移図に変換する。続いて、ビジネスプロセス図生成装置は、ユースケース表、クラス定義、オペレーション表、状態遷移図の各構造化データを用いて、ビジネスプロセス図を生成する。 よって、ビジネスプロセス図生成装置は、オペレーションシステムの設計に関する標準化ドキュメントに基づき、その標準化ドキュメントに記載された各項目を解析することにより、ビジネスプロセス図を(自動で)生成することができる。したがって、オペレーションシステム開発(特に設計工程)のコストを削減することができる。

請求項2に記載の発明は、前記サブプロセス解析手段が、前記ユースケース表で示される当該ユースケースの処理の内容を構文解析し、主文で示される内容を状態とし、従属文で示される内容を状態の遷移として当該ユースケースにおける状態遷移図を作成し、前記プロセス変換手段が、当該ユースケースにおける状態遷移図の前記状態の遷移を、前記ビジネスプロセス図において、当該ユースケースのユースケース名として記述された前記アクティビティのサブプロセスのアクティビティとして記述することを特徴とする請求項1に記載のビジネスプロセス図生成装置とした。

このようにすることで、ビジネスプロセス図生成装置は、ユースケース表で示されるユースケース内における処理の状態遷移図を作成し、ビジネスプロセス図にアクティビティのサブプロセスとして記述することができる。

請求項3に記載の発明は、前記標準化ドキュメントが、ITU−TのM.3020で規定された書式の標準化ドキュメントであることを特徴とする、請求項1または請求項2に記載のビジネスプロセス図生成装置とした。

このようにすることで、ITU−TのM.3020において規定された書式の標準化ドキュメントに沿って作成されたデータを利用し、ビジネスプロセス図を生成することができる。

請求項4に記載の発明は、コンピュータを、請求項1乃至請求項3のいずれか一項に記載のビジネスプロセス図生成装置として機能させるためのビジネスプロセス図生成プログラムとした。

このようにすることで、一般的なコンピュータを、請求項1乃至3のいずれか一項に記載のビジネスプロセス図生成装置として機能させることができる。

本発明によれば、オペレーションシステム開発の上流工程におけるシステム設計を規定した標準化ドキュメントから、ビジネスプロセス図を生成する、ビジネスプロセス図生成装置、ビジネスプロセス図生成プログラム、および、ビジネスプロセス図生成方法を提供することができる。

標準化ドキュメントにおいて「要件(Requirement)」が記載された例を示す図である。

標準化ドキュメントにおいて「ユースケース(Use Case)表」が記載された例を示す図である。

標準化ドキュメントにおいて「クラス図」および「IOC定義」が記載された例を示す図である。

標準化ドキュメントにおいて、「状態遷移図」が記載された例を示す図である。

標準化ドキュメントにおいて、「オペレーション表」が記載された例を示す図である。

本実施形態に係るビジネスプロセス図生成装置の構成例を示す機能ブロック図である。

標準化ドキュメント(PDF形式)における「要件(Requirement)」を、標準化ドキュメント(XML形式)に変換した図である。

標準化ドキュメント(PDF形式)における「ユースケース表」を、標準化ドキュメント(XML形式)に変換した図である。

本実施形態に係る再構築ルール情報を例示する図である。

ユースケース表を、XML形式の構造化データに再構築した例を示す図である。

IOC定義を、XML形式の構造化データに再構築した例を示す図である。

オペレーション表を、XML形式の構造化データに再構築した例を示す図である。

本実施形態に係るサブプロセス解析部の機能構成を示すブロック図である。

本実施形態に係るサブプロセス表作成部によるサブプロセス表の作成を説明するための図である。図14(a)は、ユースケース表の「Step」の項目例を示す図である。図14(b)は、サブプロセス表作成部が作成したサブプロセス表を示す図である。

本実施形態に係る状態遷移図作成部が作成した状態遷移図(ユースケース内)を例示する図である。

本実施形態に係る状態遷移図作成部による状態遷移図(ユースケース間)の作成を説明するための図である。図16(a)は、ユースケース表の「Preconditions」「Begins when」「Ends when」「Post Conditions」の項目例を示す図である。図16(b)は、状態遷移図作成部が作成した状態遷移図(ユースケース間)を示す図である。

本実施形態に係るプロセス変換部の機能構成を示すブロック図である。

本実施形態に係るビジネスプロセス図設定部が、ビジネスプロセス図において「オペレータ」、「NML/EML」、「NE」の3つのプールを設定した例を示す図である。

本実施形態に係るアクティビティ抽出部が、ビジネスプロセス図のオペレータプールに、ユースケース名をアクティビティとして配置した例を示す図である。

本実施形態に係るオペレーション抽出部が、ユースケースに対応するオペレーションを抽出して、ビジネスプロセス図上にアクティビティとして配置した例を示す図である。

本実施形態に係るフロー作成部が、状態遷移図(ユースケース間)に基づき、ビジネスプロセス図のアクティビティ間の順序関係を記述した例を示す図である。

本実施形態に係るデータ配置部が、IOC定義で示されるデータとプール間のメッセージとを関連付けてビジネスプロセス図上に配置した例を示す図である。

本実施形態に係るサブプロセス図作成部が、状態遷移図(ユースケース内)に基づき、アクティビティに対してサブプロセスを記述した例を示す図である。

本実施形態に係るプロセス変換部が出力するビジネスプロセス図を例示する図である。

次に、本発明を実施するための形態(以下、「本実施形態」という。)におけるビジネスプロセス図生成装置1(図6参照)等について説明する。 本実施形態に係るビジネスプロセス図生成装置1は、オペレーションシステムの設計に関する標準化ドキュメントを取り込み、その標準化ドキュメントに記載された各項目を解析することにより、ビジネスプロセス図300(後記する図24参照)を(自動で)生成する。ここで、図24は、ビジネスプロセス図として一般的に用いられる、BPMN(Business Process Modeling Notation)に基づき表記した例である。BPMNでは、アクティビティを表わす角丸四角形の記号の中に処理の内容を記載し、そのアクティビティが矢印で表記されるシーケンスフローによってつなげられる。また、各種のイベントは丸で表記され、条件分岐はひし形で表現される。

オペレーションシステムの分野では、システムの設計モデル(要件、機能仕様、処理内容等)の標準規格が規定されている。本実施形態に係るビジネスプロセス図生成装置1は、その情報(標準化ドキュメント)を再利用することにより、オペレーションシステム開発の設計コストを削減することができる。また、ビジネスプロセス図300という形にすることにより、後工程において必要な情報を付加することで、ワークフローエンジン上での実行にもつなげることができ、開発コストの削減が可能となる。

<標準化ドキュメント> まず、本実施形態に係るビジネスプロセス図生成装置1が処理の対象とする標準化ドキュメント(構造化文書)について説明する。 ここでは、ビジネスプロセス図生成装置1が、ITU−TのM.3020において規定され、M.3700シリーズで実際に用いられた書式によって書かれた標準化ドキュメントを例として説明する。例えば、このM.3700シリーズのM.3703(アラーム管理)やM.3704(性能管理)においては、オペレーションシステムの設計において必要な内容が、M.3020で規定された書式に沿った標準化ドキュメントとして記載されている。本実施形態では、このM.3020において規定された書式の標準化ドキュメント、具体的には、M.3700シリーズ(特に、M.3703,M.3704)に記載される項目のうち、少なくとも、「要件」、「ユースケース表」、「クラス図等」、「状態遷移図」、「オペレーション表」が、標準化されたドキュメントとして記載されているものとする。 以下、本実施形態に係る標準化ドキュメントについて、詳細に説明する。

図1は、標準化ドキュメントにおいて「要件(Requirement)」が記載された例(ITU−T M.3703の「6.2.1 Requirements」)を示す図である。この「要件」には、「何を実現したいか」や「何ができる必要があるか」等の情報が記載される。 また、この「要件(Requirement)」では、個々の要件に「Requirement ID」が付された形式で記載される。図1においては、「Requirement ID」として、「REQ-FM-FUN-01」「REQ-FM-FUN-02」が要件それぞれに付された例を示している。 なお、各要件の具体的な内容については、本発明との係わりがないため具体的な説明をせず、標準化ドキュメントの記載形式の説明に必要な範囲において、ITU−TのM.3700シリーズ(特に、M.3703,M.3704)を引用して記述する。以下の標準化ドキュメントの説明においても同様に、記載形式の説明に必要な範囲において記述する。

図2は、標準化ドキュメントにおいて「ユースケース(Use Case)表」が記載された例(ITU−T M.3703の「6.3.4 Use Cases」)を示す図である。 ユースケース表は、システム利用者の視点で、システムに対する要求事項(処理)を記述するものである。このユースケース表では、図2に示すように、ユースケース名として「Set alarm filter」が記述され、ユースケースの各段階(Use case stage)として、「Goal(目的)」「Actor and roles(アクターとロール)」「Telecom resources(通信リソース)」「Assumptions(前提条件)」「Preconditions(事前条件)」「Begins when(開始時)」「Step(処理)」「Ends when(終了時)」「Exceptions(例外)」「Post Conditions(事後条件)」「Traceability(追跡可能性)」が設定されており、その内容が記述される。

なお、「Step(処理)」の項目は、図2に示す「Step 1」の一つだけでなく、「Step 2」「Step 3」等のように複数記述される場合もある。また、ユースケース表についても、一つの標準化ドキュメントに複数のユースケース表が記述されていてもよく、例えば、ITU−T M.3703の「6.3.4 Use Cases」では、図2に示した「6.3.4.1 Use case : Set alarm filter」に続いて、同様の書式で他のユースケース表として「6.3.4.2 Use Case : Notification of alarm change」等が記述されている。

図3は、標準化ドキュメントにおいて「クラス図」(データモデル)およびオブジェクトクラス定義(IOC(Information Object Class)定義)が記載された例(ITU−T M.3704の「7.2.2 Class diagram」「7.2.3 Information object class definitions」)を示す図である。なお、以下において、「クラス図」(データモデル)とIOC定義とを合わせて、「IOC情報」と称することがある。 図3(a)に示すクラス図は、システムを構成するクラスと、クラス間の相互関係が記述され、システム全体の静的な構造(データ構造)を明らかにするために作成される。また、図3(b)に示すIOC定義は、各クラスに属する要件が前記した「Requirement ID」として定義される。

図4は、標準化ドキュメントにおいて、「状態遷移図」が記載された例(ITU−T M.3704の「7.2.3.2.4 State diagram」)を示す図である。状態遷移図は、時間の経過や動作によって変化する状態を示す図である。ここでは、状態を角丸四角形で表わし、状態の遷移(トリガ)を矢印で表わしている。

図5は、標準化ドキュメントにおいて、「オペレーション表」が記載された例(ITU−T M.3704の「7.3.3 Interface PMIRPOperations」)を示す図である。オペレーション表は、ある要件を満たすときに実行される操作(オペレーション)と、その操作を実行する際のパラメータ(インプットパラメータ、アウトプットパラメータ)が記述される。 図5の符号(a)に示す表は、各操作を示すオペレーション名(Operation name)に対応付けて、前記した要件(Requirement)の識別子である「Requirement ID」が記述される例を示している。図5の符号(b)に示す表は、操作(オペレーション)が「createMeasurementJob」の場合におけるインプットパラメータ(Input parameter)として、「moClass」等が記述される例を示している。また、図5の符号(c)に示す表は、操作(オペレーション)が「createMeasurementJob」の場合におけるアウトプットパラメータ(Output parameter)として、「measurementJobId」等が記述される例を示している。

ビジネスプロセス図生成装置1は、上記において説明した、「要件」、「ユースケース表」、「IOC情報」(クラス図およびIOC定義)、「状態遷移図」、「オペレーション表」が標準化されたドキュメントに基づき、ビジネスプロセス図300(図24参照)を生成する。これにより、オペレーションシステム開発の設計コストを削減することができる。また、ビジネスプロセス図300という形にすることにより、後工程において必要な情報を付加することで、ワークフローエンジン上での実行にもつなげることができるため、開発コストの削減が可能となる。 また、ビジネスプロセス図は、UMLにおいて規定されるものではないが、UMLの規定の中ではアクティビティ図に近い表記であり相互変換が容易であるため、生成したビジネスプロセス図をUMLに変換して利用することも可能となる。

<ビジネスプロセス図生成装置> 次に、ビジネスプロセス図生成装置1について説明する。 ビジネスプロセス図生成装置1は、前記した標準化ドキュメントからビジネスプロセス図300(図24参照)を生成する装置であり、制御部、記憶部、入出力部(いずれも図示省略)を備えるコンピュータにより構成される。 ここで、記憶部(記憶手段)は、ハードディスクやフラッシュメモリ、RAM(Random Access Memory)等により構成され、後記する再構築ルール情報200等を格納する。 また、入出力部は、外部装置との間で情報の送受信を行う通信インタフェースと、図示を省略したキーボード等の入力装置やモニタ等の出力装置との間で情報の入出力を行う入出力インタフェースとから構成される。 制御部は、ビジネスプロセス図生成装置1が実行する処理の全般を司り、下記において説明する各機能を実現する。なお、この制御部は、例えば、このビジネスプロセス図生成装置1の記憶部に格納されたプログラム(ビジネスプロセス図生成プログラム)をCPU(Central Processing Unit)がRAMに展開し実行することにより実現される。

図6は、本実施形態に係るビジネスプロセス図生成装置1の構成例を示す機能ブロック図である。 ビジネスプロセス図生成装置1の制御部は、図6に示すように、データ抽出部10(データ再構築手段)、再構築部20(データ再構築手段)、サブプロセス解析部30(サブプロセス解析手段)、プロセス変換部40(プロセス変換手段)を含んで構成される。

データ抽出部10(データ再構築手段)は、前記した標準化ドキュメント(ここでは、PDF(Portable Document Format)形式のドキュメントとする。)を読み込んで、構造化されたフォーマット(例えば、XML形式等)に変換し、標準化ドキュメント(XML形式)として出力する。 再構築部20(データ再構築手段)は、データ抽出部10が出力した標準化ドキュメント(XML形式)を読み込み、意味的に構造化して、要件、ユースケース表、IOC情報、状態遷移図、オペレーション表のそれぞれを再構築し、構造化データ(XML形式)として出力する。このとき、再構築部20は、記憶部に予め記憶された再構築ルール情報200(後記する図9)を参照することにより各情報を再構築する。 サブプロセス解析部30(サブプロセス解析手段)は、ユースケース表を自然言語処理し、サブプロセス表(後記する図14(b)参照)と、状態遷移図(ユースケース内)(後記する図15参照)と、状態遷移図(ユースケース間)(後記する図16(b)参照)と、を出力する。なお、状態遷移図(ユースケース内)とは、ある一つのユースケース内における状態遷移を表わす図である。また、状態遷移図(ユースケース間)とは、複数のユースケース間における状態遷移を表わす図である。 プロセス変換部40(プロセス変換手段)は、再構築部20およびサブプロセス解析部30が作成した、要件、ユースケース表、IOC情報(「クラス図(データモデル)」および「IOC定義」)、各種の状態遷移図、オペレーション表の構造化データ(XML形式)を読み込み、ビジネスプロセス図として出力する。 以下、これらの機能について詳細に説明する。

≪データ抽出部≫ データ抽出部10(図6参照)は、標準化ドキュメント(PDF形式)で記述された、「要件」、「ユースケース表」、「IOC情報」(クラス図およびIOC定義)、「状態遷移図」、「オペレーション表」等の情報を取り込んで、字句解析を行い、構造化されたフォーマット(XML形式等)に変換して、標準化ドキュメント(XML形式)として出力する。なお、このデータ抽出部10による、標準化ドキュメントのPDF形式からXML形式の変換は、既存技術を用いて行うことができる(例えば、PDF形式からXML形式への変換について、「https://helpx.adobe.com/jp/acrobat/kb/558.html」等を参照。)。

図7は、標準化ドキュメント(PDF形式)の中で「要件(Requirement)」を記載した部分(図1参照)を、既存技術を用いて機械的に標準化ドキュメント(XML形式)に変換した図である。また、図8は、標準化ドキュメント(PDF形式)の中で「ユースケース(Use Case)表」を記載した部分(図2参照)を、既存技術を用いて機械的に標準化ドキュメント(XML形式)に変換した図である。 データ抽出部10は、同様に、標準化ドキュメント(PDF形式)の中で、「IOC情報」、「状態遷移図」、「オペレーション表」等を記載した部分についても、既存技術を用いて機械的に標準化ドキュメント(XML形式)に変換する。

≪再構築部≫ 再構築部20(図6参照)は、データ抽出部10が出力した各標準化ドキュメント(XML形式)を読み込み、記憶部に記憶された再構築ルール情報200(図9)を参照することにより、意味的に構造化した、要件、ユースケース表、IOC情報、状態遷移図、オペレーション表等の情報を作成し出力する。なお、意味的に構造化した情報を、以下「構造化データ」を称することがある。また、「意味的に構造化した」とは、前記した「機械的に」構造化したXML形式のデータとは異なり、基となる情報(PDF形式で記載された標準化ドキュメント)の内容に即して要素や属性、テキストデータ等が記述されることを意味する(後記する図10〜図12参照)。

図9は、本実施形態に係る再構築ルール情報200を例示する図である。 再構築ルール情報200には、「変換前のPath」と「変換後のPath」とが対応付けて記述される。図9に示す例では、ユースケース表の「Goal(目的)」について、その“Goal”が記述される位置、“Goal”の要素の値が記述される位置について、「変換前のPath」と「変換後のPath」とが対応付けられる。再構築ルール情報200には、このように、標準化ドキュメント(PDF形式)において記述される項目を、意味的に構造化した情報(XML形式の構造化データ)として再構築できるように、変換ルールを定めておく。

図10は、再構築部20が再構築ルール情報200を参照して、ユースケース表を、意味的に構造化された情報(XML形式の構造化データ)に再構築した例を示す図である。図11は、図3(b)に示したIOC定義を規定した標準化ドキュメント(PDF形式)についてデータ抽出部10が出力した標準化ドキュメント(XML形式)を、再構築部20が取得し、再構築ルール情報200を参照して意味的に構造化されたIOC定義の情報(XML形式の構造化データ)に再構築した例を示す図である。また、図12は、図5に示したオペレーション表を規定した標準化ドキュメント(PDF形式)についてデータ抽出部10が出力した標準化ドキュメント(XML形式)を、再構築部20が取得し、再構築ルール情報200を参照して意味的に構造化されたオペレーション表の情報(XML形式の構造化データ)に再構築した例を示す図である。

標準化ドキュメントにおいては、記載要件(様式)が予め決められているため、各項目について、予めその変換内容を、再構築ルール情報200として指定しておくことができる。よって、再構築部20は、取り込んだ標準化ドキュメント(XML形式)の各情報(要件、ユースケース表、IOC情報、状態遷移図、オペレーション表)を、再構築ルール情報200を参照することにより、基となる標準化ドキュメントの内容を反映したXML形式の構造化データに再構築し出力することができる。

≪サブプロセス解析部≫ サブプロセス解析部30(図6参照)は、ユースケース表を自然言語処理し、サブプロセス表(図14(b)参照)と、状態遷移図(ユースケース内)(図15参照)と、状態遷移図(ユースケース間)(図16(b)参照)と、を出力する。 図13は、サブプロセス解析部30の詳細な機能構成を示すブロック図である。図13に示すように、サブプロセス解析部30は、字句解析部31と、サブプロセス表作成部32と、状態遷移図作成部33とを含んで構成される。

字句解析部31は、再構築部20が出力したユースケース表の構造化データを参照し、ユースケース表に記載された内容を字句ごとに切り分ける。具体的には、字句解析部31は、ユースケース表の中の「Step(手段)」の内容を字句ごとに切り分ける解析を行う。 サブプロセス表作成部32は、字句解析部31の出力情報を用いて、ユースケース表の「Step(手段)」の項目を、構文解析により主語と述語に分解し、サブプロセス表を作成する。

ここでは、ユースケース表のうちの「Step(手段)」の項目について、図14(a)に示すように、「Step 1」「Step 2.1」「Step 2.2」が設定されているものとして説明する。なお、サブプロセス解析部30は、再構築部20から、標準化ドキュメントをXML形式の構造化データに再構築した情報を取得して処理を行うが、図14(a)においては、説明を分かりやすくするため、ユースケース表を基となるPDF形式の表現で図示し説明する。

サブプロセス表作成部32は、このユースケース表の「Step」の内容を構文解析し、主文に示される文章を抽出し、主語(主体)と述語(内容)に分解してユースケース表に格納する。また、サブプロセス表作成部32は、主語が、「manager」(管理者)および「agent」(処理の行為者)ではない文章については、処理内容を示す命令文に変換し、ユースケース表に格納する。

図14(b)は、上記のようにして、サブプロセス表作成部32が作成したサブプロセス表を示す。なお、図14(b)についても、サブプロセス表作成部32は、実際には、XML形式の構造化データとして処理を行うが、ここでは、分かりやすくするため、表形式で図示している。

サブプロセス表作成部32は、例えば、図14(a)に示すユースケース表の「Step 1」を参照し、「The manager sends a request to the agent ・・・」(図14(a)の符号[1]参照)を主文と判定する。そして、サブプロセス表作成部32は、主語(主体)として「The manager」と抽出し、述語(内容)として、「Send a request to the agent」を抽出して、図14(b)に示すサブプロセス表に格納する(図14(b)の符号[1]参照)。 また、サブプロセス表作成部32は、ユースケース表の「Step 2.1」を参照し、「the job ID will be returned to the manager」(図14(a)の符号[2]参照)を主文と判定する。そして、サブプロセス表作成部32は、主語(主体)が「manager」でも「agent」でもないため、当該文を処理内容を示す命令文に変換し「Return job ID to the manager」とした上で、図14(b)のサブプロセス表の内容の欄に格納する。その際、主体には、主語が「manager」でも「agent」でもないことを示す「−」が格納される(図14(b)の符号[2]参照)。 このようにすることで、サブプロセス表作成部32は、各ユースケース表の「Step」に示される処理の主体と内容を抽出し、サブプロセス表を作成することができる。

状態遷移図作成部33(図13参照)は、状態遷移図(ユースケース内)と状態遷移図(ユースケース間)を作成する。 状態遷移図作成部33は、図14(a)で示されるユースケース表の「Step」の内容と、サブプロセス表作成部32が作成した、サブプロセス表(図14(b))を参照し、状態遷移図(ユースケース内)を作成する。

具体的には、状態遷移図作成部33は、図14(a)を参照し、ユースケース表の「Step」の内容において、If節やOtherwise節を含む、主文に対する従属文を、状態遷移表における「状態」として扱う。また、サブプロセス表の内容を、その状態の遷移(トリガ)として扱う。

図15は、状態遷移図作成部33が作成した状態遷移図(ユースケース内)を例示する図である。図15に示すように、If節や、Otherwise節、主文に対する従属文を、状態として丸(〇)で示し、サブプロセス表の内容を、状態の遷移(トリガ)として矢印(→)で示している。 このようにして、状態遷移図作成部33は、各ユースケース表について、状態遷移図(ユースケース内)を作成することができる。

また、状態遷移図作成部33は、各ユースケース表の「Preconditions(事前条件)」「Begins when(開始時)」「Ends when(終了時)」「Post Conditions(事後条件)」を参照し、ユースケース間の順序関係、遷移パターンを状態遷移図(ユースケース間)として作成する。

図16に示すように、状態遷移図作成部33は、複数のユースケース表それぞれの「Preconditions(事前条件)」「Begins when(開始時)」「Ends when(終了時)」「Post Conditions(事後条件)」を自然言語処理することにより、ユースケース間の順序関係、遷移パターンを解析し、各ユースケース表のユースケース名を、状態遷移のトリガとして記述する。 なお、前記したようにサブプロセス解析部30は、再構築部20から、標準化ドキュメントをXML形式の構造化データに再構築した情報を取得して処理を行うが、説明を分かりやすくするため、図16(a)においては、ユースケース表を基となるPDF形式の表現で図示し、図16(b)においては、状態遷移図の形式で図示している。

図16(b)の状態遷移図(ユースケース間)は、例えば、「6.3.4.1 Create a measurement job」の処理のあと、「6.3.4.2 Suspend a measurement job」と「6.3.4.5 Stop a measurement job」とに処理が分岐し、状態が遷移すること等を示している。なお、「6.3.4.1」等のユースケース表の項番は、状態遷移図(ユースケース間)において、記載してもよいし、記載を省略してもよい。 このようにして、状態遷移図作成部33は、各ユースケース間の順序や遷移パターンを示す状態遷移図(ユースケース間)を作成することができる。

≪プロセス変換部≫ プロセス変換部40(図6参照)は、再構築部20およびサブプロセス解析部30が作成した、要件、ユースケース表、IOC情報(クラス図およびIOC定義)、各種の状態遷移図、オペレーション表を読み込み、ビジネスプロセス図300として出力する。 図17は、プロセス変換部40の詳細な機能構成を示すブロック図である。図17に示すように、プロセス変換部40は、ビジネスプロセス図設定部41と、アクティビティ抽出部42と、オペレーション抽出部43と、フロー作成部44と、データ配置部45と、サブプロセス図作成部46とを含んで構成される。

なお、プロセス変換部40は、再構築部20およびサブプロセス解析部30が作成した、要件、ユースケース表、IOC情報(クラス図およびIOC定義)、各種の状態遷移図、オペレーション表を、XML形式の構造化データとして取得し処理を行う。しかしながら、以下に示すプロセス変換部40に関する図においては、説明を分かりやすくするため、ユースケース表やオペレーション表については、基となるPDFでの表現で図示し、状態遷移図についても、XML形式ではなく、UML等で規定される状態遷移図の表現で図示して説明する。 また、プロセス変換部40は、ビジネスプロセス図300の生成処理を開始する前処理として、取得した複数の状態遷移図を抽出して解析することにより、これらをマージした状態遷移図を作成しておいてもよい。

ビジネスプロセス図設定部41(図17参照)は、空のビジネスプロセス図300を生成し、プロセスの処理の主体となるレイヤについてのプールを設定する。 図18は、ビジネスプロセス図設定部41が、ビジネスプロセス図300において「オペレータ」、「NML/EML」(Network Management Layer/Element Management Layer)、「NE」(Network Element)の3つのプールを設定した例を示す図である。本実施形態においては、ビジネスプロセス図生成装置1が、ネットワーク設計のビジネスプロセス図300を作成する場合を例として説明する。よって、ここでは、ビジネスプロセス図設定部41が、システム全体の管理に関する「オペレータ」のプール(以下、「オペレータプール」と称する。)と、ネットワーク間の接続や各ネットワーク装置の設定、処理に関する「NML/EML」のプール(以下、「NML/EMLプール」と称する。)と、個々のネットワーク装置の処理を実行する「NE」のプール(以下、「NEプール」と称する。)と、をビジネスプロセス図300に設定するものとする。

アクティビティ抽出部42(図17参照)は、ユースケース表に基づき、ビジネスプロセス図300上において、「アクティビティ」となり得るユースケースを抽出する。 具体的には、アクティビティ抽出部42は、各ユースケース表の項目のうち、「Begins When(開始時)」を参照し、マネージャ(manager)が主語となるもの、つまり、「The manager」から始まるものを検出し、そのユースケース(ユースケース名)を、アクティビティとしてオペレータプールに配置する。 また、アクティビティ抽出部42は、ユースケース表の項目のうち、同じく「Begins When(開始時)」を参照し、エージェント(agent)が主語となるもの、つまり、「The agent」から始まるものを検出し、そのユースケース(ユースケース名)を、アクティビティとしてNML/EMLプールに配置する。

図19は、アクティビティ抽出部42が、ユースケース表の項目のうち「Begins When(開始時)」を参照し、「The manager」が主語となる文を検出し、「Create a measurement job」および「Suspend a measurement job」のユースケース名を、ビジネスプロセス図300のオペレータプールに、アクティビティとして配置した例を示している。 このようにして、アクティビティ抽出部42は、ビジネスプロセス図300のオペレータプールおよびNML/EMLプールに、アクティビティを配置することができる。

オペレーション抽出部43(図17参照)は、アクティビティ抽出部42が抽出した各ユースケースに対応するアクティビティが送受信するメッセージとして、オペレーション表から対応するオペレーションを検出し、ビジネスプロセス図300上に配置する。つまり、オペレーション抽出部43は、各ユースケースに対応するオペレーションを抽出して、ビジネスプロセス図300上に配置する処理を行う。

具体的には、オペレーション抽出部43は、ユースケース表の「Traceability(追跡可能性)」に記載されている「RequirementID」を抽出し、抽出した「RequirementID」とオペレーション表に記載された各オペレーションの「RequirementID」とが一致するオペレーション名(Operation name)を検索する。そして、オペレーション抽出部43は、検索したオペレーション名を、当該ユースケースのアクティビティの真下のNML/EMLプールの位置に、アクティビティとして配置する。

そして、オペレーション抽出部43は、オペレータプールに配置されたユースケースのアクティビティから、NML/EMLプールに配置された対応するオペレーションのアクティビティに向けてのメッセージフロー(点線矢印)を作成する。さらに、オペレーション抽出部43は、そのメッセージフローに、オペレーション表に記載されたインプットパラメータを記載する。また、オペレーション抽出部43は、NML/EMLプールに配置されたオペレーションのアクティビティから、オペレータプールに配置されたユースケースのアクティビティに向けてのメッセージフローを作成する。そして、オペレーション抽出部43は、そのメッセージフローに、オペレーション表に記載されたアウトプットパラメータを記載する。

なお、オペレーション抽出部43は、ユースケースに対応するオペレーションがない場合には、ユースケースのアクティビティを、その旨がわかるように、色を付したり、コメントを付けて表示したりするようにしてもよい。 また、NEとのメッセージのやりとりがあるオペレーションに関しては、NML/EMLプールとNEプールとの間にメッセージフロー(点線矢印)を記載する。

図20では、オペレーション抽出部43が、ユースケース表「6.3.4.1 Create a measurement job」の「Traceability(追跡可能性)」に記載されている「REQ-PM-FUN-01, REQ-PM-FUN-02」を抽出し、その抽出した「RequirementID」とオペレーション表に記載された各オペレーションの「RequirementID」とが一致するオペレーション名(Operation name)として「createMeasurementjob」を検出する。そして、オペレーション抽出部43が、ユースケースのアクティビティ「Create a measurement job」の真下のNML/EMLプールの位置に、アクティビティ「createMeasurementJob()」を配置する。 次に、オペレーション抽出部43は、オペレータプールに配置されたユースケースのアクティビティ「Create a measurement job」から、NML/EMLプールに配置された対応するオペレーションのアクティビティ「createMeasurementJob()」に向けてメッセージフロー(点線矢印)を作成する。さらに、オペレーション抽出部43は、そのメッセージフローに、オペレーション表に記載されたインプットパラメータのパラメータ名として「moClass」等を抽出して記載する。同様に、オペレーション抽出部43は、NML/EMLプールに配置されたオペレーションのアクティビティ「createMeasurementJob()」から、オペレータプールに配置されたユースケースのアクティビティ「Create a measurement job」に向けてのメッセージフローに、オペレーション表に記載されたアウトプットパラメータ(「measurementJobId」等)のパラメータ名を抽出して記載する。

このようにして、オペレーション抽出部43は、アクティビティ抽出部42が抽出した各アクティビティが送受信するメッセージとして、オペレーション表から対応するオペレーションを検出し、ビジネスプロセス図300上にアクティビティとして配置することができる。また、オペレーション抽出部43は、そのメッセージフローにインプットパラメータとアウトプットパラメータを記載することができる。

フロー作成部44(図17参照)は、サブプロセス解析部30が生成した状態遷移図(ユースケース間)に基づき、アクティビティ間の順序関係をビジネスプロセス図300に記述する。 具体的には、フロー作成部44は、状態遷移図(ユースケース間)における、状態遷移のトリガをビジネスプロセス図300のオペレータプールのアクティビティに対応させる。また、状態遷移図(ユースケース間)における、状態の分岐を、ビジネスプロセス図300におけるゲートウェイとメッセージに対応させる。

図21は、フロー作成部44が、サブプロセス解析部30(状態遷移図作成部33)により作成された状態遷移図(ユースケース間)(図16(b)参照)に基づき、ビジネスプロセス図300のアクティビティ間の順序関係を記述した例を示す図である。 図21に示すように、状態遷移図(ユースケース間)における状態の遷移(トリガ)をアクティビティとみなす。例えば、「6.3.4.1 Create a measurement job」を、ビジネスプロセス図300におけるアクティビティの「Create a measurement job」とし、他の状態の遷移(トリガ)についても同様にビジネスプロセス図300におけるアクティビティと対応付けを行った上で、状態遷移図(ユースケース間)で示される状態の遷移に沿って、アクティビティ間の順序関係を記述する。そして、状態遷移図(ユースケース間)における状態の分岐を、ビジネスプロセス図300においてゲートウェイとメッセージに対応付ける。

このようにすることにより、フロー作成部44は、ビジネスプロセス図300において、アクティビティ間の順序を記述することができる。また、フロー作成部44は、状態が分岐する際に必要となるメッセージを、NML/EMLプールの該当するアクティビティに送信することができる。

データ配置部45(図17参照)は、各アクティビティで用いるIOC定義を、ビジネスプロセス図300において「ノート」(補足内容を記載する表示)と「関連」(データとフローの関連付けを示す表示)を用いて記述する。つまり、データ配置部45は、IOC定義で示されるデータとプール間のメッセージとを関連付けてビジネスプロセス図300上に配置する処理を行う(図22参照)。 具体的には、データ配置部45は、IOC定義を参照し、そのIOC定義のクラス名(Class name)に基づき、IOCリストを作成する。図22においては、IOCリストとして、「PMIRP」「MeasurementJob」「Thresholdmonitor」が作成される例を示している。続いて、データ配置部45は、各オペレーション表のインプットパラメータおよびアウトプットパラメータを参照し、以下のいずれかの条件に該当する場合に、対応するIOCリストのクラス名を、オペレータプールとNML/EMLプールとを結ぶメッセージフローの上に「ノート」として重ねて表示し、IOCリストのクラス名で示されるデータとメッセージフローとを「関連」を用いて結びつける。

(条件1)オペレーション表のインプットパラメータまたはアウトプットパラメータの「Information Type」欄において、先頭に記載されているクラス名を参照し、そのクラス名がIOCリストのクラス名と一致している。 (条件2)オペレーション表のインプットパラメータまたはアウトプットパラメータの「Name」欄から末尾の“Id”を除いたオペレーション名が、IOCのクラス名と一致する。

図22では、オペレーション名が「CreateMeasurementJob」のアウトプットパラメータの「Information Type」欄の先頭に、「MeasurementJob」が記載されているため、IOCリストのクラス名と一致し、(条件1)を満たしている。また、「Name」欄の末尾から“Id”を除いたオペレーション名が「measurementJob」であり、IOCのクラス名と一致し、(条件2)も満たしている。よって、データ配置部45は、ノートにIOCリストのクラス名として「MeasurmentJob」を記載して、オペレータプールとNML/EMLプールとを結ぶメッセージフローの上に重ねて表示し、そのノートとメッセージフローとを「関連」を用いて結びつける。

このようにして、データ配置部45は、上記の(条件1)(条件2)のいずれかに該当する場合に、オペレータプールとNML/EMLプール間のメッセージに関するデータのクラスをビジネスプロセス図300上に配置することができる。

サブプロセス図作成部46(図17参照)は、サブプロセス解析部30が生成した状態遷移図(ユースケース内)に基づき、各アクティビティに対してサブプロセス図を記述する。 具体的には、サブプロセス図作成部46は、サブプロセス解析部30が解析したサブプロセス表に対応するアクティビティの下に、状態遷移図作成部33が作成した状態遷移図(ユースケース内)における状態の遷移(トリガ)を、サブプロセスの順序として記述する。

図23は、サブプロセス図作成部46が、状態遷移図(ユースケース内)に基づき、アクティビティに対してサブプロセスを記述した例を示す図である。図23においては、「Create Measurement Job」のサブプロセスを記述した例を示している。 サブプロセス図作成部46は、図15に示す状態遷移図(ユースケース内)を参照し、ビジネスプロセス図300の「Create Measurement Job」のサブプロセスを記述する。その際、サブプロセス図作成部46は、状態遷移図(ユースケース内)の状態の遷移(トリガ)を、サブプロセスのアクティビティとして記述する。

このようにして、サブプロセス図作成部46は、NML/EMLプールに記載された各アクティビティについてのより詳細な処理の流れを示すサブプロセスをビジネスプロセス図300上に配置することができる。よって、プロセス変換部40は、図24に示すビジネスプロセス図300を生成し出力することができる。図24に示すビジネスプロセス図300は、状態遷移図やクラス図等のUML等の形式に変換して出力することも可能であるため、他のシステム開発においても利用することが可能となる。

以上説明したように、本実施形態に係る、ビジネスプロセス図生成装置1、ビジネスプロセス図生成プログラム、および、ビジネスプロセス図生成方法によれば、標準化ドキュメントを取り込むことにより、その標準化ドキュメントに記載された各項目を解析して、ビジネスプロセス図を(自動で)生成することができる。したがって、オペレーションシステム開発(特に設計工程)のコストを削減することができる。

1 ビジネスプロセス図生成装置 10 データ抽出部(データ再構築手段) 20 再構築部(データ再構築手段) 30 サブプロセス解析部(サブプロセス解析手段) 31 字句解析部 32 サブプロセス表作成部 33 状態遷移図作成部 40 プロセス変換部(プロセス変換手段) 41 ビジネスプロセス図設定部 42 アクティビティ抽出部 43 オペレーション抽出部 44 フロー作成部 45 データ配置部 46 サブプロセス図作成部 200 再構築ルール情報 300 ビジネスプロセス図