偉大なるアーキテクトの秘密

By Don Awalt and Rick McUmber
RDA Corporation

July 2004

要約： 優れたアーキテクトは皆、明確な抽象化レベルでソリューションを概念化できる技を身につけています。ソリューションを個々のレベルへと組織化することによって、アーキテクトは、残りの複雑な部分をすべて無視して、ソリューションのある一部分に集中できます。本稿では、抽象化レベルをITソリューションに適用するテクニックを示し、ほかの技術分野と比較していきます。

目次

ITソリューションへの抽象化レベルの適用
抽象化レベル：すべての技術者のための強力な武器
抽象化レベルを適用する際の基本法則
ITシステムへの抽象化レベルの適用
単純な枠組み：4つの抽象化レベル
反復してレベルを発展する
抽象化レベルの基本法則を再考する
エンタープライズソリューションをサポートするためのレベルの拡張
メリット
まとめ
自己評価

ITソリューションへの抽象化レベルの適用

エンタープライズアーキテクトは、直面する膨大な量の複雑さに挑んでいます。業務を自動化する部門アプリケーションを開発することは、その複雑さのひとつです。しかしそれとはまったく別に、さまざまな業務活動をする何万ものITユーザーをサポートするための、アプリケーション、サーバー、そしてデータベースを備えたIT実験室とも言える、世界をまたにかけたネットワークを設計し、組み立て上げることも、また複雑です。複雑なものを組み合わせたときでも、ITネットワークは、いつも利用可能でなければならず、また動作時の反応がよく、企業の重要な情報資産を保護しなければなりません。 ITネットワークには、こういったすべての条件に加えて、業務の必要性に応じて変更したり、新しいテクノロジが登場したときに、それを採用できるようにする柔軟性も不可欠です。

アーキテクトのなかには、明らかに優れた人がおり、この複雑さのなかで成長していきます。私たちは幸運にも、本当に偉大なアナリストと、私たちよりも経験を積んだアーキテクトと一緒に仕事をしました。これらの経験を踏まえ、私たちは、並はずれたアーキテクトは何から生じるのかを分析しました。

例外なく、偉大なアーキテクトは皆、ソリューションを明確な抽象化レベルで概念化できる能力を身につけています。ソリューションを明確なレベルへとまとめることによって、アーキテクトは、残りの複雑な部分をすべて無視して、ソリューションのある一部分に集中できます。ひとたびソリューションの一部を安定させれば、別の部分へと次々と展開し、最終的には、実装可能な凝集性のあるモデルへと洗練化することができます。

大半のソフトウェア開発者は、ソリューションを抽象化レベルへと分解すべきだということはわかっています。しかし実際のプロジェクトに適用するのは、非常に難しいのです。最初の障害に遭遇すると、つい抽象化レベルを放棄して、コーディングを進めていってしまいがちです。偉大なアーキテクトは、この試練を乗り越え、プロジェクトのライフサイクル全体にわたって、抽象化レベルを維持するように自制しています。そうしないと、複雑さのなかに埋もれてしまうということを実感しているからです。

この記事では、ITソリューションに対して抽象化レベルを適用するためのテクニックを示します。私たちはまず、単純な例を通じてこのテクニックを実証します。そして次に、形式化された抽象化レベルに基づいたシステム成果物の構造を提示します。

抽象化レベル：すべての技術者のための強力な武器

土木技術者のような、ほかの技術分野では、何世紀もの間、抽象化レベルを活用することで複雑さに対処してきました。ここからは、他のより成熟した技術分野で、抽象化レベルをどのように適用しているのかを検証していきましょう。手始めに、新しい世代ごとに、どんどん複雑になってきたコンピュータシステムを設計する電気技師を見ていきましょう。

ハードウェア技術者

システム設計者は、抽象化レベルを用いて、コンピュータシステムをモデル化します。それぞれのレベルは適切に定義され、システムの異なる観点を示しています。多くのシステムは、主たる3つのレベルで設計されています。それは表1に示す、「システム」、「サブシステム」、「コンポーネント」です。

階層化することで、技術者はコンピュータシステムにおける複雑な多くのものを、1つの機能するものにまとめることができます。極小の部品レベルでは、コンピュータを理解することは到底不可能です。 1つのインテルのItaniumチップには、およそ2,500万のトランジスタがあります。

