Ankica Barisic
email: a.barisic@campus.fct.unl.pt

Miguel Goulão

Vasco Amaral

Ankica Barišić

Usability Driven DSL development with USE-ME

Keywords: Domain-Specific Languages, Software Language Engineering, Experimental Software Engineering, Usability Engineering, Quality of DSLs, Quality in Use

published or not. The documents may come   L'archive ouverte pluridisciplinaire

Introduction

The increasing pace at which the software is being adopted in daily tasks, including those of users not necessarily proficient with computing, is pushing the need for rapid production of a growing number of complex software applications. The degree of specialisation in certain areas is pushing for the involvement of domain aspects in the software development process, as complex software configuration tasks. A Domain-Specific Language (DSL) is specialised in a particular application domain [START_REF] Mernik | When and How to Develop Domain-Specific Languages[END_REF]. It can be defined as a user empowerment tool to increase productivity in software systems development [START_REF] Kelly | Domain-specific modeling: enabling full code generation[END_REF][START_REF] Marand | DSML4CP: A Domain-specific Modeling Language for Concurrent Programming[END_REF]. It offers the expressiveness required to specify the software applications at a higher level of abstraction, after which they can be automatically deployed or even simulated, with notations more close to the end user. DSLs are designed to bridge the gap between the problem domain (essential concepts, domain knowledge, techniques, and paradigms) and the solution domain (technical space, middleware, platforms and programming languages) [START_REF] Völter | DSL Engineering: Designing, Implementing and Using Domain-Specific Languages[END_REF]. Bridging this gap is expected to increase language users' productivity.

Practitioners often experience some practical difficulties when adopting DSLs [START_REF] Gray | DSLs: the good, the bad, and the ugly[END_REF]. During the language development, the importance of aligning the DSLs with the needs of their end users seems to be underestimated [START_REF] Kelly | Worst Practices for Domain-Specific Modeling[END_REF][START_REF] Völter | Best practices for DSLs and model-driven development[END_REF]. The necessity for assessing the impact of introducing a DSL in a domain workflow has been discussed in the literature, often with a focus on the business value that DSL can bring [START_REF] Kelly | Domain-specific modeling: enabling full code generation[END_REF]. This business value often translates into productivity gains resulting from the extent to which the domain users can use the DSL in practice [START_REF] Völter | DSL Engineering: Designing, Implementing and Using Domain-Specific Languages[END_REF].

Although building and adopting DSLs may seem intuitive, we need to have means to evaluate their impact. The measure of success has to be determined by assessing the impact of using DSL, in a realistic context of use, by its target domain users [START_REF] Barišić | How to reach a usable dsl? Moving toward a systematic evaluation[END_REF]. Investment into this assessment, commonly called Usability evaluation, is justified by a reduction of development costs and increased revenues for other software products, brought by an improved effectiveness and efficiency by their end users [START_REF] Marcus | The ROI of Usability[END_REF][START_REF] Bias | Cost-justifying usability: An update for the Internet age[END_REF]. We expect a similar effect by introducing this practice into DSL development.

The software industry does not often report investment on the assessment of DSLs [START_REF] Kosar | Domain-Specific Languages: A Systematic Mapping Study[END_REF][START_REF] Gabriel | Do Software Languages Engineers Evaluate their Languages?[END_REF]. Most of the reported DSLs evaluations are performed only at final stages of a development cycle, when changes in the DSL have a significant impact on the budget. The lack of systematic approaches, guidelines and comprehensive set of tools may explain this shortcoming in the current state of practice. We argue that this situation is due to the perceived high costs of DSL evaluation, which lacks a consistent and computer-aided integration of two different and demanding complementary software processes: DSL development and usability engineering.

Software Language Engineering (SLE) is the application of a systematic, disciplined and quantifiable approach to the development, usage, and maintenance of software languages. Although the phases of DSL life cycle are systematically defined [START_REF] Mernik | When and How to Develop Domain-Specific Languages[END_REF], we claim that this process lacks one crucial step, namely language evaluation [START_REF] Barišić | Quality in Use of DSLs: Current Evaluation Methods[END_REF]. Existing Experimental Software Engineering (ESE) techniques [START_REF] Basili | The Role of Controlled Experiments in Software Engineering Research[END_REF] combined with Usability Engineering techniques [START_REF] Nielsen | Usability Engineering[END_REF] can be adopted to support the DSLs' evaluations. Our goal is to promote quality in use of DSLs by building up a conceptual framework that supports their development process by leveraging usability as a first-class concern.

We can engineer DSLs to become more usable with a combination of both proactive and reactive approaches. Current proactive approaches that can be used to improve DSL usability, such as guidelines of visual notation [START_REF] Moody | Evaluating the Visual Syntax of UML: An Analysis of the Cognitive Effectiveness of the UML Family of Diagrams[END_REF], usability heuristics [START_REF] Nielsen | Heuristic evaluation of user interfaces[END_REF], cognitive dimensions of notations framework [START_REF] Blackwell | Notational systems-the cognitive dimensions of notations framework[END_REF][START_REF] Green | Usability analysis of visual programming environments: a cognitive dimensions framework[END_REF], or even quality assessment framework for DSLs [START_REF] Kahraman | A framework for qualitative assessment of domain-specific languages[END_REF]. Reactive approaches are necessary as well [START_REF] Kosar | Domain-Specific Languages: A Systematic Mapping Study[END_REF]; DSLs should be tested experimentally with humans using systematic techniques to confirm the impact of design decisions in a real context of use. We highlighted the experimental approach in [START_REF] Barišić | Evaluating the Usability of Domain-Specific Languages[END_REF], based on four DSL evaluation experiments that are examples of best practices ( [START_REF] Barišić | Quality in use of domain-specific languages: a case study[END_REF][START_REF] Kieburtz | A software engineering experiment in software component generation[END_REF][START_REF] Kosar | Program comprehension of domain-specific and general-purpose languages: comparison using a family of experiments[END_REF][START_REF] Murray | Kaleidoquery: a flow-based visual language and its evaluation[END_REF]). Recently, we can find more examples of performing this kind of assessments in practice (e.g. [START_REF] Erdweg | Evaluating and comparing language workbenches: Existing results and benchmarks for the future[END_REF][START_REF] Häser | Is business domain language support beneficial for creating test case specifications: A controlled experiment[END_REF][START_REF] Johanson | Effectiveness and efficiency of a domain-specific language for high-performance marine ecosystem simulation: a controlled experiment[END_REF][START_REF] Albuquerque | Quantifying usability of domain-specific languages: An empirical study on software maintenance[END_REF][START_REF] Meliá | Comparison of a textual versus a graphical notation for the maintainability of MDE domain models: an empirical pilot study[END_REF]).

Usability concerns need to be addressed from the early stages of the DSL life cycle so that practitioners can perform timely evaluations [START_REF] Izquierdo | Engaging end-users in the collaborative development of domain-specific modelling languages[END_REF]. Rather than designing the complete DSL before the implementation, abstractions should be evaluated iteratively and incrementally, in the context of a development cycle [START_REF] Barišić | How to reach a usable dsl? Moving toward a systematic evaluation[END_REF]. Building the systematic iterative usability evaluation approach is supposed to mitigate the risk of producing the inappropriate solutions that often cannot be reused. This work is expected to enhance the community's awareness to the relevance of DSLs' usability assessments to bridge the gap between the domain users and abstractions provided by language engineers.

The main contribution of this paper is a conceptual approach, which highlights the complexity of relevant knowledge that should be traced in the DSL development process to support the usability evaluations and experimental design. In Section 2 the DSL development cycle and the notion of usability engineering is introduced. In Section 3 a research process and previous work are described. In Section 4 we present a USE-ME conceptual framework, namely its domain concepts, meta-models and activity specifications. Section 5 provides a proof of concept for USE-ME approach by illustrating the conducted usability trials with the Visualino language using an early framework prototype. In Section 6 we discuss the applicability of our approach during a DSL development. Section 7 discuss related work. Finally, we conclude in Section 8.

Background

The immersion of computer technology in a wide range of domains leads to a situation where the users' needs become increasingly demanding and complex. Consequently, the development of successful software systems becomes increasingly more complicated. Software engineers need to cope with the growing of both essential and accidental complexity [START_REF] Brooks | The Mythical Man-Month[END_REF]. They have to provide solutions that solve a class of crucial problems in a given domain, which is sometimes very difficult to learn, such as the rules and technical jargon found in knowledge areas such as Physics, Finance, Medicine, etc. Also, it is necessary to deal with the accidental complexity of the used technology, e.g., the use of low-level abstraction programming languages while integrating a wide plethora of different tools and libraries.The adoption of DSLs is regarded as an approach to reduce the accidental complexity of software systems development [START_REF] Correal | Using Domain Specific Languages for Software Process Modeling[END_REF][START_REF] Völter | Model-driven software development: technology, engineering, management[END_REF][START_REF] Gray | Domain-specific modeling[END_REF].

Domain-Specific Language (DSL)

A DSL is a language that supports solutions to essential problems from a given domain (e.g. Physics Computing, Financial Domain, Health-care, Control Systems, and Gaming). They are intended to raise the level of abstraction closer to users' domain understanding. Opposing to a GPL, such as Java or C++, that is meant to be applicable across domains, a DSL offers the end user the possibility to express his needs in terms of the domain of the problem instead of in terms of the computational solution [START_REF] Selic | The pragmatics of model-driven development[END_REF]. DSLs provide a notation tailored towards an application domain as they are based on models of relevant concepts and features of the domain [START_REF] Mernik | When and How to Develop Domain-Specific Languages[END_REF]. As DSLs are used to describe and generate members of a family of systems or products in the application domain, they give the expressive power to model the required family members more easily. DSLs are claimed to match users' mental model of the problem domain by constraining the user to the given problem [START_REF] Hermans | Domain-Specific Languages in Practice: A User Study on the Success Factors[END_REF]. Finally, DSLs simplify the development of applications in specialised domains at the cost of their generality.

The use of the Model-Driven Development (MDD) techniques and tools are seen as a viable approach for dealing with accidental complexity [START_REF] Völter | Model-driven software development: technology, engineering, management[END_REF]. MDD is grounded on the notion of providing explicit Models, seen as 'first class artefacts' in the process, that are further transformed into other lower level, more detailed, models. These transformations are also considered as development artefacts and can be explicitly modelled by using transformation models. This approach has the special impact in dealing with the complexity of large-scale problems while enabling rapid prototyping, simulation, validation and verification techniques [START_REF] Kelly | Domain-specific modeling: enabling full code generation[END_REF][START_REF] Weiss | Software Product-Line Engineering: A Family-Based Software Development Process[END_REF].

In general, 'A model is a representation of something, constructed and used for a particular purpose' [START_REF] Benyon | Conceptual modeling for user interface development[END_REF]. Kühne defines this concept more appropriate to our context as 'A model is an abstraction of a (real or language-based) system allowing predictions or conferences to be made' [START_REF] Kühne | Matters of (meta-) modeling[END_REF]. Modellers build models to represent something. But a model has no meaning by itself. The information in the model can be understood if the model is combined with an interpretation. Extracting the correct meaning from the model can only be achieved if a common understanding of the concepts between modeller and the interpreter (who will typically use the model) is established. This common understanding leads us to a language. In practice, DSLs can be used to represent domain-specific models in MDD approaches. Each different model adopted by an MDD approach can be seen as a DSL that addresses the modelling of abstractions at a specific stage of software development. We have several guides that discuss how to implement a DSL based on MDD approach [START_REF] Selic | The pragmatics of model-driven development[END_REF][START_REF] Atkinson | Model Driven Development: A Metamodeling Foundation[END_REF][START_REF] Strembeck | An approach for the systematic development of domain-specific languages[END_REF].

DSL stakeholders

A Language Engineer is a professional who is skilled in the application of the engineering discipline to the creation of software languages. This professional manages the implementation priorities, designs the software language and is responsible for making the language functional at the system level. In general, Language Engineers are involved in the language specification, implementation, and evaluation, as well as in providing templates and scripts [START_REF] Kleppe | Software language engineering: creating domain-specific languages using metamodels[END_REF].

A DSL User or Domain User is any person who uses software languages to create applications (e.g. application developers) [START_REF] Kleppe | Software language engineering: creating domain-specific languages using metamodels[END_REF]. The possible user base of the models can easily be broader as domain-specific modelling allows application users to be better involved in the application development process. In that case, customers, other than typical application developers, can read, accept and in some cases change application specifications, being directly involved in the application development process. A Domain User can work with models which apply concepts directly related to specific characteristics of the configuration, such as specifying deployment of software units to hardware, or describing high-availability settings for uninterrupted services with redundancy for various fault recovery scenarios [START_REF] Kelly | Domain-specific modeling: enabling full code generation[END_REF].

A Domain Expert is a person involved in the language development process, also sometimes known as a knowledge engineer. In the case of domain-specific modelling, they do not need to have the software development background, but they can specify the application for code generation. A Domain Expert specifies models for concept prototyping or concept demonstration, and Language Engineers can proceed from these models. They are responsible for managing system goals and iterations. In contrast with Domain Users, they should have domain knowledge that includes areas of all target model applications.

DSLs are usually built by Language Engineers in cooperation with Domain Experts [START_REF] Völter | Model-driven software development: technology, engineering, management[END_REF]. In practice, Domain Users will use the DSL. These Domain Users are the real target audience for the DSL. The Domain Experts and Language Engineers can play the Domain User role, but they are, often, just a small subset of target end-users population. Although Domain Users are familiar with the domain, they are not necessarily as experienced as the Domain Experts. They may also lack the experience of Language Engineers in using languages. So, it may turn out that the language is valid by construction for Domain Experts and Language Engineers, but not necessarily to other Domain Users. Neglecting Domain Users in the development process may lead to a DSL they are not really able to work with.

DSL life-cycle

Several steps are detailed by Thibault [START_REF] Thibault | Domain-Specific Languages: Conception, implementation and application[END_REF], Völter [START_REF] Völter | Model-driven software development: technology, engineering, management[END_REF], Mernik [START_REF] Mernik | When and How to Develop Domain-Specific Languages[END_REF], Visser [START_REF] Visser | WebDSL: A Case Study in Domain-Specific Language Engineering[END_REF], Strembeck and Zdun [START_REF] Strembeck | An approach for the systematic development of domain-specific languages[END_REF], to develop a DSL, contributing to the formal definition of the DSL life-cycle. The following are listed as DSL development phases: decision, analysis, design, implementation and deployment. Mernik [START_REF] Mernik | When and How to Develop Domain-Specific Languages[END_REF] provided a set of patterns that describe common situations that potential developers may find themselves in, and were already tackled successfully by previous DSL development.

The first phase is the Decision that corresponds to the 'when' part of the DSL development, while the remaining phases to the 'how' part. Its goal is to identify the need for a DSL to the domain and its validity, which includes justifying that the effort to invest in its creation can be compensated. To make the decision, the stakeholders (including Domain Experts and Language Engineers) need to discuss the requirements of the domain following DSL development patterns.

The following phase is the Analysis. Its goal is to define the domain model with support to the DSL. The analysis has to take into account the particularities of the domain that will be explored, such as the terms and expressions intrinsic to a problem. In this phase Domain Experts helps Language Engineers to define the description of domain concepts, the feature models, the functional and technical requirements, and the goal model. The Analysis phase primarily produces a domain model, representing common and varying properties of the system within the domain [START_REF] Czarnecki | Overview of generative software development[END_REF]. The domain model will be used to assist with the creation of configurable architectures and components.

The next phase is Design, where Language Engineers formalise a language abstract syntax (i.e. meta-model) and define the representations for the model elements and production/composition rules. Additionally, the semantics of the language is defined. The design approaches of DSL design can be characterised along two orthogonal dimensions: the relationship between the DSL and existing languages, and the formal nature of the design description [START_REF] Mernik | When and How to Develop Domain-Specific Languages[END_REF]. A DSL can be designed from scratch or based on an already existing language.

