JP4787614B2 - 画像形成装置及びアプリケーション管理プログラム - Google Patents

Description

本発明は、画像形成装置及びアプリケーション管理プログラムに関し、特に、複数のアプリケーションを実行可能な画像形成装置及びアプリケーション管理プログラムに関するものである。

従来、プリンタ、コピーおよびスキャナなどの複数の機能を一つの筐体内に収納した複合機が知られている。かかる複合機では、ＵＮＩＸ（登録商標）などの汎用ＯＳ上に、プリンタアプリ、コピーアプリおよびスキャナアプリと呼ばれる複数のアプリケーションを搭載し、これらのアプリケーションの実行処理を切替えながら複数の機能を実現していた。

ところが、上記プリンタアプリ、コピーアプリおよびスキャナアプリは、それぞれエンジン制御、メモリ制御およびシステム制御などを別個におこなっているので、重複処理という無駄が生じていた。

このため、特許文献１では、複合機に搭載される複数のアプリケーションがそれぞれ担っていたエンジン制御、メモリ制御およびシステム制御などの処理を共通処理部分（プラットホーム）として各アプリケーションから括り出すことにより、アプリケーションの開発効率の向上を図っている。
特開２００２−０８４３８３号公報

しかしながら、この特許文献１で開示されている発明は、ハードウェアを制御する処理部分を共通化するものであり、各アプリケーションの内部処理全般を共通化するものではない。このため、複合機上のアプリケーションには、開発効率の向上を図るうえで改善の余地が残されている。

例えば、プリンタアプリやコピーアプリといった各アプリの動作設定を管理するアプリ管理処理では、設定画面の利用権取得や電力状態の変更といった処理をおこなったうえで各アプリに対する設定処理をおこなう必要があった。これらの処理は、複合機に搭載される各アプリケーションに共通して存在する処理であるが、ハードウェアを直接制御する処理ではないため各アプリケーションで別個に実現されており、共通化することが可能である。

また、近年の複合機では、ネットワークを介した端末装置から各アプリの設定処理をおこなうことが可能となっており、複合機を直接操作して設定処理をおこなう場合と、ネットワークを介して設定処理をおこなう場合とでは、設定対象となる項目を変更する場合も多い。さらに、設定処理をおこなう利用者には、一般利用者、保守要員（サービスパーソン）などがあり、これらの利用者ごとに設定対象となる項目を変更する必要がある。

これらのことから、複合機に搭載されるアプリケーションのアプリ管理処理をいかにして汎用的に、かつ、効率よく実現するかが大きな課題となっている。なお、かかる課題は複合機についてのみ生じるものではなく、アプリケーションの管理処理をおこなうアプリ管理装置についても同様に生ずる課題である。

本発明は、上述した従来技術による問題点を解消するためになされたものであり、機能追加や改修を容易におこなうことができるとともに、汎用的なアプリ管理の仕組みを効率よく実現することができる画像形成装置及びアプリケーション管理プログラムを提供することを目的とする。

そこで上記課題を解決するため、本発明は、複数のアプリケーションを実行する統合アプリケーションを備えた画像形成装置であって、前記アプリケーションの実行要求に応じ当該画像形成装置の状態に基づいて前記アプリケーションの利用の可否判断を行う機器状態管理手段と、前記アプリケーションの構成を管理するアプリ構成管理手段と、前記アプリケーションごとに当該アプリケーションの利用の可否判断の要因となる状態情報を管理するアプリ状態管理手段とを有し、前記アプリ構成管理手段は、前記アプリケーションごとの状態に基づいて当該アプリケーションの利用の可否判断を行うアプリケーション管理手段を有し、当該アプリケーション管理手段によって前記アプリケーションを階層構造で管理し、さらに、前記アプリ構成管理手段は、単一のアプリケーションに対応する前記アプリケーション管理手段および複数のアプリケーションに対応する前記アプリケーション管理手段のうちの少なくとも一方の２つ以上を集約する前記アプリケーション管理手段を有することを特徴とする。

このような画像形成装置では、機能追加や改修を容易におこなうことができるとともに、汎用的なアプリ管理の仕組みを効率よく実現することができる。

また、上記課題を解決するため、本発明は、上記画像形成装置を上記各手段として機能させるためのアプリケーション管理プログラムとしてもよい。

本発明によれば、機能追加や改修を容易におこなうことができるとともに、汎用的なアプリ管理の仕組みを効率よく実現することができる画像形成装置及びアプリケーション管理プログラムを提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。なお、本実施の形態では、この発明を画像形成装置に適用した場合について説明するが、本発明はこれに限らず、アプリ管理をおこなう各種装置に適用することができる。

まず、本実施の形態に係る画像形成装置（以下「複合機」と言う）１の概要について図１、図２、図３、図９および図１０を用いて説明する。図１は、本実施の形態に係る複合機１を取り巻くネットワーク環境を説明するためのネットワーク図であり、図２は、図１に示した複合機１のハードウェア構成を示すブロック図であり、図３は、図１に示した複合機１のソフトウェアとハードウェアの関係を説明するための説明図である。また、図９は、複合機１に搭載されるソフトウェア構成の変遷を説明するための説明図であり、図１０は、従来の複合機のソフトウェアとハードウェアの関係を説明するための説明図である。

図１に示すように、近年のネットワーク化の進展により、オフィスなどに設けられたパーソナルコンピュータ（ＰＣ）などの機器は、ＬＡＮ（Local Area Network）などのネットワークに接続され、相互に通信することが通常となった。例えば、同図に示したように、かかるネットワークには、クライアントＰＣ、ＳＭＴＰ（Simple Mail Transfer Protocol）サーバ、ＦＴＰ（File Transfer Protocol）サーバ、サーバＰＣなどが接続され、電子メールの送受信やファイル転送をすることができ、モデム接続された配信サーバは、オフィス外のファックス装置と通信することができる。

このようなネットワーク化の進展に伴い、複合機１もネットワークに接続され、ＰＣ等の機器と相互に通信することが可能となり、ハードディスク等の記憶装置を内蔵することで、いわゆるネットワーク複合機へと進化し、ユーザの様々なニーズに応えることができるようになった。

例えば、複合機１は、通常のコピー機能に加えて、クライアントＰＣからの印刷要求により文書データ等を印刷するプリンタ機能、クライアントＰＣからのファックス要求により文書データ等をサーバＰＣに接続されたモデムを経由して他のオフィスのファックス機器に送信するファックス機能、受信したファックス文書やコピー文書を内蔵したハードディスクに蓄積する蓄積機能などを有するようになった。

こうして複合化とネットワーク化の進展により必要となった多くの機能を実現するため、複合機１に搭載されるソフトウェアは、規模が大きく、複雑なものとなっている。そして、それにともなって、それらのソフトウェアの開発と維持管理のための工数も大幅に増大している。

図２は、かかる複合機１のハードウェア構成を示すブロック図である。同図に示すように、この複合機１は、コントローラ１０とエンジン部（Engine）６０とをＰＣＩ（Peripheral Component Interconnect）バスで接続した構成となる。コントローラ１０は、複合機１全体の制御と描画、通信、図示しない操作部からの入力を制御するコントローラである。エンジン部６０は、ＰＣＩバスに接続可能なプリンタエンジンなどであり、例えば白黒プロッタ、１ドラムカラープロッタ、４ドラムカラープロッタ、スキャナまたはファックスユニットなどである。なお、このエンジン部６０には、プロッタなどのいわゆるエンジン部分に加えて、誤差拡散やガンマ変換などの画像処理部分が含まれる。

コントローラ１０は、ＣＰＵ１１と、ノースブリッジ（ＮＢ）１３と、システムメモリ（ＭＥＭ−Ｐ）１２と、サウスブリッジ（ＳＢ）１４と、ローカルメモリ（ＭＥＭ−Ｃ）１７と、ＡＳＩＣ（Application Specific Integrated Circuit）１６と、ハードディスクドライブ（ＨＤＤ）１８とを有し、ノースブリッジ（ＮＢ）１３とＡＳＩＣ１６との間をＡＧＰ（Accelerated Graphics Port）バス１５で接続した構成となる。また、ＭＥＭ−Ｐ１２は、ＲＯＭ（Read Only Memory）１２ａと、ＲＡＭ(Random Access Memory)１２ｂとをさらに有する。

ＣＰＵ１１は、複合機１の全体制御をおこなうものであり、ＮＢ１３、ＭＥＭ−Ｐ１２およびＳＢ１４からなるチップセットを有し、このチップセットを介して他の機器と接続される。

ＮＢ１３は、ＣＰＵ１１とＭＥＭ−Ｐ１２、ＳＢ１４、ＡＧＰ１５とを接続するためのブリッジであり、ＭＥＭ−Ｐ１２に対する読み書きなどを制御するメモリコントローラと、ＰＣＩマスタおよびＡＧＰターゲットとを有する。

ＭＥＭ−Ｐ１２は、プログラムやデータの格納用メモリ、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いるシステムメモリであり、ＲＯＭ１２ａとＲＡＭ１２ｂとからなる。ＲＯＭ１２ａは、プログラムやデータの格納用メモリとして用いる読み出し専用のメモリであり、ＲＡＭ１２ｂは、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いる書き込みおよび読み出し可能なメモリである。

ＳＢ１４は、ＮＢ１３とＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。このＳＢ１４は、ＰＣＩバスを介してＮＢ１３と接続されており、このＰＣＩバスには、ネットワークインターフェース（Ｉ／Ｆ）部なども接続される。

ＡＳＩＣ１６は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣ（Integrated Circuit）であり、ＡＧＰ１５、ＰＣＩバス、ＨＤＤ１８およびＭＥＭ−Ｃ１７をそれぞれ接続するブリッジの役割を有する。このＡＳＩＣ１６は、ＰＣＩターゲットおよびＡＧＰマスタと、ＡＳＩＣ１６の中核をなすアービタ（ＡＲＢ）と、ＭＥＭ−Ｃ１７を制御するメモリコントローラと、ハードウェアロジックなどにより画像データの回転などをおこなう複数のＤＭＡＣ（Direct Memory Access Controller）と、エンジン部６０との間でＰＣＩバスを介したデータ転送をおこなうＰＣＩユニットとからなる。このＡＳＩＣ１６には、ＰＣＩバスを介してＦＣＵ（Fax Control Unit）３０、ＵＳＢ（Universal Serial Bus）４０、ＩＥＥＥ１３９４（the Institute of Electrical and Electronics Engineers 1394）インターフェース５０が接続される。

ＭＥＭ−Ｃ１７は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、ＨＤＤ（Hard Disk Drive）１８は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積を行うためのストレージである。

ＡＧＰ１５は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェースであり、ＭＥＭ−Ｐ１２に高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にするものである。

図３は、かかる複合機１のハードウェアおよびソフトウェアの構成を示した概念図であり、具体的には、後述する本実施の形態の特徴部分であるアプリ管理部１１１ｂを含む統合アプリケーション１１０と、ソフトウェア１００およびハードウェア２００の階層関係を示している。同図に示すように、ハードウェア２００は、ハードウェアリソース２０１を有し、このハードウェアリソース２０１は、スキャナ２０１ａ、プロッタ２０１ｂ、ＨＤＤ（Hard Disk Drive）２０１ｃ、ネットワーク２０１ｄおよびその他のリソース２０１ｅを有する。なお、その他のリソース２０１ｅは、２０１ａ〜２０１ｄ以外のハードウェアリソース２０１のことであり、例えば、操作パネルなどの入出力デバイスを示す。

