今日のこのブログの話題は、次のメルマガで書く内容についてです。
メルマガのほうは、次回は、外部設計の手順になります。
ということで、今日の話題は、外部設計の手順について。
要求仕様書が来たあとで行う作業として、外部設計ということになります。
この外部設計で行われる作業としては、プログラムのソフト／ハードの基本的構成の決定（フレームワーク決定）と、画面まわり、ＤＢ／ファイル周りの仕様決め、通信があれば、その通信まわりの仕様決め、そして、詳細設計に出せるまで、機能をおとしこみ、その機能間の入出力を決定することになります。
この、機能間の入出力決定が行われるからこそ、契約による設計やテストファースト、ユニットテストといった、最近ＸＰなどで取り上げられる概念が成立します。
もし、機能間の入出力決定がなされないとして、機能だけが決定していたら、どうなるでしょう。
入出力はでたらめになってしまいますので、ある機能と、ほかの機能がつながらず、作り直しになってしまいます。そこで、詳細設計に入る前に、各ユニット間の機能は決定していて、それは、テスト可能であり、そのテスト（ユニットテスト）が合格したら、各機能間が接続できるようにならなければなりません。
ということで、これらをまとめると、以下のようになります。
■■ 外部設計でやるべきこと
・ハード構成の決定
→ハードウエア構成図の作成（予算などの検討も）
・ソフトウエアの基本的な構成（フレームワーク等）の決定
→フレームワークの説明
・画面まわりの決定
→画面定義書の作成
・ＤＢ／ファイル回りの決定
→テーブル定義書、ファイル定義書
・通信など、その他の入出力まわりの決定
・機能の落とし込み
→インターフェース定義書など
そして、画面定義書とは、ユーザーの確認を取ります。
ハードウエア構成図は、作成後、ハードを導入することができるか、資金的、空間的、人的に検討します。
人的に検討というのは、そのような人材が見つかるあてもないのに、システムを作る危険がないかどうかの確認です。よくやってしまうのが、サーバーのお守りをする人がいないのに、２４時間稼動するＷｅｂシステムを構築してしまうとか、支店に、誰もコンピューターがわかる人がいないのに、そこにサーバーがあるとかです。
なお、外部設計と、詳細設計の中間あたりで、こんなことをします。
■■ 詳細設計前に行うこと
・共通で使う部分に関して、共通部分として切り出す
→共通部分の仕様と、利用の規約をまとめる
・命名規約などの決定
・フレームワーク利用規約のまとめ
・コーディング規約
・配置（javaでいうパッケージなど）
なお、共通部分というのは、ログのようなものはもちろん、一般的にＤＢの入出力や帳票出力・画面出力も共通化しますので、その部分もふくみます。これらは、最近はフレームワークに吸収されたり、Ｏ／Ｒマッピングに吸収されてしまいますが。
なお、そうすると、アスペクト指向の話？となるかもしれませんが、それよりも広い概念になるとおもいます。アスペクト指向の場合、業務の本質における部分の共通化というのを、アスペクトとして捕らえるかどうかは、意見が分かれると思います。
しかし、共通部分の作成の場合は、これは、共通化されます。
そうすると、業務の多くの部分というのは、
・チェックする
・ソートする
・マージする
・編集する
・どっかに書き出す（ＤＢ／帳票／画面）
程度の、簡単なものの組み合わせになってしまいます。そこで、これらのメソッドをあらかじめ用意しておき、詳細設計では、これらの機能を組み合わせていく形になります。
そして、これらの機能の入出力においては、契約による設計の議論を持ち出すまでもなく、確認できるためのログが入っているので、このログを追うことにより、詳細設計とプログラムの整合性が、確認できるように設計します。
やば、メルマガのレベルより、かなり高い内容になってしまった。
ちょっち、書き直さないと。メルマガ用には。。
アクセス
トータル
ランキング
