-
アーキテクチャ作業
システム全体の基本構造や主要なコンポーネント、それらの相互関係を決定する作業
-
アーキテクチャ
コンピュータシステム、ネットワークなどそれぞれのものにたいする設計思想、基本設計、基本構造のこと
-
効率性
品質特性における「応答性を向上させる」などの目標
-
安全性
品質特性における「セキュリティ管理を容易にする」などの目標
-
信頼性
品質特性における「故障耐性を向上させる」などの目標
-
保守性
品質特性における「拡張性、変更容易性、テスト容易性を向上させる」などの目標
-
論理ビュー
システムがどのような機能を持ち、それらの機能が論理的にどのような構造で実現されるか
-
実行ビュー
システムがプロセスやタスクなどの実行単位からどのように構成されているか
-
開発ビュー
システムがどのような単位でファイルにまとめられ、どのようなディレクトリ構造で管理されているか
-
配置ビュー
プロセスなどの実行時の単位をネットワーク上のどのマシンのどのプロセッサに配置するか
-
階層モデル
機能分割のモデル、非常によく出てくるモデルのパターンで色々なところで利用されている それぞれの層で呼び出すことが出来るのは直下層の機能のみ
-
クライアントサーバモデル
機能分割のモデル、データと処理機能をクライアントとサーバにわけて運用する分散システムモデル
-
データ中心モデル(リポジトリモデル)
機能分割のモデル、複数のクライアントでデータを共有しながら集中管理するモデル
-
データフローモデル
制御関係のモデル、入力データを処理して、出力を生成する変換機能により構成されるモデル
-
集中コントロールモデル
制御関係のモデル、関数の呼び出し関係やサブプロセスをメインプロセスがコントロールするようなケースで用いられるモデル
-
コールリターンモデル
上位のサブルーチンが下位のサブルーチンを呼び出す集中コントロールモデル 逐次型のシステムに適用可能
-
マネージャモデル
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 Method
GoFにおいて、処理の枠組みはスーパークラスで呼び出し、実際の処理は子クラスで実装する抽象クラスを作る目的そのもの
-
Adapter
GoFにおいて、既存のクラスに対して修正を加えることなく、インタフェースを変更することができる
-
Strategy
GoFにおいて、アルゴリズムの実装を、使う場合に応じて切り替えられるようにする
-
Facade
GoFにおいて、複数クラス利用手順書
-
Observer
GoFにおいて、プログラム内のオブジェクトに関するイベント（事象）を他のオブジェクトへ通知する処理で使われる
-
フレームワークのメリット
生産性の向上、均質な開発、テスト工程の短縮、保守性の向上
-
フレームワークのデメリット
利用コストが高い、学習期間が必要、フレームワークのバグ、選定問題
-
ユーザインタフェースの設計
設計指針に基づいてユーザインタフェースを定める作業
-
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）という
-
リエンジニアリング
既存のソフトウェアを新たに構成しなおすこと
-
リストラクチャリング
同じ抽象度におけるソフトウェア情報の変更を対象にする再構成
-
リエンジニアリング
異なる抽象度を横断する
-
リバースエンジニアリング
ソフトウェアの設計や仕様を実装（ソースコード）から再構成する作業
-
フォーワードエンジニアリング
仕様から設計、設計から実装という通常の方法の具象化活動
-
リファクタリング
既存のソフトウェアの設計の理解性や変更容易性を向上させることを目的として、内部構造を再構成すること
-
制御フロー解析
プログラム中の制御の流れを図示することによってプログラムに現れる分岐や繰り返しが明確になる
-
データフロー解析
プログラム中のデータの定義と参照の関係を解析することでデータがプログラムのどの部分に関与するかを明確にする
-
プログラムスライシング
プログラム中の変数の影響範囲を抜き出して表示させること
-
ブラックボックス再利用
再利用資産を変更なしでそのまま利用する
-
ホワイトボックス再利用
再利用対象を要求に合わせて部分的に変更して使用する
-
コンポーネント指向ソフトウェア開発
ソフトウェアを機能単位でコンポーネントとして分解し、それらを組み合わせることでソフトウェアを構築する枠組みのこと
-
グルーコード
コンポーネント同士を接続するために存在するコード
-
ソフトウェアパターン
ソフトウェア開発において蓄積された経験や知見を再利用できる形として表現したもの
-
