This program strives to model melanoma cancer's growth through the body taking into account the many factors that influence its growth. In our initially simplified model, the cancer originates at certain coordinates and from there follows an elliptical growth pattern. As time progresses, the cancerous cell count compared to the time should follow a sigmoidal curve, a curve that initially resembles a representation of exponential growth but then in time levels out (Appendix A, Figure 4). Initially, there will be exponential growth as there is virtually no competition for resources and space, which later becomes a problem. At first there is nothing stopping these malignant cells' growth. As time progresses, though, resources become a problem for development and therefore growth is slowed and levels off.
Gene Wong, M.D., our project mentor recommended that we attempt to make a program that initially follows reality and then check to make sure that various other cases worked in this scenario, editing the program so they do. This is the method used in developing professional computer models of cancer growth and has been somewhat successful. For that reason, we decided to try that method in developing our program.
Before starting on the application, we had to select a programming language. After looking at the pros and the cons of each language, Microsoft Visual Basic 6.0 appeared to fit the needs of the project quite well. As the name suggests, it is very graphically oriented, something that would be important for this program. Therefore, we used it to easily create excellent graphics while allowing us to concentrate much more on the algorithms, the part of the project that is most important. For a simple, concise view of our algorithm and general approach, see the flowchart in Appendix A, Figure 5.
To model the cancer cells we decided to have each pixel on the screen represent a melanocyte cell. The number of pixels are user defined, depending on how fine of a resolution the user wants. The healthy cells are represented by a gray dot, while the cancerous cells are red dots. Each cell is an object of our GraphicCell, which includes various properties that are changed by the different methods or sub programs. As each cell is represented by a pixel on the screen, we used a 2-D array, or basically a table containing these different human cells, named CancerModel to hold each of these objects. The name of each of the elements in the array corresponds to the x and y value of the pixel or cell on the screen, making it is somewhat like a large graph. We used a 2-D array instead of a 3-D array because we believe it provides a reasonable representation of the situation. Additionally, the third dimension would use a large amount of memory with resulting increase in run time. We accommodated various variables on each cell with the use of object-oriented programming. The variables for each cell were stored in objects of the class used.
Object Oriented Programming, or OOP, is a method of programming that makes "objects" of a "class" and then manipulates these objects for programmer's purpose. The reason this is so useful for this project is that we are able to make the components of each of the cells uniform and then manipulate them, for instance making some or all of them cancerous. We are also able to check the amount of available nutrients, a factor in growth, there are for a certain cell by calling a function that calculates and returns the amount of nutrients. Also, it is easily able to be expanded upon when giving the program greater abilities by adding more properties to the class without influencing the rest of the program. These are only a few examples of how OOP gives us a much greater opportunity to utilize all the cells of our 2-D array of objects, each cell with a member of our class GraphicCell.
The class that we created is called GraphicCell. It contains the different properties for each of the objects of the class located in the 2-D array, including IsCancerous (the property stating whether that cell of the array had been infected), HasBeenSwept (used for tabulation of cancerous cells which is described later), nutrients (amount of available nutrients to that specific cell), and other similar properties. These different properties are manipulated by the driving classes to make the model work. Also, the way in which the class is used by the program and designed allows for it to be easily expanded. This becomes very important as we continue to develop the program because when starting initially, we wanted few factors to be incorporated so the problem would be simplified, though as we progress through the project and wanted more factors be influence growth, we were able to just add to the class.
The major method in our program is the sub procedure InitiateAction, which calls many of the other function procedures (also called "procedures") and sub procedures (also called "subs"). In Visual Basic (VB), a function procedure return s a value to the calling procedure and subs do not. Among these subs are SweepTabulate, SweepGrow, and SweepReset. Each of these subs "sweeps" through the array CancerModel and changes certain properties of the object in the array. SweepTabulate checks each object in the array to see if the property IsCancerous, a boolean, is set to true. If so, the sub will then set another of the object's properties, HasBeenSwept to true. In the next sweep, SweepGrow, the sub determines which objects of the array have the HasBeenSwept property equal to true; if this is the case, the program calls the sub InfectNeighbors, passing it the name of the cancerous pixel or cell. The sub InfectNeighbors uses these passed values, which correspond to the cancerous cell's location on the x-y plane, to calculate its neighbors. After each neighbor is calculated, the sub then calls the function ShouldIInfect.
ShouldIInfect returns a true or false value to determine whether the cancerous cell should infect its nearby healthy cells. This procedure really emphasizes that growth is a function of the cancer cell's location, initial size, nutrients, etc. In this function, ShouldIInfect, we can add many types of cases, random number generators, and equations to determine whether the cancerous cell infects healthy cells, though at first we kept these relatively simple for error checking purposes and keeping the problem relatively simple, a good practice to start with. Currently, some of the factors that are taken into account include skin layer pressure, a major one, general probability of growth, and others factors. The ShouldIInfect sub works using a counter of the odds of infection, which is influenced differently by specific factors, these factors will make it more unlikely or likely for the cancer to develop in a certain spot. For example, when the cancer starts to get quite high and there is a lot of skin layer pressure, the chance for that cell to develop up or down from that point is about 1/17. Once the odds have been added together into a counter variable, a random number is then generated from 0 to whatever the counter is at. Only if the random number is zero will the program return a "true" value for the InfectNeighbors sub to infect the specified neighbor. By having these sorts of influences, the cancer mass tends to take an oval shape (Appendix B, Figure 1), which is how melanoma cancer usually develops.
In the previous paragraph, we used the word infect to describe cancer growth, though there is a important yet basically true assumption that we are making is saying this. In real life, cancer cells do not infect the cells close by it but rather the mole just expands, though as our model is a 2-D simplification, we can accurately say that the expanding cancerous cells "take over" cells of the model which is then represented by the cancerous cells. In other words, the non-cancerous cells are still there, except pushed to the side. This simplification does not seem to degrade the results and still present non-cancerous cells which were pushed out of their positions are factored in by the pressure that it exerts onto the cancerous mole.
The third and final sub is SweepReset, which sets all objects' HasBeenSwept property to false. This ensures that all cancerous cells will have a chance to grow during the next run through the sweeps. In the previous sweep, SweepGrow, the "If" statement tested for the value of the bolean HasBeenSwept. Rather than test for IsCancerous, we tested for HasBeenSwept to make certain that cancer cells that had been newly infected, with the InfectNeighbors function were not grown again in the same sub, SweepGrow.
In the earlier stages of our program, for testing purposes, we decided to limit the number of sweeps that were executed so that we could quickly run through our code using little computing power. The "sweeps" are the "development cycles" that appear on the Input Screen of our project, where one development cycle is one run through of each of the three sweeps (SweepTabulate, SweepGrow, and SweepReset). The number of sweeps is determined by user input so that if the user wishes to see how the cancerous point infects the healthy cells over a longer period of time, they can simply input a larger number for the number of sweeps. Also, because the starting x and y values for the first cancerous point is user determined, the user can observe how the cancer infects healthy cells when nearer the epidermis rather than deep in the dermis layer.
The process in which we plotted the model onto the form and the graph of how many cancer cells vs. time was a simple process, yet very effective and efficient, very important qualities in a problem like this. To plot the skin cross-section while showing the cancer growth, the program takes the GUI refresh rate input and updates the GUI every specified number of development cycles. Using the method of refreshing every few development cycles allows us to avoid wasting system resources in redrawing the graphic every time when only a little progress has made between the cycles. To check if the graphic should be updated, it takes the number of development cycles that have been performed and performs the mod function on it with the GUI refresh rate. If the answer is zero, then the program updates the skin model by sweeping through the array and checking the IsCancerous property. If it is true, then a red dot is made on the form. If it is not cancerous, then a grey dot is made. A black dot is made for the location of the initial cancer. Then, the layers of the skin are drawn on top. This overlay and color-coded diagram easily shows even an untrained user immediately what is generally happening.
In addition to creating the skin cross-section view, a graph of the development cycle (x) compared to the number of cancerous cells (y) is made. The graphing sub in the program is given the current coordinates to graph. It draws a line from the previous point to the new point and then sets the new point as the old point so next time the sub is called, it can draw the line from the previous graphed point. The graph is very accurate and easy to read using this method (Appendix B, Figures 2 and 3).
