Java EE勉強会

議事録 / 第02回

これらのキーワードがハイライトされています：ibatis

２章 目的 †

生産性 †

  • 生産性の指標
    • 人月が多い少ないで生産性の指標とすることが一般的なのでは（単純に以前のプロジェクトと比較できないが）。クラサバ時代を10人月とすればJ2EEでは8人月くらいではないか。
    • 修正に対するコストはクラサバ時代よりJ2EEのほうが少なくてすむ。
    • ロジックの重複はなくなったがモジュールそのものの生産性が高まったとは思えない。
 
  • UIの生産性
    • JSPは力技である。しかし、UIが力技を必要とするのはメインフレーム時代から変わらないのでは。
    • 1画面あたりの生産性は上がったがユーザービリティは低下した。だが、細かい作業が増えたので全体で見れば作業量はかわらないと言える。
    • HTMLの変換ツールを使ってHTMLをJSPにすればプログラマがベタでJSPを書く必要がない。
    • DBにタグつきのHTMLを格納しておくという手段をとることがある。
 
  • デザイナとのやり取りに関して
    • JSPとStrutsを使う場合、デザイナとのやり取りが頻発するとデザイナがHTML直して、プログラマがそこにカスタムタグを埋め込んでと効率がわるい。プログラマに負担にかかる。
    • デザインのロジックが頻繁に変わる場合にやはりデザイナとの協業で大変なことがある。
    • デザイナとのやり取りが発生するのは最初だけなのでそれほど問題にならないのでは？
    • デザイナが作った画面ががらりと変更することは少ないのでは。プログラマはデザイナが作った画面に項目を追加するか、その画面を基準に他の画面をつくることになる。
 
  • 今後のUIの方向性。たとえばFlexの場合の手順
    1. UIのモックは開発者がつくる。UIのモックは基本的にはHTMLのときと同じ。デザイン的な要素は意識しない。ユーザーの要件を確定させるのが目的。
    2. 外部設計。
    3. UIモックと外部設計をデザイナに渡す。デザイナに頼むのは見栄えでなく使いやすさ。デザイナはActionScript?を書かない。書くのは画面遷移だけ。
    4. デザインが終了したら、サーバサイドのロジックと結びつける。
 
  • ロジックの生産性
    • OOでコレクションフレームワークが標準でつかえることが生産性に寄与している。ソートや検索などで苦労する必要がなくなった。
    • 業務ロジック作成の生産性は限界に達しているのではないか。
 
  • プロジェクト全体の生産性
    • JUnitなのでレグレッションを避けているプロジェクトでは生産性は頭打ちだと感じられる。
    • コードを書かない宣言的なルールベースはどうか？業務ロジックは手で書いたほうが確実なのでは。
 
  • 自動生成
    • 詳しく言及されていないががIDEのリファクタリング機能やgetter/setterの自動生成は生産性を高めているといってもいいのではないか。
    • ツールが自動生成したソースを読んだり触わったりする必要がなければいいのだが...、そうもいかないことは多い。
    • 生成されたソースをバージョン管理するかどうか。一般的にはDDをバージョン管理して生成されたソースはバージョン管理しないほうがよいとされる。だが、ビルドに時間がかかりすぎることがあるので場合による。
    • 生成したコードと人間が変更したコードのマージが問題として挙げられているが、GenerationGap?パターンをつかえば解決できるのでは。GenerationGap?パターンは一般的だ。
    • ツールへの依存の問題が挙げられているが、生成時にツールに依存するのは当然なので実行時に依存しさえしなければ問題ないのでは。だが、ツールに依存しすぎて失敗することもある。Eclipse2系と3系の違いは大きかった。
    • 業務要件は変わりやすいので業務ロジックを自動生成するのは結果がみえなくて不安。手で作ったほうが確実なのでは。業務ロジックのルール化は難しい。Userさんが書くことができるのか？ルールを書くのはJavaのコードを書くよりも難しいかも。だが、宣言的プログラミングや自動生成は今後の主流になる可能性がある。MDAはそのひとつか。注目する必要はある。
    • DDLとJavaBeans?の自動生成。ツールを使って相互を自動生成することは一般的であり役立っている。Middlegenが有名。XDocletでもできる？自前で作ることも多い。
    • DAO生成。HibernateではHibernate Synchronizerなど3種類あり。S2DaoではS2DaoModelGen?やS2DaoMaker?などがある。だがDAOの生成は手で書いてもそれほど手間ではない。一番最初に雛形だけつくってしまいあとは手でメンテナンスというのが使いやすいかも。S2HibernateではS2Daoのようにインタフェースだけ作ればデータアクセスできるような仕組みを現在開発中。ところでHibernateの作者の「IDEをつかわければいけないほど複雑なものはよくない」という発言はどうなったんだ？
    • XMLについて。メタデータとして使うのは一般的だが、データとしてXMLをつかうのならば自動生成は有効かもしれない。JavaとXMLのバインディングツールにはCasterやXStreamなどがある。Casterは機能が豊富だけどつかっている人が少ない。
    • ツールの話
      • Strutsベースの商用の自動生成ツールがある。拡張ポイントを提供してくれる。
      • Relaxerの自動生成は画面まで生成してくれる。
      • XDocletでEntityBean?をつくったときはGenerationGap?パターンを適用できたっけ？
      • Torqueが生成するソースは結構むごい。
      • 移行系のツールは使いづらいことが多い。WebLogic?やWebSphere?のマイグレーションツールやVBからVB.Netへの移行ツールはかなり使えない。自前のスクリプトが必要になることがある。
      • SDOについて。GUIでペタペタとデータアクセスのコードを作れる。今後どうなるのか？このようなGUIベースの開発は業務ロジックが複雑だと、まとめての変更がしにくかったり画面での開発が煩雑になったりと使いにくいのでは。WebObjects?にはEOModelerというものがある。
      • エライ人にはGUIベースの開発環境はウケがいい。GUIベースの開発環境はEnd User Computingのためのものかもしれない。だが高いのはどうよ。
    • その他。ロギングやセキュリティのトレーサビリティを保存し再現するためにXMLをつかったことがある。だが、容量の多さが問題になった。Userの操作をトレースできるフレームワークが今後登場するのでは？
 
  • 生産性を向上させるためには
    • 自動生成を使うよりも複雑さを減らす。
    • J2EEやJ2SEのAPIの複雑さを隠蔽するための抽象化とは？あまり抽象化するのも考え物。SpringJDBCは本当に簡単になっているのか？SpringJDBCよりはHibernateがいいだろう。

