How to approach design problems like "design a vending machine"

Question

Hello,

I wanted to know what are the steps that I should follow to approach problems like design a vending machine and come up with a number of design documents (like use case, sequence diagram, class diagram). Is there any source/link that I can read where it talks about how to go step by step.

Thanks.

Answer 1

I'm not sure if theres any universally accepted set of steps, but the easiest thing to do is just break down each and every step as far as you can go.

1. Start with the major actions (putting in money, pressing a selection, receiving drink)
2. Continue decomposing every action into smaller actions and responses until it becomes almost trivial. So for putting in money, you'd have to know how much was being put in, the total that was put in, the amount to be displayed, etc.
3. Think of any scenarios where your actions would no longer be valid (you push a selection and the machine is empty), and how you would deal with it. (return their money, prompt for another choice, etc.)
4. Assign the actions and responses to the actors and to the system. Who puts in the money, who keeps track of the running total?

Then you can base your sequence diagrams and class diagram off of what you've come up with.

Answer 2

Well, a vending machine is basically a state machine.

I would decide what the valid inputs would be (coins and bills?) and what the outputs would be.

What are the likely outcomes from a user walking up to the machine. What problems might occur? (too much money, too little money) How would they be handled? (dispense change, dispense refund)

Lastly, write out the things that you would need to handle the use cases. Your nouns are likely Classes. Your verbs are likely methods that belong to those classes.

Answer 3

Broadly, think about what objects are involved in a vending machine:

• VendingMachine - possibly an abstract class
• DrinkMachine, SnackMachine, and classes extending VendingMachine
• VendingProduct - an abstract class?
• Drink, other classes extending VendingProduct
• Coke, other classes extending Drink
• &c, &c.

But I'm sure you can figure that out pretty easily. The nuts and bolts of the machine will take place in some kind of utility class, with methods to accept bills and coins, calculate change, etc.

Some linx:

• Here is a good article on beginning an OOP design, by Allen Holub.
• Here is the beginning of a Coffee Vending Machine design using OOP.

Answer 4

start by defining "vendor machine":

A vendor machine is a machine that .....

presto! there's your requirements.

Answer 5

These thoughts may help:

From an interface perspective define inputs, outputs, expected conditions, error conditions.

Decide how good it needs to look.

How long does it need to operate (service life).

How often does it need restocking?

Answer 6

I assume you've seen this link already.

Don't think about code (classes, &c.) first. Think about use cases and functional requirements. What functionality is the vending machine supposed to provide? How are the users expected to interact with it? How about the maintainers? Try not to confuse implementation details from high-level needs while doing this.

Then, depending on what type of class project this is for, think about the non-functional requirements. What's the most important attribute: speed, reliability, ease of maintenance, adaptability to new situations, security, ...? There are other possibilities. These aren't binary, yes/no answers, think more in terms of ranges and minimum standards vs. optimal goals. Note, "optimal" depends on the perspective of the stakeholder in question. Ease of use and security are often in conflict, so you have to figure out which is more important.

After that, you can go back to your use cases, and see how they're impacted by your non-functional requirements. This is where negotiation happens with your client, who in this case is probably you. Do you have to sacrifice features in order to meet some other goal? For each feature, what is the risk vs. the reward? Easy to implement features which provide high value are great. Difficult to implement (due to constraints) features which only add small value should clearly be prioritized last. The other two combinations require careful thought.

Then you can start designing the machine.

There are tons of different diagrams you can use to either help you visualize the problem, or explain your proposed solution to others.

Answer 7

There isn't only one right way to design all software from scratch!

There are probably dozens of different approaches ranging from very little upfront design such as in Evolutionary Design to Big Up Front Design which was written up in August 2005 on JoelOnSoftware. There are probably more than a few inbetween methods that have their place so it depends on what development methodology you want to use as some may require more upfront design like in a Waterfall approach compared to something more Agile where requirements can change regularly and this doesn't cause a lot of problems or at least that is the theory.