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

1. セッション 3:ソフトウェア・プロダクト ソフトウェア・エンジニアリング入門

2. セッション 3:目標 • ソフトウェア開発における重要な成果物（ソフトウェア・プロダクト）を特定する • ソフトウェアの記述のための代表的な表記法や記述言語と、それらの表記法の背景にある重要な概念について、大まかに学ぶ • ソフトウェアの記述におけるありがちな問題点について論じる

3. 成果物にはどのようなものがあるか 要求セット 設計セット 実装セット 導入セット 1.開発ビジョン 　　説明書 1.設計モデル 1.ソースコードの 　　ベースライン 1.統合製品実行 　　可能ファイルの 　　ベースライン 2. テストモデル 2.関連するコンパ 　　イル時ファイル 2. 要求モデル 3. ソフトウェア 　　アーキテクチャ 　　説明書 2.関連する 　　実行時ファイル 3. コンポーネント 　　実行可能ファイル 3. ユーザ 　　マニュアル 管理セット 立案成果物 運用成果物 1.作業分解構造 5.リリース説明 6.ステータス評価 2.ビジネスケース 7.ソフトウェア変更指示データベース 3.リリース仕様 8.導入ドキュメント 4.ソフトウェア開発計画 9.環境

4. 成果物のセット 管理セット • 管理セットは、プロセスの立案と実行に関する成果物を表現する。 • 自由な形式の表記法（文書や図表）が使われる。 • プロジェクト要員間、利害関係者間、プロジェクト要員と利害関係者間の「契約」を表現するのに必要な表現であればどのようなものでも含まれる。 • 作業分解構造: 作業の分解と経理調査のメカニズム • ビジネスケース: コスト、スケジュール、収益の予測 • リリース仕様: リリースのベースラインの対象範囲、計画、目的 • ソフトウェア開発計画: プロジェクトのプロセスインスタンス • リリース説明: リリースのベースラインの成果 • ステータス評価: プロジェクト進捗の周期的なスナップショット • ソフトウェア変更指示: ベースラインに対する個別の変更についての記述 • 導入ドキュメント: 導入計画、トレーニングコース、販売用資料 • 環境: ハードウェア、ソフトウェアツール、プロセス自動化…..

5. 成果物のセット 管理セット（評価） • 管理セットの成果物は、以下の組合せを通して評価、査定、測定が行われる。 • 関係する利害関係者によるレビュー • 成果物の現バージョンと前バージョンの間でなされた変更（コスト、スケジュール、品質の観点から見た、管理動向とプロジェクトパフォーマンスの変化）の解析 • すべての成果物間のバランスと、特にビジネスケース成果物と開発ビジョン成果物の正確さについての種マイルストーンのデモンストレーション

6. 成果物のセット エンジニアリングセット: 要求セット • 開発ビジョン説明書: • 開発資金提供者とプロジェクトチーム間の契約をサポートするプロジェクト対象範囲について記載したもの • 要求モデル: • 対象領域モデル • システム内部の仕様モデル • 後で説明する表記法を用いてモデル化 • 機能面（シナリオ）: ユースケース • 静的側面: クラス図、CRCカード、ER図等 • 動的側面: 状態遷移図、相互作用図、アクティビティ図等

7. 成果物のセット エンジニアリングセット: 要求セット（評価） • 要求セットの成果物は、以下のような観点を組合せて評価、査定、判定が行われる。 • 管理セットのリリース仕様との一貫性の分析 • 開発ビジョンと要求モデルとの一貫性の分析 • 設計セット、実装セット、導入セット間での対応性を調査し、異なるセット内に含まれる情報館の一貫性、完全性、意味的なバランスを評価する • 要求成果物の現バージョンと前バージョンとの間でなされた変更の解析（履き、やり直し、欠陥除去の傾向） • 品質の他の次元についての主観的レビュー

