JP5025193B2

JP5025193B2 - 機器、情報処理方法、情報処理プログラム、及び記録媒体

Info

Publication number: JP5025193B2
Application number: JP2006243221A
Authority: JP
Inventors: 光男安藤
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2005-09-16
Filing date: 2006-09-07
Publication date: 2012-09-12
Anticipated expiration: 2026-09-07
Also published as: JP2007109219A

Description

本発明は、機器、情報処理方法、情報処理プログラム、及び記録媒体に関する。

近年、コピー機能とプリンタ機能とスキャナ機能とファクシミリ機能を備える複合機や融合機が市販されるようになった。複合機や融合機は、コピーやプリンタとして機能する場合には、画像を印刷用紙に印刷することになり、コピーやスキャナとして機能する場合には、画像を読取原稿から読み取ることになり、ファクシミリとして機能する場合には、画像を電話回線を介して他の機器と授受することになる。
特開２００２−８４３８３号公報

近年、複合機や融合機には様々なアプリケーションやプラットフォームが実装される。そんな中で問題視されるのが、次々に登場する新規なアプリケーションに既存のプラットフォームが対応し切れなくなるのではないかと言う点である。プラットフォームの設計時において、随時開発されるアプリケーション同士の差異を考慮したり将来開発される種々のアプリケーションの機能を予測したりするのは非常に困難である。従って、アプリケーションの種類によってはプラットフォームの影響で正常に動作しない可能性も出て来る。従って、アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを実現する事が望まれる。

本発明は、アプリケーションやプラットフォームが実装される機器に関して、アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを実現することを課題とする。

そこで上記課題を解決するため、本発明は、第一のプログラムにサービスを提供し、互いに排他的に機器を動作させる複数のモジュールによって構成される第二のプログラムを備える機器であって、前記各モジュールは、前記第二のプログラムの状態遷移における各状態又は前記各状態間の状態遷移に対応し、前記状態遷移に対応するモジュールの識別情報と、当該状態遷移の条件と、当該条件を当該モジュールに対して設定する契機を示す情報とが指定された変更情報を記憶する変更情報記憶手段と、前記第一のプログラムが当該機器に実行させる前記第二のプログラムに対するサービスの提供要求に応じ、当該提供要求が前記契機を示す情報として前記変更情報に指定されている場合に、当該変更情報に指定されている前記条件を、当該変更情報に指定されている前記識別情報に係る前記モジュールに設定する変更手段とを有し、前記第二のプログラムは、当該第二のプログラムの状態遷移が発生する際は、当該状態遷移に対応する前記モジュールに対して設定されている条件に基づいて、当該状態遷移の可否を当該機器に判定させることを特徴とする。

このような機器では、アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを実現することができる。

本発明は、アプリケーションやプラットフォームが実装される機器に関して、アプリケーションの多様な変化にプラットフォームが適切に対応できる仕組みを実現するものである。

図１は、本発明の実施例に該当する融合機１０１を表す。図１の融合機１０１は、種々のハードウェア１１１と、種々のソフトウェア１１２と、融合機起動部１１３により構成される。

融合機１０１のハードウェア１１１としては、撮像部１２１と、印刷部１２２と、その他のハードウェア１２３が存在する。撮像部１２１は、読取原稿から画像（画像データ）を読み取るためのハードウェアである。印刷部１２２は、画像（画像データ）を印刷用紙に印刷するためのハードウェアである。

融合機１０１のソフトウェア１１２としては、種々のアプリケーション１３１と、種々のプラットフォーム１３２が存在する。これらのプログラムは、ＵＮＩＸ（登録商標）等のＯＳ（オペレーティングシステム）によりプロセス単位で並列的に実行される。

アプリケーション１３１としては、コピー用のアプリケーションであるコピーアプリ１４１、プリンタ用のアプリケーションであるプリンタアプリ１４２、スキャナ用のアプリケーションであるスキャナアプリ１４３、ファクシミリ用のアプリケーションであるファクシミリアプリ１４４、ネットワークファイル用のアプリケーションであるネットワークファイルアプリ１４５が存在する。

アプリケーション１３１は、専用のＳＤＫ（ソフトウェア開発キット）を使用して開発することができる。ＳＤＫを使用して開発したアプリケーション１３１をＳＤＫアプリと呼ぶ。専用のＳＤＫとしては、Ｃ言語でアプリケーション１３１を開発するための「ＣＳＤＫ」や、Ｊａｖａ（登録商標）言語でアプリケーション１３１を開発するための「ＪＳＤＫ」が提供される。ＣＳＤＫを使用して開発したアプリケーション１３１を「ＣＳＤＫアプリ」と呼び、ＪＳＤＫを使用して開発したアプリケーション１３１を「ＪＳＤＫアプリ」と呼ぶ。図１の融合機１０１にも、ＣＳＤＫアプリ１４６と、ＪＳＤＫアプリ１４７が存在する。図１の融合機１０１にはさらに、Ｊａｖａ（登録商標）言語で記述されたＪＳＤＫアプリ１４７とＣ言語で記述された他のソフトウェア１１２との仲介を行うソフトウェア１１２として、ＪＳＤＫプラットフォーム１４８が存在する。

プラットフォーム１３２としては、種々のコントロールサービス１５１、システムリソースマネージャ１５２、種々のハンドラ１５３が存在する。コントロールサービス１５１としては、ネットワークコントロールサービス（ＮＣＳ）１６１、ファクシミリコントロールサービス（ＦＣＳ）１６２、デリバリコントロールサービス（ＤＣＳ）１６３、エンジンコントロールサービス（ＥＣＳ）１６４、メモリコントロールサービス（ＭＣＳ）１６５、オペレーションパネルコントロールサービス（ＯＣＳ）１６６、サーティフィケーションコントロールサービス（ＣＣＳ）１６７、ユーザディレクトリコントロールサービス（ＵＣＳ）１６８、システムコントロールサービス（ＳＣＳ）１６９が存在する。ハンドラ１５３としては、ファクシミリコントロールユニットハンドラ（ＦＣＵＨ）１７１、イメージメモリハンドラ（ＩＭＨ）１７２が存在する。

ＮＣＳ１６１のプロセスは、ネットワーク通信の仲介を行う。ＦＣＳ１６２のプロセスは、ファクシミリのＡＰＩを提供する。ＤＣＳ１６３のプロセスは、蓄積文書の配信処理に関する制御を行う。ＥＣＳ１６４のプロセスは、撮像部１２１や印刷部１２２に関する制御を行う。ＭＣＳ１６５のプロセスは、メモリやハードディスクドライブに関する制御を行う。ＯＣＳ１６６のプロセスは、オペレーションパネルに関する制御を行う。ＣＣＳ１６７のプロセスは、認証処理や課金処理に関する制御を行う。ＵＣＳ１６８のプロセスは、ユーザ情報の管理に関する制御を行う。ＳＣＳ１６９のプロセスは、システムの管理に関する制御を行う。

アプリケーション１３１とプラットフォーム１３２の仲介を行うソフトウェア１１２として、仮想アプリケーションサービス（ＶＡＳ）１３５が存在する。ＶＡＳ１３５は、アプリケーション１３１をクライアントとするサーバプロセスとして動作すると共に、プラットフォーム１３２をサーバとするクライアントプロセスとして動作する。ＶＡＳ１３５は、アプリケーション１３１から見てプラットフォーム１３２を隠蔽するラッピング機能を備え、プラットフォーム１３２のバージョンアップに伴うバージョン差を吸収する役割等を担う。

融合機起動部１１３は、融合機１０１の電源投入時に最初に実行される。これにより、ＵＮＩＸ（登録商標）等のＯＳが起動され、アプリケーション１３１やプラットフォーム１３２が起動される。これらのプログラムは、ハードディスクドライブやメモリカードに蓄積されており、ハードディスクドライブやメモリカードから再生されて、メモリに起動されることになる。

図２は、図１の融合機１０１に係るハードウェア構成図である。融合機１０１のハードウェア１１１としては、コントローラ２０１と、オペレーションパネル２０２と、ファクシミリコントロールユニット（ＦＣＵ）２０３と、撮像部１２１と、印刷部１２２が存在する。

コントローラ２０１は、ＣＰＵ２１１、ＡＳＩＣ２１２、ＮＢ２２１、ＳＢ２２２、ＭＥＭ−Ｐ２３１、ＭＥＭ−Ｃ２３２、ＨＤＤ（ハードディスクドライブ）２３３、メモリカードスロット２３４、ＮＩＣ（ネットワークインタフェースコントローラ）２４１、ＵＳＢデバイス２４２、ＩＥＥＥ１３９４デバイス２４３、セントロニクスデバイス２４４により構成される。

ＣＰＵ２１１は、種々の情報処理用のＩＣである。ＡＳＩＣ２１２は、種々の画像処理用のＩＣである。ＮＢ２２１は、コントローラ２０１のノースブリッジである。ＳＢ２２２は、コントローラ２０１のサウスブリッジである。ＭＥＭ−Ｐ２３１は、融合機１０１のシステムメモリである。ＭＥＭ−Ｃ２３２は、融合機１０１のローカルメモリである。ＨＤＤ２３３は、融合機１０１のストレージである。メモリカードスロット２３４は、メモリカード２３５をセットするためのスロットである。ＮＩＣ２４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス２４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。セントロニクスデバイス２４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。

オペレーションパネル２０２は、オペレータが融合機１０１に入力を行うためのハードウェア（操作部）であると共に、オペレータが融合機１０１から出力を得るためのハードウェア（表示部）である。

図３は、図１の融合機１０１に係る外観図である。図３には、撮像部１２１の位置と、印刷部１２２の位置と、オペレーションパネル２０２の位置が図示されている。図３には更に、読取原稿のセット先となる原稿セット部３０１と、印刷用紙の給紙先となる給紙部３０２と、印刷用紙の排紙先となる排紙部３０３が図示されている。

オペレーションパネル２０２は、図４のように、タッチパネル３１１と、テンキー３１２と、スタートボタン３１３と、リセットボタン３１４と、機能キー３１５と、初期設定ボタン３１６により構成される。タッチパネル３１１は、タッチ操作で入力を行うためのハードウェア（タッチ操作部）であると共に、画面表示で出力を得るためのハードウェア（画面表示部）である。テンキー３１２は、キー（ボタン）操作で数字入力を行うためのハードウェアである。スタートボタン３１３は、ボタン操作でスタート操作を行うためのハードウェアである。リセットボタン３１４は、ボタン操作でリセット操作を行うためのハードウェアである。機能キー３１５は、キー（ボタン）操作でＣＳＤＫアプリ１４６やＪＳＤＫアプリ１４７による操作画面を表示させるためのハードウェアである。初期設定ボタン３１６は、ボタン操作で初期設定画面を表示させるためのハードウェアである。

原稿セット部３０１は、ＡＤＦ（自動原稿搬送装置）３２１と、フラットベッド３２２と、フラットベッドカバー３２３により構成される。給紙部３０２は、４個の給紙トレイにより構成される。排紙部３０３は、１個の排紙トレイにより構成される。

（ＣＳＤＫ／ＪＳＤＫ／ＯＳＧｉ）
図５は、図１のＣＳＤＫアプリ１４６とＪＳＤＫアプリ１４７のソフトウェア構成図である。ＣＳＤＫアプリ１４６は、Ｃ言語のアプリケーションであり、それぞれプロセスとして実行される事になる。ＪＳＤＫアプリ１４７は、Ｊａｖａ（登録商標）言語のアプリケーションであり、それぞれスレッドとして実行される事になる。

図１の融合機１０１には、ＣＳＤＫアプリ１４６として、他のＣＳＤＫアプリ１４６の制御を行うＳＡＳ（ＳＤＫアプリケーションサービス）４１１が存在し、ＪＳＤＫアプリ１４７として、他のＪＳＤＫアプリ１４７の制御を行うＳＡＳＭａｎａｇｅｒ（ＳＤＫアプリケーションサービスマネージャ）５１１が存在する。ＣＳＤＫアプリ１４６の方はプロセスとして実行されてＪＳＤＫアプリ１４７の方はスレッドとして実行されるので、ＣＳＤＫアプリ１４６用のアプリケーション管理機構とＪＳＤＫアプリ１４７用のアプリケーション管理機構が別個に存在するのである。ＳＡＳ４１１とＳＡＳＭａｎａｇｅｒ５１１はそれぞれ、ＣＳＤＫアプリ１４６とＪＳＤＫアプリ１４７の起動制御，起動解除制御，インストール制御，アンインストール制御，アップデート制御等を行う。

さて、ＳＡＳ４１１は、ＣＳＤＫアプリ１４６の制御を行う事ができるだけではなく、ＳＡＳＭａｎａｇｅｒ５１１を介してＪＳＤＫアプリ１４７の制御を行う事もできる。ＳＡＳ４１１は、ＣＳＤＫアプリ１４６については直接的にその制御を行う事ができると共に、ＪＳＤＫアプリ１４７についてはＳＡＳＭａｎａｇｅｒ５１１を介して間接的にその制御を行う事ができるのである。このように、ＣＳＤＫアプリ１４６用のアプリケーション管理機構とＪＳＤＫアプリ１４７用のアプリケーション管理機構は、ＳＡＳＭａｎａｇｅｒ５１１を制御できる機能をＳＡＳ４１１に具備させると言う形で統合的に構成されている。融合機１０１のソフトウェアの根幹部分はＣ言語によるので、ＳＤＫアプリを制御する機能を同じくＣ言語によるＳＡＳ４１１に集中しておくのが好適なのである。

図６は、図１の融合機１０１におけるＯＳＧｉ（ＯｐｅｎＳｅｒｖｉｃｅＧａｔｅｗａｙｉｎｉｔｉａｔｉｖｅ）サービスプラットフォームについて説明するための図である。ＯＳＧｉサービスプラットフォームは、ＯＳＧｉアライアンスによる標準化技術であり、Ｊａｖａ（登録商標）言語に基づいたオープンなソフトウェア部品化技術である。ＯＳＧｉサービスプラットフォームが実装された機器では、Ｊａｖａ（登録商標）言語のソフトウェアは「バンドル」と言うソフトウェア部品の形で実装される。そして、該機器の諸機能はバンドルをもって構成する事ができると共に、該機器の諸機能のアップデートやカスタマイズやメンテナンスはバンドルのダウンロードをもって実現する事ができる。

図１の融合機１０１には、Ｊａｖａ（登録商標）言語のソフトウェアとして、ＪＳＤＫアプリ１４７と、ＪＳＤＫプラットフォーム１４８と、ＯＳＧｉ用のアプリケーションであるＯＳＧｉアプリ４０１と、ＯＳＧｉ用のサービスであるＯＳＧｉサービス４０２と、バンドルの管理（バンドルのライフサイクルやデータの管理等）を行うＯＳＧｉフレームワーク４０３が存在する。

図１の融合機１０１にはさらには、他機のＯＳＧｉサービスプラットフォームを自機のＯＳＧｉサービスプラットフォームと同様に処理するためのＣＳＣ（ＣｏｍｍｕｎｉｃａｔｉｏｎＳｅｒｖｉｃｅＣｏｎｃｉｅｒｇｅ）４２１と、Ｊａｖａ（登録商標）言語のソフトウェアを実行するためのＣＶＭ（ＣｏｍｐａｃｔＶｉｒｔｕａｌＭａｃｈｉｎｅ）５５５が存在する。

さて、ＯＳＧｉアプリ４０１とＪＳＤＫアプリ１４７に関して、ＯＳＧｉアプリ４０１はバンドル化された状態で融合機１０１に実装するものとするが、ＪＳＤＫアプリ１４７はバンドル化されていない状態で融合機１０１に実装するものとする。理由は、ＪＳＤＫアプリ１４７をバンドル化して実装する負担をＪＳＤＫアプリ１４７のベンダに課さないようにするためである。その代わり、ＪＳＤＫアプリ１４７をバンドル化する「ＢｕｎｄｌｅＡｃｔｉｖａｔｏｒ４０４」がＪＳＤＫプラットフォーム１４８に存在している。そして、ＯＳＧｉフレームワーク４０３は、バンドル化された状態で融合機１０１に実装されたバンドル（ＯＳＧｉアプリ４０１）の管理を行うと共に、バンドル化されていない状態で融合機１０１に実装されて「ＢｕｎｄｌｅＡｃｔｉｖａｔｏｒ４０４」によってバンドル化されるバンドル（ＪＳＤＫアプリ１４７）の管理を行う事になる。このようにして、ＯＳＧｉアプリ４０１用のアプリケーション管理機構とＪＳＤＫアプリ１４７用のアプリケーション管理機構は、ＯＳＧｉフレームワーク４０３とＢｕｎｄｌｅＡｃｔｉｖａｔｏｒ４０４を併設すると言う形で統合的に構成されているのである。これにより、Ｊａｖａ（登録商標）言語のアプリケーションの管理先の一元化が実現されている。