複雑なものを抽象化した層へと分けていくという手法は、何もITに関連した分野に特有のものではありません。同様の手法は、航空工学から微生物学に至るまで、ほかの多数の分野でも使われています。

抽象化レベルを適用する際の基本法則

抽象化レベルを適用する場合、技術者は皆、この基本法則に従います。抽象化レベルをソフトウェアに適用する場合にも、この法則は成り立ちます。

レベルの数とその範囲を、適切に定義します。技術者達が複雑なシステムを共同で開発する場合には、チームのメンバーは皆、レベルに対する同じ理解を共有しなければなりません。設計者が設計を決めるときには、決定事項を細部にわたって適切なレベルで整理しなければなりません。

3つの抽象化レベルは、次のように定義されます。

レベル名	レベルの範囲
システム	コンピュータ技術者は、システムをさまざまなサブシステムから構成します。たとえば、バックプレーン、回路基板、シャーシ、CD/DVDドライブやディスクドライブといった内部デバイス、ディスプレイやキーボード、マウスといった外部デバイスです。技術者は、そのシステムで使われるサブシステムやインターフェイス、相互接続について考えます。それぞれのサブシステムのインターフェイスは、サブシステム設計者に向けた正式な仕様としてドキュメント化されます。
サブシステム	サブシステム技術者は、コンポーネントを統合してサブシステムを設計します。たとえば、マザーボードの設計者は、メモリチップやDMAチップ、CPUチップといったコンポーネントを統合してマザーボードを設計します。同様に、ディスプレイ技術者は、ビデオカードや CRTといったコンポーネントを統合してモニタを設計します。サブシステム技術者は、サブシステムで使われるコンポーネントやインターフェイス、内部接続の表現を考えます。それぞれのコンポーネントのインターフェイスは、コンポーネント技術者に向けた正式な仕様としてドキュメント化されます。
コンポーネント	コンポーネント技術者は、サブコンポーネントを組み立てたり統合したりしてコンポーネントを設計します。たとえば、メモリチップの設計者は、集積回路を複雑に組み合わせてチップを設計します。

表i 定義された3つの抽象化レベル

レベル名	レベルの範囲
業務ドメイン	企業は、ブラックボックス化された中央アクターです。 業務の外部アクターの観点で業務をモデル化します。 業務でのやりとりだけをモデル化します。伝達手段は含めません。
業務プロセス	業務ドメインレベルの業務のやりとりを具現化し、業務プロセスのワークフローをモデル化します。 システムはブラックボックス化された中央アクターです。 システムの外部アクターの観点で業務プロセスをモデル化します。業務取引を完結させるための伝達手段を含めます。
論理的	システムの内部設計をモデル化します。 主なシステムのサブコンポーネントが、主たるアクターとなります。 ブラックボックス化されたシステムの内部的な観点でシステムの振る舞いをモデル化します。
物理的	実装の物理的な構造をモデル化します。

表ii 抽象化レベルのための単純な枠組み

それぞれのレベルにおける複数のビュー

ときには、ひとつのレベルに存在する複雑さが手に負えなくなり、一度では理解できないこともあります。そのような場合、技術者は、ひとつのレベルに存在する設計を、複数のビューから眺めます。それぞれのビューでは、設計のある特定の側面だけをとらえます。しかし抽象化レベルは変わりません。たとえばマザーボード技術者は、マザーボードのそれぞれの層でビューを作成し、その層をつなぐ道筋となる設計をモデル化します。

図1 コンピュータシステムの抽象化レベル

レベル間の一貫性の維持

意図したようにシステムが機能するためには、それぞれの子となる層は、その親となる層に対して適切に洗練化されたものでなければなりません。コンピュータシステムの設計が、IDEバスからSCSIバスへと変わる場合は、すべてのデバイスのインターフェイス仕様もSCSIへと変更しなければなりません。レベル間で同期がとれていなければ、システムは最上位レベルにおいて、予期したようには動きません。

ITシステムへの抽象化レベルの適用

ここまでは、他の分野ではどのように抽象化レベルを適用しているのかを見てきました。今度はITソリューションに、このテクニックを適用していきましょう1。以降のセクションでは、典型的なITアプリケーションに要求される、設計ならびに実装モデルに適用可能な抽象化レベルのテクニックを示します。ここでは架空の小売業者のためのオンライン注文システムという簡単な学習用の例を使って、そのテクニックを示していきます。この例では、アーキテクチャだけでなく、システム要求や小売業界によって定義される業務コンテキストについても話題を広げていきます。

