J.E.D.I
to lower level components. Design correspondence with source code allows us to locate the necessary source code to be modified.
5.2 Programming Guidelines
Programming is a creative skill. The programmer has the flexibility to implement the code. The design component is used as a guide to the function and purpose of the
component. Language-specific guidelines are not really discussed here but for the Java Programming
Standard Guidelines
see their
website at
http:java.sun.comdocscodeconvindex.html . This section discusses several guidelines
that apply to programming in general.
5.2.1 Using Pseudocodes
The design usually provides a framework for each component. It is an outline of what is to be done in a component. The programmer adds his creativity and expertise to build
the lines of code that implement the design. He has the flexibility to choose the particular programming language constructs to use, how to use them, how the data will
be represented, and so on.
Pseudocodes can be used to adapt the design to the chosen programming language. They are structured English that describes the flow of a program code. By adopting the
constructs and data representations without becoming involved immediately in the specifics of a command or statement, the programmer can experiment and decide which
implementation is best. Codes can be rearranged or reconstructed with a minimum of rewriting.
5.2.2 Control Structure Guidelines
The control structure is defined by the software architecture. In object-oriented software, it is based on messages being sent among objects of classes, system states
and changes in the variables. It is important for the program structure to reflect the designs control structure. Modularity is a good design characteristic that must be
translated to program characteristic. By building the program in modular blocks, a programmer can hide implementation details at different levels, making the entire system
easier to understand, test and maintain. Coupling and cohesion are another design characteristics that must be translated into program characteristics.
5.2.3 Documentation Guidelines
Program Documentation is a set of written description that explain to the reader what the programs do and how they do it. Two program documentation are created: internal
documentation and external documentation.
Internal Documentation
It is a descriptive document directly written within the source code. It is directed at some who will be reading the source code. A summary information is provided to
describe its data structures, algorithms, and control flow. Normally, this information is placed at the beginning of the code. This section of the source code is known as the
header comment block. It acts as an introduction to the source code. It identifies
Software Engineering 204
J.E.D.I
the following elements: • Component Name
• Author of the Component • Date the Component was last created or modified
• Place where the component fits in the general system • Details of the components data structure, algorithm and control flow
Optionally, one can add history of revisions that was done to the component. The history element consists of:
• Who modified the component? • When the component was modified?
• What was the modification? Internal documents are created for people who will be reading the code.
Tips in writing codes 1. Use meaningful variable names and method names.
2. Use formatting to enhance readability of the codes such as indention and proper blocking.
3. Place additional comments to enlighten readers on some program statements. 4. Have separate methods for input and output.
5. Avoid using GOTOs. Avoid writing codes that jump wildly from one place to another.
6. Writing code is also iterative, i.e., one starts with a draft. If the control flow is complex and difficult to understand, one may need to restructure the program.
External Documentation
All other documents that are not part of the source code but is related to the source code are known as external documents. These type of documents are indented for people
who may not necessarily read the codes. They describe how components interact with one another which include object classes and their inheritance hierarchy. For object-
oriented system, it identifies the pre-conditions and post-conditions of the source code.
Software Engineering 205
J.E.D.I
5.3 Implementing Packages
