The Bottom Logic of Object Oriented Analysis and Design

オブジェクト指向は、人が物事を理解するための基本的な方法です

人はどのように物事を知るのか

オブジェクト指向が登場する以前は、プロセス指向の分析方法が存在していました。では、なぜオブジェクト指向が提唱されたのでしょうか。本質的な理由は、プロセス指向のアプローチが、人が通常物事を理解するやり方でソフトウェアを分析していないことにあります。では、人はどのように物事を知るのでしょうか。Yourdon は著書『Object Oriented Analysis』で、人類は分類の原則に従って物事を理解していると述べています。主に 3 つのポイントがあります。オブジェクトとその属性を区別すること、オブジェクト全体とその構成要素を区別すること、そして異なるオブジェクトクラスの形成と識別です。

ここで、私たちが物事を理解するプロセスが、分類で述べられた 3 つのポイントと非常に似ているかどうかを思い出してみましょう。ある物事を目にしたとき、おそらくそのコンポジション、形状、分類を知覚するでしょう。したがって、人はオブジェクトの観点から物事を知り、その後、リンゴ、ナシ、自動車などの具体的な概念名をオブジェクトに割り当てます。

分類と階層化の 2 つの考え方

私たちが直面する現実の世界は非常に複雑です。複雑な物事に対処する重要な方法の一つが抽象化です。抽象化は実践的な適用プロセスにおいて 2 つの方法で具現化されます。階層化と分類です。分類は、異なる物事を異なるグループに分類することです。よく耳にする「類は友を呼ぶ」という言葉の通りです。分類には 2 つの理由があります。一つは物事間の関係性の近さであり、すべての物事を結合させる必要はないということです。もう一つは、人が物事を把握する能力に限界があり、5〜7 ポイント程度の重要なポイントしか把握できず、それ以上は忘れやすくなるということです。

階層化は、異なる視点から物事を見ることです。各階層には、それぞれの視点に起因する異なる関心事があります。たとえば、コンピュータを理解するためにバイナリ電気信号まで深く掘り下げる必要はありません。階層的特徴はソフトウェア設計でよく見られます。コンピュータアーキテクチャや TCP 7 階層プロトコルなどがその例です。階層的特徴には一つの特徴があります。上に行くほど具体的で、下に行くほど抽象的であり、上のコンテンツほど不安定、つまり変更されやすいということです。

問題領域から解決空間へのマッピング

解決すべき問題を問題領域、あるいは問題空間と呼び、解決策を解決空間と呼びます。前のセクションで述べたように、物事には階層的特徴があり、異なる人々がそれぞれの視点から物事を理解するため、各人の理解とコミュニケーションは一致しません。問題空間が表面的な場合、浅い理解に基づいて設計されたソリューションは不安定になり、わずかな変更で次回に再設計が必要になる可能性があります。

ソフトウェアをシナリオ、機能、エンティティの 3 つのレイヤーに分割できます。シナリオ層は頻繁に変化します。たとえば、クーポン発行には多くのシナリオがあります。赤パケットを拾って割引を取得する、ギフトを共有してクーポンを取得する、新規登録でクーポンを取得するなどです。このシナリオはビジネスの調整に伴い非常に速く変化するため、シナリオ層は不安定です。機能はある一連のシナリオ群を支えます。シナリオに比べて機能は比較的安定的です。前述のクーポン発行シナリオの場合、本質はユーザーにクーポンを発行することであり、クーポン発行機能を提供すればよく、どのシナリオから呼び出されるかは問題ではありません。ただし、機能はシナリオの集合に基づいて抽象化されるため、シナリオの種類が変われば機能もそれに応じて変化します。たとえば、保証取引はプレセール取引とは異なります。エンティティは安定的です。保証取引とプレセール取引を例に取ると、その注文モデルはほぼ同じで、新しい情報がいくつか追加されるだけです。

