Assessment of EMF Model to Text Generation Strategies and Libraries

in an Industrial Context

Christophe Ponsard, Denis Darquennes, Valery Ramon and Jean-Christophe Deprez

CETIC Research Centre, Charleroi, Belgium

Keywords:

Model-based System Engineering, Model to Document, Tool Support, Industry Transfer, Eclipse Modelling

Framework.

Abstract:

Model-Based System Engineering is increasingly adopted. However it is centred on the notion of model while

the industry is still strongly document-based. In order to enable a smooth evolution between those paradigms,

the interplay between documents and models need to be managed, especially models can be used to efﬁciently

derive up-to-date documents matching standard templates from initial requirements to ﬁnal certiﬁcation. The

purpose of this paper is to review and to assess current strategies to manage model for document generators in

order to meet industrial requirements like document complexity, document/model scalability, quick generation

time, maintainability and evolvability of document templates. After exploring different generation strategies,

our work focuses on toolchains based on the Eclipse Modelling Framework and compares a few shortlisted

libraries in the light of our requirements and using document derived from industry cases.

1 INTRODUCTION

Because of its capability of abstraction/reasoning on

real world artefacts before building them, modelling

has been widely used across many engineering dis-

ciplines like construction, electronics or aeronau-

tics. Model-Based System Engineering (MBSE) is a

strong trend to apply modelling at system level and

across disciplines. For the industry, it is however a

paradigm shift because domain models become the

central part for the exchange between engineers rather

than documents. Model-Driven Engineering (MDE)

is a similar trend focusing only on the software devel-

opment process (Schmidt, 2006). Such approaches

can rely on standardised and widely adopted mod-

elling languages like SysML (OMG, 2005) at system

level, UML (OMG, 1997) for software and increas-

ingly Domain Speciﬁc Languages (DSLs). They pro-

vide a visual syntax enabling the design and commu-

nication activities of the engineers but also have pre-

cise semantics to enable automation of parts of the

System Development Life Cycle (SDLC).

Being able to synchronise model and text is a key

element for the industrial adoption of model-based

toolchains because documents are and will certainly

remain central to industrial development and valida-

tion workﬂows for a long time, even though the goal

is to progressively reduce them. Documents will stay

mandatory for the identiﬁcation of requirements, re-

view and validation at various SDLC steps and for

speciﬁc activities like certiﬁcation. This synchroni-

sation involves different interactions between models

and documents, like identifying concepts from docu-

ments, generating documents from models or keeping

both artefacts synchronised over the system evolution.

In our previous work, we have investigated different

kinds of such interplays using diagrams, tables and

texts (Ponsard et al., 2015) and for re synchronising

models from documents (thus achieving rountrip with

document generation) (Ponsard and Darimont, 2017).

This work focuses on model to text document

generation. This may seem easy to achieve at ﬁrst

sight but requires to fulﬁl a number of key require-

ments, both functional and non-functional, in order

to meet industry standards. Based on our experience

with industrial customers, we could identify such re-

quirements and also evaluate how currently available

technologies fulﬁl them. Then, we review different

document generation strategies with different possi-

ble trade-offs, e.g. favouring multiple output formats

through an intermediary format/API or directed to-

wards a speciﬁc format with more features and per-

formance. Our work is more speciﬁcally addressing

modelling solution based on the Eclipse Modelling

Framework (EMF) because it is an open industrial

standard and also because it ﬁtted our industrial con-

Ponsard, C., Darquennes, D., Ramon, V. and Deprez, J.

Assessment of EMF Model to Text Generation Strategies and Libraries in an Industrial Context.

DOI: 10.5220/0009155804330440

In Proceedings of the 8th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2020), pages 433-440

ISBN: 978-989-758-400-8; ISSN: 2184-4348

433

text. However, the same requirements and evaluation

process may be reused for other modelling technolo-

gies, including closed ones. The last part of our work

further investigates and compares a few solutions. It

benchmarks prototypes against a test suite covering

the target requirements and relying on real-world doc-

uments produced by industrial partners in two real-

world and complementary toolchains, one Eclipse-

based (Capella) (Polarsys/CIS, 2015) and the other

web-based with a SaaS model (Respect-IT, 2005; Da-

rimont et al., 2016). Note however that for conﬁden-

tiality purposes excerpts presented are based on the

public in-ﬂight entertainment model (Bonnet, 2015).

This paper is structured as follows. Section 2 re-

minds about key industry requirements. Then Sec-

tion 3 surveys possible generation strategies based on

