"互いに排他的に動作する複数のモジュールの接続によって構成されるプログラムを実行する機器であって、前記プログラムの更新情報の入力を受け付ける入力手段と、前記プログラムの動作状態が、前記更新情報において指定されている更新のタイミングに相当するか否かを判定するタイミング判定手段と、前記タイミング判定手段によって前記更新のタイミングであると判定されたときに、前記更新情報に従って、前記複数のモジュールの接続関係を変更する変更手段とを有し、前記更新情報には、動作中のモジュールを特定することにより前記更新のタイミングが指定されており、前記判定手段は、前記更新のタイミングとして指定されたモジュールが動作中であるときに、当該更新のタイミングであると判定することを特徴とする機器。前記変更手段は、前記更新情報に指定されている変更箇所に対応するモジュールの接続関係を変更することを特徴とする請求項1記載の機器。前記判定手段によって前記更新のタイミングであると判定されるまで、前記変更手段による変更を待機することを特徴とする請求項1又は2記載の機器。前記変更手段は、前記更新情報に新たなモジュールの追加が指定されているときは、当該新たなモジュールを生成し、当該新たなモジュールも含めて複数の前記モジュールの接続関係を変更することを特徴とする請求項1乃至3いずれか一項記載の機器。前記プログラムを構成する各モジュールは、当該プログラムの状態遷移における各状態に対応することを特徴とする請求項1乃至4いずれか一項記載の機器。互いに排他的に動作する複数のモジュールの接続によって構成されるプログラムを実行する機器と情報処理装置とを含む情報処理システムであって、前記機器は、前記プログラムの更新情報を前記情報処理装置より取得する取得手段と、前記プログラムの動作状態が、前記更新情報において指定されている更新のタイミングに相当するか否かを判定するタイミング判定手段と、前記タイミング判定手段によって前記更新のタイミングであると判定されたときに、前記更新情報に従って、前記複数のモジュールの接続関係を変更する変更手段とを有し、前記更新情報には、動作中のモジュールを特定することにより前記更新のタイミングが指定されており、前記判定手段は、前記更新のタイミングとして指定されたモジュールが動作中であるときに、当該更新のタイミングであると判定することを特徴とする情報処理システム。互いに排他的に動作する複数のモジュールの接続によって構成されるプログラムを実行する機器によって実行される情報処理方法であって、前記プログラムの更新情報の入力を受け付ける入力手順と、前記プログラムの動作状態が、前記更新情報において指定されている更新のタイミングに相当するか否かを判定するタイミング判定手順と、前記タイミング判定手順において前記更新のタイミングであると判定されたときに、前記更新情報に従って、前記複数のモジュールの接続関係を変更する変更手順とを有し、前記更新情報には、動作中のモジュールを特定することにより前記更新のタイミングが指定されており、前記判定手順は、前記更新のタイミングとして指定されたモジュールが動作中であるときに、当該更新のタイミングであると判定することを特徴とする情報処理方法。前記変更手順は、前記更新情報に指定されている変更箇所に対応するモジュールの接続関係を変更することを特徴とする請求項7記載の情報処理方法。前記判定手順において前記更新のタイミングであると判定されるまで、前記変更手順による変更を待機することを特徴とする請求項7又は8記載の情報処理方法。前記変更手順は、前記更新情報に新たなモジュールの追加が指定されているときは、当該新たなモジュールを生成し、当該新たなモジュールも含めて複数の前記モジュールの接続関係を変更することを特徴とする請求項7乃至9いずれか一項記載の情報処理方法。前記プログラムを構成する各モジュールは、当該プログラムの状態遷移における各状態に対応することを特徴とする請求項7乃至10いずれか一項記載の情報処理方法。請求項7乃至11いずれか一項記載の情報処理方法をコンピュータに実行させるための情報処理プログラム。請求項12記載の情報処理プログラムを記録したコンピュータ読取可能な記録媒体。近年、複合機や融合機には様々なプログラムが実装される。そして、これらの機器ではこれらのプログラムをアップデートすべき場面も出て来る。機器の機能を拡張する場合やプログラムのバグを修正する場合などである。従来の複合機や融合機では、プログラムのアップデート処理は機器の起動時に実施されるのが通例であった。よって、プログラムをアップデートするには機器を再起動しなければならないという問題点があった。そして、機器の再起動を手動式にすれば、再起動操作をユーザに強制する事になりユーザに操作の負担を掛ける事になるし、だからと言って、機器の再起動を自動式にすれば、再起動処理がユーザの知らぬ間に実施される事になりユーザに心理的な抵抗感が生じる事になる。本発明は、種々のプログラムが実装される機器に関して、機器に実装された種々のプログラムのアップデート処理更新処理に関する新たな手法を提案することを課題とする。そこで上記課題を解決するため、本発明は、互いに排他的に動作する複数のモジュールの接続によって構成されるプログラムを実行する機器であって、前記プログラムの更新情報の入力を受け付ける入力手段と、前記プログラムの動作状態が、前記更新情報において指定されている更新のタイミングに相当するか否かを判定するタイミング判定手段と、前記タイミング判定手段によって前記更新のタイミングであると判定されたときに、前記更新情報に従って、前記複数のモジュールの接続関係を変更する変更手段とを有し、前記更新情報には、動作中のモジュールを特定することにより前記更新のタイミングが指定されており、前記判定手段は、前記更新のタイミングとして指定されたモジュールが動作中であるときに、当該更新のタイミングであると判定することを特徴とする。このような機器によれば、種々のプログラムのアップデート処理更新処理に関する新たな手法を提案することができる。本発明は、種々のプログラムが実装される機器に関して、機器に実装された種々のプログラムのアップデート処理更新処理に関する新たな手法を提案するものである。図1は、本発明の実施例に該当する融合機101を表す。図1の融合機101は、種々のハードウェア111と、種々のソフトウェア112と、融合機起動部113により構成される。融合機101のハードウェア111としては、撮像部121と、印刷部122と、その他のハードウェア123が存在する。撮像部121は、読取原稿から画像画像データを読み取るためのハードウェアである。印刷部122は、画像画像データを印刷用紙に印刷するためのハードウェアである。融合機101のソフトウェア112としては、種々のアプリケーション131と、種々のプラットフォーム132が存在する。これらのプログラムは、UNIX登録商標等のOSオペレーティングシステムによりプロセス単位で並列的に実行される。アプリケーション131としては、コピー用のアプリケーションであるコピーアプリ141、プリンタ用のアプリケーションであるプリンタアプリ142、スキャナ用のアプリケーションであるスキャナアプリ143、ファクシミリ用のアプリケーションであるファクシミリアプリ144、ネットワークファイル用のアプリケーションであるネットワークファイルアプリ145が存在する。アプリケーション131は、専用のSDKソフトウェア開発キットを使用して開発することができる。SDKを使用して開発したアプリケーション131をSDKアプリと呼ぶ。専用のSDKとしては、C言語でアプリケーション131を開発するためのCSDKや、Java登録商標言語でアプリケーション131を開発するためのJSDKが提供される。CSDKを使用して開発したアプリケーション131をCSDKアプリと呼び、JSDKを使用して開発したアプリケーション131をJSDKアプリと呼ぶ。図1の融合機101にも、CSDKアプリ146と、JSDKアプリ147が存在する。図1の融合機101にはさらに、Java登録商標言語で記述されたJSDKアプリ147とC言語で記述された他のソフトウェア112との仲介を行うソフトウェア112として、JSDKプラットフォーム148が存在する。プラットフォーム132としては、種々のコントロールサービス151、システムリソースマネージャ152、種々のハンドラ153が存在する。コントロールサービス151としては、ネットワークコントロールサービスNCS161、ファクシミリコントロールサービスFCS162、デリバリコントロールサービスDCS163、エンジンコントロールサービスECS164、メモリコントロールサービスMCS165、オペレーションパネルコントロールサービスOCS166、サーティフィケーションコントロールサービスCCS167、ユーザディレクトリコントロールサービスUCS168、システムコントロールサービスSCS169が存在する。ハンドラ153としては、ファクシミリコントロールユニットハンドラFCUH171、イメージメモリハンドラIMH172が存在する。NCS161のプロセスは、ネットワーク通信の仲介を行う。FCS162のプロセスは、ファクシミリのAPIを提供する。DCS163のプロセスは、蓄積文書の配信処理に関する制御を行う。ECS164のプロセスは、撮像部121や印刷部122に関する制御を行う。MCS165のプロセスは、メモリやハードディスクドライブに関する制御を行う。OCS166のプロセスは、オペレーションパネルに関する制御を行う。CCS167のプロセスは、認証処理や課金処理に関する制御を行う。UCS168のプロセスは、ユーザ情報の管理に関する制御を行う。SCS169のプロセスは、システムの管理に関する制御を行う。アプリケーション131とプラットフォーム132の仲介を行うソフトウェア112として、仮想アプリケーションサービスVAS135が存在する。VAS135は、アプリケーション131をクライアントとするサーバプロセスとして動作すると共に、プラットフォーム132をサーバとするクライアントプロセスとして動作する。VAS135は、アプリケーション131から見てプラットフォーム132を隠蔽するラッピング機能を備え、プラットフォーム132のバージョンアップに伴うバージョン差を吸収する役割等を担う。融合機起動部113は、融合機101の電源投入時に最初に実行される。これにより、UNIX登録商標等のOSが起動され、アプリケーション131やプラットフォーム132が起動される。これらのプログラムは、ハードディスクドライブやメモリカードに蓄積されており、ハードディスクドライブやメモリカードから再生されて、メモリに起動されることになる。図2は、図1の融合機101に係るハードウェア構成図である。融合機101のハードウェア111としては、コントローラ201と、オペレーションパネル202と、ファクシミリコントロールユニットFCU203と、撮像部121と、印刷部122が存在する。コントローラ201は、CPU211、ASIC212、NB221、SB222、MEM-P231、MEM-C232、HDDハードディスクドライブ233、メモリカードスロット234、NICネットワークインタフェースコントローラ241、USBデバイス242、IEEE1394デバイス243、セントロニクスデバイス244により構成される。CPU211は、種々の情報処理用のICである。ASIC212は、種々の画像処理用のICである。NB221は、コントローラ201のノースブリッジである。SB222は、コントローラ201のサウスブリッジである。MEM-P231は、融合機101のシステムメモリである。MEM-C232は、融合機101のローカルメモリである。HDD233は、融合機101のストレージである。メモリカードスロット234は、メモリカード235をセットするためのスロットである。NIC241は、MACアドレスによるネットワーク通信用のコントローラである。USBデバイス242は、USB規格の接続端子を提供するためのデバイスである。IEEE1394デバイス243は、IEEE1394規格の接続端子を提供するためのデバイスである。セントロニクスデバイス244は、セントロニクス仕様の接続端子を提供するためのデバイスである。オペレーションパネル202は、オペレータが融合機101に入力を行うためのハードウェア操作部であると共に、オペレータが融合機101から出力を得るためのハードウェア表示部である。図3は、図1の融合機101に係る外観図である。図3には、撮像部121の位置と、印刷部122の位置と、オペレーションパネル202の位置が図示されている。図3には更に、読取原稿のセット先となる原稿セット部301と、印刷用紙の給紙先となる給紙部302と、印刷用紙の排紙先となる排紙部303が図示されている。オペレーションパネル202は、図4のように、タッチパネル311と、テンキー312と、スタートボタン313と、リセットボタン314と、機能キー315と、初期設定ボタン316により構成される。タッチパネル311は、タッチ操作で入力を行うためのハードウェアタッチ操作部であると共に、画面表示で出力を得るためのハードウェア画面表示部である。テンキー312は、キーボタン操作で数字入力を行うためのハードウェアである。スタートボタン313は、ボタン操作でスタート操作を行うためのハードウェアである。リセットボタン314は、ボタン操作でリセット操作を行うためのハードウェアである。機能キー315は、キーボタン操作でCSDKアプリ146やJSDKアプリ147による操作画面を表示させるためのハードウェアである。初期設定ボタン316は、ボタン操作で初期設定画面を表示させるためのハードウェアである。原稿セット部301は、ADF自動原稿搬送装置321と、フラットベッド322と、フラットベッドカバー323により構成される。給紙部302は、4個の給紙トレイにより構成される。排紙部303は、1個の排紙トレイにより構成される。CSDK/JSDK/OSGi図5は、図1のCSDKアプリ146とJSDKアプリ147のソフトウェア構成図である。CSDKアプリ146は、C言語のアプリケーションであり、それぞれプロセスとして実行される事になる。JSDKアプリ147は、Java登録商標言語のアプリケーションであり、それぞれスレッドとして実行される事になる。図1の融合機101には、CSDKアプリ146として、他のCSDKアプリ146の制御を行うSASSDKアプリケーションサービス411が存在し、JSDKアプリ147として、他のJSDKアプリ147の制御を行うSASManagerSDKアプリケーションサービスマネージャ511が存在する。CSDKアプリ146の方はプロセスとして実行されてJSDKアプリ147の方はスレッドとして実行されるので、CSDKアプリ146用のアプリケーション管理機構とJSDKアプリ147用のアプリケーション管理機構が別個に存在するのである。SAS411とSASManager511はそれぞれ、CSDKアプリ146とJSDKアプリ147の起動制御,起動解除制御,インストール制御,アンインストール制御,アップデート制御等を行う。さて、SAS411は、CSDKアプリ146の制御を行う事ができるだけではなく、SASManager511を介してJSDKアプリ147の制御を行う事もできる。SAS411は、CSDKアプリ146については直接的にその制御を行う事ができると共に、JSDKアプリ147についてはSASManager511を介して間接的にその制御を行う事ができるのである。このように、CSDKアプリ146用のアプリケーション管理機構とJSDKアプリ147用のアプリケーション管理機構は、SASManager511を制御できる機能をSAS411に具備させると言う形で統合的に構成されている。融合機101のソフトウェアの根幹部分はC言語によるので、SDKアプリを制御する機能を同じくC言語によるSAS411に集中しておくのが好適なのである。図6は、図1の融合機101におけるOSGiOpenServiceGatewayinitiativeサービスプラットフォームについて説明するための図である。OSGiサービスプラットフォームは、OSGiアライアンスによる標準化技術であり、Java登録商標言語に基づいたオープンなソフトウェア部品化技術である。OSGiサービスプラットフォームが実装された機器では、Java登録商標言語のソフトウェアはバンドルと言うソフトウェア部品の形で実装される。そして、該機器の諸機能はバンドルをもって構成する事ができると共に、該機器の諸機能のアップデートやカスタマイズやメンテナンスはバンドルのダウンロードをもって実現する事ができる。図1の融合機101には、Java登録商標言語のソフトウェアとして、JSDKアプリ147と、JSDKプラットフォーム148と、OSGi用のアプリケーションであるOSGiアプリ401と、OSGi用のサービスであるOSGiサービス402と、バンドルの管理バンドルのライフサイクルやデータの管理等を行うOSGiフレームワーク403が存在する。さて、OSGiアプリ401とJSDKアプリ147に関して、OSGiアプリ401はバンドル化された状態で融合機101に実装するものとするが、JSDKアプリ147はバンドル化されていない状態で融合機101に実装するものとする。理由は、JSDKアプリ147をバンドル化して実装する負担をJSDKアプリ147のベンダに課さないようにするためである。その代わり、JSDKアプリ147をバンドル化するBundleActivator404がJSDKプラットフォーム148に存在している。そして、OSGiフレームワーク403は、バンドル化された状態で融合機101に実装されたバンドルOSGiアプリ401の管理を行うと共に、バンドル化されていない状態で融合機101に実装されてBundleActivator404によってバンドル化されるバンドルJSDKアプリ147の管理を行う事になる。このようにして、OSGiアプリ401用のアプリケーション管理機構とJSDKアプリ147用のアプリケーション管理機構は、OSGiフレームワーク403とBundleActivator404を併設すると言う形で統合的に構成されているのである。これにより、Java登録商標言語のアプリケーションの管理先の一元化が実現されている。なお、OSGiフレームワーク403は、当然の事ながら、OSGiサービス402を構成するバンドルの管理や、JSDKプラットフォーム148を構成するバンドルの管理も行う。Java登録商標言語のソフトウェアの管理先の一元化が実現されていると言える。そして、OSGiアプリ401はここではServletかJSPであるものとする。そして、JSDKアプリ147はここではXletであるものとする。なお、JSDKアプリ147についても、バンドル化された状態で実装するものとしてもよい。さらに、JSDKアプリ147については、バンドル化された状態で実装してもバンドル化されていない状態で実装してもどちらでもよいものとしてもよい。バンドル化された状態で実装されるJSDKアプリ147については、BundleActivator404によるバンドル化は不要である。更新処理以下、バンドルとして管理されるJava登録商標言語のソフトウェアの更新処理について説明する。先ず、図1の融合機101内のJSDKプラットフォームバンドルサービス148の更新処理について説明して、次に、図1の融合機101内のJSDKアプリバンドルアプリ147の更新処理について説明する。なお、当該融合機101内のJSDKプラットフォームバンドルサービス148やJSDKアプリバンドルアプリ147の更新処理は当該融合機101内のSASManager511により実行される。図7は、バンドルサービス148のオブジェクト構成の具体例を表す。図7のバンドルサービス148は、4個のオブジェクトモジュールA/B/C/Dにより構成されている。さて、オブジェクトA/B/C/Dが相互に関連している場合には、バンドルサービス148の実行中動作中にオブジェクトAをオブジェクトAに入れ替える事は困難である。オブジェクトAが提供するサービスをオブジェクトB/C/Dが利用すべく、オブジェクトAをオブジェクトB/C/Dが参照している可能性があるからである。よって、オブジェクトAをオブジェクトAに入れ替える場合には、オブジェクトAを入れ替える旨をオブジェクトB/C/Dに通知し、オブジェクトB/C/DがオブジェクトAの参照をオブジェクトAの参照に切り替える必要がある。したがって、オブジェクトAをオブジェクトAに入れ替えるなど、バンドルサービス148の更新処理をバンドルサービス148の動作中にバンドルサービス148のモジュール毎に実行するには、従来は融合機101の再起動処理が必要だった。しかしながら、融合機101は、バンドルサービス148の更新処理をバンドルサービス148の動作中にバンドルサービス148のモジュール毎に実行するのに、融合機101の再起動処理を伴わずに実行する。よって、バンドルサービス148の更新処理を実施するのに、融合機101の再起動操作をユーザに強制する事もなくなるし、融合機101の再起動処理がユーザの知らぬ間に実施される事もなくなるのである。すなわち、融合機101は、バンドルサービス148の更新処理をバンドルサービス148の更新部分のオブジェクトがアクティブ状態ではないとき動作中でないときに実行する。これによって、融合機101は、再起動処理を伴わずに、バンドルサービス148の更新処理をバンドルサービス148の動作中にバンドルサービス148のモジュール毎に実行する事ができる。以下、バンドルサービス148の更新処理の具体例として、バンドルサービスFaxTx1がバンドルサービスFaxTx2に更新される様子について説明する。バンドルサービスFaxTx1は、画像データをFAX送信するサービスを提供するバンドルサービス148である。FaxTx2は、画像データをPDFからTIFFに変換してFAX送信するサービスを提供するバンドルサービス148である。図8はバンドルサービスFaxTx1の状態遷移図である。FaxTx1の状態としては、初期状態601、終期状態602、Idle状態603、Send状態604が存在する。Idle状態603は、FAX送信処理の待機中の状態である。Send状態604は、FAX送信処理を実行中の状態である。Idle状態603からSend状態604には、送信開始イベント611により遷移する。Send状態604から終期状態602には、送信終了イベント612により遷移する。図9はバンドルサービスFaxTx2の状態遷移図である。FaxTx2の状態としては、初期状態601、終期状態602、Idle状態603、Send状態604に加えて、Transform状態605が存在する。Transform状態605は、PDFからTIFFへの変換処理を実行中の状態である。Idle状態603からTransform状態605には、送信開始イベント611により遷移する。Transform状態605からSend状態604には、変換終了イベント613により遷移する。状態遷移図に基づいて、本実施の形態におけるバンドルサービス148は、図10に示されるようなクラス群によってモデル化されている。図10は、バンドルサービスを構成するクラス図の一例である。図10において、StateMachineクラス1001は、一つのバンドルサービス148を表現するクラスである。すなわち、バンドルサービスFaxTx1やFaxTx2を表現するオブジェクトは、SateMachineクラス1001のインスタンスStateMachineオブジェクトとして生成される。StateVertexクラス1002は、抽象クラスであり、状態遷移図において状態を表現するクラスのルートクラスに相当する。StateVertexクラス1002は、connectメソッド1002aや、reconnectメソッド1002b等のメソッドが定義されている。connectメソッド1002aは、遷移先の状態及びその状態遷移との接続を実行するメソッドである。状態遷移についてはTransitクラス1003によって表現される。したがって、より具体的には、connectメソッド1002aは、遷移先のStateVertexオブジェクト厳密にはそのサブクラスのオブジェクト。以下、総称する場合状態オブジェクトという。と、その状態遷移に対応するTransitオブジェクト以下、遷移オブジェクトという。との接続を実行するクラスである。ここでいう接続は、例えば、状態オブジェクト内に、遷移先の状態オブジェクトや、その遷移オブジェクトの識別情報ID、参照、又はポインタ等を保持することで実現される。reconnectメソッド1002bは、遷移先の変更を実行するメソッドである。なお、Trasitクラス1003には、インタフェースとしてEventインタフェース1003a、Guradインタフェース1003b、及びActionインタフェース1003c等が定義されている。Eventインタフェース1003aは、状態遷移の遷移イベントを実装するインタフェースである。Guardインタフェース1003bは、ガード条件を実装するインタフェースである。Actionインタフェース1003cは、状態遷移時に実行するアクションを実装するインタフェースである。StateVertexクラス1002のサブクラスとしては、Stateクラス1004及びPseudoStateクラス1005が定義されている。Stateクラス1004は、例えば、バンドルサービス148に応じて定義される状態を表現するクラスである。Stateクラス1004には、インタフェースとしてIStateインタフェース1004a及びActivityインタフェース1004b等が定義されている。IStateインタフェース1004aは、状態の入場時の処理入場処理及び退場時の処理退場処理を実装するインタフェースである。Activityインタフェース1004bは、状態にある間実行する処理を実装するインタフェースである。これらインタフェースは、クラスとして実装される。したがって、例えば、Activityインタフェース1004bの処理は、Activityクラスに実装される。PseudoSateクラス1005は、初期状態や終期状態等、その名の通り擬似的な状態を表現するクラスであり、そのサブクラスとしては初期状態を表現するInitialStateクラス1006及び終期状態を表現するFinalStateクラス1007等がある。上記クラス間の関係について説明する。StateMachineクラス1001は、StateVertexクラス1002を集約する。これは、一つのバンドルサービスは、一つ以上の状態を有することを表現したものである。StateVertexクラス1002は、Transitクラスを集約する。これは、状態と状態との間は遷移によって接続されることを表現したものである。以上のような、モデルに基づいて、バンドルサービスFaxTx1及びFaxTx2は、以下のようなオブジェクトによって構成される。図11はバンドルサービスFaxTx1のオブジェクト構成を表す。FaxTx1は、図8の状態遷移図に基づいて、初期状態オブジェクト701、終期状態オブジェクト702、Idle状態オブジェクト703、Send状態オブジェクト704、送信開始オブジェクト711T、送信処理オブジェクト712Aにより構成されている。また、図12はバンドルサービスFaxTx2のオブジェクト構成を表す。FaxTx2は、図9の状態遷移図に基づいて、初期状態オブジェクト701、終期状態オブジェクト702、Idle状態オブジェクト703、Send状態オブジェクト704、Transform状態オブジェクト705、送信開始オブジェクト711T、送信処理オブジェクト712A、変換処理オブジェクト713A、変換終了オブジェクト713Tにより構成されている。図11及び図12においてオブジェクト同士を連結する線分は、オブジェクト同士の参照関係を表す。遷移元の状態オブジェクトは遷移先の状態オブジェクトを参照している。なお、図中では状態オブジェクト間に遷移オブジェクトが接続されている場合がある。例えば、Idle状態オブジェクト703とSend状態オブジェクト704との間には送信開始オブジェクト711Tが接続されている。しかし、このことはIdle状態703が、Send状態オブジェクト704を参照していないことを示すものではない。Idle状態オブジェクト703は、Send状態オブジェクト703を参照すると共に、その状態遷移に対応する遷移オブジェクトとして送信開始オブジェクト711Tをも参照することを表現したものである。図11及び図12より、バンドルサービスFaxTx1からFaxTx2への更新処理とは、FaxTx1にTransform状態オブジェクト705や変換処理オブジェクト713Aや変換終了オブジェクト713Tと言った更新処理用のオブジェクトをFaxTx1に対して追加する事で実現できることが分かる。バンドルサービス148の更新処理の影響が顕著なオブジェクトが、バンドルサービス148の更新部分のオブジェクトである。バンドルサービス148の更新部分のオブジェクトとは、オブジェクトの入替部分やオブジェクトの追加部分バンドルサービス148の更新部分に連結するオブジェクトを意味する。図11から図12への更新処理では、バンドルサービス148の更新部分に相当するのがスイッチ721等の追加部分であり、バンドルサービス148の更新部分のオブジェクトに相当するのがSend状態オブジェクト704や送信開始オブジェクト711Tである。オブジェクトの状態は、サービスの授受を行うアクティブ状態とサービスの授受を行わない非アクティブ状態に分類される。バンドルサービス148の更新処理をバンドルサービス148の動作中に実行するには、バンドルサービス148の更新部分のオブジェクトがアクティブ状態ではないとき非アクティブ状態のときに実行すればよい。バンドルサービス148の動作中のオブジェクト同士のサービスの授受が更新処理により阻害されずに済むからである。よって、バンドルサービス148の更新処理をバンドルサービス148の更新部分のオブジェクトがアクティブ状態ではないときに実行するのである。なお、状態遷移図によるモデリングでは、一のオブジェクトがアクティブ状態のときは他のオブジェクトは非アクティブ状態に限定される。すなわち、各オブジェクトは互いに排他的に処理を実行する動作する。図13は、バンドルサービス148の更新処理に係るコラボレーション図である。同図の更新処理は、バンドルサービスFaxTx1をバンドルサービスFaxTx2に更新するものである。FaxTx1をFaxTx2に更新する旨の更新操作が融合機101又はクライアント端末801の操作画面で実施されると、FaxTx1をFaxTx2に更新する旨の更新要求がSAS411からSASManager511に送信S11される。次に、SASManager511では、FaxTx1からFaxTx2への更新処理を実施可能かどうかのチェックが実行S12される。次に、SASManager511では、更新処理用のモジュールを融合機101にインストール可能かどうかのチェックが実行S13される。続いて、SASManager511は、更新処理用のモジュールを融合機101にインストールS14する。続いて、SASManager511は、更新処理用のモジュールをアクティブ状態に遷移S15させる。続いて、SASManager511は、FaxTx1に更新処理用のモジュールを追加して、スイッチ721をFaxTx1側からFaxTx2側に切り替えて、FaxTx2を生成S16する。なお、更新処理が行われるタイミングは、更新処理用のモジュールに同梱されているAspectSM811と言うXMLファイルに記述されている。また、FaxTx1やFaxTx2とJSDKアプリ147との仲介制御は、JSDKプラットフォーム148を構成するProxyService822が実行する。FaxTx1からFaxTx2への更新処理について更に詳しく説明する。更新処処理自体の詳細説明の前に、図11に示されるFaxTx1のオブジェクト構成が構築される過程について説明する。図14は、バンドルサービスFaxTx1のオブジェクト構成の構築処理を説明するためのシーケンス図である。図14の処理は、FaxTx1オブジェクト831がインスタンス化された際に実行される。FaxTx1オブジェクト831は、インスタンス化されると、バンドルサービスFaxTx1の状態遷移情報に基づいて当該状態遷移に対応したオブジェクト構成を構築する101。状態遷移情報は、例えば、融合機101の所定の記憶装置内に、以下の形式で保存されている。図15及び図16は、バンドルサービスFaxTx1の状態遷移情報の定義例を示す図である。図15及び図16によって一つの状態遷移情報900の記述例が示されている。状態遷移情報900は、XMIXMLMetadataInterchangeに従った記述例が示されている。XMIは、モデルを各種のソフトウェアの間でXML文書によって交換することを目的とした標準規格である。但し、本実施の形態を実施するにあたり、状態遷移情報は、必ずしもXMIに従って記述される必要はない。なお、図中における行番号は、説明の便宜上付加したものである。状態遷移情報900の121行目における<StateMachine>タグのタグ名、及びそのname属性の値FaxTx1によって、状態遷移情報900は、バンドルサービスFaxTx1に対応するものであることが定義されている。また、当該<StateMachine>タグにおけるxmi.id属性の値004は、バンドルサービスFaxTx1を識別するIDである。125行目の<CompositeState>タグは、バンドルサービスFaxTx1における状態の定義の開始の宣言に相当する。当該宣言は、<CompositeState>タグのxmi.idの値017によって識別される。130行目から137行目における<Pseudostate>タグによって囲まれたPseudostate要素910は、初期状態601に対する定義である。Pseudostate要素910のname属性の値にはInitが設定され、xmi.id要素の値には、018が設定されている。138行目から148行目におけるCompositeState要素920は、Send状態604に対する定義である。CompositeState要素920のname属性の値にはSendが設定され、xmi.id要素の値には、019が設定されている。149行目から159行目におけるCompositeState要素930は、Idle状態603に対する定義である。CompositeState要素930のname属性の値にはIdleが設定され、xmi.id要素の値には、022が設定されている。160行目から183行目におけるPseudostate要素940は、終期状態602に対する定義である。Pseudostate要素940のname属性の値にはendが設定され、xmi.id要素の値には、024が設定されている。また、191行目から228行目には、バンドルサービスFaxTx1における各状態遷移が定義されている。すなわち、191行目から204行目におけるTransition要素950は、Idle状態603からSend状態604への状態遷移に対する定義である。Transition要素950が当該状態遷移に対する定義であることは、Transition要素950の子要素として定義されている、Transition.source要素951及びTransition.target要素952より特定される。Transition.source要素951は遷移元の状態が設定される要素である。Transition.source要素951の子要素のxmi.idref属性の値は022である。したがって、遷移元は、xmi.id属性の値が022の状態、すなわち、Idle状態603であることが分かる。また、Transition.target要素952は遷移先の状態が設定される要素である。Transition.target要素952の子要素のxmi.idref属性の値は019である。したがって、遷移先は、xmi.idの値が019の状態、すなわち、Send状態604であることが分かる。なお、Transition要素950のname属性の値は送信開始であり、xmi.id属性の値は023である。205行目から218行目におけるTransition要素960は、Send状態604から終期状態602への状態遷移に対する定義である。Transition要素960が当該状態遷移に対する定義であることは、Transition.source要素961内のxmi.idref属性の値が019Send状態604であり、Transition.target要素962内のxmi.idref属性の値が024終期状態602であることから特定される。なお、Transition要素960のname属性の値は送信終了であり、xmi.id属性の値は020である。219行目から228行目におけるTransition要素970は、初期状態601からIdle状態603への状態遷移に対する定義である。Transition要素970が当該状態遷移に対する定義であることは、Transition.source要素971内のxmi.idref属性の値が018初期状態601であり、Transition.target要素972内のxmi.idref属性の値が022Idle状態603であることから特定される。なお、Transition要素970のxmi.id属性の値は018である。130行目以降の説明に戻る。各状態に対応する、Pseudostate要素910、CompositeState要素920、及びCompositeState要素930は、StateVertex.outgoing要素及びStateVertex.incoming要素の少なくともいずれか一方を子要素として有する。StateVertex.outgoing要素は、遷移元からの状態遷移に対する接続が定義される要素である。StateVertex.incoming要素は、遷移先への状態遷移に対する接続が定義される要素である。例えば、初期状態601に対応するPseudostate要素910におけるStateVertex.outgoing要素911において、その子要素のxmi.idref属性の値は018である。したがって、初期状態601からの遷移先への状態遷移は、Transition要素970が対応する状態遷移に相当することが分かる。また、Send状態604に対応するCompositeState要素920おけるStateVertex.outgoing要素921においてその子要素のxmi.idref属性の値は020であり、StateVertex.incoming要素922において、その子要素のxmi.idref属性の値は023である。したがって、Send状態604からの遷移先への状態遷移は、Transition要素960が対応する状態遷移に相当し、遷移元の状態遷移は、Transition要素950が対応する状態遷移に相当することが分かる。なお、Idle状態603に対応するCompositeState要素930、終期状態602に対応するPseudostate要素940においても同様に状態遷移との接続が定義されている。上記のような状態遷移情報900に基づいて、FaxTx1オブジェクト831は、まず、各状態オブジェクト及び遷移オブジェクト等をインスタンス化する。図中では、状態遷移情報900におけるPseudostate要素910、CompositeState要素930、CompositeState要素940、Pseudostate要素940、及びTransition要素950のそれぞれに基づいて、初期状態オブジェクト701、Idle状態オブジェクト703、Send状態オブジェクト704、終期状態オブジェクト702、送信開始オブジェクト711Tが生成されている例が示されているS102~S106。続いて、FaxTx1オブジェクト831は、各状態オブジェクトの参照関係が状態遷移情報900に定義された状態遷移の順になるよう、遷移元の状態オブジェクトに対して遷移先の状態オブジェクトを接続する。例えば、FaxTx1オブジェクト831は、Idle状態オブジェクト703の識別情報を引数として、初期状態オブジェクト701のconnectメソッドを呼び出すS107。また、FaxTx1オブジェクト831は、Send状態オブジェクト704の識別情報を引数として、Idle状態オブジェクト703のconnectメソッドを呼び出すS108。また、FaxTx1オブジェクト831は、終期状態オブジェクト702の識別情報を引数として、Send状態オブジェクト704のconnectメソッドを呼び出すS109。connectメソッドを呼び出された各状態オブジェクトは、当該状態オブジェクト内において引数に指定された識別情報を保持する。また、必要に応じて、connectメソッドの引数には遷移オブジェクトの識別情報も指定される。例えば、ステップS108において、Idle状態オブジェクト703のconnectメソッドが呼び出される際は、送信開始オブジェクト711Tの識別情報も引数に指定される。このように、connectメソッドの引数に、状態オブジェクトと遷移オブジェクトとのそれぞれの識別情報が指定された場合、当該メソッドが呼び出された状態オブジェクトは、その状態オブジェクトの識別情報と遷移オブジェクトの識別情報とを関連付けてペアで保持する。これによって、ある状態オブジェクトがアクティブのときに、あるイベントが発生したときの遷移先の状態オブジェクトが特定され得る。以上の処理によって、バンドルサービスFaxTx1について、図11に示されるようなオブジェクト構成が構築される。上記をふまえて、バンドルサービスFaxTx1のFaxTx2への更新処理の詳細について説明する。図17は、FaxTx1からFaxTx2への更新処理を説明するためのシーケンス図である。例えば、管理者は、FaxTx2とFaxTx1との差分の追加モジュールが格納されたSDカードを融合機101のメモリカードスロット234に挿入するS201。図18は、SDカード内の追加モジュールの構成例を示す図である。図18に示されるSDカード235aには、更新差分サービスバンドル840とAspectSM.xmlファイル811AspectSM811とが格納されている。更新差分サービスバンドル840には、更新処理を実行するにあたり、図10のクラス図において、IStateインタフェース1004a、Activityインタフェース1004b、Eventインタフェース1003a、Guardインタフェース1003b、又はActionインタフェース1003cに対応するクラスのうち、追加が必要とされるクラスが実装された機能モジュール例えば、Java登録商標のクラスファイル。以下追加モジュールという。が格納されている。ここでは、追加モジュールとして、PDF2Tiff841とConvertEnd842とが格納されている。AspectSM811は、FaxTx1からFaxTx2への更新処理をどのように実施するかについての仕様がXML形式記述されているファイルである。図19は、AspectSMの記述例を示す図である。図中、行番号は説明の便宜上付加したものである。AspectSM811には、バンドルサービスFaxTx1の状態遷移情報900図15及び図16に対する変更内容が記述されている。AxpectSM811の記述例において、2行目は、xmi.idの値が004であるFaxTx1に対して状態遷移の変更を行うことを指示している。すなわち、2行目におけるxmi.idref属性は、変更の対象となるバンドルサービスのxmi.idが指定される。3行目から20行目までは一つ目の変更箇所に関する変更情報が記述されている。3行目には、変更箇所と変更タイミングが指定されている。変更箇所は、pointcut.<xxx>における<xxx>の記述とxmi.ref属性の値とによって指定される。ここで、<xxx>の部分はCompositeStateであり、xmi.ref属性の値は017である。したがって、状態遷移情報900の125行目における<CompositeState>タグ内に対する変更が指定されていることになる。また、変更のタイミングは、timing属性の値によって指定される。ここでは、Idleが指定されている。したがって、FaxTx1がIdle状態603にあるときに、変更を行うべきことが指定されている。4行目には、変更の内容が指定されている。すなわち、<advice.CompositeState>タグのタグ名におけるadvice.以降によって、変更の対象がCompositeState要素であることが指定されている。また、type属性によって、変更の種別がinsert挿入であることが指定されている。すなわち、3行目及び4行目によって、<CompositeState>タグ内に新たなCompositeState要素を挿入すべき旨が指定されている。5行目から18行目は、挿入の対象となるCompositeState要素850の定義である。CompositeState要素850は、FaxTx2のTransform状態605に対応する。CompositeState要素850内の記述形式は、図15及び図16において説明した通りである。すなわち、CompositeState要素850の子要素である、StateVertex.outgoing要素851において遷移先への接続が定義され、StateVertex.incoming要素852において遷移元への接続が定義されている。ところで、CompositeState要素850は、State.entry要素853が子要素として定義されている。State.entry要素853は、CompositeState要素850が対応するTransform状態605における入場処理が定義される要素である。すなわち、CompositeState要素850の子要素として、Action要素854が定義されているが、そのxmi.id属性とname属性より、xmi.id属性の値が026であり、name属性の値がpdf2tiffによって識別される処理が実行されることが指定されている。21行目から42行目までは二つ目の変更箇所に関する変更情報が指定されている。21行目には、変更箇所及び変更のタイミングが指定されている。ここでは、Idle状態603のときにTransition要素950図16参照に対して変更を行うことが指定されている。二つ目の変更箇所には、二つの変更が指定されている。22行目から24行目までに一つ目の変更が指定されており、25行目から41行目までに二つ目の変更が指定されている。一つ目の変更については、22行目の<advice.Transition.target>タグのタグ名におけるadovice.以降によって変更対象がTransition.target要素952であることが指定されている。また、type属性によって、変更の種別が修正modifyであることが指定されている。23行目には、変更の対象に関して修正後の定義が記述されている。すなわち、一つ目の変更は、Idle状態603からSend状態604への状態遷移を、Idle状態603からTransform状態605への状態遷移に修正することである。二つ目の変更25行目から41行目は、新たな状態遷移Tranform状態605からSend状態604への状態遷移に対応するTransision要素の挿入をIdle状態603のときに行うことである。この内容は、上記の説明から読み取れるため、各行毎の説明は省略する。43行目から55行目は、標準ではなく独自の書式に基づく定義が行われている拡張記述部分である。43行目のpointcut.以下のXMI.extensionによって、拡張記述部分であることが指定されている。本実施の形態では、この部分に、状態遷移処理で呼ばれるアクション処理と、イベント処理等に使用する機能モジュール例えば、Java登録商標クラスとの関連付けが定義される。44行目では、当該advice要素の子要素の定義を挿入insertすべきことが指定されている。45行目から49行目までは、挿入される定義である。45行目には、Bundleを実装することが指定されている。Bundleの実装先は、xmi.idref属性の値004で指定される。すなわち、FaxTx1である。46行目から49行目までは、Transform状態605に対応させて新たに挿入するCompositeState要素8505行目から18行目の入場処理の定義15行目から17行目におけるpdf2tiffと、実際にその処理が実装されているjp.co.rrr.function.pdf2tiffクラスとの関連付けが定義されている。これによって、FaxTx2に更新された後、Transform状態605に遷移したときには、jp.co.rrr.function.pdf2tiffが実行されることになる。48行目のproperty要素は、jp.co.rrr.function.pdf2tiffクラスが実行されるときのプロパティ情報である。50行目から52行目は、Transform状態605からSend状態604への状態遷移のトリガーとなる変換完了イベントとjp.co.rrr.function.convertEndクラスとの関連付けが定義されている。これによって、Traneform状態605中に変換完了イベントが検知されると、jp.co.rrr.function.convertEndクラスが実行され、その実行結果がtrueであれば、Send状態604に遷移することになる。図17に戻る。管理者によるSDカード235aの挿入が自動的に検知されると、又はSDカード235aが挿入され、オペレーションパネル202から更新指示が入力されると、SAS411は、SASManager511に更新処理の実行を要求するS202。なお、SDカード235aに記録された情報は、ネットワークを介してダウンロードされてもよい。この場合、SDカードのような記録媒体を用いる必要はない。SASManager511は、挿入されたSDカード235aの更新差分サービスバンドル840によるFaxTx1からFaxTx2への更新の可否についてチェックを行うS203。更新が可能な場合、SASManager511は、更新差分サービスバンドル840の融合機101へのインストールの可否をチェックするS204。インストールが可能な場合、SASManager511は、SDカード235a内の更新差分サービスバンドル840をOSGiフレームワーク403融合機101にインストールするS205。更新差分サービスバンドル840のインストールが完了すると、SASManager511は、更新差分サービスバンドル840をアクティブ状態に遷移させるようにOSGiフレームワーク403に要求するS206。OSGiフレームワーク403は、更新差分サービスバンドル840のインスタンスを以下、更新差分オブジェクト840aという。生成し、アクティブな状態に遷移させるS207。更新差分オブジェクト840aは、PluginAgent821に対して更新差分サービスバンドル840がプラグインされたことをAspectSM811を添えて通知するS208。PluginAgent821は、FaxTx1オブジェクト831に対して、AspectSM811を添えてFaxTx2への更新要求を行うS209。FaxTx1オブジェクト831は、AspectSM811に基づいて、サービスバンドルFaxTx1をFaxTx2へ更新する為に必要な追加モジュール判断し、当該追加モジュールここでは、PDF2Tiff841及びConvertEnd842の取得を更新差分オブジェクト840aに要求するS210。更新差分オブジェクト840aは、当該追加モジュールを取得し、FaxTx1オブジェクト831に返却するS211。続いて、FaxTx1オブジェクト831は、AspectSM811に従って、バンドルサービスFaxTx1のオブジェクト構成を、FaxTx2に対応するものに更新すると共に、当該更新によって新たに追加されたActivityオブジェクトと追加モジュールとの関連付けを行うS212。なお、ステップS212の処理は、AspectSM811に記述されているタイミングで行われる。続いて、FaxTx1オブジェクト831は、バンドルサービスFaxTx1についてFaxTx2への更新が完了したことをPluginAgent821に通知するS213。但し、FaxTx1をFaxTx2に切り替えるスイッチ721は、FaxTx1の状態のままである。更新が完了した旨の通知は、SASManaer511を介してSAS411に通知されるS214、S215。SAS411は、管理者に更新完了を通知するため、オペレーションパネル202に更新完了を通知するメッセージを表示させるS216。なお、この状態では、スイッチ721は、まだFaxTx2には切り替えられていないので、SAS411は、管理者にFaxTx2へ切り替える否かを問い合わせる。そこで、管理者が、オペレーションパネル202を介してFaxTx2への切替指示を入力するとS217、SAS411は、FaxTx2への切替要求をSASManager511に通知するS218。SASManager511は、PluginAgent821にFaxTx2への切り替えを要求するS219。PluginAgent821は、FaxTx1オブジェクト831に対して、その振る舞い状態遷移をFaxTx2に対応するものに切り替えるように指示するS220。FaxTx1オブジェクト831は、バンドルサービスFaxTx1がIdle状態703になるまで待機する。Idle状態703に遷移すると、FaxTx1オブジェクト831は、スイッチ721を切り換えることにより、自己の振る舞いをFaxTx2に対応するものに切り替えるS221。切り替えが完了すると、FaxTx1オブジェクト831は、PluginAgent821に対して、切替完了通知を行うS222。切替完了通知は、SASManager511を介してSAS411に伝達されるS223、S224。SAS411は、切替完了通知に応じ、バンドルサービスFaxTx1の切り替えが完了した旨をオペレーションパネル202に表示させるS225。次に、ステップS212における、バンドルサービスFaxTx1のオブジェクト構成の更新処理の詳細について説明する。図20は、バンドルサービスFaxTx1のオブジェクト構成の更新処理を説明するためのシーケンス図である。まず、FaxTx1オブジェクト831は、バンドルサービスFaxTx1の状態が、AspectSM811に指定されている変更箇所ごとにおけるtiming属性の値に指定されている状態に遷移するまで待機するS2111。図19のAspectSM811の例では、全ての変更箇所に対するタイミングは、Idle状態603として指定されている。したがって、ここでは、Idle状態603に遷移するまで待機する。バンドルサービスFaxTx1の状態がIdle状態603に遷移すると、FaxTx1オブジェクト831は、AspectSM811の記述にしたがって、更新処理を開始する。例えば、FaxTx1オブジェクト831は、AspectSM811の3行目から20行目に基づいてTransform状態605に対応するTransformオブジェクト状態705を生成するS2112。続いて、FaxTx1オブジェクト831は、AspectSM811の25行目から41行目に基づいて、変換終了オブジェクト713Tを生成するS2113。続いて、FaxTx1オブジェクト831は、AspectSM811の9行目から14行目や、22行目から24行目に基づいて、オブジェクト間の接続関係を変更する。すなわち、FaxTx1オブジェクト831は、Transform状態オブジェクト705の識別情報を引数としてIdle状態オブジェクト703のreconnectメソッドを呼び出すS2114。これに応じて、Idle状態オブジェクト704は、遷移先の状態オブジェクトとして、Send状態オブジェクト704とTransForm状態オブジェクト705とを保持することになる。これは、ちょうど図12において、スイッチ721によって遷移先が分岐している状態に相当する。スイッチ721は、例えば、Idle状態オブジェクト703が参照可能なフラグ変数として実装される。例えば、当該フラグ変数の値が0のときには遷移先はSend状態オブジェクト704とされ、1のときには遷移先はTransform状態オブジェクト705とされるといった具合である。なお、Idle状態オブジェクト703とTransform状態オブジェクト705との接続は行われたが、図17において説明したように、この時点では、スイッチ721は切り替えられていないため、Idle状態オブジェクト703からの遷移先のオブジェクトはSend状態オブジェクト704のままであるすなわち、バンドルサービスFaxTx1として機能する。。続いて、FaxTx1オブジェクト831は、Send状態オブジェクト704の識別情報と変換完了オブジェクト713Tの識別情報とを引数としてTransform状態オブジェクト705のconnectメソッドを呼び出すS2115。これに応じて、Transform状態オブジェクト705は、Send状態オブジェクト704の識別情報と変換完了オブジェクト713Tの識別情報とを関連付けて保持する。すなわち、変換終了イベントが発生した際のTransform状態605からSend状態604への状態遷移に対応する接続が構築されたことになる。続いて、FaxTx1オブジェクト831は、AspectSM811の43行目から55行目に基づいて、追加モジュールとオブジェクトとの関連付けを行う。すなわち、Transform状態オブジェクト705の入場処理のインタフェースIStateインタフェース1004aに対してPDF2TIFF841を関連付けるS2116。続いて、変換完了オブジェクト713TのEventインタフェース1003aに対してConvertEnd842を関連付けるS2117。以上の処理によって、バンドルサービスFaxTx1のオブジェクト構成は、図12に示されるようなものに更新される。ところで、図19において、AspectSM811にはバンドルサービスFaxTx1の状態遷移情報900図15及び図16に対する変更内容が記述されていると説明した。しかし、上記のように、FaxTx1オブジェクト831は、AspectSM811に基づいて状態遷移情報900を書き換えるのではなく、バンドルサービスFaxTx1を構成するオブジェクトを変更することで更新処理を実現する。図14において説明したように、バンドルサービスFaxTx1は、状態遷移情報900に基づいてそのオブジェクトが構築されたものである。したがって、状態遷移情報900に対する変更内容が記述されたAspectSM811は、そのままバンドルサービスFaxTx1のオブジェクト構成に適用することができるのである。なお、AspectSM811に基づいて状態遷移情報900を更新し、更新された状態遷移情報900に基づいてFaxTx1厳密には、FaxTx2に更新されたものを再構築してもよい。但し、この場合、再構築の前にバンドルサービスFaxTx1を構成するオブジェクト群が破棄されるため、バンドルサービスFaxTx1を利用中のアプリケーション等との参照関係が破壊されてしまう。したがって、本実施の形態のように、オブジェクト群を再構築するのではなく、既存のオブジェクト構成を変更する方が好適である。なお、上記のように、更新処理後は、バンドルサービスFaxTx1とFaxTx2とは、スイッチ721を切り替えることにより容易に切り替えが可能である。したがって、FaxTx1からFaxTx2への更新後、再度FaxTx2からFaxTx1に戻したい場合は、スイッチ721を切り替えることにより実現すればよい。すなわち、Idle状態オブジェクト703が参照可能なフラグ変数の値を更新すればよい。また、FaxTx2からFaxTx1への更新指示が記述されたAspectSMに基づいて、FaxTx2からFaxTx1への更新を実現してもよい。この場合スイッチ721を切り替えるタイミングは、当該AspectSMに記述されたタイミングで行われる。上述したように、本実施の形態におけるバンドルサービスは、状態オブジェクトの遷移によってサービスを実現する。また、サービスの実現過程において、アクティブな状態オブジェクトが限定されるように構成されている。言い換えれば、非アクティブな状態オブジェクトが存在することになる。このような構成を前提として、AspectSM811には、更新部分が非アクティブなタイミングで更新が行われるような更新指示が記述されている。そして、かかるAspectSM811に従って、更新部分が非アクティブなときに更新が実行される。したがって、本実施の形態におけるバンドルサービスは、当該バンドルサービスの実行中にその振る舞いの更新を実行することができる。また、振る舞いの更新にあたり、オブジェクト群が再構築されるわけではないので、当該バンドルサービスの参照側との参照関係が破壊されることなく、動的にその振る舞いを更新することが可能となっている。よって、融合機101を再起動することなくバンドルサービスの振る舞いは更新され得る。なお、本実施の形態においては、バンドルサービスが状態遷移図に基づいて設計された例を用いて説明したが、本発明が適用可能なプログラムは、状態ごとにオブジェクトが構築されるような構成であるものに限定されない。お互いに排他的に動作する複数のモジュールオブジェクトも含むの接続によって構成されているものでればよい。ここで排他的に処理を実行するとは、あるモジュールが動作中アクティブのときは、他のモジュールは動作中でない非アクティブであることが保証されることをいう。このようなソフトウェアであれば、動作中でないモジュールの接続関係を変更することが可能であり、本実施の形態において説明した更新処理を適用させることができる。以上、バンドルサービス148の更新処理を説明したが、以下、図21ではバンドルアプリ147の更新処理を説明する。バンドルアプリ147の更新処理ではバンドルサービス148の更新処理と異なりサービスの提供が問題にならないので、バンドルアプリ147の更新処理はバンドルサービス148の更新処理に比べて単純になる。図21は、バンドルアプリ147の更新処理に係るコラボレーション図である。同図の更新処理は、バンドルアプリAppXt1をバンドルアプリAppXt2に更新するものである。AppXt1をAppXt2に更新する旨の更新操作が融合機101又はクライアント端末801の操作画面で実施されると、AppXt1をAppXt2に更新する旨の更新要求がSAS411からSASManager511に送信S21される。次に、SASManager511では、更新処理用のモジュールを融合機101にインストール可能かどうかのチェックが実行S22される。続いて、SASManager511は、更新処理用のモジュールを融合機101にインストールS23する。続いて、SASManager511は、更新処理用のモジュールをアクティブ状態に遷移S24させる。続いて、SASManager511は、AppXt1に更新処理用のモジュールを追加して、所定のスイッチをAppXt1側からAppXt2側に切り替えて、AppXt2を生成S25する。なお、上記のスイッチをAppXt1側からAppXt2側に切り替えるタイミングは任意である。以上、バンドルアプリ147に係る説明とバンドルサービス148に係る説明とを別個に実施したが、以下、バンドルアプリ147に係る説明とバンドルサービス148に係る説明とを同時に実施する。図22は、バンドルアプリ147とバンドルサービス148との間の利用関係の具体例を表す。バンドルアプリ147やバンドルサービス148の更新処理が実施される場合において、どのバンドルアプリ147がどのバンドルサービス148を利用するかと言う利用関係を設定できるようにしてもよい。図22は、バンドルアプリAppXt1がバンドルサービスFaxTx1を利用する、バンドルアプリAppXt2がバンドルサービスFaxTx2を利用する、バンドルアプリAppXt3がバンドルサービスFaxTx3を利用すると言う利用関係を表す。図23は、FaxTx1とFaxTx2とFaxTx3との間の継承関係の例を表す。FaxTx1とFaxTx2については、FaxTx1が親でFaxTx2が子の関係の継承関係にある。FaxTx3については、FaxTx1ともFaxTx2とも継承関係にない。FaxTx1やFaxTx2やFaxTx3の継承関係はPluginAgent821の処理やProxyService822の処理に影響する。PluginAgent821では、FaxTx1やFaxTx2やFaxTx3の管理を継承関係を利用せず実施する。図23のように、PluginAgent821では、FaxTx1もFaxTx2もFaxTx3もそれぞれ個別に管理する。継承関係がPluginAgent821の処理に影響するのは、継承関係にあるFaxTx1とFaxTx2のスイッチをFaxTx1側からFaxTx2側に切り替える切替制御である。ProxyService822では、FaxTx1やFaxTx2やFaxTx3の登録を継承関係を利用して実施する。FaxTx1とFaxTx2については継承関係にあるため、図23のように、親のFaxTx1は登録されるが子のFaxTx2は登録不要である。FaxTx3についてはFaxTx1ともFaxTx2とも継承関係にないため、図23のように、FaxTx3は登録される。ProxyService822では、AppXt1/2/3とFaxTx1/2/3との仲介制御を実行する。図24は、利用関係の設定画面の具体例を表す。図24の設定画面は、融合機101やクライアント端末801の表示画面にSAS411が表示する。前者はいわゆるローカル表示であり、後者はいわゆるリモート表示である。リモート表示を実現するには例えば、融合機101とクライアント端末801にWebサーバ機能とWebクライアント機能を具備させればよい。図24の設定画面は、AppXt1にFaxTx1を利用させるかFaxTx2を利用させるかFaxTx3を利用させるかを設定するための設定画面である。AppXt1に係る表示情報は、AppXt1のJARファイルに対応するJNLPファイルアプリケーション管理ファイルに起因する。図24の設定画面で指定されたFaxTxFaxTx1/2/3が融合機101に実装されていない場合、図13のようなインストール処理やアップデート処理が実行される。なお、図24の設定画面での指定操作は、図13の説明で登場した操作画面での更新操作の一環として実施されるものとしてもよい。図25は、バンドルアプリ147やバンドルサービス148の更新処理用のモジュールの取得態様について説明するための図である。図中のAの矢印は、更新処理用のモジュールを融合機101に挿入されたメモリカード235から取得する態様を表す。メモリカード235は例えば、SDカードやICカードである。図25のAでは、SASManager511は、融合機101に実装されたバンドルアプリ147やバンドルサービス148を、メモリカード235から取得されたプログラムにより更新する。図25のAの取得態様では、ネットワーク接続されていない機器においても更新処理を実施する事ができる。図中のBの矢印は、更新処理用のモジュールをPull型の通信によりバンドルサーバ901から取得する態様を表す。Pull型の通信処理の主体は、融合機101のSAS411である。図25のBでは、SASManager511は、融合機101に実装されたバンドルアプリ147やバンドルサービス148を、Pull型の通信により取得されたプログラムにより更新する。図25のBの取得態様では、SDカードやICカードを利用せずに更新処理を実施する事ができる。図中のCの矢印は、更新処理用のモジュールをPush型の通信によりバンドルサーバ901から取得する態様を表す。Push型の通信処理の主体は、バンドルサーバ901である。図25のCでは、SASManager511は、融合機101に実装されたバンドルアプリ147やバンドルサービス148を、Push型の通信により取得されたプログラムにより更新する。図25のCの取得態様では、サーバからの遠隔制御のもとで更新処理を実施する事ができる。なお、更新処理の実施態様は自動更新でも手動更新でもよい。図13や図21では更新操作の直後に更新処理が実施されるようにしているが、更新操作による更新設定を契機として更新処理が定期的に実施されるようにしてもよい。"