Learning programming is hard - teaching it well is even more challenging. At university, the focus is often on functional correctness and neglects the topic of clean and maintainable code, despite the dire need for developers with this skill set within the software industry. We present a feedbackdriven teaching concept for college students in their second to third year that we have applied and refined successfully over a period of more than six years and for which received the faculty's teaching award. Evaluating the learning process within a semester of student submissions (n=18) with static code analysis tools shows satisfying progress. Identifying the correction of the in-semester programming assignments as the bottleneck for scaling the number of students in the course, we propose using a knowledge base of code examples to decrease the time to feedback and increase feedback quality. From our experience in assessing student code, we have compiled such a knowledge base with the typical issues of Java learners' code in the format of before/after comparisons. By simply referencing the problem to the student, the quality of feedback can be improved, since such comparisons let the student understand the problem and the rationale behind the solution. Further speed-up is achieved by using a curated list of static code analysis checks to help the corrector in identifying violations in the code swiftly. We see this work as a foundational step towards online courses with hundreds of students learning how to write clean code.

Workflow Management Systems (WfMSs) are a type of middleware that enables the execution of automated business processes. Users rely on WfMSs to construct flexible and easily maintainable software systems. Significant effort has been invested into standardising languages for business processes execution, with standards such as the Web Services Business Process Execution Language 2.0 or the Business Process Model and Notation 2.0. Standardisation aims at avoiding vendor lockin and enabling WfMS users to compare different systems. The reality is that, despite standardisation efforts, different independent research initiatives show that objectively comparing WfMSs is still challenging. As a result, WfMS users are likely to discover unfulfilled expectations while evaluating and using these systems. In this work, we discuss the findings of two research initiatives dealing with WfMSs benchmarking, presenting unfulfilled expectations and lessons learned concerning WfMSs' usability, reliability, and portability. Our goal is to provide advice for practitioners implementing or planning to use WfMSs.

Workflow engines are frequently used in the service-oriented and cloud computing domains. Since engines have significant impact on the quality of service provided by hosted applications, it is desirable to compare and select the most appropriate engine for a given task. To enable such a comparison, approaches for benchmarking workflow engines have emerged. Although these approaches deal with different quality properties, such as performance or standard conformance, they face many reoccurring problems during the design and implementation phase, which they solve in similar ways. In this paper, we describe such common solutions to reoccurring problems in the area of workflow engine benchmarking as patterns. Our aim is to present pattern candidates that help benchmark authors to design and implement proper and valid workflow engine benchmarks and benchmarking tools

Workflow engines are frequently used in the domains of business process management, service orchestration, and cloud computing, where they serve as middleware platforms for integrated business applications. Engines have a significant impact on the quality of service provided by hosted applications. Therefore, it is desirable to compare them and to select the most appropriate engine for a given task. To enable such a comparison, approaches for benchmarking workflow engines have emerged. Although these approaches deal with different quality attributes, i.e., performance or standard conformance, they face many reoccurring design and implementation problems, which have been solved in similar ways. In this paper, we present a pattern language that captures such common solutions to reoccurring problems (e.g., from test identification, benchmarking procedure validation, automatic engine interaction, and workflow execution observation) in the area of workflow engine conformance and performance benchmarking. Our aim is to help future benchmark authors with the pattern language presented in this paper to benefit from our experience with the design and implementation of workflow engine benchmarks and benchmarking tools

It is a long-standing debate, whether software that is developed as open source is generally of higher quality than proprietary software. Although the open source community has grown immensely during the last decade, there is still no clear answer. Service-oriented software and middleware tends to rely on highly complex and interrelated standards and frameworks. Thus, it is questionable if small and loosely coupled teams, as typical in open source software development, can compete with major vendors. Here, we focus on a central part of service-oriented software systems, i.e., process engines for service orchestration, and compare open source and proprietary solutions. We use the Web Services Business Process Execution Language (BPEL) and compare standard conformance and its impact on language expressiveness in terms of workflow pattern support of eight engines. The results show that, although the top open source engines are on par with their proprietary counterparts, in general proprietary engines perform better

Over the last years, the utilization of cloud resources has been steadily rising and an increasing number of enterprises are moving applications to the cloud. A leading trend is the adoption of Platform as a Service to support rapid application deployment. By providing a managed environment, cloud platforms take away a lot of complex configuration effort required to build scalable applications. However, application migrations to and between clouds cost development effort and open up new risks of vendor lock-in. This is problematic because frequent migrations may be necessary in the dynamic and fast changing cloud market. So far, the effort of application migration in PaaS environments and typical issues experienced in this task are hardly understood. To improve this situation, we present a cloud-to-cloud migration of a real-world application to seven representative cloud platforms. In this case study, we analyze the feasibility of the migrations in terms of portability and the effort of the migrations. We present a Dockerbased deployment system that provides the ability of isolated and reproducible measurements of deployments to platform vendors, thus enabling the comparison of platforms for a particular application. Using this system, the study identifies key problems during migrations and quantifies these differences by distinctive metrics

