-
アーキテクチャ作業システム全体の基本構造や主要なコンポーネント、それらの相互関係を決定する作業
-
アーキテクチャコンピュータシステム、ネットワークなどそれぞれのものにたいする設計思想、基本設計、基本構造のこと
-
効率性品質特性における「応答性を向上させる」などの目標
-
安全性品質特性における「セキュリティ管理を容易にする」などの目標
-
信頼性品質特性における「故障耐性を向上させる」などの目標
-
保守性品質特性における「拡張性、変更容易性、テスト容易性を向上させる」などの目標
-
論理ビューシステムがどのような機能を持ち、それらの機能が論理的にどのような構造で実現されるか
-
実行ビューシステムがプロセスやタスクなどの実行単位からどのように構成されているか
-
開発ビューシステムがどのような単位でファイルにまとめられ、どのようなディレクトリ構造で管理されているか
-
配置ビュープロセスなどの実行時の単位をネットワーク上のどのマシンのどのプロセッサに配置するか
-
階層モデル機能分割のモデル、非常によく出てくるモデルのパターンで色々なところで利用されている それぞれの層で呼び出すことが出来るのは直下層の機能のみ
-
クライアントサーバモデル機能分割のモデル、データと処理機能をクライアントとサーバにわけて運用する分散システムモデル
-
データ中心モデル(リポジトリモデル)機能分割のモデル、複数のクライアントでデータを共有しながら集中管理するモデル
-
データフローモデル制御関係のモデル、入力データを処理して、出力を生成する変換機能により構成されるモデル
-
集中コントロールモデル制御関係のモデル、関数の呼び出し関係やサブプロセスをメインプロセスがコントロールするようなケースで用いられるモデル
-
コールリターンモデル上位のサブルーチンが下位のサブルーチンを呼び出す集中コントロールモデル 逐次型のシステムに適用可能
-
マネージャモデル1つの構成要素が他の要素の開始、停止、協調を制御する集中コントロールモデル 並行システムに適用可能
-
イベント駆動コントロールモデル外部で発生したイベントで処理が駆動する オブしこにおけるイベントの処理機構や、OpenGLのシステムなど多くのシステムで用いられる
-
MVCアーキテクチャ制御関係のモデル、システムをモデル、表示、制御という3つの側面に分け、それを合成して全体とするアーキテクチャ
-
デザインパターン過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前を付け再利用しやすいように特定の規約にしたがってカタログ化したもの
-
フレームワーク対象分野の典型的な機能を提供するクラスやインタフェースの集合（アプリケーションをゼロから作らずにすむ）
-
GoFデザイン1994年に出版されたDesign Patterns:~~で紹介された23のデザインパターン
-
Singleton※GoFにおいて、あるクラスについてインスタンスが単一であることを保証する
-
Prototype※GoFにおいて、同様のインスタンスを生成するために原型のインスタンスを複製する
-
Factory Method※GoFにおいて、実際に生成されるインスタンスに依存しない、インスタンスの生成方法を提供する
-
Abstract Factory※GoFにおいて、関連する一連のインスタンスを状況に応じて、適切に生成する方法を提供する
-
Builder※GoFにおいて、復号化されたインスタンスの生成過程を隠蔽する
-
Adapter※GoFにおいて、元々関連性のない2つのクラスを接続するクラスを作る
-
Facade※GoFにおいて、複数のサブシステムの窓口となる共通のインタフェースを提供する
-
Bridge※GoFにおいて、クラスなどの実装と、呼び出し側の間の橋渡しをするクラスを用意し、実装を隠蔽する
-
Composite※GoFにおいて、再帰的な構造を表現する
-
Decorator※GoFにおいて、あるインスタンスに対し、動的に付加機能を追加する。Filterとも呼ばれる
-
Flyweight※GoFにおいて、多数のインスタンスを共有し、インスタンスの構築のための負荷を減らす
-
Proxy※GoFにおいて、共通のインタフェースを持つインスタンスを内包し、利用者からのアクセスを代理する
-
Iterator※GoFにおいて、複数の要素を内包するオブジェクトのすべての要素に対して、順番にアクセスする方法を提供する
-
State※GoFにおいて、オブジェクトの状態を変化させることで、処理内容を変えられるようにする
-
Strategy※GoFにおいて、アルゴリズムの実装を、使う場合に応じて切り替えられるようにする
-
Template Method※GoFにおいて、あるアルゴリズムの途中経過で必要な処理を抽象メソッドに委ね、その実装を変えることで処理内容を変えられるようにする
-
Chain of Responsibility※GoFにおいて、イベントの送受信を行う複数のオブジェクトを鎖状につなぎ、それらの間をイベントが渡されていくようにする
-
Command※GoFにおいて、複数の異なる操作について、それぞれに対応するオブジェクトを用意し、オブジェクトを切り替えることで、操作の切り替えを実現する
-
Interpreter※GoFにおいて、構文解析のために、文法規則を反映するクラス構造を作る
-
Mediator※GoFにおいて、オブジェクト間の相互作用を仲介するオブジェクトを定義し、オブジェクト間の結合度を低くする
-
Memonto※GoFにおいて、データ構造に対する一連の操作のそれぞれを記録しておき、以前の状態の復帰または操作の再現が行えるようにする
-
Observer※GoFにおいて、インスタンスの変化を他のインスタンスから監視できるようにする。Listenerとも呼ばれる
-
Visitor※GoFにおいて、データ構造を保持するクラスと、それに対して処理を行うクラスを分離する
-
Template MethodGoFにおいて、処理の枠組みはスーパークラスで呼び出し、実際の処理は子クラスで実装する抽象クラスを作る目的そのもの
-
AdapterGoFにおいて、既存のクラスに対して修正を加えることなく、インタフェースを変更することができる
-
StrategyGoFにおいて、アルゴリズムの実装を、使う場合に応じて切り替えられるようにする
-
FacadeGoFにおいて、複数クラス利用手順書
-
ObserverGoFにおいて、プログラム内のオブジェクトに関するイベント（事象）を他のオブジェクトへ通知する処理で使われる
-
フレームワークのメリット生産性の向上、均質な開発、テスト工程の短縮、保守性の向上
-
フレームワークのデメリット利用コストが高い、学習期間が必要、フレームワークのバグ、選定問題
-
ユーザインタフェースの設計設計指針に基づいてユーザインタフェースを定める作業
-
UIシステムの客観的な評価(メトリクス)学習時間、実行速度、エラーの割合、長期記憶、満足度
-
グラフィカルユーザインタフェース(GUI)パーソナルコンピュータなどで入出力インタフェースとして広く用いられている画面設計
-
ダイアログボックス操作の確認や動作の指定に用いられるGUI部品
-
コマンドボタン登録、削除などの実行すべき機能を表すラベルの付いたボタン。
-
ラジオボタン複数の選択項目の中から一つだけを選ぶためのボタン。どれか一つを選ぶと他のボタンが解除される。
-
チェックボックス複数の選択項目の中から適当な項目を選ぶための仕組み。複数の項目を選ぶことができる。
-
リストボックス選択する項目の一覧を表示して、その中から一つを選ぶ仕組み。
-
テキストボックスキーボードから入力するための仕組み。１行用と複数行用がある。
-
スピンボックス数値の入力欄で上下のボタンをクリックして数値を増減させる仕組み。
-
出力画面の設計ユーザの関心、情報の価値、表示手法の特徴
-
表現形式(テキスト表現とビジュアル表現)テキストを用いて情報を伝えるのか（ユーザの解釈の自由度は小）、図などを含む絵によって情報を伝えるのか（ユーザの解釈の自由度は大）を選択する必要がある
-
表現形式(アナログ表現とデジタル表現)直線、曲線、波など連続的な形で表現したもの（アナログ表現）と正確な値を表現したもの（デジタル表現）を使い分ける必要がある
-
ダークパターン消費者が気付かない間に不利な判断・意思決定をしてしまうよう誘導する仕組みのウェブデザインなどを指す（線引きは困難）
-
モジュール設計ソフトウェアをモジュールに分割して構造化する作業がモジュール設計
-
モジュール建物、家具、電気器具、コンピュータハードウェアなど様々なものに対して、その構成単位のことをいう
-
サブシステムモジュール同様構成要素を表す、他のサブシステムにより、提供されるサービスに依存しないモジュールの集合体
-
Parnasによるモジュールの性質１つのモジュールを作成するときに、他のモジュールに関する知識をあまり必要としない１つのモジュールを更新するときに、プログラムの他の部分を更新する必要がない
-
モジュール化の効果分業がしやすいのでプロジェクト管理が効率化される１つのモジュールに大幅な変更を施しても他に影響を与えず、製品に柔軟性が生まれるシステムをモジュールごとに分析すればよく、理解が容易になる
-
モジュール強度1つのモジュール内にある要素間の関連の強さを表す基準
-
モジュール結合度複数のモジュール間の関連の強さを表す基準
-
モジュール強度機能的強度←情報的強度←連絡的（順次的）強度←手順的強度←時間的強度←論理的強度←暗号的強度
-
モジュール結合度データ結合←スタンプ結合←制御結合←外部結合←共通結合←内容結合
-
内容結合最も結合度の高い結合様式、インタフェースを介さず別のモジュールを管理するデータや構造を利用して、データを参照する結合、モジュールとしての体をなしていない
-
共通結合共通データ領域に定義したデータを介して情報交換するモジュール間の結合
-
外部結合外部宣言したデータを共有するモジュール間の結合
-
制御結合あるモジュールが別のモジュールを呼び出すとき、呼び出されるモジュールの制御を支持するデータをパラメータとして引き渡すようなモジュール間の結合
-
スタンプ結合共通データ領域にない構造を持ったデータ（構造体）を引き渡すモジュール間の結合
-
データ結合データの必要な部分だけ引数として渡す方法でのみ情報交換をするモジュール間の結合
-
単一責任の原則クラスを変更する理由（クラスの役割）は一つでなければならない
-
オープン・クローズドの原則拡張に対してオープンで、修正に対してクローズでなければならない
-
リスコフの置換原則サブクラスはそのスーパークラスと置換可能でなければならない
-
依存関係逆転の原則上位のモジュールは下位のモジュールに依存してはいけない。抽象は実装に依存してはいけない
-
インタフェース分離の原則強い関連性を持つインタフェースのみをまとめてグループ化しなければならない
-
単一責任の原則の目的変更の結果としてバグが発生しても、他の無関係な動作に影響を与えないように、動作を分離すること
-
オープン・クローズドの原則の目的クラスの既存の動作を変更することなく、クラスの動作を拡張（追加）すること
-
リスコフの置換原則の目的親クラスとその子クラスがエラーなしで同じ方法で使用できるように、一貫性を保つこと
-
依存性逆転の原則の目的インターフェースを導入することにより、上位レベルのクラスが下位レベルのクラスに依存するのを減らすこと
-
インターフェース分離の原則の目的動作のセットをより小さく分割して、クラスが必要なもののみを実行すること
-
再利用・リリース等価の原則リリースするパッケージ内のクラスはすべて再利用できるものか、すべて再利用できないもののどちらかにしなければならない
-
全再利用の原則パッケージ内の全クラスが再利用されなくてはいけない。つまり、パッケージに含まれるいずれかのクラスを再利用するということは、そのほかのクラスもすべて再利用することを意味する
-
閉鎖性共通の原則１つの変更理由は単一パッケージに閉じ込められなければならない
-
安定依存の原則より安定しているパッケージに依存しなくてはならない。つまり、変更することを意識して作ったパッケージに、変更の難しいパッケージが依存することはあってはならない。
-
安定度・抽象度等価の原則抽象的なパッケージほど安定していなくてはならない。つまり、安定したパッケージに含まれるクラスは修正を加えずに拡張できる柔軟なものでなければならない。
-
STS(Source Transform Sink)分割技法データが変換される箇所（最大抽象点）を見つけて、そこを境としてモジュールに分割する
-
TR (TRansaction)分割技法入力データの種類に従って処理の振り分けを行う箇所（トランザクションセンター）に着目、振り分けを行うモジュールと、分岐先でデータを処理するモジュールを分割
-
開発支援ツールのバージョン管理システム（VCS)コードの変更履歴を管理し、複数人での開発を円滑にするためのツール Git、Subversionなど
-
開発支援ツールのビルドツールソースコードをコンパイルし、実行可能なプログラムに変換するツール Maven、Gradle、Make など
-
開発支援ツールのデバッガプログラムの実行中にエラーを検出し、修正するためのツール
-
開発支援ツールのテストフレームワークコードの品質を保証するための自動テストを実行するツール JUnit、TestNG、pytest など
-
開発支援ツールのパッケージ管理すシステム必要なライブラリや依存関係を管理するツール npm、pip、Maven など
-
開発支援ツールのコンテナ化ツールアプリケーションをコンテナにパッケージ化するツール Dockerなど
-
仮想サーバ物理マシン上に複数の仮想マシンを構築する技術
-
ホストOS型仮想サーバアプリケーションをコンテナにパッケージ化するツール Dockerなど
-
ハイパーバイザ型仮想サーバハイパーバイザと呼ばれる専用ソフトウェアを配置して、仮想サーバを構築する
-
総合開発環境（IDE）様々な開発支援ツール群を連携して実行できる開発環境
-
プログラミングパラダイムプログラムの作り方に関する規範
-
手続き型プログラミングコンピュータの処理手順を命令文で記述する（構造化プログラミングに基づく） FORTRAN、COBOL、Cなど
-
関数型プログラミング入出力関係を表現する関数とその呼び出しで記述する Lisp、Schemeなど
-
論理型プログラミング入出力関係を述語論理で記述する Prologなど
-
オブジェクト指向プログラムデータとその操作をカプセル化したオブジェクトとその間のメッセージ通信で記述する C++、Javaなど
-
アスペクト指向プログラミングオブジェクトをまたがる横断的な関心ごとをアスペクトにまとめて記述し、あとで織り合わせる AspectJ、Hyper/Jなど
-
連接構造化プログラミングにおける基本制御構造 ：命令Aを実行し、次に命令Bを実行する
-
選択構造化プログラミングにおける基本制御構造 ：条件Pの真偽により、命令AまたはBのどちらかを実行する
-
反復構造化プログラミングにおける基本制御構造 ：条件Pが真である間、命令Aを繰り返し実行する
-
構造化定理全ての適正プログラムは連接、選択、反復の３つの基本制御構造の組み合わせで記述可能である
-
適正プログラム制御の流れに対して、入口と出口が必ず１つずつある/入口から出口への制御の流れに、すべての命令が関与する
-
プロセス中心アプローチシステムの処理を中心に考え、データの流れに基づきモジュール構造を設計するSTS分割やTR分割
-
データ中心アプローチデータの基本的な特性を中心に考えモジュール構造を設計する
-
データ中心アプローチが適しているもの明確なデータ構造を扱う入出力を持つ事務処理系システムなど
-
ジャクソン法データの基本的な特性を中心に考えモジュール構造を設計する
-
ジャクソン法におけるデータ構造の構成要素基本、連接、選択、反復
-
ワーニエ法データ構造からプログラムの制御構造を直接導出する
-
ノーコード一定のサービス開発をプログラミングを一切行わずに行うこと
-
ローコード一定のサービス開発をプログラミングをほぼ行わずに行うこと
-
一定のサービス開発をプログラミングをほぼ行わずに行うことIT人材の不足、DXの促進、大企業の参入
-
ソフトウェアテストプログラムにテストデータを与えて実行し、その結果からソフトウェアの開発中に紛れ込んだ誤り（バグ）を検出する作業
-
ソフトウェアテストの重要な性質プログラムにテストデータを与えて実行し、その結果からソフトウェアの開発中に紛れ込んだ誤り（バグ）を検出する作業
-
ソフトウェアテストの重要な性質ソフトウェアテストをいくら繰り返したところで、ソフトウェアの品質を向上させることはできない
-
ソフトウェアテストの重要な性質テストはあくまでもソフトウェアにバグが混入していることや、品質が要求を満たしていないことを見つけるための作業
-
機能テストソフトウェアが仕様通りに動作するかを確認する
-
性能テストシステムの速度や応答時間を評価する
-
セキュリティソフトシステムが不正アクセスやデータ漏洩から保護されているかを確認する
-
互換性テストソフトウェアが異なる環境（OS、ブラウザ、デバイスなど）で正しく動作するかを確認する
-
ユーザビリティテストユーザーがシステムを使いやすいかを評価する
-
回帰テスト既存の機能が新しい変更によって影響を受けていないかを確認する
-
ストレステストシステムが高負荷状態でも安定して動作するかを確認する
-
デバッグテスト報告書に記録された成功（誤りなし）および失敗（誤りあり）したテスト項目からバグの原因を究明し、それらを取り除く作業
-
単体テスト（ユニットテスト）実行工程において作成したプログラムに対して、モジュール内部に存在する論理的な誤りを検出する作業
-
統合テスト（インテグレーションテスト）すべてのモジュールに対して単体テストが完了した後、モジュールを統合してテストを行う
-
トップダウンテスト上位モジュールから下位モジュールに向けて順に接続しながらテストを行う/プログラム全体に関わるモジュールを先にテストできるが、初期段階で並列的なテストが困難である
-
スタブほとんど実装を持たないインタフェースのみから構成されるモジュール
-
ボトムアップテスト下位モジュールから上位モジュールに向けて連結しながらテストを行う
-
ボトムアップテストテスト対象となるモジュールを呼び出すためのドライバを作成しなくてはならない
-
ボトムアップテスト最初の段階から並列にテスト可能であるが、全体に影響を与える上位モジュールのテストが後回しになってしまう
-
サンドイッチテストトップダウンテストとトップダウンテストを用いる。基本的にトップダウン、重要な箇所、スタブの作成が難しいところにボトムアップテスト
-
ビッグバンテスト全てのモジュールを一度に結合して行うテスト、小規模なシステム向け
-
システムテスト完成したソフトウェアシステム全体の振舞いを確認することで、システム内部に存在する誤りを検出する
-
機能テストシステムテストの一部、要求仕様が満たされるかどうか
-
性能テストシステムテストの一部、非機能的要求を評価する
-
受け入れテスト顧客が要求仕様に基づき実施するテスト
-
アルファテスト受け入れテストにおいて、大衆向けソフトウェアなど、利用者が特定できない場合、受入テストは開発者が利用者の立場に立って行う
-
ベータテスト受け入れテストにおいて、将来の利用者の一部に試験的に利用してもらう受け入れテストをベータテストという
-
設置テスト受け入れテストがテスト環境下で行われるのに対して、設置テストは実際の稼働環境にシステムをインストールして行われる
-
テスト技法ソフトウェア内部の誤りを検出すること
-
ホワイトボックステストソフトウェアの内部仕様やプログラムコードに基づき、テストケースを作成して実施するテスト例：論理網羅
-
ホワイトボックステストプログラムに入力を与えて、その実行の様子を観察することにより誤りを検出する
-
ブラックボックステストソフトウェア内部の詳細を見ずに、要求仕様書や外部仕様書に記述されたソフトウェアの振る舞いに基づいて実施するテスト
-
ブラックボックステストプログラムに入力データを与え実行結果だけを観察することにより誤りを検出する
-
論理網羅ブラックボックステスト、プログラムを構成する要素をできるだけ網羅するようにテストケースを作成すること
-
命令網羅プログラムのすべての命令を少なくとも１回は実行するようにテストケースを決定する
-
分岐網羅プログラム中のすべての分岐を少なくとも１回は通過するようにテストケースを決定する
-
条件網羅プログラム中の分岐に関するすべての条件判定を、少なくとも１回は実行するようにテストケースを決定する
-
パス網羅プログラム中のすべての実行パスに関してテストを実行する
-
論理網羅命令網羅⇒分岐網羅⇒条件網羅⇒パス網羅の順に厳格、網羅率を100%とするテストケースを用いることが必要
-
命令網羅プログラム中のすべての実行パスに関してテストを実行する
-
分岐網羅プログラム中のすべての分岐（矢印）を、少なくとも１回は通過するようにテストケースを決定する
-
条件網羅プログラム中のすべての条件判定を、少なくとも１回は実行するようにテストケースを決定する
-
パス網羅すべての実行パスに関してテストを実施する
-
同値分割プログラムの入力値の領域を、入力条件に対して有効な範囲と無効な範囲に分割し、テストケースを決定する
-
境界地分析経験的に多くの誤りが入力データの境界値付近で発生している、境界値や境界値から少し離れた値をテストデータにするとよい
-
原因結果グラフ境界値や境界値から少し離れた値をテストデータにするとよい
-
決定表原因として取りうるすべての値の組み合わせについて、対応する結果を原因結果グラフから求めて作成した表
-
信頼性成長モデルどれだけテストを繰り返してもバグが存在しないことの証明にはならない
-
横軸：テストの実施件数、縦軸：検出したバグ数信頼性成長曲線の各軸
-
ソフトウェア検証ソフトウェアにバグが存在しないことを確認する作業
-
妥当性ソフトウェア検証の観点、ソフトウェアが利用者の要求を満たしているか
-
正当性ソフトウェア検証の観点、与えられた仕様に対して、プログラムが正しく実装されているか
-
モデル検査ソフトウェアの仕様を表現したモデルが要求される性質を満たすかどうかを自動的に検証する
-
レビュー中間成果物（要求仕様、設計仕様、プログラムコード）の内容を精査する
-
インスペクション事前に検査項目を決定しておき、各参加者がそれぞれ担当する検査項目について、正常な動作との照合を行う
-
ウォークスルー机上でソフトウェアの実行シミュレーションを行う
-
静的型検査プログラムの検証技法、型に関する不適切な演算や操作を検査することで誤りを検出する
-
機能表明法部分正当性：プログラムを実行することで得られる結果が正しいことを示す、停止性：プログラムが必ず停止することを示す
-
単体テストフレームワーク単体テストの自動実行を可能にするツール
-
テストファーストテストの段階で初めてテスト用のコードを書くのではなく、コーディングの段階で、ソースコードと同時にテスト用のコードを書いていく考え方
-
ソフトウェア保守（ソフトウェアメンテナンス）現場の計算機にインストールされた後のソフトウェアが正しく動作するように維持管理したり、要求に合わせてソフトウェアを変更する活動
-
ソフトウェア再利用過去に開発されたソフトウェアの一部やそのソフトウェアの開発によって得られた経験を、次のソフトウェア開発で積極的に活用すること
-
修正保守ソフトウェア保守の分類、運用段階で検出された誤りの検出
-
適応保守ソフトウェア保守の分類、動作環境や利用環境の変化に追従するための変更
-
改善保守ソフトウェア保守の分類、ソフトウェアのある側面を拡張したり、向上させたり変更
-
予防保守ソフトウェア保守の分類、障害が起こってから誤りを修正するのではなく、故障を未然に防ぐため調査、修正
-
構成管理ソフトウェア開発の多くの構成要素やプロセスを一貫して管理すること
-
影響分析影響範囲を変更前に解析して、保守に必要な資源や工数を見積もる作業のことを影響分析（波及効果解析）と呼ぶ
-
ワークプロダクト任意の開発段階において変更を把握する必要のある成果物
-
回帰テスト動作していた機能が修正後も正常に動作するかどうかを検査する作業を回帰テスト（regression test）という
-
リエンジニアリング既存のソフトウェアを新たに構成しなおすこと
-
リストラクチャリング同じ抽象度におけるソフトウェア情報の変更を対象にする再構成
-
リエンジニアリング異なる抽象度を横断する
-
リバースエンジニアリングソフトウェアの設計や仕様を実装（ソースコード）から再構成する作業
-
フォーワードエンジニアリング仕様から設計、設計から実装という通常の方法の具象化活動
-
リファクタリング既存のソフトウェアの設計の理解性や変更容易性を向上させることを目的として、内部構造を再構成すること
-
制御フロー解析プログラム中の制御の流れを図示することによってプログラムに現れる分岐や繰り返しが明確になる
-
データフロー解析プログラム中のデータの定義と参照の関係を解析することでデータがプログラムのどの部分に関与するかを明確にする
-
プログラムスライシングプログラム中の変数の影響範囲を抜き出して表示させること
-
ブラックボックス再利用再利用資産を変更なしでそのまま利用する
-
ホワイトボックス再利用再利用対象を要求に合わせて部分的に変更して使用する
-
コンポーネント指向ソフトウェア開発ソフトウェアを機能単位でコンポーネントとして分解し、それらを組み合わせることでソフトウェアを構築する枠組みのこと
-
グルーコードコンポーネント同士を接続するために存在するコード
-
ソフトウェアパターンソフトウェア開発において蓄積された経験や知見を再利用できる形として表現したもの
ログイン
オンライン単語帳
このページを利用するにはログインする必要があります。ログインするとAnkilotをより便利にご利用いただけます。