Leemi
Thu Dec 09 14:24:28 CST 2004
Hi Darren:
You have gotten some good answers so far, but I thought I would chime in.
Here is a book from www.hentzenwerke.com:
Effective Techniques for Application Development with Visual FoxPro 6.0
by Jim Booth, Stephen A Sawyer
Edited by Steve Dingle
ISBN: 0-96550-937-0
There are several other books available in the Catalog section that might
interest you as well.
I hope this helps.
This posting is provided "AS IS" with no warranties, and confers no rights.
Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell
*-- VFP9 Public Beta Now Available!! --*
Download the VFP9 beta here:
http://msdn.microsoft.com/vfoxpro/
*-- VFP8 HAS ARRIVED!! --*
Read about all the new features of VFP8 here:
http://www.universalthread.com/VisualFoxPro/News/VFP8Release.asp
Purchase VFP8 here:
http://shop.microsoft.com/Referral/Productinfo.asp?siteID=11518
Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
- VFP5 Mainstream Support retired June 30th, 2003
- VFP6 Mainstream Support retired Sept. 30th, 2003
Hey Darren,
As you see time and time again, it depends. Scope and timeframe tend to
often undermine a lot of design, but it's generally better than not to do
design up front. Jumping right into coding MAY even be a form of design
depending on what you do and what you mean by jumping in. For example, I'll
sometimes start with putting together a screen that a user might have to
accomplish the function at hand. Thinking through that flow sometimes helps
me to realize what the underlying data will be and the functions that
support it.
There are a number of more formalized methods. MSF (Microsoft Solutions
Framework) is one that I've lately just been touching on
(
http://www.microsoft.com/technet/itsolutions/msf/default.mspx). It
essentially lays out the conceptual side of the process from the early
stages of defining functionality--prior to even selecting a language.
Whatever WAY you decide to attack the problem, UML is a tool for expressing
your decisions/outcomes. It's basically a set of diagrams that describe the
system and subsystems.
It's not only a set in the sense that there are (barring a TINY system)
going to be multiple diagrams to describe everything, but also in the sense
that there are various _kinds_ of diagrams. Some are more designed to
describe at a higher level (one that may even make sense to an end user)
what the pieces will be, who/what interacts with them and how. The general
process tends to be start with these then sort of translate them down to
more technical diagrams, describing objects in the database or components.
Visio can take these diagrams and actually build a database or write the
skeletons of the code. I believe Rose has some similar capabilities.
Kind of a generic answer, I know, but there are quite a few entire books on
the subject. Hopefully this is a nudge in a direction!
- John
"Darwood" <darrenw@nospamme.woodfordcomputers.co.uk> wrote in message
news:%23B2sz4s1EHA.2804@TK2MSFTNGP15.phx.gbl...
> In my college days I learnt DBIV and Pascal. We were taught in those days
to
> design in the following way:
> 1. JSP Diagrams.
> 2. Pseudo Code
> 3. Real Code.
>
> In our new OOP world JSP Diagrams don't seem to work. Instead I
increasingly
> find myself just coding right off. I am sure there is a better
methodology.
> What are you doing? How does UML fit in to all this? How do you define the
> flow of your application and the relationships between classes. Do you use
a
> software design tool such as Rose or Visio? I used to use a progam called
> EasyCASE but I don't even know if it is still around.
>
> --
> Regards
> Darren Woodford - MCP, MCSE
> Woodford Computer Systems Ltd
>
http://www.woodfordcomputers.co.uk
>
http://www.accountancy-software.co.uk/pegasus-opera-ii/pegasus-opera-ii.php