JP2007034486A - ユーザインターフェース装置、ソフトウェア部品管理方法、及びソフトウェア部品管理プログラム - Google Patents

Abstract

【課題】 ウィジェットの生成を効率化させソフトウェア品質を向上させ、かつ開発効率を向上させるユーザインターフェース装置、ソフトウェア部品管理方法、及びソフトウェア部品管理プログラムを提供する。
【解決手段】 画面の生成に必要な画面要素を画面テーブルが統合して管理し、画面サブシステム２０が画面テーブルに統合して管理される画面要素を用いて画面を生成することにより、表示される画面に応じて、必要な画面要素を画面サブシステム２０が抽出して画面を生成する。そのため、従来のユーザインターフェース装置と異なり、画面テーブルに画面ごとの画面要素を個別に設ける必要がなくなった。したがって、画面同士が類似した画面要素を有している場合は、１つの画面要素をのみを画面テーブルに保持させておけば、個別に類似する複数の画面要素をプログラミングする必要がない。
【選択図】 図２

Description

本発明は、ウィジェットの生成を効率化させソフトウェア品質を向上させ、かつ開発効率を向上させるユーザインターフェース装置、ソフトウェア部品管理方法、及びソフトウェア部品管理プログラムに関する。

近年、コンピュータハードウェアのパフォーマンスアップと低コスト化を受け、ソフトウェアの規模の増大とその対象となる問題の複雑化が年々増している。一方、それらソフトウェア商品、又は該ソフトウェア商品を組み込んだ機器の商品の開発サイクルは、年々短縮される傾向にある。そのような環境の中、ソフトウェア業界においてはその開発効率の改善が必然的な要求となっている。そのひとつの解決方法として、ソフトウェアの部品化が考えられる。これは、ソフトウェアを再利用しやすい形で構成することにより、一度作ったものを何度も使いまわし、それにより開発効率を向上させようという考えである。

ソフトウェア部品は、大きく２つに分けられる。一つはライブラリ管理である。これは、複数のシステムの共通機能を実現するソフトウェアを開発し、それを各システムで運用仕様書として使用するという方法である。ライブラリ管理は、再利用の粒度が小さいため、再利用の効果が小さい。また、複数のシステムで機能仕様を完全に一致させることは一般的に困難で、仕様が標準化されている分野など、特定の範囲でのみ有効であると考えられる。

もう一つのソフトウェア部品としては、フレームワークがある。フレームワークは、ソフトウェアで解決しようとしている問題領域（ドメイン）の骨格となる抽象モデル（フレームワーク）を作成し、それを複数のシステムで再利用しようという考えである。各システムでは、そのフレームワークにシステム特有の機能を肉付けすることにより構築される。フレームワークは、システムの骨格部分を再利用できるため再利用の効果が大きい。また、ドメイン共通な仕組みだけが実現されており、システム毎の詳細な機能は含んでいないため、同じ問題領域の広範囲のシステムに適用可能である。

これまで画像形成装置における操作パネルの制御は、与えられた画面フローの各画面に対して個別にプログラムを作成し、それを足し合わせることにより画面フローを実現する操作パネル制御システムを作成してきた。この方法による開発は、各画面の類似した機能を個別にプログラミングするため効率が悪い上に、画面フローが変更されると、これまでのプログラムを捨てて、一から作り直さなければならないという問題があった。

特許文献１では、複数の画面構成要素（ウィジェット）の組合せによって画面の描画を行うことにより、再利用可能なコンポーネントにより複数機種で利用可能なシステムを構成し、開発効率を改善するユーザインターフェース制御装置、ユーザインターフェース制御方法、及びその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記憶媒体が提案されている。ウィジェットは、テキスト、キー、入力領域等の基本的な要素としてフレームワークで捉えられており、各ウィジェットにはそれぞれ組合せによって実現される機能が割り付けられている。

