20 DSLs in the Implementation
最終更新：
twoflat1017 2013年12月15日(日) 18:00:13履歴
| 20 DSLs in the Implementation | |
| In this chapter we discuss the use of DSLs in the context of software implementation, based on an extensive case study in embedded software development: the mbeddr system that has been discussed in the book before. mbeddr supports extension of C with constructs useful for embedded software. In this chapter we show how language extension can address the challenges of embedded software development, and report on our experience in building these extensions. | 前本の中で議論されてきたmbeddrシステム：この章では、組込みソフトウェア開発における豊富なケーススタディに基づいてソフトウェアの実装のコンテキストでのDSLの使用を議論する。 mbeddrは、組込みソフトウェアのための便利な構文を持つCの拡張をサポートしています。この章では、言語拡張が組込みソフトウェア開発の課題に対応し、これらの拡張機能を構築する上で我々の経験を報告する方法を示しています。 |
| This section of the book is based on a paper written together with Daniel Ratiu, Bernd Kolb and Bernhard Schaetz for the SPLASH/Wavefront 2012 conference. | 本書のこのセクションでは、SPLASH/ Wavefrontの2012会議のためにダニエル·Ratiu、ベルント·コルブとベルンハルトSchaetzと一緒に書かれた紙の上に基づいています。 |
| 20.1 Introduction | |
| In this section we discuss the use of DSLs in the context of implementation. There it is crucial that the DSLs are tightly integrated with the application code that is typically written in a GPL. Language embedding and extension (Section 4.6) are obviously useful approaches. In this chapter we discuss the mbeddr system which supports domain-specific extensions to C. The amount of software embedded in devices is growing and the development of embedded software is challenging. In addition to functional requirements, strict operational requirements have to be fulfilled as well. These include reliability (a device may not be accessible for maintenance after deployment), safety (a system may endanger life or property if it fails), efficiency (the resources available to the system may be limited) or real-time constraints (a system may have to run on a strict schedule prescribed by the system’s environment). Addressing these challenges requires any of the following: abstraction techniques should not lead to excessive runtime overhead; programs should be easily analyzable for faults before deployment; and various kinds of annotations, for example for describing and type checking physical units, must be integrated into the code. Process issues such as requirements traceability have to be addressed, and developers face a high degree of variability, since embedded systems are often developed in the context of product lines. | このセクションでは、実装のコンテキストでのDSLの利用について説明します。そこには、 DSLのは、しっかりと、通常のGPLで書かれているアプリケーションコードと統合されていることが重要です。言語の埋め込みと拡張子（セクション4.6 ）は、明らかに有益なアプローチである。この章では、 Cに、ドメイン固有の拡張機能をサポートしているmbeddrシステムを議論 機器に組み込まれたソフトウェアの量が増加している組込みソフトウェアの開発が困難である。機能要件に加えて、厳格な動作要件も同様に満たされなければならない。これらには、信頼性（装置が導入後のメンテナンスのためにアクセスできない場合があります） 、安全性（それが失敗した場合に、システムが生命や財産を危険にさらす可能性があり） 、効率（システムで利用可能なリソースが制限される場合があります）、またはリアルタイムの制約（システムを含む）システムの環境によって規定され、厳格なスケジュールで実行する必要があります。これらの課題に対処するには、次のいずれかが必要です。抽象化の技術は、過剰な実行時のオーバーヘッドを招くべきではありませんが。 プログラムは、展開の前に、障害のために容易に分析可能であるべきです。 と記述すると型、物理単位をチェックするなどの注釈の様々な種類が、コードに統合する必要があります。このような要件のトレーサビリティのようなプロセスの問題に対処する必要があり、組み込みシステムは、多くの場合、製品ラインの文脈で開発されているので、開発者は、高度の可変性に直面する。 |
| Current approaches for embedded software development can be divided roughly into programming and modeling. The programming approach mostly relies on C, sometimes C++, and Ada in rare cases. However, because of C’s limited support for defining custom abstractions, this can lead to software that is hard to understand, maintain and extend. Furthermore, C’s ability to work with very low-level abstractions, such as pointers, makes C code very expensive to analyze statically. The alternative approach uses modeling tools with automatic code generation. The modeling tools provide predefined, higherlevel abstractions such as state machines or data flow component diagrams. Example tools include ASCET-SD or Simulink. Using higher-level abstractions leads to more concise programs and simplified fault detection using static analysis and model checking (for example using the Simulink Design Verifier). Increasingly, DSLs are used for embedded software, and studies show that DSLs substantially increase productivity in embedded software development. However, most real-world systems cannot be described completely and adequately with a single modeling tool or DSL, and the integration effort between manually written C code and perhaps several modeling tools and DSLs becomes significant. | 組込みソフトウェア開発のための現在の手法は、大きくプログラミングおよびモデリングに分けることができる。プログラミングのアプローチは、大部分が、まれに、C 、時々C + +、およびAdaのに依存しています。しかし、カスタム抽象化を定義するためのC言語の限定的なサポートのため、これは、理解し維持し、拡張することは困難であるソフトウェアにつながることができます。さらに、このようなポインタのような非常に低レベルの抽象化、 、で動作するように、Cの能力は静的に解析するためのCコードは非常に高価なものにする。別のアプローチは、自動コード生成とモデリングツールを使用しています。モデリングツールは、ステート·マシン、またはデータフローコンポーネント図などの事前に定義され、 higherlevel抽象化を提供します。例ツールは、 ASCET- SDまたはSimulinkのが含まれています。より高いレベルの抽象化を使用すると、 （例えばSimulinkのデザインの検証ツールを使用して）チェック静的解析とモデルを使用して、より簡潔なプログラムと単純化された障害検出につながる。ますます、 DSLは、組み込みソフトウェアに使用され、研究はDSLのは、実質的に組込みソフトウェア開発の生産性を向上させることを示している。しかし、ほとんどの実世界のシステムは、単一のモデリングツールやDSL 、および手動で書かれたCコードと、おそらくいくつかのモデリングツールとのDSLが顕著になる間の統合作業で完全にかつ適切に記述することはできません。 |
| A promising solution to this dilemma lies in much tighter integration between low-level C code and higher-level abstractions specific to embedded software. We achieve this with an extensible C programming language. The advantages of C can be maintained: existing legacy code can be easily integrated, reused, and evolved, and the need for efficient code is immediately addressed by relying on C’s low-level programming concepts. At the same time, domain-specific extensions such as state machines, components or data types with physical units can be made available as C extensions. This improves productivity via more concise programs, it helps improve quality in a constructive way by avoiding low-level implementation errors up front, and leads to system implementations that are more amenable to analysis. By directly embedding the extensions into C, the mismatch and integration challenge between domain-specific models and general-purpose code can be removed. An industry-strength implementation of this approach must also include IDE support for C and the extensions: syntax highlighting, code completion, error checking, refactoring and debugging. | このジレンマに対する有望な解決策は、低レベルのCコードと組み込みソフトウェアに特有の、より高いレベルの抽象化の間ずっと緊密な統合にある。私たちは、拡張可能なCプログラミング言語でこれを実現しています。 Cの利点を維持することができる。既存のレガシー·コードを簡単に統合され、再利用、および進化し、かつ効率的なコードの必要性は、すぐにCの低レベルのプログラミングの概念に依存することによって対処されることができます。 同時に、このような状態マシン、コンポーネントまたは物理ユニットとデータ型など、ドメイン固有の拡張はC拡張として利用可能にすることができる。これは、より簡潔なプログラムを経由して生産性を向上させ、それがアップフロントローレベルの実装のエラーを回避することにより、建設的な方法で、品質を向上させることができますし、分析により適しているシステムの実装につながる。直接Cへの拡張を埋め込むことによって、ドメイン固有のモデルと汎用コードとの間の不整合および統合の課題を除去することができる。構文の強調表示、コード補完、エラーチェック、リファクタリングやデバッグ：このアプローチの業界強度実装では、 IDEのCのサポートや拡張機能が含まれている必要があります。 |
| The LW-ES research project, run by itemis AG, fortiss GmbH, BMW Car IT and Sick AG explores the benefits of language engineering in the context of embedded software development with the mbeddr system. | itemis AGが実行LW-ESの研究プロジェクトは、社fortiss、BMWの車のITやシックAGはmbeddrシステムと組込みソフトウェア開発の文脈で言語工学の利点を探ります。 |
| 20.2 Challenges in Embedded Software | |
| In this section we discuss a set of challenges we address with the mbeddr approach. We label the challenges Cn so we can refer to them from Section 20.3.2, where we show how they are addressed by mbeddr. | このセクションでは、我々はmbeddrアプローチで取り組む課題のセットを議論する。私たちは、Cnはそう、我々は彼らがmbeddrによって対処される方法を示し、セクション20.3.2、からそれらを参照することができます挑戦にラベルを付ける。 |
| C1: Abstraction without Runtime Cost Domain-specific concepts provide more abstract descriptions of the system under development. Examples include data flow blocks, state machines, or data types with physical units. On one hand, adequate abstractions have a higher expressive power that leads to programs that are shorter and easier to understand and maintain. On the other hand, by restricting the freedom of programmers, domain-specific abstractions also enable constructive quality assurance. For embedded systems, where runtime efficiency is a prime concern, abstraction mechanisms are needed that can be resolved before or during compilation, and not at runtime. | C1：抽象化ランタイムなしで コストドメイン固有の概念は、開発中のシステムのより抽象的な記述を提供する。例としては、データフローブロック、ステートマシン、または物理的な単位でデータタイプを含む。一方では、適切な抽象化は短くし、理解し、保守が容易なプログラムにつながる、より高い表現力を持っている。一方、プログラマーの自由を制限することにより、ドメイン固有の抽象化も、建設的な品質保証を可能にする。実行時の効率が最大の関心事であり、組込みシステムのための、抽象化メカニズムは、前またはコンパイル時ではなく、実行時に解決することができるように必要としている。 |
| C2: C considered Unsafe While C is efficient and flexible, several of C’s features are often considered unsafe. Consequently, the unsafe features of C are prohibited in many organizations. Standards for automotive software development such as MISRA limit C to a safer language subset. However, most C IDEs are not aware of these and other, organization-specific restrictions, so they are enforced with separate checkers that are often not well integrated with the IDE. This makes it hard for developers to comply with these restrictions efficiently. | C2：Cみなさ安全でない Cは、効率的で柔軟性がありながら、Cの機能のいくつかは、多くの場合、安全でないと見なされます。その結果、Cの安全でない機能は多くの組織では禁止されています。このような、より安全な言語サブセットに対するMISRA限界Cなどの車載ソフトウェア開発のための標準規格。しかし、ほとんどのCのIDEは、これらおよび他の組織固有の制限を認識していないので、彼らはしばしば、十分IDEに統合されていない別々のチェッカーで実施されます。これは、ハード、開発者は効率的にこれらの制限を遵守するようになります。 |
| C3: Program Annotations For reasons such as safety or efficiency, embedded systems often require additional data to be associated with program elements. Examples include physical units, coordinate systems, data encodings or value ranges for variables. These annotations are typically used by specific, often custom-built analysis or generation tools. Since C programs can only capture such data informally as comments or pragmas, the C type system and IDE cannot check their correct use in C programs. They may also be stored separately (for example, in XML files) and linked back to the program using names or other weak links. | C 3：プログラム注釈 このような安全性や効率などの理由で、組込みシステムは、多くの場合、プログラム要素に関連付けられる追加データを必要とする。例としては、物理単位、座標系、データエンコーディングや変数の値の範囲を含む。これらのアノテーションは、通常、特定の、多くの場合、カスタムビルドの解析または生成ツールで使用されています。 Cプログラムのみのコメントやプラグマとして非公式にそのようなデータを取り込むことができますので、C言語の型システムとIDEは、Cプログラムでの正しい使用を確認することはできません。彼らはまた、（XMLファイルなどで）別々に保存することや名前やその他の弱いリンクを使用して、バックプログラムにリンクがあります。 |
| C4: Static Checks and Verification Embedded systems often have to fulfill strict safety requirements. Industry standards for safety such as ISO-26262, DO-178B or IEC-61508 demand that for high safety certification levels various forms of static analyses are performed on the software. These range from simple type checks to sophisticated property checks, for example by model checking. Since C is a very flexible and relatively weakly-typed language, the more sophisticated analyses are very expensive. Using suitable domain-specific abstractions (for example, state machines) leads to programs that can be analyzed much more easily. | C4：静的チェックと検証 組み込みシステムは、多くの場合、厳しい安全要件を満たさなければならない。このようなISO-26262などの安全のための業界標準、DO-178Bや安全性の高い認証レベルの静的解析の様々な形態がソフトウェア上で実行されていることを、IEC-61508の要求。これらは、モデル検査するなどして、単純型チェックから、洗練されたプロパティのチェックに及ぶ。 Cは非常に柔軟で比較的弱く型付けされた言語であるため、より洗練された分析は非常に高価です。適切なドメイン固有の抽象化を使用して（例えば、ステート·マシン）がはるかに容易に分析することができるプログラムをもたらす。 |
| C5: Process Support There are at least two cross-cutting and process-related concerns relevant to embedded software development. First, many certification standards (such as those mentioned above) require that code be explicitly linked to requirements such that full traceability is available. Today, requirements are often managed in external tools, and maintaining traceability to the code is a burden to the developers and often done in an ad hoc way, for example via comments. Second, many embedded systems are developed as part of product lines with many distinct product variants, where each variant consists of a subset of the (parts of) artifacts that comprise the product line. This variability is usually captured in constraints expressed over program parts such as statements, functions or states. Most existing tools come with their own variation mechanism, if variability is supported at all. Integration between program parts, the constraints and the variant configuration (for example via feature models) is often done through weak links, and with little awareness of the semantics of the underlying language. As a consequence, variant management is a huge source of accidental complexity. | C5 ：プロセスサポート 組込みソフトウェア開発に関連する少なくとも2横断的およびプロセス関連の懸念がある。まず、 （上述したような）は、多くの認証基準は、コードが明示的に完全なトレーサビリティが利用可能であることをこのような要求に連結されることを必要とする。今日では、要件は、多くの場合、外部ツールで管理され、コードへのトレーサビリティを維持することは、開発者への負担であり、多くの場合、コメントを経由して、たとえば、アドホックな方法で行われています。第二に、多くの組み込みシステムは、それぞれの変異体は、製品ラインを構成する成果物（の一部）のサブセットで構成され、多くの異なる商品バリエーションを持つ製品ラインの一部として開発されています。この変動は、通常、ステートメント、関数や状態などのプログラム部分の上に表現された制約でキャプチャされます。変動が全くサポートされている場合、ほとんどの既存のツールは、独自の可変機構が付属しています。プログラム部品、制約および（特徴のモデルを介して、例えば）バリアント構成間の統合は、多くの場合、弱いリンクを介して行われ、基盤となる言語の意味をほとんど意識しています。その結果、変異型管理は、偶発的な複雑さの巨大なソースです。 |
| An additional concern is tool integration. The diverse requirements and limitations of C discussed so far often lead to the use of a wide variety of tools in a single development project. Most commercial off-the-shelf (COTS) tools are not open enough to facilitate seamless and semantically meaningful integration with other tools, leading to significant accidental tool integration complexity. COTS tools often also do not support meaningful language extension, severely limiting the ability to define and use custom domain-specific abstractions. | 追加の懸念は、ツールの統合である。 Cの多様な要件と制限は、これまでのところ、多くの場合、単一の開発プロジェクトでの多種多様なツールの使用につながる議論した。ほとんどの商用（COTS）のツールが重要な偶発的なツール統合の複雑さにつながる、他のツールとのシームレスかつ意味的に意味のある統合を容易にするのに十分に開いていない。 COTSツールは、しばしば深刻なカスタムドメイン固有の抽象化を定義し、使用する能力を制限し、意味のある言語拡張をサポートしていません。 |
| 20.3 The mbeddr Approach | |
| Language engineering provides a holistic approach to solving these challenges. In this section we illustrate how mbeddr addresses the challenges with an extensible version of the C programming language, growing a stack of languages extensions (see Fig. 20.2, and Section 4.6.2 for a discussion of language extension). The following section explores which ways Wm of extending C are necessary to address the challenges Cn. Section 20.3.2 then shows examples that address each of the challenges and ways of extending C. | 言語工学はこれらの課題を解決するための総合的なアプローチを提供します。このセクションでは、（図20.2、および言語拡張の議論に関してセクション4.6.2を見てください）mbeddr言語拡張のスタックを成長、Cプログラミング言語の拡張可能なバージョンの課題に対処方法を示しています。次のセクションでは、Cを拡張するWMが課題をCNに対処するために必要であるかの方法探る。セクション20.3.2はその後Cを拡張する課題や方法の各対処例を示してい |
| The semantics of an extension are typically defined by a transformation back to the base language. For example, in an extension that provides state machines, these may be transformed to a switch/case-based implementation in C. Extensions can be stacked (Fig. 20.2), where a higher-level extension extends (and transforms back to) a lower-level extension instead of C. At the bottom of this stack resides plain C in text form, and a suitable compiler. Fig. 20.1 shows an example in which a module containing a component that contains a state machine is transformed to C, and then compiled. | 拡張子の意味は、一般的に、バックベース言語への変換によって定義されています。たとえば、ステートマシンを提供して拡張機能では、これらは、より高いレベルの拡張は拡張（とに戻す変換）A（図20.2）積載可能で拡張スイッチ/ケースベースの実装に変換してもよいこのスタックの下部には代わりにCの下位レベルの拡張は、テキスト形式で通常のC、および、適切なコンパイラを常駐。図。 20.1は、ステートマシンを含むコンポーネントを含むモジュールをCに変換し、その後コンパイルされた例を示している。 |
| As we have seen in Section 16.2, MPS supports modular language extension, as well as the use of independently developed language extensions in the same system. For example, in mbeddr a user can include an extension that provides state machines and an extension that provides physical units in the same program without first defining a combined language statemachine- with-units. This is very useful, because it addresses real world constraints: a set of organizations, such as the departments in a large company, will probably not agree on a single set of extensions to C, since they typically work in slightly different areas. Also, a language that contains all relevant abstractions would become big and unwieldy. Modular language extension solves these problems. | 我々は、セクション16.2で見てきたように、MPSはモジュラー言語拡張だけでなく、同じシステム内の独自に開発した言語拡張の使用をサポートしています。たとえば、mbeddrユーザーにステートマシンを提供し拡張し、第1の合成語ステートマシン付きのユニットを定義することなく、同じプログラム内の物理ユニットを提供拡張子を含めることができます。それは現実世界の制約に対処するため、これは非常に便利です。これらは一般的に、わずかに異なる領域では使え以来、このような大企業での部署などの組織、のセットは、おそらく、Cの拡張機能の単一のセットに同意しません。また、関連するすべての抽象化が含まれている言語は大きくて扱いにくくなるだろう。モジュラー言語拡張は、これらの問題を解決します。 |
| 20.3.1 Ways of Extending C | |
| In this section we discuss in which particular ways C needs to be extensible to address the challenges discussed above. | このセクションでは、特定の方法Cは、上述の課題に対処するために拡張可能である必要があるもので議論する。 |
| W1: Top-Level Constructs Top level constructs (on the level of functions or struct declarations) are necessary. This enables the integration of test cases or new programming paradigms relevant in particular domains, such as state machines, or interfaces and components. | W 1：トップレベルの構築 （関数や構造体宣言のレベルで）トップレベルの構造が必要である。これは、テストケースや、ステート·マシン、またはインターフェイスやコンポーネントなど、特定のドメイン内の関連する新しいプログラミングパラダイムの統合を可能にします。 |
| W2: Statements New statements, such as assert or fail statements in test cases, must be supported. Statements may have to be restricted to a specific context; for example, assert or fail statements must only be used in test cases and not in any other statement list. | W2：文 このようなテストケースでステートメントを主張するか、失敗するなどの新しいステートメントは、サポートされなければならない。ステートメントは、特定のコンテキストに制限する必要がある場合があり、例えば、他のステートメントリストに主張するか、ステートメントを失敗テストケースのみで使用する必要がありません。 |
| W3: Expressions New kinds of expressions must be supported. An example is a decision table expression that represents a two-level decision tree as a two-dimensional table (Fig. 20.4). | W3は：式 式の新しい種類がサポートされている必要があります。例は、二次元テーブル（図20.4）、2つのレベルの決定木を表す判定テーブル式である。 |
| W4: Types and Literals New types, e.g., for matrices, complex numbers or quantities with physical units, must be supported. This also requires the definition of new operators, and overriding the typing rules for existing ones. New literals may also be required: for example, physical units could be attached to number literals (as in 10kg). | W4：タイプとリテラル 新しいタイプは、例えば、行列の、物理的な単位との複素数や量は、サポートされなければならない。これはまた、新しい演算子の定義を必要とし、既存のもののために型付け規則をオーバーライド。新しいリテラルも必要になることがあります：例えば、物理単位は（10キロのように）数値リテラルに取り付けることができる。 |
| W5: Transformation Alternative transformations for existing language concepts must be possible. For example, in a module marked as safe, the expression x + y may have to be translated into an invocation of addWithBoundsCheck(x, y), an inline function that performs bounds-checking, besides the addition. | W5：トランスフォーメーション 既存言語の概念のための代替の変換が可能でなければならない。例えば、安全であるとマークされたモジュール内で、式x+ yはaddWithBoundsCheck（x、y）は、また他に、境界チェックを行うインライン関数の呼び出しに翻訳されていてもよい。 |
| W6: Meta Data Decoration It should be possible to add meta data, such as trace links to requirements or product line variability constraints, to arbitrary program nodes, without changing the concept of the node. | W6：メタデータデコレーション これは、ノードの概念を変更することなく、任意のプログラム·ノードに、そのような要件または製品ライン変動の制約トレースリンクなどのメタデータを追加することが可能であるべきである。 |
| W7: Restriction It should be possible to define contexts that restrict the use of specific language concepts. For example,the use of pointer arithmetic should be prohibited in modules marked as safe, or the use of real numbers should be prohibited in state machines that are intended to be model checked (model checkers do not support real numbers). | W7：制限 これは、特定の言語の概念の使用を制限するコンテキストを定義することが可能なはずである。例えば、ポインタ演算を使用することは安全だとマークされたモジュールでは禁止されるべきである、あるいは実数の使用は、モデルが（モデル検査は、実数をサポートしていない）をチェックされることを意図しているステートマシン厳禁。 |
| 20.3.2 Extensions Addressing the Challenges | |
| In this section we present example extensions that illustrate how we address the challenges discussed in Section 20.2. We show at least one example for each challenge. The table below shows an overview of the challenges, the section, and the ways of extension each example makes use of. | このセクションでは、我々は、セクション20.2で議論の課題に対処する方法を示して例の拡張機能を紹介します。私たちは、それぞれの挑戦のために少なくとも1例を示している。以下の表は、課題部の概要を示しており、伸長方法は各実施例では利用する。 |
| A Cleaned-Up C (addresses C2, uses W7) To make C extensible, we first had to implement C in MPS. This entails the definition of the language structure, syntax and type system. In the process we changed some aspects of C. Some of these changes are the first step in providing a safer C (challenge C2). Others changes were implemented, because it is more convenient to the user, or because it simplified the implementation of the language in MPS. Out of eight changes in total, four are for reasons of improved robustness and analyzability, two are for end-user convenience and three are to simplify the implementation in MPS. We discuss some of them below, and the table below shows a summary. | クリーンアップC C言語を拡張可能にする（アドレスC2は、W7を使用しています）、私たちはまず、MPSのCを実装する必要がありました。これは、言語の構造、構文と型システムの定義を必要とする。プロセスでは、これらの変更のいくつかは、より安全なC（チャレンジC2）を提供するための最初のステップであるCのいくつかの側面を変更しました。その他の変更は、それがユーザにとってより便利であるため、実装、またはそれは、MPSでの言語の実装を単純化しているためた。合計8個の変更のうち、4つが改善された堅牢性と分析可能性の理由のために、二つのエンドユーザーの便宜のためのものであり、三つMPSへの実装を簡素化することであるである。当社は、下記のうちのいくつかを議論し、以下の表では、概要が表示されます。 |
| mbeddr C provides modules (Fig. 20.3). A module contains the top-level C constructs (such as structs, functions or global variables). These module contents can be exported. Modules can import other modules, in which case they can access the exported contents of the imported modules. While header files are generated, we do not expose them to the user: modules provide a more convenient means of controlling modularizing programs and limiting which elements are visible globally. mbeddr C does not support the preprocessor. Empirical studies show that it is often used to emulate missing features of C in ad hoc way, leading to problems regarding maintenance and analyzability. Instead, mbeddr C provides first-class support for the most important use cases of the preprocessor. Examples include the modules mentioned above (replacing #include), as well as the support for variability discussed below (replacing #ifdefs). Instead of defining macros, users can create firstdsl class language extensions, including type checks and IDE support. Removing the preprocessor and providing specific support for its important use cases goes a long way in creating more maintainable and more analyzable programs. The same is true for introducing a separate boolean type and not interpreting integers as Booleans by default (an explicit cast operator is available). Type decorations, such as array brackets or the pointer asterisk, must be specified on the type, not on the identifier (int[] a; instead of int a[];). This has been done for reasons of consistency and to simplify the implementation in MPS: it is the property of a type to be an array type or a pointer type, not the property of an identifier. Identifiers are just names. | mbeddr Cはモジュール（図20.3 ）を提供します。モジュールは、 （このような構造体、関数やグローバル変数など）のトップレベルのC言語構文が含まれています。これらのモジュールの内容をエクスポートすることができます。モジュールは、彼らがimportされたモジュールのエクスポートされたコンテンツにアクセスすることができ、その場合、他のモジュールをインポートすることができます。ヘッダファイルが生成されますが、我々はそれらをユーザに公開していません。モジュールはモジュール化プログラムを制御し、要素がグローバルに見えるその制限のより便利な手段を提供します。 mbeddr Cプリプロセッサをサポートしていません。実証的研究は、それは、しばしば、メンテナンスや分析可能に関して問題をもたらすアドホックな方法でCの欠けている機能をエミュレートするために使用されることを示している。その代わりに、 mbeddr Cのプリプロセッサの中で最も重要なユースケースのための第一級のサポートを提供します。例としては、前述したモジュール（交換する＃完備）だけでなく、以下に説明する可変性のためのサポート（ ＃ ifdefをのを交換する）などがあります。代わりに、マクロを定義すると、ユーザーは型チェックとIDEサポートを含むfirstdslクラス言語拡張を、作成することができます。プリプロセッサを削除し、その重要なユースケースのための特定のサポートを提供する保守性とより多くの分析可能なプログラムを作成する際に長い道のりを行く。同じことは、別々のブール型を導入し、 （明示的なキャスト演算子が提供されています） 、デフォルトではbooleanとして整数を解釈しないにも当てはまります。このような配列のブラケットやポインタアスタリスクなどの装飾を、入力していない識別子（ INT []投稿タイプで指定しなければなりません。 intの代わりに[] ;) 。これは一貫性の理由で行われており、 MPSでの実装を簡素化するには、次のように、配列型またはポインタ型ではなく、識別子のプロパティである型のプロパティです。識別子は名前だけです。 |
| Decision Tables (addressing C1, uses W3) Decision tables are a new kind of expression, i.e. they can be evaluated. An example is shown in Fig. 20.4. A decision table represents nested if statements. It is evaluated to the value of the first cell whose column and row headers are true (the evaluation order is left to right, top to bottom). A default value (FAIL) is specified to handle the case in which none of the column/row header combinations is true. Since the compiler and IDE have to compute a type for expressions, the decision table specifies the type of its result values explicitly (int8). | ディシジョンテーブル 彼らは評価できる。すなわち、デシジョンテーブル式の新しい種類である（C1への対応、W3は使用しています）。例を図に示す。 20.4。デシジョンテーブルは、ネストされたIF文を表します。これは、列と行のヘッダーに該当する（評価順序を下へ右、上に任されている）最初のセルの値に評価されます。デフォルト値（FAIL）をカラム/行ヘッダーの組み合わせのいずれも該当しないた場合を処理するために指定されている。コンパイラとIDEは式のタイプを計算する必要があるため、デシジョンテーブルは、明示的にその結果値のタイプ（INT8）を指定します。 |
| Unit Tests (addresses C4, uses W1, W2) Unit tests are new top-level constructs (Fig. 20.5) introduced in a separate unittest language that extends the C core. They are like void functions without arguments. The unit test language also introduces assert and fail statements, which can only be used inside test cases. Testing embedded software can be a challenge, and the unit test extension is an initial step towards providing comprehensive support for testing. | ユニットテスト ユニットテストのCコアを拡張して別々のユニットテスト言語で導入された新しいトップレベルの構造（図20.5）である（アドレスはC4は、W2が、W1のを使用しています）。彼らは、引数なしで無効な機能のようなものです。ユニットテスト言語はまた、唯一のテストケースの内部で使用できる文を、アサート失敗が導入されています。組込みソフトウェアのテスト課題とし、ユニットテストの拡張子は、テストのための総合的なサポートを提供することに向かって最初のステップであることができます。 |
| Components (addresses C1, uses W1) are new top-level constructs that support modularization, encapsulation and the separation between specification and implementation (Fig. 20.6). In contrast to modules, a component uses interfaces and ports to declare the contract it obeys. Interfaces define operation signatures and optional pre- and post-conditions (not shown in the example). Provided ports declare the interfaces offered by a component; required ports specify the interfaces a component expects to use. Different components can implement the same interface differently. Components can be instantiated (also in contrast to modules), and each instance’s required ports have to be connected to compatible provided ports provided by other component instances. Polymorphic invocations (different components "behind" the same interface) are supported. | コンポーネント （アドレスC1は、W1は使用しています）は、モジュール化、カプセル化、仕様と実装の間の間隔（図20.6）をサポートする新しいトップレベルの構造である。モジュールとは対照的に、コンポーネントは、それが従うの契約を宣言するためのインタフェースおよびポートを使用しています。インターフェイスは操作シグネチャと（例には示されていない）任意の事前および事後条件を定義する。提供のポートは、コンポーネントが提供するインターフェースを宣言し、必要なポートは、コンポーネントが使用する予定のインターフェイスを指定します。異なるコンポーネントが異なる同じインターフェイスを実装することができます。成分は、（また、モジュールとは対照的に）インスタンス化することができ、各インスタンスの必要なポートが他のコンポーネントのインスタンスによって提供互換設けられたポートに接続されなければならない。多型の呼び出し（同じインターフェイスの「背後」は、異なる成分）がサポートされています。 |
| State Machines (addresses C1, C4, uses W1, W2) State machines provide a new top-level construct (the state machine itself), as well as a trigger statement to send events into state machines (see Fig. 20.7). State machines are transformed into a switch/case-based implementation in the C program. Entry, exit and transition actions may only access variables defined locally in state machines and fire out events. Out events may optionally be mapped to functions in the surrounding C program, where arbitrary behavior can be implemented. In this way state machines are semantically isolated from the rest of the code, enabling them to be model checked: if a state machine is marked as verifiable, we also generate a representation of the state machine in the input language of the NuSMV model checker, including a set of property specifications that are verified by default. Examples include dead state detection, dead transition detection, non-determinism and variable bounds checks. In addition, users can specify additional highlevel properties based on the well-established catalog of temporal logic properties patterns. The state machines extension also supports hierarchical states as a further means of decomposing complex behavior. | ステートマシン ステートマシン（ 20.7図を参照）のステートマシンにイベントを送信するために新しいトップレベル構築物（ステート·マシン自体）だけでなく、トリガー·ステートメントを提供（アドレスC1、C4は、 W2が、 W1のを使用しています） 。ステート·マシンは、 Cプログラムのスイッチ/ケースベースの実装に変換されます。入り口、出口、遷移アクションはステート·マシンでローカルに定義された変数にアクセスして、イベントを射撃できる。アウトイベントは、必要に応じて任意の行動を実現することができる周囲のCプログラム内の関数にマッピングすることができる。このようにして、ステートマシンは、意味論的モデルを確認することができるようにすること、コードの残りの部分から分離されている：状態マシンはとして検証可能マークされている場合、我々はまた的かつ強力モデルチェッカの入力言語ステートマシンの表現を生成するデフォルトでは、検証されたプロパティの仕様のセットを含む。例としては、死んだ状態検出、死ん遷移検出、非決定論と変数の境界チェックが含まれています。さらに、ユーザーは時相論理特性パターンの老舗カタログに基づいて追加のハイレベルのプロパティを指定することができます。ステートマシンの拡張機能は、複雑な振る舞いを分解するさらなる手段として、階層的なステートをサポートしています。 |
| Physical Units (addresses C3, uses W4) Physical units are new types that specify a physical unit in addition to the data type (see Fig. 20.8). New literals support the specification of values for those types that include the physical unit. The typing rules for the existing operators (+, * or >) are overridden to perform the correct type checks for types with units. The type system also performs unit computations to deal correctly with unit computations (as in speed = length/time). | 物理単位 物理的な単位は、データ型に加えて、物理装置を指定する、新しいタイプ（図20.8を参照）（アドレスC3は、W4を使用する）。新しいリテラルは、物理的手段を備え、これらのタイプの値の仕様をサポートしています。既存の演算子（+、*または>）のための型付け規則は、ユニットとの種類に適したタイプチェックを実行する上書きされます。型システムはまた、（速度=長さ/時間のように）単位の計算で正しく対処する単位の計算を実行します。 |
| Requirements Traces (addresses C5, uses W6) Requirements traces are meta data annotations that link a program element to requirements, essentially elements in other models imported from requirements management tools. Requirements traces can be attached to any program element without that element’s definition having to be aware of this (see green (gray in print) highlights in Fig. 20.9 and in Fig. 20.22). | 要件トレース 要件トレースは、要件管理ツールからインポートした他のモデルでの本質的な要素、要件にプログラム要素をリンクするメタデータの注釈です（アドレスはC5は、W6を使用しています）。要件トレース（図20.9および図。20.22）で、印刷中のグレー（緑のハイライトを見てください）、その要素の定義は、これを意識することなく、任意のプログラム要素に付着させることができる。 |
| Presence Conditions (addresses C5 and W6) A presence condition determines whether the program element to which it is attached is part of a product in the product line25. A product is configured by specifying a set of configuration flags (expressed via feature models), and the presence condition specifies a Boolean expression over these configuration switches. Like requirements traces, presence conditions can be attached to any program element. Upon transformation, program elements whose presence condition evaluates to false for the selected product configuration are simply removed from the program (and hence will not end up in the generated binary). This program customization can also be performed by the editor, effectively supporting variant-specific editing. | プレゼンス条件 （アドレスC5及びW6）は、プレゼンス状態は、それが結合しているプログラム要素が製品line25における製品の一部であるか否かを判定する。製品は、（特徴のモデルを通して表現される）構成フラグのセットを指定することによって構成され、プレゼンス状態は、これらの構成スイッチ上のブール式を指定している。要件トレースと同様に、プレゼンス条件は、任意のプログラム要素に取り付けることができる。形質転換の際に、その存在状態、選択された製品の設定にfalseと評価されたプログラム要素には、単純にプログラムから削除されます（したがって、生成されたバイナリで終了しません）。このプログラムカスタマイズも有効変異体特異的な編集をサポートする、編集者によって行うことができる。 |
| Safe Modules (addresses C2, uses W5, W7) Safe modules help prevent writing risky code. For example, runtime range checking is performed for arithmetic expressions and assignments. To enable this, arithmetic expressions are replaced by function calls that perform range checking and report errors if an overflow is detected. As another example, safe modules also provide the safeheap statement, which automatically frees dynamic variables allocated inside its body (see Fig. 20.13). | セーフモジュール （アドレスC2は、W5、W7を使用しています）セーフモジュールは、危険なコードを記述することを防ぐのに役立ちます。例えば、実行時の範囲チェックは、算術式および割り当てが行われる。これを有効にするには、算術式がオーバーフローが検出された場合、範囲のチェックとレポートのエラーを実行する関数呼び出しに置き換えられます。別の例として、安全なモジュールも、自動的に（。20.13図を参照）、その体内に割り当てられた動的変数を解放safeheap文を、提供する。 |
| 20.3.3 Addressing the Tool Integration Challenge | |
| By building all languages (C, its extensions or any other DSLs) on top of MPS, the tool integration challenge is completely solved. All languages get an MPS-style IDE, including syntax highlighting, code completion, static error checking and annotation, quick fixes and refactorings, as well as a debugger (details see Section 15.2.5). Fig. 20.9 shows a screenshot of the tool, as we edit a module with a decision table, a state machine, requirements traces and presence conditions. | MPSの上にすべての言語（C、その拡張機能やその他のDSLを）構築することにより、ツール統合の課題が完全に解決されています。すべての言語は、構文の強調表示、コード補完、静的エラーチェックや注釈、迅速な修正やリファクタリングのほか、デバッガ（詳細はセクション15.2.5を参照）を含めて、MPS形式のIDEを取得。我々は意思決定表を持つモジュール、ステート·マシン、要件トレースおよびプレゼンスの条件を編集するFig.20.9は、ツールのスクリーンショットを示しています。 |
| 20.4 Design and Implementation | |
| This section discusses the implementation of mbeddr language extensions. We briefly discuss the structure of the C core language. The main part of this section discusses each of the ways Wm of extending C based on the extensions discussed in the previous section. | このセクションでは、mbeddr言語拡張の実装について説明します。我々は簡単にC型コア言語の構造を議論する。このセクションの主要部分は拡張C言語のWMは、前のセクションで説明した拡張子に基づいていくつかの方法それぞれについて説明します。 |
| 20.4.1 The mbeddr Core Languages | |
| C can be partitioned into expressions, statements, functions, etc. We have factored these parts into separate language modules to make each of them reusable without pulling in all of C. The expressions language is the most fundamental language. It depends on no other language and defines the primitive types, the corresponding literals and the basic operators. Support for pointers and user defined data types (enum, struct, union) is factored into the pointers and udt languages respectively. statements contains the procedural part of C, and the modules language covers modularization. Fig. 20.10 shows an overview of some of the languages and constructs. | Cは式、文、関数などに分割することができます 我々は、Cのすべての式の言語が最も基本的な言語であるに引っ張らずに、それぞれ再利用可能にするために別々の言語モジュールにこれらの部品を織り込んできた。それは他の言語に依存し、プリミティブ型は、対応するリテラルと基本的な演算子を定義しています。ポインタとユーザー定義データ型（列挙型、構造体、共用体）のサポートは、それぞれポインタとUDTの言語に織り込まれている。文は、Cの手続きの一部が含まれており、モジュールは言語がモジュール化をカバーしています。図。 20.10は、言語や構文のいくつかの概要を示しています。 |
| 20.4.2 Addressing W1 (Top-Level Constructs): Test Cases | |
| In this section we illustrate the implementation of the test case construct, as well as of the assert and fail statements available inside test cases. | このセクションでは、テストケース構造の実装を説明するだけでなく、アサートのようなテストケース内で使用可能なステートメントを失敗します。 |
| Structure Modules own a collection of IModuleContents, an interface that defines the properties of everything that can reside directly in a module. All top-level constructs such as Functions implement IModuleContent. IModuleContent extends MPS’ IIdentifierNamedConcept interface, which provides a name property. IModuleContent also defines a Boolean property exported that determines whether the respective module content is visible to modules that import this module. Since the IModuleContent interface can also be implemented by concepts in other languages, new top-level constructs such as the TestCase in the unittest language can implement this interface, as long as the respective language has a dependency on the modules language, which defines IModuleContent. The class diagram in Fig. 20.10 shows some of the relevant concepts and languages. | 構造 モジュールはIModuleContentsのコレクション、モジュール内に直接置くことができ、すべてのプロパティを定義するインターフェイスを所有している。そのような機能は、すべてのトップレベルの構築物は、IModuleContentを実装します。 IModuleContentはnameプロパティを提供し、MPS'IIdentifierNamedConceptインタフェースを拡張します。 IModuleContentは、それぞれのモジュールの内容は、このモジュールをインポートするモジュールに表示されるかどうかを判定し、エクスポートするブール型プロパティを定義します。 IModuleContentインターフェイスは、他の言語での概念で実現することができるので、このようなユニットテスト言語のテストケースとして、新しいトップレベルの構成であれば、それぞれの言語がIModuleContentを定義したモジュール言語に依存しているように、このインタフェースを実装することができます。図クラス図。 20.10は、関連する概念や言語のいくつかを示しています。 |
| Constraints A test case contains a StatementList, so any C statement can be used in a test case. StatementList becomes available to the unit test language through its dependency on the statements language. unittest also defines new statements: assert and fail. They extend the abstract Statement concept defined in the statements language. This makes them valid in any statement list, for example in a function body. This is undesirable, since the transformation of asserts into C depends on them being used in a TestCase. To enforce this, a can be child constraint is defined (Fig. 20.11). | 制約 テストケースは、文のリストが含まれているため、任意のCステートメントは、テストケースに使用することができる。文のリストは、文の言語への依存によって、ユニットテスト言語に利用可能になる。ユニットテストは、新しい文が定義されています。主張すると失敗します。これらは、文の言語で定義された抽象文の概念を拡張します。これは関数本体の例では、任意のステートメントのリストには、有効になります。 Cは、それらをテストケースに使用されているに依存への変換がアサートので、これは望ましくない。これを強制するために、できる子制約は（図20.11）で定義されている。 |
| Transformation The new language concepts in unittest are reduced to C concepts: the TestCase is transformed to a void function without arguments, and the assert statement is transformed into a report statement defined in the logging language. The report statement, in turn, it is transformed into a platform-specific way of reporting an error (console, serial line or error memory). Fig. 20.12 shows an example of this two-step process. | 変態 ユニットテストで新しい言語の概念は、Cの概念に縮小されています。テストケースを引数なしvoid関数に変換され、assert文は、ロギング言語で定義されたレポート文に変換されます。 REPORT文は、順番に、それはエラー（コンソール、シリアル回線またはエラーメモリ）を報告するプラットフォーム固有の方法に変換されます。図。 20.12は、この二段階法の一例を示している。 |
| 20.4.3 Addressing W2 (Statements): Safeheap Statement | |
| We have seen the basics of integrating new statements in the previous section where assert and fail extended the Statement concept inherited from the C core languages. In this section we focus on statements that need to handle local variable scopes and visibilities. We implement the safeheap statement mentioned earlier (see Fig. 20.13), which automatically frees dynamically allocated memory. The variables introduced by the safeheap statement must only be visible inside its body, and have to shadow variables of the same name declared in outer scopes (such as the a declared in the second line of the measure function in Fig. 20.13). | 私たちは、前のセクションのassertに新しい文を統合の基本を見てきましたし、Cコア言語から継承した声明の概念を拡張し失敗します。このセクションでは、ローカル変数のスコープと可視性を処理する必要がある文に焦点を当てています。私たちは、自動的に動的に割り当てられたメモリを解放し、前述のsafeheap声明（20.13図を参照）を実装します。 safeheap文によって導入された変数は、その本体内部に表示され、（例えば図1に対策機能の2行目で宣言された。20.13など）の外側のスコープで宣言された同じ名前の変数をシャドウするために必要。 |
| Structure The safeheap statement extends Statement. It contains a StatementList as its body, as well as a list of Safe- HeapVars. These extend LocalVarDecl, so they fit with the existing mechanism for handling variable shadowing (explained below). | 構造 safeheap文は、文を拡張します。それは、その本体だけでなく、安全·HeapVarsのリストとして文のリストが含まれています。これらはLocalVarDeclを拡張するので、（後述）変数シャドウイングを処理するための既存のメカニズムとフィットします。 |
| Behavior LocalVarRefs are expressions that reference a LocalVarDecl. A scope constraint determines the set of visible variables for a given LocalVarRef. We implement this constraint by plugging into mbeddr’s generic local variable scoping mechanism using the following approach. The constraint ascends the containment tree until it finds a node which implements ILocalVarScopeProvider, and calls its getLocalVarScope method. A LocalVarScope has a reference to an outer scope, which is set by finding its ILocalVarScopeProvider ancestor, effectively building a hierarchy of LocalVarScopes. To get at the list of the visible variables, the LocalVarRef scope constraint calls the getVisibleLocalVars method on the innermost LocalVarScope object. This method returns a flat list of LocalVarDecls, taking into account that variables owned by a LocalVarScope that is lower in the hierarchy shadow variables of the same name from a higher level in the hierarchy. So, to plug the SafeHeapStatement into this mechanism, it has to implement ILocalVarScopeProvider and implement the two methods shown in Fig. 20.14. | 行動 LocalVarRefsはLocalVarDeclを参照する式です。有効範囲制約は、指定されたLocalVarRefすることも可能変数のセットを決定します。我々は、次のアプローチを使用してmbeddrの汎用ローカル変数のスコープ機構内に差し込むことによって、この制約を実装しています。制約は、それがILocalVarScopeProviderを実装するノードが見つかるまで包含ツリーを上昇し、そのgetLocalVarScopeメソッドを呼び出します。 LocalVarScopeを効果LocalVarScopesの階層を構築し、そのILocalVarScopeProvider祖先を見つけることによって、設定されている外部スコープへの参照を持っています。目に見える変数のリストで取得するには、 LocalVarRefスコープ制約は、最も内側のLocalVarScopeオブジェクトのgetVisibleLocalVarsメソッドを呼び出します。このメソッドでは、考慮して、 LocalVarDeclsのフラットなリストを返す階層の上位レベルから、同じ名前の階層シャドウ変数が低いLocalVarScopeが所有する変数。したがって、この機構にSafeHeapStatementを接続するには、 ILocalVarScopeProviderを実装し、図に示した二つの方法を実装する必要があります。 20.14 。 |
| Type System To make the safeheap statement work correctly, we have to ensure that the variables declared and allocated in a safeheap statement do not escape from its scope. To prevent this, an error is reported if a reference to a safeheap variable is passed to a function. Fig. 20.15 shows the code. | 型システム 正しくsafeheap声明を機能させるために、我々は変数が宣言され、safeheap計算書に割り当てられ、その範囲から脱出しないようにする必要があります。 safeheap変数への参照が関数に渡された場合は、これを防ぐには、エラーが報告されている。図。 20.15のコードを示しています。 |
| 20.4.4 Addressing W3 (Expressions): Decision Tables | |
| Fig. 20.4 showed the decision table expression. It is evaluated to the expression in a cell c if the column header of c and the row header of c are true. If none of the condition pairs is true, then the default value, FAIL in the example, is used as the resulting value. A decision table also specifies the type of the value it will evaluate to, and all the expressions in content cells have to be compatible with that type. The type of the header cells has to be Boolean. | 図。20.4、デシジョン·テーブルの発現を示した。CとCの行ヘッダーの列ヘッダに該当する場合には、セルC中の式を評価されます。状態対のいずれもが真でない場合、デフォルト値は、実施例にFAIL、結果の値として使用される。デシジョンテーブルはまた、と評価された値の型を指定し、コンテンツセル内のすべての式は、その型と互換性がなければならない。ヘッダーセルの型はBooleanである必要があります。 |
| Structure The decision table extends the Expression concept defined in the expressions language. Decision tables contain a list of expressions for the column headers, one for the row headers and another for the result values. It also contains a child of type Type, to declare the type of the result expressions, as well as a default value expression. The concept defines an alias dectab to allow users to instantiate a decision table in the editor. | 構造 デシジョン·テーブルは、表現言語で定義された式の概念を拡張する。デシジョンテーブルは、列ヘッダー、行ヘッダー用と結果値のための別の計算式のリストが含まれています。また、結果式の種類だけでなく、デフォルト値の式を宣言するために、Type型の子供が含まれています。コンセプトは、ユーザーがエディタで意思決定表をインスタンス化することを可能にするエイリアスdectabを定義しています。 |
| Editor Defining a tabular editor is straightforward: the editor definition contains a table cell, which delegates to a Java class that implements ITableModel. This is similar to the approach used by Java Swing. It provides methods such as getValueAt( int row, int col) or deleteRow(int row), which have to be implemented for any specific table-based editor. To embed another node in a table cell (such as the expression in the decision table), the implementation of getValueAt simply returns the node (whose editor is then embedded in the table’s editor). | エディタ 表形式のエディタを定義することは簡単です。エディタの定義はITableModelを実装するJavaクラスに委譲し、表のセルが含まれています。これは、JavaのSwingで使用される手法に似ています。これは、任意の特定のテーブルベースのエディタのために実装しなければならないようなてgetValueAt（int型の行は、INT COL）またはdeleteRowを（int型の列）などのメソッドを提供します。 （このような意思決定表内の式のような）表のセル内の他のノードを埋め込むには、てgetValueAtの実装は単純に（その編集者、テーブルのエディタに組み込まれている）ノードを返します。 |
| Type System MPS uses unification in the type system. Language concepts specify type equations that contain type literals (such as boolean) as well as type variables (such as typeof (dectab)). The unification engine then tries to assign values to the type variables such that all applicable type equations become true. New language concepts contribute additional type equations. Fig. 20.16 shows those for decision tables. | 型システム MPSは型システムに統合を使用しています。言語の概念（例えば、ブールなど）型リテラルだけでなく、（このようなtypeof演算（dectab）のような）型変数を含む型の式を指定します。統一エンジンは、該当するすべてのタイプの式が真になるようなタイプの変数に値を代入しようとします。新しい言語の概念は、追加の型の方程式に貢献。図。 20.16は、デシジョンテーブルのものを示しています。 |
| 20.4.5 Addressing W4 (Types and Literals): Physical Units | |
| We use physical units to illustrate the addition of new types and literals. We have already shown example code earlier in Fig. 20.8. | 私たちは、新しい型やリテラルの追加を説明するために物理的な単位を使用。我々はすでに、以前の図のコード例を示している。 20.8。 |
| Structure Derived and convertible UnitDeclarations are IModuleContents. Derived unit declarations specify a name (mps, kmh) and the corresponding SI base units (m, s), plus an exponent; a convertible unit declaration specifies a name and a conversion formula. The backbone of the extension is the UnitType, which is a composite type that has another type (int, float) in its valueType slot, plus a unit (either an SI base unit or a reference to a UnitDeclaration). It is represented in programs as baseType/unit/. We also provide LiteralWithUnits, which are expressions that contain a valueLiteral and, like the UnitType, a unit (so we can write, for example, 100 kmh). | 構造 派生および転換UnitDeclarationsはIModuleContentsです。派生ユニットの宣言は、名前（MPS、KMH）と対応するSI基本単位（M、S）に加え、指数を指定します。変換可能ユニットの宣言は、名前と変換式を指定します。延長の骨格は、別のタイプ（INT、フロート）の値型スロットに加え、単位（SI基本単位またはUnitDeclarationへの参照のいずれか）を持つ複合型であるunittypeは、ある。それはをbaseType/ユニット/などのプログラムで表されます。またunittypeは、ユニットのようにvalueLiteralとし、（私たちは、例えば、毎時100キロを書くことができます）が含まれている式ですLiteralWithUnitsを提供します。 |
| Scoping LiteralWithUnits and UnitTypes refer to a UnitDeclaration, which is a module content. According to the visibility rules, valid targets for the reference are the UnitDeclarations in the same module, and the exported ones in all imported modules. This rule applies to any reference to any module content, and is implemented generically. Fig. 20.17 shows the code for the scope of the reference to the UnitDeclaration. We use an interface IVisibleNodeProvider, (implemented by Modules) to find all instances of a given type. The implementation of visibleContentsOfType searches through the contents of the current and imported modules and collects instances of the specified concept. The result is used as the scope for the reference. | スコーピング LiteralWithUnitsとUnitTypesは、モジュールコンテンツであるUnitDeclaration、を参照してください。表示規則によると、参照のために有効なターゲットは、同じモジュールにUnitDeclarations、およびインポートされたすべてのモジュールでエクスポートされたものです。この規則は、任意のモジュールの内容への参照に適用され、一般的に実装されています。図。 20.17はUnitDeclarationへの参照の範囲のコードを示します。私たちは、特定のタイプのすべてのインスタンスを検索する（モジュールによって実装された）インタフェースIVisibleNodeProviderを使用しています。 visibleContentsOfTypeの実装は現在、輸入のモジュールの内容を検索し、指定された概念のインスタンスを収集します。結果は、基準のスコープとして使用される。 |
| Type System We have seen how MPS uses equations and unification to specify type system rules. However, there is special support for binary operators that makes overloading for new types easy: overloaded operations containers essentially specify 3-tuples of (leftArgType, rightArgType, resultType), plus applicability conditions to match type patterns and decide on the resulting type. Typing rules for new (combinations of) types can be added by specifying additional 3-tuples. Fig. 20.18 shows the overloaded rules for C’s MultiExpression (the language concept that implements the multiplication operator *) when applied to two UnitTypes: the result type will be a UnitType as well, where the exponents of the SI units are added. While any two units can legally be used with * and / (as long as we compute the resulting unit exponents correctly), this is not true for + and -. There, the two operand types must be the same in terms of their representation in SI base units. We express this by using the following expression in the is applicable section: | 型システム 私たちは、 MPSは、型システムの規則を指定するには、方程式と統一をどのように使用するかを見てきました。オーバーロードされたオペレーションのコンテナは、基本的に型のパターンと一致し、結果の型を決定する（ leftArgType 、 rightArgType 、 resultTypeと）の3つ組、プラスの適用条件を指定したが、簡単に新しい型のオーバーロードになり二項演算子のための特別なサポートがあります。種類の新しい（の組み合わせ）のための型付け規則は、さらに3つのタプルを指定することで追加することができます。図。 20.18は、CのMultiExpression 2 UnitTypesに適用された場合（乗算演算子*を実装した言語の概念）のために、オーバーロードの規則を示しています。結果の型は、 SI単位の指数が追加されるだけでなくunittypeは、となります。 - 任意の2台は、合法的に*を使用し、 / （限り、我々が正確に生じた単位指数を計算するようにする）ことができるが、これは+とは当てはまりません。そこでは、 2オペランドの型は、 SI基本単位での表現という点で同じでなければなりません。私たちは、ある該当する項に次の式を使用してこれを表現する。 |
| In the operation type section we then compute the resulting unit type by adding the exponents of the components of the two unit types. | 操作タイプのセクションでは、2つのユニットの種類のコンポーネントの指数を追加することによって生じたユニットタイプを計算する。 |
| The typing rule for the LocalVariableDeclaration requires that the type of the init expression must be the same or a subtype of the type of the variable. To make this work correctly, we have to define a type hierarchy for UnitTypes. We achieve this by defining the supertypes for each UnitType: the supertypes are those UnitTypes whose unit is the same, and whose valueType is a supertype of the current UnitType’s value type. Fig. 20.19 shows the rule. | LocalVariableDeclarationための型付け規則は、初期化式の型は同じでも、変数の型のサブタイプでなければならないことを要求する。正しくこの仕事をするために、我々はUnitTypesの型階層を定義する必要があります。私たちは、それぞれのunittypeはのためのスーパータイプを定義することによってこれを達成：スーパータイプは、そのユニットと同じであり、そのvalueTypeは現在unittypeはの値型のスーパータイプであるものUnitTypesある。図。 20.19は、ルールを示しています。 |
| 20.4.6 Addressing W5 (Alternative Transformations): Range Checking | |
| The safemodules language defines an annotation to mark Modules as safe (we will discuss annotations in the next subsection). If a module is safe, the binary operators such as + or * are replaced with calls to functions that, in addition to performing the addition or multiplication, perform a range check. | safemodules言語は、セーフモジュールを（我々は次のサブセクションで、注釈を説明します）マークする注釈を定義します。モジュールが安全であるならば、このような+や*などの二項演算は加算や乗算を行うことに加えて、範囲チェックを実行し、関数の呼び出しに置き換えられます。 |
| Transformation The transformation that replaces the binary operators with function calls is triggered by the presence of this annotation on the Module which contains the operator. Fig. 20.20 shows the code. The @safeAnnotation != null checks for the presence of the annotation. MPS uses priorities to specify relative orderings of transformations, and MPS then calculates a global transformation order for any given model. We use a priority to express the fact that this transformation runs before the final transformation that maps the C tree to C text for compilation. | 変換は、関数呼び出しと二項演算子を置き換え変換はオペレータが含まれているモジュール上のこの注釈の存在によってトリガーされます。図。 20.20のコードを示しています。 @のsafeAnnotation！=注釈の存在をnullチェック。 MPSは変換の相対的な順序を指定するには、優先順位を使用し、MPSは、任意の与えられたモデルのための世界的な変換順序を計算します。我々は、この変換は、コンパイルのためにC言語のテキストにC言語のツリーをマッピングし、最終的な転換の前に実行されるという事実を表現するために優先順位を使用しています。 |
| 20.4.7 Addressing W6 (Meta Data): Requirements Traces | |
| Annotations are concepts whose instances can be added as children to a node N without this being specified in the definition of N’s concept. While structurally the annotations are children of the annotated node, the editor is defined the other way round: the annotation editor delegates to the editor of the annotated element. This allows the annotation editor to add additional syntax around the annotated element. We illustrate the annotation mechanism based on the requirements traces. As we discussed at the end of Section 20.3.2, a requirements trace establishes a link from a program element to a requirement. It is important that this annotation can be annotated to any node, independent of the concept of which it is an instance. As a consequence of the projectional approach, the program can be shown with or without the annotations, controlled by a global switch. Fig. 17.5 had shown an example. | 注釈は、そのインスタンスが、これはN個の概念の定義で指定されることなく、ノードNの子として追加することができた概念である。注釈付き要素の編集者への注釈エディタ委譲：構造的注釈は注釈付きノードの子であるが、編集者は他の方法でラウンドを定義されています。これは、注釈エディタは注釈付き要素の周りに追加の構文を追加することができます。私たちは、要件トレースに基づいてアノテーションのメカニズムを説明する。我々は、セクション20.3.2の最後に述べたように、要件のトレースは要求にプログラム要素からリンクを確立します。それは、この注釈は、それがインスタンスであるという概念とは無関係に任意のノードに注釈を付けることができることが重要である。 projectionalアプローチの結果として、プログラムは、グローバル·スイッチによって制御、または注釈なしで示すことができる。図。 17.5に例を示していた。 |
| Structure Fig. 20.21 shows the structure. Notice how it extends the MPS-predefined concept NodeAnnotation. It also specifies a role, which is the name of the property that is used to store TraceAnnotations under the annotated node. | 構造 図。 20.21の構造を示す。それは、MPS-事前に定義されたコンセプトNodeAnnotationを拡張していることに注目してください。また、注釈付きのノードの下にTraceAnnotationsを格納するために使用されるプロパティの名前です。役割を指定します。 |
| Editor In the editor annotations look as if they surrounded subconcepts). their parent node (although they are in fact children). Fig. 20.22 shows the definition of the editor of the requirements trace annotation (an example is shown in Fig. 20.9): it puts the trace to the right of the annotated node. Since MPS is a projectional editor, there is base-language grammar that needs to be made aware of the additional syntax in the program. This is key to enabling arbitrary annotations on arbitrary program nodes. | エディタ 彼らはサブコンセプトを囲んだかのように、エディタでの注釈）が見えます。彼らの親ノード（彼らは実際に子供にありますが）。図。 20.22は（。例を図20.9に示します）の要件トレースの注釈の編集者の定義を示していますが、注釈付きのノードの右にトレースを置きます。 MPSはprojectionalエディタであるので、プログラム内の追加の構文を認識される必要がベース言語文法がある。これは任意のプログラム·ノード上の任意の注釈を有効にするための鍵となります。 |
| Annotations are typically attached to a program node via an intention. Intentions are an MPS editor mechanism: a user selects the target element, presses Alt-Enter and selects Add Trace from the popup menu. Fig. 20.23 shows the code for the intention that attaches a requirements trace. | 注釈は、典型的には、意図を介して番組ノードに取り付けられている。意図は、MPSエディタメカニズムです：ユーザーがターゲット要素を選択し、Altキーを入力し、選択し、ポップアップメニューから[トレースを追加押す。図。 20.23は、要件のトレースを添付意思のコードを示します。 |
| 20.4.8 AddressingW7 (Restriction): Preventing Use of Real Numbers | |
| We have already seen in Section 20.4.2 how constraints can prevent the use of specific concepts in certain contexts. We use the same approach for preventing the use of real number types inside model-checkable state machines: a can be ancestor constraint in the state machine prevents instances of float in the state machine if the verifiable flag is set. | 我々はすでに制約が特定のコンテキストで特定の概念の使用を防止する方法をセクション20.4.2で見てきた。我々は、モデルチェック可能な状態マシン内部の実数型の使用を防止するために同じアプローチを使用しステートマシンで祖先制約することができる検証可能なフラグが設定されている場合、ステートマシンでフロートのインスタンスを防止する。 |
| 20.5 Experiences | |
| In Section 20.5.1 we provide a brief overview of our experiences in implementing mbeddr, including the size of the project and the efforts spent. Section 20.5.2 discusses to what degree this approach leads to improvements in embedded software development. | セクション20.5.1では、プロジェクトの規模と過ごしたの努力を含めmbeddrを実施中の経験の概要を説明します。セクション20.5.2は、このアプローチは、組み込みソフトウェア開発の改善につながるために何度も説明します。 |
| 20.5.1 Language Extension | |
| Size Typically, lines of code are used to describe the size of a software system. In MPS, a "line" is not necessarily meaningful. Instead we count important elements of the implementation and then estimate a corresponding number of lines of code. Fig. 20.24 shows the respective numbers for the core, i.e. C itself plus unit test support, decision tables and build/make integration (the table also shows how many LOC equivalents we assume for each language definition element, and the caption explains to some extent the rationale for these factors). According to our metric the C core is implemented with less than 10000 lines of code. Let us look at an incremental extension of C. The components extension (interfaces, components, pre- and post-conditions, support for mock components in testing and a generator back to plain C) is circa 3000 LOC equivalents. The state machines extension is circa 1000. Considering the fact that these LOC equivalents represent the language definition (including type systems and generators) and the IDE (including code completion, syntax coloring, some quick fixes and refactorings), this clearly demonstrates the efficiency of MPS for language development and extension. | サイズ 典型的には、コードの行は、ソフトウェアシステムのサイズを記述するために使用される。 MPSには、 「行」は、必ずしも意味がありません。代わりに、私たちは、実装の重要な要素をカウントして、コードの行数に対応する数を推定する。図。 20.24は、コア、すなわち、Cそのものに加え、ユニットテストのサポート、デシジョン·テーブルのためのそれぞれの数値を示しており、統合を行う/ビルドする（表はまた、我々は各言語の定義要素の前提とどのように多くのLOC同等示し、キャプションがある程度説明して論理的根拠これらの要因のために） 。当社の測定基準によると、Cコアはコードの10000未満のラインを用いて実装されています。私たちは、 C.コンポーネントの拡張機能（インタフェース、コンポーネント、事前条件と事後条件、テストでモックコンポーネントのサポートとバックプレーンなCまで発電機）の増分拡張を見てみましょうと、約3000のLOC当量である。ステートマシンの拡張は、 1000年ごろです。これらのLOC等価物（型システムと発電機を含む）言語定義と（コード補完など、構文の色分け、いくつかの簡単な修正とリファクタリング） IDEを表しているという事実を考えると、これは明らかに言語発達や拡張のため、MPSの効率性を実証している。 |
| Effort In terms of effort, the core C implementation has been circa 4 person months divided between three people. This results in roughly 2,500 lines of code per person month. Extrapolated to a year, this would be 7,500 lines of code per developer. According to McConnell, in a project up to 10,000 LOC, a developer can typically do between 2,000 and 25,000 LOC. The fact that we are at the low end of this range can be explained by the fact that MPS provides very expressive languages for DSL development: you don’t have to write a lot of code to express a lot about a DSL. Instead, MPS code is relatively dense and requires quite a bit of thought. Pair programming is very valuable in language development. Once a developer has mastered the learning curve, language extension can be very productive. The state machines and components extension have both been developed in about a month. The unit testing extension or the support for decision tables can be implemented in a few days. | 努力 努力の面では、コアCの実装では、3人の間で分割4人月ごろでした。これは人月あたりのコードの約2500行になる。年に外挿し、これにより、開発者ごとにコードの7500行になります。マコーネルによると、最大10,000 LOCのプロジェクトでは、開発者は一般的に2000と25000 LOCの間で行うことができます。あなたは、DSLについて多くのことを表現するために多くのコードを記述する必要はありません：我々は、この範囲の下限であるという事実は、MPSは、DSLの開発に非常に表現力豊かな言語を提供していますという事実によって説明できる。その代わりに、MPSコードは比較的緻密で、思考のかなりを必要とします。ペアプログラミングは、言語発達に非常に貴重なものです。開発者は、学習曲線をマスターした後は、言語拡張は、非常に生産することができます。ステートマシンとコンポーネントの拡張は、両方の約月に開発されている。ユニットテストの拡張機能や意思決定テーブルのサポートは数日で実現することができる。 |
| Language Modularity, Reuse and Growth Modularity and composition are central to mbeddr. Building a language extension should not require changes to the base languages. This requires that the extended languages are built with extension in mind. Just as in object-oriented programming, where only complete methods can be overridden, only specific parts of a language definition can be extended or overwritten. The implementation of the default extensions served as a test case to confirm that the C core language is in fact extensible. We found a few problems, especially in the type system, and fixed them. None of these fixes were "hacks" to enable a specific extension – they were all genuine mistakes in the design of the C core. Due to the broad spectrum covered by our extensions, we are confident that the current core language provides a high degree of extensibility. Independently developed extensions should not interact with each other in unexpected ways. While MPS provides no automated way of ensuring this, we have not seen such interactions so far. The following steps can be taken to minimize the risk of unexpected interactions. Generated names should be qualified to make sure that no symbol name clashes occur in the generated C code. An extension should never consume "scarce resources": for example, it is a bad idea for a new Statement to require a particular return type of the containing function, or change that return type during transformation. Two such badly designed statements cannot be used together, because they are likely to require different return types. | 言語モジュール性、再利用および成長 モジュール性と組成mbeddrの中心である。言語拡張を構築することは、ベースの言語を変更する必要はありません。これが必要です 拡張された言語は、念頭に置いて拡張子を使用して構築されていること。ただ唯一の完全なメソッドはオーバーライドすることができ、オブジェクト指向プログラミング、のように、言語定義の特定の部分だけを拡張したり上書きすることができます。既定の拡張の実装は、Cコア言語が実際の拡張可能であることを確認するためのテストケースを務めた。我々は、特に型システムでは、いくつかの問題を発見し、それらを修正しました。これらの修正プログラムはいずれも、特定の拡張子を有効にするには、 "ハック"なかった - 彼らは、Cコアのデザインのすべての本物のミスだった。原因私たちの拡張機能でカバー広いスペクトルのために、我々は、現在のコア言語は、拡張性の高い学位を提供していることを確信しています。独自に開発した拡張機能は、予期しない方法で互いに相互作用しないでください。 MPSは、これを保証する全く自動化された方法を提供していませんが、我々はこれまでのところ、そのような相互作用を見ていない。以下のステップは、予期しない相互作用の危険性を最小限にするために取ることができる。生成された名前はシンボル名の衝突が生成されたCコードで発生していないことを確認するために修飾する必要があります。拡張子は「希少な資源"を消費することはありません：例えば、それは新たな声明のために悪い考えです 含む関数の特定の戻り値の型を必要とする、または変換中にその戻り値の型を変更します。彼らは異なった戻り値の型を必要とする可能性が高いので、このような2つの悪いデザインのステートメントは、一緒に使用することはできません。 |
| Modularity should also support reuse in contexts not anticipated during the design of a language module. Just as in the case of language extension (discussed above), the languages to be reused have to be written in a suitable way so that the right parts can be reused separately. We have shown this with the state machines language. State machines can be used as toplevel concepts in modules (binding out-events to C functions), and also inside components (binding out-events to component methods). Parts of the transformation of a state machine have to be different in these two cases, and these differences were successfully isolated to make them exchangeable. Also, we reuse the C expression language inside the guard conditions in a state machine’s transitions. We use constraints to prevent the use of those C expression that are not allowed inside transitions (for example, references to global variables). Finally, we have successfully used physical units in components and interfaces. Summing up, these facilities allow different user groups to develop independent extensions, growing the mbeddr stack even closer towards their particular domain. | モジュール性、また言語モジュールの設計時に想定していなかっコンテキストで再利用をサポートする必要があります。ちょうど（上述）言語拡張の場合のように、再利用される言語は、権利の部分を別々に再利用できるように適切な方法で書かれなければならない。私たちは、ステートマシン言語でこれを示している。ステート·マシンは（ C関数へのアウトイベントを結合）モジュール内のトップレベル概念として使用され、また、内部の部品（アウトイベントコンポーネントメソッドへの結合）することができます。ステートマシンの変換の部分がこれらの2つの場合において異なることがあり、これらの差異は、それらを正常に交換可能なように単離した。また、我々は、ステート·マシンの遷移中のガード条件内部のC式言語を再利用します。我々は（グローバル変数への参照など）の遷移の中に許可されていないものCの式の使用を防止するための制約を使用しています。最後に、我々が正常にコンポーネントおよびインターフェースの物理単位を使用している。まとめると、これらの施設は、さまざまなユーザーグループがさらに近く、その特定のドメインに向けてmbeddrスタックの成長、独立した拡張機能を開発することができます。 |
| Who can create Extensions? mbeddr is built to be extended. The question is by whom. This question can be addressed in two ways: who is able to extend it from a skills perspective, and who should extend it? Let us address the skills question first. We find that it takes about a month for a developer with solid object-oriented programming experience to become proficient with MPS and the structures of the mbeddr core languages. Also, designing that requires practice and experience. So, from this perspective we assume that in any given organization there should be some guidance. a select group of language developers who build the extensions for the end users. Notice that such an organizational structure is common today for frameworks and other reusable artifacts. There is also the question of who should create extensions. One could argue that, as language development becomes simpler, an uncontrolled growth in languages could occur, ultimately resulting in chaos. This concern should be addressed with governance structures that guide the development of languages. The bigger the organization is, the more important such governance becomes. | 誰が拡張機能を作成することができますか？ mbeddrが延長されるように構築されています。問題は、誰によってである。この質問は、2つの方法で対処することができます。誰がスキルの観点からそれを拡張することが可能であり、誰がそれを拡張する必要がありますか？私たちは最初のスキルの問題に対処しましょう。我々は、 MPSとmbeddrコア言語の構造と習熟するために、固体のオブジェクト指向プログラミングの経験を持つ開発者のために約一ヶ月かかることがわかります。また、それを設計することは、実践と経験が必要です。だから、このような観点から、我々は任意の組織内のいくつかのガイダンスが必要であることを前提としています。エンドユーザー向けの拡張機能を構築言語の開発者のグループを選択。このような組織構造をフレームワークや他の再利用可能な成果物のために今日一般的であることに注意してください。拡張機能を作成する必要があります誰かという問題もあります。一つは、言語発達が簡単になるように、言語で制御されていない成長は最終的に混乱をもたらし、発生する可能性がある、と主張している可能性があります。この懸念は、言語の発展を導くガバナンス構造にお願いします。大きな組織では、より重要なガバナンスになり、である。 |
| 20.5.2 Improvements in Embedded Development | |
| In this section we discuss preliminary results of a real-world development project. The project develops the software for a smart meter system. A smart meter is an electrical meter that continuously records the consumption of electric power in a home and sends the data back to the utility for monitoring and billing. The particular software we develop will run on a 2-chip board (TI MSP-430 for metrology, another TI processor (tbd.) for the remaining application logic). Instead of the gcc compiler used in mbeddr by default, this project uses an IAR compiler. The software comprises circa 30,000 lines of mbeddr code, has several time-sensitive parts that require a low-overhead implementation, and will have to be certified by an independent body. The software is derived from an existing example smart meter meter system written in traditional C, and reuses existing artifacts such as header files and libraries. | このセクションでは、現実世界の開発プロジェクトの予備的な結果を議論する。プロジェクトは、スマートメーターシステムのためのソフトウェアを開発しています。スマートメーターは、継続的に家庭内の電力消費量を記録し、バックモニターや課金のためのユーティリティにデータを送信し、電気メーターです。我々は開発し、特定のソフトウェアが（計測、残りのアプリケーション·ロジックのための別のTIのプロセッサ（tbd.）のために、TI MSP-430）2チップボード上で実行されます。代わりに、デフォルトでmbeddrで使用gccコンパイラのために、このプロジェクトは、IARコンパイラを使用しています。ソフトウェアは、mbeddrコード30,000行年頃含み、低オーバーヘッドの実装を必要とするいくつかの時間に敏感な部品を持っており、独立した機関によって認定されなければならない。ソフトウェアは、従来のC言語で書かれた既存の例スマートメーターメータシステムに由来し、このようなヘッダファイルやライブラリなどの既存の成果物を再利用している。 |
| Why mbeddr? mbeddr was chosen to implement the smart meter for the following reasons. The project has to work with an existing code base which had no production-level quality. The code quality needed to be improved incrementally. So starting with the existing C code and then refactoring towards better abstractions seemed like a good idea. Also, as we will see below, the existing C extensions provided by mbeddr are a good match for what is needed in the smart meter (see below) . Finally, as the goal is to have the meter certified, testing the software is very important. By using the abstraction hence not an option. mechanisms provided by mbeddr, and by exploiting the ability to build custom extensions, testability can be improved significantly. In particular, hardware-specifics can be isolated, which enables testing without the actual target hardware. Also, mbeddr’s support for requirements traceability comes in handy for the upcoming certification. | なぜmbeddr？ mbeddrは、次の理由のためにスマートメーターを実装することにしました。プロジェクトは製品レベルの品質を有していなかった既存のコードベースで作業する必要があります。コードの品質を段階的に改善する必要がありました。だから、既存のCコードから始まり、その後、より良い抽象化に向けてリファクタリングすることは良い考えのように思えた。我々は、以下に見るように、また、mbeddrが提供する既存のCの拡張（下記参照）、スマートメーターに必要なもののために良い試合です。目標はメーターが認定を持つことであるように最後に、ソフトウェアをテストすることは非常に重要です。したがって抽象化しないオプションを使用して。 mbeddrによって提供されるメカニズム、およびカスタム拡張を構築する能力を活用することによって、テスト容易性を大きく向上させることができる。具体的には、ハードウェア仕様は実際のターゲットハードウェアなしの試験を可能にする、単離することができる。また、要件のトレーサビリティのためmbeddrのサポートは、今後の認定のために便利です。 |
| Using the Existing Extensions The smart meter uses the following default extensions: | |
| Components The smart meter uses components to improve the structure of the application, and to support different implementations of the same interface. This improves modularity and testability. Mocks components are used excessively for testing. | コンポーネント スマートメーターは、アプリケーションの構造を改善するために、同じインターフェイスの異なる実装をサポートするためのコンポーネントを使用しています。これはモジュール性とテストの容易性を向上させます。コンポーネントはテストのために過剰に使用されているモック。 |
| State Machines The smart meter communicates with its environment via several different protocols. So far, one of these protocols has been refactored to use a state machine. This has proven to be much more readable than the original C code. Components and state machines are combined, which allows decoupling message assembly and parsing from the application logic in the server component. | ステートマシン スマートメーターは、いくつかの異なるプロトコルを介し、その環境と通信します。これまでのところ、これらのプロトコルのいずれかは、ステートマシンを使用することがリファクタリングされている。これは非常に読みやすく、元のCコードよりもあることが証明されている。コンポーネントおよびステートマシンはデカップメッセージアセンブリおよびサーバーコンポーネントのアプリケーションロジックからの解析を可能にする、結合されます。 |
| Units A major part of the smart meter application logic performs computations on physical quantities (time [s], current [A] or voltage [V]). So mbeddr’s support for physical units comes in handy. The benefits of these extensions are mostly in type checking, using types with units also improves the readability and comprehensibility of the code. | 単位 スマートメータ·アプリケーション·ロジックの大部分は、物理量に対する計算を行う（時間[s]、電流[A]または電圧[V]）。だから、物理ユニットのmbeddrのサポートに便利です。これらの拡張機能の利点は、ユニットと型を使用すると、コードの可読性とわかりやすさが向上し、型チェックで大部分があります。 |
| Requirements Tracing The smart meter also makes use of requirements traces. During the upcoming certification process, these will be extremely useful for tracking if and how the customer requirements have been implemented. Because of their orthogonal nature, the traces can be attached to the new language concepts specifically developed for the smart meter. | 必要条件 スマートメーターをトレースすることも要件トレースを使用しています。今後の認証プロセス中に、これらの顧客の要件が実装されている場合には、どのように追跡するために非常に有用であろう。ため、その直交性のため、トレースは特にスマートメーター用に開発された新しい言語の概念に付着させることができる。 |
| Custom Extensions As part of the smart meter, so far mbeddr has been extended in the following ways: | カスタム拡張 スマートメーターの一環として、これまでのところmbeddrは、次の方法で拡張されています： |
| Registers The smart meter software makes extensive use of registers (metrology: access the sensor values, UART: send and receive data). This cannot be abstracted away easily due to performance/overhead constraints. In addition, some registers are special-purpose registers: when a value is written to such a register, a hardware-implemented computation is automatically triggered based on the value supplied by the programmer. The result of this computation is then stored in the register. To run code that works with these registers on the PC for testing, developers face two problems: first, the header files that define the addresses of the registers are not valid for the PC’s processor. Second, there are no special-purpose registers on the PC, so no automatic computations or other hardware-triggered actions would be triggered. This problem was solved with a language extension that supports registers as first-class citizens and supports accessing them from mbeddr-C code (see code below). | レジスタ スマートメーターソフトウェアは、レジスタの広範な使用（：センサ値にアクセスし、UART：データの送受信を計測学）を行う。これは、パフォーマンス/オーバーヘッドの制約のため、容易に抽象化することはできません。また、いくつかのレジスタは、専用のレジスタです。値は、レジスタに書き込まれると、ハードウェアで実装され、計算は自動的にプログラマが指定された値に基づいてトリガされます。この計算の結果は、レジスタに格納される。テスト用のPC上でこれらのレジスタで動作するコードを実行するには、開発者には2つの問題に直面している。 まず、レジスタのアドレスを定義するヘッダファイルは、PCのプロセッサは有効ではありません。第二に、そこにPC上で特別な汎用レジスタがありませんので、自動計算やその他のハードウェア·トリガアクションがトリガされないであろう。この問題は、第一級の市民としてのレジスタをサポートします（以下のコードを参照してください）mbeddr-Cコードからそれらにアクセスしてサポートする言語拡張で解決した。 |
| The extension also supports specifying an expression that performs the computation. When the code is translated for the real device, the real headers are included, and access to the registers is replaced with access to the constants defined in the header. In testing, structs are generated to hold the register data. Each write access to a register is replaced with a write access to the struct, and the expression that simulates the special purpose register is included in that assignment. | 延長も計算を実行する式を指定するサポートしています。コードは、実際のデバイス用に変換されると、実際のヘッダが含まれており、レジスタへのアクセスは、ヘッダで定義された定数へのアクセスに置き換えられます。テストでは、構造体は、レジスタのデータを保持するために生成される。各レジスタへの書き込みアクセスは、構造体への書き込みアクセスに置き換えられ、特殊目的レジスタをシミュレートし、その発現は、割り当てに含まれている。 |
| Interrupts Many aspects of the smart meter system are driven by interrupts. To integrate the component-based architecture used in the smart meter with interrupts, it is necessary to trigger component runnables (methods) via an interrupt. To this end, we have implemented a language extension that allows us to declare interrupts. In addition, the extension provides runnable triggers that express the fact that a runnable is triggered by an interrupt. The extension also provides a concept to assign an interrupt to a runnable during component instantiation. A check makes sure that each interrupt-triggered runnable has at least one interrupt assigned. | 割り込み スマートメータシステムの多くの側面は、割り込みによって駆動される。割り込みとスマートメーターで使用されるコンポーネント·ベースのアーキテクチャを統合するためには、割り込みを経由して、コンポーネントのランナブル（メソッド）をトリガすることが必要である。この目的のために、我々は、私たちは、割り込みを宣言することを可能にする言語拡張を実装している。また、拡張子が実行可能な割り込みによってトリガされているという事実を表現する実行可能なトリガーを提供します。拡張子は、コンポーネントのインスタンス化の際に実行可能に割り込みを割り当てるための概念を提供します。チェックは必ず各割り込みトリガ実行可能に割り当てられた少なくとも1割り込みを持っていることになります。 |
| Data Encoding As part of the communication protocol, data has to be encoded into messages. A language extension supports the definition of data structures, and generated code deals with constructing messages. In particular, the generated code deals with packed data (where data has sizes that are not multiples of 8 bits). Also, code that processes messages can be statically checked against the message structure definition, making this code much more robust (in particular if the message definitions are hanged). | データ符号化 通信プロトコルの一部として、データは、メッセージに符号化されなければならない。言語拡張は、データ構造の定義をサポートし、メッセージを構築して、コードのお得な情報を生成した。具体的には、生成されたコードは（データが8ビットの倍数でないサイズを持っている場合）、パックされたデータを扱う。また、メッセージを処理するコードは、静的にこのコードがはるかに堅牢（特にメッセージ定義が絞首刑にされている場合）こと、メッセージ構造の定義に照らしてチェックすることができます。 |
| Conclusions The mbeddr default extensions have proven extremely useful in the development of the smart meter. The fact that the extensions are directly integrated into C (as opposed to the classical approach of using external DSLs or separate modeling tools) reduces the hurdle of using higher-level extensions and removes any potential mismatch between DSL code and C code. Generating code from higher-level abstractions may introduce performance and resource consumption overhead. While we have not yet performed a systematic analysis of the overhead incurred by the mbeddr extensions, it is low enough to run the smart meter system on the hardware intended for it. Additional effort is required to integrate with existing legacy code. As a consequence of the projectional editor, we have to parse the C text (with an existing parser) and construct the MPS AST. mbeddr provides an importer for header files as a means of connecting to existing libraries. However, mostly as a consequence of C’s preprocessor, which allows all kinds of mischief to be done to otherwise well-structured C code, this importer is not trivial. For example, we currently cannot import all alternatives expressed by #ifdefs. Users have to specify a specific configuration to be imported (in the future, we will support importing of all options by mapping the #ifdefs to mbeddr’s product line variability mechanism). Also, header files often contain platform-specific keywords or macros. Since they are not supported by the mbeddr C implementation, these have to be removed before they can be imported. The header importer provides a regular expression-based facility to remove these platform specifics before the import. The smart meter project, which is heavily based on an existing code base, also drove the need for a complete source code importer (including .c files, not just header files), which we are currently in the process of developing. We have performed scalability tests and found that mbeddr scales to at least the equivalent of 100,000 lines of C code in the developed system. These tests were based on automatically generated sample code and measured editor responsiveness and transformation times. While there are certainly systems that are substantially larger, a significant share of embedded software is below this limit and can be addressed with mbeddr. | 結論 mbeddrのデフォルトの拡張子は、スマートメーターの開発に非常に有用であることが証明されています。 （外部DSLまたは個別のモデリングツールを使用する古典的なアプローチとは対照的に）拡張機能を直接Cに統合されるという事実は、より高いレベルの拡張機能を使用することのハードルを低減し、 DSLコードとCコードの間の潜在的な不整合を除去する。より高いレベルの抽象化からコードを生成すると、パフォーマンスを紹介し、消費のオーバーヘッドリソースがあります。我々はまだmbeddr拡張によるオーバーヘッドの体系的な分析を実行していないが、それはそれのために意図されたハードウェア上でスマートメーターシステムを実行するために十分に低い。付加的な努力は、既存のレガシー·コードと統合するために必要です。 projectionalエディタの結果として、我々は（既存のパーサー）のCテキストを解析して、MPSのASTを構築する必要があります。 mbeddrは既存のライブラリに接続する手段として、ヘッダファイルのインポートツールが用意されています。しかし、大部分がいたずらのすべての種類が他のよく構造化されたCコードに行うことができるようになり、Cのプリプロセッサの結果として、このインポーターは簡単ではありません。例えば、我々は現在、 ＃ ifdefをすることで発現される全ての選択肢をインポートすることはできません。ユーザーは、インポートする特定の設定を（将来的には、我々はの製品ラインの変動メカニズムをmbeddrには、＃ ifdefをマッピングすることで、すべてのオプションのインポートをサポートします）を指定する必要があります。また、ヘッダファイルは、多くの場合、プラットフォーム固有のキーワードやマクロが含まれています。これらはmbeddr Cの実装ではサポートされていないので、これらは、インポートする前に除去しなければならない。ヘッダ輸入業者は輸入前に、これらのプラットフォームの仕様を削除するための正規表現ベースの機能を提供します。重く既存のコードベースに基づいているスマートメータープロジェクトは、 、また、我々が開発するプロセスに現在ある、 （ 。 Cファイルだけヘッダファイルではない含む）の完全なソースコードのインポートツールの必要性を運転した。私たちは、スケーラビリティテストを実施し、 mbeddrが開発したシステムでのCコード10万行のうち少なくとも同等まで拡張することを見出した。これらのテストは、自動的に生成されたサンプルコードに基づいて、エディタの応答性と変換の時間を測定した。実質的に大きいシステムでは確かにありますが、組込みソフトウェアのかなりのシェアがこの制限を下回っているとmbeddrで対処することができる。 |
| 20.6 Discussion | |
| Why MPS? Our choice of MPS is due to its support for all aspects of language development (structure, syntax, type systems, IDE, transformations), its support for flexible syntax as a consequence of projectional editing, and its support for advanced modularization and composition of languages. The ability to attach annotations to arbitrary program elements without a change to that element’s definition is another strong advantage of MPS (we we use this for presence conditions and trace links, for example). While the learning curve for MPS is significant (a developer who wants to become proficient in MPS language development has to invest at least a month), we found that it scales extremely well for larger and more sophisticated languages. | なぜMPS？ MPSの我々の選択は、言語発達のあらゆる側面への支援によるものである（構造、構文、型システムは、IDE、トランスフォーメーション）、projectional編集の結果として柔軟な構文のサポート、高度なモジュール化や言語の構成のサポート。その要素の定義を変更せずに、任意のプログラム要素に注釈を添付する機能は、MPSの別の強力な利点（我々は例えば、プレゼンス条件やトレースのリンクのためにこれを使用します）です。 MPSのための学習曲線は重要ですが（MPS言語開発に堪能になることを望んでいる開発者は、少なくとも月に投資することがある）、我々はそれがより大きく、より洗練された言語のために非常によくスケールすることを見出した。 |
| Projectional Editing Projectional editing is often considered a drawback, because the editors feel somewhat different and the programs are not stored as text, but as a tree (XML). We have already highlighted the fact that MPS does a good job regarding the editor experience, and we feel that the advantages of projectional editors regarding syntactic freedom far outweigh the drawback of requiring some initial familiarization. Our experience so far with about ten users (pilot users from industry, students) shows that after a short guided introduction of about 30 minutes, and an initial accommodation period (circa 1-2 days), users can work productively with the projectional editor. Regarding storage, the situation is not any worse than with current modeling tools that store models in a non-textual format, and MPS does provide good support for diff and merge using the projected syntax. | Projectional編集 Projectional編集は、多くの場合、編集者は多少異なる感じ、プログラムがテキストとして格納されていないため、欠点と考えられますが、木（XML）のようになる。我々はすでに、MPSは、エディタでの経験について、良い仕事をしているという事実を強調している、と我々は構文上の自由に関するprojectional編集者の利点ははるかにいくつかの初期の習熟を必要とするという欠点を上回ると感じています。約10人のユーザー（産業からのパイロットユーザー、学生）とのこれまでの我々の経験では、約30分の短いガイド付き導入、（2日年頃）は、初期の収容期間の後、ユーザーがprojectionalエディタで生産的に作業できることを示している。ストレージに関しては、状況は非テキスト形式でモデルを保存し、MPSは差分のための優れたサポートを提供し、予想の構文を使用してマージしない現在のモデリングツールと比べてどんな悪いことではありません。 |
| Feasibility of Language Extension Based on the experience with the smart meter, the effort for building extensions is reasonable. For example, the implementation of the language extensions for registers (and the simulation for testing) was done in half a day. The addition of interrupts, interrupt-trig-gered runnables and the way to "wire them" up was circa one day. Building a language extension should not require changes to the base language. The extensions for the smart meter demonstrate this point. The registers extension discussed above has been built without changing the underlying C language. Similarly, the interrupt-based runnable triggers have been hooked into the generic trigger facility that is part of the components language. Once a language is designed in a reasonable way, the language (or parts of it) should be reusable in contexts that have not been specifically anticipated in advance. The smart meter system contains such examples: expressions have been embedded in the register definition concept for emulating the hardware behavior, and types with units have been used in decision tables. Again, no change to the existing languages has been necessary. One criticism that has been used against language extension is that the language will grow large and that it is hard for users to learn all its constructs. In our experience, this is not a problem in mbeddr for the following three reasons: first, the extensions provide linguistic abstractions for concepts that are well known to the users: state-based behavior, interfaces and components or test cases. Second, the additional language features are easily discoverable because of the IDE support. Third, and most important, these extensions are modularized, and any particular end user will only use those extensions that are relevant to whatever their current program addresses. This avoids overwhelming the user with too much "stuff" at a time. | 言語拡張の実現可能性 スマートメーターの経験に基づいて、建物の拡張のための努力が合理的である。例えば、レジスタ（およびテストのためのシミュレーション）のための言語拡張の実装は、半日で行われていた。割り込みの追加は、割り込みTRIG -リトリガーランナブルと道を」 、それらをワイヤ」までは、 1日の年頃だった。言語拡張を構築することは基本言語を変更する必要はありません。スマートメーター用の拡張機能は、この点を示しています。上記のレジスタ拡張は、基礎となるC言語を変更せずに構築されています。同様に、割り込みベースの実行可能なトリガーは、コンポーネント言語の一部で、一般的なトリガ機能にフックされています。言語は合理的に設計されると、言語（またはその一部）は、特に、事前に予期されていないコンテキストで再利用可能であるべきである。スマートメーター·システムは、そのような例が含まれています。式は、ハードウェアの動作をエミュレートするためのレジスタ定義コンセプトに埋め込まれており、ユニットとタイプは、決定表で使用されてきた。ここでも、既存の言語に変更は必要とされていない。言語拡張に対して使用されている一つの批判は、言語は大きく成長し、ユーザーがそのすべての構成要素を習得するのは難しいということになるということです。まず、拡張がよく、ユーザーによく知られている概念のための言語学的な抽象化を提供します。 ：状態ベースの動作、インタフェースおよびコンポーネントやテストケース我々の経験では、これは、次の三つの理由mbeddrの問題ではありません。第二に、追加の言語機能があるため、IDEサポートの簡単発見可能。第三に、そして最も重要な、これらの拡張機能はモジュール化され、いずれかの特定のエンドユーザーはどのような彼らの現在のプログラムアドレスに関連するこれらの拡張子を使用します。これは、一度にあまりにも多くの"もの"でユーザーを圧倒避けることができます。 |
コメントをかく