Fundamentally, a design is a description of what the code will do, and how it will do it. The former is your interpretation of the spec (if you have one - if not the design is an opportunity to define one and make sure everyone agrees with it), and it's useful to cross check between them. The latter defines what you need to write, and need not be as precise.
Exactly what tools you use to describe it doesn't matter that much. Spending some time quantifying your ideas means that instead of changing your design when you've already started coding, both the bright ideas and the precise understanding that leads to design changes happen before you've started coding. That doesn't mean you won't change the design after you've started coding, but it reduces the chance of fundamental changes.
From a design point of view, I find UML, particularly class diagrams, enormously useful.
If you don't know UML, simple class diagrams (listing only attributes, methods and inheritance) are easy to learn - I found SAMS UML in 24 hours teaches this quite well, and provides useful guidance on software design as well.
If you want to go even simpler, a text document something like this:
would help you to focus (or equivalent - from your mention of UML I'm more or less assuming here that you are coding, or at least designing, from a more or less OO point of view).Object: Datasource Attributes: connectionstring field Methods: read write ################## Object: SQLDatasource superclass: Datasource Attributes: primarykey Methods: commit
Alternatively, flow charts are always a good fall back option, and easily understood even by the non-technical.
IME, you'll definitely gain a great deal of benefit from getting something substantial down in writing before you start coding.
It would also be worthwhile discussing the requirement with someone else, and getting them to look at your design in the context of the requirement. Talking over your design decisions can help to focus your mind, and input from other people always helps.
If this is related to the data consolidation requirement you posted about some time ago (Automating data loading into Oracle), at the very least your design should include something like this:
SOURCEFIELD TRANSFORMATION TARGETFIELD sourcedb.name lowercase targetdb.fullname sourcedb.firstname uppercase targetdb.givenname ..
Since you have mentioned other people involved in the project talking about UML etc, it might be that there are people around with design experience. It could be worth your while discussing this with them, and getting their suggestions.
--------------------------------------------------------------
"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
John Brunner, "The Shockwave Rider".
In reply to Re: "Designing" a Perl program
by g0n
in thread "Designing" a Perl program
by punkish
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |