以下、図面に基づいて本発明の実施の形態を説明する。なお、本実施の形態では、この発明を画像形成装置に適用した場合について説明するが、本発明はこれに限らず、アプリ管理をおこなう各種装置に適用することができる。
まず、本実施の形態に係る画像形成装置(以下「複合機」と言う)1の概要について図1、図2、図3、図9および図10を用いて説明する。図1は、本実施の形態に係る複合機1を取り巻くネットワーク環境を説明するためのネットワーク図であり、図2は、図1に示した複合機1のハードウェア構成を示すブロック図であり、図3は、図1に示した複合機1のソフトウェアとハードウェアの関係を説明するための説明図である。また、図9は、複合機1に搭載されるソフトウェア構成の変遷を説明するための説明図であり、図10は、従来の複合機のソフトウェアとハードウェアの関係を説明するための説明図である。
図1に示すように、近年のネットワーク化の進展により、オフィスなどに設けられたパーソナルコンピュータ(PC)などの機器は、LAN(Local Area Network)などのネットワークに接続され、相互に通信することが通常となった。例えば、同図に示したように、かかるネットワークには、クライアントPC、SMTP(Simple Mail Transfer Protocol)サーバ、FTP(File Transfer Protocol)サーバ、サーバPCなどが接続され、電子メールの送受信やファイル転送をすることができ、モデム接続された配信サーバは、オフィス外のファックス装置と通信することができる。
このようなネットワーク化の進展に伴い、複合機1もネットワークに接続され、PC等の機器と相互に通信することが可能となり、ハードディスク等の記憶装置を内蔵することで、いわゆるネットワーク複合機へと進化し、ユーザの様々なニーズに応えることができるようになった。
例えば、複合機1は、通常のコピー機能に加えて、クライアントPCからの印刷要求により文書データ等を印刷するプリンタ機能、クライアントPCからのファックス要求により文書データ等をサーバPCに接続されたモデムを経由して他のオフィスのファックス機器に送信するファックス機能、受信したファックス文書やコピー文書を内蔵したハードディスクに蓄積する蓄積機能などを有するようになった。
こうして複合化とネットワーク化の進展により必要となった多くの機能を実現するため、複合機1に搭載されるソフトウェアは、規模が大きく、複雑なものとなっている。そして、それにともなって、それらのソフトウェアの開発と維持管理のための工数も大幅に増大している。
図2は、かかる複合機1のハードウェア構成を示すブロック図である。同図に示すように、この複合機1は、コントローラ10とエンジン部(Engine)60とをPCI(Peripheral Component Interconnect)バスで接続した構成となる。コントローラ10は、複合機1全体の制御と描画、通信、図示しない操作部からの入力を制御するコントローラである。エンジン部60は、PCIバスに接続可能なプリンタエンジンなどであり、例えば白黒プロッタ、1ドラムカラープロッタ、4ドラムカラープロッタ、スキャナまたはファックスユニットなどである。なお、このエンジン部60には、プロッタなどのいわゆるエンジン部分に加えて、誤差拡散やガンマ変換などの画像処理部分が含まれる。
コントローラ10は、CPU11と、ノースブリッジ(NB)13と、システムメモリ(MEM−P)12と、サウスブリッジ(SB)14と、ローカルメモリ(MEM−C)17と、ASIC(Application Specific Integrated Circuit)16と、ハードディスクドライブ(HDD)18とを有し、ノースブリッジ(NB)13とASIC16との間をAGP(Accelerated Graphics Port)バス15で接続した構成となる。また、MEM−P12は、ROM(Read Only Memory)12aと、RAM(Random Access Memory)12bとをさらに有する。
CPU11は、複合機1の全体制御をおこなうものであり、NB13、MEM−P12およびSB14からなるチップセットを有し、このチップセットを介して他の機器と接続される。
NB13は、CPU11とMEM−P12、SB14、AGP15とを接続するためのブリッジであり、MEM−P12に対する読み書きなどを制御するメモリコントローラと、PCIマスタおよびAGPターゲットとを有する。
MEM−P12は、プログラムやデータの格納用メモリ、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いるシステムメモリであり、ROM12aとRAM12bとからなる。ROM12aは、プログラムやデータの格納用メモリとして用いる読み出し専用のメモリであり、RAM12bは、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いる書き込みおよび読み出し可能なメモリである。
SB14は、NB13とPCIデバイス、周辺デバイスとを接続するためのブリッジである。このSB14は、PCIバスを介してNB13と接続されており、このPCIバスには、ネットワークインターフェース(I/F)部なども接続される。
ASIC16は、画像処理用のハードウェア要素を有する画像処理用途向けのIC(Integrated Circuit)であり、AGP15、PCIバス、HDD18およびMEM−C17をそれぞれ接続するブリッジの役割を有する。このASIC16は、PCIターゲットおよびAGPマスタと、ASIC16の中核をなすアービタ(ARB)と、MEM−C17を制御するメモリコントローラと、ハードウェアロジックなどにより画像データの回転などをおこなう複数のDMAC(Direct Memory Access Controller)と、エンジン部60との間でPCIバスを介したデータ転送をおこなうPCIユニットとからなる。このASIC16には、PCIバスを介してFCU(Fax Control Unit)30、USB(Universal Serial Bus)40、IEEE1394(the Institute of Electrical and Electronics Engineers 1394)インターフェース50が接続される。
MEM−C17は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、HDD(Hard Disk Drive)18は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積を行うためのストレージである。
AGP15は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェースであり、MEM−P12に高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にするものである。
図3は、かかる複合機1のハードウェアおよびソフトウェアの構成を示した概念図であり、具体的には、後述する本実施の形態の特徴部分であるアプリ管理部111bを含む統合アプリケーション110と、ソフトウェア100およびハードウェア200の階層関係を示している。同図に示すように、ハードウェア200は、ハードウェアリソース201を有し、このハードウェアリソース201は、スキャナ201a、プロッタ201b、HDD(Hard Disk Drive)201c、ネットワーク201dおよびその他のリソース201eを有する。なお、その他のリソース201eは、201a〜201d以外のハードウェアリソース201のことであり、例えば、操作パネルなどの入出力デバイスを示す。
また、かかるハードウェア200に搭載されるソフトウェア100は階層化されており、オペレーティングシステム103の上層にはサービス層102が構築され、このサービス層102の上層にはアプリケーション層103が構築されている。そして、サービス層102は、各ハードウェアリソース(201a〜201e)を制御するドライバーに相当する、スキャナ制御102部a、プロッタ制御部102b、蓄積制御部102c、配信/メール送受信制御部102d、FAX送受信制御部102e、ネットワーク通信制御部102fおよびその他の制御部102gを有する。
ここで、図3に示したソフトウェア100が、かかる階層構造をとるに至った経緯について、図9および図10を用いて説明する。図9は、複合機1に搭載されるソフトウェア構成の変遷を示す説明図である。図9のサービス層分離前アプリケーション501に示すように、多機能化した複合機1に搭載されるソフトウェアは、コピーアプリケーション、FAXアプリケーション、スキャナアプリケーションなどの機能別に独立したアプリケーションとして作成され、図3に示したオペレーティングシステム103上で動作していた。
しかしながら、これらのアプリケーションは、ハードウェアリソースを制御するドライバー(サービス層102)を含んでいたため、各アプリケーションには重複した処理が存在していた。その結果、各アプリケーションの規模は大きなものとなっていた。
そこで、図9のサービス層分離後アプリケーション502に示すように、サービス層分離前アプリケーション501のサービス層102相当部分を括りだしサービス層102とするとともに、各アプリケーションは、このサービス層102の上層であるアプリケーション層101に構築する構成とした。かかる階層化構成をとることにより、各アプリケーションはスリム化され開発労力も軽減された。
しかしながら、複合機1のネットワーク化、多機能化がさらに進展するに従って、各アプリケーションに共通処理部分が存在することが問題となってきた。具体的には、アプリケーション層101の各アプリケーション、例えば、コピーアプリケーションやスキャナアプリケーションなどは、それぞれ、スキャナ制御部102aや蓄積制御部102cといったドライバーと通信をおこなう処理などの同様な処理を内部に有していた。このように、同様な処理を各アプリケーションが有していると、各アプリケーションの開発規模が大きくなるとともに、サービス層の仕様変更に対する各アプリケーションの改修規模が大きくなることが問題となってきた。
この問題を解決するため、図9の共通ルーチン分離アプリケーション503に示すように、かかる同様な処理(共通処理部分)を共通ルーチンとして括りだすことも考えられた。しかしながら、かかる共通ルーチンは、各アプリケーションにおいて微妙に異なる処理を共通化しようとするものであるため、共通ルーチン内部の処理は複雑なものとなってしまう。また、例えば、プリンタアプリケーションなどの新規アプリケーションを追加する場合においては、かかる新規アプリケーションに適応するために、共通ルーチンの改修が必要となる。
しかし、共通ルーチンの内部処理は複雑であるため、改修要員が処理を把握することが困難となり、改修規模の増大や、改修ミスによる他のアプリケーションへの影響が懸念された。
そこで、図9のオブジェクト指向アプリケーション504に示すように、オブジェクト指向による設計手法(オブジェクトモデリング)により、かかる複数のアプリケーションを、統合アプリケーション110に統合することとした。具体的には、各アプリケーションの共通処理部分をオブジェクトモデルとして抽出し、このオブジェクトモデルの集合体から、統合アプリケーション110を構成する。そして、従来のコピー機能やスキャナ機能といった機能は、かかるオブジェクトモデルの協調関係によって実現する。
このような構成をとることにより、例えばプリンタ機能のような新規機能の追加は、かかるオブジェクトモデルに属するクラスのサブクラス化などにより対処できる。このため、改修部分が明確となり、改修による他の機能への影響を小さくすることができる。また、オブジェクトモデリングによるプログラムは、従来の手続き型プログラムに比べて、処理の把握が容易であるため、改修要員が処理を把握することも容易となり、改修規模の削減や、改修ミスによる他のアプリケーションへの影響を小さくすることができる。
図10は、図9に示したサービス層分離後アプリケーション502の段階における従来のアプリケーションの構成と、かかるアプリケーションとサービス層102の各ドライバーの関係を示した説明図である。同図に示すように、アプリケーション層101は、コピーアプリケーション120、スキャナアプリケーション130、ファックスアプリケーション140およびプリンタアプリケーション150を有する。
例えば、コピーアプリケーション120は、コピー機能を実現するために、スキャナ制御部102a、プロッタ制御部102b、蓄積制御部102cおよびその他の制御部102gとデータの送受信をおこなう。また、ファックスアプリケーション140は、ファックス機能を実現するために、プロッタ制御部102b、蓄積制御部102c、FAX送受信制御部102e、ネットワーク通信制御部102fおよびその他の制御部102gとデータの送受信をおこなう。このように、アプリケーション層101の各アプリケーションとサービス層102の各ドライバー間の通信は、複雑なものとなっていた。
図3の説明に戻ると、上述したオブジェクトモデリングにより、アプリケーション層101に存在した複数のアプリケーションは、統合アプリケーション110に統合されている。そして、各アプリケーションが重複しておこなっていた各ドライバーとの通信処理は、統合アプリケーション110を構成する所定のオブジェクトモデルにおこなわせるように構成したことにより、アプリケーション層101のアプリケーションと、サービス層102の各ドライバー間の通信は、図10と比較して単純になっている。
次に、統合アプリケーション110の内部構成について説明する。図4は、統合アプリケーション110の内部構成を示すブロック図である。同図に示すように、統合アプリケーション110は、操作系サブシステム111と、管理系サブシステム112と、実行系サブシステム113とを有する。
操作系サブシステム111は、マンマシンインタフェースおよびアプリ管理を担当するソフトウェア群である。具体的には、この操作系サブシステム111は、ユーザの要求を受け付ける処理と、この要求の実行を指示する処理と、この要求の実行状況と実行結果についての情報をユーザに提供する処理をおこなう。
管理系サブシステム112は、複合機1の資源を管理するソフトウェア群である。具体的には、この管理系サブシステム112は、ハードウェアリソース201およびこのハードウェアリソース201が保持するデータ状態を管理するサービスをおこなう。
実行系サブシステム113は、ユーザからの要求の実行を担当するソフトウェア群である。具体的には、この実行系サブシステム113は、コピー要求がなされた場合には、原稿の読み取りから成果物の出力までの処理をおこなう。
操作系サブシステム111、管理系サブシステム112および実行系サブシステム113は、必要に応じて相互に処理を依頼してその結果を送り合う。このようにそれぞれのサブシステムが協調し合って、統合アプリケーション110全体として複合機1に必要とされるサービスの提供をおこなう。
そして、操作系サブシステム111は、マンマシンインタフェースを担当する操作制御部111aと、本実施の形態の特徴部分であるアプリ管理部111bとをさらに有する。このアプリ管理部111bは、管理対象となるアプリの振る舞いを決定する状態を管理し、この状態の移行可否判定および移行にともなう処理をおこなう処理部である。
図5は、図4に示した各サブシステムを、UML(Unified Modeling Language)のクラス図(UMLクラス図)に置き換えた図である。ここで、UMLとは、OMG(Object Management Group)が仕様を策定しているシステムモデリング言語であり、モデリングの成果を記述する記法を定義したものである。このUMLは、オブジェクト指向によるソフトウェアの設計において広く用いられている。
図5に示すように、統合アプリケーション110は複数のパッケージを有し、また、この統合アプリケーション110自体もひとつのパッケージとなっている。ここで、パッケージとはUMLモデルの各構成要素(シンボル)をグループ化したものであり、左上にタブのついたフォルダの形をしたシンボルで表現される。また、各パッケージを相互に結ぶ直線は、各パッケージ間に処理依頼などの関連があることを示している。
図5に示したように、統合アプリケーション110は、操作系サブシステム111、管理系サブシステム112および実行系サブシステム113の3つのパッケージを内部に有するパッケージである。さらに、操作系サブシステム111は、操作制御部111aと、本実施の形態の特徴部分であるアプリ管理部111bとを内部に有するパッケージである。
そして、操作系サブシステム111、管理系サブシステム112および実行系サブシステム113を相互に結ぶ直線は、各パッケージ間に処理依頼(例えば、メッセージ送受信)などの関連があることを示している。なお、操作系サブシステム111、管理系サブシステム112および実行系サブシステム113のタブの右端に記された記号は、かかるパッケージがサブシステムであることを示すUMLのシンボルである。
次に、本実施の形態の特徴部分であるアプリ管理部111bについて詳細に説明する。なお、このアプリ管理部111bは、オブジェクト指向に基づいて設計するにあたって、既存の処理を単純にオブジェクト化せず、機能追加や改修をより一層容易におこなうことができるようにオブジェクトモデルを構成した。
図6は、アプリ管理部111bのクラス構成を示すUMLクラス図である。
まず、クラスとUMLクラス図におけるクラスの記述方法について説明しておく。クラスとは、オブジェクト指向システムを構成するオブジェクトの設計図に相当する概念であり、オブジェクト内部に有する属性と処理を定義するとともに、継承関係や集約関係といった、他のクラスとの関係を定義するものである。
UMLクラス図におけるクラスは、3段の区画を有する矩形として記述される。それぞれの区画は、上から、クラス名を示す名前区画、クラスが有するデータ(属性)を示す属性区画およびクラスが有する処理(操作)を示す操作区画と呼ばれる。例えば、機器クラス311を示す矩形の名前区画は、かかるクラスのクラス名が「機器」であることを示し、属性区画は、かかるクラスが有する属性が、「運用状態」であることを示し、操作区画は、かかるクラスが有する操作が、「設定開始()」であることを示している。
このように、各クラスは、データ(属性)を保持するための属性区画と、かかる属性の書き込みおよび読み出しをおこなう処理(操作)を保持するための操作区画とを有している。これらのクラスは、プログラム(統合アプリケーション110)の一部として含まれるので、あらかじめROM12aに格納されたこのプログラムが実行されると、各クラスはRAM12bの所定領域に実体化され、属性区画に含まれる各データ(属性)がRAM12b上に展開される。したがって、クラスを実体化したオブジェクトは、RAM12b上の各データ(属性)の書き込みおよび読み出しをすることが可能となる。
なお、属性や操作といったクラスの要素の左側に「−」記号を付した場合は、かかる要素は外部のクラスには非公開であることを示し、「+」記号を付した場合は、かかる要素は外部のクラスに公開されていることを示す。また、操作については「設定開始()」のように「()」記号を付することが通例であり、「(引数1,引数2)」のように、かかる操作に引き渡す引数を記述する場合もある。
次に、本実施の形態の特徴部分であるアプリ管理部111bのクラスの概要について説明する。図6に示されるように、アプリ管理部111bは、機器状態管理部310、アプリ構成管理部320、及びアプリ状態管理部330に大別される。
機器状態管理部310は、複合機1全体に影響するような状態情報を管理し、機器クラス311及び省エネクラス312を含む。アプリ構成管理部320は、主にアプリケーションの構成を管理し、アプリクラス321、単一アプリクラス322及び複合アプリクラス323を含む。アプリ状態管理部330は、各アプリケーションの状態を管理し、設定情報クラス331、SP(Service Program)設定情報クラス332、UP(User Program)設定情報クラス333及び画面クラス334を含む。これら、各クラスについて以下に説明する。
機器クラス311は、一つのインスタンスが一台の機器(複合機1)に対応し、複合機1の利用制限に関する状態を管理するとともに、電力状態とアプリケーションの状態との調停を行うクラスである。機器クラス311は、属性として状態311aを有し、操作としてアプリ利用()312bを有する。
状態311aは、複合機1が機能を提供しているのか、又は複合機1に対する何らかの利用制限がかかっているのかといった複合機1に対する利用制限状態を保持する。
アプリ利用()312bは、アプリケーションの利用要求を受け付けるための操作であり、呼び出しに応じて、複合機1の全体的なレベルの粒度での利用可否を判定し、利用可能と判定した場合にアプリケーションの処理を実行させる。例えば、複合機1における電力状態等が利用可否の判定材料となる。
省エネクラス312は、現在の機器の電力状態を知っており、その電力状態の切替要求に対する切替可否判断と切替処理を行うクラスである。省エネクラス312は、属性として状態312aを有し、操作として解除()312bを有する。
状態312aは、複合機1の現在の電力状態を保持する。電力状態には例えば、通常待機状態や省電力状態といった複数の段階があり、各段階において電力の供給状態が異なる。通常待機状態とは、複合機1がサービス提供可能な状態で待機している状態のことをいう。省電力状態とは、電力消費を抑えるために所定箇所への電力供給を停止したり抑制したりしている状態のことをいう。例えば、この省電力状態では操作パネルを非表示にすることが行われる。なお、この省電力状態にさらに複数の段階を設けることとしてもよい。
解除()312bは、機器クラス311を実体化した機器オブジェクト311Aから呼び出され、省電力状態を解除して通常待機状態に戻す処理をおこなう。
アプリクラス321は、各アプリケーションの動作制限状態を管理すると共に、アプリケーションの利用要求がなされた際に当該アプリケーションの利用の可否判断等の処理を行うクラスである。アプリクラス321は、属性として状態321a及び種類321bを有し、操作として利用()321cを有する。
状態321aは、アプリケーションが提供できる動作に対する制限の有無を示す動作制限状態を保持する。状態321aの値が「無し」の場合は、アプリケーションが機能を縮退させることなく機能提供を行っている状態を示す。一方、状態321aの値が「有り」の場合は、アプリケーションが機能を縮退させて機能提供を行っている状態を示す。なお、動作制限状態は、設定情報の設定等の要因により変化する。
種類321bは、各アプリケーションの種類を識別するための情報を保持する。例えば、「コピーアプリ」、「送信アプリ」、「プリンタアプリ」又は「複合アプリ」等の値が保持される。
利用()321cは、アプリケーションが現在提供している機能を利用して、要求された機能を実行する。機能を実行するためには画面(操作パネル)と設定情報とを用いる必要があるため、機能の実行にあたり、画面クラス334及び設定情報クラス331とのメッセージのやりとりが発生する。
単一アプリクラス322は、アプリクラス321のサブクラスであり、単一機能のアプリケーション(以下「単一アプリ」という。)に対応する。
複合アプリクラス323は、アプリクラス321のサブクラスであり、複数の機能が複合されたアプリケーション(例えば、上述における統合アプリケーション110のようなアプリケーション、以下「複合アプリ」という。)に対応する。
設定情報クラス331は、アプリケーションの動作に必要とされる設定情報を表しており、現在の設定情報の利用状態を管理する。設定情報クラス331は、属性として状態331a及び参照数331bを有し、操作として参照()331cを有する。
状態331aは、設定情報が、現在参照されているのか、編集されているのか、といった設定情報の編集状態を保持する。
参照数331bは、現在設定情報を参照している利用者数を保持する。
参照()331cは、アプリケーションの設定情報を参照させるために必要な処理を行う。
SP設定情報クラス332は、設定情報クラス331のサブクラスであり、サービスパーソン用に特化した設定情報を管理する。
UP設定情報クラス333は、設定情報クラス331のサブクラスであり、一般利用者用に特化した設定情報を管理する。
画面クラス334は、アプリケーションが利用者とやり取りをするための操作パネルを独占的に利用するための権利(操作部利用権)の保持状態を管理し、操作部利用権の保持状態の切替要求に対する切替可否判断と切替処理とを行うクラスである。画面クラス334は、属性として状態334aを有し、操作として獲得()334bを有する。
状態334aは、操作部利用権を取得しているか否かの利用権状態を保持する。利用権状態が「有り」とは、操作部利用権を取得した状態を表しており、利用権状態が「無し」とは、操作部利用権を取得する必要がなく操作部利用権を取得していない状態を表している。すなわち、利用者が複合機1を操作して任意の機能を利用する場合、当該機能を提供するアプリケーションは、操作部利用権を取得する必要がある。本実施の形態における複合機1には、一つの操作パネルが実装されているため、同時に二つ以上のアプリケーションが操作部利用権を取得することはできない。
獲得()334bは、操作部利用権を取得していない場合に、操作部利用権を取得するための処理を行う。
次に、図6に示した各クラス間の関係について説明する。同図に示したように、UMLクラス図においては、クラス間に何らかの関係がある場合には、それらのクラスを表す矩形の間が直線で結ばれる。この直線の両端付近の数字はクラスの多重度を表す。多重度とは、直線で結ばれた他方のクラスのオブジェクトと関連付けられて生成されるオブジェクトの数のことである。
例えば、図中において機器クラス311と省エネクラス312との関係において、機器クラス311の多重度は「1」であり、省エネクラス312の多重度は「1」である。これは、機器クラス311のインスタンスである機器オブジェクト311Aと、省エネクラス312のインスタンスである省エネオブジェクト312Aとは1対1に関連付けられることを意味する。
まず、機器クラス311と省エネクラス312とのクラス関係について説明する。省エネクラス312は、複合機1の電力状態を管理するクラスであるので、複合機1内に1個だけ存在する。また、上述したように機器クラス311も複合機1内に1個だけ存在する。したがって、一つの機器オブジェクト311Aは、一つの省エネオブジェクト312Aを集約する。
次に、機器クラス311とアプリクラス321とのクラス関係について説明する。アプリクラス321は複合機1内の各アプリケーションと1対1に対応している。また、機器クラス311のインスタンス(機器オブジェクト311A)は複合機1内に1個だけ存在しており、アプリクラス321のインスタンス(アプリオブジェクト321A)の全てを管理している。従って、一つの機器オブジェクト311Aは、0個以上n個以下のアプリオブジェクト321Aを集約する。
ところで、アプリクラス321は、抽象クラスであるため、厳密にはアプリクラス321のインスタンスは生成されることはない。したがって、本実施の形態において、「アプリクラス321のインスタンス」、又は「アプリオブジェクト321A」というとき、アプリクラス321のサブクラス(単一アプリクラス322又は複合アプリクラス323)のインスタンスのことをいう。
次に、アプリクラス321と画面クラス334とのクラス関係について説明する。各アプリケーションが獲得できる操作部利用権は一つのみである。したがって、一つのアプリオブジェクト321Aは、一つの画面オブジェクト334Aを集約する。
次に、アプリクラス321と設定情報クラス331とのクラス関係について説明する。一つのアプリケーションは、0以上の設定情報を必要とする。したがって、1個のアプリオブジェクト321Aは、0個以上n個以下の設定情報オブジェクト331Aを集約する。
ところで、設定情報クラス331は、抽象クラスであるため、厳密には設定情報クラス331のインスタンスは生成されることはない。したがって、本実施の形態において、「設定情報クラス331のインスタンス」、又は「設定情報オブジェクト331A」というとき、設定情報クラス331のサブクラス(SP設定情報クラス332又はUP設定情報クラス333)のインスタンスのことをいう。
なお、単一アプリクラス322及び複合アプリクラス323は、アプリクラス321のサブクラスであるため、アプリクラス321の性質(属性、操作、関連等)を継承する。また、SP設定情報クラス332及びUP設定情報クラス333は、設定情報クラス331のサブクラスであるため、設定情報クラス331の性質を継承する。
ところで、複合アプリクラス323は、アプリクラス321を継承しているだけでなく、関連r1によってアプリクラス321を集約している。関連r1の多重度によれば、一つの複合アプリオブジェクト323Aは、2個以上n個以下のアプリオブジェクト321を集約する。この関連r1によって複合アプリの階層構造が表現されている。ここでいう、階層構造とは、アプリケーションをその機能面から分類した場合に構成される階層構造をいう。
図7は、複合機におけるアプリケーションの階層構造の例を説明するための図である。図7では、複合機1からみると統合アプリとプリンタアプリとの二つのアプリケーションが実装されていることが示されている。ここで、統合アプリは複合アプリであるため、二つ以上のアプリケーションを含む。図中では、コピーアプリと送信アプリとが統合アプリに含まれている。更に、送信アプリは複合アプリであるため、通常送信アプリとリモート送信アプリとを含む。
図7の階層構造を図6のクラス図に当てはめてみると、統合アプリは、複合アプリオブジェクト323Aとしてインスタンス化される。当該複合アプリオブジェクト323Aは、コピーアプリに対応する単一アプリオブジェクト322Aと、送信アプリに対応する複合アプリオブジェクト323Aとを集約する。更に、送信アプリに対応する複合アプリオブジェクト323Aは、通常送信アプリとリモート送信アプリとのそれぞれに対応する二つの単一アプリオブジェクト322を集約する。
このように、アプリ構成管理部320におけるクラス構成によって、複合機1におけるアプリケーションの階層構造をオブジェクトの関連によって適切に表現することができる。
次に、図6に示した各クラスの操作の実行手順について例をあげて説明する。図8は、アプリ管理部がアプリケーションの利用要求を受けた際の処理手順の一例を説明するためのUMLシーケンス図である。
ここで、UMLシーケンス図について説明しておく。図8の上部に並んだ矩形は、それぞれがクラスのインスタンス(オブジェクト)を示している。各オブジェクトから下方に伸びた線は、各オブジェクトが生存していることを示す線(ライフライン)であり、上方から下方に向かって時間が流れているものとみなされる。この線上に存在する細長い矩形は、当該のオブジェクトが実際に活動している期間(活性期間)を示す。そして、各ライフラインの間を結ぶ横向きの矢印は、オブジェクトに含まれる操作の実行を示す。具体的には、この矢印は、矢印の元のオブジェクトが、矢印の先のオブジェクトに含まれる操作を呼び出すことを示す。
機器オブジェクト311Aは、操作系サブシステム111の操作制御部111aよりアプリ利用()312bを呼び出されることにより、利用者のアプリケーションの利用要求を受け付ける(S101)。機器オブジェクト311Aは、アプリケーションの利用を開始するためには複合機1が利用制限中で無いことと、複合機1の電力状態を変えなければならないことを知っており、これらの条件を総合的にみて、複合機1全体のレベルの粒度としてアプリケーションの利用可否の判断を行う。
まず、機器オブジェクト311Aは状態311aを参照し、複合機1が現在利用制限中であるか否かを判断する。利用制限中でない場合、機器オブジェクト311Aは、省エネオブジェクト312Aの解除()312bを呼び出すことにより、省エネオブジェクト312Aに対して省電力状態の解除を要求する(S102)。
省エネオブジェクト312Aは、状態312aを参照し、省電力状態である場合は通常待機状態への復帰処理を行い、通常待機状態へ復帰できたか否かを機器オブジェクト311Aに返却する。なお、通常待機状態へ復帰できた場合、省エネオブジェクト312Aは、状態312aの値を通常待機状態に変更する。
複合機1が利用制限中でなく、電力状態も通常待機状態となった場合、機器オブジェクト311Aは、複合機1のレベルでアプリケーションは利用可能と判断し、利用が要求されたアプリケーションに対応するアプリオブジェクト321Aの利用()321cを呼び出す(S103)。
利用()321cを呼び出されたアプリオブジェクト321Aが複合アプリクラス323のインスタンスである場合、当該アプリオブジェクト321Aは、自らが集約しているアプリオブジェクト321Aの利用321cを呼び出す(S104)。したがって、利用()321cに実装された以下の処理が、アプリケーションの階層構造に応じて階層的に実行される。
利用()321c内において、アプリオブジェクト321Aは、アプリケーションレベルでの利用可否判断処理を実行する。
まず、アプリオブジェクト321Aは、は自らの状態321aを参照し、現在動作制限中であるか否かを判断する。動作制限中でない場合、アプリオブジェクト321Aは、自らが有している画面オブジェクト334Aの獲得()334bを呼び出し、操作部利用権の獲得を要求する(S105)。
画面オブジェクト334Aは、自らの状態334aを参照し、操作部利用権の有無を確認する。操作部利用権が無い場合、画面オブジェクト334Aは、操作部利用権を獲得するための処理を実行し、獲得の成否をアプリオブジェクト321Aに返却する。
続いて、アプリオブジェクト321Aは、設定情報オブジェクト331Aの参照()331cを呼び出すことにより、当該アプリケーションに対する設定情報の参照を要求する(S106)。設定情報オブジェクト331Aは、自らの状態331aを参照し、編集中でなければ、設定情報を参照させるための処理を行い、その成否をアプリオブジェクト321Aに返却する。
アプリオブジェクト321Aは、自らの状態321a、操作部利用権の獲得の成否、及び設定情報の参照の成否に基づいて、当該アプリケーションの利用の可否を判断し、その判断結果に応じて、アプリケーションを利用させるための処理を実行する。
上述したように、本実施の形態における複合機1においては、アプリケーションをその機能に基づいて階層的に分類し、かかる階層的な分類を適切に表現できるようなオブジェクト指向設計に基づくモデルによってアプリ管理部111bが実装されている。したがって、様々なアプリケーションの構成に柔軟に対応することができ、汎用的なアプリケーション管理の仕組みを効率よく実現することができる。
したがって、アプリケーションの機能の追加・削除に対するメンテナンスも容易に行うことができ、開発作業や保守作業等の工数削減を期待することもできる。
なお、本実施の形態の複合機1で実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでCD−ROM(Compact Disc Read Only Memory)、フレキシブルディスク(FD)、CD−R(CD Recordable)、DVD(Digital Versatile Disk)などのコンピュータで読み取り可能な記録媒体に記録して提供するよう構成してもよい。この場合、CPU11が上記記憶媒体から、当該プログラムを読み出してMEM−P12上にロードすることで、複合機に、上述した各ステップ、各手段または各部を実現させる。
また、当該プログラムを、インターネットなどのネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するよう構成してもよい。さらに、当該プログラムをインターネットなどのネットワーク経由で提供または配布するようにしてもよい。
以上、本発明の実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。