Software Product Lines (SPL) are sets of software products, which differ only by which features they support. Abstract Delta Modeling (ADM) shows how to organize a code-base in a natural way by structured reuse. Then, given a feature configuration (a set of desired features), we can mechanically generate any product in the product line without having to duplicate any code.

Abstract Delta Modeling, as the name suggests, is an abstract algebra and doesn't actually say anything about code. It can be used equally well for modeling families of API documentation, textbooks or office chair designs. So I usually employ the generic term 'Product Line'.

Traditionally, a single feature configuration is chosen and the corresponding product is generated at build time. This product doesn't change during its lifetime. Dynamic Product Lines (DPL) are different. Their feature configuration can change 'at runtime' in order to meet changing requirements or environmental factors, and the corresponding product should change accordingly.

Dynamic Delta Modeling (DDM) is an extension of ADM. It describes the behavior of dynamic versions of ADM-based product lines using Mealy Machines, while staying in the abstract setting of ADM.

In this ACG talk I describe DDM, first in abstract (but informal) terms, then using the example from my paper of an automated profile manager for Android, which is currently in development. Users define rules such as "when the battery is at 20% or lower, lower screen brightness" in terms of deltas, and the app dynamically enacts these rules using DDM.

I assume that monitoring a condition for change has a cost, and that some conditions are more costly than others. I will explain how the average cost of running a DPL can be minimized by disregarding costly conditions until they become relevant, without affecting the behavior of the Mealy Machine.

I presented ADM in an ACG talk in 2010, but I will make sure my talk is understandable for people who don't know about ADM.