セッション 3: ソフトウェア・プロダクト

chart 3-1

セッション 3: ソフトウェア・プロダクト

ソフトウェア・エンジニアリング入門

chart 3-2

セッション 3: 目標

• ソフトウェア開発における重要な成果物（ソフトウェア・プロダクト）を特定する

• ソフトウェアの記述のための代表的な表記法や記述言語と、それらの表記法の背景にある重要な概念について、大まかに学ぶ

• ソフトウェアの記述におけるありがちな問題点について論じる

chart 3-3

成果物にはどのようなものがあるか

要求セット

1. 開発ビジョン　　説明書

2. 要求モデル

設計セット実装セット導入セット

管理セット

1. 設計モデル

2. テストモデル

3. ソフトウェア　　アーキテクチャ　　説明書

1. ソースコードの　　ベースライン

2. 関連するコンパ　　イル時ファイル3. コンポーネント　　実行可能ファイル

1. 統合製品実行　　可能ファイルの　　ベースライン2. 関連する　　実行時ファイル

3. ユーザ　　マニュアル

立案成果物運用成果物

1. 作業分解構造

2. ビジネスケース

3. リリース仕様

4. ソフトウェア開発計画

5. リリース説明6. ステータス評価

7. ソフトウェア変更指示データベース8. 導入ドキュメント

9. 環境

chart 3-4

管理セット• 管理セットは、プロセスの立案と実行に関する成果物を表現する。• 自由な形式の表記法（文書や図表）が使われる。• プロジェクト要員間、利害関係者間、プロジェクト要員と利害関係者

間の「契約」を表現するのに必要な表現であればどのようなものでも含まれる。

• 作業分解構造 : 作業の分解と経理調査のメカニズム• ビジネスケース : コスト、スケジュール、収益の予測• リリース仕様 : リリースのベースラインの対象範囲、計画、目的• ソフトウェア開発計画 : プロジェクトのプロセスインスタンス• リリース説明 : リリースのベースラインの成果• ステータス評価 : プロジェクト進捗の周期的なスナップショット• ソフトウェア変更指示 : ベースラインに対する個別の変更についての

記述• 導入ドキュメント : 導入計画、トレーニングコース、販売用資料• 環境 : ハードウェア、ソフトウェアツール、プロセス自動化… ..

成果物のセット

chart 3-5

管理セット（評価）

• 管理セットの成果物は、以下の組合せを通して評価、査定、測定が行われる。

– 関係する利害関係者によるレビュー

– 成果物の現バージョンと前バージョンの間でなされた変更（コスト、スケジュール、品質の観点から見た、管理動向とプロジェクトパフォーマンスの変化）の解析

– すべての成果物間のバランスと、特にビジネスケース成果物と開発ビジョン成果物の正確さについての種マイルストーンのデモンストレーション


chart 3-6

エンジニアリングセット : 要求セット

• 開発ビジョン説明書 :

– 開発資金提供者とプロジェクトチーム間の契約をサポートするプロジェクト対象範囲について記載したもの

• 要求モデル :

– 対象領域モデル– システム内部の仕様モデル– 後で説明する表記法を用いてモデル化

• 機能面（シナリオ） : ユースケース• 静的側面 : クラス図、 CRC カード、 ER 図等• 動的側面 : 状態遷移図、相互作用図、アクティビティ

図等


chart 3-7

エンジニアリングセット : 要求セット（評価）

• 要求セットの成果物は、以下のような観点を組合せて評価、査定、判定が行われる。– 管理セットのリリース仕様との一貫性の分析– 開発ビジョンと要求モデルとの一貫性の分析– 設計セット、実装セット、導入セット間での対応性を

調査し、異なるセット内に含まれる情報館の一貫性、完全性、意味的なバランスを評価する

– 要求成果物の現バージョンと前バージョンとの間でなされた変更の解析（履き、やり直し、欠陥除去の傾向）

– 品質の他の次元についての主観的レビュー


chart 3-8

エンジニアリングセット : 設計セット

• 設計モデル : 後述の表記法で記述– 複数の抽象レベルで構成される– 構造と振る舞い

