The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Tools for early code design/planning

Hi. I'm an "expert in my niche" sort of programmer, entirely self-taught and often ignorant of the sorts of things one would learn in a CS degree.

When approaching a new project, what tools can one use to lay out and design how it will be structured? Ideally, I mean not only the objects and classes, but more generally the features, controls, views, dependencies/references or what have you.

My approach to this has thusfar been to sketch a little on paper, stub out a few core class, then write. But I've run into the limits of this and need to do more thinking ahead. I find myself much later saying "Damn, this X can't do Y without a reference to Z - now how will I get that?" because I didn't specifically plan the outlying parts of the code. Then I have to cram in a few getReferenceToQ() methods with a pickaxe, and the angels start weeping.

Also I've realized that neither paper nor writing stubs are working for me. Writing stubs isn't visual enough, and in both cases it's too hard to revise without starting over, so I don't.

Please note that the ability to read in existing code, or output stub code, while nice, is probably not important to me as I'm using a somewhat minor language that probably wouldn't be supported.

Ancillary question: Is UML useful for what I'm talking about? Do people use it? It seems to be used under the surface for some tools of this sort, but would it be useful to understand how it works?
anon for this one
Tuesday, June 26, 2007
 
 
> it's too hard to revise without starting over, so I don't.

One strategy is to plan to throw the first one away.
(not really) Fred Brooks
Wednesday, June 27, 2007
 
 
Have you heard of MIT's OpenCourseWare? (Basically it's free Uni courses)

http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/index.htm

That may be a good source of information for you. After quick scan I came up with this course:

http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-170Fall-2005/CourseHome/index.htm

Not sure if it's exactly what you're looking for but OpenCourseWare can give you a feel about what goes on in a CS Degree. :-)
Jonathan R Send private email
Wednesday, June 27, 2007
 
 
I sometimes get the feeling that those early stages of code design is the place were the magic happens. Not everybody is capable of doing it (never mind doing it well).

I often use paper to scetch a few object models or flow diagrams, but also use Visio or Power Point. But these are all high level designs, sometimes just touching class level, sometimes they go a little further. But I always have blind spots in my designs. Areas where you just didn't focus enough because they are not part of the core idea or just don't have your interest or you lack knowledge.

When I start coding I will make the detailed class and object interaction design. Preferably I use an UML-isch tool that also generates the code to safe time, otherwise I just do it off the top of my head or on paper.

I always seem to use some of my favorite design patterns to solve common problems (like with dependencies, you mentioned).

When the starts to smell funny (or looks funny) I refactor. Refactoring is an great way to get code design more-right than the first time (I never seem to be able to get all things right in the first try). Ofcourse you have unit tests that make sure you don't repare something to death ;-)

(enough about me, back to you)
I hope by talking about how I start code design I might give you some ideas. You do not mention refactoring in your approach. Maybe that is what you're missing? I would not focus on the tools too much, because they are just, well... tools. Focus on your design process instead. If you don't use the UML tool to generate at least a first code skeleton, then paper is faster.

--Marc
Marc Jacobi Send private email
Wednesday, June 27, 2007
 
 
Yes, we do use UML, in various ways.

http://martinfowler.com/bliki/UmlMode.html talks about different ways UML is used. Personally, I mostly use UmlAsSketch.
Mike Stockdale Send private email
Wednesday, June 27, 2007
 
 
>Jonathan: Not what I was looking for but definitely something for me to have a look at. I never missed a CS degree until I moved to a job where I was surrounded with them, but whether that's a case of me lacking real knowledge or just common metaphor is a question for more patient minds than mine... ;)

>Marc: Thank you for the thoughts, but which UML-isch tool is it that you use?
OP
Wednesday, June 27, 2007
 
 
For drawing UML, I use Visio and the stencils from http://www.softwarestencils.com/uml/index.html

(or if it's just for me, often I use paper and pencil!)
Mike Stockdale Send private email
Wednesday, June 27, 2007
 
 
A couple of thoughts:

- Unless there is some element of rigor associated with any tool you use, you might as well just get some colored markers and a white board.  The tool should help you by telling you when you make a mistake.

- I strongly believe that the most important thing is to get your data model right.  If that's wrong, you're SOL no matter what else you may get right.  Once you've got the data model you can create an object model out of that if you want, or not.
BillAtHRST Send private email
Wednesday, June 27, 2007
 
 
Here's the way I do things and this works really well:

1) Create a vision.
A one sentence description of your product is VITAL. What does it do, what sets it apart?