both literature and industry practices. Section 4 de-

tails different candidate libraries focusing on direct

generation for an EMF toolchain. Section 5 presents

our benchmarking process, test data and raw results

which are analysed in Section 6. Finally Section 7

concludes and discusses some complementary work.

2 INDUSTRY REQUIREMENTS

FOR DOCUMENT

GENERATION

In order to base our comparison on sound crite-

ria, key industrial requirements have been gathered

and grouped in two categories: functional and non-

functional. Criteria identiﬁed in bold are evaluated

later in this paper and are independent of any speciﬁc

context (e.g. EMF).

2.1 Functional Requirements (FRs)

Industrial speciﬁcations are complex in nature and

are characterised by a well-deﬁned structure usually

based on templates. An elegant way to introduce

MBSE is to use enriched templates specifying how

to populate the document, in the same format of ex-

isting corporate templates. The document generator

needs to support a variety of standard formats used

in the industry, typically Microsoft (docx) or LibreOf-

ﬁce (odt). Non editable formats like PDF and HTML

may be useful too although easy to derive. Other tar-

get formats may also be interesting, e.g. spreadsheets

or presentations. On the model side, our focus is the

support of Eclipse Modelling Framework standard.

As shown in Figure 1, such documents also usu-

ally combine

Figure 1: Excerpt of a complex speciﬁcation document mix-

ing text, diagram and tables.

• text descriptions, e.g. for requirements or func-

tion descriptions with speciﬁc writing conven-

tions. This typically requires the use of rich text

(as bold, italic, underline, bullets...).

• ﬁgures, where especially the inclusion of dia-

grams from the model should be easy, using stan-

dard formats (e.g. png, svg) and with a good qual-

ity.

• tables, to more systematically present well-

structured concepts (e.g. requirements tables with

identiﬁer, deﬁnition, priority, effort...), system de-

composition (subcomponents, interface compo-

nents) or some speciﬁc view (e.g. traceability

matrix). Although tables can be managed using

spreadsheets, the direct generation of tables is

mandatory.

The overall structure and consistency requires auto-

mated section numbering and styles. Other impor-

tant features are the generation of bookmarks to ease

the navigation in large documents. Table of contents

are already managed by standard templates.

2.2 Non-Functional Requirements

(NFRs)

The following classiﬁcation is inspired from the

SQuaRE classiﬁcation (ISO, 2014) used as checklist,

key NFRs are:

• Costs relates to a number of attributes. About ac-

quisition costs, the library maybe Free of charge

or even Open Source. However more important

cost factors relate to the adaptation and mainte-

nance of the solution which may require long term

support. This can be evaluated by the global Ma-

turity of the product (known bugs, documenta-

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

434

tion, tutorials...) and its support, either commer-

cial or through a community.

• Scalability is a mandatory requirement. The size

of industrial system means large model and thus

the ability to generate large documents gener-

ally also based on complex templates.

• Efﬁciency is less critical in case of batch/server

based generation. However, for laptop generation

or when frequently update of a work document or

developing a template, good speed of generation

(i.e. under a minute) is important. Reducing the

generation scope may also be used to accelerate

modelling/generation cycles.

• Usability is important for industrial adoption. We

should not assume the developer/maintainer of

a generator template has a programming back-

ground and favour declarative and easy to learn

tools. Two complementary levels need to be

easy to use: how to retrieve information from the

model and how to present that information in the

document under the adequate form (see FR). This

requires a good learning curve of the associated

language (preferably standard like OCL), good

writing support for both of the above levels and

good readability, i.e. to maintain and evolve the

generator template, preferably with some mod-

ularity feature. In order to invoke the tool, a

good user interface integration with the mod-

elling tool is required while a portable API (e.g.

Java) is also useful for non UI invocation, e.g. for

batch/nightly document regeneration.

3 MODEL TO DOCUMENT

GENERATION STRATEGIES

Different strategies may be considered to produce a

document from a model. In this section, we review

the available design space and give some high-level

guidelines that can help drive the choice based on typ-

ical trade-offs that need to be considered.

Template-based Generation. The most obvious

choice is to use a single transformation tool able to

convert a model into the target document format based

on a transformation speciﬁed through some template

which can take the form of a speciﬁc format (e.g.

XML with a speciﬁc schema) or a Domain Speciﬁc

Language (DSL). This simple design helps to give

good control on the available features and perfor-

mance. However, restricted choices may be available

for the model source/target document format combi-

nation. If multiple document formats need to be con-

