e Builder Application Producer v7.2での開発方法について

本日、「intra-mart e Builder Application Producer (以下 Application Producer と略記)」をリリースさせて頂きました。Application Producerは、Ver7.1からご提供させて頂いておりましたが、今回のVerUPにて、「モックアップページ作成機能」と「データモデル」に関する機能追加により、システム開発における一連の流れにおいて、Application Producerを利用出来るようになりましたので、以下、改めて、ご紹介させて頂きます。

e Builder Application Producerとは？

Application Producerは、「設計情報を製造で『最大限』に活用し、システム開発を効率化するツール」です。

以下の特長があります。

• 各種「デザイナ・エディタ」を利用したシステム設計機能
• システム設計情報からソースコードを生成する機能
• 各種設計書出力機能

開発プロセスへの適用イメージ

以下のイメージは、開発プロセス(要件定義、設計、製造、テスト)の中で Application Producer を導入した場合のサポートするタスクを表現したイメージです。

サポートするタスクは、以下となります。

•  画面定義・設計・製造
  • 画面遷移定義
  • 画面レイアウト設計
  • モックアップページ作成
  • 画面イベント定義
  • 画面入出力詳細定義
  • 画面イベント定義
  • 画面入出力詳細定義
•  処理定義設計製造
  • 画面イベント処理定義
  • バッチ処理定義
  • Webサービス処理定義
  • 処理フロー設計
  • ファンクション設計
  • ファンクション実装
•  DB設計、DAO設計・製造
  • データ項目定義 ※データディクショナリ作成
  • エンティティ定義
  • DAO設計・SQL定義
• バッチ定義
• Webサービス定義

使い方

Application Producer は、開発プロセスのさまざまな場面で使えるように設計されています。

【画面】 「モックアップページ作成機能」、それは「画面開発機能」でもある

 

「完全なデータ」を用いた「モックアップページ」を作成することで、 システムの実現イメージがより正確に表現でき、画面仕様をFIXしやすくなります。 しかし、設計工程で「モックアップページ」を作成し、製造工程で「画面プログラム(JSP)」を作成するのは手間です。
Application Producer では、 モックアップページの作成をHTMLベースに『無駄なく』行なうことができます。「TemplateHTML」というHTMLの拡張タグを利用します。 画面レイアウトはHTMLベースに行い、動的に値を埋め込みたい場合はバインド変数(例： ${userCd} )を配置します。 そのバインド変数に対してモックアップデータを外部から設定し、モックアップページを自動生成することができます。 

そして、ここで作成する「TemplateHTML」がそのまま画面のプログラム(JSP)として生成することができます。 つまり１つのソースファイル「TemplateHTML」からモックアップページと画面プログラム(JSP)を生成します。

また「マスカット (Ajax リッチクライアントアプリケーションの開発を支援するためのフレームワークおよび統合開発環境)」 においても、応答電文にモックアップデータを設定することで、マスカットのモックアップページを作成することができます。 マスカットのようにAjaxを伴った画面を開発する場合、サーバサイドのコントローラが必要になりますが、モックアップデータを利用することで、コントローラが生成され、モックアップデータを利用した「マスカットの画面開発」が行なえます。 

開発プロセスの中で「画面仕様」を設計工程の早い段階でFIXすることは非常に重要です。 なぜなら、「画面仕様」がFIXできないと「処理の設計」が行なえません。 また後の工程で画面仕様を変更する必要が発生した場合、処理も変更する必要が発生し、影響範囲は大きくなります。 手戻りをできる限り少なくするためにも、設計工程の早い段階で画面仕様をFIXすることが重要です。

【データモデル】 データディクショナリを利用した「DB設計」 と SQLから開発する「DAO」

 

