The students wanted to have some tool support in identifying the relationships between various functions (i..e. who called who). This was simpler in theory than in practice.
A not-so-quick search on the internet listed some potential candidates:
Code Visualizer
Crystal FLOW for C
Code Visual to Flowchart
http://www.EtherPad.com
http://www.metamill.com/
http://rigi.uvic.ca/
http://www.informatik.uni-stuttgart.de/ifi/ps/bauhaus/index-english.html
However none of these were very easy to use, or could not handle C as a programming language.
They also tried Rhapsody since they had a student license form another course and Enterprise Architect since it was possible to download a time-limited demo and these programs had no problems importing the code and identifying modules and functions, but they did not identity the calling relationships.
The students did not want to spend to many hours fiddling with tools so in the end they settled for manually inspecting the C code and identify what files included what other files. Since it was a distributed embedded system with 4 microprocessors and about 30 kLOC it was a doable task. Let's say that the 7 development teams had
quite different "strategies" for decomposing their code.
My personal observation is that even such a "simple" thing as decomposing you C program into files actually needs structuring principles if several development teams (or developers) work in a project, otherwise maintenance will be very difficult.
I still haven't decided if I should publish the more "awkward" ways to do it as examples to learn form, I don't want to point fingers at any particular students.
No comments:
Post a Comment