sidered, developing independent converters for each

format is not a good idea because the template design

will not be reused. An additional converter might be

chained to transform the target document into other

formats if the converter is reliable enough (e.g. to

produce a PDF from most editable formats). In this

context, we obviously restrict to Model-to-Text gen-

eration tools. This transformation can be managed by

an independent library, e.g. Gendoc (Eclipse, 2018)

or M2Doc (Obeo, 2019) for EMF) or directly inside a

Word processor through internal macro/scripting. The

latter is not recommended because the scripting lan-

guage is not effective and maintainable for such trans-

formation and for accessing a model repository. An

editor is also not optimised for generation and should

not be required at this step.

Generic Reporting Tools. Efﬁcient reporting tools

exist and are able to generate many different tar-

get document formats either editable (ofﬁce docu-

ments but also spreadsheets or even presentations) or

read-only (PDF). Birt (Eclipse Foundation, 2005) and

Jasper (Jaspersoft, 2005) are examples of such plat-

forms. They usually rely on an internal report descrip-

tion format that is populated from one or several data

sources. The usual scenario is rather to generate busi-

ness reports from spreadsheets or relational databases.

However, data sources can be extended through ad-

ditional drivers through a protocol such as the Open

Data Access (ODA) which includes support for con-

necting, accessing meta-data, and executing queries.

It is not restricted to classical relational databases and

can also be used for model-based repositories. For ex-

ample, an EMF connector is available and can be used

together with Birt (Eclipse Foundation, 2008) with

queries in OCL. The developed template can then be

run in server mode. The performance might be im-

pacted by the efﬁciency of the query engine. Alter-

natively, an intermediate data ﬁle in a speciﬁc format

might also be produced from the model and fed more

efﬁciently in the reporting tool.

Existing Modelling Platforms. Some modelling

platforms integrate reporting capabilities and some

also support model interchange, e.g. the MagicDraw

tool can process EMF and also generate ﬁles us-

ing Velocity Template Library (Apache Foundation,

2006). However, this setting is hard to automate and

reuse outside of this speciﬁc toolchain even though

some parts might be open source.

Relying on an Intermediary Format. Is an inter-

esting option because such a format can stay abstract

enough to capture the essence (semantics) of the re-

Assessment of EMF Model to Text Generation Strategies and Libraries in an Industrial Context

435

port without focusing on the concrete presentation.

From that format, different target formats may be gen-

erated. Reporting tool template follows that princi-

ple but other options are possible and an open for-

mat should be favoured. For example, XML Doc-

Book (Walsh and Hamilton, 2010) format can be

processed using W3C Formatting Object (XSL-FO)

and then to standard format such as PDF and RTF

to some extend. Such an approach was applied by

JPL on MagicDraw (Delp et al., 2013). Another

more lightweight option is to use a variant of mark-

down language relying on plain text formatting syn-

tax (Gruber, 2004). Based on this format, many

concrete document formats can be generated using

universal transformers such as Pandoc (MacFarlane,

2006). Of course, the ﬁnal quality should be care-

fully assessed w.r.t. all required features described in

Section 2. An interesting variant here is also to intro-

duce a meta-model for the document itself which en-

ables to use generally more powerful Model-to-Model

transformation like the QVT Query/View/Transform

standard (OMG, 2011) for dealing with the transfor-

mation with an additional serialisation to the textual

output format (Willink, 2018). A more elaborated

form of intermediary is to use a Domain Speciﬁc Lan-

guage directly embedding the model transformation

language. pxDoc detailed later is based on this ap-

proach (Pragmatic Modeling, 2019).

An open discussion point is whether the target for-

mat should be editable or not. While the latter ensures

all changes are made inside the model, most of the

time an editable format is preferred to enable integra-

tion, style adaptations and unfortunately some correc-

tions which are then lost unless some synchronisation

mechanism is used (Ponsard and Darimont, 2017).

Finally note that although we tried to provide a

consistent classiﬁcation, the above categories are not

mutually exclusive. For example, generic reporting

tools also rely on a template. Exiting tools may use an

intermediary format or use an external generation li-

brary. This cannot always be assessed (e.g. for closed

tool). A key point guiding the classiﬁcation design

was the kind of interface and integration capability.

4 TEMPLATE-BASED

GENERATION LIBRARIES

The rest of this document will focus on the single step

generation strategy. Although it is less able to cope

with multiple formats, it was selected for further study

in both of our industrial cases. After discarding low-

level generations libraries lacking any modelling sup-

