## 1 Introduction and Motivation
Our results identify the gap between non-programmers' and programmers' mental models with respect to two prominent approaches to composing software services; e.g., workflow-based service composition [7] and artificial intelligence-based service composition [8]. Secondly, it proposes a set of practical guidelines for designing tools to support end-user service composition, which are based on our first contribution above (Section 6). These are specialized guidelines to tackle the emerging conceptual problems and facilitate different aspects of service composition for non-programmers. This contribution agrees with the recommendation of [PERSON] et al. [9] to align development environments with developers' mental model of programming structures to accommodate for the rapidly changing requirements. Throughout this article, we use the terms 'non-programmers' and 'programmers' to denote our two user groups. The term 'non-programmers' refers to people who do not have a software development-related education, nor do they have programming experience, and the activity of programming is fairly new to them. The term 'programmers' refers to people who have a software development-related education (at degree or to a professional level) or who have considerable programming and software development experience without a formal education. The latter group will act as an expert sample against which all non-programmers' composition activities and strategies will be compared. This article poses two research questions focusing on the manual composition and assisted, template-based composition of software services by non-programmers. Next, educated hypotheses were generated from the findings of previous user-based studies of service and mashups composition. **RQ1:**_What type of design challenges are faced by non-programmers when composing services manually using a workflow-based composition approach that offers minimal tool support?_  
Due to their low level of programming skills, it was expected that non-programmers would find it challenging to understand service particulars [10; 11; 12; 13; 14], and define conditional statements [15] and dataflow connections between services [10; 11; 12; 13; 16; 17; 18]. In contrast, programmers were anticipated to complete these manual composition tasks more accurately because of their strong mental model of programming concepts. Consequently, our hypotheses pertaining to manual composition are as follows:  
**Hypothesis 1a (H1a). **_Non-programmers will find it more difficult to understand service terminologies compared to programmers._  
**Hypothesis 1b (H1b). **_Non-programmers will find it more difficult to define conditional flows (IF... ELSE) between services compared to programmers._  
**Hypothesis 1c (H1c). **_Non-programmers will find it more difficult to create dataflow connections between services compared to programmers._  
**Hypothesis 1d (H1d). **_Non-programmers will face more challenges with manual service composition compared to programmers._  
**Hypothesis 1e (H1e). **_Non-programmers will hold a more negative perception about manual composition compared to programmers._  
**RQ2:**_What are the attitudes of non-programmers when a software tool is \"taking over\" their design by abstracting technical details and advising them about consequences of their choices?_  
Due to their poor software development experience, non-programmers should regard assisted composition (i.e., assisted template-based design) as easy to use and satisfying [19; 20; 21; 22]. This is because it requires little cognitive effort to operate and is close to their mental models. However, programmers are expected to regard assisted composition as inflexible, constraining, and lacking power to express complex application logic [14; 18]. Consequently, our hypotheses pertaining to assisted composition are as follows:  
**Hypothesis 2a (H2a). **_Non-programmers will hold a more positive perception about assisted composition compared to programmers._  
**Hypothesis 2b (H2b).