8. 成果物のセット エンジニアリングセット: 設計セット • 設計モデル: 後述の表記法で記述 • 複数の抽象レベルで構成される • 構造と振る舞い • テストモデル: • 設計に対応するテストケースを任意の表記法で記述 • ソフトウェアアーキテクチャ説明書 • アーキテクチャの説明に関係のある情報を設計モデルから抜粋したもの

9. 成果物のセット エンジニアリングセット: 設計セット（評価） • 設計セットの成果物は、以下のような観点を組合せて評価、査定、判定が行われる。 • 設計モデルの内部的一貫性と品質の分析 • 要求モデルとの一貫性の分析 • 実装と導入の成果物セットおよび表記法へ変換して（たとえば、対応を追跡し、ソースコード生成、コンパイル、リンクして）、それらのセット内に含まれる情報間の一貫性、完全性、意味的なバランスを評価する。 • 設計モデルの現バージョンと前バージョンとの間でなされた変更の解析 • 品質の他の次元についての主観的レビュー

10. 成果物のセット エンジニアリングセット: 実装セット • 製品ソースコードのベースラインとその関連ファイル(*1) • (*1): コンパイルスクリプト、構成管理インフラストラクチャ、データファイル • テストソースコードのベースラインとその関連ファイル(*2) • (*2): 入力テストデータファイル、テスト結果ファイル • コンポーネントの実行可能ファイル • 単体、テストドライバ • 各ソースコードは、それ自身ドキュメントとなり得るものが望ましい。

11. 成果物のセット エンジニアリングセット: 実装セット（評価） • 実装セットは人間が読める形式の成果物で、以下のような観点を組合せて評価、査定、判定が行われる。 • 設計モデルとの一貫性の分析 • 導入セットの表記法へ翻訳（たとえばコンパイルおよびリンク）して、成果物セット間の一貫性と完全性を評価する • インスペクション、解析、デモンストレーション、テストを通して、コンポーネントのソースファイルまたは実行可能ファイルを関連する評価基準に照らして査定する • コンポーネント単体にテストケースを適用し、予想結果と実際の結果を自動的に比較する • 実装セットの現バージョンと前バージョンとの間でなされた変更の解析（破棄、やり直し、欠陥除去の傾向）

12. 成果物のセット エンジニアリングセット: 導入セット • 統合製品実行可能ファイルのベースライン • 実行可能ソフトウェア • 実行に必要なデータ類（辞書、画像、音声等を含む） • 関連する導入時ファイル • インストールスクリプト • 関連する実行時ファイル • その実行環境に特有の実行可能データ、設定ファイル • ユーザマニュアル • サンプル (Examples)

13. 成果物のセット エンジニアリングセット: 導入セット（評価） • 導入セットは、以下のような観点を組合せて評価、査定、判定が行われる。 • 要求セットに定義された利用シナリオと品質属性に照らしてテストを行い、２つのセット内に含まれる情報館の一貫性、完全性、意味的なバランスを評価する • 実装セット内のコンポーネントを導入対象システムの物理的資源（プラットフォームのタイプ、数、ネットワーク構成）にマッピングする際の、パーティション分割、複製、割り当てについての戦略をテストする • インストール、ユーザに応じた動的な再構成、本来の使用、以上管理といったユーザマニュアルに定義済みの利用シナリオに照らしてテストを行う • 導入セットの現バージョンと前バージョンとの間でなされた変更の解析（欠陥除去の傾向、性能変化）

14. 成果物のセット エンジニアリングセット: 導入セット（補足） • 導入セットの品質に影響を及ぼすが、設計セットと実装セットでは比較的把握しにくい技術的決定内容: • 動的に再設定可能なパラメータ（バッファサイズ、サーバ数等） • コンパイラ／リンカでの最適化の影響（空間 対 速度） • 一定の割り当て戦略下での性能（動的負荷分散等） • 仮想マシン上の制約（ファイル記述子、ヒープサイズ等） • プロセスレベルの並行性の問題（デッドロック条件と競合条件） • プラットフォームごとの性能や振る舞いの違い • こうしたコンフィギュレーション情報をソースコード実装とどれだけ切り離して記述できるか、重要な課題となる。

