Transcript jlect10

Disciplined Software
Engineering
Lecture #10
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Sponsored by the U.S. Department of Defense
Copyright © 1994 Carnegie Mellon University1
ｿﾌﾄｳｴｱ設計ｰ概要
設計
• 制約
• ﾌﾟﾛｾｽ
• 表現
利用者のﾆｰｽﾞ
設計の次元
設計ﾃﾝﾌﾟﾚｰﾄ
Copyright © 1994 Carnegie Mellon University2
設計の制約
要求は設計と対応していなければならない 要求はしばしば実際に動く製品を手にするまで完全に
は理解されないことがある。
各設計ﾚﾍﾞﾙはより上位ﾚﾍﾞﾙ設計をﾃﾞﾊﾞｯｸﾞする ：
•仕様は要求をﾃﾞﾊﾞｯｸﾞする。
•概要設計は仕様をﾃﾞﾊﾞｯｸﾞする。
•詳細設計は概要設計をﾃﾞﾊﾞｯｸﾞする。
•実装は詳細設計をﾃﾞﾊﾞｯｸﾞする。
Copyright © 1994 Carnegie Mellon University3
設計の枠組み
最初の要求
ﾕｰｻﾞ要求について
ﾃﾞｰﾀを集める
要求ﾃﾞｰﾀを分析する
要求に対して設計
を確認する
要求について質問し
答えを得る
概要設計について
考える
設計を洗練し文書化する
完成した設計
Copyright © 1994 Carnegie Mellon University4
開発の枠組み
要
求
設
計
実
装
単 体 ﾃ ｽ ﾄ
ﾕｰｻﾞｰ
統 合 ﾃ ｽ ﾄ
ｼｽﾃﾑﾃｽﾄ
受 入 れ
使
用
Copyright © 1994 Carnegie Mellon University5
設計ｻｲｸﾙ
要求定義
ｼｽﾃﾑ
仕様
ｼｽﾃﾑ
概要設計
製品１
仕様
製品Ｎ
仕様
- - - - - - -
製品１
概要設計
製品Ｎ
概要設計
部品 １－Ｎ
仕様
部品 １－１
仕様
- - - - - - - 部品１－Ｎ
概要設計
部品１－１
概要設計
ﾓｼﾞｭｰﾙ 1n1
仕様
ﾓｼﾞｭｰﾙ 1n1
詳細設計
- - - - - - - - - -
ﾓｼﾞｭｰﾙ 1nk
仕様
- - - - - - - - - - - - - - - - - - - - - -
ﾓｼﾞｭｰﾙ 1nk
詳細設計
Copyright © 1994 Carnegie Mellon University6
設計ﾌﾟﾛｾｽ - 1
ソフトウエア設計は不完全に定義された問題に対する
精密で効果的な解を作成する創造的プロセスである。
設計プロセスは以下を行うことができない。
•決まりきった手続きに単純化する
•自動化する
•精密にコントロールしたりあるいは予測する
Copyright © 1994 Carnegie Mellon University7
設計プロセス - 2
設計プロセスは以下のために構造化することができる
•創造的活動から決まりきった仕事を分離する
•設計作業が適切に実行されることを保証する
•潜在的な設計支援ツールと手法を認識する
次の2つの問題を分離することが重要である：
•設計する方法
•完成した設計を表現する方法
Copyright © 1994 Carnegie Mellon University8
設計プロセス - 3
多くの設計方法がある：
•全てのドメインに最善であると証明された手法はない
•最善の方法は個人に依存するかもしれない
•個人の好みはまた重要である
•あるプロセスが広く利用可能であるためには多くの
異なる設計手法で有効でなければならない。
また表現には多くのタイプがある。
•ｸﾞﾗﾌｨｯｸｽが構造の視覚化を支援する
•形式化は精密さを与える
•ﾃｷｽﾄは直観的な理解を与える
•上記3つ全てがしばしば必要になる。
Copyright © 1994 Carnegie Mellon University9
ＰＳＰ設計ﾌﾟﾛｾｽ
PSPは完成した設計は何を含むべきかに焦点を置く。
このことは以下の理由で必要である。
•与えられた設計ﾌｪｰｽﾞが何時完了するか決定するた
めの判断基準を与えるため
•その設計をﾚﾋﾞｭｰするためのﾍﾞｰｽを与えるため
•単独で最善の設計手法はないので、PSPは複数の
方法を支援することが可能でなければならない。
Copyright © 1994 Carnegie Mellon University10
貧弱な設計表現は欠陥を生じる - 1
設計のﾚﾍﾞﾙ
•明らかであるべき設計概念が実装段階でそうでない
かもしれない。
•実装期間に設計内容を再構築することは時間を消費
しまたｴﾗｰが入りやすい。
•時間を節約し欠陥を予防するためには、設計はそれ
を思いついた時に精密に記録しなければならない。
Copyright © 1994 Carnegie Mellon University11
貧弱な設計表現は欠陥を生じる - 2
設計の可視性
•複雑な設計は視覚化することが難しい。
•貧弱な表現はこの問題を一層ひどくする。
•うまく表現された設計は曖昧さがない。
設計の冗長性
•冗長な設計はしばしば矛盾している。
•矛盾があることはｴﾗｰを産み欠陥の原因となる。
•高品質な設計では重複が最小である。
Copyright © 1994 Carnegie Mellon University12
設計表現 - 要求
設計の表現は以下でなければならない。
•すべての重要な設計の側面を精密に定義する
•全ての重要な詳細を含む
•設計者の意志を伝える
•設計上の問題と見落しを識別することを助ける
また
•設計は簡潔で使い易くあるべきである。
•設計上のﾄﾋﾟｯｸｽは、関係する場所に容易に対応づ
けできなければならない 。
•冗長は避けねばならない。
Copyright © 1994 Carnegie Mellon University13
設計の利用者 - 1
設計の主な利用者をあげると、
•プログラマ
•設計レビュー者
•テスト作業者とテスト開発者
•ドキュメント作成者、保守者、および機能拡張者
Copyright © 1994 Carnegie Mellon University14
設計の利用者 - 2
全ての利用者が以下を必要とする
•プログラム論理の明確な説明文
•全ての外部呼出しと参照の記述
•全ての外部変数、パラメータ、および定数 のリスト
•全ての関連するオブジェクトとクラスに対する仕様書
•全てのファイルとメッセージの記述
•全てのシステム制約の仕様書
•全ての実装上の制約の仕様書
Copyright © 1994 Carnegie Mellon University15
設計の利用者 - 3
さらに、設計とコードのレビュー者は以下を必要とする
•そのプログラムが何処でどのようにシステムにはめ
込まれるかについての図面
•製品の構造的なビュー
•プログラムの外部機能の精密な説明文
その他の利用者は以下を必要とする
•典型的なユーザシナリオ
•特別なエラーチェックまたは条件の仕様書
•その設計を選択した理由
Copyright © 1994 Carnegie Mellon University16
設計の利用者 - 4
設計は潜在的には膨大な資料である。
•その全てが直ちに必要にはならない。
•あるものは他の情報源から得ることができる。
•できる限り設計の仕事量を制限することが
賢明である
したがって、設計者が用意しなければならない重大な
設計の部分集合を識別することが重要である。
可能なところでは, その他の項目は後であるいは他の
人あるいは他のグループが用意した方がよい。
Copyright © 1994 Carnegie Mellon University17
設計の利用者 - 5
実装の前に設計者によって用意されなければならない
きわめて重要な資料は以下である。
•プログラム論理の明確な説明文
•全ての外部呼び出しと参照の仕様書
•全ての外部変数、パラメータ、および定数のリスト
•全ての関連するオブジェクトとクラスに対する仕様書
•そのプログラムが何処でどのようにシステムにはめ
込まれるかについての図面
•製品の構造的なビュー
Copyright © 1994 Carnegie Mellon University18
設計の次元
オブジェクト
仕様
静的
内部的
属性
制約
外部的
継承
クラスの構造
動的
状態機械
サービス
メッセージ
Copyright © 1994 Carnegie Mellon University19
設計テンプレート
4つの設計テンプレートが PSPで 使用される：
•論理仕様テンプレート - 静的, 内部的
•状態仕様テンプレート - 動的, 内部的
•機能仕様テンプレート - 動的かつ静的、外部的
•操作シナリオテンプレート - 動的, 外部的
Copyright © 1994 Carnegie Mellon University20
設計の階層
プログラム要求:
ユーザが必要とするもの
機 能 仕 様
操 作 シ ナ リ オ
プログラム仕様:
プログラムは何をするか
論 理 仕 様
状 態 仕 様
概要設計:
プログラムの作業の方法
モジュール/オブジェクト仕様
Copyright © 1994 Carnegie Mellon University21
実装の階層
ﾓｼﾞｭｰﾙの要求:
ﾌﾟﾛｸﾞﾗﾑが必要とするもの
機能仕様
操作ｼﾅﾘｵ
ﾓｼﾞｭｰﾙ仕様:
そのﾓｼﾞｭｰﾙがするものは何か
論理仕様
状態仕様
詳細設計:
ﾓｼﾞｭｰﾙはどのように働くか
ﾓｼﾞｭｰﾙ
ｿｰｽｺｰﾄﾞ
Copyright © 1994 Carnegie Mellon University22
設計ﾃﾝﾌﾟﾚｰﾄの使用
これらのﾃﾝﾌﾟﾚｰﾄは設計を表現するための1つの方法
を構成している：
•その目的は精密で、曖昧でなく、冗長でなく、完全で
あること、
•あなたが出来るところではPSPでこの設計ﾃﾝﾌﾟﾚｰﾄ
を使用しなさい。
もし他の表現が同様に精密で、曖昧でなく、冗長でなく
、完全であれば、それに替えてもよい。
これら以外の表現を追加してもよい。
Copyright © 1994 Carnegie Mellon University23
ﾃﾝﾌﾟﾚｰﾄの次元
ｵﾌﾞｼﾞｪｸﾄ仕様
内部的
外部的
静的
論理仕様
ﾃﾝﾌﾟﾚｰﾄ
機能仕様
ﾃﾝﾌﾟﾚｰﾄ
動的
状態仕様
ﾃﾝﾌﾟﾚｰﾄ
機能仕様
および
操作ｼﾅﾘｵ
ﾃﾝﾌﾟﾚｰﾄ
Copyright © 1994 Carnegie Mellon University24
機能仕様ﾃﾝﾌﾟﾚｰﾄ - 1
機能用仕様ﾃﾝﾌﾟﾚｰﾄの目的はこの製品によって
提供される全ての外部的なｻｰﾋﾞｽ機能を曖昧でなく
定義することである。
•ｵﾌﾞｼﾞｪｸﾄ、ｸﾗｽ、および 継承
•外部に見える属性
•各ｵﾌﾞｼﾞｪｸﾄが与える精密な外部機能
Copyright © 1994 Carnegie Mellon University25
機能仕様ﾃﾝﾌﾟﾚｰﾄ - 2
可能なところでは、各機能の呼び出し及びﾘﾀｰﾝは
形式的記法で仕様化すべきである。
関係するｵﾌﾞｼﾞｪｸﾄやｸﾗｽの機能仕様は共通の
ﾃﾝﾌﾟﾚｰﾄの中で一緒にｸﾞﾙｰﾌﾟ化すべきである。
Copyright © 1994 Carnegie Mellon University26
機能仕様ﾃﾝﾌﾟﾚｰﾄ例
ASet (CData)
void Push(data D)
char *Pop(data &D)
int AddSet(data D)
int SubtractSet(data D)
int MemberSet(data D)
ListState (0 - 4)
ListPosition(0 - N)
:: insert D at position 1 && Reset
Empty’ :: return D.name && delete first
&& reset ||
Empty :: return “Empty”
D not in ASet :: Push(D) && Reset && return
true || D in ASet :: Reset&& return false
D in ASet :: delete(D) && Reset &&
return true || D not in ASet :: Reset &&
return false
D in ASet :: return ListPosition ||
D not in ASet && N==1 :: ListPostition = 1 &&
ListState = 1 && return false ||
D not in ASet && N>1 :: ListPosition = N &&
ListState = 4 && return false
Copyright © 1994 Carnegie Mellon University27
状態仕様ﾃﾝﾌﾟﾚｰﾄ 1
ｵﾌﾞｼﾞｪｸﾄは以下を満たす時状態機械である：
•同一のｲﾝﾌﾟｯﾄが異なる応答を作り出す時
•履歴が状態によって記憶されている時
状態仕様ﾃﾝﾌﾟﾚｰﾄはｵﾌﾞｼﾞｪｸﾄの状態と状態間の
遷移を精密に定義する。
Copyright © 1994 Carnegie Mellon University28
状態仕様ﾃﾝﾌﾟﾚｰﾄ 2
ｵﾌﾞｼﾞｪｸﾄ状態機械の各々に対して、
ﾃﾝﾌﾟﾚｰﾄは以下を仕様化する：
•各状態の名前
•各状態を特徴づける属性
•その状態に対する属性値
•その状態の簡潔な説明
•その状態から自分自身への遷移を引き起こす精密
な条件
•任意の他の状態からこの状態への遷移を引き起こ
す精密な条件
Copyright © 1994 Carnegie Mellon University29
状態機械の例*
EmptySet
First&Only
FirstOfSeveral
MiddleOfSeveral
LastOfSeveral
*注意:ある状態からそれ自身への遷移は示されていない
Copyright © 1994 Carnegie Mellon University30
部分的状態仕様
First&Only
the set has one member
N =1
ListState = 1
ListPosition = 1
EmptySet
Clear || Pop || (SubtractSet(D) && D in ASet)
First&Only
Reset || StepForward || StepBackward ||
(AddSet(D) && D in ASet) || (SubtractSet(D) && D not in
ASet) || MemberSet || Empty || Last || Status || Position
FirstOfSeveral
Push || (AddSet(D) && D not in ASet)
MiddleOfSeveral
Impossible
LastOfSeveral
Impossible
Copyright © 1994 Carnegie Mellon University31
状態仕様ﾃﾝﾌﾟﾚｰﾄの考察
全てのオブジェクト状態機械を定義しなさい
•自明な状態機械は定義するのも自明であるに違いな
い
•しばしば簡単な状態機械に見えてもそうでない
•状態機械が複数のｵﾌﾞｼﾞｪｸﾄを含む時には、ｵﾌﾞｼﾞｪｸﾄ
がうまく選ばれなかった徴候であるかもしれない。
完全性と無矛盾性をﾁｪｯｸしなさい
•全ての状態に対する属性の条件の集合は完全で直
交していなければならない。
•任意の与えられた状態からの全ての遷移条件の集
合は完全で直交していなければならない。
Copyright © 1994 Carnegie Mellon University32
論理仕様ﾃﾝﾌﾟﾚｰﾄ 1
論理仕様テンプレートはﾌﾟﾛｸﾞﾗﾑの内部論理を精密に
定義する。
論理を便利な記法で記述しなさい：
•実装言語と互換性のある疑似コードはしばしば
適当である。
•形式的記法もまた適当である。
•プログラマは使用する記法に達者でなければならない。
Copyright © 1994 Carnegie Mellon University33
論理仕様テンプレート 2
論理仕様テンプレートは以下を仕様化すべきである：
•各オブジェクトの各メソッドの論理と、そのメインプロ
グラムの論理
•プログラムまたはメソッドに対する精密な呼び出し
•includes
•特別なデータタイプとデータ定義
•プロジェクト名、日付、および開発者
Copyright © 1994 Carnegie Mellon University34
操作シナリオテンプレート - 1
操作シナリオテンプレートはユーザのシステムとの
正常および非正常な相互作用が、設計前と設計途中
の双方で、考察されかつ定義されていることを保証す
るために使用される。
操作シナリオテンプレートは以下のことに使用できる：
•テストシナリオとテストケースを定義するために
•操作上の問題に関する開発上の疑問の解決のため
•ユーザとの要求仕様の論議を解決するために
Copyright © 1994 Carnegie Mellon University35
操作シナリオテンプレート - 2
操作シナリオテンプレートはシナリオ様式を使用する。
これは以下を含む：
•主要なユーザの行動とシステムの応答
•予期されるエラーおよびリカバリー条件
Copyright © 1994 Carnegie Mellon University36
演習課題 #10
テキストの第10章を読みなさい。
PSP2.1を使用して一連のN個の実数が正規分布して
いる度合いを計算するためのプログラム 9A を書く。
•N は20より大でかつ5の偶数倍と仮定する
•数値を上昇順にソートするためにプログラム８Aを使
用する.
付録Cにあるプロセスとレポートの仕様および、付録D
にあるプログラム仕様を読むこと。
Copyright © 1994 Carnegie Mellon University37
講義10から記憶すべきメッセージ
1. 設計は創造的なプロセスであるが, その決まりきっ
た側面は定義することが出来る。
2. 設計成果物の定義と確立された様式はあなたの設
計の品質を改善できる。
3. コース演習中の ４ つのPSP 設計テンプレートにつ
いて実験しなさい、そしてもしそれらのテンプレート が
有用と判ったら、それらを他の仕事にも使いなさい。
Copyright © 1994 Carnegie Mellon University38