|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 5 of 7
There are many approaches to software design. Formal methodologies attempt to guide you through the process of transforming a problem domain into a solution domain. In designing Java programs, you may choose to use a formal methodology, to combine several formal methodologies, or to forgo formal methodology and design by the seat of your pants. But no matter how you attack the design phase of your software project, you should in some way document your design.
Documentation helps you keep track of your own design and helps you communicate it to others. Communicating your design to other developers before you implement can give you valuable feedback on your design early on, while it is still relatively easy to make changes. It is usually easier to correct design flaws during the design phase than it is later, during the implementation or the integration and test phases. (Note that this process of getting feedback on your design, and making the appropriate adjustments, is yet another example of iteration in software development.)
Many design methodologies include graphical conventions for describing a design. CASE (Computer Aided Software Engineering) tools often allow you to document your design as you create it. With Java, however, you have one other option. Java offers a simple way to express a software design not requiring anything that isn't a standard part of any Java development environment.
Documenting a design in code
A simple approach to design documentation is to express your design in Java code that has the structure and organization,
but not the functionality, of your end product. You define and name classes and interfaces, and describe them in comments.
You define the name and type of each field, and describe them in comments also. You define the name, return type, number of
parameters, and parameter types of each method, but you don't define the method body. Instead of a body, you write a comment
that describes what the body of the method, once implemented, will do. The comment can be pseudo-code, regular text description,
or both. If you take this approach, your design will remain relatively easy to change throughout the design process.
If you do this, then at the end of the design phase you will already have a lot of Java code. For each program for which you did a user interface prototype, you'll have a framework of Java code for that program -- one that has look but no functionality. (These are the user interface classes.) You will also have a framework of Java code for each class that you designed with fields, comments, and methods with empty bodies. (These are the problem domain and data management classes.)
Presenting a design with javadoc
The Java programming environment includes a tool, javadoc, that can help you document and communicate your design. In Java, there are three kinds of comments:
///* and *//** and */// indicates that the rest of the line is a comment. /* and */ indicate that all characters between the initial /* and the terminating */ should be ignored by the compiler. /** and */ also comment out anything between them; however, the comments between /** and */ are picked up by the javadoc tool and placed into an HTML file it generates to document the code. Because of this, comments starting with /** are called documentation comments, or simply doc comments. javadoc parses .java files and generates several HTML files that describe classes, fields, methods, and that show doc comments.