tailoring the montiarcautomaton component & connector … · tailoring the montiarcautomaton...

Tailoring the MontiArcAutomaton Component & ConnectorADL for Generative Development

Jan O. Ringert�

School of Computer ScienceTel Aviv University

http://www.cs.tau.ac.il/

Bernhard RumpeSoftware Engineering

RWTH Aachenhttp://www.se-rwth.de/

Andreas WortmannSoftware Engineering

RWTH Aachenhttp://www.se-rwth.de/

ABSTRACTComponent & connector (C&C) architecture description lan-guages (ADLs) combine component-based software engineer-ing and model-driven engineering to increase reuse and toabstract from implementation details. Applied to roboticsapplication development, current C&C ADLs often requiredomain experts to provide component behavior descriptionsas programming language artifacts or as models of a-priorifixed behavior modeling languages. They are limited to spe-cific target platforms or require extensive handcrafting totransform platform-independent software architecture mod-els into platform-specific implementations. We have de-veloped the MontiArcAutomaton framework that combinesstructural extension of C&C concepts with integration ofapplication-specific component behavior modeling languages,seamless transformation from logical into platform-specificsoftware architectures, and a-posteriori black-box composi-tion of code generators for di�erent robotics platforms. Thispaper describes the roles and activities for tailoring Monti-ArcAutomaton to application-specific demands.

CCS Concepts• Software and its engineering � Domain specific lan-guages; Architecture description languages; Appli-cation specific development environments;

KeywordsModel-Driven Engineering, Architecture Description Lan-guages, Component & Connector Models

1. INTRODUCTION AND MOTIVATIONEngineering robotics software requires techniques to sup-

port comprehension, separation of concerns, and reuse of ex-isting parts. Component-based software engineering (CBSE)

�J. O. Ringert acknowledges support from a postdoctoralMinerva Fellowship.

MORSE/VAO ’15, July 21 2015, L’Aquila, Italyc�

DOI: http://dx.doi.org/10.1145/2802059.2802064

is a technique to enable reuse of software components be-tween applications [2]. Software components are definedas general-purpose programming language (GPL) artifacts.These are hardly reusable in di�erent contexts (such as withdi�erent robots) and require domain experts to compre-hend software engineering concepts as well as GPL details.Model-driven engineering (MDE) abstracts from this by lift-ing models to primary development artifacts. Models can bebetter comprehensible, platform-independent, and automat-ically translated into di�erent implementations [8]. Compo-nent & connector (C&C) architecture description languages(ADLs) [18] combine CBSE and MDE to enable compositionof complex software architectures from abstract componentmodels. Code generators translate ADL models into exe-cutable systems.

Extensiblity is considered “a key property of modeling no-tations” [17] and crucial for development of applications forheterogeneous technologies as eminent in robotics. However,most C&C software ADLs come with fixed sets of modelingelements and component behavior modeling languages.

A recent survey on industrial use of ADLs found that ex-isting extension mechanisms for tailoring an ADL “towardswhole company needs” are insu�cient and correspondingtools too generic [16]. This limits the principal design deci-sions the language may express and ultimately requires torealize important design decisions in GPL artifacts bundledwith the architecture. Similarly, only 38% of the surveyrespondents generate code from ADL models. The mostimportant reasons for handcrafting code are “no need”, a“di�erent level of abstraction between software architectureand target code”, and “limited ADL expressiveness”.

We present a methodology supported by the MontiArc-Automaton framework that combines structural extension ofC&C concepts with integration of application-specific com-ponent behavior modeling languages, a transformation ofplatform-independent into platform-specific software archi-tectures and composable code generators to complement lan-guage integration flexibility. With this,

R1 the C&C language can be extended to meet specificdemands,

R2 domain experts describe component behavior using themost appropriate application-specific modeling languagesor provide GPL implementations,

R3 logical software architectures are reused for di�erenttarget platforms, and

R4 code generators are composed to translate architecture

