■ Java 詳細設計(内部設計)
・プログラミングが開始できること
・サブシステム内の機能分割
・処理概要の作成
UML、エクセル文書
・サブシステム内部の機能分割
・トランザクション管理
・大まかなクラス構成
・各サブシステムをプログラミングが可能になるまで設計する
・ドキュメント
・テーブル関連
・テーブル定義書
・ER図
・画面遷移図
・プログラムの詳細設計書
・処理内容
・ 補足資料としてアクティビティ図やフローチャート
・画面仕様書(画面フォーマット、項目説明)
・クラス図、シーケンス図 → すべては書かない、必要な部分
・SQL(考え方を書く場合とSQL自体を書く場合がある)
・テーブル関連
・テーブルは、プログラミングが可能となるまで、設計をする
・カラムの英字名、型、長さ
・主キー、外部キー
・プログラムの処理上使うカラム
・ER図、CRUD図もそれに応じて更新する
・ER図 ⇒ 非常に重要 → サンプル参照
・外部キーによるテーブル間の関係を示したもの
・システムの全体理解やプログラムの理解をするために使用する
・CRUD図 → サンプル参照
・CRUD(Create,Read,Update,Delete)
・各テーブルと各プログラムとの関係をマトリックスで表現したもの
・テーブルを変更した時に、どのプログラムが関係するかなどを判断する
・処理内容
・多くのドキュメントはエクセルで記述される
・現在では、あまり詳細な処理内容は記述しない、プログラマが理解することが前提
・内部データ構造については記述しないのが普通
・適宜、フローチャートやアクティビティ図などで、文章を補足する
・クラス図、シーケンス図
・クラスは、現実のシステムでは、最低でも数百はあるので、すべてのクラス図やシーケンス図は書けない
・クラス設計まで行わない場合も多い
・定数定義など
・種類
・テーブルで使用する定数定義
・プログラムで使用する定数定義
・他でも使用するので独立した仕様書となっている
・詳細設計と実装の作業分担の境界
・現在は、あまり詳しく詳細設計を行わずに、実装を行うことが多い
・理由には、以下がある
・あまり詳しく設計すると、誤りが入る可能性が多くなる
・実装で細かいことを決めてもらった方がよい
・実装者が内容を理解して実装できるようにする
・他の部分に影響がなければ、どのように実装しようが関係がない
・多くの場合、設計者は忙しく、そんな暇はない
・実際のありがちな設計書の構成
・処理概要
・使用するテーブル ⇒ テーブル定義は別書類
・画面項目 位置、長さ、DBとの対応
・処理詳細 - 文章が主、必要に応じて図表やUML
-----------------------------------------------------
・目次 Java システム開発
http://blogs.yahoo.co.jp/artery2020/40586660.html
・目次 - Java入門
http://blogs.yahoo.co.jp/artery2020/39975776.html
・目次 - ビジネスパーソンの常識と非常識
http://blogs.yahoo.co.jp/artery2020/39728331.html
・目次 - 論理・発想・思考についての考察と鍛え方
http://blogs.yahoo.co.jp/artery2020/39657784.html
-----------------------------------------------------