また、かかるハードウェア２００に搭載されるソフトウェア１００は階層化されており、オペレーティングシステム１０３の上層にはサービス層１０２が構築され、このサービス層１０２の上層にはアプリケーション層１０３が構築されている。そして、サービス層１０２は、各ハードウェアリソース（２０１ａ〜２０１ｅ）を制御するドライバーに相当する、スキャナ制御１０２部ａ、プロッタ制御部１０２ｂ、蓄積制御部１０２ｃ、配信／メール送受信制御部１０２ｄ、ＦＡＸ送受信制御部１０２ｅ、ネットワーク通信制御部１０２ｆおよびその他の制御部１０２ｇを有する。

ここで、図３に示したソフトウェア１００が、かかる階層構造をとるに至った経緯について、図９および図１０を用いて説明する。図９は、複合機１に搭載されるソフトウェア構成の変遷を示す説明図である。図９のサービス層分離前アプリケーション５０１に示すように、多機能化した複合機１に搭載されるソフトウェアは、コピーアプリケーション、ＦＡＸアプリケーション、スキャナアプリケーションなどの機能別に独立したアプリケーションとして作成され、図３に示したオペレーティングシステム１０３上で動作していた。

しかしながら、これらのアプリケーションは、ハードウェアリソースを制御するドライバー（サービス層１０２）を含んでいたため、各アプリケーションには重複した処理が存在していた。その結果、各アプリケーションの規模は大きなものとなっていた。

そこで、図９のサービス層分離後アプリケーション５０２に示すように、サービス層分離前アプリケーション５０１のサービス層１０２相当部分を括りだしサービス層１０２とするとともに、各アプリケーションは、このサービス層１０２の上層であるアプリケーション層１０１に構築する構成とした。かかる階層化構成をとることにより、各アプリケーションはスリム化され開発労力も軽減された。

しかしながら、複合機１のネットワーク化、多機能化がさらに進展するに従って、各アプリケーションに共通処理部分が存在することが問題となってきた。具体的には、アプリケーション層１０１の各アプリケーション、例えば、コピーアプリケーションやスキャナアプリケーションなどは、それぞれ、スキャナ制御部１０２ａや蓄積制御部１０２ｃといったドライバーと通信をおこなう処理などの同様な処理を内部に有していた。このように、同様な処理を各アプリケーションが有していると、各アプリケーションの開発規模が大きくなるとともに、サービス層の仕様変更に対する各アプリケーションの改修規模が大きくなることが問題となってきた。

この問題を解決するため、図９の共通ルーチン分離アプリケーション５０３に示すように、かかる同様な処理（共通処理部分）を共通ルーチンとして括りだすことも考えられた。しかしながら、かかる共通ルーチンは、各アプリケーションにおいて微妙に異なる処理を共通化しようとするものであるため、共通ルーチン内部の処理は複雑なものとなってしまう。また、例えば、プリンタアプリケーションなどの新規アプリケーションを追加する場合においては、かかる新規アプリケーションに適応するために、共通ルーチンの改修が必要となる。

しかし、共通ルーチンの内部処理は複雑であるため、改修要員が処理を把握することが困難となり、改修規模の増大や、改修ミスによる他のアプリケーションへの影響が懸念された。

そこで、図９のオブジェクト指向アプリケーション５０４に示すように、オブジェクト指向による設計手法（オブジェクトモデリング）により、かかる複数のアプリケーションを、統合アプリケーション１１０に統合することとした。具体的には、各アプリケーションの共通処理部分をオブジェクトモデルとして抽出し、このオブジェクトモデルの集合体から、統合アプリケーション１１０を構成する。そして、従来のコピー機能やスキャナ機能といった機能は、かかるオブジェクトモデルの協調関係によって実現する。

このような構成をとることにより、例えばプリンタ機能のような新規機能の追加は、かかるオブジェクトモデルに属するクラスのサブクラス化などにより対処できる。このため、改修部分が明確となり、改修による他の機能への影響を小さくすることができる。また、オブジェクトモデリングによるプログラムは、従来の手続き型プログラムに比べて、処理の把握が容易であるため、改修要員が処理を把握することも容易となり、改修規模の削減や、改修ミスによる他のアプリケーションへの影響を小さくすることができる。

図１０は、図９に示したサービス層分離後アプリケーション５０２の段階における従来のアプリケーションの構成と、かかるアプリケーションとサービス層１０２の各ドライバーの関係を示した説明図である。同図に示すように、アプリケーション層１０１は、コピーアプリケーション１２０、スキャナアプリケーション１３０、ファックスアプリケーション１４０およびプリンタアプリケーション１５０を有する。

例えば、コピーアプリケーション１２０は、コピー機能を実現するために、スキャナ制御部１０２ａ、プロッタ制御部１０２ｂ、蓄積制御部１０２ｃおよびその他の制御部１０２ｇとデータの送受信をおこなう。また、ファックスアプリケーション１４０は、ファックス機能を実現するために、プロッタ制御部１０２ｂ、蓄積制御部１０２ｃ、ＦＡＸ送受信制御部１０２ｅ、ネットワーク通信制御部１０２ｆおよびその他の制御部１０２ｇとデータの送受信をおこなう。このように、アプリケーション層１０１の各アプリケーションとサービス層１０２の各ドライバー間の通信は、複雑なものとなっていた。

図３の説明に戻ると、上述したオブジェクトモデリングにより、アプリケーション層１０１に存在した複数のアプリケーションは、統合アプリケーション１１０に統合されている。そして、各アプリケーションが重複しておこなっていた各ドライバーとの通信処理は、統合アプリケーション１１０を構成する所定のオブジェクトモデルにおこなわせるように構成したことにより、アプリケーション層１０１のアプリケーションと、サービス層１０２の各ドライバー間の通信は、図１０と比較して単純になっている。

次に、統合アプリケーション１１０の内部構成について説明する。図４は、統合アプリケーション１１０の内部構成を示すブロック図である。同図に示すように、統合アプリケーション１１０は、操作系サブシステム１１１と、管理系サブシステム１１２と、実行系サブシステム１１３とを有する。

操作系サブシステム１１１は、マンマシンインタフェースおよびアプリ管理を担当するソフトウェア群である。具体的には、この操作系サブシステム１１１は、ユーザの要求を受け付ける処理と、この要求の実行を指示する処理と、この要求の実行状況と実行結果についての情報をユーザに提供する処理をおこなう。

管理系サブシステム１１２は、複合機１の資源を管理するソフトウェア群である。具体的には、この管理系サブシステム１１２は、ハードウェアリソース２０１およびこのハードウェアリソース２０１が保持するデータ状態を管理するサービスをおこなう。

実行系サブシステム１１３は、ユーザからの要求の実行を担当するソフトウェア群である。具体的には、この実行系サブシステム１１３は、コピー要求がなされた場合には、原稿の読み取りから成果物の出力までの処理をおこなう。

操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３は、必要に応じて相互に処理を依頼してその結果を送り合う。このようにそれぞれのサブシステムが協調し合って、統合アプリケーション１１０全体として複合機１に必要とされるサービスの提供をおこなう。

そして、操作系サブシステム１１１は、マンマシンインタフェースを担当する操作制御部１１１ａと、本実施の形態の特徴部分であるアプリ管理部１１１ｂとをさらに有する。このアプリ管理部１１１ｂは、管理対象となるアプリの振る舞いを決定する状態を管理し、この状態の移行可否判定および移行にともなう処理をおこなう処理部である。

図５は、図４に示した各サブシステムを、ＵＭＬ（Unified Modeling Language）のクラス図（ＵＭＬクラス図）に置き換えた図である。ここで、ＵＭＬとは、ＯＭＧ（Object Management Group）が仕様を策定しているシステムモデリング言語であり、モデリングの成果を記述する記法を定義したものである。このＵＭＬは、オブジェクト指向によるソフトウェアの設計において広く用いられている。

図５に示すように、統合アプリケーション１１０は複数のパッケージを有し、また、この統合アプリケーション１１０自体もひとつのパッケージとなっている。ここで、パッケージとはＵＭＬモデルの各構成要素（シンボル）をグループ化したものであり、左上にタブのついたフォルダの形をしたシンボルで表現される。また、各パッケージを相互に結ぶ直線は、各パッケージ間に処理依頼などの関連があることを示している。

図５に示したように、統合アプリケーション１１０は、操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３の３つのパッケージを内部に有するパッケージである。さらに、操作系サブシステム１１１は、操作制御部１１１ａと、本実施の形態の特徴部分であるアプリ管理部１１１ｂとを内部に有するパッケージである。

そして、操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３を相互に結ぶ直線は、各パッケージ間に処理依頼（例えば、メッセージ送受信）などの関連があることを示している。なお、操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３のタブの右端に記された記号は、かかるパッケージがサブシステムであることを示すＵＭＬのシンボルである。

次に、本実施の形態の特徴部分であるアプリ管理部１１１ｂについて詳細に説明する。なお、このアプリ管理部１１１ｂは、オブジェクト指向に基づいて設計するにあたって、既存の処理を単純にオブジェクト化せず、機能追加や改修をより一層容易におこなうことができるようにオブジェクトモデルを構成した。

図６は、アプリ管理部１１１ｂのクラス構成を示すＵＭＬクラス図である。

まず、クラスとＵＭＬクラス図におけるクラスの記述方法について説明しておく。クラスとは、オブジェクト指向システムを構成するオブジェクトの設計図に相当する概念であり、オブジェクト内部に有する属性と処理を定義するとともに、継承関係や集約関係といった、他のクラスとの関係を定義するものである。

ＵＭＬクラス図におけるクラスは、３段の区画を有する矩形として記述される。それぞれの区画は、上から、クラス名を示す名前区画、クラスが有するデータ（属性）を示す属性区画およびクラスが有する処理（操作）を示す操作区画と呼ばれる。例えば、機器クラス３１１を示す矩形の名前区画は、かかるクラスのクラス名が「機器」であることを示し、属性区画は、かかるクラスが有する属性が、「運用状態」であることを示し、操作区画は、かかるクラスが有する操作が、「設定開始（）」であることを示している。

このように、各クラスは、データ（属性）を保持するための属性区画と、かかる属性の書き込みおよび読み出しをおこなう処理（操作）を保持するための操作区画とを有している。これらのクラスは、プログラム（統合アプリケーション１１０）の一部として含まれるので、あらかじめＲＯＭ１２ａに格納されたこのプログラムが実行されると、各クラスはＲＡＭ１２ｂの所定領域に実体化され、属性区画に含まれる各データ（属性）がＲＡＭ１２ｂ上に展開される。したがって、クラスを実体化したオブジェクトは、ＲＡＭ１２ｂ上の各データ（属性）の書き込みおよび読み出しをすることが可能となる。

なお、属性や操作といったクラスの要素の左側に「−」記号を付した場合は、かかる要素は外部のクラスには非公開であることを示し、「＋」記号を付した場合は、かかる要素は外部のクラスに公開されていることを示す。また、操作については「設定開始（）」のように「（）」記号を付することが通例であり、「（引数１，引数２）」のように、かかる操作に引き渡す引数を記述する場合もある。

次に、本実施の形態の特徴部分であるアプリ管理部１１１ｂのクラスの概要について説明する。図６に示されるように、アプリ管理部１１１ｂは、機器状態管理部３１０、アプリ構成管理部３２０、及びアプリ状態管理部３３０に大別される。

機器状態管理部３１０は、複合機１全体に影響するような状態情報を管理し、機器クラス３１１及び省エネクラス３１２を含む。アプリ構成管理部３２０は、主にアプリケーションの構成を管理し、アプリクラス３２１、単一アプリクラス３２２及び複合アプリクラス３２３を含む。アプリ状態管理部３３０は、各アプリケーションの状態を管理し、設定情報クラス３３１、ＳＰ（Ｓｅｒｖｉｃｅ Ｐｒｏｇｒａｍ）設定情報クラス３３２、ＵＰ（Ｕｓｅｒ Ｐｒｏｇｒａｍ）設定情報クラス３３３及び画面クラス３３４を含む。これら、各クラスについて以下に説明する。

機器クラス３１１は、一つのインスタンスが一台の機器（複合機１）に対応し、複合機１の利用制限に関する状態を管理するとともに、電力状態とアプリケーションの状態との調停を行うクラスである。機器クラス３１１は、属性として状態３１１ａを有し、操作としてアプリ利用（）３１２ｂを有する。

状態３１１ａは、複合機１が機能を提供しているのか、又は複合機１に対する何らかの利用制限がかかっているのかといった複合機１に対する利用制限状態を保持する。

アプリ利用（）３１２ｂは、アプリケーションの利用要求を受け付けるための操作であり、呼び出しに応じて、複合機１の全体的なレベルの粒度での利用可否を判定し、利用可能と判定した場合にアプリケーションの処理を実行させる。例えば、複合機１における電力状態等が利用可否の判定材料となる。

省エネクラス３１２は、現在の機器の電力状態を知っており、その電力状態の切替要求に対する切替可否判断と切替処理を行うクラスである。省エネクラス３１２は、属性として状態３１２ａを有し、操作として解除（）３１２ｂを有する。

状態３１２ａは、複合機１の現在の電力状態を保持する。電力状態には例えば、通常待機状態や省電力状態といった複数の段階があり、各段階において電力の供給状態が異なる。通常待機状態とは、複合機１がサービス提供可能な状態で待機している状態のことをいう。省電力状態とは、電力消費を抑えるために所定箇所への電力供給を停止したり抑制したりしている状態のことをいう。例えば、この省電力状態では操作パネルを非表示にすることが行われる。なお、この省電力状態にさらに複数の段階を設けることとしてもよい。

解除（）３１２ｂは、機器クラス３１１を実体化した機器オブジェクト３１１Ａから呼び出され、省電力状態を解除して通常待機状態に戻す処理をおこなう。

アプリクラス３２１は、各アプリケーションの動作制限状態を管理すると共に、アプリケーションの利用要求がなされた際に当該アプリケーションの利用の可否判断等の処理を行うクラスである。アプリクラス３２１は、属性として状態３２１ａ及び種類３２１ｂを有し、操作として利用（）３２１ｃを有する。

状態３２１ａは、アプリケーションが提供できる動作に対する制限の有無を示す動作制限状態を保持する。状態３２１ａの値が「無し」の場合は、アプリケーションが機能を縮退させることなく機能提供を行っている状態を示す。一方、状態３２１ａの値が「有り」の場合は、アプリケーションが機能を縮退させて機能提供を行っている状態を示す。なお、動作制限状態は、設定情報の設定等の要因により変化する。

種類３２１ｂは、各アプリケーションの種類を識別するための情報を保持する。例えば、「コピーアプリ」、「送信アプリ」、「プリンタアプリ」又は「複合アプリ」等の値が保持される。

利用（）３２１ｃは、アプリケーションが現在提供している機能を利用して、要求された機能を実行する。機能を実行するためには画面（操作パネル）と設定情報とを用いる必要があるため、機能の実行にあたり、画面クラス３３４及び設定情報クラス３３１とのメッセージのやりとりが発生する。

単一アプリクラス３２２は、アプリクラス３２１のサブクラスであり、単一機能のアプリケーション（以下「単一アプリ」という。）に対応する。

複合アプリクラス３２３は、アプリクラス３２１のサブクラスであり、複数の機能が複合されたアプリケーション（例えば、上述における統合アプリケーション１１０のようなアプリケーション、以下「複合アプリ」という。）に対応する。

設定情報クラス３３１は、アプリケーションの動作に必要とされる設定情報を表しており、現在の設定情報の利用状態を管理する。設定情報クラス３３１は、属性として状態３３１ａ及び参照数３３１ｂを有し、操作として参照（）３３１ｃを有する。

状態３３１ａは、設定情報が、現在参照されているのか、編集されているのか、といった設定情報の編集状態を保持する。

参照数３３１ｂは、現在設定情報を参照している利用者数を保持する。

参照（）３３１ｃは、アプリケーションの設定情報を参照させるために必要な処理を行う。

ＳＰ設定情報クラス３３２は、設定情報クラス３３１のサブクラスであり、サービスパーソン用に特化した設定情報を管理する。

ＵＰ設定情報クラス３３３は、設定情報クラス３３１のサブクラスであり、一般利用者用に特化した設定情報を管理する。

画面クラス３３４は、アプリケーションが利用者とやり取りをするための操作パネルを独占的に利用するための権利（操作部利用権）の保持状態を管理し、操作部利用権の保持状態の切替要求に対する切替可否判断と切替処理とを行うクラスである。画面クラス３３４は、属性として状態３３４ａを有し、操作として獲得（）３３４ｂを有する。

状態３３４ａは、操作部利用権を取得しているか否かの利用権状態を保持する。利用権状態が「有り」とは、操作部利用権を取得した状態を表しており、利用権状態が「無し」とは、操作部利用権を取得する必要がなく操作部利用権を取得していない状態を表している。すなわち、利用者が複合機１を操作して任意の機能を利用する場合、当該機能を提供するアプリケーションは、操作部利用権を取得する必要がある。本実施の形態における複合機１には、一つの操作パネルが実装されているため、同時に二つ以上のアプリケーションが操作部利用権を取得することはできない。

獲得（）３３４ｂは、操作部利用権を取得していない場合に、操作部利用権を取得するための処理を行う。

次に、図６に示した各クラス間の関係について説明する。同図に示したように、ＵＭＬクラス図においては、クラス間に何らかの関係がある場合には、それらのクラスを表す矩形の間が直線で結ばれる。この直線の両端付近の数字はクラスの多重度を表す。多重度とは、直線で結ばれた他方のクラスのオブジェクトと関連付けられて生成されるオブジェクトの数のことである。

例えば、図中において機器クラス３１１と省エネクラス３１２との関係において、機器クラス３１１の多重度は「１」であり、省エネクラス３１２の多重度は「１」である。これは、機器クラス３１１のインスタンスである機器オブジェクト３１１Ａと、省エネクラス３１２のインスタンスである省エネオブジェクト３１２Ａとは１対１に関連付けられることを意味する。

まず、機器クラス３１１と省エネクラス３１２とのクラス関係について説明する。省エネクラス３１２は、複合機１の電力状態を管理するクラスであるので、複合機１内に１個だけ存在する。また、上述したように機器クラス３１１も複合機１内に１個だけ存在する。したがって、一つの機器オブジェクト３１１Ａは、一つの省エネオブジェクト３１２Ａを集約する。

次に、機器クラス３１１とアプリクラス３２１とのクラス関係について説明する。アプリクラス３２１は複合機１内の各アプリケーションと１対１に対応している。また、機器クラス３１１のインスタンス（機器オブジェクト３１１Ａ）は複合機１内に１個だけ存在しており、アプリクラス３２１のインスタンス（アプリオブジェクト３２１Ａ）の全てを管理している。従って、一つの機器オブジェクト３１１Ａは、０個以上ｎ個以下のアプリオブジェクト３２１Ａを集約する。

ところで、アプリクラス３２１は、抽象クラスであるため、厳密にはアプリクラス３２１のインスタンスは生成されることはない。したがって、本実施の形態において、「アプリクラス３２１のインスタンス」、又は「アプリオブジェクト３２１Ａ」というとき、アプリクラス３２１のサブクラス（単一アプリクラス３２２又は複合アプリクラス３２３）のインスタンスのことをいう。

次に、アプリクラス３２１と画面クラス３３４とのクラス関係について説明する。各アプリケーションが獲得できる操作部利用権は一つのみである。したがって、一つのアプリオブジェクト３２１Ａは、一つの画面オブジェクト３３４Ａを集約する。

次に、アプリクラス３２１と設定情報クラス３３１とのクラス関係について説明する。一つのアプリケーションは、０以上の設定情報を必要とする。したがって、１個のアプリオブジェクト３２１Ａは、０個以上ｎ個以下の設定情報オブジェクト３３１Ａを集約する。

ところで、設定情報クラス３３１は、抽象クラスであるため、厳密には設定情報クラス３３１のインスタンスは生成されることはない。したがって、本実施の形態において、「設定情報クラス３３１のインスタンス」、又は「設定情報オブジェクト３３１Ａ」というとき、設定情報クラス３３１のサブクラス（ＳＰ設定情報クラス３３２又はＵＰ設定情報クラス３３３）のインスタンスのことをいう。

なお、単一アプリクラス３２２及び複合アプリクラス３２３は、アプリクラス３２１のサブクラスであるため、アプリクラス３２１の性質（属性、操作、関連等）を継承する。また、ＳＰ設定情報クラス３３２及びＵＰ設定情報クラス３３３は、設定情報クラス３３１のサブクラスであるため、設定情報クラス３３１の性質を継承する。

ところで、複合アプリクラス３２３は、アプリクラス３２１を継承しているだけでなく、関連ｒ１によってアプリクラス３２１を集約している。関連ｒ１の多重度によれば、一つの複合アプリオブジェクト３２３Ａは、２個以上ｎ個以下のアプリオブジェクト３２１を集約する。この関連ｒ１によって複合アプリの階層構造が表現されている。ここでいう、階層構造とは、アプリケーションをその機能面から分類した場合に構成される階層構造をいう。

図７は、複合機におけるアプリケーションの階層構造の例を説明するための図である。図７では、複合機１からみると統合アプリとプリンタアプリとの二つのアプリケーションが実装されていることが示されている。ここで、統合アプリは複合アプリであるため、二つ以上のアプリケーションを含む。図中では、コピーアプリと送信アプリとが統合アプリに含まれている。更に、送信アプリは複合アプリであるため、通常送信アプリとリモート送信アプリとを含む。

図７の階層構造を図６のクラス図に当てはめてみると、統合アプリは、複合アプリオブジェクト３２３Ａとしてインスタンス化される。当該複合アプリオブジェクト３２３Ａは、コピーアプリに対応する単一アプリオブジェクト３２２Ａと、送信アプリに対応する複合アプリオブジェクト３２３Ａとを集約する。更に、送信アプリに対応する複合アプリオブジェクト３２３Ａは、通常送信アプリとリモート送信アプリとのそれぞれに対応する二つの単一アプリオブジェクト３２２を集約する。

このように、アプリ構成管理部３２０におけるクラス構成によって、複合機１におけるアプリケーションの階層構造をオブジェクトの関連によって適切に表現することができる。

次に、図６に示した各クラスの操作の実行手順について例をあげて説明する。図８は、アプリ管理部がアプリケーションの利用要求を受けた際の処理手順の一例を説明するためのＵＭＬシーケンス図である。

ここで、ＵＭＬシーケンス図について説明しておく。図８の上部に並んだ矩形は、それぞれがクラスのインスタンス（オブジェクト）を示している。各オブジェクトから下方に伸びた線は、各オブジェクトが生存していることを示す線（ライフライン）であり、上方から下方に向かって時間が流れているものとみなされる。この線上に存在する細長い矩形は、当該のオブジェクトが実際に活動している期間（活性期間）を示す。そして、各ライフラインの間を結ぶ横向きの矢印は、オブジェクトに含まれる操作の実行を示す。具体的には、この矢印は、矢印の元のオブジェクトが、矢印の先のオブジェクトに含まれる操作を呼び出すことを示す。

機器オブジェクト３１１Ａは、操作系サブシステム１１１の操作制御部１１１ａよりアプリ利用（）３１２ｂを呼び出されることにより、利用者のアプリケーションの利用要求を受け付ける（Ｓ１０１）。機器オブジェクト３１１Ａは、アプリケーションの利用を開始するためには複合機１が利用制限中で無いことと、複合機１の電力状態を変えなければならないことを知っており、これらの条件を総合的にみて、複合機１全体のレベルの粒度としてアプリケーションの利用可否の判断を行う。

まず、機器オブジェクト３１１Ａは状態３１１ａを参照し、複合機１が現在利用制限中であるか否かを判断する。利用制限中でない場合、機器オブジェクト３１１Ａは、省エネオブジェクト３１２Ａの解除（）３１２ｂを呼び出すことにより、省エネオブジェクト３１２Ａに対して省電力状態の解除を要求する（Ｓ１０２）。

省エネオブジェクト３１２Ａは、状態３１２ａを参照し、省電力状態である場合は通常待機状態への復帰処理を行い、通常待機状態へ復帰できたか否かを機器オブジェクト３１１Ａに返却する。なお、通常待機状態へ復帰できた場合、省エネオブジェクト３１２Ａは、状態３１２ａの値を通常待機状態に変更する。

複合機１が利用制限中でなく、電力状態も通常待機状態となった場合、機器オブジェクト３１１Ａは、複合機１のレベルでアプリケーションは利用可能と判断し、利用が要求されたアプリケーションに対応するアプリオブジェクト３２１Ａの利用（）３２１ｃを呼び出す（Ｓ１０３）。

利用（）３２１ｃを呼び出されたアプリオブジェクト３２１Ａが複合アプリクラス３２３のインスタンスである場合、当該アプリオブジェクト３２１Ａは、自らが集約しているアプリオブジェクト３２１Ａの利用３２１ｃを呼び出す（Ｓ１０４）。したがって、利用（）３２１ｃに実装された以下の処理が、アプリケーションの階層構造に応じて階層的に実行される。

利用（）３２１ｃ内において、アプリオブジェクト３２１Ａは、アプリケーションレベルでの利用可否判断処理を実行する。

まず、アプリオブジェクト３２１Ａは、は自らの状態３２１ａを参照し、現在動作制限中であるか否かを判断する。動作制限中でない場合、アプリオブジェクト３２１Ａは、自らが有している画面オブジェクト３３４Ａの獲得（）３３４ｂを呼び出し、操作部利用権の獲得を要求する（Ｓ１０５）。

画面オブジェクト３３４Ａは、自らの状態３３４ａを参照し、操作部利用権の有無を確認する。操作部利用権が無い場合、画面オブジェクト３３４Ａは、操作部利用権を獲得するための処理を実行し、獲得の成否をアプリオブジェクト３２１Ａに返却する。

続いて、アプリオブジェクト３２１Ａは、設定情報オブジェクト３３１Ａの参照（）３３１ｃを呼び出すことにより、当該アプリケーションに対する設定情報の参照を要求する（Ｓ１０６）。設定情報オブジェクト３３１Ａは、自らの状態３３１ａを参照し、編集中でなければ、設定情報を参照させるための処理を行い、その成否をアプリオブジェクト３２１Ａに返却する。

アプリオブジェクト３２１Ａは、自らの状態３２１ａ、操作部利用権の獲得の成否、及び設定情報の参照の成否に基づいて、当該アプリケーションの利用の可否を判断し、その判断結果に応じて、アプリケーションを利用させるための処理を実行する。

上述したように、本実施の形態における複合機１においては、アプリケーションをその機能に基づいて階層的に分類し、かかる階層的な分類を適切に表現できるようなオブジェクト指向設計に基づくモデルによってアプリ管理部１１１ｂが実装されている。したがって、様々なアプリケーションの構成に柔軟に対応することができ、汎用的なアプリケーション管理の仕組みを効率よく実現することができる。

したがって、アプリケーションの機能の追加・削除に対するメンテナンスも容易に行うことができ、開発作業や保守作業等の工数削減を期待することもできる。

なお、本実施の形態の複合機１で実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（CD Recordable）、ＤＶＤ（Digital Versatile Disk）などのコンピュータで読み取り可能な記録媒体に記録して提供するよう構成してもよい。この場合、ＣＰＵ１１が上記記憶媒体から、当該プログラムを読み出してＭＥＭ−Ｐ１２上にロードすることで、複合機に、上述した各ステップ、各手段または各部を実現させる。

また、当該プログラムを、インターネットなどのネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するよう構成してもよい。さらに、当該プログラムをインターネットなどのネットワーク経由で提供または配布するようにしてもよい。

以上、本発明の実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

複合機をとりまくネットワーク環境を示すネットワーク図である。 複合機のハードウェアを説明するための説明図である。 複合機におけるハードウェアおよびソフトウェアの階層構造を説明するための説明図である。 統合アプリケーションの構成を説明するための説明図である。 統合アプリケーションの構成を表したＵＭＬクラス図である。 アプリ管理部のクラス構成を示すＵＭＬクラス図である。 複合機におけるアプリケーションの階層構造の例を説明するための図である。 アプリ管理部がアプリケーションの利用要求を受けた際の処理手順の一例を説明するためのＵＭＬシーケンス図である。 複合機に搭載されるソフトウェア構成の変遷を示す説明図である。 従来の複合機におけるハードウェアおよびソフトウェアの階層構造を説明するための説明図である。

符号の説明

