Browse by Tags
All Tags »
ソフトウェア工学 (RSS)
翔泳社のDBマガジンに連載中の記事のこれまでの一覧です。 No. 1 アーキテクチャとは何か 例えばイベント駆動を考える アーキテクトの悩み アーキテクチャの縦と横の関係 縦横2つに分ける理由と効果 縦と横で表現したアーキテクチャの例 もう一度世の中の動きを見る 今後の連載予定 No. 2 俊敏なアーキテクチャ システムを俯瞰する視点「俊敏さ」 抽象化を支えるボトムアップ 俊敏なアーキテクチャの構築法 ITシステム間の接続 データ品質の確保 ビジネスプロセスの最適化 ビジネスの観測可能性の実現 ビジネスの制御可能性の実現
Read More...
前回の説明の中でモジュール化という言葉を出しましたが、この定義について誤解を生まないように少し説明を加えましょう。モジュール化とは、モジュールを作るという意味ですが、ここでのモジュールは.NETでのアセンブリー、あるいは、JavaでのJARのように物理的な配布のためのパッケージではありません。これらは、配布、インストール、運用時の構成管理（セキュリティ設定など）、物理レベルの資産のバージョン管理のための単位です。一般的には、機能の単位、保守の単位、再利用の単位、配置の単位に利用されます。これらは、物理的形式（ファイル）ですので、プラットフォームや実装に依存します。
Read More...
アーキテクチャはコンポーネントの構造として定義されます。この定義を見て、アーキテクチャはコンポーネントをモジュールにして実装すると思っている人が多いのではないだろうか？ しかし、ここで指摘したいのはアーキテクチャの設計、その構造定義と、モジュール化は分離して考えなければいけないことです。たとえば、Webアプリケーションやマイクロソフトのエンタープライズシステムでの参照アーキテクチャ、JavaEEで見られる多層モデルによるアーキテクチャの構造はモジュールではありません。 アーキテクチャのそれぞれの役割に応じて論理的なコンポーネントを定義し、それらが複合構造となっています。UI、UIプロセス、ビジネスロジック、データアクセス、データハンドラ、サービスエージェントなどと呼ばれる論理的なコンポーネントを構造化してアーキテクチャを定義します。このアーキテクチャに対して、保守の単位、品質の確保のための検証の単位、ユーザに対する有効な機能の単位、再利用の単位、などがどうなるかを考えてみましょう。これらが、モジュール化の対象となります。
Read More...
前回の補足です。 アスペクト指向がソフトウェアプロダクトラインに本質的に親和性を持たない理由は、ソフトウェアプロダクトラインのアーキテクチャの拡張点には、拡張点に応じて「異なる」拡張コードを導入しなければいけないからです。一方、アスペクトの定義は、この拡張点をjoin pointで定義する場合、「同一」のadviceのコード定義を導入することになります。これでは、ソフトウェアプロダクトラインのプロダクトに応じた拡張点の拡張コード、プロダクトのバージョンに対する拡張コードの進化がうまく表現できません。
Read More...
ソフトウェアプロダクトラインの開発ではアーキテクチャに適切な拡張性を持たせ、要求に応じてアーキテクチャを再利用しつつ、その拡張性を使い個別の可変性に対応していくことが求められます。 コアのアーキテクチャの開発は、オブジェクト指向を使ったフレームワーク開発に代表されるように、アーキテクチャスタイルを考慮して進められます。拡張性の実現法は、用いるパラダイムに応じて多様な選択肢がありますが、典型的にはコンポーネントの接続を用いた設計がとられます。ここでいうコンポーネントは.NETアセンブリなどの特定プラットフォームの物理レベルのコンポーネントを指すのではなく、UMLのコンポーネントで表現される論理レベルでインターフェイス定義を持つモデルをいいます。このモデルをオブジェクト指向を用いて実現するならば、Open-Closed
Read More...
スケールアウトの分散システムにおいての鉄則は分散トランザクションを使わないことです。しかし、現在のプログラミングモデルでは.NETもＪａｖａでもトランザクション伝搬がプログラミングの位置の透過性から防止することができません。つまり、システム設計上トランザクションを利用するとき、開発プロセスの後半の配置の決定の段階で分散配置を選択すると、プログラムはそのまま分散トランザクションを実行してしまいます。この機能は位置の透過性という点では優れているのですが、アーキテクチャのスケラビリティの要求からは、このプログラミングモデルは不都合なのです。
Read More...
哲学は自然科学と違い、万人が同じ認識に至るという点での普遍性が乏しいと言われています。また、哲学は難解というだけで敬遠されています。忙しい現代人にとって実務で覚えるべきことが山のようにある状況では哲学までは手が回らないのでしょう。 IT 分野は変化が激しく実務的な側面が強いので、哲学は無関係な分野、直接的な効果は期待できないと思われているかもしれません。第一、哲学と IT 技術のどこに接点があるか、学問的にも確立されているとは言い難いです。 今回、紹介するカントの純粋理性批判は、難解さではかなりなレベルだという一般の認識ですが、ここにはソフトウェア分析やアーキテクチャの原則が多く隠されています。もちろん、当のカント自身、将来の
Read More...
レイヤーアーキテクチャを語るための事前準備。 レイヤーという言葉は開発ライフサイクル管理の中では複数の箇所に登場します。 概念レベルの分析段階で使われるレイヤーは、概念モデルの分類、責務の配置に関して使われます。したがって、分類法の一種です。一方、レイヤーアーキテクチャは、非機能要求を論理的なノード上の配置で動作させるための実現法です。ここで、論理ノードとは必ずしも物理ノードを意味しないで、ノード上のシステムのバージョンや構成定義の条件を決めます。 概念モデルは分析を経て責務がそのモデル上に配置されます。次に概念モデルを適切な分割単位である、パッケージやコンポーネント上で動作させます。このパッケージやコンポーネントの構造がアーキテクチャです。レイヤーアーキテクチャのレイヤーはここでのパッケージの一種です。概念モデルの責務は、適切な基準の下で、パッケージやコンポーネント上に配置されます。この場合、責務を純粋に動作させるのはコンポーネントの方です。
Read More...
ソフトウェア開発の対象となる要求、より根源的には価値、の表現には、振る舞いと情報の2つの側面が隠されています。 ある意味でこの2つの側面を抽象化し、名前を付けたのが価値や要求とも言えます。 ソフトウェア開発では、振る舞いと情報を一体として持つ価値や要求はそれぞれ別のモデルで表現されることが多いです。 アクティビティ、概念モデル、あるいは、DFD、ERDなどを使い分けて、ソフトウェア開発の対象領域を表現します。 このように振る舞いと情報を分ける表現は、それらを一体とした表現に比べて、それぞれの特徴や構造を表現するのに適していて、特に複雑になりがちな大規模システムでは有効となります。ドメイン毎の関心を表現するDSLの一種とみてもいいです。
Read More...
物理レベルのモジュール定義から論理レベルのモジュール定義に技術は移行しています。たとえば、Catalysisのコンポーネント定義、UML 2.xのコンポーネント、最近ですとSCA（Service Component Architecture）があります。これらはCBD（Component-based Development）を推進するものです。こうした論理レベルのモジュール定義は、物理レベルのモジュール定義につきまとう、バージョン管理、配布、起動モデル、リソースのライフサイクル管理の制約や移植性の問題から独立した仕様化を可能とする上で重要な考え方です。
Read More...
ソフトウェア開発の手法として主流なのが分割して複合化するという考え方です。 どういう単位にして分割するか、分割したものを統合するための複合化をどうするかを決めるのがモジュールの概念です。 モジュールというと、ファイルやクラスのような物理的な単位を想像することが多いのですが、組織や作業、あるいは、もっと抽象的な関心などもモジュールとなりえます。 モジュールの有効性は、何もソフトウェア技術だけの話ではなく、工業製品や経済学の分野でも主流ですし、むしろ、先行していると言えるでしょう。たとえば、Design
Read More...
