Structure Chart, Algorithm....

My programming teacher asked me to write a program to find the average of a class by entering percentages.
I have completed the program, but along with the program, he has asked to provide a structure chart, and algorithm.
From my understanding they are the same thing.
Anyone know what the hell he's talking about?

cheers

 

A structure chart is generally a diagramatic (e.g. flowchart, UML, etc.) way of showing the program flow and logic. These are useful since pictures tell a thousand words and can aid an understanding of the program very quickly but they lack detail. The structure chart is often supported by psuedo-code description showing how the algorithm is implemented.

An algorithm is a step-by-step word description (or even mathematical symbols) of the method that is coded in your program. Along with the description of method are a description of its interfaces, e.g., data, user interface, API and any limitations for the method. This provides the detail that the diagram cannot show but takes longer to understand the full description of the method and can be prone to missing essential detail or have assumptions. Ideally you should be able to code directly from the descriptive method.

 

Is it possible to do a structure chart in your algorithm?

 

For small simple programs the documentation does contain all the components both diagrams, method, requirements specification, etc.

However, for large scale programs with multiple routines, sub-systems, interfaces etc. the diagrams and general description are the high level design documents whereas the method or algorithm is the detailed design documents. This follows a standard practice in application design and development of a top-down structured implementation. This then allows you to consider the implications of the whole system before getting bogged down into the detailed programming.

This doesn't prevent the bottom-up approach from happening in business when someone codes directly and creates the documentation afterwards. In reality when this happens the documentation is seen as a chore and forgotten or is of poor quality. Leading to a maintenance nightmare when the complex coding has to be re-learnt and modified without a full understanding of the system.

I've only scratched the sureface here of a very large subject and I could go on at length and give a lecture on software engineering. I will say that when you develop software in business it is NOT your personal software nor for your benefit but for the benefit of a community and business. Also, no one is perfect and mistakes in software happen despite the best efforts to minimise it but a good quality design documentation using the techniques that you are learning proves extremely valuable in business whose life depend on the software performing well.

I think you need to ask why do these things from your teacher so that you can learn that it isn't just something that got to be done to keep someone quiet so that you can program in peace. Hopefully I have provided you with some thirst for knowledge here...

 

Indeed you have.

Cheers !