The fourth phase is the actual Implementation, which includes the integration of DSL artefacts with the infrastructure, as well as the implementation of the necessary DSL to platform transformations. A DSL can be implemented by different approaches (e.g., interpreter, compiler, preprocessing, embedding, extensible compiler/interpreter, COTS, hybrid [START_REF] Mernik | When and How to Develop Domain-Specific Languages[END_REF]), each having its own merits [START_REF] Kosar | A preliminary study on various implementation approaches of domain-specific language[END_REF]. In this phase the developers produce the model checkers and simulators, which will help the modeler to validate the specified models. Finally, the DSL is delivered with its documentation in the Deployment phase. While Domain Experts themselves can understand, validate and modify the software by adapting the models expressed in DSLs, more substantial changes may involve altering a DSL implementation. Therefore, the DSL should have a migration strategy, as any other software product. We argue that this process lacks an important step: Evaluation [START_REF] Barišić | How to reach a usable dsl? Moving toward a systematic evaluation[END_REF][START_REF] Čeh | Ontology driven development of domain-specific languages[END_REF], just before the deployment (see Figure 1), that should include the verification (testing if the right functionality is provided by the DSL) as well as its validation (testing if this DSLs is right for its users). According to the current practice, the focus of evaluation is only on the language engineering, and not on its usability, which is a clear lack of validation which involves the end-users [START_REF] Kosar | Domain-Specific Languages: A Systematic Mapping Study[END_REF]. Current verifications are supported by model checkers and simulators. As the DSL promote the modifications of models which are claimed to be easier to produce and their impact to be easier understood, supporting language should be systematically evaluated by real user actions. This phase is expected to help mitigate a most pervasive problem of software engineering, i.e. software comprehension [START_REF] Rajlich | The role of concepts in program comprehension[END_REF], that addresses the problem of associating human oriented concepts with their counterpart solution domain concepts (e.g. computational terms).

Visser [START_REF] Visser | WebDSL: A Case Study in Domain-Specific Language Engineering[END_REF] recommends the inductive approach which, in opposition to designing the complete DSL before implementation, incrementally introduces abstractions that allow capturing a set of common programming patterns in software development for a particular domain. Visser also states that developing the DSL in iterations can mitigate the risk of failure. Instead of a big project that produces a functional DSL in the end, an iterative process produces useful DSL early on. The availability of sophisticated language workbenches facilitates the development of DSLs making them increasingly more popular. This comes at the risk that a badly designed DSL can bring more harm than benefits and decrease productivity when compared a GPL alternative. In particular, a poorly designed DSL can be too hard to adopt by its domain users. As such, to evaluate usability is one of the key characteristics to mitigate this risk as it has an important impact on the achieved productivity of DSL users.

Approach for evaluating Usability of DSL

While thinking about programming languages, DSLs are conceived as communication interfaces between human and computers. Therefore, if we take into account the main purpose of Human-Computer Interaction (HCI), we can conclude that to evaluate DSLs has several similarities to assessing regular User Interfaces (UIs) [START_REF] Barišić | Quality in use of domain-specific languages: a case study[END_REF]. We argue that any UI is a realisation of a language, where a language is considered as a theoretical object (i.e. model) that describes the allowed terms and how to compose them into the sentences involved in a particular HCI.

Usability Engineering is a field that is generally concerned with HCI and specifically with devising UIs that have high usability. It provides structured methods for achieving efficiency and elegance in interface design [START_REF] Nielsen | Usability Engineering[END_REF]. Empirical (i.e. experimental) evaluation studies of UIs with real users is a crucial phase of the usability engineering life-cycle [START_REF] Dix | Human computer interaction[END_REF]. A relevant set of quantitative and qualitative measurements must be inferred and combined together to lead to a useful assessment of the several dimensions that define software Quality in Use, often referred to as Usability [START_REF]2011 Systems and software engineering -Systems and software Quality Requirements and Evaluation (SQuaRE) -System and software quality models[END_REF].

Usability i.e. Quality in Use

The notion of Usability is used in many different contexts and its definitions developed progressively. Usability is defined by Shackel and Richardson [START_REF] Shackel | Human factors for informatics usability[END_REF] as the capability in human functional terms to be used easily and effectively by the specified range of users, given specified training and user support, to fulfill technically specified range of tasks, within the specified range of environmental scenarios. Shortly, Usability is 'the capability to be used by humans easily and effectively, where 'easily = to a specified level of subjective assessment'; 'effectively = to a specified level of (human) performance'.

Usability is the quality characteristic that measures the ease of use of any software system that interacts directly with an end user. It is a subjective non-functional requirement that can only be measured indirectly by the extent to which it satisfies its corresponding needs based on the the users' cognitive capacity. It focuses on features of the HCI. Usability is the result of the achieved level of quality in use of a software system i.e. a user's view of quality. It is dependent on achieving the necessary external and internal quality that is influenced by the achievement of different quality attributes dependent on a context of use. Tests of language usability are based on measurements of the users' experiences with it.

International Organisation for Standardization (ISO) firstly defines Usability as 'the effectiveness, efficiency, and satisfaction with which specified users achieve specified goals in particular environments' (ISO 9241-11 [START_REF]terminals (VDTs) -Part 11: Guidance on usability[END_REF]). Later on, the notion of Usability is integrated into the software quality framework under the term Quality in Use (ISO 9126 [START_REF] Standardization | Information Technology -Software Product Evaluation -Software Quality Characteristics and Metrics[END_REF]). Finally, Usability is defined as 'degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use'. Usability can either be specified or measured as a product quality characteristic in terms of its sub-characteristics, or specified or measured directly by measures that are a subset of quality in use (ISO/IEC 25010 [START_REF]2011 Systems and software engineering -Systems and software Quality Requirements and Evaluation (SQuaRE) -System and software quality models[END_REF]).

There is an increasing awareness to the quality in use of languages, fostered by the competition of language providers. Better usability is a competitive advantage, although evaluating it remains challenging. While evaluating competing languages, it is hard to:

1. interpret the existing metrics in a fair, unbiased way; 2. provide relevant design changes; and 3. assure that the scope of their evaluation is preserved to target user groups. Software Expert Evaluators typically implement complex experimental evaluation studies. Their expertise is essential to design the evaluation sessions properly and to gather, interpret, and synthesise significant results. Although it is desirable to have an Expert Evaluator within in the teams, it is not always possible. This calls for the need of automated tools that support these experts, as well as other DSL stakeholders.

Usability Design -How and When?

Usability has two complementary roles in design: as an attribute that must be designed into the product, and as the highest-level quality objective, which should be the overall purpose of design [START_REF] Petrie | The evaluation of accessibility, usability and user experience[END_REF]. Two important issues are how and when to assess DSL usability.

Concerning the how, we can think of DSLs as communication interfaces between their users and a computing platform, making DSL usability evaluation a particular case of evaluating UIs [START_REF] Barišić | Quality in Use of DSLs: Current Evaluation Methods[END_REF]. This implies identifying the key quality criteria from the perspective of the most relevant stakeholders, to instantiate an evaluation model for that particular DSL [START_REF] Kahraman | A framework for qualitative assessment of domain-specific languages[END_REF][START_REF] Barišić | Patterns for Evaluating Usability of Domain-Specific Languages[END_REF]. These criteria are the evaluation goals, for which a set of relevant quantitative and qualitative measurements must be identified and collected. We borrow from UI evaluation several practices, including obtaining these measurements by observing or interviewing, users [START_REF] Rubin | Handbook of Usability Testing: How to plan, design and conduct effective tests[END_REF]. In general, it is crucial that the evaluation of HCIs includes real users [START_REF] Dix | Human computer interaction[END_REF], for the sake of its validity. In the context of DSLs, the 'real users' are the Domain Users (see Sec.2.1.1).

Interactive usability investigation methods apply contextual inquiry and formative usability testing as crucial for successful usability design [START_REF] Paz | A Systematic Mapping Review of Usability Evaluation Methods for Software Development Process[END_REF]. Usability Testing (UT) includes task analysis that studies the way people perform tasks with existing systems. By a high-level abstraction study of cognitive processes, we could identify what are the individual tasks that the language is expected to support. The cognitive activities that should be analysed are:

1. Composition of the syntax required to perform a function; 2. Comprehension of function syntax composed by someone else; 3. Debugging of syntax or semantics written by ourselves or others; 4. Modification of a function written by ourselves or others.

Experimenters in human factors developed a list of tasks to capture these particular aspects [START_REF] Reisner | Query languages[END_REF]: Sentence Writing, Sentence Reading, Sentence Interpretation, Comprehension, Memorization, and Problem solving. We can evaluate these tasks using tests such as Final exams, Immediate Comprehension, Reviews, Productivity, Retention, and Re-learning. Performing exhaustive evaluation of different tasks in the language usage is interesting, but would be too expensive. Therefore, the evaluation usually concerns only the most critical activities.

More general method in accessing usability are Heuristic evaluation (HE) [START_REF] Nielson | Usability Engineering[END_REF], but are often regarded as not being capable to encompass all usability attributes. Recently, new evaluation method called Domain Specific Inspection (DSI) is developed using traditional evaluations (HE and UT) in novel ways [START_REF] Paz | A Systematic Mapping Review of Usability Evaluation Methods for Software Development Process[END_REF]. The lack of a methodological framework that can be used to generate a domain-specific evaluation method, which can then be used to improve the usability assessment process for a product in any chosen domain, was proposed by Alroobaea [START_REF] Alroobaea | Generating a Domain Specific Inspection Evaluation Method through an Adaptive Framework: A Comparative Study on Educational Websites[END_REF]. It is shown that this adaptive framework is able to build a formative and summative evaluation method that provides optimal results with regard to the identification of comprehensive usability problem areas and relevant usability evaluation method metrics, with minimum input in terms of the cost and time usually spent on employing usability evaluation method.

Concerning the when, we argued that we should adopt a systematic approach to obtaining a timely frequent usability feedback, while developing the DSL, to better monitor its impact [START_REF] Barišić | How to reach a usable dsl? Moving toward a systematic evaluation[END_REF]. This implies the integration of two different and demanding complementary processes: language development and usability evaluation. Language Engineers should be aware of usability concerns during development, to minimise rework caused by unforeseen usability shortcomings. In turn, Expert Evaluators should have enough understanding of the domain-specific models involved in software language development to be able to properly design the evaluation sessions, gather, interpret, and synthesise meaningful results that can support the DSL improvements in a timely way.

The timely frequent usability testing is in line with agile practices, making them a good fit for this combined DSL building (i.e. software development) and evaluation process (i.e. usability design) [START_REF] Lárusdóttir | Informal feedback rather than performance measurements: user-centred evaluation in Scrum projects[END_REF]. Agile development process breaks products into small increments, and each iteration should fit in short time-boxes that typically not last more than a month [START_REF] Cockburn | Agile software development: The people factor[END_REF]. This iterative, incremental development process is also in alignment with Visser's inductive DSL development suggestion [START_REF] Visser | WebDSL: A Case Study in Domain-Specific Language Engineering[END_REF] (see Sec. 2.1.2). Agile practices provide a method for gathering user feedback by conducting a focus group after a feature was implemented, and ask for users' opinions. However, this approach is insufficient in supporting usability design which is largely based on observing user behaviour by utilisation of usability investigation before product implementation [START_REF] Sy | Adapting usability investigations for agile user-centered design[END_REF].

Therefore, it is necessary to apply a User-Centered Design (UCD) that is comprised of end user involvement in the development of software products at different points of the life-cycle. UCD include techniques that support usability design such as ethnographic research, participatory design, focus group research, surveys, walk through, preliminary prototyping, expert or heuristic evaluation, usability testing, as well as follow-up studies [START_REF] Rubin | Handbook of Usability Testing: How to plan, design and conduct effective tests[END_REF][START_REF] Norman | User centered system design[END_REF][START_REF] Vredenburg | A survey of user-centered design practice[END_REF]. UCD can be characterised as a multistage problem-solving process. It foresees how users are likely to use a product and tests the validity of their assumptions concerning user behaviour in real world tests with actual users. Such testing is necessary as it is often tough for the developers of a product to understand what is intuitive for an end user of their design experiences, and what each user's learning curve may look like. The essential activities required to implement UCD are described in ISO 13407 [START_REF] Bevan | Cost benefits framework and case studies[END_REF].

Contextual aspects of DSL usability evaluation

In this particular research, we only consider languages that are used as communication interfaces between humans and computers (i.e. UIs). Therefore human-human languages, e.g. natural languages, and machine-machine languages, e.g. communication protocols, are not relevant for the work described in this paper.

Semiotics, the study of the structure and meaning of languages, is a part of linguistics that studies the dependencies and influences among syntax, semantics, and pragmatics. The syntax of a language defines what signs we can use in that language, and how we can compose those signs to form sentences. The semantics of a language defines the conceptual meaning of the sentences in that language by stating how they can be logically interpreted. Finally, the pragmatics sets the context of use from which the sentences of that language can have some logical meaning [START_REF] Sgall | The meaning of the sentence in its semantic and pragmatic aspects[END_REF].

The Context of Use i.e. 'the users, tasks, equipment (hardware, software and materials), and the physical and social environments in which a product is used' [START_REF] Standardization | Information Technology -Software Product Evaluation -Software Quality Characteristics and Metrics[END_REF] is one of the characteristics that we must be considered while evaluating DSLs usability. This is to pragmatically distinguish between DSLs scope of the assessments. Different DSLs, especially the ones that are developed for various domains, have a different Context of Use. We can infer that the users of those DSLs, most likely, will have different knowledge sets, each one with a minimum amount of ontological concepts required to be able to use each language.

We need a rigorous and collaborative usability evaluation procedure for DSL (both during and after the particular DSL development) that supports validation of DSL sentences (called instance models) in a correct Context of Use. According to the context of communication, these sentences can have different interpretations. If the context is not clear, interpretations can be ambiguous. Notice that, in this pragmatic perspective, languages that do not even share the same base syntax of those same sentences may share the same domain concepts, i.e. the intersection of their domain concepts is not empty for a given non-empty intersection of contexts of use. If the intersection of their contexts of use is empty, then they do not share any of the identified domain concepts.

The USE-ME Research Process

The design science methodology [START_REF] Von Alan | Design science in information systems research[END_REF][START_REF] Simon | The sciences of the artificial[END_REF][START_REF] Wieringa | Empirical research methods for technology validation: Scaling up to practice[END_REF] fosters the creation of artefacts that are driven to problem-solving projects. Wieringa [72] see design science projects as a set of nested regulative cycles that solve practical (i.e. engineering) and a knowledge (i.e. research) problems that are decomposed in sub-problems. Knowledge problem is defined as a 'difference between the way the world is experienced by the stakeholders and the way they would like it to be'. A research problem is the 'difference between the current knowledge of stakeholders about the world and what they would like to know'.

The motivation of this work is to provide a systematic methodological approach to evaluate the usability of domain-specific languages during its development for application domains that target large end-user groups (see Section 1). Following this above-mentioned methodology, we characterise our problem as an engineering (i.e. practical) problem and argue that the goal of any DSL that is meant to be used by humans is to improve the productivity of its users. To achieve this goal, it is mandatory to increase the usability of the language (Section 2).

We address following research questions:

Q1: How can we promote usability concerns since an early stage of development of the DSL? Q2: How are we able to trace and validate language goals and usability evaluation coverage?

The regulative cycle follows the five tasks: problem investigation, solution design, design validation, solution implementation and implementation evaluation (see Figure 2). The first step is to analyse the problem in detail during the 'Problem investigation', namely to identify the stakeholders, their goals, problematic phenomena, causes, impacts and solution criteria. The following step is to analyse available solutions and design new ones during 'Solution design'. The next step is to perform 'Design validation' during which we validate solution properties and satisfaction of criteria. We observe goals, trade-offs and sensitivity of approach. The details about the first three phases were subject of previous work [START_REF] Barišić | How to reach a usable dsl? Moving toward a systematic evaluation[END_REF][START_REF] Barišić | Patterns for Evaluating Usability of Domain-Specific Languages[END_REF][START_REF] Barišić | Evaluating the Usability of Domain-Specific Languages[END_REF], and are briefly discussed in the following sub-sections. Further, we discussed the 'Solution implementation' in Section 4, by presenting the concepts and activities which are mandatory for the application of the approach. Finally, 'Implementation Evaluation' is discussed in Section 5.2.

Problem investigation

