第9章 ソフトウェア技術
９.１ プログラミング言語
９．２ オペレーティングシステム
９．３ データベース技術
９．４ マルチメディア技術
９．５ ソフトウェア開発
９．５ ソフトウェア開発
９．５．１
９．５．２
９．５．３
９．５．４
９．５．５
ソフトウェア開発工程
開発計画と開発管理
システム分析
外部設計技法
内部設計技法
９．５.１ ソフトウェア開発工程
プロセスモデルとは
ソフトウェア開発工程は，ソフトウェア開発プロセスと呼ばれ，
生産性向上を目標として，
様々なモデル的な手順が提唱されてきた。
このモデル的な手順をプロセスモデルという。
ソフトウェア開発プロセスモデルの例
① 最も伝統的なウォータフォール(Waterfall:「滝」という意味）モデル
② プロトタイプ（Prototype:「原型」という意味）モデル
③ スパイラル（Spiral:「渦巻き」という意味）モデル
④ 成長モデル
⑤ 契約モデル
⑥ 逐次開発法
（Incremental Model 「増分」，「追加」等の意味，連続的統合）
⑦ RAD(Rapid Application Development)モデル
⑧ クリーンルーム（Clean Room)モデル（逐次開発法の改良）
（注）ウォータフォールモデル，プロトタイプモデル，
スパイラルモデルは最低限抑えておくこと。
要求定義
手戻り
完了
外部設計
手戻り
（１）ウォータフォールモデル
完了
内部設計
手戻り
完了
プログラム
設計
完了
手戻り
プログラ
ミング
手戻り
完了
テスト
手戻り
完了
運用・保守
ウォータフォールモデルの特徴
① 最も伝統的なソフトウェア開発モデル。
② 上流工程から下流工程に向けて滝（ウォータフォール）を
流れ落ちる水のようにトップダウンで開発を進める。
③ 工程毎に確認と検証を行い，誤りがあった場合は，
前工程に戻る。
④ プロジェクト管理はしやすいが，前工程の誤りによっては，
何段階も前に戻ってしまい，修正が困難である等の
難点がある。
ウォーターフォールの長所と特徴
要求定義
手戻り
完了
外部設計
手戻り
長所
完了
内部設計
手戻り
プロセス分割が明確である。
完了
プログラム
設計
完了
手戻り
プログラ
ミング
手戻り
短所
プロセス毎に成果物をレビュー
することで，それぞれの作業の
品質を保証できる。
完了
テスト
手戻り
完了
運用・保守
手戻りが困難。
完成するまで成果物のイメージが不明。
大規模になればなるほど管理ポイントが拡散。
（２）成長モデル
ウォータフォールモデルにおける開発工程を
要求が出るたびに繰り返すモデル。
要求等
モデル化
要求定義
テスト及び評価
プログラミング
成長モデルの特徴
① １回のサイクルで開発される量が少ないので，
簡略化した開発工程となり，
手戻り作業も少なくなる。
② 完成するまでの工数見積りが困難になる。
（３）プロトタイピングモデル
① 成長モデルと同様のサイクル。
② ただし，最初に作成するのは
試作品（プロトタイプ）である。
機能面からの分類
プロトタイピングの種類
①モックアップ型プロトタイピング
入出力画面・帳票・操作等，外観的な機能をモデル化。
②機能型プロトタイピング
本番プログラムの機能の中で限定された範囲の機能をモデル化。
利用目的による分類
①棄却型（使い捨て型）プロトタイピング
仕様を確定するためのもので，確定後は破棄。
②組込み型プロトタイピング
プロトタイプは本番プログラムに組み込まれたり，
プロトタイプ自身が改良されて本番プログラムとなる。
プロトタイピング
長所
システム完成前にユーザの意見・要望を具体的に確
認。実現性・性能等を確認できる。
短所
開発またはユーザ試用負担が増えることがありうる。
モデル化される機能が限定される。
モデルでユーザ要求確認・実現性の確認
プロトタイピング
本番開発
ウォータフォールモデルとの併用
要求収集・分析
プロトタイプ作成
設計
プログラミング
要求の追加・
修正・削除
プロトタイプの
実行／評価
プロトタイプモデル
テスト
運用
ウォータフォールモデル
（４）スパイラルモデル
ウォータフォールモデルでの開発工程を
計画，最適化，分析・開発，検証
の４タイプのフェーズに分類し，
これをスパイラル的に繰り返す。
すなわち
段階的な機能追加の繰り返しで
開発を進める。
ウォータフォールモデルを
基礎としたスパイラルモデル
最適化フェーズ
テスト
条件等
検討
制約
条件等
検討
目標
設置
戦略
立案
テスト
次期
計画
開発
立案
計画
立案
計画フェーズ
分析・開発フェーズ
プ
開発
計画立案
ロ
グ
システム
分析
現状
分析
ラ
シス
テム
要 求 設計
定義
ユーザ
レビュー
設計
精査
定
設計
レビュー
フィールド
テスト
ミ
ン
グ
単体
テスト
結合
テスト
検証フェーズ
スパイラルモデルのもうひとつのタイプ
（類似システムの経験がない場合）
機能組み込み型のプロトタイピングを
スパイラル的に繰り返す。
実行・検証
要求の追加
プロトタイプ作成
実行・検証
要求の追加
プロトタイプ作成
（５）契約モデル
①開発工程を分割し，工程毎に発注者と受注者が契約して
開発を進める方法。各工程別に受注者を分離する場合もある。
②工程の管理が容易であること，
受注者としてはリスクが少なくなる等の利点がある反面，
発注者にとっての全体コストが見とおしにくいという難点がある。
③特殊な解析手法やプログラミング技術等を必要とする
システム開発において，これらの技術を有する企業が
小規模な場合に有効である。
（６）逐次開発法（連続的統合）
長所 大きな機能の漏れや誤りを防ぐことができる。
重
要
機
能
根幹部分
一次開発
付 重
随 要
機 機
能 能
１
根幹部分
付 重 付
随 要 随
機 機 機
能 能 能
１
２
根幹部分
二次開発
三次開発
逐次開発法（連続的統合）
① 一次開発では，根幹部分と重要な機能だけを開発し，
二次開発以降で付属的な機能を追加し，
徐々に機能を追加していく方法。
大きな機能の漏れや誤りを防ぐことができる。
② 一次開発における機能分割，特に基本的な機能
（メモリ管理，データ管理，実行モデル等）の設計が
特にキーとなる。従って，一次開発においては，
機能分割の妥当性の検証，基本的な機能部分の設計に
十分検討を尽くす必要がある。
（７）クリーンルームモデル
開発システムの要求を分析し，
機能的な仕様と利用シナリオを記述し，
順次機能を追加するための計画を策定し，
順次機能を追加する。
要求分析
中核部分開発
機能仕様
の記述
増分１開発
計画見直し
増分２開発
利用シナリオ
の記述
インクリメンタル
開発計画
クリーンルームモデルの特徴
① 「テストまたは出荷段階ではじめてユーザの確認がとれる」，
「テスト段階で生じた欠陥の修正費用が増大する」という
ウォータフォールモデルの欠点が解消される。
② 各増分ごとに検証・テストが行われるので欠陥が少なくなる。
③ 品質検査や機能検証を増分ソフトウェア部分に対してのみ行う。
④ 増分ソフトウェア部分に形式的な検証手法を厳密に適用する。
⑤ 仕様をブラックボックスとみる視点から，
徐々に入力と出力への具体的な変換操作の視点へと
見方を移して詳細化する。
９．５.２ 開発計画と開発管理
（１）開発管理
システム開発管理では，次のような管理を行う。
① 進捗管理
② 品質管理
③ 組織要員管理
④ 協力会社管理
⑤ 費用管理
⑥ 機密・契約管理
⑦ 変更管理
プロジェクトとは
①特定の目標や目的を持つ。
②活動期間が限定される。
③スケジュールと予算を持っている。
④原則として，スキルや知識を持った人材で
編成される。
⑤最終的には，何らかの成果物が作成される。
マネージメントサイクル
プロジェクトを構成する経営資源（人・物・金）を
最も効率良く活用し，適切に運営すること。
Management Cycle
PLAN
DO
ACTION
CHECK
マネージメントの視点
ＱＣＤ ： 品質(Quality), 費用(Cost), 納期(Delivery)
Quality
品質管理，変更管理
組織・要員管理，外注管理，
Cost
費用管理，機密・契約管理
進捗管理，組織・要員管理，
Delivery
外注管理
（２） プロジェクト計画技法
PPP（Phased Project Planning)
段階的プロジェクト計画
WBS（Work Breakdown Structure)
作業分割図
TRM(Task Responsibility Matrix)
役割分担図
RMC(Responsibility Matrix Chart)と呼ばれることもある。
（ａ）ＰＰＰ（Phased Project Planning)
段階的プロジェクト計画
プロジェクトのフェーズ （ＮＡＳＡ）
①予備分析 (Preliminary Analysis)
②仕様決定 (Definition)
③設計 (Design)
④開発・運用 (Development and Operation)
各フェーズを更に詳細なタスクレベルに分割
全てのタスクで，計画－実施－評価のサイクル
ＰＰＰの留意点
① プロジェクト計画時点で，各タスクでの
「計画－実施－評価」の計画・評価に
関わる時間を組み込んでおく必要がある。
② 各タスクで評価を行う必要があるが，
作業者は評価を避けがちなので，
効果などを強調して啓蒙活動を行う
必要がある。
（ｂ）ＷＢＳ（Work Breakdown Structure)
作業分割図
プロジェクトで必要な作業をトップダウンの視点で
洗い出し，それを階層表現で図示したもの
ＷＢＳの例
ＡＢＣプロジェクト
1
2
概念設計
計画策定
方針決定 目標設定 効果指針 現状分析
問題点解析
1.1
2.2
1.2
1.3
2.1
解決策立案
2.3
ＷＢＳの特徴
① 作業構成，作業範囲，必要な開発資源が明確になる。
② メンバーの責任と権限を明確にできる。
③ 分割された作業の漏れや重複が発見でき，
所要日数やコスト見積りが容易。
④ 作業分割を適正に行い，実績データを蓄積する
ことによって見積り標準データを作成できる。
⑤ ドキュメント作成，プロジェクト内教育訓練など
補足的な作業の漏れが発生する可能性がある。
⑥作業難易度に対する余裕率の設定が困難。
ＷＢＳのタイプ
① 初期（Initial） WBS : 個別開発計画策定時
（プロジェクト全体の機能を明確にする）
② 予備（Preliminary） WBS : 個別計画承認後
（プロジェクト全機能を明確にする）
③ プロジェクト（Project）WBS : 作業単位（フェーズ）に分割
（プロジェクト全体の作業を明確にする）
④ フェーズ（Phase）WBS : フェーズを更に詳細なタスクに分割
（フェーズ内の作業を明確にする）
⑤ タスク（Task）WBS :
日程計画等を策定できる程度にタスク内の作業を分割。
（ｃ）ＴＲＭ（Task Responsibility Matrix)
役割分担図
WBS.No.
作業名
白井
今泉
2.3.1
画面設計
査閲
実施
2.3.2
ＤＢ設計
2.4.1
画面定義
2.4.2
ＤＢ定義
2.4.3
アルゴリズム検討
実施
査閲
3.1.1
プログラミング
査閲
実施
実施
3.1.2
テスト
査閲
実施
実施
査閲
査閲
矢嶌
実施
実施
査閲
実施
ＴＲＭの特徴
①各作業単位に担当する要員，
レビューする要員が明確になる。
②各作業の品質の均一化，
プロジェクト全体の品質向上が
期待できる。
ＴＲＭでの注意点
① 既存の職位や職級にとらわれず，
要員の最適活用という観点で配置すること。
② 要員全体の作業時間バランスに注意すること
（能力があり，仕事が速い要員に仕事が集中しがちである）
③ プロジェクトマネージャは，実作業を担当せず，
全体の管理・監督に専念することが望ましい。
（３）日程計画表の作成技法
（ａ）マイルストーンチャート
予想 最 早 最 遅 予定 約束 実際
マイル
タスク
5 10 15 20 25 30 ストーン
作業１
担当
作業開始 白井
△
△
△
レビュー
今泉
作業完了 白井
作業２
作業開始 榎本
△
△ △
レビュー
小林
作業完了 榎本
PERT図で算出した最も早く作業が
完了した場合に到達する日付
予定期間内に作業を完了するために
完了到達が許される最も遅い日付
日
到達日 到達日
日
日
日
（ｂ）ガントチャート
作業
担当者 １月 ２月 ３月
作業１
木村
作業２
上田
作業３
大木
作業４
島田
行事
全体スケジュール等に適しているが，
作業間の順序関係を示しにくい。
４月
５月
備考
（ｃ）PERT
（Program Evaluation and Review Technique)
元々は，ミサイルの管理手法として米国海軍で開発された手法
（5,5,0)
2
5
7
4
①ネットワーク図作成
②所要日数算出
4
2
4
１
(12,15,3)
③最早結合点日程算出
④最遅結合点日程算出
3
8
3
5
(17,17,0)
(9,9,0)
（最早結合点日程，最遅結合点日程，余裕日数）
赤矢印がクリティカルパスである。
⑤余裕日数算出
①PERT／TIME ： 日程情報
②PERT／MAN－POWER：ヒト
・モノなどの資源の数・量
③PERT／COST ： ヒト・モノ・カ
ネなど経営資源中心
（４）見積り技法
①標準値法（過去のプロジェクト結果を利用）
②モデル化技法
・PUTNUM法
・DOTY法
・COCOMO法(Constructive Cost Model)
③ファンクションポイント法
④類似法
⑤外挿法
⑥ボトムアップ見積り
COCOMO(Constructive Cost Model)
ＣＯＣＯＭＯ法
プログラマの作業量を統計的なモデルを用いて，
ステップ数から工数を算定する方法。
Boehm が提案した方法である。
プログラマを以下の３階層に分けて算定する。
① 初級(Basic)
② 中級(Intermediate)
③ 上級(Advanced)
Function Point モデル
外部仕様中の入力項目数，出力項目数，照会等での項目数，
論理ファイルの数や項目数，インターフェースの複雑さから
算定されるポイントを用いて算出する。
元々は事務処理用だが，
科学技術計算用には解析や問題の難しさ等の
パラメータを用いたFeature Pointsを導入して強化されている。
（５）品質管理
（ａ）目的
情報システムが
ユーザの要求どおりの機能を提供し，
安定した稼動を継続する。
（ｂ）品質管理と品質保証
品質管理 ： ソフトウェアの製造部門が
主体となって行う品質向上活動
品質保証 ： 利用者の観点から品質を
確認する作業であり，
検査部門が行う品質向上活動。
（ｃ）品質管理の定義(JIS)
買い手の要求にあった品質またはサービスを
経済的に作り出すための体系。
品質管理を略してQCということがある。
統計的品質管理（SQC）
統計的な手法を用いた品質管理
全社的品質管理（CWQC）または総合的品質管理（TQC）
企業活動の全活動の全段階にわたって，
経営者，管理者，監督者，作業者など
企業全体の組織員の参加と協力で品質管理を行う。
品質管理＝顧客満足度
（製造業等での定義）
• 後向き品質：当たり前品質
製品自体が本来的な機能を発揮するため
に必要となる品質
• 前向き品質：付加価値，魅力
製品自体の本来的な機能以外の他製品と
の差別化要因となる品質
（ｄ）品質モデル
① Wulf のモデル
② Walters と Macall のモデル
③ Boehm のモデル
④ ISO9000-3 (品質保証国際規格）
B.W.Boehmのソフトウェア品質の特性要因
装置独立性
自己包含性
携帯性（移植性）
正確性
完全性
信頼性
堅固性／インテグリティ
無矛盾性
効率性
ソフトウェアの
品質
使用性
計測性
装置効率
操作性
アクセス可能性
伝達性
テスト容易性
自己記述性
構造性
保守性
理解性
簡潔性
明瞭性
更新性
拡張性
（６）レビューの種類
ソフトウェアの品質を高めるには，ある工程から次の工程に移る際，
設計内容等について確認作業を行う必要がある。
この確認作業がレビューである。
① デザインレビュー
各工程別にドキュメント等の評価を行うための検討会。
工程の切れ目で行われる。
② ウォークスルー
開発関係者が集まり，成果物の誤り等を見つける作業を行う会議。
③ インスペクション
責任者が，ドキュメント，ソースプログラムリスト，テスト仕様書を
チェックしながら評価・記録し，プロジェクト構成員に対して
問題点を周知徹底させる会議。
インスペクションの責任者をモデレータと呼ぶ。
第9章 ソフトウェア技術
９．５ ソフトウェア開発
９．５．１
９．５．２
９．５．３
９．５．４
９．５．５
ソフトウェア開発工程
開発計画と開発管理
システム分析
外部設計技法
内部設計技法
９．５.３ システム分析
（１）システム分析の内容
システム分析では，ユーザのシステムに対する期待や
要求を明確にし，コスト／効果，制約条件等を考慮して，
システムへの要求事項を機能仕様としてとりまとめる．
以下の作業を行う必要がある。
① 要求定義
② 要求分析
要求定義
まずシステム開発要求を持つ顧客が，
どのようなシステムを欲しがっているかを
洗い出して整理する。
要求定義では，ヒアリング等により
顧客との打合せを行い，
顧客が要求するシステムイメージを把握し，
文章等にまとめ，各種のモデル化技法を用いた
図表等を提示する。
顧客の要求を洗い出すだけでなく，顧客にも，
システムイメージを，ある程度，
理解してもらうことが目的となる。
要求分析
要求定義された内容に矛盾がないか，
機能を実現するために不足あるいは
不要なデータがないか
等について分析する。
（２）要求定義技法
（ａ）ＫＪ法（川喜多二郎氏の提案）
事実，推定，意見などを統合的に図示することで，対立意見，矛盾，具体化
に伴う問題点の関係を明確にする。
【手順】
•データの収集とカードへの記述
•カードのグルーピング
•グループ別表札の作成
•カード配置の決定
•グループ間の関係付けによる図の作成
•シナリオ作成
（ｂ）機能分析
機能を中心に，次のような方法で段階的に詳細化する。
①機能階層モデル
要求定義時のヒアリング等から得られた文章から「ＡとＢか
らＣを行い，Ｄを得る」等の表現を見つけ出し，入力データをＡ，
Ｂ，出力データをＤ，機能をＣとする。
さらにＣを行うには何（詳細機能）を行うべきかを考え，詳細
機能を実行するためのデータを推測して，詳細化を繰り返す。
②データフローモデル
データの流れを図示しながら機能階層を詳細化する。図示され
たものをデータフローダイアグラム（ＤＦＤ：Data Flow Diagram)
と呼ぶ。
データフロー図の例
営業
部
請求書
顧客
請求書
注文書
注文書
請求
書等
発行
納品書
在庫
管理
発送
伝票
注文
書
受付
営業
マスタ
顧客マスタ
情報
商品
マスタ
在庫マスタ
情報
配送
会社
（ｃ）事例応答分析
事象や時間の流れによるシステムの応答・動作・状態について分析する。
①コントロールフローモデル
大まかな処理の流れや，システム実現上，特に問題となる部分
について制御の流れを表現して，ユーザの確認を得る。
特に，ユーザから見た事象（たとえば，月末，発注発生など）により，
どのような流れになるかを明確にする。
②状態遷移モデル
事象により状態がどのように変化するかを図示する。
状態を円，事象（イベント）を矢印として表現する。
状態遷移表が使用されることもある。
③ペトリネット，テンポラリロジック
ユーザの直感的な理解を得られないことが多いので
要求定義時の使用頻度は低い。
（ｄ）データ分析
機能は要求によって変化しやすいが，システムに必要なデータや結果は，
それほど変化しないので，まずデータの分析を中心にして分析する。
①Ｅ－Ｒモデル
P.Chenが提案した構造化分析のモデル。実体（Entity）と実体間の
関係（Relationship），それらの属性（Attribute）をE-R図で表現する。
②抽象データモデル
カプセル化されたデータと操作群を抽象データ型と呼ぶ。データの実
体が隠される（情報隠しと呼ぶ）ので，操作だけで機能説明を行うこ
とになり理解しやすくなる。
③オブジェクト指向モデル
抽象データモデルを発展させ，対象物を表現するデータの共通の属性
をクラスという概念によってモデル化する。
（注）データと操作群をひとまとめにすることをカプセル化と呼ぶ
E-R図の例
部署コード
部署名
職員コード
氏名
入社年
部署
顧客
１
１
所属
受託
M
職員
M
担
当
１
M
業務
顧客コード
顧客名
業務コード
業務名
契約金額
特にプロセス中心とデータ中心について
①機能中心のアプローチではデータの全体像を把握することが困難。
②データ中心のアプローチでは処理手順を把握することが困難
両者の不足を補うために結果をつき合わせて見直す。
エンティティプロセス関連マトリックス
(CRUDマトリックス分析表とも呼ばれる）
エンティティプロセス関連マトリックスの例
エンティティタイプ
プロセス
注文書受付
営
業
マ
ス
タ
顧
客
マ
ス
タ
U
R
請求書発行
取消処理
在庫管理
R
U
請
求
書
在
庫
マ
ス
タ
C
D
U
C：生成
R：参照
U：更新
D：削除
９．５．４ 外部設計
（１） 設計手法の種類
•構造化分析(SA:Structured Analysis)
•オブジェクト指向分析（Object Oriented Analysis)
以下は外部設計時にも用いられるが，
内部設計が主であるため内部設計の項で説明する。
•構造化設計(SD:Structured Design)
SAと合わせてSA/SD法とも呼ばれる。
•ジャクソン法
•ワーニエ法
（２）構造化分析(SA)
• デマルコが提案した要求分析法。
• 要求定義にも用いられる。
• データの流れをＤＦＤで記述し，システムが
用いるデータ群をデータディクショナリに記
述し，最下層のプロセスの処理概要をミニ
仕様に記述する。
• 記述された全体を構造化仕様書と呼ぶ。
（３）オブジェクト指向の考え方
• データは「もの」を表現する。
• 「もの」はメッセージに応じて振る舞
い，自分の状態を変化させる。
• 「もの」は分類することができる（似た
ようなものは，似た属性を持つ）
データは「もの」を表現する
ペンオブジェクトを表現するデータの集合
ペンの番号
Up/Down
(X,Y)
X
：１００
Y
： 40
Up/Down状態 ：Up
番号
： １
データの種類を規定する用語
スロット
プロパティ
アトリビュート
VB風のプロパティの変更と参照
変更
ペン.X ＝ １２０
ペン.Y = 40
参照
X=ペン．X
ピリオド（．）を，日本語で「の」と読もう。
処理は対象物によって異なる(1)
顔
雑巾
食器
洗う１
洗う２
洗う３
対象物
顔を洗う
雑巾を洗う
食器を洗う
洗う処理
処理は対象物によって異なる(2)
(オブジェクト指向の表現方法は，日本語？）
おなじ処理名でも，対象物がきまらないかぎり，
処理内容は選択できない。
↓
対象物を先に指定して，処理を後で指定する方が有利。
wash her face, wash the duster, wash the tableware
↓
「顔」を「洗う」，「雑巾」を「洗う」，「食器」を「洗う」
ものはメッセージに応じて振る舞い，
自分の状態を変化させる。
オブジェクト
メッセージ
状態A
振舞い
（処理）
状態B
言い換えると，
オブジェクトは，自分がメッセージに対して
どう動くかを知っている。
さらに別の言葉を使えば
■ 動作を行うためのメソッドを持っている。
■ オブジェクト専用の関数／手続き
を持っている。
VB風のメソッドとメッセージ
ペン.移動 X:=100,Y:＝ １２０
ペン.アップ
ペン.ダウン
ペン.交換 番号:=2
メソッドの場合のピリオド（．）を，
日本語で「を」と読もう。
ものは分類することができる
Is_a関係
「彼」は「人間」である。
「人間」は「霊長類」である。
He is a person.
A person is a primate
クラスとインスタンス
霊長類
まさに存在するもの ： インスタンス
分類上の名称
： クラス
人間
高橋修一
君田恵美
クラス
インスタンス
プロパティ値，メソッドの遺伝（継承）
（インヘリタンス）
霊長類 愛称：＜文字列＞
性： （雄，雌）
尾： （有，無）
is_a
人間
氏名：＜文字列＞
性： （男，女）
尾： 無
is_a
氏名：大橋和夫
性： 男
「尾：無」が遺伝（継承）
is_a
氏名：丸山恭子
性： 女
イベントドリブン
イベント判定のための処理を
記述する必要がない。
初期設定
イベント１
処理１
イベント２
処理２
イベント３
処理３
画面の構成要素種類によっ
て行う処理は類似しているの
で，処理の標準化がやりやす
い。
マンマシン部分の共通化を図
ることができる。
インヘリタンス（継承）
• 下位オブクジェクトではスーパクラスと異なった性質だけを定義すれ
ば良い。これを差分プログラミングと呼ぶ。
スーパクラス
共通するデータやメソッド
サブクラスで定義されて
いるので継承しない
継承（インヘリタンス）
サブクラス
サブクラス
固有のデータやメソッド
継承（インヘリタンス）
他インスタンス
メッセージ
インスタンス
継承（インヘリタンス）
インスタンス
ものは複数の見方で分類することができる
スーパークラスが複数存在することがある。
• マルチインヘリタンス（多重継承）：複数のスーパクラスからの継承が
行われる。
• シングルインヘリタンス（単一継承）：ひとつのスーパクラスから継承
する。
（例）桜井眞人は学生である。桜井眞人は男である。
桜井眞人 is_a 学生。 桜井眞人 is_a 男。
Is_a と Part_of
コンピュータ
コンピュータ
分解
CPU
集約
主メモリ
Part_of 関係
(CPU is part of コンピュータ)
特化
パソコン
汎化
WS
Is_a関係
(パソコン is a コンピュータ)
（４）ＯＭＴ（Object Modeling Technique)法
• Rumbaugh の考案。オブジェクト構造，機能的な側面，動
的な側面の3視点から記述する
ドキュメント
記述内容
オブジェクトモデル図 クラス間の関連（汎化，集約，インスタンス
間の関係）
機能モデル図
データフロー図
動的モデル図
状態遷移図およびイベントトレース図
（５）UML(Unified Modeling Language)
• Booch 法，OMT法，JacobsonのOOSE(Object Oriented
Software Engineering)を統合。
ドキュメント型
ドキュメント種類
ユースケース図
記述内容
ユーザがシステムと対話するときの一連の処理
静的構造図
クラス図
オブジェクト図
クラスとクラス間の関係
特定の時点でのインスタンスの集合
振る舞い図
状態図
アクティビティ図
特定クラスに属すオブジェクトの状態遷移図
内部処理の制御の流れを表すワークフロー
相互作用図
シーケンス図
協調図
オブジェクト間のイベントトレーズ図
オブジェクト間のメッセージのやり取り図
実装図
コンポーネント図
配置図
コンポーネント間の依存図
コンポーネントやオブジェクトの計算資源の配置
（６）HIPO(Hierarchy plus Input Process Output)
機能を階層的に表現する手法である。
全体の機能構成およびサブシステム間の関係を階層的に示す
図式目次とサブシステムに対する入力・処理・出力を示す
IPO図から構成される。
在庫管理
システム
処理
入力
注文情報
注文情報
入力
在庫管理
処理
入力
受注伝票
出力
(a) 図式目次
1.注文情報受取り。
顧客データ 2.顧客チェック。
3.在庫の有無確認。
在庫データ 4.引当て処理。
5.受注数量の記録。
(b) IPO図
出力
受注情報
顧客データ
在庫データ
（７）状態遷移図(State Transition Diagram)
イベント(事象)によるシステム状態の推移関係を矢印で表現した図。
リアルタイムモニタ，通信ソフトウェアなどの分析に使用することが
多い。特に，通信ソフトウェアでは，通信相手との状態の組合せ
(カップリングと呼ぶ)によりデッドロック状態の分析を行ったり，
状態数最小化による無駄なイベントの削減等の分析に
使用することができる。
Join In/Join Empty
メッセージ受信
MT
Leave In/Leave Empty/Leave All
メッセージ受信
IN
LV
Join In/Join Empty
メッセージ受信
Leave タイマーのタイムアウト(leave.indication 発行後, 遷移)
９．５．５ 内部設計技法
（１） 内部設計で行うこと
①コンピュータ側から見たシステムの設計
②プログラム間インターフェースの設計
③詳細設計とも呼ばれる。
機能分割やプログラムの構成を設計する
部分を機能及び構成設計と呼び，
この部分以降を詳細設計として分けることもある。
（２）構造化設計技法
構造化分析の結果の最下位プロセスをプログラムとして
モジュールに分割。
① STS分割
データの流れに着目して，データの源(Source),
変換(Transform),吸収(Sink)に分割
② ＴＲ分割
トランザクション(Transaction)の種類により，
それぞれの処理単位に分割。
③ 共通機能分割
共通的な機能があれば，共通機能として定義
階層構造図とバブルチャートで表現する。
STS分割
データ２
データ１
機能
A
機能
B
源泉部（S）
データ３ データ４
データ５
データ６
機能
機能
機能
D
E
C
変換部（T）
吸収部（S）
ＴＲ分割
業務管理システム
トランザクションデータ
受注データ
発注データ
仕入データ
売上データ
受注取消データ
受注
処理
発注
処理
仕入
処理
売上
処理
受注
取消
階層構造図とバブルチャート
メインモジュール
１
モジュール
A
（源泉）
２
モジュール
B
（変換）
階層構造図
モジュール
入力
アーギュメント
出力
アーギュメント
Ａ
なし
データ３
Ｂ
データ３
データ５
Ｃ
データ５
なし
３
モジュール
C
（吸収）
バブルチャート
（３）その他の設計技法（その１）
① ワーニエ法 ： 入力データ構造を中心に構造化を行う
② ジャクソン法 ： 入出力のデータ構造の関係からプログラムの制御構造を導く。
A
B
A *
C
（連続）
B
（繰返し）
A
B
〇
C
（選択）
その他の設計技法（その２）
③ 段階的詳細化法：E. W. Dijkstraが提唱した手法であり，抽象機械とい
う概念で抽象化階層で表現する。
④ データ抽象化法：B. H. LiskovとD. L. Parnasが提唱した手法であり，個
別の抽象データ型の概念の集合による抽象化階層で表現する。Parnas
の情報隠蔽(Information Hiding)の考え方は，オブジェクト指向に引き
継がれている。
⑤ データ中心設計：システムで扱うデータに着目し，データの発生によ
り処理が起動されるものとして設計を行う。主としてヒューマンマシ
ンインターフェースを重視するシステム開発に適用される。
⑥ オブジェクト指向設計：オブジェクト指向分析と同様，オブジェクト
指向の考え方で設計する。データとそれを操作する手続きを一体化し
たオブジェクトの集合でシステムを表現する。同一のオブジェクトに
は同一の操作が行われることが多いので，モジュールの再利用性が高
まる。
（４）制御の流れの記述
（ａ）フローチャート
プログラムの実行手順を記述するための最も伝統的な図式化法。
用いられる記号はJISで定められている。
処理A
条件
処理B
条件
No
Yes
処理A
Yes
処理A
処理A
処理C
（連続）
（分岐）
（繰返し）
No
（ｂ）デシジョンテーブル
条件と実行の関係を表形式で表す手法。複雑な判定が必要な場合に
条件間の関係を簡潔に表すことができる。
繰返しの表現はできないが，
① 必要な判定がすべて揃っているか(完全性)，
② 冗長な判定はないか(冗長性)
を形式的にチェックできるので複雑な判定を整理するために使われる。
ルール
スタブ
条 条件 2
件 条件 3
行 条件４
実 実行１
行 実行２
行 実行３
実行４
ルール
１
Y
Y
Y
２
Y
Y
N
３
Y
４
Y
N
Y
５
N
Y
X
X
X
X
６
N
N
X
X
X
X
X
X
（ｃ）その他の処理記述法
構造化プログラミングの普及とともに，
構造化プログラミングに適した図式化法として提唱された手法に，
NSチャート，PAD，YACII等がある。
以下に，NSチャートの例，PADの例を示す。
なお，これらは同一の処理を表現している。
この他，擬似的な言語を設定して処理を記述するPDLという技法もある
実行１
条件１
T
実行１
T
条件２
実行2
。
F
実行3
左のNSチャートは，
While 条件1
{ 実行1;
If 条件2 Then
実行2
Else
実行3
}
を示す。
条件１
実行２
条件２
実行３
９．５ ソフトウェア開発
完
© Copyright 2024 ExpyDoc
