Planning is alot of work. Something most developer don't do because it's not really what a software developer does. You need experience developing software before you can plan a software project, but the two are quite different.
It's awesome your looking to form a solid application document plan, but if your working on a project solely for your own purpose, it might be overkill?
If not, here is some advice.
Think abstract. Like Everah suggested, your flow chart is to implementation specific. The slightest code change and your document is now garbage, or atleast requires re-designing. Abstractions *anything* don't break as easily. Regardless of whether it's high level abstraction in a project planning document or low-level in the case of a ABC.
The next step, is abstraction decomposition. Make your abstractions less abstract, but not so concrete that implementation changes cause you to redo your documents. The book on XP i'm reading right now really made me realize where my mistakes were. I planned to much (I love to plan, maybe more than writting code) and when implementation changed my documents needed changed. But after spending an hour or so making a document look good, the last thing you want to do is redo it, so you get into the habit of "I'll change it later" syndrome. Something I did so much my documents rarely stayed in synch with my code base.
OOD and application or system design are slightly different. OOD typically revolves around problem solving in OO perspective. You take the problem on head first and generally wack out a single monolithic class. That class must then be analyzed and likely decomposed. I read in an excellent C++ book by Bruce Eckel??? If your interface doesn't fit on a sticky pad (sticky notes or whatever their called) your class API is to large (general rule of thumb not hardened guideline).
Personally, I have experienced almost any object (after some thought) could be further decomposed. It's problem solving from an OO perspective. Like any problem, you start big and break it down into smaller and smaller problems until a atmoic state has been reached.
This is where TDD comes in really handy, at least the principles, not the practice. If you write your tests first, you don't waste any time writing code, only later to discover your object could be further broken into 2 or more objects. Thus forcing you to refactor - not a bad thing, but in this case can usually be avoided with proper planning, at least somewhat.
Another thing which I really appreciate about XP, is it's stance on staying Agile and not locking onto any single method or approach. Keep your SDLC (software development life cycle) changing, improving, etc. Evolve basically. Learn over time.
It sounds like your expecting to much, too soon. It's a process which never stops. You'll never get your application 100% correct, ever! Cranck out some code, print it, read, whatever. Understand it, map it to design patterns, etc.
1) Rename functions to make more sense.
2) Refactor objects into a more atomic state.
3) Re-iterate the above over and over again
Software is truely like a living organism, only when a project dies does it stop growing and changing. So like your source code your methods and techniques should change and evolve to fit your requirements, etc.
I would suggest reading XP or Agile books, but they don't really disscuss anything design specific. They are more geared towards project managament, developing a culture of high performance developers, who adapt and don't just accept what is said to be the best or only way...
They also kind of assume you've had experience working on large projects, where you have maybe experienced sympotoms of code rott, or fragile source bases, etc. I'm not sure where you stand in that department, but for now it sounds like you need to read up on OOD.
Those design pattern books that Arborint always suggests, are a good start, but again it helps if you've written code and made those realizations yourself first then have them formalized by a third party. They do serve a purpose:
1) The further your grasp/understanding of abstract thinking - this cannot be learned except through osmosis.
2) The give a common vocabulary to begin easily disscussing ideas amongst others and assist in further understanding what it is your code is doing.
I'm not sure I am as enthusiastic about them as arborint is, but they good to know, even marginally. Just a general understanding will make a difference in your overview of your own code. Reminding yourself, that
"the application entry point where pages are selected based on GET variables and pulled in with a simple PHP include at runtime, which are invoked by specially constructed URL's in the client end" it's alot easier to assume some defaults (native to your PHP environment) and just tell yourself front controller...
Less words, more pictures...afterall a picture is worth a thousand words, not visa versa.
Cheers
