Transcript 3回目 - ソフトウェア設計検証研究室

ソフトウェア工学
第三回
知能情報学部
新田直也
先週の復習（ウォーターフォールモデ
ルの長所と短所）

ウォーターフォールモデルの長所：




仕様や設計の変更は工程全体に深刻なダメージをもたらす．ウォー
ターフォールモデルでは，後の工程が混乱しないよう仕様や設計を早
い段階で固定化する．
各工程毎に成果物を残すことで，不具合が発覚したときに，その原因
の箇所を特定しやすくなる．
プロジェクトの進捗の管理が容易である．
ウォーターフォールモデルの短所：



開発期間が長くなる．
成果物を逐一残すため負荷が増大．
後戻りを許さないため，開発途上で仕様や設計の変更ができない．



進歩の著しい分野に適さない．
一般に顧客の要求はあいまい．どれだけ検証しても，実際に動くものを見
て初めて「こんなはずではなかった」と気づく場合が多々ある．
実装前に完全な設計を行うことはほぼ不可能．
スパイラルモデル（spiral model）




ベーム（1986年）による．
4つのフェーズからなるサイクルを繰り返しながら，ソフトウェ
アを漸進的に成長させる．
4つのフェーズは，計画フェーズ，目標決定フェーズ，評価
フェーズ，開発検証フェーズからなる．目標決定フェーズでは
実装の複数の選択肢（代替案）を考える．評価フェーズでそ
れらの比較評価を行い，それらの中から1つを選定する．
仕様変更や設計のやり直しが発生する度にサイクルを実行
する．
目標決定
計画
評価
開発検証
プロトタイピングモデル
（prototyping model）

開発の初期段階で動く試作品（プロトタイプ, prototype）を作
り顧客に見せる（レビュー, review）．迅速プロトタイピングとも
呼ばれる．







顧客の潜在的な要求と実際の仕様のギャップ（「こんなはずではなかっ
た」）を小さくするため．
プロトタイプでは主要な画面の動きのみを実装する．
プロトタイプで要求を固定化しておいた上で，通常の開発を進
める．（後で文句を言わせない．）
一般に，プロトタイプ作成に用いた試験的な実装は捨てられる．
プロトタイプを捨てずに漸進的に完成品に近づけていく開発手
法はRAD（Rapid Application Development）と呼ばれる．
RADでは顧客へのレビューが繰り返し行われる．
RADは，VisualBasic などの開発環境により広く浸透した．
「人月の神話 新装版」ではマイクロソフトの毎日構築アプロー
チとして紹介されている．
新しいプロセスモデル


近年，アジャイルプロセス（agile process）が産業界で注目
を集めている．
アジャイルプロセスには以下のようなものがある．






XP（eXtreme Programming）
Crystal
SCRUM
:
他にも，モデル駆動型アーキテクチャ，ソフトウェア工場など
開発プロセスに関する新しい話題が出てきている．
最近の話題はいずれもオブジェクト指向技術を前提．
詳しくは，オブジェクト指向開発の説明の後に…
@ITの調査（1）

@ITによる2002年の調査
「第4回 読者アンケート結果
～ソフトウェアの危機とRUP／XP／UML～ 」
http://www.atmarkit.co.jp/fjava/survey/survey0202/survey0202.html
図1 関与する主なソフトウェア開発案件の種類（N=250）
図2 ソフトウェア開発モデルの採用状況 （N=250）
@ITの調査（2）


ソフトウェア危機は解決されていない．
XP，RUP（MDA）など開発プロセスへの期待が高まっている．
図3 ソフトウェア開発の課題（3つまでの複数回答 N=250）
図4 ソフトウェア開発プロセス実践状況（複数回答 N=250）
本日のお話
前回はさまざまな開発プロセスのモデルを紹介した．
 今回は多くの開発プロセスに含まれる，要求分析
（requirement analysis）工程と設計（design）工
程について説明する．
 要求分析と設計は，開発工程の中でも特に重要．



影響範囲が大きいため．
特に作業効率や品質を大きく左右する．
決定的な手法や表記法は今のところ存在しない．
 今日は，「オブジェクト指向以前」の主要な話題を中
心に説明する．

ウォーターフォールモデル
（water fall model）（復習）



