1000 Java Tips ebook
Free "1000 Java Tips" eBook is here! It is huge collection of big and small Java
programming articles and tips. Please take your copy here.
Take your copy of free "Java Technology Screensaver"!.
Easy Learn Java: Programming Articles, Examples and Tips - Page 363
1060 Stories (530 Pages, 2 Per Page)
Iterative/Incremental Development -I
There are many ways to divide the Software Development Life Cycle.
I've choosen some common terms, but don't be surprised to see other terms.
Here's a brief explanation of the what each means.
- Analysis - Also called requirements analysis. This is the process
of figuring out what the customer wants or needs.
- Design - This is the process of deciding how to structure the
program. For large projects this is often divided into two stages:
architectural design and detailed design.
- Testing - This is the process of trying to detect errors in the program.
For large programs this is typically divided into two parts: unit testing
tests individual modules and integration testing sees if the total
program works when all the modules are run together.
Waterfall technique -- traditional, but risky
When you understand a problem and its solution very well, it's possible write a
program by following the steps at the left. But problems are rarely understood
as well at initially thought, and this "waterfall" approach has turned out to be
responsible for an
high number of software project failures. There are several reasons for this.
This are some of the typical reasons that use of the Waterfall methodology is
not recommended. An iterative/incremental approach is better.
- Mistakes in the understanding the the early phases (eg, requirements
analysis and design) that are not discovered until the testing or
integration phases are expensive (ie, time consuming) to fix, costing much
more time (eg 20x) to fix than if they had been done right the first time.
The earlier mistakes are discovered, the easier they are to fix. The cost of
finding an error that must be fixed in the completed design or coding phases
is usually quite high. Student programs often suffer from this in several
- The requirements of a programming problem may not be well
understood. For example, the instructor may not have written a clear
- If the student is designing their own project, they may not always
be clear about what they want. Typically, the idea for a student project
evolves as the project progresses.
- Sometimes the programming solution may not be well understood, and a
plan is made based on incorrect ideas about what will work.
- The resources (ie, time) required to complete a program are not
accurately estimated (almost always in the optimistic direction). In
commercial development this results in late delivery and cost overruns or
cancellation. In student programs it means that the program doesn't run,
with unhappy consequences.
Disadvantages compared to iterative method
- The cycle of getting rid of compilation errors can be unnecessarily
- The output may not be what you want, but when debugging an entire
program, it's harder to identify the source of the error.
3 comments | | Score: 0
Posted by jalex on Wednesday, May 25, 2005 (00:00:00) (2451 reads)
Fail Early, Fail Often
You will write bugs
In programming you will write a lot of bugs. Just accept it. I've known a lot of
fantatically capable programmers, but only one who wrote essentially flawless
code in the first draft, Ira Rubin.
Mistakes are educational
If you aren't writing bugs, at least while you're still learning the art of
programming, you probably aren't pushing yourself to try new things. You can
rationalize a lot of errors by repeating "I learn more from my mistakes than my
successes", and it's probably true.
Compile-time errors are the best
Ideally, you want someone else to find your errors. Compiler error checking is
your friend because it finds errors you've made immediately and tells you about
them. Some development systems even have continuous compilation, so you are
informed about errors during compilation. I haven't tried these systems, but
imagine it might work something like spelling checkers that put a read line
under words that might be errorneous as you type -- not intrusive, but letting
you know where there may be a problem.
The quality of compile-time error diagnosis is both a function of language
design and the compiler design. The Java language is so-so in this area, however
its strong typing (variable types must be declared) and required casting
are very good features. Some of the rumored featuers of JDK 1.5 will further
improve compile time checks, eg, templates, type-safe enums, and a "foreach"
statement. The goal of not allowing illegal programs to compile is impossible,
but its always interesting to think of how the language design could be improved
to help detect errors at compile time.
Catch runtime errors early if possible
The worst kind of runtime error causes the program to slowly fall apart. Perhaps
the greated leap that Java made over C++ is in providing runtime checks that
various common errors. Perhaps the most important features are garbage
collection and array indexes out of range.
Yet, there are still many possible run-time errors. Java provides another
great tool in the
assert statement which checks that things
that must be true really are (See Assertions). Learn about assertions and use
While it is true that testing can only show the presence of bugs, not their
absence, it essential. Methodologies such as Extreme Programming require
that test data be written before the code. The
facility makes writing and running tests much easier. With fast machines it is
possible to run regression tests frequently. See Testing.
Fail early, fail often
You will write bugs and you want them caught as early as possible. Use types to
help catch errors at compile time if possible; use assertions to stop execution
if something is wrong; use rigorous testing to find errors.
7 comments | | Score: 0
Posted by jalex on Tuesday, May 24, 2005 (00:00:00) (1942 reads)