Easy to Learn Java: Programming Articles, Examples and Tips

Start with Java in a few days with Java Lessons or Lectures

Home

Code Examples

Java Tools

More Java Tools!

Java Forum

All Java Tips

Books

Submit News
Search the site here...
Search...
 
Search the JavaFAQ.nu
1000 Java Tips ebook

1000 Java Tips - Click here for the high resolution copy!1000 Java Tips - Click here for the high resolution copy!

Java Screensaver, take it here

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


Previous 1060 Stories (530 Pages, 2 Per Page) Next

Iterative/Incremental Development -I

Go to all tips in Java Notes by Fred Swartz

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 Waterfall stepsextraordinarily high number of software project failures. There are several reasons for this.
  • 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 ways.
    • The requirements of a programming problem may not be well understood. For example, the instructor may not have written a clear problem statement.
    • 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.
This are some of the typical reasons that use of the Waterfall methodology is not recommended. An iterative/incremental approach is better.

Disadvantages compared to iterative method

  • The cycle of getting rid of compilation errors can be unnecessarily long.
  • 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 | Printer Friendly Page  Send to a Friend | Score: 0
Posted by jalex on Wednesday, May 25, 2005 (00:00:00) (2451 reads)

Fail Early, Fail Often

Go to all tips in Java Notes by Fred Swartz

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 them.

Rigorous testing

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 JUnit testing 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 | Printer Friendly Page  Send to a Friend | Score: 0
Posted by jalex on Tuesday, May 24, 2005 (00:00:00) (1942 reads)

Previous 1060 Stories (530 Pages, 2 Per Page) Next

530| 529| 528| 527| 526| 525| 524| 523| 522| 521| 520| 519| 518| 517| 516| 515| 514| 513| 512| 511| 510| 509| 508| 507| 506| 505| 504| 503| 502| 501| 500| 499| 498| 497| 496| 495| 494| 493| 492| 491| 490| 489| 488| 487| 486| 485| 484| 483| 482| 481| 480| 479| 478| 477| 476| 475| 474| 473| 472| 471| 470| 469| 468| 467| 466| 465| 464| 463| 462| 461| 460| 459| 458| 457| 456| 455| 454| 453| 452| 451| 450| 449| 448| 447| 446| 445| 444| 443| 442| 441| 440| 439| 438| 437| 436| 435| 434| 433| 432| 431| 430| 429| 428| 427| 426| 425| 424| 423| 422| 421| 420| 419| 418| 417| 416| 415| 414| 413| 412| 411| 410| 409| 408| 407| 406| 405| 404| 403| 402| 401| 400| 399| 398| 397| 396| 395| 394| 393| 392| 391| 390| 389| 388| 387| 386| 385| 384| 383| 382| 381| 380| 379| 378| 377| 376| 375| 374| 373| 372| 371| 370| 369| 368| 367| 366| 365| 364|
363
| 362| 361| 360| 359| 358| 357| 356| 355| 354| 353| 352| 351| 350| 349| 348| 347| 346| 345| 344| 343| 342| 341| 340| 339| 338| 337| 336| 335| 334| 333| 332| 331| 330| 329| 328| 327| 326| 325| 324| 323| 322| 321| 320| 319| 318| 317| 316| 315| 314| 313| 312| 311| 310| 309| 308| 307| 306| 305| 304| 303| 302| 301| 300| 299| 298| 297| 296| 295| 294| 293| 292| 291| 290| 289| 288| 287| 286| 285| 284| 283| 282| 281| 280| 279| 278| 277| 276| 275| 274| 273| 272| 271| 270| 269| 268| 267| 266| 265| 264| 263| 262| 261| 260| 259| 258| 257| 256| 255| 254| 253| 252| 251| 250| 249| 248| 247| 246| 245| 244| 243| 242| 241| 240| 239| 238| 237| 236| 235| 234| 233| 232| 231| 230| 229| 228| 227| 226| 225| 224| 223| 222| 221| 220| 219| 218| 217| 216| 215| 214| 213| 212| 211| 210| 209| 208| 207| 206| 205| 204| 203| 202| 201| 200| 199| 198| 197| 196| 195| 194| 193| 192| 191| 190| 189| 188| 187| 186| 185| 184| 183| 182| 181| 180| 179| 178| 177| 176| 175| 174| 173| 172| 171| 170| 169| 168| 167| 166| 165| 164| 163| 162| 161| 160| 159| 158| 157| 156| 155| 154| 153| 152| 151| 150| 149| 148| 147| 146| 145| 144| 143| 142| 141| 140| 139| 138| 137| 136| 135| 134| 133| 132| 131| 130| 129| 128| 127| 126| 125| 124| 123| 122| 121| 120| 119| 118| 117| 116| 115| 114| 113| 112| 111| 110| 109| 108| 107| 106| 105| 104| 103| 102| 101| 100| 99| 98| 97| 96| 95| 94| 93| 92| 91| 90| 89| 88| 87| 86| 85| 84| 83| 82| 81| 80| 79| 78| 77| 76| 75| 74| 73| 72| 71| 70| 69| 68| 67| 66| 65| 64| 63| 62| 61| 60| 59| 58| 57| 56| 55| 54| 53| 52| 51| 50| 49| 48| 47| 46| 45| 44| 43| 42| 41| 40| 39| 38| 37| 36| 35| 34| 33| 32| 31| 30| 29| 28| 27| 26| 25| 24| 23| 22| 21| 20| 19| 18| 17| 16| 15| 14| 13| 12| 11| 10| 9| 8| 7| 6| 5| 4| 3| 2| 1|


Home Code Examples Java Forum All Java Tips Books Submit News, Code... Search... Offshore Software Tech Doodling

RSS feed Java FAQ RSS feed Java FAQ News     

    RSS feed Java Forums RSS feed Java Forums

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest 1999-2006 by Java FAQs Daily Tips.

Interactive software released under GNU GPL, Code Credits, Privacy Policy