15. 成果物の記述 記述、表記法、記述言語 • ソフトウェアの成果物は、すべて「記述」である。 • 記述の目的、注目対象、適用範囲等によって、さまざまな表記法、記述言語がある。 • 状況に合わせて、適切な表記法、記述言語を使用する。 • ここでは、要求モデルや設計モデルを記述するために使用される、代表的な表記法、記述言語を簡単に紹介する。 • シナリオ記述用: ユースケース • 静的側面の記述用: CRCカード、クラス図、ER図等 • 動的側面の記述用: 状態遷移図、相互作用図等 • 汎用: 木構造図、表、ラフなスケッチ、文

16. 記述の表記 目的に合わせた標準的な表記を用いる理由 • 担当者の頭の中だけにあっても、何らかの方法で記述しなければ、他の人にはわからない。 • 表記がバラバラだと誤解や混乱が生じやすい。 • 行き当たりばったりの表記で記述すると、本来必要なことを記述し忘れたり考慮し忘れたりすることがある。 • 目的に合わない表記で記述すると、うまく記述できなかったり、かえって複雑になったりする。 • 目的に合わせた標準的な表記で記述されていれば、関係者は適切に批評できる。互いに議論しあうことによって、問題点に早く気づいたり、記述内容が質的に高まることが期待できる。

17. シナリオ記述の表記 ユースケース • ユーザの一般的な目的に照らして結びつけられた一群のシナリオ • シナリオとは、ユーザとシステム間のやりとりを表す一連の手順。 • たとえば、Web上にオンラインショップを持っている場合において: • 「製品を購入する」という一つのシナリオが考えられる: • 顧客がカタログに目を通し、ショッピングカートに商品を入れていく。支払の際、顧客は配達方法とクレジット番号を入力し…. • 「購入成功」「認証失敗」という２つのシナリオを持つ、「製品を購入する」という単一のユースケースが考えられる。 • 一つのユースケースについて起こり得るすべてのシナリオを考えると非常に複雑になることがあるので、本当に役立つ要素だけを取り上げるのが有用。 ※このスライドは、マーチン・ファウラー「UMLモデリングのエッセンス第２版」, 翔泳社, 2000, p.35 を参考にしました。

18. シナリオ記述の表記 ユースケースの例 • 製品を購入する: 購入成功の場合 • 1. 顧客がカタログを読んで買う商品を選択する • 2. 顧客が精算を指示する（チェックアウトする） • 3. 顧客が配達方法（住所と配達日）を入力する • 4. システムが送料を含めた合計金額を表示する • 5. 顧客がクレジット番号を入力する • 6. システムがクレジット情報を入力する • 7. システムが直ちに購入内容を販売に通知する • 8. システムが顧客に確認の電子メールを送信する • バリエーション: 認証の失敗 • 手順6でシステムがクレジットによる購入を認証できなかった場合、顧客は再度クレジット情報を入力してリトライできる • バリエーション: 定期的な顧客 • 3a. システムが最新の発送情報、金額情報、およびクレジット情報の最後の4桁を表示する • 3b. 顧客は規定値を受け入れることも変更することもある • ステップ6で主シナリオに戻る ※このスライドは、マーチン・ファウラー「UMLモデリングのエッセンス第２版」, 翔泳社, 2000, p.37 を引用しました。