特許文献２では、１つもしくは継承関係を伴う複数のクラスからなる呼出元機能と、１つもしくは継承関係を伴う複数のクラスからなる呼出先機能と、呼出元機能から呼び出されて呼出先機能を生成する生成クラスとを有することにより、呼出先のクラスに変更が加えられたときに容易にインターフェース保証を行うことができるプログラムが提案されている。
特開２０００−３１５１５２号公報 特開２００３−５９６８号公報

しかし、上記の発明は以下の問題を有している。

従来のユーザインターフェース装置、ソフトウェア部品管理方法、及びそれをコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記憶媒体は、新しい機能が追加され、それに伴い新しいウィジェットの種類が増えるにしたがって、ウィジェットの生成に関する処理が煩雑になり、システム全体の品質を劣化させる原因となる。

そこで、本発明は、ソフトウェア部品の構成を制御対象と制御方法とに分離して管理し、かつ制御方法は表示する画面に応じて制御対象を生成することにより、制御方法ごとに制御対象に係わるプログラムを追加する必要がなくなり、ソフトウェア部品の再利用性が向上し、メンテナンスし易くなるので、ソフトウェア開発者の負担を軽減し、開発効率を向上させることができるユーザインターフェース装置、ソフトウェア部品管理方法、及びソフトウェア部品管理プログラムを提案することを目的としている。

請求項１記載の発明は、情報を入力する入力部と、前記入力部による入力に対する応答結果を画面に表示する画面表示部を有する操作パネルとを有するユーザインターフェース装置において、前記画面の遷移を制御する画面遷移サブシステムと、前記画面表示部の画面構成要素を管理する画面サブシステムと、前記操作パネルのデバイスを管理するパネルサブシステムとを独立のソフトウェア部品として有し、前記ソフトウェア部品を用いて前記操作パネルの動作を制御する制御手段とを有し、前記画面サブシステムは、前記画面表示部の画面構成要素を生成するモデル部品と、このモデル部品によって生成された前記画面構成要素を出力するビュー部品と、前記画面構成要素の入力を管理し、前記モデル部品及び前記ビュー部品を操作するコントローラ部品とをそれぞれ独立に設け、前記制御手段により前記ビュー部品と前記コントローラ部品との組合せに応じ、前記モデル部品、前記ビュー部品、及び前記コントローラ部品が互いに協調して所望の機能を実現することを特徴とする。

請求項２記載の発明は、請求項１記載のユーザインターフェース装置において、前記画面構成要素を管理する画面テーブルと、前記モデル部品は、前記画面表示部の画面構成要素を前記画面テーブルに基づいて生成する生成クラスとを有することを特徴とする。

請求項３記載の発明は、請求項２記載のユーザインターフェース装置において、前記生成クラスは、１つもしくは継承関係を伴う複数のクラスからなる前記画面構成要素を生成することを特徴とする。

請求項４記載の発明は、請求項３記載のユーザインターフェース装置において、前記画面構成要素は、前記画面を表すウィンドウが複数のウィジェットを有する形で構成されることを特徴とする。

請求項５記載の発明は、情報を入力する入力部と、前記入力部による入力に対する応答結果を画面に表示する画面表示部を有する操作パネルとを有し、前記画面の遷移を制御する画面遷移サブシステムと、前記画面表示部の画面構成要素を管理する画面サブシステムと、前記操作パネルのデバイスを管理するパネルサブシステムとを独立のソフトウェア部品として有し、前記ソフトウェア部品を用いて前記操作パネルの動作を制御する制御手段とを有するユーザインターフェース装置のソフトウェア部品管理方法であって、前記画面サブシステムは、前記画面表示部の画面構成要素を生成するモデル部品と、このモデル部品によって生成された前記画面構成要素を出力するビュー部品と、前記画面構成要素の入力を管理し、前記モデル部品及び前記ビュー部品を操作するコントローラ部品とをそれぞれ独立に設ける工程と、前記制御手段により前記ビュー部品と前記コントローラ部品との組合せに応じ、前記モデル部品、前記ビュー部品、及び前記コントローラ部品が互いに協調して所望の機能を実現する工程とを有することを特徴とする。