port such as POI or VTL (Apache Foundation, 2006),

we shortlisted three candidates which are presented

hereafter. All of them rely on OCL (or variant) as

model query language.

4.1 Gendoc

Gendoc (Eclipse, 2018) is an Open Source library de-

veloped by the Eclipse Foundation under its EPL li-

cense. It supports the generation of documents based

on EMF models in different formats from Microsoft

Ofﬁce (docx, xslx, pptx) and Libre Ofﬁce (.odt). Gen-

doc relies on existing templates for the general struc-

ture and styling while the content is speciﬁed using

XML tags embedding commands for generating rich

text, diagrams and tables. It strongly relies on the

Acceleo Query Language (AQL), an OCL variant to

dynamically retrieve content from the model. It is

also compatible with the Papyrus (Eclipse, 2010) and

Capella (Polarsys/CIS, 2015) modellers.

Figure 2: Fragment of Gendoc template.

Figure 2 shows an example of template built using

Gendoc. It is divided in two parts respectively marked

by the context and gendoc tags. The context con-

tains the absolute path to the model, the searchMeta-

model and importedBundles information. The gen-

doc section contains a static text ”List of entities”,

followed by a variable self.name which is the name

of the model. A for loop lists inside the model the

names of the entities resulting from the AQL request

allInstances()->sortedBy(name)”. Figure 3 shows

the result generated from this fragment.

Figure 3: Result of the fragment of Gendoc template.

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

436

4.2 M2Doc

M2Doc (Obeo, 2019) is an Open Source library (EPL)

developed by Obeo to generate documents from EMF

models. Like Gendoc, it relies on the combination of

a document template with AQL. The main differences

are the limitation to Word documents (.docx) and the

use of special ﬁelds of the form { m: <content>

} rather than XML tags for retrieving the model ele-

ments, resulting in a better readability. M2Doc relies

on ApachePOI for creating docx ﬁles. Figure 4 shows

an example of fragment of M2Doc template function-

ally equivalent to the Gendoc fragment presented in

Figure 2 and producing the same result as in Figure 3.

The elaborated document presented in Figure 1 was

also produced using M2Doc from the public in-ﬂight

entertainment model (Bonnet, 2015).

Figure 4: Fragment of M2Doc template.

4.3 pxDoc

pxDoc (Pragmatic Modeling, 2019) is a commercial

library used to generate Microsoft Word documents

from EMF models. It requires an end-user license.

Contrary to Gendoc and M2Doc, it does not extend

an existing document template with queries to retrieve

model content. Instead, a textual Domain Speciﬁc

Language (DSL) is used for transforming the model

into text and applying styles referenced from an ex-

isting and unmodiﬁed template. Figure 5 shows how

to retrieve the same content than in the Gendoc and

M2Doc sections, by using model navigation expres-

sion in a format closed to OCL and AQL queries.

Styling is applied using styling reference like #Ti-

tle1 and speciﬁc command like numbering to control

Figure 5: Fragment of pxDoc template.

the numbering level. The DSL is implemented with

EMF and XText technologies that are completely in-

tegrated with the Eclipse development environment

and Eclipse-based modellers like Papyrus (Eclipse,

2010) and Capella (Polarsys/CIS, 2015).

Compared to GenDoc and M2Doc, pxDoc is

closer to coding and has a direct integration with Java

and Eclipse. The DSL looks like a simpliﬁed form

of Java and is not complex to learn. The DSL edi-

tor provides productivity features like syntax check-

ing and content assist, including to navigate into the

target model when writing a query. This greatly ac-

celerates the development of a document generator. It

also does not require Word in this phase.

5 ASSESSMENT OF SELECTED

GENERATION LIBRARIES

This section presents our assessment of the libraries

shortlisted in Section 4. Our assessment was based

on prototyping generation of realistic industrial doc-

uments without prior knowledge of the libraries. For

the models and templates, we used the publicly avail-

able in-ﬂight entertainment system (Bonnet, 2015)

and models provided by two industrial partners: one

producing large design documents for railways sys-

tems and the other producing very elaborated require-

ments documents for large call for tenders.

Table 1 and 2 present the assessment respectively

for the functional and non-functional criteria deﬁned

in Section 2. Criteria are ranked either on a binary

Table 1: Comparison of selected libraries for the functional criteria.

Gendoc M2Doc pxDoc

EMF support x x x

Standard formats supported docx, odt, docx docx

xlsx, pptx

Use of enriched templates x x -

Rich text inclusion x - x

