http://social.msdn.microsoft.com/Forums/ja-JP/windowsazureja/thread/b76f647b-5e11-446b-92bd-2efdc2e7e362 Azure フォーラム に質問があった在庫管理の設計例を題材にしたWindows Azure Storage Service（主にKVS）による設計例をここで考えていきたい。問題の詳細は上記のリンクを参照してください。 1. 商品在庫管理テーブル 商品コード 商品名 在庫エリアコードAREA01在庫数...

マイクロソフト株式会社 萩原正義   Microsoft社は2004年よりソフトウェアファクトリーを次世代のソフトウェア開発基盤技術として推進してきた。2009年以降はWindows Azure Platformを始めとするクラウドが新しいソフトウェアの開発および実行基盤と位置付けられる段階になり、クラウドのアプリケーション開発へのソフトウェアファクトリーの適用の機会が増えると予想される。そこでここでは、ソフトウェアプロダクトラインの構築、特性モデルによる可変性（ソフトウェアの要求変更能力...

アーキテクチャの基本的な考え方は、 機能要求に先行 して構築されてることです。 この原則は、EA（Enterprise Architecture）、DOA（データ中心アプローチ）、プロダクトライン開発のアーキテクチャでもほぼ同じ思想を持っています。 一方、アジャイル開発ではTDDなどを使い、要求を定義しその実現を検証しながら開発を進めます。その結果、開発される成果物は必然的に要求との依存性が高くなります。要求との追跡性の重視や、ビジネス価値の追求を重視すれば、その傾向はさらに強くなります。それ自体は悪いことではなく...

平鍋氏のアーキテクチャとはを読んで私のアーキテクチャに対して感じていることを以下に書きます。 http://blogs.itmedia.co.jp/hiranabe/2008/10/grady-booch-dd7.html Booch氏のアーキテクチャはデザインであるが、すべてのデザインがアーキテクチャであるわけではない、という深い意味を持つ言葉は、アーキテクチャは暗黙知を表現する1形態であって、連続する意思決定から構成されていると、解釈します。暗黙知だから、創発されることもあり、また、パターン化のような形式化に限界があることが説明できます...

翔泳社のDBマガジンに連載中の記事のこれまでの一覧です。 No. 1 アーキテクチャとは何か 例えばイベント駆動を考える アーキテクトの悩み アーキテクチャの縦と横の関係 縦横2つに分ける理由と効果 縦と横で表現したアーキテクチャの例 もう一度世の中の動きを見る 今後の連載予定 No. 2 俊敏なアーキテクチャ システムを俯瞰する視点「俊敏さ」 抽象化を支えるボトムアップ 俊敏なアーキテクチャの構築法 ITシステム間の接続 データ品質の確保 ビジネスプロセスの最適化 ビジネスの観測可能性の実現 ビジネスの制御可能性の実現...

前回の説明の中でモジュール化という言葉を出しましたが、この定義について誤解を生まないように少し説明を加えましょう。モジュール化とは、モジュールを作るという意味ですが、ここでのモジュールは.NETでのアセンブリー、あるいは、JavaでのJARのように物理的な配布のためのパッケージではありません。これらは、配布、インストール、運用時の構成管理（セキュリティ設定など）、物理レベルの資産のバージョン管理のための単位です。一般的には、機能の単位、保守の単位、再利用の単位、配置の単位に利用されます。これらは...

アーキテクチャはコンポーネントの構造として定義されます。この定義を見て、アーキテクチャはコンポ���ネントをモジュールにして実装すると思っている人が多いのではないだろうか？ しかし、ここで指摘したいのはアーキテクチャの設計、その構造定義と、モジュール化は分離して考えなければいけないことです。たとえば、Webアプリケーションやマイクロソフトのエンタープライズシステムでの参照アーキテクチャ、JavaEEで見られる多層モデルによるアーキテクチャの構造はモジュールではありません。 アーキテクチャのそれぞれの役割に応じて論理的なコンポーネントを定義し...

前回の補足です。 アスペクト指向がソフトウェアプロダクトラインに本質的に親和性を持たない理由は、ソフトウェアプロダクトラインのアーキテクチャの拡張点には、拡張点に応じて「異なる」拡張コードを導入しなければいけないからです。一方、アスペクトの定義は、この拡張点をjoin pointで定義する場合、「同一」のadviceのコード定義を導入することになります。これでは、ソフトウェアプロダクトラインのプロダクトに応じた拡張点の拡張コード、プロダクトのバージョンに対する拡張コードの進化がうまく表現できません...

