1 Introduction

A "model" refers to an abstract description of the composition and relative dynamic behaviour of the sub-parts of some system

This specification describes an XML representation of such a model, to be used as reference for more specific model types

Definitions

The presence of each of non-model elements appearing, verbatim, in a model document causes the creation, at run-time, of a corresponding "artefact", situated within the implementation's run-time environment, each of which are then transformed, in some way, due to the presence of one of more (possibly nested) model elements

There are several attributes common to all model elements

Related elements may possess a "constraint" attribute constraining the element's relationships to other elements, as expressed by an XPath expression evaluating to a non-zero value when the constraint holds

The model itself consists of any nested combination of the following, beneath a top-level "model" element (each of the items below will be further discussed when introduced below)

• Type Hierarchy
• Component compositing
• Partitioning
• Imperative Execution
• Object group stereotyping
• Inter-process synchronisation
• Message timing and sequencing

4.3 Partitioning

The (possibly nested) "partition" element isolates run-time artefacts generated by declarations in the sub-tree of the element from artefacts outside the sub-tree

The following example demonstrates three partitioned elements having tags "a", "b" and "c" isolated from a second partition containing both an element with tag "d" and a sub-partiton containing elements with tags "e" and "f", respectively

<partition>
    <a />
    <b />
    <c />
</partition>
<partition>
    <d />
    <partition>
        <e />
        <f />
    </partition>
</partition>

4.4 Imperative Execution

The term "imperative Processing", as specified in the "process" element, refers to a set of "imperative statements" transforming, at run-time, a stream of artefacts arriving on the designated the "input stream" of that process (as specified by the element the ID of which forms the value of the "in" attribute), then output to the element referenced in the value of the "out" attribute

A "stereotype" creates a "template" instantiated, at run-time, by a group of objects, each fulfilling named "roles" within that stereotype

The template for the stereotype itself is established by the appearance of a "stereotype" element containing one or more "role" sub-elements, each containing a "name" attribute, the value of which names the role, and a "matches" attribute, the value of which contains an XPath expression constraining the location and/or nature of the role within the stereotype

This XPath expression, the context node of which is set to the element in on which the "stereotype" attribute is located, is augmented with a "model:role" function returning the node bound to the role, within the stereotype having the name passed in the function's first argument

The following example illustrates a "family" stereotype, whose "mother" role is constrained to be a female whose children include the "son" or "daughter" role in the stereotype, whose "father" role to a male constrained in the same manner, whose "son" role is constrained to be a male whose father or mother has the "father" or "mother" role in the stereotype and whose "daughter" role as a female constrained in the same manner, instantiated by two elements denoting a mother and father, and two denoting a son and daughter

<stereotype xml:id="family">

    <role name="father" matches="person[@gender='male']
          and (person/@mother is model:role('mother')
          or person/@father is model:role("father'))" />

    <role name="mother" matches="person[@gender='female']
          and (person/@mother is model:role('mother') or
          person@/@father is model:role("'father'))" /> 

    <role name="son" matches="person[@gender='male']
          and (person/child[model:role('son')] or
          person/child[model:role('daughter')])" />

    <role name="daughter" matches="person[@gender='female']
          and (person/child[model:role('son')] or
          person/child[model:role('daughter')])" />

</stereotype>
 
<group stereotype="#family">

    <person xml:id="john" gender="male"
                             role="father" >
        <child>
             <person xml:id="emily"
                           gender="female"
                           erole="daughter"
                           father="#john"
                           mother="#jenny" />
            </child>
            <child>

                <person xml:id="tom"
                       gender="male"
                       role="son"
                       father="#john"
                       mother="#jenny" /"&;gt
            </child>
        </person>
        <person xml:id="jenny" gender="female"
                                  role="mother" />
            <child>
                <person xml:id="emily"
                        gender="female
                        role="daughter"
                        father="#john"
                        mother="#jenny" />
            </child>
            <child>
                <person xml:id="tom"
                       gender="male"
                       role="son"
                       father="#john"
                       mother="#jenny" />
            </child>
    </person>
</group>

4.6 Inter-process Synchronisation

This aspect of the model refers to the capability of a process to wait to start until signalled by the process identified by the content of the element's "wait_on" attribute, and to notify when completed the process identified by the content of the element's "notify" attribute.

The following example illustrates two elements, the first of which waits got the second to complete which, itself, notifies the first on completion

<a wait_on="#a" xml:id="b" />
<b notify="#b" xml:id="a" />

The timing of messages between objects and the relative order of these messages is specified through use of the "messaging" element

Within this element are located a "path" element, the children of which identify the path of the messages, followed by a set of "message" elements, each identifying a message along that path

The children of the "path" element collectively identify the path of run-time objects, within the model, for which messaging is specified, while each "message" sub-element represents a single message along that path, to be referenced by certain timing- and sequencing-related attributes of the remaining elements

The "starts" attribute of such an element references the message creating, when received, the run-time object corresponding to the element on which the attribute appears, while the value of the "ends" attribute destroys the analogous object

The value of the "delay" attribute specifies the delay, in seconds, between the sending of the message and the creation or destruction of the object

The value of the "after" attribute references the message that must may only be sent after the run-time object has received the message referenced in the value of the "ctx" attribute, while the value of the "before" attribute references the message that may only be sent before the analogous message has been received

Similarly, the value of the "delay" attribute specifies the delay, in seconds, between the the receipt of the message and the message before or after it must be received

The following example demonstrates a path of three elements the first of which must creates start the second, the first of which may only be sent after the second, with a delay of 4 seconds

<messaging>
     <path>
        <a xml:id="a" />
        <b xml:id="b" />
        <c xml:id="c" />
    </path>
    <message xml:id="x" />
    <message xml:id="y" />
    <a starts="#y" />
    <b after="#x" ctx="#y" delay="4" />
</messaging>

References