設計
何かの設計じゃなくて普通の設計の話
まず設計作業のゴールを定義する
- 情報の状態とその流れが決まっていること
- ユーザが特に気にする一部の画面が設計されていること
- 帳票が設計されていること
- 外部連携が設計されていること
- データ移行が設計されていること
この状態になればプログラムにいける
＃普通の業務システムでもこれくらいで大丈夫なので一番最初以外はそんなに変わらない感じ（ｗ
で、設計の順番としてこんな感じになる
- 情報の抽出
- 状態と流れの把握
ここからは並行作業OKで
- 帳票・外部連携の設計
- 一部画面の設計
- データ移行の設計と計画
一番大変そうに聞こえる情報の抽出は
これでたいていの場合はOK
状態と流れの把握も案外簡単で基本はこれだけ
- その情報は誰が最初に書いて誰にいつ渡しているのかを情報が変化するか片付けられるまで一連の流れを把握する
ちょっと難しいのはここから
大抵の情報はそれほど変化しないのでそのままシステムに乗せれば良いんだけど・・・
理想的なシステムがほしい場合は要望が非常にふくらむ事が多いし、状態と流れの把握が複雑になったり、情報量が大きくなったりする
これをある条件に収まるようにがんばって切り刻む
条件は状態数が10を超えないこと。これだけ
もちろん、超えないと無理な場合あるけどそれは吟味の上例外とする事
この結果として情報もばらばらに切り刻まれるのでそれも一緒にやる
それと同時に上位の状態を追加する必要がある事もあるので必要なら追加する
ここまで終わると情報と状態とその流れの俯瞰図でも詳細図でもなんでも作れるはず。
あとはそれまで聞いてた話から帳票や特殊な画面やデータ移行を設計する
この流れで作ると帳票とか特殊な画面の設計では状態がどんな風に管理しているのかを考える必要はないので、比較的さくさく作れるはず。
データ移行に関しては旧データに状態が足りなかったりフラグをどういう風にどの状態と見なせばいいのかがポイントになるはず。あとは不足してるデータの初期値等々が必要だと思うけど、これは一般的な話
こんな感じで情報と状態の管理をはじめからきっちりやることで設計工程はかなり楽になる。
ちなみにこの方法は別にジェネレータとか関係なく普通の業務システムの話。
Web+DB PressのVol.19の頃に既にちょっとだけ触れてるし、実際にはぶりとか関係なく10年くらい前には原型があったから（ｗ
最後に情報をERDにすれば良いんだけど、まぁジェネレータががんばってERD作れば良いんじゃない？ってよく思う