なお、ＯＳＧｉフレームワーク４０３は、当然の事ながら、ＯＳＧｉサービス４０２を構成するバンドルの管理や、ＪＳＤＫプラットフォーム１４８を構成するバンドルの管理も行う。Ｊａｖａ（登録商標）言語のソフトウェアの管理先の一元化が実現されていると言える。そして、ＯＳＧｉアプリ４０１はここではＳｅｒｖｌｅｔかＪＳＰであるものとする。そして、ＪＳＤＫアプリ１４７はここではＸｌｅｔであるものとする。

なお、ＪＳＤＫアプリ１４７についても、バンドル化された状態で実装するものとしてもよい。さらに、ＪＳＤＫアプリ１４７については、バンドル化された状態で実装してもバンドル化されていない状態で実装してもどちらでもよいものとしてもよい。バンドル化された状態で実装されるＪＳＤＫアプリ１４７については、ＢｕｎｄｌｅＡｃｔｉｖａｔｏｒ４０４によるバンドル化は不要である。

（ＪＳＤＫ）
図７は、図１のＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８のクラス図である。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は、全体で１プロセスとして、同一プロセス上で実行される。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８中の各ブロックは、それぞれこの１プロセス上のスレッドとして、スレッド単位で並列的に実行（マルチスレッド）される。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は、Ｊａｖａ（登録商標）コンパイラによりソースコードからバイトコードに一括翻訳されており、Ｊａｖａ（登録商標）仮想マシンにより逐次実行される。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は「Ｊａｖａ（登録商標）２ＭｉｃｒｏＥｄｉｔｉｏｎ」の「ＦｏｕｎｄａｔｉｏｎＰｒｏｆｉｌｅ」がベースとなっている。

ＪＳＤＫアプリ１４７としては、図に示す通り、ユーザアプリ５０１と、ＳＡＳＭａｎａｇｅｒ５１１と、ＳｃｒｅｅｎＭａｎａｇｅｒ５１２等が存在する。

ユーザアプリ５０１は、融合機１０１のユーザ（例えばベンダ）がＪＳＤＫを使用して開発したＪＳＤＫアプリ１４７である。ＳＡＳＭａｎａｇｅｒ５１１は、他のＪＳＤＫアプリ１４７（ユーザアプリ５０１等）の制御等を行うＪＳＤＫアプリ１４７である。ＳｃｒｅｅｎＭａｎａｇｅｒ５１２は、他のＪＳＤＫアプリ１４７（ユーザアプリ５０１等）を操作対象とする操作画面の表示等を行うＪＳＤＫアプリ１４７である。

ユーザアプリ５０１はここでは、スタンドアロンアプリケーションやアプレットと並ぶＪａｖａ（登録商標）アプリケーションの一種であるＸｌｅｔである。ＳＡＳＭａｎａｇｅｒ５１１とＳｃｒｅｅｎＭａｎａｇｅｒ５１２はここでは、独自の拡張を施したＸｌｅｔ（ＸｌｅｔＥｘ）である。

ＪＳＤＫプラットフォーム１４８には、図に示す通り、ＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１と、ＸｌｅｔＭａｎａｇｅｒ５３１と、ＭｕｌｔｉＸｌｅｔＭａｎａｇｅｒ５３２と、ＳｅｎｄＭａｎａｇｅｒ５４１と、ＥｖｅｎｔＭａｎａｇｅｒ５４２と、ＳｙｓｔｅｍＥｖｅｎｔＭａｎａｇｅｒ５４３と、ＰａｎｅｌＭａｎａｇｅｒ５４４と、ＩｎｓｔａｌｌＭａｎａｇｅｒ５４５と、Ｓｅｒｖｅｒ／ＣｌｉｅｎｔＭａｎａｇｅｒ５４６と、ＳｅｒｖｉｃｅＭａｎａｇｅｒ５４７等のクラスが存在する。

ＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１は、ＪＳＤＫシステムの実行環境を反映したＪＳＤＫシステムの起動環境設定を実行するクラスである。

ＸｌｅｔＭａｎａｇｅｒ５３１は、１対１でＸｌｅｔを管理するクラスである。ここでは、５個のＸｌｅｔのライフサイクルやデータがそれぞれ１対１で５個のＸｌｅｔＭａｎａｇｅｒ５３１によって管理される。ＭｕｌｔｉＸｌｅｔＭａｎａｇｅｒ５３２は、全てのＸｌｅｔＭａｎａｇｅｒ５３１を管理するクラスである。ここでは、５個のＸｌｅｔＭａｎａｇｅｒ５３１のライフサイクルやデータが全て１個のＭｕｌｔｉＸｌｅｔＭａｎａｇｅｒ５３２によって管理される。なお、ＳＡＳＭａｎａｇｅｒ５１１，ＳｃｒｅｅｎＭａｎａｇｅｒ５１２，ＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１，ＭｕｌｔｉＸｌｅｔＭａｎａｇｅｒ５３２，ＳｅｎｄＭａｎａｇｅｒ５４１，ＥｖｅｎｔＭａｎａｇｅｒ５４２，ＳｙｓｔｅｍＥｖｅｎｔＭａｎａｇｅｒ５４３，ＰａｎｅｌＭａｎａｇｅｒ５４４，ＩｎｓｔａｌｌＭａｎａｇｅｒ５４５，Ｓｅｒｖｅｒ／ＣｌｉｅｎｔＭａｎａｇｅｒ５４６，ＳｅｒｖｉｃｅＭａｎａｇｅｒ５４７等のクラスのバンドルのライフサイクルやデータは、ＯＳＧｉフレームワーク４０３によって管理される。

ＳｙｓｔｅｍＥｖｅｎｔＭａｎａｇｅｒ５４３は、図１のプラットフォーム１３２からのシステムイベント（電力モード等）の管理を行うクラスである。ＰａｎｅｌＭａｎａｇｅｒ５４４は、１個のＸｌｅｔが図２のオペレーションパネル２０２の画面を占有する際の調停を行うクラスである。ＩｎｓｔａｌｌＭａｎａｇｅｒ５４５は、ＳＤｃａｒｄやＷｅｂからのインストールやアンインストールの管理を行うクラスである。ＳｅｒｖｉｃｅＭａｎａｇｅｒ５４７は、Ｘｌｅｔからのサービス要求に応じてＸｌｅｔへのサービス提供を行うクラスである。

図７のＪＳＤＫシステムでは、ＡＰＩとして、ＪＳＤＫＡＰＩ５５１とＪＳＤＫＡＰＩ５５２が利用される。なお、ＸｌｅｔとＸｌｅｔＥｘの差異として、ＸｌｅｔＥｘは、オブジェクトにアクセスするのにＪＳＤＫＡＰＩ５５１の利用とＪＳＤＫプラットフォーム１４８へのアクセスが可能である点が挙げられる。図１の融合機１０１にはさらに、図７のＪＳＤＫシステムに係る要素として、Ｃ言語とＪａｖａ（登録商標）言語のインタフェースとなるＪＳＤＫＳｅｓｓｉｏｎ５５３とＮａｔｉｖｅＪＳＤＫＳｅｓｓｉｏｎ５５４や、ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８を実行するためＪａｖａ（登録商標）仮想マシンであるＣＶＭ５５５が存在する。

図８は、ＪＳＤＫシステムの起動処理を説明するための図である。ＪＳＤＫシステムの起動処理では先ず、ＯＳＧｉフレームワーク４０３が、ＯＳＧｉアプリ４０１やＯＳＧｉサービス４０２を構成するバンドルを生成（Ｓ１）する。次に、ＯＳＧｉフレームワーク４０３が、ＪＳＤＫアプリ１４７やＪＳＤＫプラットフォーム１４８を構成するバンドルを生成（Ｓ２）する。次に、ＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１が、ＪＳＤＫＳｅｓｓｉｏｎ５５３やＮａｔｉｖｅＪＳＤＫＳｅｓｓｉｏｎ５５４を生成するなど、ＪＳＤＫシステムの実行環境を反映したＪＳＤＫシステムの起動環境設定を実行（Ｓ３）する。次に、ＪＳＤＫＳｅｓｓｉｏｎ５５３が、ＳｅｎｄＭａｎａｇｅｒ５４１やＥｖｅｎｔＭａｎａｇｅｒ５４２を生成（Ｓ４）する。なお、ユーザアプリ５０１の起動処理には、ＳＡＳ４１１やＳＡＳＭａｎａｇｅｒ５１１が関与（Ｓ５）する。

以下、ＳｅｒｖｉｃｅＭａｎａｇｅｒ５４７について詳細に説明する。文中、ＳｅｒｖｉｃｅＭａｎａｇｅｒ５４７についてはＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１、ＪＳＤＫＡＰＩ５５１についてはＦｕｎｃｔｉｏｎＡＰＩ６１１、ＪＳＤＫＡＰＩ５５２についてはＣ／ＪＡＰＩ６２１と表記する。なお、ＡＰＩは、アプリケーションプログラムインタフェースの略語に相当する。

１）ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ
図９は、図７のＪＳＤＫシステムを構成するＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１について説明するためのクラス図である。ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１は、ユーザアプリ５０１からのサービス要求に応じてユーザアプリ５０１へのサービス提供を行うクラスである。サービス内容の具体例としては、コピー処理の実行制御に関するサービス、プリント処理の実行制御に関するサービス、スキャン処理の実行制御に関するサービス、ファックス処理の実行制御に関するサービスが挙げられる。図７のＪＳＤＫシステムには、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、ＦｕｎｃｔｉｏｎＡＰＩ６１１が存在する。

ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１は、ユーザアプリ５０１からのサービス要求を調停する機能を備える。ユーザアプリ５０１からのサービス要求が競合する場合があるからである。ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１は、図９に示す通り、一のユーザアプリ５０１からのサービス要求と他のユーザアプリ５０１からのサービス要求とが競合する際には、一方のサービス要求を優先させて他方のサービス要求を劣後させる等、一方のサービス要求と他方のサービス要求とを調停する事になる。

ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１には、ＡｄａｐｔｉｖｅＦｕｎｃｔｉｏｎ７０１や、ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２等のクラスが存在する。さらに、ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２には、ＣｏｐｙＳｅｒｖｉｃｅ７１１や、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２や、ＳｃａｎＳｅｒｖｉｃｅ７１３や、ＦａｘＳｅｒｖｉｃｅ７１４や、ＳＡＳＳｅｒｖｉｃｅ７２１等のクラスが存在する。

ＡｄａｐｔｉｖｅＦｕｎｃｔｉｏｎ７０１は、ユーザアプリ５０１等からのサービス要求を受け付けるクラスである。ＡｄａｐｔｉｖｅＦｕｎｃｔｉｏｎ７０１は、ユーザアプリ５０１等からのサービス要求を処理する動的に変更可能な種々の関数を備える。ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２は、ユーザアプリ５０１等へのサービス提供を執り行うクラスである。ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２は、自己の振る舞いを動的に変更する機能を備える。なお、プログラムの振る舞いの取り扱いに関する具体例は例えば、特願２００４−０６２４１３に開示されている。

ＣｏｐｙＳｅｒｖｉｃｅ７１１は、コピー処理の実行制御に関するサービス提供等を執り行うクラスである。ＰｒｉｎｔＳｅｒｖｉｃｅ７１２は、プリント処理の実行制御に関するサービス提供等を執り行うクラスである。ＳｃａｎＳｅｒｖｉｃｅ７１３は、スキャン処理の実行制御に関するサービス提供等を執り行うクラスである。ＦａｘＳｅｒｖｉｃｅ７１４は、ファックス処理の実行制御に関するサービス提供等を執り行うクラスである。

ＳＡＳＳｅｒｖｉｃｅ７２１は、ユーザアプリ５０１の動作態様を制御するクラスである。ＳＡＳＳｅｒｖｉｃｅ７２１は、ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２の振る舞いの動的な変更に応じて所定のユーザアプリ５０１の動作態様を変更する。なお、ＳＡＳＳｅｒｖｉｃｅ７２１は、ＳＡＳＭａｎａｇｅｒ５１１を制御する事でユーザアプリ５０１の動作態様を制御する事ができる。

なお、ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８はリフレクション型のアーキテクチャで実装されている。リフレクションとは、プログラムが自己の静的な構造や動的な振る舞いに関する情報を公開したり、自己の静的な構造や動的な振る舞いを変更したりする能力を意味する。リフレクション型のアーキテクチャは、ベースレベルとメタレベルからなる。図７のＪＳＤＫシステムでは、ＪＳＤＫアプリ１４７がベースレベルに相当し、ＪＳＤＫプラットフォーム１４８がメタレベルに相当する。

図１０は、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の動作について説明するための図である。図１０は、図９のクラス図に対応するコラボレーション図に相当する。

ユーザアプリ５０１がＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にサービスを要求する際には先ず、ユーザアプリ５０１からＦｕｎｃｔｉｏｎＡＰＩ６１１に、当該サービスを要求する旨のサービス要求が送信（Ｓ１１）される。次に、ＦｕｎｃｔｉｏｎＡＰＩ６１１からＡｄａｐｔｉｖｅＦｕｎｃｔｉｏｎ７０１に、当該サービスを要求する旨の当該サービス要求が送信（Ｓ１２）される。次に、ＡｄａｐｔｉｖｅＦｕｎｃｔｉｏｎ７０１からＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２に、当該サービスを要求する旨の当該サービス要求が状態遷移のイベント形式で送信（Ｓ１３）される。次に、ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２からプラットフォーム１３２に、当該サービスに関する情報処理，通信処理，画像形成処理等の種々の処理を要求する旨の処理要求が状態遷移のアクション形式で送信（Ｓ１４）される。

続いて次に、プラットフォーム１３２からＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２に、当該処理要求に関する処理結果が状態遷移のイベント形式で送信（Ｓ２１）される。次に、ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２からＡｄａｐｔｉｖｅＦｕｎｃｔｉｏｎ７０１に、上記のサービス要求に関するサービス結果が状態遷移のアクション形式で送信（Ｓ２２）される。次に、ＡｄａｐｔｉｖｅＦｕｎｃｔｉｏｎ７０１からＦｕｎｃｔｉｏｎＡＰＩ６１１に、上記のサービス要求に関する上記のサービス結果が送信（Ｓ２３）される。次に、ＦｕｎｃｔｉｏｎＡＰＩ６１１からユーザアプリ５０１に、上記のサービス要求に関する上記のサービス結果が送信（Ｓ２４）される。

さて、プラットフォーム１３２が情報処理，通信処理，画像形成処理等の上記の処理を実行する際に上記の処理を実行する上での不都合や不具合が存在する場合には、プラットフォーム１３２からＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１に、不都合や不具合が存在する旨の通知が送信（Ｓ３１）される。次に、ＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１からＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２に、自己の振る舞いを動的に変更する旨の命令が送信（Ｓ３２）される。次に、ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２が、自己の振る舞いを動的に変更（Ｓ３３）して更に、ＡｄａｐｔｉｖｅＦｕｎｃｔｉｏｎ７０１の種々の関数の動作を動的に変更（Ｓ３４）する。次に、ＳＡＳＳｅｒｖｉｃｅ７２１が、ＳＡＳＭａｎａｇｅｒ５１１を通じて所定のユーザアプリ５０１の動作態様を変更（Ｓ３５，Ｓ３６）する。

図１１は、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の動作の具体例について説明するための図である。図１１のコラボレーション図は、図１０のコラボレーション図の具体例に該当する。

先ず、第３のユーザアプリ５０１からＦａｘＳｅｒｖｉｃｅ７１４に、ファックス送信処理の実行制御に係るサービス要求が送信（Ｓ４１）される。次に、ＦａｘＳｅｒｖｉｃｅ７１４からプラットフォーム１３２に、ファックス送信処理に係る処理要求が送信（Ｓ４２）される。続いて次に、第１のユーザアプリ５０１からＰｒｉｎｔＳｅｒｖｉｃｅ７１２に、プリント処理の実行制御に係るサービス要求が送信（Ｓ４３）される。次に、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２からプラットフォーム１３２に、プリント処理に係る処理要求が送信（Ｓ４４）される。