要求分析（要求定義）と設計は
開発プロセスにおいて上流に
位置する．
要求定義においても，設計にお
いても，作業の結果は文書（ド
キュメント）に残される．
要求定義の結果を記した文書
を要求定義書，設計の結果を
記した文書を設計書という．
要
求
定
義
システム
要求定義
検証
ソフトウェア
要求定義
上流工程
検証
基本設計
設
計
検証
詳細設計
検証
コーディング
検証
テスト
検証
下流工程
運用保守
検証
要求分析（requirement analysis）

要求とは?
システムが解くべき問題，システムを開発する目的．基本的
に顧客が（明示的あるいは潜在的に）持っているもの．

要求分析：
顧客が持っている漠然とした要求を明確化し，何を作るかを
決めていく作業．分析した結果は要求定義として文書化され，
顧客と開発者の間で共有される．

具体的には，顧客と開発者の間の打ち合わせで進められて
いく場合が多い．開発工数や費用の見積もりが必要な場合
もある．
機能的要求と非機能的要求
要求は大きく，機能的要求と非機能的要求に分ける
ことができる．
 機能的要求（functional requirement）：
システムと環境の相互作用．
 非機能的要求（non-functional requirement） ：
システムの性能，セキュリティ，システムが動作すべ
き環境（OS，ブラウザ，プラットフォーム…），使い易
さ，拡張性など．
 特に非機能的要求は衝突（トレードオフ関係）を起こ
し易い．

要求定義書と要求仕様書

要求分析，定義の成果は，要求定義書と要求仕様書に記述
される．要求定義書は開発者と顧客が共有するもので，開発
者の専門用語で書かれないものである．要求仕様書は要求
定義書と同じ内容を，開発者（特に設計者）向けに書き直し
たものである．

実際は，要求定義書と要求仕様書を分けて書くことは少ない
と思われる．
 分けて書くのに余分な手間がかかる．
 同一の情報を二重に管理するため管理の手間もかかる．
 要求定義書から要求仕様書を作る場合にエラーが混入
する恐れもある．
要求のモデル，記法





要求仕様書を記述する方法が何通りも考えられてきた．
自然言語：
最も一般的で，汎用性が高い．ただし，あいまいな部分が常
に残る．
状態遷移図（state chart diagram）：
システムへの入出力と，それによる内部状態の変化に着目．
UMLの項目で説明する．
ユースケース図（use case diagram）：
システムの利用者の典型的な操作手順を列挙する．UMLの
項目で説明する．
データフローダイアグラム（data flow diagram）：
システムを流れるデータの流れに着目．次に説明．
構造化分析と
データフローダイアグラム




構造化分析は，オブジェクト指向以前の標準的な分析手法．
構造化プログラミング（ダイクストラ）から発展した．
 システムをトップダウンに構造化（段階的詳細化）．
構造化分析の結果はデータフローダイアグラム（data flow
diagram, DFD）として記述され，構造化設計に引き継がれ
る．
データフローダイアグラムの構成要素：
①入出力
入力名
/ 出力名
②データの流れ
③データの処理
④データの蓄積
データ名
処理名
ファイル名
データフローダイアグラムの例（1）

酒屋の在庫問題(付録参照)：

階層化して図式化される．最上位の図を全体文脈図（コ
ンテキストダイアグラム, context diagram）という．
出庫指示書
倉庫係
積荷票
出庫依頼
依頼者
倉庫係
受付係
システム
在庫なし連絡
依頼者
酒屋の在庫問題のDFD(コンテキストダイアグラム)
データフローダイアグラムの例（2）

酒屋の在庫問題の続き：
積荷票
倉庫係
出庫指示書
在庫ファイル
在庫不足リスト
出庫依頼
依頼者
倉庫係
入庫処理
在庫なし連絡
出庫処理
酒屋の在庫問題のDFD(受付係システム)
依頼者
データフローダイアグラムの例（2）

酒屋の在庫問題の続き：
出庫指示書 出庫指示書
作成処理
倉庫係
空予定コンテナ
在庫あり
出庫依頼
在庫ファイル
出庫依頼
依頼者
在庫不足リスト
不足判定
処理
在庫なし
出庫依頼
在庫なし
処理
酒屋の在庫問題のDFD(出庫処理)
在庫なし
連絡
依頼者
設計



要求分析の結果（何を作ればよいか）に基づいて，如何に作
るべきかを考えること．
主にシステム全体をどう分割するかを決定する．
設計は，実装作業の分担，効率，システムの再利用性，保
守性，信頼性に大きく関わる．




