Domain-Specific Languages-Based Methodologies .1 Draco.1 Draco

In his PhD thesis [Nei80], Neighbors presented withDraco the first domain engineering approach. His model for the general domain engineering process with separation of domain engineering from application engineering is still valid. Almost all newer models are only refinements of this model.

Neighbors recognized that it is important to represent a domain in a language that fits the problems of the domain rather than using a general-purpose programming language. He introduced the termdomain language² for these languages. The Draco approach is based on source-to-source transformations of domain languages. The Draco tool chain allows to specify and transform the domain specific language into statements of a general-purpose language. The difference between normal compiler technology and Draco transformations is that the transformations are user-defined and can be tagged with constraints for a selec-tion of transformaselec-tions based on domain knowledge. That in turn enables domain-specific optimizations. This is achieved by including more than one possible transformation for an input language statement from which one is selected based on the given constraints.

The initial Draco system had some deficiencies regarding scalability. For each new domain, the process of developing a domain specific language and its transformations to the target language had to be redone from scratch. This has later been fixed in Draco [Nei84] with the introduction of subdomains.

A subdomain represents a part of the solution for the parent domain. It is a Draco do-main itself, using its own dodo-main language. The parent dodo-main can use the subdodo-main by providing a mapping of its domain language (or parts of it) to the subdomain language.

This can increase reusability significantly. Carefully designed subdomains can be reused in many different contexts under the assumption that it is easier to provide the mapping than to develop new transformations or adapt transformations from other domains.

2Today the termdomain specific languageis more common, but has essentially the same meaning.

Application Engineering Environment Qualify Domain

Model Application Produce Application Deliver and Support Application

Analyze Domain Implement Domain

Engineer Application Engineer Domain Iterate

Iterate Feedback

Feedback

Applications

Figure 3.3: The FAST process (taken from [WL99])

3.6.1.2 FAST — Family-Oriented Abstraction, Specification and Translation The Family-Oriented Abstraction, Specification and Translation (FAST) approach was de-veloped by Weiss et al. [WL99]. FAST has its roots in the Synthesis [CBFO91] approach.

FAST is a customizable process and artifact model for family-based software development.

The development process is described in terms of artifacts, steps to produce these artifacts and an associated role model. Each artifact has a definition where the structure, possible states and transition of each artifact are described.

The basic steps for producing a software family are shown in Figure ??³. FAST starts with a domain qualifying activity to decide whether it is worthwhile to pay the increased initial investment for developing a family when compared to developing a number of single systems for the domain of interest. If the qualifying activity results in a positive evaluation scope, variability and commonality (VC) analysis follows.

The results from this analysis are represented as lists. For each variability a set of parameters of variation is defined. These parameters with their value ranges describe the different

3FAST’sdomain analysisactivity includes the domain design activity.

3.6 Selected Approaches

variations possible at that point. Adecision modelis derived from the variabilities list. This model contains an ordered list of decisions and allows to differentiate the possible family members based on these decisions. As with the results of the VC analysis, it is not clearly defined how these decisions should be represented.

The decision model is used to defined anapplication modeling language (AML) for the description of the family members. An AML can be anything from simply more or less informal text, which is processed manually, up to a new language for which compilers have to be build. The decision what kind of AML representation to use depends on the nature of the domain, the development environment and also the skills of the developers involved.

The domain implementation activity consists of the implementation of the AML environ-ment and includes the construction of tools, libraries and docuenviron-mentation for the AML.

The application engineer uses the environment to model the application in terms of the AML. The AML tools then generate all or parts of the application from that AML specifi-cation. Parts that cannot be generated are added to produce the final applispecifi-cation.

The strength of the FAST process lies in its detailed process model that is supported by a process modeling approach (Process and Artifact State Transition Abstraction - PASTA).

This model allows an organization to introduce family-based development easily by follow-ing the process model and changfollow-ing the process accordfollow-ing to its needs.

Due to its general approach, FAST does not give much information on how to implement a family. The representation for commonalities and variabilities is weaker and less formally defined as in FODA or other feature model based approaches. On the other hand it is possible to customize the process for the use of feature models for this representation.

3.6.1.3 P3

P3 [BCRW00] is a DSL for container data structures. It is implemented using a GenVoca generator, see section 4.5.1 for a detailed description of GenVoca. Its root is P2 [BTS94], an earlier approach for the same application domain.

P3 is not an entirely new language but extends the Java language to support easy definition of container data structures and efficient access to them. The user of P3 has to specify how the container data structures are constructed from basic types and what kind of access operations are required. The generated code provides special objects (cursor objects) for data structure access. Each cursor type has to be defined using the DSL as part of the container data structure description. A cursor can have a number of attributes, for example how often this cursor will be used, predicates defining which data items are visible using this cursor, or what operations on the data items can be performed using the cursor. From this information the implementation of the data structure itself and the associated cursors types is generated.

Domain Analysis

Domain Modelling

Context Analysis Architecture Modelling

Entity Relationship Diagram Feature Model Functional Model Domain Terminology Dictionary Context Diagram

Structure Diagram Process Interaction

Model Structure Chart

Figure 3.4: FODA activities and results (from [KCH⁺90])

P3 is a good example where additional domain knowledge, which usually cannot be ex-pressed easily in common programming languages, is used to provide implementations that are more efficient. The comparison with other Java-based libraries in [BCRW00] shows that using the additional knowledge leads to better performance for the DSL based approach.