• テストモデル : – 設計に対応するテストケースを任意の表記法で記

述• ソフトウェアアーキテクチャ説明書

– アーキテクチャの説明に関係のある情報を設計モデルから抜粋したもの


chart 3-9

エンジニアリングセット : 設計セット（評価）

• 設計セットの成果物は、以下のような観点を組合せて評価、査定、判定が行われる。– 設計モデルの内部的一貫性と品質の分析– 要求モデルとの一貫性の分析– 実装と導入の成果物セットおよび表記法へ変換して（た

とえば、対応を追跡し、ソースコード生成、コンパイル、リンクして）、それらのセット内に含まれる情報間の一貫性、完全性、意味的なバランスを評価する。

– 設計モデルの現バージョンと前バージョンとの間でなされた変更の解析

– 品質の他の次元についての主観的レビュー


chart 3-10

エンジニアリングセット : 実装セット

• 製品ソースコードのベースラインとその関連ファイル (*1)

– (*1): コンパイルスクリプト、構成管理インフラストラクチャ、データファイル

• テストソースコードのベースラインとその関連ファイル (*2)

– (*2): 入力テストデータファイル、テスト結果ファイル• コンポーネントの実行可能ファイル

– 単体、テストドライバ• 各ソースコードは、それ自身ドキュメントとなり得るもの

が望ましい。


chart 3-11

エンジニアリングセット : 実装セット（評価）

• 実装セットは人間が読める形式の成果物で、以下のような観点を組合せて評価、査定、判定が行われる。– 設計モデルとの一貫性の分析– 導入セットの表記法へ翻訳（たとえばコンパイルおよびリ

ンク）して、成果物セット間の一貫性と完全性を評価する– インスペクション、解析、デモンストレーション、テスト

を通して、コンポーネントのソースファイルまたは実行可能ファイルを関連する評価基準に照らして査定する

– コンポーネント単体にテストケースを適用し、予想結果と実際の結果を自動的に比較する

– 実装セットの現バージョンと前バージョンとの間でなされた変更の解析（破棄、やり直し、欠陥除去の傾向）


chart 3-12

エンジニアリングセット : 導入セット

• 統合製品実行可能ファイルのベースライン– 実行可能ソフトウェア– 実行に必要なデータ類（辞書、画像、音声等を含む）

• 関連する導入時ファイル– インストールスクリプト

• 関連する実行時ファイル– その実行環境に特有の実行可能データ、設定ファイル

• ユーザマニュアル• サンプル (Examples)


chart 3-13

エンジニアリングセット : 導入セット（評価）

• 導入セットは、以下のような観点を組合せて評価、査定、判定が行われる。– 要求セットに定義された利用シナリオと品質属性に照らしてテス

トを行い、２つのセット内に含まれる情報館の一貫性、完全性、意味的なバランスを評価する

– 実装セット内のコンポーネントを導入対象システムの物理的資源（プラットフォームのタイプ、数、ネットワーク構成）にマッピングする際の、パーティション分割、複製、割り当てについての戦略をテストする

– インストール、ユーザに応じた動的な再構成、本来の使用、以上管理といったユーザマニュアルに定義済みの利用シナリオに照らしてテストを行う

– 導入セットの現バージョンと前バージョンとの間でなされた変更の解析（欠陥除去の傾向、性能変化）


chart 3-14

エンジニアリングセット : 導入セット（補足）

• 導入セットの品質に影響を及ぼすが、設計セットと実装セットでは比較的把握しにくい技術的決定内容 :– 動的に再設定可能なパラメータ（バッファサイズ、サーバ数等）

– コンパイラ／リンカでの最適化の影響（空間対速度）

– 一定の割り当て戦略下での性能（動的負荷分散等）

– 仮想マシン上の制約（ファイル記述子、ヒープサイズ等）

– プロセスレベルの並行性の問題（デッドロック条件と競合条件）

– プラットフォームごとの性能や振る舞いの違い• こうしたコンフィギュレーション情報をソースコード実装

とどれだけ切り離して記述できるか、重要な課題となる。


chart 3-15

