ドメインモデル表現-正式なオントロジーとコード
免責事項：私はドメインモデルの構築に限られた経験しかありません。これは、純粋にそうする人に興味があるために求められます
最近、データモデルを ontologies で表すという概念に遭遇しました。組織のソフトウェアシステムで使用されるドメインモデルを指定するための優れた方法のようです。
私の質問は：
オントロジーのような形式でドメインモデルを正式に指定する価値があるのはいつですか？例えば。生物医学的カタログ作成ソフトウェアなどの「複雑な知識システム」がそれらを使用することを読みましたが、それらは典型的なビジネスアプリケーションには余計な作業になるでしょうか？
ソフトウェアとは別のドメインモデルの表現を持たない方が一般に良い方法ですか？つまりソフトウェアをドメインモデルの単一の情報源とする
一般に、ソフトウェアエンジニアリングのドメインモデルはUMLで表され、ほとんどのUMLクラス図の構成はオントロジーに変換できます。私はこれについて書きました ここ 。
ソフトウェア工学のためのオントロジーの利点
UMLクラス図をオントロジーに変換することの利点は、オントロジーは人工知能推論手順に裏付けられているため、UMLクラス図に論理的な不整合があるかどうかを判断できることです。論理的な不整合は通常、単体テストの焦点である単一のクラスではなく、クラス間の関係から発生するため、このような論理的な不整合は通常のユニットテスト（クラス図がコードに実装された後）で見つけるのは困難です。さらに、オントロジーは、不整合を強調するだけでなく、不整合が発生した理由を提供することもできます。これは、不整合を解消するのに役立ちます。
オントロジーがソフトウェアエンジニアリングで広く使用されていない理由
オントロジーが非常に役立つ場合、なぜソフトウェアエンジニアリングで広く使用されないのですか？ （私の意見では）3つの主な理由があると思います：
（1）私の経験では、オントロジーに気づいている人はほとんどいないようです。そのため、そもそもそのオプションはレーダーにありません。
（2）多くの企業は、要求エンジニアリングを完全に中止するか、市場投入のプレッシャーが原因で、要求エンジニアリングの縮小バージョンを実行しています。したがって、多くの場合、要件を「指定」するのは開発者次第であり、UMLクラス図をコーディングするか描画するかの選択が残された場合、多くの開発者はすぐにコードを書くことを好みます。
（3）ツールのサポートに問題があります。オントロジーを作成し、それらを推論するためのツールは多数ありますが、UMLとオントロジー間を変換するためのツールはありません。ツールがなくても、手作業で翻訳を行うことができます。オントロジーの根底にある数学的論理について知識を深める必要がありますが、それは簡単なことではありませんが、UMLとオントロジーの間の変換は十分に理解されており、変換を行うための「パターン」の種類があります。したがって、翻訳のためのツールがないことは困難を伴いますが、それは障害ではありません。ただし、速度が遅くなります。
ソフトウェアエンジニアリングにオントロジーを使用する場合
オントロジーの限られたスキルと限られたツールのサポートを考慮すると、ビジネスロジックが複雑である場合や、ビジネスロジックを間違った場合の影響がビジネスに深刻な悪影響を与える場合に使用するのが理にかなっています。例として、私はビジネスアナリストが2000を超える順列を持つ企業の原価モデルのドメインモデルを設計するのを支援しました。この順列の数は、利害関係者が問題について考えることを非常に困難にしました。
問題の一部は、利害関係者の多くが、多くの概念が重複しているあいまいな概念を頭に持っていることです。ビジネスアナリストの仕事はこれらの概念のもつれを解くことですが、経験豊富なビジネスアナリストであっても、ドメインモデルのどの概念が問題であり、その理由を正確に説明するのは難しい場合があります。オントロジーの推論および説明サービスは、この点に関して有益な洞察を与えることができます。
原価計算モデルのオントロジーを設計する際に、矛盾は関係者が彼らの概念が曖昧であることを理解するのに役立ち、説明はビジネスアナリストが概念がなぜ曖昧であるかを理解し、代替案を提案するのに役立ちました。
コードの外部にドメインモデルを持つことを検討する必要がある理由
ドメインモデルがコードでのみ見つかる場合、ソフトウェア開発者のみがアクセスできます。ビジネスアナリスト、テスター、プロジェクトマネージャー、ユーザー、ビジネス関係者、スポンサーはアクセスできません。コードの外部にドメインモデルを持つことの最大の利点は、ソフトウェア開発者だけでなく、すべての利害関係者がシステムを共有して理解できるようになることです。このような共有ドメインモデルは、「開発者の用語」と「ビジネスの用語」の間で翻訳する必要があるため、コミュニケーションの誤りが原因で無駄になる時間が少なくなる共有の理解を促進します。
UPDATE 20180513-モデリングに関するコメント
Stackoverflowに関するこの質問では、受け入れられた回答は... OWLの目的はモデリングではない...それは他のソフトウェアエンジニアリングプロセスとは異なるはずです...オントロジーは「データモデリング」よりも「知識表現」に優れていると主張しています。ここの主な違いは何ですか？
OWLの目的は、概念と、概念間に存在する関係を説明することです。そのため、OWLは概念モデリング言語と見なすことができます。概念モデリングとは何ですか？私の論文では、次のように定義しています。
概念モデリングは、関係者間の理解とコミュニケーションを促進するためにドメインを文書化する行為です。概念モデリングアクティビティから生じるアーティファクトは、概念スキーマと呼ばれます。概念スキーマは、ドメインの概念的に関連する側面を特定の観点から抽象化したものです。実装固有の詳細は、概念スキーマから除外されています。特定のドメインは、いくつかの異なる概念スキーマによって記述される場合があります。
UMLは、オブジェクト指向ソフトウェアシステムの分析、設計、および実装で使用するために設計された汎用モデリング言語です。オブジェクト指向分析の焦点は、問題領域の一部を形成するクラスとオブジェクトを引き出して記述することであり、オブジェクト指向設計の焦点はソフトウェアの設計にあるという点で、オブジェクト指向分析はオブジェクト指向設計とは異なります。要件を満たすオブジェクトと関連するコラボレーションで構成されるソリューション。したがって、オブジェクト指向分析は概念モデリングに強く関連し、オブジェクト指向設計は概念スキーマをコードで実現する実装の詳細に強く関連しています。
主な違い
OWLは、ソフトウェアシステム（オブジェクト指向分析）の概念モデル/ドメインモデルを定義するために使用できます。ただし、OWLは、ソフトウェアシステム（オブジェクト指向設計）の実装の詳細を定義するには不適切な選択です。どうして？ソフトウェアシステムの実装は、パフォーマンス、スケーラビリティ、統合性、セキュリティなどのさまざまなアーキテクチャ品質属性を満たしながら、概念モデルを実現することを目的としています。これらの実装の詳細は、OWLの範囲外です。これは、概念モデル/ドメインモデルがコードベースの外部で利用可能である必要があると私が考える理由の一部です。さまざまな品質属性を満たすことを目的として、ドメインモデルは多くの場合、コードベースでは隠されています。
前の回答で述べた優れた点を繰り返すつもりはありませんが、ソフトウェアエンジニアリング（SE）とオントロジーエンジニアリング（OE）の分離を埋める根本的な課題は、前者が一般的に closed世界の仮定 、そして後者は オープンワールドの仮定 を作成します。
これについて考える1つの方法は、OE/OWLなどは主に世界の構造を表すことに焦点を当てているのに対し、SE/UMLなどはデータとコードの構造に関するものです。
実用的な例として、オントロジーはすべての人間がちょうど2つの生物学的親;を持っていると言うかもしれません。これをクローズドワールドカーディナリティ制約として適用するデータモデルは、データベースに親、祖先などを再帰的に入力する必要があるため、実用的ではありません（これを空のままにすると、CWAの制約違反になるため）。
これは、多くの文学、ワークショップなど、非常に微妙な部分のほんの一面です。また、 W3C Ontology Driven Architecturesドキュメント もご覧ください。簡単な概要として、 これらのスライド が役立つと思います。