Survey on Textual Notations for the Unified Modeling Language
Stephan Seifermann and Henning Groenda
Software Engineering, FZI Research Center for Information Technology, Haid-und-Neu-Str. 10-14, Karlsruhe, Germany
Keywords:
UML, Textual Notation, Survey, Editing Experience.
Abstract:
The Unified Modeling Language (UML) has become the lingua franca of software description languages.
Textual notations of UML are also accessible for visually impaired people and allow a more developer-oriented
and compact presentation. There are many textual notations that largely differ in their syntax, coverage of the
UML, user editing experience, and applicability in teams due to the lack of a standardized textual notation.
The available surveys do not cover the academic state of the art, the editing experience and applicability in
teams. This implies heavy effort for evaluating and selecting notations. This survey identifies textual notations
for UML that can be used instead of or in combination with graphical notations, e.g. by collaborating teams
or in different contexts. We identified and rated the current state of 16 known notations plus 15 notations that
were not covered in previous surveys. 20 categories cover the applicability in engineering teams. No single
editable textual notation has full UML coverage. The mean coverage is 2.7 diagram types and editing support
varies between none and 7 out of 9 categories. The survey facilitates the otherwise unclear notation selection
and can reduce selection effort.
1 INTRODUCTION
The Unified Modeling Language (UML) has become
the lingua franca of software description languages.
The UML specification comes with a graphical no-
tation, which is commonly applied. There is no
standardized textual notation. According to Spinel-
lis (Spinellis, 2003), textual notations provide an al-
ternative representation. It can be more compact or
more intuitive for certain user groups than the graph-
ical representation. An example is the textual repre-
sentation of an UML activity diagram-like specifica-
tion of a service’s behavior (Erb, 2011). The textual
version requires significantly less space for the repre-
sentation and is more intuitive to developers.
There are several tailored textual notations tai-
lored for specific purposes such as creating documen-
tation integrated in the code, having a more com-
pact representation, or increasing accessibility. They
largely differ in their syntax, coverage of the UML,
user editing experience, and applicability in an engi-
neering teams.
The latest surveys covering textual UML notations
were performed by Luque, et al. (Luque et al., 2014a;
Luque et al., 2014b). The former (Luque et al., 2014a)
focuses on the accessibility of UML for blind students
in classrooms and the latter (Luque et al., 2014b) on
tools for use-case and class diagrams used in indus-
try at 20 companies in the state of Sao Paolo (Brazil).
Both surveys target notations used in practice without
regarding the state of the art described in scientific
publications. (Mazanec and Macek, 2012) focuses on
textual notations in general but is a few years old and
covers few notations. It does not represent the current
development state and available variety of the nota-
tions and modeling environments. The three existing
surveys show that there is a wide range available with
individual advantages and drawbacks. They do not
analyze the user’s editing experience, which is cru-
cial for using a notation in a collaborating engineering
team, and requires heavy analyses effort. The overall
effort reduces the chance for a comprehensive analy-
sis and can endanger the selections’s quality.
The contribution of this survey is the identifica-
tion and classification of textual UML notations in-
cluding the user experience. Engineering teams can
use the classification for identifying appropriate no-
tations for their usage scenarios. The classification
scheme is tailored to support this selection. This sur-
vey examines accessibility of notations with respect to
their syntax, editors, and modeling environment. Us-
ability in realistic scenarios is determined by covered
diagram types, data format exchanges, and synchro-
nization approaches with other notations. It addition-
ally evaluates whether non-necessary parts of the no-
tation can be omitted. This sketch support eases low-
28
Seifermann, S. and Groenda, H.
Survey on Textual Notations for the Unified Modeling Language.
DOI: 10.5220/0005644900280039
In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 28-39
ISBN: 978-989-758-168-7
Copyright
c
2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
overhead discussion and brainstorming. For instance,
the UML specification allows to omit the types of the
class attributes.
The survey identified and rated 31 notations of
which 15 were not covered in previous surveys. 20
categories allow fine-grained pre-selection and cover
the applicability in engineering teams.
The remainder of this survey is structured as fol-
lows: Section 2 describes the review method of the
survey by defining the objectives and the review pro-
tocol consisting of three phases. Section 3 describes
the classification scheme based on the defined objec-
tives. Section 4 presents the analysis results in terms
of classified textual notations. Section 5 discusses the
validity of the results and the findings. Finally, Sec-
tion 6 concludes the paper.
2 REVIEW METHOD
The review process follows the guidelines of Kitchen-
ham and Charters (Kitchenham and Charters, 2007).
They developed guidelines for structured literature re-
views (SLR) in software engineering based on the
guidelines in the field of medical research. Their
guidelines cover the planning, conduction, and writ-
ing of reviews. Planning involves defining research
objectives and creating a review protocol describing
the activities in each step during the review conduc-
tion.
The following sections describe our implementa-
tion of the SLR and mapping to the proposed method.
The results of our search activities are documented
and available for reproducibility at http://cooperate-
project.de/modelsward2016.
2.1 Objectives
Our objectives are to determine each notation’s (O1)
coverage of the UML, (O2) user editing experience
and (O3) applicability in an engineering team. The
reasoning requires an analysis of the textual notations
and of the modeling environments. Section 3 presents
the detailed classification scheme based on the ob-
jectives and instructions on the according information
extraction procedure from literature.
2.2 Review Protocol
Figure 1 shows an overview of our review protocol.
We distinguish three phases during the conduction:
classic SLR, Quality Assurance and Complement.
The classic SLR follows the guidelines of review
conduction by Kitchenham, et al. (Kitchenham and
ad Quality Assurance
Identification of
Research
Study Selection
Study Quality
Assessment
Data Extraction
Data Synthesis
Identification of
Unpublished
Approaches
Build Reference
Closure
Reasoning
Check Availability
Study Selection
Study Quality
Assessment
Data Extraction
Data Synthesis
ad SLR ad Complement
Data Extraction
Data Synthesis
Figure 1: The three phases of the review conduction process
used in this survey.
Charters, 2007). We extend the SLR with two addi-
tional phases in order to increase the quality of the re-
sults and to take notations into account that are mainly
used in (industrial) practice: The Quality Assurance
phase focuses on incoming and outgoing literature
references as suggested by the Snowballing search
approach (Wohlin, 2014). In contrast to the original
proposal, we use Snowballing only to cross-check our
SLR search strategy. The Complement phase focuses
on textual notations that are available in practice but
are not scientifically published.
2.3 Phase 1: SLR
The review conduction according to (Kitchenham and
Charters, 2007) consists of the five activities marked
as SLR in Figure 1.
The Identification of Research describes the
search strategy for collecting literature. We chose a
keyword-based search approach using the search en-
gines ACM Digital Library, IEEExplorer, CiteSeer,
ScienceDirect, SpringerLink and Google Scholar.
These search engines cover relevant journals and are
suggested by Kitchenham and Charters for the soft-
ware engineering domain. We did not include EI
Compendex and Inspec as we could not query these
search engines without subscriptions. Their focus is
on high-qualitative entries and metadata and they do
not belong to a not-covered established publishing
authority. We are confident that the selected search
engines are sufficient and that no relevant paper is
not selected by our keywords because of insufficient
Survey on Textual Notations for the Unified Modeling Language
29
Table 1: Keyword groups used in search queries.
Group Keywords
Textual T CTS, textual modeling, textual mod-
elling, text-based modeling, text-
based modelling, textual notation,
text-based notation, textual UML,
text-based UML, textual syntax
UML U UML, unified modeling language,
unified modelling language
metadata provided by the selected engines.
We defined a set of keywords T for identifying
textual notations and another one U for identifying the
usage of UML. Both sets are shown in Table 1 and are
variations of our original terms textual notation, and
UML. They are based on commonly used terminology
in the modeling domain. A search query is given by
(t
0
t
1
. . . t
9
) (u
0
u
1
u
2
) with t
i
T u
i
U.
The query enforces the exact matching of keywords.
It considers abstracts and titles because this restricts
the search to literature that focuses on textual nota-
tions for UML. Google Scholar has API restrictions
that limit queries on abstracts to papers that have been
released at most one year ago. This restriction does
not apply to our title-based search. We restrict Sci-
enceDirect queries to computer science papers. We
implemented a search on the SpringLink results en-
abling keyword identification in the abstract. After
collecting the results of all search engines, we merge
them and filter duplicates.
Study Selection covers a rough screening based on
titles and abstracts to allow spending more time on
relevant literature. We focus on textual notations for
graphical parts of the UML notation, which are given
in the UML specification (OMG, 2015a, p. 683). We
exclude all textual notations only extending UML or
its elements rather than expressing UML itself. We
exclude all notations that are not related to UML. We
exclude notations not intended for usage by humans
such as data transfer containers, e.g. XMI serializa-
tion (OMG, 2015b). We include a) primary papers
describing a single textual notation, and b) secondary
survey-like papers including their references as pri-
mary sources.
The Study Quality Assessment considers title, ab-
stract, and the content of the full paper. We decide on
in-/exclusion of the remaining papers in this step.
Data Extraction is the process of determining the
information required to judge about the fulfillment of
the objectives. Section 3 shows the analyzed features
of the notations, their hierarchy, and individual deci-
sion basis in detail. We reason on the modeling en-
vironment based on information found directly in lit-
erature, implemented prototypes, prototype websites,
and source code. We identify prototypes, their web-
site, and the source code by: a) following links in the
papers, b) mining the website of the institute or com-
pany of the authors, c) and searching for the name of
the notation (full name and abbreviation if used) via
the Google search engine and on Githuband visit the
first one hundred search results. Data extraction takes
place for the declared primary editor. If there is more
than one prototype, we use the declared primary edi-
tor and an IDE-integrated editor. We assume the latter
to profit from advanced accessibility features of the
IDE. If there are editors for several IDEs, we decide
in favor of the Eclipse-based one because Eclipse is
open source, highly extensible, and offers many ac-
cessibility features
1
.
Data Synthesis summarizes the information. We
show and summarize the analysis results according to
the classification given in Section 3.
2.4 Phase 2: Quality Assurance
The Quality Assurance phase is based on the Snow-
balling approach (Wohlin, 2014) of Wohlin. Wohlin
suggests starting with an initial set of relevant liter-
ature and including relevant forward and backward
references. Afterwards, the resulting set of literature
is processed as described in common SLR processes.
We do not use Snowballing as primary source for rele-
vant literature because its quality heavily depends on
the initial literature set as described by Wohlin. In-
stead, we accept the overhead of a prior SLR phase
with broad search terms and use Snowballing to ver-
ify the quality of our SLR phase as described below.
Build Reference Closure determines the complete-
ness of results from the SLR phase. We collect all
directly referenced and referencing literature for the
analyzed papers. We derive the referenced literature
from the references section of the paper. We use
Google Scholar to determine the literature that cites
the paper under investigation.
The Study Selection and Study Quality Assessment
from phase SLR are applied to identify additional no-
tations.
We perform Data Extraction on selected papers as
in the SLR phase and add the notation to our database.
Data Synthesis summarizes the information as
carried out in the SLR phase.
Reasoning addresses why the newly identified no-
tations have not been found in the SLR phase. The
results are presented in Section 5. This phase is dif-
ferent from the Snowballing approach of Wohlin and
allows us to verify the quality of our SLR phase.
1
https://wiki.eclipse.org/Accessibility
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
30
2.5 Phase 3: Complement
Identification of Unpublished Approaches focuses on
textual notations that are available in practice but are
not scientifically published. We use the Google search
engine to identify the top 5 pages for ’UML textual
notation’, ’UML textual notations’, ’UML textual no-
tations list’. We mine the resulting websites to iden-
tify new approaches. We follow the links from the
identified websites looking for notations or compar-
isons of notations.
Additionally, we search for unrecognized scien-
tific surveys or notation comparisons. We perform a
full-text search via Google Scholar with the names of
the three most popular non-scientific notations. We
assume that recent surveys including non-scientific
notations cover them and thereby will be included in
the search results. We determine a notation’s popular-
ity by querying Google with the name of the notation
and comparing the announced results with the amount
of other notations. We only included notations that do
claim to relate to the UML.
In Check Availability, we exclude potential nota-
tions with dead links for all results.
We perform Data Extraction for new notations,
analyze the information, and add the notation to our
database.
Data Synthesis summarizes the information as
carried out in the SLR phase.
3 CLASSIFICATION
This section presents the classification and informa-
tion extraction goals derived from the three objectives
presented in Section 2.1. The objectives cover aspects
of what can be edited based on the textual notation
definition (O1, O2) as well as how it can be edited
based on modeling environments (O2, O3). We use
feature modeling to represent the evaluation classes,
their hierarchy, and possible values. The resulting
overview is depicted in Figure 2. The features them-
selves and how their values are evaluated for the no-
tations are presented in the following.
Each Textual Notation is defined by a Language
(O1, O2) and an optional Implementation (O2, O3) in
a modeling environment.
The Implementation is optional and covers all as-
pects with respect to a modeling environment for a
notation. It can have Recent Activity (O3), a License
(O3), and can support Change Propagation (O2, O3)
between different notations, data Format Exchange
(O2), and Editor (O2) features.
We divide the classification of the implementation
into two parts for a better overview: integration as-
pects, and the editor itself. The former covers the fea-
tures relevant for integrating an implementation into
a tool chain. The latter covers the editing experience
of the editors.
The following subsections will cover the lan-
guage, integration, and the editor in that order.
3.1 Language
The Language definition is mandatory and describes
the language’s syntax and semantics. It consists of the
UML Support (O1) for diagram types and can have
Sketch Support (O2), integrated Layout Information
(O2), and be Similar to UML Graphics (O2).
UML Support is mandatory and describes the sup-
ported UML diagram types. At least one type has to
be supported. A type is supported if the documenta-
tion states it to be supported or the modeling environ-
ment allows the creation of a corresponding type. The
considered diagram types are based on the UML spec-
ification (OMG, 2015a, p. 682). The abbreviations
are based on the official abbreviations from (OMG,
2015a, p. 682), or self-made if there is no official
one: Activity Diagram (ACT), Class Diagram (CLS),
Communication Diagram (COM), Component Dia-
gram (CMP), Composite Structure Diagram (COS),
Deployment Diagram (DEP), Interaction Overview
Diagram (INT), Object Diagram (OBJ), Package Di-
agram (PKG), Profile Diagram (PRO), Sequence Dia-
gram (SEQ), State Machine Diagram (STM), Timing
Diagram (TIM), and Use Case Diagram (UC).
Sketch Support is optional and can ease the no-
tation’s usage during discussions. Discussions benefit
from quick interaction and formal full-fledged model-
ing can extend the interaction time. There is support
if only mandatory elements of UMLs abstract syntax
are required.
Layout Information is optional states if the textual
model can contain graphical layout information. This
information allows to improve graphical presentation
of the textual statements. The information is irrele-
vant to describe the model itself. The interpretation
is difficult as graphical coordinates or positions are
only visible in graphic notations. The information can
be either Mixed with model elements or kept Sepa-
rated. It is marked as Mixed if at least one element
has mandatory layout information.
Similar to UML Graphics is optional and denotes
if graphical syntax elements such as arrows are repli-
cated in the textual notation by ASCII art. For in-
stance, the characters <>--> are similar to the UML
graphical representation for an aggregation. This can
Survey on Textual Notations for the Unified Modeling Language
31
Textual Notation
Language
Implementation
Sketch Support
Similar to UML
Graphics
Layout
Information
UML Support
Mixed
Separated
CLS
SEQ
(12 more)
Editor
License
Open Source
Closed Source
Export
Import
UML XMI
Custom
Format Exchange
Textual to
Graphical
Graphical to
Textual
Via Import/Export
Change
Propagation
Textual
Graphical
Editable
Layoutable
Visualization
Navigation
Refactoring
Folding
Syntax
Highlighting
Code Completion
Outline
Goto
Syntax
Element
Optional
Mandatory
Logical ORLogical XOR
Recent Activity
Release Activity
Ticket Activity
Commit Acitivity
Figure 2: Feature model for analyzed characteristics and their hierarchy.
work well for people knowing the graphical represen-
tation but have adverse effects on people using ac-
cessibility tools like Braille displays. A notation is
marked as similar if there is at least one ASCII art
mapping.
3.2 Integration
The integration covers all features that are relevant
for integrating an implementation into a tool chain.
Such a decision is based on the costs, extensibility,
support, maintainability and compatibility to existing
tools. The following features cover these aspects in
more detail.
The Recent Activity is optional and indicates the
support status. In contrast to a maintained project,
a discontinued project will not receive bugfixes and
might be incompatible to recent software such as new
versions of an IDE. We determine three activity dates
that allow judging project activity. One of them has to
be identifiable: Release Activity relates to the date of
the last release. A release can be a proper release,
snapshot, or nightly build. Ticket Activity is deter-
mined by the date of the most recently closed ticket.
Commit Activity is given if we can determine the most
recent commit.
The License is optional and can be crucial for us-
ing and maintaining the modeling environment. Open
Source licenses allow own bug fixing and the devel-
opment of extensions and adaptations. The individual
requirements for a license depend heavily on the us-
age context of the modeling environment. An expert
review is required to check for a notation of interest if
it applies to the own use case. We therefore differen-
tiate solely between Open Source and Closed Source
licenses. We rely on the list of the Open Source
Initiative (Open Source Initiative, 2015). If the li-
cense is listed on their website, we treat the project as
open source. All other licenses are considered Closed
Source.
Change Propagation can be supported and ad-
dresses transferring changes from one notation into
another. The modification in the modeling environ-
ment for a textual notation can therefore result in
an according change in a graphical notation of the
same content. This targets a consistent view of the
content and allows different team members to work
with different notations during discussion. This can
mean updates in real-time for close collaboration or
based on exporting and importing models in differ-
ent environments. We consider the three cases: Tex-
tual to Graphical, Graphical to Textual, and Via Im-
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
32
port/Export propagation. Textual to Graphical and
Graphical to Textual apply if the modeling environ-
ment includes a textual and a graphical editor. We
consider it supported if changes in one editor are re-
flected in the other one. Via Import/Export applies if
there is an import or export functionality and nota-
tions can be updated sequentially. It is marked if it
provides import and export function for UML models
in the standardized XMI data format.
Data Format Exchange is optional and allows in-
tegrating the modeling results into other tools or ex-
isting tool chains. We only consider fully-automated
exchange procedures provided by the implementation
itself. We do not consider other procedures such as
the error-prone manual translation between notations
or tools that is usually done by assistants. A mod-
eling environment can support the Import or Export
of a different set of data formats. This feature can
have the value UML XMI as standardized UML data
exchange and can list Custom formats supported by
the tools. The values are selected based on the doc-
umentation or file extensions provided in the editing
environment.
3.3 Editor
Editor categorizes properties related to user input, in-
teraction, and presentation. They can be Textual (O2),
Graphical (O2) or both. An editor is considered tex-
tual if it contains only text and no graphical elements.
Text coloring may be used. This ensures that textual
editors are accessible by accessibility techniques such
as screen readers. Otherwise, it is treated as Graphi-
cal.
Textual editors address several features to increase
user experience and accessibility. A textual editor can
support Visualization (O2), Refactoring (O2) of the
model, and user Navigation (O2) within the model.
Previous surveys did not focus on the editing expe-
rience in detail. Therefore, we selected the features
according to our objectives.
A Visualization is optional and allows focused
presentation of content by means of information hid-
ing. It can support Folding (O2), and Syntax High-
lighting (O2).
Folding (un)hides selected partitions of the model,
eases comprehension for complex models and fo-
cused presentation. It is selected if there is at least
one partition in a model that can be hidden or shown
based on the editor’s UI.
Syntax Highlighting highlights keywords or im-
portant structural parts of the model. It eases compre-
hension and identifying the structure of models. It is
selected if colors or text formatting is used in the edi-
tor to highlight at least one keyword of the language.
Refactoring is optional and addresses batch
changes to the model. For instance, all occurrences
of a model element can be replaced with another one
in one single step instead of using a manual search
and replace approach. This feature exists if there is at
least one supported refactoring.
Navigation is optional and addresses the naviga-
tion to model elements and providing an overview to
users. There can be support for Code Completion
(O2), overviews on model element by Outline (O2),
and direct model element navigation by Goto (O2).
Navigation is selected if there is at least one of its
child features selected.
Code Completion is optional and provides com-
pletion of a language’s syntax or referenced model
elements. It can provide hints on keywords of the
Syntax or model Elements allowed at the current po-
sition. It aids users in specifying correct models and
speeds up changes. We consider two types of values:
Syntax-based and Element-based completion. They
are selected if there is at least one corresponding code
completion feature in the editor.
Outline is optional and provides an overview of
the elements in a model. This can include their hi-
erarchical structure. It is selected if there is at least
a list of all top-level elements in a model depicted in
the editor.
Goto is optional and allows direct navigation or
jumps to specific model elements. This eases com-
prehension and look-up of elements. It is selected if
there is a navigation or jump support for a least one
type of element in the editor. It is included if it is di-
rectly in the textual notation and excluded if its only
in the Outline.
Graphical editors are optional and allow display-
ing and editing graphical version of the models. There
are many advanced graphical UML editors available
based on the formal UML specification. (Kern, 2014)
gives a good overview in his survey of interoperabil-
ity of UML tools. (Wikipedia, 2015) illustrates the
features of various UML tools. There are many com-
parisons between few selected tools such as IBM Ra-
tional Software Architect, MagicDraw, and Papyrus
in (Safdar et al., 2015) or between Rational Rose,
ArgoUML, MagicDraw, and Enterprise Architect in
(Khaled, 2009). This survey focuses on the synchro-
nization aspect with textual languages and their edi-
tors (O3). Our categories show if the editor is mainly
a pure static presentation of the model or allows inter-
actions. We distinguish for Graphical editors if their
content is Editable (O2) and Persistable (O2). This
feature is selected if there is a graphical presentation
of the model in the modeling environment.
Survey on Textual Notations for the Unified Modeling Language
33
Editable is optional and denotes if the graphical
content can be modified, e.g. a user can rename el-
ements. This feature is selected if at least some ele-
ments in the graphical editor can be modified.
Layoutable is optional and denotes if modifica-
tions to the graphical layout, e.g. the position of
model elements, can be done. Users can structure the
graphical representation in this way. This feature is
selected if elements can be moved.
4 ANALYSIS RESULTS
This chapter presents the analysis results for all no-
tations. Table 2 provides an overview and shows the
determined characteristics for all notations. The fol-
lowing paragraphs provide a short description of the
notations. They point out features or provide com-
ments, which are not already covered by the overview.
Alf (OMG, 2013) has been specified by the OMG
and is the action language for UML. It is based on
Foundational UML (fUML). There is no official edi-
tor implementation.
Alloy (Jackson, 2002) is a model finder and solver
based on the Z notation (ISO/IEC 13568:2002, 2002)
instead of UML. The author compares it to UML in
sections 4.1 and 6.4 and states that ”Alloy is similar
to OCL, the Object Constraint Language (OCL) of
UML”
2
. It provides a graphical and textual notation
but does not support any UML diagrams. It is licensed
under the MIT license and does not provide access to
source code.
AUML (Winikoff, 2005) is an extension to UML
SEQ diagrams. Winikoff defined a textual notation
for AUML that has been included in the Prometheus
Design Tool
3
. It provides a PNG export but does not
provide a mechanism to import or export a model.
Clafer (Zayan, 2012) is a modeling language for
CLS diagrams and constraints. It can be used for fea-
ture modeling. The online tool
4
provides no graphical
view but offers a GraphViz export.
DCharts (Feng, 2004) specifies a meta-model in
AToM
3 5
and a graphical and textual notation. The
textual notation is the leading one and the graphical
implemented only partially (Feng, 2004, p. 35). No
tool or files could be found actually implementing the
theoretical concept. We could not find an advanced
textual editor with collaboration features for the self-
defined language. The publication claims that there is
2
http://alloy.mit.edu/alloy/faq.html
3
https://sites.google.com/site/rmitagents/software/prometh
eusPDT
4
http://t3-necsis.cs.uwaterloo.ca:8094
5
http://atom3.cs.mcgill.ca/
a transformation from the meta-model to UML state
charts.
Earl Grey (Mazanec and Macek, 2012) is a proof
of concept for an accessible textual notation. The
Eclipse implementation creates a model during edit-
ing but there is no export to other notations.
HUTN (Vieritz et al., 2014) is an OMG standard
for text-based representation of MOF-based meta-
models, which covers the UML meta-model. Humans
can use it easier than XMI. There is no official refer-
ence implementation of an HUTN-based UML editor.
IOM/T (Doi et al., 2004) allows specifying pro-
tocols for agent communication. It covers AUML
(Winikoff, 2005) sequence diagrams partially, which
we consider as SEQ support. The notation seems to
consist of two papers, the latest in 2007.
MetaUML (Gheorghies, 2015) is a DSL leverag-
ing TeX in the background. It creates graphics in
UML style but no UML models.
modsl
6
is a text to diagram sketch tool based on
Java code specifications. The proposed default editing
environment is Eclipse. It creates graphics in UML
style but no UML models.
pgf-umlcd
7
and pgf-umlsd
8
are both based on
PGF/TikZ. They leverage T
E
X interpreters. This has
a major influence on its syntax and structure. They
create graphics in UML style but no UML models.
PlantUML (Roques, 2015) is a textual notation
to diagram tool. CLS diagrams can be exported as
UML files for the StarUML and ArgoUML tools. Im-
ports and synchronization mechanisms are not avail-
able. There are various standalone and integrated ed-
itor implementations.
Quick Sequence Diagram Editor
9
is a text to dia-
gram sketch tool written in Java. It creates graphics
in UML style but no UML models.
TCD (Washizaki et al., 2010) is an ASCII-art con-
verter for CLS diagrams. It provides a conversion
from and to the UML XMI representation. The im-
plementation is not available.
TextUML (Chaves, 2015) exports standard UML
models but does not provide a graphical view. Ser-
vices such as Cloudfier
10
use it as alternative for
graphical modeling tools.
tUML (Jouault and Delatour, 2014) focusses on
modeling for validation and verification purposes.
The mentioned prototype is not available.
txtUML (D
´
evai et al., 2014) uses regular Java syn-
tax for modeling. Java Annotations provide additional
6
https://code.google.com/p/modsl/
7
https://github.com/xuyuan/pgf-umlcd
8
https://code.google.com/p/pgf-umlsd
9
http://sdedit.sourceforge.net/
10
http://doc.cloudfier.com/creating/language/
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
34
information. There is no dedicated textual or graphi-
cal editor but a Papyrus model can be exported.
UML/P (Gr
¨
onniger et al., 2014) is a textual no-
tation claiming to merge programming and modeling
by enriching UML models with Java expressions. The
Eclipse plugin provides textual and graphical editors
but no import or export.
UMLet
11
(Auer et al., 2003) is a graphical UML
sketch tool. It provides graphical UML shapes. A se-
lected shape is shown in a textual view, which allows
to modify the element. The textual view covers only
the selected element. It create graphics in UML style
but no UML models.
UMLGraph (Spinellis, 2003) uses Java source
files and customized JavaDoc comments to create di-
agrams. It creates graphics in UML style but no UML
models.
uml-sequence-diagram-dsl-txl
12
is a command-
line based text to diagram sketch tool written in the
transformation language TXL. The Eclipse IDE plug-
in was not available. The table lists the mentioned
features of the guide
13
. It creates graphics in UML
style but no UML models.
Umple (Lethbridge, 2014) is a model-to-code gen-
erator with textual notations. UML elements not rel-
evant for code generation such as aggregations are
omitted. The online tool synchronizes the textual and
graphical notation.
USE (Zayan, 2012) aims for specifying systems
with including OCL constraints. The official tool does
not provide an editor but textual and graphical views.
AWMo (Del Nero Grillo and de Mattos Fortes,
2014)
14
is a Web application targeting the collabora-
tion of blind and sighted users. The Web tool does not
work, there is no included documentation. The char-
acteristics have been determined based on the source
code and available presentations and the paper. They
define their own simplistic meta-model inspired by
CLS diagrams for their proof of concept. Collabora-
tion is realized via store and load mechanism, which
maps to Import and Export in the table.
blockdiag
15
has the subprojects seqdiag
16
and act-
diag
17
. Both are written in Python and convert tex-
tual diagram descriptions to graphics. The syntax is
Graphviz’s DOT format. The code and release activi-
ties are taken from seqdiag only being representative.
It creates graphics in UML style but no UML models.
11
www.umlet.com
12
http://www.macroexpand.org/doku.php
13
http://www.txl.ca/eclipse/TXLPluginGuide.pdf
14
http://garapa.intermidia.icmc.usp.br:3000/awmo/
15
http://blockdiag.com/en/
16
https://bitbucket.org/blockdiag/seqdiag
17
http://blockdiag.com/en/actdiag/index.html
Finite State Machine Diagram Editor and Source
Code Generator
18
has an own XML Schema Defini-
tion, which defines their textual language called Fs-
mML. Conforming XML documents can be Imported
and Exported. Links to model elements are realized
via String matching.
js-sequence-diagrams
19
is a text to diagram sketch
tool written in Java Script. It is inspired by the com-
mercial WebSequenceDiagram. It parses plain text
and can report basic parsing errors. Its shared with an
own license title as simplified BSD. It creates graph-
ics in UML style but no UML models.
nomnoml
20
is a text to diagram sketch tool written
in Java Script. The syntax is oriented at the graphical
UML shapes. It creates graphics in UML style but no
UML models.
WebSequenceDiagrams
21
is a text to diagram
sketch tool written in Java Script. It creates graphics
in UML style but no UML models. A free alternative
is js-sequence-diagrams.
yUML (Harris, 2015) is a text to diagram sketch
tool. It creates graphics in UML style but no UML
models.
5 DISCUSSION
This section discusses the presented results of the sur-
vey. Section 5.1 discusses observations based on the
results. Section 5.2 discusses threats to validity.
5.1 Findings
The analyzed notations can be divided into two
groups: 14 notations focuses on generating diagrams
for documentation purposes but do not consider UML
modeling. These notations mainly regard the text
to graph change propagation and focus on graphical
export. 17 notations focus on modeling or further
analysis. The relative share of web tools in the first
group (5) is twice as much as in the second group (3).
Most scientifically published notations mentioned in
(Luque et al., 2014a) are in the first group as well.
Only 23% of the remaining notations of (Luque et al.,
2014a) that are also present in our survey do not focus
on graphics generation. This shows that the delivery
method of the editor has no significant effect on the
editing experience and applicability.
Notations that focus on sketching graphics of-
ten disregard formal UML rules and having a UML
18
http://www.stateforge.com/
19
https://bramp.github.io/js-sequence-diagrams/
20
https://github.com/skanaar/nomnoml
21
https://www.websequencediagrams.com/
Survey on Textual Notations for the Unified Modeling Language
35
Table 2: Characteristics of analyzed textual UML notations. Characteristics are: not extractable (-), given (X), or not given
(×). Layout information is: mixed (m) or separated (s). The License is: open (O) or closed (C) source.
Language (mandatory) Implementation
Recent Activity Format Exchange Editor
Textual Graph.
Visuali-
zation
Navigation
Notation
UML Support (mandatory)
Sketch Support
Layout Information
Similar to UML Graphics
Release
Ticket
Commit
License
Change Propagation
Export
Import
Syntax Highlighting
Folding
Refactoring
Code Completion (Syntax)
Code Completion (Element)
Outline
Goto
Editable
Layoutable
Alf CLS,ACT,PKG X × × - - - - - - - - - - - - - - - -
Alloy × × × × 22.02.15 × × O × DOT, XML ALS X × × × × × × × X
AUML SEQ × × × 05.09.14 20.11.14 - - T2G PNG × X × × × × × × - -
AWMo CLS × × × × × 05.11.13 C T2G,
G2T
× × - - - - - - - - -
blockdiag:
seq-,actdiag
SEQ,ACT X m X 01.01.15 10.09.14 22.08.15 O T2G PNG,SVG,PDF × - - - - - - - - -
Clafer CLS,OBJ × × × 28.07.15 11.03.15 28.07.15 O × own,DOT,Z3Py,
ALF,ChocoJS
× X × × × × × × - -
Dcharts STM X × × - - - - - - - - - - - - - - - -
Earl Grey CLS,SEQ,STM × × × 25.05.12 09.04.12 23.05.12 O × × × X X X X X X X - -
Finite State
Machine DE
STM X × × 02.04.15 - - O T2G,
G2T
own own X × × × × × × X ×
HUTN all X × × - - - - - - - - - - - - - - - -
IOM/T SEQ × × × - - - - - - - - - - - - - - - -
js-sequence-
diagrams
SEQ X m X 17.05.15 14.08.15 27.07.15 O T2G SVG × - - - - - - - - -
MetaUML CLS,STM,ACT,
UC,CMP,PKG
X m × 23.06.15 23.08.15 07.08.15 O T2G × × - - - - - - - - -
modsl CLS,COM X × × 11.08.09 09.11.09 11.08.09 O T2G PNG, JPG × X X X X × X X - -
Nomnoml CLS,OBJ,STM,
UC,PKG
X m X × 14.08.15 03.08.15 C T2G PNG × - - - - - - - - -
pgf-umlcd CLS X m × 28.04.14 22.08.15 31.05.15 O T2G × × X × × × × × × - -
pgf-umlsd SEQ X m × 24.02.14 09.02.15 24.02.14 O T2G × × X × × × × × × - -
PlantUML CLS,OBJ,SEQ,
STM,ACT,UC,
CMP,DEP
X m X 05.08.15 23.10.14 05.08.15 O T2G UML,SVG,EPS,
TXT,HTML
× - - - - - - - - -
Quick Se-
quence
Diag. Edit.
SEQ X × × 11.02.13 22.01.15 01.02.15 O × PDF,JPEG,SVG,
SWF,EMF,GIF,
JPEG,(E)PS
× - - - - - - - - -
TCD CLS X × X - - - - IE UML UML - - - - - - - - -
TextUML CLS, STM × × × 20.08.15 02.08.15 20.08.15 O × UML × X × × X × X × - -
tUML CLS, STM, COS × × × - - - - T2G,
IE
UML UML X X × × × X X × ×
txtUML CLS, STM, ACT × × × 14.07.15 - - - T2G UML × X X × × × X X - -
UML/P CLS, OBJ, SEQ,
STM, ACT
X s X - - - C T2G × × X X × X × X X X ×
UMLet CLS, OBJ, UC,
PKG
X m × 19.03.15 13.08.15 12.08.15 O × BMP,EPS,GIF,
JPG,PDF,PNG
UXF X × × × × × × X X
UMLGraph CLS, SEQ X m × 28.10.14 29.10.14 29.10.14 O T2G PNG,fig,PS,GIF
EMF,SVG,JPEG
× - - - - - - - - -
uml-se-
quence-dia-
gram-dsl-txl
SEQ X m X 29.08.09 × × × T2G XML, Code × X X × X × X X - -
Umple CLS, STM, COS X s X 24.02.15 07.02.15 20.08.15 O T2G,
G2T
UML,ALS,USE,
EMF,UXF,Code,
TUML,yUML
× X × × × × × × X X
USE CLS × s × 04.08.15 19.09.14 - O T2G PDF × X × × × × × × X ×
WebSequence-
Diagrams
SEQ X m X - - - × T2G × × - - - - - - - - -
yUML CLS, ACT, UC X × X - - - - T2G PNG,PDF,SVG,
JPEG,JSON
× - - - - - - - - -
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
36
model. This leads to some drawbacks: First, the
results of the textual modeling cannot be processed
in tool chains. This is true for all notations that
do not provide export formats other than graphics.
Second, interpreting the generated graphic might be
hard because determining the semantics of the ele-
ments requires spatial thinking. Non-UML graph-
ics such as the conditional node in the PlantUML
activity diagram
22
make this even harder. Third,
the (semantic) relation of graphic elements is inac-
cessible for machines and visually impaired people.
These drawbacks limit consistency and collaborative
editing. We only identified ve notations providing
UML-compaptible model export.
19 notations cover less than three UML diagram
types. The most supported diagram type is the CLS
diagram (20) followed by the SEQ (13) and STM di-
agram (12). TIM, PRO, and INT diagrams are only
supported by the HUTN. 15 do not provide editing en-
vironments at all. Based on our results, notations are
specialized and there is no notation that supports col-
laborative editing in textual and graphical notations
of more than ve UML diagrams. MetaUML (6) and
PlantUML (8) come with the highest UML diagram
type coverage and provide an implementation but no
state-of-the-art editing environment. We could not
identify a one-fits-all notation in our survey.
Almost half of the reviewed notations (14) have
recent activity in the year 2015. Therefore, we ex-
pect improvements in the syntax and implementation
of the notations in the near future.
5.2 Threats to Validity
We address four common threats to internal validity:
incomplete selection, inconsistent measurements, bi-
ased experimenter, and incomplete information.
We addressed incomplete selection with two addi-
tional phases that check the completeness of search
results. During the survey, we found a total of 31
textual UML notations. We found half of them in
the SLR phase. In the Quality Assurance phase, we
found four new papers and three new notations. The
first phase did not reveal three of these papers (Jack-
son, 2002; He, 2006; Doi et al., 2004) because their
main contribution was not about a textual UML no-
tation. Therefore, they did not clearly indicate that
they also cover a textual UML notation in their title
or abstract. The remaining paper (D
´
evai et al., 2014)
is not indexed by the search engines that we used. The
major new result of the completion phase was the tex-
tual UML tool list (Cabot, 2015) provided by Jordi
22
http://plantuml.com/activity2.html
Cabot, a professor with research interests in model-
driven software engineering at the ICREA research
institute. We found eleven new notations compared
to the previous phase. We did not find ten of them
in earlier phases because those phases are focused on
scientific notations and the found notations have not
been scientifically published. The remaining notation
(Del Nero Grillo and de Mattos Fortes, 2014) is not
indexed by the search engines we used. Therefore,
we consider the keywords of the SLR phase and the
whole notation finding process to be successful and
appropriate.
The Complement phase did not include an exten-
sive search strategy because we focus on scientifi-
cally published notations in this survey. We com-
plement the intensive search strategies of the previ-
ous phases with the most common notations used in
industry. To achieve this, we imitate the common
search strategy that covers the very first results only
because they are the most popular ones. We included
all notations of previous surveys in the analysis. In to-
tal, we found 14 new notations compared to previous
surveys: Alf, Alloy, AUML, Clafer, Dcharts, HUTN,
IOM/T, Nomnoml, pgf-umlcd, pgf-umlsd, tUML, tx-
tUML, UML/P, and uml-sequence-diagram-dsl-txl.
We addressed inconsistent measurements and bi-
ased experimenter with a rigorous review protocol
and instructions for the characteristics extraction. The
characteristics for the notations can be determined
in an objective way. Mazanec et al. (Mazanec and
Macek, 2012), however, used subjective characteris-
tics such as readability or simplicity and did not men-
tion how they have been determined.
We addressed incomplete information by using
multiple information sources. We characterized all
31 notations by extracting information from the pa-
pers, and mining websites and source code (if possi-
ble). The former is the standard approach during a
SLR but the two latter allow filling the gaps left by
the scientific papers. Especially, the project’s activ-
ity and editor features are most commonly not cov-
ered by publications. Only Alf, Dcharts, HUTN, and
IOM/T did not provide sufficient information to de-
termine these characteristics.
The external validity requires generalizable re-
sults. The survey results are applicable for scenarios
that cover collaborative UML editing with textual no-
tations in general because the characteristics do not
focus on a specific scenario. This is a benefit over the
previous surveys (Luque et al., 2014a; Luque et al.,
2014a) that focused on teaching UML to visually im-
paired people from industry applying UC and CLS
diagrams. The fuzzy characteristics in (Mazanec and
Macek, 2012) lead to a limited generalization and ap-
Survey on Textual Notations for the Unified Modeling Language
37
plicability.
6 CONCLUSIONS
UML is most commonly used for modeling tasks in
various domains. It provides a graphical but no tex-
tual notation. The results show that the lack of a stan-
dard leads to many different and incompatible textual
notations tailored for specific purposes. They largely
differ in syntax, coverage, editing experience and ap-
plicability in teams. This diversity requires high effort
to evaluate and select a notation for a specific purpose
and environment.
The contribution of this survey is the identifica-
tion and classification of textual UML modeling no-
tations. Teams that plan to incorporate a textual mod-
eling notation can save effort by using our survey be-
cause a) we provide a comprehensive list of available
notations, b) we classified the notations with respect
to characteristics that are important for their practical
use in teams, and c) are usage scenario independent.
The applied review method ensures reproducible
and reliable results, which is crucial for using our sur-
vey as a foundation for the approach selection. The
review method covered a traditional SLR and two ad-
ditional phases for ensuring the quality and complete-
ness of the review. The SLR phase consisted of a
keyword-based search in search engines relevant for
the software engineering domain. The quality assur-
ance phase applied one iteration of the snowballing
approach as cross-check for the quality of our SLR
phase. The complement phase completed the list of
notations used in practice but without academic back-
ground. The two latter phases identified about the
same amount of notations as the SLR showing the
strength of our SLR method.
The classification is tailored to include the user’s
point of view and support the notation selection in
teams. We presented each of the twenty categories
in detail including objectively checkable conditions
that cover the level of UML support, the editing expe-
rience, and the applicability in an engineering team.
The categories are also a reference for future surveys
in the area.
About half of the identified notations focus on the
generation of graphics for documentation purposes
based on notations on the code level. Many nota-
tions focus on discussions using purely graphic no-
tations. They provide UML shapes and allow their
arbitrary placement on a canvas. This prevents auto-
mated processing such as checking model validity or
compliance to existing code. This prevents the usage
in many context and can be taken into account during
selection.
The restriction to graphical exports prohibits col-
laborative editing of graphical as well as textual rep-
resentations in engineering teams although both have
their advantages. The majority of notations only
cover less than three UML diagram types. Most of
them do not provide a state-of-the-art editor. This
shows that users have to select notations based on
their own usage scenario and decide on the supported
UML diagram types and the required editor support.
Practitioners can leverage our survey to prioritize
their analysis of notations.
We could not identify a single comprehensive tex-
tual UML notation that comes with a state-of-the-art
editing environment and standard import/export for-
mats. This incompatibility suggests future work for
researchers and practitioners as well: Researchers can
analyze the gap in UML coverage or if there is a best
of breed notation available for all diagrams. Practi-
tioners can compare the available notations more eas-
ily and see which features can help users.
From our perspective, there is a need for notations
that target proper UML modeling and have the abil-
ity to import and export standard UML models. This
allows engineering teams to include the notation in
existing tool chains and enables collaboration.
ACKNOWLEDGEMENTS
This work is funded by the German Federal Min-
istry of Labour and Social Affairs under grant
01KM141108.
REFERENCES
Auer, M., Tschurtschenthaler, T., and Biffl, S. (2003). A
flyweight uml modelling tool for software develop-
ment in heterogeneous environments. In Proceedings
of EUROMICRO’03, pages 267–272. IEEE Computer
Society.
Cabot, J. (2015). Modeling languages – Uml Tools. https://
modeling-languages.com/uml-tools. accessed 04.Au-
gust 2015
Chaves, R. (2015). Textuml toolkit. http://abstratt.github
.io/textuml/readme.html. accessed 14. August 2015
Del Nero Grillo, F. and de Mattos Fortes, R. (2014). Tests
with blind programmers using awmo: An accessible
web modeling tool. In UAHCI’14, pages 104–113.
D
´
evai, G., Kov
´
acs, G. F., and An,
´
A. (2014). Textual, exe-
cutable, translatable UML. In Proceedings of the 14th
International Workshop on OCL and Textual Mod-
elling, pages 3–12.
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
38
Doi, T., Yoshioka, N., Tahara, Y., and Honiden, S. (2004).
Bridging the gap between AUML and implementation
using IOM/T. In Proceedings of ProMAS’04, pages
147–162.
Erb, S. (2011). Textual modeling of service effect speci-
fications. http://stephanerb.eu/files/erb2011a Textual
Modeling of Service Effect Specifications.pdf. Ac-
cessed 04. August 2015.
Feng, H. (2004). DCharts, a formalism for modeling and
simulation based design of reactive software systems.
Master’s thesis, School of Computer Science, McGill
University, Montreal, Canada.
Gheorghies, O. (2015). Metauml - github. https://github
.com/ogheorghies/MetaUML. accessed 14. August
2015.
Gr
¨
onniger, H., Krahn, H., Rumpe, B., Schindler, M., and
V
¨
olkel, S. (2014). Text-based modeling. CoRR,
abs/1409.6623.
Harris, T. (2015). Create uml diagrams online in seconds,
no special tools needed. http://yuml.me. accessed 14.
August 2015.
He, Y. (2006). Comparison of the modeling languages alloy
and UML. In Proceedings of SERP’06,pages 671–677
ISO/IEC 13568:2002 (2002). Information technology z
formal specification notation syntax, type system
and semantics. Standard, International Organization
for Standardization.
Jackson, D. (2002). Alloy: a lightweight object mod-
elling notation. ACM Trans. Softw. Eng. Methodol.,
11(2):256–290.
Jouault, F. and Delatour, J. (2014). Towards fixing sketchy
UML models by leveraging textual notations: Appli-
cation to real-time embedded systems. In Proceedings
of the 14th International Workshop on OCL and Tex-
tual Modelling, pages 73–82.
Kern, H. (2014). Study of interoperability between meta-
modeling tools. In Computer Science and Informa-
tion Systems (FedCSIS), 2014 Federated Conference
on, pages 1629–1637.
Khaled, L. (2009). A comparison between uml tools. In
ICECS’09, pages 111–114.
Kitchenham, B. and Charters, S. (2007). Guidelines for
performing systematic literature reviews in software
engineering (version 2.3). EBSE technical report,
EBSE-2007-01, Keele University.
Lethbridge, T. (2014). Umple: An open-source tool for
easy-to-use modeling, analysis, and code generation.
In Proceedings of the Demonstrations Track of MoD-
ELS’14.
Luque, L., Brand
¯
ao, L. O., Tori, R., and Brand
¯
ao, A. A. F.
(2014a). Are you seeing this? what is available
and how can we include blind students in virtual uml
learning activities. In Proceedings of SBIE’14.
Luque, L., Veriscimo, E., Pereira, G., and Filgueiras, L.
(2014b). Can we work together? on the inclusion
of blind people in uml model-based tasks. In Inclu-
sive Designing, pages 223–233. Springer International
Publishing.
Mazanec, M. and Macek, O. (2012). On general-purpose
textual modeling languages. In Proceedings of
Dateso’12, pages 1–12.
OMG (2013). Action language for foundational uml (alf).
http://www.omg.org/spec/ALF/1.0.1/PDF.
OMG (2015a). Unified Modeling Language (UML) Ver-
sion 2.5. http://www.omg.org/spec/UML/2.5/PDF.
OMG (2015b). XML Metadata Interchange (XMI) Ver-
sion 2.5.1. http://www.omg.org/spec/XMI/2.5.1/PDF.
Open Source Initiative (2015). Licenses by name.
http://opensource.org/licenses/alphabetical. accessed
04. August 2015.
Roques, A. (2015). Plantuml: Open-source tool that uses
simple textual descriptions to draw uml diagrams.
http://plantuml.com/. accessed 14. August 2015.
Safdar, S. A., Iqbal, M. Z., and Khan, M. U. (2015). Em-
pirical evaluation of uml modeling toolsa controlled
experiment. In Modelling Foundations and Applica-
tions, volume 9153 of Lecture Notes in Computer Sci-
ence, pages 33–44. Springer International Publishing.
Spinellis, D. (2003). On the declarative specification of
models. IEEE Software, 20(2):94–96.
Vieritz, H., Schilberg, D., and Jeschke, S. (2014). Access
to uml diagrams with the hutn. In Automation, Com-
munication and Cybernetics in Science and Engineer-
ing 2013/2014, pages 751–755. Springer International
Publishing.
Washizaki, H., Akimoto, M., Hasebe, A., Kubo, A., and
Fukazawa, Y. (2010). Tcd: A text-based uml class di-
agram notation and its model converters. In Advances
in Software Engineering, volume 117 of Communi-
cations in Computer and Information Science, pages
296–302. Springer Berlin Heidelberg.
Wikipedia (2015). List of unified modeling language tools.
https://en.wikipedia.org/wiki/List of Unified Modeli
ng Language tools. accessed 04. August 2015.
Winikoff, M. (2005). Towards making agent UML practi-
cal: A textual notation and a tool. In 2005 NASA /
DoD Conference on Evolvable Hardware (EH 2005),
pages 401–412.
Wohlin, C. (2014). Guidelines for snowballing in system-
atic literature studies and a replication in software en-
gineering. In Proceedings of EASE’14, pages 38:1–
38:10. ACM.
Zayan, D. O. (2012). Model Evolution: Comparative study
between clafer and Textual Uml. http://gsd.uwaterloo
.ca/sites/default/files/Model%20Evolution;%20Clafer
%20versus%20Textual%20UML.pdf. Project Report.
Survey on Textual Notations for the Unified Modeling Language
39