記述、表記法、記述言語

• ソフトウェアの成果物は、すべて「記述」である。• 記述の目的、注目対象、適用範囲等によって、さまざま

な表記法、記述言語がある。• 状況に合わせて、適切な表記法、記述言語を使用する。• ここでは、要求モデルや設計モデルを記述するために使

用される、代表的な表記法、記述言語を簡単に紹介する。– シナリオ記述用 : ユースケース– 静的側面の記述用 : CRC カード、クラス図、 ER 図等 – 動的側面の記述用 : 状態遷移図、相互作用図等– 汎用 : 木構造図、表、ラフなスケッチ、文

成果物の記述

chart 3-16

目的に合わせた標準的な表記を用いる理由

• 担当者の頭の中だけにあっても、何らかの方法で記述しなければ、他の人にはわからない。

• 表記がバラバラだと誤解や混乱が生じやすい。• 行き当たりばったりの表記で記述すると、本来必要なこ

とを記述し忘れたり考慮し忘れたりすることがある。• 目的に合わない表記で記述すると、うまく記述できな

かったり、かえって複雑になったりする。• 目的に合わせた標準的な表記で記述されていれば、関係

者は適切に批評できる。互いに議論しあうことによって、問題点に早く気づいたり、記述内容が質的に高まることが期待できる。

記述の表記

chart 3-17

ユースケース

• ユーザの一般的な目的に照らして結びつけられた一群のシナリオ• シナリオとは、ユーザとシステム間のやりとりを表す一連の手順。• たとえば、 Web上にオンラインショップを持っている場合において :

– 「製品を購入する」という一つのシナリオが考えられる :• 顧客がカタログに目を通し、ショッピングカートに商品を入れて

いく。支払の際、顧客は配達方法とクレジット番号を入力し… .

– 「購入成功」「認証失敗」という２つのシナリオを持つ、「製品を購入する」という単一のユースケースが考えられる。

• 一つのユースケースについて起こり得るすべてのシナリオを考えると非常に複雑になることがあるので、本当に役立つ要素だけを取り上げるのが有用。

※このスライドは、マーチン・ファウラー「 UML モデリングのエッセンス第２版」 , 翔泳社 , 2000, p.35 を参考にしました。

シナリオ記述の表記

chart 3-18

ユースケースの例• 製品を購入する : 購入成功の場合

– 1. 顧客がカタログを読んで買う商品を選択する– 2. 顧客が精算を指示する（チェックアウトする）– 3. 顧客が配達方法（住所と配達日）を入力する– 4. システムが送料を含めた合計金額を表示する– 5. 顧客がクレジット番号を入力する– 6. システムがクレジット情報を入力する– 7. システムが直ちに購入内容を販売に通知する– 8. システムが顧客に確認の電子メールを送信する

• バリエーション : 認証の失敗– 手順 6 でシステムがクレジットによる購入を認証できなかった場合、顧客は再度クレ

ジット情報を入力してリトライできる• バリエーション : 定期的な顧客

– 3a. システムが最新の発送情報、金額情報、およびクレジット情報の最後の 4桁を表示する

– 3b. 顧客は規定値を受け入れることも変更することもある– ステップ 6 で主シナリオに戻る

※このスライドは、マーチン・ファウラー「 UML モデリングのエッセンス第２版」 , 翔泳社 , 2000, p.37 を引用しました。

シナリオ記述の表記

chart 3-19

CRC カード

• CRC とは Class-Responsibility-Collaborator の略。• クラスの名前、責任（役割）、他のどのクラスと協調

（協同作業）するかの３つを明らかにしたカード。• 要求分析定義の段階では、重要な「もの」をクラスとし

てカードに書き、グループでロールプレイすることで、必要な機能やサービスを提供するために必要なクラスの洗い出しや役割の確認をすることができる。

• 設計段階では、プログラムに直結するクラスをカードに書くことで、クラスの役割や協調関係を明らかにできる。

• テスト段階では、プログラミングされたクラスがその役割をきちんと果たしているか確認するために使用できる。

静的側面の表記

chart 3-20

CRC カードの表記

注文

• 在庫があるかチェックす

る

• 価格を決定する

• 有効な支払かチェックす

る

• 納入先住所へ配送する

注文明細

スーパクラス : サブクラス :

3 x 5 インチのインデックスカードを使っている人が多いといわれています。

クラス名

顧客

協調者(Collaborator)

配送

あれば親クラスや子クラスを記入する

責務(Responsibility)

※この図は、マーチン・ファウラー「 UML モデリングのエッセンス第２版」 , 翔泳社 , 2000, p.68 を参考にしました。


chart 3-21

クラス図

• クラス図は、ソフトウェアの静的な側面を、クラスの属性やクラスが提供するサービス、クラス間の性質の相違や役割関係等に注目して構造化した図である。

• クラス図は、ドメイン分析、要求仕様分析、設計／実装のそれぞれの段階で使える。それぞれの段階で観点が異なるので異なるモデルとなる。それぞれ必要なものをクラスとして取り上げ、図化する。

• あらゆるものに対してクラス図を作成しようとせず、主要な分野に集中して作成するのが得策。

• 1枚の図ですべてのクラス関係を表そうしないこと。


chart 3-22

クラス図の構成要素

• クラス : ものごとを共通の性質でくくったもの– クラス名– 属性リスト : クラスが覚えておくべき要素、項目– 操作リスト : クラスが自分でしなければいけない処理

• クラス間の汎化／特殊化（継承関係）• クラス間の関連

– ロール名 : 役割の名前– 多重度 : 厳密に 1 、多 (0 以上 ) 、オプション (0 か 1) 、値範囲

指定、集約、コンポジション

• インスタンス : クラスを具体化したもの（オブジェクト）


chart 3-23

ER 図（実体関連図）

• ER 図（実体関連図）は、システムが保存すべき情報を整理するため、 Entity( 実体 ) と Relationship （関連）に着目して構造化し、図化したものである。

• リレーショナルデータベース (RDB) のスキーマ設計では昔から良く使われている。

• 実体 : 「顧客」や「製品」のように、何らかの意味的にまとまりのある属性を持った独立した「個別のもの」を指す。

• 関連 : 「顧客」が「製品」を「購入する」という場合に、「購入」が関連となる。

• 基数 : 1 対 1 、 1 対多、多対多かを表す。 RDB では基数（カーディナリティ）が問題となるので、基数も記述する。

• クラス図は ER 図を元に発展したので、クラス図と ER 図を両方書く必要はないが、 RDB のスキーマ設計では必要かもしれない。


chart 3-24

「 0,N 」はカーディナリティ（結合度、多重度）という。顧客は注文をしないか複数回注文をすることがあるので、「顧客」から見ると「注文」は 0,N

ER 図（実体関連図）の表記

発注

注文

注文番号受付年月日担当者

明細

注文明細

明細番号数量値引き

記載

顧客

顧客番号顧客名所在地電話番号与信限度額

0,N 1,1

1,N

1,1製品

製品番号製品名単価製造元

1,1 0,N

四角形はエンティティ（実体）を表す。線の上部がエンティティ名、下部がアトリビュート（属性）名。下線付き属性は「 unique key 」。

ひし形は Relationship（関連、関係）を表す。

※カーディナリティの表現には他にもいろいろありますが、ここではこのような表記を紹介します。※この図は、大木幹雄「ソフトウェア設計の基礎」 ,日本理工出版会 , 1999, p.151 を参考にしました。


chart 3-25

相互作用図

• 相互作用図は、何らかの振る舞い（１つのユースケース等）を為すために、オブジェクト群がどのように協調して相互作用を行うかを説明するための図である。

• 図を見るだけでメッセージをすぐに読み取ることができる。• ただし、相互作用図は数ある振る舞いの実現方法の例示に過ぎない。代替方法の検討には、 CRC カードによるロールプレイが便利。

• 複数のユースケースに存在する１つのオブジェクトの振る舞いを見たいときは状態遷移図を使う。複数のユースケースやスレッドにまたがる振る舞いを見たいときには、アクティビティ図（ペトリネットの UML改良版）を使うと良い。