[RRW15] J. O. Ringert, B. Rumpe, A. Wortmann: Tailoring the MontiArcAutomaton Component & Connector ADL for Generative Development. In: Proceedings of the 2015 Joint MORSE/VAO Workshop on Model-Driven Robot Software Engineering and View-based Software-Engineering, pp. 41-47, L'Aquila, Italy, ACM New York, 2015. www.se-rwth.de/publications

motor actuating left track

ultrasonic sensor

Lego NXT computation

unit

ultrasonicsensors

body with embedded dual core computer

Figure 1: Exploration platforms: a Lego NXT robotwith leJOS and a Pioneer 3-AT with ROS.

models of specific language combinations into imple-mentations.

We have previously presented technical details on the ex-tension mechanisms of MontiArcAutomaton in [27, 23, 15].The description in this paper focuses on the methodologyof applying these and comprises of roles and activities forthe customization and extension of the MontiArcAutomatonframework and its ADL. In the following, Sect. 2 illustratesthe issues MontiArcAutomaton tackles by example, beforeSect. 3 presents background on MontiCore and MontiArc-Automaton. Sect. 4 describes how to use the extensionmechanisms of MontiArcAutomaton and Sect. 5 discussesrelated work. Finally, Sect. 6 concludes.

2. EXAMPLEConsider a robotics company that is going to produce

robots for exploration of unknown areas. These robots aresupposed to explore the area they are deployed to until theyapproach an obstacle, log it, back up, rotate, and start ex-ploring again. The company is going to produce systems fordifferent requirements: a cheap system for indoor educationpurposes and a robust system for outdoor exploration. Bothsystems are depicted in Fig. 1. The educational system - onthe left - comprises of a Lego NXT robot equipped with aninexpensive computation unit, a front-mounted ultrasonicsensor, and the leJOS NXJ operating system1 to interfacethe NXT hardware with Java. The outdoor exploration sys-tem uses Pioneer 3-AT robot with multiple front-mountedultrasonic sensors, a powerful on-board computer, and therobot operating system ROS [20] to interface the hardwarewith Python.

Although both platforms require different GPLs, sensors,and actuators they provide similar functionality To reduceengineering costs by reusing the same logical software archi-tecture for both systems (R3), the company uses an C&CADL with embedded component behavior modeling languagesand a GPL-independent data type language. A software en-gineer decomposes the system’s functionality into nine com-ponent types as depicted in Fig. 2. The composed com-ponent type ExplorerBot contains two subcomponents oftypes Button and UltraSonic that provide input to a sub-component of type ExplorationControl. ExplorationCon-trol is composed from a Controller, which translates inputsinto navigation commands, and a Logger, which persists dis-tance data. The navigation commands are passed to a com-ponent of type Navigation that contains a Translator and1Website of leJOS: http://www.lejos.org/

composedcomponent

type

outgoingport

„distance“

connectorof type Float

MAA

parametrizedsubcomponent instances

of type Motor

subcomponent instance„control“ of composed

type „ExplorationControl“

atomic componenttypes with embedded

activity diagrams

subcomponentof type Logger

ExplorerBot Navigation

navigationExplorationControl

control

Motor

left(PORT_A)

Motor

right(PORT_B)

pressed cmd

Logger

logdistance

Translator

translator

msg

Float

Button

emergencyOff

UltraSonic

sensor

Controller

control

Figure 2: Platform-independent ExplorerBot Compo-nent and Connector model.

two instances of component type Motor to translate navi-gation commands into control of two parallel motors thatpropel the robot.

To ensure optimal component scheduling, the software en-gineer wants to specify their order in the ExplorerBot com-ponent type – a feature that requires to extend the ADL andadd modeling elements to represent subcomponent schedulesas well as well-formedness rules to check whether a scheduleis valid (R1). The component types Button, UltraSonic,Logger, and Motor require specific GPL implementations asthey use APIs to interface drivers of hardware components oroperating system functionality. The integration and bindingof specific implementations to components is a necessity forthe project’s engineers (R2). The engineers decide to modelthe behavior of the component types Timer and Controllerwith variant of UML activity diagrams (AD) popular at thecompany. Using ADs to model component behavior requiresextending the ADL with the AD language and integrationof new code generators (R2 and R4).

3. PRELIMINARIESIn ongoing efforts we are creating the extensible C&C

ADL MontiArcAutomaton2 that integrates application-specificcomponent behavior modeling languages with full supportfor extension and code generation to multiple platforms. Itspowerful modeling language extension and integration mech-anisms are implemented on top of the MontiCore languageworkbench, which we present in Sect. 3.1. We introduce theMontiArcAutomaton framework in Sect. 3.2.

3.1 The MontiCore Language WorkbenchMontiCore [14] is a workbench for the compositional de-

velopment of domain specific languages (DSLs). It com-prises of a language to describe concrete and abstract syntaxof DSLs and generators to create language processing infras-tructure. For a specific DSL, tools to parse textual modelsand to translate these into an abstract representation, as wellas frameworks for well-formedness checking [31], languageintegration [9], and template-based code generation [29] aregenerated from the DSLs context-free grammar.

2MontiArcAutomaton website: http://monticore.de/robotics/montiarcautomaton/.

42 Jan Oliver Ringert, Bernhard Rumpe and Andreas Wortmann

system

comp. impl.

A

P

I

generated

comp. impl.

A

P

I

generated

comp. impl.

A

P

I

system

comp. impl.

A

P

I

environment: hardware,

frameworks, UIs

application programmer

model libraryprovider

code library provider

models

generatordeveloper

languageengineer

run-time systemdevelopergenerated

comp. impl.

A

P

I

A

P

Igenerated

comp. impl.

A

P

I

generated

comp. impl.

A

P

I

manual

comp. impl.

A

P

I

run-time system

code

libraries

MontiArcAutomaton

M2TM2M

code generator

(behavior-specific)behavior

DSL

ADL

model

libraries

applicationmodeler

I/Oω

Figure 3: The MontiArcAutomaton framework processes C&C models with embedded component behaviormodels of application-specific languages to produce artifacts for arbitrary GPLs. To this end, it providesextension points for behavior languages and code generators that need to be implemented by different roles.

The language integration mechanisms of MontiCore real-ize a syntax-oriented approach towards black-box languageintegration of grammar-based languages. With these, Mon-tiCore enables language aggregation, language embedding,and language inheritance. Language aggregation combinesseveral languages into a loosely coupled language family,which enables a combined interpretation of independent mod-els that reside in different artifacts. A typical application areorthogonal system aspects, e.g., a component modeling lan-guage and its data types. Language embedding combineslanguages by embedding elements of one language into dis-tinguished extension points of another. This enables usingboth languages in a single artifact and lends itself to em-bedding component behavior modeling languages into com-ponent modeling language elements of ADLs. Language in-heritance is used to refine or to extend an existing language.Inheritance is used to extend the MontiArcAutomaton ADLwith additional modeling elements. In each case of reuse, thelanguage processing infrastructure for all languages is gen-erated by MontiCore. Its language integration mechanismssupport all levels of syntax-oriented language integration,i.e., they integrate concrete syntax, abstract syntax, andwell-formedness rules [31]. Detailed descriptions of Monti-Core [13], language integration [10], and code generation [29]are available.

3.2 The MontiArcAutomaton ArchitectureModeling Framework

At is core, MontiArcAutomaton contains an ADL extend-ing the MontiArc ADL [11], embeds a component behav-ior modeling language based on I/Oω automata [26], andaggregates UML/P class diagrams (CD) [28] to describedata types. All languages are implemented with MontiCore.The MontiArcAutomaton ADL [26] describes logically dis-tributed software architectures as C&C systems in whichcomponents perform computations and connectors regulatecommunication. Components are black-boxes with stableinterfaces of typed, directed ports and are either atomic orcomposed. The data types of ports are defined as UML/PCDs. Atomic components feature a component behavior de-scription, either as a model of an embedded language [25],or as GPL artifacts. Composed components contain a hi-

