A Simple Discrete-Event Simulation: Part 56

I the process of working off some of the TODO: items I have sprinkled through the code I ended up fleshing out the model verification function. It is called after everything is defined but before the model runs. I haven’t let a negative finding prevent the model from running — yet — since I currently have a working configuration. The function also ensures that certain settings are initialized.

Here’s the function itself. Explanations and supplementary listings follow.

The function starts out by verifying that all previous and next component links exists and are valid in a number of ways. Here’s an example of the most general formation. A customized version of the verifyLinks method was created for each component type. Component types that do not support one type of link or another (e.g., Exit components do not include forward connections) do not test those elements. It is possible that these methods can be even more standardized and modularized, and I may look into that at some point.

In general, the method ensures that the count of connections is not zero, that the list of connections does contain references to something, that the references are to objects, that the objects are (likely to be) components by testing for the presences of the componentType property, and that the connections are not to types of components that make no sense (e.g., Entry components cannot be connected to Exit components and vice versa).

The function continues by setting the value of the exclusive property for each Path component based the exclusive property of its terminating non-Path component. This assumes that the exclusive property of each non-Path component has already been set.

Here’s the getNextExclusive function I had to define in the Path component. I noticed that I do this pass-through thing frequently and should come up with a consistent naming convention for methods like this.

The verifyModel function then tests the nextComponentList links of every Entry component to ensure that all connected components are defined to be non-exclusive. Here’s the code for the A customized version of the verifyLinks method was created for each component type. method.

Finally, I moved the mechanism for assigning destination component indices for forward links to here.

Some of the methods return error codes, and these are placed in the scrolling text area. The messages include detailed notes about the components and connections that are incorrectly configured.

I have a comment in place to implement a mechanism to assign the desired distribution method based on the nature of the downstream connections.

I currently have the routing logic attached to the individual components, but there is also a need to ensure that certain combinations of destinations can be reached from the point of view of an entity moving through a system. Moreover, destinations may need to be identitied in an aggregate way, like a toll plaza containing many booths. I will implement a test mechanism to address that process at some point as well.

There are many more things that can be tested or automated in this or similar functions. However, this was a pretty good start.

Last but not least, and not related to this project, I was able to complete another class on Udemy over the weekend, this time about Sass and SCSS.

This entry was posted in Simulation and tagged . Bookmark the permalink.

Leave a Reply