Planning / Designing computer programs?

[christinetom]

Hi there everybody. I hope you are all well.
I have a question about planning and designing computer programs.
Can someone tell me how someone going about a large program would go about this. There would be allot of classes, functions, modules etc. I want to learn how to do this more professionally myself but I don't know how. Is there a technique using something like UML or type of software or syntax in which programs are designed on paper or on screen etc?

Any help on this topic would be very much appreciated.

Thenks....:) :) :)

[Hiroshe]

There are a lot of ways. For user programs I generally use incremental-like development myself. For more API-like things, I plan the interface out (headers and studs) before going into a more incremental-like development mode. This worked fairly well in teams I've worked with. I'm not saying it's supirior though.

Each increment must have pass all tests, must include any new tests, and must be compilable. Each increment is commited with a meaningfull comment.

Make sure you use revision control, some systematic way of documenting your code and a decent testing framekwork. Also spend time on manually using the software and looking for bugs (unit tests generally do well to avoid introducing new bugs, but it's not generally as effective for discovering new bugs).

Never found UML too usefull to be honest. Maybe a quick diagram to include all of the important parts to help out writting the headers and studs. Some will probably disagree with me on this.

[mike_2000_17]

I agree with Hiroshe about UML diagrams. I have rarely found them to be useful. I think that they are simply too detailed. If you have to make a diagram that has all your classes, with all of their data members and methods (functions), you are basically doubling your workload (because it takes about as much time making that diagram as it takes to write the code), and you don't really get that "big picture" benefit because there are so many details in a UML diagram that anything that is non-trivial will end up as a huge UML mess of details and connections. I see UML diagrams more as a way to graphically document an existing design, not as a tool for designing it. But I sometimes draw higher level diagrams, with none of those unecessary details, only to map out the building-blocks of the software and their inter-dependencies (very important!).

I also don't see UML diagrams being used that much as a form of communication about software design ideas either. All seasoned programmers know code very well, and therefore, it seems like a much more natural language of communication than UML diagrams. What I tend to see the most is people expressing their design ideas in the form of snippets of code (often just stubs) that illustrate how it should work ("use-cases") or how it could be done (e.g., like the skeleton of an implementation, maybe some pseudo-code in there). And I think that this seems to be a fairly effective method of communicating ideas or design proposals between developers in a team. Of course, when you have to present it to the manager / boss, you translate those mock-up designs into some UML diagrams, and then you insert the word "Agile" all over your presentation, because managers need to hear or read that word every 5 minutes or else they get withdrawal symptoms.

The main thing to do really is to figure out what logical separations you can make in the code, i.e., what are the building-blocks? (classes, modules, etc.) And then map out what depends on what, or what should depend on what (or should not depend on). It's all about putting the right things (e.g., "responsabilities" or "operations") at the right places such that you minimize inter-dependencies, because that's where all the real complexity is in software design, i.e., it's not about the number of parts to the software, it's about the number of connection between the parts that really complicates things. A design where "everything depends on everything else to work" is the very definition of horrible. A good design is the opposite of that.

There are lots of buzzwords around software development methodologies (like "Agile") and all that, but at the end of the day it really just boils to:

1. Know what you want.
2. Know what you are doing.
3. Do it correctly.

When you lay out your requirements correctly, and you know what you're doing (comes with experience only), then the software sort of just takes shape in your mind because it usually involves design patterns that you've done before and solutions that you know will work nicely for the problem at hand. And you should never byte off more than you can chew, i.e., there is no proper software design that really requires a full and comprehensive system design because if things are well-separated, then you should only need to design limited parts of it at a time. Then, your requirements usually turn into unit-tests and integration tests that kind of layout the details of how everything should work and what the expected behaviour is. Then, you just incrementally code, test, code, test, until you're done.

When you lack experience, you just have to be a bit more cautious to avoid pinning yourself in a hole (design-wise) that you can't get out of without restarting the whole thing (which will happen, I guarantee you). You also have to seek out that knowledge about typical patterns and solutions used for the kinds of problems you are trying to solve. But otherwise, the process is the same, it's just that you'll be stumbling around and banging your head more often than your more experienced counter-parts.

And as for being "more professional", there isn't really any magic to it either. A "professional" works more effectively with the tools around him. Things like version control, documentation generators, build systems, package managers, various scripts, nightly builds, etc... are all things that people use to varying degrees. Another aspect of being professional is being serious about quality assurance and maintainability. In other words, professionals care about creating robust and reliable software that could last for decades without major failures or difficulty in maintaining it (bug-fixes, added features, updates, etc.). So, things like unit-tests, regression tests, incremental development, abiding to a number of maintainability "coding practices" (e.g., self-documenting code, documenting interfaces, isolating external dependencies, etc.), and so on, are all part of insuring that the software is solid and will remain so.

You might say that this answer is too general and vague, that I don't give any specific "trick" that will make you an awesome software engineer. But don't expect anything more than vague generalizations to a question like this. For example, if you ask a carpenter about what's the trick to building a great house, don't expect him to tell you that if you just hold the hammer in a particular way, a great big house will pop out of the ground by magic. In reality, the carpenter has developed a number of tricks, of ways to do things, and of instincts that help him to just do it right and be effective at it.

[rubberman]

Well, I have to disagree with Mike2K with regard to UML, but that depends upon the tools you use. I employ Sparx Enterprise Architect for my design needs, and then use it to generate source code. If I have to work with existing code, then I used its reverse engineering capabilities to capture the code design into UML diagrams. I have designed major software systems in use for many enterprise systems since the early to mid 1990's using UML or earlier OOP tools (I was there when Booch, et al announced UML 1.0 at OOPSLA in San Jose). Modern tools such as Enterprise Architect, Rose, Tau G2 (Rose and G2 are currently owned by IBM), and such are often capable of forward and reverse engineering from model to code to model. So, there is no doubling of effort, provided you use appropriate tools.

Many of the complex systems I have designed and implemented since the early 1990's would have not been possible without the use of modern design tools (UML, Booch diagrams, CRC cards, etc). The complexity is very much clarified with such tools, allowing one to understand the relationships between classes that would be daunting if you only have source to analyze.

[christinetom]

Thansk everyone. That will be useful.
For a rookie like me I just needed to get an idea of how to go about this kind of thing. My projects are getting bigger so I figured that I should start learning how the pro's deal with the complexity. I agree that my question may have been a little vauge but to get an overall view of my options is really what I'm looking for. I will probably pick one option and focus on that for a while just to get used to the idea of using it over time.

Any other suggestions welcome.

Thank you again.

[christinetom]

Actually, I have decided to use UML just to describe some of my projects to others. I was wondering, while I am on the subject, if anyone knows of some good free open source UML editors? I know there are allot but thought that maybe some are better than others.

[DonnSchwartz]

There are something that you have to be familiar with before starting a programe. When i did a school management programe (infactr that was not a vaste programe) i found very difficult as i was not knowing anuything about that. Well plansed mind is the thing what you should have before going for the work. You should have a complete knowledege within you like what you really want to producw, what and all the tool you should really have. Of course this is not a simple task as i am telling. You may take even a week to complete this, i took. you should have a complete rough book on your hand with a well explained details

[Bunny Slimer]

I think Hiroshe about UML diagrams might be useful.