請求項６記載の発明は、請求項５記載のソフトウェア部品管理方法において、前記ユーザインターフェース装置は、前記画面構成要素を管理する画面テーブルを有し、前記モデル部品は、前記画面表示部の画面構成要素を前記画面テーブルに基づいて生成する工程を有することを特徴とする。

請求項７記載の発明は、請求項６記載のソフトウェア部品管理方法において、前記生成工程は、１つもしくは継承関係を伴う複数のクラスからなる前記画面構成要素を生成することを特徴とする。

請求項８記載の発明は、請求項７記載のソフトウェア部品管理方法において、前記画面構成要素は、前記画面を表すウィンドウが複数のウィジェットを有する形で構成されることを特徴とする。

請求項９記載の発明は、情報を入力する入力部と、前記入力部による入力に対する応答結果を画面に表示する画面表示部を有する操作パネルとを有し、前記画面の遷移を制御する画面遷移サブシステムと、前記画面表示部の画面構成要素を管理する画面サブシステムと、前記操作パネルのデバイスを管理するパネルサブシステムとを独立のソフトウェア部品として有し、前記ソフトウェア部品を用いて前記操作パネルの動作を制御する制御手段とを有するユーザインターフェース装置のソフトウェア部品管理プログラムであって、前記画面サブシステムは、前記画面表示部の画面構成要素を生成するモデル部品と、このモデル部品によって生成された前記画面構成要素を出力するビュー部品と、前記画面構成要素の入力を管理し、前記モデル部品及び前記ビュー部品を操作するコントローラ部品とをそれぞれ独立に設ける処理と、前記制御手段により前記ビュー部品と前記コントローラ部品との組合せに応じ、前記モデル部品、前記ビュー部品、及び前記コントローラ部品が互いに協調して所望の機能を実現する処理とを有することを特徴とする。

請求項１０記載の発明は、請求項９記載のソフトウェア部品管理プログラムにおいて、前記ユーザインターフェース装置は、前記画面構成要素を管理する画面テーブルを有し、前記モデル部品は、前記画面表示部の画面構成要素を前記画面テーブルに基づいて生成する処理を有することを特徴とする。

請求項１１記載の発明は、請求項１０記載のソフトウェア部品管理プログラムにおいて、前記生成処理は、１つもしくは継承関係を伴う複数のクラスからなる前記画面構成要素を生成することを特徴とする。

請求項１２記載の発明は、請求項１１記載のソフトウェア部品管理プログラムにおいて、前記画面構成要素は、前記画面を表すウィンドウが複数のウィジェットを有する形で構成されることを特徴とする。

本発明は、ソフトウェア部品の構成を制御対象と制御方法とに分離して管理し、かつ制御方法は表示する画面に応じて制御対象を生成することにより、制御方法ごとに制御対象に係わるプログラムを追加する必要がなくなり、ソフトウェア部品の再利用性が向上し、メンテナンスし易くなるので、ソフトウェア開発者の負担を軽減し、開発効率を向上させることができる。

以下に本発明の一実施形態に係わる画像形成装置の構成及び動作について説明する。

まず、本実施形態に係わる画像形成装置のハードウェア構成について図１を用いて説明する。

本実施形態に係わる画像形成装置１００は、ＲＯＭ１、ＲＡＭ２、ＮＶＲＡＭ３、操作部４、読取部５、記憶部６、通信部７、モデム８、ホストＩ／Ｆ９、及びＣＰＵ１０を有して構成される。