ソフトウェアプロダクトラインの開発ではアーキテクチャに適切な拡張性を持たせ、要求に応じてアーキテクチャを再利用しつつ、その拡張性を使い個別の可変性に対応していくことが求められます。 コアのアーキテクチャの開発は、オブジェクト指向を使ったフレームワーク開発に代表されるように、アーキテクチャスタイルを考慮して進められます。拡張性の実現法は、用いるパラダイムに応じて多様な選択肢がありますが、典型的にはコンポーネントの接続を用いた設計がとられます。ここでいうコンポーネントは.NETアセンブリなどの特定プラットフォームの物理レベルのコンポーネントを指すのではなく...

一般にスケーラビリティを得るためには、分散させないことがアーキテクチャの原則です。 プロセス間通信のマーシャリングコストはインプロセスのローカルコールに対して桁違いのオーバーヘッドになるからです。また、分散トランザクションのロックもこの状況を悪化させます。それにもかかわらず、GoogleやAmazonなど大規模サイトは分散アプローチをとり、スケーラビリティを確保しています。この事実は非分散アーキテクチャの原則を否定しているともいえます。 企業システムや大規模Webアプリケーションを想定する場合、非分散のアーキテクチャの原則は有効でしょうか...

スケールアウトの分散システムにおいての鉄則は分散トランザクションを使わないことです。しかし、現在のプログラミングモデルでは.NETもＪａｖａでもトランザクション伝搬がプログラミングの位置の透過性から防止することができません。つまり、システム設計上トランザクションを利用するとき、開発プロセスの後半の配置の決定の段階で分散配置を選択すると、プログラムはそのまま分散トランザクションを実行してしまいます。この機能は位置の透過性という点では優れているのですが、アーキテクチャのスケラビリティの要求からは、このプログラミングモデルは不都合なのです...

ソフトウェアは概念、論理、物理レベルで定義されます。もっとも論理と物理レベルの境界の曖昧性から、概念（ビジネス、what）と論理/物理（IT技術、how）で分類する場合もあります。 いずれにしても概念レベルでソフトウェアがカバーする範囲、コンテキストを明確���することが大切です。従来の概念レベルでの定義は、概念モデルと呼ばれるモデルで、ビジネスの仕組み（ビジネスアーキテクチャ）、知識とその体系化を示すことが中心でした（これ以外にビジネスプロセスなどの動的記述もありますが）。しかし、この定義をベースとしたソフトウェア開発は概念と論理レベルの間に深いギャップがあるため...

哲学は自然科学と違い、万人が同じ認識に至るという点での普遍性が乏しいと言われています。また、哲学は難解というだけで敬遠されています。忙しい現代人にとって実務で覚えるべきことが山のようにある状況では哲学までは手が回らないのでしょう。 IT 分野は変化が激しく実務的な側面が強いので、哲学は無関係な分野、直接的な効果は期待できないと思われているかもしれません。第一、哲学と IT 技術のどこに接点があるか、学問的にも確立されているとは言い難いです。 今回、紹介するカントの純粋理性批判は、難解さではかなりなレベルだという一般の認識ですが...

Software Factoriesのメタモデルに関連する技術には大きく3つの分類が存在します。 1つはPractical Software Factories in .NETに示される、開発プロセス上のメタモデルです。 これはIEEE 1471をベースとし、プロダクトライン開発におけるプロダクト開発のプロセスを記述します。 一般に開発方法論は、ロール、タスク、アセットで抽象的に記述可能であって、それをプロダクトライン開発に適用し、Software Factoriesスキーマとして定義しています...

レイヤーアーキテクチャを語るための事前準備。 レイヤーという言葉は開発ライフサイクル管理の中では複数の箇所に登場します。 概念レベルの分析段階で使われるレイヤーは、概念モデルの分類、責務の配置に関して使われます。したがって、分類法の一種です。一方、レイヤーアーキテクチャは、非機能要求を論理的なノード上の配置で動作させるための実現法です。ここで、論理ノードとは必ずしも物理ノードを意味しないで、ノード上のシステムのバージョンや構成定義の条件を決めます。 概念モデルは分析を経て責務がそのモデル上に配置されます...

SOAにおけるサービスの実装法ではカプセル化の考え方から、どんな実装法でも選択が可能です。 多くの場合は、OOPを使い、インターフェイス定義を使ってクラスを実装するとともに、インターフェイス定義をWSDLで外部に公開します。 あるいは、Contract-Firstで開発する場合には、先に契約を定義して、実装法を後で選択します。 しかし、この場合でも主流の開発言語がOOPであることや、SOAで必要となる他の非機能要求の実現のために必要な機能を提供する実行環境がOOPのフレームワークで提供されているので...