次に、プラットフォーム１３２からＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１に、ファックス送信処理とプリント処理を同時に実行するためのメモリが不足している旨が通知（Ｓ５１）される。次に、ＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１は、ファックス送信処理の実行中はプリント処理の処理要求を発行しないようＰｒｉｎｔＳｅｒｖｉｃｅ７１２の振る舞いを動的に変更（Ｓ５２）する。

次に、プラットフォーム１３２からＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１に、プリント処理を停止してもファックス送信処理を実行するためのメモリがいまだ不足している旨が通知（Ｓ６１）される。次に、ＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１は、ファックス送信処理の実行中はファックス送信処理の要求元のユーザアプリ５０１を除く全てのユーザアプリ５０１を停止するようＳＡＳＳｅｒｖｉｃｅ７２１の振る舞いを動的に変更（Ｓ６２）する。次に、ＳＡＳＳｅｒｖｉｃｅ７２１は、ファックス送信処理の実行中はファックス送信処理の要求元のユーザアプリ５０１を除く全てのユーザアプリ５０１を停止（Ｓ６３，Ｓ６４）する。

図１２は、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の振る舞い変更処理について概念的に説明するための図である。

ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にて、ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２には、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１、ＭｏｄｉｆｙＡｇｅｎｔ７３２等のクラスが存在する。

ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１は、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２やＦａｘＳｅｒｖｉｃｅ７１４の状態遷移モデルの管理を執り行う。ＭｏｄｉｆｙＡｇｅｎｔ７３２は、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２やＦａｘＳｅｒｖｉｃｅ７１４の状態遷移モデルの修正を執り行う。状態遷移モデルの管理・修正は、ＣｏｐｙＳｅｒｖｉｃｅ７１１やＳｃａｎＳｅｒｖｉｃｅ７１３も実施対象となる。

ＰｒｉｎｔＳｅｒｖｉｃｅ７１２の状態遷移モデルについて説明しておく。Ｉｄｌｅ状態７４１は、プリント処理の待機中の状態である。Ｐｒｉｎｔ状態７４２は、プリント処理を実行中の状態である。Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２は、印刷開始イベント７４３により遷移する。Ｐｒｉｎｔ状態７４２からＩｄｌｅ状態７４１は、印刷終了イベント７４４により遷移する。

ＦａｘＳｅｒｖｉｃｅ７１４の状態遷移モデルについて説明しておく。Ｉｄｌｅ状態７５１は、ファックス送信処理の待機中の状態である。ＦａｘＳｅｎｄ状態７５２は、ファックス送信処理を実行中の状態である。Ｉｄｌｅ状態７５１からＦａｘＳｅｎｄ状態７５２には、送信開始イベント７５３により遷移する。ＦａｘＳｅｎｄ状態７５２からＩｄｌｅ状態７５１には、送信終了イベント７５４により遷移する。

ＭｏｄｉｆｙＡｇｅｎｔ７３２は、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１が管理する状態遷移モデルに状態遷移の実行条件を付加する事で、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１が管理する状態遷移モデルを修正する事ができる。これによって、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２やＦａｘＳｅｒｖｉｃｅ７１４の振る舞いが動的に変更される事になる。

図１２にて、図１２Ａは振る舞い変更前の状態遷移モデルを表し、図１２Ｂは振る舞い変更後の状態遷移モデルを表す。ＰｒｉｎｔＳｅｒｖｉｃｅ７１２に関して、図１２ＡではＩｄｌｅ状態７４１からＰｒｉｎｔ状態７４２に遷移するのに制限条件は存在しないが、図１２ＢではＩｄｌｅ状態７４１からＰｒｉｎｔ状態７４２に遷移するのに制限条件が存在する。当該制限条件（ガード条件）は、ＦａｘＳｅｒｖｉｃｅ７１４がＩｄｌｅ状態７５１の際に限りＰｒｉｎｔＳｅｒｖｉｃｅ７１２の状態遷移を許容する事を意味する。当該制限条件（ガード条件）による振る舞い変更処理が、図１１のＳ５１・Ｓ５２による振る舞い変更処理に匹敵する。

ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１は、アスペクト指向プログラムに相当する。アスペクト指向とは、システム横断的な関心事の分離メカニズムを意味する。アスペクト指向では、アスペクト指向プログラムにアスペクトを織り込む事で、アスペクト指向プログラムの状態遷移モデルに状態遷移の実行条件を付加する事ができる。これによって、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１が管理する状態遷移モデルに状態遷移の実行条件を付加する。なお、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１は、振る舞いと部品が分離されて設計されており、ＭｏｄｉｆｙＡｇｅｎｔ７３２からＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１に、状態遷移モデルと部品ライブラリが登録される。これによって、アスペクト指向によるアスペクトの織り込みが実現されている。

ＸＭＩ言語によるＸＭＬ文書（図９，図１０，図１１）について説明しておく。図１０に示す通り、ＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１とＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１では、ＸＭＩ言語を記述言語とするＸＭＬ文書であるＡｓｐｅｃｔＳＭ．ｘｍｌファイル（以下、単に「ＡｓｐｅｃｔＳＭ」という。）の記述内容に従って、それぞれＳ３２の処理とＳ３３の処理を実行する。図１１で言えば、ＡｓｐｅｃｔＳＭにはメモリが不足している際にはＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の振る舞いを動的に変更する旨が記述されている。なお、ＸＭＬは「ｅＸｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ」の略語に相当する。また、ＸＭＩは「ＸＭＬＭｅｔａｄａｔａＩｎｔｅｒｃｈａｎｇｅ」の略語に相当する。

以上の説明のように、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１は、自己の振る舞いを動的に変更する事ができる。これにより、ＪＤＳＫアプリ１４７の多様な変化にＪＳＤＫプラットフォーム１４８が適切に対応する事ができるのである。更に、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１は、自己の振る舞いの動的な変更に応じてユーザアプリ５０１の動作態様を変更する事ができる。これにより、ＪＤＳＫアプリ１４７の多様な変化にＪＳＤＫプラットフォーム１４８が、ＪＳＤＫプラットフォーム１４８の制御と更にＪＤＳＫアプリ１４７の制御を基に適切に対応する事ができるのである。

図１２において概念的に説明した内容を更に具体的に説明する。図１２に示されるモジュール構成は、図１３に示されるクラス図に基づいている。図１３は、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅの振る舞いの動的な変更を実現するクラス群を説明するためのクラス図である。

図１３において、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌクラス１０００は、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１を表現するクラスである。すなわち、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１は、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌクラス１０００のインスタンスである。

ＳｔａｔｅＭａｃｈｉｎｅクラス１００１は、ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２における各サービス（ＣｏｐｙＳｅｒｖｉｃｅ７１１、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２、ＳｃａｎＳｅｒｖｉｃｅ７１３、及びＦａｘＳｅｒｖｉｃｅ７１４等）を表現するクラスである。すなわち、ＣｏｐｙＳｅｒｖｉｃｅ７１１、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２、ＳｃａｎＳｅｒｖｉｃｅ７１３、及びＦａｘＳｅｒｖｉｃｅ７１４等は、それぞれＳａｔｅＭａｃｈｉｎｅクラス１００１のインスタンス（ＳｔａｔｅＭａｃｈｉｎｅオブジェクト）として生成される。したがって、以後、これらのサービスを総称する場合、「ステートマシン」という。

ＳｔａｔｅＶｅｒｔｅｘクラス１００２は、抽象クラスであり、各ステートマシンの状態遷移モデルにおいて状態を表現するクラスのルートクラスに相当する。ＳｔａｔｅＶｅｒｔｅｘクラス１００２には、ｃｏｎｎｅｃｔメソッド１００２ａや、ｒｅｃｏｎｎｅｃｔメソッド１００２ｂ等のメソッドが定義されている。ｃｏｎｎｅｃｔメソッド１００２ａは、遷移先の状態及びその状態遷移との接続を実行するメソッドである。状態遷移についてはＴｒａｎｓｉｔクラス１００３によって表現される。したがって、より具体的には、ｃｏｎｎｅｃｔメソッド１００２ａは、当該メソッドが呼び出されたオブジェクトと、当該オブジェクトの遷移先のＳｔａｔｅＶｅｒｔｅｘオブジェクト（厳密にはそのサブクラスのオブジェクト。以下、総称する場合「状態オブジェクト」という。）及びその状態遷移に対応するＴｒａｎｓｉｔオブジェクト（以下、「遷移オブジェクト」という。）との接続を実行するクラスである。ここでいう接続は、例えば、状態オブジェクト内に、遷移先の状態オブジェクトや、その遷移オブジェクトの識別情報（ＩＤ、参照、又はポインタ等）を保持することで実現される。ｒｅｃｏｎｎｅｃｔメソッド１００２ｂは、遷移先の変更を実行するメソッドである。なお、Ｔｒａｓｉｔクラス１００３には、インタフェースとしてＥｖｅｎｔインタフェース１００３ａ、Ｇｕｒａｄインタフェース１００３ｂ、及びＡｃｔｉｏｎインタフェース１００３ｃ等が定義されている。Ｅｖｅｎｔインタフェース１００３ａは、状態遷移の遷移イベントを実装するためのインタフェースである。Ｇｕａｒｄインタフェース１００３ｂは、ガード条件を実装するためのインタフェースである。Ａｃｔｉｏｎインタフェース１００３ｃは、状態遷移時に実行するアクションを実装するためのインタフェースである。

ＳｔａｔｅＶｅｒｔｅｘクラス１００２のサブクラスとしては、Ｓｔａｔｅクラス１００４及びＰｓｅｕｄｏＳｔａｔｅクラス１００５が定義されている。Ｓｔａｔｅクラス１００４は、例えば、ステートマシンの状態を表現するクラスである。Ｓｔａｔｅクラス１００４には、インタフェースとしてＩＳｔａｔｅインタフェース１００４ａ及びＡｃｔｉｖｉｔｙインタフェース１００４ｂ等が定義されている。ＩＳｔａｔｅインタフェース１００４ａは、状態の入場時の処理（入場処理）及び退場時の処理（退場処理）を実装するためのインタフェースである。Ａｃｔｉｖｉｔｙインタフェース１００４ｂは、状態にある間実行する処理を実装するためのインタフェースである。これらのインタフェースは、クラスとして実装される。したがって、例えば、Ａｃｔｉｖｉｔｙインタフェース１００４ｂの処理は、Ａｃｔｉｖｉｔｙクラスに実装される。

ＰｓｅｕｄｏＳａｔｅクラス１００５は、初期状態や終期状態等、その名の通り擬似的な状態を表現するクラスであり、そのサブクラスとしては初期状態を表現するＩｎｉｔｉａｌＳｔａｔｅクラス１００６及び終期状態を表現するＦｉｎａｌＳｔａｔｅクラス１００７等がある。但し、図１２の状態遷移モデルでは、初期状態及び終期状態は便宜上省略されている。

ＭｏｄｉｆｙＡｇｅｎｔクラス１００９は、ＭｏｄｉｆｙＡｇｅｎｔ７３２を表現するクラスである。すなわち、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、ＭｏｄｉｆｙＡｇｅｎｔクラス１００９のインスタンスである。ＰｌｕｇｉｎＡｇｅｔｎｔクラス１００８については後述する。

上記クラス間の関係について説明する。ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌクラス１０００は、ＳｔａｔｅＭａｃｈｉｎｅクラス１００１を集約する。これは、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１が、一つ以上のステートマシンのそれぞれの状態遷移モデルを管理することを表現したものである。

ＳｔａｔｅＭａｃｈｉｎｅクラス１００１は、ＳｔａｔｅＶｅｒｔｅｘクラス１００２を集約する。これは、一つのステートマシンは、一つ以上の状態を有することを表現したものである。ＳｔａｔｅＶｅｒｔｅｘクラス１００２は、Ｔｒａｎｓｉｔクラスを集約する。これは、状態と状態との間は遷移によって接続されることを表現したものである。

以上のような、モデルに基づいて、例えば、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２は、以下のようなオブジェクトによって構成される。

図１４は、ＰｒｉｎｔＳｅｒｖｉｃｅのオブジェクト構成を表す図である。ＰｒｉｎｔＳｅｒｖｉｃｅ７１２は、図１２の状態遷移モデルに基づいて、Ｉｄｌｅ状態オブジェクト７４１Ｓ、Ｐｒｉｎｔ状態オブジェクト７４２Ｓ、印刷開始オブジェクト７４３Ｔ、プ及び印刷終了オブジェクト７４４Ｔ等より構成される。Ｉｄｌｅ状態オブジェクト７４１Ｓ及びＰｒｉｎｔ状態オブジェクト７４２Ｓは、Ｓｔａｔｅクラス１００４のインスタンスである。印刷開始オブジェクト７４３Ｔ及び印刷終了オブジェクト７４４Ｔは、Ｔｒａｎｓｉｔクラス１００３のインスタンスである。

図１４においてオブジェクト同士を連結する線分は、オブジェクト同士の参照関係を表す。遷移元の状態オブジェクトは遷移先の状態オブジェクトを参照している。なお、図中では状態オブジェクト間に遷移オブジェクトが接続されている。例えば、Ｉｄｌｅ状態オブジェクト７４１ＳとＰｒｉｎｔ状態オブジェクト７４２Ｓとの間には印刷開始オブジェクト７４３Ｔが接続されている。しかし、このことはＩｄｌｅ状態７０３が、Ｐｒｉｎｔ状態オブジェクト７４２Ｓを参照していないことを示すものではない。Ｉｄｌｅ状態オブジェクト７４１Ｓは、Ｐｒｉｎｔ状態オブジェクト７４２Ｓを参照すると共に、その状態遷移に対応する遷移オブジェクトとして印刷開始オブジェクト７４３Ｔをも参照することを表現したものである。

オブジェクトの状態は、サービスの授受を行う「アクティブ状態」とサービスの授受を行わない「非アクティブ状態」に分類される。ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１におけるステートマシンの振る舞い変更を当該ステートマシンの動作中に実行するには、当該ステートマシンの更新部分のオブジェクトがアクティブ状態ではないとき（非アクティブ状態のとき）に実行すればよい。当該ステートマシンの動作中のオブジェクト同士のサービスの授受が更新処理により阻害されずに済むからである。よって、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の更新処理をＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の更新部分のオブジェクトがアクティブ状態ではないときに実行するのである。なお、状態遷移図によるモデリングでは、一のオブジェクトがアクティブ状態のときは他のオブジェクトは非アクティブ状態に限定される。すなわち、各オブジェクトは互いに排他的に処理を実行する（動作する）。

図１４に示されるＰｒｉｎｔＳｅｒｖｉｃｅ７１２のオブジェクト構成が構築される過程について説明する。

図１５は、ＰｒｉｎｔＳｅｒｖｉｃｅのオブジェクト構成の構築処理を説明するためのシーケンス図である。図１５の処理は、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２がＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１によってインスタンス化される際に実行される。

ＰｒｉｎｔＳｅｒｖｉｃｅ７１２は、インスタンス化されると、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２の状態遷移情報に基づいて、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２の状態遷移モデルに対応したオブジェクト構成を構築する（Ｓ４０１）。状態遷移情報は、例えば、融合機１０１の所定の記憶装置内に、以下の形式で保存されている。

図１６及び図１７は、ＰｒｉｎｔＳｅｒｖｉｃｅの状態遷移情報の定義例を示す図である。図１６及び図１７によって一つの状態遷移情報９００の記述例が示されている。状態遷移情報９００は、ＸＭＩ（XML Metadata Interchange）に従った記述例が示されている。ＸＭＩは、モデルを各種のソフトウェアの間でＸＭＬ文書によって交換することを目的とした標準規格である。但し、本実施の形態を実施するにあたり、状態遷移情報は、必ずしもＸＭＩに従って記述される必要はない。なお、図中における行番号は、説明の便宜上付加したものである。

状態遷移情報９００の１行目における＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグのタグ名、及びそのｎａｍｅ属性の値（「Ｐｒｉｎｔ」）によって、状態遷移情報９００は、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２に対応するものであることが定義されている。また、当該＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグにおけるｘｍｉ．ｉｄ属性の値（「００３」）は、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２を識別するためのＩＤである。

３行目の＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグは、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２における状態の定義の開始の宣言に相当する。当該宣言は、＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグのｘｍｉ．ｉｄの値（「００４」）によって識別される。

