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 try at 20 companies in the state of Sao Paolo (Brazil). Both surveys target notations used in practice without The Unified Modeling Language (UML) has become regarding the state of the art described in scientific the lingua franca of software description languages. publications. (Mazanec and Macek, 2012) focuses on The UML specification comes with a graphical no- textual notations in general but is a few years old and tation, which is commonly applied. There is no covers few notations. It does not represent the current standardized textual notation. According to Spinel- development state and available variety of the nota- lis (Spinellis, 2003), textual notations provide an al- tions and modeling environments. The three existing ternative representation. It can be more compact or surveys show that there is a wide range available with more intuitive for certain user groups than the graph- individual advantages and drawbacks. They do not ical representation. An example is the textual repre- analyze the user’s editing experience, which is cru- sentation of an UML activity diagram-like specifica- cial for using a notation in a collaborating engineering tion of a service’s behavior (Erb, 2011). The textual team, and requires heavy analyses effort. The overall version requires significantly less space for the repre- effort reduces the chance for a comprehensive analy- sentation and is more intuitive to developers. sis and can endanger the selections’s quality. There are several tailored textual notations tai- The contribution of this survey is the identifica- lored for specific purposes such as creating documen- tion and classification of textual UML notations in- tation integrated in the code, having a more com- cluding the user experience. Engineering teams can pact representation, or increasing accessibility. They use the classification for identifying appropriate no- largely differ in their syntax, coverage of the UML, tations for their usage scenarios. The classification user editing experience, and applicability in an engi- scheme is tailored to support this selection. This sur- neering teams. vey examines accessibility of notations with respect to The latest surveys covering textual UML notations their syntax, editors, and modeling environment. Us- were performed by Luque, et al. (Luque et al., 2014a; ability in realistic scenarios is determined by covered Luque et al., 2014b). The former (Luque et al., 2014a) diagram types, data format exchanges, and synchro- focuses on the accessibility of UML for blind students nization approaches with other notations. It addition- in classrooms and the latter (Luque et al., 2014b) on ally evaluates whether non-necessary parts of the no- tools for use-case and class diagrams used in indus- 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 Survey on Textual Notations for the Unified Modeling Language overhead discussion and brainstorming. For instance, ad SLR ad Quality Assurance ad Complement the UML specification allows to omit the types of the class attributes. Identification of Build Reference Identification of The survey identified and rated 31 notations of Research Closure Unpublished which 15 were not covered in previous surveys. 20 Approaches categories allow fine-grained pre-selection and cover the applicability in engineering teams. Study Selection Study Selection The remainder of this survey is structured as fol- Check Availability lows: Section 2 describes the review method of the Study Quality Study Quality survey by defining the objectives and the review pro- Assessment Assessment tocol consisting of three phases. Section 3 describes the classification scheme based on the defined objec- Data Extraction Data Extraction Data Extraction 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- Data Synthesis Data Synthesis Data Synthesis tion 6 concludes the paper. Reasoning 2 REVIEW METHOD Figure 1: The three phases of the review conduction process The review process follows the guidelines of Kitchen- used in this survey. ham and Charters (Kitchenham and Charters, 2007). They developed guidelines for structured literature re- Charters, 2007). We extend the SLR with two addi- views (SLR) in software engineering based on the tional phases in order to increase the quality of the re- guidelines in the field of medical research. Their sults and to take notations into account that are mainly guidelines cover the planning, conduction, and writ- used in (industrial) practice: The Quality Assurance ing of reviews. Planning involves defining research phase focuses on incoming and outgoing literature objectives and creating a review protocol describing references as suggested by the Snowballing search the activities in each step during the review conduc- approach (Wohlin, 2014). In contrast to the original tion. proposal, we use Snowballing only to cross-check our The following sections describe our implementa- SLR search strategy. The Complement phase focuses tion of the SLR and mapping to the proposed method. on textual notations that are available in practice but The results of our search activities are documented are not scientifically published. and available for reproducibility at http://cooperate- project.de/modelsward2016. 2.3 Phase 1: SLR 2.1 Objectives The review conduction according to (Kitchenham and Charters, 2007) consists of the five activities marked Our objectives are to determine each notation’s (O1) as SLR in Figure 1. coverage of the UML, (O2) user editing experience The Identification of Research describes the and (O3) applicability in an engineering team. The search strategy for collecting literature. We chose a reasoning requires an analysis of the textual notations keyword-based search approach using the search en- and of the modeling environments. Section 3 presents gines ACM Digital Library, IEEExplorer, CiteSeer, the detailed classification scheme based on the ob- ScienceDirect, SpringerLink and Google Scholar. jectives and instructions on the according information These search engines cover relevant journals and are extraction procedure from literature. suggested by Kitchenham and Charters for the soft- ware engineering domain. We did not include EI 2.2 Review Protocol Compendex and Inspec as we could not query these search engines without subscriptions. Their focus is Figure 1 shows an overview of our review protocol. on high-qualitative entries and metadata and they do We distinguish three phases during the conduction: not belong to a not-covered established publishing classic SLR, Quality Assurance and Complement. authority. We are confident that the selected search The classic SLR follows the guidelines of review engines are sufficient and that no relevant paper is conduction by Kitchenham, et al. (Kitchenham and not selected by our keywords because of insufficient 29 MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development Table 1: Keyword groups used in search queries. erature, implemented prototypes, prototype websites, Group Keywords and source code. We identify prototypes, their web- site, and the source code by: a) following links in the Textual T CTS, textual modeling, textual mod- papers, b) mining the website of the institute or com- elling, text-based modeling, text- pany of the authors, c) and searching for the name of based modelling, textual notation, the notation (full name and abbreviation if used) via text-based notation, textual UML, the Google search engine and on Githuband visit the text-based UML, textual syntax first one hundred