=Paper=
{{Paper
|id=Vol-2019/mdetools_1
|storemode=property
|title=Challenges and Research Directions for Successfully Applying MBE Tools in Practice
|pdfUrl=https://ceur-ws.org/Vol-2019/mdetools_1.pdf
|volume=Vol-2019
|authors=Francis Bordeleau,Grischa Liebel,Alexander Raschke,Gerald Stieglbauer,Matthias Tichy
|dblpUrl=https://dblp.org/rec/conf/models/BordeleauLRST17
}}
==Challenges and Research Directions for Successfully Applying MBE Tools in Practice==
https://ceur-ws.org/Vol-2019/mdetools_1.pdf
Challenges and Research Directions for
Successfully Applying MBE Tools in Practice
Francis Bordeleau∗ , Grischa Liebel† , Alexander Raschke‡ , Gerald Stieglbauer§ and Matthias Tichy‡
∗ CMind Inc., Canada, Email:francis.bordeleau@cmind.io
† Software Engineering Division, Chalmers | University of Gothenburg, Sweden, Email: grischa@chalmers.se
‡ Institute of Software Engineering and Programming Languages, Ulm University, Germany,
Email: alexander.raschke@uni.ulm.de, matthias.tichy@uni-ulm.de
§ AVL List Gmbh, Graz, Austria, Email: gerald.stieglbauer@avl.com
Abstract—Model Based Engineering aims to improve efficiency section, we describe the experienced challenges in specific
and effectiveness of software engineering. Success in industrial settings and propose research directions to overcome these
practice of MBE does not only depend on the modeling languages limitations.
and constructive or analytical approaches, like code generation or
model checking. It is also heavily influenced by the quality and, Section 2 discusses challenges in industrial use while Sec-
particularly, usability of the selected tools. In this position paper, tion 3 discusses challenges with respect to introduction of
we discuss challenges experienced in applying MBE in practice modeling tools into industrial environments. Section 4 focuses
both from academic as well as industrial viewpoints. Based on on use of modeling tools in education. Sections 5 and 6 discuss
the research challenges, we discuss future research directions to technical challenges in developing modeling tools, particularly,
improve the chances for the success of MBE in industrial practice.
with respect to development of editors. We conclude with a
I. I NTRODUCTION summary.
Model-Based Engineering (MBE) has been successfully
II. I NDUSTRIAL U SE OF MBE
used in industrial domains and contexts, though mostly em-
bedded systems [1], over the last decades to manage the In spite of the fact that MBE has been used in the industry
increasing complexity of modern software intensive systems, since the 90s, the tools have not significantly evolved over the
and increase developer productivity and product quality. Since last decades. Existing MBE tools are still much too complex
then, many different aspects of this field were addressed in to use and customize for domain specific needs. Moreover, the
research and industry: creation and representation of models, lack of evolution of the MBE tools in the last years and the
model transformation, code generation, and tool support to fact that MBE tools still lack key capabilities has led several
mention only a few. development units to seriously re-consider the use of MBE in
Several tools (commercial and open source) have been spite of the all of the benefits it provides.
developed to handle textual and/or graphical models. In the be-
ginning, the focus was on fixed modeling languages like UML A. Experienced Challenges
while in the last decade, the support for modeling domain From our industrial experience, we identify three main areas
specific languages (DSL) raised. This resulted in frameworks that need to be improved to enable a broader adoption of MBE
and tools to generate (textual and graphical) modeling tools tools.
out of meta-models, like GMF, Sirius, MPS, and Xtext. Customization and DSL support. In order to enable the
However, despite the undoubtable strengths of MBE, its increase of productivity, it is essential that MBE tools support
adoption in the industry, particularly outside the embedded customization and Domain Specific Languages (DSL) to allow
systems domain, often remains limited. A substantial body of adapting the tool to the specifics of the domain/context in
work has empirically investigated MBE adoption in industry, which they are used. MBE tools should also allow combining
both using quantitative methods [1], [2], [3] and qualitative graphical and textual modeling in a complementary manner in
methods [4], [5], [6], [7]. Consistently, obstacles reported in a single DSL.
this context are related to modeling tools and their short- This is one aspect that essentially all commercial UML
comings. Commonly named shortcomings are, e.g., inadequate modeling tools have failed to address. UML tools typically
usability [1], [8], [9], lack of interoperability [1], [3], [4], [5], present the whole UML language to the user with very little
[10], high complexity [4], [6], [11], and high training effort capabilities to reduce the set of concepts and diagrams to the
[1], [6]. subset the user needs, and essentially no support for textual
In this position paper, we enumerate several obstacles that modeling. This means that the overall tool environment is
are limiting the broad adoption of MBE in industry. From much more complex than it used to be. While most people
different points of view (two industrial, three academic), we associate this problem with UML, it is not a problem with
present our experiences regarding the application and devel- UML but the UML tools. Team support and collaborative
opment of MBE tools not only, but mainly in industry. In each modeling To enable efficient team collaboration, MBE tools
must provide first-class support for the following aspects: are not contradictory at all. However, there is an observed
versioning, model diff/merge, model review, and document difference between application (e.g. the act of modeling) and
generation. While versioning is well supported, much better introduction of MBE (e.g. learning a modeling language) and
support is required for model diff/merge, model review, and according to some experiences, the latter is considered as much
document generation. If we compare to coding environments more critical within agile environments.
where diff/merge and review are well supported, MBE tools Within agile environments, so-called development sprints
still lack proper support. have shrunk the length of traditional development cycles
Tool capabilities. In spite of years of research in essentially from months to weeks. The support of frequent product
all technical aspects, existing MBE tools still lack capabilities updates, rapid prototyping and continuous integration became
regarding a number of aspects that are considered key (or an inherent part these sprints. In contrast, most established
essential) by software and system engineers, including model- MBE tools originate from MBEs first hype during the 90s
based tracing and debugging, model validation/verification, of the previous century when agile environments were less
model executability, and many others (as discussed in the other prominent. Many traditional MBE introduction strategies are
sections). thus not intentionally designed to comply with weekly sprints
While technical evolution is needed regarding many dif- and due to a limited tool evolvement, MBE tools do not
ferent MBE aspects, we believe that the most effective way provide an inherent support for an agile-oriented introduction
to get access to more and better capabilities is to increase strategy.
technology transfer. In spite of major investment in MBE
research over the last decades, very little has been made A. Experienced Challenges
available in industrial tools. If we want the MBE tools to
In contrast to weekly sprints and their central paradigm
evolve and provide more capabilities, we need to increase
of a gradual change, traditional strategies for introduction
technology transfer. To achieve effective technology transfer,
of MBE usually emphasize on a methodological paradigm
the MBE community needs to collaborate together on the
shift. It is argued that this shift needs extensive MBE training
development of an open source MBE tooling platform that
programs for employees and investments in new tool suites
can be used by both industrial developers and researchers to
both supervised by experienced modeling advocates. These
develop tools and capabilities. We believe that it is the only
programs are planned for a longer period and are promoted to
pragmatic way to obtain the ever-evolving set of capabilities
the management with the promise of a drastic improvement
that we need.
of the development efficiency. The size of these programs,
B. Proposed Research Directions however, turns out to be a classical showstopper in practice
Regarding research directions, we believe that the following for the following simple reason: Upcoming deadlines remain
three topics are key to broaden the use of MBE in the industry. demanding and the agile development team is moving forward,
while the modeling advocates are still focusing on various
• DSL support. We need more research focused tool
long-term investigations. Once the modeling advocates are
support for DSL, in particular on UML-based DSL so
presenting the initial MBE-based approach, they usually miss
that we can get in the same MBE tools the full benefits of
the latest requirements of the next upcoming deadline. The
UML as a standard modeling language and the strength of
result will thus not be accepted by the development team and
DSL. Also, we need to research focus on how to combine
prevents the MBE approach to achieve critical momentum.
different DSLs in the same modeling environment/tools.
• Model diff/merge. We need to increase focus on model
B. Proposed Research Directions
diff/merge to address existing issues. In particular, we
need scalable model diff/merge support for DSL. Instead of a radical paradigm shift from traditional de-
• Model review. MBE tools currently dont provide real velopment methods to MBE, there is a strong need for a
capabilities for model review. Typically, people do model strategy about a gradual introduction of MBE. In [12], a
review by generating PDF documents from models and corresponding MBE introduction strategy is proposed by the
providing comments in the PDF documents. Firstclass definition of so-called MBE micro injections. These MBE
model review is required to enable efficient use of MBE. micro injections are intended to go along agile development
Finally, we need to better understand how to develop processes and the related effort of one MBE micro injection
and establish vibrant open source communities to foster is manageable within one development sprint. Furthermore,
innovations and enable efficient technology transfer. the benefits and drawbacks of a single MBE micro injection
have to be quantifiable in relation to a traditional approach to
III. I NCREMENTAL I NTRODUCTION OF MBE convince the development team. If the concrete numbers favor
As one reaction to limited MBE tool capabilities, the indus- the MBE approach, it has to be capable of being integrated
try is favoring alternative development strategies such as ag- to the main development trunk within the next development
ile development in combination with traditional development sprint. To ensure sustainability, the development team takes
technologies. This is despite a common agreement within the over responsibility from the modeling advocate during this in-
modeling community that agility and the application of MBE tegration. Adequate tool support is fundamental to support the
co-existence MBE micro injections and traditional approaches related to mistakes they had made in their models. In the
during the gradual introduction phase. course project, students work in teams of 6 to 8 people. Due
Domain-specific languages (DSLs) are promising candi- to the weak support for collaboration, as discussed in Section
dates to fulfill the requirements of MBE micro injections. 2, we observe that students typically resort to work on a single
However, a DSL design step and the development of a computer or develop a complex manual process to deal with
related end-user tool to promote the DSL must be feasible changes on different computers.
during a sprint to be accepted by the development team. Finally, a challenge we encountered regularly is a lack
Rapid prototyping must thus come along with a high degree of tool support. Official documentation is often outdated or
of automation (e.g. DSL editor generation) besides further incomplete. Due to its rapid evolution during the last three
aspects such as a high tool matureness (in terms of stability, years, this is especially true for Papyrus. Additionally, in
usability and documentation), straightforward integration in official documentation for industry-grade modeling tools it is
existing industrial development tool chains (e.g. Visual Stu- usually assumed that the reader is a modeling expert, which
dio), sophisticated collaboration features and composability of is clearly not the case for students. Similarly, in order to be
intermediate and distributed MBE approaches across working able to ask questions on a support forum, the students often
groups and departments. Despite of promising candidates (e.g. lack knowledge of how to phrase their questions, or even
the Eclipse eco-system), none of the established MBE tools to distinguish a tool-related question from a language-related
are currently mature enough in all mentioned fields. A missed question. Therefore, we have during the last years resorted to
deadline due to this, however, contradicts the vision of a MBE giving dedicated tool support during lectures and, recently, in
micro injection and undermines the fragile trust between the the form of short videos that introduce different topics in a
modeling advocate and the development team. concise way.
IV. U SAGE OF MBE T OOLS IN E DUCATION B. Proposed Research Directions
For MBE to be adopted successfully in industry, appropriate Several of the challenges we encounter are identical to the
university education on the topic is instrumental. Our experi- challenges in industry. For example, we also see the clear
ence is drawn from four years of teaching a Bachelor-level need for customization and DSL support. While simplified,
course on model-based software development at Chalmers education-specific tools are clearly a way to tackle the com-
University of Technology and Gothenburg University in plexity our students encounter with industrial MBE tools, we
Gothenburg, Sweden. During each year, approximately 120 to often experience that these tools are built with a specific
150 students took this 8-week long course. The course consists course design in mind. Hence, they might be restricted to
of several lectures on the topic of modeling, in particular a certain process and diagram types. Therefore, we believe
UML, and a group project. While the syntax of several UML that to address complexity of MBE Tools, tool developers
diagrams is introduced, the course focus is on the semantics of and researchers should investigate how industrial tools can
the produced models and several different purposes of using effectively be customized in a quick fashion without expert
models, from informal models for communication purposes to tool knowledge. In particular, it should be possible to adapt
models for code generation. a tools customization after it has been installed, e.g., to
Three different tools have been used throughout the four re-distribute it to students or employees when changes are
course years. In the first year, we used a commercial MBE necessary. Furthermore, we need better team support and
tool that supports executable models (the academic license collaborative modeling to allow students to effectively work
agreement prohibits us to name the tool). In the remaining in groups.
three years, we used Papyrus. In the fourth year, we addi- Additionally, we also see multiple directions for research
tionally used Yakindu to allow students to explore executable aimed specifically at modeling education. Based on the chal-
state machines. From the second year on, the students were lenge to distinguish tool errors from mistakes resulting from a
required to build a running system from the generated code. lack in understanding, we propose to research how students
We provided in all four years tool support through a dedi- can be provided with feedback on their models in a con-
cated teacher instead of relying on official tool documentation. structive way. Similar work has been conducted in the area
However, the amount of support we could provide varied of programming education, e.g., in [13], [14]. It is important
depending on resources. to note that this research is not only restricted to tool features
or automated feedback, but could also be in terms of novel
A. Experienced Challenges course designs or processes that ensure that students receive
Industrial MBE tools are often reported to contain many sufficient and constructive feedback, such as in [14].
bugs and have low usability. Additionally, we often observe
that students have difficulties to distinguish actual tool errors V. D EVELOPMENT OF MORE USABLE MODEL
TRANSFORMATION TOOLS
from mistakes in their model. For example, when we used
code generation students would often attribute errors during We discuss the challenges during development of model
code generation to bugs in the modeling tool. When asking transformation tools with a higher usability using Henshin as
the teachers for help, we discovered that the errors were rather a case. Henshin is an Eclipse-based Model Transformation
Language based on the Graph Transformation formalism. It nature makes it more difficult to understand how rules are
uses a declarative way to specify model transformations by executed and the sequences of actions are not explicitly
defining pre- and postconditions. Henshin and predecessors expressed by the developer but automatically inferred and
have been around since 2009 and heavily use tooling of the optimized by the engine.
Eclipse Modeling Framework ecosystem, e.g., generation of
graphical and tree editors. Recently, we developed several B. Proposed Research Directions
usability improvements with respect to syntax checks when We see a need for a more systematic usability engineer-
executing model transformations from plain Java code, a ing support in MBE tool development. Particularly, we are
textual syntax, and generation of transformation rules [15]. wondering whether existing usability engineering techniques
[16] can simply be reused, and are maybe often ignored,
A. Experienced Challenges or specific techniques for MBE need to be researched. For
A major challenge during the development of Henshin is a example, there could be a significant difference in usability
rather big gap between the abstract syntax and the concrete requirements between the developer of MBE tools and expert
syntax. Graph transformation based model transformations de- users on the one side and non-expert users and domain experts
fine a precondition (called Left Hand Side) and a postcondition on the other side.
(called Right Hand Side) on the to-be-transformed model Furthermore, while we developed a textual editor for Hen-
part. Henshin and most graph transformation languages use a shin [15] for an easier specification of transformation rules, we
shorthand notation as concrete syntax, where the left hand side still see the value of graphical editors. However as discussed
and right hand side is combined and the changes to transform in Section 2, we need both types of editors highly integrated,
the model from the pre-condition into the post-condition are as shown in an early prototype [17], and the corresponding
explicitly annotated. However, the abstract syntax of Henshin development frameworks which makes those editors easy to
is based on the explicit distinction between the left and the develop.
right hand side. This leads to a big gap between the concrete
syntax and the abstract syntax and is out-of-the-box not well VI. U SER E XPERIENCE OF G RAPHICAL M ODELING T OOLS
supported by frameworks for graphical. Hence, we had to add The user experience plays an important role in the accep-
many manual changes to the generated code of the graphical tance of a tool. If the creation and editing of a model is painful
editor. First, these manual changes are difficult to correctly do and time-consuming, the advantage of MBE by shortening the
and require a rather big effort. Second, these manual changes development time can melt dramatically.
complicate further usage of the frameworks code generation Besides MBE tools for fixed models like UML, a set
capabilities and, thus, hampers development. of frameworks were built to support development and/or
Furthermore, one of our recurring experiences in MBE tools generation of graphical modeling editors for a DSL. These
is that they often focus on functionality. Particularly, we be- frameworks (e.g. GMF, Sirius, MPS, and graphiti) reduce the
lieve that we, as a community, much more value functionality effort for the developer tremendously. Unfortunately, these
over usability. A researcher will get a paper on new language frameworks are optimized for fast development, and thus
features or performance improvement accepted, but work on helpful for the introduction of MBE (see Section 3), but not
simply improving usability of existing tools is difficult to for a comfortable and user-optimized usage. In the following,
measure and to publish. For example, the MODELS 2017 we focus on our experiences with these generator frameworks.
main program does only have 2 papers which cover usability, 7
mention it somewhere as something important or future work, A. Experienced Challenges
and 27 ignore it. Hence, we believe there is a systematic bias One of the main problems is the correct-by-construction
against usability improvements to MBE tools. This has been approach of the underlying GEF framework. This means that
also our experience, while working in industry, developing any editing step must result in a (syntactically) correct model.
modeling tools. Obviously, this is useful from the developer view, because any
With respect to model transformations, there have been diagram is a representation of the model. It is not necessary
numerous papers on search plan optimization and other kinds to deal with two kinds of models: one (possibly incorrect) for
of automatic performance improvement. However, to the best the graphical editing and one for further processing.
of our knowledge there does not yet exist an easy way Considering the users view, it is often painful to ensure
for developers of graph transformations to understand how that any editing operation does not contain any intermediate,
transformation rules are executed and the specific impact of incomplete model. In the simplest case, the tool enforces the
changes in their transformation rules have on the performance user to do some editing in a specific order. For example, if
of model transformation executions. an edge exists between two nodes and the user wants to add
Similarly, often modeling tools do not provide easy to another node in the middle of the edge, then, first, she has
use debugging capabilities. Particularly, for declarative model to create the new node, attach the start or the end point of
transformation languages like Henshin, it is very difficult for the existing edge to the new node and then create a new edge,
developers to understand why a model transformation rule correspondingly. It is not possible to first detach the edge from
does not work as intended, particularly, since the declarative one of the existing nodes.
Another example is to remove the surrounding state of a To tackle existing challenges, we outline directions for
hierarchical state in a state chart, i.e., to move the contained future work in the area of MBE tooling. These directions can
states one level up. In most tools deleting the surrounding state be separated into directions for research, e.g., improved model
results in a deletion of the containing states as well. At least, diff/merge capabilities and novel MBE introduction strategies,
any edge to or from the surrounding state is removed, because directions for industry and communities like improved tech-
otherwise these edges are not connected to two nodes. In this nology transfer and initiatives to start and foster open source
case, the user has to redraw the edges again or she has to move communities around MBE, and directions for academic policy,
all contained states to the same level as the surrounding state, e.g., an increased focus on tool creation or improvements in
modify the edges, remove the surrounding (and now empty) tenure procedures.
state, and rearrange the states to their original position. ACKNOWLEDGMENT
Problems like these are the reason why simple drawing tools
like Microsoft Visio or even Powerpoint are often preferred This work was partially funded by the German Research
for creating graphical models. These tools do not restrict Foundation (DFG) as part of the DFG Priority Programme
the users in their workflow. The avoidance of incomplete 1593 (TI 803/2-2 and TI 803/4-1).
graphical representations of models is in contrast to the textual R EFERENCES
representation. In a text editor, most of the time, the actual [1] G. Liebel, N. Marko, M. Tichy, A. Leitner, and J. Hansson, “Model-
text does not represent a correct model. Only at specific based engineering in the embedded systems domain - an industrial
times, when the text is parsed, it is necessary that the text survey on the state-of-practice,” Software & Systems Modeling, Mar.
2016.
is syntactically correct. [2] L. T. W. Agner, I. W. Soares, P. C. Stadzisz, and J. M. Simão, “A
The need for incomplete graphical models in MBE tools brazilian survey on UML and model-driven practices for embedded
becomes even larger, if textual and graphical models are used software development,” Journal of Systems and Software, vol. 86, no. 4,
pp. 997–1005, 2013.
in a hybrid view, where the underlying model can be edited [3] A. Forward and T. C. Lethbridge, “Problems and opportunities for
either by using a textual or graphical representation and it model-centric versus code-centric software development: a survey of
should be possible to change between these views at any time software professionals,” in International Workshop on Modeling in
Software Engineering, MiSE 2008, Leipzig, Germany, May 10-11, 2008,
as discussed in Section 2. J. M. Atlee, R. B. France, G. Georg, A. Moreira, B. Rumpe, S. Völkel,
and S. Zschaler, Eds. ACM, 2008, pp. 27–32.
B. Proposed Research Directions [4] S. Kirstan and J. Zimmermann, “Evaluating costs and benefits of
model-based development of embedded software systems in the car
In order to improve the user experience of graphical editing industry–results of a qualitative case study,” in Proceedings Workshop
tools, we propose the following three research directions: C2M: EEMDD ”From code centric to model centric: Evaluating the
effectiveness of MDD” ECMFA, 2010.
• Comprehensive studies with industrial users have to be
[5] P. Baker, S. Loh, and F. Weil, “Model-driven engineering in a large
conducted to gain more insight into the required features industrial context - motorola case study,” in Model Driven Engineering
enabling a faster editing of models. Languages and Systems, 8th International Conference, MoDELS 2005,
Montego Bay, Jamaica, October 2-7, 2005, Proceedings, ser. Lecture
• Based on the results of these studies, improved prototypes
Notes in Computer Science, L. C. Briand and C. Williams, Eds., vol.
of editors supporting different kinds of graphical editing 3713. Springer, 2005, pp. 476–491.
tasks have to be evaluated with industrial users. [6] J. E. Hutchinson, J. Whittle, M. Rouncefield, and S. Kristoffersen,
“Empirical assessment of MDE in industry,” in Proceedings of the 33rd
• Finally, frameworks incorporating the results of the pre-
International Conference on Software Engineering, ICSE 2011, Waikiki,
ceding studies have to be developed. Honolulu , HI, USA, May 21-28, 2011, R. N. Taylor, H. C. Gall, and
N. Medvidovic, Eds. ACM, 2011, pp. 471–480.
VII. C ONCLUSIONS [7] J. E. Hutchinson, M. Rouncefield, and J. Whittle, “Model-driven engi-
neering practices in industry,” in Proceedings of the 33rd International
In this position paper, based on our cumulative experience Conference on Software Engineering, ICSE 2011, Waikiki, Honolulu ,
in industry, research, and education, we present current chal- HI, USA, May 21-28, 2011, R. N. Taylor, H. C. Gall, and N. Medvidovic,
lenges related to MBE tooling. Eds. ACM, 2011, pp. 633–642.
[8] P. Mohagheghi, W. Gilani, A. Stefanescu, M. A. Fernández, B. Nord-
We discuss the introduction of MBE tools in industry, which moen, and M. Fritzsche, “Where does model-driven engineering help?
is often hindered by outdated assumptions on the process and experiences from three industrial cases,” Software and System Modeling,
a slow return on investment. With respect to tool usage in vol. 12, no. 3, pp. 619–639, 2013.
[9] S. Karg, A. Raschke, M. Tichy, and G. Liebel, “Model-driven software
industry, we see that there are several key features currently engineering in the openetcs project: project experiences and lessons
missing that effectively prevent the use of MBE tools. These learned,” in Proceedings of the ACM/IEEE 19th International Confer-
are, e.g., a lack of collaboration facilities and customization ence on Model Driven Engineering Languages and Systems, Saint-Malo,
France, October 2-7, 2016, B. Baudry and B. Combemale, Eds. ACM,
support. Mirroring the industrial use of MBE tools, several 2016, pp. 238–248.
similar challenges can be seen in modeling education, which [10] P. Mohagheghi and V. Dehlen, “Where is the proof? - A review
suggests that the topic of MBE education should not only of experiences from applying MDE in industry,” in Model Driven
Architecture - Foundations and Applications, 4th European Conference,
be studied in isolation. Using and building MBE tools in an ECMDA-FA 2008, Berlin, Germany, June 9-13, 2008. Proceedings, ser.
academic environment, we observe that the user experience Lecture Notes in Computer Science, I. Schieferdecker and A. Hartman,
and usability of existing tools and tool-building frameworks Eds., vol. 5095. Springer, 2008, pp. 432–443.
[11] A. Forward, O. Badreddin, and T. C. Lethbridge, “Perceptions of
are low, but at the same time that academic policies do not software modeling: a survey of software practitioners,” in Proc. of
effectively encourage improvements within academia. C2M:EEMDD, 2010.
[12] G. Stieglbauer and I. Roncevic, “Objecting to the revolution: Model- [15] D. Strüber, K. Born, K. D. Gill, R. Groner, T. Kehrer, M. Ohrndorf,
based engineering and the industry - root causes beyond classical and M. Tichy, “Henshin: A usability-focused framework for EMF
research topics,” in Proceedings of the 5th International Conference on model transformation development,” in Graph Transformation - 10th
Model-Driven Engineering and Software Development, MODELSWARD International Conference, ICGT 2017, Held as Part of STAF 2017,
2017, Porto, Portugal, February 19-21, 2017., L. F. Pires, S. Hammoudi, Marburg, Germany, July 18-19, 2017, Proceedings, ser. Lecture Notes in
and B. Selic, Eds. SciTePress, 2017, pp. 629–639. Computer Science, J. de Lara and D. Plump, Eds., vol. 10373. Springer,
[13] M. J. Lee and A. J. Ko, “Personifying programming tool feedback 2017, pp. 196–208.
improves novice programmers’ learning,” in Proceedings of the Seventh [16] A. Seffah, J. Gulliksen, and M. C. Desmarais, Human-Centered Soft-
International Workshop on Computing Education Research, ICER 2011, ware Engineering - Integrating Usability in the Software Development
Providence, RI, USA, August 8-9, 2011, K. Sanders, M. E. Caspersen, Lifecycle, 1st ed. Springer Publishing Company, Incorporated, 2011.
and A. Clear, Eds. ACM, 2011, pp. 109–116. [17] S. Maro, J. Steghöfer, A. Anjorin, M. Tichy, and L. Gelin, “On integrat-
[14] A. Vihavainen, M. Paksula, and M. Luukkainen, “Extreme apprentice- ing graphical and textual editors for a UML profile based domain specific
ship method in teaching programming for beginners,” in Proceedings language: an industrial experience,” in Proceedings of the 2015 ACM
of the 42nd ACM technical symposium on Computer science education, SIGPLAN International Conference on Software Language Engineering,
SIGCSE 2011, Dallas, TX, USA, March 9-12, 2011, T. J. Cortina, E. L. SLE 2015, Pittsburgh, PA, USA, October 25-27, 2015, R. F. Paige, D. D.
Walker, L. A. S. King, and D. R. Musicant, Eds. ACM, 2011, pp. Ruscio, and M. Völter, Eds. ACM, 2015, pp. 1–12.
93–98.