(57)【要約】【課題】操作管理処理を効率よく実現することができる操作管理プログラム、操作管理方法および画像形成装置を提供すること。【解決手段】操作管理の仕組みを操作者クラス３１０、受付クラス３２０、プランクラス３３０およびオプションクラス３４０からなるオブジェクトの協調により実現する。これにより、継承やカプセル化といったオブジェクト指向の利点を享受でき、機能追加や改修が容易になる。さらに、従来は受付クラス３２０が単独で担当していた処理の詳細な実現方法の判断をプランクラス３３０と共同でおこなうように構成したので、受付クラス３２０の処理を単純化でき、機能追加や改修がさらに容易になる。【選択図】        図８
2006042074.tif 000002
【特許請求の範囲】
【請求項１】
所定の処理の実行要求を受け付け、前記処理の実行を処理実行手順に依頼する操作管理プログラムであって、
前記要求元からの前記処理の実行要求を取得する要求取得手順と、
前記要求取得手順により取得された前記処理の実行要求を受け付け、該実行要求の種別を判定して対応手順を生成する要求受付手順と、
前記要求受付手順により前記対応手順として生成され、前記処理の実行要求を解析してこれを実施段階に分解し、前記実施段階を実行する実施手順を選別する要求解析手順と、
前記要求解析手順により前記実施手順として選別されるとともに前記実施段階のうち少なくとも一つを割当てられ、該実施段階の実行を前記処理実行手順に依頼する実施依頼手順と
をコンピュータに実行させることを特徴とする操作管理プログラム。
【請求項２】
前記要求受付手順は、実行要求ごとに要求解析手順を生成し、これらを関連付けて管理することを特徴とする請求項１に記載の操作管理プログラム。
【請求項３】
前記要求解析手順は、全ての実施依頼手順のうち自身の種別に関連する実施依頼手順のみを把握し、この自身が把握している実施依頼手順から前記実施手順を選別することを特徴とする請求項１または２に記載の操作管理プログラム。
【請求項４】
前記実施依頼手順は、前記処理実行手順の種類毎に個別に存在することを特徴とする請求項１、２または３に記載の操作管理プログラム。
【請求項５】
所定の処理の実行要求を受け付け、前記処理の実行を処理実行工程に依頼する操作管理方法であって、
前記要求元からの前記処理の実行要求を取得する要求取得工程と、
前記要求取得工程により取得された前記処理の実行要求を受け付け、該実行要求の種別を判定して対応工程を生成する要求受付工程と、
前記要求受付工程により前記対応工程として生成され、前記処理の実行要求を解析してこれを実施段階に分解し、前記実施段階を実行する実施工程を選別する要求解析工程と、
前記要求解析工程により前記実施工程として選別されるとともに前記実施段階のうち少なくとも一つを割当てられ、該実施段階の実行を前記処理実行工程に依頼する実施依頼工程と
を含んだことを特徴とする操作管理方法。
【請求項６】
所定の処理の実行要求を受け付け、前記処理の実行を処理実行手順に依頼する操作管理プログラムを制御ソフトウェアの一部として有する画像形成装置であって、
前記操作管理プログラムは、
前記要求元からの前記処理の実行要求を取得する要求取得手順と、
前記要求取得手順により取得された前記処理の実行要求を受け付け、該実行要求の種別を判定して対応手順を生成する要求受付手順と、
前記要求受付手順により前記対応手順として生成され、前記処理の実行要求を解析してこれを実施段階に分解し、前記実施段階を実行する実施手順を選別する要求解析手順と、
前記要求解析手順により前記実施手順として選別されるとともに前記実施段階のうち少なくとも一つを割当てられ、該実施段階の実行を前記処理実行手順に依頼する実施依頼手順と
をコンピュータに実行させることを特徴とする画像形成装置。
【請求項７】
前記要求受付手順は、実行要求ごとに要求解析手順を生成し、これらを関連付けて管理することを特徴とする請求項６に記載の画像形成装置。
【請求項８】
前記要求解析手順は、全ての実施依頼手順のうち自身の種別に関連する実施依頼手順のみを把握し、この自身が把握している実施依頼手順から前記実施手順を選別することを特徴とする請求項６または７に記載の画像形成装置。
【請求項９】
前記実施依頼手順は、前記処理実行手順の種類毎に個別に存在することを特徴とする請求項６、７または８に記載の画像形成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所定の処理の実行要求を受け付け、前記処理の実行を処理実行手順に依頼する操作管理プログラム、操作管理方法および画像形成装置に関し、特に操作管理処理を効率よく実現することができ、機能追加と改修を容易におこなうことができる操作管理プログラム、操作管理方法および画像形成装置に関するものである。
【背景技術】
【０００２】
従来、プリンタ、コピーおよびスキャナなどの複数の機能を一つの筐体内に収納した複合機が知られている。かかる複合機では、ＵＮＩＸ（Ｒ）などの汎用ＯＳ上に、プリンタアプリ、コピーアプリおよびスキャナアプリと呼ばれる複数のアプリケーションを搭載し、これらのアプリケーションの実行処理を切替えながら複数の機能を実現していた。
【０００３】
ところが、上記プリンタアプリ、コピーアプリおよびスキャナアプリは、共通して含まれるエンジン制御、メモリ制御およびシステム制御などの機能をそれぞれ別個に実現していたので、重複開発という無駄が生じていた。
【０００４】
このため、特許文献１では、複合機に搭載される複数のアプリケーションがそれぞれ担っていたエンジン制御、メモリ制御およびシステム制御などの処理を共通処理部分（プラットホーム）として各アプリケーションから括り出すことにより、アプリケーションの開発効率の向上を図っている。
【０００５】
【特許文献１】特開２００２−０８４３８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、この特許文献１で開示されている発明は、ハードウェアを制御する処理部分を共通化するものであり、各アプリケーションの内部処理全般を共通化するものではない。このため、複合機上のアプリケーションには、開発効率の向上を図るうえで改善の余地が残されている。
【０００７】
たとえば、オペレーションパネルの制御ソフトウェアを介して利用者からの処理要求を受け付け、この処理を制御ソフトウェアを介してハードウェアに実行させ、実行経過および実行結果を要求元にフィードバックするという操作管理処理は、複写機上の各アプリケーションに共通して存在する機能であるが、ハードウェアを直接制御する処理ではないため各アプリケーションで別個に実現されており、共通化することが可能である。
【０００８】
ところで、この操作管理処理は、複写機が多機能化するのに伴って複雑化しており、新たな機能を追加する場合や不具合の改修をおこなう場合には、既存の機能に障害が発生しないように注意して開発をおこなうことが必要とされ、多くの開発工数を割当てなければならなくなっている。このため、操作管理処理を各アプリケーションで共通化するにあたっては、機能追加や改修のための工数を低減することが強く求められている。
【０００９】
本発明は、上述した従来技術による問題点を解消するためになされたものであり、操作管理処理を効率よく実現することができ、機能追加と改修を容易におこなうことができる操作管理プログラム、操作管理方法および画像形成装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、所定の処理の実行要求を受け付け、前記処理の実行を処理実行手順に依頼する操作管理プログラムであって、前記要求元からの前記処理の実行要求を取得する要求取得手順と、前記要求取得手順により取得された前記処理の実行要求を受け付け、該実行要求の種別を判定して対応手順を生成する要求受付手順と、前記要求受付手順により前記対応手順として生成され、前記処理の実行要求を解析してこれを実施段階に分解し、前記実施段階を実行する実施手順を選別する要求解析手順と、前記要求解析手順により前記実施手順として選別されるとともに前記実施段階のうち少なくとも一つを割当てられ、該実施段階の実行を前記処理実行手順に依頼する実施依頼手順とをコンピュータに実行させることを特徴とする。
【００１１】
また、請求項２にかかる発明は、請求項１の発明において、前記要求受付手順は、実行要求ごとに要求解析手順を生成し、これらを関連付けて管理することを特徴とする。
【００１２】
また、請求項３にかかる発明は、請求項１または２の発明において、前記要求解析手順は、全ての実施依頼手順のうち自身の種別に関連する実施依頼手順のみを把握し、この自身が把握している実施依頼手順から前記実施手順を選別することを特徴とする。
【００１３】
また、請求項４にかかる発明は、請求項１、２または３の発明において、前記実施依頼手順は、前記処理実行手順の種類毎に個別に存在することを特徴とする。
【００１４】
また、請求項５にかかる発明は、前記処理の実行を処理実行工程に依頼する操作管理方法であって、前記要求元からの前記処理の実行要求を取得する要求取得工程と、前記要求取得工程により取得された前記処理の実行要求を受け付け、該実行要求の種別を判定して対応工程を生成する要求受付工程と、前記要求受付工程により前記対応工程として生成され、前記処理の実行要求を解析してこれを実施段階に分解し、前記実施段階を実行する実施工程を選別する要求解析工程と、前記要求解析工程により前記実施工程として選別されるとともに前記実施段階のうち少なくとも一つを割当てられ、該実施段階の実行を前記処理実行工程に依頼する実施依頼工程とを含んだことを特徴とする。
【００１５】
また、請求項６にかかる発明は、前記処理の実行を処理実行手順に依頼する操作管理プログラムを制御ソフトウェアの一部として有する画像形成装置であって、前記操作管理プログラムは、前記要求元からの前記処理の実行要求を取得する要求取得手順と、前記要求取得手順により取得された前記処理の実行要求を受け付け、該実行要求の種別を判定して対応手順を生成する要求受付手順と、前記要求受付手順により前記対応手順として生成され、前記処理の実行要求を解析してこれを実施段階に分解し、前記実施段階を実行する実施手順を選別する要求解析手順と、前記要求解析手順により前記実施段階として選別されるとともに前記実施段階のうち少なくとも一つを割当てられ、該実施手順の実行を前記処理実行手順に依頼する実施依頼手順とをコンピュータに実行させることを特徴とする。
【００１６】
また、請求項７にかかる発明は、請求項６の発明において、前記要求受付手順は、実行要求ごとに要求解析手順を生成し、これらを関連付けて管理することを特徴とする。
【００１７】
また、請求項８にかかる発明は、請求項６または７の発明において、前記要求解析手順は、全ての実施依頼手順のうち自身の種別に関連する実施依頼手順のみを把握し、この自身が把握している実施依頼手順から前記実施手順を選別することを特徴とする。
【００１８】
また、請求項９にかかる発明は、請求項６、７または８の発明において、前記実施依頼手順は、前記処理実行手順の種類毎に個別に存在することを特徴とする。
【発明の効果】
【００１９】
請求項１にかかる発明によれば、要求の種別に応じて要求受付手順が要求解析手順をひとつ選択し、さらに要求解析手順が要求の詳細を検討して必要な実施依頼手順を選択するように構成したので、要求の解析のための処理が要求受付手順と要求解析手順とに分散されて単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。
【００２０】
また、請求項２にかかる発明によれば、一つの実行要求に対して一つの要求解析手順が生成されるように構成したので、実行要求が複数受け付けられている場合であっても、要求解析手順は、対応する実行要求の解析のみをおこなえばよく、複数の実行要求に対応するための処理が不要になる分だけ処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。
【００２１】
また、請求項３にかかる発明によれば、多数存在する実施依頼手順のうち、要求解析手順は、自身の種別に関連する実施依頼手順のみを把握し、この中から要求を実施するために必要なものを選択するように構成したので、要求解析手順の処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。
【００２２】
また、請求項４にかかる発明によれば、処理実行手順の種類毎に実施依頼手順を作成するように構成したので、新たな処理実行手順に対応することが必要になった場合に実施依頼手順を新規に作成することで、既存の実施依頼手順に影響を与えることなく対応することができ、機能追加に容易に対応することができるという効果を奏する。
【００２３】
また、請求項５にかかる発明によれば、要求の種別に応じて要求受付工程が要求解析工程をひとつ選択し、さらに要求解析工程が要求の詳細を検討して必要な実施依頼工程を選択するように構成したので、要求の解析のための処理が要求受付工程と要求解析工程とに分散されて単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。
【００２４】
また、請求項６にかかる発明によれば、要求の種別に応じて要求受付手順が要求解析手順をひとつ選択し、さらに要求解析手順が要求の詳細を検討して必要な実施依頼手順を選択するように構成したので、要求の解析のための処理が要求受付手順と要求解析手順とに分散されて単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。
【００２５】
また、請求項７にかかる発明によれば、一つの実行要求に対して一つの要求解析手順が生成されるように構成したので、実行要求が複数受け付けられている場合であっても、要求解析手順は、対応する実行要求の解析のみをおこなえばよく、複数の実行要求に対応するための処理が不要になる分だけ処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。
【００２６】
また、請求項８にかかる発明によれば、多数存在する実施依頼手順のうち、要求解析手順は、自身の種別に関連する実施依頼手順のみを把握し、この中から要求を実施するために必要なものを選択するように構成したので、要求解析手順の処理が単純化され、処理内容が理解され易くなり、もって機能追加と改修に容易に対応することができるという効果を奏する。
【００２７】
また、請求項９にかかる発明によれば、処理実行手順の種類毎に実施依頼手順を作成するように構成したので、新たな処理実行手順に対応することが必要になった場合に実施依頼手順を新規に作成することで、既存の実施依頼手順に影響を与えることなく対応することができ、機能追加に容易に対応することができるという効果を奏する。
【発明を実施するための最良の形態】
【００２８】
以下に添付図面を参照して、この発明にかかる操作管理プログラム、操作管理方法および画像形成装置の最良な実施の形態を詳細に説明する。ここでは、まず、画像形成装置の概要について説明し、その後に、この発明にかかる操作管理プログラム、操作管理方法および画像形成装置の構成および処理手順について説明することとする。なお、本実施の形態では、この発明を画像形成装置に適用した場合について説明するが、本発明はこれに限らず、利用者の要求を受け付け、その要求の実行を処理実行部に依頼する各種プログラムおよび装置に適用することができる。
【００２９】
（画像形成装置の概要）
まず、画像形成装置の概要について説明する。近年、画像形成装置は、デジタル化にともなって機能の複合化が進んでいる。たとえば、帯電したドラムに電子制御されたレーザー光等を照射することで部分的に電荷を消失させて像を作り、電荷の残った部分にトナーを付着させてこれを紙に転写する印刷機能は、コピー機とプリンタとＦＡＸ機に共通して用いることができる。また、原稿をＣＣＤ（Charge Coupled Devices）によって読み取って電子情報化する機能はＦＡＸ機とスキャナに共通して用いることができる。
【００３０】
このような共通する機能を１台の筐体にまとめて統合したいわゆる複合機は、従来のコピー機、プリンタ、ＦＡＸ機およびスキャナがもっていた役割を１台で果たすことができ、オフィスのスペース効率の向上と機器導入コストの低減に貢献している。
【００３１】
また、近年の画像形成装置は、かかる複合化に加えてネットワーク化も進んでいる。図１は、画像形成装置が接続されたネットワーク環境の一例を示す説明図である。同図に示すように、近年のオフィスは、クライアントＰＣや各種サーバがＬＡＮ（Local Area Network）などのネットワークに接続された形態をとることが多い。
【００３２】
このようなネットワーク環境に接続された画像形成装置は、クライアントＰＣから要求により文書を印刷するいわゆるネットワークプリンタとしての機能以外に、クライアントＰＣから要求により文書をＦＡＸ送信するネットワークＦＡＸ機能や、スキャナ機能により読み取った文書を画像形成装置内のハードディスク装置に蓄積し、クライアントＰＣからネットワーク経由で取得させる文書蓄積機能等を備えるようになっている。
【００３３】
こうして複合化とネットワーク化の進展により必要となった多くの機能を実現するため、画像形成装置に搭載されるソフトウェアは、規模が大きく、複雑なものとなっている。そして、それにともなって、それらのソフトウェアの開発と維持管理のための工数も大幅に増大している。
【００３４】
図２は、画像形成装置に搭載されるソフトウェアの構成の変遷を示す説明図である。サービス層分離前アプリケーション４０１に示すように、複合化した画像形成装置に搭載されるソフトウェアは、コピーアプリケーション、ＦＡＸアプリケーション、スキャナアプリケーションなどの機能別に独立したアプリケーションとして作成されていた。
【００３５】
しかしながら、これらのアプリケーションは、ハードウェアリソースを制御するドライバー（サービス層相当部分）をそれぞれ独自に含んでいたため、メンテナンスに工数を要するものとなっていた。たとえば、コピーアプリケーションとＦＡＸアプリケーションは、どちらも出力結果を得るためにプロッタ装置を制御する必要があるが、この制御処理はコピーアプリケーションとＦＡＸアプリケーションにそれぞれ別個に実装されていた。このため、プロッタ装置に関する新しい制御方法を追加する場合には、コピーアプリケーションとＦＡＸアプリケーションの両方に手を加えなければならず、メンテナンスのための開発工数が重複して発生していた。
【００３６】
そこで、サービス層分離後アプリケーション４０２に示すように、サービス層分離前アプリケーション４０１のサービス層相当部分を括りだしてサービス層とし、その上層に位置するアプリケーション層の各アプリケーションがこのサービス層の機能を呼び出してハードウェアを制御する構成とした。かかる構成をとることにより、各アプリケーションに重複していた機能がサービス層に集約され、ソフトウェアのメンテナンスに要する労力が軽減された。
【００３７】
しかしながら、画像形成装置の多機能化、ネットワーク化がさらに進展するに従って各アプリケーションの複雑化と大規模化が大きく進み、開発とメンテナンスに要する工数が再び増大してきた。こうした中で、各アプリケーションに共通処理部分が存在することが問題となってきた。
【００３８】
具体的には、コピーアプリケーションやスキャナアプリケーションなどのアプリケーション層のアプリケーションは、サービス層の機能を呼び出すための処理や、ジョブ管理処理などの同様な内部処理を共通して有していた。このように、共通した処理を各アプリケーションが有していると、メンテナンスのための工数が重複して発生する。さらに、各アプリケーションが大規模で複雑になり、全体の仕様を理解するのが困難になることから、機能追加や不具合修正をおこなう際に不具合を発生させ易くなる。
【００３９】
この問題を解決するため、共通ルーチン分離アプリケーション４０３に示すように、共通処理部分を共通ルーチンとして括りだすこともできる。しかしながら、かかる共通ルーチンは、各アプリケーションにおいて微妙に異なる処理を共通化する必要があるため、共通ルーチン内部の処理が複雑化してしまい、開発者にとって把握が困難なものになる可能性が高い。また、たとえば、プリンタアプリケーションなどの新規アプリケーションを追加する必要が生じた場合には、共通ルーチンの改修が必要となり、その影響で共通ルーチンを使用する既存のアプリケーションに不具合が発生する可能性もある。
【００４０】
そこで、オブジェクト指向アプリケーション４０４に示すように、オブジェクト指向による設計手法を用いて、機能ごとに存在していた複数のアプリケーションを一つのアプリケーションに統合することを解決策とした。すなわち、各アプリケーションの共通処理部分をオブジェクトとして抽出し、この共通して利用されるオブジェクトとこれらのオブジェクトを利用してコピー機能やスキャナ機能といった個別の機能を実現するオブジェクトの集合体として統合アプリケーションを構築することとした。
【００４１】
ここで、オブジェクト指向とは、データとそれを操作する手続きをオブジェクトという単位で一体化し、ソフトウェアをこのオブジェクトの集合として設計／プログラミングする手法のことを指す。オブジェクト指向では、自立したオブジェクトがそれぞれ協調して処理を実現する形態がとられるが、協調に関係のないデータや手続き、すなわちオブジェクト内部でのみ使用されるデータや手続きは、カプセル化と呼ばれる仕組みによってオブジェクト内部に隠蔽される。このため、個々のオブジェクトの仕様が明確化され、設計者や開発者に理解され易いという利点を有する。また、継承と呼ばれる汎化／特化の仕組みを備え、既存のオブジェクトを再利用して新たなオブジェクトを作成することが容易であるという利点も有する。
【００４２】
このオブジェクト指向の考え方をとりいれると、たとえばプリンタ機能を追加するというような新規機能の追加の必要が生じた場合も、継承の仕組みによって既存の類似のオブジェクトとの差分のみを設計・実装することが可能になる。また、オブジェクト間のインターフェースも明確化されるため、改修要員が仕様を把握することも容易となる。このように、オブジェクト指向の考え方をとりいれることにより、開発工数を削減でき、仕様の理解不足による改修ミスを回避することができる。
【００４３】
図１１は、図２のサービス層分離後アプリケーション４０２の段階の画像形成装置のハードウェアおよびソフトウェアの構成を説明するための説明図である。同図に示すように、ハードウェア２００は、各種機器からなるハードウェアリソース２０１を有する。このハードウェアリソース２０１に含まれる機器には、スキャナ２０１ａ、プロッタ２０１ｂ、ＨＤＤ（Hard Disk Drive）２０１ｃ、ネットワークインターフェース２０１ｄなどがある。また、その他のリソース２０１ｅとして、たとえば、オペレーションパネルのような入出力デバイス等も有する。
【００４４】
このハードウェア２００を制御するソフトウェア１００は、３階層に階層化されている。最下層には、オペレーティングシステム１０３が存在する。その上層にはサービス層１０２が設けられ、最上層にはアプリケーション層１０１が設けられる。
【００４５】
オペレーティングシステム１０３は、サービス層１０２とアプリケーション層１０３とが動作するための基盤を提供する。そして、サービス層１０２は、各ハードウェアリソース（２０１ａ〜２０１ｅ）を制御するドライバーに相当し、スキャナ制御プログラム１０２ａ、プロッタ制御プログラム１０２ｂ、蓄積制御プログラム１０２ｃ、配信／メール送受信制御プログラム１０２ｄ、ＦＡＸ送受信制御プログラム１０２ｅ、ネットワーク通信制御プログラム１０２ｆおよびその他の制御プログラム１０２ｇを有する。
【００４６】
アプリケーション層１０３は、このサービス層１０２を利用してコピー機能やＦＡＸ機能等を実現する。アプリケーション層１０１には、コピーアプリケーション１２０、スキャナアプリケーション１３０、ファックスアプリケーション１４０およびプリンタアプリケーション１５０が個別に存在している。
【００４７】
たとえば、コピーアプリケーション１２０は、コピー機能を実現するために、スキャナ制御プログラム１０２ａ、プロッタ制御プログラム１０２ｂ、蓄積制御プログラム１０２ｃおよびその他の制御プログラム１０２ｇとデータの送受信をおこなう。また、ファックスアプリケーション１４０は、ファックス機能を実現するために、プロッタ制御プログラム１０２ｂ、蓄積制御プログラム１０２ｃ、ＦＡＸ送受信制御プログラム１０２ｅ、ネットワーク通信制御プログラム１０２ｆおよびその他の制御プログラム１０２ｇとデータの送受信をおこなう。このように、アプリケーション層１０１とサービス層１０２の通信は、複雑なものとなっており、それを実現するためのソフトウェアも理解が困難なものとなっていた。
【００４８】
図３は、図２のオブジェクト指向アプリケーション４０４の段階の画像形成装置のハードウェアおよびソフトウェアの構成を説明するための説明図である。同図に示すように、アプリケーション層１０１に存在した複数のアプリケーションは、統合アプリケーション１１０に統合されている。そして、各アプリケーションがそれぞれおこなっていたサービス層１０２との通信処理を、統合アプリケーション１１０を構成する所定のオブジェクトがおこなうようになっているので、アプリケーション層１０１とサービス層１０２の間の通信は、図１１と比較して単純になっており、システムが単純化され仕様の理解が容易になっているのが見て取れる。
【００４９】
このようにオブジェクト指向に基づいてアプリケーションを統合することにより、重複していた機能を集約することができ、また、システムの仕様の理解しやすくなり、機能追加や改修に容易に対応できるようになる。
【００５０】
（第１の実施の形態）
まず、本実施の形態に係る画像形成装置のハードウェア構成について説明する。図４は、本実施の形態に係る画像形成装置のハードウェア構成を示すブロック図である。同図に示すように、画像形成装置１は、コントローラ１０と、ＦＡＸ制御装置（ＦＣＵ（Fax Control Unit））３０と、ＵＳＢ（Universal Serial Bus）インターフェース４０と、ＩＥＥＥ１３９４（the Institute of Electrical and Electronics Engineers 1394）インターフェース５０と、エンジン部（Engine）６０とをＰＣＩ（Peripheral Component Interconnect）バス７０で接続した構成となる。
【００５１】
コントローラ１０は、画像形成装置１の全体制御をおこなう制御装置であり、ＣＰＵ１１と、システムメモリ（ＭＥＭ−Ｐ）１２と、ノースブリッジ（ＮＢ）１３と、サウスブリッジ（ＳＢ）１４と、ＡＳＩＣ（Application Specific Integrated Circuit）１６と、ローカルメモリ（ＭＥＭ−Ｃ）１７と、ハードディスクドライブ（ＨＤＤ（Hard Disk Drive））１８とを有し、ノースブリッジ（ＮＢ）１３とＡＳＩＣ１６との間をＡＧＰ（Accelerated Graphics Port）１５で接続した構成となる。
【００５２】
ＣＰＵ１１は、各種ソフトウェアを実行するための演算装置である。本実施の形態に係る操作管理プログラムを含む、画像形成装置１のコピー機能やＦＡＸ機能を実現するためのソフトウェア群は、ＭＥＭ−Ｃ１７もしくはＨＤＤ１８に記憶保持され、必要に応じてＭＥＭ−Ｐ１２にロードされてこのＣＰＵ１１により実行される。
【００５３】
ＭＥＭ−Ｐ１２は、プログラムやデータの格納用メモリ、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いるシステムメモリであり、ＲＯＭ（Read Only Memory）１２ａとＲＡＭ(Random Access Memory)１２ｂとからなる。ＲＯＭ１２ａは、プログラムやデータの格納用メモリとして用いる読み出し専用のメモリであり、ＲＡＭ１２ｂは、プログラムやデータの展開用メモリ、プリンタの描画用メモリなどとして用いる書き込みおよび読み出し可能なメモリである。
【００５４】
ＮＢ１３およびＳＢ１４は、ＭＥＭ−Ｐ１２やＡＧＰ１５を制御する制御装置であり、ＮＢ１３を介してＣＰＵ１１とＭＥＭ−Ｐ１２とＳＢ１４とＡＧＰ１５とが接続される形をとる。ＮＢ１３は、ＡＧＰ１５を介してＡＳＩＣ１６とも接続され、その先にＰＣＩバス７０が接続される。
【００５５】
ＡＳＩＣ１６は、画像処理のための制御装置である。このＡＳＩＣ１６は、ＭＥＭ−Ｃ１７やＨＤＤ１８やオペレーションパネル２０のような周辺機器と接続され、これらの制御もおこなう。ＭＥＭ−Ｃ１７は、ＡＳＩＣ１６が画像処理をおこなう画像データ等を一時記憶する記憶部であり、ＨＤＤ１８は、各種ソフトウェア、フォントデータ、蓄積するよう指示された画像データ等を記憶する記憶部である。オペレーションパネル２０は、利用者の操作を受け付ける入力装置である。
【００５６】
ＰＣＩバス７０に接続されるＦＡＸ制御装置（ＦＣＵ）３０は、ＦＡＸ送受信を制御する制御装置である。ＵＳＢインターフェース４０およびＩＥＥＥ１３９４インターフェース５０は、外部機器を接続するためのインターフェースである。エンジン部（Engine）６０は、印刷処理をおこなう装置であり、たとえば白黒プロッタ、１ドラムカラープロッタ、４ドラムカラープロッタ、スキャナまたはファックスユニットなどからなる。ＰＣＩバス７０には、これら以外にネットワーク接続のためのインターフェース装置等も接続される。
【００５７】
次に、統合アプリケーション１１０の内部構成について説明する。図５は、統合アプリケーション１１０の内部構成を示すブロック図である。同図に示すように、統合アプリケーション１１０は、操作系サブシステム１１１と、管理系サブシステム１１２と、実行系サブシステム１１３とを有する。
【００５８】
操作系サブシステム１１１は、マンマシンインタフェースを担当するソフトウェア群である。具体的には、この操作系サブシステム１１１は、ユーザの要求を受け付ける処理と、この要求の実行を指示する処理と、この要求の実行状況と実行結果についての情報をユーザに提供する処理をおこなう。
【００５９】
管理系サブシステム１１２は、画像形成装置１の資源を管理するソフトウェア群である。具体的には、この管理系サブシステム１１２は、ハードウェアリソース２０１およびこのハードウェアリソース２０１が保持するデータ状態を管理するサービスをおこなう。
【００６０】
実行系サブシステム１１３は、ユーザからの要求の実行を担当するソフトウェア群である。具体的には、この実行系サブシステム１１３は、コピー要求がなされた場合には、原稿の読み取りから成果物の出力までの処理をおこなう。
【００６１】
操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３は、必要に応じて相互に処理を依頼してその結果を送り合う。このようにそれぞれのサブシステムが協調し合って、統合アプリケーション１１０全体として画像形成装置１に必要とされるサービスの提供をおこなう。
【００６２】
そして、操作系サブシステム１１１は、操作管理部１１１ａと操作制御部１１１ｂを有する。操作管理部１１１ａは、ユーザの要求を受け付ける処理と、この要求の実行状況と実行結果についての情報をユーザに提供する処理をおこなう。操作制御部１１１ｂは、ユーザの要求の実行を実行系サブシステム１１３または管理系サブシステム１１２に指示する処理をおこなう。
【００６３】
次に、統合アプリケーション１１０のオブジェクトモデルについて説明する。図６は、統合アプリケーション１１０のＵＭＬクラス図である。ＵＭＬ（Unified Modeling Language）とは、ＯＭＧ（Object Management Group）が仕様を策定しているシステムモデリング言語であり、モデリングの成果を記述する記法を定義したものである。このＵＭＬは、オブジェクト指向によるソフトウェアの設計において広く用いられている。
【００６４】
同図に示すように、統合アプリケーション１１０は複数のパッケージを有し、また、統合アプリケーション１１０自体もひとつのパッケージとなっている。ここで、パッケージとは、オブジェクトモデルの構成要素（シンボル）をグループ化したものであり、ＵＭＬにおいては、左上にタブのついたフォルダの形をしたシンボルで表現される。また、各パッケージを相互に結ぶ直線は、各パッケージ間に処理依頼などの関連があることを示している。
【００６５】
図５に示すように、統合アプリケーション１１０は、操作系サブシステム１１１、管理系サブシステム１１２および実行系サブシステム１１３という３つのパッケージを有する。さらに、操作系サブシステム１１１は、操作管理部１１１ａと操作制御部１１１ｂという２つのパッケージを有する。また、操作系サブシステム１１１と管理系サブシステム１１２、操作系サブシステム１１１と実行系サブシステム１１３、および管理系サブシステム１１２と実行系サブシステム１１３の間には処理依頼などの関連があり、さらに、操作管理部１１１ａと操作制御部１１１ｂの間にも処理依頼などの関連がある。
【００６６】
次に、操作管理部１１１ａのクラス構成について説明する。なお、操作管理部１１１ａをオブジェクト指向に基づいて設計するにあたって、既存の処理を単純にオブジェクト化せず、機能追加や改修をより一層容易におこなうことができる構成をとっている。ここで、この構成について説明しておく。
【００６７】
図７−１は、既存の処理を単純にオブジェクト化した場合のオブジェクトモデルを説明するための説明図である。同図に示すように、このモデルでは、ユーザからの要求をユーザインターフェース制御部を経由して受け取る「操作者」と、「操作者」が受け取った要求を受け付けてそれを実現するために必要な処理を洗い出し、個々の処理の実行を指示する「受付」と、「受付」から指示された個別の処理の実行を操作制御部１１１ｂに依頼する「オプション」とが存在する。
【００６８】
「オプション」は、原稿の読み取り処理、印刷処理などの個別の処理ごとに専用のものが存在する。このため、たとえば、原稿を読み取ってこれを印刷し、さらに印刷結果にパンチ穴を開けるようにという要求が「操作者」からあった場合には、「受付」は、この要求を分析して、原稿の読み取り処理をおこなう「オプション」と印刷処理をおこなう「オプション」とパンチ処理をおこなう「オプション」とを選別し、これらに個別に指示を出すことになる。
【００６９】
このように「オプション」を個別の処理ごとに専用のものとして用意しておくことにより、例えば、文書のメール送信のような新しい処理が必要になった場合にもそれに対応した「オプション」を新規に作成することにより、他の「オプション」に影響をあたえることなくその処理を追加することができる。
【００７０】
しかし、ＦＡＸ送信中に文書のコピーを要求された場合のように「操作者」が複数同時に存在する場合がある上に、「操作者」からの要求は画像形成装置１の多機能化によって多様化しているため、このモデルでは、要求を実現するために必要な「オプション」を選別する「受付」の処理内容は、大変複雑なものになり、機能追加と改修が困難なる恐れがある。
【００７１】
図７−２は、「受付」の処理を分割した場合のオブジェクトモデルを説明するための説明図である。同図に示すように、「受付」と「オプション」の間に「プラン」を置き、「操作者」からの要求を実現するために必要な「オプション」を選別する処理をこの「プラン」におこなわせることで上記の問題を解決することができる。
【００７２】
たとえば、文書のコピーやＦＡＸ送信を行うための「文書の操作プラン」やＦＡＸの送信先を登録する「電話帳の操作プラン」のような「プラン」を事前に用意しておき、「受付」は、これらの中から要求にあった「プラン」を選択するのみとし、「プラン」が要求の詳細を解析して必要な「オプション」を選択する。各「プラン」は、処理目的毎に存在するため、それぞれは自分に関係のない「オプション」については知る必要がないので選択の幅は狭いものとなる。
【００７３】
また、「受付」が「操作者」ごとにひとつの「プラン」を割当てるようにすることで、「プラン」は、複数の「操作者」への対応を考慮する必要が無くなり、処理を軽減することができる。
【００７４】
このように「オプション」の選択を「受付」と「プラン」の２段階でおこない、「操作者」ごとに「プラン」を割当てることにより、「受付」と「プラン」の処理を単純化することができ、単純にオブジェクト指向を適用した場合よりもさらに機能追加と改修への対応が容易になる。
【００７５】
図８は、操作管理部１１１ａのクラス構成を示すＵＭＬクラス図である。ここで、クラスとＵＭＬクラス図におけるクラスの記述方法について説明しておく。クラスとは、オブジェクトの設計図に相当する概念であり、オブジェクト内部に有する属性と操作や、他のオブジェクトとの関係を定義するものである。
【００７６】
クラスは、ＵＭＬクラス図においては、３段の区画を有する矩形として記述される。それぞれの区画は、上から、名前区画、属性区画および操作区画と呼ばれる。名前区画には、当該のクラスの名称が記述され、属性区画には、当該のクラスが有するデータ（属性）が記述され、操作区画には、当該のクラスが有する手続き（操作）が記述される。
【００７７】
このように、クラスは、データ（属性）を所持するための属性区画と、かかる属性の書き込みおよび読み出しをおこなう手続き（操作）を所持するための操作区画とを有している。これらのクラスは、プログラム（統合アプリケーション１１０）の一部として含まれるので、あらかじめＲＯＭ１２ａに格納されたこのプログラムが実行されると、各クラスはＲＡＭ１２ｂの所定領域に実体化され、属性区画に含まれる各データ（属性）がＲＡＭ１２ｂ上に展開される。したがって、クラスを実体化したオブジェクトは、ＲＡＭ１２ｂ上の各データ（属性）の書き込みおよび読み出しをすることが可能となる。
【００７８】
なお、クラス図において、属性や操作の左側に「−」記号を付した場合は、当該の属性や操作が外部のクラスに非公開であることを示し、「＋」記号を付した場合は、当該の属性や操作が外部のクラスに公開されていることを示す。また、操作については「リクエスト投入（）」のように「（）」記号を付することが通例であり、「（引数１，引数２）」のように、かかる操作に引き渡す引数を記述する場合もある。
【００７９】
図８に示すように、操作管理部１１１ａは、操作者クラス３１０と、受付クラス３２０と、プランクラス３３０と、オプションクラス３４０とを有する。なお、操作者クラス３１０、受付クラス３２０、プランクラス３３０およびオプションクラス３４０は、特許請求の範囲における要求取得手順、要求受付手順、要求解析手順および実施依頼手順にそれぞれ相当する。
【００８０】
操作者クラス３１０は、ユーザインターフェース制御部からユーザの要求を受け取り、また、ユーザインターフェース制御部に対して要求の実行経過と実行結果を報告するクラスである。操作者クラス３１０は、操作として、要求する（）３１０ａと経過報告（）３１０ｂとを有する。
【００８１】
要求する（）３１０ａは、ユーザインターフェース制御部からの要求を受け付け、受付クラス３２０のオブジェクトに対し要求への対応を依頼する処理である。また、経過報告（）３１０ｂは、要求の経過報告をユーザインターフェース制御部へ通知する処理である。
【００８２】
受付クラス３２０は、操作者クラス３１０のオブジェクトの依頼を受け付けてどのようなプランが必要なのかを判断し、依頼元が新規の場合はプランクラス３３０のオブジェクトを作成するクラスである。受付クラス３２０は、属性として、最大受付数３２０ａを有し、操作として、要求する（）３２０ｂ、経過報告（）３２０ｃ、受付処理（）３２０ｄおよび報告先判断（）３２０ｅを有する。これらの属性と操作のうち、受付処理（）３２０ｄと報告先判断（）３２０ｅは、クラスの外部に公開されない。
【００８３】
最大受付数３２０ａは、受け付けることのできる要求の最大数を表し、既にこの数の要求を受け付けている状態で新たな依頼がなされた場合は拒絶される。なお、最大受付数３２０ａは、受付クラス３２０を実体化したオブジェクトが生成される際にＲＡＭ１２ｂ上に展開され、書き込みおよび読み出しをすることが可能となる。
【００８４】
要求する（）３２０ｂは、操作者クラス３１０のオブジェクトからの依頼を受け付け、受け付け可能ならばプランクラス３３０のオブジェクトに対し変更を依頼する処理である。経過報告（）３２０ｃは、プランクラス３３０のオブジェクトから経過報告を受け、操作者クラス３１０のオブジェクトに報告する処理である。
【００８５】
受付処理（）３２０ｄは、操作者クラス３１０のオブジェクトからの要求を受付可能であるか否かを判断し、受け付け可能な場合には、要求元の操作者クラス３１０のオブジェクトが新規かどうかをさらに判断し、新規であった場合には、プランクラス３３０のオブジェクトを生成する処理である。報告先判断（）３２０ｅは、プランクラス３３０のオブジェクトからの経過報告をどの操作者クラス３１０のオブジェクトに報告するのかを判断する処理である。
【００８６】
プランクラス３３０は、受付クラス３２０のオブジェクトの依頼を受けて、依頼された要求を実現するために必要なオプションクラス３４０のオブジェクトを選別し、選別したオブジェクトに作業を依頼するクラスである。プランクラス３３０は、操作として、変更する（）３３０ａ、経過報告（）３３０ｂおよび依頼先判断（）３３０ｃを有する。これらの操作のうち、依頼先判断（）３３０ｃは、クラスの外部に公開されない。
【００８７】
変更する（）３３０ａは、受付クラス３２０のオブジェクトからの変更依頼を受け、オプションクラス３４０のオブジェクトに作業を依頼する処理である。経過報告（）３３０ｂは、オプションクラス３４０のオブジェクトから経過報告を受け、受付クラス３２０のオブジェクトに報告する処理である。依頼先判断（）３３０ｃは、受付クラス３２０からの要求を実現するために必要なオプションクラス３４０のオブジェクトを選定して作業の依頼先を決定する処理である。
【００８８】
オプションクラス３４０は、プランクラス３３０のオブジェクトから依頼された作業を実現するために操作制御部１１１ｂに作業を依頼するクラスである。オプションクラス３４０は、操作として、変更する（）３４０ａと経過報告（）３４０ｂを有する。
【００８９】
変更する（）３４０ａは、プランクラス３３０のオブジェクトからの変更依頼を受け、操作制御部１１１ｂに作業を依頼する処理である。経過報告（）３４０ｂは、操作制御部１１１ｂから経過報告を受け、プランクラス３３０のオブジェクトに報告する処理である。
【００９０】
次に、図８に示した各クラスの関係について説明する。同図に示すように、ＵＭＬクラス図においては、クラス間に何らかの関係がある場合には、それらのクラスを表す矩形の間が直線で結ばれる。この直線の両端付近の文字はクラスのロールを表し、数字はクラスの多重度を表す。ここで、ロールとは、直線で結ばれた他方のクラスに対する当該のクラスの役割のことであり、多重度とは、直線で結ばれた他方のクラスのオブジェクトと関連付けられて生成されるオブジェクトの数のことである。
【００９１】
まず、操作者クラス３１０と受付クラス３２０の関係について説明する。受付クラス３２０のオブジェクトは、操作管理部１１１ａにひとつだけ存在する。この受付クラス３２０のオブジェクトは、０以上存在する新規の操作者クラス３１０のオブジェクトからの依頼を受け付け、プランクラス３３０のオブジェクトの作成をおこなう。このように、操作者クラス３１０と受付クラス３２０は、「受付待ちの顧客」と「依頼先」という関係をなしている。
【００９２】
また、受付クラス３２０のオブジェクトは、０以上存在する既存の操作者クラス３１０のオブジェクトからの依頼も受け付ける。このように、操作者クラス３１０と受付クラス３２０は、「登録済みの顧客」と「依頼先」という関係もなしている。
【００９３】
次に、受付クラス３２０とプランクラス３３０の関係について説明する。プランクラス３３０のオブジェクトは、操作管理部１１１ａにひとつだけ存在する受付クラス３２０のオブジェクトによって、既存の操作者クラス３１０のオブジェクトごとに作成される。したがって、受付クラス３２０とプランクラス３３０は、「作成者」と「作成対象」という関係をなし、プランクラス３３０のオブジェクトは、０以上存在することになる。
【００９４】
次に、プランクラス３３０とオプションクラス３４０の関係について説明する。プランクラス３３０のオブジェクトは、少なくとも一つのオプションクラス３４０のオブジェクトから構成される。一方、オプションクラス３４０のオブジェクトは、プランクラス３３０のオブジェクトが生成される前から存在し、対応付けられて作成された０以上のプランクラス３３０のオブジェクトから実行要求を受け付ける。このように、プランクラス３３０とオプションクラス３４０は、「要求元」と「構成要素」という関係をなしている。
【００９５】
次に、受付クラス３２０とオプションクラス３４０の関係について説明する。操作管理部１１１ａにひとつだけ存在する受付クラス３２０のオブジェクトは、利用者に提供できる機能を表すオプションクラス３４０のオブジェクトを少なくとも一つ持ちネタとして所有する。このように、受付クラス３２０とオプションクラス３４０は、「所有者」と「持ちネタ」という関係をなしている。
【００９６】
このように、操作者クラス３１０、受付クラス３２０、プランクラス３３０およびオプションクラス３４０の各オブジェクトは、相互に関連し合い、協調して、操作管理部１１１ａに必要な機能を実現している。
【００９７】
次に、図８に示した各クラスの操作の実行手順について例を挙げて説明する。図９は、ユーザインターフェースの制御部から処理要求があった場合の操作の実行手順を示すＵＭＬシーケンス図である。
【００９８】
ここで、ＵＭＬシーケンス図について説明しておく。図９の上部に並んだ矩形は、それぞれがクラスのオブジェクトを示している。各オブジェクトから下方に伸びた線は、各オブジェクトが生存していることを示す線（ライフライン）であり、上方から下方に向かって時間が流れているものとみなされる。この線上に存在する細長い矩形は、当該のオブジェクトが実際に活動している期間（活性期間）を示す。
【００９９】
各ライフラインの間を結ぶ横向きの矢印は、オブジェクトに含まれるの操作の実行を示す。具体的には、この矢印は、矢印の元のオブジェクトが、矢印の先のオブジェクトに含まれる操作を呼び出すことを示す。また、矢印が自分自身のオブジェクトを指している場合は、オブジェクトが自分に含まれる操作を自身で呼び出すことを意味する。
【０１００】
図９に示すように、ユーザインターフェースの制御部は利用者からの要求を取得すると、操作者クラス３１０のオブジェクトの要求する（）３１０ａを呼び出す（ステップＳ１０１）。そして、呼び出しを受けた操作者クラス３１０のオブジェクトは、受付クラスのオブジェクトの要求する（）３２０ｂを呼び出す（ステップＳ１０２）。
【０１０１】
呼び出しを受けた操作者クラス３１０のオブジェクトは、自身の受付処理（）３２０ｄを実行する。この操作では、受け付けている要求の数が属性区画のデータ（属性）である最大受付数３２０ａに達しているか否かが確認され、達している場合には呼び出し元に受付不能の旨が返される。受け付けている要求の数が最大受付数３２０ａに達していない場合には、呼び出し元の操作者クラス３１０のオブジェクトからの要求が初めてか否かを確認し、初めての場合には要求に適合するプランクラス３３０のオブジェクトが作成される。要求が初めてでない場合には、呼び出し元の操作者クラス３１０のオブジェクトに対応するプランクラス３３０のオブジェクトが検索される（ステップＳ１０３）。
【０１０２】
そして、ステップＳ１０３で作成もしくは検索されたプランクラス３３０のオブジェクトの変更する（）３３０ａを呼び出して、要求の内容をプランクラス３３０のオブジェクトに反映させる（ステップＳ１０４）。
【０１０３】
要求の内容を反映されたプランクラス３３０のオブジェクトは、自身の依頼先判断（）３３０ｂを呼び出して、要求を実現するためにどのオプションクラス３４０のオブジェクトに何を依頼する必要があるかを判断する（ステップＳ１０５）。そして、必要と判断したオプションクラス３４０のオブジェクトの変更する（）３４０ａを呼び出して依頼内容を反映させる（ステップＳ１０６）。
【０１０４】
要求の内容を反映されたオプションクラス３４０のオブジェクトは、操作制御部１１１ｂを通じて管理系サブシステム１１２もしくは実行系サブシステム１１３に必要な処理の実行を依頼する（ステップＳ１０７）。こうして、ユーザインターフェースの制御部から伝えられた要求は、管理系サブシステム１１２もしくは実行系サブシステムによって実行されることとなる。
【０１０５】
図８に示した各クラスの操作の実行手順についてもう一つ例を挙げて説明する。図１０は、管理系サブシステム１１２もしくは実行系サブシステム１１３から経過報告があった場合の操作の実行手順を示すＵＭＬシーケンス図である。
【０１０６】
同図に示すように、操作制御部１１１ｂは、管理系サブシステム１１２もしくは実行系サブシステム１１３から実行を依頼した処理の経過報告を受け取ると、対応するオプションクラス３４０のオブジェクトの経過報告（）３４０ｂを呼び出して経過報告に関する情報を引き渡す（ステップＳ２０１）。
【０１０７】
呼び出しを受けたオプションクラス３４０のオブジェクトは、当該の処理を依頼したプランクラス３３０のオブジェクトの経過報告（）３３０ｂを呼び出して経過報告に関する情報を引き渡す（ステップＳ２０２）。そして、呼び出しを受けたプランクラス３３０のオブジェクトは、受付クラス３２０のオブジェクトの経過報告（）３２０ｃを呼び出して経過報告に関する情報を引き渡す（ステップＳ２０３）。
【０１０８】
ここで、受付クラス３２０のオブジェクトは、自身の報告先判断（）３２０ｅを呼び出して、受け取った報告をどの操作者クラス３１０のオブジェクトに引き渡すかを判断する（ステップＳ２０４）。具体的には、ここでは、当該の処理の実行を要求した操作者クラス３１０のオブジェクトが引き渡し相手として選択されることになる。
【０１０９】
そして、受付クラス３２０のオブジェクトは、ステップＳ２０４で選択した操作者クラス３１０のオブジェクトの経過報告（）３１０ｂを呼び出して経過報告に関する情報を引き渡す（ステップＳ２０５）。情報を受け取った操作者クラス３１０のオブジェクトは、その情報をユーザインターフェースの制御部に引渡し、利用者に通知させる（ステップＳ２０６）。こうして、管理系サブシステム１１２もしくは実行系サブシステム１１３から発せられた経過報告は利用者に通知されることとなる。
【０１１０】
上述してきたように、本実施の形態では、オブジェクト指向設計により操作管理の仕組みを構築し、さらに本来は受付クラス３２０がもっていた役割をプランクラス３３０を設けてこれに委譲させ、個々の処理が簡略化されるように構成したので、操作管理の機能を効率よく実現することができる。
【産業上の利用可能性】
【０１１１】
以上のように、本発明に係る操作管理プログラム、操作管理方法および画像形成装置は、各種装置における操作管理に有用であり、特に、実現を効率よくおこない、機能追加や改修を容易におこなうことが必要な場合に適している。
【図面の簡単な説明】
【０１１２】
【図１】画像形成装置が接続されたネットワーク環境の一例を示す説明図である。
【図２】画像形成装置に搭載されるソフトウェアの構成の変遷を示す説明図である。
【図３】図２のオブジェクト指向アプリケーションの段階の画像形成装置のハードウェアおよびソフトウェアの構成を説明するための説明図である。
【図４】本実施の形態に係る画像形成装置のハードウェア構成を示すブロック図である。
【図５】統合アプリケーションの内部構成を示すブロック図である。
【図６】統合アプリケーションのＵＭＬクラス図である。
【図７−１】既存の処理を単純にオブジェクト化した場合のオブジェクトモデルを説明するための説明図である。
【図７−２】「受付」の処理を分割した場合のオブジェクトモデルを説明するための説明図である。
【図８】操作管理部のクラス構成を示すＵＭＬクラス図である。
【図９】ユーザインターフェースの制御部から処理要求があった場合の操作の実行手順を示すＵＭＬシーケンス図である。
【図１０】管理系サブシステムもしくは実行系サブシステムから経過報告があった場合の操作の実行手順を示すＵＭＬシーケンス図である。
【図１１】図２のサービス層分離後アプリケーションの段階の画像形成装置のハードウェアおよびソフトウェアの構成を説明するための説明図である。
【符号の説明】
【０１１３】
１  画像形成装置
１０  コントローラ
１１  ＣＰＵ
１２  ＭＥＭ−Ｐ
１２ａ  ＲＯＭ
１２ｂ  ＲＡＭ
１３  ＮＢ
１４  ＳＢ
１５  ＡＧＰ
１６  ＡＳＩＣ
１７  ＭＥＭ−Ｃ
１８  ＨＤＤ
２０  オペレーションパネル
３０  ＦＣＵ
４０  ＵＳＢインターフェース
５０  ＩＥＥＥ１３９４インターフェース
６０  エンジン部（Engine）
７０  ＰＣＩバス
１００  ソフトウェア
１０１  アプリケーション層
１０２  サービス層
１０２ａ  スキャナ制御プログラム
１０２ｂ  プロッタ制御プログラム
１０２ｃ  蓄積制御プログラム
１０２ｄ  配信／メール送受信制御プログラム
１０２ｅ  ＦＡＸ送受信制御プログラム
１０２ｆ  ネットワーク通信制御プログラム
１０２ｇ  その他の制御プログラム
１０３  オペレーティングシステム
１１０  統合アプリケーション
１１１  操作系サブシステム
１１１ａ  操作管理部
１１１ｂ  操作制御部
１１２  管理系サブシステム
１１３  実行系サブシステム
１２０  コピーアプリケーション
１３０  スキャナアプリケーション
１４０  ファックスアプリケーション
１５０  プリンタアプリケーション
２００  ハードウェア
２０１  ハードウェアリソース
２０１ａ  スキャナ
２０１ｂ  プロッタ
２０１ｃ  ＨＤＤ
２０１ｄ  ネットワークインターフェース
２０１ｅ  その他のリソース
３１０  操作者クラス（要求取得手順）
３１０ａ  要求する（）
３１０ｂ  経過報告する（）
３２０  受付クラス（要求受付手順）
３２０ａ  最大受付数
３２０ｂ  要求する（）
３２０ｃ  経過報告（）
３２０ｄ  受付処理（）
３２０ｅ  報告先判断（）
３３０  プランクラス（要求解析手順）
３３０ａ  要求する（）
３３０ｂ  経過報告する（）
３３０ｃ  依頼先判断（）
３４０  オプションクラス（実施依頼手順）
３４０ａ  要求する（）
３４０ｂ  経過報告する（）
４０１  サービス層分離前アプリケーション
４０２  サービス層分離後アプリケーション
４０３  共通ルーチン分離アプリケーション
４０４  オブジェクト指向アプリケーション
【図１】
2006042074.tif 000003
【図２】
2006042074.tif 000004
【図３】
2006042074.tif 000005
【図４】
2006042074.tif 000006
【図５】
2006042074.tif 000007
【図６】
2006042074.tif 000008
【図７−１】
2006042074.tif 000009
【図７−２】
2006042074.tif 000010
【図８】
2006042074.tif 000011
【図９】
2006042074.tif 000012
【図１０】
2006042074.tif 000013
【図１１】
2006042074.tif 000014