Balancing Security and Performance Properties During System Architectural Design
Bibliographic record
Abstract
Developers of critical systems need to address several quality properties, such as security and performance, in the early stages of the development cycle to ensure that the system under construction meets its requirements. Sometimes quality properties conflict with each other and/or with the system’s functionalities, so the developers need to make trade-off decisions. Unreasonable costs, added developer resources and tight project schedules may be other reasons for having to trade-off between alternative solutions. In the context of Model-Driven Development, the analysis of quality properties is done by transforming software design models into different analysis models based on various formalisms, which are then analyzed with existing tools. A major challenge is to integrate different models, transformations and tools into a consistent and coherent process. In this chapter the authors present a methodology called Aspect-Oriented Risk Driven Development (AORDD), which integrates the analysis of two quality properties, namely security and performance, into the development process of critical systems. Each quality property is analyzed separately, and then all results are input to a trade-off analysis that identifies conflicts between the properties. Trade-off analysis aims at supporting designers and developers in choosing the security and performance solutions that best fit their needs, without introducing unacceptable development delays or costs. The security analysis consists of identifying the assets (critical components, such as sensitive information) of an application and the attacks that can compromise these assets, and formally analyzing whether these attacks are actually possible using the tools UML2Alloy and Alloy Analyzer. If the system is vulnerable to the attack, some security solution, modeled as an aspect according to Aspect Oriented Modeling (AOM), is added to the system. The analysis must be repeated to ensure that the resulting system is secure. Performance analysis is accomplished using Layered Queuing Network (LQN) models. Annotated system models are transformed into LQN models and performance experiments are executed on them. If the performance results are unacceptable, the system design has to be changed and the analysis repeated. Finally, the results of the security and performance analysis are input to the system quality property trade-off analysis, which is implemented as a Bayesian Belief Network (BBN) topology, and which also takes as input external parameters, such as time to market and budget constraints. The results of the trade-off analysis help identify how well a particular design meets performance, security and other project goals, which, in turn, can guide the developer in making informed design decisions. The approach is illustrated using a transactional web e-commerce benchmark (TPC-W) originally developed by the Transaction Processing Performance Council.
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.014 | 0.019 |
| Meta-epidemiology (narrow) | 0.001 | 0.002 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.002 | 0.001 |
| Science and technology studies | 0.002 | 0.002 |
| Scholarly communication | 0.005 | 0.004 |
| Open science | 0.001 | 0.002 |
| Research integrity | 0.001 | 0.002 |
| Insufficient payload (model declined to judge) | 0.001 | 0.000 |
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".