ＲＯＭ１は、プログラムコード、フォント、及びその他の静的なデータが格納される。ＲＡＭ２は、一時的な記憶場所として利用される。ＮＶＲＡＭ３は、不揮発性のデータを格納する。操作部４は、操作パネル４ａとパネル制御部４ｂとを有して構成され、ユーザとのインターフェースを司る。読取部５は、スキャン/プリントエンジン５ａとエンジン制御部５ｂとを有して構成され、イメージデータの入出力ユニットとして、紙原稿の読み取りと転写紙への印刷を実行する。記憶部６は、記憶装置６ａとディスクドライバ６ｂとを有して構成され、大量のイメージデータなどの蓄積やデータベースの記憶場所として利用される。通信部７は、イーサネット（登録商標）等のネットワークに接続され、外部の機器との通信を可能とする。なお、操作部４と読取部５との通信に利用することも可能である。モデム８は、公衆回線と接続され、外部の機器との通信を実現する。ホストＩ／Ｆ９は、セントロニクスやＲＳ−２３２Ｃ等のインターフェースを用いてホスト外部の機器との通信を可能とする。

操作部４と読取部５とが同じＣＰＵ資源を共有するか否かにより、図１又は図２の構成が考えられる。本実施形態では、ハードウェア構成はどちらの構成にも対応する。

次に、本実施形態に係わる画像形成装置のソフトウェア構成について図３を用いて説明する。

画像形成装置１００のソフトウェアは、アプリケーションプログラム１１、パネル制御プログラム１２、エンジン制御プログラム１３、通信制御プログラム１４、パネルドライバ１５、エンジンドライバ１６、通信ドライバ１７、及びオペレーションシステム１８を有して構成される。

アプリケーションプログラム１１は、コピー、ファクス、プリンタなどの機能実行を管理する。パネル制御プログラム１２は、パネル制御部４ｂを介して操作パネル４ａを制御し、ユーザからの情報をアプリケーションプログラム１１に伝え、アプリケーションプログラム１１からの情報をユーザに伝える。パネルドライバ１５は、パネル制御プログラム１２の指示によりオペレーションシステム１８を介して操作パネル４ａを制御する。エンジン制御プログラム１３は、エンジンドライバ１６を介してスキャン／プリントエンジン５ｂを制御し、スキャン／プリントエンジン５ｂからの情報をアプリケーションプログラム１１に伝え、アプリケーションプログラム１１からの情報をスキャン／プリントエンジン５ａに伝える。エンジンドライバ１６は、エンジン制御プログラム１３の指示によりオペレーションシステム１８を介して物理スキャナ／プリントエンジン５を制御する。通信制御プログラム１４は、通信ドライバ１７を介してネットワーク通信を制御し、ネットワーク２００上の通信相手（ＰＣ３００）からの情報をアプリケーションプログラム１１に伝え、アプリケーションプログラム１１からの情報をネットワーク２００上の通信相手（ＰＣ３００）に伝える。通信ドライバ１７は、通信制御プログラム１４の指示によりオペレーションシステム１８を介して物理ネットワーク通信を制御する。オペレーションシステム１８は、各種ドライバからの指示に基づき物理デバイスを制御し、物理デバイスの情報を各デバイスドライバに伝え、各デバイスドライバからの情報を物理デバイスに伝える。

次に、本実施形態のソフトウェアを構成するユーザインターフェース部品（以下、ＵＩ部品とする）について図４を用いて説明する。なお、ソフトウェア部品は、画像形成装置１００内に存在する制御可能なリソースの集合である。本実施形態では、グラフィカル・ユーザインターフェースのアーキテクチャを利用し、画面サブシステムのソフトウェア部品を３つのカテゴリに分類している。

画面サブシステム２０には、画面テーブルが対応しており、ＭＶＣ（Model/View/Controller）におけるビューとコントローラとを関連付けて制御するようになっている。

ここで、ＭＶＣの概念とクラスをそれぞれ図５（ａ）と図５（ｂ）に示す。図５（ａ）において、ＭＶＣで用いられるモデル（Model）は、データ管理を専門に行い、画面遷移サブシステム４０から必要なＵＩアプリデータ（View Data）を取得し、ビュー（View）に提供する。ビューは、コントローラ（Controller）の指示により、モデルに対してＵＩアプリデータの取得を要求し、モデルからの表示位置や形態の変更通知に応じ、データモデルの表示（出力）を行うものである。また、コントローラは、ユーザからの要求（ここでは、ビューからの指示となる）を受け付け、モデル、ビュー、及び画面遷移サブシステム４０にメッセージを送るものである。なお、ＭＶＣのデータ構造とデータの操作は図５（ｂ）に示すとおりである。

