User-friendly approach for handling performance parameters during predictive software performance engineering
Bibliographic record
Abstract
A Software Product Line (SPL) is a set of similar software systems that share a common set of features. Instead of building each product from scratch, SPL development takes advantage of the reusability of the core assets shared among the SPL members. In this work, we integrate performance analysis in the early phases of SPL development process, applying the same reusability concept to the performance annotations. Instead of annotating from scratch the UML model of every derived product, we propose to annotate the SPL model once with generic performance annotations. After deriving the model of a product from the family model by an automatic transformation, the generic performance annotations need to be bound to concrete product-specific values provided by the developer. Dealing manually with a large number of performance annotations, by asking the developer to inspect every diagram in the generated model and to extract these annotations is an error-prone process. In this paper we propose to automate the collection of all generic parameters from the product model and to present them to the developer in a user-friendly format (e.g., a spreadsheet per diagram, indicating each generic parameter together with guiding information that helps the user in providing concrete binding values). There are two kinds of generic parametric annotations handled by our approach: product-specific (corresponding to the set of features selected for the product) and platform-specific (such as device choices, network connections, middleware, and runtime environment). The following model transformations for (a) generating a product model with generic annotations from the SPL model, (b) building the spreadsheet with generic parameters and guiding information, and (c) performing the actual binding are all realized in the Atlas Transformation Language (ATL).
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.005 | 0.023 |
| Meta-epidemiology (narrow) | 0.002 | 0.002 |
| Meta-epidemiology (broad) | 0.001 | 0.002 |
| Bibliometrics | 0.003 | 0.001 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.003 | 0.004 |
| Open science | 0.003 | 0.003 |
| Research integrity | 0.002 | 0.003 |
| Insufficient payload (model declined to judge) | 0.007 | 0.004 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".