Project Planning? (UML?)
I am pretty new to programming (I have programmed 3 basic games, tetris, breakout, and a maze with enemies) and am looking to start on a slightly bigger project. Not entirely sure what yet, probably some kind of side-scroller. (Possibly a platformer, or maybe a Gradius clone.) Either of these options would be big enough that programming-as-I-go will probably set me up for disaster, or having to redo code several times, so I am looking into having at least a rough framework sketched up before I start coding. I am wondering what tools or strategies other devs use/have used that might be helpful. I have read a little bit on UML, but everything I have read about it has been mixed reviews. (Also, there are all different kinds of diagrams and charts to it, and it sounds fairly complicated, so I don't know if it's worth the time investment to just learn a diagraming method, especially when reviews are mixed.)
One site I have found and dabbled around with (it's not programming specific) is www.exobrain.co, which seems useful for mental mapping. In its simplicity though, and having only just started with this, I don't know if it will provide everything I need. I have attached a picture of a section of my longer term project that I have started planning on here. My scheme was to pick a color for Class, Interface, Member, and Method, so for each class, I could create all the members and methods I thought it would need, and keep them clear by color coding. I don't think this is a bad method, but I'm curious what strategies other people use.
Thank you,
-Wally
[attachment=11329:Exobrain.png]
One site I have found and dabbled around with (it's not programming specific) is www.exobrain.co, which seems useful for mental mapping. In its simplicity though, and having only just started with this, I don't know if it will provide everything I need. I have attached a picture of a section of my longer term project that I have started planning on here. My scheme was to pick a color for Class, Interface, Member, and Method, so for each class, I could create all the members and methods I thought it would need, and keep them clear by color coding. I don't think this is a bad method, but I'm curious what strategies other people use.
Thank you,
-Wally
[attachment=11329:Exobrain.png]
or having to redo code several times,
"No plan survives first contact with reality." - adapted shamelessly from a paraphrased quote of a 19th century Prussian General.
You're going to need to adapt, re-arrange and generally redo code as you learn more about your problem and run into issues where your mental model wasn't 100% accurate. Plan for that.
In general, a pencil and paper is still the best design tool for a programmer. Once you get more than one, a whiteboard is better. Proper UML is a waste of time (imo).
So what kind of things would you map out with your pencil and paper? Do you keep it at the high level, showing only classes? Do you detail methods and members? Do you try to flow diagram it, showing roughly chronologically the sequence of events/calls? Some of all of the above?
I'm sure everyone has their own level of detail that they go into when tackling a problem, just as everyone has their own distinct approach to a problem. I'm just looking for suggestions on what approaches people have used and found helpful.
I'm sure everyone has their own level of detail that they go into when tackling a problem, just as everyone has their own distinct approach to a problem. I'm just looking for suggestions on what approaches people have used and found helpful.
Do you keep it at the high level, showing only classes?
Usually, sometimes not even at the class level; sometimes modules are better.
Do you try to flow diagram it, showing roughly chronologically the sequence of events/calls?
Rarely. I tend toward OO design, so doing data-flow would be improper.
Basically I jot down whatever is necessary to get a firm grasp on the design in my head (and possibly to communicate that design to others so they get a firm grasp of it). Firm enough to run the basic use cases through the mental model, and feel comfortable that I've not missed something major or otherwise made an obviously poor design.
[quote name='EpicWally' timestamp='1347971487' post='4981226']
or having to redo code several times,
"No plan survives first contact with reality." - adapted shamelessly from a paraphrased quote of a 19th century Prussian General.
You're going to need to adapt, re-arrange and generally redo code as you learn more about your problem and run into issues where your mental model wasn't 100% accurate. Plan for that.
In general, a pencil and paper is still the best design tool for a programmer. Once you get more than one, a whiteboard is better. Proper UML is a waste of time (imo).
[/quote]
Personally i think UML is great for documentation purposes. (Gives a nice clear overview of how everything sticks together). its far too much work to maintain manually though. (There are great tools that will create nice looking UML diagrams of your codebase for you)
I kinda agree with both, it depends on what you want to do:
first, you have to order your thoughs and solution ideas, a Mindmap is fit for the job, the Mindmap is only for you.
Then you can go into more detail, just draw what you like on a piece of paper, it only has to make sense to you.
If someone else should understand it too, there is where UML is a good tool, since it is widely used.
Keep in mind, UML is not the ultimate solution. There are other diagrams that also offer functionality. For ex. Petri Nets are great to model states and statechanges. With sofisticated analysis tools you can check for deadlocks, unreachable states,starvation etc.
If the client doesn't want to see any diagrams, it is completely up to your team.
If you work alone, you may not need to go to the hassle of UML.
E: in the end, choose the right tool for the right job. You don't do anything wrong with UML, but sometimes you can do better.
first, you have to order your thoughs and solution ideas, a Mindmap is fit for the job, the Mindmap is only for you.
Then you can go into more detail, just draw what you like on a piece of paper, it only has to make sense to you.
If someone else should understand it too, there is where UML is a good tool, since it is widely used.
Keep in mind, UML is not the ultimate solution. There are other diagrams that also offer functionality. For ex. Petri Nets are great to model states and statechanges. With sofisticated analysis tools you can check for deadlocks, unreachable states,starvation etc.
If the client doesn't want to see any diagrams, it is completely up to your team.
If you work alone, you may not need to go to the hassle of UML.
E: in the end, choose the right tool for the right job. You don't do anything wrong with UML, but sometimes you can do better.
In my experience, which compared to many here is negligible, UML is a nice tool. I use basic class diagrams to get an idea of how classes can be generallized(hmm... all 3 of these have a transform function, perhaps a superclass should be created) and broken into separate codebases/libs. I also am a big fan of sequence diagrams, so I can see who will call what to get the job done.
On the other hand, as Simon mentioned, UML is it's own language, so essentially you are writing code twice, each time you change your code, you must update your UML model to reflect the changes, or vice versa. I find it the same way with documentation. So you may end up writing your program 3 times in 3 languages. Enter tools like doxygen, to extract usable documentation, or staruml(my personal fav uml modeller) to extract uml class diagrams from a code base.
My work flow now is: a
quickie design model, using starUML, pen and paper is fine, but with starUML I can then export as c++( interfaces only, unfortunately it doesn't write implementations ).
test/debug/rinse/repeat until I'm happy it works as expected.
import the 'finished' project into starUML as an implementation model.
create docs with doxygen.
On the other hand, as Simon mentioned, UML is it's own language, so essentially you are writing code twice, each time you change your code, you must update your UML model to reflect the changes, or vice versa. I find it the same way with documentation. So you may end up writing your program 3 times in 3 languages. Enter tools like doxygen, to extract usable documentation, or staruml(my personal fav uml modeller) to extract uml class diagrams from a code base.
My work flow now is: a
quickie design model, using starUML, pen and paper is fine, but with starUML I can then export as c++( interfaces only, unfortunately it doesn't write implementations ).
test/debug/rinse/repeat until I'm happy it works as expected.
import the 'finished' project into starUML as an implementation model.
create docs with doxygen.
I have never found UML diagrams helpful.
Things that do help me are:
I normally choose to implement some basic things to get a framework going, and then I concentrate on the hardest parts. The program takes shape quickly from there and, although I didn't know the whole design from the beginning, the result is normally pretty acceptable. If it is not acceptable, hopefully the division of the program into modules will keep the damage confined to one or two modules that I may have to rethink.
The thing is, I don't know if this way of programming works for everyone or not. It probably wouldn't have worked for me when I had a lot less experience. I guess what I am trying to say is: Don't worry too much about design if you don't have much experience, because the ability to design comes with experience.
Things that do help me are:
- a rough division of the program into modules,
- a description of the interface between modules and
- prototyping the parts that are not completely clear in my head.
I normally choose to implement some basic things to get a framework going, and then I concentrate on the hardest parts. The program takes shape quickly from there and, although I didn't know the whole design from the beginning, the result is normally pretty acceptable. If it is not acceptable, hopefully the division of the program into modules will keep the damage confined to one or two modules that I may have to rethink.
The thing is, I don't know if this way of programming works for everyone or not. It probably wouldn't have worked for me when I had a lot less experience. I guess what I am trying to say is: Don't worry too much about design if you don't have much experience, because the ability to design comes with experience.
I just started using exobrain, and will probably use it from now on. I like how it provides a general overview of my whole project so I know what to program and don't have to keep thinking back.
Thanks everyone for the tips!
Hmm... That makes a lot of sense. Thank you.
Awesome! Glad you're finding it useful. As far as I can tell, it's kinda new, so they're still working on adding features and functionality.
The thing is, I don't know if this way of programming works for everyone or not. It probably wouldn't have worked for me when I had a lot less experience. I guess what I am trying to say is: Don't worry too much about design if you don't have much experience, because the ability to design comes with experience.
Hmm... That makes a lot of sense. Thank you.
I just started using exobrain, and will probably use it from now on. I like how it provides a general overview of my whole project so I know what to program and don't have to keep thinking back.
Awesome! Glad you're finding it useful. As far as I can tell, it's kinda new, so they're still working on adding features and functionality.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement