今やっている、シリーズオブジェクト指向で開発の最初から最後までの手順例のあと、Accessを開発ツールとして使って、同じように、サーブレットを自動生成する話を考えてみたいと思ってます。
でもまだ、アイデア段階。
で、おもいついたことを、とりあえず書いておいて見たいと思います
つまり、自分用メモってことで、あとのシリーズで、まとめます
■要件設計部分
・データルートと業務フロールートにわかれる。
・データルートは、正規化して、テーブルを入力したら、リレーションにすれば、
あと、リレーションを貼ると、ER図が描ける。
・業務フロールートは、アクティビティ図をとりあえず、
アクティビティをボタン
として、フォームに表現する。
アクティビティの中に、詳細なアクティビティがあれば、
アクティビティをクリックすると、その詳細アクティビティ図のフォームにいく
・詳細アクティビティ図でない場合、つまり、その業務を記述する場合は、
フォームに、入力項目をいれ、表示項目ないしは、帳票をつくることになる。
→入力項目をいれて、出力項目を出す場合は、画面設計になる
■外部なの?設計
・画面設計
上記の「入力項目をいれて、出力項目を出す場合」
そのような画面作成をすると同時に、それに対応するクエリをかく。
クエリの項目は、入力項目と出力項目
入力項目は、条件のところに、画面項目の値で選択するように書かれる
・帳票設計
帳票を出す場合も、クエリが作られる。
クエリの項目は、入力項目と帳票に出力したい項目
入力項目は、条件のところに、画面項目の値で選択するように書かれる
出力項目は、並べ替えを使って、コントロールレベルを表現する。
■詳細+コーディング=自動生成
・テーブル情報から、Create Tableなどが作れる。
そのテーブル情報を入手するには
(つまり、現在作成してあるテーブルのテーブル名、項目などを入手するには)
ADOXを使う。
参考サイトは、ここ
http://www.accessclub.jp/ado/adox/index.html
・ボタンがコントローラーに対応する
・モデルは、いくつか考えられる
1.クエリに対応させる
2.コントローラーに対応させる
→1コントローラ1クラス
3.フォーム(画面用)に対応させる
→1フォーム1クラス、ボタン分のメソッド
2か3?
・Viewはフォームを出力する。
横縦で整列させ、横は、小さい順
たては、ある程度の誤差を認めて(グリッドレベル?)順に