さった7月18日に超高速開発コミュニティ主催第7回セミナー「上流工程ツールとの連携事例報告」で、JBグループが提供する XupperII が出力した成果物を、3つの自動生成ツールで取り込むという実証実験の報告会がありました。
http://www.x-rad.jp/seminar201407/
Wagbyの事例発表は私の方で行いましたので、ブログで報告します。
XupperII からの出力
実験に協力した3社に、次の6つのCSVファイルが提供されました。
| ファイル名 | 概要 | 例 |
| Entity.csv | エンティティの定義 | 受注,JUCHU |
| EntityEntry.csv | 各エンティティのフィールドの定義 | 受注,JUCHU,受注番号,JUCHU_NO,K |
| Field.csv | フィールドの詳細 | 受注番号,NBR,7,受注データを特定するための識別子 |
| Domain.csv | 型に関する情報 | 電話番号,テキストタイプのドメイン,TXT,10 |
| DeviceEntity.csv | 画面設計情報 | 受注入力,B,受注番号,I |
| Condition.csv | 選択肢 | 定期発注,VAL,1,定量発注,VAL,2 |
# 上記で示した例は抜粋です。実際にはもっと多くの規則が含まれていましたが、ここでは割愛します。
各社とも独自の方法でこのファイルを読み込み、自社の自動生成エンジンで解釈させます。
各社のアプローチ
私たち（Wagby）は、上記ファイルを読み込み、Wagbyの設計情報形式（リポジトリ）に変換するプログラムを作成しました。Wagbyのリポジトリはプレーンテキストで内部は key-value ペアです。例えば次のようなものです。
model/modelitem/@label=受注番号
model/modelitem/@name=JUCHU_NO
model/modelitem/@primaryKey=○
つまり "CSVファイル to Key-Valueファイル" への変換プログラムです。Javaを使った（よくある）コマンドラインプログラムとして実装しました。
一方、エス・エー・エフ・データさんはすでにツール内で設計情報(CSV)取り込み機能があるとのことで、そちらを使っていました。ただし読み込めたのは一部のファイルです。残りの情報は自社ツールで手動設定というアプローチでした。
そしてウイングさんはGeneXusの開発ツールを拡張し、CSVファイルが取り込めるようにしていました。ただし画面設計情報は除かれていました。GeneXusは標準で、エンティティ同士のリレーションは「名前が同じならリレーション関係にあるとみなす」というルールが備わっていました。さらにそのルールで対応できない場合には、別途外部からリレーション情報を与える仕組みもあるとのことです。エンティティやフィールドの名前の一致性でリレーションを設定するというのは有効なアイデアというのは理解しますが、設計の自由度が下がることを懸念したためWagbyでは採用しませんでした。ただプログラミングの世界でも名前によって挙動を意味付けするフレームワークは存在するため、馴れてしまえば問題ないと思います。
実験の成果
XupperIIの設計情報を取り込んだところです。WagbyDesignerという開発ツールが解釈できています。
この設計情報にまったく手を加えず、そのままビルドした受注入力画面です。XupperIIで記述された自由文章はヘルプメッセージとして活用するなど工夫しています。
見えてきた課題
設計情報という定義そのものに統一スタイルが存在しない
以前から課題として認識していましたが、この業界には設計書の統一フォーマットが存在しません。
XupperII では、一般的な文字列、数値、日付に加えてパーセントや金額といった「型」が存在しました。それは便利なのですが、XupperII だから持っている、と考えることもできます。今回はこのような情報もできるだけ取り込むようにしました。
また「選択肢」について、Wagbyでは "コード=値" という表現ですが、XupperIIには「コードの範囲」という概念がありました。これはWagbyでは取り込めなかったものです。一方で、Wagbyには「コードの有効期限」がありますが、これはXupperIIでは自由文章として表現するしかありませんでした。
エンティティと画面設計の扱い
XupperIIではエンティティには含めないが、画面には表示または入力する項目を定義できます。しかしWagbyではいずれも「モデル」で表現します。具体的にはEntity.csv,EntityEntiry.csv,DeviceEntry.csvを一つにまとめる作業です。この処理の過程で独自に解釈した箇所がいくつもあったため、発表ではその解釈の妥当性について会場から意見を求めるようにしました。一方、他2社は画面設計情報を読み込まず、自社ツールで再設定というアプローチでした。
自由記述や計算式の扱い
XupperIIでの自由記述は、もちろんWagbyでは取り込めません。例を挙げると次のようなものです。
- "自動採番の登録時のみ前回採番した伝票Noを表示それ以外は...。"
- "当日日付よりも過去であること。"
これらはプログラミング言語や式で表現するという案もありますが、上流設計ツールで式を記述するということは、文法チェックまで行うというこになります。それはツールの範疇を超えるかも知れません。
相互変換の問題
今回はXupperIIの設計情報を取り込む、ということだけに注力しましたが、取り込んだあとに Wagby で設計情報を変更するという作業は（当然）ありえます。するとリバースはできるのか、という点も重要になります。今回は実験の対象外でしたが、実運用ではこの点も何らかの手法を提供することが求められます。
まとめ
エンタープライズアプリケーションで共通の概念であるER図および、入出力に関わる諸情報が入手可能な環境があれば、Wagbyのリポジトリへ変換することができることを具体的に示すことができました。既存システムの情報からWagbyのリポジトリの叩き台を生成し、これをベースに詳細な定義を加えていく、という開発は有効と実感しました。
Wagbyはデータ辞書という概念をまだ持っていないため、XupperIIの辞書情報の活用には興味がありました。実際、さまざまな情報を取り込むことができたのですが、一方で自由文章についてはヘルプメッセージとしての活用程度であり、ロジックに反映させることは困難でした。
そして本実験でえられた最大の知見は、ツール to ツールで設計情報を再利用する際、読み込む側のツールの特性を活かそうとするほど元の設計情報から独自の解釈（判断）を行う余地があるということす。これを是とするか、それとも厳密なルールを規定するかは今後の課題です。厳密性を追うと、UML が目指した MDA の世界が一つの解です。ただし現時点では（厳密すぎるルールは）普及が難しいという状況です。
個人的には、統一的な設計情報には何を含めるべきか、という議論を本格的に行ってもよいと考えています。私が知らないだけで、すでにそのようなコミュニティや学会があるのかも知れません。ただ超高速開発コミュニティの優位性は、実際にビジネスの現場で使われているツールが揃っているということです。今後、各ツールが意識して相互運用の可能性を探っていくことになればコミュニティ活動の大きな成果になる、と考えています。
今後のコミュニティ活動への期待
このコミュニティが発足してまだ1年たっていないところですが、このような実験ができるようになるまで、各社の風通しは良くなってきました。これは私にとっての大きな成果です。
また、コミュニティ発足の当初から「単なる営業アピールの場にとどめない」ことを掲げてきましたので、こういう実証実験は望むところです。今回のセミナー参加者からも、実験で課題が浮き彫りになったことは、何をやるべきかが明確になるので良かったという評価の声をいただきました。
今後はさらなる相互運用実験や、分科会での継続的な議論につなげていきたいと思います。
