Modelling Complex Behaviour

As an example, consider a web application that needs to hidean Input Text Fieldif the value of a separate text field is zero, orshowthe field otherwise. This behaviour may be implemented using only ECA Rules, Parametersand Complex Termsas illustrated in Figure 5.2537. Here, an instance of a Complex Termused as aConditionfor oneECA Ruleis reused as aParameter.

However, there are a number of negative aspects that may arise when using this simplistic approach to model complex behaviour, that need to be considered.

1. Conceptually, complex behaviour would no longer be represented by an Action, but would instead be represented by the constraints operating on a particularECA Ruleas it applies to a single instance of anEvent. This has important ramifications: most importantly, it means that anECA Ruleinstance must support the definition ofmanyEvent triggers, otherwise complex behaviour must be duplicated for each triggeringEvent.

This also means that an Action would no longer represent “a specification of parameterized behaviour” as defined earlier in Section 5.4.3, but would instead represent a single form of predefined behaviour that cannot be specified by the model developer. This also means that behaviours could not be externally referenced – if the onChange and onInput events should perform the same action, for example, the behaviour would need to be duplicated.

2. As the complexity of a particular behaviour increases linearly, the complexity of eachECA Rule increases exponentially. For example, consider a behaviour which may execute one of eight different operations based on the evaluation of three boolean input variables. In this example, eightECA Ruleswould need to be provided, each with a different expression of the same input

Frame ’Using ECA Rules’>Input Text Field ’Input Field’ ! "# "# $ %& ' ( ) %& ' ) )

Figure 5.25: Representing complex behaviour within IAML using twoECA Rules

variables. This represents a significant amount of developer effort, and may result in logic errors.

3. The visual complexity of Figure5.25is a consequence of the visual notation used, where every model element has a corresponding node or edge. This issue is discussed in further detail later in Section9.3.3. A new visual notation would need to be proposed, and this notation may need to incorporate grouping related elements, a hybrid textual/visual syntax, or directly supporting event algebra [377] and behaviour composition operators.

For example, anECA Rulecould specify a textual condition “[op:numeric-equal(text.fieldValue, 0)]” on the edge, which would implement the intended logic. This approach is extremely similar to the use of OCL within UML [254], and would require the definition of a mapping between model instance elements to references within the textual syntax. However, this approach would vastly simplify the definition of complex conditions on a rule.

4. With this approach it is not possible to specify procedural-based behaviour such as loops38, or concurrency-based behaviour such as multithreading. Some procedural behaviour may be emulated using special element wrapper structures – for example, a loop may be implemented by allowing anECA Ruleto re-trigger its triggeringEvent.

38_{As discussed earlier in Section3.1.2, Fowler [102] argues that domain-specific languages should not exhibit Turing} completeness through general-purpose language concepts such as loops. IAML follows this guideline with the exception of describingActivity Operations, as general-purpose language concepts vastly simplify the implementation of domain logic.

5.8 Operations 127

5. Finally, this concept ofevent-oriented behaviourimplies that the lowest level of the hierarchical design of the IAML metamodel, as illustrated earlier in Figure5.2, would be focused on the definition of components. In order to improve the manageability of the complexity of the model instance, it may instead be desirable to support a further hierarchical decomposition into an

operation modellinglayer.

It is therefore more desirable to support modelling complex logic and behaviours within anAc- tion, than on theConditionsof anECA Rule. Two approaches to modelling complex behaviour will be considered, with respect to the modelling language development principles discussed earlier in Sec- tion2.7: the reuse of an existing textual expression language; or the reuse of a subset of UML. It is not appropriate to introduce a new form of logic into the IAML metamodel; any approach for modelling complex logic should reuse existing IAML concepts where appropriate.

Reusing an Existing Textual Expression Language

There are many existing languages for defining expressions and behaviour, and these could be used to defineOperationswithin IAML. For example, a new model element namedOCL Operationcould be added to the model, and contain an OCL operation [252]; similarly, a model element namedJava Operationcould support the execution of a method within a Java class.

The main issue with using external languages for defining expressions and operations is of the resulting implementation. For each target platform where the expression must be evaluated, either an instance of that language must be available to evaluate the expression directly, or – if there is no instance of the language in that target platform – the expression must be translated into another form where itcanbe evaluated. For example, anOCL Operationwould require an OCL interpreter for both Javascript and PHP, as discussed later in Section7.6.3.

Reusing UML Activity Diagrams

As discussed earlier in Section4.3.1, UML activity diagrams may be used to model the lower-level object and control flow of an activity. While the same behaviour may be implemented though UML interaction sequence diagrams, Bennett et al. [28, pg. 106] argue that activity diagrams are more useful to model business behaviours. Some lower-level constructs such as arithmetic are however not supported, and it is not possible to consistently translate these models into code. The metamodel specific to UML activity diagrams is also very large; at the time of writing, this included 52 separate modelling concepts, and 31 common behaviours [254].

As the intent of an IAMLActionis based upon the UMLActivitymodel element, UML activity diagrams should be well-suited towards the intent of operation modelling within IAML. UML activity diagrams allow for the complex behaviour of the example illustrated earlier in Figure5.25to be im- plemented as an independentActivity. In Figure4.8, the same complex behaviour of Figure5.25has been expressed with a UML activity diagram.

It is not desirable to directly use UML activity diagrams within the IAML metamodel due to the size of the UML metamodel. However, it would be desirable to reuse aspects of the UML activity diagram through metamodel restriction, where a smaller subset of the UML activity diagram is reused along with their concepts, and concrete execution semantics are defined for this smaller metamodel. Therefore IAML does not directly include UML activity diagrams, but adapts many of the elements and their relevant visual notations and behaviours.

Figure 5.26: UML class diagram for theActivityPackage: Operations Model