Element adornments

[Paolo F Cantoni]

Hi,

I've been asked by Sparxians to let them have my views on customization within EA.  I've started the process by discussing Element adornments.

This is an extract of what I sent Sparx:

• Adornments should be available for both lines and shapes in consistent ways.  That is to say, the only differences should be when it makes NO sense to manipulate that property for that type of object (for example, Fill colour or texture for a line)
  
• The modeller should have complete control over rendering.  For example, don't restrict us to line formats that are UML compliant.  You've already alluded to a checker that will check for UML compliance (got some thoughts on that also...  :-))
  
• Cascading styles need to be defined (ala MS Word).  You apply styles to UML element types, UML elements or stereotypes.  Order of style (or adornment) application is apply stereotype styles, then element type styles, then element instance styles (see below for rendition)
  
• Style elements need to be marked applicable/not applicable (in this style).  That is, this style does/doesn't use a particular element.  This leaves the element available for another style to manipulate.  This is how you can use stereotyping styling to correctly render in multiple stereotype situations (one stereotype might control line-style only, another font weight only).  Not withstanding this, adornments are applied successively according to stereotype order (from left to right).  It's up to the modeller to get the required rendering by ordering the stereotypes.
  
• Style elements need to be inheritable:  For example: set, unset, inherit, reverse inherit (for Boolean values)  Note, only applies for applicable element.
  
• Adornments need to be context sensitive.  For example, I can define a particular rendition for a stereotype (its default rendition), but in a project, or  in a particular diagram (or set of diagrams) I may want to use a different rendition.  I suspect that allowing rendition override by package would do the trick...  So the order of precedence would be:  Default followed by Project followed Diagram Type followed by Package (within hierarchy).
  
• ALL of the foregoing available thorough the automation API

Comments and feedback welcome.  I'll collect the results of the topic and forward it to Sparx when appropriate.

Paolo