2. I. Abstract
Community Partners of Dallas (CPD) is a nonprofit organization located in Dallas, Texas
with the mission of ensuring safety, restoring dignity, and inspiring hope for the more than
20,000 abused and neglected children served by Dallas County Protective Services.1
In line with
this mission, each year the organization hosts a Back To School Drive, which provides school
supplies and uniforms to around 2,400 students in the Dallas area. The CPD Back To School
Drive has quickly grown to be more than the organization can handle efficiently. Currently,
caseworkers submit information about their children via email and volunteers spend hours
perusing the submitted data to determine what supplies each student needs. Volunteers then
pack backpacks with supplies and uniforms. Oftentimes, however, due to the multiple layers of
communication, certain supplies and uniform sizes run out in the middle of the drive.
It is from here that the motivation for creating this GUI was derived. This GUI
streamlines the organization’s Back to School Drive by saving data in a central location, tracking
the inventory, and providing the organization with an optimal storage plan based on the amount
of items in stock. Due to an inability to test this model with actual data from the organization, a
standard of measuring “success” must be defined. Ultimately, though the realworld applications
of such a program are hard to deny, it was found that the GUI could be both more robust and
more practical. Further work could focus on a more systematic approach of analyzing the data to
ensure an optimal storage configuration is selected each time new information is input.
Following are details regarding the overall concept of the project through its design statement.
1
3. II. Overall Concept
The project goal was to generate a program that obtains information about what CPD
currently has in stock for the 2,400 children that the Back to School Drive benefits and report
back what they need in a clear and organized format. Furthermore, the program was created to
outline an optimal storage plan based on the dimensions of the storage space and CPD’s current
inventory. Below, Figure 1 is a flowchart that represents the methods through which a final
solution was achieved. This figure is referenced more extensively and explained in greater detail
in Section III.
Figure 1. Flowchart for Optimization Algorithm
Throughout the design process, a few changes had to be made. First, although not in the
initial plan, the creation of a caseworker GUI was deemed necessary. This allows caseworkers to
input the information for each child into the system. The initial GUI and the caseworker GUI
needed to be linked in order for them to function properly. Second, the initial plan was to create
2
4. a simulation that would allow the user to see the boxes being placed in their locations. A
program similar to tetris was considered; however, it took too long to run and it did not
consistently create the optimal storage plan. Another plan involved using an optimization
strategy based on chromosome coding to create the ideal layout; however, this code could not be
configured to include the three different shelves3
. A different algorithm, described in Section III
and graphically represented in Figure 1 above, was used for the optimization.
III. Underlying Concept
As alluded to above, in place of using a genetic algorithm to find an optimal
configuration for the given amount of boxes, a cost function was created that takes into account
the importance the user places on the location of boxes on the shelving unit. If the user places
low emphasis on the location of boxes, the program optimizes “for space”, simply filling the
shelving unit with as many boxes as possible. A high emphasis on location corresponds to an
optimization “for use”, where the size of each box plays a role in determining its final location.
In this model, an optimal small box is defined as one that is placed on the middle shelf. The cost
function created in this program synthesizes this information and outputs an optimal
configuration to the user based on this importance level. On a basic level, aspects of the
computational model include the dimensions of the boxes used, the dimensions of the shelving
unit, and the number of shelves in the warehouse. Before a cost function could be created, a few
assumptions had to be made. First, it was assumed that only three discrete box sizes would be
used: a small box (8” x 12” x 10”), a medium box (12” x 16” x 16”), and a large box (24” x 24”
x 20”). Further, it was assumed that only one shelving unit would be used that contained three
identical shelves of dimensions 40’ x 2’ x 3’. Finally, to ensure no smaller boxes were crushed
3
5. under the weight of their larger counterparts, it was assumed that boxes would not be stacked on
top of one another.
Figure 1 in Section II illustrates the thought process behind the optimization aspect of the
program. Initially, all boxes are stored along with their box sizes as a separate entry in a
structure array. Also stored in the structure array is an access constant, a value of 0.1 for small
boxes, 0.3 for medium boxes, or 0.5 for large boxes, where a smaller value corresponds to a box
that should be easily accessible to the user. A random solution is then generated that assigns
each box to one of the three shelves. Based on this random assignment, a location constant is
ascribed to each box, a value between 0 and 1 that describes the success of the placement of the
box based on the box’s location and the access constant of each box. Again, a smaller number
corresponds to a more optimal location. For example, a small box initially placed on the bottom
shelf is given a location constant of 0.5, while the location constant of a small box placed on the
middle shelf is 0.1. The cost function relates the emphasis the user places on box location, along
with the location constant and access constant of all of the boxes in the configuration. The cost
of a box is given by equation (1) below:
(x) (L ) (A 00)C = c * S + c * 1 (1)
where Lc is the location constant of a given box, S corresponds to the “Location Importance”
slider value, and Ac refers to the access constant of a given box. The total cost of the
configuration is then calculated by summing the cost of each individual box. This cycle is
repeated a number of times based on an iteration value input by the user. After all iterations
have completed, the lowest total cost is selected and the configuration causing this minimal cost
is stored. To ensure this configuration does not exceed the maximum capacity of the shelves, the
4
6. numbers of optimal small, medium, and large boxes are input into numBoxesF, a function that
outputs the number of boxes of each type that can be placed on each shelf for the optimal amount
of area to be used. The function works by comparing the total area of each shelf to the area used
by the inputted number of boxes. The area of each box and shelf is given by equation (2) below:
lA = * w (2)
where l is the length of the object, and w is the width of the object.
The caseworker GUI, shown below in Figure 2 of Section IV takes the information that is
entered when the “submit” button is pressed and stores it in an array. When the “submit” button
is pressed, it also calculates all of the values that will be displayed in the “needed” column of the
optimization GUI, which can be seen in Figures 3 and 4 of Section IV. The information is passed
from one GUI to another through global variables, which can be accessed from any file. This was
the simplest way for the necessary variables to be entered in the caseworker GUI and accessible
in the optimization GUI.
IV. GUI Tool
This project contains two GUIs that are linked: one GUI is the interface through which
the caseworker inputs all of their information and is shown below in Figure 2. The other GUI is
the interface through which the optimization of the shelves and the inventory control is displayed
and is shown below in both Figure 3 and Figure 4. Each GUI was graphically designed using
imported .jpeg files designed in Microsoft PowerPoint and used as the background of each GUI.
The key features of the GUI in Figure 2 include the seven fields in which each case worker from
CPD inputs their information. The “Name,” “Your Unit,” and “Student Name” fields are all edit
boxes due to the infinite variability of these data points. The “Gender,” “Age,” “Grade,” and
5
7. “Uniform Size” fields are all dropdown menus so that the organization can be easily organized
and sorted for the organization to later use. As mentioned above, the information that the GUI
obtains here is organized into an array; however, this array is not displayed in the final GUI
output for the practical reason that there would not be enough room to display all of this
information. The number in the lower right hand corner of Figure 2 lets the caseworker know
how many times they have submitted information; the caseworker can submit one sheet of
information for each child. The “Submit” button, also in the lower right hand corner of Figure 2,
is used to generate a new, blank caseworker GUI and to submit the information, which is then
linked to the GUI displayed in Figures 3 and 4.
Figure 2. Caseworker GUI
6
8. Below, in both Figures 3 and 4, is the GUI that displays (1) a visual representation of the
shelving space being optimized and statistics associated with that, (2) data fields to enter new
donations, and (3) data fields that report back the current status of the inventory of the CPD.
Key features of this GUI include the visual representation of the optimization of the shelves in
the graph shown in the center of the GUI. In Figure 4, the graph is shown in 3D to demonstrate
the function that plots cubes2
. The color of each cube depends on the extent to which it is
optimized; for example, in Figure 3, the large green rectangles on the first shelf represent large
boxes that are optimized to their fullest extent because it was dictated by the organization that it
is best to have the large boxes on the lowest shelf. The orange color of some boxes represents
mediocre optimization, while the red color of other boxes represents that these boxes are in their
least preferred location. Beneath the storage visualization graph is a slider for the importance of
location and an edit box for the number of iterations. A slider was chosen for the user to easily
and quickly adjust the importance that location holds for each box, while an edit box was chosen
for the number of iterations, since the user will probably want to keep this number fairly high in
order for the algorithm to be the most effective. The last optimization feature of this GUI are the
two percentage values beneath this slider that allow the user to see the effectiveness of the
algorithm; the higher the percentage of storage space filled and the higher the number of optimal
small boxes, the more effective the algorithm is. Finally, the “Sort” button can be pressed in
order to run the algorithm and rearrange the boxes on the shelves in the graph.
7
9.
Figure 3. Display of Optimization GUI
Another key feature of this storage visualization GUI depicted in Figures 3 and 4 are the
data fields on the right and left sides. The fields on the left side that are next to the school supply
item name (Example: “Backpacks”) are all edit boxes that allow the caseworkers to input new
numbers for any donations they may receive for the summer school drive. Changing these
numbers automatically adjusts the static text boxes at the lower left hand corner of the GUI in
Figure 4 so that they accurately represent how many boxes the organization will need to store all
these new items in addition to their current items. The fields on the right are static text boxes
that represent what the organization currently has in stock, what they need based on what each
caseworker inputs into the caseworker GUI depicted in Figure 2, and whether or not they have a
surplus or deficit of those items. This information is displayed only when the “Refresh” button
8
10. in the lower right hand corner is pressed after the caseworker inputs all the pertinent information
into the caseworker GUI.
Figure 4. 3D Display of Optimization GUI
V. Discussion of Performance
One way to determine effectiveness of the algorithm is the percent of optimal small boxes,
which ideally is a rather high percentage. The results for this percentage varied significantly
each time the boxes were resorted. This inconsistency is a slight variation from the predicted
outcome, and it is due to the randomization aspect of the algorithm which completely
reorganized all the boxes each time the “sort” button was pressed. Therefore, the success of the
program can be difficult to determine because the randomization makes it harder to assess the
average percent of optimal small boxes depicted in the GUI.
9
11. Another consequence of the randomization was that the value of the slider determining the
relative importance of location did not have a significant impact on the percent of optimal small
boxes depicted in the GUI, which is the major difference in the results from the predictions.
In order to solve this randomization issue, the program could have made use of the “brute
force method.” This would involve the program cycling through every possible solution and
ranking each one based on its cost, but would thereby be sacrificing valuable time. After being
run both ways, the program was determined to be more effective when not using the brute force
method, which was vastly too time consuming and did not provide significantly improved
results.
In order to make the GUI more practical for the reallife warehouse, the information could be
entered and stored online, and the data could be entered into the GUI from one centralized
location later, or the GUI itself could possibly be run online. Doing either of these would avoid
the problem of each worker having to use the same computer in order for the GUI to collect all
the data. Another way to make the algorithm more practical would be creating a “box stacking”
option, which would incorporate the optimization of volume, opposed to only accounting for
area. Overall, despite the above discrepancies, the results of the GUI matched well with the
predictions listed in the initial project memo.
10