Service orchestrations are a powerful tool for implementing intra- and interorganizational business processes that base on services. Several heterogeneous orchestration languages can be found in contemporary IT landscapes. While the Web Services Business Process Execution Language (BPEL) is the de facto standard, others gain attention, including Windows Workflow (WF) in the. NET segment. When integrating orchestrations, incompatibilities between them can easily arise. In this paper, we investigate an automated Petri net-based integration between BPEL and WF to solve these issues with behavioral adapter services. We provide a mapping of WF to Open Workflow Nets (oWFNs) and implement it in a compiler. Thereby, we integrate our approach with existing approaches for BPEL and adapter synthesis and validate the integration with a standards-based case study using the two languages.

Software architecture degradation is a phenomenon that frequently occurs during software evolution. Source code anomalies are one of the several aspects that potentially contribute to software architecture degradation. Many techniques for automating the detection of such anomalies are based on source code metrics. It is, however, unclear how accurate these techniques are in identifying the architecturally relevant anomalies in a system. The objective of this paper is to shed light on the extent to which source code metrics on their own can be used to characterize classes contributing to software architecture degradation. We performed a multi-case study on three open-source systems for each of which we gathered the intended architecture and data for 49 different source code metrics taken from seven different code quality tools. This data was analyzed to explore the links between architectural inconsistencies, as detected by applying reflexion modeling, and metric values indicating potential design problems at the implementation level. The results show that there does not seem to be a direct correlation between metrics and architectural inconsistencies. For many metrics, however, classes more problematic as indicated by their metric value seem significantly more likely to contribute to inconsistencies than less problematic classes. In particular, the fan-in, a classes’ public API, and method counts seem to be suitable indicators. The fan-in metric seems to be a particularly interesting indicator, as class size does not seem to have a confounding effect on this metric. This finding may be useful for focusing code restructuring efforts on architecturally relevant metrics in case the intended architecture is not explicitly specified and to further improve architecture recovery and consistency checking tool support.

Work ow Management Systems (WfMSs) today act as ser- vice composition engines and service-oriented middleware to enable the execution of automated business processes. Automation based on WfMSs promises to enable the model-driven construction of exible and easily maintainable services with high-performance characteristics. In the past decade, signi cant e ort has been invested into standardizing WfMSs that compose services, with standards such as the Web Services Business Process Execution Language (WS-BPEL) or the Business Process Model and Notation (BPMN). One of the aims of standardization is to enable users of WfMSs to compare di erent systems and to avoid vendor lock-in. Despite these e orts, there are many expectations concerning portabil- ity, performance e ciency, usability, reliability and maintainability of WfMSs that are likely to be unful lled. In this work, we synthesize the ndings of two research initiatives that deal with WfMSs conformance and performance benchmarking to distill a set of lessons learned and best practices. These ndings provide useful advice for practitioners who plan to evaluate and use WfMSs and for WfMS vendors that would like to foster wider adoption of process-centric service composition middleware. 

Context: Facing the implementation of the EU General Data Protection Regulation in May 2018, many commercial software providers will soon need to adapt their products to new privacy-related constraints. Privacy patterns defined for different aspects of the software engineering process promise to be a useful concept for this task. In this situation, it seems valuable to characterize the state of the research related to privacy patterns.Objective: To identify, characterize and classify the contributions made by published research results related to patterns in the context of considering privacy concerns in engineering software. Method: A literature review in form of a mapping study of scientific articles was performed. The resulting map structures the relevant body of work into multiple dimensions, illustrating research focuses and gaps.Results: Results show that empirical evidence in this field is scarce and that holistic approaches to engineering privacy into software based on patterns are lacking. This potentially hinders industrial adoption.Conclusion: Based on these results, we recommend to empirically validate existing privacy patterns, to consolidate them in pattern catalogues and languages, and to move towards seamless approaches from engineering privacy requirements to implementation.

Service-oriented software consists of middleware, such as application servers and runtime engines, into which service applications are deployed. This middleware is often complex and difficult to install. The deployment of services requires the crafting of deployment descriptors and packaging of applications. As a consequence, the installation of service-oriented software systems can be a daunting task. Install ability, however, is an important influencer of the portability of software. Portability in turn is one of the main goals of service orchestration languages based on open standards. In this paper, we investigate the install ability of service orchestrations based on the Systems and software Quality Requirements and Evaluation (Square) method, the new series of software quality standards currently under development by the ISO/IEC. We develop a measurement framework based on Square and tailored to evaluating the install ability of service orchestrations and their runtimes. We validate the measurement framework theoretically and show its applicability in a case study.

Context: Several studies suggest that there is a relation between code smells and architecture degradation. They claim that classes, which have degraded architecture-wise, can be detected on the basis of code smells, at least if these are manually identiÿed in the source code.

