「astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみる」という、このシリーズ、以下の手順で説明する予定ですが、
（１）作るべきもののユースケースを書く
（２）ユースケースシナリオを書く
（３）ロバストネス分析
（４）バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
（５）バウンダリの項目を元に、画面構成を考える。
（６）(必要があれば）エンティティを正規化して、ER図にする
（７）フレームワークを決定する
（８）画面クラスをソースコードに書き直す
（９）エンティティをDBのテーブルと、DAOに書き直す
（１０）コントローラーを書き直す
前回、（４）をやったので、今回は、「（５）バウンダリの項目を元に、画面構成を考える」について。
■概要と位置づけ
前回、出力を元に入力を考え、入力から出力が出来ることを確認したわけです。
ということで、画面の入出力項目は、すべて出揃ったことになります。
ただし、項目が出揃ったというだけで、１つの画面に、物理的に全て表示できるかどうかわかりません。また、今まで非機能要件について考えていませんので、もしかしたら、とっても使いにくい画面になっているかもしれません。
ということで、ここで、画面を分割し、画面項目を振り分けていきます。
そして、それらの画面を、どんな順番で動かしていくかという、画面遷移を考えます。
この段階で、遷移上、必要な画面（ボタンやリンクをクリックして、画面表示するだけのメニュー画面など）も出てきますので、それを追加します。
つまり、この段階では、画面分割と画面遷移を扱うわけで、これにレイアウトを加えると、外部設計中の画面設計ということになります。
■画面分割
前回（４）まででは、ロバストネス分析をした状態なので、画面は、処理(ユースケース）に対して１つになっていると思います。
これでいい場合は良いのですが、画面が大きすぎる場合は、分割します。
この分割する際、なんらかの方針を持っているほうが、やりやすいし、操作性を向上させます
たとえば、「編集画面は、一覧を出して、詳細を出すようにする」とか・・・
新しい画面もクラスとして表現します。
項目が、属性となります。
ボタンをクリックしたり、何かを選択したりすると、JavaScriptだと、ファンクションを呼び出しますが、それら、
イベントはメソッドとして書き出します。
■画面遷移
そして、画面ができたら、画面遷移図を書きます。
画面を並べて、どんなイベントが起きたら、次にどの画面に飛ぶかを→で書くのが画面遷移図ですが、Astah*にはないので、とりあえずステートマシン図で代用します
状態（角丸四角形）を、１画面とします(画面表示状態とします）。
そして、→で遷移をあらわします。
ガードに条件を書くかんじ・・・
そんなかんじで画面遷移図を書いていきます。
このとき、起動するためのメニュー画面とか、認証するためのログイン画面とかが不足するので、追加しておきます。
■マスタメンテナンス
なお、不足する画面の中で、データベースにデータを入れる、マスターメンテナンス画面が必要になる場合があります（DBのツール等から直接データを入力するためにいらないこともあります）。
マスタメンテナンスは、ふつう各テーブルごとになります（受注と受注明細をあわせるなど、関連あるものをあわせてしまうことはある）。
画面構成は、
一覧選択画面：削除はこの画面から
詳細画面 ：編集、新規作成
の２種類、ないしは詳細画面は表示だけとし、
編集画面を別に作って、そこから、編集、新規作成する場合もあります。
また、検索画面というのを作ることもあります。
この、【一覧、詳細、（編集、検索）画面】ひとそろえで、１テーブル分という感じになります。
■このあと
画面レイアウトを作成することになります。
これはAstah＊では出来ないので、HTML作成エディタなどで作成します。
これら（画面構成＆画面遷移図＆画面レイアウト）をもとに、画面定義書を作成することになります。
アクセス
トータル
ランキング