アーキテクチャ †

  • OSSのソリューション。
    • OSSのソリューションは今後の主流であるが、企業によってはOSSの使用を禁止しているところがある。例としては次のもの。
      • ロギングも含めてすべて禁止。
      • ロギングに関してのみはOK。
      • メインの部分への使用は禁止だが運用ツールではOK。
      • StrutsやStrutsのカスタムタグはだめだがJSTLはOK。
      • JakartaならばOK。（大手がStrutsを採用することによりJakartaに対しては安心感が出てきたという側面がある。だがプロダクトがJakartaから離れてしまうと困る。）
    • OSSを使う理由は、コストがかからないから。一方使わない理由としては、不具合があったときの責任の所在をどうするかが問題になるから。
    • 営業について。営業さんが技術的な話をどこまでするのか？ライブラリーの問題までをお客さんと話をするのか？契約書に責任範囲を明示する場合やOSSのライセンスに抵触する恐れがある場合は営業レイヤーでOSSが話題にあがることになる。OSSを使うために営業さんを説得する必要が生じる場合がある。
    • ライセンスについて。Javaの世界ではライセンスを明示しているプロダクトが多いと思われる。Perlにはライセンスが曖昧なライブラリが多いので苦労することがある（ダブルライセンスとか）。会社としてはライセンスの問題は非常に大きい。

