• No results found

Our approach to define SDaaS is based on treating software processes as workflows.

Such workflows consist of several types of elements. In this section, we describe the main elements and their life-cycles from the time of creation until the workflow is fully executed. Software workflows consist of a set of Activities, Artefacts and Actors.

Modelling of these elements will be discussed in Chapter 3.

2.5.1 Activities types

Software workflows are complex and contain various types of activities performed by different actors. In general, these activities can be categorised into three categories:

• Automated Activities. Some activities in a software process can be supported by automated tools. Such tools will need to receive an input (in the form of artefacts and/or parameters). Examples of such activities include different types of testing, model checking and data analysis. Depending on the size of the inputs (e.g., test cases, models to verify, etc.) such activities need to handle, they might be computationally intensive and take long time to finish executing.

• Interactive Activities. Unlike the automated activities, interactive activities re-quire the involvement of actors to make decisions, provide input or perform manual tasks such as editing code and models.

• Control Points. At certain points in the software workflow, there will be a need for making decisions about the next steps in the workflow enactment. The decision could be to go back and change the process or the input artefacts or going into one of multiple possible forward paths in the workflow. For example, based on testing results, the actor can decide whether the code still need to be modified or not.

2.5.2 Interaction patterns

There are two possible types of human-computer interactions which take place in soft-ware workflows. The first is the interaction to create, edit, manage and enact softsoft-ware workflows. This can be achieved using the user interfacing tools (aka workflow client applications). Such tools can be desktop-based, web-based or mobile applications. The other type of interaction is the interaction during the execution of the software work-flow. As mentioned earlier, software workflows contain different types of activities.

Some of these activities are interactive where actors need to interact with the work-flow to provide instructions, decisions, input parameters and to edit artefacts. These activities need to have a way of sending messages and receiving responses from the relevant actors. Long interactions such as editing code or other artefacts can be done offline using the workflow client applications where the workflow enactment will be paused till the editing is finished. It is worth noting that we do not investigate the human-to-human interactions between actors in this thesis.

2.5.3 Software workflows life-cycle

In our vision, software workflows are executable and live throughout the development process. Software workflow models represent software processes. As shown in Fig-ure 2.4, they come to life after process author(s) construct(s) the workflow model using a software process modelling language (which will be discussed in Chapter 3). After being created, the workflow models can be instantiated as many times as necessary and those instances can then be enacted. Enacting a workflow model will result in the generation of new artefacts as prescribed in the model. If the workflow model needs to be adapted (e.g., for another project or to improve the process or use a different tool), the model is modified, then new instances can be created and enacted.

Software workflow instances move between three states as shown in Figure 2.5. Ini-tially, the instance is Inactive and once it starts to be enacted, it becomes Active. After completing the execution of an instance, the state becomes Completed. The completed state indicates that the execution of an instance has terminated either successfully or not.

Chapter 2: Reference Architecture for Software Development as a Service (SDaaS)

Produces

Workflow Authoring

Workflow Instantiation

Workflow Enactment

Model

Instance 1 Instance...

Instance N

Artefacts

Figure 2.4: Workflow life-cycle

Inactive Active Completed

Figure 2.5: Workflow instance life-cycle states

2.5.4 Activities life-cycle

Software workflows consist of a set of activities. These activities are executable and they can be custom-made tools/applications or standard CASE tools. They are inte-grated to the SDaaS architecture (stored in the artefact repository) and are executed when a workflow instance containing them is enacted. During the workflow instance enactment, the activities status change between five states. As we can see in Figure 2.6, an activity is initially in the Inactive state which means that it has not become ready to execute yet. The Ready state indicates that the activity is now ready to be executed which means that all its preconditions (availability of input artefacts/parameters) have been met. Once in the Ready state, the scheduler of the enactment service will allocate the activity to a suitable workflow engine by placing the activity in the jobs queue of that engine. The activity is now in the Queued state. Once the engine becomes free and starts executing the activity, the state of the activity becomes Active. The Completed state means that the activity has finished execution (either successfully or not). Failure to execute an activity will result in termination of the process instance execution.

Inactive Ready Queued Active Completed

Figure 2.6: Activities life-cycle

2.5.5 Artefacts life-cycle

Artefacts are consumed/produced by activities while a workflow instance is being executed. In addition, artefacts can be created offline by actors and provided as input for activities. In some cases, artefacts will be edited by actors or activities during workflow instance execution. The new modifications are stored as a new version of the same artefact. Figure 2.7 illustrates this cycle.

Artefact Creation (by actors or

activities)

Artefact Usage (As an input)

Editing (As an output)

Create new artefact version

Figure 2.7: Artefacts life-cycle