This paper describes an approach for user (e.g. SW architect) assisting in software processes. The approach observes the user's action and tries to predict his next step. For this we use approaches in the area of machine learning (sequence learning) and adopt these for the use in software processes. Keywords: Software engineering, Software process description languages, Software processes, Machine learning, Sequence prediction
Software processes can help us to develop and deliver (complex) software systems. Hereby, a Software Process is a set of activities in a project which is executed to produce the software system. A Software Process Description is an abstract representation of a set of software processes. A Software Process Description Language is a language to describe a Software Process Description. Software Process Descriptions differ from each other in many things, e.g. the level of detail, the domain which is supported, the paradigm they implement.
The use of Software Process Description Languages has many advantages: The clear defined syntax and semantics make a tool-based interpretation possible. In software projects this is actually used for controlling, planning, and coordination of software projects.
A lot of Software Process Description Languages have been developed. Some implement one paradigm, for example rule based languages (pre-/postconditions), net based languages (petri nets, state machines), or imperative languages (based on programming languages). Others implement multiple paradigms. There are advantages and disadvantages inherent in every paradigm:
Rule based languages have loosely coupled steps, which are flexibly combinable. The advantage is that the user (e.g. the developer, SW architect) of the process can execute the step in his own way. The disadvantage is that tool support during process execution is not possible for the user of the process. Thus, there is a lower benefit for the user.
Imperative and net based languages implement the step order directly. The step order corresponds to a generally valid order. Hereby, a tool based process execution is possible. The problem is that the order of the steps defined in the process description does not reflect the user’s working method. Our goal is to define a Process Description Language which prevents these disadvantages so that it is a) flexibly executable for the user (e.g. engineer, architect) but can nevertheless b) support the user with a tool by suggesting the next steps in the actual context. The paper is structured as follows: Section 1.1 describes the related work in the area of software process languages and sequence learning. Section 2 gives an overview of our software process description language. In section 3 our approach to assist the user during process execution is shown. Section 4 shows our evaluation. The last section is the conclusion.
Good summaries of work in the area of software process languages are [1], [2]. This paper contains approaches in the field of sequence prediction which is a subgroup of machine learning. Hartmann and Schreiber describe different sequence prediction algorithms in their paper [3]. The sequence prediction technique which is presented in this paper is based on IPAM [4] and Jacobs/Blockeel [5].
An overview paper of this work can be found here: [6].
In this section we present a short overview of the concepts of our process modeling language. This language contains only elements which are needed to assist the user during process enactment. The language does not contain other elements like phases, roles, etc. We have designed a process language based on pre-/postcondition. One key element in our language is a step which is an activity during process execution. For example there are existing steps like “Map requirement to Component” or “Specify Component”.
Every step has pre-and postconditions, that describe if the user can start or stop the step execution. Furthermore, steps can contain a set of contexts. This can be an execution context which is a subset of the product model (e.g. all classes within component c are in one execution context) or a “parameter” which describes a certain situation. This can be for example the implementation language, the used case tool, framework, the project, and so on. The number of steps is fix at project execution time; the number of contexts can vary (e.g. if a new product is added to the product model, one or more execution contexts are created corresponding to the process description). A more detailed description of our language can be found here [6].
For user assistance we have developed an approach to predict the next step the user wants to start. Our approach observes the last couple of started steps (and corresponding contexts) and tries to build a database where identified sequences are stored. Our work is based on the work of Davison/Hirsh [4], and Jacobs/Blockeel [5].
In the next subsection the results of the work of Davison/Hirsh and Jabobs/Blockked are presented.
IPAM is the work of Davison/Hirsh and addresses the prediction of UNIX commands. The approach implements a first order markov model, so the prediction which is made is based on the last observed element. IPAM stores unconditional and conditional probabilities in a database. After each observation the entries of the database are updated as follows:
observation and y=last observation. The entries w
This content is AI-processed based on open access ArXiv data.
