views:

165

answers:

8

I've learned enough to begin writing programs from scratch, but I'm running into the problem of not knowing how to design the layout and implementation of a program. To be more precise, I'm having difficulty finding a good way to come up with an action plan before I dive in to the programming part. I really want to know what classes, methods, and objects I would need beforehand instead of just adding them along the way.

My intuition is leading me to using some kind of charting software that gives a hierarchal view of all the classes and methods. I've been using OmniGraffle Pro and while it does seem to work somewhat, I'm still having trouble planning out the program in its entirety. How should I approach this problem? What softwares out there are available to help with this problem? Any good reads out there on this issue?

Thanks so much!

Edit: Oh yeah, I'm using Eclipse and I code mainly in Java right now.

+11  A: 

I wouldn't worry about the charting aspect. I would try and document all the entities that you're going to need, and everything that they're going to do. In the simplest case, every noun will be a class, and every verb will be a method.

This is a very basic approach, and what you're asking for is some analysis methodology. Whole books have been written on this and it's a substantial topic.

You can take an alternative approach and adopt an agile methodology. In this you solve one particular problem (a sub-problem of your ultimate goal), and then refactor (perhaps heavily) as you solve further problems. As you code you write and maintain unit tests such that your refactoring don't break your existing code. You have to be prepared to throw away work that you've done but it's a powerful technique that means you get something up and running early, rather than relying on a big-bang approach.

Brian Agnew
I just attended lecture and guess what, my professor talked about exactly this! He even mentioned the word "agile" in talking about TDD and how to use J-Unit. Thanks so much Brian this really just made my day. I can't wait to get started on this.
Leebuntu
That's good news. Best of luck!
Brian Agnew
+2  A: 

There are tools specifically for this kind of problem (e.g., Rational Rose). Unfortunately, while they're lightyears better than Omnigraffle, most of them are quite expensive. There are a few free tools that you might want to look into, such as ArgoUML, and UMLet -- though the latter is an Eclipse plugin, so it's probably not interesting unless you're using (or willing to use) Eclipse.

Jerry Coffin
While you've specifically answered the question, I think Brian's answer is overall more helpful in pointing the OP towards a better approach.
hbunny
@stevendick:yes, it's often a bit interesting to decide between answering the question that was asked, and the question you think probably should have been asked. Brian's answer is pretty much the standard 30-second description of object oriented analysis, but I have to say I've rarely found it very useful. Most people start with a simple view that "the program should do X, Y and Z", giving "the program" as the sole object. It generally takes quite a few attempts at diagramming before you can point at anything that can reasonably be an object in real code.
Jerry Coffin
+2  A: 

Consider looking into Object Oriented Design philosophy for a methodology on how to structure programs. UML or Unified Modeling Language is generally accepted as a method for structuring OO programs in languages like Java and Python. Good programs for those such as BoUML and ArgoUML. Additionally look into the this page on re-factoring, though it's about restructure of code it may help with initial structure as well. Finally look into these OO design principals

Mimisbrunnr
+2  A: 

It would be best to start out with some simple stories or even a list of requirements of what the application can do. From there you can think about what classes you may want to use and how they will interact with each other.

I like to create the various packages that I plan to use and put stub classes in there. You can even stub out the methods if you like and add Javadoc comments.

I wouldn't worry too much about trying to plan it out exactly as it will most likely change as you build it, so even if you get it just perfect at design time, a shifting requirement or something not working out as well as you had originally thought could alter things. The nice thing about a skeleton layout like this is that once you're ready to code you just need to go and start filling in method bodies.

Ryan Elkins
A: 

Most engineers I've known use Visio--it's usually available as part of your company suite.

There are also some free webapps that do modeling for you (Object Modeling is the "keyword" for what you are talking about)

You might look at UML Object diagrams--although it's not important to follow any specs exactly, if you use that as a base more people will have some idea of what you are talking about.

Bill K
A: 

I use a good sized whiteboard for modeling. I found it really helps for me to be able to take a few steps back and be able to view the entire design, and the flexibility to be able to change something with a swipe of an eraser really lets me focus on the task at hand.

When I'm finished I take a picture with my camera and load it onto my computer for long term use.

Covar
A: 

You need to know about design recipes:

http://en.wikipedia.org/wiki/How_to_Design_Programs

pbernatchez
A: 

I would add to Brian's comments that while adopting an agile approach you also adopt a Test Driven Development (TDD) approach to writing your code. Essentially, you write the tests for your code before you write any actual production code. This really forces you to slow down and think hard about what you need (and don't need) to program, what data models you will need and how they will interact. There are lots of advantages to TDD, but better design is a big plus to me. Here's a relevant snippet from the above link:

Test-driven development offers more than just simple validation of correctness, but can also drive the design of a program. By focusing on the test cases first, one must imagine how the functionality will be used by clients (in the first case, the test cases). So, the programmer is concerned with the interface before the implementation.

If you've never done this before, it can be really hard, primarily because it can be difficult to not launch straight into coding. But persevere and you'll never go back to writing code any other way. The advantages really are well worth it. Good luck!

Chris Knight