次に、画面サブシステム２０周辺のソフトウェア部品の構造を図６に示す。

図６において、ビューにはそれぞれウィンドウとして独立したメニュー部品、ラベル部品、及びウィンドウ部品などがあり、コントローラにはそれぞれ独立したフォーカス制御部品、選択制御部品などがある。本実施形態では、前述したビューとコントローラとの組合せの適否関係を予め設定し、組合せを制限しながら必要な部品を呼び出して再利用するよう、構成されている。例えば図７に示すように、ビュー部品とコントローラ部品との組合せの適否関係が登録された、関係テーブル（関係設定手段に含まれる）をＲＯＭ１、ＮＶＲＡＭ３、記憶装置６等に更新可能に記憶しておいてもよい。

次に、画面遷移サブシステム４０の具体的な構成及び処理について説明する。

画面遷移サブシステム４０は、画面の遷移の管理を行うとともに、アプリケーションとのデータの受け渡しを行う。具体的には、画面の切り替え（画面単位の表示切り替え制御）、アプリケーションとのデータの入出力管理（画面要素の起動により実行されるアプリケーションのデータ（以下、ＵＩアプリデータとする）の取得、及びユーザによって入力されたデータのアプリケーションへの受け渡しを実行する。

次に、画面サブシステム２０の具体的な構成及び処理について説明する。画面サブシステム２０は、画面テーブルから画面要素を抽出し、その制御を実現する。ここで、画面要素とは、画面を構成する要素であり、ユーザへのデータの出力、及びユーザからのデータの入力を受け付ける。図６は、画面サブシステム６０をＵＭＬ（Unified Modeling Language）のクラス図により表現した図である。ここで、ＵＭＬとは、ＯＭＧ（Object Management Group）という団体がまとめたシステムモデリング言語であり、システムモデリングの成果を記述する記法を定義したものである。そして、このＵＭＬは、オブジェクト指向によるソフトウェア開発において、一般的に用いられている。

各クラスを示す矩形は３段の区画を有し、上から、クラス名を示す名前区画、クラスが有するデータ（属性）を示す属性区画、及びクラスが有する処理（操作）を示す操作区画と呼ばれる。たとえば、モデルクラスを示す矩形の名前区画は、かかるクラスのクラス名が「モデル」であることを示し、操作区画は、かかるクラスが有する操作が「値を取得する（）」、「値を変更する（）」、及び「変更通知を出す（）」であることを示している。

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

なお、属性や操作といったクラスの要素の左側に「−」記号を付した場合は、かかる要素は外部のクラスには非公開であることを示し、「＋」記号を付した場合は、かかる要素は外部のクラスに公開されていることを示す。また、操作については、「値を取得する（）」のように「（）」記号を付するのが通例である。

ここで、図６に示したクラス図について詳細に説明する。モデルクラスは、コントローラクラスが受け付けたユーザからの要求に応じて画面テーブルに保持される画面要素を抽出し、ビュークラスを生成する。具体的には、モデルクラスは、操作として、「値を取得する（）」、「値を変更する（）」、及び「変更通知を出す（）」を有する。

コントローラクラスは、操作として、「入力を受け付ける（）」を有し、サブクラスとしてフォーカス制御、及び選択制御を有する。

モデルクラスは、操作として、「値を取得する（）」、「値を変更する（）」、及び「変更通知を出す（）」を有する。コントローラクラスによりモデルクラスの値を取得する（）が呼び出されると、モデルクラスは、各画面の画面要素を画面テーブルから抽出する。

ビュークラスは、操作として、「表示する（）」、及び「表示を更新する（）」を有する。モデルクラス又はコントローラクラスによって表示する（）が呼び出されると、ビュークラスは、モデルクラスによって抽出された画面要素をパネルサブシステム３０へセットし、画面の表示を実行する。

