August 2007 - Posts
前回の補足です。 アスペクト指向がソフトウェアプロダクトラインに本質的に親和性を持たない理由は、ソフトウェアプロダクトラインのアーキテクチャの拡張点には、拡張点に応じて「異なる」拡張コードを導入しなければいけないからです。一方、アスペクトの定義は、この拡張点をjoin pointで定義する場合、「同一」のadviceのコード定義を導入することになります。これでは、ソフトウェアプロダクトラインのプロダクトに応じた拡張点の拡張コード、プロダクトのバージョンに対する拡張コードの進化がうまく表現できません。
Read More...
ソフトウェアプロダクトラインの開発ではアーキテクチャに適切な拡張性を持たせ、要求に応じてアーキテクチャを再利用しつつ、その拡張性を使い個別の可変性に対応していくことが求められます。 コアのアーキテクチャの開発は、オブジェクト指向を使ったフレームワーク開発に代表されるように、アーキテクチャスタイルを考慮して進められます。拡張性の実現法は、用いるパラダイムに応じて多様な選択肢がありますが、典型的にはコンポーネントの接続を用いた設計がとられます。ここでいうコンポーネントは.NETアセンブリなどの特定プラットフォームの物理レベルのコンポーネントを指すのではなく、UMLのコンポーネントで表現される論理レベルでインターフェイス定義を持つモデルをいいます。このモデルをオブジェクト指向を用いて実現するならば、Open-Closed
Read More...
一般にスケーラビリティを得るためには、分散させないことがアーキテクチャの原則です。 プロセス間通信のマーシャリングコストはインプロセスのローカルコールに対して桁違いのオーバーヘッドになるからです。また、分散トランザクションのロックもこの状況を悪化させます。それにもかかわらず、GoogleやAmazonなど大規模サイトは分散アプローチをとり、スケーラビリティを確保しています。この事実は非分散アーキテクチャの原則を否定しているともいえます。 企業システムや大規模Webアプリケーションを想定する場合、非分散のアーキテクチャの原則は有効でしょうか。分散させない原則は企業システムではなかなか現実的に実行は困難です。性能面だけでなく、管理コスト面で分散システムには不利益がありますが、本当でしょうか？性能面と管理面の2つを考えてみましょう。
Read More...
