型インスタンス同音異義語

「戦争と平和」は素晴らしい本です。

「ちょっと見てみよう…この本は表紙がボロボロで残念だ」

2つの文で、どちらも「本」という単語を使っています。私たちは毎日このような組み合わせを何気なく見ていますが、「本」という言葉がそれぞれの文で全く異なる意味を持っていることに気づいていません。

最初の文では「本」は文学作品を指し、100年以上も存在しているものです。2番目の文では「本」は物理的なオブジェクトを指し、おそらくそれよりもずっと短い期間存在しています。後者は簡単に火で燃やすことができますが、前者は炎の影響を受けず、私よりも長く続くでしょう。前者は多くの兄弟と一緒にハードディスクに保存でき、その総重量は後者よりもはるかに軽くなります。

この特定の曖昧さは、自然言語では驚くほど一般的です。「車」、「オーク」、「プログラマー」などの単語を考えてみてください。これを整理しようとすると、哲学における意味論の暗い領域に簡単に迷い込む可能性があります。ここでは、私がどのように考えているかについて説明します。

「本」という単語は、複数の概念を指すことができます。上記の2つの文は、「本」が指す2つの概念、つまり文学作品と物理的なコピーを示しています。読者のほとんどはプログラマーであるため、プログラミングのアナロジーを使用して、どちらも「book」と呼ばれる2つの異なるクラスがあると説明します。これらは、LiteraryWorkクラスとPhysicalCopyクラスとして参照することで区別できます。最初の文で「戦争と平和」は本であると言っている場合、それは「戦争と平和」がLiteraryWorkクラスのインスタンスであると言っていることになります。2番目の文は、PhysicalCopyのインスタンスのプロパティを参照しています。

これらの2つの概念は独立していません。rightとright（leftとwrongの反対語）のような同音異義語とは異なり、これら2つの概念には密接な関係があります[1]。本[PhysicalCopy]には、本[LiteraryWork]の描写が載っています。そのため、「私の戦争と平和は表紙がボロボロだ」と言うかもしれません。同様に、私のスバル・レガシィ[物理的な車のインスタンス]は、スバル・レガシィ[車種のインスタンス]と関係があります。実際、私の車の型はスバル・レガシィ[車種]と言うことができます。この種の関係は非常に一般的であり、オブジェクトやデータモデリングを行う人々には馴染みがあります。製品と製品タイプを含む同様の構造をよく目にします。BookとBook Typeという用語は使いませんが、基本的に同じ関係です。

ほとんどどのようなドメインでも、モデリングやプログラミングを行うと、そのドメインの一般的な用語を取って、それが2つの別々の概念を表していることに気づく時点に達します。これは、コード内で異なる名前を持つ別々のクラス（またはテーブル）を意味します。ドメイン言語で同音異義語が発生する場合は、多くの場合、用語が異なるコンテキストで使用されているためです。エリック・エヴァンスが言う「バウンデッドコンテキスト」です。ジム・オデルが指摘したように、「メアリーは子羊を飼っていた」は、獣医と料理人では全く異なる意味を持ちます。型インスタンス同音異義語の問題は、非常に狭いバウンデッドコンテキスト内でも発生することです。

私の目的は、このような状況のモデリングについてさらに詳しく説明することではなく、この一般的なタイプの同音異義語が引き起こす曖昧さを検討することです。この曖昧さについて本当に興味深いのは、それがほとんど問題を引き起こさないことです。人間は複数の概念間を簡単に切り替え、その過程でつまずくことはめったにありません。さらに悪いことに、日常会話で積極的に異なる用語を使用しようとすると、それを続けることはほぼ不可能です。私は確かに会話と両方で試みましたが、すぐに無駄だと気づきました。規律がなかっただけでなく、何らかの奇妙な精神状態の人のように聞こえました。（型インスタンスの場合だけがこの特性を持つわけではなく、「先週塗装したドアを通る」というフレーズが示唆するように）

私の専門であるオブジェクト指向設計には、特に興味深い事例があります。私たちはしばしば「オブジェクトにメソッドを追加する」といったことについて話します。しかし、もちろん、オブジェクトにメソッドを追加するのではなく、クラスに追加します。あなたのキャリアのある時点で、会議でそれを指摘したペダンティックな人だったことがあるでしょう。それ以来、あなたは数え切れないほどの会話でその点を苦労なく曖昧にしてきました。

そこで、私たちは絶対にこの同音異義語を認識しなければならないという結論に至りました。ソフトウェアでは、概念を別々に、異なる名前で表現する必要があります。しかし、混乱の本当の危険があるコンテキストでない限り、会話の中でそれらの区別をすることは期待すべきではありません。なぜなら、ほとんどの場合、私たちの脳は自動的に曖昧さを解消するからです。

では、ユビキタス言語のコンテキストでは、これはどういう意味でしょうか？まず、モデリングを行い、異なる概念があることを認識する必要があります（同音異義語を認識する）。次に、ユビキタス言語で、そしてソフトウェア表現で使用する異なる概念の名前を考え出します。これらの名前を付ける際には、同音異義語そのものを避けるのが好きです。そのため、図書館のコンテキストでは「book」は使用せず、「Literary Work」や「Physical Copy」のようなものを使用します。これらの曖昧さを解消する用語は、ユビキタス言語の他のものと同様に、ドメインエキスパートにとって理解できるものでなければなりません。したがって、ドメインエキスパートは同音異義語を認識し、新しい用語の考案に協力する必要があります。そして、得られた精度が必要なときはいつでも、新しい用語を使用します。しかし、同音異義語を完全に取り除こうとすることに注意する必要があります。それは、新しい用語のそれぞれの同義語になります。したがって、ドメインの人が「本には著者がいる」と言う場合、「そこで文学作品のことですね？」と言うかもしれません。同音異義語の用語を使用しないことは誰にとっても不自然に感じられることを覚えておいてください。そのため、軽やかに精度を適用してください。幸いなことに、認識がここの戦いの90％を占めます。

この同音異義語のさらなる結果として、常にアンテナを張って探しておく必要があります。特に、新しいドメインでの作業の初期段階では。通常、それはそのドメインに絶対に不可欠な用語で発生します。本と図書館のように。私は非公式なクラス図を使用してユビキタス言語をモデル化するのが好きで、この種の同音異義語を排除するのに役立つことがわかりました。

2013年3月19日再投稿