JP5482243B2 - 系列生成プログラム、系列生成方法、および系列生成装置 - Google Patents

系列生成プログラム、系列生成方法、および系列生成装置 Download PDF

Info

Publication number
JP5482243B2
JP5482243B2 JP2010018088A JP2010018088A JP5482243B2 JP 5482243 B2 JP5482243 B2 JP 5482243B2 JP 2010018088 A JP2010018088 A JP 2010018088A JP 2010018088 A JP2010018088 A JP 2010018088A JP 5482243 B2 JP5482243 B2 JP 5482243B2
Authority
JP
Japan
Prior art keywords
sequence
series
model
processing
executed
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.)
Expired - Fee Related
Application number
JP2010018088A
Other languages
English (en)
Other versions
JP2011158969A (ja
Inventor
智弘 清水
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2010018088A priority Critical patent/JP5482243B2/ja
Priority to US13/016,738 priority patent/US8677364B2/en
Publication of JP2011158969A publication Critical patent/JP2011158969A/ja
Application granted granted Critical
Publication of JP5482243B2 publication Critical patent/JP5482243B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Description

本発明は処理の系列を生成する系列生成プログラム、系列生成方法、および系列生成装置に関する。
コンピュータシステムには、計算機を複数接続し、それらの間で通信を行って処理を実行する多階層システムがある。多階層システムの一例として、ウェブサーバ、アプリケーションサーバ、データベースサーバからなるウェブ３階層システムと呼ばれるシステムがある。
多階層システムでは、サーバ間で受け渡されるメッセージを観測することで、システムの動作状況を把握するシステム分析装置がある。ネットワーク上のメッセージに基づいてシステム分析を行うことで、各計算機で動くサービス提供機能に手を入れることなく、システムの動作状況を把握できる。例えば、多階層システムで提供されるサービスのトランザクションごとの処理時間が把握できる。
このようなシステム分析装置では、例えばネットワーク上を流れるメッセージを観測し、どのような処理がいつどこでどこから起こされたかを判断する。処理の例としてはアプリケーションの実行、データベースへのアクセスといったものがある。ここで、システム分析装置には、ある処理がどのような処理を呼び出すのかを表現するモデルを定義しておくことができる。システム分析装置は、システム観測時にはネットワーク上のメッセージから得られるイベントデータをモデルと照合することで、複数のサーバの連係した処理により提供されるサービスの各サーバの実行時間を算出できる。
なお、時系列のイベントを解析する場合には、例えば、時系列イベント記録を複数の意味集合に分解することができる。
特開２００６−１１６８３号公報 特開２００３−３０８２２９号公報
しかし、他のサーバからの呼び出しに応じて処理を実行するサーバでは、実行される処理の実行時間が短い程、モデルに適合する処理間の呼び出し関係を探索する際の分析装置の処理負荷が大きくなる。
すなわち、モデルに適合する処理間の呼び出し関係を探索する場合、例えば「ある処理から呼び出された処理の開始時刻は、呼び出し元の処理開始時刻以降で、且つ終了時刻は呼び出し元の処理終了時刻以前である。」という制約条件が用いられる。この制約条件を満たす範囲で、他の処理から呼び出されて実行された処理（呼び出し先の処理）について、その処理を呼び出した処理（呼び出し元の処理）が探索される。この場合、呼び出し先の処理の実行時間が短い程、上記制約条件を満たす呼び出し元候補の処理数が多くなる。その結果、分析装置において適切な呼び出し元の探索に要する処理時間が増加することとなる。例えば、アプリケーションサーバからデータベースサーバに出されるデータアクセスのリクエストなどは、短時間に繰り返し実行される場合が多く、モデルに適合する呼び出し関係の探索に時間がかかっていた。
本発明はこのような点に鑑みてなされたものであり、処理間の正しい呼び出し関係を効率的に判別可能な系列を生成できる系列生成プログラム、系列生成方法、および系列生成装置を提供することを目的とする。
上記課題を解決するために、以下のような処理をコンピュータに実行させる系列生成プログラムが提供される。
系列生成プログラムに基づいてコンピュータは、第１の装置と第２の装置が通信したメッセージに基づいて、第１の装置と第２の装置とのそれぞれで実行された処理を判別する。そしてコンピュータは、第１の装置で実行される処理と第２の装置で実行される処理との間で発生し得る呼び出し関係を定義したモデルを記憶する記憶手段を参照し、第１の装置で実行された処理の実行時間内に第２の装置で実行された処理の配列である呼び出し可能処理列から、第１の装置で実行された処理を呼び出し元とするモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列を含み、呼び出し先となり得ない処理を除外した系列を生成する。
また、上記課題を解決するために、上記系列生成プログラムを実行するコンピュータと同様の処理を行う系列生成方法が提供される。さらに、上記課題を解決するために、上記系列生成プログラムの実行によりコンピュータ上で実現される機能と同様の機能を有する系列生成装置が提供される。
上記系列生成プログラム、系列生成方法、および系列生成装置により、モデルに適合させることが可能な系列が生成され、処理間の正しい呼び出し関係を効率的に判別可能となる。
第１の実施の形態のシステム構成を示すブロック図である。 系列化による呼び出し関係の探索範囲の変化を示す図である。 第１の実施の形態における系列化の第１の例の前半を示す図である。 第１の実施の形態における系列化の第１の例の後半を示す図である。 第１の実施の形態における系列化の第２の例を示す図である。 本実施の形態のシステム構成例を示す図である。 本実施の形態に用いる分析装置のハードウェア構成例を示す図である。 分析装置の機能を示すブロック図である。 メッセージ記憶部内のメッセージシーケンスを示す図である。 モデル記憶部のデータ構造例を示す図である。 系列化および分析処理の手順を示すフローチャートである。 Σ・Ｃ・Ｒ更新処理の手順を示すフローチャートである。 第１の更新処理の動作定義の一例を示す図である。 第１の更新処理の動作定義に従った処理手順を示すフローチャートである。 第２の更新処理の動作定義の一例を示す図である。 第２の更新処理の動作定義に従った処理手順を示すフローチャートである。 第３の更新処理の動作定義の一例を示す図である。 第３の更新処理の動作定義に従った処理手順を示すフローチャートである。 第４の更新処理の動作定義の一例を示す図である。 第４の更新処理の動作定義に従った処理手順を示すフローチャートである。 全体適合系列対応処理の手順を示すフローチャートである。 部分適合系列対応処理の手順を示すフローチャートである。 第２の実施の形態における系列化の第１の例を示す図である。 第２の実施の形態における系列化の第２の例を示す図である。 第２の実施の形態における系列化の第３の例を示す図である。 第２の実施の形態における系列化の第４の例の前半を示す図である。 第２の実施の形態における系列化の第４の例の後半を示す図である。 第２の実施の形態における系列化の第５の例を示す図である。 第２の実施の形態における系列化の第６の例の前半を示す図である。 第２の実施の形態における系列化の第６の例の後半を示す図である。 系列記憶部のデータ構造例を示す図である。 親子候補記憶部のデータ構造例を示す図である。
以下、本実施の形態について図面を参照して説明する。
〔第１の実施の形態〕
図１は、第１の実施の形態のシステム構成を示すブロック図である。第１の実施の形態では、複数のサーバ２〜４による多階層システムで発生した処理を、系列生成装置１で分析する。多階層システムは、例えば、ウェブ３階層システムである。図１の例では、サーバ２からのリクエストメッセージに応じてサーバ３が処理を実行する。またサーバ３からのリクエストメッセージに応じてサーバ４が処理を実行する。サーバ２とサーバ３との間は、複数のセッションで接続されいずれかのセッションを介してサーバ２とサーバ３との間でメッセージが受け渡される。同様に、サーバ３とサーバ４との間は、複数のセッションで接続されいずれかのセッションを介してサーバ３とサーバ４との間でメッセージが受け渡される。
系列生成装置１は、サーバ２〜４間で受け渡されるメッセージを監視し、サーバ３，４で実行された処理を解析する。系列生成装置１は、解析した処理と予め登録されたトランザクションのモデルとを照合し、サーバ２〜４によって実行された処理の呼び出し関係を判断する。すなわち、サーバ３で実行されたどの処理が、サーバ４で実行されたどの処理を呼び出したのかを判断する。系列生成装置１は、処理とモデルとの照合の前処理として、サーバ４で実行された処理の系列化を行う。ここで、系列生成装置１の機能を説明する前に、処理の系列化について説明する。
サーバ３で実行される処理が、サーバ４に対して連続して複数回のリクエストメッセージを送信する場合がある。その場合、探索の効率化のために連続した複数個の処理をひとまとまりの処理と考え、時系列の処理を複数のまとまりに分割することができる。このように時系列の複数の処理を複数のまとまりに分割することを系列化と呼び、得られた処理のまとまり（処理列）を系列と呼ぶ。
系列化により生成された系列を１つの処理をみなして、その系列の呼び出し元となるサーバ３の処理を探索することで、判断対象となるサーバ３での処理の数が少なくなる。すなわち、生成された系列は、複数の処理の集合であり、系列全体の処理に要する時間が個々の処理より長くなる。すると、系列の処理時間を包含する処理時間を有する呼び出し元の処理は少なくなる。
図２は、系列化による呼び出し関係の探索範囲の変化を示す図である。図２の例では、サーバ３がアプリケーションサーバであり、サーバ４がデータベースサーバである場合を想定している。アプリケーションサーバでは、２つの処理２１，２２が実行されている。またデータベースサーバでは、４つの処理３１〜３４が実行されている。
図２では、呼び出し関係が存在し得る処理を矢印で示している。なお呼び出し関係が存在し得る場合とは、少なくとも「ある処理から呼び出された処理の開始時刻は、呼び出し元の処理開始時刻以降で、且つ終了時刻は呼び出し元の処理終了時刻以前である。」という制約条件を満たす場合である。
系列化前の状態では、アプリケーションサーバの処理２１から呼び出された可能性があるのはデータベースサーバの処理３１〜３３である。また、アプリケーションサーバの処理２２から呼び出された可能性があるのはデータベースサーバの処理３２〜３４である。すると、処理３２と処理３３については、アプリケーションサーバにおけるいずれの処理から呼び出されたのかを一意に特定することができない。この場合、各処理の呼び出し関係を定義したモデルと照合し、適切な呼び出し関係を判断することとなる。
ここで系列化が行われた場合、同一の処理から呼び出された可能性が高い処理列が１つの系列にまとめられる。図２の例では、処理３１〜３３が１つの系列４１にまとめられている。また処理３４は、１つの処理で１つの系列４２を構成する。
このような系列化が行われた場合、系列４１を呼び出し得るのは処理２１のみとなる。すなわち、系列化前には処理２１，２２のいずれからでも呼び出し関係が存在し得た処理３２，３３について、系列化によって処理２２との間の呼び出し関係が存在し得ないことが判明する。このように、呼び出し関係が存在し得ないことが判明した処理間については、モデルとの適合性の判別処理が不要となり、呼び出し元の処理の探索負荷が軽減されることとなる。
ここで、系列化処理としては、例えば以下のような処理が考えられる。
〔第１の手法〕処理間の時間間隔を使う方法
〔第２の手法〕系列の開始終了パターンを使う方法
第１の手法は、ある処理に関わる一連の処理では、処理間の時間が短く、一連の処理が終わって次の処理を開始するときには処理間の時間が長いことを利用したものである。この場合、適切な閾値を求め、その閾値より時間間隔が開いた処理間を系列の境界とする。そして、その境界で分離することで得られる個々の処理列を系列とする。
第２の手法は、処理の途中は分からないまでも、一連の処理の最初や最後に必ず現れる処理種別がある場合に利用される。一連の処理の最初と最後に現れるべき処理種別が出現した場合には、最初の処理種別から最後の処理種別までの処理列を１つの系列とする。
このような２つの系列化の手法のうち第１の手法は、適切な閾値の設定が困難である。例えば、閾値が大きすぎると、実際には一連の処理ではない処理までも包含した系列が生成される可能性がある。その場合、モデルとの適合性の判別において、正しい判断を行うことができなくなってしまう。逆に閾値が小さすぎると、ほとんどの処理が個別の系列となってしまい、呼び出し先のイベントを系列化することによるモデルとの照合処理の効率化の効果が薄れてしまう。
閾値については、例えば、モデル生成時の処理の時間間隔を参考に閾値を決定することができる。ただし、負荷の状況などの影響により、モデルを得たときと実際にモデルと各処理とを照合するときとで、一連の処理の前後の時間間隔が違う場合がある。このような場合には、モデル生成時の処理の時間間隔を参考に閾値を決定しても、適切な系列を生成できない。
また第２の手法は、最初や最後に必ず現れる処理種別がない場合には全く対応できない。
このように、第１・第２の手法では、適切な系列化を行うことができない場合がある。そこで、第１の実施の形態では、予め作成されている呼び出し関係のモデルと、ネットワークの監視によって得られた処理とを照合することで、適切な系列化を行う。
以下、図１の説明に戻り、モデルを用いた系列化機能について詳細に説明する。系列生成装置１は、モデル記憶手段１ａ、処理判別手段１ｂ、系列化手段１ｃ、系列記憶手段１ｄ、呼び出し候補判定手段１ｅ、および呼び出し候補記憶手段１ｆを有している。
モデル記憶手段１ａは、処理間の呼び出し関係を定義したモデル５ａ，５ｂを記憶する。例えば、モデル５ａは、処理種別「Ａ」の処理の処理から、処理種別「ａ」の処理、処理種別「ｂ」の処理、処理種別「ｃ」の処理が順に呼び出されることを示している。同様にモデル５ｂは、処理種別「Ｂ」の処理から、処理種別「ｂ」の処理、処理種別「ｃ」の処理、処理種別「ｄ」の処理が順に呼び出されることを示している。
処理判別手段１ｂは、第１の装置と第２の装置が通信したメッセージに基づいて、第１の装置と第２の装置とのそれぞれで実行された処理を判別する。図１の例では、サーバ３を第１の装置、サーバ４を第２の装置として、サーバ３，４それぞれで実行された処理が判別される。例えば、処理判別手段１ｂは、サーバ２〜４間でネットワークを介して受け渡されるメッセージを監視する。図１の例では、サーバ２とサーバ３との間に張られた複数のセッションから、４つのメッセージ８ａ，８ｂ，８ｃ，８ｄが検出されている。メッセージ８ａは、処理種別「Ａ」の処理の実行を要求するリクエストメッセージである。メッセージ８ｂは、処理種別「Ｂ」の処理の実行を要求するリクエストメッセージである。メッセージ８ｃは、処理種別「Ａ」の処理の実行終了を示すレスポンスメッセージである。メッセージ８ｄは、処理種別「Ｂ」の処理の実行終了を示すレスポンスメッセージである。これらのメッセージにより、サーバ３において、処理種別「Ａ」と処理種別「Ｂ」との２つの処理３ａ，３ｂが実行されたことが判別できる。
各処理の実行に際し、サーバ４への処理要求が発生する場合がある。その場合、サーバ３とサーバ４との間に張られた複数のセッションのいずれかを介してリクエストメッセージが送信される。処理判別手段１ｂは、すべてのセッションを監視することができる。図１には、サーバ３とサーバ４との複数のセッションのうちの１つのセッション９の監視により取得された８個のメッセージ９ａ，９ｂ，９ｃ，９ｄ，９ｅ，９ｆ，９ｇ，９ｈが例示されている。
メッセージ９ａは、処理種別「ａ」の処理の実行を要求するリクエストメッセージである。メッセージ９ｂは、処理種別「ａ」の処理の実行終了を示すレスポンスメッセージである。メッセージ９ｃは、処理種別「ｂ」の処理の実行を要求するリクエストメッセージである。メッセージ９ｄは、処理種別「ｂ」の処理の実行終了を示すレスポンスメッセージである。メッセージ９ｅは、処理種別「ｃ」の処理の実行を要求するリクエストメッセージである。メッセージ９ｆは、処理種別「ｃ」の処理の実行終了を示すレスポンスメッセージである。メッセージ９ｇは、処理種別「ｄ」の処理の実行を要求するリクエストメッセージである。メッセージ９ｈは、処理種別「ｄ」の処理の実行終了を示すレスポンスメッセージである。これらのメッセージにより、サーバ４において、処理種別「ａ」、処理種別「ｂ」、処理種別「ｃ」、および処理種別「ｄ」の４つの処理４ａ，４ｂ，４ｃ，４ｄが実行されたことが判別できる。
なお、図１に示す各メッセージは、取得時刻が早い順に下から並べられている。
系列化手段１ｃは、モデル記憶手段１ａに記憶されたモデル５ａ，５ｂを参照しながら、処理判別手段１ｂから渡されたメッセージで認識される処理列の系列化を行う。具体的には、系列化手段１ｃは、第１の装置で実行された処理の実行時間内に第２の装置で実行された処理の配列を、呼び出し可能処理列とする。そして系列化手段１ｃは、呼び出し可能処理列から、第１の装置で実行された処理を呼び出し元とするモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列を含み、呼び出し先となり得ない処理を除外した系列を生成する。図１の例では、サーバ３を第１の装置、サーバ４を第２の装置として、系列を生成している。
また、系列化手段１ｃは、複数の呼び出し元の処理から呼び出し可能な処理の配列については、複数の呼び出し元それぞれに適用される各モデルにおける呼び出し先の処理列の重複部分と一致する処理列を、系列とすることができる。例えば、系列化手段１ｃは、第１の装置で実行された第１の処理を呼び出し元とする第１のモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列を、第１の適合処理列とする。また、系列化手段１ｃは、第１の装置で実行された第２の処理を呼び出し元とする第２のモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列を、第２の適合処理列とする。系列化手段１ｃは、第１の適合処理列と第２の適合処理列とが一部重複する場合、少なくとも重複する処理列を含み、第１のモデルと第２のモデルのいずれかにおいて呼び出し先となり得ない処理を除外した系列を生成する。これにより、生成された系列は、第１のモデルと第２のモデルとのいずれに対しても適合させることができる。
以上のような構成の系列生成装置１により、処理の系列化が行われる。以下、系列化処理について、より詳細に説明する。なお以下の説明では、呼び出し元となる処理を「親」、呼び出し先となる処理を「子」と呼ぶこととする。また、呼び出し先となる処理のうち、モデルとの照合対象とする処理を「非除外要素」、照合対象としない処理を「除外要素」とする。非除外要素は、例えば、モデルにおいて呼び出し先として設定されている場合にのみ、そのモデルに適合するトランザクションにおいて呼び出される処理である。他方、除外要素は、例えば、モデルにおいて呼び出し先として設定されていなくても、そのモデルに適合するトランザクションにおいて呼び出される場合がある処理である。図１の例に示すサーバ４で実行されている処理４ａ，４ｂ，４ｃ，４ｄは、モデル５ａ，５ｂのいずれかに含まれた処理種別であり、非除外要素である。
系列化手段１ｃは、サーバ３へのリクエストメッセージを取得すると、そのリクエストメッセージに応じて実行される処理を親とし、親が適用されるモデルを参照する。例えば、メッセージ８ａを取得した場合、モデル５ａが参照される。また、メッセージ８ｂを取得した場合、モデル５ｂが参照される。
系列化手段１ｃは、親のリクエストメッセージを取得後、親から子へのメッセージの通信に使用されるセッションごとに、系列に属する処理列を登録するリストを作成する。系列化手段１ｃは、セッションごとに設けられたリストに対して、該当するセッションの監視により認識され、かつ参照しているモデルに適合する処理を系列に加えていく。その後、系列化手段１ｃは、例えば、取得した親のリクエストメッセージに対するレスポンスメッセージを検出すると、モデルに最後に適合した非除外要素より後の時点を境界として処理列を分割する。また系列化手段１ｃは、モデルに適合しない非除外要素が検出されると、モデルに最後に適合した非除外要素より後で、モデルに適合しない非除外要素より前の時点を境界として、処理列を分割することもできる。分割の境界を決定した場合、系列化手段１ｃは、境界より前の処理列を１つの系列とする。
図１の例では、メッセージ８ａ，８ｂの取得により、系列に属する処理列のリストがセッションごとに作成される。リストは、初期状態では空集合となっている。また、２つのリクエストメッセージ８ａ，８ｂの取得により、２つのモデル５ａ，５ｂが参照される。その後、セッション９を介して受け渡されたメッセージに基づいて、サーバ４で処理種別「ａ」、「ｂ」、「ｃ」、「ｄ」の各処理４ａ，４ｂ，４ｃ，４ｄが順に実行されたことが、系列化手段１ｃで認識される。この場合、処理種別「ｂ」の処理４ｂと処理種別「ｃ」の処理４ｃとについては、１つの系列にまとめてしまっても、処理種別「Ａ」の処理３ａと処理種別「Ｂ」の処理３ｂとのいずれに対しても、子となり得る。そこで系列化手段１ｃは、処理種別「ｂ」の処理４ｂと処理種別「ｃ」の処理４ｃとを１つの系列（系列β）とすることを示す系列情報６ｂを生成する。系列情報６ｂには、処理４ｂを示す処理情報と処理４ｃを示す処理情報とが含まれる。
一方、処理種別「ａ」の処理４ａについては、系列情報６ｂに示される系列と同一系列にした場合、モデル５ｂに適合しなくなる。すると、処理４ａ，４ｂ，４ｃを同一系列にすると、その系列は、処理種別「Ａ」の処理３ａの子とはなり得るが、処理種別「Ｂ」の処理３ｂの子とはなり得なくなる。すなわち、処理４ｂ，４ｃまでも、処理３ｂの子となり得なくなってしまう。そこで、系列化手段１ｃは、処理種別「ａ」の処理４ａと処理種別「ｂ」の処理４ｂとの間を境界として処理列を分割し、処理種別「ａ」の処理４ａを１つの系列（系列α）とする系列情報６ａを生成する。系列情報６ａには、処理４ａを示す処理情報が含まれる。
処理種別「ｄ」の処理４ｄについては、系列情報６ｂに示される系列と同一系列にした場合、モデル５ａに適合しなくなる。すると、処理４ｂ，４ｃ，４ｄを同一系列にすると、その系列は、処理種別「Ｂ」の処理３ｂの子とはなり得るが、処理種別「Ａ」の処理３ａの子とはなり得なくなる。すなわち、処理４ｂ，４ｃまでも、処理３ａの子となり得なくなってしまう。そこで、系列化手段１ｃは、処理種別「ｃ」の処理４ｃと処理種別「ｄ」の処理４ｄとの間を境界として処理列を分割し、処理種別「ｄ」の処理４ｄを１つの系列（系列γ）とする系列情報６ｃを生成する。系列情報６ｃには、処理４ｄを示す処理情報が含まれる。
なお、図１にはセッション９を介して通信されるメッセージに基づいて実行される処理の系列化の例を示しているが、サーバ３とサーバ４との間の他のセッションを介して通信されるメッセージに基づいて実行される処理についても、系列化が行われる。
呼び出し候補判定手段１ｅは、系列化手段１ｃで生成された系列情報６ａ，６ｂ，６ｃに基づいて、呼び出し関係が存在する可能性がある呼び出し元処理と系列との関係を示す呼び出し候補情報を生成する。呼び出し関係が存在する可能性は、モデル記憶手段１ａに格納されたモデル５ａ，５ｂに基づいて判断される。すなわち、呼び出し元の処理に適用されるモデルにおいて、系列情報で示される系列の呼び出しが存在すれば、当該呼び出し元の処理と当該系列との呼び出し関係が存在する可能性がある。
例えば、処理種別「Ａ」の処理３ａからは、系列情報６ａ，６ｂで示される系列（「系列α」、「系列β」）を呼び出している可能性がある。そこで、呼び出し候補判定手段１ｅは、処理種別「Ａ」の処理３ａと系列情報６ａ，６ｂそれぞれとの関係を呼び出し候補とする呼び出し候補情報７ａを生成する。同様に、呼び出し候補判定手段１ｅは、処理種別「Ｂ」の処理３ｂと系列情報６ｂ，６ｃそれぞれとの関係を呼び出し候補（親子候補）とする呼び出し候補情報７ｂを生成する。生成された呼び出し候補情報７ａ，７ｂは、呼び出し候補記憶手段１ｆに格納される。
このように、第１の実施の形態では、呼び出し可能処理列が系列化される。生成された系列に含まれる処理は、同じ処理から呼び出されるものとすることで、各系列を呼び出し可能な呼び出し元の処理が絞り込まれる。すなわち、系列化したことにより、系列の最初の処理の開始時刻よりも先に開始され、系列の最後の処理の終了時刻よりも後に終了する処理のみが、系列を呼び出し可能となる。その結果、呼び出し元の選択肢が減り、正しい呼び出し関係（現実にサーバ２とサーバ３間で行われた処理の呼び出し）の解析負荷が軽減される。
しかも、第１の実施の形態では、モデル５ａ，５ｂを参照しながら系列化が行われ、参照対象のモデルに含まれる処理列となるか否かで系列の境界を決定される。その結果、余分な処理が系列に含まれずにすむ。すなわち、モデルの呼び出し先として定義されている系列から逸脱しない範囲での系列が生成される。モデルの系列から逸脱しないことで、モデル全体と一致する処理の組み合わせを検出する際に、各系列をモデルに適合する呼び出し先候補として取り扱うことができる。これにより、系列化を行ったことによる処理の呼び出し関係の分析精度の低下が抑止される。
また、系列化と同時に呼び出し関係の候補の列挙が可能である。呼び出し関係の候補を列挙しておけば、各サーバ２〜４で実行された処理とモデル全体とを照合する際に、サーバ３とサーバ４との間の呼び出し関係については、呼び出し関係の候補の中から、モデル全体に合致する呼び出し関係の組み合わせを見つけ出せばよい。すなわち、モデル全体との照合の処理負荷が軽減される。
例えばモデルで呼び出し先とされる非除外要素のリストが［ａ，ｂ，ｃ］となっている場合を考える。括弧内の英文字は呼び出し先となる非除外要素の処理種別であり、左の非除外要素から順に呼び出されることを示している。この場合、ネットワークから取得したメッセージに基づいて、非除外要素のリストが［ａ，ｂ，ｃ，ａ］となる系列を作ってしまうと、モデル全体に合致しなくなってしまう。ただし、［ａ，ｂ］のようにモデルの呼び出し先のリストより短い場合には、［ｃ］という系列と組み合わせれば、モデルと照合するときに［ａ，ｂ］と［ｃ］とを並べてモデル全体に合致させることが可能である。従って、［ａ，ｂ，ｃ，ａ］のようにモデルに出現する系列に余分な要素がついてしまうのは不適切である。モデル全体と照合するときに、この系列化された非除外要素のリストを分割することも可能ではあるが、計算量の削減という系列化の目的を阻害してしまう。また、系列化でなるべく短めの系列を作るとすると、モデルとの照合時の問題は解消するものの、計算量の削減に貢献できない。従って、モデルに適合させることが可能な形で、できるだけ長い系列を作成するのが適切である。
第１の実施の形態では、モデルを参照し、各モデルに部分的に合致する範囲で、１つの系列に、連続する処理列が含められる。これにより、モデル全体に合致する呼び出し関係を探索する際の処理量を軽減できる。また、モデルに合致しない処理列を包含する系列を作成しないようにすることにより、モデルとの照合時に、正確な呼び出し関係の探索が可能となる。
ところで、図１に示した例では、系列化処理を分かりやすくするため、サーバ４で実行された処理のうち非除外要素のみを示している。しかし、非除外要素の間に、１以上の除外要素が挟まることがある。系列化のために複数の系列に分割する場合、系列の境界は、非除外要素を基準に判断される。その際、非除外要素の前後に１以上の除外要素があれば、処理列を分割する際の境界として選択可能な位置が、複数存在することとなる。そこで系列化手段１ｃは、所定の基準に基づいて、境界となる位置を決定する。以下、非除外要素と除外要素とが混在する場合を想定し、処理列の系列化の例について説明する。
まず、系列化の第１の例について、図３、図４を参照して説明する。
図３は、第１の実施の形態における系列化の第１の例の前半を示す図である。図３の例では、サーバ３の処理からサーバ４の処理を呼び出す場合の呼び出し関係のモデルとして、処理種別「Ｉ１」の処理に適用するモデル５１と、処理種別「Ｉ２」の処理に適用するモデル５２とが予め定義されているものとする。処理種別「Ｉ１」の処理に適用するモデル５１には、処理種別「Ｒ１」の処理を呼び出すことが定義されている。また処理種別「Ｉ２」の処理に適用するモデル５２には、処理種別「Ｒ１」と「Ｒ２」との処理を順に呼び出すことが定義されている。
なお各モデル５１，５２では、モデルに定義されていない除外要素の呼び出しが行われることを許容している。他方、各モデル５１，５２では、モデルに定義されていない非除外要素の呼び出しが行われることを許容しない。
図３には、各処理の実行時間を線で示している。線の左端が処理の開始時刻を示し、右端が終了時刻を示す。処理を示す線の上側左端には、その処理の処理種別が示されている。処理種別「φ」は、除外要素であることを示している。レスポンスメッセージが検出された処理については、その処理を示す線の上側右端に「ｒｅｓ」と表記されている。また、横方向に並べられた処理は、同一セッションでメッセージの通信が行われた処理である。
〔第１の状態〕まずサーバ３において、処理種別「Ｉ１」の処理６１と処理種別「Ｉ２」の処理６２との実行が開始されている。すると、系列化手段１ｃにより、モデル５１，５２とその後のサーバ４で実行される処理との比較が開始される。
〔第２の状態〕サーバ４において、除外要素「φ」の処理７１が実行されている。処理７１は除外要素であるため、サーバ３で実行されている処理６１，６２のいずれからの呼び出しであっても、モデル５１，５２に適合する。そこで、系列化手段１ｃは、処理７１に対して、処理６１，６２を親候補として仮設定する。
〔第３の状態〕サーバ４において、処理７１に続けて、順に処理種別「Ｒ１」の処理７２、除外要素の処理７３、処理種別「Ｒ２」の処理７４が実行されている。処理種別「Ｒ１」は、モデル５１，５２の双方において最初の呼び出し先の処理の処理種別として定義されている。また、処理７３は除外要素である。そのため、処理７１、処理７２、処理７３の処理列はモデル５１，５２に適合する。他方、処理７４は処理種別「Ｒ２」であり、処理７１、処理７２、処理７３、処理７４の処理列はモデル５１に適合しない。すなわち、処理７４は、処理６１の子になり得ない。そこで、系列化手段１ｃは、処理列を分割する。
図４は、第１の実施の形態における系列化の第１の例の後半を示す図である。
〔第４の状態〕系列化手段１ｃは処理列を分割し、モデル５１に適合しない処理７４を含まない処理列を１つの系列８１とする。系列化手段１ｃは、モデル５１，５２に適合すると判定された非除外要素（処理７２）については、系列８１に含める。そのため系列化手段１ｃは、処理７２と処理７４との間のいずれかの箇所を境界として処理列を分割する。なお、境界は、処理７１〜７４が実行されていない箇所に設定される。
図４の例では、処理７２と処理７３との間、または処理７３と処理７４との間のいずれかを境界とすることができる。境界の決定については、例えば処理間の時間間隔が最大の箇所を境界とする。図４の例では、処理７３と処理７４との間が境界に決定され、処理列が分割されている。そして、分割された処理列のうち境界より前に位置する処理列がまとめられ、１つの系列８１が生成されている。
生成された系列８１は、モデル５１に適合している。そこで呼び出し候補判定手段１ｅは、モデル５１が適用される処理６１と系列８１との間の関係を、親子候補として設定する。
〔第５の状態〕サーバ４では、処理７４に続けて除外要素の処理７５が実行され、その後、サーバ３において処理６１，６２が終了している。
〔第６の状態〕処理６２が終了したことで、系列化手段１ｃにより、処理７４と処理７５との処理列がまとめられ系列８２が生成される。この場合、系列８１と系列８２との組み合わせは、処理６２に適用されるモデル５２に適合している。そこで呼び出し候補判定手段１ｅは、系列８１と処理６２との間の関係、および系列８２と処理６２との間の関係を親子候補として設定する。
このようにして、処理７１〜７５の系列化と、系列化により生成された系列８１，８２を用いた親子候補の設定が完了する。
次に、系列化の第２の例について、図５を参照して説明する。第２の例は、参照されているモデルに現れない非除外要素が検出された場合の系列化である。
図５は、第１の実施の形態における系列化の第２の例を示す図である。図５の例では、図３、図４と同様のモデル５１，５２が定義されているもとする。図５の第１の状態、第２の状態については、図３に示した第１の状態、第２の状態と同じである。
〔第３の状態〕サーバ４において、処理７１に続けて、順に処理種別「Ｒ１］の処理７２、除外要素の処理７３、処理種別「Ｒ３」の処理７６が実行されている。処理種別「Ｒ１」は、モデル５１，５２の双方において最初の呼び出し先の処理の処理種別として定義されている。また、処理７３は除外要素である。そのため、処理７１、処理７２、処理７３の処理列はモデル５１，５２に適合する。他方、処理７６は処理種別「Ｒ３」であり、処理７１、処理７２、処理７３、処理７６の処理列はモデル５１，５２に適合しない。すなわち、処理７６は、処理６１，６２のいずれの子ともなり得ない。そこで、系列化手段１ｃは、処理列を分割する。
〔第４の状態〕系列化手段１ｃは処理列を分割し、モデル５１，５２に適合しない処理７６を含まない処理列を１つの系列８３とする。系列化手段１ｃは、モデル５１，５２に適合すると判定された非除外要素（処理７２）については、系列８３に含める。そのため系列化手段１ｃは、処理７２と処理７６との間のいずれかの箇所を境界として処理列を分割する。境界の決定については、例えば処理間の時間間隔が最大の箇所を境界とする。図５の例では、処理７３と処理７６との間が境界に決定され、処理列が分割されている。そして、分割された処理列のうち境界より前に位置する処理列がまとめられ、１つの系列８３が生成されている。
生成された系列８３は、モデル５１に適合している。そこで呼び出し候補判定手段１ｅは、モデル５１が適用される処理６１と系列８３との間の関係を、親子候補として設定する。
このようにして、参照しているモデル５１，５２に合致しない非除外要素を検出した場合においても、適切な系列化を行うことができる。
ところで、図３〜図５に示した系列化の例では、処理７１以前にサーバ４で実行された処理がないため、系列８１，８３内の処理列は、処理７１が先頭となっている。処理７１より前にも除外要素となる複数の除外要素が存在する場合もある。この場合、系列化手段１ｃは、例えば、モデル５１，５２に適合する処理７２より前にある処理Ｉ１または処理Ｉ２から呼び出し可能な複数の除外要素から処理７２までの間で、処理間の時間間隔が最大の箇所を境界とする。そして系列化手段１ｃは、境界となる位置の次にある処理を先頭とする系列を作成する。
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、ウェブ３階層システムにおけるトランザクションの解析において、処理の系列化を行うものである。なお以下の説明では、各サーバで実行される処理単位をイベントと呼ぶこととする。
図６は、本実施の形態のシステム構成例を示す図である。図６に示すように、ネットワーク２１０には複数のクライアント２２１〜２２３が接続されている。また、ネットワーク２１０にはルータ２３１が接続されている。図中、ルータ２３１およびルータ２３１より右側の各装置によって、サービス提供側のネットワークシステムが構成されている。サービス提供側のネットワークシステムは、Ｗｅｂサーバ２４１、アプリケーションサーバ２４２、およびデータベース（ＤＢ）サーバ２４４による３階層構造となっている。
ルータ２３１にはスイッチ２３２を介してＷｅｂサーバ２４１が接続されている。Ｗｅｂサーバ２４１は、クライアント２２１〜２２３に対してＷＷＷ（World Wide Web ）による情報提供を行う。Ｗｅｂサーバ２４１には、スイッチ２３３を介してアプリケーションサーバ２４２が接続されている。アプリケーションサーバ２４２は、Ｗｅｂサーバ２４１からの要求に応じてデータ処理を実行する。アプリケーションサーバ２４２には、スイッチ２３４を介してＤＢサーバ２４４が接続されている。ＤＢサーバ２４４は、アプリケーションサーバ２４２からの要求に応じてデータベースへのデータの入出力を行う。
なお第２の実施の形態では、アプリケーションサーバ２４２とＤＢサーバ２４４との間には、複数のセッションが予め設定されているものとする。アプリケーションサーバ２４２がＤＢサーバ２４４に処理を要求する場合、いずれかのセッションを介してリクエストメッセージが送信される。また、第２の実施の形態に示す例では、アプリケーションサーバ２４２が実行する１つのイベントから複数回のＤＢアクセスが発生するとき、そのイベントはＤＢアクセスが完了するまで、１つのセッションを占有する。すなわち、アプリケーションサーバ２４２で実行される１つのイベントに基づいて送信される複数のリクエストメッセージは、１つのセッション上で連続して送信される。
各スイッチ２３２〜２３４は、ポートモニタリング機能を有している。ポートモニタリング機能とは、スイッチ２３２〜２３４のポートを介して送受信されるパケットのコピーを、予め指定したポートへ送出する機能である。各スイッチ２３２〜２３４のコピーされたパケットを送出するポートには、スイッチ２３５を介して分析装置１００が接続されている。
分析装置１００は、サービス提供側のネットワーク内で送受信されるパケットの内容を解析し、複数のサーバで処理されるトランザクションを検出する。そして、分析装置１００は、検出したトランザクションを実行するのに各サーバが要した時間を分析する。
図７は、本実施の形態に用いる分析装置のハードウェア構成例を示す図である。分析装置１００は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０８を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ１０６、および通信インタフェース１０７が接続されている。
ＲＡＭ１０２は、分析装置１００の主記憶装置として使用される。ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。
ＨＤＤ１０３は、内蔵したディスクに対して磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、分析装置１００の二次記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、二次記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。
グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。モニタ１１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。
入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号をＣＰＵ１０１に送信する。なお、マウス１３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
光学ドライブ１０６は、レーザ光などを利用して、光ディスク１４に記録されたデータの読み取りを行う。光ディスク１４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク１４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
通信インタフェース１０７は、スイッチ２３５に接続されている。通信インタフェース１０７は、スイッチ２３５を介して、ルータ２３１、Ｗｅｂサーバ２４１、アプリケーションサーバ２４２、およびＤＢサーバ２４４間で送受信されるパケットを取得（キャプチャ）する。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図７では分析装置１００のハードウェア構成を示したが、クライアント２２１〜２２３、Ｗｅｂサーバ２４１、アプリケーションサーバ２４２、ＤＢサーバ２４４も同様のハードウェア構成で実現することができる。
図８は、分析装置の機能を示すブロック図である。分析装置１００は、ネットワーク監視部１１０、メッセージ記憶部１２０、モデル生成部１３０、モデル記憶部１４０、系列化部１５０、系列記憶部１６０、親子候補設定部１７０、親子候補記憶部１８０および分析部１９０を有している。
ネットワーク監視部１１０は、スイッチ２３５を介してパケットを取得し、そのパケットに基づいて各サーバ間で通信されたメッセージを解析する。例えばネットワーク監視部１１０は、取得したパケットの内容を解析し、１つ以上のパケットで構成されるメッセージを検出する。そして、ネットワーク監視部１１０は、検出したメッセージを示すメッセージデータをメッセージ記憶部１２０に格納する。
メッセージ記憶部１２０は、メッセージデータを記憶する。例えば、ＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部がメッセージ記憶部１２０として使用される。
モデル生成部１３０は、メッセージ記憶部１２０に格納されたメッセージに基づいて、ウェブ３階層システムで実行されるトランザクションのモデルを作成する。この際、モデル生成部１３０は、ＤＢサーバ２４４で実行されるイベントを、除外要素と非除外要素とに分ける。例えば、アプリケーションサーバ２４２で実行されるいずれかの種別のイベントから常に呼び出し対象とされる種別のＤＢサーバ２４４のイベントは、非除外要素とされる。他方、アプリケーションサーバ２４２で実行されるいずれの種別のイベントからも、任意に呼び出される種別のイベント（呼び出されない場合もある種別のイベント）については、除外要素とされる。モデル生成部１３０は、ＤＢサーバ２４４のイベントについては、非除外要素のみをモデルの構成要素とする。
モデル生成部１３０でモデルを生成する場合、例えば、システムの運用を一時的に停止可能であれば、運用停止期間中にテスト用のトランザクションをシステムで実行させる。その際に取得されたメッセージからモデル生成部１３０がトランザクションのモデルを生成することで、実行させたトランザクションに対する正確なモデルを生成できる。また、システム運用中に取得したメッセージに基づいてモデルを生成する場合、例えば、モデル生成部１３０は、Ｗｅｂサーバ２４１で実行される複数のイベントのうち、他のイベントと時間的に重複しない期間に実行されたイベントを抽出する。そして、モデル生成部１３０は、抽出したＷｅｂサーバ２４１のイベントと、そのイベントの実行期間中に発生したアプリケーションサーバ２４２やＤＢサーバ２４４のイベントに関するメッセージを取得する。これにより、抽出したＷｅｂサーバ２４１のイベントを呼び出し元とするアプリケーションサーバ２４２のイベント、およびそのアプリケーションサーバ２４２のイベントを呼び出し元とするＤＢサーバ２４４のイベントが明確となる。そこで、モデル生成部１３０は、取得したメッセージに基づくイベント間の呼び出し関係によりモデルを作成する。生成されたモデルは、イベント間の呼び出し関係が木構造で表される。
ところで、１つのトランザクションにおいて、ＤＢサーバ２４４で呼び出されるイベント数が非常に多いことがある。そのため取得したメッセージから判別したイベントがモデルに適合するどうかを、１つ１つのモデルと照合すると非常に時間がかかる。また、銀行口座の入出金照会のように個人や期間によって個数が違ったりアクセスがあったりなかったりするトランザクションがある。このようなＤＢサーバ２４４へのアクセス回数が異なるトランザクションであっても、アプリケーションサーバ２４２が受け付けたリクエストは同種の処理の場合がある。このようなアプリケーションサーバ２４２が受け付けた同種のリクエストに基づいて実行された複数のトランザクションは、モデルを用いたトランザクションの解析においても同一視することが可能である。そこで、モデル生成部１３０は、あるイベントについては個数が違うだけのトランザクションを同一視することを可能としたモデルを生成する。例えば、モデル生成部１３０は、同種のトランザクションを同一視することを可能なモデルを作成するため、連続した複数個のイベントを一連の処理と捉え、イベント列を分割する。そしてモデル生成部１３０は、その代表となるイベント（１個または複数個）をモデル生成に使用する。代表となるイベントとしては、同種のトランザクションにおいて共通に呼び出されているイベントである。ここで、イベント列を分割してできる個々のイベントリストが系列であり、この分割する処理が系列化である。
このようにして、同種の複数のトランザクションそれぞれのモデルを作成した場合にいずれのモデルにも含まれる共通のイベント間の呼び出し関係を定義したモデルが生成される。同種のトランザクションそれぞれのモデルの共通部分のみを残したモデルでは、そのモデルに定義されているすべてのイベントが呼び出されていることが、そのモデルに適合するトランザクションの条件となる。モデルに定義されていないイベントについては、基本的には存在しても存在しなくてもよい。ただし、第２の実施の形態においては、特定のトランザクションに固有のイベントは、他のトランザクションに含まれることはないものとする。そこで、本実施の形態では、いずれかのモデルに含まれるイベントを非除外要素とし、いずれのモデルにも含まれないイベントを除外要素として区別される。そして取得したメッセージから認識されたイベントとモデルとを照合する場合、モデルに含まれない非除外要素を含むトランザクションは、そのモデルに適合しないものとする。この場合、除外要素については、あってもなくてもよい。
モデル生成部１３０はモデルを生成すると、そのモデルをモデル記憶部１４０に格納する。
モデル記憶部１４０は、トランザクションに含まれるメッセージの組み合わせを示すモデルを記憶する。例えば、ＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部がモデル記憶部１４０として使用される。なおモデルは、クライアントから出力される要求の種別ごとに設けられる。
系列化部１５０は、ネットワーク監視部１１０が取得したメッセージからイベントの開始と終了とを認識し、１つのセッションで発生したイベントの系列化を行う。本実施の形態では、ＤＢサーバ２４４で実行されたイベントについての系列化を行うものとする。系列化を行う場合、系列化部１５０は、モデル記憶部１４０に格納されたモデルと系列とを随時照合し、モデルに定義されているＤＢサーバ２４４の系列の少なくとも一部に適合する範囲内で、イベントを系列化する。系列化部１５０は、生成した系列を示す系列情報を系列記憶部１６０に格納する。系列情報には、系列に含まれるイベントの識別情報の列が含まれる。
系列記憶部１６０は、系列情報を記憶する。例えば、ＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部が系列記憶部１６０として使用される。
親子候補設定部１７０は、系列化部１５０で生成された系列に基づいて、呼び出し関係の親子候補を設定する。親子候補とは、呼び出し元のイベントを親とし、呼び出し先のイベントを子としたとき、親子関係になる可能性のあるイベント間の関係を示す情報である。親子候補設定部１７０は、設定した親子候補を示す親子候補情報を、親子候補記憶部１８０に格納する。親子候補情報には、親となるイベントの識別情報と子となるイベントの識別情報とが含まれる。
親子候補記憶部１８０は、親子候補情報を記憶する。例えば、ＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部が親子候補記憶部１８０として使用される。
分析部１９０は、モデル記憶部１４０に格納されたモデルと、メッセージ記憶部１２０に格納されたメッセージとを照合し、モデル全体に適合するトランザクションを検出する。トランザクションは、モデル全体に適合する呼出関係を有する複数のイベントで表される。その際、分析部１９０は、系列記憶部１６０を参照し、系列内のイベントについては、同一のイベントから呼び出された一連の処理として認識し、系列全体を含むトランザクションを検出する。このように、系列を用いてメッセージとモデルとの照合を行うことで、呼び出し可能なイベントの組み合わせが少なくなり、メッセージとモデルとの照合処理の効率化が図れる。
また、分析部１９０は親子候補記憶部１８０を参照し、系列の親となるイベントを探索する際には、親子候補の親として設定された関係のみを調査する。このように、予め設定された親子候補を使って呼び出し関係の探索を行うことで、メッセージとモデルとの照合処理の効率化が図れる。
また、分析部１９０は、照合によって認識された各トランザクションに基づいて、種別ごとのトランザクションの処理に要する処理時間を分析することもできる。処理時間は、例えば、サーバごとに計算できる。分析部１９０は、処理時間の分析結果をグラフなどでモニタ１１に表示することもできる。
図９は、メッセージ記憶部内のメッセージシーケンスを示す図である。メッセージ記憶部１２０には、キャプチャされたパケットから生成された複数のメッセージデータが時系列で格納されている。
メッセージデータの先頭は時刻を示すタイムスタンプである。なお、タイムスタンプは、ネットワーク監視部１１０が、パケットを取得したときに取得したパケットに付与している。そして、ネットワーク監視部１１０は、メッセージデータの生成元となったパケットに付与されていたタイムスタンプを、生成されたメッセージデータに付与して、メッセージ記憶部１２０に格納する。
メッセージデータ内のタイムスタンプの後には、セッション番号とリクエスト番号との組が付与される。タイムスタンプの後の括弧内の値のうち、左側がセッション番号、右側がリクエスト番号である。セッション番号は、通信に使用したセッションのｉｄである。リクエスト番号は、セッションを介して送信されたリクエストメッセージのｉｄである。セッション番号とリクエスト番号との組は、リクエストメッセージとレスポンスメッセージとに対して同じ値が設定される。同じセッション番号の２つのメッセージデータのうち、タイムスタンプの時刻が早い方がリクエストメッセージを示している。また、タイムスタンプの時刻が遅い方がレスポンスメッセージを示している。
メッセージデータ内のセッション番号の後には、プロトコル名が設定されている。図９の例では、プロトコル名として「ＨＴＴＰ」、「ＩＩＯＰ」、「ＲＤＢ２」といった値が設定されている。プロトコル名によって、どのサーバが実行したイベントに関するメッセージなのかが判別できる。「ＨＴＴＰ」は、Ｗｅｂサーバ２４１で実行されたイベントに関するメッセージである。「ＩＩＯＰ」は、アプリケーションサーバ２４２で実行されたイベントに関するメッセージである。「ＲＤＢ２」は、ＤＢサーバ２４４で実行されたイベントに関するメッセージである。
メッセージデータ内のプロトコル名の後には、メッセージの内容が設定されている。例えば、リクエストメッセージの内容の一部を、そのリクエストメッセージの名前とすることができる。またリクエストメッセージの名前を、そのリクエストメッセージに応じて実行されるイベントの種別としてもよい。
このようなメッセージデータに基づいて、各サーバで実行されたイベント９１〜９９が認識される。イベントを認識する場合、まずメッセージデータの中から、イベントの開始を示すリクエストメッセージが検索される。次に、リクエストメッセージと同じセッション番号のレスポンスメッセージが検索される。セッション番号が共通のリクエストメッセージとレスポンスメッセージとにより、１つのイベントの開始時刻と終了時刻が表される。
図９に示したようなメッセージシーケンスに基づいて、モデル生成部１３０によりモデルが生成される。生成されたモデルは、モデル記憶部１４０に格納される。
図１０は、モデル記憶部のデータ構造例を示す図である。モデル記憶部１４０には、複数のモデル１４１，１４２，１４３，・・・が格納されている。モデル１４１，１４２，１４３，・・・は、呼び出し関係を表す木構造である。
図１０の例では、Ｗｅｂサーバ２４１で実行されるイベントは「Ｈ」の記号と数字とで示されている。アプリケーションサーバ２４２で実行されるイベントは「Ｉ」の記号と数字とで示されている。ＤＢサーバ２４４で実行されるイベントは「Ｒ」の記号と数字とで示されている。それぞれのイベントに付与された数字は、プロトコルごとのイベントを識別するための識別番号である。
モデル１４１，１４２，１４３，・・・では、呼び出し元のイベントを上に記載し、呼び出し先のイベントを下に記載している。最下位層のイベント列については、系列として認識される。例えばモデル１４１には、Ｗｅｂサーバ２４１で実行されるイベント「Ｈ１」からアプリケーションサーバ２４２で実行されるイベント「Ｉ１」が呼び出されることが示されている。また、モデル１４１には、アプリケーションサーバ２４２で実行されるイベント「Ｉ１」からＤＢサーバ２４４で実行されるイベント「Ｒ１，Ｒ２，Ｒ３」が呼び出されることが示されている。イベント「Ｒ１，Ｒ２，Ｒ３」は、最下位層のイベントであり、系列として認識される。系列の場合、一連の動作の中で全体に共通する動作のみが識別子で定義されているものと解釈される。従って、モデル１４１には、複数のインスタンス１４１ａ，１４１ｂ，１４１ｃ，・・・が適合する。例えば、インスタンス１４１ａには、アプリケーションサーバ２４２で実行されるイベント「Ｉ１」からＤＢサーバ２４４で実行されるイベント「Ｒ１，Ｒ２，Ｒ４，Ｒ４，Ｒ３」が呼び出されることが示されている。また、インスタンス１４１ｂには、アプリケーションサーバ２４２で実行されるイベント「Ｉ１」からＤＢサーバ２４４で実行されるイベント「Ｒ１，Ｒ２，Ｒ４，Ｒ４，Ｒ４，Ｒ３」が呼び出されることが示されている。
なお、図１０の例では、「Ｒ１」、「Ｒ２」、「Ｒ３」の各イベントは非除外要素である。また「Ｒ４」、「Ｒ５」、「Ｒ６」の各イベントは除外要素である。
このようにモデルが準備され分析装置１００にメッセージ分析の指示が入力されると、所定期間内のメッセージがネットワーク監視部１１０により取得されメッセージ記憶部１２０に格納される。この際、ネットワーク監視部１１０が取得したメッセージは、順次、系列化部１５０に渡される。すると、系列化部１５０によりイベントの系列化が行われると共に、親子候補設定部１７０による親子候補の設定が行われる。そして、所定期間内のメッセージの取得が完了すると、分析部１９０によるメッセージとモデルとのマッチングが行われ、所定期間内に発生したトランザクションの種別、および処理時間が解析される。
次に、系列化部１５０による系列化処理と親子候補設定部１７０による親子候補設定処理について説明する。なお、本実施の形態では、ＤＢサーバ２４４が実行しているイベントの系列化を行う。そのため、系列化部１５０は、ネットワーク監視部１１０から取得したメッセージのうち、アプリケーションサーバ２４２で実行されたイベントに関するメッセージと、ＤＢサーバ２４４で実行されたイベントに関するメッセージとについてのみ解析する。アプリケーションサーバ２４２で実行されたイベントは、親となるイベントと認識される。ＤＢサーバ２４４で実行されたイベントは、子となるイベントと認識される。Ｗｅｂサーバ２４１で実行したイベントに関するメッセージについては、系列化の処理には使用されない。また、系列化部１５０は、モデル記憶部１４０内のモデルの構造うち、アプリケーションサーバ２４２で実行されたイベントからＤＢサーバ２４４で実行されるイベントへの呼び出し関係のみを参照する。
系列化部１５０と親子候補設定部１７０とは、親となるイベントに関するメッセージを取得した場合、以下のような処理を実行する。
系列化部１５０は、親となるイベントのリクエストメッセージを取得したとき、それ以降の各セッションのデータの観測を開始する。また、系列化部１５０は、親となるイベントのレスポンスメッセージが届いたとき、モデルに合う形の系列がみつかっていれば、それを子候補に登録する。親子候補設定部１７０は、互いに、親候補、子候補として相手の設定し合う関係になったイベント間を、親子候補に設定する。
系列化部１５０と親子候補設定部１７０とは、子となるイベントに関するメッセージを取得した場合、以下のような処理を実行する。
系列化部１５０は、系列化する新たなリクエストメッセージ、レスポンスメッセージを取得すると、取得したメッセージで示されるイベントを最新の系列に追加したときに、親となるイベントに適用するモデルに適合するか否かを判断する。親となるイベントに適用するモデルに適合している場合、系列化部１５０は、取得したメッセージに示されるイベントを系列に加える。親となるイベントに適用するモデルにあわない系列となる場合、系列化部１５０は系列の分割を検討する。系列化部１５０は、系列の分割の検討において、他のイベントを親としたモデルとの照合により、既に適切な境界で系列が分割されていれば、それ以上の系列の分割は行われない。この場合、親子候補設定部１７０は、既に得られている系列との間で親子候補の設定を行う。系列化部１５０は、系列の分割の検討において、適切な境界での系列の分割が行われていない場合、境界として設定可能な箇所のうち、時間間隔が最大の箇所を選択する。そして、系列化部１５０は、選択した箇所を境界として系列を分割する。親子候補設定部１７０は、分割により得られた系列との間で親子候補の設定を行う。
次に、このような系列生成処理および親子候補設定処理について、数学や情報科学における論理や集合の概念を用いて詳細に説明する。以下の説明では、各サーバで実行された個々のイベントを示すデータ、およびイベントの種別を示すデータを、集合を構成する要素とする。
〔事象種類〕
系列化部１５０による解析対象となる事象は以下の通りである。
・系列の呼び出し元（親のイベント）のリクエストメッセージの取得
・系列の呼び出し元のレスポンスメッセージの取得
・系列要素（子のイベント）のリクエストメッセージの取得
・系列要素のレスポンスメッセージの取得
〔要素判別関数〕
系列化部１５０には、系列化するプロトコルに関するイベントを示す要素が、除外要素か非除外要素かを示す関数Ｋが予め定義されている。関数Ｋは、以下のように表される。
Ｋ：｛ｄx，…｝→｛Ｉ，Ｏ｝
ｄxは、実行されたイベントの種別を示す要素である。イベントの種別は、イベントの名前（ラベル）によって表される。例えば図９に示したリクエストメッセージの内容の文字列に対応する名前を予め定義しておき、その名前を、リクエストメッセージで実行されるイベントの種別を示す要素として用いることができる。関数Ｋでは、イベントの種別を示す要素が入力されると、その要素で示されるイベントが除外要素か非除外要素かを示す情報を出力する。除外要素であれば関数Ｋの処理結果として「Ｉ」が出力され、非除外要素であれば関数Ｋの処理結果として「Ｏ」が出力される。系列化部１５０は、系列要素のリクエストメッセージを取得するごとに、そのリクエストメッセージの内容を引数として関数Ｋを実行し、処理結果を取得する。これにより、取得したリクエストメッセージにより実行されるイベントが、除外要素か非除外要素かを判別できる。
なお、関数Ｋに代えて、イベントの種別を示す各要素と、除外要素か非除外要素かを示す情報との対応関係が登録されたテーブルを用いることもできる。その場合、テーブルは、ＲＡＭ１０２やＨＤＤ１０３に予め格納される。テーブルを用いる場合、系列化部１５０は、関数Ｋの呼び出しに代えてテーブルを参照し、発生したイベントが除外要素か非除外要素かを判断する。
〔モデル構造〕
系列化部１５０は、モデル記憶部１４０内のモデルを参照し、系列化のためのモデルを生成する。生成されたモデルは、系列化部１５０が管理するＲＡＭ１０２内の記憶領域などに格納される。系列化部１５０で生成されるモデルは、呼び出し元と系列との組み合わせである。データ構造は、以下の通りである。
＜呼び出し元データ，系列データ＞
呼び出し元データとは、呼び出し元のイベントの種別を示すデータである。系列データは、系列に含まれる呼び出し先のイベントの種別を示すデータを、呼び出し順に並べたデータ列である。このように、系列化部１５０では、元のモデルの木構造全体でなく、親が非系列、子が系列の部分のみ取り出した部分構造を、照合対象のモデルとする。
また系列化部１５０は、系列化処理時の中間データとして、各セッションのイベント列のうち、モデルに合致する範囲を示す適合系列情報と、各セッション中のイベント列を系列に分割したときの境界を示す系列分割情報とが用いられる。
〔適合系列情報〕
適合系列情報は、各セッションについて、系列の呼び出し元データについてモデルにあっているか、またあっているならどこまであっているかを表現する状態集合である。適合系列情報（Σ）は以下の式で表される。
Figure 0005482243
各変数は以下を意味する。
・ｓｅｓｓｉｏｎｉｄ：セッションのｉｄ
・ｄ：親となり得る要素
・ｍｏｄｅｌｉｄ：モデルｉｄ
・ｄ0：ｄの子になり得る系列要素のうちの最初の要素（除外要素でもよい）
・ｄs：ｄの子になり得る非除外要素のうちの最初の要素
・ｐ：直前に確認したモデル内の系列の位置
式（１）に示す適合系列情報Σで定義された関数により、アプリケーションサーバ２４２とＤＢサーバ２４４との間のセッションのｉｄを入力すると親となるイベントを示すデータが特定される。また、特定された親となるイベントを示すデータに基づきモデルｉｄが特定される。そして、特定されたセッションのｉｄ、親となり得る要素およびモデルｉｄに対応するｄ0、ｄs、ｐの各値が特定される。
なお、各発生イベントを特定するため、系列化部１５０は、レスポンスメッセージを取得した場合に、過去に取得したリクエストメッセージとの対応関係を検出する。そのため系列化部１５０では、以下の関数Ｐが定義される。
Figure 0005482243
関数Ｐは、レスポンスメッセージの入力に対して、対応するリクエストメッセージを返す処理が定義されている。例えば系列化部１５０は、関数Ｐを呼び出して実行することで、レスポンスメッセージと同じセッション番号とリクエスト番号との組を有するリクエストメッセージを示すデータを取得できる。
〔系列分割情報〕
系列の分割時には、モデルｉｄに基づいて対応するモデルが参照される。そこで系列化部１５０には、モデルｉｄからモデルへの写像（Ｍ）が以下のように定義される。
Figure 0005482243
ｌ，ｌ0…ｌn-1は、それぞれデータの名前（系列要素の種別に相当）を示している。ｌは親となる要素の名前であり、ｌ0…ｌn-1は子となる要素の名前である。σは、子となる要素の名前の列である。
系列の分割はセッションごとに行われ、各セッションについて以下の系列分割情報（Ｃ）が生成される。
Figure 0005482243
これは、ｓｅｓｓｉｏｎｉｄで示されるセッションを介した通信から、系列要素がｄ0，…，ｄn1，ｄn1+1，…，ｄnの順で取得されたことが示されている。また［ｄi，…，ｄj］のように括弧で囲まれた系列要素のリストは、リストに示された系列要素の列を有する系列を表している。すなわち、セッションｉｄで示されるセッションを開始したメッセージに基づいて認識された系列要素の列が、括弧で示される各リストからなる系列に分割されている。
ここで、系列［ｄi，…，ｄj］を表す変数としてｓを用いることとする。変数ｓの右下に系列の識別番号を示す数字を付与することで、個々の系列との対応関係が示される。
〔親子候補情報〕
親子候補設定部１７０は、呼び出し関係を有する可能性がある要素間の関係（親子候補）を示す親子候補情報を生成する。親子候補情報（Ｒ）は、以下のように定義される。
Figure 0005482243
各変数は以下を意味する。
・ｄ： 親となり得る要素
・ｍｏｄｅｌｉｄ：モデルｉｄ
・ｓｅｓｓｉｏｎｉｄ：セッションｉｄ
・［ｓ0，…，ｓn］：系列のリスト
式（５）に示す親子候補情報Ｒで定義された関数により、親となり得る要素を入力すると、親となり得る要素に基づきモデルｉｄが特定される。また、特定されたモデルｉｄに基づきセッションｉｄが特定される。そして、特定されたセッションｉｄに基づき、系列のリストが特定される。
以上のような情報等を用いて系列化部１５０が系列化を行い、親子候補設定部１７０が親子候補を設定する。そして、分析部１９０が系列分割情報や親子候補情報を用いて、発生したイベントとモデル全体との照合（マッチング）を行い、トランザクションの処理状況を分析する。
図１１は、系列化および分析処理の手順を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。
〔ステップＳ１１〕系列化部１５０は、ネットワーク監視部１１０からのメッセージの入力を待つ。
〔ステップＳ１２〕系列化部１５０は、ネットワーク監視部１１０で検出されたメッセージを取得する。例えば、図９に示すメッセージ記憶部１２０に格納される各メッセージが、ネットワーク監視部１１０から系列化部１５０に渡される。
〔ステップＳ１３〕系列化部１５０と親子候補設定部１７０は、適合系列情報Σ、系列分割情報Ｃ、および親子候補情報Ｒを更新する。この処理の入力は、各セッションの系列分割情報Ｃ、および発生したイベントを示す時系列のデータである。なお、系列分割情報Ｃの初期状態は空である。またこの処理の出力は、親子候補情報Ｒと各セッションの系列分割情報Ｃである。この処理の詳細は後述する。
〔ステップＳ１４〕系列化部１５０は、処理開始後にメッセージ記憶部１２０に格納されたメッセージの数を示す保存個数の値を更新する。なお、保存個数を示す情報は、例えば系列化部１５０が管理するＲＡＭ１０２内の記憶領域に一時的に格納されている。
〔ステップＳ１５〕系列化部１５０は、保存個数が予め設定された一定値を超過したか否かを判断する。超過した場合、処理がステップＳ１６に進められる。超過していなければ、処理がステップＳ１１に進められる。
〔ステップＳ１６〕系列化部１５０は、系列分割情報Ｃを系列記憶部１６０に格納する。親子候補設定部１７０は、親子候補情報Ｒを親子候補記憶部１８０に格納する。そして、分析部１９０は、系列分割情報Ｃと親子候補情報Ｒとを参照し、メッセージ記憶部１２０に格納されたメッセージとモデル記憶部１４０に格納されたモデルとを照合する。分析部１９０は、メッセージとモデルとの照合において、メッセージに基づいて認識されるイベント間の呼び出し関係を、モデルに適合するように決定する。その際、系列に含まれるメッセージは、同一のイベントから呼び出されることが条件となる。分析部１９０は、照合により決定された呼び出し関係により、実行された各トランザクションを構成するイベントや系列を特定する。そして、分析部１９０は、サーバで各イベントが実行された時間を計算し、各トランザクションのイベントごとの処理時間を分析する。分析結果は、例えばモニタ１１に表示される。
このようにして、取得したメッセージに基づく系列化および分析が行われる。次に、ステップＳ１３に示す処理を詳細に説明する。
図１２は、Σ・Ｃ・Ｒ更新処理の手順を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。
〔ステップＳ２１〕系列化部１５０は、取得したメッセージが親となり得る要素のリクエストメッセージまたはレスポンスメッセージか、あるいは系列要素のリクエストメッセージまたはレスポンスメッセージかを判断する。例えば、Ｗｅｂサーバ２４１とアプリケーションサーバ２４２との間のセッションから取得したメッセージであれば、親となり得る要素のリクエストメッセージまたはレスポンスメッセージであることが分かる。また、アプリケーションサーバ２４２とＤＢサーバ２４４との間のセッションから取得したメッセージであれば、系列要素のリクエストメッセージまたはレスポンスメッセージであることが分かる。取得したメッセージがリクエストメッセージなのか、あるいはレスポンスメッセージなのかを示す情報は、メッセージの内容に記述されている。そのため、系列化部１５０は、メッセージの内容を参照することで、リクエストメッセージなのか、あるいはレスポンスメッセージなのかを判別できる。
取得したメッセージが親となり得る要素のリクエストメッセージであれば、処理がステップＳ２２に進められる。取得したメッセージが親となり得る要素のレスポンスメッセージであれば、処理がステップＳ２３に進められる。取得したメッセージが系列要素のリクエストメッセージであれば、処理がステップＳ２４に進められる。取得したメッセージが系列要素のレスポンスメッセージであれば、処理がステップＳ２５に進められる。
〔ステップＳ２２〕系列化部１５０は、親となり得る要素のリクエストメッセージ取得時には、第１の更新処理を実行する。この処理の詳細は後述する（図１３、図１４参照）。その後、Σ・Ｃ・Ｒ更新処理が終了する。
〔ステップＳ２３〕系列化部１５０は、親となり得る要素のレスポンスメッセージ取得時には、第２の更新処理を実行する。この処理の詳細は後述する（図１５、図１６参照）。その後、Σ・Ｃ・Ｒ更新処理が終了する。
〔ステップＳ２４〕系列化部１５０は、系列要素のリクエストメッセージ取得時には、第３の更新処理を実行する。この処理の詳細は後述する（図１７、図１８参照）。その後、Σ・Ｃ・Ｒ更新処理が終了する。
〔ステップＳ２５〕系列化部１５０は、系列要素のレスポンスメッセージ取得時には、第４の更新処理を実行する。この処理の詳細は後述する（図１９〜図２２参照）。その後、Σ・Ｃ・Ｒ更新処理が終了する。
次に、第１〜第４の更新処理それぞれについて詳細に説明する。なお図１３〜図３０では、変数「Ｒｅｑ」はリクエスト（Ｒｅｑｕｅｓｔ）メッセージの要素を示し、変数「Ｒｅｓ」はレスポンス（Ｒｅｓｐｏｎｓｅ）メッセージの要素を示す。
以下、第１〜第４の更新処理の論理的な動作定義例を示し、その動作定義を参照しながら、動作定義に従った更新処理の手順をフローチャートに沿って説明する。なお、動作定義の表記は、以下の規則に従う。
〔代入〕
値の代入は、「Ａ：＝Ｖ」のような形式で表記される。この式は、Ａの値をＶに設定することを示している。なお同様の表記は、関数の設定にも使用される。例えばｆ（２）＝１となるように関数ｆを設定する場合には、ｆ（２）：＝１と表記される。
〔論理式〕
「かつ」を意味する連言（∧）や「ならば」を意味する含意（⊃）などの論理式に用いられる記号は、数学や情報科学で通常用いられる通りの意味で使用される。例えば、連言や含意以外には、和集合（∪）、「ではない」を意味する否定（¬）などがある。
〔文字列長〕
文字列長ｎは、「｜ｌ0…ｌn-1｜＝ｎ」と表記される。
〔組〕
「＜ａ，ｂ＞，＜ａ，ｂ，ｃ＞，＜ａ，ｂ，ｃ，ｄ＞」などで、任意の個数の要素の組が表現される。
〔文字列σの位置ｐの文字〕
σで表される文字列「ｌ0…ｌn-1」中の位置ｐの文字ｌpは「σ（ｐ）」と表記される。
図１３は、第１の更新処理の動作定義の一例を示す図である。図１３には、親となり得る要素のリクエストメッセージを取得した場合の系列化部１５０と親子候補設定部１７０との動作が定義されている。なお、⊥は未定義値を意味する。
図１４は、第１の更新処理の動作定義に従った処理手順を示すフローチャートである。以下図１４のステップ番号に沿って、図１３の動作定義に従った処理を説明する。
〔ステップＳ３１〕系列化部１５０は、取得したメッセージに対応する親とり得る要素から子を呼び出し得るすべてのセッションについて、ステップＳ３２〜Ｓ３５の処理を実行する。この処理は、図１３に示す「∀ｓｉｄ∈ｄｏｍ（Σ）」の動作定義に基づいて実行される。
「∀ｓｉｄ∈ｄｏｍ（Σ）」は、任意のセッションｉｄが適合系列情報Σの定義域に属していることを示している。すなわち、取得したメッセージが示す要素が、子の要素の呼び出しに使用できるセッションのセッションｉｄが適合系列情報Σの定義域に属しており、そのセッションｉｄそれぞれを処理対象とすべき旨が示されている。例えばアプリケーションサーバ２４２のイベントにおいて、データベースアクセスの際に、アプリケーションサーバ２４２とＤＢサーバ２４４との間に予め設けられた複数のセッションのいずれを使用することもできる場合がある。この場合、アプリケーションサーバ２４２で実行されたイベントを示す要素に関して、アプリケーションサーバ２４２とＤＢサーバ２４４の間のすべてのセッションが、子を呼び出し得るセッションとなる。
〔ステップＳ３２〕系列化部１５０は、取得したメッセージに対応する親となり得る要素に適用可能なすべてのモデルについて、ステップＳ３３〜Ｓ３４の処理を実行する。この処理は、図１３に示す「∀ｍｉｄ∈ｄｏｍ（Ｍ）」の動作定義に基づいて実行される。
「∀ｍｉｄ∈ｄｏｍ（Ｍ）」は、任意のモデルｉｄが写像Ｍの定義域に属していることを示している。系列化部１５０はこの定義に基づいて、取得したメッセージで示される親となり得る要素に適用可能なすべてのモデルについて動作定義（α）以下の処理を実行する。
〔ステップＳ３３〕系列化部１５０は、系列の全セッションについてモデルに当て嵌まる部分の情報（適合系列情報Σ）を初期化する。この処理は、「ｓ．ｔ． Ｍ（ｍｉｄ）＝＜Ｒｅｑ の名前，＿＞」および「Σ（ｓｉｄ）（Ｒｅｑ）（ｍｉｄ）：＝＜⊥，⊥，０＞」に基づいて実行される。
「ｓ．ｔ．」は、「ｓｕｃｈ ｔｈａｔ」の略であり、右辺に記載されている値を満たすような、写像の変数を求めることを意味する。従って「ｓ．ｔ． Ｍ（ｍｉｄ）＝＜Ｒｅｑの名前，＿＞」は、リクエストメッセージの名前が呼び出し元に定義されているモデルのモデルｉｄを求める処理である。このとき得られるモデルｉｄは、１つまたは複数である。
「Σ（ｓｉｄ）（Ｒｅｑ）（ｍｉｄ）：＝＜⊥，⊥，０＞」は、処理対象のセッションｉｄ、リクエストメッセージ、およびモデルｉｄの組に対応する適合系列情報Σの値として、＜⊥，⊥，０＞を設定することを意味している。すなわち、系列化部１５０は、適合系列情報Σの初期状態として、親となる要素の子になり得る最初の系列要素、および親となるイベントを示す要素の子になり得る最初の非除外要素それぞれに、未定義値を設定する。また、系列化部１５０は、適合系列情報Σの初期状態として、直前に確認したモデルの系列の位置を示す値に「０」を設定する。
〔ステップＳ３４〕親子候補設定部１７０は、すべてのセッションに関して、処理対象となっているモデルに当て嵌まり得る親子候補情報Ｒを初期化する。
「Ｒ（Ｒｅｑ）（ｓｉｄ）（ｍｉｄ）：＝φ」は、処理対象のリクエストメッセージ、セッションｉｄ、およびモデルｉｄの組に対応する親子候補情報Ｒの値として「φ」を設定することを示している。なお親子候補情報Ｒの値として設定される「φ」は、空集合を意味する。
〔ステップＳ３５〕系列化部１５０は、取得したメッセージに対応する親となり得る要素に適用可能なすべてのモデルについてステップＳ３３〜Ｓ３４の処理が終了すると、ステップＳ３３〜Ｓ３４のループ処理を終了する。
〔ステップＳ３６〕系列化部１５０は、取得したメッセージに対応する親となり得る要素から子を呼び出し得るすべてのセッションについてステップＳ３２〜Ｓ３５の処理が終了すると、ステップＳ３２〜Ｓ３５のループ処理を終了する。その後、第１の更新処理が終了する。
次に第２の更新処理について説明する。
図１５は、第２の更新処理の動作定義の一例を示す図である。図１５には、親となり得る要素のレスポンスメッセージを取得した場合の系列化部１５０と親子候補設定部１７０との動作が定義されている。
図１６は、第２の更新処理の動作定義に従った処理手順を示すフローチャートである。以下図１６のステップ番号に沿って、図１５の動作定義に従った処理を説明する。
〔ステップＳ４１〕系列化部１５０は、取得したレスポンスメッセージに対応するリクエストメッセージを取得する。これは、図１５に示す「Ｒｅｑ：＝Ｐ（Ｒｅｓ）」の動作定義に基づいて実行される処理である。すなわち系列化部１５０は、レスポンスメッセージの識別情報（例えばセッション番号など）を変数として関数Ｐを実行することで、そのレスポンスメッセージに対応するリクエストメッセージを取得できる。
〔ステップＳ４２〕系列化部１５０は、取得したメッセージに対応する親となり得る要素から子を呼び出し得るすべてのセッションについて、ステップＳ４３〜Ｓ４９の処理を実行する。この処理は、図１５に示す「∀ｓｉｄ∈ｄｏｍ（Σ）」の動作定義に基づいて実行される。
〔ステップＳ４３〕系列化部１５０は、取得したメッセージに対応する親となり得る要素に適用可能なすべてのモデルについて、ステップＳ４４〜Ｓ４８の処理を実行する。この処理は、図１５に示す「∀ｍｉｄ∈ｄｏｍ（Ｍ）」の動作定義に基づいて実行される。
〔ステップＳ４４〕系列化部１５０は、処理対象のセッションの系列要素に、処理対処のモデル全体に適合する部分があるか否かを判断する。この処理は、図１５に示す「Σ（ｓｉｄ）（Ｒｅｑ）（ｍｉｄ）＝＜ｄ0，ｄs，ｐ＞∧Ｍ（ｍｉｄ）＝＜ｒ，σ＞∧ｒ＝Ｒｅｑの名前∧ｐ＋１＝｜σ｜」の条件に基づいて実行される。
「Σ（ｓｉｄ）（Ｒｅｑ）（ｍｉｄ）＝＜ｄ0，ｄs，ｐ＞∧Ｍ（ｍｉｄ）＝＜ｒ，σ＞∧ｒ＝Ｒｅｑの名前」は、「Ｒｅｑ」の名前（ラベル）が「ｒ」が、処理対象のモデルの親となる要素の名前と同じ（ｒ＝Ｒｅｑの名前）であることを示す。つまり処理対象のモデルが、取得したリクエストメッセージに応じた要素が親になり得ることが、第１の条件として定義されている。「ｐ＋１＝｜σ｜」は、処理対象のモデルについて与えられたセッション上でそのモデルの系列「σ」全体に適合する部分が現状みつかっていることを示す。図１５に示す動作定義では、「⊃」の左側の条件がすべて満たされるならば、下位に定義した動作定義に応じた処理を実行することが示されている。その結果、モデル全体に適合する部分があれば、処理がステップＳ４５に進められる。モデル全体に適合する部分がなければ、処理がステップＳ４８に進められる（図１５中（δ）で示す動作定義に基づく）。
〔ステップＳ４５〕系列化部１５０は、モデル中のσに適合する系列が、既に分割によって得られた系列以降の組み合わせか否かを判断する。この処理は、図１５中（β）で示した定義の条件部分「Ｃ（ｓｉｄ）の中にｄ0からｄsの１つ前の要素の間の要素を先頭とするリスト［ｄ’，．．．］が存在する」に基づいて実行される。この条件部分は、ｄs以前に複数の除外要素がある場合に、ｄ0とｄsの１つ前の要素との間に除外要素が存在し得る。そして、もしｄ0とｄsの１つ前の要素との間を境界として既に系列が分割されている場合、ｄ0からｄsの１つ前の要素の間の要素（ｄ’）を先頭とするリスト［ｄ’，．．．］が存在する。このリストには、ｄs以降の系列要素が含まれている。そのためリスト［ｄ’，．．．］が存在すれば、既に分割によって得られた系列以降の組み合わせによって、モデル中のσに適合する系列が得られる。
モデル中のσに適合する系列が、既に分割によって得られた系列以降の組み合わせであれば、処理がステップＳ４６に進められる。モデル中のσに適合する系列が、既に分割によって得られた系列以降の組み合わせでなければ、処理がステップＳ４７に進められる。
［ステップＳ４６］親子候補設定部１７０は、適合する系列の組み合わせを親子候補に設定する。この処理は、図１５中（β）で示された定義の結論部分「Ｒ（Ｒｅｑ）（ｍｉｄ）（ｓｉｄ）＝Ｒ（Ｒｅｑ）（ｍｉｄ）（ｓｉｄ）∪｛［σ，．．．，σ’］｝ただし、σ＝［ｄ’，．．．］かつσ’＝Ｃ（ｓｉｄ）の最後の要素」に基づいて実行される。結論部分は、Ｒ（Ｒｅｑ）（ｍｉｄ）（ｓｉｄ）に既に設定されている親子関係候補の集合と［σ，．．．，σ’］との和集合を、Ｒ（Ｒｅｑ）（ｍｉｄ）（ｓｉｄ）の集合として新たに設定することを示している。この処理が終了すると、処理がステップＳ４８に進められる。
［ステップＳ４７］系列化部１５０は、リスト［ｄ’，．．．］が存在しない場合、適切な系列の境界が未定のため、境界を判定して系列を分割する。この処理は、図１５中（γ）で示された動作定義に基づいて実行される。この動作定義（γ）の内容は、さらに（γ−１）、（γ−２）、（γ−３）に分けられる。
まず系列化部１５０は、処理対象のモデルに適合するように分割可能な位置（適合系列情報Σで与えられるｄ0とｄsの間）を求める。次に、系列化部１５０は、求めた位置のうち時間間隔が最大な場所を境界として系列を分割する。この処理は、図１５中（γ−１）で示された動作定義に基づいて実行される。すなわち、「Ｃ＝［．．．，［．．．，ｄ0，．．．，ｄs，．．．］，．．．］で、ｄ0とｄsとの間で一番時間間隔の大きい要素対をｃ，ｃ’として」の部分で、ｃとｃ’との間を境界とすることが示されている。そして「Ｃ：＝「Ｃ＝［．．．，［．．．，ｄ0，．．．，ｃ］，［ｃ’，．．．，ｄs，．．．］，．．．］」の部分で、系列を分割することが示されている。
親子候補設定部１７０は、分割によって生成された境界より後の系列を、処理対象の親となり得る要素に対して子候補として設定する。この処理は、図１５中（γ−２）で示された動作定義「Ｒ（Ｒｅｑ）（ｍｉｄ）（ｓｉｄ）：＝Ｒ（Ｒｅｑ）（ｍｉｄ）（ｓｉｄ）∪｛［σ，．．．，σ’］に基づいて実行される。この場合、σはｄsを含む系列［ｃ’，．．．，ｄs，．．．］であり、σ’はσ’＝Ｃ（ｓｉｄ）の最後の要素である。
さらに親子候補設定部１７０は、処理対象の親となり得る要素に対して子候補として設定した系列を、監視対象となっている他の親となり得る要素全体に反映させる。すなわち、処理対象の親となり得る要素の子候補として追加した系列が、他の呼び出し元の要素の子候補の一部に含まれていたら、当該追加した系列と同じになるように他の呼び出し元の要素の子候補を分割する。この処理は図１５中（γ−３）で示された動作定義「∀ｒ∈ｄｏｍ（Ｒ） Ｒ（ｒ）（ｓｉｄ）中に［．．．，ｃ，ｃ’，．．．］を含めば［．．．，ｃ］，［ｃ’，．．．］に更新」に基づいて実行される。
［ステップＳ４８］系列化部１５０は、適合系列情報Σを、処理対象のＲｅｑについて削除する。この処理は、図１５中（δ）で示す動作定義「∀ｓｉｄ∈ｄｏｍ（Σ） ∀ｍｉｄ∈ｄｏｍ（Ｍ） Σ（ｓｉｄ）（Ｒｅｑ）（ｍｉｄ）：＝⊥」に基づいて実行される。
〔ステップＳ４９〕系列化部１５０は、取得したメッセージに対応する親となり得る要素に適用可能なすべてのモデルについてステップＳ４４〜Ｓ４８の処理が終了すると、ステップＳ４４〜Ｓ４８のループ処理を終了する。
〔ステップＳ５０〕系列化部１５０は、取得したメッセージに対応する親となり得る要素から子を呼び出し得るすべてのセッションについてステップＳ４３〜Ｓ４９の処理が終了すると、ステップＳ４３〜Ｓ４９のループ処理を終了する。その後、第２の更新処理が終了する。
次に第３の更新処理について説明する。
図１７は、第３の更新処理の動作定義の一例を示す図である。図１７には、系列要素のリクエストメッセージを取得した場合の系列化部１５０の動作が定義されている。
図１８は、第３の更新処理の動作定義に従った処理手順を示すフローチャートである。以下図１８のステップ番号に沿って、図１７の動作定義に従った処理を説明する。
〔ステップＳ６１〕系列化部１５０は、同一セッション上で対応するレスポンスメッセージを取得した場合に対応付けるリクエストメッセージとして、取得した系列要素のリクエストメッセージのデータを関数Ｐの戻り値に登録する。この処理は、図１７中（ζ）で示す動作定義に基づいて実行される。例えば、系列化部１５０は、取得したリクエストメッセージのデータからセッションｉｄを取得する。次に系列化部１５０は、取得したセッションｉｄを関数Ｐの変数とした場合の値として、取得したリクエストメッセージを示すデータを登録する。
次に第４の更新処理について説明する。
図１９は、第４の更新処理の動作定義の一例を示す図である。図１９には、系列要素のレスポンスメッセージを取得した場合の系列化部１５０と親子候補設定部１７０との動作が定義されている。
図２０は、第４の更新処理の動作定義に従った処理手順を示すフローチャートである。以下図２０のステップ番号に沿って、図１９の動作定義に従った処理を説明する。
〔ステップＳ７１〕系列化部１５０は、取得したレスポンスメッセージに対応するリクエストメッセージを取得する。これは、図１９に示す「Ｒｅｑ：＝Ｐ（Ｒｅｓｐｏｎｓｅ）」の動作定義に基づいて実行される処理である。すなわち系列化部１５０は、レスポンスメッセージの識別情報（例えばセッションｉｄなど）を変数として関数Ｐを実行する。これにより、系列化部１５０は、そのレスポンスメッセージＲｅｓｐｏｎｓｅ（ｓｅｓｓｉｏｎｉｄ＝ｓｉｄ）に対応するリクエストメッセージＲｅｑｕｅｓｔ（ｒ）を取得できる。
〔ステップＳ７２〕系列化部１５０は、系列要素を系列に追加する。この処理は、図１９中（η）で示された動作定義「Ｃ（ｓｉｄ）：＝［．．．，［．．．，ｌ，ｒ］］ ｗｈｅｒｅ Ｃ（ｓｉｄ）＝［．．．，［．．．，ｌ］］」に基づいて実行される。なお、追加された要素「ｒ」には、そのレスポンスメッセージの情報も含まれる。
〔ステップＳ７３〕系列化部１５０は、取得したリクエストメッセージの属するセッションの親となり得るすべての要素について、ステップＳ７３〜Ｓ８１の処理を実行する。この処理は、図１９に示す「∀ｓｉｄ∈ｄｏｍ（Σ（ｓｉｄ））」の動作定義に基づいて実行される。
〔ステップＳ７４〕系列化部１５０は、処理対象の親となり得る要素に適用可能なすべてのモデルに対して、ステップＳ７４〜Ｓ８０の処理を実行する。この処理は、図１９に示す「「∀ｍｉｄ∈ｄｏｍ（Σ（ｓｉｄ）（Ｒｅｑ））」の動作定義に基づいて実行される。
〔ステップＳ７５〕系列化部１５０は、与えられた親データに対して子候補の列が設定されておらず、かつリクエストメッセージに対応する系列要素が除外要素であるかどうかを判断する。なお、親データに対して子候補の列が設定されていない場合とは、これまで親のリクエストメッセージが届いてから子のセッションのリクエストメッセージが届いていないか、または、届いたが現在照合しているモデルに適合しなかった場合である。この処理は、図１９中（θ）で示された動作定義の条件部「ｄ0＝⊥∧Ｋ（ｒ）＝Ｉ」に基づいて実行される。定義された条件が満たされる場合、処理がステップＳ７６に進められる。定義された条件が満たされなければ、処理がステップＳ７７に進められる。
〔ステップＳ７６〕系列化部１５０は、子となり得る最初の要素を更新する。例えば系列化部１５０は、適合系列情報Σに対して、このリクエストメッセージからモデルに適合するかもしれないという情報を設定する。この処理は、図１９中（θ）で示される動作定義の結論部「Σ（ｓｉｄ）（Ｒｅｑ）（ｍｉｄ）：＝＜ｒ，ｄs，ｐ＞」に基づいて実行される。ただし、リクエストメッセージを示す「ｒ」には、同一セッションの中の順番などの情報も含まれているものとする。その後、処理がステップＳ８１に進められる。
〔ステップＳ７７〕系列化部１５０は、検出した系列要素が非除外要素か否かを判断する。この処理は、図１９の動作定義「Ｋ（ｒ）＝Ｏ」に基づいて実行される。非除外要素であれば、処理がステップＳ７８に進められる。非除外要素でなければ、処理がステップＳ８１に進められる。
〔ステップＳ７８〕系列化部１５０は、照合しているセッションの系列に含まれる非除外要素の配列が、モデルの系列全体に適合するか否かを判断する。この処理は、図１９の動作定義「Ｍ（ｍｉｄ）＝＜＊，σ＞」および「ｐ＝｜σ｜」に基づいて実行される。系列が全体適合していれば、処理がステップＳ７９に進められる。部分的にしか適合していか、まったく適合していなければ、処理がステップＳ８０に進められる。
〔ステップＳ７９〕系列化部１５０は、全体適合系列対応処理を実行する。この処理の詳細は後述する（図２１参照）。その後、処理がステップＳ８１に進められる。
〔ステップＳ８０〕系列化部１５０は、部分適合系列対応処理を実行する。この処理の詳細は後述する（図２２参照）。
〔ステップＳ８１〕系列化部１５０は、適用可能なすべてのモデルについてステップＳ７５〜Ｓ８０の処理が終了すると、ステップＳ７５〜Ｓ８０のループ処理を終了する。
〔ステップＳ８２〕系列化部１５０は、親となり得るすべての要素についてステップＳ７４〜Ｓ８１の処理が終了すると、ステップＳ７４〜Ｓ８１のループ処理を終了する。その後、第４の更新処理が終了する。
次に、全体適合系列対応処理について説明する。
図２１は、全体適合系列対応処理の手順を示すフローチャートである。以下図２１のステップ番号に沿って、図１９の動作定義に従った処理を説明する。
〔ステップＳ９１〕系列化部１５０は、系列を分割する。この処理は、図１９中（ι）で示す動作定義に基づいて実行される。この動作定義（ι）の内容は、さらに（ι−１）、（ι−２）、（ι−３）、（ι−４−１）、（ι−４−２）に分けられる。
まず系列化部１５０は、リクエストメッセージから除外要素が続く間遡って、一番時間間隔の大きいところで系列に分割する。この処理は、図１９中（ι−１）で示す動作定義に基づいて実行される。すなわち、「Ｃ（ｓｉｄ）：＝［．．．，［．．．ｎ］，［ｎ’，．．．，ｒ］］ ｗｈｅｒｅ［．．．，ｎ，ｎ’，．．．，ｒ］」の動作定義により、［．．．，ｎ，ｎ’，．．．，ｒ］で示される系列が、要素ｎと要素ｎ’との間を境界として分割される。このとき、要素ｒから非除外要素（「Ｋ（＊）＝Ｏ」）に到達するまで遡って、除外要素ｎ’（「Ｋ（ｎ’）＝Ｉ」）とその前の要素ｎとの時間間隔が最大となる位置が、系列の境界となる。
次に系列化部１５０は、系列の先頭部分として適当な境界がなければ、第２の更新処理における分割処理（ステップＳ４７）と同様に、一番時間間隔の大きい位置を境界として系列を分割する。ここで、系列の先頭部分として適当な境界とは、現在照合しているモデルとの関係におけるｄ0とｄsとの間と位置のうち、他のモデルとの照合時に系列の分割に用いられた境界である。この処理は、図１９中（ι−２）の動作定義に基づいて実行される。このように、他のモデルとの照合において既に境界が決定されている場合、その境界以降の処理列が、新たに生成する系列とされる。
さらに親子候補設定部１７０は、分割によって生成された系列を、親子候補に設定する。この処理は、図１９中（ι−３）の動作定義「Ｒ（Ｒｅｑ）（ｍｉｄ）（ｓｉｄ）：＝Ｒ（Ｒｅｑ）（ｍｉｄ）（ｓｉｄ）∪｛［σ，．．．，σ’］｝」に基づいて実行される。この場合、σ＝［．．．，ｄs，．．．］であり、かつσ’はＣ（ｓｉｄ）の後ろから２番目の要素である。
〔ステップＳ９２〕系列化部１５０は、現在処理対象となっている親となり得る要素に対し適用可能なすべてのモデルについて、ステップＳ９３〜Ｓ９５の処理を実行する。
〔ステップＳ９３〕系列化部１５０は、モデルの系列の最初の要素にｒ（届いたレスポンスメッセージに対応するリクエストメッセージの名前（ラベル））が合致するか否かを判断する。この処理は、図１９に示す動作定義「∀ｍｉｄ’∈ｄｏｍ（Ｍ） ｓ．ｔ．Ｍ（ｍｉｄ）’＝＜Ｒｅｑの名前，σ’＞」に基づいて実行される。名前が合致する場合、処理がステップＳ９４に進められる。名前が合致しない場合、処理がステップＳ９５に進められる。
〔ステップＳ９４〕系列化部１５０は、モデルの系列の最初の要素に合致するリクエストメッセージであると判定した場合、処理対象となっているモデルに関する適合系列情報Σを更新する。具体的には系列化部１５０は、ステップＳ９１の系列分割処理で分割された最後の系列の先頭の要素から、現在処理対象となっているモデルに合致する可能性があることを設定する。すなわち、分割時の境界となった位置の次の系列の先頭の要素ｎ’が、適合系列情報Σの変数ｄ0に設定される。また系列化部１５０は、届いたレスポンスメッセージに対応するリクエストメッセージから合致しないといけないように適合系列情報Σを更新する。すなわち、取得したレスポンスメッセージに対応するリクエストメッセージを示す要素が、適合系列情報Σの変数ｄsに設定される。この際、系列化部１５０は、モデルの系列のうちの最初の要素との照合が終了を示したことを示す情報を設定する。すなわち、適合系列情報Σの変数ｐに「１」が設定される。この処理は、図１９中（ι−４−１）で示す動作定義「σ’（０）＝ｒ ⊃ Σ（ｓｉｄ）（Ｒｅｑ）（ｍｉｄ’）：＝＜ｎ’，ｒ，１＞」に基づいて実行される。
〔ステップＳ９５〕系列化部１５０は、モデルの系列の最初の要素に合致しないリクエストメッセージであると判定した場合、処理対象となっているモデルに関する適合系列情報Σを初期化する。この処理は図１９中（ι−４−２）で示す動作定義「σ’（０）≠ｒ ⊃ Σ（ｓｉｄ）（Ｒｅｑ）（ｍｉｄ）：＝＜⊥，⊥，０＞」に基づいて実行される。
〔ステップＳ９６〕系列化部１５０は、現在処理対象となっている親となり得る要素に対し適用可能なすべてのモデルについて、ステップＳ９３〜Ｓ９５の処理が完了するとループ処理を終了すると共に、全体適合系列対応処理を終了する。
次に、部分適合系列対応処理について説明する。
図２２は、部分適合系列対応処理の手順を示すフローチャートである。以下図２２のステップ番号に沿って、図１９の動作定義に従った処理を説明する。
〔ステップＳ１０１〕系列化部１５０は、モデルの系列の途中まで、監視対象のセッションの系列が適合しており、かつ今回得たリクエストメッセージがモデルの系列の次の部分に適合しているかどうかを判断する。この処理は、図１９中（κ）で示される動作定義の条件部分「ｐ≠｜σ｜∧σ（ｐ）＝ｒ」に基づいて実行される。当該条件が満たされていれば、処理がステップＳ１０５に進められる。当該条件が満たされていなければ、処理がステップＳ１０２に進められる。
〔ステップＳ１０２〕系列化部１５０は、少なくとも含まないといけない要素を示す情報（ｄs）が得られていない（ｄs＝⊥）か否かを判断する。該当情報が得られていない場合、処理がステップＳ１０３に進められる。該当情報が得られている場合、処理がステップＳ１０４に進められる。
〔ステップＳ１０３〕系列化部１５０は、少なくとも含まないといけない要素を示す情報（ｄs）が得られていない場合、処理対象のセッションの処理対象のモデルに関する適合系列情報Σを初期化する。この処理は、図１９中（λ）で示される動作定義「（ｄs＝⊥） ⊃ Σ（ｓｉｄ）（Ｒｅｑ）（ｍｉｄ）：＝＜⊥，⊥，０＞」に基づいて実行される。その後、部分適合系列対応処理が終了する。
〔ステップＳ１０４〕系列化部１５０は、少なくとも含まないといけない要素を示す情報（ｄs）が得られている場合、まず適合系列情報Σを初期化する。その後、系列化部１５０は、得ていた要素ｄsの次の要素から、取得したリクエストメッセージまで、順にもう一度、対応するレスポンスメッセージが到着したものとして適合系列情報Σの更新処理を行う。この処理は、図１９中（μ）で示す動作定義「（ｄs≠⊥） ⊃ Σ（ｓｉｄ）（Ｒｅｑ）（ｍｉｄ）：＝＜⊥，⊥，０＞としてｄsの次の要素からｒまでの要素について、この処理を繰り返す」に基づいて実行される。その後、部分適合系列対応処理が終了する。
〔ステップＳ１０５〕系列化部１５０は、モデルに合致し得る部分の系列要素が見つかっていない（ｄ0＝⊥）か否かを判断する。該当要素が見つかっていない場合、処理がステップＳ１０６に進められる。見つかっている場合、処理がステップＳ１０７に進められる。
〔ステップＳ１０６〕系列化部１５０は、ｄ0に登録する要素が見つかっていない場合、ｄ0に、取得したレスポンスメッセージに対応するリクエストメッセージを示す要素を設定する。その後、処理がステップＳ１０８に進められる。
〔ステップＳ１０７〕系列化部１５０は、ｄ0に登録する要素が見つかっている場合、ｄ0は変更しない。
なおステップＳ１０５〜Ｓ１０７の処理は、図１９中（κ−１）で示す動作定義「ｄ0’＝ｒ ｉｆ ｄ0＝⊥、ｄ0’＝ｄ0 ｏｔｈｅｒｗｉｓｅ」に基づいて実行される。
〔ステップＳ１０８〕系列化部１５０は、モデルの系列の最初の要素と適合した要素がない（ｐ＝０）か否かを判断する。該当する要素がない場合、処理がステップＳ１０９に進められる。該当する要素がある場合、処理がステップＳ１１０に進められる。
〔ステップＳ１０９〕系列化部１５０は、モデルの系列の最初の要素と適合した要素がない場合、ｄsに、取得したレスポンスメッセージに対応するリクエストメッセージを示す要素を設定する。その後、処理がステップＳ１１０に進められる。
〔ステップＳ１１０〕系列化部１５０は、モデルの系列の最初の要素と適合した要素がある場合、ｄsは変更しない。
なおステップＳ１０８〜Ｓ１１０の処理は、図１９中（κ−２）で示す動作定義「ｄs’＝ｒ ｉｆ ｐ＝０、ｄs’＝ｄs ｏｔｈｅｒｗｉｓｅ」に基づいて実行される。
〔ステップＳ１１１〕系列化部１５０は、ステップＳ１０５〜Ｓ１１０で設定したｄ0、ｄsの値を適合系列情報Σに設定する。その後、部分適合系列対応処理が終了する。
以上のような手順で処理を行うことで、適切な系列化が行われる。以下、系列化の具体例について説明する。
まず、第２の実施の形態における系列化の第１の例について説明する。
図２３は、第２の実施の形態における系列化の第１の例を示す図である。第１の例では、名前が「Ｉ１」の要素に適用されるモデル「ｍ１」では、呼び出し先として系列「Ｒ１，Ｒ２」が設定されている。
〔第１−１の状態〕まず、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｉ１」のリクエストメッセージが検出されたものとする。このリクエストメッセージに応じたイベントを示す要素を「ａ」とする。このときアプリケーションサーバ２４２とＤＢサーバ２４４との間のセッション（ｓｅ１）上の処理列の系列化を行う場合を想定する。
親となり得る要素「ａ」の発生により、子候補になるセッション（ｓｅ１）上の要素を監視するため、まず系列分割情報Ｃが初期化される。例えば、Ｃ（ｓｅ１）＝［．．．，［．．．］］とされる。また第１の更新処理の（α）で示される動作定義に従って、適合系列情報Σと親子候補情報Ｒとが初期化される。
〔第１−２の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｒ１」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｂ」とする。すると系列分割情報Ｃの最後に、系列要素「ｂ」が追加される。
また、「Ｒ１」のイベントの呼び出しは、モデル「ｍ１」に適合している。そこで、第４の更新処理の（ι）で示される処理に従って、適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｂ，ｂ，１＞」に更新される。この適合系列情報Σの更新処理は、系列要素ａを系列要素ｂの親候補として仮設定することを意味する。
〔第１−３の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｒ２」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｃ」とする。すると系列分割情報Ｃの最後に、系列要素「ｃ」が追加される。
また、「Ｒ１」に続く「Ｒ２」のイベントの呼び出しは、モデル「ｍ１」に適合している。そこで第４の更新処理の（ι）で示される処理に従って、適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｂ，ｂ，２＞」に更新される。すなわち、モデルの系列の何番目まで適合したのかを示す情報がカウントアップされる。この適合系列情報Σの更新処理は、要素「ａ」を系列要素「ｃ」の親候補として仮設定することを意味する。
〔第１−４の状態〕最後に、ＤＢサーバ２４４からアプリケーションサーバ２４２への親となり得る要素「ａ」のレスポンスメッセージが検出されたものとする。この場合、セッション（ｓｅ１）上の要素がモデル（ｍ１）の系列に適合している。そこで、第２の更新処理の（β）で示される動作定義に従って、親子候補情報Ｒが「Ｒ（ａ）（ｍ１）（ｓｅ１）：＝｛［［ｂ，ｃ］］｝」に更新される。この親子候補情報Ｒの更新処理は、親となり得る要素「ａ」と系列要素「ｃ」との関係を、親子候補に設定することを意味する。
ここで、〔第１−４の状態〕では、親子候補情報Ｒの更新状況を示しているが、系列化部１５０は、系列分割情報Ｃについても、系列要素「ｂ」，「ｃ」を１つの系列３０１とするように更新することができる。
次に、系列化の第２の例について説明する。
図２４は、第２の実施の形態における系列化の第２の例を示す図である。図２４の例は、親となり得る要素に複数の親子候補が設定される場合の一例を示している。このような例として、系列上の処理列が観測中にモデルと適合しなくなり、そこで系列の分割を行う場合がある。第２の例では、名前が「Ｉ１」の要素に適用されるモデル「ｍ１」では、呼び出し先として系列「Ｒ１」が設定されている。
〔第２−１の状態〕まず、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｉ１」の２つのリクエストメッセージが検出されたものとする。このリクエストメッセージに応じたイベントを示す要素を、それぞれ「ａ」、「ｂ」とする。このときアプリケーションサーバ２４２とＤＢサーバ２４４との間のセッション（ｓｅ１）上の処理列の系列化を行う場合を想定する。
親となり得る要素「ａ」、「ｂ」の発生により、セッション（ｓｅ１）上の子となり得る要素を監視するため、まず系列分割情報Ｃが初期化される。また第１の更新処理の（α）で示される動作定義に従って、親となり得る要素「ａ」、「ｂ」ごとに、適合系列情報Σと親子候補情報Ｒとが初期化される。
〔第２−２の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｒ１」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｃ」とする。すると系列分割情報Ｃの最後に、系列要素「ｃ」が追加される。
また、「Ｒ１」のイベントの呼び出しは、モデル「ｍ１」に適合している。そこで、第４の更新処理の（ι）で示される動作定義に従って、親となり得る要素「ａ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｃ，ｃ，１＞」に更新される。同様に、親となり得る要素「ｂ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ｂ）（ｍ１）：＝＜ｃ，ｃ，１＞」に更新される。
〔第２−３の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｒ１」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｄ」とする。すると第４の更新処理の（η）で示される動作定義に従って、系列分割情報Ｃの最後に系列要素「ｄ」が追加される。
また、「Ｒ１」に続く「Ｒ１」のイベントの呼び出しは、モデル「ｍ１」に適合していない。すると、このまま前の系列要素「ｃ」と新たに検出した系列要素「ｄ」とを１つの系列でまとめるとモデルに適合しなくなる。そこで、第４の更新処理の（ι）で示される動作定義に従って、系列要素「ｃ」と系列要素「ｄ」との間を境界として系列が分割されるように系列分割情報Ｃが更新される。この際、系列要素「ｃ」の手前でも分割され、「ｃ」１つだけからなる系列３０２が作成される。具体的には、系列分割情報Ｃが「Ｃ（ｓｅ１）：＝［．．．，［．．．］，［ｃ］，［ｄ］］」に更新される。
さらに、親となり得る要素「ａ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｄ，ｄ，０＞」に更新される。同様に、親となり得る要素「ｂ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ｂ）（ｍ１）：＝＜ｄ，ｄ，０＞」に更新される。すなわち、新たに、系列要素「ｄ」の親候補に要素「ａ」、「ｂ」が仮設定され、系列要素「ｄ」から始まる系列の監視が継続される。
〔第２−４の状態〕最後に、ＤＢサーバ２４４からアプリケーションサーバ２４２への親となり得る要素「ａ」のレスポンスメッセージが検出されたものとする。この場合、セッション（ｓｅ１）上の系列要素「ｄ」がモデル（ｍ１）の系列に適合している。そこで系列要素「ｄ」１つだけからなる系列３０３が作成され、各要素「ａ」との間で親子候補の関係が設定される。すなわち、第２の更新処理の（β）で示される処理に従って、親となり得る要素「ａ」に対応する親子候補情報Ｒが「Ｒ（ａ）（ｍ１）（ｓｅ１）：＝｛［［ｃ］］，［［ｄ］］｝」に更新される。
その後、親となり得る要素「ｂ」のレスポンスメッセージが検出された場合にも同様の親子候補が設定される。すなわち、親となり得る要素「ｂ」に対応する親子候補情報Ｒが「Ｒ（ｂ）（ｍ１）（ｓｅ１）：＝｛［［ｃ］］，［［ｄ］］｝」に更新される。
このように複数の親候補が設定された場合、本来の親子関係については、分析部１９０において判断される。すなわち、分析部１９０は、親子関係の確からしさを統計的な手法などを用いて計算し、親子関係が確かに存在するイベント間の親子関係を特定する。これにより、分析部１９０では、複数の親子候補の中から、１つの親子関係を特定することができる。なお、分析部１９０は、親子候補となっていない要素と系列との関係は、親子関係の有無に関する判断対象から除外する。これにより、分析部１９０における処理負荷が軽減される。
次に、第２の実施の形態における系列化の第３の例について説明する。
図２５は、第２の実施の形態における系列化の第３の例を示す図である。系列化の第３の例は、図２４に示した第２の例と同様に、データが観測中にモデルと適合しない系列要素を検出する場合の例である。ただし、第３の例では、最初に適合しない系列要素を検出し、その後、途中から適合する系列要素を検出する場合の例である。なお第３の例では、親候補は１つのみとする。また図２５の例では、名前が「Ｉ１」の要素に適用されるモデル「ｍ１」では、呼び出し先として系列「Ｒ１」が設定されている。
〔第３−１の状態〕まず、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｉ１」のリクエストメッセージが検出されたものとする。このリクエストメッセージに応じたイベントを示す要素を、「ａ」とする。このときアプリケーションサーバ２４２とＤＢサーバ２４４との間のセッション（ｓｅ１）上の処理列の系列化を行う場合を想定する。
親となり得る要素「ａ」の発生により、子候補になるセッション（ｓｅ１）上の要素を監視するため、まず系列分割情報Ｃが初期化される。また第１の更新処理の（α）で示される動作定義に従って、適合系列情報Σと親子候補情報Ｒとが初期化される。
〔第３−２の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｒ２」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｂ」とする。すると系列分割情報Ｃの最後に、系列要素「ｂ」が追加される。
また、「Ｒ２」のイベントの呼び出しは、モデル「ｍ１」に適合していない。そこで、第４の更新処理の（η）で示される動作定義に従って、親となり得る要素「ａ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜⊥，⊥，０＞」に初期化される。
〔第３−３の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｒ１」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｃ」とする。すると系列分割情報Ｃの最後に、系列要素「ｃ」が追加される。
また、「Ｒ１」のイベントの呼び出しは、モデル「ｍ１」に適合している。そこで、第４の更新処理の（κ）で示される動作定義に従って、親となり得る要素「ａ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｃ，ｃ，１＞」に更新される。
〔第３−４の状態〕最後に、ＤＢサーバ２４４からアプリケーションサーバ２４２への親となり得る要素「ａ」のレスポンスメッセージが検出されたものとする。この場合、セッション（ｓｅ１）上の系列要素「ｃ」がモデル（ｍ１）の系列に適合している。そこで系列要素「ｃ」１つだけからなる系列３０４が作成され、各要素「ａ」との間で親子候補の関係が設定される。すなわち、第２の更新処理の（γ）で示される処理に従って、系列分割情報Ｃが、「Ｃ（ｓｅ１）：＝［…，［…，ｂ］，［ｃ］］」に更新される。また、親子候補情報Ｒが「Ｒ（ａ）（ｍ１）（ｓｅ１）：＝｛［［ｃ］］｝」に更新される。
このとき、要素「ａ」以外の親となり得る要素が存在し、系列［ｂ，ｃ］との間で親子候補が既に設定されていた場合、その要素に関する親子候補情報Ｒにおいて、系列［ｂ，ｃ］が個別の系列［ｂ］，［ｃ］に分割される。このように要素「ａ」に関する処理中に系列が分割された場合、その分割結果に応じて親となり得る他の要素に関する親子候補情報が更新される。これにより、親となり得る要素間の親子候補情報における系列の整合性が保たれる。
次に、第２の実施の形態における系列化の第４の例について、図２６、図２７を参照して説明する。
図２６は、第２の実施の形態における系列化の第４の例の前半を示す図である。第４の例は、モデルに適合する系列要素が検出された後、モデルに適合しない非除外要素が検出されたときに、再び途中から観測結果を調べる場合の例である。第４の例では、名前が「Ｉ１」の要素に適用されるモデル「ｍ１」では、呼び出し先として系列「Ｒ１，Ｒ２」が設定されている。
〔第４−１の状態〕まず、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｉ１」のリクエストメッセージが検出されたものとする。このリクエストメッセージに応じたイベントを示す要素を、「ａ」とする。このときアプリケーションサーバ２４２とＤＢサーバ２４４との間のセッション（ｓｅ１）上の処理列の系列化を行う場合を想定する。
親となり得る要素「ａ」の発生により、子候補になるセッション（ｓｅ１）上の要素を監視するため、まず系列分割情報Ｃが初期化される。また第１の更新処理の（α）で示される動作定義に従って、適合系列情報Σと親子候補情報Ｒとが初期化される。
〔第４−２の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｒ１」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｂ」とする。すると系列分割情報Ｃの最後に、系列要素「ｂ」が追加される。
また、「Ｒ１」のイベントの呼び出しは、モデル「ｍ１」の系列の先頭の要素に適合しているものの、また「Ｒ２」が検出されていないため、系列全体としては一致していない。そこで、第４の更新処理の（κ）で示される動作定義に従って、親となり得る要素「ａ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｂ，ｂ，１＞」に更新される。
〔第４−３の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｒ１」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｃ」とする。すると系列分割情報Ｃの最後に、系列要素「ｃ」が追加される。
また、「Ｒ１」のイベントの２回連続での呼び出しは、モデル「ｍ１」に適合していない。そこで、第４の更新処理の（μ）で示される動作定義に従って、まず、親となり得る要素「ａ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜⊥，⊥，０＞」に初期化される。そして、系列要素「ｃ」以降でモデルに適合する箇所（途中まででもよい）が確認される。図２６の例では、系列要素「ｃ」がモデルの先頭に適合している。そこで、適合する箇所から、モデルにあう系列がある可能性があるように、適合系列情報Σが更新される。すなわち、適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｃ，ｃ，１＞」に更新される。
図２７は、第２の実施の形態における系列化の第４の例の後半を示す図である。
〔第４−４の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｒ２」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｄ」とする。すると系列分割情報Ｃの最後に、系列要素「ｄ」が追加される。
また、「Ｒ１」に続く「Ｒ２」のイベントの呼び出しは、モデル「ｍ１」に適合している。そこで第４の更新処理の（κ）で示される処理に従って、適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｃ，ｄ，２＞」に更新される。
〔第４−５の状態〕最後に、ＤＢサーバ２４４からアプリケーションサーバ２４２への親となり得る要素「ａ」のレスポンスメッセージが検出されたものとする。この場合、セッション（ｓｅ１）上の系列「ｃ，ｄ」がモデル（ｍ１）の系列に適合している。そこで系列要素「ｃ，ｄ」からなる系列３０５が作成され、要素「ａ」との間で親子候補の関係が設定される。すなわち、第２の更新処理の（γ）で示される処理に従って、系列分割情報Ｃが、「Ｃ（ｓｅ１）：＝［…，［…，ｂ］，［ｃ，ｄ］］」に更新される。また、親子候補情報Ｒが「Ｒ（ａ）（ｍ１）（ｓｅ１）：＝｛［［ｃ，ｄ］］｝」に更新される。
次に、第２の実施の形態における系列化の第５の例について説明する。
図２８は、第２の実施の形態における系列化の第５の例を示す図である。第５の例は、除外要素を含むデータを観測する場合の系列化の例である。第５の例では、名前が「Ｉ１」の要素に適用されるモデル「ｍ１」では、呼び出し先として系列「Ｒ１」が設定されている。
〔第５−１の状態〕まず、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｉ１」のリクエストメッセージが検出されたものとする。このリクエストメッセージに応じたイベントを示す要素を、「ａ」とする。このときアプリケーションサーバ２４２とＤＢサーバ２４４との間のセッション（ｓｅ１）上の処理列の系列化を行う場合を想定する。
親となり得る要素「ａ」の発生により、子候補になるセッション（ｓｅ１）上の要素を監視するため、まず系列分割情報Ｃが初期化される。また第１の更新処理の（α）で示される動作定義に従って、適合系列情報Σと親子候補情報Ｒとが初期化される。
〔第５−２の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「φ（除外要素）」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｂ」とする。すると系列分割情報Ｃの最後に、系列要素「ｂ」が追加される。
ここで、系列要素「ｂ」は除外要素であるが、要素「ａ」の子となり得る最初の要素なので、系列要素「ｂ」から子になり得ることが記録される。すなわち第４の更新処理の（ι）で示される動作定義に従って、親となり得る要素「ａ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｂ，⊥，０＞」に更新される。
〔第５−３の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｒ１」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｃ」とする。すると系列分割情報Ｃの最後に、系列要素「ｃ」が追加される。
また、「Ｒ１」のイベントの呼び出しは、モデル「ｍ１」の系列の先頭の要素に適合している。そこで、第４の更新処理の（ι）で示される動作定義に従って、親となり得る要素「ａ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｂ，ｃ，１＞」に更新される。
〔第５−４の状態〕最後に、ＤＢサーバ２４４からアプリケーションサーバ２４２への親となり得る要素「ａ」のレスポンスメッセージが検出されたものとする。この場合、セッション（ｓｅ１）上の要素がモデル（ｍ１）の系列に適合している。このとき、系列を生成するための境界の位置としては、系列要素「ｂ」の前と後との両方が考えられる。図２８の例では、系列要素「ｂ」の前の時間間隔の方が、系列要素「ｂ」と「ｃ」との間より大きい。そこで、系列要素「ｂ」の前を境界として、系列３０６が生成される。そして、要素「ａ」と系列３０６との関係が親子候補に設定される。すなわち、第２の更新処理の（β）で示される動作定義に従って、親子候補情報Ｒが「Ｒ（ａ）（ｍ１）（ｓｅ１）：＝｛［［ｂ，ｃ］］｝」に更新される。ここで、〔第５−４の状態〕では、親子候補情報Ｒの更新状況を示しているが、系列化部１５０は、系列分割情報Ｃについても、系列要素「ｂ」，「ｃ」を１つの系列３０６とするように更新することができる。
次に、第２の実施の形態における系列化の第６の例について、図２９、図３０を参照して説明する。
図２９は、第２の実施の形態における系列化の第６の例の前半を示す図である。第６の例は、除外要素を含むデータに複数個の親がある場合の例である。第６の例では、名前が「Ｉ１」の要素に適用されるモデル「ｍ１」では、呼び出し先として系列「Ｒ１」が設定されている。また、名前が「Ｉ２」の要素に適用されるモデル「ｍ２」では、呼び出し先として系列「Ｒ１，Ｒ２」が設定されている。
〔第６−１の状態〕まず、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｉ１」の２つのリクエストメッセージが検出されたものとする。このリクエストメッセージに応じたイベントを示す要素を、それぞれ「ａ」、「ｂ」とする。このときアプリケーションサーバ２４２とＤＢサーバ２４４との間のセッション（ｓｅ１）上の処理列の系列化を行う場合を想定する。
親となり得る要素「ａ」、「ｂ」の発生により、セッション（ｓｅ１）上の子となり得る要素を監視するため、まず系列分割情報Ｃが初期化される。また第１の更新処理の（α）で示される動作定義に従って、親となり得る要素「ａ」、「ｂ」ごとに、適合系列情報Σと親子候補情報Ｒとが初期化される。
〔第６−２の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「φ（除外要素）」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｃ」とする。すると系列分割情報Ｃの最後に、系列要素「ｃ」が追加される。
ここで、系列要素「ｃ」は除外要素であるが、要素「ａ」、「ｂ」それぞれの子となり得る最初の要素なので、系列要素「ｃ」から子になり得ることが記録される。すなわち第４の更新処理の（θ）で示される動作定義に従って、親となり得る要素「ａ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｃ，⊥，０＞」に更新される。同様に、親となり得る要素「ｂ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ｂ）（ｍ２）：＝＜ｃ，⊥，０＞」に更新される。
〔第６−３の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｒ１」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｄ」とする。すると系列分割情報Ｃの最後に、系列要素「ｄ」が追加される。
また、「Ｒ１」のイベントの呼び出しは、モデル「ｍ１」の系列の先頭の要素に適合している。そこで、第４の更新処理の（κ）で示される動作定義に従って、親となり得る要素「ａ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｃ，ｄ，１＞」に更新される。同様に、親となり得る要素「ｂ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ｂ）（ｍ２）：＝＜ｃ，ｄ，１＞」に更新される。
〔第６−４の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「φ（除外要素）」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｅ」とする。すると系列分割情報Ｃの最後に、系列要素「ｅ」が追加される。ここで、検出した系列要素が除外要素であるため、第４の更新処理の（ν）で示される動作定義に従い、適合系列情報Σについては更新されない。
図３０は、第２の実施の形態における系列化の第６の例の後半を示す図である。
〔第６−５の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「Ｒ２」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｆ」とする。すると系列分割情報Ｃの最後に、系列要素「ｆ」が追加される。
ここで、系列要素「ｆ」は名前が「Ｒ２」であり、モデル「ｍ１」に適合しない。ただし、系列要素「ｅ」までの系列がモデル「ｍ１」に適合する。そこで、分割に適切な位置を判断し、その位置を境界として系列が分割される。図３０の例では、系列の先頭の位置については、時間間隔が最大の位置が調べられ、系列要素「ｃ」の前の位置が境界とされる。系列の最後の境界は、系列要素「ｅ」の前または後のうち、時間間隔が最大の位置となる。図３０の例では、系列要素「ｅ」の後が境界とされる。決定された前後の境界で分割することで、系列３０７が生成される。具体的には、第４の更新処理の（ι）で示す動作定義に基づいて、系列分割情報Ｃが「Ｃ［ｓｅ１］：＝［…，［…］，［ｃ，ｄ，ｅ］，［ｆ］］」に更新される。また、親となり得る要素「ａ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜⊥，⊥，０＞」に初期化される。
生成された系列３０７は、親となり得る要素「ａ」との間に、親子候補の関係が設定される。すなわち、親子関係情報Ｒが「Ｒ（ａ）（ｍ１）（ｓｅ１）：＝［［ｃ，ｄ，ｅ］］」に変更される。
なお、系列要素「ｆ」は、モデル「ｍ２」には適合している。そこで第４の更新処理の（κ）で示される処理に従って、親となり得る要素「ｂ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ｂ）（ｍ２）：＝＜ｃ，ｄ，２＞」に更新される。
〔第６−６の状態〕次に、アプリケーションサーバ２４２からＤＢサーバ２４４への「φ（除外要素）」のリクエストメッセージと、そのリクエストメッセージに対応するレスポンスメッセージとが検出されたものとする。ここで、検出されたメッセージに応じたイベントを示す系列要素を「ｇ」とする。すると系列分割情報Ｃの最後に、系列要素「ｇ」が追加される。
ここで、系列要素「ｇ」は除外要素であるが、要素「ａ」の子となり得る最初の要素なので、系列要素「ｇ」から子になり得ることが記録される。すなわち第４の更新処理の（θ）で示される動作定義に従って、親となり得る要素「ａ」に対応する適合系列情報Σが「Σ（ｓｅ１）（ａ）（ｍ１）：＝＜ｇ，⊥，０＞」に更新される。
〔第６−７の状態〕ＤＢサーバ２４４からアプリケーションサーバ２４２への親となり得る要素「ａ」のレスポンスメッセージが検出されたものとする。この場合、モデル「ｍ１」の系列全体に適合するセッション「ｓｅ１」上の系列がない。そのため第２の更新処理の（δ）に示す動作定義に基づき、親子関係情報Σや系列分割情報Ｃの更新は行われない。ただし、親となり得る要素「ａ」の適合系列情報Σは値が削除される。すなわち、「Σ（ａ）（ｓｅ１）（ｍ１）：＝⊥」に変更される。
〔第６−８の状態〕最後に、ＤＢサーバ２４４からアプリケーションサーバ２４２への親となり得る要素「ｂ」のレスポンスメッセージが検出されたものとする。この場合、先に生成されている系列３０７と系列３０８との組み合わせで、モデル「ｍ２」に適合する。そこで、第２の更新処理の（β）で示す動作定義に従って、親となり得る要素「ｂ」の親子関係情報Ｒが「Ｒ（ｂ）（ｍ２）（ｓｅ１）：＝［［ｃ，ｄ，ｅ］，［ｆ，ｇ］］」に更新される。
以上のようにして、セッションごとの系列化と、親となり得る要素と系列との間の親子候補の設定とが行われる。各セッションの系列分割情報は系列記憶部１６０に格納され、親子候補を示す親子候補情報は親子候補記憶部１８０に格納される。
図３１は、系列記憶部のデータ構造例を示す図である。系列記憶部１６０には、セッションごとの系列分割情報１６１，１６２，１６３，・・・が格納される。
図３２は、親子候補記憶部のデータ構造例を示す図である。親子候補記憶部１８０には、親となり得る要素、その要素に適用されるモデル、およびセッションの組に対応する親子候補情報１８１，１８２，１８３，・・・が格納される。
以上のように、第２の実施の形態では、モデルにあうかどうかを考慮しながら系列の分割を行う。そのため、モデルに適合するイベント列を含みながら、モデルに適合しなくなるほど長い系列を作成することがなくなる。
〔その他の応用例〕
第２の実施の形態では、スイッチ２３２〜２３４におけるポートミラーリング機能を用いてパケットを収集しているが、各サーバが受信したパケットを分析装置１００に転送するようにしてもよい。
また第２の実施の形態では、図１０に示すように３階層のトランザクションのモデルからアプリケーションサーバ２４２とＤＢサーバ２４４とのイベントに関する部分のみを抽出して利用している。しかし、アプリケーションサーバ２４２とＤＢサーバ２４４とのイベントの呼び出し関係のみを示すモデルを予め作成しておき、モデル記憶部１４０に格納しておいてもよい。
上記の処理機能は、コンピュータによって実現することができる。その場合、分析装置が有すべき機能の処理内容を記述した系列生成プログラムが提供される。その系列生成プログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述した系列生成プログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disc）などがある。
系列生成プログラムを流通させる場合には、例えば、その系列生成プログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、系列生成プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにその系列生成プログラムを転送することもできる。
系列生成プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録された系列生成プログラムもしくはサーバコンピュータから転送された系列生成プログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置から系列生成プログラムを読み取り、系列生成プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接系列生成プログラムを読み取り、その系列生成プログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータから系列生成プログラムが転送されるごとに、逐次、受け取った系列生成プログラムに従った処理を実行することもできる。
また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現することもできる。
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
以上の実施の形態に開示された技術には、以下の付記に示す技術が含まれる。
（付記１） コンピュータに、
第１の装置と第２の装置が通信したメッセージに基づいて、前記第１の装置と前記第２の装置とのそれぞれで実行された処理を判別し、
前記第１の装置で実行される処理と前記第２の装置で実行される処理との間で発生し得る呼び出し関係を定義したモデルを記憶する記憶手段を参照し、前記第１の装置で実行された処理の実行時間内に前記第２の装置で実行された処理の配列である呼び出し可能処理列から、前記第１の装置で実行された処理を呼び出し元とするモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列を含み、呼び出し先となり得ない処理を除外した系列を生成する、
処理を実行させる系列生成プログラム。
（付記２） 系列を生成する際には、前記第１の装置で実行された第１の処理を呼び出し元とする第１のモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列と、前記第１の装置で実行された第２の処理を呼び出し元とする第２のモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列とが一部重複する場合、少なくとも重複する処理列を含み、前記第１のモデルと前記第２のモデルのいずれかにおいて呼び出し先となり得ない処理を除外した系列を生成する、
ことを特徴とする付記１記載の系列生成プログラム。
（付記３） モデルとの照合対象としない処理が除外要素として定義され、モデルとの照合対象とする処理が非除外要素と定義されており、
系列の生成の際には、前記呼び出し可能処理列において、モデルとの照合の結果、呼び出し先となり得ると判定された非除外要素と呼び出し先となり得ないと判定された非除外要素との間に少なくとも１つの除外要素が存在する場合、いずれかの除外要素の前後の位置を、系列の境界とする、
ことを特徴とする付記１または２のいずれかに記載の系列生成プログラム。
（付記４） 呼び出し先となり得ると判定された非除外要素と呼び出し先となり得ないと判定された非除外要素との間に存在する少なくとも１つの除外要素の前後の位置のうち、処理間の時間間隔が最も長い位置を、系列の境界とする、
ことを特徴とする付記３記載の系列生成プログラム。
（付記５） 前記第１のモデルとの関係において呼び出し先となり得ると判定された非除外要素と呼び出し先となり得ないと判定された非除外要素との間に存在する少なくとも１つの除外要素の前後の位置のうち、前記第２のモデルとの関係において既に境界と判定されている位置がある場合、既に境界と判定されている位置を、前記第１のモデルとの関係において生成される系列の境界とする、
ことを特徴とする付記３記載の系列生成プログラム。
（付記６） 前記コンピュータに、さらに、
系列に含まれる処理が同一の処理から呼び出されることを条件に、前記第１の装置で実行された処理と前記第２の装置で実行された処理との中から、モデル全体に適合する呼び出し関係となる処理の組を検出する、
処理を実行させることを特徴とする付記１乃至５のいずれかに記載の系列生成プログラム。
（付記７） 前記コンピュータに、さらに、
前記第１の装置で実行された処理を呼び出し元とするモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列を含む系列と、前記第１の装置で実行された処理との関係を、呼び出し候補に設定する、
ことを特徴とする付記１乃至５のいずれかに記載の系列生成プログラム。
（付記８） 前記コンピュータに、さらに、
呼び出し候補に設定されている処理と系列との呼び出し関係の中から、モデル全体に適合する呼び出し関係となる処理の組を検出する、
処理を実行させることを特徴とする付記７記載の系列生成プログラム。
（付記９） 処理の判別の際には、判別した処理に対して、処理に対応するメッセージの通信に使用された前記第１の装置と前記第２の装置との間のセッションの識別番号を付与し、
系列の生成の際には、同一セッションにおける処理の配列を前記呼び出し可能処理列とする、
ことを特徴とする付記１乃至８のいずれかに記載の系列生成プログラム。
（付記１０） コンピュータが、
第１の装置と第２の装置が通信したメッセージに基づいて、前記第１の装置と前記第２の装置とのそれぞれで実行された処理を判別し、
前記第１の装置で実行される処理と前記第２の装置で実行される処理との間で発生し得る呼び出し関係を定義したモデルを記憶する記憶手段を参照し、前記第１の装置で実行された処理の実行時間内に前記第２の装置で実行された処理の配列である呼び出し可能処理列から、前記第１の装置で実行された処理を呼び出し元とするモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列を含み、呼び出し先となり得ない処理を除外した系列を生成する、
ことを特徴とする系列生成方法。
（付記１１） 第１の装置と第２の装置が通信したメッセージに基づいて、前記第１の装置と前記第２の装置とのそれぞれで実行された処理を判別する処理判別手段と、
前記第１の装置で実行される処理と前記第２の装置で実行される処理との間で発生し得る呼び出し関係を定義したモデルを記憶する記憶手段を参照し、前記第１の装置で実行された処理の実行時間内に前記第２の装置で実行された処理の配列である呼び出し可能処理列から、前記第１の装置で実行された処理を呼び出し元とするモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列を含み、呼び出し先となり得ない処理を除外した系列を生成する系列化手段と、
を有する系列生成装置。
１ 系列生成装置
１ａ モデル記憶手段
１ｂ 処理判別手段
１ｃ 系列化手段
１ｄ 系列記憶手段
１ｅ 呼び出し候補判定手段
１ｆ 呼び出し候補記憶手段
２〜４ サーバ
３ａ，３ｂ，４ａ，４ｂ，４ｃ，４ｄ 処理
５ａ，５ｂ モデル
６ａ，６ｂ，６ｃ 系列情報
７ａ，７ｂ 呼び出し候補情報
８ａ，８ｂ，８ｃ，８ｄ，９ａ，９ｂ，９ｃ，９ｄ，９ｅ，９ｆ，９ｇ，９ｈ メッセージ
９ セッション

Claims (7)

  1. コンピュータに、
    第１の装置と第２の装置が通信したメッセージに基づいて、前記第１の装置と前記第２の装置とのそれぞれで実行された処理を判別し、
    前記第１の装置で実行される処理と前記第２の装置で実行される処理との間で発生し得る呼び出し関係を定義したモデルを記憶する記憶手段を参照し、前記第１の装置で実行された処理の実行時間内に前記第２の装置で実行された処理の配列である呼び出し可能処理列から、前記第１の装置で実行された処理を呼び出し元とするモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列を含み、呼び出し先となり得ない処理を除外した系列を生成する、
    処理を実行させる系列生成プログラム。
  2. 系列を生成する際には、前記第１の装置で実行された第１の処理を呼び出し元とする第１のモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列と、前記第１の装置で実行された第２の処理を呼び出し元とする第２のモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列とが一部重複する場合、少なくとも重複する処理列を含み、前記第１のモデルと前記第２のモデルのいずれかにおいて呼び出し先となり得ない処理を除外した系列を生成する、
    ことを特徴とする請求項１記載の系列生成プログラム。
  3. モデルとの照合対象としない処理が除外要素として定義され、モデルとの照合対象とする処理が非除外要素と定義されており、
    系列の生成の際には、前記呼び出し可能処理列において、モデルとの照合の結果、呼び出し先となり得ると判定された非除外要素と呼び出し先となり得ないと判定された非除外要素との間に少なくとも１つの除外要素が存在する場合、いずれかの除外要素の前後の位置を、系列の境界とする、
    ことを特徴とする請求項１または２のいずれかに記載の系列生成プログラム。
  4. 呼び出し先となり得ると判定された非除外要素と呼び出し先となり得ないと判定された非除外要素との間に存在する少なくとも１つの除外要素の前後の位置のうち、処理間の時間間隔が最も長い位置を、系列の境界とする、
    ことを特徴とする請求項３記載の系列生成プログラム。
  5. 前記コンピュータに、さらに、
    前記第１の装置で実行された処理を呼び出し元とするモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列を含む系列と、前記第１の装置で実行された処理との関係を、呼び出し候補に設定する、
    ことを特徴とする請求項１乃至４のいずれかに記載の系列生成プログラム。
  6. コンピュータが、
    第１の装置と第２の装置が通信したメッセージに基づいて、前記第１の装置と前記第２の装置とのそれぞれで実行された処理を判別し、
    前記第１の装置で実行される処理と前記第２の装置で実行される処理との間で発生し得る呼び出し関係を定義したモデルを記憶する記憶手段を参照し、前記第１の装置で実行された処理の実行時間内に前記第２の装置で実行された処理の配列である呼び出し可能処理列から、前記第１の装置で実行された処理を呼び出し元とするモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列を含み、呼び出し先となり得ない処理を除外した系列を生成する、
    ことを特徴とする系列生成方法。
  7. 第１の装置と第２の装置が通信したメッセージに基づいて、前記第１の装置と前記第２の装置とのそれぞれで実行された処理を判別する処理判別手段と、
    前記第１の装置で実行される処理と前記第２の装置で実行される処理との間で発生し得る呼び出し関係を定義したモデルを記憶する記憶手段を参照し、前記第１の装置で実行された処理の実行時間内に前記第２の装置で実行された処理の配列である呼び出し可能処理列から、前記第１の装置で実行された処理を呼び出し元とするモデルにおいて呼び出し先として定義された処理列に少なくとも部分一致する処理列を含み、呼び出し先となり得ない処理を除外した系列を生成する系列化手段と、
    を有する系列生成装置。
JP2010018088A 2010-01-29 2010-01-29 系列生成プログラム、系列生成方法、および系列生成装置 Expired - Fee Related JP5482243B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2010018088A JP5482243B2 (ja) 2010-01-29 2010-01-29 系列生成プログラム、系列生成方法、および系列生成装置
US13/016,738 US8677364B2 (en) 2010-01-29 2011-01-28 Computer program, method, and apparatus for grouping tasks into series

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010018088A JP5482243B2 (ja) 2010-01-29 2010-01-29 系列生成プログラム、系列生成方法、および系列生成装置

Publications (2)

Publication Number Publication Date
JP2011158969A JP2011158969A (ja) 2011-08-18
JP5482243B2 true JP5482243B2 (ja) 2014-05-07

Family

ID=44342765

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010018088A Expired - Fee Related JP5482243B2 (ja) 2010-01-29 2010-01-29 系列生成プログラム、系列生成方法、および系列生成装置

Country Status (2)

Country Link
US (1) US8677364B2 (ja)
JP (1) JP5482243B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5751336B2 (ja) * 2011-10-18 2015-07-22 富士通株式会社 情報処理装置、時刻補正値決定方法、およびプログラム
US9282124B2 (en) * 2013-03-14 2016-03-08 Twilio, Inc. System and method for integrating session initiation protocol communication in a telecommunications platform
JP5676676B2 (ja) 2013-04-08 2015-02-25 株式会社スクウェア・エニックス ビデオゲーム処理装置、及びビデオゲーム処理プログラム
JP6303300B2 (ja) * 2013-06-25 2018-04-04 富士通株式会社 制御依頼方法、情報処理装置、システム、およびプログラム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5781449A (en) * 1995-08-10 1998-07-14 Advanced System Technologies, Inc. Response time measurement apparatus and method
US6226678B1 (en) * 1995-09-25 2001-05-01 Netspeak Corporation Method and apparatus for dynamically defining data communication utilities
US20010044821A1 (en) * 2000-05-17 2001-11-22 Picoapp. Inc. Distributed data processing system for use with limited function computing devices
JP2003308229A (ja) 2002-04-17 2003-10-31 Nippon Telegr & Teleph Corp <Ntt> 時系列イベント記録解析方法及び装置並びにプログラム及び記録媒体
JP4093483B2 (ja) * 2003-12-26 2008-06-04 インターナショナル・ビジネス・マシーンズ・コーポレーション 解析システム、解析方法、解析プログラム、及び記録媒体
JP4610240B2 (ja) * 2004-06-24 2011-01-12 富士通株式会社 分析プログラム、分析方法及び分析装置
JP4549231B2 (ja) * 2005-05-17 2010-09-22 富士通株式会社 サービス処理状況分析プログラム、サービス処理状況分析方法、およびサービス処理状況分析装置
JP5035068B2 (ja) * 2008-03-28 2012-09-26 富士通株式会社 サービス処理状況分析プログラム、サービス処理状況分析装置、およびサービス処理状況分析方法
US20100017486A1 (en) * 2008-07-16 2010-01-21 Fujitsu Limited System analyzing program, system analyzing apparatus, and system analyzing method
JP5200775B2 (ja) 2008-09-04 2013-06-05 富士通株式会社 イベントデータ分割処理プログラム，装置および方法
US8670546B2 (en) * 2008-10-22 2014-03-11 At&T Intellectual Property I, L.P. Systems and methods for providing a personalized communication processing service
JP5422989B2 (ja) 2008-12-17 2014-02-19 富士通株式会社 トランザクションモデル生成支援プログラム、トランザクションモデル生成支援装置、およびトランザクションモデル生成支援方法

Also Published As

Publication number Publication date
US8677364B2 (en) 2014-03-18
JP2011158969A (ja) 2011-08-18
US20110191778A1 (en) 2011-08-04

Similar Documents

Publication Publication Date Title
US11244247B2 (en) Facilitating concurrent forecasting of multiple time series
US11651149B1 (en) Event selection via graphical user interface control
US10685279B2 (en) Automatically generating field extraction recommendations
US11775501B2 (en) Trace and span sampling and analysis for instrumented software
JP4738885B2 (ja) グラフ分析および同期の方法およびシステム
US20170220672A1 (en) Enhancing time series prediction
US11194794B2 (en) Search input recommendations
CN110928772A (zh) 一种测试方法及装置
US11188600B2 (en) Facilitating metric forecasting via a graphical user interface
US20100058118A1 (en) Storage medium recording information reacquisition procedure generation program and information reacquisition procedure generation apparatus
JP2018088242A (ja) データ処理装置、方法およびプログラム
JP2011138422A (ja) 行動パターン検出装置、行動パターン検出方法及び行動パターン検出プログラム
JP5482243B2 (ja) 系列生成プログラム、系列生成方法、および系列生成装置
JP2016100005A (ja) リコンサイル方法、プロセッサ及び記憶媒体
JP2020135207A (ja) 経路探索方法、経路探索プログラム、経路探索装置および経路探索のデータ構造
JP5422989B2 (ja) トランザクションモデル生成支援プログラム、トランザクションモデル生成支援装置、およびトランザクションモデル生成支援方法
US20060149731A1 (en) System and method for deriving affinity relationships between objects
JP4059970B2 (ja) 情報源推薦装置
US11762869B1 (en) Generating journey flow visualization with node placement based on shortest distance to journey start
CN110262870A (zh) 利用dump文件定位异常的方法、装置、计算机设备及存储介质
JP2010097285A (ja) システム分析支援プログラム、システム分析支援装置、およびシステム分析支援方法
JP2010049324A (ja) システム分析プログラム、システム分析装置、システム分析方法
JP2007073072A (ja) 関連文書表示装置
WO2019008394A1 (en) CAPTURE AND EXTRACTION OF DIGITAL INFORMATION
US11402979B1 (en) Interactive expandable histogram timeline module for security flagged events

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20121005

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20131030

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20131112

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131227

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140121

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140203

R150 Certificate of patent or registration of utility model

Ref document number: 5482243

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees