If you have made diagrams using AgileJ StructureViews and switched through the various Diagram Styles which come as standard you will have seen how the amount of information shown can vary, and the way in which elements are displayed can change.
When a diagram is switched to a particular Diagram Style, that Diagram Style is responsible for providing the display rules for all elements on the diagram. In other words, before the diagram displays each element, it asks the current diagram style 'how would you like me to display this?' (see sequence). If the element is a class, the response will be a Class Display Style, and so on for fields and methods.
Inside the Diagram Style each of its Element Bindings is tried in turn until a match is found. If none of the Element Bindings matches the element about to be drawn, then the inherited Diagram Style is tried.
So creating a Diagram Style is largely about drawing upon the Element Sets and Element Display Styles which we have at our disposal to describe how we would like elements to be displayed.
Before we start creating Element Bindings there are just a few attributes on the Diagram Style itself to consider.
There is a Diagram Style defined in the standard profile which is the default. All new diagrams are initially assigned this style. When a diagram is opened, if its last used Diagram Style cannot be located anywhere in the profile (because that Diagram Style has been deleted or its project has been closed), then the diagram editor reverts to using the default Diagram Style automatically.
To recap, as a diagram is displayed, each element is presented to the Diagram Style and the Diagram Style responds with a style describing how to display the element. If the element which was presented was a class, then the response should be a Class Display Style. If the element was a field, the response should be a Field Display Style; and the same for an initializer or a method. There is nothing in the profile editor which enforces this - so care is needed to make sure the appropriateness of the binding.
Under normal circumstances, if you choose one of the standard Diagram Styles as the inherited values of your Diagram Style, the Line Bindings which come with it will be sufficient. If you would like to mark out relationships between particular sets of elements, you can define your own Line Style and create a Line Binding.
As well as there being bindings to match elements to display styles, there is another kind of binding which controls the type of line to draw between classes.
A Member Order has two concerns:
1. to place dividers between groups of members in a class (for example to group fields in one box and methods in another).
2. to get the members of a class to appear in the required order.
A Member Order has no attributes other than its id. It is an ordered collection of Member Divisions.
For each Member Division, a box is created in the members area of a class as it is displayed. A Member Division has a single attribute visible members which references an Element Set to use as a filter for the members which are to be placed in this division. Note that there are no attributes for controlling the order in which members are shown, this is handled by a list of Order By child Profile Parts.
An Order By simply gives precedence to elements which belong to a particular set, as indicated by the set attribute. Members are sorted by the Member Division by asking the Order Bys in turn to compare pairs of elements. If the two elements both belong to the same Element Set, the qualifier attribute is used to determine the rank. The qualifier options are name which gives precedence by string comparison of the names, and source which respects the order in which the elements are declared in the source code.