「データディクショナリ」とは、データ項目の辞書である。たとえば、データ項目 userCd に対して、 論理名が「ユーザコード」で、カラム名が「USER_CD」で、カラムデータ型が「VARCHAR」でサイズが「50」などと定義できます。
データディクショナリでデータ項目を「一元管理」することで、DBのテーブルを設計で複数のテーブルに対して同じデータ項目を配置する場合に、各カラムで定義の整合性が崩れない。また一括で変更できます。
さらに、「DBデザイナ」でテーブル設計を行なうと、各テーブルに対して以下の「基本DAO」が自動生成されます。

• 全件取得DAO
• 主キー条件による１件取得DAO
• 登録DAO
• 主キー条件による１件更新DAO
• 全件削除DAO
• 主キー条件による１件削除DAO

※DAOとは、データにアクセスするためのオブジェクトである。
※基本DAOは編集することができない。

これ以外のDAOは開発する必要があります。 Application Producer でのDAOの開発は、以下の『３ステップ』でSQLベースに開発を行ないます。

1. SQLタイプ(SELECT/INSERT/UPDATE/DELETE)の選択
2. SQLの作成とSQLテスト
3. DAOのインターフェースの設定

ステップ3では、DAOの基本となるインターフェースを設定します。その基本となるインターフェース情報は、作成したSQLを解析して自動で作成されます。 自動作成されたインターフェースに対して、変数名を選択するなどの設定を行います。
インターフェースの設定が完了すると、DAOのプログラムがビルダにより自動生成されます。 これにより、ファンクション(FC)からDAOを呼出すこともできます。

Application Producer で作成した DAO は、業務ロジックフロー(CTR/BIZ)の中からマッピングだけで呼出すことができます。 このとき、便利なオプションがあります。たとえば、取得用(SELECT)のDAOに対しては、利用タイプとして「全件取得」「フェッチ取得」、「件数取得」、「存在チェック」を選択できます。 つまり、「フェッチ取得」、「件数取得」、「存在チェック」用のDAOを作成する必要がなくなります。

【処理】 プログラムをデザインする「ビジネスロジックの処理フローの設計」

 

ビジネスロジックは、画面などから受け付けたリクエストに対して、手続き的に処理を実行し、処理結果を返す。
Application Producer では、このビジネスロジックの処理フローをCTRエディタで設計する。 CTRエディタでは、DAOやファンクション(FC)をどのような順番で呼出すかを定義する。 そして、この定義からビジネスロジックのコードを自動生成できる仕組みになっています。

Application Producer におけるファンクション(FC)とは、ある入力に対して何かの値を出力することが定義された「インターフェース」です。 ファンクション(FC)はビジネスロジックの処理フローの中で利用し、その中身は Java で実装することになります。 ファンクション(FC)のインターフェース定義は、設計と実装を繋ぐ大事なポイントにあります。 また、ファンクション(FC)の処理内容の「粒度」がポイントです。 複数のビジネスロジックから共通利用できるようにファンクション(FC)を設計することが、設計者の「腕の見せ所」でもあります！

【マッピング】 データ(Model)、画面(View)、処理(Controller) をマッピングしてソースコード生成

Application Producer のアーキテクチャは、データを加工して画面に表示するようなアプリケーション開発における技法「Model View Controller (MVC)」の考え方がベースになっています。

Application Producer では、基本的には以下の手順でアプリケーションを開発します。

1. ３つのコンポーネント「データ(Model)」、「画面(View)」、「処理(Controller)」を作成
2. 各コンポーネントを組み合わせる ( ＝マッピング)
3. ソースコード生成、設計書出力

このように、「データ(Model)」、「画面(View)」、「処理(Controller)」の３つのコンポーネントに分かれていることで、 画面(View)だけを取り替えて画面をリニューアルしたり、他システムに連携するために処理(Controller)をカスタマイズするといったことが柔軟に行ないやすくなります。

出力できる設計書の一覧

出力できる設計書の種類は１８種類です。設計書の出力時に、出力形式を Word/PDF/HTML から選択することができます。