単純な枠組み：4 つの抽象化レベル

この簡単な例では、ITソリューションのための、次の4つの抽象化レベルを定義します。

• 業務ドメイン
• 業務プロセス
• 論理的
• 物理的

それぞれのレベルでは、そのレベルにおける振る舞いに対する「動的なビュー」と「静的なビュー」の両方を示します。動的なビューでは、オブジェクト間のメッセージをモデル化します。その一方で、静的なビューでは、オブジェクトの構造やオブジェクト間の関係をモデル化します。

業務ドメインレベルの抽象化

上記に示した範囲定義の規則を適用すれば、業務ドメインレベルにおいて、小売業者はブラックボックス化された中央アクターとなります。顧客は外部アクターです。業務ドメインレベルでは、顧客の観点でモデル化されます。購入というやりとりだけがモデル化されます。購入を完了するために使われる伝達手段は、このレベルには含まれません。それは業務プロセスのレベルに入ります。

品物の購入手順

1. 顧客は小売業者の品物カタログを閲覧します。
2. 顧客は品物を1つないし複数選択します。
3. 顧客は小売業者に対して、それらの代金を支払います。

図2 業務ドメインレベルにおける小売業者からの品物の購入に関する動的なビュー

図3 業務ドメインレベルにおける小売業者からの品物の購入に関する静的なビュー

動的なビュー

業務ドメインレベルにおける動的なビューでは、顧客と小売業者とのやりとりをモデル化します。次の図は、業務ドメインにおけるコンテキストを要約したものであり、業務のやりとりを物語る単純なユースケース図です。

オンラインでの品物の購入手順

1. 顧客は小売業者のWebサイトを訪れます。
2. 顧客は小売業者のオンラインカタログを閲覧します。
3. または、顧客はカタログに対してキーワード検索を実行します。
4. 顧客は品物を選択します。
5. 顧客はオンラインアカウントでログインします。
6. 顧客はその品物の注文を作成します。
7. 顧客はクレジットカードでその品物の代金を支払います。
8. 従業員は完了していない注文がないか、システムをチェックします。
9. 従業員は棚から品物を取り出し、箱詰めして注文の配送先へと配送することで、注文を完了します。
10. 従業員は棚の商品を減らしたという配送情報で、システムを更新します。
11. システムは顧客に発送状況を知らせるため、自動的にメールによる通知を送信します。

＜バリエーション＞

• 顧客は注文を作成するよりも前の時点でログインするかもしれません。
• 手順5において、顧客がまだアカウントをもっていない場合は、新しいアカウントを登録できます。
• 手順7において、クレジットの承認が失敗した場合は、そのクレジットカードによる支払を拒否します。

図4 業務プロセスレベルにおける、小売業者から品物をオンラインで購入する際の動的なビュー

静的なビュー

業務ドメインレベルにおける静的なビューでは、クラスの構造やユースケースで示されたオブジェクトの関係をモデル化します。言い換えれば、この抽象化レベルにおいて、購入という処理を完了するためには、顧客はどのオブジェクトを理解する必要があるかということです。図5に、業務ドメインレベルにおける、静的なビューのクラス図を示します。

図5 業務プロセスレベルにおける、小売業者から品物をオンラインで購入する際の静的なビュー

顧客はPerson (人) のひとつのインスタンスです。顧客と小売業者との関係は、Account (勘定) として具現化します。すべてのPurchase (購入) は、顧客のAccountに結び付けます。 Purchaseは、購入したそれぞれのItem (品物) に結び付けます。それぞれのItemは、特定のProduct (商品) であり、Productはメタクラスパターンに従います。 Productのインスタンスは、そのProductクラス内だけで有効です。メタクラスとしてProductをモデル化することで、追加のProductは純粋にデータ駆動のプロセスであるCatalog (カタログ) に追加するだけでよく、クラスモデルを密にしないという意味において、より柔軟になります。クラスの仕上げとして、それぞれのPayment (支払い) をPurchaseに結び付けます。

ここまで見てきたように、このレベルにおけるこのモデルは、小売業者がオンラインかそれとも旧来のものか、規模が大きいか小さいかに関わらず、典型的なものです。このモデルは、［業界］の業務ドメインモデルにおいて、実際に企業をブラックボックス化した中央アクターとして定義しなければならない理由を説明しています。同じ業界における企業は、外部アクターに対して同じ一定の業務のやりとりを行う傾向にあります。そうでありながらも、同じ業界においても企業によってやり方は大きく違うので、その企業に固有の業務プロセスは、業務ドメインレベルでは除外します。

業務ドメインレベルでは、外部アクターの観点から見た業務のやりとりだけに着目します。私たちは、そのやりとりを実行するための実装機構を含めないように注意しなければなりません。そういった詳細は、次の抽象化レベルに属するものです。つまり、この場合には「閲覧」、「選択」、「購入」、「支払い」だけをモデル化します。これらのやりとりがどのように遂行されるか――電話なのか、郵便なのか、電子メールなのか、Webアプリケーションなのか、対面取引なのか、小切手なのか、クレジットカードなのか、現金なのか――といったことは、モデル化しません。

業務プロセスレベルの抽象化

この、次のレベルの抽象化では、業務ドメインレベルでとらえたやりとりを実現するための企業の業務プロセスをモデル化します。システムレベルで、企業というブラックボックスに「ズームイン」し、業務取引の実行のために協調する、すべての従業員とシステムを識別します。このレベルでは、開発されようとしているシステムが、ブラックボックス化した中央アクターとなります。

このシステムレベルに対して範囲定義の規則を適用すれば、オンライン注文システムは、ブラックボックス化した中央アクターとなります。顧客と従業員は、外部アクターです。このシステムレベルでは、顧客と従業員の観点でモデル化します。顧客は、オンラインで購入を行います。支払いはクレジットカードによって行います。その注文は、顧客の送付先に品物が配送されることで完了します。出荷通知は、電子メールで送信されます。

動的なビュー

動的なビューでは、業務ドメインレベルにおける購入取引を再現しますが、今回は、小売業者の内部の業務プロセスを表します。図4は、業務プロセスのコンテキストを要約しており、システムとそのアクターとのやりとりを物語る単純なユースケース図です。

静的なビュー

このレベルの静的なビューでは、業務プロセスのレベルにおけるユースケースで示されるオブジェクトをとらえ、クラスのモデルを洗練化していきます。言い換えれば、「注文をオンラインで作成し、その注文を完了するためには、顧客と従業員は、どのオブジェクトを理解する必要があるか」ということです。図5は、業務プロセスにおける静的なビューのためのクラス図を示しています。私たちは、業務プロセスレベルで物事をとらえるために、業務ドメインレベルのモデルを洗練化していきます。 Person、Account、Company (企業) という抽象化概念は、CatalogやProduct と同様に、今までと変わりありません。ただし、業務ドメインモデルにおける抽象的なPurchase (購入) というイベントは、Order (注文) で置き換えます。

Orderには、Catalog中のProductと結び付けたLineItem (品目明細) を含ませます。このレベルでは、企業内部の業務プロセスがモデル化されるので、棚卸表 (特定の場所における品物の識別番号を示すSKU (Stock Keeping Unit) という属性) をとらえる必要があります。さらに、オンラインシステムにアクセスできるようにするため、顧客のUser Account (ユーザーアカウント) をモデル化します。 Paymentは、CreditCardAccount (クレジットカード引き落とし口座) を使って実現します。アメリカ国内の地理的な位置はLocation (場所) で示し、請求先やOrderの配送先として使います。 Shipment (出荷) には、積荷に含まれているItemを含めます。

このシステムレベルの抽象化では、一般に多くの創造性が要求されます。というのは、業務プロセスの流れを合理化していくレベルであるからです。その際、業務プロセスレベルで、いくつかの異なる手段を用いて、業務ドメインレベルのひとつの取引を実現するのが一般的です。たとえば、購入は、オンラインだったり、電話だったり、注文用紙によるメールやファックスだったり、小売店での対面取引だったりします。これらは、業務プロセスレベルでモデル化する必要があります。たとえクレジットカードの承認者が小売業者から見て外部アクターであるとしても、このレベルに含めるという点に注意してください。なぜなら、このレベルにおいて、最初に現れる業務プロセスの実装に不可欠だからです。

結局のところ、システムはテクノロジには依存しないという点に注目してください。この例のオンライン購入システムは、どんなWebテクノロジを使っても実装できるはずです。ブラックボックス化されたシステムのテクノロジは、アーキテクチャによって決まります。

