This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
I saw a couple of diagrams in random java related searches on google. They arrange the class members systematically. Some even mentioned the functionality/purpose of each member.
I feel that my approach to coding lacks all these "formal" things and is very disorganized. All i do is, think something and start coding almost immediately. Later, I realize that my design is not so good and I have to
redo almost half my code.
I want to get my requirements and documentation right before I begin. I don't want design and documentation as an after thought.
Any suggestions on how to go about it ?
Java Newbie with 72% in OCJP/SCJP - Super Confused Jobless Programmer.
I am a "newbie" too. Please verify my answers before you accept them.
Have you ever come across use-case diagrams, entity relationship diagrams, dataflow models etc? They are a pretty standard way to capture the goal and functionality of a piece of work without being language specific. You could even break your work into different areas and have documentation for each area. Ultimately the time spent thinking and planning (however you do it) before you start coding will save you many times the amount of refactoring and redesigning at a later stage.
I dont have detailed knowledge on ERD and DFDs. I know that I can, from requirements specification document,
- understand in abstract what has to be done,
- figure out what classes and tables etc I have to create and what I have to use (created by others)
- can draw a diagrammatic representation connecting all the classes and databases as I would like to,
- can write down the implementation details, as how would I do it, then
- write all the UnitTest cases
- then REVIEW
Probably the only suggestion you can get is you start learning UML if you already didn't.
Formally defining requirements at the beginning of the project is very important. Discovering requirement mistakes in early phases will save you a lot of time and money later. Though requirements always tend to change and evolve (yes, clients are very strange creatures) you need to make sure you first agree with your client about the requirements you specified formally before you start actually working on them because that's probably the only connection between you two in early phases.
Designing software is all about thinking at the higher lever of abstraction, leaving implementation details aside. We all (software developers) get goose bumps when we hear something like high level of abstraction or something prefixed with meta, and designing is all about that. So it tells you it is probably a good practice, especially in terms of maintainability.
Depending on the project you can choose how deep you want to go into design before you start implementing a solution. In any case, UML is there as a tool for you to specify all you need. The way you iterate over different phases before or during implementation is a matter of method you use for development, which is also an important thing to keep in mind.
I suggest you take a look at the UML website for some more details, find a software that you can use for UML modeling and start learning.
The quieter you are, the more you are able to hear.
subject: How to document requirements, design of classes/code properly before coding begins ?