ソフトウェア開発標準サンプル @ wiki
http://w.atwiki.jp/devstsample/
ソフトウェア開発標準サンプル @ wiki
ja
2010-03-24T22:22:12+09:00
1269436932
-
方式設計サンプル
https://w.atwiki.jp/devstsample/pages/17.html
&bold(){(ただいま作成中です。)}&italic(){}
方式として決めておいたほうが良いことをざっと決めます。
なお、サンプルフレームワークで実装予定の無いところは、項目だけにしておきます。
**1.セッション管理
・HttpSessioを直接開発者に操作させることは、不具合の原因になりやすいため、
管理機構を用意する。
・ブラウザから一定間隔で生存通信(HeartBeat)をサーバに送信し、
システムを開いている間はセッションが切れないようにする。
・ログイン/ログアウト時に自動的にセッションのクリアを行い、
ゴミが残ることを防ぐ。
・セッション情報の用途は、
①画面を行ったり来たりしたときに以前の情報が再表示出来るようにすること。
②ログイン済み、ログインユーザIDなど、認証情報を保存できるようにすること。
(設計中)
**2.ファイルアップロード/ダウンロードと永続保存方式
(設計中)
**3.PDF/印刷方式
※通常は商用のミドルウェアと連携するため、このサンプルでは作成しない予定。
**4.認証/権限方式
(設計中)
**5.エラー制御方式
画面設計規約で述べた、エラーハンドリング方法を下記の方法で実装する。
(設計中)
**6.ログ出力方式
・ログの出力タイミング、出力項目を規定する。
①フレームワークが自動で出力するログ
「開始」⇒Actionの開始
「終了」⇒Actionの終了
1Action内の、DBアクセス時間の累計とSQL発行回数と
Action全体の処理時間を分けて、終了時のログに出力する。
「アプリケーションエラー」
・データの不整合などが検出された場合に、
個別プログラムでハンドリングするエラー。
エラー時は個別プログラムではエラーのthrowだけ行い、
ログ出力はフレームワークに委ねる。
「システムエラー」
下記のように個別のプログラムでハンドリングできないエラー。
①ハード/OS/ミドルウェアなど基盤の停止・不具合に起因する問題。
②プログラムのバグにより発生する、NullPointerExceptionなどの問題。
・SQLでエラーが発生した場合はSQLの全文をログ出力する。
・Actionでエラーが発生した場合は、リクエストのダンプを出力する。
「処理時間警告」
・Action終了時、SQL終了時に一定以上の時間がかかった場合は、
警告ログを出力する。
「排他制御メッセージ」
・楽観ロックによる排他制御を行った際に、他のユーザーと入力が競合し
再入力を要求するメッセージ。
ログ上は警告とする。
画面上の動きは個別の開発者が実装しなくて良いようにフレームワークで
標準化したいところ。
②個別プログラムで出力するログ
「●名称未定●」
処理停止は必要ないが、管理者が把握し対応が必要なもの。
ただし、24時間即時対応が必要なレベルではなく、夜間バッチで出たら、
管理者を叩き起こすレベルではなく翌朝対応で十分なもの。
「デバッグ」
開発者が任意のものを出してよいが、基本的には単体開発環境だけで出力するもの
とし、本番環境では出力しない。
①出力項目は
・時刻
・ユーザーID
・ユーザーIPアドレス
・画面ID
・画面名
・操作名(クリックしたボタン名など)
・種別[開始/終了/エラー/処理時間警告/警告/デバッグ]
・メッセージID
・メッセージ連番(1回のログが複数行になる場合があるので、行ごとに番号を振る)
・メッセージ本文
**7.ログインユーザー管理
ログイン中のユーザーを管理者が把握できるようにする。
・セッション管理のところで述べたHeartBeat、ブラウザを閉じるとログインを怠ったユーザー分のセッションもほどなく消えるため、現在のログインユーザが把握可能となる。
**8.排他制御方式
データ更新の排他制御について述べる。
・トランザクション分離レベルはRead Committedに設定する。
・Read Committedに設定されするため、1トランザクション内で2度以上同一のレコードを検索することは禁止。ただし、変更の可能性の無いレコードや、変更の可能性があっても問題ないことが保障できる場合は可能とする。
・1トランザクション内で、同一レコードを読みそのレコードを書き込む場合は、SELECT FOR UPDATEによるロックを実行する。
・SELECT FOR UPDATEを使う場合は、下記のルールに従ってロックする。
①ロック順はテーブル名の昇順とする
②SELECT FOR UPDATE発行時にORDER BY で、主キーの昇順にソートして取得する。
・画面からの入力されるデータの更新については、楽観ロック方式により、先勝ちによる整合性の確保を実現する。すなわち、検索時にレコードのバージョン番号フィールドをhidden項目に保持し、更新時は、Update文のWHERE句にバージョン番号が一致する事を条件として更新を実施し、該当するレコードが無い場合は、他のユーザーにより更新されているものと判断する。なお、更新時にデータを再取得してはいけない。
**9.改ページ方式
改ページの実装方式を規定する。
また、セッションに必要以上のデータを保持しない実装方式について述べる。
・改ページ対応の一覧形式データ表示の前には、Countで全数を把握後、表示するページの分だけデータを取得する。
**10.ブラウザ互換性確保方式
①リセットスタイル
・下記の3スタイルシートをベースにカスタマイズしたものを用意する。
YUI Liblaryの「reset.css」⇒各ブラウザでデフォルトで設定されているスタイルをリセット
YUI Liblaryの「base.css」⇒独自のスタイルを設定
YUI Liblaryの「fonts.css」⇒各ブラウザのフォントサイズの相違をリセット
・その他下記の指定。
* {
font-family:
~
}
//IE7対応
*:first-child+html * {
font-family:
~
}
//IE6対応
* html * {
font-family:
~
}
・スクロールバーを必ず表示(Fire Fox3でスクロールバーが表示されない問題に対応。
html {
overflow: scroll;
overflow: -moz-scrollbars-vertical;
overflow-x: scroll;
}
②CSSハック
・Google CodeのEI8.jsの使用を検討する。
・ブラウザ個別にスタイルを指定できるハックを利用する。
・ボックスモデルバグなど、主要なバグをあらかじめ把握してスタイルシートを作成する。
・ブラウザ個別の位置の調整にはネガティブマージンを利用する。
メモ
・cssはバージョン2.1を使用する。
(設計中)
2010-03-24T22:22:12+09:00
1269436932
-
トップページ
https://w.atwiki.jp/devstsample/pages/1.html
**ソフトウェア開発標準サンプル@wikiへようこそ
-ソフトウェア開発標準(以下、開発標準と記す)のサンプルを公開するwikiです。
-開発標準とは、各プロジェクトで定められる、ガイドドキュメント・フレームワーク・支援ツール・設計書テンプレートの一式です。言い換えれば、数十人以上の共同作業で進められる開発プロジェクトで、「標準化チーム」「共通チーム」「アーキテクトチーム」などの名前で呼ばれるチームが作成するものの一式と考えてください。
-このwikiでは、簡易な画面標準と開発プロセスをまずサンプルとして定義し、「プロジェクトに特化すればフレームワークと支援ツールでここまで出来る」というあたりをフレームワーク・ツールを中心としてサンプルとして作成していきます。
-基本的には、個人のノウハウを整理するために作っていますし、ターゲットとするシステムは決め打っているので、このまま使っていただく事はできないかと思いますが、このwikiを読んでいただいた方が、開発標準を作成する際に参考になるようなものになれば幸いです。
**コンテンツ
このwikiで力をいれていくのは、フレームワークと開発支援ツールです。
しかしながら、システム概要/画面規約/開発プロセスをある程度決めないと、プロジェクト固有のフレームワークは作れないので、申し訳程度には、これらのものを用意します。
設計書からソースコードの一部を自動生成する仕組みもツールとして提供したいので、インプットとなる設計書も申し訳程度にはサンプルで作ります。
というわけで、このwikiでは下記のものをサンプルで作っていきます。
-[[システム概要サンプル]]
-[[画面規約サンプル]]
-[[開発プロセスサンプル]]
-[[方式設計サンプル]]
-[[フレームワークサンプル]]
-[[開発環境サンプル]]
-設計書サンプル
-[[開発支援ツールサンプル]]
バッチ処理や帳票規約も作ってこそ一式ですが、初めはこのぐらいにしておきます。
2010-03-24T21:58:11+09:00
1269435491
-
画面規約サンプル
https://w.atwiki.jp/devstsample/pages/15.html
このwikiのメインではないのでここは非常にシンプルに書いておきます。
**1.基本的な考え方:
レイアウト・配色・画面遷移・動作の全てについて、規約でパターン化を行い、
個別の機能でカスタマイズは不可とします。
パターンに従う事が出来ない場合は、規約改定について協議する事とします。
こうすることで、システム内の全機能の操作性・デザインの統一を図るとともに、
フレームワークによる開発支援を容易にし生産性・保守性の向上を図ります。
**2.画面種類
画面には大きく下記の5種類を定める。
①業務画面
⇒ユーザーが業務を行う中心となる画面。
②入力支援ダイアログ
⇒業務画面への入力を支援する画面。
(商品コードを検索して、業務画面のテキストボックスに埋めたりする画面)
③確認ダイアログ
⇒ポップアップして「はい」「いいえ」を選択させる。
④エラー通知ダイアログ
⇒ポップアップしてエラーを通知する。
⑤メッセージ通知ダイアログ
⇒ポップアップしてエラー以外の情報を通知する。
⑥ログイン画面
⇒ID、passwordを入力してログインする画面。
⑦メニュー画面
⇒このシステムの機能一覧を表示しユーザに選ばせる画面。
⑧パスワード変更画面
⇒パスワードを変更する画面。
**3.画面種類毎のデザイン
①業務画面
・画面ID、画面名、システム日付、ユーザー名をヘッダーに表示。
・フッター部分にボタン及び、メッセージ表示領域を配置。
・Window初期サイズは◎◎×◎◎。(後で決めます。今は細かく書かない)
・ユーザによるWindowサイズ変更は可能だが、
レイアウトが崩れないことは保障しない。
・アドレスバー、ブラウザメニュなどブラウザ標準機能は非表示。
・フォントXX、背景色。。。(後で決めます。今は細かく書かない)
**4.画面遷移
前提:
・メニュー画面は複数同時に起動される可能性があるものとします。
・業務画面は複数同時に起動される可能性があるものとします。
・同一の業務画面が多重起動される可能性もあるものとします。
①業務画面表示までの流れ
・通常ログインパターン
ログイン画面でログインボタンをクリック
↓
(同一ウィンドウ内で遷移)メニュー画面表示
↓
メニュー画面で機能名をクリック
↓
(別ウィンドウをポップアップ)業務画面表示
・シングルサインオンパターン
社内ポータルサイトのログインでログインボタンをクリック
↓
(同一ウィンドウ内で遷移)社内ポータルトップ画面表示
↓
社内ポータルサイトのログインでログインボタンをクリック
↓
(同一ウィンドウ内で遷移)社内ポータルトップ画面表示
②業務画面表示後の画面遷移
・参照パターン
初期画面で、検索条件を入力し検索ボタンをクリック
↓
(同一ウィンドウ内で遷移)検索結果を一覧形式で初期画面に表示
↓
検索結果の1行を選択し、参照ボタンをクリック
↓
(同一ウィンドウ内で遷移)参照画面を表示
↓
参照画面で戻るボタンをクリック
↓
(同一ウィンドウ内で遷移)初期画面を表示
・新規登録パターン
初期画面で、登録ボタンをクリック
↓
(同一ウィンドウ内で遷移)登録画面を表示
↓
登録画面で確認ボタンをクリック
↓
(同一ウィンドウ内で遷移)確認画面を表示
↓
確認画面で実行ボタンをクリック
↓
(同一ウィンドウ内で遷移)完了画面を表示
↓
完了画面で完了ボタンをクリック
↓
(同一ウィンドウ内で遷移)初期画面を表示
※完了画面で連続登録ボタンをクリックすると、再度登録画面へ遷移
・更新パターン
初期画面で、検索条件を入力し検索ボタンをクリック
↓
(同一ウィンドウ内で遷移)検索結果を一覧形式で初期画面に表示
↓
検索結果の1行を選択し、更新ボタンをクリック
↓
(同一ウィンドウ内で遷移)更新画面を表示
↓
更新画面で確認ボタンをクリック
↓
(同一ウィンドウ内で遷移)確認画面を表示
↓
確認画面で実行ボタンをクリック
↓
(同一ウィンドウ内で遷移)完了画面を表示
↓
完了画面で完了ボタンをクリック
↓
(同一ウィンドウ内で遷移)登録画面を表示
・削除パターン
初期画面で、検索条件を入力し検索ボタンをクリック
↓
(同一ウィンドウ内で遷移)検索結果を一覧形式で初期画面に表示
↓
検索結果の1行を選択し、削除ボタンをクリック
↓
(同一ウィンドウ内で遷移)削除画面を表示
↓
削除画面で確認ボタンをクリック
※この画面では何も編集できないが削除には慎重を期すため、
登録、更新と同じ手数にしておく。
↓
(同一ウィンドウ内で遷移)確認画面を表示
↓
確認画面で実行ボタンをクリック
↓
(同一ウィンドウ内で遷移)完了画面を表示
↓
完了画面で完了ボタンをクリック
↓
(同一ウィンドウ内で遷移)登録画面を表示
・ファイルアップロードパターン
初期画面、登録画面、変更画面では必要に応じファイルのアップロードが可能。
・ファイルダウンロードパターン
初期画面、参照画面では必要に応じファイルのダウンロードが可能。
・PDF表示/印刷指示パターン
初期画面、参照画面では必要に応じPDF表示、
特定のサーバプリンタへの印刷指示が可能。
・バッチ処理指示パターン
初期画面、参照画面では必要に応じバッチ処理の実行指示が可能。
**5.ボタン一覧
①前提
・ボタンの種類は標準で定める。これ以外のボタンは作らない。
・ボタン種類毎に標準で定めたファンクションキーを割り当てる。
・ブラウザに予約されているファンクションー動作(F5で更新等)は無効化し、システム内のボタン操作に割り当てる。
②業務画面フッターボタン一覧表
|ボタン名|動作|使用可能画面|
|F1:閉じる|業務画面を閉じる|初期画面|
|F3:再取得|DBからデータを再取得して表示|更新画面、削除画面|
|F3:クリア|入力内容をクリアする|初期画面、登録画面|
|F5:参照|参照画面に移る|初期画面|
|F6:登録|登録画面に移る|初期画面|
|F6:連続登録|登録画面に移る|完了画面(登録パターンのみ)|
|F7:更新|更新画面に移る|初期画面|
|F8:削除|削除画面に移る|初期画面|
|F9:印刷指示|印刷指示を実行|初期画面、参照画面|
|F9:PDF出力|PDF出力を実行|初期画面、参照画面|
|F9:ファイルアップロード|ファイルアップロード|初期画面、登録画面、編集画面|
|F9:ファイルダウンロード|ファイルダウンロード|初期画面、参照画面|
|F10:検索|検索を実行|初期画面|
|F11:確認|確認画面に移る|参照画面、登録画面、編集画面、削除画面|
|F11:実行|完了画面に移る|確認画面|
|F11:完了|初期画面に移る|完了画面|
|F12:戻る|1つ前の画面に戻る|参照画面、登録画面、編集画面、削除画面|
|F12:再入力|1つ前の画面に戻る|確認画面|
③業務画面フッター以外のボタン
フッター以外のボタンはファンクションキーを割り当てない
|ボタン名|動作|備考|
|ヘルプ|ヘルプを表示|ある場合はヘッダー部分に配置|
|入力支援|入力支援ダイアログをポップアップ|テキストボックスの右に配置、見た目は[...]|
④入力支援ダイアログのフッターボタン
|ボタン名|動作|備考|
|F10:検索|検索を実行||
|F11:選択|業務画面のテキストボックスに値をセットしてダイアログを閉じる||
|F12:戻る|ダイアログを閉じる||
⑤ログイン画面
ファンクションキー割り当てなし
|ボタン名|動作|備考|
|ログイン|メニュー画面に遷移||
|パスワード変更|パスワード変更画面に遷移||
|管理者に連絡|メーラが開き、あて先がシステム管理者||
⑥パスワード変更画面
ファンクションキー割り当てなし
|ボタン名|動作|備考|
|パスワード変更|パスワード変更してログイン画面に戻る||
|戻る|ログイン画面に戻る||
⑦メニュー画面
・機能名のリンクをクリックで業務画面表示
・画面番号テキストボックスに番号を入力して、開くボタンクリック(もしくはEnterキー)
で業務画面表示
**6.エラー時の動作
エラー種類と動作:
・クライアントで発生するエラー
①ロストフォーカス時単項目チェックエラー
内容:
テキストボックスからフォーカスが外れたタイミングでチェックを行う、
単項目のチェック。サーバサイドへの問い合わせはしない。
細かくは、「型チェック」⇒「範囲チェック」の順で行い、
型チェックでエラーの場合、範囲チェックは行わない。
ただし、未入力でフォーカスをはずす場合は、チェックを行わない。
動作:
ポップアップでエラーを表示、エラーになった項目名と理由を表示する。
②クライアントサイドシステムエラー
内容:
JavaScriptで予期せぬ結果が返るなど、クライアントサイドで発生するシステムエラー。
動作:
・ポップアップでエラーを表示。
・サーバに非同期通信でエラーを通知を試行。
・および、クッキーにエラー内容を書き込む。
・サーバで発生するエラー
①~③までは、サーバ処理の最初にこの順で実行する。
①単項目入力チェックエラー
内容:
単項目の入力内容チェック結果のエラー。
細かくは、「必須チェック」⇒「型チェック」⇒「範囲チェック」優先順位でチェック。
また、画面上の全入力項目を一度のに全てチェックする。
動作:
・入力した画面から次の画面には遷移させない。
・ポップアップでエラーを表示。「入力チェックでエラーが発生しました。」と表示。
・エラーのあった項目の色を赤色に変更
・フォーカスをエラーのあった項目のうち、Tab順が最も早い箇所に設定。
・画面下部のメッセージ領域に、フォーカスが当たっている項目のエラー内容を表示。
(その後も、サーバー処理が発生するまで、フォーカスが当たった項目がエラーの場合だけ、
メッセージ領域にエラーを表示するようにし続ける。)
②相互項目入力チェックエラー
内容:
項目間の入力内容を相互チェックして判明するエラー。
例えば、値の大小比較。終了日のほうが開始日より早い値が設定されているなど。
このチェックは、1箇所でもエラーがあればそこで終了。
動作:
・入力した画面から次の画面には遷移させない。
・ポップアップでエラーを表示。「入力チェックでエラーが発生しました。」と表示。
・エラーのあった項目の色を赤色に変更
・フォーカスをエラーのあった項目のうち、Tab順が最も早い箇所に設定。
・画面下部のメッセージ領域に、相互チェックエラー内容を表示。
(その後も、サーバー処理が発生するまで、メッセージ領域にエラーを表示し続ける。)
③コード未存在エラー
内容:
マスターに存在しないコードが入力されているかどうかチェックする。
このチェックは、1箇所でもエラーがあればそこで終了。
動作:
・入力した画面から次の画面には遷移させない。
・ポップアップでエラーを表示。「コード未存在エラーが発生しました。」と表示。
・エラーのあった項目の色を赤色に変更
・フォーカスをエラーのあった項目に設定。
・画面下部のメッセージ領域に、コード未存在エラーの内容を表示。
④排他制御エラー
内容:
更新対象のデータが、すでに別のトランザクションで更新されてしまっていた場合発生。
このチェックは、1箇所でもエラーがあればそこで終了。
動作:
・入力した画面から次の画面には遷移させない。
・ポップアップでエラーを表示。
「このデータは別のユーザに更新されています。読み込みなおしてから更新してください」
と表示。
・画面下部のメッセージ領域にも、エラー内容を表示。
⑤業務処理エラー
内容:
①~④に当てはまらないエラーでプログラム内で明示的にチェックを行うもの。
例えば、会計的な締め処理が終了しているデータを更新しようとした場合にエラーとするなど。
このチェックは、1箇所でもエラーがあればそこで終了。
動作:
・入力した画面から次の画面には遷移させない。
・ポップアップでエラーを表示。エラーメッセージはエラー内容に応じたものを出す。
・画面下部のメッセージ領域にも、エラー内容を表示。
⑥サーバサイドシステムエラー
内容:
バグもしくはハード・ミドルウェアに障害がある場合に発生、タイミングは随時ありえる。
このチェックは、1箇所でもエラーがあればそこで終了。
動作:
・入力した画面から次の画面には遷移させない。
・ポップアップでエラーを表示。エラーメッセージはエラー内容に応じたものを出す。
極力内容を分類するが、NullPointerException等バグにより発生するものは、
「予期せぬ例外が発生しました。」とする。
・画面下部のメッセージ領域にも、エラー内容を表示。
**7.その他の動作
・タブキーによる制御準は、画面単位で、「ブラウザ標準」or「全項目の順序制御」を決める。
・画面初期表示時のフォーカスはタブによるキー制御の1番目のもの。
・完了画面から初期画面に遷移した場合、初期画面に検索機能があれば直近の検索条件で再検索する。
・Enterキーでも次の項目へのフォーカス移動を行うようにする。ただし、ボタンにフォーカスが当たっている場合は、ボタンクリックの動作をする。
・テーブル内の項目にフォーカスが当たっている場合に、上下のキーを入力すると、フォーカスが1の行、下の行に移動する。
・クリアボタン、戻るボタン、終了ボタンクリック時は、入力項目が変更されている場合のみ、「編集内容が失われます。よろしいですか?」と確認ダイアログを出す。
ただし、入力項目でも単に検索条件の項目の入力の場合は、変更とみなされない(つまり確認ダイアログは出ない)。
・入力項目は、フォーカスを受け付けた際は、色が変わる。
(このぐらいにしておきます。)
2009-08-26T23:16:12+09:00
1251296172
-
開発支援ツールサンプル
https://w.atwiki.jp/devstsample/pages/20.html
&bold(){(ただいま作成中です。)}&italic(){}
**1.開発予定ツール
①設計書から、デザイン確認用画面/JSP/Actionの自動生成部分を生成するツール。
②JUnitテスト支援。
-テストソース内のコメントから、Excel形式のテスト仕様書作成。
-本フレームワーク上でのJUnit実行を支援するためのTestCaseの拡張版
-Selenimu実行支援。予定として、SelenimuのRCモードJava版を使用し、
サーバーサイドのモジュールと似たような形式でテストケースを管理できるようにする。
2009-08-26T01:32:05+09:00
1251217925
-
メニュー
https://w.atwiki.jp/devstsample/pages/2.html
**メニュー
-[[トップページ]]
-[[システム概要サンプル]]
-[[画面規約サンプル]]
-[[開発プロセスサンプル]]
-[[方式設計サンプル]]
-[[フレームワークサンプル]]
-[[開発環境サンプル]]
-設計書サンプル
-[[開発支援ツールサンプル]]
----
**リンク
-[[@wiki>>http://atwiki.jp]]
-[[@wikiご利用ガイド>>http://atwiki.jp/guide/]]
**他のサービス
-[[無料ホームページ作成>>http://atpages.jp]]
-[[無料ブログ作成>>http://atword.jp]]
-[[2ch型掲示板レンタル>>http://atchs.jp]]
-[[無料掲示板レンタル>>http://atbbs.jp]]
-[[お絵かきレンタル>>http://atpaint.jp/]]
-[[無料ソーシャルプロフ>>http://sns.atfb.jp/]]
// リンクを張るには "[" 2つで文字列を括ります。
// ">" の左側に文字、右側にURLを記述するとリンクになります
//**更新履歴
//#recent(20)
&link_editmenu(text=ここを編集)
2009-08-25T00:18:14+09:00
1251127094
-
フレームワークサンプル
https://w.atwiki.jp/devstsample/pages/18.html
&bold(){(ただいま作成中です。)}&italic(){}
ようやくここから本題。
**1.オンラインで採用するミドルウェアと、ベースフレームワーク
・JDK6系最新
・Tomcat6系最新
・SAStruts最新
・S2JDBC最新
テンプレートエンジン(mayaa等も)検討する。
あとは適宜追加。
**2.階層構造
・Action層から、S2JDBCを直接使用する方式。
従って、JSP + Action層の2層構造。
※Service層は作らない。
Service層を作らない理由は、Serviceの粒度の検討など、
設計者が迷いやすい要素を排除するため。
階層が無ければ、実装箇所が自明となるため、実装が均質化する。
※Dao層の採用は検討する。
DB周りの処理ロジックを自動生成出来生産性向上につながる可能性があるため。
※JSPはテンプレートエンジンを採用した場合は、別の形になる。
・画面IDDTO
SQLの戻り値として、Tableに対応したEntityだけでは、扱いにくい。
画面IDDto+連番の命名方法で、画面と1と対応したDtoを用意し、
S2JDBCのEntityの一種として扱う。
ヘッダ + テーブルなどの構造を持っている場合は、
1画面に2つ対応したDTOを作る。
・Actionの継承関係
BaseAction←(継承)- 画面IDActionGen←(継承)-画面IDAction
Actionは、画面1つに対して2つ作る(自動生成分と手動生成分)。
-BaseActionは、フレームワークで1つ(とりあえず。あとで増やすかも)
-画面IDActionGenは、画面で1つに対して1つ(ツールで自動生成)
-画面IDActionは、画面で1つに対して1つ(手動で作成)
どこに実装するかは、明確で、Base>Gen>手動の順で、
出来るだけ上の階層に実装し、手動実装を減らす。
※Genは自動生成なので、Baseは無くても実装コストは変わらないが、
ソースコード量が増えると、SVN・ファイルコピー・コンパイルなどに、
時間がかかるためBaseは必須。
・今のところ作成予定が無いが、Dao層をおいた場合でも、
Base>Gen>手動の構造は維持する。
実装を開始しました。しばらくwiki更新の頻度は下がるかもしれません。
2009-08-24T01:51:00+09:00
1251046260
-
開発環境サンプル
https://w.atwiki.jp/devstsample/pages/19.html
&bold(){(ただいま作成中です。)}&italic(){}
**1.使用ソフト
・JDK1.6.0_16(jre6)
・Tomcat6.0.20
・S2.4.39
・S2Tiger-2.4.39
・eclipse3.3.2
※3.5は、SeaserのResourceSynchronizerとSAStrutsPluginが
導入できなかったため導入見送り。
・Tomcatプラグイン
・ResourceSynchronizerとSAStrutsPlugin
・プロパティエディタPlugin 5.3.3
**2.環境初期セットアップ
①JDKはインストーラでインストール
②tomcatは、zipから解凍して配備
③Eclipseは、zipから解凍して配備
④Tomcatプラグイン
⑤ResourceSynchronizerとSAStrutsPlugin
⑥プロパティエディタPlugin
※④~⑥は、http://sastruts.seasar.org/setup.htmlを参照
動作確認のため、「5.インストール後の設定と動作確認」
までやってしまう。
注意は、「sa-struts-tutorial」をインポート後、Tomcat6.xでは、
ライブラリパスの変更が必要。
(変更前)
TOMCAT_HOME/common/lib/jasper-runtime.jar
TOMCAT_HOME/common/lib/jsp-api.jar
TOMCAT_HOME/common/lib/servlet-api.jar
↓
(変更後)
TOMCAT_HOME/lib/jasper.jar
TOMCAT_HOME/lib/jsp-api.jar
TOMCAT_HOME/lib/servlet-api.jar
**3.環境フォルダ構成
C:\devstsample ⇒開発環境のルートフォルダ
├─env ⇒ ツールやミドルは出来るだけここに集約
│ ├─apache-tomcat-6.0.20
│ ├─eclipse
│ └─Java
│ ├─jdk1.6.0_16
│ └─jre6
└─src ⇒ ソースは出来るだけここに集約
└─eclipsews ⇒ eclipseのworkspaceはここ
└─sa-struts-tutorial
2009-08-22T02:39:14+09:00
1250876354
-
開発プロセスサンプル
https://w.atwiki.jp/devstsample/pages/16.html
このwikiのメインではないのでここは非常にシンプルに書いておきます。
**1.開発プロセスの概要:
ざっくりこんな流れを想定します。
・①要件定義⇒②外部設計⇒③内部設計⇒④単体開発/単体テスト⇒⑤結合テスト⇒⑥シナリオテスト⇒⑦システムテスト⇒⑧ユーザーテスト
・SEとPGは分業制です。
-SEはお客様の対面に立って、仕様の詰めを行うがプログラム開発はしません。
スキルとしてもJavaによるプログラムが出来ることは必須としません。
-PGはお客様の対面には立ちませんが、プログラム開発を行います。
①要件定義
システムの業務フロー、機能一覧(画面一覧とバッチ一覧)、
DBの主要項目ぐらいまでは洗い出します。
担当:SE
②外部設計
お客様と決めておくべき事項は全てここで決めます。
加えて、画面の項目やDB項目の物理名は決めておきます。
担当:SE
③内部設計
外部設計で定義していないので、プログラム開発に必要な項目を設計する。
担当:PG
④単体開発/単体テスト
プログラム開発と、プログラム単体の自動テスト(JUnitなど)、
PGのローカルPC上での画面単位の動作確認テストなどを実施。
一連の操作による画面の流れが正常に出来る程度の結合テストまでは実施。
担当:PG
⑤結合テスト
全プログラムを結合して、結合テスト環境に配備してテストを実施。
関連する機能同士の整合性の確認、また、PG開発者とは別の人間により、
単体テストの再確認等も実施。
結合して動かせることと、PGが開発したプログラムの品質確保が目的。
担当:SE
※、不具合の修正はPGが実施
⑥シナリオテスト
夜間バッチ実行(日次処理、月次処理、年次処理)とオンラインでの入力を絡めた、
実業務のシナリオを想定したテストを実施。
結合テストの一部だが、上記のレベルの品質が安定しないと実施が不能なため、
タイミングはかなり開発の後半になる。
担当:SE
※、不具合の修正はPGが実施
⑦システムテスト
負荷テスト、バックアップ/リカバリーなどの運用テストなど実施。
本番環境へのプログラム配備と確認もここで行う。
タイミングは、⑥と平行ぐらい。
アーキテクチャーとして性能が出ない構成になっていないかどうかというレベルの、
負荷テストはもっとまえに実施する。
担当:
※個別機能の担当者主体ではなく、アーキテクトなど主体となる。
⑧ユーザーテスト
最後にユーザーが受け入れのために確認を行うテスト。
担当:
ユーザー。
ただし、SEが最大限に支援を行い。修正はPGが行う。
2.どのように開発を支援するか
①徹底した標準化と、フレームワーク/ツールによる支援。
・設計書から、均質な動作をするソースコードを自動生成できるように
ツールを開発します。
・ツールでは100%自動生成は目指しませんが下記の方針として自動生成します。
・自動生成後に追加で手動で記述する部分と、自動生成部分は明確に分離して、
何度でも、設計書⇒ソースコード生成を行えるようにする。
これにより、設計書に修正が必要な変更が発生した場合は、
設計書修正⇒ソースコード修正の流れを維持できるようにし、
生産性向上とともに
「設計書とソースコードの乖離を最小限に抑えること」
「自動生成部分に変更があった場合も生成できること」
も狙う。
・設計資料も含めて、何箇所にも等価なものを記述する手間を省く。
例えば、HTMLで設計資料用の画面イメージを作り、実装用にはJSPを作成する
といった無駄も省けるようにする。
②上記を前提とした、設計/実装ガイド資料を作成
③上記を前提とした設計書テンプレートを作成。
レビューガイド/チェック資料なども作成。
④共通部品の提供
共通部品として提供できるものは一式そろえる。
⑤単体開発環境を提供。
・Eclipseに、プロジェクトに必要なプラグインを設定済みにして配布。
・SVN環境の整備。
-フォルダ階層の標準化やソースコード管理方法の整備も含む。
⑥結合テスト以降のテスト環境構築と、ライブラリ管理者への受け渡し方法の整備。
ここでいうライブラリ管理者は、リリースすべきソースコードの管理と、
障害解消の対応付けなどを行う人のこと。
どこまで人手を必要とするかは、考え方と環境整備の充実度による。
本wikiでは、「結合テスト」で使用するソース管理は、
開発者やサブシステムのリーダの担当とし、
「シナリオテスト」以降のテストで使用するソースは、
結合テストで合格したものを厳格な手続きでライブラリ管理者に受け渡して
管理する方法を想定する。
⑦自動テスト環境の整備。
単体開発者がJUnit、Selenium等による自動テストを実施できる環境を用意し、
かつ、テストソースもソースと一緒にSVN管理する。
テストケースの網羅性なども一定の指針を設けて、最低限のラインは確保する。
ただし、自動テストをやったら手動テストはしないというのではなく、
普通に手動で動作させての確認は自動テストと重複する内容でも1度は実施する。
結合テスト以降の環境では、毎日全てのテストソースを夜間自動実行し、
結果をフードバックして不具合は速やかに修正する。
⑧不具合修正/要件変更手順の整備
手順を明確にし、お客様と同意しておく。
(このぐらいにしておきましょう。)
2009-08-18T22:50:41+09:00
1250603441
-
システム概要サンプル
https://w.atwiki.jp/devstsample/pages/14.html
このwikiのメインではないのでここは非常にシンプルに書いておきます。
**システム概要
・数百人~数千人ぐらいで利用する、社内システム。
・海外拠点等はなく、さしあたり日本語のみ対応。
・日中はオンライン処理を実行し、夜間にはオンラインを閉局させバッチ処理を実行する。
・Webアプリケーションとし、IE6~8で動作することを求められている。
・DBMSはOracle11g。
・アプリケーションサーバーはTomcatのOSはLinx系。
・開発言語はJava。
・アプリケーションサーバは、ロードバランサーにより不可分散された環境下で動作する。
このぐらいにしておきます。
2009-08-12T00:16:49+09:00
1250003809
-
右メニュー
https://w.atwiki.jp/devstsample/pages/3.html
**訪問者数
|今日|&counter(today)人|
|昨日|&counter(yesterday)人|
|総合|&counter(total)人|
**更新履歴
#recent(20)
&link_editmenu2(text=ここを編集)
2009-08-11T23:18:19+09:00
1250000299