JP5140708B2 - 電子機器用プログラム及び電子機器システム - Google Patents

Description

本発明は、表示装置と出力装置とに接続された電子機器に用いる電子機器用プログラム及び電子機器システムに関する。

従来、印刷物を出力する際の課題として、設計の際にイメージする出力データ仕様書と、実際に印刷される印刷物（レポートページ，ステータスページ）との整合性を確保することが挙げられる。

特許文献１は、このような課題に鑑みて、各種形式の元データを読み込み、ＸＭＬ形式の共通基礎情報を生成するスクリプトエンジンから共通基礎情報を取り込み、共通基礎情報を基にテンプレートエンジンから出力用テンプレートを読み込み、共通基礎情報を出力用テンプレートに従って処理し、プログラムや仕様書等の文書を生成するプログラムを開示している。

特許文献１の発明によれば、ＸＭＬ形式の共通基礎情報や出力用テンプレートに基づいて、所望のプログラムや仕様書等の文書を生成することができるので、形式が異なる設計書等の間の不整合減少によるプログラム開発の生産性の向上を図ることができ、また、機械的作業が軽減することによるプログラム開発の生産性、保守性、品質の向上が実現できると考えられる。

特開２００７−８７１２７号公報

印刷設計のシステム開発の一環として、始めに「出力データ仕様書」を作成し、その出力データ仕様書に基づいて印刷用の「ソースファイル」（プログラム）を作成することがある。この出力データ仕様書は、印刷用紙に印字される出力イメージを明確にするためのものであり、実際に印刷を行った用紙を評価する際の評価仕様書としても利用される。

しかし、このような従来の方法では、「出力データ仕様書」と「ソースファイル」との両方を作成する必要があるのみならず、始めに「出力データ仕様書」を作成し、その後「ソースファイル」を作成する必要があるため、開発期間が長くなるおそれがある。

また、「出力データ仕様書」と「ソースファイル」とを別々に作成する必要があるため、作成した「ソースファイル」がその元にした「出力データ仕様書」と一致しない場合がある。つまり、ソースファイルは、出力データ仕様書に基づいて、その仕様を忠実に再現することが求められているが、ソースファイルは人が作成するものであり、多少のバグやコーディングミス等はつきものである。

したがって、出来上がったソースファイルを実際にコンパイルしてプログラムを動作させても、出力データ仕様書通りに印刷物が生成されないことがある。この点、実際に出力された印刷物と出力データ仕様書とを見比べて、ソースファイルを何度も修正していけば、いずれは正しい出力結果が得られることにはなるが、その作業は大変手間である。

また、実際のレポートページ（ステータスページ）は、プリンタ等の機種にもよるが、設定項目が４０種類くらいあるため、どうしても細かい部分までチェックがいきとどかないのが現状である。

さらに、画像形成装置の仕様変更が発生した場合は、その都度「出力データ仕様書」と「ソースファイル」との両方を修正する必要がある。このため、まず「出力データ仕様書」を修正し、それに基づいて「ソースファイル」も修正しなければならないため、二重に手間がかかり、両者の整合性を保つことも大変な労力となる。

一方、特許文献１の技術は、各種形式の元データからＸＭＬ形式の共通基礎情報を生成し、その共通基礎情報からプログラムや仕様書等を作成するものであるが、ソースファイルの自動生成の具体的な処理内容については開示されていない。

そこで本発明は、出力データ仕様書からソースファイルを作成する際の手間を減らし、人為的なコーディングミスも軽減でき、仕様変更が発生した場合であっても、出力データ仕様書やソースファイルを簡単に修正することができる技術の提供を課題としたものである。

上記課題を解決するため、本発明は、第１に電子機器用プログラムを提供する。また本発明は、第２に電子機器システムを提供する。

〔電子機器用プログラム〕
本発明の電子機器用プログラムは、表示装置と出力装置とに接続された電子機器のコンピュータに、所定の記述言語で記述されたベースファイルから、表示装置での表示処理に必要な情報を読み出して、表示装置にベースファイルの内容に応じた情報を表示させる表示手順と、出力装置での出力処理に必要な情報であって出力装置の機種に依存して複数の機種で共通して使用できない機種依存情報をベースファイルから読み出し、読み出した機種依存情報から制御コードを含まずに関数情報及びその関数が必要とする引数により構成された変動ファイルを作成させる変動ファイル作成手順と、出力装置の機種に依存せずに複数の機種で共通して使用できる非機種依存情報が制御コードを含んで構成された固定ファイル、及び変動ファイル作成手順で作成した変動ファイルを用いて、出力装置にベースファイルの内容に応じた情報を出力させる出力手順とを実行させるための電子機器用プログラムである。

この発明によれば、１つのベースファイルに基づいてベースファイルの内容に応じた情報の表示を行いながら（例えば出力データ仕様書の表示）、これと同じベースファイルに基づいて変動ファイル（例えばヘッダファイル）を作成するので、ベースファイルの内容に応じた情報の表示と変動ファイルの作成とを同時に行うことができる。これにより、従来の「出力データ仕様書」と「ソースファイル」との両方を作成する作業が不要になる。

また、変動ファイルは、ベースファイルから自動生成されるので、ベースファイルから変動ファイルへの変換アルゴリズムが確立されている限り、コーディングミスによるバグの発生を防止することができる。

さらに、ベースファイルの内容に応じた情報の表示と変動ファイルの作成とは、１つのベースファイルに基づいて行われるので、両者の一致度を高めることができる。しかも、仕様変更が発生した場合は、ベースファイルのみを変更すればよく、従来のようにまず「出力データ仕様書」を修正し、それに基づいて「ソースファイル」も修正するといった二重の手間がかかることを回避することができる。

ここで、一般的に、出力データ仕様書等からソースファイル（Ｃ言語、Ｃ＋＋言語等）を自動生成することは技術的に難しいものである。これは、制御コード（例えば、判断処理や分岐処理等）を含む場合、それらをソースファイルに自動で落とし込む処理は技術的に困難であるとの理由による。この点、本願発明では、「変動ファイル」を、制御コードを含まずに関数情報及びその関数が必要とする引数により構成することによって、ベースファイルを単純に読み込んで、それを変動ファイルに書き込むだけの単純な処理でことが足りるため、容易に変動ファイルを自動生成することができる。

電子機器用プログラムの構成として、変動ファイル作成手順では、関数情報及びその関数が必要とする引数を構造体にまとめて変動ファイルを作成することが好ましい。

この発明によれば、関数情報及びその関数が必要とする引数を構造体にまとめることにより、コンパクトでメモリ容量も必要としない変動ファイルとすることができる。また、複数の関数を構造体にまとめることにより、開発の過程で使用しなくなった関数については、例えばコメントアウトする等といった簡単な作業で呼び出しの可否を変更することができ、メンテナンスも行いやすいファイル構成とすることができる。

電子機器用プログラムの構成として、変動ファイル作成手順では、親構造体及び子構造体を生成し、複数の関数情報及び子構造体の参照先アドレスを親構造体にまとめ、親構造体にまとめた各関数が必要とする引数を子構造体にまとめることが好ましい。

この発明によれば、変動ファイルで管理する情報のうち、関数情報は親構造体にまとめ、各関数が必要とする引数は子構造体にまとめることにより、構造体の定義の関係上必要となる不使用領域を減らすことができ、オブジェクトサイズをより小さなものとし、メモリの使用量を大幅に削減することができる。

〔電子機器システム〕
本発明の電子機器システムは、所定の記述言語で記述されたベースファイルから、表示処理に必要な情報を読み出して、ベースファイルの内容に応じた情報を表示する表示手段と、出力処理に必要な情報であって機種に依存して複数の機種で共通して使用できない機種依存情報をベースファイルから読み出し、読み出した機種依存情報から制御コードを含まずに関数情報及びその関数が必要とする引数により構成された変動ファイルを作成する変動ファイル作成手段と、機種に依存せずに複数の機種で共通して使用できる非機種依存情報が制御コードを含んで構成された固定ファイル、及び変動ファイル作成手段が作成した変動ファイルを用いて、ベースファイルの内容に応じた情報を出力する出力手段とを備えることを特徴とする電子機器システムである。

この発明によれば、上述した電子機器用プログラムの発明と同様な効果を得つつ、その効果をシステム全体で実現することができるという有用性がある。

本発明によれば、１つのベースファイルに基づいて、出力データ仕様書等の表示と変動ファイルの自動生成とを行うので、開発過程における作業負担を軽減させることができる。また、変動ファイルを制御コードを含まずに関数情報及びその関数が必要とする引数によって構成することにより、変動ファイルを容易に自動生成することができる。

画像形成装置１０１及び電子機器２０１を含む電子機器システムの構成例を概略的に示す図である。 プログラム４００を実現するためのレポートページ自動生成アルゴリズムのアーキテクチャ（ソフトウエア構成図）を示す図である。 ＸＭＬファイルの内容を示す連続図である（１／２）。 ＸＭＬファイルの内容を示す連続図である（２／２）。 ＸＭＬブラウザでの処理の流れを概念的に示す図である。 ソースファイル変換ツールでの処理の流れを概念的に示す図である。 固定部の詳細について説明する図である。 印刷物が出力される過程を示す図である。 従来の構造体の構成例について示す図である。 本実施形態の構造体の構成例について示す図である。 電子機器システムの制御の流れを示すフローチャートである。

以下、本発明の電子機器用プログラム及び電子機器システムの実施形態について説明する。

図１は、画像形成装置（出力装置，出力手段）１０１及び電子機器２０１を含む電子機器システムの構成例を概略的に示す図である。電子機器システムは、画像形成装置１０１を備えるとともに、電子機器２０１の一例としてパーソナルコンピュータを備えている。これら画像形成装置１０１及び電子機器２０１がネットワーク２に接続された状態で、１つの電子機器システム（ネットワーク環境）が構成されている。

先ず、画像形成装置１０１の構成について説明する。
画像形成装置１０１は、例えばネットワークプリンタに代表されるネットワーク機器である。プリンタとして機能するため、画像形成装置１０１は図示しないプリントエンジンを内蔵している。プリントエンジンには、図示しない感光体ドラムや帯電器、露光ユニット、トナー現像ユニット（カラープリンタである場合は中間転写ベルト）等が含まれる。さらに画像形成装置１０１には、図示しない給紙装置が付属する。

なお、ここではネットワークプリンタを例に挙げているが、画像形成装置１０１はネットワーク対応のデジタル複合機であってもよい。この場合、画像形成装置１０１はさらに画像読取部を備える。画像読取部には、例えばスキャナランプ及びミラーが搭載された走査光学系のほか、集光レンズ及びＣＣＤ等の光学素子が内蔵される。また画像読取部に付属して、原稿自動搬送機構（ＡＤＦ）が装備される態様であってもよい。

また画像形成装置１０１は、電子機器システム内で動作するための構成を有する。具体的には、通信インタフェース１０２や制御部１０３等が画像形成装置１０１に装備されている。

上記通信インタフェース１０２は、ネットワーク２に接続するための通信アダプタである。また制御部１０３は、コンピュータとして機能する要素であり、例えばプロセッサ（ＣＰＵ）やメモリ（ＲＯＭ、ＲＡＭ等）を実装した電子回路基板の形態で画像形成装置１０１に内蔵されている。この制御部１０３は、通信インタフェース１０２による通信を制御するだけでなく、画像形成装置１０１が行う各種の処理や動作を制御する機能を有している。

次に、電子機器２０１の構成を説明する。
電子機器２０１には、一般に普及しているデスクトップ型ＰＣやノートブック型ＰＣを適用することができる。電子機器２０１の一般的な構成例として、プロセッサ（ＣＰＵ，変動ファイル作成手段）２０２や通信インタフェース２０３、記憶装置２０４、表示制御部２０５、入力制御部２０６等を備えたものが挙げられる。また電子機器２０１には、表示装置（表示手段）３０１や入力装置３０２が接続されている。

通信インタフェース２０３は、ネットワーク２に接続するための通信アダプタである。また、記憶装置２０４は、内蔵のハードディスクやメモリ等の記録デバイスである。表示装置３０１はいわゆるディスプレイ、モニタに相当するハードウエアであり、表示制御部２０５はディスプレイアダプタである。また入力装置３０２はキーボード、ポインティングデバイス等に相当するハードウエアであり、入力制御部２０６はそのアダプタである。

以上が電子機器システムの基本的な構成である。加えて本実施形態では、電子機器２０１にインストールされたプログラム（電子機器用プログラム）４００をコンピュータにより実行することで、本実施形態に係る電子機器システムの機能を実現することができる。なお、プログラム４００は、記憶装置２０４に記憶されていてもよい。

次に、本実施形態で用いるプログラム４００の詳細について説明する。
図２は、プログラム４００を実現するためのレポートページ自動生成アルゴリズムのアーキテクチャ（ソフトウエア構成図）を示す図である。
まず、図中ステップＳ１に示すように、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）ファイルを作成する。このＸＭＬファイルは、人が手作業で作成するものである。ここで、ＸＭＬとは、文書構造の記述言語の１つであり、ＨＴＭＬ（ｈｙｐｅｒ ｔｅｘｔ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）の拡張版にあたる。ＸＭＬは、ＳＧＭＬ（ｓｔａｎｄａｒｄ ｇｅｎｅｒａｌｉｚｅｄ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）をインターネット用に最適化したものであり、文書内のデータに対してユーザーが独自の属性情報や論理構造を定義することができる。

図３及び図４は、ＸＭＬファイルの内容を示す連続図である。
図３及び図４の例では、７つのブロック（Ａ〜Ｇ）について記述している。
ＸＭＬファイルでは、レポートページ用に新たにタグを定義しており、いずれのブロックも上から順に、「ライブラリ関数名」、「メッセージ」、「メッセージ出力位置（Ｘ座標、Ｙ座標）」、「関数が参照する変数」、「フォント」、「フォントの色」、「外部関数名」の項目について設定（規定）されている。

