I’m trying to set up more of the initial code and continue to be overwhelmed with possibilities and things to consider. (This is a good thing and not a bad thing!) What this tells me is that I have to do more design work before proceeding.
Part of the issue is that I’m thinking of a number of features that would be included in the final design, while also trying to incrementally build up something really simple that works and is (at least somewhat) visually interesting with each day’s increment. There are two main areas I’m thinking about.
The first issue has already been discussed, and it has to do with where to put the “intelligence” in the model. The intelligence can be in the entities or in the components. A hybrid approach is also possible, where some parts of the logic are in the entities and other parts are in the components. There are also (at least) two different types of logic that have to be considered. One concerns determining an entity’s residence time in each component, which can be very complicated. Another concerns knowing which component an entity needs to go to next.
There are reasons for both approaches, but for now I need to make a some kind of a decision so I can move forward. Let me describe the requirements for each approach for each component. My ruminations will be affected by specific problems I have encountered in the past, but others are certainly possible. I don’t guarantee that I’ll think of every possibility.
The other major thing I’m thinking about right now is how to graphically show the status of the components and entities in the system. Every component must be displayed graphically, probably at least with an accompanying text label. Since the visualization is supposed to be abstract, none of the entities are displayed. Rather, their location, count, and status are shown by updating the information about each of the components. Components can have different amounts of information to display, based on the type of component and the desired level of detail. The movement of entities from one component to another are governed by the events defined for the system.
I had the idea that I wanted to be able to display basic data about each component on the component itself, and more complicated data — if desired — in an associated display of additional status information. When the simulation is running at speed it would just show the components and their basic statuses (mostly the number of entities in each queue, current wait times in queues, and the number of items processed per time interval at each component, if even that). When running slowly or stepping through the simulation it could show more complicated information, which would largely consist of descriptions of entities as they transitioned from component to component. Think of an animated process diagram that displays only the graphic objects when running normally, and displaying extra boxes of information for each component when running slowly (e.g., during debugging).
Doing this would require the ability to draw every item during each refresh (which happens after every event). If the detailed information is to be displayed in a separate box then that is redrawn at the same time as well.
Two other questions occurred to me. One is whether I wanted to update the status to show times counting down for each component as it processes entities over time, as opposed to just showing the start and end time of each process, which would be simpler. The other is whether to clear the display of transition events after a specified period of time.
So here are my conclusions.
1) I’m going to place all of the intelligence in the components and none in the entities. The entities will be completely passive. This will change what I’ve done up to now.
2) I’m not going to include continuous countdowns for the status of any component. Statuses will only be updates when entities move from component to component.
3) There are only two types of events that cause updates: the creation of entities in the arrivals component, and the movement of entities from component to component thereafter.
With that I think I can actually move forward.
Oh, one final note. Seeing that I’m repeating the same patterns for displaying variable and property values I’m going to create some objects that will standardize that process as well.