トップ » 技術記事 » POSA 本でアーキテクチャパターンを勉強しよう(1) - パターンとは何か?

POSA 本でアーキテクチャパターンを勉強しよう(1) - パターンとは何か?

タグ: POSA アーキテクチャ パターン

どうも、あかさたです。日々の仕事に負われていると、勉強内容がどうしても「すぐに役に立つかどうか」という目先の視点に縛られがちです。本連載では、目先の視点から少し離れて、POSA 本と呼ばれるアーキテクチャパターンを論じた古典を元に、「中長期的に役に立つソフトウェア設計のやり方」を勉強したいと思います。今回は初回なので、「パターンとは何か?」(POSA本第一章に相当)を紹介します。

はじめに

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系(通称、POSA)は、アーキテクチャパターンについて記述した本です。日本語訳で 2000 年に出版されたものなので、この領域ではそろそろ古典と呼ぶ方がふさわしいものかもしれません。とはいえ、今でもアーキテクチャについて考えるときはこの本を脇に置いて考えるようにしています。

日々の仕事に負われていると、調査する技術内容がどうしても「すぐに役に立つかどうか」という目先の視点に縛られがちです。「流行の言語をどう使うか」「あるライブラリやフレームワークをいかに素早く使いこなすか」ということにとらわれ、その背後にどのような思想があるのか、ソフトウェアのアーキテクチャは本来どのようにあるべきなのかなど本質的なことを考える暇を持てないでいます。

そこで、本連載ではいまさら感はありますが、POSA 本を再読してみたいと考えています。古い本なので適用例が少し古かったりしますが、本連載で紹介する際は今時の事情に合わせながら、本書から設計の勘所を引き出せたらと考えています。

パターンとは何か?

パターンは、過去のソフトウェアの知見を前提-課題-解決策(Context-Problem-Solution)という観点からドキュメント化したものです。言い換えると、ある前提(Context)で繰り返し発生する課題(Problem)の解決策(Solution)を記したドキュメントがパターンです。

一つ例を挙げましょう。最近よく聞かれる MVC フレームワークの MVC(Model-View-Controller)もアーキテクチャパターンの一つです。MVC については後の連載で詳しく紹介しますが、前提「人間とコンピュータの対話型アプリケーション」において、「ユーザインタフェースは要求仕様の変更の影響を受けやすいが、機能中核部分(処理)とインタフェースが強く結合してしまうことによってその変更に対応できなくなる」という課題に頻繁に遭遇します。解決策として「システムを処理(Model)、出力(View)、入力(Controller)に分割する」というものが示されます。

また、課題の解決策に影響を与える要因をフォース(Force)と呼びます。MVC の例で言えば、「同一の情報を複数の形式(たとえば棒グラフと表とか)で見せるかどうか」「データの変更がアプリケーションの表示や動作に直ちに影響を与えるかどうか」などがフォースにあたります。課題にはいくつかのフォースが含まれており、アーキテクチャレベルの設計判断もしくは、アーキテクチャよりも粒度の小さな設計判断の材料として使われます。

このように、パターンは「実際に遭遇するであろう問題に対する有効な解決策のドキュメント化」を行ったものです。

一つ注意して欲しいことは、パターンは単なる思いつきの羅列ではなく、ソフトウェアの複雑性に対処しつつ、変更容易性や信頼性などと言った非機能要求の解決を支援するためのものだということです。

パターンのカテゴリ

POSA 本では、パターンを以下のカテゴリに分類しています。

  • アーキテクチャパターン
  • デザインパターン
  • イディオム

アーキテクチャパターンはシステムの基本となる構造を定義するための大規模なパターンです。デザインパターンは中規模なパターンで、システムの部分的な構造を定義するためのパターンです。アーキテクチャパターンとデザインパターンは特定の実装技術には依存しません。

先ほどの MVC を例に挙げて考えてみましょう。MVC のフォースとして、「データの変更がアプリケーションの表示や動作に直ちに影響を与えるかどうか」を挙げました。このフォースに対応するために、MVC それぞれのコンポーネントの相互作用を決めるとします。このケースはデザインパターンの Publisher-Subscriber パターン(別名 Observer パターン)を採用することができます。

このように、システム全体の基本構造には影響を与えない部分的な相互作用はデザインパターンを使って判断することができます。

イディオムは特定の言語や実装技術において有効なパターンです。また、特定のデザインパターンの各言語における実装パターンを取り扱う場合もあります。たとえば Singleton パターンの実装はさまざまな言語にさまざまなイディオムが存在します。

パターン間の関係

あるアーキテクチャパターンを採用すると、デザインパターンのような粒度の小さなパターンで解決すべき課題を生み出す場合があります。先ほどの MVC と Publisher-Subscriber パターンのようなケースです。これを「洗練」と呼びます。

また、MVC において View-Controller を一つのコンポーネントとして扱うパターンを Document-View パターンと呼びます。Windows スタンドアロンアプリ開発などによく見られるパターンです。このような変形パターンを「バリエーション」と呼びます。

ある課題を複数のパターンを組み合わせることによって解決する場合もあります。複雑なフォースが存在している場合です。これを「組み合わせ」と呼びます。

このように、パターンの間には「洗練」「バリエーション」「組み合わせ」という関係があります。

POSA 本のパターンの構成

POSA 本では、パターンを「名前」「別名」「例」「前提」「課題」「解決策」「静的側面」「動的側面」「実装」「補足」「適用例」「結論」「参考」という構成で記述しています。

「静的側面」と「動的側面」は、UML で言えば「クラス図」や「シーケンス図」で表現されるであろうソフトウェアの構造と振る舞いを記述したものです。

文書には文書のアーキテクチャのようなものがあり、アーキテクチャを把握してから読む方が理解が進みます。これは、仕様を読み下すときも同じで、たとえば UML 仕様書を読む場合にも同様のことが言えます。

まとめ

パターンは前提-課題-解決策を記述したドキュメントです。しかし、アーキテクチャの検討時にパターンを検討するという行為は結局、課題を検討する行為に他なりません。このため、パターンの検討は課題指向のアプローチを取った問題解決手法と言えるかもしれません。

パターンの学習はある意味においてソフトウェア開発における遭遇するであろう問題を疑似体験することに似ています。パターンというドキュメント手法そのものに興味のない人でも、パターンの学習に意味があるのはこのためです。

次回からは具体的なアーキテクチャパターンを紹介(POSA 本的には第二章に相当)します。それでは!

Series Navigationアーキテクチャパターン「混沌から構造へ」より「Layers(レイヤパターン)」»

執筆者紹介

あかさた

あかさた

未踏(2006年度下期)でWeb上で動作するモデリング環境 Kodougu の開発をしてました。こちらでもブログを書いています。

TrackBack URL :