19. 静的側面の表記 CRCカード • CRCとは Class-Responsibility-Collaborator の略。 • クラスの名前、責任（役割）、他のどのクラスと協調（協同作業）するか の３つを明らかにしたカード。 • 要求分析定義の段階では、重要な「もの」をクラスとしてカードに書き、グループでロールプレイすることで、必要な機能やサービスを提供するために必要なクラスの洗い出しや役割の確認をすることができる。 • 設計段階では、プログラムに直結するクラスをカードに書くことで、クラスの役割や協調関係を明らかにできる。 • テスト段階では、プログラミングされたクラスがその役割をきちんと果たしているか確認するために使用できる。

20. 静的側面の表記 CRCカードの表記 クラス名 あれば親クラスや 子クラスを記入する 注文 スーパクラス: サブクラス: 協調者 (Collaborator) • 在庫があるかチェックする • 価格を決定する • 有効な支払かチェックする • 納入先住所へ配送する 注文明細 責務 (Responsibility) 顧客 配送 3 x 5 インチのインデックスカードを使っている人が多いといわれています。 ※この図は、マーチン・ファウラー「UMLモデリングのエッセンス第２版」, 翔泳社, 2000, p.68 を参考にしました。

21. 静的側面の表記 クラス図 • クラス図は、ソフトウェアの静的な側面を、クラスの属性やクラスが提供するサービス、クラス間の性質の相違や役割関係等に注目して構造化した図である。 • クラス図は、ドメイン分析、要求仕様分析、設計／実装のそれぞれの段階で使える。それぞれの段階で観点が異なるので異なるモデルとなる。それぞれ必要なものをクラスとして取り上げ、図化する。 • あらゆるものに対してクラス図を作成しようとせず、主要な分野に集中して作成するのが得策。 • 1枚の図ですべてのクラス関係を表そうしないこと。

22. 静的側面の表記 クラス図の構成要素 • クラス: ものごとを共通の性質でくくったもの • クラス名 • 属性リスト: クラスが覚えておくべき要素、項目 • 操作リスト: クラスが自分でしなければいけない処理 • クラス間の汎化／特殊化 （継承関係） • クラス間の関連 • ロール名: 役割の名前 • 多重度: 厳密に1、多(0以上)、オプション(0か1)、値範囲指定、集約、コンポジション • インスタンス: クラスを具体化したもの（オブジェクト）

23. 静的側面の表記 ER図（実体関連図） • ER図（実体関連図）は、システムが保存すべき情報を整理するため、Entity(実体)とRelationship（関連）に着目して構造化し、図化したものである。 • リレーショナルデータベース(RDB)のスキーマ設計では昔から良く使われている。 • 実体: 「顧客」や「製品」のように、何らかの意味的にまとまりのある属性を持った独立した「個別のもの」を指す。 • 関連: 「顧客」が「製品」を「購入する」という場合に、「購入」が関連となる。 • 基数: 1対1、1対多、多対多かを表す。RDBでは基数（カーディナリティ）が問題となるので、基数も記述する。 • クラス図はER図を元に発展したので、クラス図とER図を両方書く必要はないが、RDBのスキーマ設計では必要かもしれない。

24. 顧客 発注 顧客番号 顧客名 所在地 電話番号 与信限度額 製品 製品番号 記載 製品名 単価 製造元 静的側面の表記 ER図（実体関連図）の表記 四角形はエンティティ（実体） を表す。線の上部が エンティティ名、下部が アトリビュート（属性）名。 下線付き属性は「unique key」。 注文 注文番号 0,N 1,1 受付年月日 担当者 ひし形は Relationship （関連、関係）を表す。 1,N 明細 1,1 「0,N」はカーディナリティ （結合度、多重度）という。 顧客は注文をしないか 複数回注文をすることが あるので、 「顧客」から見ると 「注文」は0,N 注文明細 0,N 1,1 明細番号 数量 値引き ※カーディナリティの表現には他にもいろいろありますが、ここではこのような表記を紹介します。 ※この図は、大木幹雄「ソフトウェア設計の基礎」,日本理工出版会, 1999, p.151を参考にしました。