Objective: To evaluate the suitability of contemporary code smell detection tools by combining different smell categories for ÿnding classes that show symptoms of architecture degradation.

Method: A case study is performed in which architectural in-consistencies in an open source system are detected via reflexion modeling and code smell metrics are collected through several tools. Using data mining techniques, we investigate if it is possible to auto-matically and accurately classify classes connected to architectural inconsistencies based on the gathered code smell data.

Results: Results suggest that existing code smell detection techniques, as implemented in contemporary tools, are not sufficiently accurate for classifying whether a class contains architectural in-consistencies, even when combining categories of code smells.

Conclusion: It seems that current automated code smell detection techniques require ÿne-tuning for a speciÿc system if they are to be used for ÿnding classes with architectural inconsistencies. More research on architecture violation causes is needed to build more accurate detection techniques that work out-of-the-box.

Being able to access and provide Internet services anonymously is an important mechanism to ensure freedom of speech in vast parts of the world. Offering location-hidden services on the Internet requires complex redirection protocols to obscure the locations and identities of communication partners. The anonymity system Tor supports such a protocol for providing and accessing TCP-based services anonymously. The complexity of the hidden service protocol results in significantly higher response times which is, however, a crucial barrier to user acceptance. This communication overhead becomes even more evident when using limited access networks like cellular phone networks. We provide comprehensive measurements and statistical analysis of the bootstrapping of client processes and different sub-steps of the Tor hidden service protocol under the influence of limited access networks. Thereby, we are able to identify bottlenecks for low-bandwidth access networks and to suggest improvements regarding these networks.

Orchestration languages are of paramount importance when implementing business processes based on services. Several languages for specifying Web Services-based orchestrations are available today. Examples are the Web Services Business Process Execution Language or Windows Workflow. Patterns for process-aware information systems have frequently been used to assess such languages. Various studies discuss the degree of support such languages provide for certain sets of patterns. However, the traditional trivalent support measure is limited in terms of granularity and selectivity. This paper proposes an edit distance complexity measure that allows to overcome these issues. The applicability of this measure is demonstrated by an analysis of several orchestration languages using four different pattern catalogs.

Various approaches for service-oriented business-to-business integration (B2Bi) rely on a top-down development methodology. The starting point is a choreography model which is subsequently partitioned into multiple orchestrations. Most current approaches use the Web Services Business Process Execution Language (BPEL) for implementing the latter. At the same time, a plethora of other languages, such as Business Process Model and Notation (BPMN) 2.0 process diagrams, is available. As integration partners are free to select the orchestration language of their choice, it should be easy to integrate different orchestration languages with current choreography technology. Language transformation, starting from a suitable format, is a means to achieve this. In this paper, we assess BPEL 2.0 and BPMN 2.0 process diagrams for their suitability for this transformation in a services-based B2Bi setting using a requirements framework identified through a literature study.

Service orchestration languages, like the Web Services Business Process Execution Language (BPEL), have been frequently used to provide an implementation platform for model-driven development approaches. As avoidance of vendor lock-in and portability of process definitions are central aims of BPEL, most approaches claim to support a large set of different runtime environments. But, even though today various runtimes for BPEL are available, every runtime implements a different language subset, thus hampering portability. Our idea is to improve this situation by using techniques, the Web Services Interoperability Organization (WS-I) has used to improve services interoperability. We describe a portability profile for BPEL that can detect portability issues in process definitions. Using this profile, we evaluate the portability of BPEL mappings used in several model-driven development approaches.

A key promise of process languages based on open standards, such as the Web Services Business Process Execution Language, is the avoidance of vendor lock-in through the portability of process definitions among runtime environments. Despite the fact that today, various runtimes claim to support this language, every runtime implements a different subset, thus hampering portability and locking in their users. In this paper, we intend to improve this situation by enabling the measurement of the degree of portability of process definitions. This helps developers to assess their process definitions and to decide if it is feasible to invest in the effort of porting a process definition to another runtime. We define several software quality metrics that quantify the degree of portability a process definition provides from different viewpoints. We validate these metrics theoretically with two validation frameworks and empirically with a large set of process definitions coming from several process libraries.

A key promise of process languages based on open standards, such as the Web Services Business Process Execution Language, is the avoidance of vendor lock-in through the portability of processes among runtime environments. Despite the fact that today various runtimes claim to support this language, every runtime implements a different subset, thus hampering portability and locking in their users. It is our intention to improve this situation by enabling the measurement of the portability of executable service-oriented processes. This helps developers to assess their implementations and to decide if it is feasible to invest in the effort of porting a process to another runtime. In this paper, we define several software quality metrics that quantify the degree of portability of an executable, service-oriented process from different viewpoints. When integrated into a development environment, such metrics can help to improve the portability of the outcome. We validate the metrics theoretically with respect to measurement theory and construct validity using two validation frameworks. The validation is complemented with an empirical evaluation of the metrics using a large set of processes coming from several process libraries.