なお、ビュークラスは、メニューの画面要素からなるメニュークラス、ラベルからなる画面要素のラベルクラス、ウィンドウからなる画面要素のウィンドウクラス等のサブクラスを有している。サブクラスは、画面を構成する新たな画面要素が追加される場合、ビュークラスのインスタンスとして適宜追加することができる。よって、新たな画面要素を追加する場合のソフトウェア開発者による開発効率を向上させることができる。また、モデルクラスは、要求された画面の表示に必要な画面要素のみを画面テーブルから抽出してビュークラスを生成するため、その処理の効率を向上させることができる。

ここで、モデルクラス（図９に示す）の具体的な構成、及びモデルクラスによって生成された画面要素（図８に示す）について説明する。

図９に示すように、モデルクラスは、画面に表示されるウィンドウを生成するウィンドウ生成クラス、該ウィンドウを構成する画面要素を画面テーブルから抽出するウィジェット生成クラス、及びウィジェット生成クラスの部分であり、実際にウィジェットを生成するクリエータクラスを有して構成される。また、ウィジェットクリエータクラスは、サブクラスとして集合ウィジェットクリエータクラス、テキストクリエータクラス、及びボタンクリエータクラスを有している。さらに、集合ウィジェットクリエータクラスは、サブクラスとしてメニュークリエータクラス及びフレームクリエータクラスを有している。

モデルクラスは、画面に表示されるウィンドウを生成するウィンドウクラス、該ウィンドウを構成する各種ライブラリからなる画面要素を生成するウィジェットクラス、及びウィジェットクラスのサブクラスを有して構成されるビュークラスを生成する。なお、本実施形態においては、ウィジェットクラスのサブクラスとして文字を表示するテキストクラス、画面上の押下対象を表示するボタンクラス、選択肢からの選択を行うメニュークラス、及び画面内でのまとまりとしてのフレームクラスを有している。ウィジェットクラスは、ウィンドウクラスによって表示される画面ごとに必要な画面要素を画面テーブルから抽出する。ここに、ウィジェットクラスの構造は、ウィジェットクラスを頂点とする階層構造をなし、メニューウィジェットとフレームウィジェットは、集合ウィジェットの下位に属する。ウィジェットクラスの基本動作は、ウィンドウにおけるイベントによりコマンドを実行してウィンドウに通知することであるが、ウィジェットクラスはその下位に属するウィジェットに共通するコマンドを実行し、下位に属するウィジェットはそれぞれ特有のコマンドを実行する。つまり、ウィンドウからのコマンド、例えば、テキストクラスに対する描画コマンドをウィジェットクラスの階層を通して伝え、コマンドを受けるテキストクラスにおける描画イベントの発生をウィジェットクラスの階層を通してウィンドウに通知する。

また、本ソフトウェア部品管理方法を採用する画像形成装置において、画面内のフレームを削除し、ユーザからの入力を受け付ける機能が必要となった場合、図１０に示すように、モデルクラスを構成する集合ウィジェットクリエータクラスのサブクラスからフレームクリエータクラスを削除し、エントリクリエータクラスを追加することにより、モデルクラスのソフトウェアの構成を変更することができる。なお、該モデルクラスのソフトウェアの構成を変更することにより、生成されるビュークラスの構成からフレームクラスが削除され、エントリクラスが新たに生成される。したがって、本構成によれば、ソフトウェアのパッケージング作業を行う際、不要なフレームクラス及びフレームクリエータクラスを削除し、エントリクラス及びエントリクリエータクラスを加えるだけで、ソフトウェアの構成を変更することができる。

次に、操作パネル４ａ上への描画動作例の概要を図１１を用いて説明する。この動作例は、画面の操作パネル４ａ上へのマッピング動作により、高速且つ効率よく画面表示を行うことを目的として構成される上記したシステムにおける画面表示動作に係わるものである。

