Expansion Goals

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

where 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 tutorialComp::Invoice::details and tutorialComp::Invoice::info.

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.

More formally:

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