#br

  • 社内(in-house)用ソリューションの問題点。
    • 労力の無駄である。
      • 承知の上で社内ソリューションに取り組むので改めて指摘するほどのことでもないと思われる。
    • 困難である。
      • メジャーなOSSはフィードバックを得て洗練されていく。OSSに比べれば社内ソリューションはどうしてもフィードバックが少ない。
    • 標準でない。
      • 社内用ソリューションはパートナーの開発者への教育が必要になる。だが、これはOSSのプロダクトを使用したときでも教育はある程度必要になるのでは。開発者がかならずしもOSSのドキュメントや市販の書籍に目を通すわけではないので、OSSを採用するプロジェクトを開始する前に、OSSのドキュメントとは別にそのプロダクト内独自でOSSを説明したドキュメントを用意することが多い(特に大きな規模のプロジェクトの場合)。
    • 十分なドキュメントがない。
      • 社内用ソリューションだからといってドキュメントを作らないということはないはず。また逆に、OSSだからといってドキュメントが豊富ということもないのでは。ただし、サンプルやチュートリアルについては社内ソリューションのほうが少ないだろう。OSSの場合、ドキュメントがそれほど整っていなくてもチュートリアルを紹介する人がたくさんいるので、最終的なドキュメントは豊富になると感じられる。
      • すでに作られた社内ソリューションを使う場合はドキュメントは問題にならないかもしれないが、フレームワークと業務プログラムが並行で開発される場合は、ドキュメントがないことが問題になる。
      • 社内用ソリューションのドキュメントは社外秘になるので、意欲的な開発者が社外で気軽にドキュメントを読むことができない。
    • その他。
      • 社内向けに動くことを最優先して作る場合と社外の人目を意識して作る場合では、ソースコードに若干違いが表れるかもしれない。
      • 社内向けソリューションでは設計方針に一貫性が欠けることがある。設計が人に依存してしまう。
      • 社内向けソリューションを作成する側と利用する側で温度差がある場合はフィードバックしても対応がすぐ得られず困ることがある。
      • 開発者によってはドキュメントを読まない人もいる。モチベーションを持つきっかけとして動くサンプルを用意することは効果がある。
 
  • 社内用ソリューションの利点
    • キメの細かい対応ができる。
    • OSSには取り込みにくいような少数プロジェクト限定で要求される実装も組み込みやすい。
    • OSSが成熟するまでに使える。すでに選べるOSSがあるならば当然それを採用するが、求めるOSSがないときは自前でつくるしかない。
 
  • O/Rマッピング
    • HibernateやDbUtils?が出てきた頃からO/Rマッピングのフレームワークを使うことは一般的になりつつある
    • iBatis。読み方は「アイ・バティス」でなくて「イー・バティス」。
    • Torque。Torqueがあまり使われなくなってきたのは使いにくいため。Hibernateなどと異なり永続化技術にDataMapperでなくActiveRecordを使っていることが問題。データアクセス層がTorqueの特定クラスを継承する必要があり、POJOを使うという時代の流れからは外れる。Torqueが自動生成するコードは良くないし使いづらい。
    • Cayenne。WebObjects?と似ているが、まだ使いやすいとはいえない。GUIのツールがついているが必ずしも使う必要はない。GUIツールはGenerationGap?パターンを考慮したコードを生成するので、自動生成と手でのメンテナンスの問題はない。CayenneはPOJOではないのが問題。
    • JDO。SpringのサンプルにJDOを使ったものがあるが、JDOの実装は何を使っているか？SpringにはSpringJDOというJDOの実装をTemplateパターンで簡単にしてくれるものが含まれている。
 
  • 業務ロジック層とデータアクセス層の依存関係
    • 業務ロジック層は、データアクセス層のインターフェースに依存することは問題ないが データアクセス層の実装に依存してはいけない。データアクセス層を変更したときに業務ロジック層にまで影響が及んでしまうのを避けるため。たとえば、Cayenneを使っていて一部分だけDbUtils?などに変更したとしても実装に依存していなければ業務ロジック層には影響を与えないですますことができる。