論理レベルの抽象化

論理レベルでは、ブラックボックス化されたシステムに「ズームイン」し、システムの高水準な設計を表します。アーキテクトは、テクノロジを選択し、高水準のシステム構造を定義します。この単純な例では、プレゼンテーション層とビジネス層のホストにMicrosof t IIS／Microsoft ASP.NETサーバーを、そして、データアクセス層として永続的なデータを保存するためにMicrosoft SQL Serverデータベースサーバーを、それぞれ使ってシステムを構成します。

動的なビュー

論理レベルの動的なビューでは、システムの主要なコンポーネント間を流れるメッセージを追跡します。例として、ConfirmOrder (注文確認) というWebフォームをサブミットしたときの流れを追跡したものを図6に示します。

注文の確定

1. 顧客は注文の概要を再確認し、フォームを送信することで、注文を確定します。
2. ASP.NETはConfirmOrderPageへとPOSTします。ConfirmOrderPageは、現在の注文を取り出し、Order.Save()を呼び出します。
3. Order.Save()は、注文が業務規則に適合するかを調べます。適合しないなら、Saveはエラー一覧を返します。
4. 適合しているなら、Save()は、支払総額を承認するために、クレジットカードの承認者を呼び出します。
5. 成功したなら、Save()は、Orderのすべての部分をシリアル化し、データアクセス層を呼び出して、SaveOrderSPを実行します。
6. データアクセス層は、その要求をストアドプロシージャへと転送します。
7. SaveOrderSPは、その注文をデータベースへと保存します。

図6 論理レベルにおける、小売業者から品物をオンラインで購入する際の動的なビュー

静的なビュー

論理レベルでは、静的なビューでも、やはりシステムの内部へと視点を切り替えます。業務プロセスレベルでは、業務プロセスで現れる実世界の抽象的な概念をモデル化しました。論理レベルでは、その抽象化されたモデルを、システムの内部に表現可能なものとしてモデル化します。実際のシステムでは、アーキテクトは、それぞれのソフトウェア層 (プレゼンテーション層、ビジネス層、データアクセス層) におけるクラスを設計することになるでしょう。ここでは話を簡単にするため、図7に、ビジネス層の静的な設計に限って、システムレベルの抽象化をどのように洗練化して設計していくのかを示します。

図7 論理レベルにおける、小売業者から品物をオンラインで購入する際の静的なビュー

アーキテクトは、ビジネス層のインターフェイスを設計するために、システムレベルにおけるクラスを洗練化していきます。

このシステムにおいては、すべての勘定と顧客は、小売業者のものです。つまり、Companyのインスタンスをひとつ作成して、それをすべての勘定に結び付けるということはありえません。そこでCompanyは、このレベルでは無視します。この例では、CreditCardAccountのインスタンスを個別に作るのではなく、単純に、クレジットカード番号や請求先をPaymentに格納することにします。さらにシステムは、売り切れてしまったItemのインスタンスを作ることもありえません。そこでItemをモデルから省き、代わりに、LineItem内の注文された品物 (item) の数を追跡し、配送された品物の数を、新しく導入したShippedItemsクラスへと保存するようにモデル化します。

アーキテクトはさらに、ビジネス層で提供するサービスの粒度も定義します。この例ではビジネス層において、Account、UserAccount、Order、Shipment、そして、Catalogのそれぞれのサービスに対して、「作成」、「読み取り」、「更新」、「削除」 (CRUD) を提供します。楕円形は、CRUD操作の粒度を示します。

たとえこのレベルのクラスが、業務プロセスのクラスのスーパーセットとして適切でない場合でも、アーキテクトは、業務プロセスのクラスを直接洗練化し、視点をシステムの外部から内部へと変えることで、この設計へとたどり着けるという点に注意してください。

物理レベルの抽象化

物理レベルの抽象化では、システムの実装面での構造をとらえます。システムは、ノードのネットワークとして実装されるものであり、それぞれのノードは、ハードウェアやソフトウェアとして構成されます。論理的なビューにおける3つのソフトウェア層 (プレゼンテーション層、ビジネス層、データ層) は、コードとして物理的に実装され、これらのノードへと配置されます。論理的なビューにある永続的なクラスは、SQL Serverデータベース内のリレーショナルなテーブルへと物理的に格納されます。

動的なビュー

