情報処理技術者試験対策のページ＞午前対策 目次
テクノロジ系 開発技術 システム開発技術
設計手法
- プロセス中心設計
- データ中心設計
- データを共有資源と見なし、その一貫性や完全性維持を重視して資源側からソフトウェアを規定する、という考え方に基づく
- 対象とする業務をデータの関連に基づいてモデル化し、分析する
- 対象業務領域のモデル化に当って、情報資源のデータ構造に着目する
- データ資源の重複だけでなく、それに起因するプロセスの重複も排除することを目的としている
- 「プログラムの処理ロジックが頻繁に変更されたとしてもデータは比較的安定的である」という考え方を基本とする
- データ中心設計法におけるカプセル化の特徴
データとその操作の実装がカプセル内に閉じ込められるので、カプセルの利用者と提供者を明確に切り分けることができる
- トランザクション正規化
トランザクションを標準データと標準プロセスごとに分割すること
- データ中心アプローチによる開発手順
- データモデリング(要求分析/データ分析)
業務で利用するデータの構造を分析し、抽出したエンティティとエンティティ間の関係をE-R図などで整理する
データ中心アプローチによる開発では、データ分析を先に行い、モデル化することを優先する
- データ標準化/データベース設計
モデル化したデータの意味や特性を明確にし、標準データとして定義する
- 標準プロセスの設計
標準データに対応する処理プログラムとして標準プロセスを設計する
標準プロセスは、標準データの発生/変更/消滅という基本的な処理機能と、データ整合性維持のための機能を含む
- カプセル化/トランザクション正規化
標準データと標準プロセスをひとまとめにするカプセル化を行う
- 応用プログラム設計
標準プロセスを利用する応用プロフラムを設計する
- 構造化設計
業務を構成する処理の内容を、概要から詳細へと階層的に示す
- オブジェクト指向設計
-
オブジェクトに外部からメッセージを送れば機能するので、利用に際してその内部構造や動作原理の詳細を知る必要はない
- データとデータに関する処理をひとつのまとまりとして管理し、そのまとまりを組み合わせて開発する
-
クラス階層を導く手法として、汎化／特化、集約化／分解、グループ化などの抽象化操作がある
- データは外部から隠蔽され、メソッドと呼ばれる手続によって間接的に操作される。プログラムは、データとメソッドをひとまとまりにしたものの集まりである
- オブジェクト指向の特徴
- データを外部から隠蔽し、メソッドと呼ばれる手続によって間接的に操作することができる
- 継承という概念によって、モデルの拡張や変更の際に変更箇所を局所化できる
- プログラムは、データとメソッドをひとまとまりにしたものの集まりである
- 汎化
下位クラスに共通する内容を抽出して上位クラスに定義すること
- 継承 （ インヘリタンス ）
-
オブジェクト指向の概念で、上位のクラス(基底クラス)のデータやメソッドを下位のクラスで再利用できる性質
-
あるクラスの下にサブクラスを定義するとき、上のクラスで定義されたデータ構造と手続きをサブクラスで引き継いで使うことができる
-
後で下位のクラスを追加するとき、その上位クラスを利用して書かれた業務プログラムにメソッドを追加するだけでよく、再利用できる部分が多い
- 基底クラスで定義したデータ構造と手続をサブクラスで引き継いで使用する
- オブジェクト指向の概念で、上位のクラスのデータやメソッドを下位のクラスで利用できる性質
- インスタンス
- クラスとインスタンスとの関係
クラスの定義に基づいてインスタンスが生成される
- ホワイトボックス型（開かれた）再利用
基底クラスに対してサブクラスを作ることによって、基底クラスのデータや機能を再利用すること
基底クラスで定義したデータや機能に対する差異をサブクラスに記述すればよく、開発効率が良い
- ブラックボックス型再利用
汎用的に作成されたクラス（コンポーネント）をそのまま利用する形態
- 抽象データ型
データとそれに対する操作を一体化して定義したものであり、データへのアクセスは定義された操作を用いて行う
- 情報隠蔽
オブジェクトは、メッセージによってだけアクセス可能となる
- カプセル化
データとそれを操作する手続きを一つにして、オブジェクトの内部に隠蔽すること
オブジェクトの内部データ構造やメソッドの実装を変更しても、その影響を他のオブジェクトに及ぼしにくい
オブジェクト指向において、属性と振る舞いをひとつにまとめた構造にすること
データとそれを操作する手続きを一つのオブジェクトにして、その実装をオブジェクトの内部に隠蔽すること
- 多様性（ポリモルフィズム）
同一メッセージを各オブジェクトに送っても、オブジェクトによって動作が異なるので、メッセージを受け取るオブジェクトの種類が増えても、メッセージを送るオブジェクトには影響がない
- クラス
サブクラスではスーパクラスの操作を再定義することができる
- 抽象クラスでできないこと
インスタンスを生成すること
- 抽象化
- CORBA
-
オブジェクト指向技術の標準化団体OMGが制定した、オブジェクト指向による分散処理環境を実現するためのオブジェクト管理プラットフォームの参照モデル
-
分散システム環境で異なったオブジェクト間でもメッセージの交換を可能にした共通仕様
- 遠隔地にあるデータベースにアクセスするプロトコルを規定している国際規格
- エージェント指向
-
利用者の意図を反映しながら進める機能
- 例
フライト（飛行便）予約システムにおいて、利用者が航空会社や時刻などを細かく指定しなくても、“水曜日午前中にニューヨークに着きたい”と指示すれば、条件に合うフライトを検索し、第１希望が満席なら次善のフライトを検索するといった一連の処理を、利用者の意図を反映しながら進める
テスト
- 開発フェーズに対応したテスト
- システム開発のVモデル
- システム開発で行われる各テストについて、そのテスト要求事項が定義されるアクティビティとテストの組合せ
- システム方式設計：システム結合テスト
- ソフトウェア方式設計：ソフトウェア結合テスト
- ソフトウェア詳細設計：ソフトウェアユニットテスト
- 単体テスト
- モジュールもしくはプログラム単位で行うテスト
- テストツールを利用して、プログラムがコーディング基準を満足しているかを検証する
- モジュール設計書を見ながら、原則としてすべてのロジックパスを一度は通るようなテストケースによって検証を行う
- プログラムに記述されたすべての命令を少なくとも1回実行し、仕様通りに動くことを検証する
- 利用する手法
- 結合テスト
- 単体テストを完了したモジュールもしくはプログラムを組み合わせ、モジュール間やサブシステム間のインタフェースを検証するために行うテスト
- 二つの単体テスト済のプログラムを組み合わせ、プログラム間のインタフェースが仕様通りに作成され、正常に連動することをテストする
- 個々のプログラム間のインタフェースの整合性を検証する
- トップダウンテスト
- 上位のモジュールから下位のモジュールへと順次結合してテストする
- 開発の初期段階ではテスト作業を行うことが困難
- インタフェース間の問題が発生しても影響が小さい
- ドライバは不要で、スタブが必要である
- スタブ
- 階層構造のモジュール群からなるソフトウェアの結合テストを、上位のモジュールから行う場合に使用する、下位モジュールの代替となるテスト用のモジュール
- 結合テストにおいて、上位モジュールをテストするために、上位モジュールから制御を受け取り、想定される戻り値を返す、テスト用に作成した下位モジュール
- ボトムアップテスト
- 下位のプログラムから上位のプログラムに向かって結合テストを行う
- 開発の初期の段階でも並行してテスト作業を進めることができる
- テストの最終段階でモジュール間のインタフェースに問題が発見された場合、テスト済みのモジュールの修正が必要となるため影響が大きい
- ドライバが必要で、スタブは不要である
- ドライバ
- ボトムアップテストにおいて、被テストモジュールの上位モジュールの機能を代行するもの
- テスト対象モジュールに引数を渡して呼び出す
- プログラムを構成するモジュールの単体テストを行うとき、そのモジュールを呼び出す仮の上位モジュールを用意して、動作を確認する
-
結合テストにおいて、下位モジュールをテストするために、下位モジュールに制御を渡し、引数を与える、テスト用に作成した上位モジュール
- サンドイッチテスト
チップダウンテストとボトムアップテストを同時並行して進める方法
- ビッグバンテスト
すべてのプログラムを一度に結合する方法
- 一斉テスト
単体テストを省略して全プログラムを一度に結合する方法
- 利用する手法
- テスト担当者がソフトウェア結合テストを実施したところ、実行結果がテスト使用書の記述と異なっていたときのテスト担当者の対応
問題を記録し、開発者に修正を依頼する
- システムテスト ( 総合テスト )
-
システムの目的や性能などの要求仕様を満足しているかを総合的に検証するためにシステム全体の動作確認をするテスト
-
目的
開発者が、システム全体の機能と性能を検証する
- オンライントランザクション処理のレスポンスタイムが要求仕様を満足するか検証する
-
システムの要求仕様に照らしたマニュアル検証やテストケース設計などを行う場合、ユーザ部門の要員に参画してもらう
-
本番環境に近い単位で要件を満たすことを確認するテスト
- テストケース作成に対応させる仕様書
外部設計工程で作成した外部設計書
- システムテストを実施するとき、用意しておくべきテストデータ
実際に業務で使うデータや、業務上例外として処理されるデータ
- 検証する内容
端末から行う照会処理の応答時間を検証する
- 利用する手法
- 運用テスト
- 完成プログラムを本稼動環境下で試行するテスト
- 原則としてユーザ部門の責任で利用者が主体となり、実際の業務プロセスに沿って機能用件や操作性を検証する
- ユーザ部門が優先して確認すべき事項：決められた手順どおりに、システムが稼動すること
- システム運用部門が行う
- 開発されたシステムが実運用に耐えうるものであることを確認する
- バックアップの所要時間、休日かどう、障害発生時の対応策など、運用面での問題点を洗い出す
- 利用者に提供するという視点で、システムが要求を満足していることを確認する
- ユーザテスト
-
要件を満たすことを納品時にユーザが確認するテスト
-
利用者がシステムをスムーズに操作できるかどうかをテストする
- 移行テスト
既存のシステムを新規システムに置き換えるときに、以前と同様に正しくデータの処理が出来るかどうかをテストする
- 互換性テスト
ソフトウェアが、複数の異なるシステム構成の上で正常に動作するかどうかをテストする
- テスト手法
- ホワイトボックステスト
-
プログラムのアルゴリズムやモジュールなどの内部構造に基づいてテストデータを作成する
-
プログラムのソースコードを見て、それに基づいてテストデータを作成するテスト方法
-
内部構造に基づいてテストデータを作成する
- プログラムをテストすることを前提にしているため単体テストにしか使われない
- プログラムの分岐条件を検証する
- 技法
- 命令網羅
プログラム中のすべての命令を少なくとも1回実行するテスト
- 判定条件網羅
条件分岐の新利を少なくとも1回は実行するテスト
- 複数条件網羅
それぞれの判定における可能な組み合わせの全てを実行するテスト
- テストカバーレッジ ( 網羅率 )
- C0カバーレッジ ( 命令網羅の網羅率 )
テストで通過した命令数÷プログラムに存在する命令数×100
- C1カバーレッジ ( 判定条件網羅の網羅率
)
テストで通過した分岐数÷プログラムに存在する分岐数×100
- ブラックボックステスト
-
モジュールの内部構造ではなく、入力データと出力結果の関係だけに注目してテストデータを作成し、仕様書どおりに機能するかどうかをテストする
- 入力と出力だけに着目して様々な入力に対して仕様書どおりの出力が得られるかどうかを確認していく、システムの内部構造とは無関係に外部から見た機能について検証するテスト方法
- プログラムのソースコードを見ずに、仕様書に基づいてテストデータを作成するテスト方法
- モジュールの内部構造を考慮することなく、仕様書通りに機能するかどうかをテストする手法
- 設計書に基づいて行うテストであるので、単体テスト・結合テスト・システムテストに適用できる
- 稼動中のシステムから実データを無作為に抽出し、テストデータを作成する
-
機能仕様から同値クラスや限界値を識別し、テストデータを作成する
-
プログラムがどのような機能を果たすのかを仕様書で調べて、テストケースを設計する
-
被テストプログラムに冗長なコードが合っても検出できない
-
プログラムが設計者の意図した機能を実現しているかどうかのテストを、主にプログラム開発者以外の第三者が実施する
- 技法
- 同値分割
- プログラムの入力仕様条件をもとに、有効値と無効値の2つを設定し、テストケースを設計する方法
-
仕様からデータを、意味のあるグループ（同値クラス）に分類し，各グループから代表値を選びテストを行う
- 同値クラス
- 限界値分析 ( 境界値分析法 )
- プログラムの入力と出力の仕様条件をもとに、その境界値を中心にテストケースを設計する方法
-
同値クラスの間の境界の値（境界値）をテストデータとして選択する
-
プログラムの誤りの一つに、繰返し処理の判定条件としてA≧aとすべきところをA>aとコーディングすることがある。このような誤りを見つけ出すために有効なテスト設計技法
-
例)
-
出力帳票の1ページごとにヘッダと30件分のレコードを出力するプログラムをテストしたい。このプログラムを限界値分析によってテストするための最小のテストデータを用意するとき、レコード件数の組み合わせ
0，1，30，31
- 原因・結果グラフ
-
テスト条件項目(原因)と所定動作(結果)とこれら要因項目間の論理関係を記述したグラフ
- 退行テスト （ レグレッションテスト /
リグレッションテスト / デグレードテスト /
デグレテスト ）
- 既存のソフトウェアに誤りの修正や仕様変更が生じ、プログラムを改修した場合、変更しなかった部分が従来と同じ動作をすることを検証するテスト
-
保守のためにシステムの一部や、ソフトウェアに修正を加えときに、変更した箇所がほかの正常な部分（影響を受けないはずの箇所）に影響していないかどうかを確認する目的で行う
-
ソフトウェアテストの種類のうち、ソフトウェア保守のために行った変更によって、影響を受けないはずの箇所に影響を及ぼしていないかどうかを確認する目的で行うもの
-
例）既存のシステムのある機能を修正したところ、今まで正常に動作していた機能を実行するとエラーが発生するようになった→退行テストが不十分であったと考えられる
- 負荷テスト
想定している単位時間あたりの最大件数のデータを入力したときに、意図したとおりに処理できるかどうかをテストする
- 静的テスト
プログラムを実行することなくテストする手法であり、コード検査、静的解析などがある
- 静的テストツールの機能に分類されるもの
ソースコードを解析して、プログラムの誤りを検出する
- アサーションチェック
プログラム実行中の特定の時点で成立する変数間の関係や条件を記述した論理式を埋め込んで、そのプログラムの正当性を検証する手法
- バグ埋め込み法
-
テスト対象のプログラムにバグを埋め込んでおき、埋め込みバグの検出状況から、プログラム全体の検出状況を推定する
- 摘出した総バグ数：摘出した埋め込みバグ数＝総バグ数：埋め込みバグ数
- 潜在バグ数＝総バグ数−埋め込みバグ数−（摘出した総バグ数−摘出した埋め込みバグ数）
- バグ埋め込み法において、埋め込まれたバグ数をS、埋め込まれたバグのうち発見されたバグ数をｍ、埋め込まれたバグを含まないテスト開始前の潜在バグ数をT、発見された層バグ数をｎとしたとき、S、T、ｍ、ｎ、の関係を表す式
m/S = (n-m)/T
- テストケース設計法
- プログラムテスト仕様書の作成手順
- テスト環境、テスト方法などのプログラムテストに関する概要を記述する
- テスト項目をすべて列挙する
- テスト効率を上げるために、適切なテストケースを設定する
- テストケースごとのテストデータの作成と予想結果の作成を行う
- テストを実行するときの個々の詳細な手順を設定する
- テストケースの作成者
- システムテスト：外部設計の担当者
- 単体テスト：プログラム開発の担当者
- 結合テスト：内部設計の担当者
- 運用テスト：利用部門の担当者