方法論 †

  • サンプルについて
    • ロッド氏は実装を含んだサンプルを否定しStruts blankのようなテンプレートを使うことを提唱しているが、実装を含んだ動くサンプルは必要なのではないか。開発者は、マニュアルを読んだだけではどこに着目すべきかわからない。サンプルは業務アプリケーションの典型的なパターンを抽出したものから作成し、実際に動くものにする。開発者はこのサンプルを通して業務アプリケーションの開発の仕方を学ぶことができる。このような手段は有効かつ重要。
    • たとえば必要なサンプルには2種類ある。
      • step by stepで進むチュートリアル。ツールの使い方、レイヤーごとにコンポーネントを作成する順番、Mockの使い方、テストの仕方などを含む。
      • 実際のアプリケーションに出てくるパターンを実装したサンプル。特にテストのサンプルは必ず用意すべき
    • 実際に動くシステムがある場合は動いているシステムがサンプルになる。新しい開発者には典型的なパターンのプログラムを読んで理解してもらう。
    • プロジェクトでStruts + Spring + Hibernateなど複数のOSSを使用する場合は、OSSごとにつくるよりも（必要かもしれないが）、複数を組み合わせたサンプル（業務アプリケーションの実装を含んだもの）を用意したほうが良い。開発者からは組み合わせたサンプルを求められることが多い。
 
  • コピペについて
    • 業務ロジック部分はコピペしないが、画面のコードはコピペすることが多い。
    • アプリケーションによってはコピペが効率が良い場合がある。
    • コピペはとっかかりには必要となることがある。
 
  • 画面とロジックで開発者の担当を分けるか分けないか（横割りか縦割りか）
    • 担当を分けていないという参加者が多かった。
    • 横割り派の意見
      • プレゼンテーション層と業務ロジック層で担当をわけることが多い。
      • 並行開発（開発期間短縮）ができる。
    • 縦割り派の意見
      • 技術知識よりも業務知識のほうが伝達が難しい。そのため機能ごとに担当を割り振る。
 
  • アジャイルとJ2EEの関連について
    • 関連は少ないと思われる。ただ、JavaがOOPであるということに若干のメリットがあるかもしれない。

ツール †

  • コードカバレッジツールは結構浸透している（参加者の約半数が利用したことがある）。
  • 話題に上がったツール。
    • Clover
    • jtest
    • Agitator
    • jcoverage
    • RAD
 
  • テストツールの使いどころ
    • Testコードを書かずにすべてをツールにまかせるのは間違っている。少なくとも、ブラックボックステストについては設計者がテストすべき内容を知っているべき。ホワイトボックステストについてはテストをツールにまかせるのはある程度意味があるかもしれない。
    • ツールはテストを補完する目的で使うべき。たとえば、境界値のテストはプログラマによってバラつきがありレビューをしても漏れが生じやすいのでツールによる自動網羅のテストは価値がある。
 
  • ライセンスの問題
    • ライセンス料が高い。
    • テストツールはテストを保証してくれると言っても、単に保証のためにお客さんが納得して高額なライセンス料を払ってくれるだろうか？
    • jtestの使い方。開発者全員が使用するのではなく専用端末で1つを使う。たとえば1日の終わりにバッチ処理を実行し翌朝レポートを見るという感じて使う。こうすればライセンス料はそれほど高く感じない。
 
  • 事前条件/事後条件
    • Coverageを信頼していないので内部設計の段階でメソッドごとに事前条件/事後条件を書き、それをレビューしている。
    • 事前条件とエラーチェックは違うもの。これを混同している人が多い。
    • 事前条件/事後条件を細かく書くのは大変。
 
  • その他
    • 最近のIDEベンダ（IBM、Oracle、Borland）は、コードカバレッジ、自動テスト、プロファイラ等をまとめた形で提供するようになってきている。たとえばWSADのRADなど。

