Embedding Component Behavior DSLs into the MontiArcAutomaton ADL Arvid Butting, Bernhard Rumpe, Andreas Wortmann Software Engineering RWTH Aachen University www.se-rwth.de Abstract. Component & connector architecture description languages often need to capture application-specific or company-specific require- ments. Therefore, it is a crucial prerequisite for their successful applica- tion to adapt the ADLs by customizing the languages themselves. Perva- sive modeling with tailored ADLs can benefit from integration of DSLs to model-specific forms of component behavior. This requires expertise of the underlying language integration mechanisms. Current research in in- tegrating heterogeneous component behavior DSLs into an ADL focuses on integration of specific kinds of DSLs or is restricted to syntactic inte- gration. However, language integrators can be liberated from requiring in-depth language integration expertise using appropriate abstractions. To this effect, we present a compact DSL for the integration of behavior DSLs into a component & connector ADL that guides and facilitates this form of language integration. Modeling the embedding of behavior DSLs into ADLs facilitates their composition and ultimately the perva- sive modeling of complex architectures. 1 Introduction For a good acceptance of component & connector (C&C) architecture descrip- tion languages (ADLs) [17], adapting to application-specific or company-specific requirements is a crucial prerequisite [16]. Where domain experts contribute component behavior, adaptation might include integrating appropriate compo- nent behavior DSLs into the ADL of choice [8,18]. Model-driven development and meta modeling can support such adaptation [15], but require expertise of the underlying language workbenches [6], particularly their definition and inte- gration mechanisms [3]. Language workbenches usually provide means to define a subset of abstract syntax, concrete syntax, static semantics, and dynamic semantics for DSLs as well as generic integration mechanisms, such as importing, inheritance, or embed- ding, on top of these definitions (such as Eco [5], Kermeta [12], or Spoofax [25]). While providing powerful means to compose new DSLs from existing ones, these integration mechanisms are usually unaware of their operation context and hence impose that language customization requires extensive language workbench im- plementation knowledge. However, where the context of DSL integration is re- stricted, such as inheritance from a fixed parent DSL or embedding a DSL into a well-defined extension point of an ADL, the degrees of integration freedom can be greatly reduced to facilitate language integration. We present a DSL for the adaptation of C&C ADLs in terms of embedding application-specific component behavior DSLs. This DSL enables language in- tegrators to easily embed DSLs as required by contributing domain experts. To this effect it exploits features of the architecture modeling infrastructure Monti- ArcAutomaton [20] and its underlying language workbench MontiCore [11] to alleviate reuse of the embedded DSL’s syntax and semantics. This ultimately facilitates architecture modeling with domain experts. In the following, Sect. 2 motivates the benefits of easy, post-hoc DSL em- bedding before Sect. 3 highlights MontiCore and MontiArcAutomaton. Sect. 4 presents the embedding DSL and Sect. 5 highlights observations. Afterwards, Sect. 6 discusses related work and Sect. 7 concludes. 2 Example Consider the development of an assembly line robot that sorts parts according to their quality. The robot features a camera to detect parts and means to deter- mine their quality based on various inputs. According to their quality, the parts are sorted in different bins. The architecture of the system is as depicted in Fig. 1: it consists of a composed component PartSorter that yields subcomponents for sensors (Camera and QualityChecker), control, and manipulation. Com- ponents exchange messages via connectors between their typed, directed ports only and are either composed or atomic, i.e., yield a behavior specification in form of a DSL model or general programming language (GPL) artifact. The behavior of components Controller and Arm is provided by two respective domain experts: one being a professional in part quality and sorting that prefers to use Statecharts. The other is an expert in robot arm movement (including trajectory planning and grasping) and prefers to use the LightRocks [24] DSL for robotic manipulation. Hence, each domain expert should be enabled to use the most appropriate DSL as depicted without requiring the system integrator to become a language engineering expert. composed instance of atomic instance of atomic outgoing port i of incoming port s of component component type with component type with MAA data type Image data type Skill type embedded statechart model embedded LightRocks model PartSorter Camera Image ActionController Arm i i Skill s s Quality Quality Checker q q d d Fig. 1. Architecture of a robot that sorts parts using two embedded DSLs. As the effect of behavior DSL embedding is restricted to ADL concepts ‘vis- ible’ in atomic components, the system integrator can leverage model-driven development to describe integration of the component behavior DSLs using a specific integration DSL. The compact models of this DSL require minimal knowledge of the underlying language engineering principles and their represen- tations in language workbenches. The DSL is tailored to component behavior DSL embedding into the specific ADL and exploits this to reduce the freedom (and complexity) of arbitrary DSL composition. In this restricted context, the integrator can thus easily embed new component behavior DSLs by adding small configuration models per DSL to be embedded. The next sections present this. 3 Preliminaries MontiCore [14,11] is a language workbench for the engineering of compositional DSLs. It generates DSL processing infrastructure from context-free grammars (CFGs), which define abstract syntax and concrete syntax of a DSL in an inte- grated fashion. MontiCore DSLs yield Java-based well-formedness rules, called context conditions, for ensured static semantics, and code generators to realize the dynamic semantics of a DSL. The generated DSL processing infrastructure comprises abstract syntax tree (AST) classes, modular parsers for each pro- duction of the CFG, a symbol table acting as language interface, and context condition infrastructure. MontiCore supports three kinds of DSL composition: embedding, inheritance, and aggregation. Embedding is purely syntactic and combines the CFGs of participating DSLs, such that their instances can be pro- cessed as integrated models. This, for instance, is useful, for embedding SQL into Java or similar. Inheritance enables one DSL to extend or refine another via inheriting or overriding the parent CFG’s productions. A typical use case is the introduction of new constructs to an existing DSL, such as the ADL ArchJava [1], which extends Java with C&C modeling elements. Aggregation enables the joint processing of models of independent DSLs, such as class diagrams describing the data types of a C&C ADL’s ports. For embedding, MontiCore supports extension points in form of external pro- ductions in the host DSL’s CFG. The productions of embedded DSLs are condi- tionally mapped to these extension points and MontiCore combines the parsers for the corresponding productions accordingly (i.e., whenever an instance of the external production should be parsed, the corresponding embedded production is parsed instead). For aggregation, the meta models of the participating DSLs are related (for instance, to check that two ports with data types defined in class diagrams can be connected). Instead of coupling the participating DSLs’ ASTs, their symbol tables are related. Symbol tables represent DSL interfaces for specific integration purposes and, as such, may abstract from the technical necessities of the AST classes. With aggregation, models of the participating DSL may remain in separate artifacts. For embedding with joint interpretation we apply aggregation although the models reside in integrated artifacts, hence in the following, embedding also includes joint interpretation. Instances of Monti- Core’s DSLTool class combine the generated parsers with context conditions and names of these methods are incomplete property data types are the the keywords of BCL models class core MontiCore classes CD BCLBuilder EmbeddedDSL + BCLBuilder name(String name) - String name + BCLBuilder behavior(String behavior) - MCParser parser + BCLBuilder tool(DSLTool tool) - DSLTool tool + BCLBuilder language(ModellingLanguage) - ModellingLanguage dsl + BCLBuilder error(ContextCondition coco) - Map cocos + BCLBuilder errors(ContextCondition coco) - MCGenerator generator + BCLBuilder generator(MCGenerator gen) - Map embeddedDSLs + EmbeddedDSL build() Fig. 2. Class BCLBuilder describes the syntax of BCL models and ultimately pro- duces instances of EmbeddedDSL for each component behavior DSL to be embedded. symbol table infrastructure to ease programmatic model processing. DSLTool instances further can be extended with workflows that add additional model processing capabilities (such as pre-processing model-to-model transformation or automated extraction of documentation). MontiArcAutomaton [20] is an infrastructure for model-driven development of C&C architectures that is built with MontiCore. At its core is the Monti- ArcAutomaton ADL [21] that enables to model architectures as hierarchies of connected components. Components are black boxes with interfaces of directed, typed ports for communication. Port types are modeled as class diagrams. Com- ponent models in MontiArcAutomaton are either composed, if their behavior is defined by a subcomponent configuration, or atomic. The behavior of atomic components is defined via GPL artifacts or embedded DSL models. To this effect, MontiArcAutomaton comprises an extensible ADL that supports integration of DSLs to describe component behavior. To this extent, its CFG yields an external production used by the production for components. It also supports composi- tional code generation enabling transformation of such integrated models into GPL artifacts. This relies on the identification of three code generator kinds with specific interfaces describing the provided and required information for compo- sition. For the specific context of behavior DSL embedding, these three kinds suffice to enable black-box code generator composition. 4 A DSL for Behavior Language Embedding The Behavior Configuration Language (BCL), which is responsible for configur- ing the embedding of component behavior DSLs into the MontiArcAutomaton ADL, is realized for usage with the language workbench MontiCore and as an internal DSL implemented in Groovy. The former entails that it uses concrete syntax referencing important concepts and artifacts of MontiCore DSLs. As Mon- tiCore is implemented in Java and Groovy is compatible with Java, it also follows that models of the integration DSL can directly interface MontiCore artifacts. The BCL is realized as a fluent interface [9] using the builder pattern [10] to enable DSL-like usage, while actually being a Groovy GPL API. Basically, methods of the builder class become keywords of BCL models and ultimately the builder produces an instance of an embedding configuration that is used by the act Configure Embedding AD [single [without custom Add name Add language tool] workflows] Add and behavior [with tool generator DSLTool] [multiple [without languages tool] DSLTool] [with custom [has workflows] [without adapters] ModelingLanguage] [with adapters] Add Add Add adapters language workflows [no ModelingLanguage] [no custom [without] symbol table] [with custom [with context symbol table] conditions] Add context Add conditions symbol table summarized Fig. 3. Specification of name, behavior production, tool, and generator suffices to em- bed a DSL. More complex embedding scenarios are supported as well. MontiArcAutomaton infrastructure. To this effect, it uses the MontiCore classes ContextCondition, ModelingLanguage, MCGenerator, and MCParser. The class diagram depicted in Fig. 2 illustrates this. The methods of class BCLBuilder contribute the concrete syntax and abstract syntax to describe BCL models and successively create and fill an instance of EmbeddedDSL. The BCL well-formedness rules are encoded in the build() method of BCLBuilder and, for instance, ensure that referenced grammar productions exist and mini- mal configuration is available. With Groovy, much of the notational noise [26] of a GPL can be omitted, hence, BCL models actually are chained calls of BCLBuilder methods with brackets and dots omitted. Omitting relations to BCLBuilder is possible as Groovy enables to process scripts in the context of so-called base classes. The Groovy parser is configured for BCLBuilder as base class and interprets method calls in its context. BCL models vary in complexity, which depends on the behavior DSL’s ‘com- pleteness’ and the possibilities to derive DSL infrastructure elements from others. The activity diagram depicted in Fig. 3 describes the configuration flexibility of the BCL: providing name, behavior, and generator are the only manda- tory properties of each BCL model. The name specifies which production of the behavior DSLs grammar is mapped to the unique extension point in MontiArc- Automaton’s grammar (cf. Sect. 3), hence each model must at least identify the grammar production (behavior) to be embedded. With MontiCore defin- ing concrete syntax and abstract syntax in integrated grammars, this specifica- tion covers embedding of both. Also, supporting usage of arbitrary productions of the behavior DSLs enables reusing required DSL parts only. As a tool in MontiCore may process multiple DSLs, it may comprise symbol table infras- tructure, workflows, and context conditions for all processable DSLs. If not all DSLs of a DSLTool are to be reused, the required constituents can be specified individually in terms of their respective MontiCore ModelingLanguage in- stance [11]. If it only processes a single DSL, this DSL, together with its symbol table, workflows, and context conditions is derived from the DSLTool. Where no BCL integration parametrizes MontiCore and Generated Application models generator composition with BCL instances Artifacts MAA SC SC BCLBuilder uses MAA ADL Generator GBC GBC Infrastructure DSLTool Composition SC LR BCL BCL uses GPL Artifacts references instantiates references SC DSL LR2Java LR DSL SC2Java contain grammar, workflows, context conditions, and symbol tables processes Fig. 4. Principal artifacts in processing architecture models with embedded behavior DSL models using the BCL and MontiArcAutomaton. ModelingLanguage is available, their constituents must be provided individ- ually. A BCL model also may add new workflows and a code generator com- patible to the behavior DSL and the code generator of the MontiArcAutomaton ADL. Where additional information is necessary (such as inter-language well- formedness rules [23]), additional modeling elements support their specification. Interpretation of Groovy scripts does not require generating any infrastruc- ture artifacts specific to the language combination (such as combined parsers of symbol table classes), saving the expense of a generation process for each application-specific language combination. We thus extended the infrastructure of MontiArcAutomaton (i.e., its DSLTool subclass) to initially parse all Groovy files in a MontiArcAutomaton project in the context of the BCLBuilder base class and store the EmbeddedDSL instances before processing architecture mod- els with embedded behavior models. Overall, the MontiArcAutomaton DSLTool processes architecture models and BCL models as depicted in Fig. 4 using the BCLBuilder infrastructure. From the models, it combines the parsers generated by MontiCore for the referenced behavior DSL grammars with the MontiArc- Automaton parser and aggregates context conditions, symbol table infrastruc- tures, and workflows. It then parses the architecture with integrated behavior models, creates symbol table instances, and applies the aggregated context con- ditions and workflows. Afterwards, it loads the referenced code generators and composes their execution to produce corresponding GPL artifacts. The most compact case of DSL integration is illustrated in Lst. 1, where UML/P Statecharts [22] are integrated into the MontiArcAutomaton ADL. The integration infrastructure addresses properties of this embedding with the name “statechart” (keyword name, l. 1). It embeds the production SCBody of the Stat- echart DSL (keyword behavior, l. 2) and extracts context conditions, symbol table, and workflows from the DSL’s SCTool (keyword tool, l. 3). Furthermore, it will use the SC2Java code generator (keyword generator, l. 4) to produce combined artifacts. The latter is a reference to a generator description artifact of 1 name "statechart" BCL 2 behavior "umlp.sc.SC.SCBody" 3 tool new umlp.sc.SCTool() 4 generator new SC2Java() Lst. 1. BCL model that configures the integration of the Statechart DSL into Monti- ArcAutomaton 1 // abstract + concrete syntax BCL 2 name "lightrocks" 3 behavior "lr.LightRocks.SkillDefinition" 4 tool new LightRocksTool() 5 language new SkillLanguage() 6 // inter-language well-formedness rules 7 error new ValidMotorRotation() 8 error new RespectPortDirection() 9 warning new TooManyActions() 10 // dynamic semantics 11 generator new Skill2Java() Lst. 2. BCL model that configures the integration of the LightRocks Skill DSL into MontiArcAutomaton MontiArcAutomaton that describes provided and required information for code generator composition (cf. [20]). The BCL model for the integration of the LightRocks DSL is depicted in Lst. 2. The listing begins with name, behavior, and tool (ll. 1-3). The LightRocks DSLTool supports processing of multiple DSLs for the specifica- tion of robotic manipulation processes, tasks, skills, and actions. As only skills are being reused within MontiArcAutomaton, the corresponding MontiCore in- frastructure must be selected manually. Hence, here the DSLTool contributes workflows only, and the SkillLanguage (l. 5) contributes context conditions and symbol table infrastructure related to robotic manipulation skills. After- wards, the model adds three inter-language context conditions (ll. 7-9) that are specific to the integration of skills into MontiArcAutomaton components and either raise errors or warnings. Ultimately, it also adds a code generator (l. 11). Following this approach enables to process architecture models with embedded behavior models as depicted in Lst. 3, which shows the component ActionController of Fig. 1. After importing the ImageProcessor data type, it defines the ActionController component type (ll. 3-15), which com- prises an interface of three ports (ll. 4-7) and a body using an embedded State- chart model (ll. 9-14). The keyword behavior (l. 9) indicates that an embedded behavior model follows. The subsequent concrete syntax is part of the Statechart language and the tool chain configured with the BCL model illustrated in Lst. 1 will select the SCBody parser generated by MontiCore to process it. 5 Related Work Integrating component behavior DSLs is supported by AADL [8] and xADL [13] as well: AADL supports integration of state-based DSLs via its behavior an- nex [2], but does not consider integration of static semantics or dynamic se- mantics. The same holds for xADL, where embedding of a component behavior 1 import ImageProcessor; MAA 2 3 component ActionController { 4 port 5 in Image i, 6 in Quality q, 7 out Skill s; 8 9 behavior statechart { 10 state Waiting, Grasping, Moving, Deploying; 11 Waiting [ImageProcessor.findPart()] 12 -> Grasping / s = new Grasp(ImageProcessor.partPose()); 13 // ... 14 } 15 } Lst. 3. MontiArcAutomaton component model using an embedded Statechart model to describe its behavior. DSLs also enforces to introduce a new corresponding component type [18]. Nei- ther supports language integration in a specialized, compact DSL. The byADL infrastructure [4] resembles a workbench for ADLs. It supports various language integration operations that enable great flexibility. However, they are generic to a broad class of application scenarios and lack the structured guidance of integration DSLs for specific purposes. The π-ADL [19] enables to describe structure and behavior of a software architecture based on the π-calculus. In this, it generally supports to add arbi- trary behavior modeling capabilities on layers on top of its ADL. This, however, ultimately yields a monolithic language aggregate where the individual com- ponents can be hardly exchanged. Furthermore, it does not support black-box composition of code generators for the individual behavior DSLs. The Kermeta language workbench enables to mashup [12] meta-languages, static semantics, and dynamic semantics to compose DSLs. This is a more general form of composition and yields the same challenges than other general compo- sition mechanisms in other language workbenches. 6 Discussion On the one hand, the presented BCL is specific to its implementation with Monti- ArcAutomaton and MontiCore, which is reflected in its concrete syntax. On the other hand, where the integration context is sufficiently elaborated, applying integration DSLs translates to other language workbenches as well. A benefit of combining MontiCore with an internal integration DSL is in its agility: AST classes and parsers generated for ADL and behavior DSLs can be reused without requiring intermediate code generation to produce integrated AST classes and parsers (cf. [11]). Also, no artifacts are produced from the integration model, which is validated in the context of related MontiCore artifacts at design time. Our notion of DSL embedding differs from the self-extension identified in [7] and discussed in [11]. Where we advocate embedding of independent, external DSLs, self-extension usually refers to internal DSLs that can easily extend their con- crete syntax with new APIs. However, with the embedding of sufficient complex DSLs (such as the Java DSL presented in [23]), self-extension can be realized with embedding. The BCL relieves language engineers from detailed knowledge about the MontiCore language composition mechanisms. The embedding of a new behavior DSL takes place in a single BCL model, instead of registering DSL infrastructure across scattered artifacts. Embedding is decoupled from the DSLs, enabling to reuse behavior DSLs in different contexts. 7 Conclusion We have presented a small DSL for the agile adaptation of C&C ADLs via em- bedding of component behavior DSLs. It supports ADL developers in fitting their ADL to the participating domain experts’ DSL requirements and supports agile, post-hoc customization exploiting properties of the underlying MontiCore language workbench as well as its internal DSL nature. In the future, similarly elaborated language integration purposes might produce further specific integra- tion DSLs (for instance, to easily integrate and exchange the data type descrip- tion language an ADL operates on) for different purposes and on top of different language workbenches. We believe that such specialized integration operations can advance the application of model-driven development, where adaptation of existing DSLs is crucial. References 1. Aldrich, J., Chambers, C., Notkin, D.: ArchJava: Connecting Software Architecture to Implementation. In: International Conference on Software Engineering (ICSE) 2002 (2002) 3 2. Bedin Franca, R., Bodeveix, J.P., Filali, M., Rolland, J.F.: The AADL Behavior Annex-Experiments and Roadmap. In: Proceedings of the 12th IEEE International Conference on Engineering Complex Computer Systems (2007) 5 3. Clark, T., den Brand, M., Combemale, B., Rumpe, B.: Conceptual Model of the Globalization for Domain-Specific Languages. In: Globalizing Domain-Specific Languages. Springer (2015) 1 4. Di Ruscio, D., Malavolta, I., Muccini, H., Pelliccione, P., Pierantonio, A.: Devel- oping Next Generation ADLs Through MDE Techniques. In: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering (2010) 5 5. Diekmann, L., Tratt, L.: Eco: A Language Composition Editor. In: International Conference on Software Language Engineering (2014) 1 6. Erdweg, S., van der Storm, T., Völter, M., Boersma, M., Bosman, R., Cook, W., Gerritsen, A., Hulshout, A., Kelly, S., Loh, A., Konat, G., Molina, P., Palatnik, M., Pohjonen, R., Schindler, E., Schindler, K., Solmi, R., Vergu, V., Visser, E., van der Vlist, K., Wachsmuth, G., van der Woning, J.: The State of the Art in Language Workbenches. In: Software Language Engineering. Springer International Publishing (2013) 1 7. Erdweg, S., van der Storm, T., Völter, M., Tratt, L., Bosman, R., Cook, W.R., Gerritsen, A., Hulshout, A., Kelly, S., Loh, A., Konat, G., Molina, P.J., Palat- nik, M., Pohjonen, R., Schindler, E., Schindler, K., Solmi, R., Vergu, V., Visser, E., van der Vlist, K., Wachsmuth, G., van der Woning, J.: Evaluating and Com- paring Language Workbenches: Existing Results and Benchmarks for the Future. Computer Languages, Systems & Structures (2015) 6 8. Feiler, P.H., Gluch, D.P.: Model-Based Engineering with AADL:An Introduction to the SAE Architecture Analysis& Design Language. Addison-Wesley (2012) 1, 5 9. Fowler, M.: Domain-Specific Languages. Addison-Wesley Professional (2010) 4 10. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional (1995) 4 11. Haber, A., Look, M., Mir Seyed Nazari, P., Navarro Perez, A., Rumpe, B., Voelkel, S., Wortmann, A.: Integration of Heterogeneous Modeling Languages via Exten- sible and Composable Language Components. In: Proceedings of the 3rd Interna- tional Conference on Model-Driven Engineering and Software Development (2015) 1, 3, 4, 6 12. Jézéquel, J.M., Combemale, B., Barais, O., Monperrus, M., Fouquet, F.: Mashup of Meta-Languages and its Implementation in the Kermeta Language Workbench. Software and Systems Modeling (2013) 1, 5 13. Khare, R., Guntersdorfer, M., Oreizy, P., Medvidovic, N., Taylor, R.N.: xADL: Enabling Architecture-Centric Tool Integration with XML. In: System Sciences, 2001. Proceedings of the 34th Annual Hawaii International Conference (2001) 5 14. Krahn, H., Rumpe, B., Völkel, S.: MontiCore: Modular Development of Textual Domain Specific Languages. In: Proceedings of Tools Europe (2008) 3 15. Lago, P., Malavolta, I., Muccini, H., Pelliccione, P., Tang, A.: The Road Ahead for Architectural Languages. Software, IEEE (2015) 1 16. Malavolta, I., Lago, P., Muccini, H., Pelliccione, P., Tang, A.: What Industry Needs from Architectural Languages: A Survey. IEEE Transactions on Software Engineer- ing (2013) 1 17. Medvidovic, N., Taylor, R.: A Classification and Comparison Framework for Soft- ware Architecture Description Languages. IEEE Transactions on Software Engi- neering (2000) 1 18. Naslavsky, L., Dias, H.Z., Ziv, H., Richardson, D.: Extending xADL with Statechart Behavioral Specification. In: Third Workshop on Architecting Dependable Systems (WADS), Edinburgh, Scotland (2004) 1, 5 19. Oquendo, F.: Pi-ADL: an Architecture Description Language based on the Higher- order Typed pi-calculus for Specifying Dynamic and Mobile Software Architec- tures. SIGSOFT Software Engineering Notes (2004) 5 20. Ringert, J.O., Roth, A., Rumpe, B., Wortmann, A.: Language and Code Generator Composition for Model-Driven Engineering of Robotics Component & Connector Systems. Journal of Software Engineering for Robotics (JOSER) (2015) 1, 3, 4 21. Ringert, J.O., Rumpe, B., Wortmann, A.: Architecture and Behavior Modeling of Cyber-Physical Systems with MontiArcAutomaton. Aachener Informatik-Berichte, Software Engineering, Shaker Verlag (2014) 3 22. Rumpe, B.: Modeling with UML. Language, Concepts, Methods. Springer Inter- national (2016) 4 23. Schindler, M.: Eine Werkzeuginfrastruktur zur agilen Entwicklung mit der UM- L/P. Aachener Informatik-Berichte, Software Engineering, Band 11, Shaker Verlag (2012) 4, 6 24. Thomas, U., Hirzinger, G., Rumpe, B., Schulze, C., Wortmann, A.: A New Skill Based Robot Programming Language Using UML/P Statecharts. In: 2013 ICRA IEEE International Conference on Robotics and Automation (ICRA). Karlsruhe, Germany (2013) 2 25. Wachsmuth, G.H., Konat, G.D.P., Visser, E.: Language Design with the Spoofax Language Workbench. IEEE Software (2014) 1 26. Wile, D.S.: Supporting the DSL Spectrum. Computing and Information Technol- ogy 4 (2001) 4