■ 開発の動機

現在、企業内の情報システムはWebを中心とした多層のシステムとして開発されることがほとんどではないでしょうか。私たちも何度かこうしたシステムを開発してきました。ところが、以前に比べて開発期間はだんだん短くなってきているのにもかかわらず、仕様変更は頻繁に起きています。私たちソフトウェア開発者はそのたびごとにビジネスロジック、GUI画面の変更など何度も似たような作業を強いられてきました。

データモデル自体が複雑化している、時代の変化が速いこと等から、こうしたことはある程度は仕方のないことかもしれません。しかし、もっと仕様変更に柔軟に対応できるシステムを作れないものでしょうか？　私たちの出発点はここにありました。

なぜ、柔軟に対応できないのか？

この問題を考えているときに、その原因がRDBにあるという結論に至ったのです。

RDBは言うまでもなく、現在の情報システムでは欠くことのできないプレイヤーです。開発者にしてみれば、ほとんどOSと同格と言ってもいいかもしれません。トランザクションや排他制御、マルチスレッドへの対応などRDBでなければならない状況はたくさんあります。

RDBではまずスキーマありきです。そのスキーマにしたがってシステムは作られていきます。しかし、データモデル（一連のスキーマ）に変更があれば、その影響は各層におよびます。そのため、保守・変更作業が大変になります。しかも、各層の開発担当が別で連絡が面倒だとか、あるいは担当者が辞めてしまったとなると...　皆さんには、こんなため息が出そうな経験ありませんか？

データモデルの変更は避けられません。これに柔軟に対応するには、

• データモデルに変更があっても、システムの変更を局所化できること
• RDBの担当ではなくてもデータモデルの変更が容易にできること

Xoneはフレームワークの一種ですが、他のフレームワークと異なるのはRDBをラップしているることです。このため、

• JDBCやSQLを知らなくても開発できる
• データモデルを容易に作成できる
• データモデルの変更への対応を局所化できる

という大きな特徴があります。「そんなうまい話が...」と言う前に、ぜひ実際に試してみてください。システム開発も、その保守作業も？倍ぐらいスピードアップするかもしれません（？にはお使いになってから、ご自身で数字を入れてください^^;）。

なお、XoneのデータモデルについてはXoneメタモデルを参照してください。また、データモデルの定義例については制約式と検索条件式を参照してください。

（当社ではXoneを使ったシステム開発やコンサルティングも行っています。お問い合わせは info@fiverworks.com にお願いします。）