Consider the case of a DSL for 'Service Contracts' of a web service.
One part of the 'Service Contract' are the 'Data Contracts' used to define the parts of 'Message Contracts'. 'Message Contracts' are used as the request and response types for 'Service Operations'. Each 'Service Operation'
has a single request parameter of type 'Message Contract' and a response type of 'Message Contract'. A 'Service Interface' is composed of several ' Service Operations'. The 'Service Contract' as a whole include the 'Service
Interfaces' and the 'Message Contracts'.
This can be represented in the domain model as follows:
The designer of the DSL decides that to represent 'Data Contracts' as individual shapes on the diagram with all their 'Data Fields' would mean a lot of shape clutter. Considering also that other shapes for 'Service Interfaces', and 'Service
Operations' maybe more important aspects of the domain to display, the designer decides to represent 'Data Contracts' as line items in a compartment shape instead.
The problem now becomes how to suitably configure 'Data Contracts'? Considering they have many fields, a recursive structure, and multiple properties to define for each field?
Currently, the only user experience provided out-of-the-box for configuring these model elements is navigating the 'Model Explorer' with the 'Properties Window', and configuring each 'Data Contract' field-by-field and property-by-property.
Clearly this is a very mouse intensive experience.
In this domain, a 'Data Contract' is roughly an XSD definition, composed of multiple 'Fields' (XSD Attributes) and multiple 'Groups' (XSD Elements), each Group is further composed of multiple sub-Fields and multiple sub-Groups (recursively).
- Each 'DataField' has a number of key properties such as its name, data type, and comments.
- Each 'DataGroup' has a name, comments and whether it’s repeatable (collection or subgroup).
This recursive relationship can be seen here:
The example below of the ‘Contracts and Entities Editor’
displays the composition of 'Data Contracts', in their hierarchical structure defining 'Data Fields' and 'Groups'.
With this editor, the user experience is greatly enhanced, since it requires no mouse actions to create, edit or modify Fields or Groups - this can all be done with keyboard navigation around this editor.
The editor exposes model elements in the domain model that don't have a representation on the diagram, and their hierarchical relationships - this considerably reduces diagram clutter.
Furthermore, the user can, at a glance, browse all instances of 'Data Fields' and 'Groups' for a particular 'Data Contract', and scan instances of them and compare their properties for errors or discrepancies very quickly.
Without this editor, these types of tasks are intensely manual with the 'Model Explorer' and 'Properties Window', and neither of these controls give a comparative overview of all the fields.