21 DSLs and Product Lines
最終更新：
twoflat1017 2013年12月18日(水) 23:12:26履歴
| 21 DSLs and Product Lines | |
| This chapter discusses the role of DSLs in Product Line Engineering(PLE). We first briefly introduce PLE and feature models and discuss how feature models can be connected to programs expressed in DSLs. We then explain the difference in expressivity between feature models and DSLs and argue why sometimes features models are not enough to express the variability in a product line, and how DSLs can help. The chapter concludes with a mapping of the concepts relevant to PLE and DSLs. This chapter is written mostly for people with a background in PLE who want to understand how DSLs fit into PLE. | この章では、プロダクトライン·エンジニアリング（PLE）内のDSLの役割について説明します。まず、簡単にPLEおよびフィーチャーモデルを導入し、機能モデルはDSLの中で表現されたプログラムとの接続方法を説明します。それから、機能モデルとDSLの間の表現力の違いを説明し、時にはモデルは製品ラインの多様性を表現するのに十分なされていない機能、およびDSLのは、どのように役立つか、なぜ主張している。章では、PLEおよびDSLのに関連する概念のマッピングで締めくくり。この章では、DSLのは、PLEに収まるかを理解したい、PLEのバックグラウンドを持つ人々のために主に書かれています。 |
| 21.1 Introduction | |
| The goal of product line engineering (PLE) is to efficiently manage a range of products by factoring out commonalities such that definitions of products can be reduced to a specification of their variable aspects. As a consequence of this approach, software quality can be improved and time-to-market of any single product in the product line can be reduced. One way of achieving this is the expression of product configurations on a higher level of abstraction than the actual implementation. An automated mapping transforms the configuration to the implementation. | 製品ラインエンジニアリング（PLE）の目的は、効率的に製品の定義は、その変数の態様の仕様にすることができるように、共通性を因数分解することによって製品の範囲を管理することである。このアプローチの結果として、ソフトウェアの品質を向上させることができ、タイム·ツー·マーケット製品ラインの任意の単一の生成物を低減することができる。これを達成する1つの方法は、実際の実装よりも高い抽象化レベルでの製品構成の表現である。自動化されたマッピングは、実装にコンフィギュレーションを変換します。 |
| 21.2 Feature Models | |
| In PLE, this higher level of abstraction is typically realized with feature models. Feature models express configuration options and the constraints among them. A graphical notation, called feature diagrams, is often used to represent feature models (Fig. 21.1 shows an example). Here is why we need constraints: if a product line’s variability was just expressed by a set of Boolean options, the configuration space would grow by 2n, with n representing the number of options. With feature models, constraints are expressed regarding the combinations of features, limiting the set of valid configurations to a more manageable size. Constraints include: ・Mandatory (filled circles): mandatory features have to be in each product. For example, in Fig. 21.1, each Stack has to have the feature ElementType. ・Optional (empty circles): optional features may or may not be in a product. Counter and Optimization are examples of optional features. ・Or (filled arc): a product may include zero, one or any number of the features in an or group. In the example, a product may include any number of features from ThreadSafety, BoundsCheck and TypeCheck. ・Xor (empty arc): a product must include exactly one of the features grouped into a xor group. The ElementType must either be int, float or String. | PLEでは、抽象化のこの高いレベルは、一般的に機能モデルを用いて実現されている。機能モデルは、構成オプションとそれらの間の制約を表現。機能ダイアグラムというグラフィカル表記は、多くの場合（図21.1は、一例を示している）機能モデルを表すために使用される。我々は制約が必要な理由はここにある：製品ラインの変動がちょうどブールオプションのセットで表現された場合は、コンフィギュレーション空間は、 nはオプションの数を表すとともに、 2Nで育つ。機能モデルと、制約がより扱いやすいサイズに有効な構成のセットを制限し、特徴の組み合わせに関する表現されている。制約は、次のとおりです。 ·必須（黒丸） ：必須機能は、各製品でなければならない。例えば、図。 21.1 、各スタックは、機能のElementTypeを有していなければならない。 ·オプション（白丸） ：オプション機能や製品であってもなくてもよい。カウンターと最適化オプション機能の例です。 ·または、（満たされたアーク） ：製品は、ゼロ、 1 、または、グループ内の任意の数の特徴を含むことができる。この例では、生成物がThreadSafety 、 BoundsCheckと型チェックの特徴のいずれかを含むことができる。 · XOR（空アーク） ：製品が正確にXORグループにグループ化された機能の1を含める必要があります。のElementTypeはint型、 float型またはStringのいずれかである必要があり。 |
| A configuration represents a product in the product line. It comprises a set of feature selections from a feature model that comply with the constraints expressed in the feature model. For example, the configuration {Optimization, Memory Use, Additional Features, Type Check, Element Type, int, Size, Dynamic} would be valid. A configuration that includes Speed and Memory Usage would be invalid, because it violates the xor constraint between those two features expressed in the feature model. Note that a feature model does not yet describe the implementation of a product or the product line, the feature model has to be connected to implementation artifacts in a separate step. | 構成は、製品ラインの製品を表しています。これは、フィーチャーモデルで表現された制約に準拠するフィーチャーモデルからの特徴選択肢のセットを含む。例えば、構成{最適化、メモリ使用、その他の機能、種類を確認、要素の型はint、サイズ、ダイナミック}は有効になります。それは違反しているため、速度とメモリ使用量を含む構成は、無効となります これらの2つの機能のXOR制約が特徴モデルで表現。フィーチャーモデルは、まだ製品または製品ラインの実装が説明されていないことに注意し、フィーチャーモデルは、別々の工程で実装成果に接続されなければならない。 |
| 21.3 Connecting Feature Models to Artifacts | |
| By definition, feature models express product line variability at a level that is more abstract than the implementation. In many systems, the implementation of variability is scattered over (parts of) many implementation artifacts. However, to result in a correct system, several variation points (VP) may need to be configured in a consistent, mutually dependent way. If each VP has to be configured separately, the overall complexity grows quickly. By identifying logical variation points and factoring them into features in a feature model, and then tying the (potentially many) implementation variation points to these logical variation points, related implementation variations can be tied together and managed as one (Fig. 21.2). | 定義上、機能モデルは実装よりも抽象的でレベルの製品ラインの多様性を表現しています。多くのシステムでは、変動性の実装は、多くの実装成果物（の一部）上で散乱される。しかし、正しいシステムをもたらすと、いくつかの変化点（VP）は一貫して、相互に依存するように設定する必要があります。各VPは別々に設定する必要がある場合には、全体的な複雑さはすぐに成長する。論理変化点を特定し、特徴モデル内のフィーチャにそれらを因数分解してから、これらの論理変化点に（潜在的に多く）の実装の変化点を結ぶことにより、関連する適用のバリエーションが1（図21.2）と一緒に接続し、管理することができます。 |
| If DSLs are used to implement a software system, then the artifacts configured from the feature model are typically DSL programs, and the variation points are program elements. By using DSL models instead of low-level implementation code, the number of variation points in the artifacts will be reduced, because you use the DSL-to-code transformation to expand all the details in a consistent way. The trade-off is that you have to define this high-level domain specific language, including a way to define variants of programs written in that language. You also need to define the transformation down to the actual implementation artifacts (Fig. 21.3). | DSLは、ソフトウェアシステムを実装するために使用される場合、フィーチャーモデルから構成された成果物は、典型的には、DSLのプログラムであり、変化点は、プログラム要素である。一貫性のある方法ですべての詳細を展開するためにDSLからコード変換を使用するため、DSLモデルを用いた代わりに、低レベルの実装コードのことで、成果物の変化点の数を低減することができる。トレードオフは、あなたがその言語で書かれたプログラムの亜種を定義する方法を含め、このハイレベルのドメイン固有言語を定義しなければならないことです。また、ダウン実際の実装成果物（図21.3）への変換を定義する必要があります。 |
| The configuration of models (and other artifacts) can be done in several different ways: removal, injection and parameterization. | モデル（およびその他の成果物）の構成は、いくつかの異なる方法で行うことができます。除去、注射とパラメータ。 |
| ■Removal (also known as negative variability) In this approach, the mapping from a feature model to implementation artifacts removes parts of a comprehensive whole (Fig. 21.4). This implies marking up the various optional parts of the comprehensive whole with Boolean expressions that determine when to remove the part. These expressions are called presence conditions. The biggest advantage of this approach is its apparent simplicity. However, the comprehensive whole has to contain the parts for all variants (maybe even parts for combinations of variants), making it potentially large and complex. Also, depending on the tool support, the comprehensive whole might not even be a valid instance of the underlying language or formalism. In an IDE, the respective artifact might show errors, which makes this approach annoying at times. ifdefs in C and C++ are a well-known implementation of this strategy. A preprocessor removes all code regions whose ifdef condition evaluates to false. When calling the compiler/preprocessor, you have to provide a number of symbols that are evaluated as part of the conditions. Conditional compilation can also be found in other languages. Preprocessors that treat the source code simply as text are available for many languages and are part of many PLE tool suites. The AUTOSAR standard, as well as other modeling formalisms, support the annotation of model elements with presence conditions. The model element (and all its children) are removed from the model if the condition evaluates to false. The same approach is available in mbeddr. | ■除去（負の変動とも呼ばれます） このアプローチでは、実装成果物に特徴モデルからのマッピングは、包括的な全体（図21.4 ）の部分を削除します。これは一部を除去するかを決定するブール式を持つ総合的な全体の様々なオプションパーツをマークアップを意味します。これらの表現は、存在条件と呼ばれます。このアプローチの最大の利点は、その見かけシンプルさです。しかし、包括的な全体は、それが潜在的に大規模で複雑なこと、すべての亜種（変種の組み合わせについて、多分部品）の部品が含まれている必要があります。また、ツールのサポートに応じて、包括的な全体でも、基礎となる言語や形式主義の有効なインスタンスではない場合があります。 IDEでは、それぞれの成果物は、常に迷惑なこのアプローチを行っている、エラーが表示される場合があります。 CおよびC + +でのifdefは、この戦略のよく知られた実装です。プリプロセッサは、その切り分け、条件がfalseに評価されるすべてのコード領域を削除します。コンパイラ/プリプロセッサを呼び出すときには、条件の一部として評価されるシンボルの数を提供する必要があります。条件付きコンパイルは、他の言語でも見ることができる。単にテキストとしてソースコードを扱うプリプロセッサは、多くの言語で利用可能であり、多くのPLEツール·スイートの一部である。 AUTOSAR規格だけでなく、他のモデリング形式主義は、プレゼンス状態を持つモデル要素の注釈をサポートしています。条件が偽と評価された場合のモデル要素（とそのすべての子）がモデルから削除されます。同じアプローチはmbeddrで提供されています。 |
| ■ Injection (also known as positive variability) In this approach, additions are defined relative to a minimal core (Fig. 21.5). The core does not know about the variability: the additions point to the place where they need to be added. The clear advantage of this approach is that the core is typically small and contains only what is common for all products. The parts specific to a variant are kept external and added to the core only when necessary. To be able to do this, however, there must be a way to refer to the location in the minimal core at which to add a variable part. This either requires the explicit definition of named hooks in the minimal core, or some way of pointing into the core from an external source. Also, interactions between the additions for various features may also be hard to manage. Aspect-oriented programming is a way of implementing this strategy. Pointcuts are a way of selecting from a set of join points in the base asset. A joint point is an addressable location in the core. Instead of explicitly defining hooks, all instances of a specific language construct are automatically addressable. Various preprocessors can also be used in this way. However, they typically require the explicit markup of hooks in the minimal core. For models, injection is especially simple, since in most formalisms model elements are addressable by default and/or the language can be extended to be able to mark up hooks. This makes it possible to point to a model element, and add additional model elements to it, as long as the result is still a valid instance of the meta model. | ■インジェクション（正変動とも呼ばれます） このアプローチでは、追加が最小限のコア（図21.5 ）に関連して定義されています。コアは、ばらつきを知られていません。追加は、彼らが追加する必要がある場所を指している。このアプローチの明確な利点は、コアが一般的に小さく、すべての製品に共通しているものだけが含まれていることである。変種に固有の部分は、外部に保ち、必要な場合にのみコアに追加されます。これを実行できるようにするには、しかし、可変部分の追加で最小のコア内の場所を参照する方法がなければならない。これはどちらか、最小限のコアの名前付きフックの明示的な定義、または外部ソースからのコアに向いてのいくつかの方法が必要になります。また、さまざまな機能のための添加の間の相互作用もまた、管理するのは難しいかもしれません。アスペクト指向プログラミングは、この戦略を実行する方法です。ポイントカットは、基本資産におけるジョインポイントの集合から選択する方法です。関節点は、コア内のアドレス可能な場所です。代わりに、明示的にフックを定義する、特定の言語構造のすべてのインスタンスを自動的にアドレス指定可能である。種々のプリプロセッサもこの方法で使用することができる。しかし、彼らは一般的に、最小限のコア内のフックの明示的なマークアップを必要とする。ほとんどの形式論でモデル要素は、デフォルトおよび/または言語によってアドレスがフックをマークアップすることができるように拡張することができているので、モデルの場合、注射は、特に簡単である。これにより、モデル要素を指し、そして限り、結果はまだメタモデルの有効なインスタンスであるように、そこに追加のモデル要素を追加することができます。 |
| ■Parameterization The variable artifact defines parameters. A variant is constructed by providing values for those parameters (Fig. 21.6). The parameters are usually typed to restrict the range of valid values. In most cases, the values for the parameters are relatively simple, such as strings, integers, Booleans or regular expressions. However, in principle, they can be arbitrarily complex. The parameterized artifact needs to explicitly define the parameters, as well as a way to specify values. The artifact has to query the values of those parameters explicitly and use them for whatever it does. The approach requires the core to be explicitly aware of the variability. A configuration file that is read out by the an application is a form of parameterization. The names of the parameters are predefined by the application, and when defining a variant, a set of values is supplied. The Strategy pattern is a form of parameterization, especially in combination with a factory. A variant is created by supplying an implementation of an interface defined by the configurable application. All kinds of other small, simple or domain-specific languages can be used as a form of parameterization. A macro language in an application is a form of parameterization, where the type of parameter is "valid program written in language X". | ■パラメータ化 変数アーティファクトはパラメータを定義します。変異体は、それらのパラメータ（図21.6 ）の値を提供することによって構成されている。パラメータは、通常、有効な値の範囲を制限するために型指定されている。ほとんどの場合、パラメータの値は、文字列、整数、ブール値や正規表現など、比較的単純である。しかし、原理的には、それらは任意に複雑になる場合があります。パラメータ化されたアーティファクトは、明示的なパラメータだけでなく、値を指定する方法を定義する必要があります。アーティファクトは、明示的にこれらのパラメータの値を照会し、それがない何のためにそれらを使用する必要があります。アプローチは、変動性を明示的に認識しているコアを必要とします。アプリケーションによって読み出され、設定ファイルには、パラメータ化の一形態である。パラメータの名前は、アプリケーションによって事前定義されており、変異型を定義する際、値のセットが供給されている。 Strategyパターンは、特に、工場との組み合わせで、パラメータ化の一形態である。変異体は、構成アプリケーションによって定義されたインタフェースの実装を供給することによって作成される。他方、小さな単純またはドメイン固有の言語のすべての種類は、パラメータ化の形態として用いることができる。アプリケーションのマクロ言語では、パラメータの型は、 「言語Xで記述された有効なプログラム」でパラメータ化の形態である。 |
| 21.3.1 Example Implementation in mbeddr | |
| In mbeddr we use a textual notation for feature models. Fig. 21.7 shows this notation for the stack feature model shown graphically above. Note how the constraint affects all children of a feature, so we had to introduce the intermediate feature options to separate mandatory features from optional features. Features can also have configuration attributes (of any type). A configuration is a named set of selections from the features in a feature model. The selection has to be valid regarding the constraints defined in the feature model. Fig. 21.8 shows two example configurations. If an invalid configuration is created, errors will be shown in the configuration model. | mbeddrでは、フィーチャモデルのテキストの表記法を使用します。図。 21.7ショーをグラフ上に示したスタック機能モデルのこの表記。制約が機能のすべての子に影響を与えますので、我々は、オプション機能の必須機能を分離するための中間機能オプションを導入しなければならなかったことに注目してください。機能も（任意の型の）構成属性を持つことができます。構成は、フィーチャー·モデルの特徴から選択の名前付きセットです。選択は、機能モデルで定義された制約に関して有効である必要があります。図。 21.8は、2例の構成を示しています。無効な構成が作成されると、エラーが構成モデルに表示されます。 |
| Presence conditions can be attached to any program element expressed in any language, without this language having to know about it, thanks to MPS’ annotations (discussed in Section 16.2.7). For example the two report statements and the message list in the left program in Fig. 21.9 are only part of a product if the logging feature is selected in the product configuration. The background color of an annotated node is computed from the expression: annotated nodes using the same expression have the same color (an idea borrowed from Christian Kaestner’s CIDE12). | プレゼンス状態は、この言語は、それについて知っている（セクション16.2.7で説明します）MPS」の注釈のおかげでなくても、任意の言語で表現され、任意のプログラム要素に付着させることができる。例2レポート文と図の左のプログラムのメッセージリストについて。ログ機能は、製品の設定で選択されている場合21.9は、製品の一部である。注釈付きノードの背景色は、式から計算されます。同じ式を使用して、注釈付きのノードが同じ色（クリスチャン·ケストナーのCIDE12から借りたアイデアを）持っている。 |
| It is possible to edit the program as a product line (with the annotations), undecorated (without annotations), as well as a specific product. Fig. 21.9 shows an example. During transformation, those parts of programs that are not in the product are removed from the model. | それは、（注釈なし）装飾されていない（注釈付き）製品ライン、ならびに特定の製品としてプログラムを編集することが可能である。図。 21.9に例を示します。変換中に、製品に含まれていないプログラムの部分は、モデルから削除されます。 |
| 21.3.2 Feature Models on Language Elements | |
| Instead of using feature models to vary programs expressed with DSLs, the opposite approach is also possible. In this case, the primary product definition is done with DSLs. However, some language concepts have a feature model associated with them for detailed configuration. When the particular language concept is instantiated, a new ("empty") feature configuration is created, and can be configured by the application engineer. | 代わりに、DSLを用いて表現されたプログラムを変化させるように機能モデルを使用する、逆のアプローチも可能である。この場合、一次製品定義は、DSLを用いて行われる。しかし、いくつかの言語の概念は、詳細な構成のためにそれらに関連付けられた機能モデルを持っている。特定の言語の概念がインスタンス化されると、新たな（「空」）機能の設定が作成され、アプリケーションエンジニアで構成することができる。 |
| 21.3.3 Variations in the Transformation or Execution | |
| When working with DSLs, the execution of models – by transformation, code generation or interpretation – is under the control of the domain engineer. The transformations or the interpreter can also be varied based on a feature model. | のDSLを使用する場合は、モデルの実行 - 変換により、コード生成や解釈は - ドメインエンジニアの制御下にある。変換またはインタプリタは、特徴モデルに基づいて変化させることができる。 |
| ■ Negative Variability via Removal The transformations or the interpreter can be annotated with presence conditions; the configuration happens before the transformations or the interpreter are executed. ■ Branching The interpreter or the transformations can query over a feature configuration and then branch accordingly at runtime. ■ Positive Variability via Superimposition Transformations or interpreters can be composed via superposition before execution. For transformations, this is especially feasible if the transformation language is declarative, which means that the order in which the transformations are specified is irrelevant. Interpreters are usually procedural, object-oriented or functional programs, so declarativeness is hard to achieve in those. ■ Positive Variability via Aspects If the transformation language or the interpreter implementation language support aspect oriented programming, then this can be used to configure the execution environment. For example, the Xpand code generation engine supports AOP for code generation templates. | 除去によって負の可変を■ 変換またはインタプリタが存在条件で注釈を付けることができ、変換またはインタプリタが実行される前に設定が行われます。 ■分岐 インタプリタや変換は、機能の設定を介してクエリを実行してから、実行時にそれに応じて分岐することができます。 重畳を介して正変動を■ 変換または通訳は、実行前に重ね合わせを経由して構成することができる。変換言語、宣言型である場合の変換の場合、これは変換が指定された順序とは無関係であることを意味し、特に実現可能である。通訳は通常、手続き型、オブジェクト指向、または機能的なプログラムなので、 declarativenessはそれらの中で達成することは困難である。 側面を介して正変動を■ 変換言語又はインタプリタ実装言語サポート態様指向プログラミングは、これは実行環境を構成するために使用することができる場合。たとえば、のXpandコード生成エンジンは、コード生成テンプレートのAOPをサポートしています。 |
| Creating transformations with the help of other transformations, or by any of the above variability mechanisms, is also referred to as higher-order transformations. Note that if a boot-strapped environment is used, the transformations are themselves models created with a transformation DSL. This case then reduces to just variation over models, as described in the previous subsection. | 他の変換の助けを借りて、または上記可変機構のいずれかによって、型の変換を作成すること、また、高次の変換と呼ばれる。ブートストラップ環境を使用する場合は、変換は、それ自体が変態のDSLで作成されたモデルであることに注意してください。前節で説明したように、この場合は、その後、モデルに比べ単に変化に減少します。 |
| 21.4 From Feature Models to DSLs | |
| A feature model is a compact representation of the features of the products in a product line, as well as the constraints imposed on combinations of these features in products. Feature models are an efficient formalism for configuration, i.e. for selecting a valid combination of features from the feature model. The set of products that can be defined by feature selection is fixed and finite: each valid combination of selected features constitutes a product. This means that all valid products have to be "designed into" the feature model, encoded in the features and the constraints among them. Some typical examples of things that can be modeled with feature models are the following: • Does the communication system support encryption? • Should the in-car entertainment system support MP3s? • Should the system be optimized for performance or memory footprint? • Should messages be queued? What is the queue size? Because of the "select from set of options" metaphor, feature model-based configuration is simple to use – product definition is basically a decision tree. This makes product configuration efficient, and potentially accessible for stakeholders other than software developers. Also, as described by Batory and Czarnecki, one advantage of feature models is that a mapping to logic exists. Using SAT solvers, it is possible to check, for example, whether a feature model has valid configurations at all. The technique can also be used to automatically complete partial configurations. | 機能モデルは、製品ラインの製品の特徴のコンパクトな表現だけでなく、製品にこれらの機能の組み合わせに課せられた制約である。機能モデルは、機能モデルから機能の有効な組み合わせを選択するために、すなわち、コンフィギュレーションのための効率的な形式主義、である。特徴選択によって定義することができる製品のセットが固定されており、有限である：選択した機能のそれぞれ有効な組み合わせは、製品を構成している。これは、すべての有効な製品は、その中の機能や制約でエンコードされた、特徴モデル」に設計された "されなければならないことを意味します。機能モデルでモデル化することができることのいくつかの典型的な例は次のとおりです。 •通信システムのサポートの暗号化をしていますか？ •車載エンターテイメントシステムのサポートMP3ファイルをすべきか？ •システムは、パフォーマンスやメモリフットプリントのために最適化されるべきか？ •メッセージがキューに入れされるべきか？キューのサイズは何ですか？ ので、「一連のオプションから選択し、「隠喩の、特徴モデルベースの設定は、使用が簡単です - 製品の定義は、基本的には決定木である。これは、製品構成が効率的になり、そしてソフトウェア開発者以外の利害関係者のために潜在的にアクセスできます。バートリとCzarneckiに記載されているように、また、特徴モデルの一つの利点は、論理マッピングが存在することである。 SATソルバを使用して、フィーチャーモデルは全く有効な構成を有しているか否かは、例えば、確認することができる。技術はまた、自動的に部分的な構成を完了するために使用することができる。 |
| In the rest of this section we will discuss the limitations of feature models, in particular, that they are not suited for openended construction of product variants. Instead of giving up on models completely and using low-level programming, we should use DSLs instead. This avoids losing the differentiation between problem space and solution space, while still supporting more expressivity in the definition of a product. | このセクションの残りでは、それらは生成物変異体のオープンエンドの構築に適していないことを、特に特徴のモデルの限界を説明する。代わりに、完全なモデルを放棄し、低レベルのプログラミングを使用して、我々は、代わりにDSLを使用する必要があります。これはまだ、製品の定義により表現力をサポートしながら、問題空間と解空間の間の区別を失う避けることができます。 |
| As an example, we use a product line of water fountains, as found in recreational parks. Fountains can have several basins, pumps and nozzles. Software is used to program the behavior of the pumps and valves to make the sprinkling waters aesthetically pleasing. The feature model in Fig. 21.10 represents valid hardware combinations for a simple water fountain product line. Each feature corresponds to the presence of a hardware component in a particular fountain installation. | 一例として、我々は、レクリエーション公園で見られるように、噴水の製品ラインを使用しています。噴水は、複数の盆地、ポンプ、ノズルを持つことができます。ソフトウェアは、散布水が美的にするポンプとバルブの動作をプログラムするために使用される。図中の特徴のモデル。 21.10は、簡単な噴水製品ラインの有効なハードウェアの組み合わせを表しています。それぞれの特徴は、特定の噴水のインストールでハードウェアコンポーネントの存在に対応している。 |
| The real selling point of water fountains is their behavior. A fountain’s behavior determines how much water each pump should pump, at which time, with what power, or how a pump reacts when a certain condition is met, e.g., a basin is full. Expressing the full range of such behaviors is not possible with feature models. Feature models can be used to select among a fixed number of predefined behaviors, but approximating all possible behaviors would lead to unwieldy feature models. | 噴水の本当のセールスポイントは、その動作です。噴水の動作は、各ポンプは、特定の条件が満たされたときにどのような力、またはどのようにしてポンプが流域がいっぱいになって、例えば、反応し、その時点では、ポンプどの程度水を決定します。このような行動の全範囲を表現する機能モデルでは不可能です。フィーチャーモデルは、事前定義された行動の固定数の中から選択するために使用することができるが、全ての可能な挙動を近似することは扱いにくい特徴モデルにつながる。 |
| 21.4.1 Feature Models as Grammars | |
| To understand the limitations of feature models, we consider their relation to grammars. Feature models essentially correspond to context-free grammars without recursion. For example, the feature model in Fig. 21.10 is equivalent to the following grammar: | 機能モデルの限界を理解するために、我々は文法との関係を考えてみましょう。機能モデルは、本質的に再帰することなく、文脈自由文法に対応しています。例えば、図フィーチャーモデル。 21.10は、次の文法と等価です。 |
| This grammar represents a finite number of sentences: there are exactly four possible configurations, which correspond to the finite number of products in the product line. However, this formalism does not make sense for modeling behavior, for which there is typically an infinite range of variability. To accommodate for unbounded variability, the formalism needs to be extended. Allowing recursive grammar productions is sufficient to model unbounded configuration spaces, but for convenience, we consider also attributes and references. | この文法は、文章の有限数を表し製品ラインの製品の有限数に対応する正確に4つの可能な構成が存在する。変動性の無限の範囲は、通常、そこにされているが、この形式主義は、モデリングの動作のためには意味がありません。非有界変動性に対処するため、形式主義を拡張する必要がある。再帰的な文法のプロダクションを許可すると、無制限の配置空間をモデル化するのに十分であるが、便宜のために、我々はまた、属性と参照を検討してください。 |
| Attributes express properties of features. For example, the PUMP could have an integer attribute rpm, representing the power setting of the pump. Recursive grammars can be used to model repetition and nesting. Nesting is necessary to model tree structures such as those occurring in expressions. The following grammar extends the fountain feature model with a Behavior, which consists of a number of Rules. The Basin can now have any number of Nozzles. References allow the creation of context-sensitive relations between parts of programs described by the grammar. For example, by further extending our fountain grammar we can describe a rule whose condition refers to the full attribute of the ISFULLSENSOR and whose consequence sets a PUMP’s rpm to zero. Fig. 21.11 shows a possible rendering of the grammar with an enhanced feature modeling notation. We use cardinalities, as well as references to existing features, the latter are shown as dotted boxes. A valid configuration could be the one shown in Fig. 21.12. It shows a fountain with one basin, two nozzles named n1 and n2, one sensor s and a pump p. It contains a rule that expresses the condition that if the full attribute of s is set, and the rpm of pump p is greater than zero, then the rpm should be set to zero. | 属性は、機能の特性を表現しています。例えば、 PUMPは、ポンプのパワー設定を表す整数属性回転数を有することができる。再帰的な文法は反復とネストをモデル化するために使用することができる。ネスティングは、このような式において生じるもののようなツリー構造をモデル化することが必要である。次の文法はルールの数で構成されて行動、と噴水機能モデルを拡張します。盆地は今ノズルの数に制限はありません。参照は、文法で記述するプログラムの部分の間の文脈依存関係の作成を可能にします。例えば、一層の噴水文法を拡張することによって、我々は、その条件ISFULLSENSORのフル属性を参照し、その結果としてゼロにポンプの回転数を設定し、ルールを記述することができます。図。 21.11は、拡張機能のモデリング表記法と文法の可能レンダリングを示しています。私たちは、カーディナリティのほか、既存の機能への参照を使用し、後者は点線のボックスとして表示されます。有効な構成は、図に示すものであってもよい。 21.12 。それが1台、 n1とn2という名前の2つのノズル、一つのセンサSとポンプPと噴水を示しています。これは、sの完全な属性が設定され、ポンプPの回転数がゼロより大きい場合には、その後回転数がゼロに設定されるべきであるという条件を表すルールを含む。 |
| 21.4.2 Domain-Specific Languages | |
| While the extended grammar formalism discussed above enables us to cover the full range of behavior variability, the use of a graphical tree notation to instantiate these grammars is not practical. Another interpretation of these grammars is as the definition of a DSL – the tree in Fig. 21.12 looks like an abstract tree (AST). To make the language readable we need to add concrete syntax definitions (keywords), as in the following extension of the fountain grammar: We can now write a program that uses a convenient textual notation, which is especially useful for the expressions in the rules. We have created a DSL for configuring the composition and behavior of fountains. DSLs fill the gap between feature models and programming languages. They can be more expressive than feature models, but they are not as unrestricted and low-level as programming languages. Like programming languages, DSLs support construction, allowing the composition of an unlimited number of programs. Construction happens by instantiating language concepts, establishing relationships, and defining values for attributes. We do not a-priori know all possible valid programs. In contrast to programming languages, DSLs keep the distinction between problem space and solution space intact, since they consist of concepts and notations relevant to the problem domain. Non-programmers can continue to contribute directly to the product development process, without being exposed to implementation details. | 上記の拡張された文法形式主義は行動の変動性の全範囲をカバーするために私達を可能にするが、これらの文法をインスタンス化するグラフィカルなツリー表記を使用することは現実的ではない。図のツリー - これらの文法の別の解釈は、DSLの定義としてである。 21.12抽象ツリー（ AST ）のように見えます。言語は読みやすくするために、我々は噴水文法の次の拡張のように、具体的な構文定義（キーワード）を追加する必要があります。我々は今のルールの式のために特に有用である便利なテキスト形式の表記を、使用するプログラムを書くことができます。私たちは、噴水の構成と動作を設定するためのDSLを作成しました。 DSLは機能モデルとプログラミング言語との間のギャップを埋める。彼らは、機能モデルよりも、より表現することができますが、プログラミング言語のように制限されていないと、低レベルではありません。プログラミング言語と同様に、 DSLはプログラムの数に制限の構成を可能にする構築をサポート。建設、言語の概念をインスタンス化関係を確立し、属性値を定義して行われます。私たちは、事前のすべての可能な有効なプログラムを知らない。彼らは概念や問題領域に関連する表記で構成されているので、プログラミング言語とは対照的に、 DSLは、そのまま問題空間と解空間の区別を保持します。非プログラマは実装の詳細にさらされることなく、製品開発プロセスに直接貢献していきます。 |
| 21.4.3 Making Feature Models More Expressive | |
| We described the limitations of the feature modeling approach above, and proposed DSLs as an alternative. However, the feature modeling community is working on alleviating some of these limitations. | 私たちは、代替手段として、上記の特徴のモデリング手法の限界、および提案されたDSLを説明した。しかし、フィーチャーモデリングコミュニティはこれらの制限の一部を緩和することに取り組んでいます。 |
| For example, cardinality based feature models support the multiple instantiation of feature subtrees. References between features could be established by using feature attributes typed with another feature – the value range would be the set of instances of this feature. Name references are an approximation of this approach. | たとえば、カーディナリティ基づく特徴モデルは機能サブツリーの複数のインスタンス化をサポートしています。値の範囲は、この機能のインスタンスのセットになります - 機能間の参照は、別の特徴に型付けされた地物の属性を使用することによって確立することができた。名前の参照は、このアプローチの近似値である。 |
| Clafer combines meta modeling and feature modeling. In addition to providing a unified syntax and a semantics based on sets, Clafer also provides a mapping to SAT solvers to support validation of models. The following is an example Clafer: The code describes a concept Person with the following characteristics: • A name and a first name of type String (similar to attributes). • A gender, which is Male or Female, or both (similar to or-groups in feature models). • A marital status, which is either single, married or divorced (similar to xor-groups in feature models). • An Address (similar composition is language definitions) . • An optional State attribute on the address (similar to optional features in feature modeling). | Clafer、メタモデリングと機能モデリングを組み合わせたものです。統一された構文とセットに基づいてセマンティックを提供するだけでなく、Claferもモデルの検証をサポートするために、SATソルバへのマッピングを提供する。次の例Claferです。 コードは次の特性を持つコンセプトパーソンについて説明します。 名前と（属性と同様）、String型の名を•。 （特徴のモデルや、基と同様）男性または女性である性別、またはその両方を•。 （特徴のモデルで類似するXOR-基など）、単独の結婚や離婚のどちらかである配偶者の有無を、•。 •アドレス（同じような組成物は言語定義である）。 （特徴モデリングオプション機能に似ています）のアドレスにオプションのState属性を•。 |
| The code also shows a reference: a WaitingLine refers to any number of Persons. | コードは、参照を示しています。WaitingLineは人の任意の数を指します。 |
| Note however that an important ingredient for making DSLs work in practice is the domain-specific concrete syntax. None of the approaches mentioned in this section provide customizable syntax. However, approaches like Clafer are a very interesting backend for DSLs, to support analysis, validation and automatic creation of valid programs from partial configurations. | しかしDSLは、実際に働く作るための重要な成分は、ドメイン固有の具体的な構文であることに注意してください。このセクションに記載されているアプローチのいずれも、カスタマイズ可能な構文を提供していません。しかし、Claferようなアプローチは、分析、検証、部分的な構成から有効なプログラムの自動作成をサポートするために、DSLのための非常に興味深いのバックエンドである。 |
| 21.5 Conceptual Mapping from PLE to DSLs | |
| This section looks at the bigger picture of the relationship between PLE and DSLs. It contains a systematic mapping from the core concepts of PLE to the technical space of DSLs. First we briefly recap the core PLE concepts. | このセクションでは、PLEおよびDSLの関係の全体像を見る。これは、DSLの技術的な空間にPLEの中核となる概念から体系的なマッピングが含まれています。まず、簡単にコアPLE概念をおさらい。 |
| Core Assets designate reusable artifacts that are used in more than one product. As a consequence of their strategic relevance, they are usually high quality and maintained over time. Some of the core assets might have variation points. | コア資産は複数の製品で使用されている再利用可能な成果物を指定する。彼らの戦略的な関連性の結果として、彼らは通常、時間をかけて、高品質で維持されます。中核資産の中には、変化点があるかもしれません。 |
| A Variation Point is a well-defined location in a core asset where products differ from one another. | |
| Kind of Variability classifies the degrees of freedom one has when binding the variation point. This ranges from setting a simple Boolean flag, through specifying a database URL or a DSL program, to a Java class hooked into a platform framework. | 変動性の種類は、変化点をバインドするときに1が持つ自由度を分類します。これは単純なブールフラグを設定することから、プラットフォームのフレームワークにフックのJavaクラスに、データベースURLまたはDSLプログラムを指定することによって範囲である。 |
| Binding Time denotes the point in time when the decision is made as to which alternative should be used for a variation point. Typical binding times include source time (changes to the source code are required), load time (bound when the system starts up) and runtime (the decision is made while the program is running). | 代替的には変化点のために使用されるべきかについての決定が行われたときに時間をバインドする時点を表す。代表的な結合時間は、ソースタイム（ソースコードの変更が必要）、ロード時間（システムの起動時にバインドされた）およびランタイムを（プログラムの実行中に決定が下されている）が含まれる。 |
| The Platform is those core assets that actually form a part of the running system. Examples include libraries, frameworks or middleware. | プラットフォームは、実際には、実行中のシステムの一部を構成するもの中核資産である。例としては、ライブラリ、フレームワークやミドルウェアが含まれています。 |
| Production Tools are core assets that are not part of the platform, but which are used during the (possibly) automated development of products. | 制作ツールは、プラットフォームの一部ではないコア資産でありますが、製品の（おそらく）自動化された開発中に使用されている。 |
| Domain Engineering refers to activities in which the core assets are created. An important part of domain engineering is domain analysis, during which a fundamental understanding of the domain, its commonalities and variability is established. | ドメインエンジニアリング、コア資産が作成された活動を指します。ドメインエンジニアリングの重要な部分は、ドメイン、その共通性と変動の基本的な理解が確立されている間、ドメイン分析である。 |
| Application Engineering is the phase in which the domain engineering artifacts are used to create products. Unless variation points use runtime binding, they are bound during this phase. | アプリケーション·エンジニアリングドメインエンジニアリングアーティファクト製品を作成するために使用される相である。変化点は、実行時バインディングを使用しない限り、それらはこのフェーズの間にバインドされています。 |
| The Problem Space refers to the application domain in which the product line resides. The concepts found in the problem space are typically meaningful to non-programmers as well. | 問題のスペースは、製品ラインが存在するアプリケーションドメインを指します。問題空間で見つかった概念は、典型的には、非プログラマにとって有意義にもある。 |
| The Solution Space refers to the technical space that is used to implement the products. In the case of software product line engineering, this space is software development. The platform lives in the solution space. The production tools create or adapt artifacts in the solution space based on a specification of a product in the problem space. | 解空間は、製品を実装するために使用される技術的な空間を意味する。ソフトウェアプロダクトライン工学の場合、このスペースは、ソフトウェアの開発である。プラットフォームは、解空間に住んでいます。制作ツールは、問題空間における製品の仕様に基づいて解空間での成果物を作成したり、適応させる。 |
| In the following sections we now elaborate on how these concepts are realized when DSLs are used. | 以下のセクションでは、今のDSLを使用する場合、これらの概念が実現されるかについて詳しく説明。 |
| 21.5.1 Variation Points and Kinds of Variability | |
| DSL programs can either be transformed to executable code or interpreted. This maps to the binding times introduced above in the following way: • If we generate source code that has to be compiled, packaged and deployed, the binding time is source. We speak of static variability, or static binding. • If the DSL programs are interpreted, and the DSL programs can be changed as the system runs, this constitutes runtime binding, and we speak of dynamic variability. • If we transform the DSL program into another formalism that is then interpreted by the running system, we are in the middle ground. Whether the variability is load-time or runtime depends on the details of how and when the result of the transformation is (re-)loaded into the running system. | DSLプログラムは、いずれかの実行可能コードに変換又は解釈することができる。これは、次のように上に導入されたバインディング回にマップされます。 我々は、コンパイル済みのパッケージ化およびデプロイする必要があるソースコードを生成する場合•、結合時間はソースです。私たちは、静的なばらつきについて話す、または結合スタティック。 DSLのプログラムが解釈され、およびDSLプログラムは、システムの実行時に変更することができれば•、これは実行時バインディングを構成し、我々は、動的な変動話す。 我々はそれから実行しているシステムによって解釈されている別の形式主義に、DSLプログラムを変換した場合•我々は妥協点である。変動性は、ロード時または実行時にはいつどのように変換の結果が（再）は、実行中のシステムにロードされるの詳細に依存するかどうか。 |
| 21.5.5 Core Assets, Platform and the Production Tools | |
| DSLs constitute core assets; they are used for many, and often all, of the products in the product line. It is however not easy to answer the question of whether they are part of the platform or the production tools: • If the DSL programs are transformed, the transformation code is a production tool; it is used in the production of the products. The DSL or the models are not part of the running system. • In the case of interpretation, the interpreter is part of the platform. Since it directly works with the DSL program, the language definition becomes a part of the platform as well. • If we can change the DSL programs as the system runs, even the IDE for the DSL is part of the platform. • If the DSL programs are transformed into another formalism that is in turn interpreted by the platform, then the transformations constitute production tools, and the interpreter of the target formalism is a part of the platform. | DSLはコア資産が構成され、それらは製品ラインの製品のため、多くの場合、すべての多くに使用され、。それは彼らがプラットフォームや制作ツールの一部であるかどうかの質問に答えるためにしかし簡単ではありません。 DSLプログラムが形質転換された場合•、変換コードは、生産ツールであり、それは製品の製造に使用される。 DSLまたはモデルは、実行中のシステムの一部ではありません。 •解釈の場合には、インタプリタはプラットフォームの一部である。それが直接のDSLプログラムで動作しているため、言語の定義は、同様に、プラットフォームの一部となります。 システムが動作するように我々は、DSLプログラムを変更することができれば•、DSLのためにも、IDEは、プラットフォームの一部です。 •DSLプログラムはプラットフォームによって解釈次に別の形式主義に変換される場合、変換は、生産ツールを構成し、ターゲット形式主義のインタプリタはプラットフォームの一部である。 |
コメントをかく