The data storage module

This module will be responsible for storing all of our program's data. We already know that we'll need to store three types of information: a list of products, a list of locations, and a list of inventory items.

To keep our program as simple as possible, we will make two major design decisions regarding the data storage module:

A more sophisticated implementation of our inventory control system would store this information in a database and allow the user to view and edit the lists of product codes and locations. In our case, however, we are more interested in the overall structure of our program, so we want to keep the implementation as simple as possible.

While the list of product codes will be hardwired, we don't necessarily want to build this list into the data storage module itself. The data storage module is responsible for storing and retrieving information—it isn't the data storage module's job to define the list of product codes. Because of this, we are going to need a function within the data storage module that can be called to set the list of product codes. This function will look like the following:

def set_products(products):
    ...

We've already decided that for each product, we want to store the product code, a description, and the desired number of items that the user wants to keep in their inventory for that type of product. To support this, we're going to define the list of products (as supplied in the products parameter to our set_products() function) as a list of (code, description, desired_number) tuples. For example, our list of products might look something like this:

[("CODE01", "Product 1", 10),
 ("CODE02", "Product 2", 200), ...
]

Once the list of products have been defined, we can provide a function to return this list as needed:

def products():
    ...

This would simply return the list of products, allowing your code to work with this list as needed. For example, you can scan through the list of products using the following Python code:

for code,description,desired_number in products():
    ...

These two functions allow us to define the (hardwired) list of products and retrieve this list whenever we need it. Let's now define the equivalent two functions for the list of locations.

First, we need a function to set the hardwired list of locations:

def set_locations(locations):
    ...

Each item in the locations list will be a (code, description) tuple, where code is the code for a location and description is a string describing the location so that the user knows where it is.

We then need a function to retrieve this list of locations as needed:

def locations():
    ...

Once again, this returns the list of locations, allowing us to work with these locations as required.

We now need to decide on how the data storage module will allow the user to store and retrieve the list of inventory items. An inventory item is defined as a product code plus a location code. In other words, an inventory item is a particular type of product at a particular location.

To retrieve the list of inventory items, we'll use the following function:

def items():
    ...

Following the design we used for the products() and locations() functions, the items() function will return a list of the inventory items, where each inventory item is a (product_code, location_code) tuple.

Unlike the lists of products and locations, however, the list of inventory items will not be hardwired: the user will be able to add and remove inventory items. To support this, we're going to need two more functions:

def add_item(product_code, location_code):
    ...


def remove_item(product_code, location_code):
    ...

There is only one more part of our data storage module that we need to design: since we know that we'll be storing the list of inventory items in memory and saving them to disk as required, we're going to need some way of loading the inventory items from disk into memory when the program starts. To support this, we're going to define an initialization function for our module:

def init():
    ...

We've now decided on a total of eight functions for the data storage module. These eight functions make up the public interface for our module. In other words, the other parts of the system will only interact with our module using these eight functions:

Notice the process we went through here: we started by looking at what our module needed to do (in this case, storing and retrieving information) and then designed the module's public interface based on those requirements. For the first seven functions, we used our business requirements to help us design the interface, while for the final function, init(), we used our knowledge of how the module will work internally to change the interface so that the module can do its job. This is a common way of working: both the business requirements and the technical requirements will help shape the module's interface and how it interacts with the rest of the system.

Now that we've designed our data storage module, let's repeat the process for the other modules in our system.

The user interface module

The user interface module will be responsible for interacting with the user. This includes asking the user for information, as well as displaying information on the screen. To keep things simple, we will use a simple text-based interface for our inventory control system, using print() statements to display information and input() to ask the user to enter something.

A more sophisticated implementation of our inventory control system would use a graphical user interface with windows, menus, and dialog boxes. Doing this would make the inventory control system much more complicated and is well beyond the scope of what we are trying to achieve here. However, because of the modular design of the system, if we were to rewrite the user interface to use menus, windows, and the like, we would only be changing this one module—the rest of the system would be unaffected.

Let's think about the various tasks our inventory control system needs to perform from the point of view of the user's interaction with the system:

Let's work through these interactions one at a time:

This completes our design for the user interface module. There are a total of four public functions which we will need to implement for this module.

The report generator module

The report generator module is responsible for generating reports. Since there are two types of report that we need to be able to generate, we are simply going to have two public functions in the report generator module, one for each type of report:

def generate_inventory_report():
    ...

def generate_reorder_report():
    ...

Each of these functions will generate a report of the given type, returning the report's contents as a list of strings. Note that there are no parameters to these functions; because we are keeping things as simple as possible, the reports won't use any parameters to control how they are to be generated.

The main program

The main program isn't a module. Instead, it is a standard Python source file that the user runs to start the system. The main program will import the various modules it needs, and call the functions we have defined to do all the work. In a sense, our main program is the glue that binds together all the other parts of the system.

In Python, when a source file is intended to be run (as opposed to being imported and used by other modules or from the Python command line), it is common to use the following structure for the source file:

def main():
    ...

if __name__ == "__main__":
    main()

All of the program's logic is written inside the main() function, which is then called by the final two lines in the file. The if __name__ == "__main__" line is a piece of Python magic that basically means if this program is being run. In other words, if the user is running this program, call the main() function to do all the work.

We are going to use this design for our main program, putting all the actual functionality within a single function called main().

Our main() function is going to do the following:

Steps 3 and 4 will be repeated indefinitely until the user quits.