Loading article…
ドメイン エンジニアリングは、新しいソフトウェアシステムの作成においてドメイン知識を再利用するプロセス全体です。これは、体系的なソフトウェア再利用と製品ライン エンジニアリングの重要な概念です。体系的なソフトウェア再利用の重要なアイデアはドメインです。ほとんどの組織は、いくつかのドメインでのみ作業しています。さまざまな顧客のニーズを満たすために、特定のドメイン内でバリエーションのある同様のシステムを繰り返し構築します。新しいシステムのバリアントをそれぞれゼロから構築するのではなく、ドメイン内の以前のシステムの一部を再利用して新しいシステムを構築することで、大幅な節約を実現できます。
ドメインを識別し、境界を定め、ドメイン内のシステム間の共通点と可変性を発見するプロセスを、ドメイン分析と呼びます。この情報は、ドメイン実装フェーズで使用されるモデルに取り込まれ、再利用可能なコンポーネント、ドメイン固有言語、またはドメイン内で新しいシステムを構築するために使用できるアプリケーション ジェネレーターなどの成果物を作成します。
ISO26550:2015で定義されている製品ラインエンジニアリングでは、ドメインエンジニアリングは、製品ラインから派生した個々の製品のライフサイクルを管理するアプリケーションエンジニアリングによって補完されます。 [1]
目的
ドメインエンジニアリングは、ソフトウェア成果物の再利用を通じて開発されたソフトウェア製品の品質を向上させるように設計されています。[2]ドメインエンジニアリングは、開発されたソフトウェアシステムのほとんどが新しいシステムではなく、同じ分野の他のシステムのバリエーションであることを示しています。[3]結果として、ドメインエンジニアリングの使用により、企業は以前のソフトウェアシステムの概念と実装を使用してターゲットシステムに適用することで、利益を最大化し、市場投入までの時間を短縮できます。[2] [4]コストの削減は実装フェーズでも明らかです。 ある調査では、ドメイン固有言語の使用により、メソッド数とシンボル数の両方でコードサイズが50％以上削減され、コードの総行数が約75％削減されることが示されました。[5]
ドメインエンジニアリングは、ソフトウェアエンジニアリングのプロセス中に収集された知識の獲得に重点を置いています。再利用可能な成果物を開発することで、コンポーネントを低コストかつ高品質で新しいソフトウェアシステムに再利用できます。[6]これはソフトウェア開発サイクルのすべてのフェーズに当てはまるため、ドメインエンジニアリングは、アプリケーションエンジニアリングと並行して、分析、設計、実装という3つの主要なフェーズにも重点を置いています。[7]これにより、ドメインに関連するソフトウェア実装コンポーネントのセットだけでなく、再利用可能で構成可能な要件と設計も生成されます。[8]
Web上のデータの増加とモノのインターネットの成長を考えると、ドメインエンジニアリングのアプローチは他の分野にも関連しつつあります。[9] Webサービスの深いチェーンの出現は、サービスの概念が相対的であることを浮き彫りにしています。ある組織によって開発および運用されるWebサービスは、別の組織のプラットフォームの一部として利用できます。サービスは異なるコンテキストで使用される可能性があり、したがって異なる構成が必要になるため、サービスファミリの設計はドメインエンジニアリングのアプローチから恩恵を受ける可能性があります。
フェーズ
ドメインエンジニアリングは、アプリケーションエンジニアリングと同様に、分析、設計、実装という3つの主要なフェーズで構成されています。ただし、ソフトウェアエンジニアリングが単一のシステムに焦点を当てているのに対し、ドメインエンジニアリングはシステムファミリーに焦点を当てています。[7]優れたドメインモデルは、プロセスの後半で曖昧さを解決するための参照、ドメインの特性と定義に関する知識のリポジトリ、およびドメインの一部である製品の開発者への仕様として機能します。[10]
ドメイン分析
ドメイン分析は、ドメインを定義し、ドメインに関する情報を収集し、ドメインモデルを作成するために使用されます。[11]フィーチャモデル（当初はフィーチャ指向のドメイン分析方法の一部として考えられた）の使用により、ドメイン分析はドメイン内の共通点とドメイン内の変動点を特定することを目的としています。[12]ドメイン分析を使用することで、従来のアプリケーションエンジニアリングアプローチによって生成される静的な構成ではなく、構成可能な要件とアーキテクチャの開発が可能になります。[13]
ドメイン分析は要件エンジニアリングとは大きく異なるため、従来の要件導出アプローチはドメインモデルに存在するような構成可能な要件の開発には効果がありません。ドメインエンジニアリングを効果的に適用するには、ソフトウェア開発ライフサイクルの早い段階で再利用を考慮する必要があります。開発された機能モデルから機能を選択することで、技術の再利用の検討を非常に早い段階で実行し、開発プロセス全体にわたって適切に適用することができます。[14]
ドメイン分析は、主にそのドメインにおける過去の経験から生み出された成果物から派生します。[11]既存のシステム、その成果物（設計文書、要件文書、ユーザーマニュアルなど）、標準、顧客はすべて、ドメイン分析の入力の潜在的なソースです。[11] [15]ただし、要件エンジニアリングとは異なり、ドメイン分析は情報の収集と形式化だけで構成されるわけではなく、創造的な要素も存在します。ドメイン分析プロセスでは、エンジニアは既知の知識を超えてドメインの知識を拡張し、ドメインを類似点と相違点に分類して再構成可能性を高めることを目指します。[11]
ドメイン分析では、主にドメイン内のシステムの共通および変化する特性を表すドメインモデルが生成されます。 [11]ドメインモデルは、これらのコンポーネントを設計するための基盤として機能することで、構成可能な方法でアーキテクチャとコンポーネントの作成を支援します。[16]効果的なドメインモデルには、ドメイン内の変化し一貫性のある機能だけでなく、ドメインで使用される語彙を定義し、システム内の概念、アイデア、現象も定義されます。[11] [17]機能モデルは、概念を必須機能とオプション機能に分解して、完全に形式化された構成可能な要件のセットを生成します。[18]
ドメイン設計
ドメイン設計は、ドメイン分析フェーズで作成されたドメイン モデルを使用して、ドメイン内のすべてのシステムが準拠できる汎用アーキテクチャを作成することを目指します。[19]アプリケーション エンジニアリングが機能要件と非機能要件を使用して設計を作成するのと同じように、ドメイン エンジニアリングのドメイン設計フェーズでは、ドメイン分析フェーズで開発された構成可能な要件を使用して、システム ファミリの構成可能な標準化されたソリューションを作成します。ドメイン設計は、要件構成が異なるにもかかわらず、ドメイン内のシステム間で共通の問題を解決するアーキテクチャ パターンを作成することを目指します。[20]ドメイン設計中のパターンの開発に加えて、エンジニアは、パターンの範囲と、パターンに関連するコンテキストのレベルを識別することにも注意する必要があります。コンテキストの制限は重要です。コンテキストが多すぎると、パターンが多くのシステムに適用できなくなり、コンテキストが少なすぎると、パターンが十分に強力でなくなり、役に立たなくなります。[21]有用なパターンは、頻繁に繰り返され、高品質である必要があります。[22]
ドメイン設計の目的は、開発された機能モデルが提供する柔軟性を維持しながら、できるだけ多くのドメイン要件を満たすことです。アーキテクチャは、ドメイン内のすべてのシステムを満たすのに十分な柔軟性を持ちながら、ソリューションの基盤となる強固なフレームワークを提供できるほど堅牢である必要があります。[23]
ドメイン実装
ドメイン実装とは、ドメイン内でカスタマイズされたプログラムを効率的に生成するためのプロセスとツールを作成することです。
批判
ドメインエンジニアリングは、個人の世界観、言語、またはコンテキストがソフトウェアの設計に統合されるような「使用のためのエンジニアリング」に集中するのではなく、汎用的なソフトウェア機能の「再利用のためのエンジニアリング」または「再利用を伴うエンジニアリング」に重点を置きすぎていると批判されてきました。[24]
参照
参考文献
- ^ ISO 26550:2015 – ソフトウェアおよびシステムエンジニアリング — 製品ラインエンジニアリングおよび管理の参照モデル。
- ^ フレイクス＆カン 2007、p. 2より
- ^ フレイクス＆カン 2007、p. 1
- ^ ツァルネッキ＆アイゼネッカー 2000、19ページ
- ^ バトリー他 2002年、19ページ
- ^ ツァルネッキ＆アイゼネッカー 2000、p. 20
- ^ ab Czarnecki & Eisenecker 2000、p. 21より
- ^ ハルス 2002、p.8
- ^ ラインハルツ・バーガー他 2013、p. xii
- ^ ファルボ、ギザーディ、ドゥアルテ、2002、p. 2
- ^ abcdef ツァルネッキ＆アイゼネッカー 2000、p. 23
- ^ ツァルネッキ＆アイゼネッカー 2000、38ページ
- ^ カン他 2004、p.7
- ^ カン他 2004、3ページ
- ^ カン他 2004、p.4
- ^ フレイクス＆カン 2007、3ページ
- ^ ツァルネッキ＆アイゼネッカー 2000、p.84
- ^ ツァルネッキ＆アイゼネッカー 2000、p.86
- ^ ツァルネッキ＆アイゼネッカー 2000、24ページ
- ^ ツァルネッキ＆アイゼネッカー 2000、25ページ
- ^ ブッシュマン、ヘニー、シュミット 2007、p.42
- ^ ブッシュマン、ヘニー、シュミット 2007、31 ページ
- ^ ツァルネッキ＆アイゼネッカー 2000、28ページ
- ^ メトラー 2017、5 ページ
出典
- Batory, Don; Johnson, Clay; MacDonald, Bob; von Heeder, Dale (2002). 「製品ラインとドメイン固有言語による拡張性の実現: ケーススタディ」. ACM Transactions on Software Engineering and Methodology . 11 (2). ACM : 191–214. CiteSeerX 10.1.1.100.7224 . doi :10.1145/505145.505147. S2CID 7864469.
- Buschmann, Frank; Henney, Kevlin ; Schmidt, Douglas C. (2007).パターン指向ソフトウェアアーキテクチャ: パターンとパターン言語について. 第 5 巻. John Wiley & Sons . ISBN 978-0-471-48648-0。
- Czarnecki, Krzysztof; Eisenecker, Ulrich W. (2000)。 『ジェネレーティブプログラミング：方法、ツール、およびアプリケーション』。ボストン：Addison- Wesley。ISBN 0-201-30977-7。
- Falbo, Ricardo de Almedia; Guizzardi, Giancarlo; Duarte, Katia Cristina (2002)。「ドメイン エンジニアリングへのオントロジー的アプローチ」。ソフトウェア エンジニアリングと知識エンジニアリングに関する第 14回国際会議の議事録。ACM。pp . 351–358。CiteSeerX 10.1.1.19.2577。doi : 10.1145 / 568760.568822。ISBN 1581135564. S2CID 16743035。
- Kang, Kyo C.; Lee, Jaejoon; Kim, Kijoo; Kim, Gerard Jounghyun; Shin, Euiseob; Huh, Moonhang (2004 年 10 月)。「FORM: ドメイン固有の参照アーキテクチャによる機能指向の再利用方法」。Annals of Software Engineering。5。Springer Netherlands : 143–168。CiteSeerX 10.1.1.95.7568。doi : 10.1023 /A : 1018980625587。S2CID 1830464。
- Frakes, William B.; Kang , Kyo (2007 年 7 月)。「ソフトウェア再利用研究: 現状と将来」。IEEE Transactions on Software Engineering。31 ( 7): 529–536。CiteSeerX 10.1.1.75.635。doi : 10.1109 / tse.2005.85。S2CID 14561810 。
- Harsu, Maarit (2002 年 12 月)。ドメイン エンジニアリングに関する調査(PDF) (レポート)。タンペレ工科大学ソフトウェア システム研究所。p. 26。ISBN 9789521509322。
- Mettler, Tobias (2017). 「医療のためのプロフェッショナルソーシャルネットワークの文脈化：アクションデザイン研究からの経験」(PDF)。情報システムジャーナル。28 (4): 684–707。doi :10.1111/isj.12154。S2CID 49411423。
- Reinhartz-Berger, Iris; Sturm, Arnon; Clark, Tony; Cohen, Sholom; Bettin, Jorn (2013).ドメインエンジニアリング: 製品ライン、言語、概念モデル. Springer Science+Business Media . ISBN 978-3-642-36654-3。