NMOD Primer Ch 2

Some tools that use network diagrams to facilitate visual modeling may force the user to accept predefined level of resolution or abstraction for each node. For example, they may require one node each to define an expression (i.e. a constant, variable, function or a combination of the three). Some do not permit creation of new data structures, performing of array operations, use of pointers, etc. Such restrictions often negate the potential advantages of highly structured tools as problems to be modeled become larger and more complex.

NMOD atom is anything the user wishes it to be at any given point in a model. The user may wish to use one node (or arc) to define one variable at a certain point in a model and many variables at another. Nodes and arcs can also be used to contain, or call, procedures. When to do what is left strictly up to the judgment of the analyst.

With NMOD, users can do virtually anything one would do with higher order languages, in addition to leveraging NMOD's modeling paradigm, to move rapidly from model inception to implementation.

Click Figure 1-Revised at left to open a separate window to display an ORMSware network of our example model. After reading this chapter, if you wish, you can go through Chapter 2 (Quick hands-on tour of NMOD modeling process) and Chapter 3 (Building ORMSware networks - basics) of Hands-on Tutorial to learn to construct network-structured models using ORMSware's Visio interface.

ORMSware's current (fully operational prototype) network definition interface was developed with the Standard version of Microsoft's Visio 2002.

Looking at Figure 1-Revised window you will notice right away that the ORMSware network contains more information.

Figure 1-Revised

ORMSware network objects (nodes and arcs) have many properties, a few of which were specifically selected to be automatically displayed in diagrams. We will go through all node and arc properties relevant in NMOD later, but let us focus for now just on the properties displayed in ORMSware network diagrams.

Note: The current interface is an operational rapid proof-of-concept prototype for demonstrating the ORMSware paradigm. We have not made any attempt to use the programming features in Visio to create a shelf-ready ORMSware interface. Instead we used the fastest and easiest way to prepare an interface, within the no-programming constraint, to facilitate defining and drawing model networks and entering as much data and logic as possible through the interface.

To facilitate entry of more logic into nodes and arcs, if necessary, a data organizing scheme is available for storing all supplemental information in three ASCII text files. These files are automatically synchronized with the model's networks during ORMSware's network translation process. The planned Integrated Development Environment (IDE) will obviously work in a direct, seamless fashion.

Node display

The first three lines of node displays are automatic. Fourth line can contain nothing, or whatever the analyst wishes to communicate to the viewer. Analyst's entry (through node dialog box) will continue to wrap to new lines in the display as the entry gets longer.

Figure 2

Node size can be increased manually (vertically as well as horizontally) by the analyst to contain all displayed text within the boundaries of the node display. The analyst also has the option of preventing a property from being displayed on any given node by simply deleting it from that node's display.

Looking at the bottom left node in the Figure 1 window (also displayed in Figure 2 above for easy reference), you will notice that the first line starts with "1" in square brackets, followed by the word Normal in red color, also enclosed in square brackets.

The number in square bracket is an ID automatically assigned to each object by Visio. These ID numbers are not used by NMOD for sequencing of calculations. Calculation sequences depend strictly on the arcs in networks.

Note: You may wonder why it is necessary to display Visio object ID in each node and arc. The reason will become clear as you go through this document. In developing this example, we took special care to make the Visio object ID of every node correspond to the appropriate step number in the instruction set shown to the right of Figure 1 in Chapter 1 (Models and logical networks). There is no need to be concerned with such correlation while developing actual models with NMOD.

"Normal" on the first line refers to the Type property of the node. The values a node's Type property can take on in NMOD are listed below:

The second line (in green) displayed on a node is the name assigned to the node by the analyst ("WearParameters" in the case of the node in Figure 2). If node name is longer than 20 characters, it will wrap to next line. However, the user can prevent wrapping by widening node display. Regardless of the length of the name the analyst assigns to a node, NMOD stores only the first 25 characters of a node name.