１ 画像形成装置（複合機）
１０ コントローラ
１１ ＣＰＵ
１２ ＭＥＭ−Ｐ
１２ａ ＲＯＭ
１２ｂ ＲＡＭ
１３ ＮＢ
１４ ＳＢ
１５ ＡＧＰ
１６ ＡＳＩＣ
１７ ＭＥＭ−Ｃ
１８ ＨＤＤ
２０ キーボード（オペレーションパネル）
３０ ＦＣＵ
４０ ＵＳＢ
５０ ＩＥＥＥ１３９４
６０ エンジン部（Engine）
１００ ソフトウェア
１０１ アプリケーション層
１０２ サービス層
１０２ａ スキャナ制御部
１０２ｂ プロッタ制御部
１０２ｃ 蓄積制御部
１０２ｄ 配信／メール送受信制御部
１０２ｅ ＦＡＸ送受信制御部
１０２ｆ ネットワーク通信制御部
１０２ｇ その他の制御部
１０３ オペレーティングシステム
１１０ 統合アプリケーション
１１１ 操作系サブシステム
１１１ａ 操作制御部
１１１ｂ アプリ管理部
１１２ 管理系サブシステム
１１３ 実行系サブシステム
１２０ コピーアプリケーション
１３０ スキャナアプリケーション
１４０ ファックスアプリケーション
１５０ プリンタアプリケーション
２００ ハードウェア
２０１ ハードウェアリソース
２０１ａ スキャナ
２０１ｂ プロッタ
２０１ｃ ＨＤＤ
２０１ｄ ネットワーク
２０１ｅ その他のリソース
３１０ 機器状態管理部
３１１ 機器クラス
３１１Ａ 機器オブジェクト
３１１ａ 状態
３１１ｂ アプリ利用（）
３１２ 省エネクラス
３１２Ａ 省エネオブジェクト
３１２ａ 状態
３１２ｂ 解除（）
３２０ アプリ構成管理部
３２１ アプリクラス
３２１Ａ アプリオブジェクト
３２１ａ 状態
３２１ｂ 種類
３２１ｃ 利用（）
３２２ 単一アプリクラス
３２２Ａ 単一アプリオブジェクト
３２３ 複合アプリクラス
３２３Ａ 複合アプリオブジェクト
３３０ アプリ状態管理部
３３１ 設定情報クラス
３３１Ａ 設定情報オブジェクト
３３１ａ 状態
３３１ｂ 参照数
３３１ｃ 参照（）
３３２ ＳＰ設定情報
３３３ ＵＰ設定情報
３３４ 画面クラス
３３４Ａ 画面オブジェクト
３３４ａ 状態
３３４ｂ 獲得（）

Claims (6)

1. 複数のアプリケーションを実行する統合アプリケーションを備えた画像形成装置であって、
   前記アプリケーションの実行要求に応じ当該画像形成装置の状態に基づいて前記アプリケーションの利用の可否判断を行う機器状態管理手段と、
   前記アプリケーションの構成を管理するアプリ構成管理手段と、
   前記アプリケーションごとに当該アプリケーションの利用の可否判断の要因となる状態情報を管理するアプリ状態管理手段とを有し、
   前記アプリ構成管理手段は、前記アプリケーションごとの状態に基づいて当該アプリケーションの利用の可否判断を行うアプリケーション管理手段を有し、当該アプリケーション管理手段によって前記アプリケーションを階層構造で管理し、
   さらに、前記アプリ構成管理手段は、単一のアプリケーションに対応する前記アプリケーション管理手段および複数のアプリケーションに対応する前記アプリケーション管理手段のうちの少なくとも一方の２つ以上を集約する前記アプリケーション管理手段を有することを特徴とする画像形成装置。
2. 前記機器状態管理手段は、
   当該画像形成装置の利用制限に関する状態を管理する利用状態管理手段と、
   当該画像形成装置の電力状態を管理する電力状態管理手段とを有し、
   前記利用制限に関する状態と、前記電力状態とに基づいて前記アプリケーションの利用の可否判断を行うことを特徴とする請求項１記載の画像形成装置。
3. 前記アプリ状態管理手段は、
   前記アプリケーションが当該画像形成装置の操作パネルを利用する権利を有しているか否かを管理する操作部利用権管理手段と、
   前記アプリケーションに対する設定情報の編集状態を管理する設定情報管理手段とを有することを特徴とする請求項１又は２記載の画像形成装置。
4. 複数のアプリケーションを実行する統合アプリケーションを備えた画像形成装置を、
   前記アプリケーションの実行要求に応じ当該画像形成装置の状態に基づいて前記アプリケーションの利用の可否判断を行う機器状態管理手段と、
   前記アプリケーションの構成を管理するアプリ構成管理手段と、
   前記アプリケーションごとに当該アプリケーションの利用の可否判断の要因となる状態情報を管理するアプリ状態管理手段として機能させるためのアプリケーション管理プログラムであって、
   前記アプリ構成管理手段は、前記アプリケーションごとの状態に基づいて当該アプリケーションの利用の可否判断を行うアプリケーション管理手段を有し、当該アプリケーション管理手段によって前記アプリケーションを階層構造で管理し、
   さらに、前記アプリ構成管理手段は、単一のアプリケーションに対応する前記アプリケーション管理手段および複数のアプリケーションに対応する前記アプリケーション管理手段のうちの少なくとも一方の２つ以上を集約する前記アプリケーション管理手段を有することを特徴とするアプリケーション管理プログラム。
5. 前記機器状態管理手段は、
   当該画像形成装置の利用制限に関する状態を管理する利用状態管理手段と、
   当該画像形成装置の電力状態を管理する電力状態管理手段とを有し、
   前記利用制限に関する状態と、前記電力状態とに基づいて前記アプリケーションの利用の可否判断を行うことを特徴とする請求項４記載のアプリケーション管理プログラム。
6. 前記アプリ状態管理手段は、
   前記アプリケーションが当該画像形成装置の操作パネルを利用する権利を有しているか否かを管理する操作部利用権管理手段と、
   前記アプリケーションに対する設定情報の編集状態を管理する設定情報管理手段とを有することを特徴とする請求項４又は５記載のアプリケーション管理プログラム。

Images