25. 動的側面の表記 相互作用図 • 相互作用図は、何らかの振る舞い（１つのユースケース等）を為すために、オブジェクト群がどのように協調して相互作用を行うかを説明するための図である。 • 図を見るだけでメッセージをすぐに読み取ることができる。 • ただし、相互作用図は数ある振る舞いの実現方法の例示に過ぎない。代替方法の検討には、CRCカードによるロールプレイが便利。 • 複数のユースケースに存在する１つのオブジェクトの振る舞いを見たいときは状態遷移図を使う。複数のユースケースやスレッドにまたがる振る舞いを見たいときには、アクティビティ図（ペトリネットのUML改良版）を使うと良い。

26. 動的側面の表記 状態遷移図 • 状態図とは、何かについて状態の遷移を表した図。 • 以下のことを明らかにしたい場合に描く: • その「何か」にはどういう状態があるのか: 状態 • 状態が遷移する「トリガ（きっかけ）」は何か: イベント • 状態が遷移すると何が起きるのか: アクション • 何についても描けるが、興味深い振る舞いをするものに絞って描くのが得策。たとえば: • なんらかの制御(control)をするオブジェクト • ユーザインタフェース

27. スーパー状態名 状態名 イベント名（引数リスト） [条件]/アクション 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.

28. 会員証の提示待ち do: 提示を要求 登録票記入待ち entry: 登録票を渡す レンタル商品記録中 do: 商品番号の入力 仮払い料金精算待ち entry: 請求金額の提示 do: 仮払売上金の入力 動的側面の表記 状態遷移図の例 “レンタルショップ受付係” の状態遷移図記述例 レンタル注文 入会希望［会員証なし］ do: 登録制度の説明 提示［会員期限切れ］ 更新依頼 do: 更新意思表示待ち 更新拒否 提示［会員期限内］ 記入完了 / 登録内容確認 精算OK 記録完了 / 確認 ※この図は、大木幹雄「ソフトウェア設計の基礎」,日本理工出版会, 1999, p.170を参考にしました。

29. 動的側面の表記 アクティビティ図 • アクティビティ図とは、アクティビティ、すなわち、何かの動作を行っている状態を中核にして、流れを表した図。 • ワークフローモデリング、ペトリネットなどに由来する概念を組合せたもの。 • ワークフローを接続したり、並行処理を伴う振る舞いを記述するのに特に役に立つ。 • ある処理の流れの中で、非同期で（並行に）動作してもかまわないものがあれば、複数のスレッドに「フォーク」し、それぞれのスレッドが終了した後、同期する必要がある時に「ジョイン」させて終了させる。

30. 動的側面の表記 アクティビティ図の表記 開始状態 注文を受け付ける アクティビティ フォーク 注文を処理する 請求書を送付する 分岐 [急ぎの注文] [else] 即発送する 通常発送する 支払を確認する ジョイン マージ 注文を終了する ※この図は、マーチン・ファウラー「UMLモデリングのエッセンス第２版」, 翔泳社, 2000, p.114を参考にしました。 終了状態

31. 記述の例 例: MVCパターン • これから数枚のスライドを使って、CRCカード、クラス図、相互作用図の例を示します。 • 題材としては、対話型システムで良く使われるアーキテクチャパターン 「MVC(Model-View-Controller)パターン」を取り上げます。 • MVCパターンが最初に導入されたのは、Smalltalk-80プログラミング環境です。 ※ここから数枚のスライドにわたる、MVCパターンの例については、F.ブッシュマン他「ソフトウェア アーキテクチャ」（略称:POSA本）, トッパン, 1999, p.120-139を参考にしました。

32. 記述の例 例: MVCパターンのコンテキストと課題 • コンテキスト: • 人間とコンピュータのインタフェースに柔軟性を持たせた対話型アプリケーション。 • 課題: • ユーザインタフェースは要求仕様の変更の影響を受けやすく、またプラットフォームにより異なることが多いので柔軟性を持たせたい。 • ユーザインタフェースとシステムの機能中核部分の結合度が高いと、誤りを潜在的に持つ可能性が高くなり、変更や保守が困難である。

