画像形成装置、情報処理方法、情報処理プログラム、及び記録媒体
【課題】アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを備える画像形成装置を実現する。
【解決手段】アプリケーションにサービスを提供し互いに排他的に動作する複数のモジュールの接続によって構成されるサービス提供プログラムを備える画像形成装置であって、前記サービス提供プログラムの変更情報の入力を受け付ける入力手段と、前記サービス提供プログラムの動作状態が、前記変更情報において指定されている変更のタイミングに相当するか否かを判定するタイミング判定手段と、前記タイミング判定手段によって前記変更のタイミングであると判定されたときに、前記変更情報に従って、前記複数のモジュールの接続関係を変更する変更手段と、前記変更が施された前記サービス提供プログラムを前記アプリケーションに利用させるためのインタフェースを追加するインタフェース追加手段とを有することにより上記課題を解決する。
【解決手段】アプリケーションにサービスを提供し互いに排他的に動作する複数のモジュールの接続によって構成されるサービス提供プログラムを備える画像形成装置であって、前記サービス提供プログラムの変更情報の入力を受け付ける入力手段と、前記サービス提供プログラムの動作状態が、前記変更情報において指定されている変更のタイミングに相当するか否かを判定するタイミング判定手段と、前記タイミング判定手段によって前記変更のタイミングであると判定されたときに、前記変更情報に従って、前記複数のモジュールの接続関係を変更する変更手段と、前記変更が施された前記サービス提供プログラムを前記アプリケーションに利用させるためのインタフェースを追加するインタフェース追加手段とを有することにより上記課題を解決する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コピー／プリンタ／スキャナ／ファクシミリ／複合機／融合機等の画像形成装置、情報処理方法、情報処理プログラム、ＳＤメモリカード等の記録媒体に関する。
【背景技術】
【０００２】
近年、コピー機能とプリンタ機能とスキャナ機能とファクシミリ機能を備える複合機や融合機が市販されるようになった。複合機や融合機は、コピーやプリンタとして機能する場合には、画像を印刷用紙に印刷することになり、コピーやスキャナとして機能する場合には、画像を読取原稿から読み取ることになり、ファクシミリとして機能する場合には、画像を電話回線を介して他の機器と授受することになる。
【特許文献１】特開２００２−８４３８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
近年、複合機や融合機には様々なアプリケーションやプラットフォームが実装される。そんな中で問題視されるのが、次々に登場する新規なアプリケーションに既存のプラットフォームが対応し切れなくなるのではないかと言う点である。プラットフォームの設計時において、随時開発されるアプリケーション同士の差異を考慮したり将来開発される種々のアプリケーションの機能を予測したりするのは非常に困難である。従って、アプリケーションの種類によってはプラットフォームの影響で正常に動作しない可能性も出て来る。従って、アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを実現する事が望まれる。
【０００４】
本発明は、アプリケーションやプラットフォームが実装される画像形成装置に関して、アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを実現することを課題とする。
【課題を解決するための手段】
【０００５】
そこで上記課題を解決するため、本発明は、アプリケーションにサービスを提供し互いに排他的に動作する複数のモジュールの接続によって構成されるサービス提供プログラムを備える画像形成装置であって、前記サービス提供プログラムの変更情報の入力を受け付ける入力手段と、前記サービス提供プログラムの動作状態が、前記変更情報において指定されている変更のタイミングに相当するか否かを判定するタイミング判定手段と、前記タイミング判定手段によって前記変更のタイミングであると判定されたときに、前記変更情報に従って、前記複数のモジュールの接続関係を変更する変更手段と、前記変更が施された前記サービス提供プログラムを前記アプリケーションに利用させるためのインタフェースを追加するインタフェース追加手段とを有することを特徴とする。
【０００６】
このような画像形成装置では、アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを実現することができる。
【発明の効果】
【０００７】
本発明は、アプリケーションやプラットフォームが実装される画像形成装置に関して、アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを実現するものである。
【発明を実施するための最良の形態】
【０００８】
図１は、本発明の実施例に該当する融合機１０１を表す。図１の融合機１０１は、種々のハードウェア１１１と、種々のソフトウェア１１２と、融合機起動部１１３により構成される。
【０００９】
融合機１０１のハードウェア１１１としては、撮像部１２１と、印刷部１２２と、その他のハードウェア１２３が存在する。撮像部１２１は、読取原稿から画像（画像データ）を読み取るためのハードウェアである。印刷部１２２は、画像（画像データ）を印刷用紙に印刷するためのハードウェアである。
【００１０】
融合機１０１のソフトウェア１１２としては、種々のアプリケーション１３１と、種々のプラットフォーム１３２が存在する。これらのプログラムは、ＵＮＩＸ（登録商標）等のＯＳ（オペレーティングシステム）によりプロセス単位で並列的に実行される。
【００１１】
アプリケーション１３１としては、コピー用のアプリケーションであるコピーアプリ１４１、プリンタ用のアプリケーションであるプリンタアプリ１４２、スキャナ用のアプリケーションであるスキャナアプリ１４３、ファクシミリ用のアプリケーションであるファクシミリアプリ１４４、ネットワークファイル用のアプリケーションであるネットワークファイルアプリ１４５が存在する。
【００１２】
アプリケーション１３１は、専用のＳＤＫ（ソフトウェア開発キット）を使用して開発することができる。ＳＤＫを使用して開発したアプリケーション１３１をＳＤＫアプリと呼ぶ。専用のＳＤＫとしては、Ｃ言語でアプリケーション１３１を開発するための「ＣＳＤＫ」や、Ｊａｖａ（登録商標）言語でアプリケーション１３１を開発するための「ＪＳＤＫ」が提供される。ＣＳＤＫを使用して開発したアプリケーション１３１を「ＣＳＤＫアプリ」と呼び、ＪＳＤＫを使用して開発したアプリケーション１３１を「ＪＳＤＫアプリ」と呼ぶ。図１の融合機１０１にも、ＣＳＤＫアプリ１４６と、ＪＳＤＫアプリ１４７が存在する。図１の融合機１０１にはさらに、Ｊａｖａ（登録商標）言語で記述されたＪＳＤＫアプリ１４７とＣ言語で記述された他のソフトウェア１１２との仲介を行うソフトウェア１１２として、ＪＳＤＫプラットフォーム１４８が存在する。
【００１３】
プラットフォーム１３２としては、種々のコントロールサービス１５１、システムリソースマネージャ１５２、種々のハンドラ１５３が存在する。コントロールサービス１５１としては、ネットワークコントロールサービス（ＮＣＳ）１６１、ファクシミリコントロールサービス（ＦＣＳ）１６２、デリバリコントロールサービス（ＤＣＳ）１６３、エンジンコントロールサービス（ＥＣＳ）１６４、メモリコントロールサービス（ＭＣＳ）１６５、オペレーションパネルコントロールサービス（ＯＣＳ）１６６、サーティフィケーションコントロールサービス（ＣＣＳ）１６７、ユーザディレクトリコントロールサービス（ＵＣＳ）１６８、システムコントロールサービス（ＳＣＳ）１６９が存在する。ハンドラ１５３としては、ファクシミリコントロールユニットハンドラ（ＦＣＵＨ）１７１、イメージメモリハンドラ（ＩＭＨ）１７２が存在する。
【００１４】
ＮＣＳ１６１のプロセスは、ネットワーク通信の仲介を行う。ＦＣＳ１６２のプロセスは、ファクシミリのＡＰＩを提供する。ＤＣＳ１６３のプロセスは、蓄積文書の配信処理に関する制御を行う。ＥＣＳ１６４のプロセスは、撮像部１２１や印刷部１２２に関する制御を行う。ＭＣＳ１６５のプロセスは、メモリやハードディスクドライブに関する制御を行う。ＯＣＳ１６６のプロセスは、オペレーションパネルに関する制御を行う。ＣＣＳ１６７のプロセスは、認証処理や課金処理に関する制御を行う。ＵＣＳ１６８のプロセスは、ユーザ情報の管理に関する制御を行う。ＳＣＳ１６９のプロセスは、システムの管理に関する制御を行う。
【００１５】
アプリケーション１３１とプラットフォーム１３２の仲介を行うソフトウェア１１２として、仮想アプリケーションサービス（ＶＡＳ）１３５が存在する。ＶＡＳ１３５は、アプリケーション１３１をクライアントとするサーバプロセスとして動作すると共に、プラットフォーム１３２をサーバとするクライアントプロセスとして動作する。ＶＡＳ１３５は、アプリケーション１３１から見てプラットフォーム１３２を隠蔽するラッピング機能を備え、プラットフォーム１３２のバージョンアップに伴うバージョン差を吸収する役割等を担う。
【００１６】
融合機起動部１１３は、融合機１０１の電源投入時に最初に実行される。これにより、ＵＮＩＸ（登録商標）等のＯＳが起動され、アプリケーション１３１やプラットフォーム１３２が起動される。これらのプログラムは、ハードディスクドライブやメモリカードに蓄積されており、ハードディスクドライブやメモリカードから再生されて、メモリに起動されることになる。
【００１７】
図２は、図１の融合機１０１に係るハードウェア構成図である。融合機１０１のハードウェア１１１としては、コントローラ２０１と、オペレーションパネル２０２と、ファクシミリコントロールユニット（ＦＣＵ）２０３と、撮像部１２１と、印刷部１２２が存在する。
【００１８】
コントローラ２０１は、ＣＰＵ２１１、ＡＳＩＣ２１２、ＮＢ２２１、ＳＢ２２２、ＭＥＭ−Ｐ２３１、ＭＥＭ−Ｃ２３２、ＨＤＤ（ハードディスクドライブ）２３３、メモリカードスロット２３４、ＮＩＣ（ネットワークインタフェースコントローラ）２４１、ＵＳＢデバイス２４２、ＩＥＥＥ１３９４デバイス２４３、セントロニクスデバイス２４４により構成される。
【００１９】
ＣＰＵ２１１は、種々の情報処理用のＩＣである。ＡＳＩＣ２１２は、種々の画像処理用のＩＣである。ＮＢ２２１は、コントローラ２０１のノースブリッジである。ＳＢ２２２は、コントローラ２０１のサウスブリッジである。ＭＥＭ−Ｐ２３１は、融合機１０１のシステムメモリである。ＭＥＭ−Ｃ２３２は、融合機１０１のローカルメモリである。ＨＤＤ２３３は、融合機１０１のストレージである。メモリカードスロット２３４は、メモリカード２３５をセットするためのスロットである。ＮＩＣ２４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス２４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。セントロニクスデバイス２４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。
【００２０】
オペレーションパネル２０２は、オペレータが融合機１０１に入力を行うためのハードウェア（操作部）であると共に、オペレータが融合機１０１から出力を得るためのハードウェア（表示部）である。
【００２１】
図３は、図１の融合機１０１に係る外観図である。図３には、撮像部１２１の位置と、印刷部１２２の位置と、オペレーションパネル２０２の位置が図示されている。図３には更に、読取原稿のセット先となる原稿セット部３０１と、印刷用紙の給紙先となる給紙部３０２と、印刷用紙の排紙先となる排紙部３０３が図示されている。
【００２２】
オペレーションパネル２０２は、図４のように、タッチパネル３１１と、テンキー３１２と、スタートボタン３１３と、リセットボタン３１４と、機能キー３１５と、初期設定ボタン３１６により構成される。タッチパネル３１１は、タッチ操作で入力を行うためのハードウェア（タッチ操作部）であると共に、画面表示で出力を得るためのハードウェア（画面表示部）である。テンキー３１２は、キー（ボタン）操作で数字入力を行うためのハードウェアである。スタートボタン３１３は、ボタン操作でスタート操作を行うためのハードウェアである。リセットボタン３１４は、ボタン操作でリセット操作を行うためのハードウェアである。機能キー３１５は、キー（ボタン）操作でＣＳＤＫアプリ１４６やＪＳＤＫアプリ１４７による操作画面を表示させるためのハードウェアである。初期設定ボタン３１６は、ボタン操作で初期設定画面を表示させるためのハードウェアである。
【００２３】
原稿セット部３０１は、ＡＤＦ（自動原稿搬送装置）３２１と、フラットベッド３２２と、フラットベッドカバー３２３により構成される。給紙部３０２は、４個の給紙トレイにより構成される。排紙部３０３は、１個の排紙トレイにより構成される。
【００２４】
（ＣＳＤＫ／ＪＳＤＫ／ＯＳＧｉ）
図５は、図１のＣＳＤＫアプリ１４６とＪＳＤＫアプリ１４７のソフトウェア構成図である。ＣＳＤＫアプリ１４６は、Ｃ言語のアプリケーションであり、それぞれプロセスとして実行される事になる。ＪＳＤＫアプリ１４７は、Ｊａｖａ（登録商標）言語のアプリケーションであり、それぞれスレッドとして実行される事になる。
【００２５】
図１の融合機１０１には、ＣＳＤＫアプリ１４６として、他のＣＳＤＫアプリ１４６の制御を行うＳＡＳ（ＳＤＫアプリケーションサービス）４１１が存在し、ＪＳＤＫアプリ１４７として、他のＪＳＤＫアプリ１４７の制御を行うＳＡＳ Ｍａｎａｇｅｒ（ＳＤＫアプリケーションサービスマネージャ）５１１が存在する。ＣＳＤＫアプリ１４６の方はプロセスとして実行されてＪＳＤＫアプリ１４７の方はスレッドとして実行されるので、ＣＳＤＫアプリ１４６用のアプリケーション管理機構とＪＳＤＫアプリ１４７用のアプリケーション管理機構が別個に存在するのである。ＳＡＳ４１１とＳＡＳ Ｍａｎａｇｅｒ５１１はそれぞれ、ＣＳＤＫアプリ１４６とＪＳＤＫアプリ１４７の起動制御，起動解除制御，インストール制御，アンインストール制御，アップデート制御等を行う。
【００２６】
さて、ＳＡＳ４１１は、ＣＳＤＫアプリ１４６の制御を行う事ができるだけではなく、ＳＡＳ Ｍａｎａｇｅｒ５１１を介してＪＳＤＫアプリ１４７の制御を行う事もできる。ＳＡＳ４１１は、ＣＳＤＫアプリ１４６については直接的にその制御を行う事ができると共に、ＪＳＤＫアプリ１４７についてはＳＡＳ Ｍａｎａｇｅｒ５１１を介して間接的にその制御を行う事ができるのである。このように、ＣＳＤＫアプリ１４６用のアプリケーション管理機構とＪＳＤＫアプリ１４７用のアプリケーション管理機構は、ＳＡＳ Ｍａｎａｇｅｒ５１１を制御できる機能をＳＡＳ４１１に具備させると言う形で統合的に構成されている。融合機１０１のソフトウェアの根幹部分はＣ言語によるので、ＳＤＫアプリを制御する機能を同じくＣ言語によるＳＡＳ４１１に集中しておくのが好適なのである。
【００２７】
図６は、図１の融合機１０１におけるＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）サービスプラットフォームについて説明するための図である。ＯＳＧｉサービスプラットフォームは、ＯＳＧｉアライアンスによる標準化技術であり、Ｊａｖａ（登録商標）言語に基づいたオープンなソフトウェア部品化技術である。ＯＳＧｉサービスプラットフォームが実装された機器では、Ｊａｖａ（登録商標）言語のソフトウェアは「バンドル」と言うソフトウェア部品の形で実装される。そして、該機器の諸機能はバンドルをもって構成する事ができると共に、該機器の諸機能のアップデートやカスタマイズやメンテナンスはバンドルのダウンロードをもって実現する事ができる。
【００２８】
図１の融合機１０１には、Ｊａｖａ（登録商標）言語のソフトウェアとして、ＪＳＤＫアプリ１４７と、ＪＳＤＫプラットフォーム１４８と、ＯＳＧｉ用のアプリケーションであるＯＳＧｉアプリ４０１と、ＯＳＧｉ用のサービスであるＯＳＧｉサービス４０２と、バンドルの管理（バンドルのライフサイクルやデータの管理等）を行うＯＳＧｉフレームワーク４０３が存在する。
【００２９】
図１の融合機１０１にはさらには、他機のＯＳＧｉサービスプラットフォームを自機のＯＳＧｉサービスプラットフォームと同様に処理するためのＣＳＣ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｃｏｎｃｉｅｒｇｅ）４２１と、Ｊａｖａ（登録商標）言語のソフトウェアを実行するためのＣＶＭ（Ｃｏｍｐａｃｔ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）５５５が存在する。
【００３０】
さて、ＯＳＧｉアプリ４０１とＪＳＤＫアプリ１４７に関して、ＯＳＧｉアプリ４０１はバンドル化された状態で融合機１０１に実装するものとするが、ＪＳＤＫアプリ１４７はバンドル化されていない状態で融合機１０１に実装するものとする。理由は、ＪＳＤＫアプリ１４７をバンドル化して実装する負担をＪＳＤＫアプリ１４７のベンダに課さないようにするためである。その代わり、ＪＳＤＫアプリ１４７をバンドル化する「Ｂｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ４０４」がＪＳＤＫプラットフォーム１４８に存在している。そして、ＯＳＧｉフレームワーク４０３は、バンドル化された状態で融合機１０１に実装されたバンドル（ＯＳＧｉアプリ４０１）の管理を行うと共に、バンドル化されていない状態で融合機１０１に実装されて「Ｂｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ４０４」によってバンドル化されるバンドル（ＪＳＤＫアプリ１４７）の管理を行う事になる。このようにして、ＯＳＧｉアプリ４０１用のアプリケーション管理機構とＪＳＤＫアプリ１４７用のアプリケーション管理機構は、ＯＳＧｉフレームワーク４０３とＢｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ４０４を併設すると言う形で統合的に構成されているのである。これにより、Ｊａｖａ（登録商標）言語のアプリケーションの管理先の一元化が実現されている。
【００３１】
なお、ＯＳＧｉフレームワーク４０３は、当然の事ながら、ＯＳＧｉサービス４０２を構成するバンドルの管理や、ＪＳＤＫプラットフォーム１４８を構成するバンドルの管理も行う。Ｊａｖａ（登録商標）言語のソフトウェアの管理先の一元化が実現されていると言える。そして、ＯＳＧｉアプリ４０１はここではＳｅｒｖｌｅｔかＪＳＰであるものとする。そして、ＪＳＤＫアプリ１４７はここではＸｌｅｔであるものとする。
【００３２】
なお、ＪＳＤＫアプリ１４７についても、バンドル化された状態で実装するものとしてもよい。さらに、ＪＳＤＫアプリ１４７については、バンドル化された状態で実装してもバンドル化されていない状態で実装してもどちらでもよいものとしてもよい。バンドル化された状態で実装されるＪＳＤＫアプリ１４７については、Ｂｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ４０４によるバンドル化は不要である。
【００３３】
（ＪＳＤＫ）
図７は、図１のＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８のクラス図である。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は、全体で１プロセスとして、同一プロセス上で実行される。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８中の各ブロックは、それぞれこの１プロセス上のスレッドとして、スレッド単位で並列的に実行（マルチスレッド）される。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は、Ｊａｖａ（登録商標）コンパイラによりソースコードからバイトコードに一括翻訳されており、Ｊａｖａ（登録商標）仮想マシンにより逐次実行される。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は「Ｊａｖａ（登録商標） ２ Ｍｉｃｒｏ Ｅｄｉｔｉｏｎ」の「Ｆｏｕｎｄａｔｉｏｎ Ｐｒｏｆｉｌｅ」がベースとなっている。
【００３４】
ＪＳＤＫアプリ１４７としては、図に示す通り、ユーザアプリ５０１と、ＳＡＳ Ｍａｎａｇｅｒ５１１と、Ｓｃｒｅｅｎ Ｍａｎａｇｅｒ５１２等が存在する。
【００３５】
ユーザアプリ５０１は、融合機１０１のユーザ（例えばベンダ）がＪＳＤＫを使用して開発したＪＳＤＫアプリ１４７である。ＳＡＳ Ｍａｎａｇｅｒ５１１は、他のＪＳＤＫアプリ１４７（ユーザアプリ５０１等）の制御等を行うＪＳＤＫアプリ１４７である。Ｓｃｒｅｅｎ Ｍａｎａｇｅｒ５１２は、他のＪＳＤＫアプリ１４７（ユーザアプリ５０１等）を操作対象とする操作画面の表示等を行うＪＳＤＫアプリ１４７である。
【００３６】
ユーザアプリ５０１はここでは、スタンドアロンアプリケーションやアプレットと並ぶＪａｖａ（登録商標）アプリケーションの一種であるＸｌｅｔである。ＳＡＳ Ｍａｎａｇｅｒ５１１とＳｃｒｅｅｎ Ｍａｎａｇｅｒ５１２はここでは、独自の拡張を施したＸｌｅｔ（ＸｌｅｔＥｘ）である。
【００３７】
ＪＳＤＫプラットフォーム１４８には、図に示す通り、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１と、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１と、Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２と、Ｓｅｎｄ Ｍａｎａｇｅｒ５４１と、Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４２と、Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４３と、Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４と、Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５と、Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６と、Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒ５４７等のクラスが存在する。
【００３８】
ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１は、ＪＳＤＫシステムの実行環境を反映したＪＳＤＫシステムの起動環境設定を実行するクラスである。
【００３９】
Ｘｌｅｔ Ｍａｎａｇｅｒ５３１は、１対１でＸｌｅｔを管理するクラスである。ここでは、５個のＸｌｅｔのライフサイクルやデータがそれぞれ１対１で５個のＸｌｅｔ Ｍａｎａｇｅｒ５３１によって管理される。Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２は、全てのＸｌｅｔ Ｍａｎａｇｅｒ５３１を管理するクラスである。ここでは、５個のＸｌｅｔ Ｍａｎａｇｅｒ５３１のライフサイクルやデータが全て１個のＭｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２によって管理される。なお、ＳＡＳ Ｍａｎａｇｅｒ５１１，Ｓｃｒｅｅｎ Ｍａｎａｇｅｒ５１２，ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１，Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２，Ｓｅｎｄ Ｍａｎａｇｅｒ５４１，Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４２，Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４３，Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４，Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５，Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６，Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒ５４７等のクラスのバンドルのライフサイクルやデータは、ＯＳＧｉフレームワーク４０３によって管理される。
【００４０】
Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４３は、図１のプラットフォーム１３２からのシステムイベント（電力モード等）の管理を行うクラスである。Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４は、１個のＸｌｅｔが図２のオペレーションパネル２０２の画面を占有する際の調停を行うクラスである。Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５は、ＳＤｃａｒｄやＷｅｂからのインストールやアンインストールの管理を行うクラスである。Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒ５４７は、Ｘｌｅｔからのサービス要求に応じてＸｌｅｔへのサービス提供を行うクラスである。
【００４１】
図７のＪＳＤＫシステムでは、ＡＰＩとして、ＪＳＤＫ ＡＰＩ５５１とＪＳＤＫ ＡＰＩ５５２が利用される。なお、ＸｌｅｔとＸｌｅｔＥｘの差異として、ＸｌｅｔＥｘは、オブジェクトにアクセスするのにＪＳＤＫ ＡＰＩ５５１の利用とＪＳＤＫプラットフォーム１４８へのアクセスが可能である点が挙げられる。図１の融合機１０１にはさらに、図７のＪＳＤＫシステムに係る要素として、Ｃ言語とＪａｖａ（登録商標）言語のインタフェースとなるＪＳＤＫ Ｓｅｓｓｉｏｎ５５３とＮａｔｉｖｅ ＪＳＤＫ Ｓｅｓｓｉｏｎ５５４や、ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８を実行するためＪａｖａ（登録商標）仮想マシンであるＣＶＭ５５５が存在する。
【００４２】
図８は、ＪＳＤＫシステムの起動処理を説明するための図である。ＪＳＤＫシステムの起動処理では先ず、ＯＳＧｉフレームワーク４０３が、ＯＳＧｉアプリ４０１やＯＳＧｉサービス４０２を構成するバンドルを生成（Ｓ１）する。次に、ＯＳＧｉフレームワーク４０３が、ＪＳＤＫアプリ１４７やＪＳＤＫプラットフォーム１４８を構成するバンドルを生成（Ｓ２）する。次に、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１が、ＪＳＤＫ Ｓｅｓｓｉｏｎ５５３やＮａｔｉｖｅ ＪＳＤＫ Ｓｅｓｓｉｏｎ５５４を生成するなど、ＪＳＤＫシステムの実行環境を反映したＪＳＤＫシステムの起動環境設定を実行（Ｓ３）する。次に、ＪＳＤＫ Ｓｅｓｓｉｏｎ５５３が、Ｓｅｎｄ Ｍａｎａｇｅｒ５４１やＥｖｅｎｔ Ｍａｎａｇｅｒ５４２を生成（Ｓ４）する。なお、ユーザアプリ５０１の起動処理には、ＳＡＳ４１１やＳＡＳ Ｍａｎａｇｅｒ５１１が関与（Ｓ５）する。
【００４３】
以下、Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒ５４７について詳細に説明する。文中、Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒ５４７についてはＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１、ＪＳＤＫ ＡＰＩ５５１についてはＦｕｎｃｔｉｏｎ ＡＰＩ６１１、ＪＳＤＫ ＡＰＩ５５２についてはＣ／Ｊ ＡＰＩ６２１と表記する。なお、ＡＰＩは、アプリケーションプログラムインタフェースの略語に相当する。
【００４４】
１）Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ
図９は、図７のＪＳＤＫシステムを構成するＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１について説明するためのクラス図である。Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、ユーザアプリ５０１からのサービス要求に応じてユーザアプリ５０１へのサービス提供を行うクラスである。サービス内容の具体例としては、コピー処理の実行制御に関するサービス、プリント処理の実行制御に関するサービス、スキャン処理の実行制御に関するサービス、ファックス処理の実行制御に関するサービスが挙げられる。図７のＪＳＤＫシステムには、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１が存在する。
【００４５】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、ユーザアプリ５０１からのサービス要求を調停する機能を備える。ユーザアプリ５０１からのサービス要求が競合する場合があるからである。Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、図９に示す通り、一のユーザアプリ５０１からのサービス要求と他のユーザアプリ５０１からのサービス要求とが競合する際には、一方のサービス要求を優先させて他方のサービス要求を劣後させる等、一方のサービス要求と他方のサービス要求とを調停する事になる。
【００４６】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１には、Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１や、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２等のクラスが存在する。さらに、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２には、Ｃｏｐｙ Ｓｅｒｖｉｃｅ７１１や、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２や、Ｓｃａｎ Ｓｅｒｖｉｃｅ７１３や、Ｆａｘ Ｓｅｒｖｉｃｅ７１４や、ＳＡＳ Ｓｅｒｖｉｃｅ７２１等のクラスが存在する。
【００４７】
Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１は、ユーザアプリ５０１等からのサービス要求を受け付けるクラスである。Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１は、ユーザアプリ５０１等からのサービス要求を処理する動的に変更可能な種々の関数を備える。Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２は、ユーザアプリ５０１等へのサービス提供を執り行うクラスである。Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２は、自己の振る舞いを動的に変更する機能を備える。なお、プログラムの振る舞いの取り扱いに関する具体例は例えば、特願２００４−０６２４１３に開示されている。
【００４８】
Ｃｏｐｙ Ｓｅｒｖｉｃｅ７１１は、コピー処理の実行制御に関するサービス提供等を執り行うクラスである。Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、プリント処理の実行制御に関するサービス提供等を執り行うクラスである。Ｓｃａｎ Ｓｅｒｖｉｃｅ７１３は、スキャン処理の実行制御に関するサービス提供等を執り行うクラスである。Ｆａｘ Ｓｅｒｖｉｃｅ７１４は、ファックス処理の実行制御に関するサービス提供等を執り行うクラスである。
【００４９】
ＳＡＳ Ｓｅｒｖｉｃｅ７２１は、ユーザアプリ５０１の動作態様を制御するクラスである。ＳＡＳ Ｓｅｒｖｉｃｅ７２１は、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２の振る舞いの動的な変更に応じて所定のユーザアプリ５０１の動作態様を変更する。なお、ＳＡＳ Ｓｅｒｖｉｃｅ７２１は、ＳＡＳ Ｍａｎａｇｅｒ５１１を制御する事でユーザアプリ５０１の動作態様を制御する事ができる。
【００５０】
なお、ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８はリフレクション型のアーキテクチャで実装されている。リフレクションとは、プログラムが自己の静的な構造や動的な振る舞いに関する情報を公開したり、自己の静的な構造や動的な振る舞いを変更したりする能力を意味する。リフレクション型のアーキテクチャは、ベースレベルとメタレベルからなる。図７のＪＳＤＫシステムでは、ＪＳＤＫアプリ１４７がベースレベルに相当し、ＪＳＤＫプラットフォーム１４８がメタレベルに相当する。
【００５１】
図１０は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の動作について説明するための図である。図１０は、図９のクラス図に対応するコラボレーション図に相当する。
【００５２】
ユーザアプリ５０１がＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求する際には先ず、ユーザアプリ５０１からＦｕｎｃｔｉｏｎ ＡＰＩ６１１に、当該サービスを要求する旨のサービス要求が送信（Ｓ１１）される。次に、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１からＡｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１に、当該サービスを要求する旨の当該サービス要求が送信（Ｓ１２）される。次に、Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１からＡｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２に、当該サービスを要求する旨の当該サービス要求が状態遷移のイベント形式で送信（Ｓ１３）される。次に、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２からプラットフォーム１３２に、当該サービスに関する情報処理，通信処理，画像形成処理等の種々の処理を要求する旨の処理要求が状態遷移のアクション形式で送信（Ｓ１４）される。
【００５３】
続いて次に、プラットフォーム１３２からＡｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２に、当該処理要求に関する処理結果が状態遷移のイベント形式で送信（Ｓ２１）される。次に、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２からＡｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１に、上記のサービス要求に関するサービス結果が状態遷移のアクション形式で送信（Ｓ２２）される。次に、Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１からＦｕｎｃｔｉｏｎ ＡＰＩ６１１に、上記のサービス要求に関する上記のサービス結果が送信（Ｓ２３）される。次に、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１からユーザアプリ５０１に、上記のサービス要求に関する上記のサービス結果が送信（Ｓ２４）される。
【００５４】
さて、プラットフォーム１３２が情報処理，通信処理，画像形成処理等の上記の処理を実行する際に上記の処理を実行する上での不都合や不具合が存在する場合には、プラットフォーム１３２からＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１に、不都合や不具合が存在する旨の通知が送信（Ｓ３１）される。次に、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１からＡｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２に、自己の振る舞いを動的に変更する旨の命令が送信（Ｓ３２）される。次に、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２が、自己の振る舞いを動的に変更（Ｓ３３）して更に、Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１の種々の関数の動作を動的に変更（Ｓ３４）する。次に、ＳＡＳ Ｓｅｒｖｉｃｅ７２１が、ＳＡＳ Ｍａｎａｇｅｒ５１１を通じて所定のユーザアプリ５０１の動作態様を変更（Ｓ３５，Ｓ３６）する。
【００５５】
図１１は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の動作の具体例について説明するための図である。図１１のコラボレーション図は、図１０のコラボレーション図の具体例に該当する。
【００５６】
先ず、第３のユーザアプリ５０１からＦａｘ Ｓｅｒｖｉｃｅ７１４に、ファックス送信処理の実行制御に係るサービス要求が送信（Ｓ４１）される。次に、Ｆａｘ Ｓｅｒｖｉｃｅ７１４からプラットフォーム１３２に、ファックス送信処理に係る処理要求が送信（Ｓ４２）される。続いて次に、第１のユーザアプリ５０１からＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２に、プリント処理の実行制御に係るサービス要求が送信（Ｓ４３）される。次に、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２からプラットフォーム１３２に、プリント処理に係る処理要求が送信（Ｓ４４）される。
【００５７】
次に、プラットフォーム１３２からＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１に、ファックス送信処理とプリント処理を同時に実行するためのメモリが不足している旨が通知（Ｓ５１）される。次に、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１は、ファックス送信処理の実行中はプリント処理の処理要求を発行しないようＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の振る舞いを動的に変更（Ｓ５２）する。
【００５８】
次に、プラットフォーム１３２からＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１に、プリント処理を停止してもファックス送信処理を実行するためのメモリがいまだ不足している旨が通知（Ｓ６１）される。次に、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１は、ファックス送信処理の実行中はファックス送信処理の要求元のユーザアプリ５０１を除く全てのユーザアプリ５０１を停止するようＳＡＳ Ｓｅｒｖｉｃｅ７２１の振る舞いを動的に変更（Ｓ６２）する。次に、ＳＡＳ Ｓｅｒｖｉｃｅ７２１は、ファックス送信処理の実行中はファックス送信処理の要求元のユーザアプリ５０１を除く全てのユーザアプリ５０１を停止（Ｓ６３，Ｓ６４）する。
【００５９】
図１２は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞い変更処理について概念的に説明するための図である。
【００６０】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にて、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２には、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２等のクラスが存在する。
【００６１】
Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２やＦａｘ Ｓｅｒｖｉｃｅ７１４の状態遷移モデルの管理を執り行う。Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２やＦａｘ Ｓｅｒｖｉｃｅ７１４の状態遷移モデルの修正を執り行う。状態遷移モデルの管理・修正は、Ｃｏｐｙ Ｓｅｒｖｉｃｅ７１１やＳｃａｎ Ｓｅｒｖｉｃｅ７１３も実施対象となる。
【００６２】
Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移モデルについて説明しておく。Ｉｄｌｅ状態７４１は、プリント処理の待機中の状態である。Ｐｒｉｎｔ状態７４２は、プリント処理を実行中の状態である。Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２は、印刷開始イベント７４３により遷移する。Ｐｒｉｎｔ状態７４２からＩｄｌｅ状態７４１は、印刷終了イベント７４４により遷移する。
【００６３】
Ｆａｘ Ｓｅｒｖｉｃｅ７１４の状態遷移モデルについて説明しておく。Ｉｄｌｅ状態７５１は、ファックス送信処理の待機中の状態である。ＦａｘＳｅｎｄ状態７５２は、ファックス送信処理を実行中の状態である。Ｉｄｌｅ状態７５１からＦａｘＳｅｎｄ状態７５２には、送信開始イベント７５３により遷移する。ＦａｘＳｅｎｄ状態７５２からＩｄｌｅ状態７５１には、送信終了イベント７５４により遷移する。
【００６４】
Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１が管理する状態遷移モデルに状態遷移の実行条件を付加する事で、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１が管理する状態遷移モデルを修正する事ができる。これによって、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２やＦａｘ Ｓｅｒｖｉｃｅ７１４の振る舞いが動的に変更される事になる。
【００６５】
図１２にて、図１２Ａは振る舞い変更前の状態遷移モデルを表し、図１２Ｂは振る舞い変更後の状態遷移モデルを表す。Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２に関して、図１２ＡではＩｄｌｅ状態７４１からＰｒｉｎｔ状態７４２に遷移するのに制限条件は存在しないが、図１２ＢではＩｄｌｅ状態７４１からＰｒｉｎｔ状態７４２に遷移するのに制限条件が存在する。当該制限条件（ガード条件）は、Ｆａｘ Ｓｅｒｖｉｃｅ７１４がＩｄｌｅ状態７５１の際に限りＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移を許容する事を意味する。当該制限条件（ガード条件）による振る舞い変更処理が、図１１のＳ５１・Ｓ５２による振る舞い変更処理に匹敵する。
【００６６】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、アスペクト指向プログラムに相当する。アスペクト指向とは、システム横断的な関心事の分離メカニズムを意味する。アスペクト指向では、アスペクト指向プログラムにアスペクトを織り込む事で、アスペクト指向プログラムの状態遷移モデルに状態遷移の実行条件を付加する事ができる。これによって、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１が管理する状態遷移モデルに状態遷移の実行条件を付加する。なお、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、振る舞いと部品が分離されて設計されており、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２からＳｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に、状態遷移モデルと部品ライブラリが登録される。これによって、アスペクト指向によるアスペクトの織り込みが実現されている。
【００６７】
ＸＭＩ言語によるＸＭＬ文書（図９，図１０，図１１）について説明しておく。図１０に示す通り、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１とＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１では、ＸＭＩ言語を記述言語とするＸＭＬ文書であるＡｓｐｅｃｔＳＭ．ｘｍｌファイル（以下、単に「ＡｓｐｅｃｔＳＭ」という。）の記述内容に従って、それぞれＳ３２の処理とＳ３３の処理を実行する。図１１で言えば、ＡｓｐｅｃｔＳＭにはメモリが不足している際にはＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞いを動的に変更する旨が記述されている。なお、ＸＭＬは「ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ」の略語に相当する。また、ＸＭＩは「ＸＭＬ Ｍｅｔａｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ」の略語に相当する。
【００６８】
以上の説明のように、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、自己の振る舞いを動的に変更する事ができる。これにより、ＪＤＳＫアプリ１４７の多様な変化にＪＳＤＫプラットフォーム１４８が適切に対応する事ができるのである。更に、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、自己の振る舞いの動的な変更に応じてユーザアプリ５０１の動作態様を変更する事ができる。これにより、ＪＤＳＫアプリ１４７の多様な変化にＪＳＤＫプラットフォーム１４８が、ＪＳＤＫプラットフォーム１４８の制御と更にＪＤＳＫアプリ１４７の制御を基に適切に対応する事ができるのである。
【００６９】
図１２において概念的に説明した内容を更に具体的に説明する。図１２に示されるモジュール構成は、図１３に示されるクラス図に基づいている。図１３は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの振る舞いの動的な変更を実現するクラス群を説明するためのクラス図である。
【００７０】
図１３において、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌクラス１０００は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１を表現するクラスである。すなわち、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌクラス１０００のインスタンスである。
【００７１】
ＳｔａｔｅＭａｃｈｉｎｅクラス１００１は、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２における各サービス（Ｃｏｐｙ Ｓｅｒｖｉｃｅ７１１、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２、Ｓｃａｎ Ｓｅｒｖｉｃｅ７１３、及びＦａｘ Ｓｅｒｖｉｃｅ７１４等）を表現するクラスである。すなわち、Ｃｏｐｙ Ｓｅｒｖｉｃｅ７１１、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２、Ｓｃａｎ Ｓｅｒｖｉｃｅ７１３、及びＦａｘ Ｓｅｒｖｉｃｅ７１４等は、それぞれＳａｔｅＭａｃｈｉｎｅクラス１００１のインスタンス（ＳｔａｔｅＭａｃｈｉｎｅオブジェクト）として生成される。したがって、以後、これらのサービスを総称する場合、「ステートマシン」という。
【００７２】
ＳｔａｔｅＶｅｒｔｅｘクラス１００２は、抽象クラスであり、各ステートマシンの状態遷移モデルにおいて状態を表現するクラスのルートクラスに相当する。ＳｔａｔｅＶｅｒｔｅｘクラス１００２には、ｃｏｎｎｅｃｔメソッド１００２ａや、ｒｅｃｏｎｎｅｃｔメソッド１００２ｂ等のメソッドが定義されている。ｃｏｎｎｅｃｔメソッド１００２ａは、遷移先の状態及びその状態遷移との接続を実行するメソッドである。状態遷移についてはＴｒａｎｓｉｔクラス１００３によって表現される。したがって、より具体的には、ｃｏｎｎｅｃｔメソッド１００２ａは、当該メソッドが呼び出されたオブジェクトと、当該オブジェクトの遷移先のＳｔａｔｅＶｅｒｔｅｘオブジェクト（厳密にはそのサブクラスのオブジェクト。以下、総称する場合「状態オブジェクト」という。）及びその状態遷移に対応するＴｒａｎｓｉｔオブジェクト（以下、「遷移オブジェクト」という。）との接続を実行するクラスである。ここでいう接続は、例えば、状態オブジェクト内に、遷移先の状態オブジェクトや、その遷移オブジェクトの識別情報（ＩＤ、参照、又はポインタ等）を保持することで実現される。ｒｅｃｏｎｎｅｃｔメソッド１００２ｂは、遷移先の変更を実行するメソッドである。なお、Ｔｒａｓｉｔクラス１００３には、インタフェースとしてＥｖｅｎｔインタフェース１００３ａ、Ｇｕｒａｄインタフェース１００３ｂ、及びＡｃｔｉｏｎインタフェース１００３ｃ等が定義されている。Ｅｖｅｎｔインタフェース１００３ａは、状態遷移の遷移イベントを実装するためのインタフェースである。Ｇｕａｒｄインタフェース１００３ｂは、ガード条件を実装するためのインタフェースである。Ａｃｔｉｏｎインタフェース１００３ｃは、状態遷移時に実行するアクションを実装するためのインタフェースである。
【００７３】
ＳｔａｔｅＶｅｒｔｅｘクラス１００２のサブクラスとしては、Ｓｔａｔｅクラス１００４及びＰｓｅｕｄｏＳｔａｔｅクラス１００５が定義されている。Ｓｔａｔｅクラス１００４は、例えば、ステートマシンの状態を表現するクラスである。Ｓｔａｔｅクラス１００４には、インタフェースとしてＩＳｔａｔｅインタフェース１００４ａ及びＡｃｔｉｖｉｔｙインタフェース１００４ｂ等が定義されている。ＩＳｔａｔｅインタフェース１００４ａは、状態の入場時の処理（入場処理）及び退場時の処理（退場処理）を実装するためのインタフェースである。Ａｃｔｉｖｉｔｙインタフェース１００４ｂは、状態にある間実行する処理を実装するためのインタフェースである。これらのインタフェースは、クラスとして実装される。したがって、例えば、Ａｃｔｉｖｉｔｙインタフェース１００４ｂの処理は、Ａｃｔｉｖｉｔｙクラスに実装される。
【００７４】
ＰｓｅｕｄｏＳａｔｅクラス１００５は、初期状態や終期状態等、その名の通り擬似的な状態を表現するクラスであり、そのサブクラスとしては初期状態を表現するＩｎｉｔｉａｌＳｔａｔｅクラス１００６及び終期状態を表現するＦｉｎａｌＳｔａｔｅクラス１００７等がある。但し、図１２の状態遷移モデルでは、初期状態及び終期状態は便宜上省略されている。
【００７５】
ＭｏｄｉｆｙＡｇｅｎｔクラス１００９は、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２を表現するクラスである。すなわち、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、ＭｏｄｉｆｙＡｇｅｎｔクラス１００９のインスタンスである。ＰｌｕｇｉｎＡｇｅｔｎｔクラス１００８については後述する。
【００７６】
上記クラス間の関係について説明する。ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌクラス１０００は、ＳｔａｔｅＭａｃｈｉｎｅクラス１００１を集約する。これは、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１が、一つ以上のステートマシンのそれぞれの状態遷移モデルを管理することを表現したものである。
【００７７】
ＳｔａｔｅＭａｃｈｉｎｅクラス１００１は、ＳｔａｔｅＶｅｒｔｅｘクラス１００２を集約する。これは、一つのステートマシンは、一つ以上の状態を有することを表現したものである。ＳｔａｔｅＶｅｒｔｅｘクラス１００２は、Ｔｒａｎｓｉｔクラスを集約する。これは、状態と状態との間は遷移によって接続されることを表現したものである。
【００７８】
以上のような、モデルに基づいて、例えば、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、以下のようなオブジェクトによって構成される。
【００７９】
図１４は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅのオブジェクト構成を表す図である。Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、図１２の状態遷移モデルに基づいて、Ｉｄｌｅ状態オブジェクト７４１Ｓ、Ｐｒｉｎｔ状態オブジェクト７４２Ｓ、印刷開始オブジェクト７４３Ｔ、プ及び印刷終了オブジェクト７４４Ｔ等より構成される。Ｉｄｌｅ状態オブジェクト７４１Ｓ及びＰｒｉｎｔ状態オブジェクト７４２Ｓは、Ｓｔａｔｅクラス１００４のインスタンスである。印刷開始オブジェクト７４３Ｔ及び印刷終了オブジェクト７４４Ｔは、Ｔｒａｎｓｉｔクラス１００３のインスタンスである。
【００８０】
図１４においてオブジェクト同士を連結する線分は、オブジェクト同士の参照関係を表す。遷移元の状態オブジェクトは遷移先の状態オブジェクトを参照している。なお、図中では状態オブジェクト間に遷移オブジェクトが接続されている。例えば、Ｉｄｌｅ状態オブジェクト７４１ＳとＰｒｉｎｔ状態オブジェクト７４２Ｓとの間には印刷開始オブジェクト７４３Ｔが接続されている。しかし、このことはＩｄｌｅ状態７０３が、Ｐｒｉｎｔ状態オブジェクト７４２Ｓを参照していないことを示すものではない。Ｉｄｌｅ状態オブジェクト７４１Ｓは、Ｐｒｉｎｔ状態オブジェクト７４２Ｓを参照すると共に、その状態遷移に対応する遷移オブジェクトとして印刷開始オブジェクト７４３Ｔをも参照することを表現したものである。
【００８１】
オブジェクトの状態は、サービスの授受を行う「アクティブ状態」とサービスの授受を行わない「非アクティブ状態」に分類される。Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１におけるステートマシンの振る舞い変更を当該ステートマシンの動作中に実行するには、当該ステートマシンの更新部分のオブジェクトがアクティブ状態ではないとき（非アクティブ状態のとき）に実行すればよい。当該ステートマシンの動作中のオブジェクト同士のサービスの授受が更新処理により阻害されずに済むからである。よって、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の更新処理をＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の更新部分のオブジェクトがアクティブ状態ではないときに実行するのである。なお、状態遷移図によるモデリングでは、一のオブジェクトがアクティブ状態のときは他のオブジェクトは非アクティブ状態に限定される。すなわち、各オブジェクトは互いに排他的に処理を実行する（動作する）。
【００８２】
図１４に示されるＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２のオブジェクト構成が構築される過程について説明する。
【００８３】
図１５は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅのオブジェクト構成の構築処理を説明するためのシーケンス図である。図１５の処理は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２がＳｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１によってインスタンス化される際に実行される。
【００８４】
Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、インスタンス化されると、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移情報に基づいて、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移モデルに対応したオブジェクト構成を構築する（Ｓ４０１）。状態遷移情報は、例えば、融合機１０１の所定の記憶装置内に、以下の形式で保存されている。
【００８５】
図１６及び図１７は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの状態遷移情報の定義例を示す図である。図１６及び図１７によって一つの状態遷移情報９００の記述例が示されている。状態遷移情報９００は、ＸＭＩ（XML Metadata Interchange）に従った記述例が示されている。ＸＭＩは、モデルを各種のソフトウェアの間でＸＭＬ文書によって交換することを目的とした標準規格である。但し、本実施の形態を実施するにあたり、状態遷移情報は、必ずしもＸＭＩに従って記述される必要はない。なお、図中における行番号は、説明の便宜上付加したものである。
【００８６】
状態遷移情報９００の１行目における＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグのタグ名、及びそのｎａｍｅ属性の値（「Ｐｒｉｎｔ」）によって、状態遷移情報９００は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２に対応するものであることが定義されている。また、当該＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグにおけるｘｍｉ．ｉｄ属性の値（「００３」）は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２を識別するためのＩＤである。
【００８７】
３行目の＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグは、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２における状態の定義の開始の宣言に相当する。当該宣言は、＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグのｘｍｉ．ｉｄの値（「００４」）によって識別される。
【００８８】
５行目から１５行目におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０は、Ｉｄｌｅ状態７４１に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０のｎａｍｅ属性の値には「Ｉｄｌｅ」が設定され、ｘｍｉ．ｉｄ要素の値には、「００５」が設定されている。
【００８９】
１６行目から２６行目（図１７）におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０は、Ｐｒｉｎｔ状態７４２に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０のｎａｍｅ属性の値には「Ｐｒｉｎｔ」が設定され、ｘｍｉ．ｉｄ要素の値には、「００８」が設定されている。
【００９０】
また、３４行目から６４行目には、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２における各状態遷移が定義されている。すなわち、３４行目から５０行目におけるＴｒａｎｓｉｔｉｏｎ要素９３０は、Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素９３０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ要素９３０の子要素として定義されている、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９３１及びＴｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９３２より特定される。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９３１は遷移元の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９３１の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００５」である。したがって、遷移元は、ｘｍｉ．ｉｄ属性の値が「００５」の状態、すなわち、Ｉｄｌｅ状態７４１であることが分かる。また、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９３２は遷移先の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９３２の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００８」である。したがって、遷移先は、ｘｍｉ．ｉｄの値が「００８」の状態、すなわち、Ｐｒｉｎｔ状態７４２であることが分かる。なお、Ｔｒａｎｓｉｔｉｏｎ要素９３０のｎａｍｅ属性の値は「印刷開始」であり、ｘｍｉ．ｉｄ属性の値は「００６」である。
【００９１】
５１行目から６４行目におけるＴｒａｎｓｉｔｉｏｎ要素９４０は、Ｐｒｉｎｔ状態７４２からＩｄｌｅ状態７４１への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素９４０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９４１内のｘｍｉ．ｉｄｒｅｆ属性の値が「００８」（Ｐｒｉｎｔ状態７４２）であり、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９４２内のｘｍｉ．ｉｄｒｅｆ属性の値が「００５」（Ｉｄｌｅ状態７４１）であることから特定される。なお、Ｔｒａｎｓｉｔｉｏｎ要素９４０のｎａｍｅ属性の値は「印刷終了」であり、ｘｍｉ．ｉｄ属性の値は「００７」である。
【００９２】
５行目以降の説明に戻る。各状態に対応する、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０及びＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０は、ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素及びＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素の少なくともいずれか一方を子要素として有する。ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素は、遷移元からの状態遷移に対する接続が定義される要素である。ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素は、遷移先への状態遷移に対する接続が定義される要素である。
【００９３】
例えば、Ｉｄｌｅ状態７４１に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０おけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素９１１においてその子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００６」であり、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素９１２において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００７」である。したがって、Ｐｒｉｎｔ状態７４２からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９３０が対応する状態遷移に相当し、遷移元の状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９４０が対応する状態遷移に相当することが分かる。
【００９４】
また、Ｐｒｉｎｔ状態７４２に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０おけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素９２１においてその子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００７」であり、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素９２２において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００６」である。したがって、Ｐｒｉｎｔ状態７４２からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９４０が対応する状態遷移に相当し、遷移元の状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９３０が対応する状態遷移に相当することが分かる。
【００９５】
上記のような状態遷移情報９００に基づいて、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、まず、各状態オブジェクト及び遷移オブジェクト等をインスタンス化する。図中では、状態遷移情報９００におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０、Ｔｒａｎｓｉｔｉｏｎ要素９３０、及びＴｒａｎｓｉｔｉｏｎ要素９４０のそれぞれに基づいて、Ｉｄｌｅ状態オブジェクト７４１Ｓ、Ｐｒｉｎｔ状態オブジェクト７４２Ｓ、印刷開始オブジェクト７４３Ｔ、及び印刷終了オブジェクト７４４Ｔが生成されている例が示されている（Ｓ４０２〜Ｓ４０５）。
【００９６】
続いて、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、各状態オブジェクトの参照関係が状態遷移情報９００に定義された状態遷移の順になるよう、遷移元の状態オブジェクトに対して遷移先の状態オブジェクトを接続する。例えば、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、Ｐｒｉｎｔ状態オブジェクト７４２Ｓの識別情報と印刷開始オブジェクト７４３Ｔの識別情報とを引数として、Ｉｄｌｅ状態オブジェクト７４１Ｓのｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ４０６）。また、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、Ｉｄｌｅオブジェクト７４１Ｓの識別情報と印刷終了オブジェクト７４４Ｔの識別情報とを引数として、Ｐｒｉｎｔ状態オブジェクト７４２Ｓのｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ４０７）。ｃｏｎｎｅｃｔ（）メソッドを呼び出された各状態オブジェクトは、当該状態オブジェクト内において引数に指定された識別情報を保持する。
【００９７】
このように、ｃｏｎｎｅｃｔ（）メソッドの引数に、状態オブジェクトと遷移オブジェクトとのそれぞれの識別情報が指定された場合、当該メソッドが呼び出された状態オブジェクトは、その状態オブジェクトの識別情報と遷移オブジェクトの識別情報とを関連付けて（ペアで）保持する。これによって、ある状態オブジェクトがアクティブのときに、あるイベントが発生したときの遷移先の状態オブジェクトが特定され得る。
【００９８】
以上の処理によって、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２について、図１４に示されるようなオブジェクト構成が構築される。
【００９９】
上記をふまえて、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の振る舞い変更処理を具体的に説明する。図１８及び図１９は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの振る舞い変更処理を説明するためのシーケンス図である。
【０１００】
プラットフォーム１３２からＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１に、例えば、不都合や不具合の発生等を示すイベントが送信される（Ｓ４２１）。ここでは、メモリが不足していることを示すイベントが通知されたこととする。但し、ここで通知されるイベントは不具合や不都合に限定されず、例えば、機器の状態の変化も含まれ得る。機器の状態の変化としては、静的な情報（機種名、機種のスペック、周辺機器情報）の変化と動的な情報（使用可能メモリ、周辺機器の状態、ユーザ操作）の変化とがある。静的な情報の変化は確定した時にＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１に通知され、動的な情報は変化が発生した時に随時通知される。 ＪＳＤＫ Ｅｎｖｉｒｏｎｍｎｅｔ５２１は、プラットフォーム１３２からのイベントに応じた振る舞い修正指示がＡｓｐｅｃｔＳＭに記載されているか確認する。
【０１０１】
図２０は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの振る舞いの変更内容が記述されたＡｓｐｅｃｔＳＭの記述例を示す図である。ＡｓｐｅｃｔＳＭ８１０には、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移情報９００（図１６及び図１７）に対する変更内容が記述されている。
【０１０２】
ＡｓｐｅｃｔＳＭ８１０において、１行目から６行目までの＜Ｅｖｅｎｔ＞タグで囲まれたＥｖｅｎｔ要素８１１のｎａｍｅ属性、ｔｙｐｅ属性、ｖａｌｕｅ属性のそれぞれには、振る舞いを変更するトリガとなるイベント名、条件、閾値が記述される。また、Ｅｖｅｎｔ要素８１１の子要素（ｍｏｄｉｆｙ．ＳｔａｔｅＭａｃｈｉｎｅ要素）には、振る舞いの変更対象となるステートマシンが記述される。図２０の例では、空きメモリが１０ＭＢを下回ったことを示すイベントを受信した場合にＰｒｉｎｔ（Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２）に対して振る舞いを変更することが記述されている。
【０１０３】
７行目から１５行目までのａｓｐｅｃｔ要素８１２のＸＭＩ．ＳｔａｔｅＭａｃｈｉｎｅ属性には、変更するステートマシン名（Ｐｒｉｎｔ）が記述される。また、ｐｏｉｎｔｃｕｔ．Ｔｒａｎｓｍｉｓｓｉｏｎ要素８１３のｎａｍｅ属性には、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２において変更対象となる状態遷移の名前が記述され、ｔｉｍｅｎｇ属性にはＡｓｐｅｃｔＳＭ８１０による変更処理を実行するタイミングが記述される。図２０の例では、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移において、Ｉｄｌｅ状態７４１のときに振る舞い変更処理を実行することが記述されている。ａｄｖｉｃｅ．Ｇａｕｒｄ要素には、変更の内容が記述される。すなわち、＜ａｄｖｉｃｅ．Ｇｕａｒｄ＞タグのタグ名におけるａｄｖｉｃｅ．以降によって、変更の対象がＧｕａｒｄ（ガード条件）であることが記述されている。また、ｔｙｐｅ属性によって、変更の種別が「ｉｎｓｅｒｔ」（挿入）であることが記述されている。すなわち、変更内容はガード条件を挿入することであることが記述されている。１０行目から１２行目までは、実際に状態遷移情報９００に挿入される定義である。すなわち、ＡｓｐｅｃｔＳＭ８１０では、「Ｉｄｌｅ状態７４１のときにＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の印刷開始イベント７４３に基づく状態遷移に対してガード条件（Ｆａｘ Ｓｅｒｖｉｃｅ７１４がＩｄｌｅ状態であること）を付加すること」が定義されている。
【０１０４】
なお、各イベントに応じたＡｓｐｅｃｔＳＭは、予め融合機１０１のＨＤＤ２３３又はメモリカード２３５等に保存されている。
【０１０５】
したがって、ステップＳ４２１において通知されたイベントが、空きメモリが１０ＭＢを下回ったことを示すものであった場合、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｎｅｔ５２１は、図２０のＡｓｐｅｃｔＳＭ８１０に基づいて、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の振る舞いを変更する必要があることを判断し、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２にＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の振る舞い変更情報を添付して振る舞い変更要求を発行する（Ｓ４２２）。ここで、「振る舞い変更情報」とは、ＡｓｐｅｃｔＳＭ８１０より、振る舞いの変更に必要な情報のみが抽出されたものでもよいし、ＡｓｐｅｃｔＳＭ８１０そのものでもよい。
【０１０６】
Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２に対する振る舞い変更要求を受け、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に対して、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移情報９００の取得要求を発行する（Ｓ４２３）。Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、状態遷移情報９００の取得要求に対して、当該状態遷移情報が登録されていれば状態遷移情報９００をＭｏｄｉｆｙ Ａｇｅｎｔ７３２に提供する（Ｓ４２４）。
【０１０７】
Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１から状態遷移情報９００を取得できた場合、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移情報９００に対する振る舞い変更処理の可否を判断する（Ｓ４２５ａ）。一方、状態遷移情報９００を取得できなかった場合、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１にＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は登録されていないことを実装してないことをＪＳＤＫ Ｅｎｖｉｒｏｎｍｎｅｔ５２１に通知する（Ｓ４２５ｂ）。
【０１０８】
ステップＳ４２５ａにおいて、振る舞い変更処理が可能であると判断した場合、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に対して、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２がインスタンス化されているか（すなわち、図１４に示されるオブジェクト構成がメモリ上に構築されているか）を問い合わせる（Ｓ４２６ａ）。一方、ステップＳ４２５ａにおいて、振る舞い変更処理は不可能であると判断した場合、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｎｅｔ５２１に変更不可であることを通知する（Ｓ４２６ｂ）。
【０１０９】
ステップＳ４２６ａの問い合わせに対して、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２がインスタンス化されていればそのインスタンスを返却する（Ｓ４２７）。
【０１１０】
Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２のインスタンスが生成されていない場合、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、状態遷移情報９００に対し振る舞い変更情報に応じた修正を行い、修正された状態遷移情報９００をＳｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に登録する（Ｓ４２８ａ）具体的には、状態遷移情報９００の３４行目と３８行目の間に、ＡｓｐｅｃｔＳＭ８１０の１０行目から１３行目が挿入される。したがって、以降にＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２がインスタンス化される際は、修正された状態遷移情報９００に基づいて、オブジェクト群が構築される。
【０１１１】
一方、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２のインスタンスが生成されている場合、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、図１９に示される処理を実行する（Ｓ４２８ｂ）
図１９において、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２のＩｄｌｅ状態オブジェクト７４１Ｓを検索する（Ｓ４３１、Ｓ４３２）。ここで、Ｍｏｄｅｆｙ Ａｇｅｎｔ７３２は、ＡｓｐｅｃｔＳＭ８１０のｐｏｉｎｔｃｕｔ．Ｔｒａｎｓｍｉｓｓｉｏｎ要素８１３のｔｉｍｉｎｇ属性に基づいて、Ｉｄｌｅ状態オブジェクト７４１Ｓを監視することにより、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２がＩｄｌｅ状態７４１に遷移するまで待機する。
【０１１２】
Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２がＩｄｌｅ状態７４１に遷移すると、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｉｄｌｅ状態オブジェクト７４１Ｓより、印刷開始オブジェクト７４３Ｔを検索する（Ｓ４３３、Ｓ４３４）。続いて、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、ガード条件を表現するガード条件オブジェクト７４６を生成し（Ｓ４３５）、ＡｓｐｅｃｔＳＭ８１０に定義されているガード条件（［ｉｓ＿ｉｎ（ＦａｘＴｘＩｄｌｅ）］）を、ガード条件オブジェクト７４６に設定する（Ｓ４３６）。ここで、ＦａｘＴｘＩｄｌｅは、Ｆａｘ Ｓｅｒｖｉｃｅ７１４のＩｄｌｅ状態オブジェクトの識別情報である。
【０１１３】
続いて、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、印刷開始オブジェクト７４３Ｔに対して、ガード条件オブジェクト７４６を設定する（Ｓ４３７）。ここで、印刷開始オブジェクト７４３Ｔは、Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２への状態遷移に対応するオブジェクトである。したがって、ステップＳ４３７の処理により、当該状態遷移にガード条件が付加されたことになる。以降、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２において、Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２への遷移が発生する際、印刷開始オブジェクト７４３Ｔに設定されたガードオブジェクト７４６に基づいて、遷移の可否が判定される。
【０１１４】
上述したように、本実施の形態におけるＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、状態オブジェクトの遷移によってサービスを実現する。また、サービスの実現過程において、アクティブな状態オブジェクトが限定されるように構成されている。言い換えれば、非アクティブな状態オブジェクトが存在することになる。このような構成を前提として、ＡｓｐｅｃｔＳＭ８１０には、更新部分が非アクティブなタイミングで更新が行われるような更新指示が記述されている。そして、かかるＡｓｐｅｃｔＳＭ８１０に従って、更新部分が非アクティブなときに更新が実行される。したがって、本実施の形態におけるＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、当該Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の実行中にその振る舞いの変更を実行することができる。また、振る舞いの変更にあたり、オブジェクト群が再構築されるわけではないので、当該Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の参照側との参照関係が破壊されることなく、動的にその振る舞いを変更することが可能となっている。よって、融合機１０１を再起動することなくＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞いは変更され得る。
【０１１５】
なお、本実施の形態においては、ステートマシンが状態遷移モデルに基づいて設計された例を用いて説明したが、本発明が適用可能なプログラムは、状態ごとにオブジェクトが構築されるような構成であるものに限定されない。お互いに排他的に動作する複数のモジュール（オブジェクトも含む）の接続によって構成されているものでればよい。ここで排他的に処理を実行するとは、あるモジュールが動作中（アクティブ）のときは、他のモジュールは動作中でない（非アクティブである）ことが保証されることをいう。このようなソフトウェアであれば、動作中でないモジュールを変更することが可能であり、本実施の形態において説明した振る舞いの変更処理を適用させることができる。
【０１１６】
２）Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ
図２１は、図７のＪＳＤＫシステムを構成するＭｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２について説明するためのクラス図である。Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２は、ＪＳＤＫアプリ１４７からのＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に対するサービスの提供要求に応じて、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを修正するクラスである。すなわち、第一節（Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ）では、プラットフェーム１３２からのイベントに応じて、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１が、自らの振る舞いを変更する処理について説明したが、Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２は、ＪＳＤＫアプリ１４７がＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１を利用しようとしたときに、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞いを変更するのである。
【０１１７】
図７のＪＳＤＫシステムでは、第１節で取り上げたＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１と第２節で取り上げるＭｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２は下位層と上位層の関係にある。図７のＪＳＤＫシステムには、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１が存在し、Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、Ｍｏｄｉｆｙ ＡＰＩ６１２が存在する。Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２とＭｏｄｉｆｙ ＡＰＩ６１２の実装態様は、図２１の実装態様ではなく図２２の実装態様でもよい。図２１についての説明の内容は図２２についても同様に成立する。なお、図２１は、Ｍｏｄｉｆｙ ＡＰＩ６１２は、複数のユーザアプリ５０１に対して有効であること（呼び出し元が限定されないこと）を示す。一方、図２２は、Ｍｏｄｉｆｙ ＡＰＩ６１２は、特定のユーザアプリ５０１に対して有効であること（呼び出し元が限定されること）を示す。
【０１１８】
Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２とＭｏｄｉｆｙ ＡＰＩ６１２の実装理由を説明する事にする。図７のＪＳＤＫシステムには、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞いを動的に変更する機能は実装しているが、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１の動作を動的に変更する機能は実装していない。ＡＰＩの実装態様はユーザアプリ５０１の開発効率に与える影響が大きいところ、ＡＰＩの動作を動的に変更するような実装は開発トラブルや市場トラブルを招き兼ねないからである。よって、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを修正するには、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを修正するＭｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２を、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に上乗せするのである。そしてさらに、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１にＭｏｄｉｆｙ ＡＰＩ６１２を上乗せする。
【０１１９】
図２１に示す通り、旧バージョンのユーザアプリ５０１は、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１を通じてＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求（Ｓ１０１）する。一方、新バージョンのユーザアプリ５０１は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求する際には、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１を通じてＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求（Ｓ１０２）して、Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２にサービスを要求する際には、Ｍｏｄｉｆｙ ＡＰＩ６１２を通じてＭｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２にサービスを要求（Ｓ１０３）する。
【０１２０】
但し、Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２を介してサービス要求がなされ、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞いが変更された後は、旧バージョンのユーザアプリ５０１であっても、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１を通じて、振る舞いが変更されたＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１によるサービスの提供を受けることができる。
【０１２１】
Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６１２について更に具体的に説明する。図２３は、Ｍｏｄｉｆｙ ＳｅｒｖｉｃｅによるＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの変更処理を説明するためのシーケンス図である。図２３では、Ｆａｘ Ｓｅｒｖｅｃｅ７１４を利用するためのＦｕｎｃｔｉｏｎ ＡＰＩ６１１の呼び出しに応じて、Ｐｒｉｎｔｅｒ Ｓｅｒｖｉｃｅ７１２の振る舞いが変更される例について説明する。
【０１２２】
ＪＳＤＫアプリ１４７の一つであるＦａｘ送信アプリ５０１ｆが起動されている状態において、ユーザが、オペレーションパネル２０２を介してＦａｘ送信アプリ５０１ｆに対して送信開始の指示を行ったとする（Ｓ５０１）。Ｆａｘ送信アプリ５０１ｆは、ユーザからの指示に応じ、Ｆｕｎｃｔｉｏｎ ＡＰＩ６０１又はＭｏｄｉｆｙ ＡＰＩ６１２の一部を構成するＦａｘ送信クラス６１１ｆを用いて送信開始を行う（Ｓ５０２）。具体的には、Ｆａｘ送信アプリ５０１ｆは、Ｆａｘ送信クラス６１１ｆのｓｔａｒｔ（）メソッド（Ｆａｘｔｘ．ｓｔａｒｔ（））を呼び出す。
【０１２３】
Ｆａｘ送信クラス６１１ｆは、ＦａｘＴｘ．ｓｔａｒｔ（）メソッドが呼ばれたこと（送信開始イベント７５３の発生）を要求元のアプリのプロダクトＩＤを添えてＭｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２に通知する（Ｓ５０３）。Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２は、通知されたイベント（送信開始イベント７５３）が、Ｆａｘ送信アプリ５０１ｆのインストールの際にＦａｘ送信アプリ５０１ｆに対応させて登録されたＡｓｐｅｃｔＳＭに基づく振る舞い変更のトリガとなるイベントであるか当該ＡｓｐｅｃｔＳＭを参照することにより判断する。
【０１２４】
図２４は、Ｆａｘ送信アプリに対応させて登録されたＡｓｐｅｃｔＳＭの記述例を示す図である。図２４のＡｓｐｅｃｔＳＭ８２０は、２行目の記述内容が、図２０のＡｓｐｅｃｔＳＭ８１０と異なる。
【０１２５】
すなわち、ＡｓｐｅｃｔＳＭ８２０のＥｖｅｎｔ要素８２１のｎａｍｅ属性には、振る舞いを変更するトリガとなるイベント名として"Ｍｅｔｈｏｄ"が記述されている。これは、メソッドが呼び出されたことがトリガとなることを意味する。また、ｔｙｐｅ属性には、トリガとなる具体的なメソッド名（" ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ＦａｘＴｘ：ｓｔａｒｔ（ｖｏｉｄ）"）が記述されている。ここで「ＦａｘＴｘ」とは、Ｆａｘ送信クラスを示す。更に、ｖａｌｕｅ属性には、メソッドの呼び出し元を特定するプロダクトＩＤ（"１２３４５６"）が記述されている。ここで、"１２３４５６"は、Ｆａｘ送信アプリ５０１ｆのプロダクトＩＤである。呼び出し元を特定しない場合、ｖａｌｕｅ属性の値は空となる。なお、ｖａｌｕｅ属性の値にプロダクトＩＤが指定されない場合（すなわち、呼び出し元が限定されない場合）と、プロダクトＩＤが指定される場合（すなわち、呼び出し元が限定される場合）との違いは、図２１と図２２との違いによって概念的に示されている。
【０１２６】
上記より、ＡｓｐｅｃｔＳＭ８２０には、Ｆａｘ送信アプリ５０１ｆからのＦａｘｔｘ．ｓｔａｒｔ（）の呼び出しが、振る舞いを変更するトリガであることが記述されていることが分かる。
【０１２７】
したがって、Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２は、ＡｓｐｅｃｔＳＭ８２０のＥｖｅｎｔ要素８２１に基づいて、Ｆａｘ送信クラス６１１ｆより通知されたイベント（送信開始イベント７５３）は、振る舞い変更のトリガとなるイベントであると判断し、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２に「振る舞い変更情報」を添えて、Ｐｒｉｎｔｅｒ Ｓｅｒｖｉｃｅ７１２の振る舞いの変更を要求する（Ｓ５０４）。
【０１２８】
続いて、ステップＳ５０５からステップＳ５１０ｂまでは、図１８のステップＳ４２３からステップＳ４２８ｂまでと同様の処理が実行される。したがって、ステップＳ５１０ｂでは、図１９において説明した処理と同様の処理が実行され、Ｐｒｉｎｔｅｒ Ｓｅｒｖｉｃｅ７１２の振る舞いが変更される。すなわち、Ｐｒｉｎｔｅｒ Ｓｅｒｖｉｃｅ７１２における、Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２への状態遷移に対してガード条件が付加される。
【０１２９】
続いて、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｐｒｉｎｔｅｒ Ｓｅｒｖｉｃｅ７１２の振る舞いの変更が完了したことをＭｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２に通知する（Ｓ５１１）。Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２は、Ｆａｘ送信クラス６１１ｆに対して変更の完了を通知する（Ｓ５１２）。
【０１３０】
Ｆａｘ送信クラス６１１ｆは、Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２からの変更完了通知が届くまで待機している。Ｆａｘ送信クラス６１１ｆは、変更完了通知に応じてＳｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に対して送信開始イベント７５３を発行する（Ｓ５１３）。Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、送信開始イベント７５３の通知先を検索し、検索されたＦａｘ Ｓｅｒｖｉｃｅ７１３に送信開始イベント７５３を通知する（Ｓ５１４）。
【０１３１】
ここでＦａｘ Ｓｅｒｖｉｃｅ７１３によってＦａｘの送信処理が実行されるが、この間は、上記で説明した振る舞いの変更によってＰｒｉｎｔｅｒ Ｓｅｒｖｉｃｅ７１２に対して印刷開始イベント７４３が発行されても、印刷は開始されない。
【０１３２】
Ｆａｘ Ｓｅｒｖｉｃｅ７１４によるＦａｘ送信が完了すると（Ｓ５１５）、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、Ｆａｘ送信クラス６１１ｆに送信完了通知を行う（Ｓ５１６）。Ｆａｘ送信クラス６１１ｆは、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１からの送信完了通知を受けてＦａｘ送信アプリ５０１ｆに送信完了通知を行う（Ｓ５１７）。Ｆａｘ送信アプリ５０１ｆは、オペレーションパネル２０２に送信が完了した旨のメッセージ等を表示することにより、Ｆａｘ送信の完了をユーザに通知する（Ｓ５１８）。
【０１３３】
ところで、図２３のステップＳ５１４において、「Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、送信開始イベント７５３の通知先を検索する」と説明したが、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に通知されたイベントが、どのように各ステートマシンに通知されるかについて説明する。
【０１３４】
図２５は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌによるイベントの通知方式について説明するための図である。
【０１３５】
Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、イベントを受け付けると、管理しているステートマシン群に対して、ラウンドロビン方式で順番にイベントを発行する。これにより、ステートマシン間では排他的な動作が実現される。また、個々のステートマシンも遷移処理を排他的に処理することにより、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１内のアクション処理を排他的に実行することができる。
【０１３６】
図２５に示される手順に沿って説明する。
【０１３７】
送信開始イベント７５３が、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に対して発行される（Ｓ５２１）。Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、管理している全てのステートマシン（但し、イベントに宛先が明示されている場合は、特定のステートマシン）に送信開始イベント７５３をラウンドロビン方式で発行する（Ｓ５２１〜Ｓ５２４）。例えば、Ｆａｘ Ｓｅｒｖｉｃｅ７１４が、待ち行列の最初に位置している場合、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、最初にＦａｘ Ｓｅｒｖｉｃｅ７１４に送信開始イベント７５３を発行する（Ｓ５２１）。
【０１３８】
Ｆａｘ Ｓｅｒｖｉｃｅ７１４は、今現在、アクティブな状態オブジェクトに接続している全ての遷移オブジェクトに対して順番にイベントを発行し、遷移条件を満足しているかを確認する。遷移条件を満足していれば、アクションを実行して遷移する。例えば、Ｉｄｌｅ状態７５１であれば、送信開始イベント７５３によりＦａｘＳｅｎｄ状態７５２に遷移し、Ｆａｘ送信を開始する。
【０１３９】
３）Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ
図２６は、図７のＪＳＤＫシステムを構成するＥｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３について説明するためのクラス図である。Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを拡張するクラスである。図７のＪＳＤＫシステムでは、第１節で取り上げたＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１と第３節で取り上げるＥｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３は同位層の関係にある。図７のＪＳＤＫシステムには、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１が存在し、Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、第１のＥｘｔｅｎｄ ＡＰＩ６１３−１が存在し、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１とＥｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３との間のサービス授受を仲介するＡＰＩとして、第２のＥｘｔｅｎｄ ＡＰＩ６１３−２が存在する。
【０１４０】
Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３とＥｘｔｅｎｄ ＡＰＩ６１３の実装理由を説明する事にする。ＪＳＤＫアプリ１４７の多様な変化にＪＳＤＫプラットフォーム１４８が適切に対応するには、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスをより他律的に変更できる方が好適な場合がある。Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に部品を外部から提供してＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを拡張する場合等である。よって、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを拡張するのに、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを拡張するＥｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３を、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１とともに実装するのである。そしてさらに、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１とともにＥｘｔｅｎｄ ＡＰＩ６１３を実装する。
【０１４１】
図２６に示す通り、旧バージョンのユーザアプリ５０１は、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１を通じてＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求（Ｓ２０１）する。一方、新バージョンのユーザアプリ５０１は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に非拡張バージョンのサービスを要求する際は、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１を通じてＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求（Ｓ２０２）して、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に拡張バージョンのサービスを要求する際は、第１のＥｘｔｅｎｄ ＡＰＩ６１３−１とＥｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３と第２のＥｘｔｅｎｄ ＡＰＩ６１３−２とを通じてＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求（Ｓ２０３−１，２）する。
【０１４２】
図２７は、Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅの動作の概要を説明するための図である。
【０１４３】
図２７に示されるＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にて、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２には、非拡張バージョンのＦａｘ Ｓｅｒｖｉｃｅ７１４であるＦａｘＴｘ１と、拡張バージョンのＦａｘ Ｓｅｒｖｉｃｅ７１４であるＦａｘＴｘ２が存在する。ＦａｘＴｘ１は、画像データをＦＡＸ送信するＦａｘ Ｓｅｒｖｉｃｅ７１４である。ＦａｘＴｘ２は、画像データをＰＤＦからＴＩＦＦに変換してＦＡＸ送信するＦａｘ Ｓｅｒｖｉｃｅ７１４である。画像データをＰＤＦからＴＩＦＦに変換してＦＡＸ送信する場合において、ＦａｘＴｘ１が送信処理に関与する場合にはＪＳＤＫアプリ１４７で変換処理を実行する事になり、ＦａｘＴｘ２が送信処理に関与する場合にはＪＳＤＫプラットフォーム１４８で変換処理を実行する事になる。
【０１４４】
図２８は、ＦａｘＴｘ１やＦａｘＴｘ２の状態遷移モデルである。ＦａｘＴｘ１の状態には、初期状態７６０、Ｉｄｌｅ状態７６１、Ｓｅｎｄ状態７６２、及び終期状態７６４等が存在する。ＦａｘＴｘ２の状態には、初期状態７６０、Ｉｄｌｅ状態７６１、Ｓｅｎｄ状態７６２、Ｔｒａｎｓｆｏｒｍ状態７６３、及び終期状態７６４等が存在する。Ｉｄｌｅ状態７６１は、ＦＡＸ送信処理の待機中の状態である。Ｓｅｎｄ状態７６２は、ＦＡＸ送信処理を実行中の状態である。Ｔｒａｎｓｆｏｒｍ状態７６３は、画像変換処理を実行中の状態である。図２８により、ＦａｘＴｘ１とＦａｘＴｘ２は継承関係にある事が解る。ＦａｘＴｘ１が継承前のクラスであり、ＦａｘＴｘ２が継承後のクラスである。
【０１４５】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にて、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２では、自己の振る舞いを動的に継承する事で、自己の振る舞いを動的に変更する事ができる。例えば、図２７に示す通り、ＦａｘＴｘ１がＦａｘＴｘ２に動的に継承される事で、画像データをＰＤＦからＴＩＦＦに変換しない振る舞いが変換する振る舞いに動的に変更される事になる。
【０１４６】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にて、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２では、自己に振る舞い継承用のプラグイン部品をプラグインする事で、自己の振る舞いを動的に継承する事ができる。例えば、図２７に示す通り、画像データをＰＤＦからＴＩＦＦに変換するためのプラグイン部品の「ＰＤＦ２ＴＩＦＦ」のプラグインにより、ＦａｘＴｘ１がＦａｘＴｘ２に動的に継承される。振る舞い継承用のプラグイン部品は、Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３がＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に提供する。
【０１４７】
図２９は、Ｆａｘ Ｓｅｒｖｉｃｅに関するプラグイン処理を説明するための図である。
【０１４８】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にて、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２には、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１、Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３等のクラスが存在する。
【０１４９】
Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、ＦａｘＴｘ１やＦａｘＴｘ２の状態遷移モデルを管理するクラスである。Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３は、ＦａｘＴｘ１やＦａｘＴｘ２の状態遷移モデルに振る舞い継承用のプラグイン部品のプラグイン結果を反映させるクラスである。
【０１５０】
Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に振る舞い継承用のプラグイン部品がプラグインされた場合、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１が管理する状態遷移モデルに振る舞い継承用のプラグイン部品のプラグイン結果を反映させる。これによって、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞いが動的に変更される。
【０１５１】
図２６から図２９にかけてその概要を説明したＦａｘＴｘ１からＦａｘＴｘ２への拡張処理について更に具体的に説明する。
【０１５２】
拡張前のＦａｘ Ｓｅｒｖｉｃｅ７１４であるＦａｘＴｘ１は、図１３に示したモデルに基づいて、以下のようなオブジェクトによって構成される。
【０１５３】
図３０は、ＦａｘＴｘ１のオブジェクト構成を表す図である。ＦａｘＴｘ１は、図２８の状態遷移モデルに基づいて、初期状態オブジェクト７６０Ｓ、終期状態オブジェクト７６４Ｓ、Ｉｄｌｅ状態オブジェクト７６１Ｓ、Ｓｅｎｄ状態オブジェクト７６２Ｓ、送信開始オブジェクト７６５Ｔ、送信処理オブジェクト７６２Ａ等より構成されている。
【０１５４】
また、図３１はＦａｘＴｘ２のオブジェクト構成を表す図である。ＦａｘＴｘ２は、図２８の状態遷移モデルに基づいて、初期状態オブジェクト７６０Ｓ、終期状態オブジェクト７６４Ｓ、Ｉｄｌｅ状態オブジェクト７６１Ｓ、Ｓｅｎｄ状態オブジェクト７６２Ｓ、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓ、送信開始オブジェクト７６５Ｔ、送信処理オブジェクト７６２Ａ、変換処理オブジェクト７６３Ａ、変換終了オブジェクト７６６Ｔ等より構成されている。なお、図３０及び図３１においては、一部の遷移オブジェクトが省略されているが（例えば、Ｓｅｎｄ状態７６２から終期状態７６４への状態遷移に対応する遷移オブジェクト）、これは便宜的なものである。
【０１５５】
図３０及び図３１より、ＦａｘＴｘ１からＦａｘＴｘ２への拡張処理とは「Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓ」や「変換処理オブジェクト７６３Ａ」や「変換終了オブジェクト７６６Ｔ」といった拡張処理用のオブジェクトをＦａｘＴｘ１に対して追加する事で実現できることが分かる。
【０１５６】
Ｆａｘ Ｓｅｒｖｉｃｅ７１４の拡張処理の影響が顕著なオブジェクトが、Ｆａｘ Ｓｅｒｖｉｃｅ７１４の更新部分のオブジェクトである。Ｆａｘ Ｓｅｒｖｉｃｅ７１４の更新部分のオブジェクトとは、オブジェクトの入替部分やオブジェクトの追加部分（Ｆａｘ Ｓｅｒｖｉｃｅ７１４の更新部分）に連結するオブジェクトを意味する。図３０から図３１への拡張処理では、Ｆａｘ Ｓｅｒｖｉｃｅ７１４の更新部分に相当するのがスイッチ７７０等の追加部分であり、Ｆａｘ Ｓｅｒｖｉｃｅ７１４の更新部分のオブジェクトに相当するのがＳｅｎｄ状態オブジェクト７６２Ｓや送信開始オブジェクト７６５Ｔである。Ｆａｘ Ｓｅｒｖｉｃｅ７１４の拡張処理をＦａｘ Ｓｅｒｖｉｃｅ７１４の動作中に実行するには、Ｆａｘ Ｓｅｒｖｉｃｅ７１４の更新部分のオブジェクトがアクティブ状態ではないとき（非アクティブ状態のとき）に実行すればよい。
【０１５７】
図３２及び図３３は、ＦａｘＴｘ１の状態遷移情報の定義例を示す図である。図３２及び図３３によって一つの状態遷移情報１１００の記述例が示されている。なお、図中における行番号は、説明の便宜上付加したものである。
【０１５８】
状態遷移情報１１００の１２１行目における＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグのタグ名、及びそのｎａｍｅ属性の値（ＦａｘＴｘ１）によって、状態遷移情報１１００は、ＦａｘＴｘ１に対応するものであることが定義されている。また、当該＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグにおけるｘｍｉ．ｉｄ属性の値（「００４」）は、ＦａｘＴｘ１を識別するＩＤである。
【０１５９】
１２５行目の＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグは、ＦａｘＴｘ１における状態の定義の開始の宣言に相当する。当該宣言は、＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグのｘｍｉ．ｉｄの値（「０１７」）によって識別される。
【０１６０】
１３０行目から１３７行目における＜Ｐｓｅｕｄｏｓｔａｔｅ＞タグによって囲まれたＰｓｅｕｄｏｓｔａｔｅ要素１１１０は、初期状態７６０に対する定義である。Ｐｓｅｕｄｏｓｔａｔｅ要素１１１０のｎａｍｅ属性の値には「Ｉｎｉｔ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０１８」が設定されている。
【０１６１】
１３８行目から１４８行目におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１２０は、Ｓｅｎｄ状態７６２に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１２０のｎａｍｅ属性の値には「Ｓｅｎｄ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０１９」が設定されている。
【０１６２】
１４９行目から１５９行目におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１３０は、Ｉｄｌｅ状態７６１に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１３０のｎａｍｅ属性の値には「Ｉｄｌｅ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０２２」が設定されている。
【０１６３】
１６０行目から１８３行目におけるＰｓｅｕｄｏｓｔａｔｅ要素１１４０は、終期状態７６４に対する定義である。Ｐｓｅｕｄｏｓｔａｔｅ要素１１４０のｎａｍｅ属性の値には「ｅｎｄ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０２４」が設定されている。
【０１６４】
また、１９１行目から２２８行目には、ＦａｘＴｘ１における各状態遷移が定義されている。すなわち、１９１行目から２０４行目におけるＴｒａｎｓｉｔｉｏｎ要素１１５０は、Ｉｄｌｅ状態７６１からＳｅｎｄ状態７６２への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素１１５０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ要素１１５０の子要素として定義されている、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１５１及びＴｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１５２より特定される。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１５１は遷移元の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１５１の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０２２」である。したがって、遷移元は、ｘｍｉ．ｉｄ属性の値が「０２２」の状態、すなわち、Ｉｄｌｅ状態７６１であることが分かる。また、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１５２は遷移先の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１５２の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０１９」である。したがって、遷移先は、ｘｍｉ．ｉｄの値が「０１９」の状態、すなわち、Ｓｅｎｄ状態７６２であることが分かる。なお、Ｔｒａｎｓｉｔｉｏｎ要素１１５０のｎａｍｅ属性の値は「送信開始」であり、ｘｍｉ．ｉｄ属性の値は「０２３」である。
【０１６５】
２０５行目から２１８行目におけるＴｒａｎｓｉｔｉｏｎ要素１１６０は、Ｓｅｎｄ状態７６２から終期状態７６４への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素１１６０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１６１内のｘｍｉ．ｉｄｒｅｆ属性の値が「０１９」（Ｓｅｎｄ状態７６２）であり、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１６２内のｘｍｉ．ｉｄｒｅｆ属性の値が「０２４」（終期状態７６４）であることから特定される。なお、Ｔｒａｎｓｉｔｉｏｎ要素１１６０のｎａｍｅ属性の値は「送信終了」であり、ｘｍｉ．ｉｄ属性の値は「０２０」である。
【０１６６】
２１９行目から２２８行目におけるＴｒａｎｓｉｔｉｏｎ要素１１７０は、初期状態７６０からＩｄｌｅ状態７６１への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素１１７０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１７１内のｘｍｉ．ｉｄｒｅｆ属性の値が「０１８」（初期状態７６０）であり、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１７２内のｘｍｉ．ｉｄｒｅｆ属性の値が「０２２」（Ｉｄｌｅ状態７６１）であることから特定される。なお、Ｔｒａｎｓｉｔｉｏｎ要素１１７０のｘｍｉ．ｉｄ属性の値は「０１８」である。
【０１６７】
１３０行目以降の説明に戻る。各状態に対応する、Ｐｓｅｕｄｏｓｔａｔｅ要素１１１０、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１２０、及びＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１３０は、ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素及びＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素の少なくともいずれか一方を子要素として有する。ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素は、遷移元からの状態遷移に対する接続が定義される要素である。ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素は、遷移先への状態遷移に対する接続が定義される要素である。
【０１６８】
例えば、初期状態７６０に対応するＰｓｅｕｄｏｓｔａｔｅ要素１１１０におけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素１１１１において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０１８」である。したがって、初期状態７６０からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素１１７０が対応する状態遷移に相当することが分かる。
【０１６９】
また、Ｓｅｎｄ状態７６２に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１２０おけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素１１２１においてその子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０２０」であり、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素１１２２において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０２３」である。したがって、Ｓｅｎｄ状態７６２からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素１１６０が対応する状態遷移に相当し、遷移元の状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素１１５０が対応する状態遷移に相当することが分かる。
【０１７０】
なお、Ｉｄｌｅ状態７６１に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１３０、終期状態７６４に対応するＰｓｅｕｄｏｓｔａｔｅ要素１１４０においても同様に状態遷移との接続が定義されている。
【０１７１】
このような状態遷移情報に基づいて、ＦａｘＴｘ１のオブジェクト構成は構築される。なお、オブジェクト構成の構築処理は、図１５において説明したものに準ずるため、ここでの説明は省略する。
【０１７２】
上記をふまえて、Ｆａｘ Ｓｅｒｖｉｃｅ７１４の拡張処理を具体的に説明する。図３４は、Ｆａｘ Ｓｅｒｖｉｃｅの拡張処理を説明するためのシーケンス図である。
【０１７３】
例えば、管理者は、ＦａｘＴｘ２とＦａｘＴｘ１との差分の追加モジュールが格納されたＳＤカードを融合機１０１のメモリカードスロット２３４に挿入する（Ｓ６０１）。
【０１７４】
図３５は、ＳＤカード内の追加モジュールの構成例を示す図である。図３５に示されるＳＤカード２３５ａには、Ｆａｘ拡張インタフェース６１３−１ａと、更新差分サービスバンドル８４０と、ＡｓｐｅｃｔＳＭ．ｘｍｌファイル８５０（ＡｓｐｅｃｔＳＭ８５０）とが格納されている。Ｆａｘ拡張インタフェース６１３−１ａ（ＦａｘＴｘＥｘ）は、Ｆａｘ Ｓｅｒｖｉｃｅ７１４を拡張するためのＥｘｔｅｎｄ ＡＰＩ６１３−１に相当する。すなわち、Ｆａｘ拡張インタフェース６１３−１ａは、ＦａｘＴｘ２をユーザアプリ５０１に利用させるためのインタフェースを提供する。更新差分サービスバンドル８４０には、拡張処理を実行するにあたり、図１３のクラス図において、ＩＳｔａｔｅインタフェース１００４ａ、Ａｃｔｉｖｉｔｙインタフェース１００４ｂ、Ｅｖｅｎｔインタフェース１００３ａ、Ｇｕａｒｄインタフェース１００３ｂ、又はＡｃｔｉｏｎインタフェース１００３ｃに対応するクラスのうち、追加が必要とされるクラスが実装された機能モジュール（例えば、Ｊａｖａ（登録商標）のクラスファイル。以下「追加モジュール」という。））が格納されている。ここでは、追加モジュールとして、ＰＤＦ２Ｔｉｆｆ８４１とＣｏｎｖｅｒｔＥｎｄ８４２とが格納されている。
【０１７５】
ＡｓｐｅｃｔＳＭ８５０は、ＦａｘＴｘ１からＦａｘＴｘ２への拡張処理をどのように実施するかについての仕様がＸＭＬ形式記述されているファイルである。
【０１７６】
図３６は、Ｆａｘ Ｓｅｒｖｉｃｅの拡張内容が記述されたＡｓｐｅｃｔＳＭの記述例を示す図である。図中、行番号は説明の便宜上付加したものである。ＡｓｐｅｃｔＳＭ８５０には、ＦａｘＴｘ１の状態遷移情報１１００（図３２及び図３３）に対する変更内容が記述されている。
【０１７７】
ＡｓｐｅｃｔＳＭ８５０の記述例において、２行目は、ｘｍｉ．ｉｄの値が「００４」であるＦａｘＴｘ１に対して状態遷移の変更を行うことを指示している。すなわち、２行目におけるｘｍｉ．ｉｄｒｅｆ属性は、変更の対象となるステートマシンのｘｍｉ．ｉｄが指定される。
【０１７８】
３行目から２０行目までは一つ目の変更箇所に関する変更情報が記述されている。３行目には、変更箇所と変更タイミングが指定されている。変更箇所は、ｐｏｉｎｔｃｕｔ．＜ｘｘｘ＞における＜ｘｘｘ＞の記述とｘｍｉ．ｒｅｆ属性の値とによって指定される。ここで、＜ｘｘｘ＞の部分は「ＣｏｍｐｏｓｉｔｅＳｔａｔｅ」であり、ｘｍｉ．ｒｅｆ属性の値は「０１７」である。したがって、状態遷移情報１１００の１２５行目における＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグ内に対する変更が指定されていることになる。また、変更のタイミングは、ｔｉｍｉｎｇ属性の値によって指定される。ここでは、「Ｉｄｌｅ」が指定されている。したがって、ＦａｘＴｘ１がＩｄｌｅ状態７６１にあるときに、変更を行うべきことが指定されている。
【０１７９】
４行目には、変更の内容が指定されている。すなわち、＜ａｄｖｉｃｅ．ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグのタグ名におけるａｄｖｉｃｅ．以降によって、変更の対象がＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素であることが指定されている。また、ｔｙｐｅ属性によって、変更の種別が「ｉｎｓｅｒｔ」（挿入）であることが指定されている。すなわち、３行目及び４行目によって、＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグ内に新たなＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素を挿入すべき旨が指定されている。
【０１８０】
５行目から１８行目は、挿入の対象となるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１の定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１は、ＦａｘＴｘ２のＴｒａｎｓｆｏｒｍ状態７６３に対応する。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１内の記述形式は、図３２及び図３３において説明した通りである。すなわち、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１の子要素である、ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素８５２において遷移先への接続が定義され、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素８５３において遷移元への接続が定義されている。
【０１８１】
ところで、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１は、Ｓｔａｔｅ．ｅｎｔｒｙ要素８５４が子要素として定義されている。Ｓｔａｔｅ．ｅｎｔｒｙ要素８５４は、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１が対応するＴｒａｎｓｆｏｒｍ状態７６３における入場処理が定義される要素である。すなわち、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１の子要素として、Ａｃｔｉｏｎ要素８５５が定義されているが、そのｘｍｉ．ｉｄ属性とｎａｍｅ属性より、ｘｍｉ．ｉｄ属性の値が「０２６」であり、ｎａｍｅ属性の値がｐｄｆ２ｔｉｆｆによって識別される処理が実行されることが指定されている。
【０１８２】
２１行目から４２行目までは二つ目の変更箇所に関する変更情報が指定されている。２１行目には、変更箇所及び変更のタイミングが指定されている。ここでは、Ｉｄｌｅ状態７６１のときにＴｒａｎｓｉｔｉｏｎ要素１１５０（図３３参照）に対して変更を行うことが指定されている。
【０１８３】
二つ目の変更箇所には、二つの変更が指定されている。２２行目から２４行目までに一つ目の変更が指定されており、２５行目から４１行目までに二つ目の変更が指定されている。
【０１８４】
一つ目の変更については、２２行目の＜ａｄｖｉｃｅ．Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ＞タグのタグ名におけるａｄｏｖｉｃｅ．以降によって変更対象がＴｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１５２であることが指定されている。また、ｔｙｐｅ属性によって、変更の種別が修正（ｍｏｄｉｆｙ）であることが指定されている。２３行目には、変更の対象に関して修正後の定義が記述されている。すなわち、一つ目の変更は、Ｉｄｌｅ状態７６１からＳｅｎｄ状態７６２への状態遷移を、Ｉｄｌｅ状態７６１からＴｒａｎｓｆｏｒｍ状態７６３への状態遷移に修正することである。
【０１８５】
二つ目の変更（２５行目から４１行目）は、新たな状態遷移（Ｔｒａｎｆｏｒｍ状態６０５からＳｅｎｄ状態７６２への状態遷移）に対応するＴｒａｎｓｉｓｉｏｎ要素の挿入をＩｄｌｅ状態７６１のときに行うことである。この内容は、上記の説明から読み取れるため、各行毎の説明は省略する。
【０１８６】
４３行目から５５行目は、標準ではなく独自の書式に基づく定義が行われている拡張記述部分である。４３行目のｐｏｉｎｔｃｕｔ．以下の「ＸＭＩ．ｅｘｔｅｎｓｉｏｎ」によって、拡張記述部分であることが指定されている。本実施の形態では、この部分に、状態遷移処理で呼ばれるアクション処理と、イベント処理等に使用する機能モジュール（例えば、Ｊａｖａ（登録商標）クラス）との関連付けが定義される。
【０１８７】
４４行目では、当該ａｄｖｉｃｅ要素の子要素の定義を挿入（ｉｎｓｅｒｔ）すべきことが指定されている。
【０１８８】
４５行目から４９行目までは、挿入される定義である。４５行目には、Ｂｕｎｄｌｅを実装することが指定されている。Ｂｕｎｄｌｅの実装先は、ｘｍｉ．ｉｄｒｅｆ属性の値（「００４」）で指定される。すなわち、ＦａｘＴｘ１である。
【０１８９】
４６行目から４９行目までは、Ｔｒａｎｓｆｏｒｍ状態７６３に対応させて新たに挿入するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１（５行目から１８行目）の入場処理の定義（１５行目から１７行目）におけるｐｄｆ２ｔｉｆｆと、実際にその処理が実装されているｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｐｄｆ２ｔｉｆｆクラスとの関連付けが定義されている。これによって、ＦａｘＴｘ２に更新された後、Ｔｒａｎｓｆｏｒｍ状態７６３に遷移したときには、ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｐｄｆ２ｔｉｆｆが実行されることになる。４８行目のｐｒｏｐｅｒｔｙ要素は、ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｐｄｆ２ｔｉｆｆクラスが実行されるときのプロパティ情報である。
【０１９０】
５０行目から５２行目は、Ｔｒａｎｓｆｏｒｍ状態７６３からＳｅｎｄ状態７６２への状態遷移のトリガとなる変換完了イベントとｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｃｏｎｖｅｒｔＥｎｄクラスとの関連付けが定義されている。これによって、Ｔｒａｎｅｆｏｒｍ状態６０５中に変換完了イベントが検知されると、ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｃｏｎｖｅｒｔＥｎｄクラスが実行され、その実行結果がｔｒｕｅであれば、Ｓｅｎｄ状態７６２に遷移することになる。
【０１９１】
図３４に戻る。管理者によるＳＤカード２３５ａの挿入が自動的に検知されると、又はＳＤカード２３５ａが挿入され、オペレーションパネル２０２から更新指示が入力されると、ＳＡＳ４１１は、ＳＡＳ Ｍａｎａｇｅｒ５１１に拡張処理の実行を要求する（Ｓ６０２）。なお、ＳＤカード２３５ａに記録された情報は、ネットワークを介してダウンロードされてもよい。この場合、ＳＤカードのような記録媒体を用いる必要はない。
【０１９２】
ＳＡＳ Ｍａｎａｇｅｒ５１１は、挿入されたＳＤカード２３５ａの更新差分サービスバンドル８４０によるＦａｘＴｘ１からＦａｘＴｘ２への更新の可否についてチェックを行う（Ｓ６０３）。更新が可能な場合、ＳＡＳ Ｍａｎａｇｅｒ５１１は、更新差分サービスバンドル８４０の融合機１０１へのインストールの可否をチェックする（Ｓ６０４）。インストールが可能な場合、ＳＡＳ Ｍａｎａｇｅｒ５１１は、ＳＤカード２３５ａ内の更新差分サービスバンドル８４０をＯＳＧｉフレームワーク４０３（融合機１０１）にインストールする（Ｓ６０５）。更新差分サービスバンドル８４０のインストールが完了すると、ＳＡＳ Ｍａｎａｇｅｒ５１１は、更新差分サービスバンドル８４０をアクティブ状態に遷移させるようにＯＳＧｉフレームワーク４０３に要求する（Ｓ６０６）。
【０１９３】
ＯＳＧｉフレームワーク４０３は、更新差分サービスバンドル８４０のインスタンスを（以下、「更新差分オブジェクト８４０ａ」という。）生成し、アクティブな状態に遷移させる（Ｓ６０７）。
【０１９４】
続いて、ＳＡＳ Ｍａｎａｇｅｒ５１１は、Ｆａｘ拡張インタフェース６１３−１ａをＯＳＧｉフレームワーク４０３にインストールし（Ｓ６０８）、Ｆａｘ拡張インタフェース６１３−１ａのＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１への組み込みをＥｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３に要求する（Ｓ６０９）。
【０１９５】
続いて、Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３が、Ｆａｘ拡張インタフェース６１３−１ａをアクティブな状態にするようＯＳＧｉフレームワーク４０３に要求すると（Ｓ６１０）、ＯＳＧｉフレームワーク４０３は、Ｆａｘ拡張インタフェース６１３−１ａをアクティブな状態に遷移させる。（Ｓ６１１）。Ｆａｘ拡張インタフェース６１３−１ａがアクティブな状態に遷移すると、Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３は、Ｆａｘ拡張インタフェース６１３−１ａをＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に登録する（Ｓ６１２）。これによって、Ｆａｘ拡張インタフェース６１３−１ａの呼び出しが可能となる。
【０１９６】
一方、ステップＳ６０７においてアクティブな状態にされた更新差分オブジェクト８４０ａは、Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３に対して更新差分サービスバンドル８４０がプラグインされたことをＡｓｐｅｃｔＳＭ８５０を添えて通知する（Ｓ６１３）。Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１より、ＦａｘＴｘ１のオブジェクト（ＦａｘＴｘ１オブジェクト７１４ａ）を取得する（Ｓ６１４、Ｓ６１５）。
【０１９７】
Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３は、ＦａｘＴｘ１オブジェクト７１４ａに対して、ＡｓｐｅｃｔＳＭ８５０を添えてＦａｘＴｘ２への更新要求を行う（Ｓ６１６）。ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０に基づいて、サービスバンドルＦａｘＴｘ１をＦａｘＴｘ２へ更新する為に必要な追加モジュール判断し、当該追加モジュール（ここでは、ＰＤＦ２Ｔｉｆｆ８４１及びＣｏｎｖｅｒｔＥｎｄ８４２）の取得を更新差分オブジェクト８４０ａに要求する（Ｓ６１７）。更新差分オブジェクト８４０ａは、当該追加モジュールを取得し、ＦａｘＴｘ１オブジェクト７１４ａに返却する（Ｓ６１８）。
【０１９８】
続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０に従って、ＦａｘＴｘ１のオブジェクト構成を、ＦａｘＴｘ２に対応するものに更新すると共に、当該更新によって新たに追加されたＡｃｔｉｖｉｔｙオブジェクトと追加モジュールとの関連付けを行う（Ｓ６１９）。なお、ステップＳ６１９の処理は、ＡｓｐｅｃｔＳＭ８５０に記述されているタイミングで行われる。
【０１９９】
続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＦａｘＴｘ１についてＦａｘＴｘ２への更新が完了したことをＰｌｕｇｉｎ Ａｇｅｎｔ７３３に通知する（Ｓ６２０）。但し、ＦａｘＴｘ１をＦａｘＴｘ２に切り替えるスイッチ７７０は、ＦａｘＴｘ１の状態のままである。
【０２００】
更新が完了した旨の通知は、ＳＡＳ Ｍａｎａｅｒ５１１を介してＳＡＳ４１１に通知される（Ｓ６２１、Ｓ６２２）。ＳＡＳ４１１は、管理者に更新完了を通知するため、オペレーションパネル２０２に更新完了を通知するメッセージを表示させる（Ｓ６２３）。なお、この状態では、スイッチ７７０は、まだＦａｘＴｘ２には切り替えられていないので、ＳＡＳ４１１は、管理者にＦａｘＴｘ２へ切り替える否かを問い合わせる。
【０２０１】
そこで、管理者が、オペレーションパネル２０２を介してＦａｘＴｘ２への切替指示を入力すると（Ｓ６２４）、ＳＡＳ４１１は、ＦａｘＴｘ２への切替要求をＳＡＳ Ｍａｎａｇｅｒ５１１に通知する（Ｓ６２５）。ＳＡＳ Ｍａｎａｇｅｒ５１１は、Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３にＦａｘＴｘ２への切り替えを要求する（Ｓ６２６）。Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３は、ＦａｘＴｘ１オブジェクト７１４ａに対して、その振る舞い（状態遷移）をＦａｘＴｘ２に対応するものに切り替えるように指示する（Ｓ６２７）。
【０２０２】
ＦａｘＴｘ１オブジェクト７１４ａは、ＦａｘＴｘ１がＩｄｌｅ状態７６１になるまで待機する。Ｉｄｌｅ状態７６１に遷移すると、ＦａｘＴｘ１オブジェクト７１４ａは、スイッチ７７０を切り換えることにより、自己の振る舞いをＦａｘＴｘ２に対応するものに切り替える（Ｓ６２８）。切り替えが完了すると、ＦａｘＴｘ１オブジェクト７１４ａは、Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３に対して、切替完了通知を行う（Ｓ６２９）。切替完了通知は、ＳＡＳ Ｍａｎａｇｅｒ５１１を介してＳＡＳ４１１に伝達される（Ｓ６３０、Ｓ６３１）。ＳＡＳ４１１は、切替完了通知に応じ、ＦａｘＴｘ１の切り替えが完了した旨をオペレーションパネル２０２に表示させる（Ｓ６３２）。
【０２０３】
次に、ステップＳ６１９における、ＦａｘＴｘ１のオブジェクト構成の更新処理の詳細について説明する。図３７は、ＦａｘＴｘ１のオブジェクト構成の更新処理を説明するためのシーケンス図である。
【０２０４】
まず、ＦａｘＴｘ１オブジェクト７１４ａは、ＦａｘＴｘ１の状態が、ＡｓｐｅｃｔＳＭ８５０に指定されている変更箇所ごとにおけるｔｉｍｉｎｇ属性の値に指定されている状態に遷移するまで待機する（Ｓ６１９１）。図３６のＡｓｐｅｃｔＳＭ８５０の例では、全ての変更箇所に対するタイミングは、Ｉｄｌｅ状態７６１として指定されている。したがって、ここでは、Ｉｄｌｅ状態７６１に遷移するまで待機する。
【０２０５】
ＦａｘＴｘ１の状態がＩｄｌｅ状態７６１に遷移すると、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の記述にしたがって、拡張処理を開始する。
【０２０６】
例えば、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の３行目から２０行目に基づいてＴｒａｎｓｆｏｒｍ状態７６３に対応するＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓを生成する（Ｓ６１９２）。続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の２５行目から４１行目に基づいて、変換終了オブジェクト７６６Ｔを生成する（Ｓ６１９３）。続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の９行目から１４行目や、２２行目から２４行目に基づいて、オブジェクト間の接続関係を変更する。すなわち、ＦａｘＴｘ１オブジェクト７１４ａは、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓの識別情報を引数としてＩｄｌｅ状態オブジェクト７６１Ｓのｒｅｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ６１９４）。これに応じて、Ｉｄｌｅ状態オブジェクト７６１Ｓは、遷移先の状態オブジェクトとして、Ｓｅｎｄ状態オブジェクト７６２ＳとＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓとを保持することになる。これは、ちょうど図３１において、スイッチ７７０によって遷移先が分岐している状態に相当する。スイッチ７７０は、例えば、Ｉｄｌｅ状態オブジェクト７６１Ｓが参照可能なフラグ変数として実装される。例えば、当該フラグ変数の値が０のときには遷移先はＳｅｎｄ状態オブジェクト７６２Ｓとされ、１のときには遷移先はＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓとされるといった具合である。なお、Ｉｄｌｅ状態オブジェクト７６１ＳとＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓとの接続は行われたが、図３４において説明したように、この時点では、スイッチ７７０は切り替えられていないため、Ｉｄｌｅ状態オブジェクト７６１Ｓからの遷移先のオブジェクトはＳｅｎｄ状態オブジェクト７６２Ｓのままである（すなわち、ＦａｘＴｘ１として機能する。）。
【０２０７】
続いて、ＦａｘＴｘ１オブジェクト７１４ａは、Ｓｅｎｄ状態オブジェクト７６２Ｓの識別情報と変換完了オブジェクト７６６Ｔの識別情報とを引数としてＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓのｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ６１９５）。これに応じて、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓは、Ｓｅｎｄ状態オブジェクト７６２Ｓの識別情報と変換完了オブジェクト７６６Ｔの識別情報とを関連付けて保持する。すなわち、変換終了イベントが発生した際のＴｒａｎｓｆｏｒｍ状態７６３からＳｅｎｄ状態７６２への状態遷移に対応する接続が構築されたことになる。
【０２０８】
続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の４３行目から５５行目に基づいて、追加モジュールとオブジェクトとの関連付けを行う。すなわち、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓの入場処理のインタフェース（ＩＳｔａｔｅインタフェース１００４ａ）に対してＰＤＦ２ＴＩＦＦ８４１を関連付ける（Ｓ６１９６）。続いて、変換完了オブジェクト７６６ＴのＥｖｅｎｔインタフェース１００３ａに対してＣｏｎｖｅｒｔＥｎｄ８４２を関連付ける（Ｓ６１９７）。
【０２０９】
以上の処理によって、ＦａｘＴｘ１のオブジェクト構成は、図３１に示されるようなもの（ＦａｘＴｘ２）に更新される。
【０２１０】
ところで、図３６において、ＡｓｐｅｃｔＳＭ８５０にはＦａｘＴｘ１の状態遷移情報１１００（図３２及び図３３）に対する変更内容が記述されていると説明した。しかし、上記のように、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０に基づいて状態遷移情報１１００を書き換えるのではなく、ＦａｘＴｘ１を構成するオブジェクトを変更することで拡張処理を実現する。ＦａｘＴｘ１は、状態遷移情報１１００に基づいてそのオブジェクトが構築されたものである。したがって、状態遷移情報１１００に対する変更内容が記述されたＡｓｐｅｃｔＳＭ８５０は、そのままＦａｘＴｘ１のオブジェクト構成に適用することができるのである。なお、ＡｓｐｅｃｔＳＭ８５０に基づいて状態遷移情報１１００を更新し、更新された状態遷移情報１１００に基づいてＦａｘＴｘ１（厳密には、ＦａｘＴｘ２に更新されたもの）を再構築してもよい。但し、この場合、再構築の前にＦａｘＴｘ１を構成するオブジェクト群が破棄されるため、ＦａｘＴｘ１を利用中のアプリケーション等との参照関係が破壊されてしまう。したがって、本実施の形態のように、オブジェクト群を再構築するのではなく、既存のオブジェクト構成を変更する方が好適である。
【０２１１】
なお、上記のように、拡張処理後は、ＦａｘＴｘ１とＦａｘＴｘ２とは、スイッチ７７０を切り替えることにより容易に切り替えが可能である。したがって、ＦａｘＴｘ１からＦａｘＴｘ２への更新後、再度ＦａｘＴｘ２からＦａｘＴｘ１に戻したい場合は、スイッチ７７０を切り替えることにより実現すればよい。すなわち、Ｉｄｌｅ状態オブジェクト７６１Ｓが参照可能なフラグ変数の値を更新すればよい。また、ＦａｘＴｘ２からＦａｘＴｘ１への更新指示が記述されたＡｓｐｅｃｔＳＭに基づいて、ＦａｘＴｘ２からＦａｘＴｘ１への更新を実現してもよい。この場合スイッチ７７０を切り替えるタイミングは、当該ＡｓｐｅｃｔＳＭに記述されたタイミングで行われる。
【０２１２】
上述したように、本実施の形態では、ＡｓｐｅｃｔＳＭ８５０には、拡張部分が非アクティブなタイミングでＦａｘ Ｓｅｒｖｉｃｅ７１４の拡張が行われるような拡張指示が記述されている。そして、かかるＡｓｐｅｃｔＳＭ８５０に従って、拡張部分が非アクティブなときに拡張が実行される。したがって、本実施の形態におけるＦａｘ Ｓｅｒｖｉｃｅ７１４は、当該Ｆａｘ Ｓｅｒｖｉｃｅ７１４の実行中にその振る舞いの拡張を実行することができる。また、振る舞いの拡張にあたり、オブジェクト群が再構築されるわけではないので、当該Ｆａｘ Ｓｅｒｖｉｃｅ７１４の参照側との参照関係が破壊されることなく、動的にその振る舞いを拡張することが可能となっている。よって、融合機１０１を再起動することなくＦａｘ Ｓｅｒｖｉｃｅ７１４の振る舞いは拡張され得る。
【０２１３】
４）ＯＳＧｉ
図３８は、Ｓｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙ８０１について説明するためのクラス図である。Ｓｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙ８０１は、ＯＳＧｉフレームワーク４０３を構成するクラスである。サービス提供側であるＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、自己が提供するサービス内容をＳｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙ８０１に登録（Ｓ３０１）し、サービス要求側であるユーザアプリ５０１は、自己が要求するサービス内容をＳｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙ８０１から検索（Ｓ３０２）する。これによって、ユーザアプリ５０１は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求（Ｓ３０３）して、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、ユーザアプリ５０１にサービスを提供（Ｓ３０４）する。
【０２１４】
図３９は、状態遷移モデルのバンドル化手順について説明するためのデータ図である。状態遷移モデルは、振る舞いと部品に分離されて設計される。振る舞いはＸＭＩ言語にて記述されて、部品はＪａｖａ（登録商標）言語にて記述される。ＸＭＩ言語によるコードとＪａｖａ（登録商標）言語によるコードはＯＳＧｉによるバンドル化手順に従ってバンドル化される。バンドルには、マニフェストファイル８０２が同梱される。マニフェストファイル８０２には、バンドルにとって必要な情報が格納される。
【０２１５】
図４０・図４１は、ＣＳＣ４２１について説明するための図である。融合機１０１には他機のＯＳＧｉサービスプラットフォームを自機のＯＳＧｉサービスプラットフォームと同様に処理するためのＣＳＣ４２１が実装されている。ＣＳＣ４２１の実装態様は、図６に示す通りである。
【０２１６】
図４０は他機が融合機１０１である場合を表し、図４１は他機がＰＣ８０３である場合を表す。図４０・図４１に示す通り、自機のＣＳＣ４２１と他機のＣＳＣ４２１の仲介によって、自機のＳＡＳ Ｍａｎａｇｅｒ５１１と他機のＳＡＳ Ｍａｎａｇｅｒ５１１の連携が実現される。
【図面の簡単な説明】
【０２１７】
【図１】本発明の実施例に該当する融合機を表す。
【図２】図１の融合機に係るハードウェア構成図である。
【図３】図１の融合機に係る外観図である。
【図４】オペレーションパネルを表す。
【図５】図１のＣＳＤＫアプリとＪＳＤＫアプリのソフトウェア構成図である。
【図６】図１の融合機におけるＯＳＧｉについて説明するための図である。
【図７】図１のＪＳＤＫアプリとＪＳＤＫプラットフォームのクラス図である。
【図８】ＪＳＤＫシステムの起動処理を説明するための図である。
【図９】Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅについて説明するためのクラス図である。
【図１０】Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの動作の説明図である。
【図１１】Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの動作の具体例の説明図である。
【図１２】Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの振る舞い変更処理について概念的に説明するための図である。
【図１３】Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの振る舞いの動的な変更を実現するクラス群を説明するためのクラス図である。
【図１４】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅのオブジェクト構成を表す図である。
【図１５】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅのオブジェクト構成の構築処理を説明するためのシーケンス図である。
【図１６】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの状態遷移情報の定義例を示す図である。
【図１７】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの状態遷移情報の定義例を示す図である。
【図１８】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの振る舞い変更処理を説明するためのシーケンス図である。
【図１９】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの振る舞い変更処理を説明するためのシーケンス図である。
【図２０】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの振る舞いの変更内容が記述されたＡｓｐｅｃｔＳＭの記述例を示す図である。
【図２１】Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅについて説明するためのクラス図である。
【図２２】Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅについて説明するためのクラス図である。
【図２３】Ｍｏｄｉｆｙ ＳｅｒｖｉｃｅによるＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの変更処理を説明するためのシーケンス図である。
【図２４】Ｆａｘ送信アプリに対応させて登録されたＡｓｐｅｃｔＳＭの記述例を示す図である。
【図２５】Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌによるイベントの通知方式について説明するための図である。
【図２６】Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅについて説明するためのクラス図である。
【図２７】Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅの動作の概要を説明するための図である。
【図２８】ＦａｘＴｘ１やＦａｘＴｘ２の状態遷移モデルである。
【図２９】Ｆａｘ Ｓｅｒｖｉｃｅに関するプラグイン処理を説明するための図である。
【図３０】ＦａｘＴｘ１のオブジェクト構成を表す図である。
【図３１】ＦａｘＴｘ２のオブジェクト構成を表す図である。
【図３２】ＦａｘＴｘ１の状態遷移情報の定義例を示す図である。
【図３３】ＦａｘＴｘ１の状態遷移情報の定義例を示す図である。
【図３４】Ｆａｘ Ｓｅｒｖｉｃｅの拡張処理を説明するためのシーケンス図である。
【図３５】ＳＤカード内の追加モジュールの構成例を示す図である。
【図３６】Ｆａｘ Ｓｅｒｖｉｃｅの拡張内容が記述されたＡｓｐｅｃｔＳＭの記述例を示す図である。
【図３７】ＦａｘＴｘ１のオブジェクト構成の更新処理を説明するためのシーケンス図である。
【図３８】Ｓｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙについて説明するためのクラス図である。
【図３９】状態遷移モデルのバンドル化手順について説明するためのデータ図である。
【図４０】ＣＳＣについて説明するための図（同機種の場合）である。
【図４１】ＣＳＣについて説明するための図（別機種の場合）である。
【符号の説明】
【０２１８】
１０１ 融合機
１１１ ハードウェア
１１２ ソフトウェア
１１３ 融合機起動部
１２１ 撮像部
１２２ 印刷部
１２３ その他のハードウェア
１３１ アプリケーション
１３２ プラットフォーム
１３３ アプリケーションプログラムインタフェース
１３４ エンジンインタフェース
１３５ 仮想アプリケーションサービス
１４１ コピーアプリ
１４２ プリンタアプリ
１４３ スキャナアプリ
１４４ ファクシミリアプリ
１４５ ネットワークファイルアプリ
１４６ ＣＳＤＫアプリ
１４７ ＪＳＤＫアプリ
１４８ ＪＳＤＫプラットフォーム
１５１ コントロールサービス
１５２ システムリソースマネージャ
１５３ ハンドラ
１６１ ネットワークコントロールサービス
１６２ ファクシミリコントロールサービス
１６３ デリバリコントロールサービス
１６４ エンジンコントロールサービス
１６５ メモリコントロールサービス
１６６ オペレーションパネルコントロールサービス
１６７ サーティフィケーションコントロールサービス
１６８ ユーザディレクトリコントロールサービス
１６９ システムコントロールサービス
１７１ ファクシミリコントロールユニットハンドラ
１７２ イメージメモリハンドラ
２０１ コントローラ
２０２ オペレーションパネル
２０３ ファクシミリコントロールユニット
２１１ ＣＰＵ
２１２ ＡＳＩＣ
２２１ ＮＢ
２２２ ＳＢ
２３１ ＭＥＭ−Ｐ
２３２ ＭＥＭ−Ｃ
２３３ ＨＤＤ
２３４ メモリカードスロット
２３５ メモリカード
２４１ ＮＩＣ
２４２ ＵＳＢデバイス
２４３ ＩＥＥＥ１３９４デバイス
２４４ セントロニクスデバイス
３０１ 原稿セット部
３０２ 給紙部
３０３ 排紙部
３１１ タッチパネル
３１２ テンキー
３１３ スタートボタン
３１４ リセットボタン
３１５ 機能キー
３１６ 初期設定ボタン
３２１ ＡＤＦ
３２２ フラットベッド
３２３ フラットベッドカバー
４０１ ＯＳＧｉアプリ
４０２ ＯＳＧｉサービス
４０３ ＯＳＧｉフレームワーク
４０４ Ｂｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ
４１１ ＳＡＳ
４２１ ＣＳＣ
５０１ ユーザアプリ
５１１ ＳＡＳ Ｍａｎａｇｅｒ
５１２ Ｓｃｒｅｅｎ Ｍａｎａｇｅｒ
５２１ ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ
５３１ Ｘｌｅｔ Ｍａｎａｇｅｒ
５３２ Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ
５４１ Ｓｅｎｄ Ｍａｎａｇｅｒ
５４２ Ｅｖｅｎｔ Ｍａｎａｇｅｒ
５４３ Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ
５４４ Ｐａｎｅｌ Ｍａｎａｇｅｒ
５４５ Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ
５４６ Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ
５４７ Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒ
５５１ ＪＳＤＫ ＡＰＩ
５５２ ＪＳＤＫ ＡＰＩ
５５３ ＪＳＤＫ Ｓｅｓｓｉｏｎ
５５４ Ｎａｔｉｖｅ ＪＳＤＫ Ｓｅｓｓｉｏｎ
５５５ ＣＶＭ
６０１ Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ
６０２ Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ
６０３ Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ
６１１ Ｆｕｎｃｔｉｏｎ ＡＰＩ
６１２ Ｍｏｄｉｆｙ ＡＰＩ
６１３ Ｅｘｔｅｎｄ ＡＰＩ
６２１ Ｃ／Ｊ ＡＰＩ
７０１ Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ
７０２ Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ
７１１ Ｃｏｐｙ Ｓｅｒｖｉｃｅ
７１２ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ
７１３ Ｓｃａｎ Ｓｅｒｖｉｃｅ
７１４ Ｆａｘ Ｓｅｒｖｉｃｅ
７２１ ＳＡＳ Ｓｅｒｖｉｃｅ
７３１ Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ
７３２ Ｍｏｄｉｆｙ Ａｇｅｎｔ
７３３ Ｐｌｕｇｉｎ Ａｇｅｎｔ
７４１ Ｉｄｌｅ状態
７４２ Ｐｒｉｎｔ状態
７４３ 印刷開始イベント
７４４ 印刷終了イベント
７４６ ガード条件オブジェクト
７４１Ｓ Ｉｄｌｅ状態オブジェクト
７４２Ｓ Ｐｒｉｎｔ状態オブジェクト
７４３Ｔ 印刷開始オブジェクト
７４４Ｔ 印刷終了オブジェクト
７５１ Ｉｄｌｅ状態
７５２ ＦａｘＳｅｎｄ状態
７５３ 送信開始イベント
７５４ 送信終了イベント
７６０ 初期状態
７６１ Ｉｄｌｅ状態
７６２ Ｓｅｎｄ状態
７６３ Ｔｒａｎｓｆｏｒｍ状態
７６４ 終期状態
８０１ Ｓｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙ
８０２ マニフェストファイル
８０３ ＰＣ
８１０、８２０ ＡｓｐｅｃｔＳＭ
９００、１１００ 状態遷移情報
１０００ ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌクラス
１００１ ＳｔａｔｅＭａｃｈｉｎｅクラス
１００２ ＳｔａｔｅＶｅｒｔｅｘクラス
１００３ Ｔｒａｎｓｉｔクラス
１００３ａ Ｅｖｅｎｔインタフェース
１００３ｂ Ｇｕａｒｄインタフェース
１００３ｃ Ａｃｔｉｏｎインタフェース
１００４ Ｓｔａｔｅクラス
１００４ａ ＩＳｔａｔｅインタフェース
１００４ｂ Ａｃｔｉｖｉｔｙインタフェース
１００５ ＰｓｅｕｄｏＳｔａｔｅクラス
１００６ ＩｎｉｔｉａｌＳｔａｔｅクラス
１００７ ＦｉｎａｌＳｔａｔｅクラス
１００８ ＰｌｕｇｉｎＡｇｅｎｔクラス
１００９ ＭｏｄｉｆｙＡｇｅｎｔクラス
【技術分野】
【０００１】
本発明は、コピー／プリンタ／スキャナ／ファクシミリ／複合機／融合機等の画像形成装置、情報処理方法、情報処理プログラム、ＳＤメモリカード等の記録媒体に関する。
【背景技術】
【０００２】
近年、コピー機能とプリンタ機能とスキャナ機能とファクシミリ機能を備える複合機や融合機が市販されるようになった。複合機や融合機は、コピーやプリンタとして機能する場合には、画像を印刷用紙に印刷することになり、コピーやスキャナとして機能する場合には、画像を読取原稿から読み取ることになり、ファクシミリとして機能する場合には、画像を電話回線を介して他の機器と授受することになる。
【特許文献１】特開２００２−８４３８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
近年、複合機や融合機には様々なアプリケーションやプラットフォームが実装される。そんな中で問題視されるのが、次々に登場する新規なアプリケーションに既存のプラットフォームが対応し切れなくなるのではないかと言う点である。プラットフォームの設計時において、随時開発されるアプリケーション同士の差異を考慮したり将来開発される種々のアプリケーションの機能を予測したりするのは非常に困難である。従って、アプリケーションの種類によってはプラットフォームの影響で正常に動作しない可能性も出て来る。従って、アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを実現する事が望まれる。
【０００４】
本発明は、アプリケーションやプラットフォームが実装される画像形成装置に関して、アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを実現することを課題とする。
【課題を解決するための手段】
【０００５】
そこで上記課題を解決するため、本発明は、アプリケーションにサービスを提供し互いに排他的に動作する複数のモジュールの接続によって構成されるサービス提供プログラムを備える画像形成装置であって、前記サービス提供プログラムの変更情報の入力を受け付ける入力手段と、前記サービス提供プログラムの動作状態が、前記変更情報において指定されている変更のタイミングに相当するか否かを判定するタイミング判定手段と、前記タイミング判定手段によって前記変更のタイミングであると判定されたときに、前記変更情報に従って、前記複数のモジュールの接続関係を変更する変更手段と、前記変更が施された前記サービス提供プログラムを前記アプリケーションに利用させるためのインタフェースを追加するインタフェース追加手段とを有することを特徴とする。
【０００６】
このような画像形成装置では、アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを実現することができる。
【発明の効果】
【０００７】
本発明は、アプリケーションやプラットフォームが実装される画像形成装置に関して、アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを実現するものである。
【発明を実施するための最良の形態】
【０００８】
図１は、本発明の実施例に該当する融合機１０１を表す。図１の融合機１０１は、種々のハードウェア１１１と、種々のソフトウェア１１２と、融合機起動部１１３により構成される。
【０００９】
融合機１０１のハードウェア１１１としては、撮像部１２１と、印刷部１２２と、その他のハードウェア１２３が存在する。撮像部１２１は、読取原稿から画像（画像データ）を読み取るためのハードウェアである。印刷部１２２は、画像（画像データ）を印刷用紙に印刷するためのハードウェアである。
【００１０】
融合機１０１のソフトウェア１１２としては、種々のアプリケーション１３１と、種々のプラットフォーム１３２が存在する。これらのプログラムは、ＵＮＩＸ（登録商標）等のＯＳ（オペレーティングシステム）によりプロセス単位で並列的に実行される。
【００１１】
アプリケーション１３１としては、コピー用のアプリケーションであるコピーアプリ１４１、プリンタ用のアプリケーションであるプリンタアプリ１４２、スキャナ用のアプリケーションであるスキャナアプリ１４３、ファクシミリ用のアプリケーションであるファクシミリアプリ１４４、ネットワークファイル用のアプリケーションであるネットワークファイルアプリ１４５が存在する。
【００１２】
アプリケーション１３１は、専用のＳＤＫ（ソフトウェア開発キット）を使用して開発することができる。ＳＤＫを使用して開発したアプリケーション１３１をＳＤＫアプリと呼ぶ。専用のＳＤＫとしては、Ｃ言語でアプリケーション１３１を開発するための「ＣＳＤＫ」や、Ｊａｖａ（登録商標）言語でアプリケーション１３１を開発するための「ＪＳＤＫ」が提供される。ＣＳＤＫを使用して開発したアプリケーション１３１を「ＣＳＤＫアプリ」と呼び、ＪＳＤＫを使用して開発したアプリケーション１３１を「ＪＳＤＫアプリ」と呼ぶ。図１の融合機１０１にも、ＣＳＤＫアプリ１４６と、ＪＳＤＫアプリ１４７が存在する。図１の融合機１０１にはさらに、Ｊａｖａ（登録商標）言語で記述されたＪＳＤＫアプリ１４７とＣ言語で記述された他のソフトウェア１１２との仲介を行うソフトウェア１１２として、ＪＳＤＫプラットフォーム１４８が存在する。
【００１３】
プラットフォーム１３２としては、種々のコントロールサービス１５１、システムリソースマネージャ１５２、種々のハンドラ１５３が存在する。コントロールサービス１５１としては、ネットワークコントロールサービス（ＮＣＳ）１６１、ファクシミリコントロールサービス（ＦＣＳ）１６２、デリバリコントロールサービス（ＤＣＳ）１６３、エンジンコントロールサービス（ＥＣＳ）１６４、メモリコントロールサービス（ＭＣＳ）１６５、オペレーションパネルコントロールサービス（ＯＣＳ）１６６、サーティフィケーションコントロールサービス（ＣＣＳ）１６７、ユーザディレクトリコントロールサービス（ＵＣＳ）１６８、システムコントロールサービス（ＳＣＳ）１６９が存在する。ハンドラ１５３としては、ファクシミリコントロールユニットハンドラ（ＦＣＵＨ）１７１、イメージメモリハンドラ（ＩＭＨ）１７２が存在する。
【００１４】
ＮＣＳ１６１のプロセスは、ネットワーク通信の仲介を行う。ＦＣＳ１６２のプロセスは、ファクシミリのＡＰＩを提供する。ＤＣＳ１６３のプロセスは、蓄積文書の配信処理に関する制御を行う。ＥＣＳ１６４のプロセスは、撮像部１２１や印刷部１２２に関する制御を行う。ＭＣＳ１６５のプロセスは、メモリやハードディスクドライブに関する制御を行う。ＯＣＳ１６６のプロセスは、オペレーションパネルに関する制御を行う。ＣＣＳ１６７のプロセスは、認証処理や課金処理に関する制御を行う。ＵＣＳ１６８のプロセスは、ユーザ情報の管理に関する制御を行う。ＳＣＳ１６９のプロセスは、システムの管理に関する制御を行う。
【００１５】
アプリケーション１３１とプラットフォーム１３２の仲介を行うソフトウェア１１２として、仮想アプリケーションサービス（ＶＡＳ）１３５が存在する。ＶＡＳ１３５は、アプリケーション１３１をクライアントとするサーバプロセスとして動作すると共に、プラットフォーム１３２をサーバとするクライアントプロセスとして動作する。ＶＡＳ１３５は、アプリケーション１３１から見てプラットフォーム１３２を隠蔽するラッピング機能を備え、プラットフォーム１３２のバージョンアップに伴うバージョン差を吸収する役割等を担う。
【００１６】
融合機起動部１１３は、融合機１０１の電源投入時に最初に実行される。これにより、ＵＮＩＸ（登録商標）等のＯＳが起動され、アプリケーション１３１やプラットフォーム１３２が起動される。これらのプログラムは、ハードディスクドライブやメモリカードに蓄積されており、ハードディスクドライブやメモリカードから再生されて、メモリに起動されることになる。
【００１７】
図２は、図１の融合機１０１に係るハードウェア構成図である。融合機１０１のハードウェア１１１としては、コントローラ２０１と、オペレーションパネル２０２と、ファクシミリコントロールユニット（ＦＣＵ）２０３と、撮像部１２１と、印刷部１２２が存在する。
【００１８】
コントローラ２０１は、ＣＰＵ２１１、ＡＳＩＣ２１２、ＮＢ２２１、ＳＢ２２２、ＭＥＭ−Ｐ２３１、ＭＥＭ−Ｃ２３２、ＨＤＤ（ハードディスクドライブ）２３３、メモリカードスロット２３４、ＮＩＣ（ネットワークインタフェースコントローラ）２４１、ＵＳＢデバイス２４２、ＩＥＥＥ１３９４デバイス２４３、セントロニクスデバイス２４４により構成される。
【００１９】
ＣＰＵ２１１は、種々の情報処理用のＩＣである。ＡＳＩＣ２１２は、種々の画像処理用のＩＣである。ＮＢ２２１は、コントローラ２０１のノースブリッジである。ＳＢ２２２は、コントローラ２０１のサウスブリッジである。ＭＥＭ−Ｐ２３１は、融合機１０１のシステムメモリである。ＭＥＭ−Ｃ２３２は、融合機１０１のローカルメモリである。ＨＤＤ２３３は、融合機１０１のストレージである。メモリカードスロット２３４は、メモリカード２３５をセットするためのスロットである。ＮＩＣ２４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス２４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。セントロニクスデバイス２４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。
【００２０】
オペレーションパネル２０２は、オペレータが融合機１０１に入力を行うためのハードウェア（操作部）であると共に、オペレータが融合機１０１から出力を得るためのハードウェア（表示部）である。
【００２１】
図３は、図１の融合機１０１に係る外観図である。図３には、撮像部１２１の位置と、印刷部１２２の位置と、オペレーションパネル２０２の位置が図示されている。図３には更に、読取原稿のセット先となる原稿セット部３０１と、印刷用紙の給紙先となる給紙部３０２と、印刷用紙の排紙先となる排紙部３０３が図示されている。
【００２２】
オペレーションパネル２０２は、図４のように、タッチパネル３１１と、テンキー３１２と、スタートボタン３１３と、リセットボタン３１４と、機能キー３１５と、初期設定ボタン３１６により構成される。タッチパネル３１１は、タッチ操作で入力を行うためのハードウェア（タッチ操作部）であると共に、画面表示で出力を得るためのハードウェア（画面表示部）である。テンキー３１２は、キー（ボタン）操作で数字入力を行うためのハードウェアである。スタートボタン３１３は、ボタン操作でスタート操作を行うためのハードウェアである。リセットボタン３１４は、ボタン操作でリセット操作を行うためのハードウェアである。機能キー３１５は、キー（ボタン）操作でＣＳＤＫアプリ１４６やＪＳＤＫアプリ１４７による操作画面を表示させるためのハードウェアである。初期設定ボタン３１６は、ボタン操作で初期設定画面を表示させるためのハードウェアである。
【００２３】
原稿セット部３０１は、ＡＤＦ（自動原稿搬送装置）３２１と、フラットベッド３２２と、フラットベッドカバー３２３により構成される。給紙部３０２は、４個の給紙トレイにより構成される。排紙部３０３は、１個の排紙トレイにより構成される。
【００２４】
（ＣＳＤＫ／ＪＳＤＫ／ＯＳＧｉ）
図５は、図１のＣＳＤＫアプリ１４６とＪＳＤＫアプリ１４７のソフトウェア構成図である。ＣＳＤＫアプリ１４６は、Ｃ言語のアプリケーションであり、それぞれプロセスとして実行される事になる。ＪＳＤＫアプリ１４７は、Ｊａｖａ（登録商標）言語のアプリケーションであり、それぞれスレッドとして実行される事になる。
【００２５】
図１の融合機１０１には、ＣＳＤＫアプリ１４６として、他のＣＳＤＫアプリ１４６の制御を行うＳＡＳ（ＳＤＫアプリケーションサービス）４１１が存在し、ＪＳＤＫアプリ１４７として、他のＪＳＤＫアプリ１４７の制御を行うＳＡＳ Ｍａｎａｇｅｒ（ＳＤＫアプリケーションサービスマネージャ）５１１が存在する。ＣＳＤＫアプリ１４６の方はプロセスとして実行されてＪＳＤＫアプリ１４７の方はスレッドとして実行されるので、ＣＳＤＫアプリ１４６用のアプリケーション管理機構とＪＳＤＫアプリ１４７用のアプリケーション管理機構が別個に存在するのである。ＳＡＳ４１１とＳＡＳ Ｍａｎａｇｅｒ５１１はそれぞれ、ＣＳＤＫアプリ１４６とＪＳＤＫアプリ１４７の起動制御，起動解除制御，インストール制御，アンインストール制御，アップデート制御等を行う。
【００２６】
さて、ＳＡＳ４１１は、ＣＳＤＫアプリ１４６の制御を行う事ができるだけではなく、ＳＡＳ Ｍａｎａｇｅｒ５１１を介してＪＳＤＫアプリ１４７の制御を行う事もできる。ＳＡＳ４１１は、ＣＳＤＫアプリ１４６については直接的にその制御を行う事ができると共に、ＪＳＤＫアプリ１４７についてはＳＡＳ Ｍａｎａｇｅｒ５１１を介して間接的にその制御を行う事ができるのである。このように、ＣＳＤＫアプリ１４６用のアプリケーション管理機構とＪＳＤＫアプリ１４７用のアプリケーション管理機構は、ＳＡＳ Ｍａｎａｇｅｒ５１１を制御できる機能をＳＡＳ４１１に具備させると言う形で統合的に構成されている。融合機１０１のソフトウェアの根幹部分はＣ言語によるので、ＳＤＫアプリを制御する機能を同じくＣ言語によるＳＡＳ４１１に集中しておくのが好適なのである。
【００２７】
図６は、図１の融合機１０１におけるＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）サービスプラットフォームについて説明するための図である。ＯＳＧｉサービスプラットフォームは、ＯＳＧｉアライアンスによる標準化技術であり、Ｊａｖａ（登録商標）言語に基づいたオープンなソフトウェア部品化技術である。ＯＳＧｉサービスプラットフォームが実装された機器では、Ｊａｖａ（登録商標）言語のソフトウェアは「バンドル」と言うソフトウェア部品の形で実装される。そして、該機器の諸機能はバンドルをもって構成する事ができると共に、該機器の諸機能のアップデートやカスタマイズやメンテナンスはバンドルのダウンロードをもって実現する事ができる。
【００２８】
図１の融合機１０１には、Ｊａｖａ（登録商標）言語のソフトウェアとして、ＪＳＤＫアプリ１４７と、ＪＳＤＫプラットフォーム１４８と、ＯＳＧｉ用のアプリケーションであるＯＳＧｉアプリ４０１と、ＯＳＧｉ用のサービスであるＯＳＧｉサービス４０２と、バンドルの管理（バンドルのライフサイクルやデータの管理等）を行うＯＳＧｉフレームワーク４０３が存在する。
【００２９】
図１の融合機１０１にはさらには、他機のＯＳＧｉサービスプラットフォームを自機のＯＳＧｉサービスプラットフォームと同様に処理するためのＣＳＣ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｃｏｎｃｉｅｒｇｅ）４２１と、Ｊａｖａ（登録商標）言語のソフトウェアを実行するためのＣＶＭ（Ｃｏｍｐａｃｔ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）５５５が存在する。
【００３０】
さて、ＯＳＧｉアプリ４０１とＪＳＤＫアプリ１４７に関して、ＯＳＧｉアプリ４０１はバンドル化された状態で融合機１０１に実装するものとするが、ＪＳＤＫアプリ１４７はバンドル化されていない状態で融合機１０１に実装するものとする。理由は、ＪＳＤＫアプリ１４７をバンドル化して実装する負担をＪＳＤＫアプリ１４７のベンダに課さないようにするためである。その代わり、ＪＳＤＫアプリ１４７をバンドル化する「Ｂｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ４０４」がＪＳＤＫプラットフォーム１４８に存在している。そして、ＯＳＧｉフレームワーク４０３は、バンドル化された状態で融合機１０１に実装されたバンドル（ＯＳＧｉアプリ４０１）の管理を行うと共に、バンドル化されていない状態で融合機１０１に実装されて「Ｂｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ４０４」によってバンドル化されるバンドル（ＪＳＤＫアプリ１４７）の管理を行う事になる。このようにして、ＯＳＧｉアプリ４０１用のアプリケーション管理機構とＪＳＤＫアプリ１４７用のアプリケーション管理機構は、ＯＳＧｉフレームワーク４０３とＢｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ４０４を併設すると言う形で統合的に構成されているのである。これにより、Ｊａｖａ（登録商標）言語のアプリケーションの管理先の一元化が実現されている。
【００３１】
なお、ＯＳＧｉフレームワーク４０３は、当然の事ながら、ＯＳＧｉサービス４０２を構成するバンドルの管理や、ＪＳＤＫプラットフォーム１４８を構成するバンドルの管理も行う。Ｊａｖａ（登録商標）言語のソフトウェアの管理先の一元化が実現されていると言える。そして、ＯＳＧｉアプリ４０１はここではＳｅｒｖｌｅｔかＪＳＰであるものとする。そして、ＪＳＤＫアプリ１４７はここではＸｌｅｔであるものとする。
【００３２】
なお、ＪＳＤＫアプリ１４７についても、バンドル化された状態で実装するものとしてもよい。さらに、ＪＳＤＫアプリ１４７については、バンドル化された状態で実装してもバンドル化されていない状態で実装してもどちらでもよいものとしてもよい。バンドル化された状態で実装されるＪＳＤＫアプリ１４７については、Ｂｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ４０４によるバンドル化は不要である。
【００３３】
（ＪＳＤＫ）
図７は、図１のＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８のクラス図である。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は、全体で１プロセスとして、同一プロセス上で実行される。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８中の各ブロックは、それぞれこの１プロセス上のスレッドとして、スレッド単位で並列的に実行（マルチスレッド）される。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は、Ｊａｖａ（登録商標）コンパイラによりソースコードからバイトコードに一括翻訳されており、Ｊａｖａ（登録商標）仮想マシンにより逐次実行される。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は「Ｊａｖａ（登録商標） ２ Ｍｉｃｒｏ Ｅｄｉｔｉｏｎ」の「Ｆｏｕｎｄａｔｉｏｎ Ｐｒｏｆｉｌｅ」がベースとなっている。
【００３４】
ＪＳＤＫアプリ１４７としては、図に示す通り、ユーザアプリ５０１と、ＳＡＳ Ｍａｎａｇｅｒ５１１と、Ｓｃｒｅｅｎ Ｍａｎａｇｅｒ５１２等が存在する。
【００３５】
ユーザアプリ５０１は、融合機１０１のユーザ（例えばベンダ）がＪＳＤＫを使用して開発したＪＳＤＫアプリ１４７である。ＳＡＳ Ｍａｎａｇｅｒ５１１は、他のＪＳＤＫアプリ１４７（ユーザアプリ５０１等）の制御等を行うＪＳＤＫアプリ１４７である。Ｓｃｒｅｅｎ Ｍａｎａｇｅｒ５１２は、他のＪＳＤＫアプリ１４７（ユーザアプリ５０１等）を操作対象とする操作画面の表示等を行うＪＳＤＫアプリ１４７である。
【００３６】
ユーザアプリ５０１はここでは、スタンドアロンアプリケーションやアプレットと並ぶＪａｖａ（登録商標）アプリケーションの一種であるＸｌｅｔである。ＳＡＳ Ｍａｎａｇｅｒ５１１とＳｃｒｅｅｎ Ｍａｎａｇｅｒ５１２はここでは、独自の拡張を施したＸｌｅｔ（ＸｌｅｔＥｘ）である。
【００３７】
ＪＳＤＫプラットフォーム１４８には、図に示す通り、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１と、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１と、Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２と、Ｓｅｎｄ Ｍａｎａｇｅｒ５４１と、Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４２と、Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４３と、Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４と、Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５と、Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６と、Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒ５４７等のクラスが存在する。
【００３８】
ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１は、ＪＳＤＫシステムの実行環境を反映したＪＳＤＫシステムの起動環境設定を実行するクラスである。
【００３９】
Ｘｌｅｔ Ｍａｎａｇｅｒ５３１は、１対１でＸｌｅｔを管理するクラスである。ここでは、５個のＸｌｅｔのライフサイクルやデータがそれぞれ１対１で５個のＸｌｅｔ Ｍａｎａｇｅｒ５３１によって管理される。Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２は、全てのＸｌｅｔ Ｍａｎａｇｅｒ５３１を管理するクラスである。ここでは、５個のＸｌｅｔ Ｍａｎａｇｅｒ５３１のライフサイクルやデータが全て１個のＭｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２によって管理される。なお、ＳＡＳ Ｍａｎａｇｅｒ５１１，Ｓｃｒｅｅｎ Ｍａｎａｇｅｒ５１２，ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１，Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２，Ｓｅｎｄ Ｍａｎａｇｅｒ５４１，Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４２，Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４３，Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４，Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５，Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６，Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒ５４７等のクラスのバンドルのライフサイクルやデータは、ＯＳＧｉフレームワーク４０３によって管理される。
【００４０】
Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４３は、図１のプラットフォーム１３２からのシステムイベント（電力モード等）の管理を行うクラスである。Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４は、１個のＸｌｅｔが図２のオペレーションパネル２０２の画面を占有する際の調停を行うクラスである。Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５は、ＳＤｃａｒｄやＷｅｂからのインストールやアンインストールの管理を行うクラスである。Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒ５４７は、Ｘｌｅｔからのサービス要求に応じてＸｌｅｔへのサービス提供を行うクラスである。
【００４１】
図７のＪＳＤＫシステムでは、ＡＰＩとして、ＪＳＤＫ ＡＰＩ５５１とＪＳＤＫ ＡＰＩ５５２が利用される。なお、ＸｌｅｔとＸｌｅｔＥｘの差異として、ＸｌｅｔＥｘは、オブジェクトにアクセスするのにＪＳＤＫ ＡＰＩ５５１の利用とＪＳＤＫプラットフォーム１４８へのアクセスが可能である点が挙げられる。図１の融合機１０１にはさらに、図７のＪＳＤＫシステムに係る要素として、Ｃ言語とＪａｖａ（登録商標）言語のインタフェースとなるＪＳＤＫ Ｓｅｓｓｉｏｎ５５３とＮａｔｉｖｅ ＪＳＤＫ Ｓｅｓｓｉｏｎ５５４や、ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８を実行するためＪａｖａ（登録商標）仮想マシンであるＣＶＭ５５５が存在する。
【００４２】
図８は、ＪＳＤＫシステムの起動処理を説明するための図である。ＪＳＤＫシステムの起動処理では先ず、ＯＳＧｉフレームワーク４０３が、ＯＳＧｉアプリ４０１やＯＳＧｉサービス４０２を構成するバンドルを生成（Ｓ１）する。次に、ＯＳＧｉフレームワーク４０３が、ＪＳＤＫアプリ１４７やＪＳＤＫプラットフォーム１４８を構成するバンドルを生成（Ｓ２）する。次に、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１が、ＪＳＤＫ Ｓｅｓｓｉｏｎ５５３やＮａｔｉｖｅ ＪＳＤＫ Ｓｅｓｓｉｏｎ５５４を生成するなど、ＪＳＤＫシステムの実行環境を反映したＪＳＤＫシステムの起動環境設定を実行（Ｓ３）する。次に、ＪＳＤＫ Ｓｅｓｓｉｏｎ５５３が、Ｓｅｎｄ Ｍａｎａｇｅｒ５４１やＥｖｅｎｔ Ｍａｎａｇｅｒ５４２を生成（Ｓ４）する。なお、ユーザアプリ５０１の起動処理には、ＳＡＳ４１１やＳＡＳ Ｍａｎａｇｅｒ５１１が関与（Ｓ５）する。
【００４３】
以下、Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒ５４７について詳細に説明する。文中、Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒ５４７についてはＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１、ＪＳＤＫ ＡＰＩ５５１についてはＦｕｎｃｔｉｏｎ ＡＰＩ６１１、ＪＳＤＫ ＡＰＩ５５２についてはＣ／Ｊ ＡＰＩ６２１と表記する。なお、ＡＰＩは、アプリケーションプログラムインタフェースの略語に相当する。
【００４４】
１）Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ
図９は、図７のＪＳＤＫシステムを構成するＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１について説明するためのクラス図である。Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、ユーザアプリ５０１からのサービス要求に応じてユーザアプリ５０１へのサービス提供を行うクラスである。サービス内容の具体例としては、コピー処理の実行制御に関するサービス、プリント処理の実行制御に関するサービス、スキャン処理の実行制御に関するサービス、ファックス処理の実行制御に関するサービスが挙げられる。図７のＪＳＤＫシステムには、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１が存在する。
【００４５】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、ユーザアプリ５０１からのサービス要求を調停する機能を備える。ユーザアプリ５０１からのサービス要求が競合する場合があるからである。Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、図９に示す通り、一のユーザアプリ５０１からのサービス要求と他のユーザアプリ５０１からのサービス要求とが競合する際には、一方のサービス要求を優先させて他方のサービス要求を劣後させる等、一方のサービス要求と他方のサービス要求とを調停する事になる。
【００４６】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１には、Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１や、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２等のクラスが存在する。さらに、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２には、Ｃｏｐｙ Ｓｅｒｖｉｃｅ７１１や、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２や、Ｓｃａｎ Ｓｅｒｖｉｃｅ７１３や、Ｆａｘ Ｓｅｒｖｉｃｅ７１４や、ＳＡＳ Ｓｅｒｖｉｃｅ７２１等のクラスが存在する。
【００４７】
Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１は、ユーザアプリ５０１等からのサービス要求を受け付けるクラスである。Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１は、ユーザアプリ５０１等からのサービス要求を処理する動的に変更可能な種々の関数を備える。Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２は、ユーザアプリ５０１等へのサービス提供を執り行うクラスである。Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２は、自己の振る舞いを動的に変更する機能を備える。なお、プログラムの振る舞いの取り扱いに関する具体例は例えば、特願２００４−０６２４１３に開示されている。
【００４８】
Ｃｏｐｙ Ｓｅｒｖｉｃｅ７１１は、コピー処理の実行制御に関するサービス提供等を執り行うクラスである。Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、プリント処理の実行制御に関するサービス提供等を執り行うクラスである。Ｓｃａｎ Ｓｅｒｖｉｃｅ７１３は、スキャン処理の実行制御に関するサービス提供等を執り行うクラスである。Ｆａｘ Ｓｅｒｖｉｃｅ７１４は、ファックス処理の実行制御に関するサービス提供等を執り行うクラスである。
【００４９】
ＳＡＳ Ｓｅｒｖｉｃｅ７２１は、ユーザアプリ５０１の動作態様を制御するクラスである。ＳＡＳ Ｓｅｒｖｉｃｅ７２１は、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２の振る舞いの動的な変更に応じて所定のユーザアプリ５０１の動作態様を変更する。なお、ＳＡＳ Ｓｅｒｖｉｃｅ７２１は、ＳＡＳ Ｍａｎａｇｅｒ５１１を制御する事でユーザアプリ５０１の動作態様を制御する事ができる。
【００５０】
なお、ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８はリフレクション型のアーキテクチャで実装されている。リフレクションとは、プログラムが自己の静的な構造や動的な振る舞いに関する情報を公開したり、自己の静的な構造や動的な振る舞いを変更したりする能力を意味する。リフレクション型のアーキテクチャは、ベースレベルとメタレベルからなる。図７のＪＳＤＫシステムでは、ＪＳＤＫアプリ１４７がベースレベルに相当し、ＪＳＤＫプラットフォーム１４８がメタレベルに相当する。
【００５１】
図１０は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の動作について説明するための図である。図１０は、図９のクラス図に対応するコラボレーション図に相当する。
【００５２】
ユーザアプリ５０１がＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求する際には先ず、ユーザアプリ５０１からＦｕｎｃｔｉｏｎ ＡＰＩ６１１に、当該サービスを要求する旨のサービス要求が送信（Ｓ１１）される。次に、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１からＡｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１に、当該サービスを要求する旨の当該サービス要求が送信（Ｓ１２）される。次に、Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１からＡｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２に、当該サービスを要求する旨の当該サービス要求が状態遷移のイベント形式で送信（Ｓ１３）される。次に、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２からプラットフォーム１３２に、当該サービスに関する情報処理，通信処理，画像形成処理等の種々の処理を要求する旨の処理要求が状態遷移のアクション形式で送信（Ｓ１４）される。
【００５３】
続いて次に、プラットフォーム１３２からＡｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２に、当該処理要求に関する処理結果が状態遷移のイベント形式で送信（Ｓ２１）される。次に、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２からＡｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１に、上記のサービス要求に関するサービス結果が状態遷移のアクション形式で送信（Ｓ２２）される。次に、Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１からＦｕｎｃｔｉｏｎ ＡＰＩ６１１に、上記のサービス要求に関する上記のサービス結果が送信（Ｓ２３）される。次に、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１からユーザアプリ５０１に、上記のサービス要求に関する上記のサービス結果が送信（Ｓ２４）される。
【００５４】
さて、プラットフォーム１３２が情報処理，通信処理，画像形成処理等の上記の処理を実行する際に上記の処理を実行する上での不都合や不具合が存在する場合には、プラットフォーム１３２からＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１に、不都合や不具合が存在する旨の通知が送信（Ｓ３１）される。次に、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１からＡｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２に、自己の振る舞いを動的に変更する旨の命令が送信（Ｓ３２）される。次に、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２が、自己の振る舞いを動的に変更（Ｓ３３）して更に、Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ７０１の種々の関数の動作を動的に変更（Ｓ３４）する。次に、ＳＡＳ Ｓｅｒｖｉｃｅ７２１が、ＳＡＳ Ｍａｎａｇｅｒ５１１を通じて所定のユーザアプリ５０１の動作態様を変更（Ｓ３５，Ｓ３６）する。
【００５５】
図１１は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の動作の具体例について説明するための図である。図１１のコラボレーション図は、図１０のコラボレーション図の具体例に該当する。
【００５６】
先ず、第３のユーザアプリ５０１からＦａｘ Ｓｅｒｖｉｃｅ７１４に、ファックス送信処理の実行制御に係るサービス要求が送信（Ｓ４１）される。次に、Ｆａｘ Ｓｅｒｖｉｃｅ７１４からプラットフォーム１３２に、ファックス送信処理に係る処理要求が送信（Ｓ４２）される。続いて次に、第１のユーザアプリ５０１からＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２に、プリント処理の実行制御に係るサービス要求が送信（Ｓ４３）される。次に、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２からプラットフォーム１３２に、プリント処理に係る処理要求が送信（Ｓ４４）される。
【００５７】
次に、プラットフォーム１３２からＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１に、ファックス送信処理とプリント処理を同時に実行するためのメモリが不足している旨が通知（Ｓ５１）される。次に、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１は、ファックス送信処理の実行中はプリント処理の処理要求を発行しないようＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の振る舞いを動的に変更（Ｓ５２）する。
【００５８】
次に、プラットフォーム１３２からＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１に、プリント処理を停止してもファックス送信処理を実行するためのメモリがいまだ不足している旨が通知（Ｓ６１）される。次に、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１は、ファックス送信処理の実行中はファックス送信処理の要求元のユーザアプリ５０１を除く全てのユーザアプリ５０１を停止するようＳＡＳ Ｓｅｒｖｉｃｅ７２１の振る舞いを動的に変更（Ｓ６２）する。次に、ＳＡＳ Ｓｅｒｖｉｃｅ７２１は、ファックス送信処理の実行中はファックス送信処理の要求元のユーザアプリ５０１を除く全てのユーザアプリ５０１を停止（Ｓ６３，Ｓ６４）する。
【００５９】
図１２は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞い変更処理について概念的に説明するための図である。
【００６０】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にて、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２には、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２等のクラスが存在する。
【００６１】
Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２やＦａｘ Ｓｅｒｖｉｃｅ７１４の状態遷移モデルの管理を執り行う。Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２やＦａｘ Ｓｅｒｖｉｃｅ７１４の状態遷移モデルの修正を執り行う。状態遷移モデルの管理・修正は、Ｃｏｐｙ Ｓｅｒｖｉｃｅ７１１やＳｃａｎ Ｓｅｒｖｉｃｅ７１３も実施対象となる。
【００６２】
Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移モデルについて説明しておく。Ｉｄｌｅ状態７４１は、プリント処理の待機中の状態である。Ｐｒｉｎｔ状態７４２は、プリント処理を実行中の状態である。Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２は、印刷開始イベント７４３により遷移する。Ｐｒｉｎｔ状態７４２からＩｄｌｅ状態７４１は、印刷終了イベント７４４により遷移する。
【００６３】
Ｆａｘ Ｓｅｒｖｉｃｅ７１４の状態遷移モデルについて説明しておく。Ｉｄｌｅ状態７５１は、ファックス送信処理の待機中の状態である。ＦａｘＳｅｎｄ状態７５２は、ファックス送信処理を実行中の状態である。Ｉｄｌｅ状態７５１からＦａｘＳｅｎｄ状態７５２には、送信開始イベント７５３により遷移する。ＦａｘＳｅｎｄ状態７５２からＩｄｌｅ状態７５１には、送信終了イベント７５４により遷移する。
【００６４】
Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１が管理する状態遷移モデルに状態遷移の実行条件を付加する事で、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１が管理する状態遷移モデルを修正する事ができる。これによって、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２やＦａｘ Ｓｅｒｖｉｃｅ７１４の振る舞いが動的に変更される事になる。
【００６５】
図１２にて、図１２Ａは振る舞い変更前の状態遷移モデルを表し、図１２Ｂは振る舞い変更後の状態遷移モデルを表す。Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２に関して、図１２ＡではＩｄｌｅ状態７４１からＰｒｉｎｔ状態７４２に遷移するのに制限条件は存在しないが、図１２ＢではＩｄｌｅ状態７４１からＰｒｉｎｔ状態７４２に遷移するのに制限条件が存在する。当該制限条件（ガード条件）は、Ｆａｘ Ｓｅｒｖｉｃｅ７１４がＩｄｌｅ状態７５１の際に限りＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移を許容する事を意味する。当該制限条件（ガード条件）による振る舞い変更処理が、図１１のＳ５１・Ｓ５２による振る舞い変更処理に匹敵する。
【００６６】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、アスペクト指向プログラムに相当する。アスペクト指向とは、システム横断的な関心事の分離メカニズムを意味する。アスペクト指向では、アスペクト指向プログラムにアスペクトを織り込む事で、アスペクト指向プログラムの状態遷移モデルに状態遷移の実行条件を付加する事ができる。これによって、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１が管理する状態遷移モデルに状態遷移の実行条件を付加する。なお、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、振る舞いと部品が分離されて設計されており、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２からＳｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に、状態遷移モデルと部品ライブラリが登録される。これによって、アスペクト指向によるアスペクトの織り込みが実現されている。
【００６７】
ＸＭＩ言語によるＸＭＬ文書（図９，図１０，図１１）について説明しておく。図１０に示す通り、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１とＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１では、ＸＭＩ言語を記述言語とするＸＭＬ文書であるＡｓｐｅｃｔＳＭ．ｘｍｌファイル（以下、単に「ＡｓｐｅｃｔＳＭ」という。）の記述内容に従って、それぞれＳ３２の処理とＳ３３の処理を実行する。図１１で言えば、ＡｓｐｅｃｔＳＭにはメモリが不足している際にはＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞いを動的に変更する旨が記述されている。なお、ＸＭＬは「ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ」の略語に相当する。また、ＸＭＩは「ＸＭＬ Ｍｅｔａｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ」の略語に相当する。
【００６８】
以上の説明のように、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、自己の振る舞いを動的に変更する事ができる。これにより、ＪＤＳＫアプリ１４７の多様な変化にＪＳＤＫプラットフォーム１４８が適切に対応する事ができるのである。更に、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、自己の振る舞いの動的な変更に応じてユーザアプリ５０１の動作態様を変更する事ができる。これにより、ＪＤＳＫアプリ１４７の多様な変化にＪＳＤＫプラットフォーム１４８が、ＪＳＤＫプラットフォーム１４８の制御と更にＪＤＳＫアプリ１４７の制御を基に適切に対応する事ができるのである。
【００６９】
図１２において概念的に説明した内容を更に具体的に説明する。図１２に示されるモジュール構成は、図１３に示されるクラス図に基づいている。図１３は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの振る舞いの動的な変更を実現するクラス群を説明するためのクラス図である。
【００７０】
図１３において、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌクラス１０００は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１を表現するクラスである。すなわち、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌクラス１０００のインスタンスである。
【００７１】
ＳｔａｔｅＭａｃｈｉｎｅクラス１００１は、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２における各サービス（Ｃｏｐｙ Ｓｅｒｖｉｃｅ７１１、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２、Ｓｃａｎ Ｓｅｒｖｉｃｅ７１３、及びＦａｘ Ｓｅｒｖｉｃｅ７１４等）を表現するクラスである。すなわち、Ｃｏｐｙ Ｓｅｒｖｉｃｅ７１１、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２、Ｓｃａｎ Ｓｅｒｖｉｃｅ７１３、及びＦａｘ Ｓｅｒｖｉｃｅ７１４等は、それぞれＳａｔｅＭａｃｈｉｎｅクラス１００１のインスタンス（ＳｔａｔｅＭａｃｈｉｎｅオブジェクト）として生成される。したがって、以後、これらのサービスを総称する場合、「ステートマシン」という。
【００７２】
ＳｔａｔｅＶｅｒｔｅｘクラス１００２は、抽象クラスであり、各ステートマシンの状態遷移モデルにおいて状態を表現するクラスのルートクラスに相当する。ＳｔａｔｅＶｅｒｔｅｘクラス１００２には、ｃｏｎｎｅｃｔメソッド１００２ａや、ｒｅｃｏｎｎｅｃｔメソッド１００２ｂ等のメソッドが定義されている。ｃｏｎｎｅｃｔメソッド１００２ａは、遷移先の状態及びその状態遷移との接続を実行するメソッドである。状態遷移についてはＴｒａｎｓｉｔクラス１００３によって表現される。したがって、より具体的には、ｃｏｎｎｅｃｔメソッド１００２ａは、当該メソッドが呼び出されたオブジェクトと、当該オブジェクトの遷移先のＳｔａｔｅＶｅｒｔｅｘオブジェクト（厳密にはそのサブクラスのオブジェクト。以下、総称する場合「状態オブジェクト」という。）及びその状態遷移に対応するＴｒａｎｓｉｔオブジェクト（以下、「遷移オブジェクト」という。）との接続を実行するクラスである。ここでいう接続は、例えば、状態オブジェクト内に、遷移先の状態オブジェクトや、その遷移オブジェクトの識別情報（ＩＤ、参照、又はポインタ等）を保持することで実現される。ｒｅｃｏｎｎｅｃｔメソッド１００２ｂは、遷移先の変更を実行するメソッドである。なお、Ｔｒａｓｉｔクラス１００３には、インタフェースとしてＥｖｅｎｔインタフェース１００３ａ、Ｇｕｒａｄインタフェース１００３ｂ、及びＡｃｔｉｏｎインタフェース１００３ｃ等が定義されている。Ｅｖｅｎｔインタフェース１００３ａは、状態遷移の遷移イベントを実装するためのインタフェースである。Ｇｕａｒｄインタフェース１００３ｂは、ガード条件を実装するためのインタフェースである。Ａｃｔｉｏｎインタフェース１００３ｃは、状態遷移時に実行するアクションを実装するためのインタフェースである。
【００７３】
ＳｔａｔｅＶｅｒｔｅｘクラス１００２のサブクラスとしては、Ｓｔａｔｅクラス１００４及びＰｓｅｕｄｏＳｔａｔｅクラス１００５が定義されている。Ｓｔａｔｅクラス１００４は、例えば、ステートマシンの状態を表現するクラスである。Ｓｔａｔｅクラス１００４には、インタフェースとしてＩＳｔａｔｅインタフェース１００４ａ及びＡｃｔｉｖｉｔｙインタフェース１００４ｂ等が定義されている。ＩＳｔａｔｅインタフェース１００４ａは、状態の入場時の処理（入場処理）及び退場時の処理（退場処理）を実装するためのインタフェースである。Ａｃｔｉｖｉｔｙインタフェース１００４ｂは、状態にある間実行する処理を実装するためのインタフェースである。これらのインタフェースは、クラスとして実装される。したがって、例えば、Ａｃｔｉｖｉｔｙインタフェース１００４ｂの処理は、Ａｃｔｉｖｉｔｙクラスに実装される。
【００７４】
ＰｓｅｕｄｏＳａｔｅクラス１００５は、初期状態や終期状態等、その名の通り擬似的な状態を表現するクラスであり、そのサブクラスとしては初期状態を表現するＩｎｉｔｉａｌＳｔａｔｅクラス１００６及び終期状態を表現するＦｉｎａｌＳｔａｔｅクラス１００７等がある。但し、図１２の状態遷移モデルでは、初期状態及び終期状態は便宜上省略されている。
【００７５】
ＭｏｄｉｆｙＡｇｅｎｔクラス１００９は、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２を表現するクラスである。すなわち、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、ＭｏｄｉｆｙＡｇｅｎｔクラス１００９のインスタンスである。ＰｌｕｇｉｎＡｇｅｔｎｔクラス１００８については後述する。
【００７６】
上記クラス間の関係について説明する。ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌクラス１０００は、ＳｔａｔｅＭａｃｈｉｎｅクラス１００１を集約する。これは、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１が、一つ以上のステートマシンのそれぞれの状態遷移モデルを管理することを表現したものである。
【００７７】
ＳｔａｔｅＭａｃｈｉｎｅクラス１００１は、ＳｔａｔｅＶｅｒｔｅｘクラス１００２を集約する。これは、一つのステートマシンは、一つ以上の状態を有することを表現したものである。ＳｔａｔｅＶｅｒｔｅｘクラス１００２は、Ｔｒａｎｓｉｔクラスを集約する。これは、状態と状態との間は遷移によって接続されることを表現したものである。
【００７８】
以上のような、モデルに基づいて、例えば、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、以下のようなオブジェクトによって構成される。
【００７９】
図１４は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅのオブジェクト構成を表す図である。Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、図１２の状態遷移モデルに基づいて、Ｉｄｌｅ状態オブジェクト７４１Ｓ、Ｐｒｉｎｔ状態オブジェクト７４２Ｓ、印刷開始オブジェクト７４３Ｔ、プ及び印刷終了オブジェクト７４４Ｔ等より構成される。Ｉｄｌｅ状態オブジェクト７４１Ｓ及びＰｒｉｎｔ状態オブジェクト７４２Ｓは、Ｓｔａｔｅクラス１００４のインスタンスである。印刷開始オブジェクト７４３Ｔ及び印刷終了オブジェクト７４４Ｔは、Ｔｒａｎｓｉｔクラス１００３のインスタンスである。
【００８０】
図１４においてオブジェクト同士を連結する線分は、オブジェクト同士の参照関係を表す。遷移元の状態オブジェクトは遷移先の状態オブジェクトを参照している。なお、図中では状態オブジェクト間に遷移オブジェクトが接続されている。例えば、Ｉｄｌｅ状態オブジェクト７４１ＳとＰｒｉｎｔ状態オブジェクト７４２Ｓとの間には印刷開始オブジェクト７４３Ｔが接続されている。しかし、このことはＩｄｌｅ状態７０３が、Ｐｒｉｎｔ状態オブジェクト７４２Ｓを参照していないことを示すものではない。Ｉｄｌｅ状態オブジェクト７４１Ｓは、Ｐｒｉｎｔ状態オブジェクト７４２Ｓを参照すると共に、その状態遷移に対応する遷移オブジェクトとして印刷開始オブジェクト７４３Ｔをも参照することを表現したものである。
【００８１】
オブジェクトの状態は、サービスの授受を行う「アクティブ状態」とサービスの授受を行わない「非アクティブ状態」に分類される。Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１におけるステートマシンの振る舞い変更を当該ステートマシンの動作中に実行するには、当該ステートマシンの更新部分のオブジェクトがアクティブ状態ではないとき（非アクティブ状態のとき）に実行すればよい。当該ステートマシンの動作中のオブジェクト同士のサービスの授受が更新処理により阻害されずに済むからである。よって、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の更新処理をＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の更新部分のオブジェクトがアクティブ状態ではないときに実行するのである。なお、状態遷移図によるモデリングでは、一のオブジェクトがアクティブ状態のときは他のオブジェクトは非アクティブ状態に限定される。すなわち、各オブジェクトは互いに排他的に処理を実行する（動作する）。
【００８２】
図１４に示されるＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２のオブジェクト構成が構築される過程について説明する。
【００８３】
図１５は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅのオブジェクト構成の構築処理を説明するためのシーケンス図である。図１５の処理は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２がＳｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１によってインスタンス化される際に実行される。
【００８４】
Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、インスタンス化されると、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移情報に基づいて、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移モデルに対応したオブジェクト構成を構築する（Ｓ４０１）。状態遷移情報は、例えば、融合機１０１の所定の記憶装置内に、以下の形式で保存されている。
【００８５】
図１６及び図１７は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの状態遷移情報の定義例を示す図である。図１６及び図１７によって一つの状態遷移情報９００の記述例が示されている。状態遷移情報９００は、ＸＭＩ（XML Metadata Interchange）に従った記述例が示されている。ＸＭＩは、モデルを各種のソフトウェアの間でＸＭＬ文書によって交換することを目的とした標準規格である。但し、本実施の形態を実施するにあたり、状態遷移情報は、必ずしもＸＭＩに従って記述される必要はない。なお、図中における行番号は、説明の便宜上付加したものである。
【００８６】
状態遷移情報９００の１行目における＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグのタグ名、及びそのｎａｍｅ属性の値（「Ｐｒｉｎｔ」）によって、状態遷移情報９００は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２に対応するものであることが定義されている。また、当該＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグにおけるｘｍｉ．ｉｄ属性の値（「００３」）は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２を識別するためのＩＤである。
【００８７】
３行目の＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグは、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２における状態の定義の開始の宣言に相当する。当該宣言は、＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグのｘｍｉ．ｉｄの値（「００４」）によって識別される。
【００８８】
５行目から１５行目におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０は、Ｉｄｌｅ状態７４１に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０のｎａｍｅ属性の値には「Ｉｄｌｅ」が設定され、ｘｍｉ．ｉｄ要素の値には、「００５」が設定されている。
【００８９】
１６行目から２６行目（図１７）におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０は、Ｐｒｉｎｔ状態７４２に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０のｎａｍｅ属性の値には「Ｐｒｉｎｔ」が設定され、ｘｍｉ．ｉｄ要素の値には、「００８」が設定されている。
【００９０】
また、３４行目から６４行目には、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２における各状態遷移が定義されている。すなわち、３４行目から５０行目におけるＴｒａｎｓｉｔｉｏｎ要素９３０は、Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素９３０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ要素９３０の子要素として定義されている、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９３１及びＴｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９３２より特定される。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９３１は遷移元の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９３１の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００５」である。したがって、遷移元は、ｘｍｉ．ｉｄ属性の値が「００５」の状態、すなわち、Ｉｄｌｅ状態７４１であることが分かる。また、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９３２は遷移先の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９３２の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００８」である。したがって、遷移先は、ｘｍｉ．ｉｄの値が「００８」の状態、すなわち、Ｐｒｉｎｔ状態７４２であることが分かる。なお、Ｔｒａｎｓｉｔｉｏｎ要素９３０のｎａｍｅ属性の値は「印刷開始」であり、ｘｍｉ．ｉｄ属性の値は「００６」である。
【００９１】
５１行目から６４行目におけるＴｒａｎｓｉｔｉｏｎ要素９４０は、Ｐｒｉｎｔ状態７４２からＩｄｌｅ状態７４１への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素９４０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９４１内のｘｍｉ．ｉｄｒｅｆ属性の値が「００８」（Ｐｒｉｎｔ状態７４２）であり、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９４２内のｘｍｉ．ｉｄｒｅｆ属性の値が「００５」（Ｉｄｌｅ状態７４１）であることから特定される。なお、Ｔｒａｎｓｉｔｉｏｎ要素９４０のｎａｍｅ属性の値は「印刷終了」であり、ｘｍｉ．ｉｄ属性の値は「００７」である。
【００９２】
５行目以降の説明に戻る。各状態に対応する、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０及びＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０は、ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素及びＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素の少なくともいずれか一方を子要素として有する。ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素は、遷移元からの状態遷移に対する接続が定義される要素である。ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素は、遷移先への状態遷移に対する接続が定義される要素である。
【００９３】
例えば、Ｉｄｌｅ状態７４１に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０おけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素９１１においてその子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００６」であり、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素９１２において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００７」である。したがって、Ｐｒｉｎｔ状態７４２からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９３０が対応する状態遷移に相当し、遷移元の状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９４０が対応する状態遷移に相当することが分かる。
【００９４】
また、Ｐｒｉｎｔ状態７４２に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０おけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素９２１においてその子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００７」であり、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素９２２において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００６」である。したがって、Ｐｒｉｎｔ状態７４２からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９４０が対応する状態遷移に相当し、遷移元の状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９３０が対応する状態遷移に相当することが分かる。
【００９５】
上記のような状態遷移情報９００に基づいて、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、まず、各状態オブジェクト及び遷移オブジェクト等をインスタンス化する。図中では、状態遷移情報９００におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０、Ｔｒａｎｓｉｔｉｏｎ要素９３０、及びＴｒａｎｓｉｔｉｏｎ要素９４０のそれぞれに基づいて、Ｉｄｌｅ状態オブジェクト７４１Ｓ、Ｐｒｉｎｔ状態オブジェクト７４２Ｓ、印刷開始オブジェクト７４３Ｔ、及び印刷終了オブジェクト７４４Ｔが生成されている例が示されている（Ｓ４０２〜Ｓ４０５）。
【００９６】
続いて、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、各状態オブジェクトの参照関係が状態遷移情報９００に定義された状態遷移の順になるよう、遷移元の状態オブジェクトに対して遷移先の状態オブジェクトを接続する。例えば、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、Ｐｒｉｎｔ状態オブジェクト７４２Ｓの識別情報と印刷開始オブジェクト７４３Ｔの識別情報とを引数として、Ｉｄｌｅ状態オブジェクト７４１Ｓのｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ４０６）。また、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は、Ｉｄｌｅオブジェクト７４１Ｓの識別情報と印刷終了オブジェクト７４４Ｔの識別情報とを引数として、Ｐｒｉｎｔ状態オブジェクト７４２Ｓのｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ４０７）。ｃｏｎｎｅｃｔ（）メソッドを呼び出された各状態オブジェクトは、当該状態オブジェクト内において引数に指定された識別情報を保持する。
【００９７】
このように、ｃｏｎｎｅｃｔ（）メソッドの引数に、状態オブジェクトと遷移オブジェクトとのそれぞれの識別情報が指定された場合、当該メソッドが呼び出された状態オブジェクトは、その状態オブジェクトの識別情報と遷移オブジェクトの識別情報とを関連付けて（ペアで）保持する。これによって、ある状態オブジェクトがアクティブのときに、あるイベントが発生したときの遷移先の状態オブジェクトが特定され得る。
【００９８】
以上の処理によって、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２について、図１４に示されるようなオブジェクト構成が構築される。
【００９９】
上記をふまえて、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の振る舞い変更処理を具体的に説明する。図１８及び図１９は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの振る舞い変更処理を説明するためのシーケンス図である。
【０１００】
プラットフォーム１３２からＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１に、例えば、不都合や不具合の発生等を示すイベントが送信される（Ｓ４２１）。ここでは、メモリが不足していることを示すイベントが通知されたこととする。但し、ここで通知されるイベントは不具合や不都合に限定されず、例えば、機器の状態の変化も含まれ得る。機器の状態の変化としては、静的な情報（機種名、機種のスペック、周辺機器情報）の変化と動的な情報（使用可能メモリ、周辺機器の状態、ユーザ操作）の変化とがある。静的な情報の変化は確定した時にＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２１に通知され、動的な情報は変化が発生した時に随時通知される。 ＪＳＤＫ Ｅｎｖｉｒｏｎｍｎｅｔ５２１は、プラットフォーム１３２からのイベントに応じた振る舞い修正指示がＡｓｐｅｃｔＳＭに記載されているか確認する。
【０１０１】
図２０は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの振る舞いの変更内容が記述されたＡｓｐｅｃｔＳＭの記述例を示す図である。ＡｓｐｅｃｔＳＭ８１０には、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移情報９００（図１６及び図１７）に対する変更内容が記述されている。
【０１０２】
ＡｓｐｅｃｔＳＭ８１０において、１行目から６行目までの＜Ｅｖｅｎｔ＞タグで囲まれたＥｖｅｎｔ要素８１１のｎａｍｅ属性、ｔｙｐｅ属性、ｖａｌｕｅ属性のそれぞれには、振る舞いを変更するトリガとなるイベント名、条件、閾値が記述される。また、Ｅｖｅｎｔ要素８１１の子要素（ｍｏｄｉｆｙ．ＳｔａｔｅＭａｃｈｉｎｅ要素）には、振る舞いの変更対象となるステートマシンが記述される。図２０の例では、空きメモリが１０ＭＢを下回ったことを示すイベントを受信した場合にＰｒｉｎｔ（Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２）に対して振る舞いを変更することが記述されている。
【０１０３】
７行目から１５行目までのａｓｐｅｃｔ要素８１２のＸＭＩ．ＳｔａｔｅＭａｃｈｉｎｅ属性には、変更するステートマシン名（Ｐｒｉｎｔ）が記述される。また、ｐｏｉｎｔｃｕｔ．Ｔｒａｎｓｍｉｓｓｉｏｎ要素８１３のｎａｍｅ属性には、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２において変更対象となる状態遷移の名前が記述され、ｔｉｍｅｎｇ属性にはＡｓｐｅｃｔＳＭ８１０による変更処理を実行するタイミングが記述される。図２０の例では、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移において、Ｉｄｌｅ状態７４１のときに振る舞い変更処理を実行することが記述されている。ａｄｖｉｃｅ．Ｇａｕｒｄ要素には、変更の内容が記述される。すなわち、＜ａｄｖｉｃｅ．Ｇｕａｒｄ＞タグのタグ名におけるａｄｖｉｃｅ．以降によって、変更の対象がＧｕａｒｄ（ガード条件）であることが記述されている。また、ｔｙｐｅ属性によって、変更の種別が「ｉｎｓｅｒｔ」（挿入）であることが記述されている。すなわち、変更内容はガード条件を挿入することであることが記述されている。１０行目から１２行目までは、実際に状態遷移情報９００に挿入される定義である。すなわち、ＡｓｐｅｃｔＳＭ８１０では、「Ｉｄｌｅ状態７４１のときにＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の印刷開始イベント７４３に基づく状態遷移に対してガード条件（Ｆａｘ Ｓｅｒｖｉｃｅ７１４がＩｄｌｅ状態であること）を付加すること」が定義されている。
【０１０４】
なお、各イベントに応じたＡｓｐｅｃｔＳＭは、予め融合機１０１のＨＤＤ２３３又はメモリカード２３５等に保存されている。
【０１０５】
したがって、ステップＳ４２１において通知されたイベントが、空きメモリが１０ＭＢを下回ったことを示すものであった場合、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｎｅｔ５２１は、図２０のＡｓｐｅｃｔＳＭ８１０に基づいて、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の振る舞いを変更する必要があることを判断し、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２にＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の振る舞い変更情報を添付して振る舞い変更要求を発行する（Ｓ４２２）。ここで、「振る舞い変更情報」とは、ＡｓｐｅｃｔＳＭ８１０より、振る舞いの変更に必要な情報のみが抽出されたものでもよいし、ＡｓｐｅｃｔＳＭ８１０そのものでもよい。
【０１０６】
Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２に対する振る舞い変更要求を受け、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に対して、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移情報９００の取得要求を発行する（Ｓ４２３）。Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、状態遷移情報９００の取得要求に対して、当該状態遷移情報が登録されていれば状態遷移情報９００をＭｏｄｉｆｙ Ａｇｅｎｔ７３２に提供する（Ｓ４２４）。
【０１０７】
Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１から状態遷移情報９００を取得できた場合、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２の状態遷移情報９００に対する振る舞い変更処理の可否を判断する（Ｓ４２５ａ）。一方、状態遷移情報９００を取得できなかった場合、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１にＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２は登録されていないことを実装してないことをＪＳＤＫ Ｅｎｖｉｒｏｎｍｎｅｔ５２１に通知する（Ｓ４２５ｂ）。
【０１０８】
ステップＳ４２５ａにおいて、振る舞い変更処理が可能であると判断した場合、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に対して、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２がインスタンス化されているか（すなわち、図１４に示されるオブジェクト構成がメモリ上に構築されているか）を問い合わせる（Ｓ４２６ａ）。一方、ステップＳ４２５ａにおいて、振る舞い変更処理は不可能であると判断した場合、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｎｅｔ５２１に変更不可であることを通知する（Ｓ４２６ｂ）。
【０１０９】
ステップＳ４２６ａの問い合わせに対して、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２がインスタンス化されていればそのインスタンスを返却する（Ｓ４２７）。
【０１１０】
Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２のインスタンスが生成されていない場合、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、状態遷移情報９００に対し振る舞い変更情報に応じた修正を行い、修正された状態遷移情報９００をＳｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に登録する（Ｓ４２８ａ）具体的には、状態遷移情報９００の３４行目と３８行目の間に、ＡｓｐｅｃｔＳＭ８１０の１０行目から１３行目が挿入される。したがって、以降にＰｒｉｎｔ Ｓｅｒｖｉｃｅ７１２がインスタンス化される際は、修正された状態遷移情報９００に基づいて、オブジェクト群が構築される。
【０１１１】
一方、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２のインスタンスが生成されている場合、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、図１９に示される処理を実行する（Ｓ４２８ｂ）
図１９において、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２のＩｄｌｅ状態オブジェクト７４１Ｓを検索する（Ｓ４３１、Ｓ４３２）。ここで、Ｍｏｄｅｆｙ Ａｇｅｎｔ７３２は、ＡｓｐｅｃｔＳＭ８１０のｐｏｉｎｔｃｕｔ．Ｔｒａｎｓｍｉｓｓｉｏｎ要素８１３のｔｉｍｉｎｇ属性に基づいて、Ｉｄｌｅ状態オブジェクト７４１Ｓを監視することにより、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２がＩｄｌｅ状態７４１に遷移するまで待機する。
【０１１２】
Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２がＩｄｌｅ状態７４１に遷移すると、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｉｄｌｅ状態オブジェクト７４１Ｓより、印刷開始オブジェクト７４３Ｔを検索する（Ｓ４３３、Ｓ４３４）。続いて、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、ガード条件を表現するガード条件オブジェクト７４６を生成し（Ｓ４３５）、ＡｓｐｅｃｔＳＭ８１０に定義されているガード条件（［ｉｓ＿ｉｎ（ＦａｘＴｘＩｄｌｅ）］）を、ガード条件オブジェクト７４６に設定する（Ｓ４３６）。ここで、ＦａｘＴｘＩｄｌｅは、Ｆａｘ Ｓｅｒｖｉｃｅ７１４のＩｄｌｅ状態オブジェクトの識別情報である。
【０１１３】
続いて、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、印刷開始オブジェクト７４３Ｔに対して、ガード条件オブジェクト７４６を設定する（Ｓ４３７）。ここで、印刷開始オブジェクト７４３Ｔは、Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２への状態遷移に対応するオブジェクトである。したがって、ステップＳ４３７の処理により、当該状態遷移にガード条件が付加されたことになる。以降、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ７１２において、Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２への遷移が発生する際、印刷開始オブジェクト７４３Ｔに設定されたガードオブジェクト７４６に基づいて、遷移の可否が判定される。
【０１１４】
上述したように、本実施の形態におけるＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、状態オブジェクトの遷移によってサービスを実現する。また、サービスの実現過程において、アクティブな状態オブジェクトが限定されるように構成されている。言い換えれば、非アクティブな状態オブジェクトが存在することになる。このような構成を前提として、ＡｓｐｅｃｔＳＭ８１０には、更新部分が非アクティブなタイミングで更新が行われるような更新指示が記述されている。そして、かかるＡｓｐｅｃｔＳＭ８１０に従って、更新部分が非アクティブなときに更新が実行される。したがって、本実施の形態におけるＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、当該Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の実行中にその振る舞いの変更を実行することができる。また、振る舞いの変更にあたり、オブジェクト群が再構築されるわけではないので、当該Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の参照側との参照関係が破壊されることなく、動的にその振る舞いを変更することが可能となっている。よって、融合機１０１を再起動することなくＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞いは変更され得る。
【０１１５】
なお、本実施の形態においては、ステートマシンが状態遷移モデルに基づいて設計された例を用いて説明したが、本発明が適用可能なプログラムは、状態ごとにオブジェクトが構築されるような構成であるものに限定されない。お互いに排他的に動作する複数のモジュール（オブジェクトも含む）の接続によって構成されているものでればよい。ここで排他的に処理を実行するとは、あるモジュールが動作中（アクティブ）のときは、他のモジュールは動作中でない（非アクティブである）ことが保証されることをいう。このようなソフトウェアであれば、動作中でないモジュールを変更することが可能であり、本実施の形態において説明した振る舞いの変更処理を適用させることができる。
【０１１６】
２）Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ
図２１は、図７のＪＳＤＫシステムを構成するＭｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２について説明するためのクラス図である。Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２は、ＪＳＤＫアプリ１４７からのＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に対するサービスの提供要求に応じて、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを修正するクラスである。すなわち、第一節（Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ）では、プラットフェーム１３２からのイベントに応じて、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１が、自らの振る舞いを変更する処理について説明したが、Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２は、ＪＳＤＫアプリ１４７がＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１を利用しようとしたときに、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞いを変更するのである。
【０１１７】
図７のＪＳＤＫシステムでは、第１節で取り上げたＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１と第２節で取り上げるＭｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２は下位層と上位層の関係にある。図７のＪＳＤＫシステムには、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１が存在し、Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、Ｍｏｄｉｆｙ ＡＰＩ６１２が存在する。Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２とＭｏｄｉｆｙ ＡＰＩ６１２の実装態様は、図２１の実装態様ではなく図２２の実装態様でもよい。図２１についての説明の内容は図２２についても同様に成立する。なお、図２１は、Ｍｏｄｉｆｙ ＡＰＩ６１２は、複数のユーザアプリ５０１に対して有効であること（呼び出し元が限定されないこと）を示す。一方、図２２は、Ｍｏｄｉｆｙ ＡＰＩ６１２は、特定のユーザアプリ５０１に対して有効であること（呼び出し元が限定されること）を示す。
【０１１８】
Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２とＭｏｄｉｆｙ ＡＰＩ６１２の実装理由を説明する事にする。図７のＪＳＤＫシステムには、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞いを動的に変更する機能は実装しているが、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１の動作を動的に変更する機能は実装していない。ＡＰＩの実装態様はユーザアプリ５０１の開発効率に与える影響が大きいところ、ＡＰＩの動作を動的に変更するような実装は開発トラブルや市場トラブルを招き兼ねないからである。よって、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを修正するには、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを修正するＭｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２を、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に上乗せするのである。そしてさらに、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１にＭｏｄｉｆｙ ＡＰＩ６１２を上乗せする。
【０１１９】
図２１に示す通り、旧バージョンのユーザアプリ５０１は、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１を通じてＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求（Ｓ１０１）する。一方、新バージョンのユーザアプリ５０１は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求する際には、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１を通じてＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求（Ｓ１０２）して、Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２にサービスを要求する際には、Ｍｏｄｉｆｙ ＡＰＩ６１２を通じてＭｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２にサービスを要求（Ｓ１０３）する。
【０１２０】
但し、Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２を介してサービス要求がなされ、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞いが変更された後は、旧バージョンのユーザアプリ５０１であっても、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１を通じて、振る舞いが変更されたＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１によるサービスの提供を受けることができる。
【０１２１】
Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６１２について更に具体的に説明する。図２３は、Ｍｏｄｉｆｙ ＳｅｒｖｉｃｅによるＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの変更処理を説明するためのシーケンス図である。図２３では、Ｆａｘ Ｓｅｒｖｅｃｅ７１４を利用するためのＦｕｎｃｔｉｏｎ ＡＰＩ６１１の呼び出しに応じて、Ｐｒｉｎｔｅｒ Ｓｅｒｖｉｃｅ７１２の振る舞いが変更される例について説明する。
【０１２２】
ＪＳＤＫアプリ１４７の一つであるＦａｘ送信アプリ５０１ｆが起動されている状態において、ユーザが、オペレーションパネル２０２を介してＦａｘ送信アプリ５０１ｆに対して送信開始の指示を行ったとする（Ｓ５０１）。Ｆａｘ送信アプリ５０１ｆは、ユーザからの指示に応じ、Ｆｕｎｃｔｉｏｎ ＡＰＩ６０１又はＭｏｄｉｆｙ ＡＰＩ６１２の一部を構成するＦａｘ送信クラス６１１ｆを用いて送信開始を行う（Ｓ５０２）。具体的には、Ｆａｘ送信アプリ５０１ｆは、Ｆａｘ送信クラス６１１ｆのｓｔａｒｔ（）メソッド（Ｆａｘｔｘ．ｓｔａｒｔ（））を呼び出す。
【０１２３】
Ｆａｘ送信クラス６１１ｆは、ＦａｘＴｘ．ｓｔａｒｔ（）メソッドが呼ばれたこと（送信開始イベント７５３の発生）を要求元のアプリのプロダクトＩＤを添えてＭｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２に通知する（Ｓ５０３）。Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２は、通知されたイベント（送信開始イベント７５３）が、Ｆａｘ送信アプリ５０１ｆのインストールの際にＦａｘ送信アプリ５０１ｆに対応させて登録されたＡｓｐｅｃｔＳＭに基づく振る舞い変更のトリガとなるイベントであるか当該ＡｓｐｅｃｔＳＭを参照することにより判断する。
【０１２４】
図２４は、Ｆａｘ送信アプリに対応させて登録されたＡｓｐｅｃｔＳＭの記述例を示す図である。図２４のＡｓｐｅｃｔＳＭ８２０は、２行目の記述内容が、図２０のＡｓｐｅｃｔＳＭ８１０と異なる。
【０１２５】
すなわち、ＡｓｐｅｃｔＳＭ８２０のＥｖｅｎｔ要素８２１のｎａｍｅ属性には、振る舞いを変更するトリガとなるイベント名として"Ｍｅｔｈｏｄ"が記述されている。これは、メソッドが呼び出されたことがトリガとなることを意味する。また、ｔｙｐｅ属性には、トリガとなる具体的なメソッド名（" ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ＦａｘＴｘ：ｓｔａｒｔ（ｖｏｉｄ）"）が記述されている。ここで「ＦａｘＴｘ」とは、Ｆａｘ送信クラスを示す。更に、ｖａｌｕｅ属性には、メソッドの呼び出し元を特定するプロダクトＩＤ（"１２３４５６"）が記述されている。ここで、"１２３４５６"は、Ｆａｘ送信アプリ５０１ｆのプロダクトＩＤである。呼び出し元を特定しない場合、ｖａｌｕｅ属性の値は空となる。なお、ｖａｌｕｅ属性の値にプロダクトＩＤが指定されない場合（すなわち、呼び出し元が限定されない場合）と、プロダクトＩＤが指定される場合（すなわち、呼び出し元が限定される場合）との違いは、図２１と図２２との違いによって概念的に示されている。
【０１２６】
上記より、ＡｓｐｅｃｔＳＭ８２０には、Ｆａｘ送信アプリ５０１ｆからのＦａｘｔｘ．ｓｔａｒｔ（）の呼び出しが、振る舞いを変更するトリガであることが記述されていることが分かる。
【０１２７】
したがって、Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２は、ＡｓｐｅｃｔＳＭ８２０のＥｖｅｎｔ要素８２１に基づいて、Ｆａｘ送信クラス６１１ｆより通知されたイベント（送信開始イベント７５３）は、振る舞い変更のトリガとなるイベントであると判断し、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２に「振る舞い変更情報」を添えて、Ｐｒｉｎｔｅｒ Ｓｅｒｖｉｃｅ７１２の振る舞いの変更を要求する（Ｓ５０４）。
【０１２８】
続いて、ステップＳ５０５からステップＳ５１０ｂまでは、図１８のステップＳ４２３からステップＳ４２８ｂまでと同様の処理が実行される。したがって、ステップＳ５１０ｂでは、図１９において説明した処理と同様の処理が実行され、Ｐｒｉｎｔｅｒ Ｓｅｒｖｉｃｅ７１２の振る舞いが変更される。すなわち、Ｐｒｉｎｔｅｒ Ｓｅｒｖｉｃｅ７１２における、Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２への状態遷移に対してガード条件が付加される。
【０１２９】
続いて、Ｍｏｄｉｆｙ Ａｇｅｎｔ７３２は、Ｐｒｉｎｔｅｒ Ｓｅｒｖｉｃｅ７１２の振る舞いの変更が完了したことをＭｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２に通知する（Ｓ５１１）。Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２は、Ｆａｘ送信クラス６１１ｆに対して変更の完了を通知する（Ｓ５１２）。
【０１３０】
Ｆａｘ送信クラス６１１ｆは、Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ６０２からの変更完了通知が届くまで待機している。Ｆａｘ送信クラス６１１ｆは、変更完了通知に応じてＳｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に対して送信開始イベント７５３を発行する（Ｓ５１３）。Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、送信開始イベント７５３の通知先を検索し、検索されたＦａｘ Ｓｅｒｖｉｃｅ７１３に送信開始イベント７５３を通知する（Ｓ５１４）。
【０１３１】
ここでＦａｘ Ｓｅｒｖｉｃｅ７１３によってＦａｘの送信処理が実行されるが、この間は、上記で説明した振る舞いの変更によってＰｒｉｎｔｅｒ Ｓｅｒｖｉｃｅ７１２に対して印刷開始イベント７４３が発行されても、印刷は開始されない。
【０１３２】
Ｆａｘ Ｓｅｒｖｉｃｅ７１４によるＦａｘ送信が完了すると（Ｓ５１５）、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、Ｆａｘ送信クラス６１１ｆに送信完了通知を行う（Ｓ５１６）。Ｆａｘ送信クラス６１１ｆは、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１からの送信完了通知を受けてＦａｘ送信アプリ５０１ｆに送信完了通知を行う（Ｓ５１７）。Ｆａｘ送信アプリ５０１ｆは、オペレーションパネル２０２に送信が完了した旨のメッセージ等を表示することにより、Ｆａｘ送信の完了をユーザに通知する（Ｓ５１８）。
【０１３３】
ところで、図２３のステップＳ５１４において、「Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、送信開始イベント７５３の通知先を検索する」と説明したが、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に通知されたイベントが、どのように各ステートマシンに通知されるかについて説明する。
【０１３４】
図２５は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌによるイベントの通知方式について説明するための図である。
【０１３５】
Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、イベントを受け付けると、管理しているステートマシン群に対して、ラウンドロビン方式で順番にイベントを発行する。これにより、ステートマシン間では排他的な動作が実現される。また、個々のステートマシンも遷移処理を排他的に処理することにより、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１内のアクション処理を排他的に実行することができる。
【０１３６】
図２５に示される手順に沿って説明する。
【０１３７】
送信開始イベント７５３が、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１に対して発行される（Ｓ５２１）。Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、管理している全てのステートマシン（但し、イベントに宛先が明示されている場合は、特定のステートマシン）に送信開始イベント７５３をラウンドロビン方式で発行する（Ｓ５２１〜Ｓ５２４）。例えば、Ｆａｘ Ｓｅｒｖｉｃｅ７１４が、待ち行列の最初に位置している場合、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、最初にＦａｘ Ｓｅｒｖｉｃｅ７１４に送信開始イベント７５３を発行する（Ｓ５２１）。
【０１３８】
Ｆａｘ Ｓｅｒｖｉｃｅ７１４は、今現在、アクティブな状態オブジェクトに接続している全ての遷移オブジェクトに対して順番にイベントを発行し、遷移条件を満足しているかを確認する。遷移条件を満足していれば、アクションを実行して遷移する。例えば、Ｉｄｌｅ状態７５１であれば、送信開始イベント７５３によりＦａｘＳｅｎｄ状態７５２に遷移し、Ｆａｘ送信を開始する。
【０１３９】
３）Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ
図２６は、図７のＪＳＤＫシステムを構成するＥｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３について説明するためのクラス図である。Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを拡張するクラスである。図７のＪＳＤＫシステムでは、第１節で取り上げたＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１と第３節で取り上げるＥｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３は同位層の関係にある。図７のＪＳＤＫシステムには、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１が存在し、Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、第１のＥｘｔｅｎｄ ＡＰＩ６１３−１が存在し、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１とＥｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３との間のサービス授受を仲介するＡＰＩとして、第２のＥｘｔｅｎｄ ＡＰＩ６１３−２が存在する。
【０１４０】
Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３とＥｘｔｅｎｄ ＡＰＩ６１３の実装理由を説明する事にする。ＪＳＤＫアプリ１４７の多様な変化にＪＳＤＫプラットフォーム１４８が適切に対応するには、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスをより他律的に変更できる方が好適な場合がある。Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に部品を外部から提供してＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを拡張する場合等である。よって、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを拡張するのに、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１のサービスを拡張するＥｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３を、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１とともに実装するのである。そしてさらに、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１とともにＥｘｔｅｎｄ ＡＰＩ６１３を実装する。
【０１４１】
図２６に示す通り、旧バージョンのユーザアプリ５０１は、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１を通じてＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求（Ｓ２０１）する。一方、新バージョンのユーザアプリ５０１は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に非拡張バージョンのサービスを要求する際は、Ｆｕｎｃｔｉｏｎ ＡＰＩ６１１を通じてＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求（Ｓ２０２）して、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に拡張バージョンのサービスを要求する際は、第１のＥｘｔｅｎｄ ＡＰＩ６１３−１とＥｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３と第２のＥｘｔｅｎｄ ＡＰＩ６１３−２とを通じてＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求（Ｓ２０３−１，２）する。
【０１４２】
図２７は、Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅの動作の概要を説明するための図である。
【０１４３】
図２７に示されるＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にて、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２には、非拡張バージョンのＦａｘ Ｓｅｒｖｉｃｅ７１４であるＦａｘＴｘ１と、拡張バージョンのＦａｘ Ｓｅｒｖｉｃｅ７１４であるＦａｘＴｘ２が存在する。ＦａｘＴｘ１は、画像データをＦＡＸ送信するＦａｘ Ｓｅｒｖｉｃｅ７１４である。ＦａｘＴｘ２は、画像データをＰＤＦからＴＩＦＦに変換してＦＡＸ送信するＦａｘ Ｓｅｒｖｉｃｅ７１４である。画像データをＰＤＦからＴＩＦＦに変換してＦＡＸ送信する場合において、ＦａｘＴｘ１が送信処理に関与する場合にはＪＳＤＫアプリ１４７で変換処理を実行する事になり、ＦａｘＴｘ２が送信処理に関与する場合にはＪＳＤＫプラットフォーム１４８で変換処理を実行する事になる。
【０１４４】
図２８は、ＦａｘＴｘ１やＦａｘＴｘ２の状態遷移モデルである。ＦａｘＴｘ１の状態には、初期状態７６０、Ｉｄｌｅ状態７６１、Ｓｅｎｄ状態７６２、及び終期状態７６４等が存在する。ＦａｘＴｘ２の状態には、初期状態７６０、Ｉｄｌｅ状態７６１、Ｓｅｎｄ状態７６２、Ｔｒａｎｓｆｏｒｍ状態７６３、及び終期状態７６４等が存在する。Ｉｄｌｅ状態７６１は、ＦＡＸ送信処理の待機中の状態である。Ｓｅｎｄ状態７６２は、ＦＡＸ送信処理を実行中の状態である。Ｔｒａｎｓｆｏｒｍ状態７６３は、画像変換処理を実行中の状態である。図２８により、ＦａｘＴｘ１とＦａｘＴｘ２は継承関係にある事が解る。ＦａｘＴｘ１が継承前のクラスであり、ＦａｘＴｘ２が継承後のクラスである。
【０１４５】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にて、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２では、自己の振る舞いを動的に継承する事で、自己の振る舞いを動的に変更する事ができる。例えば、図２７に示す通り、ＦａｘＴｘ１がＦａｘＴｘ２に動的に継承される事で、画像データをＰＤＦからＴＩＦＦに変換しない振る舞いが変換する振る舞いに動的に変更される事になる。
【０１４６】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にて、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２では、自己に振る舞い継承用のプラグイン部品をプラグインする事で、自己の振る舞いを動的に継承する事ができる。例えば、図２７に示す通り、画像データをＰＤＦからＴＩＦＦに変換するためのプラグイン部品の「ＰＤＦ２ＴＩＦＦ」のプラグインにより、ＦａｘＴｘ１がＦａｘＴｘ２に動的に継承される。振る舞い継承用のプラグイン部品は、Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３がＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に提供する。
【０１４７】
図２９は、Ｆａｘ Ｓｅｒｖｉｃｅに関するプラグイン処理を説明するための図である。
【０１４８】
Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にて、Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ７０２には、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１、Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３等のクラスが存在する。
【０１４９】
Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１は、ＦａｘＴｘ１やＦａｘＴｘ２の状態遷移モデルを管理するクラスである。Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３は、ＦａｘＴｘ１やＦａｘＴｘ２の状態遷移モデルに振る舞い継承用のプラグイン部品のプラグイン結果を反映させるクラスである。
【０１５０】
Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に振る舞い継承用のプラグイン部品がプラグインされた場合、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１が管理する状態遷移モデルに振る舞い継承用のプラグイン部品のプラグイン結果を反映させる。これによって、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１の振る舞いが動的に変更される。
【０１５１】
図２６から図２９にかけてその概要を説明したＦａｘＴｘ１からＦａｘＴｘ２への拡張処理について更に具体的に説明する。
【０１５２】
拡張前のＦａｘ Ｓｅｒｖｉｃｅ７１４であるＦａｘＴｘ１は、図１３に示したモデルに基づいて、以下のようなオブジェクトによって構成される。
【０１５３】
図３０は、ＦａｘＴｘ１のオブジェクト構成を表す図である。ＦａｘＴｘ１は、図２８の状態遷移モデルに基づいて、初期状態オブジェクト７６０Ｓ、終期状態オブジェクト７６４Ｓ、Ｉｄｌｅ状態オブジェクト７６１Ｓ、Ｓｅｎｄ状態オブジェクト７６２Ｓ、送信開始オブジェクト７６５Ｔ、送信処理オブジェクト７６２Ａ等より構成されている。
【０１５４】
また、図３１はＦａｘＴｘ２のオブジェクト構成を表す図である。ＦａｘＴｘ２は、図２８の状態遷移モデルに基づいて、初期状態オブジェクト７６０Ｓ、終期状態オブジェクト７６４Ｓ、Ｉｄｌｅ状態オブジェクト７６１Ｓ、Ｓｅｎｄ状態オブジェクト７６２Ｓ、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓ、送信開始オブジェクト７６５Ｔ、送信処理オブジェクト７６２Ａ、変換処理オブジェクト７６３Ａ、変換終了オブジェクト７６６Ｔ等より構成されている。なお、図３０及び図３１においては、一部の遷移オブジェクトが省略されているが（例えば、Ｓｅｎｄ状態７６２から終期状態７６４への状態遷移に対応する遷移オブジェクト）、これは便宜的なものである。
【０１５５】
図３０及び図３１より、ＦａｘＴｘ１からＦａｘＴｘ２への拡張処理とは「Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓ」や「変換処理オブジェクト７６３Ａ」や「変換終了オブジェクト７６６Ｔ」といった拡張処理用のオブジェクトをＦａｘＴｘ１に対して追加する事で実現できることが分かる。
【０１５６】
Ｆａｘ Ｓｅｒｖｉｃｅ７１４の拡張処理の影響が顕著なオブジェクトが、Ｆａｘ Ｓｅｒｖｉｃｅ７１４の更新部分のオブジェクトである。Ｆａｘ Ｓｅｒｖｉｃｅ７１４の更新部分のオブジェクトとは、オブジェクトの入替部分やオブジェクトの追加部分（Ｆａｘ Ｓｅｒｖｉｃｅ７１４の更新部分）に連結するオブジェクトを意味する。図３０から図３１への拡張処理では、Ｆａｘ Ｓｅｒｖｉｃｅ７１４の更新部分に相当するのがスイッチ７７０等の追加部分であり、Ｆａｘ Ｓｅｒｖｉｃｅ７１４の更新部分のオブジェクトに相当するのがＳｅｎｄ状態オブジェクト７６２Ｓや送信開始オブジェクト７６５Ｔである。Ｆａｘ Ｓｅｒｖｉｃｅ７１４の拡張処理をＦａｘ Ｓｅｒｖｉｃｅ７１４の動作中に実行するには、Ｆａｘ Ｓｅｒｖｉｃｅ７１４の更新部分のオブジェクトがアクティブ状態ではないとき（非アクティブ状態のとき）に実行すればよい。
【０１５７】
図３２及び図３３は、ＦａｘＴｘ１の状態遷移情報の定義例を示す図である。図３２及び図３３によって一つの状態遷移情報１１００の記述例が示されている。なお、図中における行番号は、説明の便宜上付加したものである。
【０１５８】
状態遷移情報１１００の１２１行目における＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグのタグ名、及びそのｎａｍｅ属性の値（ＦａｘＴｘ１）によって、状態遷移情報１１００は、ＦａｘＴｘ１に対応するものであることが定義されている。また、当該＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグにおけるｘｍｉ．ｉｄ属性の値（「００４」）は、ＦａｘＴｘ１を識別するＩＤである。
【０１５９】
１２５行目の＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグは、ＦａｘＴｘ１における状態の定義の開始の宣言に相当する。当該宣言は、＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグのｘｍｉ．ｉｄの値（「０１７」）によって識別される。
【０１６０】
１３０行目から１３７行目における＜Ｐｓｅｕｄｏｓｔａｔｅ＞タグによって囲まれたＰｓｅｕｄｏｓｔａｔｅ要素１１１０は、初期状態７６０に対する定義である。Ｐｓｅｕｄｏｓｔａｔｅ要素１１１０のｎａｍｅ属性の値には「Ｉｎｉｔ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０１８」が設定されている。
【０１６１】
１３８行目から１４８行目におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１２０は、Ｓｅｎｄ状態７６２に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１２０のｎａｍｅ属性の値には「Ｓｅｎｄ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０１９」が設定されている。
【０１６２】
１４９行目から１５９行目におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１３０は、Ｉｄｌｅ状態７６１に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１３０のｎａｍｅ属性の値には「Ｉｄｌｅ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０２２」が設定されている。
【０１６３】
１６０行目から１８３行目におけるＰｓｅｕｄｏｓｔａｔｅ要素１１４０は、終期状態７６４に対する定義である。Ｐｓｅｕｄｏｓｔａｔｅ要素１１４０のｎａｍｅ属性の値には「ｅｎｄ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０２４」が設定されている。
【０１６４】
また、１９１行目から２２８行目には、ＦａｘＴｘ１における各状態遷移が定義されている。すなわち、１９１行目から２０４行目におけるＴｒａｎｓｉｔｉｏｎ要素１１５０は、Ｉｄｌｅ状態７６１からＳｅｎｄ状態７６２への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素１１５０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ要素１１５０の子要素として定義されている、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１５１及びＴｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１５２より特定される。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１５１は遷移元の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１５１の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０２２」である。したがって、遷移元は、ｘｍｉ．ｉｄ属性の値が「０２２」の状態、すなわち、Ｉｄｌｅ状態７６１であることが分かる。また、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１５２は遷移先の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１５２の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０１９」である。したがって、遷移先は、ｘｍｉ．ｉｄの値が「０１９」の状態、すなわち、Ｓｅｎｄ状態７６２であることが分かる。なお、Ｔｒａｎｓｉｔｉｏｎ要素１１５０のｎａｍｅ属性の値は「送信開始」であり、ｘｍｉ．ｉｄ属性の値は「０２３」である。
【０１６５】
２０５行目から２１８行目におけるＴｒａｎｓｉｔｉｏｎ要素１１６０は、Ｓｅｎｄ状態７６２から終期状態７６４への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素１１６０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１６１内のｘｍｉ．ｉｄｒｅｆ属性の値が「０１９」（Ｓｅｎｄ状態７６２）であり、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１６２内のｘｍｉ．ｉｄｒｅｆ属性の値が「０２４」（終期状態７６４）であることから特定される。なお、Ｔｒａｎｓｉｔｉｏｎ要素１１６０のｎａｍｅ属性の値は「送信終了」であり、ｘｍｉ．ｉｄ属性の値は「０２０」である。
【０１６６】
２１９行目から２２８行目におけるＴｒａｎｓｉｔｉｏｎ要素１１７０は、初期状態７６０からＩｄｌｅ状態７６１への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素１１７０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１７１内のｘｍｉ．ｉｄｒｅｆ属性の値が「０１８」（初期状態７６０）であり、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１７２内のｘｍｉ．ｉｄｒｅｆ属性の値が「０２２」（Ｉｄｌｅ状態７６１）であることから特定される。なお、Ｔｒａｎｓｉｔｉｏｎ要素１１７０のｘｍｉ．ｉｄ属性の値は「０１８」である。
【０１６７】
１３０行目以降の説明に戻る。各状態に対応する、Ｐｓｅｕｄｏｓｔａｔｅ要素１１１０、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１２０、及びＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１３０は、ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素及びＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素の少なくともいずれか一方を子要素として有する。ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素は、遷移元からの状態遷移に対する接続が定義される要素である。ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素は、遷移先への状態遷移に対する接続が定義される要素である。
【０１６８】
例えば、初期状態７６０に対応するＰｓｅｕｄｏｓｔａｔｅ要素１１１０におけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素１１１１において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０１８」である。したがって、初期状態７６０からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素１１７０が対応する状態遷移に相当することが分かる。
【０１６９】
また、Ｓｅｎｄ状態７６２に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１２０おけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素１１２１においてその子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０２０」であり、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素１１２２において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０２３」である。したがって、Ｓｅｎｄ状態７６２からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素１１６０が対応する状態遷移に相当し、遷移元の状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素１１５０が対応する状態遷移に相当することが分かる。
【０１７０】
なお、Ｉｄｌｅ状態７６１に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１３０、終期状態７６４に対応するＰｓｅｕｄｏｓｔａｔｅ要素１１４０においても同様に状態遷移との接続が定義されている。
【０１７１】
このような状態遷移情報に基づいて、ＦａｘＴｘ１のオブジェクト構成は構築される。なお、オブジェクト構成の構築処理は、図１５において説明したものに準ずるため、ここでの説明は省略する。
【０１７２】
上記をふまえて、Ｆａｘ Ｓｅｒｖｉｃｅ７１４の拡張処理を具体的に説明する。図３４は、Ｆａｘ Ｓｅｒｖｉｃｅの拡張処理を説明するためのシーケンス図である。
【０１７３】
例えば、管理者は、ＦａｘＴｘ２とＦａｘＴｘ１との差分の追加モジュールが格納されたＳＤカードを融合機１０１のメモリカードスロット２３４に挿入する（Ｓ６０１）。
【０１７４】
図３５は、ＳＤカード内の追加モジュールの構成例を示す図である。図３５に示されるＳＤカード２３５ａには、Ｆａｘ拡張インタフェース６１３−１ａと、更新差分サービスバンドル８４０と、ＡｓｐｅｃｔＳＭ．ｘｍｌファイル８５０（ＡｓｐｅｃｔＳＭ８５０）とが格納されている。Ｆａｘ拡張インタフェース６１３−１ａ（ＦａｘＴｘＥｘ）は、Ｆａｘ Ｓｅｒｖｉｃｅ７１４を拡張するためのＥｘｔｅｎｄ ＡＰＩ６１３−１に相当する。すなわち、Ｆａｘ拡張インタフェース６１３−１ａは、ＦａｘＴｘ２をユーザアプリ５０１に利用させるためのインタフェースを提供する。更新差分サービスバンドル８４０には、拡張処理を実行するにあたり、図１３のクラス図において、ＩＳｔａｔｅインタフェース１００４ａ、Ａｃｔｉｖｉｔｙインタフェース１００４ｂ、Ｅｖｅｎｔインタフェース１００３ａ、Ｇｕａｒｄインタフェース１００３ｂ、又はＡｃｔｉｏｎインタフェース１００３ｃに対応するクラスのうち、追加が必要とされるクラスが実装された機能モジュール（例えば、Ｊａｖａ（登録商標）のクラスファイル。以下「追加モジュール」という。））が格納されている。ここでは、追加モジュールとして、ＰＤＦ２Ｔｉｆｆ８４１とＣｏｎｖｅｒｔＥｎｄ８４２とが格納されている。
【０１７５】
ＡｓｐｅｃｔＳＭ８５０は、ＦａｘＴｘ１からＦａｘＴｘ２への拡張処理をどのように実施するかについての仕様がＸＭＬ形式記述されているファイルである。
【０１７６】
図３６は、Ｆａｘ Ｓｅｒｖｉｃｅの拡張内容が記述されたＡｓｐｅｃｔＳＭの記述例を示す図である。図中、行番号は説明の便宜上付加したものである。ＡｓｐｅｃｔＳＭ８５０には、ＦａｘＴｘ１の状態遷移情報１１００（図３２及び図３３）に対する変更内容が記述されている。
【０１７７】
ＡｓｐｅｃｔＳＭ８５０の記述例において、２行目は、ｘｍｉ．ｉｄの値が「００４」であるＦａｘＴｘ１に対して状態遷移の変更を行うことを指示している。すなわち、２行目におけるｘｍｉ．ｉｄｒｅｆ属性は、変更の対象となるステートマシンのｘｍｉ．ｉｄが指定される。
【０１７８】
３行目から２０行目までは一つ目の変更箇所に関する変更情報が記述されている。３行目には、変更箇所と変更タイミングが指定されている。変更箇所は、ｐｏｉｎｔｃｕｔ．＜ｘｘｘ＞における＜ｘｘｘ＞の記述とｘｍｉ．ｒｅｆ属性の値とによって指定される。ここで、＜ｘｘｘ＞の部分は「ＣｏｍｐｏｓｉｔｅＳｔａｔｅ」であり、ｘｍｉ．ｒｅｆ属性の値は「０１７」である。したがって、状態遷移情報１１００の１２５行目における＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグ内に対する変更が指定されていることになる。また、変更のタイミングは、ｔｉｍｉｎｇ属性の値によって指定される。ここでは、「Ｉｄｌｅ」が指定されている。したがって、ＦａｘＴｘ１がＩｄｌｅ状態７６１にあるときに、変更を行うべきことが指定されている。
【０１７９】
４行目には、変更の内容が指定されている。すなわち、＜ａｄｖｉｃｅ．ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグのタグ名におけるａｄｖｉｃｅ．以降によって、変更の対象がＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素であることが指定されている。また、ｔｙｐｅ属性によって、変更の種別が「ｉｎｓｅｒｔ」（挿入）であることが指定されている。すなわち、３行目及び４行目によって、＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグ内に新たなＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素を挿入すべき旨が指定されている。
【０１８０】
５行目から１８行目は、挿入の対象となるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１の定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１は、ＦａｘＴｘ２のＴｒａｎｓｆｏｒｍ状態７６３に対応する。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１内の記述形式は、図３２及び図３３において説明した通りである。すなわち、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１の子要素である、ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素８５２において遷移先への接続が定義され、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素８５３において遷移元への接続が定義されている。
【０１８１】
ところで、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１は、Ｓｔａｔｅ．ｅｎｔｒｙ要素８５４が子要素として定義されている。Ｓｔａｔｅ．ｅｎｔｒｙ要素８５４は、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１が対応するＴｒａｎｓｆｏｒｍ状態７６３における入場処理が定義される要素である。すなわち、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１の子要素として、Ａｃｔｉｏｎ要素８５５が定義されているが、そのｘｍｉ．ｉｄ属性とｎａｍｅ属性より、ｘｍｉ．ｉｄ属性の値が「０２６」であり、ｎａｍｅ属性の値がｐｄｆ２ｔｉｆｆによって識別される処理が実行されることが指定されている。
【０１８２】
２１行目から４２行目までは二つ目の変更箇所に関する変更情報が指定されている。２１行目には、変更箇所及び変更のタイミングが指定されている。ここでは、Ｉｄｌｅ状態７６１のときにＴｒａｎｓｉｔｉｏｎ要素１１５０（図３３参照）に対して変更を行うことが指定されている。
【０１８３】
二つ目の変更箇所には、二つの変更が指定されている。２２行目から２４行目までに一つ目の変更が指定されており、２５行目から４１行目までに二つ目の変更が指定されている。
【０１８４】
一つ目の変更については、２２行目の＜ａｄｖｉｃｅ．Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ＞タグのタグ名におけるａｄｏｖｉｃｅ．以降によって変更対象がＴｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１５２であることが指定されている。また、ｔｙｐｅ属性によって、変更の種別が修正（ｍｏｄｉｆｙ）であることが指定されている。２３行目には、変更の対象に関して修正後の定義が記述されている。すなわち、一つ目の変更は、Ｉｄｌｅ状態７６１からＳｅｎｄ状態７６２への状態遷移を、Ｉｄｌｅ状態７６１からＴｒａｎｓｆｏｒｍ状態７６３への状態遷移に修正することである。
【０１８５】
二つ目の変更（２５行目から４１行目）は、新たな状態遷移（Ｔｒａｎｆｏｒｍ状態６０５からＳｅｎｄ状態７６２への状態遷移）に対応するＴｒａｎｓｉｓｉｏｎ要素の挿入をＩｄｌｅ状態７６１のときに行うことである。この内容は、上記の説明から読み取れるため、各行毎の説明は省略する。
【０１８６】
４３行目から５５行目は、標準ではなく独自の書式に基づく定義が行われている拡張記述部分である。４３行目のｐｏｉｎｔｃｕｔ．以下の「ＸＭＩ．ｅｘｔｅｎｓｉｏｎ」によって、拡張記述部分であることが指定されている。本実施の形態では、この部分に、状態遷移処理で呼ばれるアクション処理と、イベント処理等に使用する機能モジュール（例えば、Ｊａｖａ（登録商標）クラス）との関連付けが定義される。
【０１８７】
４４行目では、当該ａｄｖｉｃｅ要素の子要素の定義を挿入（ｉｎｓｅｒｔ）すべきことが指定されている。
【０１８８】
４５行目から４９行目までは、挿入される定義である。４５行目には、Ｂｕｎｄｌｅを実装することが指定されている。Ｂｕｎｄｌｅの実装先は、ｘｍｉ．ｉｄｒｅｆ属性の値（「００４」）で指定される。すなわち、ＦａｘＴｘ１である。
【０１８９】
４６行目から４９行目までは、Ｔｒａｎｓｆｏｒｍ状態７６３に対応させて新たに挿入するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１（５行目から１８行目）の入場処理の定義（１５行目から１７行目）におけるｐｄｆ２ｔｉｆｆと、実際にその処理が実装されているｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｐｄｆ２ｔｉｆｆクラスとの関連付けが定義されている。これによって、ＦａｘＴｘ２に更新された後、Ｔｒａｎｓｆｏｒｍ状態７６３に遷移したときには、ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｐｄｆ２ｔｉｆｆが実行されることになる。４８行目のｐｒｏｐｅｒｔｙ要素は、ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｐｄｆ２ｔｉｆｆクラスが実行されるときのプロパティ情報である。
【０１９０】
５０行目から５２行目は、Ｔｒａｎｓｆｏｒｍ状態７６３からＳｅｎｄ状態７６２への状態遷移のトリガとなる変換完了イベントとｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｃｏｎｖｅｒｔＥｎｄクラスとの関連付けが定義されている。これによって、Ｔｒａｎｅｆｏｒｍ状態６０５中に変換完了イベントが検知されると、ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｃｏｎｖｅｒｔＥｎｄクラスが実行され、その実行結果がｔｒｕｅであれば、Ｓｅｎｄ状態７６２に遷移することになる。
【０１９１】
図３４に戻る。管理者によるＳＤカード２３５ａの挿入が自動的に検知されると、又はＳＤカード２３５ａが挿入され、オペレーションパネル２０２から更新指示が入力されると、ＳＡＳ４１１は、ＳＡＳ Ｍａｎａｇｅｒ５１１に拡張処理の実行を要求する（Ｓ６０２）。なお、ＳＤカード２３５ａに記録された情報は、ネットワークを介してダウンロードされてもよい。この場合、ＳＤカードのような記録媒体を用いる必要はない。
【０１９２】
ＳＡＳ Ｍａｎａｇｅｒ５１１は、挿入されたＳＤカード２３５ａの更新差分サービスバンドル８４０によるＦａｘＴｘ１からＦａｘＴｘ２への更新の可否についてチェックを行う（Ｓ６０３）。更新が可能な場合、ＳＡＳ Ｍａｎａｇｅｒ５１１は、更新差分サービスバンドル８４０の融合機１０１へのインストールの可否をチェックする（Ｓ６０４）。インストールが可能な場合、ＳＡＳ Ｍａｎａｇｅｒ５１１は、ＳＤカード２３５ａ内の更新差分サービスバンドル８４０をＯＳＧｉフレームワーク４０３（融合機１０１）にインストールする（Ｓ６０５）。更新差分サービスバンドル８４０のインストールが完了すると、ＳＡＳ Ｍａｎａｇｅｒ５１１は、更新差分サービスバンドル８４０をアクティブ状態に遷移させるようにＯＳＧｉフレームワーク４０３に要求する（Ｓ６０６）。
【０１９３】
ＯＳＧｉフレームワーク４０３は、更新差分サービスバンドル８４０のインスタンスを（以下、「更新差分オブジェクト８４０ａ」という。）生成し、アクティブな状態に遷移させる（Ｓ６０７）。
【０１９４】
続いて、ＳＡＳ Ｍａｎａｇｅｒ５１１は、Ｆａｘ拡張インタフェース６１３−１ａをＯＳＧｉフレームワーク４０３にインストールし（Ｓ６０８）、Ｆａｘ拡張インタフェース６１３−１ａのＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１への組み込みをＥｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３に要求する（Ｓ６０９）。
【０１９５】
続いて、Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３が、Ｆａｘ拡張インタフェース６１３−１ａをアクティブな状態にするようＯＳＧｉフレームワーク４０３に要求すると（Ｓ６１０）、ＯＳＧｉフレームワーク４０３は、Ｆａｘ拡張インタフェース６１３−１ａをアクティブな状態に遷移させる。（Ｓ６１１）。Ｆａｘ拡張インタフェース６１３−１ａがアクティブな状態に遷移すると、Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ６０３は、Ｆａｘ拡張インタフェース６１３−１ａをＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１に登録する（Ｓ６１２）。これによって、Ｆａｘ拡張インタフェース６１３−１ａの呼び出しが可能となる。
【０１９６】
一方、ステップＳ６０７においてアクティブな状態にされた更新差分オブジェクト８４０ａは、Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３に対して更新差分サービスバンドル８４０がプラグインされたことをＡｓｐｅｃｔＳＭ８５０を添えて通知する（Ｓ６１３）。Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３は、Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ７３１より、ＦａｘＴｘ１のオブジェクト（ＦａｘＴｘ１オブジェクト７１４ａ）を取得する（Ｓ６１４、Ｓ６１５）。
【０１９７】
Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３は、ＦａｘＴｘ１オブジェクト７１４ａに対して、ＡｓｐｅｃｔＳＭ８５０を添えてＦａｘＴｘ２への更新要求を行う（Ｓ６１６）。ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０に基づいて、サービスバンドルＦａｘＴｘ１をＦａｘＴｘ２へ更新する為に必要な追加モジュール判断し、当該追加モジュール（ここでは、ＰＤＦ２Ｔｉｆｆ８４１及びＣｏｎｖｅｒｔＥｎｄ８４２）の取得を更新差分オブジェクト８４０ａに要求する（Ｓ６１７）。更新差分オブジェクト８４０ａは、当該追加モジュールを取得し、ＦａｘＴｘ１オブジェクト７１４ａに返却する（Ｓ６１８）。
【０１９８】
続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０に従って、ＦａｘＴｘ１のオブジェクト構成を、ＦａｘＴｘ２に対応するものに更新すると共に、当該更新によって新たに追加されたＡｃｔｉｖｉｔｙオブジェクトと追加モジュールとの関連付けを行う（Ｓ６１９）。なお、ステップＳ６１９の処理は、ＡｓｐｅｃｔＳＭ８５０に記述されているタイミングで行われる。
【０１９９】
続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＦａｘＴｘ１についてＦａｘＴｘ２への更新が完了したことをＰｌｕｇｉｎ Ａｇｅｎｔ７３３に通知する（Ｓ６２０）。但し、ＦａｘＴｘ１をＦａｘＴｘ２に切り替えるスイッチ７７０は、ＦａｘＴｘ１の状態のままである。
【０２００】
更新が完了した旨の通知は、ＳＡＳ Ｍａｎａｅｒ５１１を介してＳＡＳ４１１に通知される（Ｓ６２１、Ｓ６２２）。ＳＡＳ４１１は、管理者に更新完了を通知するため、オペレーションパネル２０２に更新完了を通知するメッセージを表示させる（Ｓ６２３）。なお、この状態では、スイッチ７７０は、まだＦａｘＴｘ２には切り替えられていないので、ＳＡＳ４１１は、管理者にＦａｘＴｘ２へ切り替える否かを問い合わせる。
【０２０１】
そこで、管理者が、オペレーションパネル２０２を介してＦａｘＴｘ２への切替指示を入力すると（Ｓ６２４）、ＳＡＳ４１１は、ＦａｘＴｘ２への切替要求をＳＡＳ Ｍａｎａｇｅｒ５１１に通知する（Ｓ６２５）。ＳＡＳ Ｍａｎａｇｅｒ５１１は、Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３にＦａｘＴｘ２への切り替えを要求する（Ｓ６２６）。Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３は、ＦａｘＴｘ１オブジェクト７１４ａに対して、その振る舞い（状態遷移）をＦａｘＴｘ２に対応するものに切り替えるように指示する（Ｓ６２７）。
【０２０２】
ＦａｘＴｘ１オブジェクト７１４ａは、ＦａｘＴｘ１がＩｄｌｅ状態７６１になるまで待機する。Ｉｄｌｅ状態７６１に遷移すると、ＦａｘＴｘ１オブジェクト７１４ａは、スイッチ７７０を切り換えることにより、自己の振る舞いをＦａｘＴｘ２に対応するものに切り替える（Ｓ６２８）。切り替えが完了すると、ＦａｘＴｘ１オブジェクト７１４ａは、Ｐｌｕｇｉｎ Ａｇｅｎｔ７３３に対して、切替完了通知を行う（Ｓ６２９）。切替完了通知は、ＳＡＳ Ｍａｎａｇｅｒ５１１を介してＳＡＳ４１１に伝達される（Ｓ６３０、Ｓ６３１）。ＳＡＳ４１１は、切替完了通知に応じ、ＦａｘＴｘ１の切り替えが完了した旨をオペレーションパネル２０２に表示させる（Ｓ６３２）。
【０２０３】
次に、ステップＳ６１９における、ＦａｘＴｘ１のオブジェクト構成の更新処理の詳細について説明する。図３７は、ＦａｘＴｘ１のオブジェクト構成の更新処理を説明するためのシーケンス図である。
【０２０４】
まず、ＦａｘＴｘ１オブジェクト７１４ａは、ＦａｘＴｘ１の状態が、ＡｓｐｅｃｔＳＭ８５０に指定されている変更箇所ごとにおけるｔｉｍｉｎｇ属性の値に指定されている状態に遷移するまで待機する（Ｓ６１９１）。図３６のＡｓｐｅｃｔＳＭ８５０の例では、全ての変更箇所に対するタイミングは、Ｉｄｌｅ状態７６１として指定されている。したがって、ここでは、Ｉｄｌｅ状態７６１に遷移するまで待機する。
【０２０５】
ＦａｘＴｘ１の状態がＩｄｌｅ状態７６１に遷移すると、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の記述にしたがって、拡張処理を開始する。
【０２０６】
例えば、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の３行目から２０行目に基づいてＴｒａｎｓｆｏｒｍ状態７６３に対応するＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓを生成する（Ｓ６１９２）。続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の２５行目から４１行目に基づいて、変換終了オブジェクト７６６Ｔを生成する（Ｓ６１９３）。続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の９行目から１４行目や、２２行目から２４行目に基づいて、オブジェクト間の接続関係を変更する。すなわち、ＦａｘＴｘ１オブジェクト７１４ａは、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓの識別情報を引数としてＩｄｌｅ状態オブジェクト７６１Ｓのｒｅｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ６１９４）。これに応じて、Ｉｄｌｅ状態オブジェクト７６１Ｓは、遷移先の状態オブジェクトとして、Ｓｅｎｄ状態オブジェクト７６２ＳとＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓとを保持することになる。これは、ちょうど図３１において、スイッチ７７０によって遷移先が分岐している状態に相当する。スイッチ７７０は、例えば、Ｉｄｌｅ状態オブジェクト７６１Ｓが参照可能なフラグ変数として実装される。例えば、当該フラグ変数の値が０のときには遷移先はＳｅｎｄ状態オブジェクト７６２Ｓとされ、１のときには遷移先はＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓとされるといった具合である。なお、Ｉｄｌｅ状態オブジェクト７６１ＳとＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓとの接続は行われたが、図３４において説明したように、この時点では、スイッチ７７０は切り替えられていないため、Ｉｄｌｅ状態オブジェクト７６１Ｓからの遷移先のオブジェクトはＳｅｎｄ状態オブジェクト７６２Ｓのままである（すなわち、ＦａｘＴｘ１として機能する。）。
【０２０７】
続いて、ＦａｘＴｘ１オブジェクト７１４ａは、Ｓｅｎｄ状態オブジェクト７６２Ｓの識別情報と変換完了オブジェクト７６６Ｔの識別情報とを引数としてＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓのｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ６１９５）。これに応じて、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓは、Ｓｅｎｄ状態オブジェクト７６２Ｓの識別情報と変換完了オブジェクト７６６Ｔの識別情報とを関連付けて保持する。すなわち、変換終了イベントが発生した際のＴｒａｎｓｆｏｒｍ状態７６３からＳｅｎｄ状態７６２への状態遷移に対応する接続が構築されたことになる。
【０２０８】
続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の４３行目から５５行目に基づいて、追加モジュールとオブジェクトとの関連付けを行う。すなわち、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓの入場処理のインタフェース（ＩＳｔａｔｅインタフェース１００４ａ）に対してＰＤＦ２ＴＩＦＦ８４１を関連付ける（Ｓ６１９６）。続いて、変換完了オブジェクト７６６ＴのＥｖｅｎｔインタフェース１００３ａに対してＣｏｎｖｅｒｔＥｎｄ８４２を関連付ける（Ｓ６１９７）。
【０２０９】
以上の処理によって、ＦａｘＴｘ１のオブジェクト構成は、図３１に示されるようなもの（ＦａｘＴｘ２）に更新される。
【０２１０】
ところで、図３６において、ＡｓｐｅｃｔＳＭ８５０にはＦａｘＴｘ１の状態遷移情報１１００（図３２及び図３３）に対する変更内容が記述されていると説明した。しかし、上記のように、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０に基づいて状態遷移情報１１００を書き換えるのではなく、ＦａｘＴｘ１を構成するオブジェクトを変更することで拡張処理を実現する。ＦａｘＴｘ１は、状態遷移情報１１００に基づいてそのオブジェクトが構築されたものである。したがって、状態遷移情報１１００に対する変更内容が記述されたＡｓｐｅｃｔＳＭ８５０は、そのままＦａｘＴｘ１のオブジェクト構成に適用することができるのである。なお、ＡｓｐｅｃｔＳＭ８５０に基づいて状態遷移情報１１００を更新し、更新された状態遷移情報１１００に基づいてＦａｘＴｘ１（厳密には、ＦａｘＴｘ２に更新されたもの）を再構築してもよい。但し、この場合、再構築の前にＦａｘＴｘ１を構成するオブジェクト群が破棄されるため、ＦａｘＴｘ１を利用中のアプリケーション等との参照関係が破壊されてしまう。したがって、本実施の形態のように、オブジェクト群を再構築するのではなく、既存のオブジェクト構成を変更する方が好適である。
【０２１１】
なお、上記のように、拡張処理後は、ＦａｘＴｘ１とＦａｘＴｘ２とは、スイッチ７７０を切り替えることにより容易に切り替えが可能である。したがって、ＦａｘＴｘ１からＦａｘＴｘ２への更新後、再度ＦａｘＴｘ２からＦａｘＴｘ１に戻したい場合は、スイッチ７７０を切り替えることにより実現すればよい。すなわち、Ｉｄｌｅ状態オブジェクト７６１Ｓが参照可能なフラグ変数の値を更新すればよい。また、ＦａｘＴｘ２からＦａｘＴｘ１への更新指示が記述されたＡｓｐｅｃｔＳＭに基づいて、ＦａｘＴｘ２からＦａｘＴｘ１への更新を実現してもよい。この場合スイッチ７７０を切り替えるタイミングは、当該ＡｓｐｅｃｔＳＭに記述されたタイミングで行われる。
【０２１２】
上述したように、本実施の形態では、ＡｓｐｅｃｔＳＭ８５０には、拡張部分が非アクティブなタイミングでＦａｘ Ｓｅｒｖｉｃｅ７１４の拡張が行われるような拡張指示が記述されている。そして、かかるＡｓｐｅｃｔＳＭ８５０に従って、拡張部分が非アクティブなときに拡張が実行される。したがって、本実施の形態におけるＦａｘ Ｓｅｒｖｉｃｅ７１４は、当該Ｆａｘ Ｓｅｒｖｉｃｅ７１４の実行中にその振る舞いの拡張を実行することができる。また、振る舞いの拡張にあたり、オブジェクト群が再構築されるわけではないので、当該Ｆａｘ Ｓｅｒｖｉｃｅ７１４の参照側との参照関係が破壊されることなく、動的にその振る舞いを拡張することが可能となっている。よって、融合機１０１を再起動することなくＦａｘ Ｓｅｒｖｉｃｅ７１４の振る舞いは拡張され得る。
【０２１３】
４）ＯＳＧｉ
図３８は、Ｓｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙ８０１について説明するためのクラス図である。Ｓｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙ８０１は、ＯＳＧｉフレームワーク４０３を構成するクラスである。サービス提供側であるＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、自己が提供するサービス内容をＳｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙ８０１に登録（Ｓ３０１）し、サービス要求側であるユーザアプリ５０１は、自己が要求するサービス内容をＳｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙ８０１から検索（Ｓ３０２）する。これによって、ユーザアプリ５０１は、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１にサービスを要求（Ｓ３０３）して、Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ６０１は、ユーザアプリ５０１にサービスを提供（Ｓ３０４）する。
【０２１４】
図３９は、状態遷移モデルのバンドル化手順について説明するためのデータ図である。状態遷移モデルは、振る舞いと部品に分離されて設計される。振る舞いはＸＭＩ言語にて記述されて、部品はＪａｖａ（登録商標）言語にて記述される。ＸＭＩ言語によるコードとＪａｖａ（登録商標）言語によるコードはＯＳＧｉによるバンドル化手順に従ってバンドル化される。バンドルには、マニフェストファイル８０２が同梱される。マニフェストファイル８０２には、バンドルにとって必要な情報が格納される。
【０２１５】
図４０・図４１は、ＣＳＣ４２１について説明するための図である。融合機１０１には他機のＯＳＧｉサービスプラットフォームを自機のＯＳＧｉサービスプラットフォームと同様に処理するためのＣＳＣ４２１が実装されている。ＣＳＣ４２１の実装態様は、図６に示す通りである。
【０２１６】
図４０は他機が融合機１０１である場合を表し、図４１は他機がＰＣ８０３である場合を表す。図４０・図４１に示す通り、自機のＣＳＣ４２１と他機のＣＳＣ４２１の仲介によって、自機のＳＡＳ Ｍａｎａｇｅｒ５１１と他機のＳＡＳ Ｍａｎａｇｅｒ５１１の連携が実現される。
【図面の簡単な説明】
【０２１７】
【図１】本発明の実施例に該当する融合機を表す。
【図２】図１の融合機に係るハードウェア構成図である。
【図３】図１の融合機に係る外観図である。
【図４】オペレーションパネルを表す。
【図５】図１のＣＳＤＫアプリとＪＳＤＫアプリのソフトウェア構成図である。
【図６】図１の融合機におけるＯＳＧｉについて説明するための図である。
【図７】図１のＪＳＤＫアプリとＪＳＤＫプラットフォームのクラス図である。
【図８】ＪＳＤＫシステムの起動処理を説明するための図である。
【図９】Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅについて説明するためのクラス図である。
【図１０】Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの動作の説明図である。
【図１１】Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの動作の具体例の説明図である。
【図１２】Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの振る舞い変更処理について概念的に説明するための図である。
【図１３】Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの振る舞いの動的な変更を実現するクラス群を説明するためのクラス図である。
【図１４】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅのオブジェクト構成を表す図である。
【図１５】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅのオブジェクト構成の構築処理を説明するためのシーケンス図である。
【図１６】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの状態遷移情報の定義例を示す図である。
【図１７】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの状態遷移情報の定義例を示す図である。
【図１８】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの振る舞い変更処理を説明するためのシーケンス図である。
【図１９】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの振る舞い変更処理を説明するためのシーケンス図である。
【図２０】Ｐｒｉｎｔ Ｓｅｒｖｉｃｅの振る舞いの変更内容が記述されたＡｓｐｅｃｔＳＭの記述例を示す図である。
【図２１】Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅについて説明するためのクラス図である。
【図２２】Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅについて説明するためのクラス図である。
【図２３】Ｍｏｄｉｆｙ ＳｅｒｖｉｃｅによるＦｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅの変更処理を説明するためのシーケンス図である。
【図２４】Ｆａｘ送信アプリに対応させて登録されたＡｓｐｅｃｔＳＭの記述例を示す図である。
【図２５】Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌによるイベントの通知方式について説明するための図である。
【図２６】Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅについて説明するためのクラス図である。
【図２７】Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅの動作の概要を説明するための図である。
【図２８】ＦａｘＴｘ１やＦａｘＴｘ２の状態遷移モデルである。
【図２９】Ｆａｘ Ｓｅｒｖｉｃｅに関するプラグイン処理を説明するための図である。
【図３０】ＦａｘＴｘ１のオブジェクト構成を表す図である。
【図３１】ＦａｘＴｘ２のオブジェクト構成を表す図である。
【図３２】ＦａｘＴｘ１の状態遷移情報の定義例を示す図である。
【図３３】ＦａｘＴｘ１の状態遷移情報の定義例を示す図である。
【図３４】Ｆａｘ Ｓｅｒｖｉｃｅの拡張処理を説明するためのシーケンス図である。
【図３５】ＳＤカード内の追加モジュールの構成例を示す図である。
【図３６】Ｆａｘ Ｓｅｒｖｉｃｅの拡張内容が記述されたＡｓｐｅｃｔＳＭの記述例を示す図である。
【図３７】ＦａｘＴｘ１のオブジェクト構成の更新処理を説明するためのシーケンス図である。
【図３８】Ｓｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙについて説明するためのクラス図である。
【図３９】状態遷移モデルのバンドル化手順について説明するためのデータ図である。
【図４０】ＣＳＣについて説明するための図（同機種の場合）である。
【図４１】ＣＳＣについて説明するための図（別機種の場合）である。
【符号の説明】
【０２１８】
１０１ 融合機
１１１ ハードウェア
１１２ ソフトウェア
１１３ 融合機起動部
１２１ 撮像部
１２２ 印刷部
１２３ その他のハードウェア
１３１ アプリケーション
１３２ プラットフォーム
１３３ アプリケーションプログラムインタフェース
１３４ エンジンインタフェース
１３５ 仮想アプリケーションサービス
１４１ コピーアプリ
１４２ プリンタアプリ
１４３ スキャナアプリ
１４４ ファクシミリアプリ
１４５ ネットワークファイルアプリ
１４６ ＣＳＤＫアプリ
１４７ ＪＳＤＫアプリ
１４８ ＪＳＤＫプラットフォーム
１５１ コントロールサービス
１５２ システムリソースマネージャ
１５３ ハンドラ
１６１ ネットワークコントロールサービス
１６２ ファクシミリコントロールサービス
１６３ デリバリコントロールサービス
１６４ エンジンコントロールサービス
１６５ メモリコントロールサービス
１６６ オペレーションパネルコントロールサービス
１６７ サーティフィケーションコントロールサービス
１６８ ユーザディレクトリコントロールサービス
１６９ システムコントロールサービス
１７１ ファクシミリコントロールユニットハンドラ
１７２ イメージメモリハンドラ
２０１ コントローラ
２０２ オペレーションパネル
２０３ ファクシミリコントロールユニット
２１１ ＣＰＵ
２１２ ＡＳＩＣ
２２１ ＮＢ
２２２ ＳＢ
２３１ ＭＥＭ−Ｐ
２３２ ＭＥＭ−Ｃ
２３３ ＨＤＤ
２３４ メモリカードスロット
２３５ メモリカード
２４１ ＮＩＣ
２４２ ＵＳＢデバイス
２４３ ＩＥＥＥ１３９４デバイス
２４４ セントロニクスデバイス
３０１ 原稿セット部
３０２ 給紙部
３０３ 排紙部
３１１ タッチパネル
３１２ テンキー
３１３ スタートボタン
３１４ リセットボタン
３１５ 機能キー
３１６ 初期設定ボタン
３２１ ＡＤＦ
３２２ フラットベッド
３２３ フラットベッドカバー
４０１ ＯＳＧｉアプリ
４０２ ＯＳＧｉサービス
４０３ ＯＳＧｉフレームワーク
４０４ Ｂｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ
４１１ ＳＡＳ
４２１ ＣＳＣ
５０１ ユーザアプリ
５１１ ＳＡＳ Ｍａｎａｇｅｒ
５１２ Ｓｃｒｅｅｎ Ｍａｎａｇｅｒ
５２１ ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ
５３１ Ｘｌｅｔ Ｍａｎａｇｅｒ
５３２ Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ
５４１ Ｓｅｎｄ Ｍａｎａｇｅｒ
５４２ Ｅｖｅｎｔ Ｍａｎａｇｅｒ
５４３ Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ
５４４ Ｐａｎｅｌ Ｍａｎａｇｅｒ
５４５ Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ
５４６ Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ
５４７ Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｒ
５５１ ＪＳＤＫ ＡＰＩ
５５２ ＪＳＤＫ ＡＰＩ
５５３ ＪＳＤＫ Ｓｅｓｓｉｏｎ
５５４ Ｎａｔｉｖｅ ＪＳＤＫ Ｓｅｓｓｉｏｎ
５５５ ＣＶＭ
６０１ Ｆｕｎｃｔｉｏｎ Ｓｅｒｖｉｃｅ
６０２ Ｍｏｄｉｆｙ Ｓｅｒｖｉｃｅ
６０３ Ｅｘｔｅｎｄ Ｓｅｒｖｉｃｅ
６１１ Ｆｕｎｃｔｉｏｎ ＡＰＩ
６１２ Ｍｏｄｉｆｙ ＡＰＩ
６１３ Ｅｘｔｅｎｄ ＡＰＩ
６２１ Ｃ／Ｊ ＡＰＩ
７０１ Ａｄａｐｔｉｖｅ Ｆｕｎｃｔｉｏｎ
７０２ Ａｄａｐｔｉｖｅ Ｂｅｈａｖｉｏｒ
７１１ Ｃｏｐｙ Ｓｅｒｖｉｃｅ
７１２ Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ
７１３ Ｓｃａｎ Ｓｅｒｖｉｃｅ
７１４ Ｆａｘ Ｓｅｒｖｉｃｅ
７２１ ＳＡＳ Ｓｅｒｖｉｃｅ
７３１ Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｐｏｏｌ
７３２ Ｍｏｄｉｆｙ Ａｇｅｎｔ
７３３ Ｐｌｕｇｉｎ Ａｇｅｎｔ
７４１ Ｉｄｌｅ状態
７４２ Ｐｒｉｎｔ状態
７４３ 印刷開始イベント
７４４ 印刷終了イベント
７４６ ガード条件オブジェクト
７４１Ｓ Ｉｄｌｅ状態オブジェクト
７４２Ｓ Ｐｒｉｎｔ状態オブジェクト
７４３Ｔ 印刷開始オブジェクト
７４４Ｔ 印刷終了オブジェクト
７５１ Ｉｄｌｅ状態
７５２ ＦａｘＳｅｎｄ状態
７５３ 送信開始イベント
７５４ 送信終了イベント
７６０ 初期状態
７６１ Ｉｄｌｅ状態
７６２ Ｓｅｎｄ状態
７６３ Ｔｒａｎｓｆｏｒｍ状態
７６４ 終期状態
８０１ Ｓｅｒｖｉｃｅ Ｒｅｇｉｓｔｒｙ
８０２ マニフェストファイル
８０３ ＰＣ
８１０、８２０ ＡｓｐｅｃｔＳＭ
９００、１１００ 状態遷移情報
１０００ ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌクラス
１００１ ＳｔａｔｅＭａｃｈｉｎｅクラス
１００２ ＳｔａｔｅＶｅｒｔｅｘクラス
１００３ Ｔｒａｎｓｉｔクラス
１００３ａ Ｅｖｅｎｔインタフェース
１００３ｂ Ｇｕａｒｄインタフェース
１００３ｃ Ａｃｔｉｏｎインタフェース
１００４ Ｓｔａｔｅクラス
１００４ａ ＩＳｔａｔｅインタフェース
１００４ｂ Ａｃｔｉｖｉｔｙインタフェース
１００５ ＰｓｅｕｄｏＳｔａｔｅクラス
１００６ ＩｎｉｔｉａｌＳｔａｔｅクラス
１００７ ＦｉｎａｌＳｔａｔｅクラス
１００８ ＰｌｕｇｉｎＡｇｅｎｔクラス
１００９ ＭｏｄｉｆｙＡｇｅｎｔクラス
【特許請求の範囲】
【請求項１】
アプリケーションにサービスを提供し互いに排他的に動作する複数のモジュールの接続によって構成されるサービス提供プログラムを備える画像形成装置であって、
前記サービス提供プログラムの変更情報の入力を受け付ける入力手段と、
前記サービス提供プログラムの動作状態が、前記変更情報において指定されている変更のタイミングに相当するか否かを判定するタイミング判定手段と、
前記タイミング判定手段によって前記変更のタイミングであると判定されたときに、前記変更情報に従って、前記複数のモジュールの接続関係を変更する変更手段と、
前記変更が施された前記サービス提供プログラムを前記アプリケーションに利用させるためのインタフェースを追加するインタフェース追加手段とを有することを特徴とする画像形成装置。
【請求項２】
前記サービス提供プログラムは、前記変更情報に指定されている変更箇所に対応するモジュールの接続関係を変更することを特徴とする請求項１記載の画像形成装置。
【請求項３】
前記変更情報には、少なくとも前記変更箇所に対応するモジュールが動作中でないときが前記変更のタイミングとして指定されていることを特徴とする請求項２記載の画像形成装置。
【請求項４】
前記変更情報には、動作中のモジュールを特定することにより前記変更のタイミングが指定されており、
前記サービス提供プログラムは、前記変更のタイミングとして指定されたモジュールが動作中であるときに、当該変更のタイミングであると判定することを特徴とする請求項１乃至３いずれか一項記載の画像形成装置。
【請求項５】
前記サービス提供プログラムは、前記変更のタイミングであると判定するまで前記変更を待機することを特徴とする請求項１乃至４いずれか一項記載の画像形成装置。
【請求項６】
前記サービス提供プログラムを構成する各モジュールは、当該サービス提供プログラムの状態遷移における各状態に対応し、
前記複数のモジュールの接続関係は、前記各状態間の状態遷移に対応することを特徴とする請求項１乃至５いずれか一項記載の画像形成装置。
【請求項７】
アプリケーションにサービスを提供し互いに排他的に動作する複数のモジュールの接続によって構成されるサービス提供プログラムを備える画像形成装置によって実行される情報処理方法であって、
前記サービス提供プログラムの変更情報の入力を受け付ける入力手順と、
前記サービス提供プログラムの動作状態が、前記変更情報において指定されている変更のタイミングに相当するか否かを判定するタイミング判定手順と、
前記タイミング判定手順において前記変更のタイミングであると判定されたときに、前記変更情報に従って、前記複数のモジュールの接続関係を変更する変更手順と、
前記変更が施された前記サービス提供プログラムを前記アプリケーションに利用させるためのインタフェースを追加するインタフェース追加手順とを有することを特徴とする情報処理方法。
【請求項８】
前記変更手順は、前記変更情報に指定されている変更箇所に対応するモジュールの接続関係を変更することを特徴とする請求項７記載の情報処理方法。
【請求項９】
前記変更情報には、少なくとも前記変更箇所に対応するモジュールが動作中でないときが前記変更のタイミングとして指定されていることを特徴とする請求項８記載の情報処理方法。
【請求項１０】
前記変更情報には、動作中のモジュールを特定することにより前記変更のタイミングが指定されており、
前記変更手順は、前記変更のタイミングとして指定されたモジュールが動作中であるときに、当該変更を行うことを特徴とする請求項７乃至９いずれか一項記載の情報処理方法。
【請求項１１】
前記変更手順は、前記変更のタイミングであると判定されるまで前記変更を待機することを特徴とする請求項８乃至１１いずれか一項記載の情報処理方法。
【請求項１２】
前記サービス提供プログラムを構成する各モジュールは、当該サービス提供プログラムの状態遷移における各状態に対応し、
前記複数のモジュールの接続関係は、前記各状態間の状態遷移に対応することを特徴とする請求項７乃至１１いずれか一項記載の情報処理方法。
【請求項１３】
請求項７乃至１２いずれか一項記載の情報処理方法をコンピュータに実行させるための情報処理プログラム。
【請求項１４】
請求項１３記載の情報処理プログラムを記録したコンピュータ読取可能な記録媒体。
【請求項１】
アプリケーションにサービスを提供し互いに排他的に動作する複数のモジュールの接続によって構成されるサービス提供プログラムを備える画像形成装置であって、
前記サービス提供プログラムの変更情報の入力を受け付ける入力手段と、
前記サービス提供プログラムの動作状態が、前記変更情報において指定されている変更のタイミングに相当するか否かを判定するタイミング判定手段と、
前記タイミング判定手段によって前記変更のタイミングであると判定されたときに、前記変更情報に従って、前記複数のモジュールの接続関係を変更する変更手段と、
前記変更が施された前記サービス提供プログラムを前記アプリケーションに利用させるためのインタフェースを追加するインタフェース追加手段とを有することを特徴とする画像形成装置。
【請求項２】
前記サービス提供プログラムは、前記変更情報に指定されている変更箇所に対応するモジュールの接続関係を変更することを特徴とする請求項１記載の画像形成装置。
【請求項３】
前記変更情報には、少なくとも前記変更箇所に対応するモジュールが動作中でないときが前記変更のタイミングとして指定されていることを特徴とする請求項２記載の画像形成装置。
【請求項４】
前記変更情報には、動作中のモジュールを特定することにより前記変更のタイミングが指定されており、
前記サービス提供プログラムは、前記変更のタイミングとして指定されたモジュールが動作中であるときに、当該変更のタイミングであると判定することを特徴とする請求項１乃至３いずれか一項記載の画像形成装置。
【請求項５】
前記サービス提供プログラムは、前記変更のタイミングであると判定するまで前記変更を待機することを特徴とする請求項１乃至４いずれか一項記載の画像形成装置。
【請求項６】
前記サービス提供プログラムを構成する各モジュールは、当該サービス提供プログラムの状態遷移における各状態に対応し、
前記複数のモジュールの接続関係は、前記各状態間の状態遷移に対応することを特徴とする請求項１乃至５いずれか一項記載の画像形成装置。
【請求項７】
アプリケーションにサービスを提供し互いに排他的に動作する複数のモジュールの接続によって構成されるサービス提供プログラムを備える画像形成装置によって実行される情報処理方法であって、
前記サービス提供プログラムの変更情報の入力を受け付ける入力手順と、
前記サービス提供プログラムの動作状態が、前記変更情報において指定されている変更のタイミングに相当するか否かを判定するタイミング判定手順と、
前記タイミング判定手順において前記変更のタイミングであると判定されたときに、前記変更情報に従って、前記複数のモジュールの接続関係を変更する変更手順と、
前記変更が施された前記サービス提供プログラムを前記アプリケーションに利用させるためのインタフェースを追加するインタフェース追加手順とを有することを特徴とする情報処理方法。
【請求項８】
前記変更手順は、前記変更情報に指定されている変更箇所に対応するモジュールの接続関係を変更することを特徴とする請求項７記載の情報処理方法。
【請求項９】
前記変更情報には、少なくとも前記変更箇所に対応するモジュールが動作中でないときが前記変更のタイミングとして指定されていることを特徴とする請求項８記載の情報処理方法。
【請求項１０】
前記変更情報には、動作中のモジュールを特定することにより前記変更のタイミングが指定されており、
前記変更手順は、前記変更のタイミングとして指定されたモジュールが動作中であるときに、当該変更を行うことを特徴とする請求項７乃至９いずれか一項記載の情報処理方法。
【請求項１１】
前記変更手順は、前記変更のタイミングであると判定されるまで前記変更を待機することを特徴とする請求項８乃至１１いずれか一項記載の情報処理方法。
【請求項１２】
前記サービス提供プログラムを構成する各モジュールは、当該サービス提供プログラムの状態遷移における各状態に対応し、
前記複数のモジュールの接続関係は、前記各状態間の状態遷移に対応することを特徴とする請求項７乃至１１いずれか一項記載の情報処理方法。
【請求項１３】
請求項７乃至１２いずれか一項記載の情報処理方法をコンピュータに実行させるための情報処理プログラム。
【請求項１４】
請求項１３記載の情報処理プログラムを記録したコンピュータ読取可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【公開番号】特開２００７−１１０６８９（Ｐ２００７−１１０６８９Ａ）
【公開日】平成１９年４月２６日（２００７．４．２６）
【国際特許分類】
【出願番号】特願２００６−２４３２２２（Ｐ２００６−２４３２２２）
【出願日】平成１８年９月７日（２００６．９．７）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成１９年４月２６日（２００７．４．２６）
【国際特許分類】
【出願日】平成１８年９月７日（２００６．９．７）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]