ソフトウェア方式設計・詳細設計についてまとめました。
【ソフトウェア構造とコンポーネントの設計】
| – |
ソフトウェア構造とコンポーネントの設計 |
| ソフトウェア方式設計 |
「ソフトウェア要件定義書」を基にして、必要な内部機能を開発部門が設計することです。 |
| オブジェクト指向プログラミング言語 |
データと手続きをひとまとまりにしたオブジェクトをベースにしてプログラムを構成していくプログラム言語(C++、C#、Javaなど)。 |
| 関数型プログラミング言語 |
関数の定義によってプログラムを構成するプログラム言語(Lispなど)。命令を逐一実行するのではなく式を入れ子構造にし、式を計算結果を置き換えていくことで実行していく。 |
| 手続型プログラミング言語 |
手続きを処理する順番に並べて命令文を記述するプログラム言語(C、COBOL、PASCALなど)。 |
| 論理型プログラミング |
論理式の証明過程をプログラムで自動化するためのプログラム言語(Prolog)。プログラムに”事実”と”規則”を記述することで、言語の処理系がもつ導出原理によって”質問”に適合する事実を導き出すことが可能。 |
| イディオム |
プログラミングで用いられる慣用語や典型的なプログラミングテクニックのことです。 |
| デザインパターン |
オブジェクト指向プログラミングにおいて頻繁に使われる設計法を、部品の構成・使い方など共に共通パターンとして定義したもの。GoF(Gang of four)による23種のパターンがある。 |
| フレームワーク |
プログラミングやシステム設計での再利用を目的として汎用的な枠組み。 |
| モデリング |
対象となる業務を分析しシステム化の前提となるデータモデルを定義する作業。 |
【インタフェース設計】
【ソフトウェアユニットのテストの設計】
| – |
ソフトウェアユニットのテストの設計 |
| UT（Unit Test） |
「単体テスト」のことです。1つの「関数」「モジュール」が正常に動作するかテストします。 |
【ソフトウェア結合テストの設計】
【ソフトウェア品質】JIS X 0129-1、JIS X 25010:2013
JIS X 0129
ISO/IEC9126(JIS X 0129)において、ソフトウェアの品質を評価する基準である機能性，信頼性，使用性，効率性，保守性，移植性の6つの特性と、それぞれの品質特性をさらに細分化した21の副特性が定められています。
| 6つの特性 |
概要 |
| 機能性(Functionality) |
目的から求められる必要な機能の実装の度合い |
| 信頼性(Reliability) |
機能が正常動作し続ける度合い，障害の起こりにくさの度合い |
| 使用性（Usability） |
分かりやすさ、使いやすさの度合い |
| 効率性(Efficiency) |
目的達成のために使用する資源の度合い |
| 保守性(Maintainability) |
保守（改訂）作業に必要な労力の度合い |
| 移植性（Portability） |
移植のしやすさ、別の環境へ移した際そのまま動作する度合い |
| 満足性(satisfaction) |
製品又はシステムが明示された利用状況において使用されるとき，利用者ニーズが満足される度合い。満足性にはさらに「実用性」「信用性」「快感性」「快適性」の4つの副特性がある |
| 満足性の副特性 |
概要 |
| 実用性(usefulness) |
利用者が把握した目標の達成状況によって得られる利用者の満足の度合い。 |
| 信用性 (trust) |
利用者や利害関係者がシステムを使用した際に、システムが意図したとおりに動作するという確信の度合い。 |
| 快感性 (pleasure) |
利用者が個人的なニーズを満たすことから感じる喜びの度合い。 |
| 快適性 (comfort) |
利用者がシステムの快適さに満足する度合い。 |
JIS X 25010:2013
JIS X 25010:2013は、ソフトウェア品質特性を定義した国際規格ISO/IEC 25010のJIS版(JIS X 0129-1の後継)です。
JIS X 0129-1で6つだった品質特性が以下の8つに増えています。
| 8つの特性 |
概要 |
| 機能適合性 |
明示された状況下で使用するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を，製品又はシステムが提供する度合い。 |
| 性能効率性 |
明記された状態（条件）で使用する資源の量に関係する性能の度合い。 |
| 互換性 |
同じハードウェア環境又はソフトウェア環境を共有する間、製品、システム又は構成要素が他の製品，システム又は構成要素の情報を交換することができる度合い、及び／又はその要求された機能を実行することができる度合い。 |
| 使用性 |
明示された利用状況において、有効性、効率性及び満足性をもって明示された目標を達成するために、明示された利用者が製品又はシステムを利用することができる度合い。 |
| 信頼性 |
明示された時間帯で，明示された条件下に、システム、製品又は構成要素が明示された機能を実行する度合い。 |
| セキュリティ |
人間又は他の製品若しくはシステムが、認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように，製品又はシステムが情報及びデータを保護する度合い。 |
| 保守性 |
意図した保守者によって、製品又はシステムが修正することができる有効性及び効率性の度合い。 |
| 移植性 |
一つのハードウェア、ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に、システム、製品又は構成要素を移すことができる有効性及び効率性の度合い。 |
【レビュー】
| – |
レビュー |
| インスペクション(Inspection) |
和訳すると「診断」という意味です。ソフトウェア開発においては、事前に役割を決められた参加者が責任のある第三者(モデレータ)の下で成果物を確認することを意味します。 |
| ウォークスルー |
作成者を含めた複数人の関係者が参加して会議形式で行い、レビュー対象となる成果物を作成者が説明して参加者が質問やコメントをします。 |
| ラウンドロビン |
参加者が順番に司会者とレビュアになります。そして、司会者の進行によってレビュア全員が順番にコメントをして、全員が発言したら司会者を交代して次のテーマに移ります。 |
| パスアラウンド |
レビュー対象となる成果物を複数のレビュアに配布又は回覧し、レビュアがコメントします。 |
【ウォークスルー】
【ソフトウェア設計の評価】
【プロセス中心設計】
【データ中心設計】
【構造化設計】
【オブジェクト指向設計】構成要素
| 用語 |
概要 |
| カプセル化(情報隠ぺい) |
オブジェクトの内部を隠ぺい(ブラックボックス化)することで、ユーザーが内部構造を知らずにオブジェクトを扱うことができます。 |
| ポリモーフィズム(多相性・多態性) |
オブジェクトへの操作呼び出しが、呼び出し側でなく受け手側の特性で決まる特性です。同じメッセージを送っても受け手によって行われる操作が異なります。 |
| サブクラス(子クラス) |
基本クラス(スーパークラス)から派生して新しく定義されたクラス。基本クラスの属性やメソッドを継承し、それを基にサブクラス独自の特性を追加できます。（例：基本クラスが”車”ならサブクラスは”トラック”などに相当） |
| プロパゲーション |
あるオブジェクトに対して操作を適用したとき、関連するオブジェクトに対してもその操作が自動的に適用される仕組み(伝搬)。 |
| デリゲーション |
あるオブジェクトに対する操作をその内部で他のオブジェクトに依頼する仕組み(委譲)。 |
| インヘリタンス(継承) |
子クラス(例:バス、タクシー)が親クラス(例:自動車)の親クラスの定義(属性やメソッドなど)を引き継ぐこと。下上位の特性を引き継ぐことで差分プログラミングが可能となります。 |
| コンポジション |
複数のオブジェクトを部分として用いて、新たな一つのオブジェクトを生成する仕組み(合成)。 |
| 汎化 |
子クラス(例:バス、タクシー)の共通部分を取り出し、親クラス(例:自動車)として定義すること。 |
| 特化 |
親クラス(自動車)から引き継いだ特性に、独自の特性を派生した子クラス(バス、タクシー)を作成すること |
【モジュールの設計】
モジュール強度
モジュール強度とは、モジュール内部の関連性の強さを表し、以下の7種類があります。
モジュール強度が高いほど、他の影響を受けにくくなるので再利用や拡張がしやすくなります。
| 種別 |
概要 |
| 暗合的強度(低) |
関係のない機能をまとめたモジュールです。 |
| 論理的強度 |
関連する複数の機能をまとめたモジュールです。 |
| 時間的強度 |
特定の時期に実行する機能をまとめたモジューです。 |
| 手順的強度 |
関連ある逐次的な機能をまとめたモジュールです。 |
| 連絡的強度 |
関連ある逐次的な機能で要素が連絡し合うものをまとめたモジュールです。 |
| 情報的強度 |
同じデータ構造や資源を扱う機能を一つにまとめたモジュールです。 |
| 機能的強度(高) |
一つの機能を実現するためだけのモジュールです。単一の機能を実行するモジュールが最も独立性が高い、つまりモジュール機能的強度が高くなります。 |
モジュール結合度
モジュール結合度とは、モジュール同士の関連性の強さを表します。
モジュール結合度が弱いほど関連するモジュールに変更があった場合の影響を受けにくくなり、モジュールの独立性が高まり保守性が向上します。
モジュール結合度は、データの受け渡し方法などにより以下の6段階のレベルに分類されます。
（上にいくほど結合度が弱く独立性が高いため保守しやすい）
| 種別 |
概要 |
| ①データ結合 |
処理に必要なデータのみを単一のパラメータとして受け渡している。 |
| ②スタンプ結合 |
処理に必要なデータのみをレコードや構造体などのデータ構造として受け渡し。 |
| ③制御結合 |
もう１つのモジュールの制御要素を受け渡し。実行する機能や論理を決定するために引数を受け渡すとき，このモジュール間の関係は、片方のモジュールの制御要素を受け渡しているので、制御結合です。 |
| ④外部結合 |
外部宣言された共通データを参照。大域的な単一のデータ項目を参照するモジュール間の関係は，外部宣言された同じデータ項目を参照しているので、外部結合です。 |
| ⑤共通結合 |
共通域に宣言された共通データを参照。大域的なデータを参照するモジュール間の関係は、外部宣言された同じデータを構造参照しているので、共通結合です。 |
| ⑥内部結合 |
お互いのモジュール内部を直接参照・分析。あるモジュールがCALL命令を使用せずにJUMP命令でほかのモジュールを呼び出すときは、お互いのモジュール内部を直接参照し合っているので、内部結合です。 |
【部品化と再利用】
【アーキテクチャパターン】
【デザインパターン】
【その他】システム設計の考え方
| 種別 |
概要 |
| フールプルーフ |
不特定多数の人が操作するシステムに、入力データのチェックやエラーメッセージの表示などの機能を加えることで、人為的ミスによるシステムの誤動作を防ぐように設計する考え方です。 |
| フェールセーフ |
システムの不具合や故障が発生したときでも、障害の影響範囲を最小限にとどめ、常に安全を最優先にして制御を行う考え方でです。 |
| フェールソフト |
障害が発生した時に、多少のシステム性能の低下を許容し、システム全体の運転継続に必要な機能を維持させようとする考え方です。 |
| フォールトトレランス |
システムの一部に障害が発生しても全体としては停止することなく稼働を続け、その間に復旧を図るようにシステムを設計する考え方です。これを実現するには各機器を二重構成にし障害発生時には機器の切替えを即座に行える設計であることが条件となります。 |
【情報処理入門】テクノロジ系、マネジメント系、ストラテジ系、資格試験
情報処理の基礎知識（テクノロジ系、マネジメント系、ストラテジ系）や資格試験についてまとめました。なお、情報処理技術者試験の試験要綱で整理されている分野別(テクノロジ系、マネージメント系、ストラテジ系)に各項目を整理しています。そのため、I...
コメント