アーキテクチャ

とっぷぺーじ

システム構成 †

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

1. リソース情報の分離
2. 多機能カラム情報
3. 画面／機能のモジュール化
4. 汎用オブジェクトによる拡張性

リソース情報の分離 †

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

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

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

多機能カラム情報 †

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

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

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

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

画面／機能のモジュール化 †

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

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

汎用オブジェクトによる拡張性 †

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

データフロー（検索系） †

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