図１０を参照して動作を説明する。画面サブシステム２０は、ユーザによって画面表示の指令が可能な画面で指令入力がなさると、コントローラクラスの入力を受け付ける（）を呼び出す（ステップＳ１１０１）。次に、コントローラクラスは、モデルクラスの値を取得する（）が呼び出す（ステップＳ１１０２）。モデルクラスは、ウィンドウ生成クラスを生成し（ステップＳ１１０３）、ウィンドウ生成クラスのウィンドウ生成（）を呼び出す（ステップＳ１１０４）。ウィンドウ生成クラスは、ウィジェット生成クラスのウィジェット生成（）を呼び出し（ステップＳ１１０５）、該ウィンドウを構成するウィジェットを画面テーブルから抽出・生成する（ステップＳ１１０６）。ウィジェットが生成されると、モデルクラスはビュークラスの表示する（）を呼び出す（ステップＳ１１０７）。生成されたウィジェットは、関係テーブルを基にコントローラからの描画指令により画面部品を利用して必要な画面要素を生成し、生成した画面データをパネルサブシステムにセットする。その後、コントローラがパネルサブシステムに対して表示要求を発行し、表示要求を受け取ったパネルサブシステムはウィジェットから送られセットされている画面データの内容に従って操作パネル４ａを利用した表示データへのマッピング動作を行う。

上述の構成によれば、画面の生成に必要な画面要素を画面テーブルが統合して管理し、画面サブシステムが画面テーブルに統合して管理される画面要素を用いて画面を生成することにより、表示される画面に応じて、必要な画面要素を画面サブシステムが抽出して画面を生成する。そのため、従来のユーザインターフェース装置と異なり、各画面に画面要素を個別に設ける必要がなくなった。したがって、画面同士が類似した画面要素を有している場合に個別に類似する画面要素をプログラミングする必要がなくなった。

画像形成装置のハードウェア構成を示すブロック図である。 画像形成装置のハードウェア構成を示すブロック図である。 画像形成装置のソフトウェア構成を示すブロック図である。 ユーザインターフェース部品の構成を示すブロック図である。 ＭＶＣの概念とクラスを説明するブロック図である。 画面サブシステムの構成を示すクラス図である。 関係テーブルの図である。 画面構成要素の構成を示すクラス図である。 モデルクラスの構成を示すクラス図である。 画面構成要素及びモデルクラスの構成を示すクラス図である。 画面生成シーケンスを示すシーケンス図である。

符号の説明

１ ＲＯＭ
２ ＲＡＭ
３ ＮＶＲＡＭ
４ 操作部
４ａ 操作パネル
４ｂ パネル制御部
５ 読取部
５ａ スキャン／プリントエンジン
５ｂ エンジン制御部
６ 記憶部
６ａ 記憶装置
６ｂ ディスクドライバ
７ 通信部
８ モデム
９ ホストＩ／Ｆ
１０ ＣＰＵ

Claims (12)

1. 情報を入力する入力部と、前記入力部による入力に対する応答結果を画面に表示する画面表示部を有する操作パネルとを有するユーザインターフェース装置において、
   前記画面の遷移を制御する画面遷移サブシステムと、前記画面表示部の画面構成要素を管理する画面サブシステムと、前記操作パネルのデバイスを管理するパネルサブシステムとを独立のソフトウェア部品として有し、
   前記ソフトウェア部品を用いて前記操作パネルの動作を制御する制御手段とを有し、
   前記画面サブシステムは、前記画面表示部の画面構成要素を生成するモデル部品と、このモデル部品によって生成された前記画面構成要素を出力するビュー部品と、前記画面構成要素の入力を管理し、前記モデル部品及び前記ビュー部品を操作するコントローラ部品とをそれぞれ独立に設け、
   前記制御手段により前記ビュー部品と前記コントローラ部品との組合せに応じ、前記モデル部品、前記ビュー部品、及び前記コントローラ部品が互いに協調して所望の機能を実現することを特徴とするユーザインターフェース装置。
2. 前記画面構成要素を管理する画面テーブルと、
   前記モデル部品は、前記画面表示部の画面構成要素を前記画面テーブルに基づいて生成する生成クラスとを有することを特徴とする請求項１記載のユーザインターフェース装置。
