Accessを開発／自動生成ツールにして、システム開発する方法のメモ１ - ウィリアムのいたずらの、まちあるき、たべあるきーPART2

今やっている、シリーズオブジェクト指向で開発の最初から最後までの手順例のあと、Accessを開発ツールとして使って、同じように、サーブレットを自動生成する話を考えてみたいと思ってます。

　でもまだ、アイデア段階。

　で、おもいついたことを、とりあえず書いておいて見たいと思います

　つまり、自分用メモってことで、あとのシリーズで、まとめます

■要件設計部分
・データルートと業務フロールートにわかれる。
・データルートは、正規化して、テーブルを入力したら、リレーションにすれば、
　あと、リレーションを貼ると、ER図が描ける。

・業務フロールートは、アクティビティ図をとりあえず、
　　　アクティビティをボタン
　として、フォームに表現する。
　アクティビティの中に、詳細なアクティビティがあれば、
　アクティビティをクリックすると、その詳細アクティビティ図のフォームにいく

・詳細アクティビティ図でない場合、つまり、その業務を記述する場合は、
　フォームに、入力項目をいれ、表示項目ないしは、帳票をつくることになる。
　　→入力項目をいれて、出力項目を出す場合は、画面設計になる

■外部なの？設計

・画面設計
　上記の「入力項目をいれて、出力項目を出す場合」
　そのような画面作成をすると同時に、それに対応するクエリをかく。
　クエリの項目は、入力項目と出力項目
　入力項目は、条件のところに、画面項目の値で選択するように書かれる

・帳票設計
　帳票を出す場合も、クエリが作られる。
　クエリの項目は、入力項目と帳票に出力したい項目
　入力項目は、条件のところに、画面項目の値で選択するように書かれる
　出力項目は、並べ替えを使って、コントロールレベルを表現する。

■詳細＋コーディング＝自動生成
・テーブル情報から、Create Tableなどが作れる。
　そのテーブル情報を入手するには
　（つまり、現在作成してあるテーブルのテーブル名、項目などを入手するには）
　ADOXを使う。

　参考サイトは、ここ
http://www.accessclub.jp/ado/adox/index.html

・ボタンがコントローラーに対応する

・モデルは、いくつか考えられる
　　　１．クエリに対応させる
　　　２．コントローラーに対応させる
　　　　　　→１コントローラ１クラス
　　　３．フォーム（画面用）に対応させる
　　　　　　→１フォーム１クラス、ボタン分のメソッド
　２か３？

・Viewはフォームを出力する。
　横縦で整列させ、横は、小さい順
　たては、ある程度の誤差を認めて（グリッドレベル？）順に