シリーズ化してしまった？修正可能なシステムです。
まず、ここで、何をやるかについて書きました。
そこにおける、要求仕様では、
（１）出力データに関して正規化して、エンティティを割り出す
（２）業務プロセスで、永続的に保存すべきデータに関して正規化して、
エンティティを割り出す
（３）それらエンティティを既存のエンティティに溶け込ます
（４）溶け込ましたエンティティを使って、各業務プロセスが、つながる
ということをやるということで、前回まで（３）をやりました。
今回は、（４）のプロセスについて考えてみたいと思います。
■データのまとめとプロセス
で、前回までで、（１）から（３）の作業で、データは、
・新規入力項目
・出力項目
ただ表示すればよいだけ
データを残す
既存のデータの修正・追加
新規データ
と分かれると書きました。
つまり、仕様変更のデータは、入力データと出力データにわかれるけど、
入力データに関しては、既存のもののほかに、新規入力データが必要になることもある。
（なお、書きもれましたが、既存のデータを修正（拡張する＝いままで英数字のみだったものを、漢字を許すとか）しないといけない場合もあります）
出力データに関しては、表示すればいいだけの場合もあるけど、データを残す場合もあり、データを残すときは、既存データを修正・追加する場合と、新規データの場合があると・・
つまり、もう一度まとめなおすと、保存すべきデータと保存しなくていい（画面から等の）テンポラリ入力や、テンポラリ出力にわかれ、保存すべきデータに関しては
入力 出力 既存データ修正 （あ） （い） 新規 （う） （え）
の４種類があることになります。
■プロセスにおいてやるべきこと
プロセスにおいて、修正可能にするためには、
・入力データをもとに、出力データが作り出せるプロセスになっているか、
シナリオを作って確認する
・既存のプロセスにどれだけ影響するか確認する
→できるだけ、影響がでないようにする
の２つの作業が必要になります。
■シナリオづくり
まず、今まで調べた、
テンポラリな入力データや、保存データをもとに、
出力データが、本当に作れるかどうか、
想定している修正・追加必要なプロセスの入出力を確認しながら
シナリオを作ります。
たとえば、日報を出していない一覧画面を作成する
ということになると、
出力データは日報一覧
この一覧画面は、
・日付、従業員、日報有無の●X
となっていると思います（部課名も入っているかも・・）
そうすると、日報有無の●Xは、テンポラリデータで、
日報テーブル中の該当日付、従業員レコードの存在で調べるので、
入力データは、
日報テーブル
従業員テーブル
（場合によっては部課テーブル）
検索条件（日付、部課、従業員）＝＞テンポラリ（保存するかも・・）
となります。
そうすると、プロセスは、
・日報一覧表示
は当然として、
・日報入力
・従業員入力（部課入力）
という機能がすでに存在し（なければつくる）
さらに、この前後関係は、部課→従業員→日報→日報一覧になる。
（データをおっていくと、これ以外のシナリオだと矛盾が出る）
というようなかんじです。
まあ、こんなに簡単なのだと、ここで矛盾がでることはないけど、
複雑になると、入力データがない！なんてこともあるので確認する
（たとえば、上記の例だと、日報の出している状況を１年間見たいが、
日報は、３ヶ月ごとにDBから消しているなどというケース。
→ふつう、この程度では、矛盾はないので、無理やり考えました）
で、ここで、矛盾が起こらないように、データを確定していきます。
■既存のプロセスにどれだけ影響するか確認する
まあ、上記のシナリオで、問題が起こるようだと、先行き
はあ・・・（－＿－；）
なんだけど、実際は、そんなことは少ない。
一番大きな問題は、（そして修正可能なシステムのメインテーマは）
この修正で、既存のプロセスにどれだけ影響が出るか？
という問題。
まず、さっきの図
入力 出力 既存データ修正 （あ） （い） 新規 （う） （え）
でみると、新規データの追加である（う）、（え）では、
それに伴い、既存プロセスを拡張する場合以外は、問題は起こらない。
（既存プロセスは、まだ見ぬ、新規データをアクセスしていないはずだから）。
問題は、（あ）、（い）の、既存データを修正してしまう場合。
この既存データの意味合いを変えてしまうと、問題が起こる
で、それの回避策などに関しては、今後の設計の話で、ここでは、
どのプロセスに影響が出るか・・だけを確認しておこう。
■確認方法
既存DBテーブルと、プロセスのCRUD図があれば、
直接的に影響を受けるプロセスは調べられる
（修正をうける既存テーブルに対して、CRUDしているプロセスが直接的な影響を受けるプロセス）
で、こーいうCRUDがない場合は、どうなるか・・
以下の前提がある場合
・DBアクセスしているクラスが１テーブル１クラスになっている
・１ファイル１クラスになっている（内部クラスは除く）
テーブルに対応するクラスが、プログラムソースファイル中に
存在するか（存在する＝CRUDのいずれかで利用）をgrepで調べれば
よい。
そーいう前提がないと（SQLをまとめていて、その定義からアクセスしている）
ちとめんどう。
■間接的な利用の確認
でも、直接的な利用はまだかんたん。
間接的な利用にともなう修正、つまり、
・DBデータの変更の影響により、返り値などがかわってしまい、
・その返り値を利用しているので、変更がおきる
はたいへん。
この場合、
・まず、「直接的な利用」で挙げられたクラスのメソッドが、
既存の入力データが修正されることにより、返り値に影響が
受けるかどうか確認し、
・もし、変更を受けるようなら、そのメソッドを利用している
プログラムを洗い出す
(grepで・・・（＾＾；））
・で、洗い出したプログラムが・・
既存の入力データが修正されることにより、返り値に影響が
受けるかどうか確認し、
：
（以下影響がうけないまでループ）
なーんてことを調べるツールがあるといいんだけど、
ないと手作業で調べるなんつーことは、やんないだろうから、
この辺があまくて、あとで、「うぎゃ」となってデスマーチになる・・・
ということで、要求仕様にかんしては、とりあえずおしまい。
次から、外部設計に。。。
アクセス
トータル
ランキング
