top / index / prev / next / target / source

2005-06-16 diary: 「ロケーションID」という概念の定義

いがぴょんの日記 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

「ロケーションID」という概念の定義

ソースコード上および物理設計書上の特定の位置を表す「ロケーションID」という概念が必要なのではないかと考えました。 , Ajax実装のひとつである 楽々Frameworkというパッケージソフト。

ソースコード上の特定の位置を示す 「ロケーションID」 という概念

ソースコード上の特定の位置を示すために「ロケーションID」という概念を導入する価値がある場面に巡り会いました。

比較的規模の大きいシステムでは、位置を示すために ログIDまたは画面メッセージIDを一意に保つようにルール決めを行い、それらIDを元にソースコード上の位置と物理設計書の位置とを一意に表すことがあります。ところが、ログIDにしても画面メッセージIDにしても、一意になるようにすると別の制約が発生してなかなか うまく回りません。

そこで考えられるのが「ロケーションID」という概念です。何かある法則に則ったコード体系をもって 位置を表現するための一意なコードである「ロケーションID」を導入すれば、ソースコード上の位置と物理設計書の位置とを一意に表すことができます。

そういう概念が既出のものかどうかについては、私は知りません。

ここで、Java言語などではリファクタリングなどが行われることがあるので、ファイル名やクラス名とは一線を画しておく必要があります。あくまでもいわゆるコード体系に沿ってコードを定義します。もしシステムの大きな意味でのコード体系について、Java言語などにおいてパッケージ構成と関連づけが行われていたら、パッケージ構成とロケーションIDとは関連が出てくるものと考えます。

このロケーションIDには、画面メッセージIDやログIDを関連づけることができます。ロケーションIDをもとに 画面メッセージIDやログIDの引き当てができるようにしておきます。(ひも付く画面メッセージIDやログIDが存在しない場合には空欄にしておく)

また、このようなロケーションIDが導入できれば、物理設計書とソースコードとの乖離をチェックするためのドキュメントコンパイラ・ツール (blanco Frameworkとして構想が存在) の作成が容易になる (あるいは設定について自明になる) ものと考えられます。

2005.06.17追記 ロケール対応についてメモを取っておきます。ロケーションIDを導入したとして、引き当てられる画面メッセージについてはロケール(Locale)対応しておくようにします。というのも、画面メッセージはロケール対応を行うことによって各国語による画面表示対応を行う必要があるからです。一方システム保守を行う人が閲覧するであろうログメッセージについては、ロケール対応は必要なく 単に固定のロケールで動作して良いのです。

Ajax実装のひとつである 楽々Frameworkというパッケージソフト

Ajaxをちょっとずつ勉強していったら、どうやら 以前見て その操作性のスマートさに衝撃を受けた 楽々Frameworkという Javaアプリケーション開発環境が Ajax実装のひとつであるのだ ということに気がつきました。

Webブラウザだけを用いてリッチな操作環境を得るための手段のひとつとして Ajaxがあります。現時点で Ajaxを導入するには JavaScriptのプログラミングを伴う場合が多いものと考えます。ところが、楽々Frameworkを用いれば、Java言語を用いてリッチな操作環境を Webブラウザのみで実現という組み合わせが、JavaScriptのコーディングを伴わないで すぐに導入できるように感じました。(ただし 私は別に楽々Frameworkを用いた実開発の経験があるわけではありません。あくまでも そのように感じたにすぎません。)

この日記について