@DBFlute, Java, ReplaceSchema, WEB+DB Press "WEB+DB Press vol.55" の見本誌が届き、いつものように 読ませて頂いているのですが...なんといっても "特集１"。 うぉっ、"DBFluteのReplaceSchema" が紹介されてる！？ "設計と実装に活かす技術" ということで、およそDBFlute は出る幕も無いなぁと思いきや、素晴らしい展開で紹介して 頂いています。(筆者の方、ありがとうございます！) で、一番真っ先に思ったのが： "あっ、サイトにReplaceSchemaのドキュメントがない！" ドキュメントリニューアルのマイルストーン http://d.hatena.ne.jp/jflute/20100219/1266545175 にて、書かせて頂きましたが、リニューアル後は 完全なReplaceSchemaのドキュメントが公開される予定です。 でも、WEB+DB Press vol.55発売までには間に合わないぞ！ ということで、ReplaceSchemaに関する情報を取り急ぎ ここでまとめてみました。
"現場ソリューション2 DBFlute (PDF)" "DDL＆データ" というカテゴリでReplaceSchemaに関する 記事があります。紹介記事ではありますが、今、存在する中で 一番良いと思われるドキュメントです。 データ登録時のデフォルト値設定やシート名30文字問題の設定など のファイル名が "xxx.txt" 形式から "xxxMap.dataprop" に変わっていることだけ注意です。(でも古い形式でも動きます) ex) デフォルト値設定 default-value.txt ==> defaultValueMap.dataprop
"DBFluteのタスク全体図" タスク全体図と言いつつ、ReplaceSchemaに関する 補足説明がごついです。
あと、Blogでの紹介記事。 特殊な機能とかは、ここでしか書いてないこともあります。 "DBFlute: ReplaceSchemaの思想" "ReplaceSchemaの紹介・おさらい" "ReplaceSchemaの最後にシーケンス調整" "シーケンス調整のシーケンス増分値の想定" "ReplaceSchemaでDBユーザも作る" "ReplaceSchemaのチェック機能" "take-finallyのAssertを環境毎に切り替え" "take-finallyでのAssertで「存在すること」も" "ReplaceSchemaでBatchUpdateしないモード" "OracleのSequenceを自動Drop" "空文字データを登録できるように" "DBFlute: データエクセルのテンプレート" "DBFlute: ReplaceSchemaで埋め込み変数" "HibernateプロジェクトでもDBFlute" "ReplaceSchemaがWindows Azureで" "ReplaceSchemaでDBユーザも作る" は、最近の機能ですが、 とても便利ですね(自分で実感)。ユーザ作成・権限設定周りが 本当にバッチでできちゃうので設定さえできちゃば本当に楽です。 dbflute-oracle-example、dbflute-mysql-example にて実際に利用しています。
実は、新ドキュメントのReplaceSchemaの記事は おおよそは書き終わっています。サイト全体ができて ないので、まだ公開できていないだけなのです。 "新ドキュメント(推敲中)のReplaceSchema" まだデザインも仮のもの、レビューも終わってませんが、 がっつり理解するのであれば、こちらを見てもらっても 良いかと思います。 dfwww-factoryプロジェクトを(SVN)チェックアウトして、 ローカルファイルとしてブラウザで見れば仮のデザインが 適用されて、直接上記のリンクで見るよりは見やすいです。
ちなみに、このWEB+DB Pressの特集１の記事、 とても共感の持てる勉強になる良い記事でした。 たくさんあるのですが、その中で幾つかの言葉を ピックアップして、jfluteの感想を： ＜１＞ "ユーザは実物を見て初めて次の要求が出せる" 全くその通りで、ユーザに限らず人間そうですよね。 想像力にも限界があって(個人差もあるし)、 普段別のこと(業務)をやってる最中で、システムの 要件を出し切るのはそもそも難しい、それを踏まえた 上でそれをフォローする仕組みを作っていかないと。 ちなみに今やってるDBFluteのドキュメントリニューアル でまさに実感です。どのようなデザインにするか？ 最初から全部の細かい要件はなかなか出て来ないものです。 段階的にWEBデザイナに伝えて、一旦ある程度できたもの を見て、そこからまた思いついたものを伝えて、を繰り返し、 というやり方でスムーズに進んでいます。 ＜２＞ "(可能であれば)設計者が実装車に説明した仕様をもとに、 実装者自身に詳細化を行ってもらい、それを設計者が レビューするという方法" 詳細設計の話ですが、自分は幾つかのプロジェクトで これを実践したのを経験しました。 (自分が主導したプロジェクトでも導入) 詳細設計の全てというわけではありませんが、 少なくとも実装者には "処理概要フロー" に相当する "コミュニケーション図" を書いてもらいました。 これは必ず実装前に書いてもらいます(これ大事)。 それを設計者とレビューし、意識の乖離がある場合は、 その場で修正します。クラス図やシーケンス図は、 そういう役割としてはあまり向いていないと考えています。 ある一方の視点からの "非常に正確な" 構造もしくは動き を表現できるのですが、それを書くのはそれこそ時間がかかり ますし、設計者はそれを見てもあまりピンと来ません。 それよりも、構造(依存関係とか)と動きの両方を "漠然と" 表現できる "コミュニケーション図" の方が向いていると。 まさに設計者と実装者のコミュニケーションをつなぐもの。 また、設計者だけとなく隣接する機能を実装する他の 実装者(+1人、2人)もレビューに加わります。 それは、最後のコラムで書かれている "共に仕様を把握 している実装メンバーで助け合う..." につながります。 実際にやったプロジェクトでは、本当に複雑な画面において のみ、クラス図やシーケンス図を作成し、それ以外は全て コミュニケーション図だけで開発を進めて行きました。 (もちろん、画面定義書は別にちゃんとありますよ) 結果、レビューはとてもスムーズにでき、意識のズレと いうのはほとんどなく、リリース後のメンテナンスでも そのコミュニケーション図が新加入のメンバーの 現状把握の一番の良い入り口となりました。 メインの図をコミュニケーション図に絞ることで、 図のメンテも皆嫌がること無くしっかり同期されました。 などなど、 他にもとても興味深い内容が記事に書かれています。 ぜひ興味ある人は読んでみて下さい。
