in reply to How do you program (again)?

First, I model the data, and the relationships between the data. Sometimes I'll use an editor like Umbrello, or simply sketch some UML on some paper. Other times I'll just hack Class::Tangram classes directly (as Class::Tangram has quite direct correspondance to most UML data model forms).

Once I've got this model (represented as Class::Tangram classes), I'll write test cases for each class that tests any "special" actions that the object needs to do, for instance, password encryption and authentication on a User object.

The next stages really depend on what the application is doing. Sometimes the next stage will be to plug the classes into a Tangram::Schema, so that I can save them to a database. Sometimes the database plays a more direct part in the planning stage, if there is an existing data form I need to represent and map to.

I find that once the data model is good, writing the actual program is just a matter of joining the dots... which of course can often take a lot longer than you think ;-). 

$h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/."
."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n";

[download]

Replies are listed 'Best First'.
Re: Model the data first
by other90percent (Sexton) on Jun 03, 2005 at 09:22 UTC

    I'll second the notion, and try a paraphrase:

    • Model the data first: give yourself nouns.
    • Decide what the application is doing: give yourself verbs.
    Make it easy on yourself, too. Get Code Complete and Design Patterns. Find out what UML is, and if it fits your way of thinking, use it; but don't force it, or get caught up in dogma. I use bits and pieces from 6 different programming "schools" - Waterfall, Rational, Extreme, etc. Do what works best for you, and you'll be most productive. Find work environments where this fact is respected.
[reply]
      I've worked a bit with UML 4 to 5 years ago, and quite frankly, it confuses me more than it helps : I find too often that the nice UML blue-print doesn't fit well actual data, or workflow, and has to be trashed after the development has already advanced quite far. Maybe that's just me...
      Proper datamodeling is very important though, but I prefer thinking it directly in Perl, or relational databases, or whatever else I'll be using to manage the actual data.
[reply]

        No matter what the application, there is always a model that expresses the Classes in your code, and a metamodel that expresses the structure you used to write them. The first thing you do when you refactor someone else's mess is identify what objects they have, what properties they are setting etc.

        The thing is, is your model explicit in your design or implicitly spread throughout your codebase? 

        $h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/."
."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n";

        [download]
[reply]
[d/l]

In Section Meditations