erarchy of subcomponents and their behavior emerges fromtheir combination. MontiArcAutomaton distinguishes com-ponent types and subcomponent instances, supports generictypes, component configuration parameters, and introducescomponent variables. Architecture models are parsed bythe generated language processing infrastructure, checkedfor well-formedness, and transformed into executable sys-tem using multiple code generators [23, 24]. Different targetplatforms are supported by model and code libraries [27].

4. TAILORING MONTIARCAUTOMATONEach tailoring activity is performed by roles involved in

the MontiArcAutomaton development process (illustratedwith the related artifacts in Fig. 3). We distinguish betweenthe following roles and their specific technical skills:

application modeler: models C&C architecture and behav-ior, selects libraries, binds abstract to platforms-specificcomponents

application programmer: provides GPL implementations ofcomponents if not possible to generate

model library provider: provides platform-independent com-ponents and data types

code library provider: implements modeled library compo-nent types in GPL if not possible to generate

language engineer: develops and integrate modeling languages

generator developer: provides code generators for languagesand specific run-time system (RTS)

RTS developer: provides run-time system in platform GPL

The activities for tailoring the framework are organized inthree stages addressing customization of the modeling lan-guage, development of the application model, and composi-tion of code generators. An overview of the tailoring activi-ties is shown in Fig. 4. Each stage starts with a decision nodeand has two alternative actions depending on the necessityof customization. The first stage distinguishes whether theMontiArcAutomaton language family has to be extended or

Tailoring the MontiArcAutomaton Component & Connector ADL for Generative Development 43

ADact Tailor Framework

use providedlanguage

family

develop PSarchitecture

selectmonolithicgenerator

extendlanguage

family

develop PIarchitecture

composecode

generators

generatetargetcode

[features

sufficient]

[requires

extension]

[single target

platform]

[multiple

target platforms]

[monolithic

generator exists]

[no appropriate

generator]

stage 3

stage 2

stage 1

Figure 4: The stages and activities involved in tailor-ing MontiArcAutomaton, developing C&C applica-tions, and generating platform-specific target code.

not. The case of extending the MontiArcAutomaton ADLwith new structural modeling elements and adding compo-nent behavior modeling languages is described in Sect. 4.1.In the second stage, a robotics application is modeled. Hereeither a platform specific architecture is developed or the ar-chitecture is kept platform-independent by means of modellibraries and bindings. Details of the activity for devel-oping a platform-independent architecture are provided inSect. 4.2. Finally, in the third stage code generators are se-lected. If a monolithic code generator for the combinationof ADL features, behavior languages, and target platformexists, it can be used. Otherwise, an appropriate code gen-erator has to be composed from other code generators asdescribed in Sect. 4.3. Engineering C&C applications withMontiArcAutomaton using its provided features, languages,and monolithic code generators, i.e., always selecting the up-per branches in the activity shown in Fig. 4, are documentedin [25, 24].

4.1 Language Family ExtensionIn case an existing MontiArcAutomaton language family

is insufficient for the development of a new robotics appli-cation, it has to be extended. The extension mechanismcomprises of extending the MontiArcAutomaton ADL (R1)and adding the most-appropriate component behavior mod-eling languages (R2). This activity is carried out by theroles application modeler and language engineer and shownin Fig. 5.

The application modeler examines the MontiArcAutomatonADL for required features. These requirements are passedto the language engineer, who thus refines or extends the

C&C modeling part of the MontiArcAutomaton ADL usingthe language inheritance feature of MontiCore. An examplefor this kind of extension is adding scheduling information asdiscussed in the example in Sect. 2 as R1. Afterwards, theapplication modeler identifies the required component be-havior modeling languages. If new behavior languages haveto be created or existing ones have to be extended, this taskis passed to the language engineer again. In our running ex-ample an existing language for activity diagrams was chosento extend the language family (see Sect. 2, R2). After alllanguages meet the application modeler’s requirements, thelanguage engineer integrates these into a new language fam-ily. In our example, this language family is also extendedwith well-formedness rules for scheduling information andembedded ADs.