動的側面の表記

chart 3-26

状態遷移図

• 状態図とは、何かについて状態の遷移を表した図。• 以下のことを明らかにしたい場合に描く :

– その「何か」にはどういう状態があるのか : 状態– 状態が遷移する「トリガ（きっかけ）」は何か :

イベント– 状態が遷移すると何が起きるのか : アクション

• 何についても描けるが、興味深い振る舞いをするものに絞って描くのが得策。たとえば :

– なんらかの制御 (control) をするオブジェクト– ユーザインタフェース


chart 3-27

状態遷移図の表記

状態遷移図には何種類もの表記がありますが、ここでは、 UML 1.3 で採用されている、David Harel (1987) の表記（を元に Rumbaugh が拡張した表記）を紹介します。David Harel: “Statecharts: A Visual Formalism for Complex Systems.” 　 In Science of Computer Programming, Vol.8, 1987.

スーパー状態名

状態名

状態名

entry/ 入状アクション

do/ アクティビティ

exit/退状アクション

イベント / アクション（引数リスト）

イベント名（引数リスト）[条件 ]/ アクション

※遷移ラベルにイベントが含まれていない場合は、　所定の状態に関連付けられたアクティビティが完了すると直ちにその遷移が発火する。


chart 3-28

do: 登録制度の説明

状態遷移図の例

会員証の提示待ちdo: 提示を要求

レンタル注文

提示［会員期限内］

レンタル商品記録中

do: 商品番号の入力

記録完了 / 確認

入会希望［会員証なし］

提示［会員期限切れ］

“レンタルショップ受付係” の状態遷移図記述例

更新依頼

更新拒否

登録票記入待ちentry: 登録票を渡す

仮払い料金精算待ちentry: 請求金額の提示do: 仮払売上金の入力

精算 OK

記入完了 / 登録内容確認

do: 更新意思表示待ち

※この図は、大木幹雄「ソフトウェア設計の基礎」 ,日本理工出版会 , 1999, p.170 を参考にしました。


chart 3-29

アクティビティ図

• アクティビティ図とは、アクティビティ、すなわち、何かの動作を行っている状態を中核にして、流れを表した図。

• ワークフローモデリング、ペトリネットなどに由来する概念を組合せたもの。

• ワークフローを接続したり、並行処理を伴う振る舞いを記述するのに特に役に立つ。

• ある処理の流れの中で、非同期で（並行に）動作してもかまわないものがあれば、複数のスレッドに「フォーク」し、それぞれのスレッドが終了した後、同期する必要がある時に「ジョイン」させて終了させる。


chart 3-30

アクティビティ図の表記

注文を受け付ける

注文を処理する請求書を送付する

即発送する通常発送する支払を確認する

開始状態

フォーク

注文を終了する

終了状態

ジョイン

分岐

マージ

アクティビティ

[急ぎの注文 ] [else]

※この図は、マーチン・ファウラー「 UML モデリングのエッセンス第２版」 , 翔泳社 , 2000, p.114 を参考にしました。


chart 3-31

例 : MVC パターン

• これから数枚のスライドを使って、 CRC カード、クラス図、相互作用図の例を示します。

• 題材としては、対話型システムで良く使われるアーキテクチャパターン「 MVC(Model-View-Controller)パターン」を取り上げます。

• MVC パターンが最初に導入されたのは、 Smalltalk-80 プログラミング環境です。

※ここから数枚のスライドにわたる、 MVC パターンの例については、 F.ブッシュマン他「ソフトウェアアーキテクチャ」（略称 :POSA本） , トッパン , 1999, p.120-139 を参考にしました。

記述の例

chart 3-32

例 : MVC パターンのコンテキストと課題

• コンテキスト : – 人間とコンピュータのインタフェースに柔軟性を持たせた対話型アプリケーション。

• 課題 :– ユーザインタフェースは要求仕様の変更の影響を受けやすく、またプラットフォームにより異なることが多いので柔軟性を持たせたい。

– ユーザインタフェースとシステムの機能中核部分の結合度が高いと、誤りを潜在的に持つ可能性が高くなり、変更や保守が困難である。

記述の例

chart 3-33

例 : MVC パターンの課題のフォース (force)

• 以下に述べるフォースがこの課題の解決策に影響を与える。– 同一情報を別々のウィンドウに異なる形式で表示する必要がある。

たとえば、棒グラフや円グラフという形式で情報が表示される。– データに対して行われた操作が、直ちにアプリケーションの表示と

動作に反映されなければならない。– ユーザインタフェースの変更を容易に行うことができる。また、実

行時においても、その変更を行うことができることが望ましい。– 異なるルック＆フィール標準のサポートやそれらの間の移植が、ア

プリケーションの中核となるコードに影響してはならない。

記述の例

chart 3-34

例 : MVC パターンの解決策

• 対話型アプリケーションを、処理、出力、入力の３つの領域を担当するコンポーネントに分ける。それぞれ、 Model 、 View 、 Controller が担当する。

• Model は、アプリケーションの核となるデータと機能をカプセル化する。特定の出力表現や入力動作からは独立したものである。

• View は、情報をユーザに表示することについて責任を持つ。そのために、 Model からデータを取得する。 1 つの Model について複数の View を定義できる。

• 個々の Viewごとに Controller が存在する。 Controller はマウスやキーボードなどからの入力を受取る役割を担う。 Controller は受取ったイベントを Model や View に対するサービス要求に翻訳する。ユーザは、 Controller を通じてのみ、システムと対話できる。

記述の例

chart 3-35

例 : MVC パターンの解決策（続き）

• View と Controller を Model から分離することによって、同一モデルに対して複数の View を持たせることが可能になる。

• 1 つの View と関連づけられている Controller を通じてユーザが Model を変更すると、このデータに依存するすべての View はその変更を反映させた表示を行わなくてはならない。

• したがって、 Model のデータが変更された場合にはいつでも、モデルがそれをすべての View に通知するようにする。

• その通知を受けて、 View が Model から新しいデータを取り出し、表示している情報を更新する。これを更新伝播機構と呼ぶ。

• この解決策の静的側面を CRC カードとクラス図で、動的側面をシナリオと相互作用図（シーケンス図）で説明する。

記述の例

chart 3-36

例 : MVC パターンの CRC カード

クラス

責務

Model

・アプリケーションの機能中核を提供する。・ View と Controller を登録する。・データ変更をコンポーネントに通知する。

協調者・ View・ Controller

クラス

責務

View

・ Controller を生成して初期化する。・情報をユーザに表示する。・更新手続を実装する。・ Model のデータを取得する。

協調者・ Controller・ Model

クラス

責務

Controller

・ユーザ入力をイベントとして受取る。・イベントを Modelへのリクエスト、あるいは、 Viewへのリクエストに変換する。・（必要に応じて）更新用手続を実装する。

協調者・ View・ Model

CRC カード : Class-Responsibility-Collaborator card: クラス -責務 -協調者カード [BeCu89]

CRC カードは、アプリケーションにおける重要なクラスを特定し、それぞれの責務と協調者を明らかにするのに役立つ。

「クラス」とあるが、概念レベルのクラスやコンポーネントの洗い出しに使用しても有効である。

紙面の都合で協調者を右上に書いているが、責務ごとに協調者を書くのが本来の姿である。

記述の例

chart 3-37

例 : MVC パターンのクラス図

ModelcoreDatasetOfObservers

attach(Observer)detach(Observer)notifygetDataservice

update を呼び出す

Observer

update

View

myModelmyControllerInitialize(Model)makeControlleractivatedisplayupdate

Controller

myModelmyView

Initialize(Model, View)handleEventupdate

getData と関連付ける生成する

表示を操作する

サービス呼び出しと関連付ける

クラスを表す。上段はクラス名、中段は属性名、下段は操作。

Observer はView や Controller を「汎化」したものであることを表す

記述の例

chart 3-38

例 : MVC の動的な振る舞いを描いたシナリオ１

• このシナリオは、モデルを変化させるユーザ入力が更新伝播メカニズムをどのように駆動するかを示すものである。

