ICSEA 2014 : The Ninth International Conference on Software Engineering Advances An Approach for Modeling and Transforming Contextually-Aware Software Engineering Workflows Roy Oberhauser Computer Science Dept. Aalen University Aalen, Germany [email protected] Abstract—Software engineering environments (SEE) face rigid, and inflexible [6], and fail to adequately support the challenges for providing automated guidance for human- human, creative, and dynamics of SW development. Thus, centric software development workflows. Among the various such systems are ignored or abandoned by SW engineers. issues is the lack of a method to model software engineering To address this challenge for such human-centric SE (SE) workflows, as commonly used business process modeling processes, we created a PCSEE called the Context-aware notation is generalized and not conducive to context-aware Software Engineering Environment Event-driven Framework support for SEE, while available SE-specific process model (CoSEEEK) [7]. Beyond SE tool sensors and other notation, such as the Software & Systems Process Engineering contextual knowledge, it utilizes workflows to understand Metamodel, is not executable. The solution approach in this the process context. That includes knowing which activities a paper simplifies and validates the modeling of SE workflows SW engineer performed, which activity is likely currently via graphical modeling capabilities that extend the Software Engineering Workflow Language (SEWL). Model-based being worked on, which activity is next, and associates these transformation of workflow concepts to diverse workflow with SE concepts of project, teams, persons, roles, tools, and management systems (WfMS), as well semantic transformation artifacts via an ontology and reasoner. While various facets of SE concepts to a contextually-aware process-centered were investigated, including collaboration [8], quality software engineering environment - CoSEEEK, is supported. integration [9], and others, we still faced the problem of The results show the viability and practicality of such an providing an easy to use way for SW engineers to model and approach to graphically model, transform, and enact SE transform SE workflows, integrating SE concepts without workflows while transforming relevant SE concepts to an vendor-lockin to a specific WfMS or its tools. ontology that supports contextual guidance capabilities. Considering possible SE workflow modeling notation, the Software & Systems Process Engineering Metamodel Keywords-process-centered software engineering (SPEM) [10] is aimed primarily at defining a domain- environments; software engineering environments; software specific notation for the documentation of SE processes, and engineering process modeling; software engineering process does not completely address issues related to executable SE model transformation. processes so that automatic support and guidance for software engineers in operational activities can occur. On the I. INTRODUCTION other hand, a general workflow language notation such as the In order to be generally applicable to various software Business Process Model and Notation (BPMN) [11], while (SW) development projects, most software engineering (SE) executable, lacks the inclusion and semantic meaning of process models remain abstract and require tailoring to the various SE domain-specific concepts. specific project, team, and tool environment. Examples of SE To address the executable SE workflow language gap, process models include VM-XT [1] (specified for all public- our team had created the text-based language SEWL [12] sector IT development in Germany) and OpenUP [2]. and had targeted the adaptive WfMS AristaFlow [13] and Typical SE process models are documented in natural YAWL [14]. This paper contributes various extensions to the languages and are thus not easily executable in an automated original workflow concepts, including: a new graphical form. Executable processes whose sequence can be representation for SE-specific workflows blending BPMN automated and modeled in a workflow management system and SPEM notation; a graphical editor for SE workflows; (WfMS) are called workflows. SE workflows can cover details on the model-driven generation of tailored artifacts some sequence of activities and steps related to that target the ontology and heterogeneous WfMS support, requirements, design, testing, etc., for instance Activity specifically the common of-the-shelf (COTS) WfMS jBPM Flows in VM-XT [3] or workflows in OpenUP [4]. [15] and Activiti [16]; and the workflow ontology generator, Despite the potential of process-aware information which addresses the aspect of contextual-awareness support systems (PAIS) to provide automatic process assistance and for workflows in conjunction with CoSEEEK. guidance for humans, this area has lacked satisfactory The summary of the paper is as follows: the next section assistance mechanisms and standards. While process- discusses related work; Section III describes the solution centered software engineering environments (PCSEEs) have concept; followed by implementation details; Section V attempted to address this area [5], they remain intrusive, presents an evaluation, which is followed by a conclusion. Copyright (c) IARIA, 2014. ISBN: 978-1-61208-367-4 117 ICSEA 2014 : The Ninth International Conference on Software Engineering Advances II. RELATED WORK and abstracts the peculiarities of each WfMS (such as jBPM SPEM 2.0 [17] was approved without supporting full and Activiti), interacting via events indirectly with process enactment. It proposes two possible approaches for CoSEEEK through the Space. enactment: One proposes mapping to project planning tools. Model Transform Deploy Operate However, this does not support automated adaptation to «generate» «input» j BPM Engine SEWL Activiti Activiti Engine «input» changing project contexts during project execution. The Template «generate» Workflow other proposal is to use the Process Behavior package to SEWL Editor «input» Generator «generate» j BPM Workflow Process Manager Space relate SPEM process elements to external behavior models «events» using proxy classes. Both approaches lack full workflow «input» «generate» CoSEEEK «events» SEWL modeling and executability at the level of BPMN. Ontology Diagram «generate» «input» Other work related to enactment of SPEM includes eXecutable SPEM (xSPEM) [17]. Process execution is Figure 1. Solution concept. addressed via transformation to the Business Process Execution Language (BPEL), while process validation is Model. One primary principle of the approach is that addressed via transformation to a Petri net in combination SEWL workflows always remain the reference point of truth. with a model checker. [18] maps SPEM to the UML In the process modeling phase, a graphical SEWL Editor Extended Workflow Metamodel (UML-EWM) in order to assists the process modeler in creating the textual SEWL create a concretely executable workflow. [19] and [20] workflows, which maintain the essence of workflow investigate transforming SPEM to BPMN, while [21] maps concepts. Supplemental graphical diagram information SPEM to XPDL. xSPIDER ML [22] is an extension profile (position, font, color, etc.) is retained in separately of SPEM 2.0 to enable process enactment. maintained diagram files, which are kept in sync with the The novelty of our solution is that, in contrast to the SEWL workflows during the Transform phase. Manual above approaches, it targets a simple graphical as well as editing of the XML-based SEWL format is thus also textual SE process language and notation for modeling, possible, however, the Generator will remove all non- blending the strengths of BPMN and SPEM; it concretely applicable elements from the graphical diagrams. Further generates executable workflows on different WfMS targets; details are provided in the next section. and it generates an OWL-compliant ontology of SE concepts Transform. In the Transform phase, workflow templates for context-aware PCSEE tooling support. This addresses for the WfMS are generated as shown in Figure 1. The prior hindrances and challenges for modeling and integrating Generator also semantically transforms SE concepts in the SE workflows in SEE. workflow to produce an OWL-DL compliant ontology that it utilized for process contextual awareness by CoSEEEK. III. SOLUTION Table I shows the mapping of concepts, whereby WUC Figure 1 will be used to describe the solution concept. stands for Work Unit Container and WU for Work Unit. The The four SE process phases shown at the top will be primary difference between jBPM and Activiti is that in referenced in the solution description below. The basis of the Activiti loops are typically expressed via inclusive gateways, solution concept is the SEWL workflow. A SEWL workflow and in jBPM via exclusive gateways. E.g., any concurrent is modeled, either with the graphical SEWL editor or a tasks in an SE workflow would be modeled with the BPMN textual editor, and provided as input for the Generator. To parallelGateway, which activates all branches transform the input, the Generator utilizes various adapters simultaneously and, when merging, waits for all branches to that generate appropriate workflow templates tailored for a complete. Most WfMS support such basic features. specific WfMS while concurrently providing OWL-DL [23] output of semantic concept instances. These templates are TABLE I. MAPPING OF SE AND WORKFLOW CONCEPTS then deployed. During operations,