Model Driven Engineering (MDE) considers models as a key artifact in software processes, and focus on the creation of models and transformations between them in order to (semi) automatically generate code. In this paper, we step back and consider the software process model itself as a key artifact that can be enacted and semi automated. We support our vision by proposing an architecture for a cloud-based software processes modelling and enactment environment which integrates software development tools and maintains repositories of modelling artifacts and the history of development.
As software systems are becoming more pervasive, the complexity of these
systems has been increasing and the notion of systems of systems has been adopted.
This complexity makes producing software systems a di cult task due to the
increasing gap between the problem and the software implementation domains [
Models are used in most engineering domains to provide abstraction from the real world. In software systems, models are used for di erent purposes such as: documentation, testing, static analysis, and code generation. The use of models helps in representing the problem in a systematic way and displays the right amount of details for di erent perspectives and at di erent stages of development.
At the same time, the cloud computing paradigm has evolved to simplify
organizational IT management and maintenance and cut both operational and
expenditure costs. Cloud o ers computing resources on demand using di erent
service models (infrastructures, platforms, and software) and di erent
deployment models (public, private, community, and hybrid) [
As the cloud is being widely adopted by both research and industry,
researchers have started investigating the potential of using it for some
software development phases (especially the computing intensive ones e.g.
testing) [
MDE is centred around the creation of models and their relevant
transformation techniques in order to automatically generate parts of models or code
from other models. Typically, the focus is on modelling of individual phases of
the software development process. In [
The rest of the paper is structured as follows: a background discussing the use of cloud for software development and software process modelling is established in section 2. Section 3 describes the general architecture for our cloud-based software development platform. The paper concludes with a brief summary of future work. 2 2.1
Today, Global Software Development (GSD) has become a popular development
model where teams are distributed (sometimes across continents) and use
different sets of tools to support and manage the development process. Developers
have their own computers and need to have the tools that they need installed and
con gured. In addition, each team needs access to shared repositories and
collaboration tools. The distribution in GSD brings multiple challenges to software
development processes such as: restricted communication, less shared project
awareness, and inconsistent builds [
Cloud's accessibility facilitates distributed development by providing a shared development environment (artifacts and tools). Furthermore, cloud can bridge the gap between development and deployment environments. Having a virtually unlimited pool of resources in the cloud helps in allocating su cient resources to certain heavy computing software development tasks (e.g. model checking or testing). Eventually, using the cloud to support software development processes will help software teams to focus their e orts on the core problem rather than on setting up and maintaining development environments. There are some commercial cloud-based tools that support di erent phases of the software development process such as: IDEs (e.g. codenvy 3), testing (e.g. BlazeMeter4), issue tracking (e.g. JIRA 5). However, these tools are dedicated to support one or more phases of the software development process but not the entire process. 2.2
Despite the current trend of embedding high level abstractions in programming
languages to avoid code generation bottlenecks, Several approaches to MDE have
been introduced: Model-Driven Architecture (MDA) 6, Model-Driven Software
Development (MDSD) [
Among the previous approaches, SPEM (Software Process Engineering
Metamodel) has became an OMG standard for software process modelling. SPEM is
based on the concept of interaction between Roles that perform Activities which
3 https://www.codenvy.com/
4 http://www.blazemeter.com/
5 https://www.atlassian.com/software/jira
6 http://www.omg.org/mda/
7 http://www.omg.org/spec/SPEM/2.0/
consume (and produce) Work Products [
Following an enforced formal process modelling can be useful in some cases (e.g. for certifying safety-critical systems). However, in practice, it can be restrictive for the creativity of team members. Organizations have been moving to agile methods to gain more dynamicity and to increase productivity. Therefore, we propose in the next section a less formal, more exible and adhoc modelling notation than the previously mentioned approaches, with emphasis on the enactment of process models with support of an integrated tool set in the cloud. 3
As mentioned in the previous section, SPEM lacks support for process enactment. In addition, neither the extensions that are o ered by researchers for enactment support are standardized nor widely adopted outside academia. These approaches do not have a proper tool support and do not consider integrating software development tools within the enactment environment. The understanding of software process enactment in most of these approaches seemed to be limited to the concept of process simulation/monitoring. Although this notion of enactment can be useful for project management and monitoring, we think of enactment in a much broader way. Hence, we describe software process enactment as the process of performing software development activities by di erent actors within an environment that provides enactment support through the integration of development tools and automatic passing of control and data between activities. This means that unlike the approaches mentioned in the previous section, the entire development process execution takes place within one environment where tools and artifacts are available. 3.1
Software engineering process can be described as a sequence of operations
(activities) performed by development team members including customers and
managers (actors) where activities produce artifacts which are used as inputs
for other activities. This complies with The Work ow Management Coalition
(WfMC) de nition of work ow [
Based on our description of enactment and software work ows, we propose an architecture to support software process enactment in the cloud. The bene ts that software development can gain from the cloud has been discussed in section 2.1. In addition, provisioning of software development environments in the cloud with elastic resources will direct organization's resources towards solving the actual problem. Allowing third parties to integrate their tools makes it possible to try di erent tool vendors and di erent versions interchangeably without a huge adjustment e ort. The work ow enactment environment passes the execution control between activities as prescribed in the process model. Non-interactive and repetitive tasks can be automated and bene t from the elasticity of the cloud (e.g. run a distributed model checker on two nodes initially and add more nodes if necessary). The artifacts generated from each activity can be accessed by team members (as it is stored on a repository in the cloud) and will be passed to the next relevant activity as an input. Often, software processes can be reused which adds another advantage for software development rms.
The three logical layers of the proposed architecture are illustrated in Figure 1. The top layer is for process modelling where a project manager or a software developer can create/edit models for either higher level abstract processes (e.g project plan) or for daily tasks processes (e.g. implementation). The work ow management layer is where the enactment of the processes takes place while the cloud management layer handles the underlying cloud infrastructure issues (e.g. QoS and multiple cloud providers/models).
The process model contains a description of the activities involved in the process and the data and control ow information which guides the process enactment. Activities are performed by human actors and they are categorized in two types: concrete and abstract. Concrete activities can be either local or external. The local activities can be either a self-contained executable code or interactive (to input decisions or data), while the external activities are web services maintained by third parties. High level abstraction can be provided by abstract activities which are non executable activities and by default will be representing a sub-process. Activities are available in activities pool and can be either created by third party or by the development team. In general, each activity has zero or more input ports and zero or more output ports. The type of input and output artifacts that a port can accept/generate is de ned at the time of creation of the activity. This guarantees that activities can only be linked to each other when their input/output artifacts are compliant. Activities are executed independently provided that the input needed for them to execute is available. This decoupling allows distributing the execution of the process across several work ow engines (deployed potentially on di erent virtual machines on the cloud). Activities have con gurable parameters to control how the activity will be deployed and executed on the cloud. 3.2
Software processes are dynamic and unpredictable. In addition, organizations tailor process models such as waterfall or spiral di erently to meet their needs. Hence, a exible modelling notation is required. This notation needs to be (a) expressive (to express the process and its cloud execution settings), (b) executable, and (c) understandable and easy to use. The notation needs to support a combination of on the y creation/modi cation of activities for the purposes of capturing the short term/everyday development and of the longer term activities at the organizational level. Based on that we de ned the basic constructs for the software development process model. The process will be represented using a simple graphical notation that can be translated to XML which will then be used to enact the process. The graphical notation can be useful for understanding the process and training new team members. An XML schema has been de ned to map the semantics of the graphical notation. These constructs are described in table 1.
Each of the activities can be con gured to specify how it will be executed; parameters include (but not limited to): the speci ed tool support, the cloud execution requirement (e.g. on public/private cloud), and accepted and generated artifacts. For the sake of simplicity, the notation does not explicitly support modelling of actors at this stage.
Process Examples: Agile methods are widely adopted in industry as they increase the throughput. SCRUM is one of the agile methods which de nes a project management framework. This framework de nes a set of roles and a set of meetings with di erent purposes, attendees, and frequencies. Figure 2 illustrates the high level representation of a scrum sprint. This abstraction can be useful from a management perspective. However, it does not specify any details of how developers are going to implement the process. In reality, most software developers use an IDE, an issue tracking tool (e.g. JIRA), a continuous integration framework (e.g. JENKINS), and a version control system (e.g. GIT). These tools are used on daily basis to write, test, store, and integrate code. A model of the daily development process (representing the implementation sub-process) using the notation de ned in this subsection is illustrated in Figure 3. The control ow dependency between the "edit issue tracking" and "edit code" activities sets the order of execution, however, since no data dependency is included here, it allows us to perform any of the activities independently. The decision point allows to create a loop based on the decision of the software developer whether to commit his code or to change it or even to edit the issue tracking. Another example is the parallel model checking process (Figure 4) where the model checking activity can be deployed on multiple nodes to utilize the cloud elasticity in order to improve the model checking performance. 3.3
Once the process is de ned using the graphical notation described in the previous subsection (which is translated to XML), it will be validated against the process de nition schema to make sure the XML le is valid. Next the enactment service should interpret the XML representation of the process and schedule the execution on as many distributed work ow engines as required. The enactment service consists of an enactment server and multiple work ow engines. The service itself is provided as a web service which accepts requests from any type of clients (desktop, web, mobile/tablet).The enactment service consists of: { Enactment Server: responsible for managing work ow engines and provide smart scheduling algorithms to optimize cost and performance when the work ow execution is distributed across multiple clouds (if necessary). It is also responsible for monitoring the work ow execution and handling exceptions. { Work ow Engines: responsible for loading the needed tools and artifacts for executing an activity. It also reports back the execution progress to the enactment server.
{ Enactment Service API: provides a standard access to the enactment service.
Using the cloud for executing work ows requires addressing certain issues, such
as: portability and QoS of the cloud resources. Authors in [
In this paper, we proposed a cloud-based software process modelling and enactment environment which harnesses both of cloud and work ows bene ts. We considered software process model as a main artifact in the software development process. The process model can be (partially) automated and supported by development tools which are integrated within the enactment environment. We proposed the core of a simple modelling notation for modelling di erent parts of the software process. Currently, a prototype of the enactment service is being implemented to run on a single cloud initially which will be extended to run on di erent clouds later. The future work includes: assessing the modelling notation after applying it to more case studies, applying provenance to provide reasoning about the software process, and investigating possible support for interoperability between di erent tools.