Software Engineering
Home Planning Requirements Writing Hazard Analysis Requirement Analysis Config Control Software Design Software Testing Software Standards Basic Logic

Software Design Case Study - Currency Conversion

The Problem

This was a simple introductory class assignment in C programming, originally for the days of MS-DOS and command lines.. I've used it from time to time as a WIN32 console application, to demonstrate functional decomposition and design-by-comments. The assignment was simple enough, but I rewrote the original requirements as a series of use cases, to facilitate design and testing. The overall goals were to:

  • Display the names of currencies and their U.S. dollar equivalents.
  • Allow the user to select a currency from the menu and convert it to any other currency on the menu.
  • User has the option of displaying the results on screen, to a file, or both.
  • Screen shows the results of the last 10 currency conversions.
  • Allow the exchange rates to be read from a file.


Not all countries have the concept of pennies, shillings, or other coinage; therefore the program will assume that all currency input is in integer amounts and the output will be in decimal amounts (e.g. $1.3782).

The output results are to be placed into an array. For simplicity, the maximum size of the array will be set at compile time. The output array will be used as a circular buffer, so that it holds the last 10 conversions.

The format of the currency input file will be ASCII text, either comma or tab separated. The file will contain one line for each currency. Each line will contain the currency name and the conversion to US Dollars (e.g number of Yen per Dollar). The program need only handle up to 20 currencies in the file. When reading currencies from the file, menu letters for each currency will be assigned automatically.

The program will be a WIN32 Console application running from a command line.

The Design

Initially, I identified those parameters that were most likely to change:

  • Number of countries (program was supposed to handle from 2 to 20 countries).
  • Exchange rates between currencies.
  • Name of country (not because of revolutions; but might want to replace one country with a different country).
  • Position of country on the main menu.

As a result, I defined a data file format that would define the country and exchange rate. The program would simply read lines from the file until it either ran out of entries or hit the 20th entry, writing each country's information to a data structure in an array. Menu letters were assigned automatically as the countries were read from the file. This design accommodated the primary source of change in this application.


Functional Decomposition often encourages the use of flow charts. THIS IS A VERY BAD PRACTICE! Flowcharting is a hangover from the days of unstructured programming. Flowcharting was developed when branching was still done by the conditional GOTO: [ IF (condition) GOTO X ]. It is easy to flowchart a logic sequence that either cannot, or should not, be coded.

Instead, I encourage design-by-comments at the function level, and UML for object-oriented design at the application level. Because this was such a small program being written in C, I used functional decomposition exclusively. I began the functional decomposition with the main() function:


This was a console application, so the main() function is called when the program starts. When main() exits, the program ends. I created the project and did the functional decomposition using comments. The initial decomposition was:

/* Initialize program data structures and variables */
/* REPEAT menu selections and conversions */
    /* Display the menu */
    /* Get the source menu selection */
    /* IF Exit not selected THEN
        /* Get the destination currency to convert */
        /* Get the currency amount */
        /* Do the conversion */
        /* Display the results */
    /* END IF */
/* UNTIL exit is selected */

The initial decomposition of the menu selection function was:

/* WHILE a valid menu item has NOT been selected DO */
   /* Get a key from the keyboard */
   /* IF the key is a function key OR a special key THEN */
      /* Throw the key hit away */
   /* ELSE IF key is the Exit key THEN*/  
      /* Set a valid EXIT selection */
   /* ELSE IF key is in the menu list THEN */
      /* Set a valid menu selection */
   /* END IF */

Code was then written under each comment: a function call to perform the required action and return the required result. The functions were written as stubs (function just returns a hard coded value) to allow the program to compile and to initially test the logic in main(). The conversion function was coded first, and the other functions remained stubs, with the menu selection functions being stubbed to return a hard coded menu selection. That allowed unit testing to proceed incrementally, rather than waiting until the entire program was written.

The Implementation

One the functions were designed in comments, code was added beneath the comments. Additional code for error handling had to be added in some cases, such as failure to open a currency definition file. The design was done in comments, and stubbed so that no errors would be caught. Once the main logic was working, code was written to implement the error handling. This is termed an Incremental Life Cycle.

The design can be read in the comments of the source code.

Click here to get the source code in C and the executable program .

Unit Testing

Because the program was designed first, using functional decomposition, and because functions were initially stubbed to return a hard coded value, unit testing could be done incrementally, one function at a time. This allowed early detection of defects. Also, if fundamental logic errors were found, they could be corrected before very much code was written.

The basic set of tests were:

  • Correct display of menu options.
  • Ability to select a source and destination country from the menu.
  • Correct conversion.
  • Correct display of results.
  • Correct display of last 10 conversions.
  • Ability to exit program.
  • Error handling for currency definition file, such as file missing or incorrectly formatted.
  • Error handling for incorrect inputs, such as invalid menu selections or invalid currency amounts (e.g. letters instead of numbers).