５行目から１５行目におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０は、Ｉｄｌｅ状態７４１に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０のｎａｍｅ属性の値には「Ｉｄｌｅ」が設定され、ｘｍｉ．ｉｄ要素の値には、「００５」が設定されている。

１６行目から２６行目（図１７）におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０は、Ｐｒｉｎｔ状態７４２に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０のｎａｍｅ属性の値には「Ｐｒｉｎｔ」が設定され、ｘｍｉ．ｉｄ要素の値には、「００８」が設定されている。

また、３４行目から６４行目には、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２における各状態遷移が定義されている。すなわち、３４行目から５０行目におけるＴｒａｎｓｉｔｉｏｎ要素９３０は、Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素９３０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ要素９３０の子要素として定義されている、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９３１及びＴｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９３２より特定される。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９３１は遷移元の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９３１の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００５」である。したがって、遷移元は、ｘｍｉ．ｉｄ属性の値が「００５」の状態、すなわち、Ｉｄｌｅ状態７４１であることが分かる。また、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９３２は遷移先の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９３２の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００８」である。したがって、遷移先は、ｘｍｉ．ｉｄの値が「００８」の状態、すなわち、Ｐｒｉｎｔ状態７４２であることが分かる。なお、Ｔｒａｎｓｉｔｉｏｎ要素９３０のｎａｍｅ属性の値は「印刷開始」であり、ｘｍｉ．ｉｄ属性の値は「００６」である。

５１行目から６４行目におけるＴｒａｎｓｉｔｉｏｎ要素９４０は、Ｐｒｉｎｔ状態７４２からＩｄｌｅ状態７４１への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素９４０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９４１内のｘｍｉ．ｉｄｒｅｆ属性の値が「００８」（Ｐｒｉｎｔ状態７４２）であり、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９４２内のｘｍｉ．ｉｄｒｅｆ属性の値が「００５」（Ｉｄｌｅ状態７４１）であることから特定される。なお、Ｔｒａｎｓｉｔｉｏｎ要素９４０のｎａｍｅ属性の値は「印刷終了」であり、ｘｍｉ．ｉｄ属性の値は「００７」である。

５行目以降の説明に戻る。各状態に対応する、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０及びＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０は、ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素及びＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素の少なくともいずれか一方を子要素として有する。ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素は、遷移元からの状態遷移に対する接続が定義される要素である。ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素は、遷移先への状態遷移に対する接続が定義される要素である。

例えば、Ｉｄｌｅ状態７４１に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０おけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素９１１においてその子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００６」であり、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素９１２において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００７」である。したがって、Ｐｒｉｎｔ状態７４２からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９３０が対応する状態遷移に相当し、遷移元の状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９４０が対応する状態遷移に相当することが分かる。

また、Ｐｒｉｎｔ状態７４２に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０おけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素９２１においてその子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００７」であり、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素９２２において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「００６」である。したがって、Ｐｒｉｎｔ状態７４２からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９４０が対応する状態遷移に相当し、遷移元の状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９３０が対応する状態遷移に相当することが分かる。

上記のような状態遷移情報９００に基づいて、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２は、まず、各状態オブジェクト及び遷移オブジェクト等をインスタンス化する。図中では、状態遷移情報９００におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９１０、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０、Ｔｒａｎｓｉｔｉｏｎ要素９３０、及びＴｒａｎｓｉｔｉｏｎ要素９４０のそれぞれに基づいて、Ｉｄｌｅ状態オブジェクト７４１Ｓ、Ｐｒｉｎｔ状態オブジェクト７４２Ｓ、印刷開始オブジェクト７４３Ｔ、及び印刷終了オブジェクト７４４Ｔが生成されている例が示されている（Ｓ４０２〜Ｓ４０５）。

続いて、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２は、各状態オブジェクトの参照関係が状態遷移情報９００に定義された状態遷移の順になるよう、遷移元の状態オブジェクトに対して遷移先の状態オブジェクトを接続する。例えば、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２は、Ｐｒｉｎｔ状態オブジェクト７４２Ｓの識別情報と印刷開始オブジェクト７４３Ｔの識別情報とを引数として、Ｉｄｌｅ状態オブジェクト７４１Ｓのｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ４０６）。また、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２は、Ｉｄｌｅオブジェクト７４１Ｓの識別情報と印刷終了オブジェクト７４４Ｔの識別情報とを引数として、Ｐｒｉｎｔ状態オブジェクト７４２Ｓのｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ４０７）。ｃｏｎｎｅｃｔ（）メソッドを呼び出された各状態オブジェクトは、当該状態オブジェクト内において引数に指定された識別情報を保持する。

このように、ｃｏｎｎｅｃｔ（）メソッドの引数に、状態オブジェクトと遷移オブジェクトとのそれぞれの識別情報が指定された場合、当該メソッドが呼び出された状態オブジェクトは、その状態オブジェクトの識別情報と遷移オブジェクトの識別情報とを関連付けて（ペアで）保持する。これによって、ある状態オブジェクトがアクティブのときに、あるイベントが発生したときの遷移先の状態オブジェクトが特定され得る。

以上の処理によって、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２について、図１４に示されるようなオブジェクト構成が構築される。

上記をふまえて、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２の振る舞い変更処理を具体的に説明する。図１８及び図１９は、ＰｒｉｎｔＳｅｒｖｉｃｅの振る舞い変更処理を説明するためのシーケンス図である。

プラットフォーム１３２からＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１に、例えば、不都合や不具合の発生等を示すイベントが送信される（Ｓ４２１）。ここでは、メモリが不足していることを示すイベントが通知されたこととする。但し、ここで通知されるイベントは不具合や不都合に限定されず、例えば、機器の状態の変化も含まれ得る。機器の状態の変化としては、静的な情報（機種名、機種のスペック、周辺機器情報）の変化と動的な情報（使用可能メモリ、周辺機器の状態、ユーザ操作）の変化とがある。静的な情報の変化は確定した時にＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ５２１に通知され、動的な情報は変化が発生した時に随時通知される。ＪＳＤＫＥｎｖｉｒｏｎｍｎｅｔ５２１は、プラットフォーム１３２からのイベントに応じた振る舞い修正指示がＡｓｐｅｃｔＳＭに記載されているか確認する。

図２０は、ＰｒｉｎｔＳｅｒｖｉｃｅの振る舞いの変更内容が記述されたＡｓｐｅｃｔＳＭの記述例を示す図である。ＡｓｐｅｃｔＳＭ８１０には、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２の状態遷移情報９００（図１６及び図１７）に対する変更内容が記述されている。

ＡｓｐｅｃｔＳＭ８１０において、１行目から６行目までの＜Ｅｖｅｎｔ＞タグで囲まれたＥｖｅｎｔ要素８１１のｎａｍｅ属性、ｔｙｐｅ属性、ｖａｌｕｅ属性のそれぞれには、振る舞いを変更するトリガとなるイベント名、条件、閾値が記述される。また、Ｅｖｅｎｔ要素８１１の子要素（ｍｏｄｉｆｙ．ＳｔａｔｅＭａｃｈｉｎｅ要素）には、振る舞いの変更対象となるステートマシンが記述される。図２０の例では、空きメモリが１０ＭＢを下回ったことを示すイベントを受信した場合にＰｒｉｎｔ（ＰｒｉｎｔＳｅｒｖｉｃｅ７１２）に対して振る舞いを変更することが記述されている。

７行目から１５行目までのａｓｐｅｃｔ要素８１２のＸＭＩ．ＳｔａｔｅＭａｃｈｉｎｅ属性には、変更するステートマシン名（Ｐｒｉｎｔ）が記述される。また、ｐｏｉｎｔｃｕｔ．Ｔｒａｎｓｍｉｓｓｉｏｎ要素８１３のｎａｍｅ属性には、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２において変更対象となる状態遷移の名前が記述され、ｔｉｍｅｎｇ属性にはＡｓｐｅｃｔＳＭ８１０による変更処理を実行するタイミングが記述される。図２０の例では、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２の状態遷移において、Ｉｄｌｅ状態７４１のときに振る舞い変更処理を実行することが記述されている。ａｄｖｉｃｅ．Ｇａｕｒｄ要素には、変更の内容が記述される。すなわち、＜ａｄｖｉｃｅ．Ｇｕａｒｄ＞タグのタグ名におけるａｄｖｉｃｅ．以降によって、変更の対象がＧｕａｒｄ（ガード条件）であることが記述されている。また、ｔｙｐｅ属性によって、変更の種別が「ｉｎｓｅｒｔ」（挿入）であることが記述されている。すなわち、変更内容はガード条件を挿入することであることが記述されている。１０行目から１２行目までは、実際に状態遷移情報９００に挿入される定義である。すなわち、ＡｓｐｅｃｔＳＭ８１０では、「Ｉｄｌｅ状態７４１のときにＰｒｉｎｔＳｅｒｖｉｃｅ７１２の印刷開始イベント７４３に基づく状態遷移に対してガード条件（ＦａｘＳｅｒｖｉｃｅ７１４がＩｄｌｅ状態であること）を付加すること」が定義されている。

なお、各イベントに応じたＡｓｐｅｃｔＳＭは、予め融合機１０１のＨＤＤ２３３又はメモリカード２３５等に保存されている。

したがって、ステップＳ４２１において通知されたイベントが、空きメモリが１０ＭＢを下回ったことを示すものであった場合、ＪＳＤＫＥｎｖｉｒｏｎｍｎｅｔ５２１は、図２０のＡｓｐｅｃｔＳＭ８１０に基づいて、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２の振る舞いを変更する必要があることを判断し、ＭｏｄｉｆｙＡｇｅｎｔ７３２にＰｒｉｎｔＳｅｒｖｉｃｅ７１２の振る舞い変更情報を添付して振る舞い変更要求を発行する（Ｓ４２２）。ここで、「振る舞い変更情報」とは、ＡｓｐｅｃｔＳＭ８１０より、振る舞いの変更に必要な情報のみが抽出されたものでもよいし、ＡｓｐｅｃｔＳＭ８１０そのものでもよい。

ＭｏｄｉｆｙＡｇｅｎｔ７３２は、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２に対する振る舞い変更要求を受け、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１に対して、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２の状態遷移情報９００の取得要求を発行する（Ｓ４２３）。ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１は、状態遷移情報９００の取得要求に対して、当該状態遷移情報が登録されていれば状態遷移情報９００をＭｏｄｉｆｙＡｇｅｎｔ７３２に提供する（Ｓ４２４）。

ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１から状態遷移情報９００を取得できた場合、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２の状態遷移情報９００に対する振る舞い変更処理の可否を判断する（Ｓ４２５ａ）。一方、状態遷移情報９００を取得できなかった場合、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１にＰｒｉｎｔＳｅｒｖｉｃｅ７１２は登録されていないことを実装してないことをＪＳＤＫＥｎｖｉｒｏｎｍｎｅｔ５２１に通知する（Ｓ４２５ｂ）。

ステップＳ４２５ａにおいて、振る舞い変更処理が可能であると判断した場合、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１に対して、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２がインスタンス化されているか（すなわち、図１４に示されるオブジェクト構成がメモリ上に構築されているか）を問い合わせる（Ｓ４２６ａ）。一方、ステップＳ４２５ａにおいて、振る舞い変更処理は不可能であると判断した場合、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、ＪＳＤＫＥｎｖｉｒｏｎｍｎｅｔ５２１に変更不可であることを通知する（Ｓ４２６ｂ）。

ステップＳ４２６ａの問い合わせに対して、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１は、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２がインスタンス化されていればそのインスタンスを返却する（Ｓ４２７）。

ＰｒｉｎｔＳｅｒｖｉｃｅ７１２のインスタンスが生成されていない場合、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、状態遷移情報９００に対し振る舞い変更情報に応じた修正を行い、修正された状態遷移情報９００をＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１に登録する（Ｓ４２８ａ）具体的には、状態遷移情報９００の３４行目と３８行目の間に、ＡｓｐｅｃｔＳＭ８１０の１０行目から１３行目が挿入される。したがって、以降にＰｒｉｎｔＳｅｒｖｉｃｅ７１２がインスタンス化される際は、修正された状態遷移情報９００に基づいて、オブジェクト群が構築される。

一方、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２のインスタンスが生成されている場合、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、図１９に示される処理を実行する（Ｓ４２８ｂ）
図１９において、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２のＩｄｌｅ状態オブジェクト７４１Ｓを検索する（Ｓ４３１、Ｓ４３２）。ここで、ＭｏｄｅｆｙＡｇｅｎｔ７３２は、ＡｓｐｅｃｔＳＭ８１０のｐｏｉｎｔｃｕｔ．Ｔｒａｎｓｍｉｓｓｉｏｎ要素８１３のｔｉｍｉｎｇ属性に基づいて、Ｉｄｌｅ状態オブジェクト７４１Ｓを監視することにより、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２がＩｄｌｅ状態７４１に遷移するまで待機する。

ＰｒｉｎｔＳｅｒｖｉｃｅ７１２がＩｄｌｅ状態７４１に遷移すると、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、Ｉｄｌｅ状態オブジェクト７４１Ｓより、印刷開始オブジェクト７４３Ｔを検索する（Ｓ４３３、Ｓ４３４）。続いて、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、ガード条件を表現するガード条件オブジェクト７４６を生成し（Ｓ４３５）、ＡｓｐｅｃｔＳＭ８１０に定義されているガード条件（［ｉｓ＿ｉｎ（ＦａｘＴｘＩｄｌｅ）］）を、ガード条件オブジェクト７４６に設定する（Ｓ４３６）。ここで、ＦａｘＴｘＩｄｌｅは、ＦａｘＳｅｒｖｉｃｅ７１４のＩｄｌｅ状態オブジェクトの識別情報である。

続いて、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、印刷開始オブジェクト７４３Ｔに対して、ガード条件オブジェクト７４６を設定する（Ｓ４３７）。ここで、印刷開始オブジェクト７４３Ｔは、Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２への状態遷移に対応するオブジェクトである。したがって、ステップＳ４３７の処理により、当該状態遷移にガード条件が付加されたことになる。以降、ＰｒｉｎｔＳｅｒｖｉｃｅ７１２において、Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２への遷移が発生する際、印刷開始オブジェクト７４３Ｔに設定されたガードオブジェクト７４６に基づいて、遷移の可否が判定される。

上述したように、本実施の形態におけるＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１は、状態オブジェクトの遷移によってサービスを実現する。また、サービスの実現過程において、アクティブな状態オブジェクトが限定されるように構成されている。言い換えれば、非アクティブな状態オブジェクトが存在することになる。このような構成を前提として、ＡｓｐｅｃｔＳＭ８１０には、更新部分が非アクティブなタイミングで更新が行われるような更新指示が記述されている。そして、かかるＡｓｐｅｃｔＳＭ８１０に従って、更新部分が非アクティブなときに更新が実行される。したがって、本実施の形態におけるＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１は、当該ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の実行中にその振る舞いの変更を実行することができる。また、振る舞いの変更にあたり、オブジェクト群が再構築されるわけではないので、当該ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の参照側との参照関係が破壊されることなく、動的にその振る舞いを変更することが可能となっている。よって、融合機１０１を再起動することなくＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の振る舞いは変更され得る。

なお、本実施の形態においては、ステートマシンが状態遷移モデルに基づいて設計された例を用いて説明したが、本発明が適用可能なプログラムは、状態ごとにオブジェクトが構築されるような構成であるものに限定されない。お互いに排他的に動作する複数のモジュール（オブジェクトも含む）の接続によって構成されているものでればよい。ここで排他的に処理を実行するとは、あるモジュールが動作中（アクティブ）のときは、他のモジュールは動作中でない（非アクティブである）ことが保証されることをいう。このようなソフトウェアであれば、動作中でないモジュールを変更することが可能であり、本実施の形態において説明した振る舞いの変更処理を適用させることができる。

２）ＭｏｄｉｆｙＳｅｒｖｉｃｅ
図２１は、図７のＪＳＤＫシステムを構成するＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２について説明するためのクラス図である。ＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２は、ＪＳＤＫアプリ１４７からのＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１に対するサービスの提供要求に応じて、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１のサービスを修正するクラスである。すなわち、第一節（ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ）では、プラットフェーム１３２からのイベントに応じて、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１が、自らの振る舞いを変更する処理について説明したが、ＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２は、ＪＳＤＫアプリ１４７がＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１を利用しようとしたときに、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の振る舞いを変更するのである。