• コントローラは、イベントハンドリング手続でユーザ入力を受取り、そのイベントを解釈し、モデルのサービス手続を活性化する。

• モデルは、リクエストされたサービスを実行する。この結果、モデルの内部データが変化する。

• モデルは、更新伝播メカニズムに登録されたすべてのビューとコントローラによって行われる。

• （次スライドに続く）

記述の例

chart 3-39

例 : MVC の動的な振る舞いを描いたシナリオ１

（続き）• 各ビューがモデルに更新データをリクエストし、自

らを画面に再表示する。• 更新伝播メカニズムに登録されている各コントロー

ラが、ユーザ機能を活性可能／不可能 (enable or disable) にするために、モデルからデータを取得する。たとえば、モデルのデータが更新されると、続いて、データ保存のメニュー項目が活性化される。

• コントローラが制御を再獲得し、イベントハンドリング手続に戻る。

記述の例

chart 3-40

例 : MVC パターンの相互作用図（シーケンス図）

Controller Model View

handleEventservice

update

getData

notifyupdate display

getData

この図は、 MVC の動的な振る舞いのシナリオ１について、簡単のために 1 つのView-Controller 対だけを示したものである。

記述の例

chart 3-41

その他の記述

• その他、ソフトウェアの成果物（中間成果物を含む）には、さまざまな記述（ドキュメント）が作成される。– 必要性の高いもの : そこにしか書かれていないことが書

かれているもの。特に、全体構成がわかるものや、「なぜこうなってるの？」という疑問に答えてくれるもの。

– 必要性が低いもの : プログラム（ソースコード）を見ればわかることしか書いていないもの。

• 記述の多くは、日本語などの自然言語による文章や図表であるが、数学的裏づけのある形式的記述も有効である。

成果物の記述

chart 3-42

形式的仕様記述言語

• 数学的に裏づけられた形式的 (formal)手段で検証できるように規定された仕様記述言語。

• VDM (http://www.csr.ncl.ac.uk/vdm/)• VDMTools -- 形式手法 VDM とその記述言語を支援する環境 (htt

p://www.ifad.dk/Products/vdmtools.htm)• OBJ (http://www.comlab.ox.ac.uk/archive/obj.html)• 特に高い信頼性を求められるシステムでは、形式的

仕様記述により、仕様を数学的に検証することが有効な場合がある。

成果物の記述

chart 3-43

ソフトウェアの記述における問題点

• 書き出すとすぐに複雑になり、書ききれなくなる。• 何のために何を書いた記述なのかわかりにくい。• 重要なこととそうでないこととの区別がつきにくい。• 担当部分だけ詳細に定義してあっても、全体の中での位置づけや関係がわからないと、わかった気がしない。

• ソフトウェアは変更を受けやすいので、その仕様や設計の記述も修正されるべきであるが、修正されないまま放置されることが少なくない。

• システム外部（ドメイン）についての記述は、システムを理解する上で重要であるにもかかわらず、意外と少ない。

成果物の記述

chart 3-44

ここでもう一度良い設計のための根底技術• 抽象化• カプセル化• 情報隠蔽• モジュール化• 関心の分離• 結合度と凝集度• 充足性、完全性、プリミティブ性• ポリシーと実装の分離• 参照の一点性• 分割統治

参考 : POSA本 (邦訳：ソフトウェアアーキテクチャ）の 6.3節

chart 3-45

ソフトウェアの記述における留意点

• 一度にすべてのことを書こうとしないこと– 関心の分離、分割統治– モジュール化、カプセル化、情報隠蔽– 特に例外の記述には要注意。

• 必要のない詳細は書かないこと– 最終的なソースコードやデータには詳細は必要。

• 変更しやすいものは分離しておくこと– ポリシーと実装の分離

• 他にもいろいろとあると思いますが ...

chart 3-46

まとめ

• 成果物にはどのようなものがあるか

• 記述の表記法にはどのようなものがあるか

• どういう場合にどういう表記法を使うか

• 記述にはどのような問題点があるか

• 記述する際にはどのような点に留意すればよいか

セッション 3: ソフトウェア・プロダクト

Documents