「astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみる」という、このシリーズ、以下の手順で説明する予定ですが、
（１）作るべきもののユースケースを書く
（２）ユースケースシナリオを書く
（３）ロバストネス分析
（４）バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
（５）バウンダリの項目を元に、画面構成を考える。
（６）(必要があれば）エンティティを正規化して、ER図にする
（７）フレームワークを決定する
（８）画面クラスをソースコードに書き直す
（９）エンティティをDBのテーブルと、DAOに書き直す
（１０）コントローラーを書き直す
前回、（２）をやったので、今回は、「（３）ロバストネス分析」について。
■ロバストネス分析とは
ロバストネス分析の説明は、ここにあるとおり。
つまり、MVCみたいに、システムを
バウンダリ：ユーザーとの入出力
コントロール：バウンダリとエンティティをつなぎ処理する
エンティティ：保存すべきデータを管理しておく
の３つにわけます。
このバウンダリ、コントロール、エンティティは、３つの層と考えられ、
・同じ層の間
・お隣さんとの層の間
とは、やりとりできますが、
・間を離れた層の間
では、やりとり「できません」
つまり、バウンダリから、エンティティには、アクセス「できません」
これを、コミュニケーション図という形にまとめるのが、バウンダリ分析です。かんたんにいっちゃうと・・・
■本日のミッション
したがって、今日やるべき、ミッションは、前に書いたユースケース
とユースケースシナリオをもとに、バウンダリ分析をして、
なコミュニケーション図を作ることです（上記例は受注のみ）。
■作り方
（１）ユースケース図は、コンピューターに「処理させたいこと」を書いているはずです。
ってことは、これは、処理＝コントロールになります。
ってことで、各ユースケースを「～処理」という形にして、
迷わずコントロールにしましょう。
例：ユースケース：受注する→受注処理(コントロール）
（２）ユースケースシナリオを見てください。それに、画面入力・画面出力はありますか？
あれば、「～画面」として、バウンダリを書きましょう（～はユースケース名）
帳票も出力するのであれば、帳票のバウンダリも作ります。
例：ユースケース：受注する→受注画面（バウンダリ）
（３）引き続き、ユースケースシナリオを見てください。
画面から入力されたもの＋保存されているデータを元に、
何らかの処理をして、
画面、帳票、保存すべきデータに出力
しているはずです。このとき、保存されている、すべきデータがエンティティとなります。
エンティティはたいてい名詞ですが、名詞が全てではなく、
ひとつひとつが区別して、管理できるものです。
なにかと、一緒になっていているようなものは、属性です
（「なにか」が、エンティティかも？）
ってことで、ユースケースシナリオの名詞に着目し、
・保存すべきデータで
・ひとつひとつ区別でき、管理すべきもの
をエンティティとしてあげて、記述します
なお、処理をしたり、保存しなくてよいデータを作成している場合、
それはコントロールです
他のユースケース名でなく（コントロールになることなく）、
重要で、かつ独立したものは、コントロールとして挙げておいていいです。
→挙げなくてもいいです。当コントロールクラスのメソッドにしますから・・・
（４）今書いた、コントロール、バウンダリ、エンティティに線を引きます。
バウンダリ － コントロール － エンティティ１
－ エンティティ２
：
のような感じで、線が引かれると思います。
（５）メッセージを記入します。
ユースケースシナリオが、ここに書くことを意識している場合は、
たぶん、ユースケース１つ１つをぺたぺた貼ればいい感じだと思います
（Enterprise Architectのシナリオなどの場合）
こんでできあがり。
受注画面とか、めちゃくちゃ大雑把！と思うかもしれないけど、
とりあえず、これでいい。次回、詳しく書きます。
アクセス
トータル
ランキング