図７のＪＳＤＫシステムでは、第１節で取り上げたＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１と第２節で取り上げるＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２は下位層と上位層の関係にある。図７のＪＳＤＫシステムには、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、ＦｕｎｃｔｉｏｎＡＰＩ６１１が存在し、ＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、ＭｏｄｉｆｙＡＰＩ６１２が存在する。ＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２とＭｏｄｉｆｙＡＰＩ６１２の実装態様は、図２１の実装態様ではなく図２２の実装態様でもよい。図２１についての説明の内容は図２２についても同様に成立する。なお、図２１は、ＭｏｄｉｆｙＡＰＩ６１２は、複数のユーザアプリ５０１に対して有効であること（呼び出し元が限定されないこと）を示す。一方、図２２は、ＭｏｄｉｆｙＡＰＩ６１２は、特定のユーザアプリ５０１に対して有効であること（呼び出し元が限定されること）を示す。

ＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２とＭｏｄｉｆｙＡＰＩ６１２の実装理由を説明する事にする。図７のＪＳＤＫシステムには、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の振る舞いを動的に変更する機能は実装しているが、ＦｕｎｃｔｉｏｎＡＰＩ６１１の動作を動的に変更する機能は実装していない。ＡＰＩの実装態様はユーザアプリ５０１の開発効率に与える影響が大きいところ、ＡＰＩの動作を動的に変更するような実装は開発トラブルや市場トラブルを招き兼ねないからである。よって、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１のサービスを修正するには、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１のサービスを修正するＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２を、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１に上乗せするのである。そしてさらに、ＦｕｎｃｔｉｏｎＡＰＩ６１１にＭｏｄｉｆｙＡＰＩ６１２を上乗せする。

図２１に示す通り、旧バージョンのユーザアプリ５０１は、ＦｕｎｃｔｉｏｎＡＰＩ６１１を通じてＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にサービスを要求（Ｓ１０１）する。一方、新バージョンのユーザアプリ５０１は、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にサービスを要求する際には、ＦｕｎｃｔｉｏｎＡＰＩ６１１を通じてＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にサービスを要求（Ｓ１０２）して、ＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２にサービスを要求する際には、ＭｏｄｉｆｙＡＰＩ６１２を通じてＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２にサービスを要求（Ｓ１０３）する。

但し、ＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２を介してサービス要求がなされ、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の振る舞いが変更された後は、旧バージョンのユーザアプリ５０１であっても、ＦｕｎｃｔｉｏｎＡＰＩ６１１を通じて、振る舞いが変更されたＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１によるサービスの提供を受けることができる。

ＭｏｄｉｆｙＳｅｒｖｉｃｅ６１２について更に具体的に説明する。図２３は、ＭｏｄｉｆｙＳｅｒｖｉｃｅによるＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅの変更処理を説明するためのシーケンス図である。図２３では、ＦａｘＳｅｒｖｅｃｅ７１４を利用するためのＦｕｎｃｔｉｏｎＡＰＩ６１１の呼び出しに応じて、ＰｒｉｎｔｅｒＳｅｒｖｉｃｅ７１２の振る舞いが変更される例について説明する。

ＪＳＤＫアプリ１４７の一つであるＦａｘ送信アプリ５０１ｆが起動されている状態において、ユーザが、オペレーションパネル２０２を介してＦａｘ送信アプリ５０１ｆに対して送信開始の指示を行ったとする（Ｓ５０１）。Ｆａｘ送信アプリ５０１ｆは、ユーザからの指示に応じ、ＦｕｎｃｔｉｏｎＡＰＩ６０１又はＭｏｄｉｆｙＡＰＩ６１２の一部を構成するＦａｘ送信クラス６１１ｆを用いて送信開始を行う（Ｓ５０２）。具体的には、Ｆａｘ送信アプリ５０１ｆは、Ｆａｘ送信クラス６１１ｆのｓｔａｒｔ（）メソッド（Ｆａｘｔｘ．ｓｔａｒｔ（））を呼び出す。

Ｆａｘ送信クラス６１１ｆは、ＦａｘＴｘ．ｓｔａｒｔ（）メソッドが呼ばれたこと（送信開始イベント７５３の発生）を要求元のアプリのプロダクトＩＤを添えてＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２に通知する（Ｓ５０３）。ＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２は、通知されたイベント（送信開始イベント７５３）が、Ｆａｘ送信アプリ５０１ｆのインストールの際にＦａｘ送信アプリ５０１ｆに対応させて登録されたＡｓｐｅｃｔＳＭに基づく振る舞い変更のトリガとなるイベントであるか当該ＡｓｐｅｃｔＳＭを参照することにより判断する。

図２４は、Ｆａｘ送信アプリに対応させて登録されたＡｓｐｅｃｔＳＭの記述例を示す図である。図２４のＡｓｐｅｃｔＳＭ８２０は、２行目の記述内容が、図２０のＡｓｐｅｃｔＳＭ８１０と異なる。

すなわち、ＡｓｐｅｃｔＳＭ８２０のＥｖｅｎｔ要素８２１のｎａｍｅ属性には、振る舞いを変更するトリガとなるイベント名として"Ｍｅｔｈｏｄ"が記述されている。これは、メソッドが呼び出されたことがトリガとなることを意味する。また、ｔｙｐｅ属性には、トリガとなる具体的なメソッド名（" ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ＦａｘＴｘ：ｓｔａｒｔ（ｖｏｉｄ）"）が記述されている。ここで「ＦａｘＴｘ」とは、Ｆａｘ送信クラスを示す。更に、ｖａｌｕｅ属性には、メソッドの呼び出し元を特定するプロダクトＩＤ（"１２３４５６"）が記述されている。ここで、"１２３４５６"は、Ｆａｘ送信アプリ５０１ｆのプロダクトＩＤである。呼び出し元を特定しない場合、ｖａｌｕｅ属性の値は空となる。なお、ｖａｌｕｅ属性の値にプロダクトＩＤが指定されない場合（すなわち、呼び出し元が限定されない場合）と、プロダクトＩＤが指定される場合（すなわち、呼び出し元が限定される場合）との違いは、図２１と図２２との違いによって概念的に示されている。

上記より、ＡｓｐｅｃｔＳＭ８２０には、Ｆａｘ送信アプリ５０１ｆからのＦａｘｔｘ．ｓｔａｒｔ（）の呼び出しが、振る舞いを変更するトリガであることが記述されていることが分かる。

したがって、ＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２は、ＡｓｐｅｃｔＳＭ８２０のＥｖｅｎｔ要素８２１に基づいて、Ｆａｘ送信クラス６１１ｆより通知されたイベント（送信開始イベント７５３）は、振る舞い変更のトリガとなるイベントであると判断し、ＭｏｄｉｆｙＡｇｅｎｔ７３２に「振る舞い変更情報」を添えて、ＰｒｉｎｔｅｒＳｅｒｖｉｃｅ７１２の振る舞いの変更を要求する（Ｓ５０４）。

続いて、ステップＳ５０５からステップＳ５１０ｂまでは、図１８のステップＳ４２３からステップＳ４２８ｂまでと同様の処理が実行される。したがって、ステップＳ５１０ｂでは、図１９において説明した処理と同様の処理が実行され、ＰｒｉｎｔｅｒＳｅｒｖｉｃｅ７１２の振る舞いが変更される。すなわち、ＰｒｉｎｔｅｒＳｅｒｖｉｃｅ７１２における、Ｉｄｌｅ状態７４１からＰｒｉｎｔ状態７４２への状態遷移に対してガード条件が付加される。

続いて、ＭｏｄｉｆｙＡｇｅｎｔ７３２は、ＰｒｉｎｔｅｒＳｅｒｖｉｃｅ７１２の振る舞いの変更が完了したことをＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２に通知する（Ｓ５１１）。ＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２は、Ｆａｘ送信クラス６１１ｆに対して変更の完了を通知する（Ｓ５１２）。

Ｆａｘ送信クラス６１１ｆは、ＭｏｄｉｆｙＳｅｒｖｉｃｅ６０２からの変更完了通知が届くまで待機している。Ｆａｘ送信クラス６１１ｆは、変更完了通知に応じてＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１に対して送信開始イベント７５３を発行する（Ｓ５１３）。ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１は、送信開始イベント７５３の通知先を検索し、検索されたＦａｘＳｅｒｖｉｃｅ７１３に送信開始イベント７５３を通知する（Ｓ５１４）。

ここでＦａｘＳｅｒｖｉｃｅ７１３によってＦａｘの送信処理が実行されるが、この間は、上記で説明した振る舞いの変更によってＰｒｉｎｔｅｒＳｅｒｖｉｃｅ７１２に対して印刷開始イベント７４３が発行されても、印刷は開始されない。

ＦａｘＳｅｒｖｉｃｅ７１４によるＦａｘ送信が完了すると（Ｓ５１５）、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１は、Ｆａｘ送信クラス６１１ｆに送信完了通知を行う（Ｓ５１６）。Ｆａｘ送信クラス６１１ｆは、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１からの送信完了通知を受けてＦａｘ送信アプリ５０１ｆに送信完了通知を行う（Ｓ５１７）。Ｆａｘ送信アプリ５０１ｆは、オペレーションパネル２０２に送信が完了した旨のメッセージ等を表示することにより、Ｆａｘ送信の完了をユーザに通知する（Ｓ５１８）。

ところで、図２３のステップＳ５１４において、「ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１は、送信開始イベント７５３の通知先を検索する」と説明したが、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１に通知されたイベントが、どのように各ステートマシンに通知されるかについて説明する。

図２５は、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌによるイベントの通知方式について説明するための図である。

ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１は、イベントを受け付けると、管理しているステートマシン群に対して、ラウンドロビン方式で順番にイベントを発行する。これにより、ステートマシン間では排他的な動作が実現される。また、個々のステートマシンも遷移処理を排他的に処理することにより、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１内のアクション処理を排他的に実行することができる。

図２５に示される手順に沿って説明する。

送信開始イベント７５３が、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１に対して発行される（Ｓ５２１）。ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１は、管理している全てのステートマシン（但し、イベントに宛先が明示されている場合は、特定のステートマシン）に送信開始イベント７５３をラウンドロビン方式で発行する（Ｓ５２１〜Ｓ５２４）。例えば、ＦａｘＳｅｒｖｉｃｅ７１４が、待ち行列の最初に位置している場合、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１は、最初にＦａｘＳｅｒｖｉｃｅ７１４に送信開始イベント７５３を発行する（Ｓ５２１）。

ＦａｘＳｅｒｖｉｃｅ７１４は、今現在、アクティブな状態オブジェクトに接続している全ての遷移オブジェクトに対して順番にイベントを発行し、遷移条件を満足しているかを確認する。遷移条件を満足していれば、アクションを実行して遷移する。例えば、Ｉｄｌｅ状態７５１であれば、送信開始イベント７５３によりＦａｘＳｅｎｄ状態７５２に遷移し、Ｆａｘ送信を開始する。

３）ＥｘｔｅｎｄＳｅｒｖｉｃｅ
図２６は、図７のＪＳＤＫシステムを構成するＥｘｔｅｎｄＳｅｒｖｉｃｅ６０３について説明するためのクラス図である。ＥｘｔｅｎｄＳｅｒｖｉｃｅ６０３は、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１のサービスを拡張するクラスである。図７のＪＳＤＫシステムでは、第１節で取り上げたＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１と第３節で取り上げるＥｘｔｅｎｄＳｅｒｖｉｃｅ６０３は同位層の関係にある。図７のＪＳＤＫシステムには、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、ＦｕｎｃｔｉｏｎＡＰＩ６１１が存在し、ＥｘｔｅｎｄＳｅｒｖｉｃｅ６０３とユーザアプリ５０１との間のサービス授受を仲介するＡＰＩとして、第１のＥｘｔｅｎｄＡＰＩ６１３−１が存在し、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１とＥｘｔｅｎｄＳｅｒｖｉｃｅ６０３との間のサービス授受を仲介するＡＰＩとして、第２のＥｘｔｅｎｄＡＰＩ６１３−２が存在する。

ＥｘｔｅｎｄＳｅｒｖｉｃｅ６０３とＥｘｔｅｎｄＡＰＩ６１３の実装理由を説明する事にする。ＪＳＤＫアプリ１４７の多様な変化にＪＳＤＫプラットフォーム１４８が適切に対応するには、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１のサービスをより他律的に変更できる方が好適な場合がある。ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１に部品を外部から提供してＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１のサービスを拡張する場合等である。よって、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１のサービスを拡張するのに、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１のサービスを拡張するＥｘｔｅｎｄＳｅｒｖｉｃｅ６０３を、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１とともに実装するのである。そしてさらに、ＦｕｎｃｔｉｏｎＡＰＩ６１１とともにＥｘｔｅｎｄＡＰＩ６１３を実装する。

図２６に示す通り、旧バージョンのユーザアプリ５０１は、ＦｕｎｃｔｉｏｎＡＰＩ６１１を通じてＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にサービスを要求（Ｓ２０１）する。一方、新バージョンのユーザアプリ５０１は、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１に非拡張バージョンのサービスを要求する際は、ＦｕｎｃｔｉｏｎＡＰＩ６１１を通じてＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にサービスを要求（Ｓ２０２）して、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１に拡張バージョンのサービスを要求する際は、第１のＥｘｔｅｎｄＡＰＩ６１３−１とＥｘｔｅｎｄＳｅｒｖｉｃｅ６０３と第２のＥｘｔｅｎｄＡＰＩ６１３−２とを通じてＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にサービスを要求（Ｓ２０３−１，２）する。

図２７は、ＥｘｔｅｎｄＳｅｒｖｉｃｅの動作の概要を説明するための図である。

図２７に示されるＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にて、ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２には、非拡張バージョンのＦａｘＳｅｒｖｉｃｅ７１４であるＦａｘＴｘ１と、拡張バージョンのＦａｘＳｅｒｖｉｃｅ７１４であるＦａｘＴｘ２が存在する。ＦａｘＴｘ１は、画像データをＦＡＸ送信するＦａｘＳｅｒｖｉｃｅ７１４である。ＦａｘＴｘ２は、画像データをＰＤＦからＴＩＦＦに変換してＦＡＸ送信するＦａｘＳｅｒｖｉｃｅ７１４である。画像データをＰＤＦからＴＩＦＦに変換してＦＡＸ送信する場合において、ＦａｘＴｘ１が送信処理に関与する場合にはＪＳＤＫアプリ１４７で変換処理を実行する事になり、ＦａｘＴｘ２が送信処理に関与する場合にはＪＳＤＫプラットフォーム１４８で変換処理を実行する事になる。

図２８は、ＦａｘＴｘ１やＦａｘＴｘ２の状態遷移モデルである。ＦａｘＴｘ１の状態には、初期状態７６０、Ｉｄｌｅ状態７６１、Ｓｅｎｄ状態７６２、及び終期状態７６４等が存在する。ＦａｘＴｘ２の状態には、初期状態７６０、Ｉｄｌｅ状態７６１、Ｓｅｎｄ状態７６２、Ｔｒａｎｓｆｏｒｍ状態７６３、及び終期状態７６４等が存在する。Ｉｄｌｅ状態７６１は、ＦＡＸ送信処理の待機中の状態である。Ｓｅｎｄ状態７６２は、ＦＡＸ送信処理を実行中の状態である。Ｔｒａｎｓｆｏｒｍ状態７６３は、画像変換処理を実行中の状態である。図２８により、ＦａｘＴｘ１とＦａｘＴｘ２は継承関係にある事が解る。ＦａｘＴｘ１が継承前のクラスであり、ＦａｘＴｘ２が継承後のクラスである。

ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にて、ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２では、自己の振る舞いを動的に継承する事で、自己の振る舞いを動的に変更する事ができる。例えば、図２７に示す通り、ＦａｘＴｘ１がＦａｘＴｘ２に動的に継承される事で、画像データをＰＤＦからＴＩＦＦに変換しない振る舞いが変換する振る舞いに動的に変更される事になる。

ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にて、ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２では、自己に振る舞い継承用のプラグイン部品をプラグインする事で、自己の振る舞いを動的に継承する事ができる。例えば、図２７に示す通り、画像データをＰＤＦからＴＩＦＦに変換するためのプラグイン部品の「ＰＤＦ２ＴＩＦＦ」のプラグインにより、ＦａｘＴｘ１がＦａｘＴｘ２に動的に継承される。振る舞い継承用のプラグイン部品は、ＥｘｔｅｎｄＳｅｒｖｉｃｅ６０３がＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１に提供する。

