Model: Connector

Optional element

In this section, the use of connectors in combination with two different naming policies is explained.

Purpose

Connectors are modeling objects that translate between two di fferent namespaces, usually caused by the use of different notations. To make an equation system or equation using notation ‘A’ usable in an equation system using another notation (‘B’), you need to specify a connector that provides all pertinent variables with a synonym complying to notation ‘B’.

It is also possible to use a connector to rename certain variables whose meaning changes when added to another equation system, e.g. if a variable’s superscript switches from “out” to “in”.

Concept of different naming policies with and without connectors

Should the brief introduction regarding the purpose of connectors be too confusing at this point, the following paragraphs will hopefully reduce this confusion. We start with the description of the two naming policies, which are available in MOSAICmodeling. Then, we show how equations (or equation systems) can change under these naming policies in combination with or without connectors.

Naming policies

We differ between two naming policies, which will be explained below.

1. Naming policy “integrate”
2. Naming policy “encapsulate”

The basic rules of the naming policy “integrate” are:

• If an equation or equation system (sub element) is added to a super equation system (super element), the sub element’s variables will get the namespace of the super element;
• If a sub element is connected to a super element, and both elements use different notations, then all variable names of the sub element have to be translated (by a connector) into the super notation;
• Attention: In any time the meaning of each variable has to be uniquely defined by the notation of its namespace. If different notations are used in sub and super element, each variable has to be translated. Otherwise the meaning of some variables coming from the sub element would be undefined in the notation (and therefore in the namespace) of the super element;
• Result: After parsing, all variables have a top level naming according to the super notation in the top level namespace.

The basic rules of the naming policy “encapsulate” are:

• If an equation or equation system (sub element) is added to a super equation system (super element), the sub element’s variables will get their own namespace;
• If a sub element is added to a super element by using a connector, only the variable names of the sub element that are translated by the connector will get the super element’s namespace;
• When considering the sub element, only the variables translated by a connector have a top level naming according to the super notation.

Combination of connectors and naming policies

We now demonstrate the concept of different naming policies with and without connectors for the equations and connectors below:

Equations:

(equation 1, namespace: e1)

(equation 2, namespace: e2)

Connectors:

(connector 1, may be applied on equation 1)

(connector 2, may be applied on equation 2)

Case A: naming policy “integrate” + connectors

In this case, the resulting equation system is:

(equation 1, namespace: e0)

(equation 2, namespace: e0)

As you can see, the policy “integrate” caused all variables to have the same namespace. The connectors renamed the variables , , and . Please note that the of the first equation and the of the second equation became the same variable in the final equation system. The final system contains four distinguishable variables (, , , and ).

Case B: naming policy “integrate” without connectors

Without connector, we have

(equation 1, namespace: e0)

(equation 2, namespace: e0)

Again, the policy “integrate” caused all variables to have the same namespace.The final equation system contains four distinguishable variables (, , , and ).

Case C: naming policy “encapsulate” + connectors

With the naming policy “encapsulate”, new name spaces are created:

(equation 1, no unified namespace)

(equation 2, no unified namespace)

The connectors renamed the variables , , and to , , and , respectively, so that they are now part of the top level namespace (e0). On the other hand, the unconnected variable, i.e., got lower level namespaces (e0e1, e0e2) as it existed in the notations of both equation 1 and equation 2. The final equation system contains five distinguishable variables (, , , , and ).

Case D: naming policy “encapsulate” without connectors

Finally, using “encapsulate without connectors results in

(equation 1, namespace: e1)

(equation 2, namespace: e2)

Now, both equations retain their individual namespaces e1 and e2. Each variable got the namespace of its original equation. The final equation system contains six distinguishable variables (, , , , , and ).

Explanation of the editor

Every connector consists of three pieces of information: The sub notation, the super notation and a variable matching list. However, there are several ways to create a connector. The standard way is to specify the sub and super notation directly and create the variable namings that need to be matched by hand. If you already have connectible elements (equations or equation systems) that you want to match, you can also load them into the connector editor. In this case, the notations and the variable namings are extracted from the loaded connected elements, which usually saves much work. The stored information, however, is still only the sub notation, the super notation and the variable matching list.