ここでは、図３の１番目のブロックＡについて説明する。なお、図３及び図４に示す２番目のブロックＢから７番目のブロックＧについては、図３の１番目のブロックＡと詳細な内容はそれぞれ異なるが、タグの定義の仕方等の基本的な内容は１番目のブロックＡと同様である。

＜Ｆｕｎｃｔｉｏｎ＞ｒｐｇ＿ｐｒｉｎｔｆ＜／Ｆｕｎｃｔｉｏｎ＞
この記述は、「ライブラリ関数名」がｒｐｇ＿ｐｒｉｎｔｆであるということを示している。この関数は、以下の「メッセージ」の内容を画像形成装置１０１を用いて実際に印字するための関数である。

＜Ｍｅｓｓａｇｅ＞ジョブエラーレポート＜／Ｍｅｓｓａｇｅ＞
この記述は、「メッセージ」として、ジョブエラーレポートという文字を出力することを示している。「ジョブエラーレポート」の文言は、上記関数「ｒｐｇ＿ｐｒｉｎｔｆ」によって出力される。

＜Ｐｏｓｉｔｉｏｎ＞０，０＜／Ｐｏｓｉｔｉｏｎ＞
この記述は、「メッセージ」の出力が、（Ｘ座標，Ｙ座標）＝（０，０）の位置で出力されることを示している。

＜Ｖａｒｉａｂｌｅ＞＜／Ｖａｒｉａｂｌｅ＞
この記述は、関数が参照する変数がないことを示している。なお、参照する変数があれば、その変数を記述する必要がある。

＜Ｆｏｎｔ＞ＭＳ Ｐゴシック＜／Ｆｏｎｔ＞
この記述は、「メッセージ」をＭＳＰゴシックで表示するということを示している。

＜ＦｏｎｔＳｉｚｅ＞１６＜／ＦｏｎｔＳｉｚｅ＞
この記述は、「メッセージ」を１６ポイントの大きさで表示するということを示している。

＜ＦｏｎｔＣｏｌｏｒ＞Ｂｌｕｅ＜／ＦｏｎｔＣｏｌｏｒ＞
この記述は、「メッセージ」を青色で表示するということを示している。

＜ＥｘｔＦｕｎｃｔｉｏｎ＞＜／ＥｘｔＦｕｎｃｔｉｏｎ＞
この記述は、外部関数を使用しないことを示している。なお、使用する外部関数があれば、その外部関数を記述する必要がある。

次に、図２中ステップＳ２に示すように、作成したＸＭＬファイル（図３及び図４参照）を、ＸＭＬブラウザに入力する。ここで、ＸＭＬブラウザとは、ＸＭＬファイルに記述された内容を表示装置３０１にて閲覧するためのソフトウェアである。ＸＭＬブラウザは、一度作成すると以降汎用ツールとして使用可能になる。ＸＭＬブラウザは、ＸＭＬファイルを読み込んで、ＸＭＬファイルの内容を出力データ仕様書（紙への印字イメージ）として表示装置３０１に表示する（図２中ステップＳ３参照）。

図５は、ＸＭＬブラウザでの処理の流れを概念的に示す図である。
ＸＭＬブラウザは、ＸＭＬファイルに記述された内容のうち、ＸＭＬブラウザで有効なタグを判断する。
例えば、ＸＭＬファイルの＜Ｆｕｎｃｔｉｏｎ＞ｒｐｇ＿ｐｒｉｎｔｆ＜／Ｆｕｎｃｔｉｏｎ＞の項目については、「×（不必要項目）」の判断となっている。これは、＜Ｆｕｎｃｔｉｏｎ＞の項目は、画像形成装置１０１では必要な関数であるが、ＸＭＬブラウザで表示する場合には必要のない項目であるからである。

これに対して、ＸＭＬファイルの＜Ｍｅｓｓａｇｅ＞ジョブエラーレポート＜／Ｍｅｓｓａｇｅ＞の項目については、「○（必要項目）」の判断となっている。これは、＜Ｍｅｓｓａｇｅ＞の項目は、画像形成装置１０１で必要な関数であるとともに、ＸＭＬブラウザで表示する場合にも必要のある項目であるからである。
どの項目を「○（必要項目）」「×（不必要項目）」にするかは、ＸＭＬブラウザにて必要な項目を予め定義しておくことにより、必要な項目のみを抜き出すことができる。