図２９は、ＦａｘＳｅｒｖｉｃｅに関するプラグイン処理を説明するための図である。

ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にて、ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ７０２には、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１、ＰｌｕｇｉｎＡｇｅｎｔ７３３等のクラスが存在する。

ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１は、ＦａｘＴｘ１やＦａｘＴｘ２の状態遷移モデルを管理するクラスである。ＰｌｕｇｉｎＡｇｅｎｔ７３３は、ＦａｘＴｘ１やＦａｘＴｘ２の状態遷移モデルに振る舞い継承用のプラグイン部品のプラグイン結果を反映させるクラスである。

ＰｌｕｇｉｎＡｇｅｎｔ７３３は、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１に振る舞い継承用のプラグイン部品がプラグインされた場合、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１が管理する状態遷移モデルに振る舞い継承用のプラグイン部品のプラグイン結果を反映させる。これによって、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１の振る舞いが動的に変更される。

図２６から図２９にかけてその概要を説明したＦａｘＴｘ１からＦａｘＴｘ２への拡張処理について更に具体的に説明する。

拡張前のＦａｘＳｅｒｖｉｃｅ７１４であるＦａｘＴｘ１は、図１３に示したモデルに基づいて、以下のようなオブジェクトによって構成される。

図３０は、ＦａｘＴｘ１のオブジェクト構成を表す図である。ＦａｘＴｘ１は、図２８の状態遷移モデルに基づいて、初期状態オブジェクト７６０Ｓ、終期状態オブジェクト７６４Ｓ、Ｉｄｌｅ状態オブジェクト７６１Ｓ、Ｓｅｎｄ状態オブジェクト７６２Ｓ、送信開始オブジェクト７６５Ｔ、送信処理オブジェクト７６２Ａ等より構成されている。

また、図３１はＦａｘＴｘ２のオブジェクト構成を表す図である。ＦａｘＴｘ２は、図２８の状態遷移モデルに基づいて、初期状態オブジェクト７６０Ｓ、終期状態オブジェクト７６４Ｓ、Ｉｄｌｅ状態オブジェクト７６１Ｓ、Ｓｅｎｄ状態オブジェクト７６２Ｓ、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓ、送信開始オブジェクト７６５Ｔ、送信処理オブジェクト７６２Ａ、変換処理オブジェクト７６３Ａ、変換終了オブジェクト７６６Ｔ等より構成されている。なお、図３０及び図３１においては、一部の遷移オブジェクトが省略されているが（例えば、Ｓｅｎｄ状態７６２から終期状態７６４への状態遷移に対応する遷移オブジェクト）、これは便宜的なものである。

図３０及び図３１より、ＦａｘＴｘ１からＦａｘＴｘ２への拡張処理とは「Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓ」や「変換処理オブジェクト７６３Ａ」や「変換終了オブジェクト７６６Ｔ」といった拡張処理用のオブジェクトをＦａｘＴｘ１に対して追加する事で実現できることが分かる。

ＦａｘＳｅｒｖｉｃｅ７１４の拡張処理の影響が顕著なオブジェクトが、ＦａｘＳｅｒｖｉｃｅ７１４の更新部分のオブジェクトである。ＦａｘＳｅｒｖｉｃｅ７１４の更新部分のオブジェクトとは、オブジェクトの入替部分やオブジェクトの追加部分（ＦａｘＳｅｒｖｉｃｅ７１４の更新部分）に連結するオブジェクトを意味する。図３０から図３１への拡張処理では、ＦａｘＳｅｒｖｉｃｅ７１４の更新部分に相当するのがスイッチ７７０等の追加部分であり、ＦａｘＳｅｒｖｉｃｅ７１４の更新部分のオブジェクトに相当するのがＳｅｎｄ状態オブジェクト７６２Ｓや送信開始オブジェクト７６５Ｔである。ＦａｘＳｅｒｖｉｃｅ７１４の拡張処理をＦａｘＳｅｒｖｉｃｅ７１４の動作中に実行するには、ＦａｘＳｅｒｖｉｃｅ７１４の更新部分のオブジェクトがアクティブ状態ではないとき（非アクティブ状態のとき）に実行すればよい。

図３２及び図３３は、ＦａｘＴｘ１の状態遷移情報の定義例を示す図である。図３２及び図３３によって一つの状態遷移情報１１００の記述例が示されている。なお、図中における行番号は、説明の便宜上付加したものである。

状態遷移情報１１００の１２１行目における＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグのタグ名、及びそのｎａｍｅ属性の値（ＦａｘＴｘ１）によって、状態遷移情報１１００は、ＦａｘＴｘ１に対応するものであることが定義されている。また、当該＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグにおけるｘｍｉ．ｉｄ属性の値（「００４」）は、ＦａｘＴｘ１を識別するＩＤである。

１２５行目の＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグは、ＦａｘＴｘ１における状態の定義の開始の宣言に相当する。当該宣言は、＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグのｘｍｉ．ｉｄの値（「０１７」）によって識別される。

１３０行目から１３７行目における＜Ｐｓｅｕｄｏｓｔａｔｅ＞タグによって囲まれたＰｓｅｕｄｏｓｔａｔｅ要素１１１０は、初期状態７６０に対する定義である。Ｐｓｅｕｄｏｓｔａｔｅ要素１１１０のｎａｍｅ属性の値には「Ｉｎｉｔ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０１８」が設定されている。

１３８行目から１４８行目におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１２０は、Ｓｅｎｄ状態７６２に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１２０のｎａｍｅ属性の値には「Ｓｅｎｄ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０１９」が設定されている。

１４９行目から１５９行目におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１３０は、Ｉｄｌｅ状態７６１に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１３０のｎａｍｅ属性の値には「Ｉｄｌｅ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０２２」が設定されている。

１６０行目から１８３行目におけるＰｓｅｕｄｏｓｔａｔｅ要素１１４０は、終期状態７６４に対する定義である。Ｐｓｅｕｄｏｓｔａｔｅ要素１１４０のｎａｍｅ属性の値には「ｅｎｄ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０２４」が設定されている。

また、１９１行目から２２８行目には、ＦａｘＴｘ１における各状態遷移が定義されている。すなわち、１９１行目から２０４行目におけるＴｒａｎｓｉｔｉｏｎ要素１１５０は、Ｉｄｌｅ状態７６１からＳｅｎｄ状態７６２への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素１１５０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ要素１１５０の子要素として定義されている、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１５１及びＴｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１５２より特定される。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１５１は遷移元の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１５１の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０２２」である。したがって、遷移元は、ｘｍｉ．ｉｄ属性の値が「０２２」の状態、すなわち、Ｉｄｌｅ状態７６１であることが分かる。また、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１５２は遷移先の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１５２の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０１９」である。したがって、遷移先は、ｘｍｉ．ｉｄの値が「０１９」の状態、すなわち、Ｓｅｎｄ状態７６２であることが分かる。なお、Ｔｒａｎｓｉｔｉｏｎ要素１１５０のｎａｍｅ属性の値は「送信開始」であり、ｘｍｉ．ｉｄ属性の値は「０２３」である。

２０５行目から２１８行目におけるＴｒａｎｓｉｔｉｏｎ要素１１６０は、Ｓｅｎｄ状態７６２から終期状態７６４への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素１１６０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１６１内のｘｍｉ．ｉｄｒｅｆ属性の値が「０１９」（Ｓｅｎｄ状態７６２）であり、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１６２内のｘｍｉ．ｉｄｒｅｆ属性の値が「０２４」（終期状態７６４）であることから特定される。なお、Ｔｒａｎｓｉｔｉｏｎ要素１１６０のｎａｍｅ属性の値は「送信終了」であり、ｘｍｉ．ｉｄ属性の値は「０２０」である。

２１９行目から２２８行目におけるＴｒａｎｓｉｔｉｏｎ要素１１７０は、初期状態７６０からＩｄｌｅ状態７６１への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素１１７０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素１１７１内のｘｍｉ．ｉｄｒｅｆ属性の値が「０１８」（初期状態７６０）であり、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１７２内のｘｍｉ．ｉｄｒｅｆ属性の値が「０２２」（Ｉｄｌｅ状態７６１）であることから特定される。なお、Ｔｒａｎｓｉｔｉｏｎ要素１１７０のｘｍｉ．ｉｄ属性の値は「０１８」である。

１３０行目以降の説明に戻る。各状態に対応する、Ｐｓｅｕｄｏｓｔａｔｅ要素１１１０、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１２０、及びＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１３０は、ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素及びＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素の少なくともいずれか一方を子要素として有する。ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素は、遷移元からの状態遷移に対する接続が定義される要素である。ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素は、遷移先への状態遷移に対する接続が定義される要素である。

例えば、初期状態７６０に対応するＰｓｅｕｄｏｓｔａｔｅ要素１１１０におけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素１１１１において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０１８」である。したがって、初期状態７６０からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素１１７０が対応する状態遷移に相当することが分かる。

また、Ｓｅｎｄ状態７６２に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１２０おけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素１１２１においてその子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０２０」であり、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素１１２２において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０２３」である。したがって、Ｓｅｎｄ状態７６２からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素１１６０が対応する状態遷移に相当し、遷移元の状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素１１５０が対応する状態遷移に相当することが分かる。

なお、Ｉｄｌｅ状態７６１に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素１１３０、終期状態７６４に対応するＰｓｅｕｄｏｓｔａｔｅ要素１１４０においても同様に状態遷移との接続が定義されている。

このような状態遷移情報に基づいて、ＦａｘＴｘ１のオブジェクト構成は構築される。なお、オブジェクト構成の構築処理は、図１５において説明したものに準ずるため、ここでの説明は省略する。

上記をふまえて、ＦａｘＳｅｒｖｉｃｅ７１４の拡張処理を具体的に説明する。図３４は、ＦａｘＳｅｒｖｉｃｅの拡張処理を説明するためのシーケンス図である。

例えば、管理者は、ＦａｘＴｘ２とＦａｘＴｘ１との差分の追加モジュールが格納されたＳＤカードを融合機１０１のメモリカードスロット２３４に挿入する（Ｓ６０１）。

図３５は、ＳＤカード内の追加モジュールの構成例を示す図である。図３５に示されるＳＤカード２３５ａには、Ｆａｘ拡張インタフェース６１３−１ａと、更新差分サービスバンドル８４０と、ＡｓｐｅｃｔＳＭ．ｘｍｌファイル８５０（ＡｓｐｅｃｔＳＭ８５０）とが格納されている。Ｆａｘ拡張インタフェース６１３−１ａ（ＦａｘＴｘＥｘ）は、ＦａｘＳｅｒｖｉｃｅ７１４を拡張するためのＥｘｔｅｎｄＡＰＩ６１３−１に相当する。更新差分サービスバンドル８４０には、拡張処理を実行するにあたり、図１３のクラス図において、ＩＳｔａｔｅインタフェース１００４ａ、Ａｃｔｉｖｉｔｙインタフェース１００４ｂ、Ｅｖｅｎｔインタフェース１００３ａ、Ｇｕａｒｄインタフェース１００３ｂ、又はＡｃｔｉｏｎインタフェース１００３ｃに対応するクラスのうち、追加が必要とされるクラスが実装された機能モジュール（例えば、Ｊａｖａ（登録商標）のクラスファイル。以下「追加モジュール」という。））が格納されている。ここでは、追加モジュールとして、ＰＤＦ２Ｔｉｆｆ８４１とＣｏｎｖｅｒｔＥｎｄ８４２とが格納されている。

ＡｓｐｅｃｔＳＭ８５０は、ＦａｘＴｘ１からＦａｘＴｘ２への拡張処理をどのように実施するかについての仕様がＸＭＬ形式記述されているファイルである。

図３６は、ＦａｘＳｅｒｖｉｃｅの拡張内容が記述されたＡｓｐｅｃｔＳＭの記述例を示す図である。図中、行番号は説明の便宜上付加したものである。ＡｓｐｅｃｔＳＭ８５０には、ＦａｘＴｘ１の状態遷移情報１１００（図３２及び図３３）に対する変更内容が記述されている。

ＡｓｐｅｃｔＳＭ８５０の記述例において、２行目は、ｘｍｉ．ｉｄの値が「００４」であるＦａｘＴｘ１に対して状態遷移の変更を行うことを指示している。すなわち、２行目におけるｘｍｉ．ｉｄｒｅｆ属性は、変更の対象となるステートマシンのｘｍｉ．ｉｄが指定される。

３行目から２０行目までは一つ目の変更箇所に関する変更情報が記述されている。３行目には、変更箇所と変更タイミングが指定されている。変更箇所は、ｐｏｉｎｔｃｕｔ．＜ｘｘｘ＞における＜ｘｘｘ＞の記述とｘｍｉ．ｒｅｆ属性の値とによって指定される。ここで、＜ｘｘｘ＞の部分は「ＣｏｍｐｏｓｉｔｅＳｔａｔｅ」であり、ｘｍｉ．ｒｅｆ属性の値は「０１７」である。したがって、状態遷移情報１１００の１２５行目における＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグ内に対する変更が指定されていることになる。また、変更のタイミングは、ｔｉｍｉｎｇ属性の値によって指定される。ここでは、「Ｉｄｌｅ」が指定されている。したがって、ＦａｘＴｘ１がＩｄｌｅ状態７６１にあるときに、変更を行うべきことが指定されている。

４行目には、変更の内容が指定されている。すなわち、＜ａｄｖｉｃｅ．ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグのタグ名におけるａｄｖｉｃｅ．以降によって、変更の対象がＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素であることが指定されている。また、ｔｙｐｅ属性によって、変更の種別が「ｉｎｓｅｒｔ」（挿入）であることが指定されている。すなわち、３行目及び４行目によって、＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグ内に新たなＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素を挿入すべき旨が指定されている。

５行目から１８行目は、挿入の対象となるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１の定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１は、ＦａｘＴｘ２のＴｒａｎｓｆｏｒｍ状態７６３に対応する。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１内の記述形式は、図３２及び図３３において説明した通りである。すなわち、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１の子要素である、ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素８５２において遷移先への接続が定義され、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素８５３において遷移元への接続が定義されている。

ところで、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１は、Ｓｔａｔｅ．ｅｎｔｒｙ要素８５４が子要素として定義されている。Ｓｔａｔｅ．ｅｎｔｒｙ要素８５４は、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１が対応するＴｒａｎｓｆｏｒｍ状態７６３における入場処理が定義される要素である。すなわち、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１の子要素として、Ａｃｔｉｏｎ要素８５５が定義されているが、そのｘｍｉ．ｉｄ属性とｎａｍｅ属性より、ｘｍｉ．ｉｄ属性の値が「０２６」であり、ｎａｍｅ属性の値がｐｄｆ２ｔｉｆｆによって識別される処理が実行されることが指定されている。

２１行目から４２行目までは二つ目の変更箇所に関する変更情報が指定されている。２１行目には、変更箇所及び変更のタイミングが指定されている。ここでは、Ｉｄｌｅ状態７６１のときにＴｒａｎｓｉｔｉｏｎ要素１１５０（図３３参照）に対して変更を行うことが指定されている。

二つ目の変更箇所には、二つの変更が指定されている。２２行目から２４行目までに一つ目の変更が指定されており、２５行目から４１行目までに二つ目の変更が指定されている。

一つ目の変更については、２２行目の＜ａｄｖｉｃｅ．Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ＞タグのタグ名におけるａｄｏｖｉｃｅ．以降によって変更対象がＴｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素１１５２であることが指定されている。また、ｔｙｐｅ属性によって、変更の種別が修正（ｍｏｄｉｆｙ）であることが指定されている。２３行目には、変更の対象に関して修正後の定義が記述されている。すなわち、一つ目の変更は、Ｉｄｌｅ状態７６１からＳｅｎｄ状態７６２への状態遷移を、Ｉｄｌｅ状態７６１からＴｒａｎｓｆｏｒｍ状態７６３への状態遷移に修正することである。

二つ目の変更（２５行目から４１行目）は、新たな状態遷移（Ｔｒａｎｆｏｒｍ状態６０５からＳｅｎｄ状態７６２への状態遷移）に対応するＴｒａｎｓｉｓｉｏｎ要素の挿入をＩｄｌｅ状態７６１のときに行うことである。この内容は、上記の説明から読み取れるため、各行毎の説明は省略する。

４３行目から５５行目は、標準ではなく独自の書式に基づく定義が行われている拡張記述部分である。４３行目のｐｏｉｎｔｃｕｔ．以下の「ＸＭＩ．ｅｘｔｅｎｓｉｏｎ」によって、拡張記述部分であることが指定されている。本実施の形態では、この部分に、状態遷移処理で呼ばれるアクション処理と、イベント処理等に使用する機能モジュール（例えば、Ｊａｖａ（登録商標）クラス）との関連付けが定義される。

