Automotive SPICE 4.0 SWE.2 ソフトウェアアーキテクチャ設計とは？
Automotive SPICE 4.0が発行され、Automotive SPICE （VDA）ガイドラインも含めて内容を確認していますが、SWE.2 のガイドラインにとても良い説明が書かれていますので、なるべく原文を引用しながら、個人的な見解を書いてみます。
青文字：VDAガイドラインから引用
黒文字：筆者のコメント
ソフトウェアアーキテクチャ設計の目的
Automotive SPICEはそれぞれのレベルでの設計上の決定を通じて、要求が体系的に下位レベルに細分化されるべきであることを強調している。
つまり、要求レベルのフワっとした内容を、ソフトウェアで実現するための仕様に落とし、仕様をインプットにして詳細な設計を実施していく段階的なアプローチを前提としているということです。
ソフトウェア構造においては、コンポーネント、モジュール、ユニット、関数と構造化設計をしていくことが高品質で変更にも強いソフトウェアを作ることが可能になります。結果的に、生産性も高まってくるわけで、こういった考え方がソフトウェアアーキテクチャ設計の目指すところになります。
その背後にある考え方は以下の通りである：
- あまりにも多くの情報に圧倒されて間違いを犯さないようにする（「分割統治」の原則）
- 将来のスタッフにソフトウェアの文書を提供し、潜在的に膨大なソースコードからソフトウェアがどのように作動するかを非効率的に学習する必要がないようにする
- 暗黙の知識が文書及び最終製品において失われていないことを確実にする
- それぞれのレベルでの要求が完全にカバーされていることを確保する
- 最終的に、余分なソフトウェアエレメントが存在しない（つまり、SWは要求が必要とする以上のものを含まない）
小規模ソフトウェアの場合、要件毎に必要な関数を作り関数と関数をつなげた方が手っ取り早く機能を実現できるため、構造化設計の必要性を肌で感じていない方も多いのだと思っています。開発規模の増大化や実現機能の複雑化に加え、再利用性が事業上の重要課題になってくると、そのパラダイムを変える必要が出てくるはずです。
事業に貢献するためのソフトウェアアーキテクチャを作りあげること。アーキテクチャに基づいて、それぞれの領域の専門家が分業していくことで、品質はもとよりTime to Marcketに貢献できるソフトウェア開発と保守が可能になるのです。
ソフトウェアアーキテクチャ設計
静的及び動的なビューを超えて、どのようなビューが必要であるかについての共通的な定義はなく、ビューがいくつあれば完全であるかに関する基準はない。ビューの数及び種類は製品のサイズ並びに複雑性に大きく依存する。
業界には、綿密なアーキテクチャ設計記述のために、ビューに必要となる情報の種類（ある種類のビューを構築するためのパターン、テンプレート、規約の集合体である「ビューポイント」）、及び複数のビューの統合について特定したアプローチがいくつか存在する。
多くの場合、ソフトウェアアーキテクチャ設計はテキストの説明によって補足されるソフトウェアのグラフィック的な表現である。
ここにも書かれているように、アーキテクチャ設計はグラフィック系のソフトウェアを使用して作成することが一般的です。過去には、VISIOなどのDraw系ソフトウェアを使われている方が多かったようですが、現在ではSysML系のソフトウェアなどを使われているケースも多くなっています。更には、テキストから図表を自動作成してくれるSphinxの活用も一般的になってきているようです。
動的なビューとしては、つぎのような例が一般的でしょう：
-
-
-
- シーケンス図（ソフトウェアコンポーネント間の相互作用を記述）
- 状態遷移図（製品を制御するために必要な動作状態と状態を遷移するイベントを記述）
- アクティビティ図（処理実行の流れと条件分岐を記述）
- データフロー図（データの流れを記述）
-
-
開発するソフトウェアにとって、最適なビューを使うことがポイントとなります。
動的ビューの事例は、弊社発行のAutomotive SPICE入門書籍でも掲載していますので参考にしてみてください。https://www.bgarage.co.jp/news/323/
静的なソフトウェアアーキテクチャのビューは、ソフトウェアを高い凝集性及び低い結合性をもつ管理可能なエレメントに分解することを可能にする。この分解は、これらのアーキテクチャエレメントへの要求の割り当てを支援し、開発者への作業パッケージの配布を整理するのに役立つ。
アセスメントの範囲外で開発されたソフトウェアのアーキテクチャエレメント（例えば、オープンソースソフトウェア、プラットフォームソフトウェア、第三者ソフトウェア）も、ソフトウェアアーキテクチャ設計の専用エレメントとして含まれ、同様にインタフェース分析、動的な振る舞い、リソース消費目標などに対しても考慮されなければならない。
必要に応じて、アーキテクチャエレメントはアーキテクチャ設計において最下位レベルのエレメントであるコンポーネントに至るまで更に具体化される。コンポーネントは１つ以上のユニットで構成され、ソフトウェア詳細設計（SWE.3）の対象となる。
静的ビューについては、疎結合な設計をするために互換性や拡張性の観点からみて最適な構造を作ることを支援します。要求全体を見ながら、共通的な機能をまとめたり個別機能間とのインタフェースなどを考慮しながら、ソフトウェアコンポーネントを配置していくことになります。
このような構造設計を実施すると、要求とソフトウェアが1対1にならないため、分割された各ソフトウェア要素にソフトウェア要求を割り付けることや、要求に対してソフトウェアコンポーネント間の相互動作を文書化して要求の網羅性を検証する必要が出てきます。
そもそも構造化ができていない、関数の連結によるアーキテクチャであれば、要求の割り当てやトレーサビリティもあまり意味を持たないものになります。
疎結合が高い設計は、分業化が進むことにより生産性や品質へ寄与しますが、反面ソフトウェアの全体を見渡せる人材が少なくなり、問題解析が１人では困難になるという副作用もでてきます。
ソフトウェア構造の例は、コラム（ソフトウェアドキュメント間のトレーサビリティ）をご参照ください。https://www.bgarage.co.jp/news/190/
割り込みに関して
最先端技術によれば、割り込みサービスルーチンはドメインロジックの振る舞い又は複雑なアルゴリズムを含めてはならないが、割り込み処理は依然として並列制御又はデータフローさえも表示している。特に、高い割り込み負荷はアプリケーションにおいて干渉を引き起こす可能性がある。
そのため、Automotive SPICE v4.0 では、それらをソフトウェア設計、特に動的な設計に反映させるためにソフトウェアユニットとして関連する割り込み処理を扱うことが重要であると考えている。
割り込みについては、リアルタイムOSで見られるような割り込みクラスを定義して、タスクをダイナミックに制御することができていないことが多いようです。スケジューラに頼りすぎた設計になり、思わぬ障害につながるケースも数多く見てきました。ソフトウェアのアーキテクチャ設計では、割り込み処理に加えて、タスク制御やリソースおよび性能面も含めたソフトウェアの基本となるメカニズムの可視化も大切になります。
日吉 昭彦