したがって、問題空間から解決空間への移行では、見て理解する内容が一貫しており、物事の本質を見ていることが重要です。外見ではなく。多くの場合、シナリオと機能は不安定であり、プロセス指向は機能駆動型であるため、変化の激しいシナリオでは多くの問題に直面します。より安定的なのは問題空間内のエンティティオブジェクトであるため、オブジェクト指向分析は実践的な必要性です。プロセス指向とオブジェクト指向は異なる視点からの 2 つの分析方法です。プロセス指向は帰納的分析方法であり、外から内へのプロセスです。オブジェクト指向は演繹的分析方法であり、内から外へのプロセスです。

3 つの一貫性

ソフトウェア開発は、分析、概要設計、詳細設計、コーディング、テスト、リリースの主要なフェーズを経ます。各部分が断片化されることは望ましくありません。たとえば、分析完了後に設計フェーズで再度分析をやり直すようなことです。ここでは一貫性の問題が関わってきます。つまり、要件と分析の間の一致、分析と設計の間の一致、設計とコーディングの間の一致です。このアプローチの利点は、情報の歪みがないことを保証できることです。したがって、これを実現する分析設計手法が切実に求められており、オブジェクト指向分析設計がそれを実現できます。そのため、プロセス全体を通じてオブジェクトを分析と設計の目標とし、最終的なコーディングでもそれらはオブジェクトのままです。

オブジェクト指向の本質的なロジック

オブジェクト指向と言えば、カプセル化、継承、多態性といった特徴を挙げる人もいます。しかし、これらはオブジェクト指向の本質的な特徴ではありません。たとえば、カプセル化はオブジェクト指向のプロセス中に存在しますが、多態性も同様にオブジェクト指向のプロセスで現れます。これらの特徴はオブジェクト指向固有のものではありません。オブジェクト指向の本質的なロジックは、現実の事物に基づく抽象マッピングです。現実の事物はソフトウェアのオブジェクトに対応します。解決空間のオブジェクトが問題空間のオブジェクトに対応でき、両者は一対一で直接マッピングされます。他の分析方法は、問題空間と解決空間の間の間接的なマッピングです。

オブジェクト指向分析設計の全体像

私たちが直面する問題は何か

最上位から見ると、要件からコーディングまでの作業を完了する必要があります。しかし、要件からコーディングまでは、要求分析や方式設計など多くの段階があります。大きなレベルでは、主に 3 つの問題に直面します。

1. 何をすべきか

これはシンプルな質問のように見えますが、複雑なビジネスシナリオでは、何をすべきかの理解が極めて重要です。異なる人々が要件に対して異なる理解を持つからです。たとえば、ある最近のプロジェクトで、「越境注文にのみ課税する」というビジネス判定ルールがありました。初期の開発者の理解は、販売者のタイプが越境販売者かどうかを判定するというものでした。しかし、テスト段階になって、このビジネスルールの判定と理解が一致していないことが判明しました。越境注文は販売者のタイプとは関係がありません。実際の越境注文の課税シナリオは、配送元 (shipFrom) と配送先 (shipTo) の国アドレスが異なることです。大規模プロジェクトでは複数チーム間の連携が伴い、この問題は極めて顕著になります。さらに、ビジネス要件から製品要件、技術ソリューションへと 2 回の変換が行われており、各変換には異なる役割が関わり、各人の理解が異なります。

2. どうやるか

具体的なやり方になると、人々は通常大きな問題を抱えません。どうやるかは実装段階ではより具体的です。プログラマーは通常、論理的厳密性に大きな問題はありません。問題は通常、最初の「何をすべきか」の問題であり、これは方向性が間違っていることに等しく、行った作業が無駄になります。

3. 方法論のガイダンスの問題

すべての問題を労せず処理できる万能な方法を求める一方で、ローレベルな方法を軽視する傾向があります。たとえば、ほとんどの人はユースケース分析手法を軽蔑し、高い技術レベルの手法で反映したいと考えます。実際には、1970〜80 年代からソフトウェア分析設計手法はあまり変わっておらず、大学で学んだ内容ですが、崇高な方法とは見なされていません。

分析から設計へのプロセス

