In iterative and agile software development, fast development cycles can outdate software models quickly, hindering their application for architecture-based quality predictions. Therefore, in this short paper, we present our envisioned generalized process to continuously manage the consistency between a software project's artifacts, the running software, and software models, enabling quality predictions and round-trip engineering.
In iterative and agile software development processes, development teams usually employ DevOps
practices, including Continuous Integration (CI) and Continuous Delivery (CD) pipelines, for fast
deployments and fast feedback [
Due to the fast changes in iterative software development [
Thus, the question raises: How can architecture-based quality predictions in general be utilized in DevOps environments? In this short paper, we present our envisioned generalized process for the Continuous Consistency-aware Quality Management (CCQM). By maintaining the consistency between diferent software models, including the software architecture, a software’s artifacts, and the running software throughout the development and operation of a software, the CCQM process enables continuous architecture-based quality predictions for quality management.
The reminder of this paper is structured as follows. In section 2, we present our envisioned CCQM process. Then, we conclude the paper in section 3 with a short outlook to a planned evaluation. 0. Iterative Software Development 3. CD
VCS Repository with Prescriptive Models 1a. CI-based Model
Transformation 4. Measurements
Running Software Descriptive Models 5. Consistency Maintenance 7b. Update
(Intermediate)
Prescriptive Models 7a. Consistency
Maintenance 1b. Consistency
Maintenance
Prescriptive Models (including Software Architecture) and (optional) Predictive Models 2. / 6. Analysis
Architecture-based Quality Prediction Legend:
Model
Data Source
Process Step
In this section, we present our envisioned generalized process for CCQM to continuously manage the consistency between software models, enabling architecture-based quality predictions throughout DevOps practices. An overarching goal is to have incremental and automated process steps as much as possible to reduce the efort and barrier for software developers. We base the process partly on the Continuous Integration of architectural Performance Models (CIPM) approach [9], to which we refer for an example realization of the CCQM process, and the MODA framework [14]. Hence, we diferentiate software models according to the three following roles [14]: • Prescriptive Models, which encompass the structure, behavior, and operational context of the software. In our context, these models include source code, deployment descriptors, configuration ifles, software architecture, and others. • Predictive Models, used in combination with prescriptive models to predict quality attributes in alternative and future states. They can realized by, for instance, annotations in prescriptive models. • Descriptive Models, which represent a software’s runtime and a software at runtime. Here, we consider descriptive models solely as models of measurements (e.g., performance metrics, traces, or logs) taken from the production environment by monitoring the running software.
Figure 1 depicts the CCQM process, its steps, and how the models in their diferent roles are connected. The numbering of the process steps presents one possible sequence. Nevertheless, in reality, the diferent steps can be executed in varying orders and concurrently. In the following, we describe the process steps, grouped in four sub-processes for clarity, on a rather abstract level to allow adaptations, potentially needed for concrete realizations.
CI-based Consistency during Software Development CCQM during iterative software development (step 0) mainly concerns the consistency between prescriptive models on diferent abstraction levels. Thus, in step 1a, a CI pipeline reads the recent changes from a version control system (VCS) repository. Even though the artifacts in the VCS repository (e.g., source code or deployment descriptors) are prescriptive models, we do not directly utilize them for the consistency maintenance. Instead, we automatically parse and transform the artifacts and their changes so that all prescriptive models can conform to the same meta-metamodel (e.g., ecore). The resulting models can be called intermediate, bridging the gap between the artifacts in the VCS repository and other prescriptive models. In addition, this allows easier tracing of related model elements. The execution of step 1a does not necessarily need to be accomplished after every commit in the VCS repository. Software developers can schedule the execution (e.g., after a certain number of commits) or trigger it manually.
The changes of the (intermediate) models trigger the consistency maintenance in step 1b towards the other prescriptive models, mainly the software architecture. This step employs change-based, incremental model transformations to update model parts that are afected by the changes in the VCS repository. These transformations can be defined as rules on the metamodel level, analogous to the CIPM approach [9]. Step 1b should also be fully automated to be able to run in a CI pipeline. However, there are cases, in which input from software developers or architects is required. Thus, open questions remain: How can manual actions be separated from a CI-based execution, to which extent are manual actions required, and how can the manual efort be reduced? As the (intermediate) models can contain information relevant for the predictive models or quality predictions, step 1b can also target predictive models, specific parts of them, or annotations to be able to preserve these relevant information. In this context, an open question is how targeted quality attributes influence the consistency maintenance and preserved information. Steps 1a and 1b represent the reverse engineering of the software architecture [15]. If there is already a software architecture, it can be either incorporated into the prescriptive models [10] or created from scratch by the CCQM process (e.g., for checking the consistency between the existing and newly created software architecture). Based on the consistent software models from steps 1a and 1b, architecture-level quality predictions can be performed (step 2).
Consistency during Software Operation During software operation, starting with the CD pipeline (step 3), the CCQM process aims to automatically maintain the consistency between the running software and its models. Therefore, measurements from the running software are incorporated into the descriptive models (step 4). An open question is how to connect existing monitoring tools and infrastructure with this step. Since we consider here only models of measurements as descriptive models for their explicit modeling, we assume that the measurements are only appended to the descriptive models, which do not change otherwise. Afterward, the actual consistency maintenance can be automatically executed to update corresponding prescriptive and (optionally) predictive models (step 5), for example, performance parameters in CIPM [9]. It is configurable when step 5 is triggered, analogous to step 1a. Beside manual executions, automatic triggers encompass specific changes and thresholds for certain change characteristics, for instance, when a predefined time frame or number of changes has passed. As a consequence of the consistency maintenance, the software architecture can reflect the production environment accurately, and quality predictions based on an up-to-date state of the production environment can be performed (step 6). While it seems that there could be conflicts or collisions when maintaining the consistency between software models with changes from development and operation, the software models, the software architecture, in particular, or the CCQM process should be able to handle and reflect the diferent aspects by, for instance, providing multiple versions and variants of the models. This enables analyses for diferent development and operation states. Forward Engineering during Software Development As last step, the CCQM process allows changing the prescriptive models, especially the software architecture, in response to prediction results (automatically) or software evolution (manually). With these changes, the consistency maintenance in step 7a can semi-automatically update the prescriptive models (e.g., source code models), resulting in forward engineering [15]. To close the process, the artifacts in the VCS repository are changed according to the updated intermediate prescriptive models (step 7b) by automatic model transformations. Although the CCQM process contains both forward and reverse engineering, efectively enabling round-trip engineering [16], it is also possible to only realize one, either reverse or forward engineering. Architecture-based Quality Predictions The most important part of the CCQM process is the architecture-based quality predictions in step 2 and step 6. All previous steps ensure that the required software architecture models and optionally relevant prescriptive, predictive, or descriptive model (parts) are consistent with the running software or development state. Using these consistent models, existing analyses and prediction approaches can be applied. As their concrete application varies, we do not further specify steps 2 and step 6. As an example, the performance predictions in the CIPM approach directly operate on the software architecture, enriched with performance parameters [9]. In contrast, an approach by Cortellessa et al. [4] for availability defines a round-trip process: the software architecture is transformed into a specific analysis model, from which the analysis results can be transferred back to the architecture.
In this short paper, we presented a generalized process for the continuous consistency management of software models, enabling architecture-based quality predictions throughout DevOps practices. During software development, the CCQM process ensures the consistency between artifacts in a VCS repository and mainly the software architecture. During software operation, the CCQM process maintains the consistency between the running software and its models. Based on the consistent models, architecture-based quality predictions can be performed.
In future work, we plan to evaluate our envisioned CCQM process regarding its (1) suitability and (2) applicability for diferent architecture-based quality predictions. For the (1) suitability, we want to conduct interviews with researchers in the domain of quality predictions to find out how well analyses can be embedded into the CCQM process and which (potential) additional features need to be considered. While we have a concrete realization of the CCQM process within the CIPM approach for performance [9], we plan an additional application of the CCQM process for a diferent quality attribute.
This work was supported by funding from the pilot program Core Informatics at KIT (KiKIT) of the Helmholtz Association (HGF), by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) - SFB 1608 - 501798263, and by KASTEL Security Research Labs.
The authors have not employed any Generative AI tools.