いうことで、およそDBFluteは出る幕も無いなぁと思いきや、素晴らしい展開で紹介して頂いています。(筆者の方、ありがとうございます!)で、一番真っ先に思ったのが:"あっ、サイトにReplaceSchemaのドキュメントがない!"ドキュメントリニューアルのマイルストーンhttp://d.hatena.ne.jp/jflute/20100219/1266545175にて、書かせて頂きましたが、リニューアル後は完全なReplaceSchemaのドキュメントが公開される予定です。vol.55発売までには間に合わないぞ!ということで、ReplaceSchemaに関する情報を取り急ぎここでまとめてみました。いうカテゴリでReplaceSchemaに関する記事があります。紹介記事ではありますが、今、存在する中で一番良いと思われるドキュメントです。"xxxMap.dataprop"に変わっていることだけ注意です。defaultValueMap.dataprop"DBFluteのタスク全体図"タスク全体図と言いつつ、ReplaceSchemaに関する補足説明がごついです。あと、Blogでの紹介記事。特殊な機能とかは、ここでしか書いてないこともあります。最近の機能ですが、とても便利ですね(自分で実感)。ユーザ作成・権限設定周りが本当にバッチでできちゃうので設定さえできちゃば本当に楽です。dbflute-oracle-example、dbflute-mysql-exampleにて実際に利用しています。実は、新ドキュメントのReplaceSchemaの記事はおおよそは書き終わっています。サイト全体ができてないので、まだ公開できていないだけなのです。"新ドキュメント(推敲中)のReplaceSchema"まだデザインも仮のもの、レビューも終わってませんが、がっつり理解するのであれば、こちらを見てもらっても良いかと思います。dfwww-factoryプロジェクトを(SVN)チェックアウトして、ローカルファイルとしてブラウザで見れば仮のデザインが適用されて、直接上記のリンクで見るよりは見やすいです。Pressの特集1の記事、とても共感の持てる勉強になる良い記事でした。あるのですが、その中で幾つかの言葉をピックアップして、jfluteの感想を:<1>"ユーザは実物を見て初めて次の要求が出せる"全くその通りで、ユーザに限らず人間そうですよね。普段別のこと(業務)をやってる最中で、システムの要件を出し切るのはそもそも難しい、それを踏まえた上でそれをフォローする仕組みを作っていかないと。ちなみに今やってるDBFluteのドキュメントリニューアルでまさに実感です。どのようなデザインにするか?最初から全部の細かい要件はなかなか出て来ないものです。段階的にWEBデザイナに伝えて、一旦ある程度できたものを見て、そこからまた思いついたものを伝えて、を繰り返し、というやり方でスムーズに進んでいます。実装者自身に詳細化を行ってもらい、それを設計者がレビューするという方法"詳細設計の話ですが、自分は幾つかのプロジェクトでこれを実践したのを経験しました。これは必ず実装前に書いてもらいます(これ大事)。それを設計者とレビューし、意識の乖離がある場合は、その場で修正します。クラス図やシーケンス図は、そういう役割としてはあまり向いていないと考えています。構造もしくは動きを表現できるのですが、それを書くのはそれこそ時間がかかりますし、設計者はそれを見てもあまりピンと来ません。設計者と実装者のコミュニケーションをつなぐもの。設計者だけとなく隣接する機能を実装する他の実装者(+1人、2人)もレビューに加わります。実際にやったプロジェクトでは、本当に複雑な画面においてのみ、クラス図やシーケンス図を作成し、それ以外は全てコミュニケーション図だけで開発を進めて行きました。(もちろん、画面定義書は別にちゃんとありますよ)結果、レビューはとてもスムーズにでき、意識のズレというのはほとんどなく、リリース後のメンテナンスでもそのコミュニケーション図が新加入のメンバーの現状把握の一番の良い入り口となりました。図のメンテも皆嫌がること無くしっかり同期されました。他にもとても興味深い内容が記事に書かれています。興味ある人は読んでみて下さい。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。