そして、ＸＭＬブラウザにて必要な項目（図中「○」の項目）のみを抜き出すことにより、表示装置３０１に「出力データ仕様書１０」が表示される。出力データ仕様書１０の内容は、ＸＭＬファイルから必要な項目のみを抜き出した内容が表示されるものであり、具体的には、「ジョブエラーレポート／現象：複数部数印刷の要求に対して、１部しか印刷できませんでした。／理由：メモリオーバーフローです。／解決方法：拡張メモリ（ＲＡＭ）を装着してください。」といった内容が表示される。この内容は、図３及び図４のＸＭＬファイルの全てのブロック（Ａ〜Ｇ）の内容を結合して表示したものである。

次に、図２中ステップＳ４に示すように、作成したＸＭＬファイル（図３及び図４参照）を、ソースファイル変換ツールに入力する。ここで、ソースファイル変換ツールとは、ＸＭＬファイルに記述された内容をヘッダファイルに変換するソフトウェアである。ソースファイル変換ツールは、一度作成すると、以降汎用ツールとして使用可能になる。ソースファイル変換ツールは、ＸＭＬファイルを読み込んで、変動部３０のヘッダファイルを作成する（図２中ステップＳ５参照）。

図６は、ソースファイル変換ツールでの処理の流れを概念的に示す図である。
ソースファイル変換ツールは、ＸＭＬファイルに記述された内容のうち、ヘッダファイルで有効なタグを判断する。

ソースファイル変換ツールは、ＸＭＬブラウザとは異なり、全ての項目を有効なタグと判断する。その結果、全ての項目が「○（必要項目）」の判断となっている。これは、実際に印刷を行う際には、ＸＭＬファイルに記述されている内容が全て必要な項目であるからである。

そして、ソースファイル変換ツールにてＸＭＬファイルの全ての項目を抜き出すことにより、変動部３０のヘッダファイルが自動生成される。ＸＭＬファイルには、文字列しか羅列されておらず制御の要素が入っていないため、これらの文字列は、簡単にヘッダファイルに変更することができる。例えば、ＸＭＬファイルを上から順に読み込んでいき、カッコとカッコの間にある文字列を単純に抜き出すことで実現可能である。

そして、図６に示すように、変動部３０のヘッダファイルは、関数情報（関数ポインタ）及びその関数が必要とする引数を有する構造体により構成されている。
具体的には、１番上のブロックについては、一番左側に関数情報としての「ｒｐｇ＿ｐｒｉｎｔｆ」、その右側に引数としての「ジョブエラーレポート」、「０，０」、「Ｄｕｍｍｙ」、「ＭＳ Ｐゴシック」、「１６」、「Ｂｌｕｅ」、「Ｄｕｍｍｙ」が順に並んでいる。２番目のブロックについては、関数情報としての「ｒｐｇ＿ｐｒｉｎｔｆ」、引数としての「現象：」、「０，１０」、「Ｄｕｍｍｙ」、「ＭＳ Ｐゴシック」「１１」「Ｂｌａｃｋ」、「Ｄｕｍｍｙ」が順に並んでいる。ここで、「Ｄｕｍｍｙ」とは、具体的な引数がないことを示している。

実際の構造体は、プログラム言語によってもその記述方式は異なってくるが、例えば以下のように記述する。
ｓｔｒｕｃｔ ｋａｎｓｕｕ｛
ｆｕｎｃ１，ａ，ｂ，ｃ；／＊ ｆｕｎｃ１の関数ポインタ及び引数 ＊／
ｆｕｎｃ２，ｄ，ｅ，ｆ；／＊ ｆｕｎｃ２の関数ポインタ及び引数 ＊／
ｆｕｎｃ３，ｇ，ｈ，ｉ；／＊ ｆｕｎｃ３の関数ポインタ及び引数 ＊／
｝；

そして、実際にコンパイルによってオブジェクトファイルを作成するためのファイルとしては、図２に示すように、固定部２０と変動部３０とが必要である。固定部２０は、Ｃ言語であれば「ｆｉｌｅ０１．ｃ」等のプログラムファイル（固定ファイル）で構成され、変動部３０は「ｈｅａｄｅｒ０１．ｈ」等のヘッダファイル（変動ファイル）で構成される。

本実施形態では、固定部２０のプログラムファイルには、画像形成装置１０１の機種に依存せずに複数の機種で共通して使用できる非機種依存情報を記述し、変動部３０のヘッダファイルには、画像形成装置１０１の機種に依存して複数の機種で共通して使用できない機種依存情報を記述している。
これは、例えば、まず最初の一機種を作って、つぎに、また新しい機種を作る場合、全てのプログラムを修正するのは大変であるから、固定部２０のプログラム部分はそのまま残しておいて、変動部３０のプログラム部分だけを修正するためのものである。固定部２０に関しては、同じプログラムを継続して使用できるので、プログラム開発の生産性が高まり、不具合も少なくなるので、ソフトウエアとしての安定性が確保できる。

