Focusing on the customers for the moment: they customer will turn up and look around to see what you've got (e.g. search the shop) or ask one of the shop assistants if you sell something.
Customer: "I'd like a Slurpee please".
Shop assistant: [after searching for the right machine...]
"sorry, we don't sell slurpees"
[requirement: can find a machine by name]
"sorry, we do sell slurpees, but we're out of frozen water"
[requirement: can query machine status]
but assume it's
"ok, what flavor do you want?"
Customer: - "what flavors do you sell?"
Shop assistant: [after searching for the Slurpee machine for
the favors (producs) it dispenses]
- "Cola, sarsaparilla, orange, lemon, root beer, or yogurt & Mint"
[requirement: can query for all a machines products]
Customer: - "do you have any Mountain Dew flavor?"
Shop assistant: - "sorry, we don't do that flavor"
[requirement: can query a machines for a specific product]
[note: need to know the difference between products you do stock,
but which are currently out of stock and products you don't stock]
Now, the need to find a machine by name means we need a FindMethod which takes a name (obviously) and have to store the machines in a way that allows you to obtain them by name as well as index (probably.)
(Are you familar with std::map ?? You could either store the Machine in a vector and then search for the machine with the required name. Of use a name to Machine map, which makes finding them easier but means you have to use an iterator when you work on them as a group.)
And your Slurpee machine needs a find product method, but a cash machine doesn't. So you need a bending machine (though maybe dispensing machine might be better? but that's a detail.)
The dialog is probably going too far (though some people do go this far), but this is pretty much what you do; it's called use-case analysis (when done formally, unlike here.) It allows you to work out what has to happen to achieve your main aims. Once you've worked out the what, you then look at the how (the implementation.)
- has zero or more machines
(accessible by name and index)
- RemoveMachine (to balance add)
- FindMachine by name
Also need a way to deal with all machine?
- brand name
(prob better than SetBrandName, as you expand?)
- class Machine
- has zero or more products
(accessible by name and index)
- GetProductLevel ???
(this needs working on?)
Regarding GetProductLevel. Is it enough to have a method which returns (e.g.) an int to inform you of how many servings are still available? Or do you need a Product class which has a GetLevel method plus other stuff? Etc. This would mean the Machine needs to work with Product instance rather than just products names.
And should the machine now the price of it's products, in the general case? Or should that be for the cash register (in a shop, the bar code identifies the products and the register then looks up the price.)
class VendingMachine : brand name = "Slurpee Machine"
- has zero or more product prices
(accessible by product name and index)
Writing this down, I'm now thinking about how the save-game mechanism will work. Once you've added all the products to the Slurpee machine, you do't nwat to have the store reconfiguring the machine every time it "open". So you need to provide a way for each machine to save its data (serialize it's data to disk) when the game closes, and then read it back in when the game is restarted. While you don't need to worry about the detail of this yet, I would add it to my to do list.
And how real life customers can be a bit random! So need a random number generator somewhere in the game.
I keep a notebook with hand-written notes and sketches to keep track of this kind of thing, which is something you should consider doing if you're already doing so. for small scale projects it's not really worth the effort of writing Word documents or the like.
PS I was taught to write my notes in pen and never remove or tipex anything out. If you make a mistake, just strike it through and make a note of why you think it's wrong. Then,if it turns out later you were wrong about being wrong, you haven't lost any information.
Sketching out the use cases and classes in your own way is going to be more than enough for your purposes. But if you want to find out more, see the following links fr a starting point. Use-case analysis, User stories, and UML (a set way of drawing class hierachy diagrams, etc.) are all popular with software compaines.
Unified Modeling Language