＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
初心者が教える「オブジェクト指向で設計する技法」
1
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-03-23 22:18
１．はじめに
オブジェクト指向の物件に一度も携わっていないド素人（はにまる）が 「オブジェクト指向の設計技法」を教えるという、 明らかに、頭のネジが２桁の数で抜けている事を証明する大馬鹿な企画です。 
注意１．素人が記述していますので読む際は、ご注意を。 注意２．当スレッドは設計：「オブジェクト指向」で設計する事についての派生スレッドです。 本当の狙いはこっちにあります。 注意３．考えながらの投稿ですので、投稿サイクルは遅い上、 編集が頻繁に発生し、前後関係が取れていない場合がありますが、ご了承下さい。 注意４．明らかに途中で挫折する企画です。 その際は「ギブアップ」と記述します。 注意５．返信はこちらでお願い致します。 注意６．設計自体の議論はこちらでお願い致します。 注意７．私は新人教育を担当した事がありますが、 教育機関で教育した事が無いので、うまく表現出来ていない事が多いと思います。 注意８．私はＣ／Ｓ系の基幹システムしかした事が無い為、そこに話が偏ります。 見方１．顔マークは、ＰＧの頃の私の意見です。 編集：注意７を追加（編集日時 2004-03-23 22:34 ） 編集：注意８を追加（編集日時 2004-03-25 18:49 ） 編集：見方１を追加 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-03-25 18:49 ] [ メッセージ編集済み 編集者: はにまる 編集日時 2004-03-25 21:38 ] | ||||||||||||||||||||||||||||||||
|
投稿日時: 2004-03-23 22:33
２．設計を設計する。（その１）
＜方針＞ 設計とは、自分の考えを周囲の人間が判る内容に書き上げ、 要求者へ対応手段を提示し確認を行い、 実装者へ対応手段を伝え作成してもらう事とします。 設計書が知識の結果であり、 設計書が知識の伝達媒体として考えた場合、 設計書のあり方からオブジェクト指向で考えると良いと思います。 教育対象者としては、ＰＧ（ＶＢ５）の頃の私に教える感じでいきます。 (1)まず設計書には一般的に何がかかれいるのでしょうか？ こんな所かな？
(2)ではＰＧのあなたが良く見かける設計ってなんですか？ これ位しか知りません。
(3)(1)で記述した設計書に掛かれている事は、 (2)で記述した設計書の全てに言える事ですね？ つまり、
といえます。 (4)それでは、それぞれの設計書には何がよく記述されていますか？ こんな感じでしょうか？
(5)こう見ると、各設計書にはＩＤと名称と目的がついていますね。 なので、こうしましょう！
(6)良く見ると、画面設計と印刷設計が良く似た項目ですね？ だって入出力の設計だからでは？
そうですねここには、ユーザインタフェースという概念があります。 ユーザインタフェースは、 御客様の要求をどの様に提供するか提示する資料となります。
つまりこうなります。 ＜あとがき＞ この様に自分が設計の行為で知っている僅かな知識を整理していくと 何故、その設計書が必要なのか、その設計書がどうあるべきか また、新たにどの様な設計が必要か判ります。 # 今は、とりあえず整理する事を記述しています。 設計書が、優秀な設計者の形式知となる様にしていくのが狙いです。 # 気長に見守って下さい。 (^^; 編集 (6)を修正して話を一旦終了。 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-03-25 18:52 ] | ||||||||||||||||||||||||||||||||
|
投稿日時: 2004-03-25 21:18
３．設計を設計する。（その２）
# ２．設計を設計するを編集しました。 (1)では、もうこれで設計出来るね？  そんな無茶な！入力画面の更新とか照会画面／帳票の出力って
何か訳の解らん話が何時もあって、、、多分設計出来ない。 それは、何時もプログラム個別で更新とか出力の話をするから 意味が分かり難いんだよね。 ある意味、ここが（はにまるにとって）既存の設計手法の弱点で 業務知識がＰＧや初級ＳＥに引継がれない問題だね。 だから、一旦、画面設計や帳票設計から更新仕様などを排除して 一般的に「業務知識」と言われる箇所の設計を別けて記述するんだ。
業務設計書で表す部分はビジネスロジックといわれる箇所で アプリケーション層（図：ユーザインタフェース設計） ビジネスロジック層（図：業務設計書） データ層（ＤＢ設計書） の３つに別けて考え、３階層アーキテクチャと言われるんだ。 ま〜、本当は厳密な定義づけがあるんと思うが．．． 今回は設計を考える際に別ければそれでいい。  ホントいい加減ですね．．．
(2)業務設計書は書ける？  業務設計書ってどの様に記述すればいいんですか？そんな設計書、見た事が無いし．．．
だったら、どんなのがいいか考えれば良いでない？ ホントいい加減ですね．．．
ん、あれ！それって、ＵＭＬが使えるんじゃ無いですか？
そうだね。如何にもオブジェクト指向というＵＭＬは今は、置いといて、 結構、業務の流れを記述するにはＵＭＬが利用し易いんだ。 おお、ではＵＭＬの話にいく訳ですね？
いや、業務の流れを書くのにＵＭＬが適していると言いたいだけ。 おい、おい
(3)では今まで黙っていたけど、テキスト操作の設計が無いよね？  あ、忘れていた。
ん、でもテキストを操作するプログラムってバッチもあれば画面もあるし、
入力とか、出力とか．．そういえばバッチ帳票っての聞いたことある。
こんなんで「設計書」の構成図って書けます？
いや、いや、整理仕切れないという事は、何か見落としているんだね。 正確に言えば、固定概念の元になっている考えを外して、 考える粒度を小さくするんだ。 つまり、今回は「設計書」では無く「設計」の単位に落して考える。
※根拠は全く無いが今の所は、入力／出力では別けない。 (4)実はさっきの図で「ＤＢ設計」を「テーブル設計」を 変えたのだけど、それはあるも設計を記述したいからなんだ。 結構、話の持っていき方が強引ですね。「テーブル関連図」の事ですか？
そうそう、実はここが重要なんだけど、「テーブル関連図」ってどんな設計？ そのままで、、、テーブルの関連を明示した設計？
「関連」を示しているものだね！大切なのは、１つ気付いたら、他に同じような考えが 無いか考える事なんだ、どう他にない？ あ、結構ありますね、「画面遷移」や「ジョブフロー」？
「画面遷移」と言えば、「メニュー画面」っを忘れていました。
そうそう、似たものを考える事によって抜けを防いだり、新たな考えがでるんだ。 「メニュー」と言えば、テキストとか帳票も画面から実行する事が多いから、 「操作画面」という言葉で締め括ろう。
| ||||||||||||||||||||||||||||||||
|
投稿日時: 2004-03-29 18:49
３．画面をオブジェクト指向で設計する（画面）
# 実際には設計を考える場合、後、「運用」、「管理」、「契約」 # 「インフラ」等の要素があるのですが、今回は一旦省きます。 始めてオブジェクト指向で開発をする事を考えた場合、 一番、効果が発揮し易いのが「画面」と「基本的な処理の流れ」です。 これは、画面や処理手段によって、昔からテンプレートが組まれている為、 そのテンプレートをクラス化すればいいからです。 うん、それは思った。
画面は、ざくっと記述すれば、この様に列挙出来ますが、 もし既存の別言語で存在する「テンプレート」が質素な場合、 そのままクラスを作るとスカスカにります。 その場合は、良く使う機能などを予め記述し、プログラム毎に特定機能を使う／使わない の選択を可能としておけば、オブジェクト指向の恩恵が受けれます。 なるほど。
あと「基本的な処理の流れ」の１例として「更新処理の手順」を考えた場合
となり、この流れからどうやってオブジェクト化するのか考えればいいと思います。 なんか、サブルーチンの単位ですね。
そうです。元サブルーチン（処理部品）の単位が確りした設計をしていれば、 ここもオブジェクト指向に移行し易い訳です。 しかし、今まで話を聞いている限り、オブジェクト指向で設計というのを感じませんが．．．
結局、サブルーチン＝オブジェクトでいいの？
そこは、 「メソッド（サブルーチン） → 御仕事」 「オブジェクト → 人」 「クラス → 各担当者の作業手順書」 で考えると解り易いと思います。 例えば、
これは、現実世界で担当者を決めて仕事をする時に、 「役割を決める」 「仕事依頼時の手順を決める」 「１回の情報提供で沢山の仕事をして欲しい」など 担当者のあり方とオブジェクトのあり方が似ているからです。 なるほど。何か因果関係がありそうですね。
ん．．．そこまで考えてない。 ．．．
ここまでは、既存設計の「おさらい的」な話、ここまでで言いたい事は、 既存の設計とオブジェクト指向の設計の基礎部分は一緒で、 既存の設計技法（特にモジュール分割）が確りしておけば、 オブジェクト指向に移行し易いという事です。 １．テンプレート化、部品化している組織では、オブジェクト指向の恩恵を受け難いが、 オブジェクト指向言語に移行し易い。 ２．部品化技術のレベルが低い組織では、オブジェクト指向言語で提供されている 各種部品やフレームワークで、その技術レベルの低さを補える。 ３．視覚的要素のある箇所、基本的な処理の流れは、オブジェクト化し易い。 と言えると思います。 あい。
ただ、今日の話は、あまり設計手段は変わりません。つまり、今日の話は、 「オブジェクト指向の設計」ではなく、 「オブジェクト指向の言語」の恩恵と 考える事が出来るます。 確かに．．．
では！次から言いたかった事の本題に行きますね。（多分．．．）  多分かよ！
[ メッセージ編集済み 編集者: はにまる 編集日時 2004-03-29 22:52 ] | ||||||||||||||||||||||||||||||||
|
投稿日時: 2004-03-31 20:03
４．オブジェクト指向で設計する。
４−１．はじめに 前回話をしたオブジェクト単位の考えた方は、 「擬人化」と言われる一般的な手法見たい．．． 何時の間にかに見た情報を暗黙的に記憶から引き摺り出したようです。 あらら、パクリですね。
いやいや、技術は基本的に誰かのパクリだから、気にしない、気にしない ま〜「擬人化」は置いといて、今回言いたい事は、ずばり 「オブジェクト指向で設計行為ををする」事。 ４−１．要件について 設計は「要望」と「制限」の影響を受け、 この「要望」と「制限」を一般的に「要件」と言います。 要件を考えた場合、下記の要件があります。（言葉は勝手につけている） １．業務要件 →御客様の要望 例：売上から請求書を作りたい。 製品単位で利益が出ているか知りたい。 ２．システム要件 →組織で明示されたベキ論／一般論、運用担当者／保守要員の要望 例：外部ＩＦは全てバックアップを取る。 内部エラーはテキスト若しくは、ＤＢに記録として残す。 ３．アプリ／インフラ要件 →言語／ツールが仕様提示している要件、物理的限界など 例：ＶＢ６だからマルチスレッド処理は出来ない。 容量的に３年間の情報は保持出来ない。 ４．暗黙要件 →設計者、組織で根拠が明示されていない、ベキ論／一般論 例：オブジェクト指向はｘｘｘｘするべきだ！ この処理はこうするのが普通だ！ ５．管理要件 →金、納期、メンバースキルなど 例：２０００万の予算で開発する。 新技術の摘要は今回出来ない。 今回の話として、５番は、実作業上の話ですので対象外とします。 要は、「４．暗黙要件」を１〜３の要件に持っていき、 最終的に「２．システム要件」として管理出来る状態にする事。 実際には、「４．暗黙要件」が完全に無くなる事は無く、 また、全てを上記の何れかに分類する事は出来ないが、 今、自分が設計している根拠はどれなのか？を意識する事によって 「４．暗黙要件」か「それ以外の要件」かを意識する事が大切なんだ。 :sweak:よ〜解らん。 そうだね、自分でもあまりパッとしない説明だなと思うが、、ここに答えがあると思う。 :sweak:おい、おい ４−２．ＤＢ設計をオブジェクト指向で設計する。 今回の「オブジェクト指向で設計する」をＤＢで説明するね。 え！画面じゃないの？
画面で説明すると、既存のオブジェクト指向の設計技法が邪魔して 言いたい事が伝わらない可能性があるからだ。 ま〜頑張ってくれ。
まず。ＤＢテーブルを基本的に構成する要素を挙げます
と列挙できます。 まず、軽〜いレベルから考える。 「キー項目」が何故必要か、どうあるベキか？ 「属性項目」が何故必要か、どうあるベキか？ 「更新履歴」が何故必要か、どうあるベキか？ ４−３．キー項目を考える。 結論からすれば、「キー項目」は、指定のテーブルからレコードを特定する為に必要な訳だが、 レコードを特定する訳だから 「キー項目」はシステム内部に取込まれた瞬間に内部連番を採番すると 業務要件の問題が無くなる訳で、開発者に優しくなる。 もし、ｘｘｘｘテーブルのキー項目は、ｘｘｘコードと行き成り考えたらそれは、 「４．暗黙要件」で設計しているから要注意。 ただ、内部連番で管理するのは、キー項目を２元管理する危険な行為とも取れる訳で、 安易に「はにまるの話」に乗るのは問題がある。 最初の話の通り、そのキー項目は何を元に決めましたか？と言う事を考える必要がある。 実例で話をすると、 「得意先コード」と言ってもそれが グループ企業／法人格／営業所／納品場所／請求送付書／発注送信所の どのレベルを現し、どれをマトメテ扱うのか考えないと、 システム開発の終わりになってマスタの管理手段について認識差が問題として発覚する。 また、伝票などでも、 伝票番号だけで主キーと考えると問題がある。業務に慣れしている人は、解っているが、 伝票番号とは、物理的な伝票と一致させる必要があり、 その伝票番号はどの様に採番されているか考えないといけない、 伝票番号は、使い切ると１から利用する事が習慣的に多く 伝票の発行場所が異なる場合は、採番管理が１元管理されていないから 「日付、伝票番号、発行管理単位」が主キーとなる。 この結果、３、４つの複合キーは危険と判断し、話を戻して内部連番を選択する事も有りだ。 主キーを、なめていました．．．
でも、どこがオブジェクト指向なんですか？
いい振りするね〜、流石は一人二役！ １．テーブルの概念 「テーブル」の要素である「キー項目」は、自動採番を基本とする。 ↓ （知識の継承） ↓ ２．得意先マスタの基本概念 「キー」項目は、「グループ企業、法人格、営業所、納品場所、請求送付書、発注送信所」の 何れか一つ若しくは複数のレベルで管理する。 ↓ （知識の継承） ↓ ３．当プロジェクトの「得意先マスタ」の概念 得意先マスタは、「法人格／営業所」単位で管理する。 と言う様にキーの設計根拠を「暗黙要件」から「業務要件」「システム要件」にするんだ。 これで、「設計根拠が設計」された訳だ。 「伝票」の例は、「得意先」の例より利用性が高くなり、伝票のキー概念が確定すれば、 売上／仕入／返品／値引・・と各種伝票にその概念を継承出来るんだ。 しかし、そこまで設計を求められたら、設計工程が終わりませんよ？
違う違う！１と２の知識を残す事が大切と言いたいんだ、 プロジェクトとしての設計書は３だけで良いし、特に問題が無ければＳＥにも３の話だけでいい。 不必要に情報を提供するのは管理上好ましく無いしＳＥも知った所で開発の際はメリットがない。 ただ、マスタ構成を御客様に確認する場合は２のレベルで一回確認した方がいいし、 今後、勉強熱心なＳＥの為に２の設計書が勉強資料となるから 時間との兼合いを見定め、組織的に「設計根拠の設計書」を作成していかないと洒落にならない。 ま〜、一生掛けて、一人で作成するのもＳＥ人生とも言えるかもしれないけど．．． でも、そもそも出来るの？今のアプリケーションで、そんな開発？
「設計根拠を設計する」際は、開発の話は除けて考える事が大切。 設計根拠をそのまま開発するのでは無く、 「アプリ／インフラ要件」により設計書に記述するレベルを定めればいい。 利用する言語やアプリケーションに縛られた設計をしていては、設計能力は上がらない。 逆に問題点や改善点を指摘出来る位になれば一人前だ。 一人前が遠い〜な〜。
| ||||||||||||||||||||||||||||||||
|
投稿日時: 2004-04-01 12:39
ギブアップ
私が、悪うございました... そして、このような意味不明なスレッドを総数７００回も 温かく見守って下さった方々へありがとうございます。 私成りの結論は、設計：「オブジェクト指向」で設計する事について に記述致します。 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-04-01 12:39 ] | ||||||||||||||||||||||||||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.