4.2 Platform-Independent and Platform-Specific Architectures

The integration of components with platform-specific im-plementations renders an architecture platform-specific. Whendeveloping robotics applications for multiple platforms thisdependency should be avoided (R3). MontiArcAutomatonuses platform-independent model libraries, platform-specificcode libraries, and bindings to enable a late commitment toactual platforms [27]. We show how to apply these mecha-nisms for stage 2 in the activity in Fig. 6.

First, the application modeler identifies component typesrequiring platform-specific implementations that cannot begenerated from behavior models. In our example scenario,the component types Button, UltraSonic, Logger, and Mo-tor require specific GPL implementations because they in-teract with platform-specific APIs. The model library providercreates models of these components, which the applicationmodeler then uses to model the platform-independent ar-chitecture. Platform-independent components that requireGPL implementations are bound in a platform-specific ap-plication model. For each platform the application mod-eler identifies matching code libraries provided by the codelibrary developer. In Sect. 2, e.g., platform-specific imple-mentations of the UltraSonic sensor are required for the LegoNXT and Pioneer 3-AT robot.

4.3 Code Generator Development andConfiguration

MontiArcAutomaton enables to use monolithic code gen-erators for specific language aggregates, as well as compo-sition of modular and reusable code generators (R4). Thecomposition of modular code generators is aligned with thelanguage extension mechanisms of the framework [23] anddefines code generator kinds for three different concerns: (1)component generators produce code representing componenthulls [30], i.e., ports, variables, messaging infrastructure,and the hierarchies of composed components, (2) behaviorgenerators process models of a single embedded behaviorlanguage to produce component behavior code, and (3) typegenerators produce code to represent data types in the tar-get GPL.

The activity of code generator composition begins withthe application modeler identifying required code generatorssuitable for the intended target platforms. First, a propercomponent generator has to be selected. If no such gener-ator exists, a generator developer needs to provide it. Tointegrate generated component code with handcrafted and


Language

Engin

eer

identify ADLrequirements

extend ADLaccordingly

[ADL insufficient]

identify behaviorlanguage

requirements

[ADL sufficient]

createbehaviorlanguages

extend behaviorlanguagesaccordingly

[languages missing]

integratelanguages

[languages suffice]A

pplic

ation

Modele

r

act Extend Language Family

[languages

insuficient]

AD

Figure 5: Extension and configuration of the MontiArcAutomaton language family.

Model Lib

rary

Pro

vid

er

Applic

ation

Modele

r

AD

model platform-independentarchitecture

identifyrequired PIcomponents

createapplication

models

createmodellibrary

createcodelibrary

[matching model

libraries do

not exist]

identifyrequired PS

implementations

[matching code

libraries do

not exist]

[matching model

libraries exist]

[matching code

libraries exist]

[platform bindings missing]

[all

platforms

bound]

act Develop Platform-Independent Architecture Model

Code L

ibra

ry

Pro

vid

er

Figure 6: Developing a platform-independent software architecture and binding it to platform-specific imple-mentations.

generated behavior code, the component generator relies ona run-time system (RTS) provided by a run-time system de-veloper. Afterwards, for each component behavior language,target platform, and RTS, a suitable behavior generator isselected. This may include the generator developer to de-velop proper generators. Finally, data type generators (e.g.,for types used by ports) for the target platform’s GPL are aswell provided by a code generator developer. After selectionof proper code generators, transformation into executablesystems can be invoked.

We now focus on the activity of developing new code gen-erators shown in Fig. 7. This activity combines extensionof the MontiArcAutomaton ADL, integration of new com-ponent behavior languages, introduction of a new data typelanguage, and usage of a new target platform. The gener-ator developer begins with identifying the missing genera-tor’s type. Component generators and behavior generatorsrequire selection of a matching RTS. Afterwards, the gen-erator developer defines the generator’s provided behavior,i.e., the processable component behavior languages. Then,she implements the generator’s model-to-model or model-to-text transformations, and identifies the code generator’s en-

try point and input requirements (cf. [23]). In collaborationwith the language engineer, the generator developer iden-tifies whether the code generator requires additional well-formedness rules to reject models using language features thecode generator does not support (such as non-determinism).If such well-formedness rules are required, the generator de-veloper creates these. Ultimately, the generator developercreates a generator model documenting the RTS, providedbehaviors, entry point, and well-formedness rules of the newgenerator. MontiArcAutomaton relies on these models foractual generator composition as explained in [23].

5. RELATED WORKMultiple architecture modeling languages and frameworks

for C&C systems have been brought forth [18, 16, 21]. Thesehave emerged from different domains, such as automotive[1, 12], avionics [7], or robotics [30, 6, 3] and focus differ-ent challenges of architecture engineering from academic andindustrial perspectives. Most of these are “first-generationADLs” [17] that are“solely focused”on technology instead ofbusiness-related or domain-specific aspects. The flexible in-tegration of DSLs with ADLs is rare and usually overly com-


AD

Language

Engin

eer

Genera

tor

Develo

per

identifygenerator

type

implementgenerator

trans.

identifyentrypoint

identify well-formedness

rules

develop well-formedness

rules

[requires

well-formedness

rules]

creategenerator

model

[component

or behavior

generator]

[data type

generator]

selectrun-timesystem

defineprovidedbehaviors

behaviors

run-time system

entry point

well-formedness

rules

act Develop Compositional Code Generator

[does not require

well-formedness

rules]

Figure 7: Activities to develop of a composable code generator.

plicated (cf. the “Behavior Annex” of AADL [7]). The ADLxADL [4, 5] focuses on architecture extensibility as well. Itis based on the xArch3 meta model for XML-based ADLs,shares many features with MontiArcAutomaton (such asatomic and composed component types, instantiation, com-ponent behavior models). Extension in xADL focuses onlanguage extension on the meta model level and does nei-ther support black-box language integration, nor integra-tion of language processing infrastructure [19]. Also, xADLdoes not consider code generator composition. Instead, itsarchitecture instantiation schemas [4] tie software architec-ture models to specific implementations. In architecturemodeling frameworks driven by the demands of a specificdomain, extensibility usually is less focused and domain-specific issues are challenged foremost. Popular robotics ar-chitecture modeling frameworks [21], such as SmartSoft [30],RobotML [6], BRICS [3], or SafeRobots [22], enable seam-less development of robotics software architectures. Theseframeworks provide solutions to domain-specific issues, suchas advanced communication patterns, deployment, or plan-ning, that are not tackled by MontiArcAutomaton. Al-though most of these frameworks employ state of the artlanguage workbenches, they neither focus ADL extension,nor integration of application-specific behavior languages, orcode generator composition. The authors of [30] explicatethis as “freedom from choice” to support application devel-opers in creating solutions instead of dealing with frameworkmechanisms. To the best of our knowledge, neither genericADLs, nor domain-specific ADLs provide an explicit exten-sion methodology from language extension to generator com-position.

6. SUMMARYWe have presented main activities for extending the ADL

and framework MontiArcAutomaton. Our methodology com-bines structural extension of C&C concepts, integration of

3xArch website: http://isr.uci.edu/architecture/xarch/.