Diagram inclusion x x x

Table generation x x x

Section numbering x x x

Style support x x x

Bookmark/hyperlink generation x x x

Assessment of EMF Model to Text Generation Strategies and Libraries in an Industrial Context

437

Table 2: Comparison of selected libraries for the non-functional criteria.

Gendoc M2Doc pxDoc

Cost

Free of charge x x -

Open Source x x x

Maturity ++ + ++

Scalability + ++ +++

Efﬁciency

Large document + ++ +++

Complex template + ++ +++

Usability

Learning curve + + -

Writing support + ++ ++

Readability + +++ ++

Interface integration ++ + ++

Figure 6: Comparison of generation time for pure text document (left) and documents with ﬁgure (right).

scale (fulﬁlled=”x” and not fulﬁlled=”-”) or on a qual-

itative scale (from ”—” for very poor to ”+++” for

very good). For the scalability criteria, quantitative

benchmarks were run but are reported on a qualitative

scale with some additional comments. Note that due

to the preselection, the global ranking is rather good.

Table 1 shows that three preselected libraries pro-

vide good coverage of all functional criteria. A

weaker point for M2Doc is the current lack of support

for rich text import. Gendoc is the only to support the

Open Source odt format. Table 2 shows more con-

trasted results for the non-functional criteria that are

further discussed in Section 6.

About efﬁciency, our prototypes were bench-

marked using the same models to produce large doc-

uments (up to 1000 pages) on a standard laptop

(Core I7 2.8GHz with 16GB RAM running Windows

10). We considered simple templates (mostly sec-

tion, subsections and lists) and more complex tem-

plates (including ﬁgures and tables resulting from

complex queries). Figure 6 summarises our compar-

ison for Gendoc (V0.7.2), M2DOC (V2.0.2) and px-

Doc (V1.1.1):

• for pure text documents, the generation time re-

mains acceptable in all cases: less than 1 minute

• globally pxDoc is faster, probably due to the over-

head for interpreting AQL in M2Doc and Gendoc.

• Gendoc is slower, especially for generating large

documents with a complex template. For 1000

pages, it did not crash but took 15 minutes. For

M2Doc and pxDoc template complexity has a

limited impact resulting in the same curves.

• when considering ﬁgures, the results are slower

and more balanced: between 3 and 4 minutes for

500 pages. This is probably due to the similar ﬁg-

ure transfer time from Capella to the document.

Gendoc is slightly better than M2Doc here.

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

438

6 DISCUSSION: WHAT TO USE

AND IN WHICH CONTEXT ?

We provide here some guidelines to help in the se-

lection of libraries within the scope of the libraries

studied in Section 3. Section 2 gives more general

guidelines about other possible strategies but without

digging in concrete solutions. More detailed guide-

lines are out of the scope of this paper but part of our

future work.

Globally, pxdoc is quite different because it does

not extend existing templates but it requires a licence

and to learn a DSL. However it provides very effec-

tive tool support for writing templates. The solution

can be suitable for a big company which can afford a

license (e.g. a few ﬂoating might be enough) and with

usually quite stable templates and a dedicated trained

person in charge of the corporate templates.

Gendoc is a good solution for not too overly large

documents. However, XML tags are not easy to read

and also reduce the maintainability. The direct sup-

port for odt is a strong point if this is a standard for-

mat adopted by the company. It allows a fully Open

Source toolchain. The long term support needs to be

monitored as the project does not seem very active.

M2Doc is a more recent solution which still lack

some features like rich text and adapted if the focus

is on the docx format only. It is quite efﬁcient and

easy to learn and maintain due to the lighter form

of embedding. The use of a docx template requires

careful writing and a few cycle of debugging which is

decently supported by errors reported in a validation

document or directly inside the generated document.

The library is still actively evolving, although the last

version is quite behind schedule.

About the dependency over Eclipse, M2Doc is

quite easy to isolate and run outside of Eclipse, e.g.

to develop a web-based tool. On the contrary, Gendoc

has intricate Eclipse dependencies difﬁcult to isolate.

A workaround lacking efﬁciency and robustness is to

run Gendoc as console-mode Eclipse service.

7 CONCLUSION AND FUTURE

WORK

In this paper, we stated key industrial criteria for

model-based document generation. Based on those

criteria, we ﬁrst identiﬁed and discussed possible doc-

ument generation strategies with different beneﬁts

and drawbacks. Then, we focused on a direct gener-

ation strategy and assessed the best libraries for this

purpose and an EMF modelling context. As a re-

sult, we produced guidelines that we believe useful

for driving the selection of a generation solution in an

EMF context and, more generally, based on the iden-

tiﬁed criteria and assessment process.

In our future work, we plan to extend our bench-

marking to compare different strategies especially

with a generic reporting tool and an intermediary

markdown format. Different quality attributes will be

quantiﬁed in order to help selecting the best approach

given a speciﬁc industrial context. We will also keep

monitoring the evolution of the identiﬁed libraries and

also study new ones like Papyrus Model2Doc which

is announced (Lorenzo, 2019). Based on this we

could provide more extensive guidelines to help in the

decision process of a document generation solution in

the context of a set of speciﬁc requirements among

those we identiﬁed.

ACKNOWLEDGEMENTS

This research was partly supported by the IDEES Co-

innovation project (nr. ETR121200001379) of the

Walloon Region. We thank Respect-IT for its indus-

trial cases and feedback.

REFERENCES

Apache Foundation (2006). Velocity Template Library.

https://velocity.apache.org/engine/1.7/vtl-reference.

html.

Bonnet, S. (2015). In-ﬂight entertainment system model.

https://wiki.polarsys.org/Capella/Samples/IFE.

Darimont, R., Zhao, W., Ponsard, C., and Michot, A.

(2016). A modular requirements engineering frame-

work for web-based toolchain integration. In 24th

IEEE Int. Req. Eng. Conf., Beijing, China, Sept.

Delp, C., Lam, D., Fosse, E., and Lee, C.-Y. (2013). Model

based document and report generation for systems en-

gineering. In IEEE Aerospace Conference.

Eclipse (2010). Papyrus Modeler. https://www.eclipse.org/

papyrus.

Eclipse (2018). Gendoc - Generation of Documentation

from EMF models using document templates. https:

//www.eclipse.org/gendoc.

Eclipse Foundation (2005). Business Intelligence and Re-

porting Tools. https://www.eclipse.org/birt.

Eclipse Foundation (2008). Open data access driver. https:

//wiki.eclipse.org/Ecore ODA Driver.

Gruber, M. (2004). Markdown. https://daringﬁreball.net/

projects/markdown.

ISO (2014). 25000 systems and software quality require-

ments and evaluation (square). https://www.iso.org/

standard/64764.html.

Assessment of EMF Model to Text Generation Strategies and Libraries in an Industrial Context

439

Jaspersoft (2005). Jasper Reports. https://community.

jaspersoft.com/project/jasperreports-library.

Lorenzo, V. (2019). EclipseCON, Munich (accepted).

MacFarlane, J. (2006). Pandoc - a universal document con-

verter. https://pandoc.org.

Obeo (2019). M2Doc - generation of Ofﬁce Open XML

documents from EMF models and document template.

http://www.m2doc.org/ref-doc/2.0.2/.

OMG (1997). Uniﬁed modeling language. http://www.omg.

org/spec/UML.

OMG (2005). System modeling language. http://www.omg.

org/spec/SysML.

OMG (2011). MOF Query/View/Transformation. https://

www.omg.org/spec/QVT/1.1.

Polarsys/CIS (2015). Capella - open source solution

for model-based systems engineering. https://www.

polarsys.org/capella.

Ponsard, C. and Darimont, R. (2017). Improving Re-

quirements Engineering through Goal-oriented Mod-

els and Tools: Feedback from a Large Industrial De-

ployment. In Proc. 12th Int. Conf. on Soft. Tech., IC-

SOFT, Madrid, Spain, July 24-26.

Ponsard, C., Darimont, R., and Michot, A. (2015). Com-

bining Models, Diagrams and Tables for Efﬁcient Re-

quirements Engineering: Lessons Learned from the

Industry. In INFORSID 2015, Biarritz, France.

Pragmatic Modeling (2019). pxDoc - generate Word docu-

ments from Java. https://www.pxdoc.fr.

Respect-IT (2005). The Objectiver Goal-Oriented Require-

ments Engineering Tool. http://www.objectiver.com.

Schmidt, D. C. (2006). Guest editor’s introduction: Model-

driven engineering. Computer, 39(2):25–31.

Walsh, N. and Hamilton, R. L. (2010). DocBook 5: The

Deﬁnitive Guide. O’Reilly, Sebastopol, CA.

Willink, E. D. (2018). A text model - use your favourite

M2M for M2T. In Proceedings of MODELS 2018

Workshops, Copenhagen, Denmark, October.

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

440