During development, there is practical a need to specifically expand only a number of artefacts. Being able to selectively expand a subset of all the files has a number of advantages:
- Time of expansion is reduced. In large projects with often more than a 100 elements, this can be significant.
- Because less files are touched after expansion, build engines like maven have less trouble only compiling the files that have actually changed.
- Expander developers may want to test a specific use case without requiring a complete expansion.
Expansion goal: All
The simplest goal, and the one that is expected to be the default, is to expand all artefacts of all elements.
Expansion goal: specific element
The reverse of the
All goal would be to only expand 1 element. E.g. the user could input something like:
expand --model tutorialComp::Invoice
Invoice is a data-element. The element is referenced by its qualified name. The use of this name is to uniquely define the element within the scope of the entire project by defining its specific element name in addition to its parent ‘elements’, in this case only the component.
Children of a specific element
The expansion of a specific element will still entail the expansion of its child elements. E.g. when expanding the data element
tutorialComp::Invoice, the user will also expect the Expanders to expand its projections, such as
This means that the filtering function filtering the valid targets for expansion, when asking “should I expand this element?” should return true if the questioned element is a child or descendant of the target element.
shouldExpand(element) <=> element ⊆ targetElement
Implementation-wise, the qualified name provides an easy way to check this descendancy:
element ⊆ ancestor <=> (element = ancestor) || (element.qualifiedName.startsWith(ancestor.qualifiedName + "::") )
Note that the rather odd
+ "::"is added to prevent e.g. InvoiceTaskStatus being a seen as a child of Invoice
Expansion goal: enumeration of specific elements
Similarly, expansion on multiple targets will be required. In essence, the same result could be achieved by running multiple expands in sequence. However, in order to minimize the number of scripts being built around the expansion, it may be prudent to expose this functionality as an expansion goal.
User input would look like:
expand --model tutorialComp.Invoice,tutorialComp.InvoiceSender
We can extend the description of shouldExpand for multiple target elements:
shouldExpand(element) <=> ∃ targetElement ∈ expansionGoal: element ⊆ targetElement
Expansion goal: filter element types
On top of expanding specific elements, it could also be possible to filter elements by type.
Let’s say the user can expand only data-elements with the following syntax:
expand * --type dataElement
Or multiple type filters:
expand * --type dataElement,taskElement
This also makes it possible to, for example, only expand the finders of a specific data-element:
expand --model tutorialComp::Invoice --type finder
Whereas the filtering on element allows vertical filtering in the model, the filtering on type can add horizontal filtering to pinpoint specific targets.
When applied, each element should only be expanded if the element is both a descendant of a target element and of an element type as defined in the expansion goal.
shouldExpand(element) <=> ∃ targetElement, targetType ∈ expansionGoal: (element ⊆ targetElement) ∧ (element.type = targetType)
∧represent a logical AND