application-specific component behavior modeling languages,transformation of platform-independent into platform-specificsoftware architectures and composable code generators to re-flect language integration flexibility. The activities realizingthis methodology rely on the language integration mecha-nisms of MontiCore [10], as well as on the C&C nature [26],binding concepts [27], and code generators [23] of Monti-ArcAutomaton. The presented methodology comprises ofthree stages: customization of the modeling language, de-velopment of the application models, and composition ofcode generators. Depending on the project’s needs not allactivities are necessary: off-the-shelf MontiArcAutomatonembeds I/Oω automata as component behavior modelinglanguage, can be used for modeling platform-specific soft-ware architectures, and provides code generators for Java,Python, and Mona [24]. With the presented methodology,ADLs can be tailored to specific needs and the resulting soft-ware architectures can be used with different platforms us-ing platform-independent components and specifically com-posed code generators. In the future, we plan to examinehow language engineers can be further assisted in creatingADL extension and valid language aggregates.

7. REFERENCES[1] M. Broy, F. Huber, and B. Schatz. AutoFocus – Ein

Werkzeugprototyp zur Entwicklung eingebetteterSysteme. Informatik Forschung und Entwicklung, 1999.

[2] D. Brugali and P. Salvaneschi. Stable Aspects InRobot Software Development. International Journal ofAdvanced Robotic Systems, 2006.

[3] H. Bruyninckx, M. Klotzbucher, N. Hochgeschwender,G. Kraetzschmar, L. Gherardi, and D. Brugali. TheBRICS Component Model: A Model-BasedDevelopment Paradigm For Complex RoboticsSoftware Systems. In Proceedings of the 28th AnnualACM Symposium on Applied Computing, 2013.

[4] E. M. Dashofy, A. Van der Hoek, and R. N. Taylor. AHighly-Extensible, XML-Based Architecture


Description Language. In Software Architecture, 2001.Proceedings. Working IEEE/IFIP Conference on,2001.

[5] E. M. Dashofy, A. Van der Hoek, and R. N. Taylor.An Infrastructure for the Rapid Development ofXML-based Architecture Description Languages. InSoftware Engineering, 2002. ICSE 2002. Proceedingsof the 24rd International Conference on, 2002.

[6] S. Dhouib, S. Kchir, S. Stinckwich, T. Ziadi, andM. Ziane. RobotML, a Domain-Specific Language toDesign, Simulate and Deploy Robotic Applications. InSimulation, Modeling, and Programming forAutonomous Robots. Springer Berlin Heidelberg, 2012.

[7] P. H. Feiler and D. P. Gluch. Model-based Engineeringwith AADL: An Introduction to the SAE ArchitectureAnalysis and Design Language. Addison-WesleyLongman, Amsterdam, 2012.

[8] R. France and B. Rumpe. Model-driven developmentof complex software: A research roadmap. In Future ofSoftware Engineering 2007 at ICSE., 2007.

[9] T. Greifenberg, K. Hoelldobler, C. Kolassa, M. Look,P. Mir Seyed Nazari, K. Mueller, A. Navarro Perez,D. Plotnikov, D. Reiss, A. Roth, B. Rumpe,M. Schindler, and A. Wortmann. A Comparison ofMechanisms for Integrating Handwritten andGenerated Code for Object-Oriented ProgrammingLanguages. In Proceedings of the 3rd InternationalConference on Model-Driven Engineering andSoftware Development, 2015.

[10] A. Haber, M. Look, P. Mir Seyed Nazari,A. Navarro Perez, B. Rumpe, S. Voelkel, andA. Wortmann. Integration of Heterogeneous ModelingLanguages via Extensible and Composable LanguageComponents. In Proceedings of the 3rd InternationalConference on Model-Driven Engineering andSoftware Development, 2015.

[11] A. Haber, J. O. Ringert, and B. Rumpe. MontiArc –Architectural Modeling of Interactive Distributed andCyber-Physical Systems. Technical report, RWTHAachen, 2012.

[12] F. Howing. Effiziente Entwicklung vonAUTOSAR-Komponenten mit domanenspezifischenProgrammiersprachen. In Proc. of WorkshopAutomotive Software Engineering, 2007.

[13] H. Krahn. MontiCore: Agile Entwicklung vondomanenspezifischen Sprachen imSoftware-Engineering. Shaker Verlag, 2010.

