【研修ノート】

10/28/2008

実開発では、e.printStackTrace(), System.out.println()などは入れない！
コードを少しでも変えたら処理が変わったということになるので、
単体テストからやり直し。

ログ出力の規約を決めておく。それに沿ってログを出すようにする。

【トランザクション制御】
一つのトランザクションの中には一つのコネクション。
コネクションの管理はトランザクションの範囲。
コネクションを管理する一番いい層はビジネス層である。
なぜならビジネス層は一度の業務（一度のトランザクション）単位で分割されているから。
データアクセス層にはコネクションを作らない！
コネクションを生成するのはビジネス層にし、コネクションを引数としてDAOに受け渡す。


【三層に分ける】
ビジネス層には特定の技術に依存するような設計はしない。例：Connection
理由：しっかりと層を分けるためにそのように設計する。

三層に分ける理由。
大規模開発において開発者個々の技能において担当範囲を分けることができる。
個々の層の構成を見やすくする。可読性を上げる。

どうすればそのような設計ができるのか。
フレームワーク使う。よくわからん。


【テーラリング】
プロセスを設計する必要がある。プロジェクトに応じてプロセスを組み替える。
代表的なものはテンプレートとしてあるので、それを実際の状況に合うように
テーラリングをする。

【概念クラス図】
クラスを抽出する。
多重度が大事。

【ユースケース】
細かいことは書かない。
ユーザーから見たシステムの主な機能を書き出す。

【ユースケースシナリオ】
やりすぎない。
丁寧にやり過ぎない。

【画面】
画面があればユースケースシナリオが要らないこともある。
Webアプリの場合はこっちに力を入れるほうがいいかも？
画面大事だと思うらしい。俺もそう思う。
なんか作るもののイメージわくし。

【シーケンス図】
全て書いていくと膨大な量になり、大変非効率である。
代表的なものだけ書いていく。

一概にどのようなドキュメントを作るかというのは決まっていない。

正解は無く、その場の状況に合わせてプロセスを作り変えていかなければいけない。

ドキュメントはお客様に合わせる。

極端に作業を遅らせるようなドキュメントを依頼された場合は要相談。

分析をやっている間にアーキテクチャ（技術要素検討）をやっていく。
用件定義⇔技術要素検討
例：用件定義の段階でお客さんがJavaを使ってほしいなどの要求を出してきた場合。


【パッケージング】
レイヤは論理的にシステムを分ける。概念的に分ける。抽象的。
パッケージングはレイヤを参考にしてクラスを物理的に分ける。

相互依存、循環参照はだめ。絶対。

相互依存、循環参照はパッケージを変更した場合に影響範囲が大きくなる可能性がある。
とても危険なのよ。
クラスで循環参照、相互依存は御法度！for未熟者
ただ高度な設計テクで相互依存になっている場合はあるらしい。
相互依存になっている場合はまず作成者に理由を聞くべし。

＜クラス設計に関するメモ ＞
http://homepage3.nifty.com/satoshis/oo/memo.html

＜第5回　Webサイトの詳細設計＞
http://www.atmarkit.co.jp/fjava/rensai2/websys05/websys05.ht...


【インターフェースの導入】
変更や各兆字の影響や、再利用、チーム開発、テスト容易性の観点などから
インターフェースを導入する。
インターフェースがあればスタブが作成しやすい。


【技術要素の検討】
システムの特性に合わせてメリット、デメリットを検討。

同期　　：クライアントがサーバに要求を出さなければ動かない。

　非同期型：クライアントが要求を送信しなくても動く。例：GoogleMap


【トランザクションスクリプト】
ビジネス層の設計方式のうちの一つ。
振る舞いと属性を分離していく。
処理のみの（ステートレスな）オブジェクトが、値のみを持つオブジェクトから、
必要な値をやり取りして情報結果を得る。

【ドメインモデル】
ビジネス層の設計方式のうちの一つ。
OO指向的な設計方法。
属性と振る舞いを持ったオブジェクト同士が、必要な情報を得るために、
メッセージをやり取りして最終的な情報結果を得る。

Patterns of Enterprise Application Architecture
http://martinfowler.com/eaaCatalog/



web.xmlを処理を追加する(Servletを増やす)ごとに更新していくのは面倒且つ危険。
Front Controller。受け付けるだけのServlet。
を使うことによって処理を増やすごとにServletの数を増やさずにすむ。

【設計クラス図】
実装技術を意識する。
クラス図には描き過ぎないように注意する。

【シングルトンパターン】
処理を表すクラスはシステム内で一つのオブジェクトしか必要ない場合が多い。
属性を持ってない場合はオブジェクト一つで済む場合。
一つしかオブジェクトが生成されないようにするための仕掛け。
オブジェクトが一つであることを保障する。

コンストラクタをprivate指定にしてしまう。
クラス内でオブジェクトをnewする。
オブジェクトはprivate static finalで。
public指定のgetInstanceを使ってオブジェクトを他のクラスに渡す。