Software Performance Engineering (SPE)

The following figure schematically represents the typical steps that are executed at a generic phase of the software lifecycle to conduct a model-based performance analysis process. Hence, a round-trip Software Performance Engineering (SPE) process is schematically represented.
The roud-trip process is composed by two sub-processes, namely the forward and the backward paths.
The forward path starts from a Software Model which is transformed, by means of a Model2Model Transformation, into a Performance Model that can be solved with common performance analysis techniques/tools (see Model Solution) to obtain Performance Indices (i.e. response times, throughput, and device s utilizations).
The backward path consists of a Problems Detection & Solution step that processes performance indices, in conjunction with the software artifact and/or the performance model, to detect and remove possible sources of performance problems. Hence, a set of Refactoring Actions (e.g. split a software component in two components and re-deploy one of them) that may apply to the software artifact and/or the performance model is obtained. This round-trip process is reiterated until satisfactory performance indices are obtained.

The SPE process.

The problem tackled in my Ph.D. studies is to interpret performance analysis results and to introduce automation in the backward path, in the form of refactoring actions that do not suffer of the original performance problems. Such automation provides several gains since it notifies the software designer of the interpretation of the analysis results. Performance issues and subsequent architectural emendations aimed at removing such issues are outlined without the intervention of performance experts. We believe that both the software and performance models represent suitable instruments that can be refined accordingly to the feedback we provide, while the development progresses, thus to act early in the software lifecycle.