## 6 Discussion and Practical Implications for Service Composition
* **DR4:**_\"Enable non-programmers to observe and inspect the behaviour of their compositions on the fly and introduce fault/bug localization features.\"_ It is nearly impossible to create perfect compositions on the first attempt, as evident in the condition definition and dataflow specification tasks; therefore, service-development environments should host features to locate and fix bugs within the composition models. This guideline agrees with previous research [80]. This way, users can check the correctness of their requirements and composite service [81]. * **DR5:**_\"Provide composition walkthroughs and examples of varying complexity to raise self-efficacy and confidence of non-programmers progressively.\"_ This design guideline enables a \"gentle slope\" of cognitive challenge and tailorability. **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?_  
The qualitative results showed two opposing views towards the assisted service composition. The first view, by non-programmers, appreciates the ease with which services can be composed through simple clicks on activities and their services (i.e., H2a partially-supported). Assisted composition simplifies service composition through activity-based templates, offering direct manipulation of services without the need to write programming code. These features support the limited syntactic and semantic knowledge of non-programmers, as they can work directly with the services that interest them without dwelling in computational abstracts. Interestingly, the help section of the tool was described as technically-oriented and difficult to understand, and non-programmers expressed doubts over their capability to perform composition without assistance. This can be attributed to their low self-efficacy and confidence [5, 58]. The second view, by programmers, criticizes the assisted composition for its inflexibility and restrictiveness, and questions whether it is sufficient to express complex scenarios. For instance, this approach to composition did not allow the formation of conditions, limiting the richness of the composite services produced. Programmers were more inquisitive than non-programmers' as they requested to learn the mechanics behind assisted composition and why certain things happen. This was evidenced in the time they spent arranging activities and assigning services to template activities, which was statistically longer than that of non-programmers'. Justifiably, programmers were negative towards the assisted-composition approach due to its low level of expressiveness and power, which did not allow them to achieve advanced application behaviour (i.e., H2a partially-supported). Service composition approaches that rely solely on direct manipulation often lose their power of expressiveness and flexibility. In conclusion, such kinds of approaches may be more suitable for users whose primary function is not programming. The design recommendations to lower the barriers to assisted service composition by non-programmers are as below. * **DR1:**_\"Use activity or goal-oriented templates to facilitate and support service composition tasks.\"_ Non-programmers are capable of undertaking development tasks that make use of natural languages [73]. Activity-based templates identify the goal of composition and break this down into simple actions that achieve that goal (e.g. task analysis). This process supports the strategic knowledge of non-programmers who are naturally aware of domain concepts but not acquainted with the underlying programming and service composition concepts.