3. 前記生成クラスは、１つもしくは継承関係を伴う複数のクラスからなる前記画面構成要素を生成することを特徴とする請求項２記載のユーザインターフェース装置。
4. 前記画面構成要素は、前記画面を表すウィンドウが複数のウィジェットを有する形で構成されることを特徴とする請求項３記載のユーザインターフェース装置。
5. 情報を入力する入力部と、前記入力部による入力に対する応答結果を画面に表示する画面表示部を有する操作パネルとを有し、前記画面の遷移を制御する画面遷移サブシステムと、前記画面表示部の画面構成要素を管理する画面サブシステムと、前記操作パネルのデバイスを管理するパネルサブシステムとを独立のソフトウェア部品として有し、前記ソフトウェア部品を用いて前記操作パネルの動作を制御する制御手段とを有するユーザインターフェース装置のソフトウェア部品管理方法であって、
   前記画面サブシステムは、前記画面表示部の画面構成要素を生成するモデル部品と、このモデル部品によって生成された前記画面構成要素を出力するビュー部品と、前記画面構成要素の入力を管理し、前記モデル部品及び前記ビュー部品を操作するコントローラ部品とをそれぞれ独立に設ける工程と、
   前記制御手段により前記ビュー部品と前記コントローラ部品との組合せに応じ、前記モデル部品、前記ビュー部品、及び前記コントローラ部品が互いに協調して所望の機能を実現する工程とを有することを特徴とするソフトウェア部品管理方法。
6. 前記ユーザインターフェース装置は、前記画面構成要素を管理する画面テーブルを有し、
   前記モデル部品は、前記画面表示部の画面構成要素を前記画面テーブルに基づいて生成する工程を有することを特徴とする請求項５記載のソフトウェア部品管理方法。
7. 前記生成工程は、１つもしくは継承関係を伴う複数のクラスからなる前記画面構成要素を生成することを特徴とする請求項６記載のソフトウェア部品管理方法。
8. 前記画面構成要素は、前記画面を表すウィンドウが複数のウィジェットを有する形で構成されることを特徴とする請求項７記載のソフトウェア部品管理方法。
9. 情報を入力する入力部と、前記入力部による入力に対する応答結果を画面に表示する画面表示部を有する操作パネルとを有し、前記画面の遷移を制御する画面遷移サブシステムと、前記画面表示部の画面構成要素を管理する画面サブシステムと、前記操作パネルのデバイスを管理するパネルサブシステムとを独立のソフトウェア部品として有し、前記ソフトウェア部品を用いて前記操作パネルの動作を制御する制御手段とを有するユーザインターフェース装置のソフトウェア部品管理プログラムであって、
   前記画面サブシステムは、前記画面表示部の画面構成要素を生成するモデル部品と、このモデル部品によって生成された前記画面構成要素を出力するビュー部品と、前記画面構成要素の入力を管理し、前記モデル部品及び前記ビュー部品を操作するコントローラ部品とをそれぞれ独立に設ける処理と、
   前記制御手段により前記ビュー部品と前記コントローラ部品との組合せに応じ、前記モデル部品、前記ビュー部品、及び前記コントローラ部品が互いに協調して所望の機能を実現する処理とを有することを特徴とするソフトウェア部品管理プログラム。
10. 前記ユーザインターフェース装置は、前記画面構成要素を管理する画面テーブルを有し、
    前記モデル部品は、前記画面表示部の画面構成要素を前記画面テーブルに基づいて生成する処理を有することを特徴とする請求項９記載のソフトウェア部品管理プログラム。
11. 前記生成処理は、１つもしくは継承関係を伴う複数のクラスからなる前記画面構成要素を生成することを特徴とする請求項１０記載のソフトウェア部品管理プログラム。
12. 前記画面構成要素は、前記画面を表すウィンドウが複数のウィジェットを有する形で構成されることを特徴とする請求項１１記載のソフトウェア部品管理プログラム。

Images