Planning Code

Before we build anything, we should have a plan, right? Imagine what would happen if we wanted to build a house without a plan, and then end up with the kitchen in the basement and bedroom in the bathroom, and then tried to fix it all after it was all built. Well, that’s what software engineering can look like… Therefore, we should plan our code so that we can code and test easily.

First we start with a specification, often just a description in English, which then gets translated into high-level pseudocode, which we then progressively refine until we can code it.

What is the difference between high-level and low-level pseudocode? The amount of detail.

For example:

If the high level pseudocode is: DoHwk

Low level can be: //DoHwk read book read notes solve problems

And then it can get lower and lower, until it almost looks like code. For example, all pseudocode in our textbook is on the lowest level possible. Notice that it doesn’t have any implementation details, e.g. about data types, etc.

This approach is the core of object-oriented approach, or “black box” approach, where we break the code into various pieces. Then it is easy to test because each “box” should have a clearly indicated input and output. We then know what happens when we put in a certain input, what output we should get. This is so simple, very common sense, and will save you a lot of headache when coding. ICS311 Worksheet

Task: architect code for function MakeDinner(.). The function takes as inputs veggies, rice and fish and produces a cooked meal. (Notice that later you can reuse this function in a variety of other functions such as FancyDinner or RaisingHealthyKids or PoisonSomeoneWithFood.) Assume that at your disposal is a library of functions describing and operating on kitchen equipment.

Details: write progressively more involved pseudocode. Try to keep track of what should be function inputs and outputs, but don’t make it the priority at this point. Spend more time thinking how to develop the pseudocode in stages.

Notice that the choice of “kitchen equipment” will depend on your assumptions. For example, you can assume that you have a Java library that contains Fridge, Stove, and Sink; or Firepit, Stream, Garden, and DryingRack. For example:

Class Fridge {

Object fridge;

OpenFridge(…) Close Fridge(…) GrabFromFridge(…) IncreaseTemp(….) DecreaseTemp(…) Clean(…) Defrost(…) }

Or, you could have a Java library of functions such as:

Class Water {

Object water

GetWater() ThrowDirtyWater() } where the implementation of GetWater() could be: GetWaterFromFawcett () or FetchWaterFromStream().