プログラム再構成に関する 特許申請について

ソフトウェア工学
第三回
知能情報学部
新田直也
先週の復習(ウォーターフォールモデ
ルの長所と短所)

ウォーターフォールモデルの長所:




仕様や設計の変更は工程全体に深刻なダメージをもたらす.ウォー
ターフォールモデルでは,後の工程が混乱しないよう仕様や設計を早
い段階で固定化する.
各工程毎に成果物を残すことで,不具合が発覚したときに,その原因
の箇所を特定しやすくなる.
プロジェクトの進捗の管理が容易である.
ウォーターフォールモデルの短所:



開発期間が長くなる.
成果物を逐一残すため負荷が増大.
後戻りを許さないため,開発途上で仕様や設計の変更ができない.



進歩の著しい分野に適さない.
一般に顧客の要求はあいまい.どれだけ検証しても,実際に動くものを見
て初めて「こんなはずではなかった」と気づく場合が多々ある.
実装前に完全な設計を行うことはほぼ不可能.
スパイラルモデル(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銘柄のみに限られてい
る.在庫がないか数量が不足の場合には,その旨依頼者に電話
連絡し,同時に在庫不足リストに記入する.そして当該品の積荷
が必要量あった時点で,不足品の出庫指示をする.また空になる
コンテナを倉庫係に知らせることになっている.
受付係の仕事(在庫なし連絡,出庫指示書作成および在庫不足リ
スト作成)のための計算機プログラムを作成せよ.