「標準ソフトウエア工学教科書」を作ってみたいと思います その１６ ３．４

土日シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は、詳細設計です。

---

■３．４　詳細設計（内部設計）

　前の工程である、外部設計で、以下のものが決まりました
　　・画面定義書
　　・ＤＢ定義書
　　・帳票定義書
　　・サービス定義書

　プログラム内部を決定する内部設計（詳細設計）では、
　　（１）まず、フレームワークを決めます
　　（２）フレームワークが決まると、どんなファイル、クラスを作るか
　　　　　決まってしまいますので、
　　（３）そこの部分を設計します。

以下、それぞれについて説明していきます。

---

（１）フレームワークの決定

　現在のプログラミングでは、
　　　・属人性の排除
　　　・生産の効率性
　　　・変更しやすさ
　などなどの理由から、フレームワークを使った開発が主流です
　（って、言い切っちゃっていいかなあ？）

　画面、ＤＢを使っている場合、ＭＶＣアーキテクチャやその変形に基づく
フレームワークを使うことが多いです。
　ＭＶＣとは、
　　画面部分（Ｖｉｅｗ）と処理＆ＤＢ入出力部分（Ｍｏｄｅｌ）、それぞれの
分離性を高めるために、この間に制御部分（Ｃｏｎｔｒｏｌ）を置いたものです。
　頭文字をとって、ＶＭＣ・・・ではなく、ＭＶＣ

　こうすると、画面と処理部分が分離されるため、画面はデザイナー、処理は
プログラマと別々の人が担当できる（のが理想だけど、そこまではうまくいかない）
のと、画面で変更があったら画面だけ修正、処理で変更があったら処理だけ修正と
いう具合に、修正を局所化できます。

　そして、このＭＶＣアーキテクチャ（やそれに似たもの）を実現するのが
フレームワークです。

　フレームワークには、主に

　　・画面と処理をつなぐ、コントローラー部分のフレームワーク
　　　　（Ｔ２，Ｓｔｒｕｔｓなど）
　　・処理（モデル）部分のフレームワーク
　　　　（Ｓｐｒｉｎｇなど）
　　・ＤＢアクセス部分のフレームワーク（Ｏ／Ｒマッピング等）
　　　　（Ｈｉｂｅｒｎａｔｅなど）　

　などに分かれているのですが、最近は、これらをまとめて、すべての機能を提供する
フルスタックフレームワークが流行です（Ruby on Railsなど）

---

（２）フレームワーク決定→作成物決定

　そして、フレームワークが決まると、何をどのように作ればよいかが決まってきて
しまいます。
　これは、フレームワークを利用する場合、ハリウッドの法則に従わないといけない
からです。

　ハリウッドの法則とは、

　　　私を呼び出すな、必要なら私から呼び出す

　というもので（ハリウッドの女優の、監督への売り込みをうるさく思った監督が、
女優にいうせりふらしい）、フレームワークを決定すると、書くところがきまって
しまい、そこしかかけません。

　たとえば、Ｓｔｒｕｔｓを採用した場合

　　・画面遷移などを書く、Struts-config.xml
　　・実際の画面をＪＳＰで記述（strutsタグ混在）
　　・データバインディングを行うActionForm
　　・データ処理を行うAction

　ぐらいしかかけず、かつ、書き方、内容もきまっています。

　そこで、フレームワークを選択すると、何を書けばいいかがきまります。

---

（３）各部分を設計

　そこで、フレームワークが求めるファイルを、外部設計をもとにつくっていく
ことになります。この段階では、実際にプログラミングするのではなく、クラス図
などを作ることになります。

　　・・・が、作っていってしまったほうが早いかも・・・

---

　実際のフレームワーク決定は、もっと早い段階の場合が多いと思います
　というのは、フレームワークによって出せる画面の限界みたいなのが
あることがあるからです。

　この内部設計までで詳細化はまず終わりで、以降の工程は(プログラミングや
ＳＱＬなどに）変換していく作業になっていきます、。