このセクションでは、ソフトウェア分析から設計へのプロセスを粗い粒度から細かい粒度へと推論し、最終的に私たちが触れてきた UML の知識を実装します。要件からコーディング実装までには 2 つの重要な問題があります。一つは目標の定義、つまり何をすべきかを明確に定義することで、これは作業の方向性と目標に相当します。もう一つは、どうやるか、つまり具体的なプログラムで需要目標の実現をどう支えるかです。したがって、目標の定義と具体的な方案の表現を支援し、かつ相互認識のための汎用的な方法が必要です。

ユースケース図は目標の定義に役立ちます。ユースケースには 3 つの重要な要素があります。ユーザー、シナリオ、目標です。たとえば、取引注文は一つのユースケースです。ユーザーは購入者で、シナリオには成功と不成功の 2 つのシナリオがあり、ユースケースの目標は購入者が望む商品を購入できることです。ユースケースの目標が決まれば、目標を定義し、何をすべきかを知ることになります。このプロセスはビジネス側と繰り返し確認し、全員が目標に対して同じ理解を持つまで行う必要があります。方向が正しければ、具体的なやり方は簡単です。

具体的な方法を表現するにはどうすればよいでしょうか。シーケンス図を描く際に注意すべき点は、トップレベルのオブジェクト階層を一貫させることです。一部のオブジェクトは具体的なエンティティオブジェクトを表すことができず、一部のオブジェクトはシステムオブジェクトを表します。つまり、オブジェクトの階層を一致させる必要があります。全員がシステムである場合（ショッピングガイドシステムが取引システムを呼び出し、取引システムが決済システムを呼び出す）、または全員がオブジェクトである場合（商品、注文など）のいずれかです。シーケンス図を通じて、完全な機能の実行ステップを見ることができ、正常フローと異常フローを含む具体的な実行の詳細が含まれます。

実際、上記には一つの問題があります。シーケンス図を描く際に、オブジェクトを決定する必要があります。オブジェクトはどこから来たのでしょうか。ロバストネス図によって分析されます。その中には 3 つの重要なオブジェクトがあります。一つは境界オブジェクトで、理解しやすいものです。たとえば、UI インターフェイスが境界オブジェクトです。もう一つは制御オブジェクト、つまりビジネスフローを制御するオブジェクトです。以下の単一サービスは制御オブジェクトと見なせます。最後にエンティティオブジェクトで、問題空間内のビジネスオブジェクトであり、たとえば注文などです。ロバストネス図の描画にはルールがあります。一般的に、境界オブジェクトが制御オブジェクトを呼び出し、制御オブジェクトがエンティティオブジェクトを生成します。たとえば、ユーザー注文インターフェイスは境界オブジェクト、注文サービスは制御オブジェクト、注文はエンティティオブジェクトです。

オブジェクトの発見方法

オブジェクトはどこから来るのか

本記事の第一部第三セクションで述べたように、問題空間は解決空間に一対一でマッピングされます。解決空間のオブジェクトについて議論するとき、それらは実際には問題空間のオブジェクトにマッピングされています。一方、問題空間のオブジェクトは主にビジネス概念、ビジネスルール、重要なイベントから来ます。オブジェクトの多くは目に見えるものですが、ビジネスを理解することで隠れたオブジェクトを発見できることもあります。引き続きビジネスへの深い理解が必要です。優れたオブジェクトモデルは何度も練り直す必要があり、一度で完璧には仕上がりません。

オブジェクトを発見する方法

オブジェクトを見つける方法は本記事の第二部第二セクションで述べられていますが、それは重要なオブジェクトのみでした。このセクションでは、完全なオブジェクト発見の方法について主に説明します。主な方法は 4 つのステップに分けられます。

1. ロバストネス図を使って重要なエンティティオブジェクトを見つける。

2. 構造分析を通じてより堅牢なオブジェクトを見つける。

3. オブジェクトを有機的なオブジェクトモデルとして構成する。

4. 最後に、ユースケースを通じてオブジェクトモデルが完全かどうかを検証する。

ここでは、オブジェクト発見のプロセスを具体例で説明します。ケースは、ユーザーが注文時に注文上に税額を表示するというものです。まずロバストネス図を描きます。ここでの境界オブジェクトは注文インターフェイスです。制御オブジェクトは 2 つあり、一つは注文サービス、もう一つは課税サービスです。エンティティオブジェクトも 2 つあり、一つは課税伝票、もう一つは注文です。課税伝票と注文の 2 つのエンティティオブジェクトがあれば、構造分析法を通じてさらに多くのオブジェクトを分析できます。