ここで、固定部２０は、ライブラリ関数の集合である。各々のライブラリ関数は、機能毎に部品化する。各々のライブラリ関数は、機種に依存せず使用可能にする。ライブラリ関数は、初めの機種開発で作成する。ライブラリ関数は、２機種目以降の開発では、機能追加した部分のみを部品として追加する。

また、固定部２０は、機能毎にライブラリ関数を集め、機能毎に一つのソースファイルとする。これにより、ある機種で不要な機能は、該当するソースファイルをコンパイル時のリンク対象から外すことで、コンパイルしないようにすることができ、最終的に生成されるオブジェクトファイル（実行ファイル）のサイズを小さくすることができる。例えば、ＦＡＸ関連のライブラリ関数群は、ｆａｘ＿ｌｉｂ．ｃｐｐにまとめ、プリンタ機ではＦＡＸ機能が不要なので、リンク時にｆａｘ＿ｌｉｂ．ｃｐｐをリンク対象から外すようにすればよい。

また、固定部２０のプログラムファイルは、制御コード（例えば、ｆｏｒ文等のループ処理や、ｉｆ文等の分岐処理）を含んだ態様で構成しているが、変動部３０のヘッダファイルは、制御コードを含まずに関数情報及びその関数が必要とする引数により構成された構造体によって構成している。

変動部３０のヘッダファイルは、上述したように「ＸＭＬファイル」から自動生成され、変動部３０は、ヘッダファイルのみで構成される。変動部３０をヘッダファイルのみで構成することで、ＸＭＬファイルから容易にヘッダファイルを自動生成することができる。変動部３０のヘッダファイルには、固定部２０にあるライブラリ関数を呼び出すための「関数ポインタ」とその「引数」を記述する。機種依存部分については、変動部３０のヘッダファイルに記述する関数ポインタ（固定部のライブラリ関数を呼び出す際のアドレス）を変更することで対応することができる。

例えば、固定部２０のプログラムファイルのメインループでは、全ての関数をコールするように設計しておき、変動部３０のヘッダファイルでは、不必要な関数をコメント化（無効化）することができるので、ある機種では、ｆｕｎｃ１、ｆｕｎｃ２、ｆｕｎｃ３、ｆｕｎｃ４の全ての関数の呼び出しをしたり、ある機種では、ｆｕｎｃ１、ｆｕｎｃ３をコメント化すれば、ｆｕｎｃ２、ｆｕｎｃ４といったように限定した関数の呼び出しをしたりできるようになる。このように、固定部２０において全ての関数を用意しておき、変動部３０のヘッダファイルでは、コメント化により呼び出し関数を調整することにより、呼び出し関数を簡単に選択することができる。

図７は、固定部の詳細について説明する図である。
固定部２０のプログラムファイルに関しては、プログラムを自動生成することはできないので、開発の最初の段階で人が自らコーディングして固定部２０のプログラムファイルを作成する必要がある。具体的には使用するプログラム言語の記述方法に倣って記述する。

図示の例では、
ｒｐｇ＿ｐｒｉｎｔｆ（”現象：”，０，１０，Ｄｕｍｍｙ，”ＭＳ Ｐゴシック”，１１，”Ｂｌａｃｋ”，Ｄｕｍｍｙ）
｛
／／ ここに、引数で指定された文字列が印刷される様にプログラムを記述する
｝
と記載しており、小かっこの中に実際に使用する引数を記述し、大かっこの中に、引数で指定された文字列が印刷されるようにプログラムのコードを記述する。この関数は、図３の２番目のブロックＢに対応する関数である。

図８は、印刷物が出力される過程を示す図である。
そして、これらソースファイル（固定部のプログラムファイル及び変動部のヘッダファイル）をコンパイルすることにより、オブジェクトファイルが作成され、このオブジェクトファイルを実際に実行することにより、印刷物（レポートページ，ステータスページ）７０が画像形成装置１０１から出力される。印刷物７０の印刷内容は、図５のものと同様である。

コンパイルに関しては、図２に示すように、ＲＰＧ（Ｒｅｐｏｒｔ Ｐｒｏｇｒａｍ Ｇｅｎｅｒａｔｏｒ）コンポーネントのみならず、必要に応じて他のコンポーネントから提供される外部関数４０や変数領域５０、メッセージ領域６０を組み合わせて行うことができる。

次に、構造体の最適化について説明する。
図９は、従来の構造体の構成例について示す図であり、図１０は、本実施形態の構造体の構成例について示す図である。