４４行目では、当該ａｄｖｉｃｅ要素の子要素の定義を挿入（ｉｎｓｅｒｔ）すべきことが指定されている。

４５行目から４９行目までは、挿入される定義である。４５行目には、Ｂｕｎｄｌｅを実装することが指定されている。Ｂｕｎｄｌｅの実装先は、ｘｍｉ．ｉｄｒｅｆ属性の値（「００４」）で指定される。すなわち、ＦａｘＴｘ１である。

４６行目から４９行目までは、Ｔｒａｎｓｆｏｒｍ状態７６３に対応させて新たに挿入するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５１（５行目から１８行目）の入場処理の定義（１５行目から１７行目）におけるｐｄｆ２ｔｉｆｆと、実際にその処理が実装されているｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｐｄｆ２ｔｉｆｆクラスとの関連付けが定義されている。これによって、ＦａｘＴｘ２に更新された後、Ｔｒａｎｓｆｏｒｍ状態７６３に遷移したときには、ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｐｄｆ２ｔｉｆｆが実行されることになる。４８行目のｐｒｏｐｅｒｔｙ要素は、ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｐｄｆ２ｔｉｆｆクラスが実行されるときのプロパティ情報である。

５０行目から５２行目は、Ｔｒａｎｓｆｏｒｍ状態７６３からＳｅｎｄ状態７６２への状態遷移のトリガとなる変換完了イベントとｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｃｏｎｖｅｒｔＥｎｄクラスとの関連付けが定義されている。これによって、Ｔｒａｎｅｆｏｒｍ状態６０５中に変換完了イベントが検知されると、ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｃｏｎｖｅｒｔＥｎｄクラスが実行され、その実行結果がｔｒｕｅであれば、Ｓｅｎｄ状態７６２に遷移することになる。

図３４に戻る。管理者によるＳＤカード２３５ａの挿入が自動的に検知されると、又はＳＤカード２３５ａが挿入され、オペレーションパネル２０２から更新指示が入力されると、ＳＡＳ４１１は、ＳＡＳＭａｎａｇｅｒ５１１に拡張処理の実行を要求する（Ｓ６０２）。なお、ＳＤカード２３５ａに記録された情報は、ネットワークを介してダウンロードされてもよい。この場合、ＳＤカードのような記録媒体を用いる必要はない。

ＳＡＳＭａｎａｇｅｒ５１１は、挿入されたＳＤカード２３５ａの更新差分サービスバンドル８４０によるＦａｘＴｘ１からＦａｘＴｘ２への更新の可否についてチェックを行う（Ｓ６０３）。更新が可能な場合、ＳＡＳＭａｎａｇｅｒ５１１は、更新差分サービスバンドル８４０の融合機１０１へのインストールの可否をチェックする（Ｓ６０４）。インストールが可能な場合、ＳＡＳＭａｎａｇｅｒ５１１は、ＳＤカード２３５ａ内の更新差分サービスバンドル８４０をＯＳＧｉフレームワーク４０３（融合機１０１）にインストールする（Ｓ６０５）。更新差分サービスバンドル８４０のインストールが完了すると、ＳＡＳＭａｎａｇｅｒ５１１は、更新差分サービスバンドル８４０をアクティブ状態に遷移させるようにＯＳＧｉフレームワーク４０３に要求する（Ｓ６０６）。

ＯＳＧｉフレームワーク４０３は、更新差分サービスバンドル８４０のインスタンスを（以下、「更新差分オブジェクト８４０ａ」という。）生成し、アクティブな状態に遷移させる（Ｓ６０７）。

続いて、ＳＡＳＭａｎａｇｅｒ５１１は、Ｆａｘ拡張インタフェース６１３−１ａをＯＳＧｉフレームワーク４０３にインストールし（Ｓ６０８）、Ｆａｘ拡張インタフェース６１３−１ａのＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１への組み込みをＥｘｔｅｎｄＳｅｒｖｉｃｅ６０３に要求する（Ｓ６０９）。

続いて、ＥｘｔｅｎｄＳｅｒｖｉｃｅ６０３が、Ｆａｘ拡張インタフェース６１３−１ａをアクティブな状態にするようＯＳＧｉフレームワーク４０３に要求すると（Ｓ６１０）、ＯＳＧｉフレームワーク４０３は、Ｆａｘ拡張インタフェース６１３−１ａをアクティブな状態に遷移させる。（Ｓ６１１）。Ｆａｘ拡張インタフェース６１３−１ａがアクティブな状態に遷移すると、ＥｘｔｅｎｄＳｅｒｖｉｃｅ６０３は、Ｆａｘ拡張インタフェース６１３−１ａをＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１に登録する（Ｓ６１２）。これによって、Ｆａｘ拡張インタフェース６１３−１ａの呼び出しが可能となる。

一方、ステップＳ６０７においてアクティブな状態にされた更新差分オブジェクト８４０ａは、ＰｌｕｇｉｎＡｇｅｎｔ７３３に対して更新差分サービスバンドル８４０がプラグインされたことをＡｓｐｅｃｔＳＭ８５０を添えて通知する（Ｓ６１３）。ＰｌｕｇｉｎＡｇｅｎｔ７３３は、ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ７３１より、ＦａｘＴｘ１のオブジェクト（ＦａｘＴｘ１オブジェクト７１４ａ）を取得する（Ｓ６１４、Ｓ６１５）。

ＰｌｕｇｉｎＡｇｅｎｔ７３３は、ＦａｘＴｘ１オブジェクト７１４ａに対して、ＡｓｐｅｃｔＳＭ８５０を添えてＦａｘＴｘ２への更新要求を行う（Ｓ６１６）。ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０に基づいて、サービスバンドルＦａｘＴｘ１をＦａｘＴｘ２へ更新する為に必要な追加モジュール判断し、当該追加モジュール（ここでは、ＰＤＦ２Ｔｉｆｆ８４１及びＣｏｎｖｅｒｔＥｎｄ８４２）の取得を更新差分オブジェクト８４０ａに要求する（Ｓ６１７）。更新差分オブジェクト８４０ａは、当該追加モジュールを取得し、ＦａｘＴｘ１オブジェクト７１４ａに返却する（Ｓ６１８）。

続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０に従って、ＦａｘＴｘ１のオブジェクト構成を、ＦａｘＴｘ２に対応するものに更新すると共に、当該更新によって新たに追加されたＡｃｔｉｖｉｔｙオブジェクトと追加モジュールとの関連付けを行う（Ｓ６１９）。なお、ステップＳ６１９の処理は、ＡｓｐｅｃｔＳＭ８５０に記述されているタイミングで行われる。

続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＦａｘＴｘ１についてＦａｘＴｘ２への更新が完了したことをＰｌｕｇｉｎＡｇｅｎｔ７３３に通知する（Ｓ６２０）。但し、ＦａｘＴｘ１をＦａｘＴｘ２に切り替えるスイッチ７７０は、ＦａｘＴｘ１の状態のままである。

更新が完了した旨の通知は、ＳＡＳＭａｎａｅｒ５１１を介してＳＡＳ４１１に通知される（Ｓ６２１、Ｓ６２２）。ＳＡＳ４１１は、管理者に更新完了を通知するため、オペレーションパネル２０２に更新完了を通知するメッセージを表示させる（Ｓ６２３）。なお、この状態では、スイッチ７７０は、まだＦａｘＴｘ２には切り替えられていないので、ＳＡＳ４１１は、管理者にＦａｘＴｘ２へ切り替える否かを問い合わせる。

そこで、管理者が、オペレーションパネル２０２を介してＦａｘＴｘ２への切替指示を入力すると（Ｓ６２４）、ＳＡＳ４１１は、ＦａｘＴｘ２への切替要求をＳＡＳＭａｎａｇｅｒ５１１に通知する（Ｓ６２５）。ＳＡＳＭａｎａｇｅｒ５１１は、ＰｌｕｇｉｎＡｇｅｎｔ７３３にＦａｘＴｘ２への切り替えを要求する（Ｓ６２６）。ＰｌｕｇｉｎＡｇｅｎｔ７３３は、ＦａｘＴｘ１オブジェクト７１４ａに対して、その振る舞い（状態遷移）をＦａｘＴｘ２に対応するものに切り替えるように指示する（Ｓ６２７）。

ＦａｘＴｘ１オブジェクト７１４ａは、ＦａｘＴｘ１がＩｄｌｅ状態７６１になるまで待機する。Ｉｄｌｅ状態７６１に遷移すると、ＦａｘＴｘ１オブジェクト７１４ａは、スイッチ７７０を切り換えることにより、自己の振る舞いをＦａｘＴｘ２に対応するものに切り替える（Ｓ６２８）。切り替えが完了すると、ＦａｘＴｘ１オブジェクト７１４ａは、ＰｌｕｇｉｎＡｇｅｎｔ７３３に対して、切替完了通知を行う（Ｓ６２９）。切替完了通知は、ＳＡＳＭａｎａｇｅｒ５１１を介してＳＡＳ４１１に伝達される（Ｓ６３０、Ｓ６３１）。ＳＡＳ４１１は、切替完了通知に応じ、ＦａｘＴｘ１の切り替えが完了した旨をオペレーションパネル２０２に表示させる（Ｓ６３２）。

次に、ステップＳ６１９における、ＦａｘＴｘ１のオブジェクト構成の更新処理の詳細について説明する。図３７は、ＦａｘＴｘ１のオブジェクト構成の更新処理を説明するためのシーケンス図である。

まず、ＦａｘＴｘ１オブジェクト７１４ａは、ＦａｘＴｘ１の状態が、ＡｓｐｅｃｔＳＭ８５０に指定されている変更箇所ごとにおけるｔｉｍｉｎｇ属性の値に指定されている状態に遷移するまで待機する（Ｓ６１９１）。図３６のＡｓｐｅｃｔＳＭ８５０の例では、全ての変更箇所に対するタイミングは、Ｉｄｌｅ状態７６１として指定されている。したがって、ここでは、Ｉｄｌｅ状態７６１に遷移するまで待機する。

ＦａｘＴｘ１の状態がＩｄｌｅ状態７６１に遷移すると、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の記述にしたがって、拡張処理を開始する。

例えば、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の３行目から２０行目に基づいてＴｒａｎｓｆｏｒｍ状態７６３に対応するＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓを生成する（Ｓ６１９２）。続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の２５行目から４１行目に基づいて、変換終了オブジェクト７６６Ｔを生成する（Ｓ６１９３）。続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の９行目から１４行目や、２２行目から２４行目に基づいて、オブジェクト間の接続関係を変更する。すなわち、ＦａｘＴｘ１オブジェクト７１４ａは、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓの識別情報を引数としてＩｄｌｅ状態オブジェクト７６１Ｓのｒｅｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ６１９４）。これに応じて、Ｉｄｌｅ状態オブジェクト７６１Ｓは、遷移先の状態オブジェクトとして、Ｓｅｎｄ状態オブジェクト７６２ＳとＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓとを保持することになる。これは、ちょうど図３１において、スイッチ７７０によって遷移先が分岐している状態に相当する。スイッチ７７０は、例えば、Ｉｄｌｅ状態オブジェクト７６１Ｓが参照可能なフラグ変数として実装される。例えば、当該フラグ変数の値が０のときには遷移先はＳｅｎｄ状態オブジェクト７６２Ｓとされ、１のときには遷移先はＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓとされるといった具合である。なお、Ｉｄｌｅ状態オブジェクト７６１ＳとＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓとの接続は行われたが、図３４において説明したように、この時点では、スイッチ７７０は切り替えられていないため、Ｉｄｌｅ状態オブジェクト７６１Ｓからの遷移先のオブジェクトはＳｅｎｄ状態オブジェクト７６２Ｓのままである（すなわち、ＦａｘＴｘ１として機能する。）。

続いて、ＦａｘＴｘ１オブジェクト７１４ａは、Ｓｅｎｄ状態オブジェクト７６２Ｓの識別情報と変換完了オブジェクト７６６Ｔの識別情報とを引数としてＴｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓのｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ６１９５）。これに応じて、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓは、Ｓｅｎｄ状態オブジェクト７６２Ｓの識別情報と変換完了オブジェクト７６６Ｔの識別情報とを関連付けて保持する。すなわち、変換終了イベントが発生した際のＴｒａｎｓｆｏｒｍ状態７６３からＳｅｎｄ状態７６２への状態遷移に対応する接続が構築されたことになる。

続いて、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０の４３行目から５５行目に基づいて、追加モジュールとオブジェクトとの関連付けを行う。すなわち、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７６３Ｓの入場処理のインタフェース（ＩＳｔａｔｅインタフェース１００４ａ）に対してＰＤＦ２ＴＩＦＦ８４１を関連付ける（Ｓ６１９６）。続いて、変換完了オブジェクト７６６ＴのＥｖｅｎｔインタフェース１００３ａに対してＣｏｎｖｅｒｔＥｎｄ８４２を関連付ける（Ｓ６１９７）。

以上の処理によって、ＦａｘＴｘ１のオブジェクト構成は、図３１に示されるようなもの（ＦａｘＴｘ２）に更新される。

ところで、図３６において、ＡｓｐｅｃｔＳＭ８５０にはＦａｘＴｘ１の状態遷移情報１１００（図３２及び図３３）に対する変更内容が記述されていると説明した。しかし、上記のように、ＦａｘＴｘ１オブジェクト７１４ａは、ＡｓｐｅｃｔＳＭ８５０に基づいて状態遷移情報１１００を書き換えるのではなく、ＦａｘＴｘ１を構成するオブジェクトを変更することで拡張処理を実現する。ＦａｘＴｘ１は、状態遷移情報１１００に基づいてそのオブジェクトが構築されたものである。したがって、状態遷移情報１１００に対する変更内容が記述されたＡｓｐｅｃｔＳＭ８５０は、そのままＦａｘＴｘ１のオブジェクト構成に適用することができるのである。なお、ＡｓｐｅｃｔＳＭ８５０に基づいて状態遷移情報１１００を更新し、更新された状態遷移情報１１００に基づいてＦａｘＴｘ１（厳密には、ＦａｘＴｘ２に更新されたもの）を再構築してもよい。但し、この場合、再構築の前にＦａｘＴｘ１を構成するオブジェクト群が破棄されるため、ＦａｘＴｘ１を利用中のアプリケーション等との参照関係が破壊されてしまう。したがって、本実施の形態のように、オブジェクト群を再構築するのではなく、既存のオブジェクト構成を変更する方が好適である。

なお、上記のように、拡張処理後は、ＦａｘＴｘ１とＦａｘＴｘ２とは、スイッチ７７０を切り替えることにより容易に切り替えが可能である。したがって、ＦａｘＴｘ１からＦａｘＴｘ２への更新後、再度ＦａｘＴｘ２からＦａｘＴｘ１に戻したい場合は、スイッチ７７０を切り替えることにより実現すればよい。すなわち、Ｉｄｌｅ状態オブジェクト７６１Ｓが参照可能なフラグ変数の値を更新すればよい。また、ＦａｘＴｘ２からＦａｘＴｘ１への更新指示が記述されたＡｓｐｅｃｔＳＭに基づいて、ＦａｘＴｘ２からＦａｘＴｘ１への更新を実現してもよい。この場合スイッチ７７０を切り替えるタイミングは、当該ＡｓｐｅｃｔＳＭに記述されたタイミングで行われる。

上述したように、本実施の形態では、ＡｓｐｅｃｔＳＭ８５０には、拡張部分が非アクティブなタイミングでＦａｘＳｅｒｖｉｃｅ７１４の拡張が行われるような拡張指示が記述されている。そして、かかるＡｓｐｅｃｔＳＭ８５０に従って、拡張部分が非アクティブなときに拡張が実行される。したがって、本実施の形態におけるＦａｘＳｅｒｖｉｃｅ７１４は、当該ＦａｘＳｅｒｖｉｃｅ７１４の実行中にその振る舞いの拡張を実行することができる。また、振る舞いの拡張にあたり、オブジェクト群が再構築されるわけではないので、当該ＦａｘＳｅｒｖｉｃｅ７１４の参照側との参照関係が破壊されることなく、動的にその振る舞いを拡張することが可能となっている。よって、融合機１０１を再起動することなくＦａｘＳｅｒｖｉｃｅ７１４の振る舞いは拡張され得る。

