ソフトウェア工学 第四回 知能情報学部 新田直也

構造化分析と データフローダイアグラム 構造化分析は，オブジェクト指向以前の標準的な分析手法． 構造化プログラミング（ダイクストラ）から発展した． システムをトップダウンに構造化（段階的詳細化）． 構造化分析の結果はデータフローダイアグラム（data flow diagram, DFD）として記述され，構造化設計に引き継がれる． データフローダイアグラムの構成要素： ①入出力 ②データの流れ ③データの処理 ④データの蓄積 データ名 入力名 / 出力名 処理名 ファイル名

データフローダイアグラムの例（1） 酒屋の在庫問題(付録参照)： 階層化して図式化される．最上位の図を全体文脈図（コンテキストダイアグラム, context diagram）という． 出庫指示書 倉庫係 倉庫係 積荷票 空予定コンテナ 受付係 システム 出庫依頼 在庫なし連絡 依頼者 依頼者 酒屋の在庫問題のDFD(コンテキストダイアグラム)

データフローダイアグラムの例（2） 酒屋の在庫問題の続き： 酒屋の在庫問題のDFD(受付係システム) 積荷票 出庫指示書 倉庫係 入庫処理 空予定コンテナ 在庫ファイル 在庫不足リスト 出庫依頼 在庫なし連絡 依頼者 出庫処理 依頼者 酒屋の在庫問題のDFD(受付係システム)

データフローダイアグラムの例（2） 酒屋の在庫問題の続き： 酒屋の在庫問題のDFD(出庫処理) 出庫指示書 作成処理 出庫指示書 倉庫係 空予定コンテナ 在庫あり 出庫依頼 在庫ファイル 在庫不足リスト 在庫なし 出庫依頼 在庫なし 連絡 出庫依頼 依頼者 不足判定 処理 在庫なし 処理 依頼者 酒屋の在庫問題のDFD(出庫処理)

設計 要求分析の結果（何を作ればよいか）に基づいて，如何に作るべきかを考えること． 主にシステム全体をどう分割するかを決定する． 設計は，実装作業の分担，効率，システムの再利用性，保守性，信頼性に大きく関わる． 分割がうまくできていれば，部品ごとに独立に実装できる． よくできた部品は，他のシステムでも再利用できる． 分割がうまくできていれば， 1つの不具合は1つの部品の修正だけで対処できる． うまく設計できるか否かは設計者の技能によるところが大きい．

情報隠蔽（information hiding） 1970年にD.L.パルナス オブジェクト指向の原型となった． 情報隠蔽とは? システムを複数のモジュールに分割する．そのとき，互いの独立性を高めるように，モジュール内の不必要な情報を他のモジュールに対して隠そうという考え方． そのモジュールを利用する人間が知っておくべき情報のみを公開し，それ以外は隠蔽される．たとえば，ある処理内部の具体的な手続き，具体的なデータ構造などは隠蔽される． 他のモジュールの情報が隠蔽されることで，実装者は自分の担当モジュールの実装に専念できる．

構造化設計（1） DFDを基にモジュール分割を行う．（出庫処理を例に…） 酒屋の在庫問題のDFD(出庫処理) 出庫指示書 作成処理 倉庫係 空予定コンテナ 在庫あり 出庫依頼 在庫ファイル 在庫不足リスト 在庫なし 出庫依頼 在庫なし 連絡 出庫依頼 依頼者 不足判定 処理 在庫なし 処理 依頼者 酒屋の在庫問題のDFD(出庫処理)

構造化設計（2） データの流れから関数（サブルーチン）呼出しのインタフェースを決める． 分岐がある場合は，分岐先を下位の処理にする． 合流がある場合は上位に戻る． 出庫依頼 在庫なし 連絡 出庫指示書， 空予定コンテナ 不足判定処理 在庫なし 出庫依頼 在庫なし 連絡 在庫あり 出庫依頼 出庫指示書， 空予定コンテナ 在庫なし処理 出庫指示書 作成処理

結合度と凝集度 結合度： モジュールの独立性を評価する基準．結合度が低いほど独立性は高い．結合度の低い順に，無結合，データ結合，スタンプ結合，制御結合，共通結合，内容結合という基準が設定されている．たとえば，内容結合は他のモジュールの内部を直接参照している場合に相当し，データ結合はデータ構造を持たない引数のやりとりのみが存在する場合に相当する． 凝集度： あるモジュール内部の機能の関連性の高さを評価する基準．凝集度が高い順に機能的強度，逐次的強度，通信的強度，手続き的強度，時間的強度，論理的強度，偶発的強度という基準が設定されている． モジュール間の結合度が低く，凝集度が高い方がよい設計ということになる．

仕様変更と設計変更 仕様変更： 設計変更： ビジネス要因の変化に応じて，作るものを変えなければならない． 顧客自身が何を作りたいか定まっていない． 顧客と開発者の意思疎通が不十分であった． 設計変更： 仕様変更に伴う設計の変更． 実装途上で設計の不備に気づく． そもそも実装前に設計が必要か? →オブジェクト指向とそれに基づく分析，設計法

本日のまとめ 要求定義と設計の重要性． 構造化分析，構造化設計を中心に説明． 決定的な手法は存在しない． 僕の私見： 本質的には開発者の技能による． 僕の私見： 要求分析は工学に頼るな！ 要求分析は開発者のコミュニケーション能力が重要． 今から勉強（研究）するなら設計法を．今後発展が見込まれる分野．

付録：酒屋の在庫問題 ある酒類販売会社の倉庫では，毎日数個のコンテナが搬入されてくる．その内容はビン詰めの酒で，1つのコンテナには10銘柄まで混載できる．扱い銘柄は約200種類ある．倉庫係は，コンテナを受け取りそのまま倉庫に保管し，積荷票を受付係へ手渡す．また受付係からの出庫指示によって内蔵品を出庫することになっている．内蔵品は別のコンテナに詰め替えたり，別の場所に保管することはない．空になったコンテナはすぐに搬出される． さて受付係は毎日数十件の出庫依頼を受け，そのつど倉庫係へ出庫指示書を出すことになっている．出庫依頼は出庫依頼票または電話によるものとし，1件の依頼では，1銘柄のみに限られている．在庫がないか数量が不足の場合には，その旨依頼者に電話連絡し，同時に在庫不足リストに記入する．そして当該品の積荷が必要量あった時点で，不足品の出庫指示をする．また空になるコンテナを倉庫係に知らせることになっている． 受付係の仕事（在庫なし連絡，出庫指示書作成および在庫不足リスト作成）のための計算機プログラムを作成せよ．