動的なビューでは、物理的な構成のノードを通るメッセージの流れを追跡します。 ConfirmOrderはHTTPによって、顧客のブラウザからインターネットを流れて、小売業者のファイアウォールへと伝わり、WebサーバーへとPOSTされます。W ebサーバでは、Microsoft WindowsがIISへと転送し、IISはMicrosoft ASP.N ETへと伝えます。そしてConfirmOrder.aspxに渡します。幸いなことに、現在の開発ツールは、物理的なネットワークのほとんどを隠蔽します。しかしながら、アーキテクトは、ネットワークのボトルネックやセキュリティの問題を回避するために、物理層を理解する必要があります。

静的なビュー

静的なビュー (図8) では、論理的なビューにある永続的なクラスを、物理的な表現へと洗練化します。私たちの小売業の例では、ビジネス層のクラスは、次に示すSQL Serverのテーブルに格納します。

図8 物理レベルにおける、小売業者から品物をオンラインで購入する際の静的なビュー

クラスはリレーショナルなテーブルへとマッピングし、属性は列として実装します。 1対1の関係や1対多の関係は、外部キーを用いて実装します。楽観的な並列性は、datetimeフィールドをCRUD操作の対象となるそれぞれの親クラスに割り当てることによって実装します。

論理レベルの設計時には、アーキテクトは主に、システム機能の実装に着目しています。つまりシステム機能は、この時点で既にカバーされているはずなので、アーキテクトは物理レベルでの最適化に集中できます。

反復してレベルを発展する

この枠組みを確立したら、アーキテクトは、何度か反復してソリューションを発展させていきます。それぞれの反復では、追加機能を組み込みます。たとえば、送り状、入荷待ち、人による注文、電話による注文などです。その際には、アーキテクトは適切な抽象化レベルを変更します。そして、その変更を物理的な実装レベルへと洗練化していきます。

抽象化レベルの基本法則を再考する

さて、ここで取り上げた例が、抽象化レベルの基本法則に適するかどうか調べてみましょう。

• レベルの数や範囲の適切な定義： 私たちは、4つのレベル を定義しました。それは「企業のブラックボックス」、「システムのブ ラックボックス」、「システム内部の論理的な設計」、「物理的な実 装」です。
• それぞれのレベルにおける複数のビュー： この単純な例では、それぞれのレベルにおいて、動的なビューと静的なビューを示しました。
• レベル間の一貫性の維持： 業務ドメインモデルで変更が生じると、その変更による影響は、下位レベルへと伝わっていきます。たとえば小売業者が製品の保守契約を申し出る場合、アナリストは、業務ドメインモデルにMaintenaceContract (保守契約) を加えて、それを物理的な表現へと洗練化していくことになります。すべてのレベルを同期することは、大規模なシステムを維持するために、とても重要です。拡張せよとの要求があれば、アナリストは、対応するレベルに与える影響を精査します。拡張には、業務ドメインレベルに影響を与えるものもあります (つまりそれゆえ、それより上のすべてのレベルにも影響を与えることになります) 。しかし拡張によっては、ただ物理的レベルに影響を与えるだけのものもあります。

エンタープライズソリューションをサポートするためのレベルの拡張

さてここまで、4つのレベルによる抽象化の簡単な例を示したところで、この手法をITエンタープライズ向けのソリューションをサポートするように拡張しましょう。表1に、ラショナル統一プロセス (RUP) で構成した適切に定義された抽象化レベルを含む組織的なプロジェクトを示します。

表内におけるレベルを次に示します。

レベル名	レベルの範囲
業務ドメイン	企業はブラックボックス化された中央アクターです。 業務の外部アクターの観点で業務をモデル化します。 業務でのやりとりだけをモデル化します。伝達手段は含めません。
プロジェクトのビジョン	プロジェクトの使命であり、業務の目的であり、プロジェクトの費用対効果です。
業務プロセス	業務ドメインレベルの業務のやりとりを具現化し、業務プロセスのワークフローをモデル化します。 システムはブラックボックス化された中央アクターです。 システムの外部アクターの観点で業務プロセスをモデル化します。 業務取引を完結させるための伝達手段を含めます。
UI仕様	システム機能におけるUI設計とUIプロトタイプです。どのようにしてシステムのユーザーが業務プロセスワークフローを実現するのかを示したものです。
詳細な要求	システムの外部インターフェイスを示すもっとも低レベルな詳細を明示したものです。たとえば、「アメリカの郵便番号はxxxxxもしくはxxxxx-xxxでなければならない」といったことです。性能、信頼性、セキュリティ、国際化、コンフィグレーション、スケーラビリティ、柔軟性といった極めて高度な要求も明示します。
アーキテクチャ	ブラックボックス化されたシステムの内部です。
	論理的なビュー	並列性のビュー	セキュリティのビュー	配置のビュー	コンポーネントのビュー	データのビュー
	論理的な設計	並列性がある設計	セキュリティの設計	ネットワークの構成	コンポーネントのインターフェイス	論理的なデータモデル
		一貫性がある実装	セキュリティの実装	構成物の構成	コンポーネントのインターフェイス実装	物理的なデータモデル
