ソフトウェア・エンジニアリング入門 セッション 3: ソフトウェア・プロダクト chart 3-1 セッション 3: 目標 • ソフトウェア開発における重要な成果物（ソフト ウェア・プロダクト）を特定する • ソフトウェアの記述のための代表的な表記法や 記述言語と、それらの表記法の背景にある重要 な概念について、大まかに学ぶ • ソフトウェアの記述におけるありがちな問題点に ついて論じる chart 3-2 成果物にはどのようなものがあるか 要求セット 設計セット 1. 開発ビジョン 説明書 1. 設計モデル 2. 要求モデル 3. ソフトウェア アーキテクチャ 説明書 2. テストモデル 立案成果物 1. 作業分解構造 2. ビジネスケース 3. リリース仕様 4. ソフトウェア開発計画 管理セット 実装セット 導入セット 1. ソースコードの ベースライン 1. 統合製品実行 可能ファイルの ベースライン 2. 関連するコンパ 2. 関連する イル時ファイル 実行時ファイル 3. コンポーネント 3. ユーザ 実行可能ファイル マニュアル 運用成果物 5. リリース説明 6. ステータス評価 7. ソフトウェア変更指示データベース 8. 導入ドキュメント 9. 環境 chart 3-3 成果物のセット 管理セット • 管理セットは、プロセスの立案と実行に関する成果物を表現する。 • 自由な形式の表記法（文書や図表）が使われる。 • プロジェクト要員間、利害関係者間、プロジェクト要員と利害関係者間の 「契約」を表現するのに必要な表現であればどのようなものでも含まれる。 • 作業分解構造: 作業の分解と経理調査のメカニズム • ビジネスケース: コスト、スケジュール、収益の予測 • リリース仕様: リリースのベースラインの対象範囲、計画、目的 • ソフトウェア開発計画: プロジェクトのプロセスインスタンス • リリース説明: リリースのベースラインの成果 • ステータス評価: プロジェクト進捗の周期的なスナップショット • ソフトウェア変更指示: ベースラインに対する個別の変更についての記述 • 導入ドキュメント: 導入計画、トレーニングコース、販売用資料 • 環境: ハードウェア、ソフトウェアツール、プロセス自動化….. chart 3-4 成果物のセット 管理セット（評価） • 管理セットの成果物は、以下の組合せを通して評価、査定、測 定が行われる。 – 関係する利害関係者によるレビュー – 成果物の現バージョンと前バージョンの間でなされた 変更（コスト、スケジュール、品質の観点から見た、管 理動向とプロジェクトパフォーマンスの変化）の解析 – すべての成果物間のバランスと、特にビジネスケース 成果物と開発ビジョン成果物の正確さについての種マ イルストーンのデモンストレーション chart 3-5 成果物のセット エンジニアリングセット: 要求セット • 開発ビジョン説明書: – 開発資金提供者とプロジェクトチーム間の契約をサポートす るプロジェクト対象範囲について記載したもの • 要求モデル: – 対象領域モデル – システム内部の仕様モデル – 後で説明する表記法を用いてモデル化 • 機能面（シナリオ）: ユースケース • 静的側面: クラス図、CRCカード、ER図等 • 動的側面: 状態遷移図、相互作用図、アクティビティ図等 chart 3-6 成果物のセット エンジニアリングセット: 要求セット（評価） • 要求セットの成果物は、以下のような観点を組合せて評価、査 定、判定が行われる。 – 管理セットのリリース仕様との一貫性の分析 – 開発ビジョンと要求モデルとの一貫性の分析 – 設計セット、実装セット、導入セット間での対応性を調査し、 異なるセット内に含まれる情報館の一貫性、完全性、意味 的なバランスを評価する – 要求成果物の現バージョンと前バージョンとの間でなされ た変更の解析（履き、やり直し、欠陥除去の傾向） – 品質の他の次元についての主観的レビュー chart 3-7 成果物のセット エンジニアリングセット: 設計セット • 設計モデル: 後述の表記法で記述 – 複数の抽象レベルで構成される – 構造と振る舞い • テストモデル: – 設計に対応するテストケースを任意の表記法で記述 • ソフトウェアアーキテクチャ説明書 – アーキテクチャの説明に関係のある情報を設計モデ ルから抜粋したもの chart 3-8 成果物のセット エンジニアリングセット: 設計セット（評価） • 設計セットの成果物は、以下のような観点を組合せて評価、査 定、判定が行われる。 – 設計モデルの内部的一貫性と品質の分析 – 要求モデルとの一貫性の分析 – 実装と導入の成果物セットおよび表記法へ変換して（たと えば、対応を追跡し、ソースコード生成、コンパイル、リンク して）、それらのセット内に含まれる情報間の一貫性、完全 性、意味的なバランスを評価する。 – 設計モデルの現バージョンと前バージョンとの間でなされ た変更の解析 – 品質の他の次元についての主観的レビュー chart 3-9 成果物のセット エンジニアリングセット: 実装セット • 製品ソースコードのベースラインとその関連ファイル(*1) – (*1): コンパイルスクリプト、構成管理インフラストラクチャ、 データファイル • テストソースコードのベースラインとその関連ファイル(*2) – (*2): 入力テストデータファイル、テスト結果ファイル • コンポーネントの実行可能ファイル – 単体、テストドライバ • 各ソースコードは、それ自身ドキュメントとなり得るものが望ま しい。 chart 3-10 成果物のセット エンジニアリングセット: 実装セット（評価） • 実装セットは人間が読める形式の成果物で、以下のような観点を 組合せて評価、査定、判定が行われる。 – 設計モデルとの一貫性の分析 – 導入セットの表記法へ翻訳（たとえばコンパイルおよびリンク）し て、成果物セット間の一貫性と完全性を評価する – インスペクション、解析、デモンストレーション、テストを通して、 コンポーネントのソースファイルまたは実行可能ファイルを関連 する評価基準に照らして査定する – コンポーネント単体にテストケースを適用し、予想結果と実際の 結果を自動的に比較する – 実装セットの現バージョンと前バージョンとの間でなされた変更 の解析（破棄、やり直し、欠陥除去の傾向） chart 3-11 成果物のセット エンジニアリングセット: 導入セット • 統合製品実行可能ファイルのベースライン – 実行可能ソフトウェア – 実行に必要なデータ類（辞書、画像、音声等を含む） • 関連する導入時ファイル – インストールスクリプト • 関連する実行時ファイル – その実行環境に特有の実行可能データ、設定ファイル • ユーザマニュアル • サンプル (Examples) chart 3-12 成果物のセット エンジニアリングセット: 導入セット（評価） • 導入セットは、以下のような観点を組合せて評価、査定、判定が行わ れる。 – 要求セットに定義された利用シナリオと品質属性に照らしてテストを行い、 ２つのセット内に含まれる情報館の一貫性、完全性、意味的なバランス を評価する – 実装セット内のコンポーネントを導入対象システムの物理的資源（プラッ トフォームのタイプ、数、ネットワーク構成）にマッピングする際の、パー ティション分割、複製、割り当てについての戦略をテストする – インストール、ユーザに応じた動的な再構成、本来の使用、以上管理と いったユーザマニュアルに定義済みの利用シナリオに照らしてテストを 行う – 導入セットの現バージョンと前バージョンとの間でなされた変更の解析 （欠陥除去の傾向、性能変化） chart 3-13 成果物のセット エンジニアリングセット: 導入セット（補足） • 導入セットの品質に影響を及ぼすが、設計セットと実装 セットでは比較的把握しにくい技術的決定内容: – 動的に再設定可能なパラメータ（バッファサイズ、サーバ数等） – コンパイラ／リンカでの最適化の影響（空間 対 速度） – 一定の割り当て戦略下での性能（動的負荷分散等） – 仮想マシン上の制約（ファイル記述子、ヒープサイズ等） – プロセスレベルの並行性の問題（デッドロック条件と競合条件） – プラットフォームごとの性能や振る舞いの違い • こうしたコンフィギュレーション情報をソースコード実装とど れだけ切り離して記述できるか、重要な課題となる。 chart 3-14 成果物の記述 記述、表記法、記述言語 • ソフトウェアの成果物は、すべて「記述」である。 • 記述の目的、注目対象、適用範囲等によって、さまざまな 表記法、記述言語がある。 • 状況に合わせて、適切な表記法、記述言語を使用する。 • ここでは、要求モデルや設計モデルを記述するために使 用される、代表的な表記法、記述言語を簡単に紹介する。 – シナリオ記述用: ユースケース – 静的側面の記述用: CRCカード、クラス図、ER図等 – 動的側面の記述用: 状態遷移図、相互作用図等 – 汎用: 木構造図、表、ラフなスケッチ、文 chart 3-15 記述の表記 目的に合わせた標準的な表記を用いる理由 • 担当者の頭の中だけにあっても、何らかの方法で記述し なければ、他の人にはわからない。 • 表記がバラバラだと誤解や混乱が生じやすい。 • 行き当たりばったりの表記で記述すると、本来必要なこと を記述し忘れたり考慮し忘れたりすることがある。 • 目的に合わない表記で記述すると、うまく記述できなかっ たり、かえって複雑になったりする。 • 目的に合わせた標準的な表記で記述されていれば、関係 者は適切に批評できる。互いに議論しあうことによって、問 題点に早く気づいたり、記述内容が質的に高まることが期 待できる。 chart 3-16 シナリオ記述の表記 ユースケース • ユーザの一般的な目的に照らして結びつけられた一群のシナリオ • シナリオとは、ユーザとシステム間のやりとりを表す一連の手順。 • たとえば、Web上にオンラインショップを持っている場合において: – 「製品を購入する」という一つのシナリオが考えられる: • 顧客がカタログに目を通し、ショッピングカートに商品を入れてい く。支払の際、顧客は配達方法とクレジット番号を入力し…. – 「購入成功」「認証失敗」という２つのシナリオを持つ、「製品を 購入する」という単一のユースケースが考えられる。 • 一つのユースケースについて起こり得るすべてのシナリオを考え ると非常に複雑になることがあるので、本当に役立つ要素だけを 取り上げるのが有用。 ※このスライドは、マーチン・ファウラー「UMLモデリングのエッセンス第２版」, 翔泳社, 2000, p.35 を参考にしました。 chart 3-17 シナリオ記述の表記 • 製品を購入する: 購入成功の場合 – – – – – – – – • ユースケースの例 1. 顧客がカタログを読んで買う商品を選択する 2. 顧客が精算を指示する（チェックアウトする） 3. 顧客が配達方法（住所と配達日）を入力する 4. システムが送料を含めた合計金額を表示する 5. 顧客がクレジット番号を入力する 6. システムがクレジット情報を入力する 7. システムが直ちに購入内容を販売に通知する 8. システムが顧客に確認の電子メールを送信する バリエーション: 認証の失敗 – 手順6でシステムがクレジットによる購入を認証できなかった場合、顧客は再度クレジット情 報を入力してリトライできる • バリエーション: 定期的な顧客 – 3a. システムが最新の発送情報、金額情報、およびクレジット情報の最後の4桁を表示する – 3b. 顧客は規定値を受け入れることも変更することもある – ステップ6で主シナリオに戻る ※このスライドは、マーチン・ファウラー「UMLモデリングのエッセンス第２版」, 翔泳社, 2000, p.37 を引用しました。 chart 3-18 静的側面の表記 CRCカード • CRCとは Class-Responsibility-Collaborator の略。 • クラスの名前、責任（役割）、他のどのクラスと協調（協同 作業）するか の３つを明らかにしたカード。 • 要求分析定義の段階では、重要な「もの」をクラスとして カードに書き、グループでロールプレイすることで、必要 な機能やサービスを提供するために必要なクラスの洗い 出しや役割の確認をすることができる。 • 設計段階では、プログラムに直結するクラスをカードに書 くことで、クラスの役割や協調関係を明らかにできる。 • テスト段階では、プログラミングされたクラスがその役割 をきちんと果たしているか確認するために使用できる。 chart 3-19 静的側面の表記 CRCカードの表記 クラス名 あれば親クラスや 子クラスを記入する スーパクラス: サブクラス: 注文 • 在庫があるかチェックする • 価格を決定する 責務 (Responsibility) 注文明細 • 有効な支払かチェックする 顧客 • 納入先住所へ配送する 配送 協調者 (Collaborator) 3 x 5 インチのインデックスカードを使っている人が多いといわれています。 ※この図は、マーチン・ファウラー「UMLモデリングのエッセンス第２版」, 翔泳社, 2000, p.68 を参考にしました。 chart 3-20 静的側面の表記 クラス図 • クラス図は、ソフトウェアの静的な側面を、クラスの属性 やクラスが提供するサービス、クラス間の性質の相違や 役割関係等に注目して構造化した図である。 • クラス図は、ドメイン分析、要求仕様分析、設計／実装の それぞれの段階で使える。それぞれの段階で観点が異 なるので異なるモデルとなる。それぞれ必要なものをクラ スとして取り上げ、図化する。 • あらゆるものに対してクラス図を作成しようとせず、主要 な分野に集中して作成するのが得策。 • 1枚の図ですべてのクラス関係を表そうしないこと。 chart 3-21 静的側面の表記 クラス図の構成要素 • クラス: ものごとを共通の性質でくくったもの – クラス名 – 属性リスト: クラスが覚えておくべき要素、項目 – 操作リスト: クラスが自分でしなければいけない処理 • クラス間の汎化／特殊化 （継承関係） • クラス間の関連 – ロール名: 役割の名前 – 多重度: 厳密に1、多(0以上)、オプション(0か1)、値範囲指定、 集約、コンポジション • インスタンス: クラスを具体化したもの（オブジェクト） chart 3-22 静的側面の表記 ER図（実体関連図） • ER図（実体関連図）は、システムが保存すべき情報を整理する ため、Entity(実体)とRelationship（関連）に着目して構造化し、 図化したものである。 • リレーショナルデータベース(RDB)のスキーマ設計では昔から良く使 われている。 • 実体: 「顧客」や「製品」のように、何らかの意味的にまとまりの ある属性を持った独立した「個別のもの」を指す。 • 関連: 「顧客」が「製品」を「購入する」という場合に、「購入」が関 連となる。 • 基数: 1対1、1対多、多対多かを表す。RDBでは基数（カーディ ナリティ）が問題となるので、基数も記述する。 • クラス図はER図を元に発展したので、クラス図とER図を両方書く必要 はないが、RDBのスキーマ設計では必要かもしれない。 chart 3-23 静的側面の表記 ER図（実体関連図）の表記 注文 顧客 顧客番号 顧客名 所在地 電話番号 与信限度額 0,N 発注 1,1 四角形はエンティティ（実体） を表す。線の上部が エンティティ名、下部が アトリビュート（属性）名。 下線付き属性は「unique key」。 注文番号 受付年月日 担当者 1,N 明細 ひし形は Relationship （関連、関係）を表す。 1,1 「0,N」はカーディナリティ （結合度、多重度）という。 顧客は注文をしないか 複数回注文をすることが あるので、 「顧客」から見ると 「注文」は0,N 製品 注文明細 明細番号 1,1 記載 0,N 数量 値引き 製品番号 製品名 単価 製造元 ※カーディナリティの表現には他にもいろいろありますが、ここではこのような表記を紹介します。 ※この図は、大木幹雄「ソフトウェア設計の基礎」,日本理工出版会, 1999, p.151を参考にしました。 chart 3-24 動的側面の表記 相互作用図 • 相互作用図は、何らかの振る舞い（１つのユースケース等）を 為すために、オブジェクト群がどのように協調して相互作用を 行うかを説明するための図である。 • 図を見るだけでメッセージをすぐに読み取ることができる。 • ただし、相互作用図は数ある振る舞いの実現方法の例示に過 ぎない。代替方法の検討には、CRCカードによるロールプレイが便利。 • 複数のユースケースに存在する１つのオブジェクトの振る舞い を見たいときは状態遷移図を使う。複数のユースケースやス レッドにまたがる振る舞いを見たいときには、アクティビティ図 （ペトリネットのUML改良版）を使うと良い。 chart 3-25 動的側面の表記 状態遷移図 • 状態図とは、何かについて状態の遷移を表した図。 • 以下のことを明らかにしたい場合に描く: – その「何か」にはどういう状態があるのか: 状態 – 状態が遷移する「トリガ（きっかけ）」は何か: イベント – 状態が遷移すると何が起きるのか: アクション • 何についても描けるが、興味深い振る舞いをするものに 絞って描くのが得策。たとえば: – なんらかの制御(control)をするオブジェクト – ユーザインタフェース chart 3-26 動的側面の表記 状態遷移図の表記 スーパー状態名 状態名 entry/入状アクション do/アクティビティ exit/退状アクション イベント名（引数リスト） [条件]/アクション 状態名 イベント/アクション（引数リスト） ※遷移ラベルにイベントが含まれていない場合は、 所定の状態に関連付けられたアクティビティが完了すると直ちにその遷移が発火する。 状態遷移図には何種類もの表記がありますが、ここでは、UML 1.3 で採用されている、 David Harel (1987) の表記（を元にRumbaughが拡張した表記）を紹介します。 David Harel: “Statecharts: A Visual Formalism for Complex Systems.” In Science of Computer Programming, Vol.8, 1987. chart 3-27 動的側面の表記 状態遷移図の例 “レンタルショップ受付係” の状態遷移図記述例 レンタル注文 会員証の提示待ち 入会希望［会員証なし］ do: 登録制度の説明 do: 提示を要求 提示［会員期限切れ］ 更新依頼 do: 更新意思表示待ち 提示［会員期限内］ レンタル商品記録中 do: 商品番号の入力 記録完了 / 確認 更新拒否 記入完了 / 登録内容確認 登録票記入待ち entry: 登録票を渡す 仮払い料金精算待ち entry: 請求金額の提示 do: 仮払売上金の入力 精算OK ※この図は、大木幹雄「ソフトウェア設計の基礎」,日本理工出版会, 1999, p.170を参考にしました。 chart 3-28 動的側面の表記 アクティビティ図 • アクティビティ図とは、アクティビティ、すなわち、何かの動 作を行っている状態を中核にして、流れを表した図。 • ワークフローモデリング、ペトリネットなどに由来する概念 を組合せたもの。 • ワークフローを接続したり、並行処理を伴う振る舞いを記 述するのに特に役に立つ。 • ある処理の流れの中で、非同期で（並行に）動作してもか まわないものがあれば、複数のスレッドに「フォーク」し、そ れぞれのスレッドが終了した後、同期する必要がある時に 「ジョイン」させて終了させる。 chart 3-29 動的側面の表記 アクティビティ図の表記 開始状態 アクティビティ 注文を受け付ける 注文を処理する フォーク 請求書を送付する 分岐 [急ぎの注文] 即発送する [else] 通常発送する 支払を確認する ジョイン マージ 注文を終了する ※この図は、マーチン・ファウラー「UMLモデリ ングのエッセンス第２版」, 翔泳社, 2000, p.114を参考にしました。 終了状態 chart 3-30 記述の例 例: MVCパターン • これから数枚のスライドを使って、CRCカード、クラス図、 相互作用図の例を示します。 • 題材としては、対話型システムで良く使われるアーキテク チャパターン 「MVC(Model-View-Controller)パターン」 を取り上げます。 • MVCパターンが最初に導入されたのは、Smalltalk-80プ ログラミング環境です。 ※ここから数枚のスライドにわたる、MVCパターンの例については、F.ブッシュマン他「ソフトウェア アーキテク チャ」（略称:POSA本）, トッパン, 1999, p.120-139を参考にしました。 chart 3-31 記述の例 例: MVCパターンのコンテキストと課題 • コンテキスト: – 人間とコンピュータのインタフェースに柔軟性を持たせ た対話型アプリケーション。 • 課題: – ユーザインタフェースは要求仕様の変更の影響を受 けやすく、またプラットフォームにより異なることが多い ので柔軟性を持たせたい。 – ユーザインタフェースとシステムの機能中核部分の結 合度が高いと、誤りを潜在的に持つ可能性が高くなり、 変更や保守が困難である。 chart 3-32 記述の例 例: MVCパターンの課題のフォース(force) • 以下に述べるフォースがこの課題の解決策に影響を与える。 – 同一情報を別々のウィンドウに異なる形式で表示する必要があ る。たとえば、棒グラフや円グラフという形式で情報が表示される。 – データに対して行われた操作が、直ちにアプリケーションの表示 と動作に反映されなければならない。 – ユーザインタフェースの変更を容易に行うことができる。また、実 行時においても、その変更を行うことができることが望ましい。 – 異なるルック＆フィール標準のサポートやそれらの間の移植が、 アプリケーションの中核となるコードに影響してはならない。 chart 3-33 記述の例 例: MVCパターンの解決策 • 対話型アプリケーションを、処理、出力、入力の３つの領域を担当 するコンポーネントに分ける。それぞれ、Model、View、Controller が担当する。 • Model は、アプリケーションの核となるデータと機能をカプセル化 する。特定の出力表現や入力動作からは独立したものである。 • View は、情報をユーザに表示することについて責任を持つ。その ために、Modelからデータを取得する。1つのModelについて複数 のViewを定義できる。 • 個々のViewごとにControllerが存在する。Controllerはマウスや キーボードなどからの入力を受取る役割を担う。Controllerは受 取ったイベントをModelやViewに対するサービス要求に翻訳する。 ユーザは、Controllerを通じてのみ、システムと対話できる。 chart 3-34 記述の例 例: MVCパターンの解決策（続き） • View と Controller を Model から分離することによって、同一 モデルに対して複数の View を持たせることが可能になる。 • 1つのViewと関連づけられているControllerを通じてユーザが Model を変更すると、このデータに依存するすべての View はその変更を反映させた表示を行わなくてはならない。 • したがって、Modelのデータが変更された場合にはいつでも、 モデルがそれをすべてのViewに通知するようにする。 • その通知を受けて、ViewがModelから新しいデータを取り出し、 表示している情報を更新する。これを更新伝播機構と呼ぶ。 • この解決策の静的側面をCRCカードとクラス図で、動的側面 をシナリオと相互作用図（シーケンス図）で説明する。 chart 3-35 記述の例 例: MVCパターンのCRCカード クラス Model 責務 協調者 ・ View ・ Controller ・ アプリケーションの機能中核を提供する。 ・ ViewとController を登録する。 ・ データ変更をコンポーネントに通知する。 クラス View 責務 協調者 ・ Controller ・ Model ・ Controller を生成して初期化する。 ・ 情報をユーザに表示する。 ・ 更新手続を実装する。 ・ Model のデータを取得する。 クラス Controller 責務 協調者 ・ View ・ Model ・ ユーザ入力をイベントとして受取る。 ・ イベントをModelへのリクエスト、あるい は、Viewへのリクエストに変換する。 ・ （必要に応じて）更新用手続を実装する。 CRCカードは、 アプリケーションにおける重 要なクラスを特定し、それぞれの責務と協調 者を明らかにするのに役立つ。 「クラス」とあるが、概念レベルのクラスやコン ポーネントの洗い出しに使用しても有効であ る。 紙面の都合で協調者を右上に書いているが、 責務ごとに協調者を書くのが本来の姿である。 CRCカード: Class-Responsibility-Collaborator card: クラス-責務-協調者カード [BeCu89] chart 3-36 記述の例 例: MVCパターンのクラス図 クラスを表す。 上段はクラス名、 中段は属性名、 下段は操作。 Observer update updateを呼び出す Observerは ViewやControllerを 「汎化」したもの であることを表す Model coreData setOfObservers attach(Observer) detach(Observer) notify getData service View myModel getDataと 関連付ける myController Initialize(Model) makeController activate display update 生成する Controller 表示を 操作する myModel サービス呼び出し と関連付ける myView Initialize(Model, View) handleEvent update chart 3-37 記述の例 例: MVCの動的な振る舞いを描いたシナリオ１ • このシナリオは、モデルを変化させるユーザ入力が更新伝 播メカニズムをどのように駆動するかを示すものである。 • コントローラは、イベントハンドリング手続でユーザ入力を受 取り、そのイベントを解釈し、モデルのサービス手続を活性 化する。 • モデルは、リクエストされたサービスを実行する。この結果、 モデルの内部データが変化する。 • モデルは、更新伝播メカニズムに登録されたすべての ビューとコントローラによって行われる。 • （次スライドに続く） chart 3-38 記述の例 例: MVCの動的な振る舞いを描いたシナリオ１ （続き） • 各ビューがモデルに更新データをリクエストし、自らを画 面に再表示する。 • 更新伝播メカニズムに登録されている各コントローラが、 ユーザ機能を活性可能／不可能(enable or disable)に するために、モデルからデータを取得する。たとえば、モ デルのデータが更新されると、続いて、データ保存のメ ニュー項目が活性化される。 • コントローラが制御を再獲得し、イベントハンドリング手続 に戻る。 chart 3-39 記述の例 例: MVCパターンの相互作用図 （シーケンス図） Controller handleEvent Model View service notify update display getData update getData この図は、MVCの動的な振る舞いのシナリオ１について、簡単のために1つの View-Controller対だけを示したものである。 chart 3-40 成果物の記述 その他の記述 • その他、ソフトウェアの成果物（中間成果物を含む）には、 さまざまな記述（ドキュメント）が作成される。 – 必要性の高いもの: そこにしか書かれていないことが書か れているもの。特に、全体構成がわかるものや、「なぜこう なってるの？」という疑問に答えてくれるもの。 – 必要性が低いもの: プログラム（ソースコード）を見ればわか ることしか書いていないもの。 • 記述の多くは、日本語などの自然言語による文章や図表 であるが、数学的裏づけのある形式的記述も有効である。 chart 3-41 成果物の記述 形式的仕様記述言語 • 数学的に裏づけられた形式的(formal)手段で検証できる ように規定された仕様記述言語。 • VDM (http://www.csr.ncl.ac.uk/vdm/) • VDMTools -- 形式手法VDMとその記述言語を支援する環境 (http://www.ifad.dk/Products/vdmtools.htm) • OBJ (http://www.comlab.ox.ac.uk/archive/obj.html) • 特に高い信頼性を求められるシステムでは、形式的仕様 記述により、仕様を数学的に検証することが有効な場合 がある。 chart 3-42 成果物の記述 ソフトウェアの記述における問題点 • • • • 書き出すとすぐに複雑になり、書ききれなくなる。 何のために何を書いた記述なのかわかりにくい。 重要なこととそうでないこととの区別がつきにくい。 担当部分だけ詳細に定義してあっても、全体の中での位 置づけや関係がわからないと、わかった気がしない。 • ソフトウェアは変更を受けやすいので、その仕様や設計 の記述も修正されるべきであるが、修正されないまま放 置されることが少なくない。 • システム外部（ドメイン）についての記述は、システムを理 解する上で重要であるにもかかわらず、意外と少ない。 chart 3-43 ここでもう一度 良い設計のための根底技術 • • • • • • • • • • 抽象化 カプセル化 情報隠蔽 モジュール化 関心の分離 結合度と凝集度 充足性、完全性、プリミティブ性 ポリシーと実装の分離 参照の一点性 分割統治 参考: POSA本(邦訳：ソフトウェアアーキテクチャ）の6.3節 chart 3-44 ソフトウェアの記述における留意点 • 一度にすべてのことを書こうとしないこと – 関心の分離、分割統治 – モジュール化、カプセル化、情報隠蔽 – 特に例外の記述には要注意。 • 必要のない詳細は書かないこと – 最終的なソースコードやデータには詳細は必要。 • 変更しやすいものは分離しておくこと – ポリシーと実装の分離 • 他にもいろいろとあると思いますが... chart 3-45 まとめ • 成果物にはどのようなものがあるか • 記述の表記法にはどのようなものがあるか • どういう場合にどういう表記法を使うか • 記述にはどのような問題点があるか • 記述する際にはどのような点に留意すればよいか chart 3-46
© Copyright 2024 ExpyDoc