図９に示すように、従来の構造体では、プログラム言語の制約上、構造体を構成するメンバのうち最も引数の多いメンバに全てのメンバの引数の数を一致させる必要があった。図９の例では、構造体Ａに関数ポインタとその関数の引数を格納しているが、関数５の引数が１０個なので、他の関数の引数の数も１０個に合わせている。このため、未使用と記載されている部分は、実際には不要な引数であるが、構造体の定義の関係上、ダミーとなる引数を設定しなければならず、その分メモリ領域が無駄になっていた。図示の例では、１３６個のメモリ領域が無駄になっている。

これに対して本実施形態の構造体では、図１０に示すように、従来の構造体のように１つの構造体に「関数ポインタ」及び「引数」の情報をまとめるのではなく、２つの種類の構造体に分けて「関数ポインタ」及び「引数」の情報を配置している。具体的には、「関数ポインタ」は構造体Ｂ（親構造体）に配置し、「引数」は構造体１〜２０（子構造体）に配置している。また、構造体Ｂには、別の構造体１〜２０の参照先アドレス（各構造体へのポインタ）が配置されている。

このように、各関数の引数を構造体Ｂ内に配置するのではなく、それぞれ独立した別の構造体１〜２０に配置することで、不要な引数を削除することができる。図１０の例では、図９の例と比較して構造体自体の数は増えているが、図９で未使用であるが領域を確保していた部分を全て削除することができ、実際に使用されない余分なメモリ領域を削除することができる。これにより、ヘッダファイル（構造体）をコンパイルした後のオブジェクトサイズを小さくすることができる。

次に、本実施形態の電子機器システムの制御の流れについて説明する。
図１１は、電子機器システムの制御の流れを示すフローチャートである。以下、ステップＳ１１０からステップＳ１６０までの手順について説明する。また以下の説明により、電子機器用プログラムが画像形成装置１０１及び電子機器２０１のコンピュータに実行させる手順例が明らかとなる。

ステップＳ１１０：プロセッサ２０２がプログラム４００を動作させることにより、ＸＭＬブラウザが起動され、ＸＭＬファイルがＸＭＬブラウザに入力される。

ステップＳ１２０：ＸＭＬブラウザによって、出力データ仕様書１０が表示装置３０１に表示される（表示手順）。

ステップＳ１３０：プロセッサ２０２がプログラム４００を動作させることにより、ソースファイル変換ツールが起動され、ＸＭＬファイルがソースファイル変換ツールに入力される。

ステップＳ１４０：ソースファイル変換ツールによって、変動部のヘッダファイルが自動生成される（変動ファイル作成手順）。このステップでは、関数情報及びその関数が必要とする引数を、図１０で説明した構造体にまとめてヘッダファイルが作成される。

ステップＳ１５０：プロセッサ２０２がプログラム４００を動作させることにより、プログラムファイル、ヘッダファイル及びその他必要なファイルがまとめてコンパイルされ、オブジェクトファイルが得られる（出力手順）。

ステップＳ１６０：プロセッサ２０２がプログラム４００を動作させて、オブジェクトファイルが実行されることにより、印刷物（レポートページ，ステータスページ）７０が得られる（出力手順）。そして、作業員が、この印刷物７０と表示装置３０１に表示された出力データ仕様書１０とを見比べることにより、両者の整合性を確かめ、実際の紙への出力状態と、画面上の出力イメージとを評価する。
なお、「ステップＳ１３０〜Ｓ１６０」を先に処理して、「ステップＳ１１０，Ｓ１２０」を後に処理してもよく、また、「ステップＳ１１０，Ｓ１２０」の処理と「ステップＳ１３０〜Ｓ１６０」の処理とを平行して処理を行うようにしてもよい。

このように、本実施形態によれば、「出力データ仕様書」と「変動部のヘッダファイル」とを自動生成するアルゴリズムを提供しているので、「出力データ仕様書」と「変動部のヘッダファイル」とを同時に生成可能とし、開発期間の短縮を図ることができる。

通常は、「出力データ仕様書」（出力イメージ）を作成してから、「ソースファイル」（プログラム）の作成を行うが、本実施形態では、始めにＸＭＬファイルを作成し、そこから「出力データ仕様書」と「変動部のヘッダファイル」とを自動生成している。これにより、「出力データ仕様書」（出力イメージ）と「印刷物」（プログラムの実装によって得られるレポートページ）とが異なるという不具合の発生防止に寄与することができる。

また、仕様変更が生じた場合でも、ＸＭＬファイルのみを修正すればよいので、手直しに要する工数を大幅に短縮することができる。