実装	データベーススキーマ、ソースコード、リファレンスデータ、構成ファイルです。

表1 RUPで構成した適切に定義された抽象化レベルを含む組織的なプロジェクト

• 業務ドメイン 業務ドメインレベルでは、プロジェクトに おける業務コンテキストをとらえます。
• プロジェクトのビジョン プロジェクトのビジョンは、業務にシステムを適用することによって、業務に対して与える影響を伝えます。費用対効果を分析することで、この影響の大きさを測ります。プロジェクトのビジョンは、プロジェクトの抽象化の最上位レベルに位置します。
• 業務プロセス システムレベルで、企業における業務プロセスをモデル化します。とても複雑な組織の場合、このレベルは「部門」や「部門間」、「部門内」といったサブレベルに分割できます。
• UI仕様 UI仕様では、業務プロセスを実現するユーザーイ ンターフェイスを設計します。 UI仕様は、UI設計ドキュメントと機能的なUIプロトタイプで構成されます。
• 詳細な要求 詳細な要求では、システムが要求するもっとも低レベルな抽象化を明示します。詳細な要求には、データタイプのフォーマットや業務ルールの詳細が含まれています。さらに、性能、信頼性、セキュリティ、国際化、コンフィグレーション、スケーラビリティ、そして、柔軟性といった、極めて高度な要求も含まれます。
• アーキテクチャ システムアーキテクチャは、次の6つの ビューで編成されます。
  • 論理的 システムの機能を実現するためのソフトウェア層 や主な抽象化概念を定義します。
  • 並列性 トランザクション、サーバー群、リソースの観点 から、システムを並列的な視点でとらえます。
  • セキュリティ 証明、認証、秘密の保護、その記録方法を 定義します。
  • 配置 ネットワークトポロジやシステム構成の配置を定義 します。
  • コンポーネント システムコンポーネント、および、その インターフェイスや依存性を定義します。
  • データ 永続的なデータの構造設計を定義します。

メリット

システムを分離した抽象化レベルで編成することには、いくつかのメリットがあります。

• システムの要求を「業務プロセス」、「UI仕様」、「詳細な要求」という、抽象化した3つの異なるレベルへと分離できます。もはや、私たちは、ただひとつの、一枚岩的な機能仕様で業務ユーザーを圧倒させてしまうことはありません。代わりに、詳細にわたって精錬された3つのレベルにあるシステム要求を扱います。
• アナリストやアーキテクトは、複雑なものをまとめて、ひとつのシステムの統合されたモデルにできます。
• アーキテクトは、システムの一部分だけに集中し、それらを統合してソリューション全体を決めていくことができます。
• 抽象化レベルは、システムを構成するものの構造を型どります。たとえば、ソフトウェアアーキテクチャのドキュメントは、それぞれ見方を違えた、小分けされた部分を示します。
• 抽象化レベルにより、要求事項から設計、そして、実装へと、直接追跡することが可能になります。要求の変更を評価するときには、これらを追跡することによって、正確にその影響を判断できます。
• 同じ枠組みを使っていくつかのシステムを開発していくと、それぞれの抽象化レベルでパターンが登場してきます。組織においては、これらのパターンや、それぞれの抽象化レベルにおけるベストプラクティスをカタログ化できます。ベストプラクティスのこのカタログは、プロセス改善を計画するうえでの拠り所として役立ちます。

まとめ

すべての技術分野では、複雑さに対処するため、抽象化レベルという形式を適用しています。ソフトウェアも例外ではありません。抽象化レベルのメリットを得るために、プロジェクトでは、次のことをしなければなりません。