Node names are not used by NMOD except in the case of nodes with Network Type property (explained later). In all other instances node name is strictly for the benefit of the analyst (for model debugging), and for easy communication of model content among stakeholders of a model.

The third line in each node display is for showing Resource information. Since Resource properties of nodes and arcs are not accessible in NMOD, this line always appears as R:{} or just {} in every node.

Analysts typically use node name to describe nodes in short form. Expanded node description can be entered in the Description property of a node. Since the fourth line and higher displayed in every node is actually the Description property of a node, the analyst can use this property to display equations or whatever else that may be of help to the viewer in understanding a model.

Arc display

The first line in an arc display shows the object ID automatically assigned to it by Visio, followed a placeholder for Resource information (not used in NMOD).

Figure 3a

The second line of an arc display is the same as the 4th line of a node display. Default setting for holding arc text can be altered with the Text block and rotation tool from the Tool bar.

Do not enter Description property text directly into nodes and arcs. Always use their dialog boxes to enter property values so that connections from property values to the display will not be affected.

Alert: If you wish to rotate the text inside a node display, do not rotate the node, too. It is critical to retain the original orientation of nodes, since ORMSware uses properties of this orientation to decipher which arcs originate from and terminate in any given node. Also, no node should be placed overlapping or touching another node.

The analyst can use Description property of an arc to display whatever needs to be communicated to the viewer. In the case of the arc in Figure 4 above, the analyst has chosen to communicate that the calculation sequence will always proceed unconditionally along this arc. Always (i.e. unconditional execution) is the default condition on all arcs.

Arcs are used to control the sequence of calculations as well as to perform calculations. Nodes and arcs are derived from the same base object. Therefore, many of their properties and functions are identical. In the network in Figure 1-Revised window, however, arcs are used strictly to control sequence of calculations; no calculations are performed on any of the arcs in that network. In several example problems posted at this site arcs are also used for calculations and transformations.

They are OR (--->|) Type and AND (-->>|) Type. All arcs in Figure 1 network are AND arcs as the one shown with double arrowheads in Figure 3b. The arc shown in Figure 3a is an OR arc.

NMOD internally labels any node with at least one AND arc leading into it as a Convergence node. It makes sure that a Convergence node executes only when all AND conditions leading into it have been satisfied.

Note: Actually, that is not a totally accurate statement, but that will do for our current discussion. We will discuss convergence later in more detail. The idea of using Arc Types for convergence is different from what is commonly seen in other network paradigms. They use AND junctions or gates to ensure convergence before permitting flows to proceed to convergence nodes. ORMSware approach has certain advantages which will become obvious as we proceed through this primer.

In the network in Figure 1 window, nodes 3 and 5 are Convergence nodes. NMOD makes sure that Node 3 does not execute until both arcs leading into it (Arcs 6 and 7) are finished; and that Node 5 does not execute until both Arc 8 and Arc 9 are finished.

A Convergence node can also have any number of OR arc(s) leading into it. You will see an example of this later in this primer.

Role property of nodes and arcs

The appearance of any Type of node or arc can be changed to indicate the overall role it plays in a model. When this property value is changed from Primary to Support, the lines in the object turn from solid to dashed and the text and line colors change from black to gray. But, primary and support objects have identical capabilities.

Analysts change role property of an object to Support only to push it to the back of a "viewer's consciousness," because its function in a network may strictly be one of facilitating the overall flow of a model or performing certain housekeeping functions. Understanding the details of such objects may not be essential in understanding the essence of a model. You will see examples of support objects in several models presented at this site.

Note: The dashed lines of Support objects do not show up as dashed when Visio 2002 creates web pages at times, but you will still be able to notice the gray text and line color. Of course, if you download the diagrams and view them in Visio 2002, you will see all objects exactly the way they are supposed to appear.

Figures 4 and 5

NMOD atom and ORMSware netoworks

**NMOD atom and ORMSware netoworks**