OO †

  • Fake Object（偽のObject）について
    • OOの考え方からすればFake Objectはおかしい。ただ、OOだけで物事が解決するわけではないので、Fake Objectは使う場面を限って使うべき。
    • Fake Objectとしての永続オブジェクト：たとえば業務系アプリケーションの永続オブジェクトの場合、エンティティに閉じたエンティティ固有の抽象度の高い操作はないように思われる。したがって、永続オブジェクトに業務ロジックの操作もたせようと分析するのは時間の無駄なので永続オブジェクトはFake Objectでよいのでは。
    • プレゼンテーション層でのFake Object：プレゼンテーション層からコントロール層のインタフェースへ渡されるDTOをトランスファーオブジェクトと呼ぶのはふさわしくない。一種のビューのようなものだ。プレゼンテーションに対してエンティティの構造をすっきり見せるためのビューだと考えるとトランスファーオブジェクトとは別の意味合いでFake Objectを使う価値がある場面。
 
  • ビューとドメイン
    • きれいな設計では、ViewHelper?を介してビューとドメインオブジェクトが相互変換される。たとえば画面から値が入力された場合はViewHelper?を通じてドメインオブジェクトに値が設定され、業務ロジック層はドメインオブジェクトを使って何らかの処理を行い、データアクセス層へ転送する。この設計の問題としては、ドメインオブジェクトを分析するのが大変ということと、ビューとドメインオブジェクトの変換コードを書くのにコストがかかるということが挙げられる。
    • ViewHelper?をだれが書くのか（書くことができるのか）は大きな問題になる。ViewHelper?を作成するのはビューの構造を知っている画面担当者になるが、画面担当者がドメインオブジェクトのレイヤー構造を理解してViewHelper?を作成するのは大変な作業になる。画面担当者はViewHelper?を作るよりも自分たちの欲しい形でデータをDTOにつめて業務ロジック層と受け渡ししたほうがよい。そのほうがプロジェクトがスムーズに進む。
    • OOにこだわる必要があるのか？
      • OOにこだわったからといって生産性や品質があがるわけではない。
      • OOをわかっている人たちだけでプロジェクトが進むのであれば問題ないかもしれないが、設計者であってもOOを理解しているとは限らないのが現実。
      • 作業のお願いしやすさを優先して考えた場合、OOにこだわる必要性を感じない。
      • レイヤーを区切ってインタフェースでDTOをやりとりするとしたほうが生産性が高い。だが、画面がなければDTOはあまり必要にならない。業務ロジックの層から見た場合はドメインオブジェクトを知っているほうがきれいなのかもしれない。
 
  • エンティティ
    • Springのサンプルでは料金計算をエンティティに持っているが、料金計算のようなロジックは業務ごとに異なり1つのエンティティに閉じない。業務ルールは物や客によって異なるはず。業務ルールをエンティティにもたせるよりは業務ロジックのオブジェクトにもたせたほうがいい。
    • エンティティにロジックをもたせるとオーバーライドを考えるなど処理が複雑になるだけ。
    • 業務アプリケーションの世界では、業務ロジックは、エンティティに属するというより、業務機能に属する。例えば、手数料というものがあった場合に、手数料を計算するロジックは、業務機能ごとに違うのがほとんど。したがって業務機能にロジックを持たせるほうが実態に合っている。（くーすにおける業務フローと業務機能の定義を参照）
    • くーすにおける業務フローと業務機能の定義。
      • 業務フローとは、誰がどのような作業をやるのかを進行順に示したもので、誰が（どの部門が）何を行って、誰と（どの部門と）どんな関連があるのかが簡単に把握できるようになります。
      • 業務フローの中の個別の作業を、業務機能と呼ぶことにします。例えば、「交通費を清算する」という業務フローがあった場合、作業の流れとしては、起票者が「交通費清算書を起票する」、上長が「交通費清算書を承認する」、経理が「交通費清算所の上長承認を承認する」のようになります。この「交通費清算書を起票する」などがそれぞれ業務機能になります。
 
  • OOの使いどころ
    • OOはデザインパターンと同様非常に重要な意義がある。フレームワークや基盤を作る場合はOOは使いやすく、保守性はあがる。だが、業務ロジックについてはOOを適用してもそれほど効果を得られないのでは。あまりOOを大上段に構えず低コストで作ることを優先すべき。
    • OOはCADなどのようなグラフィカルに画面を作成するには適しているだろう。このような世界ではOOらしいOOが昔から良く使われてきた。
    • OOの使いどころは立場によって異なるといえる。何が最適解かは人それぞれ。
    • 業務系のアプリケーションの場合、「UMLによるビジネスモデリング」という本に書かれていることが業務の世界をどのようにモデリングするかの参考になりそう。リソースと手続きを分けて考えている。
    • アナリシスパターンはどうだろう。理解できる人が少ない。理解できてもあのモデルを作る意義は疑問だ
 
  • JavaとSQL
    • マーティンファウラーさんはDTOについて否定的。
      • ドメインモデル貧血症。
      • ドメインモデルとSQL。
    • 業務ロジックのおき場所。
      • SQLにロジックを埋め込むべきか否か？問い合わせのSQLには容易に業務ロジックが入ってしまう。ひとつの仕様書に書いてある要件がJavaとSQLにバラけることがある。問題点は、仕様変更があったときに修正箇所が一発でわからないこと。コスト増、保守性悪化につながる。
      • 指針としては、Select文一発で取得できることはSQLで行いSQLだけで無理なことはJavaで行うというのはどうか。サブクエリーは使う。だが、プロジェクトによってはSQLが複雑すぎて解析が難しい（たとえば300行以上のSQL。まれに1000行以上のSQL。）ことがあるので、チームメンバーの技術水準でどういう方針をとるかを決めるべき。
    • パフォーマンスについて
      • DBの設計が悪いときはSQLで不要なデータをはじくべき。通常はDBが一番のボトルネックになるので無条件にデータをDBから取ってきてJavaで処理すべきではない。
      • 最初にきれいに作ってあとでボトルネックを取りかえるという考え方があるが現実的ではない。DBアクセス部分を変更すると全体の構成に大きな影響が出る場合が多いので、あらかじめ最もチューニングされたデータアクセス層のメソッド定義をしておくことが必要。そうでなければ全体のコストがあがってしまう。
      • SQLで苦労するところはSelect文。更新系SQLはさほど問題にならない。
    • その他
      • 理想はSQLの記述力がとても高いか、Javaですべてが書けるくらいDBの性能が高いこと。
      • SQLにはコードが埋め込まれることがあるので苦労する。

