Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
research:dsal:scatterml [2009/02/19 15:22] – created jfabryresearch:dsal:scatterml [2009/06/26 08:52] (current) – jfabry
Line 1: Line 1:
 +===== ScatterML =====
  
 +(Internal classification: anecdotical)
 +
 +Reference paper: **"Automating Deployment Planning with an Aspect Weaver"** Jules White, Douglas Schmidt, In //IET Software//, To Appear
 +
 +===== Domain of the language =====
 +
 +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.  
 +
 +===== Intent of the language =====
 +
 +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.
 +
 +===== Join Point Model and Advice Model =====
 +  * JPM: Domain-Specific : Join points are the devices on which to deploy
 +  * AM: Domain-Specific : There is no advice specification in ScatterML
 +
 +===== Anatomy of the language =====
 +
 +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>; 
 +    ... 
 +  }
 +
 +===== Typical Example =====
 +
 +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.
 +
 +===== Enforced Restrictions =====
 +
 +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.
 +
 +===== Implementation description =====
 +
 +The weaver is a constraint solver that takes the ScatterML program and a set of destination nodes to produce a deployment plan.