2) Map out the features
Map out what features your product needs to support to work and compete with your other competitors.

I repeat steps 3) to 5) to get a stubbed version of my code:

3) Create a use case. Remember to always work on the use case with the most risk first. Basically what use case is VITAL for your project. If you have something that is VITAL and something you have never done before, then it's even more important you work on this first.

4) Create the interfaces that you need to implement this use case. Try and make each method in the interface depend only on predefined types (like integer, string) as far as possible. Your interfaces need to be as cohesive as possible and couple as little as possible.

5) Create an implementation of each interface. Write only as much code as needed to ensure that each interface has the correct information available. For example simply return a dummy values for functions etc.

Now you can use a tool like Enterprise Architect to reverse engineer this and take a look at how your interfaces work together. Remember UML is just a tool so don't be too anal about the diagrams that you generate.

All this should get you the complete framework for your product. Basically you're getting the framework of your product ready. You should even be able to compile this code and run it though it won't do anything yet.

The next stage is to actually implement this with Test driven development, refactoring when you've made a mistake in your design etc.
Praveen Angyan Send private email
Wednesday, June 27, 2007
 
 
> My approach to this has thusfar been to sketch a little
> on paper, stub out a few core class, then write.

This approach works for me.

> But I've run into the limits of this and need to do more
> thinking ahead. I find myself much later saying "Damn,
> this X can't do Y without a reference to Z - now how
> will I get that?"

Use more paper ;)
Jussi Jumppanen
Wednesday, June 27, 2007
 
 
>Marc: Thank you for the thoughts, but which UML-isch tool is it that you use?

OP: I use Paper (never crashes ;-), Visio (UML stencil) for conceptual stuff and Visual Studio 2005 Class Designer for physical stuff. I think paper is still my favorite.
Marc Jacobi Send private email
Thursday, June 28, 2007
 
 
Hi

I generaly start by choosing a "theme" or metaphore for the architecture: a brief, vivid description of the architectural approach for the system and its ONE main desing principle. This is very much like what a music compositor does to create a complex symphonia.

Some examples from actual projects: "every  object will be treated like a document stored in a library. . . " or "the information will treated as a graph on wich the user can navigate or view from different perspectives "

The two main advantage of creating this "theme" are: first, the resulting design is more coherent because it is not just a bunch of patterns put together. I use patterns during the realization of this guiding principle.

Second, the metaphore brings other ideas to your design. For instance, the "graph" metaphore brought a lot of nice ideas like "graph walkers" as a way to process the information. The resulting system was very, very flexible and the user interface was a snap. 

It might sound complicated, but the themes you choose are related to your experience (that's why you choose them) so at the end they make a lot of sense to you. Some one can say "this system will be like a self-service restaurant" whatever it means to him/her.
Pablo Chacin Send private email
Thursday, June 28, 2007
 
 
One tool I've used to do UML as a sketch is UMLet: http://www.umlet.com/
Kevin
Saturday, June 30, 2007
 
 
anon

not sure it's exactly what you're looking for but I read this thread with some interest [looking for similar things] and have found some of what meets my [possibly your] needs here:
http://www.startupcto.com/
anon II
Sunday, July 01, 2007
 
 
If you want to experiment with an UML tool without spending anything, ArgoUML is an option.  (I found it to be kind of a beast, hungry for ram and crashy, but to be fair the last time I had cause to use it was around six years ago.  I did think it had promise, at the time, just a bad case of "1.0-itis".)  I think there are also UML sketcher environments available as plugins for netbeans and eclipse, and I'm sure most every commercial IDE.  The main thing about UML, much like the patterns movement, is that it adds value only in the extent that it helps expedite the design process... pictures and abstract architectural dialog sooner or later have to turn into code.  That's a long winded way of saying that designers/architects need to try hard to avoid "analysis paralysis".
son of anon
Tuesday, July 03, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz