## 3 Tools and Methods
### Study Procedure and Tasks' Description
#### 3.4.2 Service Composition Phase  
First, we conducted a pilot study, including three participants, to ensure that the composition tasks were well described and interpreted in the intended manner. Subsequently, we refined the descriptions of the tasks so that they accurately described what needed to be achieved without detailing the fine-grained steps required to solve the tasks. We also ensured the tasks were sufficiently complex to enable full coverage of the different service composition activities supported by the SOA4 All tools. \begin{table}
\begin{tabular}{l l} \hline \hline
**Composition Tool and Aim** & **Features** \\ \hline \hline \multirow{7}{*}{Process Editor: Models service processes using visual notations—manual design of service compositions} & (1) Uses graphical notations to visualize and represent services for higher level of abstraction and increased understandability; \\  & (2) Relies on graphical manipulation, e.g., drag and drop, to connect notations together for expressing process flow and data \\  & (3) No coding is required to produce process models; \\  & (4) Composition relies on workflow-based notations. \\ \hline \hline \multirow{7}{*}{User Assisted Composition Tool: Composes services using activity-based templates—parametric design using templates} & (1) Focuses on the goal of the composition (i.e., intent of the end-user developer); \\  & (2) Relies heavily on selection of services; \\ \cline{1-1}  & (3) Services are represented as black boxes, hiding \\ \cline{1-1}  & (4) No visual modelling or coding is required; \\ \cline{1-1}  & (5) Composition uses artificial intelligence \\ \cline{1-1}  & (6) techniques to assist the user. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Features of SOA4 all service composition tools. At the start, the participants were given an evaluation workbook containing the \"University Registration\" scenario, along with a description of the development tasks and a list describing the available services and their operations that may be used to achieve the scenario. Participants then interacted with the SOA4 All tools and performed a range of service composition tasks, as outlined in Table 2.  
We selected a scenario that our participants, non-programmers and programmers alike, would find familiar, since it related to the process they went through when applying to study at a particular UK university. The overall description of the test scenario was as follows:  
\"This scenario describes the registration process that overseas students go through while getting admission into UK universities. Your goal is to complete an overseas student registration process. For this you need to develop a software application which allows you to search for a UK university, register for a course in the university and find an accommodation. There are two ways for paying the university fee, the first way is to open a bank account and get funds transferred into that account. The bank account can be used to make a payment for the university fee. In the second way, you can request a letter from a sponsor and submit that letter to the university. You must choose only one way to pay the university fee. After paying the university fee, you will register with the NHS.\"  
This scenario helps participants to think about the aim and context of the composition, and the control flow of the composite service to be developed. The service-development tasks were of two types: (a) manual service composition and (b) parametric design using templates with high degrees of software support (or assisted composition). The SOA4 All composition tools offered two varying levels of support when interacting with the users, ranging from very little support during manual service composition to a high level of support during the parametric design with templates, where users only have to select the correct template, and then those services which fit their circumstances and preferences. This is illustrated in Figure 4.