現在のソフトウェア技術は不必要に複雑な部分があります。 世の中の要求から、複雑にならざるを得ない部分もあるのですが、 技術的な発展の経緯や、かならずしも技術だけでは決まらない互換性、標準化、政治的決定などがあるからです。 たとえば、ファイナライザは非決定論的なVMのGCに依存する以上、リソースの消費に対して 安全な見積もりができないという点では、あるべき機能ではありません。 また、オブジェクトを生成するDI（依存性注入）と解放するGCは、対となる機能ですが、 実現する場所もメカニズムも異なっています...

トランザクション処理はデータ管理の必須機能で、プログラミングモデルの進化とともに容易に利用できるようになってきました。 このプログラミングモデルの進化で記念的な出来事がMicrosoft Transaction Server（MTS）のプログラミングモデルの登場です。COMコンポーネントに属性による宣言を付け加えることで、トランザクションの実行スコープをメソッドのブロックに限定する発想でした。これ以降は、コンポーネントないしオブジェクトと、トランザクション処理に関するリソースマネージャとの親和性がよくなりました...

ソフトウェア開発の対象となる要求、より根源的には価値、の表現には、振る舞いと情報の2つの側面が隠されています。 ある意味でこの2つの側面を抽象化し、名前を付けたのが価値や要求とも言えます。 ソフトウェア開発では、振る舞いと情報を一体として持つ価値や要求はそれぞれ別のモデルで表現されることが多いです。 アクティビティ、概念モデル、あるいは、DFD、ERDなどを使い分けて、ソフトウェア開発の対象領域を表現します。 このように振る舞いと情報を分ける表現は、それらを一体とした表現に比べて、それぞれの特徴や構造を表現するのに適していて...

Software Factoriesはソフトウェアプロダクトラインとモデル駆動型開発を組み合わせた技術ととらえる点が強調されています。この組み合わせはソフトウェアプロダクトラインの分野では最近流行しているのですが、これと並んで、Software Factoriesは開発プロセスの設計と実装が重要なテーマです。 たとえば、簡単な例で飲み会で終電に遅れそうになっている例を考えてみましょう。この例では、目的は無事に自宅に帰宅できることです。この目的を遂行するために必要な活動をプロジェクトと見なします...

物理レベルのモジュール定義から論理レベルのモジュール定義に技術は移行しています。たとえば、Catalysisのコンポーネント定義、UML 2.xのコンポーネント、最近ですとSCA（Service Component Architecture）があります。これらはCBD（Component-based Development）を推進するものです。こうした論理レベルのモジュール定義は、物理レベルのモジュール定義につきまとう、バージョン管理、配布、起動モデル、リソースのライフサイクル管理の制約や移植性の問題から独立した仕様化を可能とする上で重要な考え方です...

ソフトウェア開発の手法として主流なのが分割して複合化するという考え方です。 どういう単位にして分割するか、分割したものを統合するための複合化をどうするかを決めるのがモジュールの概念です。 モジュールというと、ファイルやクラスのような物理的な単位を想像することが多いのですが、組織や作業、あるいは、もっと抽象的な関心などもモジュールとなりえます。 モジュールの有効性は、何もソフトウェア技術だけの話ではなく、工業製品や経済学の分野でも主流ですし、むしろ、先行していると言えるでしょう。たとえば、Design...

Software Factoriesは開発環境と開発プロセス、それを支援するアーキテクチャなどの開発資産を合わせた開発基盤技術です。開発方法論というと、開発手順、成果物、開発組織を決定するので、Software Factoriesは開発方法論を含んでいると言えるのですが、特定の開発方法論を決めないでその枠組みだけを決めている点で、開発方法論ではありません。 現在までに、開発の生産性やプロジェクトの成功確率の改善のために、多くの技術が開発され利用されています。コンポーネントやフレームワーク、IDEやソースコード管理...

マイクロソフトの萩原正義です。Software Architectです。 このブログでは、ソフトウェア技術や開発方法をできるだけ工学的な視点で扱います。 この目的のために、以下の点に留意します。 技術に対して中立な姿勢をとります。筆者が属しているマイクロソフト社の技術が中心となるのは、筆者が業務として時間的にマイクロソフト社の技術に接している時間が多いからですが、必ずしも、その技術に偏った視点を持っているのではありません。必要に応じて他の技術の引用や客観的な比較を行います...