どんなシステム開発でも、設計方針を決めずに進めると、開発の質が低下しがちです。設計方針は、使うプログラミング言語などに依存し、適した方針を決めなければなりません。

Titanium Desktopによる開発では、HTML、JavaScript、ブラウザが基本となります。また、これらを含めた形の独立動作アプリとしてもビルドできます。今回は、ターゲット環境がMac限定なので、Mac用の独立動作アプリとしてビルドすることに決めました。ブラウザのバージョンアップに依存しないほうが、システムとして安定するだろうとの判断です。

続いて、システム全体の構成を考えます。将来的にはブラウザで動作させる可能性もありますから、ブラウザ上で動かすことも考慮します。ブラウザで一番心配なのは、動作の安定性です。途中で異常終了したために、せっかく入力したデータを失ったら、業務が大変な状態に陥ります。

そこで最大の設計方針は、「途中で異常終了しても、できるだけデータを失わない構造にすること」としました。具体的には、入力したデータは、すぐにファイルへ書き込むこと。ただし、書き込む途中で異常終了すると、ファイルごと失う可能性もあります。ファイルへの追加書き込みはせず、前のファイルをコピーしてから、新しいデータを追加する方式とします。せっかくなので、前のファイルも数世代ほど保存することにしましょう。

このような方法で設計すると、新しいデータの書き込み中に異常終了しても、新しいデータ１件を失うだけで、過去に入力したデータは失いません。異常終了により、データが正しく入力されていないことは分かりますから、そのデータを再入力するという判断も容易でしょう。

システムで使用する画面は、入力画面だけではありません。入力したデータをグラフ表示したり、入力データを後で変更したり、業務システム固有の設定をしたり、何個もの画面を行き来します。これらの移動で、データを受け渡しする方法も考えなければなりません。

どうせなら、画面ごとに完全に独立して動く方式が一番良いと思いました。画面ごとに独立するとは、必要なデータを画面ごとに読み込み、JavaScriptも独立させるということです。JavaScriptの共通部分はひとまとめにして、全画面で読み込めばよいでしょう。画面を独立させることで、画面間の受け渡しデータが不要になり、自由に行き来できる形に仕上がります。

こうした方法だと、画面を切り替える度に同じファイルを読み込むことになります。しかし実際は、HDDから毎回読み込まれるわけではありません。Mac OS Xの場合は、RAMの空きに読んだファイルを残しておいて、再度読み込むときに利用しています。そのため頻繁に画面を切り替えても、HDDアクセスは生じず、短い時間で切り替わることになります。

設計方針の検討は、まだ続きます。採用API、ファイルのフォーマット、画面レイアウトの標準化などです。続きは、次回に。