The first step was to analyse the problem in detail. We started by focusing our attention onto stakeholders who have the need for a DSL, i.e. Domain Users, and specify their goals regarding a development of the DSL in Section 2. To understand better the problem, they are facing and their causes, we have analysed the existing DSL development techniques and artefacts produced during a regulative development cycle. The development of different DSLs followed in the context of the FCT/UNL faculty's DSL courses and DSL summer school1 . These activities gave us a practical experience in using different modelling workbenches (EMF, TextEdit, Eugenia, MetaEdit, Kaos, ATL). We reported our experience during the development of a Role-Playing Game (RPG) DSL following the regulative development cycle [START_REF] Marques | The RPG DSL: a case study of language engineering using MDD for Generating RPG Games for Mobile Phones[END_REF]. Besides that, we have performed an initial evaluation on the DSL named Pheasant for high energy physics domain [START_REF] Barišić | Quality in use of domain-specific languages: a case study[END_REF]. This study helped us understand the impact of the problem in the context where the DSL is meant to be used by non-programmers in a sensitive context. Finally, we analysed existing evaluation examples of DSLs and specified a generic experimental model [START_REF] Barišić | Evaluating the Usability of Domain-Specific Languages[END_REF]. The experimental model helped us understand the criteria for stakeholders to consider the problem as solved.

RPG DSL

In this case study, an RPG DSL for product lines was developed, which was completely built using MDD software development techniques [START_REF] Marques | The RPG DSL: a case study of language engineering using MDD for Generating RPG Games for Mobile Phones[END_REF]. We have shown several benefits of applying MDD regarding prototyping of cross-platform games, and their evaluation by means of static and dynamic verification techniques of the game's logic properties.

In the Domain Analysis phase, we worked on two different levels: at the problem level (i.e., expressing the concepts and logics of RPG Games), and at the solution level (i.e., how those concepts can be realised in a computational platform). At the level of the problem of RPGs' design, we tried to express and define what would be the common characteristics of all RPG games, regardless of what are the requirements of their implementation on an underlying computation infrastructure. At the solution (computational) level, we had to choose platforms to deploy the generated games and to analyse them. We chose a game developing platform and built our framework on top of it. The criteria to select the target framework from the existing game engines were: fast development; provided abstraction level relatively to system calls and hardware dependencies (e.g., graphical primitives, input modalities, etc.); and, need to previous knowledge in the area of game engines.

We chose Corona SDK 2 from a set of three promising candidate frameworks because it supports the possibility to compile the game for different mobile platforms. The game is programmed using the Lua language: a scripting language, which is preferred for rapid development. The creation of an API over the framework allowed a model to model transformation that was easily produced between RPG and Framework meta-models, which consists mostly of 1 to 1 relationships. This strategy of bottom-up modelling in the framework allowed the focusing on the RPG entities. The mapping of the RPG meta-model to APN is too complex to be performed in just one step. Therefore we introduced an intermediate meta-model RPG, that allowed a simpler mapping between both.

Pheasant

The DSL on this case study published in [START_REF] Barišić | Quality in use of domain-specific languages: a case study[END_REF], called Pheasant (Physicist's Easy Analysis Tool), is assessed in contrast with a pre-existing GPL baseline. The comparison combines quantitative and qualitative data, collected with users from a real-world setting, and was performed at the end of the development process. The goal of Pheasant's development was to improve the efficiency, reduce the error rate and have a less steep learning curve than the existing GPL. The target users of the Pheasant language are specialists in High Energy Physics, with varying experience in software development. The evaluation was performed according to the ISO 9241-11 usability definition, which is an essential part of the achieved Quality in Use.

The assessment includes Physicists with programming experience with two profiles: the ones with no experience with the previous framework used and the experienced ones. The goal was to analyse the performance of Pheasant programmers compared to the baseline alternative with respect to the efficiency, effectiveness and confidence in defining queries in Pheasant. The assessment was done from the point of view of a researcher trying to assess the Pheasant DSL, in the context of a case study on selected queries.

Introducing one language to the whole group of participants and only afterwards the other language would bias the evaluation, as the knowledge acquired while learning the first language could be partially reused while using the second language. To mitigate this threat to the validity of the results we had to split the group in two. This way, it reduced the influence of the first language while presenting the second. Mixing the two groups might lead to new variables in the evaluation that are hard to track. Therefore, it was necessary to organise four sessions, with each group taking part in two sessions (one for each language). Following the scientific method, the participants' performance in the query writing was evaluated. Every participant had four queries, specified in English, to be rewritten in the previously learned language.

Using Pheasant, the users increased effectiveness during their query specification. The DSL was less error-prone than the alternative; it is allowed non-programmers to define their queries correctly. The evaluation also showed a considerable speedup in the query definition by all the groups of users that were using Pheasant. In general, the feedback obtained from the users was that it is more comfortable to use Pheasant with the alternative. The preliminary pilot study was fundamental to ensure that the subject's time was well spent. This work's contribution illustrates how an experimental process (Section 2.2.4) can be used in the context of a DSL evaluation, with respect to its impact on Quality in Use characteristics (Section 2.2.1), namely effectiveness and efficiency. The valuable feedback from users concerning the tool support for the language, as well as their fears concerning language expressiveness, support the idea of an iterative evaluation process where improvements to the language and its tool support are to be performed and then assessed in a new round of evaluation.

Experimental Model

In the context of Software Engineering, a controlled experiment can be defined as 'a randomised experiment or quasiexperiment in which individuals or teams (the experimental units) conduct one or more Software Engineering tasks for the sake of comparing different populations, processes, methods, techniques, languages or tools (the treatments)' [START_REF] Sjøberg | A survey of controlled experiments in software engineering[END_REF]. For our purposes, this can be instantiated with developers typically conducting software construction, or evolution tasks, for the sake of comparing different languages including the DSL under evaluation and any existing baseline alternatives to that DSL. This complex challenge was covered by a general model for DSL experimental evaluation presented in [START_REF] Barišić | Evaluating the Usability of Domain-Specific Languages[END_REF], that served as a set of instantiations that were proof of concept of the proposed model.

When conducting language evaluation experiments, one should clearly define the experiments' objectives. Building upon Basili's earlier work [START_REF] Basili | The role of experimentation in software engineering: past, current, and future[END_REF], Wohlin et al. proposed a framework to guide the experiment definition [START_REF] Wohlin | Experimentation in Software Engineering: An Introduction[END_REF]. The framework is to be mapped into a template with the following: the object of study under analysis, the purpose of the experiment, its quality focus, the perspective from which the experiment results are being interpreted, and the context under which the experiment is run.

While the experiment definition expresses something about why a particular language evaluation is performed, the experiment planning expresses something about how it can be performed. Before starting the experiment, decisions have to be made concerning the context of the experiment, the hypotheses under study, the set of independent and dependent variables that will be used to evaluate the hypotheses, the selection of subjects participating in the experiment, the experiment's design and instrumentation, and also an evaluation of the experiment's validity. Only after all these details are sorted out should the experiment be performed. The outcome of planning is the experimental language evaluation design, which should encompass enough details to be independently replicable.

Solution design

After the problem has been characterised, it was necessary to research the domain to justify that none of the existing solutions solve the problem [START_REF] Barišić | Quality in Use of DSLs: Current Evaluation Methods[END_REF]. As no satisfactory solution has been found, there was room to propose a new one. As a consequence, a new solution is designed with the aim to solve the problem [START_REF] Barišić | How to reach a usable dsl? Moving toward a systematic evaluation[END_REF]. The usability of a language needs to be evaluated through controlled experiments involving the language's end users. To be able to identify potential quality problems that will lead to user interaction and experience problems, a suitable approach is to apply UCD practices during design and development of the language. Nevertheless, it is found hard to control budget and plan time and responsibilities accordingly. An incremental, iterative process should be applied to enable tracking of design changes and validation of usability metrics.

Patterns for DSL evaluation

In [START_REF] Barišić | Patterns for Evaluating Usability of Domain-Specific Languages[END_REF] we proposed an iterative user-centered approach for DSL evaluation that is to be used during DSLs' life-cycle. This proposal illustrates correspondences between the DSL development process (Section 2.1.2) and the agile UCD approach (Section 2.2.2). The goal of our approach is to support DSL usability evaluations since the early stages of its development to prevent user-interaction mistakes, hence achieving a usable DSL by construction. The initial vision is detailed by a pattern language for evaluating the usability of DSLs that places the intended users of a language as the focal aspect of its design and conception by establishing formal correspondences for all stages between the DSL development process and the usability evaluation process. This iterative approach allows us to track the usability requirements and impact of recommendations, with a well-prepared evaluation process, allowing us to control the budget and the scope of the language's evaluation. This set of practices reflecting high-level guidelines are:

(i) Agile development process including patterns devoted to project management and engineering of a DSL. Through organisation and planning of language development, this practice enables the control of evaluation activities, their scope (i.e. the context of use), the budget and tracking the success of the DSL. (ii) Iterative UCD is providing patterns for the engagement of the Expert Evaluator into the development process, with the intention of collecting relevant information concerning the Language Engineer perception of the problem solution and Domain Users' interpretation. Depending on the cognitive model instances to be evaluated, the DSL implementation technique or usability investigation technique, each design vary a lot. (iii) Experimental evaluation design supporting the definition of experiment execution (e.g. hypothesis, tests, metrics, samples and statements) that were given by evaluation model [START_REF] Barišić | Evaluating the Usability of Domain-Specific Languages[END_REF]. This model supports the formal execution specification for any usability investigation assessment that includes involvement of the Domain Users.

To perform a DSL evaluation, a first step is to understand and specify its context of use. This activity is complementary to the domain analysis phase of DSL's construction. Further, a set of evaluation goals can be identified during the requirements' elicitation process. Interviews or questionnaires with the DSL's intended users can be designed to capture information about the working environment and by the baseline approach to solving problems. During DSL Design, it is necessary to validate if the design decisions conform to the context of use (e.g. chosen technical environment is integrable with the users' environment, or that the designed DSL constructs are understandable). Unclear assumptions can be improved through different iterations, but already with the first designs, the Expert Evaluator can define questions that could answer evaluation goals. During the Implementation, the evaluation model can be specified. The stakeholders that should be involved in the evaluation could already be profiled and prepared for the execution. In certain cases, just use of proactive approach can be sufficient to evaluate the iteration objectives. Finally, in the Evaluation phase the Expert Evaluator executes experiments and analyses the results, while the Language Engineers may still perform tests or prepare the product for Deployment.

The proposed iterative UCD evaluation approach can be merged into the development cycles of already existing and evolving languages. It enables us to intervene at any point of the DSL development. Very often the developers only become concerned with Usability issues in later phases of the DSL life-cycle.

Design validation

Once this design is completed, it is necessary to validate the solution (Design Validation) before its realisation. For that matter, the solution properties are assessed according to the criteria defined in the problem investigation, characterising the context of the target application and the coverage of the solution. If the solution has the desired effect for stakeholders in their context, the solution can be finally implemented. For that purpose, we have applied the approach in the two industrial cases of DSL development, namely FlowSL and Visualino. FlowSL served an instantiation of usability evaluation into DSL development guided by agile management during three iteration cycles [START_REF] Barišić | Evaluating the Quality in Use of Domain-Specific Languages in an Agile Way[END_REF]. The second one, Visualino, is an ongoing case study that we are performing, currently in the third iteration of the language's development and evaluation. This case study is a good representation of the DSL where the usability evaluation is mandatory as the users are children, and the programed behavior is expected to run on an Arduino robot. Finally, we applied our approach in the case of DSE Merge language [START_REF] Barišić | STSM Report: Evaluating the efficiency in use of search-based automated model merge technique[END_REF], which is to be used by the programmers. This experience showed how the end users who are programmers could also benefit from the usability approach. Also, in this familiar environment was even easier to set up a more complex experiment and explore several possibilities for reusing it a virtual evaluation environment. However, we shortly report on this experiences in the following subsections.

FlowSL

We applied action research to the development of a DSL, named FlowSL, designed to support managers when specifying and controlling the business processes supporting humanitarian campaigns [START_REF] Barišić | Evaluating the Quality in Use of Domain-Specific Languages in an Agile Way[END_REF]. FlowSL is targeted to non-programmers. Their ability to use this language was identified as one of the highest concerns, so discovering usability issues in early development iterations facilitated the achievement of an acceptable usability, while tracking the design decisions and their impact. Usability has two complementary roles in design: as an attribute that must be designed into the product, and as the highest level quality objective which should be the overall objective of design.

FlowSL is a DSL for specifying humanitarian campaigns to be conducted by a non-governmental organisation and is integrated into Movercado (MVC) 2 . This project consists of a mobile-based messaging platform at the core of an ecosystem that enables real-time and a more efficient impact, by facilitating interactions among beneficiaries, health workers and facilities, e-money and mobile operators. A first version of the system (MVC1) was developed as a proof-of-concept to validate the key underlying principles. The second version of the system (MVC2) was developed in the form of a platform easily customizable by managers and extensible by developers of the organization's team. An important goal was to develop a language, FlowSL, to empower the Campaign Managers to define new kinds of campaign flows taking advantage of their domain knowledge.

To balance the development effort with effective reusability (e.g. while envisioning new marketing solutions), MVC2 was developed in a fast-paced way, iteratively, along six two-weeks sprints, following an agile development process based on Scrum3 and best practices of evolving reusable software systems. In the process of development, the Domain Experts were part of the Product Owners team, while the Language Engineers were part of the Scrum Team. The DSL evaluation process was guided by the FlowSL development stages, as different effort was estimated in each sprint for its development. The problem analysis was performed by mutual interaction and brainstorming between Domain Experts and Language Engineers in each sprint planning. We had the role of observing and guiding the analysis outputs, while preparing the evaluation plan, without being directly involved in the language specification.

In this case study, we integrated top-down usability engineering practices into a bottom-up agile development of a DSL from its beginning. While playing the role of Evaluation Expert that is expected to be introduced into DSL development, we experienced that small iterations involving other project stakeholders then Language Engineers, namely Domain Experts, Product Owners and End Users, can help us to clarify the meaning and the definition of the relevant language concepts. This enables an early identification of possible language usability shortcomings and helps to reshape the DSL accordingly. Early evaluations can be executed with a relatively low-cost thanks to model-driven tools (i.e. language workbenches) that support the production of rapid prototypes and presenting the idea. These evaluations support well-informed trade-offs among the strategy and design of the DSL under development, and its technical implementation, by improving communication. Besides, they improve the traceability of decisions, and of the solution progress. These iterations also help to capture and clarify contractual details of the most relevant language aspects that need to be considered during DSL development and are an essential element to improve the End Users experience while working with FlowSL.

Visualino

Visualino is a visual DSL with the objective to support children while programming a low-cost Arduino robots 4 . It is developed iterative reusing user-centered design methods. Programming technologies of rover robots for children still are excluding the children as target audience as it is hard for them to program in a textual language with a complex syntax full of technical concepts. To design an appropriate DSL for children is far from being a trivial task. There is no unique profile, and several factors related mostly to age, like the maturity level, that can influence widely in the design.

A visual programming language allows the user to implement programs, through the manipulation of visual elements or objects. This manipulation is deduced in a visual way, allowing the user to understand programming mechanisms quickly, increasing their accessibility to new systems. Users with no programming background may implement programs in a simpler form. Visual languages introduce programming concepts to children, while robots perform the developed code in the real world. Children have the opportunity to observe their own developed program, running on a physical robot.

The focus of the evaluated work was to build a dedicated DSL that removes the programming details, to control a rover robot, and at the same time allows children to easily get acquainted with it and preserve the possibility to program complex behaviour. The development of this language, named Visualino, counted with a robot consisting of common components and functions in the robotic area. The work was developed under the collaboration between the group ASE NOVA/LINCS and Artica 5 , a company that specialises in the development of robotic and audio-visual solutions.

The chosen meta-modelling workbench for the DSL implementation was Eugenia for Eclipse. Its first development iteration was a part of the master theses, where its abstract syntax and initial concrete syntax was proposed [START_REF] Leonardo | Child Programming : An adequate Domain Specific Language for programming specific robots[END_REF]. The DSL implementation started with domain analysis that brought concepts and details, so it was possible to develop the DSL meta-model. Among different behaviour paradigms for visual language, after extended analysis, it was chosen to represent a language through behaviour trees. This last paradigm is an alternative to the state machines and comprehends a hierarchy of behaviours, with an objective to fulfil. Each node may have a specification that determines how the actions of its children will be executed, which may be in parallel or sequentially.

The first evaluation session was with children between 7-10 years old, and with adults. The evaluation with adults helped to validate the language's functions, while evaluation with children provided ideas how to fill in the gap of approaching this language to the youngest. After the second development cycle, we applied our approach to compare a Visualino with the well-known Lego 6 commercial DSL which paradigm is based on the building blocks composition.

We illustrated the evaluation model from this iteration in Section 5.2. This evaluation helped to understand which features are missing or can be improved to make Visualino competitive to the best product in the market with the same purpose. Finally, the developers addressed the recommendations during the third development cycle and renamed a language to Gyro. We further compared the Gyro to the existing low-cost alternative MBlock 7 , and has shown to be more usable when applied in the same context (e.g. with a same type of robots) 8 . We also manage to show that the usability of the Gyro significantly improved in terms of efficiency and satisfaction when compared to earlier version of language (Visualino).

The preliminary evaluations helped in timely detecting crucial usability problems of Visualino, as well as detecting the audience that can comprehend the given paradigm. The provided feedback helped in improving the language to support the intended user's needs. A fundamental difference in this work is that the language evaluation was introduced early in the DSL development process so that problems can be found on-time and fixed at a fraction of the cost it would take to fix them if detected only in the deployment phase.

DSE Merge

As a final case study reported in [START_REF] Barišić | STSM Report: Evaluating the efficiency in use of search-based automated model merge technique[END_REF], we evaluated the tool support developed within this project at Budapest University of Technology and Economics, named DSE Merge, which presents a novel search-based automated model merge [START_REF] Kessentini | Searching models, modeling search: On the synergies of SBSE and MDE[END_REF]. The framework built on top of off-the-shelf tools for model comparison, uses guided rule-based design space exploration (rule-based DSE) for merging models. In general, rule-based DSE aims to search and identify various design candidates to fill certain structural and numeric constraints. The exploration starts with initial models and systematically traverses paths according to specific operations properly identified by operators chosen by the end user. In this context, the results of model comparison will be the initial model, while a target design candidates will represent the conflict-free merged models'.

While many existing model merge approaches detect conflicts statically in a preprocessed phase, DSE carries out conflict detection dynamically, during exploration time thanks to the highlight of conflicting rules and constraint violations. Then, multiple consistent resolutions of conflicts are presented to the domain experts. This technique allows incorporating domain-specific knowledge into the merge process by additional constraints, goals and operations to provide better solutions. The alternative, i.e. baseline support for the model merge problem that is suitable for experimental comparison was found to have two possibilities: Diff Merge 9 and EMF Compare 10 .

The general experimental process started with the Learning session, during which the subjects filled the Background Questionnaire. After this, they proceeded by solving the exercises during the Task session, that was video recorded. Finally, during the Feedback session, participants filled a final questionnaire, rating tools that they have used. During the Learning sessions, the subjects learned about the domain and the tool. The subjects were invited to ask questions and to ask for help only after the presentation. During the Task session, the subjects were not limited by time to solve this tasks. They were not allowed to ask for help, except if they were experiencing some technical or connection problem.

During the pilot session, the cognitive effort for each task was estimated to be similar, the TLX scale 11 is decided to be used just once for each tool that is being evaluated, at the end of Video Session. Based on the results and opinions of the participants during the Pilot Session, it was found that Diff Merge is rated as a more competitive alternative for DSE Merge. The experimental groups were divided in two. One group started the Tool Session by learning about DiffMerge and then DSE Merge, while the second group had learned the other way around.

The most valuable contribution that resulted from this evaluation is the experiment design, instrumentation and metrics that can be easily repeated and reused for similar evaluations of new techniques. This experiment design took a deeper analysis of the subject's profiles, technology, social and physical environment and targeted workflow scenarios, which are defined explicitly and incorporated in a data collection instruments and reflected in the hypothesis. 7

Supporting usability evaluation methods during DSL development (Solution implementation)

As already mentioned in Section 2.2, usability engineering aims to increase the awareness and acceptance of established usability methods among software practitioners. Knowledge of the basic usability methods is expected to enhance the ease of use and acceptability of a system for a particular class of users carrying out specific tasks in a specific environment. It is claimed to affect the user's performance and satisfaction. We introduce usability engineering methods into the DSL life-cycle (see Section 2.1.2) by following an MDD SLE process.

The main concepts supporting the modelling approach are introduced as UML class diagrams. The flow of activities is described by UML activity diagrams. While discussing the supporting conceptual framework, we will use the following symbols; Similarly to other software qualities, usability evaluation should not be just added at the end of the development process. Following the discussion in Section 2, we argue that it has to be included in the development process from the beginning by accurately profiling the end-user and finding the right definition of the problem. The approach is to support usability evaluations, expressed as regular Expert Evaluator activities, in the SLE, backed by a conceptual framework that promotes the iterative UCD evaluation approach. The Usability Software Engineering Modelling Environment (USE-ME) presents a solution implementation and consists of the following modelling activities that are expected to be performed by the Expert Evaluator (see Figure 3):

-the Context Modelling to define the context of use for the DSL; -the Goal Modelling that sets the objectives for the DSL; -the Evaluation Modelling that instructs the usability experiments; -the Survey Modelling that provides the support for survey/feedback collection; -the Interaction Modelling that defines the interaction task under study; -the Report Modelling that supports management of the collected data.

The goal specifications for the DSL under evaluation are underpinned by the Catalogue of Usability Metrics that describes usability goals and its possible measurements and treatments. This Catalogue helps to specify the relevant metrics and interpretation of the results. Finally, the Goal Coverage Engine versions the iterative evaluations and defines context coverage for the validated goals. The Expert Evaluator in certain modelling activities is supported by artefacts and feedback provided by other DSL stakeholders. We present the process of usability evaluation using a USE-ME framework as an activity diagram (see Figure 4). First, it is necessary to produce a [Context Model (CM)], which supports the description of language context, based on which is possible to describe the usability goals as a [Goal Model (GM)]. The Language Engineer and the Domain Expert are involved into 'Context Modelling' and 'Goal Modelling', as they are expected to contribute to the interpretation of development artefacts (i.e. domain model, feature model, abstract syntax, etc.) and review of produced specifications. While specifying the goals and their scope, it is likely that the new context elements are found which are relevant for the use of the DSL. In this case, it is necessary to 'update a CM' and proceeds with specifying a [GM] till we have at least one usability goal for which only actor representing Expert Evaluator is responsible. Further, it is possible to define an [Evaluation Model (EM)], which highlights evaluation goals and their corresponding evaluation steps. The Language Engineer provides the developed artefacts (i.e. DSL, documentation, validation tests) and helps to prepare the evaluation. There is a 'need to specify a [Test Model]' or reuse existing one. The [Test Model] is crucial for the assessment process and can be defined as an [Interaction Model (IM)] or/and a [Survey Model (SM)]. These two modelling activities depend on the same [EM] and should be performed in parallel to complement each other. However, for certain types of evaluations, it is not necessary to develop both models. For instance, when performing a heuristic evaluation, a checklist implemented as an [SM] can be sufficient. When the [EM] is ready, we can proceed with the 'Evaluation execution' in which Domain Users are included as subjects, while the Language Engineers and Domain Experts help in execution. The next step is to analyse the stored results of the test models and to create the [Report Model (RM)], that recommends a [GM] extensions and calculates a success factor of the evaluated usability goal. Finally, it is up to all DSL stakeholders to decide to continue to 'new evaluation cycle' or finalise the assessment period. Ideally, this decision will eventually indicate the end of the development cycle.

Utility

In this section, we introduce the Utility package, which contains artefacts that are reused from the existing development process of DSL. It includes the following concepts (see Figure 5):

-DSL -represents a language artefact, which can have associated to it an Abstract Syntax and a Concrete Syntax. This can be seen as a reference object to DSL under development and its progressive design implementations.

-Existing GM -goal model is a standard development artefact in MDD. If the DSL is evolving from the previous state, or usability analysis is performed in later phases of development cycle like implementation or testing, we already could have an existing GM from which we should reuse the knowledge. We will not focus during this analysis on Functional and non-functional goals and requirements. They are seen as a part of an existing goal model. Instead, we are addressing usability goals and requirements which are often dependent on the satisfaction of existing ones.

-Profile Template -is a classification artefact for a user profile. It is used for categorization of user profiles and specifying their features as Logical Expression (e.g. regex, ocl expression, boolean). These expressions contain a list of concrete (e.g. 'age'>7) or abstract (e.g. 'age'=int) specifications. Often we may find sources which can be used to import these values which describe potential users, for example, client human resources. -CEVariable -is a variable describing the environment of the language under development. Their elements are parts of the architectural design (e.g. feature diagrams), or the specifications of language supporting equipment and dependent tools (e.g. sensors, operating systems, interaction equipment).

-Process Model -is an artefact which refers to business process models designed during DSL development. Additionally, specifies the experiment processes designed as a part of this approach.

-Survey Engine -represents an artefact which is connected to existing survey platform (e.g. Google Forms, Survey Monkey, etc.).

-Priority Value -represents predefined priority values, which are set to be 3-scaled with values [High], [Medium] and [Low].

Context Modelling

As pointed in the previous chapter, the evaluations are context dependent. In consequence, the DSL's intended Context of Use should be specified when answering the following questions:

1. Who will use the DSL? 2. Where will the DSL be used? 3. How is the DSL expected to be used?

We argue that it is sufficient to describe the Context Model (CM) with the following concepts (see Figure 6):

-User Profile -helps us to define who will use the DSL. The user modelling activity [START_REF] Kobsa | Generic user modeling systems[END_REF] customises and adapts the language to the user's specific needs. Each profile can be instantiated as a subcategory of the main stakeholders during the DSL evaluation, namely {Language Engineer}, {Domain Expert}, {Domain User} and {Expert Evaluator}. Also, it stores the «priority» regarding the current evaluation needs (in the ongoing development cycle) expressed as an enumerated <Priority Value>. Any additional [User Profile] is justified by a «classifier», presenting any <Logical Expression>, which justifies new «subProfiles». Usually, during this classification, we categorise new profiles by particular «parent» characteristics into at least two distinct sets.

-User Hierarchy -is the prioritised categorization of the [User Profile] presented by the diagram in which each «subProfile» inherits the properties of its «parent». These properties are documented using <Profile Templates>, and they describe characteristics such as the expected background information (e.g. demographic data, education, special needs/disabilities) and relevant experience with computing and domain activities (e.g. expected knowledge sets, ontology). The [User Hierarchy] represents the user-centered meta-knowledge which categorises profiles and identifies shared semantics. -Context Environment -describes where the DSL is to be used. Namely, it can be defined as: -Technical Environment -specifies the information about the user's system usage. In other words, software, hardware and network environment that describe the users': i) working equipment (e.g. interacting device specification); ii) DSL operating equipment (e.g. storage, calculation libraries); iii) operation systems; iv) supported platforms; v) frameworks; vi) dependent software tools; vii) and, technical usage conditions (such as display capabilities, connection bandwidth, etc.).

-Social Environment -expresses the relation of the DSL to the users' working environment concerning the social context i.e. situational environment [START_REF] Halliday | Language as social semiotic[END_REF]. The referred situations are used to model a conceptual framework for representing a given the social context of the semiotic environment in which the users exchange meaning. This model recognises the fact that technology is not developed in isolation but as a part of the wider organisational environment.

-Physical Environment -describes the working equipment and organisation of the physical environment in which the user interacts with the system, as well as the models of the physical systems and their natural environment that are being affected by the use of the DSL.

The specification of the technical, social or physical elements is stored as a «cEElement» which is represented as an environmental variable <CEVariable>. The definition of the [Context Environment] instances can be supported by the integration of existing requirement engineering approaches that support traceability of the environmental variables during the software development [START_REF] Lempia | Requirements engineering management handbook[END_REF]. -Workflow -describes how the DSL is to be used by documenting prioritised user workflows, which reflect a group of tasks relevant for specific «userProfiles» or environment elements i.e, «cElements». The [Workflow] can be defined by using the existing tools for modelling processes (e.g. BPMN [START_REF] Allweyer | BPMN 2.0: introduction to the standard for business process modeling[END_REF], UML diagrams [START_REF] Fowler | UML distilled: a brief guide to the standard object modeling language[END_REF], or by user requirements notation ITU standard [START_REF] Amyot | Towards advanced goal model analysis with jUCMNav[END_REF]). These models are referred by «process» attribute, which reflects <ProcessModel> -Scenario -represents a concrete task, i.e. use case, that produce the possible paths and outcomes. Each [Scenario] is describing the user interaction activities, executed by the specific [User Profile] or «cEElement» from [Context Environment]. The [Scenario] can be further decomposed in a more basic functional actions inside of the system that can be connected to a DSLs domain model, preferably to its concrete or abstract syntax features.

The Context Modelling activity, specified by the diagram in Figure 7, engages all stakeholders included in the development. It starts with 'User Hierarchy prioritising', for which initial [User Hierarchy] is represented by DSL stakeholders, if not specified differently. This prioritisation helps stakeholders to decide if 'the usability evaluation is necessary?', and also to indicate from which stakeholder's perspective. Usually, the high priority for the End User profile justifies the investment in reactive experimental approach during the evaluation. Furthermore, it is necessary to perform 'User Profile classification' during which the relevant «classifiers» are identified, resulting a new [User Profiles] in the hierarchy. The parallel activity to this user identification is a 'Context Environment definition', during which the physical, social and technical environmental elements, i.e. «cEElements», are specified. Finally, after knowing who will use the DSL and where it is going to be used, the expert evaluator can describe why the DSL will be utilised by [Workflows] created during the 'Workflow definition'. It is likely that the evaluation expert will identify at this point missing context element specifications, or the need for a new [User Profile] classification. In this case, when the process reaches the decision point 'Need to extend CM?' it is possible to return and extend associated models. Finally, when there are no new insights after the Workflow specification, the Expert Evaluator is ready to finalise this activity.

Goal Modelling

The Goal Model (GM) specifies objectives that a user may have while using the DSL. This model describes 'why is the new language being developed?', and this makes it a central part of the USE-ME framework through which we are expected to model context dependent goals and trace the success of the DSL under development (see Figure 8).

Goals capture, at different levels of abstraction, the various objectives the system under consideration should achieve [START_REF] Van Lamsweerde | Requirements engineering in the year 00: a research perspective[END_REF]. A goal model is a well-known element of requirements engineering that is also widely used in business analysis. They have been used in SLE to model non-functional requirements [START_REF] Chung | Non-functional requirements in software engineering[END_REF] and early requirements for software systems. There are already several approaches for goal modelling; namely, KAOS [START_REF] Van Lamsweerde | Goal-oriented requirements engineering: A guided tour[END_REF], i* [START_REF] Yu | Towards modelling and reasoning support for early-phase requirements engineering[END_REF] and Tropos method [START_REF] Giorgini | Goal-oriented requirements analysis and reasoning in the tropos methodology[END_REF]. These approaches already support the core concepts of goal modelling, i.e., goal hierarchy and quantitative and qualitative relations. However, they should be specialised and, in some way extended to serve our research objectives. Usability is found in these approaches as a non-functional requirement or a soft goal. In our approach usability is meant to be highest level objective (i.e. goal) for developed DSL. The [GM] of USE-ME can represent extensions to <Existing GM> of the language, or can be built from scratch. It is described by Usability Goal using a GOMS (Goal, Operators, Methods, Selection) [START_REF] Dix | Human computer interaction[END_REF] and/or GQM (Goal, Question, Metric) analysis [START_REF] Van Solingen | Goal question metric (GQM) approach[END_REF] -Scope -that is described by the instance of [CM] for which [Usability Goal] applies. By default, each goal of [GM] applies for the complete [CM], if it is not specified differently (e.g. specific <User Profile>, Workflow> or Context Environment>). The priority level of [Usability Goal] can be inherited from the [Scope] to which it is related to.

-Method -defines the measurable requirements (i.e. Usability Requirements) that contribute to the achievement of the goal. It consist «testCase»s taken as individual <Scenario>s from [Scope]). These «testCase»s can be used to evaluate the requirement. A [Method] is often dependent on the development stage of a DSL and the context of the planned evaluation. For instance, during early evaluations without a functional prototype, we can evaluate the readability and understandability of the design; when assessing early ideas, the focus can be to evaluate the feasibility of the language construction or usage process, and finally when having functional prototypes we can perform experiments with using a DSL. A [Method] is associated with «functionalGoal» that should be tested by Language Engineer. The <Functional Goal> represents the functionalities that are to be provided to support the execution of a «testCase».