一般的に、仕様書からソースファイル（Ｃ言語、Ｃ＋＋言語等）を自動生成することは技術的に難しいが、本実施形態では、固定部をライブラリ関数群で構成し、変動部をヘッダファイルのみで構成することにより、変動部のヘッダファイルを容易に自動生成することができ、ソフトウェアの品質も格段に向上させることができる。

さらに、始めに２つのソフトウェアツール（ＸＭＬブラウザ、ソースファイル変換ツール）を新規に作成する必要があるが、これらのツールが完成すれば、「出力データ仕様書」と「変動部のヘッダファイル」とが自動生成されるので、その後の開発期間（工数）の短縮が可能となる。

さらにまた、仕様変更に伴う新規機能については、「固定部」にライブラリ関数を追加し、追加したライブラリ関数へのポインタを、「変動部」のヘッダファイルに登録するだけの簡単な修正で済む。つまり、「固定部」のライブラリ関数群は一度作成すると変更不要となり、ソースコード変更に因るデグレード（改善を加えたにもかかわらず、以前より品質や機能が悪くなること）の危険性がなくなり、ソフトウェアの品質向上につながる。

そのうえ、「固定部」のライブラリ関数は、機能毎に部品化されているので、ソースコードの解析が容易になり、保守性が向上する。

本発明は、上述した一実施形態に制約されることなく、各種の変形や置換を伴って実施することができる。ベースファイルは、ＸＭＬファイルではなく、ＨＴＭＬファイルやＳＧＭＬファイル等であってもよい。

また、本発明のアルゴリズムは、Ｃ言語やＣ＋＋言語を用いて実現された各種の組込機器にて利用可能である。

さらに、一実施形態で挙げた画像形成装置１０１や電子機器２０１の構成はいずれも好ましい例示であり、これらを適宜変形して実施可能であることはいうまでもない。

２ ネットワーク
１０ 出力データ仕様書
２０ 固定部
３０ 変動部
７０ 印刷物
１０１ 画像形成装置（出力装置，出力手段）
１０２ 通信インタフェース
１０３ 制御部
２０１ 電子機器
２０２ プロセッサ（変動ファイル作成手段）
２０３ 通信インタフェース
２０４ 記憶装置
２０５ 表示制御部
２０６ 入力制御部
３０１ 表示装置（表示手段）
３０２ 入力装置
４００ プログラム（電子機器用プログラム）

Claims (4)

1. 表示装置と出力装置とに接続された電子機器のコンピュータに、
   所定の記述言語で記述されたベースファイルから、前記表示装置での表示処理に必要な情報を読み出して、前記表示装置に前記ベースファイルの内容に応じた情報を表示させる表示手順と、
   前記出力装置での出力処理に必要な情報であって前記出力装置の機種に依存して複数の機種で共通して使用できない機種依存情報を前記ベースファイルから読み出し、読み出した前記機種依存情報から制御コードを含まずに関数情報及びその関数が必要とする引数により構成された変動ファイルを作成させる変動ファイル作成手順と、
   前記出力装置の機種に依存せずに複数の機種で共通して使用できる非機種依存情報が制御コードを含んで構成された固定ファイル、及び前記変動ファイル作成手順で作成した変動ファイルを用いて、前記出力装置に前記ベースファイルの内容に応じた情報を出力させる出力手順と
   を実行させるための電子機器用プログラム。
2. 請求項１に記載の電子機器用プログラムにおいて、
   前記変動ファイル作成手順では、
   前記関数情報及びその関数が必要とする引数を構造体にまとめて変動ファイルを作成することを特徴とする電子機器用プログラム。
3. 請求項１又は２に記載の電子機器用プログラムにおいて、
   前記変動ファイル作成手順では、
   親構造体及び子構造体を生成し、
   複数の前記関数情報及び前記子構造体の参照先アドレスを前記親構造体にまとめ、前記親構造体にまとめた各関数が必要とする引数を前記子構造体にまとめることを特徴とする電子機器用プログラム。
4. 所定の記述言語で記述されたベースファイルから、表示処理に必要な情報を読み出して、前記ベースファイルの内容に応じた情報を表示する表示手段と、
   出力処理に必要な情報であって機種に依存して複数の機種で共通して使用できない機種依存情報を前記ベースファイルから読み出し、読み出した前記機種依存情報から制御コードを含まずに関数情報及びその関数が必要とする引数により構成された変動ファイルを作成する変動ファイル作成手段と、
   機種に依存せずに複数の機種で共通して使用できる非機種依存情報が制御コードを含んで構成された固定ファイル、及び前記変動ファイル作成手段が作成した変動ファイルを用いて、前記ベースファイルの内容に応じた情報を出力する出力手段と
   を備えることを特徴とする電子機器システム。