分割がうまくできていれば，部品ごとに独立に実装できる．
よくできた部品は，他のシステムでも再利用できる．
分割がうまくできていれば， 1つの不具合は1つの部品の修正だけで
対処できる．
うまく設計できるか否かは設計者の技能によるところが大き
い．
情報隠蔽（information hiding）
1970年にD.L.パルナス
 オブジェクト指向の原型となった．
 情報隠蔽とは?
システムを複数のモジュールに分割する．そのとき，
互いの独立性を高めるように，モジュール内の不必
要な情報を他のモジュールに対して隠そうという考
え方．



そのモジュールを利用する人間が知っておくべき情報の
みを公開し，それ以外は隠蔽される．たとえば，ある処理
内部の具体的な手続き，具体的なデータ構造などは隠蔽
される．
他のモジュールの情報が隠蔽されることで，実装者は自
分の担当モジュールの実装に専念できる．
構造化設計（1）

DFDを基にモジュール分割を行う．（出庫処理を例
に…）
出庫指示書 出庫指示書
作成処理
倉庫係
空予定コンテナ
在庫あり
出庫依頼
在庫ファイル
出庫依頼
依頼者
在庫不足リスト
不足判定
処理
在庫なし
出庫依頼
在庫なし
処理
酒屋の在庫問題のDFD(出庫処理)
在庫なし
連絡
依頼者
構造化設計（2）

データの流れから関数（サブルーチン）呼出しのイン
タフェースを決める．


分岐がある場合は，分岐先を下位の処理にする．
合流がある場合は上位に戻る．
出庫依頼
在庫なし
連絡
出庫指示書，
空予定コンテナ
不足判定処理
在庫なし
出庫依頼
在庫なし処理
在庫あり
出庫依頼
出庫指示書，
空予定コンテナ
出庫指示書
作成処理
結合度と凝集度



結合度：
モジュールの独立性を評価する基準．結合度が低いほど独
立性は高い．結合度の低い順に，無結合，データ結合，スタ
ンプ結合，制御結合，共通結合，内容結合という基準が設定
されている．たとえば，内容結合は他のモジュールの内部を
直接参照している場合に相当し，データ結合はデータ構造を
持たない引数のやりとりのみが存在する場合に相当する．
凝集度：
あるモジュール内部の機能の関連性の高さを評価する基準．
凝集度が高い順に機能的強度，逐次的強度，通信的強度，
手続き的強度，時間的強度，論理的強度，偶発的強度という
基準が設定されている．
モジュール間の結合度が低く，凝集度が高い方がよい設計
ということになる．
仕様変更と設計変更

仕様変更：




ビジネス要因の変化に応じて，作るものを変えなければ
ならない．
顧客自身が何を作りたいか定まっていない．
顧客と開発者の意思疎通が不十分であった．
設計変更：



仕様変更に伴う設計の変更．
実装途上で設計の不備に気づく．
そもそも実装前に設計が必要か?
→オブジェクト指向とそれに基づく分析，設計法
本日のまとめ
要求定義と設計の重要性．
 構造化分析，構造化設計を中心に説明．
 決定的な手法は存在しない．



本質的には開発者の技能による．
僕の私見：



要求分析は工学に頼るな！
要求分析は開発者のコミュニケーション能力が重要．
今から勉強（研究）するなら設計法を．今後発展が見込ま
れる分野．
付録：酒屋の在庫問題
ある酒類販売会社の倉庫では，毎日数個のコンテナが搬入され
てくる．その内容はビン詰めの酒で，1つのコンテナには10銘柄ま
で混載できる．扱い銘柄は約200種類ある．倉庫係は，コンテナ
を受け取りそのまま倉庫に保管し，積荷票を受付係へ手渡す．ま
た受付係からの出庫指示によって内蔵品を出庫することになって
いる．内蔵品は別のコンテナに詰め替えたり，別の場所に保管す
ることはない．空になったコンテナはすぐに搬出される．
さて受付係は毎日数十件の出庫依頼を受け，そのつど倉庫係へ
出庫指示書を出すことになっている．出庫依頼は出庫依頼票また
は電話によるものとし，1件の依頼では，1銘柄のみに限られてい
る．在庫がないか数量が不足の場合には，その旨依頼者に電話
連絡し，同時に在庫不足リストに記入する．そして当該品の積荷
が必要量あった時点で，不足品の出庫指示をする．また空になる
コンテナを倉庫係に知らせることになっている．
受付係の仕事（在庫なし連絡，出庫指示書作成および在庫不足リ
スト作成）のための計算機プログラムを作成せよ．