Success Coverage -reflects the evaluated context coverage and can be represented by the percentage of the [CM] (i.e. [Scope]) to which each success factor apply. As we are evaluating usability, we find that the metric representing the score for the evaluated scope can also rate on the scale -1 to 1, where the (1) indicates that measured experience was positive, while (-1) indicates a negative experience while using the given DSL. Further, the representation of success can be represented by the use of Kiviat diagrams [START_REF] Barišić | Quality in Use of DSLs: Current Evaluation Methods[END_REF] reflecting different requirements that were taken into consideration, or by single project dependent indicator predefined by stakeholder [START_REF] Vallecillo | Expressing Measurement Uncertainty in Software Models[END_REF]. The Goal Modelling activity, specified by the diagram in Figure 9, starts with identifying if there is an 'Existing [GM]?'. In case there is a [GM], previously created within USE-ME or another context, the Expert Evaluator performs '[GM refactoring]' regarding the evaluation Priority and a structure and identifies if there is a need to 'Change or introduce a new [Usability Goal]'. Further, the [Usability Goal] is changed/introduced during 'Goal specification' activity during which Expert Evaluator consults Usability Catalogue (Section 5.7.). In parallel, a [Scope] is associated with the goals during 'Context selection' and an [Actor] during 'Responsible actor selection'. Next, it is necessary to verify if the 'Single [Actor] is responsible?', meaning that the goal is decomposed into a «subGoals» for which only one [Actor] is «responsibleFor», and by this making it ready for evaluation. This is followed by 'Functional Goal association' during which all the functional prerequisites that need to be verified for evaluation are provided by the Language Engineer and associated with [Method] justifying [Usability Goal] evaluation. In parallel, the Expert Evaluator defines an evaluation [Method] during 'Measurable method specification', which aggregates [Usability Requirements] and «testCases». This activity requires consultation of the Usability Catalogue, to reuse the existing metrics if possible. Finally, if the '[Usability Goal] is evaluated', then it is feasible to perform a 'Success Coverage calculation' that indicates the scope for which the goal was evaluated, as well as the evaluation results.

Evaluation Modelling

Although DSLs' development process is not the same as the one of the UIs, typically DSLs have an explicit underlying model (thanks to meta-models or grammars), while UIs models are usually implicit in their implementation.

In general, there is no distinction between DSLs and UIs from the end users point of view, so their evaluation should essentially validate human-computer interaction (HCI) [START_REF] Barišić | Quality in use of domain-specific languages: a case study[END_REF].

Therefore, we can reuse the common techniques used for UI usability evaluation; e.g. UCA (Usability Context analysis) [START_REF] Bevan | Quality and usability: a new framework[END_REF], MUSiC (Metrics for Usability Standards in Computing) [START_REF] Binucci | Software quality of use: Evaluation by MUSiC[END_REF] and MAGICA [START_REF] Alva | Comparison of Methods and Existing Tools for the Measurement of Usability in the Web[END_REF] methods and tools. UCA ensures that the user-based evaluation produces valid results, by specifying how important factors are to be handled in the assessment. MUSiC and MAGICA provide modules that can be used for measuring user satisfaction, user performance, cognitive workload, task completion time and analytic measurement.

The evaluation modelling activity is expected to support the application of techniques mentioned above that are represented by the Evaluation Model [EM] (see Figure 10). [EM] expresses the purpose of evaluating a certain objective (an instance of [GM]) for a DSL in the particular context (an instance of [CM]). Therefore, the prerequisites for the evaluation modelling are to have a [GM] and [CM] for a DSL under evaluation. This activity is supported by modelling of:

-Evaluation Goal -defines the experimental «hypothesis» and «researchQuestions». It is related to «goal»s specified in [GM] and inherits its <Methods> which can be introduced as «measurements».

-Language of experimental study -is a <DSL> under evaluation. The experimental modelling is supporting more than one [Language] for a case of comparative evaluations (e.g. with the baseline that can be an alternative system or previous DSL version). -Test Model -describes the usability testing activities that are not learning treatments, i.e. questionnaires, interviews, and observations. The creation and execution of these models are supported by USE-ME sub-activities of survey modelling and interaction modelling, described in the following sections.

-Process -defines the concrete design for evaluation by modelling the activities that should be performed with specific [User Profile] that is described by the When preparing an evaluation (see Figure 11), the evaluation expert performs an 'Evaluation language selection' where the DSL under development is chosen to be an evaluation object. Next, he defines the experimental objective and participants during 'Evaluation Goal definition' and 'Participant selection' activities. He also decides if he will perform a 'Comparative evaluation?' and, if so, which another language he will use ('Baseline selection').

. Interaction Modelling

The [Test models] that are defined as Interaction model [IM] (see Figure 12) encapsulate summative methods for measuring usability over concrete tasks that involve interaction with at least one [Language] (i.e. DSL under evaluation or its alternative). The [IM] supports capturing of the predefined events and providing statistics about their occurrences. It is described by:

-Interaction Syntax -reflects the interaction elements from the version of the [Language] of experiment study (for instance DSLs abstract and/or concrete syntax model, or feature model).

-Task -«useCase» taken from the «scope» of [Evaluation Context]. It is documented in [Documentation] and represents a concrete task for which the interaction will be analysed. -Event -accounts for the type of data («subEvents») that will be captured from different interaction devices. It describes how it will be recorded and can refer to single events (e.g. eye movement, mouse click, biosignal, gesture), or to the particular sequence of interaction and/or the sequence of reactions (themselves or as a consequence of interaction sequence). Also, events can be associated with the «requirement».

-Interaction Result -includes the statistical analysis and results of the executed interaction model, where participants use the [Language] of experiment study to perform a [Task].

Interaction Modelling (see Figure 13) starts with 'Interaction Task definition', that is interdependent on 'Interaction Syntax analysis', as the task is to be solved by the use of the analysed syntax, following the

. Survey Modelling

The survey methodology is a field of applied statistics that studies the sampling of individual units from a population and the associated survey data collection techniques, such as questionnaire construction and methods for improving the number and accuracy of the response to the inquiry. A survey is not just the instrument (the questionnaire or checklist) for gathering information. It is a comprehensive system for collecting information to describe, compare or explain knowledge, attitudes, and behaviour [START_REF] Kitchenham | Personal opinion surveys[END_REF].

In the case of USE-ME, the Survey Modelling activity supports formative methods for measuring usability. The Survey Model [SM] (see Figure 14) can correlate to any existing [Survey Engine] that automates response collection (e.g. Google Forms, Survey Monkey, mySurveyLab, etc.). It is described by the following concepts: -Questionnaire -defines a particular set of Questions (inquiries) to the survey part that can be provided in different forms; on-line, by phone or personal interview, pen and paper, and in advanced interaction environment (a testing environment that supports additional interaction equipment that can capture eye movements, gesture, biosignals). Generally, [Question] has an associated concrete «scale», represented as a list of String values. It can also have a defined «indicator» that helps to get fine-grained variables that can help during the results analysis. The [Question] can be defined as:

-Background Qs -designed to collect the information about the participant (e.g. demographic data, education, special needs/disabilities). Each question is related to at least one <Logical Expression of participant's <User Profile>.

-Feedback Qs -collects the opinions and reactions about what is being tested i.e. the DSL, its baseline or alternative. In our case it would be expected to support existing appropriate methods such as inspections (usability heuristics [START_REF] Nielsen | Heuristic evaluation of user interfaces[END_REF], quality requirements for DSLs [START_REF] Kolovos | Requirements for domain-specific languages[END_REF], Framework for Qualitative assessment of DSL [START_REF] Kahraman | A framework for qualitative assessment of domain-specific languages[END_REF]) and notation assessments (Cognitive dimensions of notations framework [START_REF] Blackwell | Notational systems-the cognitive dimensions of notations framework[END_REF], Physics of Notations [START_REF] Moody | Evaluating the Visual Syntax of UML: An Analysis of the Cognitive Effectiveness of the UML Family of Diagrams[END_REF]). Each question, or a checkpoint, can refer to concrete «useCase» and/or «requirement».

-Survey Result -includes the statistical analysis and results of a survey, that can be generated automatically if <Survey Engine> was used, and further customised (e.g. merged results from different questionnaires, formatted, statistically analysed, etc.).

The creation of [SM] (see Figure 15) starts with asking if 'New questions?' are needed to be defined for the survey. In the case they are needed, the evaluation expert decides if the questions to be defined are '[Background]', leading to 'Background question definition', or '[Feedback]', leading to 'Feedback question definition'. When there are no 'New questions?', the expert evaluator is performing 'Survey participant assessment' where the experiment

. Report Modelling

The report modelling activity helps on the construction of final reports for experimental assessment specified by the [EM] and encapsulate the results and improvement suggestions into the Report Model (RM) (see Figure 16). It consists of: ). Based on these results, the expert evaluator performs a 'Recommendation specification', by designing a [RecommendGM]. At the same time, the evaluator can calculate a [Success Coverage] for the recommended [GM], which helps in making decisions how to redesign goals. Finally, when recommendation is ready if the plan is to enter 'New evaluation cycle?', the expert evaluator 'Run Goal Coverage Engine' which validate that all rules are preserved while integrating a recommended [GM] with the initial one. Finally, during 'Goal modelling update' recommendations are accepted or rejected.

Catalogue of Usability Metrics

This catalogue is seen as a structured knowledge base about the DSLs usability evaluations. It has the purpose to help during two crucial activities of the USE-ME framework:

• Goal modelling, where it is used to find existing specifications of the usability goals and requirements. These specifications can be based on standards [START_REF]2011 Systems and software engineering -Systems and software Quality Requirements and Evaluation (SQuaRE) -System and software quality models[END_REF], or existing frameworks which address the evaluations in general [START_REF] Green | Usability analysis of visual programming environments: a cognitive dimensions framework[END_REF][START_REF] Moody | Evaluating the Visual Syntax of UML: An Analysis of the Cognitive Effectiveness of the UML Family of Diagrams[END_REF][START_REF] Kahraman | A framework for qualitative assessment of domain-specific languages[END_REF]). On the other hand, they can provide examples of which were reported on existing DSL evaluations.

• Evaluation modelling, where it is expected to support the choice of treatments for evaluation process activities based on a diversity of goals and the number of available participants, technology, etc. Further, it is meant to register the instantiation of quality in use metrics [START_REF]2016, Systems and software engineering -Systems and software quality requirements and evaluation (SQuaRE) -Measurement of quality in use[END_REF] for selected evaluation objectives and enhance a metric reuse and improvement.

To obtain the first structure of this knowledge base, we are performing an extensive Systematic Literature Review (SLR) whose protocol can be found in [START_REF] Barišić | Domain-Specific Language domain analysis and evaluation: a systematic literature review[END_REF]. The SLR is extended from previously performed work of Gabriel [START_REF] Gabriel | Do Software Languages Engineers Evaluate their Languages?[END_REF]. The selected publications should report on the human-machine DSLs (excluding the machine-machine languages). The SLR should report on the involvement of domain users in the DSL development process and the evaluation of DSLs usability. The goal is to identify domain analysis and/or evaluation techniques for developed DSLs. The next step is to summarise the state-of-the-art research trends, as well as to categorise the proposed approaches, techniques, tools and methods for domain analysis and evaluation phases. We are concerned about how selected reports identify the DSL objectives, and how they are evaluated.

Goal Coverage Engine

This engine should provide version support of the USE-ME project models and support their updates by using model merge approaches (see Section 3.3.3), while checking the predefined rules. The Goal Coverage Engine supports all DSL stakeholders to trace different states of models for different versions of the DSL or their assessments, as well as a knowledge base. For each new iteration cycle of the DSL development, the stakeholders need to confirm that the context and goals are still the same, or update them if they have changed. This engine should also check the validity of specific rules for removing/merging/updating USE-ME models. Finally, this engine can be seen as a transformation engine that performs the updates of GMs based on the recommendations of the Report Model and finds the scope coverage for which the goals are validated based on a context instance (see Figure 18).

USE-ME Feasibility Study (Implementation Evaluation)

In a previous section, we described the implementation of our approach, for which we present a feasibility study in this section. First, we present implementation architecture which we used for prototype implementation. Further, we illustrate an instantiation of prototype models on an industrial case study. Finally, we perform a pilot empirical evaluation of the implemented tool on four DSL development projects. We have shown that it is feasible to capture all information which is relevant for the evaluation and its use in the result analysis.

Implementation architecture

The USE-ME prototype [START_REF] Barišić | Usability Software Engineering -Modeling Environment (USE-ME 1.1)[END_REF] was developed as specialization of conceptual framework (see Figure 19). The USE-ME conceptual framework was formally specified on Cameo Systems Modeler 12 , a cross-platform collaborative model-based systems engineering environment. This platform enabled us to produce Unified Modeling Language (UML) 13 compliant models and diagrams. Namely, we presented the main concepts as class diagrams and a process as activity diagrams. This diagrams served as a general specification of abstract syntax for the USE-ME approach. They were reviewed by a research group of NOVA-LINCS during a presentation session and trough individual questionnaires. The USE-ME prototype 14 was developed using Eclipse Modeling Framework (EMF) 15 , which is an Eclipse-based modelling framework for building tools and other applications based on a structured data model. From an XMI model specification, EMF provides tools and runtime support to produce a set of Java classes for the model. The EMF framework includes a meta model (Ecore) for describing models and runtime support for the models. The class diagram specified in Cameo System Modeler was transformed to an Ecore model. Due to constraints in the target meta-modelling tool, we had to adapt the model given in pure UML in order not to lose information from the original contents and to address restrictions provided by Ecore (e.g. necessity of containment relationships).

Further, we used Sirius 16 , a platform for developing and using graphical model editors, which is also based on the Eclipse Platform, and in particular the modelling stack based on EMF. The Sirius platform is domain-agnostic, in that it can be used by modellers for any business domain as long as they can describe it using EMF. In our prototype, we used Sirius to declare the visual representation of models instantiated in Ecore. The USE-ME architecture as described in this document supports modellers to design the USE-ME instances in an EMF generated editor with Ecore tooling. It is also possible to redefine and preview the implemented representations by Sirius.

Visualino case study

We dedicate this Section to illustrate the USE-ME approach with a case study about a free web-based programming language, named Visualino (see Section 3.3.2), for rover-like robots. The following description refers to the design of 12 empirical study conducted during the second development iteration of Visualino 17 , where the USE-ME approach was applied systematically.

During the description we use following symbols;

-[] -instantiation of the concept i.e. instance object; -«» -property of the instance object; -{} -property value of the instance object;

Context Model Instantiation

The Context modelling starts with prioritising the initial user hierarchy, which is represented by the DSL's stakeholders. Therefore, we are having a [DSL Stakeholder] as a 'root' element of the hierarchy, and its subProfiles defined as [Domain Expert], [End User], [Expert Evaluator] and [Language Engineer] (see Figure 20).

For the case of Visualino, the target users are children, which usually are not experienced with programming. As such, the usability evaluation of the language with its end users is highly important. We set up the priority of its [End User] to be {High}. Having, the lower priority value associated with other stakeholders indicates that the investment in the usability evaluation of these profiles is not as important during the current development cycle. However, as the language develops further, the investment into the evaluation with other user profiles may become more important. For instance, the development iteration may focus on the language extension that supports the [Domain Expert] to specify the environment configurations for different robots. Then, the priority for the [Domain Expert] profile will be updated accordingly. In this case, the priority of the [End User] should stay the same. Setting up a 'lower' priority is reasonable only if the initial purpose of the language has changed. For example, this may occur if the language 'fails' to be adopted by the initial audience, and the opportunity for further development presented itself in a different context.

After the initial prioritisation, we classify user profiles and define profile templates (see Figure 21). Profile templates are categorised as a {Background Demographics} and {Background Experience}. They are captured with logical expressions. These expressions reflect profile characteristics and their values, concrete or as measurable scales. For instance, the expression «language» indicates that [End User] is expected to speak {Portuguese} or {English}. On the other hand, «programming» is a characteristic that can be measured by {ordinalscale(experience)} which can be later specified with concrete scales.

Logical expressions can be used further as classifiers. For instance, an expression «age» is defined as a condition {age > 7} for [End User] profile. When creating the 'child' profiles, we use this expression as a classifier, meaning it will be restricted in two or more distinct sets (e.g. {age = 7-19}) for [Child] and {age > 19}) for [Adult]). It further specialises a [Child] into [Kid] and [Teen] profiles. Each subProfile inherits profile templates and logical expressions that are assigned to their parents. This kind of structural analysis of domain users for a DSL answers to the question 'Who will use the DSL?'. The next step is to respond the question 'Where will the DSL be used?' by specifying the context environment.

The context environment is described by environmental elements (i.e. CEVariable) such as the social, physical and technical environment (see Figure 22). These elements can be reused from architectural descriptions, feature diagrams or other specification files of the language. For each environment element, it is necessary to specify if it is {Mandatory} or {Optional}. Further, it is possible to define contained environment elements and specify their types as a list of values that can be prioritised. The answer to the question 'How is the DSL expected to be used?' can build on scenario-based approaches, such as use case descriptions, which define scenarios and workflows. (see Figure 23). In the case of Visualino, use case specifications are designed with SysUML language. These specifications are referred in the «Process Model» instance. The actors who make part of use case description are represented by different user profiles (users) or environment elements (other systems) that initialise a use case.

A workflow [W1] poses a scenario in which the {End User} (specified as an actor) wants to program a behaviour of a robot and, eventually, execute that behaviour on a physical {Robot} defined in the context environment. In most of the cases, the priority of each workflow can be easily inherited based on the involved user profiles priorities. Following that rule, this case is has a {High} priority. In the workflow [W2] the {Domain Expert} wants to configure the language environment, which inherits the {Medium} priority. Finally, the workflow [W3] represents the case of a {Language Engineer} who wants to create a new language component or change or remove the existing one, in this instance, inheriting the {low} priority.

Several scenarios are associated with a workflow [W1] (see Figure 24). The first scenario is to program the robot to move forward and then move back. The second scenario is to program the robot to move along a path similar to a '5'. This scenario includes the following sequence of instructions: move forward, first turn left, second turn left, first turn right, second turn right and stop. In each turn, the robot needs to execute the move operation using the same amount of time and then to make a 90 o angle turn. The third scenario is to program a robot to move forward until it bumps into some object, then it would move back and stop. The fourth scenario aggregates the sequences from the previous scenarios. It describes how to program the robot to make a shape of '5', as in the second exercise, but the robot will only turn when it hits the bumper.

Goal Model Instantiation

In this section, we show how the collected knowledge from the context model can be used in goal analysis (see Figure 25). We start with an empty model, as there is no existing goal model from the previous development iteration of Visualino. The 'root' goal represents the highest objective of our analysis, that is to achieve [Quality in Use]. It is prioritised as high, indicating that usability evaluation is highly necessary for this development project. Its «scope» is set to be applicable on {all} CM, designed in the previous section. The «actor» responsible for achievement of the highest usability goal reflects all stakeholders included in the development. The {Children robotics expert} and {Visualino development} represent the domain experts and language engineers from Artica, while {Language Evaluator} represents the authors that were included as expert evaluators. 23. The «scope» objects, associated with these goals, restrict a CM in a way that they reflect parts for which each workflow apples. They are only associated to a sub-branch of the user hierarchy model that consider a user profile of the workflow's actor. A goal [UG1] is given the high «priority» as its «scope» reflects the {End User} profile and {Workflow1} workflow. As it is suggested by goal modelling approaches, such as Kaos [START_REF] Van Lamsweerde | Goal-oriented requirements engineering: A guided tour[END_REF], we further divide this goal into the subgoal [U1] for which the evaluation the responsible is just one «actor», {Language evaluator}.

A usability goal [U1] specifies that the «actor» {Language evaluator} evaluates the [Usability to program a robot] and represents a quality goal usually measured by non-functional requirements (see Figure 26). It answers the «question» {Is it usable for an [End User] to program a robot?}. Further, a measurable method is specified as [Programming a <Use Case> is usable] and is related to particular usability requirements. This method is related to a functional goal [F1]. A functional goal specifies that the {Visualino development} verifies that it is possible to program a robot. It answers the «question» {Which scenarios are verified to be programmable using Visualino?} by testing requirements which describe the necessary functionalities to execute the selected «Test case», {Workflow1}. Further, usability requirements are specified in a way they can be measured in the current phase of development. In the case of Visualino, we focus on the evaluation activity which was planned to be executed after the implementation. In this phase, the following measurable requirements are found to impact the goal [U1]: [Effectiveness], measured by a {Correctness of programmed <Use Case>.}; [Satisfaction], measured by {Satisfaction questions related to <Use Case>.}; [Efficiency], measured by {Time to program the <Use Case>.}; and, [Learnability], measured by {Success to program the learned Use Case.}. Note that other measures could be appropriate in different development stages: for the design phase without working prototype, readability and understandability [START_REF] Barišić | Introducing Usability Concerns Early in the DSL Development Cycle : FlowSL Experience Report[END_REF], or for a proof of concept, feasibility and integrability. The catalogue of usability metrics is expected to support this choice and document the metrics from existing experiences.

Evaluation Model Instantiation

As mentioned previously, language usability can be promoted by combining usability engineering techniques with empirical software engineering. In this section, we present an evaluation model for the empirical study of our target DSL, Visualino, which is specified based on its [CM] and [GM]. The first thing to do is to model the evaluation objectives (see Figure 27). The primary language of the presented study is a [Visualino]. It was found useful to compare its early prototype to other widely used language for programming robots, namely [Lego], representing a second language in [EM]. The participants were expected to match the {Teen} «profile», as the experiment was performed with secondary school subjects during the ExpoFCT event at Universidade Nova de Lisboa in Portugal. The goal was to evaluate the «usability goal» {U1 -Usability of programming the robot}, specified by GM. Namely, each evaluation goal was to validate «usability requirement»: first addressing the {Effectiveness}, and second by {Satisfaction}. For each, we have specified the research question in the form of a «problem» using the GQM template, from which we have derived the «hypothesis».

We analysed the Lego context by giving attention to the workflows and environment that are comparable to the Visualino's, and the ones that are in the scope of the «usability goal» which we are evaluating. During this analysis, it was possible to identify the context in which the evaluation study was appropriate to be performed, and it is described by evaluation context (see Figure 28). The evaluation context is defined by: «user profile» of [ExpoFCTParticipant], which is {Teen}; the «context environment» that represents where the experiment will take place; and, by the «workflow» that will be used. For instance, for the social environment, the «country» was set to {Portugal}, and the «workPlace» was selected to be a {Classroom}, while the «purpose» was chosen to be a {Competition} to create a motivating environment for the participants. The technical environment was instantiated by «OS» {Windows 7} and the «browser» {Google Chrome}. The physical environment details the information about the «computers», «interaction devices» and «robots» that will be used. The preferred «configuration» for both robots (Lego and Farrusco) is specified, to assure that the robots will have the same functionality. We can note how the environmental elements of Visualino's CM are initialized to concrete values, which are saved to value lists associated with this objects. Finally, the observed <workflow> is the {Workflow1}, which includes all scenarios defined previously, as they are executable in this specific context. During the execution of the experiment, it was decided to use a 'between groups' design where participants were randomly assigned to either programming a robot using [Visualino] or [Lego], but not both. The evaluation process [emVisualinoProcess] was designed to start with a 30 minutes learning session, during which the participants should learn the language's concepts and how to solve three basic exercises that reflect the first three scenarios specified in {Workflow1}. This three activities and the tool help were prepared as printable documents, presentations and video demos with the version of the language under evaluation. The materials were saved as documentation objects. Further, it is necessary to define a «test model» through survey modelling for {Background Questionnaire}, which was filled in during the evaluation session. The evaluation continued with 15 minutes of a competition session during which the participants tried to solve a programming {Challenge} reflecting the fourth scenario, which was aggregating the sequences from the previous scenarios. The «test model» for this session was specified with the interaction model, as we wanted to capture relevant events by recording the contents of the computer screen during the session. Finally, there was a feedback session, taking up to 5 minutes, to collect the children's subjective opinions about using the language they were assigned to, by answering to the {Satisfaction Questionnaire}, which was modelled by the survey modelling activity, but dependent on the specification of the interaction model.

While preparing this evaluation, from the teaching materials and the events analysis, we were also creating the documentation of Visualino and its application scenarios that can be shipped along with the software product, as they were reviewed and improved for the purposes of the experiment. This material, referring to a specific scenario can be documented within the CM. Further, we illustrate how the test models are designed using the interaction modelling and the survey modelling activities.

Interaction Model Instantiation

In this section, we instantiate the interaction test model (see Figure 29), which is used during the competition session of evaluation. This model encapsulates the «interaction syntax» from both, Visualino and Lego. Further, it is specified for the «task» which is associated with the concrete scenario from the evaluation context, named {Challenge}. A correct solution of the problem was provided by the Artica developers for Visualino, and by a language engineer who had experience with Lego.

By analysing the given task and the evaluation model, three events are defined to be captured. To measure «usability requirement» {Effectiveness}, described as correctness of solving <Use Case:Challenge>, [Event1] and [Event3] are specified. [Event1] captures Success (S) or Fail (F) of modelling the following concepts: Bumper, First Turn Left, Second Turn Left, First Turn Right, and Second Turn Right. It is captured manually observing {Screen Record}, e.g. videos of the participant's interaction with the language while trying to provide a correct solution. Further, [Event3] was marked with Success (S) if the robot successfully performed the challenge in the arena; Fail (F) if the team tried until the time limit, but did not succeed to program the robot correctly; and Quit (Q), if the team gave up. Finally, in the [Event3], we assessed additional useful information during the video analysis, like if the team: (i) saved or reused the previous exercises; (ii) experienced technical problems or functional errors; (iii) had interaction difficulties (e.g. using copy/paste for visual objects or connecting concepts in sequence); (iv) reused previously constructed sequences (within the same exercise); or (v) used any other additional language features (e.g. zooming). [Event3] registers the time of occurrence of certain <captureEvents>, measured from the beginning of the competition session and can serve as a source for ideas on improvement of certain language features for language engineers. The interaction results are analysed by the expert evaluator, who prepared the data collection sheets and has put forward the analysis. The correlation analysis was supported by SPSS tool [START_REF] Leech | SPSS for intermediate statistics: Use and interpretation[END_REF], and the graphs were generated in Excel.

Survey Model Instantiation

By performing survey modelling, we instantiated the test models (see Figure 31) for the background questionnaire used during the learning session, and for the feedback questionnaire used during the feedback session. The survey forms were composed of Smileyometers, which are found to be appropriate for children questionnaires [START_REF] Sim | Investigating children's opinions of games: Fun Toolkit vs. This or That[END_REF]. While answering to forms, children were assisted by an adult (one of the experiment assistants). This was done to ensure that there were no misinterpretations of questions and answers, and to confirm that participants did not experience reading problems. As participants were grouped into teams, the participants' individual answers to questionnaires were merged, and the mean rate was computed within each team, for each answer. The background questionnaire [BackgroundVisualino] is related with the {Teen} «profile». Each question in this questionnaire is related to one of the logical expressions associated with evaluated profile in CM. For instance, for [Q1:Age], the «logical expression» {age} was associated. In this case, the age is defined as an actual value ranging from 13-19. As so, the expected answer is defined as an {integer} ranging from 13 to 19. If another value occurs, the participant's data is discarded from further analysis. The collected data includes «indicators» defined as {Demographics}. These help to verify if there are other factors, such as age or gender, influencing the results. On the other hand, certain «indicators» like /Experience/ were calculated as a merged value of this group of questions to serve for further impact analysis. Also, the abstract scale, for instance of «logical expression» {Computer game} was instantiated as 3-point Likert scale { [START_REF] Mernik | When and How to Develop Domain-Specific Languages[END_REF]: Very often, [0.5] Often, [0] Not so often} with concrete weights which are used for later calculations. To evaluate the usability of {Visualino} and {Lego} we reused techniques of UI evaluation that imply the involvement of real users as subjects of controlled experiments. A comparison criterion was based on the correctness of the problem solution, the time to solve it and personal preference. To get correct interpretations of our results, it was mandatory to profile the users. The criteria that were observed were their age, gender, and programming background. Further, we collected the participant's feedback and success rate regarding their experience with a language. During the report modelling activity, we declared all of these results in a Report Model [expo2015result] (see Figure 31). The results specified by the interaction and survey models are documented for each event or questionnaire. They are correlated to evaluation results, whose objective was to analyse the {Effectiveness} and {Satisfaction} «requirements» for each language. The statistical analysis documents are assigned as «outsideRef» properties.

Result Model Instantiation

The observed evaluation results of the second iteration of the design of the DSL showed convergence and highlighted new possible improvements of Visualino. The children subjects were still having problems in making a right solution, having a small {Effectiveness} score of 0.37 for Visualino. The subjects were expressing likability toward Lego, while toward a Visualino they were indifferent. Based on these results, we created the recommended GM [Recommendations] consisting of new requirements impacting the usability goal for [U1] and functional goal [F1].

Pilot evaluation study

In this section, we report on the pilot assessment of the feasibility of the USE-ME tool with master students in computer science which were involved in a DSL course. In total, four groups were consisting of two or three participants which were developing the following DSLs: The evaluation sessions were prepared as shown in Figure 32. The first learning session took place after four weeks of the DSL development. Students were introduced to the usability evaluation during a 2h theoretical lecture. For the next two hours, the students received a tutorial on the USE-ME tool and were guided to perform installation and set up working environment. Also, the students were given a participation questionnaire to fill in and describe a purpose of their DSL. At the end of the session, they were given the background questionnaire to fill in. The following two weekly four-hour sessions consisted of USE-ME hands on labs. The students were introduced to the modelling activities followed by Visualino example. For each activity, the same student from the group was using the tool to create USE-ME models for their DSL, while other students from the group were helping in deciding what would be a correct specification. Finally, students were asked to try to finish the learned models and deliver them as a part of the DSL course. After delivery, the students who were using the tool to model were asked to fill in a feedback questionnaire.

The evaluation deliveries (project reports, USE-ME models), background and feedback questionnaire results and evaluation results can be found at [START_REF] Barišić | USE-ME Empirical evaluation pilot study[END_REF]. Here we shortly describe the obtained results:

The participants were master students with intermediate knowledge of modelling techniques, namely having a background knowledge of UML (class diagrams, use cases, activity diagrams and interaction diagrams). Also, participants knowledge related to the working environment was advanced. However, the participants had little or no knowledge regarding HCI, especially empirical experiments or the usability testing. As the objectives of the USE-ME framework are to support Language Engineers in specifying the usability evaluations, as the Expert Evaluators are often found to be too expensive to be included, we find that participants are adequate surrogates for the target end user of {Language Engineer} profile which is to be supported by USE-ME approach. 1 presents the results of the USE-ME model validation for each reported DSL. We have analysed all diagrams which should be provided for Context Modelling, Goal Modelling and Evaluation Modelling activities. The diagrams were graded regarding their completeness and correctness as follows: (0) -no delivered model, (0.2) -very low, (0.4)low , (0.6) -satisfactory, (0.8) -good, (1) -very good. We can note that all groups expect the Spreadsheet DSL manage at least satisfactory specify their models. However, Spreadsheet group participated only for a two hours of a hands-on session and this impacted the low score of their reports. In each case, we can observe that delivered models were satisfactory and by this indicating the understandability of the approach in specifying the usability evaluation within a small amount of time. However, it seems the biggest challenge for participants was to figure out how to specify usability goal model and associated requirements. In its current version, the prototype does not yet support the usability catalogue. We believe that this extension will help users without much knowledge about requirement engineering and quality evaluation to define properly usability objectives for their case.

The participants from the groups which were having a bit higher understanding of HCI were naturally selected to be responsible for modelling with the USE-ME framework. That is why just these participants were asked to provide a feedback about the tool. Participants authorised the publication of project results to Zenodo library. Although they found usability evaluations necessary for a DSL deployment in practice, they did not find the modelling activity interesting. One of the main reason was that the modelled evaluation was not to be executed, making it less interesting for their project purpose. The Gesture Kinect group found that it was easy to understand the USE-ME approach. The Peddy Paper group found it on another hand not to be so easy, pointing out there were too many steps to follow. The Smart House and Spreadsheets groups found approach more or less easy, pointing the lack of a guided cycle and highlighting a usefulness of the Visualino example for understanding an approach. All of them reported to be able to discover environmental elements which they did not consider before in development, and found easy to create a user hierarchy and more or less easy to specify other context model elements. However, they found the modelling of usability goals they found a bit harder but still manageable. Two groups found useful to reuse context model elements in goal specifications, or during the evaluation modelling. They found it to be easy to creating test model specifications for evaluation. In general, they did not feel very confident while using a USE-ME tool, however, they find a tool more or less expressive enough for purpose of specifying usability evaluation, and also suitable for another kind of software products. However, none of the participants is familiar with any other tool which supports usability evaluation.

Applicability of USE-ME approach

In this section, we discuss a correlation of the USE-ME process we proposed in Section 4 with a DSL development cycle presented in Section 2.1.2. them with the existing goal model. Further, during the DSL Design phase Goal Modelling should be concluded and the Evaluation Modelling phase can start. The evaluation is dependent on the scope of the DSL artefacts which are designed and are to be implemented in the current iteration. For instance, already early on, it is possible to define the objective of the study and specify its process and context or to discuss if the comparative evaluation should take place and which are alternatives to be considered. During the implementation phase, test models are created for the evaluation trough Survey Modelling and Interaction Modelling activities. Further, in the testing/evaluation phase, the evaluation is executed. However, often its execution can depend on the success of the tests. Usability goal measures can depend on the provided functionalities of the DSLs. If these functionalities are tested in this phase, the evaluation process should reflect the dependencies on the tests which should be performed before its execution. Finally, the Report Modelling activity can be performed and, if necessary, extended to the DSL deployment phase. Finally, the Recommendation Model is used to extend/change the previous Goal Model and to make a decision about the next development cycle.

Integration of USE-ME approach with DSL development phases

However, sometimes the complete USE-ME cycle can be applied during a single DSL development phase. For instance, during the Domain Analysis phase in which the requirements and objectives are not clear, we can model the survey which will help to clarify the objectives from the different stakeholders. In this case, the resulting goal or context model is formally justified. On the other hand, during the Design phase, we might want to experiment with different syntax designs, and it is useful to create an assessment to evaluate their readability and understandability. Further, during an implementation phase, the various prototypes can be implemented and evaluated in order to continue with final implementation. Finally, during the testing/evaluation phase, we might want to perform several evaluation executions which are interdependent, e.g. previous ones impacting the extension of the CM and GM.

Application of USE-ME to incremental iterative DSL development

The USE-ME framework reuses the specifications along different iterations so that it is not necessary to start again from scratch with the analysis and design in each iteration. When introducing small extensions or changes to the DSLs' syntax or semantics, it will be necessary to extend the existing USE-ME models with 'new' context instances (e.g. new/extended user type, environment or user story). The updated evaluation goals should take into consideration the new features and/or expected usability improvements over a previous version of the DSL. It is useful to perform the comparative evaluation with a previous version of the DSL, to observe if an improvement happened. For instance, in the case of Visualino (see Section 3.3.2), we reused the experimental design, evaluation process and their instruments (surveys and an interaction test model) from the previous iteration. This gave us means to comparatively analyse the results from the first and second iteration. To support the organisation and planning of the iterative development, and increase the transparency of the development tasks, we can benefit from existing management tools support used for agile approaches (for instance we applied Scrum and Pivotal Tracker during the FlowSL case study (see Section 3.3.1).

To trace changes in a DSL, we can benefit from existing incremental language development approaches such as LISA [START_REF] Mernik | Incremental programming language development[END_REF]. In this work, when the language is extended with new features, this corresponds to a new language containing specifications of the change together with the description of the previous language. For example, Mernik et.al [START_REF] Mernik | Incremental programming language development[END_REF] extend (in the sense of object-oriented extension) a simple language describing a robot movement with a new language which also calculates when the robot will reach the final position. For performing this extension, there should be a concrete motivation behind. For instance, in this case, new scenarios should be added to the previous workflow in a Context Model. This change does not imply the addition of the new Usability goal, but rather an extension of the existing ones with a new scenario. The evaluation design can be kept and applied to a refined scenario. On another case, also taken from [START_REF] Mernik | Incremental programming language development[END_REF], the authors perform an extension which supports the robot for cleaning. This change refines the previous end user profile (the user wanted 'to use a robot'), to a new profile where the end user wants 'to use a robot for cleaning'. Also, the environment context is specified more in depth reflecting the robots for cleaning and environment where they are used. Finally, the new user stories may have different actors and will be documented under the new workflow. The evaluation should redefine the usability goals, and probably create new ones which take into consideration the new context.

Early evaluations and extensions without a significant change of context or usability goals, can be performed with domain experts, while other users should be involved in evaluations later on. By performing early assessments with more available users the evaluation design and its metrics are being validated, and a risk of not obtaining a return of the investment in extensive evaluations is lowered. Also, as mentioned previously, bigger investment into usability evaluations should be applied to the DSLs which target a wide scope of the end users, especially those who are not exactly reflected by the domain experts profile which is included in the development. For the 'in house', or small DSLs developed for a very small set of users, especially those included in its development process, an application of this approach as a whole might be too expensive, but the analysis procedure can still be found useful. We applied the USE-ME approach on two industrial DSLs. In both case studies, we were not directly involved in the development of the DSLs but participated as evaluation experts. These DSLs were developed from scratch: an internal DSL based on Ruby [START_REF] Barišić | Introducing Usability Concerns Early in the DSL Development Cycle : FlowSL Experience Report[END_REF]; an external DSL described in Section 5.2. We chose these case studies as we did not find many examples of usability evaluations involving end users early in the DSLs' development cycle (see Section 7). If we think of DSLs already existing in the market, the USE-ME process will be similar to the process used with DSLs which are under development. However, with previously released DSLs, it should already be clear Who are the users, What are the user stories and Where the DSL is being used. It is expected that it will be possible to reuse most of this knowledge from already existing artefacts and specify the usability goals and metrics in an easier fashion. During the evaluation modelling, the assessments can be planned to be performed automatically (e.g. with automated usage data collection) and remotely. With a large number of regular users, more data can be obtained.

On the other hand, if there is still information missing to create a complete context or goal model, it is still possible to plan the evaluation, by sticking to the information that exists. For instance, if there is no formal specification/documentation of the workflows, this information can be omitted. However, the evaluation model will be designed accordingly, e.g. to evaluate the satisfaction with a language or the readability of design concepts. It is also possible to create an interaction model which captures just 'random' roll-back cycles (semantic errors) during a common use of a product (e.g. placing and deleting certain commands repetitively in a certain sequence can help identifying misinterpretation issues of a concrete syntax element).

Grammar-based DSLs

Both of our case studies were developed by using metamodeling tools (MetaEdit and Eclipse EMF, respectively). Our process is not restricted to model-based DSLs and could, in principle, be applicable also to grammar-based DSLs or even to GPLs. However, this would require adapting our prototype to cope with their architecture. This would be feasible but is beyond the scope of this paper. It would be necessary to apply modelling techniques (e.g. reverse engineering), to create certain artefacts (e.g. goal model, UML diagrams, etc.).

The users of the USE-ME approach -taking the role of Expert Evaluator during the DSL development cycle

The modelling activities in our framework are presented as activities of an Expert Evaluator which, in practice, is not typically included in the DSL development process. We mentioned in Section 2.2 that this HCI expert usually implements complex experimental usability evaluation studies. The HCI expert profile includes comprehension of user profiling, experimental approaches and usability evaluation methods. However, when applying the proposed approach, these kinds of experts may lack the knowledge about model-driven methods and requirements engineering, and it may be not trivial for them to grasp the modelling concepts and tools. Therefore, these experts should be introduced to abstraction modelling and trained to use the modelling support with a focus on mastering the modelling concepts present at the USE-ME approach (e.g. goal modelling, process modelling, UML modelling).

Moreover, we found that in case there is no person included in the development team with evaluation expertise, the knowledge of these experts can be transmitted to a typical DSL Engineer through the USE-ME approach. The approach was validated by researchers from NOVA-LINCS research centre, who are experts in MDD and DSL development and were not involved in the framework development. Some of them are also knowledgeable about the experimental software engineering and requirements engineering. These experts provided valuable feedback and improvement suggestions over the framework. However, people with high level of experience might also not be available during the DSL development process to take the role of Expert Evaluators. Inexperienced engineers can still be suitable for the Expert Evaluator role in the DSL development project. As a proof of concept, we performed a preliminary pilot evaluation of the framework prototype with master students in informatics who had knowledge about MDD and DSL development [START_REF] Barišić | USE-ME Empirical evaluation pilot study[END_REF]. However, these engineers should be trained in user profiling, usability evaluation methods, experimental software engineering and requirements engineering practices.

Related Work

The related studies show that the scientific community is still not making use of the current solutions offered by the software engineering community [START_REF] Kelly | Domain-specific modeling: enabling full code generation[END_REF]. The requirements discovery process is complicated because DSLs are exploring new domain-related problems. Therefore, in most of the cases requirements cannot be known in advance; they change as knowledge changes [START_REF] Segal | Developing Scientific Software[END_REF]. These constraints affect the applicability of many of the traditional software engineering practices and partially explain why scientists tend not to use them [START_REF] Kendall | Development of a Weather Forecasting Code: A Case Study[END_REF].

General purpose usability evaluation approaches

In the context of GPLs, comparing the productivity impact of using different languages during the software development process has some tradition [START_REF] Prechelt | An Empirical Comparison of Seven Programming Languages[END_REF]. Some of the common techniques are the use of a popularity index [START_REF] Cook | Domain specific development[END_REF], the cognitive dimensions framework [START_REF] Green | Usability analysis of visual programming environments: a cognitive dimensions framework[END_REF], or heuristics based on the studies of cognitive effectiveness for visual syntax [START_REF] Moody | Evaluating the Visual Syntax of UML: An Analysis of the Cognitive Effectiveness of the UML Family of Diagrams[END_REF]. These methods can be reused when these techniques are identified as relevant for the usability of a DSL (e.g. Moody's work on cognitive effectiveness can be reused if the visual concrete syntax is given to the target DSL). When usability problems are identified too late, a common approach to mitigate them is to build a tool support that minimises their effect on the user's productivity [START_REF] Bellamy | Using CogTool to model programming tasks[END_REF].

GPL users are typically technically-oriented programmers, with good understanding, skills, and experience in computer science and technology. However, the understanding of domain concepts is also necessary to develop programming solutions. On the other hand, DSLs are meant to reduce the use of computation concepts by putting the focus on the domain concepts. As such, DSLs are expected to be used by a diverse target population (e.g. experts from physics, chemistry, finance, management, etc.). The evaluation criteria for DSLs need to be appropriate for their target users, as well as, technical, social and physical environment.

We can build on existing methodologies and tools to assess the usability of UIs [START_REF] Barišić | Quality in Use of DSLs: Current Evaluation Methods[END_REF] and adopt them for programming languages as we discussed in Section 2.2. Existing UI practices, due to the wide spectrum of the context of use that they target, have a low level of external validity, making it hard to interpret what the collected information means. DSLs are built for a more confined context of use, and they capture one particular set of domain concepts. When evaluating them, the population of users is smaller, and the external validity of the result is expected to be higher.

The state of practice in DSL evaluation

Some studies address specific quality characteristics for DSLs by performing the experimental evaluation after implementing the language (see Sec.2.1.2). Haugen et al. [START_REF] Haugen | A Multi-dimensional Framework for Characterizing Domain Specific Languages[END_REF] present a structured questionnaire based on three dimensions of a DSL; expressiveness, transparency, and formalisation. Merilinna and Parssinen [START_REF] Merilinna | Comparison Between Different Abstraction Level Programming: Experiment Definition and Initial Results[END_REF] investigate the benefits of using DSLs by making comparisons between the DSL approach and traditional methods experimentally. Kosar et al. [START_REF] Kosar | Comparing General-Purpose and Domain-Specific Languages: An Empirical Study[END_REF] independently evaluated several DSLs and are mostly concerned with program comprehension, correctness and efficiency while using the DSLs when compared with using GPLs. A detailed analysis of their data could be used to identify opportunities for improving the tested DSLs. Kieburtz et al.'s [START_REF] Kieburtz | A software engineering experiment in software component generation[END_REF] experiment address DSL comparative evaluation as part of the concern with flexibility. Murray's experiment [START_REF] Murray | Kaleidoquery: a flow-based visual language and its evaluation[END_REF] explicitly looks for opportunities for improving the respective DSLs under scrutiny by taking learnability, understandability, usability, user satisfaction and language evolution as improvement goals. Kärnä et al. [START_REF] Kärnä | Evaluating the use of domain-specific modeling in practice[END_REF] evaluate the DSL solution in an industrial case focusing on the productivity and usability. They first determine the objectives for the creation of the DSL and then collect data via controlled laboratory studies. In general, existing assessments are performed with a final version of a DSL when potential problems are expensive to fix. Our research aims to introduce language evaluation concerns early in the DSL development process so that problems can be found 'on-time' and fixed at a fraction of the cost it would take to fix them if detected only after the implementation.

Gabriel et al. [START_REF] Gabriel | Do Software Languages Engineers Evaluate their Languages?[END_REF] present a systematic review emphasising the reduced concern on the evaluation of DSLs. This work highlights the state of practice and increases awareness of the shortcomings of research regarding this problem. Kosar et al. [START_REF] Kosar | Domain-Specific Languages: A Systematic Mapping Study[END_REF] performed a systematic mapping study of DSLs in the period from 2006 till 2013. They concluded that 'DSL community focuses more on the development of new techniques/methods rather than investigating the integrations of DSLs with other software engineering processes or measuring the effectiveness of DSL approaches'. This work explicitly presents a clear lack of evaluation research, in particular, controlled experiments and a need for integration and measuring effectiveness. Also, it is pointed that DSLs had rarely been validated (e.g., by end-users) assuming that the developed DSLs were perfectly tailored for domains, as well as fitting end-users requirements. However, this is far from true. DSL under development should have been validated by empirical studies, the involvement of end-users, or by the psychology of programming research. Some authors, however, did tackle above mentioned problems. Kolovos et al. [START_REF] Kolovos | Requirements for domain-specific languages[END_REF] list the core quality requirements for a DSL. Hermans et al. [START_REF] Hermans | Domain-Specific Languages in Practice: A User Study on the Success Factors[END_REF] identify success factors for designing DSLs by performing an empirical study. Wu et al. [START_REF] Wu | Measuring the Effort for Creating and Using Domain-Specific Models[END_REF] present an approach to determine the effort while using DSLs during application development, contributing to the classification of the effort and proposing of related metrics. Kelly and Pohjonen [START_REF] Kelly | Worst Practices for Domain-Specific Modeling[END_REF] discuss worst practices for creating DSLs which developers should avoid, based on industrial case studies. McKean and Sprinkle [START_REF] Mckean | Heterogeneous multi-core systems: UML profiles vs. DSM Approaches[END_REF] present criteria that will help in selecting a DSL or any other approach to be used in system development. Nishino [START_REF] Nishino | Misfits in abstractions: towards user-centered design in domain-specific languages for end-user programming[END_REF] was to solve the usability problems of DSLs caused by a bad design. He proposes to identify usability problems by analysing a set of cognitive dimensions proposed by Green et al. [START_REF] Green | Usability analysis of visual programming environments: a cognitive dimensions framework[END_REF]. However, their approach does not cover how to proceed to apply changes in a potential existing analysis model, how to evolve the design models or the implementation infrastructure. This approach addresses only partially the testing of usability problems by usability expert, and it doesn't include end-users into the evaluation. Kahraman [START_REF] Kahraman | A framework for qualitative assessment of domain-specific languages[END_REF] propose a Framework for Qualitative Assessment of DSLs that adapts and integrates the ISO/IEC 25010 standard, maturity level evaluation approach and the scaling approach into a perspective-based model. This framework supports the choice of quality goals from the different stakeholders' perspective but does not to include the Domain User concerns. Finally, Häser [START_REF] Häser | An Integrated Tool Environment for Experimentation in Domain Specific Language Engineering[END_REF] provides an integrated end-to-end tool environment to perform controlled experiments in DSL engineering. The environment supports language design and steps of experimentation, i.e., planning, operation, analysis interpretation, as well as presentation package. Controlled experiments have the potential to provide appropriate, data-driven decision support for language engineers to compare different language features with evidence-based feedback. However, this kind of usability assessments is not always cost effective in early phases of language development.

Applying UCD methodology into design of visual languages

Assessments of the usability of a visual language recently are getting more often seen in practice by successfully involving the UCD methodology (see Sec.2.2.2) into a design of visual DSLs. Neumann [START_REF] Neumann | End-user strategy programming[END_REF] investigates rule-based, end-user strategy programming by introducing a domain-specific, end-user programming environment to allow football coaches to create animated football scenarios and by associating strategy information with virtual football players. This study contributes further by putting into evidence the usefulness of Natural Programming design process, which applies principles of UCD [START_REF] Pane | A programming system for children that is designed for usability[END_REF].

Aghee [START_REF] Aghaee | End-User Development of Mashups with NaturalMash[END_REF] iteratively evaluated a DSL for developing of Mashups using formative evaluations. Angelini [START_REF] Angelini | VIRTUE: A visual tool for information retrieval performance evaluation and failure analysis[END_REF] presents an innovative visualisation environment, which eases and makes more effective the experimental assessment process. Ardito [START_REF] Ardito | User-driven visual composition of service-based interactive spaces[END_REF] offers an approach where a composition platform enables the extraction of content from heterogeneous services and its integration. Bauelo [START_REF] Bauleo | Design, realization and user evaluation of the SmartVortex Visual Query System for accessing data streams in industrial engineering applications[END_REF] presents a visual query system that has been designed and implemented following the UCD approach. Danado [START_REF] Danado | Puzzle: A mobile application development environment using a jigsaw metaphor[END_REF] creates a visual mobile end user development framework which allows end users without programming background to create, modify and execute applications, and provides support for interaction with smart devices, phone functions, and web services. Fogli [START_REF] Fogli | A meta-design approach to the development of e-government services[END_REF] describes a meta-design approach to transfer the development of government-to-citizen services from professional software developers to administrative employees, without forcing employees to acquire any programming skills.

We find that these examples are valuable, although they lack systematic experimental assessment in most of the cases. However, evaluation practice discovered in these works could be made model-driven, systematic and extended to DSLs in general.

Collaborative attempts of introducing an end-user into DSL development

Finally, we present attempts to solve the usability problems by taking into account end-users needs during DSL development. However, these approaches are in most of the cases just applicable in the domain analysis and language design phase, namely supporting collaborative development of the abstract and concrete syntax with end-users. However, these examples do not adequately represent the complete domain model explicitly (scope, terminology, concepts, and commonalities and visibilities). Also, the profile of the users which are included, or knowledge sets which are necessary, are primarily domain experts.

Perez [START_REF] Pérez | Towards the involvement of end-users within model-driven development[END_REF] claims that end-users are taken into account because a visual DSL is selected by applying best practices of end-user development during the design of the concrete syntax, but without a systematic evaluation or customization support. In fact, the proposal always creates visual DSLs to improve usability, which may not be the best approach for some end-users. The goal of Wuest et al. [START_REF] Wuest | Semi-automatic generation of metamodels from model sketches[END_REF] was to facilitate the meta-modeling activity to non-experts by creating FlexiSketch, an environment for modellers and end-users to design together with the examples of the domain using sketches. These examples are used for the creation of the DSL syntax, both the abstract syntax and the concrete syntax. Similarly, Cho et al. [START_REF] Cho | Creating visual domain-specific modeling languages from end-user demonstration[END_REF], provide a friendly solution for end-users to describe domain examples, the creation of the DSL syntax, and the semantic restrictions. Kuhrman et al. [START_REF] Kuhrmann | Rapid Prototyping for Domain-specific Languages-From Stakeholder Analyses to Modelling Tools[END_REF] want to bring together DSL developers and domain experts when developing DSLs in complex application domains. This work provides a DSL, named 'PDE language', which provides a visualisation model editor with different views to facilitate the participation of domain experts in design of concrete syntax. Sanchez-Cuadrado et al. [START_REF] Sánchez-Cuadrado | Bottom-up meta-modelling: An interactive approach[END_REF] wanted to support the use of informal drawing tools as a friendly interface that facilitates the meta-modeling task. The difference of this work in respect to the others is the approach used to generate the meta-model from the domain examples sketches. This meta-model is obtained iteratively, one example at a time, in which developers can assess the evolution of the meta-model and the specific effects of each domain example over the meta-model. If some changes have been applied, a procedure checks for possible mismatches between the final meta-model and the domain examples. Nevertheless, none of the above approaches makes explicit the domain model details, nor addresses evaluation activities of DSL development.

The motivation of Canovas et al. [START_REF] Izquierdo | Enabling the collaborative definition of DSMLs[END_REF][START_REF] Izquierdo | Engaging end-users in the collaborative development of domain-specific modelling languages[END_REF][START_REF] Cánovas Izquierdo | Collaboro: a collaborative (meta) modeling tool[END_REF] was to highlight the importance of the end-users role in the definition of DSLs and provide means to enable the collaboration between end-users and developers in the context of DSL development. With this aim, they propose a community-driven DSL Collaboro, to encourage end-user participation in the definition of DSLs. Collaboro describes the elements of the collaborative activity (comment, vote, solution, etc.) and the elements of the abstract and concrete syntax of a DSL (entity, attribute, relationship, textual notation, etc.). These elements are used to track the evolution of both the abstract and concrete syntax. The collaborative development starts after requirements gathering when developers design a preliminary abstract and concrete syntax. End-users can comment, propose solutions, and vote other participants opinions and proposals. This interaction continues until the syntax after all the changes proposed and applied. In summary, the main contribution of this work as a whole, in contrast to previous works, is the use of friendly mechanisms, such as the use of an informal panel and the use of examples, as a way to reason about the domain and the abstract and concrete syntax. Villanova [START_REF] Villanueva | Involving end-users in the design of a domain-specific language for the genetic domain[END_REF] made a significant contribution in introducing agile methodologies in DSL development. Methods like customer reviews and demonstrations that are used in Scrum are not often validated by real end-users, but mostly with managers or 'buyers' of the software.The practice of introducing a definition of Done brought by the agile practices promotes demonstration to the customers and collecting feedback. However, demonstration and questionnaire are not sufficient to test product usability with the customers. Indeed, without using a product, end users will have a hard time identifying where they are likely to make mistakes and use the product inappropriately. While they can provide some feedback on their satisfaction regarding a language construction, they will not be able to give feedback on their efficiency and effectiveness while using it.

The mentioned works do not address how to prioritise user recommendations, for the next iterations of the DSL development. We could leverage user profile to support prioritisation of requirements for the next iterations, which would lead to more timely and usable improvements in the DSL. This means providing the set of the most needed functionalities in the application area that are possible to be developed in the following cycle when considering the technical restrictions (e.g. lack of the informational database to support the functionality, need to develop previous modules to support the functionality). The domains for which DSLs are developed are constantly changing, so prioritising evaluation can help providing timely solutions that are usable by end-users. However, the specific requirements and needs of the target end-users are not evaluated by including them in systematic evaluations during the DSL development process.

Conclusions and future work

This paper presents and evaluates a framework, called USE-ME, to capture essential concepts relevant for usability evaluation during an iterative and incremental DSL development life-cycle. It aims to cope with the need for systematic approaches for usability evaluations of DLSs, including supporting empirical studies and controlled experiments with end users, that takes into consideration the several development stages. USE-ME covers the whole DSL development process, contrasting with other related approaches which tend to focus on domain analysis and design. Further, they tend to use domain experts as subjects, while we involve the actual end-users in our evaluations.

Figure 1 :

 1 Figure 1: DSL Life-Cycle

Figure 2 :

 2 Figure 2: Research Process Overview

  -[] -main concepts i.e. classes in diagrams; -«» -attributes and relations of the introduced concepts that are part of the diagram presented in a section, -<Italic> -attributes and relations that are part of diagrams from other sections, -{} -instantiation of the concept i.e. instance object; -" -activity in a diagram -'Italic' -decision in activity diagram 4.1. The Usability Software Engineering Modelling Environment (USE-ME)

Figure 3 :

 3 Figure 3: USE-ME life-cycle

Figure 4 :

 4 Figure 4: USE-ME activity diagram

Figure 5 :

 5 Figure 5: Utility package

Figure 6 :

 6 Figure 6: Context Model class diagram

Figure 7 :

 7 Figure 7: Context Modelling activity diagram

Figure 8 :

 8 Figure 8: Goal Model class diagram

  . The root [Usability Goal] of the [GM] is the Quality in Use, and represents «parentGoal» of any newly defined «subGoal». Goals are characterised by: -Actor -is a specialisation of DSL stakeholder, namely an instantiation of a [User Profile] from the [CM], to which are assigned the responsibilities («responsible For») for the associated [Usability Goal]. The resulting responsibility model clearly distinguishes stakeholders to which a [Usability Goal] is related (i.e. [Scope]) from the ones that are responsible for achieving it (i.e. [Actor], «responsibleActor»).

Figure 9 :

 9 Figure 9: Goal Modelling activity diagram

Figure 10 :

 10 Figure 10: Evaluation Model class diagram

  [Evaluation Context]. The choice of appropriate treatment is guided by its probability to evaluate the [Evaluation Goal]. These activities are represented by [Documentation] and [Test Models]. They specify the flow of learning treatment activities that are modelled in the evaluation [Process].

  The 'Evaluation Context specification' activity defines the context that is considered during evaluation, taking into consideration «profile» of selected [Participants] and the «scope» of the [Evaluation Goal]. This activity can be extended by the context modelling activity if the existing [CM] is missing relevant information. Before the 'Evaluation execution', it is necessary to produce [Documentation] during the 'Teaching Material creation', define evaluation [Process] by 'Process specification' and prepare the [Test Model] during 'Test Model creation'. The 'Test Model creation' activity selects a previously created [Test Model] or calls the Interaction Modelling or Survey Modelling to produce the new or refined [Test Models].

Figure 11 :

 11 Figure 11: Evaluation Modelling activity diagram

Figure 12 :

 12 Figure 12: Interaction Model class diagram

  [Workflow] that is included in the [Evaluation Context]. Based on the [Task], the evaluation expert is ready to perform 'Events specification' during which [Event]s are defined, as well as the way to capture them. Further, he performs the 'Interaction Participant assessment' activity where the experiment [Participants] are assigned to the [IM]. In the same time, the scheme for [Interaction Result] is prepared by 'Interaction Result formatting' activity. Finally, when the [SM] is complete, it is sent to 'Interaction execution' during which results are automatically stored in the [Interaction Result] model.

Figure 13 :

 13 Figure 13: Interaction Modelling activity diagram

Figure 14 :

 14 Figure 14: Survey Model class diagram

  [Participants] are assigned to the [SM]. In the same time, the scheme for [Survey Result] is prepared in the 'Survey result formatting' activity. Finally, when the [SM] is complete, it is sent to 'Survey execution' during which results are automatically stored in the [Survey Result] model.

Figure 15 :

 15 Figure 15: Survey Modelling activity diagram

Figure 16 :

 16 Figure 16: Report Model class diagram

Figure 17 :

 17 Figure 17: Report modelling activity diagram

Figure 18 :

 18 Figure 18: Model to model transformations supported by Goal Coverage Engine

Figure 19 :

 19 Figure 19: USE-ME architecture

Figure 20 :

 20 Figure 20: User Hierarchy

Figure 21 :

 21 Figure 21: User Profile Template

Figure 22 :

 22 Figure 22: Environment Context

Figure 23 :

 23 Figure 23: Workflows

Figure 24 :

 24 Figure 24: Scenarios

Figure 25 :

 25 Figure 25: Usability Goal Model

Figure 26 :

 26 Figure 26: Usability requirements for usability goal [U1]

Figure 27 :

 27 Figure 27: Evaluation objectives

Figure 28 :

 28 Figure 28: Evaluation Instantiation

Figure 29 :

 29 Figure 29: Interaction Test Model

Figure 30 :

 30 Figure 30: Survey Test Model

  The feedback survey was designed to measure the «requirement» {Satisfaction}, which was characterised by the following «indicators»: {Confidence}, reflecting how confident children were about their solution, {Likability}, reflecting how interesting and enjoyable they found the challenge itself; and {Learnability}, reflecting how useful they found what was taught during the learning session to help them facing the final challenge. Each question can be related to a concrete «scenario» included in EM. For instance, the question [F2: Did you find it difficult to program the robot to move in front?] indicates {Confidence} of the participant regarding the learned «scenario» {Program robot to move front and back}. The «scale» for all satisfaction questions reflects positive or negative experiences and is defined as {[1]: Smiley[positive], [0]: Smiley[neutral], [-1]: Smiley[negative]}.

Figure 31 :

 31 Figure 31: Report Model

-

  DSL Spreadsheets -a DSL that transforms an activity graph into a Gantt chart. The target users of this DSL are project managers. -Gestures Kinect -a DSL which supports specification of communication between navy users using a Kinect device. The target users of this DSL are navy operators. -Peddy Paper -a DSL which creates several instances of personalised rally paper scripts. The target users are rally paper organisers. -Smart House -a DSL which supports a design of the elements and operations for a smart home. It is meant to be used by house owners.

Figure 32 :

 32 Figure 32: Pilot session process Model

Figure 33 :

 33 Figure 33: Integration of USE-ME approach with DSL development phases

6. 3 .

 3 Applicability of the approach outside of the scope of model-based DSLs under development 6.3.1. Previously released DSLs

  https://www.nomagic.com/products/cameo-systems-modeler (accessed May 4, 2017) 13 http://www.uml.org/ (accessed May 4, 2017) 14 https://github.com/akki55/useme (accessed May 4, 2017) 15 http://www.eclipse.org/modeling/emf/ (accessed May 4, 2017) 16 https://eclipse.org/sirius/ (accessed May 4, 2017)

Table 1 :

 1 Validation table of USE-ME models produced for each DSL

	DSL	Spread Sheets Gestures Kinect Peddy Paper Smart House AVG
	Participation time	6h	12h	12h	12h
	CONTEXT MODELING	0.36	0.72	0.56	0.76	0.6
	User Hierarchy	0.6	0.8	0.8	1	0.8
	User Profile Template	0.4	0.6	0.4	0.6	0.5
	Environment Context	0.2	0.8	0.6	0.8	0.6
	Workflows	0.2	0.8	0.2	0.8	0.5
	Scenarios	0.4	0.6	0.8	0.6	0.6
	GOAL MODELING	0	1	0.4	0.5	0.475
	Usability Goal Model	0	1	0.4	0.8	0.55
	Usability Requirements	0	1	0.4	0.2	0.4
	EVALUATION MODELING 0.2	0.6	0.7	0.7	0.55
	Evaluation objectives	0.2	0.8	0.6	0.6	0.55
	Evaluation instantiation	0.2	0.4	0.8	0.6	0.5
	Interaction Test Model	0.2	0.4	0.8	0.8	0.55
	Survey Test Model	0.2	0.8	0.6	0.8	0.6
	Table

dsm-tp.org (accessedMay 4,

2017)

https://movercado.wordpress.com/ (accessedMay 4, 2017)

http://www.scrum.org/ (accessed May

4, 2017) 4 http://www.arduino.cc/ (accessed May 4, 2017) 5 http://artica.cc/ (accessed May 4, 2017) 6 https://www.lego.com/en-us/mindstorms/ (accessed May 4, 2017)

https://sites.google.com/view/vl-empiricalstudy/home (accessedMay 4, 2017)

Acknowledgments

The authors would like to thank FCT/MEC NOVA LINCS; PEst UID/ CEC/04516/ 2013 and DSML4MA TUBITAK/0008/2014 Projects, as well as to COST Action IC1404 Multi-Paradigm Modelling for Cyber-Physical Systems (MPM4CPS) for the partial support to this work.

This work identifies all the mandatory concepts and activities and aggregates them into a formal meta-model. With this approach, we highlight the complexity of the information that should be traced to streamline and automate (as much as possible) the user-centered development process. The framework supports internal and external quality (e.g. syntactic and semantic models) and quality in use (e.g. interaction and survey models). Our approach helps the Language Engineers to explicitly model the evaluation process. This procedure allows the DSL developers to monitor the impact of language evolution to the efficiency and effectiveness of practitioners using the language (and its companion toolset). Additionally, it supports specifying experimental assessments and tracing the impact of usability improvements since an early stage of development of DSLs. In the long run, this approach is expected to improve the productivity of the DSL developers and the language users.

The methodological contributions are supported by a modelling tool. A prototype tool was integrated with an existing Eclipse-based IDE to support the development of DSLs. This prototype enables language engineers to take the role of Expert Evaluators and to prepare the evaluation models. Also, it supports tracing the evaluation goals, reusing experiment designs and providing better documentation and reasoning.

This approach, besides documenting the evaluation process, enables reasoning about the models and setting a clear workflow to its users. As part of the future work, we are improving the tool support to guide the users through the modelling process and validate the models. It is being implemented as a part of Goal Coverage engine, which will contain specification and verification of different syntactic and semantic rules depending in which step of a USE-ME process is a user. This engine will also support verification of rules regarded to transformations between the models in different development stages. Finally, the USE-ME engine will be extended with a tool for (semi)automatically determine the success coverage of the specified usability goals by the DSL developer.

Finally, another follow-up to the presented work is to study the integration of USE-ME with already existing solutions and modelling workbenches for the development of the DSLs. We believe that this contribution is a step towards the automation of the DSL development process tackling a specific concern that is typically neglected, Quality in use.