NMOD Primer Ch 3

Click here to open Figure 6 window showing Visio diagram of a model with multiple networks in it.

Node and arc notations explained in this chapter are applicable to all documents at this site.

Starting with the next chapter we will be using certain node and arc notations in this document. Those notations are described in this chapter so that you will know what they stand for when you come across them in remaining chapters. These notations are used strictly for communication purposes (in documents and execution feedback files). They are not part of the ORMSware language.

In the most generalized form, a node notation consists of the network it belongs to, the object ID assigned to it by Visio and its name given by the analyst. For example, in the node identification notation

CostPerPiece refers to the network the node belongs to, [1] refers to its object ID assigned to it by Visio and WearParameters refers to the name given to the node by the analyst. The first two components (CostPerPiece.[1]) uniquely identify any node in a model. Therefore, a node name (the third component, i.e. WearParameters in this case) need not be unique, except for clarity.

Some places in this document the same node may be referred to in slightly different ways. For example, the node name above may be referred to as CostPerPiece.n[1]WearParameters. The n after the period and before [ is to identify the object as a node. Sometimes a node may simply be referred to as n[1]. This is done only within known context, when there is no doubt as to which network/page the node belongs to or what name it was given by the analyst.

In the most generalized form, an arc notation consists of the network it belongs to, the object ID assigned to it by Visio, the name of the node from which it originates, arc Type, and the name of the node at which it terminates. For example, in the arc identification notation

CostPerPiece refers to the network the arc belongs to, [7] refers to its object ID assigned to it by Visio, PiecesPerHour refers to the name of its originating node, -->>| refers to the arc's Type, and MachineCostPerHour refers to the name of its terminating node. The first two components (CostPerPiece.[7] in this case) uniquely identify any arc in a model. NMOD tacks on the originating node, the Arc Type, and the terminating node to an arc's identification notation just for clarity.

Some places in this document the same arc may be referred to in slightly different ways. For example, the above arc may also be referred to as CostPerPiece.a[7]PiecesPerHour-->>|PiecesPerHour. The a after the period and before [ is to identify the object as an arc, though it should be obvious from the Arc Type symbol that it is an arc.

Sometimes an arc may simply be referred to as a[7]. This is done only within known context, when there is no doubt as to which page/network the arc belongs to, at which node it originates, and at which node it terminates.

Notes

1. On any given page, an object ID occurs only once. For example, on the CostPerPiece page/network, [1] will occur only once. Therefore, it is not necessary to identify it as n[1] (i.e. Node 1). Just [1] should be sufficient. We use the "a" and "n" prefixes strictly for clarity and ease of discussion. When we refer to an object as a node or arc while discussing a diagram, it is easier for the reader to locate the object, since one needs to scan only for that particular object type in the diagram.

2. If you had wondered before why we do not hide Visio object IDs from displays and use Name property values of objects instead, you probably understand now the issue of ambiguity. A useful and powerful feature of NMOD is that it permits definition of multiple arcs between any given pair of nodes. As you can see from the notation explanation above, we will not be able to uniquely identify an arc between a pair of nodes if we do not add something unique to its label made up of originating and terminating nodes and Type. Requiring the analyst to add a unique piece to the name of each arc will be putting unnecessary burden on the analyst. Requiring the analyst to add a unique label only when there are multiple arcs between a pair of nodes unnecessarily increases various complexities in the software.