私たちはこの目でソフトウェアそのものを見ることはできませんが、すべてのソフトウェアには確かな構造があります。そしてその構造次第で、完成したソフトウェアシステムの変更容易性、パフォーマンス、セキュリティといった特性の良し悪しが決まります。この特性は non-functional requirements と呼ばれることもありますが、Software Engineering Institue (SEI) ではこの呼び方を避けています。それは、non-functional という名前が誤解を招きやすいからです。Non-functional requirements の対になっている functional requirements というのは、"System shall do X", "System shall do Y" に表されるようにシステムが何をするのかといった仕様のことを指します。一方で non-functional requirements というのは、"System shall do X in such a way that..." の...に表されるようにシステムが X をどのように実行するかといったことを指します。例としては、どれだけ速くとか、どれだけ安全にとか、どれだけ X の機能変更に時間がかかるとか、などです。
Non-functional という名前はどんな誤解を招くのでしょうか？誤解其の一として、non-functional は"機能しない"と意味にも捉えられてしまうということ。誤解其の二として、Non という名前が頭についてるため、functional requirements を第一に、non-functional requirements を第二に考えるという誤った順序を連想させてしまうということ。誤解其の三として、変更容易性、パフォーマンス、セキュリティといった要素は個々に検討しなければならない重要なシステム特性にも関わらず、non-functional という名称のせいで"functional 以外のもの"という誤ったレッテルのもとに、まとめて取り扱われてしまうということ。そこで、SEI は non-functional のかわりに quality attribute という名前を与えています。
さて、完成したソフトウェアシステムが functional requirements を満たすのは最低条件で、それに加えて変更容易性、パフォーマンス、セキュリティのような quality attribute requirements も満たさないといけません。ここで肝心なのは、functional requirements とアーキテクチャの構造決定の間には"あまり"関係がないということです。A という機能を満たすのに、tiered architecture で実現できるかもしれませんし、event driven architecture でも実現できるかもしれませんし、あるいは極端な話、ひとつの大きな monolithic な構造をしたアーキテクチャでも実現できるかもしれません。実際、monolithic なアーキテクチャではシステムが分割されていない分、パフォーマンスの面では他のアーキテクチャより優れているかもしれません（どのようなパフォーマンスを指しているかはここでは触れないでおきます）。では、数ある候補の中からどの構造をもったアーキテクチャを選べばいいのでしょうか？その選択に必要な判断材料のひとつが quality attribute requirements なのです。言い換えれば、quality attribute requirements を満足するために、変更容易性、パフォーマンス、セキュリティといった、ある特性を促進するアーキテクチャを選択すればよいのです。
quality attribute をはじめとして、アーキテクチャの構造を決定する要素はアーキテクチャドライバー と呼ばれており、以下の４つからなります。
- ビジネス制約 （business constraints）
- 技術制約 （technical constraints）
- ハイレベル機能要件 （high level functional requirements）
- 品質特性要件 （quality attribute requirements）
あ、今回のエントリーで「ここ違うよ！」という箇所があればどんどんご指摘ください^^
なるほど、大昔に MSE の人と話してたときに non-functional requirement を quality attributes って言ってたんだけど、そういうわけだったんだね。FURPS+なんて雑多なまとめ方もあるけど、「アーキテクチャドライバー」の４つで考えるほうが大分まともそうだね！
返信削除こんにちは。
返信削除「間違いだらけのソフトウェア・アーキテクチャ」という本を読んでいてアーキテクチャドライバとは？を調べた際に、こちらに辿りつきました。
機能要件とアーキテクチャがあまり関係がなく、このアーキテクチャドライバが関係しているという話は興味深いです。
jugemixさん
返信削除お返事が遅くなりすみませんでした。過去の記事ですが、文章を読んでいただいてありがとうございます。本記事で書いたことは当時大学院で学んだことですが、今でもこの考え方は通じると思います。4年半エンジニアをしてきて、レガシーコードありきの環境ではアーキテクチャの選択肢が自ずと限られてくるということも現場で目の当たりにしました。
"間違いだらけのソフトウェア・アーキテクチャ"という本は読んだことがないのですが、原著をAmazon.com で探したみたところなぜか検索がヒットしませんでした。 Amazon.jp のなか見検索で目次や参考文献を見るに Software Engineering Institute の色が強い書籍ですね。