ドメイン・エンジニアリング

ドメイン・エンジニアリングとは、新しいソフトウェア・システムの構築においてドメイン知識を再利用するプロセス全体のことである。体系的なコードの再利用とプロダクトライン・エンジニアリングにおける重要な概念である。体系的なソフトウェア再利用における重要な考え方は、ドメインである。ほとんどの組織は、数個のドメインでしか仕事をしない。彼らは、与えられたドメイン内で、さまざまな顧客のニーズを満たすために、バリエーションを持たせた同様のシステムを繰り返し構築する。新しいシステムの各バリエーションをゼロから構築するのではなく、ドメイン内の過去のシステムの一部を再利用して新しいシステムを構築することで、大幅なコスト削減を実現する可能性がある。

ドメインを特定し、その境界を設定し、ドメイン内のシステム間の共通性と可変性を発見するプロセスは、ドメイン分析と呼ばれる。この情報は、再利用可能なコンポーネント、ドメイン固有言語、またはドメイン内の新しいシステムを構築するために使用できるアプリケーションジェネレータなどの成果物を作成するためのドメイン実装フェーズで使用されるモデルに取り込まれる。

ISO26550:2015で定義されているプロダクトライン・エンジニアリングでは、ドメイン・エンジニアリングは、プロダクトラインから派生する個々の製品のライフサイクルを担当するアプリケーション・エンジニアリングによって補完される[1]。

目的

ドメイン・エンジニアリングは、ソフトウェア成果物の再利用を通じて、開発されたソフトウェア製品の品質を向上させることを目的としている[2]。ドメイン・エンジニアリングは、開発されたソフトウェアシステムのほとんどが新しいシステムではなく、同じ分野の他のシステムの亜種であることを示している[3]。その結果、ドメインエンジニアリングを利用することで、先行するソフトウェアシステムのコンセプトや実装を利用し、ターゲットシステムに適用することで、企業は利益を最大化し、市場投入までの時間を短縮することができる[2][4]。コストの削減は、実装段階においても明らかである。ある研究によると、ドメイン固有言語を使用することで、メソッド数とシンボル数の両方でコードサイズを50％以上削減でき、総コード行数を75％近く削減できたという[5]。

ドメイン・エンジニアリングは、プロセスで収集された知識を取り込むことに焦点を当てている。再利用可能な成果物を開発することで、コンポーネントを低コストかつ高品質で新しいソフトウェアシステムに再利用することができる[6]。これは、ソフトウェア開発サイクルのフェーズすべてに適用されるため、ドメイン・エンジニアリングは、アプリケーション・エンジニアリングと同様に、分析、設計、実装の3つの主要フェーズにも重点を置いている[7]。これにより、ドメインに関連するソフトウェア実装コンポーネントのセットだけでなく、再利用可能で設定可能な要件と設計も生成される[8]。

ウェブ上のデータの増大とモノのインターネットの成長を考えると、ドメイン・エンジニアリングのアプローチは他の分野にも関連してきている[9]。ウェブサービスのディープチェーンの出現は、サービスの概念が相対的なものであることを浮き彫りにしている。ある組織が開発・運営するウェブサービスを、別の組織がプラットフォームの一部として利用することができる。サービスは異なるコンテキストで使用されることがあり、したがって異なるコンフィギュレーションを必要とするため、サービスファミリーの設計はドメインエンジニアリングアプローチの恩恵を受ける可能性がある。

フェイズ

アプリケーション・エンジニアリングと比較した場合のドメイン・エンジニアリング。ドメインエンジニアリングの各フェーズのアウトプットは、ドメインエンジニアリングの後続フェーズとアプリケーションエンジニアリングの対応するフェーズの両方にフィードバックされる。

ドメイン・エンジニアリングは、アプリケーション・エンジニアリングと同様に、分析、設計、実装の3つの主要なフェーズから構成される。しかし、ソフトウェアエンジニアリングが単一のシステムに焦点を当てるのに対し、ドメインエンジニアリングはシステムのファミリーに焦点を当てる[7]。優れたドメインモデルは、プロセスの後半で曖昧さを解決するための参照、ドメインの特性と定義に関する知識のリポジトリ、ドメインの一部である製品の開発者に対する仕様の役割を果たす[10]。

ドメイン分析

ドメイン分析は、ドメインを定義し、ドメインに関する情報を収集し、ドメインモデルを作成するために使用される[11]。特徴モデル（当初は特徴指向ドメイン分析手法の一部として考案された）を使用することで、ドメイン分析はドメイン内の共通点とドメイン内の変化点を特定することを目的としている[12]。ドメイン分析を使用することで、従来のアプリケーション・エンジニアリングアプローチで作成される静的な構成ではなく、構成可能な要件とアーキテクチャの開発が可能になる[13]。

ドメイン分析は、要求工学とは大きく異なるため、従来の要件導出のアプローチは、ドメインモデルに存在するような構成可能な要件の開発には効果がない。ドメイン・エンジニアリングを効果的に適用するには、ソフトウェア開発ライフサイクルの初期段階で再利用を考慮する必要がある。開発された機能モデルから機能を選択することにより、技術の再利用の考慮が非常に早い段階で行われ、開発プロセス全体を通して適切に適用することができる[14]。

ドメイン分析は、主にそのドメインにおける過去の経験から生み出された成果物から導かれる[11]。既存のシステム、その成果物（設計文書、要求文書、ユーザーマニュアルなど）、標準、顧客はすべて、ドメイン分析のインプットの潜在的な情報源である[11][15]。しかし、要求工学とは異なり、ドメイン分析は情報の収集と形式化だけで構成されるものではなく、創造的な要素も存在する。ドメイン分析プロセスでは、エンジニアは、ドメインに関する知識をすでに知られているもの以上に拡張し、ドメインを類似点と相違点に分類して再構成可能性を高めることを目指す[11]。

ドメイン分析では、主にドメインモデルを作成し、ドメイン内のシステムに共通する特性とさまざまな特性を表現する[11]。ドメインモデルは、コンポーネントを設計するための基礎として機能することで、構成可能な方法でアーキテクチャとコンポーネントを作成することを支援する[16]。効果的なドメインモデルは、ドメイン内の多様で一貫した特徴を含むだけでなく、ドメイン内で使用される語彙を定義し、システム内の概念、アイデア、現象を定義する[11][17]。フィーチャーモデルは、概念を必要なフィーチャーとオプションのフィーチャーに分解し、完全に形式化された設定可能な要求のセットを作成する[18]。

ドメイン設計

ドメイン設計は、ドメイン分析フェーズで作成されたドメインモデルを使用し、ドメイン内のすべてのシステムが適合できる汎用アーキテクチャを作成することを目的とする[19]。アプリケーションエンジニアリングが機能要件と非機能要件を使用して設計を作成するのと同じように、ドメインエンジニアリングのドメイン設計フェーズでは、ドメイン分析フェーズで作成された設定可能な要件を使用して、システムファミリーのための設定可能で標準化されたソリューションを作成する。ドメイン設計の目的は、要件構成が異なるにもかかわらず、ドメイン内のシステムに共通する問題を解決するアーキテクチャパターンを作成することである[20]。ドメイン設計におけるパターンの開発に加えて、エンジニアはパターンの範囲と、コンテキストがパターンに関連するレベルを特定することにも注意しなければならない。コンテキストの制限は非常に重要である。コンテキストの量が多すぎると、そのパターンは多くのシステムに適用できず、コンテキストの量が少なすぎると、パターンが十分に強力でないために有用でなくなる[21]。有用なパターンは、頻繁に繰り返され、かつ高品質でなければならない[22]。

ドメイン設計の目的は、開発された機能モデルによって提供される柔軟性を保持しながら、可能な限り多くのドメイン要件を満たすことである。アーキテクチャは、ドメイン内のすべてのシステムを満足させるのに十分な柔軟性を持ちながら、ソリューションのベースとなる強固なフレームワークを提供するのに十分な剛性を持つべきである[23]。

ドメイン実装

ドメイン実装とは、ドメイン内でカスタマイズされたプログラムを効率的に生成するためのプロセスとツールの作成である。

批判

ドメイン・エンジニアリングは、個人の世界観や言語、文脈をソフトウェアの設計に統合するような「使用のためのエンジニアリング」に集中するのではなく、汎用的なソフトウェア機能の「再使用のためのエンジニアリング」や「再使用を伴うエンジニアリング」に集中しすぎていると批判されてきた[24]。

関連項目

脚注

  1. ^ ISO 26550:2015 – Software and systems engineering — Reference model for product line engineering and management
  2. ^ a b Frakes & Kang 2007, p. 2
  3. ^ Frakes & Kang 2007, p. 2
  4. ^ Frakes & Kang 2007, p. 2
  5. ^ Frakes & Kang 2007, p. 2
  6. ^ Czarnecki & Eisenecker 2000, p. 20
  7. ^ a b Czarnecki & Eisenecker 2000, p. 21
  8. ^ Harsu 2002, p. 8
  9. ^ Reinhartz-Berger et al. 2013, p. xii
  10. ^ Falbo, Guizzardi & Duarte 2002, p. 2
  11. ^ a b c d e f Czarnecki & Eisenecker 2000, p. 23
  12. ^ Czarnecki & Eisenecker 2000, p. 38
  13. ^ Kang et al. 2004, p. 7
  14. ^ Kang et al. 2004, p. 3
  15. ^ Kang et al. 2004, p. 4
  16. ^ Frakes & Kang 2007, p. 3
  17. ^ Czarnecki & Eisenecker 2000, p. 84
  18. ^ Czarnecki & Eisenecker 2000, p. 86
  19. ^ Czarnecki & Eisenecker 2000, p. 24
  20. ^ Czarnecki & Eisenecker 2000, p. 25
  21. ^ Buschmann, Henney & Schmidt 2007, p. 42
  22. ^ Buschmann, Henney & Schmidt 2007, p. 31
  23. ^ Czarnecki & Eisenecker 2000, p. 28
  24. ^ Mettler 2017, p. 5

参考文献

 

Strategi Solo vs Squad di Free Fire: Cara Menang Mudah!