４）ＯＳＧｉ
図３８は、ＳｅｒｖｉｃｅＲｅｇｉｓｔｒｙ８０１について説明するためのクラス図である。ＳｅｒｖｉｃｅＲｅｇｉｓｔｒｙ８０１は、ＯＳＧｉフレームワーク４０３を構成するクラスである。サービス提供側であるＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１は、自己が提供するサービス内容をＳｅｒｖｉｃｅＲｅｇｉｓｔｒｙ８０１に登録（Ｓ３０１）し、サービス要求側であるユーザアプリ５０１は、自己が要求するサービス内容をＳｅｒｖｉｃｅＲｅｇｉｓｔｒｙ８０１から検索（Ｓ３０２）する。これによって、ユーザアプリ５０１は、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１にサービスを要求（Ｓ３０３）して、ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ６０１は、ユーザアプリ５０１にサービスを提供（Ｓ３０４）する。

図３９は、状態遷移モデルのバンドル化手順について説明するためのデータ図である。状態遷移モデルは、振る舞いと部品に分離されて設計される。振る舞いはＸＭＩ言語にて記述されて、部品はＪａｖａ（登録商標）言語にて記述される。ＸＭＩ言語によるコードとＪａｖａ（登録商標）言語によるコードはＯＳＧｉによるバンドル化手順に従ってバンドル化される。バンドルには、マニフェストファイル８０２が同梱される。マニフェストファイル８０２には、バンドルにとって必要な情報が格納される。

図４０・図４１は、ＣＳＣ４２１について説明するための図である。融合機１０１には他機のＯＳＧｉサービスプラットフォームを自機のＯＳＧｉサービスプラットフォームと同様に処理するためのＣＳＣ４２１が実装されている。ＣＳＣ４２１の実装態様は、図６に示す通りである。

図４０は他機が融合機１０１である場合を表し、図４１は他機がＰＣ８０３である場合を表す。図４０・図４１に示す通り、自機のＣＳＣ４２１と他機のＣＳＣ４２１の仲介によって、自機のＳＡＳＭａｎａｇｅｒ５１１と他機のＳＡＳＭａｎａｇｅｒ５１１の連携が実現される。

本発明の実施例に該当する融合機を表す。図１の融合機に係るハードウェア構成図である。図１の融合機に係る外観図である。オペレーションパネルを表す。図１のＣＳＤＫアプリとＪＳＤＫアプリのソフトウェア構成図である。図１の融合機におけるＯＳＧｉについて説明するための図である。図１のＪＳＤＫアプリとＪＳＤＫプラットフォームのクラス図である。ＪＳＤＫシステムの起動処理を説明するための図である。ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅについて説明するためのクラス図である。ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅの動作の説明図である。ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅの動作の具体例の説明図である。ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅの振る舞い変更処理について概念的に説明するための図である。ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅの振る舞いの動的な変更を実現するクラス群を説明するためのクラス図である。ＰｒｉｎｔＳｅｒｖｉｃｅのオブジェクト構成を表す図である。ＰｒｉｎｔＳｅｒｖｉｃｅのオブジェクト構成の構築処理を説明するためのシーケンス図である。ＰｒｉｎｔＳｅｒｖｉｃｅの状態遷移情報の定義例を示す図である。ＰｒｉｎｔＳｅｒｖｉｃｅの状態遷移情報の定義例を示す図である。ＰｒｉｎｔＳｅｒｖｉｃｅの振る舞い変更処理を説明するためのシーケンス図である。ＰｒｉｎｔＳｅｒｖｉｃｅの振る舞い変更処理を説明するためのシーケンス図である。ＰｒｉｎｔＳｅｒｖｉｃｅの振る舞いの変更内容が記述されたＡｓｐｅｃｔＳＭの記述例を示す図である。ＭｏｄｉｆｙＳｅｒｖｉｃｅについて説明するためのクラス図である。ＭｏｄｉｆｙＳｅｒｖｉｃｅについて説明するためのクラス図である。ＭｏｄｉｆｙＳｅｒｖｉｃｅによるＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅの変更処理を説明するためのシーケンス図である。Ｆａｘ送信アプリに対応させて登録されたＡｓｐｅｃｔＳＭの記述例を示す図である。ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌによるイベントの通知方式について説明するための図である。ＥｘｔｅｎｄＳｅｒｖｉｃｅについて説明するためのクラス図である。ＥｘｔｅｎｄＳｅｒｖｉｃｅの動作の概要を説明するための図である。ＦａｘＴｘ１やＦａｘＴｘ２の状態遷移モデルである。ＦａｘＳｅｒｖｉｃｅに関するプラグイン処理を説明するための図である。ＦａｘＴｘ１のオブジェクト構成を表す図である。ＦａｘＴｘ２のオブジェクト構成を表す図である。ＦａｘＴｘ１の状態遷移情報の定義例を示す図である。ＦａｘＴｘ１の状態遷移情報の定義例を示す図である。ＦａｘＳｅｒｖｉｃｅの拡張処理を説明するためのシーケンス図である。ＳＤカード内の追加モジュールの構成例を示す図である。ＦａｘＳｅｒｖｉｃｅの拡張内容が記述されたＡｓｐｅｃｔＳＭの記述例を示す図である。ＦａｘＴｘ１のオブジェクト構成の更新処理を説明するためのシーケンス図である。ＳｅｒｖｉｃｅＲｅｇｉｓｔｒｙについて説明するためのクラス図である。状態遷移モデルのバンドル化手順について説明するためのデータ図である。ＣＳＣについて説明するための図（同機種の場合）である。ＣＳＣについて説明するための図（別機種の場合）である。

符号の説明

１０１融合機
１１１ハードウェア
１１２ソフトウェア
１１３融合機起動部
１２１撮像部
１２２印刷部
１２３その他のハードウェア
１３１アプリケーション
１３２プラットフォーム
１３３アプリケーションプログラムインタフェース
１３４エンジンインタフェース
１３５仮想アプリケーションサービス
１４１コピーアプリ
１４２プリンタアプリ
１４３スキャナアプリ
１４４ファクシミリアプリ
１４５ネットワークファイルアプリ
１４６ＣＳＤＫアプリ
１４７ＪＳＤＫアプリ
１４８ＪＳＤＫプラットフォーム
１５１コントロールサービス
１５２システムリソースマネージャ
１５３ハンドラ
１６１ネットワークコントロールサービス
１６２ファクシミリコントロールサービス
１６３デリバリコントロールサービス
１６４エンジンコントロールサービス
１６５メモリコントロールサービス
１６６オペレーションパネルコントロールサービス
１６７サーティフィケーションコントロールサービス
１６８ユーザディレクトリコントロールサービス
１６９システムコントロールサービス
１７１ファクシミリコントロールユニットハンドラ
１７２イメージメモリハンドラ
２０１コントローラ
２０２オペレーションパネル
２０３ファクシミリコントロールユニット
２１１ＣＰＵ
２１２ＡＳＩＣ
２２１ＮＢ
２２２ＳＢ
２３１ＭＥＭ−Ｐ
２３２ＭＥＭ−Ｃ
２３３ＨＤＤ
２３４メモリカードスロット
２３５メモリカード
２４１ＮＩＣ
２４２ＵＳＢデバイス
２４３ＩＥＥＥ１３９４デバイス
２４４セントロニクスデバイス
３０１原稿セット部
３０２給紙部
３０３排紙部
３１１タッチパネル
３１２テンキー
３１３スタートボタン
３１４リセットボタン
３１５機能キー
３１６初期設定ボタン
３２１ＡＤＦ
３２２フラットベッド
３２３フラットベッドカバー
４０１ＯＳＧｉアプリ
４０２ＯＳＧｉサービス
４０３ＯＳＧｉフレームワーク
４０４ＢｕｎｄｌｅＡｃｔｉｖａｔｏｒ
４１１ＳＡＳ
４２１ＣＳＣ
５０１ユーザアプリ
５１１ＳＡＳＭａｎａｇｅｒ
５１２ＳｃｒｅｅｎＭａｎａｇｅｒ
５２１ＪＳＤＫＥｎｖｉｒｏｎｍｅｎｔ
５３１ＸｌｅｔＭａｎａｇｅｒ
５３２ＭｕｌｔｉＸｌｅｔＭａｎａｇｅｒ
５４１ＳｅｎｄＭａｎａｇｅｒ
５４２ＥｖｅｎｔＭａｎａｇｅｒ
５４３ＳｙｓｔｅｍＥｖｅｎｔＭａｎａｇｅｒ
５４４ＰａｎｅｌＭａｎａｇｅｒ
５４５ＩｎｓｔａｌｌＭａｎａｇｅｒ
５４６Ｓｅｒｖｅｒ／ＣｌｉｅｎｔＭａｎａｇｅｒ
５４７ＳｅｒｖｉｃｅＭａｎａｇｅｒ
５５１ＪＳＤＫＡＰＩ
５５２ＪＳＤＫＡＰＩ
５５３ＪＳＤＫＳｅｓｓｉｏｎ
５５４ＮａｔｉｖｅＪＳＤＫＳｅｓｓｉｏｎ
５５５ＣＶＭ
６０１ＦｕｎｃｔｉｏｎＳｅｒｖｉｃｅ
６０２ＭｏｄｉｆｙＳｅｒｖｉｃｅ
６０３ＥｘｔｅｎｄＳｅｒｖｉｃｅ
６１１ＦｕｎｃｔｉｏｎＡＰＩ
６１２ＭｏｄｉｆｙＡＰＩ
６１３ＥｘｔｅｎｄＡＰＩ
６２１Ｃ／ＪＡＰＩ
７０１ＡｄａｐｔｉｖｅＦｕｎｃｔｉｏｎ
７０２ＡｄａｐｔｉｖｅＢｅｈａｖｉｏｒ
７１１ＣｏｐｙＳｅｒｖｉｃｅ
７１２ＰｒｉｎｔＳｅｒｖｉｃｅ
７１３ＳｃａｎＳｅｒｖｉｃｅ
７１４ＦａｘＳｅｒｖｉｃｅ
７２１ＳＡＳＳｅｒｖｉｃｅ
７３１ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌ
７３２ＭｏｄｉｆｙＡｇｅｎｔ
７３３ＰｌｕｇｉｎＡｇｅｎｔ
７４１Ｉｄｌｅ状態
７４２Ｐｒｉｎｔ状態
７４３印刷開始イベント
７４４印刷終了イベント
７４６ガード条件オブジェクト
７４１ＳＩｄｌｅ状態オブジェクト
７４２ＳＰｒｉｎｔ状態オブジェクト
７４３Ｔ印刷開始オブジェクト
７４４Ｔ印刷終了オブジェクト
７５１Ｉｄｌｅ状態
７５２ＦａｘＳｅｎｄ状態
７５３送信開始イベント
７５４送信終了イベント
７６０初期状態
７６１Ｉｄｌｅ状態
７６２Ｓｅｎｄ状態
７６３Ｔｒａｎｓｆｏｒｍ状態
７６４終期状態
８０１ＳｅｒｖｉｃｅＲｅｇｉｓｔｒｙ
８０２マニフェストファイル
８０３ＰＣ
８１０、８２０ＡｓｐｅｃｔＳＭ
９００、１１００状態遷移情報
１０００ＳｔａｔｅＭａｃｈｉｎｅＰｏｏｌクラス
１００１ＳｔａｔｅＭａｃｈｉｎｅクラス
１００２ＳｔａｔｅＶｅｒｔｅｘクラス
１００３Ｔｒａｎｓｉｔクラス
１００３ａＥｖｅｎｔインタフェース
１００３ｂＧｕａｒｄインタフェース
１００３ｃＡｃｔｉｏｎインタフェース
１００４Ｓｔａｔｅクラス
１００４ａＩＳｔａｔｅインタフェース
１００４ｂＡｃｔｉｖｉｔｙインタフェース
１００５ＰｓｅｕｄｏＳｔａｔｅクラス
１００６ＩｎｉｔｉａｌＳｔａｔｅクラス
１００７ＦｉｎａｌＳｔａｔｅクラス
１００８ＰｌｕｇｉｎＡｇｅｎｔクラス
１００９ＭｏｄｉｆｙＡｇｅｎｔクラス

Claims

第一のプログラムにサービスを提供し、互いに排他的に機器を動作させる複数のモジュールによって構成される第二のプログラムを備える機器であって、
前記各モジュールは、前記第二のプログラムの状態遷移における各状態又は前記各状態間の状態遷移に対応し、
前記状態遷移に対応するモジュールの識別情報と、当該状態遷移の条件と、当該条件を当該モジュールに対して設定する契機を示す情報とが指定された変更情報を記憶する変更情報記憶手段と、
前記第一のプログラムが当該機器に実行させる前記第二のプログラムに対するサービスの提供要求に応じ、当該提供要求が前記契機を示す情報として前記変更情報に指定されている場合に、当該変更情報に指定されている前記条件を、当該変更情報に指定されている前記識別情報に係る前記モジュールに設定する変更手段とを有し、
前記第二のプログラムは、当該第二のプログラムの状態遷移が発生する際は、当該状態遷移に対応する前記モジュールに対して設定されている条件に基づいて、当該状態遷移の可否を当該機器に判定させる機器。
前記変更情報には、少なくとも前記識別情報に係るモジュールが当該機器を動作させていないときが前記条件の設定のタイミングとして指定されていることを特徴とする請求項１記載の機器。
前記変更情報には、当該機器を動作させているモジュールを特定することにより前記条件の設定のタイミングが指定されており、
前記変更手段は、前記条件の設定のタイミングとして指定されたモジュールが当該機器を動作させているときに、前記条件の設定のタイミングであると判定することを特徴とする請求項２記載の機器。
前記変更手段は、前記条件の設定のタイミングであると判定するまで前記条件の設定を待機することを特徴とする請求項２又は３記載の機器。
前第変更手段は、前記変更情報に基づいて、前記状態遷移に対してガード条件を設定することを特徴とする請求項１乃至４いずれか一項記載の機器。
前記モジュールは、オブジェクトであることを特徴とする請求項１乃至５いずれか一項記載の機器。
前記契機を示す情報は、当該情報に指定されたメソッドが呼び出されたことを示すことを特徴とする請求項１乃至６いずれか一項記載の機器。
第一のプログラムにサービスを提供し、互いに排他的に機器を動作させる複数のモジュールによって構成される第二のプログラムを備える機器によって実行される情報処理方法であって、
前記各モジュールは、前記第二のプログラムの状態遷移における各状態又は前記各状態間の状態遷移に対応し、
前記第一のプログラムが当該機器に実行させる前記第二のプログラムに対するサービスの提供要求に応じ、変更情報記憶手段が記憶する、前記状態遷移に対応するモジュールの識別情報と、当該状態遷移の条件と、当該条件を当該モジュールに対して設定する契機を示す情報とが指定された変更情報を参照し、当該提供要求が前記契機を示す情報として前記変更情報に指定されている場合に、当該変更情報に指定されている前記条件を、当該変更情報に指定されている前記識別情報に係る前記モジュールに設定する変更手順を有し、
前記第二のプログラムは、当該第二のプログラムの状態遷移が発生する際は、当該状態遷移に対応する前記モジュールに対して設定されている条件に基づいて、当該状態遷移の可否を当該機器に判定させる情報処理方法。
前記変更情報には、少なくとも前記識別情報に係るモジュールが当該機器を動作させていないときが前記条件の設定のタイミングとして指定されていることを特徴とする請求項８記載の情報処理方法。
前記変更情報には、当該機器を動作させているモジュールを特定することにより前記条件の設定のタイミングが指定されており、
前記変更手順は、前記条件の設定のタイミングとして指定されたモジュールが当該機器を動作させているときに、前記条件の設定のタイミングであると判定することを特徴とする請求項９記載の情報処理方法。
前記変更手順は、前記条件の設定のタイミングであると判定するまで前記条件の設定を待機することを特徴とする請求項９又は１０記載の情報処理方法。
前第変更手順は、前記変更情報に基づいて、前記状態遷移に対してガード条件を設定することを特徴とすることを特徴とする請求項８乃至１１いずれか一項記載の情報処理方法。
前記モジュールは、オブジェクトであることを特徴とする請求項８乃至１２いずれか一項記載の情報処理方法。
請求項８乃至１３いずれか一項記載の情報処理方法をコンピュータに実行させるための情報処理プログラム。
請求項１４記載の情報処理プログラムを記録したコンピュータ読取可能な記録媒体。