(Internal classification: anecdotical)

Reference paper: “Automating Deployment Planning with an Aspect Weaver” Jules White, Douglas Schmidt, In IET Software, To Appear

In enterprise and middleware systems, associating software with computational nodes is known as deployment planning. The challenge here is to take into account non-functional concerns (e.g. performance and security) as they may be opposing forces for the deployment plan.

ScatterML allows for the description of deployment constraints. Each component of the source code that needs to be deployed specifies constraints and effects that apply to the node which it is going to be deployed. These effects impact other components that are deployed to the same node, which gives it a cross-cutting nature.

The paper is not explicit on what's cross-cutting here. Instead the DSAL argument is made from the point of view of what an aspect weaver does. “In AOP, an aspect weaver automates the process of associating advice with joinpoints based on a set of pointcut pattern expressions. […] By viewing deployment planning as a process for associating items from a source set with items in a target set, an aspect weaver can be used to automate the process of assigning components to nodes.” Hence ScatterML is an aspect language and a DSAL due to its domain-specific nature.

• JPM: Domain-Specific : Join points are the devices on which to deploy
• AM: Domain-Specific : There is no advice specification in ScatterML

At its heart, ScatterML is a constraint specification language. A simplified grammar, taken from the reference paper (with modifications for clarity:

<SourceItem1Identifier>: { <ConstraintExpressions> }
<ConstraintExpression> = <AttributeIdentifier> <ConstraintOperator> <Value>; 
<ConstraintOperator> = (<|>|=<|>=|=)

SourceItemIdentifier is a unique ID, AttributeIdentifier and Value are unspecified in the text.

The model of the devices on which deployment is to be planned is of a similar form:

<TargetItem1Identifier>: { 
  <Attribute1>=<Value>; 
  <Attribute2>=<Value>; 
  ... 
}

An automotive domain example. The ScatterML code:

ABS{ 
Memory - 1; 
Requires:BrakeActuators; 
} 
BrakeActutators{ 
Memory - 10; 
FirmwareVendor = Z; 
FirmwareVersion > 1.2; 
} 
SteeringControl{ 
Excludes: ABS; 
FirmwareVersion > 1.6; 
} 
Infotainment{ 
Memory - 3; 
} 
GPSNavSystem{ 
Memory - 5 
}

This can be deployed on the following devices:

ECU1 
Memory = 9 
Cost = 10 
FirmwareVendor = Z 
FirmwareVersion = 1.5 

ECU2 
Memory = 12 
Cost = 16 
FirmwareVendor = Z 
FirmwareVersion = 1.9

ECU3 
Memory = 15 
Cost = 19 
FirmwareVendor = Z 
FirmwareVersion = 1.9 

The goal of the planning process is to minimize the total cost.

As no advice can be specified and pointcuts are purely declarative, the language is very restrictive. There is however a point that is not clear: various parts of the weaver rely on the implementation of extra 'adaptors' e.g. the implementation of the constraint operators. There is no mention of any verification or restriction on the work of these adaptors.

The weaver is a constraint solver that takes the ScatterML program and a set of destination nodes to produce a deployment plan.