Programs, like people, get old. The same is true for models, which can become obsolete due to a diversity of factors such as changing requirements, data drift or evolution of the domain itself. Preventing or addressing obsolescence as early as possible helps to reduce the significant costs, risks, and uncertainties incurred by obsolete models and the software system generated from them. Indeed, obsolescence in models can easily propagate to errors in the system resulting in behavioral uncertainty marked by unforeseen, emergent, or unpredictable behavior.

Nevertheless, methods and strategies to identify, anticipate, minimize, and manage model obsolescence are presently lacking. We present an innovative approach to tackle model obsolescence. We have designed a domain-specific language (DSL) to specify potential aging and degradation conditions for model elements. Based on the DSL annotations and the history of changes in a model, we can pinpoint those elements that require validation or risk becoming obsolete. Both the DSL and the engine to calculate the obsolescence status of the elements in a model have been released as part of the open source BESSER modeling platform, in particular, check the model obsolescence repository.

You can learn the full details of our Modeling the obsolescence of models paper (open access). But keep reading for a summary.

Overview of our model obsolescence solution

We have designed an obsolescence DSL to express the rules at design time and an obsolescence engine able to execute such rules and alert designers when elements become obsolete and should be revised.

The next figure presents an overview of our approach and its main components in two main stages: design-time for the specification of obsolescence rules applied to a domain model, and lifespan model monitoring for the continuous evaluation and reporting of model obsolescence

Overview of our obsolescence approach

Overview of our obsolescence approach, comprising both the design-time and run-time components

 

Modeling obsolescence policies with our DSL at design-time

The design stage involves specifying the conditions or rules for obsolescence. As seen before, the designer provides both the Domain model and the set of obsolescence rules (Obs rules model) that govern it (step 1 in the previous figure). The Obs rules model consists of a set of different types of obsolescence conditions defined following a DSL we have defined for this purpose. See below the metamodel and grammar (for the concrete syntax) to define obsolescence rules.

 

Obsolescence metamodel

Metamodel of our obsolescence DSL

Grammar of our textual notation

Grammar to declare the obsolescence rules impacting model elements

With this DSL you can define three types of obsolescence rules.

  1. Temporal obsolescence: rules that occur when a deadline is reached, either defined as a fixed or a recurrent period (i.e. to state that a certain model element should be revised every 6 months)
  2. Data-Driven obsolescence: model elements representing data to be processed by the system (e.g. streaming data) may become obsolete if the data schema changes. With this type of rule, we can specify the discrepancy that should trigger a model review.
  3. Internal obsolescence: it enables the specification of dependencies of model elements, stating what elements should be reevaluated if other elements change based on arbitrary conditions.

For all rules, we can also specify the criticality of the rule and the propagation behaviour, i.e. how the rule should partially impact as well elements that are linked to those requiring a review). Via this propagation, it may happen that an element that has not been directly triggered by a rule needs to be reevaluated anyway as many of its neighbours have been impacted.

Runtime evaluation of the potentially obsolete model elements

Based on the above rules, model elements are continuously monitored to detect model elements that need to be revised and alert the designer so that he can confirm whether the elements are still valid or need to be updated. Once done, the “obsolescence counter” for that elements is reset. The revisions and changes done to the element are also stored for traceability purposes.

This “obsolescence” counter is added to all the model elements and it is increased every time a new rule affecting the element is triggered (e.g. arriving to a certain date for elements linked to a temporal obsolescence condition).

Runtime metamodel extension to monitor the obsolescence

Based on this information, the designer can request at anytime the generation of an obsolescence report, listing all the elements that should be reviewed ASAP.

Result of the generated obsolescence report

Result of the generated obsolescence report

Further work

As further work, we will enrich the obsolescence DSL by adding the possibility to state the designer’s subjective opinion on the (un)certainty of the obsolescence annotations and the possibility to take into account the designer profile (e.g. their expertise) as a factor in the propagation of obsolescence values.

We will also study the application of our DSL to other types of artifacts (even code itself could be a target) and models, such as machine-learning models. ML models could benefit from an adaptation of our DSL to help experts identify and alert of potential drifts in the ML model. We also plan to improve our tool by adding support for additional types of rules in the obsolescence evaluator engine, such as interpreting obsolescence conditions expressed as OCL constraints.

Finally, we aim to implement automatic maintenance techniques for models. These techniques will automatically correct, prevent, or improve model elements when they become obsolete. However, it is essential to ensure that updates to the model are reflected in the corresponding software artifacts. This could trigger a series of changes, such as updating the source code and redeploying certain system artifacts.

Want to build better software faster?

Want to build better software faster?

Get the latest news in software modeling, model-based and low-code development

Thanks for your interest. Check your inbox and confirm your subscription!

Pin It on Pinterest

Share This