- PR -

詳細設計について

1
投稿者投稿内容
oki
ベテラン
会議室デビュー日: 2004/12/18
投稿数: 55
投稿日時: 2005-09-21 23:35
いつもお世話になっております。

Javaの詳細設計について疑問があります。

UMLのクラス図やシーケンス図等だけで
PGは実装できるのか？という疑問です。

特に複雑なビジネスロジックを持つクラスについては
クラス図やシーケンス図だけでは
実装が難しいのではないかと思っています。

皆様はどのように詳細設計を行っているのでしょうか？
その方法や詳細設計書の雛形、参考になるURLなど
ご教授お願いできれば幸いです。

よろしくお願い致します。

以上


[ メッセージ編集済み 編集者: hoho 編集日時 2005-09-21 23:48 ]
さる
ぬし
会議室デビュー日: 2005/07/14
投稿数: 276
お住まい・勤務地: 実家戻ったｗ
投稿日時: 2005-09-22 00:01
引用:

hohoさんの書き込み (2005-09-21 23:35) より:
UMLのクラス図やシーケンス図等だけで
PGは実装できるのか？という疑問です。

出来ません。

引用:

特に複雑なビジネスロジックを持つクラスについては
クラス図やシーケンス図だけでは
実装が難しいのではないかと思っています。

難しいではなくて不可能ですね。

詳細設計ってどのレベルからが詳細設計としていますか？
oki
ベテラン
会議室デビュー日: 2004/12/18
投稿数: 55
投稿日時: 2005-09-22 00:25
ご返答ありがとうございます。

引用:

詳細設計ってどのレベルからが詳細設計としていますか？


ご指摘の通り、どのレベルからが詳細設計なのか？という
定義の曖昧さが今回の疑問を生んでいるだと思いますが
さるさんは、どのレベルからが詳細設計としているのでしょうか？
また、クラス図やシーケンス図は、どのレベルに位置づけしているのでしょうか？

質問攻めで申し訳ありませんが
よろしくお願い致します。

以上

[ メッセージ編集済み 編集者: hoho 編集日時 2005-09-22 00:30 ]
さる
ぬし
会議室デビュー日: 2005/07/14
投稿数: 276
お住まい・勤務地: 実家戻ったｗ
投稿日時: 2005-09-22 00:48
俺の場合なら、
クラス図とシーケンス図は完全ではないのを基本設計で作って
詳細設計では完全な物ですね。
(まあ、仕様変更やら修正やらはあるとは思いますが)
ユースケースだったらは基本かな？

Webアプリ系が多かったのでWebアプリと仮定して、

基本設計で作るべきだと思ってる物
デモHTML(顧客確認済み)
画面項目定義書(後で修正ありレベル)
DB定義書(後で修正ありレベル)
ユースケース図
プロトタイプのクラス図(アキーテクチャ？)
一番簡単な処理のパターン毎のシーケンス図(アキーテクチャ？)
いわゆる日本語の基本設計書。

詳細設計で作るべきだと思ってる物
仕様変更以外の修正がない画面項目定義書(入力・出力・hidden項目)
仕様変更以外の修正がないDB定義書
ER図
シーケンス図
いわゆる日本語の詳細設計書
SQL一覧(なくてもOK・メンバーのレベル次第)
以下の二つを実装した単純なソース
　プロトタイプのクラス図(アキーテクチャ？)
　一番簡単な処理のパターン毎のシーケンス図(アキーテクチャ？)

こんなもんでしょうか？
なんか抜けてる気がするけど・・・眠いからこれで良いやｗ
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2005-09-22 03:27
るぱんです。

クラス図とシーケンス図だけでプログラムは作れないと思います。
というか・・・UMLの図ってメモ程度のものでは？
正式に採用している所もありますが・・・。

メモ以上にこって作るのであれば、
その分余計なコストがかかると思います。

主要部品のI/Fとその引数と戻り値を明確に定義するだけの方が
よっぽど生産性が高いと思う。

僕が考える基本設計は
アクティビティ図（業務フローレベル）
プロトタイプDB（旧バージョンなど）
サイトマップ
遷移概要図（→コンポーネント図）
モックアップ
テストシナリオ
かな？

詳細設計だと・・・
１ボタン１アクションの設計書
そのアクション一覧
画面遷移図詳細
画面項目定義（画面表示定義）
ER図、エンティティ定義書
単体テスト項目設計書
帳票・ファイル・メール各定義書
他システムとの連携部分のI/F定義書

SQLは・・・一覧にする意味が無いかな？
共通で使いまわすものだけ別にこしらえるけど、
基本的には１ボタン１アクションの設計書に含めたらそれで終わりかな？
エラー、メッセージ周りもアクションの設計書に含めるかな？

クラス図は、詳細設計書いている人たちの間の意思疎通のためのメモかなぁ？
I/F周りでしか使わないけどなぁ？

シーケンス図は、設計書を書きながらプログラム書くときに
頭の整理目的で使ったり、
できない人に教える為に使うかな？
やっぱり、メモ程度。

でも、複雑な所はそのメモを後でキレイにして別紙参照扱いで
納品対象に含めるかな？

DB項目の雛形をクラス図で起こす人いるけど、
僕は、モックアップから起こすかな？

やってることは一緒なんだけど、
エクセルでソートすると、
どのテーブルのどのカラムはどの画面と紐ついているか
一発でわかるからそっちの方がありがたいかな？

あとで検証掛けられるし。
flatline
大ベテラン
会議室デビュー日: 2005/09/22
投稿数: 102
投稿日時: 2005-09-22 09:35
flatline と申します。

ぼくの場合は、
1.業務フロー作成
2.ユースケースと用語辞書作成
3.ロバストネス分析
4-1.外部設計
4-2.クラス設計
4-3.エンティティ設計
5.テストケース作成
6.実装
という流れです。4-1. 以降を詳細設計フェーズとしています。
あくまで便宜上ですが。
いわゆる詳細設計書みたいなものは作っていません。ソースと
同期を取るためのコストが非常に高いし、後で読んでも役に
立たないことが多いので。そのかわりソースの可読性とクラスの
粒度に注意しています。

ただし、ぼくの場合、比較的小規模な社内システムを少人数の
チームで開発しているので、上記のような方法を取っていますが、
数10人〜100人以上の大規模開発では、進捗度があいまいになる
かもしれません。また、成果物としての詳細設計書が必要になる
こともあるでしょうから、万人向けではないとは思います。
参考までに。
Lichtenstein
ベテラン
会議室デビュー日: 2003/11/06
投稿数: 61
投稿日時: 2005-09-22 09:44
出来るか出来ないかなら……　出来ますよ
誰も知らない記号が、クラス図に溢れることになりますが。

現実的には、ビジネスロジックと呼ばれるものの文書は、
人様が臨機応変に作るしかないと思います。
さる
ぬし
会議室デビュー日: 2005/07/14
投稿数: 276
お住まい・勤務地: 実家戻ったｗ
投稿日時: 2005-09-22 15:24
引用:

さるさんの書き込み (2005-09-22 00:48) より:
こんなもんでしょうか？
なんか抜けてる気がするけど・・・眠いからこれで良いやｗ


あっ、思い出した。
詳細設計で開発環境構築の手引き
これで開発できる(はずｗ)

テストってのもあったけど・・・
本当は詳細設計には出来てて欲しいけど現実的に考えて仕様変更ばっかりくるとねぇ〜ｗ
いちいち修正施すの面倒だから
基本設計書に項目追加でブラックボックス。
詳細設計書に項目追加でホワイトボックス。
てな具合で考えるでテスト仕様書は後回しかな。

引用:

SQLは・・・一覧にする意味が無いかな？
共通で使いまわすものだけ別にこしらえるけど、
基本的には１ボタン１アクションの設計書に含めたらそれで終わりかな？
エラー、メッセージ周りもアクションの設計書に含めるかな？

SQL一覧にするのはDBチーム(DB設計からADO作成までする所)に引き渡すからかな。
そういうチームも個人もなければ不要。
ある程度精通してる人がいるならそちらに一任した方が
下手にみんなに触らせるよりかマシになるし。

#　昔テスト仕様書が設計書だったプロジェクトあるな。
#　あれはあれで楽だったかも。
1

スキルアップ／キャリアアップ（JOB@IT）