tags:

views:

144

answers:

3

Hi All,

I would like to know if there are any tools that can help me model C applications i.e. Functional programming. E.g. I'm currently building a shared library. But to communicate my design visually, I need something like UML. I would like to do this so that the person reviewing my design need not read through 100s of pages of functions, variables and so on.

I have read about UML for C, which I'm considering. If there is anything better out there, please let me know. The bottom line is to visualize the design of C applications and modules without reading through 100s of pages of text, because it takes time and is difficult for the reviewers.

Any help in this area from the experts here would be much appreciated.

Thanks.

+5  A: 

A well written text documentation brings you a far. Much further than any UML diagram could ever achieve.

Cheery
Then why is UML a industry standard modelling language and adopted by so many companies. Why don't they just rely on well written text document?.
UML is not really industry standard. There are some companies that implement processes to be ISO 9000 compliant - the go for UML 'cause ISO 9000 auditors just love it. There is no sense in UML otherwise.
qrdl
A: 

Whatever you like. It's not a standard but many devs use it and understand it. If it does help you to communicate with other people and document your work -> its for you. If it just takes too much time and you think it's not effective, drop it. Also, don't bother with all details, as long as it resembles UML and your team can work with it, it's fine.

It's meant to help you, not waste you time.

Nazgob
A: 

You should split this in two parts:

  • What do you want to say?
  • What's the best way to saying it?

Whatever formalism you use to answer the second part, you should be sure it's not ambigous.

The good of UML is that a lot of semantic is already defined by the language so you don't have to include a definition of what those boxes, lines and arrows mean in a collaboration diagram.

But most importantly, documenting something means create a path for others to understand the subject you are documenting. A very precise description that offers no clue on how to read it is as good as none. So, use UML, Finite state machines, ER diagrams, plain English, whatever you want but be sure to include a logical path that your "readers" can follow to understand what's going on.

I had a friend that was a fan of "preciseness at all cost" and it would ask us to go through all the details before some sort of meaning would emerge.

I once ask him to do this experiment: on his next trip to an unknown city, he would have to carry the most precise map he could get. Much better, he would have to carry a 1:1 map of the city with every single detail exactly reported in scale. That way he couldn't get lost!

He declined but I would love to see him trying to use that map. Just even folding it! :)

Remo.D