オブジェクトには構造があります。オブジェクトの構造を把握すれば、基本的にオブジェクトの全体像を把握できます。したがって、オブジェクトの構造から出発して、オブジェクトの内部構造とオブジェクト間の関連構造を分析します。本質的には 2 つの次元から始めます。一つは自分自身の視点から、内部に含まれるオブジェクトを見ることです。たとえば、メイン注文がサブ注文を含むなどです。もう一つは外部の視点から、自分と関連するオブジェクトを見ることです。たとえば、課税伝票と注文などです。このオブジェクト発見の方法は構造分析法と呼ばれます。構造自体が物事の本質の表現だからです。たとえば、化学分子構造が化学現象を決定するように。

オブジェクトの構造をよりよく表現するために、私の経験では、異なる次元からオブジェクトを定義することです。たとえば、機能次元、価値次元、目的次元、構造次元などです。ここでは、構造次元からオブジェクトを定義できます。課税計算書を例に取ると、次のように定義できます。課税計算書は、注文の金額情報を複数の対象オブジェクトに変換して課税計算を行うドキュメントモデルである。この定義から、課税計算書が注文と関連していること、および課税計算書が複数の対象オブジェクトを含んでいることが分かります。課税計算書のオブジェクトモデルを描くことができます。

オブジェクトモデルを描いた後、今後はこのオブジェクトモデルを中心にビジネス上の問題を議論します。たとえば、商品のどの金額項目を課税対象とすべきか、課税額の計算基準は何かといった点です。ここで、「問題空間が解決空間に一対一で直接マッピングされる」という言葉を実感します。ビジネス要件は所詮、どの注文費用項目に課税すべきか、課税計算のロジックはどうか、このシナリオではゴールド基準割引を差し引く可能性がある、別のシナリオでは差し引く必要がない、といったことに尽きます。オブジェクトモデルに基づいて、製品チームやテストチームのメンバーと問題を議論します。全員が同じ視点から問題を見るため、コミュニケーションと理解のコストは大幅に削減されます。

オブジェクトモデルは視覚的な表現形式です。コミュニケーション上の問題の多くは、明示的な表現が不足していることに起因します。ある言葉はこのようにも解釈でき、そのようにも解釈できるため、誤解が生じます。モデルという形式で問題を議論することで、多くの逸脱や曖昧さが解消されます。

オブジェクト構造の組織化

多くのオブジェクトを分析した後、一定の組織化を行う必要があります。前述の通り、人の物事に対する理解力には限界があり、一度に多くのことを受け入れることはできません。したがって、小さなドメインに分割できます。たとえば、商品ドメイン、注文ドメイン、課税ドメインなどです。問題を集約する際は、特定のサブドメイン内のオブジェクトモデルだけを見ればよいのです。

責務の割り当て方法

責務はどう生まれたのか

オブジェクト指向で最も難しい点は 2 つあります。一つはオブジェクトの発見、もう一つは責務の割り当てです。UML では責務を「クラス要素の契約または義務」と定義しています。したがって、責務の分割は本質的にクラス要素自身によって決定されます。たとえば、注文は注文レンダリング、注文作成、注文修正、注文照会の義務を提供します。

責務は 2 つのカテゴリに分けられます。認知責任ともう一つは動作責任です。

・認知責任には以下が含まれます。
・プライベートデータのカプセル化に関する知識。
・関連オブジェクトの認知。
・派生または計算可能な事柄の知識。

・動作責任には以下が含まれます。
・オブジェクトの作成や計算を含む自己実行の動作。
・他のオブジェクトを初期化する動作。
・他のオブジェクトの制御や調整活動。

責務を割り当てるロジック

