まえに、
業務と情報処理試験の関係を、午後の問題から考える（要求仕様編）
というのを書いたけど、あした情報処理試験だそうなので、その続きでも書くかにょ。
題材は、基本情報２１年秋、午後の問５。
このシステムを作るとしたらどうなるか？
出題と、どこでどう関係してくるか・・・について書いてみていて、
前回、
・まず、業務を出してくる方法としてユースケース図
・その業務の関係者と手順を考えるアクティビティ図
・業務で出力する帳票・画面などから、正規化して、ＥＲ図
を書いた。
今回は、外部設計がらみで、シーケンス図、クラス図、ステートチャート図について。
■外部設計、機能設計
要求仕様のあとは、外部設計や機能設計ということになる。
情報処理は、「情報」である、データの構造を、「処理」であるプロセスによって、変換する作業であるといえる。
その「情報」と「処理」は、
「情報」である、データの構造→ER図→モデル部分クラス図
「処理」であるプロセス→ユースケース図・アクティビティ図→★
★：シーケンス図、ステートチャート図、流れ図→画面遷移図
という形で要求仕様から外部設計につながっていく
以下、それぞれについてみていく。
■データ構造の表現１：モデル部分クラス図
ER図で記述したエンティティはテーブルになる（大体原則）。
それと同時に、エンティティはクラスとしても表現できる。
１エンティティ１クラスみたいなかんじ。
これが、データ部分のクラス図になってくる。
たとえば、ER図、
は、基本情報２１年秋、午後の問５の２２ページのクラス図と、同じ感じだ。
ちがいは、ER図の場合、関連を主キー―外部キーの関係で表現するため、この項目が入っているのに対し、クラス図は関係を、たんに線を引くことで表現するので、その項目（属性）がないくらいかな・・
O／Rマッピングによって、エンティティ（R)とクラス（O)を多少変えて、しかしマッピングの関係にすることもできる。ただ、私の経験から言うと、そんなに変えないほうがいい。そして、複数クラスにまたがる操作は、サービスとして、それ自体を１クラスとしてしまったほうが、きれいにまとまる。
■データ構造の表現２：入出力部分レイアウト→クラス図
外部設計としては、DBに保存するだけでなく、帳票や画面の設計もしなくてはならない。
このような、入出力部分、MVCでいうと、ビューの部分は、帳票、画面の場合、レイアウトを記述することによって行われる。
このビューの項目と、DBとの対応は、ER図作成の時の正規化で確認されている。
そこで、これらの項目を、どのように表示するか、レイアウト図が書かれる。
このレイアウトの項目も、クラス図にできる。
基本情報２１年秋、午後の問５の２５ページ図３の左側がそれにあたる。
これは、出題のため、へんなふうになっているが、何も書かれいない属性のところは、本来、画面項目が書かれ、そのあとのメソッド部分は、ボタンなど、イベントを起こすものが該当する。
つまり、MVCモデルのMとVの構造はクラス図で表現でき、それをどう結び付けるかが、以降の「プロセスの表現」によって示される。
■プロセスの表現：シーケンス図、ステートチャート図、流れ図
プロセスの表現の仕方としては、以下のようにしたほうがきれい。
・場合分けが少なく、手順が決まっている場合
シーケンス図に表現するといい
・前後の遷移は決まっているが、全体の手順は決まっていない
ステートチャート図がいい
・場合分けが多くが手順は決まっている
業務流れ図を洗練させる。いきなり画面遷移図に行ってもいい。
以下、とくにシーケンス図を細かく見ていく（試験に出てるのがシーケンス図なので）
●プロセスの表現１：シーケンス図
場合分けが少ない場合は、シーケンス図で表現すると表現しやすい。
前回書いた、要求仕様のアクティビティ図は、
なかんじだった。シーケンス図
（基本情報２１年秋、午後の問５の２４ページ）
のアクターは、このアクティビティ図のスイムレーンになる。
今回は、アクティビティ図の販売担当者が、シーケンス図のアクターになっている。
★だから、
・アクティビティ図のスイムレーンというかロール
→ シーケンス図のアクター
にマッピングされ、さらに
・アクティビティ図のアクティビティ
↓
シーケンス図のアクターが送信するメッセージ
↓
画面のクラスの「メッセージ」
という関係になっているわけ。
★そのうえで、クラスとシーケンス図の関係は、
◎JAVAのクラスがシーケンス図の上のところに表現されている場合
・シーケンス図で、「呼び出されるほう」（→の矢のほう）のクラスに
そのメソッドがあり、
・呼び出し側のメソッド（→の元のほう）内で、呼び出し側（→の矢のほう）
のメソッドを呼んでいる。
★具体的に言うと、
航空券発券画面のメソッドの中には、→の矢のほう、つまり、
・出発日時、出発地および到着地となる空港名、便名、グレード、人数、席種を入力し、発券可否を確認する
・発見可否を表示する（自分の中から出て、自分の中に入っても、矢があれば、そこにメソッドはある）
・座席を確保する
・顧客情報を登録する
・航空券を発券する
というメソッドがあるはずで、そのうち、「出発日時、出発地および到着地となる空港名、便名、グレード、人数、席種を入力し、発券可否を確認する」メソッドの中では、航空券発券管理の
・ｄ
・発券可否を表示する
というメソッドを呼び出している。
と読み込める。
★シーケンス図は、このように
アクター→ 画面クラス→・・・→モデル部分のクラス
（設問ではC,顧客、航空券）
というふうに画面のボタンなどで発生させるイベントとクラスのメソッドの関係を表現できる点はメリット。
★ただし、IF文を表現できないというか、かりに表現できたとしてもぐちゃぐちゃになっちゃうので、場合分けが必要だったら、別のシーケンス図を書くことになる。そーすると、場合分けがいっぱいあると、いっぱいシーケンス図になってしまい。。そんなら、流れ図のほうが、よくね？ということになる。
また、手順が決まっていなかったら、これは書けない。
たとえば、ケータイ電話の操作など、何をやりだすかわからない。でも、前後の流れは決まっている。
このようなときには、ステートチャート図を書くことになる。
★なお、ここまでの話は、Javaのクラス図をシーケンス図で表現した場合で、シーケンス図は一般に他に、通信プロトコルを表現する場合がある。
この場合は、
クラスではなく、サーバー(など）となり
呼び出される→の矢側に、受け取り手（サービス、デーモンなど、ワッチしてるもの）があり、元のほうから、矢のほうにメッセージを送る。
双方向に矢がいている場合は、結局、送受信両方の機能が必要になる。
●プロセスの表現２：ステートチャート図
前後の遷移は決まっているけど、全体の流れが画一的でない（何回も同じことしなおしたり、急に違う機能を使ったりとか）場合は、ステートチャート図のほうがうまくいく場合もある。
ステートチャート図（オブジェクト指向でない場合、状態遷移図）は、
平成１７年春期 ソフトウェア開発技術者 午後I 問２ ７ページ
などにある。こんなかんじで、イベントと状態を表す。
イベントと状態であって、入出力との関係を表現しないことから、ビジネス用としてより、組み込み用として使われることが多いんじゃないかな？
●プロセスの表現３：流れ図など
場合分けが多い場合などは、業務流れ図を普通の流れ図で書き換えたり・・ということも考えられる。ただ、そんな図を作らなくても、画面遷移図には落とせるので、直接画面遷移に行くことも多いんじゃないかな・・・
ってなかんじ。次回は、画面遷移図、画面・帳票定義、DB・ファイル定義
アクセス
トータル
ランキング
