シリーズ化してしまった？修正可能なシステム。
前回は、概要として、何をやるかについて書きました。
本来なら、その説明をするべきですが、その前に、どこが問題で、このような手順になっているのか？という背景の話をします。
■データに関する修正をかける場合
問題は、データ構造に対して、削除、あるいは意味が変わったり、型が変わったりする修正で起こります。
（価格を、整数から実数へ、文字２バイトを１バイト、有効期間項目をなくすなど・・）
この場合、修正後のプログラムを作るには、まず、データの構造を修正しないといけません。
とくに、データ構造に追加がある場合、追加しないと、プログラムが作れないので、追加します。そうすると、同時に項目を変えないといけない場合（つじつまが合わなくなるので）、削除や、型をかえるなどということもします。
そうすると、今度は、既存のプログラムで、修正未対応のものは、既存のデータが来ると思っているので、おかしくなります。
つまり、修正をかけるためにデータを更新すると、まだ未対応のものがおかしくなるし、
未対応のものに対応してもらうまで待つと、修正をかけるプログラムがそれまでつくれない。
とくに、プログラムAは、Xテーブルに対しては、新規構造で修正なんだけど、Yテーブルに関しては既存テーブルの対応、プログラムBがその逆というときはこまってしまいます。
■そこで、スタブをいれるけど・・
そこで、スタブ（ダミーモジュール）をいれて、新規構造で値がかえってくるようなものを作っておけば、よさそうですが、というか、そうしてますが、これだと、新規構造に対応しなければいけない人が、もれる可能性があります。
ダミーモジュールで開発している間はいいのですが、いつまでもダミーというわけには行かないので、どこかで、ダミーでないものにします。そーなったとき、急に構造が変わるので、漏れた人は、そこで気がつき・・ぎゃーということになります。
■であれば、
であれば、昔の構造で見ている人には、昔の構造のまま、
新しい構造で見ている人は、新しい構造で
見えれば、いいわけです。
そのへんのくふうが、＜＜外部設計部分＞＞でおこなわれています。
また、このような漏れを減らすため、＜＜要求仕様部分＞＞では、１事実１箇所になるようにしています。
ってなわけで、きょうはここまで。
アクセス
トータル
ランキング