33. 記述の例 例: MVCパターンの課題のフォース(force) • 以下に述べるフォースがこの課題の解決策に影響を与える。 • 同一情報を別々のウィンドウに異なる形式で表示する必要がある。たとえば、棒グラフや円グラフという形式で情報が表示される。 • データに対して行われた操作が、直ちにアプリケーションの表示と動作に反映されなければならない。 • ユーザインタフェースの変更を容易に行うことができる。また、実行時においても、その変更を行うことができることが望ましい。 • 異なるルック＆フィール標準のサポートやそれらの間の移植が、アプリケーションの中核となるコードに影響してはならない。

34. 記述の例 例: MVCパターンの解決策 • 対話型アプリケーションを、処理、出力、入力の３つの領域を担当するコンポーネントに分ける。それぞれ、Model、View、Controllerが担当する。 • Model は、アプリケーションの核となるデータと機能をカプセル化する。特定の出力表現や入力動作からは独立したものである。 • View は、情報をユーザに表示することについて責任を持つ。そのために、Modelからデータを取得する。1つのModelについて複数のViewを定義できる。 • 個々のViewごとにControllerが存在する。Controllerはマウスやキーボードなどからの入力を受取る役割を担う。Controllerは受取ったイベントをModelやViewに対するサービス要求に翻訳する。ユーザは、Controllerを通じてのみ、システムと対話できる。

35. 記述の例 例: MVCパターンの解決策（続き） • View と Controller を Model から分離することによって、同一モデルに対して複数の View を持たせることが可能になる。 • 1つのViewと関連づけられているControllerを通じてユーザが Model を変更すると、このデータに依存するすべての View はその変更を反映させた表示を行わなくてはならない。 • したがって、Modelのデータが変更された場合にはいつでも、モデルがそれをすべてのViewに通知するようにする。 • その通知を受けて、ViewがModelから新しいデータを取り出し、表示している情報を更新する。これを更新伝播機構と呼ぶ。 • この解決策の静的側面をCRCカードとクラス図で、動的側面をシナリオと相互作用図（シーケンス図）で説明する。

36. 記述の例 例: MVCパターンのCRCカード 協調者 協調者 クラス クラス ・ View ・ Model Model Controller ・ View ・ Controller 責務 責務 ・ ユーザ入力をイベントとして受取る。 ・ イベントをModelへのリクエスト、あるいは、Viewへのリクエストに変換する。 ・ （必要に応じて）更新用手続を実装する。 ・ アプリケーションの機能中核を提供する。 ・ ViewとController を登録する。 ・ データ変更をコンポーネントに通知する。 協調者 CRCカードは、 アプリケーションにおける重要なクラスを特定し、それぞれの責務と協調者を明らかにするのに役立つ。 「クラス」とあるが、概念レベルのクラスやコンポーネントの洗い出しに使用しても有効である。 紙面の都合で協調者を右上に書いているが、責務ごとに協調者を書くのが本来の姿である。 クラス ・ Controller ・ Model View 責務 ・ Controller を生成して初期化する。 ・ 情報をユーザに表示する。 ・ 更新手続を実装する。 ・ Model のデータを取得する。 CRCカード: Class-Responsibility-Collaborator card: クラス-責務-協調者カード [BeCu89]

37. 記述の例 例: MVCパターンのクラス図 クラスを表す。 上段はクラス名、 中段は属性名、 下段は操作。 Observer Observerは ViewやControllerを 「汎化」したもの であることを表す update updateを呼び出す Model coreData setOfObservers View myModel myController attach(Observer) detach(Observer) notify getDataと 関連付ける 生成する Controller Initialize(Model) makeController activate display update 表示を 操作する getData service myModel myView Initialize(Model, View) handleEvent update サービス呼び出し と関連付ける

