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
© Copyright 2025 ExpyDoc
