『openGion』の哲学

『openGion』を使って、Ｗｅｂアプリケーションを構築する場合に 重要になるのが、『openGion』の哲学です。

『openGion』は、元々ＰＤＭシステムのＷｅｂアプリケーションフレームワーク として、構築しましたが、現在では、Ｗｅｂアプリケーション全般に適用する方向で、 開発が続けられています。

特に、社内業務システムでは、業務効率を優先的に考えます。これは、過剰な 装飾や必要以上の多機能化は、必要ないということです。 逆に、日々、使用するため、操作性は重要視されます。また、システム開発自身も 効率的でなければなりませんし、カスタマイズ性は、強く求められます。

実は、もっと深刻な問題があります。それは、開発者のスキルの確保です。 高度な技術が求められる開発ツールを利用すると、そのための教育に時間が かかったり成果物の品質が低下します。社内システムの開発に、高度な技術を 利用する必要はありません。必要なときに、必要な技術を用いるだけです。

『openGion』の特長を挙げるとすれば、以下の３つに集約できます。

（１）．短納期指向
（２）．効果的な開発
（３）．RDBMSが中心

（１）短納期指向
	短納期指向とは、開発の初めから実稼動までのリードタイムの短縮を目指すというものです。
	エクストリーム・プログラミング (XP) などのアジャイルな方法論が注目を集めていますが、
	考え方としましては、TOC(Theory of Constraints：制約条件理論）によるシステム開発の
	変革による、スループット向上を中心に、ＸＰ的な考え方を取り込んでいます。

（２）効果的な開発
	効果的な開発とは、『効率の追求から効果の追求』に考え方をシフトし、
	『今、必要な機能のみを実装する』という開発手法です。
	『効率の追求から効果の追求』では、設計ｰ開発ｰ顧客の分業による一律開発から脱却し、
	設計ｰ開発ｰ顧客が一体となって効果を追求することにより、顧客満足度を向上させる狙いがあります。

	

	現在のシステム開発手法では、システム設計時に｢将来に対する投資｣と称して、
	不要な設計や機能を組み込んでいます。
	技術進歩が早く、業務方法や市場環境の変化が激しい現代では、将来使われるかどうか
	判らない機能は大きなリスクであり、キャッシュフローや、スループットの観点からも、
	好ましいものではありません。 『今、必要な機能のみを実装する』事が非常に重要です。

	

（３）ＲＤＢＭＳが中心
	この中で、３番目のRDBMSが中心 というキーワードが、最もこのエンジンを特徴付けている
	のかもしれません。
	現在のWebアプリケーションの中心はJ2EEです。ＥＪＢだ、ＭＶＣだと騒がしのですが、
	RDBMSで扱う表形式というのは、人が最も理解しやすい形式であり、かつ、非常に強力で
	柔軟だと思います。
	これを最大限活用する為、RDBMS中心の設計としました。

	

システムを構成する４つのロジック（業務ロジックＡ，Ｂ，リソース， エンジン）は、 下記方針を実現する為に、最適に配置されています。

（１）．リソース情報の分離
（２）．多機能カラム情報
（３）．画面／機能のモジュール化
（４）．汎用オブジェクトによる拡張性

（１）リソース情報の分離
	ラベル、メッセージなどの国際化対応の項目や、カラム定義、画面定義、ユーザー定義、
	システム定義など、定義情報をリソースとして画面開発と分離しています。

	これにより、基本設計時にデータベース定義情報を利用して基本的な画面を短期間で
	作成することが可能です。しかも、全画面において基本情報はすべて考慮されている
	状態になります。（『短納期志向』）

	その後、必要な画面を必要なだけ、機能アップしていけば、『効果的な開発』が、可能になります。

（２）多機能カラム情報
	データベースのカラム名をオブジェクト化し、多機能情報を与えることにより、 
	select文を記述する（『業務ロジックＡ』 ）だけで、基本的な画面を作成することが出来ます。

	カラム情報は、先のリソース情報で与える為、画面設計時には、詳細指示を出す必要が
	ありません。また、開発途中で、機能強化を行う場合も、リソース情報を書き換えるだけで、
	全画面に対してその機能を有効にする事が可能になります。

	簡易的なカラムチェックは、多機能カラム情報を利用している為、業務ロジックＡやＢには、
	本流の流れのみを記述できます。

	多機能カラム情報は、ＳＱＬ文（SELECT PN,CDK,NM FROM RK08 ) や、ColumnTag の
	name属性の『CDK』 というカラム名より、カラム情報が自動的に集められて、
	多機能カラムオブジェクトを構築します。

	

（３）画面／機能のモジュール化
	画面（『業務ロジックＡ』）は、画面ＩＤと、実フォルダが仮想的に対応しています。
	そのため、フォルダ毎に画面を開発していくことで、フォルダのコピーによる機能追加や、
	他の画面を修正せずに、顧客対応のカスタマイズが可能になります。

	また、画面系のロジック（『業務ロジックＡ』）と、業務系のロジック（『業務ロジックＢ』）
	も分かれているため、各々の機能をモジュール化しておくことで、カスタマイズが容易になり、
	基幹業務を流用することが可能になります。

（４） 汎用オブジェクトによる拡張性
	Ｗｅｂエンジンは、汎用オブジェクトインターフェース（ Query、View、DBTableModel、
	Renderer、Editor、DBType など）を用いて開発しています。そのため、各インターフェースを
	継承したサブクラスを作成するだけで、容易に新機能を実装することが可能です。

	

検索系のデータフロー例を示します。