19.1.2     Designing the solution

This is NOT the latest copy of this book; click here for the latest version.

Once you have a full grasp of what your users want out of your application, the next goal is to try to plan out how the system should be put together. To begin with, the design should be entirely paper-based - draw sketches of your classes and how they fit together, give functions names and specify where they will be used, and also specify how files should work together.

If your solution involves a database, which it often will, you will likely find it useful to draw up a simple database schema diagram defining each attribute in your tables, as well as the primary and foreign keys. I personally use a very basic schema design, where each table in a database is represented as a table in the diagram with its attributes as physical table rows. Each attribute that is a primary key has a box on its left shaded in, and each attribute that is a foreign key has a box on its right shaded in, with a line connecting it to the table where the key originates.

Once you have your paper design completed - and at this point you may have gone through various iterations as you find problems - you can start doing draft programming. The goal here is to produce a very simple version of your application, a skeleton you might say, that implements the various connectivity between each part of the app. It might be that functions simply output messages such as "Entering function X" and "Exiting function X", which is fine - at this stage the goal is to make sure that the design is, for the most part, correct.

The ease of writing PHP code often makes it relatively straightforward to make fairly advanced prototypes, even to the point where you can end up basing your main application on the final prototype.