読者です 読者をやめる 読者になる 読者になる

Teeda Extension featuring Goya 〜外部設計〜

Seasar2 Teeda

要件定義→外部設計→(アーキテクチャ)→内部設計→コーディング→単体テスト結合テスト

工程の位置づけ

システムがユーザに提供するものを定義します。

  • システムの振る舞いとして、ユーザレビューを行うもの
  • 内部設計以降の工程でプロジェクトメンバが増えることを前提として、インプットとして決定しておくべきもの

という観点で、標準(?)のGoyaでは含まれていませんが、DB設計もこの工程に含めています。

成果物

  • 業務機能一覧
    • 業務ごとに、システムの役割の概要を書く。
  • 画面遷移図
    • 業務フローから、画面遷移図を書き起こす。
  • UIスケッチ
    • 画面の構成を決定する。入力/表示項目、ボタン/リンクのみを記述し、デザインにはこだわらないように注意する。
    • 業務フローに沿って、ウォークスルーを実施。漏れ/不要/修正箇所を洗い出す。
  • 画面項目説明
    • 項目の仕様として、説明/初期値/バリデーションルールなどを記述します。DB設計が完了したら、対応DBカラムも記述しておく。
  • 操作シナリオ
    • 画面の操作説明を書く。ユースケース詳細を書いても良いが、ユーザは分からないことがほとんどなので、お薦めしない。
    • 画面やログに出力するメッセージも決めておく。
  • 処理レシピ
    • システムで、複雑な処理を行ったり、他システムと連携したりする場合は、操作シナリオとは別途、処理内容を書く。
  • UIモック
    • UIスケッチをもとに、HTMLモックを作成する。
    • Teedaでは、HTMLのタグにidを割り振ることが必要となるが、id自体は内部設計で決めれば良い。ただし、ボタンと表示/非表示を切り替える部分については、idを決めておく。画面遷移情報と関連するため。
  • DB設計
    • UIスケッチをもとに、入出力項目を抽出し、テーブル設計を行う。


※2007/03/10 画面項目説明を追加。

Tips for Teeda

  • 画面遷移の処理
    • 他画面への遷移だけでなく、自画面遷移(PostBack)の処理も考慮しておく。Teedaは、画面の入出力値をサーバ側のPageクラスで1:1で保持するので、表示を更新する/しない項目を明確にしておく必要がある。
  • UIモックの作成
    • 画面遷移は、ボタンのonclick属性で「location.href='xxxx.html'」と書いておき、JavaScriptで処理する。ボタンのidが「go〜」「jump〜」「do〜」となっている場合はTeedaが無視してくれるため、モックの場合だけJavaScriptで遷移するようになる。
    • 表示/非常時を切り替える部分については、「div id="is〜"」「div id="isNot〜"」と書いておき、モック作成時点で両ケースを表示できるようにしておく。さらに、「is〜」「isNot〜」それぞれにclass属性を指定しておき、JavaScriptをモック用に作成して、そのclass属性を持つdivタグの表示/非表示を切り替えるようにしておく(behaviour.jsを使うのがお薦め)。実際に動作させるときは、そのJavaScriptを動作させないようにしておけば、モックと実際の動作を簡単に切り替えられる。
    • モックの場合のみ表示させたい項目がある場合は、idを「mock〜」とすることで、実行時には表示されなくなる。
  • DBのカラム名の付け方
    • 全テーブルで一意になるように付けておく。
    • ほぼ、HTMLのid=DBのカラム名となるが、Empテーブルのnameカラムと、それに関連付くDeptテーブルのnameカラムを、同時に表示させようとしたときにバッティングしてしまうため。
    • Dxoの処理で、id名とカラム名のマッチングを変更することも可能だが、それだけ手間も増え、バグがあっても見つかりにくくなるので、制約が無い限り止めておいた方が良い。