38. 記述の例 例: MVCの動的な振る舞いを描いたシナリオ１ • このシナリオは、モデルを変化させるユーザ入力が更新伝播メカニズムをどのように駆動するかを示すものである。 • コントローラは、イベントハンドリング手続でユーザ入力を受取り、そのイベントを解釈し、モデルのサービス手続を活性化する。 • モデルは、リクエストされたサービスを実行する。この結果、モデルの内部データが変化する。 • モデルは、更新伝播メカニズムに登録されたすべてのビューとコントローラによって行われる。 • （次スライドに続く）

39. 記述の例 例: MVCの動的な振る舞いを描いたシナリオ１（続き） • 各ビューがモデルに更新データをリクエストし、自らを画面に再表示する。 • 更新伝播メカニズムに登録されている各コントローラが、ユーザ機能を活性可能／不可能(enable or disable)にするために、モデルからデータを取得する。たとえば、モデルのデータが更新されると、続いて、データ保存のメニュー項目が活性化される。 • コントローラが制御を再獲得し、イベントハンドリング手続に戻る。

40. 記述の例 例: MVCパターンの相互作用図（シーケンス図） Controller Model View handleEvent service notify update display getData update getData この図は、MVCの動的な振る舞いのシナリオ１について、簡単のために1つの View-Controller対だけを示したものである。

41. 成果物の記述 その他の記述 • その他、ソフトウェアの成果物（中間成果物を含む）には、さまざまな記述（ドキュメント）が作成される。 • 必要性の高いもの: そこにしか書かれていないことが書かれているもの。特に、全体構成がわかるものや、「なぜこうなってるの？」という疑問に答えてくれるもの。 • 必要性が低いもの: プログラム（ソースコード）を見ればわかることしか書いていないもの。 • 記述の多くは、日本語などの自然言語による文章や図表であるが、数学的裏づけのある形式的記述も有効である。

42. 成果物の記述 形式的仕様記述言語 • 数学的に裏づけられた形式的(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) • 特に高い信頼性を求められるシステムでは、形式的仕様記述により、仕様を数学的に検証することが有効な場合がある。

43. 成果物の記述 ソフトウェアの記述における問題点 • 書き出すとすぐに複雑になり、書ききれなくなる。 • 何のために何を書いた記述なのかわかりにくい。 • 重要なこととそうでないこととの区別がつきにくい。 • 担当部分だけ詳細に定義してあっても、全体の中での位置づけや関係がわからないと、わかった気がしない。 • ソフトウェアは変更を受けやすいので、その仕様や設計の記述も修正されるべきであるが、修正されないまま放置されることが少なくない。 • システム外部（ドメイン）についての記述は、システムを理解する上で重要であるにもかかわらず、意外と少ない。

44. ここでもう一度 良い設計のための根底技術 • 抽象化 • カプセル化 • 情報隠蔽 • モジュール化 • 関心の分離 • 結合度と凝集度 • 充足性、完全性、プリミティブ性 • ポリシーと実装の分離 • 参照の一点性 • 分割統治 参考: POSA本(邦訳：ソフトウェアアーキテクチャ）の6.3節

45. ソフトウェアの記述における留意点 • 一度にすべてのことを書こうとしないこと • 関心の分離、分割統治 • モジュール化、カプセル化、情報隠蔽 • 特に例外の記述には要注意。 • 必要のない詳細は書かないこと • 最終的なソースコードやデータには詳細は必要。 • 変更しやすいものは分離しておくこと • ポリシーと実装の分離 • 他にもいろいろとあると思いますが...

46. まとめ • 成果物にはどのようなものがあるか • 記述の表記法にはどのようなものがあるか • どういう場合にどういう表記法を使うか • 記述にはどのような問題点があるか • 記述する際にはどのような点に留意すればよいか