３章 アーキテクチャ †

ビジネスサービス層 †

  • ステートレスについて
    • ビジネスサービス層はステートレスにするのが一般的。
    • ステートレスなサービスはオブジェクト指向的には中途半端なオブジェクトだとロッド氏は主張しているが疑問を感じる。ステートレスだからOOではないとはどいうことか。ロッド氏は状態と振る舞いを両方持つものを真のオブジェクトとしているようだ。
    • .Netではステートレスでもステートフルでもどちらも可能。主流はどちらなのか？EJBと同じようにステートレスのほうが良いのでは。
 
  • EJBよりも.Netのserviced componentsが生産性が高いというのは本当か？
 
  • EJBを使わない行き当たりばったりの（アドホックな）方法
    • EJBを使わない行き当たりばったりの方法を採用すると社内ソリューションに走りメンテナンスがしずらくなるのではないか。一般的で はないので習得しにくいというデメリットも生じる。
    • それほど問題もないのでは。たとえば、トランザクションの制御などはTemplateMethod?などを使えばそれなりにカバーできるはず。

ビジネスオブジェクトを公開する †

  • 永続オブジェクトは永続ストアから切り離さねばならない。
    • p.38の次の文の「relationships」とは何か？「As with transfer objects, this requires us to materialize all necessary relationships to support the current use case.」
    • エンティティビーンは切断をサポートしていない？エンティティビーンはトランザクションの中でしか使えないということではないか。
    • HibernateのOpenSessionInView?について。
      • 使うべきでない。
      • プレゼンテーション層がデータアクセス層に依存すべきでない。プレゼンテーション層がエンティティを直接見るのはおかしい。
      • 画面を表示しているときに例外が発生するかもしれないなど、やっかい。不確定な状態をプレゼンテーション層に持ち込みたくない。
      • DTOを使わないからOpenSessionInView?が必要になる。ロッド氏はFake ObjectやDTOを否定しているが、これらで解決できる問題をOpenSessionInView?で解決しようとしているのではないか。
 
  • 薄いWeb層
    • StrutsのActionやJSPにロジックのコードを書いてはいけない。
 
  • リモートクライアントのサポート
    • Hessian：バイナリベースのWebサービスのプロトコル。容量が小さくてすむ。バイナリデータの送信に適している。
    • Burlap：Webサービスに接続するためのシンプルなXMLベースのプロトコル。

次回について †

  • 3章(小林さん)
  • 4章(大谷さん)

この議事録を読んで分からないことや、疑問に思ったこと、その他ご意見等がありましたら下記コメント欄にお願いします。匿名でも結構です。


Menu