There are two primary factors influencing strategy for migration of design to code.

a. Work Conduct

We decided to use the Threads approach for Work Conduct of our project. We also used a top-down approach in our Threads strategy. This means that we produce our modules in sets according to association with particular functionality. Since Rational Rose was used in our design, it was easy to identify modules that need to be developed and then develop them.

The advantages in our approach are that we can have focused debugging and uniform programming and documentation standards. We can decide whether to build the drivers or stubs first and in our development, we generated the stubs using Rational Rose.

However this approach makes debugging difficult but fortunately our development team works tightly together, enabling us to crush bugs easily. Although the user of our product sees it very late, we can ensure that with our Work Conduct approach, the user will be receiving a very high quality product.

b. Base Product

We chose to have our product to be custom-made. This means that all our modules are coded from scratch. Our team also integrated our custom modules from scratch. No reused or pre-built components are used in our product. We chose the custom product over a package product that consists of modules pre-built and fully integrated into complete ready-to-use system because there are no easily available pre-built modules for the product we are developing. Even if there are pre-built modules available, we foresee a lot of localization and customization will be needed and that it might be much easier just to code from scratch. This is because we are developing a quite unique product in a parking system.

A observation at the Implementation Success Zone chart which shows the strategic combo of Work Conduct and Base Product that is likely to bring more successful implementation indicates that our approach is most likely to succeed, choosing to use a Threads Work Conduct and Custom Base Product.

2. Implementation Issues

a. Programming language and complier chosen

We chose the Java programming language in the development of our product because of the versatility it possesses and the ease in porting our code to our platforms if necessary. Choosing a object oriented language like Java also allows us to develop our product systematically. The Sun Microsystems Java 1.2 complier is used as it is free of charge and provides all the functionality needed in developing our product.

b. Code production

Rational Rose was used to auto-generate stubs of codes for our programming team to fill up the logic.

c. Coding style

We ensured that our coding style complies with the high standards set by our team although there were no requirements from our customer.
We used meaningful, descriptive and definitive identifiers in our code.
The standard practices to enhance readability of our code are ensured.

E Blank lines to separate instruction blocks
E Indent to highlight instruction hierarchy, blocks within blocks
E Parenthesis sets (open, close) aligned by column
E Parse long phrases (semantically correct, meaningful)
E Explain design logic, operations via comments

d. Quality Coding

To ensure quality code is produced, we avoided deep nesting, keeping loops to at most 3 levels and avoided compound condition tests. Variables are initialized before use in formulae and implicit type conversion is avoided unless absolutely necessary

Also we adopted the n-Version programming defect defeat technique for our important modules. Modules like the calculation of parking fees, which involves money, are implemented by different members in our team. This ensures that the same defect occurring in our product is highly unlikely. Since this method is resource intensive and therefore very expensive, only a few critical modules are implemented and analyzed separately.

3. Documentation

Standard documentation like headers, instruction blocks and line comments are found in our code to ensure that our team members know exactly what code does what kind of work. The source code itself constitutes the main implementation document itself. We made sure that although there is no absolute standard in documenting our code, we kept our documentation at a very high level to help in debugging and reusability.