SoCの原則とSLAP
ソフトウェア設計の原則にSoCの原則とSLAP（単一抽象度レベルの原則）があります。これら原則は、アーキテクチャやコードの責務設計・構造設計の基本となります。以下それぞれ解説します。
SoCの原則
SoCは「Separation of Concerns（関心の分離）」の略称です。SoCの原則は、対象を関心ごと（何をしたいのか、何をすべきか）を基準に分離すべき、という原則になります。これは次の目的で実施します。
- 規模が大きく複雑で扱いにくいものを、扱えるサイズになるまで関心ごとを単位に細分化します。
- 責務やコンポーネントを、関心ごとを基準に設計することで、責務やコンポーネントの凝集性を高く確保します。これにより開発しやすさや、保守性（理解しやすいさ・テストしやすさ）の高さを確保します。
例えばウェブサービスのアーキテクチャ設計で、ユーザ管理、認証、モニタリング、決済、注文と、関心ごとにサービスやコンポーネントの責務を割り当てるアプローチが、SoCの原則推進の一種です。それにより、以降は認証、決済といったサービスごとに担当を分けて開発を進められるようにします。
このSoCの原則は、医療機器ソフトウェア開発で特に重要視されます。医療機器ソフトウェア開発では、アーキテクチャ設計でのコンポーネント設計で関心の分離を実施した上で、各関心ごとで懸念レベル（Level of Concern）を分析します。そして関心ごとの懸念レベルに応じて、開発の厳格さを切り分けます。例えば手術装置ならば、電気メス制御など懸念レベルの高い関心ごとを割り当てたコンポーネントには厳格で重厚な開発プロセスを、USBメディア制御といった懸念レベルが高くない関心ごとを割り当てたコンポーネントには軽快な開発プロセスを適用します。
SLAP
SLAPは「Single Level of Abstraction Principle」の略称です。日本語で単一抽象度レベルの原則と呼ばれます。SLAPは、同じレイヤならば、設計やコードの抽象度を揃えることを求める原則です。例えば「同じメソッド内ならばコードの抽象度を揃えるべき」「同じレイヤなら属するコンポーネントの抽象度を揃えるべき」といった原則となります。
SLAPの推進により、理解しやすく、保守しやすい設計・コードを実現できます。
このSLAPを実践したアーキテクチャとしてレイヤドアーキテクチャがあります。例えば車載ソフトウェアのアーキテクチャ標準のAUTOSARでは、MCAL、ECUCAL、サービスレイヤなど、抽象度に応じたレイヤを設定し、直にマイクロコントローラやハードウェアを制御するコードはMCALやECUALに閉じ込めて、それより上のレイヤ（CDD除く）では一貫してハードウェアを抽象化したコードを書くようにする、レイヤごとの抽象度の統一を行っています。
テスト設計で使えるSoCの原則/SLAPの原則
上記のSoCの原則、SLAPは、レイヤー構造やツリー構造の設計・実装を行う際に普遍的に使えるものです。これはテスト設計でも同様です。
例えばテストコードの実装では、次のような推進が有効になります。
- SoCの原則の推進：テスト設計で抽出した、テストコンテナやテストスイートを単位に、テストコードのクラスやモジュールを分ける
- SLAPの推進：テストクラス、テストメソッドの抽象度を統一する。また、Page ObjectやFacadeパターンといった抽象化・ラッピングを行う設計パターンを採用する際はそれに応じた抽象化の統一を行う。例えばPage Objectパターンならば、Page Objectに具体的なテスト対象制御の記述を書き、テストコードでは抽象化されたテストのWhatを書くように抽象度を統一する
次にテスト設計でも、次のような推進が有効になります。
- 全体のテストの責務を設計する際は、品質特性や、抽象度の高いテストの要求など、テスト分析に応じた関心ごとを単位に、テストレベルやテストタイプを分割する
- 全体のテストの責務をツリー構造で設計する際は、兄弟ノードの抽象度を合わせる。例えば、テストを責務を、最初のレイヤでテストレベルに分け、次のレイヤで抽象的なテストタイプに分け、次の末端レイヤで具体的なテストタイプに分ける、といった全体設計アプローチを取る