前のセクションで述べた 2 種類の責務について、認知責任はオブジェクト自身の属性に基づく認知範囲を指します。つまり、自身の属性に基づいてのみ対応する責務を完了できます。たとえば、1 親複数子の注文で合計注文金額を計算する場合、どのように責務を割り当てるでしょうか。まず、商品は自身の価格情報のみを見つけることができます。その理解は商品価格属性に基づいています。サブ注文は複数の商品を持てるため、サブ注文の金額情報のみを計算できます。その理解は商品項目と数量属性に基づいています。メイン注文はすべてのサブ注文の情報を含んでいるため、注文全体の合計金額を計算できます。

上記の例から分かるように、認知責任はオブジェクトの属性に基づいています。「その位に在らざれば、その政を謀らず」という言葉の通り、認知責任は自身の認知範囲を超えてはなりません。

動作責任はドメイン固有のサービスです。時に、ある責務は特定のオブジェクトに属さない場合があります。たとえば転送は一つの行為であり、他の責務に引き受けるのは不適切です。このような動作責任は多くの場合、重要なビジネス活動です。たとえば注文レンダリングや注文作成は、認知責任ではなく動作責任です。

責務の割り当ては必ず「情報エキスパート」モデルに従う必要があります。これは、責務の完了に必要な情報を持つ者に責務を割り当てる、つまり前述の知識から責務を生み出すということです。

責務割り当ての妥当性を検証する

割り当てられた責務が「高凝集・低結合」の要件を満たすことを期待します。どう検証するでしょうか。責務の定義に戻って考えましょう。クラス要素の契約または義務です。つまり、責務は他のオブジェクトから呼び出されるものであり、これはシーケンス図を描く目的と一致しています。すべての呼び出しは、他のオブジェクトがある責務を提供する必要があることを意味します。したがって、シーケンス図でのオブジェクト間の呼び出し頻度を確認できます。あるオブジェクトが非常に頻繁に呼び出されている場合、そのオブジェクトが過度の責務を抱えている可能性があります。分割して一部の責務を再割り当てできないか検討しましょう。したがって、オブジェクトの責務割り当ては一朝一夕で完成するものではなく、継続的なレビューと検証が必要です。

責務の割り当ては、クリエータパターン、情報エキスパートモデル、純粋仮想モデルなど、一定の原則に従う必要があります。これらの原則については次の記事で個別に議論します。

ケース

ケースの背景

ここでは、プロセス指向とオブジェクト指向の分析およびコード作成の違いを具体例で説明します。税金を計算するには、課税ルールを満たすかどうかを判定する必要があります。たとえば、仮想商品は非課税（携帯電話のチャージなど）、非課税アドレスは非課税、小規模 B バイヤーは非課税などです。したがって、課税フィルタリングの判定ロジックを提供する必要があります。

一般的なプロセス指向の実装

プロセス指向の考え方は非常にシンプルです。フィルタリングメソッドを提供し、以下のロジックを順番に処理します。仮想商品の課税リクエストのフィルタリング、非課税アドレスの課税リクエストのフィルタリング、小規模 B バイヤーの課税リクエストのフィルタリング。

オブジェクト指向の実装

プロセス指向はプロセスや機能の観点から問題を分析しますが、オブジェクト指向はオブジェクトの観点から問題を分析します。課税リクエストのフィルタリングは、課税リクエストが課税ルールに適合するかどうかを判定する課税フィルタです。オブジェクトは 2 つあります。課税フィルタと課税ルールです。課税要件を満たすかどうかの判定責任は、具体的な課税ルールプロセッサにあるべきです。たとえば、小規模 B バイヤーかどうかの判定などです。これにより、オブジェクトモデルを描くことができます。

まとめ

記事では、オブジェクト指向の本質的なロジックは現実の事物に基づく抽象マッピングであると述べられています。重要なのは特定のオブジェクト指向技術の使用ではなく、問題を分析する考え方です。これが最も難しい点です。最大のメリットは、問題空間から解決空間への一対一の直接マッピングが継続的に行われることです。間接マッピングの場合、シナリオや機能に基づく帰納的設計、すなわち表面的な設計であるため、設計方案が後で再設計に直面する可能性があります。オブジェクト指向分析設計の方法を真に習得し、そのメリットを実感すれば、ビジネス理解、方式設計、コーディング開発のすべてに有益です。