COLUMN
コラム
Column 45

ソフトウェアアーキテクチャ

ソフトウェアアーキテクチャ(software architecture)とは、ソフトウェアの構築方法・設計スタイルのことで、開発対象全体の設計図を抽象的に表したものです。 実際にプログラムを作り始める前に、ソフトウェアの構造に影響を与える要件を特定することが目的です。良好なアーキテクチャは、技術要件を満たす際のビジネスリスクを削減し、ビジネス要件と技術要件の間の橋渡しのような役割を果たします。
ここでは具体的な活動や働きから、ソフトウェアアーキテクチャの重要性を見ていきたいと思います。

1.アーキテクチャの検討

①要件獲得

要件獲得のフェーズでは、ISO25010の品質特性をもとにしてアーキテクチャ設計を行います。
開発者からどのようにすれば非機能要件を満たせるかのヒアリングや、各非機能特性の優先度順位づけ等をするQuality Attribute Workshopというワークショップを行うこともあります。そこでは、具体的な品質特性をシナリオ形式で導出します。

品質特性シナリオ(Quality Attribute Scenario)は以下の6つの要素からなり、外部からの刺激に対して対象がどのように振る舞うべきかを表現します。
●Stimulus(刺激;システムに影響を与えるコンディション)
●Source(発生源;Stimulusを生み出した要素)
●Environment(環境;Stimulusが発生した状況・環境)
●Artifact(成果物;Stimulusによって刺激を受けた成果物)
●Response(応答;Stimulusによってもたらされるべき動作)
●Response Measure(応答測定;評価可能なシステムの応答単位)

②アーキテクチャ設計

Architecture Tactics(各品質特性を高めるための個々の方策)やArchitecture Pattern(レイヤパターンなどよく使われるTacticsをまとめてパターン化したもの)を参考にしながら、 Attribute-Driven Design(ADD;品質特性駆動型設計)で設計と解析を繰り返し、イテレーションしながらアーキテクチャを改善していきます。

③アーキテクチャ分析

開発の初期段階では、机上でのシミュレーションや話し合いを行います。確立された分析手法としては、Architecture Tradeoff Analysis Method(ATAM)等があります。
ATAMとは、開発の関係者が機能や目標、制約等についてシナリオを作成し分析を行うことで、トレードオフやリスクの低減を目指すものです。
Design Structure Matrix(DSM;設計構造マトリクス)を用いてDecoupling Level(各コンポーネントの独立性)を計算し、保守性の低い可能性のあるコンポーネントを抽出することもできます。

2.ソフトウェアアーキテクチャの重要性

①開発(実装)のしやすさ

ソフトウェアアーキテクチャが定義されていることでプログラムの影響範囲が明確になり、複数人で開発をする際にコンフリクトしにくくなります。 また、ソフトウェア全体の設計図としての役割も果たすので、実装に落とし込む際に機能の重複を防ぐことにも繋がります。

②テストのしやすさ

ソフトウェアの構造が分かるとテスト対象も分かりやすく、テスト対象を切り出したり合否判定に必要な情報を取得したりしやすくなります。 また、機能追加や変更時に影響範囲を絞ってテストできるので、テスト工数もより少なくすることができます。

③保守のしやすさ

保守の面では、影響範囲を意識したプログラムの改修が行えるので、デグレの多発を防ぐことができます。検証パートにおいても、テスト対象が分かりやすく、実施が必要なテストも絞ることができます。

3.まとめ

以上のように、ソフトウェアのアーキテクチャを意識することで、影響範囲を絞れることによる品質向上、納期短縮、コスト削減が期待できます。 ソフトウェアアーキテクチャへの理解は、開発工程だけでなく検証工程や保守運用を行う上でも重要な役割を果たします。
ここで述べた以外にも様々な考え方、活動があるので、興味があればぜひ調べてみてください。

ページトップへ戻る