• 層をよく見極めてください。それぞれの層を適切な範囲にしてくだ さい。
• ひとつのレベルにある複雑なものは、複数のビューに分割してくだ さい。
• レベル間の一貫性を維持してください。

この記事では、単純な例によって、抽象化レベルをどのように適用すればよいのかを実証しました。そして、その手法をエンタープライズITソリューションをサポートするように拡張しました。そこでは、RUPで構成した適切に定義された抽象化レベルを含む組織的なプロジェクトを示しました。

自己評価

• あなたの現在のプロジェクトでは、抽象化レベルを適用しています か？
• レベルは適切に定義していますか？
• プロジェクトチームは、そのレベルをよく理解していますか？
• ひとつのレベルで複雑なものが多いとき、チームでは、それを複数 のビューへと分割していますか？
• チームでは、レベル間の一貫性を維持していますか？
• あなたのプロジェクトは、抽象化レベルからメリットを得られるで しょうか？

偉大なるアーキテクトは、本能的に、これらの法則に従っています。取り残された私たちは、意識的に抽象化レベルを適用し、プロジェクトのライフサイクル全体にわたって、そのレベルを維持するように自制しなければなりません。

関連情報

Cockburn, Alistair. Writing Effective Use Cases. New Jerse y: Addison-Wesley, 2001

Kroll, Per and Kruchten, Philippe. The Rational Unified Proces s Made Easy: A Practitioner's Guide to the RUP. Boston MA: Pears on Education and Addison-Wesley, 2003

DeMarco, Tom and Plauger, P. J. Structured Analysis and System Specification. Prentice Hall PTR, 1979

DoD Standard 2167Aのオンラインコピーは、http://www2.umassd.edu/SWPI/DOD/MIL-STD-2167A/DOD2167A.html (英語) で参照できます。

注

1 ソフトウェアに対する抽象化レベルの適用には、多数の成功例があります。エド・ヨードンとトム・デマルコは、1979年に「構造化分析とシステム仕様」を発表しました。階層的なハードウェアやソフトウェアの細目でシステムを作り上げることを要求するアメリカ政府で標準化された「DoD Standard 2167A」には、たくさんの派生物があります。 DBAコミュニティーでは、リレーショナルデータベースをモデル化するために詳細レベルをしばしば適用します。とくにバックマンのツールセットやジェームズ・マーチンの「インフォメーション・エンジニアリング原論 (Information Engineering Methodolog y) 」では、データベースを論理的にモデル化してから物理的なモデルに変換します。 Googleで"software levels of abstraction"を検索すると、いくつかの結果が返ってきます。しかしその大部分は、学会からのものであり、形式的なコンピュータ言語に着目したもののようです。

著者紹介

Don Awaltは、カスタムソフトウェアエンジニアリングの会社として1988年に設立されたRDAコーポレーションのCEOおよび設立者です。RDAコーポレーションのオフィスは、ワシントンDC、ボルティモア、アトランタ、フィラデルフィア、シカゴにあります。 RDAコーポレーションは、Microsoft認定ゴールドパートナーであり、.NET F rameworkを使ったエンタープライズWebやリッチクライアントシステムを中心に開発しています。 Donは、Microsoftのフィラデルフィア地域のリージョナルディレクターを過去に務めており、現在は、ワシントンDCのリージョナルディレクターです。 DonはTech EdやDeveloper Days、MSDNイベント、SQL ServerやWindowsのイベントといった業界イベントの常連講師です。 DonはSQL Server MatazineとPC Tech Journal Magazinの補助編集員を務めており、他誌にも寄稿しています。 Donの専門分野は、Webサービス、SQL Server、現代のプログラミングの進化、さらには、Microsoftプレスクリプティブアーキテクチャグループ (PAG) でのプロセスワークまで、多岐にわたります。 Donへの連絡は、 AWALT@rdacorp.com(英語) まで。

Rick McUmberはRDAコーポレーションで、品質とベストプラクティスのディレクターをしています。 11年間、IBMとRational Softwareコーポレーションでそれぞれ働き、運輸省や国防総省、NASA、そして、カナダの国防総省のシステム開発を手がけました。 1994年以降は、RSAコーポレーションで働き、その顧客に向けて、ビジネスソリューションを開発しています。 Rickへの連絡は、McUmber@rdacorp. com (英語) まで。

 

 ページのトップへ