[14] H. Krahn, B. Rumpe, and S. Volkel. MontiCore: aframework for compositional development of domainspecific languages. STTT, 2010.

[15] M. Look, A. Navarro Perez, J. O. Ringert, B. Rumpe,and A. Wortmann. Black-box Integration ofHeterogeneous Modeling Languages forCyber-Physical Systems. In Proceedings of the 1stWorkshop on the Globalization of Modeling Languages(GEMOC), 2013.

[16] I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, andA. Tang. What Industry Needs from ArchitecturalLanguages: A Survey. IEEE Trans. Software Eng.,2013.

[17] N. Medvidovic, E. M. Dashofy, and R. N. Taylor.Moving architectural description from under the

technology lamppost. Information & SoftwareTechnology, 2007.

[18] N. Medvidovic and R. N. Taylor. A Classification andComparison Framework for Software ArchitectureDescription Languages. IEEE Trans. Software Eng.,2000.

[19] L. Naslavsky, H. Z. Dias, H. Ziv, and D. Richardson.Extending xADL with Statechart BehavioralSpecification. In Third Workshop on ArchitectingDependable Systems (WADS), Edinburgh, Scotland,2004.

[20] M. Quigley, B. Gerkey, K. Conley, J. Faust, T. Foote,J. Leibs, E. Berger, R. Wheeler, and A. Ng. ROS: anopen-source Robot Operating System. In ICRAWorkshop on Open Source Software, 2009.

[21] A. Ramaswamy, B. Monsuez, and A. Tapus.Model-driven Software Development Approaches inRobotics Research. In Proceedings of the 6thInternational Workshop on Modeling in SoftwareEngineering, 2014.

[22] A. Ramaswamy, B. Monsuez, and A. Tapus.SafeRobots: A model-driven Framework fordeveloping Robotic Systems. In Intelligent Robots andSystems (IROS 2014), 2014 IEEE/RSJ InternationalConference on, 2014.

[23] J. O. Ringert, A. Roth, B. Rumpe, and A. Wortmann.Code Generator Composition for Model-DrivenEngineering of Robotics Component & ConnectorSystems. In 1st International Workshop onModel-Driven Robot Software Engineering (MORSE2014), 2014.

[24] J. O. Ringert, B. Rumpe, and A. Wortmann. FromSoftware Architecture Structure and BehaviorModeling to Implementations of Cyber-PhysicalSystems. In Software Engineering 2013 Workshopband,2013.

[25] J. O. Ringert, B. Rumpe, and A. Wortmann.MontiArcAutomaton : Modeling Architecture andBehavior of Robotic Systems. In Workshops andTutorials Proceedings of the IEEE InternationalConference on Robotics and Automation (ICRA),2013.

[26] J. O. Ringert, B. Rumpe, and A. Wortmann.Architecture and Behavior Modeling of Cyber-PhysicalSystems with MontiArcAutomaton. Shaker Verlag,2014.

[27] J. O. Ringert, B. Rumpe, and A. Wortmann.Multi-Platform Generative Development ofComponent & Connector Systems using Model andCode Libraries. In 1st International Workshop onModel-Driven Engineering for Component-BasedSystems (ModComp 2014), 2014.

[28] B. Rumpe. Modellierung mit UML. Springer, 2011.

[29] M. Schindler. Eine Werkzeuginfrastruktur zur agilenEntwicklung mit der UML/P. Shaker Verlag, 2012.

[30] C. Schlegel, A. Steck, and A. Lotz. Model-DrivenSoftware Development in Robotics : CommunicationPatterns as Key for a Robotics Component Model. InIntroduction to Modern Robotics. iConcept Press,2011.

[31] S. Volkel. Kompositionale Entwicklungdomanenspezifischer Sprachen. Shaker Verlag, 2011.


tailoring the montiarcautomaton component & connector … · tailoring the montiarcautomaton...

Documents